Processo de Software

Núcleo de Educação a Distância

www.unigranrio.com.br
Rua Prof. José de Souza Herdy, 1.160
25 de Agosto – Duque de Caxias - RJ

Reitor Pró-Reitora Comunitária

Arody Cordeiro Herdy Sônia Regina Mendes

Pró-Reitor de Administração Acadêmica Pró-Reitora de Ensino de Graduação

Carlos de Oliveira Varella Hulda Cordeiro Herdy Ramim

Pró-Reitor de Pesquisa e Pós-Graduação Pró-Reitora de Pós-Graduação Lato Sensu e Extensão

Emilio Antonio Francischetti Nara Pires

Produção: Fábrica de Soluções Unigranrio Desenvolvimento do material: Rafael Maiani de Mello

Copyright © 2018, Unigranrio

Nenhuma parte deste material poderá ser reproduzida, transmitida e gravada, por qualquer meio eletrônico,
mecânico, por fotocópia e outros, sem a prévia autorização, por escrito, da Unigranrio.
Sumário
Processo de Software
Objetivos ........................................................................................... 04
Introdução ......................................................................................... 05
1. Engenharia de Software ........................................................ 06
2. Processo de Software ............................................................ 07
2.1 Modelo em Cascata .............................................................. 09
2.2 Modelo em V ....................................................................... 11
2.3 Modelo de Desenvolvimento Incremental ................................. 12
2.4 Rapid Application Development (RAD) ..................................... 15
2.5 Prototipação ........................................................................ 16
2.6 Modelo Espiral ..................................................................... 17
2.7 Modelo Iterativo e Incremental ............................................... 18
Síntese ............................................................................................. 20
Referências ....................................................................................... 21
Objetivos
Ao final desta unidade de aprendizagem, você será capaz de:

▪▪ Conceituar a Engenharia de Software;

▪▪ Conceituar Processo de Software;
▪▪ Apresentar e comparar os diferentes modelos de processo.

4 Arquitetura de Processos de Software

Introdução
A Engenharia de Software pode ser definida como a disciplina que se
ocupa dos aspectos da produção de software, visando à produção de produtos
de software de qualidade. Por sua natureza sociotécnica, a qualidade do
produto de software é fortemente influenciada por concepções humanas e
tecnológicas. Entretanto, o processo de software também é um importante
aspecto para proporcionar essa qualidade, na medida em que direciona os
esforços de produção. A literatura técnica apresenta diferentes modelos de
processo usados como referência para a definição de processos de software
adotados em projetos reais. Nesta unidade de aprendizagem, vamos conceituar
a engenharia de software e o seu processo. Em seguida, veremos como ela
apresenta e discute os modelos de processo de software mais difundidos na
literatura e adotados na indústria.

Arquitetura de Processos de Software 5

1. Engenharia de Software
Quando falamos em software, é natural pensarmos imediatamente em
um sistema ou aplicativo pronto para execução. No entanto, para chegarmos
a esse resultado (produto final), é necessário desenvolver e validar outros
artefatos, como especificações textuais, modelos e planos de testes. Nesse
sentido, o conceito de software é mais abrangente, englobando o conjunto
de programas de computador e toda a documentação a ele associada
(PRESSMAN, 2005).

Importante
É recomendável que todo artefato de software seja devidamente versionado, de modo a
facilitar a gestão de sua configuração e promover a sua manutenibilidade.

Por sua vez, a engenharia de software pode ser definida como a

disciplina que se ocupa de todos os aspectos da produção de software,
cobrindo desde a concepção do software até a sua futura manutenção.
Até os anos 1970, a influência da engenharia de software na indústria era
pequena. É importante lembrar que, até essa época, diversas tecnologias
consideradas corriqueiras hoje em dia, eram praticamente inexistentes:
terminais de autoatendimento, a Web, computadores pessoais e até mesmo
videogames. Documentos e relatórios organizacionais ainda eram preparados
em máquinas de escrever, e apenas as grandes organizações realizavam
algum tipo de processamento automatizado de dados, utilizando grandes
computadores centrais.

