Apostila Engenharia de Software

PROF.
TNIA BARBOSA SALLES GAVA

ENGENHARIA DE SOFTWARE
SERRA
2009
2
Tecnologia em Anlise e Desenvolvimento de Sistemas
Governo Federal
Ministro de Educao
Fernando Haddad
Ifes Instituto Federal do Esprito Santo
Reitor
Dnio Rebello Arantes
Pr-Reitora de Ensino
Cristiane Tenan Schlittler dos Santos
Coordenadora do CEAD Centro de Educao a Distncia
Yvina Pavan Baldo
Coordenadoras da UAB Universidade Aberta do Brasil
Yvina Pavan Baldo
Maria das Graas Zamborlini
Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas
Coordenao de Curso
Isaura Nobre
Designer Instrucional
Danielli Veiga Carneiro / Jos Mrio Costa Jnior
Professor Especialista/Autor
Tnia Barbosa Salles Gava
Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417
F279e Gava, Tnia Barbosa Salles
Engenharia de sofware. / Tnia Barbosa Salles Gava. Vitria: Ifes, 2009.
140 p. : il.
1. Engenharia de software. I. Instituto Federal do Esprito Santo. II. Ttulo.

CDD 005.1
DIREITOS RESERVADOS
Ifes Instituto Federal do Esprito Santo
Av. Vitria Jucutuquara Vitria ES - CEP - (27) 3331.2139
Crditos de autoria da editorao
Capa: Juliana Cristina da Silva
Projeto grfco: Juliana Cristina da Silva / Nelson Torres
Iconografa: Nelson Torres
Editorao eletrnica: Duo Translations
Reviso de texto:
Ilioni Augusta da Costa
Maria Madalena Covre da Silva
COPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao escrita dos autores
e do detentor dos direitos autorais.
3
Engenharia de Software
Ol, Aluno(a)!
um prazer t-lo conosco.
O Ifes(Instituto Federal do Esprito Santo) oferece a voc, em parceria com
as Prefeituras e com o Governo Federal, o Curso Tecnologia em Anlise e
Desenvolvimento de Sistemas, na modalidade a distncia. Apesar de este
curso ser ofertado a distncia, esperamos que haja proximidade entre ns,
pois, hoje, graas aos recursos da tecnologia da informao (e-mails, chat,
videoconferncia, etc.) podemos manter uma comunicao efetiva.
importante que voc conhea toda a equipe envolvida neste curso: co-
ordenadores, professores especialistas, tutores a distncia e tutores presen-
ciais porque, quando precisar de algum tipo de ajuda, saber a quem
recorrer.
Na EaD Educao a Distncia, voc o grande responsvel pelo sucesso
da aprendizagem. Por isso, necessrio que se organize para os estudos e
para a realizao de todas as atividades, nos prazos estabelecidos, confor-
me orientao dos Professores Especialistas e Tutores.
Fique atento s orientaes de estudo que se encontram no Manual do
Aluno!
A EaD, pela sua caracterstica 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
4
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por voc,
aps a leitura dos textos.
Indicao de leituras complemtares, referentes
ao contedo estudado.
Destaque de algo importante, referente ao
contedo apresentado. Ateno!
Refexo/questionamento sobre algo impor-
tante referente ao contedo apresentado.
Espao reservado para as anotaes que voc
julgar necessrias.
ICONOGRAFIA
Veja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos.
5
ENGENHARIA DE SOFTWARE
Cap. 1 - INTRODUO ENGENHARIA DE
SOFTWARE 9
1.1. Viso Geral 9
1.1.1. O que software? 10
1.1.2. O que engenharia de software? 12
1.1.3. Qual a diferena entre engenharia de
software, engenharia de sistemas e engenharia
de conhecimento? 12
1.1.4. Qual a diferena entre engenharia de
software e cincia da computao? 13
1.2. Histrico da Engenharia de Software 13
1.3. Qualidade de Software 14
Cap. 2 - CARACTERSTICAS DO SOFTWARE 19
2.1. O Software como Produto 19
2.1.1. Caractersticas de um Software 21
2.1.2. Mitos do Software 23
Cap. 3 - PROCESSOS DE SOFTWARE 29
3.1. Uma viso genrica de processo 29
3.2. Processo de Software x Engenharia de
Software 30
3.3. O que um Processo de Software 32
3.4. Definio 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. Especificao e Anlise de Requisitos 51
5.2. Projeto de Sistema 53
6
5.3. Implementao e Testes 55
5.4. Entrega e Manuteno 57
5.5. Exemplo da Loja Vitria 58
5.5.1. Documento de Especificao de Requi-
sitos 59
Cap. 6 - GERENCIAMENTO DE PROJETO DE
SOFTWARE 71
6.1. Introduo 71
6.2. Escopo de Software 71
6.3. Estimativa de Custo de Software 72
6.3.1. Estimativa LOC (Estimativa de Linha de
Cdigo) 72
6.3.2. Anlise de Ponto de Funo 77
6.4. Elaborao de Cronograma 80
Cap. 7 - MTRICAS DE SOFTWARE 89
7.1. Mtricas de Software 89
7.2. Mtricas de Processo 92
7.3. Mtricas de Projeto 93
7.4. Mtricas de Produto 94
Cap. 8 - ANLISE E GERENCIAMENTO DE
RISCO 99
8.1. Introduo 99
8.2. Identificao de risco 100
8.3. Estimativa de risco 102
8.4. Exposio de risco 102
8.5. Mitigao de risco 103
8.7. Monitoramento de riscos 105
Cap. 9 - GARANTIA DE QUALIDADE DE
SOFTWARE 109
9.1. Introduo 109
9.2. Revises Tcnicas Formais 109
9.3. Confiabilidade do Software 110
9.4. Garantia Estatstica 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
REFERNCIAS BIBLIOGRFICAS 119
ANEXO A 121
ANEXO B 129
8
APRESENTAO
Ol!
Meu nome Tnia Barbosa Salles Gava, responsvel pela disciplina de
Engenharia de Sofware. Sou professora atualmente do Instituto Federal
do Esprito Santo, Centro Universitrio Vila Velha (UVV), mas j lecionei
em outras instituies de ensino superior como Centro Universitrio So
Camilo, Universidade Federal do Esprito Santo e Faculdade Salesiana
de Vitria. Tambm atuo como professora em cursos de ps-graduao
latu-sensu do IFES, UVV, e cursos a distncia, fornecidos pelo programa
ProInfo, em parceria com o MEC-UFES-UFRGS.
Sou graduada em Matemtica Aplicada e Computacional (1995)
e Cincia da Computao (1996), Mestre em Informtica (1998)
e Doutora em Engenharia Eltrica-Automao, todos cursados na
UFES.
Nesta disciplina sero discutidos assuntos relacionados disciplina de en-
genharia de sofware. Muitos dos conceitos que sero discutidos j foram
vistos com diferentes nveis de profundidade nas disciplinas de Anlise de
Sistema e Projeto de Sistemas, e outros assuntos sero novos para voc.
O objetivo deste material auxili-lo no estudo da disciplina de engenha-
ria de sofware, por meio de dicas e sugestes que destacam os pontos mais
importantes a serem estudados. O objetivo do material dar um enfoque
mais prtico disciplina, citando exemplos sempre que possvel, e dando
sugestes de leituras complementares.
Em geral, para ser bem sucedido neste curso, importante que voc faa
as atividades sugeridas e estude os exerccios resolvidos, alm dos estudos
regulares, evitando, dessa forma, o acmulo de contedo. A participao
no ambiente e, consequentemente, a interao com os colegas e tutores
extremamente importante para o sucesso na disciplina e no curso como
um todo. Procure realizar com afnco 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 Tnia Barbosa Salles Gava
9
Prezado aluno,
Neste primeiro captulo abordarei como temas principais uma introduo
engenharia de sofware, um breve histrico dessa disciplina e falarei um
pouco sobre qualidade de sofware. Tambm sero apresentados os trs
tipos bsicos de atividades envolvidas na engenharia de sofware: ativida-
des de desenvolvimento, atividades de gerncia de projeto e atividades de
garantia da qualidade. Para cada um destes trs tipos de atividades ser
dedicado um captulo. A saber, captulos 5, 6 e 7 respectivamente.
Bons estudos!
1.1. Viso Geral
O termo Engenharia muito comum de ser utilizado em diferentes
contextos. No entanto, se eu lhe pedisse para defnir o que engenharia,
voc saberia me responder?
A Engenharia, segundo o Dicionrio Houaiss da lngua portu-
guesa, possui muitas defnies:
Aplicao de mtodos cientcos ou empricos utilizao 1.
dos recursos da natureza em benefcio do ser humano;
Formao, cincia e ofcio de engenheiro; 2.
O conjunto de atividades e funes de um engenheiro, 3.
que vo da concepo e do planejamento at a responsa-
bilidade pela construo e pelo controle dos equipamen-
tos de uma instalao tcnica ou industrial, etc.
Alm disso, vrias so as especialidades ou ramos da engenharia. Algu-
mas das mais comuns so a engenharia eltrica, a mecnica, a qumica,
a civil, a aeronutica, a ambiental, a de alimentos e ainda outras mais
curiosas, como engenharia txtil, de plsticos, de pesca, petroqumica,
robtica e de entretenimento.
INTRODUO ENGENHARIA DE
SOFTWARE
10
Mas e a Engenharia de Sofware, o que seria? Certamente, se voc um
iniciante na rea, possui esta e muitas outras dvidas, tais como: o que
um sofware, como ele produzido, se engenharia de sistemas e enge-
nharia de sofware so a mesma coisa e qual a diferena de engenharia
de sofware e cincia da computao (SOMMERVILLE, 2003).
A seguir, tentarei esclarecer essas dvidas.
1.1.1. O que software?
Quando voc pensa em sofware, o que vem a sua mente? Se voc res-
pondeu que sofware um programa de computador voc pensa como
a maioria das pessoas. No entanto, sofware no apenas um programa,
mas tambm toda a documentao associada e os dados de confgurao
necessrios para fazer com que esse programa opere de forma correta.
Um sistema de sofware geralmente consiste em uma srie programas
separados tais como:
os arquivos de congurao que so utilizados para congu-
rar esses programas;
a documentao do sistema, que descreve a estrutura des-
se sistema;
e a documentao do usurio, que explica como utilizar
o sistema.
No caso de produtos de sofware, h ainda sites web onde os usurios
podem fazer download de informaes referentes a esse produto.
H dois tipos de produtos de sofware:
Os 1. Produtos Genricos, que so sistemas do tipo stand-alone,
produzidos por uma organizao 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 eletrnicas, paco-
tes de desenho, ferramentas de gerenciamento de projetos, etc.
O termo stand-alone signica independente, isolado, autnomo.
Esse adjetivo descreve um dispositivo que no necessita do suporte
de outro dispositivo ou sistema, por exemplo, um computador que
no est conectado a uma rede.
Captulo 1
11
Produtos sob encomenda ou personalizados 2. , que so sistemas
encomendados por um cliente em particular e desenvolvidos
especialmente para esse cliente por uma empresa de desen-
volvimento de software. Uma diferena entre esse tipo de sof-
tware e os produtos genricos que, nos produtos genricos, a
especicao do software denida pela prpria organizao
que o desenvolve, ao contrrio dos produtos sob encomenda,
em que a especicao do software controlada pela prpria
organizao que est comprando o software.
Alm disso, Pressman (2006) nos apresenta sete tipos de categorias im-
portantes de sofware de computadores. So elas:
Software de Sistemas: 1. coleo de programas escritos para
servir a outros programas, como, por exemplo, os compilado-
res, editores e utilitrios para gesto de sistemas;
Software de Aplicao: 2. programa isolado que resolve uma
necessidade especca do negcio, tal como o processamento
de transaes no ponto de venda ou o controle do processo de
fabricao em tempo real;
Software Cientco e de Engenharia: 3. antigamente caracte-
rizado por algoritmos que processavam nmeros, atualmente
vo da astronomia vulcanologia, da anlise automotiva de
tenses dinmica orbital do nibus espacial e da biologia
molecular manufatura automatizada;
Software Embutido: 4. reside dentro de um produto ou sistema e
usado para implementar e controlar caractersticas e funes para
o usurio nal e para o prprio sistema. Como exemplo, pode-
mos citar os softwares desenvolvidos para aparelhos celulares;
Software para linhas de produtos: 5. projetado para fornecer
uma capacidade especca 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;
Aplicaes Web: 6. cobrem uma ampla variedade de aplica-
es, que podem ou no estar integradas a banco de dados de
empresas e s aplicaes do negcio. Aplicaes de comrcio
eletrnico so um exemplo de aplicaes web.
Software para Inteligncia Articial: 7. faz uso de algoritmos
no numricos para resolver problemas complexos que no
podem ser resolvidos pela computao ou anlise direta. Apli-
Introduo Engenharia de Software
12
caes nessa rea incluem robtica, sistemas especialistas, re-
conhecimento de padres de imagem e voz, jogos, etc.
1.1.2. O que engenharia de software?
A engenharia de sofware uma disciplina da engenharia que se preo-
cupa com todos os aspectos da produo de sofware, desde os estgios
iniciais de especifcao do sistema at a sua manuteno, aps esse sis-
tema entrar em funcionamento.
Em relao engenharia de software muito importante desta-
car que essa disciplina no se dedica simplesmente aos processos
tcnicos de desenvolvimento de software, mas tambm a ativi-
dades como o gerenciamento de projetos de software e o desen-
volvimento de ferramentas, mtodos e teorias que dem apoio
produo de software.
1.1.3. Qual a diferena entre engenharia de software,
engenharia de sistemas e engenharia de conhecimento?
A engenharia de sistemas uma disciplina mais antiga que a engenharia
de sofware. A engenharia de sistemas engloba todos os aspectos do de-
senvolvimento e da evoluo de sistemas complexos, em que o sofware
desempenha papel principal. Ou seja, a engenharia de sistemas preocu-
pa-se no s com o desenvolvimento de hardware, do projeto de polticas
e processos, da implantao de sistemas, mas tambm da engenharia de
sofware. Os engenheiros de sistema esto envolvidos na especifcao
do sistema, na defnio de sua arquitetura geral e tambm na integra-
o das diferentes partes necessrias para se criar um sistema completo,
e menos envolvidos com o hardware e o sofware. J os engenheiros de
sofware tm a responsabilidade direta de construir e manter um siste-
ma de sofware. Em relao engenharia de conhecimento, trata-se de
uma rea que tem a ver com os sistemas baseados em conhecimento e
suas aplicaes, em que se faz investigao fundamental de modelos de
representao de conhecimento e formas de raciocnio, estabelecimento
de mtodos de comparao, tanto do ponto de vista formal como do
experimental, desenvolvimento de sistemas baseados em conhecimento
e estudo das relaes entre sistemas e o processo ensino/aprendizagem.
Captulo 1
13
1.1.4. Qual a diferena entre engenharia de software e
cincia da computao?
A cincia da computao se preocupa com as teorias e mtodos bsicos
referentes aos computadores e a sistemas de sofware, enquanto a enge-
nharia de sofware se preocupa com os problemas prticos da produo
de sofware. Da mesma forma que a fsica pr-requisito para os enge-
nheiros eltricos, fundamental que os engenheiros de sofware tenham
algum conhecimento sobre a cincia da computao.
Atividades
Aps ler o tpico 1.1 responda:
1. Diferencie os conceitos de software, cincia da computao,
engenharia de sistemas e engenharia de software.
2. Fale um pouco sobre como um software produzido.
3. Quais so os dois tipos de produtos de software? Fale sobre
cada um desses tipos.
4. Cite as trs categorias de software que voc considera mais
importantes para nossa sociedade e justique suas escolhas.
1.2. Histrico da Engenharia de Software
O desenvolvimento de de sofware uma atividade de crescente impor-
tncia no dias de hoje. Os sistemas de sofware esto praticamente em
todos os lugares, e a utilizao dos computadores nas mais diversas re-
as do conhecimento tem gerado uma demanda cada vez mais crescente
por solues computadorizadas.
Para os iniciantes, muitas vezes o desenvolvimento de sofware confun-
dido com programao. Isso acontece porque geralmente comeamos
nesta rea resolvendo pequenos problemas que vo 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 programao no mais indicada. Na verdade, essa abordagem
aplicvel apenas para resolver pequenos problemas, tais como calcular
mdias, ordenar conjuntos de dados, etc. De fato, medida que os pro-
blemas vo se tornando mais complexos, uma abordagem de engenharia
14
necessria. E foi exatamente essa a motivao para o desenvolvimento
da disciplina de engenharia de sofware, ou seja, a engenharia de sofware
foi desenvolvida em resposta a problemas de construo de sistemas de
grande porte e personalizados, destinados a aplicaes industriais, gover-
namentais e para o setor de defesa (SOMMERVILLE, 2003).
Para compreendermos melhor a importncia da engenharia de sofware
na produo de sofware, vamos utilizar uma analogia feita por (FALBO,
2005), em que o autor compara a engenharia de sofware com a engenharia
civil. Por exemplo, para se construir uma casinha de cachorro, difcilmente
algum ir elaborar um projeto de engenharia civil, com plantas baixa, hi-
drulica e eltrica. Para resolver o problema, basta um bom pedreiro. Pode
ser que esse pedreiro no faa a melhor casinha de cachorro possvel, mas
certamente o produto resultante atender aos requisitos pr-estabelecidos.
No entanto, voc se arriscaria a investir todo o seu dinheiro, por exemplo,
na construo de um edifcio comercial sem ter feito um projeto? Para se
construir um edifcio fundamental realizar um estudo profundo, incluin-
do anlises de solo, clculos estruturais etc., seguido de um planejamento
da execuo da obra e desenvolvimento de modelos at a realizao da obra,
que deve ocorrer em etapas, tais como fundao, alvenaria, acabamento, en-
tre outras. Alm disso, importante realizar um acompanhamento da obra
para se verifcar prazos, custos e a qualidade do que se est construindo.
importante tambm destacar que a engenharia de sofware, alm de
ser desenvolvida em resposta a problemas de construo de sistemas
mais complexos, tambm visa melhoria da qualidade dos produtos de
sofware e ao aumento de produtividade no processo de desenvolvimen-
to de sofware. Alm disso, a engenharia de sofware tambm trata de
aspectos relacionados ao estabelecimento de processos, mtodos, tcni-
cas, ferramentas e ambientes de suporte produo de sofware.
1.3. Qualidade de Software
Na seo anterior vimos que um dos objetivos da engenharia de sofwa-
re melhorar a qualidade dos produtos de sofware desenvolvidos. Mas
voc saberia responder o que seria qualidade de sofware?
FALBO (2005) nos apresenta o conceito de qualidade como um conceito de
muitas facetas. Ou seja, para um usurio, um produto de sofware de boa quali-
dade deve satisfazer suas necessidades, sendo fcil de usar, efciente e confvel.
Para um desenvolvedor, um produto de boa qualidade deve ser fcil de manter.
Captulo 1
15
J para um cliente, o produto de sofware deve agregar valor a seu negcio. 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 sofware.
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 sofware depende fortemente da qualidade dos
processos usados para desenvolv-lo e mant-los. E essa a grande preocupa-
o da engenharia de sofware, produzir sofware de qualidade!
Seguindo uma tendncia de outros setores, a qualidade do processo de
sofware tem sido apontada como parte fundamental para a obteno da
qualidade do produto. Como veremos com mais detalhes nos captulos
frente, abordagens de qualidade de processo, tal como a srie de padres
ISO 9000, sugerem que, melhorando a qualidade do processo de sofware,
possvel melhorar a qualidade dos produtos resultantes. Ou seja, a idia por
trs disso que, uma vez que se tenham processos bem estabelecidos, que
incorporem mecanismos sistemticos 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 sofware no captulo 3).
Vale destacar que um processo de sofware em uma abordagem de en-
genharia de sofware envolve diferentes atividades que podem ser clas-
sifcadas quanto ao seu propsito como(FALBO, 2005):
Atividades de Desenvolvimento (ou Tcnicas ou de Cons- t
truo): so as atividades diretamente relacionadas ao proces-
so de desenvolvimento do sofware, ou seja, que contribuem
diretamente para o desenvolvimento do produto de sofware a
ser entregue ao cliente. So exemplos de atividades de desen-
volvimento: especifcao e anlise de requisitos, projeto de
sistema, implementao e testes, entrega e manuteno. Essas
atividades sero discutidas no captulo 5;
Atividades de Gerncia de Projeto: t so aquelas relacionadas
ao planejamento e acompanhamento gerencial do projeto, tais
como realizao de estimativas, elaborao de cronogramas,
anlise dos riscos do projeto, etc. Falaremos de gerenciamento
de projeto no captulo 6;
Atividades de Garantia da Qualidade: t so as relacionadas
com a garantia da qualidade do produto em desenvolvimen-
to e do processo de sofware utilizado, tais como revises e
inspees de produtos (intermedirios ou fnais) do desen-
volvimento. Assuntos relacionados garantia de qualidade de
sofware sero discutidos no captulo 8.
16
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 so realizadas segundo
uma ordem estabelecida no planejamento.
J as atividades de gerncia e de controle da qualidade so muitas vezes con-
sideradas atividades de apoio, pois no esto ligadas diretamente construo
do produto fnal. Essas atividades so normalmente realizadas ao longo de
todo o ciclo de vida do sofware, sempre que necessrio ou em pontos pr-
estabelecidos durante o planejamento, ditos marcos ou pontos de controle.
Atividades
Aps ler os itens 1.2 e 1.3 responda:
Por que importante que um software tenha qualidade? 1.
Quais so as atividades que geralmente esto envolvidas no 2.
processo de software?
(1) ALBO, R.A., Notas de Aula: Engenharia de Sofware. Dispo-
nvel em http://www.inf.ufes.br/~falbo, 2005.
(2) PRESSMAN, R.S., Engenharia de Sofware. So Paulo: Mc-
Graw-Hill, 6 Edio, 2006.
(3) SOMMERVILE, I. Engenharia de Sofware. So Paulo: Pear-
son Addison Wesley, 6 edio, 2003.
Captulo 1
17

