Livro-Texto - Unidade II (1)

Prévia do material em texto

42
Unidade II
Unidade II
3 PROCESSO DE SOFTWARE
3.1 Processo de software e o desenvolvimento do projeto
 
[…] a engenharia de software é uma disciplina da engenharia que se ocupa de 
todos os aspectos da produção de software. Isso vai desde os estágios iniciais 
de especificação de um sistema até propriamente a manutenção, para que 
esse mesmo sistema sobreviva ao longo do tempo (SOMMERVILLE, 2003, p. 5).
A estrutura apresentada na figura 15 mostra o uso da engenharia de software durante os estágios 
de evolução da análise de um sistema em uma organização.
Estruturar a organização, 
identificando áreas de gestão
Estruturar funções e informações com base 
nas atividades e dados da organização
Modelar entidades, relações e 
dados com base nos requisitos
Gerar funcionalidades, 
protótipos e buscar validação
Usar a engenharia de software para escolher processos, 
métodos e ferramentas apropriadas para o projeto, controle, 
operacionalização e manutenção do sistema de informação
Figura 15 – Estágio de análise e construção do software ou sistema: de sua concepção até sua implantação
Stair (2006) sugere que quando se elabora um sistema é importante percorrer uma série de 
passos previsíveis, conhecidos como ciclo de vida do desenvolvimento do software (SDLC – Software 
Development Life Cycle).
O SDLC é um roteiro que ajuda a criar a tempo um resultado de alta qualidade. Os modelos de 
processos de software englobam um conjunto de atividades, métodos, práticas e transformações a 
serem empregadas no desenvolvimento e na manutenção do software; fornecem estabilidade, controle 
e organização para as atividades.
Se um processo estiver sem controle, as atividades tornam-se bastante caóticas, comprometendo 
a eficiência do projeto. Sem controle significa: sem acompanhamento, medições e sem comparações com 
43
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
marcas de referência (milestones); ocorrem atividades e tarefas redundantes, conflitos na comunicação, 
na análise e, consequentemente, há aumento de erros.
 Observação
Ao construir e operacionalizar um software sem planejamento com base 
em processos, haverá o risco de o projeto não ser efetivado e operacionalizado.
3.1.1 Planejamento do processo
Segundo Pressman (2002), um processo é uma sequência de fatos, atividades ou operações que 
apresentam certa unidade e/ou que se reproduzem com certa regularidade.
O processo deve ser delimitado, definindo-se seu início e fim. Os pontos de início (input) e fim 
(output) são marcas de referências (ou milestones) úteis para o acompanhamento do processo. Essas 
marcas servirão para controlar o processo, medir, avaliar e projetar melhorias e tendências.
A figura 16 mostra o modelo básico de um processo, com suas respectivas marcas de referência 
(input e output):
• Input: o ponto inicial normalmente marca os itens necessários para dar entrada ao processo. Esses 
itens referem-se aos requisitos de entrada do processo, tais como: objetos claros e específicos; 
recursos humanos necessários; materiais; tecnologia a ser empregada; fornecedores; componentes 
do software/sistema; metodologias; ferramentas; custo; cronograma; procedimentos de trabalho 
e documentos.
• Processo: é a combinação organizada dos itens de entrada para criar um produto de software ou 
de sistema, um componente de outro produto ou executar um determinado trabalho.
• Output: é a finalização do processo com a entrega do produto ou serviço determinado no 
processo. Assim, novos registros são feitos e novas medições e verificações são realizadas para 
confrontar o resultado obtido com o objetivo planejado para o processo.
Processo
Input (Entradas)
- Objetivos
- Recursos necessários
- Procedimentos
- Documentos
- Custo / cronograma
- Métodos / ferramentas
Output (Saídas)
- Produto
- Componente
- Serviços
Figura 16 – Modelo básico do processo
44
Unidade II
3.1.2 Decomposição do processo
Decompor um processo é estabelecer uma sequência coerente de práticas que objetiva o 
desenvolvimento ou evolução de sistemas de software. Essas práticas englobam as atividades de 
análise, especificação, modelagem, implementação, testes, implantação, suporte e manutenção. 
Por exemplo: o processo de engenharia de software pode representar a implementação de uma 
determinada funcionalidade.
O bom processo é caracterizado pelo emprego de ferramentas específicas de escolha do arcabouço 
do processo, registro e interação das ferramentas de trabalho, pessoas envolvidas no processo e 
métodos aplicáveis.
 Observação
Funcionalidade: uma ou várias funções que empregam recursos e 
lógicas similares, tecnologias comuns e que capacitam o produto software 
a prover funções que atendam as necessidades externas e internas do 
software/sistema.
De acordo com o escopo do projeto, o processo é estruturado em vários módulos (ou componentes), 
com base no tamanho do processo, na complexidade, na qualidade exigida e na tecnologia a ser 
implementada. A figura 17 mostra como é a estrutura genérica de um processo e os elementos que 
a compõem.
Processo
Subprocesso 1 Subprocesso 2 Subprocesso n
Procedimento 1 Procedimento 2
Tarefa 1 Tarefa 2 Tarefa 3 Tarefa 4
Atividade 1 Atividade 2 Atividade 3
Figura 17 – Estrutura genérica do processo
O processo pode ser dividido em etapas. Vale o bom senso. Normalmente, a divisão em etapas 
está associada a aspectos como tamanho, complexidade, qualidade, custo e prazo de cumprimento 
do processo.
O subprocesso (etapa do processo ou meta) é uma marca de referência que traça o objetivo de uma 
parte do processo. Tem como objetivo manter os planos, artefatos e atividades de software consistentes 
com os requisitos alocados.
A atividade é a realização de uma função específica do processo, usualmente compreendida no subprocesso.
45
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
O procedimento é a forma de como se deve agir, fazer ou cumprir uma atividade. Em geral, os 
procedimentos são caracterizados por meio de uma lista que apresenta passo a passo – e de modo 
sequencial – as tarefas que deverão ser executadas.
As tarefas são os trabalhos que devem ser efetuados. Representam uma empreitada de serviços, ou 
seja, uma quantidade de trabalhos realizados ou a realizar dentro de um prazo determinado.
O processo de software, como mostrado na figura 18, estabelece uma metodologia do processo 
que, em 2007, Pressman também chamou de arcabouço de processo.
 
Cada atividade metodológica é composta por um conjunto de ações de 
engenharia de software. Cada ação é definida por um conjunto de tarefas, 
o qual identifica as tarefas de trabalho a serem completados, os artefatos de 
software que serão produzidos, os fatores de garantia da qualidade que serão 
exigidos e os marcos utilizados para indicar progresso (PRESSMAN, 2011, p. 53).
Pressman (2011) determina uma metodologia de processo genérica para a engenharia de software 
estabelecida em cinco atividades metodológicas: comunicação; planejamento; modelagem; 
construção; entrega.
Processo de software
Metodologia do processo
Atividades de apoio
 Tarefas de trabalho
 Artefatos de software
 Fatores de garantia da qualidade
 Pontos de controle do projeto
 Tarefas de trabalho
 Artefatos de software
 Fatores de garantia da qualidade
 Pontos de controle do projeto
 Tarefas de trabalho
 Artefatos de software
 Fatores de garantia da qualidade
 Pontos de controle do projeto
 Tarefas de trabalho
 Artefatos de software
 Fatores de garantia da qualidade
 Pontos de controle do projeto
Atividade metodológica n° 1
Atividade metodológica n° n
Ação de engenharia de software n˚ 1.1
Ação de engenharia de software n˚ n.1
Ação de engenharia de software n˚ 1.k
Ação de engenharia de software n˚ n.m
Conjuntos 
de tarefas
Conjuntos 
de tarefas
Conjuntos 
de tarefas
Conjuntos 
de tarefas
Figura 18 – Metodologia do processo de software
46
Unidade II
Essa metodologia do processo, além de compor um conjunto de atividades de apoio, considera a 
administração de riscos, a garantiada qualidade, o gerenciamento das configurações e as revisões técnicas.
A garantia da qualidade é composta de um grupo que acompanha a qualidade do produto com 
base em métricas da qualidade. São feitas medições para avaliar o quão distante estão os resultados 
obtidos em relação aos determinados nos objetivos do software. Pressman (2002) apresenta a estrutura 
comum de um processo de software, como ilustrado na figura 19. Nesse modelo, o grupo conhecido 
como garantia da qualidade de software (SQA – Software Quality Assurance) acompanha os resultados 
de cada tarefa, cada atividade e, consequentemente, a medição da capacidade de cada processo do 
desenvolvimento do software. O grupo SQA cuida para que os resultados qualitativos e quantitativos 
não desviem de seus objetivos e metas, garantindo a eficácia de cada item.
Estrutura comum para o acompanhamento do processo
Conjunto de tarefas
Atividades de estrutura
Tarefa
Marca de referância (milestone)
SQA — Software Quality Assurance
(Garantia da Qualidade de Software)
Figura 19 – Elementos que compõem uma estrutura comum do processo
 Saiba mais
