09 - Modelos de Processo de Software PDF

Engenharia de Software
Gilson de Souza Carvalho

gaucho.gilson@hotmail.com
Modelos de Processo de Software
4.1.1 O Modelo em Cascata
O primeiro modelo de processo de desenvolvimento de
software publicado originou-se de processos mais gerais
de sistema (Royce, 1970). Isso mostrado na Figura 4.1.
Devido ao encadeamento de uma fase com outra, esse
modelo conhecido como modelo em cascata ou ciclo de
vida do software. Os principais estgios do modelo
demonstram
as
atividades
fundamentais
de
desenvolvimento.
1. Analise e definio de requisitos. Os servios, restries
e objetivos do sistema so definidos por meio de consultas
aos usurios do sistema. Eles so, portanto, definidos
detalhadamente e servem como uma especificao do
sistema.
2. Projeto de Sistema e Software. O processo de projeto
de sistema divide os requisitos em sistemas de hardware
ou de software. Ele estabelece um arquitetura geral do
sistema. O projeto de software envolve a identificao e
descrio das abstraes fundamentais do sistema de
software e suas relaes.
3. Implementao e teste de unidade. Durante este
estagio, o projeto de software realizado com um
conjunto de programas ou unidades de programas. O teste
unitrio envolve a verificao de que cada unidade atende
a sua especificao.
4. Integrao e teste de sistema. As unidades individuais
de programa so integrados e testados como um sistema
completo para garantir que os requisitos de software
foram atendidos. Aps os testes , o sistema de software
liberado para o cliente.
5. Operao e manuteno. Geralmente (embora no
necessariamente) esta a fase mais longa do ciclo de vida.
O sistema instalado e colocado em operao. A
manuteno envolve a correo de erros no detectados
nos estgios anteriores do ciclo de vida, no aprimoramento
da implementao das unidades de sistema e na
ampliao dos servios de sistema medida que novos
requisitos so identificados.
Figura 4.1
Em principio, o resultado de cada fase consiste de um ou
mais documentos aprovados (assinados). A fase seguinte
no deve comear antes que a fase anterior tenha
terminado. Na pratica, esses estgios se sobrepem e
trocam informaes entre si.
Durante o projeto, so identificados problemas com
requisitos; durante a codificao, so encontrados
problemas de projeto e assim por diante. O processo de
software no um modelo linear simples; envolve uma
sequencia
de
interaes
das
atividades
de
desenvolvimento.
Devido aos custos de produo e aprovao de
documentos, as interaes so onerosas e envolvem um
retrabalho significativo. Portanto, aps um pequeno
numero de interaes , normal suspender partes do
desenvolvimento, como a especificao, e prosseguir com
os estgios posteriores do desenvolvimento.
Os problemas so resolvidos posteriormente, ignorados
ou reprogramados. O congelamento prematuro de
requisitos pode significar que o sistema no far o que o
usurio deseja. Isso pode levar tambm a sistemas mal
estruturados, pois os problemas de projeto foram
contornados por meio de artifcios de implementao.
Durante a fase final do ciclo de vida (operao e
manuteno) , o software colocado em uso. Erros e
omisses nos requisitos originais de software so
descobertos. Os erros de programao e projeto emergem
e a necessidade de novas funcionalidades identificada. O
sistema deve, portanto, evoluir para permanecer util. Essas
mudanas (manuteno de software) podem implicar
repetio de estgios anteriores do processo.
As vantagens do modelo em cascata consiste na
documentao produzida em cada fase e sua aderncia a
outros modelos de processo de engenharia. Seu maior
problema a diviso inflexvel do projeto em estgios
distintos. Os compromissos devem ser assumidos no
estagio inicial do processo, o que torna difcil reagir as
mudanas de requisitos do usurio.
Portanto, o modelo em cascata deve ser usado apenas
quando os requisitos forem bem compreendidos e houver
pouca probabilidade de mudanas radicais durante o
desenvolvimento do sistema. No entanto, o modelo em
cascata reflete o tipo de modelo de processo usado em
outros projetos de engenharia. Consequentemente,
processos de softwares baseados nessa abordagem so
ainda usados
para desenvolvimento de software,
particularmente quando fazem parte de um projeto maior
de engenharia de sistemas.
4.1.2 Desenvolvimento Evolucionrio
O desenvolvimento evolucionrio baseia-se na ideia de

