A Post I Lae Ngen Hari A Software

&OHFOIBSJBEF4PGUXBSF
&OHFOIBSJBEF4PGUXBSF
PROFª. TÂNIA BARBOSA SALLES GAVA
ENGENHARIA DE SOFTWARE
SERRA
2009
2
Governo Federal
Ministro de Educação
Fernando Haddad
Ifes – Instituto Federal do Espírito Santo

Reitor
Dênio Rebello Arantes
Pró-Reitora de Ensino
Cristiane Tenan Schlittler dos Santos
Coordenadora do CEAD – Centro de Educação a Distância

Yvina Pavan Baldo
Coordenadoras da UAB – Universidade Aberta do Brasil

Yvina Pavan Baldo
Maria das Graças Zamborlini
Curso de Tecnologia em Análise e Desenvolvimento de Sistemas

Coordenação de Curso
Isaura Nobre
Designer Instrucional
Danielli Veiga Carneiro / José Mário Costa Júnior
Professor Especialista/Autor
Tânia Barbosa Salles Gava
Catalogação da fonte: Rogéria Gomes Belchior - CRB 12/417

F279e Gava, Tânia Barbosa Salles
Engenharia de software. / Tânia Barbosa Salles Gava. – Vitória: Ifes, 2009.
140 p. : il.
1. Engenharia de software. I. Instituto Federal do Espírito Santo. II. Título.
CDD 005.1
DIREITOS RESERVADOS
Ifes – Instituto Federal do Espírito Santo
Av. Vitória – Jucutuquara – Vitória – ES - CEP - (27) 3331.2139
Créditos de autoria da editoração

Capa: Juliana Cristina da Silva
Projeto gráfico: Juliana Cristina da Silva / Nelson Torres
Iconografia: Nelson Torres
Editoração eletrônica: Duo Translations
Revisão de texto:
Ilioni Augusta da Costa
Maria Madalena Covre da Silva
COPYRIGHT – É proibida a reprodução, mesmo que parcial, por qualquer meio, sem autorização escrita dos autores
e do detentor dos direitos autorais.
Tecnologia em Análise e Desenvolvimento de Sistemas

3
Olá, Aluno(a)!
É um prazer tê-lo conosco.

O Ifes(Instituto Federal do Espírito Santo) oferece a você, em parceria com
as Prefeituras e com o Governo Federal, o Curso Tecnologia em Análise e
Desenvolvimento de Sistemas, na modalidade a distância. Apesar de este
curso ser ofertado a distância, esperamos que haja proximidade entre nós,
pois, hoje, graças aos recursos da tecnologia da informação (e-mails, chat,
videoconferência, etc.) podemos manter uma comunicação efetiva.
É importante que você conheça toda a equipe envolvida neste curso: co-
ordenadores, professores especialistas, tutores a distância e tutores presen-
ciais porque, quando precisar de algum tipo de ajuda, saberá a quem
recorrer.
Na EaD – Educação a Distância, você é o grande responsável pelo sucesso
da aprendizagem. Por isso, é necessário que se organize para os estudos e
para a realização de todas as atividades, nos prazos estabelecidos, confor-
me orientação dos Professores Especialistas e Tutores.
Fique atento às orientações de estudo que se encontram no Manual do
Aluno!
A EaD, pela sua característica de amplitude e pelo uso de tecnologias mo-
dernas, representa uma nova forma de aprender, respeitando , sempre, o
seu tempo.
Desejamos-lhe sucesso!
Equipe do Ifes
Engenharia de Software
4
ICONOGRAFIA
Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos.
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por você,

após a leitura dos textos.
Indicação de leituras complemtares, referentes

ao conteúdo estudado.
Destaque de algo importante, referente ao

conteúdo apresentado. Atenção!
Reflexão/questionamento sobre algo impor-

tante referente ao conteúdo apresentado.
Espaço reservado para as anotações que você

julgar necessárias.

5
ENGENHARIA DE SOFTWARE
Cap. 1 - INTRODUÇÃO À ENGENHARIA DE

SOFTWARE 9
1.1. Visão Geral 9
1.1.1. O que é software? 10
1.1.2. O que é engenharia de software? 12
1.1.3. Qual é a diferença entre engenharia de
software, engenharia de sistemas e engenharia
de conhecimento? 12
1.1.4. Qual é a diferença entre engenharia de
software e ciência da computação? 13
1.2. Histórico da Engenharia de Software 13
1.3. Qualidade de Software 14
Cap. 2 - CARACTERÍSTICAS DO SOFTWARE 19

2.1. O Software como Produto 19
2.1.1. Características de um Software 21
2.1.2. Mitos do Software 23
Cap. 3 - PROCESSOS DE SOFTWARE 29

3.1. Uma visão genérica de processo 29
3.2. Processo de Software x Engenharia de
Software 30
3.3. O que é um Processo de Software 32
3.4. Definição de Processos 35
Cap. 4 - MODELOS DE CICLO DE VIDA 39

4.1. O Ciclo de Vida de um Software 39
4.2. Categorias de Modelos de Ciclo de Vida 41
4.3. Modelo Linear Sequencial 43
4.4. Modelo Incremental 45
4.5. Modelo Espiral 45
4.6. Modelo de Prototipagem 46
Cap. 5 - ATIVIDADES DE DESENVOLVIMENTO 51

5.1. Especificação e Análise de Requisitos 51
5.2. Projeto de Sistema 53
6
5.3. Implementação e Testes 55

5.4. Entrega e Manutenção 57
5.5. Exemplo da Loja Vitória 58
5.5.1. Documento de Especificação de Requi-
sitos 59
Cap. 6 - GERENCIAMENTO DE PROJETO DE

SOFTWARE 71
6.1. Introdução 71
6.2. Escopo de Software 71
6.3. Estimativa de Custo de Software 72
6.3.1. Estimativa LOC (Estimativa de Linha de
Código) 72
6.3.2. Análise de Ponto de Função 77
6.4. Elaboração de Cronograma 80
Cap. 7 - MÉTRICAS DE SOFTWARE 89

7.1. Métricas de Software 89
7.2. Métricas de Processo 92
7.3. Métricas de Projeto 93
7.4. Métricas de Produto 94
Cap. 8 - ANÁLISE E GERENCIAMENTO DE

RISCO 99
8.2. Identificação de risco 100
8.3. Estimativa de risco 102
8.4. Exposição de risco 102
8.5. Mitigação de risco 103
8.7. Monitoramento de riscos 105
Cap. 9 - GARANTIA DE QUALIDADE DE

SOFTWARE 109
9.2. Revisões Técnicas Formais 109
9.3. Confiabilidade do Software 110
9.4. Garantia Estatística de Qualidade de
Software 111
9.5. Normas e Modelos de Qualidade de Processo
de Software 114
9.5.1 As Normas de Qualidade ISO 9000 114

7
REFERÊNCIAS BIBLIOGRÁFICAS 119
ANEXO A 121
ANEXO B 129
8
APRESENTAÇÃO
Olá!
Meu nome é Tânia Barbosa Salles Gava, responsável pela disciplina de
Engenharia de Software. Sou professora atualmente do Instituto Federal
do Espírito Santo, Centro Universitário Vila Velha (UVV), mas já lecionei
em outras instituições de ensino superior como Centro Universitário São
Camilo, Universidade Federal do Espírito Santo e Faculdade Salesiana
de Vitória. Também atuo como professora em cursos de pós-graduação
latu-sensu do IFES, UVV, e cursos a distância, fornecidos pelo programa
ProInfo, em parceria com o MEC-UFES-UFRGS.
Sou graduada em Matemática Aplicada e Computacional (1995)
e Ciência da Computação (1996), Mestre em Informática (1998)
e Doutora em Engenharia Elétrica-Automação, todos cursados na
UFES.
Nesta disciplina serão discutidos assuntos relacionados à disciplina de en-
genharia de software. Muitos dos conceitos que serão discutidos já foram
vistos com diferentes níveis de profundidade nas disciplinas de Análise de
Sistema e Projeto de Sistemas, e outros assuntos serão novos para você.
O objetivo deste material é auxiliá-lo no estudo da disciplina de engenha-
ria de software, por meio de dicas e sugestões que destacam os pontos mais
importantes a serem estudados. O objetivo do material é dar um enfoque
mais prático à disciplina, citando exemplos sempre que possível, e dando
sugestões de leituras complementares.
Em geral, para ser bem sucedido neste curso, é importante que você faça
as atividades sugeridas e estude os exercícios resolvidos, além dos estudos
regulares, evitando, dessa forma, o acúmulo de conteúdo. A participação
no ambiente e, consequentemente, a interação com os colegas e tutores é
extremamente importante para o sucesso na disciplina e no curso como
um todo. Procure realizar com afinco todas as atividades sugeridas.
Desejo sinceramente que este material venha lhe agregar valores e que lhe
ajude a construir conhecimento sobre os assuntos estudados.
Profª Tânia Barbosa Salles Gava

9
INTRODUÇÃO À ENGENHARIA DE
SOFTWARE
Prezado aluno,
Neste primeiro capítulo abordarei como temas principais uma introdução
à engenharia de software, um breve histórico dessa disciplina e falarei um
pouco sobre qualidade de software. Também serão apresentados os três
tipos básicos de atividades envolvidas na engenharia de software: ativida-
des de desenvolvimento, atividades de gerência de projeto e atividades de
garantia da qualidade. Para cada um destes três tipos de atividades será
dedicado um capítulo. A saber, capítulos 5, 6 e 7 respectivamente.
Bons estudos!
1.1. Visão Geral
O termo Engenharia é muito comum de ser utilizado em diferentes

contextos. No entanto, se eu lhe pedisse para definir o que é engenharia,
você saberia me responder?
A Engenharia, segundo o Dicionário Houaiss da língua portu-

guesa, possui muitas definições:
1. Aplicação de métodos científicos ou empíricos à utilização
dos recursos da natureza em benefício do ser humano;
2. Formação, ciência e ofício de engenheiro;
3. O conjunto de atividades e funções de um engenheiro,
que vão da concepção e do planejamento até a responsa-
bilidade pela construção e pelo controle dos equipamen-
tos de uma instalação técnica ou industrial, etc.
Além disso, várias são as especialidades ou ramos da engenharia. Algu-

mas das mais comuns são a engenharia elétrica, a mecânica, a química,
a civil, a aeronáutica, a ambiental, a de alimentos e ainda outras mais
curiosas, como engenharia têxtil, de plásticos, de pesca, petroquímica,
robótica e de entretenimento.
10
Capítulo 1
Mas e a Engenharia de Software, o que seria? Certamente, se você é um

iniciante na área, possui esta e muitas outras dúvidas, tais como: o que
é um software, como ele é produzido, se engenharia de sistemas e enge-
nharia de software são a mesma coisa e qual a diferença de engenharia
de software e ciência da computação (SOMMERVILLE, 2003).
A seguir, tentarei esclarecer essas dúvidas.
1.1.1. O que é software?
Quando você pensa em software, o que vem a sua mente? Se você res-
pondeu que software é um programa de computador você pensa como
a maioria das pessoas. No entanto, software não é apenas um programa,
mas também toda a documentação associada e os dados de configuração
necessários para fazer com que esse programa opere de forma correta.
Um sistema de software geralmente consiste em uma série programas

separados tais como:
• os arquivos de configuração que são utilizados para configu-

rar esses programas;
• a documentação do sistema, que descreve a estrutura des-

se sistema;
• e a documentação do usuário, que explica como utilizar

o sistema.
No caso de produtos de software, há ainda sites web onde os usuários

podem fazer download de informações referentes a esse produto.
Há dois tipos de produtos de software:
1. Os Produtos Genéricos, que são sistemas do tipo stand-alone,

produzidos por uma organização de desenvolvimento de sof-
tware e vendidos no mercado. Muitas vezes, esse tipo de sof-
tware é chamado de pacote de software. Podemos dar como
exemplo os processadores de texto, planilhas eletrônicas, paco-
tes de desenho, ferramentas de gerenciamento de projetos, etc.
O termo stand-alone significa independente, isolado, autônomo.

Esse adjetivo descreve um dispositivo que não necessita do suporte
de outro dispositivo ou sistema, por exemplo, um computador que
não está conectado a uma rede.

11
Introdução à Engenharia de Software
2. Produtos sob encomenda ou personalizados, que são sistemas

encomendados por um cliente em particular e desenvolvidos
especialmente para esse cliente por uma empresa de desen-
volvimento de software. Uma diferença entre esse tipo de sof-
tware e os produtos genéricos é que, nos produtos genéricos, a
especificação do software é definida pela própria organização
que o desenvolve, ao contrário dos produtos sob encomenda,
em que a especificação do software é controlada pela própria
organização que está comprando o software.
Além disso, Pressman (2006) nos apresenta sete tipos de categorias im-
portantes de software de computadores. São elas:
1. Software de Sistemas: coleção de programas escritos para

servir a outros programas, como, por exemplo, os compilado-
res, editores e utilitários para gestão de sistemas;
2. Software de Aplicação: programa isolado que resolve uma

necessidade específica do negócio, tal como o processamento
de transações no ponto de venda ou o controle do processo de
fabricação em tempo real;
3. Software Científico e de Engenharia: antigamente caracte-

rizado por algoritmos que processavam números, atualmente
vão da astronomia à vulcanologia, da análise automotiva de
tensões à dinâmica orbital do ônibus espacial e da biologia
molecular à manufatura automatizada;
4. Software Embutido: reside dentro de um produto ou sistema e é

usado para implementar e controlar características e funções para
o usuário final e para o próprio sistema. Como exemplo, pode-
mos citar os softwares desenvolvidos para aparelhos celulares;
5. Software para linhas de produtos: projetado para fornecer

uma capacidade específica a ser usada por muitos clientes dife-
rentes. Geralmente este tipo de software foca um mercado limi-
tado e especial, tal como os produtos de controle de estoque;
6. Aplicações Web: cobrem uma ampla variedade de aplica-

ções, que podem ou não estar integradas a banco de dados de
empresas e às aplicações do negócio. Aplicações de comércio
eletrônico são um exemplo de aplicações web.
7. Software para Inteligência Artificial: faz uso de algoritmos

não numéricos para resolver problemas complexos que não
podem ser resolvidos pela computação ou análise direta. Apli-
12
Capítulo 1
cações nessa área incluem robótica, sistemas especialistas, re-

conhecimento de padrões de imagem e voz, jogos, etc.
1.1.2. O que é engenharia de software?
A engenharia de software é uma disciplina da engenharia que se preo-

cupa com todos os aspectos da produção de software, desde os estágios
iniciais de especificação do sistema até a sua manutenção, após esse sis-
tema entrar em funcionamento.
Em relação à engenharia de software é muito importante desta-

car que essa disciplina não se dedica simplesmente aos processos
técnicos de desenvolvimento de software, mas também a ativi-
dades como o gerenciamento de projetos de software e o desen-
volvimento de ferramentas, métodos e teorias que dêem apoio à
produção de software.
1.1.3. Qual é a diferença entre engenharia de software,

engenharia de sistemas e engenharia de conhecimento?
A engenharia de sistemas é uma disciplina mais antiga que a engenharia

de software. A engenharia de sistemas engloba todos os aspectos do de-
senvolvimento e da evolução de sistemas complexos, em que o software
desempenha papel principal. Ou seja, a engenharia de sistemas preocu-
pa-se não só com o desenvolvimento de hardware, do projeto de políticas
e processos, da implantação de sistemas, mas também da engenharia de
software. Os engenheiros de sistema estão envolvidos na especificação
do sistema, na definição de sua arquitetura geral e também na integra-
ção das diferentes partes necessárias para se criar um sistema completo,
e menos envolvidos com o hardware e o software. Já os engenheiros de
software têm a responsabilidade direta de construir e manter um siste-
ma de software. Em relação à engenharia de conhecimento, trata-se de
uma área que tem a ver com os sistemas baseados em conhecimento e
suas aplicações, em que se faz investigação fundamental de modelos de
representação de conhecimento e formas de raciocínio, estabelecimento
de métodos de comparação, tanto do ponto de vista formal como do
experimental, desenvolvimento de sistemas baseados em conhecimento
e estudo das relações entre sistemas e o processo ensino/aprendizagem.

13
1.1.4. Qual é a diferença entre engenharia de software e

ciência da computação?
A ciência da computação se preocupa com as teorias e métodos básicos

referentes aos computadores e a sistemas de software, enquanto a enge-
nharia de software se preocupa com os problemas práticos da produção
de software. Da mesma forma que a física é pré-requisito para os enge-
nheiros elétricos, é fundamental que os engenheiros de software tenham
algum conhecimento sobre a ciência da computação.
Atividades
Após ler o tópico 1.1 responda:
1. Diferencie os conceitos de software, ciência da computação,
engenharia de sistemas e engenharia de software.
2. Fale um pouco sobre como um software é produzido.
3. Quais são os dois tipos de produtos de software? Fale sobre
cada um desses tipos.
4. Cite as três categorias de software que você considera mais
importantes para nossa sociedade e justifique suas escolhas.
1.2. Histórico da Engenharia de Software
O desenvolvimento de de software é uma atividade de crescente impor-

tância no dias de hoje. Os sistemas de software estão praticamente em
todos os lugares, e a utilização dos computadores nas mais diversas áre-
as do conhecimento tem gerado uma demanda cada vez mais crescente
por soluções computadorizadas.
Para os iniciantes, muitas vezes o desenvolvimento de software é confun-

dido com programação. Isso acontece porque geralmente começamos
nesta área resolvendo pequenos problemas que vão aumentando grada-
tivamente de complexidade, requerendo cada vez mais conhecimentos e
habilidades. No entanto, chega-se a um ponto em que, devido à comple-
xidade e tamanho dos problemas a serem resolvidos, essa abordagem cen-
trada na programação não é mais indicada. Na verdade, essa abordagem
é aplicável apenas para resolver pequenos problemas, tais como calcular
médias, ordenar conjuntos de dados, etc. De fato, à medida que os pro-
blemas vão se tornando mais complexos, uma abordagem de engenharia
14
Capítulo 1
é necessária. E foi exatamente essa a motivação para o desenvolvimento

da disciplina de engenharia de software, ou seja, a engenharia de software
foi desenvolvida em resposta a problemas de construção de sistemas de
grande porte e personalizados, destinados a aplicações industriais, gover-
namentais e para o setor de defesa (SOMMERVILLE, 2003).
Para compreendermos melhor a importância da engenharia de software

na produção de software, vamos utilizar uma analogia feita por (FALBO,
2005), em que o autor compara a engenharia de software com a engenharia
civil. Por exemplo, para se construir uma casinha de cachorro, dificilmente
alguém irá elaborar um projeto de engenharia civil, com plantas baixa, hi-
dráulica e elétrica. Para resolver o problema, basta um bom pedreiro. Pode
ser que esse pedreiro não faça a melhor casinha de cachorro possível, mas
certamente o produto resultante atenderá aos requisitos pré-estabelecidos.
No entanto, você se arriscaria a investir todo o seu dinheiro, por exemplo,
na construção de um edifício comercial sem ter feito um projeto? Para se
construir um edifício é fundamental realizar um estudo profundo, incluin-
do análises de solo, cálculos estruturais etc., seguido de um planejamento
da execução da obra e desenvolvimento de modelos até a realização da obra,
que deve ocorrer em etapas, tais como fundação, alvenaria, acabamento, en-
tre outras. Além disso, é importante realizar um acompanhamento da obra
para se verificar prazos, custos e a qualidade do que se está construindo.
É importante também destacar que a engenharia de software, além de

ser desenvolvida em resposta a problemas de construção de sistemas
mais complexos, também visa à melhoria da qualidade dos produtos de
software e ao aumento de produtividade no processo de desenvolvimen-
to de software. Além disso, a engenharia de software também trata de
aspectos relacionados ao estabelecimento de processos, métodos, técni-
cas, ferramentas e ambientes de suporte à produção de software.
1.3. Qualidade de Software
Na seção anterior vimos que um dos objetivos da engenharia de softwa-

re é melhorar a qualidade dos produtos de software desenvolvidos. Mas
você saberia responder o que seria qualidade de software?
FALBO (2005) nos apresenta o conceito de qualidade como um conceito de

muitas facetas. Ou seja, para um usuário, um produto de software de boa quali-
dade deve satisfazer suas necessidades, sendo fácil de usar, eficiente e confiável.
Para um desenvolvedor, um produto de boa qualidade deve ser fácil de manter.

15
Já para um cliente, o produto de software deve agregar valor a seu negócio. Ob-
serve que quer seja em uma perspectiva externa, interna ou sobre a qualidade
de uso, o conceito de qualidade está sempre associado ao produto de software.
Um outro aspecto muito importante a ser observado é que a qualidade deve
ser incorporada ao produto ao longo de todo o seu desenvolvimento. Ou seja,
a qualidade dos produtos de software depende fortemente da qualidade dos
processos usados para desenvolvê-lo e mantê-los. E essa é a grande preocupa-
ção da engenharia de software, produzir software de qualidade!
Seguindo uma tendência de outros setores, a qualidade do processo de

software tem sido apontada como parte fundamental para a obtenção da
qualidade do produto. Como veremos com mais detalhes nos capítulos à
frente, abordagens de qualidade de processo, tal como a série de padrões
ISO 9000, sugerem que, melhorando a qualidade do processo de software, é
possível melhorar a qualidade dos produtos resultantes. Ou seja, a idéia por
trás disso é que, uma vez que se tenham processos bem estabelecidos, que
incorporem mecanismos sistemáticos para acompanhar o desenvolvimen-
to e avaliar a qualidade, em geral isso conduzirá a produtos de qualidade
(iremos tratar com mais detalhes de processos de software no capítulo 3).
Vale destacar que um processo de software em uma abordagem de en-

genharia de software envolve diferentes atividades que podem ser clas-
sificadas quanto ao seu propósito como(FALBO, 2005):
t Atividades de Desenvolvimento (ou Técnicas ou de Cons-

trução): são as atividades diretamente relacionadas ao proces-
so de desenvolvimento do software, ou seja, que contribuem
diretamente para o desenvolvimento do produto de software a
ser entregue ao cliente. São exemplos de atividades de desen-
volvimento: especificação e análise de requisitos, projeto de
sistema, implementação e testes, entrega e manutenção. Essas
atividades serão discutidas no capítulo 5;
t Atividades de Gerência de Projeto: são aquelas relacionadas

ao planejamento e acompanhamento gerencial do projeto, tais
como realização de estimativas, elaboração de cronogramas,
análise dos riscos do projeto, etc. Falaremos de gerenciamento
de projeto no capítulo 6;
t Atividades de Garantia da Qualidade: são as relacionadas

com a garantia da qualidade do produto em desenvolvimen-
to e do processo de software utilizado, tais como revisões e
inspeções de produtos (intermediários ou finais) do desen-
volvimento. Assuntos relacionados à garantia de qualidade de
software serão discutidos no capítulo 8.
16
Capítulo 1
Figura 1-1: Atividades do Processo de Software

Fonte: [1] – Falbo, 2005.
A espinha dorsal do desenvolvimento é formada pelas atividades de

desenvolvimento, e geralmente essas atividades são realizadas segundo
uma ordem estabelecida no planejamento.
Já as atividades de gerência e de controle da qualidade são muitas vezes con-

sideradas atividades de apoio, pois não estão ligadas diretamente à construção
do produto final. Essas atividades são normalmente realizadas ao longo de
todo o ciclo de vida do software, sempre que necessário ou em pontos pré-
estabelecidos durante o planejamento, ditos marcos ou pontos de controle.
Atividades
Após ler os itens 1.2 e 1.3 responda:
1. Por que é importante que um software tenha qualidade?
2. Quais são as atividades que geralmente estão envolvidas no

processo de software?
(1) ALBO, R.A., Notas de Aula: Engenharia de Software. Dispo-

nível em http://www.inf.ufes.br/~falbo, 2005.
(2) PRESSMAN, R.S., Engenharia de Software. São Paulo: Mc-
Graw-Hill, 6ª Edição, 2006.
(3) SOMMERVILE, I. Engenharia de Software. São Paulo: Pear-
son Addison Wesley, 6ª edição, 2003.

17
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
18
Capítulo 1

19
CARACTERÍSTICAS DO
SOFTWARE
Prezado aluno,
Agora que você já tem uma visão geral da engenharia de software,
neste capítulo estudaremos o software como um produto, além de
discutirmos sobre o processo de desenvolvimento de um software.
Bom estudo!
2.1. O Software como Produto
O software de computador é o produto que os profissionais, ou seja, os

engenheiros de software, constroem e depois mantém ao longo do tem-
po para que pessoas de todo o mundo o usem, direta ou indiretamente.
Como dissemos anteriormente, o software abrange programas que po-
dem executar em diferentes computadores, com diferentes tecnologias.
Mas por que o software é um produto tão importante? A resposta é sim-
ples. Ele é um produto fundamental em nossa sociedade porque afeta
praticamente todos os aspectos de nossas vidas e tornou-se difundido na
indústria, no comércio, na nossa cultura e em nossas atividades diárias.
Tempos atrás quem poderia prever que o software estaria embutido em
sistemas de toda espécie, tais como de transporte, médico, de telecomuni-
cações, militar, industrial, de entretenimento, etc? Vários intelectuais têm
procurado mostrar a importância do software para a sociedade:
t Osborn, em 1979, caracterizou a criação do software como

uma “nova revolução industrial”;
t Toffler, em 1980, chamou o advento da microeletrônica de

“terceira onda de mudança” da história da humanidade;
t Naisbitt, em 1982, previu a transformação da sociedade in-

dustrial em uma “sociedade da informação”;
t Feigenbaum e McCorduck, em 1983, sugeriram que o poder

do século XXI estaria na informação e no conhecimento;
t Por fim, Stoll, em 1989, ponderou que o que ele chamou de

comunidade eletrônica, criada por redes e softwares, seria a
chave para a troca de conhecimento em todo o mundo.
20
Capítulo 2
Um outro aspecto importante do produto de software é que, inde-

pendentemente de seu tamanho, complexidade ou domínio de apli-
cação, ele evoluiu com o tempo, como podemos observar nas fases
ou eras descritas a seguir:
t Antigamente (até meados dos anos 60). Sistemas batch,

pouca distribuição, software sob medida para computado-
res específicos. O software é visto apenas como um coadju-
vante da indústria de hardware. O hardware era muito mais
caro do que o software;
t Segunda era (até o meio dos anos 70). Sistemas multiusuário,

tempo real, bancos de dados, o software começa a ser visto
como um produto;
t Terceira era (até o final dos anos 80). Sistemas distribuídos,

sistemas inteligentes, hardware barato;
t Quarta era (do final dos anos 80 até os dias de hoje). Os sis-
temas passam a ter interfaces muito amigáveis com o usuário;
surgem as redes de computadores; os sistemas orientados a
objetos; os sistemas especialistas, as redes neurais e os algorit-
mos genéticos; a programação paralela; a Internet, o Cybers-
pace e a “information superhighway”.
O Cyberspace, também conhecido como ciberespaço, é um espaço

de comunicação que descarta a necessidade do homem físico para
constituir a comunicação como fonte de relacionamento, dando
ênfase ao ato da imaginação, necessária para a criação de uma ima-
gem anônima, que terá comunhão com os demais.
Apesar de a internet ser o principal ambiente do ciberespaço, devi-
do a sua popularização e sua natureza de hipertexto, o ciberespaço
também pode ocorrer na relação do homem com outras tecnolo-
gias: celular, pagers, comunicação entre rádio-amadores e por ser-
viços do tipo “tele-amigos”, por exemplo. (JUNGBLUT, 2004; GUI-
MARÃES JR., 1999).
Também conhecido como Cyberespaço, termo muito comum na
ficção científica, possui variações para várias outras denominações
referente à Internet, Cyberpoeta, Cyberpunk e outros mais.
Já information superhighway foi um termo popular usado na déca-
da de 90 para fazer referência aos sistemas de comunicação digital.
Fonte: Wikipédia

21
Características do Software
Existem muitas questões que demonstram a preocupação da indústria

com o software e com a maneira como ele é desenvolvido. O tempo
necessário para se desenvolver um software, os altos custos de desen-
volvimento de um software, a dificuldade de corrigir todos os erros de
um software ao entregá-lo ao cliente, a manutenção de um software que
requer tempo e esforço e a dificuldade em avaliar todo o processo de
desenvolvimento do software são algumas dessas questões.
Atividades
Pesquise na Internet, ou em outras fontes de pesquisa que você

achar interessante, sobre os seguintes conceitos:
1. Sistemas batch.
2. Sistemas monousuário e multiusuário.
3. Sistemas distribuídos e programação paralela.
4. Sistemas inteligentes, sistemas especialistas, redes neurais e
algoritmos genéricos.
2.1.1. Características de um Software
Na nossa sociedade, existe uma infinidade de produtos que são produ-

zidos todos os dias, com as mais diferentes finalidades. Os produtos vão
desde um pão francês, uma roupa ou calçado, um brinquedo, até um
carro ou navio. Mas o que torna um software um produto tão diferen-
ciado? Observe suas características, descritas a seguir, e tente chegar a
uma conclusão:
1. O software não é fabricado no sentido clássico da palavra. O sof-

tware é desenvolvido: se você pensar na fabricação de um hardwa-
re qualquer como, por exemplo, uma impressora, ou no desen-
volvimento de um software qualquer como um editor de texto,
verá que, apesar de existirem algumas semelhanças entre estas
duas produções, elas são duas atividades fundamentalmente di-
ferentes. Caso haja um bom projeto, ambas as atividades gerarão
produtos de qualidade. No entanto, a fabricação de um hardware
pode gerar problemas de qualidade que poderiam ser corrigidos
facilmente em um software, ou até mesmo nem existirem nesse
caso. Além disso, ambas as atividades envolvem pessoas (embora
a relação entre as pessoas envolvidas e o trabalho realizado seja
22
Capítulo 2
diferente) e requerem a construção de um “produto” (embora

com abordagens diferentes). Além disso, uma diferença impor-
tante entre a fabricação de um software e a de um hardware está
relacionada ao custo desses dois tipos de produto. Os projetos de
software não podem ser geridos como se fossem projetos de fa-
bricação simplesmente, pelo fato dos custos do software serem
concentrados na engenharia de software. Isso faz com que o cus-
to do desenvolvimento de software seja muito maior do que o
custo da fabricação de um hardware.
2. O software não “se desgasta”: você já teve que trocar sua impres-
sora, comprar um mouse novo, trocar seu modem por um mais
moderno ou trocar alguma peça quebrada ou deteriorada de seu
computador? Se você possui um computador pessoal, certamen-
te sim. Mas e o software? Precisamos trocá-lo de vez em quan-
do por que ele “quebrou”? Embora não tenhamos essa relação
de desgaste ou de quebra, o software tem uma outra caracterís-
tica muito particular, o software torna-se obsoleto. Basta lembrar
quantas vezes você teve que atualizar seu sistema operacional ou
um pacote de ferramentas como o “Microsoft Office” ou o “Open
Office”. Além disso, quando um hardware se desgasta, ele tem que
ser substituído por um outro, ou ser feita uma troca de peças. Já
com o software isso não acontece. Não há peças sobressalentes
para um software. Isso significa que toda falha de software é gera-
da por um erro de projeto. Isso faz com que a manutenção de um
software seja consideravelmente muito mais complexa do que a
manutenção de um hardware qualquer.
3. A maioria dos softwares ainda continua a ser desenvolvida sob en-

comenda, e não como um produto genérico: se você fosse comprar
uma simples garrafa térmica, iria a uma loja e pediria ao vendedor que
encomendasse uma garrafa cuja cor, estampa, altura e largura você pu-
desse escolher como mais lhe agradasse ou simplesmente entraria numa
loja e levaria uma das que estivessem disponíveis? Em geral, quando
compramos um produto qualquer, não é isso que acontece. Ou seja, os
produtos são fabricados em larga escala e de forma padronizada. Na
fabricação de um hardware, por exemplo, existem diversos componen-
tes reutilizáveis que foram criados para que os engenheiros se concen-
trassem nos elementos realmente inovadores de um novo projeto. Em
relação ao desenvolvimento de software, embora possa haver reusabili-
dade, de forma geral, o software é desenvolvido de forma customizada
e não montado a partir de partes. Nos anos 60 preconizava-se que as bi-
bliotecas de software permitiriam reuso intenso de código. Atualmente,
embora a reusabilidade seja totalmente desejável, as perspectivas para
que isso aconteça são muito mais discretas.

23
2.1.2. Mitos do Software
Um mito é uma crença, uma construção mental de algo idealizado; no

entanto, sem comprovação prática. Existem muitos mitos quando se
trata de software, mitos tanto da gerência responsável pelo software, dos
clientes que o compram ou encomendam, quanto dos profissionais que
o desenvolvem. Sendo você um iniciante ou não na disciplina de en-
genharia de software, é importante ter ciência desses mitos, que estão
descritos em Pressman (2006):
Mitos da Gerência
Os gerentes com responsabilidade sobre um software geralmente trabalham
sob pressão para obedecer a orçamentos, cumprir cronogramas e melhorar
a qualidade desse software. A fim de diminuir a pressão, pelo menos
temporariamente, eles se agarram aos seguintes mitos:
Mito: Já temos um livro que está cheio de padrões e procedimentos para elaborar
o software. Isso não fornece ao meu pessoal tudo o que o eles precisam saber.
Realidade: O livro de padrões pode até existir, mas será que ele é usado?
Os profissionais de software sabem de sua existência? Ele reflete as práticas
modernas da engenharia de software? Ele é completo? É adaptável? Está
voltado para melhorar o prazo de entrega, mantendo o foco na qualidade?
Em muitos casos, a resposta a essas perguntas é negativa.
Mito: Se nos atrasarmos no cronograma, podemos adicionar mais
programadores e ficar em dia.
Realidade: Esse tipo de pensamento é um grande erro, pois o processo de
desenvolvimento de software não é um processo mecanizado como o de um
hardware, por exemplo. Como citado por Brooks (1975), “Adicionar pessoas a
um projeto de software atrasado atrasa-o mais ainda”. Não podemos esquecer que
sempre que novas pessoas são adicionadas a um projeto, a equipe já constituída
precisa gastar tempo orientando os novatos, o que reduz a quantidade de tempo
investida no desenvolvimento produtivo. Isso NÃO quer dizer que pessoas não
podem ser adicionadas a um projeto. Absolutamente, mas desde que isso seja
feito de maneira planejada e bem coordenada.
Mito: Se eu decidir terceirizar um projeto de software, vou poder relaxar
e deixar que a empresa contratada o elabore.
Realidade: Se uma organização não sabe como gerir e controlar projetos de
software internamente, certamente terá problemas na terceirização de seus
projetos.
24
Capítulo 2
Mitos do Cliente
Um cliente pode ser uma pessoa ou empresa que encomendou um software,
geralmente sob contrato. Frequentemente, os clientes acreditam em certos mitos
por falta de informações mais precisas sobre o desenvolvimento do software
por parte dos gerentes ou profissionais de software. Isso pode levar a falsas
expectativas e à insatisfação do cliente.
Mito: Estabelecer um objetivo geral para um projeto de software é suficiente para
iniciar o seu desenvolvimento – podemos fornecer os detalhes posteriormente.
Realidade: uma das principais causas do fracasso de um projeto de software
é ter uma definição inicial mal feita. Num projeto de software, fazer uma
descrição formal e detalhada do domínio da informação, das funcionalidades,
do comportamento, do desempenho das interfaces, das restrições do projeto
e dos critérios de validação é algo essencial. E isso só é possível por meio de
intensa comunicação entre os envolvidos no projeto (stakeholders).
OBS: É comum encontrar o termo stakeholder quando se faz

referência aos envolvidos em um projeto de software. Stakeholder ou,
em Português, parte interessada ou interveniente, refere-se a todos
os envolvidos num processo, por exemplo, clientes, colaboradores,
investidores, fornecedores, comunidade, etc.
Mito: Os requisitos de um projeto mudam continuamente, mas as mudanças
podem ser facilmente adaptadas porque o processo de desenvolvimento de
software é flexível.
Realidade: Outro erro muito comum. Na verdade, os requisitos de software
mudam, mas o impacto dessas mudanças pode variar muito, dependendo
de quando elas acontecem. Por exemplo, quando uma mudança é solicitada
antecipadamente, quando o projeto ou mesmo a codificação do software ainda
não tenha começado, o impacto do custo é relativamente baixo. Por outro lado,
à medida que o tempo passa, o impacto do custo aumenta consideravelmente
– isso acontece porque os recursos já foram comprometidos, a estrutura do
projeto foi estabelecida e as mudanças podem causar consequências que
exijam recursos adicionais e grandes modificações no projeto.
OBS: Um requisito é definido como “uma condição ou uma capacidade

com a qual o sistema deve estar de acordo”. Fonte: http://www.wthreex.com/
rup/process/workflow/requirem/co_req.htm

25
Mitos do Profissional
Os mitos entre os profissionais de software que serão apresentados a seguir
existem desde os primórdios da programação, persistindo até hoje.
Mito: Quando escrevemos um programa e o fazemos funcionar, nosso trabalho
está completo.
Realidade: Dados da indústria indicam que entre 60% e 80% de todo o
esforço despendido em software vai acontecer depois de o software ter sido
entregue ao cliente pela primeira vez, pois é quando o cliente usa o software
que ele percebe suas falhas, e quais de suas necessidades que não foram
atendidas por esse programa.
Mito: Até que eu esteja com o programa “rodando” não tenho como avaliar a
sua qualidade.
Realidade: Um dos mecanismos mais eficazes de garantia de qualidade de um

software pode ser aplicado logo no início de um projeto – é a revisão técnica
formal. Revisões de software são um “filtro de qualidade” que se descobriu ser
mais eficaz do que testes para encontrar alguns tipos de erros de software.
Mito: O único produto de trabalho que pode ser entregue para um projeto de
software bem-sucedido é o programa executável.
Realidade: Um programa executável é apenas um dos elementos
produzidos em um projeto de software. A documentação fornece a base
para uma engenharia bem-sucedida e funciona como uma orientação
para o suporte ao software.
Mito: A engenharia de software vai nos fazer criar documentação volumosa
e desnecessária que fará atrasar o projeto.
Realidade: A engenharia de software tem a ver com a criação de qualidade,
e não somente com a criação de documentos. Uma melhor qualidade leva à
redução de trabalho e retrabalho. Reduzir (re)trabalho resulta em tempos de
entrega mais rápidos.
Uma Revisão Técnica Formal é uma atividade de garantia da

qualidade de software realizada por engenheiros de software. Seus
objetivos são:
1. Descobrir erros de funcionalidade, lógica ou implemen-
tação para qualquer representação do software;
2. Verificar se o software sob revisão satisfaz seus
requisitos;
3. Garantir que o software tenha sido representado de
acordo com padrões pré-definidos;
4. Conseguir que o software seja desenvolvido de modo
uniforme;
5. Tornar os projetos mais administráveis.
Fonte: Pressman, 2006.
26
Capítulo 2
É importante que você tenha em mente que todo projeto de softwa-

re se inicia baseado em alguma necessidade de negócio. Sem um
problema para se resolver não há projeto de software! Essa necessi-
dade pode ser criar um novo produto, serviço ou sistema, adaptar
um sistema legado a alguma necessidade em particular, corrigir um
defeito de uma aplicação existente ou estender as funcionalidades
dessa aplicação, entre outras. Ao iniciar um projeto de software, a
necessidade do negócio muitas vezes é expressa informalmente. Mas
com o passar do tempo você vai ver que a engenharia de software
vai fornecer toda uma estrutura para que seja desenvolvido um sof-
tware de qualidade que atenda a essa necessidade de negócio.
Sistema Legado é o termo utilizado em referência aos sistemas

computacionais de uma organização que, apesar de serem bastan-
te antigos, fornecem serviços essenciais.
Fonte: Wikipédia.
Atividades
1. Descreva as características de um software que o tornam dife-
rente dos demais produtos que você conhece.
2. Fale sobre pelo menos um mito da gerência, do cliente e do
profissional.
3. Baseado no que você leu até aqui, fale da importância da
engenharia de software para a construção de software com
qualidade.
(1) FALBO, R.A., Notas de Aula: Engenharia de Software. Dispo-

(2) RAPCHAN, F., Notas de Aula: Engenharia de Software.

27
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
28
Capítulo 2

29
Métodos e Estratégias de Estudo
PROCESSOS DE SOFTWARE
Prezado aluno,
Neste capítulo apresentarei a diferença entre engenharia de softwa-
re e processo de desenvolvimento de software, dando detalhes sobre
o processo de desenvolvimento de um software, apresentando ativi-
dades principais e atividades de apoio ao processo de software.
Bom estudo!
3.1. Uma visão genérica de processo
O Dicionário Houaiss da língua portuguesa nos dá várias definições in-

teressantes do que seja um processo. Eis algumas delas:
1. Ação continuada, realização contínua e prolongada de algu-

ma atividade; seguimento, curso, decurso;
2. Seqüência contínua de fatos ou operações que apresentam

certa unidade ou que se reproduzem com certa regularidade;
andamento, desenvolvimento, marcha;
3. Modo de fazer alguma coisa; método, maneira,

procedimento.
Mas numa linguagem técnica, o que seria um processo de desenvol-

vimento de software? Segundo Pressman (2006), um processo de de-
senvolvimento de software é um arcabouço para as tarefas necessárias
para a construção de um software de qualidade. Numa linguagem bem
simples, o processo de software é um roteiro que você cria e segue com
o objetivo de desenvolver um produto de qualidade. Mas será que enge-
nharia de software e processo de software são a mesma coisa? Embora
a diferença seja sutil, ela existe. Ou seja, um processo de software define
uma abordagem que é adotada quando o software é elaborado. Mas a
engenharia de software também inclui tecnologias que constituem um
processo, tais como métodos técnicos e ferramentas automatizadas.
30
Capítulo 3
3.2. Processo de Software x Engenharia de

Software
Até aqui temos falado um pouco sobre engenharia de software. Mas

chegou a hora de definirmos o termo. Embora muitos autores tenham
definições pessoais do termo, vamos utilizar a definição proposta por
Fritz Bauer (apud Pressman, 2006), que diz que:
Engenharia de Software é a criação e a utilização de sólidos princí-

pios de engenharia a fim de obter softwares econômicos que sejam
confiáveis e que trabalhem eficientemente em máquinas reais.
Essa definição foi dada em 1969 na primeira conferência sobre o assun-

to e está longe de ser uma definição completa e satisfatória. Há muitos
aspectos não contemplados nessa definição, tais como os aspectos téc-
nicos da qualidade do software, a necessidade de satisfação do ciente
ou a importância de um processo e de medidas e unidades. Mas o IEEE
(Institute of Electrical and Electronic Engineers) em 1993 nos deu uma
definição mais apurada do termo que diz que:
Engenharia de Software é (1) aplicação de uma abordagem siste-

mática, disciplinada e quantificável para o desenvolvimento, ope-
ração e manutenção do software; isto é, a aplicação da engenharia
ao software. (2) o estudo de abordagens como as de (1).
O IEEE - Institute of Electrical and Electronic Engineers colabora no

incremento da prosperidade mundial, promovendo a engenharia de
criação, desenvolvimento, integração, compartilhamento e o conheci-
mento aplicado no que se refere à ciência e tecnologias da eletricidade
e da informação, em benefício da humanidade e da profissão. O IEEE
foi criado em 1884, nos E.U.A. e é uma sociedade técnico-profissional
internacional, dedicada ao avanço da teoria e prática da engenharia
nos campos da eletricidade, eletrônica e computação. Congrega mais
de 312.000 associados, entre engenheiros, cientistas, pesquisadores e
outros profissionais, em cerca de 150 países.
Se você deseja conhecer um pouco mais sobre o IEEE, consulte o
site http://www.ieee.org.

31
Processos de Software
A Engenharia de Software pode ser considerada uma tecnologia em ca-

madas (Pressman, 2006). Essas camadas compreendem o foco na qua-
lidade, o processo, os métodos e as ferramentas. Novamente vemos a
relação entre processo de software e engenharia de software. Nesta defi-
nição podemos ver que o processo é parte de um todo chamado engenha-
ria de software. A Figura 2.1 apresenta essas camadas.
Figura 3-1: Camadas da engenharia de software

(Adaptado de Pressman, 2006).
1) Foco na Qualidade: qualquer abordagem de engenharia, inclusive a

engenharia de software, deve ter um compromisso com a qualidade. O
foco na qualidade deve ser a base da engenharia de software.
2) Processo: essa camada deve ser o alicerce da engenharia de software.

O processo, como já foi dito, deve ser um arcabouço estabelecido para a
efetiva utilização da tecnologia de engenharia de software. Além disso,
essa camada é que mantém as outras unidas e permite o desenvolvimen-
to racional e adequado de softwares.
3) Métodos: os métodos fornecem a técnica para se desenvolver sof-

tware de qualidade. Constituem um conjunto de tarefas que incluem
comunicação, análise de requisitos, modelagem de projeto, construção
de programas, testes e manutenção.
4) Ferramentas: as ferramentas fornecem apoio automatizado para o

processo de software e os métodos.
Além desses processos, uma parte significativa do trabalho da engenharia de

software pode ser agrupada nas seguintes fases genéricas:
1) Definição: seu foco está no que será desenvolvido. Compreende

três tarefas principais:
t Engenharia do sistema;
t Plano de projeto do software (software project planning);
t Análise dos requisitos do sistema.
32
Capítulo 3
2) Desenvolvimento: seu foco está em como o software será desenvol-

vido. Ou seja, como os dados serão estruturados e como as funções se-
rão implementadas? Como as interfaces serão caracterizadas? Como o
projeto será traduzido em uma linguagem de programação? Como os
testes serão feitos? Etc. Compreende três tarefas principais:
t Projeto do software;
t Geração de código;
t Testes.
3) Manutenção: é a fase da correção de erros. Há quatro tipos princi-

pais de manutenção:
t Corretiva;
t Adaptativa;
t Evolutiva;
t Preventiva (reengenharia).
3.3. O que é um Processo de Software
Nós vimos até aqui várias definições de engenharia de software, e que

nenhuma deles consegue descrever com precisão o que seja essa disci-
plina. Além disso, vimos também que o processo de desenvolvimento
de software pode ser considerado como uma das camadas da engenha-
ria de software, se a consideramos uma tecnologia em camadas. Nesta
seção, definiremos o que é um processo de software, apresentando seus
principais elementos.
Segundo Falbo (2005), “Um processo de software pode ser visto como o
conjunto de atividades, métodos, práticas e transformações que guiam
pessoas na produção de software. Um processo eficaz deve, claramente,
considerar as relações entre as atividades, os artefatos produzidos no

desenvolvimento, as ferramentas e os procedimentos necessários e a ha-
bilidade, o treinamento e a motivação do pessoal envolvido”.
Além disso, os processos de software são, geralmente, decompostos em

diversas fases, etapas ou atividades (Falbo, 2005). São elas:

33
1) Planejamento: o objetivo desta atividade é fornecer uma estrutura

que possibilite ao gerente fazer estimativas razoáveis de recursos, custos
e prazos. Uma vez estabelecido o escopo de software, com os requisitos
esboçados, uma proposta de desenvolvimento deve ser elaborada, isto
é, um plano de projeto deve ser elaborado configurando o processo a
ser utilizado no desenvolvimento de software. À medida que o projeto
progride, o planejamento deve ser detalhado e atualizado regularmente.
Pelo menos ao final de cada uma das fases do desenvolvimento (análise
e especificação de requisitos, projeto, implementação e testes), o pla-
nejamento como um todo deve ser revisto e o planejamento da etapa
seguinte deve ser detalhado. O planejamento e o acompanhamento do
progresso fazem parte do processo de gerência de projeto.
2) Análise e Especificação de Requisitos: Nesta atividade, o processo

de levantamento de requisitos é intensificado. O escopo deve ser refina-
do e os requisitos melhor definidos. Para entender a natureza do softwa-
re a ser construído, o engenheiro de software tem que compreender o
domínio do problema, bem como a funcionalidade e o comportamento
esperados. Uma vez capturados os requisitos do sistema a ser desenvol-
vido, estes devem ser modelados, avaliados e documentados. Uma parte
vital dessa atividade é a construção de um modelo descrevendo o que o
software tem que fazer (e não como fazê-lo).
3) Projeto: Esta atividade é responsável por incorporar requisitos tec-

nológicos aos requisitos essenciais do sistema, modelados na ativida-
de anterior e, portanto, requer que a plataforma de implementação seja
conhecida. Esta atividade envolve basicamente duas grandes etapas:
projeto da arquitetura do sistema e projeto detalhado. O objetivo da
etapa de projeto da arquitetura do sistema é definir a arquitetura geral
do software, tendo por base o modelo construído na fase de análise de
requisitos. Essa arquitetura deve descrever a estrutura de nível mais alto
da aplicação e identificar seus principais componentes. Já o objetivo da
etapa de projeto detalhado é detalhar o projeto do software para cada
componente identificado na etapa anterior. Os componentes de softwa-
re devem ser sucessivamente refinados em níveis maiores de detalha-
mento, até que possam ser codificados e testados.
4) Implementação: Nesta atividade o projeto deve ser traduzido para

