Mod.01.MPS Engenharia&QualidadeSoftware v.28.09.06

CURSO DE PS-GRADUAO LATO SENSU (ESPECIALIZAO) DISTNCIA MELHORIA DE PROCESSO DE SOFTWARE
INTRODUO ENGENHARIA DE SOFTWARE E QUALIDADE DE SOFTWARE
Alexandre Marcos Lins de Vasconcelos Ana Cristina Rouiller Cristina ngela Filipak Machado Teresa Maria Maciel de Medeiros
Universidade Federal de Lavras - UFLA Fundao de Apoio ao Ensino, Pesquisa e Extenso - FAEPE Lavras - MG
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
Ficha Catalogrfica Preparada pela Diviso de Processos Tcnicos da Biblioteca Central da UFLA
Introduo Engenharia de Software e Qualidade de Software / Alexandre Marcos Lins de Vasconcelos, Ana Cristina Rouiller , Cristina ngela Filipak Machado, Teresa Maria Maciel de Medeiros. Lavras: UFLA/FAEPE, 2006. 157 p. :il. (Curso de Ps-graduao Lato Sensu (Especializao) Distncia Melhoria de Processo de Software. Bibliografia. 1. Engenharia de software. 2. Qualidade. 3. Projeto. 4. Gerenciamento. 5. Desenvolvimento. I. Vasconcelos, A. M. L. de. II. Universidade Federal de Lavras. III. Fundao de Apoio ao Ensino, Pesquisa e Extenso. IV Ttulo. CDD-005.1
Nenhuma parte desta publicao pode ser reproduzida, por qualquer meio, sem a prvia autorizao da FAEPE.
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
5 O Processo de Desenvolvimento de Software .......................................................51 5.1 Engenharia de Requisitos ....................................................................................51 5.1.1 Caractersticas Especficas da Engenharia de Requisitos ..........................54 5.1.2 Requisitos Funcionais e No-Funcionais ....................................................57 5.1.3 O Processo de Engenharia de Requisitos ..................................................57 Elicitao .......................................................................................................58 Modelagem ....................................................................................................59 Anlise........................................................................................................... 59 Validao .......................................................................................................59 5.1.4 Modelos Conceituais e Linguagens para a Engenharia de Requisitos .......60 Linguagens Naturais ......................................................................................60 Linguagens Rigorosas ...................................................................................61 Linguagens Formais ......................................................................................62 5.1.5 Consideraes ............................................................................................62 5.2 Projeto de Software ..............................................................................................63 5.3 Implementao .....................................................................................................64 5.4 Testes de Software...............................................................................................65 5.4.1 Introduo ...................................................................................................65 5.4.2 Estgios de Teste .......................................................................................66 5.4.3 Abordagens de Teste..................................................................................66 5.4.4 Tipos de Teste ............................................................................................67 5.4.5 Responsabilidade pelos testes....................................................................67 5.4.6 Ferramentas de Teste.................................................................................68 5.5 Gerncia de Configurao....................................................................................68 5.6 Operao e Manuteno de Software ..................................................................69 5.7 Ferramentas CASE ..............................................................................................70 6 Qualidade de Software .............................................................................................73 6.1 Conceituao........................................................................................................73 6.2 Evoluo dos conceitos de qualidade ..................................................................74 6.2.1 Abordagem de W. Edwards Deming ...........................................................75 6.2.2 Abordagem de Armand Feigenbaum ..........................................................76 6.2.3 Abordagem de Joseph M. Juran .................................................................76 6.2.4 Abordagem de Philip Crosby.......................................................................77 6.2.5 Total Quality Control (TQC).........................................................................78 6.2.6 Total Quality Management (TQM)...............................................................80 6.3 Introduo Qualidade de Software ....................................................................81 6.3.1 Preveno X Deteco ...............................................................................81 Tcnicas de Preveno .......................................................................................82 Tcnicas de Deteco .........................................................................................82 6.3.2 Planejamento e Gerncia da Qualidade de Software .................................82 Planejamento da Qualidade de Software.......................................................82 Garantia da Qualidade de Software...............................................................84 Controle da Qualidade de Software...............................................................85
6.3.3 Custos da Qualidade...................................................................................85 6.4 Modelos e Padres de Qualidade de Software ....................................................87 6.4.1 As Normas ISO ...........................................................................................88 ISO12207......................................................................................................90 ISO15504......................................................................................................91 6.4.2 Os Modelos do Software Engineering Institute (SEI) ..................................95 CMMI ............................................................................................................97 6.5 Melhoria do Processo de Software.....................................................................100 6.5.1 O Modelo IDEAL .......................................................................................100 6.6 Auditorias e Avaliaes (Assessments)..............................................................101 6.6.1 Auditorias ..................................................................................................102 Tipos de Auditoria ........................................................................................102 6.6.2 Avaliaes Internas (Assessments) ..........................................................103 6.7 Medio de Software..........................................................................................105 6.7.1 Seleo de Mtricas..................................................................................105 Tcnica Goal/Question/Metric (GQM)..........................................................105 6.7.2 Uso de Mtricas para Suporte a Estimativas ............................................107 6.8 Verificaes e Validaes...................................................................................109 6.8.1 Revises Formais .....................................................................................109 Revises Tcnicas (technical reviews) ........................................................109 Inspees (inspection) .................................................................................110 Wakthroughs................................................................................................110 Revises Gerenciais ....................................................................................110 6.8.2 Inspees de Software..............................................................................111 6.9 Consideraes Finais .........................................................................................112 7 Qualidade de Produto de Software .......................................................................115 7.1 Modelo de qualidade ..........................................................................................115 7.2 Funcionalidade ...................................................................................................116 7.2.1 Adequao ................................................................................................117 7.2.2 Acurcia ....................................................................................................117 7.2.3 Interoperabilidade .....................................................................................117 7.2.4 Segurana de acesso ...............................................................................117 7.2.5 Conformidade............................................................................................118 7.3 Confiabilidade.....................................................................................................118 7.3.1 Maturidade ................................................................................................118 7.3.2 Tolerncia a falhas....................................................................................118 7.3.3 Recuperabilidade ......................................................................................119 7.3.4 Conformidade............................................................................................119 7.4 Usabilidade.........................................................................................................119 7.4.1 Inteligibilidade ...........................................................................................119 7.4.2 Apreensibilidade........................................................................................119 7.4.3 Operacionalidade ......................................................................................120 7.4.4 Atratividade ...............................................................................................120 7.4.5 Conformidade............................................................................................120
7.5 Eficincia ............................................................................................................120 7.5.1 Comportamento em relao ao tempo......................................................121 7.5.2 Utilizao de recursos...............................................................................121 7.5.3 Conformidade............................................................................................121 7.6 Manutenibilidade ................................................................................................121 7.6.1 Analisabilidade ..........................................................................................121 7.6.2 Modificabilidade ........................................................................................121 7.7 Estabilidade ........................................................................................................122 7.7.1 Testabilidade.............................................................................................122 7.7.2 Conformidade............................................................................................122 7.8 Portabilidade.......................................................................................................122 7.8.1 Adaptabilidade ..........................................................................................122 7.8.2 Capacidade para ser instalado.................................................................122 7.8.3 Coexistncia..............................................................................................123 7.8.4 Capacidade para substituir .......................................................................123 7.8.5 Aderncia ..................................................................................................123 7.9 Eficcia ...............................................................................................................124 7.10 Produtividade....................................................................................................124 7.11 Segurana ........................................................................................................124 7.12 Satisfao.........................................................................................................124 8 Concluso ...............................................................................................................126 9 Exerccios de Fixao ............................................................................................129 10 Referncias Bibliogrficas ...................................................................................131 Anexo A Padro de codificao JAVA..................................................................137
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
EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software
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
por exemplo, de gerenciamento de software. Dessa forma, aumenta-se a probabilidade de produzir software de grande porte com qualidade, ou seja, software que satisfaa os requisitos do usurio, bem como as expectativas de tempo e de oramento. As ODSs (Organizaes de Desenvolvimento de Software)1, com o intuito de minimizar os problemas do desenvolvimento do software, tm geralmente adotado metodologias de desenvolvimento de software. Todavia, os paradigmas metodolgicos para desenvolvimento de software tm sido considerados somente em termos de um mtodo de anlise/projeto/implementao, isto , um conjunto de conceitos, tcnicas e notaes. Essa viso elimina os aspectos tecnolgicos, contextuais e organizacionais que potencialmente existem dentro de um processo de software. Os ambientes tradicionais das ODSs geralmente suportam apenas a engenharia do produto, assumindo um processo implcito e tendo como foco principal o produto. Essa viso tem limitado as ODSs no que diz respeito tomada de decises, ao estabelecimento e arquivamento de metas organizacionais, determinao de pontos para melhoria, estipulao de prazos para entrega de produtos e obteno de uma certificao. O captulo 2 apresenta os aspectos evolutivos das ODSs e seus produtos de software. De forma geral, pode-se dividir as funes de uma ODS em trs grupos principais [Garg1996]2: 1. Definir, analisar, simular, medir e melhorar os processos da organizao; 2. Donstruir o produto de software; 3. Medir, controlar, modificar e gerenciar os projetos de software. Estes trs grupos so abordados, respectivamente, pela Engenharia de Processo, pela Engenharia de Produto e pelo Gerenciamento de Projeto. O relacionamento entre estes grupos mostrado na Figura 1.1.
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

Experincias passadas Requisitos do processo Engenharia do processo Modelo do processo Gerenciamento de projeto Processo de desenvolvimento Engenharia do produto Produto de software Requisitos do projeto Requisitos do produto
Figura 1.1: Relacionamento entre engenharia de processo, gerenciamento de projeto e engenharia do produto A engenharia de processo tem como meta a definio e a manuteno dos processos da ODS. Ela deve ser capaz de facilitar a definio, a anlise e a simulao de um processo, assim como estar apta a implant-lo, avali-lo, medi-lo e melhor-lo. A engenharia de processo trata os processos de software de uma forma sistemtica com um ciclo de vida bem definido. O captulo 6 aborda este tema discorrendo sobre qualidade de software, um tema cada vez mais relevante e que engloba avaliao e melhoria contnua dos processos da ODS. O gerenciamento de projeto tem o objetivo de assegurar que processos particulares sejam seguidos, coordenando e monitorando as atividades da engenharia do produto. Um processo de gerenciamento de projeto deve identificar, estabelecer, coordenar e monitorar as atividades, as tarefas e os recursos necessrios para um projeto produzir um produto e/ou servio de acordo com seus requisitos. Todavia, gerenciar projetos de software uma atividade complexa devido a uma srie de fatores, tais como: dinamicidade do processo, grande nmero de variveis envolvidas, exigncia de adaptabilidade ao ambiente de desenvolvimento e constantes alteraes no que foi planejado. Esses fatores dificultam o trabalho das equipes de desenvolvimento na medio do desempenho dos projetos, na verificao de pontos falhos, no registro de problemas, na realizao de estimativas e planejamentos adequados. O captulo 4 aborda esse tema. A engenharia do produto encarregada do desenvolvimento e manuteno dos produtos e servios de software. A principal figura da engenharia do produto a metodologia de desenvolvimento, que engloba uma linguagem de representao, um
Introduo
15
modelo de ciclo de vida e um conjunto de tcnicas. Os ambientes tradicionais de desenvolvimento de software tm se preocupado essencialmente com a engenharia do produto, assumindo um processo implcito e tendo como foco o produto. Todavia, a engenharia do produto por si s insuficiente para suprir as necessidades da ODS e torn-la mais produtiva e adequada s exigncias do mercado. O captulo 3 aborda os modelos de ciclo de vida mais utilizados na engenharia do produto. O captulo 5 descreve as principais atividades da engenharia de produto.
16
2
O PRODUTO DE SOFTWARE E A ORGANIZAO DE DESENVOLVIMENTO
Impulsionados pelas mudanas tecnolgicas e pelo amadurecimento das atividades de desenvolvimento de software os produtos, as organizaes de desenvolvimento (ODSs) e seus processos associados mudaram no decorrer das ltimas dcadas. Este captulo faz uma retrospectiva desses elementos. A seo 2.1 e 2.2 abordam, respectivamente, a evoluo dos produtos de software e a evoluo das organizaes de desenvolvimento. A seo 2.3 apresenta os processos existentes em uma ODS, demonstrando modelos e elucidando conceitos. 2.1 O PRODUTO DE SOFTWARE Tem-se observado muitas mudanas nos produtos de software que, nos ltimos anos, surgem em prateleiras de supermercados ou mesmo disponveis gratuitamente na Web. Conseqncia do aperfeioamento tecnolgico e da maturidade no desenvolvimento de software adquiridos no decorrer dos anos. Anterior revoluo gerada pelo surgimento dos PCs (Personal Computers), o software3, geralmente, era confeccionado dentro da empresa que iria utiliz-lo. Os detalhes do negcio ento eram do conhecimento dos desenvolvedores. O software tambm era monoltico e especfico para rodar na plataforma da empresa, considerando o seu ambiente e os seus processos. De responsabilidade organizacional e no contratual, se o software executasse as funes a que se propunha, geralmente, j satisfazia os seus usurios/clientes. O produto de software hoje confeccionado pelas ODSs possui caractersticas diferenciadas, desde a sua especificao at a entrega. Em primeiro lugar, ele deve
3
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
Figura 2.1: Diferenas do produto de software
O Produto de Software e a Organizao de Desenvolvimento
19
2.2 A ORGANIZAO DE DESENVOLVIMENTO DE SOFTWARE natural que um produto confeccionado com caractersticas to diferentes das iniciais tambm fosse gerado por uma ODS diferente. Nesta seo visto o quanto as organizaes mudaram para satisfazer as necessidades da confeco dos produtos de software e se adequarem s novas tecnologias e tendncias mercadolgicas. 2.2.1 Ncleo de Processamento de Dados Os primeiros tipos de computadores produzidos foram os mainframes, equipamentos caros e de difcil manuteno e operao. Uma empresa que resolvesse adquirir um equipamento deste porte sofria a imediata conseqncia de necessitar contratar, tambm, uma grande equipe para produzir e operar os softwares (tanto os desenvolvidos por ela, quanto os de suporte ao desenvolvimento). Os contratos de venda, aluguel e manuteno desses equipamentos ultrapassavam as cifras de milhares de dlares. Somente em grandes empresas, com um bom faturamento e em grandes universidades, observvamos o computador. As equipes dentro dos centros de desenvolvimento de software eram grandes e era requerida muita especializao por parte de quem desenvolvia software. As ODSs (nomeadas de ncleos ou centros de processamento de dados - CPDs ou NPDs) eram compostas, salvo algumas excees, por setores agrupados baseados nas tarefas (funes) que cada um desempenhava em relao ao desenvolvimento e operao do software. A Figura 2.2 mostra um exemplo de um organograma de um NPD.
Empresa
Ncleo de Processamento de Dados
....
....
Desenvolvimento
Suporte
Produo
Anlise
Programao
Digitao
Conferncia
Operao
Figura 2.2: Exemplo da estrutura de um NPD
20
Na diviso de desenvolvimento se concentrava a confeco do produto de software. O setor de anlise levantava informaes junto aos usurios e especificava4 logicamente e fisicamente o software, enquanto o setor de programao codificava as especificaes definidas pelos analistas de sistemas. Dentro do setor de programao poderamos observar duas equipes distintas: equipe de desenvolvimento (encarregada dos novos programas) e a equipe de manuteno (encarregada de manter os programas j desenvolvidos e em produo). A diviso de suporte possua duas caractersticas principais. A primeira era manter em funcionamento os equipamentos e os softwares, instalando e configurando, alm de ter contnua preocupao com o desempenho. A segunda caracterstica era promover a capacitao do pessoal do NPD. Isso implicava em estudo de novas tecnologias e treinamento apropriado. Devido complexidade do gerenciamento dos mainframes, a diviso de suporte requeria pessoal altamente especializado. Dar suporte operao do software e a seu desenvolvimento no era tarefa fcil. A diviso de produo era responsvel por executar, obter os resultados e implantar as informaes. O setor de digitao realizava a digitao dos documentos ou planilhas que vinham do usurio, alm dos programas do setor de programao. Devido ao pouco acesso que as pessoas tinham aos computadores, os usurios preenchiam planilhas com as informaes a serem armazenadas nos computadores para posterior processamento. O setor de conferncia conferia se havia erros nos dados digitados, se os resultados produzidos pelo processamento estavam corretos etc. Muitos artifcios eram utilizados para garantir a digitao correta dos dados, entre eles o total de lote que representava uma totalizao dos valores digitados para posterior conferncia. As execues eram solicitadas pelos usurios ou tinham datas pr-determinadas. Essas execues eram realizadas no setor de operao que tambm administrava o hardware. A documentao de um sistema era um trabalho muito rduo e cansativo. A utilizao de mquinas de datilografia, pastas mantidas manualmente etc., traziam um custo muito elevado para se manter o sistema atualizado. Por isso, alguns NPDs possuam um setor de documentao que era encarregado de realizar todas as alteraes feitas manualmente por analistas, programadores e operadores. A qualidade do produto e do processo que o confeccionava era uma preocupao constante nos NPDs. Todavia, a Engenharia de Software ainda engatinhava em seus conceitos e no havia maturidade em relao a padres de qualidade do produto e do processo de software. O alto custo do homem especializado em computao e de hora mquina obrigava tambm estas organizaes a medirem seu processo. Em
4
Especificar um software neste contexto significa criar um modelo computacional, independente da plataforma computacional que ser utilizada.
21
suma, os NPDs primavam por usar uma metodologia de desenvolvimento, documentar os sistemas, medir as atividades pessoais e dar um custo para cada tarefa desenvolvida. Os pontos apontados como falhos para esta estrutura esto mais ligados tecnologia empregada do que estrutura propriamente dita. Com a sada do desenvolvimento dos NPDs para pequenas equipes de desenvolvimento em empresas especficas, houve uma perda da qualidade do processo e do produto. Inclusive tornando a computao desacreditada perante aqueles que necessitavam e/ou pretendiam desenvolver um software. 2.2.2 Pequeno Centro de Desenvolvimento A evoluo do hardware e software mudou significativamente o processo de desenvolvimento e a estrutura das organizaes. Com a chegada e barateamento dos PCs, muitas empresas de pequeno e mdio porte puderam adquirir computadores e contratar pequenas equipes para automatizar seus processos. Assim, as funes realizadas de formas distintas dentro de um NPD comearam a ser fundidas no ambiente de desenvolvimento e produo. Figuras pejorativas (e que posteriormente passaram at mesmo a incorporar carreiras organizacionais) surgiram como o programalista (programador + analista) e o anador (analista + programador). Sistemas como folha de pagamento, contas a pagar, contabilidade, controle de estoque, entre outros, invadiram as pequenas e mdias empresas. A funo supervalorizada de quem produzia software tornou-se algo to comum como um escriturrio ou um contador. A Figura 2.3 ilustra um exemplo de um pequeno centro de desenvolvimento dentro de uma empresa de pequeno ou mdio porte.
Diretoria
Pequeno centro de desenvolvimento
....
....
Figura 2.3: Pequeno centro de desenvolvimento Todavia, qual foi o problema destes pequenos centros de desenvolvimento? Em primeiro lugar tinha-se um cliente (usurio) alheio s dificuldades do desenvolvimento de software, que acreditava que qualquer programador resolveria a automao de sua empresa. E em segundo lugar, um grupo de desenvolvimento imaturo metodologicamente e, em sua maioria, descompromissado com o futuro do produto
22
que confeccionavam. Esses dois pontos trouxeram diversos problemas para a informtica. Muitas empresas, em pouco tempo, se viram merc de um software inopervel ou de difcil/impossvel manuteno. Poucos empresrios passaram a confiar em quem produzia software para solucionar os problemas ou melhorar a produtividade de seu negcio. Criou-se uma lacuna entre quem precisava do software e quem o produzia. 2.2.3 Fbrica de Software Com o intuito de preencher esta lacuna, alguns centros de desenvolvimento de software foram montados como empresas apartadas do cliente/usurio. bom deixar claro que as fbricas de software no surgiram em decorrncia de uma idia, mas sim de bons desenvolvedores que passaram a oferecer sua soluo de software para diversas empresas, assegurando uma continuidade do produto que desenvolviam. Isso possibilitava que o comprador do software tivesse uma garantia contratual de manuteno e evoluo do produto. Apesar dos sistemas perderem em especificidade, comeava a despontar uma soluo de software barato (pois era vendido para diversas empresas) e de melhor qualidade. Atualmente, as fbricas de software so realidades e se tornaram muito mais complexas do que poderamos imaginar. Alm de possurem as funes de desenvolvimento que existiam nos NPDs, somaram a si funes de negcio e administrativas, algumas at possuindo departamentos especializados em pesquisa (ver Figura 2.4). Trabalham, muitas vezes, dispersas em reas geogrficas diferentes e sub-contratam servios. So impulsionadas e avaliadas pelos mesmos quesitos de qualquer outra indstria: qualidade do produto e produtividade.
ODS
Projeto 1
(equipe do
designer, gerncia de marketing, gerncia administrativa, Engenharia
Suporte
Anlise
Figura 2.4: Organograma de uma fbrica de software
23
A Figura 2.5 caracteriza algumas diferenas entre a organizao que produzia software na dcada de 1970 e a organizao que atualmente desenvolve software. lgico que nem todas as organizaes se encaixam em uma ou outra ponta. Quando se fala, por exemplo, que no ano 2000 as organizaes esto fora da empresa que necessita do software, no se est ditando nenhuma regra absurda, apenas trata-se do mais comumente encontrado e de uma tendncia que vislumbrada.
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
dentro da empresa que necessida do software pequenas equipes locais modela funcionalidades e necessidades da empresa processo de software ad-hoc lida com responsabilidade organizacional utilizao de metodologias + ciclo de vida planejamento precrio baixo rodzio de pessoal produz software caro
Figura 2.5: NPDs versus fbricas de software A prxima seo apresenta aspectos referentes aos processos utilizados pelas ODSs para produzir software.
2.3 OS PROCESSOS DA ODS Um processo pode ser definido como um conjunto de atividades interrelacionadas que transformam um conjunto de entradas em resultados [ISO12207:95]. Segundo a ISO15504 [ISO15504:1-9:98] processo de software um conjunto de processos utilizados por uma ODS ou um projeto de software para planejar, gerenciar, executar, monitorar, controlar e melhorar as atividades que esto relacionadas com software. O trabalho de Wang [Wang99] apresenta um framework unificado de um sistema de processo para uma ODS. A Figura 2.6 mostra este modelo, que est dividido em trs agrupamentos principais: o modelo do processo, o modelo de avaliao do processo e o modelo de melhoria do processo.
24
Modelagem do sistema de processo
Modelo do processo
Modelo de avaliao do processo
Modelo de melhoria do processo
Subsistema do processo organizacional
Subsistema do processo de desenvolvimento
Subsistema do processo de gerenciamento
Modelo de capacidade do processo
Mtodo de determinao da capacidade do processo
Modelo de melhoria baseado em avaliao
Modelo de melhoria baseado em Benchmark
Escala do desempenho da pratica
Escala da capacidade do processo
Escopo da capacidade do processo
Determinao da capacidade do processo
Agregao de capacidade do projeto
Agregao da capacidade da organizao
Figura 2.6: Estrutura para modelagem do sistema de processo da ODS O modelo do processo utilizado para descrever a organizao, sua categoria, sua hierarquia, o inter-relacionamento e as instncias dos seus processos. O modelo de processo descrito por [Wang1999] identifica trs conjuntos de subsistemas: processo organizacional, processo de desenvolvimento de software e processo de gerenciamento. Os processos organizacionais regulam as atividades que so geralmente praticadas em uma ODS acima do nvel de projeto. Os processos de desenvolvimento e de gerenciamento so interativos e, em paralelo, atuam sobre o projeto. O modelo de avaliao do processo serve para definir procedimentos para avaliar os pontos fortes e fracos dos processos da ODS, alm de identificar os pontos para melhoria. Atravs do modelo de melhoria do processo podem-se definir procedimentos sistemticos para uma efetiva melhoria do desempenho dos processos da ODS, mudando os processos correntes ou adicionando a eles novos processos para correo ou melhoria de problemas identificados. O processo de melhoria vem a seguir do processo de avaliao e o relacionamento entre eles forma um ciclo repetitivo at o processo de a ODS estar otimizado. Exemplo disso o plan-do-checkact descrito por Campos [Campos1992]. O captulo 6 detalhar os aspectos referentes avaliao e melhoria dos processos de software. Diversos modelos, normas e padres definem certificao, avaliao e melhoria para o processo de software, entre eles, podem-se citar: a ISO9000 [ISO9000-3:1997], CMM [Paulk1993] [Paulk1997], CMMI [CMMI:00], ISO15504 [ISO15504:1-9:98] e
25
BootStrap [Kuvaja1993] [Kuvaja1994]. O captulo 6 detalhar os aspectos referentes a essas normas e padres. Apesar das ODSs durante muito tempo negligenciarem a especificao e o gerenciamento de seus processos, estes sempre existiram. Porm, no h um consenso de que tipo de processo de software deva ser utilizado em uma ODS, pois alguns processos se adequam melhor a certos tipos de aplicaes do que outros. Alm disso, uma ODS pode, inclusive, possuir diversos padres de processos de software sendo utilizados em projetos distintos. O reconhecimento das necessidades dos modelos de processo de software tem deixado um amplo campo de trabalho em muitas direes. As ODSs tm verificado que definindo seus processos pode-se melhorar sua eficcia e a qualidade dos produtos e servios que realiza.
26
3
MODELOS DE CICLO DE VIDA DO PROCESSO DE SOFTWARE
A fim de facilitar o entendimento do processo de desenvolvimento de software5, vrios modelos de ciclo de vida tm sido propostos. Estes modelos so descries abstratas do processo de desenvolvimento, tipicamente mostrando as principais atividades e dados usados na produo e manuteno de software, bem como a ordem em que as atividades devem ser executadas. As atividades presentes nos diversos modelos de ciclo de vida de software no so um padro; elas dependem da metodologia6 utilizada no desenvolvimento de um projeto de software. A seguir ser descrito, em detalhes, alguns dos principais modelos de ciclo de vida do processo de software. 3.1 O MODELO CASCATA O modelo de ciclo de vida mais antigo e tambm um dos mais usados o chamado modelo cascata (ou clssico) (vide Figura 3.1). Foi derivado de modelos existentes em outras engenharias e considera que o processo de desenvolvimento de software composto por vrias etapas que so executadas de forma sistemtica e seqencial. Durante a etapa de Definio de Requisitos os servios, as metas e as restries impostas ao sistema so identificados junto aos usurios do software. Nessa etapa, os requisitos identificados tambm so analisados de modo a remover inconsistncias e ambigidades. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.1.
Ressaltamos que processo de desenvolvimento de software est intimamente ligado engenharia do produto de software. 6 Uma metodologia um processo concreto que descreve em detalhes as atividades, passos, artefatos e respectivos responsveis envolvidos no desenvolvimento de um projeto de software. Vrias metodologias diferentes podem estar relacionadas a um modelo de ciclo de vida de software especfico.
28
Na etapa de Projeto do Sistema e do Software, os requisitos identificados so mapeados em componentes de hardware e software, de modo que o sistema possa ser posteriormente implementado. Nessa etapa, a arquitetura geral do sistema tambm estabelecida. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.2.
Figura 3.1: O Modelo Cascata Na etapa de Implementao e Testes Unitrios, o projeto de software implementado em unidades de programas, utilizando-se uma linguagem de programao. Nessa etapa, as unidades implementadas tambm so testadas para assegurar conformidade em relao s suas especificaes. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.3. Na etapa de Integrao e Teste do Sistema, as unidades de programas so integradas e testadas como um sistema completo, para assegurar que todos os requisitos do software sejam atendidos. Recomenda-se que os testes sejam feitos medida que as unidades individuais vo sendo integradas (testes de integrao) e que, ao final da integrao, o sistema completo seja testado novamente (teste de sistema). Por esse motivo, muitas vezes a Integrao considerada como parte integrante da Implementao. No captulo 5, seo 5.4, as atividades de Testes sero detalhadas. Na etapa de Operao e Manuteno, o sistema instalado e colocado em Operao. Posteriormente, quando erros forem encontrados no sistema ou quando forem solicitadas mudanas nos requisitos, o sistema entra numa etapa de Manuteno. As atividades dessa etapa sero detalhadas no captulo 5, seo 5.6.
Modelos de Ciclo de Vida do Processo de Software
29
Na sua forma mais simples, o modelo cascata no apresenta iteraes, como visto na Figura 3.1. Na prtica, porm, o processo de desenvolvimento de software pode ter etapas que so desenvolvidas em paralelo e de forma iterativa (vide Figura 3.2), pois durante uma determinada etapa, problemas existentes na etapa anterior podem ser descobertos (ex: novos requisitos podem ser descobertos durante a realizao da etapa de projeto, o que implica uma iterao para a etapa especificao e anlise de requisitos).
Figura 3.2: O Modelo Cascata com Iteraes Outra limitao do modelo cascata que o mesmo no contempla atividades que so executadas antes do incio do ciclo de vida (ex: Estudo de viabilidade), bem como atividades que so executadas durante todo o ciclo de vida do software (ex: Planejamento e Gerenciamento, Verificao e Validao, Gerncia de Configurao e Documentao). O Estudo de viabilidade deve ser executado antes do incio do projeto de software e tem por objetivo: delinear o escopo do problema a ser resolvido; identificar alternativas de soluo; identificar seus custos e tempo para execuo; identificar potenciais benefcios para o usurio. O ideal fazer uma anlise profunda do problema para se produzir um estudo de viabilidade bem fundamentado. Na prtica, porm, tal anlise tem sido superficial devido a limitaes de tempo e de custo. Como no se tem certeza de que a proposta para a execuo do servio ser aceita pelo usurio em potencial, torna-se bastante arriscado investir muitos recursos nessa etapa.
30
O Planejamento de um projeto de software se caracteriza pela definio das tarefas a serem realizadas durante o seu desenvolvimento, bem como pela atribuio de responsabilidades, custos, prazos, marcos de referncia e recursos para a realizao das mesmas. As atividades de planejamento so executadas desde o incio do projeto at a sua finalizao. O Gerenciamento est intimamente relacionado ao planejamento e tem o foco em garantir que o desenvolvimento do projeto est ocorrendo de acordo com o planejado. Assim, o gerenciamento de um projeto de software gera feedbacks para o planejamento e re-planejamento do projeto. Associadas ao gerenciamento do projeto, esto atividades de gerncia de requisitos (gerencia as mudanas de requisitos e seus impactos durante o desenvolvimento do projeto), gerncia de configurao (gerencia verses do software e as interdependncias entre as partes componentes do software ex: documentos e programas) e gerncia da qualidade (dos produtos desenvolvidos e do processo de desenvolvimento). No captulo 4, as atividades de gerenciamento e planejamento so detalhadas; a seo 5.1 apresenta um detalhamento das atividades de gerncia de requisitos; a seo 5.5 apresenta um detalhamento das atividades de gerncia de configurao; e o captulo 6 detalha as atividades de gerncia da qualidade. As atividades de Verificao e Validao esto relacionadas gerncia da qualidade e so responsveis pelos feedbacks durante o desenvolvimento do software para as demais atividades do ciclo de vida. Na Figura 3.2, essas atividades esto relacionadas s iteraes. Basicamente, Verificao investiga, em cada etapa de desenvolvimento, se o software que est sendo construdo atende aos requisitos especificados. Como exemplos de atividades de Verificao, temos os testes unitrios, de integrao e de sistemas, os quais sero detalhados posteriormente na seo 5.4; e as revises e inspees que sero tratadas no captulo 6. A Validao investiga se as funes oferecidas pelo software so as que o usurio realmente quer, pois possvel que os requisitos especificados no atendam s reais necessidades dos usurios. As atividades de Validao caracterizam-se por contarem com a colaborao direta do usurio em suas execues. Como exemplos de atividades de Validao esto os testes de aceitao, que sero tratados na seo 5.4 e a validao de requisitos que ser tratada na seo 5.1. As atividades de Verificao e Validao so executadas durante todo o ciclo de vida do software, a fim de que erros e omisses sejam descobertos antes de serem propagados de uma etapa para outra. Isso necessrio porque quanto mais tarde erros e omisses forem descobertos, mais dispendioso fica para consert-los. A
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.
Figura 3.3: O Modelo de Desenvolvimento Evolucionrio 3.2.1 O Modelo de Programao Exploratria O objetivo desse modelo o desenvolvimento da primeira verso do sistema o mais rpido possvel. Os sistemas desenvolvidos com esse modelo caracterizam-se por no terem o escopo claramente definido, ou seja, a especificao do escopo feita de forma intercalada ao desenvolvimento. Aps o desenvolvimento de cada uma das
32
verses do sistema, ele mostrado aos usurios para comentrios. Modificaes sucessivas so feitas no sistema at que o mesmo seja considerado adequado. A principal diferena dos outros modelos a ausncia da noo de programa correto. Esse modelo tem sido usado com sucesso para o desenvolvimento de Sistemas Especialistas, no contexto da Inteligncia Artificial (ex: sistemas de reconhecimento de voz, sistemas de diagnstico mdico etc.). 3.2.2 O Modelo de Prototipagem Descartvel O objetivo principal desse modelo entender os requisitos do sistema. Tem sido usado com sucesso para validar partes do sistema (Interface Grfica e aspectos do sistema relacionados arquitetura ex: performance, portabilidade etc.). Como na programao exploratria, a primeira etapa prev o desenvolvimento de um programa (prottipo) para o usurio experimentar. No entanto, ao contrrio da programao exploratria, o prottipo ento descartado e o software deve ser re-implementado na etapa seguinte, usando qualquer modelo de ciclo de vida (ex: cascata). 3.3 O MODELO DE TRANSFORMAO FORMAL Uma especificao formal (definio matemtica, no ambgua) do software desenvolvida e, posteriormente, transformada em um programa executvel (vide Figura 3.4), atravs de regras que preservam a corretude da especificao (passos de refinamento).
Figura 3.4: O Modelo de Transformao Formal Esse modelo tem sido aplicado ao desenvolvimento de sistemas crticos, especialmente naqueles onde a segurana um fator crtico (ex: sistema de controle de trfego areo). No entanto, a necessidade de habilitaes especializadas para aplicar as tcnicas de transformao e a dificuldade de especificar formalmente alguns aspectos do sistema, tais como a interface com o usurio, so fatores que limitam seu uso. 3.4 O MODELO DE DESENVOLVIMENTO BASEADO EM REUSO Esse modelo baseia-se no reuso sistemtico de componentes existentes ou sistemas COTS (Commercial-Off-The-Shelf). Durante o projeto do sistema, os componentes que podem ser reusados so identificados e a arquitetura do sistema
33
modificada para incorporar esses componentes. O sistema , ento, construdo seguindo essa arquitetura revisada. O processo de desenvolvimento divide-se nas seguintes etapas (vide Figura 3.5): Especificao de requisitos: os requisitos do sistema so especificados; Anlise de componentes: identificam-se componentes que so candidatos a serem reusados no projeto do sistema; Modificao dos requisitos: os requisitos identificados so modificados para se adequarem aos componentes a serem reusados; Projeto do sistema com reuso: o sistema projetado, utilizando-se os componentes a serem reusados; Desenvolvimento e integrao: componentes desenvolvidos e todos os componentes so integrados; Validao: o sistema validado pelo usurio final. no-existentes so
Figura 3.5: Desenvolvimento baseado em reuso Esse modelo de ciclo de vida assume que o sistema , em sua maior parte, formado por componentes pr-existentes. Assim, o processo de desenvolvimento passa a ser similar ao de uma linha de montagem. Essa abordagem de desenvolvimento tem se tornado muito importante, contudo ainda h pouca experincia com ela em larga escala. 3.5 MODELOS ITERATIVOS Os requisitos de um sistema sempre evoluem durante o curso de um projeto. Assim, a iterao do processo sempre faz parte do desenvolvimento de grandes sistemas de software. Iteraes podem ser aplicadas a qualquer modelo do ciclo de vida de software, mesmo no modelo cascata, como vimos anteriormente. Nesse contexto, h duas abordagens relacionadas que so mais adequadas para o tratamento de iteraes:
34
Desenvolvimento Espiral; Desenvolvimento Incremental. 3.5.1 O Modelo de Desenvolvimento Espiral
Acrescenta aspectos gerenciais (planejamento, controle e tomada de deciso) ao processo de desenvolvimento de software, ou seja, anlise de riscos em intervalos regulares. O processo de desenvolvimento representado como uma espiral, ao invs de uma seqncia de atividades (vide Figura 3.6). O modelo define quatro quadrantes, nos quais as atividades (gerenciais ou tcnicas) de um projeto so executadas durante um ciclo na espiral: Determinao dos objetivos, alternativas e restries: os objetivos especficos para a etapa so identificados e alternativas para realizar os objetivos e restries so encontradas; Anlise das alternativas e identificao e/ou resoluo de riscos: os riscos principais so identificados, analisados e buscam-se meios para reduzir esses riscos; Desenvolvimento e validao da verso corrente do produto: um modelo apropriado para o desenvolvimento escolhido, o qual pode ser qualquer um dos modelos de ciclo de vida; Planejamento: o projeto revisto e o prximo ciclo da espiral planejado.
Figura 3.6: O modelo espiral
35
A espiral representa o curso do projeto, onde, a cada volta, um novo produto construdo (ex: documento de requisitos, modelo de projeto, implementao etc.). Cada volta na espiral representa uma etapa no processo de desenvolvimento. No h etapas fixas como especificao ou projeto (o contedo de uma volta na espiral escolhido dependendo do produto requerido pela etapa). Os riscos so avaliados explicitamente e resolvidos ao longo do processo. 3.5.2 O Modelo de Desenvolvimento Incremental Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega so divididos em incrementos, com cada incremento representando parte da funcionalidade requerida (vide Figura 3.7). Os requisitos dos usurios so priorizados e os requisitos de mais alta prioridade so includos nas iteraes iniciais. Uma vez que o desenvolvimento de um incremento iniciado, os requisitos so "congelados", embora os requisitos possam continuar evoluindo para incrementos posteriores. Em certos aspectos similar programao exploratria. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento.
Figura 3.7: O modelo incremental As principais vantagens do modelo incremental so: A funcionalidade do sistema estar disponvel mais cedo, pois ela entregue a partir dos incrementos; Incrementos iniciais agem como um prottipo para ajudar a elicitar requisitos para incrementos finais; Diminuem-se os riscos de falhas no projeto como um todo; Os servios de prioridade mais alta do sistema tendem a receber mais testes.
36
3.6 CONSIDERAES FINAIS Modelos de ciclo de vida de software so descries abstratas do processo de desenvolvimento, tipicamente mostrando a seqncia de execuo das principais atividades envolvidas na produo e evoluo de um sistema de software. Existem vrios modelos de ciclo de vida e todos eles apresentam pontos positivos e negativos. Parte do trabalho do Engenheiro de Software escolher o modelo de ciclo de vida mais adequado s necessidades do cliente/usurio e da empresa que ir desenvolver o software. Nos captulos 4 e 5 as principais atividades envolvidas no processo de desenvolvimento de software, independentemente do modelo de ciclo de vida adotado, sero descritas em detalhes. O foco ser principalmente nas atividades de Gerenciamento, Requisitos e Testes, as quais esto mais intimamente relacionadas com a qualidade do produto de software. A etapa de planejamento e gerenciamento, apresentada no captulo 4, responsvel por garantir que o produto seja entregue no prazo e no custo desejados, bem como por definir critrios de acompanhamento do progresso do projeto. A qualidade do software comea a ser fomentada na etapa de requisitos, pois nessa etapa que so determinados os principais atributos de qualidade relevantes para o usurio do sistema. Finalmente, a etapa de testes um dos principais mecanismos para garantir que o produto final seja entregue com qualidade. No captulo 6 outras atividades ligadas garantia da qualidade sero abordadas.
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
Walker [Walker1997] conclui que: o desenvolvimento de software ainda imprevisvel; somente 10% dos projetos de software so entregues com sucesso dentro das estimativas de oramento e custo; a disciplina de gerncia , portanto, mais um discriminador de sucesso ou falha dos projetos. Muitas pesquisas enfatizam que o gerenciamento a principal causa do sucesso ou fracasso dos projetos de software. Apesar disso, o gerenciamento de projetos de software ainda pouco abordado e praticado nas ODSs [Machado2001]. Jones [Jones1999] destaca que a ausncia de um processo de gerenciamento apropriado, aliado a estimativas deficientes de custo e de tempo, uma das principais causas das falhas dos projetos de software. Os principais padres e normas para SPA/SPI (Software Process Assessment/ Software Process Improvement) tm colocado o gerenciamento de projetos como um dos requisitos bsicos para que uma empresa inicie a melhoria de seu processo. Contudo, a introduo de padres e normas dentro das ODSs tem se mostrado complexa demais, alm de causar uma sobrecarga de trabalho significativa. Segundo Belloquin [Belloquin1999], esses padres e normas definem prticas que devem ser realizadas, porm no determinam como execut-las. O captulo 6 ir discorrer sobre esses padres. 4.1 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE J em 1989, Humphrey [Humphrey1989] constatou que: a ausncia de prticas administrativas no desenvolvimento de software a principal causa de srios problemas enfrentados pelas organizaes, tais como: atrasos em cronogramas, custo maior do que o esperado e presena de defeitos, ocasionando uma srie de inconvenincias para os usurios e enorme perda de tempo e de recursos. Ainda hoje esta afirmao tem sido confirmada por diversos autores. Na atual cultura das ODSs, o planejamento, quando ocorre, feito de forma superficial [Weber1999] [Sanches2001]. A maioria dos projetos de software realizada sem um planejamento de como a idia modelada, durante o levantamento de requisitos e necessidades dos clientes, pode ser transformada em produto. Os gerentes de projeto esto desacostumados a estimar [Vigder1994]. Quando estimam, costumam basear-se em estimativas passadas, mesmo sabendo que elas podem estar incorretas (no sabem tambm precisar o quanto elas esto incorretas). H gerente que se recusa a estimar somente por julgar perda de tempo, uma vez que se corre o risco de obter resultados incorretos e, portanto, estar desperdiando tempo. Boas estimativas de custo, esforo e prazo de software requerem um processo ordenado que defina a utilizao de mtricas de software, mtodo e ferramenta de
Planejamento e Gerenciamento de Projetos de Software
39
estimativa. As ODSs, de forma geral, no detm conhecimentos e recursos para isso [Vigder1994]. Estimar, medir e controlar um projeto de software tarefa difcil, pois o desenvolvimento de software uma atividade criativa e intelectual, com muitas variveis envolvidas (como metodologias, modelos de ciclo de vida, tcnicas, ferramentas, tecnologia, recursos e atividades diversas). Os gerentes inexperientes tentam cumprir prazos dando a mxima velocidade na fase inicial e esto despreparados para os momentos de impasse, quando os ajustes so inevitveis. A dinamicidade do processo de software dificulta tambm o gerenciamento efetivo de projetos de software, devido s alteraes constantes nos planos de projetos, redistribuio de atividades, incluso/excluso de atividades, adaptao de cronogramas, realocao de recursos, novos acordos com os clientes, entregas intermedirias no previstas etc. Um projeto de software tambm deve adaptar-se ao ambiente, dependendo da disponibilidade de recursos, ferramentas e habilidades do pessoal ou equipe. 4.2 PRINCIPAIS ATIVIDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE NAS ODSS A gerncia de projetos trata do planejamento e acompanhamento das atividades voltadas a assegurar que o software seja entregue dentro do prazo previsto e de acordo com os requisitos especificados pelas organizaes que esto desenvolvendo e adquirindo o software. O gerenciamento de projeto necessrio porque o desenvolvimento de software est sempre sujeito a restries de oramento e cronograma. Gerentes lutam para cumprir os objetivos dos projetos, os quais tm prazos finais difceis de serem cumpridos. Freqentemente, os sistemas que so entregues no satisfazem aos usurios, os gastos com manuteno so muito grandes e os prazos no so cumpridos. Muitas vezes, esses problemas ocorrem no por incompetncia das pessoas, mas por falha nas tcnicas de gerncia empregadas nos projetos. Nas prximas subsees, sero abordados os aspectos envolvidos com a gerncia de projetos de software. O gerenciamento de um projeto de software difere de outros projetos de engenharia porque, no caso do software, o produto no concreto (a anlise do progresso do projeto depende de sua documentao). No existe um processo padro de gerncia e grandes sistemas de software so normalmente desenvolvidos uma nica vez, o que restringe o reuso de informaes de projetos anteriores. Dependendo da empresa e do projeto, as atividades mais comuns da gerncia so:
40
4.2.1
Escrever a proposta do projeto; Fazer estimativas do projeto (custo, tempo etc.); Definir marcos de referncia; Analisar os riscos; Fazer o planejamento e o cronograma do projeto; Selecionar e avaliar pessoal; Fazer acompanhamento e revises; Escrever os relatrios de acompanhamento; Fazer apresentaes sobre o projeto. O Planejamento do Projeto
uma atividade contnua, desde a concepo inicial do sistema, at a sua entrega. Os planos devem ser revisados regularmente, medida que novas informaes se tornam disponveis. Caso seja necessrio, os planos devem ser atualizados. O plano de projeto um documento que descreve as atividades, os recursos e o cronograma usados para o desenvolvimento do sistema. Uma possvel estrutura para esse documento descrita na Figura 4.1.
Figura 4.1: Estrutura de um plano de projeto
41
4.2.2 A Seleo de Pessoal Nem sempre possvel conseguir as pessoas ideais para trabalharem num projeto devido a limitaes, tais como: Oramento de projeto pode no permitir o uso de pessoal altamente qualificado e, conseqentemente, bem pago; Pessoal com experincia apropriada pode no estar disponvel; Pode fazer parte da poltica da organizao desenvolver as habilidades dos empregados durante um projeto de software. Ou seja, projetos podem ser usados como forma de treinar o pessoal. Assim, gerentes tm de alocar o pessoal disponvel, dentro das restries impostas. Muitas vezes, tambm papel do gerente participar da seleo para a contratao de pessoal para um projeto. 4.2.3 O Gerenciamento de Riscos Um risco uma probabilidade de que alguma circunstncia adversa acontea. O gerenciamento de riscos trata da identificao dos riscos e da preparao de planos para minimizar os seus efeitos no projeto. Riscos podem ser classificados de acordo com vrios critrios. Uma possvel classificao seria: Riscos de projeto: afetam cronogramas ou recursos; Riscos de produto: afetam a qualidade ou desempenho do software que desenvolvido; Riscos de negcio: afetam a organizao que est desenvolvendo ou adquirindo o software. O processo de gerenciamento de riscos pode ser dividido nas seguintes atividades: Identificao dos riscos: identificar os riscos de projeto, produto e negcio. Esses riscos podem estar associados escolha da tecnologia, das pessoas, mudanas de requisitos, estimativas do projeto etc.; Anlise dos riscos: avaliar a probabilidade e as conseqncias dos riscos. Uma possvel classificao para a probabilidade e para as conseqncias pode ser: Probabilidade: muito baixa, baixa, moderada, alta ou muito alta. Conseqncia: catastrfica, sria, tolervel ou insignificante; Planejamento dos riscos: preparar planos, definindo estratgias para gerenciar os riscos. As estratgias podem ser:
42
- Estratgias para evitar o risco: a probabilidade de que o risco surja reduzida. - Estratgias para minimizar o risco: O impacto do risco no projeto ou no produto ser reduzido. - Planos de contingncia: se o risco surgir, os planos de contingncia trataro aquele risco; Monitoramento dos riscos: monitorar os riscos ao longo do projeto. Avalia cada risco identificado regularmente para decidir se ele est se tornando menos ou mais provvel. Tambm avalia se as conseqncias do risco tm se modificado. Cada risco-chave deve ser discutido nas reunies de progresso do gerenciamento. 4.2.4 A Definio das Atividades, Marcos de Referncia e Produtos Entregues ao Usurio Associados s atividades, podem existir marcos de referncia (milestones) ou produtos. Um marco de referncia um ponto final, bem definido, de uma etapa ou atividade. A escolha dos marcos de referncia e das suas freqncias de produo est relacionada ao modelo de ciclo de vida utilizado no projeto. Por exemplo, num projeto desenvolvido utilizando o ciclo de vida em cascata, ao final de cada etapa de desenvolvimento, pode haver um marco de referncia. Nesse caso, um possvel marco de referncia seria o modelo de anlise e projeto, o qual seria produzido ao final da etapa de mesmo nome. Os marcos de referncia podem ser tambm associados concluso de uma atividade. Nesse caso, um marco de referncia associado a uma atividade da etapa de anlise e projeto poderia ser a produo de um diagrama especfico do modelo, como, por exemplo, um diagrama de classes, produzido por uma atividade associada a essa etapa de desenvolvimento. Por outro lado, um produto a ser entregue ao cliente (deliverable) diferencia-se do marco de referncia justamente pelo fato de que nem todos os marcos de referncia so entregues ao cliente. Ou seja, produtos so marcos de referncia, mas marcos de referncia no so necessariamente produtos. 4.2.5 A Definio do Cronograma O cronograma divide o projeto em tarefas e estima o tempo e os recursos requeridos para completar cada tarefa. Sempre que possvel, devem ser definidas tarefas concorrentes de modo a fazer o melhor uso do pessoal. Outra premissa que deve ser levada em conta tentar definir as tarefas que so independentes umas das outras. Isso evita atrasos causados por uma tarefa que est esperando por uma outra
43
ser completada. No entanto, a definio de bons cronogramas depende da intuio e da experincia dos gerentes de projeto. Ou seja, no existe uma cincia exata que determine a melhor forma de se construir um cronograma. Dentre os principais problemas relacionados confeco de um cronograma, pode-se citar: Estimar o esforo associado resoluo dos problemas e, conseqentemente, o custo do desenvolvimento de uma soluo difcil; A produtividade no proporcional ao nmero de pessoas que esto trabalhando numa tarefa; Adicionar pessoas a um projeto atrasado pode fazer com que ele se atrase ainda mais. Isso ocorre devido ao overhead da comunicao; O inesperado sempre acontece. Sempre permita a contingncia no planejamento e uma folga no cronograma; As tarefas no devem ser muito pequenas, de modo que no haja uma interrupo constante dos desenvolvedores pelo gerente do projeto. Assim, recomendado que as tarefas tenham a durao entre uma e duas semanas. 4.3 A GERNCIA DE PROJETOS SOB A TICA DO PMBOK Ao se abordar o planejamento e a gerncia de projeto no se pode deixar de citar o PMBOK Project Management Body of Knowledge, criado pelo PMI Project Management Institute. O PMI (www.pmi.org) uma associao de profissionais de gerenciamento de projetos que existe desde 1969. Essa associao criou em 1986 a primeira verso do PMBOK Project Management Body of Knowledge. O PMBOK um guia que descreve a somatria de conhecimento e as melhores prticas dentro da profisso de gerenciamento de projetos. um material genrico que serve para todas as reas de conhecimento, ou seja, tanto para construo de um edifcio como para a produo de software. A meta do gerenciamento de projetos, segundo o PMBOK conseguir exceder as necessidades e expectativas dos stakeholders7. Todavia, satisfazer ou exceder essas necessidades envolve um balanceamento entre as vrias demandas concorrentes em relao a: Escopo, tempo, custo e qualidade (objetivos do projeto); Stakeholders com necessidades e expectativas diferenciadas;
Requisitos identificados (necessidades) e requisitos no identificados (expectativas).

7
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
O PMBOK [PMBOK2000] organiza os processos de gerenciamento de projetos em cinco grupos (Figura 4.2): processos de inicializao, processos de planejamento, processos de execuo, processos de controle e processos de finalizao.
Processos de Inicializao
Processos de Planejamento
Processos de controle
Processos de execuo
Processos de finalizao
Figura 4.2: Processos do gerenciamento de projetos do PMBOK Os processos de inicializao autorizam o incio do projeto ou de uma fase do projeto. Os processos de planejamento definem e refinam os objetivos do projeto selecionando as melhores alternativas para realiz-lo. Os processos de execuo coordenam pessoas e outros recursos para a realizao do projeto, baseando-se no planejamento. Os processos de controle monitoram e medem o progresso do que est sendo executado, com o intuito de tomar aes corretivas, quando necessrias. Os processos de finalizao formalizam o aceite e a finalizao do projeto ou de uma fase do projeto. Os processos do PMBOK esto organizados por reas de conhecimento, que se referem a um aspecto a ser considerado dentro do gerenciamento de projetos. Dentro dessas reas de conhecimento os cinco grupos de processos acima descritos podem ocorrer. A Figura 4.3 mostra as 9 reas de conhecimento do PMBOK. A seguir sero descritos os processos de cada rea de conhecimento do PMBOK. Todos os processos das reas abaixo descritos interagem uns com os outros e tambm com os processos das demais reas de conhecimento. Cada processo pode envolver esforo de um ou mais indivduos ou grupos de indivduos dependendo das necessidades do projeto. Cada processo, geralmente, ocorre pelo menos uma vez em cada fase do projeto.
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
Figura 4.3: reas do gerenciamento de projetos do PMBOK 4.3.1 Gerncia de Integrao de Projetos A gerncia de integrao engloba os processos necessrios para garantir que os vrios elementos de um projeto sejam propriamente coordenados. Objetiva realizar as negociaes dos conflitos entre objetivos e alternativas do projeto, com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execuo do plano de projeto e o controle geral das mudanas. Essa rea de processo incluiu os seguintes processos principais: Desenvolvimento do plano do projeto - agregar os resultados dos outros processos de planejamento construindo um documento coerente e consistente; Execuo do plano do projeto - levar a cabo o projeto atravs da realizao das atividades nele includas; Controle geral de mudanas - coordenar as mudanas atravs do projeto inteiro. 4.3.2 Gerncia de Escopo de Projetos A gerncia do escopo do projeto inclui os processos requeridos para assegurar que o projeto inclua todo o trabalho necessrio, e to somente o trabalho necessrio,
46
para complementar de forma bem sucedida o projeto. A preocupao fundamental compreende definir e controlar o que est ou no includo no projeto. Essa rea de processo incluiu os seguintes processos principais: Iniciao - comprometer a organizao a iniciar a prxima fase do projeto; Planejamento do escopo - desenvolver uma declarao escrita do escopo como base para decises futuras do projeto; Detalhamento do escopo - subdividir os principais subprodutos do projeto em componentes menores e mais manejveis; Verificao do escopo - formalizar a aprovao do escopo do projeto; Controle de mudanas de escopo - controlar as mudanas do escopo do projeto. 4.3.3 Gerncia de Tempo de Projetos A gerncia de tempo do projeto objetiva garantir o trmino do projeto no tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades, e de elaborao e controle de cronogramas. Essa rea incluiu os seguintes processos principais: Definio das atividades - identificar as atividades especficas que devem ser realizadas para produzir os diversos subprodutos do projeto; Seqenciamento das atividades - identificar e documentar as relaes de dependncia entre as atividades; Estimativa da durao das atividades - estimar a quantidade de perodos de trabalho que sero necessrios para a implementao de cada atividade; Desenvolvimento do cronograma - analisar a seqncia e as duraes das atividades e os requisitos de recursos para criar o cronograma do projeto; Controle do cronograma - controlar as mudanas no cronograma do projeto. 4.3.4 Gerncia de Custo de Projetos 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; Controle dos custos - controlar as mudanas no oramento do projeto. 4.3.5 Gerncia da Qualidade de Projetos A gerncia da qualidade objetiva garantir que o projeto satisfar as exigncias para as quais foi contratado. Consiste de planejamento, garantia e controle de qualidade. Essa rea de processo incluiu os seguintes processos principais: Planejamento da qualidade - identificar quais padres de qualidade so relevantes para o projeto e determinar a forma de satisfaz-los; Garantia da qualidade - avaliar periodicamente o desempenho geral do projeto buscando assegurar a satisfao dos padres relevantes de qualidade; Controle da qualidade - monitorar os resultados especficos do projeto para determinar se eles esto de acordo com os padres de qualidade relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatrios. 4.3.6 Gerncia de Recursos Humanos de Projetos A gerncia de recursos humanos objetiva garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento organizacional, alocao de pessoal e definio de equipe. Essa rea de processo incluiu os seguintes processos principais: Planejamento organizacional - identificar, documentar e designar as funes, responsabilidades e relacionamentos de reporte dentro do projeto; Montagem da equipe - conseguir que os recursos humanos necessrios sejam designados e alocados ao projeto; Desenvolvimento da equipe - desenvolver habilidades individuais e do grupo para aumentar o desempenho do projeto. 4.3.7 Gerncia de Comunicao de Projetos A gerncia de comunicao tem por objetivo principal garantir a gerao adequada e apropriada, coleta, disseminao, armazenamento e disponibilizao da informao.
48
Essa rea de processo incluiu os seguintes processos principais: Planejamento das comunicaes - determinar as informaes e comunicaes necessrias para os interessados: quem necessita de qual informao, quando necessitar dela e como isso ser fornecido; Distribuio das informaes - disponibilizar as informaes necessrias para os interessados do projeto, da maneira conveniente; Relato de desempenho - coletar e disseminar as informaes de desempenho. Inclui relatrios de situao, medio de progresso e previses; Encerramento administrativo - gerar, reunir e disseminar informaes para formalizar a concluso de uma fase ou de todo o projeto. 4.3.8 Gerncia de Risco de Projetos A gerncia de risco objetiva maximizar os resultados de ocorrncias positivas e minimizar as conseqncias de ocorrncias negativas. Consiste de identificao, quantificao, tratamento e controle dos riscos do projeto. Essa rea de processo incluiu os seguintes processos principais: Identificao dos riscos - determinar quais os riscos so mais provveis afetar o projeto e documentar as caractersticas de cada um; Quantificao dos riscos - avaliar os riscos, suas interaes e possveis conseqncias; Desenvolvimento das respostas aos riscos - definir as melhorias necessrias para o aproveitamento de oportunidades e respostas s ameaas; Controle das respostas aos riscos - responder s mudanas nos riscos no decorrer do projeto. 4.3.9 Gerncia de Aquisio de Projetos A gerncia de aquisio tem por objetivo principal obter bens e servios externos organizao executora. Consiste na seleo de fornecedores, planejamento de aquisio, planejamento de solicitao, solicitao de propostas, e administrao e encerramento de contratos. Essa rea de processo incluiu os seguintes processos principais: Planejamento das aquisies - determinar o que contratar e quando; Preparao das aquisies - documentar os requisitos do produto e identificar os fornecedores potenciais; Obteno de proposta - obter propostas de fornecimento, conforme apropriado a cada caso (cotaes de preo, cartas-convite, licitao);
49
Seleo de fornecedores - escolher entre os possveis fornecedores;
Administrao dos contratos - gerenciar os relacionamentos com os fornecedores; Encerramento do contrato - completar e liquidar o contrato incluindo a resoluo de qualquer item pendente. 4.4 CONSIDERAES FINAIS O bom planejamento essencial para o sucesso de um projeto. A natureza intangvel do software causa problemas para o gerenciamento. Gerentes tm vrias atividades, sendo as mais importantes o planejamento e a elaborao de estimativas e de cronogramas. Essas atividades so processos interativos que continuam ao longo do curso do projeto. Marcos de referncia so resultados de atividades e produtos so marcos de referncia que so entregues aos clientes. O gerenciamento de risco uma rea que toma cada vez mais importncia no desenvolvimento de software e trata da identificao de riscos que podem afetar o projeto. Trata tambm do planejamento, para assegurar que esses riscos no se transformaro em ameaas. Os riscos podem ser de projeto, de produto ou de negcio. O PMBOK fornece conceitos importantes para quem deseja gerenciar adequadamente os projetos de software. Outros modelos tambm retratam as necessidades da gerncia de projetos e sero vistos no captulo 6. Estudos realizados na dcada de 1990 sobre gerenciamento de projetos de software deixaram evidente que as prticas de gerenciamento de projetos devem ser melhoradas para que os projetos de software tenham sucesso. Dada esta preocupao, muitos modelos e normas para SPA/SPI evoluram principalmente com a incluso de prticas gerenciais para os projetos de software. Exemplos so: CMM [Paulk1993] para CMMI [CMMI:2000]; o adendo norma ISO12207 [ISO12207:1995] em 2001 [ISO12207:2000] e os novos processos de gerenciamento inseridos na ISO15504 no decorrer de sua confeco. Contudo, Machado [Machado2001] demonstrou, recentemente, que apesar das pesquisas evidenciarem que o problema da indstria de software mais gerencial do que tcnico, a gerncia de projetos no est sendo considerada como deveria. Atravs da comparao das prticas de gerenciamento propostas nos padres e normas para SPA/SPI com as contidas no PMBOK Project Management Body Knowledge [PMBOK2000], concluiu-se que os requisitos de gerenciamento de projeto no esto representados devidamente nos modelos [Machado2001]. O gerenciamento de projeto
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
Este captulo aborda as principais atividades envolvidas no processo de desenvolvimento de software, independente do modelo de ciclo de vida adotado. Ao final do captulo discute-se a automao deste processo atravs do uso de ferramentas CASE8. 5.1 ENGENHARIA DE REQUISITOS O objetivo do desenvolvimento de software a criao de sistemas de software que correspondam s necessidades de clientes e usurios. Uma correta especificao dos requisitos do software essencial para o sucesso do esforo de desenvolvimento. Mesmo que tenhamos um sistema bem projetado e codificado, se ele foi mal especificado, certamente ir desapontar o usurio e causar desconforto equipe de desenvolvimento, que ter de modific-lo para se adequar s necessidades do cliente. De acordo com o Insitute of Electrical and Electronics Engineers - IEEE, o processo de aquisio, refinamento e verificao das necessidades do cliente chamado de engenharia de requisitos [IEEE1984]. A Engenharia de Requisitos (E.R.) aborda uma etapa crucial no ciclo de vida do desenvolvimento de Software por tratar de conhecimentos no apenas tcnicos, mas tambm gerenciais, organizacionais, econmicos e sociais. Vrias abordagens tm sido propostas para apoiar a engenharia de requisitos, sendo a maioria baseada em linguagens capazes de expressar os desejos dos clientes/usurios. Entre os aspectos importantes das linguagens de especificao de requisitos, so destacados: Poder de expresso: o conjunto de construtores disponveis na linguagem deve ser rico o suficiente para permitir uma traduo (mapeamento) natural dos fenmenos do mundo real em descries escritas na linguagem;
Computer Aided Software Engineering.
52
Formalidade: definio de regras precisas de interpretao, que permitam a prova de propriedades da especificao dos requisitos, bem como a possibilidade de descobrir inconsistncias e/ou incompletudes. Boehm [Boehm1989] define E.R. como uma disciplina para desenvolver uma especificao completa, consistente e no ambgua que sirva como base para um acordo entre todas as partes envolvidas, descrevendo o que o produto de software ir fazer (mas no como ele ser feito). Observe que Boehm define a E.R. como um processo que envolve uma grande colaborao entre o cliente e o desenvolvedor. A especificao de requisitos funciona como um meio de comunicao para atingir um acordo acerca do software pretendido. enfatizada tambm a importncia de se tentar evitar decises de projeto no momento da definio de requisitos (desejvel, porm difcil de obter na prtica). Meyer [Meyer1988] afirma que especificar o documento de requisitos de um software definir de uma forma completa e no ambgua: As caractersticas externas do software oferecidas aos usurios; A forma pela qual o software integrado no sistema.
J Davis [Davis1993] informa que, durante a etapa de requisitos, necessrio analisar e, portanto, entender o problema a ser resolvido. A anlise do problema a atividade que inclui o entendimento das necessidades do usurio, bem como as limitaes impostas na soluo. Estudos mostram que existe um grande nmero de sistemas de informao que no so apropriados para as necessidades de seus usurios. De fato, o nvel de aceitao para sistemas de informao comercial da ordem de 40%, enquanto para sistemas de tempo real, o ndice de aceitao sobe para 75%. Muitas vezes, o motivo de tal insucesso devido ao fato de que os requisitos no foram bem definidos e/ou entendidos. Do ponto de vista jurdico, desejamos que o documento de requisitos funcione como um acordo contratual entre os clientes e fornecedores de software. Portanto, necessrio que existam tcnicas apropriadas para especificao de sistemas. A equipe responsvel pelo desenvolvimento de software deve ter a obrigao de inquirir sobre os requisitos dos seus clientes, visando a uma melhor compreenso do sistema a ser desenvolvido. Assim, necessrio um melhor conhecimento das tcnicas de aquisio de requisitos. Os desenvolvedores de software tambm devem ser obrigados a informar seus usurios sobre a soluo proposta, no bastando apenas um manual de usurios. Uma forma razovel para apresentar o sistema seria atravs da definio apropriada dos requisitos do sistema.
O Processo de Desenvolvimento de Software
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.
Figura 5.1: Erros e custo de correo Muitos estudos tm mostrado que, quanto mais tarde for detectada uma deciso errada, mais caro ser corrigi-la [Boehm1989]. Por exemplo, a correo de um erro de especificao cerca de cinco vezes mais cara do que uma correo de um erro de codificao. A engenharia de requisitos fora os clientes a considerarem os seus requisitos cuidadosamente e revis-los no contexto do problema. O objetivo desse processo alcanar uma especificao completa do sistema de software. So feitas anotaes e refinamentos dos requisitos, aumentando a transparncia do sistema de software e melhorando a comunicao entre clientes e desenvolvedores. Um projeto s ser bem sucedido se houver um consenso entre as partes envolvidas (clientes e desenvolvedores), que representado pela especificao de requisitos. A especificao de requisitos funciona como um padro contra o qual o projeto e a implementao pode ter sua completude e corretude testadas. As atividades da engenharia de requisitos servem tambm como importante ponto inicial para as subseqentes atividades de controle e gerncia, tais como: estimativa de custo, tempo e recursos necessrios.
54
5.1.1 Caractersticas Especficas da Engenharia de Requisitos Os perfis do engenheiro de software e do engenheiro de requisitos so bastante distintos. O engenheiro de software movido por tecnologia, usa uma abordagem transformacional (isto , procura transformar uma especificao em cdigo) e se preocupa em provar suas transformaes (pelo menos num futuro prximo). J o engenheiro de requisitos se interessa tanto pelo sistema a ser construdo, quanto pelo ambiente no qual ele ir funcionar. Ele precisa modelar os conhecimentos, ou seja, representar os conhecimentos adquiridos, atravs de uma notao adequada. No existe a possibilidade de se provar formalmente que os requisitos modelados so, de fato, aqueles que o cliente apresentou. O processo caracterizado por interaes humanas que envolvem comunicao, aprendizagem e negociao (vide Figura 5.2).
Figura 5.2: Engenheiro de Requisitos X Engenheiro de Software As tarefas do engenheiro de requisitos podem ser divididas em quatro grandes etapas [Pressman2001]: Reconhecimento do problema; Avaliao e sntese; Especificao; Validao.
A etapa de reconhecimento do problema visa entender os elementos bsicos, de acordo com a percepo do cliente/usurio. O engenheiro de requisitos precisa estabelecer contato com a equipe tcnica e gerencial da organizao do cliente/usurio e da organizao responsvel pelo desenvolvimento do software. O gerente de projeto poder atuar como coordenador, para facilitar o estabelecimento de caminhos de comunicao. Durante a etapa de avaliao e sntese de soluo, o engenheiro de requisitos deve avaliar o fluxo e estrutura de informaes, refinar as funes do software em detalhe, estabelecer caractersticas da interface com o usurio e descobrir limitaes
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; Habilidade de entender o ambiente do usurio/cliente; Habilidade de lidar com problemas complexos;
Habilidade de aplicar elementos de software/hardware ao ambiente do usurio/cliente; Habilidade de comunicar-se bem, tanto de forma escrita, como oral; Habilidade de evitar detalhes desnecessrios, concentrando-se nos objetivos gerais do software. A atividade de engenharia de requisitos requer uma intensa atividade de comunicao. Durante a comunicao, problemas de omisso e m interpretao podem causar dificuldades entre o engenheiro e o cliente/usurio. Freqentemente, informaes obtidas de usurios entram em conflito com requisitos descritos anteriormente por outras pessoas. Nesses casos, preciso negociar uma soluo para o impasse. A qualidade da negociao depende de um bom entendimento e de uma anlise rigorosa. Porm, essa atividade no trivial, pois os indivduos sabem bem mais do assunto do que so capazes de informar (o chamado de conhecimento tcito) e nem sempre desejam, necessariamente, um sistema baseado em computadores. Grandes sistemas de software possuem, usualmente, uma clientela bastante heterognea. Diferentes clientes desfrutam de variadas prioridades. Diferentes requisitos possuem diversos graus de importncia. Dificilmente, quem encomenda o sistema (o cliente, responsvel pelo pagamento) ser o usurio (principal) do software.
56
comum a imposio de requisitos que so devidos questo organizacional ou limitaes financeiras da empresa. Essas solicitaes podem entrar em conflito com os requisitos dos usurios. Portanto, as vises parciais dos clientes muitas vezes no so consistentes entre si. A evoluo dos sistemas um outro aspecto de suma importncia. Sabemos que, independentemente da etapa de desenvolvimento de um sistema, ocorrero mudanas nos requisitos. Portanto, devemos abordar a questo da coordenao das mudanas dos requisitos, seu impacto em outras partes do software e como corrigir erros de especificao, de forma que efeitos colaterais sejam evitados (ou minimizados). Muitas vezes, as mudanas so realizadas apenas no cdigo, causando uma divergncia entre o sistema de software implementado e sua especificao de requisitos. Assim, entre as metas da engenharia de requisitos esto: Propor tcnicas de comunicao que visem facilitar a aquisio de informaes; Desenvolver tcnicas e ferramentas que resultem em especificaes de requisitos adequadas e precisas; Considerar alternativas na especificao de requisitos.
A produo de uma boa especificao de requisitos no uma tarefa fcil, tendo em vista os problemas j expostos. A seguir, so enumeradas as propriedades que uma especificao apropriada deve satisfazer [Stokes1994]: No ambigidade: todas as especificaes devem, idealmente, ter uma nica interpretao. Essa uma propriedade difcil de ser alcanada, at mesmo atravs da aplicao de mtodos formais; Completude: uma especificao de requisitos deve descrever cada aspecto significante e relevante do sistema e deve incluir detalhes a respeito de todas as informaes. A natureza subjetiva da definio de completude faz com que essa propriedade seja impossvel de ser garantida; Consistncia: no devem existir requisitos contraditrios na especificao; Verificabilidade: quando o sistema for projetado e implementado, dever ser possvel verificar se seu projeto e implementao satisfazem os requisitos originais; Validao: o usurio/cliente deve ser capaz de ler e entender a especificao de requisitos e, ento, indicar se os requisitos refletem as suas idias; Modificao: como os requisitos esto freqentemente sujeitos a mudanas, todas as especificaes de requisitos devem permitir que alteraes sejam feitas facilmente, sem a necessidade de que tais modificaes sejam realizadas em toda a especificao. Isso exige, geralmente, que alguma estruturao seja imposta na especificao;
57
Compreenso: clientes, usurios, analistas, projetistas e engenheiros devem ser capazes de entender os requisitos. Como eles possuem formaes diferentes, podem preferir utilizar distintas representaes para os requisitos; Rastreamento: devem ser feitas referncias entre os requisitos, aspectos de projeto e implementao. Dessa forma, efeitos das modificaes nos requisitos, projeto e implementao sero controlados. 5.1.2 Requisitos Funcionais e No-Funcionais Uma forma de melhorar a compreenso dos requisitos dividi-los em requisitos funcionais e no-funcionais. Embora as suas fronteiras nem sempre sejam precisas de se determinar, essa diviso tem sido bastante usada na literatura. Os Requisitos Funcionais definem as funes que o sistema ou componentes do sistema devem executar. Eles descrevem as transformaes do sistema ou de seus componentes que transformam entradas em sadas. Os Requisitos No-Funcionais, tambm referidos com requisitos de qualidades, incluem tanto limitaes no produto (performance, interface de usurios, confiabilidade, segurana, interoperabilidade), como limitaes no processo de desenvolvimento (custos e tempo, metodologias a serem adotadas no desenvolvimento, componentes a serem reutilizados, padres a serem aderidos etc.). 5.1.3 O Processo de Engenharia de Requisitos
Esta seo apresenta brevemente as atividades do processo da engenharia de requisitos, mostrando as relaes existentes entre elas. Para nossos propsitos, o processo ser dividido nas seguintes atividades: elicitao de requisitos, modelagem de requisitos, anlise de requisitos e validao de requisitos. As atividades de elicitao e validao de requisitos correspondem etapa de aquisio de requisitos, enquanto as atividades de modelagem e anlise de requisitos correspondem etapa de especificao de requisitos (vide Figura 5.3).
58
Figura 5.3: Processo de engenharia de requisitos Elicitao Na atividade de elicitao, o engenheiro de requisitos procura capturar os requisitos do sistema, buscando tambm obter um conhecimento do domnio do problema. Usualmente, so feitas entrevistas com o cliente e/ou consultado material existente descrevendo objetivos e desejos da organizao. Tambm se observam sistemas similares. importante observar que o uso apenas de entrevista no suficiente para obter todas as informaes necessrias. O engenheiro de requisitos precisa se envolver com o trabalho do cliente, se misturar com os funcionrios, observar, aprender e questionar. Um dos objetivos da etapa de elicitao deve ser o entendimento da razo pela qual os procedimentos atuais do cliente so feitos da forma que so. Trata-se, portanto, de uma atividade de aprendizagem: Do comportamento de sistemas existentes, incluindo: - Procedimentos manuais; - Engenharia reversa de softwares existentes; - Interfaces. Do conhecimento do domnio de aplicao, ou seja, da parte especfica do domnio que est relacionada com o sistema de software a ser implementado; Dos objetivos e limitaes dos usurios, incluindo: - Limitaes funcionais; - Limitaes organizacionais.
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
Quando uma especificao de requisitos executvel (um prottipo), o trabalho de validao bastante facilitado, pois os usurios podem experimentar com partes da especificao, dando imediatamente suas impresses sobre o sistema. Dessa forma, os prprios usurios contribuem para que o software seja adequado s suas necessidades, reduzindo custos e colaborando para que os prazos sejam cumpridos. 5.1.4 Modelos Conceituais e Linguagens para a Engenharia de Requisitos Idealmente, dever-se-ia usar linguagens que possussem uma nica interpretao com o mundo real, ou seja, que cada parte da linguagem (ex. palavra) tivesse um nico significado no mundo real. Se isso fosse sempre possvel, o engenheiro de requisitos seria capaz de fazer descries que fossem no ambguas e que pudessem ser corretamente entendidas por usurios/clientes e engenheiros/projetistas (vide Figura 5.4). Nessa seo, sero discutidas as principais abordagens de linguagens para representao de requisitos, isto , linguagens naturais, linguagens rigorosas e linguagens formais.
Figura 5.4: Linguagens para especificao de requisitos Linguagens Naturais Obviamente, a linguagem natural a que oferece maior grau de compreenso e acesso para o incio de uma descrio [Ford1994]. No nosso caso, o Portugus poderia ser adotado. O uso de linguagem natural bastante atrativo pois: Usa o conhecimento j existente da linguagem pelo engenheiro de requisitos; Permite que as idias sejam comunicadas de um modo que seja entendida pelo pblico em geral; Possui a vantagem de no fazer nenhuma tentativa de prescrever um mtodo para implementao.
61
Infelizmente, h muitos problemas com as linguagens naturais [Ryam1993]. Inicialmente, os textos tendem a ser desestruturados. As pessoas tendem a escrever de uma forma desorganizada. Somente aps muito treino que um escritor se habitua a estruturar suas descries e observaes. Tambm, na prtica, a linguagem natural torna-se ambgua, dando margem a interpretaes diferentes, dependendo dos diferentes tipos de pessoas e suas experincias. Torna-se invivel determinar se a especificao est completa. De fato, muito difcil usar linguagens naturais na especificao de requisitos sem deixar nenhuma ambigidade ou m interpretao para leitores com diferentes experincias. A origem do problema est no uso de palavras e estruturas que sejam interpretadas de formas diferentes pelo leitor. Uma determinada caracterstica do sistema em desenvolvimento pode ser to bvia que ningum ter a preocupao de escrev-la, pois a necessidade dela perfeitamente entendida por todos os membros da equipe. Como conseqncia, essa caracterstica pode nunca ser includa na especificao e, portanto, no ser implementada. Muitas vezes, feita uma superespecificao, abordando detalhes que na realidade so de projeto ou implementao. Especificaes em linguagem natural podem apresentar redundncias e contradies difceis de detectar. Na prtica, existem sugestes que a linguagem natural seja usada de uma forma estruturada, muitas vezes refraseando especificaes para uma linguagem baseada numa linguagem de programao de alto-nvel. Pelo menos na teoria, o uso dessas linguagens pode ser eficiente para remover ambigidades e ms interpretaes dos requisitos do sistema. A maior desvantagem dessa tcnica a dificuldade do engenheiro de requisitos de se expressar de forma independente do paradigma de implementao. Logo, h um risco maior da especificao ser escrita mais em termos de como ela ser implementada, do que em termos do que deve ser entregue. Linguagens Rigorosas Desde a dcada de 1970, tem sido desenvolvido um grande nmero de tcnicas, mtodos e ferramentas que ajudam na produo de requisitos. As descries dos requisitos passaram a ter uma sintaxe mais formal, muitas vezes usando grficos, acompanhados de informaes textuais. Apesar de parte da especificao ainda ser informal, as linguagens passaram a possuir uma limitada interpretao formal. Isso tem permitido encontrar contradies e incompletudes bsicas de uma forma mais sistemtica. A linguagem UML [Booch1998] um exemplo de uma notao que se enquadra nessa categoria. Nessa linguagem, os requisitos funcionais so expressos atravs de
62
diagramas de casos de uso, os quais possuem uma sintaxe precisa. No entanto, a especificao mais detalhada dos casos de uso e a especificao dos requisitos nofuncionais ainda continuam a serem feitas usando-se uma linguagem natural. Linguagens Formais As tcnicas de especificao formal so baseadas em notaes matemticas, que possuem regras de interpretao no-ambguas. Por intermdio de um sistema de inferncia, possvel deduzir (provar) propriedades do sistema. Muitas vezes, essas tcnicas so acompanhadas por uma metodologia que facilita tanto a especificao, como a verificao formal. As vantagens do uso de tcnicas formais so: clareza, no-ambigidade, independncia de implementao e completude da especificao. Os mtodos formais existentes no so muitos atrativos, exatamente pela necessidade de se ter uma certa base matemtica para se usufruir totalmente da tcnica, pois essa habilidade no encontrada na maioria dos usurios. Contudo, experincias recentes sugerem que, motivados a escrever um software de alta-qualidade (talvez por ser um software crtico), o desafio de usar um mtodo formal algo a ser considerado, mesmo para aqueles que no tm maiores inclinaes matemticas. Uma vantagem adicional a possibilidade de se obter especificaes que sejam executveis, permitindo que um prottipo do sistema seja produzido rapidamente. Existem limitaes nas linguagens formais, decorrentes do sistema matemtico usado. Muitas vezes, o formalismo escolhido pode no ser apropriado para modelar todas as propriedades do sistema. Por exemplo, as questes do tempo e de concorrncia exigem uma base matemtica apropriada. Dentre as linguagens de especificao formal, Z [Spivey1989] tem sido uma das mais usadas. 5.1.5 Consideraes
Durante a ltima dcada, as pesquisas tm se concentrado em como descrever os requisitos de grandes sistemas feitos sob encomenda. Atualmente, verifica-se a existncia de um mercado de distribuio para as massas. Estes softwares orientados para massa raramente usam especificao de requisitos, pelo menos do tipo tradicional. Eles se baseiam em pesquisas de mercado, grupos de interesse e feedback de usurios que fizeram testes em verses preliminares do software. Portanto, a engenharia de requisitos precisa se adequar a essa nova realidade. Entre os vrios problemas que precisam ser mais bem estudados, esto os desafios organizacionais e gerenciais. As equipes de gerenciamento, geralmente, no tm conscincia do papel estratgico da engenharia de requisitos [Lubars1993]. O envolvimento e o comprometimento da gerncia na E.R. so, freqentemente, muito
63
baixos. Isso implica que os trabalhos de E.R. normalmente no esto relacionados com as vises de negcios e objetivos, processos de reengenharia de negcios e outras mudanas organizacionais. As organizaes tendem a no aprender com as experincias anteriores de E.R. As especificaes de requisitos no so usadas como fonte de conhecimento para futuros projetos de engenharia de requisitos. Existe uma tendncia das empresas, que antes desenvolviam software, de terceirizar sua produo. Como conseqncia, ser necessrio que os usurios de software melhorem suas prticas de engenharia de requisitos. Eles tero de ser mais exigentes para conseguir o que querem. No desenvolvimento tradicional de requisitos, o desenvolvedor de software o provvel executor de muitas das atividades de engenharia de requisitos descritas anteriormente. Contudo, com a terceirizao, os prprios clientes/usurios devero ser especialistas em requisitos. Finalmente, necessrio elaborar novas formas de participao de usurios na engenharia de requisitos, pois ainda existem problemas de comunicao entre desenvolvedores e clientes, ocasionando um baixo nvel de validao dos requisitos. Os usurios acreditam que os desenvolvedores conhecem seus requisitos tcitos e que validam as especificaes de requisitos sem entenderem completamente suas implicaes. 5.2 PROJETO DE SOFTWARE Nesta etapa, os requisitos do sistema so particionados em nvel de subsistemas de hardware ou software, a fim de que a estrutura interna (arquitetura) seja descrita. Na prtica, existe um forte relacionamento entre a etapa de projeto e a especificao do sistema, pois o projetista interage entre o projeto e a especificao, de modo que, ao final desse processo, cada uma das partes componentes do sistema (sub-sistemas) tenham sido especificadas. Por esse motivo, a especificao do software , muitas vezes, vista como a primeira etapa do projeto do sistema. Na etapa de projeto, mais e mais detalhes so adicionados especificao do sistema, de modo a definir os algoritmos e as estruturas de dados concretos a serem usados. Assim, pode-se dizer que a etapa de definio e anlise de requisitos determina o que o sistema deve fazer e a etapa de projeto determina como a funcionalidade do sistema deve ser implementada. Os dois principais enfoques para o projeto de sistemas so: o top-down e o bottom-up. No enfoque top-down, um sistema recursivamente decomposto em subsistemas (geralmente chamados de mdulos) at que sub-sistemas tratveis (facilmente implementveis) sejam identificados. A estrutura geral que resulta desse processo de decomposio uma hierarquia em forma de rvore, na qual o sistema a raiz da rvore e os sub-sistemas so seus ns. Essa hierarquia pode se degenerar
64
em um grafo, medida que as possibilidades de reuso dos sub-sistemas so identificadas. Esse enfoque mais utilizado para o desenvolvimento de sistemas seguindo o paradigma imperativo, no qual o estado de um sistema centralizado e compartilhado entre as funes que operam sobre este estado. Nesse caso, as folhas da rvore correspondem s funes a serem implementadas. No enfoque bottom-up, o sistema visto como uma coleo de buildingblocks. Este enfoque mais utilizado para o desenvolvimento de sistemas seguindo o paradigma orientado a objetos, no qual o estado de um sistema descentralizado entre os objetos que compem o sistema, ou seja, cada objeto manipula seu prprio estado. Objetos so membros de classes e tm um conjunto de atributos, os quais definem seus estados e operaes que agem sobre os atributos. Ou seja, classes definem atributos e operaes relacionados a objetos membros. Cada classe pode herdar o comportamento (atributos e operaes) de superclasses e, dessa forma, possvel definir subclasses. Assim como na etapa de especificao e anlise de requisitos, mtodos estruturados tambm so usados na etapa de projeto. Nesse caso, esses mtodos possibilitam a descrio da arquitetura dos sistemas atravs de diagramas. Um mtodo estruturado composto por uma notao diagramtica e um conjunto de diretrizes de como utilizar a notao. Atualmente, a notao UML [Booch1998] tem sido bastante utilizada na etapa de projeto. No entanto, esta notao no corresponde realmente a um mtodo, pois pode ser usada segundo vrias diretrizes existentes (ou metodologias), tais como RUP [Kruchten1998] e Catalysis [DSouza2001]. A seguir descreveremos parte desta metodologia. 5.3 IMPLEMENTAO Durante essa etapa, o projeto do software implementado como um conjunto de unidades de uma linguagem de programao (ex: programas ou classes). Essa etapa baseia-se totalmente na disponibilidade de ferramentas e/ou ambientes de apoio programao (ex: compiladores, depuradores de cdigo e editores sintticos). O paradigma da linguagem de programao utilizada nessa etapa est diretamente relacionado ao paradigma utilizado no projeto do sistema. Assim, ao se fazer um projeto orientado a objetos, por exemplo, recomendado implement-lo em uma linguagem que siga o mesmo paradigma. Independentemente do paradigma utilizado na implementao do software, a qualidade do cdigo produzido pode ser julgada com base em alguns atributos: Qualidade de sua documentao; Uso de um padro de codificao;
65
Legibilidade; Nvel de complexidade; Tamanho; Tempo de execuo.
A utilizao de padres de documentao ajuda na obteno da qualidade do cdigo. Esses padres vo desde a definio do ambiente de programao at de comentrios no prprio cdigo. Veja o exemplo de padro de codificao JAVA no Anexo A. H vrios outros atributos para tal julgamento. Alguns desses atributos podem ser avaliados atravs de atividades de reviso e inspeo, descritas no segundo mdulo deste curso, outros podem ser avaliados atravs da etapa de testes, tratada na prxima seo. 5.4 TESTES DE SOFTWARE Existe grande possibilidade de injeo de falhas no processo de desenvolvimento de software. Assim, os custos associados s falhas de software justificam uma atividade de teste cuidadosa e bem planejada, como parte dos esforos, no sentido de garantir a qualidade do software. 5.4.1 Introduo Os testes representam a ltima oportunidade de detectar erros antes de o software ser entregue aos usurios. A atividade de testes pode ser feita de forma manual e/ou automtica e tem por objetivos: Produzir casos de teste que tenham elevadas probabilidades de revelar um erro ainda no descoberto, com uma quantidade mnima de tempo e esforo; Comparar o resultado dos testes com os resultados esperados, a fim de produzir uma indicao da qualidade e da confiabilidade do software. Quando h diferenas, inicia-se um processo de depurao para descobrir a causa. A realizao de testes no consegue mostrar ou provar que um software ou programa est correto. O mximo que os testes de um software conseguem provar que ele contm defeitos ou erros. Quando os testes realizados com um determinado software no encontram erros, haver sempre duas possibilidades: A qualidade do software aceitvel; Os testes foram inadequados.
66
5.4.2 Estgios de Teste Existem diferentes estgios de teste associados ao desenvolvimento de um produto de software: Teste de unidade: visa testar individualmente cada um dos componentes (programas ou mdulos), procurando garantir que funcionem adequadamente; Teste de integrao: visa testar o relacionamento entre as diversas unidades integradas. Em outras palavras, garantir que a interface entre os mdulos funcione adequadamente, pois no h garantias de que unidades testadas em separado funcionaro em conjunto; Teste de sistema: conjunto de testes cujo objetivo primordial colocar completamente prova todo o sistema, baseado em um computador. Em outras palavras, testa a integrao do software com o ambiente operacional - hardware, pessoas e dados reais; Teste de aceitao (homologao): so testes realizados pelo cliente/usurio com o objetivo de validar o sistema a ser implantado. A motivao maior para esses testes o fato do desenvolvedor nunca conseguir prever como o usurio realmente usar um software numa situao real. Os testes de aceitao podem ser de dois tipos: - Testes alfa: so feitos por um determinado cliente, geralmente nas instalaes do desenvolvedor, que observa e registra os erros e/ou problemas; - Testes beta: so realizados por possveis clientes, em suas prprias instalaes, sem a superviso do desenvolvedor. Cada cliente relata os problemas encontrados ao desenvolvedor, posteriormente. 5.4.3 Abordagens de Teste Existem basicamente duas abordagens que podem ser aplicadas aos diferentes tipos de teste: Abordagem funcional (caixa-preta): concentra-se nas interfaces do software e visa mostrar que: as entradas so aceitas; as sadas so as esperadas; a integridade dos dados mantida. Aplica-se, principalmente, aos testes de validao, sistemas e aceitao, mas pode ser tambm usada com os testes unitrios; Abordagem estrutural (caixa-branca): visa mostrar que os componentes internos do software (programas) realmente funcionam. Em princpio, os testes de caixa branca pretendem garantir que todas as estruturas dos programas e todos os possveis casos sejam testados. Aplica-se, principalmente, aos testes
67
unitrios e de integrao. Na prtica, mesmo para pequenos programas, geralmente impossvel testar todas as possibilidades. 5.4.4 Tipos de Teste Existem vrios tipos de teste que podem ser executados nos diversos estgios de teste e utilizando as diferentes abordagens existentes:
Teste de funcionalidade: testa a funcionalidade geral do sistema, em termos de regras de negcio (fluxo de trabalho), considerando-se tanto as condies vlidas como as invlidas; Teste de recuperao de falhas: seu objetivo forar o software a falhar de diversas maneiras e verificar se a recuperao adequada; Teste de segurana de acesso: tenta certificar-se de que todos os mecanismos de proteo embutidos no software, de fato, o protegero dos acessos indevidos; Teste de carga: tenta confrontar o software ou os programas com situaes anormais. Ele executa o software de uma forma que exige recursos em quantidade, freqncia e volume bem maiores do que o uso normal; Teste de desempenho: so testes que visam verificar o desempenho ou performance do software. So, muitas vezes, combinados ou feitos juntamente com os testes de estresse. So comuns em software de tempo real; Teste de portabilidade: so testes que verificam o grau de portabilidade do produto de software em diferentes ambientes de hardware/software.
A execuo de todos esses tipos de testes pode ser feita de forma combinada. Ou seja, nenhum desses testes exclui o outro. 5.4.5 Responsabilidade pelos testes Os testes, normalmente, so feitos pela equipe de desenvolvimento, i.e., por engenheiros de software. No entanto, ideal que pelo menos os testes de sistemas sejam feitos por uma equipe de testes independente. importante que os grandes sistemas e programas tambm sejam testados por outras pessoas que no os seus desenvolvedores, e que tais pessoas sejam bastantes crticas. Assim, seria possvel a seguinte distribuio de responsabilidades: Equipe de desenvolvimento: Testes de unidades; Testes de integrao.
68
Equipe independente de testes: Testes de sistema.
Usurio: Teste de aceitao. 5.4.6 Ferramentas de Teste O processo de testes pode ser automatizado, atravs do uso de ferramentas CASE especficas para essa atividade. Alguns tipos de ferramentas de apoio aos testes so descritos a seguir: Ferramenta de gerao de massa de dados: gera dados para serem usados em testes. A gerao dos dados freqentemente baseada em regras de formao definidas pelos casos de teste; Ferramenta de teste de API: testa mtodo a mtodo de uma classe, a partir de uma srie de combinaes de parmetros. Utiliza a abordagem caixa-preta para cada mtodo; Ferramenta de teste de GUI: grava (em um script) a execuo da interface grfica (cliques do mouse e entradas de teclado) e repete a entrada quantas vezes forem necessrias. O script gerado pode ser modificado atravs do uso de uma linguagem prpria de script; Ferramenta de teste de cobertura: aps a execuo da aplicao, indica quais os trechos do cdigo foram ou no executados, bem como o nmero de vezes que determinado mtodo/trecho foi executado. Utiliza a abordagem caixabranca; Ferramenta de teste de carga e stress: simula acessos simultneos a uma aplicao multi-usurio, bem como o envio e recuperao de altos volumes de dados; Ferramenta de teste de desempenho/gargalos: analisa o desempenho do software, quando em execuo, e detecta potenciais pontos de gargalo no cdigo fonte. 5.5 GERNCIA DE CONFIGURAO O desenvolvimento de software uma atividade que precisa ser executada em equipe, principalmente para os softwares de grande porte. Freqentemente, artefatos (ex: documentos, programas etc.) precisam ser acessados e alterados por vrias pessoas da equipe e, nesse caso, a modularizao do projeto normalmente no suficiente para resolver esse problema.
69
A Gerncia de Configurao controla as mudanas e mantm a integridade dos artefatos de um projeto. As principais atividades envolvidas com essa etapa do ciclo de vida so: Identificao de itens de configurao (componentes individuais do software ex: arquivos com programas fonte); Restrio s modificaes nesses itens (controle de acesso); Criao de verses dos itens modificados;
Auditoria nos itens de configurao (para determinar por que, quando e por quem um artefato foi modificado); Retorno a uma verso anterior de um artefato.
Estas atividades, geralmente, so apoiadas por ferramentas de controle de verses e mudanas. Essas ferramentas permitem tornar o processo de desenvolvimento mais produtivo, uma vez que a gerncia de configurao aplicada a todos os artefatos produzidos em todas as etapas do ciclo de vida. Para garantir que todas as atividades desta etapa sejam executadas de maneira satisfatria, recomendase que seja produzido um Plano de Gerncia de Configurao, o qual ir determinar quando, por quem e com que ferramentas as atividades dessa etapa sero executadas. 5.6 OPERAO E MANUTENO DE SOFTWARE Nessa etapa, o sistema posto em uso (operao). Erros e omisses nos requisitos originais, nos programas e no projeto so descobertos. A necessidade de novas funcionalidades e melhorias identificada. Conseqentemente, modificaes sero necessrias para que o software continue sendo usado. Essas modificaes so chamadas: manuteno do software. A Manuteno pode envolver mudanas nos requisitos, no projeto e/ou na implementao. Conseqentemente, podem ser necessrios novos testes. Assim sendo, todo o processo de desenvolvimento (ou parte dele) pode ser repetido quando so feitas modificaes. As manutenes podem ser classificadas em: Corretivas; Adaptativas; Perfectivas; Preventivas.
70
A manuteno dita corretiva quando feita para corrigir os erros no identificados durante o desenvolvimento e testes do sistema. Esse tipo de manuteno existe porque os testes de software dificilmente conseguem detectar todos os erros. A manuteno dita adaptativa quando alteraes se tornam necessrias por conta de mudanas no ambiente computacional. Essas manutenes so necessrias porque a vida til dos aplicativos longa e no acompanha a rpida evoluo da computao. A manuteno dita perfectiva quando alteraes visam melhorar o software de alguma forma. Geralmente, o resultado de recomendaes de novas capacidades, bem como modificaes em funes existentes solicitadas pelos usurios. A manuteno dita preventiva quando modificaes so feitas com o objetivo de melhorar o software no que se refere sua confiabilidade ou manutenibilidade, ou para oferecer uma base melhor para futuras ampliaes. Independentemente do tipo de manuteno, existe a certeza de que essa atividade ir ocorrer no desenvolvimento de um software. Sendo assim, o processo de software utilizado por uma organizao, bem como as pessoas envolvidas nessa atividade devem estar preparadas para desempenh-la da forma mais produtiva possvel, de maneira a atender rapidamente s necessidades dos clientes. 5.7 FERRAMENTAS CASE Como qualquer outra engenharia, a Engenharia de Software envolve trabalho criativo e tambm uma grande quantidade de trabalho tedioso de administrao e de controle. A execuo das atividades no criativas pode, na maioria das vezes, ser automatizada atravs do uso de ferramentas CASE. O suporte automatizado ao processo de desenvolvimento de software uma arma fundamental para aumentar a produtividade na execuo das atividades e garantir a qualidade de um produto de software. Uma ferramenta CASE oferece um conjunto de servios fortemente relacionados para apoiar uma ou mais atividades do processo de software. Esses servios vo, desde a simples edio de textos, at o gerenciamento de configuraes, o teste de software e a verificao formal de programas. As ferramentas CASE so, geralmente, projetadas para funcionar individualmente, com objetivo especfico. Por exemplo, apoiar um mtodo de anlise orientada a objetos ou a programao em uma linguagem especfica. Essas ferramentas, usualmente, possuem repositrios de dados mais sofisticados que simples arquivos, podendo incluir dicionrios de dados ou at mesmo utilizar um gerenciador de banco de dados comercial para armazenar seus dados. No entanto,
71
existem conjuntos de ferramentas que trabalham integradas e que so, geralmente, conhecidos como Tool suites ou Ambientes CASE. Esses ambientes podem ser de propsito especfico (ex: conjunto de ferramentas que do apoio a uma nica etapa do ciclo de vida de software) ou de propsito genrico (ex: conjunto de ferramentas que do apoio a diversas atividades do ciclo de vida). Vale salientar que, para se extrair todos os benefcios do uso de ferramentas CASE, necessrio que as ferramentas selecionadas se adeqem ao processo de desenvolvimento de software da organizao. Assim, primordial que tal processo esteja bem definido e institucionalizado, para que as ferramentas adequadas sejam selecionadas.
72
6
QUALIDADE DE SOFTWARE
Em tempos de competitividade acirrada, a conscincia da necessidade de processos de produo mais eficientes, que garantam o equilbrio perfeito entre qualidade e produtividade, vem crescendo substancialmente. Nesse contexto, o fator qualidade tem sido considerado fundamental para o sucesso de qualquer organizao. O termo qualidade no contexto organizacional , em geral, relacionado a uma srie de aspectos, tais como normalizao e melhoria de processo, medies, padres e verificaes, entre outros. Esses aspectos vm sendo abordados ao longo dos ltimos 50 anos por vrios estudiosos no assunto, considerados verdadeiros mestres, cujas propostas marcaram um caminho evolutivo que fundamenta, at hoje, diversos modelos de qualidade internacionais. Inserido nesse contexto, esse captulo compreende conceitos bsicos e uma viso da evoluo da qualidade e produtividade, essenciais para a obteno de conhecimento abrangente no assunto. 6.1 CONCEITUAO Apesar da ateno substancial que se tem dado ao assunto, muitas organizaes tm dificuldade de definir o termo qualidade, to cobiado no mercado competitivo. Dessa forma, antes de tudo, preciso entender o que significa qualidade no contexto do setor produtivo. Vrios significados tm sido dados no sentido de prover um entendimento adequado do termo qualidade no contexto da produtividade. Atendimento s expectativas do cliente, conformidade com a especificao, conhecimento do processo para melhor-lo, efetividade e usabilidade. Esses aspectos poderiam ser consolidados na definio dada pela International Organization for Standardization (ISO), segundo a qual qualidade a totalidade das caractersticas de uma entidade que lhe confere a capacidade de satisfazer s necessidades explcitas e implcitas (NBR ISO 8402). Necessidades explcitas so as condies e objetivos propostos por aqueles que
74
produzem o software. As necessidades implcitas so necessidades subjetivas dos usurios, tambm chamadas de fatores externos, e podem ser percebidas tanto pelos desenvolvedores quanto pelos usurios. Em outras palavras, a definio da ISO confirma a relao entre o grau de qualidade e a satisfao do cliente, em termos de expectativas atendidas. 6.2 EVOLUO DOS CONCEITOS DE QUALIDADE Os avanos tecnolgicos e a crescente preocupao na eliminao de defeitos, aumento na produtividade e reduo de custos motivaram o surgimento de modelos de qualidade para o processo de manufatura. A partir da dcada de 1960, comearam a surgir critrios, modelos e tcnicas para a garantia da qualidade no processo de produo. A indstria japonesa foi a precursora do Controle da Qualidade Total (Total Quality Control - TQC), seguida pelos americanos, que definiram o modelo de Gerncia da Qualidade Total (Total Quality Management), ambos bastante utilizados em todo o mundo. Em 1947, a criao da Organizao Internacional de Padronizao (ISO) formalizou a necessidade da definio de padres internacionais no setor da indstria e muito contribuiu para a evoluo do setor, definindo normas para a garantia da qualidade direcionadas para produo, servios e gerenciamento, entre outros contextos. Como exemplo de padro internacional de qualidade temos a norma ISO9001:2000 [ISO9001:2000] que define requisitos para gerncia de sistemas da qualidade, abrangendo todo o ciclo de desenvolvimento de um produto, desde seu pedido, passando pela anlise e gerenciamento de requisitos, projeto e fabricao, at sua entrega ao cliente, incluindo infra-estrutura adequada, competncias e comprometimento da alta administrao. Observando contribuies ao longo dos ltimos anos, algumas iniciativas podem ser consideradas verdadeiros marcos na histria evolutiva da qualidade, alm da criao da ISO. O incio dessa evoluo est situado no incio do sculo XX, quando foi criada a Comisso Internacional Eletrotcnica (IEC) em 1906. Abordagens como a introduo da noo de gesto da qualidade por Feigenbaum, em 1957, e do aperfeioamento e novas abordagens por Deming, Juran e Crosby, seguidos da proposta do Total Quality Management, por Tom Peters, foram fundamentais e so at hoje consideradas nas propostas atuais sobre o assunto. A seguir so apresentadas as diferentes abordagens defendidas ao longo da evoluo da rea da qualidade e produtividade.
Qualidade de Software
75
6.2.1 Abordagem de W. Edwards Deming W. Edwards Deming reconhecido como o grande mestre do controle da qualidade. Sua abordagem defende que a qualidade inicia com o alto nvel gerencial e uma atividade estratgica. A proposta de Deming enfatizou a necessidade dos mtodos estatsticos, participao, educao e proposta de melhoria. Segundo Deming, fundamental que as especificaes sejam sempre revistas, uma vez que os desejos do cliente tm um alto grau de instabilidade. Deming defendeu 14 pontos fundamentais, que podem ser considerados recomendaes para o sucesso de um programa de qualidade em uma organizao, os quais podem ser resumidos nas seguintes recomendaes: 1. Estabelea um propsito constante direcionado melhoria de produtos e servios; 2. Adote uma nova filosofia. O gerenciamento moderno deve estar atento aos desafios, aprender suas responsabilidades e liderar as mudanas; 3. Elimine a necessidade de inspeo em massa, produzindo produtos de qualidade; 4. Elimine a prtica de fazer negcios com base apenas nos preos. Ao invs, minimize os custos. Estabelea um relacionamento duradouro com os seus fornecedores; 5. Melhore constantemente o sistema de produo e de servios para melhorar a relao qualidade x produtividade e, assim, diminuir custos e aumentar lucros; 6. Institucionalize novos mtodos de treinamento no trabalho; 7. Institucionalize e fortalea os papis de liderana; 8. Elimine os medos, de modo que cada funcionrio possa trabalhar efetivamente pela companhia; 9. Quebre barreiras entre departamentos. Todos devem trabalhar como uma equipe coesa; 10. Elimine slogans, exortaes e metas para a fora de trabalho produzir com defeito-zero e novos nveis de produtividade, pois isto pode levar a um desgaste no relacionamento entre as pessoas causando baixa qualidade e produtividade; 11. Elimine cotas-padro arbitrrias e gerenciamento por objetivos; 12. Produza e gerencie com foco na qualidade e no apenas em atingir nmeros; 13. Institucionalize um vigoroso programa de educao e auto-melhoria; 14. Coloque todos na organizao para trabalhar pela transformao.
76
6.2.2 Abordagem de Armand Feigenbaum Armand V. Feigenbaum era estudante de doutorado no Massachusetts Institute of Technology nos anos 1950, quando introduziu o conceito de controle da qualidade total e concluiu a primeira edio do seu livro Total Quality Control (TQC). Segundo Feingenbaum, o Controle da Qualidade Total representa um sistema efetivo que integra a qualidade do desenvolvimento, qualidade de manuteno e esforos de melhoria da qualidade de vrios grupos em uma organizao. Pode-se consolidar o enfoque da abordagem de Feigenbaum nos seguintes aspectos: Liderana para a qualidade significa que a qualidade deve ser gerenciada e submetida manuteno constante, a fim de se obter a excelncia; Tecnologia moderna para qualidade nessa viso, todos na organizao so responsveis pela qualidade de seus processos, produtos e servios, o que impe a integrao de colaboradores em diferentes nveis organizacionais; Compromisso organizacional a qualidade deve ser vista como um fator estratgico pela organizao, que deve ser responsvel por treinar sua equipe nas atividades especficas de cada um. 6.2.3 Abordagem de Joseph M. Juran Joseph M. Juran foi um educador chave em gerncia da qualidade para os japoneses, que difundiram sua teoria. Ele focou sua abordagem nas atividades gerenciais e na responsabilidade para a qualidade, se preocupando no impacto de trabalhadores individuais e no envolvimento e motivao da fora de trabalho nas atividades de melhoria. Ele fundamentou sua abordagem sobre gerncia de qualidade em trs processos bsicos:
Planejamento da Qualidade o planejamento deve ser iniciado com a determinao das necessidades do cliente, seguido da definio de requisitos bsicos para que o produto ou servio atenda s expectativas do cliente. Processos para desenvolvimento desses requisitos devem ser definidos; Controle da Qualidade uma vez estabelecidos direcionamentos e processos para desenvolvimento dos produtos e servios, o controle da qualidade deve garantir o grau de qualidade e produtividade previamente estabelecido; Melhoria da Qualidade as atividades de melhoria da qualidade abrangem a identificao de oportunidades de melhoria, assim como o estabelecimento de responsabilidades para execuo dessas melhorias e divulgao de resultados.
77
6.2.4 Abordagem de Philip Crosby Philip B.Crosby iniciou seus estudos na dcada de 1960 e defendeu que a qualidade pode ser vista como o grau de conformidade com a especificao, fundamentada em uma abordagem de busca contnua do defeito zero [PMBOK2000]. Sua abordagem inclui o que ele denominou de 4 certezas do Gerenciamento da Qualidade: Qualidade significa atendimento aos requisitos; Qualidade vem atravs de preveno; Padro para desempenho da qualidade e defeitos zero; A medida de qualidade o preo da no-conformidade.
Em seu livro Quality is Free [Crosby1979], Crosby define um modelo de maturidade organizacional com 5 estgios baseados no gerenciamento da qualidade. Essa abordagem inspirou o Capability Maturity Model for Software (CMM) [Paulk1995], modelo de maturidade criado pelo Software Engineering Institute. Os 5 estgios so apresentados a seguir. 1. Desconhecimento: Ns no sabemos que temos problemas com qualidade. Nesse nvel, no h compreenso sobre qualidade como uma ferramenta de gesto. Problemas so tratados medida que surgem. Inspees no so realizadas; 2. Despertar: absolutamente necessrio ter problemas com qualidade? Reconhecimento de que gerenciamento da qualidade pode agregar valor, mas no gerando um crescimento do lucro da organizao; 3. Alinhamento: Atravs de compromisso gerencial e melhoria da qualidade ns identificamos e resolvemos nossos problemas. Gerenciamento da qualidade se torna uma ferramenta de suporte e ajuda aos processos. Comunicaes de aes corretivas so estabelecidas e problemas so priorizados e solucionados seguindo uma ordem; 4. Sabedoria: Preveno de defeito uma parte da rotina de nossa operao. Entendimento absoluto do gerenciamento da qualidade. Reportagem efetiva de status e aes preventivas. Problemas so identificados antes do seu desenvolvimento. Todas as funes esto abertas para sugestes e melhoria nos processos; 5. Certeza: Ns sabemos por que no temos problemas com qualidade. A funo qualidade considerada uma parte essencial do sistema organizacional. Exceto em casos no comuns, problemas so prevenidos.
78
Segundo o modelo de maturidade de Crosby, uma organizao no nvel 1 no tem estimativas sobre o custo da qualidade, que representa 20% em termos do servio vendido. medida que o nvel de maturidade se eleva, o custo da qualidade tende a diminuir. Em outras palavras, uma organizao nvel 5 apresenta um custo da qualidade estimado praticamente igual ao real, que gira em torno de 2,5% [Crosby1979]. 6.2.5 Total Quality Control (TQC) Total Quality Control, ou TQC, um sistema desenvolvido no Japo, montado pelo Grupo de Pesquisa do Controle da Qualidade da Union of Japanese Scientists and Engineers (JUSE), para implementar a melhoria contnua da qualidade. H mais de 40 anos, o TQC vem sendo aperfeioado por estudiosos na rea de qualidade. Conforme praticado no Japo, o TQC se baseia na participao de todos os setores da empresa e de todos os empregados no estudo e conduo do controle da qualidade. O TQC baseado em elementos provenientes de vrias fontes (vide Figura 6.1): emprega o mtodo cartesiano, utiliza o controle estatstico de processos, adota conceitos sobre o comportamento humano. Adicionalmente, aproveita o todo o conhecimento ocidental sobre qualidade, principalmente o trabalho de Juran. O TQC regido pelos seguintes princpios bsicos [Feingenbaum1994]: Produzir e fornecer produtos e/ou servios que atendam concretamente s necessidades do cliente; Garantir a sobrevivncia da empresa atravs do lucro contnuo, adquirido pelo domnio da qualidade; Identificar o problema mais crtico e solucion-lo pela mais alta prioridade; Falar, raciocinar e decidir com dados e com base em fatos; Gerenciar a organizao ao longo do processo e no por resultados;
Reduzir metodicamente as distores atravs do isolamento de suas causas fundamentais; No permitir a venda de produtos defeituosos; No repetir erros;
Definir e garantir a execuo da viso e estratgia da alta direo da empresa.
79
Figura 6.1: Bases do TQC Uma das principais formas de implementao do controle de processos e adotada pelo TQC a utilizao do Ciclo PDCA (Plan-Do-Check-Action), que consiste em 4 fases: planejar, executar, verificar e atuar corretamente (vide Figura 6.2).
Figura 6.2: Ciclo PDCA para melhorias Na fase Plan, o foco est na identificao do problema, anlise do processo atual e definio do plano de ao para melhoria do processo em questo. Na fase Do, o plano de ao definido deve ser executado e controlado. Em Check, verificaes devem ser realizadas, a fim de subsidiar ajustes e se tirar lies de aprendizagem. Finalmente, em Action, deve-se atuar corretivamente para fundamentar um novo ciclo, garantindo a melhoria contnua.
80
O PDCA considerado um ciclo clssico, adotado, at hoje, por organizaes no mundo inteiro. Ele deve ser utilizado para todos os processos da organizao, em todos os nveis hierrquicos. Ele pode ser utilizado como base para qualquer organizao, na definio de uma metodologia de controle ou melhoria de qualquer tipo de processo. 6.2.6 Total Quality Management (TQM) Total Quality Management (TQM) uma abordagem para sucesso em longo prazo, que medida atravs da satisfao do cliente e baseada na participao de todos os membros da organizao. TQM foca a melhoria de processos, produtos, servios e cultura organizacional e considera qualidade de um processo como responsabilidade do dono do processo. Nesse contexto, Kan [Kan1995] descreve os seguintes elementos-chave do TQM, conforme demonstrado graficamente na Figura 6.3: Foco no cliente consiste em analisar os desejos e necessidades, bem como definir os requisitos do cliente, alm de medir e gerenciar a satisfao do cliente; Melhoria de processo o objetivo reduzir a variao do processo e atingir a melhoria contnua do processo. Processos incluem tanto processos de negcio quanto processo de desenvolvimento de produtos; Aspecto humano nesse contexto, as reas-chave incluem liderana, gerncia, compromisso, participao total e outros fatores sociais, psicolgicos e humanos; Medio e anlise o objetivo gerenciar a melhoria contnua em todos os parmetros de qualidade por um sistema de medio orientado a metas.
Figura 6.3: Elementos-chave do TQM
81
6.3 INTRODUO QUALIDADE DE SOFTWARE No sentido de se tornarem mais competitivas, as organizaes de software vm investindo cada vez mais na qualidade de seus produtos e servios de software. A qualidade de software est diretamente relacionada a um gerenciamento rigoroso de requisitos, uma gerncia efetiva de projetos e em um processo de desenvolvimento bem definido, gerenciado e em melhoria contnua. Atividades de verificao e uso de mtricas para controle de projetos e processo tambm esto inseridas nesse contexto, contribuindo para tomadas de deciso e para antecipao de problemas. Inserido nesse contexto, esta seo prov uma viso geral da rea de qualidade de software, abrangendo atividades e processos fundamentais para garantia da qualidade e produtividade em organizaes de software. 6.3.1 Preveno X Deteco Toda organizao possui processos formais e/ou informais que so implementados para produzir seus produtos de desenvolvimento de software (vide Figura 6.4). Esses produtos podem incluir tanto produtos finais, que so usados pelos clientes (como cdigo executvel, manuais de usurio), como artefatos intermedirios (como documento de requisitos, diagramas de projeto, casos de teste etc.).
Figura 6.4: Desenvolvimento de Produtos de Software Vrias tcnicas so utilizadas para identificar defeitos nos produtos de trabalho. Esses defeitos so eliminados atravs de re-trabalho, que tm efeito imediato na produtividade do projeto. Defeitos tambm so encontrados em atividades de teste e podem ser analisados, a fim de se identificar suas causas. A partir dessa anlise, lies aprendidas podem ser usadas para criar futuros produtos e prevenir futuros defeitos e, dessa forma, ter impacto positivo na qualidade do produto e na produtividade do projeto.
82
Algumas tcnicas de preveno e de deteco so listadas a seguir: Tcnicas de Preveno Treinamento; Planejamento; Modelagem; Atuao do grupo de garantia da qualidade (SQA); Uso de lies aprendidas; Melhoria de processo.
Tcnicas de Deteco Compilao/Anlise de cdigo; Peer Reviews (reviso por pares); Teste e simulao; Auditorias; Verificaes e validaes. 6.3.2 Planejamento e Gerncia da Qualidade de Software O planejamento e o gerenciamento da qualidade tm representado um papel cada dia mais forte no contexto do desenvolvimento de software. Desde o incio de um projeto, a qualidade deve ser vista como um fator crtico para o sucesso do software e deve ser considerada no planejamento e gerenciamento do mesmo. Essa seo apresenta uma viso geral dos processos de Planejamento da Qualidade de Software e Gerenciamento da Qualidade de Software. Planejamento da Qualidade de Software O processo de planejamento da qualidade de um projeto (vide Figura 6.5) compreende a identificao de quais padres so relevantes para o projeto e a determinao de como os satisfazer [PMBOK2000]. Esse processo deve ser executado em paralelo ao planejamento do projeto como um todo, uma vez que as atividades de qualidade planejadas influenciam na estimativa de esforo e no custo do projeto como todo.
83
Figura 6.5: Viso geral do planejamento da qualidade No contexto do desenvolvimento de software, o planejamento da qualidade deve incluir a documentao das atividades de preveno e deteco de defeitos, tais como auditorias, inspees, teste, coleta de mtricas, alm do uso de padres e descrio do processo de software adotado. As atividades de planejamento da qualidade so subsidiadas por informaes fundamentais, tais como: Poltica da Qualidade compreende intenes e diretrizes de uma organizao, no contexto da qualidade, formalmente expressadas pela alta gerncia; Estabelecimento do Escopo o conhecimento do escopo do projeto a entrada-chave para o planejamento da qualidade, desde os produtos a serem entregues, assim como os objetivos do projeto; Procedimentos, Padres e Regulamentos padres e regulamentos relacionados com o contexto do projeto que so aplicveis devem ser considerados no planejamento do projeto. Isso inclui processos, modelos e tcnicas definidas no mbito organizacional, alm de padres regulamentares fora do escopo da organizao; Descrio do Produto o entendimento das caractersticas do software a ser gerado fundamental para que se tenha uma viso clara dos processos adequados ao projeto. Com base nessas caractersticas, mtodos, modelos e processos devem ser selecionados e adaptados para o projeto especfico. O plano da qualidade o produto principal do processo de planejamento da qualidade de software. Compreende informaes sobre como a equipe de qualidade ir garantir o cumprimento da poltica de qualidade, no contexto do programa ou projeto a ser desenvolvido, podendo ser detalhado ou geral, dependendo das caractersticas do projeto. O plano da qualidade pode ser um documento especfico ou parte do plano do projeto e deve ser utilizado como base do gerenciamento ao longo de todo o ciclo de vida do projeto.
84
O IEEE [IEEE1999a] define um modelo bsico para plano da qualidade de um projeto de software, que inclui entre outras, as seguintes informaes: Propsito; Documentos de referncia; Organograma; Atividades; Responsabilidades; Requisitos de documentao; Padres e convenes; Mtricas; Revises e auditorias; Teste; Reporte de problemas e aes corretivas; Ferramentas, mtodos e metodologias; Controle de fornecimento; Coleta, manuteno e reteno de registros; Treinamento; Gerenciamento de riscos.
Garantia da Qualidade de Software Garantia da qualidade (vide Figura 6.6) um conjunto de atividades planejadas e sistemticas, implementadas com base no sistema da qualidade da organizao, a fim de prover a confiana de que o projeto ir satisfazer padres relevantes de qualidade [PMBOK2000]. As atividades de garantia da qualidade de software so focadas na preveno de defeitos e problemas, que podem surgir nos produtos de trabalho. Definio de padres, metodologias, tcnicas e ferramentas de apoio ao desenvolvimento fazem parte desse contexto.
Figura 6.6: Viso geral da garantia da qualidade
85
As atividades de garantia da qualidade so apoiadas pelas seguintes informaes que representam as entradas do processo: Plano da Qualidade de Software o plano da qualidade a ferramenta bsica que direciona todas as atividades de garantia da qualidade e deve ser utilizado efetivamente ao longo do desenvolvimento do projeto; Resultados de medies de qualidade mtricas coletadas e consolidadas, a partir das atividades de controle da qualidade, devem ser utilizadas para anlise e subsdio para melhoria do processo no mbito do projeto, assim como no mbito organizacional. Como principal resultado do processo tem-se a Melhoria da Qualidade, que inclui aes de melhoria no projeto, assim como nos processos, mtodos e padres adotados pelo projeto. Essas aes so identificadas em atividades como auditorias, revises e coleta de mtricas. Controle da Qualidade de Software Compreende atividades de monitorao de resultados especficos do projeto, a fim de determinar sua aderncia a padres de qualidade e identificar causas de resultados insatisfatrios. Essas atividades so executadas atravs do uso de tcnicas que incluem revises por pares, diagramas de Pareto, teste e anlise de tendncias, entre outras. O controle da qualidade deve ser executado ao longo do desenvolvimento do software, em geral, por membros da equipe de desenvolvimento, assim como por pessoas que tenham independncia com relao equipe de desenvolvimento de software. 6.3.3 Custos da Qualidade Os custos da qualidade abrangem o custo total dos esforos para alcanar a qualidade do produto/servio, podendo ser categorizados em custos de preveno, custos de avaliao, custos de falhas internas e custos de falhas externas. A fim de reduzir custos de falhas internas e externas, ns, tipicamente, devemos despender mais esforo em preveno e deteco. Conforme ilustrado na Figura 6.7, existe um ponto timo de equilbrio entre os diferentes custos de qualidade, que aponta um custo ideal total da qualidade. Vale salientar que esse ponto timo, no entanto, pode ser difcil de ser mensurado, considerando custos subjetivos de falhas externas, como a insatisfao do cliente, por exemplo.
86
Figura 6.7: Balanceamento do custo da qualidade [Kezner1998] Os custos de preveno incluem esforo para prevenir defeitos que venham a ser inseridos ao longo do desenvolvimento do software. Os custos de avaliao compreendem o custo do esforo gasto em atividades de deteco de defeitos nos produtos, processos ou servios. Os custos de falhas internas envolvem manuteno e correo de falhas encontradas antes da liberao do produto ou servio ao cliente. Inclui esforos gastos nas seguintes atividades: Depurao; Correo; Re-peer reviews; Teste da correo e teste de regresso.
Finalmente, os custos de falhas externas envolvem manuteno e correo de falhas encontradas aps da liberao do produto ou servio ao cliente. Inclui esforos gastos nas seguintes atividades: Depurao; Correo; Re-peer reviews; Teste da correo e teste de regresso; Verses corretivas; Servio de atendimento ao cliente; Insatisfao do cliente e vendas perdidas.
87
Alguns mtodos de coleta podem ser adotados para subsidiar a anlise de custos da qualidade, conforme relacionado a seguir: Time sheets; Logs e relatrios de teste; Help desk; Sistemas de reporte de defeitos; Custo do projeto; Informaes de vendas; ndice de satisfao do cliente.
6.4 MODELOS E PADRES DE QUALIDADE DE SOFTWARE Com o crescimento do setor de software, vrios modelos e padres tm sido propostos ao longo dos ltimos anos. Nesse contexto, alguns conceitos fundamentais so importantes de serem entendidos. O primeiro deles a poltica, que representa um princpio governamental, tipicamente usado como base para regras, procedimentos ou padres e geralmente estabelecido pela mais alta autoridade da organizao [Humphrey1989]. Um padro pode ser entendido como uma base para comparao e usado para suportar tamanho, contedo, valor ou qualidade de um objeto ou atividade. Um guia, por sua vez, uma prtica, mtodo ou procedimento sugerido. Finalmente, um modelo pode ser definido como uma representao abstrata de um item ou processo, a partir de um ponto de vista especfico. O objetivo do modelo expressar a essncia de algum aspecto de um item ou processo, sem prover detalhes desnecessrios. Diversos modelos de qualidade de software vm sendo propostos ao longo dos ltimos anos. Esses modelos tm sido fortemente adotados por organizaes em todo o mundo. A Tabela 6.1 apresenta uma viso geral da evoluo dos modelos de qualidade de software, atravs de algumas iniciativas relevantes, desde 1980. Em seguida, os padres ISO9000 e os modelos propostos pelo Software Engineering Institute so abordados ainda nessa seo. Tabela 6.1: Iniciativas para melhoria da qualidade do processo de software
ANO 1983 1984 1987 - Avaliao conduzida pela IBM - ISO 9001 verso inicial - NIST/MBNQA: 1 Prmio de Qualidade Nacional Malcolm Baldrige (USA) - SEI-87-TR-24 (questionrio SW-CMM) 1988 Continua... - AS 3563 (Sist. de Gerenciamento de Qualidade de Software) verso inicial INICIATIVA - NQI/CAE: 1 Prmio Canadense de Excelncia
88
EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software ...continuao 1991 - IEEE 1074 verso inicial - ISO 9000-3 verso inicial - SEI SW-CMM V 1.0 verso inicial - Trillium V 1.0 verso inicial 1992 - EFQM/BEA: 1o Prmio de Excelncia do Negcio (Europa) - IEEE adota AS 3563 como IEEE 1298 - TickIT V2.0 1993 - SEI SW-CMM V1.1 - BOOTSTRAP - SPICE 1994 1995 1996 1997 1998 1999 2000 2001 2003 - ISO 9001 - Trillium V3.0 - ISO 12207 verso inicial - ISO 15504 (SPICE) verso inicial - IEEE/EIA 12207 - ISO 9000-3 - SW-CMM com suporte ao CMM Integration (CMMI) - ISO 15504 (SPICE) para o pblico como relatrio tcnico - TickIT V4.0 - SEI CMMI para projetos piloto - Nova verso da ISO9001 - CMMI - Adendo a ISO12207 - Nova verso da ISO9000-3 - ISO 15504
6.4.1 As Normas ISO A International Organization for Standardization (ISO) uma organizao nogovernamental, fundada em 23/02/1947, com sede em Genebra Sua. A razo de existncia da ISO foi motivada pela necessidade de referncias internacionais para regulamentar obrigaes contratuais entre fornecedores e compradores, que focalizassem a garantia de manuteno e uniformidade da qualidade de produtos. As normas da ISO h muito tempo so relacionadas qualidade. Atualmente, a norma ISO9001:2000 modelo base para auditorias de certificao da famlia ISO9000. A norma um padro internacional que especifica requisitos para um sistema gerencial de qualidade de uma organizao. Com o crescimento substancial das indstrias de software e, levando-se em conta que a produo de software
89
apresenta caractersticas peculiares, a ISO tem trabalhado na definio de vrias normas que podem ser utilizadas como guias e padres para diversas reas de atuao dentro do contexto da cincia da computao. Dentre esses, vale ressaltar a importncia da norma ISO9000-3, que estabelece um guia para facilitar a aplicao da ISO9001 para desenvolvimento, suporte e manuteno de software. Seguindo o mesmo contedo da ISO9001, a ISO9000-3 descreve requisitos para sistemas de qualidade, focados em 4 aspectos: Responsabilidade gerencial envolve o compromisso da alta administrao; Gerncia de recursos - abrange tanto a parte de infra-estrutura quanto o capital humano da organizao;
Realizao do produto - compreende requisitos para planejamento, projeto e implementao de produtos; Medio e anlise - contempla requisitos para coleta e anlise do sistema da qualidade.
A Figura 6.8 apresenta uma visualizao grfica dos requisitos da Norma ISO9000-3:2000.
Figura 6.8: Requisitos da ISO9001/ISO9000-3 Uma certificao ISO9000, no Brasil, conduzida por uma empresa acreditada pelo INMETRO. Isso significa que a empresa foi avaliada e julgada por um organismo certificador, pertencente ao Sistema Brasileiro de Certificao, segundo aquela norma. A Tabela 6.2 apresenta algumas normas ISO aplicadas qualidade de software, focadas em produto ou processo de software.
90
Tabela 6.2: Normas ISO9000 para suporte ao desenvolvimento de software

Nome Norma ISO/IEC 9126 (NBR 13596) Descrio Define as caractersticas de qualidade de software que devem estar presentes em todos os produtos (Funcionalidade, Confiabilidade, Eficincia, Usabilidade, Manutenibilidade e Portabilidade); Estabelece os requisitos de qualidade para pacotes de software; Define um processo de avaliao da qualidade de produto de software; Define um processo de ciclo de vida de software; Apresenta diretrizes para a aplicao da ISO 9001 por organizaes que desenvolvem software ao desenvolvimento, fornecimento e manuteno de software; Aprovada como norma em 2003 focada na avaliao de processos organizacionais.
Norma ISO/IEC 12119 Norma ISO/IEC 14598-5 Norma ISO/IEC 12207 Norma ISO/IEC 9000-3
Norma ISO15504
Dentre as normas citadas, vale a pena destacar a norma ISO12207 e a recm aprovada ISO15504. A ISO12207 descreve um modelo de ciclo de vida de software, que pode servir de base referencial para organizaes que desejam formalizar um processo de desenvolvimento de software. A ISO15504 atualmente uma norma que representa um padro internacional emergente, que estabelece um framework para construo de processos de avaliao e melhoria. ISO12207 O principal objetivo da norma ISO12207 o estabelecimento de uma estrutura comum para os processos de ciclo de vida de software, para ser utilizada como referncia. Alm disso, a norma considera que o desenvolvimento e a manuteno de software devem ser conduzidos da mesma forma que a disciplina de engenharia. A estrutura descrita na ISO12207 (vide Figura 6.9) utiliza-se de uma terminologia bem definida e composta de processos, atividades e tarefas a serem aplicados em operaes que envolvam, de alguma forma, o software, seja atravs de aquisio, fornecimento, desenvolvimento, operao ou manuteno. Essa estrutura permite estabelecer ligaes claras com o ambiente de engenharia de sistemas, ou seja, aquele que inclui prticas de software, hardware, pessoal e negcios.
91
Figura 6.9: Processos da ISO12207 ISO15504 Em 1993, um grupo de trabalho conjunto da ISO/IEC-International Organization for Standardization/International Electrotechnical Commission estabeleceu um projeto denominado SPICE-Software Process Improvement and Capability Evaluation [Dorling1993], que objetivava chegar a um consenso entre os diversos mtodos de avaliao do processo de software. Este projeto posteriormente gerou o relatrio tcnico ISO15504 [ISO15504:1-9:1998]. A ISO15504 atualmente uma norma que representa um padro internacional emergente que estabelece um framework para construo de processos de avaliao e melhoria do processo de software. Este framework pode ser utilizado pelas ODSs envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisio, fornecimento, desenvolvimento, operao, evoluo e suporte do software. A ISO15504 no um mtodo isolado para avaliao e sua caracterstica genrica permite que possa ser utilizada em conjunto com uma variedade de mtodos, de tcnicas e de ferramentas. Nove documentos compem a ISO15504. Alguns tm carter normativo (como a ISO15504-2, ISO15504-3 e ISO 15504-9) e outros possuem carter informativo (como a ISO15504-1, ISO15504-4, ISO15504-5, ISO15504-6, ISO15504-7 e ISO15504-8). A seguir faremos um resumo do contedo destes documentos.
92
A ISO15504-1 fornece as informaes gerais sobre o contedo de todos os documentos da ISO15504 e como eles esto relacionados. Determina tambm o campo de aplicao da ISO15504, seus componentes e os relacionamentos da ISO15504 com outros padres internacionais (tais como a srie ISO9000 e a ISO12207). A ISO15504-2 define um modelo de referncia de processo e um modelo de capacitao do processo (Figura 6.10) que pode compor a base para a definio e avaliao de um processo de software. Este modelo de referncia possui uma abordagem bidimensional.
Nvel 5 Nome dos Atributos Processo Otimizado Atributos de mudana do processo Atributos de melhoria continua Processo Previsvel Atributos de medida do processo Atributos de controle do processo Processo Estabelecido Atributos de definio do processo Atributos de recursos do processo Processo Gerenciado Atributos de gerencimento do desempenho Atributos do gerenciamento de artefatos Processo Executado Atributos de desempenho do processo Atributos de melhoria continua Processo Incompleto
Processos do Ciclo de Vida Categoria
CUS
ENG
SUP
MAN
ORG
3 2 1 0
.............
Processo
Dimenso de Processo
Dimenso de Capacidade
Figura 6.10: As dimenses do modelo de referncia da ISO 15504 A primeira dimenso auxilia os engenheiros de processo na definio dos processos necessrios em uma ODS, assim como sua adequao ISO15504. A segunda dimenso, similar ao CMM, tem por objetivo determinar a capacidade do processo da ODS, avaliando-o atravs de um conjunto de atributos pr-estabelecidos. Os atributos de processo esto agrupados nos nveis de capacidade e podem ser aplicados em todos os processos descritos na ODS para determinar a maturidade do processo. Cinco grupos de processos so definidos pela ISO 15504-2: 1. Fornecedor-Cliente (CUS-Custormer-Supplier): so os processos que de alguma forma impactam diretamente o cliente: dentre eles o suporte para desenvolvimento e transaes de software para o cliente, fornecimento de operaes corretas e uso do produto de software ou servio;
93
2. Engenharia (ENG-Engineering): esta categoria agrupa os processos que especificam, implementam e mantm o produto de software, sua relao com o sistema e a documentao do cliente; 3. Suporte (SUP-Support): So processos que podem ser empregados em algum dos outros processos e em vrios pontos no ciclo de vida do software objetivando dar suporte a eles; 4. Gerenciamento (MAN-Management): so processos que contm prticas gerenciais que podem ser utilizadas por algum que gerencia algum tipo de projeto ou processo dentro do ciclo de vida do software; 5. Organizao (ORG-Organization): so processos que estabelecem as finalidades dos processos de desenvolvimento e da organizao, do produto, e dos recursos, que, quando utilizados por projetos na organizao, realizaro as metas do negcio. O modelo de referncia definido na ISO15504-2 fornece uma base comum para executar avaliaes da capacidade do processo de software. Porm, o modelo no pode ser utilizado sozinho, tendo em vista que o detalhamento insuficiente. As ISO15504-3 e ISO15504-4 servem como guias para a realizao de uma avaliao do processo. Determinam procedimentos para: a definio das entradas da avaliao, a determinao das responsabilidades, a especificao do processo propriamente dito da avaliao e os resultados que devem ser guardados. O modelo de avaliao definido pela ISO15504-5 est baseado e compatvel com o modelo de referncia descrito pela ISO15504-2, podendo ser usado como base para conduzir uma avaliao da capacidade do processo de software. A Figura 6.11 apresenta a estrutura bsica do modelo de avaliao da ISO15504-5 e seu relacionamento com a ISO15504-2. Este modelo de avaliao expande o modelo de referncia adicionando a definio e uso de indicadores de avaliao. Os indicadores de avaliao so definidos para que os assessores possam julgar o desempenho e capacidade de um processo implementado. A ISO15504-5 detalha os processos (primeira dimenso do modelo de referncia da ISO15504-2) associando a eles algumas prticas bsicas. Artefatos e atributos so sugeridos e associados s prticas bsicas com o intuito de estabelecer sua realizao.
94
A ISO15504-6 objetiva a preparao de assessores para a execuo de avaliaes de processos de software. Esta norma tambm descreve mecanismos que podem ser utilizados para determinar a competncia dos assessores e avaliar seu conhecimento, seu treinamento e a sua experincia como assessor.
MODELO DE AVALIAO Dimenso de Processo MODELO DE REFERNCIA Indicadores de avaliao Dimenso da Capacidade
Categorias de processo
Nveis de capacidade Atributos do processo
Indicadores de desempenho do processo Prticas bsicas
Indicadores da capacidade do processo Prticas de gerenciamento Caracteristicas de desempenho das prticas Caractersticas da infraestrutura e recursos
Artefatos e suas caractersticas
Figura 6.11: Relacionamento entre o modelo de referncia e o modelo de avaliao. A ISO15504-7 auxilia a criao de frameworks e mtodos para executar a melhoria do processo de software de um modo contnuo. Esta parte da ISO15504 estabelece como: Invocar uma avaliao do processo de software; Usar os resultados de uma avaliao; Medir o processo de software e melhorar sua efetividade; Identificar aes de melhorias alinhadas com as metas do negcio; Usar um modelo de processo compatvel com o modelo de referencia definido na ISO15504-2;e Garantir uma cultura organizacional no contexto de melhoria do processo de software.
A ISO15504-8 um guia para a determinao da capacidade do processo do fornecedor. Esta determinao da capacidade do processo uma avaliao e anlise sistemtica dos processos de software selecionados dentro de uma organizao, cujo objetivo identificar os pontos fortes, as fraquezas e os riscos associados no desdobramento do processo, encontrando um requisito especificado. Este requisito pode ser um projeto, um produto ou um servio, uma nova ou existente tarefa, um
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.
Figura 6.12: Utilizao da ISO15504 6.4.2 Os Modelos do Software Engineering Institute (SEI) O Software Engineering Institute (SEI), dos Estados Unidos, tem contribudo bastante com o fortalecimento da rea de qualidade de software, atravs da definio de modelos internacionais focados no processo de software, assim como na publicao de relatrios tcnicos e artigos relacionados ao assunto. Dentre os modelos propostos pelo SEI, o Capability Maturity Model for Software (CMM) destaca-se porque tem sido largamente adotado pela comunidade de software internacional. O CMM um modelo focado na capacidade organizacional e seu desenvolvimento foi motivado por uma solicitao do Departamento de Defesa dos Estados Unidos, que precisava de um instrumento de avaliao dos fornecedores contratados pelo prprio Departamento.
96
O CMM categoriza as organizaes em 5 nveis de maturidade, desde um processo ad hoc e desorganizado (nvel 1), at um estgio altamente gerenciado de melhoria contnua (nvel 5). Esses nveis de maturidade so definidos em reas-chave de processo (KPAs), que por sua vez, possuem metas que devem ser atingidas atravs da implementao de prticas-chave, categorizadas no que o modelo chama de caractersticas comuns, conforme observado na Figura 6.13.
Figura 6.13: Estrutura do Capability Maturity Model for Software O nvel de maturidade 2 se concentra em disciplinas de gerncia de projetos; o nvel 3 focado na definio, melhoria e uso adequado do processo de software da organizao; o nvel 4 define prticas referentes gerncia de qualidade. Finalmente, no nvel 5, a organizao deve ter processos para garantir efetividade na preveno de defeitos e em mudanas tecnolgicas e no processo organizacional. O CMM foi descontinuado pelo SEI e substitudo pelo CMMI, detalhado a seguir. Vale salientar que o CMM foi um dos modelos de qualidade mais adotados pelas indstrias de software brasileiro, juntamente com a norma ISO9001.
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
A arquitetura do CMMI composta basicamente pela definio de um conjunto de reas de processo, organizadas em duas representaes diferentes: uma como um modelo por estgio, semelhante ao SW-CMM, e outra como um modelo contnuo (semelhante ISO/IEC 15504). A verso atual composta por 25 reas de processo, conforme ilustrado na Figura 6.14.
Figura 6.14: CMMI - reas de processo em duas representaes: por estgio e contnua Cada rea de processo definida no modelo por meio da descrio de seu propsito, notas introdutrias, relacionamentos com outras reas, metas especficas, metas genricas, prticas e sub-prticas especficas, prticas e sub-prticas genricas, produtos de trabalho tpicos e referncias para outros elementos do modelo relacionados. A descrio de cada rea ocupa cerca de 20 pginas. Na representao por estgio, as 25 reas de processo esto agrupadas em 4 nveis de maturidade: nveis 2, 3, 4 e 5 (o nvel 1 no contm nenhuma rea de processo) [SEI2002b]. Em relao a esta representao, o processo de desenvolvimento e manuteno de software ou sistema de uma unidade
99
organizacional pode estar classificado em um dos seguintes cinco nveis de maturidade: Nvel 1: Inicial (Initial); Nvel 2: Gerenciado (Managed); Nvel 3: Definido (Defined); Nvel 4: Gerenciado Quantitativamente (Quantitatively Managed); Nvel 5: Otimizando (Optimizing).
Cada nvel de maturidade definido basicamente pelo conjunto de reas de processo do nvel. Na representao contnua, as mesmas 25 reas de processo esto agrupadas em quatro grupos (gerncia de processos, gerncia de projetos, engenharia e suporte) e so definidos seis nveis de capacidade de processo [SEI2002c]. Nesta representao, o conjunto de atividades correspondente a cada uma destas reas de processo, pode ter sua capacidade de execuo classificada em um dos seguintes seis nveis de capacidade de processo: Nvel 0: Incompleto (Incomplete); Nvel 1: Executado (Performed); Nvel 2: Gerenciado (Managed); Nvel 3: Definido (Defined); Nvel 4: Gerenciado Quantitativamente (Quantitatively Managed); Nvel 5: Otimizando (Optimizing).
Cada nvel de capacidade definido por um conjunto de caractersticas que o processo deve satisfazer para estar naquele nvel. Em relao ao SW-CMM, o CMMI por estgio uma reviso, com ajustes. No nvel 2 de maturidade, por exemplo, foi includa a rea de processo de medio e anlise como uma ampliao deste assunto, que j era coberto em parte em cada rea do SW-CMM. No nvel 3, por exemplo, a rea de engenharia de produto do SW-CMM foi mais bem descrita por meio de cinco reas de processo: Desenvolvimento de Requisitos, Soluo Tcnica, Integrao de Produto, Verificao e Validao. Outras mudanas ocorrem para refletir melhor a orientao para atendimento dos nveis de maturidade. Em relao utilizao para melhoria de processo, o CMMI por estgio sugere abordagens semelhantes quelas utilizadas com sucesso com o SW-CMM. Em relao ao CMMI contnuo, a tendncia toda a experincia de utilizao da ISO15504 ser aproveitada para ajustar as abordagens j utilizadas com sucesso pelo SW-CMM.
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);
101
Ao, que foca a definio de processos e mtricas, execuo de projetos pilotos e acompanhamento; Nivelamento (Leveraging), que abrange a atualizao da abordagem organizacional e anlise de lies aprendidas. A Figura 6.15 apresenta uma visualizao grfica do modelo IDEAL.
Figura 6.15: Visualizao grfica do IDEAL [MacFeeley1999] O IDEAL adotado como base de vrios mtodos de avaliao definidos pelo SEI. Vale salientar seu alinhamento abordagem do ciclo PDCA, apresentado na seo 6.2.5. 6.6 AUDITORIAS E AVALIAES (ASSESSMENTS) Um dos avanos mais relevantes do controle da qualidade o crescimento da funo de auditoria da qualidade. A implementao e execuo das auditorias representam uma das reas mais significativas da engenharia de controle do processo. Por outro lado, as avaliaes, tambm conhecidas como assessments, so tambm largamente adotadas como fundamento para planos de melhoria. Esta seo tem como objetivo assegurar um entendimento sobre o conceito de auditoria e avaliao interna (assessment), seus objetivos e benefcios.
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; Identificao da eficcia do sistema da qualidade e do potencial de melhoria; Atendimento aos requisitos regulamentares; Para fins de certificao.
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:
103
Primeira parte
realizada por uma organizao sobre si mesma;
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.
Figura 6.16: Viso geral do processo de auditoria 6.6.2 Avaliaes Internas (Assessments) As avaliaes internas, tambm conhecidas como assessments, auxiliam a organizao a melhorar, atravs da identificao de problemas crticos e estabelecimento de aes de melhoria, com foco em reviso e no em auditoria. Elas tm como objetivos a aquisio de conhecimento sobre como a organizao trabalha, a fim de identificar principais problemas e recomendar aes (vide Figura 6.17).
104
A conduo e sucesso de uma avaliao interna esto relacionados garantia de algumas premissas, conforme relacionadas a seguir: Base em um modelo de processo toda avaliao interna segue um modelo que serve como base para a avaliao do processo em foco. O CMM um bom exemplo de um modelo que serve de base para essas avaliaes; Confidencialidade naturalmente, muitas informaes so analisadas criticamente e, dessa forma, expostas equipe condutora. Assim, a confidencialidade premissa bsica para que a organizao submetida avaliao esteja totalmente vontade para expor os dados que forem necessrios para uma concluso segura; Envolvimento da alta gerncia o compromisso da alta direo da organizao que est sendo avaliada fundamental para respaldar os resultados e garantir a execuo de aes corretivas; Respeito a diferentes pontos de vista cada organizao tem cultura prpria. essencial que se leve em considerao a cultura organizacional e a liberdade de escolha com relao forma de execuo de algumas atividades.
Figura 6.17: Viso geral do processo de avaliao Assim como as auditorias, as avaliaes precisam ser bem planejadas e geram como produto principal um documento. Esse documento compreende os resultados das avaliaes realizadas durante o perodo de avaliao, apontando pontos fracos e fortes, identificados durante os trabalhos. Uma caracterstica interessante das avaliaes internas que elas so conduzidas por um grupo de pessoas, diferente das auditorias, que em geral so conduzidas por 1 ou 2 auditores.
105
6.7 MEDIO DE SOFTWARE O uso de mtricas tem representado uma ferramenta essencial gerncia de projetos de software. Muitos engenheiros de software medem as caractersticas do mesmo, a fim de obter uma viso clara de uma srie de aspectos, tais como, o atendimento dos produtos de software aos requisitos especificados, desempenho do processo de desenvolvimento, esforo/custo despendido, entre outros. As medies podem ser teis sob diferentes ticas. Por exemplo, o gerente de projeto pode utilizar medies para se certificar se estimativas realizadas no incio do projeto foram efetivas, acompanhando esforo, prazo, custo e tamanho, comparando dados planejados com dados reais. Por outro lado o cliente pode usar medies para determinar se o mesmo atende aos requisitos e se possui um grau de qualidade satisfatrio. 6.7.1 Seleo de Mtricas Atualmente, os programas de mtricas de software tm sido definidos para prover informaes especficas necessrias para gerenciar projetos de software e melhorar processos e servios de engenharia de software. Objetivos no nvel organizacional, de projeto ou de tarefa, so determinados antecipadamente e, ento, mtricas so selecionadas baseadas nesses objetivos. Essas mtricas so, ento, utilizadas para determinar a eficcia do alcance desses objetivos. Vale salientar que as mtricas coletadas no solucionam problemas. O que as mtricas podem fazer prover informao sobre as quais se pode garantir tomadas de decises embasadas em dados mais concretos. Uma mtrica til sempre tem um cliente. O cliente dessa mtrica a pessoa (ou pessoas) que ir tomar decises com base na informao gerada pela mtrica. Se uma mtrica no tem um cliente, ou seja, se no existe uma pessoa que vai utiliz-la para tomada de deciso, ento a mtrica no tem sentido para a organizao. Em outras palavras, preciso responder seguinte pergunta: Quem precisa da informao? Quem ir usar esta mtrica? Tcnica Goal/Question/Metric (GQM) A tcnica, ou paradigma, GQM foi definida por Basili e Rombach e prov um excelente mecanismo para definio de um programa de mtricas baseado em objetivos. Segundo a tcnica, primeiramente deve-se selecionar um ou mais objetivos mensurveis. Esses objetivos podem ser tanto metas estratgicas, como minimizao de custos ou maximizao de satisfao do cliente, quanto objetivos mais especficos, como avaliao de um novo mtodo de anlise e projeto, por exemplo.
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. Qual o nvel de satisfao atual do meu cliente? Como ns estamos em comparao com nossos concorrentes?
Quais atributos de produtos e servios so mais importantes para os nossos clientes? => Selecionando Mtricas Finalmente, mtricas devem ser selecionadas sempre com o foco nico de resposta s questes definidas. Em outras palavras, so as mtricas que provem informao necessria para responder cada questo definida. Para que um programa de mtricas seja efetivo e para que a mtrica selecionada seja til para a organizao importante que ela seja:
107
Facilmente calculada, entendida e testada; Passvel de estudos estatsticos; Expressa em alguma unidade; Obtida o mais cedo possvel no ciclo de vida do software; Passvel de automao; Repetvel e independente do observador. Vlida: quantifica o que queremos medir; Confivel: produz os mesmos resultados dadas as mesmas condies; Prtica: barata, fcil de computar e fcil de interpretar.
Alm disso, uma mtrica deve ser:
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: Quantos defeitos ns temos por produto? Qual o status de cada defeito?
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
Em 1979, Allan Albrecht, prosseguindo essas pesquisas, introduziu uma tcnica de avaliao conhecida como pontos por funo. Essa mtrica tem sido bastante adotada e est baseada na viso externa do usurio, sendo independente da linguagem utilizada. Ela permite calcular o esforo de programao e auxilia o usurio final a melhorar o exame e avaliao de projetos. Os pontos por funo de um sistema de informao so definidos em trs etapas de avaliao: A primeira etapa resulta na contagem de pontos por funo no ajustados, que refletem as funes especficas e mensurveis do negcio, provida ao usurio pela aplicao; A segunda etapa da avaliao gera o fator de ajuste, que representa a funcionalidade geral provida ao usurio pela aplicao; A terceira e ltima etapa resulta na contagem de pontos por funo ajustados, que por sua vez reflete o fator de ajuste aplicado ao resultado apurado na primeira etapa. O clculo do fator de ajuste baseado em 14 caractersticas gerais dos sistemas, que permitem uma avaliao geral da funcionalidade da aplicao. Essas caractersticas so relacionadas a seguir: Comunicao de dados; Processamento distribudo; Performance; Utilizao de equipamento; Volume de transaes; Entrada de dados on-line; Eficincia do usurio final; 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.
109
Esse mtodo independente da linguagem de programao. Baseia-se em dados que so conhecidos logo no comeo da evoluo de um projeto, tornando-se mais atraente como abordagem de estimativa. No entanto, a contagem dos pontos se baseia parcialmente em dados subjetivos, implicando organizao estabelecer um plano com critrios e premissas para subsidiar a medio, antes do incio efetivo da utilizao. Esse planejamento fundamental para que os resultados das medies possam ser comparados entre os projetos. 6.8 VERIFICAES E VALIDAES Cada vez mais, as verificaes e validaes de software tm sido consideradas ferramentas teis no contexto da garantia da qualidade de software. Atravs delas, so obtidas vises mais concretas com relao a aspectos de qualidade de alguns produtos de software. Nesse contexto, as revises formais - que incluem inspees e atividades de teste so fortemente recomendadas por modelos atuais de qualidade de software, tais como as normas ISO e o CMM. Segundo o IEEE, verificao e validao de software (V&V) abrangem tcnicas de reviso, anlise e teste para determinar o quanto um sistema de software e seus produtos intermedirios esto de acordo com os requisitos. Esses requisitos incluem tanto capacidade funcional quanto atributos de qualidade. O esforo de V&V tipicamente aplicado como parte ou em paralelo ao desenvolvimento do software e atividades de suporte. Ele prov informaes sobre engenharia, qualidade e status dos produtos de software ao longo do ciclo de vida, promovendo previamente identificao de defeitos. Essa seo apresenta informaes sobre verificao e validao, especialmente apresentando a tcnica de revises formais. Vale salientar que atividades de teste esto no contexto das verificaes e j foram abordadas no captulo 5. 6.8.1 Revises Formais As revises formais so verificaes normalmente adotadas para a garantia de produtos de software. Segundo o IEEE [IEEE1999b], os principais tipos de revises formais de software so: Revises Tcnicas (technical reviews) Essas revises tm o objetivo de avaliar artefatos especficos para verificar se eles esto de acordo com os respectivos padres e especificaes e se eventuais modificaes nos artefatos foram efetuadas de maneira correta. Em geral, as revises
110
tcnicas so aplicadas a documentos - como o Documento de Requisitos, artefatos tcnicos de anlise e projeto, Projeto de Teste - com objetivo principal de verificar a aderncia dos artefatos revisados aos padres adotados pelo projeto, assim como aspectos que interferem na qualidade, como completude, preciso, consistncia, facilidade de manuteno e verificao, entre outros aspectos. Inspees (inspection) Representam um tipo de reviso por pares (peer reviews). Tm o objetivo principal de identificao e remoo de defeitos. obrigatria a gerao de uma lista de defeitos, com classificao padronizada, requerendo-se a ao dos autores para remoo desses defeitos. Em geral, so aplicadas aos artefatos de desenho, implementao e testes, focalizando a correo destes em relao aos respectivos padres e especificaes, enquanto as revises tcnicas tm maior enfoque na qualidade da documentao. Inspees sero mais bem detalhadas na Seo 6.8.2. Wakthroughs So revises nas quais o autor apresenta, em ordem lgica, sem limite de tempo, o material a um grupo, que verifica o material medida que ele vai sendo apresentado. Esse tipo de reviso no exige muita preparao prvia e pode ser feito com maior nmero de participantes. As revises de apresentao so consideradas como de eficcia mdia para a deteco de defeitos. Elas podem ser usadas nos marcos de projeto, em que so necessrias apresentaes ao cliente. Revises Gerenciais So conduzidas pelo gerente de um projeto, com os objetivos principais de avaliar os problemas tcnicos e gerenciais do projeto, assim como o seu progresso em relao aos planos. Em geral, pelo menos uma reviso gerencial deve ser realizada ao final de cada iterao. Conforme a poltica adotada de controle de projetos, elas podem ser tambm realizadas por perodo (por exemplo: semana, quinzena ou ms). Finalmente, so aplicveis a alguns documentos que no requerem, normalmente, uma reviso tcnica, por serem de natureza gerencial, ou como reviso preliminar de documentos que sero submetidos a revises tcnicas ou revises de apresentao ao cliente. Alm dos tipos supracitados, o padro IEEE-1028 [IEEE1999b] cobre tambm as auditorias, que tm o objetivo de verificar a conformidade de produtos e projetos com padres e processos. Revises informais tambm podem ser realizadas, especialmente antes das revises formais, a fim de que problemas mais relevantes possam ser resolvidos
111
antecipadamente. Exemplos de revises informais incluem a programao em pares, adotada pelas metodologias geis, como a Extreme Programming (XP), e as revises individuais, que so realizadas pelos autores, seguindo formalmente os roteiros pertinentes, eventualmente com a ajuda de pares. 6.8.2 Inspees de Software Inspees representam um tipo de revises formais por pares, ou peer reviews, as quais so tcnicas de anlise para avaliao de forma, estrutura e contedo de um documento, cdigo fonte ou outro produto de trabalho [Wieger2002]. Essa tcnica realizada por um grupo de pessoas que tm o mesmo perfil (da pares) do autor do produto a ser revisado, a fim de identificar discrepncias do produto com base em padres e especificaes. Em outras palavras, inspeo um mtodo formal de reviso por pares, onde um grupo de pares, incluindo o autor, se rene para examinar um determinado produto de trabalho. O produto de trabalho , tipicamente, submetido inspeo quando o autor acredita que o mesmo foi concludo ou est pronto para ser promovido a uma prxima fase ou atividade do ciclo de vida. O foco da inspeo a identificao de defeitos, com base em preparao prvia dos participantes. Vale salientar que mtricas devem ser coletadas e utilizadas para determinar critrios de entrada para a reunio de inspeo, assim como para serem consideradas no processo de melhoria. A Figura 6.18 apresenta uma viso geral do processo de inspeo. O resultado final de uma inspeo deve ser um dos seguintes: Material aceito sem modificaes; Material aceito com pequenas modificaes (no ser necessria nova reviso tcnica para o resultado do projeto em pauta, colocando-se um dos membros da reviso tcnica disposio do gerente do projeto para uma reviso informal das modificaes); Material rejeitado para profundas modificaes (haver necessidade de nova reviso aps serem feitas as modificaes sugeridas); Material rejeitado para reconstruo (ser necessria nova confeco do material); A reviso no foi completada (foi necessrio cancelar ou interromper a reunio de reviso e uma nova reviso ser marcada). Na ausncia de consenso para a classificao dos defeitos, prevalece o pior status proposto pelos revisores. Recomendam-se as seguintes diretrizes: Nas inspees de projeto, violaes dos requisitos levam, obrigatoriamente, rejeio;
112
Nas inspees de implementao, obrigatoriamente, rejeio;
violaes
do
desenho
levam,
Violaes no justificadas de padres pertinentes ao material levam, normalmente, rejeio; Defeitos de forma (portugus, esttica, falta de uniformidade de apresentao) levam, normalmente, aceitao, com pequenas modificaes, exceto no caso de documentos de usurio, caso em que levam rejeio.
Figura 6.18: Viso geral do processo de inspeo 6.9 CONSIDERAES FINAIS Nos ltimos anos, com a crescente demanda por produtos mais eficazes e de baixo custo agregado, somado ao surgimento de um mercado sem limites de competitividade, a qualidade tornou-se um aspecto fundamental a qualquer organizao. Qualidade e produtividade so fatores que foram sendo tratados por diversos autores ao longo de vrios anos, desde a dcada de 1950. Entre tais autores esto Crosby, Deming, Juran e outros que muito contriburam com o setor produtivo, atravs de abordagens bastante relevantes, que servem de fundamentos para modelos propostos at hoje. No contexto da qualidade de software, vrios modelos vm sendo publicados e so, hoje, largamente adotados por vrias organizaes no mundo. As normas ISO, os modelos propostos pelo Software Engineering Institute-SEI, como o Capability Maturity
113
Model for Software (CMM), so hoje considerados requisitos para organizaes de software que desejam um lugar de destaque no mercado competitivo. Nesse contexto, conceitos como preveno e deteco, avaliaes e auditorias, coleta e anlise de mtricas, entre outros, devem ser bem entendidos para se garantir uma viso clara do cenrio da qualidade de software.
114
7
QUALIDADE DE PRODUTO DE SOFTWARE
Qualidade definida como Totalidade de caractersticas de uma entidade que lhe confere a capacidade de satisfazer as necessidades explcitas e implcitas. Atualmente existem normas da ISO/IEC JTC1 que tentam definir as caractersticas de qualidade do produto de software. Essas caractersticas tm como principal objetivo organizar e tratar o produto de software sobre os seus diversos aspectos, contribuindo para que os desenvolvedores entendam e planejem o desenvolvimento do produto para atender aos aspectos de qualidade que mais so relevantes para o produto, visto que o atendimento de todas as caractersticas poderia ser economicamente invivel. A principal norma de qualidade de produto a ISO/IEC 9126 que especifica um modelo de qualidade o qual categoriza atributos de qualidade de software em seis caractersticas, as quais so, por sua vez, subdivididas em subcaractersticas. Estas subcaractersticas so manifestadas externamente quando o software utilizado como parte de um sistema computacional e so um resultado de atributos internos de software. O efeito combinado das caractersticas de qualidade de software para o usurio definido como qualidade em uso. 7.1 MODELO DE QUALIDADE A qualidade de software pode ser definida e avaliada usando um modelo de qualidade definido. Um modelo de qualidade agrupa os vrios aspectos do produto e no caso da norma temos 6 caractersticas de qualidade, que agrupadas formam a totalidade do produto de software.
116
Qualidade de produto de software
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade
Adequao Acurcia Interoperabilidade Segurana de acesso Conformidade
Maturidade Tolerncia a Falhas Recuperabilidade Conformidade
Inteligibilidade Apreensibilidade Operacionalidade Atratividade Conformidade
Comportamento em relao ao tempo Comportamento em relao aos recursos
Conformidade
Analisabilidade Modificabilidade Estabilidade Testabilidade Conformidade
Adaptabilidade Capacidade para ser instalado Co-existncia Capacidade para substituir Conformidade
Figura 7.1: Qualidade de produto de software Os atributos de qualidade de software so categorizados em seis caractersticas (funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade), que so subdivididas dentro em subcaractersticas. Subcaractersiticas podem ser medidas atravs de mtricas internas ou por mtricas externas. Mtricas internas bsicas (tais como tamanho de programa) so medidas de software que normalmente no so usadas isoladas como mtricas de qualidade de software, mais so usadas em combinao com outras medidas para criar mtricas de qualidade. So fornecidas definies para cada caracterstica do software e respectivas subcaractersticas que influenciam a caracterstica de qualidade. A capacidade do software referente a cada caracterstica e subcaracterstica determinada por um conjunto de atributos internos que possam ser medidos. Exemplos de mtricas internas so fornecidos no documento ISO/IEC 9126-3. As caractersticas e subcaractersticas podem ser medidas externamente pelo quanto a capacidade representada por elas fornecida pelo sistema contendo o software. Exemplos de mtricas externas so fornecidos no documento ISO/IEC 9126-2.
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.
Qualidade de Software de Produto de Software
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).
7.2.4 Segurana de acesso A capacidade do produto de software para proteger informaes e dados de forma que pessoas ou sistemas no autorizados no possam l-los nem modific-los e pessoas ou sistemas autorizados no faam acessos danosos a eles.
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.
7.3.2 Tolerncia a falhas A capacidade do produto de software de manter um nvel de desempenho especificado em casos de defeitos no software ou de violao de sua interface especificada.
119
NOTA - O nvel de desempenho especificado pode incluir a capacidade de suportar falhas. 7.3.3 Recuperabilidade A capacidade do produto de software de restabelecer seu nvel de desempenho e recuperar os dados diretamente afetados no caso de uma falha. 7.3.4 Conformidade A capacidade do produto de software de estar de acordo com normas, convenes ou regulamentaes relativos a confiabilidade . 7.4 USABILIDADE A capacidade do produto de software de ser compreendido, aprendido, usado e apreciado pelo usurio, quando usado sob condies especificadas. NOTAS 1 Alguns aspectos como funcionalidade, confiabilidade e eficincia tambm afetaro a usabilidade, mas para os propsitos da ISO/IEC 9126 no so classificados como usabilidade. 2 Usurios podem incluir operadores, usurios final e intermedirio que esto sob influncia de ou dependentes do uso do software. A usabilidade deve enderear todos os diferentes ambientes que o software pode afetar, os quais podem incluir preparao para uso e avaliao de resultados. 7.4.1 Inteligibilidade A capacidade do produto de software de permitir ao usurio reconhecer se o software se aplica a suas necessidades e como ele pode ser usado para determinadas tarefas e condies de uso. NOTA - Isto depender da documentao e impresses iniciais oferecidas pelo software. 7.4.2 Apreensibilidade A capacidade do produto de software de permitir ao usurio aplicao. aprender sua
120
NOTA - Os atributos internos correspondem a aplicabilidade para aprendizagem, como definido na ISO 9241-10. 7.4.3 Operacionalidade A capacidade do produto de software de permitir o usurio oper-lo e control-lo. NOTAS 1 Aspectos de aplicabilidade, modificabilidade, adaptabilidade e capacidade de instalao podem afetar a operacionalidade. 2 Operacionalidade corresponde capacidade de controle, tolerncia a erros e conformidade com as expectativas do usurio como definido na ISO 9241-10. 3 Para um sistema que operado por um usurio, a combinao de funcionalidade, confiabilidade, usabilidade e eficincia pode ser medida externamente pela qualidade em uso. 7.4.4 Atratividade A capacidade do produto de software de ser apreciado pelo usurio. NOTA - Isto se refere a atributos de software que possuem a inteno de fazer o software mais atrativo para o usurio, como o uso de cores e da natureza do projeto grfico. 7.4.5 Conformidade A capacidade do produto de software de estar de acordo com normas, convenes, guias de estilo ou regulamentaes relativas a usabilidade. 7.5 EFICINCIA A capacidade do produto de software de fornecer desempenho apropriado, relativo quantidade de recursos usados, sob condies especificadas. NOTAS 1 Recursos podem incluir outros produtos de software, facilidades de hardware e materiais ( por exemplo: impressora, disquetes) . 2 Para um sistema que operado por um usurio, a combinao de funcionalidade, confiabilidade, usabilidade e eficincia pode ser medida externamente pela qualidade em uso.
121
7.5.1 Comportamento em relao ao tempo A capacidade do produto de software de fornecer tempo de resposta e tempo de processamento apropriados e taxas de I-O (entrada e sadas) quando executando suas funes, sob condies estabelecidas. 7.5.2 Utilizao de recursos A capacidade do produto de software de usar quantidade e tipos de recursos apropriados quando o software executa suas funes sob condies estabelecidas.
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.
CARACTERSTICAS DE QUALIDADE EM USO

