unid05

Prévia do material em texto

Metodologia de 
Desenvolvimento de 
Sistemas 
Metodologia de 
Desenvolvimento de 
Sistemas 
1ª edição
2019
Autoria
Parecerista Validador
Samira Santos da Silva
Sandra Gavioli Puga / José Leão
*Todos os gráficos, tabelas e esquemas são creditados à autoria, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade da autoria a emissão de conceitos. Nenhuma parte
desta publicação poderá ser reproduzida por qualquer meio ou forma sem autorização. A violação dos
direitos autorais é crime estabelecido pela Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
63
 5Unidade 55. Processos de MDS
Para iniciar seus estudos
Nesta unidade, você compreenderá a definição de processo de 
desenvolvimento de software. Também assimilará os diversos tipos 
de fluxo de processos existentes, as diversas métricas para avaliar um 
processo e a forma como um processo unificado se organiza. Com a 
aprendizagem desses conceitos, você poderá fazer as melhores escolhas 
em seus projetos futuros.
Objetivos de Aprendizagem
• Definir processo de desenvolvimento de software e fluxo de 
processo de software.
• Aplicar métricas de projeto e processo de software.
• Definir a aplicação do processo unificado.
64
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Introdução da unidade
Esta unidade abordará diversos conceitos relacionados ao processo de desenvolvimento de software. 
Apresentaremos sua definição de forma que seja possível compreender sua localização dentro da engenharia 
de software. Abordaremos, também, os diversos tipos de fluxo de processo: linear, iterativo, evolucionário e 
paralelo. Compreender as suas diferenças possibilita que você saiba quando utilizá-los em seus projetos futuros. 
Além disso, evidenciaremos a definição de métricas de processo e projeto de software e apresentaremos alguns 
dos seus exemplos. Dessa forma, será possível assimilar as principais características por trás das métricas e sua 
importância, de modo que você se sentirá motivado a utilizá-las em seus projetos. Por fim, definiremos o processo 
unificado, um exemplo de processo que se utiliza das fases genéricas de um processo de desenvolvimento de 
software.
5.1 Processos de MDS
Nesta unidade, algumas definições sobre o processo de desenvolvimento de software serão abordadas. 
Inicialmente, a definição de processo de desenvolvimento de software será estabelecida, bem como as principais 
atividades de um processo genérico. Em seguida, os tipos mais básicos de fluxo de processos de desenvolvimento 
serão apresentados. Por fim, a importância das métricas na avaliação do processo e projeto de desenvolvimento 
de software será evidenciada, bem como será dado um exemplo de processo que pode ser representado utilizando 
as atividades genéricas, denominado processo unificado.
5.1.1 Definição de processo de desenvolvimento de software
De acordo com Pressman e Maxim, uma visão de um ponto de vista diferente sobre o processo de software, 
compreendido pela visão de um economista, Howard Beatjer Jr., é dada pelo seguinte trecho:
Porque o software, como todo capital, é conhecimento incorporado, e porque esse conhecimento é, 
inicialmente, disperso, tácito, latente e, em considerável medida, incompleto, o desenvolvimento 
de software é um processo de aprendizado social. Esse processo é um diálogo no qual o 
conhecimento, que deverá se tornar o software, é coletado, reunido e incorporado ao software. 
O processo possibilita a interação entre usuários e projetistas, entre usuários e ferramentas em 
evolução e entre projetistas e ferramentas em evolução (tecnologia). Trata-se de um processo 
iterativo no qual a própria ferramenta em evolução serve como meio de comunicação, com cada 
nova rodada do diálogo extraindo mais conhecimento útil das pessoas envolvidas (PRESSMAN; 
MAXIM, 2016, p. 30).
Podemos, de fato, entender a construção de um software como um processo de aprendizado social iterativo, cujo 
resultado (definido por Howard como “capital de software”) seria a integração do conhecimento que é coletado, 
filtrado e organizado durante o processo. 
O processo de software, de um ponto de vista mais técnico, pode ser definido como uma metodologia para 
atividades, ações e tarefas, cujo objetivo final é desenvolver um software de qualidade. O processo de software 
define a abordagem que será utilizada de acordo com a engenharia de software. Entretanto, a engenharia de 
65
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
software também incorpora as tecnologias que fazem parte do processo. Exemplo disso seriam as ferramentas 
automatizadas.
Compreendendo o processo de software como parte da engenharia de software, é importante 
notar que esse processo deve se adaptar de forma que se adeque aos produtos desenvolvidos 
e às necessidades do mercado.
De forma geral, podemos compreender o processo de software como uma série de passos previsíveis para a 
construção de um sistema. Ele pode ser visto como uma espécie de roteiro para que um software de qualidade 
seja produzido dentro de um prazo estabelecido. Geralmente, o processo de software é adaptado por engenheiros 
de software e gerentes para se adequar ao contexto em que será aplicado e, então, seus passos são seguidos. 
Clientes/usuários também têm um papel fundamental no processo de definição, construção e teste do software.
A importância do processo de software se dá, principalmente, pelo fato de que ele favorece com que haja 
controle, estabilidade e organização em uma atividade que poderia se tornar caótica sem essas características. 
Um processo deve ser “ágil” e, para isso, deve requerer somente atividades, controles e produtos adequados para 
a equipe que esteja produzindo e para o produto a ser produzido, além de atender às expectativas de negócio da 
organização. 
O processo de software a ser adotado vai depender do sistema a ser desenvolvido, além das características 
específicas da equipe que vai atuar no seu desenvolvimento. As etapas envolvidas serão diferentes se o sistema a 
ser construído é o software que atua no controle e gerenciamento do tráfego aéreo ou se o sistema é um website 
de uma loja que venda produtos eletrônicos na Internet. 
Os produtos de trabalho ou artefatos envolvidos no processo de software são os programas, documentos e dados 
que foram gerados como resultado das sequências de atividades e tarefas envolvidas no processo do software. 
As atividades, ações e tarefas realizadas dentro de um processo devem-se alocar dentro de uma metodologia 
ou modelo que determina como elas vão se relacionar entre si e também com o processo. A Figura 28 ilustra um 
exemplo de um processo de software genérico.
66
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 28 – Um modelo para um processo de software genérico
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
67
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Na figura acima, é possível identificar uma sequência com n atividades metodológicas. Atividades metodológicas 
são compostas por um conjunto de k ações de engenharia de software. Ações são compostas por um conjunto 
de tarefas que podem indicar as tarefas programadas para entrega e artefatos de software, ou seja, os programas 
que serão implementados, as garantias que serão requeridas no processo e, por fim, os prazos das entregas 
parciais, com o objetivo de avaliar o progresso. De forma geral, uma metodologia de processo precisa definir 
cinco atividades metodológicas: comunicação, planejamento, modelagem, construção e entrega. Além dessas 
atividades, podem ser aplicadas um conjunto de atividades de apoio durante o processo, com o objetivo, por 
exemplo, de avaliar o controle do projeto.
Uma afirmação interessante sobre processo de desenvolvimento de software encontrada em 
Pressman e Maxim e mencionada pelo engenheiro de software americano Tom DeMarco é a 
seguinte: “Achamos que desenvolvedoresde software não percebem uma verdade essencial: 
a maioria das organizações não sabe o que faz. Elas acham que sabem, mas não sabem” 
(PRESSMAN; MAXIM, 2016, p. 36).
5.2 Principais fluxos de processos de desenvolvimento de 
software
Tendo em vista as atividades genéricas que se fazem presentes em processos de software, faz-se necessário 
apresentar a definição do conceito de fluxo de processo. Podemos definir o fluxo do processo de desenvolvimento 
de sistemas como a forma como as atividades metodológicas são dispostas. Outra forma de visualizar seu 
significado é compreendê-lo como sendo maneiras de se organizarem ações e tarefas que fazem parte das 
atividades, com relação à ordem de execução e tempo. Fluxos de processo podem ser categorizados em quatro 
tipos: linear, iterativo, evolucionário e paralelo. 
O fluxo de processo de software linear executa cada uma das atividades metodológicas em sequência, uma 
seguida da outra, como se fossem uma série de atividades. Nesse fluxo, inicia-se pela etapa de comunicação e 
finaliza-se com a entrega do sistema ao cliente e a implantação no ambiente do usuário. A Figura 29 exemplifica 
o fluxo de processo linear.
Figura 29 – Fluxo de processo linear
Comunicação Planejamento Modelagem Construção Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
68
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Já o fluxo de processo iterativo organiza as atividades em uma sequência, como no fluxo linear, mas possui como 
diferença a característica de poder repetir uma ou mais atividades antes de prosseguir para a seguinte. Um 
exemplo de uma ilustração desse processo é mostrado na Figura 30.
Figura 30 – Fluxo de processo iterativo
Comunicação Planejamento Modelagem Construção Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Um processo de software que segue o fluxo de processo evolutivo organiza as suas atividades de forma circular, 
de modo que a cada volta no círculo, passando pelas cinco atividades, um novo incremento do software seja 
produzido. Assim, o software é entregue por completo ao final de várias voltas. A Figura 31 demonstra esse 
processo.
Figura 31 – Fluxo de processo evolutivo
Liberado
por
Incremento
Planejamento
Comunicação
Entrega Construção
Modelagem
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Por fim, o fluxo paralelo dispõe as atividades de modo que seja possível executar uma atividade em paralelo 
com outras. No caso do exemplo da Figura 32, a etapa de modelagem poderia ser realizada em paralelo com a 
construção de um outro aspecto do software.
69
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 32 – Fluxo de processo paralelo
Comunicação Planejamento
Modelagem
Construção
Tempo
Entrega
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Existem diversos mecanismos para a avaliação de processos de softwares, que possibilitam garantir com que o 
trabalho tenha sido feito de forma correta. Geralmente, essas métricas conseguem medir a “maturidade” do 
processo de software. Entretanto, a melhor forma de avaliar a qualidade de um processo de software é verificar 
a qualidade do software, o cumprimento de prazos e a viabilidade a longo prazo do sistema a ser desenvolvido. 
Esses quesitos conseguem dar uma ideia de forma precisa sobre a eficácia do processo de software utilizado. 
Sobre esse assunto, veremos mais detalhadamente na próxima seção. 
5.3 Métricas de processo e projeto de desenvolvimento de 
software
A medição do andamento do processo e do projeto de um software nos possibilita ter um mecanismo de avaliação 
objetiva para chegar a uma conclusão precisa sobre se os objetivos estipulados no princípio do desenvolvimento 
estão sendo atingidos. Como expressado em Pressman e Maxim, Lord Kelvin disse, certa vez:
Quando você pode medir o que você está falando e expressar em números, você sabe alguma coisa 
sobre aquilo; mas quando você não pode medir, quando você não pode expressar em números, o 
seu conhecimento é algo escasso e insatisfatório: pode ser o começo do conhecimento, mas você 
avançou muito pouco, em seu raciocínio, para o estágio de uma ciência (PRESSMAN; MAXIM, 
2016, p. 703).
As medições podem ser utilizadas no processo de software com o intuito de obter uma melhoria contínua no 
processo. Sua importância se dá, por exemplo, nas estimativas, na produtividade, controle de qualidade e no 
controle do projeto. Além disso, medições podem ser usadas na avaliação da qualidade dos artefatos produzidos 
a cada atividade executada, bem como podem ajudar na tomada de decisões em relação ao andamento do 
projeto. 
Uma equipe de software que está envolvida em um processo de software se preocupa, primariamente, com métricas 
de produtividade e qualidade. Essas métricas dizem respeito ao resultado do que foi feito em função do esforço 
70
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
e tempo aplicados e à adequação para uso dos artefatos produzidos. Se o intuito da medição é planejamento e 
estimativa, o interesse nessas medidas é ao longo do tempo. De acordo com Pressman e Maxim (2016), algumas 
das perguntas que poderiam ser feitas são as seguintes:
• Com que nível de qualidade o software foi produzido? 
• De que maneira a produtividade passada e os dados referentes à qualidade podem beneficiar o presente?
• De que forma utilizar esses dados pode te ajudar a realizar estimativas e planos de maneira mais precisa?
Podemos compreender métricas de projeto e processo de software como medidas quantitativas que permitem 
à equipe de desenvolvimento a avaliação da eficácia do processo de software e os projetos que são executados 
usando o processo. O objetivo desses dados é compará-los com dados do passado, a fim de verificar se ocorreram 
melhorias tanto de qualidade quanto de produtividade. Além disso, métricas podem ser utilizadas para a detecção 
de áreas que possuam problemas para que possam ser corrigidas e o processo de software aprimorado. 
A tarefa de analisar e avaliar as métricas de software é destinada aos gerentes de software. Os dados para realizar 
essa análise geralmente são coletados por engenheiros de software. A importância de se utilizar métricas de 
processo e projeto de software é imensa. Caso esses dados não fossem medidos, a avaliação seria feita somente 
de forma subjetiva, não permitindo a existência de uma avaliação mais eficaz e precisa. Por meio da medição, é 
possível que tendências boas e ruins sejam constatadas e, assim, levar ao aprimoramento das estimativas com o 
passar do tempo. 
Para a medição do processo e projeto de software, é necessário, a princípio, um conjunto restrito de medidas de 
processo, projeto e produto que sejam coletadas com facilidade. Elas podem, por exemplo, ser normalizadas 
utilizando-se de métricas que são orientadas a tamanho ou função. O resultado da normalização é comparado 
com valores anteriores que foram obtidos em projetos similares. Por fim, são detectadas as tendências e obtidas 
as conclusões.
Uma forma de garantir com que o trabalho de medição de processo e projeto de software seja 
empregado de forma correta é utilizar um sistema de medições que seja consistente, porém 
simples, que nunca deve ser usado para avaliar, recompensar ou até mesmo punir indivíduos 
da equipe pelo seu desempenho pessoal.
Fique atento!
No livro de (PARK, 1996), que consiste em um guia para medições de software, são ressaltadas as razões pelas 
quais medimos:
1. Caracterizar, na busca por conhecer processos, produtos, recursos e ambientes, bem como para definir 
embasamento para futuras comparações.
2. Avaliar, a fim de estabelecer o status atual em comparação com o planejado.
3. Prever compreendendo a forma como processos se relacionam e modelando estas relações.
71
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
4. Melhorar reconhecendo etapas, origens de problemas, inabilidades, dentre outros recursos que podem 
ser melhoradosafim de aumentar a qualidade do processo e do produto.
Utilizada como ferramenta de gerenciamento, a medição proporciona discernimento ao gerente de projeto. Por 
consequência, a equipe de desenvolvimento, como um todo, tomará as melhores decisões que levarão a um 
projeto de sucesso. 
5.3.1 Métricas de processo x Métricas de projeto
Apesar de métricas de processo e projeto por muitas vezes serem as mesmas, é interessante destacar as 
características de cada uma delas. As métricas de processo são obtidas de todos os projetos que foram realizados 
por um longo período de tempo. Seu principal objetivo é o levantamento de indicadores de processo que resultam 
na melhoria do processo de software à longo prazo. Já as métricas de projeto permitem com que o gerente de 
projetos: avalie o andamento do projeto, traçe potenciais riscos, descubra possíveis áreas problemáticas com 
antecedência, realize ajustes no fluxo de tarefas e avalie a habilidade da equipe de projeto no controle de 
qualidade do software final. 
Na maior parte das vezes, as mesmas métricas são utilizadas tanto no domínio do processo quando no domínio 
do projeto. Exemplo disso pode ser visto nas seções 5.3.2 e 5.3.3 onde serão abordados dois tipos de métricas de 
software que podem ser utilizadas tanto como métrica de processo quanto métrica de projeto.
Métricas de processo possuem impacto a longo prazo e seu objetivo consiste em melhorar 
o próprio processo. As métricas de projeto frequentemente acabam contribuindo para o 
desenvolvimento de métricas de processo. 
Saiba mais
Não se deve utilizar métricas para comparar indivíduos ou equipes do desenvolvimento de 
um software, visto que existem muitos fatores que afetam o processo.
Fique atento!
5.3.2 Métricas orientadas a tamanho
Para compreender as métricas orientadas a tamanho, vamos primeiro analisar um exemplo de situação. Suponha 
que os membros de duas equipes de projetos diferentes, equipe X e equipe Y, registrem todos os erros encontrados 
durante o processo de software dos seus respectivos projetos. As medidas dos membros de cada equipe são 
combinadas a fim de obter uma medida por equipe. A equipe X encontrou 330 erros durante o processo de 
72
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
software. Já a equipe Y encontrou 170. Sendo iguais em todas as características restantes, qual foi a equipe mais 
eficaz na descoberta de erros no processo? Esta é uma pergunta difícil de se responder, visto que não se sabe o 
tamanho ou a complexidade do projeto de cada equipe. Entretanto, se normalizarmos as medidas, poderíamos 
comparar os valores obtidos por ambas as equipes de maneira mais justa.
Métricas de software orientadas a tamanho são estabelecidas com base em medidas de qualidade ou 
produtividade que são normalizadas considerando o tamanho do software desenvolvido. Dessa forma, se uma 
organização preserva um registro com o histórico dos projetos desenvolvidos, a elaboração de uma tabela de 
medidas orientadas a tamanho se torna possível, como ilustra a Tabela 2 a seguir.
Tabela 2 – Métricas orientadas a tamanho
Projeto Linhas de Código Esforço Custo Pág. Doc. Erros Defeitos Pessoas
Alfa 12100 24 168 365 134 29 3
Beta 27200 62 440 1224 321 86 5
Gama 20200 43 314 1050 256 64 6
... ... ... ... ... ... ... ...
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
No exemplo da figura acima, temos o registro de cada um dos projetos que foi desenvolvido por determinada 
organização ao longo dos anos e algumas medidas que correspondem a eles. Considere, por exemplo, a linha 
correspondente ao projeto denominado Alfa. Esse projeto resultou em 12.100 linhas de código, tendo a 
contribuição de 24 pessoas/mês e o custo de 168 mil dólares. É importante notar que tanto o trabalho quanto 
o custo na tabela correspondem a todas as atividades de engenharia de software, não contemplando apenas a 
etapa de codificação. Além disso, outras informações a respeito desse projeto é que foram criadas 365 páginas 
de documentação, 134 erros foram encontrados durante o processo de software todo e 29 defeitos foram 
apresentados após a entrega do software para o cliente no primeiro ano do sistema em operação. Por fim, na 
parte de codificação do software, três pessoas estavam envolvidas. 
Partindo da Tabela 2, é possível escolher, por exemplo, o número de linhas de código como um valor de 
normalização. Seguem abaixo alguns exemplos de métricas simples orientadas a tamanho que poderiam ser 
utilizadas normalizando pelo número de linhas de código:
• Erros por MLDC (1.000 linhas de código).
• Defeitos por MLDC.
• Custo por MLDC.
• Páginas de documentação por MLDC.
Além disso, outras métricas interessantes seriam:
• Erros por pessoa-mês.
• MLDC por pessoa-mês.
• Custo por página de documentação.
73
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Apesar da ampla utilização das métricas orientadas a tamanho, ainda existe um grande 
debate sobre sua validade e aplicabilidade.
Saiba mais
Métricas orientadas por tamanho são simples e rápidas. Entretanto, nem sempre são aceitas como a melhor 
forma de medir processos de software. A maior razão para isso é o fato de elas utilizarem as linhas de código 
como principal medida. Os defensores da utilização da medida LDC (linhas de código) alegam que LDC é uma 
característica que qualquer projeto de desenvolvimento de software possui e, por isso, pode ser facilmente obtida. 
Além disso, diversos modelos para estimativa de software existentes recebem como entrada LDC e diversos 
métodos da literatura e dados já utilizam LDC. 
Em contrapartida, oponentes da medida afirmam que LDC é bastante dependente da linguagem de programação 
e, na avaliação de produtividade, programas bem projetados e menores seriam penalizados, linguagens 
procedurais não poderiam ser utilizadas com essas métricas. Também defendem que a estimativa de LDC é algo 
difícil de planejar, visto que no princípio do projeto é difícil ter uma noção do número de linhas que o código 
conterá.
5.3.3 Métricas orientadas a função
Outra métrica que utiliza a normalização de medidas é a métrica de software orientada a função. A diferença em 
relação à métrica orientada a tamanho é o fato de que a normalização na métrica orientada a função acontece 
usando uma medida da funcionalidade fornecida pelo sistema como valor de normalização. A métrica orientada 
a função mais utilizada atualmente é a Pontos de Função (Function Point – FP). O cálculo de pontos de função 
tem como base as características de domínio de informação e a complexidade do software. 
Assim como LDC, a utilização do ponto de função como métrica é, por vezes, bastante controverso. Os defensores 
da métrica afirmam que essa função é independente da linguagem de programação, o que faz ela ser ideal para 
aplicações com diferentes linguagens. É ideal que elas sejam convencionais ou não procedurais e que a métrica 
é baseada em dados com grandes chances de serem conhecidos na evolução de um projeto. Sendo assim, FP 
se torna mais atraente na elaboração de estimativas. Já os oponentes à métrica alegam que é necessário um 
pouco de “jeitinho” no método, visto que ele é baseado em dados subjetivos em vez de objetivos, as contagens 
do domínio de informações podem ser algo difícil de ser computado. Também alegam que a FP é apenas um 
número, não tendo significado físico claro.
Existem diversos tipos de métricas aqui não abordados. Para determinar a melhor métrica 
para um processo de software específico, é necessário analisar o contexto em que o software 
está sendo desenvolvido e sua aplicação final. 
Saiba mais
74
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
5.4 O processo unificado
De acordo com o livro que deu origem ao processo unificado (JACOBSON, 1999), o mesmo foi fruto de uma busca 
por um processo de software que fosse “dirigido a casos de uso, centrado na arquitetura, iterativo e incremental”. 
Entre as característicasdo processo unificado, está o fato de ele buscar o aproveitamento dos melhores recursos 
e características dos modelos tradicionais de desenvolvimento de software, enquanto os adapta de modo a 
implementar muitos dos princípios do desenvolvimento ágil de software. Além disso, o processo unificado tem 
por característica o reconhecimento da importância da comunicação com o cliente e de métodos racionalizados 
que possam descrever a visão do cliente sobre o sistema desejado (ex.: casos de uso). Por fim, enfatiza o papel 
da arquitetura de software, o que ajuda o arquiteto a ter foco nas metas corretas, e sugere um fluxo de processo 
iterativo e incremental, de forma que dá uma sensação evolucionária necessária no desenvolvimento moderno. 
Em meados de 1990, James Rumbaugh, Grady Booch e Ivar Jacobson começaram a trabalhar em um método 
unificado que combinasse as melhores características de cada um dos métodos individuais de análise e 
projeto orientados a objetos. O resultado foi a Linguagem de Modelagem Unificada (UML), que é utilizada até 
os dias atuais para modelar sistemas. Em 1997, a UML se tornou de fato um padrão no desenvolvimento de 
softwares orientados a objetos. Durante os anos que se seguiram, os três autores da UML desenvolveram o 
Processo Unificado (UP), um método de engenharia de software orientada a objetos utilizando UML. Atualmente, 
tanto o processo unificado quanto a UML são amplamente utilizados.
5.4.1 Fases do processo unificado
O processo unificado pode ser descrito utilizando as atividades genéricas abordadas na Seção 5.1, que são úteis em 
quaisquer processos. A fase de concepção envolve as atividades de comunicação com o cliente e planejamento. 
Nessa fase, com a colaboração de clientes, as necessidades de negócio do software são identificadas e propõe-se 
uma arquitetura simples para os sistemas, além de se desenvolver um planejamento para a natureza iterativa e 
incremental do projeto. A fase de elaboração envolve as atividades de comunicação e modelagem do modelo 
de processo genérico. Nessa fase, são refinados e expandidos os casos práticos preliminares desenvolvidos na 
concepção. Divide-se a visão da arquitetura em cinco modelos: modelo de caso prático, modelo de requisitos, 
modelo de projeto, modelo de implementação e modelo de emprego. Na elaboração, há também uma revisão 
do plano de forma bastante cuidadosa para ver se não é necessária alguma alteração. 
A fase de construção é idêntica à atividade genérica de construção definida para um processo de software 
qualquer. Sua entrada é o modelo de arquitetura. Essa fase desenvolve ou agrega componentes de software, 
de forma que cada caso prático se torne uma funcionalidade no sistema. Modelos de requisitos e projeto são 
finalizados e implementam-se no código-fonte todas as funções exigidas para o incremento de software. 
A fase de transição engloba os últimos estágios da atividade de construção e a primeira parte da atividade de 
emprego/entrega, consistindo na entrega e no feedback do usuário. Testes beta com usuário são realizados na 
busca de encontrar defeitos ou mudanças necessárias no software. Manuais técnicos e de usuários são elaborados, 
e nessa fase o resultado é uma versão utilizável do software. Por fim, a fase de produção consiste na fase final 
do emprego/entrega do software. Essa fase engloba o monitoramento da utilização do software pelo usuário, 
enquanto disponibiliza-se suporte ao mesmo, implementando e analisando relatórios de defeitos ou mudanças. 
A Figura 33 ilustra as fases do processo unificado, bem como as atividades genéricas existentes nos processos de 
software.
75
Metodologia de Desenvolvimento de Sistemas | Unidade 5 - Processos de MDS
Figura 33 – O processo unificado
Planejamento
Comunicação
Modelagem
ConstruçãoEntrega/
Emprego
Incremento de
Software
Produção
Transição
Versão
Concepção
Elaboração
Construção
Fonte: Adaptada de PRESSMAN; MAXIM, 2016.
Síntese da unidade
Esta unidade abordou o conceito de processo de desenvolvimento de softwares e conceitos relacionados, tais 
como: principais fluxos de processo, métricas de processo e projeto de software e o processo unificado.
76
Considerações finais
A compreensão do processo de desenvolvimento de software é essencial 
para sua utilização de forma eficaz e eficiente, porque possibilita 
que decisões sejam tomadas de forma mais precisa. Desse modo, 
evitam-se prejuízos, tanto em termos de tempo quanto em termos 
financeiros, levando o software desenvolvido a atender às expectativas de 
negócio da organização. 
	Unidade 1
	1. Histórico do Desenvolvimento de Software 
	Unidade 2
	2. Fundamentos de Desenvolvimento de Software
	Unidade 3
	3. Modelos do Ciclo de Vida de Projetos de Desenvolvimento de Software
	Unidade 4
	4. Modelos MDS 
	Unidade 5
	5. Processos de MDS
	Unidade 6
	6. Tipos MDS 
	Unidade 7
	7. Qualidade em MDS
	Unidade 8
	8. Estudos de Casos com Uso de Software CASE