uma forma passível de execução pela máquina. A atividade de imple-
mentação realiza essa tarefa, isto é, cada unidade de software do projeto
detalhado é implementada.
5) Testes: esta atividade inclui diversos níveis de testes, a saber, teste

de unidade, teste de integração e teste de sistema. Inicialmente, cada
unidade de software implementada deve ser testada e os resultados do-
cumentados. A seguir, os diversos componentes devem ser integrados
34
Capítulo 3
sucessivamente até se obter o sistema. Finalmente, o sistema como um

todo deve ser testado.
6) Entrega e Implantação: uma vez testado, o software deve ser coloca-

do em produção. Para que isso aconteça, contudo, é necessário treinar os
usuários, configurar o ambiente de produção e, muitas vezes, converter
bases de dados. O propósito desta atividade é estabelecer que o software
satisfaça os requisitos dos usuários. Isso é feito instalando o software no
ambiente do usuário e conduzindo testes de aceitação. Quando o software
tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e
a operação (próxima etapa) iniciada.
7) Operação: nesta atividade o software é utilizado pelos usuários no

ambiente de produção.
8) Manutenção: Sem dúvida, o software sofrerá mudanças após ter sido en-
tregue para o usuário. Alterações ocorrerão por diversos motivos: porque
erros foram encontrados, porque o software precisa ser adaptado para aco-
modar mudanças em seu ambiente externo ou porque o cliente necessita
de funcionalidade adicional ou aumento de desempenho. Muitas vezes, de-
pendendo do tipo e do porte da manutenção necessária, essa atividade pode
requerer a definição de um novo processo, em que cada uma das fases prece-
dentes é re-aplicada no contexto de um software existente, ao invés de iniciar
um processo de criação de um novo software.
As atividades descritas acima são as atividades principais de um

processo de software. No entanto, existe uma série de outras ativi-
dades de apoio que se encontram no entorno das atividades prin-
cipais, mas que nem por isso deixam de ser de grande importância
(Pressman, 2006). São elas:
1) Acompanhamento e controle do projeto de software: permi-

te à equipe de software avaliar o progresso com base no plano de
projeto e tomar a ação necessária para manter o cronograma;
2) Gestão de risco: avalia os riscos que podem afetar o resultado

do projeto ou a qualidade do produto;
3) Garantia da qualidade: define e conduz as atividades necessá-

rias para garantir a qualidade do software;
4) Revisões Técnicas Formais: avaliam os produtos de trabalho da

engenharia de software, num esforço para descobrir e remover erros
antes que eles sejam propagados para a próxima ação ou atividade;
5) Medição: define e reúne medidas de processo, projeto e pro-

duto que ajudam a equipe a entregar um software que satisfaça às
necessidades do usuário; pode ser realizada de forma conjugada
com todas as outras atividades principais;

35
6) Gestão de configuração de software: gerencia os efeitos das

modificações ao longo de todo o processo de software;
7) Gestão de reusabilidade: define critérios para a reutilização

dos produtos de trabalho (inclusive componentes de software) e
estabelece mecanismos para obter componentes reusáveis. (Um
produto de trabalho é produzido ao final de uma atividade do
processo de software);
8) Preparação e produção do produto de trabalho: abrange as

atividades necessárias para criar produtos de trabalho como mo-
delos, documentos, registros, formulários e listas.
Finalizando, um processo de software é o conjunto total de atividades

de engenharia de software necessárias para transformar requisitos do
usuário em software (“Managing the Process”, Humphrey, 1989), ou seja,
é um conjunto de atividades realizadas por pessoas cujo objetivo é o de-
senvolvimento ou a evolução de um software e sua documentação.
Figura 3-2: Processo de Desenvolvimento de Software
3.4. Definição de Processos
Um processo de software não pode ser definido de uma maneira univer-

sal. Para ser eficaz e conduzir à construção de produtos de boa qualida-
de, cada processo de software deve ser adequado às especificidades do
projeto em questão, tais como as características da aplicação (domínio
do problema, tamanho, complexidade etc), a tecnologia a ser adotada na
sua construção (paradigma de desenvolvimento, linguagem de progra-
mação, mecanismo de persistência, etc), a organização em que o produ-
to será desenvolvido e a equipe de desenvolvimento, etc.
Muitos aspectos devem ser considerados na definição de um processo

de software. Como descrito no item 3.3., um processo de software pos-
sui atividades principais, tais como: análise e especificação de requisitos,
projeto, implementação e testes, que são a base sobre a qual o processo
de desenvolvimento deve ser construído. Entretanto, a definição de um
processo envolve outros fatores tais como a escolha de um modelo de
36
Capítulo 3
ciclo de vida (ou modelo de processo), que veremos no capítulo 4, o

detalhamento (decomposição) de suas macro-atividades, a escolha de
métodos, técnicas e roteiros (procedimentos) para a sua realização e a
definição de recursos e artefatos necessários e produzidos.
Atividades
1) Faça um paralelo entre os conceitos de engenharia de software
e de processo de software.
2) A engenharia de software pode ser considerada uma tecno-
logia em camadas. Diante dessa afirmação, descreva cada uma
dessas camadas.
2) Identifique as atividades principais e as atividades de apoio
de um processo de software. Fale um pouco sobre cada uma
dessas atividades.


37
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
38
Capítulo 3

39
MODELOS DE CICLO DE VIDA
Prezado aluno,
Neste capítulo apresentaremos o que é o ciclo de vida de um sof-
tware, bem como as categorias mais comuns de modelos de ciclo
de vida: Modelo Linear Seqüencial, Modelo Incremental, Mo-
delo Espiral e Modelo de Prototipagem. Neste capítulo também
serão apresentados as principais atividades e documentos típicos
relacionados ao ciclo de vida de um software.
Bom estudo!
4.1. O Ciclo de Vida de um Software
O ciclo de vida de um software consiste em uma sequência de diferentes ativi-

dades que são executadas durante o desenvolvimento desse software. Durante
o desenvolvimento dessas atividades, diversos artefatos são produzidos. Um
artefato é um produto de trabalho, que pode ser um modelo, documento ou
código-fonte produzido por uma atividade, entre outros. Geralmente, as ati-
vidades e os artefatos estão diretamente relacionados. Além disso, o ciclo de
desenvolvimento de um software é marcado pelo que chamados de marcos,
que são eventos que podem ser usados para definir o status de um projeto.
Por exemplo, o evento de completar o manual do usuário pode ser um marco.
Os marcos são essenciais para fins de gerenciamento porque o término de
um marco permite ao gerente identificar o progresso do desenvolvimento do
software. Gustafson (2003) apresenta uma lista com os Tipos de Atividades
do Ciclo de Vida e Documentos Típicos, listados a seguir:
Atividade Objetivo
Determina se o desenvolvimento
Viabilidade
proposto é viável.
Determina se existe mercado potencial
Análise de mercado
para esse produto.
Determinam quais as funcionalidades o
Requisitos
software deve ter.
Elucidação de Requisitos Obtém dos requisitos do usuário.
40
Capítulo 4
Atividade Objetivo
Determina quais tarefas e estruturas
Análise de Domínio
são comuns ao problema.
Planejamento do Projeto Determina como desenvolver o software.
Análise de Custos Determina a estimativa dos custos.
Constrói o cronograma para o
Cronograma
desenvolvimento.
Garantia da Qualidade de Determina atividades que irão ajudar a
Software garantir a qualidade do produto.
Determina como o software deverá
Projeto
prover as funcionalidades.
Projeto Arquitetural Projeta a estrutura do sistema.
Especifica as interfaces entre as partes
Projeto de Interface
do sistema.
Projeto Detalhado Projeta os algoritmos para cada parte.
Implementação Construção do software.
Execução do software com dados
Teste para ajudar a garantir que o software
funcione corretamente.
Teste do desenvolvedor original que
Teste de Unidade focaliza o esforço de verificação na
menor unidade de projeto do software.
Teste de Integração Teste durante a integração do software.
Teste do software em um ambiente
Teste do Sistema
semelhante ao ambiente operacional.
Teste pelo cliente no ambiente do
Teste Alpha
desenvolvedor.
Teste pelo cliente em seu ambiente
Teste Beta
operacional.
Teste de Aceitação Teste para satisfazer o cliente.
Teste de armazenamento da versão
anterior para garantir que a nova
Teste de Regressão
versão possui todas as capacidades
anteriores.
Provê o cliente com uma solução de
Entrega
software eficiente.
Torna o software disponível no
Instalação
ambiente operacional do cliente.
Treinamento Capacita o usuário a operar o software.
Responde a questões (dúvidas) dos
Help Desk
usuários.
Atualização e evolução do software
Manutenção
para garantir usabilidade constante.
Tabela 4.1 - Atividades do ciclo de Vida do software

41
Modelos de Ciclo de Vida
Atividade Objetivo
Descrição preliminar das
Contrato de Trabalho funcionalidades desejadas, geralmente
produzidas pelo usuário.
Especificação dos Descreve o que o software final irá
Requisitos de Software fazer.
Apresenta as classes e os objetos
Modelo de Objetos
principais.
Mostram a sequência de possíveis
Diagramas de Casos de
comportamentos do ponto de vista do
Uso
usuário.
Descreve a ordem das tarefas e
Cronograma do Projeto as estimativas de tempo e esforço
necessários.
Descreve como o software será testado
Plano de Teste do
para garantir o comportamento
Software
apropriado.
Testes elaborados pelo cliente para
Testes de Aceitação
determinar a aceitabilidade do sistema.
Projeto de Software Descreve a estrutura do software.
Estrutura de alto nível com as
Projeto Arquitetural
interconexões.
Projeto de baixo nível dos módulos ou
Projeto Detalhado
objetos.
Plano de Garantia da Descreve as atividades que serão
qualidade do software desenvolvidas para garantir a
(SQA) qualidade.
Manual do Usuário Descreve como usar o software pronto.
Código Fonte O código fonte do produto atual.
Descreve como os testes foram feitos e
Relatório de Teste
como o sistema se comportou.
Descreve as insatisfações do cliente
com os comportamentos específicos
Relatório de Falhas
do sistema, geralmente suas falhas ou
erros.
Tabela 4.2 – Documentos Típicos
4.2. Categorias de Modelos de Ciclo de Vida
Um modelo de ciclo de vida ou modelo de processo, segundo Falbo (2005),

“pode ser visto como uma representação abstrata de um esqueleto de pro-
cesso, incluindo tipicamente algumas atividades principais, a ordem de
precedência entre elas e, opcionalmente, artefatos requeridos e produzidos.
De maneira geral, um modelo de processo descreve uma filosofia de orga-
42
Capítulo 4
nização de atividades, estruturando as atividades do processo em fases e

definindo como essas fases estão relacionadas. Entretanto, ele não descreve
um curso de ações preciso, recursos, procedimentos e restrições. Ou seja,
ele é um importante ponto de partida para definir como o projeto deve ser
conduzido, mas a sua adoção não é o suficiente para guiar e controlar um
projeto de software na prática”. Ou seja, a escolha de um modelo de ciclo de
vida (ou modelo de processo) é apenas o ponto de partida para a definição
de um processo de desenvolvimento de software.
Como visto na definição de Falbo (2005), um modelo de ciclo de vida,

geralmente, organiza as macro-atividades básicas do processo (atividades
principais), estabelecendo precedência e dependência entre as mesmas.
No entanto, para a definição completa do processo, cada atividade des-
crita no modelo de ciclo de vida deve ser decomposta e para suas subati-
vidades, devem ser associados métodos, técnicas, ferramentas e critérios
de qualidade, entre outros, formando uma base sólida para o desenvolvi-
mento de um software. Além disso, outras atividades tipicamente geren-
ciais devem ser definidas, entre elas atividade de gerência de projetos e de
controle e garantia da qualidade.
Os seguintes fatores influenciam a definição de um processo e, por con-

seguinte, a escolha do modelo de processo a ser usado como base: tipo de
software (por exemplo, sistema de informação, sistema de tempo real etc.),
paradigma de desenvolvimento (paradigma estruturado, orientado a obje-
tos, etc.), domínio da aplicação, tamanho e complexidade do sistema, es-
tabilidade dos requisitos, características da equipe, entre outros. A seguir,
veremos com mais detalhes o que é um modelo de ciclo de vida, e alguns
exemplos principais desses modelos.
Os modelos de ciclo de vida descritos a seguir são os modelos de ciclo de vida

de software mais comuns (Gustafson, 2003):
1. Modelo Linear Sequencial;
2. Modelo Incremental;
3. Modelo Espiral;
4. Modelo de Prototipagem.

43
Quando se estuda um assunto em particular, geralmente existem, na li-

teratura especializada, vários autores que escrevem sobre esse assunto.
Além disso, esses diferentes autores muitas vezes apresentam diferentes
nomenclaturas e categorizações para falar de um mesmo assunto. Em re-
lação a modelos de ciclo de vida, existem outras formas, além dessas, de
categorizá-los e organizá-los, que podem ser destacadas. Em Pressman
(2006), por exemplo, todos os modelos de ciclo de vida são definidos como
prescritivos, pelo fato de prescreverem um conjunto de elementos de pro-
cesso. Esses modelos prescritivos são, então, divididos em:
1. Modelo em Cascata;
2. Modelos Incrementais: que compreendem o Modelo
Incremental e o Modelo RAD
(Rapid Application Development);
3. Modelos Evolucionários: que compreendem a
Prototipagem, O Modelo Espiral e O Modelo de
Desenvolvimento Concorrente.
Já Falbo (2005) categoriza os modelos de ciclo de vida como:
1. Modelos Sequenciais: que contemplam o Modelo em
Cascata e o Modelo V;
2. Modelos Incrementais: que contemplam o Modelo
Incremental e o Modelo RAD;
3. Modelos Evolutivos ou Evolucionários: que contempla
o Modelo Espiral;
4. Prototipação.
4.3. Modelo Linear Sequencial
Também chamado de Modelo em Cascata, esse modelo tem seu diagrama

parecido com uma série de cascatas, daí seu nome. Inicialmente descrito
por Royce em 1970, foi a primeira realização de uma sequência padrão
de tarefas. Existem muitas versões desse modelo. Na versão apresentada
na Figura 4.1, note que as atividades de planejamento de projeto estão
incluídas na fase de requisitos. Além disso, as fases de entrega e ma-
nutenção foram deixadas de fora. Já a Figura 4.2 apresenta uma versão
diferente da anterior. Compare as duas e tire suas conclusões sobre qual
seria a melhor, na sua opinião.
44
Capítulo 4
Figura 4.1 - da página 13 da coleção schaum –
Figura 4-1: Modelo em Cascata – Versão 1

Fonte: Gustafson, 2003
Figura 4-2: Modelo em Cascata – Versão 2

Fonte: Falbo, 2005

45
4.4. Modelo Incremental
Há muitas situações em que os requisitos iniciais do software são ra-

zoavelmente bem definidos, mas o tamanho do sistema a ser desenvol-
vido impossibilita a adoção de um modelo sequencial, principalmente
quando há a necessidade de se fornecer rapidamente aos usuários um
conjunto limitado de funcionalidades e depois refinar e expandir essas
funcionalidades em novas versões do software. Nesses casos, o uso de
um modelo incremental é o mais adequado.
O Modelo Incremental foi proposto inicialmente por D. L. Parnas. O Obje-

tivo era projetar e entregar ao cliente um conjunto mínimo do sistema que
continuasse a ser um sistema usável. O processo, então, continuaria a inte-
ragir ao longo de todo o ciclo de vida com incrementos adicionais mínimos.
Ou seja, no desenvolvimento incremental, o sistema é dividido em subsiste-
mas ou módulos, tomando por base a funcionalidade. Os incrementos (ou
versões) são definidos, começando com um pequeno subsistema funcional
que, a cada ciclo, é acrescido de novas funcionalidades. Além de acrescentar
novas funcionalidades, nos novos ciclos, as funcionalidades providas ante-
riormente podem ser modificadas para melhor satisfazer às necessidades
dos clientes/usuários. Vale ressaltar que a definição das versões, com sua
segmentação e atribuição de requisitos, é realizada antes do desenvolvimen-
to da primeira versão. As vantagens deste modelo incluem fornecer logo ao
cliente um sistema e novas versões de trabalho.
4.5. Modelo Espiral
Como todo sistema complexo, o software também evolui com o tempo. Seus
requisitos, de negócio ou do próprio produto, muitas vezes são difíceis de se-
rem definidos ou mudam frequentemente durante o desenvolvimento. Dessa
forma, é importante que os profissionais de software possam contar com mo-
delos de ciclo de vida que tenham sido explicitamente projetados para lidar
com incertezas e contínuas mudanças. Por serem iterativos, os modelos in-
crementais podem ser aplicados a esses casos, permitindo o desenvolvimento
de versões cada vez mais completas do software. Vale ressaltar que a grande
maioria dos modelos evolutivos toma como pressuposto que os requisitos es-
tejam muito bem definidos. Faz parte desta categoria o Modelo Espiral.
O Modelo Espiral, também chamado Modelo Espiral de Boehm, foi introdu-

zido por B. Boehm, de quem recebeu o nome. A imagem do modelo é de
uma espiral que começa no meio e continuamente revisa as tarefas básicas
do usuário: Especificação de requisitos, Análise, Projeto, Implementação,
Testes e Entrega e Implantação.
46
Capítulo 4
A palavra iterativo quer dizer um processo que se repete diversas

vezes para se chegar a um resultado e a cada vez gera um resulta-
do parcial que será usado na vez seguinte.
Fonte: wikipédia.
Figura 4-3: Modelo Espiral

Fonte: Falbo, 2005
4.6. Modelo de Prototipagem
Às vezes, os clientes podem até ter em mente um conjunto de objetivos

gerais para um sistema de software. No entanto, eles não são capazes
de identificar claramente os requisitos de entrada, processamento e
saída desse sistema. Também chamado de Prototipação, este modelo
pode ser útil para ajudar a levantar e validar requisitos, mas também
pode acontecer de os clientes/usuários só terem uma dimensão real do
que está sendo desenvolvido se colocados diante do sistema. Nesses
casos, o uso da prototipação é fundamental. Ou seja, a prototipação é
uma técnica cujo objetivo é ajudar tanto os profissionais de software
quanto os clientes a entenderem o que está sendo desenvolvido, quan-
do os requisitos não estão claros. Apesar de a prototipação poder ser
usada como um modelo de processo independente, ela é mais comu-
mente usada como uma técnica que pode ser aplicada no contexto de
qualquer modelo de processo.

47
Na prototipação, os objetivos gerais do software são definidos, identifi-

cam-se as necessidade do cliente e as áreas que necessitam de mais defi-
nições são delineadas. Após isso, uma iteração é planejada e modelada
na forma de um projeto rápido. Esse projeto rápido concentra-se apenas
na representação dos aspectos do sistema de software que são visíveis ao
cliente/usuário. Esse projeto leva ao desenvolvimento de um protótipo.
Esse protótipo é implantado e depois avaliado pelo cliente/usuário. O
feedback dado pelo cliente/usuário é usado para refinar os requisitos do
sistema. A iteração ocorre à medida que o protótipo é ajustado para
satisfazer as necessidades do cliente, e ao mesmo tempo permite aos
desenvolvedores entender melhor o que precisa ser feito.
Em administração, feedback é o procedimento que consiste no pro-

vimento de informação a uma pessoa sobre o desempenho, conduta
ou eventualidade executada por ela e objetiva reprimir, reorientar
e/ou estimular uma ou mais ações determinadas, executadas ante-
riormente. No nosso contexto, o feedback são as informações que o
cliente/usuário fornece aos profissionais de software sobre o sistema
de software em questão, sob diferentes aspectos, quer seja de utiliza-
ção, atendimento das suas necessidades, facilidade de uso, etc.
Atividades
1) Quais são as diferenças entre um modelo de ciclo de vida do
software e um modelo processo?
2) Pesquise sobre outras versões do modelo em cascata e des-
creva em forma de diagrama de atividades as versões que você
encontrar.
3) Descreva com suas próprias palavras o modelo de
prototipagem.
Exercícios Resolvidos
1. Como um modelo de ciclo de vida de fases contempla o geren-

ciamento de software?
2. Qual é a característica de um marco?
48
Capítulo 4
3. Para cada um dos seguintes documentos, indique a(s) fase(s)

do ciclo de vida do software em que são desenvolvidos. Use como
base o modelo cascata.
- Manual final do usuário
- Projeto arquitetural
- Plano de SQA
- Especificação de Módulos
- Código Fonte
- Seqüência de Trabalho
- Plano de Teste
- Manual de Usuário Preliminar
- Projeto detalhado
- Estimativa de custo
- Plano de Projeto
- Relatório de Teste
- Documentações
4. Ordene as seguintes tarefas em termos do modelo cascata:

- Teste de aceitação
- Planejamento do projeto
- Teste de unidade
- Revisão de requisitos
- Estimativa de custo
- Projeto em alto nível
- Análise de mercado
- Projeto em baixo nível
- Teste de sistema
- Revisão do projeto
- Implementação
- Especificação de Requisitos
Respostas dos Exercícios

1. O ciclo de vida de fases melhora a visibilidade do projeto. O projeto
pode ser gerenciado usando-se as fases como marcos. Fases mais de-
talhadas permitem um monitoramento mais próximo do progresso.
2. Um marco deve estar sempre relacionado com o progresso de de-

senvolvimento do software. Por exemplo, ele pode ser usado para de-
finir o status de um projeto e, para fins de gerenciamento, permite ao
gerente identificar o progresso do desenvolvimento do software.

49
3.
- Manual final do usuário – fase de implementação
- Projeto arquitetural – fase de projeto
- Plano de SQA – fase de planejamento de projeto
- Especificação de Módulos - fase de projeto
- Código Fonte - fase de implementação
- Sequência de Trabalho – fase de viabilidade
- Plano de Teste – fase de teste
- Manual de Usuário Preliminar – fase de requisitos
- Projeto detalhado - fase de projeto
- Estimativa de custo - fase de planejamento de projeto
- Plano de Projeto - fase de planejamento de projeto
- Relatório de Teste – fase de teste
- Documentações - fase de implementação
4. Ordem das tarefas:

1. Análise de mercado
2. Planejamento do projeto, estimativa de custo, especificação de
requisitos (podem ser feitos concomitantemente)
3. Revisão dos requisitos
4. Projeto em alto nível
5. Projeto em baixo nível
6. Revisão do projeto
7. Implementação
8. Teste de unidade
9. Teste de sistema
10. Teste de aceitação
(1) FALBO, R.A., Notas de Aula: Engenharia de Software. Dis-

ponível em http://www.inf.ufes.br/~falbo, 2005.
(2) GUSTAFSON, DAVID A. Teoria a problemas de engenharia
de software. Porto alegre: Bookman, 2003. (Coleção Schaum).
PRESSMAN, R.S., Engenharia de Software. São Paulo: McGraw-
Hill, 6ª Edição, 2006.
50
Capítulo 4
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________

51
ATIVIDADES DE
DESENVOLVIMENTO
Prezado aluno,
Como visto na seção 1.3, em um processo de software, em uma abor-
dagem de engenharia de software, podemos considerar três tipos de
atividades principais: de desenvolvimento, de gerência de projetos e
de garantia da qualidade. No entanto, a espinha dorsal do desenvol-
vimento de um software é formada pelas atividades chamadas de
atividades de desenvolvimento, técnicas ou atividades de cons-
trução. As atividades de gerência e de controle da qualidade são
muitas vezes consideradas atividades de apoio. Neste capítulo apre-
sentarei as atividades de desenvolvimento, que são as atividades
que contribuem diretamente para o desenvolvimento do produto de
software a ser entregue ao cliente. As atividades de desenvolvimen-
to compreendem basicamente as seguintes atividades: especificação
e análise de requisitos, projeto de sistema, implementação e testes,
entrega e manutenção.
Bom estudo!
5.1. Especificação e Análise de Requisitos
Em relação às atividades de desenvolvimento de software, a primeira

coisa a ser feita é capturar os requisitos que devem ser tratados pelo
sistema que será desenvolvido. Ter um entendimento completo dos re-
quisitos do software que será desenvolvido é um dos fatores mais im-
portantes que determinarão o sucesso ou não do esforço de desenvolvi-
mento desse software.
Também chamada de engenharia de requisitos, esta fase do desen-

volvimento de um software é um processo de descoberta, refinamento,
modelagem e especificação. A engenharia de requisitos é o processo de
identificar todos os envolvidos, descobrir seus objetivos e necessidades
e documentá-los apropriadamente.
Nesta fase, o escopo do software, que foi definido no planejamento do proje-

to, é refinado em detalhes. Também são especificadas as funções e o desem-
52
Capítulo 5
penho do software, bem como as interfaces com outros sistemas e restrições

que o software deve atender. Também são construídos os modelos de dados
que definem o controle e o comportamento operacional do software. Final-
mente, são definidos os critérios para a avaliação da qualidade do produto
de software nas atividades subsequentes (FALBO, 2005).
Falbo (2005) apresenta a engenharia de requisitos como um processo

composto das seguintes atividades:
• Levantamento de Requisitos: nesta atividade identificam-se os

usuários, clientes e especialistas de domínio, que trabalham juntos
com os engenheiros de requisitos para descobrir, articular e entender
a organização como um todo, o domínio da aplicação, os processos
de negócio, as necessidades que o software deve atender e os pro-
blemas e deficiências dos sistemas atuais. Também são levantados
os diferentes pontos de vista dos envolvidos no processo, as opor-
tunidades de melhoria e restrições existentes, os problemas a serem
resolvidos e o desempenho requerido do sistema como um todo.
• Análise de Requisitos: tem como objetivo definir um conjunto de

requisitos consistentes e sem ambiguidades, que serão usados como
base para o desenvolvimento do software. Nesta atividade serão
construídos diversos tipos de modelos. Nesta fase também pode in-
cluir a negociação para se resolver conflitos detectados.
• Documentação de Requisitos: atividade de representar os resulta-

dos da engenharia de requisitos em um documento (ou conjunto de
documentos) contendo os requisitos do software.
• Verificação e Validação de Requisitos: a verificação de requisi-

tos avalia se o documento de especificação de requisitos está sendo
construído corretamente e se está de acordo com padrões previa-
mente definidos, não contendo requisitos ambíguos, incompletos,
incoerentes ou impossíveis de serem testados. A validação de re-
quisitos avalia se o documento de especificação de requisitos está
correto, ou seja, se os requisitos e modelos documentados atendem
às reais necessidades e requisitos dos clientes/usuários.
• Gerência de Requisitos: esta atividade preocupa-se em gerenciar

as mudanças que porventura ocorram nos requisitos já acordados,
mantendo uma trilha dessas mudanças, gerenciando os relaciona-
mentos entre os requisitos e as dependências entre o documento de
requisitos e demais artefatos produzidos no processo de software,
de forma a garantir que mudanças nos requisitos ocorram de manei-
ra controlada e documentada.

53
Atividades de Desenvolvimento
Finalizando, um requisito de software pode ser funcional ou não funcio-

nal. Requisitos funcionais, como o próprio nome diz, descrevem as fun-
ções que o sistema deve fornecer e como o sistema deve se comportar em
determinadas situações. Já os requisitos não funcionais descrevem restri-
ções sobre as funções oferecidas, tais como as restrições de tempo, de uso
de recursos, etc. Alguns requisitos não funcionais dizem respeito ao sis-
tema como um todo e não a uma funcionalidade específica. Os requisitos
não funcionais podem ser classificados de diferentes maneiras: requisitos
de desempenho, requisitos de portabilidade, requisitos legais, requisitos
de conformidade etc. (FALBO, 2005).
5.2. Projeto de Sistema
A fase de projeto inicia-se assim que os requisitos do software tiverem

sido especificados e modelados. Esta atividade corresponde à primeira
das três atividades do domínio computacional – projeto, implementa-
ção e testes – requeridas para se construir um sistema de software.
A atividade de projeto envolve a modelagem de como o sistema será

implementado, incorporando os requisitos não funcionais aos modelos
construídos na fase de análise. O objetivo do projeto de um sistema é
incorporar a tecnologia aos requisitos essenciais dos usuários, projetan-
do o que será construído na fase de implementação. Assim, é necessário
conhecer as tecnologias disponíveis e as facilidades do ambiente de sof-
tware no qual o sistema será implementado.
O projeto de software é um processo iterativo. O projeto inicialmente é

representado em um alto nível de abstração. À medida que as iterações
ocorrem, os refinamentos conduzem a representações com níveis me-
nores de abstração.
54
Capítulo 5
Uma visão geral da atividade de projeto é apresentada na Figura 5.1.
Figura 5-1: Visão Geral da Atividade de projeto

Fonte: Falbo, 2005
A Tabela 5.1 nos apresenta primeiramente o quê um projeto de sistema

deve ser e contemplar, bem como nos apresenta os produtos de trabalho
(artefatos) produzidos nessa fase (FALBO, 2005).
Tabela 5.1
Um projeto de sistema deve:

Contemplar todos os requisitos explícitos contidos no modelo de análise e
todos os requisitos implícitos desejados pelos clientes/usuários.
Ser um guia legível e compreensível para aqueles que irão codificar, testar e
fazer a manutenção do software.
Fornecer um quadro completo do software, tratando aspectos funcionais, com-
portamentais e de dados, segundo uma perspectiva de implementação.
Diagramas de Casos de Uso
Um projeto de sistema deve produzir:
Projeto da Arquitetura do software: visa definir os grandes componentes
estruturais do software e seus relacionamentos.
Projeto de Dados: tem como objetivo projetar a estrutura de armazenamento
de dados necessária para implementar o software.
Projeto de Interface: visa descrever como o software deve se comunicar
internamente (interfaces internas), com outros sistemas (interfaces externas)
e com seus usuários (interface com o usuário).
Projeto Procedimental Detalhado: tem como objetivo refinar e deta-
lhar a descrição procedimental dos componentes estruturais da arqui-
tetura do software.

55
5.3. Implementação e Testes
Após projetar um sistema, é necessário escrever os programas que im-

plementem esse projeto e testá-los. Em relação à implementação, sabe-
mos que mesmo que um projeto esteja bem elaborado, esta tarefa não
é necessariamente fácil. A seguir listamos alguns aspectos que tornam
esta tarefa tão complexa:
t Muitas vezes, os projetistas não conhecem a plataforma de im-

plementação em detalhes e, portanto, não são capazes de chegar
a um projeto algorítmico passível de implementação direta;
t Questões relacionadas à legibilidade, alterabilidade e reutili-

zação devem ser levadas em conta;
t Geralmente os programadores trabalham em equipe, necessi-

tando integrar, testar e alterar código produzido por outros, o
que cria uma necessidade da criação de padrões organizacio-
nais que devem ser seguidos por todos os programadores;
t Deve-se sempre ter o cuidado de manter a correspondência entre

os componentes do projeto e o código. Lembrar sempre que o
projeto é o guia para a implementação, ainda que os programa-
dores possam e devam ter certa flexibilidade de implementação;
t Para uma implementação bem-sucedida, as unidades de sof-

tware devem ser codificadas e critérios de verificação das mes-
mas devem ser definidos.
Em relação a Testes, é muito importante que, após a implementa-

ção, o produto de software produzido seja testado, a fim de que se
descubra o número máximo de defeitos possível antes da entrega do
produto de software ao cliente.
O processo de teste envolve quatro atividades principais (Falbo, 2005),

descritas a seguir:
t Planejamento de Testes: diz respeito à definição das atividades de

teste, das estimativas dos recursos necessários para realizá-las, dos
objetivos, estratégias e técnicas de teste a serem adotadas e dos crité-
rios para determinar quando uma atividade de teste está completa;
56
Capítulo 5
t Projeto de Casos de Testes: é a atividade chave para um teste bem-

sucedido, ou seja, para se descobrir a maior quantidade de defeitos
com o menor esforço possível. Os casos de teste devem ser cuida-
dosamente projetados e avaliados para se tentar obter um conjunto
de casos de teste que seja representativo e envolva as várias possibi-
lidades de exercício das funções do software (cobertura dos testes).
Existe uma grande quantidade de técnicas de teste para apoiar os
testadores a projetar casos de teste, oferecendo uma abordagem sis-
temática para o teste de software;
t Execução dos testes: consiste na execução dos casos de teste e regis-

tro de seus resultados;
t Avaliação dos resultados: detectadas falhas, os defeitos deverão ser

procurados. Não detectadas falhas, deve-se fazer uma avaliação final
da qualidade dos casos de teste e definir pelo encerramento ou não
de uma atividade de teste.
Existem diferentes Categorias de Técnicas de Teste. Usaremos a ca-

tegorização que separa as Técnicas de Testes em Funcional ou Teste
Caixa-Preta, Estrutural ou Teste Caixa-Branca e as baseadas em má-
quinas de estado (Falbo, 2005).
t Os testes funcionais ou caixa-preta são conduzidos na interface

do software, ou seja, o conhecimento sobre uma determinada
implementação não é usado. Esse tipo de teste utiliza as es-
pecificações (de requisitos, análise e projeto) para definir os
objetivos do teste e, portanto, para guiar o projeto de casos
de teste. Os testes caixa-preta ou funcionais, como o próprio
nome diz, são empregados para demonstrar que as funções do
software estão operacionais, que a entrada é adequadamente
aceita e a saída é corretamente produzida e que a integridade
da informação externa é mantida. Testes caixa preta exami-
nam algum aspecto fundamental do sistema, pouco se preo-
cupando com a estrutura lógica interna do software.
t Os testes estruturais ou caixa-branca são baseados em um exa-

me rigoroso do detalhe procedimental. Esse tipo de teste es-
tabelece os objetivos do teste com base em uma determinada
implementação, verificando detalhes do código, ao contrário
do teste caixa-preta. Caminhos lógicos internos são testados,
definindo casos de testes que exercitem conjuntos específicos
de condições ou laços.

57
t Os testes baseados em máquinas de estado são projetados utili-

zando o conhecimento subjacente à estrutura de uma máqui-
na de estados para determinar os objetivos do teste.
Em relação a Técnicas de Teste de Software, é muito importante

ressaltar que as diferentes técnicas devem ser utilizadas de forma
complementar, já que elas têm propósitos distintos, detectando
categorias de erros distintas.
Além das Técnicas de Testes, existe o que chamamos de Estratégias de

Teste. A estratégia de teste é a série planejada de realização dos testes, e
compreende basicamente três grandes fases. A saber: teste de unidade,
teste de integração e teste de sistema (Falbo, 2005).
t Teste de Unidade: tem por objetivo testar a menor unidade do

projeto, procurando identificar erros de lógica e de implemen-
tação em cada módulo separadamente. Como menor unidade
de projeto, podemos considerar um componente de software
que não pode ser subdividido. No paradigma estruturado, a
menor unidade refere-se a um procedimento ou função.
t Teste de Integração: tem como objetivo descobrir erros asso-

ciados às interfaces entre os módulos, quando esses são inte-
grados para formar estrutura do produto de software.
• Teste de Sistema: tem como objetivo identificar erros de fun-

ções (requisitos funcionais) e características de desempenho
(requisito não funcional) que não estejam de acordo com as
especificações pré-estabelecidas.
5.4. Entrega e Manutenção
A Entrega é a última etapa do processo de desenvolvimento de software,

e ocorre após o software ter sido testado, aceito e instalado no ambiente
operacional do usuário. Uma vez instalado, o software passa a ser usado,
e eventuais mudanças, quer sejam de caráter corretivo, quer sejam de
caráter de evolução, caracterizam-se como uma manutenção.
Após o produto de software ser entregue ao cliente e entrar em opera-

ção, podemos considerar o término do desenvolvimento desse sistema.
A partir daí, deve-se garantir que o sistema continuará sendo útil e aten-
58
Capítulo 5
dendo às necessidades do usuário, o que pode demandar alterações no

mesmo. Começa, então, a fase de manutenção. Existem diferentes tipos
de manutenção, a saber: manutenção corretiva, adaptativa, perfectiva e
preventiva, descritas a seguir (Falbo, 2005).
• Manutenção Preventiva: trata de problemas decorrentes de

defeitos. À medida que falhas ocorrem, elas são relatadas à
equipe de manutenção, que se encarrega de encontrar o de-
feito que causou a falha e fazer as correções necessárias, quer
sejam nos requisitos, na análise ou projeto do sistema, ou em
sua implementação.
• Manutenção Adaptativa: diz respeito às necessidades de

adaptação que ocorrem quando há uma mudança no ambiente
do sistema, incluindo hardware e software de apoio.
• Manutenção Perfectiva: consiste em realizar mudanças para

melhorar algum aspecto do sistema, mesmo quando nenhuma
das mudanças for consequência de defeitos. Isso inclui a adi-
ção de novas capacidades, bem como ampliações gerais.
• Manutenção Preventiva: tem como objetivo realizar mu-

danças a fim de prevenir falhas. Esse tipo de manutenção ge-
ralmente ocorre quando um mantenedor descobre um defeito
que ainda não causou uma falha e, então, decide corrigi-lo
antes que seja causada efetivamente uma falha.
5.5. Exemplo da Loja Vitória
Para tornar este capítulo o mais prático possível, nesta seção apresenta-
remos exemplos das principais documentações relacionadas a um pro-
jeto de software. Trata-se de um projeto de informatização de uma loja
chamada “Loja Vitória”. Serão inicialmente apresentados os documen-
tos de especificação de requisitos. Os documentos de análise e projeto
podem ser consultados no Anexos A e B, respectivamente, ao final do
material impresso.

59
5.5.1. Documento de Especificação de Requisitos
Projeto Loja Vitória
1. Introdução
Este documento contém a especificação de requisitos para o projeto de

informatização da Loja Vitória. Essa atividade foi desenvolvida usando
a técnica de modelagem de casos de uso e, portanto, esse documento
apresenta os diagramas de caso de uso gerados, bem como as descrições
dos atores e dos casos de usos identificados nesses diagramas. Na seção
2, uma breve descrição do domínio do problema é apresentada.
2. Descrição do Mini-mundo
Uma pequena empresa, a Loja Vitória, deseja um sistema para auto-

matizar o seu faturamento e controle de estoque. A loja trabalha com
uma variedade de produtos que são oferecidos por fornecedores. De um
produto, deseja-se saber o nome, descrição, valor de venda, estoque e
fornecedores. Para facilitar a manutenção do estoque da loja, é mantido
um estoque mínimo para cada produto. Um produto pode ser obtido de
diversos fornecedores e cada fornecedor oferece vários produtos à loja.
Fornecedores são pessoas jurídicas, das quais se deve saber o nome, en-
dereço, telefone, CNPJ e prazo de entrega dos produtos.
Clientes compram produtos. Quando é feita a venda de um ou mais

produtos, é emitida uma nota fiscal de saída contendo o cliente, data de
emissão e itens determinando a quantidade de cada produto vendido. A
uma nota fiscal de saída pode ser estabelecido ainda um desconto. Um
cliente possui nome, endereço, telefone e CPF (caso seja pessoa física)
ou CNPJ (caso seja pessoa jurídica). Clientes que ainda não fizeram uma
compra são considerados prospectados e clientes que já compraram aci-
ma de R$ 2.000,00 são considerados preferenciais, podendo obter um
desconto de até 10% em suas compras. Clientes não preferenciais (ativos
ou prospectados) poderão ter descontos de até 5%.
Quando produtos são entregues à loja por um fornecedor, devem ser

registradas notas fiscais de entrada, contendo o fornecedor dos produ-
tos, data de entrada e itens, determinando a quantidade de cada produto
adquirido. No momento em que notas fiscais de entrada são registradas,
as quantidades compradas devem ser acrescidas ao estoque dos respec-
tivos produtos. Da mesma forma, quando são emitidas notas fiscais de
saída, os estoques dos produtos vendidos devem ser decrementados.
Para facilitar a administração da empresa, o gerente da loja deseja que o

sistema seja capaz de emitir os seguintes relatórios: listagem de produtos
60
Capítulo 5
com estoque abaixo do mínimo, produtos de um fornecedor, fornece-

dores de um produto, notas fiscais de entrada emitidas em determinado
período, notas fiscais de saída registradas em determinado período e
listagem de clientes preferenciais.
3. Modelo de Casos de Uso
A Figura 1 mostra o diagrama de pacotes do sistema, subdividindo-o

em dois subsistemas, a saber:
t Controle Interno: envolve a funcionalidade relacionada com

o controle interno da loja, abrangendo cadastro de clientes,
produtos e fornecedores.
t Controle de Notas Fiscais: envolve a funcionalidade relacionada

à criação de notas fiscais, incluindo emissão de notas fiscais de
saída, registro de notas fiscais de entrada e emissão de relatórios.
Figura 1 – Diagrama de Pacotes.
3.1. Controle Interno
A figura 2 mostra o diagrama de casos de uso referente ao controle in-

terno. Na sequência, os casos de uso identificados são descritos.
Figura 2 – Diagrama de Casos de Uso “Controle Interno”.

61
Os atores que atuam nesse subsistema são o Ator Operador e o Ator

Administrador, que representam os papeis desempenhados, respecti-
vamente, pelos funcionários e pelo gerente da loja.
Sistema: Controle de Estoque

Pacote: Controle Interno
Caso de Uso: Controlar Cliente

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pelo controle de clientes, abrangen-
do a inclusão de um novo cliente, alteração, consulta, e exclusão de
clientes existentes.
Curso Normal:
Incluir Novo Cliente

O administrador ou operador informa os dados do novo cliente, incluindo nome,
endereço, telefones e CPF (caso seja pessoa física) ou CNPJ (caso seja pessoa jurídi-
ca). Caso os dados sejam válidos, o cliente é registrado com o estado “prospectado”.
Alterar Dados de Cliente

O administrador ou operador informa o cliente cujos dados deseja alterar e os
novos dados. Os novos dados são validados e a alteração registrada.
Consultar Dados de Cliente

O administrador ou operador informa o cliente que deseja consultar. Os dados
do cliente são apresentados.
Ativar Cliente
Pré-requisito: cliente selecionado.
O sistema calcula o total de compras do cliente, dado pela soma do valor total de
cada uma de suas notas fiscais de saída. Se o total for superior a R$ 2.000,00, o esta-
do do cliente é alterado para “preferencial”. Caso contrário é alterado para “ativo”.
Desativar Cliente
O administrador informa o cliente que deseja desativar. O estado do cliente é
alterado para “inativo”.
Excluir Cliente
O administrador ou operador informa o cliente que deseja excluir. Um cliente
somente poderá ser excluído se não houver nenhum vínculo com notas ficais
de saída. Os dados do cliente são apresentados e é solicitada a confirmação.
Caso confirmado, o cliente é excluído.
62
Capítulo 5
Cursos Alternativos:
Incluir Novo Cliente / Alterar Dados de Cliente
t Dados do cliente inválidos: uma mensagem de erro é exibida,
solicitando correção da informação inválida.
Excluir Cliente
t Cliente possui notas fiscais de saída: uma mensagem de erro é
exibida indicando que o cliente possui notas ficais de saída.
Restrições de Integridade:
Não há restrições de integridade.

Caso de Uso: Cadastrar Produto

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pelo controle de produtos, abrangendo a
inclusão de um novo produto, alteração, consulta e exclusão de produ-
tos existentes.
Curso Normal:
Incluir Novo Produto
O administrador informa os dados do novo produto, incluindo nome, des-
crição, valor de venda, estoque mínimo e fornecedores. O estoque do pro-
duto é inserido como zero. Caso os dados sejam válidos, serão registrados.
Alterar Dados de Produto

O administrador informa o produto cujos dados deseja alterar e os no-
vos dados. Os novos dados são validados e a alteração registrada.
Consultar Dados de Produto

O administrador ou operador informa o produto que deseja consultar.
Os dados do produto são apresentados.
Excluir Produto
O administrador informa o produto que deseja excluir. Um produto so-
mente poderá ser excluído se não houver nenhum vínculo com itens
de notas ficais. Os dados do produto são apresentados e é solicitada a
confirmação. Caso confirmado, o produto é excluído.

63
Incluir Novo Produto / Alterar Dados de Produto
t Dados do produto inválidos: uma mensagem de erro é exibi-

da, solicitando correção da informação inválida.
Excluir Produto
t Produto possui vínculo com itens de notas fiscais: uma men-

sagem de erro é exibida indicando que o produto possui itens
de notas ficais.

Caso de Uso: Cadastrar Fornecedor

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pelo controle de fornecedores, abrangen-
do a inclusão de um novo fornecedor, alteração, consulta e exclusão de
fornecedores existentes.
Curso Normal:
Incluir Novo Fornecedor

O administrador informa os dados do novo fornecedor, incluindo nome,
endereço, telefones, CNPJ e prazo de entrega. Caso os dados sejam vá-
lidos, serão registrados.
Alterar Dados de Fornecedor

O administrador informa o fornecedor cujos dados deseja alterar e os
novos dados. Os novos dados são validados e a alteração registrada.
Consultar Dados de Fornecedor

O administrador ou operador informa o fornecedor que deseja consul-
tar. Os dados do fornecedor são apresentados.
Excluir Fornecedor
O administrador informa o fornecedor que deseja excluir. Um fornece-
64
Capítulo 5
dor somente poderá ser excluído se não houver nenhum vínculo com
notas ficais de entrada. Os dados do fornecedor são apresentados e é
solicitada a confirmação. Caso confirmado, o fornecedor é excluído.
Incluir Novo Fornecedor / Alterar Dados de Fornecedor
t Dados do fornecedor inválidos: uma mensagem de erro é exi-
bida, solicitando correção da informação inválida.
Excluir Fornecedor
t Fornecedor possui notas fiscais de entrada: uma mensagem de
erro é exibida indicando que o fornecedor possui notas ficais
de entrada.
3.2. Controle de Notas Fiscais
A Figura 3 mostra o diagrama de casos de uso referente ao controle de

notas fiscais. Na sequência, os casos de uso identificados são descritos.
Figura 2 – Diagrama de Casos de Uso “Controle de Notas Fiscais”.
O ator que atua neste subsistema é o Ator Operador, que representa o papel
desempenhado pelos operadores do sistema da loja.

65

Pacote: Controle de Nota Fiscal
Caso de Uso: Controlar Nota Fiscal de Saída

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pelo controle de Notas Fiscais de Saída,
abrangendo a emissão e consulta de notas fiscais de saída.
Curso Normal
Emitir Nota Fiscal de Saída
Pré-requisito: cliente informado não deve ser inativo.
O administrador ou operador informa o cliente constante da nota fiscal

e, em seguida, os produtos e suas respectivas quantidades. O sistema cal-
cula e exibe o valor total da nota. O valor total é dado pela somatória dos
valores dos produtos vezes as quantidades pedidas. O administrador ou
operador informa, então, um desconto sobre o valor total, que pode ser de
até 10% para clientes preferenciais e de até 5% para os demais clientes. O
sistema verifica se todos os produtos informados existem em estoque em
quantidade igual ou superior à desejada. Se existirem, as quantidades em
estoque são decrementadas das quantidades pedidas na nota.
Se os dados forem válidos, a nota fiscal é registrada com um número

gerado pelo sistema e a data de emissão.
É realizado o evento “Ativar cliente” do caso de uso “Controlar Cliente”.
Consultar Nota Fiscal de Saída

O administrador ou operador seleciona a nota fiscal de saída que deseja
consultar. Os dados da nota fiscal são apresentados.
Cursos Alternativos
Emitir Nota Fiscal de Saída
t Há produtos com quantidade em estoque inferior à pedida:
Uma mensagem é exibida solicitando a alteração da quanti-
dade pedida.
t Desconto informado superior ao permitido: Uma mensagem
é exibida solicitando a correção do desconto.
Restrições de Integridade
66
Capítulo 5

Caso de Uso: Controlar Nota Fiscal de Entrada

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pelo controle de Notas Fiscais de Entrada,
abrangendo o registro e a consulta de notas fiscais de entrada.
Curso Normal
Registrar Nota Fiscal de Entrada
O administrador ou operador informa o fornecedor e o número da nota
fiscal e, em seguida, os produtos e suas respectivas quantidades. Os da-
dos são validados. As quantidades em estoque de cada item contido na
Nota Fiscal são acrescidas das quantidades informadas na nota.
A nota fiscal é registrada com a data de registro.
Consultar Nota Fiscal de Entrada

O administrador ou operador informa a nota fiscal de entrada que dese-
ja consultar. Os dados da nota fiscal são apresentados.
Cursos Alternativos
Registrar Nota Fiscal de Entrada
t Dados da nota fiscal inválidos: uma mensagem de erro é exibi-

Caso de Uso: Emitir Relatório

Data: 16/08/2005
Descrição:
Este caso de uso é responsável pela emissão dos relatórios que auxiliam
o controle do estoque da empresa.

67
Curso Normal
Listar Produtos Abaixo do Estoque Mínimo

O administrador ou operador do sistema solicita um relatório dos pro-
dutos com quantidade em estoque abaixo do mínimo permitido. O sis-
tema exibe uma listagem dos produtos cuja quantidade em estoque se
encontra abaixo da quantidade mínima permitida.
Listar Produtos por Fornecedor

O administrador ou operador do sistema informa o fornecedor cujos
produtos deseja listar. O sistema exibe um relatório contendo os produ-
tos fornecidos pelo fornecedor informado.
Listar Fornecedor por Produto

O administrador ou operador do sistema informa o produto cujos for-
necedores deseja listar. O sistema exibe um relatório contendo os forne-
cedores do produto informado.
Listar Notas Fiscais de Entrada

O administrador ou operador informa o período de registro em que
deseja listar as notas fiscais de entrada. O sistema exibe um relatório
contendo as notas fiscais de entrada registradas no período informado.
Listar Notas Fiscais de Saída

O administrador ou operador informa o período de emissão em que
deseja listar as notas fiscais de saída. O sistema exibe um relatório con-
tendo as notas fiscais de saída emitidas no período informado.
Listar Clientes por Estado

O administrador ou operador informa o estado dos clientes que deseja
listar. O sistema exibe um relatório contendo os clientes que se encon-
tram no estado informado.
Cursos Alternativos
Listar Notas Fiscais de Entrada / Listar Notas Fiscais de Saída
t Período informado inválido: uma mensagem de erro é exibi-

68
Capítulo 5
Atividades
1. Quais são as atividades que compõem a espinha dorsal de de-
senvolvimento de um software? Descreva cada uma dessas ativi-
dades de forma sucinta, com suas próprias palavras.
2. Todas as atividades envolvidas no processo de desenvolvimen-
to de software produzem artefatos. Um artefato é um produto de
trabalho, que pode ser um modelo, documento ou código fonte
produzido por uma atividade, entre outros. Pesquise em livros,
internet ou outras fontes sobre os artefatos produzidos em cada
uma das atividades de desenvolvimento. Discuta os artefatos pes-
quisados com seus colegas em um fórum de discussão.


69
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
70
Capítulo 5

71
GERENCIAMENTO DE PROJETO
DE SOFTWARE
Prezado aluno,
No capítulo 1 foram apresentadas três atividades básicas envolvidas

em um processo de software em uma abordagem de engenharia de
software, que são as atividades de desenvolvimento, as atividades de
gerência de projeto e as atividades de garantia da qualidade. Neste
capítulo apresentarei as atividades de gerência de projeto, que são
aquelas relacionadas ao planejamento e acompanhamento geren-
cial do projeto, tais como realização de estimativas, elaboração de
cronogramas, análise dos riscos do projeto etc.
Bom estudo!
6.1. Introdução
A gerência de projetos de software é um conjunto de atividades que

tem como objetivo responder a perguntas tais como quanto o proje-
to custará e qual será a sua duração. Para responder a essas pergun-
tas é preciso definir o escopo do projeto, realizar estimativas, levantar
riscos, alocar recursos e definir um cronograma de execuções. Todas
essas informações são registradas em um documento chamado “Plano
de Projeto”, que deve ser sistematicamente revisado, a fim de permitir
o acompanhamento do projeto e a tomada de ações corretivas, sempre
que necessário.
6.2. Escopo de Software
Basicamente o escopo de software é composto pela especificação de

um conjunto de funcionalidades (requisitos funcionais) associada a
outras características desejadas (requisitos não funcionais), tais como
desempenho, confiabilidade etc. O escopo de software pode ser do-
cumentado de várias formas, sempre contendo uma breve descrição
das funções do sistema, requisitos não funcionais importantes e o
contexto e objetivos do sistema. Diagramas de casos de uso são um
72
Capítulo 6
importante instrumento para mostrar as funcionalidades de um siste-

ma. De forma geral, um diagrama de casos de uso apresenta o sistema
segundo uma perspectiva externa, na qual atores (usuários ou outros
sistema) aparecem interagindo com as funções do sistema (casos de
uso) (FALBO, 2005). A Figura 6.1 apresenta um exemplo de diagrama
de casos de uso preliminar de um sistema.
Figura 6-1: Exemplo de um Diagrama de Casos de Uso

Fonte: Falbo, 2005
6.3. Estimativa de Custo de Software
Estimativa de custo de software é uma atividade que serve para deter-

minar quantos recursos serão necessários para completar o projeto. Ge-
ralmente essa estimativa é feita pensando no número de programadores
necessário por mês (PM) para um determinado projeto. Existem duas
diferentes abordagens que serão discutidas neste capítulo. A mais antiga
delas, chamada estimativa LOC, é baseada no número de linhas de códi-
go necessárias para desenvolver um projeto. A outra abordagem é base-
ada na contagem de pontos de função na descrição do projeto. Ambas as
abordagens serão ilustradas com exemplos para facilitar a compreensão
(Gustafson, 2003).
6.3.1. Estimativa LOC (Estimativa de Linha de Código)
A estimativa LOC contempla três passos: (1) Estimar o número de li-

nhas de código no projeto final; (2) Estimativa de Custo baseado por
LOC baseado em dados históricos; (3) Estimativa de custo por LOC
baseado no tipo de projeto.

73
Gerenciamento de Projeto de Software
1. Estimativa de Linha de Código (LOC): a estimativa de linha de código

é uma estimativa de tamanho do software. Ela é feita baseada em experi-
ência, tamanho de projetos anteriores, tamanho da solução concorrente
ou dividindo-se o projeto em partes menores e, então, estimando o ta-
manho de cada uma dessas partes. Uma abordagem padrão é, para cada
parte, estimar o tamanho máximo de linhas possível (Tamanho Max), o
melhor tamanho (Ideal) e o tamanho mínimo possível (Tamanho Min). A
estimativa do número de linhas do projeto final é dada pela soma das es-
timativas de cada parte, em que a estimativa de uma parte é dada por 1/6
da soma da estimativa máxima, 4 vezes a estimativa ideal e a estimativa
mínima de cada parte do projeto, como mostra o exemplo a seguir:
Exemplo: A equipe WRT identificou sete partes no seu projeto (P1 a

P7). Elas estão apresentadas na Tabela 6.1, com suas estimativas de ta-
manho máximo, ideal e mínimo para cada uma de suas partes:
Parte Tamanho Max Ideal Tamanho Min

1 20 30 50
2 10 15 25
3 25 30 45
4 30 35 40
5 15 20 25
6 10 12 14
7 20 22 25
Tabela 6.1 – Estimativa de Tamanho das Partes (em LOC)
As estimativas para cada parte são calculadas a seguir:
P1 = (20 + 4*30 + 50)/6 = 190/6 = 31,6
P2 = (10 + 4*15 + 25)/6 = 95/6 = 15,8
P3 = (25 + 4*30 + 45)/6 = 190/6 = 31,6
P4 = (30 + 4*35 + 40)/6 = 220/6 = 36,7
P5 = (15 + 4*20 + 25)/6 = 120/6 = 20
P6 = (10 + 4*12 + 14)/6 = 72/6 = 12
P7 = (20 + 4*22 + 25)/6 = 133/6 = 22,17
A estimativa para todo o projeto é dada então por:
Total = 31,6 + 15,8 + 31,6 + 36,7 + 20 + 12 + 22,17 = 170,07 LOC.
74
Capítulo 6
Embora a estimativa baseada na contagem do número de linhas de có-

digo (Lines Of Code - LOC) seja uma das mais simples, existem alguns
estudos que demonstram a alta correlação entre essa métrica e o tem-
po necessário para se desenvolver um sistema. Entretanto, o uso dessa
métrica apresenta várias desvantagens. Primeiro, verifica-se que ela é
fortemente ligada à tecnologia empregada, sobretudo a linguagem de
programação e ao estilo do código escrito. Segundo, pode ser difícil es-
timar essa grandeza no início do desenvolvimento, sobretudo se não
houver dados históricos relacionados com a linguagem de programação
utilizada no projeto. Por fim, essa é uma métrica que pouco significativa
para o cliente.
2. Estimativa de Custo baseado em LOC: a abordagem básica de LOC

é a fórmula que combina dados históricos do projeto. A fórmula básica
tem três parâmetros:
Custo = α * KLOCβ + γ, em que
α (Alfa) = custo marginal por KLOC (1000 linhas de código), que repre-
senta o custo adicional para 1000 linhas de código;
β (Beta) = expoente que reflete a não-linearidade do relacionamento.

Valores de beta maiores do que 1 significam que o custo por KLOC au-
menta à medida que o tamanho do projeto aumenta. Isso significa uma
economia de escala ao inverso. Se o valor de beta é menor do que 1, isso
reflete uma economia de escala. Foram encontrados em estudos tanto
valores maiores quanto valores menores do que 1 para beta.
γ (Gama) = reflete o custo fixo de qualquer projeto. Estudos encontra-

ram valores positivos e o valor zero para gama.
O exemplo a seguir tem como objetivo calcular o esforço necessário

para um projeto novo de 50 KLOC.
Exemplo: A companhia LMN armazenou os seguintes dados de projeto

s anteriores. Estime os parâmetros para a fórmula de estimativa de cus-
to e quanto esforço será necessário para um novo projeto de 30 KLOC.
(Veja Tabela 6.2).

75
Projeto Tamanho (KLOC) Esforço (PM)

1 50 120
2 80 192
3 40 96
4 10 24
5 20 48
Tabela 6.2 – Dados Históricos
Analisando ou traçando o gráfico desses dados, será mostrado um rela-

cionamento linear entre tamanho e esforço. O coeficiente de inclinação
da linha é 2,4 (basta dividir o valor do esforço pelo tamanho nos dados
da tabela para chegar a este coeficiente). Esse valor será alfa (α) na fór-
mula de estimativa de custo baseada em LOC. Já que a linha é reta, o
valor de beta (β) será 1. O valor de gama deve ser zero. Dessa forma,
para um projeto de tamanho 30 KLOC o esforço será de 72 PM.
3. Constructive Cost Model (COCOMO): COCOMO é uma fórmula

de estimativa de custo criada por Barry Boehm na década de 70. Bo-
ehm usou milhares de instruções de código prontas – thousands deli-
vered source instructions (KDSI) – como unidade de tamanho (KDSI
é equivalente a KLOC). Sua unidade de esforço é dada em progra-
mador/mês (PM). Boehm dividiu dados históricos do projeto em três
tipos de projeto:
1. Programas aplicativos (Ex: processadores de texto);
2. Programas utilitários (Ex: compiladores);
3. Programas de sistemas (embarcados).
Ele identificou os valores de parâmetros para determinação do esforço:
1. Programas aplicativos: PM = 2,4 * (KDSI)1,05
2. Programas utilitários: PM = 3,0 * (KDSI)1,12
3. Programas de sistemas: PM = 3,6 * (KDSI)1,20
Exemplo: Calcule o esforço do programador para projetos de 5 a 50

KDSI. Veja Tabela 6.3.
76
Capítulo 6
Tamanho Apl Útil Sist

5K 13,0 18,2 24,8
10K 26,9 39,5 57,1
15K 41,2 62,2 92,8
20K 55,8 86,0 131,1
25K 70,5 110,4 171,3
30K 85,3 135,3 213,2
35K 100,3 160,8 256,6
40K 115,4 186,8 301,1
45K 130,6 213,2 346,9
50K 145,9 239,9 393,6
Tabela 6.3 – Esforço COCOMO
Boehm também determinou que em seus dados de projeto existisse

um tempo de desenvolvimento padrão baseado no tipo e tamanho do
projeto. As fórmulas a seguir determinam o tempo de desenvolvimento
(TDEV) em programador/mês (PM):
1. Programas aplicativos: TDEV = 2,5 * (PM)0,38
2. Programas utilitários: TDEV = 2,5 * (PM)0,35
3. Programas de sistemas: TDEV = 2,5 * (PM)0,32
Exemplo: Calcule o padrão TDEV usando as fórmulas COCOMO para

projetos de 5 a 50 KDSI (Veja Tabela 6.4).
Tamanho Apl Útil Sist

5K 6,63 6,90 6,99
10K 8,74 9,06 9,12
15K 10,27 10,62 10,66
20K 11,52 11,88 11,90
25K 12,60 12,97 12,96
30K 13,55 13,93 13,91
35K 14,40 14,80 14,75
40K 15,19 15,59 15,53
45K 15,92 16,33 16,25
50K 16,61 17,02 16,92
Tabela 6.4 – Tempo de Desenvolvimento COCOMO

77
6.3.2. Análise de Ponto de Função
A contagem de pontos de função é o exemplo mais conhecido de métrica

que tem como objetivo possibilitar a realização de estimativas de tama-
nho logo no início do processo de software e sem os problemas de depen-
dência em relação à tecnologia. A contagem de pontos de função busca
medir as funcionalidades do sistema requisitadas pelo usuário, indepen-
dentemente da tecnologia usada na implementação. A análise de pontos
de função é um método-padrão para a medição do desenvolvimento, ma-
nutenção ou tamanho de uma aplicação de software, visando estabelecer
uma medida de tamanho de software em Pontos de Função (PF), com
base na quantificação da funcionalidade solicitada ou fornecida, sob o
ponto de vista do usuário. Os objetivos da análise de pontos de função são
medir as funcionalidades do sistema (solicitadas e recebidas pelos usuá-
rios) e medir projetos de desenvolvimento e manutenção de software, sem
a preocupação com a tecnologia que será usada na implementação. Ou
seja, pontos de função são usados para identificar e quantificar as funcio-
nalidades requeridas para um projeto. A idéia central é contar elementos
no comportamento que irão requerer processamento. Gustafson (2003)
nos apresenta os itens clássicos de contagem:
Requisitos: são pares de solicitação-resposta que não mudam os dados

internos. Por exemplo, a solicitação do endereço de um funcionário espe-
cífico é um requisito. Toda a sequência de perguntar e preencher o nome
e o endereço de um funcionário será contada como um único requisito;
Entradas: são itens da aplicação de dados suprida pelo programa. A

entrada lógica geralmente é considerada um item e os campos individu-
ais não são contados separadamente. Por exemplo, a entrada de dados
pessoais para um funcionário pode ser considerada uma entrada;
Saídas: são os dados da aplicação exibidos. Pode ser um relatório, uma

tela ou uma mensagem de erro. Os campos individuais também não
são considerados saídas separadas. Se um relatório tem múltiplas linhas,
por exemplo, uma linha para cada funcionário de um departamento, es-
sas linhas serão consideradas como uma única saída. Entretanto, alguns
contam linhas sumárias como saídas separadas;
Arquivos Internos: são arquivos lógicos que o usuário entende que de-
vem ser mantidos pelo sistema. Um arquivo que contenha 1.000 entradas
de dados pessoais provavelmente será contado como um único arquivo.
No entanto, se um arquivo contém dados pessoais, dados sumários de
um departamento, e outros dados do departamento, para o propósito de
pontos de função, provavelmente esses arquivos seriam contados como
três arquivos separados;
78
Capítulo 6
Interfaces Externas: são dados que são compartilhados com outros

programas. Um arquivo pessoal, por exemplo, pode ser usado pelo
departamento de recursos humanos para promoção ou folha de paga-
mento. Assim, esse arquivo pode ser considerado uma interface com
ambos os sistemas.
Falbo (2005) nos apresenta os sete passos compreendidos no processo

de contagem de pontos de função, ilustrados na figura 6.1 e descritos de
forma sucinta logo a seguir:
Figura 6-2: Passos do Processo de contagem dos Pontos de Função

Fonte: Falbo, 2005
Passo 1: Determinar o tipo de contagem dos pontos de função: este é

o primeiro passo no processo de contagem dos pontos de função, sendo
que existem três tipos de contagem: contagem de PF de projeto de de-
senvolvimento, de aplicações instaladas e de projetos de manutenção.

79
Passo 2: Identificar o escopo de contagem e a fronteira da aplicação:

neste passo, são definidas as funcionalidades que serão incluídas em
uma contagem de Pontos de função específica. Também é definida a
fronteira da aplicação, estabelecendo um limite lógico entre a aplicação
que está sendo medida, o usuário e outras aplicações. O escopo de con-
tagem define a parte do sistema (funcionalidades) a ser contada.
Passo 3: Determinar a contagem de pontos de função não ajustados:

os pontos de função não ajustados refletem as funcionalidades forneci-
das pelo sistema para o usuário. Essa contagem leva em conta dois tipos
de função: funções de dados e funções transacionais, e também se a
complexidade é simples, média ou complexa.
Passo 4: Contagem das funções de dados: as funções de dados repre-

sentam as funcionalidades relativas aos requisitos de dados internos e
externos à aplicação, que são os arquivos lógicos internos e os arquivos
de interface externa. Ambos são grupos de dados logicamente relacio-
nados ou informações de controle que foram identificados pelo usuário.
A diferença está no fato de um Arquivo Lógico Interno (ALI) ser man-
tido dentro da fronteira da aplicação, isto é, armazenar os dados manti-
dos através de um ou mais processos elementares da aplicação, enquan-
to um Arquivo de Interface Externa (AIE) é apenas referenciado pela
aplicação, ou seja, ele é mantido dentro da fronteira de outra aplicação.
Assim, o objetivo de um AIE é armazenar os dados referenciados por
um ou mais processos elementares da aplicação sendo contada, mas que
são mantidos por outras aplicações.
Passo 5: Contagem das funções transacionais: as funções transacio-

nais representam as funcionalidades de processamento de dados do sis-
tema fornecidas para o usuário, tais como as entradas externas, as saídas
externas e as consultas externas. As Entradas Externas (EE) são proces-
sos elementares que processam dados (ou informações de controle) que
entram pela fronteira da aplicação. O objetivo principal de uma EE é
manter um ou mais ALI ou alterar o comportamento do sistema. As Sa-
ídas Externas (SE) são processos elementares que enviam dados (ou in-
formações de controle) para fora da fronteira da aplicação. Seu objetivo
é mostrar informações recuperadas através de um processamento lógico
(isto é, que envolva cálculos ou criação de dados derivados) e não ape-
nas uma simples recuperação de dados. Uma SE pode, também, manter
um ALI ou alterar o comportamento do sistema. Já uma Consulta Ex-
terna (CE) , assim como uma SE, é um processo elementar que envia
dados (ou informações de controle) para fora da fronteira da aplicação,
mas sem a realização de cálculos nem a criação de dados derivados. Seu
objetivo é apresentar informação para o usuário, por meio apenas de
uma recuperação das informações. Nenhum ALI é mantido durante sua
realização, nem o comportamento do sistema é alterado.
80
Capítulo 6
Passo 6: Determinar o valor do fator de ajuste: o fator de ajuste é ba-

seado em quatorze características gerais de sistemas, que avaliam a fun-
cionalidade geral da aplicação que está sendo contada e seus níveis de
influência. O nível de influência de uma característica é determinado
com base em uma escala de 0 a 5, em que 0 significa nenhuma influência
e 5 significa forte influência. O objetivo do fator de ajuste é ajustar os
pontos de função não ajustados em ± 35%.
Passo 7: Calcular os pontos de função ajustados: neste último passo,

os pontos de função ajustados são calculados, considerando-se o tipo de
contagem definido no primeiro passo.
6.4. Elaboração de Cronograma
É possível estimar o tempo cronológico (duração) de cada atividade

e, consequentemente, do projeto como um todo, assim que tiverem
sido feitas as estimativas de esforço, realizando, em paralelo, a alo-
cação de recursos.
Estimativas de esforço buscam medir o esforço necessário para com-

pletar o projeto ou cada uma de suas atividades. Estimativas de esforço
podem ser obtidas diretamente pelo julgamento de especialistas, tipica-
mente usando técnicas de decomposição, ou podem ser computadas a
partir de dados de tamanho ou de dados históricos.
Já a Alocação de recursos diz respeito a estimar os recursos necessá-

rios para realizar o esforço de desenvolvimento. Quando falamos em
recursos, estamos englobando pessoas, hardware e software. No caso de
software, devemos pensar em ferramentas de software, tais como ferra-
mentas CASE ou software de infra-estrutura (por exemplo, um sistema
operacional), bem como componentes de software a serem reutilizados
no desenvolvimento, tais como bibliotecas de interface ou uma camada
de persistência de dados.
Se a estimativa de esforço tiver sido realizada para o projeto como um

todo, então ela deverá ser distribuída pelas atividades do projeto. Dados
históricos de projetos já concluídos na organização são uma boa base
para se fazer essa distribuição.
No entanto, muitas vezes uma organização não tem ainda esses dados
históricos disponíveis. Embora as características do projeto sejam deter-
minantes para a distribuição do esforço, uma diretriz inicial útil consiste
em considerar a distribuição mostrada na Tabela 6.5 (Falbo, 2005).

81
Tabela 6.5 - Distribuição de Esforço pelas Principais Atividades do Processo

de Software.
Como dissemos, feita a distribuição do esforço por atividade e, parale-

lamente, realizando a alocação de recursos, pode-se criar uma rede de
tarefas com o esforço associado a cada uma das atividades. A partir des-
sa rede, pode-se estabelecer qual é o caminho crítico do projeto, isto é,
qual o conjunto de atividades que determina a duração do projeto. Um
atraso em uma dessas atividades provocará atraso no projeto como um
todo. Finalmente, a partir da rede de tarefas, deve-se elaborar um Gráfi-
co de Tempo (também chamado gráfico de Gantt), estabelecendo o cro-
nograma do projeto. Uma rede de tarefas, também chamada de rede de
atividades, é uma representação gráfica do fluxo de tarefas de um pro-
jeto. Algumas vezes a rede de tarefas é usada como um mecanismo por
meio do qual a sequência e as dependências de tarefas são alimentadas
em uma ferramenta automática de cronogramação de projeto. Gráficos
de Tempo podem ser elaborados para o projeto como um todo (crono-
grama do projeto), para um conjunto de atividades, para um módulo
específico ou mesmo para um membro da equipe do projeto.
As Figuras 6.3, 6.4 e 6.5 apresentam, respectivamente, uma rede de tarefas
para desenvolvimento conceitual, um exemplo de gráfico de tempo (que
mostra uma parte de um cronograma de projeto que enfatiza a determina-
ção do escopo conceitual para um produto de software de processamento
de texto) e um exemplo de tabela de projeto, que é uma listagem tabular de
todas as tarefas do projeto, de suas datas iniciais e finais (planejadas e reais) e
várias outras informações relacionadas (Pressman, 2006).
Figura 6-3: Uma rede de tarefas para desenvolvimento conceitual

Fonte: Pressman, 2006
82
Capítulo 6
Figura 6-4: Um exemplo de gráfico de tempo

Figura 6-5: Um exemplo de Tabela de Projeto

A seguir, apresentamos dois modelos de planos de projeto de software:
Modelo 1
1. Introdução
1. Escopo e propósito do documento
2. Objetivos do Projeto
1. Objetivos
2. Funções Principais
3. Questões de desempenho
4. Restrições técnicas e administrativas

83
2. Especificação dos Requisitos
1. Especificação dos Casos de Uso

2. Diagramas de Atividades e Tarefas
3. Diagramas de Classes e Objetos
3. Recursos humanos
1. Relação do pessoal envolvido (formação técnica, disponibilida-

de, experiência)
2. Estrutura da equipe
3. Distribuição das tarefas (pode ser colocado junto com o
cronograma)
4. Estimativas de Projeto
1. Dados históricos
2. Técnicas de estimativas
3. Estimativas
5. Riscos do projeto
1. Identificação dos Riscos

2. Análise dos riscos
1. Estimativas e probabilidade da ocorrência de cada risco
2. Impacto no projeto
3. Prioridade (probabilidade x impacto)
3. Gerenciamento dos riscos
1. Ações a serem tomadas para reduzir a ocorrência dos riscos
2. Ações para reduzir o impacto, casos os riscos venham a
ocorrer
6. Cronograma
1. Rede de tarefas
2. Gráfico de linha-de-tempo (timeline)
3. Tabela de recursos
84
Capítulo 6
7. Recursos materiais
1. Ferramentas de software para desenvolvimento

2. Ferramentas de software para operação
3. Hardware para desenvolvimento
4. Hardware para operação
5. Outros materiais (energia, material de escritório, etc.)
8. Mecanismos de rastreamento e controle
9. Orçamento
1. Gastos com recursos materiais

2. Gastos com recursos humanos
3. Outros gastos
Modelo 2
Modelo de Documento Plano de Projeto
Título: Plano de Projeto
Dados Gerais:
Projeto: <<Nome do Projeto>>
Versão: <<Número da Versão do Plano de Projeto>>
Responsáveis: <<Nome dos Responsáveis>>
Seções do Documento e Instruções para seu preenchimento:

1. Introdução
Texto livre introdutório descrevendo o documento.
2. Escopo do Projeto
Texto introdutório sobre o problema a ser tratado, seguido de uma iden-
tificação de subsistemas e módulos/macro-funções que o sistema deverá
tratar, apresentada na forma de diagramas de casos de uso e descrições
sucintas dos mesmos.

