wiki

GGI033 - Aula 03 - 2019-2

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


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: TRW Incorporation: 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 O 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

O 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.


Erro ao criar miniatura: Arquivo não encontrado


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

Erro ao criar miniatura: Arquivo não encontrado

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).



Referências usadas na 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.


Erro ao criar miniatura: Arquivo não encontrado


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


  • 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


Fazem parte dos modelos evolutivos.

Há situações em que a engenharia de software necessita de um modelo de processo que possa acomodar um produto que evolui com o tempo. Modelos evolutivos são iterativos, possibilitam o desenvolvimento de versões cada vez mais completas do software. Esses processos são usados quando: - os requisitos de produto e de negócio mudam conforme o desenvolvimento procede. - data de entrega apertada (mercado) – impossível a conclusão de um produto completo. - o conjunto de requisitos importantes é bem conhecido, porém os detalhes ainda devem ser definidos.

O que difere o modelo iterativo incremental do modelo espiral?

Barry Boehm sugeriu, tendo em vista as limitações da abordagem tradicional, que o desenvolvimento de sistemas de informação poderia ser administrado numa série de incrementos. Assim, poderia haver uma série de ciclos de vida tradicionais para cada incremento.

O Modelo Incremental foi desenvolvido através da combinação entre os modelos linear e prototipação. O desenvolvimento é dividido em etapas, denominadas “incrementos”, que produzirão incrementalmente o sistema, até a sua versão final.

Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.

O Modelo Incremental apresenta diversas vantagens para o desenvolvimento de um software, especialmente se os requisitos não estão claros inicialmente. Por exemplo: quando o Modelo Incremental é utilizado, o primeiro incremento é normalmente constituído do núcleo do sistema. Isto é, os requisitos básicos são implementados, e os detalhes suprimidos. Esse produto será entregue para uma avaliação, que poderá detectar, inicialmente, problemas que poderiam ser de dimensões muito maiores se detectados somente na entrega do produto final.

Outra vantagem para o desenvolvedor é que, em contato com o sistema, o cliente esclarece seus requisitos e suas prioridades para os próximos incrementos, além de contar com os serviços da versão já produzida.

Outras vantagens são: A construção de um sistema menor é sempre menos arriscada que a construção de um grande; Se um grande erro é cometido, apenas o último incremento é descartado; Reduzindo o tempo de desenvolvimento de um sistema, as chances de mudanças nos requisitos do usuário durante o desenvolvimento são menores.


O modelo espiral combina a iteratividade da prototipagem com os aspectos controlados e sistemáticos do modelo cascata.

Seguindo a mesma linha do modelo incremental,o modelo foi proposto o modelo EPS (Boehm, 1988) - Evolutionary Spiral Process. Este modelo baseia-se em quatro principais atividades:

Determinação dos objetivos, alternativas e restrições; Análise de risco e prototipação; Validação e verificação; Planejamento da fase seguinte.

Esta concepção tende a criar um roteiro de atividades e etapas para que se alcance uma maturidade do processo evolutivo de desenvolvimento de sistemas complexos e obter, ao final, um produto em sua forma mais completa possível.

Problemas do Modelo espiral. O modelo em espiral, por suas características de avaliação e planejamento baseadas em risco, exige que se tenha gerentes e técnicos experientes. As tarefas gerenciais para acompanhamento e controle do projeto tornam-se mais difíceis, uma vez que o modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado. É necessário o uso de técnicas específicas para estimar e sincronizar cronograma.


Conclusão: O modelo Espiral é uma de versões incrementais gera o software no bom estilo do modelo incremental. A cada ciclo, versões progressivamente mais completas do software são construídas. Ajustes ao plano do projeto são feitas a cada passagem pela região de planejamento. Os gerentes de projeto ajustam o custo, o cronograma e a quantidade de iterações que completarão o projeto através da avaliação do cliente. Dessa forma, observa-se que o modelo espiral acrescenta aspectos gerenciais ao processo de desenvolvimento de software (análise de riscos, planejamento, controle, tomada de decisão), redução de riscos antes que os mesmos fiquem problemáticos, usa a prototipagem como mecanismo de redução de riscos e pode ser adaptado às necessidades de cada projeto.

Referências: https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/85816/233634.pdf?sequence=1&isAllowed=y https://edisciplinas.usp.br/pluginfile.php/839466/mod_resource/content/1/Aula02_ModelosProcessos.pdf https://www1.univap.br/prado/disciplina/engsoft-I/notasdeaula/curso/part1/cap2/cap2.htm

  • Pesquisa : Franklin Piauhy Neto


Material de apoio

Original:

  • Schach, Stephen R. Engenharia de Software: Os Paradigmas Clássico e Orientado a Objetos. McGraw Hill. 7.ed. 2010.
  • Alves, Rafael Ferreira . Vanalle, Rosângela Maria. Ciclo de vida de desenvolvimento de sistemas - Visão conceitual dos modelos clássico, espiral e prototipação. Unimep.

Cópias:

Disponível em “http://3.143.69.156/wiki/index.php?title=GGI033_-_Aula_03_-_2019-2&oldid=70971”