domingo, 11 de março de 2007

Por que o Windows Vista atrasou?

A empresa de desenvolvimento de software mais poderosa do mundo não conseguiu entregar o seu produto dentro do prazo previsto. O Windows Vista tinha entrega prevista para março de 2006, mas acabou sendo entregue 10 meses depois. Os principais motivos foram problemas com a sua arquitetura e gerência de software. Estes problemas vêm, há anos, sendo descritos na literatura da Engenharia de Software.

O código do Vista cresceu para o espantoso número de aproximadamente 50 milhões de linhas de código fonte e sua arquitetura tornou-se um caótico “spaghetti”. Uma arquitetura spaguetti é aquela na qual o código torna-se tão dependente de outras partes que o acompanhamento do fluxo de controle possui tantas idas e vindas de uma parte para a outra que fica praticamente impossível entendê-lo. Além disso, qualquer pequeno ajuste em uma pequena parte do sistema é imprevisível e pode desestabilizar o código, levando-o a um comportamento defeituoso.

Os problemas e causas do código spaguetti foram diagnosticados no final da década de 60 e durante os anos 70 diversas estratégias foram apontadas para evitá-lo. Dentre elas estão as técnicas de programação estruturada, o princípio da informação escondida e a modularização. Para solucionar o problema do código spaguetti, a Microsoft jogou fora o código trabalhado e voltar ao código de base do servidor do Windows 2000/XP que possuía bem menos defeitos. A equipe foi orientada a construir módulos a partir desta base.

Outro fator fundamental foi que a equipe cresceu para a enorme quantidade de 4000 programadores e 4000 testadores. Este número cresceu devido a um fator condenado há vários anos na engenharia de software no clássico livro “The Mythical Man-Month” de Frederick Brooks, engenheiro de software da IBM, responsável pelo sistema operacional OS-360, na segunda metade da década de 60 (Brooks, 1975). Em seu livro de 1975, Fred Brooks aponta que quando uma empresa está com prazos apertados, o aumento no número de pessoas na equipe de desenvolvimento, o que teoricamente poderia reduzir os prazos de entrega, não necessariamente causa o aumento de produtividade. Quando o número de pessoas em uma equipe aumenta, os canais de comunicação aumentam de forma exponencial e a gerência do projeto torna-se extremamente complexa. Quanto mais gente, mais atrasos.

A Microsoft tornou-se a mais poderosa indústria de software por uma boa estratégia política e de marketing – algumas das quais levou a empresa a responder a processos judiciais – e também pela produção de produtos de qualidade. Produtos como o Office são um sucesso pela forma como foram projetados e como o seu processo foi conduzido. A Microsoft conduziu este processo numa estratégia conhecido como “sincronizar-e-estabilizar”(Cusumano, 1997). Neste processo são definidos marcos a partir da divisão do produto em pequenas partes. As partes são entregues a times pequenos de jovens programadores, recém saídos das universidades, que trabalham no estilo “hacking” em salas que lembram alojamentos universitários, movidos a junk food (Coupland, 1995). No processo de sincronizar e estabilizar da Microsoft, builds (código compilado) são produzidos diariamente e em reuniões de sincronização são testados e corrigidos de forma a produzir versões estáveis. Esta estratégia, na década de 90, era bastante diferente daquelas conduzidas pela IBM nas quais milhares de engenheiros eram recrutados para o desenvolvimento de seus produtos de software. Na Microsoft, a equipe que desenvolveu o NT tinha algo em torno de 400 pessoas, na época a maior da empresa.

No entanto, mesmo com o seu bem sucedido processo de software de “sincronizar e estabilizar”, a Microsoft teve bastante dificuldade de realizar sincronização diária com uma equipe de 8000 pessoas e consertar defeitos em um código mal arquitetado com 50 milhões de linhas de código.

A versão beta do Windows Vista ficou pronta em agosto de 2005. Um ano e meio de foi reservado para testes e em janeiro de 2007 foi colocada à venda no mercado mundial. O projeto total levou 6 anos e consumiu 2 bilhões de dólares de investimento em programação e testes (Cusumano, 2006).