O quanto que um produto usado por usurios especificados atende suas necessidades para atingir metas especificadas com eficcia, produtividade, segurana e satisfao em contextos de uso especificados. NOTAS 1 Qualidade em uso a viso do usurio da qualidade de um sistema contendo software e medida em termos do resultado do uso do software ao invs das propriedades do prprio software. 2 Exemplos de mtricas para qualidade em uso so dados na ISO/IEC 9126-2. 3 A definio de qualidade em uso em NBR 14598-1 (que reproduzida no Anexo A) no inclui atualmente a nova caracterstica de segurana.
124
4 Usabilidade definida em ISO 9241-11 de uma maneira similar definio de qualidade em uso nesta parte da NBR 9126. Qualidade em uso pode ser influenciada por qualquer das caractersticas de qualidade, e assim definido na NBR 9126-1 em termos de inteligibilidade, apreensibilidade, operabilidade e atratividade. 7.9 EFICCIA O quanto que o produto de software permite aos usurios atingir metas especificadas com acurcia e completitude em um contexto de uso especificado. 7.10 PRODUTIVIDADE Os recursos dispendidos pelo sistema e usurios em relao eficcia atingida quando o produto de software utilizado em um contexto de uso especificado. NOTA - Recursos relevantes podem incluir tempo, esforo, materiais ou custos financeiros. 7.11 SEGURANA O quanto que o produto de software limita o risco de danos (para pessoas) ou avarias em um nvel aceitvel em um contexto de uso especificado. NOTAS 1 A definio baseada na ISO 8402:1994. 2 Segurana inclui o risco de danos para a sade dos usurios de um sistema e riscos de avarias ou leses resultante do uso do produto de software. 3 Riscos para a segurana so usualmente um resultado de deficincias na funcionalidade, confiabilidade ou usabilidade.
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
Figura 7.2: Qualidade em uso
8
CONCLUSO
A Engenharia de Software uma disciplina que est envolvida com todos os aspectos da produo de software, desde a sua concepo at a sua entrega, operao e manuteno. Neste livro, os aspectos da produo de software foram abordados com foco em trs grandes reas da Engenharia de Software: a Engenharia de Produto, a Gerncia de Projetos e a Engenharia de Processo. Em relao engenharia de produto apresentaram-se os modelos de ciclo de vida e as principais atividades envolvidas no desenvolvimento de software. No que se refere gerncia de projetos de software abordou-se as dificuldades para sua execuo, as principais atividades envolvidas e o PMBOK. Quanto engenharia de processo foram apresentados aspectos relacionados qualidade de software (a engenharia de processo comumente vista como uma extenso da garantia da qualidade). Vale ressaltar que o objetivo maior da Engenharia de Software produzir software de qualidade, dentro do prazo e no custo desejado pelo cliente. Nesse contexto, os padres e normas para SPA/SPI tm realizado uma excelente contribuio para a rea auxiliando na definio, avaliao e melhoria dos processos de uma ODS. Todavia, apesar da sua importncia, eles ainda esto sendo pouco considerados pelas ODSs. Diversos motivos dificultam o uso desses padres, dentre eles o fato de que a definio e uso de um processo de software envolve uma complexa inter-relao de fatores organizacionais, culturais, tecnolgicos e econmicos. No que se refere ao gerenciamento de projetos de software especificamente, pode-se estar de acordo com as concluses realizadas nos trabalhos de [Fernandes1989] e [Maidantchik1999]: apesar do esforo da comunidade de engenharia de software em definir modelos e padres para a construo de um efetivo processo de gerenciamento de projetos, a maioria das ODSs ainda sentem dificuldade em definir os seus processos e no gerenciam os seus projetos de forma satisfatria.
127
Por fim, conclui-se que impulsionado pelas mudanas tecnolgicas os produtos, as ODSs e seus processos associados mudaram no decorrer das ltimas dcadas. Atualmente, as fbricas de software so medidas por dois fatores que esto relacionados a qualquer outro tipo de indstria: qualidade de seus produtos e capacidade de ser cada vez mais produtiva. Essa a essncia atual para a sobrevivncia e sucesso de uma empresa de software. Nesse contexto, a Engenharia de Software tem sido cada vez mais considerada pela comunidade de software por oferecer uma excelente contribuio.
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
[ABNT/SC10, 1999] - ABNT/SC10, ASSOCIAO BRASILEIRA DE NORMAS TCNICAS/SUBCOMIT DE SOFTWARE. Guia para utilizao nas normas sobre avaliao de qualidade de produto de software ISO/IEC 9126 e ISO/IEC 14598. Curitiba-PR:ABNT/SC10, 1999. [Bellouquim1999] Bellouquim, A. CMM em Pequenas Organizaes: seria mesmo possvel? Developers Magfazine, Janeiro, 1999. [Boehm1981] B. W. Boehm, Software Engineering Economics, Prentice-Hall, Englewood Cliffs, NJ (1981). [Boehm1989] B. W. Boehm, Software Risk Management, IEEE Computer Society Press: Washington (1989). [Booch1998] Grady Booch et al, The Unified Modeling Language user Guide, Addisson-Wesley Object Technology Series, (1998). [Campos1992] Campos, V. C. TQC: Controle da Qualidade Total, Fundao Christiano Otooni, 7 edio, 1992. [CMMI:2000] CMMI Model Componentes Derived from CMMI SE/SW, Version 1.0 Technical report CMU/SEI-00-TR24. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2000. [Crosby1979] Crosby, P. Quality is Free - McGraw-Hill, 1979.
132
[DSouza2001] DSouza and Arlan Cameron Wills, Objects, Components, and Frameworks with UML:The Catalysis Approach, (Addison-Wesley Object Technology Series), Desmond, Francis, ISBN: 0201310120, Addison-Wesley Pub Co. [Davis1993] Davis, A. M., Software Requirements: Object, Functions & States, Englewood-Cliffs, NJ (1993). [Dod1994] Defense Science Board, Report of the Defense Science oard Task force on Acquiring Defense Software Commercially, Washington D.C., Junho, 1994. [Feingenbaum1994] Feingenbaum, A. V. Controle da Qualidade Total II, McGrawHill, 1994. [Fernandes1989] Fernandes, Aguinaldo Aragon & Kugler, J. L. C. Gerncia de Projetos de Sistemas. Rio de Janeiro, LTC, 1989. [Ford1994] N. J. Ford and M. Woodroffe, Intoducing Software Engineering, Prentice Hall Englewood Cliffs (1994). [Garg1996] Garg, P. K. Process-centered Software Engineering Environments Published by IEEE Computer Society Press, Los Alamitos, CA 90720-1264, 1996. [Gibbs1994] Softwares Chronic Crisis. Trends In Computing,W. Wayt Gibbs. (1994) [Gotel1994] O.C.Z. Gotel and A.C.W. Finkelstein, An Analysis of the Requirements Traceability Problem, pp. 94-101 in Proceedings of the First International Conference on Requirements Engineering, Colorado Springs, CO (1994). [Graham1999] Graham, I. S & Henderson-Sellers, B. & Younessi, H. The OPEN Process Specification, Addison Wesley Longman Inc. outubro, 1999. [Humphrey1989] Humphrey, W. Managing the Software Process. Addison Wesley, 1989. [IEEE1984] IEEE Std. 830 IEEE Guide to Software Requirements Specification. The Insitute of Electrical and Electronics Engineers: New York (1984). [IEEE1990] IEEE Std. 610.12 IEEE Standard Glossary of Software Engineering Terminology. The Institute of Electrical and Electronics Engineers: New York (1990).
Referncias Bibliogrficas
133
[IEEE1999a] IEEE Standards Software Engineering, Vol.2 IEEE Standards for Software Quality Assurance Plans IEEE Std.730-1997, IEEE, 1999. [IEEE1999b] IEEE Standards Software Engineering, Vol.2 IEEE Standards for Software Reviews IEEE Std.730-1997, IEEE, 1999. [ISO/IEC 9126-2] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC TR 9126-2:2003, Software engineering - Product quality - Part 2: External metrics. Geneve: ISO, 2002. [ISO/IEC 9126-3] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC TR 9126-3:2003, Software engineering - Product quality - Part 3: Internal metrics. Geneve: ISO, 2002. [ISO/IEC 9126-4] - the International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC TR 9126-4:2004, Software engineering - Product quality - Part 4: Quality in Use. Geneve: ISO, 2002 [ISO12207:1995] ISO/IEC 12207, Information Technology Software Life-Cycle Processes, International Standard Organization, Geneve,1995. [ISO12207:2000] International Standard Organization. ISO/IEC 12207 Amendement: Information Technology Amendement to ISO/IEC 12207, verso PDAM 3, novembro 2000. [ISO15504:1-9:1998] ISO/IEC TR 15504, Parts 1-9: Information Technology Software Process Assessment, 1998. [ISO9000-3:1997] ISO9000-3, Quality management and Quality Assurance Standards. [ISO9001:2000] International Standard Organization Certification for IMS Company. [Jones1996] Jones, C. Patterns of Software Systems Failure and Success. International Thomson Computer Press, Boston, Massachusetts, 1996. [Jones1999] Jones, C. Software Project Management in the 21st Century. American Programmer, Volume XI, N. 2, fevereiro 1999.
134
[Kan1995] Kan, Stephen Metrics and Models en Software Quality Engineering Addison-Wesley, Reading, 1995. [Kruchten1998] Philippe Kruchten, The Rational Unified Process: an Introduction, Addisson-Wesley Object Technology Series, (1998). [Kuvaja1993] Kuvaja, P. et all BOOTSTRAP: Europes assessment method, IEEE Software, vol 10, N. 3, 1993. [Kuvaja1994] Kuvaja, P. et al. Software Process Assessment & Improvement - The BOOTSTRAP Approach, Blackwell, 1994. [Lubars1993] M. Lubars, C. Potts, and C. Richter, A Review of the State of Practice in Requirements Modeling, pp. 2-14 in Proceedings of the IEEE International Symposium on Requirements Engineering, San Diego, CA (January, 1993) [MacFeeley1999] McFeeley, Bob IDEALSM: A Users Guide for Software Process Improvement Software Technology Conference, 1999. (www.sei.cmu.edu/ideal) [Machado2001] Machado, C. A. & Burnett, R. C. Gerncia de Projetos na Engenharia de Software em Relao as Prticas do PMBOK. XII CITS - Conferncia Internacional de Tecnologia de Software. Junho, 2001. [Maidantchik1999] Maidantchik, C. & Rocha, A R. C. & Xexeo, G. B Software Process Standardization for Distributed Working Groups. In Proceedings of the 4 th IEEE International Software Engineering Standards Symposioum, Curitiba, Paran, Brasil, maio de 1999. [Meyer1988] Meyer, B., Object-Oriented Software Construction, Prentice Hall, (1988). [NBR ISO/IEC 9126-1] - ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. NBR ISO/IEC 9126-1:2003 - Engenharia de software - Qualidade de produto - Parte 1: Modelo de qualidade. Rio de Janeiro: ABNT, 2003. [Paulk1993] Paulk, M. & Curtis, B. & Crissis, M & Weber, C. Capability Maturity Model for Software, Version 1.1, Technical report CMU/SEI-93-TR-24, Software Engineering Institute, Pittsburgh, fevereiro, 1993.
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). [SEI2002b] Sei, Web Site do software Engineering Institute http://www.sei.cmu.edu/ (CMMI nodels available at www.sei.cmu.edu/cmmm). SEI,
SEI,
136
[SEI2002c] Sei, Web Site do software Engineering Institute http://www.sei.cmu.edu/ (CMMI nodels available at www.sei.cmu.edu/cmmm). [Spivey1989] J. M. Spivey, The Z Notation, Prentice Hall, (1989). [Standish2001] The Standish Group, Extreme www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf, em outubro de 2004.
SEI,
Chaos, acessado
[Stokes1994] D. A. Stokes, Requirements Analysis, chapter 16 of Software Engineerings Handbook, Ed. John Mcdermid, Butterworth Heinemann (1994). [Vigder1994] Vigder, M. R. & Kark, A. W. Software Cost Estimation and Control. National Research Council Canada. Institute for Information Technology, 1994. http://wwwsel.iit.nrc.ca/abstracts/NRC37116.abs, acessado em dezembro de 2001. [Walker1997] Walker, E. Managing Successful Iterative Development Projects: A Seminar on Software Best Practices, version 2.3, Rational Software Corporation, Menlo Park, California, 1997. [Wang1999] Randolph Y. Wang1999, David A. Patterson, and Thomas E. Anderson. Virtual log based file systems for a programmable disk. [Weber1999] Weber, K. C Qualidade e Produtividade em Software. 3 ed. So Paulo: Makron Books do Brasil Ltda, 1999. [Wieger2002] Wieger, Karl Peer Reviews in Software Addison-Wesley, Boston, 2002.
ANEXO A PADRO DE CODIFICAO JAVA
1.1 Arquivos fonte Java