85
3. Processo de Software do Projeto

Indicar o processo padrão / especializado usado como base (quando
aplicável) e o modelo de ciclo de vida adotado, com uma breve justifica-
tiva para sua escolha. A seguir, apresentar o processo de desenvolvimen-
to no seguinte formato:
Processo de Desenvolvimento
<<Nome da Atividade>>
Preatividades: <<Nomes das preaatividades>>
Subatividades: <<Nomes das subatividades>>
Artefatos Insumo: <<Artefatos requeridos pela atividade>>
Artefatos Produzidos: <<Artefatos produzidos pela atividade>>
Recursos Necessários:
Recursos Humanos: <<Papéis necessários para realizar a
atividade>>
Ferramentas de Software: <<Tipos de Ferramentas
necessárias>>
Hardware: <<Equipamentos necessários para realizar a
atividade>>
Procedimentos: <<Procedimentos a serem adotados>>
Tecer comentários sobre os demais processos, sobretudo quando
houver mudanças em relação ao processo padrão.
4. Equipe do Projeto
Apresentar a equipe do projeto, identificando as pessoas e os papéis que
as mesmas vão desempenhar no projeto.
5. Estimativas
5.1 – Estimativa de Tamanho
Apresentar a estimativa e a base de cálculo para se chegar a ela, infor-
mando o procedimento utilizado em sua elaboração.
5.2 – Estimativa de Esforço
Apresentar a estimativa e a base de cálculo para se chegar a ela, infor-
mando o procedimento utilizado em sua elaboração.
86
Capítulo 6
5.3 – Alocação de Recursos

Apresentar a alocação de recursos para as atividades do processo.
5.4 – Estimativa de Duração
Apresentar uma rede de tarefas, apontando o caminho crítico do proje-
to e um gráfico de tempo para o projeto como um todo (cronograma).
5.5 – Estimativa de Custo
Apresentar a estimativa de custo e a base de cálculo para se chegar
a ela, informando o procedimento utilizado em sua elaboração,
quando couber.
6. Plano de Riscos
Anexar o plano de riscos, desenvolvido segundo o modelo de pla-
no de riscos.
Além da bibliografia básica usada neste capítulo, e referenciada

em seu final, você pode consultar as seguintes fontes para mais
informações sobre gerência de projetos de software.
- PRESSMAN, R. S. Engenharia de Software. 5. ed.,Rio de Janei-
ro: McGraw Hill, 2002.
O capítulo 3 dá uma visão geral da gerência de projetos de sof-
tware, com discussões sobre pessoal e formação de equipes (se-
ção 3.2), definição do escopo do software (seção 3.3), estrutura
de divisão do trabalho (seção 3.4). O capítulo 4 aborda o tema de
medição e métricas nas seções 4.1 e 4.3. O capítulo 5 trata com
mais detalhes do planejamento do projeto, com destaque para a
determinação do escopo (seção 5.3), estimativas (seções 5.1, 5.5,
5.6 e 5.7) e recursos (seção 5.4). O capítulo 6 trata da gerência de
riscos. Finalmente, o capítulo 7 aborda a elaboração e o acompa-
nhamento do cronograma.
- SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo:
Addison-Wesley, 2003.
O capítulo 4 proporciona uma visão geral da gerência de projetos de
software, abordando atividades da gerência (seção 4.1), planejamento
do projeto (seção 4.2), elaboração do cronograma (seção 4.3) e gerên-
cia de riscos (seção 4.4). Além disso, há dois capítulos (22 e 23) dedica-
dos, respectivamente, à gerência de pessoal e às estimativas.

87
- PFLEEGER, S.L. Engenharia de Software: Teoria e Prática. 2.

ed. São Paulo: Prentice Hall, 2004.
O capítulo 3 é dedicado ao planejamento e à gerência de proje-
tos de software. A seção 3.1 trata do escopo, estrutura de divisão
do trabalho e elaboração do cronograma. Na seção 3.2, há uma
discussão acerca do pessoal necessário para o projeto e formação
de equipes. As seções 3.3, 3.4 e 3.5 discutem, respectivamente, os
temas estimativas, gerência de riscos e plano de projeto.
- VIEIRA, M.F. Gerenciamento de Projetos de Tecnologia da
Informação. Rio de Janeiro: Editora Elsevier/ Campus, 2003.
- MARTINS,J.C.C. Gerenciando Projetos de Desenvolvimento
de Software com PMI, RUP e UML, 2. ed. revisada, Rio de Janei-
ro : Brasport, 2005.
- VAZQUEZ,C.E., SIMÕES,G.S. & ALBERT,R.M. Análise de
Pontos de Função: Medição, Estimativas e Gerenciamento de
Projetos de Software, 3. ed., São Paulo : Editora Érica, 2005.
Este livro traz uma apresentação bastante detalhada do método
da Análise de Pontos de Função, explorando a importância da
medição (capítulo 1), uma visão geral do processo de contagem
(capítulo 3), detalhamento desse processo (capítulos 4, 5, 6 e 7) e
estimativas (capítulo 9).
Atividades
1. Tanto a estimativa de linha de código (LOC), quanto a análise
de pontos de função (APF), são estimativas do tamanho do sof-
tware. A análise de pontos de função também tem como objetivo
medir o desenvolvimento e a manutenção de uma aplicação de
software. Descreva com suas palavras cada uma dessas estimati-
vas, destacando as características principais de cada uma delas, e
as principais diferenças.
2. Em relação à medição do tamanho de uma aplicação de sof-
tware, na sua opinião, qual das estimativas citadas na Atividade
1 é a melhor?
3. Compare os dois modelos de plano de projeto apresentados na
seção 6.4 e registre suas observações. Qual dos modelos você con-
sidera ser o melhor? Descreva os motivos da escolha.
88
Capítulo 6
[1] FALBO, R.A., Notas de Aula: Engenharia de Software.

Disponível em http://www.inf.ufes.br/~falbo, 2005.
[2] GUSTAFSON, DAVID A. Teoria a problemas de engenha-
ria de software. Porto alegre: Bookman, 2003. (Coleção Schaum).
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________

89
MÉTRICAS DE SOFTWARE
Prezado aluno,
Neste capítulo discutiremos métricas de software no contexto de

produto, processo e projeto.
Bom estudo!
7.1. Métricas de Software
Segundo a Wikipédia, Medição é a atividade de comparar uma quanti-

dade com um padrão pré-definido. Através da medição o homem pode
expressar numericamente qualidades de um objeto ou fenômeno. Sem
a medição, o homem fica refém de conceitos como “grande/pequeno”,
“forte/fraco”, “largo/fino”, etc; porém, com a medição, o homem pode
raciocinar com mais precisão acerca das referidas qualidades.
O ato de medir envolve essencialmente a existência de unidades de me-

dida, que são os comparativos usados na medição. Envolve também a
existência de instrumentos de medição que, graduados de acordo com
a unidade de medida em questão, fornecem com variados graus de pre-
cisão a medida desejada.
Apesar dos termos medida, medição e métrica serem frequentemente

usados num mesmo contexto, eles contêm diferenças sutis que são im-
portantes de serem observadas. A palavra medida pode ser usada tanto
como substantivo quanto como verbo, tornando a definição do termo
confusa. No contexto da engenharia de software, uma medida nos dá
uma indicação quantitativa de da extensão, quantidade, dimensão, ca-
pacidade ou tamanho de algum atributo de um produto ou processo.
Medição é o ato de determinar uma medida. Já métrica é definida pela
IEE standard Glossary como “uma medida quantitativa do grau em que
um sistema, componente ou processo possui um determinado atributo”.
Já um indicador é uma métrica ou combinação de métricas que forne-
ce profundidade na visão do processo de software, projeto de software
ou produto em si (Pressman, 2006). Para saber mais sobre a diferença
entre medida, medição e indicadores, visite o link: http://www.sinfic.pt/
SinficNewsletter/sinfic/Newsletter50/Dossier2.html
90
Capítulo 7
O texto a seguir vai ajudá-lo a entender mais sobre medida, medi-

ção e métrica.
“Quando se trata de avaliação quantitativa, quatro conceitos, mui-

tas vezes usados equivocadamente com o mesmo sentido, são im-
portantes: medida, medição, métrica e indicador.
Uma medida fornece uma indicação quantitativa da extensão,
quantidade, dimensão, capacidade ou tamanho de um atributo de
um produto ou de um processo. Quando os dados de um único
ponto são coletados, uma medida é estabelecida (p.ex., quantida-
de de erros descobertos em uma revisão).
Medição é o ato de medir, isto é, de determinar uma medida. Já
uma métrica procura relacionar medidas individuais com o obje-
tivo de se ter uma idéia da eficácia do processo, do projeto ou do
produto sendo medido. Por fim, desenvolvem-se métricas para se
obter indicadores, isto é, para se ter uma compreensão do proces-
so, produto ou projeto sendo medido.
Seja o seguinte exemplo: deseja-se saber se uma pessoa está com
seu peso ideal ou não. Para tal, duas medidas são importantes: al-
tura (H) e peso (P). Ao medir essas dimensões, está-se efetuando
uma medição. A métrica “índice de massa corporal (IMC)” é cal-
culada segundo a seguinte fórmula: IMC = P / H2. A partir dessa
métrica, a Organização Mundial de Saúde estabeleceu indicado-
res que apontam se um adulto está acima do peso, se está obeso ou
abaixo do peso ideal considerado saudável, conforme a seguir:
Se IMC < 18,5, então o indivíduo está abaixo do peso ideal consi-
derado saudável;
Se 18,5 <= IMC < 25, então o indivíduo está com o peso normal;
Se 25 <= IMC <= 30, então o indivíduo está acima do peso;
Se IMC > 30, então o indivíduo está obeso.
Realizando medições, uma pessoa pode obter suas medidas para
altura e peso. A partir delas, pode calcular a métrica IMC e ter um
indicador se está abaixo do peso, no peso ideal, acima do peso ou
obeso. Conhecendo esse indicador, a pessoa pode ajustar seu pro-
cesso de alimentação, obtendo melhorias reais para sua saúde.”
Fonte: Capítulo 4 – Gerência da Qualidade – Medição e Mé-
tricas (Falbo, 2005).

91
Métricas de Software
O texto a seguir vai ajudá-lo a entender mais sobre métricas de software.
“A ciência é baseada em medidas. Melhorar o processo requer a

compreensão dos relacionamentos e isso requer medidas.
Medida de software é o mapeamento de símbolos para objetos. O
propósito é qualificar alguns atributos dos objetos, por exemplo,
a medida do tamanho do projeto de software. Adicionalmente, o
objetivo pode ser predizer alguns atributos que não são aparente-
mente mensuráveis, tais como o esforço necessário para desenvol-
ver um projeto de software.
Nem todos os mapeamentos de símbolos para objetos são aplicá-
veis. Uma questão importante é a validação das métricas; entre-
tanto, a validação está relacionada ao uso da métrica. Um exemplo
é a altura de uma pessoa. A altura é importante para predizer a
habilidade da pessoa passar por uma porta sem bater a cabeça. Ter
uma correlação entre a medida e um atributo não é suficiente para
validar uma medida. Por exemplo, o tamanho do pé de uma pes-
soa é altamente relacionado com a altura dela; entretanto, normal-
mente não é aceito como medida para a altura de uma pessoa.
Os seguintes critérios são válidos para métricas:
1. Uma métrica deve permitir a distinção entre diferentes entidades.
2. Uma métrica deve obedecer a uma condição de representação.
3. Cada unidade do atributo deve contribuir com a mesma quan-
tidade para a métrica.
4. Entidades diferentes podem ter o mesmo valor do atributo.
Muitas vezes, o interesse do atributo não é diretamente mensurá-
vel; nesse caso, uma medida indireta é usada. Uma medida indi-
reta envolve a medida e a forma de predição. Por exemplo, densi-
dade não é uma medida direta. Ela é calculada a partir da massa
e do volume, que são medidas diretas. Na ciência da computação,
muitos “atributos” (mantenibilidade, facilidade de leitura, texta-
bilidade, qualidade, complexidade, etc.) não podem ser medidos
diretamente, e medidas indiretas para esses atributos é o objetivo
de muitas métricas de programas.
Os seguintes critérios são válidos para métricas indiretas:
1. O modelo deve ser explicitamente definido.
2. O modelo deve ser dimensionalmente consistente.
3. Não deve haver descontinuidade inesperada.
4. Unidades e tipos de escala devem ser corretos.”
Fonte: Gustafson, 2003.
92
Capítulo 7
Mas para que serve a medição no contexto da engenharia de software?
A medição pode ser aplicada em três contextos diferentes:
1. Pode ser aplicada ao processo de software com o objetivo de

melhorá-lo de forma contínua;
2. Pode ser usada ao longo de um projeto de software para

auxiliar em:
a. Estimativa
b. Controle da Qualidade
c. Avaliação de Produtividade
d. Controle do Projeto
3. Pode ser usada para ajudar a avaliar a qualidade dos produtos

do trabalho e auxiliar na tomada de decisões táticas à medida
que o projeto evolui.
Esses três contextos serão discutidos a seguir:
7.2. Métricas de Processo
O objetivo das métricas de processo é fornecer um conjunto do que

chamamos de “indicadores de processo”, que leva a aperfeiçoamentos do
processo de software a longo prazo. Métricas de processo são coletadas
no decorrer de todos os projetos e durante longos períodos de tempo.
Segundo Pressman (2006), as métricas de software nos permitem:
4. Avaliar o estado de um projeto em andamento;
5. Acompanhar riscos potenciais;
6. Descobrir áreas-problema antes que elas se tornem áreas “críticas”;
7. Ajustar o fluxo de trabalho ou tarefas;
8. Avaliar a capacidade da equipe de projeto em controlar a qua-

lidade dos produtos de software.

93
As métricas de processo (como também as métricas de projeto) são me-

didas quantitativas que nos permitem ter ideia da eficácia do processo de
software. São coletados dados básicos de qualidade e produtividade, que
são analisados, comparados com métricas anteriores e avaliados para
determinar se ocorreram melhorias de qualidade e produtividade. Ou
seja, o objetivo das métricas de processo é exatamente melhorar a quali-
dade do processo de desenvolvimento de software de forma contínua.
Como exemplo de métricas de processo, apresentaremos a produtividade

(Gustafson, 2003). Ela é calculada pela divisão do total de linhas do có-
digo-fonte entregues pelos programadores/dia atribuídos ao projeto. As
unidades de medida normalmente são dadas em LOC/programador/dia.
Exemplo: Um projeto totalizou 100 KLOC. Trabalharam no projeto 20

programadores por ano. Esse ano inclui o esforço total para requisitos,
projeto, implementação, testes e fases de entrega. Assuma que existam
aproximadamente 240 dias de trabalho no ano (20 dias ao mês por 12
meses, sem férias). A produtividade é dada então por:
100.000 LOC / 20 programadores * 240 dias = 100.000 LOC / 4800 dias

= 20,8 LOC/programador/dia.
7.3. Métricas de Projeto
Podemos dizer que as métricas de processo são usadas com finalida-

des estratégias, visando melhorar o processo de software de forma
contínua. Já as métricas de projeto são táticas. Elas podem ser usa-
das ao longo de um projeto para auxiliar na estimativa, no controle
de qualidade, na avaliação de produtividade e no controle do projeto.
Tal como as métricas de processo, as métricas de projeto são medidas
quantitativas que nos permitem ter a idéia da eficácia dos projetos que
são conduzidos usando o processo de software como arcabouço. Elas
são usadas pelo gerente de projeto para adaptar o fluxo de trabalho e
as atividades técnicas do projeto.
O objetivo das métricas de projeto é duplo. Elas são usadas para:
1. Minimizar o cronograma de desenvolvimento (ou pelo menos

permitir que ele não “estoure”), fazendo os ajustes necessários
para evitar atrasos, problemas e riscos em potencial;
2. Avaliar a qualidade do produto de software durante sua evo-

lução e, quando necessário, modificar a abordagem técnica para
aperfeiçoar a qualidade.
94
Capítulo 7
Geralmente, a primeira aplicação das métricas de projeto ocorre du-

rante as estimativas (veja seção 6.3). Métricas coletadas de projetos an-
teriores são usadas como base, a partir da qual estimativas de esforço e
tempo são feitas para o projeto atual. Conforme o projeto evolui, medi-
das de esforço e tempo despendidos são comparadas com as estimativas
originais e com o cronograma do projeto. Esses dados são usados para
monitoração e controle do progresso do projeto.
Quando o trabalho técnico se inicia, outras métricas começam a ser im-

portantes, tais como a taxa de produção representada em termos de mo-
delos criados, horas de revisão (veja exercícios resolvidos do capítulo 8),
pontos por função (veja seção 6.3.2) e linhas de código-fonte entregue
(veja seção 6.3.1), etc. Além disso, são registrados os erros descobertos
durante cada tarefa de engenharia de software.
À medida que o software evolui da especificação ao projeto, métricas

técnicas são coletadas para avaliar a qualidade do projeto e fornecer in-
dicadores que irão influenciar a abordagem adotada para geração de
código e teste.
7.4. Métricas de Produto
As métricas de produto são métricas que podem ser calculadas para a

documentação de um produto de software, independentemente da for-
ma como ele foi produzido, e geralmente estão relacionadas ao código
fonte, podendo ser definidas a partir de outros documentos.
Como exemplo, podemos citar que uma métrica possível seria o núme-
ro de parágrafos que consistem na especificação de requisitos.
Existem muitas taxonomias propostas para métricas de produto. A se-

guir apresentaremos as apresentadas por Pressman (2006).
Métricas para o Modelo de análise: tratam de vários aspectos do mo-

delo de análise, entre eles:
Funcionalidade Fornece uma medida indireta da funcionalidade

entregue que é empacotada com o software.
Tamanho do Mede o tamanho global do sistema definido em ter-
sistema mos de informação disponível como parte do mo-
delo de análise.
Qualidade da Fornece uma indicação da especificidade e comple-
especificação teza de uma especificação de requisitos.

95
Métricas para o Modelo de projeto: essas métricas quantificam atri-

butos do projeto de um modo que permita ao engenheiro de software
avaliar a qualidade do projeto. A métrica inclui:
Métrica arquitetural Fornece uma indicação da qualidade do proje-

to arquitetural.
Métrica no nível de Mede a complexidade dos componentes de
componente software e outras características que têm influ-
ência em sua qualidade.
Métricas de projeto Focalizam principalmente a usabilidade.
de interface
Métricas especializa- Medem características de classes e suas carac-
das em projeto OO terísticas de comunicação e colaboração.
Métricas para código-fonte: medem o código-fonte e podem ser usa-

das para avaliar sua complexidade, manutebilidade e testabilidade, entre
outras características.
Métricas de Halstead Embora controversas, fornecem medidas sin-

gulares de um programa de computador.
Métricas de Medem a complexidade lógica do código-fonte
complexidade (podem também ser consideradas como mé-
tricas de projeto no nível do componente).
Métricas de Fornecem uma indicação do tamanho do
comprimento software.
Métricas de teste: ajudam o projeto de casos de teste efetivos e avaliam

a eficácia do teste. Podem ser:
Métricas de cober- Levam ao projeto casos de teste efetivos e ava-

tura de comando e liam a eficácia do teste.
desvio
Métricas relaciona- Enfocam erros encontrados, em vez dos testes
das a defeito em si.
Efetividade de teste Fornece uma indicação em tempo real da efeti-
vidade dos testes que foram conduzidos.
Métricas em Métricas relacionadas a processo que po-
processo dem ser determinadas à medida que o teste é
conduzido.
Em muitos casos, algumas dessas métricas podem ser usadas em ativi-

dades posteriores de engenharia de software, por exemplo, métricas de
modelo de projeto podem ser usadas para estimar o esforço necessário
para gerar código-fonte.
96
Capítulo 7
Atividades
1. Após ler o capítulo, pesquise mais sobre o tema e fale com suas
próprias palavras sobre o que são:
t Métricas de Processo
t Métricas de Projeto
t Métricas de Produto
2. Fale sobre as diferenças básicas entre esses três tipos de métricas.

[2] PRESSMAN, R.S., Engenharia de Software. São Paulo:
McGraw-Hill, 6ª Edição, 2006.
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________

97
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
98
Capítulo 7

99
ANÁLISE E GERENCIAMENTO
DE RISCO
Prezado aluno,
Neste capítulo vamos abordar a área de análise e gerenciamento de

risco.. Falaremos sobre identificação de risco, estimativa de risco,
exposição de risco, mitigação de risco e sobre planos de gerencia-
mento de risco (Gustafson, 2003).
Bom estudo!
8.1. Introdução
Podemos considerar um risco como a possibilidade de um evento inde-

sejável acontecer. Esse desejo indesejável é chamado de evento de risco.
Os riscos envolvem incertezas e perdas. Não são considerados riscos
eventos que certamente ocorrerão ou eventos que não afetam negativa-
mente o projeto.
Existe uma certa discordância sobre quais riscos devem ser gerencia-
dos. Alguns especialistas sugerem que riscos comuns a vários projetos
devem ser incorporados ao processo do software, devendo apenas ser
gerenciados os riscos que são únicos a um projeto corrente.
Segundo Pressman (2006), a análise e gestão de riscos são uma série de

passos que ajudam uma equipe de software a entender e administrar as
incertezas do projeto. Muitos problemas podem perturbar um projeto
de software, mas um risco é um problema em potencial pois, como o
próprio nome diz, um risco é um risco, e, portanto, pode ou não ocorrer.
No entanto, independentemente do resultado, é importante identificar
riscos, avaliar a probabilidade de eles ocorrerem, estimar seu impacto,
estabelecer um plano de contingência no caso do problema efetivamen-
te ocorrer e monitorar os riscos.
100
Capítulo 8
8.2. Identificação de risco
A identificação de risco, como o próprio nome diz, é um processo que

identifica possíveis riscos. Os ricos podem sem classificados como:
t Riscos de Projeto: riscos que afetam o plano de projeto;

t Riscos Técnicos: riscos que afetam a qualidade do projeto;
t Riscos de Negócio: riscos que afetam a viabilidade do projeto.
O exemplo a seguir, retirado de Gustafson (2003), vai ajudá-lo a en-

tender a identificação de alguns tipos de riscos. Devemos lembrar que
alguns especialistas consideram apenas os riscos que não são comuns a
todos os projetos. Esses riscos mais comuns são considerados por eles
como parte do planejamento do projeto padrão da organização.
Exemplo: Considere um projeto que envolve a tentativa de desenvolver

um software de segurança crítica para corte de equipamento. Liste os
riscos e classifique-os como sendo de projeto, técnico ou de negócio, e
como comum a todos os projetos ou especial a este projeto.
Risco Projeto Técnico Negócio Comum Especial

Equipamento não-
X X
disponível
Requisitos
X X
incompletos
Uso de metodolo-
X X
gias Especializadas
Problemas na busca
da confiabilidade X X
requerida
Retenção de
X X
pessoas-chave
Subestimativa do
X X
esforço requerido
Desistência do
único cliente em X X
potencial
Tabela 8.1 – Tipos de Riscos
Um método de identificar riscos é criar um checklist (veja seção 9.2).

Abaixo segue uma categorização para riscos de software, que estão
associados a:

101
Análise e Gerenciamento de Risco
- Tamanho do projeto.
Os riscos do projeto são diretamente proporcionais ao tama-
nho do projeto.
- Impacto nos negócios.

Aspectos comerciais muitas vezes vão de encontro à realidade técnica.
Custo (impacto) associado com atrasos na entrega do produto final.
- Características do usuário final.

Número de pessoas que usarão o sistema.
Nível de sofisticação do usuário.
- Características do cliente.
Já trabalhou com este cliente antes?
O cliente mostra-se acessível e disposto a gastar tempo em reuniões?
O cliente tem conhecimento (treinamento) de processos de de-
senvolvimento de software?
- Definição do processo (maturidade do processo)

A empresa possui um processo de desenvolvimento de software
bem definido (CMM por exemplo – veja seção 9.5)?
O grupo está acostumado (treinado) a usar processos de desen-
volvimento de software?
Haverá um processo de desenvolvimento bem definido para
o projeto?
- Ambiente de desenvolvimento.
Há ferramentas adequadas para dar suporte a todas as fases do
desenvolvimento do projeto?
- Complexidade do produto (quantidade de tecnologia que

será empregada na construção do produto).
A tecnologia que será usada para desenvolver o projeto é nova
para a empresa ou para o grupo?
Há requisitos muito fortes de performance para o produto final?
Mais de 90% do código será escrito em uma linguagem de alto nível?
- Tamanho e experiência da equipe.

