Adaptação de Processos na Indústria de Software

As empresas cujas experiências são relatadas nesta Seção foram selecionadas tendo como critério a existência e disponibilidade de documentação sobre a estratégia de adaptação adotada, além de circunstâncias e métodos interessantes que pudessem enriquecer o relato das experiências.

2.3.1 Alcatel

No ano de 1998, a Alcatel7, após ter atingido o Nível 2 do CMM, iniciou um trabalho de reengenharia de seus processos de software [13]. A principal razão para essa reengenharia foi a necessidade de gerenciar a grande diversidade de processos de software da empresa.

A produção de software era feita em mais de 20 centros de desenvolvimento, por mais de 5000 pessoas. A base instalada de software se espalhava por mais de 60 países. As melhorias no processo de desenvolvimento eram frutos de iniciativas isoladas, que não chegavam a beneficiar a organização como um todo.

Assim, os objetivos da reengenharia de processos de software realizada eram:

• Facilitar a comunicação e interação das equipes virtuais através de um sistema de workflow integrado.

• Reduzir a sobrecarga causada pela replicação de atividades de definição e melhoria de processos.

• Estimular o aprendizado organizacional e evitar o isolamento de melhores práticas.

• Integrar workflows específicos de cada produto através de interfaces padronizadas e de uma gerência de configuração uniforme para elementos do processo e artefatos.

• Melhorar a eficiência do desenvolvimento através do uso de processos

7

padrões e das tecnologias e ferramentas que melhor suportem esses processos.

Devido à grande variedade de projetos de software existente na Alcatel, não era suficiente apenas definir processos padrões de desenvolvimento. Era necessário também estabelecer formas de adaptar esses processos para adequá-los às necessidades de cada projeto.

O primeiro passo para definir a política de adaptação de processos foi identificar quais elementos ou partes de processos deveriam variar de projeto para projeto e quais deveriam permanecer imutáveis. Em seguida foram identificados os seguintes critérios para a adoção de um processo específico:

• Tamanho do projeto, em termos de esforço (3 níveis).

• Tipo de produto (produto genérico, customização ou manutenção de produto, protótipo).

• Critérios específicos do produto (plataforma de desenvolvimento, linguagem de programação, parâmetros industriais).

Para garantir que os processos utilizados em todos os centros de desenvolvimento da Alcatel estivessem de acordo com o processo organizacional, foi desenvolvida uma ferramenta de apoio à adaptação. O gerente do projeto define valores para os critérios que caracterizam o projeto e a ferramenta gera um modelo do processo adaptado com links para os elementos do processo (descrição de papéis e atividades, modelos, ferramentas etc).

Os principais benefícios alcançados com a reengenharia dos processos de software na Alcatel foram:

• Menor redundância e maior facilidade de manutenção dos documentos de processo.

• Os processos tornaram-se mais acessíveis e compreensíveis para os desenvolvedores.

• Melhor coordenação entre as mudanças nos processos e as mudanças das ferramentas de apoio.

• Maior facilidade de treinamento especializado, de acordo com os papéis estabelecidos nos processos.

• Maior facilidade de mover um desenvolvedor de um projeto para outro devido ao alinhamento entre os processos.

2.3.2 Goddard Space Flight Center

Em 1999 o Software Engineering Laboratory (SEL) iniciou um trabalho para o Information Systems Center (ISC) do Goddard Space Flight Center (GSFC)8 [40]. Esse trabalho incluía, entre outras coisas, auxiliar a equipe de desenvolvimento de software do GFSC na seleção e adaptação de processos de software. Um dos objetivos era que os processos fossem compatíveis com os padrões ISO 9001 e CMM.

Os processos forma classificados em Novo Desenvolvimento, Manutenção, Alto Reuso e Prototipação.

Além desses tipos de projeto, foram definidos três critérios de adaptação:

• Tamanho da equipe de desenvolvimento: pequena, média, grande.

• Criticidade do sistema: crítico, não-crítico.

• Cronograma: folgado, normal, agressivo.

Os processos definidos são constituídos de Atividades, agrupadas em Grupos de Atividades. Cada Atividade emprega um conjunto de Técnicas (Figura 2-6).

Figura 2-6: Elementos do framework de processos do GSFC (traduzido de [40])

Para especificar em que condições certas atividades deveriam ou não ser realizadas, tentou-se utilizar uma linguagem estruturada, uma espécie de pseudocódigo. O problema é que cada especificação em pseudocódigo correspondia a somente uma 8 Site do GSFC: www.gfsc.nasa.gov. Atividade Processo de Software Atividades de

Requisitos Implementação Atividades de Atividades n Grupo de

Definição de

Requisitos Análise de Requisitos

Técnica 1

Técnica 2

Técnica 1

Revisar Código Atividade n

Técnica n

Tipo de Processo

Grupo de

instância do processo. Dado que existiam quatro tipos de processo e três critérios de adaptação, com dois desses critérios podendo assumir três valores distintos e o terceiro podendo assumir dois valores distintos, seriam necessárias setenta e duas especificações diferentes (4x3x3x2) para cobrir todas as instâncias possíveis do processo. Esse grande número de especificações tornava difícil o desenvolvimento e análise dos processos.

Para resolver esse problema, foi adotada uma abordagem baseada em uma matriz de representação de processos (Figura 2-7). A coluna esquerda da matriz identifica o pseudocódigo e os passos a serem seguidos. As outras colunas representam as várias combinações de critérios de adaptação. Cada atividade é identificada como obrigatória ou opcional e as revisões são identificadas como formais ou informais.

Software Crítico Software Não Crítico Cronograma Normal Cronograma Agressivo Cronograma Normal Cronograma Agressivo X.0 Grupo de Atividades X.X Atividades Principais Atividades Equipe pequena Equipe grande Equipe pequena Equipe grande Equipe pequena Equipe grande Equipe pequena Equipe grande 2.0 Projeto 2.1 Prototipação

SE existirem riscos técnicos significativos ENTÃO

Fazer prototipação para reduzir riscos

Realizar para todos os tipos de projetos Documentar o esforço de

prototipação

X X X X X X O X