Odelagem de Istemas Mpresariais: Prof. Neli Miglioli Sabadin

Modelagem de Sistemas
Empresariais
Prof. Neli Miglioli Sabadin
2016
Copyright © UNIASSELVI 2016
Elaboração:
Prof. Neli Miglioli Sabadin
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
003
S113m Sabadin; Neli Miglioli
Modelagem de sistemas empresariais/ Neli Miglioli Sabadin:
UNIASSELVI, 2016.
191 p. : il
ISBN 978-85-7830-962-6
1. Sistemas.
I. Centro Universitário Leonardo da Vinci.
Impresso por:
Apresentação
Prezado (a) acadêmico (a)
Bem-vindo à disciplina de Modelagem de Sistemas Empresariais.

Através desta disciplina verificaremos como o caminho da modelagem se
modificou nos últimos anos, para se adequar aos constantes progressos das
linguagens de programação, dos sistemas operacionais, dos bancos de dados,
regras de negócio cada vez mais complexas e paradigmas da programação
que buscam cada vez mais agilidade.
Vale lembrar que um dos assuntos mais relevantes da modelagem

é que ela tem o objetivo de permitir o entendimento do projeto a qualquer
pessoa da equipe, seja por parte da solicitante ou da solicitada, e em qualquer
ponto do processo. Como já diz o ditado popular, “uma imagem vale mais
que mil palavras”.
Conheceremos na primeira unidade os modelos de processo de

desenvolvimento tradicionais e os modelos evolucionários. Na sequência,
na segunda unidade, verificaremos como é realizado o levantamento dos
requisitos e as técnicas para essa atividade, além de entendermos como
funcionam as equipes e as fases do desenvolvimento do projeto. Para finalizar,
conheceremos a UML, bem como seus diagramas. E complementando os
estudos, será apresentada uma atividade para consolidar os conhecimentos
aprendidos na disciplina de Modelagem de Sistemas Gerenciais.
Aproveito a oportunidade para destacar a importância de desenvolver

as autoatividades, lembrando que essas atividades NAO SÃO OPCIONAIS.
Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na
realização das atividades, sugiro que você entre em contato com seu tutor
externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades
sem ter sanado todas as dúvidas que irão surgindo.
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
Neli Miglioli Sabadin
III
UNI
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades
em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o

material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato
mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação
no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir
a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
IV
V
VI
Sumário
UNIDADE 1 - INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS:
MODELO CASCATA E INCREMENTAL E MODELOS
EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO......................... 1
TÓPICO 1 - MODELOS DE CICLO DE VIDA................................................................................... 3

1 INTRODUÇÃO...................................................................................................................................... 3
2 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS...................................... 4
2.1 MODELO EM CASCATA................................................................................................................ 4
2.1.1 Modelo Incremental................................................................................................................ 7
2.1.2 Modelos de processo evolucionário..................................................................................... 9
2.1.3 Modelo Espiral......................................................................................................................... 9
2.1.4 Prototipação............................................................................................................................. 10
RESUMO DO TÓPICO 1........................................................................................................................ 12
AUTOATIVIDADE.................................................................................................................................. 13
TÓPICO 2 - INTRODUÇÃO A MODELAGEM ESTRUTURADA E

MODELAGEM ORIENTADA A OBJETO..................................................................... 15
1 INTRODUÇÃO...................................................................................................................................... 15
2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS................................................................... 18
3 EVOLUÇÃO HISTÓRICA DA MODELAGEM.............................................................................. 20
3.1 MODELAGEM ESTRUTURADA.................................................................................................. 21
3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO).................................................................. 23
RESUMO DO TÓPICO 2........................................................................................................................ 26
AUTOATIVIDADE.................................................................................................................................. 27
TÓPICO 3 - MÉTODO DE DESENVOLVIMENTO ÁGIL............................................................... 29

1 INTRODUÇÃO...................................................................................................................................... 29
2 PRECEITOS E PRINCÍPIOS................................................................................................................ 31
2.1 FATORES HUMANOS.................................................................................................................... 32
2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE................................. 33
2.2.1 Extreme Programming (programação extrema) XP........................................................... 34
2.2.2 Desenvolvimento de Software Adaptativo (ASD)............................................................. 35
2.2.3 Scrum........................................................................................................................................ 36
2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)....................................... 39
2.2.5 Crystal....................................................................................................................................... 40
2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD)....................................................... 40
2.2.7 Desenvolvimento de Software Enxuto (LSD)..................................................................... 41
2.2.8 Modelagem Ágil (AM)........................................................................................................... 41
2.2.9 Processo Unificado Ágil (AUP)............................................................................................. 42
2.2.10 Rational Unified Process (RUP).......................................................................................... 42
LEITURA COMPLEMENTAR................................................................................................................ 45
RESUMO DO TÓPICO 3........................................................................................................................ 59
AUTOATIVIDADE.................................................................................................................................. 61
VII
UNIDADE 2 - ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO....... 63
TÓPICO 1 - ENGENHARIA DE REQUISITOS.................................................................................. 65

1 INTRODUÇÃO...................................................................................................................................... 65
2 ENGENHARIA DE REQUISITOS..................................................................................................... 65
2.1 DEFININDO OS REQUISITOS...................................................................................................... 68
2.1.1 Requisitos Funcionais............................................................................................................. 68
2.1.2 Requisitos não funcionais...................................................................................................... 69
2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE REQUISITOS...................................... 71
2.3 PROBLEMAS ENCONTRADOS REFERENTES A REQUISITOS............................................. 73
2.4 ESPECIFICAÇÃO DE REQUISITOS............................................................................................. 74
2.4.1 Especificação em Linguagem Natural.................................................................................. 76
2.4.2 Especificação Estruturada...................................................................................................... 77
2.4.3 Documento de requisito de software................................................................................... 79
2.4.4 Gerenciamento de requisitos................................................................................................. 82
RESUMO DO TÓPICO 1........................................................................................................................ 86
AUTOATIVIDADE.................................................................................................................................. 88
TÓPICO 2 - DESCOBERTA DE REQUISITOS................................................................................... 91

1 INTRODUÇÃO...................................................................................................................................... 91
2 TÉCNICAS DE LEVANTAMENTO................................................................................................... 92
2.1 ENTREVISTA.................................................................................................................................... 93
2.1.1 Etnografia - Observação pessoal........................................................................................... 94
2.1.2 Questionário............................................................................................................................. 95
2.1.3 Brainstorming............................................................................................................................ 96
2.1.4 JAD (Joint Application Design)................................................................................................ 97
RESUMO DO TÓPICO 2........................................................................................................................ 99
AUTOATIVIDADE.................................................................................................................................. 100
TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE.................................................... 101

1 INTRODUÇÃO...................................................................................................................................... 101
2 FASES DO DESENVOLVIMENTO DE SISTEMAS....................................................................... 101
2.1 ESTUDO DE VIABILIDADE.......................................................................................................... 102
2.1.1 Análise...................................................................................................................................... 103
2.1.2 Projeto....................................................................................................................................... 104
2.1.3 Implementação........................................................................................................................ 105
2.1.4 Implantação.............................................................................................................................. 105
2.2 GERENCIAMENTO DE PROJETOS............................................................................................. 105
2.3 EQUIPE DE DESENVOLVIMENTO.............................................................................................. 107
2.3.1 Gerente...................................................................................................................................... 108
2.3.2 Analistas................................................................................................................................... 109
2.3.3 Projetistas.................................................................................................................................. 110
2.3.4 Arquitetos de software........................................................................................................... 110
2.3.5 Programadores........................................................................................................................ 112
RESUMO DO TÓPICO 3........................................................................................................................ 116
AUTOATIVIDADE.................................................................................................................................. 117
UNIDADE 3 - REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO

COMPORTAMENTAL E ESTRUTURAL E UM DETALHAMENTO
NOS CASOS DE USO.................................................................................................... 119
VIII
TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE)............................................................... 121
1 INTRODUÇÃO...................................................................................................................................... 121
2 MODELO CONCEITUAL DA UML.................................................................................................. 121
2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML..................................................................... 122
2.1.1 Itens estruturais ...................................................................................................................... 122
2.1.2 Itens comportamentais........................................................................................................... 124
2.1.3 Itens de agrupamento............................................................................................................. 125
2.1.4 Itens anotacionais.................................................................................................................... 125
2.2 RELACIONAMENTOS NA UML................................................................................................. 125
RESUMO DO TÓPICO 1........................................................................................................................ 127
AUTOATIVIDADE.................................................................................................................................. 128
TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS

E COMPORTAMENTAIS................................................................................................. 129
1 INTRODUÇÃO...................................................................................................................................... 129
2 DIAGRAMAS......................................................................................................................................... 129
2.1 DIAGRAMAS ESTRUTURAIS....................................................................................................... 131
2.1.1 Diagrama de Objetos.............................................................................................................. 131
2.1.2 Diagrama de Estrutura Composta........................................................................................ 132
2.1.3 Diagrama de Classes............................................................................................................... 134
2.1.4 Diagrama de Pacotes............................................................................................................... 135
2.2 DIAGRAMAS COMPORTAMENTAIS......................................................................................... 136
2.2.1 Diagramas de atividade......................................................................................................... 136
2.2.2 Diagramas de Caso de Uso.................................................................................................... 137
2.2.3 Diagrama de Transição de Estados...................................................................................... 138
2.3 DIAGRAMAS DE INTERAÇÃO.................................................................................................... 139
2.3.1 Diagrama de Sequência.......................................................................................................... 139
2.3.2 Diagrama de Temporização................................................................................................... 140
2.3.3 Diagrama de Comunicação.................................................................................................... 140
2.3.4 Diagrama de Visão Geral de Interação................................................................................ 141
2.4 DIAGRAMAS DE IMPLEMENTAÇÃO........................................................................................ 142
2.4.1 Diagrama de Componentes................................................................................................... 142
2.4.2 Diagrama de Implantação...................................................................................................... 143
RESUMO DO TÓPICO 2........................................................................................................................ 145
AUTOATIVIDADE.................................................................................................................................. 147
TÓPICO 3 - MODELO DE CASO DE USO......................................................................................... 149

1 INTRODUÇÃO...................................................................................................................................... 149
2 CASO DE USO....................................................................................................................................... 150
3 ATORES................................................................................................................................................... 150
4 FLUXO DE EVENTOS.......................................................................................................................... 151
5 RELACIONAMENTO........................................................................................................................... 152
5.1 RELACIONAMENTO ENTRE ATORES....................................................................................... 152
5.2 ATOR X CASO DE USO.................................................................................................................. 152
5.3 INCLUSÃO E EXTENSÃO............................................................................................................. 153
5.4 EXTENSÃO....................................................................................................................................... 154
6 GENERALIZAÇÃO............................................................................................................................... 156
RESUMO DO TÓPICO 3........................................................................................................................ 158
AUTOATIVIDADE.................................................................................................................................. 159
TÓPICO 4 - DIAGRAMA DE CLASSE................................................................................................ 161

1 INTRODUÇÃO...................................................................................................................................... 161
IX
2 DIAGRAMAS DE CLASSE................................................................................................................. 161
RESUMO DO TÓPICO 4........................................................................................................................ 174
AUTOATIVIDADE.................................................................................................................................. 175
TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA....................................................................................... 177

1 INTRODUÇÃO...................................................................................................................................... 177
2 TIPOS DE MENSAGEM...................................................................................................................... 177
2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA......................................................................... 178
RESUMO DO TÓPICO 5........................................................................................................................ 188
AUTOATIVIDADE.................................................................................................................................. 189
REFERÊNCIAS.......................................................................................................................................... 190
X
UNIDADE 1
INTRODUÇÃO AOS MODELOS

DE PROCESSO TRADICIONAIS:
MODELO CASCATA E INCREMENTAL
E MODELOS EVOLUCIONÁRIOS:
MODELO ESPIRAL E PROTOTIPAÇÃO
OBJETIVOS DE APRENDIZAGEM
Esta unidade tem por objetivos:
• introdução aos conceitos de ciclo de vida;
• modelagem orientada e estruturada;
• conhecimento dos modelos ágeis de desenvolvimento.
PLANO DE ESTUDOS
Esta unidade de ensino contém três tópicos. No final de cada um deles você
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TOPICO 1 – MODELOS DE CICLO DE VIDA
TÓPICO 2 – INTRODUÇÃO À MODELAGEM ESTRUTURADA E

MODELAGEM ORIENTADA A OBJETO
TÓPICO 3 – METÓDO DE DESENVOLVIMENTO ÁGIL
1
2
UNIDADE 1 TÓPICO 1
MODELOS DE CICLO DE VIDA
1 INTRODUÇÃO
A existência de um sistema de informação passa por um processo conhecido
como Ciclo de Vida, com três estágios bastante conhecidos pelo analista de sistema:
concepção, desenvolvimento e vida útil. De acordo com Silva (2014, p. 28), o nome
de cada fase da vida de um sistema pode sofrer variações, mas, na sua essência,
nada muda. Como vemos na definição:
Existe um encadeamento específico dessas fases, para a construção

do sistema dá-se o nome de Ciclo de vida. O processo de software é
o conjunto de atividades que constituem o desenvolvimento de um
sistema computacional. Estas atividades são agrupadas em fases, como:
• Definição de requisitos,
• Análise, projeto,
• Desenvolvimento,
• Teste e implantação.
Cada fase do desenvolvimento de software é definida. Além das suas

atividades, as funções e responsabilidades de cada membro da equipe, e, como
produto resultante, os artefatos. Como tudo que dá certo se repete, no mercado
de software ocorre o mesmo. Repetiram-se as práticas que ofereceram resultados
positivos. E a formalização em modelos de ciclo de vida. Em outras palavras, os
modelos de Ciclo de Vida são o esqueleto ou as estruturas predefinidas, nas quais
encaixamos as fases do processo. De acordo com Macêdo e Spínola (2016), a NBR
ISO/IEC 12207:1998, o Ciclo de Vida é a “Estrutura contendo processos, atividades
e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto
de software, abrangendo a vida do sistema desde a definição de seus requisitos, até
o término de seu uso”.
O modelo de Ciclo de Vida é a primeira escolha a ser feita no processo de

software, e a partir desta escolha definir-se-á desde a maneira mais adequada para
obter as necessidades do cliente, até quando e como o cliente receberá sua primeira
versão operacional do sistema. Vale ressaltar que não existe um modelo ideal. O
perfil e complexidade do empreendimento do cliente, o tempo disponível, o custo,
a equipe, o ambiente operacional são fatores que influenciarão diretamente na
escolha do Ciclo de Vida de software a ser adotado. Da mesma forma, também é
difícil uma empresa adotar somente um Ciclo de Vida no processo.
Os ciclos de vida se comportam de maneira sequencial (fases seguem

determinada ordem) e/ou incremental (divisão de escopo) e/ou iterativa
(retroalimentação de fases) e/ou evolutiva (software é aprimorado).
3
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
Não existe uma regra, a escolha de um modelo de processo depende muito

das características do projeto. Para escolher o modelo mais adequado é importante
conhecer alguns modelos de Ciclo de Vida e as situações em que são aplicáveis.
2 MODELOS DE PROCESSOS PRESCRITIVOS OU

TRADICIONAIS
Originalmente, modelos prescritivos foram propostos para trazer ordem
ao caos existente na área de desenvolvimento de software. Segundo Pressman
(2011, p.58), esses modelos proporcionavam uma contribuição quanto à estrutura
utilizável no trabalho de engenharia de software e forneceram um roteiro
razoavelmente eficaz para as equipes deste.
2.1 MODELO EM CASCATA

Também chamado de “modelo de ciclo de vida clássico”, o Modelo em
Cascata organiza as atividades do processo de desenvolvimento de forma
sequencial, como mostra a Figura 1. Uma característica desse modelo é que cada
fase resulta na elaboração de um ou mais documentos, que devem ser aprovados
antes de se iniciar a fase seguinte. Ou seja, uma fase só será iniciada após a conclusão
daquela que a precede. Uma vez que, na prática, essas fases se sobrepõem de
alguma forma, geralmente permite-se um retorno à fase anterior para a correção
de erros encontrados. O resultado final, ou melhor, a entrega do sistema completo
ocorre de uma única vez, ao final da fase de Entrega e Implantação. No Modelo em
Cascata, todo o projeto deve ser entendido em suas fases iniciais, seguindo até o
final com pouquíssima interação com o cliente.
4
TÓPICO 1 | MODELOS DE CICLO DE VIDA
FIGURA 1 - MODELO EM CASCATA
FONTE: Disponível em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessa- NEMO/

ES_Mestrado/Artigos/ProcessoDeSoftware.pdf> Acesso em: 23 fev. 2016
Os principais estágios do Modelo em Cascata refletem diretamente as

atividades fundamentais do desenvolvimento, segundo Sommerville (2011, p. 20):
TURO S
ESTUDOS FU
No capítulo 2- Detalharemos os tipos de requisitos e técnicas de levantamento

de requisitos.
1. Análise e definição de requisitos: Os serviços, restrições e metas

do sistema são estabelecidos por meio de consulta aos usuários. Em
seguida, são definidos em detalhes e funcionam como uma especificação
do sistema.
2. Projeto de sistema e software: O processo de projeto de sistemas
aloca os requisitos tanto para sistemas de hardware como para sistemas
de software, por meio de definição de uma arquitetura geral do sistema.
O projeto de software envolve a identificação e descrição das abstrações
fundamentais do sistema de software e seus relacionamentos.
3. Implementação e teste unitário: Durante esse estágio, o projeto do
software é desenvolvido como um conjunto de programas ou unidades
de programa. O teste unitário envolve a verificação de que cada unidade
atende à sua especificação.
4. Integração e teste de sistema: As unidades individuais do programa
ou programas são integradas e testadas como um sistema completo,
para assegurar que os requisitos do software tenham sido atendidos.
Após o teste o sistema de software é entregue ao cliente.
5
5. Operação e manutenção: Normalmente (embora não necessariamente),

essa é a fase mais longa do ciclo de vida. O sistema é instalado e
colocado em uso. A manutenção envolve a correção de erros que não
foram descobertos em estágios iniciais do ciclo de vida, com melhora da
implementação das unidades do sistema e ampliação de seus serviços
em resposta às descobertas de novos requisitos.
Existe uma variação do Modelo em Cascata que é chamado de modelo V.

Nesse modelo, procura-se enfatizar a estreita relação entre as atividades de teste
(teste de unidade, teste de integração, teste de sistema e teste de aceitação) e as
demais fases do processo.
Pressman (2011) explica que à medida que a equipe de software desce em

direção ao lado esquerdo do V, os requisitos básicos do problema são refinados em
representações progressivamente cada vez mais detalhadas e técnicas do problema
e de sua solução. Como mostra a Figura 2.
FIGURA 2 - MODELO V
FONTE: Adaptado de Pressman (2011, p. 60)
6
O Modelo em Cascata é o modelo mais antigo na engenharia de software, e

nos últimos anos recebeu várias críticas, conforme relatadas por Pressman (2011,
p. 61):
• Projetos reais raramente seguem o fluxo sequencial que o modelo

propõe. Embora o modelo linear possa conter interações, ele o faz
indiretamente. Como consequência, mudanças podem provocar
confusão à medida que a equipe de projeto prossegue.
• Frequentemente, é difícil para o cliente estabelecer explicitamente
todas as necessidades. O modelo em cascata requer isso e tem dificuldade
para adequar a incerteza natural que existe no início de muitos projetos.
• O cliente deve ter paciência. Uma versão operacional do(s) programa(s)
não estará disponível antes de estarmos próximo do final do projeto.
Um erro grave, se não detectado até o programa operacional ser revisto,
pode ser desastroso.
2.1.1 Modelo Incremental

Nem todos os projetos que conseguem ter todos os requisitos são
razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido,
isso torna impossível a adoção de um modelo sequencial, especialmente pela
necessidade de disponibilizar uma versão para o usuário rapidamente. Para esses
casos o Modelo Incremental é o mais indicado, como detalharemos.
Pressman (2011) diz que o Modelo Incremental combina elementos dos

fluxos de processos lineares e paralelos. A Figura 3 ilustra esses modelos.
7
FIGURA 3 - MODELO INCREMENTAL
FONTE: Pressman (2011, p. 54)
O princípio fundamental desse modelo é que, seja iteração ou ciclo, uma

versão operacional do sistema é gerada e entregue para avaliação e uso detalhado
do cliente.
Para que isso aconteça, os requisitos têm que ser levantados detalhadamente
e há de se constatar que o sistema é modular, de modo que se possa planejar o
desenvolvimento em incrementos. O primeiro incremento, tipicamente, contém
funcionalidades centrais, tratando dos requisitos básicos. A cada ciclo, novas
funcionalidades são adicionadas e as funcionalidades providas anteriormente
podem ser modificadas para melhor satisfazer às necessidades dos clientes/
usuários. Outras características são tratadas em ciclos subsequentes. Dependendo
do tempo estabelecido para a liberação dos incrementos, algumas atividades
podem ser feitas para o sistema como um todo ou não.
8
2.1.2 Modelos de processo evolucionário

Pressman (2011) afirma que o software, assim como todos os sistemas
complexos, evolui ao longo do tempo e, conforme o desenvolvimento deste software
avança, temos mudanças nas necessidades de negócio e de produtos, uma vez
que mudam frequentemente. Isso torna inadequado seguirmos um planejamento
em linha reta de determinado produto. Muitas vezes, os prazos reduzidos, a
necessidade de atender à pressão comercial e até mesmo da concorrência e em
outras situações como essas ou similares, faz-se necessário um modelo de processo
que tenha sido projetado especificamente para desenvolver um produto que
evolua ao longo do tempo. Modelos Evolucionários são caracterizados por serem
iterativos e apresentarem características que possibilitem desenvolvermos versões
cada vez mais completas do software. Os Processos Evolucionários se caracterizam
por dois modelos comuns: Prototipação e Espiral.
2.1.3 Modelo Espiral

O Modelo Espiral foi originalmente proposto por Boehm em 1988. Para
definir esse modelo de uma maneira mais simples, basta analisa-lo como um
Modelo em Cascata, onde cada fase é precedida por uma análise de risco e sua
execução é feita evolucionariamente (ou incrementalmente). Neste modelo de
desenvolvimento é possível avaliar riscos de projeto, tomando-se decisões baseadas
na experimentação de diferentes soluções. Para entendermos melhor, veja a Figura
4.
A dimensão radial representa o custo acumulado atualizado e a dimensão

angular representa o progresso através da espiral. Cada setor da espiral corresponde
a uma tarefa (fase) do desenvolvimento. No modelo original foram propostas
quatro tarefas (fases ou quadrantes) onde, por exemplo, na primeira volta pode
gerar como resultado a especificação do produto, na espiral subsequente o
resultado pode ser o protótipo, e nas voltas seguintes podem ser relativos a versões
aprimoradas do sistema (PRESSMAN, 2008, p.38).
9
FIGURA 4 - MODELO ESPIRAL
2.1.4 Prototipação
Em relação a esse paradigma, Pressman (2011) afirma que, embora possa
ser utilizada como um modelo de processo isolado (stand-alone-process), é mais
comumente utilizada como uma técnica passível de ser implementada no contexto
de qualquer um dos modelos apresentados. Ele explica o funcionamento deste
paradigma de maneira reduzida.
Na fase de comunicação, faz-se uma reunião com os envolvidos para

definir os objetivos gerais do software, identificar quais requisitos já são conhecidos
e esquematizar quais áreas necessitam, obrigatoriamente, de uma definição
mais ampla. Uma interação de prototipação é planejada rapidamente e ocorre a
modelagem (na forma de um “projeto rápido”).
Durante a fase de modelagem do projeto rápido: se concentra em uma

representação daqueles aspectos do software que serão visíveis aos usuários finais,
como, por exemplo, o layout da interface com o usuário ou formatos de exibição na
tela. E, finalmente, a construção de um protótipo: Nesta fase é feita a construção do
protótipo, que é empregado e avaliado, conforme vemos na Figura 5.
10
FIGURA 5 - PROTOTIPAÇÃO
Sommerville (2011, p. 31) alerta que, às vezes, os desenvolvedores são

pressionados pelos gerentes para entregar protótipos descartáveis, especialmente
quando há atrasos na entrega da versão final do software. No entanto, isso costuma
ser desaconselhável:
1. Pode ser impossível ajustar o protótipo para atender aos requisitos

não funcionais, como requisitos de desempenho, proteção, robustez e
confiabilidade, que foram ignorados durante o desenvolvimento do
protótipo.
2. Mudanças rápidas durante o desenvolvimento inevitavelmente
significam que o protótipo não está documentado. A única especificação
do projeto é o código do protótipo. Para a manutenção a longo prazo,
isso não é bom o suficiente.
3. As mudanças durante o desenvolvimento do protótipo provavelmente
terão degradado a estrutura do sistema. O sistema será difícil e custoso
de ser mantido.
4. Padrões de qualidade organizacional geralmente são relaxados para
o desenvolvimento do protótipo.
11
RESUMO DO TÓPICO 1
Neste tópico, vimos:
• Um breve contato com conceitos e modelos relacionados ao processo de

desenvolvimento de software.
• Modelos de processos prescritivos ou tradicionais: Modelo em Cascata e Modelo

Incremental e um resumo das fases.
• Modelos de processo evolucionário: Modelo espiral e Prototipação.
12
AUTOATIVIDADE
1 Qual deve ser a primeira escolha a ser feita no processo de software?
2 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe.

Embora o modelo linear possa conter interações, ele o faz indiretamente.
Como consequência, mudanças podem provocar confusão à medida que a
equipe de projeto prossegue. Essa é uma crítica que vem sendo apresentada
referente a qual modelo de desenvolvimento?
3 Quando se começa um projeto, nem todos conseguem ter todos os requisitos

razoavelmente bem definidos, e devido ao tamanho do sistema a ser
desenvolvido, isso torna impossível a adoção de qual modelo? E qual modelo
pode ser sugerido?
4 Preencha de acordo com a definição das fases de desenvolvimento:
Normalmente (embora não necessariamente), essa é a fase mais

longa do Ciclo de Vida. O sistema é instalado e colocado em
uso. A manutenção envolve a correção de erros que não foram
descobertos em estágios iniciais do Ciclo de Vida, com melhora
da implementação das unidades do sistema e ampliação de seus
serviços em resposta às descobertas de novos requisitos.
O processo de projeto de sistemas aloca os requisitos tanto para
sistemas de hardware como para sistemas de software, por meio
de definição de uma arquitetura geral do sistema. O projeto
de software envolve a identificação e descrição das abstrações
fundamentais do sistema de software e seus relacionamentos.
Os serviços, restrições e metas do sistema são estabelecidos por
meio de consulta aos usuários. Em seguida, são definidos em
detalhes e funcionam como uma especificação do sistema.
As unidades individuais do programa ou programas são
integradas e testadas como um sistema completo, para assegurar
que os requisitos do software tenham sido atendidos. Após o
teste, o sistema de software é entregue ao cliente.
Durante esse estágio, o projeto do software é desenvolvido como
um conjunto de programas ou unidades de programa. O teste
unitário envolve a verificação de que cada unidade atende à sua
especificação.
13
5 Qual é o modelo ideal que se aplica à maioria dos projetos de software?
6 A definição de que, embora possa ser utilizada como um modelo de processo

isolado (stand-alone-process), é mais comumente utilizada como uma técnica
passível de ser implementada no contexto de qualquer um dos modelos
apresentados, se refere a qual modelo de desenvolvimento?
14
UNIDADE 1
TÓPICO 2
INTRODUÇÃO A MODELAGEM ESTRUTURADA E

MODELAGEM ORIENTADA A OBJETO
1 INTRODUÇÃO
Se pedissem para você desenhar ou procurar na internet um item bem
específico: Uma cadeira com bolinhas amarela e confortável. A princípio não
parece ser um pedido muito difícil, certo?
Mas, qual das cadeiras era a solicitada?
FIGURA 6 - CADEIRA DE BOLINHA
FONTE: Disponível em: <http://arquitetura-tamiris.blogspot.

com/2011/03/cadeira-de-bolinha-amarelinhaa.html>. Acesso em: 22
mar. 2016.
15
FIGURA 7- CADEIRA DE BOLINHA
FONTE: Disponível em: <http://revistacasaejardim.globo.com/Revista/

Common/0,,ERT75860-16940,00.html>. Acesso em: 22 mar. 2016.
Isso foi apenas uma maneira de ilustrar a dificuldade de atender aos

requisitos. Mas se foi tão difícil para um item tão simples como uma cadeira,
imagine para o sistema de uma empresa.
Para ajudar nessa tarefa, têm-se os modelos, que são uma visualização dos
requisitos, bem como o desejo do cliente do que deve ser implementado. Juntos,
eles auxiliam no entendimento do que o cliente solicitou e do que a equipe deve
desenvolver.
O ponto mais importante do desenvolvimento de um sistema é compreender

as necessidades e desejos do usuário e da organização e visualizar os benefícios que
serão obtidos com esse sistema, mas se isso não for bem entendido, os requisitos
e as atividades relacionadas ao seu desenvolvimento não terão significado algum.
O termo modelagem já sugere a criação de um modelo, a elaboração

de um esboço do que se pretende fazer, por meio de um gráfico, um desenho,
antes de começar a construção propriamente dita. Essa atividade abrange vários
segmentos, pode ser uma casa, um carro, um vestido ou até mesmo um software.
Abaixo há alguns esboços de coisas bem diferentes, mas que seguem a mesma
linha de raciocínio.
16
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
FIGURA 8- MODELO CASA
FONTE: Disponível em: < http://www.tudoconstrucao.com/10-modelos-

de-plantas-de-casas-para-2015/>. Acesso em: 22 mar. 2016.
FIGURA 9- MODELO CARRO
FONTE: Disponível em: < http://pt.dreamstime.com/fotos-de-stock-

royalty-free-desenho-do-carro-image7844748>. Acesso em: 22 mar. 2016.
FIGURA 10- MODELO VESTIDO
FONTE: Disponível em: <http://vida-estilo.estadao.com.br/

noticias/moda,veja-quais-sao-os-vestidos-de-casamento-mais-
iconicos-de-todos-os-tempos,1786989>. Acesso em: 22 mar.
2016.
17
É durante a fase de modelagem que o autor do projeto, independentemente

do tipo, prepara um “modelo” com todos os requisitos, funcionalidade ou
características, que o seu cliente ou usuário solicitou. Nesse modelo apresentam-se
a estrutura e o comportamento do sistema que será desenvolvido, enxergando seu
funcionamento. Durante essa fase é possível verificar com o usuário se o modelo
proposto atende às suas necessidades, conforme os requisitos informados.
A criação de modelos é de suma importância para o entendimento do

projeto como um todo.
2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS

Pode-se construir uma casa para um cachorro apenas juntando algumas
tábuas, alguns pregos e algumas ferramentas básicas. Com um planejamento
mínimo, em poucas horas e com um pouco de habilidade, nosso cachorro terá
uma casa (BOOCH et al., 2000).
FIGURA 11 - CASA DE CACHORRO
FONTE: Disponível em: <http://bioretro.eco.br/lar-cao-tambem-sustentavel/>. Acesso em: 23 fev.

2016.
Ainda segundo o autor, se o plano for construir a casa para sua família, com
certeza uma pequena pilha de tábuas e alguns pregos não será o suficiente, pois,
com certeza, sua família será um pouco mais exigente que o seu cachorro. Para fazer
a sua casa, antes de sair batendo o primeiro prego é necessário que você saiba o que
18
sua família espera, será melhor fazer um planejamento bem detalhado de como
será essa construção. Fazer alguns desenhos e verificar todos os procedimentos
para garantir a segurança da edificação. Durante esse detalhamento, você verá
que é muito difícil construir uma casa sozinho, e que terá que ter uma equipe para
auxiliar, com cada membro da equipe sabendo o que deve desempenhar. Se tudo
correr bem e o modelo for seguido, provavelmente, ao final do projeto, sua família
ficará satisfeita. Vale ressaltar que, para não gerar frustrações ao final do projeto, é
muito importante definir as expectativas desde o início.
FIGURA 12 - CASA SEM PROJETO
FONTE: Disponível em: <http://atl.clicrbs.com.br/mundoidao/2008/08/26/

casa-e-construida-de-cabeca-para-baixo/> Acesso em: 23 fev. 2016.
Agora, se você não quer construir software equivalente a uma casa, Booch
et al. (2000) advertem que o segredo estará em criar o código correto e pensar em
como será possível elaborar menos software. Isso faz com que o desenvolvimento
de programa de qualidade se torne uma questão de arquitetura, processo e
ferramentas. Para uma empresa de software ter sucesso, existem vários elementos
que contribuem para isso, um deles é a utilização da modelagem.
Ainda segundo Booch et al. (2000, p.6) constroem-se modelos para

compreender melhor o sistema que estamos desenvolvendo. E com ela é possível
alcançar quatro objetivos:
• Os modelos ajudam a visualizar o sistema como ele é ou como

desejamos que seja.
• Os modelos permitem especificar a estrutura ou o comportamento de
um sistema.
• Os modelos proporcionam um guia para a construção do sistema.
• Os modelos documentam as decisões tomadas.
Vale ressaltar que a modelagem não se restringe apenas a grandes sistemas.

Ainda de acordo com Booch et al. (2000), softwares pequenos, equivalentes a uma
casa de cachorro, poderão receber os benefícios da modelagem, porém é verdade que
quanto maior e mais complexo o sistema, maior será a importância da modelagem,
por um motivo bem simples, que não é possível compreendê-los em sua totalidade.
19
3 EVOLUÇÃO HISTÓRICA DA MODELAGEM

Bezerra (2015) apresenta um breve resumo histórico da evolução das
técnicas de desenvolvimento, para explicar como chegamos ao cenário atual.
Décadas de 1950/1960: Os sistemas eram bem simples, e o seu desenvolvimento

era direto ao assunto, não tinha um planejamento inicial, como dizem, “ad
hoc”. Como os sistemas eram significativamente mais simples, as técnicas de
modelagem também: Eram usados fluxogramas e diagramas de módulos.
Década de 1970: Começaram a surgir computadores mais avançados e

acessíveis. Houve grande ampliação do mercado computacional. Sistemas mais
complexos começavam a surgir. Consequentemente, modelos mais robustos
foram propostos. Os autores Larry Constantine e Edward Yourdon são grandes
colaboradores nessas técnicas.
Década de 1980: Nessa fase os computadores se tornaram ainda mais avançados e

mais baratos. Surge a necessidade por interfaces mais sofisticadas, o que originou
a produção de sistemas de softwares mais complexos. A Análise Estruturada
surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter
Coad, Tom De Marco, James Martin e Chris Gane.
Década de 1990: No início dessa década é o período em que surge um novo

paradigma de modelagem, a Análise Orientada a Objetos, como resposta a
dificuldades encontradas na aplicação da análise estruturada em algumas
aplicações. Grandes colaboradores desse paradigma são Sally Shlaer, Stephen
Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson.
Já no fim da década, o paradigma da orientação a objetos atinge sua

maturidade. Os conceitos de padrões de projeto, frameworks, componentes
e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem
Unificada UML.
Década de 2000: O reúso por meio de padrões de projetos e frameworks se

solidifica. As denominadas metodologias ágeis começam a ganhar espaço.
Técnicas de testes automatizados e refatoração começaram a se difundir entre os
desenvolvedores que trabalham com orientação a objeto. Grandes nomes dessa
fase são: Rebecca Wirfs-Brock, Martin Fowler e Eric Vans.
Como percebemos, durante a década de 90 surgiram várias propostas

e técnicas para modelagem de sistema segundo o paradigma da orientação a
objeto. Era comum, durante essa década, duas técnicas possuírem diferentes
notações gráficas para modelar a mesma perspectiva de um sistema. Todas
tinham pontos fortes e fracos em relação à notação utilizada, mas via-se a
necessidade de uma notação que viesse a se tornar um padrão para a modelagem
de sistemas orientados a objeto, e que fosse amplamente aceita, nas indústrias e
na academia.
20
Alguns esforços surgiram em 1996 para essa padronização, o que resultou

na definição da UML (Unified Modeling Language), que detalharemos a seguir
em um tópico específico, mas antes falaremos na Modelagem Estruturada e da
Modelagem Orientada a Objetos.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/19056116/principios-de-analise-
e-projeto---eduardo-bezerra/7>. Acesso em: 11 abr. 2016.
3.1 MODELAGEM ESTRUTURADA

A modelagem estruturada teve seu início na década de 1970, com uma
abordagem bem sistemática, utilizando técnicas de construção de modelos. O
seu princípio é a divisão em módulos e submódulos. Ele é de fácil utilização,
especialmente por ser diagrama de fácil compreensão e minimização, a lacuna
de conhecimento, muitas vezes, existente entre os analistas e os usuários. A sua
documentação é feita através dos diagramas de fluxo de dados (DFD), Diagrama
de entidade-relacionamento (DER).
O Diagrama de fluxo de dados tem como objetivo representar graficamente o

fluxo dos dados, normalmente usados para apresentar uma visão geral do sistema,
onde podemos verificar a entrada e saída das informações e onde os dados serão
armazenados.
Entidades Externas: São categorias lógicas de objetos ou pessoas que representam

Origem ou destino de dados, e que acionam um sistema e/ou recebem informações.
Podem ser pessoas, sistemas ou unidades departamentais, segundo Rezende (2005,
p.170).
Fluxo de dados: Representa um processo de transformação de dados, é o meio por

onde os dados e as informações trafegam, eles sempre envolvem um processo, sua
representação é um retângulo com cantos arredondados;
Processos: Transformam fluxos de dados em uma atividade, ou seja, são as

atividades que transformam as entradas, transportam dados de processo a
processo, armazena os dados, e produz as saídas de um sistema.
Depósito de dados: São locais de armazenamento de dados, são arquivos físicos.
21
FIGURA 13- SUBSISTEMAS DE FATURAMENTO
FONTE: Rezende (1997, p. 109)
Diagrama entidade-relacionamento (DER): O principal propósito do DER

é representar os objetos de dados e suas relações, sendo que cada entidade termina
representada pelo menos por uma tabela de dados, e normalmente expressa por
um depósito de dados do DFD.
Os objetos de dados são representados por retângulos rotulados e os

relacionamentos são indicados por losangos, e as conexões entre os dados e os
relacionamentos são estabelecidos usando-se uma série de linhas e ligações
especiais.
22
FIGURA 14- ELEMENTOS E SÍMBOLOS DER
FIGURA 15- EXEMPLO DE DIAGRAMA DER
FONTE: Disponível em: < http://www.devmedia.com.br/artigo-sql-magazine-61-modelagem-

de-dados-para-um-sistema-de-controle-de-orcamento/11726>. Acesso em: 23 fev. 2016.
3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO)

Uma forma mais eficiente de pensar em modelagem e desenvolvimento de
projetos é a Proposta Orientada a Objetos, que organiza os problemas em torno de
situações reais, como elas realmente acontecem na prática, e isso impõe uma forma
completamente diferente de pensar e organizar a solução, se comparado à forma
como o pensamento estruturado apresenta esta. (BOOCH, 1994).
Inicialmente é importante definir a palavra paradigma. Pode-se dizer,

então, que o termo “paradigma da orientação a objetos” é uma forma de abordar
um problema. Segundo Bezerra (2015, p. 5):
23
Há alguns anos, Alan Kay, um dos pais do paradigma a orientação a

objetos, formulou a chamada “analogia biológica”. Por meio dela, ele
imaginou um sistema de software que funcionasse como um ser vivo.
Nesse sistema, cada “célula” interagiria com outras células através do
envio de mensagens com o propósito de realizar um objetivo comum.
Além disso, cada célula se comportaria como uma unidade autônoma.
Ele pensou em construir um sistema de software a partir de agentes

autônomos que interagem entre si. E estabeleceu os seguintes princípios da
orientação a objetos Kay apud Bezerra (2005, p 6).
1. Qualquer coisa é um objeto.

2. Objetos realizam tarefas por meio da requisição de serviços a outros
objetos.
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa
objetos similares.
4. A classe é um repositório para comportamento associado ao objeto.
5. Classes são organizadas em hierarquia.
Pode-se concluir que a Orientação a Objeto como técnica para modelagem

de sistemas diminui a diferença semântica entre a realidade que está sendo
modelada e os modelos construídos.
A visão contemporânea no desenvolvimento de software, segundo Booch et

al. (2000), adota uma perspectiva orientada a objeto. Nessa visão, o principal bloco
de construção de todos os sistemas de software é o objeto ou classe. Objeto é alguma
coisa geralmente estruturada a partir do vocabulário do espaço ou problema ou do
espaço da solução. E uma Classe é a descrição de um conjunto de objetos comuns.
Todos os objetos têm uma identidade. É possível atribuir nomes ou diferenciá-los
de alguma maneira. Um estado (costuma haver dados a eles relacionados) e um
comportamento, que indica que você pode fazer algo com o objeto ou ele poderá
fazer algo com outros objetos.
Entre as ideias fundamentais básicas para a tecnologia orientada a objeto

temos:
• Objetos.
• Classes.
• Métodos.
• Herança.
• Encapsulamento.
Objetos: Cada conceito é uma ideia ou um entendimento coletivo que

temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido
sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam
são denominados objetos. Um objeto pode ser real ou abstrato.
• Os objetos possuem informações (contêm dados) e desempenham ações

(possuem funcionalidade).
24
• Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância

de um conceito ou tipo de objeto.
• Um objeto é uma instância de uma classe.
Classe: O termo classe refere-se à implementação de software de um tipo

de objeto. Um tipo de objeto especifica uma família de objetos sem estipular
como o tipo e o objeto são implementados. Os tipos de objetos são especificados
durante a análise OO. Os tipos de objetos são implementados como módulos,
enquanto na linguagem orientada a objeto os tipos de objetos são classificados
como classes.
• Uma classe é uma implementação de um tipo de objeto.

• Uma classe especifica uma estrutura de dados e os métodos operacionais
permissíveis que se aplicam a cada um de seus objetos.
• Uma classe pode ter sua própria estrutura de dados e métodos, bem como
herdá-la de sua superclasse.
Métodos:
• Os métodos especificam a maneira pela qual os dados de um objeto são

manipulados.
• Uma especificação dos passos pelos quais uma operação deve ser executada.
• Ele é um script de implementação de uma operação.
• Diferentes métodos podem ser usados para executar a mesma operação.
• Os métodos de um tipo de objeto referenciam somente as estruturas de dados
desse tipo de objeto.
• A ação que um objeto ou uma classe podem desempenhar.
• Os métodos são similares às funções e procedures do universo da programação
estruturada.
Encapsulamento: O ato de empacotar ao mesmo tempo dados e objetos

é denominado encapsulamento. O objeto esconde seus dados de outros objetos e
permite que os dados sejam acessados por intermédio de seus próprios métodos.
Isso é chamado de ocultação de informações (information hiding).
• O encapsulamento protege os dados do objeto do uso arbitrário e não

intencional.
• O encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da
implementação de um objeto.
• O encapsulamento é importante porque separa a maneira como um objeto se
comporta da maneira como ele é implementado.
FONTE: Disponível em: <http://www.macoratti.net/net_oocb.htm>. Acesso em: 11 abr. 2016.
25
RESUMO DO TÓPICO 2
Neste tópico, vimos que:
• A modelagem facilita a comunicação entre as partes envolvidas.
• A importância da modelagem de sistemas, como parte imprescindível no

desenvolvimento dos projetos.
• A evolução histórica da modelagem, o que deu certo e o que mudou.
• As técnicas de Modelagem estruturada e o Paradigma da Orientação a Objeto

(OO).
26
AUTOATIVIDADE
1 “Cada conceito é uma ideia ou um entendimento coletivo que temos do

nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre
as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam
são denominadas objetos.” Essa definição é verdadeira ou falsa?
2 Para que serve a modelagem?
3 Quais definições apresentadas não estão corretas?
• Encapsulamento – É o agrupamento de ideias afins em uma unidade. Permite

ao programador apresentar os detalhes da representação dos dados por trás
de um conjunto de operações (como a interface). Reflita sobre o seguinte:
você sabe como funciona internamente o seu micro-ondas? Mas você sabe
como ligá-lo, programá-lo e desligá-lo. Você interage com o micro-ondas por
meio de sua interface sem se preocupar com os detalhes da implementação:
esse é um exemplo de encapsulamento.
• Ocultação de informações e implementações – é exatamente o uso do
encapsulamento que restringe a visibilidade de detalhes e informações que
ficam internas à estrutura do encapsulamento.
• Mensagens – solicitação de um objeto para que outro objeto efetue uma de suas
operações. Os objetos não podem mandar mensagens entre si. As mensagens
resultam na chamada de métodos que executam as ações necessárias.
• Classes – as classes são conjuntos de objetos com características semelhantes.
• Herança – o mecanismo de herança permite que uma classe seja criada a
partir de outra classe (superclasse), e a nova classe (subclasse) herda todas as
suas características.
• Poliformismo – é a propriedade segundo a qual uma operação pode se
comportar de modos diversos em classes diferentes. Sistemas orientados
a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e
oferecem a oportunidade de criar e implementar componentes totalmente
reutilizáveis.
4 Quais são os objetivos atingidos utilizando modelos?
5 Quando e por que a Análise Orientada a Objetos surgiu?
6 Defina os objetivos da análise estruturada e como ela é documentada.
27
28
UNIDADE 1
TÓPICO 3
MÉTODO DE DESENVOLVIMENTO ÁGIL
1 INTRODUÇÃO
Em 2001, Kent Beck e outros 16 renomados desenvolvedores, autores e
consultores da área de software, batizados de “Aliança dos ágeis (Agile Alliance)”,
assinaram o Manifesto para o Desenvolvimento Ágil de Software (Agile Software
Development Manifesto), que se inicia da seguinte maneira, segundo Pressman
(2011, p. 81):
DICAS
Para maiores informações, acesse: http://agilemanifesto.org/
Desenvolvendo e ajudando outros a desenvolver software, estamos

desvendando formas melhores de desenvolvimento. Por meio deste
trabalho passamos a valorizar:
Indivíduos e interações acima de processos e ferramentas.
Software operacional acima de documentação completa.
Colaboração dos clientes acima de negociação comercial.
Respostas a mudanças acima de seguir um plano.
Ou seja, embora haja valor nos itens à direita, valorizaremos os da
esquerda mais ainda.
Ainda segundo o autor, normalmente, um manifesto é associado a um

movimento político emergente: atacando a velha guarda e sugerindo uma
mudança revolucionária (normalmente, espera-se que para a melhor). E, de certa
forma, é exatamente disso que o desenvolvimento ágil trata. Vale frisar que apesar
de parecer benéfica, essa metodologia não é indicada para todos os projetos,
produtos, pessoas e situações.
Afinal, no contexto de engenharia de software, o que é agilidade? Jacobson

apud Pressman (2011, p. 82) responde essa pergunta:
Atualmente agilidade tornou-se a palavra da moda quando se descreve

um moderno processo de software. Todo mundo é ágil. Uma equipe ágil
é aquela capaz de responder apropriadamente a mudanças. Mudanças
têm muito a ver com desenvolvimento de software. Mudanças no
software que está sendo criado, mudanças nos membros da equipe,
mudanças devido a novas tecnologias, mudanças de todos os tipos
29
que poderão ter um impacto no produto que está em construção ou

no projeto do produto. Suporte para mudanças deve ser incorporado
em tudo o que fazemos em software, algo desenvolvido por indivíduos
trabalhando em equipes e que as habilidades dessas pessoas, suas
capacidades em colaborar estão no cerne do sucesso do projeto.
O Método Ágil de desenvolvimento incentiva a estruturação e as atitudes

em equipe que tornam a comunicação mais fácil entre todos os envolvidos no
projeto, e também enfatiza a entrega rápida do software operacional e diminui a
importância dos artefatos intermediários.
Importante salientar que os custos para as alterações em software aumentam

de forma não linear conforme o projeto avança, e quando mais tarde for feita a
alteração, mais alto será o custo. É fácil imaginar que se uma alteração for feita
durante a fase de requisitos, no início do projeto, estes custos serão mínimos, e o
tempo não afetará negativamente o resultado do projeto, como podemos observar
na Figura 16.
FIGURA 16 - CUSTO DE ALTERAÇÃO
Fonte: Pressman (2011, p. 83)
30
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
2 PRECEITOS E PRINCÍPIOS
Pressman (2011, p.84) ressalta que qualquer processo ágil de software é
caracterizado de uma forma que se relacione a uma série de preceitos-chave acerca
da maioria dos projetos de software.
1. É difícil afirmar antecipadamente quais requisitos de software irão

persistir e quais sofrerão alterações. É igualmente difícil prever de
que maneira as prioridades do cliente sofrerão alterações conforme o
projeto avança.
2. Para muitos tipos de software, o projeto e a construção são
“interconduzidos”, ou seja, ambas as atividades devem ser realizadas
uma atrás da outra, para que modelos de projeto sejam provados
conforme sejam criados. É difícil prever quanto de trabalho de projeto
será necessário antes que seu desenvolvimento seja implementado para
avaliar o projeto.
3. Análise, projeto, desenvolvimento e testes não são tão previsíveis
quanto gostaríamos que fossem segundo o ponto de vista do
planejamento.
Em análise a esses pontos, surge a dúvida de como é possível administrar a

imprevisibilidade. A resposta, conforme observado, consiste na adaptabilidade de
processos, ou seja, um processo ágil deve ser adaptável.
Para se conseguir essa agilidade, segundo Pressman (2011, p.84), o grupo

“Aliança dos ágeis” estabeleceu 12 princípios:
1. A maior prioridade é satisfazer o cliente por meio da entrega

adiantada e contínua de software valioso.
2. Acolha bem os pedidos de alterações, mesmo atrasados no
desenvolvimento. Os processos ágeis se aproveitam das mudanças
como uma vantagem competitiva na relação com o cliente.
3. Entregue o software em funcionamento frequentemente, de algumas
semanas para alguns meses, dando preferência a intervalos mais curtos.
4. O pessoal do comercial e os desenvolvedores devem trabalhar em
conjunto diariamente ao longo de todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o
ambiente e apoio necessários e confie neles para ter o trabalho feito.
6. O método mais eficiente e efetivo de transmitir informações para e
dentro de uma equipe de desenvolvimento é uma conversa aberta, de
forma presencial.
7. Software em funcionamento é a principal medida de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os
proponentes, desenvolvedores e usuários devem estar capacitados para
manter um ritmo constante indefinidamente.
9. Atenção contínua para com a excelência técnica e para com bons
projetos aumenta a agilidade.
10. Simplicidade, a arte de maximizar o volume de trabalho não
efetuado, é essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes
que se auto-organizam.
12. A intervalos regulares, a equipe se avalia para ver como tornar-se
mais eficiente, então sintoniza e ajusta seu comportamento de acordo.
31
O autor ressalta que nem todo modelo de processo ágil aplica esses 12
princípios de maneira igual, adequando-se e priorizando um ou outro princípio.
Entretanto, os princípios definem um espírito ágil mantido em cada um dos
modelos de processo.
2.1 FATORES HUMANOS

Os defensores das metodologias ágeis de desenvolvimento esforçam-se
para reforçar a importância dos “fatores humanos”. Pressman (2011) afirma que
o desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando
o processo de acordo com as pessoas e equipes específicas. Abaixo listaremos
algumas características ou traços-chave que uma pessoa de uma equipe ágil e a
equipe em si devem possuir.
Competência: Abrange talentos inatos, habilidades específicas

relacionadas a software e conhecimento generalizado do processo que a equipe
escolheu para aplicar. Habilidade e conhecimento de processo podem e devem
ser ensinados para todas as pessoas que sejam membros de uma equipe ágil.
Foco comum: Embora os membros de uma equipe ágil possam realizar

tarefas e tenham habilidades diferentes em um projeto, todos devem estar
focados em um único objetivo: entregar um incremento de software funcionando
ao cliente, dentro do prazo estipulado. Para atingir essa meta, a equipe também
irá focar em adaptações contínuas (pequenas e grandes) que farão com que o
processo se ajuste às necessidades da equipe.
Colaboração: Criar informações que ajudarão todos os envolvidos

a compreender o trabalho da equipe e a construir informações (software para
computadores e banco de dados relevantes) que forneçam valor de negócio para
o cliente. Para realizar essas tarefas, os membros da equipe devem colaborar
entre si, e com todos os demais envolvidos.
Habilidade à tomada de decisão: Ter liberdade para controlar seu

próprio destino, ou seja, a equipe deve ter autonomia, autoridade na tomada de
decisões. Tanto nos assuntos técnicos como de projetos.
Habilidade de solução de problemas confusos: Os gerentes de

software devem reconhecer que a equipe ágil terá de lidar continuamente com
ambiguidade e que será continuamente atingida por mudanças. Em alguns casos,
a equipe tem de aceitar o fato de que o problema que eles estão solucionando hoje
talvez não seja o problema que necessita ser solucionado amanhã. Entretanto,
lições aprendidas de qualquer atividade de solução de problemas podem ser
futuramente benéficas para a equipe no projeto.
32
Confiança mútua e respeito: Deve ser uma equipe consistente, pois

demonstra confiança e o respeito necessário para torná-la fortemente unida. O
todo é maior que a soma das partes.
Auto-organização: No contexto do desenvolvimento ágil, a auto-

organização implica três fatores:
1. A equipe ágil se organiza para o trabalho a ser feito;

2. A equipe organiza o processo para melhor se adequar ao seu
ambiente local;
3. A equipe organiza o cronograma de trabalho para melhor cumprir a
entrega do incremento de software.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/16282034/engenharia-de-

software---uma-abordagem-profissional----7-edicao/35>. Acesso em: 11 abr. 2016.
A auto-organização possui uma série de benefícios técnicos, mas o mais

importante é o fato de servir para melhorar a colaboração e levantar o moral da
equipe. Vale ressaltar que a equipe faz seu próprio gerenciamento, pois seleciona
quanto trabalho acredita ser capaz de realizar dentro da iteração e se compromete
com o trabalho. É extremamente desmotivador para o conjunto um terceiro assumir
compromissos por ele.
2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE

SOFTWARE
Como foi visto até agora, as metodologias ágeis têm o objetivo de acelerar
o desenvolvimento do software visando a melhoria contínua do processo, gerando
benefícios como o aumento da comunicação e interação da equipe, organização
diária para o alcance da meta definida, evitar falhas na elaboração, respostas
rápidas às mudanças e aumento significativo da produtividade. A seguir, algumas
metodologias de desenvolvimento ágil.
• Extreme Programming XP.

• Desenvolvimento de Software Adaptativo (ASD).
• Scrum.
• Método de Desenvolvimento de Sistemas Dinâmicos (DSDM).
• Crystal.
• Desenvolvimento Dirigido à Funcionalidade (FDD).
• Desenvolvimento de Software Enxuto (LSD).
• Modelagem Ágil (AM).
• Processo Unificado Ágil (AUP).
• Rational Unified Process (RUP).
33
2.2.1 Extreme Programming (programação extrema) XP

Em seu livro, Pressman (2011, p.87) define um conjunto de cinco valores
que estabelecem as bases para todo o trabalho realizado com parte da XP, onde
cada um deles é usado como um direcionador das atividades, ações e tarefas
específicas da XP:
• Comunicação
• Simplicidade
• Feedback (realimentação ou retorno)
• Coragem e
• Respeito.
A Extreme Programming emprega uma abordagem orientada a objetos

como seu paradigma de desenvolvimento preferido e envolve um conjunto de
regras e práticas constantes no contexto de quatro atividades metodológicas, que
são: planejamento, projeto, codificação e testes. A Figura 17 ilustra o processo e
destaca alguns conceitos e tarefas-chave associados a cada uma das atividades
metodológicas.
FIGURA 17 - EXTREME PROGRAMMING
Segundo Sommerville (2011, p.44), em um processo XP os clientes estão

intimamente envolvidos na especificação e priorização dos requisitos do sistema.
Os requisitos não estão especificados como uma lista de funções requeridas do
34
sistema. Pelo contrário, o cliente do sistema é parte da equipe de desenvolvimento

e discute cenários com outros membros da equipe. Juntos eles desenvolvem um
“cartão de história” englobando as necessidades do cliente.
FIGURA 18 - DESENVOLVIMENTO XP
Princípio ou prática Descrição

Os requisitos são gravados em cartões de história e as histórias que
Planejamento serão incluídas em um release são determinadas pelo tempo disponível e
incremental sua relativa prioridade. Os desenvolvedores dividem essas histórias em
'Tarefas'. Veja quadro 3.1 e 3.2.
Em primeiro lugar, desenvolve-se um conjunto mínimo de funcionalidades
Pequenos releases útil, que fornece o valor do negócio. Releases do sistema são frequentes e
gradualmente adicionam funcionalidade ao primeiro release.
Projeto simples Cada projeto é realizado para atender às necessidades atuais e nada mais.
Um framework de testes iniciais automatizados é usado para escrever os
Desenvolvimento
testes para uma nova funcionalidade antes que a funcionalidade em si seja
test-first
implementada.
Todos os desenvolvedores devem refatorar o códio continuamente assim
Refatoração que encontrarem melhorias de código. Isso mantém o código simples e
manutenível.
Programação em Os desenvolvedores trabalham em pares, verificando o trabalho dos outros
pares e prestando apoio para um bom trabalho sempre.
Os pares de desenvolvedores trabalham em todas as áreas do sistema, de
Propriedade modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos
Coletiva e todos os desenvolvedores assumem responsabilidade por todo o código.
Qualquer um pode mudar qualquer área.
Assim que o trabalho em uma tarefa é concluído, ele é integrado ao sistema
Integração contínua como um todo. Após essa integração, todos os testes de unidade do sistema
devem passar.
Grandes quantidades de horas-extras não são consideradas aceitáveis, pois
Ritmo sustentável o resultado final, muitas vezes, é a redução da qualidade do código e da
produtividade a médio prazo.
Um representante do usuário final do sistema (o cliente) deve estar
disponível todo o tempo à equipe de XP. Em um processo de Extreme
Cliente no local
Programming, o cliente é um membro da equipe de desenvolvimento e é
responsável por levar a ela os requisitos de sistema para implementação.
FONTE: Sommerville (2011, p.45)
2.2.2 Desenvolvimento de Software Adaptativo (ASD)

É uma técnica para a construção de software e sistemas complexos. As bases
se concentram na colaboração humana e na auto-organização das equipes. Nesta
técnica de desenvolvimento define-se um ciclo de vida que incorpora três fases:
especulação, colaboração e aprendizagem.
35
FIGURA 19 - DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD)
FONTE: Pressman (2011, p.94)
2.2.3 Scrum
Os princípios do Scrum são consistentes com o manifesto ágil e são usados
para orientar as atividades de desenvolvimento dentro de um processo que
incorpora as seguintes atividades estruturais: Requisitos, análise, projeto, evolução
e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de
um padrão de processo chamado Sprint. O fluxo geral do processo de Scrum é
ilustrado na Figura 20.
36
FIGURA 20 - DESENVOLVIMENTO SCRUM
DICAS
Esse assunto merece seu estudo, acesse http://www.scrumguides.org/docs/

scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
Segundo o guia do Scrum (2013, p. 4), ele é baseado nas teorias empíricas
de controle de processo, ou empirismo. O empirismo garante que o conhecimento
vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum
emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade
e o controle de riscos.
São três os pilares que apoiam a implementação de controle de processo

empírico: transparência, inspeção e adaptação, que detalharemos a seguir:
Transparência: Aspectos significativos do processo devem estar

visíveis aos responsáveis pelos resultados. Esta transparência requer
aspectos definidos por um padrão comum para que os observadores
compartilhem um mesmo entendimento do que está sendo visto.
Por exemplo:
• Uma linguagem comum referindo-se ao processo deve ser
compartilhada por todos os participantes; e,
• Uma definição comum de “Pronto” deve ser compartilhada por
aqueles que realizam o trabalho e por aqueles que aceitam o resultado
do trabalho.
Inspeção: Os usuários Scrum devem, com frequência, vistoriar os
artefatos Scrum e o desenvolvimento em direção a detectar variações.
Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a
própria execução das tarefas. As inspeções são mais benéficas quando
realizadas de forma diligente por inspetores especializados no trabalho
a se verificar.
37
Adaptação: Se um inspetor determina que um (ou mais) aspectos de

um processo desviou para fora dos limites aceitáveis, e que o produto
resultado será inaceitável, o processo ou o material sendo produzido
deve ser ajustado. O ajuste deve ser realizado o mais breve possível,
para minimizar mais desvios.
O Scrum (2013, p.4) prescreve quatro eventos formais, contidos dentro dos
limites da Sprint, para inspeção e adaptação, como descrito na seção Eventos do
Scrum deste documento.
• Reunião de planejamento da Sprint

• Reunião diária
• Reunião de revisão da Sprint
• Retrospectiva da Sprint
Steffen (2011) afirma que o Scrum não é um processo ou uma técnica,

mas um framework que, quando usado puro ou em conjunto com demais práticas
ou processos, promove maior flexibilidade, visibilidade e produtividade, além,
é claro, de outros benefícios que ainda serão abordados. É importante que
fique claro que Scrum não é uma abordagem prescritiva. Não é um processo
previsível, ele não define o que fazer em toda circunstância. É uma ferramenta,
um framework, um conjunto de práticas que torna tudo visível. O Scrum deixa
muitas decisões a critério da equipe, porque acredita que a equipe sabe como
melhor resolver algum problema apresentado, assim como quais práticas ela
está madura suficiente para adotar. Ainda segundo a autora, os envolvidos em
um projeto podem ser divididos em dois grupos:
• Stakeholders (interessados no produto, mas não comprometidos)

• Time Scrum, que é composto do Product Owner, ScrumMaster e equipe de
desenvolvimento (7 + ou - 2, ou seja, de 5 até 9 pessoas).
O Product Owner gerencia o product Backlog
• Representa todos os demais stakeholders (cliente, usuários, representantes de
negócios, etc.).
• Responsável por definir a funcionalidade do produto
• Foco nos negócios. É responsável pelo gerenciamento do Product Backlog,
pelo ROI e prioridades.
• Responsável pelo aceite do produto - resultado de cada Sprint.
• Não é um comitê, mas uma única pessoa.
• É o único responsável pela manutenção do Backlog.
• Não pode ser o ScrumMaster
• Define para onde o time deve ir mas não como chegar lá, não em qual
velocidade.
O ScrumMaster é quem gerencia o processo, ele é o facilitador da equipe

e é responsável por:
• Garantir que os valores e as práticas do Scrum foram entendidos pelo time e

estão sendo seguidos.
38
• Ensinar e treinar a equipe de forma que ela seja autogerenciável e multifuncional.

• Ensinar/Garantir que o Product Owner também está desempenhando seu
trabalho.
• Remover impedimentos (visíveis e não visíveis) (internos e externos).
• Motivar e manter a saúde da equipe, trabalho em equipe, comunicação,
minimizando atritos e promovendo a cooperação.
• Assegurar a melhoria contínua.
• Gerenciar as expectativas.
• Obter o comprometimento das partes (Stakeholders e Equipe).
O time de desenvolvimento se gerencia, sendo:
• Responsável por tornar os requisitos em um produto para o usuário.

• Responsável pela entrega do produto e pela qualidade do mesmo.
• Deve ser composto de todos os membros necessários para tomar decisões e
realizar as tarefas, ou seja, é multifuncional.
• Responsável pela seleção, detalhamento das atividades e estimativas de
cada Sprint e pelo comprometimento do trabalho a ser executado, ou seja,
é autogerenciado, nenhum gestor define quem irá realizar determinada
tarefa. Eles se auto-organizam para realizar e terminar o prometido no prazo
especificado.
• Compartilham as responsabilidades.
• Trabalham como uma equipe para desenhar, codificar, testar e implementar o
produto de SW.
• No Time Scrum não existe necessariamente uma divisão funcional através de
papéis tradicionais, tais como programador, designer, analista de testes ou
arquiteto e troca de bastões.
• Todos no projeto trabalham juntos (colaboram) para completar o conjunto de
trabalho com o qual se comprometeram conjuntamente para um Sprint.
FONTE: Disponível em: <https://www.ibm.com/developerworks/community/blogs/rationalbrasil/

entry/scrum_basicamente14?lang=en>. Acesso em: 11 abr. 2016.
2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos

(DSDM)
Este método oferece uma metodologia para construir e manter sistemas que
atendem restrições de prazo apertado através do uso de prototipagem incremental
em um ambiente de projeto controlado. Baseia-se em uma versão modificada do
princípio de Pareto, de que 80% de uma aplicação pode ser entregue em 20% do
tempo que levaria a aplicação completa (100%).
Somente o trabalho suficiente é requisitado para cada incremento, para

facilitar o movimento para o próximo incremento. Os detalhes remanescentes
podem ser completados depois, quando outros requisitos de negócio forem
conhecidos ou alterações tiverem sido solicitadas e acomodadas.
39
2.2.5 Crystal
Alistair Cockburn e Jim Highsmith criaram a família Crystal de métodos
ágeis, visando conseguir elaborar uma abordagem de desenvolvimento de software
que priorizasse a adaptabilidade (“maneuverability”) durante o que Cockburn
caracteriza como um “jogo de invenção e comunicação cooperativo e com recursos
limitados, tendo como primeiro objetivo entregar software útil em funcionamento
e, como segundo, preparar-se para o jogo seguinte”, conforme Pressman (2011).
Ainda segundo o autor, para conseguir a adaptabilidade os criadores definiram
um conjunto de metodologias com elementos essenciais comuns a todas, mas com
papéis, padrões de processos, produtos de trabalho e prática únicos para cada uma
delas. Na verdade, a família Crystal é um conjunto de exemplos de processos
ágeis que provaram ser efetivos para diferentes tipos de projetos. A intenção é
possibilitar que equipes ágeis selecionem o membro da família Crystal mais
apropriado para seu projeto e ambiente.
2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD)

Como outras abordagens ágeis, o FDD adota uma filosofia que enfatiza a
colaboração entre as pessoas da equipe FDD; gerencia problemas e complexidade
de projetos, utilizando a decomposição baseada em funcionalidades, seguida pela
integração dos incrementos de software e comunicação de detalhes técnicos usando
meios verbais, gráficos e de texto Pressman (2008, p.98).
A abordagem FDD define cinco atividades metodológicas “colaborativas”,

conforme mostrado na Figura 21. Essa abordagem oferece maior ênfase às diretrizes
e técnicas de gerenciamento de projeto do que muitos outros métodos ágeis.
40
FIGURA 21 - DESENVOLVIMENTO DIRIGIDO A FUNCIONALIDADES
Fonte: Pressman (2011, p. 98)
2.2.7 Desenvolvimento de Software Enxuto (LSD)

Esse método pode ser sintetizado em: eliminar desperdícios, incorporar
qualidade, criar conhecimento, adiar compromissos, entregar rápido, respeitar
as pessoas e otimizar o todo. Cada princípio pode ser adaptado ao processo de
software.
2.2.8 Modelagem Ágil (AM)

Quando se fala em Modelagem Ágil, Pressman (2011) aponta que esta
adota todos os valores consistentes com o Manifesto Ágil. Sua filosofia reconhece
que uma equipe ágil deve ter a coragem de tomar decisões que possam causar a
rejeição de um projeto e sua refabricação. A equipe também deve ter a humildade
para reconhecer que os profissionais de tecnologia não possuem todas as respostas e
que os experts em negócios e outros profissionais envolvidos devem ser respeitados
e integrados ao processo.
O autor continua mostrando que Modelagem Ágil é particular no

desenvolvimento de sistemas. Embora sugira uma ampla gama de princípios de
modelagem essenciais e suplementares, os que a tornam única são:
• Modele com um objetivo.

• Use modelos múltiplos.
• Viajar leve.
• Conteúdo é mais importante do que a representação.
• Tenha conhecimento, domínio dos modelos e das ferramentas que for
utilizar.
• Adapte localmente
41
2.2.9 Processo Unificado Ágil (AUP)

Adota, segundo Pressman (2011), a filosofia serial para o que é amplo e
iterativa para o que é particular no desenvolvimento de sistemas. Adotando as
atividades clássicas: início, elaboração, construção e transição. Essa metodologia
fornece uma camada serial, ou seja, uma sequência linear de atividades, que
capacita a equipe visualizar o fluxo do processo geral de um projeto de software.
Entretanto, dentro de cada atividade, a equipe itera ou se repete para alcançar a
agilidade e para entregar incrementos de software significativo para os usuários
finais tão rapidamente quanto possível. Cada atividade dirige-se para as seguintes
atividades: Modelagem, Implementação, Teste, Aplicação e Configuração.
2.2.10 Rational Unified Process (RUP)

Segundo Vianna (2016), a Rational é bem conhecida pelo seu investimento
em Orientação a objetos. A empresa foi a criadora da Unified Modeling Language
(UML), assim como de várias ferramentas que a suportam, sendo a mais conhecida
o Rational Rose. O Rational Unified Process (RUP) é uma metodologia completa
criada pela Rational para viabilizar que grandes projetos de software sejam bem-
sucedidos. O RUP é na verdade um produto composto de material de referência
na forma de páginas HTML, descrevendo toda a metodologia.
O RUP reconhece que os modelos de processo convencionais apresentam

uma visão única do processo. Em contrapartida, o RUP é normalmente descrito em
três perspectivas, segundo Sommerville (2011, p. 34):
1. Uma perspectiva dinâmica, que mostra as fases do modelo ao longo

do tempo.
2. Uma perspectiva estática, que mostra as atividades realizadas no
processo.
3. Uma perspectiva prática, que sugere boas práticas a serem usadas
durante o processo.
O RUP adota as seguintes premissas básicas: Uso de iterações para evitar

o impacto de mudanças no projeto, Gerenciamento de mudanças e Abordagens
dos pontos de maior risco, o mais cedo possível. A estrutura básica do RUP é
apresentada na Figura 22, o projeto passa por quatro fases básicas. Estas fases são,
de acordo com Sommerville (2011, p.34):
• Concepção - entendimento da necessidade e visão do projeto,

• Elaboração - especificação e abordagem dos pontos de maior risco,
• Construção - desenvolvimento principal do sistema,
• Transição - ajustes, implantação e transferência de propriedade do sistema.
42
FIGURA 22 - FASES RUP
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-o-

processo-unificado-integrado-ao-desenvolvimento-web/8032>. Acesso em: 22 mar. 2016.
Em relação a essas fases, Vianna (2016) aponta que:
Apesar de parecer um modelo em cascata, na verdade cada fase é

composta de uma ou mais iterações, o que se assemelha a um modelo
em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam
algumas poucas funções do sistema. Isto reduz o impacto de mudanças,
pois quanto menor o tempo, menor a probabilidade de haver uma
mudança neste período para as funções em questão.
A visão estática do RUP dá prioridade às atividades que ocorrem durante

o processo de desenvolvimento. Segundo o RUP, essas são chamadas de workflows.
Segundo Pressmman (2011, p. 34), existem seis workflows centrais, identificadas no
processo, e três no de apoio, conforme mostra a Tabela 1.
43
TABELA 1 - WORKFLOWS ESTÁTICOS NO RUP
Workflow Descrição
Modelagem de Os processos de negócios são modelados por meio de caso de
negócios uso de negócios.
Atores que interagem com o sistema são identificados e casos
Requisitos de uso são desenvolvidos para modelar os requisitos do
sistema.
Um modelo de projeto é criado e documentado com modelos
Análise de
de arquitetura, modelos de componentes, modelos de objetos
projeto
e modelos de sequência.
Os componentes do sistema são implementados e estruturados
em subsistemas de implementação. A geração automática de
Implementação
código a partir de modelos de projeto ajuda a acelerar esse
processo.
O teste é um processo iterativo que é feito em conjunto com
Teste a implementação. O teste do sistema segue a conclusão da
implementação.
Um release do produto é criado, distribuído aos usuários e
Implantação
instalado em seu local de trabalho.
Gerenciamento
de configuração e Esse workflow de apoio gerencia as mudanças do sistema.
mudanças
Gerenciamento Esse workflow de apoio gerencia o desenvolvimento do
de projeto sistema.
Esse workflow está relacionado com a disponibilização de
Meio ambiente ferramentas apropriadas para a equipe de desenvolvimento
de software.
Fonte: Adaptado de Sommerville (2011, p. 35)
DICAS
Os workflows de apoio são bem mais amplos em suas definições, pesquise e leia
a respeito em Sommerville (2011), capítulos 22, 23 e 25. Acesso à documentação do RUP em
http://www.wthreex.com/rup/portugues/index.htm
44
LEITURA COMPLEMENTAR
ANÁLISE COMPARATIVA DA UTILIZAÇÃO DO MODELO TRADICIONAL

(WATERFALL) DE DESENVOLVIMENTO DE PROJETOS E O MODELO
ÁGIL (AGILE)EM FÁBRICAS DE SOFTWARE
Mario Augusto Rivas
Resumo: Nos últimos anos a utilização das metodologias ágeis na indústria

