ENGENHARIA DE SOFTWARE

Preencha a ficha de cadastro no final deste livro e receba gratuitamente informaes sobre os lanamentos e as promoes da Editora Campus. Consulte tambm nosso catlogo completo e ltimos lanamentos em www.campus.com.br James E. Peters / Witold Pedrycz Teoria e Prtica Traduo Ana Patrcia Machado de Pinho Garcia Reviso Tcnica Jussara Pimenta Matos Departamento de Engenharia de Computao e Sistemas Digitais da Escola Politcnica da USP e Consultora em Engenharia de Software CAMPUS Do original: An Engineering aproach Traduo autorizada da edio publicada por Johrr Wiley & Sons Copyright 2000 by John Wiley & Sons, mc. 2001, Editora Campus Ltda. Todos os direitos reservados e protegidos pela Lei 5.988 de 14/12/73. Nenhuma parte deste livro, sem autorizao prvia por escrito da editora, poder ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer outros. Editorao Eletrnica RioTexto Reviso Grfica Roberto Mauro Facce Projeto Grfico Editora Campus Ltda. A Qualidade da Informao. Rua Sete de Setembro, 111 - 16 andar 20050-002 Rio de Janeiro RJ Brasil Telefone: (21) 3970-9300 FAX (21) 2507-1 991 E-mail: info @campus.com.br

ISBN: 85-352-0746-5 (Edio original ISBN: 0-471-18964-2) CIP-Brasil. Catalogao-na-fonte. Sindicato Nacional dos Editores de Livros, RJ P575e Petere, James F. Engenharia de software / James F. Peters, Witold Pedrycz traduo de ana Patricia Garcia. - Rio de Janeiro: Campus, 2001 Traduo de: An engineering approach ISBN 85-352-0746-5 1. Engenharia de software. 1. Pedrycz, Witold, 1953-. II. Ttulo. 00-1652. CDD - 005.1 CDU - 004.4 1 0102030405 5 4 3 2 UNIVERSIDADE ESTAdO DE L BIBLIOTECAEJL.: Z-Ss7 1 Em: o4IiioH Prefcio

Um dos elementos mais relevantes para se dar incio revoluo na programao feita por uma s pessoa foi o desenvolvimento de um framework bsico que serve a propsitos gerais, por sua simplicidade. - DAVID HARREL, 1992 O mundo da engenharia de software vem se desenvolvendo rapidamente. A engenharia de software fornece uma grande variedade de frameworks, mtodos e tecnologias que auxiliam as atividades comumente encontradas em projetos de software. Tais atividades tendem a se sobrepor de forma muito semelhante s mos que se desenham na gravura de M. C. Escher, denominada Drawing Hands. Cada atividade fornece um novo nvel de detalhes e refinamento a um projeto de software que, por sua vez, faz parte de um ciclo anterior do seu desenvolvimento. Da mesma forma, cada uma das mos na gravura de Escher aprimora e acrescenta detalhes a um trao feito anteriormente. Perceba, tambm, que uma parte do brao que est sendo desenhado no aparece. Aquilo que vemos no desenho sugere aquilo que no conseguimos ver. Do mesmo modo, quando foram descobertas as vantagens da ocultao dos detalhes em um desenho de software, o software desenvolvido tornou-se mais compreensvel. A idia de se esconderem informaes foi apresentada por David Parnas em 1972. Essa idia concretizada no projeto de software atravs de uma estrutura modular. De fato, o truque do artista de sugerir o que est por trs da parte visvel levado para o projeto de software. A parte visvel de uma arquitetura de software projetada de forma a sugerir o que est subjacente a

ela. A cada ano so freqentes as novas verses de produtos de software existentes, bem como verses de novos produtos e tecnologias de software. O lanamento de novas linguagens de programao como Java, navegadores da Web, linguagens markup e ambientes de desenvolvimento integrados visualmente mudou a nossa viso do software e sua funo na sociedade contempornea. Podemos tambm afirmar que a prpria engenharia de software est amadurecendo, sendo cada vez mais vista como a aplicao dos mtodos e tecnologias da engenharia para planejar, especificar, desenhar, implementar, validar, testar, medir, manter e aprimorar os sistemas de software. Essa evoluo aparece como uma resposta s sugestes dos interessados no projeto, s mudanas de requisitos, aos novos conhecimentos sobre o comportamento e o ambiente do software e necessidade de se otimizar o seu desempenho. v Prefcio VII O que torna este livro diferente de outros trabalhos disponveis atualmente no mercado? Na nossa opinio, h diversas caractersticas importantes: Uma introduo engenharia de software cuidadosamente balanceada e extremamente coerente, que enfatiza os aspectos de anlise e projeto da tecnologia, igualmente importantes. Aspecto completo do livro. Organizao bem-elaborada do material, proporcionando fcil utilizao. Uma forte nfase no projeto ao longo de todo o texto. Uma extensa gama de exerccios ao final de cada captulo. Diversas referncias a fontes de informaes atuais da Web so feitas no livro. Grficos de estado utilizados na seleo de arquiteturas e projeto de software. Aplicaes especficas (como o controle de trfego areo em Java). A modularidade e o encapsulamento de informaes de David Parnas so temas recorrentes do livro. Apresentao de tcnicas grficas teis no gerenciamento e controle do desenvolvimento de software. o que e o como da engenharia de software. Abordagem sala limpa, que tem bom desempenho no projeto de software. Glossrio detalhado de termos tcnicos e siglas. A arquitetura ETVXM de Humphrey para o projeto de processos especficos de projeto. O paradigma de desenho tendo em vista a manuteno. Exemplos com C++ + e Java. A seguir, apresentamos uma breve descrio de cada captulo para enfatizar os principais tpicos e fornecer ao leitor uma viso melhor dos assuntos tratados no livro. O Captulo 1 fornece uma viso geral de algumas caractersticas bsicas da abordagem de engenharia no desenvolvimento de software. Esse captulo chama a ateno para o problema conceitual de especificar, projetar e testar o software. Apresentamos tambm o uso de formalismos visuais e a idia de um

framework bsico, assim chamado por sua simplicidade, para a soluo desse problema. O Captulo 2 analisa o processo de desenvolvimento do software, a evoluo dos componentes de um sistema de software durante seu ciclo de vida e diversos modelos de ciclos de vida de software. A arquitetura de processo ETVXM de Humphrey, o sistema de feedback, o modelo win win de Boehm e os modelos sincronizar e estabilizar da Microsoft esto includos nesse captulo. O Captulo 3 fornece uma viso geral de como gerenciar e controlar os documentos do projeto. Trs ferramentas do GCS so apresentadas. O Captulo 4 ilustra o planejamento de um projeto onde se desenvolveu um programa de treinamento para controladores de trfego areo (tCTA). O Captulo 5 lida com a engenharia de requisitos atravs de duas tarefas bsicas: a anlise do Problema, que leva a uma compreenso da base de um sistema de software, e a preparao de uma especificao de requisitos de software.

VI ENGENHARIA DE SOFTWARE O Captulo 6 ilustra o desenvolvimento dos requisitos de um sistema de tCTA. As descries do processo so dadas atravs de diagramas de fluxo de dados e grficos de estado. O Captulo 7 investiga possveis arquiteturas e elementos arquitetnicos que possam ser usados no desenho de um sistema de software. O Captulo 8 apresenta mtodos para a elaborao de um projeto de software durante a transio do projeto para um cdigo cem por cento correto. O Captulo 9 mostra a elaborao do projeto no contexto da computao mvel e o desenvolvimento de programas em Java. O Captulo 10 une tcnicas de planejamento, especificao, projeto e verificao de um sistema de tCTA. Esse captulo fornece uma metodologia para a escolha da arquitetura de software. Tambm fornecida uma amostra de cdigo de Java para partes de um sistema de tCTA. O Captulo 11 considera algumas abordagens para a validao de um projeto de software e sua anlise de risco. O Captulo 12 apresenta abordagens para a testagem de produtos de software. O Captulo 13 concentra-se em diversas maneiras de se medir a complexidade dos sistemas de software e de se quantificarem seus efeitos no projeto, verificao e manuteno do software. O Captulo 14 engloba diversos mtodos de estimativa de custos: o modelo de pontos de funo, os modelos COCOMO e o mtodo de Delphi. O Captulo 15 apresenta mtodos para se avaliar a confiabilidade e a disponibilidade dos produtos de software. O Captulo 16 considera os fatores humanos no desenvolvimento de software, concentrando-se igualmente nos pontos de vista do usurio e do desenvolvedor. O Captulo 17 examina a reengenharia, sua metodologia e seus aspectos

financeiros. O Captulo 18 retoma a preocupao original da engenharia de software: o projeto tendo em vista a manutenibilidade. Um mapa esquemtico dos possveis caminhos a traar neste livro mostrado na Figura 0.1. O material do livro pode ser utilizado de diversas formas diferentes dependendo do pblico e de seus objetivos. Estamos convencidos de que os tpicos abordados atendero a um grande universo de leitores. Na Figura 0.1 a seguir, esboamos diversas opes. Seja qual for a sua escolha, procure no se deixar influenciar. Voc ainda poder escolher o seu prprio caminho e utilizar o material da forma que melhor atenda s suas necessidades. O livro pode ser igualmente til para alunos novatos e avanados, bem como para profissionais de engenharia de software. Pode-se achar o material relevante em um novo currculo de engenharia de software, onde o livro possa servir como texto introdutrio e como material de referncia em cursos mais especializados, como qualidade de software, confiabilidade de software, medidas de software, arquiteturas de software, testes de software e assim por diante. Prefcio IX Alunos de graduao iniciantes. Podemos visualizar dois tipos de cursos. Um curso breve, de um perodo, que seria essencialmente uma introduo engenharia de software pode ser preparado com base nos Captulos 1 a 3, 5 a 8 e 11 a 12 (caminho O da Figura 0.1). Tambm de interesse nesse contexto o projeto de software no caminho 2 da Figura 0.1. Alunos de graduao avanados, O curso mais longo, de dois perodos, poderia iniciar com o material discutido no Captulo 1. A segunda parte do curso seria desenvolvida em torno de idias de qualidade, medidas, estimativa de custo, confiabilidade, reengenharia e manuteno de software (caminho 2 da Figura 0.1). Profissionais experientes e pesquisadores. Os profissionais experientes e os pesquisadores podem utilizar este livro de uma forma diferente, simplesmente folheando rapidamente a parte mais bsica e concentrando-se nos tpicos mais avanados. Os caminhos 1, 2 e 3 da Figura 0.1 poderiam ser de particular interesse no destaque de algumas tendncias recentes da engenharia de software. Gostaramos de agradecer aos sofridos alunos do curso de graduao da Universidade de Manitoba, que utilizaram rascunhos deste livro nos ltimos anos. Muitos problemas, exemplos, sugestes, explicaes e processos surgiram de discusses com esses alunos. Alm disso, gostaramos de agradecer s seguintes pessoas da Faculdade de Engenharia da Universidade de Manitoba:

Ewa Pedrycz, por ajudar a desenvolver a pgina da Web deste livro, Sheela Ramanna por seus insights e sugestes, bem como por ajudar a editar e corrigir todo o livro; os tcnicos Gord Toole, Figura 0.1 Mapa Esquemtico X ENGENHARIA DE SOFTWARE Ken Biegan, Ai McKay, Mount First, Ken Podaima e Guy Jonatschick por sua ajuda em gerenciar os sistemas usados no desenvolvimento desses materiais e Steve Onyshko, Rob Menzies e Donald Shields por sua ajuda em criar um ambiente que possibilitou a elaborao deste livro. Tambm gostaramos de agradecer profundamente s vrias discusses e interaes com Andrzej Skowron do Instituto de Matemtica da Universidade de Varsvia, Polnia; Zbigniew Suraj do Instituto de Matemtica, University Pedagogical, Rzesqw, Polnia; Witold Kinsner, Steve Onyshko, Howard Card, Bob McCleod, Dave Blight, Rob Menzies e Mirek Pawlak do Departamento ECE da Universidade de Manitoba; Dano Maravali e Luis Baumela da Universidade Politcnica de Madri; David Schmidt, William Hankley, Dave Gustafson, Austin Melton, Rod Howell, Elizabeth Unger, Maria Zamfir e Virg Wallentine da Universidade Estadual do Kansas; Richard McBride da Universidade de Dakota do Sul; B.V. Saroja da Universidade de Osmnia, India; Keith Pierce da Universidade de MinnesotaDuluth; Verner Hogatt, John Dutton e Gareth Williams da Universidade Estadual da Califrnia em San Jose; Bob Dumonceaux, Chuck Lavine, Jerry Lenz, Melchior Freund, Gordon Tavis e Noreen Herzfeld-Gass da St. Johns University; Leon Schilmoeler da 3M Corporation; Hamid Sailam da Universidade Estadual de Mankato; Paul Willis e John Kelly do Jet Propuision Laboratory Caltech; Hal Berghel, Roy Fuiler e Greg Starling da Universidade de Arkansas; E. Roventa da Universidade de York; K. Hirota do Instituto de Tecnologia do Japo; T. Furuhashi da Universidade de Nagoya, Japo; Shusaku Tsumoto da Universidade Mdica e Dentria de Tquio e Fernando Gomide da Universidade de Campinas. Gostaramos de expressar nossa gratido aos revisores deste livro por seus vrios comentrios e sugestes construtivas e teis. Somos muito gratos ao Conselho de Pesquisa em Cincias Naturais e Engenharia do Canad (Natural Sciences and Engineering Research Council of Canada, NSERC) pelos recursos financeiros recebidos, a John Wley & Sons, e ao Comit de Bolsas de Pesquisa da Universidade de Manitoba, que apoiou o desenvolvimento de material para este livro. Tambm gostaramos de agradecer a Regina Brooks e Bili Zobrist da John Wiley & Sons em Nova York por sua ajuda no desenvolvimento deste livro. James Peters Winnipeg, Manitoba Witold Pedrycz Edmonton, Alberta Sumrio Viso do Terreno da Engenharia de Software 1

1.1 INTRODUO 2 1.2 AS PEPITAS DA ENGENHARIA DE SOFTWARE: OS COMPONENTES 3 1.3 UMA ABORDAGEM DE ENGENHARIA 4 1.4 PROBLEMAS NO DESENVOLVIMENTO DO SOFTWARE 5 1.5 MEDINDO A QUALIDADE DO SOFTWARE 9 1.6 COMPRE, NO FAA 14 1.7 DESENVOLVIMENTO INCREMENTAL 14 1.8 MODELO DE MATURIDADE DE CAPACIDADE 18 1.9 PADRES DO SOFTWARE 23 1.10 RESUMO 24 1.11 EXERCCIOS 25 1.12 REFERNCIAS 27 2 O Processo de Software 29 2.1 INTRODUO 29 2.2 ARQUITETURA ETVXM 31 2.3 PERFIS DE UM PROCESSO DE SOFTWARE 33 2.4 PROCESSO DE PR-DESENVOLVIMENTO 38 2.5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 39 2.6 MODELOS DE CICLO DE VIDA DE SOFTWARE 40 2.7 MODELO SINCRONIZAR E ESTABILIZAR 52 2.8. MODELO DE PROCESSO SALA LIMPA 53 2.9 ESPECIALIZANDO MODELOS DE PROCESSO DE SOFTWARE UNIVERSAIS 58 2.10 EXEMPLO: MODELOS DE NVEL MUNDIAL E ATMICO 59 2.11 RESUMO 62 XI XII ENGENHARIA DE SOFTWARE 2.12 EXERCCIOS 63 2.13 REFERNCIAS 65 3 Gerenciamento de Configurao de Software 67 3.1 INTRODUO 68 3.2 IDENTIFICAO DA CONFIGURAO DE SOFTWARE 69 3.3 CONTROLE DE CONFIGURAO DE SOFTWARE 69 3.4 AUDITORIA DE CONFIGURAO DE SOFTWARE 71 3.5 RELATRIO SOBRE O ESTADO DA CONFIGURAO DE SOFTWARE 72 3.6 DINMICA DO GCS 72 3.7 FERRAMENTAS DO GCS 72 3.8 FERRAMENTAS PARA A AUDITORIA DO GCS 78 3.9 RESUMO 80 3.10 EXERCCIOS 80 3.11 REFERNCIAS 81 4 Projeto de Software: Planejamento 83 4.1 INTRODUO 83 4.2 CONSIDERAES INICIAIS 84

4.3 ESTUDO DE CASO 88 4.4 MODELOS DE NVEL ATMICO DO TTA 91 4.5 RESUMO 97 4.6 EXERCCIOS 97 4.7 REFERNCIAS 100 5 Engenharia de Requisitos 101 5.1 INTRODUO 101 5.2 ANLISE DE PROBLEMAS 103 5.3 ESPECIFICAO DE REQUISITOS DE SOFTWARE 103 5.4 EXEMPLO: SISTEMA DE NAVEGAO DE VECULO 108 5.5 ANLISE DE REQUISITOS ORIENTADA A OBJETOS 109 5.6 ANLISE ORIENTADA A FUNES 114 5.7 ESPECIFICAO DO PROCESSO 117 5.8 MTODO DE DESENVOLVIMENTO DE SISTEMA JACKSON 118 5.9 SDL 120 5.10 SADT 120 5.11 DARTS 122 Sumrio XIII 5.12 CODARTS 124 5.13 ABORDAGEM ORIENTADA A ESTADOS PARA ESPECIFICAO COMPORTAMENTAL 125 5.14 ABORDAGEM DE MTODOS FORMAIS PARA ESPECIFICAO 132 5.15 RECURSOS NO-COMPORTAM ENTAIS DO ERS 144 5.16 MEDIO DA QUALIDADE DOS REQUISITOS 150 5.17 REQUISITO DE RASTREABILIDADE BIDIRECIONAL 151 5.18 RESUMO 152 5.19 EXERCCIOS 153 5.20 REFERNCIAS 157 6 Projeto de Software: Requisitos 161 6.1 INTRODUO 161 6.2 ESTUDO DE CASO 163 6.3 ERS-3 VERSO BASEADA NO ESTADO 173 6.4 RESUMO 176 6.5 EXERCCIOS 176 6.6 REFERNCIAS 178 7 Projeto de software: Arquiteturas 179 7.1 INTRODUO 179 7.2 ARQUITETURAS DE SOFTWARE 181 7.3 ESTILOS ARQUITETNICOS 183 7.4 ARQUITETURAS DE FLUXO DE DADOS 184 7.5 ARQUITETURAS DE CHAMADA E RETORNO 187 7.6 ARQUITETURA DE INDEPENDENTES DO PROCESSOS 191 7.7 ARQUITETURAS DE MQUINA VIRTUAL 198 7.8 ARQUITETURAS DE REPOSITRIOS 204 7.9 ARQUITETURAS DE DOMNIO ESPECFICO 207

7.10 RESUMO 213 7.11 EXERCCIOS 213 7.12 REFERNCIAS 218 8 Elaborao do Projeto 219 8.1 INTRODUO 220 8.2 ABORDAGEM INCREMENTAL ELABORAO DO PROJETO 222 8.3 ELABORAO DE PROJETO COM ESTRUTURAS DE OBJETOS 229 XIV ENGENHARIA DE SOFTWARE 8.4 EXEMPLO: SISTEMA DE CONTROLE DE ROB 242 8.5 RESUMO 252 8.6 EXERCCIOS 253 8.7 REFERNCIAS 261 9 Elaborao de Projeto: Computao Mvel 263 9.1 INTRODUO 263 9.2 ELABORAO DE PROJETO: COMPUTAO MVEL 265 9.3 EXEMPLO: ELABORAO DE PROJETO EM JAVA 275 9.4 RESUMO 289 9.5 EXERCCIOS 290 9.6 REFERNCIAS 302 10 Projeto de Software: Projeto 303 10.1 INTRODUO 304 10.2 CONSIDERAES INICIAIS 304 10.3 PROJETO INCREMENTAL DO SCANNER DA AERONAVE 314 10.4 CRIAO DE PROTTIPOS DE MOSTRADORES DE AERONAVE 315 10.5 IMPLEMENTAO DE PROJETO ARQUITETNICOS 322 10.6 PROJETO TENDO EM MENTE A MANUTENO 323 10.7 INCREMENTO COM ARQUITETURA DE PIPELINE PARCIAL 323 10.8 RESUMO 332 10.9 EXERCCIOS 333 10.10 REFERNCIAS 336 11 Projeto de software: Validao e Anlise de Riscos 337 11.1 INTRODUO 338 11.2 VALIDAO DO PROJETO DE SOFTWARE 338 11.3 FUNDAMENTOS PARA A AVALIAO DO DPS 346 11.4 ENGENHARIA DE RISCOS: GESTO E ANLISE 349 11.5 DESCRIO DAS INTERFACES DE SOFTWARE 353 11.6 ALGORITMOS 355 11.7 PROJETO DE SOFTWARE DETALHADO 361 11.8 RESUMO 365 11.9 EXERCCIOS 366 11.10 REFERNCIAS 375

Sumrio XV 12 Teste de Software 377 12.1 INTRODUO 378 12.2 TAXONOMIA DE TESTE DE SOFTWARE 379 12.3 NVEIS DE TESTE DE SOFTWARE 383 12.4 ATIVIDADES DE TESTE 384 12.5 TIPOS DE TESTES DE SOFTWARE 385 12.6 TESTE DE CAIXA PRETA 386 12.6.2 TESTE BASEADO EM TABELA DE DECISO 388 12.6.4 EXEMPLO: CONTROLE DE NVEL LQUIDO 389 12.6.5 GRFICOS DE CAUSA-EFEITO EM TESTE FUNCIONAL 390 12.7 TESTE DE CONDIES LIMITE 394 12.8 TESTE EXAUSTIVO 395 12.9 TESTE ESTRUTURAL 395 12.10 CRITRIOS DE ABRANGNCIA DE TESTE BASEADOS EM MECANISMOS DE FLUXO DE DADOS 408 12.11 DIRETRIZES NA APLICAO DE TCNICAS DE ABRANGNCIA 410 12.12 TESTE DE REGRESSO 412 12.13 TESTE DE SOFTWARE ESTTICO 413 12.14 TCNICAS FORMAIS 415 12.15 TESTE EM GRANDE ESCALA 416 12.16 RESUMO 421 12.17 EXERCCIOS 422 12.18 REFERNCIAS 426 13 Medidas de Software 429 13.1 INTRODUO 430 13.2 MEDIDA DE SOFTWARE E MEDIO DE SOFTWARE 431 13.3 TAMANHO, DADOS E MEDIDAS DE COMPLEXIDADE DE SOFTWARE BASEADOS EM LGICA 432 13.4 MEDIES CIENTFICAS DO SOFTWARE 434 13.5 MEDIDA DE TAMANHO BASEADA NA LEI DE ZIPF 442 13.6 MEDIDA DA ESTRUTURA DE DADOS 445 13.7 MEDIDA DA ESTRUTURA LGICA 445 13.8 MEDIDA DE SOFTWARE BASEADO EM ENTROPIA 456 13.9 FLUXO DE INFORMAES DA MEDIDA DE SOFTWARE 460 13.10 MEDIDAS DE SOFTWARE PARA SISTEMAS ORIENTADOS A OBJETOS 462 XVI ENGENHARIA DE SOFTWARE 13.11 PARADIGMA DE APERFEIOAMENTO DA QUALIDADE DO SOFTWARE 471 13.12 RESUMO 471 13.13 EXERCCIOS 472 13.14 REFERNCIAS 476 14 Estimativas de Custos de Software 479

14.1 INTRODUO 480 14.2 MODELOS DE PONTOS DE FUNO 482 14.3 MODELO COCOMO 487 14.4 MTODO DE DELPHI DE ESTIMATIVA DE CUSTOS 493 14.5 RESUMO 496 14.6 EXERCCIOS 496 14.7 REFERNCIAS 498 15 Confiabilidade de Software 499 15.1 INTRODUO 500 15.2 IDIAS BSICAS SOBRE CONFIABILIDADE DE SOFTWARE 500 15.3 CLCULO DE CONFIABILIDADE DE SISTEMA 504 15.4 CLASSES DE MODELOS DE CONFIABILIDADE DE SOFTWARE 507 15.5 MODELOS DE CONFIABILIDADE DE SOFTWARE DEPENDENTES DE TEMPO 508 15.6 MODELOS DE CONFIABILIDADE DE SOFTWARE INDEPENDENTES DE TEMPO 515 15.7 CLASSIFICAO ORTOGONAL DE DEFEITOS 525 15.8 MODELOS DE DISPONIBILIDADE DE SOFTWARE 526 15.9 MODELO DE CONFIABILIDADE DE SOFTWARE: UM PROCEDIMENTO GERAL 531 15.10 RESUMO 534 15.11 EXERCCIOS 534 15.12 REFERNCIAS 538 16 Fatores Humanos 541 16.1 INTRODUO 541 16.2 FATORES HUMANOS NO DESENVOLVIMENTO DE SOFTWARE 544 16.3 CINCIA COGNITIVA E PROGRAMAO 548 16.4 MODELO DE PROCESSO DE SOFTWARE PESSOAL 551 16.5 INTERAO HOMEM-COMPUTADOR 552 Sumrio XVII 16.6 RESUMO 554 16.7 PROBLEMAS 554 16.8 REFERNCIAS 557 17 ReengenhariadeSoftware 559 17.1 INTRODUO 559 17.2 MTODO DE REENGENHARIA 561 17.3 QUESTES ECONMICAS DA REENGENHARIA 562 17.4 QUAL O PROPSITO DA REENGENHARIA? 564 17.5 BOLETIM INFORMATIVO DA ENGENHARIA REVERSA 564 17.6 RESUMO 564 17.7 EXERCCIOS 565 17.8 REFERNCIAS 565 18 Manuteno de Software 567 18.1 INTRODUO 568

18.2 ATIVIDADES DE MANUTENO 568 18.3 MODELOS DE MANUTENO 569 18.4 MANUTENIBILIDADE 572 18.5 REUSO DE SOFTWARE 576 18.6 ENGENHARIA REVERSA 578 18.7 PROJETO VISANDO A MANUTENIBILIDADE 578 18.7 RESUMO 579 18.8 EXERCCIOS 580 18.10 REFERNCIAS 582 Glossrio 583 ndice 597 CAPTULO 1 Viso do Terreno da Engenharia de Software sempre digo que, quando voc pode medir aquilo bre o que est falando, e express-lo em nmeros, jnifica que voc sabe algo a respeito dele. .ORD KELVIN, 1883 Objetivos Explorar os recursos no terreno da engenharia de software Considerar a abordagem de frameworks bsicos Comear a medir a qualidade de software Considerar o desenvolvimento incremental do software Comear a medir os nveis de maturidade Figura 1.1 Principais propulsores do desenvolvimento de software. 2 ENGENHARIADESOFTWARE Lii INTRODUO O terreno da engenharia de software extremamente rico e variado. A Figura 1.1 descreve a estrutura e extenso desse terreno em relao a algumas de suas principais caractersticas. Uma das caractersticas dominantes neste terreno uma abordagem de engenharia para frameworks de trabalho utilizados no planejamento, conceituao e projeto do software. E recomendvel comprar partes prontas do sistema de software em vez de constru-las. Faz mais sentido aproveitar os recursos fornecidos nos produtos de prateleira (commercial off-theshelf) em vez de reinventar a roda. Atualmente, os distribuidores de produtos de prateleira fornecem uma variedade de ferramentas, componentes e bibliotecas, bem como ambientes completos de desenvolvimento. A grande vantagem de se iniciar na engenharia de software a partir desse ponto que a vida se torna mais fcil devido enorme disponibilidade de ferramentas e bibliotecas teis para o incio de novos projetos de software. No lugar de construir novos sistemas de software a partir do nada, agora possvel comprar partes deles como produtos de prateleira e, at mesmo, adquirir pacotes completos para satisfazer s necessidades do cliente. Agora, to importante