Para ampliar seu conhecimento, consulte a referência a seguir:
SERRA, A. P. Modelos de processo pessoal e de equipe. In: CONFERÊNCIA 
DA QUALIDADE DE SOFTWARE, 4., 2011, São Paulo. Anais [...]. São Paulo: 
Universidade São Judas, 2011. Disponível em: https://bit.ly/3cEOy8z. Acesso 
em: 3 mar. 2021.
3.2 Gestão de planejamento do software
Funciona em conjunto com a metodologia de desenvolvimento de sistemas/software. Isso ocorre 
no processo de iniciação. Nessa fase, elabora-se um documento breve, que serve de instrumento de 
comunicação para avaliar a organização das pessoas envolvidas no projeto de software (stakeholders), 
definindo papéis e responsabilidades de acordo com a capacitação técnica e aptidões para que elas 
atuem nos processos de comunicação, planejamento, modelagem, construção e entrega.
47
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
O gestor atua diretamente com as pessoas envolvidas no projeto, determinando suas atividades, 
suas datas, seus custos e recursos necessários para o projeto e de acordo com os resultados obtidos; 
também elabora ajustes para controlar o projeto.
3.2.1 Análise de recursos para os processos do projeto
No ciclo de vida de desenvolvimento de sistemas/software, os recursos a serem determinados para 
cada processo referente a cada fase do projeto compreendem os recursos necessários para o projeto 
do sistema ou software. Na projeção dos recursos, três perfis de analistas são essenciais: analista de 
negócios, analista de processo e analista de sistema, os quais têm a função de elaborar a efetivação do 
projeto, alinhando o negócio com a TI.
• Analista de negócio (ou autor do processo): esse profissional é aquele que precisa do negócio. 
Entende-se pelo negócio como algo que tenha que ser gerado, corrigido ou melhorado, para 
atender um objetivo ou necessidade. O analista de negócio utiliza uma linguagem natural e 
diagramas simples para apresentar o que quer, o que precisa que seja feito.
• Analista de processo: é aquele que interpreta a ideia do negócio, seus riscos e regras, e que 
tem por objetivo determinar as atividades e respectivas tarefas necessárias para processar o 
negócio. O analista de processo busca uma padronização da nomenclatura, destacando por 
meio de textos breves e diagramas específicos a ordenação das atividades e das tarefas que 
compõem a atividade.
• Analista de sistema: converte as atividades em componentes (peças que compõem o processo). 
Cada componente representa uma parte do sistema apoiada pelo processamento dos dados. 
A interpretação das tarefas e do workflow (fluxo de trabalho) levam à criação das funções 
de acesso do software/sistema, à lógica de processamento (programa de computador) e aos 
recursos computacionais necessários para executar as funções. Na prática da engenharia de 
software, o analista de sistema especifica cada função por meio de descrições singulares e 
modelos gráficos (modelagem) e determina as funcionalidades que serão interpretadas pelos 
especialistas da TI.
3.2.2 Recursos do projeto e do produto
Os recursos necessários para o projeto e para o produto, bem como os procedimentos de modelagem, 
construção e entrega, garantem a efetivação de cada processo do projeto. Com base nos requisitos 
determinados pelos analistas, essa abordagem atinge duas categorias gerenciais: gerência do projeto e 
gerência do produto.
• Gerência do projeto: dimensiona o escopo do projeto, se comunica, interpreta o processo, 
distribui atividades e tarefas, organiza, elabora cronogramas, tabela de custos e diagramas de 
execução e implantação do processo. No gerenciamento do projeto, os principais recursos a serem 
tratados são:
48
Unidade II
— Recursos humanos: são todos os envolvidos e interessados no projeto. Incluem aqueles que 
promovem o projeto, tais como: empresários e administradores; analistas representantes do 
cliente; grupos da qualidade; aqueles ligados às operações do software; representantes 
do usuário; contratações; desenvolvedores. A lista dos desenvolvedores é fornecida pela 
gerência do produto.
— Recursos materiais: se referem a localização, transporte, mobília e instalações para o ambiente 
de uso e ambiente de desenvolvimento do software. A parte referente ao desenvolvimento do 
software diz respeito aos recursos tangíveis, fornecidos pela gerência do produto.
— Recursos tecnológicos: envolvem os recursos intangíveis, fornecidos pela gerência do produto.
— Recursos financeiros: são os patrocinadores do projeto.
• Gerência do produto: especifica e cria o projeto do produto. Como vimos anteriormente, o 
produto pode ser um componente ou um subproduto, serviços a serem executados, resultados 
da produção ou do comércio, ou produto produzido em fábrica. Processos de gerenciamento de produto 
são tipicamente definidos em uma determinada etapa do ciclo de vida do projeto e variáveis 
específicas da área de aplicação. No ambiente computacional informatizado, é considerado 
como gerenciamento do produto aquele praticado para fornecer a infraestrutura de TI, que apoia 
o desenvolvimento do sistema de informação (SI). Em uma sequência ordenada, os principais 
recursos para desenvolver um SI são:
— Recursos humanos (Peopleware): são pessoas que trabalham diretamente ou indiretamente 
com a área de TI ou mesmo com o SI. Essas pessoas trabalham principalmente na gerência do 
produto, prestando serviços para o desenvolvimento do software.
— Recursos de software: basicamente, são recursos intangíveis, tais como licenças de software 
necessárias para desenvolvimento, gerenciamento do banco de dados, implantação e controle 
do software a ser produzido.
— Recursos de hardware: são recursos tangíveis, que compreendem computadores (servidores 
e estações), terminais de computadores, interfaces de hardware específicas para comunicação, 
gabinetes, racks, dispositivos associados a computação e periféricos em geral.
— Recursos de dados: são aspectos de serviços ligados ao projeto e gerenciamento do banco 
de dados, serviços de dados, estrutura dos dados, segurança da informação, regras de acesso, 
distribuição dos dados, armazenamento, proteção e recuperação dos dados.
— Recursos da rede de computadores: são os serviços ligados ao projeto de topologia da rede, 
bem como à configuração dos dispositivos associados à ligação e proteção da rede.
49
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
3.3 Fusão do produto e do processo
O processo é um diálogo no qual o conhecimento, que deve se transformar em software, é reunido 
e embutido no software (PRESSMAN, 2002).
 
