Engenharia de Software - OS PARADIGMAS DA ENGENHARIA DE SOFTWARE

Um paradigma de engenharia de software é escolhido tendo como base: a natureza do
projeto e da aplicação, os métodos e as ferramentas a serem usadas, os controles e os
produtos que precisam ser entregues ao usuário.
3.1 O Ciclo de Vida Clássico
São utilizados conceitos de Engenharia de Software, a qual prevê atividade de verificação
(estamos fazendo o produto de forma correta?), validação (estamos fazendo o produto certo?)
e de controle de qualidade. É um paradigma que utiliza um método sistemático e seqüêncial
em que o resultado de uma fase se constitui na entrada de outra.
As vezes chamado de modelo cascata, este paradigma abrange atividades (ou ciclos) de:
• Engenharia de Software: quanto mais dados forem coletados em nível de sistema,
menor será a probabilidade de haver "bugs" no sistema, consequentemente diminuirá
os futuros reparos no mesmo. Também conhecido como estudo de viabilidade.
• Análise e Especificação de Requisitos de software: é importante saber o que o
cliente quer que o software tenha, com relação à recursos. Os requisitos devem ser
documentados e revistos com
o cliente antes de começar a
execução do projeto.
• Projeto: envolve muitos
passos que se concentram em
4 atributos distintos do
programa: estrutura de dados,
arquitetura de software,
detalhes procedimentais e
caracterização de interface. O
processo de feitura do projeto
traduz quanto à qualidade
antes de iniciar a codificação.
• Codificação: o projeto deve
ser transformado em programa,
usando uma linguagem de programação, isto é, traduzido numa linguagem de
máquina.
• Testes e Integração do sistema: deve-se testar todas os programas a procura de
erros. A Integração consiste das junções das várias unidades e programas
desenvolvidos. O resultado real deve concordar com o projeto ou resultado exigido.
Depois de testado, o software é entregue ao usuário.
• Manutenção e Operação: o sistema é instalado e colocado em uso, indubitavelmente
o software sofrerá mudanças depois que foi entregue ao cliente, e, mesmo software
embutido sofre upgrade de tempos em tempos. A manutenção ocorre basicamente
com a correção de erros não detectados (manutenção corretiva), com a adaptação da
aplicação às mudanças do ambiente (manutenção adaptativa) e na adição de novas
características e qualidades do software (manutenção evolutiva).
O ciclo de vida clássico é o paradigma mais antigo e o mais amplamente usado em
Engenharia de Software, mesmo assim surgirão, ou surgem problemas como: Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 23
Fim Início
Avaliação do
Protótipo pelo
Cliente
Construção
do
Protótipo
Projeto
Rápido
Coleta e
refinamento
dos requisitos
 Engenharia
 do
 Produto
