Engenharia de Software: José de Sousa Magalhães

Engenharia de
Software
JOSÉ DE SOUSA MAGALHÃES
Editora
ENGENHARIA DE
SOFTWARE
JOSÉ DE SOUSA MAGALHÃES
Editora:
Editora
1º EDIÇÃO - 2021 | SÃO PAULO/ SP

ENGENHARIA DE SOFTWARE
EXPEDIENTE
COORDENAÇÃO GERAL COORDENAÇÃO DE

REVISÃO ORTOGRÁFICA
Nelson Boni
Esthela Malacrida
AUTOR(ES) COORDENAÇÃO,
PROJETO GRÁFICO E CAPA
José de Sousa Magalhães
João Guedes
1º EDIÇÃO - 2021 | SÃO PAULO/ SP
Ficha Catalográfica/ ISBN
CATALOGAÇÃO ELABORADA POR GLAUCY DOS SANTOS SILVA - CRB8/6353
Editora
Apresentação
Prezado aluno,
A
engenharia de software é o processo de analisar as
necessidades do usuário e, em seguida, projetar,
construir e testar aplicativos de usuário final que
satisfaçam essas necessidades através do uso de linguagens
de programação de software.
O termo desenvolvimento de software pode ser usado
para cada tipo de desenvolvimento de software, seja tão
simples quanto o básico visual para aplicativos Módulos
para Microsoft Word, Excel ou Access ou desenvolvendo
aplicativos grandes, caros e complicados para empresas ou
criando software para entretenimento de jogos.
Além disso, um engenheiro de software é aquele que
acompanha um processo sistemático que leva à compre-
ensão dos requisitos, trabalhando com equipes e diversos
profissionais a fim de criar o software de aplicativo ou com-
ponentes ou módulos que satisfazem as necessidades espe-
cíficas dos usuários com sucesso; que um programador de
computador pode trabalhar de forma independente, pois
ele entende algoritmos e sabe como criar códigos seguindo
as especificações dadas pelos engenheiros de software.
Desta forma, esta obra tem por objetivo apresentar os
conceitos teóricos e técnicos relacionados ao desenvolvi-
mento de softwares, passando pelo processo organizacio-
nal, humano e programável.
Para tanto, faremos isso apresentando os um pouco so-
bre a história do desenvolvimento de software, técnicas já
usadas e atuais, além de apresentar um exemplo simples
e prático de desenvolvimento de um sistema voltado para
área da saúde, onde são necessários seguir alguns passos
apresentados nesta obra.
Bons estudos!

SUMÁRIO:
UNIDADE 1:
ENGENHARIA DE SOFTWARE E PROCESSO DE SOFTWARE��1-1
CAPÍTULO 1:
CONCEITOS BÁSICOS DE ENGENHARIA DE SOFTWARE�� 1-2
EXERCÍCIOS PROPOSTOS�� 1-10
CAPÍTULO 2:
PROCESSO DE DESENVOLVIMENTO DE SOFTWARE�� 2-1
UNIDADE 2:
PRODUTO DE TRABALHO E ARQUITETURA DE SOFTWARE��3-1
CAPÍTULO 3:
PRODUTO DE TRABALHO E DISCIPLINA DE COMPROMISSO�� 3-2
CAPÍTULO 4:
ARQUITETURA DE SOFTWARE�� 4-1
UNIDADE 3:
GERENCIAMENTO DE REQUISITOS E CONFIGURAÇÃO��5-1
CAPÍTULO 5:
GERENCIAMENTO DE REQUISITOS�� 5-2
CAPÍTULO 6:
GERENCIAMENTO DE CONFIGURAÇÃO�� 6-1
UNIDADE 4:
GERENCIAMENTO DE PROJETO E PLANEJAMENTO��7-1
CAPÍTULO 7:
GERENCIA DE PROJETOS�� 7-2
CAPÍTULO 8:
ORGANIZAÇÃO DA EQUIPE�� 8-1
UNIDADE 5:
TESTES E DESCRIÇÃO CMMI��9-1
CAPÍTULO 9:
TESTE�� 9-2
CAPÍTULO 10:
CMMI�� 10-1
UNIDADE 6:
METODOLOGIAS ÁGEIS E EXEMPLO PRÁTICO�� 11-1
CAPÍTULO 11:
METODOLOGIAS ÁGEIS�� 11-2
CAPÍTULO 12:
EXEMPLO PRÁTICO DE PROJETO DE SISTEMA DE SOFTWARE�� 12-1
REFERÊNCIAS�� 13-1
GABARITO�� 14-1
DISCIPLINA:
Engenharia de
Software
UNIDADE 1:
ENGENHARIA DE SOFTWARE E
PROCESSO DE SOFTWARE
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta primeira unidade, daremos orientações acerca dos fundamen-

tos iniciais de engenharia e processo de software, bem como sua rele-
vância para construção de aplicações.
Conteúdos da Unidade:
Nesta unidade, iremos conhecer um pouco sobre os conceitos básicos
de desenvolvimento de software, entender o que de fato é um programa
de computador e outras nuanças do processo; por fim, veremos algu-
mas definições sobre melhoria nos processos de software.
9 Conceitos básicos de Engenharia de Software
9 Processo de Desenvolvimento de Software
Acompanhe os conteúdos desta unidade. Se preferir, vá assinalando
os assuntos, à medida que for estudando.
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 1:
CONCEITOS BÁSICOS DE
ENGENHARIA DE SOFTWARE
Engenharia de Software 1
CONCEITO S B Á S IC O S D E EN G EN H A R IA D E SO FT WARE
1.1 FUNDAMENTOS
Como a programação é diferente de um programa de enge-
nharia? Nesse sentido, a primeira é algum tipo de atividade abstra-
ta e pode ocorrer em muitos contextos diferentes. Você pode pro-
gramar para se divertir, para aprender (por exemplo, na sala de
aula, em seminários na universidade), você pode programar
no âmbito do desenvolvimento científico. E você pode fazer pro-
gramação industrial. Via de regra, isso acontece em equipe, e com
certeza - para um cliente que paga pelo trabalho. Ao mesmo tempo,
é necessário entender exatamente o que o cliente precisa para con-
cluir o trabalho no prazo e o resultado deve ser da qualidade dese-
jada - que satisfaça o cliente e pelo qual ele pague. Para atender a
esses requisitos adicionais,a programação “cresce mais” várias
atividades adicionais: desenvolvimento de requisitos, planejamen-
to, teste, gerenciamento de configuração, gerenciamento de proje-
to, criação de várias documentações (design, usuário, etc.).
O desenvolvimento do código do programa é precedido de
análise e design (o primeiro significa a criação de um mode-
lo funcional do futuro sistema sem levar em conta a im-
plementação, para que os programadores entendam os
requisitos e expectativas do cliente; o segundo significa
um layout preliminar, esboço, planta do sistema em pa-
pel). O esforço envolvido na análise e design, bem como a forma
como os resultados são apresentados, variam muito dependendo
do tipo de projeto e das preferências dos desenvolvedores e clientes.
Esforços especiais também são necessários para organizar o
processo de desenvolvimento. Em geral, este é um modelo iterati-
vo-incremental, quando a funcionalidade necessária é criada em
porções que os gestores e o cliente podem avaliar e, portanto, existe
1-3
a possibilidade de gerenciar o andamento do desenvolvimento. No
entanto, este modelo geral tem muitas modificações e variações.
O desenvolvimento do sistema também deve ser realizado le-
vando em consideração a conveniência de sua posterior manuten-
ção, reutilização e integração com outros sistemas. Isso significa
que o sistema é dividido em componentes fáceis de desenvolver,
reutilizar e integrar. E também com as características de desempe-
nho necessárias. Para esses componentes, as interfaces são cuida-
dosamente projetadas. O próprio sistema é documentado em vá-
rios níveis, regras para o design do código do programa são criadas
- isto é, vários traços semânticos são deixados que ajudam a criar
e manter, manter uma arquitetura única e harmoniosa, estilo uni-
forme, ordem ...
Todas essas e outras atividades adicionais realizadas no pro-
cesso de programação industrial e necessárias ao sucesso da exe-
cução dos pedidos serão denominadas engenharia de software 1.
Acontece que é assim que designamos, em primeiro lugar, alguma
atividade prática e, em segundo lugar, uma área especial do co-
nhecimento. Ou em outras palavras, uma disciplina científica. Na
verdade, para facilitar a implementação de cada projeto individual,
ser capaz de usar uma variedade de experiências positivas alcança-
das por outras equipes e desenvolvedores, essa mesma experiência
está sujeita à compreensão, generalização e design adequado. É
assim que vários métodos e práticas (melhores práticas) apa-
recem - teste, design, trabalho em requisitos, etc., padrões de ar-
quitetura, etc. Bem como padrões e metodologias relativos a todo
o processo como um todo (por exemplo, MSF, RUP, CMMI,
Scrum). São essas generalizações que estão incluídas na engenha-
ria de software como um campo do conhecimento.
1-4
A necessidade da engenharia de software como área espe-
cializada do conhecimento foi reconhecida pela comunidade mun-
dial no final da década de 60 do século passado, mais de 20 anos
após o nascimento da própria programação, se considerarmos o
famoso relatório de von Neumann “First Draft de Relatório sobre
o EDVAC”, por ele promulgado em 1945. O nascimento da enge-
nharia de software é 1968 - a conferência OTAN de Engenharia de
Software, Garmisch (Alemanha), que foi inteiramente dedicada
à consideração dessas questões. A área de engenharia de softwa-
re cobre todas as questões e tópicos relacionados à organização e
melhoria do processo de desenvolvimento de software, a gestão da
equipe de desenvolvimento, o desenvolvimento e implementação
de ferramentas de software para apoiar o ciclo de vida de desen-
volvimento de software. A engenharia de software usa avanços
na ciência da computação, está intimamente relacionada à enge-
nharia de sistemas, frequentemente precedido por reengenharia
de negócios. Um pouco mais de detalhes sobre esse contexto de
engenharia de software.
Ciência da Computação (ciência da computação) é uma
coleção de ciências teóricas baseada na matemática e dedicada aos
fundamentos formais da computabilidade. Isso inclui lógica mate-
mática, teoria gramatical, métodos de construção do compilador,
métodos matemáticos formais usados na verificação e teste de mo-
delo, etc. É difícil separar estritamente a engenharia de software
da ciência da computação, mas em geral o foco dessas disciplinas
é diferente. A engenharia de software visa resolver problemas de
produção, a ciência da computação visa desenvolver abordagens
formais e matematizadas de programação.
Engenharia de sistemas (engenharia de sistema) combi-
na várias disciplinas de engenharia para o desenvolvimento de to-
dos os tipos de sistemas artificiais - usinas de energia, sistemas de
1-5
telecomunicações, sistemas embarcados em tempo real, etc. Mui-
tas vezes, o software passa a fazer parte de tais sistemas, desempe-
nhando a tarefa de controlar o equipamento correspondente. Esses
sistemas são chamados de software e hardware e, ao participarem
de sua criação, os programadores são forçados a compreender pro-
fundamente os recursos do hardware correspondente.
Reengenharia de negócios (reengenharia de negócios) -
em um sentido amplo, significa a modernização dos negócios em
uma determinada empresa, a introdução de novas práticas supor-
tadas por novos sistemas de informação apropriados. Ao mesmo
tempo, a ênfase pode ser tanto na reestruturação interna da empre-
sa quanto no desenvolvimento de um novo serviço de atendimen-
to ao cliente (via de regra, essas questões estão inter-rela-
cionadas). A reengenharia de negócios muitas vezes precede o
desenvolvimento e implementação de sistemas de informação em
uma empresa, uma vez que é necessário primeiro estabelecer uma
certa ordem no trabalho de escritório, e só então consolidá-la com
um sistema de informação.
1.2 Softwares
Definição: Entendamos por software (software) um con-
junto de prescrições lógicas que evoluem no tempo, com a ajuda das
quais um determinado grupo de pessoas controla e utiliza um siste-
ma multiprocessador e distribuído de dispositivos computacionais.
Esta definição, dada por Harald Mills, um renomado enge-
nheiro de software da IBM, é a seguinte.
1. As prescrições lógicas não são apenas os próprios progra-

mas, mas também várias documentações (por exemplo,
1-6
sobre o funcionamento dos programas) e, mais
amplamente, um certo sistema de relações entre as pes-
soas que utilizam esses programas no quadro de um de-
terminado processo de atividade.
2. O software moderno é projetado, via de regra, para fun-
cionar simultaneamente com muitos usuários, que po-
dem ser significativamente removidos uns dos outros no
espaço físico. Assim, o ambiente computacional (com-
putadores pessoais, servidores, etc.) em que o sof-
tware opera é distribuído.
3. As tarefas resolvidas por softwares modernos muitas ve-
zes requerem diferentes recursos computacionais devi-
do às diferentes especializações dessas tarefas, devido à
grande quantidade de trabalho executado, bem como por
razões de segurança. Por exemplo, aparece um servidor
de banco de dados, um servidor de aplicação, etc.
4. O software se desenvolve ao longo do tempo: er-
ros são corrigidos, novas funções são adicionadas, novas
versões são lançadas, sua base de hardware muda.
Propriedades: Assim, o software é um sistema dinâmico

complexo que inclui aspectos técnicos, psicológicos e sociais. O
software difere marcadamente de outros tipos de sistemas cria-
dos (criados) pelo homem - mecânicos, sociais, científicos, etc.,
e possui as seguintes características, destacadas por Frederick
Brooks em seu famoso artigo “Não há bala de prata”.
1. Complexidade objetos de software, o que depende signifi-

cativamente de seu tamanho. Como regra, mais software
(mais usuários, mais dados processados, requi-
sitos de desempenho mais rigorosos, etc.) com
1-7
funcionalidade semelhante é outro software. A ciência
clássica construiu modelos simples de fenômenos com-
plexos, e isso foi bem-sucedido, uma vez que a complexi-
dade não era uma característica dos fenômenos em con-
sideração. (A comparação da programação com a
ciência, e não com teatro, cinema, esportes e ou-
tras áreas da atividade humana, justifica-se, pois
surgiu, principalmente da matemática, e seus
primeiros frutos - computadores, linguagens de
programa - destinavam-se ao uso em cálculos
científicos. Além disso, a maioria dos programa-
dores tem formação científica, matemática ou
técnica. Assim, os paradigmas do pensamento
científico são amplamente utilizados na progra-
mação - explícita ou implicitamente.)
2. Consistência: O software não é baseado em premissas
objetivas (assim como vários sistemas na ciência
clássica são baseados em postulados e axiomas),
mas deve ser consistente com um grande número de in-
terfaces com as quais deve posteriormente interagir. Es-
sas interfaces são difíceis de padronizar porque são base-
adas em várias convenções humanas mal formalizadas.
3. Mutabilidade: O software é fácil de alterar e, como
resultado, os requisitos para ele mudam constantemen-
te durante o processo de desenvolvimento. Isso cria
muitas dificuldades adicionais em seu desenvolvimen-
to e evolução.
4. Intangibilidade: O software não pode ser visto, é virtu-
al. Portanto, por exemplo, é difícil tirar proveito de tecno-
logias baseadas na criação preliminar de desenhos, que
são utilizadas com sucesso em outras áreas industriais
1-8
(por exemplo, na construção, engenharia me-
cânica). Lá, nos desenhos, as formas geométricas dos
objetos que estão sendo criados são reproduzidas de
forma esquemática.
1-9
EXERCÍCIOS PROPOSTOS
1) Como a programação é diferente de um programa de engenharia?
( ) -a) Nesse sentido, a primeira é nenhum tipo de atividade abstra-

ta e pode não pode ocorrer em muitos contextos diferentes.
( ) -b) Nesse sentido, a primeira é algum tipo de atividade abstrata
e pode ocorrer em muitos contextos diferentes.
( ) -c) Você não pode programar para se divertir.
( ) -d) Você pode não pode programar no âmbito do desenvolvi-
mento científico.
( ) -e) E você não pode fazer programação industrial.
2) Observe as afirmações abaixo:

I) Não é necessário entender exatamente o que o cliente precisa para con-
cluir o trabalho no prazo.
II) Para atender a esses requisitos adicionais, a programação “cresce mais”
várias atividades adicionais: desenvolvimento de requisitos, planejamento,
teste, gerenciamento de configuração, gerenciamento de projeto, criação de
várias documentações design, usuário, etc.
III) O desenvolvimento do código do programa é precedido de análise e
nem de design.
Estão CORRETAS:
( ) -a) I, somente
( ) -b) I e II
( ) -c) III, somente
( ) -d) II, somente
( ) -e) I e III
1-10
3) Sobre O desenvolvimento do código do programa que é precedido de aná-
EX ER C ÍC IO S PR O PO STO S
lise e design é correto afirma que:
( ) -a) O primeiro significa um layout preliminar, esboço, planta

do sistema em papel, o segundo significa a criação de um
modelo funcional do futuro sistema sem levar em conta a
implementação, para que os programadores entendam os
requisitos e expectativas do cliente.
( ) -b) O primeiro significa um layout preliminar, esboço, planta do
sistema em papel, o segundo significa que não a criação de
um modelo funcional do futuro sistema sem levar em conta
a implementação, para que os programadores entendam os
( ) -c) O primeiro significa a criação de um modelo funcional do fu-
turo sistema sem levar em conta a implementação, para que
os programadores entendam os requisitos e expectativas do
cliente, o segundo significa um layout preliminar, esboço,
planta do sistema em papel.
( ) -d) O primeiro significa a criação de um modelo funcional do fu-
turo sistema sem levar em conta a implementação, para que
os programadores entendam os requisitos e expectativas do
cliente, o segundo significa que não há um layout preliminar
ou esboço, planta do sistema em papel.
( ) -e) O primeiro significa uma página preliminar, esboço, planta
do sistema em papel, o segundo significa a criação de um
modelo funcional do futuro sistema sem levar em conta a
implementação, para que os programadores entendam os
4) Sobre O esforço envolvido na análise e design, é correto afirmar que:
( ) -a) São apresentados, variam muito dependendo do tipo de pro-

jeto e das preferências dos desenvolvedores e clientes.
( ) -b) Não são necessários para organizar o processo de
desenvolvimento.
( ) -c) Não depende de tipo de projeto e nem de preferências dos
desenvolvedores e clientes.
( ) -d) São apresentados, mas não variam muito do tipo de projeto
e nem das preferências dos desenvolvedores e clientes.
1-11
( ) -e) Em geral, este é um modelo iterativo-incremental, quando
a funcionalidade necessária não é criada em porções que os
gestores e o cliente podem avaliar e, portanto, existe a possi-
bilidade de gerenciar o andamento do desenvolvimento.
5) Observe as afirmações abaixo.

I) O desenvolvimento do sistema não deve ser realizado levando em consi-
deração a conveniência de sua posterior manutenção, reutilização e integra-
ção com outros sistemas.
II) O sistema é dividido em componentes fáceis de desenvolver, reutilizar e
integrar.
III) O próprio sistema é documentado em vários níveis, regras para o de-
sign do código do programa são criadas.
Estão INCORRETAS:
( ) -a) I e III
( ) -b) II, somente
( ) -c) II e III
( ) -d) III, somente
( ) -e) I, somente
6) Todas as atividades adicionais realizadas no processo de programação

industrial e necessárias ao sucesso da execução dos pedidos serão
denominadas:
( ) -a) Engenharia de software

( ) -b) Engenharia da Computação
( ) -c) Engenharia de Controle e Automação
( ) -d) Engenharia Civil
( ) -e) Engenharia de Produção.
7) Estão incluídas na engenharia de software como um campo do conheci-

mento. Estamos falando de:
( ) -a) MSF
( ) -b) Padrões de arquitetura
1-12
( ) -c) Generalizações
( ) -d) Engenharia da Computação
( ) -e) CMMI
8) Definimos software como:
( ) -a) Um sistema dinâmico complexo que não inclui aspectos téc-

nicos, psicológicos e sociais.
( ) -b) Um conjunto de prescrições lógicas que evoluem no tempo,
com a ajuda das quais um determinado grupo de pessoas
controla e utiliza um sistema multiprocessador e distribuído
de dispositivos computacionais.
( ) -c) Complexidade objetos de software, o que não depende signi-
ficativamente de seu tamanho.
( ) -d) Software se desenvolve ao longo do tempo – erros que não
são corrigidos, novas funções são adicionadas, novas versões
são lançadas, sua base de hardware não muda.
( ) -e) Complexidade objetos de software, o que não depende signi-
9) Definimos Propriedades como:
( ) -a) É um sistema dinâmico complexo que inclui aspectos técni-

cos, psicológicos e sociais.
( ) -b) Complexidade objetos de software, o que não depende signi-
( ) -c) Um conjunto de prescrições lógicas que evoluem no tempo,
com a ajuda das quais um determinado grupo de pessoas
controla e utiliza um sistema multiprocessador e distribuído
de dispositivos computacionais.
( ) -d) Software se desenvolve ao longo do tempo – erros que não
são corrigidos, novas funções são adicionadas, novas versões
são lançadas, sua base de hardware não muda.
( ) -e) Complexidade objetos de software, o que não depende signi-
1-13
10) A respeito de Consistência podemos afirmar que:
( ) -a) O software é fácil de alterar e, como resultado, os requisi-
tos para ele mudam constantemente durante o processo de
desenvolvimento.
( ) -b) O software não pode ser visto, é virtual.
( ) -c) O software não é baseado em premissas objetivas.
( ) -d) São utilizadas com sucesso em outras áreas industriais.
( ) -e) A ciência clássica construiu modelos simples de fenômenos
complexos, e isso foi bem-sucedido, uma vez que a com-
plexidade não era uma característica dos fenômenos em
consideração.
1-14
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 2:
PROCESSO DE
DESENVOLVIMENTO
DE SOFTWARE
PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

2.1 PROCESSO
Como trabalhamos, qual é a sequência de nossos passos,
quais são as normas e regras de comportamento e trabalho, quais
são as regras de relacionamento entre os membros da equipe, como
o projeto interage com o mundo exterior, etc.? Juntos, tendemos a
chamar tudo isso de processo. Percebê-lo, construí-lo e aprimorá-
-lo é a base de qualquer atividade de grupo eficaz. Portanto, não é
por acaso que o processo acabou sendo um dos conceitos básicos
da engenharia de software.
O foco central do estudo da engenharia de software é o pro-
cesso de criação de software - muitas atividades, métodos, técnicas
e etapas diferentes usados para desenvolver e desenvolver softwa-
re e produtos relacionados (planos de projeto, documenta-
ção, código de programa, testes, documentação de usuá-
rio, etc.) .
No entanto, hoje não existe um processo universal de desen-
volvimento de software. Um conjunto de técnicas, regras e regula-
mentos adequados para software de qualquer tipo, para qualquer
empresa, para equipas de qualquer nacionalidade. Cada proces-
so de desenvolvimento atual realizado por uma equipe dentro de
um projeto específico possui um grande número de característi-
cas e personalidades. Porém, é aconselhável planejar o processo
de trabalho antes de iniciar o projeto, definindo os papéis e res-
ponsabilidades na equipe, os produtos do trabalho (intermedi-
ários e finais), o procedimento para participação dos membros
da equipe no seu desenvolvimento, etc. Chamaremos esta descri-
ção preliminar de processo específico, distinguindo-o do plano de
trabalho, especificações de design, etc. Por exemplo, no Microsoft
Visual Tem System existe um modelo de processo que é criado
ou adaptado (no caso de usar um padrão ) antes de iniciar o
2-2

desenvolvimento. O VSTS tem predefinições para processos espe-
cíficos com base no CMMI.
Dentro da empresa, é possível e útil unir e padronizar todos
os processos atuais, que chamaremos de processo padrão. Este úl-
timo, portanto, acaba sendo algum tipo de banco de dados conten-
do o seguinte:
● Informações, regras de uso, documentação e pacotes de

instalação das ferramentas de desenvolvimento utilizadas
nos projetos da empresa (sistemas de controle de versão,
ferramentas de controle de erros, ferramentas de progra-
mação - diversos IDEs, SGBD, etc.);
● Descrição das práticas de desenvolvimento: ge-
renciamento de projetos, regras para trabalhar com um
cliente, etc.;
● Modelos para documentos de design: especificações
técnicas, especificações de design, planos de teste, etc. etc.
● Também é possível padronizar o procedimento para o de-
senvolvimento de um processo específico como.
“Recortes” do padrão. A ideia central do processo padrão

é o fluxo das melhores práticas dentro da empresa, bem como a
unificação das ferramentas de desenvolvimento. Muitas vezes,
nas empresas, diferentes departamentos e projetos diferem muito
na maturidade do processo de desenvolvimento e também é difí-
cil reutilizar as melhores práticas. Além disso, acontece que uma
empresa utiliza várias ferramentas de desenvolvimento paralelas,
por exemplo, ferramentas de controle de versão DBMS. Às vezes
é justificado (por exemplo, esses são os requisitos do clien-
te), muitas vezes é necessário - por exemplo, Java .NET (a maior
competência da empresa offshore permite receber uma
2-3

gama mais ampla de pedidos). Mas muitas vezes esta é uma
escolha arbitrária dos próprios desenvolvedores. Em qualquer
caso, tal multiplicidade complica significativamente a migração de
especialistas de projeto para projeto, a utilização dos resultados de
um projeto em outro, etc. No entanto, ao organizar um processo
padrão, é necessário garantir que o processo padrão não se torne
apenas um aparato burocrático formal. O conceito de um processo
padrão é introduzido e detalhado na abordagem CMMI.
Deve-se notar que a presença de um processo padrão indica
a presença de “a vontade unida” em uma organização que existe
precisamente no nível do processo. No nível de vendas, contabi-
lidade e outros processos e ativos familiares a todas as empresas,
a unidade não é difícil de alcançar. Mas no nível dos processos de
desenvolvimento, muitas vezes cada projeto acaba sendo por conta
própria (especialmente em projetos offshore) - o “turnover”
captura e isola os projetos uns dos outros com muita firmeza.
2.2 Melhoria de processos

Definição: A melhoria do processo (melhoria do proces-
so de software) é a atividade de alterar o processo existente (tan-
to atual, no âmbito de um projeto, e padrão, para toda a
empresa), a fim de melhorar a qualidade dos produtos criados
e / ou reduzir o preço e tempo de desenvolvimento. Os motivos
da relevância desta atividade para as empresas de software são
os seguintes.
1. Uma rápida mudança nas tecnologias de desenvolvimen-

to de software está ocorrendo, exigindo o estudo e imple-
mentação de novas ferramentas de desenvolvimento.
2-4

2. Há um rápido crescimento das empresas e sua entrada
em novos mercados, o que exige uma nova organização
do trabalho.
3. Há alta competição, o que requer a busca por métodos de
desenvolvimento mais eficientes e econômicos.
O que pode ser melhorado e como:

1. Transição para novas ferramentas de desenvolvimento,
linguagens de programação, etc.
2. Melhorar o gerenciamento individual e as práticas de en-
genharia - testes, gerenciamento de requisitos, etc.
3. Reestruturação completa e complexa de todos os proces-
sos de um projeto, departamento, empresa (de acordo
com, por exemplo, CMMI).
4. Certificação da empresa (CMM / CMMI, ISO
9000, etc.).
Separamos o item 3 do item 4 porque, na prática, 4 nem sem-

pre significa trabalho criativo real para melhorar os processos de
desenvolvimento de software, mas muitas vezes se resume a man-
ter o fluxo de trabalho apropriado necessário para obter a certifi-
cação. O certificado é então usado como um meio, uma moeda de
troca na luta por pedidos.
A principal dificuldade em perceber a melhoria de processos
em uma empresa é que ao mesmo tempo que ela deve trabalhar e
criar software, ela não pode ser “registrada”.
Daí a ideia de melhoria contínua do processo, por assim di-
zer, em pequenas porções, para que não seja tão doloroso. Isso é
tanto mais razoável quanto as novas tecnologias de desenvolvi-
mento que surgem no mercado, assim como o desenvolvimento
2-5

das existentes, precisam ser constantemente monitoradas. Essa
estratégia se reflete particularmente no Padrão de Melhoria do
Processo de Desenvolvimento CMMI.
Estratégias de puxar / empurrar: No contexto da intro-
dução de inovações nos processos de produção de empresas (não
necessariamente empresas de software), existem dois para-
digmas a seguir.
1. Organização puxada: as inovações visam resolver

problemas específicos da empresa.
2. O impulso de tecnologia é uma introdução em larga esca-
la de inovações a partir de considerações estratégicas. Em
vez de problemas específicos que serão resolvidos após a
implementação da inovação, neste caso, são considera-
dos os indicadores da empresa (eficiência, produtivi-
dade, volume de negócios anual, valorização das
ações de uma empresa aberta), que serão aumen-
tados, melhorados após a implementação da inovação.
Ao mesmo tempo, presume-se que inúmeros problemas
particulares da organização serão resolvidos automati-
camente, incluindo aqueles sobre os quais nada se sabe
até o momento.
Um exemplo de uso da estratégia pull da organização é a in-

trodução de novas ferramentas de teste em uma situação em que
os requisitos de qualidade do projeto são altos ou quando a quali-
dade do sistema de software não satisfaz o cliente.
Um exemplo do uso da estratégia de push de tecnologia é a
transição da empresa de ferramentas de desenvolvimento estrutu-
ral para ferramentas orientadas a objetos. Outro exemplo de uso
da mesma estratégia é a implementação dos padrões de qualidade
2-6

ISO 9000 ou CMMI. Em ambos os casos, a empresa não resolve
nenhum problema ou uma série de problemas - ela quer mudar
radicalmente a situação, alcançar novas fronteiras, etc.
O problema de aplicar a estratégia de push de tecnologia é
que ela requer uma reestruturação global do processo. Mas a em-
presa não pode ser “fechada para reconstrução” - durante este
tempo a posição de mercado pode ser ocupada por concorrentes,
as ações da empresa podem cair, etc. Assim, a introdução de ino-
vações, via de regra, ocorre paralelamente às atividades habituais
da empresa, por etapas, o que no caso do impulso tecnológico está
associado a grandes dificuldades e riscos.
O uso da estratégia pull da organização é menos arriscado,
as mudanças que ela faz no processo são menos globais, mais lo-
cais. Mas essas inovações também trazem menos benefícios, em
comparação com implementações bem-sucedidas de acordo com a
estratégia de push de tecnologia.
Deve-se observar também que existem problemas que não
podem ser eliminados por alterações pontuais no processo, ou seja,
é necessária a aplicação de uma estratégia de push de tecnologia.
Citemos como exemplo o processo de manutenção e desenvolvi-
mento de uma família de produtos de software que está paralisada
- a empresa sofre grandes prejuízos acompanhando os produtos
já entregues, as ferramentas do projeto estão irremediavelmente
desatualizadas e em um estado deplorável, a gestão está chateado,
todas as tentativas da gerência de mudar o processo resultam em
incompreensão da equipe, brigas e conflitos. É possível que neste
caso não se possa prescindir de uma “revolução”.
Outra diferença entre as duas estratégias: no caso do pull da
organização, via de regra, o retorno do investimento na implemen-
tação é mais rápido do que no caso do push da tecnologia.
2-7

2.3 Modelos de processos clássicos
Determinação do modelo de processo: O processo de
desenvolvimento de software não é uniforme. Um determinado
método de desenvolvimento de software, via de regra, determina
algumas dinâmicas de implantação de determinados tipos de ativi-
dades, ou seja, determina o modelo de processo.
O modelo é uma boa abstração de vários métodos de desen-
volvimento de software, permitindo que sejam apresentados de
forma sucinta, concisa e informativa. No entanto, a própria ideia
de um modelo de processo é uma das primeiras na engenharia de
software, quando se acreditava que um modelo de sucesso é a coisa
mais importante que contribui para o sucesso do desenvolvimento.
Posteriormente, constatou-se que muitos outros aspectos (prin-
cípios de gestão e desenvolvimento, estrutura da equipe,
etc.) precisam ser definidos de comum acordo. E as metodologias
de desenvolvimento integral começaram a se desenvolver. No en-
tanto, existem vários modelos de processo clássicos que são úteis
na prática e serão discutidos a seguir.
Fases e atividades: Ao falar sobre modelos de processos, é
necessário distinguir entre fases e tipos de atividades.
Estágio (fase): é um estágio específico em um processo que
tem um início, um fim e uma saída. Por exemplo, a fase de verifi-
cação de viabilidade do projeto, entrega do projeto, etc. As fases
seguem uma à outra em ordem linear, caracterizada pelo reporte
ao cliente e, muitas vezes, pagamento em dinheiro pela parte do
trabalho executado.
Raramente um cliente concorda em ver os resultados pela
primeira vez somente após a conclusão do projeto. Os empreitei-
ros, por outro lado, preferem receber o pagamento aos poucos, à
2-8

medida que partes do trabalho são feitas. Assim, existem fases que
permitem criar e apresentar os resultados intermediários do pro-
jeto. As fases também são úteis independentemente da interação
com o cliente - com a ajuda delas, você pode sincronizar as ativida-
des de diferentes equipes, bem como acompanhar o andamento do
projeto. Exemplos de fases podem ser o acordo com o cliente das
especificações técnicas, a implementação de determinada funcio-
nalidade do software, a fase de desenvolvimento, terminando com
a entrega do sistema para teste ou o lançamento da versão alfa.
Tipo de atividade (atividade): é um tipo específico de
trabalho executado durante o desenvolvimento de software. Mui-
tas vezes, diferentes tipos de atividades requerem diferentes habi-
lidades profissionais e são realizadas por diferentes profissionais.
Por exemplo, o gerenciamento de projetos é executado por um ge-
rente de projeto, a codificação por um programador e o teste por
um testador. Existem atividades que podem ser realizadas pelas
mesmas pessoas - por exemplo, a codificação e o design (espe-
cialmente em um projeto pequeno) geralmente são realiza-
dos pelas mesmas pessoas.
Muitas atividades diferentes podem ser realizadas em uma
fase. Além disso, um tipo de atividade pode ser realizado em dife-
rentes fases - por exemplo, teste: na fase de análise e design, você
pode escrever testes e configurar um ambiente de teste, durante o
desenvolvimento e antes da entrega, realmente testando a si mes-
mo. Atualmente, para softwares complexos, são utilizados mo-
delos de processos multidimensionais, nos quais a separação das
fases das atividades facilita muito o gerenciamento do desenvolvi-
mento de software.
As atividades, de fato, estão presentes, sob diferentes nomes,
em todos os métodos de desenvolvimento de software. No RUP,
2-9