Cada arquivo fonte Java contm uma classe pblica ou uma interface. Quando classes privadas e interfaces so associadas a uma classe pblica, voc poder coloc-las em um mesmo arquivo fonte. A classe pblica ou a interface dever ser a primeira no arquivo. Arquivos fontes Java possuem a seguinte ordem:

Comentrios iniciais (opcional); Instrues (statements) de pacotes (package) e importaes (import); Declarao de classes e interfaces. Exemplo: //comentrios iniciais (opcional) /* * PesquisaCEP.ajva * * Verso 1.0 * * Data: 01/05/2004 * * Copyright(c) 2006 - UFLA */
//pacote ao qual a classe pertence
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 { ... }
1.2 Comentrios Iniciais (opcional)

Todos os arquivos fontes devero comear com um comentrio c-style (padro C) que lista o nome da classe, verso e notas de direitos autorais.
/* * Classname * * Version information * * Date * * Copyright notice /*
Anexo A - Padro de Codificao JAVA
139
1.3 Package e Import

A primeira linha sem-comentrios da maioria dos arquivos fontes Java um statement de package. Depois disso, statements de import podem seguir. Por exemplo:
package java.awt; import java.awt.peer. CanvasPeer;
1.4 Declarao de Classes e Interfaces

A tabela seguinte descreve as etapas (partes) da declarao de uma classe ou interface, na ordem em que devero aparecer.
declarao Partes da declarao de classes e interface

1 Comentrios de Documentao (/**..*/)
Observaes
Veja Comentrios de documentao para informaes sobre como usar este comentrio
2 Declarao de Classe ou Interface. 3 Implementao da classe / interface, comentrio (/* ... */), se necessrio. Este comentrio dever conter qualquer informao sobre a classe ou interface, que no seja apropriado para documentao. 4 Variveis Estticas (static). Primeiramente as variveis
140
declarao Partes da declarao de classes e interface
Observaes
pblicas (public) da classe, ento as protegidas (protected) e finalmente as privadas (private).
5 Instncia de Variveis
Primeiro a public, ento a
protected e finalmente a private;