A partir dos anos 1970, veio à tona a chamada crise de software. Isso
porque surgiu uma crescente e acelerada demanda pelo desenvolvimento de
novos sistemas de software para apoiar diferentes finalidades. No entanto,
essa crescente demanda esbarrava em algumas grandes limitações da época,
como falta de visão de processo e produto, falta de pessoal qualificado,
carência de controle de qualidade da produção, carência de tecnologias de
suporte ao desenvolvimento. Tudo isso resultava em produtos com qualidade
frequentemente insatisfatória, não obstante o altíssimo custo de produção e o
significativo esforço de desenvolvimento investido.

6 Arquitetura de Processos de Software

 Saiba Mais
A engenharia de software é considerada uma disciplina recente. O estatístico John Tukey
cunhou a expressão “engenharia de software” em 1958. Dez anos depois, em 1968,
aconteceu a primeira conferência em engenharia de software, a NATO
– Software Engineering Conference. Esse ano ainda é considerado um
marco para a engenharia de software. Em 2018, é comemorado 50
anos da engenharia de software no ICSE, a Conferência Internacional
de Engenharia de Software. Especialmente, nessa ocasião, grandes
nomes da área fizeram memoráveis apresentações, discutindo a
história e o futuro da engenharia de software. Leia mais

A crise de software impulsionou o estabelecimento da disciplina de

engenharia de software como importante ferramenta para a promoção da
qualidade do produto final. Por meio dela, esforços foram somados para retirar o
desenvolvimento de software de uma prática predominantemente improvisada
e artesanal para um processo sistemático, mensurável e controlado. Assim,
foram se consolidando importantes atividades da área, como a especificação
de requisitos, a modelagem de software e os testes de software.

2. Processo de Software
Apesar do uso do termo Pessoas
“engenharia”, cabe destacar a natureza
sociotécnica da área. Isso significa que
tanto as tecnologias utilizadas quanto
os indivíduos alocados possuem grande
influência no desenvolvimento de software. QeP
Ignorar qualquer uma dessas naturezas
é, portanto, um risco ao sucesso de um
projeto. Entretanto, é importante também Processos Tecnologia
observar que a qualidade do produto de
software também depende de um terceiro Figura 1: Aspectos fundamentais da qualidade do
produto de software.
aspecto o processo.

Arquitetura de Processos de Software 7

 Importante
Além de tecnologia, pessoas e processo, Sommerville (2010) acrescenta, ainda, um
conjunto de fatores de gestão como um outro aspecto determinante da qualidade de
software, são eles: custo, tempo e cronograma. Entretanto, tais fatores podem ser
considerados como restrições aos demais aspectos considerados determinantes. Por exemplo,
os recursos financeiros disponíveis para determinado projeto podem levar à adoção de um
processo mais enxuto, o que pode incluir, por exemplo, o uso de tecnologias mais acessíveis
e a alocação de profissionais menos experientes.

Um processo de software pode ser considerado um conjunto de

atividades associadas que levam a produção de um produto de software
(SOMMERVILLE, 2010). Com base no modelo de ciclo de vida a ser seguido,
um processo de software define as atividades, procedimentos, marcos, papéis
a serem desempenhados e responsabilidades. Ele também define os artefatos
de entrada e de saída que devem ser criados ou mantidos em cada atividade,
além poder estabelecer os procedimentos a serem seguidos e as ferramentas
a serem adotadas.

É o processo de software, portanto, que guiará a alocação tanto de

recursos humanos quanto tecnológicos, a fim de entregarmos um produto de
software de qualidade.

Importante
A qualidade do processo de software (e de sua execução) não determinam a qualidade do
produto final de software, embora sejam um caminho mais seguro para alcançar esse objetivo.

De uma maneira geral, é esperado que todo processo de software

aborde, de algum modo, as quatro seguintes atividades fundamentais
(SOMMER, 2010):

1. Especificação: definir as funcionalidades do software e as restrições

ao seu funcionamento;
2. Projeto e implementação: produzir o software que atenderá à
especificação;
8 Arquitetura de Processos de Software
 3. Validação: com o objetivo de garantir que o software implementado
atende às necessidades do cliente;
4. Evolução: viabilizar a contínua evolução do produto para atender
às necessidades de mudança dos clientes.