eles são chamados de fluxos de trabalho; no CMM, eles são cha-
mados de áreas-chave do processo. Manteremos os nomes tradi-
cionais usados em um método ou outro para não criar confusão.
2.3.1 Modelo em cascata

Foi proposto em 1970 por Winston Royce. Na verdade, pela
primeira vez no processo de desenvolvimento de software, várias
etapas de desenvolvimento foram identificadas e as idéias primi-
tivas sobre o desenvolvimento de software na forma de análise de
sistema e codificação foram abaladas.
As seguintes etapas foram identificadas: desenvolvimento de
requisitos de sistema, desenvolvimento de requisitos de software,
análise, design, codificação, teste, uso - ver Figura 2-1.
Outra vantagem desse modelo era a limitação da possibili-
dade de retroceder um passo arbitrário para trás, por exemplo, do
teste à análise, do desenvolvimento ao trabalho nos requisitos, etc.
Observou-se que tais reembolsos poderiam aumentar catastrofica-
mente o custo do projeto e o prazo de sua conclusão. Por exemplo,
se forem descobertos erros de projeto ou análise durante o teste,
corrigi-los geralmente resulta em um retrabalho completo do siste-
ma. Este modelo permitiu retroceder apenas para a etapa anterior,
por exemplo, do teste à codificação, da codificação ao design, etc.
2-10

Figura 2-1: Exemplo de Modelo em Cascata
Fonte: https://www.researchgate.net/profile/Joao-Sedraz/publica-
tion/327222517/figure/fig3/AS:663537412231168@1535211055722/
Figura-1-Modelo-Cascata-Fonte-SOMMERVILLE-2004-p38.png
Por fim, foi introduzida a prototipagem neste modelo, ou

seja, propôs-se desenvolver o sistema duas vezes para reduzir os
riscos de desenvolvimento. A primeira versão - o protótipo - per-
mite que você veja os principais riscos e tome as principais deci-
sões arquitetônicas de maneira razoável. A prototipagem levou até
um terço do tempo de desenvolvimento.
Nos anos 70-80 do século passado, esse modelo estava fir-
memente enraizado no desenvolvimento de software devido à sua
simplicidade e semelhança com os modelos de desenvolvimento
de outros sistemas não relacionados a software. Posteriormente,
em conexão com o desenvolvimento da engenharia de software
e a consciência da natureza iterativa do processo de desenvolvi-
mento de software, esse modelo foi ativamente criticado, na prá-
tica, por todos os autores de artigos e livros didáticos relevantes. É
2-11

geralmente aceito que não reflete as especificidades do desenvol-
vimento de software. As desvantagens do modelo em cascata são:
● identificação de fases e tipos de atividades, o que acarreta

uma perda de flexibilidade de desenvolvimento, em parti-
cular, dificuldades em suportar um processo de desenvol-
vimento iterativo;
● a exigência de conclusão completa da fase da atividade,
consolidação dos resultados na forma de documento ini-
cial detalhado (tarefa técnica, especificação do projeto);
no entanto, a experiência no desenvolvimento de softwa-
re mostra que é impossível desenvolvimento de requisitos
completos, design de sistema, etc. - tudo isso está sujeito a
alterações; e as razões aqui não são apenas que o ambien-
te do projeto é móvel, mas também que muitas decisões
não podem ser precisamente definidas e formuladas com
antecedência, elas são esclarecidas e refinadas somente
mais tarde;
● a integração de todos os resultados do desenvolvimento
ocorre no final, como resultado do que os problemas de
integração se fazem sentir tarde demais;
● os usuários e o cliente não podem se familiarizar com as
variantes do sistema durante o desenvolvimento e ver o
resultado apenas no final; assim, eles não podem influen-
ciar o processo de criação do sistema e, portanto, os ris-
cos de mal-entendidos entre desenvolvedores e usuários /
cliente aumentam;
● o modelo é instável a interrupções no financiamento de
projetos ou na redistribuição de recursos, o desenvolvi-
mento que começou, de fato, não tem alternativas “ao lon-
go do caminho”.
2-12

No entanto, este modelo continua a ser usado na prática -
para pequenos projetos ou no desenvolvimento de sistemas típi-
cos, onde a iteração não é tão exigida. Com sua ajuda, é convenien-
te acompanhar o desenvolvimento e implementar o controle passo
a passo do projeto. Este modelo também é frequentemente usado
em projetos offshore3 com salários por hora. O modelo em casca-
ta foi incorporado como parte de outros modelos e metodologias,
como o MSF.
2.3.2 Modelo em espiral

Foi proposto por Bary Boehm em 1988 para superar as defi-
ciências do modelo em cascata, principalmente para uma melhor
gestão de risco. De acordo com esse modelo, o desenvolvimento
do produto é feito em espiral, cada rodada sendo uma fase de de-
senvolvimento específica. Ao contrário do modelo em cascata, a
espiral não possui um conjunto de curvas pré-determinado e obri-
gatório, cada curva pode se tornar a última no desenvolvimento
do sistema, ao ser finalizada são traçados planos para a próxima
curva. Por fim, um loop é apenas uma fase, e não um tipo de ativi-
dade, como no modelo em cascata; dentro de sua estrutura, muitos
tipos diferentes de atividades podem ser realizados, ou seja, o mo-
delo é bidimensional.
2-13

Figura 2-2: Exemplo de Modelo em Espiral
Fonte: https://miro.medium.com/max/1400/1*RkEarinR8m3rJh7cOLKPyg.png
A sequência de loops pode ser a seguinte: no primei-

ro loop, é tomada uma decisão sobre a viabilidade de criação de
software, no próximo loop, os requisitos do sistema são determi-
nados, então o sistema é projetado, etc. As bobinas podem ter ou-
tros significados.
Cada loop tem a seguinte estrutura (setores):
● Definir os objetivos, restrições e alternativas do projeto;

● Avaliação de alternativas, avaliação e resolução de riscos;
é possível utilizar prototipagem (incluindo a criação de
uma série de protótipos), simulação de sistema, mode-
lagem visual e análise de especificações; foco nas partes
mais arriscadas do projeto;
2-14

● Desenvolvimento e teste: aqui um modelo em cascata
ou o uso de outros modelos e métodos de desenvolvimen-
to de software é possível;
● Planejamento das próximas iterações: são anali-
sados os resultados, planos e recursos para o desenvol-
vimento subsequente; é tomada uma decisão (ou não)
sobre uma nova rodada; analisa se faz sentido continu-
ar a desenvolver o sistema ou não; o desenvolvimento
pode ser suspenso, por exemplo, devido a falhas de fi-
nanciamento; o modelo em espiral permite que você faça
isso corretamente.
Uma espiral separada pode corresponder ao desenvolvi-

mento de algum componente de software ou à introdução de
novas mudanças no produto. Assim, o modelo pode ter uma ter-
ceira dimensão.
O modelo espiral é impraticável para aplicação em projetos
de baixo grau de risco, com orçamento limitado, para projetos pe-
quenos. Além disso, a falta de boas ferramentas de prototipagem
também pode tornar o uso do modelo em espiral inconveniente.
O modelo espiral não encontrou ampla aplicação na indús-
tria e é importante, sim, em termos históricos e metodológicos: é
o primeiro modelo iterativo, tem uma bela metáfora - uma espiral
- e, como o modelo em cascata, foi usado posteriormente para criar
outros modelos de processos e metodologias de desenvolvimento
de software.
2-15
1) Como trabalhamos, qual é a sequência de nossos passos, quais são as

normas e regras de comportamento e trabalho, quais são as regras de
relacionamento entre os membros da equipe, como o projeto interage
com o mundo exterior, etc.? Juntos, tendemos a chamar tudo isso de:
( ) -a) Software.
( ) -b) Engenharia.
( ) -c) Código.
( ) -d) Processo.
( ) -e) Produtos.

I) Hoje existe um processo universal de desenvolvimento de software.
Um conjunto de técnicas, regras e regulamentos adequados para sof-
tware de qualquer tipo, para qualquer empresa, para equipas de qualquer
nacionalidade.
II) Cada processo de desenvolvimento atual realizado por uma equipe den-
tro de um projeto específico possui um grande número de características e
personalidades.
III) O foco central do estudo da engenharia de software é o processo de
criação de software - muitas atividades, métodos, técnicas e etapas dife-
rentes usados para desenvolver e desenvolver softwares e produtos rela-
cionados planos de projeto, documentação, código de programa, testes,
documentação de usuário, etc.
Estão CORRETAS:
( ) -a) III, somente
( ) -b) II e III
( ) -c) I, somente
( ) -d) II, somente
( ) -e) I e II
2-16
I) Não é aconselhável planejar o processo de trabalho antes de iniciar o
projeto, definindo os papéis e responsabilidades na equipe, os produtos do
trabalho intermediários e finais, o procedimento para participação dos mem-
bros da equipe no seu desenvolvimento, etc.
II) Microsoft Visual Tem System existe um modelo de processo que é criado
ou adaptado (no caso de usar um padrão antes de iniciar o desenvolvimento.
III) O VSTS tem predefinições para processos específicos com base no
CMMI.
Estão INCORRETAS:
( ) -a) I e III
( ) -b) I, somente
( ) -d) II e III
( ) -e) II, somente
4) Dentro da empresa, é possível e útil unir e padronizar todos os processos

atuais, que chamamos de:
( ) -a) Processo.
( ) -b) Código.
( ) -c) Produtos.
( ) -d) Software
( ) -e) Processo padrão.
5) A ideia central do processo padrão é:
( ) -a) Informações, regras de uso, documentação e pacotes de ins-

talação das ferramentas de desenvolvimento utilizadas nos
projetos da empresa.
( ) -b) Descrição das práticas de desenvolvimento - gerenciamento
de projetos, regras para trabalhar com um cliente, etc.;
( ) -c) É o fluxo das melhores práticas dentro da empresa, bem
como a unificação das ferramentas de desenvolvimento.
( ) -d) Modelos para documentos de design - especificações técni-
cas, especificações de design, planos de teste, etc.
2-17
( ) -e) Também é possível padronizar o procedimento para o de-
senvolvimento de um processo específico.
I) Muitas vezes, nas empresas, diferentes departamentos e projetos diferem
muito na maturidade do processo de desenvolvimento e também é difícil
reutilizar as melhores práticas.
II) Uma empresa utiliza várias ferramentas de desenvolvimento paralelas,
por exemplo, ferramentas de controle de versão DBMS.
III) Às vezes não é justificado por exemplo, esses são os requisitos do clien-
te, muitas vezes é necessário - por exemplo, Java .NET a maior competência
da empresa offshore permite receber uma gama mais ampla de pedidos.
Estão CORRETAS:
( ) -b) I e II
( ) -c) I e III
( ) -d) II e III
( ) -e) II, somente
7) Para organizar um processo padrão, é necessário:
( ) -a) Garantir que o processo padrão não se torne apenas um apa-

rato burocrático formal
( ) -b) Modelos para documentos de design - especificações técni-
( ) -c) Informações, regras de uso, documentação e pacotes de ins-
( ) -d) Descrição das práticas de desenvolvimento - gerenciamento
( ) -e) Padronizar o procedimento para o desenvolvimento de um
processo específico.
2-18
8) Podemos definir Melhoria de processos como:
( ) -a) Modelos para documentos de design - especificações técni-
( ) -b) Informações, regras de uso, documentação e pacotes de ins-
( ) -c) Descrição das práticas de desenvolvimento - gerenciamento
( ) -d) É a atividade de alterar o processo existente tanto atual, no
âmbito de um projeto, e padrão, para toda a empresa, a fim
de melhorar a qualidade dos produtos criados e / ou reduzir
o preço e tempo de desenvolvimento.
( ) -e) Padronizar o procedimento para o desenvolvimento de um
processo específico.
9) A principal dificuldade em perceber a melhoria de processos em uma

empresa é:
( ) -a) Uma rápida mudança nas tecnologias de desenvolvimento

de software está ocorrendo, exigindo o estudo e implemen-
tação de novas ferramentas de desenvolvimento.
( ) -b) Que ao mesmo tempo que ela deve trabalhar e criar softwa-
re, ela não pode ser “registrada”.
( ) -c) Há alta competição, o que requer a busca por métodos de
desenvolvimento mais eficientes e econômicos.
( ) -d) Há um rápido crescimento das empresas e sua entrada
em novos mercados, o que exige uma nova organização do
trabalho.
( ) -e) Melhorar o gerenciamento individual e as práticas de enge-
nharia - testes, gerenciamento de requisitos, etc.
10) Um exemplo do uso da estratégia de Push de tecnologia é:

( ) -a) A introdução de novas ferramentas de teste em uma situação
em que os requisitos de qualidade do projeto são altos ou
quando a qualidade do sistema de software não satisfaz o
cliente.
2-19
( ) -b) A transição da empresa de ferramentas de desenvolvimento
estrutural para ferramentas orientadas a objetos.
( ) -c) Uma rápida mudança nas tecnologias de desenvolvimento
de software está ocorrendo, exigindo o estudo e implemen-
tação de novas ferramentas de desenvolvimento.
( ) -d) As inovações que visam resolver problemas específicos da
empresa.
( ) -e) O impulso de tecnologia que é uma introdução em larga es-
cala de inovações a partir de considerações estratégicas.
2-20
DISCIPLINA:
Engenharia de
Software
UNIDADE 2:
PRODUTO DE TRABALHO E
ARQUITETURA DE SOFTWARE
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta segunda unidade, daremos orientações sobre a importância e

relevância do trabalho em equipe, além de entendermos sobre arquite-
tura de software.
Nesta unidade, iremos conhecer um pouco sobre produto de trabalho
e disciplina de compromisso, a relevância de se trabalhar em equipe, ar-
quitetura de software e os mais variados pontos de vista ao se analisar
um sistema.
9 Produto de Trabalho e Disciplina de Compromisso
9 Arquitetura de Software
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 3:
PRODUTO DE TRABALHO E
DISCIPLINA DE COMPROMISSO
PRODUTO DE TR A B A LH O E D IS C IP LIN A D E CO MPR O M I SSO

3.1 FUNDAMENTOS
Devido à natureza criativa da programação, a significativa
juventude dos participantes do desenvolvimento de software, al-
gumas questões da produção industrial comum, que se tornaram
corriqueiras há muito tempo, tornam-se relevantes. Em primeiro
lugar, é uma disciplina de compromisso e um produto de trabalho.
Este conhecimento, sendo dominado na prática, é extremamente
útil no trabalho em equipe. Além disso, as metodologias de desen-
volvimento de software hoje amplamente utilizadas na prática,
apoiadas em ferramentas de software adequadas, utilizam ativa-
mente esses conceitos, esclarecendo-os e concretizando-os.
3.2 Produto de Trabalho

Uma das condições essenciais para a controlabilidade de um
processo industrial é a presença de resultados de trabalho docu-
mentados separadamente - tanto na entrega final como nas inter-
mediárias. Essas entregas individuais, como parte das entregas
gerais, ajudam a identificar, planejar e avaliar as diferentes partes
da entrega. As entregas intermediárias ajudam os gerentes em di-
ferentes níveis a rastrear o progresso do projeto, dando ao cliente a
oportunidade de ver os resultados bem antes do final do o projeto.
Além disso, os próprios participantes do projeto, no seu trabalho
diário, recebem uma forma simples e eficaz de trocar informações
de trabalho - a troca de resultados.
Este resultado é um produto de trabalho - qualquer artefato
produzido durante o desenvolvimento de software, por exemplo,
um arquivo ou conjunto de arquivos, documentos, componentes
de produtos, serviços, processos, especificações, faturas, etc.
3-3

Figura 3-1: Exemplo de Produto de Trabalho
Fonte: Próprio Autor
A principal diferença entre um produto de trabalho e um

componente de software é que o primeiro não é necessariamente
material e não deve ser projetado, embora possa ser. Um produto
de trabalho intangível é, via de regra, algum processo estabelecido
- um processo industrial para a produção de qualquer produto, um
processo educacional em uma universidade (em uma faculda-
de, em um departamento), etc.
É importante observar que o produto do trabalho não faz ne-
cessariamente parte da entrega final. Por exemplo, um processo de
teste de sistema simplificado não é entregue ao cliente junto com o
próprio sistema. A capacidade de gerir projetos (não apenas no
domínio da programação) está largamente associada à arte de
definir os produtos de trabalho necessários, insistir na sua criação
e, nos seus termos, conduzir a aceitação de fases intermédias do
3-4

trabalho, para organizar a sincronização de vários grupos de traba-
lho e especialistas individuais.
Muitas metodologias incluem descrições de produtos de
trabalho específicos usados no processo - CMMI, MSF, RUP,
etc. Por exemplo, no MSF, estes são código de programa, diagra-
mas de aplicativo e diagramas de classe, plano de iteração, teste
de unidade modular, etc. neles, o conteúdo, responsável pelo de-
senvolvimento, lugar no processo, e outros aspectos são descritos
com precisão.
Vamos nos deter em mais detalhes sobre os produtos de tra-
balho intermediários. Um componente de software criado em um
projeto por um desenvolvedor e fornecido para uso por outro de-
senvolvedor acaba sendo um produto de trabalho. Deve ser tes-
tado minimamente, os nomes das classes e métodos de interface
devem ser corrigidos, talvez, o desnecessário, não relacionado à
funcionalidade deste componente, deva ser removido, é melhor
separar público e privado, etc. Ou seja, para fazer algum trabalho
adicional, que, talvez, o desenvolvedor não teria feito se continu-
asse a usar o componente apenas ele mesmo. O escopo deste tra-
balho adicional aumenta significativamente se o componente for
submetido para uso em desenvolvimento, por exemplo, para ou-
tro centro de desenvolvimento (por exemplo, para parceiros
estrangeiros, que é uma situação comum no desenvolvi-
mento offshore). Então, fazer bons produtos de trabalho inter-
mediários é muito importante para o sucesso de um projeto, mas
requer trabalho adicional de seus autores. Trabalhar sozinho sem
fornecer produtos de trabalho é mais fácil e preferível para muitos.
Mas o trabalho em equipe exige despesas gerais, incluindo gastos
com produtos de trabalho intermediários. Claro, a qualidade des-
ses produtos e os custos de mão de obra para sua fabricação variam
3-5

muito dependendo da situação, mas aqui é importante entender o
próprio princípio.
Portanto, para resumir, um produto de trabalho intermediá-
rio deve necessariamente ter um propósito claro e usuários especí-
ficos a fim de minimizar a sobrecarga de criá-lo.
Figura 3-2: Exemplo de Produto de Trabalho
Fonte: Próprio Autor
3.3 Disciplina de compromisso

A divisão de responsabilidades nos negócios e na produ-
ção industrial é baseada em uma certa ética empresarial, regras
e regulamentos corporativos, a forma de relações - a disciplina de
obrigações. É amplamente utilizado na prática e é uma das formas
possíveis de relacionamento social entre as pessoas. Introdução de
outros modelos de relações humanas nos negócios e na indústria
- família, relações sexuais, amizade, etc. frequentemente causa sé-
rios danos aos negócios, gera conflito, diminui a eficiência.
3-6

A base desta forma de relacionamento são
as obrigações que:
● Dado voluntariamente;
● Não é fácil: trabalho, recursos, cronograma devem ser
cuidadosamente considerados;
● Entre as partes inclui o que será feito, por quem e em
que prazo;
● Formulado aberta e publicamente (ou seja, não é
um “conhecimento secreto”). Além do mais:
● O responsável procura cumprir as obrigações, mesmo que
seja necessária ajuda;
● Antes prazo, assim que fica claro que a obra não pode ser
concluída no prazo, novos compromissos são discutidos.
Observe que a disciplina de obrigações não é algum tipo de

conjunto de regras, leis, ela também difere da cultura corporativa.
Este é um certo fenômeno mental de grupo que existe na socieda-
de das pessoas modernas. Os pontos acima não são uma descrição
exaustiva deste fenômeno, mas apenas o manifestam e designam,
por assim dizer, evocam as memórias necessárias.
A disciplina de obrigações, apesar da obviedade, às vezes não
é simplesmente implementada na prática, por exemplo, nos cam-
pos criativos da atividade humana, no campo do treinamento, etc.
Existem algumas pessoas para as quais essa disciplina é interna-
mente estranha, independentemente do seu tipo de atividade.
Por outro lado, as pessoas que dominam esta disciplina ten-
dem muitas vezes a aplicá-la em outras áreas da vida e das relações
humanas, o que nem sempre se justifica. Enfatizemos que esta dis-
ciplina está longe de ser o único modelo de relações entre as pes-
soas. Como exemplo, considere as relações familiares ou amizades,
3-7

que obviamente não podem ser expressas pela disciplina do com-
promisso. Portanto, ao invés da precisão e pontualidade nessas re-
lações, a empatia emocional e sensorial é importante, sem a qual
eles são impossíveis.
A disciplina de comprometimento recebe muita atenção
dentro de MSF, porque não há líder ou chefe no modelo de equi-
pe. Esta disciplina também é implementada no Scrum: a equipe
Scrum tem muita liberdade e, portanto, muita responsabilidade.
As regras para ações quando as obrigações não podem ser cumpri-
das por tal equipe também são regulamentadas.
3.4 Projeto
A clássica divisão operacional do trabalho vem de Adam
Smith e é a essência da produção industrial em massa. Ou seja,
existe um processo de trabalho bem estabelecido e existem áreas
de especialização - uma loja afia, outra planifica, a terceira recolhe,
a quarta tinta, etc. O rendimento de tal instalação de produção ex-
cede em muito o de uma pessoa ou uma equipe realizando todo o
trabalho. Assim, no século XIX, a divisão operacional do trabalho
tornou-se a base das manufaturas, suplantando a produção arte-
sanal individual. No início do século 20, essa estrutura de trabalho
foi transferida para a gestão - ou seja, vários gerentes controlavam
áreas individuais de trabalho.
No entanto, o alto nível de complexidade de uma série de
tarefas na indústria e nos negócios não permite (felizmente!)
Funcionar dessa forma em todos os lugares. São muitas as tare-
fas criativas e novas onde, talvez, no futuro, será possível criar
transportadores, mas no momento, sua solução requer uma con-
centração significativa de esforços e energia das pessoas, soluções
3-8

inesperadas, bem como sorte e uma mão leve. . Esta é a área
de projetos.
Projeto: esta é uma atividade única (em contraste com a
produção industrial operacional tradicional) que tem um
início e um fim no tempo, visando atingir um determinado resul-
tado / objetivo, criando um produto ou serviço específico e único,
com determinados recursos e restrições de tempo, bem como os
requisitos de qualidade e o nível de risco aceitável.
Em particular, o desenvolvimento de software é principal-
mente uma área de projeto.
É necessário distinguir entre projetos industriais e criativos.
Eles têm princípios de gestão diferentes. A complexidade dos pro-
jetos industriais reside no grande número de diferentes organiza-
ções, empresas e na relativa singularidade das próprias obras. Um
exemplo é a construção de um edifício de vários andares. Isso tam-
bém inclui vários projetos internacionais e não apenas industriais
- educacionais, culturais, etc. A tarefa na gestão de tais projetos
é cobrir tudo, controlar tudo, não esquecer de nada, reunir tudo,
conseguir movimento, e o movimento é coordenado.
Os projetos criativos caracterizam-se por uma novidade ab-
soluta de ideias - um novo serviço, um produto de software com-
pletamente novo, que ainda não está no mercado, projetos no cam-
po da arte e da ciência. Qualquer empresa startup, como regra, é
um projeto criativo. Além disso, a novidade em tais projetos não é
apenas absoluta - isso ainda não aconteceu. Isso pode já ter aconte-
cido, mas não em sonhos, pela equipe do projeto. Ou seja, há uma
grande novidade relativa para as próprias pessoas que incorporam
este projeto.
Os projetos de desenvolvimento de software situam-se en-
tre esses dois polos, ocupando diferentes posições neste espaço.
3-9

Frequentemente, são complexos porque são volumosos e estão na
interseção de várias disciplinas - o negócio-alvo onde o produto
de software deve ser integrado e a programação complexa e não
trivial. O desenvolvimento de equipamentos eletrônicos e mecâni-
cos exclusivos é frequentemente adicionado a isso. Por outro lado,
uma vez que a programação é ativamente promovida em várias
esferas da atividade humana, isso acontece através da criação de
produtos completamente novos e únicos, e seu desenvolvimento e
promoção têm todas as características de projetos criativos.
Gerenciamento de Projetos (gestão de projetos) é uma
área de atividade no decurso da qual, no âmbito de certos proje-
tos, objetivos claros são determinados e alcançados ao encontrar
um compromisso entre a quantidade de trabalho, recursos (como
tempo, dinheiro, trabalho, materiais, energia, espaço,
etc.), tempo, qualidade e riscos.
Vamos observar vários aspectos importantes do gerencia-
mento de projetos.
Stakeholders: são pessoas / partes que não estão direta-
mente envolvidas no projeto, mas o influenciam e ou têm interesse
em seus resultados. Eles podem ser futuros usuários do sistema
(por exemplo, em uma situação em que eles e o cliente
não sejam os mesmos), a alta administração da empresa de-
senvolvedora, etc. A identificação de todas as partes interessadas e
o trabalho competente com eles é um componente importante do
gerenciamento de projetos de sucesso
Escopo do projeto: São os limites do projeto. Este é um
conceito muito importante para projetos de software devido à va-
riabilidade de requisitos. Muitas vezes acontece que os desenvol-
vedores começam a criar um sistema e, então, gradualmente, ele
se transforma em outro. Além disso, para os gerentes de vendas,
3-10

assim como para o cliente, nada aconteceu radicalmente, mas do
ponto de vista da estrutura interna do software, das tecnologias,
dos algoritmos de implementação, da arquitetura - tudo está mu-
dando radicalmente. O gerenciamento de projetos deve monitorar
essas tendências e lidar com elas com competência.
Compromissos: o aspecto mais importante do gerencia-
mento de projetos de software devido à consistência do software.
É importante não perder todos os parâmetros e partes acordados e
encontrar um compromisso aceitável. Uma de suas técnicas de ge-
renciamento de compensação será discutida no contexto do estudo
da metodologia do MSF.
Ao desenvolver projetos de software, as seguintes áreas de
gerenciamento são importantes:
Tabela 3-1: Áreas de Gerenciamento
Área de gerenciamento
Descrição
de projetos
Planejamento e monitora-
Integração e sincronização de planos
mento do projeto, planeja-
de projeto; organização de procedi-
mento do projeto / acom-
mentos e sistemas para gestão e moni-
panhamento / controle de
toramento de mudanças de projeto.
mudanças
Determinação e distribuição do esco-
po de trabalho (estrutura do projeto);
Gerenciamento do escopo
gerenciamento de compensação em
um projeto.
Elaboração de um calendário a partir
de estimativas de custos trabalhistas,
pedidos tarefas, mapeamento de recur-
Gestão de Cronograma
sos disponíveis para tarefas, aplicação
de métodos estatísticos, suporte da
programação do calendário.
3-11

Área de gerenciamento
Descrição
de projetos
Estimativas de custos com base em
Gestão de custos - (Custo estimativas de tempo; relatório e análi-
Gestão) se do progresso do projeto; análise de
risco de custo; Análise de valor
Planejamento de recursos; construir
Gestão de Pessoal - (Pes- uma equipe de projeto; resolução de
soal Gestão de recursos) conflitos; planejamento e gestão de
treinamento.
Planejamento de comunicação (entre
a equipe do projeto, cliente / patroci-
Gestão de comunicação -
nador, consumidores / usuários, outras
(Gestão de Comunicações)
partes interessadas); relatório de pro-
gresso do projeto.
Organização do processo de gestão de
Gestão de riscos - (Risco riscos na equipe e assessoria a ela; ga-
Gestão) rantindo o fluxo de trabalho de gestão
de risco.
Análise de preços de prestadores de
serviços e / ou hardware / software
provisão; preparação de documentos
Gestão de suprimentos para início de propostas (editais - RFPs),
- (Compras) seleção de fornecedores e subcontra-
tados; redigir contratos e negociar seus
termos; contrato; ordens de compra e
solicitações de pagamento.
Planejamento de qualidade, definição
Controle de qualidade - padrões aplicados, documentando
(Qualidade Gestão) critérios de qualidade e processos de
medição.
Fonte: Próprio autor
3-12

I) Devido à natureza criativa da programação, a significativa juventude dos
participantes do desenvolvimento de software, algumas questões da produ-
ção industrial comum, que se tornaram corriqueiras há muito tempo, tor-
nam-se relevantes.
II) As metodologias de desenvolvimento de software hoje não amplamente
utilizadas na prática, apoiadas em ferramentas de software adequadas, utili-
zam ativamente esses conceitos, esclarecendo-os e concretizando-os.
III) Uma das condições essenciais para a controlabilidade de um processo
industrial é a presença de resultados de trabalho documentados separada-
mente - tanto na entrega final como nas intermediárias.
Estão CORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) I e III
( ) -e) II e III

I) Entregas individuais, como parte das entregas gerais, ajudam os gerentes
em diferentes níveis a rastrear o progresso do projeto, dando ao cliente a
oportunidade de ver os resultados bem antes do final do o projeto.
II) As entregas intermediárias ajudam a identificar, planejar e avaliar as di-
ferentes partes da entrega.
III) Qualquer artefato produzido durante o desenvolvimento de software,
por exemplo, um arquivo ou conjunto de arquivos, documentos, componen-
tes de produtos, serviços, processos, especificações, faturas, etc.
Estão INCORRETAS:
3-13
( ) -a) I e II
( ) -b) II e III
( ) -d) II, somente
( ) -e) I e III
3) A principal diferença entre um produto de trabalho e um componente de

software é:
( ) -a) As entregas intermediárias ajudam a identificar, planejar e

avaliar as diferentes partes da entrega.
( ) -b) Que o primeiro não é necessariamente material e não deve
ser projetado, embora possa ser.
( ) -c) Um produto de trabalho intangível não é, via de regra.
( ) -d) Uma das condições essenciais para a consolabilidade de um
processo industrial é a presença de resultados de trabalho
documentados separadamente - tanto na entrega final como
nas intermediárias.
( ) -e) Observar que o produto do trabalho faz necessariamente
parte da entrega final.
4) Muitas metodologias incluem descrições de produtos de trabalho especí-

ficos usados no processo de:
( ) -a) CNMI, MSF, RUPP

( ) -b) CMI, MSPF, RUP
( ) -c) CNNI, MSF, RUP
( ) -d) CMMI, MSF, TUP
( ) -e) CMMI, MSF, RUP

I) Um componente de software criado em um projeto por um desenvolvedor
e fornecido para uso por outro desenvolvedor acaba sendo um produto de
trabalho.
II) O escopo de trabalho adicional não aumenta significativamente se o
componente for submetido para uso em desenvolvimento
3-14
III) Fazer bons produtos de trabalho intermediários não é muito importan-
te para o sucesso de um projeto, mas requer trabalho adicional de seus
autores.
Estão CORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) II e III
( ) -d) I, somente
( ) -e) III, somente
6) A divisão de responsabilidades nos negócios e na produção industrial é:
( ) -a) Despesas gerais, incluindo gastos com produtos de trabalho

intermediários.
( ) -b) Baseada em uma certa ética empresarial, regras e regula-
mentos corporativos, a forma de relações - a disciplina de
obrigações.
( ) -c) Um componente de software criado em um projeto por um
desenvolvedor e fornecido para uso por outro desenvolvedor
acaba sendo um produto de trabalho.
( ) -d) Uma das formas menos possíveis de relacionamento social
entre as pessoas.
( ) -e) Fácil - trabalho, recursos, cronograma devem ser cuidadosa-
mente considerados;
7) Observe as afirmações abaixo a respeito de Disciplina de Compromisso.

I) A disciplina de obrigações, apesar da obviedade, às vezes não é simples-
mente implementada na prática, por exemplo, nos campos criativos da ativi-
dade humana, no campo do treinamento, etc.
II) Existem algumas pessoas para as quais essa disciplina não é interna-
mente estranha, independentemente do seu tipo de atividade.
III) Pessoas que dominam esta disciplina tendem muitas vezes a aplicá-la
em outras áreas da vida e das relações humanas, o que nem sempre se
justifica.
Estão INCORRETAS:
3-15
( ) -a) II, somente
( ) -b) II e III
( ) -d) I, somente
( ) -e) I e III
8) A disciplina de comprometimento recebe muita atenção dentro de:
( ) -a) CMMI
( ) -b) RUP
( ) -c) MSF
( ) -d) SOFTWARE
( ) -e) CNNI
9) É correto afirma sobre projeto:
( ) -a) É implementada no Scrum.

( ) -b) Que a obra não pode ser concluída no prazo, novos compro-
missos são discutidos.
( ) -c) O responsável não procura cumprir as obrigações, mesmo
que seja necessária ajuda;
( ) -d) É uma atividade única em contraste com a produção indus-
trial operacional tradicional que tem um início e um fim no
tempo, visando atingir um determinado resultado / objetivo.
( ) -e) Não é necessário distinguir entre projetos industriais e criativos.
10) A complexidade dos projetos industriais reside no grande número de di-

ferentes organizações, empresas e na relativa singularidade das próprias
obras. Um exemplo é:
( ) -a) A construção de um edifício de vários andares.

