Metodologia de Desenvolvimento de Software

O termo metodologia é bastante controverso nas ciências em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e método como sinônimos, porém seria mais adequado dizer que uma metodologia envolve princípios filosóficos que guiam uma gama de métodos que utilizam ferramentas e práticas diferenciadas para realizar algo.

Modelagem

A abstração do sistema de software através de modelos que o descrevem é um poderoso instrumento para o entendimento e comunicação do produto final que será desenvolvido.

A maior dificuldade nesta atividade está no equilíbrio (tradeoff) entre simplicidade (favorecendo a comunicação) e a complexidade (favorecendo a precisão) do modelo.

Para a modelagem podemos citar 3 métodos:

Análise estruturada, criada por Gane & Searson;
Análise essencial, criada por Palmer & McMenamin e Ed. Yourdon;
UML criada por Grady Booch, Ivar Jacobson & Jaimes Rumbaugh.

Atualmente a modelagem mais recomendada, e sendo a mais comum, é a utilização da linguagem UML.

Ferramentas, Tecnologias e Práticas

A engenharia de software aborda uma série de práticas e tecnologias, principalmente estudadas pela ciência da computação, enfocando seu impacto na produtividade e qualidade de software.

Destacam-se o estudo de linguagem de programação, banco de dados e paradigmas de programação, como:

Programação estruturada
Programação funcional
Programação orientada a objetos
Componentes de Software
Programação orientada a aspectos

Ferramentas

Outro ponto importante é o uso de ferramentas CASE (do inglês Computer-Aided Software Engineering). Essa classificação abrange toda ferramenta baseada em computadores que auxiliam atividades de engenharia de software, desde a análise de requisitos e modelagem até programação e testes.

Gerência de Projetos

A gerência de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo.

A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização.

Planejamento

O planejamento de um projeto de desenvolvimento de software inclui:

Análise Econômica de Sistemas de Informações
Organização do projeto (incluindo equipes e responsabilidades)
Estruturação das tarefas (do inglês WBS – work breakdown structure)
Cronograma do projeto (do inglês project schedule)
Análise e gestão de riscos
Estimativa de custos

Essas atividades sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente a produtividade.

A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas técnicos. Esses fatores requerem uma análise de riscos cuidadosa.

Além da própria identificação dos riscos, há que ter em conta a sua gestão. Seja evitando, seja resolvendo, os riscos necessitam ser identificados (estimando o seu impacto) e devem ser criados planos para resolução de problemas.

Análise de Requisitos

As atividades de análise concentram-se na identificação, especificação e descrição dos requisitos do sistema de software. Em resumo, requisito é uma necessidade que o software deve cumprir.

Há várias interpretações e classificações sobre requisitos, entre elas:

Funcional
Não funcional
De usuário
De sistema

É comum que o cliente não saiba o que ele realmente deseja, que haja problemas na comunicação e ainda que haja mudança constante de requisitos. Todos esses fatores são recrudescidos pela intangibilidade sobre características de sistemas de software, principalmente sobre o custo de cada requisito.

Gestão

Pessoal
Produto
Processo
Projeto
Material

Análise Econômica

Visa a estabelecer se o projeto de Software gerará lucro, e se a receita gerada será o suficiente para cobrir os custos. Este processo acompanha todas as demais etapas de desenvolvimento do Software.

Análise de requisitos de software

A extração dos requisitos de um desejado produto de software é a primeira tarefa na sua criação. Embora o cliente, provavelmente, acredite saber o que o software deva fazer, esta tarefa requer habilidade e experiência em engenharia de software para reconhecer a incompletude, ambigüidade ou contradição nos requisitos.

Especificação

A especificação é a tarefa de descrever precisamente o software que será escrito, preferencialmente de uma forma matematicamente rigorosa. Na prática, somente especificações mais bem sucedidas foram escritas para aplicações bem compreendidas e afinadas que já estavam bem desenvolvidas, embora sistemas de software de missão crítica sejam freqüentemente bem especificados antes do desenvolvimento da aplicação. Especificações são mais importantes para interfaces externas que devem permanecer estáveis.

Arquitetura de Software