Em um primeiro olhar, podemos perceber que essas quatro atividades

devem ser conduzidas em sequência. Por exemplo, para se implementar
um software (2), é necessário especificá-lo (1). Para validá-lo, é necessário
implementá-lo (3). Embora isso seja verdade, um modelo de processo pode
definir diferentes estratégias para a orquestração dessas atividades essenciais
ao desenvolvimento de software. Por exemplo, uma especificação pode estar
incompleta e, ainda assim, sua implementação ser iniciada. Um software pode
não estar totalmente implementado e, ainda assim, ser parcialmente validado.

Importante
Um modelo de processo de software também é eventualmente chamado de modelo
de ciclo de vida. Entende-se que a grande diferença entre esses dois termos está na
preocupação de se enfatizar ora a existência de um modelo que irá ditar o ciclo de
desenvolvimento de um software, ora a existência de um modelo de onde um ou mais
processos de software serão instanciados. Entretanto, o termo “modelo de processo de
software” é o mais largamente adotado nas principais referências técnicas, tais como
Sommerville, 2010 e Pressman, 2005.

Portanto, como base para se estabelecer um processo de software,

é fundamental definir o modelo de processo a ser seguido. Um modelo
de processo pode não definir características do processo, como papéis e
tecnologias a serem adotadas. Por outro lado, ele consiste em uma abstração,
em um arcabouço que é utilizado para fundamentar e explicar a estratégia de
desenvolvimento utilizada.

2.1 Modelo em Cascata

O modelo em cascata foi primeiro modelo de processo de
desenvolvimento de software divulgado (ROYCE, 1970). Ele pode ser
considerado o mais simples e intuitivo de todos e atribui fases para cada

Arquitetura de Processos de Software 9

atividade fundamental apresentada na introdução desta unidade de
aprendizagem. Isso significa que, para passar à fase seguinte, a anterior precisa
estar completa. A Figura 2 apresenta o modelo em cascada, considerando as
fases apresentadas em (SOMMERVILLE, 2010). Não obstante diferentes
autores apresentem diferentes fases, a essência é a mesma: executar cada
atividade de desenvolvimento de modo sequencial, da definição dos requisitos
até a sua manutenção.
Modelo Cascata

Definição de
requisitos

Projeto de sistema
e software

Implementação e
teste unitário

Integração e teste de
sistema

Operação e
manutenção

Figura 2: O modelo cascata. Fonte: Adaptado de SOMMERVILLE (2010).

Por meio da consulta aos stakeholders, ocorre a definição de requisitos.

Essa fase engloba a especificação das funcionalidades do sistema, detalhando
o funcionamento desejado para o sistema e as restrições para seu uso.

Stakeholders são as partes interessadas em um projeto de software.

Na definição de requisitos, os usuários do sistema são o tipo de stakeholder
tipicamente consultado, mas outras partes também podem ser consultadas,
incluindo os patrocinadores do projeto, clientes dos usuários e os próprios
desenvolvedores.

Em seguida, é elaborado o projeto (design) do software,

estabelecendo a arquitetura do sistema de software e como as funcionalidades
serão implementadas. Após a conclusão dessa fase, as partes ou componentes
do software são implementadas, sendo submetidas a testes unitários. Em
seguida, esses componentes são integrados e o sistema como um todo é
testado e validado pelos representantes do usuário final. Finalmente, o sistema
é posto em operação, sendo eventualmente submetido a manutenções.

10 Arquitetura de Processos de Software

2.2 Modelo em V
Uma variação do modelo em cascada é o modelo em V (V-model). Ele
retrata o relacionamento de ações de garantia da qualidade com atividades
voltadas para o desenvolvimento do software (especificação, projeto e
implementação) (PRESSMAN, 2005). Conforme pode ser visualizado na
Figura 3, o “V” do modelo representa o distanciamento entre as atividades
dos dois tipos.

No modelo em V, as atividades de desenvolvimento irão apoiar a

condução de testes específicos em cada atividade de garantia de qualidade.
Por exemplo, os testes de unidade são tipicamente realizados ao longo da
produção de código pelos próprios desenvolvedores, enquanto que os testes
de aceitação baseiam-se nos requisitos, especificados no início do processo.

