Engenharia de Software I: Carlos Helmar Duarte

ENGENHARIA DE SOFTWARE I
Carlos Helmar Duarte
1
Carlos Helmar Duarte
Mestre em Educação pela PUC/MG - Pontifícia Universidade Católica de Minas Gerais,

especialista em Educação, Comunicação e Tecnologia, pela UEMG - Universidade do
Estado de Minas Gerais. Graduado em Pedagogia pela Universidade do Estado de Minas
Gerais e graduado em Análise e Desenvolvimento de Sistemas pela UNOPAR - Universidade
do Norte do Paraná. Tutor à distância e presencial em cursos de graduação em Pedagogia
e Cursos de Extensão na área de Educação e Tecnologia desde 2006. Professor
Pesquisador e Designer Instrucional dos cursos de EAD da Universidade do Estado de Minas
Gerais. Tem experiência na docência na área de Educação com os conteúdos de
Matemática e Informática para o ensino Fundamental e Médio; e Educação Tecnológica
para o ensino superior. Integrante do grupo de estudos ETCS - Educação, Tecnologia,
Ciências e Sociedade da PUC/MG. Participou efetivamente do NECT - Núcleo de Estudos
sobre Comunicação e Tecnologia da UEMG, de 2003 a 2007. Diretor da Divisão de Apoio
Administrativo do Departamento de Administração de Pessoal da UFMG – Universidade
Federal de Minas Gerais, desde 2010.
ENGENHARIA DE SOFTWARE I
1ª edição
Ipatinga – MG
2023
2
FACULDADE ÚNICA EDITORIAL
Diretor Geral: Valdir Henrique Valério

Diretor Executivo: William José Ferreira
Ger. do Núcleo de Educação a Distância: Cristiane Lelis dos Santos
Coord. Pedag. da Equipe Multidisciplinar: Gilvânia Barcelos Dias Teixeira
Revisão Gramatical e Ortográfica: Izabel Cristina da Costa
Revisão/Diagramação/Estruturação: Bruna Luiza Mendes Leite
Fernanda Cristine Barbosa
Guilherme Prado Salles
Lívia Batista Rodrigues
Design: Bárbara Carla Amorim O. Silva
Élen Cristina Teixeira Oliveira
Maria Eliza Perboyre Campos
© 2023, Faculdade Única.
Este livro ou parte dele não podem ser reproduzidos por qualquer meio sem Autorização
escrita do Editor.
Ficha catalográfica elaborada pela bibliotecária Melina Lacerda Vaz CRB – 6/2920.
NEaD – Núcleo de Educação a Distância FACULDADE ÚNICA

Rua Salermo, 299
Anexo 03 – Bairro Bethânia – CEP: 35164-779 – Ipatinga/MG
Tel (31) 2109 -2300 – 0800 724 2300
www.faculdadeunica.com.br
3
Menu de Ícones
Com o intuito de facilitar o seu estudo e uma melhor compreensão do conteúdo
aplicado ao longo do livro didático, você irá encontrar ícones ao lado dos textos. Eles
são para chamar a sua atenção para determinado trecho do conteúdo, cada um
com uma função específica, mostradas a seguir:
São sugestões de links para vídeos, documentos

científicos (artigos, monografias, dissertações e teses),
sites ou links das Bibliotecas Virtuais (Minha Biblioteca
e Biblioteca Pearson) relacionados com o conteúdo
abordado.
Trata-se dos conceitos, definições ou afirmações
importantes nas quais você deve ter um maior grau
de atenção!
São exercícios de fixação do conteúdo abordado

em cada unidade do livro.
São para o esclarecimento do significado de

determinados termos/palavras mostradas ao longo
do livro.
Este espaço é destinado para a reflexão sobre
questões citadas em cada unidade, associando-o a
suas ações, seja no ambiente profissional ou em seu
cotidiano.
4
SUMÁRIO
UNIDADE ENGENHARIA DE SOFTWARE: CONTEXTUALIZAÇÃO HISTÓRICA E

CONCEITOS BÁSICOS ............................................................................... 8
01 1.1
1.2
1.3
1.3.1
HISTÓRIA E CONCEITO DE SOFTWARE ............................................................. 8
CONTEXTO HISTÓRICO DO SOFTWARE............................................................ 9
TRABALHANDO OS CONCEITOS BÁSICOS DA ENGENHARIA DE SOFTWARE
......................................................................................................................... 12
Conceitos iniciais.................................................................................................12
1.3.2 Sistemas sociotécnicos.......................................................................................13
1.4 ENGENHARIA DE SOFTWARE NOS DIAS ATUAIS ............................................ 16
FIXANDO O CONTEÚDO ................................................................................. 20
UNIDADE CONCEITOS E MODELOS DE PROCESSO DE SOFTWARE ........................ 24
02
2.1 MODELOS DE PROCESSOS DE SOFTWARES.................................................... 24
2.2 CICLOS DE VIDA DE UM SOFTWARE............................................................... 26
2.2.1 Modelo em Cascata ..........................................................................................27
2.2.2 Prototipação ........................................................................................................28
2.2.3 Modelo de desenvolvimento Baseado em Componentes ........................29
2.2.4 Entrega Incremental ...........................................................................................31
2.2.5 Modelo Espiral......................................................................................................32
2.3 ATIVIDADES DE PROCESSO DE SOFTWARE .................................................... 34
2.3.1 Especificação de software ...............................................................................34
2.3.2 Implementação de software ............................................................................35
2.3.3 Validação de software ......................................................................................36
2.3.4 Evolução (manutenção) de software ............................................................38
FIXANDO O CONTEÚDO ............................................................................. 2044
UNIDADE INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS.............................. 46
03
3.1 VISÃO GERAL E CONCEITOS DO GERENCIAMENTO DE PROJETOS ................ 46
3.2 ATIVIDADES, PLANEJAMENTO E CRONOGRAMA DE PROJETOS DE SOFTWARES
............................................................................................................................ 49
3.2.1 Visão geral das atividades de gerenciamento de projeto de software.....50
3.2.2 Visão geral do planejamento de gerenciamento de projeto de software
...................................................................................................................................51
3.2.3 Visão geral do cronograma de gerenciamento de projeto de software ..53
3.3 ANÁLISE DE RISCOS ........................................................................................... 55
FIXANDO O CONTEÚDO .................................................................................... 59
UNIDADE ENGENHARIA DE REQUISITOS ................................................................. 63
04
4.1 ESTUDOS DE REQUISITOS: CONCEITOS E IMPORTÂNCIA ................................. 63
4.1.1 Importância do estudo de requisitos .................................................................64
4.1.2 Engenharia de Requisitos .....................................................................................65
4.2 REQUISITOS DE UM SOFTWARE: CARACTERÍSTICAS GERAIS, REQUISITOS
FUNCIONAIS E NÃO FUNCIONAIS .................................................................... 67
4.2.1 Características gerais ............................................................................................67
4.2.2 Requisitos Funcionais .............................................................................................68
4.2.3 Requisitos Não funcionais .....................................................................................70
4.3 ELICITAÇÃO E ANÁLISE DE REQUISITOS............................................................ 73
4.3.1 Levantamento de requisitos ................................................................................74
4.3.2 Análise de requisitos ..............................................................................................76
4.3.3 Documentação de requisitos ..............................................................................78
4.4 Validação de requisitos ................................................................................... 79
5
UNIDADE INTRODUÇÃO AO ESTUDO DE PROJETOS ORIENTADO A OBJETOS (UML -
UNIFIED MODELING LANGUAGE) ........................................................... 86
05
5.1 VISÃO GERAL DA MODELAGEM ORIENTADA A OBJETOS............................... 86
5.2 CLASSES, ATRIBUTOS E OPERAÇÕES ................................................................. 88
5.2.1 Classes ......................................................................................................................88
5.2.2 Atributos ...................................................................................................................89
5.2.3 Operações ..............................................................................................................90
5.3 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE COM UML ...................... 93
5.3.1 Contexto de sistema e modelos de uso ............................................................94
5.3.2 Projeto de arquitetura ...........................................................................................95
5.3.3 Identificação dos objetos principais do sistema ..............................................96
5.3.4 Modelo de projetos ...............................................................................................97
5.3.5 Especificar interfaces de objetos ........................................................................97
UNIDADE MODELAGEM BÁSICA: DIAGRAMAS UML .................................. 103
06
6.1 CONCEITOS E MODELOS ................................................................................. 103
6.2 DIAGRAMAS ESTRUTURAIS ............................................................................... 104
6.2.1 Diagrama de Classes ......................................................................................... 105
6.2.2 Diagrama de Objetos ........................................................................................ 107
6.3 DIAGRAMAS COMPORTAMENTAIS ................................................................. 108
6.3.1 Diagrama de Caso de Uso ............................................................................... 109
6.3.2 Diagrama de Atividades ................................................................................... 112
6.3.3 Diagramas de interação ................................................................................... 115
FIXANDO O CONTEÚDO ............................................................................................. 118
RESPOSTAS DO FIXANDO O CONTEÚDO .................................... 122
REFERÊNCIAS................................................................................. 123
6
CONFIRA NO LIVRO
A unidade I tem como objetivo vincular o conhecimento sobre o

termo “Software” à sua origem e a sua aplicação, a partir de uma
contextualização histórica do termo. Serão discutidos também
nesta unidade os principais conceitos e o contexto nos dias atuais
sobre a Engenharia de Software.
A unidade II tem como objetivo discutir os principais conceitos e

modelos de processo e os ciclos de vida de um software, (Clássico,
prototipação, espiral, etc.). Serão abordadas também as
atividades do processo de um software, desde a especificação até
a sua validação.
A unidade III aborda uma visão geral e os principais conceitos

introdutórios sobre gerenciamento de projetos. Será discutida nessa
unidade, além das atividades, do planejamento e do cronograma,
a análise de riscos dos projetos em engenharia de software.
Na unidade IV o objetivo é discutir a Engenharia de Requisitos. Serão

abordados os principais conceitos e a importância da Engenharia
de Requisitos e para isso serão caracterizados os requisitos
funcionais e não funcionais de um software, além de propor uma
discussão sobre a elicitação e análise de requisitos.
A unidade V tem como objetivo apresentar uma visão geral da

modelagem orientada a objetos – UML. Para isso, propõe-se discutir
os conceitos de classe, atributos e operações, além de introduzir
definições sobre o processo de desenvolvimento de projeto de
software com UML.
A unidade VI tem como objetivo, a partir dos conceitos

apresentados na unidade V, definir e caracterizar os diagramas da
modelagem básica em UML. Serão apresentados os dois grupos de
diagramas (estrutural e comportamental) e alguns seus de
principais subtipos.
7
ENGENHARIA DE SOFTWARE: UNIDADE
CONTEXTUALIZAÇÃO HISTÓRICA E
CONCEITOS BÁSICOS
01
1.1 HISTÓRIA E CONCEITO DE SOFTWARE
Quando as pessoas pensam no termo software, a primeira associação feita é

com programas de computador. Tecnicamente, software pode ser definido como
sendo um conjunto de componentes lógicos e de programas presentes em
computadores, celulares, carros, dentre outros. Autores como Sommerville (2007),
Pfleeger(2004), e Pressman (2011) consideram esse conceito simplista, e descrevem
que o conceito de software se refere também a todos os dados de documentação
do projeto e configurações associados aos sistemas, os quais são necessários para
que o programa funcione corretamente.
Para Pressman (2011, p. 31):
Hoje, o software assume um duplo papel. Ele é um produto e, ao

mesmo tempo, o veículo para distribuir um produto. Como produto,
fornece o potencial computacional representado pelo hardware ou,
de forma mais abrangente, por uma rede de computadores que
podem ser acessados por hardware local. (...) Como veículo de
distribuição do produto, o software atua como a base para o controle
do computador (sistemas operacionais), a comunicação de
informações (redes) e a criação e o controle de outros programas
(ferramentas de software e ambientes).
O software é responsável pelo produto mais importante nas relações dos seres
humanos atualmente, a informação. Para contexto apresentado, e visando os
objetivos iniciais dessa unidade de contextualização e caracterização do termo
software, é importante descrever o significado de sistema. Na engenharia de
software, sistema pode ser definido como sendo “um conjunto intencional de
componentes inter-relacionados que funcionam juntos para atingir certo objetivo”
(SOMMERVILLE, 2007, p.14). Para o autor essa definição de sistema abrange um vasto
universo de sistemas, desde os mais simples aos mais complexos.
Após as definições de software e sistema, é ilustrado na figura 1 um esquema
que resume o sistema de software.
8
Figura 1: Definição de sistema de Software
Fonte: Adaptado de Sommerville (2007, p. 04)
1.2 CONTEXTO HISTÓRICO DO SOFTWARE
A evolução do software ocorreu, desde o seu início, de forma acelerada. O

objetivo principal no começo não estava diretamente relacionado com a interação
entre o usuário e a máquina. O maior investimento estava centralizado em um
hardware que pudesse gerar processamento de dados em grande volume, deixando
assim o desenvolvimento do software em segundo plano.
Com o passar do tempo os conceitos sobre o uso das máquinas sofreram
mudanças, e as necessidades dos usuários têm um papel importante nesse novo
cenário que se configura com a evolução tecnológica. A exigência passa a ser por
equipamentos menores e com maior eficiência no desempenho das atividades, ou
seja, buscam-se, além do desenvolvimento do hardware, maiores investimentos na
produção dos softwares.
Até o começo da década de 70, o desenvolvimento estava centrado na parte
física da máquina, dessa forma a evolução dos softwares e as modificações ainda
não eram evidentes para os usuários. A mudança dessa concepção começa a
ocorrer com o aparecimento dos computadores multiusuários, os quais possibilitavam
um processamento de dados em tempo real.
Na figura 2, é apresentado um resumo da linha do tempo sobre a evolução
dos softwares e hardwares.
9
Figura 2: Evolução software/hardware
Fonte: Adaptado de Stallings (2010, p.12-27).
Na figura 2, a primeira geração de computadores (1940), tem como

característica principal a utilização de válvulas e programação baseada no sistema
binário, uma combinação que gastava a maior parte do tempo no processamento
de dados. Foi nessa geração que houve a evolução do armazenamento de dados
em cartões perfurados para as fitas magnéticas.
Na segunda geração de computadores (1950), ocorre o aparecimento das
máquinas com transistores, considerado uma revolução na época. Algumas
características importantes dos transistores era o fato de serem mais rápidos e
confiáveis e terem um consumo menor de energia. Nessa geração, além do alto
custo dos equipamentos, desperdiçava-se muito tempo no processo de operação
das maquinas, dessa forma uma das soluções que as pessoas encontraram para
reduzir o tempo desperdiçado foi o sistema de processamento em lotes.
A ideia era reunir em uma bandeja (tray) um conjunto de jobs da sala

de submissão e então lê-los em uma fita magnética usando um
computador relativamente pequeno e barato, como o IBM 1401, que
era muito bom para ler cartões, copiar fitas e imprimir a saída, mas
péssimo para cálculos numéricos (TANENBAUM; WOODHULL, 2008 p.
27).
10
Para entender mais sobre o sistema de processamento em lotes, recomenda-se a leitura
das páginas 26 e 27 do livro, Sistemas operacionais: projeto e implementação de Andrew
S. Tanenbaum, Albert S. Woodhull. O livro está disponível na biblioteca virtual, no link:
https://shre.ink/HZ2Y. Acesso em: 20 jan. 2023.
Na terceira geração de computadores (1958) as máquinas começam a ser

equipadas com os circuitos integrados - os microchips, feitos de silício. Uma das
principais evoluções nessa época foi à construção de equipamentos menores e mais
baratos.
De acordo com Stallings (2010, p.26) “Além da terceira geração, existe pouco
consenso geral sobre a definição das gerações de computadores”. De acordo com
o autor, há diversas gerações posteriores, todas com base nos avanços da tecnologia
do circuito integrado. Um fator importante no contexto das gerações posteriores
aconteceu em 1971, com o aparecimento do microprocessador, quando a Intel
descobriu o chip (4004), primeiro chip que possuía todos os componentes de um
processador. Isso possibilitou avanços, conforme afirma o autor, “no processamento
de imagens, reconhecimento de voz, videoconferência, criação de multimídia,
desenvolvimento em arquivos de voz e vídeo e modelagem de simulação”. (P. 29)
A partir da década de 90, com os avanços na estrutura e composição do
hardware, começam a surgir novas exigências das pessoas e organizações, o que
gerou maiores desafios no desenvolvimento de softwares. O aparecimento e a
evolução da rede mundial de computadores – Internet trouxe consigo uma nova
maneira de se buscar e disponibilizar o dado, a informação e o conhecimento, o que
exigiu, na época, um desenvolvimento de software voltado para a eficiência.
Nesse contexto, há uma mudança brusca nas estratégias para o
desenvolvimento de software, ou seja, no começo, o desenvolvedor tinha suas
próprias técnicas, e o software era construído com base na sua experiência pessoal,
no entanto, nos dias atuais para se garantir uma qualidade na produção de um
software é necessário o uso de técnicas diferenciadas, um conjunto de metodologias
e um bom trabalho em equipe. Neste momento é que surge a Engenharia de
Software.
BUSQUE POR MAIS
11
Para saber mais sobre a história e desempenho de computadores, sugerimos a leitura da
parte I, capítulo 2 “Evolução e desempenho do computador” (páginas 12 a 45) do livro
“Arquitetura e organização de computadores: Projeto para o desempenho” de William
Stallings, disponível na biblioteca virtual no endereço eletrônico https://abrir.link/FVKNj.
Acesso em: 20 jan. 2023.
Na seção 1.2 serão discutidos conceitos e termos com o objetivo de elucidar

o campo de trabalho com projetos de desenvolvimento de software associados ao
campo da Engenharia de Software.
1.3 TRABALHANDO OS CONCEITOS BÁSICOS DA ENGENHARIA DE SOFTWARE
1.3.1 Conceitos iniciais
Alguns conceitos iniciais referentes à elaboração e uso de softwares são

importantes para o um melhor entendimento da área de estudo de Engenharia de
Software.
O conceito de engenharia no dicionário Priberam online refere-se ao
“Conjunto de técnicas e métodos para aplicar o conhecimento técnico e científico
na planificação, criação e manutenção de estruturas, máquinas e sistemas para
benefício do ser humano”. A associação do conceito de engenharia e o conceito
de software apresentado na seção 1.1 dessa unidade auxiliam em um melhor
entendimento da definição proposta por Sommerville (2007) para o termo Engenharia
de Software. Para o autor “A Engenharia de Software é uma disciplina de engenharia
relacionada com todos os aspectos da produção de software, desde os estágios
iniciais de especificação do sistema até sua manutenção, depois que este entrar em
operação” (p.5). A Engenharia de Software está relacionada com os processos
técnicos de desenvolvimento e gerenciamento de projeto de software, além de
desenvolver também “ferramentas, métodos e teorias que apoiem a produção do
software” (p.5).
Ao longo dos tempos o processo de desenvolvimento de softwares tem
passado por alterações significativas, uma evolução no tempo de elaboração, no
desenvolvimento, na metodologia, nos ciclos de vidas e no custo dos projetos.
Nesse contexto, vários fatores contribuíram para uma discussão mais
12
aprofundada sobre as atividades de desenvolvimento dos softwares nas últimas
décadas. Esses fatores estão diretamente relacionados, primeiro, com às altas
complexidades do sistema que surgiram com a evolução do processamento das
imagens e sons que foram integradas aos hardwares de pequeno porte; e segundo
com as integrações, as quais ficaram cada vez mais evidentes nos diversos tipos de
hardwares e de sistemas operacionais, seja para o uso no computador doméstico ou
científico.
1.3.2 Sistemas sociotécnicos
Para um melhor entendimento das definições propostas para o termo de

engenharia de software, serão apresentadas a seguir conceitos, termos e
características dos sistemas sociotécnicos, que além de abordagens sobre
componentes de hardware e software, incluem também, procedimentos e
processos.
As discussões descritas nesse livro sobre os sistemas sociotécnicos estão
baseadas em Sommerville (2007). Para o autor, os sistemas sociotécnicos possuem
propriedades de comportamentos fortemente interligados, isso significa que:
O funcionamento com sucesso de cada componente depende do

funcionamento dos outros componentes. Dessa forma, o software
poderá operar somente se o processador estiver operacional. O
processador somente poderá realizar a computação se o sistema de
software que define essas funções tiver sido instalado com sucesso.
(SOMMERVILLE, 2007, p.15)
Uma característica no uso de sistema sociotécnicos é o fato de que as duas

partes, o social e o técnico, funcionam para produzir resultados positivos, desta forma,
é necessário um trabalho em conjunto na realização das tarefas de elaboração de
produtos físicos como resultados sociais.
O esquema da figura 3 apresenta uma visão geral em relação aos Sistemas
Sociotécnicos baseado nas ideias de Sommerville (2007).
13
Figura 3: Visão geral dos Sistemas Sociotécnicos
Fonte: Adaptado de Sommerville (2007, p. 14-27)
As associações realizadas na figura 3 mostram as interligações e propriedades

dos sistemas sociotécnicos, desde o projeto inicial até o fechamento das atividades
do projeto. A seguir serão detalhadas características sobre cada fase ilustrado na
figura 3.
As propriedades emergências podem ser classificadas como funcionais e não
funcionais. A primeira refere-se ao trabalho de todas as partes do sistema juntos
buscando o mesmo objetivo e a segunda “ao comportamento do sistema em seu
ambiente operacional” (SOMMERVILLE, 2007, p. 16). As propriedades emergentes são
difíceis de serem avaliadas, mas trazem para o projeto itens importantes na
construção e validação das atividades. São exemplos de propriedade emergentes:
usabilidade, confiabilidade, proteção, desempenho, volume e proteção.
A Engenharia de Sistemas envolve discussões na elaboração das atividades
de todo o projeto, tais como: especificação, implementação, validação,
implantação e manutenção dos sistemas.
14
Nesse ponto é importante diferenciar a engenharia de sistema de engenharia de
software, para Sommerville (2007, p. 6) a “engenharia de sistemas é uma disciplina mais
antiga que a engenharia de software”. Ao longo dos anos a pessoa tem realizado a
especificação de sistemas complexos, com a evolução da tecnologia o número de
softwares utilizados teve um expressivo aumento na produção de sistemas, dessa forma a
técnica de engenharia de software tem sido usada no processo de engenharia de
sistemas. O quadro 1 da seção 1.3 apresenta mais informações em relação as
características e diferenciações da engenharia de software e engenharia de sistemas.
Figura 4: Processo de Engenharia de Sistemas
Fonte: Adaptado de Sommerville (2007, p.17-23)
Na parte “social” do sistema referente à “organização, pessoas e sistemas de

computadores” as mudanças de processos e de trabalho aponta a necessidade de
se considerar o contexto no qual estão inseridos os usuários e o ambiente
organizacional onde será utilizado o software. Nesse ponto, é preciso um estudo do
perfil da organização interessada na elaboração do sistema, uma coleta de dados
sobre os processos organizacionais da empresa e dos usuários envolvidos no uso do
software. E, por último, a partir da coleta de dados, elaborar uma proposta de acordo
15
com as demandas do mercado.
Os sistemas desenvolvidos com base em softwares legado possuem hardware,
software, processos e procedimentos baseado em tecnologias mais antigas e
obsoletas. Os sistemas legados incluem processos de negócios, software de
aplicação, software de apoio e hardware de sistema. São “velhas formas de fazer
coisas que dificilmente são mudadas porque estão baseadas em software legado”.
(SOMMERVILLE, 2007, p.25). Os responsáveis pela empresa, associados a elaboração
de políticas e procedimentos organizacionais, na maioria dos casos não substituem
esse tipo de sistema por acreditarem que é grande o risco de perda de dados e
informações.
“Os sistemas sociotécnicos incluem hardware de computador, software e pessoas, e são

instalados dentro de uma organização. São projetados para auxiliar a organização a
atingir um grande objetivo” (SOMMERVILLE, 2007, p. 27). Ao pensarmos na montagem de
um ambiente com base na estrutura de sistema sociotécnicos, imaginamos um ambiente
com uma dimensão técnica, pessoal e organizacional. Dimensão técnica, quando nos
referimos a equipamentos físicos e virtuais, dimensão pessoal, quando a referência é de
pessoas de uma equipe de trabalho envolvida no projeto e dimensão organizacional,
quando pensamos na estrutura da organização onde o projeto será aplicado. Nesse
contexto, que elementos podemos citar da estrutura de um sistema sociotécnicos?
Nesse capítulo foram abordados alguns importantes conceitos e contextos

para o entendimento inicial sobre a área de Engenharia de Software. No próximo
capítulo será apresentado a Engenharia de Software no contexto dos dias atuais,
descrevendo sobre o trabalho, a legislação e o campo profissional do engenheiro de
software, bem como os desafios enfrentados no mercado de trabalho.
1.4 ENGENHARIA DE SOFTWARE NOS DIAS ATUAIS
Atualmente a engenharia de software tem se apresentado como uma área

de grande importância no início, durante e na finalização de projetos de software,
além de atuar também na manutenção. Essa importância se deve ao fato da equipe
realizar atividades de coleta de dados junto ao sujeito e organização, atuar no
16
processamento e análise de dados a partir de estratégias bem definidas, identificar
possíveis falhas no software e elaborar soluções para resolvê-las.
O quadro 1, mostra uma comparação entre as grandes áreas de formação
em relação à tecnologia atualmente, situando a Engenharia de Software no
contexto atual.
Quadro 1: Caracterização das áreas de conhecimento: Engenharia de Software, Engenharia

de Sistema, Ciências da Computação e Ciências da Informação
Engenharia de Engenharia Ciências da Ciências da
Software de Sistemas Computação Informação
Preocupa-se com os Refere-se aos aspectos Dedica-se as Refere-se à análise
problemas e soluções de desenvolvimento e teorias e aos da formação do
da prática da da evolução e sistemas métodos que processo desde a
produção de complexos. constituem a informação até a
softwares. base de transformação dos
computadores e dados em
sistemas de conhecimento.
softwares.
Tem relação direta Está relacionada com o Tem uma Está diretamente
com o desenvolvimento de relação direta relacionado com a
empreendedorismo e hardware, políticas e com o meio gestão da
o mercado de de processos de acadêmico e informação dentro
trabalho. Elaboração implantação dos científico como de empresas.
de um software a sistemas. um todo, devido
partir do estudo de a concentração
problemas. no estudo de
teorias.
Fonte: Elaborado pelo autor (2023)
As classificações exibidas no quadro 1, mostram que as grandes áreas de

conhecimento de tecnologia possuem relações entre si. Dessa forma, um bom
projeto de software precisa ter a atenção e os cuidados de todos os profissionais
envolvidos nas equipes.
Na engenharia de software, algumas mudanças importantes ocorreram nos
últimos anos, principalmente em relação à responsabilidade profissional e ética junto
ao mercado de trabalho. No ano de 2018, o órgão responsável pelas Entidades de
Fiscalização do Exercício das Profissões Liberais/Conselho Federal de Engenharia e
Agronomia, publicou a Resolução nº 1.100 de 24 de maio de 2018, a qual “Discrimina
as atividades e competências profissionais do engenheiro de software e insere o
respectivo título na Tabela de Títulos Profissionais do Sistema Confea/Crea, para efeito
de fiscalização do exercício profissional”. O decreto estabelece no seu artigo 2º que:
17
compete ao engenheiro de software as atribuições previstas no art. 7°
da Lei nº 5.194, de 1966, combinadas com as atividades 1 a 18 do art.
5º, §1º, da Resolução nº 1.073, de 19 de abril de 2016, referentes a
requisitos de software, sistemas e soluções de software, evolução de
software, integração local e remota de sistemas de software.
Para saber mais sobre as responsabilidades e ética do engenheiro de software, consulte:
1. Lei Nº 5.194, de 24 de dezembro de 1966. Regula o exercício das profissões de

Engenheiro, Arquiteto e Engenheiro-Agrônomo, e dá outras providências.
Fonte: https://abrir.link/dncaO. Acesso em: 20 jan. 2023.
2. Resolução nº 1.073, de 19 de abril de 2016. Regulamenta a atribuição de títulos,

atividades, competências e campos de atuação profissionais aos profissionais registrados
no Sistema Confea/Crea para efeito de fiscalização do exercício profissional no âmbito
da Engenharia e da Agronomia.
Fonte: Publicado no DOU – Diário Oficial da União em: 22/04/2016, Edição: 76, Seção: 1, Página: 245.
De acordo com os estudos da Associação Brasileira das Empresas de Software

– ABES, publicado no relatório anual do ano de 2021, o mercado de Hardware,
Software e Serviços no Brasil cresceram 22,9% com um investimento de cerca de R$
200,3 bilhões (US$ 50,7 bilhões). O mesmo estudo aponta que mais de 70% das
empresas no Brasil estão mais voltadas para a fabricação, desenvolvimento,
comercialização e distribuição de softwares.
Muitos desafios e responsabilidades se apresentam nos dias atuais para o
profissional de engenharia de software. Sommerville (2007) destaca que os principais
são: o desafio da heterogeneidade, da entrega e da confiança.
Para o autor no desafio da heterogeneidade é preciso que “os sistemas de
software operem como sistemas distribuídos, através das redes, que incluem
diferentes tipos de computadores, com diferentes tipos de sistema de apoio”
(SOMMERVILLE, 2007, p. 10).
No desafio da entrega, é preciso aliar o tempo com a qualidade, ou seja, o
software, “no ambiente de negócios de hoje deve apresentar resposta ágil e mudar
rapidamente” (SOMMERVILLE, 2007, p.10), o software de apoio precisa acompanhar
a velocidade das mudanças.
18
E o desafio da confiança, nesse ponto o autor reforça que é necessário
“desenvolver técnicas que demonstrem que o software pode ter a confiança dos
seus usuários” (SOMMERVILLE, 2007, p.10).
Em resumo, a unidade I, contextualizou a história e apresentou o conceito de
software e de engenharia de software. Foi descrito também a relação da engenharia
de software com etapas de desenvolvimento e produção de um projeto de software.
No final da unidade foi apresentado um pouco sobre a profissionalização do
engenheiro de software, descrevendo a legislação que regulamentou a profissão e
desafios nos dias atuais da área de engenharia de software.
A seguir são propostas algumas questões sobre o conteúdo da unidade 01.
19
FIXANDO O CONTEÚDO
1. A engenharia de sistemas está diretamente relacionada à execução e atividades

de todo o projeto. Sobre esse assunto analise as proposições abaixo:
I. Definição de requisitos: indicam que o sistema já pode ser iniciado, sendo liberado
para colocar em funcionamento.
II. Integração do Sistema: refere-se ao grupamento dos subsistemas para a
construção do sistema completo.
III. Evolução do sistema: relaciona-se ao período destinado a correção de erros dos
requisitos e projetos de novas implementações.
IV. Projeto de sistema: nessa parte da engenharia de sistemas a funcionalidade será
fornecida pelos componentes do sistema.
Estão corretas:
a) I, II, III, IV.
b) I, III, IV.
c) II, III, IV.
d) II e III.
e) III e IV.
2. “Os relacionamentos complexos entre os componentes de um sistema mostram

que o sistema é mais do que simplesmente a soma de suas partes. Ele possui
propriedades próprias do sistema como um todo” (SOMMERVILLE, 2007, p. 16).
São exemplos de propriedades emergentes de um sistema:
I. Complexidade.
II. Usabilidade.
III. Proteção.
IV. Contextualidade.
V. Volume.
Estão corretas:
a) I, II, III, IV e V.
b) I, III, IV e V.
c) II, III, IV e V.
d) II, III e V.
e) III e V.
20
3. A Resolução nº 1.100 de 24 de maio de 2018 indica em seu texto que as atribuições
do engenheiro de software estão previstas no art. 7° da Lei nº 5.194, de 1966. De
acordo com essa informação, analise as proposições abaixo:
I. Estudos, projetos, análises, avaliações, vistorias, perícias, pareceres E divulgação
técnica;
II. Contração de pessoal para composição da equipe de projeto;
III. Fiscalização de obras e serviços técnicos;
IV. Direção de obras e serviços técnicos;
V. Execução de obras e serviços técnicos.
São atribuições do engenheiro de software:
b) I, III, IV e V.
c) II, III, IV e V.
d) II, III e IV.
e) III e V.
4. “A engenharia de software é uma disciplina de engenharia relacionada com todos

os aspectos da produção de software, desde os estágios iniciais de especificação do
sistema até sua manutenção, depois que este entrar em operação” (SOMMERVILLE,
2007, p.5).
Sobre o conceito e a importância do processo de engenharia de software analise as
proposições abaixo:
I. É preciso antes de projetar qualquer informação sobre o sistema criar ações práticas
de elaboração do software.
II. Um ponto chave no processo de engenharia de software é entender o problema
antes de elaborar uma solução.
III. Um projeto bem feito terá como resultados: qualidade e facilidade de manutenção
do software.
IV. A engenharia de software engloba um processo, métodos de gerenciamento e
desenvolvimento de software, bem como ferramentas.
Estão corretas:
a) I, II, III e IV.
b) I e IV.
c) III e IV.
21
d) II e III.
e) II, III e IV.
5. (FUNIVERSA - 2009 - Adaptado) Assim como a Engenharia de Software, existe

também na área de informática a chamada Ciência da Computação e a
Engenharia de Sistemas. Assinale a alternativa que melhor apresenta a diferença
entre Engenharia de Software, Ciência da Computação e Engenharia de Sistemas.
a) A Ciência da Computação tem como objetivo o desenvolvimento de teorias e
fundamentações. A Engenharia de Software se preocupa com as práticas de
desenvolvimento de software. Já a engenharia de sistema está relacionada com
políticas e processos de implantação dos sistemas.
b) A Engenharia de Software trata da criação dos sistemas de computação
(softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento
e criação de componentes de hardware, a Engenharia de Sistemas com a
manutenção do sistema.
c) A Engenharia de Software e a Engenharia de Sistema tratam dos sistemas com
base em computadores, que inclui hardware e software, e a Ciência da
Computação trata apenas dos aspectos de desenvolvimento de sistemas.
d) A Ciência da Computação e a Engenharia de Sistema tratam dos sistemas com
base em computadores, que inclui hardware e software, e a Engenharia de
Software trata apenas dos aspectos de desenvolvimento de sistemas.
e) A Ciência da Computação destina-se ao estudo e solução para problemas
genéricos das áreas de rede e banco de dados e a Engenharia de Software e a
Engenharia de Sistema restringem-se ao desenvolvimento de sistemas.
6. Observe os trechos abaixo:

“Toda a programação era feita em linguagem de máquina pura, frequentemente
interligando fios através de painéis de conectores para controlar as funções básicas
da máquina” (TANENBAUM e WOODHULL, 2008).
O texto refere-se à:
a) A primeira geração de computadores
b) A geração de computadores dos circuitos integrados
c) A geração de computadores que enfatizam o processamento em tempo real
d) A quarta geração de computadores
22
e) A geração de computadores dos sistemas operacionais avançados.
7. Sobre o conceito de software, analise as proposições abaixo:

I. Os arquivos de configuração mostram no projeto como configurar o sistema
planejado;
II. A documentação do sistema refere-se às descrições da estrutura do sistema;
III. Softwares disponíveis na web são fontes de coletas de informações pelos usuários;
IV. Um projeto de software pode ser definido apenas como sendo programas de
computadores.
Estão corretas:
a) I, II, III.
b) I e III.
c) II, III, IV.
d) II e III.
e) III e IV.
8. (IPSEM– 2010) A evolução dos computadores foi caracterizada por avanços

tecnológicos que marcaram cada geração. Sobre os avanços tecnológicos e suas
respectivas gerações, é correto afirmar que:
a) Na primeira geração a tecnologia dos circuitos integrados permitiu a substituição
de centenas de componentes por uma única pastilha de silício.
b) Na segunda geração nasceu o conceito de família de computadores compatíveis
que permitiu a migração de sistemas para computadores mais potentes.
c) Na terceira geração, os computadores eram baseados no uso de relés e válvulas
permitindo a miniaturização.
d) Na primeira geração a forma dominante de armazenamento secundário foi
implementado através de fitas magnéticas que permitiam uma maior capacidade
e velocidade.
e) Na terceira geração apareceram os discos magnéticos para o armazenamento
de dados possibilitando uma maior velocidade já que permitia acesso direto aos
arquivos.
23
CONCEITOS E MODELOS DE UNIDADE
PROCESSO DE SOFTWARE
2.1 MODELOS DE PROCESSOS DE SOFTWARES

02
Vimos na unidade I, conceitos, caracterização e uma contextualização do
termo software, e de engenharia de software. Na unidade II, serão abordadas as
relações da engenharia de software e as fases na construção do projeto de software.
Essas fases consistem na apresentação de modelos de processos, do ciclo de vida e
de atividades de processos software.
O termo processo é definido por Pfleeger (2004 p.36), como sendo um
“conjunto de tarefas ordenadas (...) uma série de etapas que envolvem atividades,
restrições e recursos para alcançar a saída desejada”.
A figura 6 ilustra algumas características de um processo segundo Pfleeger
(2004).
Figura 6: Características de um processo
Fonte: Adaptado de Pfleeger (2004, p. 36-37).
24
Em relação aos processos de software, para Sommerville (2007, p. 42), “os
processos de software são complexos e, como todos os processos intelectuais e
criativos, dependem de julgamento humano”. Apesar das muitas tentativas do uso
de ferramentas para a automatização dos processos de software, os resultados são
bastante limitados, isso por causa dos fatores relacionados à decisão nos projetos, ou
seja, o uso do julgamento e da criatividade.
Pressman (2011, p. 40) descreve que no contexto da engenharia de software,
podemos dizer que o processo de desenvolvimento de software não é um processo
fixo, rígido, estático, “ao contrário, é uma abordagem adaptável que possibilita às
pessoas (a equipe de software) realizar o trabalho de selecionar e escolher o conjunto
apropriado de ações e tarefas”.
Existem vários tipos de processos de software, desta forma, um bom
entendimento sobre o funcionamento desses processos auxilia na elaboração dos
projetos. Existem algumas atividades que são comuns aos diversos tipos de processo,
assim, é importante entende-las para uma melhor escolha do tipo que será
selecionado para executar o projeto. Isso porque, confirma afirma Pfleeger (2004),
“A estrutura do processo orienta nossas ações, permitindo-nos examinar, entender,
controlar e aprimorar as atividades que compõem” (p.37), ou seja, é fundamental
que o processo esteja alinhado a metodologia proposta no projeto de software. A
figura 7 ilustra as atividades comuns no processo de software.
25
Figura 7: Atividades fundamentais e comuns no processo de software
Fonte: Adaptado de Sommerville (2007, p.43)
A figura 7 permite concluir que seja qual for o processo escolhido para compor
o projeto de software, é necessário um processo que contenha a especificação,
implementação, validação e evolução (manutenção) do projeto de software. As
seções 2.2 e 2.3 dessa unidade descrevem conceitos e caracterizam os
processos/ciclos de vida de um software.
Para saber mais sobre o processo de software sugerimos a leitura do capítulo 4 do livro
Engenharia de Software do autor Ian Sommerville (2007), páginas 42-49. O livro está
disponível na Biblioteca Virtual: https://abrir.link/slcpS. Acesso em: 20 jan. 2023.
2.2 CICLOS DE VIDA DE UM SOFTWARE
O ciclo de vida de um software é citado na literatura com diferentes

denominações, dependendo da abordagem do autor.
Nessa seção do livro serão abordados modelos de processo de software
conforme o quadro 2, conforme pressupostos de Sommerville (2007).
26
Quadro 2: Modelos de Processos de Software
Modelo em Prototipação Engenharia de Entrega Desenvolvimento
Cascata Software Incremental Espiral
Baseada em
Componentes
Especificação, Tem o Essa abordagem A especificação, O
desenvolvimento, objetivo de é baseada na o projeto e a desenvolvimento
validação e mostrar ao existência de um implementação do sistema evolui
evolução (Fases usuário, antes número de software são em espiral para
de processos da entrega significativo de divididos em uma fora a partir de
separados). do produto componentes série de um esboço inicial
final, um reusáveis. incrementos até o sistema
protótipo do desenvolvidos final.
sistema. um de cada vez.
RUP – Ration Modelo híbrido de processo. Traz elementos de todos os modelos de

Unified Process processo indicados nas colunas 1 a 5 desse quadro.
Fonte: Adaptado de Sommerville (2007).
Uma organização de posse das ferramentas tecnológicas de processo disponíveis pode

construir um modelo automatizado das tarefas, atividades e da metodologia de
processos. Ao analisarmos as informações do quadro 2, podemos afirmar que existe um
modelo único de processo para a elaboração desses projetos?
A seguir serão descritos com mais detalhes os modelos de processo de

software apresentados no quadro 2.
2.2.1 Modelo em Cascata
No modelo em Cascata, também conhecido como ciclo de vida clássico, na

medida em que se executa o projeto, as informações são trocadas entre as fases e
os problemas identificados são discutidos durante as fases do projeto.
A figura 8 ilustra o modelo em cascata, observe que o modelo tem a
característica de não linearidade.
27
Figura 8: Modelo de processo de software em Cascata
Fonte: Adaptado de Pressman (2011, p. 60).
Dentre as vantagens desse tipo de modelo podemos citar a produção de

documentos em cada fase e seu uso em outros modelos de projeto. A Desvantagem
refere-se à inflexibilidade das fases do projeto, ou seja, há resistência no projeto em
relação a mudanças de requisitos do usuário, dessa forma os requisitos precisam estar
bem definidos no projeto.
2.2.2 Prototipação
O modelo de prototipação apresenta inicialmente um produto ao usuário em

forma de protótipo, e somente depois da aprovação do cliente, o desenvolvimento
do software é iniciado. O usuário terá acesso ao protótipo, por meio de um sistema
já existente (sem todas as funcionalidades) ou por meio de aparências das janelas,
consultas, relatórios, sem funcionalidade, ou através do uso do papel, onde é
realizado um rascunho das interações com o sistema que será planejado.
A figura 9 ilustra o modelo processo de prototipação.
28
Figura 9: O modelo da prototipação
Fonte: Adaptado de Pfleeger (2004. p. 43).
O processo de prototipação pode ser usado como modelo principal no

desenvolvimento do software. Algumas práticas indicam que seu uso é mais comum
como técnica implantada junto com os outros processos de software. De acordo
com Pressman (2011) “quando os requisitos estão obscuros, o paradigma da
prototipação auxilia os interessados a compreender melhor o que está para ser
construído”. O autor completa:
O projeto rápido leva à construção de um protótipo, que é

empregado e avaliado pelos envolvidos, que fornecerão um retorno
(feedback), que servirá para aprimorar os requisitos. A iteração ocorre
conforme se ajusta o protótipo às necessidades de vários interessados
e, ao mesmo tempo, possibilita a melhor compreensão das
necessidades que devem ser atendidas (PRESSMAN, 2011, p. 64).
É importante nesse processo considerar o fator relacionado à ansiedade do

cliente, pois ao ter contato com o protótipo são geradas expectativas, o que pode
influenciar na entrega final do produto.
2.2.3 Modelo de desenvolvimento Baseado em Componentes
A característica principal desse processo é o reuso de softwares. A definição

de reuso no dicionário Priberam (2008), refere-se ao “ato ou efeito de reusar”, e a
29
palavra reusar, significa, “utilizar novamente”. Dessa forma podemos dizer que o
processo de Engenharia de Software Baseado em componentes utiliza-se de vários
softwares para a elaboração de outro software. Esse modelo de processo, “depende
de uma grande base de componentes de softwares reusáveis e algum framework de
integração desses componentes”. (SOMMERVILLE, 2007, p. 46)
De acordo com Pressman (2011, p. 69) o modelo baseado em componentes
possui as seguintes etapas no seu desenvolvimento:
1. Produtos baseados em componentes disponíveis são pesquisados e

avaliados para o campo de aplicação em questão. 2. Itens de
integração de componentes são considerados. 3. Uma arquitetura de
software é projetada para acomodar os componentes. 4. Os
componentes são integrados na arquitetura. 5. Testes completos são
realizados para assegurar funcionalidade adequada.
A figura 11 ilustra as etapas e atividades do modelo de processo baseado em

componentes.
Figura 11: Processo de desenvolvimento de Engenharia de Software Baseada em

Componentes
Fonte: Adaptado de Sommerville, (2007, p. 46)
A redução de custos e riscos é uma das vantagens desse modelo, isso porque
reduz a quantidade de software a ser produzido. A desvantagem é que o
desenvolvimento baseado em uma entrega mais rápida compromete a descrição
dos requisitos, e consequentemente a possibilidade da entrega de um software que
não atenda às necessidades reais dos usuários.
30
2.2.4 Entrega Incremental
Nos projetos de construção de softwares de grande porte há muitas pressões

internas para a mudança de requisitos, dessa forma, são necessárias alterações na
forma de gerenciamento. “A essência dos processos iterativos é que a especificação
é desenvolvida conjuntamente com o software”. No modelo incremental, “A
especificação, o projeto e a implementação de software são divididos em uma série
de incrementos desenvolvidos um de cada vez (...) o cliente identifica, em linhas
gerais, os serviços a serem fornecidos pelo sistema” SOMMERVILLE, 2007, p.47).
A Entrega Incremental combina as vantagens dos modelos evolucionárias e
modelo em cascata, conforme ilustra a figura 12.
Figura 12: Entrega Incremental – Processo de Software
Fonte: Adaptado de Sommerville, (2007, P. 46)
Observe na figura 12 que a partir do desenvolvimento do incremento do

sistema, há uma forte iteração entre as atividades e fases do processo. No final ao
validar um incremento, há um loop e a atividade se reinicia no desenvolvimento de
outro incremento.
A seguir, no quadro 3 são apresentados as vantagens e desvantagens da
Entrega Incremental.
Quadro 3: Vantagens e desvantagens da entrega incremental

Vantagens Desvantagens
 Os clientes não precisam esperar até a  Os incrementos devem ser relativamente

entrega do sistema inteiro. pequenos e cada um deve entregar uma
 Os clientes podem utilizar os funcionalidade do sistema.
incrementos iniciais como protótipos e  Dificuldade no mapeamento dos requisitos
utiliza-lo como experiência para os dos clientes em incrementos de tamanho
31
outros incrementos. adequado.
 Existe um risco menor de falha geral do  A maior parte dos sistemas requer um
projeto, principalmente nas partes mais conjunto de recursos básicos usados por
importantes do sistema. diferentes partes do sistema.
 Dificuldades na identificação dos recursos
comuns exigidos por todos os incrementos.
Fonte: Adaptado de Sommerville (2007, p. 48).
2.2.5 Modelo Espiral
No modelo espiral “o desenvolvimento do sistema evolui em espiral para fora

a partir de um esboço inicial até o sistema final” (SOMMERVILLE, 2007, p. 47). O
desenvolvimento Espiral apresenta quatro atividades importantes: planejamento,
análise de riscos, engenharia e avaliação do cliente.
De forma resumida, conforme Sommerville (2007), no planejamento ocorrem
discussões importantes, tais como a determinação dos objetivos, alternativas e
restrições. Na análise de riscos ocorre a identificação e resolução dos riscos. Na
engenharia há o desenvolvimento do produto. E por último, na avaliação do cliente,
é realizada uma avalição dos resultados da engenharia.
Um dos pontos principais do modelo espiral e o que diferencia esse modelo
dos demais modelos é a questão da análise do risco, ou seja, “o que pode dar
errado”. Na figura 13, podemos observar a relevância dada a atividade de análise
de riscos se comparado com as outras atividades do modelo.
32
Figura 13: Modelo em espiral do processo de software
Fonte: Adaptado Pfleeger (2004, p.47).
As vantagens do modelo espiral são significativas quando comparadas com

os outros modelos de software. Uma dessas vantagens é que, as interações iniciais
possuem um baixo custo, e são as que resolvem o maior número de problemas,
devido à análise de riscos do modelo. A desvantagem é a exigência do modelo em
relação à competência da avaliação de riscos para que o projeto tenha bons
resultados; outro problema e o fato do modelo não fornecer indicação da
quantidade de trabalho em cada ciclo, o que acarreta um aumento de problemas
para gerência do projeto.
O Rational Unified Process – RUP, idealizado durante o início dos anos 1990, por James
Rumbaugh, Grady Booch e Ivar Jacobson é um bom exemplo de modelo híbrido de
processo, ele traz elementos dos modelos iterativos, em cascata, baseado em
componentes, evolucionário e a prototipação, a partir de uma perspectiva dinâmica,
(mostra as fases do modelo) estática (Mostra as atividades realizadas) e prática (sugere
boas práticas a serem realizadas).
33
Para entender um pouco mais sobre o RUP, leia as páginas 54 a 56 do livro Engenharia de
software do autor Ian Sommerville. O livro está disponível na biblioteca virtual:
https://abrir.link/slcpS. Acesso em: 20 jan. 2023.
2.3 ATIVIDADES DE PROCESSO DE SOFTWARE
É importante ressaltar inicialmente que as atividades do processo de software,

conforme descreve Sommerville (2007, p. 49), “são organizadas de modo diferente
nos diversos processos de desenvolvimento”. São relatadas no quadro 5 um resumo
das quatros atividades básicas do processo de software, segundo o autor.
Quadro 5: Atividades de processo de software

Atividades Descrição
Especificação de softwareProcesso para compreender e definir quais serviços são
necessários e identificar as restrições de operação e de
desenvolvimento do sistema.
Projeto e implementação Processo de conversão de uma especificação de sistema em
de software um sistema executável.
Validação de software O Objetivo é mostrar que um sistema está em conformidade
com sua especificação e que atende às expectativas do
cliente que está adquirindo o sistema.
Evolução do software Mudanças podem ser feitas no software a qualquer instante,
durante ou após o desenvolvimento do sistema.
Fonte: Adaptado de Sommerville (2007)
A seguir são descritos com mais detalhes as atividades de processo de

software ilustradas no quadro 5.
2.3.1 Especificação de software
O processo de especificação de software é também denominado Engenharia

de Requisitos. Na unidade 4, trataremos mais específico sobre os processos que
envolvem os requisitos de um sistema. No geral, de acordo com Pressman (2011,
p.129) uma:
especificação de requisitos de software (software requirements specifi
cation, SrS) é um documento criado quando uma descrição
detalhada de todos os aspectos do software a ser construído deve ser
especificada antes de o projeto começar.
34
O produto final, portanto, do processo de especificação de software é
denominado documento de requisito e aborda o conteúdo sobre a especificação
do sistema. O modelo está ilustrado na figura 14.
Figura 14: Modelo de especificação de requisitos de software
Fonte: Pressman (2011, p.129)
As quatro principais fases da especificação de um software são: estudo de

viabilidade, elicitação e análise de requisitos, especificação de requisitos e a
validação de requisitos. Todas essas fases serão descritas com mais detalhes na
unidade 4 desse livro.
2.3.2 Implementação de software
O objetivo da atividade que envolve o projeto e a sua implementação é a

transformação da teoria (projeto do sistema) em prática (sistema executável). A
figura 14 ilustra com detalhamento o processo de implementação de um projeto de
software.
35
Figura 14: Processo de especificação de um software
Fonte: Adaptado de Sommerville, (2007, p. 47).
A figura 14 mostra as relações das atividades e produtos dos projetos, na

atividade de elaboração do projeto e implementação de software. “A saída de
cada atividade de projeto é uma especificação para o próximo estágio. [...] Os
resultados finais do processo são especificações precisas de algoritmo e estruturas de
dados a serem implementados” (SOMMERVILLE, 2007, p. 51).
2.3.3 Validação de software
O processo de validação de um software está diretamente relacionado com

as verificações do sistema e a conformidade com as solicitações feitas pelo cliente
que realizou a contratação. A ideia básica da validação do software é a partir da
localização do erro, elaborar e aplicar o projeto de reparo desse erro, visando o
acerto dos problemas encontrados.
Nesse sentido são realizados três estágios de testes: teste no componente, teste
no sistema e o teste na aceitação, conforme ilustrado na figura 15.
36
Figura 15: Processo de Validação de Software
A Figura 15 ilustra as fases de teste no processo de software. Acompanhando

o fluxo da seta, primeiramente testam-se os componentes individuais, na sequência
a integração dos componentes e por último é realizado, uma simulação, um teste
com dados fornecidos pelo cliente. Observe que caso haja uma necessidade de se
retornar a uma fase de teste isso é possível, ou seja, se o projeto encontra-se na fase
de teste do sistema e há demanda para se testar novamente um componente, o
processo poderá ser realizado.
Complementando as informações da figura 15, a figura 16 mostra o fluxo para
reparo do erro em um sistema de software.
Figura 16: Fluxo para reparo do erro no processo de software (Debugging)
Na figura 16 observa-se que após a detecção do erro (processo de

debugging), inicia-se o processo de verificação do erro e em seguida os
procedimentos para o reparo. No final uma reavaliação do programa é realizada
finalizando o processo.
37
2.3.4 Evolução (manutenção) de software
Evolução significa transformar algo ao longo de um determinado período.

Historicamente as preocupações com o processo de manutenção de um software
sempre ficaram em um plano inferior, a preocupação sempre está centrada no
desenvolvimento do sistema. Para Sommerville (2007, p. 54) apesar de historicamente
da manutenção de um software ser considerada menos desafiador do que o
desenvolvimento é preciso:
considerar o desenvolvimento e a manutenção de forma contínua.
Em vez de dois processos separados, é mais realista pensar na
engenharia de software como um processo evolutivo, no qual o
software e continuamente alterado ao longo de sua vida, em
respostas a mudanças de requisitos e as necessidades do cliente.
38
Manutenção de software
As alterações feitas no software podem ser simples mudanças para correção de erros de
codificação, até mudanças mais extensas para correção de erros de projeto, ou
melhorias significativas para corrigir erros de especificação ou acomodar novos requisitos.
As mudanças são implementadas por meio da modificação de componentes do sistema
existente e, quando necessário, por meio da adição de novos componentes
(SOMMERVILLE, 2007, p. 327).
Gráfico 1: Distribuição de esforço de manutenção

Gráfico 2: Custo de desenvolvimento e manutenção
Fonte: Sommerville (2007, p.327)
Analisando os dados dos gráficos 1 e 2 podemos retirar algumas conclusões sobre o

processo de desenvolvimento e manutenção do projeto de software. Dessa forma, ao
separarmos de um projeto de software a etapa da manutenção da etapa do
desenvolvimento, qual o maior risco que podemos correr? O prejuízo será maior ou menor?
É mais fácil trabalhar com o erro no decorrer do processo ou entregar o produto e esperar
que os erros se acumulem para resolver todos de uma só vez?
Por meio do estudo da unidade 2, foi possível perceber conceitos e relações

importantes do termo processo e dos modelos propostos de processos de software.
Foi possível também estudar os ciclos de vida de software e entender o
funcionamento de cada ciclo no contexto do desenvolvimento dos projetos de
software. Vimos, também, as quatro principais atividades do processo de software,
seus fundamentos e conceitos. Na unidade 3, estudaremos de forma introdutória o
gerenciamento de projetos.
39
A engenharia de software auxiliada por computador – CASE (Computer-Aided Sofware
Enginnering) refere-se aos softwares utilizados para dar apoio às atividades do projeto de
software, a partir da automação de algumas atividades referente ao processo.
Para saber mais sobre ferramenta CASE, sugerimos a leitura do título: “Engenharia de
software auxiliada por computador” páginas 56 e 57 do livro engenharia de software de
Ian Sommerville. O livro está disponível na biblioteca virtual: https://abrir.link/slcpS. Acesso
em: 20 jan. 2023.
40
FIXANDO O CONTEÚDO
1. Analise as proposições abaixo referentes às características de um processo:

I. Restrições e controles só podem ser aplicados a uma atividade do processo;
II. Os processos possuem um conjunto de diretrizes que explicam os objetivos de todas
as atividades;
III. Cada atividade do processo tem critérios de entrada e saída, de modo que seja
possível saber quando o processo começa e termina;
IV. Nos processos é importante atribuir critérios de entrada e saída para cada
atividade, o objetivo é saber quando um processo começa e termina.
Estão corretos:
a) I, II, III e IV.
b) I, II e III.
c) II, III e IV.
d) II e IV.
e) III e IV.
2. Observe a imagem e analise as proposições:
Fonte: Pressman, (2011, p. 60)
I. Em 5, as atividades principais desenvolvidas e a entrega do produto e a

realização dos feedbacks.
II. Em 3, o objetivo é realizar a previsão das atividades a partir da elaboração do
cronograma e realizar o acompanhamento das atividades.
III. O modelo de processo de software apresentado na figura é o modelo em
prototipação, considerado o paradigma mais antigo da engenharia de
software.
IV. Na fase 1 da figura o objetivo é que sejam definidos todas as necessidades,
um ponto criticado atualmente no modelo, tendo em vista que é difícil para o
cliente estabelecer explicitamente todas as necessidades.
V. O modelo apresentado na figura sugere uma abordagem sequencial e
41
sistemática para o desenvolvimento de software.
Estão corretas:
a) I, IV e V.
b) I, II, III e V.
c) I, III, IV e V.
d) II, IV e V.
e) II, III e IV.
3. (IFMS-2016) O Modelo de Processo de Software em Espiral (Boehm) é caracterizado

por não representar o processo de software como uma sequência de atividades com
algum retorno entre uma atividade e outra, mas sim, como uma espiral. Cada loop,
na espiral, representa uma fase do processo de software que é dividido em quatro
setores. Cronologicamente, os setores estão organizados como:
a) análise de negócio; avaliação e redução de riscos; desenvolvimento e validação;
planejamento.
b) planejamento; definição de objetivos; avaliação e redução de riscos;
desenvolvimento e validação.
c) definição de objetivos; avaliação e redução de riscos; desenvolvimento e
validação; planejamento da próxima fase.
d) planejamento; análise de negócio; avaliação e redução de riscos;
desenvolvimento e validação.
e) planejamento; análise de negócio; definição de objetivos; desenvolvimento.
4. Em relação ao ciclo de vida de um software, associe as duas colunas a seguir:

I. Modelo Espiral (A) Sugere uma abordagem sequencial e sistemática para o
desenvolvimento de software, começando com o
levantamento de necessidades por parte do cliente.
II. Modelo em Cascata (B) Cada loop representa uma fase de processo do software.
III. Engenharia baseada (C) O cliente define uma série de objetivos gerais para o
em componentes software, mas não identifica, detalhadamente, os requisitos
para funções e recursos.
IV.Entrega incremental (D) Baseia-se em componentes reusáveis.
V. Prototipação (E) Intercala atividades de especificação, desenvolvimento e
validação.
A sequência CORRETA é:
a) I-E, II-A, III-C, IV-B, V-D.
b) I-B, II-A, III-E, IV-C, V-D.
42
c) I-B, II-A, III-D, IV-E, V-C.
d) I-E, II-B, III-D, IV-B, V-C.
e) I-A, II-B, III-E, IV-D, V-C.
5. As proposições abaixo se referem às atividades de processo de software. Analise-

as para responder a questão:
I. O documento de requisito é considerado o documento que inicia as atividades
de especificação de software.
II. Na atividade de implementação de software, a discussão entre o que foi escrito
no projeto e o que está sendo aplicado é uma das principais características.
III. No processo de validação de um software, antes de reparar o erro, a equipe
realiza o teste de componentes, integração e simulação.
Está (ão) correta (s):
a) I, II e III.
b) I e II.
c) Somente II.
d) Somente III.
e) II e III.
6. Observe o trecho: “Trabalhos posteriores propuseram métodos para a tradução de

fluxos de dados ou da estrutura de dados em uma definição de projeto. Abordagens
de projeto mais recentes propuseram uma abordagem orientada a objetos para a
derivação do projeto. Atualmente, a ênfase em projeto de software tem sido na
arquitetura de software e nos padrões de projeto que podem ser utilizados para
implementar arquiteturas de software e níveis de abstração de projeto mais baixos”.
(PRESSMAN, 2011, p. 211)
O trecho acima se refere à atividade do projeto de software:
a) Evolução de software.
b) RPU.
c) Validação de software.
d) Projeto de implementação de software.
e) Análise de requisitos.
43
7. Observe o recorte da imagem:
Fonte: (Pfleeger, 2004, P. 89)
A etapa anterior a “Codificação” e posterior “Teste do sistema” são:
a) Projeto do programa e Teste de Aceitação

b) Projeto de programa e Operação e Manutenção
c) Projeto de Sistema e Teste de Aceitação
d) Projeto de Sistema e Manutenção
e) Definição de Requisitos e Manutenção
8. “Originalmente proposto por Barry Boehm [Boe88], o modelo espiral é um modelo

de processo de software evolucionário que acopla a natureza iterativa da
prototipação com os aspectos sistemáticos e controlados da modelo cascata”
(PRESSMAN, 2011, p. 65).
Sobre o modelo espiral analise as proposições abaixo:
I. Um dos principais pontos do modelo espiral, é que o modelo parte do princípio que
a forma de desenvolvimento do software precisa ser completamente determinada
de antemão.
II. Um dos ciclos no modelo espiral refere-se a avaliar alternativas com relação aos
objetivos e restrições, e identificar as principais fontes de riscos.
III. No modelo espiral, a estratégia para se descobrir os problemas é a prototipação,
que é vista como um meio de redução de riscos.
IV. Na etapa de planejamento da próxima fase, configura-se uma atividade
preventiva, tendo em vista que o projeto poderá ser abortado se apresentar um alto
fator de risco.
44
Estão corretas:
a) I, II e IV.
b) I, II e III.
c) I e IV.
d) II, III e IV.
e) II, III e IV.
45
INTRODUÇÃO AO UNIDADE
GERENCIAMENTO DE PROJETOS
3.1 VISÃO GERAL E CONCEITOS DO GERENCIAMENTO DE PROJETOS

03
De acordo com o guia PMBOK - Guide to the Project Management Body of
Knowledge ou Guia para o Conjunto de Conhecimentos de Gerenciamento de
Projetos (2017, p.4), podemos definir projeto como sendo: “um esforço temporário
empreendido para criar um produto, serviço ou resultado único. Projetos são
realizados para cumprir objetivos através da produção de entregas”. Conforme
consta no guia é possível à produção de uma ou mais entregas de:
um produto único que pode ser um componente de outro item, um

aprimoramento ou correção de um item ou um novo item final (...) um
serviço único ou uma capacidade de realizar um serviço (...) um
resultado único, como um produto ou documento; (...) e uma
combinação única de um ou mais produtos, serviços ou resultados.
(p.4)
A definição e a caracterização do termo projeto têm como objetivo ajudar na

elucidação do contexto de um estudo inicial sobre o gerenciamento de projetos. A
figura 17 apresenta algumas características importantes sobre projetos.
46
Figura 17: Contexto de iniciação do projeto
Fonte: Adaptado de Guia PMBOK (2017, p. 08)
Em relação ao gerenciamento de projetos, o guia PMBOK (2017, p. 10) define

como sendo “a aplicação de conhecimentos, habilidades, ferramentas e técnicas
às atividades do projeto a fim de cumprir os seus requisitos”.
O gerenciamento de um projeto pode ser considerado como bom ou ruim,
dependendo de vários fatores, seja eles internos ou externos. Para ajudar na
compreensão desses fatores, é descrito no quadro 6, uma visão geral de
características de gerenciamento de projetos considerados eficazes e mal
gerenciados ou a ausência do gerenciamento.
Quadro 6: Visão geral sobre a concepção de projetos

Gerenciamento de projetos eficazes Projetos mal gerenciados ou ausência de
gerenciamento
 Cumprirem os objetivos do negócio;  Prazos perdidos;
 Satisfazerem as expectativas das partes  Estouros de orçamento;
interessadas;  Má qualidade;
 Serem mais previsíveis;  Retrabalho;
 Aumentarem suas chances de sucesso;  Expansão descontrolada do projeto;
 Entregarem os produtos certos no  Perda de reputação para a organização;
momento certo;  Partes interessadas insatisfeitas; e
 Resolverem problemas e questões;  Incapacidade de alcançar os objetivos
 Responderem a riscos em tempo hábil; para os quais o projeto foi empreendido
 Otimizarem o uso dos recursos
organizacionais;
 Identificarem, recuperarem ou
47
Gerenciamento de projetos eficazes Projetos mal gerenciados ou ausência de
gerenciamento
eliminarem projetos com problemas;
 Gerenciarem restrições
 Equilibrarem a influência de restrições do
projeto e
 Gerenciarem melhor as mudanças
Fonte: Guia PMBOK, (2017, p. 10).
Para saber um pouco mais sobre as concepções de projetos e sistemas, sugerimos a

leitura da unidade I, “Aqui começa o projeto”, do livro: “Gestão de projetos” do autor
Fabio Câmara Araújo de Carvalho, páginas 1 a 18. O livro está disponível na biblioteca
virtual: https://abrir.link/AYI52. Acesso em: 20 jan. 2023.
De um modo geral o gerenciamento de projetos é agrupado em cinco

grandes grupos de processos: iniciação, planejamento, execução, monitoramento e
controle e encerramento (PMBOK, 2017, p.21)
 A iniciação é responsável pela definição e autorização de todo ou fase do
projeto,
 No planejamento trabalha-se com a definição e ações necessárias para
viabilização dos objetivos.
 Na execução realiza-se a integração das pessoas e recursos envolvidos para
o plano de gerenciamento do projeto, além de concluir o trabalho definido
no plano de gerenciamento do projeto com o objetivo de satisfazer os
requisitos do projeto.
 O grupo de monitoramento e controle é responsável pela medição constante
do processo, com o objetivo de identificar as variações em relação ao plano
de gerenciamento do projeto para o início das mudanças correspondentes.
 No encerramento é formalizada a aceitação do produto, serviço ou resultado.
Outro ponto do gerenciamento de projetos refere-se à equipe de trabalho, ou
seja, o gerenciamento das partes interessadas dos projetos. A figura 18 apresenta um
breve resumo das fases que envolvem esse gerenciamento.
48
Figura 18: Os processos de gerenciamento das partes interessadas do projeto são:
Fonte: Adaptada do guia PMBOK (2017, p. 503).
O gerenciamento das partes interessadas do projeto, em geral pode ser

resumida de acordo com o guia PMBOK, (2017):
inclui os processos exigidos para identificar todas as pessoas, grupos

ou organizações que podem impactar ou serem impactados pelo
projeto, analisar as expectativas das partes interessadas, seu impacto
no projeto e desenvolver estratégias de gerenciamento apropriadas
para o engajamento eficaz das partes interessadas nas decisões e na
execução do projeto. (p.503)
O conceito abordado nessa seção teve como objetivo descrever uma visão
geral do termo projeto e do gerenciamento de projeto. No próximo capítulo será
abordada uma visão geral das etapas específicas do gerenciamento de projeto de
software.
3.2 ATIVIDADES, PLANEJAMENTO E CRONOGRAMA DE PROJETOS DE

SOFTWARES
O gerenciamento de projetos de software é “parte essencial da engenharia

de software” (SOMMERVILLE 2007, p.61). Como foi abordado no item 3.1 desse livro,
49
um mau gerenciamento de projeto, pode resultar em falha grave nos projetos. Dessa
forma, é importante que a seleção da pessoa responsável pelo controle e
coordenação desse tipo de projeto seja realizada com responsabilidade e critério.
No gerenciamento de projetos de software, os profissionais responsáveis pelo
desenvolvimento de planos e cronograma dos projetos são os gerentes de software.
Além dessa função, eles também “supervisionam o trabalho para assegurar que ele
esteja sendo realizado dentro dos padrões exigidos e monitoram o progresso para
verificar se o desenvolvimento está no prazo e dentro do orçamento” SOMMERVILLE
(2007, p.61).
3.2.1 Visão geral das atividades de gerenciamento de projeto de software
As atividades de um projeto, em geral, estão diretamente relacionadas ao

“processo de identificação e documentação das ações específicas a serem
realizadas para produzir as entregas do projeto” (PMBOK, 2017, p. 183). Uma
atividade de gerenciamento de projeto de software está associada a “parte do
projeto que acontece ao longo de determinado período” (PFLEEGER 2004, p.64).
A figura 19 ilustra a proposta de atividades em um projeto de gerenciamento
de software.
50
Figura 19: Esboço das atividades de gerenciamento de software
3.2.2 Visão geral do planejamento de gerenciamento de projeto de software
Conforme já citado no item 3.1 desse livro, o planejamento, de uma forma

geral, trabalha visando a realização dos objetivos do projeto. Nos projetos de
gerenciamento de software, para que os objetivos sejam alcançados são necessários
planos de ações. O quadro 7, exibe informações, sobre os planos de ações de um
planejamento de projeto de software.
51
Quadro 7: Tipos de planos de ação
Plano Descrição
Descreve os procedimentos e os padrões de
Plano de qualidade
qualidade usados no projeto.
Descreve a abordagem, os recursos e o
Plano de validação
cronograma usado para a validação do sistema.
Plano de gerenciamento de Descreve os procedimentos e a estrutura de
configuração gerenciamento de configuração a serem usados.
Prevê os requisitos de manutenção do sistema, os
Plano de manutenção
cultos de manutenção e o esforço necessário.
Plano de desenvolvimento de Descreve como as habilidades e a experiência dos
pessoal membros da equipe de projeto será desenvolvida.
Fonte: Sommerville (2007, p. 64).
Em um planejamento de projeto de software, as ações devem ser elaboradas

e acompanhadas pelo gerente do projeto. Na figura 20, é possível identificar as
ações referentes ao planejamento de projeto de software. Note, na figura, que há
um “loop” ao término da ação final, caso haja um novo problema, o processo é
reiniciado.
Figura 20: Ações do planejamento de projeto de software
Fonte: Sommerville (2007, p.64)
52
Um conceito importante e que tem relação direta com as atividades é o termo
“marco”. Diferente de atividade, o marco, pode ser definido como sendo “um ponto
final reconhecível de uma atividade do processo e software” SOMMERVILLE (2007, p.
65). Para Pfleeger (2004), na relação entre marco e atividade, pode-se afirmar que
“uma atividade tem um começo e um fim, ao passo que o marco é o fim de uma
atividade – um momento específico no tempo”.
A figura 21 ilustra o conceito e as relações entre atividade e marco no
planejamento de projeto de software, observe na figura a descrição do marco e sua
finalização em uma atividade.
Figura 21: Atividade e marcos no processo de requisitos
Fonte: Adaptada de Sommerville, (2007, p.65).
3.2.3 Visão geral do cronograma de gerenciamento de projeto de software
Cronograma de projeto de software “é uma atividade que distribui o esforço

estimado por toda a duração planejada do projeto alocando esse esforço para
tarefas específicas de engenharia de software” PRESSMAN (2011, p. 632). A partir da
elaboração do cronograma é possível realizar a identificação das atividades e
marcos estabelecidos e o tempo para sua realização.
O responsável pela elaboração do cronograma de projeto de software é o
gerente de software. Elaborar um cronograma não é uma tarefa fácil, tendo em vista
que envolve a organização e divisão das tarefas de um projeto em atividades,
associado ao tempo necessário para a sua realização. Sobre isso Pressman (2011, p.
53
638) afirma que:
o objetivo das ferramentas de cronograma de projeto é permitir que
o gerente defina as tarefas; estabeleça suas dependências; atribua
recursos humanos às tarefas e desenvolva uma variedade de cartas,
diagramas e tabelas que ajudem a acompanhar e controlar o projeto
de software.
Alguns cuidados são importantes na elaboração de um cronograma, itens

como, tempo de duração das atividades, os recursos necessários para o término das
tarefas, detalhamento de orçamentos, todos esses itens precisam estar
compreensíveis, de forma que toda a equipe entenda sobre as atividades a serem
executada e o tempo previsto para a realização.
Na elaboração de um cronograma “Uma boa regra prática é fazer a
estimativa como se nada fosse dar errado e, então, aumentar a estimativa para
cobrir problemas não previstos” Sommerville (2007, p. 66). A figura 22 representa as
ideias citadas pelo autor.
Figura 21: Processo de Desenvolvimento do Cronograma de um Projeto
Fonte: Adaptada de Sommmerville (2007, p. 66).
O acompanhamento das atividades propostas no cronograma precisa ser

gerenciado pelo engenheiro de software, o qual realiza um controle da execução
das atividades e o tempo proposta para realizá-la. Importante lembrar que o
cronograma não tem caráter fixo, ou seja, ele é flexível, podendo ser ajustado com
o surgimento ou alterações de demandas.
54
Em resumo, três informações importantes sobre cronograma, de acordo com PRESSMAN
(2004, p. 629)
Por que é importante? Para criar um sistema complexo, muitas tarefas de engenharia de
software ocorrem em paralelo, e o resultado do trabalho executado durante uma tarefa
pode ter um profundo efeito sobre o trabalho a ser executado em outra tarefa. Essas
interdependências são muito difíceis de entender sem um cronograma. É também
praticamente impossível avaliar o progresso em um projeto de software de tamanho
moderado ou grande sem um cronograma detalhado.
Quais são as etapas envolvidas? As tarefas de engenharia de software ditadas pelo

modelo de processo de software são refinadas para a funcionalidade a ser criada.
Duração e esforço são alocados para cada tarefa e é criada uma rede de tarefas
(também chamada de “rede de atividades”) para possibilitar que a equipe de software
cumpra os prazos de entrega estabelecidos.
Como garantir que o trabalho foi realizado corretamente? Um cronograma apropriado

requer que: (1) todos os riscos apareçam na rede, (2) esforço e duração sejam alocados
inteligentemente para cada tarefa, (3) as interdependências entre as tarefas sejam
indicadas corretamente, (4) sejam alocados recursos para o trabalho a ser feito, e (5)
sejam alocados pontos de verificação bem próximos uns dos outros para que o progresso
possa ser acompanhado.
3.3 ANÁLISE DE RISCOS
Da mesma forma que é planejada as etapas do projeto de software, tais

como: os objetivos, a realização das atividades, marcos e cronograma, é preciso
pensar também nos riscos que podem ocorrer e os impactos no projeto de software.
A parte do projeto que se refere à análise de riscos é uma das atividades mais
importante, tendo em vista que, a eficiência dessa análise poderá ajudar na
resolução de problemas que podem ocorrer em todo o processo de software.
A análise de riscos pode afetar o cronograma e a qualidade do software. A
figura 22 apresenta as três grandes categorias de riscos.
55
Figura 22: Categoria de riscos
Fonte: Adaptada de Sommerville (2007, p. 69).
A proatividade é considerada uma das melhores estratégias para o

gerenciamento de risco. O que é uma estratégia proativa? De acordo com
Pressman, (2011, p. 649), uma estratégia proativa:
inicia muito antes que o trabalho técnico comece. São identificados

os riscos potenciais, avalia-se a probabilidade e o impacto, e os riscos
são classificados por ordem de importância. Então, a equipe de
software estabelece um plano para gerenciar o risco. O objetivo
primário é evitar o risco, mas como nem todos os riscos podem ser
evitados, o grupo trabalha para desenvolver um plano de
contingência que lhe permita responder de maneira controlada e
eficaz.
Há quatro estágios no processo de gerenciamento de riscos: identificação,

análise, planejamento e monitoração dos riscos. Três desses estágios, suas
características e definições são apresentados no quadro 8.
56
Quadro 8: Estágios do processo de gerenciamento de riscos
Tipo de risco Identificação dos riscos Análise dos riscos Monitoração dos
riscos
Tecnologia Software e Hardware Defeitos no Hardware e software
usados para componente de de apoio entregues
desenvolver o sistema. software com atraso.
Problemas no banco
de dados no processo
de transações.
Pessoal Associados a pessoas Pessoal qualificado Problemas no
da equipe de Equipe incompleta – relacionamento dos
desenvolvedores pessoal com membros da equipe –
problemas de saúde pessoal e financeiro
Falta de treinamento
do pessoal
Organizacional Ambiente Troca de gerente do Ausência do gerente
organizacional onde o projeto de projeto
software é Reduções no Boatos negativos na
desenvolvido orçamento organização
Ferramenta Ferramentas CASE e Código da Resistência da equipe
outros softwares de ferramenta CASE é para o uso de
apoio insuficiente determinados
Não possibilidade de equipamentos
integração de dados Demanda por
tecnologias mais
avançadas
Requisitos Mudança de requisitos Mudanças de Reclamações do
pelo cliente ou no requisitos – retrabalho cliente
processo de Falta de Muitas solicitações de
gerenciamento entendimento dos mudança de
clientes quanto a requisitos
mudança de
requisitos
Estimativas Estimativas de Cálculo errado no Falha no
gerenciamento e de prazo de cumprimento do
recursos na desenvolvimento cronograma e em
elaboração no sistema. Cálculo errado na eliminar defeitos
taxa de reparto do instalados
sistema
Cálculo errado na
previsão do tamanho
do software
No processo de planejamento dos riscos, cada risco é identificado, e a partir

dessa ação são elaboradas estratégias para o gerenciamento. Para Sommerville
(2007) as estratégias são classificadas como: Estratégias de prevenção, a qual indica
que a probabilidade do risco ocorrer é menor; Estratégias de minimização, na qual o
impacto do risco será reduzido; e os planos de contingência, o qual apresenta uma
estratégia para a resolução do problema.
57
As atividades de gerenciamento de riscos geram custos adicionais para o
projeto, mas pode evitar prejuízos tanto financeiros quanto estrutural, tendo em vista
o caráter preventivo das suas atividades. O controle de riscos está diretamente
relacionado com a redução, o planejamento e a resolução de riscos. De acordo
com Pfleeger (2004, p.96), três estratégias para redução de riscos são indicadas:
Evita-los modificando os requisitos quanto ao desempenho ou a

funcionalidade; transferi-los, alocando-os em outros sistemas, ou
realizando um contrato de seguro, a fim de cobrir qualquer perda
financeira, caso o risco se torne uma realidade e assumir os riscos,
acertando-os controlando-os com os recursos do projeto.
Para finalizar essa seção é importante entender que nem o gerente de

software, ou qualquer outro membro da equipe são “super-heróis”, portanto o que se
pode exigir no gerenciamento de riscos desses profissionais é o controle e
acompanhamento das ações, conforme orientações de vários autores que são
referência no assunto.
Tendo como base a leitura do quadro 8 deste livro, analise: você é um gerente de uma
empresa e está desenvolvendo um projeto de software. O software em desenvolvimento
é um aplicativo para controle de entradas e saídas de documentos do setor de protocolo
da empresa. Como seria a tabela de riscos para esse projeto?
Nessa unidade foi possível entender que um bom gerenciamento de projeto

realizado pelo gerente de projetos, é fundamental para que os projetos sejam
conduzidos de forma a cumprir o cronograma e orçamentos previstos. Se
comparada com outros projetos na área de engenharia, o projeto de engenharia de
software diferencia-se dos demais por trabalhar com um produto intangível: software.
58
FIXANDO O CONTEÚDO
1. São características no gerenciamento de projetos eficazes:

I. Identificar, recuperar ou eliminar projetos com problemas;
II. Otimizar o uso dos recursos organizacionais;
III. Saber lidar com prazos perdidos e estouro de orçamento;
IV. Saber Gerenciar restrições.
Estão corretas:
a) I, II, III e IV.
b) I, II e III.
c) I, II e IV.
d) II e III.
e) III e IV.
As questões 2 e 3 referem-se ao trecho extraído do livro “Engenharia de Software: Uma

abordagem tradicional” de Roger S. Pressman (2011, p. 367):
“De acordo com os dados médios do setor, o custo para descobrir e corrigir defeitos durante
a fase de codificação é de US$ 977 por defeito. Portanto, o custo total para corrigir os 200
defeitos “críticos” durante essa fase (200 x US$ 977) é de aproximadamente US$ 195.400. Os
dados médios do setor mostram que o custo para descobrir e corrigir defeitos durante a fase
de testes é de US$ 7.136 por defeito. Nesse caso, supondo que a fase de testes do sistema
tenha revelado aproximadamente 50 defeitos críticos (ou apenas 25% daqueles encontrados
pela Cigital na fase de codificação), o custo para descobrir e corrigir esses defeitos (50 x US$
7.136) teria sido de aproximadamente US$ 356.800. Isso teria resultado em 150 erros críticos
sem serem detectados e corrigidos. O custo para descobrir e corrigir esses 150 defeitos
remanescentes na fase de manutenção (150 x US$ 14.102) teria sido de US$ 2.115.300.
Portanto, o custo total para descobrir e corrigir os 200 defeitos após a fase de codificação
teria sido de US$ 2.472.100 (US$ 2.115.300 + US$ 356.800)”.
2. A partir da interpretação dos dados acima e nos conhecimentos discutidos sobre

o assunto, podemos afirmar que a fase de maior investimento na produção do
software indicado na situação acima é:
a) Coleta e análise dos requisitos.
b) Construção do projeto.
c) Codificação e elaboração do código fonte.
d) Fase de testes do sistema.
59
e) Na manutenção do sistema.
3. Se analisarmos os recursos disponíveis na engenharia de software atualmente, uma

estratégia que tem como objetivo evitar o tipo de gasto descrito no texto é:
a) Elaboração de um processo de planejamento de riscos.
b) Mudanças no cronograma.
c) Alterações na quantidade de pessoas da equipe de trabalho.
d) Auditoria nas atividades do software.
e) Investimentos na fase de teste do sistema.
4. Atualmente o gerenciamento de risco tornou-se uma das principais atividades dos

gerentes de projeto. O objetivo é detectar o risco que pode afetar o cronograma e
a qualidade do software em desenvolvimento.
Sobre o gerenciamento da análise de risco marque a opção CORRETA:
a) Os tipos de riscos de um projeto se sobrepõem, ou seja, se um analista for demitido,
pode ocorrer um risco de projeto, risco de produto e também um risco de negócio.
b) A qualidade e desempenho do software são considerados riscos de projeto.
c) Se uma empresa concorrente lançar no mercado o mesmo produto que outra
empresa, temos nesse caso um risco de projeto.
d) Se um componente que foi adquirido pela empresa para compor o projeto, e não
apresentar um funcionamento conforme especificado, a análise é de risco de
Negócio.
e) O processo de análise de risco é um processo linear.
5. São atividades de gerenciamento de software:

a) Seleção e avaliação do pessoal e Análise de requisitos.
b) Elaboração de relatórios de apresentação e programação do código fonte do
software.
c) Monitoração e revisões do projeto e elaboração da proposta do projeto.
d) Levantamento do custo do projeto e Elaboração dos diagramas de fases.
e) Planejamento do cronograma do projeto e realização da especificação de
componentes do sistema.
60
6. Observe as proposições abaixo sobre os planos que fazem parte do planejamento
de projeto:
I. Plano de manutenção: Realizar planilhas referente aos gastos em relação a
proposta de manutenção do sistema.
II. Plano de validação: Elaborar planilha de atividades e a previsão do tempo
para realiza-las.
III. Plano de qualidade: Elaborar documento com informações sobre o perfil da
equipe, para a realização das atividades, visando à qualidade do projeto.
IV. Plano de gerenciamento de configuração: Definir documento de requisitos
proposto no projeto.
Está (ão) correta(s):
a) I, II e III.
b) I e III.
c) I e II.
d) Somente I.
e) Somente II.
7. Observe o trecho:
“Você selecionou um modelo de processo apropriado, já identificou as tarefas de
engenharia de software que precisam ser executadas, estimou a mão de obra e o
número de pessoas, conhece os prazos e até já considerou os riscos. Agora chegou
a hora de ligar os pontos. Isto é, tem de criar uma rede de tarefas de engenharia de
software que lhe permitirá terminar o trabalho no prazo.” (PRESSMAN, 2011, p. 629)
O Trecho acima se refere ao próximo passo na elaboração do projeto de software,
marque a alternativa abaixo que se refere a essa etapa.
a) Definição das Atividades
b) Definição dos Marcos
c) Realização da Análise de riscos
d) Verificação de erros
e) Realização do Cronograma
8. (FUMARC- 2012 – Adaptado) Analise as seguintes afirmativas sobre Gestão de Riscos

em projetos de software.
I. A gestão de riscos envolve a análise do nível de incerteza e do grau de perda
61
associados a cada risco.
II. Construir um produto que não se encaixa no plano estratégico da empresa pode
ser considerado um “Risco de Negócio”.
III. “Riscos imprevisíveis” são apontados a partir de experiências em projetos
anteriores. Rotatividade de pessoal é um exemplo desse tipo de risco.
IV. Comprar um equipamento para compor o software, sem o devido estudo da
necessidade é um risco de produto.
V. Erros na elaboração do cronograma e investimentos de recursos no projeto são
considerados um risco de projeto.
Estão corretos:
b) I, II, IV e V.
c) II, III e IV.
d) II e V.
e) IV e V.
62
ENGENHARIA DE REQUISITOS UNIDADE
4.1 ESTUDOS DE REQUISITOS: CONCEITOS E IMPORTÂNCIA

04
A palavra requisito, de acordo com o dicionário Priberam online, significa,
“coisa necessária e indispensável, condição indispensável, exigência”. Na
terminologia da engenharia de software, de acordo com o Institute of Electrical and
Electronic Engineers (IEEE, 1990), citado por GLINZ Glinz (2011, p. 79) requisito é a
“condição ou capacidade que deve ser atendida ou tida por um sistema ou
componente do sistema para satisfazer a um contrato, padrão, especificação ou
outro documento formalmente imposto”. O autor completa informando que a
International Requirements Engineering Board (IREB) complementa, em um contexto
de definição mais moderna do termo, que: requisito “uma capacidade ou
propriedade que um sistema deverá ter [...]. Uma representação documentada de
uma necessidade, capacidade ou propriedade”. Sommerville (2007, p. 79)
acrescenta que requisitos de um sistema são as “descrições dos serviços fornecidos
pelo sistema e suas restrições operacionais”.
Ao realizar um trabalho com requisitos, alguns questionamentos tornam-se
importante, os quais ajudam no detalhamento e consequentemente qualificam o
relatório final do projeto de requisitos, são eles:
Os requisitos estão corretos? Os requisitos são consistentes? Os

requisitos estão completos? Os requisitos são realistas? Cada requisito
descreve algo que é necessário para o cliente? Os requisitos podem
ser verificados? Os requisitos podem ser rastreados? (PFLEEGER, 2004,
p.118).
Ressalta-se nesses conceitos iniciais sobre requisitos o fator ligado à qualidade.

São características fundamentais de qualidade de um requisito: a capacidade de
correção, precisão, completeza, consistência, priorização, verificabilidade,
modificabilidade e a rastreabilidade.
Seja qual for à definição, uma especificação ou gerenciamento ruim de um
requisito traz inúmeros prejuízos há um projeto de software.
63
O Institute of Electrical and Electronic Engineers – IEEE é considerada uma das maiores
organizações profissionais técnica do mundo para o avanço da tecnologia. Para saber
um pouco mais sobre o instituto acesse https://www.ieee.org/. O IREB (International
Requirements Engineering Board) é o Conselho Internacional de Engenharia de Requisitos.
O conselho elaborou um glossário de terminologia de engenharia de requisitos, o qual
contém conceitos de termos importantes na área. Para acessar o dicionário na sua versão
original, acesse o link: https://www.ireb.org/en/cpre/basics/. A empresa a T&M Testes Ltda
realizou a tradução do glossário no ano de 2011, o arquivo está disponível no site da IBQTS
ibqts – Instituto Brasileiro de Qualidade em Software, http://ibqts.com.br/. O site também
é uma boa fonte de pesquisa sobre o assunto requisito.
4.1.1 Importância do estudo de requisitos
A definição dos requisitos de um sistema de software é uma das etapas que

possui grande potencial de causar danos no produto final. A função de um requisito
é definir o que poderá ou não ser executado pelo software, ou seja, todos os objetivos
e funções serão definidos pelos requisitos. Dessa forma, as falhas nessa etapa do
processo poderão acarretar problemas em vários itens definidos, como
determinações dos prazos, recursos e ações planejadas no projeto.
Neste contexto alguns cuidados são necessários na fase de elaboração dos
requisitos, a figura 23, mostra um esquema contento alguns dos principais problemas
a serem verificados nessa fase.
64
Figura 23: Principais problemas na fase de elaboração de requisitos
Fonte: Adaptado de Reinehr (2020)
Os problemas podem ocorrer em qualquer projeto de software, e poderá ter

origem desde a escolha do tipo de projeto, nas atividades da equipe de trabalho ou
na tecnologia selecionada, seja em um projeto simples ou mais complexo.
A fase de análise dos requisitos combinada com outras partes do projeto está
diretamente relacionada com o sucesso do projeto de software. A redução de custos é
um dos principais benefícios. Quais outros benefícios podem pensar?
4.1.2 Engenharia de Requisitos
A engenharia de requisitos refere-se ao “amplo espectro de tarefas e técnicas

que levam a um entendimento dos Requisitos” (PRESSMANN, 2011, p. 127). Para o
autor esse processo tem importância desde o início da atividade de comunicação
até a modelagem do sistema, sendo adaptadas às necessidades do processo, do
produto e das pessoas. A engenharia de requisitos “estabelece uma base sólida para
o projeto e para a construção. Sem ela, o software resultante tem grande
probabilidade de não atender às necessidades do cliente” (p.126).
65
O processo de Engenharia de Requisitos é um elemento fundamental no
contexto da engenharia de software, pois estabelece um conjunto de interações
entre as demandas dos clientes, na elaboração do projeto de software e na equipe
que irá desenvolvê-lo. A partir dessas relações a engenharia de requisitos fornece
subsídios à modelagem nos projetos.
Para Sommerville (2007), principal objetivo da engenharia de requisitos é “criar
e manter um documento de requisitos do sistema” (p.95). Para que isso seja possível
é preciso entender os processos de viabilidade, elicitação e análise, a especificação
e a validação de requisitos, conforme é ilustrado na figura 24.
Figura 24: Atividades de Engenharia de requisitos no processo de software
As fases citadas na figura 24 mostram que a engenharia de requisitos inicia- se

a partir de um estudo inicial sobre o contexto de criação do sistema de software, ou
seja, um levantamento, um estudo sobre a descrição e viabilidade do sistema.
Na fase de elicitação e análise de requisitos o desenvolvedor irá realizar um
trabalho de coleta de dados junto ao usuário do sistema e todos os envolvidos,
buscando entender as necessidades quanto ao uso do sistema. Nessa fase vários
recursos serão utilizados para a coleta e organização da informação, (a etnografia,
entrevistas, estudo de cenários, etc.) O item 4.3 desse livro abordará detalhes e
conceitos dessa fase da engenharia de requisitos.
A fase de especificação de requisitos relaciona-se com os estudos dos
66
requisitos de usuários e de sistemas. Como exemplo, podemos citar a elaboração de
documentos em relação aos requisitos funcionais e não funcionais que serão
abordados no sistema, esses conceitos serão explicitados no item 4.2 desse livro.
A validação dos requisitos é a fase final, e abordam itens importantes, como
as revisões, prototipação e a geração de casos de testes. Nessa fase serão revisados
erros, conflitos e contradições que são apontados pelos revisores.
Engenharia de Requisitos
Quem realiza? Engenheiros de software (algumas vezes conhecidos no mundo da TI
como engenheiros de sistemas ou “analistas”) e outros interessados no projeto (gerentes,
clientes, usuários finais), todos participam da engenharia de requisitos.
Por que é importante? Projetar e construir um programa de computador elegante que
resolva o problema errado não atende às necessidades de ninguém. É por isso que é
importante entender o que o cliente quer antes de começar a projetar e construir um
sistema baseado em computador.
Qual é o artefato? O objetivo da engenharia de requisitos é fornecer a todas as partes
um entendimento escrito do problema. Isso pode ser alcançado por meio de uma série
de artefatos: cenários de uso, listas de funções e características, modelos de análise ou
uma especificação.
Como garantir que o trabalho foi realizado corretamente? Os artefatos da engenharia
de requisitos são revisados com os interessados para garantir que aquilo que você
entendeu é realmente aquilo que eles queriam dizer. Um alerta: mesmo depois de todas
as partes terem entrado em acordo, as coisas vão mudar e continuarão mudando ao
longo de todo o projeto (PRESSMANN, 2011, p. 125).
4.2 REQUISITOS DE UM SOFTWARE: CARACTERÍSTICAS GERAIS, REQUISITOS

FUNCIONAIS E NÃO FUNCIONAIS
4.2.1 Características gerais
Muitas falhas e problemas nos softwares ocorrem durante o processo de

engenharia de requisitos, isso porque não há um claro entendimento em relação aos
níveis de descrição dos requisitos (SOMMERVILLE, 2007).
No quadro 9 são exibidos conceitos e características dos requisitos de usuários
e de sistema importantes na classificação de requisitos na visão de Sommerville.
67
Quadro 9: Requisitos de usuário e requisitos de sistema.
Requisitos de Usuários Requisitos de Sistema
Utilizados para declarar os requisitos Utilizados para indicar a descrição detalhada
abstratos de alto nível, ou seja, de fácil do que o sistema deverá fazer. Portanto,
compreensão pelos usuários do sistema que estabelecem detalhadamente as funções e
não têm conhecimentos técnicos. as restrições de sistemas.
Devem ser escritos para os envolvidos no O documento de requisitos de sistema,

sistema que não tenham um conhecimento algumas vezes chamado de especificação
detalhado do seu funcionamento. funcional, deve ser preciso e pode servir
como um contrato entre o comprador do
sistema e o desenvolvedor de software.
São declarações em linguagem natural ou Devem ter como alvo os profissionais técnicos
em diagramas sobre as funções que o de nível sênior e os gerentes de projeto.
sistema deve fornecer e as restrições sob as
quais deve operar.
Exemplo: O software deverá permitir a Exemplo: os arquivos externos terão cada
representação e acesso de arquivos tipo sendo representada por um ícone
elaboradas por outras ferramentas específico a disposição do usuário.
Nas duas seções seguintes, serão descritos os requisitos funcionais e não

funcionais. A classificação de um tipo de requisito auxilia no processo de elaboração
da documentação do software, além de organizar todo processo de especificação
do projeto de software.
4.2.2 Requisitos Funcionais
Os requisitos funcionais estão diretamente relacionados com a realização de

funcionalidades pelos softwares para acatar à determinada necessidade do usuário.
São as declarações de serviços que o sistema deve fornecer como o

sistema deve reagir a entradas específicas e como o sistema deve se
comportar em determinadas situações. Em alguns casos, os requisitos
funcionais podem também estabelecer explicitamente o que o
sistema não deve fazer (SOMMERVILLE, 2007, p. 80).
Os requisitos funcionais “dependem do tipo de software que está sendo

desenvolvido, dos usuários a quem o software se destina e da abordagem geral
considerada pela organização ao redigir os requisitos” (SOMMERVILLE, 2007, p.81).
Quando expressos como requisitos de usuários são descritos de forma abstrata e os
de sistema descrevem detalhadamente as funções do sistema.
Na figura 24 um esboço da ideia em relação ao conceito de requisito
68
funcional e a ênfase na ação em relação ao software e comportamento do sistema
buscando o objetivo de elaboração de um requisito completo e consistente.
Figura 24: Conceito de Requisito Funcional
Considerando os dados apresentados na figura 24, para Sommerville (2007), a

especificação de um requisito funcional do sistema precisa ser completa porque
devem ser definidos todos os serviços do usuário e consistente indicando que não
poderá haver contradições nas definições dos requisitos funcionais.
O quadro 10 ilustra um exemplo de requisito funcional: <Gerar relatório de cpf
para bloqueios de pagamentos>, nesse exemplo a funcionalidade permitirá a
geração de uma lista, em papel ou na tela, de dados, conforme o critério de busca
do relatório.
69
Quadro 10: Exemplo de um Requisito Funcional
Identificador RF001
Nome Gerar relatório de cpf para bloqueios de pagamentos
Módulo Gerencial
Data da 15/05/2022 Responsável João do ABC
Elaboração
Data da Última N/A Responsável N/A
alteração
Versão 1.0 Prioridade Essencial
Descrição O sistema permitirá que os gerentes emitam relatórios de acordo com
os dados informados na solicitação do relatório.
Na entrada o usuário deverá realizar o preenchimento do campo do
mês e ano.
Após a inserção do mês e do ano, o sistema irá apresentar na tela,
uma lista com dados (nome, cpf, endereço, telefone) de pessoas
que ainda não foram informadas pelo sistema da realização de uma
atualização cadastral.
O Gerente terá a opção de fazer a leitura na tela, ou imprimir em
papel.
Fonte: Elaborado pelo autor
No exemplo exibido do quadro 10, é importante perceber a organização e

disposição das informações de um requisito funcional no formulário, tal organização
auxilia no processo de entendimento da funcionalidade solicitada pelo requisito.
Nos conceitos sobre requisitos funcionais trabalhados nesse tópico é possível identificar
que a realização de uma funcionalidade pode estar relacionada a mais de um requisito
funcional. Imagine um sistema que possui uma tela “Cadastro de usuários”, o qual
controla os dados cadastrais dos perfis dos usuários do sistema. Nessa tela é possível incluir,
alterar, consultar e excluir usuários, ou seja, uma única funcionalidade. Quantos e quais
requisitos podem ser realizados por essa funcionalidade?
4.2.3 Requisitos Não funcionais
Os requisitos não funcionais não estão ligados diretamente à funcionalidade,

como os requisitos funcionais, mas precisam ser elaborados, para que o software
atenda seus objetivos.
Um requisito não funcional pode estar ou não, associado a um requisito
funcional e sua importância é semelhante à dos requisitos funcionais para o projeto
de software. Para Sommerville (2007, p. 80), podemos conceituar requisitos não
70
funcionais como sendo “restrições sobre os serviços ou funções oferecidas pelo
sistema. Eles incluem restrições de timing, restrições sobre de desenvolvimento e
padrões”. Pfleeger (2004) completa afirmando que os requisitos não funcionais,
também denominados de restrições, “descrevem uma restrição no sistema que limita
nossas opções para criar uma solução para o problema” (p.115).
Um exemplo de requisito não funcional está descrito no quadro 11, o formulário
apresenta os dados de um requisito externo, da categoria de requisitos legais do tipo
“requisito de segurança”.
Quadro 11: Exemplo de um Requisito Não Funcional

Identificador RNF001 Categoria Segurança
Nome Autenticação do usuário com login e senha
Data da Elaboração 15/05/2022 Responsável João do ABC
Data da Última N/A Responsável N/A
alteração
Versão 1.0 Prioridade Essencial
Descrição Login é a identificação do usuário que seguido da digitação da
senha acessam o sistema. A senha é criptografada no sistema. Os
dados são salvos no banco de dados sendo cadastrados pelo
administrador do sistema.
Sommerville (2007) apresenta uma classificação completa em relação aos

tipos de requisitos não funcionais, conforme ilustrado na figura 25.
71
Figura 25: Tipos de requisitos não funcionais
Fonte: Sommerville (2007, p. 82).
De acordo com a figura 25, os requisitos de produtos e seus subtipos

especificam o comportamento do produto; os requisitos organizacionais e seus
subtipos estão diretamente relacionados com procedimentos de organização entre
cliente e desenvolvedor e por último os requisitos externos, os quais estão
relacionados com todos os fatores externos que envolvem desenvolvimento do
sistema.
Fatores como: o conhecimento sobre o conceito das atividades, os critérios na
determinação dos prazos, custos e o esforço para a implementação dos projetos,
são itens importantes na elaboração de requisitos não funcionais para um sistema de
software.
São consideradas metas para especificar requisitos não funcionais, as
seguintes propriedades: Velocidade, tamanho, facilidade de uso, confiabilidade,
Robustez e portabilidade.
72
Para aprofundar o assunto sobre requisitos funcionais e não funcionais, recomenda-se a
leitura da parte 2, capítulo 6 do livro “Engenharia de software” do autor Ian Sommerville
(2007), páginas 77-94. O livro está disponível na biblioteca virtual, no link:
https://abrir.link/slcpS. Acesso em: 20 jan. 2023.
4.3 ELICITAÇÃO E ANÁLISE DE REQUISITOS
Considerada uma das fases mais importantes do projeto de software a

elicitação de requisitos está diretamente relacionado com o “entendimento”, pelo
desenvolvedor, das ideias do solicitante. É a fase onde serão coletadas informações
sobre o que o cliente deseja que seja construído.
Na coleta de informações a equipe de TI irá orientar o cliente, buscando
entender as necessidades e propostas para a elaboração do projeto de software. É
um momento de muita conversa!
Nessa atividade, os engenheiros de software trabalham com os

clientes e os usuários finais do sistema para aprender sobre o domínio
da aplicação, quais serviços o sistema deve fornecer, o desempenho
esperado do sistema, restrições de hardware, etc (SOMMERVILLE, 2007,
p. 97)
Figura 26: Fontes de Elicitação de Requisitos
Fonte: Adaptado de Pohl e Rupp (2012)
A figura 26 ilustra detalhes do conceito e estrutura para a coleta de

informações na fase de elicitação de requisitos. Pohl e Rupp (2012) reforça que a
elicitação de requisitos depende do contexto do sistema que se pretende
desenvolver e inclui as fontes de requisitos que serão analisadas e investigadas, um
processo que é óbvio durante a engenharia de requisitos.
73
Nas seções seguintes, serão discutidos os recursos metodológicos proposto na
elicitação de requisitos para a coleta e análise de dados e informações para a
construção de um sistema.
4.3.1 Levantamento de requisitos
Na fase de levantamento de requisitos, como o próprio nome indica, serão

coletadas informações iniciais sobre o contexto em que se pretende desenvolver o
sistema e também de todas as partes interessadas no projeto.
Um conceito importante nessa fase do projeto é Stakeholders, termo em inglês
que significa “partes interessadas”, refere-se aos usuários que interagem com o
sistema e toda a organização (clientes, usuários, engenheiro do software, gerentes
de negócios, representantes dos sindicatos, especialistas, etc.).
Existem várias consequências negativas de não se considerar os Stakeholders,
uma delas são os custos adicionais após a conclusão de fases do projeto, ou seja, as
atividades precisam ser acertadas na fase atual do processo. Dessa forma é preciso
identificar todos os Stakeholders, para isso é necessário à manutenção dos checklists
atualizados, o que irá favorecer uma coleta de dados sistemática de Stakeholders
relevantes. Portanto, torna-se necessário: gerenciar os Stakeholders, transformar os
afetados em colaboradores e estabelecer acordos individuais com todos envolvidos
(POHL; RUPP, 2012).
Para saber mais sobre a relação dos engenheiros de requisitos e os Stakeholders, leia a
página 49 do capítulo 3 do livro: “Fundamentos da Engenharia de Requisitos”, de POHL e
RUPP (2012).
A principal função da fase do levantamento de requisitos é a de coletar

informações das pessoas envolvidas em todo o contexto do projeto de software,
principalmente dos usuários que irão fazer o uso do sistema. Essa é uma atividade
complexa, pois está diretamente relacionada com questões sociais do indivíduo, do
grupo e da organização. É necessário um bom entendimento sobre as técnicas
disponíveis para a realização desse tipo de trabalho.
No quadro 12, é apresentado um estudo comparativo de técnicas e
74
instrumentos para a coleta de dados nessa fase do projeto.
Quadro 12: Comparação das técnicas para levantamento de dados
Técnica/Definição Pontos Positivos Pontos de Atenção

Entrevistas
A possibilidade de contato
São formuladas questões O problema do
direto com os atores que
para os Stakeholders sobre o conhecimento tácito e as
detêm o conhecimento
sistema que eles usam e o diferenças de cultura entre
sobre os objetivos do
sistema a ser desenvolvido. entrevistado e entrevistador.
software e a possibilidade de
Os requisitos são derivados
validação imediata por
das respostas a essas
processos de comunicação.
questões.
Questionários A padronização das A limitação do universo de
Utilizado para obter perguntas e possibilidade de respostas e a pouca
informações de uma grande tratamento estatístico das iteração, visto a
quantidade de usuários. respostas. impessoalidade da técnica.
Fornece maior interação Algumas vezes, as ideias são
social, não limita o apresentadas de maneira
Brainstorming
problema, há ausência da confusa, tornando difícil o
É uma técnica para geração
crítica e ajuda a tirar certas refinamento, o
de ideias, em que se reúnem
dificuldades do processo. desenvolvimento e a
várias pessoas que fazem a
avaliação.
sugestão de ideias sem que
Gera uma ampla variedade
sejam criticadas ou julgadas, Pode ocorrer também de
de pontos de vistas, estimula
ou seja, as pessoas que alguns participantes se
o pensamento criativo,
participam desse tipo de manifestarem a favor ou
constrói uma imagem mais
reuniões sugerem e contra a algumas ideias
completa do problema,
exploram suas ideias apresentadas, inibindo a
provê um ambiente social
livremente. produção do grupo.
muito mais confortável e
mais fácil de aprender.
JAD - Joint Application
Provê comunicação, Quanto mais complexo o
Development
entendimento e trabalho em sistema, mais reuniões são
É um agrupamento de
equipe entre usuários e necessárias. Todos os
ferramentas destinadas a
desenvolvedores, facilitando participantes devem estar
apoiar o desenvolvimento
assim a criação de uma familiarizados com as
de sistemas de informação
visão compartilhada do que técnicas que serão utilizadas
nas fases de levantamento
o produto possa ser. durante as reuniões.
de dados, modelagem e
análise.
Permite alterar o sistema
Prototipagem mais cedo no Normalmente, várias
Inicia-se pelo estudo desenvolvimento, iterações são necessárias
preliminar dos requisitos do adequando-o mais de perto para refinar um protótipo.
usuário e às necessidades do usuário,
é concluída com uma série e a interação com o usuário.
de requisitos formulados, Considerar o protótipo como
Permite descartar um
além de um protótipo que sendo o sistema final: a
sistema quando este se
simula o comportamento do qualidade pode não ter sido
mostrar inadequado.
sistema. apropriadamente
considerada.
Observação Baixo custo e pouca A dependência do ator
Tem como objetivo coletar complexidade da tarefa. (engenheiro de software)
informações dos usuários a desempenhando o papel de
75
Técnica/Definição Pontos Positivos Pontos de Atenção
partir da observação de observador e a
situações, através do superficialidade decorrente
contato direto com as da pouca exposição o
pessoas envolvidas na universo que está sendo
elaboração do projeto de observado.
software.
Análise de documentos
Consiste na identificação de
requisitos por meio da
Facilidade de acesso e
análise de documentos, Dispersão das informações e
volume de informações.
manuais envolvidos no volume de trabalho
processo, análise de
informações e/ou estudos de
mercado.
Fonte: Adaptado de Fernandes (2017, p. 36-46)
Uma boa estratégia nessa fase do projeto é a Etnografia, a qual está

relacionada aos estudos individuais descritivo de culturas dos povos, caracterizando
hábitos, religiões, raça, etc. Considerada uma metodologia das ciências sociais na
etnografia o analista que será inserido no ambiente de trabalho onde o sistema será
implantado tem como principal função: anotar o trabalho do dia-a-dia e todas as
atividades em que os participantes estão envolvidos. “O valor da etnografia está na
ajuda que presta aos analistas para descobrir os requisitos implícitos de sistema que
refletem os processos reais, e não formais, com os quais as pessoas estão envolvidas”
(SOMMERVILLE, 2007, p. 104)
Após a coleta de dados, é importante realizar a organização das informações
em relatórios, isso irá ajudar na análise de dados, que é a próxima fase da elicitação
de requisito.
4.3.2 Análise de requisitos
Para Pressman (2011, p. 151), “a análise de requisitos resulta na especificação

de características operacionais do software, indica a interface do software com
outros elementos do sistema e estabelece restrições que o software deve atender”.
Para o autor o modelo de análise é dinâmico, atende as necessidades de um
determinado momento, dessa forma é necessário que os desenvolvedores
entendam que sempre haverá mudanças, isso porque o principal objetivo dessa fase
está diretamente relacionado com o problema, com as demandas apontadas pelos
usuários e pelo estudo realizado no levantamento de dados.
76
A figura 26 ilustra os elementos de modelo de análise sugerido por Pressman, a
proposta do autor é apresentar um conjunto de elementos genéricos que são
comuns à maioria dos modelos de análise.
Figura 26: Fontes de Elicitação de Requisitos
Fonte: Adaptado de Pressman (2011)
Regras práticas para a análise de requisitos
Arlow e Neustadt (2002), citado por Presmann (2011) sugerem uma série de regras práticas
que devem ser seguidas ao se criar o modelo de análise:
1. O modelo deve enfocar as necessidades visíveis no domínio do
problema ou do negócio; o nível de abstração deve ser
relativamente elevado;
2. Cada elemento do modelo de requisitos deve contribuir para o
entendimento geral dos requisitos de software e fornecer uma
visão do domínio de informação, função e comportamento do
sistema;
3. Postergue considerações de infraestrutura e outros modelos não
funcionais até a fase de projeto;
4. Minimize o acoplamento do sistema;
5. Certifique-se de que o modelo de requisitos agrega valor a
todos os interessados. (p.152)
As regras citadas acima são consideradas básicas, mas que podem ajudar no momento
que a equipe realiza a análise de requisitos.
77
4.3.3 Documentação de requisitos
Após a análise de todo o material, é necessário realizar registros sistematizados

das informações e dados, essa função faz parte da fase de documentação de
requisitos. Uma das principais tarefas relacionadas nessa fase é realizá-la de forma
adequada, organizada e em linguagem acessível, fazendo uso de técnicas que
consideram uma linguagem livre ou estruturada, ou a utilização de modelos já pré-
estabelecidos. ”Uma especificação e requisitos é uma coleção de requisitos
representada de forma sistemática, tipicamente para um sistema ou componente,
atendendo a determinados critérios” (POHL e RUPP 2012, p. 61).
O documento de requisitos, também denominado especificação de requisitos
de software ou SRS – Software Requiremenets Specification, conforme afirma
Sommerville (2007), é considerada a declaração oficial que os desenvolvedores de
sistema devem implementar. O quadro 13 ilustra os envolvidos e suas funções no
desenvolvimento do documento de requisitos, conforme descreve o autor.
Quadro 13: Usuários de um documento de requisitos

Usuários Função
Clientes de Especificam e leem os requisitos para verificar se eles atendem as suas
sistema necessidades.
Gerentes Usam o documento de requisitos para planejar um pedido de proposta
para o sistema e o processo de desenvolvimento do sistema
Engenheiro de Usam os requisitos para compreender qual sistema será utilizado
sistemas
Engenheiro de Usam os requisitos para desenvolver teste de validação no sistema
testes de sistema
Engenheiro de Usam os requisitos para compreender o sistema e os relacionamentos
manutenção de entre suas partes.
sistema
Fonte: Adaptado de Sommerville, (2007, p. 91)
Um dos modelos utilizados para especificação dos requisitos é o da IEEE/ANSI

830-1998, conforme afirma Sommerville (2007) é um padrão amplamente conhecido.
Veja na figura 27 detalhes dessa estrutura.
78
Quadro 27: Estrutura para elaboração do documento de requisitos
Fonte: Sommerville, (2007).
No item três, Sommerville (2007), destaca que os requisitos específicos poderão

documentar: “interfaces externas, descrever a funcionalidade e o desempenho do
sistema, especificar requisitos lógicos de banco de dados, restrições de projeto,
propriedade emergente do sistema e características de qualidade” (p. 92).
Existem outros padrões de modelo de requisitos que podem ser consultados, o
importante é saber que a documentação de requisitos é indispensável na produção
de um sistema de software.
Na concepção dos autores Pohl e Rupp (2012), existem quatro razões
principais para a documentação de requisitos: primeira, requisitos formam a base
para o desenvolvimento de sistema, segunda, o requisito tem relevância legal,
terceira, documentos de requisitos são complexos e por último, eles devem ser
acessíveis a todas as partes envolvidas.
4.4 VALIDAÇÃO DE REQUISITOS
Na produção de um sistema de software, após todo o trabalho realizado para

coleta, análise e documentação dos requisitos, é necessário realizar uma revisão da
qualidade dos requisitos desenvolvidos. A discussão proposta nessa fase do projeto
tem como objetivo confrontar o que foi realmente definido com aquilo que foi
pensando pelos usuários.
Para Pohl e Rupp (2012, p.119), são questões básicas nos fundamentos da
validação de requisitos:
79
 Os requisitos devem ser aprovados para uso nas demais partes do
desenvolvimento do projeto;
 O objetivo é descobrir erros nos requisitos recomendados;
 É preciso considerar o documento para todas as demais atividades do
desenvolvimento, evitando proliferação de erros e por último,
 É preciso realizar a verificação dos riscos legais no contrato entre cliente e
contratado.
Os detalhes que são trabalhados nas verificações do processo de validação
de requisitos, esquematizado na figura 28, a partir das ideias de Sommerville (2007),
resume as etapas e características desse processo.
Figura 28: Resumo do processo de verificação da validação e requisitos
Alguns princípios básicos auxiliam e interferem na qualidade da validação dos

requisitos, são eles: envolvimento dos Stakeholders correto; separação entre a
identificação de falhas e a correção e erros; validação a partir de diferentes pontos
de vistas; mudança adequada do tipo de documentação; construção de artefatos
de desenvolvimento e a revalidação de requisitos.
Para entender cada parte desses princípios de validação de requisitos, recomenda-se a

leitura das páginas 124-126, do livro Fundamentos da Engenharia de Requisitos de Pohl e
Rupp (2012).
80
É importante que os problemas detectados na fase da validação de requisitos
sejam tratados o mais rápido possível, principalmente identificando a causa principal
do erro. Quando o trabalho é realizado de forma preventiva, o erro é acertado onde
ele ocorreu e também em todas as outras partes da produção do software, inclusive
em outros projetos diferentes.
81
FIXANDO O CONTEÚDO
1. “A especificação de um requisito funcional de um sistema deve ser completa e

consistente” (SOMMERVILLE, 2007, p.81). Para que a especificação atinja os objetivos
de completude e consistência, os requisitos funcionais dependem:
I. do investimento da organização na elaboração do software.
II. do tipo de software que será desenvolvido.
III. do usuário para quem o software está sendo construído.
IV. do ambiente físico destinado para acomodação da equipe de trabalho.
V. da abordagem geral da organização ao redigir requisitos.
Estão corretos:
a) I, II, III, IV.
b) I, II e III.
c) II e III.
d) II, III e V.
e) III e IV.
2. “Durante o desenvolvimento do projeto, quanto mais tarde um defeito nos

requisitos for corrigido, mais altos serão os custos associados com sua correção”.
(POHL e RUPP, 2012, p. 28). A partir do trecho citado e em seus conhecimentos, analise
as afirmativas abaixo:
I. Realizar detalhamento de apenas partes do requisito, respeitando a organização
do projeto;
II. Evitar conflitos na elaboração de requisitos;
III. Elaborar requisitos que permitam teste e validação;
IV. Estabelecer uma relação de ambiguidade no sistema.
São considerados problemas na fase de elaboração de requisitos:
a) I, II, III, IV.
b) I, II e III.
c) II e III.
d) II, III e IV.
e) III e IV.
82
3. (CS-UFG – 2017 – Adaptado) Uma dimensão para a classificação de requisitos de
software é a distinção entre requisitos funcionais e não funcionais. É um exemplo de
requisito não funcional:
a) “A inclusão de um empregado não pode demorar mais de dois segundos”.
b) “Um empregado não pode ter salário superior ao do seu supervisor".
c) “Dois empregados não podem ter o mesmo salário”.
d) “A exclusão de um empregado resulta na exclusão de seus dependentes”.
e) “A exclusão de um empregado, inclui automaticamente o benefício de vale
transporte”.
4. (FUNDATEC - 2022) Algumas vezes, durante a fase de levantamento de requisitos, é

importante identificar como funções e características de um sistema serão usadas
por diferentes classes de usuários. Para tanto, pode-se utilizar um conjunto de
__________________ que identifique roteiros de uso para o sistema a ser construído.
Assinale a alternativa que preenche corretamente a lacuna do trecho acima.
a) cenários de uso.
b) protótipos.
c) modelos de domínio.
d) diagramas de comunicação.
e) modelos conceituais.
5. Leia o trecho a seguir e analise os itens:

“A elicitação de requisitos, é formada pelo conhecimento sobre o contexto do
sistema a ser desenvolvido obtido durante a engenharia de requisitos, que inclui as
fontes de requisitos a serem analisadas e investigadas” (POHL e RUPP (2012, p.47)
I. Prototipação.
II. Questionários.
III. Tarefas.
IV. Observações.
V. Modelos de domínio.
São exemplos de técnicas abordadas na elicitação de requisitos:
a) I, II, III, IV.
b) I, II e IV.
c) II e III.
83
d) II, III e IV.
e) III e IV.
6. (FGV - 2021 - TJ-RO) A especificação de software é o processo de compreensão e

definição dos serviços requisitados pelos usuários e Stakeholders que o sistema
deverá atender. Além disso, a especificação engloba quatro atividades básicas:
estudo de viabilidade, elicitação, especificação e validação de requisitos. Durante
a elicitação de requisitos, a analista de sistemas Ana fez a imersão no ambiente de
trabalho em que o sistema será utilizado e ficou observando o dia a dia para
compreender os processos operacionais e extrair os requisitos de apoio e implícitos.
Nesse caso, Ana utilizou a técnica de:
a) Prototipação.
b) etnografia.
c) entrevistas.
d) cenários.
e) casos de uso.
7. (CEFET-MG - 2021 - Adaptado) A engenharia de requisitos abrange sete tarefas

distintas: concepção, levantamento, elaboração, negociação, especificação,
validação e gestão.
Fonte: PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 8. Ed. Porto Alegre: AMGH, 2016.
Analise os itens:
I. A elaboração é guiada pela criação e pelo refinamento de cenários que
descrevem como o usuário (e outros atores) vão interagir com o sistema.
II. A negociação é o conjunto de atividades que ajuda a equipe de projeto a
identificar, controlar e acompanhar as necessidades e suas mudanças à
medida que o projeto prossegue.
III. A especificação pode ser um documento por escrito, um conjunto de modelos
gráficos, um modelo matemático formal, um conjunto de cenários de uso, um
protótipo ou qualquer combinação dos fatores citados.
IV. O levantamento define quais são os objetivos para o sistema ou produto, o
que deve ser obtido, como o sistema ou produto atende às necessidades da
empresa e, por fim, como o sistema ou produto deve ser utilizado no dia a dia.
V. A validação examina a especificação para garantir que todos os requisitos de
84
software tenham sido declarados de forma não ambígua, que inconsistências,
omissões e erros tenham sido detectados e corrigidos, e que os artefatos
estejam de acordo com os padrões estabelecidos para o processo, projeto e
produto.
Estão corretos:
a) I, III e IV.
b) I, II e IV.
c) I, III, IV e V.
d) II, III e IV.
e) III e IV.
8. O documento de requisitos, também denominado especificação de requisitos de

software ou SRS – Software Requiremenets Specification, é considerado a declaração
oficial que os desenvolvedores de sistema devem implementar. Nesse contexto, os
Stakeholders (parte interessada), são importantes elementos que fazem parte desse
documento (SOMMERVILLE, 2007)
Sobre os usuários do documento de requisitos é CORRETO afirmar que:
a) os gerentes são responsáveis pela especificação e leitura dos requisitos, para
verificarem se atendem as necessidades do projeto.
b) os clientes de sistema utilizam o documento de requisitos para planejar e entender
melhor a proposta do projeto.
c) o teste de validação do sistema é de responsabilidade dos engenheiros de
manutenção e dos usuários do sistema.
d) os engenheiros de testes utilizam os requisitos para compreender os
relacionamentos e as partes do projeto
e) os engenheiros de sistemas fazem uso dos requisitos para compreender qual
sistema será o mais adequado para ser utilizado.
85
INTRODUÇÃO AO ESTUDO DE UNIDADE
PROJETOS ORIENTADO A OBJETOS
(UML - UNIFIED MODELING
LANGUAGE)
05
5.1 VISÃO GERAL DA MODELAGEM ORIENTADA A OBJETOS
A Linguagem Orientada a Objetos – UML é uma linguagem de notação

utilizada em projetos de sistemas. Constitui-se de modelos construídos com objetivos
de auxiliar na estrutura e comportamento do sistema, visualizar e controlar a
arquitetura do sistema, compreender melhor o sistema que está sendo elaborado e
para gerenciar riscos.
Os autores Booch, Rumbaugh e Jacobson (2012), consideram alguns princípios
fundamentais na modelagem de dados em UML, são eles:
1. A escolha de modelos a serem criados tem profunda influência

sobre a maneira como um determinado problema é atacado e como
uma solução é definida (...) 2. Cada modelo poderá ser expresso em
diferentes níveis de precisão (...) 3. Os melhores modelos estão
relacionados à realidade (...) 4. Nenhum modelo único é suficiente (p.
8-10).
Há tempos atrás o desenvolvimento de softwares possuía uma visão

tradicional, centrada na perspectiva do algoritmo, atualmente, a visão
contemporânea adota a perspectiva orientada ao objeto, conforme é ilustrado na
figura 29.
86
Figura 29: Modelagem de dados
Fonte: Adaptado de Booch, Rumbaugh, e Jacobson (2005)
A orientação a objetos “é uma abordagem para desenvolvimento de software

que organiza os problemas e suas soluções como um conjunto de objetos distintos”
(PFLEEGER 2004, p. 210). Na Linguagem orientada a objetos – UML há um intenso
trabalho com atividades que envolvem a visualização, a especificação, a
construção e a documentação de artefatos, o que em termos gerais, auxiliam os
desenvolvedores no projeto de software.
O quadro 14 apresenta alguns conceitos comparativos em relação ao projeto,
análise e programação orientada a objetos.
Quadro 14: Projeto/Análise/Programação orientada a objetos

Análise Orientada a Concentra-se no desenvolvimento de um modelo orientado a
Objetos objetos do domínio da aplicação.
Projeto Orientado a Concentra-se no desenvolvimento de um modelo orientado
Objetos de um sistema de software para implementar os requisitos
identificados.
Programação Orientada a Concentra-se em realizar um projeto de software usando uma
Objetos linguagem de construções que definem classes de objeto e
um sistema de run-time para criar objetos a partir dessas
classes.
As alterações são mais fáceis de processar nos sistemas orientados por objetos
do que outras abordagens, por causa da independência dos próprios objetos. Na
seção seguinte serão abordados alguns conceitos fundamentais para a abordagem
87
orientada a objeto.
5.2 CLASSES, ATRIBUTOS E OPERAÇÕES
5.2.1 Classes
É considerada um dos itens mais importantes de qualquer sistema orientado a

objetos. Booch, Rumbaugh, e Jacobson (2005, p.49) conceituam classe como sendo
“uma descrição de um conjunto de objetos que compartilham os mesmos atributos,
operações, relacionamentos e semântica”. A classe está diretamente relacionada
com o objeto, que é definido como sendo “uma entidade que possui um estado e
um conjunto definido de operações definidas para funcionar nesse estado”
(SOMMERVILLE, 2007, p. 210). Para Pressman (2011, p. 745), a classe pode ser definida
como sendo “uma descrição generalizada que descreve uma coleção similar”, e
“objetos são instâncias de uma classe específica e herdam seus atributos e
propriedades disponíveis para manipular os atributos”.
Figura 30: Exemplos de Classe de objetos
Na figura 30 observam-se três classes, carros, pessoas e animais e os seguintes

objetos associados às classes: Honda, João e Coelho, respectivamente.
88
O nome de uma classe pode ser um texto composto por qualquer número de caracteres
e determinados sinais de pontuação (exceto alguns sinais, como os dois pontos, utilizados
para separar o nome da classe e o nome do pacote que a contém) e pode se estender
por várias linhas. Na prática os nomes das classes são substantivos ou expressões breves,
definidos a partir do vocabulário do sistema cuja modelagem está sendo feita.
Tipicamente, aparece como maiúsculo o primeiro caractere de cada palavra existente
no nome da classe Booch, Rumbaugh e Jacobson (2005, p.51).
5.2.2 Atributos
Tecnicamente, “um atributo é uma propriedade nomeada de uma classe que

descreve um intervalo de valores que as instâncias da propriedade podem
apresentar” BOOCH, RUMBAUGH, E JACOBSON (2005, p.52). Um atributo refere-se a
uma propriedade da classe, que poderá ter um, vários ou nenhum atributo.
Na figura 31, podemos enumerar alguns atributos para as classes carros,
animais e pessoas.
Figura 31: Exemplos de Atributos
A regra para os nomes de atributos seguem as mesmas regras descritas para
89
as classes de objeto, ou seja, o nome do atributo pode ser um texto. O nome é um
substantivo ou expressão que está diretamente relacionado com a classe
correspondente.
5.2.3 Operações
As operações são implementações de serviços que pode ser solicitado por

algum objeto da classe, com o objetivo de mudar o comportamento. “é uma
abstração de algo que pode ser feito com um objeto e que é compartilhado por
todos os objetos dessa classe” BOOCH, RUMBAUGH, E JACOBSON (2005, p. 53).
Na figura 32 está descrito algumas operações possíveis para as classes carros,
animais e pessoas.
Figura 32: Exemplos de Operações
90
Como podemos observar na figura 32, o nome das operações, tem como
regra ser um verbo ou locução verbal breve, representando a classe correspondente.
Na classe Carros, por exemplo, uma operação que será gerada é a de vender, ou
seja, todo carro estará disponível para venda. A UML “usa o termo operações para
definir a especificação de uma ação e o termo método para se referir a
implementação de uma operação” (SOMMERVILLE, 2007, p. 210).
Observe a figura 32, imagine mais dois objetos para cada classe, após essa inserção,
pense: é necessário alterar os atributos e operações após essa inclusão?
Uma relação importante entre as classes são as conexões estabelecidas entre

itens que as compõe, denominadas relacionamentos e a multiplicidade.
Graficamente um relacionamento é representado como um caminho, com tipos
diferentes de linhas para diferenciar os tipos de relacionamentos (BOOCH;
RUMBAUGH; JACOBSON 2005, p. 65). O quadro 15 apresenta informações em relação
aos tipos de relacionamentos em uma modelagem orientada a objetos.
Quadro 15: Relacionamentos em UML

Relacionamento Conceito Representação
Dependência Relacionamento estrutural que especifica
objetos de um item conectados a objetos de
outro item.
Agregação Significa que as duas classes estão em um
mesmo nível, sem que uma seja mais
importante que a outra.
Composição É um tipo de agregação, o todo é
responsável pela disposição de suas partes, o
objeto principal gerencia a criação e a
destruição de suas partes.
Generalização Objetos da classe-filha podem ser utilizados
em qualquer local em que a classe-mãe
ocorra, mas não vice-versa.
Associação É um relacionamento estrutural que
especifica objetos de um item conectados a
objetos de outro item.
Fonte: Adaptado de Booch, Rumbaugh e Jacobson (2005)
Complementado as informações do quadro 15 a imagem 33 apresenta

exemplos que envolvem os tipos de relacionamentos em projetos orientados à
91
objetos.
Figura 33: Exemplos de Relacionamentos em UML
No exemplo da figura 33, a dependência indica que a classe clipe depende

e usa informações da classe canal; na composição há uma relação existencial entre
a classe livro e classe capítulo, dessa forma um capítulo só existe porque existe um
livro; na agregação há uma relação não existencial, ou seja, indica que a estante
existe independente da existência do livro; na generalização a classe carros irá
herdar atributos da classe veículos e poderá ter os seus próprios atributos; e por último,
a associação, que indica que todo carro usa uma estrada, a qual não faz parte do
carro, mas ele depende dela.
Além dos relacionamentos entre as classes de objetos, a multiplicidade é outro
conceito importante nesse contexto. O objetivo da multiplicidade é especificar o
nível de dependência do objeto e determinar o número mínimo e o número máximo
de objetos envolvidos em uma associação. O quadro 16 ilustra a representação da
multiplicidade e o significado no contexto da UML.
92
Quadro 16: Significados de Multiplicidade
Multiplicidade Significado Relacionamento
0..1 No mínimo zero e no máximo um. Possui Não-Obrigatoriedade
(zero ou um) um relacionamento de não
obrigatoriedade.
1..1 ou 1 Um somente um. No relacionamento, Um objeto da classe se
(somente um) um objeto da classe se relaciona com relaciona com um objeto da
um objeto da outra. (Obrigatoriedade) outra.
0..* Ou * Mínimo nenhum e no máximo muitos -
(maior ou
igual a zero)
m..n Mínimo m e no máximo n. -
(sequência
especificada)
Alguns exemplos, relacionados no quadro 17, podem auxiliar no entendimento

do conceito sobre multiplicidade.
Quadro 17: Exemplos de conceitos de multiplicidade:

Representação - Exemplos Conceito
No relacionamento um funcionário tem
que obrigatoriamente estar associado a
um departamento, e, a um departamento
podem-se associar vários ou nenhum
funcionário.
Um cliente pode estar associado a
nenhuma ou várias notas fiscais, e, uma
nota fiscal está obrigatoriamente
associada a um e apenas a um cliente.
O relacionamento indica que um aluno
poderá se inscrever em várias disciplinas, e,
uma disciplina poderá ter vários alunos.
O relacionamento indica que um carro
poderá ter cinco pneus, e, que cinco pneus
compõem apenas um carro.
5.3 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE COM UML
Nos estudos sobre os vários métodos de processo de desenvolvimento de

software com UML, muitos autores concordam que não há um “melhor” método.
Para Pfleeger (2004) nenhuma forma de projetar foi feita para atender a todas as
situações, porém há um ponto, uma diretriz que poderá ser utilizada em todos os
sistemas: é preciso sempre projetar considerando possíveis mudanças, “não importa
qual o sistema que você está construindo, mais cedo ou mais tarde, você,
93
provavelmente, terá de modificá-lo” (p.235).
Pressman (2011) apresenta alguns conceitos importantes para o entendimento
dos processos de desenvolvimento software com UML. O quadro 18 ilustra o resumo
desses conceitos.
Quadro 18: Conceitos – Projetos UML

Conceito Descrição
Herança Um dos diferenciadores-chave entre sistemas convencionais e orientados a
objeto. Uma subclasse Y herda todos os atributos e operações associadas a
sua superclasse X.
Mensagens As classes devem interagir umas com as outras para atingir os objetivos do
projeto. Uma mensagem estimula a ocorrência de algum comportamento
no objeto receptor.
Polimorfismo Característica que reduz bastante o esforço necessário para ampliar o
projeto de um sistema orientado a objeto.
Classes de O modelo de requisitos define um conjunto completo de classes de análise.
Projeto Cada uma descreve algum elemento do domínio do problema, focalizando
os aspectos visíveis ao usuário ou ao cliente.
Completa e Uma classe de projeto deverá ser o encapsulamento completo de todos os
suficiente. atributos e métodos requeridos a uma classe
Primitivismo Os métodos associados a uma classe de projeto devem se concentrar na
execução de uma função específica para a classe. Uma vez que a função
tenha sido implementada com um método, a classe não deve proporcionar
nenhuma outra maneira de fazê-lo.
Alta coesão Uma classe de projeto coesa é limitada. Ela tem um conjunto de
responsabilidades pequeno e concentrado e aplica de forma simples
atributos e métodos para implementar aquelas responsabilidades.
Baixo No modelo de projeto, é necessário que as classes de projeto colaborem
acoplamento umas com as outras. No entanto, a colaboração deverá ser mantida em um
nível mínimo aceitável.
Fonte: Adaptado de Pressman (2011)
É importante considerar que existem várias técnicas nos projetos com

orientação a objetos, que o torna mais dinâmico, um sistema aberto a mudanças e
de fácil manutenção. Serão utilizados os pressupostos de Sommerville (2007),
referente aos cinco estágios fundamentais no processo geral de projeto de software
com UML.
5.3.1 Contexto de sistema e modelos de uso
Nesse estágio desenvolve-se uma compreensão em relação às associações

estabelecidas entre o projeto e o ambiente externo. Há dois modelos
complementares de relacionamento entre sistema e ambiente: o primeiro refere-se
94
ao fato de que o contexto do sistema é um modelo estático que descreve os outros
sistemas nesse ambiente. O segundo refere-se ao modelo de uso de sistema é um
modelo dinâmico que descreve como o sistema realmente interage com seu
ambiente (SOMMERVILLE, 2007, p.215).
A figura 34 ilustra um exemplo fictício da empresa X em relação ao contexto
de sistemas e modelos de uso.
Figura 34: Exemplo de contexto de sistema e modelos de uso
A figura 34 representa uma parte de um sistema, com associações em um

diagrama simples de bloco, mostrando as relações estabelecidas entre empregado,
coordenador e setor de trabalho de uma empresa.
5.3.2 Projeto de arquitetura
No estágio do contexto de sistema e modelos de uso foram definidas

interações entre o sistema, essas informações e os conhecimentos sobre os princípios
de projeto de arquitetura são fundamentais para o desenvolvimento do projeto de
arquitetura. Nesse estágio o sistema deverá ser decomposto em arquiteturas o mais
simples possível. “Não deve haver mais do que sete entidades fundamentais em um
modelo de arquitetura. Cada uma dessas entidades pode ser descrita
separadamente” (SOMMERVILLE, 2007, p.216).
A figura 35 ilustra um exemplo do projeto de arquitetura.
95
Figura 35: Exemplo de um diagrama simples de parte do projeto de arquitetura de um
sistema
O exemplo exibido na figura 35 é simples, descreve um nível razoável de

informações. Note que o mais importante para esse estágio é que os dados e
informações do diagrama precisam ser relevantes para o nível de abstração
correspondente.
5.3.3 Identificação dos objetos principais do sistema
O ponto principal desse estágio é a identificação dos objetos do sistema

projetado, consequentemente a caracterização das classes dos objetos tornar-se
elemento essencial. Sommerville (2007, p. 217) aponta algumas abordagens que
auxiliam nessa identificação:
1. Usar uma análise gramatical de uma descrição em linguagem

natural de um sistema; 2. Usar entidades tangíveis (coisas); 3. Usar uma
abordagem comportamental, na qual o projetista compreende
primeiro o comportamento geral do sistema. 4. Usar análise baseada
em cenários, na qual diversos cenários de uso do sistema são
analisados um de cada vez.
A figura 32 da seção 5.2.3 desse livro, é um bom exemplo de identificação dos

objetos do sistema, na figura são identificados a estrutura de classes de objetos
caracterizando os objetos e as operações a serem realizadas no sistema.
96
Com base na estrutura da figura 32, e nos elementos da figura 35, pense e escreva as
classes, objetos e operações no diagrama exibido para a empresa X da figura 34.
5.3.4 Modelo de projetos
Nesse estágio o objetivo é desenvolver modelos de projetos que possam exibir

os objetos, classes, entidades e relacionamentos do sistema. De acordo com
Sommerville (2007), os modelos de projetos podem ser considerados como a ponte
principal entre requisitos e implementação do sistema. Para o autor podemos citar
dois tipos de modelos de projetos, os quais estão descritos no quadro 19.
Quadro 19: Tipos de modelos de projeto

Tipo de modelo Descrição
Modelo Estático Descrevem a estrutura estática do sistema usando classes de objetos e
seus relacionamentos. A generalização (utiliza, é utilizado por) e a
composição são muito utilizadas nesse estágio.
Modelo Dinâmico Descrevem a estrutura dinâmica do sistema e mostram as interações
entre objetos de sistema. As interações que podem ser documentadas
incluem a sequência de solicitações de serviço feitas pelos objetos e o
modo como o estado do sistema está relacionado a essas interações
do objeto.
Fonte: Adaptado de Sommerville (2007).
A UML possui 12 modelos estáticos e dinâmicos, esses modelos serão tratados
na unidade 6, quando forem abordados os diagramas da UML.
5.3.5 Especificar interfaces de objetos
As interfaces estão diretamente relacionadas com a implementação de

elementos, a partir de modelos, pelas classes ou componentes. As interfaces podem
ser utilizadas nos diagramas de classe e componentes.
Esse estágio é considerado uma importante parte do projeto, tendo em vista
que após a especificação da interface, o desenvolvedor de outros objetos supõe
que ela já poderá ser implementada. O projeto de interface de objeto: “dedica-se a
especificação de detalhes de interface de um objeto ou um grupo de objetos. Isso
significa definir assinaturas e a semântica dos serviços fornecidos pelo objeto ou por
um grupo de objetos” (SOMMERVILLE, 2007, p. 221).
97
 Para saber um pouco mais sobre os processos de projeto orientado a objetos,
recomenda-se a leitura das páginas 213-223 do livro “Engenharia de software” do
autor Ian Sommerville (2007), páginas 77-94. O livro está disponível na biblioteca
virtual, no link: https://abrir.link/slcpS. Acesso em: 20 jan. 2023.
 Outra leitura recomenda é das páginas 221-233 do livro “Engenharia de software:

Teoria e prática” de S.L. PFLEEGER. O livro está disponível na biblioteca virtual, no
link: https://abrir.link/6psg0. Acesso em: 20 jan. 2023.
98
FIXANDO O CONTEÚDO
1. Você poderá especificar um (a) _______________ utilizando sua assinatura, que

contém o nome, tipo e o valor-padrão de todos os parâmetros e o tipo a ser
retornado. Geralmente o nome é um verbo ou uma locução verbal breve.
O conceito que completa a frase acima é:
a) classe.
b) atributo.
c) operações.
d) relacionamento.
e) diagrama.
2. Observe a figura:
Em relação à figura é CORRETO afirmar que:

a) há uma ligação indicando que a classe terapia irá herdar atributos da classe
paciente.
b) A classe sessão só existe porque há uma ligação forte com a classe terapia
aumentada.
c) A ligação entre a classe paciente e classe terapia informa que se a classe terapia
for excluída, a classe paciente continua a existir.
d) Se a classe avaliação for excluída, a classe Terapia deixa de existir.
e) Todos os atributos da classe sessão serão herdados pela classe terapia.
3. “É um conceito orientado a objeto que encapsulam dados e abstrações
procedurais necessárias para descrever o conteúdo e comportamento de alguma
99
entidade do mundo real” (PRESSMANN, 2011, P. 745). O conceito acima se refere
à:
a) classe.
b) objeto.
c) atributo.
d) requisito.
e) herança.
4. “A modelagem é uma parte central de todas as atividades que levam a

implantação de um bom software. Construímos modelos para comunicar a
estrutura e o comportamento desejado do sistema” (BOOCH; RUMBAUGH;
JACOBSON, 2004, p. 3-4).
Sobre a modelagem orientada a objetos analise as proposições abaixo:
I. A implementação de classes e relacionamentos teve seu início a partir da
implantação do algoritmo.
II. A realidade é um indicativo para a produção de bons modelos de software.
III. Na UML, cada modelo poderá ser expresso em diferentes níveis de precisão.
IV. O procedimento E a função estão diretamente relacionados ao
desenvolvimento orientado a objetos.
Estão corretos:
a) I, II, III e IV.
b) I, II e IV.
c) II, III e IV.
d) II e III.
e) III e IV.
5. As classes devem interagir umas com as outras para atingir os objetivos do projeto,
dessa forma há ações importantes que estimula a ocorrência de algum
comportamento no objeto receptor. O comportamento ocorre quando uma
operação é executada.
O texto acima se refere a:
a) Mensagem.
b) Polimorfismo.
c) Classes de projeto.
100
d) Primitivismo.
e) Herança.
6. Na visão de SOMMERVILLE (2007) nos processos de desenvolvimento de software

com UML. Marque a opção CORRETA.
a) Na fase de especificação de interface o objeto modelo de arquitetura é definido
no nível mais simples possível.
b) As ações de entendimento do comportamento do sistema e o uso da abordagem
comportamental são realizados na fase de identificação dos objetos do sistema.
c) A fase do projeto de arquitetura está diretamente relacionada com o
levantamento de dados sobre sistema para a realização do desenho final.
d) A definição dos objetos, classes, entidades e relacionamentos do sistema são
elaborados na fase do modelo e contexto de usos.
e) É necessário definir os modelos de projetos antes da identificação das classes e
objetos do projeto.
7. É usada para definir o número mínimo e máximo de objetos envolvidos em

associação nos relacionamentos entre objetos. Outra função refere-se á
capacidade de especificar o nível de dependência entre os objetos. O conceito
acima se refere a:
a) Generalização.
b) Associação.
c) Composição.
d) Função.
e) Multiplicidade.
101
8. Observe as imagens e analise as proposições a seguir:
I. Na figura 1, temos uma relação de dependência, a qual indica que se a classe

roda for apagada, a classe carro deixará de existir.
II. Na figura 2, o relacionamento indica que se a classe funcionário for excluída
a classe departamento continuará a existir.
III. Na figura 3, temos a representação de uma herança entre as classes, ou seja,
a classe macaco herda atributos e operações da classe animal, excluindo seus
atributos e operações.
IV. Na figura 2, a multiplicidade indica que um departamento poderá ter vários
funcionários.
V. Os relacionamentos representados nas figuras são: dependência na figura 1,
agregação na figura 2 e generalização na figura 3.
Estão corretos:
b) I, II, IV e V.
c) II, IV e V.
d) II, III, IV e V.
e) III e V.
102
MODELAGEM BÁSICA: UNIDADE
DIAGRAMAS UML
6.1 CONCEITOS E MODELOS

06
O termo modelagem vem do verbo modelar, que significa uma ação de fazer
um molde de uma peça, um modelo. Na UML a modelagem refere-se à linguagem
utilizada para modelar as diversas fases do desenvolvimento de sistema em UML.
Alguns conceitos importantes para um melhor entendimento sobre a
modelagem básica em UML estão descritos no quadro 20.
Quadro 20: Conceitos – Modelagem básica em UML

Sistema Coleção de subsistemas organizados para a realização de um objetivo e
descritos por um conjunto de modelos, possivelmente sob diferentes pontos
de vista.
Subsistema Agrupamento de elementos, alguns dos quais constituem uma
especificação do comportamento proporcionado pelos outros elementos
contidos.
Modelos É uma abstração semanticamente fechada de um sistema, o que significa
que representa uma simplificação autoconsistente e completa da
realidade, criada com a finalidade de permitir uma melhor compreensão a
respeito do sistema.
Visão No contexto da arquitetura, uma projeção da organização e da estrutura
do modelo de um sistema, cujo foco está voltado para um único aspecto
desse sistema.
Diagramas É a apresentação gráfica de um conjunto de elementos, geralmente
representada como um gráfico conectado de itens e relacionamentos.
O uso de diagramas em sistemas de software na perspectiva da UML tem

como objetivo a organização dos elementos mais importantes, a exibição de uma
visão clara do sistema e o auxílio na comunicação da equipe e todas as partes
envolvidas no projeto, buscando, dessa forma, evitar erros na fase de especificação.
Optou-se para uso nesse livro da classificação dos tipos de diagramas
(estruturais e comportamentais), de acordo com as concepções Booch, Rumbaugh
e Jacobson (2005, p. 95), considerados os próprios criadores da linguagem UML. Para
os autores “cada diagrama oferece uma visão acerca dos elementos que forma o
sistema”. Alguns pressupostos serão complementados por Fowler (2004).
A figura 36 ilustra uma visão geral da classificação dos diagramas na visão dos
autores.
103
Figura 36: Estrutura de diagramas UML
Na seção 6.2 e 6.3 serão abordados os principais tipos de diagramas estruturais

e comportamentais em UML.
6.2 DIAGRAMAS ESTRUTURAIS
Os diagramas estruturais da UML estão diretamente ligados aos aspectos

estáticos de um sistema, tendo como objetivo, visualizar, especificar, construir e
documentá-los.
De acordo com Booch, Rumbaugh, e Jacobson (2005):
Assim como os aspectos estáticos de uma casa incluem a existência

e a colocação de itens como paredes, portas, janelas, canos, fios e
respiradouros, também os aspectos estáticos de um sistema de
software abrangem a existência e a colocação de itens como classes
interfaces colaborações, componentes e nós (p.96).
A figura 37 ilustra de uma forma geral na visão dos autores, a classificação dos
diagramas estruturais.
104
Figura 37: Tipos de diagramas estruturais da UML
Nas seções seguintes serão abordados dois diagramas estruturais muito

utilizados na UML: diagramas de classe e diagrama de objetos.
6.2.1 Diagrama de Classes
Considerado um dos diagramas mais utilizados em sistema de modelagem

orientada a objetos, suas funções estão diretamente relacionadas com a exibição
de classes, interfaces, colaborações e relacionamentos. Para Fowler (2004, p. 52):
Um diagrama de classes descreve os tipos de objetos presentes no

sistema e os vários tipos de relacionamentos estáticos existentes entre
eles. Os diagramas de classes também mostram as propriedades e as
operações de uma classe e as restrições que se aplicam à maneira
como os objetos estão conectados.
Os diagramas de classe são utilizados para o suporte aos requisitos funcionais

de um sistema, fornecendo uma visão dos serviços que serão apresentados aos
usuários finais. Um diferencial dos diagramas de classe para os demais diagramas é
o seu conteúdo particular.
Observe na figura 38, a visão da estrutura, dos dados e informações
apresentados no diagrama de classes.
105
Figura 38: Exemplo de um diagrama de classes
Tendo como base a figura 31, que ilustra os “relacionamentos em UML” e também tendo
como referência a atividade reflexiva proposta na seção 5.3.3 desse livro, analise a figura
36 e pense: quais as classes, objetos, atributos e operações do sistema? Por que há um
relacionamento de composição entre a classe “Empresa ABC” e “Departamento de
pessoal” e “Filial”? E a relação de dependência apresentada na figura, o que significa?
O que podemos dizer sobre relacionamento entre matriz e filial?
Em geral, ao elaborar um diagrama de classes, conforme ilustrado na figura

38, alguns detalhes são importantes:
É preciso evitar o cruzamento de linhas na distribuição dos elementos, deixar
próximos os elementos a partir de sua semântica, usar o recurso de cores e notas
para marcar pontos e chamar a atenção no diagrama e minimizar a quantidade de
relacionamentos, lembrando que um único tipo de relacionamento tenderá a
predominar em um diagrama de classe (BOOCH; RUMBAUGH; JACOBSON 2005,
106
p.118).
6.2.2 Diagrama de Objetos
De acordo com Booch, Rumbaugh, e Jacobson (2005, p. 190-191), um

diagrama de objetos “mostra um conjunto de objetos e seus relacionamentos em um
ponto do tempo”. É utilizado na modelagem da visão de projeto e processo estático
do sistema, como é realizado no diagrama de classes, porém com um nível de
detalhamento maior, ou seja, a partir da perspectiva de instâncias reais ou
prototípicas.
O diagrama de objetos pode ser denominado também como diagrama de
instâncias, uma vez que exibe as instâncias (os objetos em si) ao invés de classes.
A figura 39 ilustra um exemplo do detalhamento do diagrama de objetos.
Figura 39: Relações entre diagrama de classe e diagrama de objetos
Fonte: Fowler (2004, p. 95).
Na figura 39 Fowler (2004) mostra primeiramente o diagrama de classes da

estrutura de uma festa, na sequência é ilustrado o diagrama de objetos, mostrando
as relações de instancias do diagrama. Observe o detalhamento na descrição das
instancias específicas derivadas do diagrama de classes, em relação ao responsável
107
pela organização e sua localização.
De acordo com Booch, Rumbaugh, e Jacobson (2005, p.194), um diagrama
de objetos bem-estruturado apresenta, dentre outros itens, um:
foco voltado para comunicar um único aspecto da visão estática, de

projeto ou de processo, do sistema. [...] Fornece detalhes consistentes
com seu nível de abstração; você deverá expor apenas os valores de
atributo e outros adornos que sejam essenciais para a compreensão.
A propriedade de fazer a modelagem da visão estática de um projeto, ou seja,

estudar os objetos e seus relacionamentos a partir do congelamento de uma parte
desse projeto auxilia em uma melhor compreensão da visualização, especificação e
documentação dos modelos estruturais, além de ajudar também na construção de
aspectos estáticos dos sistemas.
Por se tratar de uma disciplina introdutória de engenharia de software, foram abordados

nesse livro apenas dois diagramas estruturais, para entender sobre os outros diagramas
estruturais citados na figura 34, recomenda-se a leitura cap. 13 (Estruturas compostas), e
cap. 14 (diagramas de componentes) do livro: “UML Essencial” de Martin Flower (2004). O
livro está disponível na biblioteca virtual, no endereço eletrônico: https://abrir.link/zFIiD.
Para os diagramas de artefatos e implantação, recomenda-se a leitura do cap. 30 e cap.
31, respectivamente do livro: “UML: Guia do usuário” de Booch, Rumbaugh, e Jacobson
(2005).
6.3 DIAGRAMAS COMPORTAMENTAIS
Os diagramas comportamentais estão diretamente relacionados com as

partes do sistema que sofrem alterações, ou seja, são utilizados para visualizar,
especificar, construir e documentar os aspectos dinâmicos de um sistema.
A figura 40 ilustra uma visão geral dos principais tipos de diagramas
comportamentais na visão de Booch, Rumbaugh, e Jacobson (2005).
108
Figura 40: Tipos de diagramas Comportamentais da UML
Nas seções seguintes serão abordados três diagramas comportamentais

utilizados na UML: diagramas de caso de uso, diagrama de atividades e diagramas
de interação.
6.3.1 Diagrama de Caso de Uso
Um caso de uso pode ser definido “como sendo uma descrição de um

conjunto de sequência de ações, inclusive variantes, que um sistema executa para
produzir um resultado de valor observável por um ator”. BOOCH, RUMBAUGH, E
JACOBSON (2005, p.230). Para os autores três conceitos são importantes no contexto
dos casos de uso: os atores, que são classificados como um conjunto de papeis
desempenhado por usuários na interação com o caso de uso; o assunto, considerado
uma classe descrita no conjunto de casos de usos; e os nomes, os quais devem ser
diferenciados entre si no contexto dos casos de usos. Todos esses elementos,
juntamente com os relacionamentos são exibidos nos diagrama de casos de uso.
Antes da elaboração do diagrama de casos de uso, duas perguntas,
conforme descreve Fowler (2004, p. 107), são importantes, são elas: “Quais atores
realizam quais casos de uso? Quais casos de uso incluem outros casos de uso?”.
A figura 41 mostra um exemplo de diagrama de caso de uso na visão do autor.
109
Figura 41: Exemplo de diagrama de caso de uso
Fonte: Fowler (2004, p.107)
Na figura 41, estão descritos os atores, relacionamentos e classes do diagrama

de casos de uso. No exemplo, “Analisar riscos” é considerado um caso de uso e
“gerente” um ator; em uma das interações podemos dizer que o gerente é
responsável pela análise de riscos do sistema, além de outras tarefas. O usuário
responsável pelo sistema de contabilidade é responsável pela atualização de contas.
Alguns relacionamentos se destacam nos diagramas de casos de uso:
1. Include, (inclusão) se um caso de uso X “inclui” o caso de uso Y, significa
que toda vez que o caso de uso X for executado o caso de uso Y
também o será.
2. Extend, (Extensão) se um caso de uso X “estende” o caso de uso Y,
significa que toda vez que o caso de uso X ocorrer, o caso de uso Y
poderá ser executado.
3. Generalization, (Generalização), se um caso de uso X “generaliza” o
caso de uso Y, significa que além de executar tudo que em X está
especificado, executará tudo que está especificado em Y também.
110
Figura 42: Exemplo de relacionamentos em diagramas de caso de uso
Na figura 42, o relacionamento include indica que, ao executar o caso de uso