___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
18
Captulo 1
19
Prezado aluno,
Agora que voc j tem uma viso geral da engenharia de software,
neste captulo estudaremos o software como um produto, alm de
discutirmos sobre o processo de desenvolvimento de um software.
Bom estudo!
2.1. O Software como Produto
O sofware de computador o produto que os profssionais, ou seja, os
engenheiros de sofware, constroem e depois mantm ao longo do tem-
po para que pessoas de todo o mundo o usem, direta ou indiretamente.
Como dissemos anteriormente, o sofware abrange programas que po-
dem executar em diferentes computadores, com diferentes tecnologias.
Mas por que o sofware um produto to 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
indstria, no comrcio, na nossa cultura e em nossas atividades dirias.
Tempos atrs quem poderia prever que o sofware estaria embutido em
sistemas de toda espcie, tais como de transporte, mdico, de telecomuni-
caes, militar, industrial, de entretenimento, etc? Vrios intelectuais tm
procurado mostrar a importncia do sofware para a sociedade:
Osborn, t em 1979, caracterizou a criao do sofware como
uma nova revoluo industrial;
Tofer, t em 1980, chamou o advento da microeletrnica de
terceira onda de mudana da histria da humanidade;
Naisbitt, t em 1982, previu a transformao da sociedade in-
dustrial em uma sociedade da informao;
Feigenbaum e McCorduck, t em 1983, sugeriram que o poder
do sculo XXI estaria na informao e no conhecimento;
Por fm, t Stoll, em 1989, ponderou que o que ele chamou de
comunidade eletrnica, criada por redes e sofwares, seria a
chave para a troca de conhecimento em todo o mundo.
CARACTERSTICAS DO
SOFTWARE
20
Um outro aspecto importante do produto de software que, inde-
pendentemente de seu tamanho, complexidade ou domnio de apli-
cao, ele evoluiu com o tempo, como podemos observar nas fases
ou eras descritas a seguir:
Antigamente (at meados dos anos 60). t Sistemas batch,
pouca distribuio, software sob medida para computado-
res especficos. O software visto apenas como um coadju-
vante da indstria de hardware. O hardware era muito mais
caro do que o software;
Segunda era (at o meio dos anos 70). t Sistemas multiusurio,
tempo real, bancos de dados, o sofware comea a ser visto
como um produto;
Terceira era (at o fnal dos anos 80 t ). Sistemas distribudos,
sistemas inteligentes, hardware barato;
Quarta era (do fnal dos anos 80 at os dias de hoje). t Os sis-
temas passam a ter interfaces muito amigveis com o usurio;
surgem as redes de computadores; os sistemas orientados a
objetos; os sistemas especialistas, as redes neurais e os algorit-
mos genticos; a programao paralela; a Internet, o Cybers-
pace e a information superhighway.
O Cyberspace, tambm conhecido como ciberespao, um espao
de comunicao que descarta a necessidade do homem fsico para
constituir a comunicao como fonte de relacionamento, dando
nfase ao ato da imaginao, necessria para a criao de uma ima-
gem annima, que ter comunho com os demais.
Apesar de a internet ser o principal ambiente do ciberespao, devi-
do a sua popularizao e sua natureza de hipertexto, o ciberespao
tambm pode ocorrer na relao do homem com outras tecnolo-
gias: celular, pagers, comunicao entre rdio-amadores e por ser-
vios do tipo tele-amigos, por exemplo. (JUNGBLUT, 2004; GUI-
MARES JR., 1999).
Tambm conhecido como Cyberespao, termo muito comum na
fco cientfca, possui variaes para vrias outras denominaes
referente Internet, Cyberpoeta, Cyberpunk e outros mais.
J information superhighway foi um termo popular usado na dca-
da de 90 para fazer referncia aos sistemas de comunicao digital.
Fonte: Wikipdia
Captulo 2
21
Existem muitas questes que demonstram a preocupao da indstria
com o sofware e com a maneira como ele desenvolvido. O tempo
necessrio para se desenvolver um sofware, os altos custos de desen-
volvimento de um sofware, a difculdade de corrigir todos os erros de
um sofware ao entreg-lo ao cliente, a manuteno de um sofware que
requer tempo e esforo e a difculdade em avaliar todo o processo de
desenvolvimento do sofware so algumas dessas questes.
Atividades
Pesquise na Internet, ou em outras fontes de pesquisa que voc
achar interessante, sobre os seguintes conceitos:
Sistemas batch. 1.
Sistemas monousurio e multiusurio. 2.
Sistemas distribudos e programao paralela. 3.
Sistemas inteligentes, sistemas especialistas, redes neurais e 4.
algoritmos genricos.
2.1.1. Caractersticas de um Software
Na nossa sociedade, existe uma infnidade de produtos que so produ-
zidos todos os dias, com as mais diferentes fnalidades. Os produtos vo
desde um po francs, uma roupa ou calado, um brinquedo, at um
carro ou navio. Mas o que torna um sofware um produto to diferen-
ciado? Observe suas caractersticas, descritas a seguir, e tente chegar a
uma concluso:
O sofware no fabricado no sentido clssico da palavra. O sof- 1.
tware desenvolvido: se voc pensar na fabricao de um hardwa-
re qualquer como, por exemplo, uma impressora, ou no desen-
volvimento de um sofware qualquer como um editor de texto,
ver que, apesar de existirem algumas semelhanas entre estas
duas produes, elas so duas atividades fundamentalmente di-
ferentes. Caso haja um bom projeto, ambas as atividades geraro
produtos de qualidade. No entanto, a fabricao de um hardware
pode gerar problemas de qualidade que poderiam ser corrigidos
facilmente em um sofware, ou at mesmo nem existirem nesse
caso. Alm disso, ambas as atividades envolvem pessoas (embora
a relao entre as pessoas envolvidas e o trabalho realizado seja
Caractersticas do Software
22
diferente) e requerem a construo de um produto (embora
com abordagens diferentes). Alm disso, uma diferena impor-
tante entre a fabricao de um sofware e a de um hardware est
relacionada ao custo desses dois tipos de produto. Os projetos de
sofware no podem ser geridos como se fossem projetos de fa-
bricao simplesmente, pelo fato dos custos do sofware serem
concentrados na engenharia de sofware. Isso faz com que o cus-
to do desenvolvimento de sofware seja muito maior do que o
custo da fabricao de um hardware.
O sofware no se desgasta: 2. voc j teve que trocar sua impres-
sora, comprar um mouse novo, trocar seu modem por um mais
moderno ou trocar alguma pea quebrada ou deteriorada de seu
computador? Se voc possui um computador pessoal, certamen-
te sim. Mas e o sofware? Precisamos troc-lo de vez em quan-
do por que ele quebrou? Embora no tenhamos essa relao
de desgaste ou de quebra, o sofware tem uma outra caracters-
tica muito particular, o sofware torna-se obsoleto. Basta lembrar
quantas vezes voc teve que atualizar seu sistema operacional ou
um pacote de ferramentas como o Microsof Ofce ou o Open
Ofce. Alm disso, quando um hardware se desgasta, ele tem que
ser substitudo por um outro, ou ser feita uma troca de peas. J
com o sofware isso no acontece. No h peas sobressalentes
para um sofware. Isso signifca que toda falha de sofware gera-
da por um erro de projeto. Isso faz com que a manuteno de um
sofware seja consideravelmente muito mais complexa do que a
manuteno de um hardware qualquer.
A maioria dos sofwares ainda continua a ser desenvolvida sob en- 3.
comenda, e no como um produto genrico: se voc fosse comprar
uma simples garrafa trmica, 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 disponveis? Em geral, quando
compramos um produto qualquer, no isso que acontece. Ou seja, os
produtos so fabricados em larga escala e de forma padronizada. Na
fabricao de um hardware, por exemplo, existem diversos componen-
tes reutilizveis que foram criados para que os engenheiros se concen-
trassem nos elementos realmente inovadores de um novo projeto. Em
relao ao desenvolvimento de sofware, embora possa haver reusabili-
dade, de forma geral, o sofware desenvolvido de forma customizada
e no montado a partir de partes. Nos anos 60 preconizava-se que as bi-
bliotecas de sofware permitiriam reuso intenso de cdigo. Atualmente,
embora a reusabilidade seja totalmente desejvel, as perspectivas para
que isso acontea so muito mais discretas.
Captulo 2
23
2.1.2. Mitos do Software
Um mito uma crena, uma construo mental de algo idealizado; no
entanto, sem comprovao prtica. Existem muitos mitos quando se
trata de sofware, mitos tanto da gerncia responsvel pelo sofware, dos
clientes que o compram ou encomendam, quanto dos profssionais que
o desenvolvem. Sendo voc um iniciante ou no na disciplina de en-
genharia de sofware, importante ter cincia desses mitos, que esto
descritos em Pressman (2006):
Mitos da Gerncia
Os gerentes com responsabilidade sobre um sofware geralmente trabalham
sob presso para obedecer a oramentos, cumprir cronogramas e melhorar
a qualidade desse sofware. A fm de diminuir a presso, pelo menos
temporariamente, eles se agarram aos seguintes mitos:
Mito: J temos um livro que est cheio de padres e procedimentos para elaborar
o sofware. Isso no fornece ao meu pessoal tudo o que o eles precisam saber.
Realidade: O livro de padres pode at existir, mas ser que ele usado?
Os profssionais de sofware sabem de sua existncia? Ele refete as prticas
modernas da engenharia de sofware? Ele completo? adaptvel? 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 fcar em dia.
Realidade: Esse tipo de pensamento um grande erro, pois o processo de
desenvolvimento de sofware no um processo mecanizado como o de um
hardware, por exemplo. Como citado por Brooks (1975), Adicionar pessoas a
um projeto de sofware atrasado atrasa-o mais ainda. No podemos esquecer que
sempre que novas pessoas so adicionadas a um projeto, a equipe j constituda
precisa gastar tempo orientando os novatos, o que reduz a quantidade de tempo
investida no desenvolvimento produtivo. Isso NO quer dizer que pessoas no
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 organizao no sabe como gerir e controlar projetos de
sofware internamente, certamente ter problemas na terceirizao de seus
projetos.
24
Mitos do Cliente
Um cliente pode ser uma pessoa ou empresa que encomendou um sofware,
geralmente sob contrato. Frequentemente, os clientes acreditam em certos mitos
por falta de informaes mais precisas sobre o desenvolvimento do sofware
por parte dos gerentes ou profssionais de sofware. Isso pode levar a falsas
expectativas e insatisfao do cliente.
Mito: Estabelecer um objetivo geral para um projeto de sofware sufciente para
iniciar o seu desenvolvimento podemos fornecer os detalhes posteriormente.
Realidade: uma das principais causas do fracasso de um projeto de sofware
ter uma defnio inicial mal feita. Num projeto de sofware, fazer uma
descrio formal e detalhada do domnio da informao, das funcionalidades,
do comportamento, do desempenho das interfaces, das restries do projeto
e dos critrios de validao algo essencial. E isso s possvel por meio de
intensa comunicao entre os envolvidos no projeto (stakeholders).
OBS: comum encontrar o termo stakeholder quando se faz
referncia aos envolvidos em um projeto de software. Stakeholder ou,
em Portugus, 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 mudanas
podem ser facilmente adaptadas porque o processo de desenvolvimento de
sofware fexvel.
Realidade: Outro erro muito comum. Na verdade, os requisitos de sofware
mudam, mas o impacto dessas mudanas pode variar muito, dependendo
de quando elas acontecem. Por exemplo, quando uma mudana solicitada
antecipadamente, quando o projeto ou mesmo a codifcao do sofware ainda
no tenha comeado, 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 mudanas podem causar consequncias que
exijam recursos adicionais e grandes modifcaes no projeto.
OBS: Um requisito defnido como uma condio ou uma capacidade
com a qual o sistema deve estar de acordo. Fonte: http://www.wthreex.com/
rup/process/workfow/requirem/co_req.htm
Captulo 2
25
Mitos do Profssional
Os mitos entre os profssionais de sofware que sero apresentados a seguir
existem desde os primrdios da programao, persistindo at hoje.
Mito: Quando escrevemos um programa e o fazemos funcionar, nosso trabalho
est completo.
Realidade: Dados da indstria indicam que entre 60% e 80% de todo o
esforo despendido em sofware vai acontecer depois de o sofware ter sido
entregue ao cliente pela primeira vez, pois quando o cliente usa o sofware
que ele percebe suas falhas, e quais de suas necessidades que no foram
atendidas por esse programa.
Mito: At que eu esteja com o programa rodando no tenho como avaliar a
sua qualidade.
Realidade: Um dos mecanismos mais efcazes de garantia de qualidade de um
sofware pode ser aplicado logo no incio de um projeto a reviso tcnica
formal. Revises de sofware so um fltro de qualidade que se descobriu ser
mais efcaz do que testes para encontrar alguns tipos de erros de sofware.
Mito: O nico produto de trabalho que pode ser entregue para um projeto de
sofware bem-sucedido o programa executvel.
Realidade: Um programa executvel apenas um dos elementos
produzidos em um projeto de software. A documentao fornece a base
para uma engenharia bem-sucedida e funciona como uma orientao
para o suporte ao software.
Mito: A engenharia de software vai nos fazer criar documentao volumosa
e desnecessria que far atrasar o projeto.
Realidade: A engenharia de sofware tem a ver com a criao de qualidade,
e no somente com a criao de documentos. Uma melhor qualidade leva
reduo de trabalho e retrabalho. Reduzir (re)trabalho resulta em tempos de
entrega mais rpidos.
Uma Reviso Tcnica Formal uma atividade de garantia da
qualidade de sofware realizada por engenheiros de sofware. Seus
objetivos so:
Descobrir erros de funcionalidade, lgica ou implemen- 1.
tao para qualquer representao do sofware;
Verifcar se o sofware sob reviso satisfaz seus 2.
requisitos;
Garantir que o sofware tenha sido representado de 3.
acordo com padres pr-defnidos;
Conseguir que o sofware seja desenvolvido de modo 4.
uniforme;
Tornar os projetos mais administrveis. 5.
Fonte: Pressman, 2006.
26
importante que voc tenha em mente que todo projeto de sofwa-
re se inicia baseado em alguma necessidade de negcio. Sem um
problema para se resolver no h projeto de sofware! Essa necessi-
dade pode ser criar um novo produto, servio ou sistema, adaptar
um sistema legado a alguma necessidade em particular, corrigir um
defeito de uma aplicao existente ou estender as funcionalidades
dessa aplicao, entre outras. Ao iniciar um projeto de sofware, a
necessidade do negcio muitas vezes expressa informalmente. Mas
com o passar do tempo voc vai ver que a engenharia de sofware
vai fornecer toda uma estrutura para que seja desenvolvido um sof-
tware de qualidade que atenda a essa necessidade de negcio.
Sistema Legado o termo utilizado em referncia aos sistemas
computacionais de uma organizao que, apesar de serem bastan-
te antigos, fornecem servios essenciais.
Fonte: Wikipdia.
Atividades
Descreva as caractersticas de um sofware que o tornam dife- 1.
rente dos demais produtos que voc conhece.
Fale sobre pelo menos um mito da gerncia, do cliente e do 2.
profssional.
Baseado no que voc leu at aqui, fale da importncia da 3.
engenharia de sofware para a construo de sofware com
qualidade.
(1) FALBO, R.A., Notas de Aula: Engenharia de Sofware. Dispo-
(2) RAPCHAN, F., Notas de Aula: Engenharia de Sofware.
Captulo 2
27