Modelagem de
Teste de aceitação
requisitos

Projeto da
Teste do sistema
arquitetura

Projeto dos
Teste de integração
componentes

Geração de código Teste de unidades

Software
executável

Figura 3: O modelo V. Fonte: Adaptado de Pressman (2005).

Arquitetura de Processos de Software 11

 Desse modo, podemos observar que, na verdade, o modelo em V
propõe um modo de visualização das atividades de verificação de validação
ao longo projeto. Aqui, cabe ressaltar que o modelo V enfatiza as atividades
de teste, o que não exclui que cada artefato gerado durante o processo de
desenvolvimento deva ser submetido a verificações específicas.

Tanto o modelo em cascata quanto a sua variação em V cobrem as

atividades essenciais da engenharia de software. Entretanto, implementá-los
na prática pode ser um grande desafio, especialmente em razão da rigidez na
transição entre as atividades. Por exemplo, espera-se que a especificação esteja
completa para avançar para a próxima atividade. No entanto, em grande parte
dos projetos de sistemas na indústria, ocorre a necessidade de se entregar
pequenas partes do sistema, antes que toda a sua especificação seja finalizada.
Também é possível que os requisitos mudem ao longo do desenvolvimento
do sistema, ou seja, é comum que seja necessário realizarmos refinamentos
contínuos nos requisitos e entregas sucessivas. Com isso, evitamos um maior
desperdício de recursos e atendemos com maior efetividade às necessidades do
cliente. Não sendo isso possível, o resultado pode ser um posterior descarte de
parte ou mesmo de todo o sistema desenvolvido.

2.3 Modelo de Desenvolvimento Incremental

O desenvolvimento incremental baseia-se na obtenção de um contínuo
feedback dos usuários de modo a entregar versões do sistema que se aproximem
cada vez mais do produto desejado pelo usuário (SOMMERVILLE, 2010).
Esse processo, portanto, se repete até que a versão final seja validada. O modelo
incremental consiste em uma visão mais próxima à realidade envolvida na
resolução de problemas complexos, na qual raramente uma solução definitiva
é apresentada imediatamente. As soluções tendem a ser construídas e validadas
passo a passo, até alcançar uma solução definitiva.

O modelo incremental é a abordagem mais comumente presente na

atualidade dos processos de desenvolvimento de sistemas de informação
e aplicativos. Ele também está na essência dos chamados métodos ágeis
(SOMMERVILLE, 2010; LARMAN, 2004), sendo responsável pela
reivindicada flexibilidade desses métodos. Por outro lado, ele também é
a base de processos mais formais como o RUP (KRUCHTEN, 2004) e o
OpenUP [OPENUP]*.

12 Arquitetura de Processos de Software

 O esquema apresentado na Figura 4 indica as atividades principais
do desenvolvimento incremental com suas respectivas entregas. Aqui, cabe
ressaltar que diferentes atividades podem ser executadas simultaneamente,
por exemplo, a especificação do sistema pode ser evoluída enquanto ele está
sendo desenvolvido.

Importante
Os processos de desenvolvimento de software que não são inspirados no Manifesto Ágil
[MANIFESTO] são, muitas vezes, chamados de tradicionais, embora isso não seja uma
terminologia largamente aceita. Por outro lado, é incorreto afirmar que tais processos não
sejam ágeis. Nesse sentido, chamar processos de desenvolvimento como o RUP e de “não
ágeis” também pode remeter a uma conotação pejorativa, não havendo evidências científicas
suficientes para suportar essa afirmação.

Modelo Incremental
Atividade simultâneas

Especificação Versão inicial

Descrição do Desenvolvimento Versão

Versão
esboço Versão
intermediárias
intermediárias
intermediárias

Validação Versão final

Figura 4: O modelo incremental. Fonte: Adaptado de Sommerville (2010).

Dentre as vantagens do desenvolvimento incremental, podemos destacar:

▪▪ O custo reduzido em acomodar mudanças nos requisitos do cliente:

considerando que o sistema é desenvolvido a partir de incrementos,
a cobertura de eventuais ajustes nos artefatos de software tende a
ser menor do que no modelo sequencial;

