Saga de construção de um software
Paradigmas da Engenharia de Software
Desenvolvimento Caótico
- O produto é construído sem qualquer especificação ou projeto e o programador é a figura principal que determina todos os requisitos e passos do sistema
- Por não ter planejamento, o produto é retrabalhado quantas vezes for necessário para atender o cliente que volta e meia tem solicitações de mudança
- Este modelo pode funcionar razoavelmente para micro projetos mas para projetos maiores é totalmente inadequado.
- Em sistemas de porte não pequeno, geram tanto retrabalho que sempre um dos lados sai perdendo:
- Ou o desenvolvedor, que levará um enorme tempo para entregar uma solução complenta
- Ou o cliente, que não terá ou demorará a ter a solução que esperava.
Modelo Clássico
- A abordagem clássica prevê o desenvolvimento do sistema mediante algum tipo de análise, projeto e implementação, que são realizadas seqüencialmente, ou seja, uma após o término da outra.
- Todo projeto desenvolvido, é executado mediante algum método de análise de sistemas, projeto e implementação, mesmo que não seja feito conforme ilustrado pela figura abaixo. Assim, o número de fases varia de organização para organização e pode ter cinco, sete ou doze fases.
- Pode-se observar que as fases contemplam um conjunto seqüencial de ações de desenvolvimento, desde o diagnóstico do problema até os testes necessários à implementação.
- O uso dessa implementação possui algumas fraquezas:
- Nada está terminado até que se complete todas as fases. Se houver um atraso e o prazo final coincidir com a fase de testes, não se terá nada para apresentar ao usuário.
- Os erros mais comuns são encontrados no início do período de testes, enquanto os mais sérios são encontrados apenas no final.
- A localização do módulo que contém o erro pode ser extremamente difícil se este for detectado durante o teste de sistema.
- Uma segunda fraqueza do Modelo Clássico é a organização das fases de forma sequencial, ou seja, a fase de Análise somente teria início após a conclusão da fase de Levantamento de Dados e assim por diante.
- Além disso, este modelo exige que o usuário declare explicitamente todas as suas exigências, mas às vezes, é difícil para ele fazer isso, impedindo que o projeto siga o fluxo seqüencial que o modelo propõe.
Modelo de Prototipação
- A prototipação prevê a construção de um modelo do software que será implementado de forma que se possa fazer uma avaliação do resultado macro com base numa mostra do todo.
- A definição do sistema ocorre através da descoberta gradual e evolutiva deste por parte do usuário e do desenvolvedor. Assim, obtém-se um conjunto inicial de necessidades e as implementam rapidamente com a intenção de refiná-las de acordo com o aumento do conhecimento do sistema por parte do desenvolvedor e do usuário.
- O modelo em questão capacita o desenvolvedor a criar um modelo do sistema que será implementado. Esse modelo pode assumir três formas:
- Um protótipo em papel ou um modelo computacional que mostra a interação do homem com a máquina, de tal forma que o usuário entenda com clareza a interação existente.
- Um protótipo de trabalho que implemente algumas funções que são exigidas pelo sistema desejado.
- Um programa existente que execute parte ou toda a função desejada para o novo sistema, mas com características que poderão ser melhoradas durante o desenvolvimento.
- Em alguns casos, o protótipo permite que o usuário armazene dados e execute operações com esses dados. Tais protótipos são genericamente chamados de "Protótipos Funcionais". Alguns protótipos são mais compreensivos e modelam sistemas altamente complexos. Outros modelam sistemas pequenos e relativamente simples. Um protótipo pode modelar somente uma parte do sistema a ser desenvolvido, ou o sistema inteiro
- Uma distinção deve ser feita entre o protótipo e um sistema real:
- Sistemas reais têm a intenção de uso operacional e devem seguir determinados padrões no que diz respeito a sua qualidade, segurança, desempenho, capacidade, robustez e facilidade de manutenção.
- Em contraste, protótipos visam clareza na visualização de determinados aspectos de um sistema sobre os quais há incerteza. Protótipos são usados para verificar a precisão das hipóteses feitas sobre esses aspectos.
- Assim, diferente dos sistemas reais, os protótipos são tipicamente incompletos e não têm a intenção de funcionar sem falhas (toleráveis).
- O sistema resultante da fase “ Prototipação” é apenas um protótipo, e que não pode ser considerado como um produto final (Boar, 1984). Normalmente é descartado o produto, sendo o projeto subsequente realizado na forma tradicional, porém sempre dando sequência à capacidade e estabilidade nos requisitos obtidos na fase de “ Prototipação” .
- Como no modelo Clássico, a prototipação também tem alguns problemas:
- O cliente vê o protótipo e tem pressa para colocá-lo em funcionamento, não levando em consideração a qualidade global do sistema.
- Muitas vezes o desenvolvedor quer colocar o protótipo em funcionamento rapidamente, com isso, um sistema operacional ou linguagem de programação imprópria pode ser usada, simplesmente porque está à disposição e é conhecida.
Modelo Espiral
- Pesquisa:
Técnicas de 4a Geração
- Concentra-se na capacidade de se especificar o software a uma máquina em um nível que esteja próximo à linguagem natural
- Engloba um conjunto de ferramentas de software que possibilitam que:
- o sistema seja especificado em uma linguagem de alto nível e
- o código fonte seja gerado automaticamente a partir dessas especificações
- O ambiente de desenvolvimento de software que sustenta o modelo de 4a geração inclui as seguintes ferramentas:
- linguagens não procedimentais para consulta de banco de dados
- geração de relatórios
- manipulação de dados
- interação e definição de telas
- geração de códigos
- capacidade gráfica de alto nível
- capacidade de planilhas eletrônicas
- Obtenção dos requisitos:
- O cliente descreve os requisitos os quais são traduzidos para um protótipo operacional
- O cliente pode estar inseguro quanto aos requisitos
- O cliente pode ser incapaz de especificar as informações de um modo que uma ferramenta 4GL possa consumir
- As 4GLs atuais não são sofisticadas suficientemente para acomodar a verdadeira "linguagem natural" mas tem evoluido ao longo do tempo
- Estratégia do projeto:
- Para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos para o passo de Implementação usando uma linguagem de quarta geração
- Para grandes projetos é necessário desenvolver uma estratégia de projeto. De outro modo ocorrerão os mesmos problemas encontrados quando se usa abordagem convencional (baixa qualidade)
- Implementação usando 4GL :
- Os resultados desejados são representados de modo que haja geração automática de código .
- Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4GL
- Testes:
- O desenvolvedor deve efetuar testes e desenvolver uma documentação significativa.
- O software desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente.
Modelo de Entrega Evolutiva
- O software evolui ao longo do tempo e conforme o desenvolvimento deste software avança também temos mudanças nas necessidades de negócio e de produtos que mudam frequentemente. Isso torna inadequado seguirmos um planejamento em linha reta de um produto. Os modelos de processo evolucionário tornaram-se realidade para que possamos desenvolver um produto que evolua ao longo do tempo.
- Modelos evolucionários são caracterizados por serem iterativos e apresentarem características que possibilitem desenvolvermos versões cada vez mais completas do software. Os processos evolucionários se caracterizam por dois modelos comuns: Prototipação e Espiral.
RAD
- RAD - Rápido Desenvolvimento de Aplicações
- O RAD, como ficou conhecido, começou a surgir junto com o Visual Basic. A ideia era permitir o desenvolvimento rápido com um mínimo de código. Tornar possível que o desenvolvedor se concentrasse nas regras de negócio da aplicação que estava desenvolvendo e não em códigos acessórios era o objetivo.
- O que antes era lógica e algorítimo se tornou configuração, junção de peças e organização de componentes. A lógica e algorítimo se acomodaram sobre o funcionamento das pecinhas, funcionando como uma cola a fazer toda a junção de componentes para chegar ao resultado final, o sistema.
- Toda a evolução pode ser resumida em uma palavra : Abstração. Tanto da roda para o carro, como do Assembly para o Pascal, da interface de texto para a interface gráfica e do Clipper para o Visual Basic/Delphi com RAD a evolução caminhou sempre no sentido da abstração - o individuo ganha a possibilidade de se despreocupar a respeito da forma de funcionamento de elementos mais simples e passa a utilizar estes elementos mais simples para construir elementos mais complexos, tendo a certeza de que os mais simples já funcionam.
Vídeo explicativo:
[1]
Modelo Incremental
- Pesquisa
Modelo Espiral vs Incremental
- Comparar: Bianca Carvalho