Saga na construção de um SI
Paradigmas da Engenharia de Software
- São vários os paradigmas que cercam a arte de desenvolver um SI. Podemos encarar isso de 3 formas:
- Considerar um programa como dito acima, como uma "arte", o desenvolvedor é entende que está criando uma obra pessoal e eventualmente não segue alguns preceitos que levam a uma boa qualidade do software. Para sistemas pequenos ainda é possível mas para sistemas maiores é totalmente inviável, mesmo porque requer um grupo para sua conclusão e não apenas uma pessoa
- Assumir a criação de um programa como um método matemático a ser implantado visto que deveremos tratar de algoritmos escritos em alguma linguagem já que a intenção é resolver problemas, sendo assim, totalmente inserido dentro do contexto de métodos formais matemáticos.
- Entender que por trás de um SI temos que impor métodos e técnicas formais que são a base da Engenharia e que assim podemos projetar um sistema.
- Abaixo, são mostrados alguns caminhos que podem ser utilizados pelos desenvolvedores para obterem SIs com eficiência, qualidade e escalabilidade.
Desenvolvimento Caótico
- O produto é construído sem qualquer especificação ou projeto
- 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 contra indicado.
- 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 seqüencialmente, ou seja, uma após o término da outra.
- Todo projeto desenvolvido é executado mediante algum método 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.
- Fonte: Alves, Vanalle. Unimep. Ciclo de vida de desenvolvimento de sistemas
- 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.
- Nada está terminado até que se complete todas as fases
- 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 sequencial 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 (Mockup) 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 (open-source) 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.
- Fonte: Centraldaengenharia/2011/02/09/paradigmas-prototipacao/
- 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.
- Sistemas reais têm a intenção de uso operacional e devem seguir determinados padrões no que diz respeito a sua:
- 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 abrange as melhores características do modelo Clássico e da Prototipação, acrescentando um novo elemento:
- a análise dos riscos, inexistentes nos outros dois modelos
- Um fator muito importante no modelo Espiral é que cada ciclo é completado com uma revisão, na presença de pessoas chave para o produto em desenvolvimento
- Esta revisão mostra tudo o que foi desenvolvido durante o ciclo previsto, incluindo os planos para a próxima etapa a ser realizada
- O modelo em espiral é representado por um plano dividido em 4 quadrantes (figura abaixo), onde cada um deles contém uma fase cíclica do trabalho de desenvolvimento
- Esse plano é percorrido por uma linha espiral, que nasce no centro do plano (momento zero do trabalho de desenvolvimento), e que tem prosseguimento caminhando do centro para as bordas, sempre passando pelas 4 fases cíclicas, de tal forma que um ciclo se repete após o outro, até que o trabalho seja dado como concluído.
- Define quatro atividades principais:
- Planejamento: é a determinação dos objetivos, alternativas e restrições do projeto.
- Análise dos Riscos: é a análise das alternativas e a resolução dos riscos.
- Engenharia: desenvolvimento do produto.
- Avaliação feita pelo Cliente: é a avaliação dos resultados obtidos nas atividades da engenharia.
- Analisando a figura, observa-se que a cada iteração ao redor da espiral, iniciando-se ao centro e avançando para fora, versões mais completas do sistema são construídas.
- Durante o primeiro giro ao redor da espiral são definidos:
- objetivos
- alternativas
- restrições
- Também são identificados e analisados os riscos. Se a análise dos riscos detectar incertezas nos requisitos, deve-se fazer uso da prototipação no quadrante Engenharia, para auxiliar tanto o desenvolvedor como o usuário
- Para definir ainda mais o problema e refinar os requisitos, o desenvolvedor pode utilizar simulações e outros modelos.
- No quadrante de Avaliação, o cliente avalia o trabalho de Engenharia e apresenta suas sugestões para modificações
- A partir dessas sugestões ocorre a fase de Planejamento e Análise dos Riscos
- A conclusão da Análise dos Riscos resulta em uma decisão de prosseguir ou não o projeto.
- Caso os riscos sejam muito grandes, o projeto pode até ser encerrado.
- Fonte: Alves, Vanalle. Unimep. Ciclo de vida de desenvolvimento de sistemas
- Algumas vantagens desse modelo:
- Focaliza a atenção nas razões envolvidas com a existência do sistema
- Os passos envolvendo a identificação e a evolução de alternativas estimula estas opções.
- Prepara acomodações para a evolução do ciclo de vida , crescimento e alterações do produto do sistema.
- Fornece um mecanismo para qualidade e objetivos dentro do sistema desenvolvido
- Este mecanismo identifica todos os tipos de objetivos e regras durante cada roda do modelo espiral.
- Para cada atividade do projeto a seguinte pergunta deve ser feita “Isto é suficiente ?” , podendo assim ser avaliada a análise, o planejamento, a qualidade, os testes, as verificações formais, etc.
- O modelo pode ser aplicado com sucesso em algumas situações, mas algumas dificuldades podem ocorrer:
- Focaliza a atenção nas razões envolvidas com a existência do sistema
- O modelo Espiral trabalha bem com sistemas desenvolvidos dentro da própria empresa, mas os sistemas terceirizados não possuem a mesma flexibilidade para obter alterações possíveis.
- Em geral, os passos do processo do modelo Espiral necessitam que todos os participantes do desenvolvimento do sistema estejam operando conscientemente no contexto. Alguns exemplos disso são os detalhes que devem aparecer mais minuciosamente, os objetivos, as técnicas para estimar e sincronizar o esquema do projeto.
- Considerações:
- a) A avaliação de risco do modelo Espiral é mais adaptado às situações do projeto do que no modelo clássico.
- b) O modelo Espiral obtém muito sucesso para grandes aplicações.
- c) Ele não é ainda conhecido como o modelo mais elaborado. Pode ser aplicado por pessoas experientes, mas ele precisa adicionar a elaboração de todas as regras, especificações, revisões e situações de riscos de todas as áreas, para ser usado em todas as situações.
- d) A implementação parcial do modelo Espiral, como gerenciamento da avaliação de riscos, são compatíveis com mais modelos de processos e muito útil para visualizar riscos do projeto.
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
- Fonte: Centraldaengenharia/2011/02/09/paradigmas-prototipacao/
- 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 evoluído 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.
RAD
- O RAD - Rápido Desenvolvimento de Aplicações, 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.
- Fonte: tecnoblog.net/meiobit/16214
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
- O Modelo Incremental combina elementos do modelo seqüencial linear com a filosofia iterativa da prototipagem, além de aplicar seqüências lineares de uma forma racional à medida que o tempo passa.
- O Modelo Espiral combina a iteratividade da prototipagem com os aspectos controlados e sistemáticos do modelo seqüencial linear e considera a perspectiva da análise de risco.
- No final, o modelo Espiral é um processo com um nível de formalidade maior de execução, pois divide-se em tarefas distintas em vez de incrementos.
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.