Processos reais de software são intercalados com sequências de atividades 
técnicas, de colaboração e de gerência, com o intuito de especificar, projetar, 
implementar e testar um sistema de software. Os desenvolvedores de software 
usam uma variedade de diferentes ferramentas de software em seu trabalho. 
As ferramentas são especialmente úteispara apoiar a edição de diferentes tipos 
de documentos e para gerenciar o imenso volume de informações detalhadas 
que é gerado em um projeto de grande porte (SOMMERVILLE, 2011, p. 24).
As principais características de um bom processo são:
• ser configurável para diferentes organizações;
• ser adaptável para diferentes tamanhos e tipos de projetos;
• ser bem definido, gerenciável e repetível;
• conter nomenclatura universal e métricas para planejamento e gerenciamento do projeto;
• ser integrado com ferramentas que o suportem.
Na fusão do produto e do processo, convém descrever como são organizadas as atividades, ações 
e tarefas de cada atividade, escolha do(s) modelo(s) de processo de desenvolvimento, métodos e 
ferramentas aplicáveis do arcabouço do processo. A organização dessas atividades é apresentada por 
um fluxo de processos como mostra a seguir a figura 20, que descreve o ciclo de vida do projeto.
O ciclo de vida do projeto serve para definir o início e o fim do projeto, bem como o início e o fim 
de cada processo que o compõe. Por exemplo, no processo de construção do software, é necessário ter a 
modelagem do componente de software a ser produzido, verificado e validado. Só depois é que se passa 
para a fase de codificação.
Neste livro-texto, serão apresentados alguns dos modelos de processos de software mais utilizados 
no ciclo de vida do projeto.
3.3.1 Estrutura organizacional para o desenvolvimento de software
Basicamente, o ciclo de vida do projeto atende uma estrutura organizacional para o desenvolvimento 
de software, mostrada na figura 20, a qual apresenta as fases da organização, bem como suas formas de 
relacionamento. “A estrutura organizacional é um fator ambiental da empresa que pode afetar a 
disponibilidade dos recursos e influenciar a maneira como os projetos são conduzidos” (PMBOK, 2007, p. 23).
50
Unidade II
Fases da organização
Planejamento
Análise
Estratégico
Tático
Operacional
Projeto
Construção
Relacionamento organizacional
Figura 20 – Estrutura organizacional para o desenvolvimento de 
sistema/software com suas fases e formas de relacionamento
Observe a seguir as fases da organização para o desenvolvimento do software:
• Planejamento. Nessa fase, a empresa ou entidade desenvolvedora estabelece comunicação com 
o cliente/usuário (interno ou externo) que necessita do software. São elaboradas reuniões formais 
e/ou informais dirigidas ao produto de software que será produzido, com o objetivo de fazer 
arguições para entender e saber o que os interessados desejam do software, como o negócio 
funciona, restrições e limitações que devem ser aplicadas. No planejamento, durante a atividade 
de comunicação, faz-se o levantamento de requisitos do negócio. No planejamento, também é 
importante registrar os fatores humanos associados à política de decisão da organização envolvida 
no software. Esse registro servirá de base futura para estabelecer no software as regras do negócio, 
ou seja, as entidades associadas a regras de acesso a determinadas funções do software.
• Análise. Partindo do levantamento de requisitos do negócio, a análise consiste em determinar o 
escopo do sistema e a capacidade do desenvolvedor em produzir o software. As principais tarefas 
dessa fase são agrupar e organizar dados para especificar e modelar os requisitos do usuário, 
determinar os principais componentes do sistema que darão apoio ao software, especificar 
e modelar os requisitos do sistema, bem como definir o custo e o cronograma do ciclo de 
desenvolvimento do software.
• Projeto. Nessa fase é usada engenharia de software para escolher modelos de processos e 
metodologias para o desenvolvimento do software, especificar os requisitos funcionais e não 
funcionais do software e estabelecer procedimentos e técnicas apropriadas para o controle do 
desenvolvimento e operacionalização do sistema. Três arquiteturas são modeladas: arquitetura 
da infraestrutura da TI, arquitetura da lógica de processamento e arquitetura dos dados. No projeto 
também são determinados os seguintes aspectos: padronização de nomenclatura; linguagens, 
técnicas de programação e de gerenciamento dos dados; formas de testes; diagnósticos 
do software.
51
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
• Construção. É a fase de criação do sistema completo e executável, que abrange toda a 
infraestrutura da TI que dará suporte ao sistema. São codificados, verificados e validados os 
programas de computador. Também são ligados os componentes que integram o sistema, são 
feitas as instalações de bibliotecas (internas e externas) e a configuração de todo o ambiente 
operacional. Na entrega do sistema, além dos testes feitos no ambiente do desenvolvedor, novos 
testes são realizados no ambiente do usuário.
Vamos estudar a seguir o relacionamento organizacional no desenvolvimento do software.
Cada fase da organização normalmente trabalha de forma independente e horizontal. Contudo, o 
relacionamento entre as fases da estrutura organizacional ocorre de forma vertical.
• Relacionamento estratégico. É a relação entre a fase do planejamento e a da análise. Assim, 
faz-se a análise de viabilidade do sistema e, de acordo com os requisitos do negócio, escopo do 
sistema e a capacidade do desenvolvedor em produzir o software, avalia-se a relação custo/benefício. 
Da parte do cliente, analisam-se o ambiente operacional, o preço disposto a pagar e o prazo de 
entrega requerido. Da parte do desenvolvedor, avaliam-se os seguintes aspectos: o custo dos 
recursos necessários para produzir o software, o cumprimento do prazo determinado pelo cliente, 
a capacitação técnica do pessoal e os recursos associados.
• Relacionamento tático. É a relação entre a fase da análise e a do projeto. O relacionamento 
tático consiste na definição das funcionalidades e a ordem em que elas serão construídas, com 
base nas prioridades do negócio. As funcionalidades são definidas pautando-se nos requisitos 
do software, ou seja, os requisitos do usuário e os requisitos do sistema determinados na fase 
da análise, bem como os requisitos funcionais e não funcionais definidos na fase do projeto. 
Uma vez integrados os requisitos do software, as funcionalidades do sistema são especificadas e 
vários componentes de software são definidos. Os componentes são integrados ao(s) modelo(s) de 
processos de software, ao custo e ao cronograma do ciclo de desenvolvimento do software.
• Relacionamento operacional. É a relação entre a fase do projeto e a fase da construção. A construção 
do software acompanha os modelos projetados e alinhados aos termos do negócio. À medida que os 
componentes vão sendo construídos no ambiente de desenvolvimento, a implantação do software 
é preparada e são produzidos os manuais técnicos e do usuário. No relacionamento operacional, 
quando o software for implementado no ambiente do usuário, serão elaborados o treinamento do 
usuário, o suporte e a manutenção do software para atender as necessidades de uso.
3.3.2 Generalidades sobre o arcabouço do processo
A fusão do produto e do processo ocorre a partir das atividades de efetivação do processo. Cada 
atividade se inicia com a definição do arcabouço do processo. Arcabouço é um termo técnico que 
significa estrutura, base de apoio, instrumentação para fazer alguma coisa.
O arcabouço do processo de desenvolvimento do software é o conjunto de artefatos de software e 
recursos necessários que devem estar disponíveis para produzir o software. Esses artefatos e recursos 
52
Unidade II
formam um repertório de alternativas que ficam à disposição para serem escolhidas em cada etapa do 
processo ou de uma determinada atividade.
A cada iteração ocorre a escolha dos itens do arcabouço para preparar a equipe e dispor dos recursos 
do arcabouço para a próxima etapa. O arcabouço é uma caixa de métodos e ferramentas apropriadas para 
todas as fases do desenvolvimento do software e que ficam à disposição da equipe de desenvolvimento.
O arcabouço constitui o instrumentalnecessário para compreender novas teorias, desenvolver teses, 
executar serviços ou simplesmente embasar uma opinião. Fazem parte do arcabouço do processo de 
desenvolvimento de software os seguintes aspectos:
• Equipe de desenvolvimento com cargos (hierarquia de decisão), papéis e responsabilidades 
definidas. Mais adiante será apresentada uma metodologia, qual seja, a MR, sugerida pelo PMBOK, 
aplicada a equipes de desenvolvimento de software/sistema.
• Escolha do(s) modelo(s) de processos de software para desenvolvimento. Existem vários 
modelos de processos de software, os quais serão discutidos mais a seguir. Os modelos apresentam 
uma sequência de procedimentos apropriados para todo o desenvolvimento do software/sistema 
ou parte deste. São destaques o modelo cascata, incremental, RUP e outros.
• Métodos e procedimentos a serem aplicados. As metodologias e procedimentos de serviços 
organizam e agilizam a execução das tarefas. Trata-se de métodos já prontos, que abrangem desde 
a comunicação para a aquisição do negócio até a entrega ao cliente do produto software. Um 
exemplo é a metodologia com base na MR citada para a formação da equipe de desenvolvimento.
• Ferramentas e técnicas para o desenvolvimento. As ferramentas e técnicas permitem 
controlar e construir o software de forma eficaz e segura. Exemplo de ferramentas aplicáveis no 
desenvolvimento de software: meios de comunicação on-line, aplicativos para ambiente office, 
ferramentas para o controle de custos e cronograma do projeto, ferramentas de modelagem, de 
codificação e verificação do software.
• Artefatos de software. Os artefatos de software incluem o ambiente operacional de trabalho dos 
stakeholders, tais como: bibliotecas de componentes e objetos que dão suporte a outro software, 
gerenciador de banco de dados, gerenciador de rede, compiladores, interpretadores de comandos, 
padrões de uso de sistemas operacionais, aplicativos e utilitários. É importante que haja um padrão 
de versões e releases das ferramentas de trabalho que estão sendo empregadas e que sejam de 
uso comum entre os stakeholders.
Exemplo de aplicação
Observe a seguir a escolha de instrumentos do arcabouço para análise do projeto, codificação e 
verificação de determinada funcionalidade do software:
53
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
• Escolha da equipe: um analista de sistemas e dois programadores (um deles experiente e 
outro iniciante).
• Modelo de processo de software: modelo incremental.
• Metodolologia: Extreme Programming (XP).
• Ferramentas: controle do projeto com Microsoft Project 2019 e, para modelagem e acompanhamento 
do projeto do produto, o uso da ferramenta CASE ERwin Data Modeler Standard.
• Artefatos de software: sistema operacional Windows 10, navegador Google Chrome e Framework 
Visual Studio 2017.
3.3.3 Gerenciamento da equipe de desenvolvimento
A metodologia sugerida para um bom gerenciamento da equipe de desenvolvimento do software 
tem base na MR do PMBOK. Tal metodologia permite acomodar todos os stakeholders envolvidos no 
desenvolvimento do software.
Os stakeholders são todos os interessados no software/sistema. Em escala na hierarquia de decisão 
estão: cliente, representante do usuário, autor do processo, gerente de projeto, gerente do sistema, 
programador, administrador do banco de dados (DBA – Data Base Administrator).
Dependendo da atividade na MR, a equipe de stakeholders também pode fazer representação para os 
profissionais de influência indireta ou direta aos aspectos operacionais do desenvolvimento do software, 
por exemplo, o gerente do financeiro, que patrocina os recursos da equipe de desenvolvimento, ou o 
representante do cliente interessado no produto software.
A MR é um método abrangente e eficiente para distribuição de papéis e responsabilidades, muito 
útil no processo organizacional da equipe de desenvolvimento. O formato matricial mostra todas as 
atividades associadas a uma pessoa e todas as pessoas associadas a uma atividade (PMBOK, 2007). 
Revisado de forma contínua a cada quatro anos, em 2020 foi lançada a sétima edição do PMBOK.
Uma MR é usada para ilustrar as conexões entre pacotes de trabalho ou atividades e os membros da 
equipe do projeto (PMBOK, 2007).
A matriz é um arranjo de vários elementos num quadro retangular que comporta colunas e 
linhas. O quadro a seguir mostra uma MR para o gerenciamento da equipe de desenvolvimento de 
software. São três alinhamentos de colunas: a primeira coluna é a identificação do registro; a segunda 
é para o nome da atividade; e a terceira é formada por várias outras colunas, com os cargos profissionais 
dos stakeholders que constituem a equipe. Quanto às linhas: a primeira é reservada para o cabeçalho da 
matriz e as demais linhas são as que possuem os nomes das atividades e seus respectivos status.
54
Unidade II
Quadro 1 – Distribuição de colunas e linhas de uma MR 
para o gerenciamento da equipe de desenvolvimento de software
ID Atividade
Stakeholder
Cliente Gerente de projeto
Gerente de 
sistemas
Analista de 
sistemas Program. DBA
1 Teste: usabilidade
2 Estética
A MR pode ser usada também para um mapeamento do processo, substituindo a coluna 
de atividades por uma coluna de processos e a coluna de cargos por uma coluna dos setores da 
empresa desenvolvedora. Observe o quadro a seguir.
Quadro 2 – Distribuição de colunas e linhas de uma MR para mapeamento do processo
ID Processo
Setor da empresa
Cliente Administr. Marketing Projeto Produção Instalação
1 Comunicação
2 Planejamento
3 Modelagem
4 Construção
5 Entrega
A distribuição de responsabilidades não deve ser atribuída ao acaso. A identificação das 
responsabilidades é vital para o controle do recurso humano no processo organizacional.
Para determinar os critérios de responsabilidades, algumas questões devem ser observadas 
quanto aos integrantes da equipe de desenvolvimento:
• Qual o organograma que será aplicado para os stakeholders?
• Quem é o responsável mais cobrado por um determinado resultado do processo, da atividade 
ou da tarefa?
• Quem influencia mais o processo e possui maior poder de decisão?
• Quem é o autor do processo?
• Quem faz a maior parte do trabalho ou quais os integrantes que serão mais exigidos no processo?
55
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
A distribuição de responsabilidades é baseada em atributos, que indicam o papel que o integrante 
tem na equipe. O atributo estabelece o nível de responsabilidade do integrante na atividade em questão. 
A determinação dos atributos depende do tamanho, da complexidade e do nível de qualidade exigida 
no desenvolvimento do software. No exemplo apresentado no quadro a seguir, o modelo de atributos 
proposto para a MR é denominado RASP (responsável; quem aprova; quem dá suporte; e participante). 
O modelo teve como base a “matriz de designação de responsabilidades ilustrada no PMBOK 2000” (PMI 
MG, 2002, p. 111). Na edição atual, o conjunto de atributos da MR recebe o nome de “RACI (responsável pela 
execução, responsável pela aprovação, é consultado e é informado)” (PMBOK, 2017, p. 317, grifo nosso).
Quadro 3 – Modelo de MR aplicada no processo de distribuição de papéis e 
responsabilidades na gestão de requisitos de uma determinada funcionalidade
ID Atividade
Stakeholder
Cliente Gerente de projeto
Gerente de 
sistemas
Analista de 
sistemas Programador DBA
1 Objetivo do negócio R S S P -- --
2 Requisitos do negócio A R S S -- --
3 Modelagem do negócio S R S P -- --
4 Arcabouço do processo P S R S S S
5 Modelagem de casos de uso (RU) A S R S S P
6 Arquitetura do sistema (RS) S P A R S S
7 Arquitetura da informação (RU) (RS) (RF) (RNF) S P A R S S
8 Arquitetura da lógica de processamento (RU) (RF) (RNF) S P S A R S
9 Estrutura do banco de dados (RS) (RF) -- P S S S R
10 Prototipação A S S R S P
11 Codificação -- P S S R S
12 Testes de componente e de integração A S R S S S
Atributos do processo: R = responsável; A = quem aprova; S = quem dá suporte; e P = participanteA distribuição dos atributos deve se orientar de acordo com o grau de envolvimento do 
integrante da equipe na atividade. Na MR RASP, a definição e a função para cada atributo do 
processo na montagem da matriz são:
• R (responsável). É o integrante responsável pelo processo, atividade ou tarefa. O responsável 
alinha a equipe, cria procedimentos de serviços e dispõe os recursos necessários para a execução 
da atividade. É quem responde pelo sucesso de execução da atividade. Para todas as atividades, 
sem exceção, deve existir obrigatoriamente apenas um R.
• A (quem aprova). É o integrante responsável pela validação dos resultados da atividade, que 
normalmente é o cliente (interno ou externo), autor da atividade, diretor ou gerência. Deve ser 
usado apenas um atributo A para a atividade. Porém, não existe obrigatoriedade para aplicar 
esse atributo em todas as atividades, porque nem todas as atividades necessitam de aprovação.
56
Unidade II
• S (quem dá suporte). Compreende os auxiliares diretos que trabalham na atividade junto ao 
responsável (R). Os integrantes que dão suporte podem representar um determinado membro da 
equipe, terceirizados que trabalham na atividade ou consultores. Para cada R é sugerido que 
este seja acompanhado por, pelo menos, um S.
• P (participante). Envolve os convidados a integrar a equipe para a realização de uma determinada 
atividade. Os participantes atuam da atividade de forma indireta e podem representar vários 
perfis na equipe. Os participantes podem ter o perfil de consultores que possuem conhecimentos 
específicos sobre uma determinada atividade ou interessados na atividade por alguma outra 
razão, por exemplo, avaliar o custo da atividade, quando a atividade se referir às operações de 
verificação de integração dos componentes do software.
 Observação