Arquitetura de Processos de Software 13

 ▪▪ Os clientes participam mais ativamente do projeto, validando
diferentes versões do sistema em vez de realizar uma validação final.
O acompanhamento do cliente sobre a evolução do projeto também
fica mais intuitivo, uma vez que ele se torna menos dependente de
documentação e de modelos;
▪▪ É possível entregar uma versão funcional do produto de software
desde os primeiros incrementos. Nesse sentido, é fundamental que
os requisitos especificados sejam priorizados.

Embora o modelo incremental agregue importantes vantagens ao

desenvolvimento de software, cabe ressaltar que sua natureza também
traz alguns desafios de gestão. Um deles é a limitação da visibilidade
do processo, necessária para acompanhar o seu progresso. Outro desafio
é garantir a rastreabilidade dos artefatos de software, uma vez que
especificações precisam ser constantemente atualizadas para refletir os
incrementos do sistema e vice-versa. Além disso, as constantes alterações
estruturais do sistema podem acelerar a sua degradação, o que pode ser
mitigado por meio de contínuos esforços de revisão, incluindo atividades
de refatoração (FOWLER, 1999) e de inspeção (FAGAN, 2001). Esses
desafios são especialmente impactantes no desenvolvimento de grandes
sistemas e com maior complexidade.

Importante
Um dos maiores desafios da engenharia de software é garantir a rastreabilidade entre os
diferentes artefatos (requisitos, modelos, código-fonte, entre outros) gerados ao longo
do desenvolvimento do software. Garantir a rastreabilidade significa que cada artefato
desenvolvido em um projeto reflete, de maneira consistente, o mesmo produto de software
em diferentes níveis de abstração, o mesmo escopo.
A degradação de um produto de software pode ser percebida, por exemplo, na dificuldade
de se compreender a estrutura de um sistema ou na dificuldade de se realizar uma
pequena manutenção no código fonte. O excesso de degradação pode levar uma
organização a tomar medidas drásticas, tais como iniciar o desenvolvimento de um novo
sistema para substituir o atual.

14 Arquitetura de Processos de Software

2.4 Rapid Application Development (RAD)
O desenvolvimento rápido de aplicações foi introduzido por James
Martin no início dos anos 1990 (MARTIN, 1991). Ele é baseado na construção
de módulos por meio de ciclos de desenvolvimento consideravelmente curtos.
Esses ciclos, por sua vez, podem ser desempenhados por diferentes equipes de
desenvolvimento. Para tal, é necessário garantir que os requisitos do sistema
estejam bem-definidos e entendidos. Além disso, é preciso garantir que a
aplicação a ser construída possa ser modularizada efetivamente.

A Figura 5 exemplifica adoção do modelo RAD, em que o projeto de

um sistema de informação é dividido em dois módulos, cujas atividades de
desenvolvimento são conduzidas por duas equipes distintas.

Modelo RAD (Rapid Application Development)

Equipe #1 Equipe #2
Modelagem Modelagem
Negócio Negócio

Modelagem Dados Modelagem Dados

Modelagem Modelagem
Processo Processo

Geração Geração

Testes Testes

Figura 5: Exemplo de adoção do modelo RAD. Fonte: Adaptado de Martin (1991).

Em sua essência, o RAD se propõe a dividir o sistema em pequenos

componentes que possam seguir seu próprio ciclo em cascata. Cada entrega
pode ser considerada um incremento, porém, posterior integração (e testes)
será(ão) exigida(os). Como os ciclos de entrega são planejados para serem
rápidos, o modelo RAD é considerado adequado para o desenvolvimento de
sistemas de informação, nos quais existe uma recorrente expectativa de alta
volatilidade dos requisitos ao longo do tempo.

Arquitetura de Processos de Software 15

 Um grande desafio do modelo RAD é a possível exigência de vários
times multidisciplinares, uma vez que todas as atividades do modelo cascata
são desempenhadas em cada ciclo. Além disso, a sincronização entre times
também é uma questão importante para garantir a rapidez desejada.