Refinamento
do Produto
• Os projetos reais raramente seguem o fluxo sequencial que o modelo propõe.
• O cliente, amiúde, não saberá declarar todas as suas exigências.
• O cliente deve ter paciência, pois qualquer erro detectado após a revisão do programa
de trabalho pode ser desastroso.
Os problemas são reais, mas, mesmo assim o ciclo de vida clássico continua sendo o mais
usado no desenvolvimento de software. Este modelo é apropriado para sistemas transacionais
onde as rotinas e procedimentos a serem automatizados são altamente estruturados. A
principal desvantagem desta abordagem é o alto custo de correção das especificações quando
nas fases de Teste e Implantação..
3.2 Prototipação
Muitas vezes, as dúvidas do cliente e do programador, em relação ao software, levam ao
processo de prototipação. A prototipação capacita o desenvolvedor a criar um modelo de
software que será implementado. O objetivo é antecipar ao usuário final um modelo de sistema
para que ele possa avaliar sua finalidade, identificar erros e omissões, quando em utilização,
efetuando de imediato correções e ajustes. O modelo pode assumir uma das três formas
citadas:
• Um protótipo em papel ou em PC, que retrata a interação homem máquina, podendo
ver quantas interação haverá.
• Um protótipo que implemente funções específicas, da função exigida pelo software.
• Um programa existente que executa parte ou toda a função desejada, mas que tem
características que deverão ser melhoradas.
Como todas as abordagens ao
desenvolvimento de software, a
prototipação inicia-se com a coleta de
requisitos. Faz-se então um projeto
rápido contendo os aspectos que serão
visíveis ao cliente. O projeto rápido leva
à construção de um protótipo, que,
será avaliado pelo cliente/usuário.
Esta avaliação será usada para
refinar requisitos para o software
desenvolvido.
Idealmente, o protótipo serve
como um mecanismo para identificar
os requisitos de software. Muitas
vezes, é preciso descartar um
protótipo e, partir do início para evitar
perda de tempo com correções.
Esse paradigma pode apresentar
problemas pelas seguintes razões:
• O cliente quer resultados, e, muitas vezes
não saberá, ou não entenderá, que um protótipo
pode estar longe do software ideal, que ele nem sequer imagina como é. Mesmo Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 24
assim, a gerência de desenvolvimento cede às reclamações e tenta encurtar o prazo
de entrega, o qual já estava prolongado.
• O desenvolvedor, na pressa de colocar um protótipo em funcionamento, é levado a
usar um SO ou linguagem de programação imprópria por simplesmente estar a
disposição ou estar mais familiarizado. Essa atitude poderá levar à um algoritmo
ineficiente.
A filosofia de protótipos possui as seguintes vantagens:
• Maior garantia de sucesso técnico e psicológico;
• Redução no fator tempo: "O usuário gosta de ver o sistema funcionando";
• Ideal para sistemas gerenciais e de apoio a decisão.
Como desvantagens tem-se:
• Exige elevada capacitação gerencial por parte da equipe do projeto;
• Aparentemente, mais dispendioso (a longo prazo esta desvantagem tende a
desaparecer);
• Exige uma ferramenta apropriada de prototipação.
O protótipo é baseado no feedback dos usuários, devido a isso mudanças são feitas no
protótipo. Dependendo do comentário dos usuários, estas mudanças podem ser menores, de
modo que alterem formatos, ou podem ser maiores, de modo que são requeridas mudanças
estruturais no protótipo.
Ainda que possam ocorrer problemas, o uso da prototipação é um paradigma eficiente na
Engenharia de Software. O segredo é o entendimento entre o desenvolvedor e o cliente.
3.3 O Modelo Espiral
Foi desenvolvido para abranger as melhores características do ciclo de vida clássico e da
prototipação, ao mesmo tempo que adiciona um novo elemento, que é a análise de risco. Este
modelo de ciclo de vida se utiliza de protótipos por se adequar muito bem com esta filosofia de
desenvolvimento. Cada passo através do ciclo inclui: planejamento, análise e projeto,
prototipação e avaliação. Os passos vão sendo repetidos até que um produto seja obtido.
Sendo assim definiu-se 4 importantes atividades:
• Planejamento, determinação de objetivos, alternativas e restrições do ciclo,
considerando os resultados do ciclo anterior ou da análise dos requisitos.
• Análise dos riscos, análise das alternativas e identificação (resolução) dos riscos.
• Engenharia, Desenvolvimento e verificação da solução escolhida.
• Avaliação do Cliente, avaliação dos resultados e planejamento do ciclo seguinte.
Os riscos são circunstancias adversas que podem atrapalhar o processo de
desenvolvimento e a qualidade do produto a ser desenvolvido, assim é possível prever e
eliminar os problemas de alto risco através de um planejamento e projetos cuidadosos. Este é
um modelo que atende os seguintes casos:
• o problema a ser resolvido não está totalmente entendido;
• a realidade pode mudar enquanto o sistema está sendo desenvolvido;
• a própria solução adotada pode ter algum efeito colateral desconhecido;
• a preocupação está centrada mais na qualidade e funcionalidade do que se produz. Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 25
Com base na experiência adquirida com a primeira versão, estabelecem-se novos
requisitos para o sistema, e uma nova versão é concebida e implementada. A prototipação no
ciclo de vida espiral tem como objetivos:
• estabelecer um diálogo intensivo entre usuários e analistas/projetistas;
• encurtar ao máximo o ciclo "concepção-implementação-utilização-avaliação" do
sistema;
• possibilitar a evolução do sistema através de vários ciclos ou refinamentos sucessivos;
• avaliar constantemente o sistema.
Baseado principalmente em decisões de prosseguir / não prosseguir, de acordo com a
avaliação, seja do cliente ou do desenvolvedor, o modelo espiral tende à uma trajetória que
ruma para o modelo mais completo do sistema.
O paradigma de modelo espiral, é atualmente a abordagem mais realista para o
desenvolvimento de softwares e sistemas em grande escala. Ele usa uma abordagem
"evolucionária", capacitando o desenvolvedor e o cliente a entender e reagir aos riscos, em
cada etapa evolutiva da espiral. Usa a prototipação como um mecanismo de redução de riscos,
e a mesma pode ser aplicada em qualquer ponto evolutivo. Porém, pode ser difícil convencer
grandes clientes de que a abordagem evolutiva é controlável. Se um grande risco não for
descoberto, com certeza ocorrerão problemas.
Esse paradigma é relativamente novo, e não tem sido amplamente usado como os 2
paradigmas anteriormente explicados. Somente o tempo, que gera a experiência, poderá
comprovar a eficácia do modelo espiral.
3.4 Técnicas de 4a Geração (4GT)
Abrange um amplo conjunto de ferramentas para o desenvolvimento de software que tem
uma coisa em comum: cada uma delas possibilita que o desenvolvedor especifique alguma
característica do software num nível elevado. O código fonte é gerado automaticamente, tendo
por base a especificação do desenvolvedor. Praticamente pode-se dizer à máquina, em Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 26
linguagem natural, as especificações que se quer para o software.
O paradigma 4GT possibilita
resultados em um pequeno período de
tempo. A parte de codificação, geração de
telas, relatórios, consultas, em fim a
programação propriamente dita, se torna
automatizada. A parte considerada difícil,
ou mesmo rotineira, seria a coleta de
dados com o cliente. Saber o que o cliente
quer, ainda é o principal problema de
todos os paradigmas. Com a utilização de
4GL, talvez seja possível passar da coleta
diretamente para a implementação.
Porém, mesmo usando uma 4GL, é
preciso fazer um planejamento do sistema,
para evitar problemas de má qualidade,
manutebilidade ruim e má aceitação do
cliente.
Ferramentas como o Access, da Microsoft, podem fazer "milagres" pelo programador.
Porém, para transformar uma 4GT em um produto, o desenvolvedor deve desenvolver testes
cuidadosos e uma documentação significativa, além de executar todas as demais atividades de
"transição", que os paradigmas anteriores executam. O sistema deverá possibilitar rápida
manutenção.
Os opositores do paradigma 4GT, afirmam que tais ferramentas são insuficientes e que a
manutebilidade de grandes sistemas de software desenvolvidos pelas 4GT estão abertas a
questionamentos.
A prós e contras na discussão sobre este paradigma:
• Com raras exceções as 4GT’s se limitam a aplicações de sistemas de informação
comercial. Mas, utilizando ferramentas CASE, que agora suportam o uso das 4GT’s,
para a geração automática de esqueleto de código para as aplicações de engenharia
em tempo real.
• Os dados preliminares, coletados em empresas que estão usando 4GT parecem
indicar redução na quantidade de planejamento e análise para aplicações pequenas e
intermediárias.
• Entretanto, o uso das 4GTs ainda exige tanto ou mais análise, planejamento e teste.
A projeção é que a demanda de software continue em ascensão, mas, que os paradigmas
convencionais perderão espaço no mercado de desenvolvimento, para as 4GTs.
3.5 Modelo por incremento
Nos modelos por incremento, também chamado de modelo evolutivo, um único conjunto de
componentes é desenvolvido simultaneamente, num primeiro tempo o núcleo do software e
depois os incrementos vão sendo agregados.
As atividades de desenvolvimento e validação são desempenhadas paralelamente, com
um rápido feedback entre elas. O processo de desenvolvimento de cada incremento é
realizado usando um processo clássico dos já estudados anteriormente.
As vantagens são:
• Cada desenvolvimento é menos complexo.
Coleta de
Requisitos
 Estratégia de
Projeto
Implementação
usando 4GL
Testes Engenharia de Software
Prof. Walteno Martins Parreira Jr Página 27
• As integrações são progressivas.
• A cada interação, uma nova versão do produto pode ser distribuída.
Os riscos são:
• Os problemas no núcleo do software, inviabilizando novos incrementos, e
determinando o fim do ciclo de vida do software.
• Incapacidade de integrar novos incrementos
São usados em grandes projetos e também em softwares desenvolvidos para distribuição
em grande escala, por permitir evolução e melhorias sem descaracterizar o software.
3.6 Combinando
Paradigmas
Os paradigmas podem e
devem ser combinados de forma
que as potencialidades de cada
um, possam ser utilizados em
um único projeto. Qualquer
paradigma pode constituir a base
a qual os outros poderão ser
integrados.
O processo começa com a
determinação dos objetivos,
alternativas e restrições e depois
disso, qualquer caminho pode
ser tomado. A natureza da
aplicação é que vai determinar o
paradigma a ser utilizado, e a
combinação de paradigmas só
tende a beneficiar o processo
como um todo