Apesar de ser possível designar dois atributos para o mesmo integrante 
de uma determinada atividade, não é aconselhável que isso seja feito. 
Deve haver bom senso para a adoção desse critério, porque esse fato pode 
acarretar esforço maior de serviços para o integrante, afetar a eficácia da 
atividade na verificação e validação e ainda restringir o conhecimento, que 
é de interesse de todos os envolvidos.
4 MODELOS DE PROCESSOS DE SOFTWARE
4.1 Modelos de processos de software tradicionais
A estrutura organizacional orientada por um modelo de processo é a composição organizada do 
ciclo de vida do desenvolvimento do software em uma coleção ordenada de conjuntos de atividades, 
métodos, práticas e transformações empregadas no desenvolvimento e na manutenção de software. 
O modelo de processo de software fornece estabilidade, controle e organização para as atividades, que, 
se deixadas sem controle, tornam-se caóticas.
 Lembrete
O processo é um diálogo no qual o conhecimento, que deve se transformar 
em software, é reunido e embutido no software (PRESSMAN, 2002).
“Um modelo de processo de software é uma representação simplificada de um processo de 
software. Cada modelo representa uma perspectiva particular de um processo e, portanto, fornece 
informações parciais” (SOMMERVILLE, 2011, p. 19, grifo nosso).
57
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Logo, um modelo de software deve ser aplicado em partes específicas do processo que atenda toda 
a organização. Em uma visão global, tanto um sistema como um processo são orientados por uma 
estrutura organizacional.
Os modelos de processo de software apresentados neste capítulo são:
• Modelos de processos tradicionais: cascata, balbúrdia, prototipagem, incremental, RAD e espiral.
• Processo unificado: RUP e Praxis.
• Modelos de processo pessoal e de equipe: PSP e TSP.
4.1.1 Modelo cascata (Waterfall ou sequencial linear)
O modelo cascata foi o primeiro modelo publicado do processo de desenvolvimento do software, 
originário de outros processos da engenharia de sistemas. É considerado o modelo clássico do ciclo de 
vida de desenvolvimento do software, dá-se de forma sequencial encadeada e reflete as atividades 
fundamentais do desenvolvimento (PRESSMAN, 2011).
No modelo cascata, como é apresentado na figura 21, as principais atividades são organizadas no 
formato de uma cascata. Só após a última atividade, que é a de operação e manutenção, é feita a 
entrega do sistema ao cliente. O cliente e o desenvolvedor revisam o software ou o sistema.
Definição de 
requisitos
Projeto de sistemas 
e de software
Implementação e 
testes de unidades
Integração e 
testes de sistemas
Operação e 
manutenção
Figura 21 – Modelo cascata para o desenvolvimento do software
A seguir são descritos os conceitos sobre as atividades do modelo cascata:
• Definição dos requisitos: determinam-se funcionalidades, restrições e objetivos do sistema, que 
são estabelecidos com base na comunicação com o cliente e usuários do sistema. Em seguida, são 
definidos em detalhes e servem como especificação do sistema.
• Projeto de sistemas e de software: esse processo agrupa os requisitos em sistemas de software 
e/ou hardware, definindo a arquitetura do sistema.
58
Unidade II
• Implementação e teste de unidades: verifica se cada unidade atende as especificações.
• Integração e testes de sistemas: as unidades são integradas e testadas como um sistema 
completo. Depois dos testes, o software é entregue ao cliente.
• Operação e manutenção: essa é a fase mais longa do ciclo de vida do software. O sistema é 
instalado e colocado em operação e novos problemas surgem. A manutenção procura corrigir 
erros que não foram identificados anteriormente, melhora a interface, aumenta as funções do 
sistema e novos requisitos são descobertos.
Apesar de o modelo cascata servir de base para outros modelos, sua vantagem está nas aplicações 
com sistemas estruturados, que são sistemas únicos e que operam em um ambiente operacional restrito, 
porém de alta capacidade. Outra vantagem é ser aplicado em problemas complexos ou que sejam difíceis 
de serem resolvidos por incluir vários componentes.
A desvantagem é ser inflexível na divisão do projeto em estágios distintos. Na prática, é impossível 
conseguir a totalidade dos requisitos em um momento inicial do projeto, e qualquer problema que 
ocorra em uma das fases só poderá ser detectado após a entrega do software para o cliente, gerando 
retrabalhos ou até mesmo a extinção do projeto. A visão do modelo cascata é de alto nível e não reflete 
o modo como o software é desenvolvido. Mudanças no software durante o desenvolvimento não são 
apreciáveis e, consequentemente, não são sugeridas para projetos orientados a objeto.
4.1.2 Modelo balbúrdia (codifica/corrige ou codifica/remenda)
No modelo balbúrdia, apresentado na figura 22, que também é conhecido como codifica/corrige ou 
codifica/remenda, o software é construído sem nenhum tipo de projeto ou documentação. Normalmente, 
é encontrado em organizações que são administradas por crises, em que não há planejamento nem 
controle com relação aos possíveis riscos. Nesse modelo só existem duas fases: codificação e correção 
(ou remenda).
Nesse modelo ocorrem várias mudanças que levam sempre a novas implementações, fazendo com 
que o software fique cada vez mais longe da maturidade. Caracteriza-se pela administração do caos, pela 
informalidade, pelo loop de gestão codifica/corrige, em que o planejamento, os requisitos do software, a 
modelagem e documentação são caóticos ou até mesmo inexistentes.
Especificação 
da mudança
Implantação
Codifica
Corrige
Figura 22 – Modelo de processo de software balbúrdia
59
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
 Observação