2.5 Prototipação
Na engenharia de software, um protótipo consiste em uma versão
inicial de um sistema de software, cujo objetivo principal é demonstrar
conceitos e experimentar diferentes soluções. Protótipos também podem
ajudar a identificar alterações nos requisitos do sistema e identificar fragilidades.
Para os usuários, os protótipos contribuem para que os usuários verifiquem o
quanto o sistema dá suporte à realização de seu trabalho.

Um processo de desenvolvimento de software pode adotar o uso de

protótipos para auxiliar na comunicação entre os stakeholders em diferentes
etapas. De um modo geral, podemos utilizar-se de protótipos durante as
seguintes atividades:

▪▪ Durante a especificação de requisitos, onde o protótipo auxiliará na

elicitação e na validação dos requisitos do sistema;
▪▪ Durante o projeto (design) do sistema, no qual o protótipo poderá
ser usado para avaliar a viabilidade de alternativas de solução, bem
como para projetar a interface com o usuário.

Sommerville (2010) propôs um conjunto de etapas para o

desenvolvimento de um protótipo, conforme o fluxo apresentado na Figura 6.

Prototipação

Figura 6: Etapas para o desenvolvimento de um protótipo. Fonte: Adaptado de Sommerville (2010).

16 Arquitetura de Processos de Software

 De um modo geral, é desaconselhável transformar protótipos do
sistema em entregas do sistema. Pela sua natureza e tempestividade exigida,
protótipos frequentemente não atendem às diferentes exigências de qualidade
que se esperam no software, especialmente no atendimento à requisitos
não funcionais. Além disso, um protótipo tipicamente não é rastreável no
projeto do sistema, não sendo sequer especificado. Desse modo, tentativas de
atender a prazos apertados transformando protótipos no produto final podem
trazer consequências desastrosas. Entre elas, podemos destacar a degradação
acelerada do sistema e o aumento significativo de custos com manutenção.

2.6 Modelo Espiral

Barry Boehm propôs em 1988 (BOEHM, 1988) um modelo que
representa o processo de software como uma espiral. Cada volta da espiral
representa uma fase do processo. A primeira volta, a mais interna, objetiva
verificar a viabilidade do sistema. Os ciclos seguintes preocupam-se, nesta
ordem, com a especificação dos requisitos, o projeto do sistema, o projeto
detalhado, e assim por diante. Todas as voltas da espiral passam por quatro
setores (SOMMERVILLE, 2010):

1. Definição de objetivos: inclui definir os objetivos específicos de

uma fase do projeto, identificar restrições ao processo e ao produto e
elaborar um plano de gerenciamento. Nesse sentido, são identificados
os riscos do projeto e estratégias de resposta a esses riscos;
2. Avaliação e mitigação de riscos: os riscos identificados são
medidos e analisados de modo a prover medidas para sua mitigação
e, quando possível, sua eliminação;
3. Desenvolvimento e validação: considerando as respostas aos
riscos, aqui pode ser adotado um modelo de desenvolvimento
específico para viabilizar a construção do sistema;
4. Planejamento: os artefatos do projeto são submetidos a uma
revisão, que levará à decisão sobre uma nova volta na espiral.

Uma característica muito particular do modelo espiral é a sua ênfase na

gestão de mudanças e, consequentemente, dos riscos nelas envolvidos. Nesse

Arquitetura de Processos de Software 17

sentido, é importante observar que riscos nem sempre podem ser mitigados
ou eliminados. Exemplos de riscos em projetos de software incluem:

▪▪ Adoção de uma nova tecnologia de software: linguagens de

programação, IDEs, ferramentas de teste;
▪▪ Envolvimento de diferentes grupos de stakeholders na especificação
de requisitos;
▪▪ Baixa experiência dos analistas envolvidos;
▪▪ Perspectiva de mudanças significativas nos requisitos a curto e
médio prazos;
▪▪ Perspectiva de Indisponibilidade de pessoas chave para o projeto ao
longo de sua execução.

Modelo Espiral
Determinar objetivos,
alternativas e restrições Avaliar alternativas,
identificar, resolver riscos
Análise de
riscos
Análise de
riscos
Análise de
riscos Protótipo
Protótipo 3 operacional
Análise de Protótipo 2
REVISÃO riscos Protótipo 1

Simulações, modelos, benchmarks