___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
28
Captulo 2
29
Mtodos e Estratgias de Estudo
Prezado aluno,
Neste captulo apresentarei a diferena entre engenharia de sofwa-
re e processo de desenvolvimento de sofware, dando detalhes sobre
o processo de desenvolvimento de um sofware, apresentando ativi-
dades principais e atividades de apoio ao processo de sofware.
Bom estudo!
3.1. Uma viso genrica de processo
O Dicionrio Houaiss da lngua portuguesa nos d vrias defnies in-
teressantes do que seja um processo. Eis algumas delas:
Ao continuada, realizao contnua e prolongada de algu- 1.
ma atividade; seguimento, curso, decurso;
Seqncia contnua de fatos ou operaes que apresentam 2.
certa unidade ou que se reproduzem com certa regularidade;
andamento, desenvolvimento, marcha;
Modo de fazer alguma coisa; mtodo, maneira, 3.
procedimento.
Mas numa linguagem tcnica, o que seria um processo de desenvol-
vimento de sofware? Segundo Pressman (2006), um processo de de-
senvolvimento de sofware um arcabouo para as tarefas necessrias
para a construo de um sofware de qualidade. Numa linguagem bem
simples, o processo de sofware um roteiro que voc cria e segue com
o objetivo de desenvolver um produto de qualidade. Mas ser que enge-
nharia de sofware e processo de sofware so a mesma coisa? Embora
a diferena seja sutil, ela existe. Ou seja, um processo de sofware defne
uma abordagem que adotada quando o sofware elaborado. Mas a
engenharia de sofware tambm inclui tecnologias que constituem um
processo, tais como mtodos tcnicos e ferramentas automatizadas.
PROCESSOS DE SOFTWARE
30
3.2. Processo de Software x Engenharia de
Software
At aqui temos falado um pouco sobre engenharia de sofware. Mas
chegou a hora de defnirmos o termo. Embora muitos autores tenham
defnies pessoais do termo, vamos utilizar a defnio proposta por
Fritz Bauer (apud Pressman, 2006), que diz que:
Engenharia de Sofware a criao e a utilizao de slidos princ-
pios de engenharia a fm de obter sofwares econmicos que sejam
confveis e que trabalhem efcientemente em mquinas reais.
Essa defnio foi dada em 1969 na primeira conferncia sobre o assun-
to e est longe de ser uma defnio completa e satisfatria. H muitos
aspectos no contemplados nessa defnio, tais como os aspectos tc-
nicos da qualidade do sofware, a necessidade de satisfao do ciente
ou a importncia de um processo e de medidas e unidades. Mas o IEEE
(Institute of Electrical and Electronic Engineers) em 1993 nos deu uma
defnio mais apurada do termo que diz que:
Engenharia de Sofware (1) aplicao de uma abordagem siste-
mtica, disciplinada e quantifcvel para o desenvolvimento, ope-
rao e manuteno do sofware; isto , a aplicao da engenharia
ao sofware. (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
criao, desenvolvimento, integrao, compartilhamento e o conheci-
mento aplicado no que se refere cincia e tecnologias da eletricidade
e da informao, em benefcio da humanidade e da profsso. O IEEE
foi criado em 1884, nos E.U.A. e uma sociedade tcnico-profssional
internacional, dedicada ao avano da teoria e prtica da engenharia
nos campos da eletricidade, eletrnica e computao. Congrega mais
de 312.000 associados, entre engenheiros, cientistas, pesquisadores e
outros profssionais, em cerca de 150 pases.
Se voc deseja conhecer um pouco mais sobre o IEEE, consulte o
site http://www.ieee.org.
Captulo 3
31
A Engenharia de Sofware pode ser considerada uma tecnologia em ca-
madas (Pressman, 2006). Essas camadas compreendem o foco na qua-
lidade, o processo, os mtodos e as ferramentas. Novamente vemos a
relao entre processo de sofware e engenharia de sofware. Nesta def-
nio podemos ver que o processo parte de um todo chamado engenha-
ria de sofware. 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 sofware, deve ter um compromisso com a qualidade. O
foco na qualidade deve ser a base da engenharia de sofware.
2) Processo: essa camada deve ser o alicerce da engenharia de sofware.
O processo, como j foi dito, deve ser um arcabouo estabelecido para a
efetiva utilizao da tecnologia de engenharia de sofware. Alm disso,
essa camada que mantm as outras unidas e permite o desenvolvimen-
to racional e adequado de sofwares.
3) Mtodos: os mtodos fornecem a tcnica para se desenvolver sof-
tware de qualidade. Constituem um conjunto de tarefas que incluem
comunicao, anlise de requisitos, modelagem de projeto, construo
de programas, testes e manuteno.
4) Ferramentas: as ferramentas fornecem apoio automatizado para o
processo de sofware e os mtodos.
Alm desses processos, uma parte signifcativa do trabalho da engenharia de
sofware pode ser agrupada nas seguintes fases genricas:
1) Defnio: seu foco est no que ser desenvolvido. Compreende
trs tarefas principais:
Engenharia do sistema; t
Plano de projeto do sofware ( t sofware project planning);
Anlise dos requisitos do sistema. t
Processos de Software
32
2) Desenvolvimento: seu foco est em como o sofware ser desenvol-
vido. Ou seja, como os dados sero estruturados e como as funes se-
ro implementadas? Como as interfaces sero caracterizadas? Como o
projeto ser traduzido em uma linguagem de programao? Como os
testes sero feitos? Etc. Compreende trs tarefas principais:
Projeto do sofware; t
Gerao de cdigo; t
Testes. t
3) Manuteno: a fase da correo de erros. H quatro tipos princi-
pais de manuteno:
Corretiva; t
Adaptativa; t
Evolutiva; t
Preventiva (reengenharia). t
3.3. O que um Processo de Software
Ns vimos at aqui vrias defnies de engenharia de sofware, e que
nenhuma deles consegue descrever com preciso o que seja essa disci-
plina. Alm disso, vimos tambm que o processo de desenvolvimento
de sofware pode ser considerado como uma das camadas da engenha-
ria de sofware, se a consideramos uma tecnologia em camadas. Nesta
seo, defniremos o que um processo de sofware, apresentando seus
principais elementos.
Segundo Falbo (2005), Um processo de sofware pode ser visto como o
conjunto de atividades, mtodos, prticas e transformaes que guiam
pessoas na produo de sofware. Um processo efcaz deve, claramente,
considerar as relaes entre as atividades, os artefatos produzidos no
desenvolvimento, as ferramentas e os procedimentos necessrios e a ha-
bilidade, o treinamento e a motivao do pessoal envolvido.
Alm disso, os processos de sofware so, geralmente, decompostos em
diversas fases, etapas ou atividades (Falbo, 2005). So elas:
Captulo 3
33
1) Planejamento: o objetivo desta atividade fornecer uma estrutura
que possibilite ao gerente fazer estimativas razoveis de recursos, custos
e prazos. Uma vez estabelecido o escopo de sofware, com os requisitos
esboados, uma proposta de desenvolvimento deve ser elaborada, isto
, um plano de projeto deve ser elaborado confgurando o processo a
ser utilizado no desenvolvimento de sofware. medida que o projeto
progride, o planejamento deve ser detalhado e atualizado regularmente.
Pelo menos ao fnal de cada uma das fases do desenvolvimento (anlise
e especifcao de requisitos, projeto, implementao 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 gerncia de projeto.
2) Anlise e Especifcao de Requisitos: Nesta atividade, o processo
de levantamento de requisitos intensifcado. O escopo deve ser refna-
do e os requisitos melhor defnidos. Para entender a natureza do sofwa-
re a ser construdo, o engenheiro de sofware tem que compreender o
domnio 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 construo de um modelo descrevendo o que o
sofware tem que fazer (e no como faz-lo).
3) Projeto: Esta atividade responsvel por incorporar requisitos tec-
nolgicos aos requisitos essenciais do sistema, modelados na ativida-
de anterior e, portanto, requer que a plataforma de implementao 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 defnir a arquitetura geral
do sofware, tendo por base o modelo construdo na fase de anlise de
requisitos. Essa arquitetura deve descrever a estrutura de nvel mais alto
da aplicao e identifcar seus principais componentes. J o objetivo da
etapa de projeto detalhado detalhar o projeto do sofware para cada
componente identifcado na etapa anterior. Os componentes de sofwa-
re devem ser sucessivamente refnados em nveis maiores de detalha-
mento, at que possam ser codifcados e testados.
4) Implementao: Nesta atividade o projeto deve ser traduzido para
uma forma passvel de execuo pela mquina. A atividade de imple-
mentao realiza essa tarefa, isto , cada unidade de sofware do projeto
detalhado implementada.
5) Testes: esta atividade inclui diversos nveis de testes, a saber, teste
de unidade, teste de integrao e teste de sistema. Inicialmente, cada
unidade de sofware implementada deve ser testada e os resultados do-
cumentados. A seguir, os diversos componentes devem ser integrados
34
sucessivamente at se obter o sistema. Finalmente, o sistema como um
todo deve ser testado.
6) Entrega e Implantao: uma vez testado, o sofware deve ser coloca-
do em produo. Para que isso acontea, contudo, necessrio treinar os
usurios, confgurar o ambiente de produo e, muitas vezes, converter
bases de dados. O propsito desta atividade estabelecer que o sofware
satisfaa os requisitos dos usurios. Isso feito instalando o sofware no
ambiente do usurio e conduzindo testes de aceitao. Quando o sofware
tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e
a operao (prxima etapa) iniciada.
7) Operao: nesta atividade o sofware utilizado pelos usurios no
ambiente de produo.
8) Manuteno: Sem dvida, o sofware sofrer mudanas aps ter sido en-
tregue para o usurio. Alteraes ocorrero por diversos motivos: porque
erros foram encontrados, porque o sofware precisa ser adaptado para aco-
modar mudanas 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 manuteno necessria, essa atividade pode
requerer a defnio de um novo processo, em que cada uma das fases prece-
dentes re-aplicada no contexto de um sofware existente, ao invs de iniciar
um processo de criao de um novo sofware.
As atividades descritas acima so as atividades principais de um
processo de software. No entanto, existe uma srie 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 importncia
(Pressman, 2006). So elas:
1) Acompanhamento e controle do projeto de sofware: permi-
te equipe de sofware avaliar o progresso com base no plano de
projeto e tomar a ao necessria para manter o cronograma;
2) Gesto de risco: avalia os riscos que podem afetar o resultado
do projeto ou a qualidade do produto;
3) Garantia da qualidade: defne e conduz as atividades necess-
rias para garantir a qualidade do sofware;
4) Revises Tcnicas Formais: avaliam os produtos de trabalho da
engenharia de sofware, num esforo para descobrir e remover erros
antes que eles sejam propagados para a prxima ao ou atividade;
5) Medio: defne e rene medidas de processo, projeto e pro-
duto que ajudam a equipe a entregar um sofware que satisfaa s
necessidades do usurio; pode ser realizada de forma conjugada
com todas as outras atividades principais;
Captulo 3
35
6) Gesto de confgurao de sofware: gerencia os efeitos das
modifcaes ao longo de todo o processo de sofware;
7) Gesto de reusabilidade: defne critrios para a reutilizao
dos produtos de trabalho (inclusive componentes de sofware) e
estabelece mecanismos para obter componentes reusveis. (Um
produto de trabalho produzido ao fnal de uma atividade do
processo de sofware);
8) Preparao e produo do produto de trabalho: abrange as
atividades necessrias para criar produtos de trabalho como mo-
delos, documentos, registros, formulrios e listas.
Finalizando, um processo de sofware o conjunto total de atividades
de engenharia de sofware necessrias para transformar requisitos do
usurio em sofware (Managing the Process, Humphrey, 1989), ou seja,
um conjunto de atividades realizadas por pessoas cujo objetivo o de-
senvolvimento ou a evoluo de um sofware e sua documentao.
Figura 3-2: Processo de Desenvolvimento de Software
3.4. Definio de Processos
Um processo de sofware no pode ser defnido de uma maneira univer-
sal. Para ser efcaz e conduzir construo de produtos de boa qualida-
de, cada processo de sofware deve ser adequado s especifcidades do
projeto em questo, tais como as caractersticas da aplicao (domnio
do problema, tamanho, complexidade etc), a tecnologia a ser adotada na
sua construo (paradigma de desenvolvimento, linguagem de progra-
mao, mecanismo de persistncia, etc), a organizao em que o produ-
to ser desenvolvido e a equipe de desenvolvimento, etc.
Muitos aspectos devem ser considerados na defnio de um processo
de sofware. Como descrito no item 3.3., um processo de sofware pos-
sui atividades principais, tais como: anlise e especifcao de requisitos,
projeto, implementao e testes, que so a base sobre a qual o processo
de desenvolvimento deve ser construdo. Entretanto, a defnio de um
processo envolve outros fatores tais como a escolha de um modelo de
36
ciclo de vida (ou modelo de processo), que veremos no captulo 4, o
detalhamento (decomposio) de suas macro-atividades, a escolha de
mtodos, tcnicas e roteiros (procedimentos) para a sua realizao e a
defnio de recursos e artefatos necessrios e produzidos.
Atividades
1) Faa um paralelo entre os conceitos de engenharia de sofware
e de processo de sofware.
2) A engenharia de software pode ser considerada uma tecno-
logia em camadas. Diante dessa afirmao, 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.
Captulo 3
37

___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
38
Captulo 3
39
Prezado aluno,
Neste captulo 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 Seqencial, Modelo Incremental, Mo-
delo Espiral e Modelo de Prototipagem. Neste captulo tambm
sero apresentados as principais atividades e documentos tpicos
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 sofware consiste em uma sequncia de diferentes ativi-
dades que so executadas durante o desenvolvimento desse sofware. Durante
o desenvolvimento dessas atividades, diversos artefatos so produzidos. Um
artefato um produto de trabalho, que pode ser um modelo, documento ou
cdigo-fonte produzido por uma atividade, entre outros. Geralmente, as ati-
vidades e os artefatos esto diretamente relacionados. Alm disso, o ciclo de
desenvolvimento de um sofware marcado pelo que chamados de marcos,
que so eventos que podem ser usados para defnir o status de um projeto.
Por exemplo, o evento de completar o manual do usurio pode ser um marco.
Os marcos so essenciais para fns de gerenciamento porque o trmino de
um marco permite ao gerente identifcar o progresso do desenvolvimento do
sofware. Gustafson (2003) apresenta uma lista com os Tipos de Atividades
do Ciclo de Vida e Documentos Tpicos, listados a seguir:
Atividade Objetivo
Viabilidade
Determina se o desenvolvimento
proposto vivel.
Anlise de mercado
Determina se existe mercado potencial
para esse produto.
Requisitos
Determinam quais as funcionalidades o
sofware deve ter.
Elucidao de Requisitos Obtm dos requisitos do usurio.
MODELOS DE CICLO DE VIDA
40
Anlise de Domnio
Determina quais tarefas e estruturas
so comuns ao problema.
Planejamento do Projeto Determina como desenvolver o sofware.
Anlise de Custos Determina a estimativa dos custos.
Cronograma
Constri o cronograma para o
desenvolvimento.
Garantia da Qualidade de
Sofware
Determina atividades que iro ajudar a
garantir a qualidade do produto.
Projeto
Determina como o sofware dever
prover as funcionalidades.
Projeto Arquitetural Projeta a estrutura do sistema.
Projeto de Interface
Especifca as interfaces entre as partes
do sistema.
Projeto Detalhado Projeta os algoritmos para cada parte.
Implementao Construo do sofware.
Teste
Execuo do sofware com dados
para ajudar a garantir que o sofware
funcione corretamente.
Teste de Unidade
Teste do desenvolvedor original que
focaliza o esforo de verifcao na
menor unidade de projeto do sofware.
Teste de Integrao Teste durante a integrao do sofware.
Teste do Sistema
Teste do sofware em um ambiente
semelhante ao ambiente operacional.
Teste Alpha
Teste pelo cliente no ambiente do
desenvolvedor.
Teste Beta
Teste pelo cliente em seu ambiente
operacional.
Teste de Aceitao Teste para satisfazer o cliente.
Teste de Regresso
Teste de armazenamento da verso
anterior para garantir que a nova
verso possui todas as capacidades
anteriores.
Entrega
Prov o cliente com uma soluo de
sofware efciente.
Instalao
Torna o sofware disponvel no
ambiente operacional do cliente.
Treinamento Capacita o usurio a operar o sofware.
Help Desk
Responde a questes (dvidas) dos
usurios.
Manuteno
Atualizao e evoluo do sofware
para garantir usabilidade constante.
Tabela 4.1 - Atividades do ciclo de Vida do software
Atividade Objetivo
Captulo 4
41
Atividade Objetivo
Contrato de Trabalho
Descrio preliminar das
funcionalidades desejadas, geralmente
produzidas pelo usurio.
Especifcao dos
Requisitos de Sofware
Descreve o que o sofware fnal ir
fazer.
Modelo de Objetos
Apresenta as classes e os objetos
principais.
Diagramas de Casos de
Uso
Mostram a sequncia de possveis
comportamentos do ponto de vista do
usurio.
Cronograma do Projeto
Descreve a ordem das tarefas e
as estimativas de tempo e esforo
necessrios.
Plano de Teste do
Sofware
Descreve como o sofware ser testado
para garantir o comportamento
apropriado.
Testes de Aceitao
Testes elaborados pelo cliente para
determinar a aceitabilidade do sistema.
Projeto de Sofware Descreve a estrutura do sofware.
Projeto Arquitetural
Estrutura de alto nvel com as
interconexes.
Projeto Detalhado
Projeto de baixo nvel dos mdulos ou
objetos.
Plano de Garantia da
qualidade do sofware
(SQA)
Descreve as atividades que sero
desenvolvidas para garantir a
qualidade.
Manual do Usurio Descreve como usar o sofware pronto.
Cdigo Fonte O cdigo fonte do produto atual.
Relatrio de Teste
Descreve como os testes foram feitos e
como o sistema se comportou.
Relatrio de Falhas
Descreve as insatisfaes do cliente
com os comportamentos especfcos
do sistema, geralmente suas falhas ou
erros.
Tabela 4.2 Documentos Tpicos
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 representao abstrata de um esqueleto de pro-
cesso, incluindo tipicamente algumas atividades principais, a ordem de
precedncia entre elas e, opcionalmente, artefatos requeridos e produzidos.
De maneira geral, um modelo de processo descreve uma filosofia de orga-
Modelos de Ciclo de Vida
42
nizao de atividades, estruturando as atividades do processo em fases e
definindo como essas fases esto relacionadas. Entretanto, ele no descreve
um curso de aes preciso, recursos, procedimentos e restries. Ou seja,
ele um importante ponto de partida para definir como o projeto deve ser
conduzido, mas a sua adoo no o suficiente para guiar e controlar um
projeto de software na prtica. Ou seja, a escolha de um modelo de ciclo de
vida (ou modelo de processo) apenas o ponto de partida para a definio
de um processo de desenvolvimento de software.
Como visto na definio de Falbo (2005), um modelo de ciclo de vida,
geralmente, organiza as macro-atividades bsicas do processo (atividades
principais), estabelecendo precedncia e dependncia entre as mesmas.
No entanto, para a definio completa do processo, cada atividade des-
crita no modelo de ciclo de vida deve ser decomposta e para suas subati-
vidades, devem ser associados mtodos, tcnicas, ferramentas e critrios
de qualidade, entre outros, formando uma base slida para o desenvolvi-
mento de um software. Alm disso, outras atividades tipicamente geren-
ciais devem ser definidas, entre elas atividade de gerncia de projetos e de
controle e garantia da qualidade.
Os seguintes fatores influenciam a definio 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 informao, sistema de tempo real etc.),
paradigma de desenvolvimento (paradigma estruturado, orientado a obje-
tos, etc.), domnio da aplicao, tamanho e complexidade do sistema, es-
tabilidade dos requisitos, caractersticas 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 so os modelos de ciclo de vida
de sofware mais comuns (Gustafson, 2003):
Modelo Linear Sequencial; 1.
Modelo Incremental; 2.
Modelo Espiral; 3.
Modelo de Prototipagem. 4.
Captulo 4
43
Quando se estuda um assunto em particular, geralmente existem, na li-
teratura especializada, vrios autores que escrevem sobre esse assunto.
Alm disso, esses diferentes autores muitas vezes apresentam diferentes
nomenclaturas e categorizaes para falar de um mesmo assunto. Em re-
lao a modelos de ciclo de vida, existem outras formas, alm dessas, de
categoriz-los e organiz-los, que podem ser destacadas. Em Pressman
(2006), por exemplo, todos os modelos de ciclo de vida so defnidos como
prescritivos, pelo fato de prescreverem um conjunto de elementos de pro-
cesso. Esses modelos prescritivos so, ento, divididos em:
1. Modelo em Cascata;
2. Modelos Incrementais: que compreendem o Modelo
Incremental e o Modelo RAD
(Rapid Application Development);
3. Modelos Evolucionrios: 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 Evolucionrios: que contempla
o Modelo Espiral;
4. Prototipao.
4.3. Modelo Linear Sequencial
Tambm chamado de Modelo em Cascata, esse modelo tem seu diagrama
parecido com uma srie de cascatas, da seu nome. Inicialmente descrito
por Royce em 1970, foi a primeira realizao de uma sequncia padro
de tarefas. Existem muitas verses desse modelo. Na verso apresentada
na Figura 4.1, note que as atividades de planejamento de projeto esto
includas na fase de requisitos. Alm disso, as fases de entrega e ma-
nuteno foram deixadas de fora. J a Figura 4.2 apresenta uma verso
diferente da anterior. Compare as duas e tire suas concluses sobre qual
seria a melhor, na sua opinio.
44
Figura 4.1 - da pgina 13 da coleo schaum
Figura 4-1: Modelo em Cascata Verso 1
Fonte: Gustafson, 2003
Figura 4-2: Modelo em Cascata Verso 2
Fonte: Falbo, 2005
Captulo 4
45
4.4. Modelo Incremental
H muitas situaes em que os requisitos iniciais do sofware so ra-
zoavelmente bem defnidos, mas o tamanho do sistema a ser desenvol-
vido impossibilita a adoo de um modelo sequencial, principalmente
quando h a necessidade de se fornecer rapidamente aos usurios um
conjunto limitado de funcionalidades e depois refnar e expandir essas
funcionalidades em novas verses do sofware. 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 mnimo do sistema que
continuasse a ser um sistema usvel. O processo, ento, continuaria a inte-
ragir ao longo de todo o ciclo de vida com incrementos adicionais mnimos.
Ou seja, no desenvolvimento incremental, o sistema dividido em subsiste-
mas ou mdulos, tomando por base a funcionalidade. Os incrementos (ou
verses) so defnidos, comeando com um pequeno subsistema funcional
que, a cada ciclo, acrescido de novas funcionalidades. Alm de acrescentar
novas funcionalidades, nos novos ciclos, as funcionalidades providas ante-
riormente podem ser modifcadas para melhor satisfazer s necessidades
dos clientes/usurios. Vale ressaltar que a defnio das verses, com sua
segmentao e atribuio de requisitos, realizada antes do desenvolvimen-
to da primeira verso. As vantagens deste modelo incluem fornecer logo ao
cliente um sistema e novas verses de trabalho.
4.5. Modelo Espiral
Como todo sistema complexo, o sofware tambm evolui com o tempo. Seus
requisitos, de negcio ou do prprio produto, muitas vezes so difceis de se-
rem defnidos ou mudam frequentemente durante o desenvolvimento. Dessa
forma, importante que os profssionais de sofware possam contar com mo-
delos de ciclo de vida que tenham sido explicitamente projetados para lidar
com incertezas e contnuas mudanas. Por serem iterativos, os modelos in-
crementais podem ser aplicados a esses casos, permitindo o desenvolvimento
de verses cada vez mais completas do sofware. Vale ressaltar que a grande
maioria dos modelos evolutivos toma como pressuposto que os requisitos es-
tejam muito bem defnidos. Faz parte desta categoria o Modelo Espiral.
O Modelo Espiral, tambm chamado Modelo Espiral de Boehm, foi introdu-
zido por B. Boehm, de quem recebeu o nome. A imagem do modelo de
uma espiral que comea no meio e continuamente revisa as tarefas bsicas
do usurio: Especifcao de requisitos, Anlise, Projeto, Implementao,
Testes e Entrega e Implantao.
46
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: wikipdia.
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 sofware. No entanto, eles no so capazes
de identifcar claramente os requisitos de entrada, processamento e
sada desse sistema. Tambm chamado de Prototipao, este modelo
pode ser til para ajudar a levantar e validar requisitos, mas tambm
pode acontecer de os clientes/usurios s terem uma dimenso real do
que est sendo desenvolvido se colocados diante do sistema. Nesses
casos, o uso da prototipao fundamental. Ou seja, a prototipao
uma tcnica cujo objetivo ajudar tanto os profssionais de sofware
quanto os clientes a entenderem o que est sendo desenvolvido, quan-
do os requisitos no esto claros. Apesar de a prototipao poder ser
usada como um modelo de processo independente, ela mais comu-
mente usada como uma tcnica que pode ser aplicada no contexto de
qualquer modelo de processo.
Captulo 4
47
Na prototipao, os objetivos gerais do sofware so defnidos, identif-
cam-se as necessidade do cliente e as reas que necessitam de mais def-
nies so delineadas. Aps isso, uma iterao planejada e modelada
na forma de um projeto rpido. Esse projeto rpido concentra-se apenas
na representao dos aspectos do sistema de sofware que so visveis ao
cliente/usurio. Esse projeto leva ao desenvolvimento de um prottipo.
Esse prottipo implantado e depois avaliado pelo cliente/usurio. O
feedback dado pelo cliente/usurio usado para refnar os requisitos do
sistema. A iterao ocorre medida que o prottipo ajustado para
satisfazer as necessidades do cliente, e ao mesmo tempo permite aos
desenvolvedores entender melhor o que precisa ser feito.
Em administrao, feedback o procedimento que consiste no pro-
vimento de informao a uma pessoa sobre o desempenho, conduta
ou eventualidade executada por ela e objetiva reprimir, reorientar
e/ou estimular uma ou mais aes determinadas, executadas ante-
riormente. No nosso contexto, o feedback so as informaes que o
cliente/usurio fornece aos profssionais de sofware sobre o sistema
de sofware em questo, sob diferentes aspectos, quer seja de utiliza-
o, atendimento das suas necessidades, facilidade de uso, etc.
Atividades
1) Quais so as diferenas entre um modelo de ciclo de vida do
software e um modelo processo?
2) Pesquise sobre outras verses do modelo em cascata e des-
creva em forma de diagrama de atividades as verses que voc
encontrar.
3) Descreva com suas prprias palavras o modelo de
prototipagem.
Exerccios Resolvidos
1. Como um modelo de ciclo de vida de fases contempla o geren-
ciamento de sofware?
2. Qual a caracterstica de um marco?
48
3. Para cada um dos seguintes documentos, indique a(s) fase(s)
do ciclo de vida do sofware em que so desenvolvidos. Use como
base o modelo cascata.
- Manual fnal do usurio
- Projeto arquitetural
- Plano de SQA
- Especifcao de Mdulos
- Cdigo Fonte
- Seqncia de Trabalho
- Plano de Teste
- Manual de Usurio Preliminar
- Projeto detalhado
- Estimativa de custo
- Plano de Projeto
- Relatrio de Teste
- Documentaes
4. Ordene as seguintes tarefas em termos do modelo cascata:
- Teste de aceitao
- Planejamento do projeto
- Teste de unidade
- Reviso de requisitos
- Estimativa de custo
- Projeto em alto nvel
- Anlise de mercado
- Projeto em baixo nvel
- Teste de sistema
- Reviso do projeto
- Implementao
- Especifcao de Requisitos
Respostas dos Exerccios
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 prximo do progresso.
2. Um marco deve estar sempre relacionado com o progresso de de-
senvolvimento do sofware. Por exemplo, ele pode ser usado para de-
fnir o status de um projeto e, para fns de gerenciamento, permite ao
gerente identifcar o progresso do desenvolvimento do sofware.
Captulo 4
49
3.
- Manual fnal do usurio fase de implementao
- Projeto arquitetural fase de projeto
- Plano de SQA fase de planejamento de projeto
- Especifcao de Mdulos - fase de projeto
- Cdigo Fonte - fase de implementao
- Sequncia de Trabalho fase de viabilidade
- Plano de Teste fase de teste
- Manual de Usurio 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
- Relatrio de Teste fase de teste
- Documentaes - fase de implementao
4. Ordem das tarefas:
1. Anlise de mercado
2. Planejamento do projeto, estimativa de custo, especifcao de
requisitos (podem ser feitos concomitantemente)
3. Reviso dos requisitos
4. Projeto em alto nvel
5. Projeto em baixo nvel
6. Reviso do projeto
7. Implementao
8. Teste de unidade
9. Teste de sistema
10. Teste de aceitao
(1) FALBO, R.A., Notas de Aula: Engenharia de Software. Dis-
ponvel em http://www.inf.ufes.br/~falbo, 2005.
(2) GUSTAFSON, DAVID A. Teoria a problemas de engenharia
de software. Porto alegre: Bookman, 2003. (Coleo Schaum).
PRESSMAN, R.S., Engenharia de Sofware. So Paulo: McGraw-
Hill, 6 Edio, 2006.
50