O modelo balbúrdia não é propriamente um modelo de processo de 
software a ser seguido. Na verdade, é um modelo de processo de software 
que deve ser evitado.
4.1.3 Prototipagem
Na arquitetura e no design, é comum montar uma maquete (escala reduzida de uma obra de 
arquitetura). A prototipagem tem o mesmo objetivo de uma maquete. Antes da entrega final do sistema, 
são desenvolvidos protótipos apresentados em um esboço paramelhorar o entendimento de desenvolvedores 
e clientes sobre as possíveis problemáticas que possam surgir.
A prototipagem pode ser classificada de acordo com uma variedade de dimensões. A abordagem de 
prototipação tem um número de vantagens importantes a oferecer:
• Primeira abordagem: todos os requisitos do sistema não necessitam de determinação completa 
e antecipada, podendo estes ser alvo de trocas ainda durante o curso do projeto.
• Segunda abordagem: a entrega da prototipação concisa deve conter definições do sistema e 
especificações para o usuário final. Como consequência, o envolvimento e a satisfação do usuário 
final são fortemente aumentados.
• Última abordagem: a prototipação possibilita testar rapidamente o ambiente de desenvolvimento 
voltado para a funcionalidade, o desempenho e a interface de dados.
Dentro dessa visão, o projeto passa por várias investigações para garantir que desenvolvedor, usuário 
e cliente cheguem a um consenso sobre o que é necessário e o que deve ser proposto. Como muitos 
usuários não possuem uma visão ampla sobre a tecnologia, esse método de desenvolvimento é bastante 
interessante, permitindo que o usuário interaja significativamente no sistema.
As atividades da prototipagem podem ser determinadas a partir do paradigma de prototipagem, 
apresentado por Pressman (2002), como é mostrado na figura 23, que é um procedimento a ser seguido 
pelo engenheiro de software.
Ouvir o 
cliente
Construir / revisar 
o protótipo
O cliente testa 
o protótipo
Figura 23 – O paradigma de prototipagem
60
Unidade II
Observe a seguir o ciclo de atividades da prototipagem:
• Começar por um conjunto bem simples de requisitos fornecidos pelos clientes e usuários.
• Clientes e usuários fazem testes e experimentações. Assim que eles decidem o que querem, os 
requisitos são revisados, alterados, detalhados e documentados, e o sistema passa a ser codificado 
ou os protótipos simples são desenhados para análise de funções e interface do usuário.
• Novamente as alternativas são apresentadas e discutidas com os usuários. O processo de 
prototipagem continua, passa para uma nova etapa do ciclo de desenvolvimento do software ou 
implementa uma nova funcionalidade até a entrega definitiva do sistema.
Vantagens da prototipagem:
• A prototipagem é um ciclo de vida eficiente, que possibilita ao desenvolvedor criar o modelo do 
software que será construído.
• É apropriada para quando o cliente definiu os objetivos do software, mas não identificou detalhes 
dos requisitos de entrada, processamento e saídas.
• É útil para identificar os requisitos do software. Esse processo possibilita ao desenvolvedor, 
cliente e usuário examinarem antecipadamente os requisitos, reduzindo os riscos e incertezas do 
desenvolvimento. A chave é definir as regras do jogo logo no começo.
• Possui velocidade de desenvolvimento no sentido de propiciar ao usuário uma visão mais real do 
software que se está projetando (o usuário pode enxergar telas e relatórios resultantes do software).
• Apresenta envolvimento direto do usuário à medida que o software é desenvolvido. O usuário 
passa a ser um coautor do desenvolvimento.
Desvantagens da prototipação:
• Casos em que o cliente não sabe que o software que ele está testando ainda não foi concluído 
e não considerou, no desenvolvimento, a qualidade global e a manutenibilidade ao longo da 
operacionalização do software.
• A prototipação pode dar ao usuário a impressão de que praticamente qualquer sugestão pode 
ser implementada, de modo a não importar qual estágio do processo de desenvolvimento está 
em andamento. Além disso, para os usuários não fica claro o porquê da demora em entregar a 
aplicação final depois que uma versão demo do sistema foi exibida. Então, o cliente não aceita 
bem a ideia de que a versão final do software ainda será construída e, por conseguinte, “força” a 
utilização do protótipo como produto final.
61
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
4.1.4 Incremental
O modelo de processo incremental (figura 24) aplica sequências lineares dos elementos do 
modelo cascata e aplica de forma evolucionária incrementos com base no prazo de entrega, aprovação 
e validação. O modelo de processo incremental é iterativo e tem como objetivo apresentar um produto 
operacional a cada incremento realizado, ou seja, é desenvolvido com o conceito de versões.
Iteração é uma estratégia de planejamento para retrabalhar o processo, revisar tempos, comentar 
falhas, erros e tecnologia, melhorar o sistema e distribuir tarefas. A cada iteração são geradas novas 
versões, que são os registros de acompanhamento das mudanças no software até o release, que é 
o registro da versão que é liberada para o usuário. As iterações do processo são necessárias para a 
melhoria contínua do processo de desenvolvimento do software.
Funcionalidade
Incremento 1
Incremento 2
n Incremento
Entrega do 
Incremento 1
Entrega do 
Incremento 2
Tempo
Comunicação
Comunicação
Comunicação
Planejamento
Planejamento
Planejamento
Modelagem
Modelagem
Modelagem
Construção
Construção
Construção
Implantação
Implantação
Implantação
Figura 24 – Modelo de processo incremental
Na prática, o usuário quer sempre o sistema para ontem e com qualidade. O modelo incremental 
parte do princípio de que é preferível o usuário receber o sistema em partes, permitindo que esses 
recursos já possam ser utilizados enquanto os demais estão em desenvolvimento.
Nesse modelo, o sistema será especificado na documentação dos requisitos e “quebrado” em 
subsistemas por funcionalidades. As versões são definidas, começando com um pequeno subsistema 
funcional e então são adicionadas mais funcionalidades a cada versão. Por meio dessas novas versões, 
pode-se dizer que o modelo incremental chega lentamente à funcionalidade total.
O modelo incremental é o mais indicado na atualidade para o desenvolvimento de software, 
principalmente nos projetos orientados a objetos. Esse modelo é adaptável a vários tamanhos de 
sistemas/software e possui várias vantagens em relação aos demais modelos de processos.
A seguir são apresentadas as diversas vantagens do modelo de processo incremental:
• As iterações permitem aprendizagem e melhoria contínua do processo, bem como maturidade e 
composição progressiva do produto de software.
62
Unidade II
• Cada iteração/incremento produz um conjunto de produtos utilizáveis prontos para uso.
• A redistribuição contínua de tarefas para os envolvidos ao longo do projeto permite melhorar 
a cultura da equipe de desenvolvimento. Os desenvolvedores trocam ideias e adquirem melhor 
conhecimento sobre o produto que é para ser entregue.
• O usuário é encorajado a participar do desenvolvimento do software.
• Identificam-se falhas, riscos e dúvidas no projeto.
• Destacam-se inconsistências entre a análise, o projeto e a implementação.
4.1.5 Modelo espiral
É um modelo evolucionário, que combina a natureza iterativa da prototipagem com o estilo clássico 
do modelo cascata.
A figura 25 mostra o modelo espiral, cujo software é desenvolvido em uma série de versões 
evolucionárias e em cada ciclo da espiral é definido um conjunto de atividades de arcabouço. Então, 
depois de completada a espiral, um release é definido e, após várias iterações, o software atinge 
sua totalidade.
Determina objetivos, 
alternativas e 
restrições
Avalia alternativas 
e riscos
Desenvolve e 
testa
Restriç
ões 4
Restriç
ões 3
Restriç
ões 2
Restrições 1
Plano de implementação Teste de aceitação
Teste do sistema
Teste de 
unidades
Alternativas 1
Requisitos, 
plano do 
ciclo de vida
Plano de desenvolvimento
Plano de testes 
e de integração
Orçamento 1Orç
ame
nto
 2
Orça
men
to 3
Or
ça
me
nt
o 4
Análise de riscos 4
Análise de riscos 3
Protótipo 3 Protótipo 4
Projeto 
detalhado
Pr
oje
to
 de
 
so
ftw
ar
e
Projet
o verifi
cado 
e valid
ado
Valida
ção de
 
requis
itos
Re
qu
isit
os 
de 
sof
tw
are
Código
Análise de riscos 2
Protótipo 2
Análise de riscos1
Concepção 
da operação
Protótipo 1
Alt
ern
ativ
as 4
Alt
ern
ativ
as 3
Alt
ern
ativ
as 2
Início
Figura 25 – Modelo de processo espiral
63
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
O modelo espiral é mais adequado para sistemas complexos, softwares de grande porte e que 
exigem um alto nível de iterações com os usuários, o que possibilita uma melhor abordagem de todos 
os problemas do sistema.
Basicamente, o modelo espiral é dividido em quatro setores:
• Ativação: definem-se os objetivos específicos, identificam-se as restrições para o processo e é 
preparado um plano de gerenciamento detalhado. Identificam-se também os riscos sem analisá-los 
profundamente (foco da próxima fase).
• Análise de riscos: com base nos riscos identificados na fase anterior, são realizadas análises 
detalhadas e tomadas providências para amenizar esses riscos. Criam-se várias versões de 
protótipos para apoiar essa fase.
• Desenvolvimento: é fundamentado pelas fases anteriores. Escolhe-se o modelo mais adequado 
para o desenvolvimento do sistema. A bagagem profissional e a vivência do desenvolvedor em 
outros sistemas são estratégicas para essa fase. Dependendo da complexidade do sistema, às 
vezes é necessária a presença de um consultor especialista.
• Planejamento: o projeto é revisto nessa fase e é tomada uma decisão de realizar um novo ciclo, 
na espiral ou não. Se continuar com o aperfeiçoamento do sistema, é traçado um plano para 
a próxima fase do projeto. Um diferencial nesse modelo comparado com outros é a explícita 
consideração de riscos dentro do projeto como um todo. Para tanto, criou-se uma fase específica 
de análise de riscos nesse modelo.
4.1.6 RAD
Outros modelos se apresentam com grande utilidade. Alguns não deixam de ser a combinação de 
outros modelos, integrando dois ou mais conceitos de outros modelos, e um deles é o desenvolvimento 
rápido de aplicações (RAD – Rapid Application Development). Considerado um modelo misto e de 
características genéricas, é amplamente utilizado.
RAD é uma abordagem para desenvolvimento de software com objetivo de entregar software 
rapidamente. Comumente envolve o uso de ferramentas de programação de banco de dados e de apoio 
ao desenvolvimento, como geradores de telas e relatórios (SOMMERVILLE, 2011).
A estratégia para tais ações é o uso da abordagem de construção baseada em componentes. 
Assim, o desenvolvimento completo de um sistema de relativa complexidade (observe a figura 26) chega 
a atingir 60 a 90 dias.
64
Unidade II
Equipe n° 1
Equipe n° 2
Equipe n° 3Modelagem 
de negócios Modelagem 
de negócios Modelagem de negócios
Modelagem 
de dados
Modelagem 
de dados
Modelagem 
de dados
Modelagem 
de processo
Modelagem 
de processo
Modelagem 
de processo
Modelagem 
de aplicação
Modelagem 
de aplicação
Modelagem 
de aplicação
Teste de entrega
Teste de entrega
Teste de entrega
60 a 90 dias
Figura 26 – Modelo RAD
Enquanto outros modelos ficam na tentativa de abordar todas as principais atividades do 
desenvolvimento, o modelo de processo RAD permite que uma equipe crie um sistema plenamente 
funcional, dentro de um curto período. O modelo RAD é um processo de software incremental, que 
enfatiza um ciclo de desenvolvimento curto (PRESSMAN, 2002).
Vantagens do modelo RAD:
• RAD é um modelo sequencial linear, que enfatiza um ciclo de desenvolvimento extremamente 
curto. Possui entregas pequenas, entre 60 e 90 dias.
• O desenvolvimento rápido é obtido usando uma abordagem modularizada e de construção 
baseada em componentes. Esse processo traz facilidades de gerenciamento e para encontrar 
desvios no escopo.
• Os requisitos devem ser suficientes para alcançar o projeto restrito.
• O modelo RAD é usado principalmente para aplicações de sistemas de informação grandes e 
modularizados.
• Cada módulo ou função principal pode ser direcionada para uma equipe RAD separada e então 
ser integrada para formar o todo. Observe a figura 26.
• Visibilidade ao projeto, assim o cliente percebe pequenas entregas.
65
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Desvantagens do modelo RAD:
• Ressalta-se nesse modelo que se o sistema não for adequadamente modularizado, a construção 
de componentes necessários ao RAD será problemática.
• O RAD pode não ser adequado quando os riscos técnicos são altos, por exemplo, se existir a 
necessidade de uma aplicação usufruir tecnologias novas não dominadas pela equipe.
• Exige recursos humanos suficientes para todas as equipes.
• Exige que desenvolvedores e clientes estejam comprometidos com as atividades de “fogo-rápido” 
a fim de terminar o projeto num prazo curto.
• Nem todos os tipos de aplicação são apropriados para o RAD.
• Deve ser possível a modularização efetiva da aplicação. Se alto desempenho é uma característica 
do RAD e o desempenho do sistema estiver ligado ao sincronismo das interfaces dos componentes, 
a abordagem RAD pode não funcionar.
 Lembrete