6 Construtores 7 Mtodos Os mtodos devem ser agrupados pela funcionalidade de preferncia pelo escopo ou acessibilidade. Por exemplo, um mtodo privado de uma classe pode estar entre 2 duas instncias de mtodos pblicos. O objetivo tornar a leitura e o entendimento do cdigo algo simples. Nota: ver exemplo no item 9.
2. Endentao
Quatro espaos devem ser utilizados como unidade de endentao.
141
Nota: Recomenda-se utilizar a opo Format do Eclipse ou Reformat Code do NetBeans para facilitar a estruturao e organizao apresentadas em todo o item 2.
2.1 Tamanho de Linha

Evite linhas maiores que 80 caracteres, geralmente no mais que 70 caracteres.
2.2 Wrapping Lines

Quando uma expresso no se ajusta somente em uma linha, quebre-a de acordo com estes princpios:

Quebra depois de uma vrgula; Quebra antes de um operador; 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:
someMethod(longExpression1, longExpression2, longExpression3, longExpression4, longExpression5);
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.
longName1 = longName2 * (longName3 + longName4 longName5) + 4 * longName6; // recomendado
longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longName6; // evitar
142
Os dois exemplos, a seguir, so de endentao para declaraes de mtodos. O primeiro o caso convencional. No segundo exemplo poderia ser deslocada a segunda e terceira linha para a direita, ao invs de endentar somente com 8 espaos.
// ENDENTAO CONVENCIONAL someMethod(int anArg, Object anotherArg, String yetAnotherArg, Object andStillAnother) { ... }
// ENDENTAO COM 8 ESPAS PARA EVITAR ENDETAES PROFUNDAS private static synchronized horkingLongMethodName(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:
// NO USE ESTA ENDENTAO if ((condition1 && condition2) || (condition3 && condition4)
143
|| !(condition5 && condition6)) { doSomethingAboutIt(); }
// bad wraps // torna esta linha fcil de perder-se
// USE ESTA ENDENTAO if ((condition1 && condition2) || (condition3 && condition4) || !(condition5 && condition6)) { doSomethingAboutIt(); }
// OU USE ESTA if ((condition1 && condition2) || (condition3 && condition4) || !(condition5 && condition6)) { doSomethingAboutIt(); }
Aqui so apresentadas trs maneiras para formatar operadores ternrios:
alpha = (aLongBooleanExpression) ? beta : gamma;
144
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.
3.1 Formatos de implementao de comentrios