O que ocorreu com o desenvolvimento do Vista mostra que mesmo as poderosas empresas ainda cometem erros básicos de engenharia de software. O Windows 95 tinha cerca de 11 milhões de linhas de código e foi construído por um time de 200 pessoas. O Windows 98 tinha cerca de 15 milhões de código e o Windows XP cresceu para 25 milhões, construídos por uma equipe de 2000 pessoas. Terá a próxima versão do sistema operacional da Microsoft a astronômica quantidade de 100 milhões de linhas de código fonte? A empresa será capaz de desenhar uma arquitetura para este código e de gerenciar um time com 16 mil pessoas?

Referências

Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.

Brechner, Eric. "Journey of Enlightenment: The Evolution of Development at Microsoft" - ICSE’05 May 15–21, 2005, St. Louis, Missouri, USA.

Coupland, D. Microserfs. HarperCollins, 1995.
Cusumano, M & Selby, R. How Microsoft Builds Software - Communications of the ACM, jun1997, vol. 40, no. 6

Cusumano, M. ""What road ahead for Microsoft and Windows? Communications of the ACM archive, Volume 49 , Issue 7 (July 2006)

Programação Extrema (XP)

O método Programação eXtrema (XP, do inglês eXtreming Programming) é uma proposta de desenvolvimento ágil e iterativa. O método XP propõe um processo leve, centrado no desenvolvimento iterativo e com a entrega constante de pequenas partes da funcionalidade do software. As partes devem ser incrementadas e requerem a melhoria constante do código (re-trabalho).

A possibilidade de entrega rápida do código é um dos fatores de sucesso do XP. Isto no entanto, apenas pode ser feito com o envolvimento constante do cliente que se torna um membro ativo da equipe de desenvolvimento. Esta é uma das características importantes para o método funcionar bem. No entanto, nem sempre o cliente está disponível para a participação ativa.

Uma das características importantes do XP é que não existe um processo de design tradicional com a elaboração de modelos da arquitetura do software. O sistema é concebido a partir de uma metáfora e são descritos em estórias do usuário. Uma metáfora é a transposição de uma conceitualização do mundo real para o sistema a ser desenvolvido. Por exemplo, os programas de correio eletrônico foram construídos utilizando os conceitos de mensagem, caixa de entrada e caixa de saída. Cada mensagem possui remetente, destinatário, assunto e cópias carbono (cc). Este modelo conceitual reflete a forma como correspondências são enviadas nos escritórios e pelo sistema de correio dos Estados Unidos. A metáfora passa a ser fundamental para a elaboração das estórias de usuários.

O uso de cartões CRC (Classes, Responsabilidades e Colaborações) é recomendado de forma a permitir o design em equipe. Cartões CRC permitem a descrição dos conceitos identificados na metáfora na forma de classes. Responsabilidades são identificadas para cada classe. As colaborações determinam as interações entre classes. Os cartões permitem que o todo o time possa colaborar com o design.

Estórias de Usuários

A elaboração de estórias de usuário é uma das atividades fundamentais no XP. As estórias de usuário descrevem cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Elas deve devem ser escritas pelos próprios usuários. As estórias de usuário são semelhantes aos casos de uso da UML, mas não são a mesma coisa. A diferença é que elas não se limitam a descrever o processo de interação do usuário com o sistema.

No XP, as estórias de usuário ocupam o lugar dos longos documentos de requisitos nos métodos tradicionais. Cada estória deve ser um texto escrito com aproximadamente 3 sentenças.

As estórias de usuário são a base para a criação de estimativas de tempo que serão utilizadas nas reuniões de planejamento de entregas (releases). O plano de entregas direciona todo o planejamento do desenvolvimento e do plano de iterações para cada iteração individual. Cada estória deve levar de 2 a 3 semanas para ser implementada em uma iteração individual. Se levar mais do que isso, a estória precisa ser dividida em duas. Um número de 80 estórias aproximadamente é suficiente para definir um plano de entregas.

As estórias de usuário são também a base para a elaboração dos testes de aceitação. Um ou mais testes de aceitação automatizados deve ser criados para verificar se o programa implementa a estória corretamente.

O envolvimento do usuário, portanto, como autor das estórias, é fundamental para a elaboração do plano de entregas e dos testes de aceitação em cada iteração de desenvolvimento.

Práticas de programação

O processo de programação tem como características a programação em pares e a propriedade coletiva do código.

Na programação em pares, dois programadores ocupam um único computador. Embora, a princípio, isto possa ser visto como um desperdício de esforços, várias vantagens podem ser obtidas. Esta estratégia aumenta a qualidade do código e não altera o tempo de entrega, uma vez que haverá um ganho posterior nas etapas de retirada de erros (defeitos). Os dois programadores atuam de forma colaborativa. Enquanto o que está com o teclado e mouse está pensando diretamente na codificação (sintaxe, variáveis, fluxos de controle, etc.), o outro pode pensar estrategicamente em como o código irá interagir como outras partes do programa. Além disso, um atua com uma visão mais crítica corrigindo erros dos companheiros e pode pensar nas futuras mudanças e etapas posteriores. Isto permite que a tradicionalmente prática do codifica-e-conserta, criticada nas origens do desenvolvimento de software, possa ser realiza sem perda da qualidade do software.

A propriedade coletiva do código é outra característica fundamental do método XP, com a rotatividade do código entre os programadores e reuniões freqüentes para estabilizar o código. A propriedade coletiva encoraja o time todo a contribuir com novas idéias. Qualquer membro do time pode adicionar funcionalidade, corrigir erros ou re-fabricar o código. Não existe a figura do arquiteto chefe. Todos são responsáveis pelo código inteiro. Não existe alguém para aprovar as mudanças. Reuniões freqüentes devem ser definidas como parte do processo iterativo de programação. Estas reuniões devem ser curtas e são realizadas com todos de pé.

A prática do codifica-e-conserta também requer um processo constante de teste de unidade e integração. Para isto funcionar bem, os desenvolvedores devem trabalhar com uma ferramenta de testes automático e um repositório coletivo do código fonte. Os desenvolvedores devem criar testes de unidades e liberar o código apenas quando estiver 100% testado. Uma vez no repositório, qualquer um pode fazer alterações e adicionar novas funcionalidades. Uma ferramenta de controle de versões é fundamental.

O re-trabalho ou re-fabricação é uma atividade fundamental e necessária para o XP funcionar. Mesmo que o código esteja 100% testado, para viabilizar reuso, ele precisa ser revisto para remover redundâncias, retirar funcionalidades desnecessárias e modificar arquitetura obsoletas. O re-trabalho do código ao longo de todo o ciclo de vida reduz o tempo total de entrega do código e aumenta a qualidade do software produzido.

Regras e Práticas

Planejando
  • Estórias do usuário
  • Planejando liberações (releases) e pequenas liberações
  • Dividir projetos em iterações (ciclos)
  • Medindo velocidade do projeto
  • Dinâmica de pessoal
  • Reuniões diárias em pé

Projetando (designing)
  • Simplicidade (não adicione funcionalidades antes do tempo)
  • Metáfora
  • Cartões CRC (Classes, Responsabilidades e Colaboração)
  • Re-fabricar (refactor)

Codificando
  • O cliente deve estar sempre disponível.
  • Programação em pares.
  • Codificar de acordo com padrões acordados.
  • Codificar testes de unidade primeiro.
  • Integrar com freqüência.
  • O código é propriedade coletiva.
  • Não atrase.

Testando
  • Todo código deve ter os testes de unidade.
  • Cada unidade deve ser testada antes de liberada.
  • Quando um erro é encontrado, testes devem ser realizados.
  • Testes de aceitação devem ser freqüentes.

A programação extrema tem sido bem sucedida em projetos pequenos com times pequenos. Relatos mostram que para projetos grandes o método XP não é recomendado.

Para saber mais, consulte www.extremeprogramming.org

sexta-feira, 2 de março de 2007

O Modelo Espiral

O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele as principais características dos modelos vistos anteriormente, adaptando-os a necessidades específicas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.

Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda a evolução do desenvolvimento. Riscos são circunstâncias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonam a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão utilizados no produto final, etc. A identificação e o gerenciamento de riscos é hoje uma atividade importantíssima no desenvolvimento de software devido à imaturidade da área e à falta de conhecimento, técnicas e ferramentas adequadas.

O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro estágios.

  • No estágio 1 devem ser determinados objetivos, soluções alternativas e restrições.
  • No estágio 2, devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construídos protótipos ou realizar-se simulações do software.
  • O estágio 3 consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente.
  • O estágio 4 compreende a revisão das etapas anteriores e o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), Evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo.
Para saber mais:
  • Boehm, B. "A Spiral Model of Software Development and Enhancement" - IEEE Computer, vol.21, 5, May 1988, pp 61-72

O Modelo Transformação

Um programa é uma descrição formal, isto é, ele é descrito por uma linguagem de programação cuja sintaxe e semântica são definidos formalmente. Apenas desta forma é que temos a garantia de que o programa será sempre executado da mesma forma pelo computador.

O modelo Tranformação tem suas raízes na abordagem de métodos formais para o desenvolvimento de software. A idéia é que o desenvolvimento deve ser visto como uma seqüência de passos que gradualmente transforma uma especificação formal num programa. O passo inicial é transformar os requisitos informais numa especificação funcional formal. Esta descrição formal é então transformada numa outra descrição formal mais detalhada, e assim, sucessivamente, até chegar-se a programas que satisfaçam a especificação. Durante este processo de transformações sucessivas - chamado de otimização - as especificação formais produzidas podem ser executadas por um processador abstrato, permitindo uma verificação formal da sua validação antes mesmo que o programa venha a ser implementado. Antes de serem transformadas cada especificação formal deve ser verificada em relação às expectativas dos clientes e usuários.

As transformações devem ser realizadas pelo engenheiro de software. A natureza formal da transformação possibilita a aplicação de verificações matemáticas como prova, consistência e completude da especificação. As transformações podem ser realizadas de maneira automática por ferramentas que traduzem especificações formais mais abstratas em especificações mais detalhadas.

Este modelo prevê que o engenheiro de software deve ter a sua disposição uma biblioteca de componentes reutilizáveis que satisfaça especificações formais. Na otimização, à medida que as especificações de mais baixo nível vão sendo obtidas verifica-se quais componentes da biblioteca implementam parte desta especificação. Um ambiente automatizado de desenvolvimento (uma ferramenta CASE - Computer Aided Software Engineering) pode auxiliar este processo armazenando o histórico de decisões dos engenheiros de software.

Para se aprofundar, leia:

  • Helmut A. Partsch, Specification and transformation of programs: a formal approach to software development, Springer-Verlag New York, Inc. New York, NY, USA

O Modelo Cascata

O modelo cascata (waterfall) tornou-se conhecido na década de 70 e é referenciado na maioria dos livros de engenharia de software ou manuais de padrões de software. Nele as atividades do processo de desenvolvimento são estruturadas numa cascata onde a saída de uma é a entrada para a próxima. As suas principais atividades são:
  • estudo de viabilidade
  • análise e especificação de requisitos
  • design da arquitetura
  • Design detalhado
  • codificação e testes de unidades
  • integração e teste do sistema
  • entrega e instalação
  • manutenção
Existem muitas variantes deste modelo propostas por diferentes pesquisadores ou empresas de desenvolvimento e adaptadas a diferentes tipos de software. A característica comum é um fluxo linear e seqüencial de atividades semelhantes a descritas anteriormente.

Este modelo, quando proposto, introduziu importantes qualidades ao desenvolvimento. A primeira chama a atenção de que o processo de desenvolvimento deve ser conduzido de forma disciplinada, com atividades claramente definidas, determinada a partir de um planejamento e sujeitas a gerenciamento durante a realização. Outra qualidade define de maneira clara quais são estas atividades e quais os requisitos para desempenhá-las. Por fim, o modelo introduz a separação das atividades da definição e design da atividade de programação que era o centro das atenções no desenvolvimento de software.

O modelo Cascata também é criticado por ser linear, rígido e monolítico. Inspirados em modelos de outras atividades de engenharia, este modelo argumenta que cada atividade apenas deve ser iniciada quando a outra estiver terminada e verificada. Ele é considerado monolítico por não introduzir a participação de clientes e usuário durante as atividades do desenvolvimento, mas apenas o software ter sido implementado e entregue. Não existe como o cliente verificar antecipadamente qual o produto final para detectar eventuais problemas.

Características particulares do software (ser conceitual, por exemplo) e a falta de modelos teóricos, técnicas e ferramentas adequadas mostram que é necessário haver maior flexibilidade neste fluxo seqüencial, permitindo volta atrás para eventuais modificações. Veremos mais adiante modelos que propõem maior flexibilidade no fluxo de execução.