O modelo incremental é o mais indicado na atualidade para o 
desenvolvimento de software, principalmente nos projetos orientados 
a objetos
4.2 Processo unificado
4.2.1 RUP
O processo unificado racional (RUP – Rational Unified Process) é um processo proprietário de 
engenharia de software criado pela Rational Software Corporation. Atualmente, é representado 
pela IBM, por isso ganhou um novo nome, o IRUP, que agora é uma abreviação de IBM Rational 
Unified Process.
O RUP é um processo da engenharia de software e também é considerado como uma metodologia 
de desenvolvimento de software. Fornece às organizações um processo de software maduro, 
rigoroso e flexível.
É distribuído on-line sob o formato eletrônico, utilizando tecnologia web, disponibilizando 
upgrades regulares de software pela Rational Software. A figura 27 ilustra o ambiente operacional 
via web do RUP.
66
Unidade II
Figura 27 – Plataforma de trabalho RUP pela web
O RUP pode ser configurado de acordo com as necessidades de cada organização. É documentado, 
desenhado, desenvolvido, distribuído e mantido como uma ferramenta de software usando a linguagem 
de modelagem unificada (UML – Unified Modeling Language).
4.2.1.1 Características do RUP
O RUP oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades 
dentro de uma organização de desenvolvimento. Sua meta é garantir que a produção de software de alta 
qualidade atenda as necessidades dos usuários dentro de um cronograma e de orçamentos previsíveis.
O RUP captura as principais boas práticas modernas da engenharia de software: desenvolvimento 
iterativo, gestão de requisitos, arquitetura baseada em componentes, uso de software de modelos visuais, 
verificação contínua da qualidade e gestão e controle de mudanças de software.
Desenvolvimento iterativo
Diferentemente do método clássico de desenvolvimento, um grande sistema de software não 
permite que se defina o problema e se construa uma solução eficiente em um único passo. Dependendo 
da complexidade, os requisitos mudam com frequência, devido a vários fatores, tais como: restrições 
67
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
da arquitetura empregada, mudanças nas necessidades primárias do cliente e mudanças refletidas em 
virtude de um refinamento do problema inicialmente levantado.
Tendo como base o desenvolvimento iterativo, é possível acomodar novos requisitos ou mudanças, 
aperfeiçoar o entendimento do projeto a cada refinamento sucessivo, endereçando os itens de risco e 
permitindo a identificação e atenuação dos riscos que circundam o projeto.
Cada iteração pode corresponder a um novo release do sistema, diminuindo o risco do projeto e, 
assim, permitindo ao cliente uma avaliação do progresso do projeto e de sua gerência (KRUCHTEN, 2001).
Gestão de requisitos
Documentar apropriadamente é crucial para o sucesso de um grande projeto. O RUP é conduzido 
por casos de uso e sustentado em outros diagramas da UML. O RUP descreve como documentar as 
funcionalidades, restrições do sistema, restrições do projetoe os requisitos por meio de casos de uso 
(use cases), desde a análise de requisitos até o teste do sistema finalizado. Os casos de uso e cenários são 
exemplos de artefatos do processo que se mostram altamente eficazes para documentar os requisitos 
funcionais (KRUCHTEN, 2000).
Arquitetura baseada em componentes
O RUP é baseado na arquitetura de componentes do sistema. Promove a definição inicial de uma 
arquitetura de software robusta, que facilita a parametrização do desenvolvimento, a reutilização e 
a manutenção.
Uma arquitetura baseada em componentes viabiliza um sistema extensível, promovendo a 
reutilização de software. Kruchten (2000) afirma que o RUP suporta essa sistemática de construção de 
sistema, focando-se numa arquitetura executável nas primeiras fases do projeto.
Uso de software de modelos visuais
Ao representar o projeto utilizando construções gráficas, o RUP apresenta de forma eficiente uma 
visão geral da solução, o que permite também que clientes sem nenhuma afinidade com a área de 
desenvolvimento de sistemas possam facilmente compreender o projeto e, dessa forma, desenvolverem-se 
mais com o projeto. A linguagem UML se transformou em um padrão para as indústrias ao representar 
projetos e é utilizada amplamente pelo RUP (KRUCHTEN, 2000).
Verificação contínua da qualidade
Assegurar a qualidade do software durante do desenvolvimento do projeto é algo intensivo feito 
pelo RUP, que assiste todo o processo envolvendo todos os membros no controle e planejamento da 
qualidade (KRUCHTEN, 2000).
68
Unidade II
Gestão e controle de mudanças do software
O RUP define métodos para controlar e monitorar as mudanças a fim de garantir que mudanças não 
venham a comprometer inteiramente o sucesso do projeto (KRUCHTEN, 2000).
4.2.1.2 Fases e workflow (ou disciplinas de trabalho)
Cada ciclo do RUP se divide em fases e o ciclo resulta numa nova geração do produto ou parte dele. 
Cada fase se divide em iterações a serem definidas em cada projeto concreto. O RUP possui quatro fases, 
seis disciplinas de trabalho e três disciplinas gerenciais.
Na figura 28 as fases são apresentadas na dimensão horizontal e o workflow, na dimensão 
vertical (disciplinas).
Fases
Disciplinas
Modelagem de negócios
Requisitos
Análise e design
Implementação
Teste
Implantação
Gerenciamento de 
configuração e mudança
Gerenciamento de projeto
Ambiente
Iterações
Iniciação
Inicial Elab. n° 1 Elab. n° 2 Const. n° 1
Const. 
n° 2
Const. 
n° N
Trans. 
n° 1
Trans. 
n° 2
Elaboração Construção Transição
Figura 28 – Arquitetura do RUP com suas fases e workflow
A figura 28 mostra um processo bidimensional na arquitetura do RUP. Na dimensão horizontal 
estão as fases do processo de desenvolvimento (estrutura dinâmica), representando mudanças no 
tempo de desenvolvimento; na dimensão vertical, os workflows (estrutura estática), representando 
mudanças no esforço despendido no desenvolvimento.
69
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Estrutura dinâmica
A estrutura dinâmica corresponde às quatro fases do RUP, que equivalem ao ciclo de vida 
do desenvolvimento de um produto de software. Ao final de cada uma dessas fases, verifica-se 
se os objetivos da fase foram concluídos. Após completar as quatro fases, uma versão release 
do software estará completa e, para cada nova versão, o software passará por todas as fases 
novamente (desenvolvimento evolucionário).
• Iniciação/Concepção (Inception/Conception)
— Definir o escopo e as fronteiras do sistema (contrato com o cliente).
— Elaborar casos de uso crítico ao sistema (atores e requisitos).
— Elaborar o business case do sistema, que deve incluir os critérios de sucesso, a avaliação de 
riscos, uma estimativa de recursos e um cronograma dos pontos mais importantes.
— No final: obter concordância dos stakeholders, compreensão dos requisitos e credibilidade nas 
estimativas. O projeto pode ser cancelado ou fortemente reformulado se falhar esse marco.
• Elaboração (Elaboration)
— Garantir que o projeto, a arquitetura e o conjunto de requisitos estejam estáveis para garantir 
o cumprimento de prazos e custos.
— Produzir protótipos evolucionários e exploratórios.
— Eliminar os elementos de maior risco.
— Descrever requisitos adicionais (não funcionais e com menor grau de importância).
— Revisar o business case.
— No final: obter estabilidade da arquitetura, demonstrar que o projeto é viável (tempo, custo) e 
que o projeto pode ser cancelado ou reformulado se falhar nesse marco.
• Construção (Construction)
— Minimizar custos através da utilização ótima de recursos.
— Desenvolver versões utilizáveis.
— Completar os processos de análise, projeto, implementação e testes das funcionalidades 
do sistema.
70
Unidade II
— Desenvolver de maneira iterativa e incremental um produto que esteja pronto para ser entregue 
aos usuários, um manual e uma descrição da versão corrente.
— Decidir se o software, o site e os usuários estão prontos para a implantação do sistema.
— No final: a disponibilização pode ser adiada se os critérios não forem cumpridos.
• Transição/Implantação (Transition): atividades de entrega do software
— Testar para validar o novo sistema.
— Treinar usuários e pessoas responsáveis pela manutenção.
— Iniciar as tarefas de marketing e distribuição.
— No final: obter satisfação dos clientes, gastos e custos dentro do aceitável.
Estrutura estática
Na estrutura estática, o RUP é representado por suas nove disciplinas (seis disciplinas de trabalho e 
três gerenciais). Cada uma delas utiliza quatro elementos primários de modelagem: papéis, atividades, 
artefatos e workflows.
• Papéis. Descrevem o comportamento e responsabilidades de um indivíduo ou grupo de 
indivíduos de uma equipe. O comportamento de cada papel é dado pelo conjunto de atividades 
desempenhadas por ele. As responsabilidades de cada papel estão associadas a artefatos que 
devem ser desenvolvidos ao longo do processo. Exemplo de papéis: especificador de casos de 
uso, arquiteto de softwares, projetista de interface, gerente de projetos.
• Atividades. Realizadas pelos papéis, consistem em ações que atualizam ou geram artefatos. 
A granularidade de uma atividade é expressa em horas ou dias. As atividades são divididas em 
etapas de tarefas: entendimento, realização, revisão.
O quadro a seguir destaca exemplos de atribuições de papéis e responsabilidades:
Quadro 4 
Atividade Papel
Planejar uma iteração Gerente de projetos
Determinar casos de uso e atores Analista de sistemas
Executar teste de desempenho Analista de testes de desempenho
71
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
• Artefatos. Informações produzidas, modificadas ou utilizadas ao longo do desenvolvimento 
de software. São utilizados como entrada para atividades e são produzidos como saída. 
Exemplos: modelos (de caso de uso, projetos), documentos (plano de negócios, conjunto de 
artefatos, plano de projeto), código-fonte.
• Workflow. Define uma sequência de atividades que produzem resultados observáveis na 
forma de artefatos. Pode ser expresso em forma de diagramas de sequência, colaboração 
e atividades. O workflow é apresentado em seis disciplinas de trabalho e três disciplinas 
gerenciais, descritas a seguir.
— Disciplinas de trabalho:
– Modelagem de negócio (business modeling). A intenção é melhorar o entendimento do 
negócio através do desenvolvimento de um modelo de negócios. Os documentos gerados 
são casos de uso de negócio e modelo de objetos de negócio.
– Requisitos (requirements). Possibilita um melhor entendimento dos requisitos do sistema 
partindo de um acordo com o cliente, com o objetivo de oferecer uma orientação aos 
desenvolvedores. É produzido um modelo de caso de uso detalhado e um protótipo do sistema.
– Análise e projeto (analysis and design). Os requisitos capturados na disciplina anterior 
são transformados em projeto. Modelos de análise e projeto são gerados.
– Implementação (implementation). Nessa fase, o projeto é transformado em código. 
A estratégiaé desenvolver o sistema em camadas, particionando em subsistemas. O resultado 
final é um componente testado que faz parte do produto final.
– Teste (test). Elaboração de testes e verificação se todos os requisitos foram cumpridos. 
Os documentos gerados são os modelos e casos de testes.
– Utilização (deployment). Torna o produto disponível para o usuário final. Responsável pelo 
empacotamento do produto, instalação, treinamento ao usuário e distribuição do produto.
— Disciplinas gerenciais:
– Gerenciamento de configuração. Controla as modificações e mantém a integridade dos 
artefatos do projeto.
– Gerenciamento de projeto. Descreve várias estratégias para o trabalho com um 
processo iterativo.
– Ambiente. Abrange infraestrutura necessária para o desenvolvimento do sistema.
72
Unidade II
4.2.2 Praxis
De acordo com Paula Filho (2015b), o modelo Praxis foi desenvolvido pela equipe de Barry Boehm 
com base no modelo de ciclo de vida espiral, com as mesmas raízes no processo unificado, porém com 
estrutura diferente de disciplinas.
Igualmente ao RUP, o modelo Praxis é dirigido por casos de uso, centrado na arquitetura, é iterativo 
e incremental. A modelagem do Praxis é feita com uso do EPF (Eclipse Process Framework), que facilita 
a adaptação, a personalização, a extensão e a evolução. Herda a arquitetura RUP, complementada por 
um metamodelo da parte estática do RUP e pelo perfil Praxis.
 Saiba mais
Leia a referência a seguir:
PAULA FILHO, W. P. O processo Praxis 3.0. Vdocuments, 17 abr. 2015b. 
Disponível em: https://bit.ly/2Oj7zFo. Acesso em: 3 mar. 2021.
4.3 Modelos de processo pessoal e de equipe
4.3.1 PSP
O processo de software pessoal (PSP – Personal Software Process) é um processo de desenvolvimento 
criado pelo SEI (Software Engeneering Institute) e é específico para engenheiros de software (HUMPHREY, 
1995). O PSP orienta o planejamento e o desenvolvimento dos componentes do software e tem como 
principais objetivos:
• melhorar a estimativa de prazo e esforço para o desenvolvimento do software;
• melhorar o planejamento e o acompanhamento de cronogramas;
• evitar sobrecarga de serviços;
• criar um comprometimento pessoal com a qualidade e com a melhoria contínua do processo.
 Observação