“solicitar material”, obrigatoriamente a classe de uso “verificar estoque” deverá ser
verificada, ou seja, ao pedir material o estoque deverá ser consultado. O
relacionamento extend, mostra que ao solicitar material a compra poderá ou não
ocorrer, isso porque ao executar a classe “solicitar material”, o estoque poderá
indicar que há material suficiente e a compra não precisa ser realizada. O
relacionamento de generalização no exemplo da figura 42 indica que existe na
classe “Emitir pedido de compra” uma especificação para todo o sistema de como
se realiza o pedido de compra em qualquer área da empresa e não somente no
contexto do almoxarifado.
111
Imagine um sistema de solicitação de documentação para um determinado órgão
governamental. A partir dos itens citados abaixo, pense e faça um rascunho de como
seria o diagrama de caso de uso.
• O usuário precisa realizar um cadastro no sistema.
• Para solicitar o acesso à relação de possibilidades de solicitações de documentos, e

obrigatório ao usuário o login e senha.
• Na tela de consulta da lista de solicitações de pedidos, o usuário poderá ou não

realizar a sua solicitação.
• Se o usuário realizar o pedido da documentação e obrigatório o pagamento do valor

do documento.
No diagrama de caso de usos é importante exibir somente os casos de usos e

atores que são importantes para a compreensão de parte do sistema ou de um
sistema completo.
6.3.2 Diagrama de Atividades
Por ser um subtipo dos diagramas comportamentais os diagramas de

atividades são utilizados para a modelagem de aspectos dinâmicos do sistema. De
acordo com Fowler (2004, p. 118), os diagramas de atividades:
são uma técnica para descrever lógica de procedimento, processo

de negócio e fluxo de trabalho. De várias formas, eles desempenham
um papel semelhante aos fluxogramas, mas a principal diferença
entre eles e a notação de fluxograma é que os diagramas suportam
comportamento paralelo.
Para Booch, Rumbaugh e Jacobson (2005, p. 270). O diagrama de atividades

está diretamente relacionado à exibição do fluxo de uma atividade para outra. A
figura 43 ilustra um exemplo simples do diagrama de atividades, apresentando vários
elementos que compõe esse diagrama.
112
Figura 43: Exemplo de diagrama de atividades.
Fonte: Fowler (2004, p.107)
O quadro 21 detalha elementos do diagrama de atividades e seus conceitos

técnicos.
113
Quadro 21: Conceitos envolvidos no diagrama de atividades
Elementos Conceito/função
Ações Criar uma operação, enviar um sinal, criar ou destruir um objeto.
Nó de Unidade organizacional dentro de uma atividade. Grupos de ações
atividade aninhados ou outros nós de atividades aninhados.
Fluxos Quando uma ação ou nó de atividade está completo, o fluxo de controle
passa imediatamente a próxima ação ou nó de atividade.
Ramificações Caminhos alternativos, tomados como base alguma expressão booleana.
Valores de Representa o fluxo de um valor de objeto de uma ação para outra.
objetos
Nos diagramas de atividades não são possíveis especificar detalhes dos

objetos no próprio diagrama, dessa forma o diagrama de atividades é decomposto
em outras partes com o objetivo de uma melhor visualização e documentação dos
detalhes do projeto.
A figura 43 ilustra o processo de uma ação “entregar pedido” decomposta
como subatividade. Note que o símbolo do ancinho indica a decomposição da
ação, gerando um diagrama de atividade auxiliar. A ação decomposta na figura é
a “Entregar pedido”.
Figura 43: Decomposição de uma ação – Diagrama de atividades
Fonte: Adaptado de Fowler (2004, p.121).
Os diagramas de atividades podem ser divididos também em partições. As

partições organizam a informação e mostram quais ações uma classe ou unidade
da organização realiza a execução. A figura 44 ilustra um recorte de um diagrama
de atividades mostrando três partições: Execução, Serviços de atendimento ao
cliente e Departamento financeiro.
114
Figura 44: Recorte de um Diagrama de atividades exibindo as partições
Fonte: Adaptado de Fowler (2004, p.122).
Para Fowler (2004, p. 128), “a maior qualidade dos diagramas de atividades

está no fato de que eles suportam e estimulam o comportamento paralelo. Isso os
torna uma excelente ferramenta para modelagem de fluxos de trabalho e de
processos”.
6.3.3 Diagramas de interação
Um diagrama de interação mostra uma interação, formada por um conjunto

de objetos e seus relacionamentos, incluindo as mensagens que poderão ser
enviadas entre eles. (BOOCH; RUMBAUGH; JACOBSON, 2005, p. 251). Estão
diretamente relacionados com a modelagem de aspectos dinâmicos do sistema. Os
diagramas de sequência e os diagramas de comunicação também são diagramas
de interação.
Diagramas de sequência estão diretamente relacionados com a ordem
temporal das mensagens, já o diagrama de comunicação tem relação direta com
o envio e recebimento de mensagens. Um dos pontos fortes do diagrama de
sequência é a exibição detalhada e com clareza da sequência e ordem temporal
das mensagens e o diagrama de comunicação apresenta como ponto forte uma
economia de espaço, tendo em vista a sua capacidade de adicionar novos objetos
em duas dimensões. Como ponto fraco o diagrama de sequência apresenta um
elevado consumo de espaço por causa da inserção de modelos novos na estrutura,
no diagrama de comunicação é mais difícil de visualizar as mensagens e o diagrama
115
apresenta também menos opções de notação.
Nessa seção será descrito como exemplo do diagrama de interação, o
diagrama de comunicação.
 Diagramas de comunicação
O diagrama de comunicação, também conhecido como diagramas de
colaboração, tem como objetivo enfatizar “os vínculos de dados entre os vários
participantes na interação”, exibem vínculos que são instâncias de associações e
vínculos transitórios, que surgem somente no contexto da interação (FOWLER, 2004,
P.129).
A figura 45 e 46 ilustram diagramas completos de comunicação, para controle
centralizado e com numeração decimal aninhada, respectivamente. Observem que
na representação é possível verificar como os participantes estão vinculados,
inclusive os vínculos transitórios, que aparecem somente no momento da interação.
Importante destacar que os diagramas para controle centralizado não são válidos
para a linguagem UML (FOWLER, 2004, P.129). Se a especificação exigir uma notação
em linguagem UML oficial, deverá ser utilizado o diagrama com numeração decimal
alinhada (figura 46).
Figura 45: Diagrama de comunicação para controle centralizado
Fonte: Fowler (2004, p.122).
116
Figura 46: Diagrama de Comunicação com numeração decimal aninhada
Fonte: Fowler (2004, p.122).
De acordo com Fowler, (2004, p. 130), os diagramas de comunicação:
Não têm qualquer notação precisa para lógica de controle. Eles

permitem que você use marcadores de iteração e sentinelas, mas não
permitem especificar totalmente a lógica de controle. Não há
nenhuma notação especial para criar ou destruir objetos, mas as
palavras-chave «create» e «delete» são convenções comuns.
Os diagramas de comunicação são muito utilizados quando o desenvolvedor

quer destacar os vínculos, porém seu uso é uma questão mais pessoal, se comparado
com o diagrama de sequência.
Por se tratar de uma disciplina introdutória de engenharia de software, foram abordados

apenas três diagramas comportamentais, para entender os outros diagramas estruturais,
citados na figura 37, recomenda-se a leitura do cap. 4 (diagramas de sequência) e cap.
10 (gráfico de estados), do livro: “UML Essencial” de Martin Flower (2004). O livro está
disponível na biblioteca virtual, no endereço eletrônico: https://abrir.link/zFIiD. Acesso em:
20 jan. 2023.
117
FIXANDO O CONTEÚDO
1. (TCE-AM – 2021) A Unified Modeling Language (UML) é uma especificação que

define uma linguagem gráfica para visualizar, especificar, construir e documentar os
artefatos de sistemas. A equipe de Tecnologia da Informação (TI) de um tribunal de
contas estadual decidiu utilizar Casos de Uso para modelar os requisitos de um sistema
em UML.
Sobre os Casos de Uso especificados em UML, é CORRETO afirmar que:
a) descrevem o comportamento do sistema sem referenciar sua estrutura interna;
b) o comportamento básico pode incluir variações, eliminando comportamentos
atinentes ao tratamento de erros;
c) "extend" e "include" são tipos especiais de casos de uso contendo lógicas de
comportamento;
d) os detalhes sobre os comportamentos de um caso de uso podem ser
especificados em diagramas de classes em uml;
e) casos de uso estendidos representam reuso de comportamentos.
2. Sobre os diagramas UML, analise as proposições abaixo:

I. Os diagramas estruturais estão diretamente associados aos aspectos
dinâmicos do sistema, como é o caso do diagrama de classes.
II. Nos diagramas de caso de uso, três conceitos são fundamentais: Atores,
assuntos e nomes.
III. Um exemplo de diagrama comportamental é o diagrama de atividades, que
visualiza a lógica de procedimento, processo de negócio e fluxo de trabalho.
IV. Uma das funções do diagrama de classe é dar suporte aos requisitos funcionais
e não funcionais de um sistema.
V. O nome dos diagramas refletem suas funções, por exemplo, o diagrama de
objetos irá trabalhar com objetos, o diagrama de comunicação, com o envio
e recebimento de mensagens.
Estão corretos:
b) I, II, IV e V.
c) II, IV e V.
d) II, III, IV e V.
e) II, III e V.
118
3. (TJ-MG 2021 - ADAPTADO) O Diagrama de Casos de Uso é um dos Diagramas
Comportamentais da UML (Unified Modeling Language – Linguagem de Modelagem
Unificada), contendo três elementos principais; assinale-os.
a) Ações; Evento; e, Linhas de vida.
b) Transições; Atividades; e, Ações.
c) Linhas de vida; Mensagens; e, Atores.
d) Atores; Casos de uso; e, Relacionamentos.
e) Atores; Atividades; e, Transições
4. Marcelo precisa apresentar seu projeto para o arquiteto de aplicações da sua

equipe e para isso precisa documentá-lo utilizando a UML. Assinale a alternativa
correta para qual diagrama de interação Marcelo terá que apresentar para ilustrar
e enfatizar o envio e recebimento de mensagens.
a) Diagrama de Comunicação.
b) Diagrama de Sequência.
c) Diagrama de Atividades.
d) Diagrama de Caso de Uso.
e) Diagrama de Gráficos de Estados.
5. (TCE-AM – 2021) A figura abaixo apresenta um Diagrama de Classe em UML 2.5.1.
Com base nas classes e relacionamentos modelados, é correto afirmar que a(s):
119
a) classe G realiza a classe B;
b) classes B, C e D formam um GeneralizationSet;
c) classe F tem uma associação indireta com a classe A;
d) classe G depende da classe B para relacionar-se com a classe F;
e) classe E tem responsabilidade pela existência e armazenamento da classe F.
6. ______________ é uma abstração semanticamente fechada de um sistema, o que

significa que representa uma simplificação autoconsistente e completa da realidade,
criada com a finalidade de permitir uma melhor compreensão a respeito do sistema.
A palavra que completa a frase acima é:
a) Diagrama.
b) Visão.
c) Sistema.
d) Modelo.
e) Subsistema.
7. Observe a figura:
Fonte: Elaborada pelo autor
Sobre os relacionamentos nos diagramas de caso de uso, analise as proposições

abaixo:
I. O caso de uso A inclui o caso de uso B, toda vez que A for executado, B
também será executado.
II. a relação entre o caso uso A e o caso de uso C, informa que se A for
executado não necessariamente C o será.
III. O relacionamento citado entre B e D, indica que quando o caso de uso B for
120
executado, suas atividades serão realizadas e as atividades de D não serão
realizadas.
Está (ão) correto (s):
a) I, II e III.
b) I e II.
c) II e III.
d) Somente I.
e) Somente II.
8. (UERJ – 2021 – ADAPTADO) Considerando a utilização do conceito da UML em

relação ao diagrama da atividade, é CORRETO afirmar que:
A) ilustra a visão estática do projeto de um sistema, sendo importante não só para a
visualização, especificação e documentação de modelos estruturais, mas também
serve como apoio para a construção de sistemas executáveis por intermédio de
engenharia direta e reversa.
B) é semelhante a um diagrama de contexto, sendo utilizado para compreender
rapidamente quais são os atores externos de um sistema e as maneiras principais,
segundo as quais eles o utilizam.
C) é um tipo de diagrama de interação que ilustra as interações com mensagens
entre instâncias (e classes) no modelo de classes, em forma de grafo ou rede.
D) complementa o caso de uso por meio de uma representação gráfica do fluxo de
interação em um cenário específico.
E) Nos diagramas de atividades há possibilidades de especificar detalhes dos objetos
no próprio diagrama.
121
RESPOSTAS DO FIXANDO O CONTEÚDO
UNIDADE 01 UNIDADE 02
QUESTÃO 1 C QUESTÃO 1 C
QUESTÃO 2 D QUESTÃO 2 A
QUESTÃO 3 B QUESTÃO 3 C
QUESTÃO 4 E QUESTÃO 4 C
QUESTÃO 5 A QUESTÃO 5 E
QUESTÃO 6 E QUESTÃO 6 A
QUESTÃO 8 E QUESTÃO 8 D
QUESTÃO 1 C QUESTÃO 1 D
QUESTÃO 3 A QUESTÃO 3 A
QUESTÃO 4 A QUESTÃO 4 A
QUESTÃO 5 C QUESTÃO 5 B
QUESTÃO 6 C QUESTÃO 6 B
QUESTÃO 8 B QUESTÃO 8 E
QUESTÃO 1 C QUESTÃO 1 A
QUESTÃO 2 C QUESTÃO 2 E
QUESTÃO 3 A QUESTÃO 3 D
QUESTÃO 5 A QUESTÃO 5 E
QUESTÃO 6 B QUESTÃO 6 D
QUESTÃO 7 E QUESTÃO 7 B
QUESTÃO 8 C QUESTÃO 8 D
122
REFERÊNCIAS
ARLOW, J. NEUSTADT, I. UML and the unified process, addison-Wesley, 2002.
BOOCH, G; RUMBAUGH, J e JACOBSON, I: UML, Guia do Usuário: tradução; Fábio

Freitas da Silva, 2ª edição, Rio de Janeiro, Campus, 2005.
BRASIL. Resolução nº 1.100 de 24 de maio de 2018. Discrimina as atividades e

competências profissionais do engenheiro de software e insere o respectivo título na
Tabela de Títulos Profissionais do Sistema Confea/Crea, para efeito de fiscalização o
exercício profissional. Diário Oficial da União. Seção 1, Brasília, DF, 109, p. 239. 08 jun.
2018.
CARVALHO, Fabio A. Gestão de projetos. São Paulo, Pearson Education do Brasil,

2012.
"Engenharia", in Dicionário Priberam da Língua Portuguesa, 2008-

2021, https://dicionario.priberam.org/Engenharia [consultado em 20-04-2022].
FERNANDES, R. Engenharia de software. Editora: Fael, Curitiba, 2017.
FOWLER, M. UML essencial: um breve guia para linguagem-padrão de modelagem

de objetos. 2º ed. Porto Alegre, Bookmam, 2005.
GLINZ, M., Glossário de Terminologia Engenharia de Requisitos Com Dicionário Inglês-

Português e Português-Inglês. 2011. Disponível em:
http://ibqts.com.br/uploads/conteudo/53/03-IREB_CPRE_FL_Glossario
%20Rev%20T&M%2030102013.pdf. Acessado em 20 de maio de 2022.
Guia PMBOK. 6a. ed. – EUA: Project Management Institute, 2017. BORGES, Carlos;
ROLLIM, Fabiano.
"iteração", in Dicionário Priberam da Língua Portuguesa, 2008-

2021, https://dicionario.priberam.org/itera%C3%A7%C3%A3o [consultado em 02-05-
2022].
PFLEEGER, S. L. Engenharia de Software: Teoria e Prática, 2ª Edição, Makron Books,

2004.
PRESSMAN, R. S. Engenharia de Software: Uma abordagem profissional. Tradução

Ariovaldo Griesi ; revisão técnica Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. – 7. ed. – Dados eletrônicos. – Porto Alegre : AMGH, 2011.
POHL, K.; RUPP, C. Fundamentos da Engenharia de Requisitos. Editora: Rockynoock.

2012.
"reúso", in Dicionário Priberam da Língua Portuguesa, 2008-

2021, https://dicionario.priberam.org/re%C3%BAso [consultado em 02-05-2022].
123
SOMMERVILLE, Ian. Engenharia de Software. Tradução Selma Shin Melnikoff; Reginaldo
Arakaki; Edilson de Andrade Barbosa. 8. ed São Paulo: Persson, 2007.
STALLINGS, William. Arquitetura e organização de computadores. 8. ed. São Paulo:

Pearson Pratice Hall, 2010.
TANENBAUM, A.S. Sistemas Operacionais: Projeto e Implementação. 3. ed. – Dados

eletrônicos. – Porto Alegre : Bookman, 2008.
124

Engenharia de Software I: Carlos Helmar Duarte

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

Engenharia de Software I: Carlos Helmar Duarte

Enviado por

Direitos autorais:

Formatos disponíveis

ENGENHARIA DE SOFTWARE I

Carlos Helmar Duarte

Mestre em Educação pela PUC/MG - Pontifícia Universidade Católica de Minas Gerais,

Diretor Geral: Valdir Henrique Valério

© 2023, Faculdade Única.

NEaD – Núcleo de Educação a Distância FACULDADE ÚNICA

São sugestões de links para vídeos, documentos

São exercícios de fixação do conteúdo abordado

São para o esclarecimento do significado de

UNIDADE ENGENHARIA DE SOFTWARE: CONTEXTUALIZAÇÃO HISTÓRICA E

UNIDADE CONCEITOS E MODELOS DE PROCESSO DE SOFTWARE ........................ 24

UNIDADE INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS.............................. 46

UNIDADE ENGENHARIA DE REQUISITOS ................................................................. 63

UNIDADE MODELAGEM BÁSICA: DIAGRAMAS UML .................................. 103

RESPOSTAS DO FIXANDO O CONTEÚDO .................................... 122

A unidade I tem como objetivo vincular o conhecimento sobre o

A unidade II tem como objetivo discutir os principais conceitos e

A unidade III aborda uma visão geral e os principais conceitos

Na unidade IV o objetivo é discutir a Engenharia de Requisitos. Serão

A unidade V tem como objetivo apresentar uma visão geral da

A unidade VI tem como objetivo, a partir dos conceitos

Quando as pessoas pensam no termo software, a primeira associação feita é

Hoje, o software assume um duplo papel. Ele é um produto e, ao

Fonte: Adaptado de Sommerville (2007, p. 04)

1.2 CONTEXTO HISTÓRICO DO SOFTWARE

A evolução do software ocorreu, desde o seu início, de forma acelerada. O

Fonte: Adaptado de Stallings (2010, p.12-27).

Na figura 2, a primeira geração de computadores (1940), tem como

A ideia era reunir em uma bandeja (tray) um conjunto de jobs da sala

Na terceira geração de computadores (1958) as máquinas começam a ser

BUSQUE POR MAIS

Na seção 1.2 serão discutidos conceitos e termos com o objetivo de elucidar

1.3 TRABALHANDO OS CONCEITOS BÁSICOS DA ENGENHARIA DE SOFTWARE

1.3.1 Conceitos iniciais

Alguns conceitos iniciais referentes à elaboração e uso de softwares são

1.3.2 Sistemas sociotécnicos

Para um melhor entendimento das definições propostas para o termo de

O funcionamento com sucesso de cada componente depende do

Uma característica no uso de sistema sociotécnicos é o fato de que as duas

Fonte: Adaptado de Sommerville (2007, p. 14-27)

As associações realizadas na figura 3 mostram as interligações e propriedades

Figura 4: Processo de Engenharia de Sistemas

Fonte: Adaptado de Sommerville (2007, p.17-23)

Na parte “social” do sistema referente à “organização, pessoas e sistemas de

“Os sistemas sociotécnicos incluem hardware de computador, software e pessoas, e são

Nesse capítulo foram abordados alguns importantes conceitos e contextos

1.4 ENGENHARIA DE SOFTWARE NOS DIAS ATUAIS

Atualmente a engenharia de software tem se apresentado como uma área

Quadro 1: Caracterização das áreas de conhecimento: Engenharia de Software, Engenharia

As classificações exibidas no quadro 1, mostram que as grandes áreas de

Para saber mais sobre as responsabilidades e ética do engenheiro de software, consulte:

1. Lei Nº 5.194, de 24 de dezembro de 1966. Regula o exercício das profissões de

Fonte: https://abrir.link/dncaO. Acesso em: 20 jan. 2023.

2. Resolução nº 1.073, de 19 de abril de 2016. Regulamenta a atribuição de títulos,

De acordo com os estudos da Associação Brasileira das Empresas de Software

1. A engenharia de sistemas está diretamente relacionada à execução e atividades

2. “Os relacionamentos complexos entre os componentes de um sistema mostram

4. “A engenharia de software é uma disciplina de engenharia relacionada com todos

5. (FUNIVERSA - 2009 - Adaptado) Assim como a Engenharia de Software, existe

6. Observe os trechos abaixo:

7. Sobre o conceito de software, analise as proposições abaixo:

8. (IPSEM– 2010) A evolução dos computadores foi caracterizada por avanços

2.1 MODELOS DE PROCESSOS DE SOFTWARES