O karma dos insucessos no desenvolvimento de projetos hoje é colocar a culpa dos problemas na má obtenção e péssima documentação dos requisitos de software. Sabemos que os requisitos de negócios de um projeto de software são como água, ou seja, quanto mais congelados serão mais fáceis de trabalhar. Porém “crucificar” os requisitos está muito longe de ser uma solução completa e definitiva para os desafios de um projeto.

A ausência de metodologia é o tema que ocupa o segundo lugar nas pesquisas sobre por que seu projeto falhou. Obviamente estas são as opiniões do corpo técnico do projeto e ocultam uma realidade que possivelmente eles desconheçam: O ciclo de vida de desenvolvimento utilizado foi adequado ao projeto?

Segundo Alistair Cockburn, famoso autor de vários livros sobre metodologias ágeis, “existe uma apropriada – mas diferente – maneira de trabalhar para cada projeto e cada equipe de projeto”. Na minha leitura, costurar um ciclo de vida adequado para as características do seu projeto e o perfil de sua equipe de projeto é aproveitar o que tem de melhor nas metodologias e técnicas de gerência de requisitos sem se preocupar com as imposições burocráticas.

A necessidade de quebrar paradigmas

Como apresentado, os paradigmas mais famosos que costumam justificar fracassos em equipes de projetos são: Ausência de documentação de requisitos de negócios ou má qualidade na obtenção destes, e ausência de metodologia formal durante a execução do projeto.

Sem ter como objetivo quebrar estes paradigmas submetemos a sua reflexão outros importantes pontos que “justificam” os fracassos verificados nos últimos dez anos nos históricos dos projetos de software.

• Comunicação: problemas de;
• Códigos fontes “macarrônicos”: dificuldade de manutenção, de evolução e de absorção por novos recursos;
• Dinamismo dos negócios e necessidade de respostas rápidas;
• Introdução de novas tecnologias: interfaces ricas, “objetos” e serviços.

Conforme comentado, os paradigmas iniciais permanecem, contudo foram “enriquecidos” com alguns pontos. Então podemos concluir que para participar de projetos de software precisamos de uma nova estrutura de trabalho paradigmática? Esta pergunta você mesmo deve responder ao final deste artigo.

Há uma percepção de que os problemas citados são monolíticos, ou seja, são indivisíveis. Particularmente considero esta afirmativa perigosa baseada no fato que poderíamos tratar cada um dos assuntos separadamente. Por exemplo: a introdução de novas tecnologias é assunto para arquitetos, o dinamismo dos negócios é assunto para analistas de negócios e etc.

Definindo SDLC

A metamorfose do pensamento que expomos até o momento é que desejamos tratar todos os assuntos como uma só visão, como um ciclo. Vamos fazer uma analogia com uma borboleta. Podemos tratar separadamente cada uma das fases: casulo, lagarta e borboleta. Porém quando estudamos o todo, mesmo que separados em fases, chamamos de ciclo de vida de uma borboleta.

Da mesma forma, separando o desenvolvimento de um projeto em fases distintas, porém complementares, teremos um ambiente de estudo mais adequado para tratar os problemas dos projetos. Podemos chamar isso de ciclo de vida de desenvolvimento (ou em inglês, SDLC – Software Development Life Cycle).

SDLC se propõe a formalizar dentro de uma equipe de projetos fases de construção, processos e normas que facilitarão a previsibilidade e, principalmente, a produtividade que poderão ser medidas nos resultados desta equipe.

Alguns autores gostam de denominar SDLC como um workflow de construção de software. No wikipedia.org definiram SDLC como um processo de atividades ordenadas visando concluir um produto baseado em software. É muito comum encontrar referências a SDLC como uma espécie de linha fabril de desenvolvimento, como uma linha de produção de uma indústria.

A base do pensamento

Quando pensamos em um projeto, podemos segmentar a idéia da forma representada na figura 1. Vamos “batizar” este desenho como “contexto do desenvolvimento de um projeto”.

Figura 1: Contexto do desenvolvimento de um projeto.

Este contexto, aparentemente simples para estudantes da ciência da computação, pode ser considerado bastante avançado quando buscamos por evidências práticas nas empresas que possuem equipes de desenvolvimento de software.

Os resultados de nossos estudos no “campo” verificamos que, na grande maioria dos casos, o que se pratica é uma espécie de trabalho “oportunístico”, ou seja, quando os problemas ocorrem todos se mobilizam em resolvê-lo. Este método de trabalhar, sem a menor sombra de dúvida, é pouco produtivo, é reativo e proporciona aborrecimentos marcantes em usuários solicitantes e contratantes de serviços de software.

