UTFPR - Caderno 2 - Processos de Desenvolvimento de Software

CADERNOS DE ENGENHARIA DE SOFTWARE
CADERNO 2
PROCESSOS DE DESENVOLVIMENTO DE
SOFTWARE
PAULO CÉZAR STADZISZ

DAINF – Departamento de Informática
UTFPR – Universidade Tecnológica Federal do Paraná
1º Edição
NOTA SOBRE ESTA EDIÇÃO
Esta é a primeira edição do Caderno 2 – Processos de Desenvolvimento de Software da série

Cadernos de Engenharia de Software, produzida no DAINF – Departamento Acadêmico de
Informática – da UTFPR. Este caderno, junto com os demais da série, tem por objetivo compor um
material didático de apoio ao ensino das disciplinas de Engenharia de Software nos cursos de
graduação e de pós-graduação em computação da UTFPR.
O conhecimento recolhido neste caderno origina-se dos livros clássicos e introdutórios de Engenharia
de Software, de publicações científicas produzidas pela comunidade nacional e internacional de
computação, de publicações técnicas oriundas de empresas e associações de software, das pesquisas
em Engenharia de Software conduzidas na própria UTFPR e da experiência do autor atuando no
mercado de desenvolvimento software e como pesquisador. Destaca-se, como fonte de informação,
o SWEBOK V3.0 – Guide to the Software Engineering Body of Knowledge (Swebok, 2014).
Trata-se de um documento produzido pelo IEEE Computer Society com uma grande reputação na
definição dos conhecimentos fundamentais e consolidados da área de engenharia de software.
Neste segundo caderno, aborda-se os Processos de Desenvolvimento de Software. O objetivo é

apresentar ao leitor uma visão geral de processos de desenvolvimento e as alternativas existentes, de
forma a desenvolver no leitor uma capacidade crítica sobre o tema. Busca-se, também, esclarecer
como os processos mais modernos de classificam frente a processos mais clássicos de
desenvolvimento. Entretanto, não é objetivo deste caderno detalhar os processos de maneira a servir
de curso de formação para cada um deles.
Prof. Dr. Paulo Cézar Stadzisz

Autor
2 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

SUMÁRIO
NOTA SOBRE ESTA EDIÇÃO ........................................................................................................................ 2

VISÃO GERAL DE PROCESSOS .................................................................................................................... 5
CONCEITO DE PROCESSO................................................................................................................................ 5
VISÃO ECONÔMICA DO DESENVOLVIMENTO DE SOFTWARE ........................................................................ 7
ENGENHARIA DE SISTEMAS ....................................................................................................................... 9
CONCEITO DE SISTEMA e ENGENHARIA DE SISTEMAS ................................................................................... 9
RELACIONAMENTO ENTRE ENGENHARIA DE SISTEMAS E ENGENHARIA DE SOFTWARE ............................. 11
MACROPROCESSO DE DESENVOLVIMENTO DE SISTEMA ............................................................................. 13
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ........................................................................ 23
VISÃO GERAL DE PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ........................................................ 23
PRINCIPAIS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ................................................................ 25
PROCESSO CLÁSSICO – WATERFALL – CASCATA........................................................................................... 26
PROCESSO POR PROTOTIPAÇÃO .................................................................................................................. 30
PROCESSO EM V ........................................................................................................................................... 33
PROCESSO POR REFINAMENTOS SUCESSIVOS - ITERATIVO ......................................................................... 37
PROCESO UNIFICADO - RUP ......................................................................................................................... 40
MÉTODOS ÁGEIS........................................................................................................................................... 40
DESENVOLVIMENTO DIRIGIDO A MODELOS ................................................................................................ 40
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................................................. 43

CADERNOS DE ENGENHARIA DE SOFTWARE
CADERNO 2
PROCESSOS DE
DESENVOLVIMENTO DE
SOFTWARE
“Given enough time, I can meet any software deadline!” (Clyde Calcote).
Desde o surgimento da Engenharia de Software, tem-se organizado o desenvolvimento de software

por meio de processos. Esta é uma prática intrínseca de todas as engenharias e que, atualmente, se
aplica, também, a praticamente todas as atividades em todas as organizações.
Neste caderno, busca-se apresentar os conceitos fundamentais de Processos de Desenvolvimento de

Software para que o leitor adquira uma clareza sobre o tema, podendo tirar o melhor proveito das
alternativas e limitações existentes. Leituras complementares são recomendadas ao longo do texto
para os leitores que desejem esclarecer ou estender o estudo.
Boa leitura e bem-vindo(a) ao tema!

VISÃO GERAL DE PROCESSOS
Como em todas as engenharias, a Engenharia de Software também estipula que o

desenvolvimento de projetos se apoie em um plano pré-concebido para realização das
atividades, denominado “processo de desenvolvimento”. Neste capítulo, apresenta-se o
conceito de “processo” e uma visão do ciclo econômico em torno do processo de
desenvolvimento de produtos de software.
CONCEITO DE PROCESSO
A definição comum dos dicionários para o termo “processo” é a de “uma série de ações que
são executadas com o objetivo de se alcançar um resultado particular”. Em geral, um
processo é construído por um ou mais conhecedores de um domínio visando prescrever uma
maneira apropriada de se realizar algum trabalho. Assim, os processos são análogos a
receitas, algoritmos ou modelos a serem seguidos quando se tem determinados objetivos a
alcançar. Os processos são descritos por ações ou atividades a serem realizadas, por decisões
a serem tomadas, por eventuais entradas e saídas, e por um encadeamento destas.
Existe uma semelhança entre alguns termos como técnica (i.e., maneira de realizar uma ação
visando a obtenção de um determinado resultado), método (i.e., meio utilizado para chegar a
um fim) e processo. Na atualidade, prefere-se empregar na engenharia e nas corporações o
termo “processo”, pois tem-se uma interpretação de ele define uma forma mais detalhada e,
inclusive, diagramática de se estabelecer como se organizam as atividades para atingir
determinado resultado.
Nas organizações o termo “processo” é, também, amplamente utilizado na modelagem de

seus negócios e faz parte da rotina de gestão de todas as empresas modernas. Além de os
processos fornecerem uma base para a organização dos negócios de uma empresa, seu
emprego foi motivado ainda mais pelo aparecimento dos chamados Programas de Qualidade
(como a família de normas ISO 9001). Estes programas servem para padronizar a forma de
trabalho e buscar corrigir ineficiências nos procedimentos de uma empresa por meio,
principalmente, da definição e posterior controle de todos os seus processos. Na área de
software existem, também, programas de qualidade específicos como o CMMI (Capability
Maturity Model Integration) desenvolvido pelo SEI da Universidade Carnegie Mellon e
mantido pelo ISACA. No Brasil, o Softex (Associação para Promoção da Excelência do
Software Brasileiro) desenvolveu o MPS-BR (Melhoria do Processo de Software – Brasil)
que é semelhante ao CMMI. Alguns deste programas de qualidade envolvem certificação, ou
seja, as empresas são auditadas para checar se estão cumprindo seus processos e para medir
o seu grau de maturidade.

Na área corporativa, a modelagem dos processos emprega uma linguagem amplamente
conhecida denominada BMPN (Business Process Model and Notation). A figura a seguir
ilustra um exemplo de processo modelado em BPMN. Neste exemplo, os dois retângulos
maiores com os rótulos “CLIENTE” e “SISTEMA DE INFORMAÇÃO” são denominados
“swinlanes” e separam os fluxos de ações realizados por um comprador em um site de vendas
da empresa (parte superior) e pelo sistema de informação que informatiza a venda (parte
inferior). O círculo simples a esquerda da swinlane do CLIENTE é o ponto de início do
processo, enquanto os círculos em negrito nas dois swinlanes representam o fim do processo.
Notar que há dois fins possíveis: um pela desistência de compra do cliente (na swinlane
superior) e outro pelo término do processamento de uma compra (na swinlane inferior). Os
retângulos representam ações e os losângos representam decisões. As linhas tracejadas
ligando elementos das swinlanes representam comunicações, ou seja, o próprio fluxo de
realização do processo.
Figura 1: Exemplo de processo de solicitação de um pedido modelado com BPMN.
Visando organizar, padronizar e obter a máxima eficiência no desenvolvimento de software,

as empresas buscam, também, estabelecer um processo para seu desenvolvimento. O
processo permite que se saiba antecipadamente “como” será conduzido o desenvolvimento,
quais atividades estão previstas, quem participa de cada uma, quais são os dados de entrada
e resultados de cada atividade e qual a ordem de execução das atividades, entre outros,
criando um padrão de trabalho para a equipe. O processo de desenvolvimento define, ainda,
uma base para melhoria contínua, ou seja, ao término de cada projeto, a equipe avalia seu
desempenho e resultados alcançados e pode ajustar o seu modelo de trabalho (i.e., seu
processo) para buscar melhorar seu desempenho.

VISÃO ECONÔMICA DO DESENVOLVIMENTO DE SOFTWARE
Um desenvolvimento de software se inicia com a informação de uma demanda de mercado

(ou de um cliente específico ou, ainda, com uma escolha da própria empresa desenvolvedora)
e se encerra com um software produzido e pronto para entrega ou oferta aos clientes.
Entretanto, seguramente, o desenvolvimento de um software faz parte dos negócios de uma
empresa e está envolvido com sua atividade econômica, pois as empresas de software
produzem software para serem vendidos e gerar rendimentos para sua manutenção e
crescimento. A figura 2 ilustra, de maneira bastante simples que o desenvolvimento de
software é um negócio (i.e., uma das atividades em uma empresa de software) e que faz parte
de seu ciclo de funcionamento. De um lado (a esquerda e na forma de uma nuvem), e fora da
empresa, está o mercado, ou seja, o conjunto de clientes alvo dos produtos da empresa. Do
outro lado, a direita, está(ão) o(s) produto(s) de software que a empresa gera e “deseja”
vender ao mercado. Obtendo sucesso (e.g., conseguindo convencer os clientes a comprarem
seus produtos), a empresa aufere rendimentos que realimentam (i.e., cobrem os custos) de
desenvolvimento de seus produtos de software. Estes rendimentos, devem cobrir também os
custos com os demais setores da empresa, notadamente a administração e o marketing e
comercial, além de tributos e eventuais retornos de investimento e lucro. Cria-se, assim, um
ciclo contínuo de desenvolvimento e venda de software que, enquanto ativo, manterá a
empresa em funcionamento. É claro que todo ciclo deve ter um começo e, nesse caso, a
empresa deve primeiramente desenvolver um produto, para, então, poder vendê-lo e fazer
girar o seu ciclo econômico. Neste primeiro ciclo e, talvez, em alguns seguintes, será
necessário um aporte de investimento visando sustentar estes ciclos iniciais deficitários. Este
investimento será devolvido à empresa ou a sua fonte (como um banco ou investidor) a
medida em que os ciclos econômicos forem ocorrendo e produzindo retorno do investimento
feito.

Figura 2: Visão do ciclo econômico de desenvolvimento de software.
Um ponto importante a destacar na figura 2, é a ilustração da linha contínua que mostra o

fluxo do ciclo e que se torna tortuosa e pontilhada quando passa pela nuvem que representa
o mercado. Esta ilustração lembra que esta é uma parte do ciclo que não está sob o controle
da empresa e que não pode ser garantida. Ela representa a opção ou não de compra pelos
clientes. Se a venda ocorrer, o ciclo pode girar favoravelmente. Do contrário, o ciclo se
interrompe, levando à falência do negócio. Não existe uma fórmula definitiva para garantir
que o cliente irá optar por aceitar a oferta e efetuar a compra. Há um número gigantesco de
estudos, orientações e práticas para melhorar a chances de venda, mas nunca haverá certeza
dela. Em geral, pode-se dizer que um cliente se interessará pela compra, se o produto
corresponder, em algum grau, ao que ele busca. Ou seja, o produto deveria se mostrar útil
para o cliente e deveria atender suas exigências em termos do que ele faz ou entrega de valor
e tem como características. Ainda, assim, o cliente pode ficar reticente, pois outros fatores
sociológicos (e.g., modismos, marca, imagem da empresa), econômicos (e.g., preço,
condições de pagamento) e, mesmo, psicológicos (e.g., sentimento do cliente pelo produto,
motivação e estado de espírito) podem igualmente afetar sua decisão de compra. Poderia ser
dito, metaforicamente, que a venda é quase que um “momento mágico”, ou seja, quando algo
que não se controla completamente ocorre, sem que sua razão precisa seja conhecida.
Dentro do ciclo econômico desenhado está a atividade de “Desenvolvimento de Software”,

na qual a Engenharia de Software é aplicada. Não é incomum que os profissionais desta área
deem foco nas suas atividades técnicas, se envolvendo pouco com o ciclo econômico em si,
notadamente com marketing e vendas. Entretanto, é importante destacar que os profissionais
de desenvolvimento de software são parte integrante do ciclo econômico e, assim, deveriam
estar engajados neste ciclo. Como dito por Philip Kotler, “em uma empresa ou você está
vendendo ou deveria estar ajudando a vender”. Desta forma, os profissionais de
desenvolvimento de software deveriam sempre considerar como o produto que estão
desenvolvendo pode ser tornar um produto mais “vendável”, ou seja, que amplifique ou
maximize as chances de venda e que, assim, ajude o marketing e comercial a obter mais
sucesso para a empresa. Essa postura é possível e pode ter grande impacto. Por exemplo, se
o software for desenvolvido com uma interface com usuário atraente e ergonômica, ele será,
seguramente, mais “vendável”. Se o software tiver poucas falhas de funcionamento, ele será
mais “vendável”. Se ele for melhor do que os produtos dos concorrentes, ele, também, será
mais vendável. Se ele tiver um menor custo de desenvolvimento, seu preço poderá ser mais
atrativo e ele será mais “vendável”. Da mesma forma, se o software satisfizer os requisitos
do cliente, ele será muito “vendável”. Assim, um bom alinhamento do setor de
desenvolvimento com o setor de marketing e comercial é vital para todas as empresas
alcançarem sucesso em seu ciclo econômico.

ENGENHARIA DE SISTEMAS
Neste capítulo discute-se o conceito de “sistema” e de “engenharia de sistemas” com o

objetivo é esclarecer estes termos que frequentemente trazem alguma confusão na área de
software e que, cada vez, mais são importantes aos desenvolvedores. Discute-se, também, a
relação em Engenharia de Software e Engenharia de Sistemas e apresenta-se uma visão geral
da Engenharia de Sistema na forma de um macroprocesso e posiciona-se o desenvolvimento
de software dentro desta visão.
CONCEITO DE SISTEMA E ENGENHARIA DE SISTEMAS
É comum empregar-se o termo “sistema” na área de desenvolvimento de software. Nomes

como “sistemas de informação”, “analista de sistemas”, “sistema operacional” e “sistemas
de gestão” são bastante comuns. Entretanto, frequentemente, este termo “sistema” é
considerado sinônimo de “software”, o que não é correto.
A definição de software já foi esclarecida no “Caderno 1 – Introdução à Engenharia de

Software” em que se apresentou duas visões. Uma definição era baseada na composição do
software, dizendo que um “software era um conjunto de códigos fonte e executável,
documentações técnicas, registros de propriedade, bases de dados, entre outros”. Outra
definição focava na natureza do software, ou seja, no fato de ele representar a lógica de
operação desejada para se alcançar um determinado resultado usando um computador.
Por outro lado, a definição de “sistema” é bem mais abrangente e mais antiga, não se
limitando à área de computação. A palavra vem do latim systema e do grego sýstema
significando “aquilo que permanece junto”. A definição mais comum de “sistema” dos
dicionários é: “Um sistema é uma coleção de elementos ou componentes que são organizados
para operarem em conjunto visando alcançar um propósito comum.”. Analogamente,
segundo o INCOSE (International Council on System Engineering), “Um sistema é um
arranjo de partes ou elementos que juntos exibem um comportamento e significado que os
constituintes individuais não têm”. O conceito de “parte” está relacionado com a noção de
Aristóteles quando ele afirma que “O todo é mais que a soma das partes.”.
O conceito de sistema, suas propriedades e aplicações foi desenvolvido no último século

culminando na elaboração da Teoria Geral de Sistemas (TGS), assim denominada pelo
biólogo austríaco, Ludwig von Bertalanffy, na década de 60. Entre outras coisas, o conceito
de sistema traz a noção de hierarquização em que uma parte de um sistema pode, ao mesmo
tempo, ser também um sistema (ou melhor, um subsistema) também composto por parte

menores. Ou seja, um sistema pode ser decomposto em subsistemas, cada qual reunindo um
conjunto de partes que juntas têm uma identidade e desempenham um papel comum. De
forma análoga, um sistema por ser considerado uma parte de um sistema maior, ou seja, um
sistema de sistemas. Assim, uma organização de sistema poderia ser descrita em múltiplos
níveis de subsistemas. Essa noção permite que se faça abstrações, enxergando um sistema,
horas em um nível de abstração mais elevado, focando nos macros componentes, e horas em
níveis menos abstratos, destacando partes mais primárias. Esta visão permite entender e
organizar melhor sistemas mais complexos e é um instrumento essencial da engenharia na
atualidade.
A figura 3 ilustra o conceito de hierarquia de sistema por meio do exemplo da descrição de

componentes de um carro. Um carro é um sistema composto de partes como roda, porta e
motor, entre outras. Algumas destas partes podem ser entendidas como sistemas (ou
subsistemas), como no caso do motor, e podem ser detalhadas como um sistema em separado.
Além disso, um carro pode ser considerado parte de um sistema maior (e.g., um sistema de
trânsito) formado por outros veículos, semáforos, ruas e sinalizações.
Figura 3: Organização de sistemas e subsistemas.
Sistemas podem ser naturais (e.g., sistema solar, sistema digestivo ou nervoso de um ser vivo,
uma árvore) ou artificiais criados pelo ser humano (e.g., um carro, um submarino, um sistema

de trânsito, um sistema elétrico). Eles podem, também, ser classificados em físicos (e.g., uma
cidade, um carro ou um prédio) ou abstratos (e.g., um sistema social ou político).
A partir dos anos 40, em consequência da segunda grande guerra e, também, da evolução
tecnológica, governos e empresas passaram a desejar desenvolver produtos de maior porte e
de maior complexidade. Projetos de maior porte trazem dificuldades adicionais para se
garantir que o todo seja consistente e que opere de forma apropriada e eficiente com todas as
suas partes. Considere, por exemplo, o desenvolvimento de um submarino, de um porta
aviões ou de um sistema bancário. Para conceber e desenvolver tais produtos, é necessária
uma visão mais ampla do conjunto e das diferentes disciplinas envolvidas (e.g., engenharia
mecânica, elétrica, computação, design). Para permitir desenvolver produtos (i.e., sistemas)
deste porte foi criada a Engenharia de Sistemas. Trata-se de uma nova engenharia, distinta
das demais, cujo papel é o desenvolvimento do todo e não de uma especialidade de
engenharia. Por exemplo, o desenvolvimento de um submarino, não é um projeto de
engenharia mecânica exclusivamente, nem de engenharia elétrica ou computação. Neste
caso, é a engenharia de sistemas que deveria ser aplicada, levando em conta o conjunto
heterogêneo de partes. Engenheiros mecânicos, eletricistas e de computação participarão do
desenvolvimento de subsistemas, mas a responsabilidade pela concepção do todo é do
engenheiro de sistemas.
A criação e evolução da Engenharia de Sistemas permitiu aos países desenvolvidos

produzirem sistemas de grande porte e grande complexidade que tiveram grande sucesso e
impacto na sociedade, como usinas nucleares, novos armamentos de defesa, automação em
larga escala e missões espaciais. Nesses países, a Engenharia de Sistemas é uma área de
conhecimento estabelecida, tendo uma formação profissional específica. Para dar suporte,
disseminar os conhecimentos e dar visibilidade a esta área de conhecimento, foi criado em
1990 o INCOSE (The International Council on Systems Engineering) que é principal
referência em engenharia de sistemas no mundo.
RELACIONAMENTO ENTRE ENGENHARIA DE SISTEMAS E ENGENHARIA DE

SOFTWARE
Enquanto a Engenharia de Software se aplica unicamente ao desenvolvimento de software, a

Engenharia de Sistemas se envolve com a concepção de sistemas como um todo, que podem
ou não incluir software. Quando sistemas incluem softwares como componentes, além de ser
necessário aplicar a Engenharia de Sistemas para o todo, será preciso aplicar a Engenharia
de Software para as partes de software do sistema. Neste caso, a Engenharia de Sistemas faz
a análise de segurança, a especificação do sistema, a concepção da arquitetura e
comportamento de todo o sistema, além da alocação dos requisitos aos subsistemas. Desta

forma, o desenvolvimento de software parte de uma definição do conjunto do sistema e das
especificações de o que o software deverá fazer e ter como características, de maneira que
ele, como um componente, cumpra seu papel e seja consistente com as outras partes do
sistema do qual faz parte.
No sentido contrário, poderíamos nos perguntar se todo desenvolvimento de software requer

uma Engenharia de Sistemas. É fato que nenhum software existe ou opera completamente
sozinho ou isolado. É comum que os softwares interajam com outros elementos, como
ilustrado na figura a seguir. Neste exemplo, observa-se que o software interage com o
hardware do computador (seguramente via sistema operacional) e, também, com outros
dispositivos (e.g., impressora, mouse, teclado e monitor), com eventuais sensores (e.g.,
sensor de temperatura, botões físicos, sensor de presença) e atuadores (e.g., motores e
chaves). Adicionalmente, o software pode interagir com outros softwares como um servidor
de banco de dados (SBD), algum outro software de aplicação, framework e sistema
operacional. Além disso, um software pode, também, interagir com pessoas (e.g., usuários e
administrador do software), embora isso se faça, seguramente, via dispositivos, pois não há
forma de interação direta entre software e ser humano.
Figura 4: Ilustração de um software como componente de um sistema.
Um software interagindo com um conjunto de elementos externos, como ilustrado na figura

4, tem um ou mais propósitos, compondo um “sistema”. Assim, pode-se entender que um
software “sempre” será parte de um sistema, pois ele sempre precisa interagir com outros
componentes para produzir qualquer resultado. Exatamente por isso, é comum que alguns
sistemas que incluem softwares sejam referenciados como “sistemas de informação” ou
“sistemas de computação”. Nomes como esses, destacam que se trata de um sistema com
vários componentes, em que o software tem um papel destacado (i.e., é o elemento principal
que caracteriza o produto em si).
Embora todo software faça sempre parte de um sistema maior, nem sempre é necessário que
se aplique a Engenharia de Sistemas para, então, realizar-se o desenvolvimento de software.
Alguns sistemas de computação e de informação tem o software como componente
fundamental e os outros componentes são padrões e usuais (e.g., hardware de PC, monitor,

mouse e teclado padrões, usuário). Neste caso, a concepção do “sistema” se confunde com a
concepção do software, pois não há nada a ser projetado além do software, e uma Engenharia
de Sistemas não seria requerida. Na medida em que componentes adicionais existam, como
vários usuários com diferentes papéis, outros softwares de terceiros com os quais interagir
ou outros dispositivos não comuns, a concepção do sistema e o uso da Engenharia de
Sistemas se tornam mais relevantes.
MACROPROCESSO DE DESENVOLVIMENTO DE SISTEMA
Na condição de que um software é parte de um sistema maior e significativo, seu

desenvolvimento estaria vinculado ao desenvolvimento do sistema maior do qual ele é um
dos componentes. A figura 5 ilustra um macroprocesso (i.e., uma estruturação de processos
de mais alto nível) de desenvolvimento de sistemas contendo as principais atividades
envolvidas. Os blocos internos representam as atividades do processo que são realizadas
cronologicamente da esquerda (início) até a direita (fim). Assim, mais ao início, é feita
especificação e projeto do sistema (ou seja, o desenvolvimento do sistemas por meio da
aplicação da Engenharia de Sistemas) e o planejamento do desenvolvimento. A seguir, são
realizados os desenvolvimentos das partes do sistema empregando engenharias mais
especializadas, entre elas a Engenharia de Software, destacada em azul claro. As atividades
em verde são consideradas atividades de suporte.
Figura 5: Visão geral de um macroprocesso de desenvolvimento de sistema.

Descreve-se, a seguir, cada uma das atividades dentro do macroprocesso de desenvolvimento
de sistema, ilustradas na Figura 5.
• Desenvolvimento de Sistema (Engenharia de Sistema)
O primeiro bloco ou atividade no macroprocesso ilustrado na figura 5 é o de especificação e

concepção (i.e., desenvolvimento) do sistema, no qual se aplica os conhecimentos de
Engenharia de Sistemas. As principais ações envolvidas são brevemente discutidas a seguir.
Ao término desta atividade, o sistema, como um todo, estará especificado em termos de seus
requisitos (incluindo requisitos de segurança), sua estruturação em subsistemas,
componentes e interrelações, e seu comportamento esperado.
i) SAP (Safety Assessment Process) – Processo de Avaliação de Segurança
O processo de avaliação de segurança (SAP - Safety Assessment Process) é um método para

avaliar as funções e o projeto de um sistema para determinar se os riscos de danos (i.e.,
hazards) associados a estas funções foram tratados apropriadamente. Este método inclui as
atividades de análise de riscos funcionais (Functional Hazard Assessment - FHA), análise
preliminar de segurança de sistema (Preliminary System Safety Assessment - PSSA) e a
análise de segurança de sistema (System Safety Assessment - SSA).
A análise de segurança visa determinar quais são os riscos de falhas do futuro sistema e seus
efeitos, em especial relativo à integridade de pessoas. A determinação do nível de risco
associado a um sistema é essencial, pois a forma de condução da engenharia do sistema s
seguir será diferente de acordo com os riscos de segurança existentes. Para sistemas com
riscos maiores, o rigor da engenharia também deverá ser maior. Os riscos de falhas podem
estar associados às diversas funções e componentes do sistema, inclusive dos softwares.
Existem técnicas consagradas para a análise de segurança de sistemas como FMEA (Failure
Mode and Effect Analysis) e FMECA (Failure Mode, Effects & Criticality Analysis),
desenvolvidas a partir do final dos anos 40 e aperfeiçoadas ao longo do tempo. Basicamente,
estas técnicas consistem no estudo por parte do engenheiro, das possíveis ocorrências de
falhas (chamadas “modos de falhas”), como, por exemplo, “Falha em detectar a aproximação
de uma pessoa” ou “Falha em acionar o motor de abertura” em um sistema de porta
automática. A seguir, estuda-se as possíveis causas de cada modo de falha e o efeito destas
falhas. No exemplo do primeiro modo de falha, a causa poderia ser a “Falha de operação do
sensor de proximidade”, seu o efeito local seria “A porta automática não abre” e seu efeito
global seria “Há probabilidade da pessoa passante se chocar contra a porta.”, pois ela poderia
esperar que a porte se abriria. Estuda-se, também, outros aspectos das falhas como sua
frequência, probabilidade de ocorrência e o quão severa a falha é. Finalmente, analisa-se
quais ações podem ser tomadas, em termos de projeto do sistema, para minimizar ou evitar
a ocorrência de tais falhas. Por exemplo, no caso da porta automática, “O sensor de
proximidade deverá ser substituído a cada 6 meses que seu período de vida útil médio.”

É importante lembrar que a garantia de segurança de sistemas é uma obrigação dos
engenheiros (e demais profissionais envolvidos) e que quando um sistema falha gerando
danos materiais e à integridade dos usuários, os engenheiros e empresas responsáveis podem
ser responsabilizados técnica, civil e criminalmente.
ii) System Requirements Specification - Especificação de Requisitos do Sistema
A atividade de especificação de requisitos é realizada bem ao início do desenvolvimento do

sistema e tem por objetivo definir de forma precisa quais são suas funções (e.g., coisas que o
sistema deverá fazer) e quais suas características (i.e., suas propriedades, restrições e
condições). Essas definições são feitas baseando-se na demanda do mercado ou de algum
cliente em particular e expressam “o que” deve ser alcançado com o sistema a ser
desenvolvido. Esta especificação irá, assim, guiar todas as atividades que serão realizadas a
seguir e serão a referência para se saber se o sistema, ao final, alcançou ou não os objetivos
previstos. Certamente, a especificação de requisitos é uma atividade crítica, também, para o
sucesso do sistema no mercado, ou seja, para satisfazer a demanda e tornar o sistema atraente
para os clientes.
iii) System Architecture – Aquitetura do Sistema
A definição da arquitetura do sistema é uma atividade criativa de concepção de uma solução

para atender aos requisitos especificados. A arquitetura descreve a organização ou estrutura
do sistema na forma de um conjunto de componentes e relações entre eles. Esta organização
pode, eventualmente, ser estruturada de forma hierarquizada visando facilitar a compreensão
e melhor definir as partes ou subsistemas.
iv) System Behaviour – Comportamento de Sistema
A definição do comportamento do sistema é, também, uma atividade criativa de concepção

de uma solução para atender os requisitos especificados. Em vez de focar na estrutura, como
ocorre na definição da arquitetura do sistema, a definição do comportamento foca na
dinâmica do funcionamento e comunicação entre os subsistemas e partes do sistema.
• Planejamento do Desenvolvimento
Na prática, em simultaneidade com a especificação e concepção do sistema, pode-se

desenvolver a atividade de Planejamento do Desenvolvimento do sistema. Na figura 5, a
atividade Planejamento do Desenvolvimento está desenhada abaixo e um pouco a direita da
Engenharia de Sistema, indicando que esta atividade iniciaria pouco depois do início e
seguiria em paralelo com a Engenharia de Sistema. Trata-se de um planejamento de caráter
mais técnico, cujos objetivos são definir padrões para o projeto e planos para as atividades a
serem realizadas. Este planejamento é feito para as atividades em azul e verde na figura 5.

Não se deve confundir este planejamento técnico com o planejamento e gestão do projeto
(i.e., planejamento e gestão administrativos), o que, infelizmente, não é incomum. No
planejamento e gestão administrativos são definidos, entre outros, cronogramas físico e
financeiro, orçamento, recursos humanos necessários, programas de qualificação, aquisição
de recursos, marcos do projeto e indicadores. Este tipo de planejamento e posterior gestão da
execução estão associados à atividade de Gerenciamento de Projeto (Project Management –
PM), conduzida pelo Gerente de Projetos (Project manager – PM) e que está ilustrada na
caixa verde mais superior da figura 5.
A atividade de Planejamento do Desenvolvimento é realizada pelo corpo técnico da equipe

de desenvolvimento incluindo analistas e engenheiros, entre outros, e envolve duas
subatividades fundamentais: elaboração dos Padrões de Desenvolvimento e elaboração dos
Planos de Desenvolvimento, conforme discutido a seguir.
A elaboração dos Padrões de Desenvolvimento tem por objetivo construir documentos

contendo as referências (ou seja, modelos ou padrões) que servirão de padronização ou
uniformização para os documentos técnicos a ser elaborados pela diferentes membros da
equipe. A intenção é que toda a equipe utilizem mas mesmas notações, formatos,
nomenclaturas, formas de organização e descrição, modelos e técnicas, evitando que os
membros da equipe elaborem documentos técnicos muito distintos uns dos outros. Estes
padrões ajudam na comunicação das informações facilitando a leitura e interpretação dos
documentos por todos e aumentando a produtividade da equipe. Em geral, os padrões são
definidos baseados nas melhores práticas de engenharia, em normas ou padrões
internacionais e no próprio consenso da equipe sobre suas preferências.
Os exemplos mais comuns de padrões são: Padrão de Especificação de Requisitos

(Requirements Specification Standard), Padrões de Projeto (Design Standard), Padrão de
Construção ou de Programação (Coding Standard) e Padrão de Verificação (Verification
Standard). Descreve-se, a seguir, estes quatro padrões.
i) Um Padrão de Especificação de Requisitos define uma maneira uniformizada da equipe

de desenvolvimento escrever o documento de requisitos. Este padrão descreve a estrutura do
documento, a forma de organização da descrição dos requisitos em seções do documento, a
forma redação dos requisitos funcionais e não funcionais, a forma de rastreabilidade a ser
adotada e os próprios termos a serem empregados. Ele poderá conter, também, parâmetros
de qualidade para os requisitos, referências à normas ou padrões usados e a descrição das
responsabilidades da elaboração da especificação.
ii) Um Padrão de Projeto é um documento que define um modelo ou forma padronizada de

elaboração dos documentos técnicos de projeto de um software a ser adotado por toda a
equipe de desenvolvimento. Mesmo quando se utiliza uma linguagem padrão, como a UML,
sua forma de utilização, a escolha dos diagramas desejados e outros aspectos, como a forma

de nomear as entidades (e.g., classes, pacotes, componentes e diagramas), pode variar muito
de um profissional a outro. Desta forma, o Padrão de Projeto define uma maneira uniforme
de elaboração dos artefatos de projeto, evitando diferenças muito grandes no estilo ou
interpretação dos artefatos e facilitando a comunicação do time e, mesmo, aumentando a
produtividade da equipe.
iii) Um Padrão de Codificação é um documento que define uma forma padronizada de

construção dos programas (i.e., codificação). Mesmo que todos os membros da equipe
utilizem a mesma linguagem de programação, há muitos estilos ou forma diferentes de
programação. A definição de um modelo para todos os profissionais, auxilia a comunicação
e facilita a interpretação dos códigos produzidos dentro da equipe, melhorando a
produtividade do desenvolvimento. Um Padrão de Codificação, em geral, descreve regras de
definição do nome de variáveis, classes, arquivos e demais estruturas; formas de estruturação
do código (e.g., tabulações, alinhamentos e espaçamentos entre linhas); e padrões para
comentários e cabeçalhos, além de eventuais regras de programação para determinados casos.
iv) Um Padrão de Verificação é um modelo de como elaborar os documentos de verificação

de um desenvolvimento de software, ou seja, dos documentos de planejamento de testes, de
inspeção e de revisão. Para realizar a atividade de verificação, existem muitas opções de
técnicas, nomenclaturas e modelos. O Padrão de Verificação organiza um formato padrão a
ser adotado pela equipe para os artefatos de verificação, facilitando a comunicação e trabalho
dos profissionais.
Além dos padrões, o planejamento do desenvolvimento envolve, também, a elaboração de

planos de desenvolvimento. Cada plano é elaborado como um documento e descreve como
uma determinada atividade deverá ser conduzida pela equipe. O objetivo é definir uma
maneira adequada e padronizada para realizar cada atividade do desenvolvimento. A decisão
sobre quais planos deverão ser elaborados cabe à chefia do desenvolvimento e acordo com a
equipe de profissionais. Lista-se a seguir alguns planos de desenvolvimento mais comuns.
i) PSAC – Plan for Software Aspects of Certification (Plano dos Aspectos de

Certificação de Software)
Este tipo de plano é elaborado quando um determinado software deverá ser certificado por
uma agência reguladora, como a ANAC (Agência Nacinal de Aviação Civil), e deverá
atender a normas que regulamentam o desenvolvimento de software em determinado setor,
como o setor aeronáutico. Como todo plano, o PSAC é elaborado antes do início do
desenvolvimento do software e encaminhado ao agente regulador. O plano fornece às
autoridades de certificação uma visão geral dos meios de adequação do desenvolvimento às
normas em vigor e dos aspectos de planejamento para o desenvolvimento do produto. A
agência reguladora, em geral, irá revisar e aprovar o plano e o utilizará para o
acompanhamento do desenvolvimento por um auditor.

ii) Software Requirements Specification Plan (Plano de Especificação de Requisitos de
Software)
Este plano descreve de que forma a atividade de especificação de requisitos deverá ser
realizada. Existem várias técnicas, métodos e abordagens alternativos para uma equipe
realizar a especificação de requisitos de um software, envolvendo reuniões com o cliente,
questionários, escrita de estórias do usuário (i.e., user´s stories), análises de mercado, análises
de segurança, validação de requisitos, modelagem formal, entre outros. O plano de
especificação de requisitos determina o que e como a equipe deverá realizar esta atividade
para o desenvolvimento do software em questão, de maneira que não haja dúvida sobre como
conduzir as ações.
iii) Software Development Plan (Plan de Desenvolvimento de Software)
Este plano se refere à forma de realização das atividades de projeto e construção de um

software. Como existem muitas maneiras alternativa de se realizar o projeto e a construção
de um software, que variam segundo a cultura e experiência da equipe e segundo as
características do mercado e do software, é necessário que um plano de desenvolvimento seja
elaborado para definir a forma de trabalho a ser adotada. Em particular, este plano deve conter
o Processo de Desenvolvimento a ser aplicado, que descreve a abordagem e as atividades
envolvidas no desenvolvimento. O plano deve descrever como o projeto será realizado e
como a codificação do software será conduzida.
iv) Software Verification Plan (Plano de Verificação de Software)
Este plano determina como será realizada a atividade de Verificação durante o

desenvolvimento do software. Existem muitas técnicas de teste, inspeção e revisão que
podem ser aplicadas no desenvolvimento de software e que, também, variam de acordo com
o nível de qualidade exigido para o software (e.g., testes funcionais, testes de cobertura, testes
de regressão). Existem, também, diferentes abordagens de testes manuais e automação de
testes e diferentes ferramentas de testes que podem ser adotadas. Assim, é importante que a
equipe determine a forma como irá desenvolver esta atividade de verificação de maneira que
se saiba, antecipadamente, o que será feito e como será conduzida a atividade.
v) Software Configuration Management Plan (Plano de Gerenciamento de Configuração

de Software)
O gerenciamento de configuração (CM - Configuration Management) é a atividade

