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. A seguir são apresentados de forma simples 5 modelos de desenvolvimento diferentes.
MODELO SEQUENCIAL 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
Modelagem
Como o software faz parte de um sistema maior (hardware, banco de dados, 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.
Teste
O processo de teste focaliza os aspectos lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos, descobrindo erros na interface com o usuário e garantindo que entradas definidas produzam resultados reais, que estejam 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 reaplicar 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 são:
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. 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, banco de dados, 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.
Teste
O processo de teste focaliza os aspectos lógicos internos do software, garantindo que todos os comandos sejam testados e aspectos externos, descobrindo erros na interface com o usuário e garantindo que entradas definidas produzam resultados reais, que estejam 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 reaplicar 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 são:
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. 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.
MODELO DE PROTOTIPAGEM
A abordagem de prototipagem é muito útil para o esclarecimento e a formalização do projeto.
Esclarecimento, pois tudo o que será desenvolvido será baseado no que for apresentado em forma de telas para os usuários finais; e formalização, pois depois de aprovado o protótipo, você não corre o risco do cliente alegar que achava que determinada funcionalidade estaria no sistema.
Geralmente quando é desenvolvido um sistema, o cliente define um conjunto de objetivos gerais para o software, mas não identifica detalhadamente requisitos de entrada, de processamento, nem de saída.
Os desenvolvedores podem também estar inseguros da eficiência de um algoritmo ou da forma que a interação homem/máquina deve assumir.
Como este modelo funciona então?
O modelo de prototipagem começa com a definição de requisitos. O desenvolvedor e o cliente se encontram e definem objetivos gerais do software, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições.
Um projeto rápido é então realizado. Esse projeto concentra-se na representação daqueles aspectos de software que ficam posteriormente visíveis ao cliente/usuário (ex: abordagens de entrada e formatos de saída).
O projeto rápido parte de um protótipo. O protótipo é avaliado pelo cliente/usuário e usado para refinar os requisitos do software que é desenvolvido posteriormente.
Interações ocorrem a medida que o protótipo é ajustado para satisfazer as necessidades do cliente e ao mesmo tempo permite ao desenvolvedor entender o que precisa ser feito.
O protótipo serve como um mecanismo para a identificação dos requisitos do software.
Você pode desenvolver protótipos executáveis se julgar mais adequado. Neste caso, o desenvolvedor tenta usar partes de programas existentes ou aplica ferramentas (geradores de relatórios, gestores de janelas) que permitem que programas executáveis sejam gerados rapidamente.
O protótipo pode servir como o primeiro sistema (a questão não é se ele será descartado. Ele será pois ninguém é capaz de projetar um sistema perfeito na primeira versão).
Esse tipo de abordagem agrada a desenvolvedores e clientes.
O fluxo de desenvolvimento funciona da seguinte maneira:
OUVIR O CLIENTE - > CONSTRUIR/REVISAR PROTÓTIPO -> CLIENTE TESTA -> OUVIR O CLIENTE -> ETC...
Ao final do protótipo, temos o sistema todo delineado e já especificado o que deve ser feito.
A partir daí, o protótipo deve ser utilizado posteriormente apenas como um documento base para o que deve ser desenvolvido. O desenvolvimento de um software com qualidade começa a partir deste ponto.
Os problemas da prototipagem são:
1) O cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consegue funcionar precariamente, sem saber que na pressa de fazê-lo rodar, ninguém considerou a sua qualidade global ou a manutenibilidade a longo prazo. O protótipo não deve ser reutilizado, pois foi feito apenas para que os requisitos do sistema sejam compreendidos.
Quando informado que o produto deve ser refeito de modo que altos níveis de qualidade possam ser atingidos, o cliente reclama e exige "alguns consertos", para transformar o protótipo num produto executável. Erroneamente, mas em geral, os desenvolvedores concordam.
2) O desenvolvedor frequentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável. Um sistema operacional ou uma linguagem de programação inapropriada pode ser usado simplesmente por estar disponível e ser conhecido; um algoritmo ineficiente pode ser implementado simplesmente para demonstrar uma possibilidade. Com o tempo, o desenvolvedor pode ficar familiarizado com essas escolhas e esquecer todas as razões por que elas eram inadequadas. Tem-se que tomar muito cuidado com isso. Uma escolha muito abaixo da ideal se torna parte integral do sistema.
O importante para a prototipagem é definir as regras do jogo no início; isto é, o cliente e o desenvolvedor devem estar de acordo que o protótipo seja construído para servir apenas como um mecanismo para definição dos requisitos e que depois ele seja descartado, e o software real é submetido à engenharia com o objetivo de buscar qualidade e manutenibilidade.
Esclarecimento, pois tudo o que será desenvolvido será baseado no que for apresentado em forma de telas para os usuários finais; e formalização, pois depois de aprovado o protótipo, você não corre o risco do cliente alegar que achava que determinada funcionalidade estaria no sistema.
Geralmente quando é desenvolvido um sistema, o cliente define um conjunto de objetivos gerais para o software, mas não identifica detalhadamente requisitos de entrada, de processamento, nem de saída.
Os desenvolvedores podem também estar inseguros da eficiência de um algoritmo ou da forma que a interação homem/máquina deve assumir.
Como este modelo funciona então?
O modelo de prototipagem começa com a definição de requisitos. O desenvolvedor e o cliente se encontram e definem objetivos gerais do software, identificam as necessidades conhecidas e delineiam áreas que necessitam de mais definições.
Um projeto rápido é então realizado. Esse projeto concentra-se na representação daqueles aspectos de software que ficam posteriormente visíveis ao cliente/usuário (ex: abordagens de entrada e formatos de saída).
O projeto rápido parte de um protótipo. O protótipo é avaliado pelo cliente/usuário e usado para refinar os requisitos do software que é desenvolvido posteriormente.
Interações ocorrem a medida que o protótipo é ajustado para satisfazer as necessidades do cliente e ao mesmo tempo permite ao desenvolvedor entender o que precisa ser feito.
O protótipo serve como um mecanismo para a identificação dos requisitos do software.
Você pode desenvolver protótipos executáveis se julgar mais adequado. Neste caso, o desenvolvedor tenta usar partes de programas existentes ou aplica ferramentas (geradores de relatórios, gestores de janelas) que permitem que programas executáveis sejam gerados rapidamente.
O protótipo pode servir como o primeiro sistema (a questão não é se ele será descartado. Ele será pois ninguém é capaz de projetar um sistema perfeito na primeira versão).
Esse tipo de abordagem agrada a desenvolvedores e clientes.
O fluxo de desenvolvimento funciona da seguinte maneira:
OUVIR O CLIENTE - > CONSTRUIR/REVISAR PROTÓTIPO -> CLIENTE TESTA -> OUVIR O CLIENTE -> ETC...
Ao final do protótipo, temos o sistema todo delineado e já especificado o que deve ser feito.
A partir daí, o protótipo deve ser utilizado posteriormente apenas como um documento base para o que deve ser desenvolvido. O desenvolvimento de um software com qualidade começa a partir deste ponto.
Os problemas da prototipagem são:
1) O cliente vê o que parece ser uma versão executável do software, ignorando que o protótipo apenas consegue funcionar precariamente, sem saber que na pressa de fazê-lo rodar, ninguém considerou a sua qualidade global ou a manutenibilidade a longo prazo. O protótipo não deve ser reutilizado, pois foi feito apenas para que os requisitos do sistema sejam compreendidos.
Quando informado que o produto deve ser refeito de modo que altos níveis de qualidade possam ser atingidos, o cliente reclama e exige "alguns consertos", para transformar o protótipo num produto executável. Erroneamente, mas em geral, os desenvolvedores concordam.
2) O desenvolvedor frequentemente faz concessões na implementação a fim de conseguir rapidamente um protótipo executável. Um sistema operacional ou uma linguagem de programação inapropriada pode ser usado simplesmente por estar disponível e ser conhecido; um algoritmo ineficiente pode ser implementado simplesmente para demonstrar uma possibilidade. Com o tempo, o desenvolvedor pode ficar familiarizado com essas escolhas e esquecer todas as razões por que elas eram inadequadas. Tem-se que tomar muito cuidado com isso. Uma escolha muito abaixo da ideal se torna parte integral do sistema.
O importante para a prototipagem é definir as regras do jogo no início; isto é, o cliente e o desenvolvedor devem estar de acordo que o protótipo seja construído para servir apenas como um mecanismo para definição dos requisitos e que depois ele seja descartado, e o software real é submetido à engenharia com o objetivo de buscar qualidade e manutenibilidade.
MODELO RAD (RAPID APPLICATION DEVELOPMENT)
Modelo de desenvolvimento incremental que enfatiza um ciclo de desenvolvimento extremamente curto. O modelo RAD é uma adaptação de alta velocidade do modelo linear que é conseguido pelo desenvolvimento baseado em componentes.
Se os requisitos são bem compreendidos (aí pode-se encaixar a questão do modelo de prototipagem, mas perderia-se a característica de desenvolvimento rápido) e o objetivo do projeto é restrito, o RAD permite criar sistemas plenamente funcionais dentro de períodos muito curtos (entre 60 e 90 dias - sistemas, não sites. Sites seriam criados em ainda menos tempo).
Usa as seguintes fases:
Modelagem do negócio
O fluxo de informações entre as funções do negócio modelado visa responder as seguintes questões: Que informação dirige o processo do negócio? Que informação é gerada? Quem a gera? Para onde vai a informação? Quem a processa?
Modelagem de dados
O fluxo de informações definido anteriormente é refinado num conjunto de objetos dados que são necessários para dar suporte ao negócio. Os atributos de cada objeto são identificados e as relações entre esses objetos são definidas (ainda é anterior ao Use Case. é como se estivesse definindo os atores e os use cases sem definir a relação entre eles).
Modelagem do processo
Os objetos de dados definidos na fase anterior são transformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados (aqui monta-se propriamente o use case).
Geração da aplicação
Ao invés de usar linguagens procedimentais, o RAD usa linguagens de 4ª geração (4GL é um exemplo - permite que defina a especificação do projeto e a framework cria tudo. Relatórios, cadastros, etc). Seu desenvolvimento é feito para reutilizar componentes ou criar novos componentes reutilizáveis. Em todos os casos ferramentas automatizadas são usadas para facilitar a construção do software.
Teste e entrega
Como o processo RAD tem foco nos componentes, muitos dos componentes já devem ter sido testados. Isso reduz o tempo total de teste. Porém novos componentes devem ser testados e as interfaces exaustivamente exercitadas.
Se uma aplicação comercial pode ser modularizada de modo a permitir que cada função principal possa ser completada em menos de 3 meses usando a abordagem anterior, ela é candidata ao RAD. Cada função pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo.
Desvantagens
1) Para projetos grandes (mensuráveis) o RAD exige muitos recursos humanos.
2) Exige desenvolvedores e clientes compromissados com atividades contínuas e rápidas. Se não houver esse comprometimento, os projetos falham.
3) Nem todos os tipos de aplicações são apropriadas para o RAD. Se o sistema não puder ser adequadamente modularizado, a construção dos componentes fica problemática. Se for preciso um desempenho superior e esse desempenho seja conseguido com o ajuste dos componentes, a abordagem RAD pode não funcionar.
4) Quando riscos técnicos são elevados, o RAD não é adequado (ex: uso de uma tecnologia nova ou exigência de comunicação com outros programas).
Se os requisitos são bem compreendidos (aí pode-se encaixar a questão do modelo de prototipagem, mas perderia-se a característica de desenvolvimento rápido) e o objetivo do projeto é restrito, o RAD permite criar sistemas plenamente funcionais dentro de períodos muito curtos (entre 60 e 90 dias - sistemas, não sites. Sites seriam criados em ainda menos tempo).
Usa as seguintes fases:
Modelagem do negócio
O fluxo de informações entre as funções do negócio modelado visa responder as seguintes questões: Que informação dirige o processo do negócio? Que informação é gerada? Quem a gera? Para onde vai a informação? Quem a processa?
Modelagem de dados
O fluxo de informações definido anteriormente é refinado num conjunto de objetos dados que são necessários para dar suporte ao negócio. Os atributos de cada objeto são identificados e as relações entre esses objetos são definidas (ainda é anterior ao Use Case. é como se estivesse definindo os atores e os use cases sem definir a relação entre eles).
Modelagem do processo
Os objetos de dados definidos na fase anterior são transformados para conseguir o fluxo de informação necessário para implementar uma função do negócio. Descrições do processamento são criadas para adicionar, modificar, descartar ou recuperar um objeto de dados (aqui monta-se propriamente o use case).
Geração da aplicação
Ao invés de usar linguagens procedimentais, o RAD usa linguagens de 4ª geração (4GL é um exemplo - permite que defina a especificação do projeto e a framework cria tudo. Relatórios, cadastros, etc). Seu desenvolvimento é feito para reutilizar componentes ou criar novos componentes reutilizáveis. Em todos os casos ferramentas automatizadas são usadas para facilitar a construção do software.
Teste e entrega
Como o processo RAD tem foco nos componentes, muitos dos componentes já devem ter sido testados. Isso reduz o tempo total de teste. Porém novos componentes devem ser testados e as interfaces exaustivamente exercitadas.
Se uma aplicação comercial pode ser modularizada de modo a permitir que cada função principal possa ser completada em menos de 3 meses usando a abordagem anterior, ela é candidata ao RAD. Cada função pode ser tratada por uma equipe RAD distinta e depois integrada para formar um todo.
Desvantagens
1) Para projetos grandes (mensuráveis) o RAD exige muitos recursos humanos.
2) Exige desenvolvedores e clientes compromissados com atividades contínuas e rápidas. Se não houver esse comprometimento, os projetos falham.
3) Nem todos os tipos de aplicações são apropriadas para o RAD. Se o sistema não puder ser adequadamente modularizado, a construção dos componentes fica problemática. Se for preciso um desempenho superior e esse desempenho seja conseguido com o ajuste dos componentes, a abordagem RAD pode não funcionar.
4) Quando riscos técnicos são elevados, o RAD não é adequado (ex: uso de uma tecnologia nova ou exigência de comunicação com outros programas).
MODELOS EVOLUCIONÁRIOS: INCREMENTAL
Combina elementos do modelo sequencial linear com a filosofia interativa da prototipagem. Cada sequência linear produz um incremento.
Por exemplo: Se for desenvolver um site, no primeiro incremento tem-se as funcionalidades sobre a empresa, contato e produtos. Em um segundo incremento tem-se acesso restrito para clientes, newsletter, enquete e assim se seguiria durante todo o processo de desenvolvimento.
Quando este modelo é usado, o primeiro incremento é tido como o núcleo do sistema. Ele é usado pelo cliente e então é necessário fazer um plano para o próximo incremento como resultado do uso/avaliação. O plano visa melhorar o núcleo e adicionar novas funcionalidades, que por sua vez são testadas e alteradas para se adequarem às solicitações do cliente, e assim por diante.
A grande diferença do modelo incremental para o modelo de prototipagem é que a cada incremento o cliente já possui um modelo utilizável e aprovado.
incremento 1: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
incremento 2: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
incremento 3: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
Por exemplo: Se for desenvolver um site, no primeiro incremento tem-se as funcionalidades sobre a empresa, contato e produtos. Em um segundo incremento tem-se acesso restrito para clientes, newsletter, enquete e assim se seguiria durante todo o processo de desenvolvimento.
Quando este modelo é usado, o primeiro incremento é tido como o núcleo do sistema. Ele é usado pelo cliente e então é necessário fazer um plano para o próximo incremento como resultado do uso/avaliação. O plano visa melhorar o núcleo e adicionar novas funcionalidades, que por sua vez são testadas e alteradas para se adequarem às solicitações do cliente, e assim por diante.
A grande diferença do modelo incremental para o modelo de prototipagem é que a cada incremento o cliente já possui um modelo utilizável e aprovado.
incremento 1: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
incremento 2: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
incremento 3: ANÁLISE -> PROJETO -> CODIFICAÇÃO -> TESTE
MODELOS EVOLUCIONÁRIOS: ESPIRAL
Também mescla o modelo modelo sequencial linear com o da prototipagem. Oferece potencial para desenvolvimento rápido de versões incrementais do software. Nos primeiros incrementos podem ser usados papel ou protótipo. Durante os últimos incrementos são produzidas versões cada vez mais completas do sistema submetido à engenharia.
São utilizadas as seguintes tarefas:
São utilizadas as seguintes tarefas:
- Comunicação com o cliente;
- Planejamento - tarefa necessária para definir recursos, prazos e outras informações relacionadas ao projeto;
- Análise de risco;
- Engenharia - tarefa necessária para se construir uma ou mais representações da aplicação;
- Construção e liberação - tarefas necessárias para se construir, testar, instalar e fornecer apoio ao usuário (documentação e treinamento);
- Planejamento - tarefa necessária para definir recursos, prazos e outras informações relacionadas ao projeto;
- Análise de risco;
- Engenharia - tarefa necessária para se construir uma ou mais representações da aplicação;
- Construção e liberação - tarefas necessárias para se construir, testar, instalar e fornecer apoio ao usuário (documentação e treinamento);
- Avaliação pelo cliente.
0 comentários:
Postar um comentário