A ausência de um modelo organizacional de trabalho proporciona dúvidas clássicas como:

• O que eu tenho que fazer e quando devo fazer?
• Quem faz o quê neste projeto?
• O quê devemos fazer na semana que vem?

Se juntarmos os paradigmas comentados, os problemas descritos após os paradigmas e as dúvidas clássicas de agora, voltaremos ao ponto que todos podem ser tratados separadamente, contudo deveriam ser vistos como uma seqüência, ou seja, uma coisa que deve ser tratada uma após a outra.

É percebendo desta forma que compreendemos a base do “pensamento” SDLC: Propor através de fases distintas, porém complementares, modelos de trabalho em equipe para os desafios existentes em um projeto de software.

Cuidado com a natural confusão entre SDLC e metodologia. Apesar da pouca de documentação e de poucos autores que expliquem as diferenças e semelhanças entre as mesmas, elas são matérias desiguais. Na minha leitura, metodologia é mais completo que um SDLC, pois abrange também artefatos, papéis e pontos de checagem de estágio do projeto.

As fases do SDLC

Observando novamente a figura 1, podemos afirmar que cada uma das cores e seus respectivos “atores” poderiam ser uma fase distinta do projeto, contudo complementar.

Peço ao leitor para abandonar neste momento qualquer aprendizado anterior de modelo de processos proposto por alguma metodologia de engenharia de software e concentrar-se apenas em entender a natureza da questão. A questão é: precisamos de quatro fases para um projeto de software.

Definimos uma fase como um conjunto de atividades afins necessárias e complementares (geralmente seqüenciais) para tratar uma determinada necessidade do conjunto de necessidades presentes na construção de um projeto de software.

Estas fases são:

• Fase de início de projeto;
• Fase de planejamento de projeto;
• Fase de execução de projeto;
• Fase de fechamento de projeto.

Figura 2: Fases presentes no ciclo de vida de desenvolvimento.

Exemplificando de forma resumida e se esforçando para adicionar mais informação que a própria informação óbvia de cada fase, descrevemos abaixo alguns artefatos ou atividades destas etapas necessárias ao desenvolvimento de um projeto de software.

• Fase de início de projeto: Documento de visão, definição da equipe do projeto, escopo macro do projeto;
• Fase de planejamento do projeto: Detalhamento do escopo, plano de construção e arquitetura, especificações de negócios;

• Fase de execução do projeto: Implementação dos códigos fontes, testes de unidade, rotinas de compilação;
• Fase de fechamento do projeto: Plano de implantação e treinamento, plano de manutenção, relatório de fechamento (post mortem report).

De forma mais fácil ou mais complexa de identificar, todas estas fases estão presentes em todas as metodologias existentes hoje e também em todos os ciclos conhecidos de processos. Ao definir qual metodologia usar para uma determinada equipe, meu conselho pessoal é que seja estudado como esta metodologia provê suporte as fases necessárias de um SDLC, entre diversos outros fatores fundamentais para justificar sua escolha.

O Ciclo de Processos

As metodologias definem SDLC de diferentes formas para um projeto de software. A forma mais famosa e comumente utilizada é denominada “processos em cascata” ou “waterfall process”. No SDLC propriamente como assunto de estudo, estas formas não são definidas e fica a encargo da metodologia adotada especificar como será o ciclo de processos.

Os mais populares ciclos existentes são:

• Cascata: como já comentado é o mais famoso e ricamente defendido por metodologias mais tradicionais. Particularmente eu considero-o burocrático, pesado e lento, pois define que uma fase se inicia após o termino completo da anterior e não trabalha com o feedback rápido do usuário;
• Espiral: ciclo que se tornou muito popular com a metodologia eXtreme Programming apesar de já ter sido documentada anteriormente pela metodologia MSF – Microsoft Solutions Framework. Implementa todas as fases propostas no ciclo em cascata, contudo dividindo em ciclos curtos para obter o feedback do usuário o quanto antes. O autor Sam Guckenheimer classificou este processo como “Value-up Paradigms” em seu ótimo livro entitulado Software Engineering with Microsoft Visual Studio Team System;

• Iterativo e incremental: ciclo muito novo proposto pela metodologia MSF for Agile Software Development (também conhecida como MSF versão 4.0). É uma proposta evolucionária ao ciclo espiral ajustando pontos que aumentam o valor do produto e implementam fortes controles de “issue tracking”. Segundo Clementino Mendonça, MSF Practitioner, palestrante e autor, quando você obtêm requisitos, planeja, implementa e testa seu software de maneira iterativa em transição, o resultado é o incremento contínuo do valor do produto;
• Prototipação evolucionária: ciclo no qual o sistema é desenvolvido incrementalmente conforme o protótipo e o feedback do usuário sobre as interfaces visuais. Basicamente, iniciamos a implementar suas funcionalidades conforme as interfaces visuais são homologadas. Na minha leitura, esta proposta serviu como base para as idéias de metodologias ágeis. Tom Gilb no livro Principles of Software Management Engineering lançado em 1988 foi um dos pioneiros na defesa deste tipo de ciclo de vida (alguns autores sugerem que Tom Gilb foi o criador desta proposta). Steve McConnell elogia veementemente este ciclo de vida no seu livro intitulado Rapid Development.

Recentemente foi introduzido no mercado pela Microsoft um produto de automação de SDLC. Este produto chama-se VSTS – Visual Studio Team System. Maiores informações sobre VSTS podem ser encontradas em artigos específicos neste portal (http://www.linhadecodigo.com.br).

Padrões

O processo de desenvolvimento de software tem sido alvo da tentativa de padronização há alguns anos. Estes padrões visam a certificação de empresas (seus processos de construção de software) como possuidoras de um processo de desenvolvimento homologado, o que deveria garantir certo grau de confiança aos seus contratantes.

Alguns dos padrões existentes atualmente são:

• CMMI (anteriormente CMM)
• SPICE
• ISO 12207
• MPS/Br

O crescente número de empresas que desenvolvem software e naturalmente o incremento da concorrência entre estas empresas promovem a “indústria” dos padrões como uma “desesperada” tentativa de criar parâmetros iguais de concorrência entre fornecedores de software.

Arrisco-me a afirmar que SDLC como matéria de estudo é uma derivação do padrão ISO 12207. O padrão ISO 12207 define métodos para selecionar, implementar e monitorar ciclo de vida para projetos.

O Capability Maturity Model (CMM) é o mais popular entre os padrões desejados pelas empresas brasileiras. Medido a partir do trabalho de avaliação de organizações independentes, o CMM define áreas chaves de processos que devem ser atendidas no desenvolvimento de um projeto. Recentemente foi lançada uma versão evolucionária deste padrão denominada CMMI (I = Integration).

Tem o famoso ISO 9000 também, contudo este padrão somente preocupa-se em formalizar através de documentos os processos organizacionais de uma empresa.

Finalizando este tópico, quero comentar sobre o padrão ISO 15504, também conhecido como “Software Process Improvement Capability Determination” – SPICE. Este padrão está tornando-se popular por ser um “framework” para avaliação do processo de software.

Ao formalizar um SDLC para sua empresa, inevitavelmente sua organização estará apta a atender a maioria das exigências dos padrões citados anteriormente. Na minha forma de pensar, investir na implementação e formalização de um SDLC é um mecanismo acelerador (e certamente “barateador”) para as empresas que almejam obter a certificação de seus processos de desenvolvimento de software.

Considerações finais

Todas as organizações possuem projetos. Projetos precisam de recursos (pessoas e investimentos). Cada organização tem uma cultura de como fazer os projetos e uma quantidade de recursos que pode aplicar. Para equilibrar corretamente as expectativas de resultados com os recursos disponíveis, as empresas devem formalizar um ciclo de vida de desenvolvimento dos projetos. Quanto mais formalizado e maduro o SDLC de sua empresa, mais previsíveis e fáceis de medir serão os resultados.

Há uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a produtividade e qualidade dos projetos de software. Alguns processos tentam sintetizar e formalizar a tarefa aparentemente incontrolável de escrever um software. Outros aplicam técnicas de gerenciamento de projeto na escrita de software. Trabalhar na formalização de um SDLC adequado para seu projeto e para o perfil de sua equipe é um atalho prático e “funcional” nesta busca, principalmente por ter um enfoque direto e não burocrático para quebrar o processo de construção de um software em fases menores e melhor gerenciáveis.

Para Saber Mais

Wikipedia (http://www.wikipedia.org/SDLC)

The Project Management Life Cycle by Jason Westland

Webcasts de ciclo de vida de desenvolvimento disponíveis no site MSDN (http://www.msdn.com.br)

Treinamento de SDLC da FCamara (http://www.fcamara.com.br)

Referências

Agile Software Development: The Cooperative Game by Alistair Cockburn;

Visual Studio Team System Rocks by Fábio Câmara, Clementino Mendonça e outros;

Extreme Programming by Vinícius Manhães Teles;

Software Engineering with Microsoft Visual Studio Team System by Sam Guckenheimer;

Rapid Development by Steve McConnell;

Code Complete, 2nd Edition by Steve McConnell.