Programas podem ter 4 estilos de comentrios de implementao: bloco, linhasimples, trailing e final de linha.
145
3.1.1 Comentrios de bloco

Comentrios de bloco so usados para prover descries de arquivos, mtodos, estrutura de dados e algoritmos. Comentrios de bloco podem ser usados no incio de cada arquivo e antes de cada mtodo. Eles podem, tambm, ser usados em outros lugares, como dentro dos mtodos. Comentrios de bloco dentro de um funo ou mtodo devem ser endentados no mesmo nvel do cdigo. Um comentrio de bloco deve ser precedido por uma linha em branco para definilo como fora do cdigo. /* * Aqui um comentrio de bloco. */
3.1.2 Comentrio de linha simples

Comentrios curtos podem aparecer em uma linha simples endentada no nvel do cdigo que ela segue. Se um comentrio no puder ser escrito como uma linha simples, este dever seguir o formato de um comentrio de bloco. (ver item 3.1.1). Um comentrio de linha simples dever ser precedido de uma linha em branco. Aqui um exemplo de um comentrio de linha simples dentro de um cdigo Java.
If (condition) {
/* aqui o comentrio para condio */ ... }
3.1.3 Comentrios Trailing

Comentrios muito curtos podem aparecer na mesma linha de cdigo, mas dever estar longe o suficiente para separ-los de outras instrues. Se mais de um comentrio curto aparecer em um bloco de cdigo, todos eles devero estar usando a mesma endentao ou tabulao. Aqui um exemplo de comentrio trailing em um cdigo Java:
146
If (a == 2) return TRUE; } else { return isPrime(a); } /* trabalha somente para impar */ /* caso especial */
3.1.4 Comentrios de final de linha

