Escolar Documentos
Profissional Documentos
Cultura Documentos
INTRODUO ENGENHARIA DE
SOFTWARE E QUALIDADE DE
SOFTWARE
Parceria
Universidade Federal de Lavras - UFLA
Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE
Reitor
Antnio Nazareno Guimares Mendes
Vice-Reitor
Ricardo Pereira Reis
Diretor da Editora
Marco Antnio Rezende Alvarenga
Pr-Reitor de Ps-Graduao
Joel Augusto Muniz
Pr-Reitor Adjunto de Ps-Graduao Lato Sensu
Marcelo Silva de Oliveira
Coordenao do curso
Ana Cristina Rouiller
Presidente do Conselho Deliberativo da FAEPE
Edson Amplio Pozza
Editorao
Quality Group
Impresso
Grfica Universitria/UFLA
SUMRIO
1 Introduo .................................................................................................................11
2 O Produto de Software e a Organizao de Desenvolvimento .............................17
2.1 O Produto de Software .........................................................................................17
2.2 A Organizao de Desenvolvimento de Software ................................................19
2.2.1 Ncleo de Processamento de Dados..........................................................19
2.2.2 Pequeno Centro de Desenvolvimento.........................................................21
2.2.3 Fbrica de Software ....................................................................................22
2.3 Os Processos da ODS .........................................................................................23
3 Modelos de Ciclo de Vida do Processo de Software .............................................27
3.1 O Modelo Cascata................................................................................................27
3.2 O Modelo de Desenvolvimento Evolucionrio ......................................................31
3.2.1 O Modelo de Programao Exploratria .....................................................31
3.2.2 O Modelo de Prototipagem Descartvel .....................................................32
3.3 O Modelo de Transformao Formal....................................................................32
3.4 O Modelo de Desenvolvimento Baseado em Reuso ............................................32
3.5 Modelos Iterativos ................................................................................................33
3.5.1 O Modelo de Desenvolvimento Espiral .......................................................34
3.5.2 O Modelo de Desenvolvimento Incremental ...............................................35
3.6 Consideraes Finais ...........................................................................................36
4 Planejamento e Gerenciamento de Projetos de Software.....................................37
4.1 As Dificuldades do Gerenciamento de Projetos de Software ...............................38
4.2 Principais atividades do Gerenciamento de Projetos de Software nas ODSs ......39
4.2.1 O Planejamento do Projeto .........................................................................40
4.2.2 A Seleo de Pessoal .................................................................................41
4.2.3 O Gerenciamento de Riscos.......................................................................41
4.2.4 A Definio das Atividades, Marcos de Referncia e Produtos Entregues ao
Usurio ..................................................................................................42
4.2.5 A Definio do Cronograma........................................................................42
4.3 A Gerncia de Projetos sob a tica do PMBOK...................................................43
4.3.1 Gerncia de Integrao de Projetos............................................................45
4.3.2 Gerncia de Escopo de Projetos.................................................................45
4.3.3 Gerncia de Tempo de Projetos .................................................................46
4.3.4 Gerncia de Custo de Projetos ...................................................................46
4.3.5 Gerncia da Qualidade de Projetos ............................................................47
4.3.6 Gerncia de Recursos Humanos de Projetos .............................................47
4.3.7 Gerncia de Comunicao de Projetos.......................................................47
4.3.8 Gerncia de Risco de Projetos....................................................................48
4.3.9 Gerncia de Aquisio de Projetos .............................................................48
4.4 Consideraes Finais ...........................................................................................49
LISTA DE FIGURAS
Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de
projeto e engenharia do produto................................................................. 14
Figura 2.1: Diferenas do produto de software ........................................................... 18
Figura 2.2: Exemplo da estrutura de um NPD ............................................................ 19
Figura 2.3: Pequeno centro de desenvolvimento........................................................ 21
Figura 2.4: Organograma de uma fbrica de software................................................ 22
Figura 2.5: NPDs versus fbricas de software............................................................ 23
Figura 2.6: Estrutura para modelagem do sistema de processo da ODS. .................. 24
Figura 3.1: O modelo cascata..................................................................................... 28
Figura 3.2: O modelo cascata com iteraes.............................................................. 29
Figura 3.3: O modelo de desenvolvimento evolucionrio ........................................... 31
Figura 3.4: O modelo de transformao formal .......................................................... 32
Figura 3.5: Desenvolvimento baseado em reuso........................................................ 33
Figura 3.6: O modelo espiral....................................................................................... 34
Figura 3.7: O modelo incremental............................................................................... 35
Figura 4.1: Estrutura de um plano de projeto.............................................................. 40
Figura 4.2: Processos do gerenciamento de projetos do PMBOK. ............................. 44
Figura 4.3: reas do gerenciamento de projetos do PMBOK. .................................... 45
Figura 5.1: Erros e custo de correo......................................................................... 53
Figura 5.2: Engenheiro de requisitos X engenheiro de software ................................ 54
Figura 5.3: Processo de engenharia de requisitos...................................................... 58
Figura 5.4: Linguagens para especificao de requisitos ........................................... 60
Figura 6.1: Bases do TQC .......................................................................................... 79
Figura 6.2: Ciclo PDCA para melhorias ...................................................................... 79
Figura 6.3: Elementos-chave do TQM ........................................................................ 80
Figura 6.4: Desenvolvimento de produtos de software ............................................... 81
Figura 6.5: Viso geral do planejamento da qualidade ............................................... 83
Figura 6.6: Viso geral da garantia da qualidade ....................................................... 84
Figura 6.7: Balanceamento do custo da qualidade [Kezner1998]............................... 86
Figura 6.8: Requisitos da ISO9001/ISO9000-3........................................................... 89
Figura 6.9: Processos da ISO12207 ........................................................................... 91
Figura 6.10: As dimenses do modelo de referncia da ISO 15504........................... 92
Figura 6.11: Relacionamento entre o modelo de referncia e o modelo de
avaliao..................................................................................................... 94
Figura 6.12: Utilizao da ISO15504 .......................................................................... 95
Figura 6.13: Estrutura do Capability Maturity Model for Software............................... 96
Figura 6.14:CMMI: reas de processo em duas representaes: por estgio e
contnua ................................................................................................... 98
Figura 6.15: Visualizao grfica do IDEAL [MacFeeley1999] ................................. 101
Figura 6.16: Viso geral do processo de auditoria.................................................... 103
Figura 6.17: Viso geral do processo de avaliao .................................................. 104
Figura 6.18: Viso geral do processo de inspeo ................................................... 112
LISTA DE TABELAS
Tabela 6.1: Iniciativas para melhoria da qualidade do processo de software .............87
Tabela 6.2: Normas ISO9000 para suporte ao desenvolvimento de software ............90
10
1
INTRODUO
Atualmente, h cada vez mais sistemas controlados por software, fazendo com
que a economia de praticamente todos os pases seja muito dependente da qualidade
dos softwares por eles usados, justificando um investimento significativo nesse setor.
H alguns anos atrs, desenvolvia-se software de uma maneira completamente
artesanal. A partir de uma simples definio dos requisitos do software, partia-se
imediatamente para a implementao do mesmo. Hoje em dia, ainda h muitas
empresas que desenvolvem software dessa maneira, mas vrias outras esto
mudando suas formas de trabalho.
A forma artesanal de trabalho, geralmente, no traz grandes problemas para o
desenvolvimento de software de pequeno porte, o qual no exige um esforo muito
grande de implementao. Porm, para softwares de grande porte, srios problemas
na implementao podem comprometer todo o projeto.
Com o desenvolvimento cada vez maior da tecnologia de hardware e a
conseqente disponibilidade de mquinas cada vez mais potentes e baratas, o uso de
computadores tem-se tornado cada vez mais difundido em diversas reas. Isso tem
feito com que aumente a demanda por software cada vez maior e mais complexo. No
entanto, a demanda por software tem-se tornado maior que a capacidade do mercado
para atend-la.
Muitos projetos so entregues com um grande atraso, custando muito mais que o
inicialmente previsto, sendo no confiveis, difceis de manter e/ou no tendo um
desempenho satisfatrio. Alm do mais, na tentativa de se consertar os erros, muitas
vezes introduzem-se mais erros. Geralmente, a quantidade de problemas
diretamente proporcional ao aumento da complexidade do software produzido nos dias
de hoje. Esses problemas no desenvolvimento de software so conhecidos
mundialmente como a crise de software. Ou seja, a crise de software corresponde
incapacidade da indstria de software de atender prontamente demanda do mercado
de software, dentro dos custos e dos nveis de qualidade esperados.
12
Desde os anos 1960, quando o termo crise de software foi pronunciado pela
primeira vez, muitos problemas desta rea foram identificados e muitos deles ainda
persistem at os dias de hoje, tais como [Gibbs1994]:
Previso pobre desenvolvedores no prevem adequadamente quanto
tempo e esforo sero necessrios para produzir um sistema de software que
satisfaa s necessidades (requisitos) dos clientes/usurios. Sistemas de
software so geralmente entregues muito tempo depois do que fora planejado;
Programas de baixa qualidade programas de software no executam o que
o cliente deseja, conseqncia talvez da pressa para se entregar o produto. Os
requisitos originais podem no ter sido completamente especificados, ou podem
apresentar contradies, e isto pode ser descoberto muito tarde durante o
processo de desenvolvimento;
Alto custo para manuteno quando o sistema construdo sem uma
arquitetura clara e visvel, a sua manuteno pode ser muito custosa;
Duplicao de esforos difcil compartilhar solues ou reusar cdigo, em
funo das caractersticas de algumas linguagens adotadas, por falta de
confiana no cdigo feito por outra pessoa e at mesmo pela ausncia/deficincia
de documentao das rotinas e dos procedimentos j construdos.
O reconhecimento da existncia da crise de software tem provocado uma forte
mudana na forma de como as pessoas desenvolvem software de grande porte, visto
que o processo de desenvolvimento atual mais disciplinado do que no passado. Foi
proposto que o desenvolvimento de software deixasse de ser puramente artesanal e
passasse a ser baseado em princpios de Engenharia, ou seja, seguindo um enfoque
estruturado e metdico. Assim, surgiu o termo Engenharia de Software, que se refere
ao desenvolvimento de software por grupos de pessoas, usando princpios de
engenharia e englobando aspectos tcnicos e no-tcnicos, de modo a produzir
software de qualidade, de forma eficaz e dentro de custos aceitveis.
Portanto, a Engenharia de Software engloba no apenas o desenvolvimento de
programas, mas tambm toda a documentao necessria para o desenvolvimento,
instalao, uso e manuteno dos programas. O temo ciclo de vida de software
compreende todas as etapas, desde a concepo inicial do software, at a sua
implementao, implantao, uso e manuteno, de modo que, ao final de cada uma
destas etapas, um ou mais documentos so produzidos.
Engenheiros de software devem adotar uma abordagem sistemtica e organizada
para seu trabalho e usar ferramentas e tcnicas apropriadas, dependendo do
problema a ser solucionado, das restries de desenvolvimento e dos recursos
disponveis. Alm das tcnicas de especificao e implementao de software, os
engenheiros de software devem ter conhecimento tambm de outras tcnicas como,
Introduo
13
Uma ODS representa uma organizao independente, ou um departamento ou uma unidade dentro de
uma organizao, que responsvel por desenvolver, manter, oferecer ou operar um produto ou servio
de software ou um sistema de software intensivo [Wang1999].
2
A Engenharia de Software deve considerar estas funes objetivando a produo de software de maior
qualidade e a melhoria do desempenho da ODS, ou seja, torn-la mais produtiva.
14
Modelo do
processo
Gerenciamento de
projeto
Processo de
desenvolvimento
Engenharia do
produto
Produto de
software
Introduo
15
16
2
O PRODUTO DE SOFTWARE E A
ORGANIZAO DE
DESENVOLVIMENTO
Utilizaremos os termos software e sistema como sinnimos, apesar do ltimo ser mais abrangente.
18
ser o mais geral, flexvel e parametrizvel possvel. Deve estar apto a rodar em
empresas diferentes, que possuam inclusive processos de negcio tambm diferentes.
O usurio, que determinava os requisitos do software, passou muitas vezes at
mesmo a no existir, exigindo que a equipe de desenvolvimento se adaptasse e
passasse a buscar o conhecimento de outras formas. Muitas sub-reas da Engenharia
de Software surgiram (ou foram reforadas) para satisfazer esses novos quesitos
como, por exemplo, Engenharia do Conhecimento, Engenharia de Requisitos,
Arquitetura de Software, Sistemas Distribudos.
Alguns fatores de qualidade passaram a ser exigidos para o produto de software.
Entre esses fatores, podem-se citar os externos como usabilidade, portabilidade,
manutenibilidade etc. e fatores de qualidade internos como reusabilidade,
modularidade, flexibilidade etc. Uma constante melhoria no processo que desenvolve o
produto tambm passou a ter relevncia, pois um processo de software de alta
qualidade deve, por conseqncia, gerar um produto de alta qualidade. Pode-se dizer
que qualidade uma das palavras chaves na Engenharia de Software e medida
atualmente de duas formas: (1) qualidade do produto e (2) qualidade do processo. No
captulo 6 sero detalhados os padres que avaliam e propem melhoria da qualidade.
Outro aspecto interessante deste novo software que estamos produzindo o fato
de gerar uma demanda muitas vezes ainda no existente. Podem-se citar vrios
softwares que surgiram desta forma, como: o Windows, o Netscape, o Word, o Yahoo
e os RPGs.
A Figura 2.1 sintetiza algumas diferenas entre o produto de software que
produzamos nos primrdios da computao e os que hoje so desenvolvidos.
Software
1970
especializado
plataforma especfica
responsabilidade organizacional
validao do produto
monoltico,acopladol e no separvel
centralizado
satisfaz uma demanda
elevado custo para aquisio
dificil operao
2000
generalizado
portvel
reponsabilidade contratual
qualidade do produto
aberto, reusvel e modular
distribudo
gera uma demanda
baixo custo para aquisio
fcil operao
19
Empresa
Ncleo de
Processamento de
Dados
Desenvolvimento
Anlise
Programao
Suporte
....
....
Produo
Digitao
Conferncia
Operao
20
Especificar um software neste contexto significa criar um modelo computacional, independente da plataforma
computacional que ser utilizada.
21
Diretoria
Pequeno centro de
desenvolvimento
....
....
22
ODS
designer,
gerncia de
marketing,
gerncia
administrativa,
Projeto 1
(equipe do
Anlise
Suporte
Engenharia
Figura 2.4: Organograma de uma fbrica de software
23
1970
Centro de desenvolvimento
de software
2000
fora da empresa
grandes equipes dispersasl
exigencia de qualidadel
lida com responsabilidade contratual
processos software gerenciado
processos de desenvolvimento complexos
planejamento baseado em estimativas
alto rodzio de pessal
produz software barato
24
Modelagem do sistema de
processo
Modelo de avaliao do
processo
Modelo do processo
Subsistema do
processo
organizacional
Subsistema do
processo de
desenvolvimento
Escala do
desempenho
da pratica
Subsistema do
processo de
gerenciamento
Escala da
capacidade do
processo
Modelo de
capacidade do
processo
Escopo da
capacidade do
processo
Modelo de melhoria do
processo
Mtodo de
determinao
da capacidade
do processo
Determinao
da capacidade
do processo
Modelo de
melhoria
baseado em
avaliao
Agregao de
capacidade do
projeto
Modelo de
melhoria
baseado em
Benchmark
Agregao da
capacidade da
organizao
25
26
3
MODELOS DE CICLO DE VIDA DO
PROCESSO DE SOFTWARE
28
29
30
31
diferena entre os dois conceitos pode ser mais bem entendida atravs da definio
dada por Boehm [Boehm1981]:
Verificao: Estamos construindo o produto da maneira certa?
Validao: Estamos construindo o produto certo?
A principal desvantagem do modelo cascata que boa parte do sistema no
estar disponvel at um ponto adiantado no cronograma do projeto e, geralmente,
difcil convencer o usurio de que preciso pacincia. Alm disso, existe a dificuldade
de acomodao das mudanas depois que o processo est em andamento. Portanto,
esse modelo mais apropriado quando os requisitos so bem entendidos. No entanto,
h tambm algumas vantagens associadas ao modelo, pois ele oferece uma maneira
de tornar o processo mais visvel, fixando pontos especficos para a escrita de
relatrios e, didaticamente, uma maneira mais fcil de introduzir os principais
conceitos de Engenharia de Software. Por esse motivo, as atividades do ciclo de vida
do software sero detalhadas nos captulos 4 e 5 com base neste modelo de ciclo de
vida.
3.2 O MODELO DE DESENVOLVIMENTO EVOLUCIONRIO
O Modelo de Desenvolvimento Evolucionrio (vide Figura 3.3) subdivide-se em
dois: Programao Exploratria e Prototipagem Descartvel.
32
33
no-existentes
so
34
Desenvolvimento Espiral;
Desenvolvimento Incremental.
3.5.1 O Modelo de Desenvolvimento Espiral
35
36
37
4
PLANEJAMENTO E GERENCIAMENTO
DE PROJETOS DE SOFTWARE
Alguns estudos e pesquisas que foram realizados nos anos 1990 demonstraram
que o gerenciamento de projeto a causa mais evidente das falhas na execuo e
entrega de produtos e servios de software. O SEI-Software Engineering Institute
constatou, j em 1993, que o principal problema que aflige as organizaes de
software gerencial e preconizou que as organizaes precisam vencer o seu buraco
negro, que o seu estilo de gerenciar de maneira informal, sem mtodos e sem
tcnicas [Paulk1993].
Um estudo conduzido pelo DoD-Department of Defense [Dod1994] indicou que
75% de todos os sistemas de software falham e que a causa principal o pobre
gerenciamento por parte do desenvolvedor e adquirente, deixando claro que o
problema no de desempenho tcnico.
De acordo com um estudo realizado pelo Standish Group [Standish2001],
publicado no artigo Extreme CHAOS 2001, no perodo 2000/2001 apenas 28% dos
projetos de desenvolvimento pesquisados nos E.U.A. obtiveram sucesso, ou seja,
foram completados no tempo e no custo previstos, e possuam todas as
funcionalidades inicialmente planejadas. Apesar do aumento de sucesso em relao
ao ano de 1994, quando apenas 16% dos projetos conseguiram xito, este ainda um
percentual bastante reduzido. Este estudo aponta o gerenciamento de software como
sendo a principal razo para o sucesso ou a falha de um projeto de software.
Atravs de uma anlise e acompanhamento de cem projetos de software, Jones
[Jones1996] relata: os seis primeiros dos dezesseis fatores associados aos desastres
do software so falhas especficas no domnio do gerenciamento de projeto, e os trs
dos outros dez fatores restantes esto indiretamente associados s praticas de
gerenciamento pobre.
38
39
40
4.2.1
Analisar os riscos;
41
42
43
O PMBOK [PMBOK2000] define stakeholders como sendo os indivduos ou as organizaes que esto ativamente
envolvidos em um projeto, cujos interesses podem afetar positivamente ou negativamente o resultado da execuo
do projeto.
44
Processos de
Inicializao
Processos de
Planejamento
Processos de
controle
Processos de
execuo
Processos de
finalizao
45
Gerncia de
Projeto
Gerncia de
Integrao
Gerncia de
Escopo
Gerncia de
Tempo
Gerncia de
Custo
Gerncia de
Qualidade
Gerncia de
Recursos
Humanos
Gerncia de
Comunicao
Gerncia de
Risco
Gerncia de
Aquisio
46
A gerncia de custo tem por objetivo garantir que o projeto seja executado dentro
do oramento aprovado. Consiste no planejamento dos recursos, estimativa,
oramento e controle de custos.
Essa rea de processo incluiu os seguintes processos principais:
Planejamento dos recursos - determinar quais recursos (pessoas,
equipamentos, materiais) e que quantidade de cada deve ser usada para
executar as atividades do projeto;
47
Estimativa dos custos - desenvolver uma estimativa dos custos dos recursos
necessrios implementao das atividades do projeto;
Oramento dos custos - alocar as estimativas de custos globais aos itens
individuais de trabalho;
48
49
50
de software tem sido priorizado h pouco tempo pelas organizaes que definem
padres e normas para software.
Alm disso, esses modelos foram originalmente desenvolvidos para o mbito de
empresas bem estruturadas e departamentalizadas, ou seja, tipicamente para o mbito
de grandes empresas, dificultando ainda mais a orientao para empresas de pequeno
e mdio porte [Bellouquim1999].
Um exemplo de modelo de processo para gerncia de projetos de software o
ProGer [Rouiller2001]. O ProGer auxilia as ODSs na organizao inicial de seu
negcio atravs do uso de artefatos de alto nvel e de baixa complexidade, em
conjunto com um modelo de ciclo de vida para os projetos e o estabelecimento de
fluxos de trabalho. Esse modelo apresentado atravs de um modelo de ciclo de vida
para os projetos, da definio dos stakeholders, da definio dos fluxos de trabalho,
dos artefatos gerados no processo e de sugestes de estimativas e mtricas para
avaliao do desempenho da execuo dos projetos.
O ProGer foi concebido considerando os padres da engenharia de processo e
do gerenciamento de projetos. Foi especificado baseado nos modelos e padres de
SPA/SPI (principalmente, a ISO15504 [ISO15504:1-9:1998] e o CMMCapability
Maturity Model [Paulk1993], nas metodologias para desenvolvimento de software
(como o RUP-Rational Unified Process [Philippe1998] e o OPEN Process
[Graham1999]), nos procedimentos e normas para gerenciamento de projetos (como o
PMBOK-Project Management Body of Knowledge [PMBOK2000], TQC-Total Quality
Control [Campos1992] e [Royce1998]) e nos estudos empricos realizados em ODSs.
Para a validao desse modelo foram realizados estudos de casos em diversas
empresas de software, totalizando o acompanhamento de mais de 100 projetos de
software.
5
O PROCESSO DE
DESENVOLVIMENTO DE SOFTWARE
52
53
Estudos realizados mostram que, cerca de 40% dos erros cometidos, ocorrem na
etapa de especificao de requisitos do sistema (vide Figura 5.1). Como esses erros
so os mais caros de consertar, a correo de problemas oriundos da etapa de
especificao atinge um patamar de 66% do custo total de correo de erros do
projeto.
54
Reconhecimento do problema;
Avaliao e sntese;
Especificao;
Validao.
55
que afetam o projeto. O resultado dessa etapa a sntese de uma soluo para o
problema.
As tarefas associadas com a especificao de requisitos existem para prover
uma representao do software que possa ser revisada e aprovada pelo usurio. A
descrio inclui informaes bsicas de funcionalidade, performance e interface.
Os critrios de validao so descritos visando facilitar a tarefa de determinar se
uma implementao bem sucedida, ou seja, se atende aos requisitos especificados.
Esses critrios serviro como base para os testes durante o desenvolvimento do
software. No caso onde no possvel elaborar um prottipo, poder ser produzido um
Manual Preliminar do Usurio.
Freqentemente, questionam-se quais as caractersticas necessrias para um
engenheiro de requisitos. So vrias as tarefas realizadas, exigindo diferentes
capacidades:
Habilidade de lidar com conceitos abstratos, reorganizando-os em divises
lgicas e sintetizando as solues de acordo com cada diviso;
Habilidade de absorver fatos pertinentes a partir de fontes conflitantes e
confusas;
56
57
58
59
Modelagem
Os resultados da etapa de elicitao so documentados em forma de modelos
conceituais, que descrevem, esttica e dinamicamente, aspectos do problema e do
domnio de aplicao. O modelo conceitual seleciona propriedades do domnio de
aplicao que so de interesse do cliente, mas ignora detalhes e relaes que podem
ser importantes para outros propsitos. Nesse trabalho, o interesse maior na parte
de modelagem e de anlise.
Anlise
Durante a atividade de anlise, o objetivo a obteno de uma especificao que
seja consistente e completa. Pelas razes expostas acima, muito provvel que a
descrio obtida at ento possua vrias inconsistncias. O engenheiro de requisitos,
durante a anlise, deve ser capaz de detectar e resolver inconsistncias. A anlise
intercalada com a elicitao, pois problemas podem ser descobertos quando os
requisitos so elicitados.
A especificao pode estar incompleta, com muitas implicaes que precisam ser
explicitadas. Um grande esforo deve ser empreendido para completar a especificao
de requisitos, embora saibamos que tal tarefa praticamente impossvel.
bastante comum a existncia de omisses no que diz respeito a condies de
erro ou excees. Porm, principalmente em aplicaes que so do tipo
crtico/segurana (controle de trfego areo, reatores nucleares etc.), um esforo deve
ser feito no sentido de definir o comportamento do sistema em situaes no
desejadas.
Trabalhos recentes [Gotel1994] mostram a importncia de acompanhar (rastrear)
os requisitos, desde a sua concepo, passando por sua especificao, at a sua
implementao. Isso se torna bastante importante, por exemplo, quando da
necessidade de gerenciar/modificar o sistema.
Validao
Quando validamos uma especificao estamos garantindo que ela, de fato,
retrata as necessidades do cliente. Se a validao no for adequada, mal entendidos e
erros sero propagados para as etapas de projeto e implementao, ocasionando,
como foi visto anteriormente, um alto custo da correo.
Geralmente, um nvel aceitvel de validao obtido atravs do teste de
aceitao, que uma tcnica de confirmao que garante que a especificao de
software est de acordo com um critrio pr-estabelecido pelo cliente.
60
61
62
Consideraes
63
64
Legibilidade;
Nvel de complexidade;
Tamanho;
Tempo de execuo.
65
66
67
Testes de unidades;
Testes de integrao.
68
Testes de sistema.
Usurio:
Teste de aceitao.
5.4.6 Ferramentas de Teste
69
Auditoria nos itens de configurao (para determinar por que, quando e por
quem um artefato foi modificado);
Corretivas;
Adaptativas;
Perfectivas;
Preventivas.
70
71
72
6
QUALIDADE DE SOFTWARE
74
Qualidade de Software
75
76
Qualidade de Software
77
78
No repetir erros;
Qualidade de Software
79
80
Qualidade de Software
81
82
Treinamento;
Planejamento;
Modelagem;
Melhoria de processo.
Tcnicas de Deteco
Compilao/Anlise de cdigo;
Teste e simulao;
Auditorias;
Verificaes e validaes.
6.3.2 Planejamento e Gerncia da Qualidade de Software
Qualidade de Software
83
84
Propsito;
Documentos de referncia;
Organograma;
Atividades;
Responsabilidades;
Requisitos de documentao;
Padres e convenes;
Mtricas;
Revises e auditorias;
Teste;
Controle de fornecimento;
Treinamento;
Gerenciamento de riscos.
Qualidade de Software
85
86
Depurao;
Correo;
Re-peer reviews;
Depurao;
Correo;
Re-peer reviews;
Verses corretivas;
Qualidade de Software
87
Alguns mtodos de coleta podem ser adotados para subsidiar a anlise de custos
da qualidade, conforme relacionado a seguir:
Time sheets;
Help desk;
Custo do projeto;
Informaes de vendas;
INICIATIVA
1983
1984
1987
1988
Continua...
88
...continuao
1991
1992
1993
1994
- ISO 9001
- Trillium V3.0
1995
1996
- IEEE/EIA 12207
1997
- ISO 9000-3
- SW-CMM com suporte ao CMM Integration (CMMI)
1998
1999
2000
2001
- Adendo a ISO12207
- Nova verso da ISO9000-3
2003
- ISO 15504
Qualidade de Software
89
90
Descrio
Norma ISO15504
Qualidade de Software
91
92
CUS
ENG
SUP
MAN
ORG
.............
3
2
1
Processo
0
Dimenso de Processo
Dimenso de Capacidade
Qualidade de Software
93
94
Categorias de
processo
Indicadores de
desempenho do processo
Dimenso da Capacidade
MODELO
DE
REFERNCIA
Indicadores de
avaliao
Nveis de capacidade
Atributos do processo
Indicadores da capacidade
do processo
Prticas de gerenciamento
Prticas bsicas
Artefatos e suas
caractersticas
Caracteristicas de
desempenho das prticas
Caractersticas da
infraestrutura e recursos
Qualidade de Software
95
contrato ou uma atividade interna, ou algum outro requisito dentro dos processos de
software da ODS.
A ISO15504-9 define os termos utilizados em todos os documentos da ISO15504.
A Figura 6.12 ilustra o relacionamento destes principais elementos da 15504.
96
Qualidade de Software
97
CMMI
A sigla CMMI representa as iniciais de Capability Maturity Model Integration e
nomeia tanto um projeto, quanto os modelos resultantes deste projeto. O Projeto
CMMI, que pode ser traduzido como Projeto de Integrao dos Modelos de
Maturidade da Capacidade, est sendo executado pelo Software Engineering Institute
(SEI), em cooperao com a indstria e governo, para consolidar um framework para
modelos, evoluir e integrar modelos desenvolvidos pelo SEI (inicialmente os modelos
SW-CMM, SE-CMM e IPD-CMM) e gerar seus produtos associados, incluindo material
de treinamento e mtodo de avaliao. Estes trs modelos, que foram evoludos e
integrados inicialmente, foram a verso 2.0 do SW-CMM (Capability Maturity Model for
Software), o SE-CMM: EIA 731 (System Engineering Capability Maturity Model) e o
IPD-CMM (Integrated Product Development Capability Maturity Model).
Essa integrao e evoluo tiveram como objetivo principal a reduo do custo
da implementao de melhoria de processo multidisciplinar baseada em modelos.
Multidisciplinar porque alm da engenharia de software, o CMMI cobre tambm a
engenharia de sistemas, aquisio e a cadeia de desenvolvimento de produto. Esta
reduo de custo obtida por meio da eliminao de inconsistncias, reduo de
duplicaes, melhoria da clareza e entendimento, utilizao de terminologia comum,
utilizao de estilo consistente, estabelecimento de regras de construo uniforme,
manuteno de componentes comuns, garantia da consistncia com a norma
ISO15504 e sensibilidade s implicaes dos esforos legados.
O nome do modelo CMMI pode ser traduzido para Modelo Integrado de
Maturidade da Capacidade. Em agosto de 2000 foi lanada a verso 1.0 do CMMI,
tambm chamada de CMMI-SE/SW v1 [SEI2000]. Aps outras verses intermedirias,
em 10 de maro de 2002 foi lanada a verso atual denominada de CMMISE/SW/IPPD/SS Version 1.1 (CMMISM for Systems Engineering / Software Engineering
/ Integrated Product and Process Development / Supplier Sourcing, Version 1.1, em
portugus CMMISM para Engenharia de Sistemas / Engenharia de Software /
Desenvolvimento Integrado de Produtos e Processos / Fornecimento) [SEI2002a].
98
Qualidade de Software
99
100
Alm do CMM e CMMI, o SEI tambm definiu outros modelos que podem
contribuir com o processo de melhoria de organizaes de software. Dentre esses
modelos, podem ser citados: o People-CMM, voltado para a gerncia de pessoas em
uma organizao; o Personal Software Process (PSP), focado no processo pessoal do
desenvolvedor de software; e o IDEAL, modelo que prope um processo para melhoria
de processos baseado no ciclo PDCA.
6.5 MELHORIA DO PROCESSO DE SOFTWARE
A qualidade do produto de software est diretamente relacionada qualidade do
processo que o produz. Dessa forma, a definio de um processo de software
apropriado ao tipo da aplicao a ser desenvolvida, alinhada cultura dos
profissionais envolvidos no projeto de software, um fator crtico de sucesso para
qualquer organizao de software.
Nesse contexto, a ISO9001:2000 e o CMM/CMMI recomendam que, alm da
definio de um processo de software adequado s caractersticas do projeto, seja
garantida pela organizao uma sistemtica para melhoria contnua desse processo.
Em [Humphrey1989], Watts Humphrey relaciona passos para melhoria do
processo de software:
1. Compreender a situao corrente;
2. Desenvolver uma viso do processo;
3. Estabelecer uma lista de aes de melhoria de processo requeridas em
ordem de prioridade;
4. Produzir um plano para execuo dessas aes;
5. Iniciar o passo 1 novamente.
6.5.1 O Modelo IDEAL
Um dos modelos mais conhecidos, focado na melhoria de processo, o modelo
IDEAL [MacFeeley1999], do Software Engineering Institute (SEI). O nome IDEAL um
acrnimo para cada um dos 5 estgios definidos pelo modelo:
Iniciao, que abrange o estmulo para melhoria e estabelece a infra-estrutura
para melhoria;
Diagnstico, que compreende a avaliao e caracterizao da prtica
corrente, alm do desenvolvimento de recomendaes;
Estabelecimento, quando estratgias e prioridades so definidas (plano de
ao);
Qualidade de Software
101
102
6.6.1 Auditorias
Segundo Feingenbaum, auditoria da qualidade a avaliao da verificao da
eficcia do controle. Em outras palavras, a auditoria da qualidade pode ser
considerada, em alguns casos, a inspeo da inspeo dos itens, ensaio dos ensaios
de produto, procedimento para avaliao da eficcia dos procedimentos.
A ISO9000:2000 define uma auditoria como um processo sistemtico,
independente e documentado, para se obter evidncia e avali-la objetivamente,
visando determinar a extenso na qual os critrios de auditorias so atendidos.
importante entender que uma auditoria um exerccio de coleta de
informaes, que possibilitar a identificao de necessidade de melhoria ou de aes
corretivas. Para garantir uma auditoria efetiva, a veracidade das informaes coletadas
essencial, uma vez que decises importantes e crticas so tomadas e podem
impactar positiva ou negativamente para o cenrio financeiro de uma organizao.
As auditorias so normalmente realizadas com um ou mais dos seguintes
objetivos:
Determinao de conformidade ou no-conformidade do sistema da qualidade
com requisitos especificados;
Tipos de Auditoria
Com relao aos elementos sendo auditados, as auditorias podem ser
classificadas nos seguintes tipos:
Auditorias de Produto - uma tcnica fundamental da engenharia do controle
de processo a da implementao das auditorias de produto;
Auditorias de Processo o principal papel dessas auditorias a garantia da
execuo efetiva de todos os aspectos do procedimento. O planejamento dessas
auditorias pode ser direcionado a procedimentos individuais ou a grupos de
procedimentos, por exemplo, aplicveis em reas como documentao e
registros de processo, medies, conformidade com requisitos do processo e
conformidade de produtos com padres de qualidade estabelecidos.
Com relao avaliao da eficcia da implementao de um sistema da
qualidade e a determinao do grau com o qual os objetivos do sistema esto sendo
atingidos, as auditorias podem ser classificadas como:
Qualidade de Software
103
Segunda parte conduzida por uma organizao sobre uma outra, para fins
da organizao condutora da auditoria;
Terceira parte realizadas por uma terceira parte, independente, sem
interesse nos resultados da auditoria. Nessa classe, incluem-se as auditorias de
certificao, como as auditorias ISO9001, as quais podem ser:
Inicial: completa, abrangendo todo o escopo de certificao;
De Manuteno: peridica, conduzida para determinar a manuteno da
auditoria inicial;
De Re-certificao: realizada no final do perodo de certificao no sentido
de re-emitir o certificado para um novo perodo.
Como resultado das auditorias, um relatrio fornecido a gerentes e
supervisores da rea auditada (vide Figura 6.16). Isso permite que todas as atividades
de auditorias fiquem as mais visveis possveis, possibilitando a identificao,
execuo e o acompanhamento de aes corretivas (identificando os respectivos
responsveis). A implementao dessas aes corretivas indicadas constituir uma
rea-chave para a ateno em auditorias subseqentes. A idia utilizar os resultados
da auditoria para induzir melhoria do sistema.
104
Qualidade de Software
105
106
Aps a definio dos objetivos, devem-se determinar questes que precisam ser
respondidas, a fim de determinar se cada objetivo alcanado. Finalmente, as
mtricas so selecionadas no sentido de proverem informao necessria para a
resposta a cada questo.
=> Definindo Objetivos
Os objetivos definidos podem variar, dependendo do nvel de abstrao que se
deseja considerar no programa de mtricas a ser definido. O nvel de abstrao pode
ser:
Organizacional onde so tipicamente considerados objetivos de negcio
relacionados a custo, ndice de satisfao do cliente ou mesmo o atendimento a
uma margem de lucro almejada;
De Projeto no nvel de projeto, praticamente so considerados objetivos
para enfatizar o gerenciamento do projeto e controlar requisitos e metas do
projeto, considerando-se fatores de sucesso, tais como custo, prazo, qualidade,
atendimento aos requisitos, entre outros;
De Atividade nesse nvel, consideram-se mtricas que podem prover
informao sobre a execuo efetiva de uma determinada atividade.
=> Identificando Questes
A pergunta-chave : quais questes precisam ser respondidas para determinar
se os objetivos foram alcanados?. Com base nesse foco, cada objetivo deve ter suas
questes relacionadas. A seguir, apresentado um exemplo de questes relacionadas
a um objetivo de negcio.
Objetivo: manter um alto nvel de satisfao do cliente.
Qualidade de Software
Passvel de automao;
107
Exemplo:
Levando-se em considerao o objetivo: "garantir que todos os defeitos
conhecidos sejam solucionados antes da liberao do produto", questes a serem
definidas podem ser:
Nesse caso, mtricas podem ser definidas como Nmero de defeitos e Nmero
de defeitos por status.
6.7.2 Uso de Mtricas para Suporte a Estimativas
Um dos aspectos mais focados em medies o suporte a estimativas de
projetos. Nesse contexto, a medio de tamanho bastante recomendada pelos
modelos de qualidade. Uma dessas medidas mais comum a contagem de linhas de
cdigo (KLOC). Embora essa mtrica possa parecer simples, existe discordncia
sobre o que constitui uma linha de cdigo. Existem impasses, por exemplo, sobre a
incluso ou no de linhas de comentrio e linhas em branco, uma vez que estas
servem para a documentao interna do programa e no afeta a sua funcionalidade.
Alm disso, a linguagem de programao adotada pelo projeto um fator que impacta
diretamente na mtrica. Medidas baseadas em programas desenvolvidos em um tipo
de linguagem de programao no devem ser comparadas a cdigo escrito em outra
linguagem. Essa restrio impede, por exemplo, a utilizao de dados histricos para
projetos que no utilizam a mesma linguagem.
Em outro contexto, mtricas orientadas funo concentram-se na complexidade
da funcionalidade do software. Foram propostas no incio da dcada de 1970, por
pesquisadores da IBM, cujo trabalho era identificar as variveis crticas que
determinam a produtividade da programao.
108
Comunicao de dados;
Processamento distribudo;
Performance;
Utilizao de equipamento;
Volume de transaes;
Atualizao on-line;
Processamento complexo;
Reutilizao de cdigo;
Facilidade de implantao;
Facilidade operacional;
Mltiplos locais;
Facilidade de mudanas.
A mtrica de pontos por funo (FP), assim como as linhas de cdigo (LOC),
controversa.
Qualidade de Software
109
110
Qualidade de Software
111
112
violaes
do
desenho
levam,
Qualidade de Software
113
114
7
QUALIDADE DE PRODUTO DE
SOFTWARE
116
Qualidade
de produto
de software
Funcionalidade
Adequao
Acurcia
Interoperabilidade
Segurana de
acesso
Conformidade
Confiabilidade
Maturidade
Tolerncia a Falhas
Recuperabilidade
Conformidade
Usabilidade
Inteligibilidade
Apreensibilidade
Operacionalidade
Atratividade
Conformidade
Eficincia
Manutenibilidade
Comportamento em
relao ao tempo
Comportamento em
relao aos recursos
Analisabilidade
Modificabilidade
Estabilidade
Testabilidade
Conformidade
Conformidade
Portabilidade
Adaptabilidade
Capacidade para
ser instalado
Co-existncia
Capacidade para
substituir
Conformidade
7.2 FUNCIONALIDADE
Capacidade do produto de software de prover funes que atendam
necessidades explcitas e implcitas quando o software estiver sendo utilizado sob
condies especificadas.
117
NOTAS
1 Esta caracterstica est relacionada com o que software faz para atender
necessidades, enquanto que outras caractersticas esto principalmente relacionadas
com quando e como ele atende s necessidades.
2 Para as necessidades explcitas e implcitas nesta caracterstica, a nota da
definio de qualidade aplicvel, (ver A.21).
3 Para um sistema que seja operado por um usurio, a combinao de
funcionalidade, confiabilidade, usabilidade e eficincia pode ser medido externamente
pela qualidade em uso (ver seo 8).
7.2.1 Adequao
A capacidade do produto de software de prover um conjunto apropriado de
funes para tarefas e objetivos do usurio especificados.
7.2.2 Acurcia
A capacidade do produto de software de prover resultados ou efeitos corretos ou
acordados.
NOTA Isto inclui os dados esperados de resultados de clculo, com o grau de
preciso necessrio.
7.2.3 Interoperabilidade
A capacidade do produto de software de interagir com um ou mais sistemas
especificados.
NOTA Interoperabilidade usada no lugar de compatibilidade para se evitar
possvel ambigidade com capacidade de substituir (ver 7.6.4).
118
NOTAS
1 Isto tambm se aplica a dados na sua transmisso.
2 Segurana definida como uma subcaracterstica de qualidade em uso, j que
ela no est relacionada somente com o software, mas com o sistema como um todo.
7.2.5 Conformidade
A capacidade do produto de software em estar de acordo com normas,
convenes ou regulamentaes em leis e prescries similares.
7.3 CONFIABILIDADE
A capacidade do produto de software de manter um nvel de desempenho
especificado quando usado em condies especificadas.
NOTAS
1 Em software no ocorre desgaste ou envelhecimento. As limitaes em
confiabilidade so decorrentes de defeitos na especificao de requisitos, projeto e
implementao. As falhas decorrentes desses defeitos dependem de como o produto
de software usado e das opes de programa selecionadas e no do tempo
decorrido.
2 A definio de confiabilidade na ISO/IEC DIS 2382-14:1994 A habilidade de
uma unidade funcional de executar uma funo requisitada.... Neste documento,
funcionalidade somente uma das caractersticas de qualidade de software. Portanto,
a definio de confiabilidade tem sido expandida para manter seu nvel de
desempenho... no lugar de ... executar uma funo requisitada.
7.3.1 Maturidade
A capacidade do produto de software de evitar falhas decorrentes de defeitos no
software.
119
aprender sua
120
121
7.5.3 Conformidade
A capacidade do produto de software de estar de acordo com normas e
convenes relativas eficincia.
7.6 MANUTENIBILIDADE
A capacidade do produto de software de ser modificado. As modificaes podem
incluir correes, melhorias ou adaptaes do software devido a mudanas no
ambiente ou nos seus requisitos.
7.6.1 Analisabilidade
A capacidade do produto de software de permitir o diagnstico de deficincias ou
causas de falhas no software ou a identificao de partes a serem modificadas.
7.6.2 Modificabilidade
A capacidade do produto de software de permitir que a modificao especificada
seja implementada.
NOTAS
1 Implementao inclui modificao na codificao, projeto e documentao.
2 Se o software for modificvel pelo usurio final, a modificabilidade pode afetar a
operacionalidade.
122
7.7 ESTABILIDADE
A capacidade do produto de software de minimizar efeitos inesperados de
modificaes de software.
7.7.1 Testabilidade
A capacidade do produto de software de permitir o software modificado ser
validado.
7.7.2 Conformidade
A capacidade do produto de software de estar de acordo com normas ou
convenes relativas manutenabilidade.
7.8 PORTABILIDADE
A capacidade do produto de software de ser transferido de um ambiente para
outro.
NOTA - O ambiente pode incluir ambiente organizacional, de hardware ou de
software.
7.8.1 Adaptabilidade
A capacidade do produto de software de ser adaptado para diferentes ambientes
especificados sem necessidade de aplicao de outras aes ou meios alm daqueles
fornecidos para essa finalidade pelo software considerado.
NOTAS
1 Adaptabilidade inclui a possibilidade de alterar, por exemplo: campos de tela,
tabelas, volume de transaes, formato de relatrios etc.
2 Se o software for adaptvel pelo usurio final, adaptabilidade corresponde
aplicabilidade para personalizao como definido na ISO 9241-10 e pode afetar a
operacionalidade.
7.8.2 Capacidade para ser instalado
A capacidade do produto de software para ser instalado em um ambiente
especificado.
NOTA - Se o software para ser instalado pelo usurio final, a capacidade para
ser instalado afeta a adequao e a operacionalidade.
123
7.8.3 Coexistncia
A capacidade do produto de software para coexistir com outros softwares
independentes em um ambiente comum compartilhando recursos comuns.
7.8.4 Capacidade para substituir
A capacidade do produto de software para ser usado em substituio de outro
produto de software especificado para o mesmo propsito no mesmo ambiente.
NOTAS
1 Por exemplo, a capacidade para substituir de uma nova verso de um produto
de software importante para o usurio quando estiver atualizando a verso.
2 A capacidade para substituir utilizada no lugar de compatibilidade para evitar
possvel ambigidade com interoperabilidade (veja 7.1.3).
3 A capacidade para substituir pode incluir atributos de capacidade para ser
instalado e adaptabilidade. O conceito tem sido introduzido como uma
subcaracterstica prpria devido a sua importncia.
7.8.5 Aderncia
A capacidade do produto de software para aderir a normas ou convenes
relativas portabilidade.
124
7.12 SATISFAO
O quanto que o produto de software satisfaz os usurios em um contexto de uso
especificado.
NOTA - Questionrios psicometricamente vlidos podem ser utilizados para obter
medidas de satisfao.
125
Qualidade
em uso
Efetividade
Produtividade
Segurana
Satisfao
8
CONCLUSO
127
128
9
EXERCCIOS DE FIXAO
1. Defina com suas palavras o que voc entende por Engenharia de Software.
2. Explique com suas palavras o que vem a ser a crise de software. Voc acha
que este um problema que um dia ter uma soluo definitiva? (defenda o seu
argumento).
3. Tente relembrar, sem consultar o texto deste, quais so os principais modelos
de ciclo de vida de software, descrevendo suas caractersticas.
4. No frum virtual, coloque algumas consideraes sobre a dificuldade de se
implantar os conceitos da Engenharia de Software em uma organizao.
5. Descreva com suas palavras (no mximo 4 pargrafos) as principais
caractersticas, entradas e sadas dos processos de Planejamento e
Gerenciamento, Requisitos, Projeto de Sistemas, Implementao, Testes e
Gerncia de Configurao.
6. Defina os conceitos de produto (deliverable), release e marco de referncia
(milestone).
7. Explique cada um dos estgios de teste.
8. Defina com suas palavras o que voc entende por Qualidade de Software.
9. Explique com suas palavras o que vem a ser o TQC e o TQM.
10. No frum virtual, coloque algumas consideraes sobre a dificuldade de se
implantar os conceitos da Qualidade de Software em uma organizao.
11. Descreva com suas palavras o ciclo PDCA e o modelo IDEAL.
12. Descreva o que so auditorias e assesments.
13. Descreva sumariamente a metodologia proposta pela tcnica Goal-QuestionMetric para seleo de mtricas.
14. Fale sobre as tcnicas de verificao e validao.
130
10
REFERNCIAS BIBLIOGRFICAS
132
Referncias Bibliogrficas
133
134
Referncias Bibliogrficas
135
[Paulk1995] Paulk, M.C. et al. The Capability Maturity Model: Guidelines for
Improving the Software Process - Addison-Wesley, 1995.
[Paulk1997] Paulk, M. C & Weber, C. V & Curtis, B. & Chrissis, M. B. The Capability
Maturity Model: Guidelines for Improving the Software Process. Carnegie Mellon
University, Software Engineering Institute, Addison-Wesley Longman Inc, 1997.
[Philippe1998] Philippe, K. The Rational Unified Process: an Introduction. AddisonWesley Object Technology Series, 1998.
[PMBOK2000] A Guide to the Proiject Management Body of Knowledge, PMI-Project
Management Institute, Newtown Square, Pennsylvania, USA, 2000.
[Pressman2001] R. S. Pressman., Software Engineering: A Practioners Approach,
5th edition, McGraw-Hill International Editions, (2001).
[Rouiller2001] Rouiller A. C Gerenciamento de Projetos de Software para Pequenas
Empresas. Tese de doutorado. Universidade Federal de Pernambuco, 2001.
www.uflatec.com.br/ana.
[Royce1998] Royce, W. Software Project Management: a unified framework. Addison
Wesley Longman, 1998, USA.
[Ryan1993] K. Ryan, The Role of Natural Language in Requirements Engineering,
pp. 240-242 in Proceedings of the IEEE International Symposium on Requirements
Engineering, San Diego, CA (January, 1993).
[Sanches2001] Sanches, R. & Jnior, W. T. Proposta de um Modelo de Processo de
Planejamento de Projeto de Software para Melhoria de Gerenciamento de Projetos. XII
CITS - Conferncia Internacional de Tecnologia de Software, junho, 2001.
[SEI2000] Sei, An Overview of Capability Maturity Model Integration (CMMI) Version
1.0, Tutorial presented at SIMPROS 2000 [23], 2000.
[SEI2002a] Sei, Web Site do software Engineering Institute
http://www.sei.cmu.edu/ (CMMI nodels available at www.sei.cmu.edu/cmmm).
SEI,
SEI,
136
SEI,
Chaos,
acessado
ANEXO A PADRO DE
CODIFICAO JAVA
138
package pesquisa.cep;
//importaes de classes
import java.sql.Connection;
import java.util.Collection;
import gov.br.UFLA.reuso.cep.Localidade;
import gov.br.UFLA.reuso.cep.UF;
//declarao de classe
public class PesquisaCEP {
...
}
/*
* Classname
*
* Version information
*
* Date
*
* Copyright notice
/*
139
package java.awt;
import java.awt.peer. CanvasPeer;
declarao
Partes da declara
o de classes e interface
1 Comentrios de Documentao (/**..*/)
Observaes
Veja Comentrios de
documentao para
informaes sobre como
usar este comentrio
Primeiramente as variveis
140
declarao
Partes da declara
o de classes e interface
Observaes
pblicas (public) da classe,
ento as protegidas
(protected) e finalmente as
privadas (private).
5 Instncia de Variveis
protected e finalmente a
private;
6 Construtores
7 Mtodos
2. Endentao
Quatro espaos devem ser utilizados como unidade de endentao.
141
Alinhar a nova linha com o incio de uma expresso no mesmo nvel da linha
anterior.
Aqui esto alguns exemplos de quebra para chamada de mtodos:
var = someMethod1(longExpression1,
someMethod2(longExpression, longExpression));
Os dois exemplos, a seguir, so de quebra de expresses aritmticas. O primeiro
o preferido, desde que a quebra ocorra fora dos parnteses.
142
// ENDENTAO CONVENCIONAL
someMethod(int anArg, Object anotherArg, String yetAnotherArg,
Object andStillAnother) {
...
}
Line wrapping para declaraes if deveriam usar a regra de the 8 espaos, desde
que a convencional (4 espaos) endentao dificulte a viso do corpo. Por exemplo:
143
// bad wraps
doSomethingAboutIt();
// OU USE ESTA
if ((condition1 && condition2) || (condition3 && condition4)
|| !(condition5 && condition6)) {
doSomethingAboutIt();
}
144
alpha = (aLongBooleanExpression)
? beta
: gamma;
3. Comentrios
Os programas Java podem ter dois tipos de comentrios: comentrios de
implementao e comentrios de documentao. Comentrios de implementao so
aqueles encontrados em C++, este delimitado por /* . . . */, e / /. Comentrios de
documentao (conhecido como doc comments) so somente Java e so
delimitados por /** . . . */. Comentrios doc podem ser extrados para arquivos HTML
usando a ferramenta javadoc.
Comentrios de implementao so significativos para comentar sobre uma
implementao em particular. Comentrios Doc so significativos para descrever a
especificao de um cdigo, de uma perspectiva livre de implementao para ser lida
por desenvolvedores que provavelmente, no necessariamente possuem o cdigo
fonte em mos.
Comentrios devem ser usados para dar uma viso geral do cdigo e prover
informao adicional para determinada parte do cdigo, na qual apenas lendo-se, o
cdigo no possvel o entendimento. Comentrios devem conter somente
informaes relevantes para a leitura e entendimento do programa. Por exemplo,
informaes sobre como o determinado pacote construdo ou em qual diretrio ele
est armazenado, no devem ser includos como um comentrio.
Nota: A freqncia de comentrios algumas vezes reflete baixa qualidade do
cdigo. Quando voc se sente forado a adicionar um comentrio, considere
reescrever o cdigo para deix-lo limpo.
Comentrios no devem ser colocados em grandes caixas de desenho com
asteriscos ou outros caracteres. Comentrios nunca devem incluir caracteres
especiais.
145
If (condition) {
146
If (a == 2)
return TRUE;
/* caso especial */
} else {
return isPrime(a);
If (foo > 1) {
// coloque o comentrio aqui.
...
}
else {
return false;
// Explique a funcionalidade.
//
//}
//else {
...
147
return false;
//}
Nota: no comentar um cdigo se ele no usado.
/**
* A classe Exemplo e funcionalidades . . .
*/
public class Exemplo { . . .
}
Note que classes top-level e interfaces no so endentadas, enquanto seus
membros so. A primeira linha de um comentrio doc (/**) para classes ou interfaces
no endentada, as linhas subseqentes de comentrios doc tem cada uma 1
espao de endentao (verticalmente, alinhando os asteriscos).
Comentrios doc no devero ser inseridos dentro de um mtodo ou de um bloco
de definio de construtores, devido ao Java associar comentrios de documentao
com a primeira linha depois do comentrio.
Nota: ver exemplo no item 9.
4. Declaraes
4.1 Nmeros por Linha
Uma declarao por linha recomendada desde que seja acompanhada de
comentrios. Em outras palavras,
int level;
// qual o nvel
148
int size;
// tamanho da tabela
melhor que
level;
// qual o nvel
int
size;
// tamanho da tabela
Object
currentEntry;
4.2 Inicializao
Tente inicializar variveis locais onde elas so declaradas. A nica razo, para
no inicializar uma varivel onde ela declarada se o valor inicial depende de algum
outro processamento primeiro.
void myMethod() {
int int1 = 0;
If (condition) {
int int2 = 0;
...
// inicio do bloco if
149
}
}
A nica exceo para esta regra so os ndices, como de loops for, que em Java
podem ser declarados na prpria instruo.
// evitar!
...
}
...
}
150
int ivar1;
int ivar2;
5. Statements (instrues)
5.1 Instrues simples
Cada linha dever conter no mximo uma instruo. Exemplo:
argv++;
// Correto
argc++;
// Correto
// Evitar
151
return;
return myDisk.Size();
if (condition) {
statements;
}
if (condition) {
152
statements;
} else {
statements;
}
if (condition) {
statements;
} else if (condition) {
statements;
} else
statements;
}
Nota: Instrues if sempre utilizam chaves {}. Evite usar as seguintes formas,
pois so consideradas como erros.
If (condition)
statements;
153
while (condition) {
statements;
}
while (condition)
do {
statements;
} while (condition);
154
switch (condition) {
case ABC:
statements;
/* falsa passagem */
case DEF:
statements;
break;
case XYZ:
statements;
break;
default:
statements;
break;
}
Cada instruo switch dever incluir um caso default. O uso do break em uma
instruo default redundante, mas no previne os erros de passagens falsas se
outra instruo case for adicionada.
155
try {
statements;
} catch (ExceptionClass e) {
statements;
}
Uma instruo try-catch pode tambm ser seguida da instruo finally, esta no
ser levada em considerao quando bloco try no for completado com sucesso.
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
6. Espaos em branco
6.1 Linhas em branco
Linhas em branco facilitam a leitura do cdigo, uma vez que se define sees de
cdigo relacionadas.
Duas linhas em branco devero ser sempre usadas para as seguintes
circunstncias:
Entre sees de um arquivo fonte;
Uma linha em branco dever sempre ser usada nas seguintes circunstncias:
Entre mtodos;
156
Uma palavra chave seguida de parnteses dever ser separada por um espao.
Exemplo:
while (true) {
...
}
Note que um espao em branco no deve ser usado entre o nome de um mtodo
e o parnteses que ser aberto. Isto ajuda a distinguir as chaves da chamada de um
mtodo.
Um espao em branco dever aparecer depois de vrgulas em listas de
argumentos;
a += c + d;
a = (a + b) / (c * d);
157
As expresses dentro de uma instruo for devero ser separadas por espaos
em branco. Exemplo: