A maior rede de estudos do Brasil

Grátis
182 pág.
Apostila ENGENHARIA DE SOFTWARE unicesumar

Pré-visualização | Página 8 de 38

do usuário, acaba demorando mais 
tempo para ser desenvolvido do que o previsto, aumentando assim, o valor do 
custo do software.
As atividades mencionadas por Sommerville podem ser organizadas pelas 
empresas da forma como ela achar melhor, porém, é importante ressaltar que 
todas essas atividades são de extrema importância e o processo de software ado-
tado pela empresa não deve deixar de considerar nenhuma das etapas.
É importante ressaltar que mesmo as empresas que possuem um processo 
de software bem definido e documentado, para determinados softwares que ela 
desenvolve, pode ser utilizado outro processo de software, ou seja, dependendo 
do software a ser desenvolvido, pode ser utilizado um determinado processo de 
software. Na próxima seção, veremos alguns modelos de processo de software e 
veremos também que é possível a empresa adotar um processo de software pró-
prio, que atenda suas necessidades.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E40
MODELOS DE PROCESSO DE SOFTWARE
Como foi discutido anteriormente, um processo de software é composto por um 
conjunto de etapas que são necessárias para que seja produzido. Sommerville 
(2007) afirma que um modelo de processo de software é uma representação abs-
trata, simplificada de um processo de software. Os modelos de processo incluem 
as atividades que fazem parte do processo de software (você está lembrado das 
atividades descritas no item anterior?), os artefatos de software que devem ser 
produzidos em cada uma das atividades (documentos) e também os papéis das 
pessoas envolvidas na engenharia de software. Além disso, cada modelo de pro-
cesso representa um processo a partir de uma perspectiva particular, de uma 
maneira que proporciona apenas informações parciais sobre o processo.
Na literatura, existem diversos modelos de processo de software. Aqui, irei 
mostrar somente três desses modelos e, em seguida, mostrarei as atividades básicas 
que estão presentes em, praticamente, todos os modelos de processos de software. 
Os modelos de processo que mostrarei foram retirados de Sommerville 
(2011, p.20) e são:
1. Modelo em Cascata: esse modelo considera as atividades de especifi-
cação, desenvolvimento, validação e evolução, que são fundamentais ao 
processo e as representa como fases separadas, como a especificação de 
requisitos, o projeto de software, a implementação, os testes e assim por 
diante (SOMMERVILLE, 2011).
2. Desenvolvimento Incremental. esse modelo intercala as atividades de 
especificação, desenvolvimento e validação. Um sistema inicial é rapida-
mente desenvolvido a partir de especificações abstratas, que são refinadas 
com informações do cliente, para produzir um sistema que satisfaça suas 
necessidades, produzindo várias versões do software (SOMMERVILLE, 
2011).
3. Engenharia de Software Orientada a Reuso: esse modelo parte do prin-
cípio de que existem muitos componentes que podem ser reutilizáveis. 
O processo de desenvolvimento do sistema se concentra em combi-
nar vários desses componentes em um sistema, em vez de proceder ao 
desenvolvimento a partir do zero, com o objetivo de reduzir o tempo de 
desenvolvimento (SOMMERVILLE, 2011).
©shutterstock
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
41
O MODELO EM CASCATA
O modelo cascata ou ciclo de vida clássico, 
considerado o paradigma mais antigo da 
engenharia de software, sugere uma abor-
dagem sequencial e sistemática para o 
desenvolvimento de software, começando 
com a definição dos requisitos por parte do 
cliente, avançando pelas atividades de projeto 
e implementação de software, testes, implan-
tação, culminando no suporte contínuo do 
software concluído. 
Segundo Sommerville (2007, p. 44), os 
principais estágios do modelo em cascata demonstram as atividades fundamen-
tais do desenvolvimento:
1. Análise e definição de requisitos: as funções, as restrições e os objeti-
vos do sistema são estabelecidos por meio da consulta aos usuários do 
sistema. Em seguida, são definidos em detalhes e servem como uma espe-
cificação do sistema.
2. Projeto de sistemas e de software: o processo de projeto de sistemas 
agrupa os requisitos em sistemas de hardware ou de software. Ele esta-
belece uma arquitetura do sistema geral. O projeto de software envolve 
a identificação e a descrição das abstrações fundamentais do sistema de 
software e suas relações.
3. Implementação e teste de unidades: durante esse estágio, o projeto de 
software é compreendido como um conjunto de programas ou unida-
des de programa. O teste de unidades envolve verificar que cada unidade 
atenda a sua especificação.
4. Integração e teste de sistemas: as unidades de programa ou programas 
individuais são integrados e testados como um sistema completo a fim de 
garantir que os requisitos de software foram atendidos. Depois dos tes-
tes, o sistema de software é entregue ao cliente.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E42
5. Operação e manutenção: normalmente (embora não necessariamente), 
esta é a fase mais longa do ciclo de vida. O sistema é instalado e colo-
cado em operação. A manutenção envolve corrigir erros que não foram 
descobertos em estágios anteriores do ciclo de vida, melhorando a imple-
mentação das unidades de sistema e aumentando as funções desse sistema 
à medida que novos requisitos são descobertos.
Um estágio somente pode ser iniciado depois que o estágio anterior tenha sido 
concluído. Porém, Sommerville (2011, p. 21) afirma que na prática esses está-
gios acabam se sobrepondo, alimentando uns aos outros de informações. Por 
exemplo, durante o projeto, os problemas com os requisitos são identificados. 
O que acontece é que um processo de software não é um modelo linear simples, 
sequencial, mas envolve iterações entre as fases. Os artefatos de software que são 
produzidos em cada uma dessas fases podem ser modificados para refletirem 
todas as alterações realizadas em cada um deles.
Pressman (2011) aponta alguns problemas que podem ser encontrados 
quando o modelo cascata é aplicado:
1. Os projetos que acontecem nas empresas dificilmente seguem o fluxo 
sequencial proposto pelo modelo. Alguma iteração sempre ocorre e traz 
problemas na aplicação do paradigma.
2. Na maioria das vezes, o cliente não consegue definir claramente todas as 
suas necessidades e o modelo cascata requer essa definição no início das 
atividades. Portanto, esse modelo tem dificuldade em acomodar a incer-
teza natural que existe no começo de muitos projetos.
3. Uma versão operacional do sistema somente estará disponível no final do 
projeto, ou seja, o cliente não terá nenhum contato com o sistema durante 
o seu desenvolvimento. Isso leva a crer que se algum erro grave não for 
detectado durante o desenvolvimento, o sistema não atenderá de forma 
plena as necessidades do cliente.
Segundo Sommerville (2011) e Pressman (2011), o modelo em cascata deve 
ser utilizado somente quando os requisitos são fixos e tenham pouca probabi-
lidade de serem alterados durante o desenvolvimento do sistema e o trabalho 
deve ser realizado até sua finalização de forma linear. Sommerville (2011, p.21) 
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
43
ainda afirma que “o modelo cascata reflete o tipo de processo usado em outros 
projetos de engenharia. Como é mais fácil usar um modelo