( ) -b) Dado voluntariamente
( ) -c) A disciplina de obrigações.
( ) -d) Um produto de trabalho intangível não é, via de regra.
( ) -e) Qualquer artefato produzido durante o desenvolvimento de
software.
3-16
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 4:
ARQUITETURA DE SOFTWARE
A R Q U ITETU R A D E SO FT WARE
4.1 FUNDAMENTOS
Certa vez, um gerente estava explicando as ideias principais
de um projeto bastante grande que ele liderava. Ele desenhou três
cubos no quadro: frontend, backend, ferramentas. E ele disse que
essa é a estrutura principal do projeto. Quer ao nível da estrutura
interna do produto, quer ao nível da distribuição do trabalho da
equipa em três centros de desenvolvimento dispersos remotamen-
te. As tarefas de back-end são complexas, consomem muitos recur-
sos e são realizadas em lotes. Eles são separados da interface grá-
fica do produto (frontend), que também é complexa. O frontend
é uma interface de usuário: complexa, parametrizável, com vários
serviços de usuário integrados (em particular, o navegador de
informações) e também personalizável. Ambos os subsistemas
interagem entre si por meio de uma interface de programação bem
definida e detalhada: algoritmos de back-end são divididos em mé-
todos, que o frontend pode chamar de acordo com regras especiais,
com parâmetros, alinhando-se em uma cadeia para atingir seus
objetivos. “Do lado” de tudo isso estão as ferramentas adicionais.
Eles se integram ao front-end, mas não usam os métodos de back-
-end, mas implementam suas tarefas por conta própria. Essas ta-
refas não requerem processamento em lote complexo, mas visam a
interação interativa do usuário. Durante sua implementação, mui-
ta atenção foi dada à usabilidade.
Cada um dos três subsistemas exigiu habilidades específi-
cas dos desenvolvedores. No caso do backend, foi a habilidade e
experiência em implementar este tipo de algoritmos em lote, no
caso do frontend, foi a capacidade de criar uma interface de usu-
ário complexa, no caso de ferramentas, a arte era necessária no
projeto e implementação de ferramentas “leves” que fornecem aos
usuários do sistema recursos de serviço adicionais. Havia também
4-2
uma série de aspectos políticos para dividir o trabalho dessa for-
ma. Especificamente, a gerência de projetos queria ter o processo
de desenvolvimento da interface do usuário ao seu lado, em um
dos três centros de desenvolvimento que coincidiam com a matriz.
Acreditava-se que a aparência de um produto era muito importan-
te para o sucesso de sua venda e requeria atenção especial.
Como resultado do projeto (e tem se desenvolvido por
mais de 15 anos, alcançando seu apogeu até 150 pessoas
simultaneamente empregadas nele), tal estrutura clara mu-
dou um pouco - tão geograficamente, a interface quase “mudou”
para o centro onde o back-end foi desenvolvido. Mas, em geral,
essa divisão ponta a ponta do projeto em partes permaneceu por
muitos anos e foi o esqueleto principal de todo o desenvolvimento.
Este é um exemplo da arquitetura de um projeto de software.
4.2 Definição
Entendemos por arquitetura de software a estrutura interna
do produto (componentes e suas conexões), os fundamentos
da interface do usuário do produto, bem como a quintessência de
conhecimentos e soluções que são uma ferramenta para desenvol-
ver e gerenciar um projeto. Ou seja, a arquitetura é um conceito
ponta a ponta ou um conjunto daqueles para a superação da en-
tropia e do caos, buscando “engolir” o desenvolvimento tendo em
vista a complexidade, imaterialidade, consistência e variabilidade
do software. Ao mesmo tempo, não separamos o produto e o pro-
jeto, pois na prática ele é, via de regra, um todo, e esta “Passagem”,
se houver, é a “força” desse design.
Frequentemente, arquitetura é entendida como, por exem-
plo, apenas a estrutura interna do software, expressa em diagramas
4-3
UML. Aqui está uma piada sobre o fato de que a arquitetura não
pode ser entendida de forma unilateral. Foi perguntado a uma
emissora conhecida por que ela tinha exatamente 21 visualiza-
ções. Esperávamos ouvir uma lista sobre problemas algorítmicos
que conseguimos superar desta forma, algo sobre a eficiência es-
pecial dos algoritmos organizados desta forma, etc. Todos ficaram
surpresos com a resposta do mestre. Ele disse que exatamente es-
sas pessoas (ou seja, exatamente 21), ele tinha em sua equipe
de desenvolvimento.
Assim, a arquitetura do produto acaba sendo uma invariante
do projeto, ela ocorre e surge inesperadamente em suas diferentes
partes. Isso é um análogo dos postulados e leis “simples” das ciên-
cias naturais, cuja ausência no desenvolvimento de software, de
acordo com Brooks, é a razão da complexidade do software (no
sentido de caos, ou seja, complexidade “ruim”). Criar tais
estruturas não é uma tarefa fácil e requer muita arte. Mas esta é
precisamente a maneira de controlar o caos, aumentando a entro-
pia na forma de mudanças nos requisitos do sistema e a perda de
um entendimento claro pelos desenvolvedores de que tipo de siste-
ma eles estão criando. E é o desenvolvimento de tais estruturas que
proporciona verdadeiro prazer criativo ao desenvolver sistemas de
software. Modelos simples que não são fáceis de criar funcionam
bem. Eles acabam sendo o fio condutor do projeto, conduzindo-o
através do abismo do caos. Esses modelos têm essa propriedade.
Muitos projetos não criam uma arquitetura original, pois
são típicos e / ou pequenos e se baseiam em tecnologias prontas,
amostras arquitetônicas, modelos de equipe e na estrutura organi-
zacional do projeto.
No entanto, as equipes que se mostraram bem em tais pro-
jetos muitas vezes enfrentam o desafio de construir uma nova
4-4
arquitetura verdadeiramente original com base em desenvolvi-
mentos anteriores. Ou não é baseado - é apenas quantidade que
se esforça para se transformar em qualidade. Aqui, em primeiro
lugar, é importante notar essa transição, perceber que os antigos
métodos de trabalho não são adequados e uma experiência funda-
mentalmente nova é necessária. O que, muitas vezes, o coletivo e
seus dirigentes não.
4.3 Pluralidade de pontos de vista

Ao desenvolver a arquitetura de software, é importante com-
binar vários pontos de vista. O software acaba sendo tão comple-
xo que sua arquitetura não pode ser construída como um modelo
único - muitos aspectos separados devem ser representados na ar-
quitetura, suas conexões são complexas e mal expressas de forma
explícita. Acontece que é mais útil criar muitos modelos criados a
partir de diferentes pontos de vista.
A razão da multiplicidade de pontos de vista no desenvolvi-
mento de software. A capacidade de ver um assunto de diferen-
tes pontos de vista é a filosofia mais importante de uma prática
bem-sucedida ao trabalhar com grandes volumes de informações
heterogêneas e complexas. Vejamos o desenvolvimento de softwa-
re e por que há uma demanda por diferentes visões do processo,
sistema, etc.
Isso se deve principalmente às diferentes atividades do pro-
cesso de desenvolvimento de software (consulte a Figura 4-1).
Ao elaborar requisitos funcionais para software, é dada atenção a
que tipo de funcionalidade deve ser implementada, mas os princí-
pios e detalhes de implementação são omitidos. Ao contrário, ao
projetar, os princípios de implementação de software vêm à tona.
4-5
E durante o teste, os detalhes de implementação são novamente
sem importância - o software é visto como uma caixa preta que
implementa (não importa de que maneira) um determinado
conjunto de funcionalidades do usuário. Quando implantado no
local do cliente, o software é visto como um conjunto de arquivos,
armazenamentos de dados, etc.
Figura 4-1: Atividades diferentes sobre um sistema
Além disso, um grande número de especialistas muito dife-

rentes está envolvido no desenvolvimento / uso de software: pro-
gramadores, engenheiros, testadores, redatores técnicos, gerentes,
clientes, usuários, profissionais de marketing de vendas, etc. (ver
Figura 4-2). Todos esses especialistas precisam de informações
diferentes sobre o sistema de software. Imagine o que aconteceria
se, por exemplo, um vendedor ou um cliente não programador, em
resposta a um pedido para conhecer melhor o software, você ce-
desse os códigos do programa para ler.
4-6
Figura 4-2: Diferentes especialistas analisando um sistema
A pluralidade de pontos de vista também decorre do fato de

que não existem padrões e normas uniformes para o desenvolvi-
mento de software. Ou seja, o desenvolvimento de software é, em
muitos aspectos, o “estado da arte”. Frequentemente, você tem
que inventar uma nova modelagem de ponto de vista diretamen-
te de acordo com a situação - para que seja esse especialista que
o entenda, para que essas características particulares do sistema
sejam refletidas.
Frequentemente aqui: como em uma loteria: várias
descrições do sistema são criadas de diferentes pontos de vista,
algumas delas acabam sendo bem-sucedidas e todos irão usá-las
no futuro.
4-7
Assim, diferentes tipos de atividades no desenvolvimento de
software, diferentes categorias de especialistas envolvidos em um
projeto de software e a singularidade de cada situação específica
durante o desenvolvimento - tudo isso leva à criação e utilização de
vários modelos feitos de diferentes pontos de vista.
Ponto de vista: é uma determinada visão do sistema, que
é realizada para realizar uma determinada tarefa por qualquer um
dos participantes do projeto. O ponto de vista deve ser claramente
compreendido ao criar modelos visuais, como um modelo de caso
de uso. É importante entender que pode ser diferente em cada caso
específico. As características mais importantes de uma perspectiva
de modelagem são o objetivo (por que o modelo é criado) e o
público-alvo (ou seja, a quem se destina).
Uma questão importante que você precisa responder hones-
tamente a si mesmo no início da modelagem é por que você usa
diagramas (em particular, UML). Esta é a definição do objetivo
da simulação. Porque essa é a maneira certa de criar modelos, é
necessário? E todos os problemas (mesmo aqueles sobre os
quais nada se sabe ainda) irão desaparecer magicamente, de-
saparecer? Muitas vezes, por exemplo, ao criar um modelo de caso
de uso, existe exatamente esse “propósito” de modelagem. E então
acontece que nenhum problema foi “curado”, mas, pelo contrário,
surgiram novos (por exemplo, ninguém entende ou aceita
os diagramas que criamos). E o próprio analista sente que os
diagramas são um tanto estranhos….
Ou talvez não seja nada disso. Por exemplo, o analista real-
mente se propôs a identificar os requisitos do sistema - não para
impor sua própria visão aos outros, mas para encontrar a infor-
mação necessária, modelar e apresentá-la de forma acessível. Para
fazer isso, ele usa diagramas de casos de uso. É importante para
4-8
ele que futuros usuários do sistema possam participar desse pro-
cesso, são traçados diagramas para eles, são compreensíveis e não
redundantes. E esses mesmos diagramas estruturam e esclarecem
informações para o próprio analista.
Na prática, existem muitas histórias semelhantes. É impor-
tante entender aqui que o propósito do modelo não é alguma tarefa
hipotética como “descrever a arquitetura, porque isso é tão neces-
sário, tão certo”, e o público-alvo não é uma abstração do tipo
“Pessoas que desejam se familiarizar com software.” Ambos
são algo muito específico, realmente existente no projeto ou próxi-
mo a ele. Afinal, os desenvolvedores de software não podem se dar
ao luxo de criar algo para todas as idades e para todas as pessoas
com o dinheiro do cliente. Tanto o objetivo de modelar quanto o
público que vai trabalhar com diagramas sempre existem, só é im-
portante entender claramente o que são ...
Esta é uma boa prática para direcionar o público-alvo ao qual
seu modelo se destina. Você pode escolher um representante desse
público - uma pessoa específica e conhecida - e criar diagramas
que sejam compreensíveis para ele. No entanto, é importante não
discutir demais sobre seus modelos com ele, pois isso pode criar
um contexto adicional do qual outros usuários dos modelos serão
privados. É útil imaginar essa pessoa trabalhando em modelos -
suas reações, dúvidas, perplexidades, etc. E, a partir disso, corrigir,
corrigir o que foi criado. E, claro, é útil testar suas suposições, mos-
trando a ele o que aconteceu.
Além disso, é importante que o ponto de vista seja “vivo”,
e não inventado por um analista ou copiado impensadamente de
livros e treinamentos na UML. Sem o conhecimento de si mes-
mo, o analista pode criar seu próprio projeto, seus próprios usuá-
rios do sistema, cliente, etc. Ou seja, o analista está gradualmente
4-9
impondo a si mesmo uma certa percepção das pessoas, tarefas
realmente existentes, distorcendo sobremaneira o real estado das
coisas. E é no contexto dessa situação imaginária que ele cria seus
modelos. Mas afinal, pessoas reais, situações reais têm originali-
dade, uma ampla gama de variabilidade. Nesse sentido, o analista
deve ter flexibilidade de consciência, um amplo leque de técnicas,
além de sensibilidade e um desejo sincero de tornar cada projeto
específico em que participa mais harmonioso e adequado.
4.4 Linguagem UML

Frequentemente, o conceito de arquitetura é bastante redu-
zido, o que significa apenas uma descrição dos aspectos principais
e importantes do software, criados, por exemplo, por um arquiteto
ao desenvolver um projeto de sistema. Para tanto, é utilizada a lin-
guagem de modelagem UML (Unified Modeling Language).
Essa linguagem é o resultado do desenvolvimento de meios
para a descrição esquemática de sistemas de software, que se de-
senvolveram a partir dos diagramas de blocos propostos por von
Neumann no final dos anos 40. Ele presumiu que esses esquemas
se tornariam uma linguagem de alto nível para inserir algoritmos
em computadores, mas a evolução das linguagens de programação
seguiu o caminho das linguagens textuais. Apesar disso, os diagra-
mas de blocos se generalizaram na especificação e documentação
de softwares, foram padronizados, mas não receberam ampla apli-
cação prática. No final dos anos 60, em conexão com a busca por
novas ferramentas de desenvolvimento de software, o nascimento
da engenharia de software e seguidores em geral no projeto e de-
senvolvimento de sistemas artificiais, surgiu o termo análise estru-
turada de sistemas. O termo foi cunhado pelo cientista do MIT,
4-10
Douglas Ross, que também propôs um método diagramático para
a análise e projeto de grandes sistemas artificiais.
Com o desenvolvimento de ferramentas de desenvolvimento
orientadas a objetos (final dos anos 80 - meados dos anos
90), a análise estrutural evoluiu para análise e design orientados a
objetos. Um grande número de metodologias apareceu e, gradual-
mente, uma única linguagem de modelagem foi desenvolvida, que
foi consagrada no padrão UML. Aconteceu em 1997.
Tipos de diagramas: O “esqueleto” da UML é a estrutura
diagramática. Cada tipo de diagrama é um tipo de modelo que im-
plementa um ponto de vista específico em um sistema de software.
As visualizações de diagrama não são estritamente necessárias na
UML - você pode misturá-las e criar suas próprias visualizações
de diagrama. No entanto, os tipos padrão de diagramas são uma
propriedade definitiva da engenharia de software, pois refletem a
experiência de muitos pesquisadores e profissionais.
4.4.1 Diagramas estruturais

Os diagramas de classes são projetados para modelar a es-
trutura de aplicativos de classes orientados a objetos, seus atribu-
tos e cabeçalhos de método, herança, bem como relacionamentos
de classe entre si:
● Diagramas de componentes são usados para modelar a

estrutura de componentes de aplicativos distribuídos;
● Diagramas de objetos são usados para modelar fragmen-
tos de um sistema em execução, exibindo instâncias de
classes que realmente existem em tempo de execução e os
valores de seus atributos;
4-11
● Os diagramas de estrutura composta são usados para mo-
delar os elementos estruturais compostos dos modelos -
colaborações, componentes compostos, etc;
● Os diagramas de implantação são projetados para mode-
lar o hardware do sistema com o qual o software está dire-
tamente conectado (hospedado ou interagido);
● Os diagramas de pacote são usados para quebrar modelos
3D em suas partes constituintes e também (tradicional-
mente) para agrupar classes de software simulado quan-
do houver muitos deles.
4.4.2 Diagramas comportamentais

● Diagramas de atividades são usados para especificar os
processos de negócios que o software desenvolvido deve
automatizar, bem como para definir algoritmos complexos;
● Diagramas de caso de uso são para “Puxando” requisitos
de usuários, clientes e especialistas no assunto;
● Diagramas de máquina de estado são usados para definir
o comportamento de sistemas reativos;
● Diagrama de interação:
○ Diagramas de sequência são usados para simular as-
pectos temporais de protocolos de software inter-
nos e externos;
○ Diagrama de visão geral da interação
○ Servem para organizar a hierarquia dos diagramas
de sequência;
○ Os diagramas de comunicação são análogos aos dia-
gramas de sequência, mas são representados de uma
maneira diferente (da maneira usual, gráfico).
4-12
● Os diagramas de tempo são uma espécie de diagramas
de sequência e permitem que você visualize a dinâmica
interna da interação de um conjunto de componentes
do sistema.
Os diagramas de classes são peças fundamentais no desen-

volvimento de softwares. Um exemplo pode ser observado abaixo
na figura 4-3.
Figura 4-3: Diagrama de Classes
Fonte: https://i.stack.imgur.com/hhTO9.jpg
Abaixo, é possível ver um exemplo de diagrama

de componente.
4-13
Figura 4-4: Diagrama de Componentes
Fonte: https://support.content.office.net/pt-br/media/680f-
0334-8dfc-4ddd-bb6c-0ef7a1ecd92e.png
A seguir estão exemplos de diagramas comportamentais

UML. Os diagramas de máquina de estado permitem que você crie
especificações completas do comportamento da telecomunicação,
algoritmos orientados a eventos e gere automaticamente o código
do programa a partir dessas descrições. Um exemplo desse diagra-
ma é mostrado abaixo.
4-14
Figura 4-5: Diagrama de Máquina de Estado
Fonte: https://brunoduduhenrique.files.wordpress.com/
2012/12/estados.gif
Outro tipo importante de diagrama são os diagramas de se-

quência. Eles permitem que você defina os ramos principais de
algoritmos de telecomunicações complexos, bem como desenhe
cadeias de chamadas para aplicativos orientados a objetos que
são programados em termos de objetos, mas geralmente são pro-
jetados em termos de cadeias de chamadas. Um exemplo é mos-
trado abaixo.
4-15
Figura 4-6: Diagrama de Sequência
Fonte: https://sites.google.com/site/mindbitufrpe/_/
rsrc/1467427814583/diagramas/diagrama-de-sequencias/
Sequence%20Diagram%201%20-%20Login.png
4-16
1) Sobre Arquitetura de Software é correto afirmar que:
( ) -a) A estrutura interna do produto componentes e suas cone-

xões os fundamentos da interface do usuário do produto,
bem como a quintessência de conhecimentos e soluções
que são uma ferramenta para desenvolver e gerenciar um
projeto.
( ) -b) A arquitetura é um conceito ponta a ponta ou um conjunto
daqueles para a não superação da entropia e do caos, buscan-
do “engolir” o desenvolvimento tendo em vista a complexida-
de, imaterialidade, consistência e variabilidade do software.
( ) -c) A estrutura interna do produto componentes e suas cone-
xões os fundamentos da interface do usuário do produto,
bem como a quintessência de conhecimentos e soluções que
não são uma ferramenta para desenvolver e nem gerenciar
um projeto.
( ) -d) A arquitetura do produto acaba sendo uma invariante do
projeto, ela não ocorre e surge inesperadamente em suas di-
ferentes partes.
( ) -e) Um análogo dos postulados e leis “simples” das ciências na-
turais, cuja ausência no desenvolvimento de software, de
acordo com Brooks, não é a razão dada a complexidade do
software no sentido de caos, ou seja, complexidade “ruim”.
2) Frequentemente, arquitetura é entendida como, por exemplo, apenas a

estrutura interna do software, expressa em diagramas:
( ) -a) MSF
( ) -b) CMMI
( ) -c) RUP
( ) -d) SOFTWARE
( ) -e) UML
4-17
I) A arquitetura do produto acaba sendo uma invariante do projeto, ela ocor-
re e surge inesperadamente em suas diferentes partes.
II) A maneira de controlar o caos, aumentando a entropia na forma de mu-
danças nos requisitos do sistema terá muita perda de um entendimento cla-
ro pelos desenvolvedores de que tipo de sistema eles estão criando.
III) Muitos projetos criam uma arquitetura original, pois são típicos e / ou
pequenos e se baseiam em tecnologias prontas, amostras arquitetônicas,
modelos de equipe e na estrutura organizacional do projeto.
Estão CORRETAS:
( ) -a) I e II
( ) -b) I, somete
( ) -c) II e III
( ) -e) II, somente

I) Ao desenvolver a arquitetura de software, é importante combinar vários
pontos de vista.
II) O software acaba sendo tão complexo que sua arquitetura não pode ser
construída como um modelo único - muitos aspectos separados devem ser
representados na arquitetura, suas conexões são complexas e mal expres-
sas de forma explícita.
III) A capacidade de ver um assunto de diferentes pontos de vista é a filoso-
fia mais menos importante de uma prática bem-sucedida ao trabalhar com
grandes volumes de informações heterogêneas e complexas.
Estão INCORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) I e III
( ) -e) II e III
4-18
5) Podemos conceituar Ponto de vista como:
( ) -a) É uma determinada visão do sistema, que é realizada para
realizar uma determinada tarefa por qualquer um dos parti-
cipantes do projeto.
( ) -b) A razão da multiplicidade de menos pontos de vista no de-
senvolvimento de software.
( ) -c) A arquitetura do produto que acaba sendo uma invariante
do projeto.
( ) -d) Requisitos funcionais para software, é dada atenção a que
tipo de funcionalidade deve ser implementada, mas os prin-
cípios e detalhes de implementação são omitidos.
( ) -e) Uma caixa preta que implementa não importa de que manei-
ra um determinado conjunto de funcionalidades do usuário.
6) Como deve ser o ponto de vista?
( ) -a) O ponto de vista não precisa ser claramente compreendido

ao criar modelos visuais, como um modelo de caso de uso.
( ) -b) O ponto de vista deve ser claramente compreendido ao criar
modelos visuais, como um modelo de caso de uso.
( ) -c) Requisitos funcionais para software.
( ) -d) Menos pontos de vista no desenvolvimento de software.
( ) -e) Uma caixa preta que implementa não importa de que manei-
ra um determinado conjunto de funcionalidades do usuário.
7) As características mais importantes de uma perspectiva de modelagem são:
( ) -a) O ponto de vista

( ) -b) O software
( ) -c) O ponto de vista e o software
( ) -d) O objetivo e o público-alvo
( ) -e) O ponto de vista e o público-alvo
4-19
I) Uma questão importante que você precisa responder honestamente a si
mesmo no início da modelagem é por que você usa diagramas em particular,
UML.
II) Muitas vezes, por exemplo, ao criar um modelo de caso de uso, não
existe exatamente esse “propósito” de modelagem.
III) É importante entender que o propósito do modelo não é alguma tarefa
hipotética como “descrever a arquitetura, porque isso é tão necessário, tão
certo”, e o público-alvo não é uma abstração do tipo.
Estão CORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) I e III
( ) -e) II e III

I) Você pode escolher um representante desse público - uma pessoa espe-
cífica e conhecida - e criar diagramas que sejam compreensíveis para ele.
II) É importante que o ponto de vista seja “vivo”, e não inventado por um
analista ou copiado impensadamente de livros e treinamentos na UML.
III) Sem o conhecimento de si mesmo, o analista não pode criar seu próprio
projeto, seus próprios usuários do sistema, cliente, etc.
Estão INCORRETAS:
( ) -a) II e III
( ) -b) III, somente
( ) -c) I e II
( ) -d) I, somente
( ) -e) II, somente
4-20
10) Frequentemente, o conceito de arquitetura é bastante reduzido, o que
significa apenas uma descrição dos aspectos principais e importantes
do software, criados, por exemplo, por um arquiteto ao desenvolver um
projeto de sistema. Para tanto, é utilizada a linguagem de modelagem:
( ) -a) UML
( ) -b) MSF
( ) -c) CMMI
( ) -d) RUP
( ) -e) SOFTWARE
4-21
DISCIPLINA:
Engenharia de
Software
UNIDADE 3:
GERENCIAMENTO
DE REQUISITOS E
CONFIGURAÇÃO
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta terceira unidade, daremos orientações sobre o gerenciamento

de requisitos e gerenciamento de configurações em um projeto de desen-
volvimento de software.
Nesta unidade, iremos abordar sobre o levantamento de requisitos ao
se desenvolver um sistema; veremos suas etapas, bem como o que deve
ser feito para garantir que um software será entregue conforme plane-
jado; por fim, veremos um pouco sobre gerenciamento de configurações.
9 Gerenciamento de Requisitos
9 Gerenciamento de Configuração
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 5:
GERENCIAMENTO
DE REQUISITOS
G ER EN C IA MEN TO D E R EQ U ISI TO S
5.1 FUNDAMENTOS
5.1.1 Problema
Por exemplo, construtores constroem casas, embora sejam
diferentes: vários andares, chalés individuais, edifícios de escri-
tórios, etc. - no entanto, todo esse espectro pode muito bem ser
coberto por uma empresa. Mas tudo isso está em casa. Uma em-
presa de construção não precisa construir um disco voador, o hi-
perbolóide do engenheiro Garin, um rover lunar, um sistema de
teletransporte instantâneo etc. E os desenvolvedores de software,
em muitos aspectos, estão exatamente nesta posição.
Existe uma grande variedade de sistemas criados por uma
empresa, uma equipe. Embora agora existam tendências para a
especialização do mercado de desenvolvimento de software, no
entanto, as peculiaridades da economia mundial e muitos outros
motivos levam ao fato de que não existem tantas empresas estrita-
mente especializadas como gostaríamos. Muitas áreas enfrentam
uma grande escassez de programadores individuais e equipes in-
teiras e empresas que são bem versadas em suas especificidades.
Um exemplo de tal área é a televisão, onde o assunto é discutido
abertamente em reuniões de várias comunidades internacionais.
Além disso, o software continua a penetrar cada vez mais em
novas áreas da atividade humana e, neste caso, geralmente é uma
tarefa extremamente difícil formular requisitos adequados.
Mas mesmo se estamos falando de uma área específica, a por-
centagem de recursos novos e exclusivos de sistemas pertencentes
a esta área é alta: em termos de uma combinação de características
do usuário, em termos de recursos de tempo de execução e requisi-
tos de integração, em termos de distribuição de informações sobre
5-3
requisitos entre os funcionários da empresa cliente. Tudo isto tem
em si uma marca muito grande da individualidade do cliente - pes-
soal ou da sua empresa - está fortemente relacionada com as espe-
cificidades do seu negócio, utilizado nesta área de equipamentos.
Além disso, existem dificuldades de entendimento en-
tre o cliente e os programadores, e também na variabilida-
de do software (os requisitos tendem a mudar duran-
te o desenvolvimento).
Como resultado, está longe de ser óbvio que o sistema que
o cliente deseja possa ser feito. É difícil encontrar um gato pre-
to em um quarto escuro, especialmente se ele não estiver lá. Ou a
maneira como os desenvolvedores entenderam e implementaram
a tarefa será conveniente e exigida no mercado.
Os erros e discrepâncias que surgem ao identificar os requisi-
tos do sistema estão entre os mais caros. Requisitos são a compre-
ensão inicial do problema pelos desenvolvedores, que é a base de
todo o desenvolvimento.
Algumas palavras sobre a dificuldade de entendimento entre
o cliente e os desenvolvedores. Isso é afetado pela grande lacuna
entre os programadores e outras pessoas. Em primeiro lugar, por-
que para entender bem o que deve ser um sistema de automação
hospitalar e um sistema de suporte a experimentos químicos, é
necessário trabalhar na área pertinente por um período de tempo
suficiente. Ou, de alguma outra forma, aprender a ver os proble-
mas de uma determinada área de estudo por dentro. Em segundo
lugar, a especificidade da programação como campo de atividade
afeta. Para a maioria dos usuários e clientes, é extremamente difí-
cil articular o conhecimento exato de que os programadores preci-
sam. À pergunta, quantos tipos de análises existem no seu labora-
tório, o médico, na reflexão, responde: “43”. E só então, por acaso,
5-4
o programador esclareceu, existem outros tipos? Claro que existe,
o médico respondeu, apenas eles são raros e podem ser, em certo
sentido, qualquer coisa. Pela primeira vez, ele nomeou apenas al-
guns típicos. Mas, é claro, o sistema de informação deve armazenar
informações sobre todas as análises realizadas no laboratório.
Agora um pouco mais sobre a variabilidade do software e
suas causas.
● A situação no mercado para o qual o sistema foi projetado

está mudando, ou os requisitos para o sistema estão au-
mentando devido às perspectivas de rápida mudança de
venda de um sistema não preparado.
● No decorrer do desenvolvimento, surgem problemas e di-
ficuldades, devido aos quais a funcionalidade final muda
(modificada, cortada).
● O cliente pode mudar sua própria visão do siste-
ma: se entender melhor o que realmente precisa, se des-
cobrir que ele perdeu algo desde o início, se descobrir que
os desenvolvedores não o entenderam dessa forma. Em
geral, tudo pode acontecer, o importante é que agora o
cliente definitivamente deseja algo diferente.
Desnecessário dizer que a volatilidade dos requisitos à me-

dida que o desenvolvimento avança é muito dolorosa para um
produto. Os autores encontraram, por exemplo, uma situação tal
que o departamento de vendas começa a vender ativamente um
sistema ainda não criado, devido ao qual surge um enorme fluxo
de requisitos adicionais. Todos eles não podem ser totalmente im-
plementados; como resultado, o sistema acaba sendo um conjunto
de funcionalidades de demonstração.
5-5
5.2 Tipos e propriedades dos requisitos
Vamos dividir os requisitos em dois grandes grupos - funcio-
nais e não funcionais.
Requisitos funcionais são detalhados como uma descrição
do comportamento e serviços do sistema, sua funcionalidade. Eles
definem o que o sistema deve ser capaz de fazer. Os requisitos não
funcionais não são uma descrição das funções do sistema. Este tipo
de requisito descreve características do sistema como confiabilida-
de, recursos entrega (disponibilidade de um instalador, do-
cumentação), um certo nível de qualidade (por exemplo, para
nova máquina Java isso indicará que ele satisfaz o con-
junto de testes com suporte da Sun). Isso também pode in-
cluir requisitos para ferramentas e o processo de desenvolvimento
de sistema, requisitos para portabilidade, conformidade padrões,
etc. Requisitos desse tipo geralmente se aplicam a todo o sistema
como um todo. Na prática, especialmente especialistas novatos,
eles muitas vezes se esquecem de alguns importantes.
Vamos formular várias propriedades importantes
dos requisitos.
● Clareza, não ambiguidade: compreensão inequívoca

dos requisitos por parte do cliente e dos desenvolvedores.
Isso muitas vezes é difícil de conseguir, uma vez que a for-
malização final dos requisitos, realizada do ponto de vista
das necessidades de desenvolvimento posterior, é difícil
para o cliente ou especialista de domínio que deve inspe-
cionar a exatidão da formalização.
● Completude e consistência.
● Nível de detalhe necessário: Os requisitos devem ter
um nível de detalhe claramente compreendido, um estilo
5-6
de descrição, uma forma de formalização: ou esta é uma
descrição das propriedades da área de assunto para a qual
o software se destina, ou esta é uma tarefa técnica que está
anexada ao contrato, ou esta é uma especificação de pro-
jeto que deve ser esclarecida no futuro, com projeto deta-
lhado. Ou é outra coisa. Também é importante ver e com-
preender claramente aqueles a quem esta descrição dos
requisitos se destina, caso contrário, mal-entendidos e di-
ficuldades subsequentes não podem ser evitados. Na ver-
dade, muitos especialistas diferentes estão envolvidos no
desenvolvimento de software - engenheiros, programado-
res, testadores, representantes do cliente, possivelmente
futuros usuários - e todos eles têm formação, habilidades
profissionais e especialização diferentes, frequentemente
falam línguas diferentes. Também é importante aqui que
os requisitos sejam tão abstratos e independentes de im-
plementação quanto possível.
● Rastreabilidade: é importante ver este ou aquele re-
quisito em vários modelos, documentos e, finalmente,
no código do sistema. E muitas vezes surgem perguntas
como - “Quem sabe por que decidimos que tal e tal módu-
lo deveria funcionar da seguinte maneira ...?”. A rastre-
abilidade dos requisitos funcionais é obtida dividindo-os
em requisitos elementares individuais, atribuindo iden-
tificadores a eles e criando um modelo de rastreamento
que, idealmente, deve se estender ao código do programa.
Por exemplo, gostaria de saber onde alterar o código se
esse requisito mudou. Na prática, a rastreabilidade formal
completa é difícil de alcançar, uma vez que a lógica e a
estrutura da implementação do sistema podem ser mui-
to diferentes daquelas para o modelo de requisitos. Como
5-7
resultado, um requisito acaba sendo fortemente “man-
chado” no código e uma ou outra parte do código pode
afetar muitos requisitos.
● Testabilidade e verificabilidade: é necessário que
existam formas de testar e verificar este requisito. Além
disso, ambos os aspectos são importantes, uma vez que
o cliente muitas vezes pode verificar algo, mas testar esse
requisito é muito difícil ou impossível devido ao acesso
limitado (por exemplo, por motivos de segurança) ao
ambiente do sistema para a equipe de desenvolvimento.
Portanto, procedimentos de verificação são necessários -
realização de testes, realização de inspeções, realização de
verificação formal de alguns dos requisitos, etc. Também
é necessário determinar a “barra” de qualidade (quanto
maior a qualidade, mais caro ela custa!) Do projeto esta-
vam claramente cientes do que foi testado e do que ainda
não foi testado.
● Modificabilidade: Define os procedimentos para fazer
alterações nos requisitos.
5.3 Opções de formalização de requisitos

De modo geral, os requisitos como tais são algum tipo de
abstração. Na prática real, eles sempre existem na forma de algum
tipo de representação - um documento, um modelo, uma especifi-
cação formal, uma lista, etc. Os requisitos são importantes como
tais, porque eles se estabelecem na forma de compreensão pelos
desenvolvedores das necessidades do cliente e futuros usuários do
sistema que está sendo criado. Mas como existem muitos aspectos,
tipos de atividades e fases de desenvolvimento diferentes em um
5-8
projeto de software, esse entendimento pode assumir represen-
tações muito diferentes. Cada apresentação de requisitos execu-
ta uma tarefa específica, por exemplo, serve como uma “ponte”,
fixando um acordo entre diferentes grupos de especialistas, ou é
usada para a gestão operacional de um projeto (é rastreado em
qual fase de implementação um determinado requisito é,
quem é responsável por isso, etc.), ou usado para verificação
e teste orientado a modelo. E no primeiro, no segundo e no terceiro
exemplo, estamos lidando com requisitos, mas eles serão formali-
zados de maneiras diferentes.
Assim, a formalização de requisitos em um projeto pode ser
muito diferente - depende do seu tamanho, do processo de desen-
volvimento adotado, das ferramentas utilizadas, bem como das ta-
refas que os requisitos formalizados resolvem. Além disso, várias
formalizações podem existir em paralelo que resolvem problemas
diferentes. Vamos considerar as opções.
● Formulação informal de requisitos em corres-

pondência por e-mail: Funciona bem em pequenos
projetos, quando o cliente está envolvido em desenvol-
vimento (por exemplo, a equipe subcontrata). Também
é bom com esse estilo, quando há entendimento mútuo
entre o cliente e a equipe, ou seja, não são exigidas forma-
lidades desnecessárias. No entanto, e-mails em tal situa-
ção muitas vezes acabam sendo documentos importantes
- é importante ser capaz de conduzir correspondência co-
mercial, resumir, armazenar cartas importantes e usá-las
em caso de desacordo. Também é importante entender a
tempo quando esse método para de funcionar e aborda-
gens mais formais são necessárias.
5-9
● Requisitos de documentos: descrição da área de as-
sunto e suas propriedades, termos de referência como um
anexo ao contrato, especificações funcionais para desen-
volvedores, etc.
● Requisitos como um gráfico com dependências em uma
das ferramentas de suporte de requisitos. Essa visão é
conveniente quando os requisitos mudam com frequên-
cia, quando os requisitos são atendidos, quando as tarefas,
pessoas, testes e código estão “amarrados” aos requisitos.
Também é importante ser capaz de criar facilmente esses
gráficos a partir de documentos de texto e vice-versa, criar
documentos de apresentação para esses gráficos.
● Modelo de requisitos formais para verificação, teste base-
ado em modelo, etc.
Assim, cada forma de apresentar requisitos deve responder

às seguintes questões: quem é o consumidor, o usuário desta visão,
como exatamente, para que finalidade esta visão é utilizada. Há
alguns erros ao documentar os requisitos. Listamos uma série de
erros encontrados na preparação de especificações técnicas e ou-
tros documentos com requisitos.
● Descrição de soluções possíveis em vez de requisitos.

● Requisitos difusos que não permitem verificação
inequívoca, deixam insinuações, têm um toque de
conselhos, discussões, recomendações: “É possível
que faça sentido implementar também ...”, “etc.”.
● Ignorar o público para o qual os requisitos são apresen-
tados. Por exemplo, se uma especificação é elaborada por
um engenheiro de cliente, então muitas vezes há uma su-
perabundância de informações sobre o equipamento com
5-10
o qual o sistema de software deve funcionar, não há glos-
sário de termos e definições de conceitos básicos, vários
sinônimos são usados, etc. Ou há muito preconceito em
relação à programação, o que torna esta especificação in-
compreensível para todos os não programadores.
● A liberação de aspectos importantes relacionados a requi-
sitos não funcionais, em particular, informações sobre o
ambiente do sistema, o momento da disponibilidade de
outros sistemas com os quais este deve interagir. Este úl-
timo ocorre, por exemplo, quando um determinado siste-
ma de software faz parte de um projeto maior. Os proble-
mas são típicos durante a criação de sistemas de software
e hardware, quando o hardware não tem tempo para ser
atempado e o software não pode ser testado, mas isso não
está previsto em termos e requisitos.
5.4 Ciclo de requisitos

O Conjunto de conhecimentos em engenharia de software
do SWEBOK, Software Engineering Body of Knowledge, define
as seguintes atividades de requisitos:
● Elicitação de requisitos, com o objetivo de identificar to-

das as fontes possíveis de requisitos e restrições à opera-
ção do sistema e extrair requisitos dessas fontes.
● Análise de requisitos, cujo objetivo é a detecção e elimi-
nação de contradições e ambiguidades nos requisitos, seu
esclarecimento e sistematização.
● Especificação de requisitos, como resultado dessas ativi-
dades, os requisitos devem ser formalizados na forma de
um conjunto estruturado de documentos e modelos, que
5-11
podem ser sistematicamente analisados, avaliados sob
diferentes pontos de vista e, em última instância, devem
ser aprovados como a formulação oficial dos requisitos
do sistema.
● Validação de requisitos, que resolve o problema de ava-
liar a inteligibilidade dos requisitos formulados e suas ca-
racterísticas necessárias para desenvolver softwares com
base neles, em primeiro lugar, a consistência e completu-
de, bem como o cumprimento dos padrões corporativos
de documentação técnica.
5-12
1) Observe as afirmações abaixo sobre Gerenciamento de Requisitos:

I) Existe uma grande variedade de sistemas criados por uma empresa, uma
equipe.
II) Embora agora existam tendências para a especialização do mercado de
desenvolvimento de software, no entanto, as peculiaridades da economia
mundial e muitos outros motivos levam ao fato de que existem tantas em-
presas estritamente especializadas como gostaríamos.
III) Muitas áreas enfrentam uma grande escassez de programadores in-
dividuais e equipes inteiras e empresas que são bem versadas em suas
especificidades.
Estão INCORRETAS:
( ) -a) II e III
( ) -b) II, somente
( ) -c) I e III
( ) -e) I, somente
2) Observe as afirmações abaixo sobre Gerenciamento de Requisitos:

I) O software continua a penetrar cada vez mais em novas áreas da atividade
humana e, neste caso, geralmente é uma tarefa extremamente difícil formu-
lar requisitos adequados.
II) Existem dificuldades de entendimento entre o cliente e os programado-
res, e também na variabilidade do software os requisitos tendem a mudar
durante o desenvolvimento.
III) Os erros e discrepâncias que surgem ao não identificar os requisitos do
sistema estão entre os mais caros. Requisitos são a compreensão inicial do
problema pelos desenvolvedores, que é a base de todo o desenvolvimento.
Estão CORRETAS:
5-13
( ) -a) I e II
( ) -b) II, somente
( ) -c) II e III
( ) -e) I, somente
3) Requisitos Funcionais são:
( ) -a) Uma descrição das funções do sistema.

( ) -b) A situação no mercado para o qual o sistema foi projetado
está mudando.
( ) -c) Detalhados como uma descrição do comportamento e servi-
ços do sistema, sua funcionalidade.
( ) -d) Especificidade da programação como campo de atividade
afeta.
( ) -e) Sistema de informação
4) Requisitos não funcionais são:
( ) -a) Detalhados como uma descrição do comportamento e servi-

ços do sistema, sua funcionalidade.
( ) -b) Uma descrição das funções do sistema.
( ) -c) A situação no mercado para o qual o sistema foi projetado
está mudando.
( ) -d) Sistema de informação
( ) -e) Especificidade da programação como campo de atividade
afeta.
5) Na prática, especialmente especialistas novatos, eles muitas vezes se

esquecem de alguns importantes. Uma das propriedades importantes
dos requisitos é:
( ) -a) A situação no mercado para o qual o sistema foi projetado

está mudando, ou os requisitos para o sistema estão aumen-
tando devido às perspectivas de rápida mudança de venda
de um sistema não preparado.
5-14
( ) -b) Surgi problemas e dificuldades, devido aos quais a funciona-
lidade final muda modificada, cortada.
( ) -c) O cliente pode mudar sua própria visão do sistema.
( ) -d) A volatilidade dos requisitos à medida que o desenvolvimen-
to avança
( ) -e) Clareza, não ambiguidade: compreensão inequívoca dos re-
quisitos por parte do cliente e dos desenvolvedores.
6) A respeito de Rastreabilidade é correto afirmar que:
( ) -a) Compreensão inequívoca dos requisitos por parte do cliente

e dos desenvolvedores.
( ) -b) Os requisitos devem ter um nível de detalhe claramen-
te compreendido, um estilo de descrição, uma forma de
formalização.
( ) -c) É importante ver este ou aquele requisito em vários mode-
los, documentos e, finalmente, no código do sistema.
( ) -d) É necessário que existam formas de testar e verificar este
requisito.
( ) -e) Define os procedimentos para fazer alterações nos requisitos.

I) De modo geral, os requisitos como tais são algum tipo de abstração.
II) Na prática real, os requisitos nem sempre existem na forma de
representação
III) Os requisitos não são importantes como tais, porque eles se estabele-
cem na forma de compreensão pelos desenvolvedores das necessidades do
cliente e futuros usuários do sistema que não estão sendo criado.
Estão INCORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) I e III
( ) -d) II e III
( ) -e) III, somente
5-15
8) Cada apresentação de requisitos executa uma tarefa específica. Um
exemplo disso é:
( ) -a) Serve como uma “ponte”, fixando um acordo entre diferen-

tes grupos de especialistas.
( ) -b) Não é usada para a gestão operacional de um projeto.
( ) -c) É rastreado em qual fase de implementação um determina-
do requisito é, quem não é responsável por isso, etc.),
( ) -d) Não usado para verificação de teste orientado a modelo.
( ) -e) Define os procedimentos para fazer alterações nos requisitos.
9) Assim, a formalização de requisitos em um projeto pode ser muito:
( ) -a) Procedimentos para fazer alterações nos requisitos.

( ) -b) Para verificação de teste orientado a modelo.
( ) -c) Diferente - depende do seu tamanho, do processo de desen-
volvimento adotado, das ferramentas utilizadas, bem como
das tarefas que os requisitos formalizados resolvem.
( ) -d) Sistema de informação
( ) -e) Especificidade da programação como campo de atividade
afeta
10) Além disso, várias formalizações podem existir em paralelo que resol-
vem problemas diferentes. Um exemplo dessas opções são:
( ) -a) Clareza, não ambiguidade

( ) -b) Completude e consistência.
( ) -c) Nível de detalhe necessário
( ) -d) Rastreabilidade
( ) -e) Requisitos de documentos
5-16
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 6:
GERENCIAMENTO DE
CONFIGURAÇÃO
G ER EN C IA MEN TO D E CO N FIG U RAÇÃO

6.1 6.1 Problema
Todos sabem que existem armazéns em grandes empresas
industriais, em lojas, editoras de livros, etc. A principal tarefa do
warehouse é fornecer armazenamento e acesso aos ativos tangí-
veis: mercadorias, produtos, livros, etc. Ou seja, são tantos os ati-
vos tangíveis diferentes que é necessário um serviço especial para
sua contabilidade. Acontece que não basta colocar, por exemplo,
todos os livros disponíveis na editora em uma sala especial e distri-
buí-los aos donos da circulação quando vierem buscá-los. Existem
muitos livros e o procedimento para a emissão de cópias não é in-
teiramente trivial. O proprietário deve trazer um grande número
de documentos de acompanhamento, e todos eles devem ser ve-
rificados antes da emissão dos livros. E no próprio armazém é ne-
cessário manter a ordem para que seja possível encontrar rapida-
mente os livros necessários (como mostra a experiência, eles
podem ficar lá por muito tempo). Um procedimento ainda
mais complicado para trabalhar com livros na biblioteca - também
são adicionados catálogos, livrarias distribuídas, a necessidade de
manter um bom estado dos livros, e também controlar o seu retor-
no à biblioteca após um determinado período. Um armazém fun-
ciona de forma semelhante em qualquer planta, fábrica, etc.
Considere agora um projeto de desenvolvimento de sof-
tware. O que há nele um análogo dos ativos tangíveis na produ-
ção convencional? Definitivamente, não as mesas e cadeiras que
os desenvolvedores usam. E nem mesmo computadores, peças
sobressalentes para eles e outros equipamentos. A contabilidade
e o controle, semelhantes ao controle do armazém, exigem arqui-
vos do projeto. Existem muitos deles em um projeto de software
- centenas e milhares, mesmo para projetos relativamente peque-
nos. É muito fácil criar um novo arquivo. Muitas tecnologias de
6-2

programação suportam o estilo quando, por exemplo, um arquivo
separado é criado para cada classe.
Um arquivo é uma unidade virtual de informação. Qual é a
principal diferença entre um arquivo e unidades de contabilidade
de material? O fato de um arquivo poder ter uma versão, e mais de
uma, e ser muito fácil gerar essas versões - basta copiar este arqui-
vo para outro local no disco. Considerando que os itens de material
existem no depósito por conta própria e não existe um conceito
de versão para eles. Sim, pode haver vários itens do mesmo tipo,
diferentes esboços de produtos com diversos graus de prontidão.
Mas tudo isso não está certo. E a versão do arquivo não é um ob-
jeto muito simples. Como uma versão difere da outra? Algumas
linhas de texto ou conteúdo completamente atualizado? E qual das
duas ou mais versões é mais importante, melhor? Somado a isso
está o fato de que muitos produtos de trabalho podem consistir em
um conjunto de arquivos, e cada um deles pode ter várias versões.
Como faço para construir a versão correta do produto?
Como resultado, eventos místicos e misteriosos começam a
ocorrer no projeto de software.
● Um programa totalmente testado não funciona em tes-

tes demonstrativos
● A funcionalidade que o cliente vinha solicitando e que fi-
nalmente foi adicionada ao produto, e a nova versão foi
cerimoniosamente enviada ao cliente, desapareceu miste-
riosamente do produto.
● O programa funciona no computador do desenvolvedor,
mas não no do cliente.
A resposta é simples - é tudo sobre as versões dos arquivos.

Onde tudo é bom, existem arquivos de uma versão, e onde está
6-3

tudo ruim, outra. Mas o problema é que “a versão completa do
produto” é um conceito abstrato. Na verdade, existem versões de
arquivos individuais. Um ou vários arquivos na remessa do produ-
to têm a versão errada - isso é tudo, é ruim. É necessário controlar
as versões dos arquivos, caso contrário, esse misticismo pode se
tornar um grande problema.
Isso inibe seriamente o trabalho interno. Tanto os desenvol-
vedores quanto os testadores trabalham com diferentes versões do
sistema, ou a montagem final do sistema requer esforços especiais
de toda a equipe. Além disso, são possíveis problemas ao nível da
gestão. Várias situações curiosas em que a funcionalidade declara-
da está faltando ou não funciona (mais uma vez, os arquivos
errados foram enviados!), Podem prejudicar muito o relacio-
namento com o cliente. Um cliente insatisfeito pode até exigir uma
compensação monetária pelo fato de que os erros que surgem são
corrigidos demais em uma dívida. E não demorará muito aqui,
quando os desenvolvedores não conseguirem reproduzir e corrigir
o erro, já que não podem determinar exatamente de qual código-
-fonte esta versão foi compilada!
Assim, fica claro que em projetos de software, atividades es-
peciais são necessárias para manter os ativos do arquivo do projeto
em ordem. Isso é chamado de gerenciamento de configuração.
Vamos destacar duas tarefas principais no gerenciamento de
configuração - controle de versão e gerenciamento de montagem.
O primeiro é responsável pelo controle de versão dos arquivos e é
realizado no projeto com base em pacotes de software especiais -
ferramentas de controle de versão. Há um grande número dessas
ferramentas - Microsoft Visual SourceSafe, IBM ClearCase, cvn,
subversion, etc. O gerenciamento de compilação é um processo
automatizado de transformação de códigos-fonte de software em
6-4

um pacote de módulos executáveis que leva em conta várias confi-
gurações de projeto, configurações de compilação, e está integrado
ao processo de teste automatizado. Este procedimento é uma fer-
ramenta poderosa de integração de projetos, a base para o desen-
volvimento iterativo.
6.2 Unidades de gerenciamento de

configuração
Então, o que gerenciamos nesta atividade? Algum arquivo
que está no projeto? Não, não por qualquer um, mas apenas por
aqueles que mudam. Por exemplo, os arquivos com o software
adquirido usado em um projeto devem permanecer silenciosa-
mente em discos CD ou em uma rede local. Livros, documentos
com padrões externos usados no projeto (por exemplo, em te-
lecomunicações existem muitos padrões diferentes para
interfaces de rede), etc., também devem ser simplesmente ar-
mazenados onde qualquer um possa levá-los. Via de regra, não há
muitas dessas informações no projeto, mas, é claro, deve estar em
ordem. No entanto, isso não requer um tipo especial de atividade
no projeto.
Assim, o gerenciamento de configuração lida com produtos
que mudam no processo, consistindo em conjuntos de arquivos.
Esses produtos são comumente chamados de itens de gerencia-
mento de configuração. Aqui estão alguns exemplos:
1. Documentação do usuário;
2. Documentação do projeto;
3. Códigos-fonte de software;
4. Pacotes de teste;
6-5

5. Pacotes de instalação de software;
6. Relatórios de teste.
Cada unidade de gerenciamento de configuração

deve ter o seguinte:
● A estrutura é uma coleção de arquivos. Por exemplo, a do-

cumentação do usuário em html deve incluir um arquivo
de índice e um conjunto de arquivos html, bem como um
conjunto de imagens renderizadas (arquivos gif ou jpeg).
Esta estrutura deve ser bem definida e rastreada no ge-
renciamento de configuração - que todos os arquivos não
foram perdidos e estão presentes, têm a mesma versão,
links corretos entre si, etc.
● A pessoa responsável e possivelmente o grupo de quem
as desenvolve, bem como o grupo mais amplo e menos
responsável de quem usa essas informações. Por exemplo,
um determinado componente de software pode ser usado
por muitos desenvolvedores em um projeto, mas alguém
deve ser responsável por seu desenvolvimento, correção
de erros, etc.
● A prática de gerenciamento de configuração: quem
e em que modo, bem como em que lugar carrega uma
nova versão de um controle de configuração para uma
ferramenta de controle de versão, regras para nomear e
comentar um item nesta versão, manipulações posterio-
res com ele lá, etc. Regras de nível superior relacionadas,
por exemplo, com as regras para alterar testes e pacotes
de teste ao alterar o código. No entanto, em algum lugar
aqui está a linha divisória entre o gerenciamento de confi-
guração e outras atividades no projeto.
6-6

● Procedimento automático para verificar a inte-
gridade de um elemento: por exemplo, montagem
para códigos-fonte de programas. Nem todos os elemen-
tos têm, por exemplo, documentação, os pacotes de teste
podem não ter.
Os controles de configuração podem formar uma hierarquia.

Um exemplo é mostrado na Figura 6-1.
Figura 6-1: Controle de configuração
6.3 Controle de Versão

Controle de versão do arquivo: Como os programado-
res lidam com um grande número de arquivos, muitos arquivos
em um momento podem ser necessários para várias pessoas e é
importante que todos eles constituam constantemente uma única
6-7

versão, pelo menos compilada do produto, é necessário que traba-
lhe com arquivos com o código-fonte seja estabelecido. Também
pode funcionar com outros tipos de arquivos. Nessa situação, os
arquivos acabam sendo os elementos de gerenciamento de confi-
guração mais baixos (na hierarquia de inclusão).
Controle de versão de objetos de configuração compostos:
Conceito “Ramos” do projeto. Várias versões do sistema podem
existir simultaneamente - tanto no sentido de diferentes clientes,
etc. (por assim dizer, em um sentido amplo e real), e no
sentido de um projeto, um cliente, mas como um conjunto dife-
rente de fonte códigos. Em ambos os casos, diferentes ramifica-
ções são geradas no controle de origem. Detenhamo-nos um pouco
mais em detalhes no segundo caso.
Cada ramificação contém uma imagem completa do código-
-fonte e outros artefatos de controle de origem. Cada ramificação
pode se desenvolver de forma independente ou pode ser integrada
a outras ramificações em determinados pontos. Durante o proces-
so de integração, as alterações feitas em uma das filiais são transfe-
ridas de forma semiautomática para a outra. Como exemplo, con-
sidere a seguinte estrutura de ramificação para um projeto.
● V1.0 é o branch correspondente ao release lançado. Alte-

rações nessas filiais são proibidas e armazenam a imagem
do código do sistema no momento do lançamento.
● Fix V1.0.1: Ramificação correspondente ao fix pack libe-
rado para uma versão específica. Essas ramificações são
bifurcadas da versão original, não da ramificação princi-
pal, e são congeladas assim que o fix pack é liberado.
● Next (V1.1): o branch correspondente ao lançamento,
que está sendo preparado para lançamento e está em está-
gio de estabilização. Para tais ramos, via de regra, existem
6-8

regras mais rígidas e o trabalho nelas é realizado de forma
mais formal.
● Mainline: um ramo que corresponde à direção principal
do desenvolvimento do projeto. À medida que amadure-
ce, é a partir desse ramo que se ramificam os ramos dos
próximos lançamentos.
● O WCF Experiment é um branch criado para testar al-
guma solução técnica, mudar para uma nova tecnologia
ou fazer um grande lote de alterações que podem quebrar
o código por um longo tempo. Tais branches, como regra,
são disponibilizados apenas para um certo círculo de de-
senvolvedores e são eliminados após a conclusão do tra-
balho após a integração com o branch principal.
6.4 Gestão de Montagem

Então, por que o procedimento para compilar e criar arqui-
vos “exe”, “dll” a partir do código-fonte do projeto é um procedi-
mento tão importante? Porque isso é feito várias vezes ao dia por
cada desenvolvedor em seu próprio computador, com sua própria
versão do projeto. Quando isso for diferente:
● Um conjunto de subprojetos coletados pelo desenvolve-

dor; ele pode coletar não todo o projeto, mas apenas uma
parte dele; a outra parte não é usada por ele ou não foi
reconstruída há muito tempo, mas na verdade mudou há
muito tempo;
● As opções de compilação são diferentes.
6-9

Além disso, se você não coleta regularmente a versão fi-
nal do projeto, a integração geral pode revelar muitos proble-
mas diferentes:
● Discrepância entre as diferentes partes do projeto;

● A presença de erros específicos que surgiram devido ao
fato de que projetos individuais foram desenvolvidos sem
levar em consideração os parâmetros de compilação (em
particular, a transição da depuração para a versão de lan-
çamento no Visual Studio é frequentemente acompanha-
da pelo aparecimento de vários problemas).
Nesse sentido, o procedimento de construção do projeto é

frequentemente automatizado, ou seja, não é executado a partir do
ambiente de desenvolvimento, mas a partir de um script especial
- o script de construção. Este script é usado quando o desen-
volvedor precisa de uma compilação completa de todo o projeto.
Também é utilizado no procedimento de integração contínua - ou
seja, na montagem regular de todo o projeto (via de regra, todas
as noites). Como regra, o procedimento de integração contínua
inclui testes de regressão e, frequentemente, a criação de pacotes
de instalação. O esquema geral de montagem automatizada é mos-
trado na Figura 6-2.
6-10

Figura 6-2: Esquema geral de montagem automatizada
6.5 Conceito de linha de base

A linha de base é a linha de base, a última versão completa de
algum produto de desenvolvimento, como documentação, código
do programa, etc. Entende-se que o desenvolvimento não prosse-
gue em um fluxo contínuo, mas com a fixação de resultados inter-
mediários na forma da versão oficial atual do ativo desenvolvido. A
adoção de tal versão é acompanhada por ações adicionais para es-
tilização, suavização, teste, incluindo apenas fragmentos acabados,
etc. Este resultado pode ser visualizado, fornecido aos testadores,
repassado ao cliente, etc. A linha de base é uma boa maneira de
sincronizar o trabalho em grupo.
A linha de base pode ser tão simples quanto uma ramificação
no controle de origem, onde os desenvolvedores mantêm a versão
atual de seu código-fonte. O único requisito neste caso pode ser
apenas a compilação geral do projeto. Mas manter uma linha de
base pode ser um procedimento formal complexo, conforme mos-
trado na Figura 6-3.
6-11

Figura 6-3: Exemplo de Linha de Base
A linha de base também pode ser suportada por integração

contínua. É importante que o Baseline (especialmente no caso
de ativos de software) não seja instalado muito cedo. Primei-
ro, você precisa escrever uma certa quantidade de código para ter
algo para integrar. Além disso, no início, muita atenção é dada ao
desenvolvimento de soluções arquitetônicas básicas, e uma versão
holística não é necessária. Mas a partir de certo momento é sim-
plesmente necessário. Que momento é este - para os membros da
equipe decidirem. Finalmente, existem projetos onde a montagem
automática não é necessária - são projetos simples desenvolvidos
por um pequeno número de participantes, onde não há um grande
número de códigos-fonte de programas, projetos, parâmetros de
compilação complexos.
6-12
1) Observe as afirmações abaixo sobre Gerenciamento de configuração:

I) A principal tarefa do warehouse é fornecer armazenamento e acesso aos
ativos tangíveis: mercadorias, produtos, livros, etc.
II) A contabilidade e o controle, semelhantes ao controle do armazém, exi-
gem arquivos do projeto.
III) Muitas tecnologias de programação não suportam o estilo quando, por
exemplo, um arquivo separado é criado para cada classe.
Estão INCORRETA:
( ) -b) I e III
( ) -c) I e II
( ) -d) II, somente
( ) -e) II e III
2) Um arquivo é uma unidade virtual de informação. Qual é a principal dife-

rença entre um arquivo e unidades de contabilidade de material?
( ) -a) Fornecer armazenamento e acesso aos ativos tangíveis.

( ) -b) É necessário um serviço especial para sua contabilidade.
( ) -c) O fato de um arquivo poder ter uma versão, e mais de uma, e
ser muito fácil gerar essas versões - basta copiar este arquivo
para outro local no disco.
( ) -d) Muitos livros e o procedimento para a emissão de cópias não
é inteiramente trivial.
( ) -e) Funciona de forma semelhante em qualquer planta, fábrica,
etc.
6-13
I) Um programa totalmente testado funciona em testes demonstrativos
II) A funcionalidade que o cliente vinha solicitando e que finalmente foi adi-
cionada ao produto, e a nova versão foi cerimoniosamente enviada ao clien-
te, desapareceu misteriosamente do produto.
III) O programa funciona no computador do desenvolvedor, mas não no do
cliente.
Estão CORRETAS:
( ) -a) I e II
( ) -b) I, somente
( ) -c) I e III
( ) -e) II e III
4) Assim, o gerenciamento de configuração lida com produtos que mudam

no processo, consistindo em conjuntos de arquivos. Esses produtos são
comumente chamados de itens de:
( ) -a) Relatórios de teste.

( ) -b) Gerenciamento de configuração
( ) -c) Códigos-fonte de software
( ) -d) Pacotes de instalação de software;
( ) -e) Documentação do projeto;
5) É considerado um exemplo de gerenciamento de configuração:
( ) -a) Pacotes de instalação de software

( ) -b) Um programa totalmente testado
( ) -c) A funcionalidade
( ) -d) O programa
( ) -e) O gerenciamento de compilação
6-14
6) Cada unidade de gerenciamento de configuração deve ter:
( ) -a) Um programa totalmente testado não funciona em testes
demonstrativos
( ) -b) A funcionalidade que o cliente vinha solicitando e que final-
mente foi adicionada ao produto, e a nova versão foi cerimo-
niosamente enviada ao cliente, desapareceu misteriosamen-
te do produto.
( ) -c) O programa funcionando no computador do desenvolvedor,
mas não no do cliente.
( ) -d) A prática de gerenciamento de configuração - quem e em
que modo, bem como em que lugar carrega uma nova ver-
são de um controle de configuração para uma ferramenta de
controle de versão, regras para nomear e comentar um item
nesta versão, manipulações posteriores com ele lá, etc.
( ) -e) Documentação do usuário.
7) Como os programadores lidam com um grande número de arquivos, mui-

tos arquivos em um momento podem ser necessários para várias pesso-
as e é importante que todos eles constituam constantemente uma única
versão. Estamos falando de:
( ) -a) Gerenciamento de configuração

( ) -b) Controle de Versão
( ) -c) Pacotes de instalação de software;
( ) -d) Pacotes de teste;
( ) -e) Documentação do projeto

I) Controle de versão de objetos de configuração compostos: Conceito “Ra-
mos” do projeto.
II) Várias versões do sistema podem não existir simultaneamente tanto no
sentido de diferentes clientes, etc.
III) Durante o processo de integração, as alterações feitas em uma das fi-
liais são transferidas de forma semiautomática para a outra.
Estão INCORRETAS:
6-15
( ) -a) I e III
( ) -c) II, somente
( ) -d) II e III
( ) -e) I, somente
9) É considere a seguinte estrutura de ramificação para um projeto:
( ) -a) V1.0
( ) -b) Controle de versão
( ) -c) NextP (V1.1)
( ) -d) Pacotes de teste
( ) -e) O programa
10) O V1.0 é:
( ) -a) Ramificação correspondente ao fix pack liberado para uma
versão específica.
( ) -b) O branch correspondente ao lançamento, que está sendo pre-
parado para lançamento e está em estágio de estabilização.
( ) -c) O branch correspondente ao release lançado.
( ) -d) Um ramo que corresponde à direção principal do desenvol-
vimento do projeto.
( ) -e) Um branch criado para testar alguma solução técnica, mu-
dar para uma nova tecnologia ou fazer um grande lote de
alterações que podem quebrar o código por um longo tempo.
6-16
DISCIPLINA:
Engenharia de
Software
UNIDADE 4:
GERENCIAMENTO DE
PROJETO E PLANEJAMENTO
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta quarta unidade, daremos orientações sobre gerenciamento de

projetos e planejamento do mesmo, a fim de garantir êxito no desenvol-
vimento de um software.
Nesta unidade, iremos abordar sobre a importância do gerencia-
mento de projetos para o desenvolvimento de software. Estudaremos
as principais técnicas usadas para tal, além de entendermos o papel do
planejamento neste contexto.
9 Gerenciamento de Projetos
9 Organização da Equipe
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 7:
GERENCIA DE PROJETOS
G ER EN C IA D E PR O JETO S
7.1 FUNDAMENTOS
Em várias fontes, você pode encontrar diferentes defi-
nições do conceito de “gerenciamento”:
● Um elemento, uma função de sistemas organizados de

várias naturezas (biológica, social, técnica), garantindo
a preservação da sua estrutura específica, a manutenção
do modo de atividade, a implementação dos seus progra-
mas e objetivos;
● Liderança, direção da atividade de alguém. (www.
mega.km.ru);
● Uma mudança no estado de um objeto, sistema ou pro-
cesso que leva à realização do objetivo definido (dicioná-
rio da cibernética).
Do ponto de vista da última definição (mais aceitável para

nós), o essencial é:
● A presença de uma meta de controle mensurável (fun-

ção meta);
● A presença (possibilidade) de controle (ação de controle
afetando a mudança na função da meta);
● A presença de medidas do estado de um objeto ou processo;
● Gestão limitada.
7.2 Conceitos básicos

A palavra “projeto” vem do latim projectus, que significa “jo-
gado para a frente”. Recentemente, a palavra “projeto” tem sido
usada com bastante frequência (e muitas vezes em vão): um
7-3
projeto para tornar as ruas da cidade mais verdes, um projeto para
treinamento de pessoal, um projeto para reorganizar as atividades
de uma empresa, etc. Existem várias definições do projeto:
Um projeto é uma série arbitrária de ações ou tarefas com
um objetivo específico que será alcançado no âmbito de algumas
tarefas, caracterizado por certas datas de início e fim, limites de
financiamento e recursos.
Um projeto é um trabalho pontual que possui datas de início
e término específicas, objetivos claramente definidos, oportunida-
des e, como regra, um orçamento.
Um projeto é um esforço temporário usado para criar um
produto ou serviço exclusivo com uma data de início e término es-
pecífica que é diferente de atividades contínuas e repetidas e re-
quer melhoria de desempenho progressiva.
Essas definições refletem, em vários graus, as se-
guintes características definidoras do projeto:
● Objetivo do projeto: A presença de um resultado final,

produção, produto bem definido, definido em termos de
custo, qualidade e prazo de entrega.
● Singularidadeb: Um projeto é um empreendimento
único que não se repetirá. Mesmo projetos “repetitivos”,
por exemplo, para a construção de outro empreendimen-
to de acordo com a mesma documentação de projeto, di-
ferem significativamente entre si nos recursos utilizados e
no ambiente de implementação.
● Limitações de tempo... O projeto tem começo e fim.
Sua implementação requer uma concentração temporária
de recursos. Conforme a necessidade, os recursos são usa-
dos para outros fins.
7-4
● Recursos limitadosalocado para a implementação do
projeto (financeiro, humano, material).
● Complexidade... Para atingir os objetivos do projeto,
existem muitas tarefas a serem resolvidas. Os relaciona-
mentos entre as tarefas podem ser bastante complexos,
especialmente se houver muitas tarefas no projeto.
● Incerteza: A capacidade de atingir a meta dentro do pra-
zo especificado com os recursos alocados não é garantida
com antecedência.
● Previsibilidade... Conforme o projeto avança, a neces-
sidade de certos recursos muda. Essa mudança ocorre em
uma determinada sequência previsível determinada pelo
ciclo de vida do projeto.
Em outras palavras, um projeto é uma atividade bastante

complexa que é difícil de gerenciar devido à sua singularidade e re-
cursos e tempo limitados. Essa circunstância introduz um elemen-
to de incerteza no projeto e uma gestão devidamente organizada
torna os resultados previsíveis. A propósito, previsível não signi-
fica sucesso. Isso significa - durante a conclusão (com êxito) ou
durante a finalização (malsucedida).
Ressalta-se que nem todo tipo de atividade pode ser classifi-
cado como projeto. Não-projetos geralmente incluem:
● Programa: um esforço em grande escala com o objetivo

de alcançar um certo objetivo complexo: um programa de
pesquisa espacial, um programa de recuperação de terras
na Ásia Central. O objetivo do programa não é específico,
o tempo e os recursos não são definidos. Mas o programa
pode ser dividido em metas específicas individuais para
as quais cronogramas e recursos são alocados. Aqueles.
7-5
o programa pode ser dividido em projetos separados: o
projeto Apollo, o projeto Soyuz, o projeto de construção
do canal Volga-Amu Darya, dentre outros.
● Executando um processo de estado estacionário:
atividades que são executadas repetidamente e continu-
amente: produção de esteira, processamento de pedi-
dos, contabilidade. Tem uma meta específica (liberação
da quantidade planejada de produtos, obtenção de lucro
definido, manutenção de registros) e recursos dedicados,
mas não é única ou complexa e não está associada a pra-
zos específicos. O gerenciamento de tais processos repeti-
tivos é relativamente simples. Alterar os parâmetros dos
processos estabelecidos pode se transformar em um pro-
jeto (aumentando a lucratividade da empresa) com metas
específicas (até 45%), prazos e recursos alocados.
● Resolvendo um problema criativo (científico ou artísti-
co). Há um objetivo específico, singularidade e comple-
xidade aqui, mas, via de regra, não há restrições de tem-
po e recursos (vamos unir os esforços de nossa equipe e
provar o teorema até o Ano Novo!). O grau de incerteza é
muito grande.
A solução de problemas científicos complexos pode ser divi-

dida em estudos separados (experimentos) com objetivos, pra-
zos e recursos especificamente definidos.
7.3 Gerenciamento de Projetos

Dentre as várias definições de gerenciamento de projetos,
a mais completa é a definição formulada pelo PMI no Conjun-
to de Conhecimento em Gerenciamento de Projetos (PMBOK):
7-6
“Gerenciamento de Projetos (PM) é a ciência e a arte da liderança
e coordenação de recursos humanos e materiais ao longo do ciclo
de vida do projeto através da aplicação de modernos métodos e
técnicas de gestão para atingir os resultados definidos no projeto
em termos de âmbito e âmbito de trabalho, custo, prazo, qualidade
e satisfação dos participantes do projeto.
A gestão de projetos é baseada em dois pilares (princípios):
● Habilidade: conhecimento dos princípios e métodos de

gerenciamento de projetos (planejamento, organização,
agendamento, controle, gerenciamento e rastreamento).
● Habilidades: experiência em gerenciamento - a apli-
cação de habilidades para atingir metas em um am-
biente específico.
Embora o desenvolvimento de métodos e técnicas de gestão

tenha começado no início do século passado, como disciplina, a
gestão de projetos começou a tomar forma na década de 50 do sé-
culo XX, o que foi ocasionado pela necessidade de coordenar tra-
balhos em grandes projetos para o desenvolvimento, de armas e
exploração espacial (EUA). Métodos de gerenciamento de grandes
projetos foram desenvolvidos, entre os quais os mais famosos são:
● Método do caminho crítico (CPM)

● Método de análise e avaliação de programas PERT (Téc-
nica de Avaliação e Revisão de Programas)
7.4 Categorias de gerenciamento de projetos

Categorias (do grego. Kategoria enunciado; signo), em
filosofia, são os conceitos mais gerais e fundamentais, refletindo
7-7
as propriedades e relações universais essenciais dos fenômenos da
realidade e da cognição. As categorias foram formadas como resul-
tado da generalização do desenvolvimento histórico do conheci-
mento e da prática: matéria e consciência, espaço e tempo, causali-
dade, necessidade e acaso, possibilidade e realidade, etc.
Semelhante às categorias filosóficas, no campo do gerencia-
mento de projetos existem categorias que refletem os conceitos
básicos desta área. Em geral, os seguintes grupos de catego-
rias são diferenciados:
● Objetivos definidos pelos resultados esperados do projeto.

● Critérios de sucesso e limitações: custo, tem-
po, qualidade.
● As principais alavancas de controle: recursos (que
também são restrições) e tecnologia.
● Alavancas subsidiárias de gestão: contratos, organi-
zação, interação, pessoal.
● Incerteza associada aos riscos de execução do projeto.
7.5 Triângulo de Restrição de projetos

As restrições são uma categoria-chave envolvida no processo
de gerenciamento de projetos. A famosa lei de Lerman diz: “Qual-
quer problema técnico pode ser superado com tempo e dinheiro
suficientes”, e a investigação de Lerman esclarece: “Você nunca
terá tempo ou dinheiro suficientes.”
Ao compreender a sua principal tarefa na implementação
do projecto, irá responder: “Assegurar que as obras sejam con-
cluídas a tempo, dentro dos fundos atribuídos, de acordo com os
termos de referência”. São esses três pontos: tempo, orçamento e
7-8
qualidade do trabalho que estão sob a atenção constante do geren-
te de projetos. Eles também podem ser chamados de as principais
restrições impostas sobre projeto.
Figura 7-1: Diagrama de Sequência
Fonte: encurtador.com.br/efzGN
Essas três restrições principais (tempo, custo e qualida-

de do resultado) estão inter-relacionadas. Para ilustrar a rela-
ção, um triângulo de restrições é usado, no qual qualidade, tempo
e dinheiro são interpretados pelas áreas dos triângulos internos.
Neste triângulo, os vértices central e superior são fixos, enquanto
os vértices inferiores podem ser movidos. O triângulo ilustra que
qualquer redução nas finanças ou no tempo leva a uma redução na
qualidade, e um aumento na qualidade pode ser alcançado aumen-
tando o financiamento ou o tempo.
7.6 Papel de um Gerente de Projeto

O personagem principal do projeto é o gerente. Ele deve ter
CONHECIMENTO e HABILIDADES. Quem é o projeto de sof-
tware? Programador? No começo era. Desempenhei o papel de
7-9
conhecimento na área disciplinar (design e desenvolvimento
de software). Mas então o CONHECIMENTO e as HABILIDA-
DES sobre gerenciamento começaram a vir à tona.
Para ajudar nesta situação, será usado como exemplo de ex-
plicação, as 9 áreas de conhecimento do PMBOK.
PMBOK (Project Management Body of Knowledge) é
um padrão internacional para a composição do conhecimento em
gerenciamento de projetos, que é desenvolvido e desenvolvido pelo
Project Management Institute (PMI) [8]. PMBOK contém des-
crições da composição do conhecimento para as seguintes 9 seções
(áreas de conhecimento) de gerenciamento de projetos, cada
uma das quais é dividida em subseções correspondentes:
1. Gerenciamento integrado de projetos

a) Desenvolvimento do Plano do Projeto.
b) Execução do Plano do Projeto.
c) Controle Integrado de Mudanças.
2. Gerenciamento do escopo
a) Iniciação: uma decisão formal para iniciar
um projeto.
b) (próxima fase do projeto).
c) ScopePlanning: desenvolvimento documento, des-
crevendo o escopo do trabalho.
d) Formalização do escopo de trabalho (Defini-
ção de Escopo): decomposição de todo o escopo de
trabalho (os principais resultados exigidos) em pe-
quenas tarefas mensuráveis.
7-10
e) Verificação do escopo: confirmação do escopo do
trabalho - verificação formal da aceitabilidade dos re-
sultados do trabalho.
f) Controle de mudança de escopo: controle e
aprovação de mudanças.
3. Gerenciamento de tempo (tempo)

a) Definição de Atividade.
b) Sequenciamento de Atividades.
c) Estimativa de duração da atividade.
d) Desenvolvimento de cronograma.
4. Gestão de custos
a) Planejamento de recursos: quais recursos e em
que quantidade são necessários para o trabalho.
b) Estimativa de custos: os recursos necessários
para o trabalho.
c) Elaboração do orçamento (Cost Budgeting):
orçamentação - alocação de custos aos componentes
do projeto.
d) Controle de custos: gerenciamento de mudanças
no orçamento.
5. Gestão da Qualidade
a) Planejamento de qualidade: definição de padrões
de qualidade e meios para alcançá-los.
b) Garantia de qualidade: avaliação de desempe-
nho planejada e regular - inspeção dos processos
de produção.
7-11
c) Controle de qualidade: monitorar os resultados
do projeto, determinar sua conformidade com as nor-
mas, identificar e eliminar as causas de não conformi-
dade da qualidade.
6. Gestão de Recursos Humanos

a) Planejamento organizacional: identificar, docu-
mentar e atribuir funções, responsabilidades e estru-
turas de relatórios ao projeto.
b) Aquisição de pessoal: obtenção dos recursos hu-
manos necessários para o projeto, designando pesso-
al para a equipe do projeto.
c) Desenvolvimento da equipe do projeto (De-
senvolvimento da Equipe): aumentando a produ-
tividade do trabalho: o indivíduo e a equipe como um
todo (melhorando a interação).
7. Gestão de Comunicações
a) Planejamento de comunicações: identificando
as necessidades de informações dos participantes do
projeto e planejando os fluxos de informações.
b) Distribuição de informações: fornecimento re-
gular e oportuno aos participantes do projeto das in-
formações necessárias.
c) Relatório de desempenho: coleta e divulgação de
relatórios sobre o estado atual do projeto, progresso
alcançado e resultados esperados.
d) Encerramento Administrativo: a criação, distri-
buição (destruição) de informações necessárias para
a conclusão formal do projeto / fase.
7-12
8. Gerenciamento de riscos
a) Planejamento de gerenciamento de risco.
b) Identificação de Risco.
c) Análise Qualitativa de Risco.
d) Análise Quantitativa de Risco.
e) Planejamento de Resposta a Riscos.
f) Monitoramento e controle de risco.
9. Aquisições e gestão de suprimentos (Aquisições):

a) Planejamento de Aquisições: determinar quais
produtos e serviços são necessários externamente.
b) Propostas de planejamento (planejamento de
solicitações): documentação requisitos para produ-
tos e serviços de fornecedores externos.
c) Recebendo propostas (Solicitação)
d) Seleção de fonte.
e) Administração de Contratos: regulação das rela-
ções com fornecedores.
f) Conclusão de contratos (Encerramento de
Contrato): confirmação de desempenho, resolução
de disputas.
7.7 Competências de um Gerente de TI

O Software Quality Institute (SQI) desenvolveu um Body of
Knowledge para a certificação de gestores de projetos de software
(SWPM - SoftWare Project Management). Este documento
contém uma lista de 34 competências que um gerente de projeto de
7-13
software deve possuir. A lista é dividida em três categorias princi-
pais: metodologia de desenvolvimento de produto, habilidades
de gerenciamento de projetos e habilidades de gerencia-
mento de recursos humanos:
1. Metodologia de desenvolvimento de produto:

a) Processos de avaliação: definição de critérios
de seleção.
b) Conhecimento de padrões de processo.
c) Definição do produto: identificação do ambiente
do cliente e requisitos do produto.
d) Avaliação de processos alternativos.
e) Gerenciamento de requisitos: monitoramento
de mudanças nos requisitos.
f) Gestão de subcontratados: planejamento, ges-
tão e controle.
g) Realizando a avaliação inicial: avaliando a difi-
culdade, os riscos, os custos e o cronograma.
h) Seleção de métodos e ferramentas: definição de
processos de seleção.
i) Adaptação de processo: modificação de processos
padrão com mirar atender aos requisitos do projeto.
j) Rastreamento de qualidade do produto:
controle de qualidade durante o desenvolvimento
do produto.
k) Compreendendo as Atividades de Desenvolvi-
mento de Produto: Explorando o Ciclo de Desen-
volvimento de Software.
7-14
2. Habilidades de gerenciamento de projetos:
a) Elaboração da estrutura da lista operacional de obras.

b) Documentando planos: identificando os princi-
pais componentes.
c) Estimativa de custo: Custo de conclusão do projeto.
d) Avaliação dos custos de mão de obra: necessá-
ria para concluir o projeto.
e) Gestão de risco: identificação, determinação de ex-
posição, tratamento de risco.
f) Rastreando o processo de desenvolvimento:
monitorando o processo de desenvolvimento.
g) Cronograma: desenvolvimento do cronograma e
etapas principais do projeto.
h) Seleção métrica.
i) Seleção de ferramentas de gerenciamento de
projetos: seleção de técnicas e ferramentas.
j) Rastreamento de processo: monitorando a com-
patibilidade dos membros da equipe.
k) Acompanhamento do progresso do desen-
volvimento do produto: monitorar o progresso
do desenvolvimento com base em valores de mé-
trica selecionados.
3. Habilidade de Gestão de pessoal:

a) Avaliação de desempenho: avalia as ações da
equipe para melhorar seu desempenho.
b) Questões de propriedade intelectual: Compre-
endendo o impacto de questões críticas.
7-15
c) Organização de reuniões eficazes: planejamen-
to e condução.
d) Interação e comunicação: com desenvolvedores,
gestão e outras equipes.
e) Equipes de projeto de treinamento de liderança para
obter o melhor resultados.
f) Gerenciamento de mudanças: garantindo eficá-
cia da gestão em alterações.
g) Negociação bem-sucedida: Resolução de confli-
tos regente negociações.
h) Planejamento de carreira: estruturação e geren-
ciamento do curso de uma carreira.
i) Apresentação eficaz: usando habilidades
orais e escritas.
j) Recrutamento: recrutamento e entrevista de mem-
bros da equipe.
k) Seleção de uma equipe: especialistas alta-
mente competentes.
l) Formação de equipes: formando, orientando e
apoiando uma equipe eficaz.
7-16
1) Em várias fontes, você pode encontrar diferentes definições do conceito

de “gerenciamento” umas dela é:
( ) -a) Uma mudança no estado de um objeto, sistema ou proces-

so que leva à realização do objetivo definido (dicionário da
cibernética).
( ) -b) Um conjunto de subprojetos coletados pelo desenvolvedor.
( ) -c) A presença de erros específicos que surgiram devido ao fato
de que projetos individuais.
( ) -d) Integração geral
( ) -e) Um ramo que corresponde à direção principal do desenvol-
vimento do projeto.

I) Recentemente, a palavra projeto tem sido usada com bastante frequência
(e muitas vezes em vão
II) Um projeto é uma série arbitrária de ações ou tarefas com um objetivo
específico que será alcançado no âmbito de algumas tarefas, caracterizado
por certas datas de início e fim, limites de financiamento e recursos.
III) Um projeto é um esforço temporário usado para criar um produto ou
serviço exclusivo com apena uma data de início que é diferente de atividades
contínuas e repetidas e requer menos melhoria de desempenho progressiva.
Estão INCORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) II e III
( ) -e) I, somente.
7-17
3) O objetivo do projeto e:
( ) -a) Um empreendimento único que não se repetirá.
( ) -b) A presença de um resultado final, produção, produto bem
definido, definido em termos de custo, qualidade e prazo de
entrega.
( ) -c) Sua implementação requer uma concentração temporária de
recursos.
( ) -d) Para atingir os objetivos do projeto, existem muitas tarefas
a serem resolvidas.
( ) -e) A capacidade de atingir a meta dentro do prazo especificado
com os recursos alocados não é garantida com antecedência.
4) Ressalta-se que nem todo tipo de atividade pode ser classificado como
projeto. Não-projetos geralmente incluem:
( ) -a) Previsibilidade
( ) -b) Incerteza
( ) -c) Complexidade
( ) -d) Limitações de tempo
( ) -e) Programa
5) Dentre as várias definições de gerenciamento de projetos, a mais com-

pleta é a definição formulada pelo:
( ) -a) Software
( ) -b) Programa
( ) -c) PMI
( ) -d) PMT
( ) -e) Next
6) O conceito de Gerenciamento de Projetos (PM) é
( ) -a) A ciência e a arte da liderança e coordenação de recursos

humanos e materiais ao longo do ciclo de vida do projeto
através da aplicação de modernos métodos.
7-18
( ) -b) A solução de problemas científicos.
( ) -c) Atividades que são executadas repetidamente e continuamente:
produção de esteira, processamento de pedidos, contabilidade.
( ) -d) Um programa de pesquisa espacial, um programa de recu-
peração de terras na Ásia Central.
( ) -e) Uma atividade bastante complexa que é difícil de gerenciar
devido à sua singularidade e recursos e tempo limitados.
7) A gestão de projetos é baseada em dois pilares princípios. Um deles são:
( ) -a) Método do caminho crítico

( ) -b) Método de análise e avaliação de programas
( ) -c) Executando um processo de estado estacionário
( ) -d) Habilidade conhecimento dos princípios e métodos de ge-
renciamento de projetos planejamento, organização, agen-
damento, controle, gerenciamento e rastreamento.
( ) -e) Incerteza a capacidade de atingir a meta dentro do prazo
especificado com os recursos alocados não é garantida com
antecedência.
8) Embora o desenvolvimento de métodos e técnicas de gestão tenha começado

no início do século passado, como disciplina, a gestão de projetos começou a
tomar forma na década de 50 do século XX, o que foi ocasionado pela neces-
sidade de coordenar trabalhos em grandes projetos para o desenvolvimento,
de armas e exploração espacial (EUA). Métodos de gerenciamento de gran-
des projetos foram desenvolvidos, entre os quais os mais famosos são:
( ) -a) Habilidades - experiência em gerenciamento - a aplicação de

habilidades para atingir metas em um ambiente específico.
( ) -b) Método de análise e avaliação de programas PERT (Técnica
de Avaliação e Revisão de Programas)
( ) -c) Habilidade conhecimento dos princípios e métodos de ge-
renciamento de projetos planejamento, organização, agen-
damento, controle, gerenciamento e rastreamento.
( ) -d) Executando um processo de estado estacionário
antecedência.
7-19
9) Semelhante às categorias filosóficas, no campo do gerenciamento de pro-
jetos existem categorias que refletem os conceitos básicos desta área.
Em geral, um dos seguintes grupos de categorias são diferenciados:
( ) -a) Objetivos definidos pelos resultados esperados do projeto.

( ) -b) Método do caminho crítico (CPM)
( ) -c) Habilidade - conhecimento dos princípios e métodos de ge-
renciamento de projetos (planejamento, organização, agen-
damento, controle, gerenciamento e rastreamento).
( ) -d) A solução de problemas científicos complexos pode ser di-
vidida em estudos separados (experimentos) com objetivos,
prazos e recursos especificamente definidos.
antecedência.
10) Eles também podem ser chamados de as principais restrições impostas

sobre projeto.
( ) -a) Custo, Preço e Escopo

( ) -b) Software, Duração e Custo
( ) -c) Custo, Duração e Escopo
( ) -d) Custo, CPM, Preço
( ) -e) Software, Custo e CPM
7-20
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 8:
ORGANIZAÇÃO DA EQUIPE
O R G A N IZAÇÃO D A EQ U I PE
8.1 Peopleware
Como organizar o trabalho da equipe? Equipes de 10
e equipes de 500? Existem diferenças e quais são? É necessário or-
ganizar o trabalho de acordo com uma tecnologia rígida ou é neces-
sário dar liberdade de ação? É possível encontrar uma metodologia
(tecnologia) de implantação de projetos que garanta o sucesso?
Alistair Cowben, especialista na área de tecnologias para a
execução de projetos de TI, fornece dados de 23 projetos de diver-
sos graus de complexidade, realizados com diferentes tecnologias
e com resultados diversos. Tentando analisar os resultados da apli-
cação de várias tecnologias em determinadas condições, ele che-
ga à conclusão:
● Quase qualquer metodologia pode ser aplicada com su-

cesso a qualquer projeto.
● Qualquer metodologia pode levar ao fracasso do projeto.
Ele vê a razão principal no fato de que sempre há algo bem

na nossa frente que não percebemos: as pessoas. São as qualidades
humanas que garantem o sucesso deste ou daquele projeto, são o
fator de suma importância, a partir do qual é necessário fazer pre-
visões sobre o projeto.
Os problemas do fator humano estão associados ao fato (ma-
nifestado no fato de que as pessoas envolvidas no projeto:
● Todo mundo é diferente: em caráter, temperamento,

atividade, objetivos - não há duas pessoas iguais.
● Todos são semelhantes: a participação no projeto une
pessoas com um objetivo comum, em busca de formas de
atingir esses objetivos.
8-2
● Eles diferem em tipo: individualistas - membros
da equipe; geradores de ideias -performers; responsá-
vel - irresponsável.
● Constante e mutável: as pessoas, via de regra, mostram
a constância de seus hábitos e propriedades de caráter,
mas são capazes de exibir qualidades “opostas”: comando
individualista qualidade, performer - para gerar ideias.
● Diversos: é preciso entender que a diversidade das pes-
soas é a principal garantia da sobrevivência da humani-
dade em geral e da capacidade de realizar projetos de TI
em particular. Se todos fossem individualistas, ou todos
os comandantes, todos os geradores de idéias ou todos os
executores, dificilmente seria possível concluir pelo me-
nos um projeto, e o mundo se tornaria terrível.
Como se gerencia essas pessoas? O trabalho de Philip

Laplante fornece uma visão geral dos três principais modelos de
gestão de equipes:
8.1.1 Modelo administrativo (teoria X)

Esse é o estilo de gerenciamento tradicional associado ao
modelo hierárquico de comando e controle usado por organizações
militares. É baseado na Teoria X, que argumenta que tal aborda-
gem é necessária porque a maioria das pessoas por natureza não
gosta de trabalhar e tenderá a evitá-lo se puder. No entanto, os
gerentes devem coagir, controlar, dirigir e ameaçar os funcionários
para obter o máximo deles. Teoria e lema do modelo: As pessoas só
fazem o que você controla. Ou em uma versão mais branda: as pes-
soas fazem o que não querem fazer apenas se você as controlar. Em
8-3
última análise, a teoria é que a maioria das pessoas prefere ouvir o
que fazer e não ter que decidir por si mesmas.
Características do modelo:
● Pirâmide de poder: as decisões são tomadas de cima

para baixo.
● Uma distribuição clara de funções e responsabilidades.
● Uma distribuição clara de responsabilidades.
● Seguindo instruções, procedimentos, tecnologias.
● O papel do gestor: planejamento, controle, tomada de
decisões importantes.
Vantagens do modelo: clareza, simplicidade, previsibilidade.

O modelo se ajusta bem ao modelo de ciclo de vida em cascata e é
aplicável nos mesmos casos que o modelo em cascata. O modelo é
eficaz no caso de um processo estável.
As desvantagens do modelo estão associadas ao fato de que o
sistema administrativo busca a autopreservação (estabilidade) e
é pouco suscetível a mudanças na situação - novos tipos de proje-
tos, o uso de novas tecnologias, uma resposta rápida às mudanças
no mercado. Além disso, individualistas e geradores de ideias não
se dão bem no modelo administrativo.
O sistema administrativo (modelo) é uma locomotiva pe-
sada rodando no “meio” e não se entregando aos “extremos” da
busca por novos caminhos e soluções. Ela aceita novas soluções
e tecnologias, mas apenas comprovadas, comprovadas e padroni-
zadas. Esta é a sua força, fraqueza e manifestação do princípio da
diversidade. Aparentemente, é a ela que o termo “programação
industrial” é mais aplicável.
8-4
8.1.2 Modelo administrativo (teoria Y)
O modelo do caos é baseado na Teoria Y, que é o oposto da
Teoria X. A tese principal da Teoria Y: o trabalho é uma ativi-
dade natural e prazerosa e a maioria das pessoas é, de fato, muito
responsável e não se intimida do trabalho.
As características do modelo do caos são:
● Falta de sinais claros de poder.

● Papel do gerente é definir uma tarefa, fornecer recursos,
não interferir e garantir que os outros não interfiram.
● Falta de instruções e procedimentos regulamentados.
● Iniciativa individual: as soluções para um problema
são feitas onde o problema é encontrado.
● O processo se assemelha a um criativo o jogo participan-
tes em base amigáveis competitividade.
As vantagens deste modelo são que a iniciativa criativa dos

participantes não está ligada a nada e o potencial dos participan-
tes é plenamente revelado. Isso é especialmente eficaz quando a
resolução de um problema requer a busca de novas abordagens,
métodos, ideias e ferramentas. A equipa passa a ser uma equipa
de “avanço”, e o trabalho desenvolve-se em forma de jogo, cujo
objetivo é encontrar o melhor resultado. O processo se assemelha
a uma busca aleatória, quando ideias e soluções nascem durante
uma discussão animada e, por assim dizer, aleatória de problemas
no corredor, na sala de jantar de um piquenique. Muitas vezes,
simplesmente não é possível reunir essa equipe na sala de traba-
lho e organizar uma discussão sobre os regulamentos - esta é uma
equipe de individualistas criativos.
8-5
As desvantagens do modelo estão relacionadas ao fato de
que, sob certas condições, uma equipe de fuga pode se tornar uma
equipe de falha. Os motivos da falha podem ser:
● A competição criativa se transforma em competição de

ideias primeiro, e então- personalidades.
● O processo passa a prevalecer sobre o objetivo do proje-
to - as ideias expressas não são realizadas até o fim e são
substituídas por novas ideias, a prevalência é ganha Ideias
“lindas” que estão fora dos objetivos principais do projeto.
● Pessoas capazes de gerar ideias raramente têm paciência
para concretizá-las.
O modelo do caos é o que é necessário para o desenvolvi-

mento de novas terras. O modelo do caos não contradiz o modelo
administrativo - ele o complementa e pode coexistir efetivamente
com ele (mas em salas diferentes.). Muitos gigantes corpora-
tivos robustos confiam em “departamentos skunk” de pesquisa, de
onde obtêm novas ideias, tecnologias e produtos.
8.1.3 Arquitetura aberta (teoria Z)

Os modelos administrativos e caóticos são dois “extremos”,
entre os quais existem muitos modelos que combinam as vanta-
gens dos modelos “extremos”. Um desses modelos é o modelo de
arquitetura aberta baseado na Teoria Z. Essa teoria foi formula-
da por William Ouchi com base na experiência do estilo de gestão
japonês (Teoria Z: Como as empresas americanas podem
enfrentar o desafio japonês, “Perseus Publishing, 1981).
A Teoria Z pressupõe (mas não declara) a existência de um me-
canismo de controle interno baseado na influência dos colegas e
8-6
do grupo como um todo. As normas culturais de uma determinada
empresa têm um impacto adicional.
O princípio básico do modelo pode ser formulado da seguin-
te forma: “Trabalhamos com calma. Nós trabalhamos juntos.” Os
recursos deste modelo são:
● Adaptação às condições de trabalho: se fizermos

módulos independentes, então discordamos e fazemos, se
a arquitetura do banco de dados for necessária, então nos
reunimos e discutimos ideias.
● Discussão coletiva de problemas, construção de
consenso e tomada de decisão: nem todos podem
concordar, mas a decisão tomada é coletiva e, portanto,
obrigatória para todos.
● Responsabilidade distribuída: todos que discutiram,
trabalharam, aceitaram são responsáveis.
● Dinâmica da composição dos grupos de trabalho em fun-
ção das tarefas atuais.
● Falta de especialização: os participantes mudam
de papéis e funções e podem substituir uns aos outros,
se necessário.
● A tarefa do gestor é a participação ativa (mas ordinária,
não dirigente) no processo, o controle da construtividade
das discussões, garantindo a possibilidade de participa-
ção ativa de todos.
Uma arquitetura aberta é mais flexível, adaptável e persona-

lizável para a situação. Dá a oportunidade de se expressar a todos
os membros da equipe - tanto individualistas quanto coletivistas
podem se dar bem. Uma discussão coletiva das ideias expressas
permite que você deixe apenas ideias pragmáticas.
8-7
8.2 Comunicação da Equipe
O principal fator no desenvolvimento de software é a capa-
cidade de comunicação (comunicação entre os participantes
do projeto). A comunicação pode ser realizada de várias formas,
desde estritamente formalizada (documentação padronizada)
até completamente não formalizada (pergunta e resposta a um
vizinho, discussão em ambiente informal).
Deve-se lembrar que as comunicações em uma equipe são
determinadas pelo número de participantes (conexões de tra-
balho): com dois participantes, esta é uma conexão, com n par-
ticipantes - n (n-2) / 2. Ao mesmo tempo, qualquer uma dessas
conexões pode funcionar mal e não são transitivas: do fato de que
o participante A está em bom contato com B e B está em bom con-
tato com C, isso não significa que A está em contato com V. Isso
é, a comunicação informal “ao vivo” é eficaz apenas em equipes
relativamente pequenas e bem organizadas (bem organizadas).
8.3 Tomada de decisão

O objetivo da comunicação na equipe de desenvolvimento é
discutir os problemas e questões atuais e tomar decisões. A seguir,
veremos alguns dos problemas de organização de discussão e to-
mada de decisão. Vamos começar tomando decisões.
Portanto, uma decisão tomada como resultado de uma dis-
cussão pode ser alcançada como resultado de um compromisso ou
como resultado de um consenso. Qual é a diferença entre es-
ses resultados?
Vamos começar com as definições: Compromisso é
um acordo alcançado por meio de concessões mútuas. Consenso
8-8
(opinião coletiva) - uma opinião geral para um determinado
grupo. Qual é a diferença?
Compromisso:
9 Esta é uma solução média, que pode ser (e, via de regra,
acaba sendo) pior do que cada uma das opções.
9 Obtido por concessões mútuas (concordaremos com sua
opção de interface se concordar com nossa organização
de banco de dados).
9 Pode ser adotado por maioria (votação).
Consenso:
9 Esta é a solução ideal combinando o melhor das op-
ções propostas.
9 Alcançado através de discussão, análise e geração de no-
vas ideias.
9 Aceito por acordo geral (todos concordam que uma solu-
ção melhor foi encontrada).
L. Konstantin dá o seguinte exemplo de compromisso e

consenso. Ao discutir o posicionamento dos botões da barra de
ferramentas, duas opções foram apresentadas: horizontalmen-
te e verticalmente.
Compromisso: diagonalmente (decisão ridícula).
Consenso: painel personalizável pelo usuário (a melhor
solução que inclui ambas as opções com base em uma
nova ideia é um painel personalizado).
Ao contrário do compromisso, que geralmente é alcançado
como resultado de intrigas políticas e batalhas secretas, chegar a
um consenso requer uma tensão construtiva e frutífera de toda
8-9
a equipe e uma arte especial de gerenciamento de equipe. Neste
caso, recomenda-se aderir aos seguintes princípios e regras:
Crença na construção de consenso: cada membro da
equipe deve confiar nos outros que a discussão levará à busca de
uma solução ótima, e não a uma disputa de opiniões pessoais.
Criar essa atmosfera de confiança mútua é essencial para criar uma
equipe eficaz.
Deve ser entendido que a confiança mútua não surge por si
mesma, mas é o resultado de:
● Vários consensos de sucesso.

● Participação de todos no desenvolvimento e adoção de de-
cisões ótimas.
● Tornar todos cientes de seu envolvimento nas deci-
sões tomadas.
Não é uma posição, mas soluções: as pessoas devem vir

para a discussão não com uma posição formada (não um passo
para trás), mas com opções para possíveis soluções
Objetividade das decisões tomadas: como uma tenta-
tiva de limitar as manifestações de sentimentos e emoções ao dis-
cutir questões. Sentimentos e emoções são inerentes à natureza
humana. É improvável que seja possível evitá-los completamente,
mas as seguintes regras podem ser usadas para trazê-los
“de volta ao normal”:
9 Critérios de avaliação das opções: para a objetivi-

dade da discussão, é extremamente importante concor-
dar previamente com os critérios de avaliação - estabe-
lecer uma lista de critérios e classificá-los por ordem
de importância.
8-10
9 Separação de fatos e opiniões. Os fatos são indica-
dores objetivos, expressos na maioria dos casos
quantitativamente (mas não necessariamente):
desempenho, tempo de resposta. Opiniões são aquelas
que não são baseadas em fatos. Opiniões não devem ser
desconsideradas como muitas vezes se baseiam na expe-
riência, na intuição.
Substituindo posições: no caso de a discussão chegar a

um beco sem saída, é útil convidar os participantes a mudar seu
ponto de vista: “Por favor, liste os pontos fortes da variação do
seu oponente e os pontos fracos da sua variação.”
Dirigindo ligeiramente: o papel do líder para chegar a
um consenso é dar a todos a oportunidade de se manifestar e ofe-
recer suas opções, deixando sua opinião por último ou não a ex-
pressando. O líder deve ser neutro. O líder (líder) pode partici-
par ativamente da discussão, mas apenas como igual e, neste caso,
confiar a liderança da reunião a outra pessoa.
8.4 Planejamento e Controle

Na verdade: para que planejar, se os prazos planejados
ainda estão frustrados, os recursos planejados ainda não serão su-
ficientes, o orçamento previsto estará estourando? O planejamento
vale o tempo e o dinheiro? Vale a pena porque:
9 Você deve convencer o Cliente de que é possível fazer ne-

gócios com você. Como? Ter um plano é um dos argumen-
tos mais fortes.
9 O projeto deve ser previsível. Como você o torna previsível?
O plano é um dos principais elementos da previsibilidade
8-11
do projeto. Acompanhar o andamento do plano permite
avaliar a possibilidade de dar continuidade ao projeto.
9 O projeto tem um elemento de incerteza. Aqueles. É im-
possível prever tudo com antecedência, em virtude do que
os planos originais geralmente não são cumpridos. Mas
no caso de circunstâncias anteriormente não explicadas,
os planos podem e devem ser ajustados. Para manter o
projeto previsível. O plano não é nada. O planejamen-
to é tudo.
As principais funções de planejamento são:
9 Converter necessidades em tarefas gerenciáveis. Inicial-

mente, o projeto atua na forma de requisitos desenvolvi-
dos e acordados com o Cliente. O objetivo do planejamen-
to é representá-lo como uma coleção de tarefas individuais
que podem ser monitoradas.
9 Determinação dos recursos necessários. Planos detalha-
dos permitirão que você determine o número de pessoas,
o equipamento necessário e as condições de trabalho que
serão necessárias para concluir o projeto
9 Coordenação de equipe de trabalho no projeto. Muitas
vezes, a execução de um projeto é dividida em trabalhos
separados que podem ser executados em paralelo. Os pla-
nos tornam a coordenação possível, identificando quem
faz o quê e quando.
9 Avaliação de riscos potenciais. Embora alguns riscos pos-
sam ser identificados durante a formulação de requisitos,
muitos mais são descobertos após um planejamento de-
talhado. Saber da existência desses riscos permitirá que
8-12
você os perceba com antecedência (caso se concretizem) e
se prepare para enfrentá-los.
9 Sinalização de problemas. O desvio do plano é um sinal
de que surgiu um problema. Planos não são dogmas que
devem ser seguidos incondicionalmente. Para o gerente
de projeto, são suposições mais prováveis e uma base de
comparação. Se a implementação do projeto não atender
às expectativas, é necessário fazer o ajuste corresponden-
te ao plano.
Ao planejar um projeto, você precisa encontrar res-

postas para as seguintes perguntas:
9 O que deve ser feito e como? Determinação dos ob-

jetivos do projeto, estratégias para atingir os objetivos,
destacando tarefas.
9 Quando isso deve ser feito? Agendamento de tare-
fas individuais
9 Quanto vai custar? Planejando um orçamento para ta-
refas individuais e itens de despesas.
9 Quem deve fazer isso? Planejamento de recursos, dis-
tribuição de funções e responsabilidades.
9 Quão bem deve ser feito? Planejamento de qualidade.
9 O que pode atrapalhar? Planejamento de riscos.
9 Como verificar e avaliar? Determinação das métricas
do projeto.
Em projetos relativamente pequenos, o plano pode ser uni-

forme. Em grandes projetos, os planos podem ser elaborados para
certos tipos de trabalho (processos): plano de teste, plano de do-
cumentação, plano de gestão da qualidade, plano financeiro, etc.
8-13
Se houver vários planos, também é elaborado um plano diretor
(plano diretor), que reflete os principais indicadores do proje-
to como um todo: os principais (sem detalhamento) tipos de
obras, prazos, recursos, financiamentos.
8-14
1) Esse é o estilo de gerenciamento tradicional associado ao modelo hierár-

quico de comando e controle usado por organizações militares. Estamos
falando de:
( ) -a) Modelo administrativo (teoria X)

( ) -b) Peopleware
( ) -c) Competências de um Gerente de TI
( ) -d) Papel de um Gerente de Projeto
( ) -e) Triângulo de Restrição de projetos
2) Em última análise, a teoria é que a maioria das pessoas prefere ouvir o

que fazer e não ter que decidir por si mesmas. Umas das características
do modelo é:
( ) -a) Todo mundo é diferente - em caráter, temperamento, ativi-

dade, objetivos - não há duas pessoas iguais.
( ) -b) Todos são semelhantes - a participação no projeto une pes-
soas com um objetivo comum, em busca de formas de atingir
esses objetivos.
( ) -c) Uma distribuição clara de funções e responsabilidades.
( ) -d) Quase qualquer metodologia pode ser aplicada com sucesso
a qualquer projeto.
( ) -e) Constante e mutável - as pessoas, via de regra, mostram a
constância de seus hábitos e propriedades de caráter, mas
são capazes de exibir qualidades “opostas”: comando indivi-
dualista qualidade, performer - para gerar ideias.
3) As Vantagens do modelo Da Teoria X são:
( ) -a) Estão associadas ao fato de que o sistema administrativo

busca a autopreservação estabilidade e é pouco suscetível
8-15
a mudanças na situação - novos tipos de projetos, o uso de
novas tecnologias, uma resposta rápida às mudanças no
mercado.
( ) -b) Clareza, simplicidade, previsibilidade.
( ) -c) O papel do gestor: planejamento, controle, tomada de deci-
sões importantes.
( ) -d) Pirâmide de poder - as decisões são tomadas de cima para
baixo.
( ) -e) Uma distribuição clara de funções e responsabilidades.
4) O trabalho é uma atividade natural e prazerosa e a maioria das pessoas

é, de fato, muito responsável e não se intimida do trabalho. Estamos
falando de:
( ) -a) Modelo administrativo (teoria X)

( ) -b) Arquitetura aberta (teoria Z)
( ) -c) Peopleware
( ) -d) Modelo administrativo (teoria Y)
( ) -e) Triângulo de Restrição de projetos
5) O modelo do caos é baseado na Teoria Y, que é o oposto da Teoria X,

umas das características do modelo do caos são:
( ) -a) Falta de instruções e procedimentos regulamentados.

( ) -b) Pirâmide de poder - as decisões são tomadas de cima para
baixo.
( ) -c) Uma distribuição clara de funções e responsabilidades.
( ) -d) Uma distribuição clara de responsabilidades.
( ) -e) Seguindo instruções, procedimentos, tecnologias.
6) Os modelos administrativos e caóticos são dois “extremos”, entre os

quais existem muitos modelos que combinam as vantagens dos modelos
“extremos”. Estamos falando de:
( ) -a) Modelo administrativo (teoria Y)

( ) -b) Modelo administrativo (teoria X)
8-16
( ) -c) Peopleware
( ) -d) Triângulo de Restrição de projetos
( ) -e) Arquitetura aberta (teoria Z)
7) O princípio básico do modelo Teoria Z pode ser formulado da seguinte

forma: “Trabalhamos com calma. Nós trabalhamos juntos. Um dos recur-
sos deste modelo são:
( ) -a) Pessoas capazes de gerar ideias raramente têm paciência

( ) -b) Discussão coletiva de problemas, construção de consenso e
tomada de decisão - nem todos podem concordar, mas a de-
cisão tomada é coletiva e, portanto, obrigatória para todos.
( ) -c) O processo passa a prevalecer sobre o objetivo do projeto -
as ideias expressas não são realizadas até o fim e são substi-
tuídas por novas ideias, a prevalência é ganha Ideias “lindas”
que estão fora dos objetivos principais do projeto.
( ) -d) Pessoas capazes de gerar ideias raramente têm paciência
( ) -e) Falta de sinais claros de poder.
8) É o principal fator no desenvolvimento de software é a capacidade de

comunicação entre os participantes do projeto. Estamos falando de:
( ) -a) Tomada de decisão

( ) -b) Comunicação da Equipe
( ) -c) Modelo administrativo (teoria X)
( ) -d) Modelo administrativo (teoria Y)
9) Deve-se lembrar que as comunicações em uma equipe são determinadas

por:
( ) -a) A tarefa do gestor é a participação ativa (mas ordinária, não

dirigente) no processo, o controle da construtividade das
discussões, garantindo a possibilidade de participação ativa
de todos.
8-17
( ) -b) Falta de especialização - os participantes mudam de papéis
e funções e podem substituir uns aos outros, se necessário.
( ) -c) Pelo número de participantes (conexões de trabalho): com
dois participantes, esta é uma conexão, com n participantes
- n (n-2) / 2.
( ) -d) Dinâmica da composição dos grupos de trabalho em função
das tarefas atuais.
( ) -e) Responsabilidade distribuída - todos que discutiram, traba-
lharam, aceitaram são responsáveis.
10) O objetivo da comunicação na equipe de desenvolvimento é discutir os

problemas e questões atuais. Estamos falando de:
( ) -a) Comunicação da Equipe

( ) -b) Arquitetura aberta (teoria Z)
( ) -c) Modelo administrativo (teoria Y)
( ) -d) Modelo administrativo (teoria X)
( ) -e) Tomada de decisão
8-18
DISCIPLINA:
Engenharia de
Software
UNIDADE 5:
TESTES E DESCRIÇÃO CMMI
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta quinta unidade, daremos orientações sobre os procedimen-

tos de testes na engenharia de software, além de uma descrição sobre
o CMMI.
Nesta unidade, iremos abordar sobre testes e controle de qualidades
no desenvolvimento de softwares, além de entendermos um pouco sobre
CMMI, Capability Maturity Model Integration.
9 Teste
9 CMMI
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 9:
TESTE
T ESTE
9.1 Controle de Qualidade
O desenvolvimento do mercado mundial levou ao fato de que
muitos bens e serviços começaram a se espalhar pelo mundo, os
serviços globais começaram a se desenvolver, em particular, te-
lecomunicações, bancos. Com o objetivo de eliminar as barreiras
técnicas à indústria, ao comércio e aos negócios, surgidas pelo fato
de em diferentes países para as mesmas tecnologias e produtos es-
tarem em vigor diferentes normas, começaram a ser criados comi-
tês de normas nacionais e internacionais. Vamos nos deter nos
comitês internacionais mais famosos.
1. 1865: Forma-se um comitê, hoje denominado ITU (In-

ternational Telecommunication Union). Hoje com
sede em Genebra (Suíça), a ITU faz parte da ONU. Sua
principal tarefa é padronizar protocolos e interfaces de
telecomunicações, a fim de manter e desenvolver a rede
global de telecomunicações global. Os padrões ITU
mais famosos são:
○ ISDN (telefonia digital, combinando serviços de tele-
fonia e transmissão de dados),
○ ADSL (uma conhecida tecnologia de modem que per-
mite usar uma linha telefônica para acessar a Internet
sem bloquear o serviço telefônico regular),
○ OSI (um modelo de protocolo de rede aberto de 7
camadas no qual todas as interfaces e protocolos de
rede padrão modernos são baseados; também um pa-
drão ISO),
○ Linguagens de design visual para sistemas de teleco-
municações, SDL e MSC, posteriormente incorpo-
rado à UML.
9-3
T ESTE
2. 1946: é criada a organização ISO (International Or-
ganization for Standardization). O objetivo é pro-
mover o desenvolvimento da padronização, bem como
das atividades correlatas no mundo, com o objetivo de
assegurar o intercâmbio internacional de bens e serviços,
promovendo e desenvolvendo a cooperação nos campos
intelectual, científico, técnico e econômico. Até o momen-
to, cerca de 17.000 padrões foram criados em várias áreas
da indústria - alimentos e outros bens, vários equipamen-
tos, serviços bancários, etc. Aqui estão alguns padrões.
○ Uma série de normas ISO 9000. Tem como objetivo a
padronização da qualidade de bens e serviços. Defini-
ção da qualidade, definição de um sistema de suporte
da qualidade em todas as fases da vida de um produto,
produto, serviço (concepção, desenvolvimento, comer-
cialização, instalação e manutenção), descrição dos
procedimentos para melhorar as actividades da em-
presa, produção industrial.
○ ISO / IEC 90003: 2004 - adaptação das normas ISO
9000 à produção de software em linha com a garantia
da qualidade no ciclo de vida do software.
○ ISO 9126: 2001 - definição de software de qualidade e
vários atributos que descrevem essa qualidade.
Existem muitos padrões no campo da tecnologia da informa-

ção, bem como vários no campo da engenharia de software. Existe
uma certificação de conformidade com as normas ISO. Em parti-
cular, as empresas são certificadas pelo cumprimento das normas
ISO 9000, ou seja, por um processo de desenvolvimento de sof-
tware de alta qualidade.
9-4
T ESTE
3. 1988: formação da organização ETSI (European Te-
lecommunications Standards Institute), com sede
em Sophia Antipolis (França). É uma organização in-
dependente, sem fins lucrativos, de padronização da in-
dústria de telecomunicações (OEMs e operadoras de
rede) na Europa. Os padrões mais famosos são GSM, o
sistema de rádio móvel profissional TETRA.
Vamos agora nos deter em uma série de comitês diretamente

relacionados ao desenvolvimento de software.
1. 1984: Criação do SEI (Software Engineering Insti-

tute) com base na Carnegie Mellon University em Pitt-
sburgh (EUA). O iniciador e principal patrocinador é o
Departamento de Defesa dos Estados Unidos. A princi-
pal tarefa é a padronização no campo da engenharia de
software, o desenvolvimento de critérios para certifica-
ção de empresas confiáveis e maduras (que interessa
principalmente ao Departamento de Defesa dos
Estados Unidos para o cumprimento de seus pe-
didos). Os produtos mais famosos são o padrão CMM,
CMMI, desenvolvimentos no campo de uma família de
produtos de software (linhas de produtos). Esses pro-
dutos foram muito além das forças armadas dos Estados
Unidos, seu uso e desenvolvimento se tornaram um es-
forço internacional. Alguns produtos SEI também são
padronizados pela ISO. A certificação é realizada para
conformidade com CMM / CMMI.
2. 1963: Criação do IEEE (Instituto de Engenheiros
Elétricos e Eletrônicos). Leva a história do final do
século XIX, no contexto da padronização industrial nos
9-5
T ESTE
Estados Unidos. Agora, o IEEE é uma associação inter-
nacional sem fins lucrativos de técnicos, líder mundial no
desenvolvimento de padrões para eletrônica e engenha-
ria elétrica. Com sede nos Estados Unidos, existem vá-
rias divisões em vários países, incluindo a Rússia. O IEEE
publica um terço da literatura técnica mundial sobre a
aplicação de rádio eletrônica, computadores, sistemas
de controle, engenharia elétrica, incluindo (janeiro de
2008) 102 periódicos científicos revisados por pares e 36
periódicos comerciais para especialistas, realiza mais de
300 conferências importantes por ano , participou do de-
senvolvimento de cerca de 900 padrões atuais.
3. 1989: Um grupo de empresas americanas de TI (in-
cluindo Hewlett Packard, Sun Microsystems,
Canon) organizou o OMG (Object Management
Group). Agora inclui cerca de 800 empresas associadas.
A direção principal é o desenvolvimento e promoção de
tecnologias e padrões orientados a objetos, inclusive para
a criação de aplicativos de software independentes de
plataforma em nível empresarial. Padrões CORBA, UML
e MDA bem conhecidos.
Todos esses comitês e organizações incluem a engenharia de

software em seu campo de atividade, colaboram, emitem padrões
conjuntos, usam as melhores práticas uns dos outros, etc.
Do ponto de vista dos testes de software, estamos interes-
sados na padronização da qualidade nesses padrões (como um
contexto de teste) - primeiro dos produtos manufaturados, de-
pois dos processos para seu desenvolvimento. Isso desencadeia a
ideia de que um resultado de qualidade não pode ser criado sem
9-6
T ESTE
um processo de qualidade. A garantia de qualidade é o contexto
mais geral para o teste.
A qualidade de um produto ou serviço destinado a um con-
sumidor é definida na norma ISO 9000: 2005 como o grau em
que suas características atendem aos requisitos - obrigatórios
ou implícitos.
Sem pretender ser absolutamente completos, listamos os vá-
rios métodos de controle de qualidade usados na prática no desen-
volvimento de software:
Configurando um processo de qualidade: em outras
palavras, melhoria de processos. Para uma melhoria abrangente
dos processos da empresa (abordagem de tecnologia push),
as empresas de desenvolvimento de software usam os padrões
CMM / CMMI, bem como os padrões ISO 9000 (com subse-
quente certificação oficial). Também são utilizadas estratégias
locais, que são menos caras e mais focadas na resolução de proble-
mas específicos (a abordagem pull da organização).
Métodos Formais: a utilização de formalismos matemá-
ticos para comprovação de correção, especificação, verificação de
conformidade formal, geração automática, etc.
● Prova da correção dos programas,

● Verificar certas propriedades em modelos (verificação
de modelo),
● Análise de código estático de acordo com a árvore de aná-
lise do programa (por exemplo, verificar a exatidão do có-
digo de acordo com certos critérios - trabalho preciso com
memória, pesquisa de código morto, etc.),
9-7
T ESTE
● Teste baseado em modelo: geração automática de tes-
tes e ambiente de teste de acordo com as especificações
formais dos requisitos do sistema), etc.
Na prática, eles são usados de forma limitada devido à neces-

sidade de sério treinamento matemático dos usuários, dificuldade
de domínio, muito trabalho de implantação. Eficaz para sistemas
com maiores requisitos de confiabilidade. Também há casos de
aplicação efetiva de recursos com base nesses métodos em mãos
de especialistas altamente qualificados.
Pesquisa e análise de propriedades dinâmicas de
software: Por exemplo, o perfil é amplamente utilizado - o es-
tudo do uso de memória pelo sistema, seu desempenho e outras
características por lançamento e observações diretas na forma de
gráficos, relatórios, etc. Em particular, esta abordagem é usada ao
paralelizar programas, quando procurando gargalos. Outro exem-
plo é a área chamada modelagem e análise de desempenho.
Garantir a qualidade do código: Isso inclui uma ampla
gama de atividades e métodos diferentes. Aqui estão alguns dos
mais famosos:
● Desenvolvimento de padrões de codificação no projeto e

controle da observância desses padrões. Isso inclui regras
para criar identificadores de variáveis, métodos e nomes
de classes, para formatar comentários, regras para usar
bibliotecas padrão para um projeto, etc.
● Refatoração regular para evitar a formação de código
“Vermicelli”. Existe uma tendência para a estrutura do
código se deteriorar quando uma nova funcionalidade é
introduzida, erros são corrigidos, etc. A redundância apa-
rece, fragmentos não utilizados ou fracos são formados, a
9-8
T ESTE
estrutura torna-se confusa e difícil de entender. Refatorar
é uma atividade regular de reescrever código, não com o
objetivo de adicionar nova funcionalidade, mas para me-
lhorar sua estrutura. A refatoração apareceu no contexto
de métodos “ágeis” e atualmente é ativamente suportada
por vários ambientes de desenvolvimento de software.
● Várias opções para inspeção de código, por exemplo, a
técnica de revisão de código por pares. A última é que o
código de cada participante do projeto, seletivamente,
seja lido e discutido em reuniões especiais (reuniões de
revisão de código), e isso é feito regularmente. A prática
mostra que o código geral está ficando melhor.
● Também existe uma abordagem como a “revisão” do có-
digo, usada, por exemplo, no desenvolvimento de siste-
mas críticos de tempo real. Os desenvolvedores também
estão envolvidos, mas sua função neste projeto é a revi-
são, não o desenvolvimento.
Teste: O método mais comum de controle de qualidade de

software, apresentado, de fato, em todo projeto de software.
9.2 Testando
É uma verificação da correspondência entre o comportamen-
to real do programa e seu comportamento esperado em condições
artificiais especialmente dadas. Vamos analisar essa definição
em partes.
O comportamento esperado do programa. A informação ini-
cial para teste é o conhecimento sobre como o sistema deve se com-
portar, ou seja, os requisitos para ele ou para sua parte separada. O
9-9
T ESTE
método de teste mais comum é o teste caixa preta, ou seja, quando
a implementação do sistema não está disponível para os testadores
e apenas sua interface é testada. Frequentemente, isso é reforçado
pela organização da equipe - os testadores acabam sendo funcio-
nários separados e, em algumas empresas, eles nem mesmo se co-
municam com os desenvolvedores, em princípio, a fim de conhecer
os detalhes de implementação o menos possível e atuar como uma
autoridade de teste tão completamente quanto possível. Há um
teste de caixa branca quando o código o software está disponível
para os testadores e é usado como fonte de informações sobre o
sistema. Seu diagrama é mostrado na figura 9-1.
Figura 9-1: Exemplo de Teste de Caixa Branca
9-10
T ESTE
Nesta figura, você pode ver que com base nos requisitos do
sistema, uma implementação e um modelo de teste do sistema são
criados. O teste é uma comparação dessas duas visões para revelar
suas inconsistências. Quanto mais independentes essas represen-
tações forem umas das outras, maior será o benefício de sua com-
paração. Caso contrário, se os testadores fizerem uso significativo
de informações sobre a implementação do sistema ao escrever tes-
tes, eles podem inadvertidamente introduzir erros de implemen-
tação nos testes. A discrepância encontrada durante o teste ainda
não é um erro, porque os próprios testadores podem interpretar
mal os requisitos, pode haver erros nos testes e nas ferramentas
de teste.
Essa abordagem também se consolida na organização de
equipes de programadores - os testadores, via de regra, são sepa-
rados dos desenvolvedores. Essas são pessoas diferentes, funções
incompatíveis em MSF. Os autores ouviram uma história sobre
uma empresa americana onde desenvolvedores e testadores sen-
taram em andares diferentes, usaram roupas diferentes (testado-
res em ternos, desenvolvedores em suéteres) e os chefes
não encorajaram relacionamentos não profissionais entre esses
grupos. Isso, é claro, é um extremo, mas mais uma vez enfatiza o
quão importante é para os testadores terem um ponto de vista di-
ferente sobre o sistema daquele dos desenvolvedores. Mas, é claro,
ambos devem partir da visão geral do sistema - seus requisitos.
Especialmente dado, condições artificiais, - as condições em
que o teste é realizado. Ao mesmo tempo, o posto-chave aqui é a
presença de testes - etapas reproduzíveis de manipulação com o
sistema, levando ao seu funcionamento incorreto. O conceito do
teste é muito importante, pois é necessário não apenas detec-
tar o comportamento incorreto do sistema, mas criar e corrigir
um algoritmo de reprodução do erro - a fim de que repita para o
9-11
T ESTE
desenvolvedor ou para que o próprio desenvolvedor possa repro-
duzir o bug. Se o erro não for reproduzido, não há como corrigi-lo.
Os testes podem ser “manuais” e automatizados. Um teste
“manual” é uma sequência de ações de um testador que ele (ou
um desenvolvedor) pode reproduzir e ocorrerá um erro. Nor-
malmente, em controles de erro, essas sequências de ações estão
contidas na descrição do erro. Um teste automático é um programa
que afeta o sistema e verifica uma ou outra de suas propriedades.
Um teste automático, comparado a um teste “manual”, pode ser
facilmente reproduzido sem intervenção humana. Você pode criar
suítes de teste e executá-los com frequência, por exemplo, no modo
de teste de regressão. Além disso, testes automatizados podem ser
gerados de acordo com especificações de nível superior, por exem-
plo, de acordo com requisitos de sistema formalmente descritos. E,
por exemplo, testes para compiladores podem ser gerados a par-
tir de uma descrição formal de uma linguagem de programação.
Assim, as vantagens dos testes automatizados sobre os “manuais”
são óbvias.
Agora vamos falar sobre as dificuldades dos tes-
tes automatizados.
Primeiro, para que os testes sejam executados automatica-
mente, são necessários produtos de software apropriados, que
também são parte integrante das condições artificiais especial-
mente especificadas que estamos discutindo agora. Vamos cha-
má-los de ferramentas de teste. A tarefa deles é executar um teste
no sistema, ou seja, “Execução” de todo um pacote de testes, bem
como análise dos resultados obtidos e seu processamento. Além
disso, uma tarefa importante das ferramentas de teste é fornecer
acesso de teste ao sistema por meio de algumas de suas interfa-
ces. O acesso ao sistema pode ser difícil, por exemplo, devido a
9-12
T ESTE
circunstâncias políticas, quando um subsistema de algum sistema
estratégico é feito por desenvolvedores terceirizados e os desenvol-
vedores limitam severamente o acesso a este sistema abrangente.
Ou, devido às limitações de hardware, é difícil “subir” no hardware
onde o código-alvo está sendo executado.
Além disso, muitas vezes é difícil testar perfeitamente um
sistema com impacto mínimo e, ao mesmo tempo, analisar todos
os aspectos de sua operação. De modo geral, configurar e imple-
mentar ferramentas de teste de terceiros geralmente é caro e as-
sustador. Desenvolver suas próprias ferramentas de teste também
não é fácil.
Em segundo lugar, geralmente há um problema de recursos
de teste automatizados. Especialmente com a geração automáti-
ca de testes: muitas vezes é possível gerar automaticamente um
grande número de testes, portanto, se você ainda os executa regu-
larmente, em modo de integração contínua, os recursos de sistema
disponíveis não serão suficientes. Ao mesmo tempo, a qualidade
dos testes pode acabar sendo insatisfatória - erros raramente são
encontrados ou não são encontrados. O fato é que o número de to-
dos os estados possíveis de um sistema de software é muito grande
e os testes não podem cobrir todos eles. Na prática, em projetos
reais, são determinados critérios de teste que determinam o “pa-
drão” de qualidade que deve ser alcançado neste projeto. Afinal,
boa qualidade custa caro e é óbvio que software diferente tem qua-
lidade diferente, por exemplo, sistema de controle do reator nu-
clear e editor de texto. Na prática, muitas vezes, a qualidade do
software é determinada pelo orçamento do projeto para seu desen-
volvimento. Além disso, devido aos recursos limitados para teste,
geralmente é aconselhável determinar os aspectos do software que
são mais importantes - tanto para o desempenho geral do sistema
quanto para o cliente. Por exemplo, ao testar um aplicativo da Web
9-13
T ESTE
que fornece um serviço de criação de anúncios para a venda de
imóveis, estes critérios foram:
● A correção das transições de um mestre complexo - em

particular, em conexão com a possibilidade de transições
para trás;
● A integridade dos dados inseridos pelo usuário sobre os
anúncios criados;
Finalmente, além de limitar o número de testes para selecio-

ná-los, é importante executá-los em alguns (nem todos possí-
veis!) dados de entrada. O princípio da fatoração é frequentemen-
te usado aqui - o conjunto de todos os valores de entrada possíveis
é dividido em classes que são significativas do ponto de vista do
teste e os testes não são “executados” em todos os valores de entra-
da possíveis, mas em um conjunto de valores É tirado de cada clas-
se. Por exemplo, eles testam uma determinada função do sistema
para seus valores de limite - valores de parâmetros muito grandes,
muito pequenos, etc.
Vamos destacar os seguintes tipos de teste:
Teste de unidade: um módulo separado está sendo testa-
do, isolado do resto do sistema. O caso de uso mais comum é testar
um módulo pelo próprio desenvolvedor, verificando se os módulos,
classes e métodos individuais fazem o que se espera deles. Vários
IDEs suportam amplamente ferramentas de teste de unidade - por
exemplo, a popular biblioteca gratuita para Visual Studio NUnit,
JUnit para Java, etc. Os testes de unidade gerados pelo desenvol-
vedor são frequentemente incluídos em um conjunto de testes de
regressão e, portanto, podem ser executados várias vezes.
Teste de integração: dois ou mais componentes são tes-
tados quanto à compatibilidade. Este é um tipo de teste muito
9-14
T ESTE
importante, uma vez que diferentes componentes podem ser cria-
dos por diferentes pessoas, em diferentes momentos, usando di-
ferentes tecnologias. Esse tipo de teste, é claro, deve ser aplicado
pelos próprios programadores, a fim de, pelo menos, ter certeza
de que tudo convive em uma primeira aproximação. Além disso,
os meandros da integração podem ser investigados por testadores.
Deve-se notar que este tipo de erro - “Erros de articulação” não
são fáceis de detectar e corrigir. Durante o desenvolvimento, nem
todos os componentes estão prontos juntos, a integração é atrasa-
da e, no final, bugs difíceis são descobertos (no sentido de que
corrigi-los requer um trabalho significativo). A saída aqui
é a integração inicial do sistema e o uso posterior da prática de
integração contínua.
Teste de sistema: este teste de todo o sistema como um
todo, geralmente por meio de sua interface de usuário. Ao mesmo
tempo, testadores, gerentes e desenvolvedores se concentram em
como o software parece e funciona como um todo, se é convenien-
te, se ele atende às expectativas do cliente. Ao mesmo tempo, po-
dem surgir vários defeitos, como inconvenientes no uso de certas
funções, requisitos esquecidos ou “mal” compreendidos.
Teste de regressão: teste do sistema no processo de seu
desenvolvimento e manutenção para não regressão. Ou seja, ve-
rifica-se que as mudanças no sistema não agravaram a funcionali-
dade já existente. Para isso, são criados pacotes de teste de regres-
são, que são executados em intervalos regulares - por exemplo, em
modo batch, associado ao procedimento de integração contínua.
Teste de Estresse: testar o sistema para operação correta
com grandes quantidades de dados. Por exemplo, verificar bancos
de dados para o processamento correto de um grande (limitan-
te) volume de registros, estudar o comportamento do software de
9-15
T ESTE
servidor com um grande número de conexões de clientes, experi-
mentando a limitação de tráfego para sistemas de rede e telecomu-
nicações, abrindo um grande número de arquivos, projetos, etc. ao
mesmo tempo.
Teste de estresse: testar o sistema quanto à resistência a
situações imprevistas. Este tipo de teste não é necessário para to-
dos os sistemas, pois implica um alto nível de qualidade.
Teste de aceitação: testes realizados após a aceitação do
sistema do cliente. Além disso, vários padrões geralmente incluem
suítes de teste de aceitação. Por exemplo, existe um grande conjun-
to de testes mantidos pela Sun Microsystems que são necessários
para a execução de todas as novas implementações de máquina
Java. Acredita-se que somente depois que todos esses testes forem
aprovados com sucesso, a nova implementação poderá ser chama-
da de Java.
9.3 Lidando com erros

Uma interface de comunicação especial é necessária entre
programadores e testadores. Afinal, existem muitos bugs, conser-
tá-los leva tempo e os testadores devem se certificar de que eles
foram realmente corrigidos pelos desenvolvedores. Além disso, os
gerentes precisam de estatísticas sobre bugs encontrados e corri-
gidos - esta é uma boa ferramenta para controle de projeto. Tudo
isso é mostrado na Figura 9-2 Para lidar com esse fluxo de infor-
mações e fornecer os serviços necessários e convenientes, existe
uma classe especial de ferramentas de software - sistemas de ras-
treamento de bugs.
9-16
T ESTE
Figura 9-2: Exemplo de Trabalhos com Bugs
Via de regra, a descrição do erro no sistema de controle de

erros possui os seguintes atributos principais:
9 A pessoa responsável por verificar é o testador que o en-

controu e que verifica se as correções feitas pelo desenvol-
vedor realmente corrigem o erro;
9 A pessoa responsável por corrigi-lo - o desenvolvedor
para quem o bug é enviado para correção;
9 Status, por exemplo, bug encontrado, bug corrigido, bug
fechado, bug reaparecido, etc.
Esta lista é amplamente expandida em vários softwares de

controle de erros, mas esses são os atributos principais. O uso des-
ses sistemas tem sido uma prática comum no desenvolvimento de
software, junto com o controle de versão e muitas outras ferra-
mentas. Eles incluem:
9 Um banco de dados para armazenar erros;

9 Uma interface para este banco de dados para inserir no-
vos erros e definir seus inúmeros atributos, para visuali-
zar erros com base em vários filtros - por exemplo, todos
9-17
T ESTE
os erros encontrados no último mês, todos os erros pelos
quais este desenvolvedor é responsável, etc.;
9 Acesso à rede, à medida que os projetos são cada vez
mais distribuídos;
9 Uma interface de software para os recursos de integração
de software de tais sistemas com outro software que su-
porte o desenvolvimento de software (por exemplo, com
ferramentas de integração contínua - eles podem inserir
automaticamente os erros encontrados durante a execu-
ção automática de testes no banco de dados).
9-18
1) O desenvolvimento do mercado mundial levou ao fato de que muitos bens

e serviços começaram a se espalhar pelo mundo, os serviços globais
começaram a se desenvolver. Estamos falando de:
( ) -a) Controle de Qualidade

( ) -b) Planejamento e Controle
( ) -c) Tomada de decisão
( ) -d) Comunicação da Equipe
2) Com o objetivo de eliminar as barreiras técnicas à indústria, ao comércio

e aos negócios, surgidas pelo fato de em diferentes países para as mes-
mas tecnologias e produtos estarem em vigor diferentes normas, come-
çaram a ser criados comitês de normas nacionais e internacionais. Em
1865 - Forma-se um comitê, hoje denominado de:
( ) -a) ISDN
( ) -b) ADSL
( ) -c) OSI
( ) -d) SDL
( ) -e) ITU
3) Um dos padrões ITU mais famosos é:
( ) -a) Tem como objetivo a padronização da qualidade de bens e

serviços.
( ) -b) OSI um modelo de protocolo de rede aberto de 7 camadas no
qual todas as interfaces e protocolos de rede padrão moder-
nos são baseados também um padrão ISO.
( ) -c) Definição de software de qualidade e vários atributos que
descrevem essa qualidade.
9-19
( ) -d) Adaptação das normas ISO 9000 à produção de software em
linha com a garantia da qualidade no ciclo de vida do software.
( ) -e) Definição da qualidade, definição de um sistema de suporte
da qualidade em todas as fases da vida de um produto.
4) Em 1946 é criada a organização chamada de:
( ) -a) ITU
( ) -b) OSI
( ) -c) SDL
( ) -d) ISO
( ) -e) ISDN
5) É considerado um padrão ISO:
( ) -a) Linguagens de design visual para sistemas de telecomunica-

ções, SDL e MSC, posteriormente incorporado à UML.
( ) -b) ISO / IEC 90003: 2004 - adaptação das normas ISO 9000 à
produção de software em linha com a garantia da qualidade
no ciclo de vida do software.
( ) -c) OSI um modelo de protocolo de rede aberto de 7 camadas no
qual todas as interfaces e protocolos de rede padrão moder-
nos são baseados; também um padrão ISSO.
( ) -d) ADSL uma conhecida tecnologia de modem que permite
usar uma linha telefônica para acessar a Internet sem blo-
quear o serviço telefônico regular.
( ) -e) ISDN telefonia digital, combinando serviços de telefonia e
transmissão de dados.
6) A qualidade de um produto ou serviço destinado a um consumidor é de-

finida na norma:
( ) -a) ISO 9000: 2005

( ) -b) ISO 9126: 2001
( ) -c) ISO / IEC 90003: 2004
( ) -d) ISO 9000
( ) -e) ISO 9122: 2005
9-20
7) Para uma melhoria abrangente dos processos da empresa abordagem de
tecnologia push, as empresas de desenvolvimento de software usam os
padrões CMM / CMMI, bem como os padrões:
( ) -a) ISO 9126: 2001

( ) -b) ISO 9000: 2005
( ) -c) ISO 9000
( ) -d) ISO / IEC 90003: 2004
( ) -e) ISO 9122: 2005
8) A utilização de formalismos matemáticos para comprovação de correção,

especificação, verificação de conformidade formal, geração automática,
etc. Estamos falando de:
( ) -a) Métodos Formais

( ) -b) Configurando um processo de qualidade
( ) -c) Controle de Qualidade
( ) -d) Planejamento e Controle
( ) -e) Tomada de decisão
9) Garantir a qualidade do código: Isso inclui uma ampla gama de ativida-

des e métodos diferentes. Um dos famosos é:
( ) -a) Teste baseado em modelo: geração automática de testes e

ambiente de teste de acordo com as especificações formais
dos requisitos do sistema), etc.
( ) -b) Análise de código estático de acordo com a árvore de análise
do programa por exemplo, verificar a exatidão do código de
acordo com certos critérios trabalho preciso com memória,
pesquisa de código morto, etc.
( ) -c) Verificar certas propriedades em modelos, verificação de
modelo.
( ) -d) Prova da correção dos programas.
( ) -e) Refatoração regular para evitar a formação de código
“Vermicelli”.
9-21
10) É o método mais comum de controle de qualidade de software, apresen-
tado, de fato, em todo projeto de software:
( ) -a) Teste
( ) -b) Métodos Formais
( ) -c) Configurando um processo de qualidade
( ) -d) Tomada de decisão
( ) -e) Planejamento e Controle
9-22
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 10:
CMMI
CM M I
O CMMI é uma descrição do processo de desenvolvimen-
to de software ideal, oferece algum modelo do processo. Ou seja,
o processo destaca e descreve cuidadosamente alguns dos princi-
pais componentes do ponto de vista do CMMI. Essa perspectiva
do CMMI é melhorar os processos de desenvolvimento. Ou seja,
essas partes significativas do processo são áreas para melhorias. O
CMMI distingue entre os seguintes grupos de áreas de melhoria:
gestão de processos, gestão de projetos, áreas de engenharia, áreas
de serviço. Nesse caso, todas as áreas são especificadas na forma
de requisitos que determinam não como eles são implementados,
mas os requisitos de interface. Isso tem duas consequências.
Figura 10-1: Logo CMMI
Corolário 1. O CMMI permite diferentes implementações

e não é uma metodologia de desenvolvimento de software, como
MSF, Scrum, RUP, etc. Este último pode ser utilizado em sua
implementação. Portanto, por exemplo, há um modelo de processo
especial no VSTS para CMMI chamado MSF para CMMI.
10-2
CM M I
Corolário 2. O CMMI é usado para certificar empresas
quanto à maturidade de seus processos. Inicialmente, no final dos
anos 80 e início dos 90, o CMM (então ainda não CMMI) foi
criado precisamente como um meio de certificar subcontratados
federais. E só mais tarde, tendo se difundido no mundo, passou a
ser utilizado e a focar na melhoria de processos.
Vamos observar mais uma característica importante do
CMMI. Não se destina apenas ao desenvolvimento de sistemas
de software. Muitas grandes empresas não produzem software,
mas visam produtos, nos quais o software é incluído como parte
integrante. Por exemplo, aviação, indústria aeroespacial. Ou seja,
o desenvolvimento de software ocorre junto com outros tipos de
trabalho de engenharia. E muitas vezes acontece que mais de dois
tipos diferentes de engenharia estão envolvidos em um projeto. A
tarefa do CMMI é fornecer a esses projetos e empresas uma plata-
forma única para organizar o processo de desenvolvimento.
O CMMI foi projetado para ajudar a melhorar o desempe-
nho, fornecendo às empresas tudo o que precisam para desenvol-
ver consistentemente melhores produtos e serviços. Mas o CMMI
é mais do que um modelo de processo; também é um modelo com-
portamental. As empresas podem usar o CMMI para enfrentar a
logística de melhorar o desempenho desenvolvendo benchmarks
mensuráveis, mas o CMMI também pode ajudar a criar uma es-
trutura para incentivar comportamentos produtivos e eficientes
em toda a organização.
10.2 Evolução do CMMI

O CMMI foi desenvolvido para combinar múltiplos mode-
los de maturidade empresarial em uma única estrutura. Nasceu do
10-3
CM M I
modelo de Software CMM desenvolvido entre 1987 e 1997. CmMI
Versão 1.1 foi lançado em 2002, seguido pela Versão 1.2 em
2006, e versão 1.3 em 2010; V1.3 foi substituído por V2.0 em
março de 2018.
Em sua primeira iteração como o Software CMM, o modelo
foi adaptado para a engenharia de software. As versões seguintes
do CMMI tornaram-se mais abstratas e generalizadas, permitindo
que ele fosse aplicado ao desenvolvimento de hardware, software e
serviços em todos os setores. Com o lançamento do V2.0, o proces-
so foi simplificado — o CMMI abordou anteriormente três áreas
de interesse, incluindo desenvolvimento de produtos e serviços,
estabelecimento de serviços e aquisição de produtos e serviços,
mas todas elas foram incorporadas em um modelo autônomo.
Cada iteração do CMMI visa ser mais fácil para as empresas
entenderem e usarem do que a última, e cada modelo foi proje-
tado para ser mais econômico e mais fácil de integrar ou implan-
tar. Incentiva as empresas a se concentrarem na qualidade sobre
a quantidade, estabelecendo benchmarks para vetar fornecedores
e fornecedores, identificar e resolver problemas de processo, mini-
mizar riscos e construir uma cultura corporativa que apoie o mo-
delo CMMI.
10.3 Níveis de maturidade do processo de

acordo com CMMI
Ao contrário do modelo CMM clássico, que era rigidamente
hierárquico e permitia apenas a melhoria sequencial dos processos
entre os níveis, o modelo CMMI tem duas dimensões - sequen-
cial, o mesmo que no CMM, e contínua, permitindo a melhoria
dos processos na organização até certo ponto em uma ordem
10-4
CM M I
arbitrária. Aqui, vamos nos concentrar no modelo sequencial.
Possui 5 níveis de maturidade do processo, conforme mostrado
na Figura 10-2:
Figura 10-2: Níveis de maturidade do processo de acordo com CMMI
Fonte: https://audir.files.wordpress.com/2012/11/niveis-cmmi1.png
1. Inicial: (nível de maturidade 1) é o nível em que, por

definição, qualquer empresa se encontra. Nesse nível, o
desenvolvimento de software é mais ou menos caótico.
2. Repetível: (nível de maturidade 2) - já existem polí-
ticas e procedimentos de organização de processos, apro-
vados ao nível da empresa. Mas, na sua totalidade, os pro-
cessos existem apenas no âmbito de projetos individuais.
3. Definido: (nível de maturidade 3) - aqui vem um pro-
cesso padrão no nível de toda a empresa como um todo.
Este é um conjunto grande e em constante crescimento
10-5
CM M I
de ativos de processo - modelos de documentos, mode-
los de ciclo de vida, ferramentas de software, práticas,
etc. Qualquer processo específico é obtido eliminando
este padrão.
4. Gerenciado: quantitativamente (nível de maturida-
de 4) implica o surgimento de um sistema de medições na
empresa, que se dá com base em um processo padroniza-
do e permite o controle quantitativo do desenvolvimento.
5. Otimizando: (nível de maturidade 5) implica me-
lhoria contínua dos processos de desenvolvimento, tanto
incrementais, passo a passo e revolucionários. Ao mesmo
tempo, essas mudanças não são forçadas, mas problemas
e dificuldades antecipatórias. O processo está se aprimo-
rando e constantemente - ou seja, os mecanismos apro-
priados foram implementados.
10.4 Áreas de melhorias
Tabela 10-1: Áreas de melhorias
Nível Áreas de melhoria

Gerenciamento de requisitos
Planejamento de projeto
Supervisão e controle do projeto
Gestão de contratos de fornecedores
2
Medições e análises
Verificação de processos e produtos para conformidade
com padrões
Gerenciamento de configurações
10-6
CM M I
Nível Áreas de melhoria
Desenvolvimento de requisitos
Solução técnica
Montagem e entrega do produto
Verificação do produto para conformidade com os requisi-
tos (verificação)
Verificação do produto para a finalidade pretendida (validação)
Foco nos processos organizacionais
Definição de processos organizacionais
Organização de treinamento
3
Gestão integrada de projetos
Gestão de riscos
Gestão de equipe conjunta
Gestão abrangente de fornecedores
Tomada de decisão: avaliando alternativas
Crie um ambiente colaborativo em sua organização
Desenvolvimento de requisitos
Solução técnica
Montagem e entrega do produto
Estabelecer indicadores de desempenho para os processos
4 da organização
Gestão quantitativa de projetos
Seleção e implementação de melhorias na organização
5 Análise das causas dos problemas e prevenção de sua
ocorrência no futuro
10-7
CM M I
10.5 Atualização do CMMI
A versão mais recente do CMMI, Versão 2.0, foca mais
fortemente no desempenho e em como o desempenho impacta
os negócios e como entender as necessidades de desempenho de
uma organização. Há informações sobre como estabelecer metas
de desempenho e, em seguida, rastrear essas metas para garan-
tir que elas sejam alcançadas em todos os níveis de maturidade
dos negócios.
A versão 2.0 também se integra melhor com processos ágeis
e Scrum, com foco em segurança e segurança. Se você já tem uma
prática ágil, o CMMI V2.0 vai ajudá-lo a contornar ou melhorar
processos estabelecidos que já funcionam para o seu negócio. O
CMMI V2.0 também visa reduzir o custo global das avaliações e
encurtar o tempo necessário para avaliar e organização. O CMMI
V2.0 também reduziu a quantidade de conhecimento técnico in-
cluído, por isso é mais fácil para quem está fora da indústria tec-
nológica ler e entender. Há também uma plataforma online onde
os usuários podem construir e projetar um modelo que atenda às
necessidades específicas da organização.
O Instituto CMMI também incluiu mais informações sobre
como demonstrar o ROI, para que os líderes possam colocar ou-
tros executivos a bordo. Os benchmarks de desempenho e as metas
descritas no CMMI podem ajudar as empresas a garantir que to-
dos os projetos e processos sejam econômicos ou rentáveis. A ver-
são mais recente também é mais fácil de implantar em toda uma
organização com linguagem menos técnica e plataformas e ferra-
mentas on-line atualizadas e personalizáveis que fornecerão orien-
tação para adotar o CMMI ou fazer a transição para o V2.0 a partir
do V1.3. Também está disponível em vários idiomas traduzidos.
10-8
CM M I
10.6 Certificações CMMI
As certificações CMMI são oferecidas diretamente através
do Instituto CMMI, que certifica indivíduos, avaliadores, ins-
trutores e praticantes. O Instituto CMMI oferece as seguin-
tes certificações:
9 CMMI Associate: demonstra seu comprometimento e

habilidades quando se trata de capacidade e melhoria de
desempenho. A certificação valida que você tem as habili-
dades e conhecimentos para conectar o modelo CMMI ao
valor de negócio e participar como Membro da Equipe de
Avaliação (CTM).
9 CMMI Professional: O próximo nível de certificação
é a certificação CMMI Professional, que demonstra sua
capacidade de aplicar o modelo CMMI em uma estrutura
organizacional através de roteiros para desempenho, co-
aching de equipe, gestão de mudanças organizacionais e
fomento a uma cultura de melhoria.
9 Certified CMMI Lead Appraiser: Como essa certifi-
cação, você estará qualificado para avaliar as organizações
para determinar sua capacidade ou nível de maturidade
conforme descrito no modelo CMMI. Os pedidos são re-
visados pelo comitê de Revisão de Pedidos de Avaliação do
ISACA, que avaliará suas qualificações para a certificação.
9 Certified CMMI Instructor: Essa certificação permi-
te que você lidere cursos instrutivos sobre CMMI. Você
precisará de uma organização patrocinadora que tam-
bém seja parceira da ISACA e que seja licenciada para
uso do conjunto de produtos CMMI para se qualificar
para o exame.
10-9
CM M I
10.7 Ferramentas CMMI
O Instituto CMMI autoriza organizações terceirizadas a ven-
der ferramentas e serviços CMMI, a lista de fornecedores apro-
vados é extensa e você pode pesquisar por produto, localização e
idioma no site do Instituto CMMI.
O tipo de ferramentas CMMI que funcionarão melhor para
sua organização dependerá das necessidades do seu negócio. Se-
guindo o CMMI, você identificará as melhores ferramentas duran-
te o Nível de Maturidade 2 ou 3; neste ponto, seu consultor CMMI
oferecerá recomendações ou ajudará você a projetar ferramentas
personalizadas com base em extensas pesquisas. A categoria
mais comum de ferramentas que você precisará conside-
rar inclui:
9 Gerenciamento de projetos e documentos

9 Rastreador de bugs
9 Avaliação
9 Gerenciamento de requisitos e design
9 Ferramentas de decisão e análise
9 Ferramentas de métricas
9 Aplicativo de integração
10-10
1) É uma descrição do processo de desenvolvimento de software ideal, ofe-

rece algum modelo do processo. Estamos falando de:
( ) -a) SDL
( ) -b) CMMI
( ) -c) ITU
( ) -d) ISDN
( ) -e) OSI
2) Nesse caso, todas as áreas são especificadas na forma de requisitos que

determinam não como eles são implementados, mas os requisitos de
interface. Isso tem duas consequências. Umas dela é:
( ) -a) Corolário 2. O CMMI é usado para certificar empresas quan-

to à maturidade de seus processos.
( ) -b) Corolário 1. O CMMI não permite diferentes implementa-
ções e não é uma metodologia de desenvolvimento de sof-
tware, como MSF, Scrum, RUP, etc.
( ) -c) O processo destaca e descreve menos alguns dos principais
componentes do ponto de vista do CMMI.
( ) -d) Perspectiva do CMMI é melhorar menos os processos de
desenvolvimento.
( ) -e) O CMMI não distingue entre os seguintes grupos de áreas de
melhoria: gestão de processos, gestão de projetos, áreas de
engenharia, áreas de serviço.
10-11
I) Vamos observar mais uma característica importante do CMMI. Não se
destina apenas ao desenvolvimento de sistemas de software. Muitas gran-
des empresas não produzem software, mas visam produtos, nos quais o
software é incluído como parte integrante.
II) E muitas vezes acontece que mais de dois tipos diferentes de engenha-
ria estão envolvidos em um projeto. A tarefa do CMMI é fornecer a esses
projetos e empresas uma plataforma única para organizar o processo de
desenvolvimento.
III) O CMMI não foi projetado para ajudar a melhorar o desempenho, forne-
cendo às empresas tudo o que precisam para desenvolver consistentemente
melhores produtos e serviços.
Estão INCORRETAS:
( ) -a) I e II
( ) -b) II, somente
( ) -c) I e III
( ) -e) I, somente
4) O CMMI foi desenvolvido para combinar múltiplos modelos de maturida-

de empresarial em uma única estrutura. Nasceu do modelo de Software:
( ) -a) CMM
( ) -b) CMMI
( ) -c) OSI
( ) -d) SDL
( ) -e) ITU

I) Em sua primeira iteração como o Software CMM, o modelo foi adaptado
para a engenharia de software.
II) As versões seguintes do CMMI tornaram-se menos abstratas e genera-
lizadas, permitindo que ele fosse aplicado ao desenvolvimento de hardware,
software e serviços em todos os setores.
10-12
III) Cada iteração do CMMI visa ser mais fácil para as empresas entende-
rem e usarem do que a última, e cada modelo foi projetado para ser mais
econômico e mais fácil de integrar ou implantar.
Estão Corretas:
( ) -a) I e II
( ) -b) II e III
( ) -c) I e III
( ) -e) II, somente
6) Ao contrário do modelo CMM clássico, que era rigidamente hierárquico e

permitia apenas a melhoria sequencial dos processos entre os níveis, o
modelo CMMI tem duas dimensões - sequencial, o mesmo que no CMM,
e contínua, permitindo a melhoria dos processos na organização até cer-
to ponto em uma ordem arbitrária. Possui 5 níveis de maturidade do pro-
cesso, um deles é:
( ) -a) Métodos Formais

( ) -b) Planejamento e Controle
( ) -c) Tomada de decisão
( ) -d) Repetível
( ) -e) Configurando um processo de qualidade
7) Implica melhoria contínua dos processos de desenvolvimento, tanto in-

crementais, passo a passo e revolucionários. Estamos falando do nível:
( ) -a) Inicial
( ) -b) Otimizando
( ) -c) Gerenciado
( ) -d) Definido
( ) -e) Repetível
8) A versão mais recente do CMMI é:
( ) -a) Versão 2.1

( ) -b) Versão 1.0
10-13
( ) -c) Versão 2.0
( ) -d) Versão 1.2
( ) -e) Versão 1.5
9) São oferecidas diretamente através do Instituto CMMI, que certifica indi-

víduos, avaliadores, instrutores e praticantes. O Instituto CMMI oferece
as seguintes certificações. Estamos falando de:
( ) -a) Certificações CMMI

( ) -b) Atualização do CMMI
( ) -c) Áreas de melhorias
( ) -d) Evolução do CMMI
( ) -e) Lidando com erros
10) O Instituto CMMI oferece as seguintes certificações. Uma delas é CMMI

Associate que é:
( ) -a) O próximo nível de certificação é a certificação CMMI Pro-

fessional, que demonstra sua capacidade de aplicar o modelo
CMMI em uma estrutura organizacional através de roteiros
para desempenho, coaching de equipe, gestão de mudanças
organizacionais e fomento a uma cultura de melhoria.
( ) -b) Como essa certificação, você estará qualificado para avaliar
as organizações para determinar sua capacidade ou nível de
maturidade conforme descrito no modelo CMMI.
( ) -c) Essa certificação permite que você lidere cursos instrutivos
sobre CMMI.
( ) -d) Você precisará de uma organização patrocinadora que tam-
bém seja parceira da ISACA e que seja licenciada para uso do
conjunto de produtos CMMI para se qualificar para o exame.
( ) -e) Demonstra seu comprometimento e habilidades quando se
trata de capacidade e melhoria de desempenho.
10-14
DISCIPLINA:
Engenharia de
Software
UNIDADE 6:
METODOLOGIAS ÁGEIS E
EXEMPLO PRÁTICO
Caro(a) Aluno(a)
Seja bem-vindo(a)!
Nesta sexta unidade, daremos orientações sobre o uso das metodolo-

gias ágeis no processo de desenvolvimento de software, seguido de um
exemplo prático de desenvolvimento.
Nesta ultima unidade, iremos abordar sobre alguns modelos de me-
todologias ágeis a serem adotadas no desenvolvimento de software,
bem como sobre a importância de seu uso; por fim, será apresentado
um exemplo prático de projeto de sistema de software.
9 Metodologias Ágeis
9 Exemplo prático de projeto de Sistema de Software
Bons estudos!!!
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 11:
METODOLOGIAS ÁGEIS
METO D O LO G IAS ÁG EI S
Métodos ágeis de desenvolvimento de software surgiram
como uma alternativa aos métodos formais e Metodologias pesa-
das como CMM e RUP. Programadores talentosos não querem fa-
zer do desenvolvimento de software uma rotina, eles querem ter o
máximo de liberdade e prometer alta eficiência em troca. Por outro
lado, a prática mostra que Metodologias “pesadas” são ineficazes
em um número significativo de casos. Os principais pontos dos
métodos Ágeis consagrados no Manifesto Ágil em 2007
são os seguintes:
9 Indivíduos e interações em vez de processos e software;

9 Software funcional em vez de documentação complexa;
9 Interação com o cliente em vez de contratos rígidos;
9 Reagir às mudanças em vez de seguir um plano.
Na verdade, ágil se refere a equipes pequenas e auto-organi-

zadas de pessoas altamente qualificadas e enérgicas que são orien-
tadas para os negócios, ou seja, desenvolvendo seu próprio produ-
to para lançamento no mercado. Essa abordagem obviamente tem
seus prós e contras.
11.2 Extreme Programming (XP)

O método flexível mais famoso é o Extreme Programming
(conhecido por seu nome abreviado - XP). Foi criado pelo
talentoso engenheiro de software Kent Beck como resultado de
seu trabalho em 1996-1999 no sistema de controle de pagamento
da Chrysler.
11-3
O modelo de processo XP parece uma sequência frequente
de lançamentos de produtos, o mais frequente possível. Mas, ao
mesmo tempo, é imperativo que o lançamento inclua uma funcio-
nalidade totalmente nova. A seguir estão os princípios básicos de
organização do processo XP.
1. Planning Game, que parte do princípio de que o desen-

volvimento de software é um diálogo entre possibilidades
e desejos, e ambos vão mudar.
2. Design simples versus design redundante.
3. Metáfora: a essência do projeto deve caber em 1-2 fra-
ses amplas ou de alguma forma.
4. Refatorar é um processo de melhoria contí-
nua (simplificação)
5. Estrutura de software necessária em conexão com a adi-
ção de novas funcionalidades.
6. Programação em pares: um é programação, o outro
está pensando em toda a abordagem, em novos testes, em
simplificar a estrutura do programa, etc.
7. Propriedade Coletiva.
8. Participação do cliente no desenvolvimento
(Cliente On-site): o representante do cliente está in-
cluído na equipe de desenvolvimento.
9. Criação e uso de padrões de codificação em um
projeto: ao escrever código (criar e) usar padrões
para nomes de identificadores, comentários de compo-
sição, etc.
10. Teste: os desenvolvedores testam seus próprios softwa-
res, intercalados com o desenvolvimento. No entanto,
é recomendável criar testes antes que a funcionalidade
11-4
correspondente seja implementada. O cliente cria tes-
tes funcionais.
11. Integração contínua. O próprio desenvolvimento é apre-
sentado como uma sequência de lançamentos.
12. Semana de trabalho de 40 horas.
No entanto, o XP não foi usado na íntegra nem mesmo por

seus autores e é, ao contrário, uma filosofia. Além disso, certas
práticas XP são conhecidas e implementadas, como programação
em pares, propriedade coletiva de código e, é claro, refatoração de
código. A ideia de um design de projeto simples e não redundante
também teve um impacto significativo no mundo do desenvolvi-
mento de software. Um método de desenvolvimento “ágil” mais
prático é o Scum.
11.3 Kaban
O Método Kanban é um meio de projetar, gerenciar e melho-
rar sistemas de fluxo para o trabalho de conhecimento. O método
também permite que as organizações comecem com seu fluxo de
trabalho existente e impulsionem mudanças evolutivas. Eles po-
dem fazer isso visualizando seu fluxo de trabalho, limitar o traba-
lho em andamento (WIP) e parar de iniciar e começar a terminar.
O Método Kanban recebe seu nome a partir do uso de kanban
– mecanismos de sinalização visual para controlar o trabalho em
andamento para produtos de trabalho intangíveis.
Kanban pode ser usado em qualquer configuração de traba-
lho de conhecimento, e é particularmente aplicável em situações
em que o trabalho chega de forma imprevisível e/ou quando você
11-5
quer implantar o trabalho assim que ele está pronto, em vez de
esperar por outros itens de trabalho.
As equipes que aplicam a Kanban para melhorar os
serviços que oferecem abraçam os seguintes valores:
9 Transparência: compartilhar informações abertamen-

te usando linguagem clara e direta melhora o fluxo de va-
lor do negócio.
9 Equilíbrio: diferentes aspectos, pontos de vista e capa-
cidades devem ser equilibrados para alcançar a eficácia.
9 Colaboração: Kanban foi criado para melhorar a forma
como as pessoas trabalham juntas.
9 Foco no Cliente: Os sistemas Kanban visam otimizar o
fluxo de valor para clientes que são externos do sistema,
mas podem ser internos ou externos à organização em
que o sistema existe.
9 Fluxo: O trabalho é um fluxo contínuo ou episódico
de valor.
9 Liderança: A liderança (a capacidade de inspirar outras
pessoas a agir via exemplo, palavras e reflexão) é necessá-
ria em todos os níveis para realizar uma melhoria contí-
nua e entregar valor.
9 Compreensão: O autoconhecimento individual e orga-
nizacional do ponto de partida é necessário para avan-
çar e melhorar.
9 Acordo: Todos os envolvidos com um sistema estão com-
prometidos com a melhoria e concordam em avançar em
conjunto em direção às metas, respeitando e acomodando
diferenças de opinião e abordagem.
11-6
9 Respeito: Valor, compreensão e demonstração de consi-
deração pelas pessoas.
As seguintes práticas são atividades essenciais para geren-

ciar um sistema kanban.
Visualizar: Os sistemas Kanban usam mecanismos como
uma placa kanban para visualizar o trabalho e o processo pelo qual
ele passa. Para que a visualização seja a mais eficaz, ela
deve mostrar:
● Onde no processo uma equipe que trabalha em um serviço

concorda em fazer um item de trabalho específico (ponto
de compromisso);
● Onde a equipe entrega o item de trabalho a um cliente
(ponto de entrega);
● Políticas que determinam que trabalho deve existir em
um determinado estágio.
Limitar o trabalho em andamento: Quando você esta-

belece limites para a quantidade de trabalho que você tem em an-
damento em um sistema e usa esses limites para orientar quando
iniciar novos itens, você pode suavizar o fluxo de trabalho e re-
duzir o tempo de chumbo, melhorar a qualidade e entregar com
mais frequência.
Gerenciar o fluxo: O fluxo de trabalho em um serviço
deve maximizar a entrega de valor, minimizar os prazos de entre-
ga e ser o mais previsível possível. As equipes utilizam o contro-
le empírico através da transparência, inspeção e adaptação para
equilibrar essas metas potencialmente conflitantes. Um aspecto
fundamental do gerenciamento do fluxo é identificar e abordar
gargalos e bloqueadores.
11-7
Tornar as políticas explícitas: Políticas explícitas aju-
dam a explicar um processo além apenas da listagem de diferentes
etapas no fluxo de trabalho. As políticas devem ser esparsas, sim-
ples, bem definidas, visíveis, sempre aplicadas e facilmente mutá-
veis pelas pessoas que trabalham no serviço. Exemplos de políticas
incluem: Limites de WIP, alocação de capacidade, definição de
feito e outras regras para itens de trabalho existentes em várias
etapas do processo.
Implementar loops de feedback: Os loops de feedba-
ck são um elemento essencial em qualquer sistema que procura
proporcionar mudanças evolutivas. Os loops feedback usados em
Kanban são descritos na seção Ciclo de vida.
Melhorar de forma colaborativa, evoluir experimentalmente:
Kanban começa com o processo como ele existe atualmente e apli-
ca melhoria contínua e incremental em vez de tentar alcançar uma
meta final predefinida.
Dada a abordagem de Kanban para começar com o seu pro-
cesso existente e evoluí-lo, não há papéis explicitamente solicita-
dos ao adotar Kanban. Use os papéis que você tem atualmente em
sua equipe.
Existem dois papéis que surgiram na prática que servem a
propósitos particulares. É muito provável que essas funções sejam
preenchidas por alguém em uma função existente como mencio-
nado abaixo.
Gerente de Solicitação de Serviço: Entende as necessidades e
expectativas dos clientes, e facilita a seleção e o pedido de itens de
trabalho na Reunião de Reposição. Essa função é frequentemente
preenchida por um gerente de produto, proprietário de produto ou
gerente de serviços.
11-8
Gerente de Entrega de Serviços: Responsável pelo fluxo de
trabalho para entregar itens selecionados aos clientes. Facilita o
Planejamento de Reunião e Entrega kanban. Outros nomes para
esta função incluem gerenciador de fluxo, gerenciador de entrega
ou mestre de fluxo.
Como os itens de trabalho tendem a fluir através de um sis-
tema kanban em fluxo de peça única, e cada sistema é diferente em
relação às etapas em seu fluxo de trabalho, a melhor maneira de
descrever o ciclo de vida do método Kanban é através dos loops de
feedback envolvidos.
Esses loops de feedback (cadências) são:
Revisão de Estratégia (Trimestral): Selecione os servi-
ços a fornecer e o contexto em que esses serviços são apropriados.
Revisão de Operações (Mensal): Entenda o equilíbrio
entre e entre os serviços, incluindo a implantação de pessoas e re-
cursos para maximizar a entrega de valor.
Revisão de Risco (Mensal): Entenda e responda aos ris-
cos de entrega nos serviços.
Revisão de entrega de serviços (Bissemanal): Exami-
ne e melhore a eficácia de um serviço. Isso é semelhante a uma
retrospectiva focada em melhorar o sistema kanban.
Reunião de Reposição (Semanal): Identifique itens em
que a equipe trabalhará e determine quais itens de trabalho podem
ser selecionados em seguida. Isso é análogo a uma reunião de pla-
nejamento para um sprint ou iteração.
O Encontro Kanban (Diário): Uma equipe trabalhando
em um serviço coordena suas atividades para o dia. Isso é análogo
a um standup diário.
11-9
Reunião de Planejamento de Entrega (Cadência por
entrega): Monitore e planeje entregas aos clientes.
11.4 Scrum
Scrum é a estrutura ágil mais utilizada em todo o mundo.
Quando questionados sobre quais estruturas ágeis, metodologias
ou práticas que utilizam, quase três quartos (72%) das empresas
que participaram da 13ª Pesquisa Anual do Estado Do Ágil, afirma-
ram que o Scrum é seu quadro de escolha. Mais da metade (54%)
dos entrevistados disse que só usa Scrum, enquanto outro quin-
to (18%) usa uma estrutura híbrida, combinando Scrum com XP
ou Kanban.
Em 1986, os especialistas japoneses Hirotaka Takeuchi e
Ikujiro Nonaka publicaram uma mensagem sobre uma nova abor-
dagem para o desenvolvimento de novos serviços e produtos (não
necessariamente software). A abordagem foi baseada no tra-
balho unido de uma pequena equipe universal que desenvolve o
projeto em todas as fases. Uma analogia foi dada com o rugby,
onde toda a equipe se move em direção ao gol do adversário como
um todo, passando (passando) a bola para seus jogadores para
frente e para trás. No início dos anos 90, essa abordagem começou
a ser aplicada na indústria de software e adquiriu o nome de Scum
(um termo do rugby, que significa scrum), em 1995 Jeff Su-
therland e Ken Schwaber apresentaram uma descrição dessa abor-
dagem no OOPSLA ‘95 - um dos as conferências de maior auto-
ridade na área de programação. Desde então, o método tem sido
usado ativamente na indústria e muitas vezes descrito na literatura.
O método Scrum permite a flexibilidade de desenvolver pro-
jetos em equipes pequenas (7 pessoas mais / menos 2) em uma
11-10
situação de mudança de requisitos. Ao mesmo tempo, o processo
de desenvolvimento é iterativo e oferece muita liberdade para a
equipe. Além disso, o método é muito simples - é fácil de aprender
e aplicar na prática. Seu circuito é mostrado na figura 11-2:
Figura 11-1: Exemplo de processo de

desenvolvimento SCRUM
Primeiro, os requisitos são criados para todo o produto. Em

seguida, os mais relevantes são selecionados a partir deles e um
plano para a próxima iteração é criado. Durante a iteração, os pla-
nos não mudam (isso atinge a estabilidade relativa do de-
senvolvimento) e a iteração em si dura de 2 a 4 semanas. Termi-
na com a criação de uma versão funcional do produto (produto
funcional), que pode ser apresentada ao cliente, lançada e de-
monstrada, embora com funcionalidade mínima. Em seguida, os
resultados são discutidos e os requisitos do produto são ajustados.
É conveniente fazer isso se, após cada iteração, você tiver um pro-
duto que possa de alguma forma usar, mostrar e discutir. Em se-
guida, uma nova iteração é planejada e tudo é repetido.
Em uma iteração, o projeto é totalmente ocupado pela equipe.
É simples, o Scrum não define nenhuma função. A sincronização
11-11
com o gerenciamento e o cliente ocorre após o final da iteração. A
iteração só pode ser interrompida em casos especiais.
Existem apenas três tipos de funções no Scrum:
Proprietário do produto (Product Owner) é um ge-
rente de projeto que representa os interesses do cliente no projeto.
Suas responsabilidades incluem o desenvolvimento dos requisitos
iniciais para o produto (Product Backlog), sua mudança opor-
tuna de requisitos, a atribuição de prioridades, datas de entrega,
etc. É importante que ele não participe da implementação da pró-
pria iteração.
Scrum Masters (Scrum Master) garante a máxima efici-
ência e produtividade do trabalho da equipe - tanto na execução do
processo Scrum quanto na solução de tarefas econômicas e admi-
nistrativas. Em particular, sua tarefa é proteger a equipe de todas
as influências externas durante a iteração.
Time Scrum (Equipe Scrum) - um grupo de cinco a nove
programadores proativos e independentes. A primeira tarefa da
equipe é definir para a iteração realmente realizável e tarefas prio-
ritárias para o projeto como um todo (com base no Backlog do
projeto e com a participação ativa do product owner e do
Scrum-master). A segunda tarefa é concluir esta tarefa a todo
custo, dentro do prazo estipulado e com a qualidade declarada. É
importante que a própria equipe participe da formulação da tarefa
e ela mesma a execute.
Scrum define as seguintes práticas:
Reunião de planejamento do Sprint: Realizado no iní-
cio de cada Sprint. Primeiro, o proprietário do produto, o Scrum-
-master, a equipe, bem como os representantes do cliente e ou-
tras partes interessadas, determina quais requisitos do Backlog do
11-12
projeto são de maior prioridade e devem ser implementados den-
tro deste Sprint. Sprint Backlog está sendo formado. Em seguida,
o Scrum Master e o Time Scrum determinam como os objetivos
acima do Sprint Backlog serão alcançados. Para cada elemento do
Sprint Backlog, uma lista de tarefas é determinada e sua complexi-
dade é estimada.
Reunião Daily Scrum: uma reunião diária de quinze mi-
nutos com o objetivo de compreender o que se passou desde a reu-
nião anterior, adequando o plano de trabalho à realidade de hoje
e identificando formas de resolver os problemas existentes. Cada
membro da equipe Scrum responde a três perguntas: o que fiz des-
de a reunião anterior, meus problemas, o que farei antes da pró-
xima reunião? Qualquer parte interessada pode participar desta
reunião, mas apenas os membros da equipe Scrum têm o direito de
tomar decisões. A regra se justifica pelo fato de terem a obrigação
de atingir a meta, e só isso dá confiança de que será alcançada. Eles
são responsáveis por suas próprias palavras, e se alguém de fora
intervém e toma decisões por eles, ele remove a responsabilidade
pelo resultado dos membros da equipe. Essas reuniões mantêm a
disciplina de comprometimento na equipe Scrum, ajudam a man-
ter o foco nas metas de iteração e ajudam a resolver os problemas
pela raiz. Normalmente, essas reuniões são realizadas em pé, por
15-20 minutos.
Reunião de revisão de sprint: Realizado no final de
cada Sprint. Primeiro, a equipe Scrum demonstra o trabalho do
Dono do Produto realizado durante a Sprint, que por sua vez lide-
ra essa parte da reunião e pode convidar todos os representantes
do cliente interessados a participar. O Product Owner determina
quais requisitos do Sprint Backlog foram atendidos e discute com
a equipe e os clientes a melhor forma de priorizar o Sprint Backlog
para a próxima iteração. Na segunda parte da reunião, é realizada
11-13
a análise do sprint anterior, que é conduzida pelo Scrum master.
A equipe Scrum analisa os aspectos positivos e negativos da cola-
boração no último Sprint, tira conclusões e toma decisões impor-
tantes para trabalhos futuros. A equipe Scrum também está procu-
rando maneiras de aumentar a eficácia do trabalho futuro. Então
o ciclo se repete.
Figura 11-2: Exemplo de reunião de revisão sprint
Começar com scrum é muito fácil. Ser bem sucedido com

scrum, no entanto, requer que todos os membros da Equipe de
Desenvolvimento tenham uma compreensão básica da ideologia
ágil e do conhecimento dos conceitos e eventos scrum. O Proprie-
tário de Produto e o Scrum Master precisam de conhecimento es-
pecializado e domínio de habilidades específicas para cumprir ade-
quadamente suas funções. Para qualquer outra pessoa envolvida
em projetos scrum, que inclui usuários finais, é muito benéfico ter
uma compreensão do básico.
11-14
A certificação EXIN Agile Scrum Foundation é perfeita para
iniciantes de carreira, membros da Equipe de Desenvolvimento e
qualquer pessoa envolvida em projetos scrum. Está disponível em
dez idiomas diferentes e uma ampla gama de opções de estudo.
Para começar com o processo de aprendizagem, inscreva-se em
nossa introdução gratuita curta ao Agile e Scrum.
As certificações de nível avançado EXIN Agile Scrum Master
e EXIN Agile Scrum Product Owner são especificamente adapta-
das às funções. O que diferencia essas certificações de outras cer-
tificações de nível avançado são as habilidades práticas que você é
obrigado a mostrar antes de obter certificação.
Para scrummers experientes que desejam crescer sua carrei-
ra além disso, há uma certificação Agile Coach disponível. Com a
continuação da adoção e aplicação do Scrum e do Agile, ambos os
domínios têm muitas oportunidades de crescimento.
11-15

I) Métodos ágeis de desenvolvimento de software surgiram como uma al-
ternativa aos métodos formais e Metodologias pesadas como CMM e RUP.
II) Programadores talentosos querem fazer do desenvolvimento de softwa-
re uma rotina, eles querem ter o máximo de liberdade e prometer alta efici-
ência em troca.
III) Por outro lado, a prática mostra que Metodologias “pesadas” são inefi-
cazes em um número significativo de casos. Os principais pontos dos méto-
dos Ágeis consagrados no Manifesto Ágil em 2007.
Estão INCORRETAS:
( ) -a) II, somente
( ) -b) I e II
( ) -d) II e III
( ) -e) I e III
2) O método flexível mais famoso é o Extreme Programming conhecido por

seu nome abreviado de:
( ) -a) Kaban
( ) -b) Scrum
( ) -c) Scrum Masters
( ) -d) Daily Scrum
( ) -e) XP
11-16
3) O modelo de processo XP parece uma sequência frequente de lançamen-
tos de produtos, o mais frequente possível. Mas, ao mesmo tempo, é im-
perativo que o lançamento inclua uma funcionalidade totalmente nova.
Um dos princípios básicos de organização do processo XP e:
( ) -a) Reagir às mudanças em vez de seguir um plano.

( ) -b) Planning Game, que parte do princípio de que o desenvolvi-
mento de software é um diálogo entre possibilidades e dese-
jos, e ambos vão mudar.
( ) -c) Software funcional em vez de documentação complexa.
( ) -d) Interação com o cliente em vez de contratos rígidos.
( ) -e) Não reagir às mudanças em vez de seguir um plano.
4) É um meio de projetar, gerenciar e melhorar sistemas de fluxo para o

trabalho de conhecimento. Estamos falando do método:
( ) -a) XP
( ) -b) Daily Scrum
( ) -c) Scrum Masters
( ) -d) Kaban
( ) -e) Scrum

I) O Método Kanban recebe seu nome a partir do uso de kanban meca-
nismos de sinalização visual para controlar o trabalho em andamento para
produtos de trabalho intangíveis.
II) Kanban não pode ser usado em qualquer configuração de trabalho de
conhecimento.
III) Kanban é particularmente aplicável em situações em que o trabalho
chega de forma imprevisível e/ou quando você quer implantar o traba-
lho assim que ele está pronto, em vez de esperar por outros itens de
trabalho.
Estão CORRETAS:
( ) -a) I e III
( ) -c) II e III
11-17
( ) -d) II, somente
( ) -e) I, somente
6) As equipes que aplicam a Kanban para melhorar os serviços que ofere-
cem abraçam um dos seguintes valores:
( ) -a) Design simples versus design redundante.

( ) -b) Metáfora - a essência do projeto deve caber em 1-2 frases
amplas ou de alguma forma.
( ) -c) Refatorar é um processo de melhoria contínua simplificação.
( ) -d) Propriedade Coletiva.
( ) -e) Equilíbrio diferentes aspectos, pontos de vista e capacidades
devem ser equilibrados para alcançar a eficácia.
7) O fluxo de trabalho em um serviço deve maximizar a entrega de valor,

minimizar os prazos de entrega e ser o mais previsível possível. Estamos
falando de:
( ) -a) Limitar o trabalho em andamento

( ) -b) Gerenciar o fluxo
( ) -c) Tornar as políticas explícitas
( ) -d) Implementar loops de feedback
( ) -e) Gerente de Entrega de Serviços
8) É a estrutura ágil mais utilizada em todo o mundo.
( ) -a) Scrum
( ) -b) XP
( ) -c) Daily Scrum
( ) -d) Scrum Masters
( ) -e) Kaban
9) O método Scrum permite:
( ) -a) Software funcional em vez de documentação complexa.

( ) -b) Interação com o cliente em vez de contratos rígidos.
11-18
( ) -c) A flexibilidade de desenvolver projetos em equipes peque-
nas (7 pessoas mais / menos 2) em uma situação de mudan-
ça de requisitos.
( ) -d) Reagir às mudanças em vez de seguir um plano.
( ) -e) Planning Game, que parte do princípio de que o desenvolvi-
mento de software é um diálogo entre possibilidades e dese-
jos, e ambos vão mudar.
10) É um gerente de projeto que representa os interesses do cliente no pro-

jeto. Estamos falando de:
( ) -a) Proprietário do produto

( ) -b) Scrum Masters
( ) -c) Time Scrum
( ) -d) Reunião de planejamento do Sprint
( ) -e) Reunião Daily Scrum
11-19
DISCIPLINA:
Engenharia de
Software
CAPÍTULO 12:
EXEMPLO PRÁTICO DE PROJETO
DE SISTEMA DE SOFTWARE
EXEMPLO PRÁTIC O D E P R O J ETO D E S IS TEMA D E SO FTWARE

12.1 FUNDAMENTOS
O presente projeto costa das etapas de desenvolvimento de
um sistema de gerenciamento de consultas médicas de porte mé-
dio. Vale ressaltar que o mesmo, abarca apenas as etapas de desen-
volvimento, constando o levantamento de grande parte das tecno-
logias abordada nos capítulos anteriores.
Vale ressaltar ainda que, o objetivo desta etapa da obra, é
apresentar como o projeto fora executado, e não que os estudantes
de fato elaborem, pois aqui ainda são apresentadas tecnologias que
não foram passadas na obra, tais quais exemplos de linguagens de
programação, bancos de dados, ambientes de desenvolvimento,
dentre outros.
12.2 Tecnologias Envolvidas
12.2.1 Linguagem PHP

PHP é uma linguagem de programação muito semelhante
ao JavaScript em sua estrutura. A grande diferença entre PHP e
JavaScript é que o segundo é uma linguagem do lado do servidor,
enquanto o JavaScript é uma linguagem do lado do cliente. Na
prática, isso significa que todo o processamento de código e dados
em PHP é executado no servidor, que retorna o resultado como
HTML ao navegador do usuário. Isso contrasta com o JavaScript,
onde o código é lido e executado diretamente no / pelo navegador
do cliente.
“O PHP é e será uma ótima linguagem de programação

com uma quantidade incrível de possibilidades, se você
aprender a usá-lo corretamente” (PHP, 2020, s.p).
12-2

O PHP foi concebido no outono (lá nos EUA, aqui no
Brasil seria primavera) de 1994 por Rasmus Lerdorf.
As primeiras versões foram usadas na sua homepage
para saber quem estava consultando o currículo online.
A primeira versão, utilizada por outras pessoas, foi dis-
ponibilizada em meados de 1995, e era conhecida como
Personal Home Page Tools.
(Ferramentas para Homepages Pessoais).
(COX JUNIOR, 2000, p.07)
Como pode ser percebido, o PHP é uma ótima linguagem de

programação para desenvolvimento de sistemas web, dessa forma,
pretende-se usar ela neste trabalho a fim de otimizar os trabalhos e
se entregar um sistema mais estável e funcional possível.
12.2.2 Banco de dados MYSQL

O MySQL é normalmente é usado em conjunto com o PHP.
O MySQL é um sistema de banco de dados que permite armazenar
dados de entrada de suas páginas da web. O usuário pode então
extrair e aplicar essas entradas às suas páginas quando precisar
delas. Por exemplo, o MySQL pode ser usado para criar uma cai-
xa de comentários no seu site, onde os comentários e os nomes
da pessoa que escreveu o comentário são armazenados no banco
de dados MySQL. “O MySQL foi desenvolvido e é disponibiliza-
do pela empresa MySQL AB Limited Company, que atualmente
vende um conjunto de serviços e produtos relacionados com a tec-
nologia MySQL”. (NEVES & RUAS, 2005, p. 21).
12-3

12.2.3 Wampserver
O WAMP é “um programa para Windows que permite criar
um servidor da Web para que se possa visualizar sites de fora do seu
próprio computador”1 (WAMPSERVER, 2020, s.p). Depois de ins-
talar o servidor, talvez seja necessário permitir que o aplicativo acesse
a rede através do seu firewall. Uma vez feito, inserindo o endereço IP
no navegador, se poderá ver o que o servidor da web está mostrando ao
mundo. Quando este é instalado no Linux, passa a se chamar LAMP.
12.2.4 Brackets
Esse será o ambiente de desenvolvimento usado para codifi-
cação da aplicação. Este trata-se de um editor de texto leve e que
organiza de maneira simples os códigos digitados nele. É possível
trabalhar com pastas, codificações de texto, além de outros recur-
sos específicos do desenvolvedor. Outro fator importante, é o fato
de este ser de código aberto.
Figura 12-1: Interface da IDE Brackets
Fonte: http://brackets.io/img/hero@2x.png
1 Tradução do autor.
12-4

12.3 Detalhamento do Software
A acessibilidade aos serviços de uma empresa através da web
é de extrema importância para o sucesso eminente. A Internet é
um ótimo meio para tornar uma clínica médica conhecida por um
grande número de pessoas que podem estar potencialmente inte-
ressadas nos serviços que ela pode oferecer. Portanto, a criação de
um site ou sistema web que forneça todas as informações neces-
sárias sobre a clínica e possibilite o gerenciamento de consultas
online pode beneficiar uma clínica de várias maneiras.
O principal objetivo deste projeto é desenvolver um site para
uma clínica médica que forneça uma forma eficiente e econômica
de agendar consultas e auxiliar em todas as tarefas relacionadas:
administração de horários de clínicas e médicos, administração de
filas e exportação de consultas de pacientes.
Este sistema torna-se importante para estes estabelecimen-
tos, uma vez que o alto nível de concorrência na prestação de servi-
ços de saúde exige não só a prestação de cuidados de saúde de alta
qualidade, mas também o trabalho constante com os pacientes que
são os principais clientes dos centros de saúde.
12.3.1 Usuários do Sistema

Para se especificar as funcionalidades do sistema, bem como
ainda fazer o levantamento dos requisitos, é muito importante ter
em mente quais serão os usuários que estarão fazendo uso do mes-
mo. Dessa forma, como se trata de um sistema simples, como já
mencionado, este contará com apenas dois tipos de usuários, dou-
tor e paciente.
Pacientes: este grupo de usuários é aquele que criou uma
conta em nosso site e fez o login. Eles têm todas as funcionalidades
12-5

fornecidas ao grupo de usuários Convidados (exceto formu-
lário de registro / login e marcação de visitas), além
das seguintes:
● Faz formulário de consulta online com um dos médicos

pesquisados anteriormente por alguns critérios;
● Ver todos os próximos compromissos;
● Ver os resultados das visitas anteriores;
● Entrar e sair da conta;
● Cancelar qualquer um dos próximos compromissos;
● Ver e mudar seu próprio perfil.
Médicos: este grupo de usuários são aqueles que estão lo-

gados com uma credencial fornecida a eles por uma empresa. Eles
têm a funcionalidade de Convidado (exceto registrar / formu-
lário de login e marcar visitas) e o seguinte:
9 Exibir os próximos compromissos em formato

de calendário;
9 Dar resultado a uma visita;
9 Ver o prontuário dos pacientes (todas as consultas que fi-
zeram com este médico até o momento);
9 Adicionar o seu dia de feriado;
9 Ver os compromissos de hoje.
12-6

12.4 Requisitos Funcionais
Tabela 12-1: Requisitos funcionais do sistema
Código Descrição
O usuário deve ser capaz de registrar e gerenciar seus
RF01
compromissos online a qualquer momento.
O banco de dados deve armazenar todas as informações
RF02
de forma eficiente, sem qualquer perda de informações.
O usuário deverá poder buscar os médicos por especiali-
RF03
dade, nome, horário de trabalho e / ou sexo.
O usuário pode alterar as informações do seu perfil a
RF04
qualquer momento
Os médicos podem gerenciar todos os compromissos
RF05
marcados com ele em sua conta.
12.5 Requisitos Não-Funcionais
Tabela 12-2: Requisitos não-funcionais do sistema
Código Descrição Categoria

O sistema deve ser compatível com
diferentes navegadores populares
RNFPO01 Portabilidade
(Google Chrome, Mozilla Firefox,
Opera, Safari e Internet Explorer 8+)
12-7

A probabilidade de falha deve ser
RNFCO01
menor que 0,01%
Tempo de atividade deve ser de pelo
RNFCO02
menos 99% Confiabilidade
São necessários menos de 30 minu-
RNFCO03 tos para se recuperar de uma falha
do sistema.
Os elementos da interface (por
RNFUS01 exemplo, menus) devem ser fáceis de
entender.
O usuário deve ser capaz de apren-
RNFUS02 der a usar um sistema em menos de
30 minutos.
Tempo necessário para registro infe-
RNFUS03 Usabilidade
rior a 5 minutos.
As mensagens de erro devem expli-
RNFUS04
car como se recuperar do erro
Ações que não podem ser desfeitas
RNFUS05
devem pedir confirmação
O design responsivo deve ser
RNFUS06
implementado
O usuário precisa apenas de espaço
RNFAR01 em disco e RAM suficiente para o Armazenamento
navegador da web
Todas as operações realizadas no
RNFDE01 sistema devem responder em 5 Desempenho
segundos
Todos os plugins e componentes
RNFIP01
devem ser gratuitos.
Todos os plug-ins devem funcionar Implementação
RNFIP02 corretamente e satisfazer os requisi-
tos de desempenho e confiabilidade.
12-8

O sistema deve interoperar adequa-
Interoperabili-
RNFIT01 damente com o banco de dados
dade
(MySQL)
A senha deve ter pelo menos 8 ca-
RNFIS01 racteres, 1 maiúscula, 1 minúscula e 1
número.
Segurança
O site deve usar técnicas diferentes
RNFIS02 para ter uma transferência segura de
dados para o banco de dados
Todos os dados do usuário não po-
dem ser vendidos ou distribuídos a
RNFPR01 Privacidade
outras entidades sem sua aprovação
prévia.
Caso necessite de mais largura de
banda ou espaço em disco, o siste-
RNFES01
ma deve estar preparado para essas
situações.
Escalabilidade
Ao aumentar os recursos do site, não
pode haver nenhuma penalidade no
RNFES02
tempo de resposta ou ter mais erros
que o normal.
Tabela 12-3: Caso de uso registrar conta
Caso de uso 1 Registre uma conta CDU01

Atores Paciente
Registra uma conta com uma função de Pacien-
Descrição te que permitirá todas as diferentes funcionalida-
des dos pacientes
Condição prévia Acesse um formulário de registro
12-9

Caso de uso 1 Registre uma conta CDU01
1. Preencha todas as informações necessárias
(nome, e-mail, DNI, senha) e, opcionalmente,
número do seguro
Fluxo Básico
2. Clique no botão “Enviar”
3. Confirme um e-mail clicando em um link
enviado para sua caixa de entrada
Se algum dos campos obrigatórios não for pre-
Fluxo Alternativo enchido, mostra uma mensagem de erro sem
permitir que ele conclua seu cadastro.
Um usuário será cadastrado em um site e poderá
Pós-condição
acessar sua conta
No caso de uso acima, o usuário deve criar seu login para que
possa ter acesso aos recursos do sistema. Vale ressaltar que é pos-
sível criar uma conta apenas como paciente, os doutores têm con-
tas feitas direto pelo banco de dados. Cada tipo de usuário, possui
seus devidos recursos para acesso.
Tabela 12-4: Caso de uso Logar
Caso de uso 2 Logar CDU02

Atores Doutores/Pacientes
Descrição Permite fazer login em um site
Acesse uma página de “Login / Registro” em um
Condição prévia
site.
1. Preencha o nome de usuário e a senha.
Fluxo Básico
2. Clique no botão “Login”
Se um dos campos obrigatórios não for preen-
chido, mostra um erro ao clicar no botão “Login”.
Fluxo Alternativo
Se o login e / ou senha não estiverem corretos,
exibe uma mensagem de erro.
12-10

Caso de uso 2 Logar CDU02
Um usuário será conectado ao site. Ele será
Pós-condição capaz de usar as funcionalidades dessa função
específica.
O caso de uso dois está relacionado ao Login. Neste caso de

uso, o usuário entra com suas credenciais de modo que o formulá-
rio filtra esses dados, compara com os existentes no banco de dados
e o direciona para o painel adequado, no caso doutor ou paciente.
Tabela 12-5: Caso de uso agendar consulta
Caso de uso 3 Agendar consulta CDU02

Atores Paciente
Permite marcar uma consulta por um paciente
Descrição
logado.
Efetuou login como função de paciente no site e
Condição prévia
acessou a página “Marcar uma consulta”.
1. Escolha uma especialização e um médico
2. Escolha uma data com hora. Escreva uma des-
crição do problema
Fluxo Básico
3. Escolha se é uma primeira consulta / acompa-
nhamento e se é para você ou outra pessoa
4. Clique no botão “Enviar”
Se um dos campos obrigatórios não for pre-
Fluxo Alternativo enchido, mostra um erro ao clicar no botão
“Enviar”.
Um compromisso será adicionado a um banco
Pós-condição de dados. Agora pode ser visualizado na página
“Meus compromissos”
12-11

O caso de uso acima está relacionado ao agendamento de
consultas que são feitas diretamente pelo paciente. Ao fazer isso, a
consulta vai direto ao painel do doutor escolhido que selecionará a
opção de aceitar ou não a consulta, mediante sua disponibilidade.
Tabela 12-6: Caso de uso adicionar resultado de uma consulta
Caso de uso 4 Adicione o resultado de uma consulta CDU04

Atores Médico
Permite adicionar um resultado privado ou
público de uma visita realizada anteriormente.
Descrição
Os resultados públicos estarão disponíveis para
consulta de um paciente.
Efetuou login como uma função de médico no
Condição prévia
site e acessou a página “Escreva um resultado”.
1. Selecione um paciente e / ou uma data de
uma visita
2. Selecione o intervalo de datas de um feriado.
Fluxo Básico 3. Selecione o tipo de resultado: privado ou pú-
blico (aquele que os pacientes podem ver)
4. Escreva um resultado e clique no botão
“Enviar”
Se alguns campos obrigatórios não forem preen-
Fluxo
chidos (paciente ou data da visita), mostra uma
Alternativo
mensagem de erro.
Um resultado público ou privado será adicionado
Pós-condição
/ atualizado no banco de dados.
Esta é o caso de uso onde o médico coloca os resultados da

consulta para que o paciente possa verificar posteriormente quan-
do desejar. É possível que o paciente receba esses dados impressos
12-12

no dia da consulta, porém, em caso de perda ou uma praticidade
maior, os mesmos estarão disponíveis em acesso virtual no sistema.
Tabela 12-7: Caso de uso cancelar uma consulta
Caso de uso 5 Cancelar uma consulta (paciente) CDU05

Atores Paciente
Permite cancelar uma consulta previamente feita
Descrição
por este paciente.
Efetuou login como função de paciente no site e
Condição prévia
acessou a página “Meus compromissos”.
1. Clique em “Cancelar um compromisso” ao
Fluxo Básico lado de um deles
2. Confirme clicando em sim ou não
Fluxo Se houver um erro ao excluir um compromisso
Alternativo de um banco de dados, mostre-o.
As informações de um compromisso serão ex-
Pós-condição
cluídas do banco de dados.
Por fim, o paciente pode cancelar uma consulta em caso de

desistência por algum motivo. Esse procedimento é feito direto no
seu painel de acesso, o doutor é avisado imediatamente do cance-
lamento, para que possa vir a marcar ou abrir uma ova vaga para
outro paciente.
12-13
1) A linguagem de programação é fundamental para o desenvolvimento de

um software. Com base na linguagem escolhida no projeto apresentado,
o PHP, ela é uma linguagem de:
( ) -a) Banco de dados

( ) -b) Front-end
( ) -c) Back-end
( ) -d) Progressiva
( ) -e) Interfaces
2) Outra tecnologia importante para o desenvolvimento de software, é o

banco de dados. O banco de dados escolhido no exemplo apresentado,
foi o MYSQL, esse é um exemplo de banco de dados:
( ) -a) Relacional
( ) -b) Não relacional
( ) -c) Programável
( ) -d) Que não possui linguagem
( ) -e) N.R.A
3) Um programa para Windows que permite criar um servidor da Web para

que se possa visualizar sites de fora do seu próprio computador. Esse é o:
( ) -a) MySQL
( ) -b) SqlServer
( ) -c) Wampserver
( ) -d) Brackets
( ) -e) VisualCode
12-14
4) A IDE, ou seja, um ambiente de desenvolvimento é fundamental para o
desenvolvimento de qualquer sistema. No caso do exemplo apresentado,
a IDE escolhida foi:
( ) -a) Wampserver
( ) -b) Brackets
( ) -c) Sublime Text
( ) -d) Visual Code
( ) -e) N.R.A
5) Observe o fragmento abaixo:

“O usuário deve ser capaz de registrar e gerenciar seus compromissos
online a qualquer momento”.
Com base no que foi estudado, esse é um exemplo de:
( ) -a) Requisito funcional
( ) -b) Requisito não-funcional
( ) -c) Caso de uso
( ) -d) Exemplo de planejamento
( ) -e) Exemplo de técnica SCRUM
6) Observe o fragmento abaixo:

“O sistema deve ser compatível com diferentes navegadores populares
(Google Chrome, Mozilla Firefox, Opera, Safari e Internet Explorer 8+).”
Com base no que foi estudado, esse é um exemplo de:
( ) -a) Requisito funcional
( ) -b) Requisito não-funcional
( ) -c) Caso de uso
( ) -d) Exemplo de planejamento
( ) -e) Exemplo de técnica SCRUM
7) Observe essa sigla abaixo:

“CDU01”.
Com base no que foi apresentado no capitulo 12, essa sigla significa:
12-15
( ) -a) Case de Interface 01
( ) -b) Caso de Uso 01
( ) -c) Caso de Unidade 01
( ) -d) Caso de Unificação 01
( ) -e) Case of UX 01
8) Com base no que foi apresentado no capitulo 12: Pacientes e médicos

são exemplos de:
( ) -a) Desenvolvedores
( ) -b) Gerentes de projeto
( ) -c) Usuários
( ) -d) Visitantes
( ) -e) N.R.A
9) Ainda sobre a linguagem de programação, PHP é uma linguagem de pro-

gramação muito semelhante ao JavaScript em sua estrutura. A grande
diferença entre PHP e JavaScript é:
( ) -a) Java Script é do lado do cliente

( ) -b) PHP é do lado do cliente
( ) -c) PHP é do lado do servidor
( ) -d) JavaScript é do lado do servidor
( ) -e) A e C estão corretas.
10) Observe essa sigla abaixo:

“RNFPO01”.
Com base no que foi apresentado no capitulo 12, essa sigla significa:
( ) -a) Requisito não-funcional de possibilidade 01.
( ) -b) Requisito não-funcional de portagem 01.
( ) -c) Requisito não-funcional de portabilidade 01.
( ) -d) Requisito não-funcional de probabilidade 01.
( ) -e) N.R.A.
12-16

REFERÊNCIAS
AACHEN, D.; KLAUSE, A; TURNER, R. CMMI: Uma Abordagem In-

tegrada para Melhoria de Processos. Por do inglês. M: MFK. 2005.
BOEHM, B. Um modelo espiral de desenvolvimento e aprimora-

mento de software. IEEE Computer, vol. 21, 5, maio de 1988.
BOOCH, G; JACOBSON A; RAMBEAU J. UML. Ed. 2ª / SP: Peter, 2006.
BRACKETS, Site oficial do desenvolvedor. Um editor de textos mo-

derno e de código aberto que entende web design. Disponível em:
< http://brackets.io/> Acesso em: 16 mai. 2020.
BROOKS, F. Sem bala de prata. Procedimento de informação da IFIP

10th World Computing Conference, 2000.
COX JUNIOR, Fred. Programando para web com php/mysql.

UPE, Poli. 1ª ed. Florianópolis, 2000.
ERSHOV, A.P. Tecnologia de desenvolvimento de sistemas de

programação. A.P. Ershov. Trabalhos selecionados. “Ciência”. Novo-
sibirsk. 1994.
FATREPP, R. T; SHAFER, D. F SHAFER, L.I. Gestão de projetos de

software: obtenção de qualidade ótima com custo mínimo. Ed.
home “Williams”. 2003.
HUMPHREY, W. Gerenciando o processo de software. Addison-

-Wesley, 1989.
KOZNOV, D.V. Introdução à Engenharia de Software. Parte I. Edi-

tora da Universidade de São Petersburgo, 2005.
KULYAMIN, V.V; PAKULIN, N.V; PETRENKO, O.L; SORTOV, A.A;

KHOROSHILOV, A.V. Formalização de requisitos na prática. Pré-
-impressão ISP RAS 2005.
13-1
KULYAMIN, V.V. Tecnologia de programação. Abordagem de
componentes. Moscou: Internet University of Information Technolo-
R EFER ÊN CI AS
gies; BINOMIAL. Laboratório de Conhecimento, 2007.
KRUCHTEN, P. The for plus one View Model of Architecture.

IEEE Software, 1995.
____________ . Fundamentos de modelagem visual / D. V. Ko-

znov. - M: Internet University of Information Technologies; BINOMIAL.
Laboratório de Conhecimento, 2007.
MILLS, H. A gestão da engenharia de software Parte I: Princí-

pios da engenharia de software. IBM System Journal, Vol. 38, No.
2 e 3, 1999.
MYSQL, Site oficial da empresa. MySQL. Disponível em: < www.mysql.

com > Acesso em 18 mai. 2020.
POTTOSIN I, Engenharia de Software: Conteúdo, Opiniões e

Tendências. Programação. 1997.
PHP, Site oficial da empresa. O que é o php?. Disponível em: < https://
www.php.net/manual/pt_BR/intro-whatis.php> Acesso em 18 out. 2021.
ROYCE, W.W. Gerenciando o desenvolvimento de grandes siste-

mas de software. Proceedings of IEEE WESCON, 2007.
SOMMERVILLE, I. Engenharia de Software. 6ª edição. Addison-

-Wesley, 2001.
WAMPSEVER, Site oficial da empresa. O que é Wamp/Lamp?. Dispo-

nível em: < http://wampserver.aviatechno.net/> Acesso em 14 out. 2021.
13-2
" GABARITO
Capítulo 1:
1) (b) 6) (a)
2) (d) 7) (c)
3) (c) 8) (b)
4) (a) 9) (a)
5) (e) 10) (c)
Capítulo 2:
1) (d) 6) (b)
2) (a) 7) (a)
3) (b) 8) (d)
4) (e) 9) (b)
5) (c) 10) (b)
Capítulo 3:
1) (c) 6) (b)
2) (a) 7) (a)
3) (b) 8) (c)
4) (e) 9) (d)
5) (d) 10) (a)
14-1
Capítulo 4:
G ABAR I TO
1) (a) 6) (b)
2) (e) 7) (d)
3) (b) 8) (c)
4) (d) 9) (b)
5) (a) 10) (a)
Capítulo 5:
1) (b) 6) (c)
2) (a) 7) (d)
3) (c) 8) (a)
4) (b) 9) (c)
5) (e) 10) (e)
Capítulo 6:
1) (a) 6) (d)
2) (c) 7) (b)
3) (e) 8) (c)
4) (b) 9) (a)
5) (a) 10) (c)
Capítulo 7:
1) (a) 6) (a)
2) (d) 7) (d)
3) (b) 8) (b)
4) (e) 9) (a)
5) (b) 10) (c)
14-2
Capítulo 8:
G ABAR I TO
1) (a) 6) (e)
2) (c) 7) (b)
3) (b) 8) (b)
4) (d) 9) (c)
5) (a) 10) (e)
Capítulo 9:
1) (a) 6) (a)
2) (e) 7) (c)
3) (b) 8) (a)
4) (d) 9) (e)
5) (b) 10) (a)
Capítulo 10:
1) (b) 6) (d)
2) (a) 7) (b)
3) (d) 8) (c)
4) (a) 9) (a)
5) (c) 10) (e)
Capítulo 11:
1) (a) 6) (e)
2) (e) 7) (b)
3) (b) 8) (a)
4) (d) 9) (c)
5) (a) 10) (a)
14-3
Capítulo 12:
G ABAR I TO
1) (c) 6) (b)
2) (a) 7) (b)
3) (c) 8) (c)
4) (b) 9) (e)
5) (a) 10) (c)
14-4
1º EDIÇÃO - 2021
Editora
SÃO PAULO/ SP

Engenharia de Software: José de Sousa Magalhães

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software: José de Sousa Magalhães

Enviado por

Direitos autorais:

Formatos disponíveis

Engenharia de

JOSÉ DE SOUSA MAGALHÃES

JOSÉ DE SOUSA MAGALHÃES

1º EDIÇÃO - 2021 | SÃO PAULO/ SP

COORDENAÇÃO GERAL COORDENAÇÃO DE

1º EDIÇÃO - 2021 | SÃO PAULO/ SP

Ficha Catalográfica/ ISBN

CATALOGAÇÃO ELABORADA POR GLAUCY DOS SANTOS SILVA - CRB8/6353

Nesta primeira unidade, daremos orientações acerca dos fundamen-

1. As prescrições lógicas não são apenas os próprios progra-

Propriedades: Assim, o software é um sistema dinâmico

1. Complexidade objetos de software, o que depende signifi-

1) Como a programação é diferente de um programa de engenharia?

( ) -a) Nesse sentido, a primeira é nenhum tipo de atividade abstra-

2) Observe as afirmações abaixo:

( ) -a) O primeiro significa um layout preliminar, esboço, planta

4) Sobre O esforço envolvido na análise e design, é correto afirmar que:

( ) -a) São apresentados, variam muito dependendo do tipo de pro-

5) Observe as afirmações abaixo.

6) Todas as atividades adicionais realizadas no processo de programação

( ) -a) Engenharia de software

7) Estão incluídas na engenharia de software como um campo do conheci-

8) Definimos software como:

( ) -a) Um sistema dinâmico complexo que não inclui aspectos téc-

9) Definimos Propriedades como:

( ) -a) É um sistema dinâmico complexo que inclui aspectos técni-

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

● Informações, regras de uso, documentação e pacotes de

“Recortes” do padrão. A ideia central do processo padrão

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

2.2 Melhoria de processos

1. Uma rápida mudança nas tecnologias de desenvolvimen-

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

O que pode ser melhorado e como:

Separamos o item 3 do item 4 porque, na prática, 4 nem sem-

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

1. Organização puxada: as inovações visam resolver

Um exemplo de uso da estratégia pull da organização é a in-

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

2.3.1 Modelo em cascata

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

Por fim, foi introduzida a prototipagem neste modelo, ou

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

● identificação de fases e tipos de atividades, o que acarreta

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

2.3.2 Modelo em espiral

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

A sequência de loops pode ser a seguinte: no primei-

● Definir os objetivos, restrições e alternativas do projeto;

PROC ES S O D E D ES EN V O LV IMEN TO D E SO FT WARE

Uma espiral separada pode corresponder ao desenvolvi-

1) Como trabalhamos, qual é a sequência de nossos passos, quais são as

2) Observe as afirmações abaixo:

4) Dentro da empresa, é possível e útil unir e padronizar todos os processos

5) A ideia central do processo padrão é:

( ) -a) Informações, regras de uso, documentação e pacotes de ins-

7) Para organizar um processo padrão, é necessário:

( ) -a) Garantir que o processo padrão não se torne apenas um apa-