___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
Captulo 4
51
Prezado aluno,
Como visto na seo 1.3, em um processo de sofware, em uma abor-
dagem de engenharia de sofware, podemos considerar trs tipos de
atividades principais: de desenvolvimento, de gerncia de projetos e
de garantia da qualidade. No entanto, a espinha dorsal do desenvol-
vimento de um sofware formada pelas atividades chamadas de
atividades de desenvolvimento, tcnicas ou atividades de cons-
truo. As atividades de gerncia e de controle da qualidade so
muitas vezes consideradas atividades de apoio. Neste captulo apre-
sentarei as atividades de desenvolvimento, que so as atividades
que contribuem diretamente para o desenvolvimento do produto de
sofware a ser entregue ao cliente. As atividades de desenvolvimen-
to compreendem basicamente as seguintes atividades: especifcao
e anlise de requisitos, projeto de sistema, implementao e testes,
entrega e manuteno.
Bom estudo!
5.1. Especificao e Anlise de Requisitos
Em relao s atividades de desenvolvimento de sofware, 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 sofware que ser desenvolvido um dos fatores mais im-
portantes que determinaro o sucesso ou no do esforo de desenvolvi-
mento desse sofware.
Tambm chamada de engenharia de requisitos, esta fase do desen-
volvimento de um sofware um processo de descoberta, refnamento,
modelagem e especifcao. A engenharia de requisitos o processo de
identifcar todos os envolvidos, descobrir seus objetivos e necessidades
e document-los apropriadamente.
Nesta fase, o escopo do sofware, que foi defnido no planejamento do proje-
to, refnado em detalhes. Tambm so especifcadas as funes e o desem-
ATIVIDADES DE
DESENVOLVIMENTO
52
penho do sofware, bem como as interfaces com outros sistemas e restries
que o sofware deve atender. Tambm so construdos os modelos de dados
que defnem o controle e o comportamento operacional do sofware. Final-
mente, so defnidos os critrios para a avaliao da qualidade do produto
de sofware nas atividades subsequentes (FALBO, 2005).
Falbo (2005) apresenta a engenharia de requisitos como um processo
composto das seguintes atividades:
Levantamento de Requisitos: nesta atividade identicam-se os
usurios, clientes e especialistas de domnio, que trabalham juntos
com os engenheiros de requisitos para descobrir, articular e entender
a organizao como um todo, o domnio da aplicao, os processos
de negcio, as necessidades que o software deve atender e os pro-
blemas e decincias dos sistemas atuais. Tambm so levantados
os diferentes pontos de vista dos envolvidos no processo, as opor-
tunidades de melhoria e restries existentes, os problemas a serem
resolvidos e o desempenho requerido do sistema como um todo.
Anlise de Requisitos: tem como objetivo denir um conjunto de
requisitos consistentes e sem ambiguidades, que sero usados como
base para o desenvolvimento do software. Nesta atividade sero
construdos diversos tipos de modelos. Nesta fase tambm pode in-
cluir a negociao para se resolver conitos detectados.
Documentao de Requisitos: atividade de representar os resulta-
dos da engenharia de requisitos em um documento (ou conjunto de
documentos) contendo os requisitos do software.
Vericao e Validao de Requisitos: a vericao de requisi-
tos avalia se o documento de especicao de requisitos est sendo
construdo corretamente e se est de acordo com padres previa-
mente denidos, no contendo requisitos ambguos, incompletos,
incoerentes ou impossveis de serem testados. A validao de re-
quisitos avalia se o documento de especicao de requisitos est
correto, ou seja, se os requisitos e modelos documentados atendem
s reais necessidades e requisitos dos clientes/usurios.
Gerncia de Requisitos: esta atividade preocupa-se em gerenciar
as mudanas que porventura ocorram nos requisitos j acordados,
mantendo uma trilha dessas mudanas, gerenciando os relaciona-
mentos entre os requisitos e as dependncias entre o documento de
requisitos e demais artefatos produzidos no processo de software,
de forma a garantir que mudanas nos requisitos ocorram de manei-
ra controlada e documentada.
Captulo 5
53
Finalizando, um requisito de sofware pode ser funcional ou no funcio-
nal. Requisitos funcionais, como o prprio nome diz, descrevem as fun-
es que o sistema deve fornecer e como o sistema deve se comportar em
determinadas situaes. J os requisitos no funcionais descrevem restri-
es sobre as funes oferecidas, tais como as restries de tempo, de uso
de recursos, etc. Alguns requisitos no funcionais dizem respeito ao sis-
tema como um todo e no a uma funcionalidade especfca. Os requisitos
no funcionais podem ser classifcados 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 sofware tiverem
sido especifcados e modelados. Esta atividade corresponde primeira
das trs atividades do domnio computacional projeto, implementa-
o e testes requeridas para se construir um sistema de sofware.
A atividade de projeto envolve a modelagem de como o sistema ser
implementado, incorporando os requisitos no funcionais aos modelos
construdos na fase de anlise. O objetivo do projeto de um sistema
incorporar a tecnologia aos requisitos essenciais dos usurios, projetan-
do o que ser construdo na fase de implementao. Assim, necessrio
conhecer as tecnologias disponveis e as facilidades do ambiente de sof-
tware no qual o sistema ser implementado.
O projeto de sofware um processo iterativo. O projeto inicialmente
representado em um alto nvel de abstrao. medida que as iteraes
ocorrem, os refnamentos conduzem a representaes com nveis me-
nores de abstrao.
Atividades de Desenvolvimento
54
Uma viso geral da atividade de projeto apresentada na Figura 5.1.
Figura 5-1: Viso 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 explcitos contidos no modelo de anlise e
todos os requisitos implcitos desejados pelos clientes/usurios.
Ser um guia legvel e compreensvel para aqueles que iro codifcar, testar e
fazer a manuteno do sofware.
Fornecer um quadro completo do sofware, tratando aspectos funcionais, com-
portamentais e de dados, segundo uma perspectiva de implementao.
Diagramas de Casos de Uso
Um projeto de sistema deve produzir:
Projeto da Arquitetura do sofware: visa defnir os grandes componentes
estruturais do sofware e seus relacionamentos.
Projeto de Dados: tem como objetivo projetar a estrutura de armazenamento
de dados necessria para implementar o sofware.
Projeto de Interface: visa descrever como o sofware deve se comunicar
internamente (interfaces internas), com outros sistemas (interfaces externas)
e com seus usurios (interface com o usurio).
Projeto Procedimental Detalhado: tem como objetivo refinar e deta-
lhar a descrio procedimental dos componentes estruturais da arqui-
tetura do software.
Captulo 5
55
5.3. Implementao e Testes
Aps projetar um sistema, necessrio escrever os programas que im-
plementem esse projeto e test-los. Em relao implementao, sabe-
mos que mesmo que um projeto esteja bem elaborado, esta tarefa no
necessariamente fcil. A seguir listamos alguns aspectos que tornam
esta tarefa to complexa:
Muitas vezes, os projetistas no conhecem a plataforma de im- t
plementao em detalhes e, portanto, no so capazes de chegar
a um projeto algortmico passvel de implementao direta;
Questes relacionadas legibilidade, alterabilidade e reutili- t
zao devem ser levadas em conta;
Geralmente os programadores trabalham em equipe, necessi- t
tando integrar, testar e alterar cdigo produzido por outros, o
que cria uma necessidade da criao de padres organizacio-
nais que devem ser seguidos por todos os programadores;
Deve-se sempre ter o cuidado de manter a correspondncia entre t
os componentes do projeto e o cdigo. Lembrar sempre que o
projeto o guia para a implementao, ainda que os programa-
dores possam e devam ter certa fexibilidade de implementao;
Para uma implementao bem-sucedida, as unidades de sof- t
tware devem ser codifcadas e critrios de verifcao das mes-
mas devem ser defnidos.
Em relao a Testes, muito importante que, aps a implementa-
o, o produto de sofware produzido seja testado, a fm de que se
descubra o nmero mximo de defeitos possvel antes da entrega do
produto de sofware ao cliente.
O processo de teste envolve quatro atividades principais (Falbo, 2005),
descritas a seguir:
Planejamento de Testes: t diz respeito defnio das atividades de
teste, das estimativas dos recursos necessrios para realiz-las, dos
objetivos, estratgias e tcnicas de teste a serem adotadas e dos crit-
rios para determinar quando uma atividade de teste est completa;
56
Projeto de Casos de Testes: t a atividade chave para um teste bem-
sucedido, ou seja, para se descobrir a maior quantidade de defeitos
com o menor esforo possvel. 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 vrias possibi-
lidades de exerccio das funes do sofware (cobertura dos testes).
Existe uma grande quantidade de tcnicas de teste para apoiar os
testadores a projetar casos de teste, oferecendo uma abordagem sis-
temtica para o teste de sofware;
Execuo dos testes: t consiste na execuo dos casos de teste e regis-
tro de seus resultados;
Avaliao dos resultados t : detectadas falhas, os defeitos devero ser
procurados. No detectadas falhas, deve-se fazer uma avaliao fnal
da qualidade dos casos de teste e defnir pelo encerramento ou no
de uma atividade de teste.
Existem diferentes Categorias de Tcnicas de Teste. Usaremos a ca-
tegorizao que separa as Tcnicas de Testes em Funcional ou Teste
Caixa-Preta, Estrutural ou Teste Caixa-Branca e as baseadas em m-
quinas de estado (Falbo, 2005).
Os t testes funcionais ou caixa-preta so conduzidos na interface
do sofware, ou seja, o conhecimento sobre uma determinada
implementao no usado. Esse tipo de teste utiliza as es-
pecifcaes (de requisitos, anlise e projeto) para defnir os
objetivos do teste e, portanto, para guiar o projeto de casos
de teste. Os testes caixa-preta ou funcionais, como o prprio
nome diz, so empregados para demonstrar que as funes do
sofware esto operacionais, que a entrada adequadamente
aceita e a sada corretamente produzida e que a integridade
da informao externa mantida. Testes caixa preta exami-
nam algum aspecto fundamental do sistema, pouco se preo-
cupando com a estrutura lgica interna do sofware.
Os t testes estruturais ou caixa-branca so baseados em um exa-
me rigoroso do detalhe procedimental. Esse tipo de teste es-
tabelece os objetivos do teste com base em uma determinada
implementao, verifcando detalhes do cdigo, ao contrrio
do teste caixa-preta. Caminhos lgicos internos so testados,
defnindo casos de testes que exercitem conjuntos especfcos
de condies ou laos.
Captulo 5
57
Os t testes baseados em mquinas de estado so projetados utili-
zando o conhecimento subjacente estrutura de uma mqui-
na de estados para determinar os objetivos do teste.
Em relao a Tcnicas de Teste de Software, muito importante
ressaltar que as diferentes tcnicas devem ser utilizadas de forma
complementar, j que elas tm propsitos distintos, detectando
categorias de erros distintas.
Alm das Tcnicas de Testes, existe o que chamamos de Estratgias de
Teste. A estratgia de teste a srie planejada de realizao dos testes, e
compreende basicamente trs grandes fases. A saber: teste de unidade,
teste de integrao e teste de sistema (Falbo, 2005).
Teste de Unidade: t tem por objetivo testar a menor unidade do
projeto, procurando identifcar erros de lgica e de implemen-
tao em cada mdulo separadamente. Como menor unidade
de projeto, podemos considerar um componente de sofware
que no pode ser subdividido. No paradigma estruturado, a
menor unidade refere-se a um procedimento ou funo.
Teste de Integrao: t tem como objetivo descobrir erros asso-
ciados s interfaces entre os mdulos, quando esses so inte-
grados para formar estrutura do produto de sofware.
Teste de Sistema: tem como objetivo identicar erros de fun-
es (requisitos funcionais) e caractersticas de desempenho
(requisito no funcional) que no estejam de acordo com as
especicaes pr-estabelecidas.
5.4. Entrega e Manuteno
A Entrega a ltima etapa do processo de desenvolvimento de sofware,
e ocorre aps o sofware ter sido testado, aceito e instalado no ambiente
operacional do usurio. Uma vez instalado, o sofware passa a ser usado,
e eventuais mudanas, quer sejam de carter corretivo, quer sejam de
carter de evoluo, caracterizam-se como uma manuteno.
Aps o produto de sofware ser entregue ao cliente e entrar em opera-
o, podemos considerar o trmino do desenvolvimento desse sistema.
A partir da, deve-se garantir que o sistema continuar sendo til e aten-
58
dendo s necessidades do usurio, o que pode demandar alteraes no
mesmo. Comea, ento, a fase de manuteno. Existem diferentes tipos
de manuteno, a saber: manuteno corretiva, adaptativa, perfectiva e
preventiva, descritas a seguir (Falbo, 2005).
Manuteno Preventiva: trata de problemas decorrentes de
defeitos. medida que falhas ocorrem, elas so relatadas
equipe de manuteno, que se encarrega de encontrar o de-
feito que causou a falha e fazer as correes necessrias, quer
sejam nos requisitos, na anlise ou projeto do sistema, ou em
sua implementao.
Manuteno Adaptativa: diz respeito s necessidades de
adaptao que ocorrem quando h uma mudana no ambiente
do sistema, incluindo hardware e software de apoio.
Manuteno Perfectiva: consiste em realizar mudanas para
melhorar algum aspecto do sistema, mesmo quando nenhuma
das mudanas for consequncia de defeitos. Isso inclui a adi-
o de novas capacidades, bem como ampliaes gerais.
Manuteno Preventiva: tem como objetivo realizar mu-
danas a m de prevenir falhas. Esse tipo de manuteno ge-
ralmente ocorre quando um mantenedor descobre um defeito
que ainda no causou uma falha e, ento, decide corrigi-lo
antes que seja causada efetivamente uma falha.
5.5. Exemplo da Loja Vitria
Para tornar este captulo o mais prtico possvel, nesta seo apresenta-
remos exemplos das principais documentaes relacionadas a um pro-
jeto de sofware. Trata-se de um projeto de informatizao de uma loja
chamada Loja Vitria. Sero inicialmente apresentados os documen-
tos de especifcao de requisitos. Os documentos de anlise e projeto
podem ser consultados no Anexos A e B, respectivamente, ao fnal do
material impresso.
Captulo 5
59
5.5.1. Documento de Especificao de Requisitos
Projeto Loja Vitria
1. Introduo
Este documento contm a especifcao de requisitos para o projeto de
informatizao da Loja Vitria. Essa atividade foi desenvolvida usando
a tcnica de modelagem de casos de uso e, portanto, esse documento
apresenta os diagramas de caso de uso gerados, bem como as descries
dos atores e dos casos de usos identifcados nesses diagramas. Na seo
2, uma breve descrio do domnio do problema apresentada.
2. Descrio do Mini-mundo
Uma pequena empresa, a Loja Vitria, deseja um sistema para auto-
matizar o seu faturamento e controle de estoque. A loja trabalha com
uma variedade de produtos que so oferecidos por fornecedores. De um
produto, deseja-se saber o nome, descrio, valor de venda, estoque e
fornecedores. Para facilitar a manuteno do estoque da loja, mantido
um estoque mnimo para cada produto. Um produto pode ser obtido de
diversos fornecedores e cada fornecedor oferece vrios produtos loja.
Fornecedores so pessoas jurdicas, das quais se deve saber o nome, en-
dereo, telefone, CNPJ e prazo de entrega dos produtos.
Clientes compram produtos. Quando feita a venda de um ou mais
produtos, emitida uma nota fscal de sada contendo o cliente, data de
emisso e itens determinando a quantidade de cada produto vendido. A
uma nota fscal de sada pode ser estabelecido ainda um desconto. Um
cliente possui nome, endereo, telefone e CPF (caso seja pessoa fsica)
ou CNPJ (caso seja pessoa jurdica). Clientes que ainda no fzeram uma
compra so considerados prospectados e clientes que j compraram aci-
ma de R$ 2.000,00 so considerados preferenciais, podendo obter um
desconto de at 10% em suas compras. Clientes no preferenciais (ativos
ou prospectados) podero ter descontos de at 5%.
Quando produtos so entregues loja por um fornecedor, devem ser
registradas notas fscais 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 fscais de entrada so registradas,
as quantidades compradas devem ser acrescidas ao estoque dos respec-
tivos produtos. Da mesma forma, quando so emitidas notas fscais de
sada, os estoques dos produtos vendidos devem ser decrementados.
Para facilitar a administrao da empresa, o gerente da loja deseja que o
sistema seja capaz de emitir os seguintes relatrios: listagem de produtos
60
com estoque abaixo do mnimo, produtos de um fornecedor, fornece-
dores de um produto, notas fscais de entrada emitidas em determinado
perodo, notas fscais de sada registradas em determinado perodo 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:
Controle Interno t : envolve a funcionalidade relacionada com
o controle interno da loja, abrangendo cadastro de clientes,
produtos e fornecedores.
Controle de Notas Fiscais t : envolve a funcionalidade relacionada
criao de notas fscais, incluindo emisso de notas fscais de
sada, registro de notas fscais de entrada e emisso de relatrios.
Figura 1 Diagrama de Pacotes.
3.1. Controle Interno
A fgura 2 mostra o diagrama de casos de uso referente ao controle in-
terno. Na sequncia, os casos de uso identifcados so descritos.
Figura 2 Diagrama de Casos de Uso Controle Interno.
Captulo 5
61
Os atores que atuam nesse subsistema so o Ator Operador e o Ator
Administrador, que representam os papeis desempenhados, respecti-
vamente, pelos funcionrios e pelo gerente da loja.
Sistema: Controle de Estoque
Pacote: Controle Interno
Caso de Uso: Controlar Cliente
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pelo controle de clientes, abrangen-
do a incluso de um novo cliente, alterao, consulta, e excluso de
clientes existentes.
Curso Normal:
Incluir Novo Cliente
O administrador ou operador informa os dados do novo cliente, incluindo nome,
endereo, telefones e CPF (caso seja pessoa fsica) ou CNPJ (caso seja pessoa jurdi-
ca). Caso os dados sejam vlidos, 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 so validados e a alterao registrada.
Consultar Dados de Cliente
O administrador ou operador informa o cliente que deseja consultar. Os dados
do cliente so 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 fscais de sada. Se o total for superior a R$ 2.000,00, o esta-
do do cliente alterado para preferencial. Caso contrrio 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 excludo se no houver nenhum vnculo com notas fcais
de sada. Os dados do cliente so apresentados e solicitada a confrmao.
Caso confrmado, o cliente excludo.
62
Cursos Alternativos:
Incluir Novo Cliente / Alterar Dados de Cliente
Dados do cliente invlidos: uma mensagem de erro exibida, t
solicitando correo da informao invlida.
Excluir Cliente
Cliente possui notas fscais de sada: uma mensagem de erro t
exibida indicando que o cliente possui notas fcais de sada.
Restries de Integridade:
No h restries de integridade.
Caso de Uso: Cadastrar Produto
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pelo controle de produtos, abrangendo a
incluso de um novo produto, alterao, consulta e excluso de produ-
tos existentes.
Curso Normal:
Incluir Novo Produto
O administrador informa os dados do novo produto, incluindo nome, des-
crio, valor de venda, estoque mnimo e fornecedores. O estoque do pro-
duto inserido como zero. Caso os dados sejam vlidos, sero registrados.
Alterar Dados de Produto
O administrador informa o produto cujos dados deseja alterar e os no-
vos dados. Os novos dados so validados e a alterao registrada.
Consultar Dados de Produto
O administrador ou operador informa o produto que deseja consultar.
Os dados do produto so apresentados.
Excluir Produto
O administrador informa o produto que deseja excluir. Um produto so-
mente poder ser excludo se no houver nenhum vnculo com itens
de notas fcais. Os dados do produto so apresentados e solicitada a
confrmao. Caso confrmado, o produto excludo.
Captulo 5
63
Incluir Novo Produto / Alterar Dados de Produto
Dados do produto invlidos: uma mensagem de erro exibi- t
da, solicitando correo da informao invlida.
Excluir Produto
Produto possui vnculo com itens de notas fscais: uma men- t
sagem de erro exibida indicando que o produto possui itens
de notas fcais.
Caso de Uso: Cadastrar Fornecedor
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pelo controle de fornecedores, abrangen-
do a incluso de um novo fornecedor, alterao, consulta e excluso de
fornecedores existentes.
Curso Normal:
Incluir Novo Fornecedor
O administrador informa os dados do novo fornecedor, incluindo nome,
endereo, telefones, CNPJ e prazo de entrega. Caso os dados sejam v-
lidos, sero registrados.
Alterar Dados de Fornecedor
O administrador informa o fornecedor cujos dados deseja alterar e os
novos dados. Os novos dados so validados e a alterao registrada.
Consultar Dados de Fornecedor
O administrador ou operador informa o fornecedor que deseja consul-
tar. Os dados do fornecedor so apresentados.
Excluir Fornecedor
O administrador informa o fornecedor que deseja excluir. Um fornece-
64
dor somente poder ser excludo se no houver nenhum vnculo com
notas fcais de entrada. Os dados do fornecedor so apresentados e
solicitada a confrmao. Caso confrmado, o fornecedor excludo.
Incluir Novo Fornecedor / Alterar Dados de Fornecedor
Dados do fornecedor invlidos: uma mensagem de erro exi- t
bida, solicitando correo da informao invlida.
Excluir Fornecedor
Fornecedor possui notas fscais de entrada: uma mensagem de t
erro exibida indicando que o fornecedor possui notas fcais
de entrada.
3.2. Controle de Notas Fiscais
A Figura 3 mostra o diagrama de casos de uso referente ao controle de
notas fscais. Na sequncia, os casos de uso identifcados so 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.
Captulo 5
65
Pacote: Controle de Nota Fiscal
Caso de Uso: Controlar Nota Fiscal de Sada
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pelo controle de Notas Fiscais de Sada,
abrangendo a emisso e consulta de notas fscais de sada.
Curso Normal
Emitir Nota Fiscal de Sada
Pr-requisito: cliente informado no deve ser inativo.
O administrador ou operador informa o cliente constante da nota fscal
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 somatria dos
valores dos produtos vezes as quantidades pedidas. O administrador ou
operador informa, ento, 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 verifca se todos os produtos informados existem em estoque em
quantidade igual ou superior desejada. Se existirem, as quantidades em
estoque so decrementadas das quantidades pedidas na nota.
Se os dados forem vlidos, a nota fscal registrada com um nmero
gerado pelo sistema e a data de emisso.
realizado o evento Ativar cliente do caso de uso Controlar Cliente.
Consultar Nota Fiscal de Sada
O administrador ou operador seleciona a nota fscal de sada que deseja
consultar. Os dados da nota fscal so apresentados.
Cursos Alternativos
Emitir Nota Fiscal de Sada
H produtos com quantidade em estoque inferior pedida: t
Uma mensagem exibida solicitando a alterao da quanti-
dade pedida.
Desconto informado superior ao permitido: Uma mensagem t
exibida solicitando a correo do desconto.
Restries de Integridade
66
Caso de Uso: Controlar Nota Fiscal de Entrada
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pelo controle de Notas Fiscais de Entrada,
abrangendo o registro e a consulta de notas fscais de entrada.
Curso Normal
Registrar Nota Fiscal de Entrada
O administrador ou operador informa o fornecedor e o nmero da nota
fscal e, em seguida, os produtos e suas respectivas quantidades. Os da-
dos so validados. As quantidades em estoque de cada item contido na
Nota Fiscal so acrescidas das quantidades informadas na nota.
A nota fscal registrada com a data de registro.
Consultar Nota Fiscal de Entrada
O administrador ou operador informa a nota fscal de entrada que dese-
ja consultar. Os dados da nota fscal so apresentados.
Cursos Alternativos
Registrar Nota Fiscal de Entrada
Dados da nota fscal invlidos: uma mensagem de erro exibi- t
Caso de Uso: Emitir Relatrio
Data: 16/08/2005
Descrio:
Este caso de uso responsvel pela emisso dos relatrios que auxiliam
o controle do estoque da empresa.
Captulo 5
67
Curso Normal
Listar Produtos Abaixo do Estoque Mnimo
O administrador ou operador do sistema solicita um relatrio dos pro-
dutos com quantidade em estoque abaixo do mnimo permitido. O sis-
tema exibe uma listagem dos produtos cuja quantidade em estoque se
encontra abaixo da quantidade mnima permitida.
Listar Produtos por Fornecedor
O administrador ou operador do sistema informa o fornecedor cujos
produtos deseja listar. O sistema exibe um relatrio 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 relatrio contendo os forne-
cedores do produto informado.
Listar Notas Fiscais de Entrada
O administrador ou operador informa o perodo de registro em que
deseja listar as notas fscais de entrada. O sistema exibe um relatrio
contendo as notas fscais de entrada registradas no perodo informado.
Listar Notas Fiscais de Sada
O administrador ou operador informa o perodo de emisso em que
deseja listar as notas fscais de sada. O sistema exibe um relatrio con-
tendo as notas fscais de sada emitidas no perodo informado.
Listar Clientes por Estado
O administrador ou operador informa o estado dos clientes que deseja
listar. O sistema exibe um relatrio contendo os clientes que se encon-
tram no estado informado.
Cursos Alternativos
Listar Notas Fiscais de Entrada / Listar Notas Fiscais de Sada
Perodo informado invlido: uma mensagem de erro exibi- t
68
Atividades
1. Quais so as atividades que compem a espinha dorsal de de-
senvolvimento de um sofware? Descreva cada uma dessas ativi-
dades de forma sucinta, com suas prprias palavras.
2. Todas as atividades envolvidas no processo de desenvolvimen-
to de sofware produzem artefatos. Um artefato um produto de
trabalho, que pode ser um modelo, documento ou cdigo 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 frum de discusso.
Captulo 5
69