Plano de requisitos Conceito de
Plano de ciclo de vida operação Requisitos
de S/W Projeto de Projeto
Validação de produto detalhado
Plano de
desenvolvimento requisitos Código
Teste unitário
Plano de integração Projeto V&V Teste de
Planejar próxima fase e testes Teste de integração
aceitação Desenvolver e verificar
Operação próximo nível do produto

Figura 7: O modelo espiral. Fonte: Adaptado de Sommerville (2010).

2.7 Modelo Iterativo e Incremental

Nos modelos apresentados anteriormente, é possível perceber algumas
diferenças principais na estrutura de cada processo. O modelo sequencial e

18 Arquitetura de Processos de Software

o modelo em V são fundamentados em uma visão de que cada atividade de
desenvolvimento deve ser concluída para que a próxima seja conduzida, ou
seja, segmentação do desenvolvimento, paralelismo de atividades e retorno às
atividades anteriores não são práticas previstas. Embora a abordagem sequencial
possa ser aplicável em alguns cenários, tais como no desenvolvimento de
sistemas de pequeno escopo e com requisitos estáveis, esta não é a realidade
mais frequente na indústria.

O modelo espiral e a prototipação são fundamentados na iteração, ou

seja, na repetição cíclica de atividades, o que permite o refinamento contínuo
do produto de software até resultar na entrega de um produto final funcional.
Por outro lado, o modelo incremental e o RAD são fundamentados em ciclos
de desenvolvimento que viabilizem a entrega de incrementos funcionais, até
alcançar a entrega do produto final. Portanto, o desenvolvimento iterativo e
o desenvolvimento representam alternativas mais realistas para os projetos
atuais da indústria de software. Eles permitem lidar de maneira mais efetiva
com a volatilidade de requisitos, com a complexidade dos sistemas e com as
pressões externas referentes à custo e prazo.

Desse modo, podemos afirmar que o desenvolvimento iterativo e

o desenvolvimento incremental apresentam características e benefícios
complementares. Nesse sentido, metodologias e processos padrão de
desenvolvimento de software largamente adotadas nas últimas duas
décadas são baseadas na combinação de desenvolvimento iterativo com
desenvolvimento incremental. Tais abordagens incluem o processo unificado
da Rational (RUP) (KRUCHTEN, 2004), o OpenUP [OPENUP] e
diferentes métodos ágeis. Na prática, essa combinação significa propiciar a
entrega contínua de versões parciais e funcionais do produto de software,
resultantes de constante refinamento.

Arquitetura de Processos de Software 19

Síntese
Nesta unidade de aprendizagem, conceituamos Engenharia de
Software, destacando o importante papel do processo no desenvolvimento de
software de qualidade. Diferentes modelos de processo foram apresentados, e
suas diferenças, debatidas.

20 Arquitetura de Processos de Software

Referências
BOEHM, Barry W. A spiral model of software development and enhancement.
Computer 21.5, p.61-72, 1988.

CORDEIRO, M. A. Modelos de Qualidade de Desenvolvimento de

Software. Disponível em: <www.batebyte.pr.gov.br/modules/conteudo/
conteudo.php?conteudo=1748>. Acesso em: 20 de ago. 2018.

FAGAN, Michael E. Advances in software inspections. In: Pioneers and their

contributions to software engineering. Springer, Berlin, Heidelberg, 2001.

FOWLER, M., BECK, K., BRANT, J., OPDYKE, W., & ROBERTS,
D. Refactoring: improving the design of existing code. Addison-Wesley
Professional, 1999.

ICSE. Keynotes. Disponível em: <https://www.icse2018.org/info/keynotes>.

Acesso em: 17 ago. 2018.

KRUCHTEN, Philippe. The rational unified process: an introduction.

Addison-Wesley Professional, 2004.

LARMAN, Craig. Agile and iterative development: a manager’s guide.

Addison-Wesley Professional, 2004.

MARTIN, James. Rapid application development. Macmillan Publishing

Co., Inc., 1991.

PRESSMAN, Roger S. Software engineering: a practitioner’s approach.

Palgrave Macmillan, 2005.

SOMMERVILLE, Ian. Software engineering. New York: Addison-Wesley,

2010.

Arquitetura de Processos de Software 21