A equipe possui todas as habilidades necessárias para cons-
truir o produto?
Há pessoal suficiente para o projeto?
Assim que identificamos os possíveis riscos de um projeto, devemos es-

tabelecer planos de mitigação (evitar ou minimizar os riscos – seção
8.5) e de contingência (o que fazer caso o risco aconteça – seção 8.6).
Para isso podemos montar a seguinte tabela:
102
Capítulo 8
Plano de
Risco Probabilidade Impacto gerência de
riscos
Tamanho estima- baixa crítico
do pode ser muito
menor que o real
Equipe inexperiente média catastrófico
Troca de membros alta crítico
da equipe
Complexidade da baixa marginal
tecnologia muito
maior que a prevista
Cliente pouco alta negligenciável
disponível
... ... ... ...
Tabela 8.2 – Tabela de probabilidade, impacto e plano de gerencia de riscos
8.3. Estimativa de risco
A estimativa de risco envolve duas tarefas: estimar a probabilidade da

ocorrência do risco, também chamada de probabilidade do risco; e es-
timar o custo de acontecer o evento de risco, geralmente chamado de
impacto do risco. A tarefa de estimar a probabilidade da ocorrência do
risco é uma tarefa muito difícil. Os riscos conhecidos são mais fáceis de
gerenciar, porque se tornam parte do processo de software. Os riscos
mais importantes de gerenciar são os novos riscos, únicos para o projeto
corrente. Já o custo de um risco pode ser mais fácil de gerenciar, depen-
dendo da experiência adquirida em projetos interrompidos.
8.4. Exposição de risco
A exposição de risco é o valor esperado do evento de risco. Esse valor é

calculado multiplicando-se a probabilidade do risco pelo custo do even-
to de risco. Veja o exemplo a seguir:
Exemplo: Considere um jogo de dados com dois dados. Considere tam-

bém uma jogada de 7 como um evento indesejável, que lhe faria perder
R$ 60,00. Calcule a probabilidade do risco e o impacto do risco de acon-
tecer uma jogada de 7. Calcule a exposição do risco.

103
A probabilidade do risco é de 6 dentre as 36 combinações possíveis, ou

seja, 1/6. O impacto do risco é de R$ 60,00 (custo de o risco acontecer).
Assim, a exposição do risco é dada pela multiplicação de 1/6 por R$
60,00, dando um valor de R$ 10,00.
8.5. Mitigação de risco
Mitigação diz respeito à ação de aliviar. Ou seja, mitigação de risco é

a estratégia de encontrar maneiras de se diminuir a probabilidade da
ocorrência do risco ou diminuir o impacto da sua ocorrência. Não exis-
tem maneiras mágicas de se reduzir riscos. No entanto, é consenso que,
quanto mais cedo se tentar resolver os riscos, melhor. Por exemplo, se
existe uma preocupação sobre um sistema particular que precisa ser
usado, quanto mais cedo se investigar esses sistemas, melhor. Se o siste-
ma a ser construído precisa se comunicar com um sistema legado, por
exemplo, é importante que logo no início do projeto essa comunicação
seja testada, mesmo que seja por meio de um protótipo simples que
teste essa comunicação. Geralmente um protótipo pode ser construído
para ajudar a identificar os problemas antecipadamente.
Existe um termo chamado análise e gestão de riscos (veja capítulo 25

do livro do Pressman (2006) para mais informações) que designa uma
série de passos que ajudam uma equipe de software a entender e admi-
nistrar a incerteza inerente ao risco. Como dito anteriormente, riscos
envolvem incertezas e perdas. Muitos problemas podem perturbar um
projeto de software, e um risco é um problema em potencial, que pode
ou não ocorrer, mas independentemente se ele vai ou não ocorrer, é
muito importante identificar os riscos, avaliar a probabilidade de eles
ocorrerem, estimar seu impacto e estabelecer um plano de contingência,
no caso do problema efetivamente ocorrer. O exemplo abaixo, retirado
de Gustafson (2003) e adaptado, vai ajudá-lo a pensar em abordagens
para diminuir tanto a probabilidade quanto o impacto de riscos.
Exemplo: Considere os riscos identificados na Tabela 8.1. Sugira uma

abordagem para diminuir a probabilidade e o impacto, ou ambos, de
cada risco.
104
Capítulo 8
Diminuir
Risco Diminuir Impacto
Probabilidade
Equipamento não- Acelerar o desenvolvi-
Construir simulador
disponível mento do hardware
Requisitos Ampliar revisão dos
incompletos requisitos
Aumentar treinamen-
Uso de metodologias
tos da equipe, consul-
Especializadas
tar especialistas.
Problemas na busca
Projetar para
da confiabilidade
confiabilidade
requerida
Retenção de Empregar pessoal
Pagar mais
pessoas-chave adicional
Desenvolver no
Subestimativa do Contratar especialista
tempo estimado, re-
esforço requerido externo
estimar sempre
Desistência do único Ter avaliação externa Identificar outros
cliente em potencial da área potenciais clientes
Tabela 8.3 – Abordagens para diminuição de probabilidade e impacto de riscos
8.6. Planos de gerenciamento de risco
Na gerência de riscos, todos os aspectos envolvidos devem ser docu-

mentados em um plano de riscos, indicando os riscos que compõem o
perfil de riscos do projeto, as avaliações dos riscos, a definição dos riscos
a serem gerenciados e as ações para evitá-los ou para minimizar seus
impactos, caso venham a ocorrer (Falbo, 2005).
Um plano de riscos deve envolver alguns elementos, dentre eles:
1. Identificador do risco
2. Descrição do risco
3. Estimativa de probabilidade do risco
4. Estimativa do impacto do risco
5. Lista de estratégias de mitigação dos riscos
6. Planos de contingência
7. Marcos de risco
8. Indivíduos responsáveis (equipe)
Ainda não falamos sobre marcos de risco. Os marcos de risco servem

para identificar quando os planos de contingência devem ser ativados.

105
É bom ressaltar que outros campos podem ser adicionados ao plano

de riscos. Esta é apenas uma sugestão de modelo de plano de riscos. A
seguir apresentaremos um exemplo simples de um plano de risco, rela-
cionado a um risco apenas. (Gustafson, 2003).
Exemplo: Desenvolva um formulário para gerenciamento de risco e in-

sira dados de exemplo.
Risco: 1-010-77 Probabilidade: 10% Impacto: muito alto

Descrição: hardware especializado pode não estar disponível
Estratégia de Mitigação: construir simulador, acelerar desenvolvi-
mento do hardware
Marco do risco: hardware estragar uma semana ou mais após calendário
Plano de Contingência: ter desenvolvimento externo de hardware
como backup, implantar sistemas em um simulador
Status/data/responsável:
Criação 01/jan/08 – Marcos Silva
Simulação Completada – 10/fev/08 – Flávio Carvalho.
8.7. Monitoramento de riscos
O monitoramento de riscos é uma atividade que é realizada durante o

acompanhamento do progresso do projeto. À medida que o projeto pro-
gride, os riscos têm de ser monitorados para se verificar se os problemas
estão se tornando realidade ou não. Novos riscos podem ser identifi-
cados, o grau de exposição de um risco pode mudar e algumas ações
podem precisar ser tomadas.
Atividades
1. Depois de ler todo este capítulo, descreva com suas próprias pala-
vras se você acha importante o gerenciamento de risco e por quê.
2. Quando o gerenciamento de risco deve ser feito dentro do pro-
cesso de desenvolvimento de software? Por quê?
3. Considere que você esteja indo ao aeroporto para viajar por
uma companhia que você nunca usou antes. Descreva quais os
riscos que você considera serem únicos para essa viagem (risco
especial) e quais devem ser gerenciados como riscos comuns a
qualquer viagem (risco comum).
Fonte: Adaptado de Gustafson, 2003;
106
Capítulo 8
Exercícios Resolvidos
1. Descreva alguns riscos normais que podem acontecer em qual-
quer projeto de software.
2. Considere um projeto que tem 0.5% de probabilidade de
uma falta não-detectada causar à companhia um prejuízo de R$
100.000,00. Calcule a exposição do risco.
3. Considere o uso de uma revisão adicional para o problema 2
que custaria R$ 100,00, mas eliminaria tal falta em 50% das vezes.
Calcule essa nova exposição de risco usando a revisão adicional.
A abordagem de revisão adicional é melhor?
4. O que mudaria na Atividade 3 se uma revisão adicional fosse
efetiva em 10% das vezes?
5. A companhia X possui dados históricos que mostram que a mé-
dia de erros normais é de 0,0036 erros por KLOC. Uma nova téc-
nica de revisão custa R$ 1000,00 por 100 KLOC e decresce o nú-
mero de erros em 50%. Assuma que cada erro custe à companhia
uma média de R$ 10.000,00. O projeto em andamento é estimado
em 50 KLOC. Calcule a exposição do risco de cada abordagem. A
nova técnica de revisão é eficiente?
Fonte: Adaptado de Gustafson, 2003;
Respostas dos Exercícios
1. Riscos comuns e normais a todos os projetos de software são, por

exemplo: não entendimento dos desejos e necessidades dos usuários,
falta de comunicação ou comunicação falha com o usuário, problemas
com o hardware do usuário, o projeto ultrapassar o custo, atraso no pro-
jeto, entre outros.
2. A exposição do risco é calculada multiplicando-se a probabilidade

do risco pelo custo do evento de risco. A exposição do risco é dada pela
soma da exposição do risco para cada possibilidade:
0,005 * 100.000,00 + 0,995 * 0 = R$ 500,00.
Note que em ambos os cálculos da exposição do risco, os custos

foram acrescentados em R$ 100,00.
3. A nova exposição do risco é dada por:
0,025 * 100.100,00 + 0,9975 * 100 = R$ 250,25 + 99,75 = R$ 350,00.

107
Observe que para este novo cálculo devemos diminuir a probabilidade

da falta em 50%, indo para 25% e que o custo do projeto aumenta em R$
100,00, indo para R$ 100.100,00
A abordagem de revisão adicional é melhor.
4. A nova exposição do risco é dada por:
0,0045 * 100.100,00 + 0,9955 * 100 = R$ 450,45 + 99,55 = R$ 350,00.
Observe que este novo cálculo foi feito diminuindo 10% da probabilida-
de do risco, que é de
0,5% (0,005). Desta forma, 10% a menos de 0,005 dá 0.0045.
5. Caso 1 – Nenhuma revisão
O cálculo de exposição do risco é dado por:
0,0036 * 50 KLOC * R$ 10.000,00 = R$ 1.800,00
Caso 2 – Com revisão
O cálculo de exposição do risco é dado por:
0,0018 * 50 KLOC * R$ 10.000,00 + R$ 500,00 = R$ 1.400,00
Note que a média de erros caiu em 50% (de 00,36 para 00,18) do caso 1
para o caso 2, que foi adicionado ao caso 2 o valor de R$ 500,00, já que o
custo da revisão é de 1.000 por 100 KLOC e o projeto está estimado em
50 KLOC (metade do custo de revisão).

[2] PRESSMAN, R.S. Engenharia de Software. São Paulo:
108
Capítulo 8
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________

109
GARANTIA DE QUALIDADE DE
SOFTWARE
Prezado aluno,
Produzir software de qualidade é uma das principais metas da

engenharia de software. Neste capítulo iremos discutir alguns
assuntos mais comuns relacionados à garantia da qualidade
de software, tais como inspeção formal e técnicas de revisão,
confiabilidade do software, garantia estatística de qualidade
de software e normas e modelos de qualidade de processo de
software.
Bom estudo!
9.1. Introdução
Como vimos em vários momentos deste material, construir software de

qualidade é uma das principais metas da engenharia de software. No en-
tanto, qualidade não se consegue de forma espontânea. Muito mais do
que isso, a qualidade deve ser construída em um produto de software.
Mas o que seria um software de qualidade? Podemos considerar um

software de qualidade aquele que faz o que se espera que ele faça, e uma
das formas mais fáceis de definir se um software é ou não de qualidade é
olhar para a satisfação do usuário. Para se medir a satisfação do usuário,
a maneira usual é o relatório de defeitos. Por esse motivo, para se alcan-
çar qualidade, a técnica principal ainda é a revisão de software, que tem
por objetivo encontrar erros. (Gustafson, 2003).
Abordagens Formais para alcançar a qualidade de software têm de-

monstrado serem mais eficientes que abordagens informais. Na próxi-
ma seção discutiremos sobre revisões técnicas formais.
9.2. Revisões Técnicas Formais
Segundo Pressman (2006), uma Revisão Técnica Formal é uma ativida-

de de garantia da qualidade de software realizada por engenheiros de
software (e outros). Os objetivos das Revisões Técnicas Formais são:
110
Capítulo 9
1. Descobrir erros na função, lógica ou implementação, para qual-

quer representação do software;
2. Verificar se o software sob revisão satisfaz seus requisitos;
3. Garantir que o software tenha sido representado de acordo com
padrões pré-definidos;
4. Conseguir software que seja desenvolvido uniformemente;
5. Tornar os projetos mais administráveis.
Durante uma revisão técnica, um revisor registra todos os tópicos le-

vantados. Ao final da reunião esses tópicos são resumidos e registrados
numa “lista de tópicos de revisão”. Além disso, deve ser realizado um
relatório resumido da revisão técnica, que responda às questões abaixo:
1. O que foi revisado?

2. Quem fez a revisão?
3. Quais foram as descobertas e conclusões?
A lista de questões de revisão serve para identificar áreas problemáticas

no produto e servir como checklist de itens de ação, orientando o desen-
volvedor de software à medida que as correções são efetuadas. Geral-
mente a revisão técnica se incorpora ao registro histórico do projeto.
Checlists
Um checkist é uma lista de itens que devem ser verificados durante
uma revisão técnica. Algumas vezes os itens são colocados como
questões que devem ser respondidas. A vantagem de uma checklist
é focar a atenção do revisor nos problemas potenciais. Qualquer
falha encontrada deve ser analisada para verificar se o item da lista
garante o foco no problema detectado. Itens de uma checklist que
não são eficientes em encontrar erros durante a inspeção devem
ser removidos, pois uma quantidade grande de itens na checklist
irá prejudicar a eficiência da inspeção.
Fonte: Gustafson, 2003.
9.3. Confiabilidade do Software
A qualidade, portanto, é uma propriedade multidimensional que inclui,

além da confiabilidade de software, outros fatores de satisfação do clien-
te como funcionalidade, usabilidade, desempenho, habilidade de pres-
tação de serviço, manutenibilidade e documentação.

111
Garantia de Qualidade de Software
Na verdade, a confiabilidade é um atributo de qualidade de suma im-

portância para qualquer produto. Em relação a software, este atributo
é geralmente definido como a probabilidade do software operar sem
ocorrência de falhas durante um período especificado de tempo em um
determinado ambiente.
Segundo Gustafson (2003), a “confiabilidade de software é a medida

de quão frequentemente o software encontra uma entrada de dados
ou outra condição que não processa corretamente para produzir a res-
posta certa. A ocorrência de falhas do software não tem relação com o
seu uso demasiado”.
Geralmente a confiabilidade é denominada por R(n), onde n é um nú-

mero de unidade de tempo como, por exemplo, dia, mês, ano etc. Se
a unidade de tempo é dada em dias, R(1) significa a probabilidade do
software não falhar em 1 dia. A probabilidade de falha em um período
de tempo especificado (dada por f(n)) é 1 menos a confiabilidade para
o mesmo período de tempo, ou seja, F(n) = 1 – R(n) (Gustafson, 2003).
9.4. Garantia Estatística de Qualidade de

Software
Também chamada de Garantia da Qualidade Estatística (SQA – Statisti-

cal Quality Assurence), esse termo diz respeito ao uso da estatística para
estimar a qualidade de software. Por exemplo, executar o código com
um pequeno conjunto de casos de testes randômicos nos dará resulta-
dos que podem ser usados para estimar a qualidade (esse procedimento
algumas vezes é chamado de prova de software). A média de erros na
amostra aleatória pode ser usada como uma estimativa para a média de
erros no projeto final. Se a porcentagem de execuções corretas é alta,
então o desenvolvimento está indo bem. Caso contrário, ou seja, se é
baixa, então é possível que seja necessária a tomada de algumas ações de
remediação para o processo de desenvolvimento (Gustafson, 2003).
A Garantia da Qualidade Estatística, ou ainda, Garantia Estatística

da Qualidade, reflete uma tendência crescente em toda a indústria em
tornar-se cada vez mais quantitativa a respeito da qualidade. Em rela-
ção a software, a garantia estatítica de qualidade implica os seguintes
passos (Pressman, 2006):
1. São coletadas informações sobre defeitos de software, que de-

pois são categorizadas;
2. É feita uma tentativa de rastrear cada defeito até a sua causa
subjacente (por exemplo, não conformidade com as especifica
112
Capítulo 9
ções, erro do projeto, violação de normas, pouca comunicação

com o cliente);
3. Usando o princípio de Pareto, que diz que 80% dos defeitos po-
dem ser rastreados até 20% de todas as causas possíveis, isola-se
os 20% (“os pouco vitais”);
4. Depois de identificadas as poucas causas vitais, devemos tentar
corrigir os problemas que causaram os defeitos.
O exemplo a seguir, extraído de Pressman (2006), ilustra o uso de méto-

dos estatísticos no trabalho de engenharia de software.
Exemplo: Considere que uma organização de engenharia de software

coleta informação sobre defeitos durante um período de um ano. Alguns
dos defeitos são descobertos à medida que o software é desenvolvido.
Outros são encontrados depois que o software foi entregue a seus usu-
ários finais. Apesar de centenas de diferentes erros serem descobertos,
todos podem ser rastreados até uma (ou mais) das seguintes causas:
t Especificações incompletas ou errôneas (Incomplete or Erroneous

Specifications – IES);
t Má interpretação da comunicação com o cliente (Misinterpretation

of Customer Communication – MCC);
t Desvio intencional das especificações (Intentional Deviation Speci-

fications – IDS);
t Violação das normas de programação (Violation of Programming

Standards – VPS);
t Erro na representação dos dados (Error in Data Representation

– IDR);
t Interface de componente inconsistente (Inconsistent Component

Interface – ICI);
t Erro na lógica do projeto (Error em Design Logic – EDL);
t Teste incompleto ou errôneo (Incomplete or Erroneous Testing

– IET);
t Documentação imprecisa ou inclompleta (Inaccurate or Incomplete

Documentation – IID);
t Erro na tradução do projeto para a linguagem de programação (Er-

ror in Programming Language Translation of Design – PLT);

113
t Interface homem-computador ambígua ou inconsistente (Ambi-

guous or Inconsistent Human/Computer Interface – HCI);
t Miscelânia (MIScellaneous, MIS).
Para aplicar SQA estatística, a tabela da Figura 9.1 foi construída. A ta-
bela indica que IES, MCC e EDR são as poucas causas vitais que corres-
pondem a 53% de todos os erros. Deve-se notar, todavia, que IES, EDR,
PLT e EDL seriam selecionadas como as poucas causas vitais, se ape-
nas fossem considerados erros sérios. Uma vez determinadas as pou-
cas causas vitais, a organização de engenharia de software pode iniciar
ação corretiva. Por exemplo, para corrigir MCC, o desenvolvedor de
software poderia implementar técnicas facilitadas de coleta de requi-
sitos para aperfeiçoar a qualidade das especificações e da comunicação
com o cliente. Para aperfeiçoar EDR, o desenvolvedor poderia adquirir
ferramentas para a modelagem de dados e realizar revisões mais estritas
do projeto dos dados.
É importante notar que a ação corretiva focaliza principalmente as pou-

cas causas vitais. À medida que as poucas causas vitais são corrigidas,
novas candidatas despontam no topo da pilha.
Tem sido mostrado que as técnicas de garantia estatística de qualidade

de software propiciam aperfeiçoamentos substanciais qualidade. Em al-
guns casos, organizações de software conseguiram uma redução de 50%
dos defeitos por ano, depois de aplicar essas técnicas.
A aplicação da SQA estatística e do princípio de Pareto pode ser resu-

mida em uma única sentença: gaste seu tempo focalizando as coisas que
realmente importam, mas primeiro esteja certo de que você compreende o
que realmente importa!
Figura 9-1: coleta de dados para SQA estatística

114
Capítulo 9
9.5. Normas e Modelos de Qualidade de Proces-

so de Software
Conforme visto no capítulo 4, os modelos de ciclo de vida consistem

em uma seqüência de diferentes atividades básicas que são executa-
das durante o desenvolvimento de software. Os modelos de ciclo de
vida constituem um importante ponto de partida para a definição de
processos. No entanto, eles não são suficientes; afinal, um processo
de software é um conjunto de processos, em que podemos destacar o
processo de desenvolvimento.
Há outros processos, tais como o processo de gerência de projetos e o

processo de garantia da qualidade. No entanto, para o sucesso na defi-
nição e melhoria dos processos de software é fundamental que vários
aspectos sejam considerados. É nesse momento que entram as Nor-
mas e Modelos de Qualidade de Processo. Tais normas e modelos têm
surgido exatamente com o objetivo de apoiar a busca por processos de
maior qualidade. Eles apontam os principais aspectos que um processo
de qualidade deve considerar.
Dentre as principais normas e modelos podemos citar as normas NBR

ISO 2001, NBR ISO 9000:2000, NBR ISO/IEC 12207, ISO/IEC 15504,
SGQTEC, ISO/IEC 9126 e os modelos CMMI e MPS-BR.
9.5.1 As Normas de Qualidade ISO 9000
Um sistema de garantia de qualidade pode ser definido como a estrutura

organizacional, responsabilidades, procedimentos, processos e recursos
para implementar a gestão da qualidade. Tais sistemas são criados para
ajudar as organizações a garantir que seus produtos e/ou serviços satis-
façam as expectativas dos clientes, estando em conformidade com suas
especificações.
A ISO 9000 possui vários modelos de sistemas de garantia de quali-

dade. Ela descreve os elementos de garantia de qualidade em termos
genéricos, que podem ser aplicados a qualquer negócio, independente-
mente dos produtos ou serviços oferecidos. Para o registro em um dos
modelos de sistema de garantia de qualidade contidos na ISO 9000, o
sistema e operações de qualidade da empresa são analisados e avaliados
por auditores externos que verificam o atendimento das normas e da
efetividade da operação. Após o registro bem sucedido, a empresa rece-
be um certificado de um corpo de registro representado pelos auditores
(Pressman, 2006).

115
ISO é a sigla da Organização Internacional de Normalização (In-

ternational Organization for Standardization), que tem sede em
Genebra, Suíça e que cuida da normalização (ou normatização)
em nível mundial. A ISO cria normas nos mais diferentes seg-
mentos, variando de normas e especificações de produtos, ma-
térias-primas, em todas as áreas. A ISO ficou popularizada pela
série 9000, ou seja, as normas que tratam de Sistemas para Gestão
e Garantia da Qualidade nas empresas.
Em 1987, a ISO editou a série 9000 com o objetivo de estabelecer
critérios para implantação de Sistemas de Garantia da Qualidade.
A primeira versão criou uma estrutura de três normas sujeitas à
certificação, a ISO 9001, 9002 e 9003, além da ISO 9000, que era
uma espécie de guia para seleção da norma mais adequada ao tipo
de organização. Com três anos de atraso, a ABNT emitiu a pri-
meira versão (tradução) da série no Brasil. A mesma foi nomeada
série NBR 19000. Em 1994, a série foi revisada, porém sem gran-
des modificações, apenas com uma pequena ampliação e alguns
esclarecimentos em seus requisitos, mantendo a mesma estrutura,
ou seja, três normas sujeitas à certificação; em paralelo, a ABNT
revisou as normas brasileiras, adotando o nome “série NBR ISO
9000”, alinhando-se com o resto do mundo, que já adotava no-
menclatura similar para suas versões nacionais. Em Dezembro de
2000, a série foi totalmente revisada; além das alterações em sua
estrutura, tendo apenas a ISO 9001 sujeita à certificação.
Fonte: http://www.comexito.com.br/ISO9001/sobre_a_ISO9001.doc
Acesso em: 07/03/2009.
A série NBR ISO 9000:2000
As normas da família NBR 9000 foram desenvolvidas para apoiar or-

ganizações de todos os tipos e tamanhos na implementação e operação
de sistemas eficazes de gestão da qualidade. As normas que compõem a
série ISO 9000:2000 são (Falbo, 2005):
t NBR ISO 9000: descreve os fundamentos de sistemas de gestão

da qualidade e estabelece a terminologia para esses sistemas;
t NBR ISO 9001: especifica os requisitos para um sistema de ges-