As métricas utilizadas nas estimativas de prazos e recursos humanos são ainda bastante imprecisas e quase sempre o planejamento de atividades precisa ser revisto. Normalmente, os prazos não são cumpridos, pois o planejamento, neste modelo, é feito unicamente nas etapas iniciais do desenvolvimento. A estrutura seqüencial e rígida também não permite que o planejamento seja refeito para corrigir falhas nas atividades de desenvolvimento.

Para saber mais, recomendo os seguintes artigos (em inglês):

O Modelo Evolutivo

O modelo evolutivo descreve um processo na qual o software deve ser desenvolvido de forma a evoluir a partir de protótipos iniciais. Para entender melhor este modelo é importante entender o que é prototipação (ou prototipagem).

Prototipação é uma abordagem baseada numa visão evolutiva do desenvolvimento de software, afetando o processo como um todo. Esta abordagem envolve a produção de versões iniciais - "protótipos" - de um sistema futuro com o qual pode-se realizar verificações e experimentações para se avaliar algumas de suas qualidades antes que o sistema venha realmente a ser construído.

Objetivos da Prototipação

Num projeto de software várias questões podem ser respondida com a construcão de protótipos. Nas situações típicas de desenvolvimento podemos distinguir entre diferentes objetivos na prototipação:
  • Exploratória - é quando o protótipo é usado para ajudar a esclarecer requisitos dos usuários com respeito ao sistema futuro. Uma prototipação também é exploratória quando se busca examinar uma variedade de opções de design de maneira a evitar a escolha de uma abordagem específica não adequada. Com esses objetivos os desenvolvedores adquirem informações sobre o domínio, os usuário e tarefas. Os usuários podem emitir informações e sugestões mais precisas, tornando-se parceiro das decisões que envolvem o desenvolvimento.
  • Experimental - é quando a prototipação foca aspectos técnicos do desenvolvimento, oferecendo aos desenvolvedores resultados experimentais para tomada de decisões de design e implementação. Um aspecto essencial é a viabilização de uma base de comunicação entre os usuários e desenvolvedores para soluções de problemas técnicos de viabilidade e usabilidade, dentre outros. As principais vantagens para os desenvolvedores são a verificação e validação das decisões tomadas e soluções apresentadas.
  • Evolutiva - A prototipação pode ser aplicada de maneira bastante proveitosa num processo de reengenharia em organizações, para avaliar o impacto que a introdução de novas tecnologias pode trazer. Nesse caso o protótipo não é visto apenas como uma ferramenta em projetos individuais, mas como parte de um processo contínuo de evolução dos processos organizacionais. Os desenvolvedores não são mais os protagonistas da prototipação, mas consultores que trabalham em cooperação com os usuários no processo de reengenharia.

Tipos de Protótipos

O relacionamento entre um protótipo e as atividades do processo de desenvolvimento - início do projeto e análise de requisitos, design da interface e da aplicação, e implementação - permite a identificação de quatro tipos de protótipos:
  • Protótipo de Apresentação - oferece suporte ao início do projeto e é usado para convencer o cliente de que o futuro sistema é viável e que a interface do usuário se adequa aos requisitos. Na maioria dos casos é usado para mostrar visão que o usuário têm do sistema e revelar aspectos importantes da interface.
  • Protótipo Autêntico - é um sistema de software provisório e funcional, geralmente projetado para ilustrar aspectos específicos da interface de usuários ou parte da funcionalidade, ajudando na compreensão dos problemas envolvidos.
  • Protótipo Funcional -- é derivado do modelo do domínio do problema ou da especificação do software e serve para ajudar à equipe de desenvolvimento compreender questões relacionadas com a construção do sistema. Esse protótipo não interessa aos usuários.
  • Sistema Piloto - é usado não apenas com propósitos ilustrativos, mas como um núcleo básico operacional do sistema. Esse sistema deve ser instalado no ambiente de aplicação e experimentado com os usuários.
O fluxo de atividades do modelo evolutivo caracteriza-se por ser cíclico ou iterativo. Ele começa com o design e desenvolvimento de um protótipo inicial, que deve ser mostrado aos usuários e avaliado. Durante a avaliação novos requisitos são definidos e alterações e incrementos ao protótipo inicial devem ser feitas. Este ciclo deve ser repetido em direção ao produto final.