O PSP é um modelo de processo que ajuda os profissionais a serem 
melhores engenheiros de software. A ideia é que a melhoria da capacidade 
da organização depende da melhoria de cada indivíduo.
73
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
A estrutura do PSP é formada por quatro níveis, como mostra a figura 29:
PSP 2
Revisões de código
Revisões de projeto
PSP 1
Estimativa de testes
Relatório de testes
PSP 0
Processo atual
Registro de tempo
Registro de defeitos
Padrão de tipos de defeitos
Gestão de 
qualidade 
pessoal
Processo de 
planejamento 
pessoal
Processo 
de medição 
pessoal
PSP 3
Desenvolvimento cíclico
PSP 2.1
Padrões de projeto
PSP 1.1
Planejamento de tarefas
Cronogramas
PSP 0.1
Padrão de codificação
Medida de tamanho
PIP
Figura 29 – Estrutura do PSP
A proposta do PSP é interagir com as práticas organizacionais da qualidade (por exemplo: ISO 9001 
e ISO 9126) e de modelos de qualidade (CMMI e SPICE), de forma que os processos pessoais sejam 
conhecidos, controlados e melhorados.
As funções dos quatro níveis do PSP são:
• PSP0 (processo referencial): estabelecer práticas de medidas e alguns formatos de relatórios 
que constituem o referencial para a implantação da melhoria contínua pessoal. Não afeta as 
práticas de projeto, codificação e teste, apenas mede.
• PSP1 (processo de planejamento pessoal): acrescenta um relatório sobre testes e práticas de 
estimativa de tamanho e recurso. Depois introduz o planejamento de tarefas e a elaboração 
de cronogramas.
• PSP2 (processo de gestão pessoal da qualidade): introduz as técnicas de inspeção e revisão 
para detecção de erros mais cedo.
• PSP3 (processo pessoal cíclico): os níveis 0 a 2 são aplicáveis a pequenos programas. Para 
grandes projetos, é preciso usar os princípios contidos no nível PSP3.
74
Unidade II
Exemplo de aplicação
Estratégia de aplicação do PSP:
• Dividir o projeto em módulos.
• Realizar o desenvolvimento iterativo e incremental em cada módulo.
• Para cada iteração, usar um ciclo completo de: projeto, codificação e teste (como em PSP2).
• Controlar a qualidade de cada iteração, assumindo que a garantia das iterações anteriores foi 
conseguida ou, pelo menos, verificada.
4.3.2 TSP
O processo de software da equipe (TSP – Team Software Process) foi desenvolvido por Humphrey 
(1995) – criador do CMMI e PSP –, com enfoque na equipe de trabalho, já que o indivíduo não trabalha 
sozinho no desenvolvimento de software.
O TSP foi criado para ser seguido por desenvolvedores previamente treinados no PSP, para que 
pudessem trabalhar em equipes auto-organizadas para desenvolver softwares de qualidade, podendo 
vir a ser a solução para pequenas organizações de software que sejam consideradas muito pequenas 
para enfrentar as complexidades do CMMI.
As equipes são autogerenciadas:
• A gerência provê orientação e suporte.
• A equipe planeja o próprio trabalho, acompanha o progresso e gerencia as tarefas do dia a dia.
• Cada membro da equipe tem papéis e responsabilidades definidos.
• Todos os membros participam do planejamento do projeto e da tomada de decisões-chave.
• A equipe é proprietária dos seus processos e pode mudá-los sempre que necessário.
• Os processos da equipe são baseados em sua experiência, conhecimento e maturidade.
• As equipes aplicam práticas do nível 5 do CMMI.
O TSP provê um conjunto de elementos que guiam os desenvolvedores para: criar equipes eficazes; 
estabelecer metas e planos para a equipe; acompanhar e reportar o trabalho. Esse conjunto de elementos 
é formado por:
75
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
• Scripts de processos: são guias específicos de trabalho.
• Formulários, relatórios e gráficos: reporte sobre métodos e métricas aplicáveis, em que são 
gerados dados estatísticos a partir do histórico do projeto ou algum script de processo.
• Papéis: são definidos para cada membro da equipe, podendo adquirir as seguintes funções 
como papéis: responsável pela interação com o cliente, responsável pelo design, responsável pela 
implementação, gestor de testes, gestor de planeamento, gestor de processos, gestor de qualidade, 
responsável pelo suporte e líder de equipe.
O TSPi (Introductory Team Software Process) é uma versão simplificada do TSP para equipes e 
projetos menores, que apresenta a seguinte arquitetura:
• estrutura simples construída sobre o PSP;
• desenvolvimento incremental;
• métricas padronizadas de qualidade e desempenho;
• métricas precisas para equipes e indivíduos;
• uso de avaliações de papéis e de time;
• exigência de disciplina de processo;
• sugestões nos problemas do trabalho em equipe.
76
Unidade II
 Resumo
Toda a produção é organizada por processos, que são usados para criar 
um produto, para desenvolver, construir, implantar e manter o produto. 
Nesta unidade, vimos como projetar e aplicar determinado processo.
Enfatizou-se a estrutura organizacional como regra para construir um bom 
software, a qual tem ferramentas e técnicas específicas para produzi-lo. 
O arcabouço do processo compõe os recursos necessários para o projeto e 
a construção do produto.
Todo o processo é um conjunto de atividades e tarefas que, organizadas, 
conduzem a uma prática ou estratégia que melhoram a produtividade. 
Nesse contexto, a organização da equipe de desenvolvimento é de extrema 
importância, pois o software não é um produto manufaturado, é um produto 
criado pela engenharia inteligente dos interessados no software. Trata-se 
da inteligência organizacional, responsável pelo sucesso do software.
Toda a criação do produto software segue uma série de passos 
previsíveis. Se forem conduzidos por uma equipe capacitada, vão garantir 
o sucesso do software. Esses passos previsíveis são ditados em modelos 
de processoque mostram os métodos e as técnicas aplicadas no ciclo de 
desenvolvimento de software. Foram elencados os principais modelos: 
cascata, incremental, espiral, RAD, processos unificados, modelos 
pessoais e de equipe.
Por fim, foram abordadas as diversas formas de construir o software.
77
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
 Exercícios
Questão 1. Um processo é uma sequência de fatos, atividades ou operações que apresentam certa 
unidade e/ou que se reproduzem com determinada regularidade. Um processo deve ser delimitado pelos 
seus pontos de início e de fim. Os pontos de início (input) e de fim (output) são marcas de referências 
(milestones) úteis para o acompanhamento do processo. Essas marcas servem para controlar, medir e 
avaliar o processo. Além disso, permitem projetar melhorias e tendências.
Nesse contexto, analise as afirmativas.
I – O input é o ponto inicial, normalmente marca os itens necessários para dar entrada ao processo.
II – O processo é a combinação organizada dos itens de entrada para criar um produto de software 
ou de sistema.
III – No output, são feitos registros, medições e verificações para confrontar o resultado obtido com 
o objetivo planejado para o processo.
É correto o que se afirma em
A) I, apenas.
B) I e II, apenas.
C) II, apenas.
D) I e III, apenas.
E) I, II e III.
Resposta correta: alternativa E.
Análise das afirmativas
I – Afirmativa correta.
Justificativa: o input é o ponto inicial. Ele normalmente marca os requisitos de entrada do processo, 
como objetivos, recursos humanos necessários, materiais, tecnologia a ser empregada, fornecedores, 
componentes do software/sistema, metodologias, ferramentas, custo, cronograma, procedimentos de 
trabalho e documentos.
78
Unidade II
II – Afirmativa correta.
Justificativa: o processo é a combinação organizada dos itens de entrada para criar um produto 
de software ou de sistema, um componente de outro produto ou executar um determinado trabalho. 
O processo é a forma pela qual os inputs são trabalhados para que sejam obtidos os outputs.
III – Afirmativa correta.
Justificativa: o output é a finalização do processo com a entrega do produto ou serviço determinado. 
No output, são efetuados registros, medições e verificações para confrontar o resultado obtido com o 
objetivo planejado para o processo.
Questão 2. Entre os modelos de processo de software, podemos destacar:
• os modelos de processos tradicionais, como o modelo em Cascata, Balbúrdia, Prototipagem, 
Incremental, RAD e Espiral;
• os modelos de processo unificado, como os modelos RUP e Praxis;
• os modelos de processo pessoal e de equipe, como os modelos PSP e TSP.
Com relação ao modelo de processo tradicional em Cascata, avalie as asserções a seguir e a relação 
proposta entre elas.
I – Podemos afirmar que a vantagem do uso do modelo em Cascata reside no fato de ele poder ser 
aplicado em problemas complexos ou difíceis de resolver, por incluir vários componentes.
PORQUE
II – O modelo em Cascata é inflexível na divisão do projeto em estágios distintos, e qualquer 
problema que ocorra em uma das fases só poderá ser detectado após a entrega do software 
para o cliente.
A respeito dessas asserções, assinale a alternativa correta.
A) As asserções I e II são proposições verdadeiras, e a II é uma justificativa correta da I.
B) As asserções I e II são proposições verdadeiras, e a II não é uma justificativa correta da I.
C) A asserção I é uma proposição verdadeira, e a II é uma proposição falsa.
D) A asserção I é uma proposição falsa, e a II é uma proposição verdadeira.
E) As asserções I e II são proposições falsas.
Resposta correta: alternativa B.
79
FUNDAMENTOS DE ENGENHARIA DE SOFTWARE
Análise da questão
Apesar de o modelo em Cascata servir de base para outros modelos, a vantagem desse modelo está 
nas aplicações com sistemas estruturados, que são sistemas únicos e que operam em um ambiente 
operacional restrito, porém de alta capacidade. Outra vantagem é poder ser aplicado em problemas 
complexos ou difíceis de serem resolvidos.
A desvantagem do modelo em Cascata é ser inflexível na divisão do projeto em estágios distintos. 
Na prática, é impossível conseguirmos a totalidade dos requisitos no momento inicial do projeto, e 
qualquer problema que ocorra em uma das fases só poderá ser detectado após a entrega do software 
para o cliente, o que geraria retrabalhos ou até mesmo a extinção do projeto.
A visão do modelo em Cascata em geral não reflete o modo como o software é desenvolvido. 
Mudanças no software que ocorrem durante seu desenvolvimento não são previstas e, por consequência, 
não são previstas ações de verificação no processo inicial.
Note que as duas asserções são verdadeiras, entretanto, o fato de o modelo em Cascata ser inflexível 
não está atrelado à vantagem de ele ser aplicável em problemas complexos. Com isso, a alternativa 
correta é a B.