tão da qualidade com enfoque na satisfação do cliente. Para uma or-
ganização ser certificada ISO 9001, ela precisa demonstrar sua capa-
cidade para fornecer produtos que atendam aos requisitos do cliente
(explícitos e implícitos) e os requisitos regulamentares aplicáveis;
116
Capítulo 9
t NBR ISO 9004: fornece diretrizes que consideram tanto a eficá-

cia como a eficiência do sistema de gestão da qualidade. Seu objetivo
é melhorar o desempenho da organização e a satisfação dos clientes
e das demais partes interessadas;
t NBR ISO 19011: fornece diretrizes sobre auditoria de sistemas

de gestão da qualidade e ambiental.
“A ISO 9000 é de caráter geral, ou seja, não se destina especi-

ficamente à indústria de software e estabelece requisitos míni-
mos da garantia da qualidade que devem ser atendidos pelos
fornecedores de produtos ou serviços. Ela é uma norma certi-
ficadora. Essa certificação, mundialmente reconhecida, é feita
por organismos certificadores, em geral, credenciados por or-
ganismos nacionais de acreditação, no caso do Brasil, o INME-
TRO. Assim, a conquista da certificação ISO 9000 por uma em-
presa significa que a mesma alcançou um padrão internacional
de qualidade em seus processos.
O principal problema para se adotar essa norma é precisamente o
fato de ela ser geral. Assim, quando aplicada ao contexto da indús-
tria de software, muitos problemas surgem pela falta de diretrizes
mais focadas nas características de processos de software. De ma-
neira geral, outras normas e modelos de qualidade são usadas por
organizações de software para apoiar uma certificação ISO 9000,
com destaque para a norma NBR ISO/IEC 12207”.
Fonte: Falbo, 2005.
Atividades
Pesquise sobre as normas NBR ISO 2001, NBR ISO 9000:2000,
NBR ISO/IEC 12207, ISO/IEC 15504, SGQTEC, ISO/IEC 9126 e
os modelos CMMI e MPS-BR e discuta com seus colegas no fó-
rum “Normas e Modelos de Qualidade de Processo de Software”.
Para saber mais sobre as Normas da Série ISO 9000 visite o link:
http://allchemy.iq.usp.br/sedimentando/iso.htm
Acesso em 07/03/2009.

117

[2] PRESSMAN, R.S., Engenharia de Software. São Paulo:
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
118
Capítulo 9

119
FALBO, Ricardo de Almeida. Notas de Aula: Engenharia de Sof-

tware. Disponível em http://www.inf.ufes.br/~falbo, 2005.
GUSTAFSON, David A. Teoria a problemas de engenharia de

software. Porto alegre: Bookman, 2003. (Coleção Schaum).
PRESSMAN, Roger S. Engenharia de Software. 6 ed. São Paulo:

McGraw-Hill, 2006.
SOMMERVILLE, Ian. Engenharia de Software. 6 ed. São Paulo:

Pearson Addison Wesley, 2003.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fun-

damentos, métodos e padrões. 2 ed. Rio de Janeiro: LTC, 2003.
120

121
ANEXO A
Documento de Especificação de Análise
1. Introdução
Este documento contém a especificação de análise para o projeto de

informatização da Loja Vitória. Essa atividade foi desenvolvida em duas
etapas principais, a primeira focando a estrutura de informação do sis-
tema (classes, atributos e associações), a segunda, seu comportamento
(operações e trocas de mensagem entre objetos). Na seção 2, são apre-
sentados os produtos da primeira etapa, a saber: Diagrama de Pacotes e
Diagramas de Classes (um para cada pacote). Na seção 3, são apresen-
tados os produtos da segunda etapa: Diagramas de Transição de Esta-
dos (para as classes com comportamento variável ao longo do tempo)
e Diagramas de Sequência (agrupados por casos de uso), fechando o
conjunto de produtos gerados na fase de análise.
2. Modelo de Classes
A modelagem de classes envolve a identificação de classes, atributos,

relacionamentos e operações, bem como o agrupamento de classes em
subsistemas ou pacotes. Uma vez que, muitas vezes, é difícil identifi-
car todos os atributos e, principalmente, todas as operações através da
modelagem de classes, foram construídos modelos de comportamento,
apresentados na seção 3. É importante ressaltar que os modelos apre-
sentados nesta seção, contudo, já espelham os resultados obtidos com a
modelagem do comportamento.
122
ANEXOS
2.1 Diagrama de Pacotes
O propósito de um diagrama de pacotes é prover uma visão de nível

mais alto do sistema, mostrando sua decomposição em subsistemas. O
ponto de partida para essa decomposição é o domínio do problema e,
portanto, a decomposição utilizada no modelo de casos de uso foi trans-
posta para o modelo de classes, como mostra a figura A.1.
Figura A.1 – Diagrama de Pacotes
O diagrama da figura A.1 mostra a dependência principal entre os subsis-

temas, indicando que o pacote ControleNotaFiscal solicita serviços do
pacote ControleInterno para poder cumprir suas responsabilidades.
Na próxima seção, são apresentados os diagramas de classes para cada

um desses pacotes.
2.2 Diagramas de Classes
A figura A.2 apresenta o Diagrama de Classes referente ao pacote

ControleInterno.
Figura A.2 – Diagrama de Classes do Pacote ControleInterno.
Não foram representadas no diagrama as operações básicas para criar e

destruir instâncias de uma classe, para estabelecer e navegar associações
e para obter e atribuir valores para atributos.

123
ANEXO A
A figura A.3 apresenta o Diagrama de Classes referente ao pacote Contro-

leNotaFiscal. As classes Produto, Cliente e Fornecedor, oriundas do pa-
cote ControleInterno, mostram a integração entre esses subsistemas.
Figura A.3 – Diagrama de Classes do Pacote ControleNotaFiscal.
Assim como para o Diagrama de Classes do pacote ControleInterno,

não foram representadas no diagrama as operações básicas.
3. Modelo Comportamental
A modelagem do comportamento dos objetos visa apoiar a identifica-

ção de atributos e operações de classes. Nesta seção, são apresentados os
Diagramas de Estados, os Diagramas de Sequência e as descrições das
operações das classes.
3.1 Diagramas de Transição de Estados
3.1.1 Classe Cliente do Pacote ControleInterno
A figura A.4 mostra o diagrama de estados da classe Cliente. Os even-

tos mostrados dizem respeito à realização dos casos de uso ou eventos
dos mesmos. Esse diagrama deu origem ao atributo estado da classe
124
ANEXOS
Cliente, que indica o estado de um objeto dessa classe em um determi-

nado momento. Um cliente é criado no estado Prospectado, indican-
do que ainda não realizou nenhuma compra. A partir do momento em
que são emitidas notas fiscais para esse cliente, o evento Ativar Cliente
altera seu estado para Ativo, caso o total de compras seja inferior a R$
2.000,00; ou para Preferencial, caso o total seja superior a R$ 2.000,00.
Além disso, se for desejado, o evento Desativar Cliente modifica o es-
tado de clientes ativos ou preferenciais para Inativo, sendo essa uma
operação reversível.
Figura A.4 – Diagrama de Estados da Classe Cliente do Pacote ControleInterno.
3.2 Diagramas de Seqüência
A seguir, são apresentados os Diagramas de Sequência construídos nes-

te projeto. Apenas os cursos normais dos casos de uso / cenários foram
considerados para a elaboração desses diagramas e, portanto, na ativi-
dade de Projeto Detalhado das Operações (Projeto de Objetos) da fase
de Projeto, os cursos alternativos devem ser incorporados.

125
ANEXO A
Caso de Uso Cadastrar Cliente / Evento Incluir Novo Cliente
Caso de Uso Cadastrar Cliente / Evento Ativar Cliente
126
ANEXOS
Caso de Uso Cadastrar Cliente / Evento Excluir Cliente
Caso de Uso Controlar Nota Fiscal de Saída / Evento Emitir Nota Fiscal

127
ANEXO A
Caso de Uso Emitir Relatório / Evento Listar Notas Fiscais de Saída
128
ANEXOS

129
ANEXO B
Documento de Especificação de Projeto
1. Introdução
Este documento contém a Especificação de Projeto para o sistema da

Loja Vitória. Esta atividade foi desenvolvida em duas etapas principais,
a primeira focando na arquitetura do sistema, produzindo diagramas
de pacotes e os respectivos diagramas de classes para os componen-
tes identificados, a segunda tratando do projeto detalhado das classes
identificadas anteriormente (projeto de operações e estruturas de dados
internas). A seção 2 discute a plataforma de implementação conside-
rada. Na seção 3, é apresentada a arquitetura do sistema, na forma de
Diagramas de Pacotes. As seções 4, 5, e 6 apresentam os Diagramas de
Classes para cada um dos subsistemas identificados, organizados por
estereótipos, quando necessário. Para as Componentes de Gerência de
Dados, são apresentados, ainda, os Diagramas Relacionais correspon-
dentes, tendo em vista o uso de bancos de dados relacionais para a per-
sistência de objetos.
2. Plataforma de Implementação
O sistema proposto será implementado usando a linguagem de pro-

gramação Java. Além disso, a persistência dos objetos será feita em um
banco de dados relacional.
3. Arquitetura do Sistema
A organização de classes em pacotes deve ser o ponto de partida para

a definição da arquitetura do sistema, já que é um meio de estabelecer
níveis de abstração para o modelo. Esses níveis de abstração podem ser
130
ANEXOS
organizados em camadas e, assim, tratados separadamente durante a

fase de projeto. A organização de classes em pacotes é útil também para
permitir a produção de componentes para reuso.
Neste trabalho, foram utilizadas duas formas complementares de agru-

pamento de classes em pacotes: primeiramente pelo domínio do proble-
ma, aproveitando os subsistemas definidos na fase de análise, e depois
por estereótipos, tendo sido utilizados os estereótipos propostos por
Coad e Yourdon [Coad93]. Sendo assim, o diagrama de pacotes de nível
mais alto, mostrado na figura B.1, é praticamente o mesmo da fase de
análise, exceto pela introdução do pacote Utilitario, que trata classes
reutilizáveis em outros contextos.
O diagrama da figura B.1 mostra as dependências entre os subsistemas,

indicando que os pacotes ControleInterno e ControleNotaFiscal soli-
citam serviços ao pacote Utilitario. Mantendo a coerência com o dia-
grama da fase de análise, o pacote ControleNotaFiscal solicita serviços
do pacote ControleInterno.
Os pacotes ControleInterno e ControleNotaFiscal foram decompos-

tos em outros pacotes segundo os estereótipos, dando origem a novos
diagramas de pacotes, a serem discutidos nas próximas seções.
Figura B.1 – Diagrama de Pacotes
4. O Pacote Controle Interno
Este pacote foi decomposto no diagrama de pacotes da figura B.1, agora

tomando por base os estereótipos.

131
ANEXO B
Figura B.2 – Diagrama de Pacotes do Pacote Controle Interno
4.1. Pacote CDP do ControleInterno
A figura B.3 apresenta o Diagrama de Classes referente à Componente do

Domínio do Problema do pacote ControleInterno. O diagrama conside-
ra os tipos dos atributos e a navegabilidade existente entre as classes.
Figura B.3 – Diagrama de Classes do Pacote CDP do ControleInterno
É importante realçar que as alterações introduzidas em relação ao mo-

delo de análise dizem respeito a requisitos não funcionais importantes
para o sistema, tais como:
132
ANEXOS
t Reusabilidade: visando construir classes reutilizáveis em

domínios diversos, optou-se por desenvolver uma hierar-
quia de Pessoa (pacote Utilitario.Pessoa). Essa hierarquia
foi utilizada como base de herança para as classes Fornece-
dor e Cliente. Como clientes podem ser pessoas físicas ou ju-
rídicas (podendo estas ainda ser fornecedores), foi adotada
a herança por composição para garantir a Cliente o compor-
tamento desejado.
t Facilidade de Uso: como forma de separar parte da funciona-
lidade de Cliente, foi criada a classe EstadoCliente, responsá-
vel pelos estados que um cliente pode assumir.
t
4.2. Pacote CGT do ControleInterno
A figura B.4 apresenta o Diagrama de Classes referente à Componente

de Gerência de Tarefas do pacote ControleInterno.
Figura B.4 – Diagrama de Classes do Pacote CGT do ControleInterno
No pacote ControleInterno foi criada apenas uma classe de aplicação,

responsável pelos casos de uso Cadastrar Cliente, Cadastrar Fornecedor
e Cadastrar Produto. Essa classe está relacionada à aplicação principal
do ambiente, criada no pacote ControleNotaFiscal.

133
ANEXO B
4.3. Pacote CIH do ControleInterno
A figura B.5 apresenta o Diagrama de Classes (parcial) referente à Com-

ponente de Interação Humana do pacote ControleInterno.
Figura B.5 – Diagrama de Classes do Pacote CIH do ControleInterno
4.4. Pacote CGD do ControleInterno
Como a persistência dos objetos será realizada em um BD relacional,

é interessante procurar minimizar os impactos da tecnologia de BDs
sobre o sistema. Optou-se, portanto, por trabalhar com classes-sombra
responsáveis pela interação direta com o BD relacional e, consequen-
temente, com conhecimento de JDBC e SQL. Para tal, foi utilizada a
camada de persistência apresentada na seção 6.4. Nessa infra-estrutura,
para cada classe a ser persistida que possua uma tabela correspondente
no BD deve ser criada uma classe-sombra, responsável pela interação
com a base de dados relacional, como mostra a figura B.6.
Figura B.6 – Diagrama de Classes do Pacote CGD do ControleInterno
134
ANEXOS
Uma característica marcante dessa abordagem é a necessidade de se es-

tabelecer identificadores únicos para os objetos (IDOs) a serem persis-
tidos. Usando a camada de persistência, todas as classes cujos objetos
têm de ser persistentes passam a herdar de ClasseBasePersistencia, que
é responsável pelos IDOs.
Além disso, foi necessário construir um Diagrama Relacional, mape-

ando as classes e objetos em tabelas e linhas. O Diagrama Relacional
referente ao pacote ControleInterno é apresentado na figura B.7.
Figura B.7 – Diagrama Relacional do Pacote CGD do ControleInterno
No pacote ControleInterno, para cada classe persistente foi criada uma

tabela correspondente. As tabelas Pessoa e Telefone têm origem no pa-
cote Utilitario e a tabela Fornecimento surgiu do relacionamento N x N
existente entre Produto e Fornecedor.
5. O Pacote Controle Nota Fiscal
Este pacote foi decomposto no diagrama de pacotes da figura B.8, agora

tomando por base os estereótipos.

135
ANEXO B
Figura B.8 – Diagrama de Pacotes do Pacote Controle Nota Fiscal
5.1. Pacote CDP do ControleNotaFiscal
A figura B.9 apresenta o Diagrama de Classes referente à Componente do

Domínio do Problema do pacote ControleNotaFiscal. O diagrama con-
sidera os tipos dos atributos e a navegabilidade existente entre as classes.
Figura B.9 – Diagrama de Classes do Pacote CDP do ControleNotaFiscal
É importante realçar que as alterações introduzidas em relação ao mo-

delo de análise dizem respeito a requisitos não funcionais importantes
para o sistema, tais como o desempenho. Neste exemplo, como forma
de evitar a soma dos valores de todos os itens de uma nota fiscal para
que se saiba o seu valor total, foi introduzido o atributo valor na classe
NotaFiscalSaída, para armazenar esse dado, evitando operações desne-
cessárias. 5.2. – Pacote CGT do ControleNotaFiscal
136
ANEXOS
A figura B.10 apresenta o Diagrama de Classes referente à Componente

de Gerência de Tarefas do pacote ControleNotaFiscal.
Figura B.10– Diagrama de Classes do Pacote CGT do ControleNotaFiscal
No pacote ControleNotaFiscal foram criadas as seguintes classes de aplicação:
- AplControlarNotaFiscal: que agrupa as funcionalidades des-

critas nos casos de uso Registrar Nota Fiscal e Emitir Nota Fiscal;
- AplEmitirRelatorio: responsável pela criação de relatórios (caso
de uso Emitir Relatório);
- AplPrincipal: que é a aplicação principal do sistema, responsá-
vel por gerenciar as outras aplicações.
5.3. Pacote CIH do ControleNotaFiscal
A figura B.11 apresenta o Diagrama de Classes (parcial) referente à

Componente de Interação Humana do pacote ControleNotaFiscal.
Figura B.11 – Diagrama de Classes do Pacote CIH do ControleNotaFiscal

137
ANEXO B
A classe JanPrincipal é janela de abertura do sistema e contém os menus de

acesso às funcionalidades, a classe JanRelatorio possui uma série de subclas-
ses responsáveis pela exibição dos relatórios específicos, e a classe JanFiltro
funciona como auxiliar para seleção de dados na emissão de relatórios.
5.4. Pacote CGD do ControleNotaFiscal
Conforme discutido na seção 4.4, a persistência dos objetos será realiza-

da através da camada de persistência e de classes-sombra. Vale lembrar
que, para cada classe a ser persistida que possua uma tabela correspon-
dente no BD, deve ser criada uma classe-sombra, responsável pela inte-
ração com o BD, como mostra a figura B.12.
Figura B.12 – Diagrama de Classes do Pacote CGD do ControleNotaFiscal
Além das classes sombra, e necessário construir um Diagrama Relacional,

mapeando as classes e objetos em tabelas e linhas. O Diagrama Relacional
referente ao pacote ControleNotaFiscal é apresentado na figura B.13.
Figura B.13 – Diagrama Relacional do Pacote CGD do ControleNotaFiscal
138
ANEXOS
No pacote ControleNotaFiscal, para cada classe persistente foi criada

uma tabela correspondente. Para a hierarquia de notas fiscais foi ado-
tada a abordagem de criação de uma tabela por classe, dando origem
às tabelas NotaFiscal, NotaFiscalEntrada e NotaFiscalSaída. Vale realçar
que, quando há relacionamento entre tabelas originado de herança entre
classes, os IDOs dos registros na hierarquia devem ser idênticos, dado
que um objeto deve possuir um único identificador. As tabelas Cliente,
Fornecedor e Produto têm origem no pacote ControleInterno.
6. O Pacote Utilitário
Este pacote contém vários pacotes de utilitários, que podem ser úteis
em diversos sistemas. Nesta seção são apresentados somente os pacotes
utilizados neste sistema.
6.1 Pacote Pessoa
Este pacote contém classes para tratar aspectos gerais de pessoas físicas
e jurídicas, comuns a vários sistemas, como mostra a figura B.14a.
A figura B.14b exibe as classes-sombra deste pacote. Há apenas uma clas-

se-sombra responsável pela hierarquia de pessoa, dado ao fato da utiliza-
ção da abordagem de criação de uma única tabela para toda a hierarquia.
Figura B.14a - Diagrama de Classes do Pacote Utilitario.Pessoal

139
ANEXO B
Figura B.14b - Diagrama de Classes-Sombra do Pacote Utilitario.Pessoal
6.2. Pacote Geral
Este pacote possui classes de cunho geral para o sistema, assim como
para manipulação de listas, iteradores, comparadores, datas etc. A figura
B.15 mostra a classe Data utilizada neste sistema.
Figura B.15 – Classe Data
6.3. Pacote InterfaceUsuario
Este pacote contém classes para tratar de aspectos gerais de interfaces

gráficas, comuns a vários sistemas, como mostra a figura B.16.
Figura B.16 – Diagrama de Classes Pacote Utilitario.

InterfaceUsuario
140
ANEXOS
t PainelCadastroTabela: classe abstrata que representa o painel

de cadastro utilizado em situações em que é necessário o ca-
dastro de objeto.
t JanDados: janela abstrata utilizada como receptora dos dados
de objetos durante um cadastro.
t PainelSelecao: classe que possui duas listas de objetos, das quais
podem ser selecionados e transferidos de uma lista para outra.
t JanRelatorio: janela abstrata utilizada tipicamente para exibi-
ção de listagens.
6.4. – Pacote Persistência
Este pacote contém a camada de persistência, responsável por tratar

aspectos gerais de gerência de dados, comuns a vários sistemas, como
mostra a figura B.17.
Figura B.17 – Diagrama de Classes da Camada de Persistência
ClasseBasePersistencia é a classe abstrata da qual todas as classes a se-

rem persistidas, tipicamente da CDP, devem herdar. Ela possui um rela-
cionamento com FabricaIDOs, de que obtém os novos identificadores, e
o atributo IDO que se mantém encapsulado e isolado das subclasses do
domínio. As operações de persistência de objetos apresentam-se genera-
lizadas e utilizam as classes-sombra para obter, salvar ou excluir objetos.
A classe abstrata ClasseBaseSombra é a superclasse de todas as classes-

sombra. Essa classe possui diversas operações de persistência, possibi-
litando que as classes-sombra sejam o mais simples possível. A classe
associa-se com a Conexao utilizada para acessar o banco; um Registro,
que guarda informações a respeito de objetos e das tabelas nas quais
são persistidos, e com o Buffer, que armazena objetos para melhorar o
desempenho das aplicações.

A Post I Lae Ngen Hari A Software

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

A Post I Lae Ngen Hari A Software

Enviado por

Direitos autorais:

Formatos disponíveis

&OHFOIBSJBEF4PGUXBSF

Ifes – Instituto Federal do Espírito Santo

Coordenadora do CEAD – Centro de Educação a Distância

Coordenadoras da UAB – Universidade Aberta do Brasil

Curso de Tecnologia em Análise e Desenvolvimento de Sistemas

Catalogação da fonte: Rogéria Gomes Belchior - CRB 12/417

Créditos de autoria da editoração

Tecnologia em Análise e Desenvolvimento de Sistemas

É um prazer tê-lo conosco.

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por você,

Indicação de leituras complemtares, referentes

Destaque de algo importante, referente ao

Reflexão/questionamento sobre algo impor-

Espaço reservado para as anotações que você

Tecnologia em Análise e Desenvolvimento de Sistemas

Cap. 1 - INTRODUÇÃO À ENGENHARIA DE

Cap. 2 - CARACTERÍSTICAS DO SOFTWARE 19

Cap. 3 - PROCESSOS DE SOFTWARE 29

Cap. 4 - MODELOS DE CICLO DE VIDA 39

Cap. 5 - ATIVIDADES DE DESENVOLVIMENTO 51

5.3. Implementação e Testes 55

Cap. 6 - GERENCIAMENTO DE PROJETO DE

Cap. 7 - MÉTRICAS DE SOFTWARE 89

Cap. 8 - ANÁLISE E GERENCIAMENTO DE

Cap. 9 - GARANTIA DE QUALIDADE DE

Tecnologia em Análise e Desenvolvimento de Sistemas

REFERÊNCIAS BIBLIOGRÁFICAS 119

Tecnologia em Análise e Desenvolvimento de Sistemas

1.1. Visão Geral

O termo Engenharia é muito comum de ser utilizado em diferentes

A Engenharia, segundo o Dicionário Houaiss da língua portu-

Além disso, várias são as especialidades ou ramos da engenharia. Algu-

Mas e a Engenharia de Software, o que seria? Certamente, se você é um

A seguir, tentarei esclarecer essas dúvidas.

1.1.1. O que é software?

Um sistema de software geralmente consiste em uma série programas

• os arquivos de configuração que são utilizados para configu-

• a documentação do sistema, que descreve a estrutura des-

• e a documentação do usuário, que explica como utilizar

No caso de produtos de software, há ainda sites web onde os usuários

Há dois tipos de produtos de software:

1. Os Produtos Genéricos, que são sistemas do tipo stand-alone,

O termo stand-alone significa independente, isolado, autônomo.

Tecnologia em Análise e Desenvolvimento de Sistemas

2. Produtos sob encomenda ou personalizados, que são sistemas

1. Software de Sistemas: coleção de programas escritos para

2. Software de Aplicação: programa isolado que resolve uma

3. Software Científico e de Engenharia: antigamente caracte-

4. Software Embutido: reside dentro de um produto ou sistema e é

5. Software para linhas de produtos: projetado para fornecer

6. Aplicações Web: cobrem uma ampla variedade de aplica-

7. Software para Inteligência Artificial: faz uso de algoritmos

cações nessa área incluem robótica, sistemas especialistas, re-

1.1.2. O que é engenharia de software?

A engenharia de software é uma disciplina da engenharia que se preo-

Em relação à engenharia de software é muito importante desta-

1.1.3. Qual é a diferença entre engenharia de software,

A engenharia de sistemas é uma disciplina mais antiga que a engenharia

Tecnologia em Análise e Desenvolvimento de Sistemas

1.1.4. Qual é a diferença entre engenharia de software e

A ciência da computação se preocupa com as teorias e métodos básicos

1.2. Histórico da Engenharia de Software