A grande vantagem deste modelo está em permitir a verificação antecipada do produto final por engenheiros, clientes e usuários, permitindo a correção dos problemas detectados.

A extrema flexibilidade deste modelo e a sua falta de rigor leva a software que embora satisfaça aos requisitos dos usuários têm deficiências de desempenho, portabilidade, manutenção e outras qualidades internas.

Embora a prototipação tenha enormes vantagens e deva ser incentivada, basear o desenvolvimento no incremento de protótipos pode levar a software mal documentados e com arquiteturas mal definidas. Como os requisitos estão sempre sendo revistos a cada ciclo de desenvolvimento, torna-se praticamente impossível estimar custos e prazos e planejar as atividades de desenvolvimento.

Leituras recomendadas:

  1. Alan M. Davis: Operational Prototyping: A new Development Approach. IEEE Software, September 1992. Page 71.
  2. John Crinnion: Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York, 1991. Page 17.
  3. S. P. Overmyer: Revolutionary vs. Evolutionary Rapid Prototyping: Balancing Software Productivity and HCI Design Concerns. Center of Excellence in Command, Control, Communications and Intelligence (C3I), George Mason University, 4400 University Drive, Fairfax, Virginia.


Processo de Software

Vimos que a engenharia de software requer que as atividades para desenvolver o software sejam feitas de forma planejada, gerenciada, com pessoal capacitado, custos e prazos estimados e utilizando teorias, métodos, técnicas e ferramentas adequadas.

Elaborar um processo de software significa determinar de forma precisa e detalhada quem faz o que, quando e como. Um processo pode ser visto como uma instância de um modelo de processo ou método com suas técnicas e ferramentas associadas. O processo é definido durante a etapa de planejamento, no qual as atividades que o compõem foram alocadas aos membros da equipe de desenvolvimento, com prazos definidos e métricas para se avaliar como elas estão sendo realizadas.

Enquanto um método é algo teórico, o processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos. O processo é o resultado do planejamento e precisa ser gerenciado no decorrer de sua execução.

Não é objetivo deste texto a elaboração de processos de desenvolvimento. Apenas podemos fazê-lo após estudarmos técnicas de planejamento e gerenciamento. Neste capítulo vamos nos limitar a estudar alguns modelos de processo que nos indique como as diversas etapas e atividades do desenvolvimento podem ser estruturadas.

Conceitos importantes

  • Um processo é organizado em atividades.
  • Atividades são de responsabilidade de um membro da equipe (trabalhador).
  • Atividades devem gerar um artefato de saída, que possa ser verificado, e podem requisitar um artefato de entrada.
  • Um artefato é um modelo, documento ou código produzido por uma atividade.
  • Uma entrega (liberação) é um artefato entregue ao cliente
  • Um processo deve estabelecer uma série de marcos.
  • Um marco é um ponto final de uma atividade de processo.

Modelos de Processo

Um modelo para um processo de desenvolvimento é uma proposta teórica que junto com o planejamento deve determinar quais atividades devem ser realizadas, quando, como e por quem. Nesta seção vamos apresentar alguns dos mais conhecidos modelos do processo de desenvolvimento. Eles são o modelo Cascata, o modelo Evolutivo, o modelo Incremental, o modelo Espiral, o modelo Transformação, o modelo XP (eXtreme Programming), e RUP (Processo Unificado da Rational).

A escolha de um destes modelos envolve diversos fatores. Um deles é o tipo de software - se é um software de banco de dados, um software de tempo-real, um software embutido, um sistema especialista. Outro fator importante é se a equipe de desenvolvimento é uma empresa de desenvolvimento (software house), uma fábrica de software (desenvolvimento em linha de produção) ou se é a equipe de engenheiros da própria organização que utilizará o produto. A maneira como o produto será vendido e instalado é um outro fator importante - se o software é para ser vendido para um público amplo (software genérico) ou se será instalado em uma única empresa, sob encomenda.

Um conjunto de modelos de processo ou métodos, as técnicas de desenvolvimento é uma metodologia de desenvolvimento.

Para saber mais, recomendo os artigos:

  1. Fuggetta, A. Software process: a roadmap, in Finkelstein, A. (ed.) The Future of Software Engineering, ACM Press, 2002
  2. Sommervile, I.Software Process Models, ACM Computing Surveys, Vol.28, no.1, March 1996.
Veja os slides em PDF.