View
216
Download
1
Category
Preview:
Citation preview
Instanciação de Processos de SoftwareCiro CoelhoGrupo de Estudos em ProcessosCIn – UFPE23/07/2002
ContextoMuitos processos disponíveisMuitos projetos com características diferentesDificuldade de escolher e adequar os processos que serão utilizados em cada projeto
Contexto“Não existe um processo único que seja adequado a todos os projetos”
Alistair CockburnBarry Bohem
Brian Henderson-SellersMark GinsbergMartin Fowler
Rational Unified ProcessWalker Royce
Etc etc etc
Abordagem 1Solução Adotar um processo “de prateleira” para
cada projetoVantagens A solução já está pronta Possibilidade de troca de informações
Desvantagens Dificuldade de treinamento e aplicação de
lições aprendidas Casos intermediários
Abordagem 2Solução Adotar um processo padrão e adaptá-lo a
cada projetoVantagens Adaptável a todos os projetos Está de acordo com CMM nível 3
Desvantagens Dificuldades e custos de instanciação Gera um processo não testado
Abordagem 3Solução Adotar um processo padrão e criar instâncias
fixas desse processoVantagens Todos os processos são parecidos, facilitando
treinamento e aplicação de lições aprendidas A solução já está definida antes do projeto
Desvantagens Esforço inicial muito grande Projetos “diferentes” continuarão exigindo
adaptações
Classificação dos Processos(Martin Fowler, Variations on a Theme of XP)
Processos ConcretosProcessos Adaptáveis (Framework de Processos)Processos FilosóficosConjuntos de Melhores Práticas
Classificação dos Processos Processos Concretos
Conjunto fixo de práticas a serem seguidas, permitindo pouca ou nenhuma variaçãoExemplo: XPPontos Fortes simples de entender e aplicar, pois deixam
claro o que deve ser feito Pontos Fracos não podem ser mudados ou, pelo menos, não
existe uma forma clara e pré-definida para realizar essa mudança.
Classificação dos Processos Processos Adaptáveis
Apresentam guidelines explícitos para realizar a instanciação do processo. Framework de Processos Têm como filosofia apresentar um processo
o mais abrangente possível e instanciá-lo através da remoção de elementos desnecessários para uma situação específica
Exemplo: RUP
Classificação dos Processos Processos Adaptáveis
Pontos Fortes fornecem meios para identificar as possíveis
variações do processo e quando essas variações são apropriadas
existe um único processo que deve ser aprendido e que pode ser aplicado às mais variadas situações
Pontos Fracos normalmente é difícil entender como realizar a
instanciação de forma correta. É preciso entender o processo básico e todas as suas variações antes de decidir o que fazer
custo de instanciação
Classificação dos Processos Processos Filosóficos
Não definem atividades que devem ser realizadas ou artefatos que devem ser produzidos, definido apenas uma filosofia de desenvolvimento a ser adotadaExemplo: ASDPontos Fortes são flexíveis por natureza, podendo ser aplicados a
qualquer tipo de projeto sem a necessidade de definir regras de instanciação
Pontos Fracos como não definem claramente o que deve ser feito, são
processos difíceis de seguir
Classificação dos Processos Conjunto de Melhores Práticas
Não são propriamente processos de desenvolvimento, mas um conjunto de práticas independentes que podem ser aplicadas em qualquer processo Exemplo: PSPPontos Fortes diferentemente dos processos filosóficos,
constituem formas concretas de como realizar tarefas e produzir artefatos
Pontos Fracos não são suficientes para guiar o desenvolvimento
Instanciação de Processos no CMM
KPAs relacionadas Organization Process Focus
Planejamento e coordenação das atividades de desenvolvimento e melhoria do processo de software
Identificação dos pontos fortes e fracos do processo
Instanciação de Processos no CMM
KPAs relacionadas Organization Process Definition
Definição e manutenção de um processo de software padrão para a organização
Coleta, revisão e disponibilização de informações relacionadas ao uso do processo padrão
Instanciação de Processos no CMM
KPAs relacionadas Integrated Software Management
Adaptação do processo padrão para projetos específicos
O projeto é planejado e gerenciado de acordo com o processo definido para ele
Principais Conceitos Organization’s Standard Software Process (OSSP) Project’s Defined Software Process (PDSP) Guidelines e Critérios de Adaptação Plano de Desenvolvimento de Software Banco de Dados de Processos Biblioteca de Documentação de Processos
Instanciação de Processos no CMM
Fatores que Influenciam a Instanciação
Características do projeto Tamanho, distribuição geográfica e
experiência da equipe Criticidade do sistema Tamanho do projeto ... Padrões, normas, contratos etc. O próprio processo padrão
Métodos de Instanciação na Vida Real
Necessidade de padronização + grande diversidade de projetos (overhead de atividades) Fortemente baseados no CMM Estrutura semelhante Tailoring guidelines diferentes
Brasa pra Minha SardinhaForma sistemática de realizar a instanciação de um processo padrão da organização com base nas características de cada projeto com o objetivo de: Auxiliar o engenheiro de processos na
instanciação do processo padrão Facilitar reuso e melhoria de processos Permitir a formação de uma “família de
processos” originada a partir do processo padrão
Planejamento incial do projeto
Comparação de Projetose Reuso de Processos
Resultados do projeto
Processo instanciado
Características do projeto
Processo Preliminar
BD de Processos e Projetos
Modelo de Caracterização
de Projetos
Pconfig(baseado no processo
padrão)
PROJETO
ReferênciasBudlong, F.C., Szulewski, P.A., Tailoring Your Software Process for Software Project Plans – Part 1: Setting the Context and Making Tailoring Decisions, Crosstalk, STSC, Hill Air force Base, 1996.Budlong, F.C., Szulewski, P.A., Tailoring Your Software Process for Software Project Plans – Part 2:Documenting the Project’s Defined Software Process, Crosstalk, STSC, Hill Air force Base, 1996.Cockburn, A., Selecting a Project’s Methodology, IEEE Software, July/August 2000.Ebert, C., De Man, J., A Method and tool for Managing Process Diversity in an Industrial Setting, net.objectdays, 2000, disponível em www.netobjectdays.org/ pdf/00/papers/ooss/ebert.pdf, último acesso em abril de 2002.
ReferênciasFowler, M., Variations on a Theme of XP, MartinFowler.com, 2001.Ginsberg, M.P., Quinn, L.H., Process Tailoring and the Software Capability Maturity Model, CMU/SEI – Relatório Técnico, 1995.Haley, T., et al., Raytheon Electronic Systems Experience in Software Process Improvement, Software Engineering Institute, relatório técnico, 1995.Henderson-Sellers, B., Process Flexibility and Process Construction, Cobol Report, 2002, disponível em www.cobolreport/columnists/brian/01212002.asp, último acesso em abril de 2002.
ReferênciasMachado, L.F.C., Modelo para Definição de Processos de Software na Estação TABA, Tese de MSc., COPPE/UFRJ, Rio de Janeiro, RJ, Brasil, 2000.Schultz, D. et al., A Matrix Approach to Software Process Definitions, 25th Annual Software Engineering Workshop, Goddard Space Flight Center, 2000.SPAWAR Systems Center, A Description Of The Space And Naval Warfare Systems Center, relatório técnico, 2001.
Recommended