A arquitetura de um sistema de software remete a uma representação abstrata daquele sistema. Arquitetura é concernente à garantia de que o sistema de software irá ao encontro de requisitos do produto, como também assegurar que futuros requisitos possam ser atendidos. A etapa da arquitetura também direciona as interfaces entre os sistemas de software e outros produtos de software, como também com o hardware básico ou com o sistema operacional.

Implementação (ou codificação)

A transformação de um projeto para um código deve ser a parte mais evidente do trabalho da engenharia de software, mas não necessariamente a sua maior porção.

Testes

Testes de partes do software, especialmente onde tenha sido codificado por dois ou mais engenheiros trabalhando juntos, é um papel da engenharia de software.

Documentação

Uma importante tarefa é a documentação do projeto interno do software para propósitos de futuras manutenções e aprimoramentos. As documentações mais importantes são das interfaces externas.

Suporte e Treinamento de Software

Uma grande porcentagem dos projetos de software falham pelo fato de o desenvolvedor não perceber que não importa quanto tempo a equipe de planejamento e desenvolvimento irá gastar na criação do software se ninguém da organização irá usá-lo. As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares. Então, como parte da fase de desenvolvimento, é muito importante o treinamento para os usuários de software mais entusiasmados, alternando o treinamento entre usuários neutros e usuários favoráveis ao software. Usuários irão ter muitas questões e problemas de software os quais conduzirão para a próxima fase.

Manutenção

A manutenção e melhoria de software lidam com a descoberta de novos problemas e requisitos. Ela pode tomar mais tempo que o gasto no desenvolvimento inicial do mesmo. Não somente pode ser necessário adicionar códigos que combinem com o projeto original, mas determinar como o software trabalhará em algum ponto depois da manutenção estar completa, pode requerer um significativo esforço por parte de um engenheiro de software. Cerca de ⅔ de todos os engenheiros de software trabalham com a manutenção, mas estas estatísticas podem estar enganadas. Um pequena parte destes trabalha na correção de erros. A maioria das manutenções são para ampliar os sistemas para novas funcionalidades, as quais, de diversas formas, podem ser consideradas um novo trabalho. Analogamente, cerca de ⅔ de todos os engenheiros civis, arquitetos e construtores trabalham com manutenção de uma forma similar.

Padrões

O processo de desenvolvimento de software tem sido objetivo de vários padrões, que visam a certificação de empresas como possuidoras de um processo de desenvolvimento, o que garantiria certo grau de confiança aos seus contratantes.

Alguns padrões existentes atualmente:

CMMI (anteriormente CMM)
SPICE
ISO 12207
MPS/Br

Modelos de Processo

Há uma década, vem se tentando encontrar um processo ou metodologia previsível e repetível que melhore a produtividade e qualidade. Alguns tentaram sintetizar e formalizar a tarefa aparentemente incontrolável de escrever um software. Outros aplicaram técnicas de gerenciamento de projeto na escrita de software. Sem o gerenciamento de projeto, projetos de software podem facilmente sofrer atraso ou estourar o orçamento. Como um grande número de projetos de software não atendem suas expectativas em termos de funcionalidades, custo, ou cronograma de entrega, ainda não existe um modelo de processo perfeito para todas aplicações.

Processo em cascata

O mais antigo e bem conhecido processo é o Modelo em cascata, onde os desenvolvedores seguem estes passos em ordem. Eles estabelecem os requisitos, os analisam, projetam uma abordagem para solução, arquitetam um esboço do software, implementam o código, testam (inicialmente os testes unitários e então os testes de sistema), implantam e mantêm. Depois que cada passo é terminado, o processo segue para o próximo passo, tal como construtores que não revisam as fundações de uma casa depois que as paredes foram erguidas. Se as iterações não são incluídas no planejamento, o processo não tem meios para corrigir os erros nas etapas inicias (por exemplo, nos requisitos), então o processo inteiro da engenharia de software deve ser executado até o fim, resultando em funcionalidades de software desnecessárias ou sem uso.Para isso tem que se fazer o implemento dos requisitos anteriormente analisados pelo programador.

Processos Iterativos