___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
70
Captulo 5
71
Prezado aluno,
No captulo 1 foram apresentadas trs atividades bsicas envolvidas
em um processo de sofware em uma abordagem de engenharia de
sofware, que so as atividades de desenvolvimento, as atividades de
gerncia de projeto e as atividades de garantia da qualidade. Neste
captulo apresentarei as atividades de gerncia de projeto, que so
aquelas relacionadas ao planejamento e acompanhamento geren-
cial do projeto, tais como realizao de estimativas, elaborao de
cronogramas, anlise dos riscos do projeto etc.
Bom estudo!
6.1. Introduo
A gerncia de projetos de sofware um conjunto de atividades que
tem como objetivo responder a perguntas tais como quanto o proje-
to custar e qual ser a sua durao. Para responder a essas pergun-
tas preciso defnir o escopo do projeto, realizar estimativas, levantar
riscos, alocar recursos e defnir um cronograma de execues. Todas
essas informaes so registradas em um documento chamado Plano
de Projeto, que deve ser sistematicamente revisado, a fm de permitir
o acompanhamento do projeto e a tomada de aes corretivas, sempre
que necessrio.
6.2. Escopo de Software
Basicamente o escopo de sofware composto pela especifcao de
um conjunto de funcionalidades (requisitos funcionais) associada a
outras caractersticas desejadas (requisitos no funcionais), tais como
desempenho, confabilidade etc. O escopo de sofware pode ser do-
cumentado de vrias formas, sempre contendo uma breve descrio
das funes do sistema, requisitos no funcionais importantes e o
contexto e objetivos do sistema. Diagramas de casos de uso so um
GERENCIAMENTO DE PROJETO
DE SOFTWARE
72
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 (usurios ou outros
sistema) aparecem interagindo com as funes 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 sofware uma atividade que serve para deter-
minar quantos recursos sero necessrios para completar o projeto. Ge-
ralmente essa estimativa feita pensando no nmero de programadores
necessrio por ms (PM) para um determinado projeto. Existem duas
diferentes abordagens que sero discutidas neste captulo. A mais antiga
delas, chamada estimativa LOC, baseada no nmero de linhas de cdi-
go necessrias para desenvolver um projeto. A outra abordagem base-
ada na contagem de pontos de funo na descrio do projeto. Ambas as
abordagens sero ilustradas com exemplos para facilitar a compreenso
(Gustafson, 2003).
6.3.1. Estimativa LOC (Estimativa de Linha de Cdigo)
A estimativa LOC contempla trs passos: (1) Estimar o nmero de li-
nhas de cdigo no projeto fnal; (2) Estimativa de Custo baseado por
LOC baseado em dados histricos; (3) Estimativa de custo por LOC
baseado no tipo de projeto.
Captulo 6
73
1. Estimativa de Linha de Cdigo (LOC): a estimativa de linha de cdigo
uma estimativa de tamanho do sofware. Ela feita baseada em experi-
ncia, tamanho de projetos anteriores, tamanho da soluo concorrente
ou dividindo-se o projeto em partes menores e, ento, estimando o ta-
manho de cada uma dessas partes. Uma abordagem padro , para cada
parte, estimar o tamanho mximo de linhas possvel (Tamanho Max), o
melhor tamanho (Ideal) e o tamanho mnimo possvel (Tamanho Min). A
estimativa do nmero de linhas do projeto fnal dada pela soma das es-
timativas de cada parte, em que a estimativa de uma parte dada por 1/6
da soma da estimativa mxima, 4 vezes a estimativa ideal e a estimativa
mnima de cada parte do projeto, como mostra o exemplo a seguir:
Exemplo: A equipe WRT identifcou sete partes no seu projeto (P1 a
P7). Elas esto apresentadas na Tabela 6.1, com suas estimativas de ta-
manho mximo, ideal e mnimo 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 so 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 ento por:
Total = 31,6 + 15,8 + 31,6 + 36,7 + 20 + 12 + 22,17 = 170,07 LOC.
Gerenciamento de Projeto de Software
74
Embora a estimativa baseada na contagem do nmero de linhas de c-
digo (Lines Of Code - LOC) seja uma das mais simples, existem alguns
estudos que demonstram a alta correlao entre essa mtrica e o tem-
po necessrio para se desenvolver um sistema. Entretanto, o uso dessa
mtrica apresenta vrias desvantagens. Primeiro, verifca-se que ela
fortemente ligada tecnologia empregada, sobretudo a linguagem de
programao e ao estilo do cdigo escrito. Segundo, pode ser difcil es-
timar essa grandeza no incio do desenvolvimento, sobretudo se no
houver dados histricos relacionados com a linguagem de programao
utilizada no projeto. Por fm, essa uma mtrica que pouco signifcativa
para o cliente.
2. Estimativa de Custo baseado em LOC: a abordagem bsica de LOC
a frmula que combina dados histricos do projeto. A frmula bsica
tem trs parmetros:
Custo = * KLOC
+ , em que
(Alfa) = custo marginal por KLOC (1000 linhas de cdigo), que repre-
senta o custo adicional para 1000 linhas de cdigo;
(Beta) = expoente que refete a no-linearidade do relacionamento.
Valores de beta maiores do que 1 signifcam que o custo por KLOC au-
menta medida que o tamanho do projeto aumenta. Isso signifca uma
economia de escala ao inverso. Se o valor de beta menor do que 1, isso
refete uma economia de escala. Foram encontrados em estudos tanto
valores maiores quanto valores menores do que 1 para beta.
(Gama) = refete o custo fxo de qualquer projeto. Estudos encontra-
ram valores positivos e o valor zero para gama.
O exemplo a seguir tem como objetivo calcular o esforo necessrio
para um projeto novo de 50 KLOC.
Exemplo: A companhia LMN armazenou os seguintes dados de projeto
s anteriores. Estime os parmetros para a frmula de estimativa de cus-
to e quanto esforo ser necessrio para um novo projeto de 30 KLOC.
(Veja Tabela 6.2).
Captulo 6
75
Projeto Tamanho (KLOC) Esforo (PM)
1 50 120
2 80 192
3 40 96
4 10 24
5 20 48
Tabela 6.2 Dados Histricos
Analisando ou traando o grfco desses dados, ser mostrado um rela-
cionamento linear entre tamanho e esforo. O coefciente de inclinao
da linha 2,4 (basta dividir o valor do esforo pelo tamanho nos dados
da tabela para chegar a este coefciente). Esse valor ser alfa () na fr-
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 esforo ser de 72 PM.
3. Constructive Cost Model (COCOMO): COCOMO uma frmula
de estimativa de custo criada por Barry Boehm na dcada de 70. Bo-
ehm usou milhares de instrues de cdigo prontas thousands deli-
vered source instructions (KDSI) como unidade de tamanho (KDSI
equivalente a KLOC). Sua unidade de esforo dada em progra-
mador/ms (PM). Boehm dividiu dados histricos do projeto em trs
tipos de projeto:
1. Programas aplicativos (Ex: processadores de texto);
2. Programas utilitrios (Ex: compiladores);
3. Programas de sistemas (embarcados).
Ele identifcou os valores de parmetros para determinao do esforo:
1. Programas aplicativos: PM = 2,4 * (KDSI)1,05
2. Programas utilitrios: PM = 3,0 * (KDSI)1,12
3. Programas de sistemas: PM = 3,6 * (KDSI)1,20
Exemplo: Calcule o esforo do programador para projetos de 5 a 50
KDSI. Veja Tabela 6.3.
76
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 Esforo COCOMO
Boehm tambm determinou que em seus dados de projeto existisse
um tempo de desenvolvimento padro baseado no tipo e tamanho do
projeto. As frmulas a seguir determinam o tempo de desenvolvimento
(TDEV) em programador/ms (PM):
1. Programas aplicativos: TDEV = 2,5 * (PM)
0,38
2. Programas utilitrios: TDEV = 2,5 * (PM)
0,35
3. Programas de sistemas: TDEV = 2,5 * (PM)
0,32
Exemplo: Calcule o padro TDEV usando as frmulas 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
Captulo 6
77
6.3.2. Anlise de Ponto de Funo
A contagem de pontos de funo o exemplo mais conhecido de mtrica
que tem como objetivo possibilitar a realizao de estimativas de tama-
nho logo no incio do processo de sofware e sem os problemas de depen-
dncia em relao tecnologia. A contagem de pontos de funo busca
medir as funcionalidades do sistema requisitadas pelo usurio, indepen-
dentemente da tecnologia usada na implementao. A anlise de pontos
de funo um mtodo-padro para a medio do desenvolvimento, ma-
nuteno ou tamanho de uma aplicao de sofware, visando estabelecer
uma medida de tamanho de sofware em Pontos de Funo (PF), com
base na quantifcao da funcionalidade solicitada ou fornecida, sob o
ponto de vista do usurio. Os objetivos da anlise de pontos de funo so
medir as funcionalidades do sistema (solicitadas e recebidas pelos usu-
rios) e medir projetos de desenvolvimento e manuteno de sofware, sem
a preocupao com a tecnologia que ser usada na implementao. Ou
seja, pontos de funo so usados para identifcar e quantifcar as funcio-
nalidades requeridas para um projeto. A idia central contar elementos
no comportamento que iro requerer processamento. Gustafson (2003)
nos apresenta os itens clssicos de contagem:
Requisitos: so pares de solicitao-resposta que no mudam os dados
internos. Por exemplo, a solicitao do endereo de um funcionrio espe-
cfco um requisito. Toda a sequncia de perguntar e preencher o nome
e o endereo de um funcionrio ser contada como um nico requisito;
Entradas: so itens da aplicao de dados suprida pelo programa. A
entrada lgica geralmente considerada um item e os campos individu-
ais no so contados separadamente. Por exemplo, a entrada de dados
pessoais para um funcionrio pode ser considerada uma entrada;
Sadas: so os dados da aplicao exibidos. Pode ser um relatrio, uma
tela ou uma mensagem de erro. Os campos individuais tambm no
so considerados sadas separadas. Se um relatrio tem mltiplas linhas,
por exemplo, uma linha para cada funcionrio de um departamento, es-
sas linhas sero consideradas como uma nica sada. Entretanto, alguns
contam linhas sumrias como sadas separadas;
Arquivos Internos: so arquivos lgicos que o usurio 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 contm dados pessoais, dados sumrios de
um departamento, e outros dados do departamento, para o propsito de
pontos de funo, provavelmente esses arquivos seriam contados como
trs arquivos separados;
78
Interfaces Externas: so dados que so compartilhados com outros
programas. Um arquivo pessoal, por exemplo, pode ser usado pelo
departamento de recursos humanos para promoo 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 funo, ilustrados na fgura 6.1 e descritos de
forma sucinta logo a seguir:
Figura 6-2: Passos do Processo de contagem dos Pontos de Funo
Fonte: Falbo, 2005
Passo 1: Determinar o tipo de contagem dos pontos de funo: este
o primeiro passo no processo de contagem dos pontos de funo, sendo
que existem trs tipos de contagem: contagem de PF de projeto de de-
senvolvimento, de aplicaes instaladas e de projetos de manuteno.
Captulo 6
79
Passo 2: Identifcar o escopo de contagem e a fronteira da aplicao:
neste passo, so defnidas as funcionalidades que sero includas em
uma contagem de Pontos de funo especfca. Tambm defnida a
fronteira da aplicao, estabelecendo um limite lgico entre a aplicao
que est sendo medida, o usurio e outras aplicaes. O escopo de con-
tagem defne a parte do sistema (funcionalidades) a ser contada.
Passo 3: Determinar a contagem de pontos de funo no ajustados:
os pontos de funo no ajustados refetem as funcionalidades forneci-
das pelo sistema para o usurio. Essa contagem leva em conta dois tipos
de funo: funes de dados e funes transacionais, e tambm se a
complexidade simples, mdia ou complexa.
Passo 4: Contagem das funes de dados: as funes de dados repre-
sentam as funcionalidades relativas aos requisitos de dados internos e
externos aplicao, que so os arquivos lgicos internos e os arquivos
de interface externa. Ambos so grupos de dados logicamente relacio-
nados ou informaes de controle que foram identifcados pelo usurio.
A diferena est no fato de um Arquivo Lgico Interno (ALI) ser man-
tido dentro da fronteira da aplicao, isto , armazenar os dados manti-
dos atravs de um ou mais processos elementares da aplicao, enquan-
to um Arquivo de Interface Externa (AIE) apenas referenciado pela
aplicao, ou seja, ele mantido dentro da fronteira de outra aplicao.
Assim, o objetivo de um AIE armazenar os dados referenciados por
um ou mais processos elementares da aplicao sendo contada, mas que
so mantidos por outras aplicaes.
Passo 5: Contagem das funes transacionais: as funes transacio-
nais representam as funcionalidades de processamento de dados do sis-
tema fornecidas para o usurio, tais como as entradas externas, as sadas
externas e as consultas externas. As Entradas Externas (EE) so proces-
sos elementares que processam dados (ou informaes de controle) que
entram pela fronteira da aplicao. O objetivo principal de uma EE
manter um ou mais ALI ou alterar o comportamento do sistema. As Sa-
das Externas (SE) so processos elementares que enviam dados (ou in-
formaes de controle) para fora da fronteira da aplicao. Seu objetivo
mostrar informaes recuperadas atravs de um processamento lgico
(isto , que envolva clculos ou criao de dados derivados) e no ape-
nas uma simples recuperao de dados. Uma SE pode, tambm, 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 informaes de controle) para fora da fronteira da aplicao,
mas sem a realizao de clculos nem a criao de dados derivados. Seu
objetivo apresentar informao para o usurio, por meio apenas de
uma recuperao das informaes. Nenhum ALI mantido durante sua
realizao, nem o comportamento do sistema alterado.
80
Passo 6: Determinar o valor do fator de ajuste: o fator de ajuste ba-
seado em quatorze caractersticas gerais de sistemas, que avaliam a fun-
cionalidade geral da aplicao que est sendo contada e seus nveis de
infuncia. O nvel de infuncia de uma caracterstica determinado
com base em uma escala de 0 a 5, em que 0 signifca nenhuma infuncia
e 5 signifca forte infuncia. O objetivo do fator de ajuste ajustar os
pontos de funo no ajustados em 35%.
Passo 7: Calcular os pontos de funo ajustados: neste ltimo passo,
os pontos de funo ajustados so calculados, considerando-se o tipo de
contagem defnido no primeiro passo.
6.4. Elaborao de Cronograma
possvel estimar o tempo cronolgico (durao) de cada atividade
e, consequentemente, do projeto como um todo, assim que tiverem
sido feitas as estimativas de esforo, realizando, em paralelo, a alo-
cao de recursos.
Estimativas de esforo buscam medir o esforo necessrio para com-
pletar o projeto ou cada uma de suas atividades. Estimativas de esforo
podem ser obtidas diretamente pelo julgamento de especialistas, tipica-
mente usando tcnicas de decomposio, ou podem ser computadas a
partir de dados de tamanho ou de dados histricos.
J a Alocao de recursos diz respeito a estimar os recursos necess-
rios para realizar o esforo de desenvolvimento. Quando falamos em
recursos, estamos englobando pessoas, hardware e sofware. No caso de
sofware, devemos pensar em ferramentas de sofware, tais como ferra-
mentas CASE ou sofware de infra-estrutura (por exemplo, um sistema
operacional), bem como componentes de sofware a serem reutilizados
no desenvolvimento, tais como bibliotecas de interface ou uma camada
de persistncia de dados.
Se a estimativa de esforo tiver sido realizada para o projeto como um
todo, ento ela dever ser distribuda pelas atividades do projeto. Dados
histricos de projetos j concludos na organizao so uma boa base
para se fazer essa distribuio.
No entanto, muitas vezes uma organizao no tem ainda esses dados
histricos disponveis. Embora as caractersticas do projeto sejam deter-
minantes para a distribuio do esforo, uma diretriz inicial til consiste
em considerar a distribuio mostrada na Tabela 6.5 (Falbo, 2005).
Captulo 6
81
Tabela 6.5 - Distribuio de Esforo pelas Principais Atividades do Processo
de Software.
Como dissemos, feita a distribuio do esforo por atividade e, parale-
lamente, realizando a alocao de recursos, pode-se criar uma rede de
tarefas com o esforo associado a cada uma das atividades. A partir des-
sa rede, pode-se estabelecer qual o caminho crtico do projeto, isto ,
qual o conjunto de atividades que determina a durao 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 Grf-
co de Tempo (tambm chamado grfco de Gantt), estabelecendo o cro-
nograma do projeto. Uma rede de tarefas, tambm chamada de rede de
atividades, uma representao grfca do fuxo de tarefas de um pro-
jeto. Algumas vezes a rede de tarefas usada como um mecanismo por
meio do qual a sequncia e as dependncias de tarefas so alimentadas
em uma ferramenta automtica de cronogramao de projeto. Grfcos
de Tempo podem ser elaborados para o projeto como um todo (crono-
grama do projeto), para um conjunto de atividades, para um mdulo
especfco 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 grfco de tempo (que
mostra uma parte de um cronograma de projeto que enfatiza a determina-
o do escopo conceitual para um produto de sofware 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 fnais (planejadas e reais) e
vrias outras informaes relacionadas (Pressman, 2006).
Figura 6-3: Uma rede de tarefas para desenvolvimento conceitual
Fonte: Pressman, 2006
82
Figura 6-4: Um exemplo de grfico de tempo
Figura 6-5: Um exemplo de Tabela de Projeto
A seguir, apresentamos dois modelos de planos de projeto de sofware:
Modelo 1
1. Introduo
1. Escopo e propsito do documento
2. Objetivos do Projeto
1. Objetivos
2. Funes Principais
3. Questes de desempenho
4. Restries tcnicas e administrativas
Captulo 6
83
2. Especifcao dos Requisitos
1. Especifcao dos Casos de Uso
2. Diagramas de Atividades e Tarefas
3. Diagramas de Classes e Objetos
3. Recursos humanos
1. Relao do pessoal envolvido (formao tcnica, disponibilida-
de, experincia)
2. Estrutura da equipe
3. Distribuio das tarefas (pode ser colocado junto com o
cronograma)
4. Estimativas de Projeto
1. Dados histricos
2. Tcnicas de estimativas
3. Estimativas
5. Riscos do projeto
1. Identifcao dos Riscos
2. Anlise dos riscos
1. Estimativas e probabilidade da ocorrncia de cada risco
2. Impacto no projeto
3. Prioridade (probabilidade x impacto)
3. Gerenciamento dos riscos
1. Aes a serem tomadas para reduzir a ocorrncia dos riscos
2. Aes para reduzir o impacto, casos os riscos venham a
ocorrer
6. Cronograma
1. Rede de tarefas
2. Grfco de linha-de-tempo (timeline)
3. Tabela de recursos
84
7. Recursos materiais
1. Ferramentas de sofware para desenvolvimento
2. Ferramentas de sofware para operao
3. Hardware para desenvolvimento
4. Hardware para operao
5. Outros materiais (energia, material de escritrio, etc.)
8. Mecanismos de rastreamento e controle
9. Oramento
1. Gastos com recursos materiais
2. Gastos com recursos humanos
3. Outros gastos
Modelo 2
Modelo de Documento Plano de Projeto
Ttulo: Plano de Projeto
Dados Gerais:
Projeto: <<Nome do Projeto>>
Verso: <<Nmero da Verso do Plano de Projeto>>
Responsveis: <<Nome dos Responsveis>>
Sees do Documento e Instrues para seu preenchimento:
1. Introduo
Texto livre introdutrio descrevendo o documento.
2. Escopo do Projeto
Texto introdutrio sobre o problema a ser tratado, seguido de uma iden-
tifcao de subsistemas e mdulos/macro-funes que o sistema dever
tratar, apresentada na forma de diagramas de casos de uso e descries
sucintas dos mesmos.
Captulo 6
85
3. Processo de Sofware do Projeto
Indicar o processo padro / especializado usado como base (quando
aplicvel) e o modelo de ciclo de vida adotado, com uma breve justifca-
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 Necessrios:
Recursos Humanos: <<Papis necessrios para realizar a
atividade>>
Ferramentas de Sofware: <<Tipos de Ferramentas
necessrias>>
Hardware: <<Equipamentos necessrios para realizar a
atividade>>
Procedimentos: <<Procedimentos a serem adotados>>
Tecer comentrios sobre os demais processos, sobretudo quando
houver mudanas em relao ao processo padro.
4. Equipe do Projeto
Apresentar a equipe do projeto, identifcando as pessoas e os papis que
as mesmas vo desempenhar no projeto.
5. Estimativas
5.1 Estimativa de Tamanho
Apresentar a estimativa e a base de clculo para se chegar a ela, infor-
mando o procedimento utilizado em sua elaborao.
5.2 Estimativa de Esforo
Apresentar a estimativa e a base de clculo para se chegar a ela, infor-
mando o procedimento utilizado em sua elaborao.
86
5.3 Alocao de Recursos
Apresentar a alocao de recursos para as atividades do processo.
5.4 Estimativa de Durao
Apresentar uma rede de tarefas, apontando o caminho crtico do proje-
to e um grfco de tempo para o projeto como um todo (cronograma).
5.5 Estimativa de Custo
Apresentar a estimativa de custo e a base de clculo para se chegar
a ela, informando o procedimento utilizado em sua elaborao,
quando couber.
6. Plano de Riscos
Anexar o plano de riscos, desenvolvido segundo o modelo de pla-
no de riscos.
Alm da bibliografa bsica usada neste captulo, e referenciada
em seu fnal, voc pode consultar as seguintes fontes para mais
informaes sobre gerncia de projetos de sofware.
- PRESSMAN, R. S. Engenharia de Sofware. 5. ed.,Rio de Janei-
ro: McGraw Hill, 2002.
O captulo 3 d uma viso geral da gerncia de projetos de sof-
tware, com discusses sobre pessoal e formao de equipes (se-
o 3.2), defnio do escopo do sofware (seo 3.3), estrutura
de diviso do trabalho (seo 3.4). O captulo 4 aborda o tema de
medio e mtricas nas sees 4.1 e 4.3. O captulo 5 trata com
mais detalhes do planejamento do projeto, com destaque para a
determinao do escopo (seo 5.3), estimativas (sees 5.1, 5.5,
5.6 e 5.7) e recursos (seo 5.4). O captulo 6 trata da gerncia de
riscos. Finalmente, o captulo 7 aborda a elaborao e o acompa-
nhamento do cronograma.
- SOMMERVILLE, I. Engenharia de Sofware. 6. ed. So Paulo:
Addison-Wesley, 2003.
O captulo 4 proporciona uma viso geral da gerncia de projetos de
sofware, abordando atividades da gerncia (seo 4.1), planejamento
do projeto (seo 4.2), elaborao do cronograma (seo 4.3) e gern-
cia de riscos (seo 4.4). Alm disso, h dois captulos (22 e 23) dedica-
dos, respectivamente, gerncia de pessoal e s estimativas.
Captulo 6
87
- PFLEEGER, S.L. Engenharia de Sofware: Teoria e Prtica. 2.
ed. So Paulo: Prentice Hall, 2004.
O captulo 3 dedicado ao planejamento e gerncia de proje-
tos de sofware. A seo 3.1 trata do escopo, estrutura de diviso
do trabalho e elaborao do cronograma. Na seo 3.2, h uma
discusso acerca do pessoal necessrio para o projeto e formao
de equipes. As sees 3.3, 3.4 e 3.5 discutem, respectivamente, os
temas estimativas, gerncia de riscos e plano de projeto.
- VIEIRA, M.F. Gerenciamento de Projetos de Tecnologia da
Informao. Rio de Janeiro: Editora Elsevier/ Campus, 2003.
- MARTINS,J.C.C. Gerenciando Projetos de Desenvolvimento
de Sofware com PMI, RUP e UML, 2. ed. revisada, Rio de Janei-
ro : Brasport, 2005.
- VAZQUEZ,C.E., SIMES,G.S. & ALBERT,R.M. Anlise de
Pontos de Funo: Medio, Estimativas e Gerenciamento de
Projetos de Sofware, 3. ed., So Paulo : Editora rica, 2005.
Este livro traz uma apresentao bastante detalhada do mtodo
da Anlise de Pontos de Funo, explorando a importncia da
medio (captulo 1), uma viso geral do processo de contagem
(captulo 3), detalhamento desse processo (captulos 4, 5, 6 e 7) e
estimativas (captulo 9).
Atividades
1. Tanto a estimativa de linha de cdigo (LOC), quanto a anlise
de pontos de funo (APF), so estimativas do tamanho do sof-
tware. A anlise de pontos de funo tambm tem como objetivo
medir o desenvolvimento e a manuteno de uma aplicao de
sofware. Descreva com suas palavras cada uma dessas estimati-
vas, destacando as caractersticas principais de cada uma delas, e
as principais diferenas.
2. Em relao medio do tamanho de uma aplicao de sof-
tware, na sua opinio, qual das estimativas citadas na Atividade
1 a melhor?
3. Compare os dois modelos de plano de projeto apresentados na
seo 6.4 e registre suas observaes. Qual dos modelos voc con-
sidera ser o melhor? Descreva os motivos da escolha.
88
[1] FALBO, R.A., Notas de Aula: Engenharia de Sofware.
Disponvel em http://www.inf.ufes.br/~falbo, 2005.
[2] GUSTAFSON, DAVID A. Teoria a problemas de engenha-
ria de sofware. Porto alegre: Bookman, 2003. (Coleo Schaum).
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
Captulo 6
89
Prezado aluno,
Neste captulo discutiremos mtricas de sofware no contexto de
produto, processo e projeto.
Bom estudo!
7.1. Mtricas de Software
Segundo a Wikipdia, Medio a atividade de comparar uma quanti-
dade com um padro pr-defnido. Atravs da medio o homem pode
expressar numericamente qualidades de um objeto ou fenmeno. Sem
a medio, o homem fca refm de conceitos como grande/pequeno,
forte/fraco, largo/fno, etc; porm, com a medio, o homem pode
raciocinar com mais preciso acerca das referidas qualidades.
O ato de medir envolve essencialmente a existncia de unidades de me-
dida, que so os comparativos usados na medio. Envolve tambm a
existncia de instrumentos de medio que, graduados de acordo com
a unidade de medida em questo, fornecem com variados graus de pre-
ciso a medida desejada.
Apesar dos termos medida, medio e mtrica serem frequentemente
usados num mesmo contexto, eles contm diferenas sutis que so im-
portantes de serem observadas. A palavra medida pode ser usada tanto
como substantivo quanto como verbo, tornando a defnio do termo
confusa. No contexto da engenharia de sofware, uma medida nos d
uma indicao quantitativa de da extenso, quantidade, dimenso, ca-
pacidade ou tamanho de algum atributo de um produto ou processo.
Medio o ato de determinar uma medida. J mtrica defnida 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 mtrica ou combinao de mtricas que forne-
ce profundidade na viso do processo de sofware, projeto de sofware
ou produto em si (Pressman, 2006). Para saber mais sobre a diferena
entre medida, medio e indicadores, visite o link: http://www.sinfc.pt/
SinfcNewsletter/sinfc/Newsletter50/Dossier2.html
MTRICAS DE SOFTWARE
90
O texto a seguir vai ajud-lo a entender mais sobre medida, medi-
o e mtrica.
Quando se trata de avaliao quantitativa, quatro conceitos, mui-
tas vezes usados equivocadamente com o mesmo sentido, so im-
portantes: medida, medio, mtrica e indicador.
Uma medida fornece uma indicao quantitativa da extenso,
quantidade, dimenso, capacidade ou tamanho de um atributo de
um produto ou de um processo. Quando os dados de um nico
ponto so coletados, uma medida estabelecida (p.ex., quantida-
de de erros descobertos em uma reviso).
Medio o ato de medir, isto , de determinar uma medida. J
uma mtrica procura relacionar medidas individuais com o obje-
tivo de se ter uma idia da efccia do processo, do projeto ou do
produto sendo medido. Por fm, desenvolvem-se mtricas para se
obter indicadores, isto , para se ter uma compreenso do proces-
so, produto ou projeto sendo medido.
Seja o seguinte exemplo: deseja-se saber se uma pessoa est com
seu peso ideal ou no. Para tal, duas medidas so importantes: al-
tura (H) e peso (P). Ao medir essas dimenses, est-se efetuando
uma medio. A mtrica ndice de massa corporal (IMC) cal-
culada segundo a seguinte frmula: IMC = P / H2. A partir dessa
mtrica, a Organizao Mundial de Sade estabeleceu indicado-
res que apontam se um adulto est acima do peso, se est obeso ou
abaixo do peso ideal considerado saudvel, conforme a seguir:
Se IMC < 18,5, ento o indivduo est abaixo do peso ideal consi-
derado saudvel;
Se 18,5 <= IMC < 25, ento o indivduo est com o peso normal;
Se 25 <= IMC <= 30, ento o indivduo est acima do peso;
Se IMC > 30, ento o indivduo est obeso.
Realizando medies, uma pessoa pode obter suas medidas para
altura e peso. A partir delas, pode calcular a mtrica 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 alimentao, obtendo melhorias reais para sua sade.
Fonte: Captulo 4 Gerncia da Qualidade Medio e M-
tricas (Falbo, 2005).
Captulo 7
91
O texto a seguir vai ajud-lo a entender mais sobre mtricas de sofware.
A cincia baseada em medidas. Melhorar o processo requer a
compreenso dos relacionamentos e isso requer medidas.
Medida de sofware o mapeamento de smbolos para objetos. O
propsito qualifcar alguns atributos dos objetos, por exemplo,
a medida do tamanho do projeto de sofware. Adicionalmente, o
objetivo pode ser predizer alguns atributos que no so aparente-
mente mensurveis, tais como o esforo necessrio para desenvol-
ver um projeto de sofware.
Nem todos os mapeamentos de smbolos para objetos so aplic-
veis. Uma questo importante a validao das mtricas; entre-
tanto, a validao est relacionada ao uso da mtrica. Um exemplo
a altura de uma pessoa. A altura importante para predizer a
habilidade da pessoa passar por uma porta sem bater a cabea. Ter
uma correlao entre a medida e um atributo no sufciente para
validar uma medida. Por exemplo, o tamanho do p de uma pes-
soa altamente relacionado com a altura dela; entretanto, normal-
mente no aceito como medida para a altura de uma pessoa.
Os seguintes critrios so vlidos para mtricas:
1. Uma mtrica deve permitir a distino entre diferentes entidades.
2. Uma mtrica deve obedecer a uma condio de representao.
3. Cada unidade do atributo deve contribuir com a mesma quan-
tidade para a mtrica.
4. Entidades diferentes podem ter o mesmo valor do atributo.
Muitas vezes, o interesse do atributo no diretamente mensur-
vel; nesse caso, uma medida indireta usada. Uma medida indi-
reta envolve a medida e a forma de predio. Por exemplo, densi-
dade no uma medida direta. Ela calculada a partir da massa
e do volume, que so medidas diretas. Na cincia da computao,
muitos atributos (mantenibilidade, facilidade de leitura, texta-
bilidade, qualidade, complexidade, etc.) no podem ser medidos
diretamente, e medidas indiretas para esses atributos o objetivo
de muitas mtricas de programas.
Os seguintes critrios so vlidos para mtricas indiretas:
1. O modelo deve ser explicitamente defnido.
2. O modelo deve ser dimensionalmente consistente.
3. No deve haver descontinuidade inesperada.
4. Unidades e tipos de escala devem ser corretos.
Fonte: Gustafson, 2003.
Mtricas de Software
92
Mas para que serve a medio no contexto da engenharia de sofware?
A medio pode ser aplicada em trs contextos diferentes:
1. Pode ser aplicada ao processo de sofware com o objetivo de
melhor-lo de forma contnua;
2. Pode ser usada ao longo de um projeto de software para
auxiliar em:
a. Estimativa
b. Controle da Qualidade
c. Avaliao 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 decises tticas medida
que o projeto evolui.
Esses trs contextos sero discutidos a seguir:
7.2. Mtricas de Processo
O objetivo das mtricas de processo fornecer um conjunto do que
chamamos de indicadores de processo, que leva a aperfeioamentos do
processo de sofware a longo prazo. Mtricas de processo so coletadas
no decorrer de todos os projetos e durante longos perodos de tempo.
Segundo Pressman (2006), as mtricas de sofware 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 crticas;
7. Ajustar o fuxo de trabalho ou tarefas;
8. Avaliar a capacidade da equipe de projeto em controlar a qua-
lidade dos produtos de sofware.
Captulo 7
93
As mtricas de processo (como tambm as mtricas de projeto) so me-
didas quantitativas que nos permitem ter ideia da efccia do processo de
sofware. So coletados dados bsicos de qualidade e produtividade, que
so analisados, comparados com mtricas anteriores e avaliados para
determinar se ocorreram melhorias de qualidade e produtividade. Ou
seja, o objetivo das mtricas de processo exatamente melhorar a quali-
dade do processo de desenvolvimento de sofware de forma contnua.
Como exemplo de mtricas de processo, apresentaremos a produtividade
(Gustafson, 2003). Ela calculada pela diviso do total de linhas do c-
digo-fonte entregues pelos programadores/dia atribudos ao projeto. As
unidades de medida normalmente so dadas em LOC/programador/dia.
Exemplo: Um projeto totalizou 100 KLOC. Trabalharam no projeto 20
programadores por ano. Esse ano inclui o esforo total para requisitos,
projeto, implementao, testes e fases de entrega. Assuma que existam
aproximadamente 240 dias de trabalho no ano (20 dias ao ms por 12
meses, sem frias). A produtividade dada ento por:
100.000 LOC / 20 programadores * 240 dias = 100.000 LOC / 4800 dias
= 20,8 LOC/programador/dia.
7.3. Mtricas de Projeto
Podemos dizer que as mtricas de processo so usadas com fnalida-
des estratgias, visando melhorar o processo de sofware de forma
contnua. J as mtricas de projeto so tticas. Elas podem ser usa-
das ao longo de um projeto para auxiliar na estimativa, no controle
de qualidade, na avaliao de produtividade e no controle do projeto.
Tal como as mtricas de processo, as mtricas de projeto so medidas
quantitativas que nos permitem ter a idia da efccia dos projetos que
so conduzidos usando o processo de sofware como arcabouo. Elas
so usadas pelo gerente de projeto para adaptar o fuxo de trabalho e
as atividades tcnicas do projeto.
O objetivo das mtricas de projeto duplo. Elas so usadas para:
1. Minimizar o cronograma de desenvolvimento (ou pelo menos
permitir que ele no estoure), fazendo os ajustes necessrios
para evitar atrasos, problemas e riscos em potencial;
2. Avaliar a qualidade do produto de sofware durante sua evo-
luo e, quando necessrio, modifcar a abordagem tcnica para
aperfeioar a qualidade.
Mtricas de Software
94
Geralmente, a primeira aplicao das mtricas de projeto ocorre du-
rante as estimativas (veja seo 6.3). Mtricas coletadas de projetos an-
teriores so usadas como base, a partir da qual estimativas de esforo e
tempo so feitas para o projeto atual. Conforme o projeto evolui, medi-
das de esforo e tempo despendidos so comparadas com as estimativas
originais e com o cronograma do projeto. Esses dados so usados para
monitorao e controle do progresso do projeto.
Quando o trabalho tcnico se inicia, outras mtricas comeam a ser im-
portantes, tais como a taxa de produo representada em termos de mo-
delos criados, horas de reviso (veja exerccios resolvidos do captulo 8),
pontos por funo (veja seo 6.3.2) e linhas de cdigo-fonte entregue
(veja seo 6.3.1), etc. Alm disso, so registrados os erros descobertos
durante cada tarefa de engenharia de sofware.
medida que o sofware evolui da especifcao ao projeto, mtricas
tcnicas so coletadas para avaliar a qualidade do projeto e fornecer in-
dicadores que iro infuenciar a abordagem adotada para gerao de
cdigo e teste.
7.4. Mtricas de Produto
As mtricas de produto so mtricas que podem ser calculadas para a
documentao de um produto de sofware, independentemente da for-
ma como ele foi produzido, e geralmente esto relacionadas ao cdigo
fonte, podendo ser defnidas a partir de outros documentos.
Como exemplo, podemos citar que uma mtrica possvel seria o nme-
ro de pargrafos que consistem na especifcao de requisitos.
Existem muitas taxonomias propostas para mtricas de produto. A se-
guir apresentaremos as apresentadas por Pressman (2006).
Mtricas para o Modelo de anlise: tratam de vrios aspectos do mo-
delo de anlise, entre eles:
Funcionalidade
entregue
Fornece uma medida indireta da funcionalidade
que empacotada com o sofware.
Tamanho do
sistema
Mede o tamanho global do sistema defnido em ter-
mos de informao disponvel como parte do mo-
delo de anlise.
Qualidade da
especifcao
Fornece uma indicao da especifcidade e comple-
teza de uma especifcao de requisitos.
Captulo 7
95
Mtricas para o Modelo de projeto: essas mtricas quantifcam atri-
butos do projeto de um modo que permita ao engenheiro de sofware
avaliar a qualidade do projeto. A mtrica inclui:
Mtrica arquitetural Fornece uma indicao da qualidade do proje-
to arquitetural.
Mtrica no nvel de
componente
Mede a complexidade dos componentes de
sofware e outras caractersticas que tm infu-
ncia em sua qualidade.
Mtricas de projeto
de interface
Focalizam principalmente a usabilidade.
Mtricas especializa-
das em projeto OO
Medem caractersticas de classes e suas carac-
tersticas de comunicao e colaborao.
Mtricas para cdigo-fonte: medem o cdigo-fonte e podem ser usa-
das para avaliar sua complexidade, manutebilidade e testabilidade, entre
outras caractersticas.
Mtricas de Halstead Embora controversas, fornecem medidas sin-
gulares de um programa de computador.
Mtricas de
complexidade
Medem a complexidade lgica do cdigo-fonte
(podem tambm ser consideradas como m-
tricas de projeto no nvel do componente).
Mtricas de
comprimento
Fornecem uma indicao do tamanho do
sofware.
Mtricas de teste: ajudam o projeto de casos de teste efetivos e avaliam
a efccia do teste. Podem ser:
Mtricas de cober-
tura de comando e
desvio
Levam ao projeto casos de teste efetivos e ava-
liam a efccia do teste.
Mtricas relaciona-
das a defeito
Enfocam erros encontrados, em vez dos testes
em si.
Efetividade de teste Fornece uma indicao em tempo real da efeti-
vidade dos testes que foram conduzidos.
Mtricas em
processo
Mtricas relacionadas a processo que po-
dem ser determinadas medida que o teste
conduzido.
Em muitos casos, algumas dessas mtricas podem ser usadas em ativi-
dades posteriores de engenharia de sofware, por exemplo, mtricas de
modelo de projeto podem ser usadas para estimar o esforo necessrio
para gerar cdigo-fonte.
Mtricas de Software
96
Atividades
1. Aps ler o captulo, pesquise mais sobre o tema e fale com suas
prprias palavras sobre o que so:
Mtricas de Processo t
Mtricas de Projeto t
Mtricas de Produto t
2. Fale sobre as diferenas bsicas entre esses trs tipos de mtricas.
[2] PRESSMAN, R.S., Engenharia de Sofware. So Paulo:
McGraw-Hill, 6 Edio, 2006.
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
Captulo 7
97
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
Mtricas de Software
98
Captulo 7
99
Prezado aluno,
Neste captulo vamos abordar a rea de anlise e gerenciamento de
risco.. Falaremos sobre identifcao de risco, estimativa de risco,
exposio de risco, mitigao de risco e sobre planos de gerencia-
mento de risco (Gustafson, 2003).
Bom estudo!
8.1. Introduo
Podemos considerar um risco como a possibilidade de um evento inde-
sejvel acontecer. Esse desejo indesejvel chamado de evento de risco.
Os riscos envolvem incertezas e perdas. No so considerados riscos
eventos que certamente ocorrero ou eventos que no afetam negativa-
mente o projeto.
Existe uma certa discordncia sobre quais riscos devem ser gerencia-
dos. Alguns especialistas sugerem que riscos comuns a vrios projetos
devem ser incorporados ao processo do sofware, devendo apenas ser
gerenciados os riscos que so nicos a um projeto corrente.
Segundo Pressman (2006), a anlise e gesto de riscos so uma srie de
passos que ajudam uma equipe de sofware a entender e administrar as
incertezas do projeto. Muitos problemas podem perturbar um projeto
de sofware, mas um risco um problema em potencial pois, como o
prprio nome diz, um risco um risco, e, portanto, pode ou no ocorrer.
No entanto, independentemente do resultado, importante identifcar
riscos, avaliar a probabilidade de eles ocorrerem, estimar seu impacto,
estabelecer um plano de contingncia no caso do problema efetivamen-
te ocorrer e monitorar os riscos.
ANLISE E GERENCIAMENTO
DE RISCO
100
8.2. Identificao de risco
A identifcao de risco, como o prprio nome diz, um processo que
identifca possveis riscos. Os ricos podem sem classifcados como:
Riscos de Projeto: t riscos que afetam o plano de projeto;
Riscos Tcnicos: t riscos que afetam a qualidade do projeto;
Riscos de Negcio: t riscos que afetam a viabilidade do projeto.
O exemplo a seguir, retirado de Gustafson (2003), vai ajud-lo a en-
tender a identifcao de alguns tipos de riscos. Devemos lembrar que
alguns especialistas consideram apenas os riscos que no so comuns a
todos os projetos. Esses riscos mais comuns so considerados por eles
como parte do planejamento do projeto padro da organizao.
Exemplo: Considere um projeto que envolve a tentativa de desenvolver
um sofware de segurana crtica para corte de equipamento. Liste os
riscos e classifque-os como sendo de projeto, tcnico ou de negcio, e
como comum a todos os projetos ou especial a este projeto.
Risco Projeto Tcnico Negcio Comum Especial
Equipamento no-
disponvel
X X
Requisitos
incompletos
X X
Uso de metodolo-
gias Especializadas
X X
Problemas na busca
da confabilidade
requerida
X X
Reteno de
pessoas-chave
X X
Subestimativa do
esforo requerido
X X
Desistncia do
nico cliente em
potencial
X X
Tabela 8.1 Tipos de Riscos
Um mtodo de identifcar riscos criar um checklist (veja seo 9.2).
Abaixo segue uma categorizao para riscos de sofware, que esto
associados a:
Captulo 8
101
- Tamanho do projeto.
Os riscos do projeto so diretamente proporcionais ao tama-
nho do projeto.
- Impacto nos negcios.
Aspectos comerciais muitas vezes vo de encontro realidade tcnica.
Custo (impacto) associado com atrasos na entrega do produto fnal.
- Caractersticas do usurio fnal.
Nmero de pessoas que usaro o sistema.
Nvel de sofsticao do usurio.
- Caractersticas do cliente.
J trabalhou com este cliente antes?
O cliente mostra-se acessvel e disposto a gastar tempo em reunies?
O cliente tem conhecimento (treinamento) de processos de de-
senvolvimento de sofware?
- Defnio do processo (maturidade do processo)
A empresa possui um processo de desenvolvimento de sofware
bem defnido (CMM por exemplo veja seo 9.5)?
O grupo est acostumado (treinado) a usar processos de desen-
volvimento de sofware?
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 construo 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 fnal?
Mais de 90% do cdigo ser escrito em uma linguagem de alto nvel?
- Tamanho e experincia da equipe.
A equipe possui todas as habilidades necessrias para cons-
truir o produto?
H pessoal sufciente para o projeto?
Assim que identifcamos os possveis riscos de um projeto, devemos es-
tabelecer planos de mitigao (evitar ou minimizar os riscos seo
8.5) e de contingncia (o que fazer caso o risco acontea seo 8.6).
Para isso podemos montar a seguinte tabela:
Anlise e Gerenciamento de Risco
102
Risco Probabilidade Impacto
Plano de
gerncia de
riscos
Tamanho estima-
do pode ser muito
menor que o real
baixa crtico
Equipe inexperiente mdia catastrfco
Troca de membros
da equipe
alta crtico
Complexidade da
tecnologia muito
maior que a prevista
baixa marginal
Cliente pouco
disponvel
alta negligencivel
... ... ... ...
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
ocorrncia do risco, tambm 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 ocorrncia do
risco uma tarefa muito difcil. Os riscos conhecidos so mais fceis de
gerenciar, porque se tornam parte do processo de sofware. Os riscos
mais importantes de gerenciar so os novos riscos, nicos para o projeto
corrente. J o custo de um risco pode ser mais fcil de gerenciar, depen-
dendo da experincia adquirida em projetos interrompidos.
8.4. Exposio de risco
A exposio 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-
bm uma jogada de 7 como um evento indesejvel, 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 exposio do risco.
Captulo 8
103
A probabilidade do risco de 6 dentre as 36 combinaes possveis, ou
seja, 1/6. O impacto do risco de R$ 60,00 (custo de o risco acontecer).
Assim, a exposio do risco dada pela multiplicao de 1/6 por R$
60,00, dando um valor de R$ 10,00.
8.5. Mitigao de risco
Mitigao diz respeito ao de aliviar. Ou seja, mitigao de risco
a estratgia de encontrar maneiras de se diminuir a probabilidade da
ocorrncia do risco ou diminuir o impacto da sua ocorrncia. No exis-
tem maneiras mgicas de se reduzir riscos. No entanto, consenso que,
quanto mais cedo se tentar resolver os riscos, melhor. Por exemplo, se
existe uma preocupao sobre um sistema particular que precisa ser
usado, quanto mais cedo se investigar esses sistemas, melhor. Se o siste-
ma a ser construdo precisa se comunicar com um sistema legado, por
exemplo, importante que logo no incio do projeto essa comunicao
seja testada, mesmo que seja por meio de um prottipo simples que
teste essa comunicao. Geralmente um prottipo pode ser construdo
para ajudar a identifcar os problemas antecipadamente.
Existe um termo chamado anlise e gesto de riscos (veja captulo 25
do livro do Pressman (2006) para mais informaes) que designa uma
srie de passos que ajudam uma equipe de sofware 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 sofware, e um risco um problema em potencial, que pode
ou no ocorrer, mas independentemente se ele vai ou no ocorrer,
muito importante identifcar os riscos, avaliar a probabilidade de eles
ocorrerem, estimar seu impacto e estabelecer um plano de contingncia,
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 identifcados na Tabela 8.1. Sugira uma
abordagem para diminuir a probabilidade e o impacto, ou ambos, de
cada risco.
104
Risco
Diminuir
Probabilidade
Diminuir Impacto
Equipamento no-
disponvel
Acelerar o desenvolvi-
mento do hardware
Construir simulador
Requisitos
incompletos
Ampliar reviso dos
requisitos
Uso de metodologias
Especializadas
Aumentar treinamen-
tos da equipe, consul-
tar especialistas.
Problemas na busca
da confabilidade
requerida
Projetar para
confabilidade
Reteno de
pessoas-chave
Pagar mais
Empregar pessoal
adicional
Subestimativa do
esforo requerido
Contratar especialista
externo
Desenvolver no
tempo estimado, re-
estimar sempre
Desistncia do nico
cliente em potencial
Ter avaliao externa
da rea
Identifcar outros
potenciais clientes
Tabela 8.3 Abordagens para diminuio de probabilidade e impacto de riscos
8.6. Planos de gerenciamento de risco
Na gerncia de riscos, todos os aspectos envolvidos devem ser docu-
mentados em um plano de riscos, indicando os riscos que compem o
perfl de riscos do projeto, as avaliaes dos riscos, a defnio dos riscos
a serem gerenciados e as aes 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. Identifcador do risco
2. Descrio do risco
3. Estimativa de probabilidade do risco
4. Estimativa do impacto do risco
5. Lista de estratgias de mitigao dos riscos
6. Planos de contingncia
7. Marcos de risco
8. Indivduos responsveis (equipe)
Ainda no falamos sobre marcos de risco. Os marcos de risco servem
para identifcar quando os planos de contingncia devem ser ativados.
Captulo 8
105
bom ressaltar que outros campos podem ser adicionados ao plano
de riscos. Esta apenas uma sugesto 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 formulrio para gerenciamento de risco e in-
sira dados de exemplo.
Risco: 1-010-77 Probabilidade: 10% Impacto: muito alto
Descrio: hardware especializado pode no estar disponvel
Estratgia de Mitigao: construir simulador, acelerar desenvolvi-
mento do hardware
Marco do risco: hardware estragar uma semana ou mais aps calendrio
Plano de Contingncia: ter desenvolvimento externo de hardware
como backup, implantar sistemas em um simulador
Status/data/responsvel:
Criao 01/jan/08 Marcos Silva
Simulao Completada 10/fev/08 Flvio 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 tm de ser monitorados para se verifcar se os problemas
esto se tornando realidade ou no. Novos riscos podem ser identif-
cados, o grau de exposio de um risco pode mudar e algumas aes
podem precisar ser tomadas.
Atividades
1. Depois de ler todo este captulo, descreva com suas prprias 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 sofware? 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
Exerccios Resolvidos
1. Descreva alguns riscos normais que podem acontecer em qual-
quer projeto de sofware.
2. Considere um projeto que tem 0.5% de probabilidade de
uma falta no-detectada causar companhia um prejuzo de R$
100.000,00. Calcule a exposio do risco.
3. Considere o uso de uma reviso adicional para o problema 2
que custaria R$ 100,00, mas eliminaria tal falta em 50% das vezes.
Calcule essa nova exposio de risco usando a reviso adicional.
A abordagem de reviso adicional melhor?
4. O que mudaria na Atividade 3 se uma reviso adicional fosse
efetiva em 10% das vezes?
5. A companhia X possui dados histricos que mostram que a m-
dia de erros normais de 0,0036 erros por KLOC. Uma nova tc-
nica de reviso custa R$ 1000,00 por 100 KLOC e decresce o n-
mero de erros em 50%. Assuma que cada erro custe companhia
uma mdia de R$ 10.000,00. O projeto em andamento estimado
em 50 KLOC. Calcule a exposio do risco de cada abordagem. A
nova tcnica de reviso efciente?
Fonte: Adaptado de Gustafson, 2003;
Respostas dos Exerccios
1. Riscos comuns e normais a todos os projetos de sofware so, por
exemplo: no entendimento dos desejos e necessidades dos usurios,
falta de comunicao ou comunicao falha com o usurio, problemas
com o hardware do usurio, o projeto ultrapassar o custo, atraso no pro-
jeto, entre outros.
2. A exposio do risco calculada multiplicando-se a probabilidade
do risco pelo custo do evento de risco. A exposio do risco dada pela
soma da exposio do risco para cada possibilidade:
0,005 * 100.000,00 + 0,995 * 0 = R$ 500,00.
Note que em ambos os clculos da exposio do risco, os custos
foram acrescentados em R$ 100,00.
3. A nova exposio do risco dada por:
0,025 * 100.100,00 + 0,9975 * 100 = R$ 250,25 + 99,75 = R$ 350,00.
Captulo 8
107
Observe que para este novo clculo 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 reviso adicional melhor.
4. A nova exposio do risco dada por:
0,0045 * 100.100,00 + 0,9955 * 100 = R$ 450,45 + 99,55 = R$ 350,00.
Observe que este novo clculo 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 reviso
O clculo de exposio do risco dado por:
0,0036 * 50 KLOC * R$ 10.000,00 = R$ 1.800,00
Caso 2 Com reviso
O clculo de exposio do risco dado por:
0,0018 * 50 KLOC * R$ 10.000,00 + R$ 500,00 = R$ 1.400,00
Note que a mdia 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 reviso de 1.000 por 100 KLOC e o projeto est estimado em
50 KLOC (metade do custo de reviso).
[2] PRESSMAN, R.S. Engenharia de Sofware. So Paulo:

108
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
____________________________________________________
Captulo 8
109
Prezado aluno,
Produzir software de qualidade uma das principais metas da
engenharia de software. Neste captulo iremos discutir alguns
assuntos mais comuns relacionados garantia da qualidade
de software, tais como inspeo formal e tcnicas de reviso,
confiabilidade do software, garantia estatstica de qualidade
de software e normas e modelos de qualidade de processo de
software.
Bom estudo!
9.1. Introduo
Como vimos em vrios momentos deste material, construir sofware de
qualidade uma das principais metas da engenharia de sofware. No en-
tanto, qualidade no se consegue de forma espontnea. Muito mais do
que isso, a qualidade deve ser construda em um produto de sofware.
Mas o que seria um sofware de qualidade? Podemos considerar um
sofware de qualidade aquele que faz o que se espera que ele faa, e uma
das formas mais fceis de defnir se um sofware ou no de qualidade
olhar para a satisfao do usurio. Para se medir a satisfao do usurio,
a maneira usual o relatrio de defeitos. Por esse motivo, para se alcan-
ar qualidade, a tcnica principal ainda a reviso de sofware, que tem
por objetivo encontrar erros. (Gustafson, 2003).
Abordagens Formais para alcanar a qualidade de sofware tm de-
monstrado serem mais efcientes que abordagens informais. Na prxi-
ma seo discutiremos sobre revises tcnicas formais.
9.2. Revises Tcnicas Formais
Segundo Pressman (2006), uma Reviso Tcnica Formal uma ativida-
de de garantia da qualidade de sofware realizada por engenheiros de
sofware (e outros). Os objetivos das Revises Tcnicas Formais so:
GARANTIA DE QUALIDADE DE
SOFTWARE
110
1. Descobrir erros na funo, lgica ou implementao, para qual-
quer representao do sofware;
2. Verifcar se o sofware sob reviso satisfaz seus requisitos;
3. Garantir que o sofware tenha sido representado de acordo com
padres pr-defnidos;
4. Conseguir sofware que seja desenvolvido uniformemente;
5. Tornar os projetos mais administrveis.
Durante uma reviso tcnica, um revisor registra todos os tpicos le-
vantados. Ao fnal da reunio esses tpicos so resumidos e registrados
numa lista de tpicos de reviso. Alm disso, deve ser realizado um
relatrio resumido da reviso tcnica, que responda s questes abaixo:
1. O que foi revisado?
2. Quem fez a reviso?
3. Quais foram as descobertas e concluses?
A lista de questes de reviso serve para identifcar reas problemticas
no produto e servir como checklist de itens de ao, orientando o desen-
volvedor de sofware medida que as correes so efetuadas. Geral-
mente a reviso tcnica se incorpora ao registro histrico do projeto.
Checlists
Um checkist uma lista de itens que devem ser verifcados durante
uma reviso tcnica. Algumas vezes os itens so colocados como
questes que devem ser respondidas. A vantagem de uma checklist
focar a ateno do revisor nos problemas potenciais. Qualquer
falha encontrada deve ser analisada para verifcar se o item da lista
garante o foco no problema detectado. Itens de uma checklist que
no so efcientes em encontrar erros durante a inspeo devem
ser removidos, pois uma quantidade grande de itens na checklist
ir prejudicar a efcincia da inspeo.
Fonte: Gustafson, 2003.
9.3. Confiabilidade do Software
A qualidade, portanto, uma propriedade multidimensional que inclui,
alm da confabilidade de sofware, outros fatores de satisfao do clien-
te como funcionalidade, usabilidade, desempenho, habilidade de pres-
tao de servio, manutenibilidade e documentao.
Captulo 9
111
Na verdade, a confabilidade um atributo de qualidade de suma im-
portncia para qualquer produto. Em relao a sofware, este atributo
geralmente defnido como a probabilidade do sofware operar sem
ocorrncia de falhas durante um perodo especifcado de tempo em um
determinado ambiente.
Segundo Gustafson (2003), a confabilidade de sofware a medida
de quo frequentemente o sofware encontra uma entrada de dados
ou outra condio que no processa corretamente para produzir a res-
posta certa. A ocorrncia de falhas do sofware no tem relao com o
seu uso demasiado.
Geralmente a confabilidade denominada por R(n), onde n um n-
mero de unidade de tempo como, por exemplo, dia, ms, ano etc. Se
a unidade de tempo dada em dias, R(1) signifca a probabilidade do
sofware no falhar em 1 dia. A probabilidade de falha em um perodo
de tempo especifcado (dada por f(n)) 1 menos a confabilidade para
o mesmo perodo de tempo, ou seja, F(n) = 1 R(n) (Gustafson, 2003).
9.4. Garantia Estatstica de Qualidade de
Software
Tambm chamada de Garantia da Qualidade Estatstica (SQA Statisti-
cal Quality Assurence), esse termo diz respeito ao uso da estatstica para
estimar a qualidade de sofware. Por exemplo, executar o cdigo com
um pequeno conjunto de casos de testes randmicos nos dar resulta-
dos que podem ser usados para estimar a qualidade (esse procedimento
algumas vezes chamado de prova de sofware). A mdia de erros na
amostra aleatria pode ser usada como uma estimativa para a mdia de
erros no projeto fnal. Se a porcentagem de execues corretas alta,
ento o desenvolvimento est indo bem. Caso contrrio, ou seja, se
baixa, ento possvel que seja necessria a tomada de algumas aes de
remediao para o processo de desenvolvimento (Gustafson, 2003).
A Garantia da Qualidade Estatstica, ou ainda, Garantia Estatstica
da Qualidade, refete uma tendncia crescente em toda a indstria em
tornar-se cada vez mais quantitativa a respeito da qualidade. Em rela-
o a sofware, a garantia estattica de qualidade implica os seguintes
passos (Pressman, 2006):
1. So coletadas informaes sobre defeitos de sofware, que de-
pois so categorizadas;
2. feita uma tentativa de rastrear cada defeito at a sua causa
subjacente (por exemplo, no conformidade com as especifca
Garantia de Qualidade de Software
112
es, erro do projeto, violao de normas, pouca comunicao
com o cliente);
3. Usando o princpio de Pareto, que diz que 80% dos defeitos po-
dem ser rastreados at 20% de todas as causas possveis, isola-se
os 20% (os pouco vitais);
4. Depois de identifcadas as poucas causas vitais, devemos tentar
corrigir os problemas que causaram os defeitos.
O exemplo a seguir, extrado de Pressman (2006), ilustra o uso de mto-
dos estatsticos no trabalho de engenharia de sofware.
Exemplo: Considere que uma organizao de engenharia de sofware
coleta informao sobre defeitos durante um perodo de um ano. Alguns
dos defeitos so descobertos medida que o sofware desenvolvido.
Outros so encontrados depois que o sofware foi entregue a seus usu-
rios fnais. Apesar de centenas de diferentes erros serem descobertos,
todos podem ser rastreados at uma (ou mais) das seguintes causas:
Especifcaes incompletas ou errneas (Incomplete or Erroneous t
Specifcations IES);
M interpretao da comunicao com o cliente (Misinterpretation t
of Customer Communication MCC);
Desvio intencional das especifcaes (Intentional Deviation Speci- t
fcations IDS);
Violao das normas de programao (Violation of Programming t
Standards VPS);
Erro na representao dos dados (Error in Data Representation t
IDR);
Interface de componente inconsistente (Inconsistent Component t
Interface ICI);
Erro na lgica do projeto (Error em Design Logic EDL); t
Teste incompleto ou errneo (Incomplete or Erroneous Testing t
IET);
Documentao imprecisa ou inclompleta (Inaccurate or Incomplete t
Documentation IID);
Erro na traduo do projeto para a linguagem de programao (Er- t
ror in Programming Language Translation of Design PLT);
Captulo 9
113
Interface homem-computador ambgua ou inconsistente (Ambi- t
guous or Inconsistent Human/Computer Interface HCI);
Miscelnia (MIScellaneous, MIS). t
Para aplicar SQA estatstica, a tabela da Figura 9.1 foi construda. A ta-
bela indica que IES, MCC e EDR so 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 srios. Uma vez determinadas as pou-
cas causas vitais, a organizao de engenharia de sofware pode iniciar
ao corretiva. Por exemplo, para corrigir MCC, o desenvolvedor de
sofware poderia implementar tcnicas facilitadas de coleta de requi-
sitos para aperfeioar a qualidade das especifcaes e da comunicao
com o cliente. Para aperfeioar EDR, o desenvolvedor poderia adquirir
ferramentas para a modelagem de dados e realizar revises mais estritas
do projeto dos dados.
importante notar que a ao corretiva focaliza principalmente as pou-
cas causas vitais. medida que as poucas causas vitais so corrigidas,
novas candidatas despontam no topo da pilha.
Tem sido mostrado que as tcnicas de garantia estatstica de qualidade
de sofware propiciam aperfeioamentos substanciais qualidade. Em al-
guns casos, organizaes de sofware conseguiram uma reduo de 50%
dos defeitos por ano, depois de aplicar essas tcnicas.
A aplicao da SQA estatstica e do princpio de Pareto pode ser resu-
mida em uma nica sentena: 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 estatstica
114
9.5. Normas e Modelos de Qualidade de Proces-
so de Software
Conforme visto no captulo 4, os modelos de ciclo de vida consistem
em uma seqncia de diferentes atividades bsicas que so executa-
das durante o desenvolvimento de sofware. Os modelos de ciclo de
vida constituem um importante ponto de partida para a defnio de
processos. No entanto, eles no so sufcientes; afnal, um processo
de sofware um conjunto de processos, em que podemos destacar o
processo de desenvolvimento.
H outros processos, tais como o processo de gerncia de projetos e o
processo de garantia da qualidade. No entanto, para o sucesso na def-
nio e melhoria dos processos de sofware fundamental que vrios
aspectos sejam considerados. nesse momento que entram as Nor-
mas e Modelos de Qualidade de Processo. Tais normas e modelos tm
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 defnido como a estrutura
organizacional, responsabilidades, procedimentos, processos e recursos
para implementar a gesto da qualidade. Tais sistemas so criados para
ajudar as organizaes a garantir que seus produtos e/ou servios satis-
faam as expectativas dos clientes, estando em conformidade com suas
especifcaes.
A ISO 9000 possui vrios modelos de sistemas de garantia de quali-
dade. Ela descreve os elementos de garantia de qualidade em termos
genricos, que podem ser aplicados a qualquer negcio, independente-
mente dos produtos ou servios oferecidos. Para o registro em um dos
modelos de sistema de garantia de qualidade contidos na ISO 9000, o
sistema e operaes de qualidade da empresa so analisados e avaliados
por auditores externos que verifcam o atendimento das normas e da
efetividade da operao. Aps o registro bem sucedido, a empresa rece-
be um certifcado de um corpo de registro representado pelos auditores
(Pressman, 2006).
Captulo 9
115
ISO a sigla da Organizao Internacional de Normalizao (In-
ternational Organization for Standardization), que tem sede em
Genebra, Sua e que cuida da normalizao (ou normatizao)
em nvel mundial. A ISO cria normas nos mais diferentes seg-
mentos, variando de normas e especifcaes de produtos, ma-
trias-primas, em todas as reas. A ISO fcou popularizada pela
srie 9000, ou seja, as normas que tratam de Sistemas para Gesto
e Garantia da Qualidade nas empresas.
Em 1987, a ISO editou a srie 9000 com o objetivo de estabelecer
critrios para implantao de Sistemas de Garantia da Qualidade.
A primeira verso criou uma estrutura de trs normas sujeitas
certifcao, a ISO 9001, 9002 e 9003, alm da ISO 9000, que era
uma espcie de guia para seleo da norma mais adequada ao tipo
de organizao. Com trs anos de atraso, a ABNT emitiu a pri-
meira verso (traduo) da srie no Brasil. A mesma foi nomeada
srie NBR 19000. Em 1994, a srie foi revisada, porm sem gran-
des modifcaes, apenas com uma pequena ampliao e alguns
esclarecimentos em seus requisitos, mantendo a mesma estrutura,
ou seja, trs normas sujeitas certifcao; em paralelo, a ABNT
revisou as normas brasileiras, adotando o nome srie NBR ISO
9000, alinhando-se com o resto do mundo, que j adotava no-
menclatura similar para suas verses nacionais. Em Dezembro de
2000, a srie foi totalmente revisada; alm das alteraes em sua
estrutura, tendo apenas a ISO 9001 sujeita certifcao.
Fonte: http://www.comexito.com.br/ISO9001/sobre_a_ISO9001.doc
Acesso em: 07/03/2009.
A srie NBR ISO 9000:2000
As normas da famlia NBR 9000 foram desenvolvidas para apoiar or-
ganizaes de todos os tipos e tamanhos na implementao e operao
de sistemas efcazes de gesto da qualidade. As normas que compem a
srie ISO 9000:2000 so (Falbo, 2005):
NBR ISO 9000: t descreve os fundamentos de sistemas de gesto
da qualidade e estabelece a terminologia para esses sistemas;
NBR ISO 9001: t especifca os requisitos para um sistema de ges-
to da qualidade com enfoque na satisfao do cliente. Para uma or-
ganizao ser certifcada ISO 9001, ela precisa demonstrar sua capa-
cidade para fornecer produtos que atendam aos requisitos do cliente
(explcitos e implcitos) e os requisitos regulamentares aplicveis;
116
NBR ISO 9004: t fornece diretrizes que consideram tanto a efc-
cia como a efcincia do sistema de gesto da qualidade. Seu objetivo
melhorar o desempenho da organizao e a satisfao dos clientes
e das demais partes interessadas;
NBR ISO 19011: t fornece diretrizes sobre auditoria de sistemas
de gesto da qualidade e ambiental.
A ISO 9000 de carter geral, ou seja, no se destina especi-
ficamente indstria de software e estabelece requisitos mni-
mos da garantia da qualidade que devem ser atendidos pelos
fornecedores de produtos ou servios. Ela uma norma certi-
ficadora. Essa certificao, mundialmente reconhecida, feita
por organismos certificadores, em geral, credenciados por or-
ganismos nacionais de acreditao, no caso do Brasil, o INME-
TRO. Assim, a conquista da certificao ISO 9000 por uma em-
presa significa que a mesma alcanou um padro 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 inds-
tria de sofware, muitos problemas surgem pela falta de diretrizes
mais focadas nas caractersticas de processos de sofware. De ma-
neira geral, outras normas e modelos de qualidade so usadas por
organizaes de sofware para apoiar uma certifcao 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 Sofware.
Para saber mais sobre as Normas da Srie ISO 9000 visite o link:
http://allchemy.iq.usp.br/sedimentando/iso.htm
Acesso em 07/03/2009.
Captulo 9
117
[2] PRESSMAN, R.S., Engenharia de Sofware. So Paulo:
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
___________________________________________________
118
Captulo 9
119
FALBO, Ricardo de Almeida. Notas de Aula: Engenharia de Sof-
tware. Disponvel em http://www.inf.ufes.br/~falbo, 2005.
GUSTAFSON, David A. Teoria a problemas de engenharia de
sofware. Porto alegre: Bookman, 2003. (Coleo Schaum).
PRESSMAN, Roger S. Engenharia de Sofware. 6 ed. So Paulo:
McGraw-Hill, 2006.
SOMMERVILLE, Ian. Engenharia de Sofware. 6 ed. So Paulo:
Pearson Addison Wesley, 2003.
PAULA FILHO, Wilson de Pdua. Engenharia de Sofware: fun-
damentos, mtodos e padres. 2 ed. Rio de Janeiro: LTC, 2003.
120
121
Projeto Loja Vitria
Documento de Especifcao de Anlise
1. Introduo
Este documento contm a especifcao de anlise para o projeto de
informatizao da Loja Vitria. Essa atividade foi desenvolvida em duas
etapas principais, a primeira focando a estrutura de informao do sis-
tema (classes, atributos e associaes), a segunda, seu comportamento
(operaes e trocas de mensagem entre objetos). Na seo 2, so apre-
sentados os produtos da primeira etapa, a saber: Diagrama de Pacotes e
Diagramas de Classes (um para cada pacote). Na seo 3, so apresen-
tados os produtos da segunda etapa: Diagramas de Transio de Esta-
dos (para as classes com comportamento varivel ao longo do tempo)
e Diagramas de Sequncia (agrupados por casos de uso), fechando o
conjunto de produtos gerados na fase de anlise.
2. Modelo de Classes
A modelagem de classes envolve a identifcao de classes, atributos,
relacionamentos e operaes, bem como o agrupamento de classes em
subsistemas ou pacotes. Uma vez que, muitas vezes, difcil identif-
car todos os atributos e, principalmente, todas as operaes atravs da
modelagem de classes, foram construdos modelos de comportamento,
apresentados na seo 3. importante ressaltar que os modelos apre-
sentados nesta seo, contudo, j espelham os resultados obtidos com a
modelagem do comportamento.
ANEXO A
122
2.1 Diagrama de Pacotes
O propsito de um diagrama de pacotes prover uma viso de nvel
mais alto do sistema, mostrando sua decomposio em subsistemas. O
ponto de partida para essa decomposio o domnio do problema e,
portanto, a decomposio utilizada no modelo de casos de uso foi trans-
posta para o modelo de classes, como mostra a fgura A.1.
Figura A.1 Diagrama de Pacotes
O diagrama da fgura A.1 mostra a dependncia principal entre os subsis-
temas, indicando que o pacote ControleNotaFiscal solicita servios do
pacote ControleInterno para poder cumprir suas responsabilidades.
Na prxima seo, so apresentados os diagramas de classes para cada
um desses pacotes.
2.2 Diagramas de Classes
A fgura A.2 apresenta o Diagrama de Classes referente ao pacote
ControleInterno.
Figura A.2 Diagrama de Classes do Pacote ControleInterno.
No foram representadas no diagrama as operaes bsicas para criar e
destruir instncias de uma classe, para estabelecer e navegar associaes
e para obter e atribuir valores para atributos.
ANEXOS
123
A fgura 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 integrao entre esses subsistemas.
Figura A.3 Diagrama de Classes do Pacote ControleNotaFiscal.
Assim como para o Diagrama de Classes do pacote ControleInterno,
no foram representadas no diagrama as operaes bsicas.
3. Modelo Comportamental
A modelagem do comportamento dos objetos visa apoiar a identifca-
o de atributos e operaes de classes. Nesta seo, so apresentados os
Diagramas de Estados, os Diagramas de Sequncia e as descries das
operaes das classes.
3.1 Diagramas de Transio de Estados
3.1.1 Classe Cliente do Pacote ControleInterno
A fgura A.4 mostra o diagrama de estados da classe Cliente. Os even-
tos mostrados dizem respeito realizao dos casos de uso ou eventos
dos mesmos. Esse diagrama deu origem ao atributo estado da classe
ANEXO A
124
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 no realizou nenhuma compra. A partir do momento em
que so emitidas notas fscais 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.
Alm disso, se for desejado, o evento Desativar Cliente modifca o es-
tado de clientes ativos ou preferenciais para Inativo, sendo essa uma
operao reversvel.
Figura A.4 Diagrama de Estados da Classe Cliente do Pacote ControleInterno.
3.2 Diagramas de Seqncia
A seguir, so apresentados os Diagramas de Sequncia construdos nes-
te projeto. Apenas os cursos normais dos casos de uso / cenrios foram
considerados para a elaborao desses diagramas e, portanto, na ativi-
dade de Projeto Detalhado das Operaes (Projeto de Objetos) da fase
de Projeto, os cursos alternativos devem ser incorporados.
ANEXOS
125
Caso de Uso Cadastrar Cliente / Evento Incluir Novo Cliente
Caso de Uso Cadastrar Cliente / Evento Ativar Cliente
ANEXO A
126
Caso de Uso Cadastrar Cliente / Evento Excluir Cliente
Caso de Uso Controlar Nota Fiscal de Sada / Evento Emitir Nota Fiscal
ANEXOS
127
Caso de Uso Emitir Relatrio / Evento Listar Notas Fiscais de Sada
ANEXO A
128
ANEXOS
129
Projeto Loja Vitria
Documento de Especifcao de Projeto
1. Introduo
Este documento contm a Especifcao de Projeto para o sistema da
Loja Vitria. 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 identifcados, a segunda tratando do projeto detalhado das classes
identifcadas anteriormente (projeto de operaes e estruturas de dados
internas). A seo 2 discute a plataforma de implementao conside-
rada. Na seo 3, apresentada a arquitetura do sistema, na forma de
Diagramas de Pacotes. As sees 4, 5, e 6 apresentam os Diagramas de
Classes para cada um dos subsistemas identifcados, organizados por
esteretipos, quando necessrio. Para as Componentes de Gerncia de
Dados, so apresentados, ainda, os Diagramas Relacionais correspon-
dentes, tendo em vista o uso de bancos de dados relacionais para a per-
sistncia de objetos.
2. Plataforma de Implementao
O sistema proposto ser implementado usando a linguagem de pro-
gramao Java. Alm disso, a persistncia dos objetos ser feita em um
banco de dados relacional.
3. Arquitetura do Sistema
A organizao de classes em pacotes deve ser o ponto de partida para
a defnio da arquitetura do sistema, j que um meio de estabelecer
nveis de abstrao para o modelo. Esses nveis de abstrao podem ser
ANEXO B
130
organizados em camadas e, assim, tratados separadamente durante a
fase de projeto. A organizao de classes em pacotes til tambm para
permitir a produo de componentes para reuso.
Neste trabalho, foram utilizadas duas formas complementares de agru-
pamento de classes em pacotes: primeiramente pelo domnio do proble-
ma, aproveitando os subsistemas defnidos na fase de anlise, e depois
por esteretipos, tendo sido utilizados os esteretipos propostos por
Coad e Yourdon [Coad93]. Sendo assim, o diagrama de pacotes de nvel
mais alto, mostrado na fgura B.1, praticamente o mesmo da fase de
anlise, exceto pela introduo do pacote Utilitario, que trata classes
reutilizveis em outros contextos.
O diagrama da fgura B.1 mostra as dependncias entre os subsistemas,
indicando que os pacotes ControleInterno e ControleNotaFiscal soli-
citam servios ao pacote Utilitario. Mantendo a coerncia com o dia-
grama da fase de anlise, o pacote ControleNotaFiscal solicita servios
do pacote ControleInterno.
Os pacotes ControleInterno e ControleNotaFiscal foram decompos-
tos em outros pacotes segundo os esteretipos, dando origem a novos
diagramas de pacotes, a serem discutidos nas prximas sees.
Figura B.1 Diagrama de Pacotes
4. O Pacote Controle Interno
Este pacote foi decomposto no diagrama de pacotes da fgura B.1, agora
tomando por base os esteretipos.
ANEXOS
131
Figura B.2 Diagrama de Pacotes do Pacote Controle Interno
4.1. Pacote CDP do ControleInterno
A fgura B.3 apresenta o Diagrama de Classes referente Componente do
Domnio 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 realar que as alteraes introduzidas em relao ao mo-
delo de anlise dizem respeito a requisitos no funcionais importantes
para o sistema, tais como:
ANEXO B
132
Reusabilidade: t visando construir classes reutilizveis em
domnios diversos, optou-se por desenvolver uma hierar-
quia de Pessoa (pacote Utilitario.Pessoa). Essa hierarquia
foi utilizada como base de herana para as classes Fornece-
dor e Cliente. Como clientes podem ser pessoas fsicas ou ju-
rdicas (podendo estas ainda ser fornecedores), foi adotada
a herana por composio para garantir a Cliente o compor-
tamento desejado.
Facilidade de Uso: t 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 fgura B.4 apresenta o Diagrama de Classes referente Componente
de Gerncia 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 aplicao,
responsvel pelos casos de uso Cadastrar Cliente, Cadastrar Fornecedor
e Cadastrar Produto. Essa classe est relacionada aplicao principal
do ambiente, criada no pacote ControleNotaFiscal.
ANEXOS
133
4.3. Pacote CIH do ControleInterno
A fgura B.5 apresenta o Diagrama de Classes (parcial) referente Com-
ponente de Interao Humana do pacote ControleInterno.
Figura B.5 Diagrama de Classes do Pacote CIH do ControleInterno

4.4. Pacote CGD do ControleInterno
Como a persistncia 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
responsveis pela interao direta com o BD relacional e, consequen-
temente, com conhecimento de JDBC e SQL. Para tal, foi utilizada a
camada de persistncia apresentada na seo 6.4. Nessa infra-estrutura,
para cada classe a ser persistida que possua uma tabela correspondente
no BD deve ser criada uma classe-sombra, responsvel pela interao
com a base de dados relacional, como mostra a fgura B.6.
Figura B.6 Diagrama de Classes do Pacote CGD do ControleInterno
ANEXO B
134
Uma caracterstica marcante dessa abordagem a necessidade de se es-
tabelecer identifcadores nicos para os objetos (IDOs) a serem persis-
tidos. Usando a camada de persistncia, todas as classes cujos objetos
tm de ser persistentes passam a herdar de ClasseBasePersistencia, que
responsvel pelos IDOs.
Alm disso, foi necessrio construir um Diagrama Relacional, mape-
ando as classes e objetos em tabelas e linhas. O Diagrama Relacional
referente ao pacote ControleInterno apresentado na fgura 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 tm 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 fgura B.8, agora
tomando por base os esteretipos.
ANEXOS
135
Figura B.8 Diagrama de Pacotes do Pacote Controle Nota Fiscal
5.1. Pacote CDP do ControleNotaFiscal
A fgura B.9 apresenta o Diagrama de Classes referente Componente do
Domnio 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 realar que as alteraes introduzidas em relao ao mo-
delo de anlise dizem respeito a requisitos no 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 fscal para
que se saiba o seu valor total, foi introduzido o atributo valor na classe
NotaFiscalSada, para armazenar esse dado, evitando operaes desne-
cessrias. 5.2. Pacote CGT do ControleNotaFiscal
ANEXO B
136
A fgura B.10 apresenta o Diagrama de Classes referente Componente
de Gerncia 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 aplicao:
- AplControlarNotaFiscal: que agrupa as funcionalidades des-
critas nos casos de uso Registrar Nota Fiscal e Emitir Nota Fiscal;
- AplEmitirRelatorio: responsvel pela criao de relatrios (caso
de uso Emitir Relatrio);
- AplPrincipal: que a aplicao principal do sistema, respons-
vel por gerenciar as outras aplicaes.
5.3. Pacote CIH do ControleNotaFiscal
A fgura B.11 apresenta o Diagrama de Classes (parcial) referente
Componente de Interao Humana do pacote ControleNotaFiscal.
Figura B.11 Diagrama de Classes do Pacote CIH do ControleNotaFiscal
ANEXOS
137
A classe JanPrincipal janela de abertura do sistema e contm os menus de
acesso s funcionalidades, a classe JanRelatorio possui uma srie de subclas-
ses responsveis pela exibio dos relatrios especfcos, e a classe JanFiltro
funciona como auxiliar para seleo de dados na emisso de relatrios.
5.4. Pacote CGD do ControleNotaFiscal
Conforme discutido na seo 4.4, a persistncia dos objetos ser realiza-
da atravs da camada de persistncia 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, responsvel pela inte-
rao com o BD, como mostra a fgura B.12.
Figura B.12 Diagrama de Classes do Pacote CGD do ControleNotaFiscal
Alm das classes sombra, e necessrio construir um Diagrama Relacional,
mapeando as classes e objetos em tabelas e linhas. O Diagrama Relacional
referente ao pacote ControleNotaFiscal apresentado na fgura B.13.
Figura B.13 Diagrama Relacional do Pacote CGD do ControleNotaFiscal
ANEXO B
138
No pacote ControleNotaFiscal, para cada classe persistente foi criada
uma tabela correspondente. Para a hierarquia de notas fscais foi ado-
tada a abordagem de criao de uma tabela por classe, dando origem
s tabelas NotaFiscal, NotaFiscalEntrada e NotaFiscalSada. Vale realar
que, quando h relacionamento entre tabelas originado de herana entre
classes, os IDOs dos registros na hierarquia devem ser idnticos, dado
que um objeto deve possuir um nico identifcador. As tabelas Cliente,
Fornecedor e Produto tm origem no pacote ControleInterno.
6. O Pacote Utilitrio
Este pacote contm vrios pacotes de utilitrios, que podem ser teis
em diversos sistemas. Nesta seo so apresentados somente os pacotes
utilizados neste sistema.
6.1 Pacote Pessoa
Este pacote contm classes para tratar aspectos gerais de pessoas fsicas
e jurdicas, comuns a vrios sistemas, como mostra a fgura B.14a.
A fgura B.14b exibe as classes-sombra deste pacote. H apenas uma clas-
se-sombra responsvel pela hierarquia de pessoa, dado ao fato da utiliza-
o da abordagem de criao de uma nica tabela para toda a hierarquia.
Figura B.14a - Diagrama de Classes do Pacote Utilitario.Pessoal
ANEXOS
139
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 manipulao de listas, iteradores, comparadores, datas etc. A fgura
B.15 mostra a classe Data utilizada neste sistema.
Figura B.15 Classe Data
6.3. Pacote InterfaceUsuario
Este pacote contm classes para tratar de aspectos gerais de interfaces
grfcas, comuns a vrios sistemas, como mostra a fgura B.16.
Figura B.16 Diagrama de Classes Pacote Utilitario.
InterfaceUsuario
ANEXO B
140
PainelCadastroTabela: t classe abstrata que representa o painel
de cadastro utilizado em situaes em que necessrio o ca-
dastro de objeto.
JanDados: t janela abstrata utilizada como receptora dos dados
de objetos durante um cadastro.
PainelSelecao: t classe que possui duas listas de objetos, das quais
podem ser selecionados e transferidos de uma lista para outra.
JanRelatorio: t janela abstrata utilizada tipicamente para exibi-
o de listagens.
6.4. Pacote Persistncia
Este pacote contm a camada de persistncia, responsvel por tratar
aspectos gerais de gerncia de dados, comuns a vrios sistemas, como
mostra a fgura B.17.
Figura B.17 Diagrama de Classes da Camada de Persistncia
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 obtm os novos identifcadores, e
o atributo IDO que se mantm encapsulado e isolado das subclasses do
domnio. As operaes de persistncia 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 operaes de persistncia, possibi-
litando que as classes-sombra sejam o mais simples possvel. A classe
associa-se com a Conexao utilizada para acessar o banco; um Registro,
que guarda informaes a respeito de objetos e das tabelas nas quais
so persistidos, e com o Bufer, que armazena objetos para melhorar o
desempenho das aplicaes.
ANEXOS

Apostila Engenharia de Software

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Apostila Engenharia de Software

Uploaded by

Copyright:

Available Formats

PROF.

TNIA BARBOSA SALLES GAVA

You might also like