Projet o Preliminar

SE a arquitetura do sistema não existe ainda ENTÃO

Preparar diagramas de arquitetura alto nível

Realizar para todos os tipos de projeto PARA todo novo software

customizado FAÇA

Projetar funções ou especificações de alto nível

Sempre realizar essa atividade Conduzir inspeção das funções

ou especificações de alto nível

X X X X O O O O

SE o software é parte de um sistema maior ENTÃO

Conduzir uma revisão do projeto preliminar

I F O O

Conduzir revisão conjunta das especificações do software e do projeto preliminar

I F O O

SENÃO

Conduzir uma revisão do projeto preliminar

I F

Conduzir, em conjunto, revisão do projeto preliminar e revisão crítica do projeto

I F O O O O

FIM SE

LEGENDA: X = realizar atividade

O = atividade opcional mas recomendada F = realizar revisão formalmente I = realizar revisão informalmente

A abordagem baseada em matriz simplificou o desenvolvimento, comparação, apresentação e revisão dos processos. Além disso, abriu caminho para uma futura automatização que possibilite, a partir da seleção do tipo de processo e de valores para os critérios de adaptação, gerar a lista de atividades para o projeto.

2.3.3 Raytheon

A Raytheon9 é uma companhia de alta tecnologia que atua nos ramos de eletrônica, engenharia e aviação, entre outros. Desde 1988, a Raytheon tem acompanhado o trabalho do Software Engineering Institute (SEI) na área de processos de software. Um dos motivos para esse interesse foi a percepção de uma tendência que indicava que os clientes da Raytheon estavam cada vez mais propensos a utilizar o modelo de maturidade do SEI, o CMM, como critério de seleção de fornecedores.

A Raytheon iniciou então um projeto de melhoria do seu processo de software baseado na institucionalização do conhecimento sobre métodos e tecnologias de engenharia de software [14]. O projeto se mostrou bem sucedido, trazendo ganhos em termos de aumento de produtividade, qualidade e previsibilidade do processo.

Nas áreas de definição, melhoria e adaptação de processos, foi desenvolvido um modelo de processos (Figura 8), que representa a estratégia adotada pela empresa.

O projeto padrão da organização é definido por uma política que descreve um conjunto de práticas comuns de engenharia de software. Esse conjunto de práticas é criado através da seleção de melhores práticas utilizadas nos projetos da companhia. As práticas são compostas por procedimentos, que descrevem aspectos críticos do desenvolvimento, ferramentas e treinamento necessários para incrementar a produtividade dos desenvolvedores. Um banco de dados de processos armazena métricas e baselines, que podem ser usadas para comparações entre projetos ou dentro do mesmo projeto, e produtos relacionados a projetos, como, por exemplo, lições aprendidas, que podem ser utilizados em desenvolvimentos futuros.

9

Figura 2-8: Estrutura para processos de software da Raytheon (traduzido de [14])

Cada projeto utiliza uma versão do processo padrão adaptado para suas necessidades específicas (Figura 2-8, passo a). Além disso, cada projeto possui seu próprio plano de desenvolvimento, que é um documento que faz a ligação entre o projeto e o processo. O contrato, o plano de trabalho e os requisitos do sistema funcionam como restrições ao plano de desenvolvimento.

No decorrer da aplicação do processo ao projeto (Figura 2-8, passo b), ocorrem dois tipos de feedback (Figura 2-8, passo c): no nível de projeto, o plano de desenvolvimento é alterado para refletir lições aprendidas em estágios anteriores do desenvolvimento; no nível organizacional, as lições aprendidas servirão de insumo às atividades de melhoria de processo e podem, inclusive, gerar soluções genéricas que serão adicionadas ao processo padrão da organização.

Processo de Software Padrão Métricas

Ferramentas Métodos Treinamento Práticas de Engenharia de Software Políticas de Engenharia de Software

Influências • Tecnologia • Mercado • Negócio • Clientes Atividades de Melhoria do Processo Equipes ad hoc atualizam o processo constantemente Solução incluída no Processo Padrão Processo necessário Contrato Plano de Trabalho Requisitos Plano de Desenvolv. de Software do Projeto Desenvolvimento de Software Processo Aplicado Atividades de Melhoria do Processo Um Projeto Feedback

2.3.4 SPAWAR

O SPAWAR (Space and Naval Warfare)10, em San Diego, Estados Unidos, através de seu Centro de Sistemas, tem desenvolvido um esforço no sentido de melhorar seu processo de software [17]. O primeiro passo para realizar essa melhoria foi a criação de um repositório de informações de processos. Esse repositório tem como objetivos:

• Difundir melhores práticas para toda a organização.

• Fornecer informações para estimativas de projeto e melhoria do processo de software.

• Servir como fonte de informações pa ra o desenvolvimento de processos para projetos específicos.

• Adequar a organização ao nível 3 do CMM. As informações contidas no repositório compreendem:

• Uma descrição dos ciclos de vida de software utilizados pela organização.

• Uma descrição do processo padrão da organização, incluindo sua arquitetura e seus elementos.

• Diretrizes para a adaptação do processo padrão.

• Uma descrição de bancos de dados e métricas de projetos e processos.

• Uma descrição de uma biblioteca de documentos.

Os elementos que compõem o repositório são a base para o desenvolvimento de processos para projetos específicos a partir do processo padrão. Entretanto, alguns fatores que impactam o projeto devem ser considerados no momento da adaptação:

• Ambiente de programação.

• Padrões adotados ou impostos.

• Restrições financeiras.

• Obrigações contratuais.

• Cronograma.

• Políticas de desenvolvimento impostas pelo contratante.

• Tecnologia a ser utilizada.

• Nível de experiência dos desenvolvedores com o processo.

• Quantidade de mudanças que o projeto pode sofrer.

10

Considerados esses fatores, pode ser realizado o processo de adaptação, que é composto de três passos. Cada passo contém atividades, que indicam como realizá-lo, critérios de entrada, saídas e critérios de saída.