relacionada com o controle de todos os artefatos desenvolvidos e das alterações realizadas
sobre eles ao longo do desenvolvimento, incluindo, por exemplo, o controle de versão dos
arquivos. O plano de Gerenciamento de Configuração deve descrever quais funções de CM
serão adotadas (imagina-se que no mínimo deverá haver controle de versão), como elas serão

realizadas, quais ferramentas serão empregadas e quais serão os papéis e responsáveis na
equipe de desenvolvimento.
vi) Software Quality Assurance Plan (Plano de Garantia de Qualidade de Software)
A garantia de qualidade (QA – Quality Assurance) é uma atividade que acompanha o

processo de desenvolvimento de software tendo como objetivo checar se o processo de
desenvolvimento planejado está sendo seguido por toda a equipe. Trata-se de uma auditoria
com a intenção de garantir a “qualidade” da aplicação do processo de desenvolvimento.
Entende-se que, quando um desenvolvimento se distancia do processo planejado, este
desenvolvimento é de má qualidade, pois estaria sendo feito de forma desorientada e não
sistemática. Assim, a QA se baseia em uma abordagem de processos, típica dos programas
de qualidade como ISO 9000, CMMI e MPS-BR.
O plano de QA deve determinar a forma de realizar a garantia de qualidade, o nível de

exigência a ser aplicado, os papéis e responsabilidades, documentos a serem gerados e
ferramentas a serem utilizadas.
vii) Tool Qualification Plan (Plano de Qualificação de Ferramentas de Software)
Em projetos envolvendo alta criticidade (e.g., sistemas aeronáuticos com alto riscos à
segurança de pessoas), o nível de qualidade técnica do software deve garantido. Para isso, a
equipe de desenvolvimento deverá utilizar técnicas e ferramentas adequadas de
desenvolvimento. Como, em geral, as ferramentas são produzidas por outras empresas, há
uma dúvida legítima sobre a qualidade das ferramentas. Por exemplo, uma equipe pode se
esforçar para aplicar as melhores práticas de programação visando garantir uma alta
qualidade, mas, ainda assim, os programas podem ter falhas graves originadas por bugs no
compilador utilizado. Assim, quando o nível de qualidade de software é alto, torna-se
necessária “qualificar” as ferramentas usadas por meio da comprovação da qualidade sua
técnica. Isso pode ser feito solicitando aos fornecedores atestados de qualidade ou realizando-
se teste de garantia de qualidade sobre as ferramentas usadas. Ferramentas, cuja qualidade
não possa ser comprovada, não podem ser usadas em determinados desenvolvimentos. O
plano de qualificação de ferramentas define como cada ferramenta usada será qualificada,
obviamente, se o desenvolvimento em questão o exigir.
• PM (Project Management) – Gerenciamento de Projeto
A atividade de gerenciamento ou gestão de projeto (Project Management) envolve as ações

de administração ligadas à condução do desenvolvimento. Embora o nome clássico se refira
à “projeto”, este gerenciamento alcança todas as ações de desenvolvimento (i.e.,
especificação, projeto, construção e verificação) e é necessário para assegurar uma boa
condução das ações, um bom uso dos recursos, uma boa eficiência e um bom controle do que

será feito. Basicamente, trata-se de uma atividade de administração composta por um
conjunto de técnicas para planejar e controlar os processos que são realizados.
Algumas das principais ações envolvidas no gerenciamento de projetos são a elaboração e

acompanhamento do cronograma físico e financeiro do desenvolvimento, a seleção e
capacitação de recursos humanos, as aquisições e alocações de materiais (i.e., ferramentas de
trabalho), o controle de milestones (i.e., atingimento dos marcos do desenvolvimento), a
análise e mitigação de riscos (i.e., risk management), o gerenciamento de mudanças (i.e.,
change management), mitigação de incidentes e elaboração de indicadores e relatórios.
Embora esteja no escopo de um projeto de engenharia, o gerenciamento de projeto não é uma

atividade de engenharia propriamente dito, pois não participa da elaboração da solução
técnica em si, servindo como uma atividade de suporte à engenharia. Neste sentido, há uma
confusão considerável em torno do papel do Gerente de Projeto (PM – Project Manager),
pois não há um pleno consenso, nem clareza, sobre seu papel, levando as empresas a
adotarem interpretações distintas. Frequentemente, o papel do Gerente de Projeto se
confunde com outros papéis como os de Product Owner, Product Manager e Project Leader.
Não é incomum, inclusive, que se considere (erroneamente na visão do autor deste caderno)
que o Project Manager seja o líder de projeto, ou seja, aquele que toma as decisões sobre a
condução completa do desenvolvimento e sobre o que se busca com o produto final,
comandando todas as ações. Também, não é raro que se entenda que o Project Manager
deveria ser um engenheiro que, além de ter formação, conhecimento e experiência em
desenvolver produtos análogo ao do desenvolvimento em questão, tenha também plena
formação em administração de empreendimentos de engenharia.
Na visão do autor deste caderno, o Project Manager deveria ser um administrador (inclusive
com formação em administração) para bem conduzir as tarefas de gestão segundo as práticas
mais atuais. Ele não deveria ser o líder do desenvolvimento, pois não é um engenheiro. A
liderança do desenvolvimento deveria ser exercida por um engenheiro experiente,
assessorado por um Project Manager. Desta forma, cada profissional agiria dentro de suas
competências, podendo alcançar máxima eficiência. Não é incomum encontrar um “grande
engenheiro” alocado como Project Manager de um desenvolvimento, fazendo atividades de
administração de maneira insatisfatória (até porque não é sua competência primária, nem seu
gosto) e infeliz (e mal utilizado) por não ter disponibilidade de tempo para atuar na concepção
do produto técnico. É claro que existem, também, engenheiros que desenvolvem um gosto
maior, e até uma capacitação, em gestão e poderiam assumir, assim, o papel de Project
Manager. Mas note que nesse caso, podemos ter uma ótima gestão, mas o papel de liderança
técnica de projeto fica comprometido. O grande problema parece ser misturar dois papéis
distintos (liderança técnica e administração) em uma mesma função. É claro que isso é
compreensível e aceitável para projetos menores com uma equipe reduzida.

O gerenciamento de projetos é um tema bem desenvolvido atualmente e existe uma boa
organização da formação de PM. A maior referência neste tema é o PMI – Project
Management Institute que produz materiais de referência, como o PMBOK – Project
Management Body Of Knowledge. O PMBOK é um guia sobre como utilizar a norma “The
Standard for Project Management” da American National Standards Institute (ANSI). O PMI
também desenvolve materiais de treinamento, organiza as certificações, promove eventos e
divulga cursos na área. No Brasil existem instituições que oferecem a formação e certificação
PMI na forma que cursos de especialização (i.e., pós-graduação lato sensu).
• Desenvolvimentos de engenharia e integração
A partir da especificação e concepção do sistema, e do planejamento de seu

desenvolvimento, são iniciados os desenvolvimentos das partes do sistema, aplicando
engenharias especializadas. Quais engenharias são aplicadas dependerá na natureza das
partes do sistema. Para o desenvolvimento de smartphone, por exemplo, pode-se imaginar a
necessidade de se desenvolver a parte elétrica (aplicando engenharia elétrica), desenvolver
os circuitos eletrônicos (aplicando engenharia eletrônica), desenvolver o design do gabinete
(aplicando “engenharia de design”) e sua estrutura (aplicando engenharia mecânica), além
de desenvolver seu software (aplicando engenharia de software). Esses desenvolvimentos
podem ser conduzidos simultaneamente (como ilustra a figura 5), uma vez que eles partem
de uma especificação e concepção do todo (i.e., do sistema) que já foi feita. Entretanto, é
comum haver interdependências entre estas partes do sistema, levando a necessidade de
interação entre os desenvolvimentos ao longo de sua realização. Este desenvolvimento de
engenharias interdependentes feito concomitantemente é denomino Engenharia Simultânea
ou Engenharia Concorrente. Ao final do desenvolvimento das partes, elas devem ser
reunidas para comporem o sistema final, o que é feito na atividade de integração do
sistema. O propósito é garantir que todas as partes juntas operem de forma consistente para
cumprir os objetivos estabelecidos para o sistema.
• Verificação
A atividade de verificação tem por objetivo avaliar a qualidade técnica da solução que está
sendo concebida e construída ao longo de seu desenvolvimento. Nesta atividade, aplicam-se
técnicas de inspeção, de revisão e de testes para medir esta qualidade. Isso pode ser feito para
cada parte do sistema, separadamente, ou para o conjunto das partes do sistema, conforme o
avanço dos desenvolvimentos permita checar a qualidade das integrações das partes.
• QA (Quality Assurance) – Garantia de Qualidade
A garantia de qualidade é uma atividade de suporte ao desenvolvimento de sistema, cujo

papel é monitorar se as ações planejadas e formas de ação previstas estão sendo adotadas.
Frequentemente, a QA faz parte dos programas de qualidade das empresas de engenharia,
como ISO 9000, CMMI e MPS-BR.

A garantia de qualidade se baseia nos planos de desenvolvimento e nos padrões estabelecidos
para o desenvolvimento. Ela tem objetivo assegurar que os planos de desenvolvimento,
incluindo os processos a serem seguidos, e os padrões estão sendo obedecidos. Trata-se de
um monitoramento contínuo ou auditoria do andamento das atividades.
Não se deve confundir QA com o “controle de qualidade” (Quality Control - QC). O controle
de qualidade está relaciondo com processos ou procedimentos para assegurar a qualidade
técnica do sistema em desenvolvimento (i.e., se os parâmetros da solução desenvolvidade
estão de acordo com os requisitos técnicos especificados) e faz parte da atividade de
Verificação. Portanto, QC está relacionado com o desenvolvimento do produto em si,
podendo ser considerada, efetivamente, uma atividade de engenharia. QA, por outro lado, é
uma atividade de monitoramento dos processos que fazem parte do desenvolvimento, sendo
uma atividade de suporte à engenharia.
• CM (Configuration Management) – Gerência de Configuração
O gerenciamento de configuração (CM - Configuration Management) é uma atividade que

acompanha todo o ciclo de vida de um sistema ou software, iniciando em seu
desenvolvimento. O papel primário do CM é controlar os todos artefatos desenvolvidos e as
alterações realizadas sobre eles. Assim, na presença de problemas, a CM pode determinar o
que foi alterado que possa ter gerado o problema e quando e quem fez a alteração. Uma das
funções básicas do CM é o controle de versão, que consiste na identificação dos artefatos e
seu controle de armazenamento, por meio de versão atualizadas de cada artefato (e.g.,
documentos, modelos, códigos). Para este fim, são empregadas ferramentas como
Subversion, Git e Mercurial. Além disso, o CM pode envolver outras ações como o controle
de baselines para entregas (i.e., releases do produto), controle de variações do software (i.e.,
branches), gerência de alterações (i.e., Change Management) e gerenciamento de tarefas.
Um exemplo de ferramenta que integra estas funções é o IBM Rational Synergy.

PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Um dos importantes instrumentos da Engenharia de Software é a aplicação de processos que

organizam as atividades de desenvolvimento de software. Neste capítulo é feita uma
apresentação dos conceitos de processos de software e uma discussão sobre os principais
processos empregados nas empresas.
VISÃO GERAL DE PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Os processos de desenvolvimento de software começaram a ser empregados de forma mais

sistemática ao final dos anos 60 com o surgimento da Engenharia de Software que propunha
uma maior organização e disciplina no desenvolvimento de software, visando enfrentar os
problemas da crise de software. Inicialmente, aplicou-se uma organização do
desenvolvimento de forma similar ao que se praticava em outras engenharias, porém usando
modelos, linguagens, técnicas e ferramentas particulares para a produção de software.
Ao longo das décadas, os processos foram sendo repensados em busca de uma maior
eficiência e conformidade com as características do desenvolvimento de software. Novas
propostas de processos ou de aperfeiçoamentos de processos existentes foram apresentadas
e aplicadas na indústria, inclusive baseadas na evolução dos paradigmas de software. Até os
dias atuais, continua-se a repensar as formas de desenvolvimento utilizadas e a buscar
melhores alternativas visando melhorar a eficiência (i.e., fazer mais com menos recursos) e
melhorar a possibilidade de sucesso do produto (i.e., satisfazer as demandas dos clientes).
Atualmente, existem diversas alternativas de processos de desenvolvimento de software,

incluindo desde os processos clássicos do passado até processos mais recentes que trazem
uma “visão ágil” aos métodos utilizados. Todos os processos, inclusive os mais antigos,
podem e ainda são utilizados nas empresas. É claro que há uma preferência por processos
mais recentes, pois se imagina que eles representariam uma alternativa mais “moderna” e,
portanto, melhor para organizar as atividades de desenvolvimento. Nas seções a seguir alguns
dos principais processos serão discutidos e uma discussão comparativa permitirá refletir
sobre suas características.
Embora existam diversas alternativas de processos de desenvolvimento, todos eles envolvem

as mesmas quatro atividades fundamentais. Ou seja, o que será feito ao longo do
desenvolvimento (i.e., as atividades técnicas de desenvolvimento) será sempre o mesmo,
independentemente de processo. Assim, se uma empresa um dia decidir mudar seu processo
de desenvolvimento, o que mudará é a organização e a forma de conduzir as atividades e não

as atividades em si. Outras atividades de suporte (e.g., Quality Assurance, Configuration
Management) e gestão (e.g., Project Management) podem ter mudanças mais significativas.
As quatro atividades fundamentais de qualquer processo de desenvolvimento são: (i)

Especificação de Requisitos de Software, (ii) Projeto de Software, (iii) Construção de
Software e (iv) Verificação de Software, conforme descrito a seguir.
(i) Especificação de Requisitos de Software

Nesta primeira atividade determina-se “o que” o desenvolvimento deverá alcançar em
termos das funções e características do futuro software, ou seja, quais são os requisitos
para o software. Estes requisitos são obtidos dos clientes ou do mercado, e são
entendidos e descritos tecnicamente pelo engenheiro ou analista em um documento de
especificação que, depois de aprovado, servirá de orientação para as demais atividades
do processo de desenvolvimento.
(ii) Projeto de Software

Esta segunda atividade é dedicada à concepção e descrição da solução técnica para o
software, de forma a atender a todo o conjunto de requisitos especificado anteriormente.
A solução é descrita na forma de especificações e modelos da arquitetura do software,
descrevendo seus componentes e funções, interrelações entre eles, estruturas de
composição, modelos de dados, interfaces com os usuários, interfaces de comunicação
e protocolos e seu comportamento. Muito frequentemente, empregam-se linguagens de
modelagem, como a UML (Unified Modeling Language), nesta atividade. É importante
lembrar que a atividade de projeto não envolve meramente um trabalho de
especificação ou desenho de modelos, mas, muito mais do que isso, é uma atividade
inventiva em que uma solução deve ser imagina pelo engenheiro ou analista de forma
que seja bem estruturada, clara de implementar e eficiente, cumprindo com os requisitos
definidos.
(iii) Construção de Software

Nesta atividade, a implementação do software é efetivamente produzida. Esta
implementação poder ser feita na forma de programas codificados em alguma
linguagem ou na forma de modelos executáveis ou a serem traduzidos (i.e., compilados)
para compor o código executável do software. A atividade de construção deve ser
inteiramente baseada nas especificações do projeto definidas anteriormente.
(iv) Verificação de Software
Na atividade de verificação é feita a checagem da qualidade técnica do software

construído e a checagem do atendimento dos requisitos. Para este fim, são utilizadas
técnicas de teste, técnicas de inspeção e revisão de código, além dos testes de sistema

e de aceitação junto aos clientes. A profundidade da verificação depende das exigências
de qualidade para o software.
PRINCIPAIS PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Existem várias alternativas de processos de desenvolvimento apresentadas na literatura

técnica da área. Além disso, algumas empresas preferem customizar algum dos processos
existentes de forma a adequá-los ao estilo ou experiência da equipe ou, ainda, integrá-lo às
políticas, processos e programas de qualidade da organização.
A tabela a seguir ilustra alguns dos principais processos existentes com uma classificação
proposta pelo autor deste caderno.
Tabela 1 – Alternativas de Processos de Desenvolvimento de Software
Nome do Processo Aparecimento Tipo Classificação

Processo Clássico ou em Cascata Anos 70 Sequencial
Processo por Prototipação Anos 70 Sequencial
Antigos
Processo em V Anos 80 Sequencial
Processo Interativo ou em Espiral Anos 80 Iterativo
Processo Unificado Anos 90 Iterativo
Métodos Ágeis Anos 90 Iterativo Contemporâneos
Processo Dirigido a Modelos Anos 2000 Iterativo
Observa-se, pela Tabela 1, que os processos de desenvolvimento eram sequenciais até

meados dos anos 70 e que evoluíram para iterativos a partir de então. Processos sequenciais
são aqueles em que as atividades são realizadas uma a uma e em uma dada ordem, ou seja,
uma atividade seguinte só inicia quando a precedente estiver concluída. As atividades
fundamentais e a ordem de realização são aquelas citadas na seção anterior e ilustradas na
figura 6.a. Por outro lado, nos processos iterativos, o desenvolvimento é feito por ciclos (ou
iterações) de melhoria ou detalhamento de forma que a especificação, o projeto, a construção
e a verificação sejam realizadas por meio de múltiplos ciclos e simultaneamente, gerando
incrementos a cada ciclo (figura 6.b). Entretanto, a simultaneidade das atividades não é
exatamente simétrica como está ilustrado na figura e será rediscutida na seção sobre os
processos iterativos.

Figura 6: Processos (a) sequenciais e (b) iterativos.
PROCESSO CLÁSSICO – WATERFALL – CASCATA
Na origem da Engenharia de Software, a organização do processo de desenvolvimento

baseou-se nas práticas das outras áreas de engenharia. Assim, pode-se denominar essa
organização original como “Processo Clássico”, pois é análogo ao que, classicamente, se faz
em outras engenharias.
Consideremos, por exemplo, o desenvolvimento de uma cadeira. Inicialmente, faz-se

necessário determinar as intenções do cliente para esta cadeira (e.g., os seus requisitos),
incluindo seu uso, como para um escritório, restaurante ou em uma residência; as funções e
características desejadas, como ajuste de altura, movimentação com rodinhas, suporte para
os braços, capacidade de carga, materiais, design e preço alvo. A partir destes requisitos,
pode-se desenvolver o projeto da cadeira que consistirá em definir sua estrutura, materiais,
conexões de componentes e dinâmica de partes móveis e de uso. Na sequência, é possível
fabricar a cadeira (e.g., construção) e verificar seu funcionamento e características frente às
intenções originais do cliente ou mercado.
Percebe-se que a sequência de atividades ilustrada no exemplo do desenvolvimento de uma

