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.