da tecnologia da informação tem aumentando consideravelmente, devido entre
outros fatores à alta produtividade e qualidade dos produtos elaborados. Neste
cenário, fábricas de software que tradicionalmente utilizavam a metodologia
tradicional nas iniciativas de desenvolvimento, estão começando a aplicar
frameworks ágeis tais como Scrum ou XP. O presente artigo desenvolve uma análise
comparativa entre o modelo tradicional (waterfall) e o modelo ágil no contexto das
fábricas de software, destacando os principais tópicos que devem ser considerados
na avaliação da metodologia, por meio de uma matriz comparativa.
Palavras-chave: Agile; Scrum; Waterfall; Fábrica de Software.
1 INTRODUÇÃO
A metodologia tradicional de desenvolvimento de software (waterfall) baseia-

se numa sequência de estágios de produção independentes, que têm por objetivo
entregar, ao final desta, o produto definido na fase inicial. Este processo linear
de desenvolvimento é apontado como um dos responsáveis pelo baixo índice de
sucesso dos projetos de software, em razão de atores tais como a imprevisibilidade
dos requisitos, mudança continua do ambiente e a utilização de métodos orientados
a processos em vez de pessoas.
As metodologias ágeis, em contrapartida, estão orientadas a flexibilizar a

cadeia produtiva de software, no intuito de focalizar no produto em detrimento
da burocracia do processo. Perante esta situação, surge nas fábricas de software
a necessidade de entender a aplicabilidade destas metodologias como fator de
vantagem competitiva dentro do contexto operacional e comercial.
a) Objetivo
O objetivo principal deste trabalho é comparar a implantação das principais

premissas dos modelos tradicional (Waterfall) e ágil (Agile) nas fábricas de software,
considerando a taxonomia e o contexto destas.
b) Problema
O problema de muitos artigos e trabalhos acadêmicos têm focalizado

na problemática da migração do modelo tradicional para o modelo ágil, porém
não foi possível achar artigos que tratem o processo de análise que antecede à
45
decisão estratégica de migrar. Alguns autores destacam a resistência que pode

acontecer nas organizações que adotem o modelo ágil, por conta da incerteza
inerente ao custo e duração do projeto, embora o modelo tradicional também não
ofereça nenhuma assertividade nestes quesitos. Outros autores, concluem que
“estrutura e culturas organizacionais orientadas à inovação podem se engajar mais
facilmente no modelo ágil que as organizações construídas em base a burocracia
e formalização. As organizações devem avaliar cuidadosamente se estão prontas
para percorrer o caminho ágil”.
Dito processo decisório é influenciado não somente pelas diferencias

estruturais dos modelos senão também pelo contexto da própria fábrica de software
e do mercado, variáveis que não podem ser generalizadas.
A relevância deste trabalho reside em apresentar uma versão consolidada

da comparação dos modelos tradicional e ágil, desde o ponto de vista funcional das
fábricas de software, no intuito de facilitar a tomada de decisão nas organizações.
c) Hipótese
A hipótese sugerida é que a escolha de uma metodologia de

desenvolvimento depende de fatores intrínsecos do projeto e da fábrica de software,
e sua aplicabilidade não pode ser generalizada sem considerar o contexto interno e
externo da organização.
A metodologia proposta para desenvolver este trabalho baseia-se na

pesquisa bibliográfica tradicional do tipo conceitual, contemplando a gestão de
fábricas de software e os modelos de gestão de desenvolvimento tradicional e ágil.
Uma revisão bibliográfica tradicional conceitual busca sintetizar diferentes áreas
de conhecimento conceitual, contribuindo para um melhor entendimento das
questões.
d) Justificativa Fundamentada
O desenvolvimento de software nos últimos 30 anos evoluiu do conceito

artesanal vinculado a indivíduos altamente técnicos trabalhando isoladamente,
ao surgimento de fábricas de software com times colaborativos distribuídos
globalmente.
As metodologias de desenvolvimento não acompanharam o mesmo ritmo

de mudanças, gerando uma defasagem entre processo e tecnologia que só veio
a ser evidenciada com a aparição dos modelos ágeis. Neste contexto as fábricas
de software enfrentam a necessidade de adotar novas metodologias para evitar a
perda de posicionamento no mercado, incluindo a utilização de modelos ágeis,
eventualmente sem a devida avaliação organizacional prévia.
46
2 FÁBRICAS DE SOFTWARE
O desenvolvimento de software era originalmente uma tarefa realizada por

técnicos individuais especializados na linguagem de programação, no sistema
operacional e no próprio computador. A imprevisibilidade do desempenho dos
programadores levou Robert Bemer a criar o termo “fábrica de software”, sugerindo
a criação destas unidades nas organizações, utilizando suas próprias ferramentas
e processos.
a) Origem e Definição
O conceito de “fábrica de software” evoluiu nos anos 1960 e 1970, nos

Estados Unidos e no Japão. A primeira fábrica de software foi a Hitachi Software em
1969, pondo em prática a ideia dos executivos dessa empresa de separar o grupo
de desenvolvimento de software do restante da empresa. Nos Estados Unidos a
System Development Corp (SDC), que seria integrada à Unisys mais tarde, implantou
na sua fábrica de software de Santa Monica uma organização baseada em três
elementos: um conjunto integrado de ferramentas; procedimentos e políticas de
gerenciamento padronizadas e uma organização matricial.
O termo “fábrica de software” pode ser definido como a organização

previsível e controlada dos elementos que compõem o desenvolvimento de
software, incluindo processos, recursos e conhecimento. Esta definição enquadra
as fábricas de software numa dimensão maior do que simplesmente a produção de
código fonte, abrangendo potencialmente fábricas de testes ou especificações, por
exemplo.
b) Modelos operacionais
As fábricas de software podem ser classificadas de acordo com seu escopo

de fornecimento. Fábricas dedicadas somente à codificação e teste unitário
compõem o segmento menor nesta classificação, seguido em ordem crescente
pelas fábricas de projetos físicos que incluem o desenho detalhado e os testes
integrados e de aceitação, e pelas fábricas de projetos de software que abrangem
todas as atividades desde o projeto conceitual. Fernandes ainda descreve um nível
superior de “fábricas de projetos ampliadas”, cujos escopos transcendem a visão
tecnológica. O modelo de outsourcing de sistemas como especialização da fábrica
de projetos e a fábrica de componentes, também fazem parte desta classificação.
47
CLASSIFICAÇÃO DAS FÁBRICAS DE SOFTWARE
Todos os tipos de fábrica de software, independente da classificação,

possuem processos definidos que atendem às necessidades da linha de produção.
No caso das fábricas de programas, por exemplo, o processo central refere-se à
construção e teste unitário dos programas, e deve estar baseado na adoção de alguns
dos frameworks de mercado (waterfall, RUP, Scrum, etc.). Isto não é necessariamente
válido para as fábricas de projetos de software, nas quais o processo central é o
gerenciamento de projetos e os frameworks adotados são outros (PMBOK, PRINCE
2, etc.).
3 MODELO TRADICIONAL DE DESENVOLVIMENTO
Até meados dos anos 60 o papel do software foi secundário em relação

ao hardware, na indústria da computação. Esta situação começou a mudar com a
chegada das primeiras linguagens de programação teoricamente independentes do
hardware (Fortran, Algol, Cobol, etc.), abrindo possibilidades para a reutilização do
software e das técnicas de programação. No ano 1970 o Dr. Winston Royce publicou
o artigo original que deu origem ao framework mais popular de desenvolvimento
de software, chamado waterfall (cascata). Este modelo baseia-se na sequência de
atividades padronizadas cujos resultados individuais são utilizados como pré-
requisito para a atividade subsequente, graficamente descrito como uma cascata
que começa com os requisitos do sistema e termina com a operação (execução)
deste.
a) O Modelo de Gestão de Desenvolvimento do Dr. Winston Royce
Embora a adoção do modelo do Dr. Royce (waterfall) fosse quase total na

comunidade do software, os conceitos nele expressados foram simplificados ou
reduzidos num modelo linear conhecido como “cascata”.
48
MODELO WATERFALL
O desenho original do Dr. Royce envolve a iteração entre fases consecutivas

do waterfall, no entendimento de que o resultado de cada fase pode ter impacto na
fase anterior. Por exemplo, na fase de desenho podem ser encontrados elementos
novos que impactem a análise feita, logo a fase de análise precisa ser revisitada.
Isto pode parecer obvio no relacionamento entre as fases de teste e codificação,
porém para o resto do processo não é considerado com fins de planejamento.
Eventualmente o Dr. Royce destaca o risco inerente deste modelo: “Eu acredito
neste conceito, mas a implementação descrita acima [waterfall] possui riscos e
convida às falhas”.
Na opinião do autor do modelo, o maior risco é o fato de que as iterações

transcendam as fases consecutivas e gerem uma revisão total do desenho (design),
pois, caso exista uma incompatibilidade entre os novos requisitos e o desenho
atual, as mudanças necessárias podem ser tão destrutivas, que impliquem em um
completo redesenho do sistema.
A proposta do Royce para mitigar os riscos decorrentes do modelo é

composta pelos seguintes passos:
1) criar uma fase de desenho preliminar do software antes da fase de análise;

2) gerar documentação abrangente do desenho;
3) a partir do desenho preliminar fazer uma simulação completa do processo
(flexibilizando os requisitos de documentação), para chegar num protótipo ou
versão “1” que possa ser utilizada para o processo completo;
4) planejar, controlar e monitorar o teste e
5) envolver ao cliente.
a) Críticas ao Modelo Tradicional
49
Alguns autores argumentam que o método waterfall sempre foi efetivo em

projetos com requisitos bem definidos, tecnologia bem conhecida e baixo risco
geral. Neste contexto, o escopo, os requisitos, a tecnologia, as tarefas requeridas
e os níveis de recursos são suficientemente previsíveis para que o projeto possa
ser totalmente planejado antecipadamente. O modelo waterfall fundamentalmente
assume que os “sistemas são totalmente especificáveis, previsíveis e podem ser
feitos por meio de um meticuloso e extensivo planejamento”.
Estas premissas referidas pelos autores acima são claramente conflitantes

com a realidade da grande maioria dos projetos de software nos quais o fator
humano (originalmente menosprezado pelos metodologistas do software dos anos
60 e 70) revela-se como pouco previsível: “…esta técnica [waterfall] requer que
todas as boas ideias apareçam ao começo do ciclo de desenvolvimento, estágio no
qual podem ser incorporadas ao plano. Porém, como todos nós sabemos, as boas
ideias aparecem espontaneamente ao logo do processo – no começo, na metade e
mesmo um dia antes da implantação...Com a técnica waterfall, uma boa ideia que
apareça tarde no ciclo de desenvolvimento não é um presente, é uma ameaça”.
4 MODELO ÁGIL
Em fevereiro de 2001, dezessete metodologistas do software “leve” e

pensadores se reuniram para discutir e chegar a um consenso que refletisse suas
ideias e conceitos em relação à situação atual do desenvolvimento de software.
Entre eles estavam os cofundadores do Scrum, Jeff Sutherland e Ken Schwaber,
junto com Mike Beedle que trabalhou nos padrões iniciais do Scrum e foi coautor
do primeiro livro de Scrum. O grupo denominou-se ‘The Agile Alliance’ e estampou
o acordo no documento ‘Manifesto for Agile Software Development’, influenciado
pelas melhores práticas da indústria japonesa, particularmente pelos princípios de
desenvolvimento enxuto (lean) de empresas como Toyota e Honda.
a) O Manifesto Ágil
Longe de ser uma guia metodológica ou um framework, o Manifesto Ágil é

considerado uma intenção manifesta e coletiva dos seus autores, de impulsionar
uma visão inovadora na engenharia de software: “Estamos descobrindo maneiras
melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Por meio desse trabalho, passamos a valorizar: Indivíduos e
interações mais que processos e ferramentas. Software em funcionamento mais
que documentação abrangente. Colaboração com o cliente mais que negociação
de contratos. Responder a mudanças mais que seguir um plano. Ou seja, mesmo
havendo valor nos itens à direita (do termo ‘mais que’), valorizamos mais os itens
à esquerda. ”.
Este enfoque da disciplina do desenvolvimento de software, radicalmente

oposto à crença tradicional que enxerga a eficiência na produção de sistemas
como fruto da evolução dos processos de engenharia, teve de enfrentar vários
paradigmas até então considerados axiomáticos entre a comunidade.
50
Claro exemplo desta situação é o reconhecimento tácito da dinâmica

dos requisitos enunciada anos antes no princípio de incerteza dos requisitos
de Humphrey: “para um sistema de software, novo os requisitos não serão
completamente conhecidos até depois que os usuários o tenham utilizado”. O
Manifesto Agile não só reconhece esta situação, mas também assume a necessidade
de integrar as mudanças de requisitos em todo o processo de desenvolvimento,
visando colaborar com o cliente na obtenção da melhor vantagem competitiva.
Outro paradigma questionado por este movimento refere ao papel do cliente no
processo de desenvolvimento, que tradicionalmente estava delimitado a definir os
requisitos de negócio e receber o produto já terminado no outro extremo da cadeia
de produção. O Manifesto Agile sugere a participação diária do cliente durante
todo o processo, não só definindo os requisitos como também participando das
decisões que afetam o produto a ser criado.
Nos anos subsequentes à criação da Agile Alliance, surgiram em Europa e

nos Estados Unidos diversos frameworks de desenvolvimento, orientados a difundir
o Manifesto Agile nas organizações, dos quais o mais popular até hoje é o Scrum.
b) Scrum
De acordo com um dos criadores, o Scrum é um framework simples

utilizado para organizar as equipes e fazer o trabalho de forma mais produtiva e
com alta qualidade. A origem do termo refere a uma formação clássica do rugby,
na qual um grupo pequeno, coeso e organizado de jogadores, consegue elencar os
esforços individuais num objetivo comum. O Scrum focaliza na geração do valor
agregado para o cliente, eliminando o desperdiço e priorizando a entrega periódica
de software funcional. Essa entrega periódica decorre da estrutura iterativa do
processo, conformada por períodos de duas (2) a quatro (4) semanas chamados
Sprints, cada um dos quais se encerra com a entrega de um incremento no produto
final.
O Scrum possui três (3) papéis, três (3) cerimônias e três (3) artefatos. O
Product Owner (dono do produto) tem como responsabilidade definir os requisitos
do produto; decidir a data de implantação e o conteúdo; priorizar os requisitos de
acordo ao valor agregado e aceitar ou rejeitar os resultados do trabalho. Embora
o framework não inclua a participação de um gerente de projeto, o papel de líder
da equipe é adjudicado ao Scrum Master, quem deve atuar como um facilitador
assegurando que a equipe esteja produtiva e funcional; removendo barreiras e
blindando a equipe de interferências externas, além de assegurar que o framework
seja seguido. O terceiro papel é a própria equipe de desenvolvimento, que tem por
responsabilidades a produção do trabalho, sendo auto-organizada em todos os
aspectos.
O Scrum prevê uma cerimônia ou reunião ao começo de cada iteração

denominada Sprint Planning, na qual são definidos os requisitos que a equipe
irá entregar ao final do sprint. Vale ressaltar que as reuniões do Scrum têm sido
chamadas de cerimônias pelos praticantes deste framework no Brasil, pois os
treinamentos oficiais têm usado majoritariamente essa terminologia. Todos os
51
dias durante o sprint acontece a reunião diária de alinhamento conhecida como

Daily Scrum Meeting, geralmente feita numa sala sem cadeiras (standup meeting ou
reunião em pé) para estimular a objetividade da reunião. O objetivo desta é que
cada membro da equipe responda as perguntas:
a) O que foi feito ontem?

b) O que será feito hoje?
c) Quais os problemas que estão sendo enfrentados?
A terceira cerimônia requerida pelo Scrum é o Sprint Review Meeting,

que tem por objetivos revisar o que está sendo entregue ao cliente e analisar o
funcionamento da equipe durante o sprint, também chamado de Sprint Retrospective.
Alinhado com as premissas do Manifesto Agile que priorizam o software em

funcionamento mais que a documentação abrangente, Scrum exige somente três (3)
artefatos documentais: o Product Backlog que contém os requisitos ainda não criados
do produto, o Sprint Backlog descrevendo os requisitos a serem desenvolvidos no
sprint e o Burndown Chart, gráfico que expõe o avanço na execução dos requisitos
ao longo do sprint e serve como status do projeto.
O CICLO DO SCRUM
52
c) Aplicabilidade do Scrum em projetos de grande escala e missão crítica
Embora existam numerosos casos de sucesso em implantações de Scrum,

ainda persistem na comunidade acadêmica e na indústria de tecnologia de
informação dúvidas respeito à aplicabilidade deste framework em projetos de
grande escala e/ou missão crítica. Alguns autores argumentam que a maioria dos
projetos desenvolvidos com Scrum é de pequena escala e relativamente simples,
com grande sucesso. Entretanto, existem poucos e muito limitados estudos
referentes à aplicabilidade do Scrum em grandes projetos.
Na opinião dos autores, ainda não existem dados conclusivos para

determinar a aplicabilidade do framework neste tipo de projetos, porém sugerem
os seguintes pontos a serem considerados:
• Investir tempo na composição idônea das equipes, considerando os

projetos nos quais trabalharão.
• Escolher um Scrum Master que não só remova os impedimentos para
avançar no projeto, senão que seja capaz de gerenciar a consistência do produto
horizontalmente entre os times do projeto.
• Dedicar suficiente tempo para o planejamento e desenho.
• Adaptar o framework de acordo à natureza do projeto.
Outra dimensão importante que deve ser considerada em projetos de grande

escala advém do fato comum na indústria de software de terceirizar segmentos
do desenvolvimento, muitas vezes para locações distantes geograficamente como
Índia e China. Os autores sugerem a adaptação eventual do framework ágil escolhido
para resolver problemas decorrentes da separação dos times. “As práticas ágeis
modificadas resolvem este problema [a separação geográfica] dissolvendo algumas
das práticas do framework enquanto se mantém a essência dos princípios e valores
ágeis, e fornecendo uma nova estrutura de colaboração. Esta nova estrutura não é
burocrática, porem pode ser ajustada em base às necessidades e níveis de confiança
da organização”.
5 ANÁLISE COMPARTIVA DOS MODELOS
De acordo com o exposto anteriormente, o modelo ágil para gestão do

desenvolvimento possui diferenças significativas em relação ao modelo tradicional
ou waterfall, às quais serão explicitadas em relação aos tipos de fábricas de software
propostos.
a) Gestão dos Requisitos e Escopo
O modelo tradicional tem como premissa a preexistência dos requisitos do

cliente detalhados e completos, assumindo que todo o contexto pode ser definido a
priori pelo demandante, i.e. o cliente. Os requisitos no modelo ágil são dinâmicos e
podem ser modificados durante todo o processo de desenvolvimento. “Mudanças
nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos
ágeis tiram vantagem das mudanças com o propósito de alcançar vantagem
53
competitiva para o cliente”. Embora o impacto da gestão dos requisitos seja maior
para fábricas de programas ou componentes, em geral é o modelo comercial
destas que define o impacto real. Modelos de contratação “fixed price/fixed time”
são claramente os mais afetados.
b) Processo e Controle
O Manifesto Ágil prioriza as interações e os indivíduos perante as

ferramentas e os processos. Neste ponto a diferença em relação ao modelo
tradicional se manifesta claramente, devido ao fato deste último ser totalmente
atrelado a processos estritos, similares a uma linha de produção industrial. A
necessidade de reconhecer o indivíduo como elemento fundamental da produção
no modelo ágil, se contrapõe à visão mecanicista do modelo tradicional, na qual a
aderência aos processos de engenharia é a chave do sucesso. Isto se reflete também
nos perfis de liderança sugeridos pelas metodologias baseadas nos modelos
tradicional e ágil. Enquanto no modelo tradicional a liderança é manifesta através
do comando e controle, normalmente personificado no papel do Gestor do Projeto
(Project Manager), o Scrum define o Scrum Master como um papel de facilitador que
ajuda ao time alcançar as metas e que tem escassa autoridade formal.
c) Envolvimento do Cliente
No modelo tradicional o cliente cumpre um papel importante no começo e

no fim do projeto, quando são feitas as definições dos requisitos e a homologação
dos resultados, respectivamente. Muito pelo contrário, nos projetos gerenciados
no modelo ágil, o cliente é um papel fundamental, participando ativamente ao
longo de todo o processo.
Por definição, as fábricas de software são estruturas lógicas isoladas das

áreas de negócios ou incluso empresas externas à organização cliente, motivo
pelo qual o envolvimento direto do cliente acontece (geralmente) nos eventos
administrativos padrão (contratação, pagamentos, etc.). A vinculação permanente
dentro do processo da fábrica, como sugere o modelo ágil, envolve certo grau de
dificuldade para as fábricas externas à organização cliente, e se faz pouco produtivo
para fábricas de menor porte (programas, componentes e projeto físico).
d) Gestão da Documentação
Segundo o Manifesto Agile, a prioridade sempre é o software em

funcionamento, mais que a documentação extensiva, logo a gestão da documentação
ocupa um lugar menos importante na gestão do projeto, até mesmo porque o
próprio código gerado deve servir como documentação tácita. Contrariamente, o
modelo tradicional adota uma política de documentação explícita.
“Ocasionalmente sou solicitado para revisar o progresso de outros

desenhos de software. Meu primeiro passo é investigar o estado da documentação.
Se a documentação está em falta minha primeira recomendação é simples.
Substitua o gerente do projeto. Pare todas as atividades que não sejam relacionadas
54
à documentação. Coloque a documentação no padrão adequado. A gestão do

software é simplesmente impossível sem um grande volume de documentação”.
Para as fábricas de programas ou componentes, a documentação é de

caráter técnico e mudanças do modelo tradicional para o modelo ágil não deveriam
representar maiores impactos. Enquanto aos outros tipos de fábrica de software, o
impacto é diretamente proporcional à complexidade e diversidade das atividades
nelas desenvolvidas.
e) Matriz de Comparação
A Tabela 1 exibe um resumo dos impactos decorrentes da aplicação das

premissas acima discutidas, nos distintos tipos de fábrica de software.
55
IMPACTO COMPARATIVO DA ADOÇÃO DAS PREMISSAS DOS MODELOS TRADICIONAL E AGILE

NOS DISTINTOS TIPOS DE FÁBRICA DE SOFTWARE.
CONCLUSÃO
Nos últimos anos observou-se uma tendência importante de adoção das

metodologias ágeis no mercado das fábricas de software. Numerosos trabalhos
acadêmicos tem abordado esta temática do ponto de vista operacional, porém
nem sempre a comparação entre os modelos tradicional e Agile foi contextualizada
no conceito de fábrica de software. As fábricas podem ser classificadas segundo
o escopo de atuação em fábricas de programas e/ou componentes, fábricas de
projetos físicos, fábricas de projetos de software e/ou outsourcing, e fábricas de
projetos ampliadas. O modelo tradicional desenvolvido a partir do trabalho
de Royce, mais conhecido como Waterfall ou cascata, foi durante muitos anos o
56
padrão para a gestão do desenvolvimento. Sua estrutura linear, semelhante a uma

linha de produção industrial, e fortemente separada em etapas isoladas, facilitou
sua rápida assimilação. À medida que a engenharia de software evoluiu, falhas
importantes foram encontradas neste modelo, originárias em suas premissas
relativas à imutabilidade dos requisitos decorrente do modelo linear. Em resposta
a essa situação, um grupo de metodologista de software redigiu o Manifesto Agile,
definindo as bases conceituais do modelo ágil. Este modelo prioriza a interação e as
pessoas, mais que as ferramentas e os processos, o software em funcionamento mais
que documentação abrangente, colaboração com o cliente mais que negociação
de contratos e resposta às mudanças mais que seguir o plano. O modelo ágil
reconhece que os requisitos vão mudar constantemente ao longo do processo de
desenvolvimento, em parte devido à própria natureza dos seres humanos que
trabalham nele, e faz questão de aproveitar a evolução dos requisitos para entregar
um produto de maior valor para o cliente.
Na comparação entre os dois modelos surgiram quatro (4) tópicos de

destaque: gestão de requisitos, processos e controle, envolvimento do cliente
e gestão da documentação. Para cada um destes, foi feita uma comparação
contextualizada em cada tipo de fábrica de software (representada na Tabela 1) e
ponderada segundo o impacto que teria para ser implantada em cada instância. Foi
constatado que as fábricas de programas/componentes não apresentam vantagens
importantes na adoção das premissas do modelo ágil; pelo contrário, em razão do
escopo reduzido de atuação, fatores como a estabilidade dos requisitos resultam
muito favoráveis. Contrariamente, as mesmas premissas aplicadas às fábricas de
projetos físicos sugerem um panorama mais favorável para o modelo ágil por conta
da flexibilidade dos processos e da redução da documentação. Esta tendência se
intensifica no caso das fábricas de projetos de software e das fábricas de software
ampliada, nas quais o envolvimento do cliente.
Em razão das limitações deste artigo, grandes generalizações foram

assumidas na criação da matriz comparativa, motivo pelo qual as recomendações
nela contidas não devem se considerar como regra geral senão como elemento de
contexto na tomada de decisões estratégica. Elementos como o modelo comercial da
organização, regulamentações locais e contexto tecnológico, não foram avaliados
explicitamente, porém são fatores decisórios importantes na escolha do modelo
de desenvolvimento da fábrica de software. De acordo ao exposto como hipótese
na introdução deste artigo, confirma-se que a escolha de uma metodologia de
desenvolvimento depende de fatores intrínsecos do projeto e da fábrica de software,
e sua aplicabilidade não pode ser generalizada sem considerar o contexto interno e
externo da organização. A matriz de comparação exposta neste artigo deve servir
como marco de referência para dita escolha, sendo um elemento passível de ser
detalhado em futuros trabalhos acadêmicos.
a) Implicações e Recomendações para a Prática
A análise apresentada neste trabalho revela a importância de considerar

o escopo da fábrica de software em cada um dos fatores comparados, na escolha
do modelo de gestão do desenvolvimento. Desta forma, surge uma primeira
57
recomendação implícita para evitar o reducionismo de analisar somente o modelo

per se no processo decisório, sem contextualizar adequadamente na estrutura
da fábrica. Recomenda-se também a utilização (sujeita a adaptações) da matriz
de comparação desenvolvida neste trabalho, como ferramenta de abstração e
benchmarking para a tomada de decisões respeito ao modelo.
b) Limitações do Estudo
Como mencionado anteriormente, existem diversos fatores comerciais,

tecnológicos e regulatórios no contexto da fábrica de software, que não foram
adequadamente considerados neste trabalho por conta das limitações de espaço
predefinidas.
Outra limitação conhecida deste trabalho refere à possibilidade de modelos

híbridos entre os modelos tradicional e ágil durante a fase de migração, como
sugerido por Cohn. Esta opção foi propositalmente excluída do escopo da análise
apresentada neste artigo, no intuito de manter o foco no objetivo da comparação.
Cabe destacar também a ausência neste artigo de casos de estudo diretos

apoiando a pesquisa bibliográfica, relativizando os resultados ao marco teórico.
c) Sugestões de Pesquisas Futuras
Conforme destacado nas limitações do estudo, a ausência de casos práticos

impõe restrições às conclusões deste trabalho. Uma primeira sugestão é a ampliação
do escopo deste artigo com a inclusão de casos de estudo significativos, a fim de
estender e validar a análise comparativa dos modelos.
Uma segunda linha de pesquisa recomendada refere-se ao impacto

comercial e financeiro da migração do modelo tradicional para ágil nas fábricas
de software, na expectativa de aportar conclusões valiosas num segmento muito
pouco explorado pela bibliografia disponível. Um trabalho dessa natureza visa
responder questões centrais para os responsáveis das decisões estratégicas nas
fábricas de software, que transcendem os aspectos intrínsecos da engenharia.
FONTE: Disponível em: http://www.revistas.unifacs.br/index.php/rsc. Acesso em: 22 mar. 2016.
58
RESUMO DO TÓPICO 3
• As metodologias ágeis priorizam a comunicação e interação dentre os

participantes do projeto. Têm o objetivo de acelerar o desenvolvimento do
software visando à melhoria contínua do processo, organização diária para
o alcance da meta definida, evitar falhas na elaboração, respostas rápidas às
mudanças e aumento significativo da produtividade.
• Vimos também os 12 princípios ágeis:
a) A maior prioridade é satisfazer o cliente por meio da entrega adiantada e

contínua de software valioso.
b) Acolha bem os pedidos de alterações, mesmo atrasados no desenvolvimento.
Os processos ágeis se aproveitam das mudanças como uma vantagem
competitiva na relação com o cliente.
c) Entregue o software em funcionamento frequentemente, de algumas semanas
para alguns meses, dando preferência a intervalos mais curtos.
d) O pessoal do comercial e os desenvolvedores devem trabalhar em conjunto
diariamente ao longo de todo o projeto.
e) Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e
apoio necessários e confie neles para ter o trabalho feito.
f) O método mais eficiente e efetivo de transmitir informações para e dentro de
uma equipe de desenvolvimento é uma conversa aberta, de forma presencial.
g) Software em funcionamento é a principal medida de progresso.
h) Os processos ágeis promovem desenvolvimento sustentável. Os proponentes,
desenvolvedores e usuários devem estar capacitados para manter um ritmo
constante indefinidamente.
i) Atenção contínua para com a excelência técnica e para com bons projetos
aumenta a agilidade.
j) Simplicidade, a arte de maximizar o volume de trabalho não efetuado, é
essencial.
k) As melhores arquiteturas, requisitos e projetos emergem de equipes que se
auto-organizam.
l) A intervalos regulares, a equipe se avalia para ver como tornar-se mais
eficiente, então sintoniza e ajusta seu comportamento de acordo.
• Apresentamos uma breve descrição dos métodos ágeis mais conhecidos:
a) Extreme Programming XP
b) Desenvolvimento de Software Adaptativo (ASD)
c) Scrum
d) Método de Desenvolvimento de Sistemas Dinâmicos (DSDM)
e) Crystal
59
f) Desenvolvimento Dirigido a Funcionalidades (FDD)
g) Desenvolvimento de Software Enxuto (LSD)
h) Modelagem Ágil (AM)
i) Processo Unificado Ágil (AUP)
j) Rational Unified Process (RUP)
60
AUTOATIVIDADE
1 De acordo com a estrutura básica do RUP, o projeto passa por quatro fases
básicas. Faça a associação correta para: Concepção, Elaboração, Construção
e Transição.
_____________ Entendimento da necessidade e visão do projeto.
_____________ Desenvolvimento principal do sistema.
_____________ Especificação e abordagem dos pontos de maior risco.
_____________ Ajustes, implantação e transferência de propriedade do sistema.
2 Observe o modelo XP e o modelo SCRUM, e a seguir descreva o que é

possível determinar.
3 Explique quais são as premissas e as fases do RUP.
4 As metodologias ágeis de desenvolvimento esforçam-se para reforçar

a importância das pessoas no desenvolvimento, elas focam talentos e
habilidades de indivíduos, moldando o processo de acordo com as pessoas
e equipes específicas. Cite algumas dessas características.
5 O RUP é composto por três tipos de visões, a dinâmica, a prática e a estática.

Comente a respeito do que acontece em cada uma das etapas centrais.
61
62
UNIDADE 2
ENGENHARIA DE REQUISITOS E
EQUIPE DE DESENVOLVIMENTO
Esta unidade tem por objetivos:
• reconhecer a importância da análise de requisitos no processo de desen-

volvimento;
• perceber as diferentes etapas que fazem parte da engenharia de requisitos;
• realizar de forma consistente a atividade de análise de requisitos;
• conhecer os integrantes das equipes de desenvolvimento.
PLANO DE ESTUDOS
Está unidade está dividida em três tópicos. Em cada um deles você encon-
trará atividades que contribuirão para a apropriação dos conteúdos apresen-
tados.
TÓPICO 1 - ENGENHARIA DE REQUISITOS
TÓPICO 2 - TÉCNICAS DE LEVANTAMENTO
TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE
63
64
UNIDADE 2
TÓPICO 1
ENGENHARIA DE REQUISITOS
1 INTRODUÇÃO
Estamos sempre em movimento, mudando de opinião, de visual, de estado
civil e até mesmo de cidade. Com os softwares, isso também acontece. Você acredita
que os requisitos de um sistema permanecem inalterados ao longo do tempo? Por
exemplo, um projeto iniciado em janeiro terá os mesmos requisitos ao final de 12
meses?
Existem grandes chances de isso não acontecer, e os motivos são os mais

variados. Pode ser causado por uma mudança de hardware, a correção de um erro,
uma nova lei, ou simplesmente uma nova função a ser desenvolvida. E para que
essa mudança ou construção atenda com satisfação às necessidades do cliente, a
equipe de analistas precisa conhecer bem os objetivos a que se destina o software,
entender o negócio e conhecer os usuários. Esse conhecimento é de extrema
importância para que, na coleta de requisitos, a equipe de análise compreenda os
problemas e busque, por meio de metodologia própria, solucioná-los. Mas, o que
são requisitos?
Nos estudos desta unidade você vai encontrar apoio para responder a
essa e a outras questões relacionadas a esse processo envolvendo os requisitos do
sistema.
2 ENGENHARIA DE REQUISITOS
De uma maneira simplificada, os requisitos expressam o que o futuro
sistema deve fazer para que atenda aos usuários, além, é claro, das restrições e
características.
Requisito também pode ser definido como a condição ou capacidade de um

software que deve ser implementada por um sistema ou componentes de sistema
para que o objetivo seja por fim alcançado, segundo Engholm Jr. (2010). Ainda
de acordo com o autor, todo o projeto de software tem um conjunto de requisitos,
que são definidos pelas necessidades e expectativas dos usuários que efetivamente
usarão o software, relacionados ao atendimento dos objetivos de negócio da
empresa com que trabalham.
Durante a fase de levantamento de requisitos é o momento em que as

necessidades são exploradas por parte do desenvolvedor em companhia do cliente
65
UNIDADE 2 | ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO
e sua empresa. Para que essa etapa seja realizada com uma proposta de solução
adequada, é necessário que tarefas, como o estudo de viabilidade, licitação e
análise de requisitos, especificação e gerenciamento destes, sejam realizadas de
forma cuidadosa e consistente.
Para Sommerville (2011), os requisitos de um sistema são as descrições do

que o sistema deve fazer, os serviços que o sistema oferece, bem como as restrições
a seu funcionamento. Esses requisitos refletem a necessidade dos clientes para
um sistema com finalidade específica, seja ela controlar um dispositivo, colocar
ou buscar uma determinada informação. Esse processo de descobrir, analisar,
documentar e verificar esses serviços e restrições é chamado de Engenharia de
Requisitos (RE, do inglês requirements engineering). O autor ainda adverte sobre a
inconsistência da utilização do termo requisito, uma vez que por um lado é feita
de maneira abstrata e em alto nível dos serviços e restrições que o sistema deve
oferecer, e no outro extremo é uma definição detalhada e formal de uma função
do sistema.
Davis apud Sommerville explica essas diferenças:
Se uma empresa pretende fechar um contrato para um projeto

de desenvolvimento de software de grande porte, deve definir as
necessidades de forma abstrata o suficiente para que a solução para
essas necessidades não seja predefinida. Os requisitos precisam ser
escritos de modo que vários contratantes possam concorrer pelo
contrato e oferecer diferentes maneiras de atender às necessidades da
organização do cliente. Uma vez que o contrato tenha sido adjudicado,
o contratante deve escrever para o cliente uma definição mais detalhada
do sistema, para que este entenda e possa validar o que o software fará.
Ambos os documentos podem ser chamados documentos de requisitos
para o sistema.
Sommerville (2011) ainda alerta para alguns problemas que surgem durante
o processo de engenharia de requisitos. Que são as falhas em não fazer uma clara
separação entre os requisitos dos usuários, que expressam os requisitos abstratos
de alto nível, e os requisitos do sistema que expressam detalhadamente o que o
sistema deve fazer. Sommerville (2011, p. 58) diz que os requisitos dos usuários e
de sistemas podem ser definidos da seguinte maneira:
• Requisitos de usuário são declarações, em uma linguagem natural

com diagramas, de quais os serviços o sistema deverá fornecer a seus
usuários e as restrições com as quais deve operar.
• Requisitos de sistema são descrições mais detalhadas das funções,
serviços e restrições operacionais do sistema de software. O documento
de requisitos do sistema (às vezes, chamado especificação funcional)
deve definir exatamente o que deve ser implementado. Pode ser parte
do contrato entre o comprador do sistema e os desenvolvedores de
software.
A Tabela 2 abaixo mostra os possíveis leitores para os requisitos de

usuários e de sistemas. Como observamos, os leitores dos requisitos de usuários
não costumam, ainda segundo Sommerville (2011), se preocupar com a forma
66
TÓPICO 1 | ENGENHARIA DE REQUISITOS
como o sistema será implementado, como é o caso de gerentes que não estão
interessados nos recursos detalhados do sistema. Já os leitores dos requisitos do
sistema precisam saber mais detalhadamente o que o sistema fará, pois estão mais
interessados em como o sistema apoiará os processos dos negócios, por exemplo.
TABELA 2 - LEITORES PARA OS REQUISITOS DE USUÁRIOS E DE SISTEMAS
• Gerentes clientes.
• Usuários finais do sistema.
Requisitos de usuário • Engenheiros clientes.
• Gerentes contratantes.
• Arquitetos de sistema.
• Usuários finais do sistema.
• Engenheiros clientes.
Requisitos de sistema
• Arquitetos de sistema.
• Desenvolvedores de software.
FONTE: Adaptado de Sommerville (2010, p. 59)
A imagem a seguir demonstra de uma maneira divertida como essa falta

de entendimento entre as partes gera confusão e como o resultado pode deixar o
cliente insatisfeito.
FIGURA 23 - PROBLEMAS DE COMUNICAÇÃO
FONTE: Disponível em: <http://www.devmedia.com.br/artigo-engenharia-de-software-

introducao-a-teste-de-software/8035>. Acesso em: 22 mar. 2016.
67
E para que esses problemas sejam minimizados é muito importante que os

requisitos sejam entendidos pelas partes interessadas. E para ajudar nessa difícil
tarefa, os requisitos são divididos em dois grupos: Funcionais e não funcionais.
2.1 DEFININDO OS REQUISITOS

Os requisitos de software são frequentemente classificados como Requisitos
funcionais e Requisitos não funcionais. De acordo com Sommerville (2011, p. 59):
Requisitos funcionais: São declarações de serviços que o sistema deve

fornecer, de como o sistema deve reagir a entradas específicas e de
como o sistema deve se comportar em determinadas situações. Em
alguns casos, os requisitos funcionais também podem explicitar o que o
sistema não deve fazer.
Requisitos não funcionais: São restrições aos serviços ou funções
oferecidas pelo sistema. Incluem restrições de timing, restrições no
processo de desenvolvimento e restrições impostas pelas normas. Ao
contrário das características individuais ou serviços do sistema, os
requisitos não funcionais, muitas vezes, aplicam-se ao sistema como
um todo.
O próprio autor alerta que a distinção entre os tipos de requisitos não

é tão clara como sugerem suas definições. E afirma que os requisitos não são
independentes e que, muitas vezes, geram ou restringem outros requisitos. No
próximo tópico detalharemos um pouco mais os requisitos funcionais e não
funcionais.
2.1.1 Requisitos Funcionais

Os requisitos funcionais devem descrever as funções e as ações do sistema.
Colocando de uma maneira mais simples, esses requisitos devem dizer o que o
sistema faz, ou não faz, em algumas situações. Lembrando que essa especificação
deve ser completa e consistente.
Engholm Jr. (2010) afirma que os Requisitos funcionais são aqueles que
definem as funções ou ações fornecidas pelo sistema e que o usuário pode utilizar,
além das regras de negócio e as interfaces internas e externas.
Os Requisitos funcionais do sistema, de acordo com Sommerville (2011),

variam de requisitos gerais, que indicam o que o sistema deve fazer, até requisitos
bem específicos, que refletem os sistemas e as formas de trabalho de uma
organização.
Exemplos de Requisitos funcionais:
68
• O sistema deve permitir a inclusão, alteração e remoção de professores

com os seguintes atributos: nome, endereço, cidade, etc.
• O sistema fornecerá telas apropriadas para o usuário ler documentos.
• Cada pedido tem um único identificador.
• O sistema deve gerar diariamente, para cada unidade de ensino, a lista
dos alunos inadimplentes.
• O sistema deve permitir pesquisar a lista dos alunos com nota abaixo da
média.
Sommerville (2011, p. 60), em relação aos Requisitos funcionais, afirma que:
Em princípio, a especificação dos requisitos funcionais de um sistema

deve ser completa e consistente. Completude significa que todos os
serviços requeridos pelo usuário devem ser definidos. Consistência
significa que os requisitos não devem ter condições contraditórias. Na
prática, para sistemas grandes e complexos, é praticamente impossível
alcançar a completude e consistência de requisitos.
2.1.2 Requisitos não funcionais

Os Requisitos não funcionais, ao contrário dos funcionais, não se relacionam
com a funcionalidade do software, mas eles definem outras propriedades que
também são importantes para o sistema, como qualidade, confiabilidade,
desempenho, usabilidade, segurança, portabilidade e Integridade. (SILVA, 2014).
De acordo com Sommerville (2011), os requisitos não funcionais do sistema,

como o nome sugere, são requisitos que não estão diretamente relacionados com os
serviços específicos oferecidos pelo sistema a seus usuários. Esses requisitos podem
estar relacionados às propriedades como confiabilidade e tempo de resposta.
Ainda de acordo com o autor, a Figura 24 apresenta uma classificação dos

requisitos não funcionais. Podemos ver que os requisitos não funcionais podem
ser provenientes das características requeridas para o software. Sommerville (2011,
p.61).
• Requisitos de produto: Esses requisitos especificam ou restringem o

comportamento do software.
• Requisitos organizacionais: Esses são os requisitos gerais de sistemas
derivados das políticas e procedimentos da organização do cliente e do
desenvolvedor.
• Requisitos externos: Esse tipo abrange todos os requisitos que derivam
de fatores externos ao sistema e seu processo de desenvolvimento.
Podem incluir requisitos reguladores, que definem o que deve ser feito
para que o sistema seja aprovado para uso, tal como um banco central;
requisitos legais, que devem ser seguidos para garantir que o sistema
opere dentro da lei.
69
FIGURA 24 - REQUISITOS NÃO FUNCIONAIS
FONTE: Sommerville (2011, p. 61)
Os requisitos não funcionais são de difícil verificação, por isso devem ser
escritos quantitativamente, para que possam ser objetivamente testados, conforme
Tabela 3.
TABELA 3 – REQUISITOS NÃO FUNCIONAIS
Transações processadas/segundo.
Velocidade Tempo de resposta de usuário/evento.
Tempo de atualização tela.
Megabytes.
Tamanho
Número de chips de memória ROM.
Tempo de treinamento.
Facilidade de uso
Número de frames de ajuda.
Tempo médio para falha.
Probabilidade de indisponibilidade.
Confiabilidade
Taxa de ocorrência de falhas.
Disponibilidade.
Tempo de reinício após falha.
Robustez Percentual de eventos que causam falhas.
Probabilidade de corrupção de dados em caso de falha.
Percentual de declarações dependentes do sistema-alvo.
Portabilidade
Número de sistemas-alvo.
FONTE: Sommerville (2011, p. 63)
70
2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE

REQUISITOS
A validação de requisitos tem como objetivo mostrar que os requisitos
levantados definem o sistema desejado pelos usuários.
A importância dessa tarefa está no fato de que erros em um documento de

requisitos podem acarretar custos excessivos de trabalho quando são descobertos
durante o processo de desenvolvimento ou mesmo depois, durante a operação do
sistema. Esses problemas serão detalhados mais a fundo na Tabela 4.
Sommerville (2011) diz que durante o processo de validação dos requisitos,

diferentes tipos de verificações devem ser realizados com os documentos de
requisitos. Essas verificações incluem:
TABELA 4 - TIPOS DE VERIFICAÇÕES

Um usuário pode achar que precisa de um software para
determinada função. No entanto, uma análise mais detalhada
Verificação de pode identificar outras funções além das solicitadas. Os
validade sistemas têm diversos stakeholders com diferentes necessidades,
e qualquer conjunto de requisitos é inevitavelmente um
compromisso da comunidade de stakeholders.
Os requisitos em um documento devem ser consistentes e não
Verificação de
conflitantes. Ou seja, não deve haver restrições contraditórias
consistência
ou descrições diferentes da mesma função do sistema.
O documento de requisitos deve incluir requisitos que definam
Verificação de
todas as funções e as restrições pretendidas pelo usuário do
completude
sistema.
Ou seja, o que se deseja é possível. Usando o conhecimento
Verificação de das tecnologias existentes, os requisitos devem ser verificados
realismo para assegurar que realmente possam ser implementados.
Verificando o orçamento e o cronograma de desenvolvimento.
Com a intenção de reduzir o potencial de conflito entre o
cliente e o contratante, os requisitos do sistema devem ser
Verificabilidade passíveis de verificação. O que significa que você deve ser
capaz de escrever um conjunto de testes que demonstrem que
o sistema entregue atende a cada requisito especificado.
Para a validação dos requisitos, Sommerville (2011) lista uma série de

técnicas para a validação dos requisitos, para serem usadas individualmente ou
em conjunto.
71
TABELA 5 – VALIDAÇÃO DE REQUISITOS
Revisão de Os requisitos são sistemicamente analisados por uma equipe de

requisitos revisores que verifica erros e inconsistências.
Nessa abordagem para validação, um modelo executável do
sistema em questão é demonstrado para os usuários finais e
Prototipação
clientes. Estes podem experimentar o modelo para verificar se ele
atende às suas reais necessidades.
Os requisitos devem ser testáveis. Se os testes forem concebidos
como parte do processo de validação, isso frequentemente revela
Geração de
problemas de requisitos. Se é difícil ou impossível projetar um
casos de testes
teste, isso normalmente significa que os requisitos serão difíceis
de serem implementados e devem ser reconsiderados.
Segundo Engholm Jr. (2010), para que um requisito possa ser validado e
aceito devemos verificar se é:
TABELA 6 – VERIFICAÇÃO DOS REQUISITOS
Estar escrito de maneira que seja de fácil entendimento, possibilitando

Claro
a compreensão por todos os integrantes da equipe de projeto.
Contendo todos os detalhes importantes, como dados de entrada e
Completo
saída, regras de validação ou interação do usuário com o sistema.
Consistente Requisitos não podem ser contraditórios.
Único Requisitos devem ser únicos, sem duplicidade.
Todos os requisitos devem ser viáveis para serem atendidos pela
Viável
solução.
Os requisitos devem poder ser efetivamente testados quando
Testável
implementados.
Rastreável Devem poder ser rastreáveis a partir do problema de negócio.
FONTE: Adaptado de Engholm Jr. (2010, p. 160)
Devemos atentar e não subestimar os problemas envolvidos na validação

dos requisitos. Segundo Sommerville (2011), é difícil mostrar que um conjunto de
requisitos atende de fato às necessidades de um usuário; os usuários precisam
imaginar o sistema em operação e como esse sistema se encaixa no seu trabalho.
E até mesmo para os profissionais qualificados de informática é difícil fazer esse
tipo de análise abstrata, e é mais difícil ainda para os usuários do sistema. Por isso,
durante o processo de validação dos requisitos, raramente todos os problemas de
requisitos serão encontrados.
72
2.3 PROBLEMAS ENCONTRADOS REFERENTES A

REQUISITOS
Durante a fase de levantamento de requisitos é necessário que haja uma
sintonia entre os analistas, para que o sistema atinja os objetivos. Caso haja
problemas nessa fase, o prejuízo pode ser imenso e até mesmo comprometer e
inviabilizar todo o sistema. A tirinha apresentada relata bem esse problema.
FIGURA 25 – LEVANTAMENTO DE REQUISITOS
FONTE: Disponível em: http://gerenciandoriscosemprojetos.com/levantamento-de-requisitos/>.

Acesso em: 22 mar. 2016.
Dias e Araújo (2012) afirmam que muitos projetos têm falhado devido
a problemas no levantamento de requisitos, tais como requisitos incompletos,
mal-entendidos ou ambíguos. Faz-se necessário então que esses requisitos sejam
bem construídos, de modo que expressem exatamente o que o usuário deseja, da
maneira que ele deseja e a forma como poderá ser feito. Por isso é importante
conhecer técnicas para tornar a construção destes requisitos mais eficaz e evitar o
retrabalho.
Engholm Jr. (2010) alerta que existem vários motivos que podem gerar
problemas e até mesmo o fracasso de um projeto. Segundo ele, a falta de
especificação da real necessidade e expectativas dos usuários é o maior motivo
dessas falhas, seguido por requisitos incompletos, com baixa qualidade e falta
de controle de mudanças. Ainda segundo o autor, por mais que possa parecer
estranho, uma dificuldade que podemos encontrar em relação a requisitos é manter
o foco no produto e nos objetivos relacionados ao projeto. Devemos atentar se os
requisitos apresentados estão compatíveis e alinhados com o projeto.
Quando um processo de levantamento de requisitos é ineficaz e não reflete

as necessidades reais do cliente, acaba gerando um software de baixa qualidade.
73
De acordo com Dias e Araújo (2016), estudos mostram que de 40% a 60% de todos
os problemas encontrados em um projeto de software são causados por falhas no
processo de requisitos. Se a fase de engenharia de requisitos for bem feita, esses
problemas poderiam ser detectados e corrigidos a um custo muito mais baixo.
2.4 ESPECIFICAÇÃO DE REQUISITOS

Através da Figura 26, apresentada por Engholm Jr. (2010), é possível
entender um pouco melhor a representação dos requisitos, onde cada nível é
associado ao nível de refinamento dos requisitos.
A partir do detalhamento das necessidades do cliente pode-se obter

as características do produto, derivando destas todos os requisitos a serem
contemplados pelo projeto. A nuvem representa o domínio do problema, refletindo
as necessidades que devem ser atendidas. Também se observa, na imagem, que
todo requisito deve ter como base uma necessidade relacionada ao problema de
negócio.
FIGURA 26 - REQUISITOS
FONTE: Engholm Jr. (2010, P. 157)
74
Reforçando a afirmação de que todo requisito deve ter como base

uma necessidade do projeto, tem-se a Figura 27 para auxiliar a identificar a
rastreabilidade dos requisitos.
FIGURA 27 - RASTREABILIDADE DE REQUISITOS
FONTE: Engholm Jr. (2010, p. 152)
A especificação é o processo de escrever os requisitos levantados com os

usuários em um documento de requisitos.
Sommerville (2011) alerta para a dificuldade dessa atividade, uma vez que
cada stakeholder interpreta de maneira diferente os requisitos, gerando, muitas
vezes, inconsistências e conflitos nesta documentação. Ainda segundo o autor, os
requisitos de usuário para um sistema devem descrever os requisitos funcionais e
não funcionais de uma maneira que sejam inteligíveis para os usuários do sistema
e que não tenham conhecimentos técnicos detalhados.
Torna-se ideal não usar jargões de software, notações estruturadas ou

notações formais, não se deve incluir detalhes da arquitetura ou do projeto, deve-se
apenas especificar o comportamento externo do sistema e em linguagem natural,
com tabelas simples e diagramas intuitivos.
75
2.4.1 Especificação em Linguagem Natural

Segundo Sommerville (2011), a Linguagem Natural tem sido usada desde
o início da engenharia do software para escrever os requisitos do programa. Essa
linguagem é expressiva, intuitiva e natural. Também é potencialmente vaga,
ambígua, e seu significado depende do conhecimento do autor.
TABELA 7 – LINGUAGEM NATURAL
Notação Descrição
Sentenças em Os requisitos são escritos em frases numeradas em
linguagem natural linguagem natural. Cada frase deve expressar um requisito.
Os requisitos são escritos em linguagem natural em um
Linguagem Natural
formulário padrão ou template. Cada campo fornece
estruturada
informações sobre um aspecto do requisito.
Essa abordagem usa uma linguagem de programação,
Linguagem de mas com características mais abstratas, para especificar os
descrição do requisitos, definindo um modelo operacional do sistema.
projeto Essa abordagem é pouco usada atualmente, embora possa
ser útil para as especificações de interface.
Para definição de requisitos funcionais para o sistema são
usados modelos gráficos, suplementados por anotações de
Notações gráficas
texto; diagramas de caso de uso e de sequência da UML são
comumente usados.
Essas notações são baseadas em conceitos matemáticos,
como máquinas de estado finito ou conjuntos. Embora essas
especificações inequívocas possam reduzir a ambiguidade
Especificações
de um documento de requisitos, a maioria dos clientes não
matemáticas
entende uma especificação formal. Eles não podem verificar
que elas representam o que eles querem e são relutantes em
aceitá-las como um contrato de sistema.
Para minimizar os mal-entendidos ao escrever requisitos em linguagem

natural, Sommerville (2011) recomenda algumas diretrizes simples:
• Crie um formato-padrão e garanta que todas as definições de

requisitos aderem a esse formato. A padronização do formato torna
menos prováveis as omissões e mais fácil a verificação dos requisitos.
• Use uma linguagem consistente para distinguir entre os requisitos
obrigatórios e os desejáveis. Os obrigatórios são os requisitos aos quais
o sistema tem de dar suporte e geralmente são escritos usando-se
“DEVE”. Já os desejáveis não são essenciais e são escritos usando-se
“PODE”.
• Use negrito, itálico ou cores para destacar as partes fundamentais.
• Não assuma que os leitores compreendem a linguagem técnica da
engenharia de software. Evite o uso de jargões, siglas e acrônimos.
76
• Sempre que possível, tente colocar uma lógica a cada um dos

requisitos de usuário. Essa justificativa deve explicar por que o requisito
foi incluído, e é particularmente útil quando são alterados, uma vez que
pode ajudar a decidir sobre quais mudanças são indesejáveis.
NOTA
Colocar nota explicando a diferença entre acrônimos e sigla:

Acrônimos:
1 [Linguística] Palavra formada com as letras ou sílabas iniciais de uma sequência de palavras,
pronunciada sem soletração das letras que a compõem (ex.: OVNI por Objeto Voador Não
Identificado, PALOP por País Africano de Língua Oficial Portuguesa, etc.).
Sigla
1 [Paleografia] Letra inicial usada como abreviatura em manuscritos, medalhas e monumentos
antigos.
2 Monograma.
3 [Linguística] Vocábulo formado com as letras ou sílabas iniciais de uma sequência de palavras
e que geralmente se pronuncia soletrando o nome de cada letra (ex.: UE por União Europeia,
E.U.Apor Estados Unidos da América, etc.).
4 [Antigo] Traços empregados pelos pedreiros, como sinais da sua corporação.
FONTE: Disponível em: <"sigla", in Dicionário Priberam da Língua Portuguesa [em linha], 2008-
2013, http://www.priberam.pt/dlpo/sigla>. Acesso em: 19 jan. 2016.
2.4.2 Especificação Estruturada

Especificação estruturada, segundo Sommerville (2011), é uma forma de
escrever os requisitos do sistema na qual a liberdade do escritor dos requisitos é
limitada e todos os requisitos são escritos em uma forma-padrão. Essa abordagem
mantém grande parte da expressividade e compreensão da Linguagem Natural,
mas garante certa uniformidade imposta sobre a especificação. O autor ainda
aponta que para usar uma abordagem estruturada para a especificação de
requisitos de sistema, pode-se definir um ou mais templates para representar esses
requisitos como formulários estruturados. A especificação pode ser estruturada
em torno dos objetos manipulados pelo sistema, das funções desempenhadas, ou
pelos eventos processados por este. Ele diz que quando um formulário-padrão é
usado para especificar requisitos funcionais, as seguintes informações devem ser
incluídas:
• A descrição da função ou entidade a ser especificada.

• Uma descrição de suas entradas e de onde eles vieram.
• Uma descrição de suas saídas e para onde elas irão.
• Informações sobre a informação necessária para o processamento ou
outras entidades usadas no sistema.
• Uma descrição da ação a ser tomada.
• Se uma abordagem funcional é usada, uma precondição define o que
deve ser verdade antes que a função seja chamada, e é chamada uma
pós-condição, especificando o que é verdade depois da função.
• Uma descrição dos efeitos colaterais da opção, caso existam.
77
A Figura 28 mostra alguns exemplos de uma especificação estruturada

para pesquisa de dados.
FIGURA 28 – ESPECIFICAÇÃO ESTRUTURADA
FONTE: Disponível em: <https://repositorio.ufsc.br/bitstream/

handle/123456789/87674/212905.pdf?sequence=1>. Acesso em: 22 mar. 2016.
78
2.4.3 Documento de requisito de software

Segundo Pressman (2011), uma especificação de requisitos de software
(software requirementes specification, SRS) é um documento que deve ser construído
e especificado antes do projeto começar. Contendo uma descrição detalhada de
todos os aspectos do software.
Complementando a informação, Sommerville (2011) diz que esse

documento deve incluir tanto os requisitos do usuário para um sistema, quanto
uma especificação detalhada dos requisitos deste. Lembrando que, em algumas
vezes, os requisitos do software e dos usuários podem ser integrados em uma
única descrição. Já em outros, os requisitos dos usuários são definidos como
uma introdução à especificação dos requisitos do sistema. De acordo com o
autor, o documento de requisitos possui um conjunto diversificado de autores,
que alcançam os vários níveis na hierarquia da empresa, do mais alto, que são
responsáveis pelo pagamento do sistema, até os engenheiros que são responsáveis
pelo desenvolvimento do software. Esses níveis de usuários são definidos conforme
a tabela a seguir:
TABELA 8 – NÍVEIS DE USUÁRIOS
Especificam e leem os requisitos para verificar se estes

Clientes do sistema satisfazem suas necessidades. Os clientes especificam as
alterações nos requisitos.
Usam o documento de requisitos para planejar uma
Gerentes proposta para o sistema e para planejar o processo de
desenvolvimento do sistema.
Usam os requisitos para entender o sistema que será
Engenheiros de sistema
desenvolvido.
Engenheiros de testes Usam requisitos para desenvolver testes de validação
do sistema do sistema.
Engenheiros de Usam os requisitos para entender o sistema e os
manutenção de sistema relacionamentos entre suas partes.
Atualmente existem várias planilhas disponíveis para auxiliar nesse

processo de documentação. Elas são muito semelhantes entre si, como pode ser
visto nos modelos apresentados por Sommerville (2011) e Pressman (2013).
DICAS
Uma descrição detalhada de cada tópico SRS de Pressman pode ser obtida no link
http://www.processimpact.com/process_assets/srs_template.doc
79
FIGURA 29 – MODELO DE DOCUMENTAÇÃO
FONTE: Adaptada Pressman (2013, p.129)
80
A definição do documento de requisitos definida por Sommerville (2011)

apresenta a descrição de cada item, como segue:
TABELA 9 – DOCUMENTO DE REQUISITOS
Capítulo Descrição
Deve definir os possíveis leitores do documento e descrever seu
histórico de versões, incluindo uma justificativa para a criação
Prefácio
de uma nova versão e um resumo das mudanças feitas em cada
versão.
Deve descrever a necessidade para o sistema. Deve descrever
brevemente as funções do sistema e explicar como ele vai
Introdução funcionar com outros sistemas. Também deve descrever como o
sistema atende aos objetivos globais de negócio ou estratégicos da
organização que encomendou o software.
Deve definir os termos técnicos usados no documento. Você não
Glossário deve fazer suposições sobre a experiência ou o conhecimento do
leitor.
Deve descrever os serviços fornecidos ao usuário. Os requisitos
Definição de não funcionais de sistema também devem ser descritos nessa
requisitos de seção. Essa descrição pode usar a Linguagem Natural, diagramas
usuário ou outras notações compreensíveis para os clientes. Normas de
produtos e processos que devem ser seguidos e especificados.
Deve apresentar uma visão geral e alto nível da arquitetura do
Arquitetura sistema previsto, mostrando a distribuição de funções entre
do sistema os módulos do sistema. Componentes de arquitetura que são
reusados devem ser destacados.
Deve descrever em detalhes os requisitos funcionas e não
Especificação
funcionais. Se necessário, também podem ser adicionados mais
de requisitos
detalhes aos requisitos não funcionais. Interfaces com outros
do sistema
sistemas podem ser definidas.
Pode incluir modelos gráficos do sistema que mostram os
Modelos do relacionamentos entre os componentes do software, o sistema e seu
sistema ambiente. Exemplos de possíveis modelos de objetos, modelos de
fluxo de dados ou modelos semânticos de dados.
Deve descrever os pressupostos fundamentais em que o sistema se
baseia, bem como quaisquer mudanças previstas, em decorrência
Evolução do da evolução de hardware, de mudanças nas necessidades do usuário
sistema etc. Essa seção é útil para projetistas de sistema, pois pode ajudá-
los a evitar decisões capazes de restringir possíveis mudanças
futuras no software.
Deve fornecer informações detalhadas e específicas relacionadas à
aplicação em desenvolvimento, além de descrições de hardware e
banco de dados, por exemplo. Os requisitos de hardware definem
Apêndices
as configurações mínimas ideais para o sistema. Requisitos de
banco de dados definem a organização lógica dos dados usados
pelo software e os relacionamentos entre esses dados.
81
Vários índices podem ser incluídos no documento. Pode haver,

Índices além de um índice alfabético normal, um índice de diagramas, de
funções, entre outros pertinentes.
2.4.4 Gerenciamento de requisitos

Engholm Jr. (2010) apresenta uma sugestão de processo de gerenciamento
de requisitos em projetos de software, onde podemos visualizar os atores, a matriz
de responsabilidade, os subprocessos e os produtos e entregáveis de cada um deles.
FIGURA 30 - GERENCIAMENTO DE REQUISITOS
FONTE: Engholm Jr. (2010, p. 159)
O gerenciamento de requisitos é o processo de compreensão e controle de

mudanças nos requisitos do sistema. É preciso atenção às necessidades individuais
e manter as ligações entre as necessidades dependentes para conseguir avaliar o
impacto das mudanças de requisitos. É necessário estabelecer um processo formal
para fazer propostas de mudanças e a ligação destas às exigências do sistema.
82
“O processo formal de gerenciamento de requisitos deve começar assim que

uma versão preliminar do documento de requisitos estiver disponível. Porém, o
planejamento de como gerenciar mudanças de requisitos deve começar durante o
processo de elicitação de requisitos”. Sommerville (2011, p.78)
A importância do levantamento de requisitos no sucesso dos projetos de

software
Esse artigo pretende descrever resumidamente a relação entre o bom

levantamento de requisitos e o sucesso dos projetos de software.
A tarefa de desenvolvimento de software engloba uma série de fases e

atividades que, independentemente da metodologia escolhida, ocorrem para
a realização do seu objetivo maior: entregar software funcionando corretamente
dentro do orçamento e prazos previstos para o seu desenvolvimento.
Para atingir os objetivos do projeto, todas as atividades de desenvolvimento

têm que ser criteriosamente elaboradas e desenvolvidas, seja usando uma
abordagem de desenvolvimento mais rica em documentação, tais como o poderoso
UP (Unified Process) ou as excelentes metodologias ágeis (XP, SCRUM etc). Assim
sendo, em qualquer uma delas encontraremos com maior ou menor rigor e
formalização, atividades de análise de requisitos, design, definição de arquitetura,
codificação e outras. Um trabalho consistente de análise dos requisitos, ou seja,
identificar, quantificar, definir, priorizar e classificar os principais problemas que
o futuro software deve resolver é a base de um projeto de software de sucesso.
Muita ênfase é dada pelos profissionais de T.I. nas atividades de projeto e

codificação. Isso deve-se em boa parte à formação dada aos profissionais de T.I.
pelas universidades, que focam em suas grades curriculares principalmente em
disciplinas técnicas e científicas. Tem muito a ver também com perfil pessoal e
cultural dos profissionais que atuam na área em geral, formada eminentemente
por técnicos, bastante interessados em bits e bytes e pouco afetos a assuntos
administrativos. Isso tem mudado bastante recentemente, pois os profissionais
de T.I. têm percebido a importância da relação entre negócio e T.I. Entretanto,
a atividade de levantamento de requisitos é de fundamental importância para
que se construa o software certo, ou seja, é necessário, antes de mais nada, que
os envolvidos no projeto de software saibam exatamente o que é esperado do
aplicativo a ser construído. É muito importante também que todos os envolvidos
saibam igualmente o que o software não fará. Isso pode parecer óbvio, mas nem
sempre fica claro para todos os envolvidos do projeto sobre qual é a fronteira da
aplicação. A fronteira da aplicação pode ser entendida como uma linha imaginária
que circula e define objetivamente, dentre os requisitos de software, quais serão
automatizados e quais não serão.
83
É fundamental definir corretamente o que vem a ser um requisito: é uma

especificação de uma característica ou propriedade que um sistema deve possuir
ou fazer, assim como sua restrição de operação. Os requisitos podem ser definidos
por diversas classificações, tais como: requisitos de negócio, funcionais, não
funcionais, etc. Larga documentação existe sobre o tema, tanto em livros, como na
internet, portanto esse artigo não vai se prolongar sobre o assunto.
Toda metodologia de desenvolvimento de software (MDS) propõe uma

série de fases e atividades dentro do seu ciclo de vida e o encadeamento entre elas.
Independentemente do nome dado a cada fase, é extremamente recomendável que
o processo contemple ao menos dois grandes grupos de atividades referentes a
requisitos, que poderíamos chamar aqui de:
Especificação de requisitos - São todas as atividades realizadas para

identificar, analisar, especificar e definir as necessidades de negócio que um
aplicativo deve prover para solução do problema levantado. Requisitos que não
refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes,
mudanças em requisitos que já foram previamente acordados e a dificuldade
para se chegar a um acordo entre profissionais de T.I. e usuários são os maiores
problemas enfrentados no grupo de atividades de especificação de requisitos.
Gestão de requisitos - Preocupa-se com a documentação, versionamento,

controle de mudanças e qualidade dos requisitos levantados na fase de especificação
de requisitos. Todo requisito apresenta um ciclo de vida único que acompanha
a dinâmica dos negócios associados. Assim sendo, não se pode esperar que um
requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o
requisito se desprende é dinâmico.
O gerente de um projeto de desenvolvimento de software deve atentar

para a importância do correto entendimento das necessidades do aplicativo e
deve disponibilizar seu(s) melhor(es) analista(s) para realizar a atividade de
levantamento de requisitos. Essa etapa bem realizada servirá como uma fundação
firme para a realização das atividades seguintes do projeto. É de suma importância
que o gerente do projeto se envolva ou designe alguém capacitado para a realização
da gestão de escopo do projeto, inclusive criando um método criterioso de controle
de mudanças. Não se deve confundir criterioso com burocrático. Muitas empresas,
cientes dos problemas ocasionados por falta da correta gestão de escopo, tentam
“blindar” os requisitos do projeto, tornando qualquer alteração morosa e difícil,
cercada de documentos e assinaturas que muitas vezes provocam o efeito contrário
ao desejado. É importante que todos os envolvidos no projeto busquem harmonizar
seus interesses em prol da consecução dos objetivos do projeto.
Concluindo, podemos afirmar que sem uma correta definição e gestão

dos requisitos do aplicativo é praticamente certo que o projeto terá o seu sucesso
comprometido, frustrando as expectativas do cliente e comprometendo as metas e
planos da empresa contratante.
84
Márcio Andrade Silva

Márcio Andrade Silva - Formado em Análise de sistemas pela FAFI-BH.
Pós-graduado em Engenharia de Software pela PUC Minas.
MBA em Gestão de Negócios pela UNA - BH
FONTE: Disponível em: http://www.linhadecodigo.com.br/artigo/1685/a-importancia-do-

levantamento-de-requisitos-no-sucesso-dos-projetos-de-software.aspx#ixzz3x8rwTQ00>. Acesso
em: 22 mar. 2016.
85
RESUMO DO TÓPICO 1
• Durante o desenvolvimento do sistema é necessário estar sempre atento à

qualidade e às necessidades do cliente para que estas sejam atendidas. Para isso
é importante saber exatamente o que se espera do sistema.
a) Engenharia de requisitos: Processo de descobrir, analisar, documentar e

verificar esses serviços e restrições é chamado de Engenharia de Requisitos
(RE, do inglês requirements engineering).
b) Definindo os requisitos: Deve descrever os serviços fornecidos ao usuário.

Os requisitos funcionais e não funcionais do sistema devem ter. Esta
descrição pode usar a Linguagem Natural, diagramas ou outras notações
compreensíveis para os clientes. Normas de produtos e processos que devem
ser seguidos devem ser especificados.
c) Requisitos Funcionais: São declarações de funções de como o sistema deve

reagir a entradas específicas e como deve se comportar em determinadas
situações. É uma interação entre o sistema e o seu ambiente. Algumas vezes,
os requisitos funcionais podem também explicitamente declarar o que o
sistema não deve fazer. A especificação deve ser completa e consistente.
d) Requisitos Não Funcionais: São restrições aos serviços ou funções

oferecidas pelo sistema. Incluem restrições de timing, restrições no processo
de desenvolvimento e restrições impostas pelas normas. Ao contrário
das características individuais ou serviços do sistema, os requisitos não
funcionais, muitas vezes, aplicam-se ao sistema como um todo.
e) Critérios para validação e aceitação de requisitos: A validação de requisitos

tem como objetivo mostrar que os requisitos levantados definem o sistema
desejado pelos usuários.
f) Problemas encontrados referentes a requisitos: É a falta de especificação da

real necessidade e expectativas dos usuários. É o maior motivo dessas falhas,
seguido por requisitos incompletos, com baixa qualidade e falta de controle
de mudanças.
g) Especificação de requisitos: uma especificação de requisitos de software

(software requirementes specification, SRS) é um documento que deve ser
construído e especificado antes do projeto começar. Contendo uma descrição
detalhada de todos os aspectos do software.
86
h) Especificação em Linguagem Natural: É uma forma de escrever os requisitos
do sistema na qual a liberdade do escritor dos requisitos é limitada e todos os
requisitos são escritos em uma forma-padrão.
i) Especificação estruturada: Essa linguagem é expressiva, intuitiva e natural.

Também é potencialmente vaga, ambígua, e seu significado depende do
conhecimento do autor.
j) Documento de requisito de software: Sua utilização é durante o

desenvolvimento de um sistema de software, no qual há a necessidade de
elaborar o documento descrevendo o conjunto de requisitos do sistema de
modo a informar tanto à equipe de projeto, quanto ao cliente, o que será
implementado.
k) Gerenciamento de requisitos: A tarefa de gerenciar requisitos se preocupa

com as mudanças nos requisitos que já haviam sido acertadas entre cliente e
desenvolvedor.
87
AUTOATIVIDADE
No texto abaixo você tem a solicitação para desenvolvimento de software

de um cliente proprietário de uma clínica médica. A partir das informações
levantadas com o cliente, preencha o documento de análise do problema que
dará início à documentação do futuro sistema.
Empresa: Clínica Bem-Estar
Função: Fomos contratados para analisar seu processo atual e verificar como
expandir suas operações e melhorar seu nível de serviço.
Histórico: A clínica, fundada há cinco anos, atua no atendimento clínico

pediátrico.
A clínica possui 34 médicos cadastrados em diferentes especialidades, como:

cardiologia, clínica geral, dermatologia etc. Todos os médicos utilizam internet
e e-mail. A faixa etária predominante é de 30, 35, 40, 42, 44 e 48 anos. Todos os
médicos são aptos do ponto de vista físico.
O paciente pode ser atendido de forma particular ou por convênios. Os

convênios atendidos são o Bruxtr, Vpfzm e UIOlk.
Cada médico faz três plantões semanais de quatro horas seguidas; as consultas
possuem um intervalo de 30 minutos. Existe a possibilidade de a consulta ser
de retorno, nesse caso são apenas 15 minutos.
A clínica é 24 horas. Cada médico possui uma agenda preta onde são marcadas
as consultas. Na marcação da consulta são colocados o nome do paciente, o
horário e convênio. Trabalham há três anos na clínica com planilhas Excel.
A clínica possui duas atendentes que são responsáveis por preencher o cadastro
inicial do paciente, que contém nome, endereço, telefone, data de nascimento
e convênio.
O médico, ao atender o paciente, preenche sua ficha manualmente, informando

peso, altura, idade, motivo da consulta, queixa principal, doenças anteriores,
diagnóstico e prescrição. A prescrição pode ser a solicitação de exames ou
medicamentos com posologia.
A clínica possui de 700 a 800 fichas, sendo que cerca de 600 são de atendimento
por convênio.
88
O gerente da clínica está ansioso, pois não consegue controlar questões
relacionadas ao número de pacientes atendidos por convênio e particular,
médicos mais procurados e picos de movimento.
Volume de atendimentos: 56 por dia.
Outra questão de interesse é manter um controle de laboratórios conveniados,

pois o médico poderia indicar o laboratório já no momento da prescrição.
TEMPLATE PARA REALIZAÇÃO DA ANÁLISE DO PROBLEMA CLÍNICA

BEM-ESTAR
1 Nome da empresa.
2 Contato.
3 Descrição do problema.
4 Identificação do principal objetivo do cliente.
5 Descrição dos usuários do sistema (para cada usuário, descreva cargo e

possíveis funções dentro do processo).
6 Descrição detalhada dos processos existentes (COMO O SISTEMA ATUAL

FUNCIONA?)
• Para marcação da consulta.
• Como funciona o processo de atendimento?
7 Itens produzidos no sistema (quais são os relatórios e consultas existentes ou

solicitados pelos clientes?)
8 Volume de informações do sistema atual.
9 Descrição de situações consideradas críticas e atores envolvidos.
10 Restrições do projeto.
89
90
UNIDADE 2 TÓPICO 2
DESCOBERTA DE REQUISITOS
1 INTRODUÇÃO
A descoberta de requisitos, também é chamada de elicitação de requisitos,
é o processo de reunir informações sobre o sistema requerido e os sistemas
existentes e separar dessas informações os requisitos de usuários e de sistemas.
Pode-se listar como fontes de informação durante a fase descoberta de requisitos,
segundo Sommerville (2011, p.70):
• Documentação
• Stakeholders do sistema e
• Sistemas e especificações de sistemas similares.
A interação com os stakeholders pode se dar por meio de observação e

entrevistas, e para facilitar o entendimento desses profissionais pode-se usar
cenários e protótipos que os ajudam a compreender o funcionamento do futuro
sistema.
Sommerville apud Moraes propõe um processo genérico de levantamento

e análise que contém as seguintes atividades:
• Compreensão do domínio: Os analistas devem desenvolver sua

compreensão do domínio da aplicação.
• Coleta de requisitos: É o processo de interagir com os stakeholders do
sistema para descobrir seus requisitos. A compreensão do domínio se
desenvolve mais durante essa atividade.
• Classificação: Essa atividade considera o conjunto não estruturado
dos requisitos e os organiza em grupos coerentes.
• Resolução de conflitos: Quando múltiplos stakeholders estão
envolvidos, os requisitos apresentarão conflitos. Essa atividade tem por
objetivo solucionar esses conflitos.
• Definição das prioridades: Em qualquer conjunto de requisitos, alguns
serão mais importantes do que outros. Esse estágio envolve interação
com os stakeholders para a definição dos requisitos mais importantes.
• Verificação de requisitos: Os requisitos são verificados para descobrir
se estão completos e consistentes e se estão em concordância com o que
os stakeholders desejam do sistema.
91
2 TÉCNICAS DE LEVANTAMENTO
O levantamento e análise de requisitos é um processo iterativo, com uma
contínua validação de uma atividade para outra, conforme apresentado na Figura
31.
FIGURA 31 - LEVANTAMENTO E ANÁLISE DE REQUISITOS
FONTE: Disponível em: <http://www.devmedia.com.br/engenharia-de-software-2-tecnicas-para-

levantamento-de-requisitos/9151>. Acesso em: 22 mar. 2016.
A fase de levantamento de dados, segundo Moraes (2016), é uma fase

muito importante e que gera muita insatisfação por parte dos usuários, dentre
essas razões podemos destacar:
• Na fase de levantamento de requisitos do projeto, onde não é utilizada

uma técnica adequada para extrair os requisitos do sistema;
• A falha do analista em não descrever os requisitos do sistema de modo
claro, sem ambiguidades, conciso e consistente com todos os aspectos
significativos do sistema proposto.
Ainda segundo a autora, dentre as dificuldades encontradas na fase de

levantamento de requisitos estão:
• O usuário principal do sistema não sabe o que quer que o sistema faça
ou sabe e não consegue transmitir para o analista;
• Requisitos identificados, mas que não são realistas e não identificam
os requisitos similares informados por pessoas diferentes.
• Um stakeholder errado afetará em perda de tempo e dinheiro para
ambas as partes envolvidas no desenvolvimento do sistema.
92
TÓPICO 2 | DESCOBERTA DE REQUISITOS
Ela ainda afirma que se identifica um levantamento de requisitos adequado

através da boa definição do projeto, da efetividade do projeto, de informações
necessárias a um perfeito diagnóstico e de soluções inteligentes.
Vale ressaltar que as técnicas de levantamento de requisitos têm por

objetivo superar as dificuldades encontradas nesta fase. Todas as técnicas possuem
um conceito próprio e suas respectivas vantagens e desvantagens, que podem ser
utilizadas em conjunto pelo analista.
TURO S
ESTUDOS FU
Essas técnicas serão detalhadas de maneira resumida aqui, e sugere-se um estudo

detalhado para evitar problemas nessa importante fase.
2.1 ENTREVISTA
Segundo Sommerville (2011), as entrevistas, sejam elas formais ou informais,
realizadas com os stakeholders, são parte da maioria dos processos da engenharia
dos requisitos. Nessas entrevistas, os stakeholders são questionados pela equipe de
engenharia de requisitos sobre os sistemas que usam no momento e também sobre
o sistema que será desenvolvido. A partir dessas respostas os requisitos surgem.
Sommerville (2011, p.72), classifica essas entrevistas em dois tipos:
• Entrevistas fechadas: em que o stakeholder responde a um conjunto

predefinido de perguntas.
• Entrevistas abertas: Neste caso não existe uma agenda predefinida.
A equipe de engenharia de requisitos explora uma série de questões
com os stakeholders, e assim desenvolve uma melhor concepção das
necessidades do novo sistema.
Moraes (2016) sugere que é necessário ter um plano de entrevista para

que não haja dispersão do assunto principal e a entrevista fique longa, deixando
o entrevistado cansado e não produzindo bons resultados. E que as seguintes
diretrizes podem ser de grande auxílio na direção de entrevistas bem-sucedidas
com o usuário:
• Desenvolver um plano geral de entrevistas.

• Certificar-se da autorização para falar com os usuários.
• Planejar a entrevista para fazer uso eficiente do tempo.
• Utilizar ferramentas automatizadas que sejam adequadas.
• Tentar descobrir em que informação o usuário está mais interessado e
• Usar um estilo adequado ao entrevistar.
A autora aponta que é importante planejar a entrevista. É necessário que

antes dela sejam coletados e estudados todos os dados pertinentes à discussão,
93
como formulários, relatórios, documentos e outros. Para que, dessa forma, o

analista esteja bem contextualizado e tenha mais produtividade nos assuntos a
serem discutidos na entrevista. Após a entrevista é necessário validar se o que foi
documentado pelo analista está de acordo com a necessidade do usuário, que o
usuário não mudou de opinião e que entende a notação ou representação gráfica
de suas informações.
Moraes (2016) ressalta:
A atitude do analista em relação à entrevista é determinar seu fracasso

ou sucesso. Uma entrevista não é uma competição, deve-se evitar o
uso excessivo de termos técnicos e não conduzir a entrevista em uma
tentativa de persuasão. O modo como o analista fala não deve ser muito
alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os
termos: ele disse isso ou aquilo na reunião para o outro entrevistado.
O modo melhor para agir seria, por exemplo, dizer: O João vê a solução
para o projeto dessa forma. E o senhor André, qual é a sua opinião?
Em uma entrevista o analista nunca deve criticar a credibilidade do
entrevistado. O analista deve ter em mente que o entrevistado é o perito
no assunto e fornecerá as informações necessárias ao sistema.
Para elaborar perguntas detalhadas, Moraes (2016) entende ser necessário

solicitar que o usuário:
• Explique o relacionamento entre o que está em discussão e as demais

partes do sistema.
• Descreva o ponto de vista de outros usuários em relação ao item que
esteja sendo discutido.
• Descreva informalmente a narrativa do item em que o analista deseja
obter informações.
• Perguntar ao usuário se o item em discussão depende para a sua
existência de alguma outra coisa, para assim poder juntar os requisitos
comuns do sistema, formando assim um escopo conciso.
• Pode-se utilizar a confirmação, para tanto o analista deve dizer ao
usuário o que acha que ouviu ele dizer. Neste caso, o analista deve
utilizar as suas próprias palavras em lugar das do entrevistado e
solicitar ao entrevistado confirmação do que foi dito.
2.1.1 Etnografia - Observação pessoal

De acordo com Sommerville (2011), a Etnografia é conhecida como a técnica
de observação, onde os analistas passam alguns dias na empresa na qual o software
será utilizado, dessa forma conseguem entender a política organizacional da
empresa, acompanhar os trabalhos diários, para que assim conheçam os processos
reais que os usuários vão precisar diariamente no sistema. Esses processos são
todos observados e anotados para a montagem dos principais requisitos do software.
94
Segundo Moraes (2016), a Etnografia é uma técnica de observação que pode

ser utilizada para compreender os requisitos sociais e organizacionais, ou seja,
entender a política organizacional, bem como a cultura de trabalho, com objetivo
de familiarizar-se com o sistema e sua história. Os cientistas sociais e antropólogos
usam técnicas de observação para desenvolver um entendimento completo e
detalhado de culturas particulares. Ainda segundo a autora, nesta técnica o analista
se insere no ambiente de trabalho em que o sistema será utilizado. O trabalho
diário é observado e são anotadas as tarefas reais em que esse será utilizado. O
principal objetivo da Etnografia é que ela ajuda a descobrir requisitos de sistema
implícitos, que refletem os processos reais, em vez de os processos formais, onde
as pessoas estão envolvidas. Etnografia é particularmente eficaz na descoberta de
dois tipos de requisitos:
• Os requisitos derivados da maneira como as pessoas realmente

trabalham, em vez da maneira pelas quais as definições de processo
dizem como elas deveriam trabalhar.
• Os requisitos derivados da cooperação e conscientização das
atividades de outras pessoas.
A autora ressalta alguns itens importantes que devem ser executados antes,
durante e depois do estudo de observação:
• Antes, se faz necessário identificar as áreas de usuário a serem

observadas; além de obter a aprovação das gerências apropriadas para
executar tais observações; obter os nomes e funções das pessoas-chave
que estão envolvidas no estudo de observação; e explicar a finalidade
do estudo.
• Durante, é necessário familiarizar-se com o local de trabalho que
está sendo observado. Para isso é preciso observar os agrupamentos
organizacionais atuais; as facilidades manuais e automatizadas; coletar
amostras de documentos e procedimentos escritos que são usados
em cada processo específico que está sendo observado; e acumular
informações estatísticas a respeito das tarefas, como: frequência em
que ocorrem, fazer estimativas de volumes, tempo de duração para
cada pessoa que está sendo observada. Além de observar as operações
normais de negócios acima, é importante observar as exceções;
• Depois, é necessário fazer a documentação das descobertas que
resultará das observações feitas. Para consolidar o resultado é preciso
rever os resultados com as pessoas observadas e/ou com seus superiores.
2.1.2 Questionário
Os questionários são usados para o levantamento de Requisitos, quando
a empresa solicitante possuir filiais em diversas localidades, e ao invés da equipe
de analistas ir a todas essas filiais, são elaborados os questionários e enviados para
os principais usuários de cada filial. As questões são elaboradas de forma simples,
clara e objetiva, para que todos os envolvidos possam compreender e responder.
Moraes (2016) aponta que os questionários utilizados para esse tipo de

levantamento podem ser: múltipla escolha, lista de verificação e questões com
95
espaços em branco. A sugestão para ser desenvolvido dessa forma é minimizar

o tempo gasto em sua resposta. Ainda de acordo com Moraes (2016), na fase
de preparação do questionário deve ser indicado o tipo de informação que se
deseja obter. Assim que os requisitos forem definidos, o analista deve elaborar
o questionário com questões de forma simples, clara e concisa, deixar espaço
suficiente para as repostas que forem descritivas e agrupar as questões de tópicos
específicos em um conjunto com um título especial. A autora sugere uma lista de
procedimentos para o sucesso dessa atividade:
O questionário deve ser acompanhado por uma carta explicativa, redigida

por um alto executivo, para enfatizar a importância dessa pesquisa para
a organização. Deve ser desenvolvido um controle que identifique todas
as pessoas que receberão os questionários. A distribuição deve ocorrer
junto com instruções detalhadas sobre como preenchê-lo e ser indicado
claramente o prazo para devolução do questionário. Ao analisar as
respostas dos participantes é feita uma consolidação das informações
fornecidas no questionário, documentando as principais descobertas e
enviando uma cópia com estas informações para o participante como
forma de consideração pelo tempo dedicado a pesquisa.
(MORAES, 2016. Disponível em: < http://www.devmedia.com.br/
articles/viewcomp.asp?comp=9151>. Acesso em: 22 mar. 2016)
2.1.3 Brainstorming
Brainstorming é uma técnica para geração de ideias. Ela consiste em uma ou
várias reuniões que permitem que as pessoas sugiram e explorem ideias.
A técnica de Brainstorming é conhecida como a de geração de ideias, são

selecionados grupos de setores diferentes e com propostas de ideias que às vezes
são quase impossíveis, mas no decorrer das reuniões elas são compreendidas e
propostas para o sistema. Essa técnica costuma ocorrer diversas vezes em reuniões
marcadas com os usuários da empresa, segundo Moraes (2016).
Moraes (2016) lista as principais etapas necessárias para conduzir uma

sessão de Brainstorming:
• Seleção dos participantes: Os participantes devem ser selecionados

em função das contribuições diretas que possam dar durante a sessão.
A presença de pessoas bem informadas, vindas de diferentes grupos,
garantirá uma boa representação;
• Explicar a técnica e as regras a serem seguidas: O líder da sessão
explica os conceitos básicos de Brainstorming e as regras a serem
seguidas durante a sessão;
• Produzir uma boa quantidade de ideias: Os participantes geram
tantas ideias quantas forem exigidas pelos tópicos que estão sendo o
objeto do Brainstorming. Os participantes são convidados, um por vez,
a dar uma única ideia. Se alguém tiver problema, passa a vez e espera
a próxima rodada.
96
A autora adverte que por mais que as ideias, a princípio, pareçam não
convencionais, devem ser encorajadas, pois frequentemente estimulam os
participantes, o que pode levar a soluções criativas para o problema. O número de
ideias geradas deve ser bem grande, pois quanto mais ideias apresentadas, maior
será a chance de aparecerem boas ideias. Os participantes também devem ser
encorajados a combinar ou enriquecer as ideias de outros e, para isso, é necessário
que todas as ideias permaneçam visíveis a todos os participantes.
A documentação, de acordo com Moraes (2016), é designada para uma

pessoa que registra todas as ideias em uma lousa branca ou em papel. E à medida
que cada folha de papel é preenchida, ela é colocada de forma que todos os
participantes possam vê-la.
Analisar as ideias resultantes desse processo é a fase final do Brainstorming.

Nessa fase é realizada uma revisão das ideias, uma de cada vez. As consideradas
valiosas pelo grupo são mantidas e classificadas em ordem de prioridade.
2.1.4 JAD (Joint Application Design)

Segundo Moraes (2016), JAD é uma técnica para promover cooperação,
entendimento e trabalho em grupo entre os usuários desenvolvedores. Ela facilita
a criação de uma visão compartilhada do que o produto de software deve ser.
Através da sua utilização, os desenvolvedores ajudam os usuários a formular
problemas e explorar soluções. Dessa forma, os usuários ganham um sentimento
de envolvimento, posse e responsabilidade com o sucesso do produto. Essa técnica
tem quatro princípios básicos:
• Dinâmica de grupo: são realizadas reuniões com um líder experiente,

analista, usuários e gerentes, para despertar a força e criatividade dos
participantes. O resultado final será a determinação dos objetivos e
requisitos do sistema.
• Uso de técnicas visuais: para aumentar a comunicação e o
entendimento.
• Manutenção do processo organizado e racional: o JAD emprega
a análise top down e atividades bem definidas. Possibilita, assim, a
garantia de uma análise completa, reduzindo as chances de falhas ou
lacunas no projeto e cada nível de detalhe recebe a devida atenção.
• Utilização de documentação padrão: preenchida e assinada por todos
os participantes. Este documento garante a qualidade esperada do
projeto e promove a confiança dos participantes.
A autora afirma que a técnica JAD é composta de duas etapas principais.

A de planejamento, que tem por objetivo levantar e especificar os requisitos. E
o projeto, em que se lida com o projeto de software. Cada etapa consiste em três
fases: adaptação, sessão e finalização. A fase de adaptação consiste na preparação
para a sessão, ou seja, organizar a equipe, adaptar o processo JAD ao produto
a ser construído e preparar o material. Durante a fase de sessão é realizado um
ou mais encontros estruturados, envolvendo desenvolvedores e usuários onde
97
os requisitos são desenvolvidos e documentados. Já a fase de finalização tem

por objetivo converter a informação da fase de sessão em sua forma final (um
documento de especificação de requisitos).
Segundo a autora, há seis tipos de participantes, embora nem todos

participem de todas as fases:
• Líder da sessão: é responsável pelo sucesso do esforço, sendo o

facilitador dos encontros. Deve ser competente, com bom relacionamento
pessoal e qualidades gerenciais de liderança.
• Engenheiro de requisitos: é o participante diretamente responsável
pela produção dos documentos de saída das sessões JAD. Deve ser um
desenvolvedor experiente para entender as questões técnicas e detalhes
que são discutidos durante as sessões e ter habilidade de organizar
ideias e expressá-las com clareza.
• Executor: é o responsável pelo produto sendo construído. Tem que
fornecer aos participantes uma visão geral dos pontos estratégicos do
produto de software a ser construído e tomar as decisões executivas,
tais como alocação de recursos, que podem afetar os requisitos e o
projeto do novo produto.
• Representantes dos usuários: são as pessoas na empresa que irão
utilizar o produto de software. Durante a extração de requisitos, os
representantes são frequentemente gerentes ou pessoas-chave dentro
da empresa que têm uma visão melhor do todo e de como ele será usado.
• Representantes de produtos de software: são pessoas que estão
bastante familiarizadas com as capacidades dos produtos de software.
Seu papel é ajudar os usuários a entender o que é razoável ou possível
que o novo produto faça.
• Especialista: é a pessoa que pode fornecer informações detalhadas
sobre um tópico específico.
Para Moraes (2016), essa dinâmica de grupo pode ser utilizada para
diversas finalidades, como o planejamento de atividades técnicas para um grande
projeto, discussão do escopo e objetivos de um projeto e estimativa da quantidade
de horas necessárias para desenvolver sistemas grandes e complexos. Vale lembrar
que a maioria das técnicas JAD funciona melhor em projetos pequenos ou médios.
Para um sistema grande e complexo podem ser usadas múltiplas sessões JAD para
acelerar a definição dos requisitos do sistema.
98
RESUMO DO TÓPICO 2
• As técnicas para o levantamento de requisitos, apresentadas de acordo com

MORAES (2016):
a) Técnicas tradicionais: São aplicadas em várias áreas do conhecimento.

Exemplo: questionários, entrevistas, observação, e análise de documentos.
b) Técnicas de elicitação de grupo: Tem por objetivo compreender melhor o

pensamento e comportamento dos grupos e as necessidades dos usuários.
Exemplo: brainstorming e as sessões JAD (Joint Application Design).
c) Prototipação: O uso de protótipo auxilia na elicitação e validação dos

requisitos de sistema. A prototipação pode ser utilizada para elicitar
requisitos quando há um alto grau de incerteza ou quando é necessário um
rápido feedback dos usuários.
d) Técnicas contextuais: Surgiram como uma alternativa para as técnicas

tradicionais e cognitivas e inclui técnicas de etnografia e análise social.
99
AUTOATIVIDADE
1 Segundo o estudo de caso apresentado a seguir, crie uma lista de 10 perguntas

que você, como analista, faria ao cliente que solicitou o sistema.
Estudo de caso: Revendedora de automóveis
Model Car é o nosso cliente, e deseja automatizar o processo de compra e venda

de automóveis que é realizado em sua loja. O processo é bem simples, e funciona
da seguinte forma:
A Model Car adquire automóveis diretamente da fábrica, ou pelo sistema de

troca com seus clientes, sistema esse em que o cliente leva um automóvel da
loja e deixa o seu em troca. Para cada veículo da loja é necessário saber quem o
vendeu, para no caso de problemas entrar em contato com o responsável, seja
a fábrica ou o cliente. Quando ocorre algum problema com o veículo fornecido
pela fábrica, é necessário saber as informações básicas para que se possa entrar
em contato.
Em virtude de ser uma empresa de pequeno porte, a Model Car trabalha apenas
com veículos de passeio e utilitários leves. Sendo que para esses veículos ela
também precisa de um cadastro com informações básicas de identificação.
O mesmo acontece com os clientes da Model Car, ela precisa das informações que
possam identificar e localizá-los, para que futuramente possam ser enviadas
correspondências via carta, e-mail ou telefone com as promoções. Além de
permitir a análise do perfil do cliente para compras futuras.
O processo de vendas funciona de duas formas. Na primeira e mais comum, o

cliente se dirige até a loja e efetua a compra. A outra forma é onde o vendedor
faz visita aos clientes. Neste segundo caso, a comissão é o dobro da primeira
modalidade de venda.
O gerente, querendo administrar melhor sua empresa, deseja saber informações

que o ajudem na administração do seu negócio, como os valores pagos de
comissão, qual o vendedor que mais vendeu, a região com ou sem venda,
número de carros vendidos em troca etc. Todas essas informações mês a mês e
acumuladas também por trimestre. Além, é claro, do controle de estoque.
100
UNIDADE 2
TÓPICO 3
DESENVOLVIMENTO E EQUIPE DE SOFTWARE
1 INTRODUÇÃO
O desenvolvimento de sistemas é um processo que segue algumas
etapas, como projeto ou análise, codificação, testes, implantação. A definição das
etapas pode variar de caso para caso, mas, de uma forma geral, o processo de
desenvolvimento está relacionado a essas etapas. Neste tópico serão apresentadas
as etapas do processo de desenvolvimento de um sistema e as atividades que são
necessárias para que essas fases sejam cumpridas.
A única certeza que se tem durante toda a fase de desenvolvimento de

software é a mudança, seja no projeto ou na própria equipe. Baseado nessa premissa
é preciso alguém para organizar, planejar e executar atividades que facilitem o
processo de trabalho e a sua continuidade.
A gerência pode se dar sobre coisas, pessoas ou ambos. O gerente organiza

seu ambiente de trabalho, toma decisões, direciona o trabalho de funcionários ou
membros de uma equipe.
Pode-se definir o termo equipe como um conjunto de pessoas trabalhando

para atingir o mesmo objetivo (Projeto). Gerenciar a equipe do projeto tem
como objetivo acompanhar o desempenho da equipe, fornecer feedback, resolver
problemas e coordenar mudanças para melhorar o desempenho do projeto.
Começa-se então contextualizando a gerência do projeto e as atividades

que fazem parte do desenvolvimento de projeto.
2 FASES DO DESENVOLVIMENTO DE SISTEMAS

O processo de desenvolvimento de software classifica em atividades as
tarefas que serão realizadas durante a construção de sistema. Mesmo havendo
vários processos de desenvolvimento, há um consenso de que não existe um
melhor processo, ou aquele que se aplica a todas as situações de desenvolvimento.
Bezerra (2015) afirma que cada processo tem suas particularidades em relação ao
modo de arranjar e encadear as atividades de desenvolvimento.
Silva (2014) adverte que, muitas vezes, um analista sem muita experiência
pode achar interessante começar o sistema programando, antes de entender por
101
completo as necessidades do cliente. Vale lembrar que essa solução apressada

pode resolver a solução de determinado problema, mas pode acarretar outros
bem mais complexos. Ele sugere que é indispensável seguir uma metodologia de
projeto com ênfase no planejamento adequado. Ainda de acordo com o autor, para
o projeto de desenvolvimento de um sistema a equipe deve ter as seguintes fases
em mente.
TURO S
ESTUDOS FU
A Figura 32 demonstra o encadeamento das atividades que serão detalhadas depois.
FIGURA 32 – ENCADEAMENTO DAS ATIVIDADES
FONTE: Adaptado de Silva (2014, p. 29)
2.1 ESTUDO DE VIABILIDADE

Essa é a fase que consiste na avaliação detalhada dos custos e benefícios
do desenvolvimento do projeto para a empresa. Deve-se analisar se os riscos e
as limitações forem superiores aos benefícios. É o momento de cancelar ou fazer
mudanças que se adequem da melhor maneira para a empresa.
Ainda nessa fase de avaliação, Silva (2014) esclarece que durante essa fase
existem dois pontos importantes que devem ser avaliados. A Viabilidade Técnica
e a Viabilidade Econômica. A Viabilidade Técnica refere-se ao ambiente em que o
sistema será instalado, a familiaridade dos usuários com a tecnologia aplicada. Já
a Viabilidade Econômica demonstra a famosa e conhecida por todos, custo versus
benefício. Pois o desenvolvimento do sistema envolve custos operacionais, custos
102
TÓPICO 3 | DESENVOLVIMENTO E EQUIPE DE SOFTWARE
de desenvolvimento, de compra de equipamentos, além da contratação, em alguns

casos, de profissionais especializados.
2.1.1 Análise
Nesta fase, o analista faz um levantamento detalhado de dados e fatos,
para descobrir o que realmente precisa ser desenvolvido. Silva (2014) diz que
durante essa fase o trabalho deve ser desenvolvido de forma disciplinada e
gradual, obedecendo rigorosamente aos critérios técnicos previstos, evitando que
a equipe pule fases, comprometendo assim o desempenho do sistema que será
desenvolvido. O autor adverte que é indispensável identificar todos os elementos
de dados que podem gerar informações. Esse levantamento pode ser realizado por
meio de pesquisas em documentos, entrevistas, análise de arquivos e contato com
os usuários. Ele enumera alguns documentos resultantes dessa fase, vale ressaltar
que não são todos, pois podem variar de projeto para projeto:
• Definição dos principais objetivos do novo sistema.

• Descrição do funcionamento do sistema.
• Especificação do fluxo e dados.
• Descrição dos arquivos a serem utilizados.
• Identificação de prazo para a apresentação de resultados ao usuário e
• Construção do modelo lógico.
Formalmente, o termo análise corresponde a “quebrar” um sistema e seus

componentes e estudar como eles interagem entre si com o objetivo de entender
como esse sistema funciona. Esta é a etapa em que os analistas realizam um estudo
detalhado dos requisitos levantados. A partir desse estudo, são construídos os
modelos para representar o sistema que será construído. Esses modelos devem
ser cuidadosamente validados e verificados. (BEZERRA, 2015). O autor esclarece
o objetivo da validação, que é assegurar que as necessidades do cliente estão
sendo atendidas pelo sistema. Ele quer assegurar-se de que a especificação que os
analistas construíram do software é correta, consistente, completa, realista e sem
ambiguidade. Se um modelo não é bem definido, é possível que tanto usuários
quanto desenvolvedores tenham diferentes interpretações acerca do sistema a
ser desenvolvido. Ainda segundo o autor, a verificação tem o objetivo de analisar
se os modelos construídos estão em conformidade com os requisitos definidos.
Na verificação dos modelos é onde são analisadas a exatidão de cada modelo em
separado e a consistência entre eles.
103
NOTA
Para dizer o que é Modelo Lógico e Modelo Físico:
Modelo Lógico: Concentra-se nos detalhes da construção. O modelo lógico, também

referenciado como esquema de banco de dados, é gerado aplicando-se as regras de derivação
de tabelas para um modelo relacional de banco de dados. Dependendo da situação, é possível
definir mais de um modelo lógico.
Modelo Físico: Demonstra como os dados são fisicamente armazenados na base de dados.
São detalhados os componentes da estrutura física do banco, como tabelas, campos, tipos de
valores, índices, etc.
2.1.2 Projeto
Na fase de projeto definida por Bezerra (2015), determina-se “como”
o sistema funcionará para entender os requisitos, de acordo com os recursos
tecnológicos existentes. Nesta fase considera-se os aspectos físicos e dependentes
da implantação. Os modelos que foram construídos nesta fase são adicionados
às restrições tecnológicas. Nesta fase se produz uma descrição computacional do
que o software deve fazer de uma maneira coerente com a descrição que foi feita na
análise.
Alguns exemplos de aspectos a serem considerados nesta fase:
• Arquitetura física do sistema.

• Padrão de interface gráfica.
• Algoritmos específicos.
• O gerenciador de banco de dados.
Essa é a fase onde o analista deve assimilar exatamente o que deve ser feito
e fazer a transformação do Modelo Lógico criado na fase anterior, para o Modelo
Físico. É durante essa fase que o analista conhece com profundidade o problema
do usuário e propõe soluções.
Podemos listar alguns documentos, de acordo com Silva (2014), que são
gerados nessa fase de projeto do sistema.
• Diagrama de fluxo de dados Brooks

• Tipos de bancos de dados
• Especificação dos relatórios
O projeto detalhado é uma das fases mais decisivas do desenvolvimento,

ela tem a facilidade do analista que deve completar o fluxo de dados, conforme
definido. É nesta fase que se deve definir com os programadores e os usuários,
104
todos os detalhes da implementação, além de conter todas as especificações

técnicas necessárias para codificação de cada programa.
2.1.3 Implementação
Na fase de implementação o sistema é codificado, ou seja, ocorre a tradução
da descrição computacional obtida na fase de projeto em código executável
mediante o uso de uma ou mais linguagens de programação (BEZERRA, 2015).
Definição semelhante é dada por Silva (2014):
Com base nos programas definidos no projeto, inicia-se a sua codificação

na linguagem de programação escolhida. A implementação consiste na
codificação de programas, isto é, na construção física do sistema. Essa
atividade está mais centrada nos programadores.
2.1.4 Implantação
Esse momento de implantação constitui um marco fundamental na vida do
sistema, pois, se houver falhas, a credibilidade da equipe de sistemas será abalada.
Esta fase de implantação consiste na entrega do produto concluído ao cliente e
pronto para ser colocado em operação. Essa fase deve ser muito bem planejada e
articulada com os gerentes dos setores usuários, além dos seguintes passos (SILVA,
2014, p.36):
• Teste geral do sistema com dados reais.

• Treinamento de usuários.
• Acompanhamento de todos os procedimentos operacionais pela
equipe de análise.
• Controle e análise de resultados dos processamentos.
Bezerra define essa fase como sendo a fase em que o sistema é empacotado,
distribuído e instalado no ambiente do usuário. Também nessa fase os manuais do
sistema são escritos, os arquivos carregados, dados importados para o sistema e
os usuários para utilização correta do sistema. Em alguns casos, ocorre também a
migração de sistemas e software e dados preexistentes.
2.2 GERENCIAMENTO DE PROJETOS

O gerenciamento de projetos de software é uma parte essencial da
engenharia de software. De acordo com o guia PMBOK 5 (2013), o gerenciamento
de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às
105
atividades do projeto com o objetivo de atender aos requisitos. O gerenciamento

de projetos é dividido em cinco grandes grupos, que são: Iniciação, Planejamento,
Execução, Monitoramento e Controle e o Encerramento do projeto. Ainda segundo
PMI (2013, p.4), a atividade de gerenciamento de projeto normalmente inclui as
seguintes atividades:
• Identificação de requisitos;
• Abordagem das diferentes necessidades, preocupações e expectativas
das partes interessadas no planejamento e execução do projeto;
• Estabelecimento, manutenção e execução de comunicações ativas,
eficazes e colaborativas entre os envolvidos no projeto;
• Gerenciamento das partes interessadas visando o atendimento aos
requisitos do projeto e a criação das suas entregas,
• E o equilíbrio das restrições conflitantes do projeto.
Para ilustrar algumas das possíveis restrições conflitantes (PMI, 2013, p.5):
• Escopo;
• Qualidade;
• Cronograma;
• Orçamento;
• Recursos e
• Riscos.
É importante deixar claro que as circunstâncias e as características de um

projeto podem influenciar as restrições nas quais a equipe de gerenciamento de
projeto precisa se concentrar.
Hazrati apud Buzon afirma que um artigo publicado na Harvard Business

Review tem despertado grande interesse na comunidade. Os resultados indicam
que projetos de TI são muito mais arriscados do que se pensa: entre os mais de
1.400 projetos pesquisados, uma média de 27% extrapolou o orçamento e 16% dos
projetos poderiam ser chamados de Cisnes Negros, pois excederam o custo em
mais de 200% e tiveram atrasos de mais de 70%, um nível de fracasso grande o
suficiente para levar empresas à falência.
Azevedo (2008) do site Mundo PMP, também apresenta números

alarmantes, ela diz que: “70% dos projetos falham no cumprimento de cronograma,
custos e metas de qualidade e 50% são executados acima do orçamento”. Segundo
a autora, o problema não é apenas que a maioria dos projetos de TI não consegue
alcançar os resultados esperados. Mesmo quando os projetos são executados
com sucesso, muitas vezes eles ainda não trazem benefícios para o negócio. O
verdadeiro problema é que há uma falta de alinhamento entre os objetivos do
negócio e as atividades de TI. A gerência executiva e as unidades de negócios
têm uma visibilidade limitada sobre o que TI está fazendo e TI tem uma conexão
limitada com os objetivos estratégicos e do negócio. Um olhar mais de perto para
esta importante questão, de uma perspectiva de negócios e de uma perspectiva
técnica, mostra as causas raízes da falha do projeto.
É possível perceber como a falta de alinhamento gera um problema muito

sério no desenvolvimento de sistemas.
106
TURO S
ESTUDOS FU
No tópico a seguir vamos conhecer um pouco mais sobre a equipe de

desenvolvimento.
2.3 EQUIPE DE DESENVOLVIMENTO

Em seu livro “O mítico homem-mês”, escrito em 1975, Frederick Brooks
usa de muitas analogias interessantes para ilustrar a importância da equipe de
desenvolvimento. Analogias estas, que ainda são atuais.
DICAS
Conheça mais desse autor, veja: <http://www.dicas-l.com.br/arquivo/planejador_

mestre_fred_brooks_mostra_como_projetar_qualquer_coisa.php>
Passados mais de 40 anos, esse livro continua atual de acordo com os

dados apresentados anteriormente, e essa frase ainda se aplica e muito no
desenvolvimento de projetos. Brooks (1975) ainda usa outro exemplo no primeiro
capítulo, onde fala sobre como grandes empresas de desenvolvimento de software
têm dificuldade de terminar seus projetos no prazo, com o gasto previsto e com a
qualidade esperada, fazendo referência ao problema mortal do "poço de alcatrão
(piche)" para as grandes feras pré-históricas. Pois quando o projeto começa a
atrasar, eles vão colocando mais e mais recursos, o que na maioria das vezes não
ajuda, é apenas mais uma fera no poço de piche.
FIGURA 33 - MURAL DOS POÇOS DE ALCATRÃO DE LA BREA
FONTE: Brooks Jr. (1975, p.2)
107
Bezerra (2015) diz em seu livro que a atividade de desenvolvimento de

software é uma tarefa altamente cooperativa, pois tecnologias complexas demandam
especialistas em áreas específicas. Segundo ele, uma equipe de desenvolvimento de
software é composta por um gerente, analistas, projetistas, programadores, clientes
e grupo de avaliação de qualidade, que serão descritos a seguir, individualmente.
Ele também alerta que essa descrição dos participantes tem um fim mais didático,
pois, na prática, a mesma pessoa desempenha diferentes funções e uma mesma
função é desempenhada por várias pessoas.
2.3.1 Gerente
Segundo Bezerra (2015), o gerente de projetos é a pessoa responsável pela
gerência ou coordenação das atividades necessárias à construção do sistema. Ele
também é o responsável que desempenhará atividades como: orçamento do projeto,
estimar o tempo para o desenvolvimento do sistema, definir qual o processo de
desenvolvimento, o cronograma das atividades, a mão de obra especializada, bem
como os recursos de hardware e software.
O site Portal da Administração explica, de uma maneira geral, que a função

do gerente de projetos é determinar e executar as necessidades do cliente, seja
por indicação desse, ou baseado em seus próprios conhecimentos. O gerente de
projetos deve ser capaz de imaginar o projeto por inteiro, do seu início ao seu
final, trabalhando para manter o progresso e a interação mútua dos participantes,
reduzindo os riscos de fracasso.
108
FIGURA 34- O GERENTE DE PROJETOS
FONTE: Disponível em: <http://www.humordaterra.com/wp-content/

uploads/2011/06/Gerenciamento-de-projetos.jpg>. Acesso em: 22 mar. 2016.
2.3.2 Analistas
De acordo com a definição de Bezerra (2015), analista de sistemas é o
profissional que deve ter o conhecimento do negócio e entender seus problemas
para que possa definir os requisitos do sistema a ser desenvolvido. Deve estar
apto a se comunicar com especialistas do domínio para obter conhecimento
acerca dos problemas e das necessidades envolvidas na organização empresarial.
Ainda segundo o autor, o analista não precisa ser um especialista, mas deve ter
domínio suficiente do vocabulário da área de conhecimento na qual o sistema
será implantado, evitando assim que o profissional especialista de domínio seja
interrompido a todo momento para explicar conceitos da área.
109
FIGURA 35 – ANALISTAS DE SISTEMAS
FONTE: Disponível em: <http://vidadeprogramador.com.br/

page/2/?s=analista+de+sistemas>. Acesso em: 22 mar. 2016.
2.3.3 Projetistas
Bezerra (2015) define o projetista de sistemas como o integrante da equipe
de desenvolvimento cujas funções são: avaliar as alternativas de solução (da
definição) do problema resultante da análise. Ele diz também que o projetista tem
como função gerar a especificação de uma solução computacional detalhada.
2.3.4 Arquitetos de software

O arquiteto de software é um profissional encontrado principalmente em
grandes equipes reunidas para desenvolver sistemas complexos, de acordo com
Bezerra (2015). É ele quem toma decisões sobre quais subsistemas compõem o
sistema como um todo e quais são as interfaces entre esses subsistemas. Além de
tomar decisões globais, esse profissional, de acordo com o autor, também deve ser
capaz de tomar decisões técnicas detalhadas.
110
Tavares (2014), em relação à atividade de arquitetura de software, diz que:
Deveria ser óbvio colocar a arquitetura no centro de um projeto de

desenvolvimento de software. Não só do ponto de vista tecnológico, mas
também do ponto de vista do planejamento gerencial. Esta ilustração
mostra que as partes interessadas fornecem metas de negócios que são
destiladas em condutores arquiteturais, que conduzem toda a estrutura
da arquitetura. A arquitetura é iterativamente refinada e pode, por
sua vez, refinar os condutores arquiteturais, bem como as metas de
negócios. O DAS (documento de arquitetura de software) se torna o
principal artefato mantido ao longo de todo o projeto.
FIGURA 36 – ARQUITETURA DE SOFTWARE
FONTE: Tavares (2014)
111
A atividade do arquiteto, segundo Meriat (2011), é ilustrada através da

tirinha.
FIGURA 37 – COMO SER UM ARQUITETO DE SOFTWARE
FONTE: Disponível em: < http://www.vitormeriat.com.br/category/charges/>.

2.3.5 Programadores
Talvez seja o profissional mais conhecido na área de sistemas, pois ele é
o responsável pela implementação do sistema. Bezerra (2015) afirma quem em
um projeto é comum haver vários programadores. Um programador pode ser
proficiente em uma ou mais linguagens de programação, além de ter conhecimento
sobre banco de dados e poder ler os modelos resultantes do trabalho do projetista.
O autor pontua algumas diferenças entre as atividades desempenhadas entre os
programadores e os analistas. O analista de sistemas está envolvido em todas as
etapas do desenvolvimento, diferente do programador, que participa unicamente
das fases finais (implementação e testes). É comum bons programadores serem
“promovidos” a analistas de sistemas. Mas, ainda que,segundo o autor, essa seja
uma prática recorrente nas empresas de desenvolvimento de software, há uma falsa
lógica, pois nem sempre bons programadores serão bons analistas.
112
6 PASSOS PARA ALAVANCAR A PRODUTIVIDADE DA MINHA EQUIPE

DE SERVIÇOS PROFISSIONAIS
por Thiago Reis em Pessoas
Dobrar a produção do time de consultoria e conseguir assumir mais

projetos sem precisar contratar novos colaboradores. Qual gerente de projetos não
sonha com isso?
Apesar da rotina atribulada, validação de entregas, atendimento ao cliente

e alterações no escopo, é possível, com planejamento e foco, ampliar as entregas e
resultados. Para ajudá-lo, separamos os seis passos para que você consiga dobrar a
produtividade da sua equipe de desenvolvedores mantendo o nível de qualidade
das entregas:
1 Identifique os gargalos 80 - 20, conheça bem a sua equipe e respectivas

habilidades
A Lei de Pareto (também conhecida como princípio 80-20) afirma que para
muitos fenômenos, 80% das consequências advêm de 20% das causas. A lei foi
sugerida por Joseph M. Juran, que deu o nome em honra ao economista italiano
Vilfredo Pareto.
Aplicando a Lei de Pareto à prestação de serviços profissionais, assumimos

que 80% do seu resultado vêm de atividades que concentram 20% do seu esforço.
Independente do seu dia a dia, são essas ações que você deve garantir que serão
feitas. Analise como otimizá-las e como liberar o tempo da sua equipe. Normalmente
gastamos uma quantidade de tempo significativo preparando apresentações e
relatórios. Uma maneira de reduzir esse tempo é automatizando esse processo.
Encontre os gargalos onde seu time gasta mais tempo.
2 Automatize a distribuição de tarefas
Pesquisas realizadas com nossos clientes que conseguiram atingir um ROI

significativo com adoção de uma ferramenta identificaram que um membro da
equipe perdia um grande tempo tentando saber quais as atividades ele deveria
realizar no dia, assim como os gestores de projetos perdiam enviando e-mails
solicitando que uma tarefa seja feita e cobrando se a mesma foi executada.
Para distribuir as tarefas de maneira que elas sejam realizadas corretamente

e no tempo determinado, você deve saber delegá-las de forma simples e automática.
Uma ferramenta de gestão de projetos colaborativa te ajuda significativamente
com esse processo. Em uma pesquisa realizada com nossos clientes, identificamos
que membros da equipe tiveram uma economia média de 30 minutos por dia, e
gerente de projetos pelos gestores leva 20 minutos a menos, por dia (por projeto)
no gerenciamento.
113
3 Defina uma metodologia de trabalho
Tenha sua equipe alinhada a uma única metodologia de trabalho. É

importante que os processos estejam claros e bem executados por todos. Isso o ajudará
a conversar com toda a equipe em uma mesma linguagem, minimizando ruídos.
Além disso, algumas metodologias de projetos, como o CCPM (Gerenciamento de
Projetos por Corrente Crítica), já citado aqui no blog anteriormente, têm ganhado
destaque ao apontar excelentes resultados na otimização da produtividade sem
comprometer prazos de entrega.
4 Meça a produtividade sempre
Há diversas formas de medir a produtividade de seus desenvolvedores.

Porém, antes é preciso definir os indicadores de fato importantes para esta resposta
conforme a necessidade da sua equipe, empresa ou até mesmo projeto.
Para mensurar, é interessante utilizar sistemas de gerenciamento de projetos

que permitam a emissão de relatórios de produtividade periódicos. Através deles é
possível conferir relatórios com o andamento diário, semanal ou mensal, além de
poder optar por avaliar o trabalho de um membro ou de toda a equipe. Este tipo de
ferramenta é muito útil dentro das empresas para encontrar as falhas e aumentar
a produtividade.
Analisar a quantidade de horas gastas em determinado período, separando-

as em urgentes, importantes, rotineiras e não planejadas, pode trazer dados
consideráveis para administrar o tempo gasto em cada etapa do processo e como
este tem sido aproveitado. Um profissional que tem seu tempo e produtividade sob
controle consegue realizar entregas de 75% a 100% do que foi planejado. Caso o
resultado apresentado seja inferior, é hora de reavaliar as definições e reestruturar
algo.
5 Converse com os seus funcionários
Gerir pessoas é uma tarefa complexa que pode impactar diretamente

na produtividade de sua equipe. Lidar com motivações pessoais, interesses e
objetivos diferentes para realizar uma mesma entrega exige muito jogo de cintura.
Por isso, manter um diálogo com seus desenvolvedores, seja para esclarecimentos,
orientações, feedbacks ou uma simples reunião de alinhamento, é muito importante.
6 Adquira um software para gestão de projetos
Uma ferramenta tecnológica para gerir projetos pode auxiliá-lo não

apenas a acompanhar a execução das tarefas delegadas, mas também para evitar
procrastinação dos desenvolvedores.
Através de um software é possível avaliar o tempo médio gasto em cada

atividade, extrair relatórios de progressos da equipe (comparando o que foi
planejado e o que foi executado), minimizar riscos, facilitar o acesso à documentação
114
e até mesmo apontar falhas em processos. Ainda é possível planejar o esforço

necessário para cada atividade, analisar o atual comprometimento do membro da
equipe, bem como a alocação de recursos e padronizar o apontamento de horas
(o famoso timesheet). Tudo isso ajudará consideravelmente a aumentar o nível de
produtividade do projeto.
Com estes passos você terá maior envolvimento com sua equipe e controle
das respectivas entregas, além de poder aumentar a produtividade.
FONTE: <http://www.projectbuilder.com.br/blog-pb/entry/pessoas/6-passos-para-alavancar-a-
produtividade-da-minha-equipe-de-servicos-profissionais> Acesso em: 13 jan 2016.
DICAS
O site Techtudo apresenta a história de como a programação começa, veja que legal.
http://www.techtudo.com.br/platb/desenvolvimento/2011/06/20/historia-da-programacao-
como-tudo-comecou/Quer conhecer os maiores programadores da história? Veja a matéria
que a revista Exame preparou. Veja quantos você conhece:http://exame.abril.com.br/tecnologia/
noticias/os-22-programadores-mais-importantes-da-historia
115
RESUMO DO TÓPICO 3
• As fases de desenvolvimento de um sistema e quem as desempenha.
a) Estudo de viabilidade: Essa é a fase que consiste na avaliação detalhada

dos custos e benefícios do desenvolvimento do projeto para empresa. Deve-
se analisar se os riscos e as limitações forem superiores aos benefícios, é o
momento de cancelar ou fazer mudanças que se adequem da melhor maneira
para a empresa.
b) Análise: Nesta fase, o analista faz um levantamento detalhado de dados e
fatos, para descobrir o que realmente precisa ser desenvolvido.
c) Projeto: Determina-se “como” o sistema funcionará para entender os
requisitos, de acordo com os recursos tecnológicos existentes, nesta fase
consideram-se os aspectos físicos e dependentes da implantação.
d) Implementação: O sistema é codificado, ou seja, ocorre a tradução da
descrição computacional obtida na fase de projeto em código executável
mediante o uso de uma ou mais linguagens de programação.
e) Implantação: Esta fase de implantação consiste na entrega do produto
concluído ao cliente e pronto para ser colocado em operação.
f) Gerenciamento de projetos: o gerenciamento de projetos é a aplicação de
conhecimento, habilidades, ferramentas e técnicas às atividades do projeto
com o objetivo de atender aos requisitos.
g) Equipe de desenvolvimento: A equipe de desenvolvimento de software é
composta por um gerente, analistas, projetistas, programadores, clientes e
grupo de avaliação de qualidade.
h) Gerente: É a pessoa responsável pela gerência ou coordenação das atividades
necessárias à construção do sistema. Ele também é o responsável que
desempenhará atividades como: orçamento do projeto, estimar o tempo para
o desenvolvimento do sistema, definir qual o processo de desenvolvimento,
o cronograma das atividades, a mão de obra especializada, bem como os
recursos de hardware e software.
i) Analistas: O profissional que deve ter o conhecimento do negócio e entender
seus problemas para que possa definir os requisitos do sistema a ser
desenvolvido. E que deve estar apto a se comunicar com especialistas do
domínio para obter conhecimento acerca dos problemas e das necessidades
envolvidas na organização empresarial.
j) Projetistas: Têm como função gerar a especificação de uma solução
computacional detalhada.
k) Arquiteto de software: É ele quem toma decisões sobre quais subsistemas
compõem o sistema como um todo e quais são as interfaces entre esses
subsistemas. E além de tomar decisões globais, esse profissional também
deve ser capaz de tomar decisões técnicas detalhadas.
l) Programadores: Talvez o profissional mais conhecido na parte área de
sistemas, pois eles são os responsáveis pela implementação do sistema.
116
AUTOATIVIDADE
1 Quais são algumas das atividades de gerenciamento de projeto?
2 Identifique o profissional a que se referem as definições a seguir:
Cargo Descrição
Talvez o profissional mais conhecido na área de sistemas, pois
eles são os responsáveis pela implementação do sistema.
Profissional que deve ter o conhecimento do negócio e entender
seus problemas para que possa definir os requisitos do sistema
a ser desenvolvido. E que deve estar apto a se comunicar com
especialistas do domínio para obter conhecimento acerca dos
problemas e das necessidades envolvidas na organização
empresarial.
É ele quem toma decisões sobre quais subsistemas compõem
o sistema como um todo e quais são as interfaces entre esses
subsistemas. E além de tomar decisões globais, esse profissional
também deve ser capaz de tomar decisões técnicas detalhadas.
O integrante da equipe de desenvolvimento, cujas funções são:
avaliar as alternativas de solução (da definição) do problema
resultante da análise.
É a pessoa responsável pela gerência ou coordenação das
atividades necessárias à construção do sistema. Ele também é
o responsável que desempenhará atividades como: orçamento
do projeto, estimar o tempo para o desenvolvimento do
sistema, definir qual o processo de desenvolvimento, o
cronograma das atividades, a mão de obra especializada, bem
como os recursos de hardware e software.
3 O gerente de projeto pode encontrar alguns problemas que geram conflito,

quais são?
117
118
UNIDADE 3
REVISÃO DE CONCEITOS DA
UML, DIAGRAMAS DE VISÃO
COMPORTAMENTAL E ESTRUTURAL
E UM DETALHAMENTO
NOS CASOS DE USO
A partir desta unidade você será capaz de:
• revisar conceitos de UML;
• conhecer a visão comportamental dos diagramas da UML;
• aprofundar um pouco mais seu conhecimento nos casos de uso;
• ver exemplo de Diagrama de Classe;
• verificar a aplicação do Diagrama de Sequência.
PLANO DE ESTUDOS
Esta unidade de ensino contém cinco tópicos. No final de cada um deles você
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE)
TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E

COMPORTAMENTAIS
TÓPICO 3 - MODELO DE CASO DE USO
TÓPICO 4 - DIAGRAMA DE CLASSE
TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA
119
120
UNIDADE 3
TÓPICO 1
UML (UNIFIED MODELING LANGUAGE)
1 INTRODUÇÃO
Nesta unidade será apresentada a linguagem de modelagem unificada, a
UML, e a sua importância no desenvolvimento de software. Veremos como uma
notação gráfica bem executada no projeto de desenvolvimento de software diminui
a dificuldade de entendimento entre as partes envolvidas nessa fase.
Para iniciar os estudos, será apresentada a origem da UML, seus criadores

e seus diagramas de modelagem.
Dar-se-á ênfase ao modelo de caso de uso e aos diagramas de classe e de

sequência, onde será dedicado um tópico específico para esses diagramas, com o
objetivo de ampliar seu conhecimento, devido à sua importância no processo de
modelagem.
2 MODELO CONCEITUAL DA UML

A construção da linguagem UML teve muitos contribuintes, mas os
principais atores no processo foram Grady Booch (criador da Booch method),
James Rumbaugh (criador da OMT) e Ivar Jacobson (criador da OOSE). Esses
três pesquisadores, que também eram chamados de “os três amigos”, buscaram
aproveitar o melhor das características notações preexistentes, principalmente das
técnicas que eles haviam proposto anteriormente, removendo alguns elementos
e incluindo outros, com o objetivo de torná-la mais expressiva (BEZERRA, 2015).
A UML, ainda segundo o autor, é uma linguagem visual para modelar sistemas
orientados a objetos, ou seja, é uma linguagem que define elementos gráficos
(visuais) que podem ser utilizados na modelagem de sistemas. Elementos esses
que permitem a representação dos conceitos do paradigma de orientação a objeto.
De acordo com Booch et al. (2000), criadores da UML, ela é uma linguagem
padrão para a elaboração da estrutura de projetos de software. Pode ser utilizada
para a aplicação, visualização, especificação, construção e a documentação de
artefatos que façam uso de sistemas complexos de software. Os autores afirmam
que a UML é uma linguagem utilizada para:
• Visualizar.
• Especificar.
121
UNIDADE 3 | REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO COMPORTAMENTAL E
ESTRUTURAL E UM DETALHAMENTO NOS CASOS DE USO
• Construir e
• Documentar.
Bezerra (2015) reforça que a UML é independente tanto de linguagem de

programação quanto de processos de desenvolvimento. O que significa que ela
pode ser utilizada para a modelagem de sistemas, independente de qual linguagem
de programação será utilizada e a forma de desenvolvimento.
Booch et al. (2000) alertam que para compreender a UML, você precisa
formar um modelo conceitual da linguagem, e isso implica em aprender três
elementos principais:
• Os blocos de construção básicos da UML.

• As regras que determinam como esses blocos poderão ser combinados e
• Mecanismos de uso geral, que dão mais clareza às definições criadas
pelos blocos de construção.
2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML

O vocabulário da UML abrange três tipos de blocos de construção, segundo
Booch et al. (2000):
• Itens (abstrações identificadas como cidadão de primeira classe em um modelo)

• Relacionamentos (reúnem esses itens) e
• Diagramas (agrupam coleções interessantes de itens).
Existem quatro tipos de itens na UML. Estes itens constituem os blocos de

construção básicos orientados a objetos da UML, e você os utilizará para escrever
modelos bem formados:
• Estruturais
• Comportamentais
• Agrupamento e
• Anotacionais
2.1.1 Itens estruturais

São os substantivos utilizados em modelos da UML. São a parte mais
estática do modelo, representando elementos conceituais ou físicos. Ao todo são
sete os itens estruturais, conforme Booch et al. (2000), que definiremos a seguir
individualmente:
122
TÓPICO 1 | UML (UNIFIED MODELING LANGUAGE)
• Classes.
• Interfaces.
• Colaborações.
• Casos de uso.
• Classes ativas.
• Componentes.
• Nós.
Classes: As classes são descrições, como conjuntos de objetos que

compartilham os mesmos atributos, operações, relacionamento e semântica.
As classes implementam uma ou mais interfaces. A sua representação, feita por
retângulo, geralmente inclui seu nome, atributos e operações.
Interfaces: É uma coleção de operações que especificam serviços de uma

classe ou componente, elas descrevem o comportamento externamente visível
desse elemento. A interface define um conjunto de operações (suas assinaturas),
mas nunca um conjunto de implementações de operações. São representadas
graficamente por um círculo e o respectivo nome. As interfaces raramente
aparecem sozinhas, costumam aparecer anexadas a uma classe ou um componente
que realiza a interface.
Colaborações: As colaborações contêm dimensões estruturais, assim

como comportamentais. Uma determinada classe poderá participar em várias
colaborações. Assim, essas colaborações representam a implantação de padrões
que formam um sistema. São representadas na forma de elipses com linhas
tracejadas, geralmente incluindo seu nome.
Caso de uso: É a descrição de um conjunto de sequência de ações realizadas

pelo sistema que proporciona resultados observáveis de valor para um determinado
ator. Um caso de uso é realizado por uma colaboração e é utilizado para estruturar
o comportamento de itens em um modelo. Semelhante à colaboração, o caso de
uso também é representado por uma elipse, mas com linhas contínuas.
Os três itens restantes, ainda continuando com Booch et al. (2000), as

classes ativas, os componentes e os nós, são semelhantes às classes, elas descrevem
conjuntos de objetos que compartilham os mesmos atributos, operações,
relacionamentos e semânticas.
123
TURO S
ESTUDOS FU
Será detalhado a seguir cada um individualmente.
Classes ativas: São classes cujos objetos têm um ou mais processos ou

threads e, portanto, podem iniciar a atividade de controle. Podemos dizer que o
que difere uma classe de uma classe ativa é o fato de que seus objetos representam
elementos cujo comportamento é concorrente com o de outros elementos. Outro
item que difere é a representação, que neste caso tem linhas mais grossas.
NOTA
Definição de threads: Um pequeno programa que trabalha como um subsistema

independente de um programa maior, executando alguma tarefa específica. Um programa
dividido em vários threads pode rodar mais rápido que um programa monolítico, pois várias
tarefas podem ser executadas simultaneamente. Os vários threads de um programa podem
trocar dados entre si e compartilhar o mesmo espaço de memória e os mesmos recursos do
sistema. Acesse o link: <http://www.hardware.com.br/termos/thread>.
Componentes: São partes físicas e substituíveis de um sistema, que

proporcionam a realização de um conjunto de interfaces. Tipicamente, os
componentes representam o pacote físico de elementos lógicos diferentes, como
classes, interfaces e colaborações. A representação dos componentes é feita por
retângulos com abas, incluindo somente seus nomes.
Nós: É um elemento físico existente em tempo de execução que representa

um recurso computacional, geralmente com pelo menos alguma memória e,
frequentemente, capacidade de processamento. Em um nó pode haver um conjunto
de componentes e um nó pode migrar de um nó para outro. Sua representação é
um cubo, normalmente com seu nome, segundo Booch et al. (2000).
2.1.2 Itens comportamentais

Os itens comportamentais são os itens que definem as partes dinâmicas
dos modelos UML. São também chamados de Verbos do Modelo, representando
comportamentos no tempo e no espaço. Constituem itens: interações, máquina de
estados e atividades. Existem dois tipos principais de itens comportamentais:
124
TÓPICO 1 | UML (UNIFIED MODELING LANGUAGE)
Interações: são os conjuntos de troca de mensagens entre objetos, também

chamados de comportamento. As interações envolvem outros elementos, inclusive
mensagens, sequências de ações (os comportamentos chamados pelas mensagens)
e ligações (as conexões entre os objetos). Em UML, as mensagens são representadas
por uma seta traçada sob seu nome, conforme Booch et al. (2000).
Máquinas de estado: É um comportamento que especifica as sequências

de estado pelas quais objetos ou interações passam durante sua existência em
resposta a eventos, bem como suas respostas a esses eventos. Uma máquina de
estado abrange outros elementos, incluindo estados, transições (o fluxo de um
estado a outro), eventos (itens que disparam uma transição) e atividades (as
repostas às transições). Graficamente é representado por um retângulo com bordas
arredondadas, com o seu nome e respectivos subestados (BOOCH et al., 2000).
2.1.3 Itens de agrupamento

Itens de agrupamento: São as partes organizacionais dos modelos UML,
são os blocos em que os modelos podem ser decompostos. Existe apenas um tipo
principal de item de agrupamento, chamado Pacote. Sua representação é como
diretórios com guias, geralmente incluindo somente seus nomes e, às vezes, seu
conteúdo. Conforme Booch et al. (2000, p. 22):
Um pacote é um mecanismo de propósito geral para a organização de

elementos em grupos. Os itens estruturais, os itens comportamentais
e até outros itens de grupos podem ser colocados em pacotes. Ao
contrário dos componentes (que existem em tempo de execução), um
pacote é puramente conceitual (o que significa que apenas em tempo de
desenvolvimento).
2.1.4 Itens anotacionais

Itens anotacionais: São as partes explicativas dos modelos de UML, são os
comentários utilizados para esclarecer e fazer alguma observação sobre qualquer
modelo, e a nota é a forma de representar. Graficamente, uma nota é representada
por um retângulo com um dos cantos como uma dobra de página, acompanhado
por um texto ou comentário gráfico.
2.2 RELACIONAMENTOS NA UML

Esses relacionamentos são os blocos relacionais básicos de construção da
UML. Existem quatro tipos de relacionamentos, são eles:
125
• Dependência.
• Associação.
• Generalização e
• Realização.
Dependência: É um relacionamento semântico entre dois itens, nos quais

a alteração de um (o item independente) pode afetar a semântica do outro (o item
dependente). Sua representação é feita por linhas tracejadas, possivelmente com
setas e ocasionalmente incluindo um rótulo,
Associação: É um relacionamento estrutural que descreve um conjunto

de ligações, conforme Booch et al. (2000), em que as ligações são conexões entre
os objetos. A agregação é um tipo especial de associação, representando um
relacionamento estrutural entre o todo e suas partes. A representação é feita por
linhas sólidas, possivelmente direcionadas, ocasionalmente incluindo rótulos e
frequentemente contendo outros adornos, como nomes de papéis e multiplicidades.
Generalização: É um relacionamento de especialização/generalização,

em que os objetos dos elementos especializados (os filhos) são substituíveis por
objetos do elemento generalizado (os pais). Os filhos compartilham a estrutura e o
comportamento dos pais. Sua representação é uma linha sólida, com uma seta em
branco apontando para o pai.
Realização: É um relacionamento semântico entre classificadores, em que

um classificador especifica um contrato que outro classificador garante executar.
Esse relacionamento é encontrado entre interfaces e as classes ou componentes
que as realizam; e entre casos de uso e as colaborações que os realizam. Sua
representação é uma linha tracejada com seta branca, entre uma generalização e
um relacionamento de dependência.
126
RESUMO DO TÓPICO 1
• A UML é uma linguagem padrão para a elaboração da estrutura de projetos de

software. Ela pode ser utilizada para a aplicação, a visualização, a especificação, a
construção e a documentação de artefatos que façam uso de sistemas complexos
de software.
• Modelo conceitual da UML.
• Blocos de construção básicos da UML.
• Itens estruturais.
• Itens comportamentais.
• Itens de agrupamento.
• Itens anotacionais.
• Relacionamentos na UML.
127
AUTOATIVIDADE
1 Agora que você conheceu a UML, liste algumas aplicações dela.
2 Quais são os quatro tipos de itens na UML?
3 A definição a seguir se refere a qual item da UML e quais são os itens que a
compõem?
“São os substantivos utilizados em modelos da UML. São a parte mais

estática do modelo, representando elementos conceituais ou físicos.”
4 Faça a associação correta dos itens estruturais.
É uma coleção de operações que especificam serviços de uma

classe ou componente, elas descrevem o comportamento
externamente visível desse elemento. A interface define um
conjunto de operações (suas assinaturas), mas nunca um
conjunto de implementações de operações. São representadas
graficamente por um círculo e o respectivo nome.
Contém dimensões estruturais, assim como comportamentais.
Uma determinada classe poderá participar em várias
colaborações. Assim, essas colaborações representam a
implantação de padrões que formam um sistema. São
representadas na forma de elipses com linhas tracejadas,
geralmente incluindo seu nome.
É a descrição de um conjunto de sequência de ações realizadas
pelo sistema que proporciona resultados observáveis de valor
para um determinado ator. Um caso de uso é realizado por
uma colaboração e é utilizado para estruturar o comportamento
de itens em um modelo. Semelhante à colaboração, o caso de
uso também é representado por uma elipse, mas com linhas
contínuas.
É um elemento físico existente em tempo de execução que
representa um recurso computacional, geralmente com pelo
menos alguma memória e, frequentemente, capacidade de
processamento.
São descrições como conjuntos de objetos que compartilham os
mesmos atributos, operações, relacionamento e semântica. Elas
implementam uma ou mais interfaces.
São partes físicas e substituíveis de um sistema, que proporciona
a realização de um conjunto de interfaces. Tipicamente
representam o pacote físico de elementos lógicos diferentes,
como classes, interfaces e colaborações.
São classes cujos objetos têm um ou mais processos ou threads e,
portanto, podem iniciar a atividade de controle.
128
UNIDADE 3
TÓPICO 2
DIAGRAMAS DA UML: DIAGRAMAS
ESTRUTURAIS E COMPORTAMENTAIS
1 INTRODUÇÃO
Usar a ferramenta certa, para a atividade certa. Agir deste modo, com
certeza, facilita e muito o trabalho, você concorda?
Com esse objetivo de facilitar o trabalho e aumentar a produtividade, bem

como o entendimento das pessoas envolvidas em cada fase do projeto, é que a
UML desenvolveu um diagrama para cada função. Nem sempre se usa todos em
todos os projetos, mas é necessário que se tenha o conhecimento do que eles fazem
para tirar o melhor proveito e obter sucesso nos projetos.
A seguir será apresentado cada um em detalhes, para que você se sinta

confortável em saber qual usar e em que momento.
2 DIAGRAMAS
Um diagrama é a apresentação gráfica de um conjunto de elementos,
geralmente representada como gráficos de vértices (itens) e arcos (relacionamentos).
Segundo Booch et al. (2000), eles são desenhados para permitir a visualização de
um sistema sob diferentes aspectos.
Os artefatos gráficos produzidos durante o desenvolvimento de um sistema,

segundo Bezerra (2015), podem ser definidos pela utilização dos diagramas da
UML.
Talvez ainda surja o questionamento: “Para que tantos diagramas? ”

Segundo Guedes (2014), o objetivo é fornecer múltiplas visões do sistema que
está sendo modelado, analisando-o e modelando-o sob diversos aspectos, e
procurando, assim, atingir a totalidade da modelagem, permitindo que cada
diagrama complemente os outros. Em cada um dos diagramas da UML é analisado
o sistema, ou uma parte dele, de um determinado ponto de vista; é como se o
sistema fosse modelado em camadas.
Em alguns diagramas o sistema é visto de forma mais ampla, sem

muitos detalhes técnicos, apresentando uma visão externa do sistema e de fácil
entendimento para pessoas que não têm muito conhecimento técnico, como é o
objetivo do Diagrama de Caso de Uso. Diferente de outros diagramas que oferecem
129
uma visão um pouco mais profunda do software, eles têm por objetivo apresentar
um aspecto mais técnico ou ainda visualizar apenas uma característica específica
do sistema ou um determinado processo.
Guedes (2014) salienta que a utilização de diferentes diagramas permite

que falhas possam ser encontradas nos diagramas anteriores e assim diminuir a
possibilidade da ocorrência de erros durante a fase de desenvolvimento do software.
Vale ressaltar, como já foi dito anteriormente, que mesmo que cada diagrama
tenha sua função, nem sempre é necessário modelar um sistema utilizando-se de
todos os diagramas, pois alguns deles possuem funções muito específicas, como
é o caso do Diagrama de Tempo, que, por exemplo, tem como objetivo focalizar
o tempo ou duração da mensagem ou condições em mudança em uma linha de
tempo no diagrama. Detalharemos esse e outros diagramas a seguir.
NOTA
a UML é uma linguagem de modelagem visual, ou seja, é um conjunto de

notações e semântica correspondente para representar visualmente uma ou mais perspectivas
de um sistema. (BEZERRA, 2015, p. 19)
FIGURA 38 - DIAGRAMAS UML
FONTE: Bezerra (2015, p. 18)
130
TÓPICO 2 | DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS E COMPORTAMENTAIS
A versão 2.0 da UML, como se vê na figura anterior, traz consigo 13

diagramas, que são divididos em quatro grupos: Estruturais, Comportamentais,
Implementação e Interação. Esses diagramas serão detalhados a seguir.
E
IMPORTANT
A ordem da documentação dos diagramas não se refere à ordem em que eles

devem ser criados.
2.1 DIAGRAMAS ESTRUTURAIS

De uma maneira resumida, os diagramas estruturais definem a estrutura
do sistema tanto na parte de software, quanto de hardware. Como já dissemos,
nem todos os diagramas estruturais são necessários para a documentação de um
sistema. A seleção correta dos diagramas e a sua combinação são mais importantes
para uma modelagem eficiente, do que a modelagem de todos.
2.1.1 Diagrama de Objetos

Este diagrama está amplamente associado ao Diagrama de Classes
(detalhado mais adiante). Ele consiste em uma variação do Diagrama de Classes,
em que, em vez de classes, são representadas instâncias e ligações entre instâncias.
Na verdade, para Guedes (2014), o Diagrama de Objetos é praticamente um
complemento do Diagrama de Classes, sendo bastante dependente desse. Este
diagrama fornece uma visão dos valores armazenados pelos objetos das classes
contidas em um Diagrama de Classes em um determinado momento da execução
de um processo. Em outras palavras, ele modela as instâncias das classes contidas
no Diagrama de Classes, isto é, o Diagrama de Objetos mostra um conjunto de
objetos e seus relacionamentos no tempo. Esses diagramas são importantes para
construir os aspectos estáticos do sistema. Normalmente, são compostos por:
objetos e vínculos.
Para facilitar o entendimento, a figura abaixo mostra um Diagrama de

Objetos para o cliente Silva e seus dois pedidos na COMPRAS & COMPRAS.
Podemos ler o diagrama como:
• O objeto Silva da classe Cliente está associado aos objetos 991 e 774,
ambos da classe Pedido.
131
FIGURA 39 - DIAGRAMA DE OBJETOS
FONTE: A autora
2.1.2 Diagrama de Estrutura Composta

De acordo com Guedes (2014), este diagrama é utilizado para modelar
colaborações. Uma colaboração descreve uma visão de um conjunto de entidades
cooperativas interpretadas por instâncias que contribuem entre si para executar
uma função específica. O termo estrutura desse diagrama refere-se a uma
composição de elementos interconectados, representando instâncias de tempo
de execução que colaboram, por meio de vínculos de comunicação, para atingir
algum objetivo comum. Esse diagrama também pode ser utilizado para definir a
estrutura interna de um classificador.
FIGURA 40 - EXEMPLO DO DIAGRAMA DE ESTRUTURA COMPOSTA
FONTE: Guedes (2014, p. 21)
132
Para entender um pouco melhor, vamos analisar o modelo sugerido pela

IBM. Como a figura ilustra, um Diagrama de Estrutura Composta é exibido
no editor de diagrama como uma estrutura que tem o nome do classificador
contido (Car). As peças de material composto do classificador e suas conexões
de comunicação são exibidas na estrutura do diagrama.
FIGURA 41 - EXEMPLO DO DIAGRAMA DE ESTRUTURA COMPOSTA
A estrutura de diagrama apresenta quatro peças de material composto

internas do classificador contido, que representam as quatro rodas do carro e
são do tipo Roda. Um link de comunicação conecta as rodas dianteiras e as rodas
traseiras com conectores denominados frontaxle e rearaxle. Ou seja, sempre que
você cria um Diagrama de Estrutura Composta a partir do classificador Carro,
quatro instâncias da classe Roda são criadas. Essas peças são mantidas pela
composição dentro da instância Carro e as rodas dianteiras e as rodas traseiras
são vinculadas por conectores. Ainda segundo a IBM, os seguintes tópicos
descrevem elementos de modelo em diagramas da estrutura composta:
Peças: Em diagramas da estrutura composta, uma peça é um elemento

de diagrama que representa um conjunto de uma ou mais instâncias que um
classificador estruturado contido possui. Uma peça descreve a função de uma
instância em um classificador. Você pode criar peças no compartimento de
estrutura de um classificador e em vários diagramas UML, como estrutura
composta, classe, objeto, componente, implementação e diagramas de pacote.
Portas: Em diagramas da estrutura composta, uma porta define o ponto

de interação entre uma instância do classificador e seu ambiente ou entre o
comportamento do classificador e suas peças internas.
Colaborações: Nos diagramas UML, uma colaboração é um tipo de

classificador estruturado no qual as funções e atributos cooperam para definir
a estrutura interna de um classificador. Você utiliza uma colaboração quando
133
deseja definir apenas as funções e conexões que são requeridas para executar um
objetivo específico da colaboração. Por exemplo, o objetivo de uma colaboração
pode ser definir as funções ou os componentes de um classificador. Ao isolar
as funções principais, uma colaboração simplifica a estrutura e esclarece o
comportamento em um modelo.
Usos de Colaboração: Nos diagramas da estrutura composta, um uso

de colaboração é um elemento de modelo que representa um uso de uma
colaboração para explicar os relacionamentos entre as partes de um classificador
estruturado. Você utiliza um uso de colaboração para aplicar um padrão, que é
descrito por uma colaboração, para uma situação específica que envolve classes
ou instâncias que desempenham as funções de colaboração especificadas.
Você pode ter vários usos de colaboração, cada uma envolvendo um conjunto
diferente de funções e conectores para uma colaboração determinada.
Conectores em Classificadores Estruturados: Em diagramas UML, um

conector é uma linha que representa um relacionamento em um modelo. Ao
modelar a estrutura interna de um classificador, você pode utilizar um conector
para indicar um link entre duas ou mais instâncias de uma peça ou porta. O
conector define o relacionamento entre os objetos ou instâncias que são ligadas
a funções no mesmo classificador estruturado e identifica a comunicação entre
essas funções. O produto especifica automaticamente o tipo de conector a ser
criado.
FONTE:Disponível em:<http://www.ibm.com/support/knowledgecenter/SS5JSH_9.1.1/com.ibm.
xtools.modeler.doc/topics/ccompstruc.html?lang=pt-br>. Acesso em: 30 mar. 2016.
2.1.3 Diagrama de Classes

Considerado um dos diagramas mais importantes da UML e um dos mais
utilizados, ele serve de apoio para a maioria dos outros diagramas. Como o próprio
nome já diz, define a estrutura das classes utilizadas pelo sistema, determinando
os atributos e métodos que cada classe tem, além de estabelecer como as classes se
relacionam e trocam informações entre si. (GUEDES 2011, p. 31).
TURO S
ESTUDOS FU
Devido à sua importância, o detalharemos um pouco mais no tópico 4.
134
2.1.4 Diagrama de Pacotes

Tem por objetivo representar os subsistemas englobados por um sistema
de forma a determinar as partes que o compõem. Pode ser utilizado associado com
outros diagramas ou de maneira independente. Ele pode ser utilizado também
para ajudar a demonstrar a arquitetura de uma linguagem, como ocorre com a
própria UML.
Segundo Fowler apud Franco (2014), um pacote é um elemento de

agrupamento que permite que você organize suas classes. Interfaces e componentes
em unidades de alto nível. Na UML cada classe é um membro de um único pacote,
que obriga a organização dessas em pacotes e subpacotes de forma hierárquica.
Por exemplo, se você estiver modelando um sistema distribuído com

centenas de classes e que será desenvolvido por equipes diferentes, existe a
possibilidade de essas equipes acabarem criando classes com o mesmo nome.
Outro objetivo é organizar as classes de acordo com sua responsabilidade, o que
auxilia a organizar e estruturar o trabalho de desenvolvimento (FRANCO, 2014).
FIGURA 42 - DIAGRAMA DE PACOTES
135
2.2 DIAGRAMAS COMPORTAMENTAIS
2.2.1 Diagramas de atividade

Esse diagrama era considerado um caso especial do antigo Diagrama de
Gráfico de Estados, mas, a partir da UML 2.0, se tornou independente, deixando
inclusive de se basear em máquinas de estados e passando a se basear em Redes
de Petri, segundo Guedes (2014). Ele se preocupa em descrever os passos a serem
percorridos para a conclusão de uma atividade específica, muitas vezes representada
por um método ou algoritmo com um certo grau de complexidade, podendo, no
entanto, modelar um processo completo. Concentra-se na representação do fluxo
de controle e no fluxo de objeto de uma atividade.
FIGURA 43 - DIAGRAMAS DE ATIVIDADES
136
2.2.2 Diagramas de Caso de Uso

Guedes (2014) afirma que este é o diagrama mais geral e informal da UML,
sendo utilizado especialmente para auxiliar no levantamento e na análise dos
requisitos, em que são determinadas as necessidades do usuário, e na compreensão
do sistema como um todo, embora venha a ser consultado durante todo o processo
de modelagem e possa servir de base para a maioria dos outros diagramas.
Esse diagrama utiliza uma linguagem simples e de fácil compreensão, para

que os usuários possam ter uma ideia geral de como o sistema irá se comportar. Ele
procura identificar os atores (usuários, outros softwares que interajam com o sistema
ou até mesmo algum hardware especial), que utilizarão de alguma forma o software,
bem como as funcionalidades, ou seja, as opções que o sistema disponibilizará aos
atores, conhecidas nesse diagrama como Casos de Uso.
TURO S
ESTUDOS FU
Devido à importância desse diagrama, o tópico 3 o detalhará um pouco mais a

fundo e o exemplificará.
137
FIGURA 44 - EXEMPLO DE CASO DE USO
2.2.3 Diagrama de Transição de Estados

Esse diagrama procura modelar os estados de uma instância de uma classe
ou os estados de um processo representado por um Caso de Uso. Embora possa ser
usado de forma independente, esse diagrama pode se basear em um Caso de Uso
e se apoiar no Diagrama de Classes.
138
FIGURA 45 - DIAGRAMA DE TRANSIÇÕES DE ESTADOS
2.3 DIAGRAMAS DE INTERAÇÃO
2.3.1 Diagrama de Sequência

Preocupa-se com a ordem temporal em que as mensagens são trocadas
entre os objetos envolvidos em um determinado processo. Em geral, baseia-se em
um Caso de Uso definido pelo diagrama de mesmo nome e apoia-se no Diagrama
de Classes para determinar os objetos das classes envolvidas em um processo,
bem como os métodos disparados entre esses. Ele costuma identificar o evento
gerador do processo modelado, bem como o ator responsável por esse evento, e
determina como o processo deve se desenrolar e ser concluído por meio do envio
de mensagens que em geral disparam métodos entre os objetos (GUEDES, 2014).
TURO S
ESTUDOS FU
Por ser um diagrama muito utilizado, detalharemos ele um pouco mais no tópico 5.
139
2.3.2 Diagrama de Temporização

Esse diagrama somente passou a existir a partir da versão 2.0 da linguagem.
Também conhecido como Diagrama de Tempo, descreve a mudança no estado ou
na condição de uma instância de uma classe ou seu papel durante um tempo.
É tipicamente utilizado para demonstrar a mudança no estado de um objeto no
tempo em resposta a eventos externos.
FIGURA 46 - EXEMPLO DE DIAGRAMA DE TEMPORIZAÇÃO
2.3.3 Diagrama de Comunicação

O Diagrama de Comunicação era conhecido, de acordo com Guedes
(2014), como Diagrama de Colaboração até a versão 1.5 da UML, tendo seu
nome modificado para Diagrama de Comunicação a partir da versão 2.0. Esse
diagrama está amplamente associado ao Diagrama de Sequência; na verdade, um
complementa o outro. As informações mostradas no Diagrama de Comunicação
são, com frequência, praticamente as mesmas apresentadas no Diagrama de
Sequência, porém com um enfoque diferente, visto que esse diagrama não se
preocupa com a temporalidade do processo, concentrando-se em como os objetos
estão vinculados e quais mensagens trocam entre si durante o processo.
140
FIGURA 47 - DIAGRAMA DE COMUNICAÇÃO
2.3.4 Diagrama de Visão Geral de Interação

É uma variação do Diagrama de Atividade que fornece uma visão ampla
dentro de um sistema ou processo de negócio. Esse diagrama passou a existir
somente a partir da UML 2.0. Costuma englobar diversos diagramas de interação,
podendo ser de tipos diferentes, para demonstrar um processo geral (GUEDES,
2014).
141
FIGURA 48 - DIAGRAMA DE VISÃO GERAL DA INTERAÇÃO
2.4 DIAGRAMAS DE IMPLEMENTAÇÃO
2.4.1 Diagrama de Componentes

Está muitas vezes associado à linguagem de programação que será utilizada
para desenvolver o sistema modelado. Esse diagrama representa os componentes
do sistema quando este for implementado em termos de módulos de código-fonte,
bibliotecas, formulários, arquivos de ajuda, módulos executáveis etc., e determina
como esses componentes estarão estruturados e interagirão para que o sistema
funcione de maneira adequada. Este diagrama pode ser utilizado para modelar,
por exemplo, os arquivos de código-fonte de um software, os módulos executáveis
de um sistema ou a estrutura física de um banco de dados (GUEDES, 2014).
142
FIGURA 49 - DIAGRAMA DE COMPONENTES
2.4.2 Diagrama de Implantação

Este diagrama determina as necessidades de hardware do sistema, as
características físicas como servidores, estações, topologias e protocolos de
comunicação, ou seja, todo o aparato físico sobre o qual o sistema deverá ser
executado.
143
FIGURA 50 - DIAGRAMA DE IMPLANTAÇÃO
144
RESUMO DO TÓPICO 2
• Os 13 modelos que compõem a UML.
a) Diagrama de Objetos: Representa uma “fotografia” do sistema em certo

momento. Exibe as ligações formadas entre objetos conforme esses interagem
e os valores dos seus atributos.
b) Diagrama de Estrutura Composta: É utilizado para modelar colaborações

entre interfaces, objetos ou classes. Detalha partes internas (classe ou
componente) que o compõem e como estas se comunicam e colaboram entre
si.
c) Diagrama de Classes: Permite a visualização das classes utilizadas pelo

sistema e como estas se relacionam. Define a estrutura de classes, atributos e
métodos.
d) Diagrama de Pacotes: Demonstra como os elementos do software estão

organizados em pacotes e as respectivas dependências.
e) Diagrama de Atividades: Descreve os passos a serem percorridos para a

conclusão de uma atividade específica.
f) Diagrama de Caso de Uso: Representa as funcionalidades externamente

observáveis do sistema e os elementos externos ao sistema que interagem
com ele.
g) Diagrama de Transição de Estados: Baseia-se no Caso de Uso e apoia-se no

Diagrama de Classes acompanhando os estados por que passa uma instância
de uma classe. Demonstra o comportamento de um elemento através de um
conjunto de transição de estado.
h) Diagrama de Sequência: Preocupa-se com a ordem temporal em que

as mensagens são trocadas entre os objetos envolvidos em um processo.
Representa como o sistema age internamente para que um ator atinja seu
objetivo na realização de um caso de uso.
i) Diagrama de Temporização: Enfoca as mudanças de estado de um objeto

ao longo do tempo, útil para modelagem de sistemas de tempo real.
j) Diagrama de Comunicação: Associado ao Diagrama de Sequência. São as

mesmas informações, porém sem a temporalidade do processo. Concentra-
se em como os objetos estão vinculados e quais mensagens trocam entre si.
145
k) Diagrama de Visão Geral de Interação: É uma variação do Diagrama de
Atividades. Fornece uma visão geral dentro de um sistema ou processo de
negócio em relação ao controle de fluxo.
l) Diagrama de Implantação: Enfoca a questão da organização da arquitetura

física sobre a qual o software irá ser implantado e executado.
m) Diagrama de Componentes: Este diagrama está associado à linguagem

de programação que irão para o desenvolvimento do sistema que está sendo
modelado.
146
AUTOATIVIDADE
1 Quais são os modelos que compõem os diagramas estruturais?
2 Descreva os componentes do Diagrama de implementação.
3 Qual é o diagrama mais geral e informal da UML? Justifique.
147
148
UNIDADE 3
TÓPICO 3
MODELO DE CASO DE USO
1 INTRODUÇÃO
Booch et al. (2000) afirmam que nenhum sistema existe isoladamente. E que
todo sistema interage com atores humanos ou autômatos que utilizam esse sistema
para algum propósito, e esses atores esperam que o sistema se comporte de acordo
com a maneira prevista.
Pode-se dizer que uma das utilizações dos Casos de Uso é sua aplicação
para captar o comportamento pretendido do sistema que está sendo desenvolvido,
sem a preocupação de especificar como esse comportamento será implementado.
Eles fornecem uma maneira de compreensão entre os desenvolvedores, usuário
final e os especialistas do domínio. Além de auxiliar na validação da arquitetura
e para a verificação do sistema durante sua evolução. Vale ressaltar que os
casos de uso especificam o comportamento desejado, não determinando como
esse comportamento será executado, permitindo assim a comunicação entre os
envolvidos.
Para facilitar essa tarefa, Martins (2010, p.12) afirma que o Caso de Uso deve
contemplar um processo de ponto a ponto, incluindo vários passos ou transações,
de modo a produzir um produto ou serviço de valor para o usuário. O Caso de
Uso deve ser composto por um passo ou atividade individual de um processo. Ele
sugere alguns questionamentos para facilitar a tarefa de encontrar os casos de uso:
• Quais são as funções requeridas pelos atores?

• O sistema armazena informações?
• Que atores criam, consultam, atualizam e excluem as informações?
• O sistema notifica atores sobre algum evento ocorrido?
Um Caso de Uso é uma descrição de um conjunto de sequências de ações,

incluindo variantes que um sistema realiza para produzir um resultado observável
do valor de um ator. Um Caso de Uso deve representar um requisito funcional
do sistema. Vamos definir os termos e conceitos de um modelo de caso de uso.
Veremos também os elementos do Diagrama de Caso de Uso:
• Caso de uso
• Atores
• Relacionamentos
• Associação
• Generalização
• Dependência: Extensão e Inclusão
149
2 CASO DE USO
Sua representação é feita por uma elipse. É 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. Ainda segundo Booch et al. (2000),
todo Caso de Uso deve ter um nome que o diferencie dos demais casos de uso.
Normalmente, um caso de uso é definido exibindo apenas seu nome, conforme
mostra a Figura 51:
FIGURA 51 - CASO DE USO
Inserir produto
FONTE: A autora
3 ATORES
Os atores representam papéis desempenhados por usuários ou qualquer
outra entidade externa ao sistema (ex. hardware, outros sistemas). Eles podem
iniciar casos de uso e também podem prover e/ou receber informações dos casos
de uso. (TACLA 2010, p.16).
FIGURA 52 - ATORES
FONTE: A autora
Martins (2010, p.212) sugere algumas perguntas que devem ser feitas para
auxiliar na tarefa de encontrar os atores:
• Quem usa o sistema?
• Quem instala o sistema?
• Quem faz a manutenção dos dados do sistema?
• Que outros sistemas se comunicam com este sistema?
• Que outros sistemas extraem informações deste sistema?
150
TÓPICO 3 | MODELO DE CASO DE USO
4 FLUXO DE EVENTOS
Um Caso de Uso descreve o que um sistema (ou um subsistema, classe ou
interface) faz, mas ele não especifica como isso será feito. Booch (2010) diz que se
pode especificar o comportamento de um Caso de Uso pela descrição do fluxo
de eventos no texto de maneira clara, para que alguém de fora possa entender
facilmente. Durante essa documentação do fluxo de eventos deve-se incluir:
• Quando o caso de uso inicia e termina.

• Quando o caso de uso interage com os atores.
• Quais objetos são transferidos e
• Os fluxos básicos e alternativos.
Segue um exemplo de como documentar um fluxo de eventos:
“Nome do caso de uso”
• Atores:
a) (lista dos atores)
• Fluxo de eventos:
b) Fluxo primário ou básico ou principal (descrição das ações que ocorrem
normalmente)
c) Fluxo secundário ou alternativo (ações que ocorrem em situações
adversas, erros, etc.)
d) Pré-condições: situação necessária para iniciar o caso de uso.
e) Pós-condições: situação após o caso de uso terminar.
NOTA
Acesse um modelo de um template fornecido para uma Especificação de Caso

de Uso, que contém as propriedades de texto do caso de uso. Este documento é usado
com uma ferramenta de gerenciamento de requisitos, como o Rational RequisitePro, para
especificar e marcar os requisitos contidos nas propriedades do caso de uso, e demonstra
detalhadamente como realizar esse processo. Acesse o link: <(http://www.wthreex.com/rup/
webtmpl/templates/req/rup_ucspec.htm#2. Flow of Events)>
151
5 RELACIONAMENTO
Os relacionamentos indicam associações definidas entre os diversos
componentes dos diagramas de Casos de Uso. Os principais componentes a se
relacionar em um diagrama são os atores e os Casos de Uso. O relacionamento
pode acontecer de diversas formas, dependendo da situação. Durante a construção
de um Caso de Uso, os relacionamentos podem envolver dois casos de uso ou
mais, dois atores, ou ainda um ator e um caso de uso. Detalharemos esses eventos
a seguir.
5.1 RELACIONAMENTO ENTRE ATORES

Relações associativas podem conectar atores para representar comunicação
entre eles. A relação pode receber um nome que identifica o conteúdo da mensagem,
documento ou objeto que trafega entre os atores. A Figura 53 apresenta uma
associação entre dois atores, onde o aluno solicitação a impressão do histórico
escolar na secretaria. (TACLA, 2010, p.23).
FIGURA 53 - RELACIONAMENTO ENTRE ATORES
FONTE: A autora
Associação ou comunicação é a mais comum das relações. Pode ser

percebida entre dois atores, sua representação é feita por uma linha sólida,
indicando a comunicação entre as partes.
5.2 ATOR X CASO DE USO

Já na documentação das associações entre atores e casos de uso, estas servem
para indicar se quem dá início à comunicação é o ator ou o Caso de Uso, além de
traçar o fluxo da informação, indicando quem alimenta quem com a informação.
A figura a seguir demonstra essa associação ou comunicação entre o ator e

o caso de uso, e uma exemplificação de um funcionário e a emissão de um relatório.
152
FIGURA 54 - COMUNICAÇÃO ENTRE ATOR E CASO DE USO
FONTE: A autora
FIGURA 55 - EXEMPLO DE COMUNICAÇÃO ENTRE ATOR E CASO DE USO
FONTE: A autora
5.3 INCLUSÃO E EXTENSÃO

O relacionamento de inclusão é utilizado para incluir um comportamento
comum de um caso de uso incluído para um caso de uso base, a fim de suportar a
reutilização do comportamento comum.
Ele indica de uma forma explícita que um caso de uso, em algum momento,
faz uso de outro caso de uso. Franco (2014, p.28) explica essa atividade:
É como se, para evitar repetição, separássemos parte do comportamento

comum em vários casos de uso em um caso de uso distinto, que pode
ser agora simplesmente “incluído” por todos os demais. Analogamente,
é como separar parte de um algoritmo em um método específico para
que todo o resto do programa possa usá-lo simplesmente fazendo uma
chamada. Os casos utilizados na inclusão não podem ser acessados
diretamente pelos atores do sistema.
Será ilustrado o que foi explicado segundo o autor: um exemplo de uma

compra e do pagamento sendo validado com o cartão de crédito.
153
FIGURA 56 - EXEMPLO DE COMPRA COM CASO DE USO
FONTE: Franco (2014, p. 28)
5.4 EXTENSÃO
Já a extensão é quando um Caso de Uso utiliza o comportamento de outro
caso de uso em condições especiais. Com o funcionamento semelhante à inclusão,
a diferença é que a extensão do comportamento é opcional e ocorre nos chamados
pontos de extensão. Como no exemplo apresentado por Franco (2014), observa-se
um caso de uso chamado Calcular total da compra e é estendido pelo caso de uso
Calcular desconto. A condição para que o desconto seja calculado é que a compra
ultrapasse 10.000,00, ou seja, o calcular desconto só será estendido se, e somente se,
o valor atender à regra. Como apresenta a Figura 57.
FIGURA 57 - EXEMPLO DE EXTENSÃO
FONTE: Franco (2014, p. 29)
Abaixo temos um exemplo de Melo (2006, p.51), onde encontramos os

extends e include em um mesmo modelo. Começaremos apresentando o cenário e a
resolução do caso de uso e o diagrama de classe.
Cenário: Dra. Janete é pediatra e tem três consultórios em bairros

distintos, onde atende em horários diferentes. Ana, sua secretária, trabalha nos
três consultórios. Para que a marcação de consultas seja centralizada, Ana tem
que carregar as três agendas de um lado para outro. Dra. Janete contratou um
analista free-lancer para lhe desenvolver um sistema que controle a marcação
de consultas e a ficha dos pacientes. Para os pacientes é preciso controlar:
nome, endereço, telefones de contato, data de nascimento, data da primeira
consulta, e-mail, se é particular ou conveniado a plano de saúde. No caso de
ser conveniado, registrar qual é o plano de saúde. Para cada plano de saúde
credenciado é preciso controlar o limite de consultas no mês, por paciente.
154
Dra. Janete atende no consultório da Ilha às segundas e sextas, de 9h

às 18h. Na Tijuca, ela atende às terças e quartas de 10h às 18h. Na quinta, ela
atende em Bonsucesso, de 10h às 18h. O intervalo das consultas é de 30 minutos.
O horário de almoço é sempre de 12h30min às 13h30min. Só são permitidos
três encaixes por dia. Para clientes novos, Ana anota o nome do cliente e o seu
telefone. É preciso identificar se uma consulta é de revisão, como, por exemplo,
para entrega de exames. Nesse caso, ela não é cobrada. A marcação de consultas
deve considerar uma data futura limite.
FIGURA 58 - EXEMPLO COM EXTENDS E INCLUDE
FONTE: Adaptado de Melo (2006, p. 52)
Comentários sobre a resolução: segundo Melo (2006), o caso de uso

Manter Agenda é responsável por verificar e exibir a agenda de um consultório
numa determinada data. A partir daí, para cada horário vago é possível marcar
uma consulta (Extends Caso de Uso Registrar Consulta). Suponha que o usuário
queira ver a agenda do dia 30/09/2005. O sistema verificará que dia 30/09 é uma
sexta (dia da semana = 6). Para o dia da semana 6, a agenda é do consultório da
Ilha. Considerando os atributos desse objeto, o sistema monta a agenda do dia.
Inicia com o horário da primeira consulta (9h). Depois monta um horário a cada
intervalo de consulta (30 minutos) até o limite do horário de almoço (12h30min).
Algo assim: 9h/ 09h30min /10h /10h30min /11h /11h30 min /12h. O horário
da tarde recomeça no fim da hora de almoço (13h:30). A partir daí, continua-se a
montar horários respeitando o intervalo de consulta (30 minutos) até o horário
limite da última consulta.
A agenda completa ficaria assim: 09h / 09h30min /10h /10h30min /11h

/11h30min /12h/13h30min /14h /14h30min /15h / 15h30min /16h /16h30min /17h
/17h30min.
155
6 GENERALIZAÇÃO
Uma generalização de casos de uso é um relacionamento de um Caso de
Uso filho com um Caso de Uso pai, especificando como um filho pode adotar todo
o comportamento e as características descritas para o pai.
Um Caso de Uso pai pode ser especializado em um ou mais casos de

uso filho que representam formas mais específicas do pai. Nem o pai, nem o
filho, são necessariamente abstratos, embora o pai seja abstrato na maioria dos
casos. Um filho herda a estrutura, o comportamento e os relacionamentos do
pai. Todos os filhos do mesmo pai são especializações do pai. Essa é a maneira
que a generalização se aplica aos Casos de Uso.
A generalização é usada quando você encontra dois ou mais casos de

uso que têm comportamento, estrutura e finalidade comuns. Quando isso
ocorre, você pode descrever as partes compartilhadas em um caso de uso novo,
geralmente abstrato, que é especializado pelos casos de uso filho.
FIGURA 59 - GENERALIZAÇÃO
FONTE: Disponível em: <http://www.wthreex.com/rup/process/modguide/md_ucgen.

htm>. Acesso em: 31 mar. 2016.
Bezerra (2015) resume as possibilidades de existência de relacionamentos

entre os elementos do modelo de caso de uso na tabela a seguir:
156
TABELA 9 - POSSIBILIDADES DE EXISTÊNCIA DE RELACIONAMENTOS
Comunicação Extensão Inclusão Generalização

Caso de uso e caso
X X X
de uso
Ator e ator X
Caso de uso e ator X
FONTE: Adaptado de Bezerra (2015, p. 67)
Para reforçar o entendimento, vejamos o caso de uso proposto por Guedes

(2011, p. 67), onde um cliente se dirige ao banco e solicita ao funcionário o
encerramento da sua conta. Como sabemos, uma conta, para ser encerrada, precisa
ter seu saldo zerado. Este caso de uso representa a funcionalidade de Encerrar
Conta utilizada pelo funcionário, que pode eventualmente fazer a chamada do
caso de uso Realizar Saque, caso tenha saldo, e caso o saldo seja negativo, deve
Realizar Depósito para zerar a conta.
FIGURA 60 - EXEMPLO DE CASO DE USO ENCERRAR CONTA
157
RESUMO DO TÓPICO 3
• Um caso de uso é uma descrição de um conjunto de sequências de ações,

incluindo variantes que um sistema realiza para produzir um resultado
observável do valor de um ator.
• Um caso de uso deve representar um requisito funcional do sistema, e ele é

composto por:
a) Casos de uso.
b) Atores.
c) Relacionamentos.
d) Associação.
e) Generalização.
f) Dependência: Extensão e Inclusão.
158
AUTOATIVIDADE
Desenvolva o Diagrama de Caso de Uso para um sistema de controle de cinema,

onde:
• Um cinema pode ter muitas salas, sendo necessário, portanto, registrar

informações a respeito de cada uma, como sua capacidade, ou seja, o número
de assentos disponíveis.
• O cinema apresenta muitos filmes. Um filme tem informações como título e

duração. Assim, sempre que um filme for apresentado, deve-se registrá-lo
também.
• Um mesmo filme pode ser apresentado em diferentes salas e em horários

diferentes. Cada apresentação em uma determinada sala e horário é chamada
Sessão. Um filme sendo apresentado em uma sessão tem um conjunto
máximo de ingressos, determinado pela capacidade da sala.
• Os clientes do cinema podem comprar ou não ingressos para assistir a uma

sessão. O funcionário deve intermediar a compra de ingresso. Um ingresso
deve conter informações como o tipo de ingresso (meio ingresso ou ingresso
inteiro). Além disso, um cliente só pode comprar ingressos para sessões
ainda não encerradas.
159
160
UNIDADE 3
TÓPICO 4
DIAGRAMA DE CLASSE
1 INTRODUÇÃO
Considerado um dos diagramas mais importantes da UML e um dos mais
utilizados, ele serve de apoio para a maioria dos outros diagramas. Como o próprio
nome diz, o Diagrama de Classes define a estrutura das classes utilizadas pelo
sistema, determinando os atributos e métodos possuídos por cada classe, além de
estabelecer como as classes se relacionam e trocam informações entre si. Apresenta
um modelo de como os dados serão criados no banco de dados.
NOTA
Em um projeto de software orientado a objetos, os diagramas de classe criados

durante os estágios iniciais do projeto contêm classes que normalmente são convertidas em
classes e objetos de software reais quando você grava o código.
2 DIAGRAMAS DE CLASSE
Os Diagramas de Classe são fundamentais para o processo de modelagem
de objetos e modelam a estrutura estática de um sistema. A quantidade de
diagramas utilizados vai depender da complexidade do sistema. Pode-se utilizar
um único diagrama de classe para modelar um sistema inteiro ou vários diagramas
de classe para modelar os componentes de um sistema. Eles são úteis em muitos
estágios do design do sistema. No estágio de análise, um diagrama de classe pode
ajudá-lo a compreender os requisitos do domínio do problema e a identificar seus
componentes.
Durante a fase de execução de um ciclo de desenvolvimento de software

é possível utilizar diagramas de classe para converter os modelos em código e
converter o código em modelos. Você também pode utilizar diagramas de classe
para visualizar, especificar e documentar recursos estruturais nos modelos. Por
exemplo, durante as fases de análise e design do ciclo de desenvolvimento, é
possível criar diagramas de classe para executar as seguintes funções, segundo
IBM:
● Capturar e definir a estrutura das classes e outros classificadores.

● Definir relacionamentos entre classes e classificadores.
161
● Ilustrar a estrutura de um modelo utilizando atributos, operações e

sinais.
● Mostrar as funções e responsabilidades comuns do classificador que
definem o comportamento do sistema.
● Mostrar as classes de implementação em um pacote.
● Mostrar a estrutura e o comportamento de uma ou mais classes.
● Mostrar uma hierarquia de herança entre classes e classificadores.
● Mostrar os trabalhadores e entidades como modelos de objetos de
negócios.
FONTE: Disponível em: <http://www.ibm.com/support/knowledgecenter/SS8PJ7_9.0.0/com.ibm.

xtools.modeler.doc/topics/cclassd.html?lang=pt-br>. Acesso em 30 mar. 2016.
Podemos fazer uma associação entre as classes e o modelo entidade

relacionamento (MER), que é muito utilizado para a modelagem estruturada de
banco de dados.
FIGURA 61 - COMPARAÇÃO ENTRE CLASSES E MER
FONTE: Ferreira (2009, p. 83)
162
TÓPICO 4 | DIAGRAMA DE CLASSE
Para auxiliar o entendimento, e devido à sua importância, apresentaremos

o exemplo a seguir, de Melo (2006, p. 28), referente ao controle de ligações
telefônicas, onde deve-se identificar as classes, atributos e os métodos pertinentes
a esse cenário:
Cenário: Bruna resolveu desenvolver uma aplicação para controlar as

ligações telefônicas de sua casa, a fim de checar se o valor que paga mensalmente
está correto. Assim, sempre que desejar, poderá listar as ligações efetuadas
num determinado período, contabilizando o valor a pagar. Para que isso seja
possível, toda ligação será feita pelo computador. A cada solicitação de ligação,
a aplicação deverá registrar: a data da ligação, a hora da ligação, quantidade
de minutos gastos (que deve ser registrado no momento em que a ligação for
encerrada), o número de pulsos (que deve ser calculado pela aplicação) e o
telefone para onde se discou. A aplicação permitirá o controle de uma agenda
de telefones, com número do telefone e nome da pessoa de contato. O usuário
poderá escolher, no momento da ligação, se deseja um dos registros da agenda
ou se digitará diretamente o número do telefone.
A forma de cálculo dos pulsos considera os seguintes critérios:
• A ligação ao ser completada já conta um pulso. A partir daí, a cada quatro

minutos de conversação concluída, cobra-se mais um pulso.
• Cada pulso custa R$ 0,08 para ligações locais.
• Exemplo:
a) Ligação de 2m -1 pulso
b) Ligação de 4m30s - 2 pulsos
c) Ligação de 8m - 3 pulsos
• Os finais de semana possuem uma promoção. Cada ligação contabiliza somente

um pulso, independentemente do número de minutos de conversação.
A resolução apresentada pode ser feita da maneira definida por Melo

(2006):
163
FIGURA 62 - SOLUÇÃO
FONTE: Melo (2006, p. 28)
A autora faz algumas considerações em relação ao modelo, Melo (2006,

p.30).
a) O relacionamento da classe Ligação com a classe Agenda serve

apenas para manter o controle do lugar para onde foi feita a ligação.
Entretanto, a multiplicidade é de 0..*, pois no momento da ligação o
usuário pode escolher de onde quer obter o telefone, podendo digitar
um número sem querer registrá-lo na agenda. O telefone é replicado na
classe Ligação, para se manter o histórico de ligações, já que o contato
pode ter seu número de telefone alterado.
b) O atributo tempoGasto da classe Ligação é derivado, pois seu valor é
o resultado do método calcularTempo da classe RegraCalculo.
c) O atributo numeroPulsos da classe Ligação é derivado, pois seu valor
é o resultado do método calcularPulsos da classe RegraCalculo.
d) O caso de uso cadastrarPulsos é responsável por solicitar o cálculo do
tempo e baseado nessa informação, calcular o número de pulsos. Como
as informações tempo gasto e número de pulsos não são persistidos,
então o caso de uso Listar ligações de um período precisa fazer utilização
do caso de uso cadastrarPulsos para apresentar o relatório.
e) Como o único usuário dessa aplicação é a Bruna, o ator foi identificado
como Pessoa.
164
DICAS
Para entender um pouco mais sobre esse diagrama, leia o resumo do artigo
disponibilizado no material complementar, e para ler na íntegra acesse o site: Disponível em:
<http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-elaboracao-de-um-
diagrama-de-classes.aspx>. Acesso em: 29 fev. 2016.
ORIENTAÇÕES BÁSICAS NA ELABORAÇÃO DE UM DIAGRAMA DE

CLASSES
por Douglas de Oliveira Tybel
CENÁRIO
Você trabalha para uma empresa de desenvolvimento como analista

de sistemas. O responsável pelo setor em que você trabalha, em uma reunião,
distribuiu tarefas para cada membro da equipe. Sua tarefa foi desenvolver um
Diagrama de Classe para que seja iniciado o desenvolvimento de um novo software.
A empresa que nos contratou deseja adquirir o certificado ISO 9001 em

qualidade, entretanto uma das normas repassadas foi que deve ser obrigatório
controlar os pedidos de suporte/serviço que são feitos pelos clientes.
O ramo da empresa é Serviçe Desk. O fluxo do processo segue abaixo:
O cliente entra em contato com a central através do telefone;
Um atendente tem um prazo curto para registrar esta solicitação, informando

os dados do cliente, o que foi solicitado, o nível de urgência, o grupo de atendimento,
o técnico, um ou mais equipamentos envolvidos na manutenção. Anotar toda a
interação realizada no equipamento, como, por exemplo: Se ele conectar remotamente
ao equipamento, deve informar em um histórico e suponhamos que três segundos
depois ele reinicie o equipamento, deverá informar no histórico também. Resumindo:
Toda interação deve ser anotada no registro com data e hora.
Caso ele consiga resolver o que foi solicitado, o técnico do Service Desk irá
salvar o registro com a situação de “Resolvido” encerrando o caso, contudo, deverá,
em um local específico do registro, definir como ele resolveu o caso, informando
que se tratava de um Incidente, Problema ou Solicitação. O registro deve ser
categorizado, escolhendo dentre três classificações: Categoria >> Subcategoria
>> Item da categoria, onde a categoria é uma lista de tipo de serviço, como, por
exemplo: Se foi Hardware ou Software.
165
A Subcategoria está relacionada com a categoria, pois dependendo

do que foi escolhido na primeira lista será mostrada na segunda que será uma
Subcategoria, como, por exemplo: No caso da escolha de Hardware, seria informado
na Subcategoria algum tipo de peça do equipamento que o técnico interagiu, tipo
DVD/R. No caso de Categoria ser Software, a Subcategoria deveria ser qual software,
tipo: Word, Excel e etc. E no item da categoria deveria ser escolhido o que foi
realizado pelo técnico, no caso de Hardware >> DVD/R, poderia ser SUBSTITUÍDO,
LIMPADO etc. No caso de Software >> Word >> INSTALADO,DESINSTALADO etc.
Caso o técnico do Service Desk não consiga resolver no seu prazo que será
o mais curto, deverá enviar o registro para outro grupo de atendimento, onde
existirão outros técnicos que poderão ir até o equipamento fisicamente para resolver
o problema com um prazo mais extenso. Um grupo é composto por vários técnicos.
No registro deve constar o grupo que atendeu e o técnico, pois cada registro conta
como receita em reais para o grupo sendo apurado ao efetuar fechamento mensal.
O pagamento para os grupos de atendimento é feito por quantidade de registros
atendidos no prazo estipulado.
Se mesmo o grupo de atendimento físico tentar entrar em contato com

o cliente, mas não obtiver sucesso, o técnico poderá deixar o registro agendado.
Para realizar esta tarefa devem ser informadas no registro a data e a hora em que
será retornado o atendimento do chamado e definir a situação do registro para
“Pendente pelo cliente”, definir também a data e hora para o próximo contato.
Esta situação de pendência significa que o técnico não está atendendo por culpa
do cliente e o tempo em que o registro fica nesta situação será debitado ao final do
apuramento, a fim de beneficiar o grupo que o atende, pois cada grupo tem um
tempo para atender os registros e se ultrapassar este prazo recebe multa em cima
do valor do chamado.
Ao final, caso o pedido tenha sido designado para outro grupo, ou esteja
em andamento, pendente, cancelado ou resolvido, deve-se informar em um campo
específico o que foi feito neste registro resumidamente. Se a situação do registro
estiver definida como “Resolvido”, uma pesquisa de satisfação deverá ser enviada
para o solicitante.
IDENTIFICAR OS OBJETOS TANGÍVEIS
Para identificarmos um objeto, precisamos antes entender como vê-lo, para

isso basta ter como regra que: O objeto é algo tangível, que podemos percebê-lo
à nossa frente, sendo possível encontrá-lo no mundo real ou virtual. Exemplos de
objetos que podemos perceber ao ir a uma lanchonete: Mesa, Cadeira, Atendente,
Lanche, Bebida e etc.
Vamos tentar encontrar os objetos do nosso cenário, observe o primeiro

item abaixo:
O cliente entra em contato com a central através do telefone;
166
Nesta frase acima, podemos identificar como objetos: Cliente e Telefone.
Cliente é considerado um objeto, pois é tangível e existem vários outros

iguais a ele com as mesmas características, assim como o telefone.
No segundo item do cenário identificamos:
• Atendente.
• Solicitação.
• Grupo.
• Técnico.
• Equipamento.
• Histórico.
O único item acima que gera dúvida se é ou não um objeto seria histórico,
pois não é normal vermos este objeto, entretanto ele existe, veja o exemplo deste
objeto no mundo real: Na escola existe o histórico escolar ou na clínica existe
histórico médico e etc.
No terceiro item do cenário identificamos: Categoria, Subcategoria e Item

da categoria.
Observe que estes objetos acima são difíceis de identificarmos no mundo

real, mas preste atenção no cenário de uma locadora de DVD. Veja que as placas
com o gênero dos filmes são categorias, aquelas placas são objetos tangíveis
representando categorias, que já seria sua classe-mãe.
Os itens quatro e cinco do cenário estão apenas explicando o processo, não

identificamos nenhum objeto novo. No sexto e último item do cenário identificamos
os seguintes objetos: Pedido e Pesquisa de satisfação.
IDENTIFICAR OS OBJETOS POR SEUS ATRIBUTOS
Após identificarmos os objetos que estavam visíveis no cenário, agora

teremos que encontrá-los através de seus atributos, onde os atributos são
características do objeto. Suponhamos que no cenário acima foi falado sobre algum
objeto, contudo não foi pronunciado seu nome, dificultando assim sua localização.
Para encontrarmos teremos que identificar atributos ou características, como,
por exemplo: se no cenário dado acima tivéssemos o atributo CPF, poderíamos
identificar que esta característica pertence ao cliente, identificando assim o objeto
Cliente sem que seu nome houvesse sido pronunciado no cenário.
Você deve repassar todo cenário novamente em busca destas características

sem objetos, abaixo seguem alguns que identifiquei:
• Data.
• Hora.
• Situação.
167
• Tipo de Serviço.
• Prazo.
Observe que os atributos Data, Hora, Situação, Tipo de Serviço e Prazo

são referentes ao pedido, sendo assim, para identificarmos novas classes a partir
desses atributos, teremos que realizar a seguinte pergunta para cada um deles:
“Eu preciso uma lista de: Atributo?”, onde no lugar de Atributo você substitui por
atributos acima.
Veja os testes abaixo:
Eu preciso uma lista de Data? = Não

Eu preciso uma lista de Hora? = Não
Eu preciso uma lista de Situação? = Sim
Eu preciso de uma lista de Tipo de Serviço? = Sim
Eu preciso uma lista de Prazos? = Sim
As perguntas com resposta Sim serão novas classes, seguem abaixo as

novas classes encontradas: Situações, Tipo de Serviços e Prazos.
LISTA COMPLETA COM TODOS OS OBJETOS ENCONTRADOS
Listaremos abaixo, para facilitar nossa visualização, todos os objetos

encontrados após nossa abstração:
• Cliente.
• Telefone.
• Atendente.
• Solicitação.
• Grupo.
• Técnico.
• Equipamento.
• Histórico.
• Categoria.
• Subcategoria.
• Item da categoria.
• Pedido.
• Pesquisa satisfação.
• Situações.
• Tipo de Serviços.
• Prazos.
AGRUPAR OS OBJETOS POR SEMELHANÇA
Nosso próximo passo é agrupar todos os objetos encontrados por

características semelhantes, como, por exemplo: Mesa e Cadeira têm as mesmas
características, sendo classificadas como Móveis. Assim devemos trabalhar os
itens acima:
168
Cliente, Atendente e Técnico = Pessoas

Solicitação, Histórico, Pedido e Pesquisa de Satisfação = Documentos
Telefone = Equipamentos
Veja que alguns dos objetos acima não foram classificados, devido à não
necessidade de tal processo, pois já está em sua classificação correta, devemos
apenas usar o plural, pois normalmente uma classe está no plural devido sua
origem em agrupar vários objetos.
ELIMINAR CLASSES DESNECESSÁRIAS OU REPETIDAS
Observe no item anterior que muitas classes são do mesmo gênero, fazendo
com que esteja repetida no diagrama, e se uma classe se repete no banco de dados
será uma tabela criada sem propósito nenhum.
Para eliminar, vejamos primeiro as classes que agrupamos por semelhança:
Observe que Pedido e Solicitação no cenário fazem referência a uma mesma

coisa, assim pode-se então eliminar uma das duas, eu eliminei a solicitação. Veja
que Telefone é um item de equipamentos, sendo assim podemos também eliminá-
lo:
Abaixo a nova lista de classes:
• Pessoas.
• Cliente.
• Atendente.
• Grupo.
• Técnico.
• Equipamento.
• Histórico.
• Categoria.
• Subcategoria.
• Item da categoria.
• Pedido.
• Pesquisa satisfação.
• Situações.
• Tipo de Serviços.
• Prazos
MONTANDO O DIAGRAMA DE CLASSE
Para iniciarmos os primeiros passos de nosso diagrama de classe, desenhe

em uma folha de papel um retângulo com três divisões para cada classe. Veja
abaixo, na figura, como deve ficar:
169
DIAGRAMA DE CLASSE SEM LIGAÇÕES E CARDINALIDADE

Pessoas
-codPessoa
-Pessoa
Clientes Atendentes Técnicos Grupos
-codPessoa -codPessoa -codPessoa -codGrupo

-numCliente -numAtendente -numTecnico -codFuncionario
+setCadastrar()
+getConsultar()
Pedidos
Categorias
-codOrdem
-codDoc -codCategoria
-codCliente -categoria
-codFuncionario
-codGrupo
-codTipo
-codCategoria Sub_Categorias
-codsubCategoria -codCategoria
-coditem -subCategoria
Itens_da_Categoria
Documentos -codItem
-item
Tipos de Serviços -codDoc
-documento
-codTipo
Situação Histórico_de_Atendimento
Equipamentos
-codHistorico
-codSituação
-codDoc -codEquipamento
-situação
REALIZANDO AS PRIMEIRAS LIGAÇÕES
Para efetuarmos a primeira ligação, faremos com os objetos que agrupamos

por características semelhantes, como, por exemplo: Clientes, Atendentes e
Técnicos se relacionam com pessoas, seguem abaixo as ligações:
170
PARTE DO DIAGRAMA DE CLASSE ENVOLVENDO PESSOAS
Pessoas
-codPessoa
-Pessoa
Clientes Atendentes Técnicos

-codPessoa -codPessoa -codPessoa
-numCliente -numAtendente -numTecnico
+setCadastrar()
+getConsultar()
PARTE DO DIAGRAMA DE CLASSE ENVOLVENDO DOCUMENTOS
Pedidos
-codOrdem
-codDoc
-codCliente
-codFuncionario
-codGrupo
-codTipo
-codCategoria
-codsubCategoria
-codItem
Documentos
-codDoc
-documento
EFETUANDO AS LIGAÇÕES ENTRE AS CLASSES
Este ponto é trabalhoso, pois devemos testar classe por classe em busca de
ligações, veja abaixo como realizar esta tarefa:
Sabemos que o cliente entra em contato com o atendente que gera um

pedido. Com esta informação observamos que um pedido foi gerado da interação
entre cliente e atendente, onde um cliente pode solicitar vários pedidos para um
atendente e um atendente atende a vários clientes. Sua cardinalidade será N para
N, onde N quer dizer muitos, sendo: Muitos para Muitos. Quando ocorre esse tipo
171
de cardinalidade, nasce uma nova tabela ou classe, entre esses dois foi a classe
pedidos, que já havíamos identificado antes. O importante sobre a N para N é
que a classe que nasceu recebe os códigos da classe com que fez relação, ficando a
classe “Pedido” com o código do cliente e o código da atendente.
Sabemos também que esse pedido será repassado para um técnico que o
atenderá, sendo assim, um técnico pode atender a vários pedidos e um pedido
pode ser atendido por um técnico, sendo representado por 1-N, lembrando que a
classe que recebe o N herda o campo-chave da outra classe como chave estrangeira,
sendo assim ficará a tabela de pedidos com mais um campo chamado: código do
técnico.
Faça o processo para todas as classes, use sempre a pergunta dessa forma:
Um “Nome de um objeto da classe” pode “nome da ligação (verbo)” um ou

vários “nomes da classe”.
Como ficaria entre Pedidos e situação:
Um pedido pode ter uma ou várias situações?
Resposta: Várias, pois ao abrir está em andamento, em outro ponto do

tempo pode ficar pendente e ser concluída ao final do serviço.
172
DIAGRAMA DE CLASSE COMPLETO

Pessoas
-codPessoa
-Pessoa
Clientes Atendentes Técnicos

-codPessoa -codPessoa -codPessoa
-numCliente -NumAtendente -numTecnico Grupos
+setCadastrar() -codGrupo
+getConsultar() -codFuncionario
Equipamentos Pedidos
-codEquipamento -codOrdem
-codDoc
-codCliente Categorias
-codFuncionario -codCategoria
Pedido_Equipamentos -codGrupo
-categoria
-codTipo
-codPedido -codCategoria
-codEquipamento -codsubCategoria
-codItem Sub_Categorias
-codCategoria
-subCategoria
Itens_da_Categoria
Tipos de Serviços
-codItem
-codTipo
-Item
Histório_de_Atendimento
-codHistórico
-codDoc
Pedido_Situações
-codSituação
-codOrdem Situações
-tempoNaSituação
-codSituação
-situação
FONTE: Disponível em: <http://www.linhadecodigo.com.br/artigo/3219/orientacoes-basicas-na-

elaboracao-de-um-diagrama-de-classes.aspx>. Acesso em: 29 fev. 2016.
173
RESUMO DO TÓPICO 4
• A importância do Diagrama de Classes na modelagem de sistema.
• A associação entre as classes e o modelo entidade relacionamento (MER), que é

muito utilizado para a modelagem estruturada de banco de dados.
• Um estudo de caso onde você pôde reforçar a aprendizagem.
174
AUTOATIVIDADE
Agora que você já desenvolveu o Caso de Uso, faça o Diagrama de Classe,

continuaremos com o mesmo estudo de caso para um sistema de controle de
cinema.


também.


175
176
UNIDADE 3
TÓPICO 5
DIAGRAMA DE SEQUÊNCIA
1 INTRODUÇÃO
Eles detalham a sequência de um processo, representando os atores e
objetos envolvidos em um cenário e qual é a sequência de troca de mensagens ao
longo do tempo. Ele é baseado em Diagrama de Caso de Uso e ordena como as
mensagens são trocadas entre os objetos de forma temporal.
A notação para uma mensagem em um Diagrama de Sequência é uma flecha

(geralmente desenhada na horizontal) ligando uma linha de vida a outra. O objeto
do qual parte a seta é aquele que está enviando a mensagem (objeto remetente). O
objeto para o qual a seta aponta é aquele que está recebendo a mensagem (objeto
receptor). O formato da ponta da seta indica o tipo de mensagem sendo enviada
(síncrona ou assíncrona). O rótulo da mensagem é posicionado acima dessa seta.
Esse diagrama permite identificar os métodos e atributos de cada classe,

assim como as responsabilidades de cada classe na realização de um caso de uso.
Os elementos básicos desse Diagrama são (TACLA, 2010, pg. 36):
• Atores: São entidades externas que interagem com o sistema e que

solicitam serviços. Normalmente, o ator primário é o responsável por
enviar a mensagem inicial que inicia a interação entre os objetos.
• Objetos: Representam as instâncias das classes representadas no
processo.
• Linha do tempo (uma para cada objeto e ator): As linhas de vida
compõem a dimensão vertical. Uma linha de vida é composta de duas
partes, a cabeça e a cauda. A cabeça é representada por um retângulo
com dois compartimentos, no compartimento superior a identificação
do objeto é exibida e no compartimento inferior (cuja utilização é
opcional) aparecem valores para os atributos definidos na classe do
objeto. A cauda corresponde a uma linha vertical tracejada.
• Comunicação entre ator e objeto ou entre objetos
• Interpretação das mensagens: por exemplo, evento do sistema
operacional ou de uma interface, envio de mensagem ou chamada de
método.
2 TIPOS DE MENSAGEM
As mensagens são parte importante do Diagrama de Sequência, e elas
podem ser identificadas de várias formas, sendo as mais comuns (TACLA, 2010,
p.44):
177
• Simples: quando o tipo de mensagem é irrelevante ou ainda não foi

definido.
• Síncrona: quando enviada, o emissor fica bloqueado aguardando a
resposta.
• Assíncrona: o emissor não bloqueia até que o receptor envie resposta
para continuar seu processamento.
• Retorno ou resposta: resposta à mensagem síncrona; pode ser omitida.
2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
FIGURA 63 – NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA
FONTE: Disponível em: <http://www.dmo.fee.unicamp.br/henrique/cursoc++/

diagrama.pdf>. Acesso em: 10 out. 2015.
Neste exemplo apresentado por Guedes (2011, p. 204) enfocamos o início

do processo de encerramento de conta de um sistema bancário, onde o cliente
solicita ao funcionário o encerramento de uma conta.
Após a solicitação do cliente ao funcionário para o encerramento, o

funcionário verifica o saldo.
Vale ressaltar que para encerrar uma conta é necessário antes verificar o
saldo dessa. Para que seja depositado o valor, caso o saldo seja negativo, ou sacado
caso esteja com saldo positivo.
NOTA
Neste passo devemos imaginar que o processo de Emitir Saldo já está modelado, e
por esse motivo, só faremos sua chamada. A esse processo damos o nome de Usos de interação.
178
TÓPICO 5 | DIAGRAMA DE SEQUÊNCIA
FIGURA 64 - ENCERRAR CONTA
Neste outro modelo proposto por Guedes (2014), temos o diagrama para
a realização de depósito. Onde o cliente informa ao funcionário (neste caso, o ator
funcionário poderia ser um caixa eletrônico) o número da conta que deverá receber
o valor a ser depositado. O funcionário, em resposta, faz a verificação se a conta
existe através da interface do sistema, esta repassará ao controlador o número da
conta que, em resposta, disparará o método consultar_conta. Caso a resposta seja
positiva, o funcionário solicitará ao cliente o valor a ser depositado. O funcionário
então informará à interface do sistema a quantidade do valor a depositar. Esse
valor será repassado ao controlador, que disparará o método depositar_valor. Se a
operação for realizada com sucesso, o controlador pedirá à interface que apresente
uma mensagem informando que a operação foi concluída.
Além desse processo, o sistema deverá registar também o movimento

realizado sobre a conta em questão, e para isso ele faz referência ao processo de
Registrar Movimento.
FIGURA 65 - EXEMPLO DE DIAGRAMA DE SEQUÊNCIA
179
Outro exemplo se baseia no caso de uso Enviar Carta. Onde alguém remete
uma carta para outro país através de uma agência de correio. Primeiro, a carta é
enviada para o país do destinatário. No país, a carta é enviada para uma cidade
específica. A cidade, por sua vez, envia a carta para a residência do destinatário.
FIGURA 66 - EXEMPLO DE DIAGRAMA DE SEQUÊNCIA
FONTE: Disponível em: <http://www.wthreex.com/rup/portugues/process/modguide/

md_seqdm.htm ->. Acesso em: 29 fev. 2016.
DICAS
Veja o artigo na íntegra sobre o comparativo ergonômico de três ferramentas

de modelagem em UML. Disponível em: <http://www.atenas.edu.br/faculdade/arquivos/
NucleoIniciacaoCiencia/REVISTAS/REVIST2011/4.pdf>. Acesso em: 01 mar. 2016.
AVALIAÇÃO DE INTERFACES DE FERRAMENTAS CASE PARA

ELABORAÇÃO DE DIAGRAMAS DA UML
RESUMO: Um dos benefícios oferecidos pelas ferramentas CASE é orientar

e disciplinar o processo de modelagem durante da fase de desenvolvimento do
projeto de um software. Porém, muitas vezes a ferramenta não é totalmente explorada
do ponto de vista funcional, fundamentalmente pela relativa complexidade do
assunto e mesmo por problemas de interfaces. Desta forma, o artigo visa analisar,
através de heurísticas de usabilidade, a interface de algumas ferramentas CASE
180
que são utilizadas para elaboração dos diagramas da UML, buscando verificar a
contribuição desse aspecto na área de computação.
2.1 FERRAMENTAS CASE
As ferramentas CASE são utilizadas para apoiar a realização de atividades

específicas, tais como planejamento e análise e especificação de requisitos
(PRESSMAN, 2002). Apesar dos benefícios do uso de ferramentas CASE individuais,
atualmente, o número e a variedade de ferramentas têm crescido a tal ponto que
levou os engenheiros de software a pensarem não apenas em automatizar os seus
processos, mas sim em trabalhar com diversas ferramentas que interajam entre si e
forneçam suporte a todo ciclo de vida do desenvolvimento. As seções que seguem
apresentam três ferramentas CASE que são utilizadas na elaboração de diagramas
da UML
2.1.1 ArgoUML
Segundo Monteiro (2004), a ArgoUML é uma ferramenta CASE baseada

na notação UML, que foi desenvolvida pela comunidade de desenvolvedores de
código livre Tigris. Ele roda na maior parte das plataformas por ser implementado
em Java. De acordo com Vieira (2004), a ferramenta ArgoUML é uma das
principais ferramentas open source de modelagem UML e inclui suporte para todos
os seguintes diagramas da UML: Diagrama de Classe, Diagrama de Estados,
Diagrama de Atividades, Diagrama de Caso de Uso, Diagramas de Colaboração,
Diagrama de Utilização/Componentes e Diagrama de Sequência. Segundo a revista
Java Magazine (2006), o grande diferencial do ArgoUML em relação a outras
ferramentas CASE são os recursos cognitivos embutidos no produto. Em vez de ser
apenas um diagramador, documentador e gerador de código, o ArgoUML procura
orientar e auxiliar o desenvolvedor na construção dos modelos. Esta ajuda provém
de várias regras que são aplicadas continuamente, verificando inconsistências,
erros comuns e sugerindo próximos passos.
2.1.2 JUDE
O JUDE é uma ferramenta IDE de desenvolvimento e modelagem de dados

(UML), criada sobre a linguagem Java e de uso fácil e intuitivo. Com o JUDE é
possível realizar uma modelagem de dados complexa, apresentando os dados para
o usuário de clara e objetiva. Após feita toda a modelagem é possível exportar tudo
para um arquivo Java, HTML ou exportar cada diagrama em forma de imagem.
Segundo o site da Jude (2011), o JUDE/Community é uma ferramenta

de modelagem UML gratuita com funcionalidades básicas. Ele é rico em
funcionalidade, oferecendo características como edição e impressão de diagramas
UML 2.0, importa/exporta código-fonte Java, saída de gráficos e disposição
automática. Ainda de acordo com o site da Jude (2011), os diagramas padrão da
UML 1.4 e UML 2.0 que o JUDE/Community trabalha são: Diagrama de Classes,
Diagrama de Caso de Uso, Diagrama de Estados, Diagrama de Atividades,
181
Diagrama de Sequência, Diagrama de Comunicação, Diagrama de Componentes e

Diagrama de Estruturas Compostas.
Além de aprimoramentos adicionais, o JUDE/Profissional, segundo o site da

Jude (2011), é uma ferramenta para projetar sistemas com todas as funcionalidades
do JUDE/Community. É aprimorado para o desenvolvimento em negócios, grandes
modelos e criação de documentos. Ele provê diagramas UML 2.0 e diagramas
adicionais, funcionalidade de impressão melhorada, habilidade de fazer merge
com outros projetos JUDE, especificações de caso de uso, input-output de modelos
de/para arquivos XML, funções de copiar e colar copy em formato de vetor (EMF), e
exportação de informações do projeto em formato CSV. O site Jude (2011) ainda diz
que os diagramas padrão da UML 1.4 e UML 2.0 que o JUDE/Profissional trabalha
são: Diagrama de Classes, Diagrama de Caso de Uso, Diagrama de Estados,
Diagrama de Atividades, Diagrama de Sequência, Diagrama de Comunicação,
Diagrama de Componentes, Diagrama de Implantação e Diagrama de Estruturas
Compostas.
2.1.3 Microsoft Visio
O Microsoft Visio é um aplicativo gráfico e de desenho, que simplifica o

processo de criação de diagramas e gestão de processo. É possível utilizar o
Visio para transformar textos e tabelas complicadas e de difícil entendimento
em diagramas que comunicam rapidamente as informações. São dezenas de
ferramentas e templates prontos para serem utilizados.
O Visio fornece formas e modelos modernos para um conjunto diverso de

necessidades de criação de diagramas, incluindo gerenciamento de TI, modelagem
de processos, construção e arquitetura, design de interface do usuário, gestão de
recursos humanos, gerenciamento de projetos e muito mais, podendo ser utilizado
conjuntamente com o SharePoint para compartilhamento de seus diagramas com
pessoas da mesma empresa.
Segundo o site Microsoft Office (2011), o Microsoft Visio fornece formas

de inteligência predefinidas que representam os elementos na notação UML e
oferecem suporte para a criação dos seguintes tipos de diagramas UML: Diagramas
de Casos, Diagramas de Estruturas Estáticas, Diagramas de Pacote, Diagramas de
Atividade, Diagramas de Gráfico de Estado, Diagramas de Sequência, Diagrama
de Colaboração, Diagramas de Componentes e Diagramas de Implantação.
2.2 A IMPORTÂNCIA DA INTERAÇÃO HUMANO-COMPUTADOR E

SUAS TÉCNICAS DE AVALIAÇÃO
Segundo a norma ISO 9241, usabilidade é a “capacidade que um sistema

interativo oferece a seu usuário, em um determinado contexto de operação, para
a realização de tarefas de maneira eficaz, eficiente e agradável”. Já segundo a
norma ISO/IEC 9126, usabilidade é a “facilidade com que um usuário pode
aprender a operar, preparar entradas para e interpretar as saídas de um sistema
ou componente”. Simplificando, podemos dizer que a usabilidade está associada
182
a uma característica de qualidade de software que se refere à sua adequação à

utilização pelos usuários. A usabilidade trata da qualidade da interação usuário-
computador proporcionada pela interface de um sistema de computação. É
importante salientar que a usabilidade está sempre associada a um contexto de
utilização do produto; a adequação ao uso significa adequação ao tipo de tarefas ou
atividades que se pretende realizar com o produto de software, ao tipo de usuários
que tipicamente utilizam o produto e ao ambiente de utilização do produto.
Segundo Zambalde e Alves (2004), o cuidadoso estudo da comunidade de

usuários e do conjunto de tarefas deve considerar cinco fatores imprescindíveis
que são os principais objetivos do design de interface com o usuário:
a) produtividade do usuário: a interface deve permitir bom desempenho

do usuário na realização de suas tarefas. Não se está falando de desempenho do
software, que é um atributo de qualidade utilizado na engenharia de software, mas
do desempenho do usuário em sua interação com um sistema de software;
b) facilidade de aprendizado: deve ser fácil para o usuário aprender a

utilizar o software;
c) retenção do aprendizado com uso intermitente: a interface deve permitir

que o usuário (esporádico) consiga utilizar o software adequadamente mesmo
quando fica sem usá-lo por um período relativamente longo de tempo;
d) prevenção de erros do usuário: o sistema deve prevenir erros do usuário

quando o utiliza em suas atividades. Cabe observar aqui também que não se está
falando de erros no programa, mas sim de erros do usuário ao utilizar o sistema;
e) satisfação subjetiva: o usuário deve gostar de utilizar o sistema. Observem

que a satisfação é um aspecto subjetivo, pessoal, mas ainda assim importante e que
deve ser buscado no desenvolvimento de um produto de software.
A avaliação de interface é um passo muito importante no processo de design

de software interativo. Nesse sentido, segundo Rocha e Baranauskas (2000), os
testes de usabilidade têm o objetivo de medir quantitativamente o valor alcançado
pela interação com o sistema em cada um dos fatores de usabilidade de interesse.
Tais testes são classificados em: I) métodos de inspeção; e II) testes empíricos
com usuários. Um dos métodos de inspeção é a avaliação heurística, ou seja, a
avaliação de alguns princípios reconhecidos de usabilidade. Nielsen (1993) propõe
um conjunto de heurísticas que, dispostas em uma tabela, permite, a adequada
inspeção de usabilidade de uma interface.
3 METODOLOGIA
Uma das preocupações básicas dos pesquisadores relacionada com as

questões metodológicas de suas pesquisas é a reflexão sobre as características
específicas dos procedimentos adequados para a realização da pesquisa proposta.
Sendo assim, nesse trabalho foi elaborada pelos autores uma tabela, adaptada de
183
Nielsen (1993) (Tabela 1) para análise de algumas ferramentas CASE utilizadas

na elaboração de diagramas da UML. Para cada heurística devem ser informados
os problemas relacionados e a nota do avaliador entre 0 (RUIM) e 10 (ÓTIMO). A
interação do usuário com o sistema foi avaliada de acordo com tais heurísticas,
permite assim obter um escore em porcentagem (10 heurísticas, cada uma com
pontuação máxima 10) e, por conseguinte, a avaliação da interface, a qual será
considerada satisfatória acima de 80%, razoável entre 79% a 50% e insatisfatória
abaixo de 49%. A avaliação foi realizada por pesquisadores da área de Sistemas de
Informação no mês de agosto de 2011.
1 AVALIAÇÃO DAS FERRAMENTAS CASE
Nesta seção apresenta-se a avaliação da interface de algumas ferramentas

CASE utilizadas na elaboração de Diagramas da UML, realizada pelos autores do
trabalho, com base nas heurísticas da Tabela 1. A saber:
Ferramenta ArgoUML:
• Ao escolher o tipo de diagrama, aparece o estado do sistema no alto da tela

dando ao usuário uma facilidade maior ao criar os diagramas. Isso é importante,
pois cada diagrama usa ferramentas diferentes.
184
• Há uma boa interação com o usuário, já que os botões são bem intuitivos e
também há o uso de dicas (tooltips) para auxiliar as funções dos botões. O menu
é bem completo e fácil de ser usado.
• O controle e liberdade do usuário é relativamente bom, pois pode criar e apagar,

porém, deveria ter a função desfazer (undo) e a opção colar e copiar, que ficou a
desejar.
• A ferramenta é bem consistente, possuindo uma organização entre as áreas da

tela. Ao fechar o programa ou abrir outra aplicação pronta, o sistema pergunta
se deseja salvar o trabalho atual, dando maior segurança e evitando perdas. Se
há alguma ação que não pode ser executada, a ferramenta não executa tal ação.
Por exemplo, se tentar inserir um <<extend>> ou <<include>> entre dois atores,
a ferramenta não aceita tal comando e não executa.
• O menu está em português de fácil utilização. Os botões estão bem ilustrados e

organizados de maneira que o usuário, mesmo sendo a primeira vez ao usar a
ferramenta, não deverá ter grandes problemas ao criar os diagramas.
• Os diagramas podem ser salvos na pasta a critério do usuário, podendo der

editados a qualquer momento sem nenhuma complicação ou restrição.
• O sistema possui uma boa interface, com desenhos bem simples de entender. E
como possui o “tooltips”, dicas dos botões, se torna mais fácil o uso da ferramenta.
• Não há mensagens de erro ao criar os diagramas. Por exemplo, posso colocar um

<<extend>> e um <<include>> na mesma relação do caso de uso que ele aceita.
• A ajuda é bem completa, porém está no idioma inglês, assim como o site oficial
do sistema, que também está em inglês.
Ferramenta Jude:
• O JUDE não possui um apelo gráfico tão bom quanto o ArgoUML, ou tantas
funcionalidades como Microsoft Visio;
• O sistema não interfere nas ações do usuário.
• Existem somente versões em inglês do sistema, porém a sua interface é amigável.
• Existe em seus menus a opção “Help”, um menu de ajuda que se encontra em

inglês.
• A ferramenta Jude Community suporta apenas diagramas da UML 1.4 e UML 2.0.
185
• Existe pré-requisito para a ferramenta ser executada, ter o JRE instalado em seu
computador.
• A interface do sistema, além de ser amigável, é intuitiva, facilitando o seu uso.
Ferramenta Microsoft Visio:
• Os diagramas da UML são fáceis de serem localizados na ferramenta.
• Em momento algum o sistema informa das ações que o usuário está fazendo se
estão certas ou erradas, sendo assim, o usuário tem total liberdade de trabalhar.
• Existe uma versão da ferramenta em português, facilitando assim o entendimento

de todas as funções.
• A ferramenta apresenta um menu de ajuda e um tutorial para facilitar o

entendimento de todas as funções.
• Comando desfazer (undo) limitado - número de movimentos limitado.
• Quando um componente de um diagrama é deslocado, as setas de relacionamentos

entre eles possuem um acompanhamento automático, evitando erros.
• Os estereótipos, que denotam o relacionamento representado pela seta, não

podem ser arrastados separadamente - estão “presos” à seta.
• A ferramenta não possui todos os diagramas da UML.
• Em algumas situações a barra de ferramentas não possui todos os elementos

necessários para construir do diagrama.
• A interface da ferramenta é muito simples de ser utilizada, sendo assim o usuário

não fica perdido na localização de alguma funcionalidade.
5 COMPARAÇÃO ENTRE AS FERRAMENTAS
A Tabela 2 apresenta uma comparação entre as ferramentas estudadas em

relação aos aspectos mais relevantes segundo heurísticas de usabilidade abordadas
neste trabalho.
186
CONCLUSÃO
Este trabalho teve por objetivo fazer uma identificação e comparação de

ferramentas CASE com suporte à elaboração de diagramas da UML, visando
avaliar a usabilidade das ferramentas. Os resultados obtidos permitem identificar
as ferramentas Microsoft Visio, com 83 pontos e ArgoUML com 84 pontos, como
alcançadora dos resultados satisfatórios, uma vez que atende aos critérios propostos
por Nielsen (1993) e às pontuações propostas pelos organizadores. Entretanto, a
ferramenta Jude, com 78 pontos, foi classificada como razoável, conforme problemas
apresentados na seção de avaliação. Na linha de raciocínio, a preocupação com a
interface deve ser uma constante, tanto durante o desenvolvimento de produtos de
software – para os desenvolvedores – quanto durante a escolha de uma ferramenta
CASE que possa auxiliar as atividades de desenvolvimento. O presente trabalho
valeu-se de um estudo exploratório sobre usabilidade em ferramentas CASE
voltadas para a elaboração de diagramas da UML.
FONTE: Disponível em: <http://www.atenas.edu.br/faculdade/arquivos/NucleoIniciacaoCiencia/
REVISTAS/REVIST2011/4.pdf>. Acesso em: 01 mar. 2016.
187
RESUMO DO TÓPICO 5
• Os elementos básicos:
a) Atores: São entidades externas que interagem com o sistema e que solicitam
serviços. Normalmente, o ator primário é o responsável por enviar a
mensagem inicial que inicia a interação entre os objetos.
b) Objetos: Representam as instâncias das classes representadas no processo.
c) Linha do tempo (uma para cada objeto e ator): As linhas de vida compõem a
dimensão vertical.
d) Comunicação entre ator e objeto ou entre objetos.
e) Interpretação das mensagens: por exemplo, evento do sistema operacional

ou de uma interface, envio de mensagem ou chamada de método.
• Apresentamos um estudo de caso onde você pôde reforçar a aprendizagem.
188
AUTOATIVIDADE
Com base no estudo da sala de cinema, continuaremos nossos exercícios, agora

desenvolva o Diagrama de Sequência:


também.


189
REFERÊNCIAS
AZEVEDO, S. Por que os projetos falham? Disponível em: http://www.mundopm.
com.br/noticia.jsp?id=280>. Acesso em: 22 mar. 2016.
BEZERRA, E. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Elsevier, 2015.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Rio de Janeiro:
Elsevier, 2000.
BROOKS, F. P. The Mythical Man-Month: Essays on Software Engineering.

Reading, MA: Addison-Wesley, 1975.
DIAS, N. K. B; ARAÚJO, M. A P. Boas práticas na engenharia de requisitos.

Disponível em: <https://www.assembla.com/spaces/procsw/documents/
bI66qA44Gr34-CeJe5cbLr/download/bI66qA44Gr34-CeJe5cbLr >. Acesso em: 07
fev. 2016.
ENGHOLM JUNIOR, H. Engenharia de software na prática. São Paulo: Novatec

Editora, 2010.
FRANCO, C. R; PERINI, L. C; FABRIS, P. P. G. Modelagem de Sistemas

Empresariais. Londrina: Editora e Distribuidora Educacional S.A., 2014.
GUEDES, G. T. A. UML2 Guia prático. São Paulo: Editora Novatec, 2014.
GUEDES, G.T.A. UML2 - Uma abordagem prática. 2. ed. São Paulo: Editora
Novatec, 2011.
MACÊDO, A. B. L.; SPÍNOLA R. Ciclos De Vida Do Software. Disponível

em:<http://www.devmedia.com.br/ciclos-de-vida-do-software-artigo-revista-
engenharia-de-software-magazine-36/21099>. Acesso em: 22 mar. 2016.
MARTINS, J. C. C. Gerenciando projetos de desenvolvimento de software com

PMI, RUP e UML (colaboração de Fabricio Ramirez) 5. ed. Rio de Janeiro: Brasport,
2010.
MELO, A. C. Exercitando modelagem em UML. Rio de janeiro: Brasport, 2006.

PAGES-JONES, M. Fundamentos do desenho orientado a objetos. São Paulo:
Makron Books, 2001.
MERIAT, V. Charge da Semana: Como ser um Arquiteto de Software. Disponível

em: <http://www.vitormeriat.com.br/category/charges/>. Acesso em: 22 mar. 2016.
190
MORAES, J. B. D. Engenharia de Software 2: técnicas para levantamento de
Requisitos. Disponível em: <http://www.devmedia.com.br/articles/viewcomp.
asp?comp=9151 >. Acesso em: 22 mar. 2016.
PMI- PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em

Gerenciamento de Projetos (Guia PMBOK®) 5.ed. Newtown Square: Project
Management Institute, 2013.
PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed.

Porto Alegre: AMGH, 2011.
REZENDE, D. A. Engenharia de Software Empresarial. Rio de Janeiro: Brasport,

1997.
SCRUM. Disponível em: < http://www.scrumguides.org/docs/scrumguide/v1/

Scrum-Guide-Portuguese-BR.pdf >. Acesso em: 07 fev. 2016.
SILVA, N. P. Análise de Sistemas de Informação: conceitos, modelagem e

aplicações. São Paulo: Érica, 2014.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice

Hall, 2011.
STEFFEN, J. B. Scrum: basicamente scrum. Disponível em: <https://www.

ibm.com/developerworks/community/blogs/rationalbrasil/entry/scrum_
basicamente14?lang=en>. Acesso em: 11 abr. 2016.
TACLA, C. A. ANÁLISE E PROJETO OO E UML 2.0. Apostila: Departamento

Acadêmico de Informática. Universidade Federal Tecnológica do Paraná, 2010.
TAVARES, A. P. A importância da arquitetura de software. Disponível em: <http://

www.institutopangea.org/blog/15-a-importancia-da-arquitetura-de-software>.
VIANA, M. Conheça o Rational Unified Process (RUP). Disponível em: <http://

www.linhadecodigo.com.br/artigo/79/conheca-o-rational-unified-process-rup.
aspx#ixzz3ySiX8GyR >. Acesso em: 07 fev. 2016.
191

Odelagem de Istemas Mpresariais: Prof. Neli Miglioli Sabadin

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

Odelagem de Istemas Mpresariais: Prof. Neli Miglioli Sabadin

Enviado por

Direitos autorais:

Formatos disponíveis

Modelagem de Sistemas

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

Bem-vindo à disciplina de Modelagem de Sistemas Empresariais.

Vale lembrar que um dos assuntos mais relevantes da modelagem

Conheceremos na primeira unidade os modelos de processo de

Aproveito a oportunidade para destacar a importância de desenvolver

Bom estudo! Sucesso na sua trajetória acadêmica e profissional!

Neli Miglioli Sabadin

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

TÓPICO 1 - MODELOS DE CICLO DE VIDA................................................................................... 3

TÓPICO 2 - INTRODUÇÃO A MODELAGEM ESTRUTURADA E

TÓPICO 3 - MÉTODO DE DESENVOLVIMENTO ÁGIL............................................................... 29

TÓPICO 1 - ENGENHARIA DE REQUISITOS.................................................................................. 65

TÓPICO 2 - DESCOBERTA DE REQUISITOS................................................................................... 91

TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE.................................................... 101

UNIDADE 3 - REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO

TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS

TÓPICO 3 - MODELO DE CASO DE USO......................................................................................... 149

TÓPICO 4 - DIAGRAMA DE CLASSE................................................................................................ 161

TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA....................................................................................... 177

INTRODUÇÃO AOS MODELOS

• introdução aos conceitos de ciclo de vida;

• modelagem orientada e estruturada;

• conhecimento dos modelos ágeis de desenvolvimento.

TOPICO 1 – MODELOS DE CICLO DE VIDA

TÓPICO 2 – INTRODUÇÃO À MODELAGEM ESTRUTURADA E

TÓPICO 3 – METÓDO DE DESENVOLVIMENTO ÁGIL

Existe um encadeamento específico dessas fases, para a construção

Cada fase do desenvolvimento de software é definida. Além das suas

O modelo de Ciclo de Vida é a primeira escolha a ser feita no processo de

Os ciclos de vida se comportam de maneira sequencial (fases seguem

Não existe uma regra, a escolha de um modelo de processo depende muito

2 MODELOS DE PROCESSOS PRESCRITIVOS OU

2.1 MODELO EM CASCATA

FIGURA 1 - MODELO EM CASCATA

FONTE: Disponível em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessa- NEMO/

Os principais estágios do Modelo em Cascata refletem diretamente as

No capítulo 2- Detalharemos os tipos de requisitos e técnicas de levantamento

1. Análise e definição de requisitos: Os serviços, restrições e metas

5. Operação e manutenção: Normalmente (embora não necessariamente),

Existe uma variação do Modelo em Cascata que é chamado de modelo V.

Pressman (2011) explica que à medida que a equipe de software desce em

FONTE: Adaptado de Pressman (2011, p. 60)

O Modelo em Cascata é o modelo mais antigo na engenharia de software, e

• Projetos reais raramente seguem o fluxo sequencial que o modelo

2.1.1 Modelo Incremental

Pressman (2011) diz que o Modelo Incremental combina elementos dos

FIGURA 3 - MODELO INCREMENTAL

FONTE: Pressman (2011, p. 54)

O princípio fundamental desse modelo é que, seja iteração ou ciclo, uma

2.1.2 Modelos de processo evolucionário

2.1.3 Modelo Espiral

A dimensão radial representa o custo acumulado atualizado e a dimensão

FIGURA 4 - MODELO ESPIRAL

FONTE: Pressman (2011, p. 65)

Na fase de comunicação, faz-se uma reunião com os envolvidos para

Durante a fase de modelagem do projeto rápido: se concentra em uma

FONTE: Pressman (2011, p. 63)

Sommerville (2011, p. 31) alerta que, às vezes, os desenvolvedores são

1. Pode ser impossível ajustar o protótipo para atender aos requisitos