uma implementao inicial, expondo o resultado aos
comentrios do usurio e refinando esse resultado por
meio de varias verses ate que seja desenvolvido um
sistema adequado (Figura 4.2)
Figura 4.2
As atividades de especificao, desenvolvimento e
validao so intercaladas, em vez de serem separadas,
com feedback rpido que permeia as atividades.
Existem dois tipos fundamentais de desenvolvimento
evolucionrio:
Desenvolvimento exploratrio, no qual o objetivo do
processo trabalhar com o cliente para explorar os
requisitos e entregar um sistema final. O desenvolvimento
comea com as partes do sistema compreendidas. O
sistema evolui por meio da adio de novas caractersticas
propostas pelo cliente.
Prototipao throwaway, na qual o objetivo do processo
de desenvolvimento evolucionrio compreender os
requisitos do cliente e, a partir disso, desenvolver melhor
definio de requisitos para o sistema. O prottipo se
concentra na experimentao dos requisitos mal
compreendidos pelo clientes.
Uma abordagem evolucionaria para desenvolvimento de
software frequentemente mais eficaz que a abordagem
em cascata na produo de sistemas que atendem as
necessidades imediatas dos clientes. A vantagem de um
processo de software baseado
na abordagem
evolucionaria que a especificao pode ser desenvolvida
de forma incremental.
A medida que os usurios compreendem melhor seu
problema , isso pode ser refletido no sistema de software.
No entanto, do ponto de vista da engenharia e do
gerenciamento, a abordagem evolucionaria tem dois
problemas:
O processo no visvel. Os gerente precisam de produtos
regulares para medir o progresso. Se os sistemas so
desenvolvidos rapidamente , no vivel economicamente
produzir documentos que reflitam cada verso do sistema.
Os sistemas so frequentemente mal estruturados. A
mudana continua tende a corromper a estrutura do
software . A incorporao de mudanas de software
tornar-se cada vez mais difcil e onerosa.
Para sistemas de pequeno e mdio porte (ate 500 mil
linhas de cdigo), penso que a abordagem evolucionaria
seja o melhor mtodo de desenvolvimento. Os problemas
de
desenvolvimento
evolucionrio
tornam-se
particularmente graves para sistemas complexos de grande
porte e de longo ciclo de vida, nos quais diversas equipes
desenvolvem diferentes partes do sistema. difcil
estabelecer uma arquitetura estvel do sistema usando
essa abordagem, o que torna difcil integrar as
contribuies das equipes.
Para sistemas de grande porte, recomendo um processo
misto que incorpore as melhores caractersticas dos
modelos de desenvolvimento em cascata e evolucionrio.
Isso pode envolver o desenvolvimento de um prottipo
throwaway, usando uma abordagem evolucionaria para
resolver as incertezas na especificao do sistema. Voc
pode, portanto, reimplementar o sistema usando uma
abordagem mais estruturada.
As partes do sistema bem compreendidas podem ser
especificadas e desenvolvidas usando um processo
baseado em cascata. Outras partes do sistema, tais como
interface com o usurio, que so difceis de serem
especificadas antecipadamente, devem ser sempre
desenvolvidas usando um abordagem de programao
exploratria.
4.1.3 Engenharia de software baseada em componentes
Na maioria dos projetos de software , existe algum reuso
de software. Isso ocorre geralmente de maneira informal,
quando as pessoas que trabalham no projeto conhecem os
projetos ou cdigos similares aos necessrios. Elas
procuram por esses produtos, os modificam e os
incorporam ao sistema. Na abordagem evolucionaria, o
reuso frequentemente essencial para o desenvolvimento
rpido do sistema.
Esse reuso informal ocorre independente do processo de
desenvolvimento usado. No entanto, nos ltimos anos,
uma abordagem para desenvolvimento de software,
denominada engenharia de software baseada em
componentes (CBSE Component Based Software
Engineering) e que conta com reuso, tem emergido e se
tornar cada vez mais utilizada
A abordagem orientada a reuso depende de uma grande
base de componentes de software reusveis e algum
framework de integrao desses componentes. Algumas
vezes, esses componentes so sistemas comerciais
independentes
(COTS ou Commercial Off-The-Shelf
Systems) que podem fornecer funcionalidade especifica,
como a formatao de texto ou um calculo numrico. O
modelo genrico de processo para CBSE mostrado na
Figura 4.3.
Figura 4.3
Embora o estagio de especificao inicial de requisitos e o
estagio de validao sejam comparveis ao outros
processos, os estgios intermedirios em um processo
orientado a reuso so diferentes. Esses estgios so:
1. Analise de componentes. Dada uma especificao de
requisitos, feito uma busca por componentes para
implementar esta especificao. Geralmente, no existe
uma correspondncia exata e os componentes que podem
ser usados fornecem apenas parte da funcionalidade
necessria.
2. Modificao de requisitos. Durante esse estagio, os
requisitos so analisados usando as informaes sobre os
componentes encontrados. Eles so modificados para
refletir os componentes disponveis. Quando as
modificaes so impossveis, a atividade de analise de
componentes pode ser novamente realizada para procurar
solues alternativas.
3. Projeto de sistema com reuso. Durante esse estgio, o
framework do sistema projetado ou um framework
existe reusada. Os projetistas levam em considerao os
componentes reusados, organizando o framework para
eles. Pode ser necessrio projetar algum software novo
caso os componentes reusveis no estejam disponveis.
4. Desenvolvimento e Integrao. O software que no
pode ser adquirido externamente desenvolvido e os
componentes e os sistemas COTS so integrados para criar
o novo sistema. A integrao de sistema, nesse modelo,
pode ser parte do processo de desenvolvimento, em vez
de ser uma atividade separada.
A engenharia de software baseada em componentes tem a
vantagem obvia de reduzir a quantidade de software a ser
desenvolvido e, dessa maneira, reduzir os custos e riscos.
Isso tambm leva geralmente a uma entrega mais rpida
de software.
No entanto, compromissos com os requisitos so
inevitveis e isso pode levar a um sistema que no atenda
as reais necessidades dos usurios. Alm disso, algum
controle sobre a evoluo do sistema ser perdido se as
novas verses dos componentes reusveis no estiverem
sob controle da organizao que as utiliza.

09 - Modelos de Processo de Software PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

09 - Modelos de Processo de Software PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Engenharia de Software

Gilson de Souza Carvalho

O desenvolvimento evolucionrio baseia-se na ideia de

Das könnte Ihnen auch gefallen