wiki

GGI033 - Aula 03 - 2020-1

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.


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


Pesquisa: Quais os princípios, características e vantagens deste modelo
Pesquisador: ??
Data: 25/03/2020


Modelo Espiral vs Incremental


Pesquisa: Comparar os dois modelos
Pesquisador: ??
Data: 25/03/2020

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_-_2020-1&oldid=74112”