cadeira, assim como na figura 6.a, parece ser bastante lógica. Isso se deve ao fato de que
existe uma dependência causal entre elas, estabelecendo que uma depende da anterior (i.e., é
um efeito ou consequência) e é também a causa para a seguinte (i.e., determina como a

atividade seguinte deverá ocorrer). Note que, pensar em uma ordem diferente, como iniciar
pela Verificação, não faz muito sentido, pois não haveria o que verificar até que a Construção
fosse realizada. Similarmente, começar pelo Projeto da Solução não faz sentido, pois não há
como se projetar algo cujo propósito não é conhecido. Assim, a Especificação de Requisitos
deveria preceder o Projeto e a Construção preceder a Verificação, em função de suas relações
causais.
Uma representação gráfica alternativa àquela da Figura 6.a, seria desenhar as atividades
diagonalmente, conforme ilustrado na Figura 7. Isso não muda em nada as atividades nem
sua ordem de realização, mas permite criar uma nova analogia. Nesta visão, com cada
atividade a direita estando desenhada um pouco mais abaixo, tem-se a impressão de uma
escada ou de uma cascata em degraus (inclusive desenhou-se na Figura 7 uma representação
da água acima das atividades para melhor caracterizar esta visão de uma cascata. A analogia
(que também dá o nome de “cascata” ou “waterfall” ao processo) é a de que o processo flui
em uma única direção, tal como em uma cascata a água escorre naturalmente de um degrau
ao próximo, sempre na mesma sequência, provocado pela força da gravidade. Ou seja, deseja-
se caracterizar o fato de o processo ser sequencial, não tendo como se avançar do primeiro
ao terceiro degrau sem passar necessariamente pelo segundo, e assim por diante.
Figura 7: Processo Waterfall ou Cascata.
Entretanto, nem sempre as atividades são completamente bem-sucedidas, de forma que, ao

analisar a solução produzida na atividade de Verificação, pode-se constatar que há falhas na
construção do software, no seu projeto ou na sua especificação de requisitos. Neste caso, é
necessário retornar a uma atividade passada (pois já foi concluída) para fazer os ajustes e
correções devidos. Na figura 7, esses retornos para alterações são ilustrados pela linha na
parte de baixo das atividades. Usando ainda a analogia com uma cascata, seria possível a
água voltar degraus acima? A resposta é sim, porém exigindo grande esforço. Você poderia,
por exemplo, pegar um balde, enchê-lo com a água que chegou ao degrau mais baixo, subir
a cascata e derramá-la no primeiro degrau para que ela percorresse novamente todos os

degraus. O retorno a atividades anteriores para ajustes e correções em um processo sequencial
é muito custoso, basicamente, porque as atividades anteriores já foram concluídas, pode já
ter se passado muito tempo de sua conclusão e a equipe que participou destas atividades
provavelmente já está trabalhando em outros projetos. Assim, para refazer ou realizar ajustes,
será necessário recompor a equipe para atuar nesta atividade passada (considera-se aqui que
os profissionais de requisitos, projeto, construção e verificação podem não ser os mesmos).
Mesmo que sejam as mesmas pessoas que tenham realizado todas as atividades, há
necessidade de se retomar um conhecimento passado exigindo um esforço substancial. Além
disso, se houver algum ajuste a se fazer na Especificação de Requisitos, isso afetará o projeto
da solução, que deverá ser refeito, pelo menos para a parte afetada pela alteração de
requisitos, e, também, a Construção, que deverá ser refeita. Por fim, a Verificação deverá ser
realizada novamente para checar as mudanças e seus eventuais efeitos na qualidade do
software como um todo.
Assim, em processos sequenciais, o retorno a atividade anteriores é a situação que gera maior
dificuldade. Em especial, falha de especificação de requisitos, quando observadas apenas ao
final do processo na Verificação, exigiriam um retorno para correções no início com os
maiores custos. Este, de fato, é o maior problema da abordagem sequencial. Em razão do
alongamento do desenvolvimento criando um distanciamento entre as atividades (porque
cada atividade só inicia após a conclusão da anterior), há um grande risco ao desenvolvimento
uma vez que os requisitos especificados mais ao início só serão confirmados (verificados)
mais ao final do processo na Verificação, quando todo o esforço e custo de desenvolvimento
já foi aplicado. Se os objetivos do desenvolvimento do software forem bem claros, bem
conhecidos e não vierem a sofrer mudanças (e.g., são estáveis), então o risco ao
desenvolvimento é baixo e este processo Waterfall é aplicável. Na situação extrema ao
contrário, em que os requisitos não são bem conhecidos e há incertezas sobre eles, o processo
Waterfall pode ser uma abordagem inadequada. Foi exatamente, esta dificuldade que levou
ao processo interativos que serão discutidos adiante.
Outro aspecto a ser considerado sobre o processo Waterfall é que ele, principalmente em
desenvolvimentos maiores, levou a organizações funcionais do desenvolvimento. Como
havia quatro atividades distintas a executar, envolvendo habilidades profissionais também
distintas, muitas empresas organizavam o desenvolvimento fazendo passar o projeto por
quatro equipes, cada qual fazendo seu papel de especificação, projeto, construção e
verificação com profissionais especializados em cada tarefa. Com isso, criou-se uma
departamentalização do desenvolvimento de software. Uma equipe (ou setor ou
departamento) iniciava o desenvolvimento, fazendo a especificação de requisitos do
software. Ao término, esta equipe produzia um documento técnico com os resultados e
encaminhava para a próxima equipe que, usando os resultados anteriores, produzia o projeto
da solução e sua documentação. Os resultados eram, então, encaminhados à equipe de
Construção e, posteriormente, à equipe de Verificação. Cada profissional atuava em uma

equipe e tinha uma especialidade, criando equipes de trabalho especializadas e homogêneas,
pois todos tinham atuação na mesma especialidade. Ambientes homogêneos de trabalho
como estes são apreciados por muitas pessoas, pois promovem um espírito de colaboração
grande entre os profissionais que possuem formação, renda, interesses e competências
similares. Por outro lado, pode-se considerar que tais ambientes são menos desafiadores e
podem se tornar monótonos para alguns profissionais.
Pode-se, ainda, afirmar que o processo Waterfall é um processo simples de entender, simples
de aplicar e fácil de gerir. Esta simplicidade é resultado da natureza sequencial do processo,
pois, em geral, coisas sequenciais são mais simples de se entender e controlar. A gestão de
um processo Waterfall tende a não ser complexa (relativo à sua dimensão), pois há uma
previsibilidade do que está sendo feito a cada momento (i.e., sempre uma única atividade), o
cronograma é compreensível e sabe-se, claramente, o que há a fazer. O eventual complicador
da gestão deste processo seria a necessidade de retorno a atividades anteriores, mas que não
deveria ocorrer em excesso, pois este processo só deveria ser aplicado a casos em que os
requisitos são mais claros e estáveis.
Com relação a sua eficiência, o processo Waterfall pode ser considerado o mais eficiente dos
processos, notadamente para o caso de desenvolvimentos com requisitos claros e estáveis.
Essa alta eficiência se justifica pelo fato do processo Waterfall ter a natureza de uma linha
de produção sem série, como em uma fábrica de produtos manufaturados (e.g., produção de
automóveis). Este tipo de estrutura de produção tende a gerar o máximo de saídas (produtos
acabados) por recursos utilizados, o que representa sua eficiência. Obviamente, se houver
retrabalhos, em razão principalmente de falhas nos requisitos, esta eficiência será
comprometida.
Em resumo, descreve-se a seguir as principais características, vantagens e desvantagens do

processo Waterfall.
• Principais características do Processo Waterfall

o é um processo sequencial de desenvolvimento de software
o se aplica a desenvolvimentos em que os requisitos são conhecidos e estáveis
o tende à departamentalização ou especialização do trabalho
o representa uma abordagem clássica de engenharia
• Vantagens do Processo Waterfall
o é simples de se entender e aplicar
o é fácil de ser gerido
o é muito eficiente
o é sistemático com atividades e resultados bem definidos
• Desvantagens do Processo Waterfall
o tende a alongar o prazo de desenvolvimento
o possui alto custo para retorno a atividades anteriores (para mudanças e correções)

o pode gerar alto risco de ter que se refazer parte do desenvolvimento quando os
requisitos são mal conhecidos ou instáveis
Cabe observar que muitos autores ou profissionais da atualidade tendem a considerar o

modelo Waterfall como um contraexemplo do que seria uma visão “moderna” dos processos
de desenvolvimento de software, em que a “agilidade”, “adaptabilidade” ou “iteratividade”
costumam ser o destaque. Na verdade, há que se ter mais cuidado com tais análises. Como
foi dito nessa seção, se um desenvolvimento de software se baseia em intenções (i.e.,
requisitos) claramente definidas e estáveis, não há razão para se buscar adaptabilidade,
iteratividade ou agilidade nos processos de desenvolvimento e os métodos sequenciais, como
o Waterfall, tornam-se os mais eficientes. A “disposição em ser adaptável”, ou seja, “estar
aberto a mudanças”, e a “capacidade de adaptação”, ou seja, “conhecer e dispor de
ferramentas para se adequar a mudanças”, não são objetivos em si e sim meios para enfrentar
situações que exijam esta adaptabilidade. Devemos lembrar que a adaptabilidade aumenta,
necessariamente, os custos e prazos de desenvolvimento e pode comprometer a qualidade
das soluções. Como será discutido a seguir, a adaptabilidade surgiu como um meio para
enfrentar as situações de desconhecimento ou instabilidade dos requisitos ou das próprias
tecnologias e arquiteturas das soluções em desenvolvimento de sistemas e softwares, e, nestes
casos, ela é de fato útil.
PROCESSO POR PROTOTIPAÇÃO
A prototipação de software é uma técnica que poder ser empregada em conjunto com
qualquer processo de desenvolvimento, como um meio para melhorar a qualidade das
especificações (i.e., deixar os requisitos mais próximos da real demanda dos clientes). Além
disso, a prototipação pode ser útil para validar princípios de funcionamento da solução
pretendida, validar a performance alcançável em uma dada plataforma, analisar a viabilidade
de certas tecnologias e avaliar outras características técnicas sobre as quais a equipe possa
não ter domínio pleno ou há incertezas. Fundamentalmente, é produzido um protótipo do
software antes de se partir para o desenvolvimento mais intenso do produto. Este protótipo é
uma construção simplificada e incompleta do futuro software, baseada nos requisitos
definidos até o momento (i.e., podem ainda estar incompletos) e em um esboço da solução
estrutural e comportamental.
A prototipação é uma técnica útil, principalmente, para o desenvolvimento de softwares em

que os requisitos não estão claramente definidos, havendo, portanto, uma incerteza sobre o
que o cliente deseja como funções e características do software ao final. Para reduzir esta
incerteza, pode-se utilizar a prototipação de maneira a se desenvolver uma versão preliminar
do software (ou seja, um protótipo) que possa ser apresentada ao cliente e que permita validar,

ajustar e descobrir novos requisitos. Assim, o cliente pode ter uma melhor noção do futuro
software e pode fornecer um feeback antecipado sobre se suas necessidades estão sendo
atendidas. Reduz-se, por consequência, o risco de não satisfação do cliente ao final do
desenvolvimento.
A figura a seguir posiciona a atividade de prototipação sobre um processo waterfall. Ela se

situa entre o término da atividade de especificação de requisitos e o início do projeto da
solução. A prototipação se baseia nos requisitos definidos até então e permite incorporar
ajustes e novos requisitos identificados com a ajuda do protótipo. Além disso, a prototipação
também cobre parte do projeto da solução, pois o protótipo representa uma primeira
aproximação ou visão da concepção da solução. Quando se alcançar uma maior certeza sobre
os requisitos, por meio da avaliação do protótipo pela equipe de desenvolvimento e pelo
cliente, pode-se encerrar a prototipação e dar continuidade ao projeto do software,
avançando-se sobre o processo de desenvolvimento.
Figura 8: Posicionamento da Prototipação sobre um Processo Waterfall.
Esta técnica de prototipação também é empregada em outras áreas de engenharia. Em

construção civil, por exemplo, é comum a criação de protótipos na forma de maquetes em
escala, modelos de simulação, plantas artísticas do imóvel ou de outras construções e,
mesmo, maquetes eletrônicas e de realidade virtual (e.g., software para visualizar um
apartamento digital em três dimensões). Em engenharia mecânica é possível a criação de
modelos em CAD, simulações e a impressão em 3D de peças em plástico, como forma de
avaliar antecipadamente o produto final.
A prototipagem é uma técnica de grande valor em engenharia e deveria ser sempre

considerada quando houver incertezas sobre os requisitos ou sobre algum aspecto técnico
crucial sobre o qual há incertezas. Entretanto, ela tem um custo, pois implica um gasto de

tempo e investimento para a construção dos protótipos. Mesmo empregando ferramentas
modernas de prototipação, o custo de prototipação pode ser alto. Assim, existem duas regras
básicas a serem obedecidas na construção de um protótipo:
(i) Não investir demais em detalhes e cuidados para que o tempo de construção
seja curto e o custo seja baixo. Ou seja, a construção de um protótipo deve ser
feita sem os cuidados de desenvolvimento de um software. Não é necessário fazer
o projeto da arquitetura do protótipo, não é necessário usar técnicas de
programação detalhadas, nem documentar o protótipo, não é necessário que o
protótipo seja completo (ou seja, pode haver “ifs” sem “elses”, por exemplo, e
pode haver funções não implementadas) e, ainda, não se faz testes do protótipo
para assegurar sua qualidade.
(ii) Descartar integralmente o protótipo após seu uso. Dado que os protótipos são
construídos sem cuidados, o código produzido deve ser de baixa qualidade no
sentido geral e, assim, deve ser integralmente descartado após seu uso na
validação dos requisitos. Se houver intenção de aproveitar o código ao final, então
a regra (i), possivelmente, não será respeitada, pois haverá tendência de se
construir o protótipo com mais qualidade, alongando o tempo de desenvolvimento
e aumentando rapidamente o seu custo.
Existem algumas variantes da prototipação propostas na literatura e, eventualmente,

aplicadas em algumas empresas, conforme listado a seguir.
• Prototipação Rápida (Rapid Prototyping)

Este é o tipo clássico de prototipação em que um protótipo simples é desenvolvido a
baixo custo e cm rapidez para uma avaliação geral dos requisitos e com a intenção de
ser descartado ao final da avaliação.
• Prototipação Evolucionária (Evolutionary Prototyping)
Neste tipo de prototipação uma versão inicial do protótipo é produzida e, a seguir,
baseado no feedback dos clientes, novas versões são produzidas até se alcançar um
protótipo final aceitável pelo cliente.
• Prototipação Incremental (Incremental Prototyping)
Neste caso de prototipação, o protótipo final desejado é decomposto em um conjunto
de protótipos menores que são desenvolvidos individualmente e são integrados
gradualmente (representando incrementos ao protótipo). Os feedbacks do cliente são
feitos a cada incremento do protótipo.
• Prototipação Extrema (Extreme Prototyping)
Este tipo de prototipação é mais usado para desenvolvimento de aplicações web em
que, inicialmente, são produzidas as páginas HTML, depois as interfaces de dados e,
por fim, a integração dos serviços no protótipo.

PROCESSO EM V
O Processo ou Modelo em V (“V Model” ou ainda “The Validation and Verification Model”)
foi inicialmente proposto em 1986 por Paul Rook [11] e depois aperfeiçoado e detalhado por
vários autores, na forma de uma extensão do processo Waterfall. Assim, trata-se também de
um processo sequencial com características análogas ao que foi discutido na seção anterior,
mas com algumas particularidades. O Modelo em V teve grande repercussão mundial e
tornou-se, por exemplo, o padrão de desenvolvimento de software em 1992 das autoridades
federais da Alemanha para todos os projetos nas áreas de defesa e comercial. Ainda hoje, em
muitas áreas de engenharia, o Modelo em V também é uma referência, como no setor de
transporte, industrial, aeronáutico e de defesa.
O Processo em V foi proposto tendo uma preocupação especial com a melhoria da qualidade
dos softwares. Por esta razão, ele estende as atividades existentes no processo Waterfall para
colocar em destaque as atividades de verificação (i.e., testes). Na prática, mantém-se as
mesmas quatro atividades fundamentais de todos os processos, mas com um detalhamento
em testes. A figura a seguir ilustra o Processo em V na forma de uma extensão do Processo
Waterfall, em que a atividade de Verificação é substituída por três atividades de teste. O autor
deste caderno também chama este processo de “cascatão”, quando o desenha neste formato
de um processo em cascata alongado.
Figura 9: Ilustração do Processo em V como uma extensão do Processo Waterfall.
Classicamente, o Processo em V inclui três tipos ou níveis de atividades de teste visando

verificar a qualidade do software desenvolvido, conforme descrito a seguir.
• Testes Unitários

Logo após a conclusão da Construção, em que o código do software é produzido, realiza-se
a atividade de Testes Unitários (também chamados Testes de Componentes). Nesta atividade,
testes são realizados sobre as unidades do software, ou seja, sobre módulos, componentes ou
funções que compõem o código produzido, com o objetivo de checar se estas unidades,
isoladamente, executam adequadamente o que é esperado. A intenção é checar a ausência de
defeitos (e.g., bugs) e, com isso, obter confiança em cada unidade testada. Note que não se
está testando o software como todo e sim apenas as suas unidades separadamente. Estes testes
podem ser realizados usando diferentes métodos com maior ou menor grau de profundidade.
Um método clássico de teste unitário denomina-se “Teste em Caixa Preta” (Black Box
Testing em inglês). Este método baseia-se apenas na relação entre os dados entrada de uma
unidade e dos dados resultantes da sua execução. O fluxo de processamento dentro da
unidade de código não é considerado e é, por essa razão, que esta técnica se chama “caixa
preta”, pois não se vê o interior da unidade. Para testar cada unidade é necessário a elaboração
de um plano de testes no qual estarão definidos os casos de teste, ou seja, um conjunto de
valores de entrada e respectivos dados de saída esperados. Se a unidade sendo testada
produzir os resultados esperados para todos os casos de teste (ou seja, se a unidade passar
nos casos de teste), ela será então considerada aprovada no teste unitário. A principal
dificuldade na elaboração dos casos de teste é a possibilidade de haver um número muito
grande de casos, tornando a atividade muito longa ou inviável. Considere, por exemplo, a
seguinte unidade (i.e., função) a ser testada: int Somar(int a, int b). Para garantir que
esta função faça a soma adequada de dois inteiros quaisquer “a” e “b” e produza um inteiro
resultante da soma, seria necessário criar tantos casos de teste quando fosse a combinação de
todos os inteiros positivos e negativos de “a” e “b”, o que, seguramente, será uma longa lista.
Frequentemente, empregam-se técnicas para reduzir este número de casos, como o
“Particionamento em Classes de Equivalência” e “Análise de Valor Limite”. No
Particionamento em Classes de Equivalência busca-se determinar grupos de valores dentro
do domínio dos dados que sejam equivalentes para fins de teste, de forma a evitar a
necessidade de testá-los todos. O teste com um único valor dentro de uma classe seria
suficiente para verificação de todos os valores da classe. A Análise de Valor Limite considera
que erros costumam ocorrer nos limites dos valores dos dados que separam as classes de
equivalência e, assim, valores nestes limites são escolhidos para os casos de teste.
Outro método de teste unitário denomina-se “Teste em Caixa Branca” (White Box Testing
em inglês) em que o fluxo de execução (i.e., algoritmo) da unidade sendo testada é levado
em conta. Assim, deve-se considerar o código no interior da unidade, o que deu o nome
“Caixa Branca” ao método. Aqui vale observar que este nome parece equivocado, pois não
é possível enxergar o que há dentro de uma caixa branca. Talvez um nome melhor teria sido
“Caixa Transparente”. Testes em caixa branca buscam checar a qualidade de uma unidade
do software analisando aspectos relacionados com a cobertura dos testes (code coverage).
Deseja-se saber o quanto do código foi efetivamente testado, mesmo que ele tenha

respondido bem aos testes em caixa preta e, aparentemente, esteja produzindo os resultados
esperados. Pode-se, por exemplo, checar se todas as instruções foram percorridas durante os
testes (evitando que alguma instrução nunca tenha sido executada e testada) e se todos os
caminhos dos laços e ifs foram percorridos (evitando que algum caminho lógico nunca tenha
sido executado). Pode-se, também, detectar “códigos mortos” (dead code) que são partes do
código que, em razão das condições (ifs) nunca serão executados. Mesmo que possam parecer
inofensivos, os códigos mortos representam erros (por que teriam sido escritos se não são
necessários?) e devem ser eliminados, até porque não é impossível que um tal código “volte
à vida” algum dia e pela primeira vez, e sem jamais ter sido testado, entre em execução.
Os testes unitários são planejados e executados com maior ou menor profundidade

dependendo do grau de qualidade desejado para o software. Como o custo de realização de
teste é alto, a regra é aplicar o mínimo de teste necessário (e não o máximo como alguém
poderia imaginar). Entretanto, este “mínimo” deve representar a realidade da necessidade de
qualidade e deve ser de ciência do cliente ou mercado.
• Testes de Integração
Uma vez que todas as unidades do código do software tenham sido testadas e passaram nos
testes unitários, pode-se avançar para a atividade de Testes de Integração. Neste nível de
teste, busca-se checar se as unidades de código operando em conjunto realizam
adequadamente as funcionalidades de mais alto nível previstas. Alguns autores, diferenciam
também os testes de integração e testes funcionais, em que os primeiros envolvem funções
de mais alto nível e os segundos envolvem funções mais intermediárias ou de mais baixo
nível, ambos envolvendo a operação conjunta de unidades já testadas. Mais frequentemente,
utilizam-se métodos em Caixa Preta nos testes de integração.
Alguns autores empregam, também, o termo Testes de Sistema (System Testing) para
denominarem os testes em que todo o sistema é considerado, inclusive o hardware,
dispositivos externos, usuários e outros softwares externos que compõem o sistema. Na
prática, há grande similaridade com o que é feito nos Testes de Integração, não sendo
necessário diferenciá-los para a maioria das situações.
• Testes de Aceitação
Após a verificação da qualidade técnica do software, feita por meio dos testes unitários e de
integração, pode-se proceder aos testes de aceitação. O objetivo é verificar se os requisitos
especificados para o software foram atendidos pela solução produzida. Em geral, estes testes
são planejados baseando-se nos requisitos de alto nível, verificando-se, um a um, se o
software entrega (i.e., realiza) a funcionalidade e características que atendem cada requisitos.
Não é necessário percorrer todas as possibilidades de execução das funcionalidades, pois isso
já foi verificado anteriormente. Estes testes muitas vezes são feitos com a presença do cliente
que atesta que o software cumpre com o que foi especificado, servindo de base para o

encerramento do desenvolvimento, conclusão de um contrato e entrega do software ao cliente
ou mercado. Testes de aceitação podem, também, incluir Testes Alfa e Beta. Nesse caso, o
software é disponibilizado em ambiente interno da empresa para simulação de uso (Alpha
Test) e, a seguir, é disponibilizado a alguns clientes para uso em ambientes do cliente (Beta
Test). Estes testes são feitos ainda antes da liberação do produto (i.e., antes dos releases).
Como discutido, o Modelo em V trouxe um maior detalhamento das atividades de teste ao

processo clássico e sequencial de desenvolvimento de software, destacando três níveis de
testes. Todos os testes precisam, também, ser planejados antes de sua execução. O Modelo
em V também destaca as responsabilidades pelos planejamentos dos testes, conforme
ilustrado pelas linhas pontilhadas superiores na figura 9. É exatamente para destacar esta
relação entre o planejamento e a execução dos três tipos de testes que o desenho típico do
processo em V toma um formato em V, como ilustrado na figura 10. Neste formato, observa-
se melhor a relação entre as atividades que produzem os planos de teste (na diagonal
esquerda) e as que executam os planos (na diagonal direita). Dito de outra forma, na atividade
de Especificação de Requisitos os profissionais não só constroem a ERS, como também
elaboram o plano de testes de aceitação (que são baseados nos requisitos) a ser seguido ao
final do desenvolvimento na atividade de Testes de Aceitação. Da mesma forma, na atividade
de Projeto da Solução constrói-se as especificações e modelos do software e, também,
elabora-se o plano de testes de integração que será executado mais tarde na atividade de
Testes de Integração. Finalmente, na atividade de Construção são produzidos os códigos do
software e, também, são elaborados os testes de unitários que serão executados a seguir na
atividade de Testes Unitários.
Figura 10: Ilustração do Processo em V.
O desenho do Processo em V pode ser encontrado em muitas versões, adaptadas por

diferentes autores ou empresas. Em algumas versões, a atividade de projeto é dividida em
duas, chamadas “Projeto de Alto Nível” e “Projeto Detalhado”, ou ainda “Projeto
Arquitetural” e “Projeto de Componentes”. Mas estas variações não mudam a ideia geral do
processo.

Deve-se, também, prestar atenção a algumas interpretações equivocadas ou confusas na
literatura e na internet em que as linhas de retornos para alterações (desenhadas na parte de
baixo das figuras 9 e 10) são sobrepostas às linhas tracejas dos planos criando uma impressão
de que se pode voltar continuamente às atividades anteriores como se o Processo em V fosse
cíclico (o que ele não é, pois é sequencial).
Em resumo, as características, vantagens e desvantagens do processo em V são análogas às

do Processo Waterfall, pois também é um processo sequencial. Destaca-se, apenas, o fato de
que o Processo em V tem um foco especial no planejamento e execução de testes, ou seja,
em uma maior garantia de qualidade técnica do software. Assim, é mais indicado para
software que tenha essa exigência de qualidade.
PROCESSO POR REFINAMENTOS SUCESSIVOS - ITERATIVO
Os processos por refinamentos sucessivos ou iterativos, também denominados “iterativos e

incrementais” (do inglês, IID: Iterative and Incremental Development) e evolucionário
(Evolutionary), começaram a ser experimentados já nas décadas de 40 a 60, tendo emergido
mais amplamente entre meados dos anos 70 e início dos anos 80. O artigo de Larman e Basili
(Larman, 2003) relata em detalhes a história dos processos iterativos.
Como foi antecipado na seção PRINCIPAIS PROCESSOS DE DESENVOLVIMENTO DE

SOFTWARE deste caderno, os processos iterativos se fundamentam no desenvolvimento de
software por meio de uma sucessão de ciclos ou interações. Assim, a cada ciclo é produzida
uma nova versão da solução, também chamada um incremento, um melhoramento, um
detalhamento ou, ainda, uma evolução da solução.
Essa visão de processo surgiu do conceito de executar uma série de ciclos curtos de Planejar-
Fazer-Estudar-Agir (do inglês, PDSA: Plan-Do-Study-Act) proposto por Walter Shewhart
dos Bell Labs, nos anos 30 (Larman, 2003). Entende-se que esta visão iterativa permite ao
desenvolvedor tirar vantagem sobre o que se aprendeu durante o desenvolvimento das
versões incrementais (i.e., ciclos ou iterações) anteriores do sistema. Este aprendizado vem
das próprias conclusões sobre as decisões do desenvolvimento, mas, também, do uso do
sistema (parcial) já desenvolvido, em que a participação do cliente (i.e., do contratante e/ou
usuário) é essencial para um feedback sobre os resultados parciais já alcançados.
Os processos iterativos são, quase que unanimemente, considerados superiores ao métodos

sequenciais, pois (i) permitiriam ir adequando ou melhor orientando o desenvolvimento para
uma solução adequada à demanda do cliente (uma vez que o cliente participaria das
avaliações a cada iteração), (ii) permitiriam reduzir a complexidade em projetos de maior
porte (uma vez que o software seria desenvolvido uma parte por vez e não o todo de em

conjunto) e (iii) permitiriam um desenvolvimento mais flexível, com a capacidade de se fazer
ajustes mais facilmente durante o desenvolvimento (uma vez que ao término de cada iteração
seria possível detectar desvios no incremento produzido e já atuar em ajustes neste
incremento).
A ilustração da figura 6.b representa, de maneira simples, as sucessivas iterações ao longo de

um processo de desenvolvimento interativo. Como se vê nesta ilustração, cada iteração
envolve avanços na especificação, no projeto, na construção e na verificação para a produção
de um novo incremento. Entretanto, esta ilustração não é apropriada, pois as atividades não
podem ser realizadas da forma simétrica como ilustrado. Como dito na seção sobre o
Processo Clássico ou em Cascata, existe uma dependência causal entre as quatro atividades
fundamentais dos processos de desenvolvimento de software, fazendo com que haja uma
única ordem possível para elas, indo da atividade de especificação de requisitos até a
atividade de verificação. Para que se possa realizar essas atividades simultaneamente, é
necessário que haja “descasamento” das atividades, ou seja, é necessário que cada atividade
anterior já tenha produzido algum resultado parcial que permita avançar sobre a seguinte.
Desta forma, na(s) primeira(s) iteração(ões) de um processo iterativo só seria possível atuar
sobre a especificação dos requisitos, pois não se pode iniciar o projeto sem algum
conhecimento do que se pretende alcançar. A partir de uma especificação parcial dos
requisitos, seria possível iniciar o projeto da solução, mas não a codificação ainda, pois não
foram definidas estruturas do software que permitiram sua programação. O mesmo vale para
a verificação, em especial para os testes do software que dependem de que algum código
tenha sido construído antes. A figura 11, a seguir, mostra uma ilustração que ajusta a figura
6.b, considerando estas dependências causais. Assim, para muitas iterações haverá a
execução simultânea das quatro atividades, mas para as iterações iniciais e finais apenas
alguns atividades estarão envolvidas. Observar que as atividades (i.e., retângulos azuis) na
figura não estão em escala, podendo ser bem mais longas envolvendo mais iterações.
Na literatura mais clássica da área de engenharia de software, encontra-se, também, a

referência ao processo iterativo com a denominação “Processo em Espiral” (Spiral Process),
proposto por Barry Boehm da Universidade do Sul da Califórnia em 1986. O Processo
Espiral ilustra as iterações na forma de ciclos concêntricos incrementais que passam por
quatro quadrantes (representando as quatro atividades fundamentais do desenvolvimento de
software), formando o desenho de uma espiral, conforme ilustrado na Figura 12. À medida
em que as linhas se afastam do centro, entende-se que o desenvolvimento do software está
ganhando em conhecimento, pois está acumulando incrementos (ou seja, melhoramentos ou
ampliações). O processo avança a partir de uma primeira iteração que inicia com a
especificação parcial de requisitos. A cada iteração, é feito um incremento sobre a iteração
anterior envolvendo as quatro atividades, até a verificação e em que é avaliado o incremento
produzido, antes de partir para uma próxima iteração.

Embora esta analogia com uma espiral sejam comumente apresentada na literatura, ela é
deficiente, pois a ideia da linha da espiral leva a falsa noção de que a cada interação há um
progresso sequencial entre as atividades nos quadrantes (já que uma linha é algo sequencial
por natureza). Note que, ao contrário, o desenho na figura 11 mostra claramente a
simultaneidade das atividades. Há que se considerar, ainda, que existe uma variação de
esforço e de avanço no incremento das atividades entre as iterações. Assim, o desenho da
espiral não poderia ser simétrico, ou seja, a distância entre as linhas das iterações deveria
levar a um formato tortuoso.
Figura 11: Ilustração do Processo Iterativo com o descasamento das atividades.
Figura 12: Ilustração do Processo Iterativo na forma espiral.

O surgimento do processo iterativo de desenvolvimento de software foi um marco em
Engenharia de Software e, atualmente, fundamenta todas as propostas mais modernas de
desenvolvimento, não só na área de software. As principais características, vantagens e
desvantagens deste tipo de processo são listadas a seguir.
• Principais características do Processo Iterativo

o é um processo com atividades concorrentes de desenvolvimento de software
o se aplica a desenvolvimentos em que os requisitos pouco conhecidos ou instáveis
o deve ser executado por uma equipe dedicada
o representa a referência dos processos modernos de desenvolvimento
• Vantagens do Processo Iterativo
o tende a produzir melhores resultados em termos de satisfação do cliente (pois o
cliente pode participar das avalições a cada iteração, fornecendo feedback)
o tende a acomodar melhor as mudanças, pois a cada iteração seria possível ajustar
ou mudar coisas já feitas (obviamente, não sem custo)
o tende a promover a cooperação entre os membros da equipe, já que todos
trabalham em conjunto para o sucesso do produto final
• Desvantagens do Processo Iterativo
o é mais complexo de se entender, implantar e gerenciar
o tende a ser menos eficiente, pois há um custo do overhead das iterações.
o há um risco de produzir inconsistências quando é realizado na abordagem em
profundidade.
PROCESO UNIFICADO - RUP
TODO
MÉTODOS ÁGEIS
TODO
DESENVOLVIMENTO DIRIGIDO A MODELOS

O Desenvolvimento Dirigido a Modelos (MDD – Model Driver Development) é uma
abordagem para desenvolvimento de software que tem como foco os “modelos” e as
atividades de “modelagem” e “transformação de modelos”. Modelos são representações de
coisas reais ou conceituais, empregando algum tipo de linguagem gráfica como diagramas,
desenhos ou esboços. Seu principal atrativo está, justamente, em apresentar uma
representação gráfica, entendida como mais abstrata, mais compreensível ou mais intuitiva
ao ser humano.
A ideia de se usar modelos em computação para a modelagem de software é antiga. Há

décadas são empregados diagramas de blocos, de estados e fluxogramas, por exemplo, como
forma de definir a estrutura e o comportamento dos softwares a serem desenvolvidos. Os
modelos servem como instrumento auxiliar do desenvolvedor na concepção da estrutura e
lógica de funcionamento dos softwares e se prestam, também, como ferramenta de
comunicação entre os membros da equipe no lugar de documentos textuais ou códigos. Os
modelos também são importantes para documentação das soluções, de forma que outros
profissionais adiante possam ter um entendimento mais fácil do como o software foi
estruturado e opera, visando correções e evoluções.
Mesmo que, em algumas abordagens mais recentes e para alguns profissionais de

desenvolvimento de software, os modelos tenham um papel secundário e possam parecer
desnecessários, tradicionalmente, sabe-se de sua importância no desenvolvimento de
sistemas em geral em todas as áreas de engenharia. Em engenharia civil, por exemplo, os
modelos de planta, modelos dos projetos elétricos e hidráulicos, além de modelos estruturais
e, mesmo, modelos de maquetes são essenciais. Em engenharia mecânica, elétrica e
eletrônica, também, não é diferente. Em engenharia de software pode-se, igualmente, afirmar
que um desenvolvimento de software sem a modelagem é um empreendimento deficiente,
pois além da concepção arquitetural (tanto estrutural quando comportamental) do software
ser duvidosa, seguramente há uma deficiência em termos de documentação para fins de
evolução do produto. Apenas o conhecimento intelectual dos desenvolvedores e o código
gerado são sabidamente insuficientes para um software que se pretende manter no mercado
por um tempo maior.
Na visão de alguns profissionais de desenvolvimento de software, um elemento desmotivante

para a construção de modelos é o fato de que modelos descrevem um determinado software,
assim com os códigos também o fazem. Desta forma, criar modelos e programar parecem ser
duas atividades redundantes, apenas usando abstrações e linguagens distintas (e.g., UML
para modelar e Java para programar). Além disso, considera-se que a modelagem não cria
um produto “real”, enquanto a programação é mais prática, pois gera o software final.
Embora haja alguma dose de verdade nesta forma de ver a questão, nota-se aqui uma má
interpretação do papel da modelagem e de sua relação com a construção do código do
software.

Quando um software é desenvolvido, existem dois momentos distintos de atividade
intelectual dos desenvolvedores: a concepção e a construção. A “concepção” (que pode ser
também denomina “projeto” ou “design”) é um raciocínio criativo cujo propósito é imaginar
uma solução tecnológica com vistas a um conjunto de objetivos (ou seja, de resultados que
se quer alcançar). O desenvolver analisa os requisitos a serem cumpridos em termos de
funcionalidades e características e cria um conjunto de conceitos, módulos, componentes,
classes, atributos, métodos e relações de possam prover o que se busca. Mesmo que se possa
conduzir este raciocínio por partes, há sempre um compromisso de uma solução integrada,
coerente e eficiente para o conjunto. Comumente, emprega-se uma abordagem por abstração
em que se parte de uma solução mais geral e abstrata e detalha-se, gradualmente, seus
componentes até se alcançar uma solução suficientemente completa. A “construção” é um
raciocínio voltado para a obtenção de um objeto final, fazendo uso de alguma tecnologia de
implementação, como uma linguagem de programação. Pressupõe-se na construção que a
“forma” da solução já esteja definida e que ela atenda aos objetivos pretendidos. Assim, a
construção irá mapear os elementos definidos na concepção para a tecnologia escolhida. Este
mapeamento é também uma atividade intelectual, pois exige concentração, escolha de
alternativas e geração de novos artefatos tecnológicos (e.g., módulos, métodos, algoritmos).
Naturalmente, a construção depende da concepção, ou seja, antes de construir uma solução

tecnológica é necessário concebê-la. Em engenharia mecânica, por exemplo, é obvio que
antes de fabricar uma peça é necessário concebê-la (ou seja, projetar, dimensionar e desenhá-
la), pois se houver uma operação inadequada de corte ou furação na construção, ela é
irreversível. Em engenharia civil, também, não se pode construir uma obra antes de concebê-
la, pois não haveria como corrigir estruturas físicas já construídas caso a concepção levasse
a soluções diferentes do que se construiu. Em desenvolvimento de software, mesmo que se
possa imaginar que o software construído possa ser adequado a mudanças de concepção feitas
posteriormente, na prática, o esforço e custo podem ser consideráveis. Além disso, há uma
tendência de se alterar o mínimo necessário para adequar o que já foi construído a novos
elementos ou adequações na concepção, levando, ao final, a uma arquitetura que, mesmo
funcionando, pode ter problemas de qualidade e eficiência. Há um risco, também, de se seguir
um caminho de desenvolvimento do tipo “tentativa e erro” em que cada nova parte do código
que é construída terá que se adaptar às partes anteriormente construídas ou mudanças nas
partes anteriores deverão ser feitas para acomodarem as novas partes. Seguramente há um
custo considerável nesta abordagem levando, também, a uma solução pouco otimizada.
Podemos nos referir a esta solução final como uma arquitetura incidental, pois ela não nasceu
de uma concepção prévia intencional e sim, surgiu como resultado do caminho percorrido.
TODO – Completar a seção.

REFERÊNCIAS BIBLIOGRÁFICAS
Rook, 1986 Rook, P., Rook, E., Controlling software projects, IEEE Software Engineering
Journal, 1(1), 1986, pp. 7-16.
Larman, 2003 Larman, C. e Victor R. Basili, V. R., Iterative and Incremental Development: A
Brief History, IEEE Computer, 2003.
Boehm, 1986 Boehm, Barry, A Spiral Model of Software Development and Enhancement,
ACM SIGSOFT Software Engineering Notes. 11 (4): 14–24, 1986.
Swebok, 2014 Guide to Software Engineering Body of Knowledge, Ed. P. Bourque
e R. E. Fairley, IEEE Computer Society, 2014.
Glass, 2001 Glass, R. L., Frequently Forgotten Fundamental Facts about
Software Engineering, pg. 112, IEEE Software, May/June, 2001.

UTFPR - Caderno 2 - Processos de Desenvolvimento de Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

UTFPR - Caderno 2 - Processos de Desenvolvimento de Software

Enviado por

Direitos autorais:

Formatos disponíveis

CADERNOS DE ENGENHARIA DE SOFTWARE

PAULO CÉZAR STADZISZ

Esta é a primeira edição do Caderno 2 – Processos de Desenvolvimento de Software da série

Neste segundo caderno, aborda-se os Processos de Desenvolvimento de Software. O objetivo é

Prof. Dr. Paulo Cézar Stadzisz

2 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

NOTA SOBRE ESTA EDIÇÃO ........................................................................................................................ 2

3 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Desde o surgimento da Engenharia de Software, tem-se organizado o desenvolvimento de software

Neste caderno, busca-se apresentar os conceitos fundamentais de Processos de Desenvolvimento de

Boa leitura e bem-vindo(a) ao tema!

4 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Como em todas as engenharias, a Engenharia de Software também estipula que o

Nas organizações o termo “processo” é, também, amplamente utilizado na modelagem de

5 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Figura 1: Exemplo de processo de solicitação de um pedido modelado com BPMN.

Visando organizar, padronizar e obter a máxima eficiência no desenvolvimento de software,

6 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Um desenvolvimento de software se inicia com a informação de uma demanda de mercado

7 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Um ponto importante a destacar na figura 2, é a ilustração da linha contínua que mostra o

Dentro do ciclo econômico desenhado está a atividade de “Desenvolvimento de Software”,

8 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

Neste capítulo discute-se o conceito de “sistema” e de “engenharia de sistemas” com o

CONCEITO DE SISTEMA E ENGENHARIA DE SISTEMAS

É comum empregar-se o termo “sistema” na área de desenvolvimento de software. Nomes

A definição de software já foi esclarecida no “Caderno 1 – Introdução à Engenharia de

O conceito de sistema, suas propriedades e aplicações foi desenvolvido no último século

9 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

A figura 3 ilustra o conceito de hierarquia de sistema por meio do exemplo da descrição de

Figura 3: Organização de sistemas e subsistemas.

10 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

A criação e evolução da Engenharia de Sistemas permitiu aos países desenvolvidos

RELACIONAMENTO ENTRE ENGENHARIA DE SISTEMAS E ENGENHARIA DE

Enquanto a Engenharia de Software se aplica unicamente ao desenvolvimento de software, a

11 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

No sentido contrário, poderíamos nos perguntar se todo desenvolvimento de software requer

Figura 4: Ilustração de um software como componente de um sistema.

Um software interagindo com um conjunto de elementos externos, como ilustrado na figura

12 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

MACROPROCESSO DE DESENVOLVIMENTO DE SISTEMA

Na condição de que um software é parte de um sistema maior e significativo, seu

Figura 5: Visão geral de um macroprocesso de desenvolvimento de sistema.

13 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

• Desenvolvimento de Sistema (Engenharia de Sistema)

O primeiro bloco ou atividade no macroprocesso ilustrado na figura 5 é o de especificação e

i) SAP (Safety Assessment Process) – Processo de Avaliação de Segurança

O processo de avaliação de segurança (SAP - Safety Assessment Process) é um método para

14 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

ii) System Requirements Specification - Especificação de Requisitos do Sistema

A atividade de especificação de requisitos é realizada bem ao início do desenvolvimento do

iii) System Architecture – Aquitetura do Sistema

A definição da arquitetura do sistema é uma atividade criativa de concepção de uma solução

iv) System Behaviour – Comportamento de Sistema

A definição do comportamento do sistema é, também, uma atividade criativa de concepção

Na prática, em simultaneidade com a especificação e concepção do sistema, pode-se

15 Caderno 2 – Processos de Desenvolvimento de Software UTFPR

A atividade de Planejamento do Desenvolvimento é realizada pelo corpo técnico da equipe

A elaboração dos Padrões de Desenvolvimento tem por objetivo construir documentos

Os exemplos mais comuns de padrões são: Padrão de Especificação de Requisitos

i) Um Padrão de Especificação de Requisitos define uma maneira uniformizada da equipe

ii) Um Padrão de Projeto é um documento que define um modelo ou forma padronizada de

16 Caderno 2 – Processos de Desenvolvimento de Software UTFPR