O Desenvolvimento iterativo e incremental prescreve a construção de uma porção pequena, mas abrangente, do projeto de software para ajudar a todos os envolvidos a descobrir cedo os problemas ou suposições, falhas que possam a levar ao desastre. O processo iterativo é preferido por desenvolvedores porque lhes fornece um potencial para atingir os objetivos de projeto de um cliente que não sabe exatamente o que quer, ou quando não se conhece bem todos os aspectos da solução.

Processos de desenvolvimento ágil de software são construídos com os fundamentos do desenvolvimento iterativo. Os processos ágeis usam o feedback, mais que o planejamento, como seus mecanismos de controle primário. O feedback é produzido por testes regulares e das versões do software desenvolvido.

Processos ágeis

Os processos em Desenvolvimento ágil de software parecem ser mais eficientes do que as metodologias antigas. Utiliza menos tempo do programador no desenvolvimento de softwares funcionais de alta qualidade, mas tem a desvantagem de ter uma perspectiva de negocio que não provê uma capacidade de planejamento em longo prazo. Em essência, eles provem mais funcionalidades por custo/benefício, mas não dizem exatamente o que a funcionalidade irá fazer.

Existem várias metodologias que podem ser consideradas como abordagens ágeis, entre elas: Scrum, Programação extrema, FDD, Crystal Clear, DSDM entre outras.

A Programação Extrema (XP), é o mais bem conhecido processo ágil. Em XP, as fases são continuadas em passos extremamente pequenos (ou contínuos) comparados aos processos antigos. A primeira passada (iteração incompleta) através das etapas deve levar um dia ou uma semana, ao invés de meses ou anos para cada fase completa do modelo em cascata. Primeiramente, escreve-se um autômato de teste, que provê objetivos concretos para o desenvolvimento. Depois é codificado (por um par de programadores), este passo está completo quando todos os testes se concluem, e os programadores não pensem em nada mais que possa ser testado. Projetistas e Arquitetos executam uma refatoração do código. O projeto é feito por pessoas que estão codificando. O sistema incompleto mas funcional é entregue e demonstrado para os usuários. Neste ponto, os envolvidos iniciam novamente uma nova fase de escrita e teste para as próximas partes mais importantes do sistema.

Método formal

Os Métodos Formais são abordagens matemáticas para resolver problemas de software e hardware ao nível de requisito, especificação e projetos. Exemplos de métodos formais incluem Método-B, Redes Petri, RAISE e VDM. Várias notações de especificação formal estão disponíveis, tais como a notação-Z. De forma mais genérica, a teoria do autômato pode ser usada para construir e validar o comportamento da aplicação para o projeto de um sistema de máquina de estado finito.

Máquinas de estado finito baseadas nestas metodologias permitiram especificar software executáveis e contornar a codificação convencional.

Iconix

Iconix é um processo de desenvolvimento de software que não é tão burocrático quanto o RUP nem radical como o XP.

Iconix pode ser considerada uma metodologia pura, prática e simples, mas também poderosa e com um componente de análise e representação dos problemas sólido e eficaz, por isso, a metodologia Iconix é caracterizada como um Processo de Desenvolvimento de Software desenvolvido pela Iconix Software Engineering (www.iconixsw.com).

O Iconix é um processo não tão burocrático como o RUP, ou seja, não gera tanta documentação. E apesar de ser um processo simples como o XP, não deixa a desejar na Análise e Projeto (Design), e se destaca com um poderoso processo de desenvolvimento de software.

Este processo também faz uso da linguagem de modelagem UML e possui uma característica exclusiva chamada “Rastreabilidade dos Requisitos” (Traceability of Requirements). Mais precisamente, Iconix nos permite “obrigatoriamente”, através de seus mecanismos, verificar em todas as fases se os requisitos estão sendo atendidos. A abordagem Iconix é flexível e aberta, isto é, se for necessário usar outro recurso da UML para complementar os recursos usados nas fases do Iconix, não há problema algum.

O Iconix é composto pelas seguintes principais fases:

Modelo de Domínio
Modelo de Caso de Uso
Análise Robusta
Diagrama de Sequência
Diagrama de Classe