saber qual software j est disponvel quanto saber criar e integrar um novo sistema de software. A Figura 1.1 mostra um recurso de desenvolvimento incremental no terreno da engenharia de software. Esse tipo de desenvolvimento mais eficaz do que tentar fazer tudo em uma s etapa. E mais fcil descrever, projetar, testar e corrigir um incremento de software com algumas caractersticas desejadas do sistema planejado. Uma vez que um incremento de software esteja sincronizado em relao a um conjunto de requisitos e comprovadamente estvel, ento ser possvel refinar e adicionar recursos ao incremento. A abordagem sincronizar-eestabilizar tem sido usada com bons resultados pela Microsoft (Cusumano e Selby, 1997). O terreno da engenharia de software inclui a avaliao da maturidade das organizaes de desenvolvimento de software. Essa avaliao auxiliada pelo Modelo de Maturidade (CMM), que uma prescrio para um aprimoramento contnuo da organizao de desenvolvimento de software com relao identificao dos nveis de maturidade do processo de desenvolvimento do software. Esse modelo foi desenvolvido pelo Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon (Carnegie Melion University, 1995). O objetivo do CMM ajudar as organizaes de software a aprimorar a maturidade dos processos de software. O CMM permite a evoluo desses processos de um nvel ad hoc e catico para nveis rigorosos e disciplinados. Na prtica, o CMM encoraja um aprimoramento contnuo do processo de software. A profuso de competio de produtos e ferramentas de software obrigou a introduo de padres. Um padro de so[tware estabelece mtodos, regras, requisitos e prticas a serem empregados durante o desenvolvimento de software. Com a padronizao, tornou-se possvel medir tamanho, contedo, valor ou qualidade de uma entidade de software. Outro recurso importante desse terreno o processo de software. Um processo de software consiste em atividades, mtodos e prticas teis no desenvolvimento de um produto de software. As atividades associadas a esse processo de software incluem a descrio e preparao de esquemas que identifiquem a estrutura dos dados e elementos de controle de um sistema, codificao, verificao e implantao do software. Em outras palavras, o conjunto total de atividades necessrias para transformar os requisitos de um usurio em software denominado um processo de engenharia de software (Humphrey, 1989). Viso do Terreno da Engenharia de Software 3 11.2 AS PEPITAS DA ENGENHARIA DE SOFTWARE: LOS COMPONENTES , - _4_ No terreno da engenharia de software, esto os componentes e frameworks. Um componente uma unidade de software testada para fins especiais (por exemplo, uma classe Java, extensivamente testada, considerada altamente confivel) que seja til, adaptvel, portvel e reutilizvel. Procurar um componente de software comparvel ao processo de extrao do ouro. Da

mesma forma que o ouro vai acumulando-se nos leitos dos rios depois de ser carregado pelas chuvas montanha abaixo, os componentes so acumulados aps muitos anos de desenvolvimento de produtos pelos engenheiros de software. O principal objetivo do desenvolvimento de software baseado em componentes permitir que os desenvolvedores usem mais de uma vez o cdigo escrito em qualquer linguagem e que ele possa ser executado em qualquer plataforma (Kiely, 1998). Com origem no termo software, os componentes so tambm chamados de com ponentware (CW). A programao baseada em componentes vem sendo chamada de megaprogramao (Boehm, 1990). Os componentes tm origem nas bibliotecas de reuso, como RAPID, (Ruegsegger, 1988) ou de software de prateleira como o GRACE (Berard, 1986). O principal propulsor da tecnologia de componentware na engenharia de software a projeo de unidades de software individuais conectveis - unidades que possam ser facilmente conectadas a uma aplicao para estender o seu funcionamento. Projees de vendas em bilhes de dlares para componentware e servios associados a seu uso foram feitas pelo grupo Gartner (Kiely, 1998). O grfico mostrado na Figura 1.2 compara as projees de servios e software de componentes at 2001. Vendas (em bilhes de dlares) 6 5 4 3 2 1 servios de CW o Figura 1.2 Projees de vendas de ComponentWare (CW). Um framework uma combinao de componentes (por exemplo, uma biblioteca de classes) que simplifica a construo de aplicaes e que pode ser conectado a uma aplicao. A busca do componentware pelos engenheiros de software tem suas origens nos objetivos de aumentar cada vez mais a produtividade e qualidade do software. Um resultado natural da decomposio dos sistemas de software em componentes reutilizveis o desenvolvimento de interfaces que possibilitam conectar os componentes com as aplicaes. Uma interface de software um programa que permite que os componentes interajam e inte an 1999 ano 2000 ano 2001 4 ENGENHARIA DE SOFTWARE roperem entre si. O JavaBeans, da Sun Microsystems, o DCOM (Distributed

Component Object Model) e o ActiveX da Microsoft so exemplos de tecnologias emergentes de interface de componentes. O JavaBeans uma arquitetura de componentes que ajuda os desenvolvedores de software a escrever classes de Java, que podem ser tratadas como componentes de sistemas maiores agrupados pelos usurios. Um bean um componente de software reutilizvel que pode ser visualmente manipulado em uma ferramenta construtora (Brookshier, 1997). Um bean exporta propriedades, gera eventos e implementa mtodos em Java (Arnold e Gosling, 1998). O JavaBeans fornece uma interface de plataforma neutra para a criao e utilizao de componentes em Java. O ActiveX permite transformar componentes de software disponveis em componentes que possam ser executados na barra de endereos de um navegador. Foi observado que alguns componentes so executados em uma nica plataforma (ActiveX) ou com aplicaes escritas em uma linguagem especfica (JavaBeans) (Kiely, 1998). Um outro exemplo de interface de software o MathLink da Wolfram Research. O MathLink permite vincular o Mathematica com o Microsoft Word e Excel e com o Xmath da famlia MATRIXx. No caso do vnculo entre o MathLink e o Excel, por exemplo, possvel aprimorar os recursos de construo de tabelas do Excel com os recursos numricos, grficos e de programao do Mathematica. Um produto de software um programa de computador combinado com os itens que o tornam inteligvel, utilizvel e extensvel (Brooks, 1975). A programao de computadores atingiu um estgio avanado com o auxlio da orientao a objetos, dos ambientes de desenvolvimento integrados e de uma variedade de ferramentas teis. Equipe, equipamento e locais de trabalho so exemplos de recursos de software necessrios para o desenvolvimento de software. Os processos, requisitos, produtos e recursos do terreno da engenharia de software so exemplos daquilo que conhecemos por entidades de software. LLiUMA ABORDAGEM DE ENGENHARIA 4L 4 4 Uma abordagem de engenharia engenharia de software caracteriza-se por um desenvolvimento de software prtico, ordenado e medido. O principal objetivo dessa abordagem produzir sistemas satisfatrios que respeitem prazos e oramentos. H um bom motivo para usarmos essa abordagem no planejamento, no desenvolvimento, na avaliao e na manuteno de software. Podemos dizer que ela necessria para evitarmos o caos no desenvolvimento de software. A abordagem de engenharia prtica por ser baseada em mtodos e prticas comprovados no desenvolvimento de software. Ela organizada em casos em que a seqncia e a definio de produtos e atividades da equipe de engenharia de software so mapeadas em modelos personalizados para as necessidades do cliente. A vantagem desse mapeamento permitir o gerenciamento do processo de software. Finalmente, essa abordagem medida. Durante cada fase do processo, mtricas de software so aplicadas aos produtos produzidos. O objetivo desse aspecto da engenharia de software estimar a qualidade, os custos e a confiabilidade do que j foi produzido. Com essa medio, obtemos uma melhor compreenso dos resultados do software. Esse um aspecto crucial da abordagem, pois as medies do software servem

como indicadores para mostrar se devemos avanar ou retroceder no processo. Basicamente, a engenharia de software exige a aplicao de uma abordagem sistemtica, disciplinada e quantificvel do desenvolvimento, operao e manuteno do software. Para ser eficaz, o desenvolvimento de sistemas de software exige uma abordagem de engenharia. A necessidade de uma abordagem desse tipo foi sugerida pela primeira vez em uma conferncia da OTAN em 1968 (Naur e Randeli, 1969). No sentido clssico, o termo engenharia refere-se aplicao de princpios cientficos ao projeto, manufatura e operao de estruturas e mquinas. Viso do Terreno da Engenharia de Software 5 Uma abordagem de engenharia ao desenvolvimento de software caracterizada pela aplicao dos princpios cientficos, mtodos, modelos, padres e teorias que possibilitam gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um sistema de software. Idealmente, a engenharia de software resulta numa produo econmica de software de qualidade. Foi observado que o desenvolvimento de software exige o estabelecimento de metas mensurveis, a quantificao da qualidade do software e a medio dos componentes que contribuem para o custo de um produto de software (Fenton, 1991). Em linguagem simples, uma medio resulta do ato de determinar o tamanho ou a extenso de algo em relao a um padro (Sykes, 1982). As atividades de medio durante o desenvolvimento do software so definidas em termos dos atributos das entidades de software (Fenton, 1991; Melton, 1996). No contexto do desenvolvimento de software, uma medio de software uma associao de nmeros ou smbolos com atributos de entidades de software. Novamente, em linguagem simples, um atributo uma qualidade atribuda a uma pessoa ou coisa. Um atributo de uma entidade de software uma caracterstica, nvel de desempenho (por exemplo, tempo e taxa de transferncia) ou propriedade (por exemplo, complexidade, confiabilidade e engenharia humana). O multithreading de alguns applets em Java, a conciso dos programas em Occam, a verborragia dos programas em Cobol e o caractere criptogrfico de programas shell do Berkeley Unix so exemplos de singularidades de software. Um applet um miniaplicativo executado numa pgina de um navegador da Web. Os applets podem executar tarefas e interagir com os usurios dessas pginas sem utilizar os recursos de um servidor da Web depois de ser descarregado (Arnold e Gosling, 1998). O custo, a confiabilidade e a qualidade de um produto so os aspectos mais importantes na medio dos artefatos desse processo de desenvolvimento. Qualquer item tangvel resultante de uma tarefa de projeto chamado de artefato. O jnteresse em se medir o software surgiu da necessidade de se obter uma melhor compreenso da estruturao e do comportamento do software. As atividades de medio tipicamente ocorrem no incio de um processo de desenvolvimento de software em conexo com a definio de problemas e o planejamento do projeto. Essas atividades de medio so motivadas pela

necessidade de determinar at que ponto um processo de desenvolvimento de software minimiza as dificuldades acidentais e essenciais do software. BLEMAS NO DESENVOLVIMENTO DO SOFTWARE %WG q*ra mi wu wmw Foram identificados dois problemas principais no desenvolvimento do software (Brooks, 1987): 1. Problema conceitual. Especificar, projetar e testar a construo conceitual implcita em um sistema de software. 2. Problema representativo. Representar o software e testar a fidelidade de uma representao. O problema conceitual considerado difcil, pois a essncia de uma entidade de software uma construo de conceitos inter-relacionados. Esses conceitos podem ser encontrados nos conjuntos de dados, nas relaes entre os itens de dados, nos algoritmos e nas chamadas de funes dentro de um programa. Em contraste com isso, o problema representativo considerado mais fcil, pois est ligado a recursos acidentais do software. A distino entre os recursos acidentais e essenciais de um objeto foi apresentada por Aristteles em um livro chamado Tpicos, escrito por volta de 340 a.C. (Barnes, 1984). Um recurso considerado acidental se a existncia de algo no depender do recurso. Exemplos de recursos acidentais de software so a sua linguagem (alto nvel ou nvel de mquina), sua representao grfica ou composio (modular ou no). Esses recursos 6 ENGENHARIA DE SOFTWARE podem ser modificados sem que a essncia do software seja alterada. Perceba, por exemplo, que a orientao a objetos pode ser considerada um recurso acidental de um projeto de software. Esse tipo de projeto de software caracteriza-se por objetos em que cada um deles uma instncia de uma classe. A funcionalidade de um programa orientado a objetos mantida mesmo se ele for reescrito de forma no-orientada a objetos (sem classes definidas pelo usurio). Novamente, por exemplo, a construo conceitual implcita em um programa permanece a mesma se esse contm um nico bloco (apenas um nico mtodo principal) ou modularizado (os detalhes ficam ocultos dentro dos mdulos). A funcionalidade de um programa tambm mantida se ele ficar mais compreensvel ao ser escrito em uma linguagem de alto nvel como o C+ + ou Ada, como na linguagem assembly ou de mquina. Um recurso considerado essencial se algo no puder ser mantido sem ele. Complexidade e abstrao so exemplos de dificuldades essenciais das entidades de software. A complexidade pode ser medida em relao ao nmero de predicados condicionais de um programa. Ela tambm pode ser medida com base em tipos de instrues, contagem de operadores, nveis de aninhamento, fluxo de informaes e contagem de instrues. Alm disso, a complexidade pode ser medida pela determinao dos requisitos para os recursos (como, por exemplo, nmero e tipo de pessoas, computadores e infra-estrutura), espao (como tamanhos de reas para as equipes de desenvolvimento ou espao em memria ou em disco para a instalao e operao de programas) e tempo (por

exemplo, a durao de cada um dos processos durante o desenvolvimento do software ou o tempo mdio de execuo de um programa). Basicamente, quanto mais complexa for uma entidade de software, mais difcil ser concretiz-la. A abstrao considerada outra dificuldade essencial dos requisitos, de software da funo ou da utilizao ou da especificao de arquitetura. Em particular, a lgica (construo e aplicao de um conjunto de regras) implcita em um modelo de processo de desenvolvimento de software abstrata. 1.4.1 Superando as Dificuldades Acidentais do Software O problema bsico que ocorre no desenvolvimento do software decidir o que desejamos dizer, e no como diz-lo (Brooks, 1987). J foi mostrado que muitas das inovaes ocorridas na engenharia de software dirigem-se s dificuldades acidentais na construo do software. Outras inovaes so direcionadas s dificuldades essenciais. Essas inovaes so esboadas na Tabela 1.1. As abordagens para solucionar as dificuldades acidentais (mtodos 8 a 15 da Tabela 1.1) preocupam-se principalmente com a representao (como vemos o software). Porm, os avanos ocorridos a partir da dcada de 1980 sugerem que algumas das resolues para as dificuldades acidentais do software tambm ajudam a combater as suas dificuldades essenciais. A discusso sobre as abordagens para solucionar as dificuldades acidentais do software ser limitada s linguagens de programao, programao orientada a objetos e aos produtos de prateleira. As outras seis abordagens da Tabela 1.1 (abordagens 10 a 15) so parte do conjunto de problemas propostos para este captulo. Na prxima seo, ser explorado como combater as dificuldades essenciais do software. As linguagens de programao de alto nvel, como Ada, COBOL, FORTRAN, C e Pascal simplificaram a codificao de sistemas complexos. Essas linguagens eliminaram a necessidade de codificar operaes, tipos de dados, estruturas de controle e a comunicao em nvel de bits, registradores, endereos em memria e canais de entrada e sada. Graas s linguagens de programao de alto nvel, foi possvel conceituar o software em um nvel mais humano. A programao tornou-se mais confortvel. A programao orientada a objetos (00) tornou-se possvel atravs de linguagens como Smalltalk, C+ + e Java. A abordagem 00 permite a introduo de novos tipos de dados, da modularizao e do encapsulamento de informaes. O encapsulamento de informaes uma abordagem de projeto na qual o software decomposto em mdulos Viso do Terreno da Engenharia de Software 7 ocultem as decises de projeto (Parnas, 1972a). Um mdulo uma parte de programa logicate separada. Cada mdulo oculta decises de projeto a respeito das caractersticas e contedas estruturas de dados e exporta as operaes de que o usurio necessita para utilizar o proa corretamente, e nada alm disso (Parnas, 1972b). Uma das principais vantagens do .psulamento de informaes simplificar o projeto de software. TABELA 1.1 Inovaes na Engenharia de software Como Solucionar as Dificuldades Acidentais Compre, no faa (abordagem de venda 8. Linguagens de programao de alto

nvel de produtos de prateleira) Refine os requisitos de forma iterativa e 9. Programao orientada a objetos (00) interativa com o cliente usando prottipos 3. Desenvolva o software de forma incremental 10. Inteligncia artificial (IA) 4. Contrate projetistas talentosos 11. Sistemas especialistas 5. Utilize frameworks bsicos 12. Programao automtica 6. Modele sistemas de software 13. Programao visual 7. Analise sistemas de software 14. Verificao de programas 15. Aprimoramentos de hardware Uma clase pode ser imaginada como um mdulo com operaes visveis sobre uma estrutura dados encapsulada (Shumate, 1994). Um objeto uma instncia de uma classe. Em uma aborem 00 de projeto de software, o aspecto mais importante deixa de ser o projeto das classes para se tornar a chamada de operaes nas classes de prateleira existentes sempre que possvel. Os detalhes da implementao de uma classe permanecem ocultos. Como conseqncia, as classes e os objetos relacionados fornecem uma concretizao funcional do paradigma de encapsulamento de informaes. Isso resulta em um projeto de software simplificado. De certa forma, essa simplificao contribui para a obteno de um cdigo mais compreensvel. Por esse motivo, o projeto de software 00 enfrenta as construes conceituais implcitas no software que est sendo construdo, no apenas na sua representao. A abordagem 00 tambm abrange a coluna esquerda da Tabela 1.1, por permitir a reutilizao. Em vez de criar um software, mais barato compr-lo. A contribuio da programao 00 ao software de prateleira no parecia estar clara no final da dcada de 1980. Alm de ferramentas e ambientes de software estarem disponveis comercialmente, bibliotecas de classes e frameworks de aplicaes foram disponibilizados para que desenvolvedores os utilizassem em novas aplicaes. Considere, por exemplo, o caso em que os requisitos de uma aplicao para um navegador da Web exijam a exibio de um despertador digital que tambm exiba o dia da semana e a data. A Figura 1.3 apresenta um exemplo de resoluo produzida por uma classe de Java que faz parte de uma biblioteca de classes de Java de prateleira (Davis et al., 1996). 1.4.2 Atacando as Dificuldades Essenciais do Software O desafio da engenharia de software encontrar formas para capturar a construo conceitual de sistemas complexos (Harel, 1992). J foram sugeridas vrias abordagens para especificar, projetar e testar a construo conceitual implcita em um software em desenvolvimento. Apresentamos 8 ENGENHARIA DE SOFTWARE um resumo dessas abordagens na Figura 1.4. O refinamento iterativo e interativo dos requisito com o auxlio de uma prototipao rpida visto como uma forma de atacar a essncia conceitual do software (Brooks, 1987). Um

prottipo de software simula interfaces selecionadas e realiza uma ou mais funes principais de um sistema. A vantagem da prototipao de software que ela tende a revelar uma estrutura conceitual especfica, de forma que o cliente possa testar sua consistncia e usabilidade. Uma segunda forma de atacar as dificuldades essenciais do software desenvolv-lo de forma incremental (Milis, 1971). Essas duas formas promissoras de resolver essas dificuldades so incorporadas naquilo que chamamos de framework bsico na Figura 1.4. Figura 1.3 Despertador digital. ESPECIFICAO caractersticas funcionais de um sistema ferramentas de prateleira representao visual descrio comportamental requisitos de refinamento e prototipao rpida hierarquia de atividades mtodos, diretrizes Figura 1.4 Formas de atacar as dificuldades essenciais do software. 1.4.3 Frameworks Bsicos A idia fundamental implcita nas abordagens para a resoluo das dificuldades essenciais do software o framework bsico. Um framework bsico um sistema conceitual modificvel, para propsitos gerais, que ajuda a estreitar a distncia entre uma resoluo de alto nvel para um problema e a sua implementao em software. Tal framework fornece uma forma conveniente para a estruturao e combinao de dados, e estruturas de controle em uma estrutura algortmica. O uso de frameworks bsicos na engenharia de software pretende liberar o programador de pensar p Qua 3defev de 1999 H 22:59:13 A 23:03:05 232 hrl LmmnD ( seJ 1

PROJETO desenvolvimento incremental bibliotecas de classes de prateleira estrutura hierrquica modularizao encapsulamento de informaes mtodos, diretrizes TESTES revisar o prottipo ferramentas de prateleira mtodos, diretrizes execuo interativa passo a passo verificao de consistncia entre nveis especificao executvel Viso do Terreno da Engenharia de Software 9 em um nvel inadequado de detalhes. Isso uma influncia do paradigma das linguagens de programao de alto nvel, onde se programa com construes de linguagens naturais, como while e if no lugar de instrues da linguagem assembly que testam os valores em registradores. No caso de um framework bsico, o projetista mapeia as idias para a resoluo de problemas para um mdio alto nvel que capture as construes conceituais. Uma abordagem topdown utilizada no desenvolvimento de software com esse framework. A complexidade essencial de um sistema no ocultada, mas sim tratada e gerenciada pela captura da estrutura conceitual de um sistema de software de forma natural. E adotada uma abordagem em camadas na especificao de um sistema. A idia construir uma hierarquia funcional (descrio em camadas das atividades de sistema) entrelaada com as atividades de controle. As hierarquias das construes conceituais em um projeto so capturadas com formalismos visuais. Um formalismo visual fornece uma notao com tamanho, forma e cor para representar a estrutura e a funo de um software. Uma boa notao visual til na concepo de algoritmos de boa qualidade e na comunicao de algoritmos e de idias para terceiros (Harel, 1992). A abordagem do framework bsico tem suas origens em um trabalho antigo de Parnas e outros sobre a modularizao e o encapsulamento de informaes. Um modelo de sistema de software visto como uma hierarquia de atividades que capturam as caractersticas funcionais de um sistema. E possvel ocorrer a superposio de elementos do sistema. Os elementos e os armazenamentos de dados esto associados s entradas e sadas que ocorrem entre as atividades em diversos nveis (Harel, 1992). A descrio comportamental parte de um framework bsico. As atividades de controle de um software constituem o seu comportamento. Essa forma de descrio de software recebeu destaque por causa das exigncias do que so conhecidos como sistemas reativos. Esses sistemas so projetados de forma a manter a interagir permanentemente com seu ambiente. Esto sempre prontos para receber entradas. Os sistemas reativos aguardam os eventos recebidos de seu ambiente e respondem instantaneamente s entradas do ambiente. Exemplos de sistemas reativos so

as interfaces com usurio homem-mquina e os controladores de processo em tempo real. j.!Medindo a Qualidade do Sol tware A abordagem da engenharia para o desenvolvimento de software levou criao da engenharia de requisitos (Davis, 1993), das fbricas de software (Cusumano, 1991), da engenharia de sala limpa (Mills et al., 1987), dos padres IEEE de engenharia de software (IEEE, 1997) e dos frameworks de maturidade de processo de desenvolvimento do software (Humphrey, 1989). A engenharia de requisitos a utilizao sistemtica de mtodos, linguagens, ferramentas e princpios verificveis para a anlise e descrio das necessidades do usurio e a descrio dos recursos comportamentais e no-comportamentais de um sistema de software que satisfaa s necessidades do usurio. Como conseqncia, a engenharia de requisitos possui dois estgios principais: deteco (estgio da anlise e resoluo de problemas) e especificao comportamental e no-comportamental (estgio da descrio do software). Os principais subprodutos da engenharia de requisitos so uma Especificao de Requisitos de Software (ERS) e uma srie daquilo que conhecemos como requisitos no-comportamentais para um produto de software. Uma ERS fornece uma estrutura bsica para o projeto completo de um produto de sofrware. Uma ERS resulta de uma anlise intensiva de um problema fornecido em um plano de software. A anlise de problemas possibilita o desenvolvimento de uma ERS, que fornece uma descrio completa da funcionalidade (comportamento) de um produto de software com detalhes suficientes e compreensveis para permitir que o programador desenvolva um programa de computador correspondente. As descries comportamentais 10 ENGENHARIA DE SOFTWARE revelam fluxos de dados e condies de entrada e sada para cada tarefa de software, bem cor propriedades do software a ser verificado. Os requisitos no-comportamentais definem os atributos que um produto de software preci ter. Em outras palavras, os requisitos no-comportamentais lidam com a qualidade do produto. grau necessrio de cada atributo de qualidade que o produto de software deve ter e os atributo serem medidos. A prpria qualidade identificada com o grau em que um sistema, componen ou processo satisfaz aos requisitos especificados (IEEE, 1997). Um atributo de um produto software uma caracterstica mensurvel do software, como engenharia humana, confiabilida ou manutenibilidade. A medio do software efetuada levando-se em conta uma hierarquia atributos. Ou seja, a qualidade do software avaliada em termos de atributos de alto nvel cham dos fatores, que so medidos em relao a atributos de baixo nvel chamados critrios. Um fat de software uma viso orientada ao usurio da qualidade do produto (McCall, 1994). Em opos o a isso, temos os critrios, que so caractersticas orientadas ao software, que indicam a qual dade do produto (Bowen eta!., 1985). Os fatores e critrios de um software tendem a possuir um relao de causa e efeito (Peters e Ramanna, 1998). A correspondncia entre critrios e fatores apresentada na Tabela 1.2. Tabela 1.2 Fatores e Critrios de Qualidade

Fatores de Qualidade (Efeito) Critrios (Causa) Fidedignidade: at que ponto o software satisfaz seus Rastreabilidade, completude, consistncia requisitos Con fiabilidade: freqncia de ocorrncias de Tolerncia a erro, consistncia, exatido, problemas no software simplicidade Manutenibilidade: esforo necessrio para localizar e Consistncia, conciso, simplicidade, consertar um erro no software modularidade, nmero de comentrios, complexidade, compreensibilidade, escalabilidade Testabilidade: esforo necessrio para garantir que o Simplicidade, modularidade, instrumentao, software desempenhe as funes a que se destina capacidade de auto-descrio Eficincia: quantidade de recursos exigidos pelo Eficincia de execuo, eficincia de software armazenamento Integridade: extenso do controle de modificaes ou Controle de acesso, auditoria de acesso acessos acidentais Usabilidade: esforo necessrio para aprender, Operabilidade, treinamento, eficincia, operar, preparar entradas e interpretar a sada de um compreensibilidade, durabilidade, engenharia sistema de software humana, produtividade, manuteno de sistema, flexibilidade de sintaxe, adaptabilidade, facilidade de aprendizado, familiaridade, recuperao de erros, utilidade, comunicabilidade. Portabilidade: esforo necessrio para transferir o Independncia de sistema de software, software para outra plataforma independncia de mquina, capacidade de auto-descrio, modularidade. Interoperabiidade: esforo necessrio para acoplar *Compartilhamento de comunicaes sistemas de software *Compartilhamento de dados Reusabilidade: at que ponto os mdulos de software Capacidade de autodescrio, modularidade, podem ser usados em diferentes aplicaes portabilidade, independncia de plataforma Viso do Terreno da Engenharia de Software 1 1 1.5.1 Mtodo de Medio da Qualidade do software Tipicamente, a qualidade do software medida por meio de uma soma ponderada de medies de critrios (Bowen et ai., 1985). Para medirmos um fator de qualidade de uma entidade de software, utilizamos as seguintes etapas. Mtodo de Medio da Qualidade do software Etapa 1. Selecione os critrios usados para medir um fator de software. Etapa 2. Selecione um peso para cada critrio (geralmente O _ p _ 1).

Etapa 3. Selecione uma escala de valores para a pontuao dos critrios (por exemplo, O _ resultado do critrio _ 10). Etapa 4. Selecione valores mnimos e mximos admissveis para a pontuao de cada critrio. Etapa 5. Selecione valores mnimos e mximos admissveis para a pontuao de cada fator. Etapa 6. D uma pontuao a cada critrio Etapa 7. Calcule a soma ponderada. Etapa 8. Compare a soma ponderada com o intervalo de pontuao mnimo e mximo de fator predefinido. Etapa 9. Se a soma ponderada estiver fora do intervalo de pontuao mnimo e mximo, compare a pontuao de cada critrio individual com o intervalo predefinido de pontuao mnimo e mximo do critrio para direcionar as atividades de aprimoramento de software. As frmulas ponderadas para cada fator no framework de medio de qualidade possuem a forma p1c1 + p2c2 +... onde Pi ..., p so pesos e c1 , c so medies de critrios. Uma frmula ponderada mede o efeito cumulativo dos critrios ponderados. 1.5.2 Exemplo: Medindo a Reusabilidade do software Para medir a reusabilidade de uma entidade de software, apresentaremos, na Tabela 1.3, as trs primeiras etapas do mtodo de medio da qualidade do software aplicado a dois produtos hipotticos de software chamados Steersman and Ucontrol (para o controle de um determinado dispositivo). A capacidade de auto-descrio est associada ao software que pode ser lido e compreendido por causa de sua sintaxe, uso de linguagem natural. Considere os programas em Pascal ou COBOL, que tendem a ser autodescritveis, enquanto aqueles em FORTRAN ou Java no so considerados como tal. A modularidade definida em relao ao grau com que um sistema ou ama de computador composto de componentes discretos tal que uma alterao feita em mponente tenha um impacto mnimo nos demais componentes. Os programas em C ++, e Java geralmente possuem uma alta modularidade. A portabilidade refere-se facilidade que o software pode ser transferido de um hardware ou ambiente de software para outro. A ndncia de plataforma diz respeito ao software que no depende dos recursos exclusivos de terminado tipo de computador e que, por esse motivo, pode ser executado em mais de um te computador. Os applets em Java tendem a ser bastante portveis e independentes em relaplataforma. Em oposio a isso, temos os programas em COBOL, que no apresentam nea das duas caractersticas. A seleo e os pesos dos critrios (na Tabela 1.3) so determipor uma equipe de planejamento na criao de um guia de desenvolvimento de software a um determinado projeto. 12 ENGENHARIA DE SOFTWARE A pontuao dos critrios na Tabela 1.3 fornecida por desenvolvedores de

software experi entes. Embora a pontuao dos critrios no seja conhecida durante o estgio de planejamento, o, valores objetivos para os fatores de qualidade do software podem ser identificados. A seleo d um valor objetivo para um fator de qualidade permite que as equipes de desenvolvimento de soft ware tenham uma escala de medio, a qual fornece a base para o julgamento da aceitabilidade d uma entidade de software. Tabela 1.3 Exemplo de Critrios da Reusabilidade Critrio de Reusabilidade Pontuao de Pontuao de Peso Steersman Ucontrol capacidade de autodescrio (AD) 5 1 p1 = 0,8 modularidade (M) 5 7 p2 = 0,9 portabilidade (P) 9 3 p3 = 0,2 ndependncia de plataforma (IP) 1 - 9 p4 = 1 Tabela 1.4 Exemplo de Estimativas de Reusabilidade Reusabilidade de Steersman Reusabilidade de Ucontrol reusabWdade = p1 (AD) + p2 (M) + p3 (P) + p4 (IP) = p1 (AD) + p2 (M) + p3 (P) + p4 (IP) (0,8)(1) + (0,9)(7) + (0,2)(3) + 9 = (0,8)(5) + (0,9)(5) + (0,2)(9) + 7 8,0 + 6,3 + 0,6 + 9 =4,0+4,5+1,8+1 =16,7 = 11,3 Para completar a avaliao da reusabilidade de Steersman e de Ucontrol, calcule: Reusabilidade = Pi (AD) + P2 (M) + p (P) + 34 (IP) A Tabela 1.4 apresenta um resumo dos clculos relativos aos dois programas aplicativos. Utilizando essa frmula, o produto Ucontrol, com uma pontuao de 16,7, tem um resultado superior a Steersman, que recebe uma pontuao de 11,3. A Figura 1.5 mostra uma comparao das pontuaes dos critrios ponderados individuais de ambos os produtos de software. A Figura 1.5 sugere que com o aumento da independncia de plataforma de Steersman, esse ter uma pontuao superior a Ucontrol. Por exemplo, se Steersman eventalmente chegar a alcanar uma pontuao 6 relativa independncia de plataforma, a nova pontuao de sua reusabilidade 16,3 praticamente a mesma de Ucontrol. Em outras palavras, um grfico como o apresentado na Figura 1.5 sugere formas pelas quais os desenvolvedores podem aprimorar um produto de software de forma a alcanar os objetivos de projeto almejados. A pontuao predefinida de intervalo de fatores mnimo e mximo fornece uma indicao de qual entidade de software possui qualidade de software insuficiente (ou melhor do que esperada). Se assumirmos que o valor mnimo de cada critrio ponderado seja 5, e que o valor mximo almejado para cada critrio ponderado seja 15, ento poderemos construir o que conhecido como um diagrama Kiviat (Figura 1.6). Figura 1.6 Exemplo de diagrama Kiviat aps alguns aperfeioamentos. Um diagrama Kiviat ilustra as medies relativas aos valores mnimo e mximo. Esse tipo de diagrama possui o formato de uma roda com travas, O raio da circunferncia interna igual a um mnimo selecionado, enquanto a

circunferncia externa tem o raio igual a um mximo selecionado. H uma trava para cada critrio medido em um diagrama Kiviat que ilustra as medies de qualidade. As medies dos critrios deveriam, de forma ideal, estar entre as circunferncias interna e externa do diagrama. A beleza desta forma to simples de mtrica que ela mostra cada medio de acordo com os valores mnimo e mximo almejados, e indica o que se deve aprimorar. O diagrama Kiviat na Figura 1.6 reflete o fato de que o sistema de software Ucontrol foi aperfeioado de forma a atingir uma pontuao maior nos critrios ponderados de AD (autodescrio) e P (portabilidade). Os nveis da pontuao de fator de qualidade do software almejados podem ser negociados de antemo com o cliente, o que constitui prtica comum nas fbricas de software (Cusumano, 1991). Por exemplo, se a pontuao da reusabilidade almejada est predefinida no intervalo [15,18], ento a pontuao do pacote Ucontrol da Figura 1.6 poderia ser aceita (a pontuao 16,3 de sua reusabilidade est dentro do intervalo mnimo e mximo predefinido). Porm, o pacote Steersman necessitaria de um maior aprimoramento, pois sua pontuao e 11,3 est abaixo do mnimo predefinido. A atribuio de valores mnimo e mximo de pontuaes de critrios fornece uma escala com a qual as Viso do Terreno da Engenharia de Software 13 Ucontrol Steersman Figura 1.5 Comparao das pontuaes dos critrios ponderados. pontuao 20 16,7 IP AD mn = 5 P

mx= 15 1 4 ENGENHARIA DE SOFTWARE pontuaes de critrios individuais podem ser julgadas. A pontuao de um fator de qualidade d software pode ser julgada com relao aos valores de fator mnimo e mximo identificados por um equipe de controle de qualidade do software. Por exemplo, se a pontuao dos critrios de ai. todescrio precisa estar no intervalo [3,5 - 61, os esforos adicionais para aprimorar a pontua deAD seriam adiados. No caso em que uma pontuao de modularidade 1,8 estivesse abaixo de ur mnimo predefinido (por exemplo, M = 5), o pacote Steersman sofreria uma modularizao aind maior, de forma a aumentar a pontuao de seu fator de reusabilidade. Perceba que outros critrio alm dos apresentados na Tabela 1.3 poderiam ser considerados na medio da reusabilidade d software (como, por exemplo, a interoperabilidade). LCOMPRE, NO FAA O desenvolvimento do software quase sempre significa reutilizar, estender ou refinar um produt de software existente. Nessa abordagem para o desenvolvimento de software, mais vantajos comprar do que fazer um produto de software desde o incio. Essa abordagem tambm vem sendc apontada como uma das mais promssoras para avaliar e resolver parcalmente a dificuldade essencial do software (Brooks, 1987). H uma abundncia de exemplos dos benefcios dessa abordagem. Por exemplo, no desenvolvimento de interfaces grficas com o usurio independentes em relao plataforma que possam ser executadas por meio de um navegador da Web, podemos reduzir o tempo e o esforo utilizando o Java Abstract Windowing Toolkit (AWT) em vez de reinventar os mtodos encontrados no AWT (Zukowski, 1997). E natural encontrarmos desenvolvedores de software buscando maneiras de reutilizar estruturas de projeto de software para a uma variedade de produtos, e tentarmos imitar o sucesso obtido na engenharia dos produtos de hardware. Tambm podemos afirmar que natural considerarmos como os produtos de software existentes possam ser incorporados em novos produtos ou como possam ser modificados e aprimorados de forma a produzir um novo produto. Como conseqncia disso, foram criadas fbricas de software. Uma fbrica de software combina as ferramentas e o conhecimento profissional da engenharia de software com o gerenciamento habilidoso do produto, processo e desenvolvimento organizacional. A abordagem de fbrica de software aplicada em uma srie de projetos semelhantes. Essa abordagem vem apresentando benefcios significativos: utilizao repetida de planos de processo de software e guias de engenharia de sofrware semelhantes, anlise e controle da qualidade, padronizao de perfis, reusabilidade de sistemas de entidades de software aplicada ao desenvolvimento de produtos semelhantes, alm do aprimoramento incremental do projeto e desempenho de produtos (Cusumano, 1991). LLDESENVOLVIMENTO INCREMENTAL 1 1 O desenvolvimento incrementa! dos sistemas de software foi identificado como uma das formas de lidar com as dificuldades essenciais do software (Brooks,

1987). A abordagem incremental do desenvolvimento de software tambm fornece um dos principais meios de gerenciar o problema das mudanas contnuas nos requisitos e recursos do sistema. Os incrementos devem ser pequenos e cuidadosamente selecionados, visando os incrementos futuros. 1.7.1 Regras de Humphrey A abordagem incremental do desenvolvimento de software foi formulada por Watts Humphrey como um conjunto de regras para as equipes de gesto do software seguirem durante as fases de Viso do Terreno da Engenharia de Software 15 -. cao de requisitos e de projeto de um processo de software (Humphrey, 1989). As regras -lumphrey so mostradas na Tabela 1.5, que identifica a fase de desenvolvimento de software cvel, bem como o evento que faz com que uma regra seja utilizada. A Regra 1 da Tabela 1.5 fornece um ingrediente essencial para que haja estabilidade durante o nvo1vimento de software. Ao congelar uma etapa incremental no processo de requisitos do ware, o projetista pode executar seu trabalho com a confiana de que as etapas incrementais -nte a implementao faro a juno das partes do incremento congelado. Isso , de forma imita, um modelo evolucionrio da gesto do software, onde o feedback da fase de projeto proca mudanas nos requisitos. Esse tambm o segredo da abordagem de sala limpa ao desenvolmento de software, apresentada por Harlan Mills (Milis, 1987). R 1.5 Abordagens ao Desenvolvimento Incremental Estmulo Etapa incremental dos requisitos de software concluda Resposta Congelar requisitos Selecionar o incremento que dar suporte a incrementos futuros Nmero Regra de Humphrey Congelar requisitos relativos a cada etapa incremental antes de iniciar o projeto 2. Selecionar cada incremento de forma a dar suporte aos prximos incrementos e/ou aprimorar o conhecimento de [projeto] requisitos

Receber definio de requisitos estveis para um produto Selecionar um incremento pequeno a ser implementado 3. Implementar um produto de software em etapas pequenas e incrementais. Ocorrncia de uma alterao nos requisitos Surgimento de uma alterao no-defervel nos requisitos Deferir alterao Interromper trabalho, 5. revisar a Especificao de Requisitos de Software (ERS) 4. Sempre que houver alterao nos requisitos durante a implementao, deferir alterao para um incremento subseqente Caso as alteraes no possam ser deferidas, interrompa o trabalho, modifique os requisitos, revise o planejamento e reinicie o projeto. A aplicao das Regras 1 e 4 garante que uma funo satisfaa a sua especificao de requisitos, que cada requisito incrementa! permanece inalterado durante a sua implementao. As etaincrementais durante a fase de projeto de um processo de software so chamadas de constru s O objetivo de cada construo produzir cdigo executve! o mais rpido possvel. Perceba e no adianta insistir em uma implementao que revele uma alterao no-defervel nos requios do sistema. A Regra 5 recomenda que se interrompa qualquer implementao subseqente tse de requisitos e ojeto Pronto para incrementar Viso do Terreno da Engenharia de software 17

Engenharia sala limpa 1 plano de _________ incrementos Etapas de inspeo baseadas em verificao: incrementos 1 completos 1. Especificar a condio (funo) a ser satisfeita pelo incremento. 2. Desenvolver o incremento de software (por exemplo, requisito, arquitetura, cdigo do mdulo). 3. Mostrar que o incremento satisfaz propriedade especificada. 1. Identificar as funes do software a serem testadas, e as entradas que dem incio execuo das funes. 2. Caracterizar as entradas de software com base no perfil de utilizao. 3. Selecionar aleatoriamente dados de testes com base na utilizao operacional do software encontrado na etapa 2. 4. Determinar se a funo incorporada em um incremento foi aprovada ou reprovada nos testes. Figura 1.7 Etapas da engenharia sala limpa. A prtica da engenharia sala limpa composta de 14 processos principais utilizados na medio do desempenho de uma equipe de software. Esses processos e os artefatos resultantes de cada um deles resumido na Tabela 1.6. Os processos de gesto sala limpa so aplicados simultaneamente em todos os processos de engenharia sala limpa restantes. O sustentculo da engenharia sala limpa o planejamento de projeto, o qual estabelece ou revisa um Guia de Engenharia Sala Limpa (GES) e um Plano de Desenvolvimento de Software (PDS). A estrutura do GES mostrada na Figura 1.8. Tabela 1.6 Processos e Artefatos Sala Limpa Tipo de Processo Processo Gesto (presente durante todas as fases de um processo de desenvolvimento de software) 4. Processo de alterao de engenharia Especificao 5. Anlise de requisitos

(fase de requisitos) 6. Processo de especificao de funo 7. Processo de especificao de utilizao Artefato Guia de engenharia sala limpa Plano de desenvolvimento de software Registro de projeto Plano de melhoria do desempenho Log de alterao de engenharia Requisitos de software 1. Planejamento de projeto 2. Gerncia do projeto 3. Melhoria do desempenho Especificao de funo Especificao da utilizao 8. Especificao de arquitetura Arquitetura de software Etapas dos testes estatsticos : 18 ENGENHARIA DE SOFTWARE Tabela 1 .6 Continuao O GES refinado sucessivamente de forma a ser utilizado pelas equipes sala limpa, linhas d produo e projetos especficos. O GES tambm personalizado com relao a padres ISO IEEE, tecnologias especficas como o Windows NT e linguagens de programao como Java o Ada. O PDS complementa o GES. O primeiro tem como principais objetivos permitir a monitor2 o de desempenho e a gerncia do processo quantitativo, alm de iniciar tarefas como a anlis de requisitos. O PDS define as bases da gesto do processo de software, e serve para definir a organ zao, o cronograma, a monitorao, a avaliao e o controle dos artefatos do processo do software. 11.8 MODELO DE MATURIDADE DE CAPACIDADE

O Modelo de Maturidade (CMM) descreve a maturidade da gesto do processo de software er relao a cinco nveis (Figura 1.9). IJ1 _______ 1 ______ artefatos definio 1 definies, diretivas 1 1 gabaritos, de processo procedimentos locais formulrios Figura 1.8 Estrutura de um Guia de Engenharia Sala Limpa. Tipo de Processo Desenvolvimento (fase de projeto) Processo 9. Processo de planejamento de incremento 10. Engenharia de software 11. Processo de projeto do incremento 12. Verificao de fidedignidade Certificao (fase de controle estatstico) 13. Processo de elaborao do modelo de utilizao e planejamento de testes 14. Processo de testes estatsticos e certificao Artefato Plano de construo de incremento Plano de reengenharia Software de reengenharia Projeto do incremento Relatrio de verificao de incremente Modelos de utilizao Plano de teste incremental Casos de testes estatsticos Sistema executvel Relatrio de testes estatsticos Relatrio de certificao de incremento

Viso do Terreno da Engenharia de Software 1 9 1.8.1 Medindo os Nveis de Maturidade: Mtodo Verificao Cada um dos nveis do Modelo de Maturidade (CMM) pode ser medido. Isto pode ser feito pela construo de uma lista de verificao dos itens que caracterizem cada um desses nveis. O grau em que um item est presente em uma organizao ento medido. Em seguida, a soma dos graus estimados calculada. Essa soma serve para indicar em que grau uma organizao manifesta um determinado nvel de maturidade. Esse processo de medio pode ser automatizado, e assim fornecer uma forma de simular (e monitorar) as alteraes nos nveis de maturidade de uma organizao. Nesta seo, uma abordagem para medir a maturidade em relao ao nvel inicial ilustrada. nvel de maturidade __________________________ Melhoria contnua do processo permitido pelo nvel 5:Otimizado retorno quantitativo do processo e pelos pilotos de idias e de tecnologias inovadoras.

Medidas detalhadas do processo de software e das atividades de engenharia so coletadas. O processo de software e os produtos so compreendidos e controlados de forma quantitativa. As atividades de gesto e engenharia so documentadas, padronizadas, integradas em um processo de software padro. Estabelecimento de processos de gerncia de projeto para monitorar os custos, cronograma e funcionalidade. Existe a necessria disciplina do processo para repetir operaes bem-sucedidas em projetos com aplicaes semelhantes. Ad hoc, ocasionalmente catico. Poucos processos so definidos, O sucesso depende nivel 1: Inicial dos esforos individuais e heroicos. tempo Figura 1.9 Nveis de maturidade da gesto do processo de software. O nvel inicial do CMM caracterizado pelo caos. Uma organizao com um nvel de maturidade inicial desorganizada e depende do herosmo dos indivduos para impulsionar um projeto de software. No h planejamento suficiente e falta o desenvolvimento de um guia bem definido que as equipes de desenvolvimento possam seguir. Poucos detalhes de um processo de software esto definidos nesse nvel. Bons resultados so considerados um milagre. A lista de verificao da Tabela 1.7 indica se uma organizao est operando no nvel de maturidade inicial ou no. Uma pontuao alta no nvel de maturidade inicial serve como um indicador de uma organizao de desenvolvimento de software inexperiente, com um comportamento potencialmente catico. Na Tabela 1.7, a pontuao 0,78 indica uma organizao com necessidade de melhorias bsicas, a comear por um plano de desenvolvimento de software completo e de um guia de engenharia de software. Perceba que a lista de verificao da Tabela 1.7 poderia ser expandida de forma a incluir outros indicadores do nvel de maturidade inicial (como, por exemplo, conflitos de cronograma ou falta de continuidade). A pontuao nos itens da lista de verificao relativos ao nvel de maturidade inicial apontam para os pontos fracos (pontuaes mais altas) ou fortes (pontuaes mais baixas), e servem como indicadores de pontos onde a organizao precisa de melhoria. Nessa abor 20 ENGENHARIADESOFTWARE Ausncia de plano de desenvolvimento de software Ausncia de guia de engenharia Ausncia de modelo de processo consentido Ausncia de contrato (confidencialidade) Ausncia de envolvimento de uma gerncia snior Requisitos em constante mudana Inexperincia da equipe (grupo de trabalho desqualificado) Ausncia de (disponibilidade de) prottipos

Aumento crescente do sistema de software Suporte inadequado Pontuao do nvel de maturidade inicial = 0,7 (plano parcial presente) 1,0 (nenhum guia) 1,0 (nenhum modelo de processo consentido) 0,0 (contrato foi assinado pela equipe) 0,4 (algum envolvimento de gesto snior) 0,8 (indicao de caos) 1 (equipe altamente inexperiente) 1 (nenhum prottipo disponvel ou em uso) 1 (nenhum controle sobre o tamanho) 0,9 (muito pouco compromisso com o projeto) IndicadorNvellnicial 78 =--= 0,78 10 10 dagem, a pontuao de uma lista de verificao relativa a cada um dos outros nveis de maturidade do CMM completa como um meio objetivo de se avaliar o nvel a maturidade geral de uma organizao. 1.8.2 Arquitetura dos Nveis do Modelo de Maturidade: Areas de Processo-chave A medio do nvel de maturidade de uma organizao pode ser realizada em termos conhecidos como Areas de Processo-Chave (KPAs). Uma KPA identifica um conjunto de atividades relacionadas a serem realizadas em grupo de forma a aumentar a capacidade do processo. Uma viso geral das KPAs relativas a cada nvel do CMM apresentada na Tabela 1.8. TABEI..A 1.7 Lista de verificao para o Nvel de Maturidade Inicial Item Grau de (O _ avaliao _ 1) (10 itens na lista de verificao) (exemplos de medies) TABELA 1.8 reas de Processo-chave Nvel de reas de Processo-chave Maturidade Explicao Resumida Repetitivo Gesto de requisitos (GR) Planejamento de projeto de software (PP) Rastreamento do projeto de software, omisso Planejar, gerenciar, analisar requisitos Planejamento de incremento e projeto Rastrear a produo versus os planos e os objetivos Selecionar, gerenciar contratantes qualificados Certificao, verificao de produto Mudana de engenharia

(RP) Gesto de subcontrato de software (GS) Garantia de qualidade de software (GR) Gesto de configurao de software (GC) Viso do Terreno da Engenharia de Software 21 TABELA 1.8 Continuao Nvel de Maturidade reas de Processo-chave Explicao Resumida Foco de processo organizacional (FP) Definio de processo organizacional (DP) Programa de treinamento (PT) Gerenciamento de software integrado (MS) Engenharia de produto de software (EP) Coordenao intergrupal (Cl) Reviso por pares (RP) Gerenciado Gesto de processo quantitativo (P0) Gesto de qualidade de software (QS) Otimizado Preveno de defeitos (PD) Gesto de alterao de tecnologia (GT) Gesto de alterao de processo (GP) Responsabilidades da organizao identificadas Desenvolver, manter ativos do software Desenvolver habilidades e conhecimento da equipe Integrar atividades de software e de gesto Processo de engenharia bem definido Atividades intergrupais Identificao de defeitos com antecedncia, objetivamente Controlar desempenho do processo Desenvolver, manter ativo do processo de software Identificar, rastrear as origens dos defeitos Identificar novas tecnologias benficas Melhoria contnua do desempenho

No existe nenhuma KPA associada ao nvel 1 (inicial) do CMM, que caracterizado pela ausncia de mtodos bem-definidos para a gesto do processo de software. Portanto, no apresentada nenhum KPA relativo ao nvel 1. Na Tabela 1.8 o nvel 2 (processo repetitivo) do MM caracterizado por um compromisso com a disciplina na execuo de um projeto de desenvolvimento de software. Esta disciplina atingida pelos acordos em relao aos planos do projeto, estimativas (por exemplo, homem-ms, recursos, perfis) e reviso e rastreamento dos sistemas. Com a organizao desses itens de suporte, possvel assegurar a qualidade do produto de software (comparando-se as caractersticas positivas do artefato com os planos e requisitos do projeto) e repetir o processo do software de forma eficiente. Existem seis KPAs associadas ao nvel 2 (repetitivo). reas de Processo-chave do Nvel 2 (Processo Repetitivo do CMM) A gesto de Requisitos (GR) estabelece uma compreenso comum entre o cliente e as equipes de desenvolvimento de software com relao aos requisitos do cliente. O Planejamento de Projeto de Software (PP) estabelece um plano para um projeto de software e a gesto do processo de software. O rastreamento do Projeto de Software e omisso (RP) estabelece uma visibilidade das atividades do processo de software para facilitar a identificao dos desvios no planejamento do projeto de software. A gesto de subcontrato de Software (GS) seleciona e gerencia os subcontratados do software. A garantia de Qualidade de Software (GQ) fornece uma reviso independente do trabalho tcnico e de planejamento, a segurana que o trabalho foi feito de acordo com o plano, e de que as concluses so consistentes com o trabalho realizado (Humphrey, 1989). A gesto de Configurao de Software (GC) estabelece e fiscaliza as alteraes de engenharia e faz a manuteno dos produtos de um processo de software. Definido 22 ENGENHARIA DE SOFTWARE O nvel 3 (Processo Definido) do modelo de maturidade introduz padres para guiar a estruturao e avaliao de um projeto de software. Um padro de software um conjunto de regras prescrevendo requisitos obrigatrios a serem efetuados em uma abordagem disciplinada e uniforme ao desenvolvimento de software (IEEE, 1997). Ou seja, um padro de software fornece uma base de comparao para assegurar o tamanho, o contedo, o valor ou a qualidade de uma entidade ou atividade de software (Humphrey, 1989). Existem sete KPAs associadas ao nvel 3. reas de Processo-chave do Nvel 3 (Processo Definido do MMC) O Foco de Processo Organizacional (FP) estabelece uma responsabilidade organizacional para a melhoria das atividades e capacidades do processo de software.

A Definio de Processo Organizacional (DP) desenvolve e mantm um conjunto de ativos do processo de software (ferramentas, medidas, padres) de forma a melhorar o desempenho do processo. O Programa de Treinamento (PT) projetado de forma a desenvolver os perfis e o conhecimento necessrios dos membros da equipe. O Gerenciamento de Software Integrado (GI) unifica a engenharia de software e as atividades de gesto de acordo com os padres do processo de software e os ativos do processo. A Engenharia de Produto de Software (EP) estabelece um processo de software bem definido que integra todas as atividades de engenharia de software de forma a produzir produtos de software consistentes e corretos de forma eficaz e eficiente (Linger et ai., 1996). A Coordenao Intergrupal (CI) estabelece uma colaborao entre as diferentes equipes de projetos de software. As Revises por comparao (RC) fornecem inspees de software que verificam os erros nos estgios mais iniciais possveis durante o ciclo de desenvolvimento de um software. As inspees de software so efetuadas de acordo com listas de verificao e com os padres do software. As vezes, esses so personalizados para projetos de software especficos. A personalizao resulta de discusses de caractersticas particulares de modelos de processo e nvel mais geral e atmico de um projeto de software. As Listas de Verificao lidam com as condies de entrada e sada, itens de verificao, qualidade de software, confiabilidade e medio de custos para as tarefas do desenvolvimento de software. As listas de verificao tambm cobrem o planejamento de inspeo do software e os procedimentos necessrios para a preparao e a apresentao de relatrio. O nvel 4 (Processo Gerenciado) do modelo de maturidade est associado a duas atividades principais: levantamento e anlise de dados e gesto de qualidade de software. As duas KPAs relativas ao nvel 4 so a gesto do Processo Quantitativo (PQ) e a gesto de Qualidade de Software (QS). reas de Processo-chave do Nvel 4 (Processo Gerenciado do CMM) A gesto do Processo Quantitativo (PQ) controla o desempenho do processo de software de forma quantitativa com base nos levantamentos e na anlise de dados. A gesto de Qualidade de Software (QS) fornece uma avaliao quantitativa da qualidade do produto de software com relao aos objetivos de qualidade do software. Viso do Terreno da Engenharia de Software 23 o levantamento de dados do software feito de forma a estimular a compreenso, a avalia- o, o controle e a previso em uma empreitada de engenharia de software. Os dados do sofrware (por exemplo, linhas de cdigo, defeitos, erros, falhas, problemas, seqncias de utilizao de software, medies de qualidade, confiabilidade e custos) fornecem uma base para a determinao das taxas de desenvolvimento do incremento de software e as

tendncias do processo de software. Alm disso, a anlise de tendncias e as taxas de desenvolvimento so essenciais para o processo de tomada de decises de um projeto de software. A avaliao quantitativa da qualidade de um produto de software pode ser alcanada por comparao das medies de qualidade com os requisitos de qualidade do software. Isso pode ser feito atravs da delineao peridica das medies de qualidade (como engenharia humana, eficincia e manutenibilidade) relativas s medies mnima e mxima de um diagrama Kiviat. O nvel 5 (Processo Otimizado) do modelo de maturidade o mais alto de um processo de software gerenciado. O processo otimizado est associado preveno de defeitos, automao do processo de software sempre que possvel e aos mtodos para a melhoria da qualidade do software e produtividade da equipe, alm da diminuio do tempo de desenvolvimento. As trs KPAs do nvel 5 so a Preveno de Defeitos (PD), a gesto de alterao de Tecnologia (GT) e a gesto de alterao de Processo (GP). reas de Processo-chave do Nvel 5 (Processo Otimizado do MMC) A Preveno de Defeitos (PD) identifica as causas dos defeitos e efetua procedimentos para evitar que eles ocorram novamente. A gesto de alterao de Tecnologia (GT) identifica e transfere, de forma organizada, as tecnologias benficas de software (ferramentas, mtodos, processos) para um esforo de desenvolvimento de software. A gesto de alterao de Processo (GP) tem como objetivo continuar melhorando a qualidade e a produtividade do software, ao mesmo tempo em que diminui o tempo do ciclo para o desenvolvimento do produto de software. IIIPADRES DO SOFTWARE Muitas organizaes so fontes de padres de engenharia de software IEEE (Institute for Electrical and Electronic Engineers), ISO (International Standards Organization), ANSI (American National Standards Institute), DoD (U.S. Department of Defense), BS (British Standards Institute), IEE (Institute of Electrical Engineers no Reino Unido), CORBA (Common Request Object Broker Architecture) e OMG (Object Management Group) so fontes de padres de software. O IEEE publica regularmente os padres de desenvolvimento de software. Por exemplo, o Padro IEEE 380-1993 (Prtica Recomendada para a Especificao de Requisitos de Software) descreve o contedo e a qualidade de uma boa especificao de requisito de software. Esse padro fornece procedimentos uniformes para a descrio dos aspectos comportamentais (funcionais) e nocomportamentais (qualidade) de um produto de software. Atualmente, um esforo conjunto vem sendo feito para desenvolver padres internacionais para o desenvolvimento de software e gesto de configurao. Esse esforo patrocinado pelo ISO e pela OTAN (Organizao do Tratado do Atlntico Norte). O Padro OTAN 4591 orientado a hardware. Os padres ISO cobrem projeto e descrio (ISO 6593), documentao (ISO 9127) e gesto de qualidade de software (srie ISO 9000). A ANSI trabalha juntamente com o IEEE para produzir padres de desenvolvimento industrial de software. O DoD publica padres militares de software, entre os quais o mais

24 ENGENHARIA DE SOFTWARE proeminente o modelo de ciclo de vida de software para sistemas embutidos (Padro DoD 216 1988). O British Standards Institute e o IEE tambm so timas fontes de padres relativos a ca aspecto do desenvolvimento de software. O grupo OMG uma organizao internacional de comrcio fundada em 1989 e que j con com mais de 600 membros (veja http://www.omg.org). Tambm um dos maiores consrcios indstria de software. O CORBA criado pela OMG define o padro das capacidades que pern tem aos objetos agirem entre si. Os padres tambm so aplicados gesto de processo, pois fo necem uma base para um mtodo consistente de revisar a produo das equipes de desenvoh mento de software. L!II!!RESUMO A curiosidade a cura para o tdio. No existe cura para a curiosidade. - Dorothy Parker Este captulo oferece um passeio pelo terreno da engenharia de software. Apresenta, de un forma ampla, alguns de seus recursos, mtodos e problemas bsicos. Uma das principais caract rsticas desse terreno o esquema conceitual implcito no projeto de cada parte do software. C conjuntos de dados e, as relaes entre os itens de dados, os algoritmos e as chamadas de fun dentro de um programa refletem um esquema conceitual. Essa caracterstica positiva , ao mesm tempo, seu principal problema. E necessrio especificar, projetar e testar as construes conceiti ais no software que est sendo criado. Isso considerado difcil, pois a essncia de uma entidac de software uma construo de conceitos integrados. Duas caractersticas do software dificu tam a especificao, o projeto e os testes de sua construo conceitual. Em primeiro lugar, o sof ware basicamente abstrato difcil visualizar seu esquema conceitual. A abstrao uma caract rstica inerente e essencial do software. Uma segunda caracterstica que torna sua engenhari difcil a complexidade. J foram sugeridas muitas formas para solucionar o problema do softw re. Harlan Mills sugeriu que o software fosse desenvolvido de forma incremental. Os increment de software so mais fceis de serem compreendidos, descritos, projetados, testados e depurad do que sistemas completos. David Parnas sugeriu o que a modularidade e o encapsulamento de ir formaes so teis no projeto de software. A idia que est por trs disso que se deve concentr nos conceitos de projeto (o que uma funo faz) e ocultar os detalhes da sua implementao. Fre Brooks mostrou os benefcios dos refinamentos interativo e iterativo de requisitos com o auxli da prototipao rpida. Os prottipos so teis, pois possibilitam estudar comportamentos c software selecionados durante os estgios iniciais de um projeto. David Harel apresentou divers sugestes sobre como atacar as dificuldades essenciais do software. A idia central da abordagei de Harel a noo de um framework bsico de propsitos gerais, com razes na modularizao no encapsulamento de informaes, que tambm deve dar suporte especificao executvel, v so hierrquica da descrio funcional e comportamental do software, prototipao rpida e e pecificao

visual. A idia fundamental de um framework bsico no ocultar a complexidac mas gerenciar e controlar a complexidade do software. Em um framework bsico suportado p um sistema como o Rhapsody, da i-logix, isso significa criar um modelo executvel de um sist ma que represente clara e precisamente as funes e o comportamento desejados de um sisterr especificado. O Rhapsody um ambiente de programao visual orientado a objetos (ve http://www.ilogix.com). Viso do Terreno da Engenharia de Software 25 O desenvolvimento de software funciona bem quando tratado como uma disciplina da engenharia. O processo de software repetitivo at um certo grau se as prticas de gerenciamento de projeto bsicas estivessem corretas. Esse processo alcana o nvel definido quando padronizado. O nvel gerenciado do processo de software alcanado atravs de quantificao e treinamento. A gesto quantificada de um processo de software envolve medies de risco e desempenho da equipe de projeto, assim como definio de processo de software, manuteno e programa de treinamento ativo, O nvel otimizado do Modelo de Maturidade (CMM) caracterizado pela melhoria contnua do processo. Conhecer importante. Quantificar esse conhecimento introduz medies (nmeros) que podem ser delineadas e comparadas visando uma melhor compreenso do terreno. As medies fornecem um feedback valioso para os planejadores, facilitam o controle e a engenharia das alteraes de software e ajudam a identificar os pontos a serem melhorados no processo de software e seus produtos. Para projetar software de boa qualidade, necessrio compreender como ele ser utilizado e como sofrer alteraes no longo do tempo. Por esse motivo, a abordagem sala limpa de engenharia est vinculada ao desenvolvimento de modelos de utilizao de software. Um modelo de utilizao ajuda o desenvolvedor a estimar como uma parte de software (um incremento) ser utilizada, e avaliar os riscos associados sua utilizao. L.L EXERCCIOS 5 1. Efetue os seguintes procedimentos: (a) Identifique um programa de computador ou uma ferramenta que seja familiar (por exemplo, um pacote grfico, um processador de textos, uma planilha). (b) Selecione os critrios utilizados para medir o fator de qualidade de usabilidade. (c) Selecione um peso p para cada critrio da etapa (b), onde O _ p _ 1. (d) Selecione uma escala de valores para a pontuao dos critrios, onde O _ pontuao do critrio _ 10 (e) Selecione um valor mnimo e mximo a ser alcanado para cada pontuao de critrio da etapa (d). Para simplificar, selecione o mesmo intervalo mnimo e mximo para cada critrio. (f) Selecione um valor mnimo e mximo a ser alcanado para a pontuao da qualidade de usabilidade. (g) Crie uma tabela de avaliao de critrios de qualidade para o fator de qualidade de usabilidade dando uma pontuao para cada critrio da etapa (b).

(h) Calcule o fator de usabilidade. (i) Desenhe um diagrama Kiviat ilustrando as pontuaes dos critrios relativas ao intervalo mnimo e mximo da etapa (e). (j) Compare a pontuao da etapa (h) com o intervalo mnimo e mximo da etapa (f). (k) Compare as pontuaes da etapa (g) com os intervalos mnimo e mximo da etapa (e). (1) Baseado nas etapas (i) e (j), faa uma avaliao de qual melhoria a ser feita no software selecionado. 2. Efetue os seguintes procedimentos: (a) Escreva um programa de computador para automatizar o processo de medio do exerccio 1. (b) Simule a avaliao da qualidade de software com trs pontuaes de critrios separadas com relao pontuao de um fator que esteja abaixo de um intervalo mnimo e mximo especificado. (c) Faa um grfico das pontuaes dos critrios para cada uma das trs pontuaes de critrios da etapa (b). (d) Faa comentrios sobre as alteraes que voc achou necessrias para melhorar a pontuao do fator de qualidade de usabilidade do software selecionado. 26 ENGENHARIA DE SOFTWARE 3. Efetue os seguintes procedimentos: (a) Identifique uma organizao de criao de produtos que seja familiar. O(s) produto(s) da organizao nc precisa(m) ser software. (b) Crie uma tabela de nvel de maturidade repetitivo (incluindo sua avaliao de 1 a 10 dos recursos associados ao nvel inicial). (c) Escreva um programa de computador que automatize o processo de construo de tabelas da etapa (b). (d) Simule o nvel de maturidade repetitivo com trs conjunto