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 completa
- 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 sequencialmente, 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 sequencial 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.
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 real 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
- O modelo espiral se trata de um modelo de processo de software da forma evolucionária. Mas o que isso significa?
- De acordo com o livro “Engenharia de Software” de Roger Pressman e Bruce Maxim, um modelo de processo de software é: “Um modelo de processo de software define o fluxo de todas as atividades, ações e tarefas, o grau de iteração, os artefatos e a organização do trabalho a ser feito”. Em resumo, é uma modelagem visual de como funcionará todo o processo de desenvolvimento do software, desde sua idealização até a entrega final.
- O modelo evolucionário é uma das categorias de modelos de processo de software, nesse tipo de abordagem o software é adaptado de acordo com a evolução do projeto ou necessidade do cliente, comumente é usada a prototipagem até que se atinja a solução final ideal. Portanto, uma de suas maiores vantagens é a possibilidade de acrescentar, mudar ou remover algumas funcionalidades ao longo do processo.
- Origem do modelo espiral
- O modelo espiral foi criado pelo professor Barry Boehm que o citou em sua pesquisa “A Spiral Model of Software Development and Enhancement” em 1986. O modelo foi idealizado enquanto Barry gerenciava o processo de desenvolvimento de um novo sistema de produtividade para a empresa TRW Incorporation.
- Curiosidade:
- A TRW Automative Holdings Corporation foi criada em 1904 e conceituada por sua especialidade na fabricação de peças automotivas, em especial às associadas a segurança. Foi adquirida em 2015 pela companhia ZF Friedrichshafen AG que atua no mesmo segmento.
- Objetivo do modelo espiral
- Alinhar a estrutura metódica e clara do modelo cascata com a flexibilidade dos modelos iterativos, acrescentando ainda a gestão de risco como seu diferencial. Portanto, as etapas de desenvolvimento possuem a abordagem dos modelos clássicos, porém são presentes as fases de prototipação e análise de riscos.
- Estrutura do modelo espiral
- Pode ser dividido entre 3 a 6 fases principais, porém, o modelo de 4 quadrantes é o mais comum, sendo eles: Planejamento, Análise dos riscos, Avaliação do cliente e Engenharia.
- Fase de planejamento: nessa fase são definidos os objetivos específicos da etapa seguinte, seus riscos e também há o desenvolvimento detalhado do plano de gerenciamento.
- Fase de análise dos riscos: para cada risco levantado na etapa de planejamento aqui são elencadas as medidas imediatas para redução do impacto dos mesmos e ações para prevenção de futuros incidentes.
- Fase de engenharia: nessa etapa são definidos os requisitos técnicos necessários e a codificação do programa.
- Fase de avaliação do cliente: o projeto é revisto e avaliado pelos clientes para que o mesmo possa ser continuado, modificado ou cancelado.
- Por se tratar de um modelo maleável, as etapas contidas em cada loop podem ser adaptadas a cada projeto. Mas, de forma generalizada, podemos considerar que:
- O loop mais interno se trata do levantamento da ideia do software e seu escopo básico, levando em consideração seus possíveis riscos e durabilidade;
- A partir do segundo loop são gerados os requisitos do sistema e o modo de desenvolvimento do mesmo;
- No terceiro loop o enfoque está no projeto de desenvolvimento do software e o planejamento de suas necessidades finais para que se inicie a codificação;
- O último e mais externo loop se trata da codificação e realização dos testes de qualidade além da implementação do produto final.
- Vantagens e desvantagens do modelo espiral
- Assim como todo modelo, o modelo espiral apresenta diversas vantagens, entre elas a correção rápida de riscos, o contato e avaliação do cliente para uma entrega mais assertiva assim como também pode ser utilizada em diferentes projetos, em especial os de maior porte e complexidade. Dentre suas desvantagens pode-se citar a maior necessidade de documentação por conta das etapas de prototipagem, o fato do custo e tempo serem alterados ao longo do projeto e de difícil definição a priori e a demanda por um gerente de projetos mais experiente.
- Empresas que utilizaram o modelo espiral
- Algumas das organizações que já utilizaram o modelo espiral são a NASA, a Microsoft (utilizado durante o processo de evolução do sistema operacional Windows) e o exército dos Estados Unidos (usado no desenvolvimento de novos sistemas usados em combates).
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 é especificado em uma linguagem de alto nível e
- o código fonte é 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.
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.
Modelo Incremental
- Alguns projetos de software definem requisitos iniciais de software razoavelmente bem definidos. Pode ser necessário o rápido fornecimento de um determinado conjunto funcional aos usuários, para que após esse fornecimento, possamos melhorar e expandir suas funcionalidades em versões de software posteriores. Nesses casos, podemos optar por um modelo de processo que desenvolve software de uma forma incremental.
- O modelo de processo incremental combina elementos dos fluxos de processos tanto lineares quanto paralelos. A Figura 1 demonstra o modelo incremental:
Modelo Espiral vs Incremental
- Discussão