Modelos de desenvolvimento
Todo sistema a ser desenvolvido possui um ciclo de vida, ou seja, tem começo, meio e fim. A forma como essas etapas serão realizadas já foram discutidas pelos mais conceituados profissionais da área de informática. Este artigo apresenta de forma simples 5 modelos de desenvolvimento diferentes.
Modelo sequêncial linear
É o modelo em cascata, ou seja, o projeto vai progredindo com
o passar do tempo. Semelhante ao TCC.
ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
Como o software faz parte de um sistema maior (hardware, bd, pessoas, todos interagindo), o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois são alocados alguns subconjuntos desses requisitos para o software (por isso "em cascata").
O foco da análise volta-se para o software a ser desenvolvido. São levantadas as questões: Domínio da informação (para que o software serve e em que contexto ele está inserido), funções necessárias, comportamentos (sempre que acontecer X, fazer Y), desempenho e interface. Todos esses requisitos são documentados e revistos com o cliente.
O processo de desenvolvimento envolve múltiplos passos, que focam: estrutura de dados, arquitetura do software (como ele será construído), protótipo e detalhes procedimentais (algorítmicos). Este processo traduz (agora já pensando em nível técnico) as especificações de requisitos citadas no item anterior.
Se o projeto é realizado detalhadamente, a geração de código vira algo mecânico (aquela velha história que discutimos com maria angélica, hélder, etc).
O processo de teste focaliza os aspecto lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos (descobrir erros na interface com o usuário e garantir que entradas definidas produzirão resultados reais, que estão de acordo com os resultados exigidos (é criada uma tabela de testes, contendo a entrada, o tipo dela - numérica, alfanumérica - e seu tamanho e informações sobre o que é esperado que se obtenha como saída).
A manutenção do software reaplica cada uma das fases anteriores a um programa existente ao invés de a um novo programa.
Este modelo é o mais antigo e o mais utilizado. Porém a crítica levou até mesmo seus atuais adeptos a questionar sua eficácia. Alguns problemas:
1) Projetos reais raramente seguem o fluxo proposto (como acontece em nosso TCC, agora que identificamos várias alterações a serem feitas no início). Como resultado, modificações podem causar confusão à medida que a equipe prossegue.
2) É difícil para o cliente estabelecer todos os requisitos explicitamente (sabemos mais que ninguém que isso sempre acontece. O Você Apita é um exemplo). Este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de vários projetos.
3) O cliente precisa ter paciência. Uma versão executável do programa não estará disponível enquanto o projeto não terminar. Um erro grosseiro pode ser desastroso se não for identificado até que o programa executável seja revisto.
ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
Modelagem
Como o software faz parte de um sistema maior (hardware, bd, pessoas, todos interagindo), o trabalho começa pelo estabelecimento de requisitos para todos os elementos do sistema e depois são alocados alguns subconjuntos desses requisitos para o software (por isso "em cascata").
Análise de Requisitos para o Software
O foco da análise volta-se para o software a ser desenvolvido. São levantadas as questões: Domínio da informação (para que o software serve e em que contexto ele está inserido), funções necessárias, comportamentos (sempre que acontecer X, fazer Y), desempenho e interface. Todos esses requisitos são documentados e revistos com o cliente.
Projeto
O processo de desenvolvimento envolve múltiplos passos, que focam: estrutura de dados, arquitetura do software (como ele será construído), protótipo e detalhes procedimentais (algorítmicos). Este processo traduz (agora já pensando em nível técnico) as especificações de requisitos citadas no item anterior.
Geração de código
Se o projeto é realizado detalhadamente, a geração de código vira algo mecânico (aquela velha história que discutimos com maria angélica, hélder, etc).
Teste
O processo de teste focaliza os aspecto lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos (descobrir erros na interface com o usuário e garantir que entradas definidas produzirão resultados reais, que estão de acordo com os resultados exigidos (é criada uma tabela de testes, contendo a entrada, o tipo dela - numérica, alfanumérica - e seu tamanho e informações sobre o que é esperado que se obtenha como saída).
Manutenção
A manutenção do software reaplica cada uma das fases anteriores a um programa existente ao invés de a um novo programa.
Este modelo é o mais antigo e o mais utilizado. Porém a crítica levou até mesmo seus atuais adeptos a questionar sua eficácia. Alguns problemas:
1) Projetos reais raramente seguem o fluxo proposto (como acontece em nosso TCC, agora que identificamos várias alterações a serem feitas no início). Como resultado, modificações podem causar confusão à medida que a equipe prossegue.
2) É difícil para o cliente estabelecer todos os requisitos explicitamente (sabemos mais que ninguém que isso sempre acontece. O Você Apita é um exemplo). Este modelo exige isso e tem dificuldade de acomodar a incerteza natural que existe no começo de vários projetos.
3) O cliente precisa ter paciência. Uma versão executável do programa não estará disponível enquanto o projeto não terminar. Um erro grosseiro pode ser desastroso se não for identificado até que o programa executável seja revisto.
Na primeira página tem um trecho assim: "(aquela velha história que discutimos com maria angélica, hélder, etc)"
Ainda nessa mesma página é citado algo (um site ?) chamado: "Você Apita"
Na pagina RAD tem mais "coisas":
"(tem mais detalhes aqui no livro sobre modelagem do negócio)"
Faltou uma introdução ao contexto, mas isso não é fundamental. O que faltou mesmo foi uma abordagem sobre XP (eXtreme Programming) que tem sido o modelo predominante no desenvolvimento para Linux, apesar de pouco conhecido e praticado no brasil.