O delimitador de comentrio // pode ser utilizado para comentar uma linha de cdigo toda ou parte dela, bem como excluir uma parte do cdigo de sua seo. A seguir, exemplos dos trs estilos:
If (foo > 1) { // coloque o comentrio aqui. ... } else { return false; } // Explique a funcionalidade.
//if (bar > 1) { // // // //} //else { //coloque o comentrio aqui. ...
147
return false; //} Nota: no comentar um cdigo se ele no usado.
3.2 Comentrios de documentao

Comentrios doc (comentrios de documentao) descrevem classes Java, interfaces, construtores, mtodos e atributos. Cada comentrio doc definido dentre os delimitadores /** . . . */ , com um comentrio por classe, interface. Este comentrio dever aparecer antes da declarao:
/** * 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; melhor que
// tamanho da tabela
int level, size; No coloque diferentes tipos de dados na mesma linha. Exemplo:
int foo, fooarray[]; Nota: Os exemplos acima usam um espao entre o tipo e o identificador. Outra alternativa aceitvel o uso de tabs (tabulaes), exemplo: int int Object level; size; currentEntry; // qual o nvel // tamanho da tabela // tabela de entrada de dados
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.
4.3 Placement (localizao)

Coloque declaraes somente nos incio dos blocos. (Um bloco definido pelo cdigo que est entre as chaves { e }). No espere a varivel ser usada a primeira vez para declar-la ou inicializ-la; isto pode confundir um programador descuidado.
void myMethod() { int int1 = 0; // No inicio do bloco do mtodo.
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.
For (int i = 0; i < maxLoops; i++) { . . . } Evite declaraes locais que escondem declaraes de nveis maiores. Por exemplo, no declare o mesmo nome de varivel em um bloco interno: int count; ... myMethod() { if (condition) { int count; ... } ... } // evitar!
4.4 Declaraes de classes e interfaces

Quando estiver codificando classes e interfaces Java, as seguintes regras de formatao devero ser seguidas:
Sem espaos entre um mtodo e o parnteses ( que inicia a lista de parmetros; A chave { aparece no final da mesma linha da declarao da instruo; A chave } aparece no final do bloco da instruo endentada de acordo a instruo, exceto no caso em que instruo nula, assim a chave fecha logo aps a que foi aberta {.
Class Sample extends Object {
150
int ivar1; int ivar2;
Sample (int i, int j) { ivar1 = i; ivar2 = j; } int emptyMethod() {} ... }
Mtodos so separados por uma linha em branco.
5. Statements (instrues)
5.1 Instrues simples
Cada linha dever conter no mximo uma instruo. Exemplo: argv++; argc++; argv++; argc --; // Correto // Correto // Evitar
5.2 Instrues compostas

Instrues compostas so instrues que possuem uma lista de instrues internas entre chaves { instrues }. Veja os exemplos nas prximas sesses.
Instrues internas devero ser endentadas um ou mais nveis que as instrues compostas;
151
A chave aberta { dever estar no final da linha, onde inicia-se a instruo composta; a chave fechada } dever comear em uma linha endentada com o inicio da instruo composta; As chaves so usadas ao redor de todas as instrues, exceto para instrues simples, quando elas so partes de uma estrutura de controle, tais como uma instruo IF-ELSE or FOR.
5.3 Instruo Return

A instruo return com um valor no dever usar parnteses, ao menos que este valor torne-se mais claro com o uso de parnteses.
return;
return myDisk.Size();
return (size ? size : defaultSize);
5.4 Instrues if, if-else, if else-if else
A instruo if-else dever utilizar uma das seguintes formas:
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;
// evite, omitir as chaves nestes casos.
5.5 Instruo for

Uma instruo for dever ter a seguinte forma:
for (inicializao; condio; atualizao) { statements; }
153
Quando utilizar o operador vrgula na clusula de inicializao ou atualizao de uma instruo for, evite usar mais de 3 variveis. Se necessrio, use instrues em separado antes do lao for (para inicializao da clusula) ou no final do loop (para a clusula de atualizao).
5.6 Instruo while

Uma Instruo while dever ter a seguinte forma:
while (condition) { statements; }
Uma instruo while vazia dever ter a seguinte forma:
while (condition)
5.7 Instruo do-while

Uma instruo do-while dever ter a seguinte forma:
do { statements; } while (condition);
154
5.8 Instruo switch

Uma instruo switch dever ter a seguinte forma:
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.
5.9 Instrues try-catch

Uma instruo try-catch dever ter o seguinte formato:
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;
Entre a as declaraes de classes e interfaces.
Uma linha em branco dever sempre ser usada nas seguintes circunstncias:
Entre mtodos;
156
Entre variveis locais em um mtodo e sua primeira declarao; Antes de um bloco ou de um comentrio simples; Entre sees lgicas dentro de um mtodo para facilitar a leitura.
6.2 Espao em branco

Espaos em branco devero ser usados nas seguintes circunstncias:
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; Todos os operadores binrios exceto . devero ser separados de seus operandos por espaos. Espaos em branco nunca devero aparecer entre operadores unrios, como o operador - ou o operador de incremento ++, e decremento . Exemplos: a += c + d; a = (a + b) / (c * d);
while (d++ = s++) { n++; }
157
prints(size is + foo + \n)
As expresses dentro de uma instruo for devero ser separadas por espaos em branco. Exemplo:
For (expr1; expr2; expr3)
Operadores de cast devero ser seguidos por um espao em branco. Exemplo:
myMethod((byte) aNum, (Object) x); myMethod((int) (cp + 5), ((int) (I + 3)) + 1);

Mod.01.MPS Engenharia&amp;QualidadeSoftware v.28.09.06

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mod.01.MPS Engenharia&amp;QualidadeSoftware v.28.09.06

Enviado por

Direitos autorais:

Formatos disponíveis

CURSO DE PS-GRADUAO LATO SENSU (ESPECIALIZAO) DISTNCIA MELHORIA DE PROCESSO DE SOFTWARE

INTRODUO ENGENHARIA DE SOFTWARE E QUALIDADE DE SOFTWARE

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Figura 2.1: Diferenas do produto de software

O Produto de Software e a Organizao de Desenvolvimento

Ncleo de Processamento de Dados

Figura 2.2: Exemplo da estrutura de um NPD

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

O Produto de Software e a Organizao de Desenvolvimento

Pequeno centro de desenvolvimento

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

designer, gerncia de marketing, gerncia administrativa, Engenharia

Figura 2.4: Organograma de uma fbrica de software

O Produto de Software e a Organizao de Desenvolvimento

Centro de desenvolvimento de software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Modelagem do sistema de processo

Modelo de avaliao do processo

Modelo de melhoria do processo

Subsistema do processo organizacional

Subsistema do processo de desenvolvimento

Subsistema do processo de gerenciamento

Modelo de capacidade do processo

Mtodo de determinao da capacidade do processo

Modelo de melhoria baseado em avaliao

Modelo de melhoria baseado em Benchmark

Escala do desempenho da pratica

Escala da capacidade do processo

Escopo da capacidade do processo

Determinao da capacidade do processo

Agregao de capacidade do projeto

Agregao da capacidade da organizao

O Produto de Software e a Organizao de Desenvolvimento

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Modelos de Ciclo de Vida do Processo de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Modelos de Ciclo de Vida do Processo de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Modelos de Ciclo de Vida do Processo de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Desenvolvimento Espiral; Desenvolvimento Incremental. 3.5.1 O Modelo de Desenvolvimento Espiral

Figura 3.6: O modelo espiral

Modelos de Ciclo de Vida do Processo de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Planejamento e Gerenciamento de Projetos de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Figura 4.1: Estrutura de um plano de projeto

Planejamento e Gerenciamento de Projetos de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Planejamento e Gerenciamento de Projetos de Software

Requisitos identificados (necessidades) e requisitos no identificados (expectativas).

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Planejamento e Gerenciamento de Projetos de Software

Gerncia de Recursos Humanos

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Planejamento e Gerenciamento de Projetos de Software

EDITORA - UFLA/FAEPE Introduo Engenharia de Software e Qualidade de Software

Planejamento e Gerenciamento de Projetos de Software

Mod.01.MPS Engenharia&QualidadeSoftware v.28.09.06

Mod.01.MPS Engenharia&QualidadeSoftware v.28.09.06