Engenharia de Software

A ES é toda uma área do conhecimento da computação. A intenção é conseguir especificar, desenvolver e manter software com a melhor relação de custo e qualidade possível com todas as técnicas que temos disponíveis, se focando em aspectos práticos. Por isso ela engloba todas estas partes do software:
- Requisitos;
- Design;
- Implementação;
- Testes;
- Manutenção;
- Gerência de configuração;
- Gerência de engenharia;
- Processos de engenharia;
- Ferramentas e métodos de engenharia;
- Qualidade;

Para nos ajudar a entender tudo isso, vamos começar com a definição de ciclo de vida do produto (software). A idéia destes modelos é detalhar como deve ser o passo a passo do desenvolvimento do software até que se tenha o produto final.

No processo em Cascata temos um processo linear, na base de muitos processos de ciclo de vida ainda hoje. Completa-se a engenharia de requisitos para só depois fazer o design do software. E só depois deste é que se inicia a implementação e os testes. Depois se testa o sistema e finalmente se entra na etapa de manutenção do software. Costuma funcionar melhor para equipes tecnicamente mais fracas e minimiza o tempo de planejamento. Porém é mais inflexível e só produz um software realmente no final do processo.

O modelo em espiral tenta dar maior importância a duas partes deste ciclo: a análise de risco e a prototipagem. Procura-se definir e especificar partes menores, produzindo protótipos e cada iteração pode voltar a qualquer etapa (mais comum de se voltar ao desenvolvimento ou especificação) e gerar outro protótipo até que se chegue ao final do produto. E este acaba sendo um modelo complexo de se planejar e utilizar, mas pode-se diminuir muito o risco dos projetos. Uma variação parecida é a Prototipagem Evolucionária, que também faz ciclos de protótipos, mas não chega a fazer um planejamento geral porque se planeja apenas versões curtas, o que é muito útil quando os requisitos ainda não estão bem definidos, mas tem a desvantagem de que é impossível de prever quanto tempo ou quantas iterações serão necessárias até o final do projeto.

Entre outros modelos utilizados estão: Codificação e Correção, Staged Delivery, Evolutionary Delivery, Design-to-Schedule, Design-to-Tools e Off-the-Shelf.

Quanto as metodologias de desenvolvimento, também temos diversas delas para escolher. O RUP (Rational Unified Process) foi criado por uma empresa adquirida pela IBM e virou IRUP (IBM RUP). Eles fornecem técnicas de desenvolvimento de software visando o aumento de produtividade. Ele faz uso da Orientação a Objetos e da linguagem UML para definir e ilustrar os seus processos. Ele divide o processo em quatro fases essenciais:
Concepção: ênfase no escopo do sistema;
Elaboração: ênfase na arquitetura;
Construção: ênfase no desenvolvimento;
Transição: ênfase na implantação.
É um modelo considerado pesado, mas que é muito útil com um grande número de pessoas na equipe, no caso de projetos muito grandes. Mas é suficientemente simples para que possamos trabalhar com ele em processos menores.

De qualquer forma, muitas metodologias surgiram exatamente por esta razão, com o nome de métodos ágeis. Eles procuravam uma forma de se conseguir um resultado semelhante sem gerar tantos documentos durante o processo e procuram minimizar o risco com curtos períodos de desenvolvimento. No início a "programação extrema" causou muito reboliço com suas idéias de programação em pares e projeto contínuo e hoje em dia sofre críticas mesmo daqueles que acreditam nas metodologias ágeis, como depender de desenvolvedores muito bem preparados, falta de estrutura e documentação, requerer uma mudança cultural muito grande, etc. Mais recentemente a metodologia ágil que mais ouço falar é a Scrum que procura percorrer todo o processo de desenvolvimento de software em "sprints" curtos, geralmente de 15-30 dias, gerando versões funcionais de software regularmente.

Basicamente, no Scrum se faz um planejamento geral que gera a lista completa de requisitos de software (o que é chamado de "product backlog"). Então se faz reuniões periódicas chamadas de "Sprint Planning Meetings" onde se acorda o escopo do próximo "sprint", montando o "sprint backlog". Diariamente durante o sprint, se faz uma reunião rápida para verificar se o andamento do sprint está comprometido (Daily Scrum). No final do sprint, se faz uma apresentação as "clientes" da versão, mostrando as funcionalidades implementadas e as anomalias que foram encontradas, para atualizarem o "product backlog" e se prepararem para o novo "sprint". Também deve ser realizada uma reunião de "Sprint Restrospective" para darem feedback sobre o processo e melhorarem o que for possível para o próximo "sprint". Devem, então, acontecer tantos "sprints" quanto forem necessários para que o produto seja dado como concluído.

Ultimamente tenho começado a acreditar que esta metodologia funciona muito bem com o tipo de estrutura que temos aqui na empresa que trabalho e estou estudando mais a respeito para utilizarmos o que for possível/benéfico.