UNIVERSIDADE GAMA FILHO POSEAD

MARCOS ROGERIO SANTIAGO

Ensaio do SWEBOK Software Engineering Body Of Knowledge

GOINIA GO 2011

UNIVERSIDADE GAMA FILHO POSEAD

MARCOS ROGERIO SANTIAGO

Ensaio do SWEBOK Software Engineering Body Of Knowledge

Trabalho de Concluso de Curso apresentado em cumprimento s exigncias para obteno do ttulo de especialista latu sensu em Gesto de Tecnologia da informao da Universidade Gama Filho POSEAD Orientador: Professor Rogrio Alvarenga

GOINIA GO 2011

Agradeciemtos
Agradeo a minha esposa Tatiane por tanta pacincia nesse momento de minha vida. Quando eu mais precisei, l estava ela sendo aquele suporte necessrio. Ao professor Rogrio Alvarenga, que, com muita tranquilidade soube me ajudar nos momentos em que quase desisti. Agradeo tambm ao pessoal da Universidade Federal de Lavras pelo apoio e suporte recebidos. Sobretudo, ao meu bom Deus, que o responsvel por tudo o que acontece em minha vida. Minhas vitrias so, sem dvida, por causa Dele.

Resumo
Este trabalho tem por objetivo o estudo do SWEBOK, ferramenta criada pelo IEEE ( Institute of Electrical and Electronics Engineers), conhecida entidade de especificao de padres no mundo para ser a principal referncia para engenharia de software. Tem o objetivo tambm de fornecer uma traduo de sua ltima verso para a lngua portuguesa, e contribuir assim para o seu terceiro objetivo, que sua divulgao. O SWEBOK comparado a outros modelos de qualidade de software tem sua divulgao e utilizao tmida, mas em expanso. Possui seus critrios e contedos objetivos, claros e bem definidos, tornando-se uma ferramenta de excelncia em aplicabilidade na prtica, alm de fornecer formalizaes direcionadas para certificaes a profissionais e acadmicas.

Sumrio
Resumo.............................................................................................................................................................................................2 Lista de abreviaturas.......................................................................................................................................................................6 Lista de figuras.................................................................................................................................................................................8 1 Introduo......................................................................................................................................................................................9 1.1 Formulao do problema.......................................................................................................................................................9 1.2 Reviso de Literatura...........................................................................................................................................................10 1.3 Objetivos gerais...................................................................................................................................................................12 1.4 Objetivos especficos..........................................................................................................................................................12 1.5 Justificativa..........................................................................................................................................................................12 1.6 Delimitao do tema............................................................................................................................................................13 1.7 Metodologia de pesquisa.....................................................................................................................................................13 1.8 Estrutura do trabalho...........................................................................................................................................................13 2 Referencial terico......................................................................................................................................................................14 2.1 Aspectos do Conhecimento de Eng. de Software...............................................................................................................14 2.1.1 Histria.......................................................................................................................................................................14 2.1.2 Definies iniciais.......................................................................................................................................................16 2.1.2.1 Organizao Hierrquica..................................................................................................................................17 2.1.2.2 Material de referncia e matriz.........................................................................................................................18 2.1.2.3 Profundidade de tratamento.............................................................................................................................18 2.1.2.4 Estrutura de descrio das KAs......................................................................................................................20 2.1.2.5 KA de Requisitos de Software .........................................................................................................................20 2.1.2.6 KA de Design de Software................................................................................................................................22 2.1.2.7 KA de Construo de Software........................................................................................................................22 2.1.2.8 KA de Testes de Software.................................................................................................................................23 2.1.2.9 KA de Manuteno de Software.......................................................................................................................24 2.1.2.10 KA de Gerenciamento de Configurao do Software....................................................................................24 2.1.2.11 KA de Gerenciamento da Engenharia de Software........................................................................................25 2.1.2.12 KA Processo de Engenharia de Software......................................................................................................26 2.1.2.13 KA Ferramentas e Mtodos de Engenharia de Software...............................................................................26 2.1.2.14 KA Qualidade de Software..............................................................................................................................27 2.1.2.15 KA Disciplinas Relacionadas com Engenharia de Software..........................................................................27 2.1.2.16 Apndice A......................................................................................................................................................28 2.1.2.17 Apndice B......................................................................................................................................................28 2.1.2.18 Apndice C......................................................................................................................................................28 2.1.2.19 Apndice D......................................................................................................................................................28 2.1.3 reas de conhecimento.............................................................................................................................................31 2.1.3.1 Requisitos de Software.....................................................................................................................................31 2.1.3.1.1 Fundamentos de Requisitos de Software...............................................................................................32 2.1.3.1.2 Processo de Requisitos...........................................................................................................................34 2.1.3.1.3 Elicitao de Requisitos..........................................................................................................................35 2.1.3.1.4 Anlise de Requisitos..............................................................................................................................36 2.1.3.1.5 Especificao de Requisitos...................................................................................................................39 2.1.3.1.6 Validao de Requisitos.........................................................................................................................41 2.1.3.1.7 Consideraes Prticas..........................................................................................................................43 2.1.3.2 Design de Software..........................................................................................................................................46 2.1.3.2.1 Fundamentos do Design de Software ....................................................................................................48 2.1.3.2.2 Os Pontos Chave no Design de Software .............................................................................................50 2.1.3.2.3 Estrutura e Arquitetura de Software .......................................................................................................51

2.1.3.2.4 Anlise e Evoluo da Qualidade de Design de Software .....................................................................53 2.1.3.2.5 Notaes de Design de software ...........................................................................................................55 2.1.3.2.6 Estratgias e Mtodos de Design de Software ......................................................................................57 2.1.3.3 Construo de Software ..................................................................................................................................60 2.1.3.3.1 Fundamentos da construo de software...............................................................................................62 2.1.3.3.2 Gesto de Construo............................................................................................................................64 2.1.3.3.3 Consideraes prticas...........................................................................................................................65 2.1.3.4 Teste de Software ............................................................................................................................................70 2.1.3.4.1 Fundamentos de Teste de Software ......................................................................................................72 2.1.3.4.2 Nveis de Teste .......................................................................................................................................75 2.1.3.4.3 Tcnicas de Teste ...................................................................................................................................79 2.1.3.4.4 Medidas Relacionadas ao Teste ...........................................................................................................84 2.1.3.4.5 Processo de Teste ..................................................................................................................................87 2.1.3.5 Manuteno de Software .................................................................................................................................94 2.1.3.5.1 Fundamentos da Manuteno de Software............................................................................................95 2.1.3.5.2 Problemas chave na manuteno de software.......................................................................................99 2.1.3.5.3 Processo de manuteno....................................................................................................................106 2.1.3.5.4 Tcnicas de Manuteno......................................................................................................................112 2.1.3.6 Gerncia de Configurao de Software .........................................................................................................113 2.1.3.6.1 Gerenciamento dos Processos SCM....................................................................................................114 2.1.3.6.2 Identificao da Configurao de Software..........................................................................................121 2.1.3.6.3 Software de controle de configurao..................................................................................................124 2.1.3.6.4 Software de contabilidade do Status da Configurao 2.1.3.6.6 Software de Gerenciamento de Liberao e Entrega .................................126 ........................................................129 2.1.3.6.5 Auditoria de Configurao de Software................................................................................................127 2.1.3.7 Gerncia de Engenharia de Software .....................................................................................................131 2.1.3.7.1 Iniciao e Definio de escopo...........................................................................................................136 2.1.3.7.2 Planejamento de Projeto de Software..................................................................................................137 2.1.3.7.3 Formalizao do Projeto de Software...................................................................................................140 2.1.3.7.4 Anlise e Avaliao..............................................................................................................................142 2.1.3.7.5 Fechamento..........................................................................................................................................143 2.1.3.7.6 Mensurao/Medio de Engenharia de Software...............................................................................144 2.1.3.8 Processo de Engenharia de Software ...................................................................................................148 2.1.3.8.1 Processo de implementao e mudana..............................................................................................150 2.1.3.8.2 Definio de Processo..........................................................................................................................153 2.1.3.8.3 Avaliao de Processo..........................................................................................................................156 2.1.3.8.4 Processo e Medio de Produto...........................................................................................................157 2.1.3.9 Ferramentas e Mtodos da Engenharia de Software ...................................................................................164 2.1.3.9.1 Ferramentas da Engenharia de Software.............................................................................................165 2.1.3.9.2 Mtodos de Engenharia de Software....................................................................................................170 2.1.3.10 Qualidade de Software ................................................................................................................................172 2.1.3.10.1 Fundamentos da Qualidade de Software...........................................................................................173 2.1.3.10.2 Processos de Gesto da Qualidade de Software...............................................................................176 2.1.3.10.3 Consideraes prticas.......................................................................................................................183 2.1.3.11 Disciplinas Relacionadas Com Engenharia de Software.............................................................................192 2.1.3.11.1 Engenharia da Computao................................................................................................................192 2.1.3.11.2 Cincia da Computao......................................................................................................................193 2.1.3.11.3 Gerenciamento....................................................................................................................................194 2.1.3.11.4 Matemtica..........................................................................................................................................194 2.1.3.11.5 Gesto de Projetos..............................................................................................................................195

2.1.3.11.6 Gerncia de Qualidade........................................................................................................................196 2.1.3.11.7 Ergonomia de software........................................................................................................................196 2.1.3.11.8 Engenharia de sistemas......................................................................................................................198 2.1.4 Apndices.................................................................................................................................................................199 2.1.4.1 Apndice A......................................................................................................................................................199 2.1.4.1.1 Especificaes da Descrio de rea Para o SWEBOK......................................................................199 2.1.4.1.2 Critrios e Exigncias para Propor as Divises de Tpicos.................................................................199 2.1.4.1.3 Critrios e exigncias para descrever Tpicos ....................................................................................201 2.1.4.1.4 Critrios e exigncias para Selecionar Material de Referncia............................................................201 2.1.4.1.5 Critrios e exigncias para Identificar KAs das Disciplinas relacionadas............................................203 2.1.4.1.6 ndice dos Contedos Comuns.............................................................................................................203 2.1.4.1.7 O que Queremos Dizer com Conhecimento Geralmente Aceito?......................................................204 2.1.4.1.8 Comprimento de Descrio de reas do Conhecimento......................................................................205 2.1.4.1.9 Papel da Equipe Editorial......................................................................................................................205 2.1.4.1.10 Documentos Relacionados Importantes.............................................................................................206 2.1.4.1.11 Estilo e Diretrizes Tcnicas.................................................................................................................208 2.1.4.1.12 Outras Diretrizes Detalhadas..............................................................................................................208 2.1.4.1.13 Edio..................................................................................................................................................209 2.1.4.1.14 Liberao de Direitos Autorais............................................................................................................209 2.1.4.2 Apndice B......................................................................................................................................................210 2.1.4.2.1 Evoluo do SWEBOK..........................................................................................................................210 2.1.4.2.2 Stakeholders.........................................................................................................................................210 2.1.4.2.3 O Processo de Evoluo.......................................................................................................................211 2.1.4.2.4 Mudanas Antecipadas.........................................................................................................................213 2.1.4.3 Apndice C.....................................................................................................................................................214 2.1.4.3.1 Distribuio dos Padres de EG da IEEE/ISO para as KAs do SWEBOK..........................................214 2.1.4.4 Apndice D.....................................................................................................................................................226 2.1.4.4.1 Classificao dos Temas Segundo a Taxonomia de Bloom.................................................................226 3 Concluso..................................................................................................................................................................................234 3.1 Apresentao dos resultados............................................................................................................................................234 3.2 Principais contribuies.....................................................................................................................................................235 3.3 Aspectos positivos e Negativos.........................................................................................................................................235 3.4 Futuro do Guia...................................................................................................................................................................236 Bibliografia....................................................................................................................................................................................237

Lista de abreviaturas
ADL BABOK CASE CBD CCB CM CMMI COTS CRC DAG DFD EF EG ERD FCA FP FSM GCS HRM ICSM IDEAL IDL INCOSE KA MTBF OMG PCA PDCA PDL PMBOK QIP SADT SCAMPI SCCB SCE SCI SCM Architecture Description Languages Guide to the Business Analysis Body of Knowledge ComputerAided Software Engineering ComponentBased Design Configuration Control Board Configuration Management Capability Maturity Model Integration Commercial OfftheShelf Software Class Responsibility Collaborator card Directed Acyclic Graph Data Flow Diagram Experience Factory Engenharia de Sfotware Entity-Relationship Diagram Functional Configuration Audit Function Point Functional Size Measurement Gerncia de Configurao de Software Human Resources Management International Conference on Software Maintenance Initiating, Diagnostic, Establishing, Acting, Learning Interface Description Language International Council on Systems Engineering Knowledge Area Mean Time Between Failures Object Management Group Physical Configuration Audit Plan, Do, Check, Act Pseudo-Code and Program Design Language Guide to the Project Management Body of Knowledge Quality Improvement Paradigm Paradigma de Melhoria de Qualidade Structured Analysis and Design Tecnique Standard CMMI Appraisal Method for Process Improvement Software Configuration Control Board Software Engineering Evaluation Software Configuration Item Software Configuration Management

SCMP SCR SCSA SEI SEPG SQA SQM SRET SRS TQM UML USNRC V&V Y2K

Software Configuration Management Plan Software Change Request Software Configuration Status Accounting Software Engineering Institute Software Engineering Process Group Software Quality Assurance Software Quality Management Software Reliability Engineered Testing Software Requirement Specification Total Quality Management Unified Modeling Language U.S. Nuclear Regulatory Commission Verification and Validation Year 2000

Lista de figuras
Figura 1: Figura 2: Figura 3: Figura 4: Figura 5: Figura 6: Figura 7: Figura 8: Figura 9: reas de Conhecimento (KA) do SWEBOK Disciplinas relacionadas Categorias de Conhecimento Disciplinas relacionadas com engenharia de software Primeiras 5 reas do conhecimento ltimas 6 reas do conhecimento Tpicos dos Requisitos de software Viso simplista Viso realista

Figura 10: Tpicos para Design de Software Figura 11: Tpicos x referncias (1) Figura 12: Tpicos x referncias (2) Figura 13: Tpicos x referncias (3) Figura 14: Repartio dos tpicos para o rea de conhecimento de construo de software Figura 15: Tpicos para rea de Conhecimento Teste de Software Figura 16: Tpicos x referncias (4) Figura 17: Tpicos x referncias (5) Figura 18: Tpicos x referncias (6) Figura 19: Tpicos da Manuteno de software Figura 20: Atividades do Processo de Manuteno Figura 21: Processo de Manuteno de Software Figura 22: Tpicos da KA Gerncia de Engenharia de Software Figura 23: Tpicos para a KA Processo de Engenharia de Software Figura 24: Relao entre processos e resultados Figura 25: Tpicos da KA Ferramentas e Mtodos da Engenharia de Software Figura 26: Tpicos para a KA Qualidade de Software Figura 27: Tpicos x referncias (7) Figura 28: Tpicos x referncias (8) Figura 29: Tpicos x referncias (9) Figura 30: Disciplinas relacionadas Engenharia de Software Figura 31: Categorias de Conhecimento

1 Introduo 1.1 Formulao do problema

A Engenharia de Software uma rea do conhecimento da computao voltada para a especificao, desenvolvimento e manuteno de sistemas de software aplicando tecnologias e prticas de gerncia de projetos e outras disciplinas, objetivando organizao, produtividade e qualidade. Os fundamentos cientficos para a Engenharia de Software envolvem o uso de modelos abstratos e precisos que permitem ao engenheiro especificar, projetar, implementar e manter sistemas de software, avaliando e garantindo suas qualidades. Hoje em dia encontramos software em todas as partes. Esto nos celulares, nos aparelhos de cozinha, equipamentos mdicos, brinquedos, etc. Linhas de cdigo esto presentes em todos estes produtos e a cada dia temos mais produtos surgindo. Tudo isso sem entrarmos no campo das aplicaes web, dos sistemas empresariais, cientficos, educacionais, internet e por a vai. Com toda essa demanda a Engenharia de Software ainda uma rea nova, com poucas instituies que oferecem cursos de graduao. Em 1995, o padro internacional ISO/IEC 12207, serviu de subsdio para a elaborao do corpo de conhecimento da engenharia de software, o SWEBOK. Ocorre que o SWEBOK, um guia de referncia to importante, no tem o devido status do qual ele merece. No raro encontrar pessoas da rea de desenvolvimento que ainda no sabem de sua existncia. Cursos de ps-graduao com nfase em engenharia de software no fazem meno a este guia. Este trabalho se prope a traduo e ao detalhamento deste guia em nvel suficiente para que seja evidenciada sua importncia bem como sua divulgao.

1.2 Reviso de Literatura

Esta pesquisa influenciada pelos trabalhos de Jlio Csar Sampaio do Prado Leite e Roger S. Pressman. Roger S. Pressman uma autoridade internacionalmente reconhecida em melhoria de processo de software e tecnologias de engenharia de software. Por mais de trs dcadas, ele trabalhou como engenheiro de software, gerente, professor, autor e consultor, com foco em questes de engenharia de software. Dr. Pressman atualmente presidente do R. S. Pressman & Associates, Inc., uma empresa de consultoria especializada em mtodos de engenharia de software e formao. Dr. Pressman tem escrito muitos artigos tcnicos, um colaborador regular de revistas da indstria, e autor de seis livros. Jlio Csar Sampaio do Prado Leite Doutor em Cincia da Computao pela Universidade da Califrnia, Irvine, professor do Departamento de Informtica da PUC-RIO e vem realizando pesquisas na rea de Engenharia de Software. Professor da cadeira de Sistemas de Informao no Departamento de Informtica da UERJ. Consultor nas reas de Engenharia de Software e Sistemas de Informao. dele a citao:
A dcada de 60 e princpio da dcada de 70 mostraram a inviabilidade da ideia do sistema de informao global para toda uma organizao. pela desagradvel experincia de terem altssimos gastos A em despeito dos grandes avanos tecnolgicos, vrias organizaes passaram processamento de dados e, contrariamente ao esperado, terem acumulados grandes insucessos na implantao de ambiciosos Sistemas de Informao, os quais englobariam toda a organizao. Um Sistema de Informao no como muitos acreditavam e infelizmente, alguns ainda acreditam, um sistema puramente tcnico. ...Cabe a gerncia de Engenharia de Software todo o suporte no desenvolvimento e manuteno do software constante do sistema computacional de apoio aos Sistemas de Informao da organizao.

O Instituto de Engenheiros Eletricistas e Eletrnicos (IEEE) uma organizao profissional sem fins lucrativos, fundada nos Estados Unidos. a maior (em nmero de scios) organizao profissional do mundo. O IEEE foi formado em

10

1963 pela fuso do Instituto de Engenheiros de Rdio (IRE) com o Instituto Americano de Engenheiros Eletricistas (AIEE). O IEEE tem filiais em muitas partes do mundo, sendo seus scios engenheiros eletricistas, engenheiros da computao, cientistas da. computao, profissionais de telecomunicaes etc. Sua meta promover conhecimento no campo da engenharia eltrica, eletrnica e computao. Um de seus papis mais importantes o estabelecimento de padres para formatos de computadores e dispositivos. A leitura destes autores foi de fundamental importncia para que se observasse a necessidade de uma ferramenta que agrupasse as melhores prticas, as melhores ideias em nvel mundial, na rea de Engenharia de Software, em um local, e a partir de onde as direes para o futuro dessa nova cincia fossem apontadas.

11

1.3 Objetivos gerais

Promover o maior conhecimento do SWEBOK pelos profissionais que atuam na engenharia de software e fornecer um primeiro contato ao corpo de conhecimento de Engenharia de Software.

1.4 Objetivos especficos

Contextualizao da utilizao do guia SWEBOK Definio dos principais conceitos de Engenharia de Software Exposio das reas de conhecimento Exposio das disciplinas relacionadas Engenharia de Software Expanso do uso do guia SWEBOK

1.5 Justificativa
Roger Pressman, no livro Engenharia de Software, 6a edio, 2006, captulo 1 pgina 13, diz:
"O software tornou-se o elemento chave na evoluo de sistemas e produtos baseados em computador, e uma das tecnologias mais importantes em todo o mundo. Ao longo dos ltimos 50 anos, o software evoluiu de um ferramental especializado em soluo de problemas e anlise de informaes para um produto de indstria. Mas ainda temos problemas na construo de software de alta qualidade no prazo e dentro do oramento. O software - programas, dados e documentos - dirigido a uma ampla variedade de tecnologias e aplicaes, continua a obedecer a uma srie de leis que permanecem as mesmas h cerca de 30 anos. O intuito da engenharia de software fornecer uma estrutura para a construo de software com alta qualidade".

A partir do posicionamento de Pressman, inferimos a necessidade de se manter uma documentao padronizada e dinmica que incorpore as melhores prticas e metodologias, norteando, em nvel global, os rumos desta relativamente

12

nova cincia que desponta.

1.6 Delimitao do tema

Este trabalho tem como objetivo o estudo e divulgao do guia SWEBOK, buscando a ampliao do seu uso entre os profissionais da rea de engenharia de software, corroborando ainda para sua sedimentao como principal ferramenta para padronizao de conceitos no mundo.

1.7 Metodologia de pesquisa

Este trabalho foi realizado com base em pesquisas bibliogrficas que serviram de fundamentao a sua ideia principal, a centralizao de padronizaes. Para isso, o uso da internet para localizao de informaes relevantes, foi de crucial valor. A pesquisa bibliogrfica justifica-se por se tratar de tema que no fora abordado no curso de especializao e por se entender que algo de suma importncia para a disciplina de engenharia de software. Tal ferramenta SWEBOK deveria ser um dos temas principais a serem abordados pela sua riqueza de informaes, que tem como uma de suas premissas manter-se sempre atualizado.

1.8 Estrutura do trabalho

Este trabalho foi elaborado de acordo com os pargrafos a seguir: O Captulo 1 trata as razes que motivaram a pesquisa, a formulao do problema, as exposies do objetivo geral e dos objetivos especficos, a justificao do tema do trabalho e sua delimitao. O Captulo 2 trata dos fundamentos tericos para o trabalho, seus aspectos e como formada sua estrutura. No tpico Histria, faz uma descrio de toda a origem da engenharia de software desde suas primeiras menes nos meios sociais at a data presente. No tpico Estrutura de Descrio das KAs informado como o documento foi pensado de forma a resolver algum problema do mundo real. Nos

13

tpicos subsequentes so detalhadas todas as reas do conhecimento na forma como elas sero abordadas. Tambm informa a maneira como deve ser compreendida cada KA e uma breve descrio dos seus objetivos. Os tpicos dos apndices A, B, C e D referem-se aos suplementos e informaes necessrias para a manuteno do prprio guia, tais como critrios, conselhos, padres e taxonomia. No Captulo 3 so abordadas as concluses deste trabalho.

2 Referencial terico 2.1 Aspectos do Conhecimento de Eng. de Software

2.1.1 Histria
Em 1958, John Tukey, o estatstico de renome mundial, cunhou o termo software. O termo "Engenharia de Software" foi utilizado no ttulo de uma conferncia da Otan, realizada na Alemanha em 1968. Em 1972, a IEEE Computer Society publica pela primeira vez seu relatrio sobre Engenharia de Software. Em 1976 foi fundada uma comisso dentro da IEEE Computer Society com a incumbncia de desenvolver padres de engenharia de software. A primeira viso geral sobre Engenharia de Software a sair da IEEE Computer Society resultou de um esforo liderado por Fletcher Buckley, no padro IEEE 730 que versava sobre garantia de qualidade de software e que foi concludo em 1979. O propsito do padro IEEE 730 era fornecer requisitos mnimos de uniformidade para a preparao e contedo do planejamento de software. Esta norma influenciou o desenvolvimento e concluso de outros temas: gerenciamento de configurao, teste de software, requisitos de software, design de software, verificao e validao de software. No perodo de 1981-1985, a IEEE Computer Society realizou uma srie de oficinas sobre a aplicao de padres de engenharia de software. Nessas oficinas, profissionais envolvidos compartilhavam suas experincias com as atuais normas. Tambm se realizavam nessas oficinas sesses onde eram discutidos os rumos para as normas, incluindo as medidas e mtricas para a engenharia de software, produtos e processos. O planejamento resultou tambm no padro IEEE 1002, padro de taxonomia de engenharia de software (1986), que proporcionou uma nova viso de

14

engenharia de software. O padro descreve a forma e contedo da taxonomia dos padres de engenharia de software. Ele explica vrios tipos de padres, seus relacionamentos funcionais e externos bem como o papel das vrias funes participantes no ciclo de vida do software. Em 1990, o planejamento para um padro internacional com uma viso geral foi iniciado. Este planejamento foi focado em conciliar os pontos de vista de processo de software da IEEE 1074 e revisado pelo padro U.S. DoD 2167A. Esta reviso foi finalmente publicada como DoD Std 498. O padro internacional foi terminado em 1995 com a designao ISO/IEC 12207 e dado o ttulo de padro para os processos de ciclo de vida do software. O padro ISO/IEC 12207 forneceu um importante ponto de partida para o corpo de conhecimentos deste guia. Foi o Conselho de tutores do IEEE Computer Society que aprovou a moo apresentada em maio de 1993 por Fletcher Buckley que resultou na eleborao do guia. O conselho da Association for Computing Machinery (ACM) aprovou a referida moo em agosto de 1993. As duas propostas levaram a criao de uma comisso mista, sob a liderana de Mario Barbacci e Stuart Zweben que atuaram como copresidentes A misso da comisso mista era "Estabelecer os conjuntos de critrios e normas adequadas para a prtica profissional da engenharia de software sobre a qual decises industriais, certificaes profissionais e currculos educacionais pudessem se basear". A direo do comit organizou grupos de trabalho nas seguintes reas: 1 - Definio do corpo de conhecimentos e prticas recomendadas; 2 - Definio de tica e padres profissionais; 3 - Definio de currculos educacionais para graduao, ps-graduao e educao continuada. Este guia fornece o primeiro componente: Corpo de conhecimentos e prticas recomendadas. O cdigo de tica e padres profissionais de engenharia de software foi concludo em 1998 e aprovado tanto pelo conselho da ACM quanto pelo conselho da IEEE e tem sido adotado por inmeras empresas e outras organizaes. O currculo educacional para alunos de graduao foi concludo com esforo da IEEE e ACM em 2004.

15

2.1.2 Definies iniciais

O Guia no deve ser confundido com o Corpo de Conhecimento propriamente dito, que j existe publicado na literatura. O propsito do guia descrever qual poro do Corpo de Conhecimento geralmente aceito, para organizar esta poro, e para fornecer um acesso atual a esta. Informaes adicionais ao significado dado geralmente aceito podem ser encontradas adiante no Apndice A. O Guia para o Corpo de Conhecimento de Engenharia de Software SWEBOK - foi estabelecido com os cinco seguintes objetivos: 1. Promover uma viso consciente da engenharia do software no mundo inteiro; 2. Esclarecer o lugar "e estabelecer o limite" da engenharia de software com respeito a outras disciplinas como cincia da computao, gerenciamento de projetos, engenharia da computao, e matemtica; 3. Caracterizar os contedos da disciplina de engenharia de software; 4. Fornecer um acesso ao Corpo de Conhecimento de Engenharia de Software; 5. Fornecer uma base para desenvolvimento de currculo, certificao individual e licenciamento de material; O primeiro desses objetivos, uma viso mundial consistente da engenharia de software, foi apoiada por um processo de desenvolvimento que empregou aproximadamente 500 revisores de 42 pases na fase de Stoneman (19982001) levando verso de Prova, e mais de 120 revisores de 21 pases na fase de Ironman (2003) levando verso 2004. Mais informao quanto ao processo de desenvolvimento pode ser encontrada no Prefcio e no site www.swebok.org. As sociedades profissionais e eruditas e as agncias pblicas implicadas na engenharia de software foram oficialmente contatadas, feitas conscientes deste projeto, e convidadas para participar do processo de reviso. Editores associados foram recrutados de Amrica Norte, Costa Pacfica e Europa. Apresentaes do projeto foram feitas em vrios eventos internacionais e outras foram planejadas para o prximo ano. O segundo dos objetivos, o desejo de estabelecer um limite da engenharia de software, motiva a organizao fundamental do guia. O material que reconhecido como sendo parte desta disciplina organizado nas dez primeiras reas de Conhecimento (Knowledge Areas - KA) enumeradas na Figura 1. Cada uma dessas

16

KAs tratada como um captulo neste guia.

Requisitos de Software Design de Software Construo de Software Teste de Software Manuteno de Software Gerncia de Configurao de Software Gerncia da Engenharia de Software Processo de Engenharia de Software Ferramentas e Mtodos da Engenharia de Software Qualidade de Software
Figura 1: reas de Conhecimento (KA) do SWEBOK

No estabelecimento de um limite, tambm importante identificar que disciplinas compartilham este limite, e muitas vezes uma interseco comum, com a engenharia de software. Para este fim, o Guia tambm reconhece oito disciplinas relacionadas, enumeradas na figura 2. Engenheiros de software, naturalmente, devem ter conhecimento do material desses campos (e as descries das KAs podem fazer referncia a eles). Contudo, no um objetivo do Guia caracterizar o conhecimento das disciplinas relacionadas, mas ao invs, que conhecimento visto como especfico engenharia de software.

* Administrao * Cincias da Computao * Engenharia de Computao * Engenharia de Sistemas

Figura 2: Disciplinas relacionadas

* Ergonomia de Software * Gerenciamento da Qualidade * Gerenciamento de Projetos * Matemtica

2.1.2.1 Organizao Hierrquica A organizao das descries das KAs, apoia o terceiro objetivo do projeto uma caracterizao dos contedos da engenharia de software. Especificaes detalhadas fornecidas pela equipe editorial do projeto aos editores associados quanto aos contedos das descries das KAs podem ser encontradas no Apndice A.

17

O Guia usa uma organizao hierrquica para decompor cada KA em um conjunto de tpicos com ttulos reconhecveis. Dois ou trs nveis de separao fornecem um modo razovel de encontrar tpicos de interesse. O Guia trata os tpicos selecionados em uma maneira compatvel com as principais escolas do pensamento e com separaes geralmente encontradas na indstria e na literatura de engenharia de software e padres. As separaes dos tpicos no presumem determinados domnios de aplicao, usos para negcios, filosofia de gerncia, mtodos de desenvolvimento, e assim por diante. A extenso da descrio de cada tpico somente a necessria para entender a natureza geralmente aceita dos tpicos e para o leitor encontrar com sucesso o material de referncia. 2.1.2.2 Material de referncia e matriz Para fornecer um acesso atual ao conhecimento o quarto objetivo do projeto o Guia identifica o material de referncia de cada KA, inclusive captulos de livros, artigos referenciados, ou outras fontes reconhecidas de informao com autoridade. Cada descrio da KA tambm inclui uma matriz que relaciona o material de referncia aos tpicos enumerados. O volume total da literatura pretende-se que seja dominado pela realizao de uma educao universitria com mais quatro anos da experincia. Pode-se argumentar que algumas KAs, como projeto de software, por exemplo, merecem mais pginas de material de referncia do que outros. Tal modulao pode ser aplicada em futuras edies do Guia. Deve-se observar que o Guia no tenta ser abrangente nas suas citaes. Muito material que tanto conveniente quanto excelente no referenciado. O material foi selecionado em parte porque tomado como uma coleo fornece a cobertura dos tpicos descritos. 2.1.2.3 Profundidade de tratamento De incio, uma pergunta surgiu quanto profundidade do tratamento que o Guia deve fornecer. A equipe de projeto adotou uma abordagem que apoia o quinto objetivo do projeto fornecimento de uma base de desenvolvimento de currculo, certificao, e licena. A equipe editorial aplicou o critrio de conhecimento geralmente aceito, a distino de conhecimento avanado e de pesquisa (com base

18

em maturidade) e do conhecimento especializado (com base em generalidade da aplicao). A definio vem do Instituto de Gerenciamento de Projetos (Project Management Institute - PMI): O conhecimento geralmente aceito aplica-se maior parte de projetos, na maior parte do tempo, e o consenso comum valida o seu valor e a eficcia.

Figura 3: Categorias de Conhecimento

Contudo, o termo geralmente aceito no implica que o conhecimento indicado deva ser uniformemente aplicado a todas as tentativas de engenharia de software as necessidades de cada projeto determinam isto mas implica que engenheiros de software competentes e capazes devam ser equipados com este conhecimento para potencial aplicao. Mais precisamente, o conhecimento geralmente aceito deve estar includo no material de estudo do exame de licena de engenharia de software que graduados deveriam prestar depois de quatro anos da experincia de trabalho. Embora este critrio seja especfico ao estilo de educao dos Estados Unidos e no necessariamente se aplique a outros pases, foi considerado til. No entanto, as duas definies de conhecimento geralmente aceito

19

devem ser vistas como complementares. 2.1.2.4 Estrutura de descrio das KAs A descrio das KAs so estruturadas como a seguir. Na introduo, uma breve definio da KA e um resumo do seu respectivo escopo e do relacionamento entre outras KA so apresentados. O desdobramento em tpicos que compe a estrutura central da descrio da KA feita, descrevendo a decomposio da KA em subreas, tpicos e sub tpicos. Para cada tpico ou sub tpico, uma descrio curta fornecida, junto com uma ou mais referncias. O material de referncia foi escolhido porque se considera que ele constitui a melhor apresentao do conhecimento quanto ao tpico tratado, considerando as limitaes impostas escolha de referncias. Uma matriz liga os tpicos ao material de referncia. A ltima parte da descrio da KA a lista de referncias recomendadas. O Apndice A de cada KA inclui sugestes leituras complementar para aqueles usurios que desejam aprender mais sobre os tpicos da KA. O Apndice B apresenta a lista de padres mais relevantes para a KA. 2.1.2.5 KA de Requisitos de Software Um requisito definido como uma propriedade que deve ser exposta para resolver algum problema do mundo real. A primeira subrea de conhecimento chamada de Fundamentos de Requisitos de Software. Ela inclui definies dos prprios requisitos de software, mas tambm os principais tipos de requisitos como: diferena entre produto e processo, propriedades funcionais e no funcionais e propriedades emergentes. A subrea tambm descreve a importncia de requisitos quantificveis e tambm apresenta a diferena entre requisitos de software e requisitos de sistemas. A segunda subrea de conhecimento o Processo de Requisitos, que introduz o prprio processo, orientando o resto das cinco subreas e exposio como a engenharia de requisitos se relaciona com os demais processos de engenharia de software. Ela descreve modelos de processo, atores de processo, processos de suporte e gerenciamento, e o processo de qualidade e melhoria. A terceira subrea a Elicitao de Requisitos, que descreve de onde os

20

requisitos de software vm e como o engenheiro de software pode obt-los. Ele inclui as fontes de requisitos e tcnicas elicitao. A quarta subrea, Anlise de Requisitos, se preocupa com o processo de analisar os requisitos para: Detectar e resolver conflitos entre requisitos Descobrir os limites do software e como ele deve interagir com o seu ambiente Elaborar requisitos de sistema de forma a se transformarem requisitos de software A anlise de requisitos inclui a classificao dos requisitos, a modelagem conceitual, o desenho da arquitetura e alocao de requisitos, e a negociao de requisitos. A quinta subrea a Especificao de Requisitos. A especificao de requisitos tipicamente refere-se produo de um documento, ou o seu equivalente eletrnico, que pode ser sistematicamente revisto, avaliado e aprovado. Para sistemas complexos, em particular os que implicam o uso de componentes que no necessariamente so software. No mnimo, trs tipos diferentes de documentos so produzidos: definio de sistema, especificao de requisitos do sistema, e especificao de requisitos de software. A subrea descreve os trs documentos e as atividades subjacentes. A sexta subrea a Validao de Requisitos, cujo objetivo buscar qualquer problema antes que os recursos sejam implantados no envio dos requisitos. A validao de requisitos preocupa-se com o processo de examinar os documentos de requisitos para assegurar que eles esto definindo o sistema correto (isto , o sistema que o usurio espera). subdividido em descries de procedimento de reviso de requisitos, prototipao, validao de modelo e testes de aceitao. A stima subrea, que a ltima subrea, chamada de Consideraes Prticas. Ela descreve os tpicos que tm de ser compreendidos na prtica. O primeiro tpico a natureza iterativa do processo de requisitos. Os prximos trs tpicos so fundamentalmente sobre a gerncia de mudanas e a manuteno de requisitos em um estado que exatamente reflete o software a ser construdo, ou que j tenha sido construdo. Ele inclui gerncia de mudanas, atributos de requisitos, e investigao de requisitos. O tpico final a medio de requisitos.

21

2.1.2.6 KA de Design de Software De acordo com a definio do IEEE [IEEE 610.12-90], design "o processo de definir a arquitetura, componentes, interfaces, e outras caractersticas de um sistema ou componente" e tambm "o resultado de processo". A KA Design de Software dividida em seis subreas. A primeira subrea apresenta os Fundamentos de Design de Software, que formam uma base subjacente compreenso do papel e do escopo do design de software. Existem conceitos de software genricos, o contexto do design de software, o processo de design de software, e as tcnicas de autorizao de design de software. A segunda subrea agrupa o conjunto de Questes-chave em Design de Software. Essas questes chaves incluem colaborao, controle e tratamento de eventos, a distribuio de componentes, tratamento de excees e erros e tolerncia falha, interao e apresentao, e persistncia de dados. A terceira subrea Estrutura e Arquitetura de Software, os tpicos da qual so estruturas de arquiteturas e pontos de vista, estilos de arquitetura, padres de design, e, finalmente, as famlias dos programas e frameworks. A quarta subrea descreve Anlise de Qualidade do Design e Avaliao do software. Enquanto existe uma KA inteira dedicada qualidade de software, esta subrea apresenta os tpicos especificamente relacionados ao design de software. Esses aspectos so atributos de qualidade, anlise de qualidade, e tcnicas de avaliao e medidas. A quinta subrea Notaes de Design de Software, que dividida em descries estruturais e comportamentais. A ltima subrea descreve Estratgias de Design de Software e Mtodos. Primeiro, as estratgias gerais so descritas, seguidas por mtodos de design orientados por funo, mtodos de design orientados a objeto, design centrando na estrutura de dados, design baseado em componentes e outros. 2.1.2.7 KA de Construo de Software Construo de software se refere criao detalhada de trabalho, significando software atravs da combinao de codificao, verificao, testes de

22

unidades, testes de integrao, e depurao. A KA possui trs subreas. A primeira subrea chamada de Fundamentos de Construo de Software. Os trs primeiros tpicos so princpios bsicos da construo: minimizao da complexidade, antecipao de mudanas e construo com foco na verificao. O tpico ltimo discute padres da construo. A segunda subrea descreve o Gerenciamento da Construo. Os tpicos tratados so modelos de construo, planejamento da construo e mensurao da construo. A terceira subrea cobre as Consideraes Prticas. Os tpicos so design de construo, linguagens de programao, codificao, teste de construo, reutilizao, qualidade de construo, e integrao. 2.1.2.8 KA de Testes de Software Teste de Software compe-se da verificao dinmica de uma seleo de domnios de execues normalmente infinito, contra o comportamento esperado. Ela inclui cinco subreas. A KA inicia com a descrio de Fundamentos de Testes de Software. Primeiro a terminologia de testes de apresentada, ento so descritos assuntos relacionados com testes de software, e finalmente, os relacionamentos entre testes e as outras atividades so descritos. A segunda subrea chamada de Nveis de Teste. dividida entre os alvos dos testes e os objetivos dos testes. A terceira subrea chamada de Tcnicas de Teste. A primeira categoria inclui os testes baseados na intuio e experincia do testador. Um segundo grupo compreende tcnicas baseadas na especificao, seguidas por baseadas no cdigo, em falhas, no uso e baseadas na natureza da aplicao. Uma discusso de como selecionar e combinar as tcnicas apropriadas tambm apresentada. A quarta subrea cobre Mensuraes Relacionadas aos Testes. As medidas so agrupadas conforme o relacionamento de forma a avaliar o programa que esta sofrendo testes e avaliar o os testes executados. A ltima subrea descreve o Processo de Testes e inclui consideraes prticas e as atividades de teste.

23

2.1.2.9 KA de Manuteno de Software Uma vez na operao, as anomalias so descobertas, modificao no ambientes operacional, e novos requisitos dos usurios so expostos. A fase de manuteno do ciclo de vida comea a partir da entrega, porem, as atividades de manuteno ocorrem muito antes. A KA de Manuteno de Software dividida em quatro subreas. Primeiramente apresentado os Fundamentos de Manuteno de Software: definies e terminologia, a natureza de manuteno, a necessidade de manuteno, os principais custos de manuteno, evoluo de software e as categorias de manuteno. A segunda subrea agrupa as Questes-chave em Manuteno de Software. So as questes tcnicas, de gerncia, estimativas de custos de manuteno, e a mensurao da manuteno de software. A terceira subrea descreve o Processo de Manuteno. Os tpicos aqui so os processos de manuteno e atividades de manuteno. Tcnicas para Manuteno constituem a quarta subrea. Essa subrea inclui a compreenso de programa, a reengenharia, e a engenharia reversa. 2.1.2.10 KA de Gerenciamento de Configurao do Software A Gerncia de Configurao de Software (GCS) a disciplina de identificar a configurao do software em pontos distintos no tempo com o propsito de sistematicamente controlar modificaes configurao e de manter a integridade e a auditoria da configurao em todas as partes do ciclo de vida de sistema. Este KA inclui seis subreas. A primeira subrea a Gerncia do Processo de GCS. Ela cobre os tpicos do contexto organizacional de GCS, limites e orientao para o GCS, planejamento para o GCS, o prprio plano de GCS, e a monitorao da GCS. A segunda subrea a Identificao de Configurao de Software, que identifica itens a serem controlados, estabelece esquemas de identificao dos itens e as suas verses, tambm estabelece os instrumentos e tcnicas a serem utilizadas na aquisio e no gerenciamento dos itens controlados. Os primeiros tpicos nesta subrea so a identificao dos itens a serem controlados e a biblioteca de software. A terceira subrea o Controle de Configurao de Software, que a

24

gerncia de mudanas durante o ciclo de vida de software. Os tpicos so: primeiro, solicitando, avaliando, e aprovando alteraes no software; em segundo lugar, implementao de modificaes no software; e terceiro, desvios e no aprovaes (renncia de alteraes). A quarta subrea a Registros de Estado de Configurao de Software. Os seus tpicos so a informao sobre posio de configurao doe software e a reportagem do estado de configurao do software. A quinta subrea a Auditoria de Configurao de Software. Ele compe-se da auditoria de configurao funcional do software, auditoria de configurao fsica do software, e auditorias no processo a partir de uma base de referncia do software. A ltima subrea a Gerncia de Liberao e Entrega de Software, cobrindo elaborao de verses de software e gerenciamento de liberao de software. 2.1.2.11 KA de Gerenciamento da Engenharia de Software O KA Gerenciamento da Engenharia de Software, aponta o gerenciamento e mensurao da engenharia de software. Enquanto a mensurao um aspecto importante em todas as KAs, est aqui que o tpico de programas de mensurao apresentado. H seis subreas na KA de gerenciamento de engenharia de software. As cinco primeiras cobrem assuntos relacionados com gerenciamento de projetos de software e a sexta o sexto descrevem programas de mensurao de software. A primeira subrea a Iniciao e Definio de Escopo, que compreende a determinao e a negociao de requisitos, anlise de praticabilidade, e processo da reavaliao e a reviso de requisitos. A segunda subrea o Planejamento de Projeto de Software e inclui o planejamento de processo, determinando pacotes de trabalhos (deliverables), o esforo, agendamento e a estimativa de custos, a alocao de recursos, a gerncia dos riscos, a gerncia de qualidade, e o plano de gerenciamento. A terceira subrea a Aprovao do Projeto de Software. Os tpicos tratados nesta KA so a implementao de planos, gerncia de contrato de fornecedores, a implementao do processo de mensurao, monitorao de processo, controle de processo, e a divulgao de informaes do projeto. A quarta subrea Reviso e Avaliao, que inclui os tpicos de determinar a

25

satisfao dos requisitos e reviso e avaliao da performance. A quinta subrea descreve o Fechamento: determinao de fechamento e atividades de fechamento. Finalmente, a sexta subrea descreve a Mensurao da Engenharia de Software, mais especificamente, programas de mensurao. As mensuraes de produto e processos so descritos na KA Processo de Engenharia de Software. Muitas outras KA tambm descrevem medidas especficas para a sua respectiva KA. Os tpicos desta subrea incluem o estabelecimento e comprometimento da mensurao, planejamento do processo de mensurao, execuo do processo de mensurao, e avaliao da mensurao. 2.1.2.12 KA Processo de Engenharia de Software A KA Processo de Engenharia de Software trata da definio, implementao, avaliao, mensurao, gerenciamento, alteraes e melhora do prprio processo de engenharia de software. dividida em quatro subreas. A primeira subrea apresenta o Processo de Implementao e Mudanas. Os tpicos nesta KA so a infraestrutura de processo, o ciclo do processo de gerenciamento do software, modelos de implementao do processo e mudanas e consideraes prticas. A segunda subrea trata da Definio do Processo. Ela inclui os tpicos de modelos de ciclo de vida do software, processos de ciclo de vida de software, notaes das definies do processo, adaptao do processo e automao. A terceira subrea a Avaliao de Processo. Os tpicos aqui incluem modelos de avaliao de processo e mtodos de avaliao do processo. A quarta subrea descreve Mensurao de Produto e Processo. O processo de engenharia de software cobre a medio do produto de processo em geral. As mensuraes especficas de cada KA so abordadas nas respectivas KA. Os tpicos so mensurao do processo, mensurao do produto de software, a qualidade da mensurao dos resultados, modelos de informao de software e tcnicas de mensurao do processo. 2.1.2.13 KA Ferramentas e Mtodos de Engenharia de Software A KA Ferramentas e Mtodos para Engenharia de Software inclui, como a

26

prpria descrio apresenta, ferramentas para serem aplicadas engenharia de software e tambm mtodos para serem aplicados na engenharia de software. A subrea de Ferramentas para Engenharia de Software usa a mesma estrutura que Guia, com um tpico de cada uma das nove KAs de engenharia de software. Em um tpico adicional fornecido: assuntos sobre ferramentas diversas, como ferramentas para tcnicas de integrao, que so potencialmente aplicveis a todas as classes de ferramentas. A subrea Mtodos para Engenharia de Software dividida em quatro subsees: mtodos heursticos que tratam com aproximaes informais, mtodos formais que se baseiam em aproximaes matematicamente, e mtodos de prototipao se baseiam em aproximaes de desenvolvimento de software em torno de mltiplas formas de prototipao. 2.1.2.14 KA Qualidade de Software A KA Qualidade de Software aborda consideraes relativas qualidade de software que vo alm dos processos de ciclo de vida de software. Um vez que a qualidade de software um assunto presente em todas as partes na engenharia de software, tambm considerado em muitas outras KAs, e o leitor notar pontos desta KA nas outras KAs do Guia. Esta KA possui trs subreas. A primeira subrea descreve Fundamentos da Qualidade de Software como uma cultura e tica na engenharia de software, os valores e custos da qualidade, caractersticas de modelos e qualidade, e melhoria da qualidade. A segunda subrea trata dos Processos de Gerenciamento da Qualidade do Software. Os tpicos tratados aqui so garantia da qualidade de software, verificao e validao, e por fim, revises e auditorias. A terceira e ltima subrea descreve Consideraes Prticas relacionadas qualidade de software. Os tpicos so requisitos de qualidade de software, caracterizao de defeito, tcnicas de gerenciamento da qualidade do software, e mensurao da qualidade do software. 2.1.2.15 KA Disciplinas Relacionadas com Engenharia de Software O ltimo captulo trata das disciplinas relacionadas com a engenharia de software. Para circunscrever a engenharia de software, necessrio identificar as

27

disciplinas com que a engenharia de software compartilha limites. Este captulo identifica, em ordem alfabtica, essas disciplinas relacionadas. Para cada disciplina relacionada, e utilizao de uma fonte reconhecida base de consenso, so identificados: uma definio informativa (quando factvel); uma lista de KAs. As seguintes disciplinas so relacionadas com a engenharia de software: * Administrao * Cincias da Computao * Engenharia de Computao * Engenharia de Sistemas * Ergonomia de Software * Gerenciamento da Qualidade * Gerenciamento de Projetos * Matemtica

Figura 4: Disciplinas relacionadas com engenharia de software

2.1.2.16 Apndice A O apndice descreve as especificaes fornecidas pela equipe editorial aos editores associados para o contedo, referncias recomendadas, formato, e estilo das descries das KAs. 2.1.2.17 Apndice B O segundo apndice descreve a proposta do projeto da evoluo da Guia. O Guia 2004 simplesmente a edio atual de um guia que continuar evoluindo para conhecer as necessidades da comunidade de engenharia de software. O planejamento quanto evoluo ainda no esta completo, mas uma tentativa feita com este apndice. Como est sendo escrito, este processo foi endossado pelo Industrial Advisory Board e resumido para o Board of Governors da Computer Society do IEEE, porm, ainda no consolidado ou implementado. 2.1.2.18 Apndice C O terceiro apndice um conjuntos dos padres mais relevantes, sendo a maior parte formada por padres do IEEE e da ISO, alocada para as KAs do Guia SWEBOK. 2.1.2.19 Apndice D Como uma ajuda, notavelmente dos currculos dos desenvolvedores (e outros usurios), em suporte ao quinto objetivo do projeto, o quarto apndice aponta um

28

conjunto de categorias pedaggicas comumente atribudas a Benjamin Bloom. O conceito que os objetivos educativos podem ser classificados em seis categorias representando crescimento de profundidade: conhecimento, compreenso, aplicao, anlise, sntese, e avaliao. Os resultados deste exerccio para todas as KAs podem ser encontrados no apndice D. Este apndice no deve, contudo, ser examinado como uma classificao definitiva, mas muito mais como um ponto de partida.

Figura 5: Primeiras 5 reas do conhecimento

29

Figura 6: ltimas 6 reas do conhecimento

30

2.1.3 reas de conhecimento

2.1.3.1 Requisitos de Software A rea de conhecimento Requisitos de Software trata da elicitao, anlise, especificao e validao dos requisitos de software. A m conduo dessas atividades tornam projetos de engenharia de software criticamente vulnerveis. Requisitos de Software expressam as necessidades e restries colocadas sobre um produto de software que contribui para a soluo de um problema do mundo real. O termo Engenharia de Requisitos muito utilizado para denotar um tratamento sistemtico dos requisitos. Por consistncia, ser evitado o uso do termo neste guia. A rea Requisitos de Software fortemente relacionada a: Design do Software; Teste de Software; Manuteno do Software; Gerncia de Configurao do Software; Gerncia da Engenharia de Software; Processo de Engenharia de Software; Qualidade de Software. A diviso aqui adotada inteiramente compatvel com as sees da IEEE 12207 que referem-se s atividades de requisitos. Um risco inerente diviso proposta que um modelo do tipo cascata pode ser inferido. Para se precaver disso, a sub rea 2, Processos de Requisitos, projetada para prover uma viso geral em alto nvel do processo de requisitos estabelecendo os recursos e restries sobre os quais o processo opera e que servem para configur-lo. Uma decomposio alternativa poderia ser uma estrutura baseada em produto (requisitos do sistema, requisitos de software, prottipos, casos de uso,..)

31

Figura 7: Tpicos dos Requisitos de software

2.1.3.1.1 Fundamentos de Requisitos de Software a) Definio de Requisito de Software Propriedade que deve ser apresentada pelo software para resolver um problema do mundo real. Requisito de Software porque ele se ocupa com problemas endereados pelo Software: Software desenvolvido ou adaptado para resolver um problema em particular. Problema pode, por exemplo, ser automatizar uma tarefa utilizando o software, para suportar um processo de negcio de uma organizao, controlar um dispositivo qualquer. Requisitos, de software em particular, so tipicamente uma combinao de requisitos de diversas pessoas em diferentes nveis de organizao e de ambientes no qual o software opera. Atributos de requisitos (alm das propriedades comportamentais que expressam). Classificao de prioridade para habilitar trade-offs em face de recursos finitos. Status que permita acompanhar e monitorar o progresso do projeto; Identificao nica para que possa ser controlado pela Gerncia de Configurao e gerenciado durante todo o ciclo de vida.

32

b) Requisitos de Produto e Processo Requisitos de Produto: Requisitos sobre o software a ser desenvolvido. Por exemplo: O software deve verificar se um aluno cumpriu os pr-requisitos antes de aceitar a sua matrcula numa disciplina; Requisitos de Processo: so essencialmente restries impostas ao desenvolvimento do software tais como linguagem de programao, processos e tcnicas de desenvolvimento. Podem ser implcitos ou explcitos. Podem ser impostos pela organizao desenvolvedora, pelo cliente ou por terceiros. c) Requisitos Funcionais e No Funcionais Requisitos Funcionais (capabilities): Descreve funes que o software deve executar como por exemplo controlar fluxo de caixa; Requisitos No Funcionais (restries ou requisitos de qualidade): So aqueles que agem para restringir uma soluo. So conhecidos como restries ou requisitos de qualidade que podem ser classificados em Requisitos de Desempenho, Requisitos de Segurana, Requisitos de Manutenibilidade, Requisitos de Confiabilidade e outros tipos; Exemplos: O custo no pode ultrapassar R$50.000,00 ou Uma funo deve estar disponvel ao usurio 99,99% do tempo. d) Propriedades Emergentes Alguns requisitos representam propriedades emergentes do software, isto , propriedades que no so endereadas por um componente mas cuja satisfao depende da inter operao de diversos componentes do sistema. Por exemplo, a eficincia (throughput) de um call center depende do sistema telefnico, sistema de informao e de todos os operadores interagindo sob condies operacionais. A rapidez de atendimento de um cliente numa loja depende de fatores tais como facilidades de consulta ao cadastro de clientes, facilidades para liberao de mercadoria no estoque, agilidade na liberao pelo caixa, etc. Propriedades emergentes so crucialmente dependentes da arquitetura do sistema. e) Requisitos Quantificveis Requisitos precisam ser definidos com clareza e sem ambiguidade, o quanto

33

for possvel, e, quando for o caso, quantitativamente; Evitar definies vagas ou que no possam ser verificadas tais como O atendimento ao cliente deve ser rpido. Fica melhor O cliente deve ser atendido num intervalo de tempo de 2 minutos. f) Requisitos de Sistema e Requisitos de software Sistema: Uma combinao de elementos interagindo para obter um determinado objetivo. Inclui software, hardware, pessoas, informaes, tcnicas, servios e outros elementos de suporte; Requisitos de Sistema: Requisitos para o sistema como um todo; Requisitos de Software: Num sistema que possui componentes de software, requisitos de software so derivados dos requisitos do sistema e alocados ao software; Requisitos do Usurio: O guia define requisitos do usurio como sendo requisitos dos usurios do sistema ou usurios finais. 2.1.3.1.2 Processo de Requisitos a) Modelos de Processo No uma atividade discreta mas cobre desde o incio at o final do projeto sendo refinado continuamente durante todo o ciclo de vida; Identifica os Requisitos de software como itens de configurao e os gerencia usando as prticas de GC. Customizado de acordo com o contexto da Organizao e do Projeto Relaciona-se com atividades de Elicitao, Anlise, Especificao e Validao. Inclui atividades de Pesquisa de Mercado e Factibilidade b) Atores de Processo Define os papeis dos participantes do processo; Interdisciplinar: Especialistas de requisitos fazem mediao entre os especialistas de domnio e demais interessados (stakeholders); Exemplos tpicos de stakeholders: Usurios: os que iro operar o software;

34

 Clientes: mercado alvo e os que lucram com o produto; Analistas de Mercado: especialistas em necessidades do mercado; Agentes Reguladores: depende do domnio da aplicao (bancos, transporte, comrcio); Engenheiros de software: Interessados em facilitar o desenvolvimento do software. 2.1.3.1.3 Elicitao de Requisitos Preocupa-se com o de onde podem ser obtidos os requisitos de software e como os engenheiros de software podem colet-los; Constitui o primeiro estgio para definir e entender o problema que o software pretende solucionar; uma atividade fundamentalmente humana onde os stakeholders so identificados e so estabelecidas relaes entre equipe de desenvolvimento e o cliente; Pode ser conhecida por outros nomes: captura de requisitos, descoberta de requisitos ou aquisio de requisitos; Um princpio fundamental da boa Engenharia de software: boa comunicao entre usurios do software e os engenheiros de software. Deve-se esforar para isso. Analistas devem mediar entre o domnio do usurio e o domnio tcnico. a) Fontes de Requisitos Principais fontes a serem utilizadas: Metas ou objetivos: Objetivos do Negcio, objetivos de alto nvel do software; Conhecimento do domnio: Conhecimentos sobre o domnio da aplicao; Stakeholders: Pontos de vista dos diferentes tipos de stakeholders; Ambiente operacional: Ambiente onde o software ser executado; Ambiente organizacional: Estrutura, cultura e polticas da organizao. b) Tcnicas de Elicitao Identificadas as fontes de requisitos o engenheiro de software deve elicitar os requisitos.

35

 uma rea difcil, o engenheiro de software poder ter de enfrentar fatos tais como: * usurios podem ter dificuldades em descrever suas tarefas; * informaes importantes podem ser omitidas; * pode haver falta de vontade em cooperar. A elicitao no uma atividade passiva, o engenheiro de software geralmente precisa trabalhar duro para elicitar as informaes corretas Principais tcnicas de elicitao utilizadas: Entrevistas: Forma tradicional de elicitao. Possui vantagens e limitaes; Cenrios: Criao de contextos para a elicitao com usurios. E se. ? Como ficaria ? Prottipos: Para esclarecer dvidas e simular como seria o funcionamento; Reunio com facilitadores: brainstorming consultorias, identificao de conflitos; Observao: Imerso no ambiente alvo para captar os aspectos culturais da organizao e as tarefas nele executadas. 2.1.3.1.4 Anlise de Requisitos Processo de analisar requisitos para: Detectar e resolver conflitos entre requisitos; Descobrir as fronteiras do software e como ele deve interagir com o seu ambiente; Elaborar requisitos do sistema para derivar requisitos do software. A viso tradicional da anlise de requisitos faz com que ela se reduza ao modelamento conceitual usando algum mtodo de anlise tal como o SADT. Deve-se ter o cuidado de descrever os requisitos com preciso suficiente para que possam ser validados, sua implementao verificada e seus custos estimados. a) Classificao de Requisitos Classificao feita segundo diversos critrios: Funcional ou No Funcional (Tpico 1.3); Derivado de requisito de alto nvel, propriedade emergente ou imposta diretamente sobre o software por um stakeholder ou qualquer outra fonte;

36

 Produto ou Processo se o requisito sobre o produto ou sobre o processo. Requisitos sobre o processo podem restringir a escolha de um contratante, um processo a ser adotado, a aderncia a um padro,. Prioridade em geral so de alta prioridade os requisitos considerados essenciais para preencher os objetivos gerais do software. frequentemente so classificados numa escala de pontos fixos como: obrigatrio, muito desejvel, desejvel ou opcional. A prioridade tem que ser balanceada com o custo de desenvolvimento e implementao; Escopo refere-se extenso com que o requisito afeta o software e os componentes de software. Alguns requisitos e particularmente certos requisitos no funcionais possuem um escopo global e no pode ser alocado a nenhum componente em particular. Podem afetar muito na arquitetura. Volatilidade/Estabilidade Alguns requisitos iro mudar durante o ciclo de vida do software e mesmo durante o processo de desenvolvimento. Pode ser til a informao de quanto um requisito muda. Exemplo: Numa aplicao bancria, requisitos para calcular e creditar juros para clientes so provavelmente mais estveis que um requisito para suportar uma espcie particular de conta livre de taxas. O molde reflete uma caracterstica fundamental no domnio bancrio ( essa conta pode ganhar vantagens) enquanto que a anterior pode tornar-se obsoleta por mudana na legislao governamental. Destacando potenciais requisitos volteis pode ajudar o engenheiro de software estabelecer um design que seja mais tolerante mudanas. b) Modelagem Conceitual Desenvolvimento de modelos de um problema no mundo real chave para anlise de requisitos de software. Seu propsito auxiliar no entendimento do problema antes de iniciar o projeto da soluo. Consequentemente, modelos conceituais compreendem modelos de entidades do domnio do problema configurado para refletir relacionamentos e dependncias do mundo real. Diversos tipos de modelo podem ser desenvolvidos. Esses incluem dados e fluxos de controle, modelos de estado, rastreamento de eventos, interao com usurios,modelos de objetos, modelos de dados, e outros. Fatores que influenciam na escolha do modelo:

37

Natureza do problema (software de tempo real => modelo de fluxo de controle e estado); Percia do engenheiro de software ou quem ir utilizar o modelo; Requisitos de Processo do Cliente podem impor sua notao ou mtodo; Disponibilidade de ferramentas e mtodos (SADT, UML). Na maioria dos casos til comear pela construo de um modelo do

contexto do software que fornece uma conexo entre o software pretendido e o ambiente externo. Isso fundamental para entender o contexto do software no seu ambiente operacional e identificar interfaces. Modelamento fortemente acoplado com mtodos. Para propsitos prticos, um mtodo uma notao (ou um conjunto de notaes) suportado por um processo que guia a aplicao das notaes. Geralmente um mtodo no muito superior a outros. A larga aceitao de um mtodo ou notao podem resultar em uma extensa e benfica comunho de habilidades e conhecimentos. Modelos formais usando notaes baseada na matemtica discreta baseados no raciocnio lgico podem ter impacto em alguns domnios especializados. Podem ser impostos por clientes ou padres e oferecer vantagens na anlise de funes ou componentes crticos. Dois padres provm notaes que podem ser teis: IEEE Std 1320.1, IDEFO para modelamento funcional IEEE Std 1320.2 IDEFIX97 (IDEFObject) para modelar informaes. c) Projeto de Arquitetura e Alocao de Requisitos Em algum ponto a arquitetura da soluo precisa ser derivada. Projeto da arquitetura o ponto onde o processo de requisitos sobrepe-se com o projeto do software ou do sistema, e ilustra como impossvel desacoplar com clareza essas duas tarefas. Este tpico fortemente relacionado com a subrea Estrutura do software e Arquitetura da rea de conhecimento Design do Software. Em muitos caos o engenheiro de software age como arquiteto do software pois o processo de analisar e elaborar os requisitos demanda que os componentes que sero responsveis por satisfazer os requisitos sejam identificados. Isso alocao

38

de requisitos a atribuio a componentes, da responsabilidade por satisfazer os requisitos. Alocao importante pois permite a anlise detalhada dos requisitos; Projeto da arquitetura fortemente identificado com modelamento conceitual. O mapeamento de entidades do mundo real para componentes de software nem sempre obvio. Assim, projeto da arquitetura identificado como um tpico separado. Os requisitos de notaes e mtodos so os mesmos no modelamento conceitual e no projeto da arquitetura; IEEE 1471-2000, sugere uma abordagem de mltiplos pontos de vista para descrever a arquitetura do sistema e seus itens de software. d) Negociao de Requisitos

Negociar requisitos X Resoluo de conflitos

Resolver problemas decorrentes de conflitos entre requisitos; Dois stakeholders podem requerer features mutuamente incompatveis; Conduzida por especialistas de requisitos; Evita-se deciso unilateral: stakeholders envolvidos so consultados em busca de consenso; Por razes contratuais, s vezes clientes so envolvidos. Foi classificado como anlise de requisitos de software porque problemas emergem como resultado da anlise. Entretanto um caso grande pode tambm ser considerado como um tpico de validao. 2.1.3.1.5 Especificao de Requisitos Na maioria das engenharias o termo especificao refere-se a atribuio de valores numricos ou limites para o produto de metas do projeto. Sistemas fsicos tpicos possuem um nmero relativamente pequeno desses valores. Software tpico, possui um grande nmero de requisitos e a nfase repartida entre executar a quantificao numrica e gerenciar a complexidade da interao entre um grande nmero de requisitos. Assim, no jargo de engenharia de software, uma Especificao de Requisitos de Software tipicamente refere-se a produo de um

39

documento ou seu equivalente eletrnico, que possa ser sistematicamente revisado, avaliado e aprovado. Para sistemas complexos envolvendo substanciais componentes no-software pelo menos trs documentos so produzidos: Definio do Sistema, Requisitos do Sistema e Requisitos do Software. Nos sistemas simples, apenas o terceiro requerido. a) Documento de Definio do Sistema Tambm denominado Documento de Requisitos do Usurio ou Conceitos de Operaes. Registra, num alto nvel, os requisitos do sistema; Destina-se aos clientes e usurios do sistema (ou seus representantes); Define requisitos funcionais e no funcionais do sistema em alto nvel, seus objetivos gerais, o ambiente alvo, suas restries e pressupostos; Ponto de vista: Domnio da aplicao; Pode conter modelos conceituais para ilustrar o contexto do sistema, cenrios, principais entidades do domnio, dados ou informaes e fluxogramas. IEEE Std 1362, Documento de conceito de operao (modelo). b) Especificao de Requisitos do Sistema Aplica-se a sistemas que possuem nmero considervel de componentes (software e no software); frequentemente separa-se a descrio dos requisitos do sistema da descrio dos requisitos de software. Assim os requisitos de sistema so especificados e os requisitos de software so derivados deles e ento os requisitos de componentes do software so especificados; Especificao de Requisitos do Sistema uma atividade de Engenharia de Sistemas (fora do nosso objetivo); IEEE Std 1233 um guia para desenvolver requisitos de sistema. c) Especificao de Requisitos de Software Estabelece base para acordo entre clientes, contratadores ou fornecedores; Define o que o produto de software deve ser e o que ele no deve ser; Para leitores no tcnicos, o documento de especificao de requisitos de

40

software frequentemente acompanhado por um documento de definio dos requisitos de software; ERS Permite avaliao rigorosa dos requisitos antes do incio do seu projeto e reduz re-projeto; Prov de base realstica para estimar custos, prazos e riscos; Base para confeco de planos de verificao e validao; Normalmente escrito em linguagem natural. Pode conter suplementos em descrio formal ou semi-formal. Normalmente escrito em linguagem natural. Pode conter suplementos em descrio formal ou semi-formal. A regra geral escolher notaes apropriadas que permitam uma descrio mais precisa e concisa; Indicadores de qualidade vem sendo desenvolvidos e podem ser usados para relatar a qualidade da especificao dos requisitos de software para outras variveis de projeto: custo, aceitao, desempenho, cronograma, reprodutibilidade, ; Indicadores de qualidade da especificao de um requisito: imperativos, diretivas, frases fracas, opes, ; Indicadores de qualidade da ERS como um todo: tamanho, legibilidade, estrutura do texto, profundidade, ; IEEE Std 830 padro para ERS . 2.1.3.1.6 Validao de Requisitos Documentos devem ser revisados por stakeholders diferentes, inclusive por representantes do cliente e do desenvolvedor; Documentos de requisitos esto sujeitos mesma Gerncia de Configurao que os demais documentos; normal explicitar um ou mais pontos no processo de requisitos onde a validao realizada. Isso ajuda prevenir alguns problemas antes que recursos sejam alocados; Validao de requisitos diz respeito ao processo de examinar os documentos de requisitos para ter certeza que eles definem o software correto, ou seja, o software que faz o que o usurio espera que ele faa.

41

a) Revises de Requisitos Provavelmente a inspeo e reviso dos documentos de requisitos constitui a maneira mais comum de validao; O grupo de reviso busca por erros, contradies, falta de clareza e desvios de prticas padres; A composio do grupo muito importante e pelo menos um representante do cliente precisa estar includo; Pode ser til o fornecimento de checklists para auxiliar; Revises devem ser constitudas quando for completado o Documento de Definio do Sistema, Documento de Especificao do Sistema e Documento de Especificao de Requisitos de Software, ou em qualquer outro ponto do processo; IEEE Std 1028 fornece guias para reviso. b) Prototipagem Meio de validar a interpretao que o engenheiro de software faz do requisito; Meio para elicitar novos requisitos; * Vantagens: Facilita a interpretao de como o engenheiro v o requisito; Feedback til no caso de interpretaes estarem erradas; Diminui o esforo em desenvolvimento de requisitos errados. * Desvantagem: Desviar a ateno do usurio para a parte cosmtica ao invs de concentrar no que essencial; Custo de desenvolvimento pode ser alto. c) Validao do Modelo necessrio validar a qualidade dos modelos desenvolvidos durante a anlise; Por exemplo: Na modelagem de objetos, til executar uma anlise esttica para verificar os caminhos de comunicao existentes entre objetos que, no domnio dos stakeholders, trocam dados;

42

 Se for utilizada especificao formal, possvel utilizar raciocnio lgico para provar propriedades das especificaes. d) Testes de Aceitao Propriedade importante dos requisitos. O produto deve ser validado nos seus requisitos: Requisitos que no possam ser validados so merosdesejos; preciso planejar como verificar cada requisito (Teste de Aceitao); Para serem validados, eles precisam primeiro ser analisados at o ponto de serem expressos quantitativamente; Pode ser difcil projetar Testes de Aceitao para os Requisitos No Funcionais; Informaes adicionais no tpico 2.2.4 Testes de Conformidade - KA Teste de Software. 2.1.3.1.7 Consideraes Prticas Viso Simplista: A decomposio de subreas apresentada uma simplificao do processo, na verdade ele se expande por todo o ciclo de vida do software.

Vigura 8: Viso simplista

43

Figura 9: Viso realista

a) Natureza Iterativa do Processo de Requisito Mercado atual pressiona indstria para ciclos curtos de desenvolvimento; Alguns projetos so desenvolvidos adaptando projetos anteriores ou aproveitando partes deles; quase sempre impraticvel implementar requisitos como um processo linear e determinstico; um mito pensar que, nos grandes projetos de software, os requisitos so perfeitamente entendidos e especificados. Na maioria das vezes, o requisito sofre aperfeioamento continuado s ficando pronto quando o produto estiver terminado. Requisitos podem ir para uma baseline sem que suas propriedades estejam completamente entendidas. Isso arrisca retrabalho de problemas que podem surgir depois no processo de Engenharia de software; Engenheiros de software, por necessidades decorrentes do gerenciamento do projeto, precisam tomar algumas atitudes que assegurem a qualidade dos requisitos to alta quanto possvel com os recursos disponveis; Devem ser explicitados quaisquer pressupostos, bem como os problemas conhecidos.

44

 Entendimento dos requisitos envolve tanto os procedimentos do projeto como os de desenvolvimento; Ponto crucial no entendimento de requisitos: uma proporo significativa dos requisitos ir mudar devido a erros de anlise, mudanas no ambiente de operao ou de negcio, mudanas no mercado onde ser inserido o produto; Mudanas so inevitveis e medidas devem ser tomadas para mitigar o seu impacto; Mudanas devem ser gerenciadas por um processo definido (rastreamento, anlise de impacto e Gerencia de Configurao); Processo de requisitos no tarefa front-end mas expande-se por todo o ciclo de vida do software. b) Gerncia de Mudanas A gerncia de mudanas central no gerenciamento de requisitos; Gerencia de mudanas descreve o seu papel, os procedimentos que precisam ser efetuados e a anlise que deve ser aplicada s propostas de mudanas; Gerncia de mudanas de requisitos est intimamente ligada Gerncia de Configurao de software. c) Atributos de Requisitos Requisitos no so constitudos apenas pela especificao do que requerido, mas tambm por um conjunto de informaes adicionais que auxiliam a interpretar e gerenciar os requisitos. Isso pode incluir vrias classificaes, mtodos de verificao e aceitao e planos de teste. Pode incluir: Resumo do requisito; Fonte do requisito; Histrico das mudanas;

Identificador: a mais importante pois permite que requisitos tenham identificao nica e no ambgua.

d) Rastreamento de Requisitos Rastreamento tem a ver com as fontes dos requisitos e com os efeitos sobre

45

os seus descendentes; Fundamental para fazer anlise de impacto quando o requisito modificado; Requisitos precisam ser rastreados: Backward: Nas suas origens (requisito e stakeholders que o motivaram); Forward: Nas entidades de projeto geradas a a partir deles (requisitos, mdulos de cdigo, testes,). Rastreamento de requisitos num projeto tpico ir formar um grafo acclico dirigido (DAG). e) Medio de Requisitos Por questes prticas, til possuir algum conceito de volume dos requisitos para um particular produto de software. til para avaliar o tamanho de uma mudana de requisitos, na estimativa de custo de desenvolvimento, tarefa de manuteno ou simplesmente para ter um denominador comum de comparao com outras medies. FSM (Medida de Tamanho Funcional): tcnica para avaliar o tamanho do corpo de requisitos funcionais (IEEE Std 14143.1 define o conceito de FSM). Informaes adicionais sobre medies de tamanho e padres so encontradas na KA Processo de Engenharia de Software. **Matriz de Tpicos x Material de Referncia ** 2.1.3.2 Design de Software Design definido no [IEEE610.12-90] de duas formas o processo de definio da arquitetura, componentes, interfaces, e outras caractersticas de um sistema ou componente e o resultado do processo. Visto como um processo, o design de software o ciclo de vida da engenharia de software no qual os requisitos de software so analisados para produzir uma descrio da estrutura interna dos softwares que serviro como base de sua construo. Mais precisamente, o design de software (resultante) pode descrever a arquitetura de software isto, como o software decomposto e organizado dentro dos componentes e a interface entre estes componentes. Isso tambm descreve os componentes no nvel de detalhe que permitem sua construo.

46

O Design de Software emprega uma importante regra no desenvolvimento de software: isso permite engenheiros de software produzirem vrios de modelos que formam um tipo de plano de soluo para ser implementado. Ns podemos analisar e avaliar estes modelos para determinar se eles nos permitiro atender as diversas necessidades. Ns podemos tambm examinar e avaliar vrias solues alternativas e confront-las. Finalmente ns podemos usar os modelos resultantes para planejar as atividades do desenvolvimento subsequente, em adio ao uso deles como entrada e ponto de comeo da construo e teste. Em uma listagem padro do processo de ciclo de vida de software tal como IEEE/EIA 12207, Processos de Ciclo de Vida do Software [IEEE12207.0-96], design de software consiste em duas atividades que situa-se entre anlises e requerimentos de software e construo de software: Design de arquitetura de software (algumas vezes chamada design de alto nvel - Top-Level design): Descreve altos nveis de estrutura e organizao de softwares e identificao de componentes. Design de software detalhado: Descreve cada componente suficientemente para permitir esta construo A respeito do escopo da rea de Conhecimento do Design de Software (KA), a atual descrio KA no discute cada tpico do nome que contm a palavra design. Na terminologia de Tom DeMarcos (DeM99), a KA discutida neste captulo trata principalmente do D-Design (decomposio do design, mapeando o software dentro dos pedaos de componente). Entretanto, por conta dessa importncia no campo de crescimento da arquitetura de software ns abordaremos o PF-Design (famlia de padro de projeto, cujo o objetivo estabelecer exploraes comuns na famlia de software). Em contraste , a KA Design de Software no aborda I-Design (design da inveno, usualmente executada durante o processo de requisitos de software como o objetivo de conceitualizar e especificar o software para satisfazer descobertas necessrias e requisitos), desde este tpico deve ser considerado parte da especificao e anlise de requisitos. A descrio do Design de Software KA relatada especificamente para os Requisitos do software, Construo do Software, Gerenciamento e Engenharia de Software, Qualidade do Software, e Disciplinas Relatadas com a Engenharia de Software.

47

2.1.3.2.1 Fundamentos do Design de Software Os conceitos, noes e terminologia introduzidas aqui formam uma linha base para entender o papel e o escopo do design de software. a) Conceitos Gerais de Design O Software no o nico campo onde o design est envolvido. No senso geral, ns podemos ver design como uma forma de resolver problemas. Por exemplo, o conceito de um mau problema - um problema sem soluo definitiva - interessante em termos de entendimento dos limites do design. Uma srie de outras noes e conceitos so tambm de interesse para a compreenso de design no seu sentido geral: objetivos, restries, alternativas, representaes e solues. b) Contexto do Design de Software O Para entender o papel do design de software, importante entender o contexto em que se enquadra o ciclo de vida da engenharia de software. Assim, importante entender as maiores caractersticas das anlises de requerimento de software vs. Design de software vs. Construo de software vs. Teste de software. [IEEE12207.0-96]; Lis01:c11; Mar02; Pfl01:c2; Pre04:c2] c) Processo de Design de Software O Design de software geralmente considerado em dois passos: Design Arquitetural: descreve como o software decomposto e organizado dentro de componentes (a arquitetura de software) [IEEEP1471-00] Design Detalhado: descreve o comportamento especfico desses componentes. A sada desse processo um conjunto de modelos e artefatos que guardam as maiores decises que tenham sido tomadas. IEE1016-98; Lis01:c13; Pre04:c9 d) Tcnicas Ativas De acordo com o Dicionrio Ingls Oxford, um princpio uma verdade bsica ou lei geral que usada como a base racional ou guia de ao. Os princpios do design de software, tambm so chamados de Tcnicas Ativas ]Bus96], so noes chave consideradas fundamentais para muitas diferentes abordagens e

48

conceitos de design de software. As tcnicas ativas so as seguintes: Bus96:c6; IEEE1016-98; Jal97:c5,c6; Lis01:c1,c3; Pfl01:c5; Pre04:c9. Abstrao: o processo de esquecer informaes tais como coisas diferentes que podem ser tratadas como se elas fossem a mesma. [Lis01] No contesto de design de software, dois mecanismos chave de abstrao so a parametrizao e a especificao. Abstrao por especificao guia-nos aos trs maiores tipos de abstrao: abstrao procedural, abstrao de dados, e controle (iterao) de abstrao. Jal97:c5,c6; Lis01:c1,c2,c5,c6; Pre04:c1 Acoplamento e Coeso: Acoplamento definido como uma fora de relacionamento entre mdulos, enquanto coeso definido por como os elementos que formam um mdulo so relacionados. Jal97:c5; Pfl01:c5; Pre04:c9 Decomposio e modularizao. Decompor e Modularizar um grande software dentro de um pequeno nmero de partes nicas e independentes, usualmente com o objetivo de colocar diferentes funcionalidades ou responsabilidades em diferentes componentes. [Bas98:c6, Bus96:c6; Jal97 :c5; Pfl01:c5; Pre04:c9] Encapsulamento / Ocultamento de Informao: significa agrupar e separar em pacotes, elementos e detalhes internos de uma abstrao e fazendo esses detalhes inacessveis. Bus96:c6; Jal97:c5; Pfl01:c5; Pre04:c9 Separao da interface e implementao: envolve definir um componente para especificar uma interface, conhecer clientes, separando os detalhes de como os componente ralizado.Bos00:c10; Lis01:c1,c9 Suficincia, completude e simplicidade. Alcanar suficincia, completude e simplicidade significa garantir que um componente de software capturar todas as caractersticas importantes de uma abstrao, e nada mais. Lis01:c5

49

Figura 10: Tpicos para Design de Software

2.1.3.2.2 Os Pontos Chave no Design de Software Um certo nmero de pontos chave devem ser tratados na concepo de software. Alguns so preocupaes de qualidade. Algumas preocupaes so a qualidade que todos os softwares devem ter, por exemplo, performance. Outra questo importante a forma de decompor, organizar e empacotar componentes de software. Isso to fundamental que todas as abordagens endeream isto em um caminho ou outro. Em contraste a isto, outros pontos entregam alguns aspectos do comportamento de software que no esto no domnio da aplicao, mas desejam enderear algo no domnio do suporte. [Bos00] Tais pontos, desejam frequentemente cortar funcionalidades do sistema, referindo-se a aspectos: aspectos no tendem a ser unidades de software funcionais decompostos, mas antes propriedades que afetam a performance ou semntica dos componentes em caminhos sistmicos. a) Concorrncia Como decompor o software em processos, tarefas e servio e desejar eficincia, atomicidade, sincronizao, e verses agendadas. Mesy97:c30; Pre04:c9

50

b) Controle e transporte dos Eventos Como organizar dados e controlar fluxos, como trasportar eventos reativos e temporais atravs de vrios mecanismos tais como invocao implcita e call-back. [Pfl01:c5 ] c) Distribuio de Componentes Como distribuir o software baseado no hardware, como os componentes se comunicam, como um middleware pode ser usado para entregar software heterogneo. Bos00:c5; Bus96:c2 Mar94:DD; Pre04:c30 d) Transporte de Exceo, Erro e Tolerncia a falha Como prevenir e tolerar falhas e entregar condies excepcionais. [Pfl01:c5 ] e) Interao e Apresentao Como estruturar e organizar interaes com usurios e a apresentao da informao (por exemplo, separao da apresentao e lgica de negcios usando a abordagem Model-View-Controller).Bos00:c5;Bus96:c2; Lis01:c13; Mey97:c32. Isto pode ser notado que este tpico no sobre detalhes de especificao da interface de usurios, deseja-se que a tarefa do design de interface de usurio (uma parte do Software Ergonmico); veja as Disciplinas Relatadas da Engenharia de Software. f) Persistncia dos dados Como dados de longa vida podem ser transportados. 2.1.3.2.3 Estrutura e Arquitetura de Software No seu sentido estrito, uma arquitetura de software "uma descrio dos subsistemas e de componentes de um sistema de software e as relaes entre eles." (Bus96:c6) Arquitetura, assim, as tentativas de definir a estrutura interna. Segundo o Dicionrio Ingls Oxford, "a forma como algo construdo ou organizado"- do resultando software. Durante meados da dcada de 1990, no entanto, arquitetura de software comeou a emergi como uma mais ampla disciplina que envolve o estudo de estruturas e de arquiteturas de software de uma forma mais genrica [Sha96].

51

Isso deu origem a uma srie de ideias interessantes sobre a concepo do software em diferentes nveis de abstrao. Alguns desses conceitos podem ser teis durante a concepo arquitetnica (por exemplo, estilo arquitetnico) de um software especfico, bem como durante a sua concepo pormenorizada (por exemplo, a concepo de nvel mais baixo padres). Mas eles tambm podem ser teis para a concepo de sistemas genricos, levando concepo de famlias de programas (tambm conhecidas como linhas de produtos). Curiosamente, a maior parte destes conceitos pode ser visto como tentativas de descrever, e deste modo o reuso, conhecimentos design genricos. a) Estruturas arquitetnicas e Viewpoints Diferentes facetas de high-level de design de software podem e devem ser descritos e documentados. Estes aspectos so muitas vezes chamados views: "Uma view representa um parcial aspecto de uma arquitetura de software que mostra propriedades especficas de um sistema de software" [Bus96: c6]. Estas distintas views pertencem a distintas questes relacionadas com a design de software por exemplo, a lgica view (que satisfaa as exigncias funcionais) vs os processos view (questes de concurrency) vs fsico views (questes de distribuio) vs o desenvolvimento view (o modo como o projeto dividido em unidades de implementao). Outros autores usam diferentes terminologias, como comportamental vs funcional vs estruturais vs modelagem de dados view. Em resumo, um projeto de software um multifacetada artefato produzido pelo processo de design e geralmente composto de relativa independncia e ortogonais vista. [Bas03: c2; Boo99: c31; Bus96: c6; IEEE1016-98; IEEE1471-00] estilos arquitetnicos (padres de macroestruturas). Um estilo arquitetnico "um conjunto de restries sobre um arquitetura que define um conjunto ou famlia de arquiteturas que os satisfazem" [Bas03: c2]. Um estilo arquitetnico pode ser visto como uma metamodelo que possa fornecer software de alto nvel (high-level) para as organizaes (a macro arquitetura). Diversos autores identificaram uma srie de grandes estilos arquitetnicos. Boo99:c28; Bos00:c6; Bus96:c1,c6;Pfl01:c5 Estrutura geral (por exemplo, camadas, tubos, e filtros, Blackboard); Sistemas Distribudos (por exemplo, cliente-servidor, threetiers, broker);

52

Sistemas Interativos (por exemplo, Model-View-Controller, ApresentaoAbstrao-Controle); Adaptao de sistemas (por exemplo, micro-kernel, reflexo); Outros (por exemplo, lote, intrpretes, controle de processos, regras base).

b) Padres de Design (padres de micro arquitetura) Sucintamente descritos, um padro "uma soluo comum para um problema comum em um determinado contexto." (Jac99) Embora estilos arquitetnicos possam ser vistos como padres que descrevem o high-level de software das organizaes (as suas macro arquiteturas), outros padres de projeto pode ser usado para descrever em detalhes uma menor, mais nvel local (a sua micro arquitetura). Boo99:c28; Bus96:c1;Mar02:DP Padres Creational (por exemplo, construtor, fbrica, prottipo, e Singleton) Padres estruturais (por exemplo, adaptador, ponte, compsito, decorador, fachada, flyweight, e proxy) Padres comportamentais (por exemplo, comando, o intrprete, interao, mediador, memento, observador, estatal, estratgia, modelo, visitante). c) Famlias de programas e frameworks Uma possvel abordagem para permitir a reutilizao de design de softwares e de componentes a concepo das famlias de software, tambm conhecidos como linhas de produtos de software. Isto pode ser feito atravs da identificao dos membros comuns dessas famlias, e usando componentes reutilizveis e personalizveis para levar em conta a variabilidade entre os membros da famlia. [Bos00:c7,c10; Bas98:c15; Pre04:c30] . Na programao OO, uma chave relaciona noes do que um framework: um subsistema parcialmente completo de software que pode ser estendido pelas instalaes de plug-ins mais especficos (tambm conhecidos como hot spots). 2.1.3.2.4 Anlise e Evoluo da Qualidade de Design de Software Esta seco inclui uma srie de tpicos de qualidade e avaliao que esto especificamente relacionadas com a concepo do software. A maior parte abrangida de uma forma geral, no Quality Software KA.

53

a) Atributos de Qualidade Diversos atributos so geralmente considerados importantes para a obteno de um design de software de boa qualidade e diversas "ilities" (manutenibilidade, portabilidade, testabilidade, rastreabilidade), vrias "des" (correo, robustez), incluindo "fitness de propsito." [Bos00: c5; Bus96: c6; ISO9126.1-01; ISO15026-98; Mar94: D; Mey97: c3; Pfl01: c5] Um dado interessante a distino entre atributos de qualidade discernvel em tempo de execuo (desempenho, segurana, disponibilidade, funcionalidade, usabilidade), para aqueles que no so discernveis em tempo de execuo (modificabilidade, portabilidade, reusabilidade, integrabilidade, e testabilidade), e os relacionados com as qualidades intrnsecas da arquitetura (conceitual integridade, a exatido e a exaustividade, buildability). b) Anlise de qualidade e Tcnicas de Avaliao. Vrias ferramentas e tcnicas podem ajudar a garantir uma concepo da qualidade de software. Reviso do design de Software: semi formal ou informal, muitas vezes baseadas em grupo, tcnicas para verificar e assegurar a qualidade da concepo de componente (por exemplo, a reviso da arquitetura [Bas03: C11], opinies de design, e inspees [Fre83: VIII; IEEE1028-97; Jal97: C5, C7; Lis01: C14; Pfl01: c5], tcnicas de cenrio de base [Bas98: c9; Bos00: c5], rastreio de requisitos [Dor02: v1c4s2; Pfl01: C11]); Anlise esttica: formal ou semi formal esttico (no executvel) anlises que possam ser utilizadas para avaliar um projeto (por exemplo, anlise fault-tree ou verificao cruzada automatizada) [Jal97: c5; Pfl01: c5] Simulao e prototipagem: tcnicas dinmicas para avaliar um projeto (por exemplo, desempenho ou simulao viabilidade de prottipo [Bas98: c10; Bos00: c5; Pfl01: c5]) c) Medidas As medidas podem ser utilizadas para avaliar quantitativamente estimativos ou vrios aspectos do tamanho do design de software, estrutura, ou qualidade. A maior parte das medidas que foram propostas dependem geralmente da abordagem

54

utilizada para produzir o design. Estas medidas so classificadas em duas grandes categorias: Medidas de Design Orientados a Funo (estruturados): a concepo da estrutura, obtido principalmente atravs da decomposio funcional; geralmente representada como uma estrutura grfica (s vezes chamado de diagrama hierrquico), em que vrias medidas podem ser computadas [Jal97: C5, C7, Pre04 : c15] Medidas de Design Orientados a Objeto: a concepo global da estrutura muitas vezes representada como um diagrama de classes, em que vrias medidas podem ser computadas. Medidas sobre as propriedades de cada classe interna do contedo tambm podem ser computadas [Jal97: C6, C7; Pre04: c15] 2.1.3.2.5 Notaes de Design de software Muitas notaes e linguagens existem para representar o design de software e artefatos. Algumas so usadas principalmente para descrever a organizao estrutural de desenho, outras para representar o comportamento de software. Certas notaes so usadas pela maior parte durante o desenho arquitetnico e outros principalmente durante detalhamento do desenho, embora algumas notaes possam ser usadas em ambos os passos. Alm do mais, algumas notaes so usadas pela maior parte no contexto de mtodos especficos (ver as Estratgias de Desenho de Software e subrea de Mtodos). Aqui, eles so categorizados em notaes para descrever a viso estrutural (esttica) contra a viso comportamental (dinmica). a) Descries Estruturais (viso esttica) As seguintes notaes, pela maior parte do grfico (mas no sempre), descrevem e representam os aspectos estruturais de um design de software isto , eles descrevem os componentes principais e como eles so interligados (viso esttica): Linguagens de descrio de arquitetura (ADLs): textual, muitas vezes formal, linguagens usadas para descrever uma arquitetura de software quanto aos componentes e conectores. [Bas03:c12]

55

Diagramas de classe e objeto: usado para representar um jogo de classes (e objetos) e as suas relaes mtuas. [Boo99:c8, c14; Jal97:c5, c6] Diagramas de componentes: usado para representar um jogo de

componentes (parte fsica e substituvel [s] do sistema que [se conformam] com e [fornecem] a realizao de um jogo de interfaces [Boo99]) e suas relaes mtuas [Boo99:c12, c31] Cartes de colaborao de classes responsveis (CRCs): usado para denotar os nomes de componentes (classe), suas responsabilidades, e os nomes de seus componentes de colaborao Bus96 Diagramas de desenvolvimento: usado para representar um jogo de ns (fsicos) e as suas relaes mtuas, e, assim, modelar os aspectos fsicos de um sistema [Boo99:c30] Diagramas de entidades e relacionamento (ERDs): usado para representar modelos conceituais de dados fornecidos em sistemas de informao Dor02:v1c5; Mar02:DR Linguagens de descrio de interface (IDLs): parecido a com uma linguagem de programao usada para definir as interfaces (nomes e tipos de operaes exportadas) de componentes de softwareBoo99:c11 Estrutura de diagrama Jackson: usado para descrever os dados das estruturas quanto a sequncia, seleo, e iterao Mar02:DR Diagramas de estrutura: usado para descrever a estrutura que chama programas (que o mdulo chama, e chamado por outro mdulo) Jal97:c5; Mar02:DR;Pre04:c10 b) Descries Comportamentais (viso dinmica) As seguintes notaes e linguagens, alguns grficos e alguns textuais, so usados para descrever o comportamento dinmico de componentes de software. Muitas dessas notaes so til pela maior parte, mas no exclusivamente, durante o detalhamento do design. Diagramas de atividade: usado para mostrar o controle de fluxo de atividade (execuo no atmica contnua dentro de uma mquina de estado) atividade [Boo99:c19] Diagramas de colaborao: usado para mostrar as interaes, isto ocorre

56

entre um grupo de objetos, onde a nfase est nos objetos, as seus links, e as mensagens trocadas entre eles por esses links[Boo99:c18] Diagramas de fluxo de dados (DFDs): usado para mostrar fluxo de dados entre um jogo de processos Mar02:DR; Pre04:c8 Diagramas e tabelas de deciso: usado para representar combinaes complexas de condies e aes [Pre04:c11] Fluxogramas e fluxogramas estruturados: usado para representar o controle de fluxo e as aes associadas a ser executadas Mar02:DR; Pre04:c11 Diagramas de sequncia: usado para mostrar as interaes entre um grupo de objetos, com nfase no timeordering de mensagens [Boo99:c18] Transio de estado e diagramas de statechart: usado para mostrar o fluxo de controle de estado para estado em uma mquina de estado ar02:DR; Jal97:c7 Linguagens formais de especificao: linguagens textuais utiliza noes bsicas da matemtica (por exemplo, a lgica, o jogo, sequncia) para definir com rigor e de maneira abstrata as interfaces de componente de software e comportamento, muitas Dor02:v1c6s5; Mey97:c11 Pseudocdigo e as linguagens de design de programao(PDLs): as linguagens estruturadas-como-linguagens de programao para descrever, geralmente na etapa de detalhamento de design, o comportamento de um procedimento ou mtodo Fre83:VII; Jal97:c7; Pre04:c8, c11 2.1.3.2.6 Estratgias e Mtodos de Design de Software Existem vrias estratgias gerais para ajudar a orientar o processo de planejamento. [Mar02:D] Em contraste com as estratgias gerais, os mtodos so mais especficos nisto, eles geralmente sugerem e fornecem um conjunto de notaes a ser utilizadas com o mtodo, uma descrio do processo a ser utilizado quando o seguinte mtodo e um conjunto de orientaes na utilizao do mtodo. Tais mtodos so teis como um meio de transferir conhecimento e como um framework comum de equipes de engenheiros de software.Veja tambm os Instrumentos de Engenharia de Software e Mtodos KA. a) Estratgias Gerais vezes em termos de pr e ps-condies

57

Algumas vezes, exemplos de estratgias gerais so citados como teis em design de processo dividir e conquistar em um refinamento gradual Fre83:V, topdown vs. estratgias bottom-up, abstrao de dados e informaes ocultas[de Fre83:V], o uso da heurstica, uso de modelos e linguagens de modelo Bus96:c5, uso de uma aproximao iterativa e incremental. [Pfl01:c2]. b) Design orientado por funo (Estruturado) Este um dos mtodos clssicos do design de software, onde a decomposio centra na identificao das principais funes de software e refinao elaborando-as de cima para baixo. O design estruturado geralmente usado depois da anlise estruturada, assim produo, entre outras coisas, diagrama de fluxos de dados e descries de processo associadas. Os pesquisadores propuseram vrias estratgias (por exemplo, a anlise de transformao, anlise de transao) e heurstica (por exemplo, fan-in/fan-out, o alcance do efeito contra o alcance do controle) para transformar um DFD em uma arquitetura de software geralmente representada como um diagrama de estrutura. [Dor02:v1c6s4; Fre83:V; Jal97:c5; Pre04:c9, c10] c) Design orientado a objeto Numerosos mtodos de design de software baseados em objetos foram propostos. O campo evoluiu com o primeiro design baseado em objeto em meados dos anos 80 (substantivo = objeto; verbo = mtodo; o adjetivo = atributo) pelo design de OO, onde a herana e o polimorfismo desempenham um papel-chave, ao campo do design base de componente, onde a informao de Meta pode ser definida e acessada (pela reflexo, por exemplo). Embora as razes de design OO venham do conceito de abstrao de dados, o design levado por responsabilidade tambm tenha sido proposto como uma aproximao alternativa ao design de OO. [Dor02:v1:c6s2,s3; Fre83:VI; Jal97:c6; Mar02:D; Pre04:c9 ] d) Design centrado por estruturas de dados O desenho centrado por estruturas de dados (por exemplo, Jackson, WarnierOrr) partidas das estruturas de dados que um programa manipula e no da funo que ele executa. O engenheiro de software primeiro descreve os dados de produo

58

e a entrada das estruturas (usando os diagramas de estrutura de Jackson, por exemplo) e logo desenvolvem a estrutura de controle do programa baseada nesses diagramas de estrutura de dados. Vrias heursticas foram propostas para tratar com casos, por exemplo, especiais, quando h uma m combinao entre as estruturas de produo e entrada. [ Fre83:III,VII; Mar02:D ] e) Design baseado em componente Um componente de software uma unidade independente, tendo interfaces bem definidas e dependncias que podem ser compostas e desdobradas independentemente. O design baseado em componente dirige questes relacionadas a fornecimento, desenvolvimento, e integrao de tais componentes ara melhorar reutilizao. f) Outros mtodos Outros interessantes mas com enfoque menor tambm existem: mtodos formais e rigorosos Dor02:c5; Fre83; Mey97:c11; Pre04:c29 e mtodos transformacionais. [Pfl98:c2]

Figura 11: Tpicos x referncias (1)

59

Figura 12: Tpicos x referncias (2)

Figura 13: Tpicos x referncias (3)

2.1.3.3 Construo de Software O termo construo de software refere-se a criao trabalho detalhado, significativo de software atravs de combinao de cdigos, verificao, testes unitrios, integrao de teste e depurao. A rea de conhecimento construo de

60

software tem conexo com outra KAs (reas de conhecimentos), mais firmemente o design de software e testes de software. Isto porque processo construo de software se aplica significativo design de software e atividade de teste. Ele utiliza tambm a produo de design e fornece uma contribuio de teste, ambos design e teste pode ser atividades, no KAs neste caso. Detalhado limite entre design, construo, e testes ir variar dependendo do ciclo de vida do processo de software que usado no projeto. Embora alguns detalhes de design podem ser realizados anteriores a construo, muito trabalho de design realizado na atividade construo. Portanto, KA (rea de conhecimento) construo de software est intimamente ligado KA design de software. Durante toda construo, engenheiros de software trabalham os dois testes, de unidade e de integrao. Assim, a KA construo de software est intimamente ligada a teste de software como KA. A construo de software tipicamente produz alto volume de itens de configurao, esses necessitam de gerenciamento de projeto de software. (fonte, arquivo, contedo, caso de teste e etc.). Portanto, a KA construo de software tambm intimamente ligada a KA gerncia de configurao de software. A construo de software invoca desde ferramentas e mtodos e so provavelmente ferramentas intensivas das KAs. Elas so ligadas a KA engenharia de software ferramentas e mtodos. Enquanto qualidade de software importante em todas as KAs, o cdigo a ultima realizao do projeto de software, e, portanto qualidade de software tambm intimamente ligada a construo de software. A relao entre disciplina de engenharia de software, a KA construo de software semelhante a cincia da computao no uso de seu conhecimento de algoritmo e de detalhamento de prticas de codificao, ambos geralmente so considerados pertencentes ao domnio da cincia da computao. Ela tambm est relacionada a gerencia de projeto, na medida em que a gerencia da construo pode apresentar desafios considerveis. A repartio da KA construo de software apresenta abaixo, junto com breve descrio dos principais tpicos associados com ela. Referncias adequadas tambm so fornecidas para cada um dos tpicos. A figura 14 apresenta um grfico da decomposio de nvel superior da repartio para est KA.

61

2.1.3.3.1 Fundamentos da construo de software Os fundamentos da construo de software inclui: minimizar complexidade antecipao da mudana construo para verificao normas de construo

Figura 14: Repartio dos tpicos para o rea de conhecimento de construo de software

Os trs primeiros conceitos se aplicam ao design, bem como a construo. As seguintes sees definem estes conceitos e descreve como eles se aplicam na construo. a) Minimizar complexidade Um fator principal em como as pessoas transmitirem as intenes dos computadores limitaes serias das capacidades das pessoas em realizar complexas estruturas e informaes em suas memrias de trabalho, especialmente durante longos perodos de tempo. Isto conduz a um forte controle em construo de software. Minimizar complexidade. O necessrio de reduzir aplicaes complexas basicamente de todos os aspectos da construo de software, e particularmente critico dos processos de verificao e testes de construo de software. Em construo de software, reduzir complexidade obter por enfatiza a criao de cdigo que simples e legvel e bastante engenhoso. Minimizar complexidade realizada por meio da utilizao de padres, que discutido no tpico 1.4 Padro em

62

construo, e por numerosas tcnicas especificas resumidas no tpico 3.3 codificao. Ele tambm apoiado pela construo com foco na tcnica de qualidade resumida no tpico 3.5 qualidade de construo. b) Antecipao de mudana A maior parte dos software ir mudar com o tempo, e a antecipao das mudanas controla muitos aspectos da construo de software. A mutao de ambientes externos de software parte inevitvel, e as mudanas nesses ambientes externos afetam o software em diversas maneiras. As antecipao da mudana apoiada por muitas tcnicas especficas resumidas no tpico 3.3 codificao. c) Construo para verificao Construo para verificao meio de construir software de forma que as falhas podem ser prontamente encontradas pelo engenheiro de software que escreveu o software, bem como durante os testes independentes e atividades operacionais. Tcnicas especificas de suporte a construo para verificao inclui seguinte normas de codificao de suporte a reviso de cdigo, teste de unidades, organizao de cdigo de suporte automao de testes, e restrio de uso complexo ou linguagem de difcil compreenso das estruturas, entre outras. d) Normas de construo Normas que afetam diretamente questes de construo incluem: Mtodos de comunicao (por exemplo, padro de formatos de documentao e contexto); Linguagem de programao ( por exemplo, padres de linguagem com linguagens Java e C++); Plataforma (por exemplo, programador padro para a interface do sistema operacional chamado); Ferramenta (por exemplo, diagramas padro para notaes ligadas a UML (Linguagem de Modelagem Unificada)); Uso de normas externas. Construo depende do uso de normas externas para construo de linguagens, construo de ferramentas, tcnicas de interfaces, e interaes entre construo de software e outras KAs. Normas vm de numerosas

63

fontes, incluindo hardware e interface de especificao de software tais como o Grupo Gesto Objeto (OMG) e organizaes internacionais tais como a IEEE ou ISO. Uso de normas interna. Normas tambm podem ser criadas sobre uma base organizacional no nvel corporativo ou para utilizao em projetos especficos. Estas normas apoiam a coordenao de grupos atividades, minimizar complexidade, antecipao de mudana, e construo para verificao. 2.1.3.3.2 Gesto de Construo a) Modelos de construo Inmeros modelos tm sido criados para desenvolver software, algumas dos quais enfatizam construo mais do que outros. Alguns modelos so mais lineares e parti do ponto de construo e visualizao, tal como o modelo de ciclo de vida cascata. Estes modelos trata construo como uma atividade na qual ocorre apenas depois de significativo trabalho de detalhamento de requisitos foi concludo, extenso trabalho de design, e detalhe de planejamento. O mais linear tende abordar para enfatizar a atividade esse precede construo (requisitos e design), e tende para criar mais clara separao entre as atividades. Nestes modelos, a nfase principal pode ser a codificao. Outros modelos so mais interativos, tal como prototipagem evolutiva, Extreme Programming (XP) e Scrum. Estes tende a abortar e tratar construo como uma atividade que ocorre concomitantemente com outras atividades de desenvolvimento de software, incluindo requisitos, design, e planejamento, ou sobrepor-lhes. Estes tende abordar para misturar design, codificao, e atividades de testes, e eles muitas vezes tratam a combinao de atividades como construo. Consequentemente, o que considerado construo depende em certa medida do ciclo de vida utilizado. b) Planejamento de construo A escolha de mtodos de construo so aspectos chaves da atividade planejamento de construo. A escolha de mtodos de construo afeta o grau a qual pr-requisitos de construo so realizados, a ordem em qual eles so realizados, e o grau para qual eles so esperados para ser concludos antes de

64

comear os trabalhos de construo. A abordagem de construo do projeto afeta capacidade para reduzir complexidades, antecipar mudanas, e verificao para construo. Cada um desses objetivos pode tambm ser abordado no processo, requisitos, e nveis de design mas eles tambm sero influenciados pela escolha dos mtodos de construo. Planejamento da construo tambm define a ordem em qual os componentes so criados e entregados, a gerencia de processo de qualidade de software, a distribuio de tarefas especficas atribudas aos engenheiros de software, e a outras tarefas, segundo o mtodo escolhido. c) Medio de construo Inmeras atividades de construo e artefatos podem ser medidas, incluindo desenvolvimento de cdigo, modificao de cdigo, reutilizao de cdigo, destruio de cdigo, complexidade de cdigo, inspeo estatsticas de cdigo, a falhas e corrigir falhas, esforo, e agendamento. Estas medies podem ser teis para propsito de gerencia da construo, assegurar qualidade durante a construo, melhorar o processo de construo, bem como por outros motivos. Ver a KA processo de engenharia de software para mais sobre medies. 2.1.3.3.3 Consideraes prticas Construo uma atividade na qual o software tem que se condicionar as restries arbitrarias e caticas do mundo real e, faz-la precisamente. Devido sua proximidade a restries do mundo real, construo est mais orientada por consideraes prticas do que algumas reas de conhecimento, e a engenharia de software assemelhasse a esta rea de construo a) Design de Construo Alguns projetos reservam mais ateno para o design de construo; outros em uma fase explcita focam o plano. Independente do momento, alguns detalhes do design ocorrero em nvel de construo, e este design de trabalho ser ditado pelas restries imveis impostas pelo mundo real, problemas que so abordados pelo software. Tal como trabalhadores da construo que constroem uma estrutura fsica

65

devem fazer modificaes, contabilizar pequenas falhas no plano do construtor, construtores de software devem fazer modificaes em escala menor ou maior para enriquecer detalhes do design de software durante sua construo Os detalhes da atividade de design a nvel de construo so, essencialmente, os mesmos como descrito na rea de conhecimento de design de software, mas foram aplicadas numa escala menor. b) Linguagem de Construo Linguagens de construo incluem todas as formas de comunicao em que um homem pode especificar um soluo de um problema executvel para o computador. O tipo mais simples de linguagem de construo uma linguagem de configurao, na qual engenheiros de software escolhem um conjunto limitado de opes predefinidas para criar instalaes de software novas ou personalizadas. Os arquivos de configurao baseado em texto usados nos sistemas operacionais Windows e UNIX so exemplos, e as listas de seleo de estilo de menu de alguns geradores de programa constituem outro. Kit de ferramentas de linguagem so usadas para criar aplicativos em kits (conjuntos integrados de partes reutilizveis especficas do aplicativo) e so linguagens de configurao mais complexas. Kit de ferramentas de linguagem, podem ser explicitamente definidas como linguagens de programao de aplicativo (por exemplo, scripts) ou podem simplesmente ser implcito no conjunto de interfaces de um kit de ferramentas. Linguagens de programao so o tipo mais flexvel das linguagem de construo. Elas tambm contm o mnimo de informaes sobre reas de aplicao especficas e processos de desenvolvimento e assim o exigem mais formao e habilidade para utiliz-las de forma eficaz. Existem trs tipos gerais de notao usada para linguagens de programao, que so: Lingustica Formal Visual Notaes lingusticas distinguem-se em especial atravs da utilizao de cadeias de palavras chave de texto para representar construes de software complexo e a combinao de tais strings de palavra chave em padres que possuem

66

uma sintaxe de frase semelhante. Corretamente utilizados, cada cadeia de caracteres deve ter uma forte conotao semntica fornecendo uma compreenso intuitiva imediata do que acontecer quando a construo de software subjacente executada. Notaes formais contam com menos significados intuitivos, palavras comuns e cadeias de texto, e, mais em definies de suporte preciso, sem ambiguidades e definies formais (ou matemtica). Notaes de construo formal e os mtodos formais, so o centro da maioria das formas de sistema de programao, onde a preciso, comportamento de tempo e testabilidade so mais importantes, do que a facilidade de mapear para linguagem natural. Construes formais tambm usam precisamente formas definidas de combinar os smbolos, que evitam a ambiguidade de muitas linguagens natural de construo. Notaes Visual baseiam-se muito menos sobre as notaes de palavras chaves da construo lingustica e formal e em vez disso dependem a interpretao visual direta e o posicionamento das entidades visual que representam o software subjacente. Construo Visual tende a ser um pouco limitado pela dificuldade de fazer complexas declaraes usando apenas o movimento das entidades visuais numa exibio. No entanto, tambm pode ser uma ferramenta poderosa nos casos em que a tarefa de programao principal simplesmente construir e ajustar uma interface visual a um programa, comportamento detalhado do que foi definido anteriormente. c) Codificando As consideraes seguintes se aplicam codificao na atividade de construo software: [Ben00; IEEE12207-95; McC04] Tcnicas para criar cdigo fonte compreensvel, incluindo a nomeao e layout de cdigo de origem. Utilizao de classes, tipos enumerados, variveis, constantes nomeados e outras entidades similares. Uso do controle estruturas. Manuteno das condies de erro tanto planejadas erros e excepes (entrada de dados incorreto, por exemplo). Preveno das violaes de segurana de nvel de cdigo (saturaes de buffer ou matriz ndice estouros, por exemplo).

67

Uso de recursos atravs da utilizao de mecanismos de excluso e disciplina no acessar srie de recursos reutilizveis (incluindo threads ou bloqueios de banco de dados). Organizao de cdigo de origem (em declaraes, rotinas, classes, pacotes ou outras estruturas). Documentao de cdigo. Ajuste de cdigo

d) Testando a Construo Construo envolve duas formas de testes, que frequentemente so executadas pelo engenheiro de software que escreveu o cdigo: [Bec99; Hun00; Mag93; McC04] Testes de unidade Testes de integrao. O objetivo dos testes de construo visa reduzir a lacuna entre o tempo em que os defeitos so inseridos no cdigo e o tempo que os mesmos so detectados. Em alguns casos, testes de construo so executados depois de cdigo foi escrito. Em outros casos, os testes podem ser criados antes que cdigo seja escrito. Testes de construo envolvem tipicamente um subconjunto de tipos de testes, que so descritos na rea de conhecimento de teste de software. Por exemplo, testes de construo normalmente no incluem testes de sistema, testes alfa, teste beta, stress testing, teste de configurao, testes de usabilidade ou outros, mais tipos especializados dos testes. Duas normas foram publicadas sobre o tema: padro IEEE 829-1998, padro de IEEE para documentao de teste de software e padro de IEEE 1008-1987, padro de IEEE para testes de unidade de software. e) Reutilizao Tal como consta a introduo de (IEEE1517-99): Executando reutilizao de software implica mais do que criar e usar bibliotecas de recursos. necessrio formalizar a prtica de reutilizao, integrando os processos de reutilizao e atividades no ciclo de vida do software. No entanto, a reutilizao suficientemente importante na construo de software, e que includa aqui como um tpico.

68

As tarefas relacionadas com a reutilizao na construo de software durante a codificao e testes so: [IEEE1517-99; Som05] A seleo das unidades reutilizveis, bancos de dados, procedimentos de ensaio ou testar dados. A avaliao da reutilizao de cdigo ou de teste A comunicao de informaes de reutilizao sobre o novo cdigo, testar procedimentos ou testar dados. f) Qualidade da Construo Numerosas tcnicas existem para garantir a qualidade de como o cdigo construdo. As principais tcnicas utilizadas para construo incluem:[Bec99; Hun00; IEEE12207-95; Mag93; McC04] Unidade ensaios e testes de integrao (tal como mencionado no tpico 3.4 testes de construo) Primeiro teste de desenvolvimento (ver igualmente o teste de software na rea de conhecimento, tpico 2.2 objetivos de teste) Cdigo de reforo Utilizao de afirmaes Depurao Revises tcnicas(ver igualmente o software qualidade na rea de conhecimento, anlises tcnicas do sub-tpico 2.3.2) Anlise esttica (IEEE1028) (ver igualmente na rea de conhecimento de qualidade de software, tema 2.3 revises e auditorias). A tcnica especfica ou tcnicas selecionadas dependem da natureza do software a ser construdo, bem como dos engenheiros de software no conjunto habilidades executando a construo. Atividades de qualidade de construo so diferenciadas das outras atividades de qualidade pelo seu foco. Atividades de qualidade de construo concentram-se no cdigo e no nos artefatos que esto intimamente relacionados ao cdigo: desenhos pequenos em vez de outros artefatos que esto menos diretamente conectados com o cdigo, como requisitos, design de alto nvel e planos. g) Integrao

69

Uma atividade fundamental durante a construo a integrao das rotinas construdas separadamente, classes, componentes e subsistemas. Alm disso, um sistema de software especfico talvez precise ser integrado com outros sistemas de software ou hardware. Preocupaes relacionadas com a integrao da construo incluem planejamento a sequncia em que os componentes sero integrados, criando suporte para apoiar a verses provisrias do software, determinar o grau de testes e trabalho de qualidade realizado nos componentes antes de serem integrados e em que determinantes pontos no projeto, verses provisrias do software so testadas. [Bec99; IEEE12207-95; McC04] 2.1.3.4 Teste de Software Teste de software uma atividade executada para avaliar a qualidade do produto, e para melhor-lo, pela identificao de defeitos e problemas. Teste de software consiste da verificao dinmica do comportamento de um programa em um conjunto finito de casos de teste, adequadamente selecionados de um domnio de execuo usualmente infinito, contra o comportamento esperado. Na definio anterior, as palavras em itlico correspondem a assuntos chave na identificao de rea do Conhecimento de Teste de Software. Em particular: Dinmico: Esse termo significa que testar sempre implica executar o programa com entradas (valorizadas). Para ser preciso, s os valores de entrada no so sempre suficientes para determinar um teste, desde que um sistema complexo, no determinstico pode reagir mesma entrada com diferentes comportamentos, dependendo do estado do sistema. Nessa rea do conhecimento, embora o termo entrada ser mantido, com a conveno includa que seu significado tambm inclua um estado especfico de entrada, nesses casos para os quais isso necessrio. Diferente de testar e complementar a isso, so as tcnicas estticas descritas na rea de Conhecimento Qualidade de Software.

Finito: At mesmo em programas simples, tantos casos de testes so teoricamente possveis que testes exaustivos possam exigir meses ou anos para executar. Isso por que na prtica o conjunto inteiro de testes pode geralmente ser considerado infinito. Testes sempre implicam em uma troca

70

entre recursos limitados e programados de um lado, e exigncias inerentemente ilimitadas de testes de outro. Selecionado: As muitas tcnicas propostas de teste diferem essencialmente em como elas selecionam o conjunto de teste, e engenheiros de software precisam estar atentos que critrios de seleo diferentes podem render diferentes graus de efetividade. Como identificar o critrio de seleo mais satisfatrio em determinadas condies um problema muito complexo; na prtica, tcnicas de anlise de risco e percias de engenharia de testes so aplicadas. Esperado: Deve ser possvel, embora nem sempre fcil, decidir se os resultados observados da execuo do programa so aceitveis ou no, caso contrrio, o esforo de teste seria intil. O comportamento observado pode ser conferido contra expectativas de usurio (comumente chamado teste para validao), contra uma especificao (teste para verificao), ou finalmente, contra o comportamento antecipado de exigncias implcitas ou expectativas razoveis. A viso de testes de software tem evoludo para uma mais construtiva. Teste j no mais visto como uma atividade que comea somente depois que a fase de codificao est completa, com a finalidade limitada de deteco de falhas. Teste de software agora visto como uma atividade que deve abranger todo o processo de desenvolvimento e manuteno e ele parte importante da construo atual do produto. Realmente, o planejamento para teste deveria comear nos estgios iniciais dos processos de requisitos, e planos de teste e procedimentos precisam ser sistematicamente e continuamente desenvolvidos, e possivelmente refinados, como desenvolvimento contnuo. Estes planos de teste e atividades de planejamento constituem contribuio til para desenvolvedores realando potenciais debilidades (como descuidos ou contradies, e omisses ou ambiguidades na documentao). considerado atualmente que a atitude certa em direo qualidade uma de preveno: obviamente muito melhor evitar problemas que corrigi-los. Testes devem ser vistos, ento, principalmente como meios para conferir no s se a preveno foi efetiva, mas tambm para identificar faltas nesses casos onde, por alguma razo, no foi efetivo. talvez bvio mas com reconhecido valor que, at mesmo depois da concluso de uma extensiva campanha de testes, que o software

71

ainda possa conter falhas. O remdio para falhas experimentadas de software depois da entrega feito por aes de manuteno corretiva. Tpicos de Manuteno de Software esto cobertos na rea de Conhecimento Manuteno de Software. Na rea de Conhecimento Qualidade de Software, tcnicas de administrao de qualidade de software so categorizadas notavelmente em tcnicas estticas (nenhuma execuo de cdigo) e tcnicas dinmicas (execuo de cdigo). Ambas as categorias so teis. Esta rea de Conhecimento focaliza em tcnicas dinmicas. Teste de software tambm relacionado a construo de software (veja tpico 3.3). Testes de unidade e integrao so relacionados intimamente com a construo de software, e no parte disso.

Figura 15: Tpicos para rea de Conhecimento Teste de Software

2.1.3.4.1 Fundamentos de Teste de Software Muitos termos so usados na literatura da engenharia de software para descrever um mau funcionamento, falha notvel, fracasso, erro, e outros vrios. Essa terminologia precisamente definida em IEEE Standard 610.12-1990, Standard Glossary of Software Engineering Terminology (IEEE610-90), e isso

72

discutido tambm na rea de conhecimento Qualidade de Software. Isso essencial para distinguir claramente entre a causa de um mau funcionamento, para o qual o termo falha ou defeito ser usado aqui, e um indesejvel efeito observado no servio entregue do sistema, o qual ser chamado um fracasso. Testes podem revelar fracassos, mas so as falhas que podem e devem ser removidas. Porm, deveria ser reconhecido que a causa de um fracasso no pode ser sempre inequivocamente identificado. No existe um critrio terico para determinar definitivamente que falta causou o fracasso observado. Poderia ser dito que era a falta que tinha de ser modificada para remover o problema, mas outras modificaes poderiam ter trabalhado bem da mesma maneira. Para evitar ambiguidades, alguns autores preferem falar de entradas causando fracassos (Fra98) em vez de falhas, quer dizer, esses conjuntos de entradas que causam um fracasso. a) Critrios de seleo de testes / critrios de suficincia de Teste (ou regras de parada) Um critrio de seleo de testes um meio de decidir qual conjunto satisfatrio de casos de testes deve ser. Um critrio de seleo de testes pode ser usado para selecionar os casos de testes ou checar qual suite de testes adequada, quer dizer, decidir se o teste pode ser parado. Veja tambm as terminaes do sub tpico, no tpico 5.1 Consideraes prticas. Zhu97:s1.1 (Wey83; Wey91; Zhu97) b) Efetividade do teste / Objetivos de teste Testar a observao de uma amostra de execues do programa. Selees de amostras podem ser guiadas por diferentes objetivos: isso somente na luz do objetivo procurado que a efetividade do conjunto de teste pode ser avaliada. [Per95:c21] (Fra98) c) Teste para identificao de defeito Nos testes para identificao de defeito, um teste de sucesso um que causa a falha do sistema. Isso bastante diferente dos testes para demostrar que o software satisfaz suas especificaes ou outras propriedades desejadas, nesse caso, o teste de sucesso se nenhuma falha (significante) observada. [ Kan99:c1 ]

73

d) O problema do orculo Um orculo qualquer agente (humano ou mecnico) que decide se um programa se comportou corretamente dentro de um determinado teste, e consequentemente produz um veredito de passe ou falhe. Existem muitos tipos de orculos e a automao de orculos pode ser muito difcil e cara. [Bei90:c1] (Ber96, Wey83) e) Limitaes tericas e prticas de teste A teoria de teste adverte contra atribuir nvel injustificado de confiana para uma srie de testes passados. Infelizmente, a maioria dos resultados estabelecidos de teoria de teste so negativos, na condio de que um teste pode nunca alcanar ao invs de que eles atualmente alcanam. A citao mais famosa nessa considerao o provrbio de Dijkstra que teste de programa pode ser usado para provar a presena de bugs, mas nunca para mostrar sua ausncia. A razo bvia que o teste completo de software no possvel em software real. Por causa disto, o teste precisa ser dirigido baseado no risco e pode ser visto como uma estratgia de administrao de risco. [Kan99:c2] (How76) f) O problema dos caminhos inviveis Caminhos inviveis, os caminhos de controle de fluxo que no podem ser exercitados por qualquer dados de entrada, so um significante problema no teste de caminho orientado, e particularmente na derivao automatizada de testes de entrada para tcnicas de teste cdigo baseadas. [Bei90:c3] g) Testabilidade O termo testabilidade de software tem dois significados diferentes mas relacionados: por um lado, se refere ao grau a que se fcil para o software cumprir um critrio de cobertura de teste, como em (Bac90); por outro lado, est definida como a probabilidade, possivelmente medida estatisticamente, que o software ir expor uma falha sob o teste, se est defeituoso, como em (Voa98, Ber96a). Ambos os significados so importantes. [Bei90:c3, c13] (Bac90; Ber96a; Voa95) h) Relaes de teste com outras atividades

74

Teste de software relacionado a, mas diferente de tcnicas estticas de administrao de qualidade de software, provas de exatido, depurao e programao. Porm, informativo considerar os testes do ponto de vista de analistas de qualidade de software e de certificadores. Teste versus tcnicas estticas de administrao da qualidade de software. Veja tambm a rea de Conhecimento Qualidade de Software, sub rea 2. Processos de administrao da qualidade do software. Per95:c17 (IEEE1008-87). Teste versus provas de exatido e verificao formal Pfl01:c8. Teste versus depurao. Veja tambm a rea de Conhecimento Conhecimento Construo Construo de de Software, Software, tpico tpico 3.4 3.4 Teste Teste de de construo. construo. [Bei90:c1s2.1] (IEEE1008-87). Teste versus programao. Veja tambm a rea de [Bei90:c1s2.3]. Teste e certificao (Wak99). 2.1.3.4.2 Nveis de Teste a) alvo do teste O teste de software executado geralmente a nveis diferentes ao longo dos processos do desenvolvimento e da manuteno. Isso para dizer, o alvo do teste pode variar: um nico mdulo, um grupo de tais mdulos (relacionados pela finalidade, uso, comportamento, ou estrutura), ou um sistema inteiro. [Bei90: c1; Jor02: c13; Pfl01: c8] Trs estgios grandes de teste podem ser conceitualmente distinguidos, so eles: unidade, integrao, e sistema. O modelo do processo no significativo, nem suposto que algum daqueles trs estgios tenha maior importncia do que os outros dois. teste de unidade - [Bei90: c1; Per95: c17; Pfl01: c8s7.3] (IEEE1008-87) O teste de unidade verifica o funcionamento isoladamente das partes do software que so testveis separadamente. Dependendo do contexto, estas podiam ser os subprogramas ou os grandes componentes feitos de unidades firmemente relacionadas. Um teste de unidade definido mais precisamente no padro IEEE para Teste de unidade de software (IEEE1008-87), que tambm descreve uma aproximao integrada para testes de unidade sistemticos e documentados. Tipicamente, o teste de unidade ocorre com acesso ao cdigo que est sendo testado e com o suporte de ferramentas de depurao de erros, e fora o envolvimento dos programadores que

75

escreveram o cdigo. teste de integrao - [Jor02: c13, 14; Pfl01: c8s7.4] O teste da integrao o processo de verificar a interao entre os componentes de software. Estratgias clssicas de teste de integrao, tais como de cima pra baixo ou de baixo para cima, so usadas com software tradicional, hierarquicamente estruturado. As estratgias modernas de integrao sistemticas so um pouco guiadas pela arquitetura, implica que a integrao dos componentes de software ou subsistemas baseiam-se em linhas de identificao funcional. O teste da integrao uma atividade contnua, em cada estgio no qual os engenheiros de software devem abstrair perspectivas de baixo nvel distantes e concentrar nas perspetivas do nvel que esto integrando. exceo de software pequeno, simples, sistemtico, as estratgias de teste de integrao incremental, so geralmente preferveis para colocar todos os componentes juntos imediatamente, que chamado pictorialmente de teste dobig bang. teste de sistema - Pfl01:c9 O teste do sistema estado relacionado com o comportamento de um sistema inteiro. A maioria das falhas funcionais deve j ter sido identificada durante os testes de unidade e de integrao. O teste do sistema considerado geralmente apropriado para comparar o sistema aos requisitos de sistema no funcionais, tais como a segurana, a velocidade, a exatido, e a confiabilidade. As interfaces externas a outras aplicaes, as utilidades, os dispositivos de hardware, ou o ambiente operacional so avaliadas neste nvel tambm. Ver a rea de Conhecimento requisitos de software para mais informao sobre requisitos funcionais e no funcionais b) objetivos de teste - Pfl01:c9s8.3 O teste conduzido na perspectiva de um objetivo especfico, que fixado mais ou menos explicitamente, e com vrios graus de preciso. Fixando o objetivo em termos precisos e quantitativos, permite que o controle seja estabelecido sobre o processo do teste. O teste pode ser apontado na verificao de propriedades diferentes. Os casos de teste podem ser projetados para a verificao da correta execuo das especificaes funcionais, que referido variadamente na literatura como teste de conformidade, teste de exatido, ou teste funcional. Entretanto, diversas outras propriedades no funcionais podem ser testadas tambm, incluindo

76

o desempenho, a confiabilidade, e a usabilidade, entre muitas outras. Outros objetivos importantes para o teste incluem (mas no se limitam) a medida da confiabilidade, a avaliao da usabilidade, e a aceitao, para que as aproximaes diferentes sejam tomadas. Note que o objetivo do teste varia com o alvo de teste; geralmente, finalidades diferentes que esto sendo endereadas a diferentes nveis de teste. As referncias recomendadas acima para este tpico descrevem o conjunto de potenciais objetivos de teste. As sub-tpicos listados abaixo so aqueles mencionados mais frequentemente na literatura. Note que alguns tipos de teste so mais apropriados para pacotes de software feitos sob medida, teste de instalao, por exemplo; e outros para produtos genricos, como teste beta. Teste de aceitao e qualificao - Pfl01:c9s8.5 (IEEE12207.0-96:s5.3.9) O teste de aceitao verifica o comportamento do sistema de encontro aos requisitos do cliente, porm estes devem ter sido expressados; os clientes empreendem, ou especificam, tarefas tpicas para verificar se seus requisitos esto sendo cumpridos ou que a organizao tenha identificado estes (requisitos) para o objetivo mercadolgico do software. Esta atividade de teste pode ou no pode envolver os desenvolvedores do sistema. teste de instalao - Pfl01:c9s8.6 Geralmente aps a concluso do teste do software e de aceitao, o software pode ser verificado em cima da instalao no ambiente alvo. O teste de instalao pode ser visto como teste do sistema conduzido mais uma vez de acordo com requisitos de configurao de hardware. Os procedimentos de instalao tambm podem ser verificados. teste alfa e beta - [Kan99:c13] Antes que o software seja liberado, s vezes ele fornecido a um grupo pequeno mas representativo de potenciais usurios para o uso experimental, interno (teste alfa) ou o externo (teste beta). Estes usurios relatam problemas com o produto. O uso alfa e beta frequentemente descontrolado, e no referido sempre dentro de um plano de teste. teste de conformidade/teste funcional/teste de exatido - Per95:c8 (Wak99) O teste de conformidade tem por objetivo validar se o comportamento do software testado conforma-se a suas especificaes. Realizao e avaliao da confiabilidade - Pfl01:c9s.8.4 (Pos96) Ajudando na identificao de falhas, testar um meio de melhorar a confiabilidade. Pelo

77

contraste, pela gerao aleatria de casos de teste de acordo com o perfil operacional, as medidas estatsticas de confiabilidade podem ser derivadas. Usando modelos incrementais de confiabilidade, ambos os objetivos podem ser levados a cabo juntos (ver o sub tpico 4.1.4 teste de vida, avaliao da confiabilidade). teste de regresso - Per95:c11, c12; Pfl01:c9s8.1 (Rot96) De acordo com (IEEE610.12-90), o teste de regresso reteste seletivo de um sistema ou de um componente para verificar que modificaes no causaram efeitos no intencionais Na prtica, a ideia mostrar que esse software que passou previamente nos testes ainda passa. Beizer (Bei90) define como qualquer repetio de teste que pretende mostrar que o comportamento do software inalterado, exceto quando necessrio. Obviamente um trade-off deve ser feito entre a garantia dada pelo teste de regresso cada vez que uma mudana feita e os recursos exigiram fazer isso. O teste de regresso pode ser conduzido em cada um dos nveis do teste descritos no tpico 2.1 alvo do teste e pode aplicar-se ao teste funcional e no funcional

teste de performance - Pfl01:c9s8.3 (Wak99) Este tem por objetivo especfico verificar se o software cumpre as exigncias especficas de desempenho, por exemplo, por instncia, capacidade e tempo de resposta. Um tipo especfico do teste de desempenho o teste de volume (Per95: p185, p487; Pfl01: p401), em que as limitaes internas do programa ou do sistema so experimentadas. teste de stress - Pfl01:c9s8.3 O teste de stress fora o software na carga mxima de projeto, assim como alm dela. teste back-to-back - Um nico conjunto de teste executado em duas verses implementadas de um produto de software, e os resultados so comparados. teste de recuperao - Pfl01:c9s8.3 O teste de recuperao tem o objetivo de verificar as capacidades de reincio do software aps um desastre. teste de configurao - Pfl01:c9s8.3 Nos casos onde o software construdo para servir usurios diferentes, o teste da configurao analisa o software sob as vrias configuraes especficas. teste de usabilidade - Pfl01:c9s8.3 Este processo avalia o quanto fcil para

78

que os utilizadores finais usem e aprendam o software, incluindo a documentao de usurio; como efetivamente o software funciona no apoio de tarefas do usurio; e, finalmente, sua habilidade de se recuperar de erros do usurio. teste dirigido de desenvolvimento [Bec02] O teste dirigido de desenvolvimento no uma tcnica de teste por si s, promovendo o uso de testes como um substituto para um documento de especificao de requisitos, como uma verificao independente se o software implementou corretamente os requisitos. 2.1.3.4.3 Tcnicas de Teste Um dos objetivos do teste revelar tanto potencial para a falha como possvel, e muitas tcnicas foram desenvolvidas para fazer isso, que tentam parar o programa, rodando um ou vrios testes esboados das classes identificadas de execues julgadas equivalentes. O princpio fundamental que a base de tais tcnicas ser to sistemtico como possvel em identificar um conjunto representativo de comportamentos do programa; por exemplo, considerando subclasses do domnio de entrada, cenrio, estados, e fluxo de dados. difcil encontrar uma base homognea para classificar todas as tcnicas, e essa usada aqui deve ser vista como um compromisso. A classificao baseada em como os testes so gerados da intuio e da experincia do engenheiro de software, as especificaes, a estrutura do cdigo, (real ou artificial) falhas a serem descobertas, o uso de campos, ou, finalmente, a natureza da aplicao. s vezes estas tcnicas so classificadas como caixa branca, igualmente chamada caixa transparente, se os testes confiam na informao sobre como o software foi projetado ou codificado, ou como caixa-preta se os casos de teste confiam somente no comportamento de entrada/sada. Uma ltima categoria trata o uso combinado de duas ou mais tcnicas. Obviamente, estas tcnicas no so usadas muitas vezes igualmente por todos os engenheiros. So includas na lista aquelas que um engenheiro de software deve saber. a) baseadas na intuio e na experincia da engenheiro de software teste ad hoc [Kan99: c1] Talvez a tcnica mais extensamente praticada

79

permanea sendo o teste ad hoc: os testes so derivados confiando na habilidade do engenheiro de software, intuio, e experincia com programas similares. O teste ad hoc pode ser til para identificar testes especiais, aqueles no facilmente capturados por tcnicas formalizadas. Teste exploratrio - O teste exploratrio definido simultaneamente como aprendizagem, o projeto do teste, e a execuo do teste; isto , os testes no so definidos antecipadamente em um plano de teste estabelecido, mas so dinamicamente projetados, executados, e modificados. A eficcia do teste exploratrio confia no conhecimento do engenheiro de software, que pode ser derivado de vrias fontes: comportamento observado do produto durante o teste, familiaridade com a aplicao, a plataforma, o processo da falha, o tipo de falhas e fracassos possveis, o risco associado com um produto em particular, e assim por diante. [Kan01: c3] b) tcnicas baseadas na Especificao * 3.2.1. Diviso equivalente [Jor02: c7; Kan99: c7] - O domnio de entrada subdividido em uma coleo de subconjuntos, ou classes equivalentes, que so julgadas equivalente de acordo com uma relao especfica, e um conjunto representativo dos testes (s vezes somente um) so tomados de cada classe. Anlise do valor limite [Jor02: c6; Kan99: c7] - Os casos de teste so escolhidos prximo e nos limites do domnio da entrada das variveis, com a razo subjacente que muitas falhas tendem a se concentrar perto dos valores extremos de entradas. Uma extenso desta tcnica teste de vigor, onde as situaes de teste so escolhidas igualmente fora do domnio da entrada das variveis, para testar o vigor do programa para entradas inesperadas ou errneas. Tabela de deciso [Bei90: c10s3] (Jor02) - As tabelas de deciso representam relacionamentos lgicos entre condies (aproximadamente, entradas) e aes (aproximadamente, sadas). Os casos de teste so derivados sistematicamente considerando cada combinao possvel de condies e de aes. Uma tcnica relacionada a representao grfica de causa-efeito. [Pfl01: c9] Baseada em mquina de estado finito Jor02:c8 - Modelando um programa

80

como uma mquina de estado finito, os testes podem ser selecionados a fim cobrir estados e transies nela. Teste das especificaes formais [Zhu97: s2.2] (Ber91; Dic93; Hor95) - Dar as especificaes em uma linguagem formal permite a derivao automtica de casos de teste funcionais, e, ao mesmo tempo, fornece uma sada de referncia, um orculo, para verificar os resultados do teste. Os mtodos existem derivando casos de teste de especificaes modelo baseadas (Dic93, Hor95) ou algbricas. (Ber91) Teste aleatrio [Bei90: c13; Kan99: c7] - Os testes so gerados puramente em aleatrio, para no ser confundidos com o teste estatstico do perfil operacional como descritos no sub tpico 3.5.1 perfil operacional. Esta forma de teste cai sob o ttulo da entrada de especificao baseada, desde que pelo menos o domnio da entrada seja conhecido, para poder escolher pontos aleatrios dentro dele. c) tcnicas cdigo baseadas Critrios ipecaconhas-de-flor-branca [Bei90: c3; Jor02: c10] (Zhu97) - Os critrios de cobertura ipecaconhas-de-flor-branca tem o objetivo de cobrir todas as indicaes ou blocos de indicaes em um programa, ou combinaes especficas deles. Diversos critrios de cobertura foram propostos, como a cobertura circunstncia/deciso. O mais forte dos critrios controle de fluxo baseados o teste do trajeto, que tem por objetivo executar todos os trajetos do fluxo de controle de entrada a sada no grfico de fluxo. Desde que o teste do trajeto no seja geralmente praticvel por causa dos laos, outros critrios menos estritos tendem a ser usados na prtica, como o teste de declarao, o teste de ramificao, e o teste de condio/deciso. A suficincia de tais testes medida nas porcentagens; por exemplo, quando todas as ramificaes foram executadas pelo menos uma vez pelos testes, a cobertura da ramificao de 100% dita ter sido conseguida. Critrios fluxo de dados baseados [Bei90: c5] (Jor02; Zhu97) - No teste fluxo de dados baseado, o grfico de fluxo de controle anotado com informao sobre como as variveis do programa so definidas, usadas, e destrudas (indefinidas). O critrio mais forte, trajetos de uso definidos, necessita que,

81

para cada varivel, todo segmento do trajeto do fluxo de controle de uma definio de qual varivel para um uso de qual definio seja executada. A fim de reduzir o nmero de trajetos exigidos, estratgias mais fracas tais como todas as definies e todos osusos so empregadas. Modelos de referncia para o teste cdigo baseado (grfico de fluxo, grafo chamado) [Bei90: c3; Jor02: c5]. - Embora no seja uma tcnica em si, a estrutura de controle de um programa representada graficamente usando um grfico de fluxo nas tcnicas de teste cdigo baseadas Um grfico de fluxo um grafo dirigido de ns e arcos que correspondem aos elementos do programa. Por exemplo, os ns podem representar declaraes ou sequncias ininterruptas de declaraes, e arcos a transferncia de controle entre os ns. d) Tcnicas falha baseadas Com graus diferentes de formalizao, as tcnicas de teste falha baseadas planejam as situaes de teste visadas especificamente revelando categorias de falhas predefinidas ou provveis. (Mor90) Suposio do erro [Kan99: c7] - No suposio do erro, as situaes de teste so projetadas especificamente pelas engenheiros de software que tentam externar as falhas mais plausveis em um programa dado. Uma boa fonte de informao a histria das falhas descobertas em projetos prematuros, assim como a percia do engenheiro de software.

Teste de mutao [Per95: c17; Zhu97: s3.2-s3.3] - Um mutante uma verso ligeiramente modificada do programa sob o teste, diferindo dele por uma mudana pequena, sinttica. Cada caso de teste exercita ambos o original e todos os mutantes gerados: se um caso de teste bem sucedido em identificar a diferena entre o programa e um mutante, o ltimo seria destrudo. Concebido originalmente como uma tcnica para avaliar um caso do teste (ver 4.2), teste de mutao igualmente um critrio de teste por si s: outros testes so gerados aleatoriamente at que mutantes suficientes estejam destrudos, ou testes so projetados especificamente para destruir mutantes sobreviventes. No ltimo caso, o teste da mutao pode igualmente ser categorizado como uma tcnica cdigo baseada A

82

suposio subjacente do teste de mutao, o efeito do acoplamento, que procurando as falhas sintticas simples, mais falhas complexas porm reais sero encontradas. Para que a tcnica seja eficaz, um grande nmero de mutantes deve ser automaticamente derivado de uma maneira sistemtica. e) Tcnicas uso baseadas Perfil operacional [Jor02: c15; Lyu96: c5; Pfl01: c9] - No teste para a avaliao da confiabilidade, o ambiente de teste deve reproduzir o ambiente operacional dos software to prximo como possvel. A ideia para inferir, dos resultados da anlise observados, a confiabilidade futura do software quando no uso real. Para fazer isto, entradas so atribudas numa distribuio de probabilidade, ou num perfil, de acordo com sua ocorrncia na operao real. Teste projetado da confiabilidade de software [Lyu96: c6] - O teste projetado da confiabilidade de software (SRET) um mtodo de teste que abrange o processo de desenvolvimento inteiro, por meio de que o teste projetado e guiado por objetivos de confiabilidade e uso relativo e criticidade previstos de funes diferentes no campo. f)Tcnicas baseadas na natureza da aplicao As tcnicas acima aplicam-se a todos os tipos de software. Entretanto, para alguns tipos das aplicaes, algum "know-how" adicional exigido para a derivao do teste. Uma lista de alguns campos de teste especializados fornecida aqui, baseada na natureza da aplicao sob o teste: Teste orientado ao objeto [Jor02: c17; Pfl01: c8s7.5] (Bin00) Teste componente baseado Teste web baseado Teste de GUI [Jor20] Teste dos programas simultneos (Car91) Teste de conformidade do protocolo (Pos96; Boc94) Teste de sistemas de tempo real (Sch94) Teste dos sistemas segurana crticos (IEEE1228-94)

g) Selecionando e combinando tcnicas

83

Funcional e estrutural [Bei90: c1s.2.2; Jor02: c2, c9, c12; Per95: c17] (Pos96) - As tcnicas de teste baseadas na especificao e cdigo baseadas so contrastadas frequentemente como testes funcionais versus estruturais. Estas duas aproximaes para seleo de teste no devem ser vistas como alternativas mas como bastante complementares; de fato, usam fontes de informao diferentes e tem demonstrado destacar tipos diferentes de problemas. Poderiam ser usadas em combinao, dependendo das consideraes oramentais. Determinsticas versus aleatrias (Ham92; Lyu96: p541-547) - Os casos de teste podem ser selecionados de uma maneira determinstica, de acordo com uma das vrias tcnicas listadas, ou selecionados aleatoriamente de alguma distribuio de entradas, como feito geralmente no teste de confiabilidade. Diversas comparaes analticas e empricas foram conduzidas para analisar as condies que fazem uma aproximao mais eficaz do que a outra.

2.1.3.4.4 Medidas Relacionadas ao Teste s vezes, as tcnicas de teste so confundidas com os objetivos do teste. As tcnicas de teste devem ser vistas como auxlio que ajudam a assegurar a realizao de objetivos do teste. Por exemplo, a cobertura da ramificao uma tcnica de teste popular. Conseguir uma medida especfica da cobertura da ramificao no deve ser considerada o objetivo do teste por si s: um meio para melhorar as possibilidades de encontrar falhas sistematicamente exercitando cada ramificao do programa fora de um ponto de deciso. Para evitar tais enganos, uma distino clara deve ser feita entre as medidas teste relacionadas, que fornecem uma avaliao do programa sob o teste baseado nas sadas observadas do teste, e as aquelas que avaliam a eficcia do conjunto do teste. A informaes adicionais em medida de programas fornecida na rea de conhecimento da gerncia da engenharia de software, sub rea 6, medio da engenharia de software. A informaes adicionais em medidas pode ser encontrada na rea de conhecimento do processos de engenharia de software, na sub rea 4, processos e medida do produto. A medida considerada geralmente instrumental anlise da qualidade. A medida pode igualmente ser usada para aperfeioar o planejamento e execuo dos testes. A gerncia de teste pode usar diversas medidas de processos

84

para monitorar o progresso. As medidas relativo ao processo do teste para finalidades de gerncia so consideradas no tpico 5.1 consideraes prticas. a) Avaliao do programa sob o teste Medidas do programa para auxiliar no planejamento e no teste do projeto [Bei90: c7s4.2; Jor02: c9] (Ber96; IEEE982.1-88) - As medidas baseadas no tamanho do programa (por exemplo, linhas de cdigo fonte ou pontos de funo) ou na estrutura do programa (como a complexidade) so usadas para guiar o teste. As medidas estruturais podem igualmente incluir medidas entre os mdulos de programa nos termos da frequncia com que os mdulos chamam um ao outro. (IEEE982.1-98) Tipos, classificao, e estatsticas de falha [Bei90: c2; Jor02: c2; Pfl01: c8] (Bei90; IEEE1044-93; Kan99; Lyu96) - A literatura do teste rica nas classificaes e nas taxonomias das falhas. Para fazer o teste mais efetivo, importante saber que tipos de falhas poderiam ser encontrados no software sob o teste, e a frequncia relativa com que estas falhas ocorreram no passado. Esta informao pode ser muito til em fazer predies de qualidade, assim como para a melhoria do processo. Mais informao pode ser encontrada na rea de conhecimento qualidade de software, no tpico 3.2 caraterizao do defeito. Existe um padro IEEE em como classificar anomalias do software (IEEE1044-93).

Densidade de falha [Per95: c20] (IEEE982.1-88; Lyu96: c9) - Um programa sob teste pode ser avaliado pela contagem e classificao das falhas descobertas pelos seus tipos. Para cada classe de falha, a densidade da falha medida como a relao entre o nmero de falhas encontradas e o tamanho do programa. Teste de vida, avaliao da confiabilidade [Pfl01: c9] (Pos96: p146-154) Uma estimativa estatstica da confiabilidade de software, que possa ser obtida pela realizao e pela avaliao da confiabilidade (ver sub tpico 2.2.5), pode ser usada para avaliar um produto e para decidir se o teste pode ser parado ou no. Modelos de crescimento da confiabilidade [Lyu96: c7; Pfl01: c9] (Lyu96: c3,

85

c4) Os modelos de crescimento da confiabilidade fornecem uma predio da confiabilidade baseada nas falhas observadas sob a realizao e a avaliao da confiabilidade (ver o sub tpico 2.2.5). Eles assumem, geralmente, que as falhas que causaram os fracassos observados foram reparadas (embora alguns modelos igualmente aceitam reparos imperfeitos), e assim, em mdia, a confiabilidade do produto exibe uma tendncia de aumento. Existem agora dzias de modelos publicados. Muitos so colocados em algumas suposies comuns, enquanto outros diferem. Notavelmente, estes modelos so divididos em modelos de contagem de fracassos e modelos tempo entre fracassos. b) Avaliao dos testes executados Medidas de cobertura/eficcia [Jor02: c9; Pfl01: c8] (IEEE982.1-88) - Diversos critrios de suficincia de teste exigem que os casos de teste exercitem sistematicamente um conjunto de elementos identificados no programa ou nas especificaes (ver a sub tpico 3). Para avaliar a eficcia dos testes executados, os verificadores podem monitorar os elementos cobertos, de modo que possam dinamicamente medir a relao entre os elementos cobertos e seu nmero total. Por exemplo, possvel medir a porcentagem de ramificaes cobertas no grfico de fluxo do programa, ou dos requisitos funcionais exercidos entre aquelas listadas no documento das especificaes. Os critrios cdigo baseados de suficincia exigem a instrumentao apropriada do programa sob o teste. Semeando falhas [Pfl01: c8] (Zhu97: s3.1) - Algumas falhas so introduzidas artificialmente no programa antes do teste. Quando os testes so executados, alguma destas falhas semeadas sero reveladas, e possivelmente algumas falhas que j haviam l tambm sero. Na teoria, dependendo de qual das falhas artificiais so descobertas, e de quantas, o teste de eficcia pode ser avaliado, e o nmero restante de falhas genunas pode ser estimado. Na prtica, os estatsticos questionam a distribuio e a representatividade das falhas semeadas relativas s falhas genunas e do pequeno tamanho de amostra em que todas as extrapolaes so baseadas. Alguns igualmente discutem que esta tcnica deve ser usada com grande cuidado, desde que a

86

introduo de falhas no software envolve o risco bvio de deix-las l. Contagem da mutao [Zhu97: s3.2-s3.3] - No teste da mutao (ver o sub tpico 3.4.2), a relao de mutantes destrudos com o nmero total de mutantes gerados pode ser uma medida da eficcia do conjunto de teste executado.

Comparao e eficcia relativa das diferentes tcnicas [Jor02: c9, c12; Per95: c17; Zhu97: s5] (Fra93; Fra98; Pos96: p64-72) - Diversos estudos foram conduzidos para comparar a eficcia relativa de diferentes tcnicas de teste. importante ser preciso a respeito da propriedade contra a qual as tcnicas esto sendo avaliadas; que, por exemplo, dado o significado exato ao termo eficcia? As interpretaes possveis so: o nmero de testes necessrios para encontrar o primeiro fracasso, a relao do nmero de falhas encontradas por meio do teste para todas as falhas encontradas durante e aps o teste, ou quanto a confiabilidade foi melhorada. As comparaes analticas e empricas entre tcnicas diferentes foram conduzidas de acordo com cada um das noes da eficcia especificadas acima.

2.1.3.4.5 Processo de Teste Os conceitos, as estratgias, as tcnicas, e as medidas do teste precisam de ser integrados em um processo definido e controlado que funcione atravs de pessoas. O processo de teste suporta atividades de teste e fornece a orientao s equipes do teste, do plano de teste para o teste de avaliao da sada, de modo a oferecer a garantia justificada de que os objetivos do teste sejam encontrados de maneira rentvel. a) Consideraes prticas Atitudes/programao sem ego [Bei90: c13s3.2; Pfl01: c8] - Um componente muito importante do teste bem sucedido uma atitude colaborativa para o teste e as atividades de garantia da qualidade. Os gerentes tm um papel chave em promover uma recepo geralmente favorvel para a descoberta da falha durante o desenvolvimento e a manuteno; por exemplo, impedindo uma atitude mental da posse de cdigo entre programadores, de modo que no sintam responsveis pelas falhas reveladas por seu cdigo.

87

Guias de teste [Kan01] - As fases de teste podiam ser guiadas por vrios alvos, por exemplo: no teste risco baseado, que usa os riscos do produto para dar a prioridade e focalizar a estratgia do teste; ou no teste cenrio baseado, em que os casos de teste so definidos baseados em cenrios especficos do software. Teste da gesto de processo [Bec02: III; Per95: c1-c4; Pfl01: c9] (IEEE107497; IEEE12207.0-96: s5.3.9, s5.4.2, s6.4, s6.5) - O teste das atividades conduzidas a nveis diferentes (ver sub tpico 2 nveis de teste) deve ser organizado, junto com as pessoas, ferramentas, polticas, e medidas, em um processo bem definido que seja uma parte integrante do ciclo de vida. No IEEE/EIA Standard 12207.0, o teste no descrito como um processo autnomo, mas os princpios para atividades do teste so includos junto com os cinco processos preliminares do ciclo de vida e o processo de suporte. No IEEE STD 1074, o teste agrupado com outras atividades da avaliao como integrante ao ciclo de vida inteiro.

Teste de documentao e produtos do trabalho de [Bei90: c13s5; Kan99: c12; Per95: c19; Pfl01: c9s8.8] (IEEE829-98) - A documentao uma parte integrante da formalizao do processo de teste. O padro IEEE para teste de documentao de Software (IEEE829-98) fornece uma boa descrio de documentos de teste e de seus relacionamentos uns com os outros e com o processo do teste. Os documentos de teste podem incluir, entre outros, o plano de teste, a especificao do projeto do teste, a especificao do procedimento de teste, a especificao dos casos de teste, o registro de teste, e o relatrio do incidente ou problema do teste. O software sob o teste documentado como item do teste. A documentao de teste deve ser produzida e continuamente atualizada, ao mesmo nvel de qualidade que outros tipos de documentao na engenharia de software. Equipe de teste interna versus independente [Bei90: c13s2.2-c13s2.3; Kan99: c15; Per95: c4; Pfl01: c9] - a Formalizao do processo de teste pode envolver formalizar a organizao da equipe de teste tambm. A equipe do teste pode se compor de membros internos (isto , na equipe de projeto, envolvido ou no na construo do software), de membros externos, na esperana de trazer em uma perspetiva imparcial, independente, ou,

88

finalmente, de membros internos e externos. As consideraes de custos, de agendamento, de nveis da maturidade das organizaes envolvidas, e de criticidade da aplicao podem determinar a deciso. A estimao do custo/esforo e outras medidas do processo [Per95: c4, c21] (Per95: Apndice B; Pos96: p139-145; IEEE982.1-88) - Diversas medidas relativas aos recursos gastos no teste, assim como eficcia relativa da busca de falhas das vrias fases de teste, so usadas por gerentes para controlar e melhorar o processo do teste. Estas medidas do teste podem cobrir tais aspetos como nmero de casos de teste especficos, nmero de casos de teste executados, nmero de casos de teste passados, e nmero de casos de teste que falharam, entre outros. A avaliao de relatrios da fase de teste pode ser combinada com a anlise origem causa para avaliar a eficcia do processo de teste em encontrar falhas o mais cedo possvel. Tal avaliao pode ser associada com a anlise dos riscos. Alm disso, os recursos que gastam valor no teste devem ser proporcionais com o uso/criticidade da aplicao: as tcnicas diferentes tm custos diferentes e rendem nveis diferentes de confiana na confiabilidade do produto. Trmino [Bei90: c2s2.4; Per95: c2] - Uma deciso deve ser tomada se a quantidade de teste suficiente e quando um estgio de teste pode ser terminado. Medidas de eficcia, como a cobertura conseguida do cdigo ou a integralidade funcional, assim como estimativas da densidade das falhas ou da confiabilidade operacional, fornecem sustentao til, mas no so suficientes em si mesmas. A deciso igualmente envolve consideraes sobre os custos e os riscos incorridos pelo potencial para falhas restantes, ao contrrio dos custos implicados na continuidade do teste. Ver tambm sub tpico 1.2.1 critrios de seleo de testes /suficincia de testes. Reuso de teste e padres de teste [Bei90: c13s5] - Para realizar o teste ou a manuteno de uma maneira organizada e custo efetiva, os meios usados para testar cada parte do software devem ser reusados sistematicamente. Este repositrio de materiais do teste deve estar sob o controle da gerncia de configurao do software, de modo que as mudanas nos requisitos do software ou o projeto possam ser refletidos nas mudanas no escopo dos testes conduzidos. As solues de teste adotadas no teste de alguns tipos de

89

aplicao sob determinadas circunstncias, com as motivaes atrs das decises tomadas, do forma a um padro de teste que pode ser documentado para reuso posterior em projetos similares. b) Atividades de teste Sob este tpico, dada uma breve vista geral de atividades de teste; como implicado frequentemente pela seguinte descrio, a gerncia bem sucedida de atividades do teste depende fortemente do processo da gerncia de configurao do software. Planejamento [Kan99: c12; Per95: c19; Pfl01: c8s7.6] (IEEE829-98: s4; IEEE1008-87: s1-s3) - Como todos os outros aspetos do gerenciamento do projeto, as atividades de teste devem ser planejadas. Os aspectos chave do planeamento de teste incluem a coordenao dos pessoal, a gerncia das facilidades de teste e dos equipamentos disponveis (que podem incluir meios magnticos, planos de teste e procedimentos), e o planejamento para possveis resultados indesejveis. Se mais de uma linha de base do software est sendo mantida, ento uma considerao principal do planeamento o momento e o esforo necessrios para assegurar-se de que o ambiente de teste esteja ajustado configurao apropriada. Gerao de casos de teste [Kan99: c7] (Pos96: c2; IEEE1008-87: s4, s5) - A gerao de casos de teste baseada no nvel de teste a ser executado e das tcnicas de teste particulares. As situaes de teste devem estar sob o controle da gerncia de configurao do software e incluir os resultados previstos para cada teste. Desenvolvimento do ambiente de testes [Kan99: c11] - O ambiente usado para o teste deve ser compatvel com as ferramentas da tecnologia de programao. Deve facilitar o desenvolvimento e o controle dos casos de teste, assim como o registro e a recuperao de resultados previstos, de manuscritos, e de outros materiais do teste. Execuo [Bei90: c13; Kan99: c11] (IEEE1008-87: s6, s7) - A execuo dos testes deve personificar um princpio bsico de experimentao cientfica: tudo feito durante o teste deve ser executado e documentado bem claramente

90

para

que

uma

outra o

pessoa deve

possa ser

reproduzir executado

os de

resultados. acordo com

Consequentemente, software sob o teste.

teste

procedimentos documentados usando uma verso claramente definida do Avaliao dos resultados da anlise [Per95: c20, c21] (Pos96: p18-20, p131138) - Os resultados do teste devem ser avaliados para determinar se o teste foi mesmo bem sucedido ou no. Na maioria dos casos, bem sucedido significa que o software executou como esperado e no teve nenhum resultado principal inesperado. No todos os resultados inesperados so necessariamente falhas, entretanto, mas poderia ser julg para ser simplesmente o rudo. Antes que uma falha possa ser removida, uma anlise e um esforo na eliminao de erros necessrio para isol-la, identific-la, e descrev-la. Quando os resultados do teste so particularmente importantes, um conselho de reviso formal pode ser reunido para avali-los.

Relatrio do problema/registro do teste [Kan99: c5; Per95: c20] (IEEE829-98: s9-s10) - As atividades do teste podem ser incorporadas a um registro do teste para identificar quando um teste foi conduzido, quem executou o teste, que configurao de software foi a base para o teste, e outras informaes de identificao relevantes. Os resultados da anlise inesperados ou incorretos podem ser gravados em um sistema de relatrio de problemas, os dados que formam a base para uma posterior depurao e reparao de problemas que foram observados como falhas durante o teste. Tambm, as anomalias no classificadas como falhas poderiam ser documentadas no caso de se mostrarem posteriormente mais srias do que pensado inicialmente. Os relatrios de teste tambm so uma entrada ao processo de pedido de gerncia da mudana (ver rea de conhecimento gerenciamento de configurao de software, sub tpico 3, de controle de configurao do software). Procurando por defeito [Kan99: c6] Os fracassos observadas durante o teste so mais frequentemente devido a falhas ou defeitos no software. Tais defeitos podem ser analisados para determinar quando foram introduzidos no software, que tipo de erro fez com que eles fossem criados (requisitos mal definidos, declarao incorreta de variveis, estouro de memria, erro na

91

sintaxe de programao, por exemplo), e quando poderiam primeiramente ter sido observados no software. A informao da procura por defeito usada para determinar que aspetos da engenharia de software precisam melhorar e como foram eficazes as anlises e testes precedentes.

Figura 16: Tpicos x referncias (4)

92

Figura 17: Tpicos x referncias (5)

Figura 18: Tpicos x referncias (6)

93

2.1.3.5 Manuteno de Software Os esforos no desenvolvimento de software resultam em uma entrega de um produto de software que satisfaa as necessidades dos utilizadores. Consequentemente, os produtos de software devem mudar ou evoluir. Uma vez em operao, defeitos so descobertos, as operaes de ambientes mudam, e as novas necessidades aparecem. A fase de manuteno do ciclo de vida comea aps o perodo de garantia ou aps a implementao da entrega do suporte, mas as atividades de manuteno ocorrem muito mais cedo. A manuteno de software uma parte integral do ciclo de vida do software. Entretanto, ela no tem, historicamente, recebido o mesmo grau de ateno que as outras fases tm. Historicamente, o desenvolvimento de software tem tido um perfil muito mais elevado do que a manuteno de software, na maioria das organizaes. Isto agora est mudando, como as organizaes se esforando para espremer ao o mximo o seu investimento em desenvolvimento de software para manter a manuteno de software em operao o maior tempo possvel. Preocupaes sobre o Ano 2000 (Y2K) geraram uma significativa ateno focada sobre a fase manuteno de software, e os paradigmas dos Cdigos Abertos trouxeram ainda mais ateno questo dos artefatos de manuteno de software desenvolvida pelos outros. No Guia, manuteno de software definida como a totalidade das atividades necessrias para fornecer o melhor custo-benefcio ao suporte de software. As atividades so realizadas durante a fase pr entrega, bem como durante o perodo aps a entrega. As atividades pr entrega incluem o planejamento para as operaes ps-entrega, operaes estas de manuteno, logstica e de determinao de transio de atividades. As atividades pr entrega incluem modificao de software, formao e operao da interface de suporte. A rea de conhecimento de Manuteno de Software est relacionada a todos os outros aspectos da engenharia de software. Portanto, essa descrio de rea de conhecimento est ligada a todos os outros captulos do Guia. Repartio dos tpicos de Manuteno de software A repartio dos tpicos da rea de conhecimento de Manuteno de Software apresentada na Figura 19.

94

Figura 19: Tpicos da Manuteno de software

2.1.3.5.1 Fundamentos da Manuteno de Software Essa primeira seo introduz os conceitos e terminologia subjacente, que formam uma base para a compreenso do papel e o alcance da manuteno de software. Os tpicos fornecem definies e enfatizam o porqu da necessidade de manuteno. As categorias de manuteno de software so crticas para a compreenso do seu significado subjacente. a) Definio e Terminologia Manuteno de Software definida na Norma IEEE para Manuteno de Software, IEEE 1219, como a modificao de um produto de software aps a entrega para corrigir falhas, para melhorar o desempenho ou outros atributos, ou adaptar o produto para um ambiente modificado. A norma tambm arrola as atividades de manuteno antes da entrega do de produtos de software, mas apenas em um apndice da informao da norma. O IEEE/EIA 12207 uma norma para o processo do ciclo de vida de software que retrata essencialmente a manuteno como um dos processos primrios do ciclo de vida, e descreve a manuteno como o processo que sofre um produto de software de modificao de cdigo e documentao associada devido a um problema ou necessidade de melhoria. O objetivo modificar o software atual

95

enquanto o produto preserve a sua integridade." ISO/IEC 14764, o padro internacional para a manuteno de software, define manuteno nos mesmos termos do IEEE/EIA 12207, e enfatiza os aspectos pr entrega de manuteno, como, por exemplo, o planejamento.[IEEE1219-98:s3.1.12; IEEE12207.096:s3.1,s5.5; ISO14764-99:s6.1] b) Natureza da Manuteno A manuteno de Software sustenta o produto de software ao longo do seu ciclo de vida operacional. Os requisitos de modificao so registrados e monitorados, o impacto das propostas de mudanas determinado, cdigo de software e outros artefatos so modificados, o teste realizado, e uma nova verso lanada. Alm disso, a formao e o dirio de apoio so oferecidos aos usurios. Pfleeger [Pfl01] afirma que "a manuteno tem um objetivo maior, com maior monitoramento e controle" do que o desenvolvimento. Um mantenedor definido pelo IEEE/EIA 12207 como uma organizao que realiza atividades de manuteno [IEEE12207.0-96]. Este KA, muitas vezes, refere-se aos indivduos que desempenham essas atividades, contrapondo-os com os desenvolvedores. IEEE/EIA 12207 identifica as principais atividades de manuteno de software como: processo de execuo; problema com anlise e modificao; modificao, implementao, manuteno reviso/aceitao; migrao; e reformas. Estas atividades sero discutidas no tpico 3.2 Manuteno de Atividades. Os mantenedores podem aprender a partir do conhecimento do desenvolvedor de software. O contato precoce com os desenvolvedores ajuda a reduzir os esforos de manuteno do mantenedor. Em alguns casos, o engenheiro de software pode no ser encontrado ou se mudou para outras tarefas, o que cria um desafio adicional para os mantenedores. Os mantenedores devem ter os produtos do desenvolvimento, como os cdigos ou documentao, por exemplo, e mant-los ou evolu-los progressivamente ao longo do ciclo de vida do software.[Pfl01:c11s11.2] c) Necessidade da manuteno A manuteno necessria para assegurar que o software continue a satisfazer os requisitos dos usurios. A manuteno aplicvel a qualquer software desenvolvido utilizando o ciclo de vida modelo (por exemplo, em espiral). O sistema

96

 modificado devido s aes de mudanas corretivas e no corretivas. A sua manuteno deve ser realizada, a fim de: [Pig97: c2s2.3; Tak97:c1] Corrigir falhas; Melhorar o design; Implementar melhorias; Interface com outros sistemas; Adaptar programas para que diferentes hardware, software, sistema de recursos e de telecomunicaes possam ser utilizados; Migrar software legado Aposentar software As atividades de manuteno compreendero quatro caractersticas

principais, de acordo com Pfleeger [Pfl01]: Manter o controle sobre o software no dia-a-dia das funes; Manter o controle sobre as modificaes de software; Aperfeioar funes existentes; Impedir o desempenho degradante do software para um nvel inaceitvel;

d) A Maioria dos Custos de Manuteno A manuteno consome uma parte significativa dos recursos financeiros do ciclo de vida de software. A percepo comum de manuteno de software que ela apenas corrige falhas. No entanto, estudos e pesquisas ao longo dos anos tm indicado que a maioria, mais de 80%, do esforo da manuteno de software usada para aes no - corretivas. [Abr93, Pig97, Pre01] Jones (Jon91) descreve a maneira pela qual os grupos de gerentes de manuteno de software frequentemente apresentam melhorias e correes na gesto de seus relatrios. A incluso de problemas acessrios aos relatrios contribui para algumas das ideias erradas sobre o elevado custo de correes. Compreender as categorias de manuteno de software ajuda a compreender a estrutura dos custos de manuteno do software. Tambm, entender os fatores que influenciam a manuteno de um sistema pode ajudar na conteno de despesas. Pfleeger [Pfl01] apresenta alguns dos fatores tcnicos e no tcnicos que afetam os custos de manuteno de software, como segue: [Pfl01:c11s11.3;Pig97:c3;Pre01:c30s2.1, c30s2.2]

97

Tipo de aplicao Novidade em Software Disponibilidade de pessoal para a manuteno de software Durao de vida do Software Caractersticas do Hardware Qualidade de design de software, construo, documentao e testes.

e) Evoluo do Software Lehman foi o primeiro estudioso (addressed) da manuteno de software e evoluo anos, Evoluo". dos sistemas, pesquisas em 1969. Ao longo de um de o perodo oito fato de "Leis de que vinte de a suas levaram principais formulao incluem

[Leh97]. As

concluses

manuteno evolutiva, e que as decises sobre a manuteno so auxiliadas pela compreenso do que acontece com os sistemas (e software) ao longo do tempo. Outra concluso que o estado de manuteno um desenvolvimento continuado, exceto quando h uma entrada extra (ou constrangimento)- ou seja, quando o software nunca est concludo e continua a evoluir. Como ele evolui, ele cresce mais complexo, a menos que se tomem providncias para reduzir esta complexidade. Desde que os softwares regulares demonstram comportamento e tendncias, estes podem ser medidos. As tentativas de desenvolver modelos para estimar os esforos com a manuteno tm sido feitos, e, como resultado, instrumentos teis de gesto tm sido desenvolvidos. [Art88], (Bel72)[Art88:c1s1.0,s1.1,s1.2,c11s1.1,s1.2; Leh97:108-124],(Bel72). f) Categorias de Manuteno Lientz & Swanson inicialmente definidam trs categorias de manuteno: corretiva, adaptvel e perfectiva. [Lie78;IEEE1219-98] Esta definio foi posteriormente atualizada pela Norma para a Manuteno de Software, Engenharia de Software, ISO/IEC 14764, para incluir quatro categorias, como segue:[ Lie78; Dor02:v1c9s1.5; IEEE121998:s3.1.1,s3.1.2,s3.1.7,A.1.7; ISO1476499:s4.1,s4.3,s4.10, s4.11,s6.2; Pig97:c2s2.3] Manuteno corretiva: modificao reativa realizada aps a entrega de produtos de software para corrigir problemas detectados.

98

Manuteno

Adaptativa:

Alterao

de

um

produto

de

software

realizada aps a entrega e visa manter o software utilizvel em um produto modificado ou que fora alterando seu ambiente. Manuteno Perfectiva: Alterao de um produto de software aps a entrega, para melhorar o desempenho ou capacidade de manuteno. Manuteno Preventiva: Alterao de um produto de software aps a entrega para detectar e corrigir latente falhas no software. A ISO/IEC 14764 classifica a manuteno adaptativa e perfectiva como acessrias. Tambm rene as categorias de manuteno preventiva e corretiva na categoria de correo, conforme mostrado na Tabela 1. A manuteno preventiva, a mais nova categoria, a maior parte das vezes realizada sobre produtos de software onde a segurana crtica. 2.1.3.5.2 Problemas chave na manuteno de software Um nmero de problemas chave deve ser tratado para garantir a manuteno efetiva do software. importante entender que manuteno de software fornece desafios tcnicos e gerenciais nicos para engenheiros de software. Tentar achar uma falha em software contendo 500 mil linhas de cdigo que o engenheiro de software no desenvolveu um bom exemplo. Semelhantemente, competir com desenvolvedores de software por recursos uma batalha constante. Planejar uma verso futura enquanto se desenvolve a prxima verso e se envia atualizaes de segurana para a verso atual tambm fornece um desafio. A seo seguinte apresenta alguns problemas tcnicos e gerenciais relacionados manuteno de software. Eles tm sido agrupados como: Problemas tcnicos, Problemas gerenciais, estimativa de custo e Medidas a)Problemas tcnicos Compreenso limitada refere-se a como o engenheiro de um software, pode, rapidamente, perceber onde se deve fazer uma mudana ou uma correo no software que este indivduo no desenvolveu. Pesquisas indicam que cerca de 40% a 60% dos esforos de manuteno so dedicados ao entendimento do software a ser modificado. Assim, o tema da compreenso do software de grande interesse para os engenheiros de software.

99

compreenso

mais

difcil

na

representao

do

texto

orientador,

no cdigo-fonte, por exemplo, onde muitas vezes difcil rastrear a evoluo do software atravs das suas releases / verses quando as alteraes no so documentadas e quando os desenvolvedores no esto disponveis para explic-las, o que muitas vezes o caso. Assim, engenheiros de software podem inicialmente ter um compreenso limitada do software, e muito tem de ser feito para remediar isto. Testando. O custo da repetio de ensaios em uma grande pea de software pode ser significativo em termos de tempo e dinheiro. Regresso de testes, a seleo de uma reanlise de software ou componente para verificar se as modificaes no tenham causado efeitos no intencionais, que importante para a manuteno. Encontrar tempo para testar muitas vezes difcil. H tambm a desafio de coordenar diferentes testes quando os membros da equipe da manuteno esto trabalhando em diversos problemas ao mesmo tempo. [Plf01] Quando se executa um software com as funes crticas, pode ser impossvel traz-lo para testar offline. O Teste de Software KA fornece informaes adicionais e as referncias sobre o assunto, em seu sub-tpico 2.2.6 Regresso de testes. Estudos de impacto Dor02:v1c9s1.10; Pfl01: c11s11.5. Estudo de impacto descreve como a conduta, de forma eficaz, pode analisar completamente o impacto de uma mudana no software atual. Os mantenedores devem possuir um conhecimento aprofundado da estrutura do software e de seu contedo [Pfl01]. Eles usam esse conhecimento para realizar anlises de impacto, o que identifica todos os sistemas e produtos de software afetado por uma solicitada mudana de software, e desenvolve uma estimativa dos recursos necessrios para realizar a mudana. [Art88] Alm disso, o risco de fazer a mudana determinado. A mudana pedida, s vezes chamada de Pedido de Modificao (MR) e, muitas vezes, requerem um relatrio problema (PR), que deve, em primeiro lugar, ser analisado e traduzido em termos de software. [Dor02] realizado aps a entrada de um pedido de mudana de software no gerenciamento de configurao processo. Arthur [Art88] afirma que os objetivos de anlise de impacto so:........................................................... Determinao do mbito de uma mudana no sentido de planejar e executar trabalhos; Desenvolvimento de estimativas precisas dos recursos necessrios para executar o trabalho;

100

Anlise dos custos/benefcios das alteraes solicitadas; Comunicao a terceiro da complexidade de uma dada mudana A gravidade de um problema frequentemente utilizada para decidir como e

quando um problema ser corrigido. O engenheiro de software, ento, identifica os componentes afetados. Vrias solues potenciais so apresentadas, e, em seguida, feita uma recomendao quanto ao melhor curso de ao. O Software projetado com a manuteno em mente facilita e muito a avaliao de impacto. Mais informaes podem ser encontradas na Gerncia de Configurao de Software KA. Capacidade de Manuteno [ISO14764-99:s6.8s6.8.1; Pfl01: c9s9.4; Pig97:c16]. Como que um acompanhamento pode promover as questes da capacidade de manuteno durante o desenvolvimento? O IEEE [IEEE610.12-90] define capacidade de manuteno como a facilidade com que pode o software ser mantido, reforado, adaptado, corrigido ou satisfazer requisitos especificados. ISO/IEC define capacidade de manuteno como uma caracterstica de qualidade (ISO9126-01). As subcaractersticas da capacidade de manuteno devem ser especificadas, revista, e controladas durante o desenvolvimento das atividades de software, a fim de reduzir os custos de manuteno. Se for feito com xito, a manuteno do software ir melhorar. Isso muitas vezes difcil de ser concretizado, porque as caractersticas da capacidade de manuteno no so um importante foco durante o processo de desenvolvimento de software. Os desenvolvedores esto preocupados com muitas outras coisas e frequentemente ignoram as exigncias do mantenedor. Este fato, por sua vez, pode, e muitas vezes o faz, resultar em uma falta de documentao do sistema, o que uma das principais causas das dificuldades no programa de compreenso e avaliao do impacto. Tambm tem foi observado que a presena de sistemas, de processos maduros, tcnicas e ferramentas ajudam a reforar a manuteno de um sistema. Estudos de impacto Dor02:v1c9s1.10; Pfl01: c11s11.5. Estudo de impacto descreve como a conduta, de forma eficaz, pode analisar completamente o impacto de uma mudana no software atual. Os mantenedores devem possuir um conhecimento aprofundado da estrutura do software e de seu contedo [Pfl01]. Eles usam esse conhecimento para realizar anlises de impacto, o que identifica todos os sistemas e produtos de software afetado por uma solicitada mudana de software, e desenvolve uma estimativa dos recursos necessrios para realizar a mudana.

101

[Art88] Alm disso, o risco de fazer a mudana determinado. A mudana pedida, s vezes chamada de Pedido de Modificao (MR) e, muitas vezes, requerem um relatrio problema (PR), que deve, em primeiro lugar, ser analisado e traduzido em termos de software. [Dor02] realizado aps a entrada de um pedido de mudana de software no gerenciamento de configurao processo. Arthur [Art88] afirma que os objetivos de anlise de impacto so: Determinao Desenvolvimento do mbito de de uma mudana precisas no dos sentido de planejar e executar trabalhos estimativas recursos necessrios para executar o trabalho Anlise dos custos/benefcios das alteraes solicitadas Comunicao a terceiro da complexidade de uma dada mudana A gravidade de um problema frequentemente utilizada para decidir como e quando um problema ser corrigido. O engenheiro de software, ento,identifica os componentes afetados. Vrias solues potenciais so apresentadas, e, em seguida, feita uma recomendao quanto ao melhor curso de ao. O Software projetado com a manuteno em mente facilita e muito a avaliao de impacto. Mais informaes podem ser encontradas na Gerncia de Configurao de Software KA. Manutenibilidade [ISO14764-99:s6.8s6.8.1; Pfl01: c9s9.4; Pig97:c16]. Como que um acompanhamento pode promover as questes de manutenibilidade durante o desenvolvimento? O IEEE [IEEE610.12-90] define manutenibilidade como a facilidade com que pode o software ser mantido, reforado, adaptado, corrigido ou satisfazer uma requisitos especificados. de qualidade ISO/IEC define As manutenibilidade como da caracterstica (ISO9126-01). subcaractersticas

manutenibilidade devem ser especificadas, revista, e controladas durante o desenvolvimento das atividades de software, a fim de reduzir os custos de manuteno. Se for feito com xito, a manuteno do software ir melhorar. Isso muitas vezes difcil no de so ser um concretizado, importante porque foco as caractersticas o processo da de manutenibilidade durante

desenvolvimento de software. Os desenvolvedores esto preocupados com muitas outras coisas e frequentemente ignoram as exigncias do mantenedor. Este fato, por sua vez, pode,

102

e muitas vezes o faz, resultar em uma falta de documentao do sistema, o que uma das principais causas das dificuldades no programa de compreenso e avaliao do impacto. Tambm tem foi observado que a presena de sistemas, de processos maduros, tcnicas e ferramentas ajudam a reforar a manuteno de um sistema. b) Gesto de Problemas Alinhamento com os objetivos organizacionais [Ben00: c6sa; Dor02: v1c9s1.6]. Os objetivos organizacionais descrevem a forma de demonstrar o retorno sobre os investimentos das atividades de manuteno de software. Bennett [Ben00] afirma que " o objetivo normalmente desenvolver software baseados em projetos, com uma escala definida no tempo e oramento. O principal destaque a entrega a tempo e dentro do oramento para satisfazer as necessidades do utilizador. Em contrapartida, a manuteno de software frequentemente tem o objetivo de estender a vida de um software para o maior tempo quanto possvel. Alm disso, pode ser motivado pela procuro de utilizador por atualizaes de software e acessrios. Em ambos os casos, o retorno sobre o investimento no claro, de modo que a viso a nvel da direo muitas vezes uma das principais atividades que consomem recursos significativos, sem benefcios quantificveis claros para a organizao." Pessoalidade [Dek92 :10-17; Dor02: v1c9s1.6; Par86: c4s8-c4s11] (Lie81). Pessoalidade refere-se a forma de atrair e manter software o pessoal da manuteno. Manuteno no frequentemente visto como um trabalho glamoroso. Deklava fornece uma lista de problemas com os recursos humanos relacionados com a base em levantamento de dados. [Dek92] Como resultado, o pessoal da manuteno de software so frequentemente vistos como "Cidados de segunda classe" (Lie81), com a moral prejudicada. Processo [Pau93; Ben00: c6sb; Dor02: v1c9s1.3]. O processo de Software um conjunto de atividades, mtodos, prticas e transformaes que as pessoas usam para desenvolver e manter o software e produtos associados. [Pau93] Pelo nvel do processo, algumas atividades de manuteno so comuns as do desenvolvimento de software (por exemplo, gerncia de configurao de software uma atividade crucial para ambos). [Ben00] A Manuteno exige tambm vrias

103

atividades que no so encontrados no desenvolvimento de software. Essas atividades apresentam desafios para a gesto. [Dor02] Aspectos organizacionais da manuteno [Pfl01: c12s12.1-c12s12.3; Par86: c4s7; Pig97: c2s2.5; Tak97: C8]. Os aspectos organizacionais descrevem a forma de identificar manuteno qual de organizao e/ou funo que ser o responsvel software pela no software. A equipe desenvolve

necessariamente atribuda a manter o software quando este estiver operacional. Para decidir onde ir funcionar a manuteno de software, as organizaes de engenharia de software podem, por exemplo, permanecer com o desenvolvedor original ou ir a uma equipe separada (ou mantenedores). Muitas vezes, a opo mantenedor escolhida de modo a garantir que o software funcione adequadamente e evolua para satisfazer necessidades evolutivas dos utilizadores. Uma vez que h muitos prs e os contras de cada uma destas opes [Par86,Pig97], a deciso deve ser feita com base em cada caso. O importante a delegao ou cesso da responsabilidade pela manuteno a uma nica pessoa ou grupo [Pig97], independentemente da estrutura da organizao. Terceirizao [Dor02: v1c9s1.7; Pig97: c9s9.1, s9.2], (Car94; McC02) As indstrias terceirizadas esto a tornar-se uma grande indstria. As grandes corporaes esto terceirizando portflios inteiros de sistemas de software, incluindo a manuteno de software. Mas muitas vezes, a terceirizao uma opo selecionada de forma no absoluta, por empresas que no esto dispostas a perder o controle do software usado no seu core business. Carey (Car94) relata que alguns iro terceirizar apenas se poderem encontrar maneiras da manuteno de controle estratgico. No entanto, as medidas de controle so difceis de encontrar. Um dos grandes desafios para os terceirizados determinar o alcance dos servios de manuteno necessrios e os detalhes contratuais. McCracken (McC02) afirma que 50% dos terceirizados prestam servios sem qualquer acordo claro de nvel de servio. As empresas de terceirizao geralmente gastam muitos meses para avaliar o software que ir entrar em um relao contratual, antes de concretiz-la. [Dor02] Outro desafio identificado a transio do software para o contratante. [Pig97] c) Estimao do Custo de manuteno Engenheiros de software deve compreender as diferentes categorias de

104

manuteno de software, acima discutidas, a fim de abordar a questo da avaliao do custo da manuteno de software. Para fins de planejamento, calcular custos um aspecto importante de manuteno de software. Estimao de Custo [Art88: c3; Boe81: C30; Jon98: C27; Pfl01: c11s11.3; Pig97: C8]. Foi mencionado, anlise de impacto, que a avaliao de impacto identifica todos os sistemas e produtos de software afetados por uma mudana de software e desenvolve um pedido de estimativa dos recursos necessrios para realizar essa mudana. [Art88] As estimativas dos custos de manuteno so afetadas por muitos fatores tcnicos e no tcnicos. ISO/IEC14764 afirma que "as duas abordagens mais populares para estimar os recursos para manuteno de software so o uso de modelos paramtricos e a utilizao da experincia "[ISO14764-99: s7.4.1]. Na maior parte das vezes, usada a combinao de ambas. Modelos paramtricos [Ben00: S7; Boe81: C30; Jon98: C27; Pfl01: c11s11.3] Alguns trabalhos foram realizados na aplicao paramtrica para a modelagem do custo de manuteno de software. [Boe81, Ben00] necessrio frisar que os dados dos ltimos projetos so necessrios em a fim de se utilizar os modelos. Jones [Jon98] discute todos os aspectos de estimar os custos, incluindo os pontos das funes (IEEE14143.1-00), e oferece um detalhado captulo sobre a estimao da manuteno. Experincia [ISO14764-00: S7, s7.2, s7.2.1, s7.2.4; Pig97: C8; Sta94]. A experincia, na forma de perito acrdo (usando a tcnica Delphi, por exemplo) e analogias, um trabalho de desagregao que aborda a estrutura que deveria ser utilizada para aumentar os dados de modelos paramtrico. Claramente, a melhor abordagem para a estimativa da manuteno combinar dados empricos e experincia. Estes dados devero ser fornecidos como resultado de um programa de medio. d) Medio da Manuteno de Software Grady e Caswell [Gra87] discutem a instituio de um programa para as grandes empresas para a medio da manuteno de software, onde formulrios e dados coletados so descritos. O Sistema de Medio (PSM) um software prtico que descreve um projeto issuedriven processo de medio que utilizado por muitas organizaes e bastante prtico. [McG01] Os softwares possuem medidas que so

105

comuns a todos os empreendimentos, sendo que o Engineering Institute (SEI) tem identificadas as seguintes categorias de Software: tamanho; esforo; cronograma; e qualidade. [Pig97]m Estas medidas constituem um bom ponto de partida para o mantenedor. A discusso sobre o processo e o produto da medio apresentada no Software Engineering Process KA. O programa descrito na medio do Software Engenharia de Gesto KA. Medidas Especficas IEEE1219-98:Table3; Sta94:p239-249. Abran [Abr93] apresenta tcnicas de benchmarking para comparar as diferentes organizaes da manuteno interna. O mantenedor deve determinar quais so as medidas adequadas para a organizao em questo. [IEEE1219 - 98; ISO9126-01; Sta94] sugere medidas que sejam mais especficas para os programas de medio da manuteno de software. Esta lista inclui uma srie de medidas para cada uma das quatro subcaractersticas de durabilidade: Analisativas: Medidas do esforo do mantenedor ou recursos gastos na tentativa de diagnosticar deficincias ou causas de insucesso, ou na identificao de peas a serem modificadas. Inconstncia: Medidas do mantenedor do esforo associados implementao de uma determinada modificao. Estabilidade: Medidas do comportamento inesperado do software, incluindo a que surgir durante o ensaio. Testabilidade: Medidas do esforo do mantenedor e usurio para tentar testar o software modificado. Algumas medidas de manuteno do software podem ser obtidas utilizando ferramentas comerciais disponveis. (Lag96; Apr00)[IEEE1061-98:A.2; Pig97:c14s14.6; Gra87 ; Tak97: c6s6.1-c6s6.3] 2.1.3.5.3 Processo de manuteno O Processo de Manuteno fornece referncias de subzona de padres utilizados para implementar o processo de manuteno de software. Atividades de Manuteno diferencia o tpico Desenvolvimento da manuteno e mostra a relao da engenharia de software para outras atividades. A necessidade da engenharia de software um processo bem documentado. Os modelos CMMI se aplicam aos processos de manuteno de

106

software, e so semelhantes aos processos de desenvolvimento. [SEI01] Manuteno de Software Capability Maturity descreve os nicos processos de manuteno de software (Apr03, Nie02, Kaj01). a) Processos de Manuteno O processo de manuteno fornece atividades necessrias, detalhando as entradas/sadas para essas atividades, e so descritas na Manuteno em software IEEE 1219 e nas normas ISO/IEC 14764. O modelo de processo de manuteno descrito no Standard Manuteno de Software (IEEE1219) inicia-se com o esforo de manuteno de software durante a fase ps-entrega e aborda itens como planejamento para manuteno. Aquele processo ilustrado na Figura 20.

Figura 20: Atividades do Processo de Manuteno

A ISO/IEC 14764 [ISO14764-99] um aprofundamento do processo de manuteno IEEE/EIA 12207.0-96. As atividades de manuteno da ISO/IEC um processo semelhante dos do IEEE, com a diferena de serem agregadas um pouco diferente. As atividades desenvolvidas no processo de manuteno pela ISO / IEC so mostradas na Figura 21.

107

Figura 21: Processo de Manuteno de Software

Cada uma das atividades primrias de manuteno de software das ISO/IEC 14764 subdividida em tarefas, como se segue: Processo de Execuo Problema e Anlise da Modificao Execuo da Modificao Reviso da Manuteno / Aceitao Migraes Aposentadoria do Software Grubb & Takang [Tak97] fornecem um histrico de modelos de processos de manuteno conducentes aos modelos de processos de desenvolvimento do IEEE e ISO/IEC. Parikh [Par86] tambm d uma boa viso geral de um processo genrico de manuteno. Recentemente, metodologias geis foram criadas e promoveram a eficincia dos processos. Essa exigncia decorre do da procura por fast turn-around de manuteno de servios. Alguns experimentos com manuteno so apresentados em Extreme (Poo01).

108

b) Atividades de Manuteno Como j foi dito, muitas atividades de manuteno so semelhantes com as de desenvolvimento de software. Os mantenedores executam anlise, projeto, codificao, testes e documentao. Estes requisitos devem monitorar suas atividades como feito no desenvolvimento, atualizao a documentao como base na alterao. ISO/IEC14764 recomenda que, quando um mantenedor refere-se a um processo de desenvolvimento semelhante, ele tem que adapt-lo para satisfazer suas necessidades especficas [ISO14764-99: s8.3.2.1, 2]. No entanto, para a manuteno de software, algumas atividades envolvem processos de software exclusivos para a manuteno. Atividades nicas Dor02:v1c9s1.9.1; IEEE1219-98:s4.1,s4.2; ISO14764 99:s8.2.2.1,s8.3.2.1;Pfl01:c11s11.2. H uma srie de processos, atividades e prticas que so exclusivas da manuteno de software, como por exemplo:

Transio: uma sequncia de atividades coordenadas e controladas onde o software transferido progressivamente a partir do desenvolvedor para o mantenedor [Dek92, Pig97] Aceitao / Recusa do Pedido de Modificao: o pedido de modificao, por ter certo tamanho/esforo/complexidade, pode ser rejeitado pelo mantenedor e reencaminhado para um desenvolvedor [Dor02], (Apr01) Requisio de modificao e sua solicitao ao Help Desk: uma funo de apoio aos usurios finais, o que desencadeia avaliao, priorizao, e custeio do pedido de modificao [Ben00] Anlise do impacto (ver ponto 2.1.3 para mais detalhes) Suporte de Software: ajuda e aconselhamento ao usurio relativo a um pedido de informao (por exemplo, regras empresariais, a validao de dados, significado e pedidos ad-hoc/reports) (Apr03)

Acordos de nvel de servio (SLAs) especificam que o domnio dos contratos de manuteno de responsabilidade dos mantenedores (Apr01), As atividades de apoio [IEEE1219-98:A.7,A.11; IEEE12207.0-96:c6,c7;ITI01;

Pig97:c10s10.2,c18] ;(Kaj01). Os mantenedores podem tambm realizar atividades de apoio, tais como planejamento da manuteno de software, gesto da configurao de software, verificao e validao, garantia da qualidade de software, revises e auditorias, treinamento ao usurio. Outra atividade de apoio do

109

mantenedor, a formao, tambm necessria. [Pig97; IEEE12207.0-96] (Kaj01) Atividades de Planejamento da Manuteno [IEEE1219-98: A.3; ISO1476499: S7; ITI01; Pig97: C7, C8]. Uma atividade importante para a manuteno de software o planejamento, e os mantenedores devem resolver as questes relacionadas com o planejamento com uma serie de perspectivas: Planejamento do negcio (nvel organizacional) Planejamento da Manuteno (nvel de transio) Planejamento da Release/verso (nvel de software) Pedido individual de um processo de mudana de (nvel solicitao). No nvel individual, o planejamento realizado durante a anlise de impacto. A atividade de planejamento da release/verso exige que o mantenedor [ITI01]: Colher as datas de disponibilidade dos pedidos individuais; Concorde com os usurios sobre o contedo das subsequentes releases/verses. Identifique conflitos potenciais e crie alternativas para san-los. Avalie os riscos de uma determinada entrega e desenvolva um plano de back-out no caso de problemas surgirem. Informar todas as partes interessadas Considerando que o desenvolvimento de projetos de software geralmente pode passar de alguns meses para um nmero reduzido de anos, a fase de manuteno geralmente dura muitos anos. Fazer a previso de recursos um elemento fundamental do planejamento de manuteno. Esses recursos devem ser includos nos oramentos do planejamento dos projetos dos desenvolvedores. O planejamento da manuteno de Software deve comear com a deciso de desenvolver um novo sistema, e dever considerar objetivos de qualidade (IEEE1061-98). Um conceito de documento dever ser desenvolvido, seguido de um plano de manuteno. O conceito de documento de manuteno [ISO14764 - 99: s7.2] deve abordar: O mbito da manuteno de software Adaptao do processo de manuteno de software Identificao da organizao de manuteno do software Uma estimativa dos custos de manuteno de software

110

O prximo passo desenvolver um software correspondente ao plano de manuteno. Este plano dever ser elaborado durante o desenvolvimento de software, e deve especificar como os usurios iro solicitar as modificaes ou relatar os problemas de software. O planejamento da manuteno de Software de [Pig97] abordado no IEEE 1219 [IEEE1219-98] e ISO/IEC 14764. [ISO14764-99] ISO/IEC14764 fornece diretrizes para um plano de manuteno. Por fim, ao mais alto nvel, a organizao da manuteno ter de realizar atividades de planejamento empresarial (oramental, financeira e recursos humanos), tal como todas as outras divises da organizao. A gesto de conhecimentos necessrios para o fazer pode ser encontrada nas Disciplinas de Engenharia de Software Relacionadas ao final do captulo. Gerenciamento de configurao de Software [Art88:c2,c10; IEEE121998:A.11; IEEE12207.0-96:s6.2; Pfl01:c11s11.5; Tak97:c7]. O padro IEEE para Manuteno de Software, IEEE 1219 [IEEE1219-98], descreve a gesto da configurao de software como um elemento crtico do processo de manuteno. Os procedimentos de gerenciamento de configurao do Software devero prever a verificao, validao, e auditoria de cada passo necessrio para identificar, autorizar, executar, e liberar os produtos de software. Ele no suficiente simplesmente para monitorar a Modificao ou os Pedidos de relatrios dos problemas. O produto de software e quaisquer mudanas feitas a ele tm de ser controladas. Este controle estabelecido pela implementao e aplicao um programa aprovado de gerenciamento de processo de configurao (SCM). O Software Configuration Management KA fornece detalhes de SCM e discute o processo pelo qual os pedidos de mudana de software sejam apresentados, avaliados e aprovados. O processo de SCM para manuteno de software diferente do processo SCM para desenvolvimento de software, quanto ao nmero de pequenas mudanas que devem ser controladas no software operacional. O processo SCM implementado atravs do desenvolvimento de um plano de gesto e procedimentos operacionais. Os mantenedores devem participar da configurao das cmaras de controle e determinar o contedo dos prximos release/verses. Qualidade de software IEEE12207.0-96:s6.3; IEEE1219-98:A.7; ISO1476499:s5.5.3.2. No suficiente quer o simples aumento da esperana de aumentar a

111

qualidade ir resultar na qualidade resultaro da manuteno de software. Ela deve ser planejada e implementada para apoiar os processos processo de manuteno. As atividades e tcnicas de Segurana de Qualidade de (SQA), V & V, opinies, e auditorias devem ser selecionadas em consonncia com todos os outros processos para alcanar o nvel desejado de qualidade. tambm recomendado que os mantenedores adaptem os processos de desenvolvimento, tcnicas e resultados, para instituir testes de documentao, e testes de resultados. [ISO14764-99] Mais detalhes podem ser encontrados no Quality Software KA. 2.1.3.5.4 Tcnicas de Manuteno Este subitem introduz alguns dos mtodos geralmente aceitos pelas tcnicas utilizadas na manuteno de software. a) Programa de Compreenso Os programadores gastam um tempo considervel na leitura e compreenso dos programas, a fim de implementar mudanas. Os Cdigos Navegadores so instrumentos fundamentais para a compreenso do programa. A documentao clara e concisa pode auxiliar no processo de compreenso do programa. [Arn92: C14; Dor02: v1c9s1.11.4; Tak97: c3] b) Reengenharia Reengenharia definida como a anlise e alterao de software para reconstitu-lo em um novo formulrio, e inclui a posterior aplicao do novo formulrio. Dorfman e Thayer [Dor02] indicam que a reengenharia o mais radical (e caro) formulrio de alterao. Outros entendem que a reengenharia pode ser usada para pequenas alteraes. Ela, muitas vezes, no compromete-se a melhorar a durabilidade, mas a substituir o envelhecido legado de software. Arnold [Arn92] prev um compndio abrangente de temas, como por exemplo: conceitos, ferramentas e tcnicas, estudos de caso, e os riscos e benefcios associados reengenharia.[Arn92: C1, C3-C6; Dor02: v1c9s1.11.4; IEEE1219-98: B.2], (Fow99) c) Engenharia reversa Engenharia reversa o processo de anlise de software que identifica os

112

componentes do software e suas inter-relaes para criar representaes do software sob outra forma ou em nveis mais elevados de abstrao. A Engenharia Reversa passiva, ela no muda o software, ou resultar em novos softwares. Ela produzir esforos chamados grafos e grficos de controle de fluxo para achar o cdigo. Um tipo de engenharia reversa a redocumentao. Outro tipo a recuperao de design [Dor02]. Refactoring um programa de transformao, que reorganiza um programa sem modificar o seu comportamento, e uma forma de engenharia reversa que visa melhorar a estrutura do programa. (Fow99) Finalmente, os dados de engenharia reversa tm ganhado importncia ao longo dos ltimos anos, onde schemas lgicos foram recuperados fsicos a partir de bases de dados. (Hen01)[Arn92: c12; Dor02: v1c9s1.11.3; IEEE1219-98: B.3; Tak97: c4, Hen01] 2.1.3.6 Gerncia de Configurao de Software Um sistema pode ser definido com uma conjunto de componentes organizados para realizar uma funo especifica ou um conjunto de funes (IEEE 610.12-90). A configurao de um sistema consiste das caractersticas funcionais e/ou fsicas de hardware, firmware, ou software ou a combinao destas, conforme estabelecida na documentao tcnica e realizao de um produto. Ela tambm pode ser pensada como uma coleo de verses especficas de hardware, firmware, software ou itens combinados de acordo com procedimentos de construo especficos para servir um propsito particular. Gerenciamento de Configurao (CM), ento, a disciplina de identificao e configurao de um sistema em pontos distintos no tempo com a finalidade de controlar sistematicamente as alteraes na configurao, e manuteno da integridade e da rastreabilidade da configurao durante todo o ciclo de vida do sistema (Ber97) formalmente definido (IEEE610.12-90) como Uma disciplina aplicando tcnicas e administrando direo e fiscalizao para: identificar e documentar as caractersticas funcionais e fsicas de uma configurao de item, controle de mudanas para estas caractersticas, gravando e relatando mudanas processando e implementando status, e verificando conformidade com especificao de requisitos. Gerncia de Configurao de Software (SCM) da suporte ao ao processo de ciclo de vida do software (IEEE23307.096) beneficiando o gerenciamento de projeto, as atividades de desenvolvimento e manuteno,

113

atividades de garantia, e a cliente e usurios do produto final. O conceito de gerncia de configurao aplica a todos os itens a serem controlados, embora existam algumas diferenas na implementao entre gerncia de configurao de hardware e gerncia de configurao de software. SCM est intimamente relacionado com a atividade de garantia de qualidade de software (SQA). Como definido na Qualidade de Software KA, processos SQA fornecem garantia que os produtos de software e processos de ciclo de vida projeto esto em conformidade com suas especificaes de requisitos pelo planejamento, articulao, e execuo de um conjunto de atividade para fornecer confiana adequada que a qualidade est sendo construda no software. Atividades de SCM ajudam na realizao das metas de SQA. Em alguns contextos projetos (veja, por exemplo, IEEE730-02), especificam requisitos de SQA descrevendo certas atividades de SCM. As atividade de SCM so: gerncia e planejamento dos processos de SCM, identificao e configurao de software, controle configurao de software, estimar o status da configurao de software, auditoria da configurao de software, e a gesto de lanamento e entrega do software. 2.1.3.6.1 Gerenciamento dos Processos SCM SCM controla a evoluo e integridade de um produto pela identificao de seus elementos, gerenciando e controlando mudanas, e verificando, registrando e apresentao informaes sobre configurao. A partir da perspectiva do engenheiro de software, SCM facilita o desenvolvimento e a implementao de atividades de mudana. Uma implementao bem sucedida de SCM requer um cuidadoso planejamento e gerenciamento. Este, por sua vez, requer um entendimento do contexto organizacional para, e as restries colocadas sobre, o design e implementao dos processos de SCM. a) Contexto Organizacional para SCM Para planear um processo de SCM para um projeto, necessrio compreender o contexto organizacional e os relacionamentos entre os elementos organizacionais. SCM interage com vrias outras atividades ou elementos organizacionais. Os elementos organizacionais responsveis pelo apoio aos

114

processos de engenharia de software podem ser estruturados de vrias maneiras. Embora a responsabilidade de realizar certas tarefas SCM pode ser designada para outras partes da organizao, como a organizao de desenvolvimento, a responsabilidade global pelo SCM muitas vezes recai em um distinto elemento organizacional ou individuo designado. Software frequentemente desenvolvido como parte de um sistema maior que contenham elementos de hardware e firmware. Neste caso, atividades SCM tm lugar em paralelo com atividades GC de hardware e firmware, e devem ser compatveis com o nvel de GC do sistema. Buckley [Buc96: c2] descreve SCM dentro deste contexto. Note que o firmware contm hardware e software, portanto os conceitos de GC so aplicados a ambos hardware e software. SCM pode interagir com uma organizao atividade garantia de qualidade em questes tais como gerenciamento de registros e itens em no conformidade Em relao ao anterior, alguns itens sob controle SCM podem tambm ser registros de projeto sujeito ao fornecimento garantia de qualidade do programa da organizao. Gerenciamento itens sem conformidade geralmente da responsabilidade da atividade de garantia de qualidade, entretanto, SCM pode ajudar com monitoramento e relatrios sobre configurao de software itens que se inserem nesta categoria. Talvez a mais estreita relao com desenvolvimento e manuteno de software nas organizaes. neste contexto que muitas tarefas de controle e configurao do software so executadas. Muitas vezes, as mesmas ferramentas apoiam o desenvolvimento, manuteno, propsitos de SCM.[Ber92 :c4; Dar90:c2; IEEE828-98:c4s2.1] b)Limitaes e orientaes para o processo de SCM As restries e orientaes para o processo de SCM provm de vrias de fontes. Polticas e procedimentos organizacionais podem influenciar a concepo e implementao dos processo de SCM para um determinado projeto. Alm disso, contratos entre o compradores e o fornecedores podem conter disposies que afetam o processo de SCM. Por exemplo, a configurao de algumas auditorias poderia ser necessria, ou poderia especificar que certos itens sejam colocados sob CM. Quando os produtos de software a ser desenvolvidos tm o potencial de afetar a segurana pblica, entidades reguladoras podem impor restries externas (ver, por exemplo, USNRC1.169-97). Finalmente, o ciclo de vida de software escolhido

115

para um processo de software e as ferramentas de projeto selecionadas para executar o software afetam a concepo e implementao do processo de SCM. [Ber92] Orientao para o desenvolvimento e a implementao de um processo de SCM pode tambm ser obtido a partir de "melhores prticas", o que se refletiu em normas da engenharia de software emitidas por diferentes organizaes de padronizao. Moore [Moo98] fornece um roteiro para estas organizaes e as suas normas. As melhores prticas tambm se reflete na melhoria dos processos e modelos de processo de avaliao, tais como o Software Engineering Institutes Capability Maturity Model Integration (SEI / CMMI) (SEI01) e ISO/IEC15504 Software Engineering Process-Avaliao (ISO / IEC 15504-98). IEEE828-98:c4s1,c4s2.3; Moo98 c) Planejamento para SCM O planejamento de um processo de SCM para um determinado projeto deve ser coerente com o contexto organizacional, respeitar as restries e seguir as orientaes e a natureza do projeto (por exemplo, o tamanho e criticidade). As principais atividades abrangidas so: Identificao e Configurao de Software, Controle de Configurao de Software, Contagem de Status de Configurao de Software, Audio da Configurao de Software, e Gerenciamento de Release e Entrega do. Alm disso, questes como a organizao e as responsabilidades, recursos e cronogramas, seleo e utilizao de ferramenta, controle de fornecedores e subcontratados, e controle de interface so normalmente considerados. Os resultados do planejamento das atividades so gravados em um Plano de SCM (SCMP), que normalmente est sujeitos a reviso e auditoria da SQA. Para evitar confuso sobre quem ir realizar determinada atividade ou tarefas de SCM, as organizaes envolvidas no processo de SCM precisam ser claramente identificadas. Responsabilidades especficas para determinadas atividades ou tarefas de SCM tambm precisam ser atribudas a entidades organizacionais, quer pelo ttulo ou pelo elemento organizacional. A autoridade global e relatrios de critrios para SCM tambm devem ser identificados, embora isto possa ser realizado no gerenciamento de projetos ou na fase de Planejamento da Garantia da

116

Qualidade. O planejamento para SCM identifica os funcionrios e as ferramentas envolvidas na realizao de atividades e tarefas de SCM. Aborda questes da programao, estabelecendo as sequncias necessrias para a criao de tarefas de SCM e identificao das suas relaes com os cronogramas do projeto e das metas estabelecidas na fase de gerenciamento de planejamento do projeto. Qualquer requerimento de treinamento necessrio para a implementao dos planos e programas de formao para novos funcionrios tambm so especificados. Diferentes tipos de ferramenta de capacidades, e os procedimentos para a sua utilizao, so apoiados pelas atividades de SCM. Dependendo da situao, a capacidade destas ferramentas podem ser disponibilizadas com alguma combinao de ferramentas manuais, ferramentas automatizadas proporcionando uma capacidade nica de SCM, ferramentas automatizadas integrando uma srie de SCM (e talvez outras) capacidades, ou ferramenta integrada para os ambientes que servem as necessidades dos vrios participantes no processo de engenharia de software (por exemplo, SCM, o desenvolvimento, V & V). Ferramenta automatizada torna-se o apoio cada vez mais importante e cada vez mais difcil de estabelecer, como projetos que crescem em tamanho e como ambientes projetos se tornam mais complexos. Estas capacidades das ferramentas fornecer apoio para: A Biblioteca do SCM O pedido de mudana no software (SCR) e procedimentos de aprovao Cdigo (e produtos relacionados com o trabalho) e mudana das tarefas de gerenciamento Relato de Status Configurao de Software e coleo de mtricas de SCM Auditoria e Configurao de Software Gerenciamento e monitoramento da documentao de software Performance da construo do software Gerenciamento monitoramento da verses de software e da sua entrega As ferramentas utilizadas nessas reas tambm podem fornecer mtricas para o processo de melhoria. Royce [Roy98] descreve sete medidas fundamentais de valor no gerenciamento dos processos de engenharia de software. Informaes disponveis, a partir das diversas ferramentas de SCM, refere-se Royce ao trabalho e progresso de indicadores de gerenciamento e sua qualidade de indicadores de

117

mudana de Trfico e estabilidade, a Quebra e Modularidade, Retrabalho e Adaptabilidade, e MTBF (tempo mdio entre falhas) e maturidade. Elaborao de relatrios sobre estes indicadores podem ser organizados de vrias maneiras, por exemplo, item configurao de software ou pelo tipo de alterao solicitada. Outras ferramentas podem fornecer dados e relatrios de gerenciamento de capacidades para o gerenciamento do desenvolvimento, e atividades de garantia de qualidade. Como foi acima referido, a capacidade dos diversos tipos de ferramenta pode ser integrada com sistemas de SCM, o qual, por sua vez, est intimamente ligado s vrias atividades de outros softwares. No planejamento, engenharia de software SCM seleciona ferramentas adequadas para o trabalho. Planejamento considera questes que possam surgir na implementao destas ferramentas, especialmente se algum tipo de cultura necessrio que mudar. Uma viso geral dos sistemas de SCM e de seleo das consideraes dada em [Dar90: C3, apare], e um estudo de caso sobre a seleo de um sistema de SCM dada em [Mid97]. As informaes complementares sobre ferramentas SCM podem ser encontradas em Engenharia de Software Ferramentas e Mtodos KA. Um projeto de software pode adquirir ou utilizar a aquisio de produtos de software, tais como compiladores e outras ferramentas. SCM considera o planejamento e como estes itens sero adquiridas sob o controle de configurao (por exemplo, integrao das bibliotecas no projeto) e como mudanas e atualizaes sero avaliadas e gerenciadas. Consideraes semelhantes aplicam-se terceirizao de software. Neste caso, os requisitos SCM devem ser impostos ao subcontratante da SCM, como parte do processo de terceirizao e os meios de controlar o cumprimento, tambm so necessrios para ser estabelecido. Este ltimo inclui a considerao de que informaes de SCM devem estar disponveis para o cumprimento da monitorao efetiva Quando um item de software ir interagir com outros itens de hardwares ou softwares, uma mudana em qualquer item pode afetar outros. O planejamento para SCM considera o processo de como os itens de interface sero identificados e como as mudanas para os itens sero gerenciadas e comunicadas. O papel SCM pode fazer parte de um maior, processo de nveis de sistema para especificao de

118

interface e controle, e podem incluir especificaes da interface, planos de controle de interfaces, documentos de controle de interfaces. Nesse caso, planejamento SCM para controle de interface tem lugar no contexto do nvel de sistema do processo. A discusso da performance das atividades do controle de interface dada em [Ber92: C12]. IEEE 12207.0-96 :c6.s2.1; Som01:c29 d) Plano SCM Os resultados do planejamento SCM para um determinado projeto so gravados em um plano de gerenciamento de configurao de software (SCMP), um "documento vivo" que serve de referncia para o processo de SCM. Ele mantido (isto , atualizado e aprovado), conforme necessrio durante o ciclo de vida do software. Na implementao do SCMP, normalmente necessrio desenvolver uma srie de definio mais detalhada dos procedimentos para a subordinao de forma especfica os requisitos que sero realizados durante as atividades do dia-adia. Orientao sobre a criao e a manuteno de um SCMP, com base nas informaes produzidas pelas atividades de planejamento, est disponvel a partir de uma variedade de fontes, tais como [IEEE828-98: c4]. Esta referncia estabelece requisitos de informao a ser includa em uma SCMP. Tambm define e descreve seis categorias de SCM informaes a serem includas em um SCMP: Buc96:c3; Pau93:L2-81 Introduo (objetivos, escopo, termos usados) Gerenciamento de SCM (organizao, responsabilidades, autoridades, polticas aplicadas, diretrizes e procedimentos) Atividades de SCM (identificao da configurao, controle de configurao, e assim por diante) Cronograma de SCM (coordenao com as outras atividades do projeto) Recursos de SCM (ferramentas, recursos fsicos e humanos) Manuteno de SCMP

e) Monitoramento do Gerenciamento de configurao de software Depois que o processo de SCM implementado necessrio certo grau de monitoramento para garantir que as disposies do SCMP sejam corretamente

119

executadas (veja, por exemplo, [Buc96]). provvel que existam requisitos especficos de SQA para garantir o cumprimento de processos e procedimentos especificados no SCM. Isto poderia envolver uma autoridade de SCM garantindo que as pessoas com responsabilidades atribudas desempenhem corretamente as tarefas definidas no SCM. A autoridade da garantia da qualidade de software, como parte de uma atividade de auditoria e observncia, poderia tambm desempenhar esse monitoramento. O uso de ferramentas SCM integrado com capacidade para processar o controle pode tornar a tarefa mais fcil controlar. Algumas ferramentas para facilitar o cumprimento de transformao ao mesmo tempo proporcionar flexibilidade para o engenheiro de software para adaptar os procedimentos. Outras ferramentas para implementar o processo, deixando o engenheiro de software com menos flexibilidade. Acompanhamento e exigncias ao nvel da flexibilidade de ser fornecido a um engenheiro de software so consideraes importantes na ferramenta de seleo. SCM medidas podem ser projetadas para fornecer informaes especficas sobre a evoluo do produto, ou fornecer informaes sobre o funcionamento dos processos de SCM. Um dos objetivos de acompanhar os processos de SCM descobrir as oportunidades para melhoria dos processos. Medies dos processos de SCM fornecem um bom meio para monitorar a eficcia das atividades de SCM de forma continua. Essas medies so teis para caracterizar o estado atual do processo, bem como fornecer uma base para comparaes ao longo do tempo. Anlises das medies podem produzir conhecimento importante para mudanas e atualizaes correspondentes ao SCMP. Bibliotecas de software e as diversas ferramentas de capacidades do SCM fornecem as fontes para extrair informaes sobre as caractersticas do processo de SCM (bem como, dispor de projetos e gerenciamento da informao). Por exemplo, informaes sobre o tempo necessrio para executar diversos tipos de mudanas seriam teis numa avaliao dos critrios para determinar quais so os nveis de autoridade so timas para autorizar certos tipos de mudanas. Cuidados devem ser tomados para manter o foco no monitoramento sobre os conhecimentos que podem ser derivados a partir das medies, no sobre as medies em si. Discusso de medio do processo e do produto apresentado no

120

Processo de Engenharia de Software KA. O Programa de medio de software descrito no Gerenciamento da Engenharia de Software KA. As auditorias podem ser realizadas durante o processo de engenharia de software para investigar o estado atual de elementos especficos da configurao ou para avaliar a implementao dos processos de SCM. Auditoria no processo de SCM fornece mais um mecanismo formal para o monitoramento de determinados aspectos do processo e pode ser coordenados com a funo de SQA. Veja tambm subrea 5 Auditoria configurao de Software. [Pau93:L2-87] 2.1.3.6.2 Identificao da Configurao de Software A atividade de identificao de configurao de software, identifica itens a serem controlados, estabelece esquemas de identificao para os itens e verses deles, e estabelece as tcnicas e ferramentas para serem usadas em aquisio e gerenciamento de itens controlados. Estas atividades fornecem o bsico para outras atividades SCM. a) Identificando itens a serem controlados Um primeiro passo no controle de mudanas identificar os itens de software a serem controlados. Isto envolve a compreenso da configurao de software dentro do contexto do sistema de configurao, selecionando itens de configurao de software, desenvolvendo uma estratgia para classificao dos itens de software e descrever as suas relaes e identificao das linhas de base a ser utilizado, juntamente com o procedimento para a aquisio de uma linha de base sobre os itens . Uma configurao de software o conjunto de caractersticas fsicas e funcionais de software, conforme estabelecido na documentao tcnica ou alcanado em um produto (IEEE610.12-90). Ele pode ser visto como parte de uma configurao geral do sistema. Um item de configurao de software (SCI) uma agregao de software designado para o gerenciamento de configurao e tratada como uma entidade nica no processo de SCM (IEEE610.12-90). Uma variedade de itens, alm do prprio cdigo, normalmente controlada pelo CSM. itens de software com potencial para se tornar SIC incluem planos, especificaes e documentao do projeto,

121

ensaios de materiais, ferramentas de software de cdigo-fonte e executveis, bibliotecas de cdigo, dados e dicionrios de dados, e documentao para instalao, manuteno, operao e uso de software. Seleo de stios de importncia comunitria um importante processo no qual um equilbrio deve ser alcanado entre dar visibilidade adequada para fins de controle do projeto e fornecendo um nmero razovel de itens controlados. Uma lista de critrios para a seleo SCI dada em [Ber92]. As relaes estruturais entre a SIC selecionado, e suas partes constituintes, afetam as atividades de SCM ou outras tarefas, como a construo de software ou anlise do impacto das mudanas propostas. Adequado controle dessas relaes tambm importante para apoiar a rastreabilidade. A concepo do sistema de identificao de stios de importncia comunitria devem considerar a necessidade de mapear os elementos identificados com a estrutura de software, bem como a necessidade de apoiar a evoluo dos itens de software e seus relacionamentos. Uma verso de um item de software um item especfico identificado e especificado. Ele pode ser pensado como um estado de um item em evoluo. [Con98: C3-C5] Uma reviso uma nova verso de um item que se destina a substituir a antiga verso do item. A variante uma nova verso de um item que sero adicionados configurao sem substituir a verso antiga. Uma linha de base de software um conjunto de itens de configurao de software formalmente designado e fixado em um tempo especfico durante o ciclo de vida do software. O termo tambm usado para se referir a uma verso especfica de um item de configurao de software que foi acordado. Em ambos os casos, a base s pode ser alterada atravs de procedimentos formais de controle de mudana. Uma linha de base, juntamente com todas as alteraes aprovadas para a linha de base, representa a configurao atual aprovado. Comumente bases utilizadas so as bases funcionais, atribudas, de desenvolvimento e do produto (ver, por exemplo, [Ber92]). A linha de base funcional corresponde aos requisitos do sistema so revisados. A linha de base atribudo corresponde revista especificao de requisitos de software e interface de software especificao de requisitos. A base de desenvolvimento representa a configurao de software em desenvolvimento, por vezes, selecionados durante o ciclo de vida do software. Alterar autoridade para

122

essa

linha

de

base

geralmente

cabe

principalmente

organizao

de

desenvolvimento, mas pode ser compartilhada com outras organizaes (por exemplo, SCM ou de teste). A base do produto corresponde ao produto de software entregue preenchido para integrao de sistemas. As linhas de base a ser usada para um determinado projeto, juntamente com seus associados nveis de autoridade necessrio para a aprovao da mudana, so geralmente identificadas no SCMP. Itens de configurao de software so colocados sob controle SCM em momentos diferentes, ou seja, eles so incorporados a uma base particular em um determinado ponto do ciclo de vida do software. O fato gerador a realizao de algum tipo de tarefa a aceitao formal, como uma reviso formal. A Figura 2 caracteriza o crescimento de itens de linha de base como o produto do ciclo de vida. Este valor baseado no modelo em cascata, para fins de ilustrao, os ndices usados na figura indicam as verses dos itens de evoluo. Aps a aquisio de um SCI, alteraes para o item deve ser formalmente aprovado como adequado para a SCI e a linha de base em causa, tal como definido na SCMP. Aps a aprovao, o item ser incorporado no software de base de acordo com o procedimento adequado. b) Biblioteca de Software Uma biblioteca de software um conjunto controlado de software e documentao relacionada com a inteno de auxiliar no desenvolvimento de software, uso e manuteno (IEEE610.12-90). tambm fundamental no gerenciamento de software de lanamento e entrega de atividades. Vrios tipos de bibliotecas podem ser utilizadas, cada uma correspondendo a um determinado nvel de maturidade do item de software. Por exemplo, uma biblioteca de trabalho poder apoiar codificao e uma biblioteca de apoio ao projeto poderia apoiar testes, enquanto uma biblioteca de mestre pode ser utilizado para produtos acabados. Um nvel adequado de controle de SCM (associadas de base e nvel de autoridade para a mudana) associado a cada biblioteca. Segurana, em termos de controle de acesso e as instalaes de backup, um aspecto fundamental da gesto da biblioteca. Um modelo de uma biblioteca de software descrito em [Ber92: C14]. A ferramenta usada (s) para cada biblioteca deve apoiar o controle SCM precisa dessa biblioteca, tanto em termos de SIC controlar e controlar o acesso

123

biblioteca. Ao nvel da biblioteca de trabalho, esta uma capacidade de gerenciamento de cdigo que serve os desenvolvedores, mantenedores, e SCM. focado na gesto de verses de itens de software, apoiando as atividades de vrios desenvolvedores. Em nveis mais altos de controle, o acesso mais restrito e SCM o principal usurio. Essas bibliotecas so tambm uma importante fonte de informao para a medio do trabalho e do progresso. [Bab86: c2; c5; Buc96: c4; IEEE828-98: c4s3.1; Pau93: L2-82; Som01: C29] 2.1.3.6.3 Software de controle de configurao Software de controle de configurao est preocupado com o gerenciamento de mudanas durante o ciclo de vida do software. Abrange o processo para determinar quais as mudanas a fazer, a autoridade para aprovar as mudanas, o apoio para a implementao dessas mudanas, e o conceito de desvios formais de requisitos do projeto, bem como a renncia a eles. Informaes resultantes dessas atividades til para medir o trfego de mudana e ruptura, e aspectos de retrabalho. a) Requerente, Avaliao e aprovao de alteraes de software O primeiro passo para gerir as mudanas de produtos controlados determinar quais as mudanas a fazer. O processo de solicitao de alterao de software (ver Figura 5), prev procedimentos formais para a apresentao e gravao de solicitaes de mudana, avaliando o custo potencial e o impacto de uma mudana proposta, e aceitando, modificar ou rejeitar as alteraes propostas. Os pedidos de alterao de itens de configurao de software pode ser originada por qualquer pessoa em qualquer ponto do ciclo de vida do software e pode incluir uma proposta de soluo e a prioridade solicitada. Uma fonte de solicitaes de mudana o incio de ao corretiva em resposta a relatrios de problemas. Isso fornece uma oportunidade para acompanhar os defeitos e coletar medidas de atividade se alteram por tipo de alterao. Depois de um SCR recebida, uma avaliao tcnica (tambm conhecida como anlise de impacto) realizada para determinar a extenso das modificaes que seriam necessrias caso o pedido de mudana ser aceitas. Uma boa compreenso das relaes entre software (e, possivelmente,

124

hardware) itens importante para esta tarefa. Finalmente, uma autoridade estabelecida, compatvel com a linha de base afetado, o SCI envolvidos, bem como a natureza da mudana, ir avaliar os aspectos tcnicos e gerenciais da solicitao de mudana e quer aceitar, modificar, recusar ou adiar a mudana proposta. A autoridade para aceitar ou rejeitar as alteraes propostas recai sobre uma entidade tipicamente conhecido como um controle de configurao (CCB). Em projetos menores, esta autoridade pode realmente residir com o lder ou um indivduo atribudo ao invs de uma placa multi pessoa Pode haver vrios nveis de autoridade mudar dependendo de uma variedade de critrios, tais como a criticidade do item em causa, a natureza da mudana (por exemplo, o impacto sobre o oramento e cronograma), ou o ponto atual do ciclo de vida. A composio das CCBs utilizado para um determinado sistema varie em funo desses critrios (um representante da SCM estaria sempre presente). Todos os interessados, adequadas ao nvel da CCB, esto representados. Quando o escopo da autoridade da CCB estritamente software, que conhecido como comit de controle configurao de software (SCCB). As atividades do CCB so normalmente sujeitas auditoria da qualidade de software ou de reviso. Uma solicitao de mudana efetiva de software (SCR) processo requer o uso de ferramentas de apoio e os procedimentos que vo de formulrios de papel e um procedimento documentado para uma ferramenta eletrnica para efetuar pedidos de mudana, reforando o fluxo do processo de mudana, captando as decises do CCB, e relatar processo de mudana da informao. A ligao entre essa capacidade da ferramenta e do sistema de notificao de problemas pode facilitar o acompanhamento das solues para os problemas relatados. descries de processo de mudana e as formas de apoio (informao) so dados em uma variedade de referncias, por exemplo [Ber92: c9]. b) Implementao de mudanas de software Aprovado SCRs so implementados usando os procedimentos definidos por software, em conformidade com os requisitos calendrio aplicvel. Desde que um nmero de SCRs aprovados podero ser implementadas simultaneamente, necessrio fornecer um meio para controlar quais SCRs so incorporadas em verses de software especfico e linhas de base. Como parte do encerramento do

125

processo

de

mudana, completou mudanas

podem

sofrer

auditorias

de

configurao e verificao da qualidade de software. Isto inclui assegurar que apenas as alteraes aprovadas foram feitas. O processo de solicitao de alterao descrita acima, normalmente o documento SCM (e outras) informaes de aprovao para a mudana. A implementao efetiva de uma mudana suportada pela capacidade biblioteca de ferramentas, que fornecem o gerenciamento de verses e suporte repositrio de cdigo. No mnimo, essas ferramentas fornecem recursos de controle de verso Check-In/Check-Out e associados. Ferramentas mais poderosas podem apoiar o desenvolvimento paralelo e ambientes geograficamente distribudos. Essas ferramentas podem se manifestar como separar aplicaes especializadas sob o controle de um grupo de SCM independente. Eles tambm podem aparecer como uma parte integrada do ambiente de engenharia de software. Finalmente, podem ser to elementar como um sistema rudimentar de mudana de controle equipado com um sistema operacional. c) Desvios e Dispensas As restries impostas a um esforo de engenharia de software ou com as especificaes produzidas durante as atividades de desenvolvimento podem conter disposies que no podem ser satisfeitas no ponto designado no ciclo de vida. Um desvio uma autorizao para afastar-se uma disposio prvia para o desenvolvimento do item. A renncia uma autorizao para utilizar um item, a seguir o seu desenvolvimento, que derroga a disposio de alguma forma. Nestes casos, um processo formal usado para obter a aprovao dos desvios ou isenes de, as disposies. [Ber92: C9; Buc96: c12] 2.1.3.6.4 Software de contabilidade do Status da Configurao Software de contabilidade status de configurao (SCSA) o registo e comunicao de informaes necessrias para uma gesto eficaz da configurao do software.

a) Status de Configurao de Software da Informao A atividade SCSA projetos e opera um sistema de captura e transmisso de

126

informaes necessrias como o produto do ciclo de vida. Como em qualquer sistema de informao, as informaes de status de configurao a ser gerenciado para a evoluo das configuraes devem ser identificadas, coletadas e mantidas. Vrias informaes e as medidas so necessrias para apoiar o processo de SCM e satisfazer as necessidades de status de configurao de relatrios de gesto, engenharia de software, e outras atividades relacionadas. Os tipos de informaes disponveis incluem a identificao configurao aprovada, bem como a identificao e o atual estgio de implantao das mudanas, desvios e isenes. Uma lista parcial dos elementos de informao importante dada em [Ber92: c10]. Alguma forma de apoio ferramenta automatizada necessria para realizar a coleta de dados SCSA e tarefas de comunicao. Este poderia ser um recurso de banco de dados, ou pode ser uma ferramenta autnoma ou a capacidade de um ambiente maior ferramenta, integrada. [Buc96: C13; IEEE828-98: c4s3.3]

b) Software de Status de Configurao Reporting Informaes relatadas podem ser usados por vrios elementos da organizao e do projeto, incluindo a equipe de desenvolvimento, a equipe de manuteno, gerenciamento de projetos e atividades de qualidade de software. Relatrios podem assumir a forma de consultas ad hoc para responder a questes especficas ou a produo peridica de relatrios predefinidos. Algumas informaes produzidas pela atividade contbil status no decurso do ciclo de vida pode tornar-se registos de qualidade. Alm de relatar o status atual da configurao, as informaes obtidas pela SCSA pode servir como base para vrias medidas de interesse para o desenvolvimento, gesto e SCM. Exemplos incluem o nmero de solicitaes de mudana por SCI e o tempo mdio necessrio para executar uma solicitao de mudana. [Ber92: C10; Buc96: c13] 2.1.3.6.5 Auditoria de Configurao de Software A auditoria de software uma atividade realizada de forma independente avaliar a conformidade de produtos de software e processos de regulamentos, normas, diretrizes, planos e procedimentos (IEEE1028-97). As auditorias so realizadas de acordo com um processo bem definido composto de vrios papis e

127

responsabilidades do auditor. Consequentemente, cada auditoria deve ser planejada com cuidado. Uma auditoria pode exigir um nmero de indivduos para executar uma variedade de tarefas ao longo de um perodo relativamente curto de tempo. Ferramentas para apoiar o planeamento e a conduo de uma auditoria pode contribuir para facilitar o processo. Orientao para a realizao de auditorias de software est disponvel em diversas referncias, como [Ber92: C11; Buc96: C15] e (IEEE1028-97). O software da catividade de auditoria de configurao determina o grau em que um item satisfaa as caractersticas exigidas fsica e funcional. Informal auditorias deste tipo podem ser realizados em pontos-chave do ciclo de vida. Dois tipos de auditorias formais pode ser exigido pelo contrato que rege (por exemplo, em contratos de cobertura de software crtico): a Auditoria de Configurao Funcional (FCA) e da Auditoria de Configurao Fsica (PCA). A concluso bem sucedida destas auditorias pode ser um pr-requisito para o estabelecimento da linha de base do produto. Buckley [Buc96: c15] contrasta os efeitos da FCA e PCA em contextos de hardware versus software, e recomenda uma avaliao cuidadosa da necessidade de um software FCA e PCA antes de execut-las. a) Software de Auditoria de Configurao Funcional O objetivo do software FCA garantir que o item de software auditado est em conformidade com as especificaes aplicveis. A sada das catividades de verificao e validao um contributo essencial para esta auditoria. b) Software de Auditoria de Configurao Fsica O objetivo da auditoria de configurao de software fsica (PCA) garantir que a documentao do projeto e de referncia consistente com o produto de software "como construdo". c) Auditorias de processo de uma Baseline Software Como mencionado acima, as auditorias podem ser realizadas durante o processo de desenvolvimento para investigar o estado atual de elementos especficos da configurao. Neste caso, a auditoria pode ser aplicada a itens de linha de base da amostra para assegurar que o desempenho consistente com as

128

especificaes ou para assegurar a evoluo documentao continua a ser consistente com o ponto inicial de desenvolvimento. 2.1.3.6.6 Software de Gerenciamento de Liberao e Entrega A "libertao" utilizado neste contexto para se referir distribuio de um item de configurao de software fora da atividade de desenvolvimento. Isto inclui a libertao interna, bem como a distribuio aos clientes. Quando as verses diferentes de um item de software esto disponveis para entrega, como verses para diferentes plataformas ou em verses com capacidades diferentes, frequentemente necessrio para recriar verses especficas de pacotes e os materiais corretos para a entrega da verso. A biblioteca de software um elementochave na realizao de tarefas de lanamento e entrega. a) Construindo software Construo de software a atividade de combinar as verses corretas dos itens de configurao de software, utilizando os dados de configurao adequada, em um programa executvel para a entrega a um cliente ou outro destinatrio, como a atividade de teste. Para sistemas com hardware ou firmware, o programa executvel entregue atividade de construo do sistema. Construir instrues garantir que o bom construir sejam tomadas medidas e na sequncia correta. Alm da construo de software para novos lanamentos, geralmente necessrio tambm para SCM ter a capacidade de reproduzir verses anteriores para a recuperao, testes, manuteno, ou para fins de liberao adicional. Software construdo usando uma verso particular de ferramentas de apoio, tais como compiladores. Pode ser necessrio para reconstruir uma cpia exata de um item previamente construda configurao de software. Neste caso, as ferramentas de apoio e instrues de construo associados precisam estar sob controle de SCM para garantir a disponibilidade das verses corretas dos instrumentos. A capacidade de ferramenta til para selecionar as verses corretas dos itens de software em um ambiente determinado objectivo e para automatizar o processo de construo do software a partir das verses selecionada e os dados de configurao apropriada. Para grandes projetos, com desenvolvimento paralelo ou

129

em ambientes de desenvolvimento distribudo, esta capacidade ferramenta necessria. A maioria dos ambientes de engenharia de software fornecem esse recurso. Essas ferramentas variam em complexidade de exigir o engenheiro de software para aprender uma linguagem de script especializada para abordagens de grficos orientado que escondem muito da complexidade de um "inteligente" construir instalaes. O processo de construo e produtos esto frequentemente sujeitos a verificao da qualidade de software. As sadas do processo de compilao pode ser necessrio para referncia futura e pode tornar-se registros de garantia da qualidade. [Bab86: C6; Som05: C29] b) Software de Gerenciamento de Liberao Software de gerenciamento de liberao compreende a identificao, embalagem e entrega dos elementos de um produto, por exemplo, o programa executvel, documentao, notas de lanamento, e os dados de configurao. Dado que as alteraes do produto pode ocorrer em uma base contnua, uma preocupao para a gesto de liberao determinar quando a emitir um comunicado. A gravidade dos problemas abordados pela liberao e medies das densidades de falha de verses anteriores afetar essa deciso. (Som01) A tarefa embalagens devem identificar quais os itens de produtos devem ser entregues, em seguida, selecione as variantes correta desses itens, devido aplicao prevista para o produto. As informaes documentar o contedo fsico de uma liberao conhecido como um documento de descrio de verso. As notas de lanamento normalmente descrevem novos recursos, problemas conhecidos, e os requisitos de plataforma necessria para a operao adequada do produto. O pacote a ser lanado tambm contm instrues de instalao ou atualizao. Este ltimo pode ser complicada pelo fato de que alguns usurios atuais pode ter verses que so vrias verses antigas. Finalmente, em alguns casos, a atividade de gerenciamento de liberao pode ser necessria para controlar a distribuio do produto para vrios clientes ou sistemas de destino. Um exemplo seria um caso em que o fornecedor era obrigado a notificar o cliente de novos problemas relatados. A capacidade de ferramenta necessria para suportar essas funes de gerenciamento de liberao. til ter uma conexo com a capacidade ferramenta de

130

apoio ao processo de solicitao de alterao de contedo, a fim de mapear a libertao para o SCR que tenham sido recebidos. Esta capacidade ferramenta pode tambm manter informaes sobre as plataformas alvo diferentes e em ambientes de vrios clientes.[Som05: C29] 2.1.3.7 Gerncia de Engenharia de Software Gerncia de Engenharia de Software pode ser definida como a aplicao das atividades de gerenciamento planejamento, coordenao, mensurao, monitorao, controle e informao - para garantir que o desenvolvimento e manuteno do software seja sistemtico, disciplinado e quantificado (IEEE610.1290). A rea de conhecimento Gerncia da Engenharia de Software, portanto, trata o gerenciamento e a mensurao da engenharia de software. Embora a mensurao seja um aspecto importante de todas as KAs, aqui que o tpico de mensurao de programas apresentado. Embora seja verdade que, em um sentido, deveria ser possvel gerenciar a engenharia de software da mesma forma que qualquer outro processo (complexo), existem aspectos especficos aos produtos de software e aos processos do ciclo de vida do software que complicam o gerenciamento efetivo - apenas alguns dos quais so os seguintes: A percepo dos clientes tal que frequentemente existe uma falta de reconhecimento da complexidade inerente engenharia de software, particularmente em relao ao impacto das mudanas de requisitos. quase inevitvel que o processo de engenharia de software por ele prprio gerar a necessidade de requisitos de cliente novos ou mudados. Como resultado, o software muitas vezes construdo em um processo iterativo ao invs de em uma sequncia de tarefas fechadas. Engenharia de software necessariamente incorpora aspectos de criatividade e disciplina - a manuteno de um apropriado equilbrio entre as duas muitas vezes difcil. O grau de novidade e complexidade do software muitas vezes extremamente elevado. Existe um ritmo rpido de mudanas na tecnologia subjacente.

131

Com respeito engenharia de software, atividades de gerenciamento ocorrem em trs nveis: gerenciamento organizacional e de infraestrutura, gerncia de projetos, e planejamento e controle do programa de mensuraes. As duas ltimas so cobertas em detalhes na descrio desta KA. Entretanto, isto no para diminuir a importncia das questes de gerenciamento organizacional. Como o link s disciplinas relacionadas - obviamente gerenciamento - importante, ele ser descrito em maior detalhe do que nas descries das outras KA. Aspectos de gerncia organizacional so importantes em termos de seu impacto na engenharia de software - sobre a poltica de gesto, por exemplo: padres e polticas organizacionais fornecem a estrutura na qual a engenharia de software realizada. Essas polticas podem precisar ser influenciadas pelos requisitos do efetivo desenvolvimento e manuteno do software, e um nmero especfico de polticas de engenharia de software podem ter que ser estabelecidas para o efetivo gerenciamento da engenharia de software no nvel organizacional. Por exemplo, polticas normalmente so necessrias para estabelecer processos especficos em escala organizacional ou procedimentos para tais tarefas de engenharia de software como projeto, implementao, estimativas, monitoramento e "informes/relatrios". Tais polticas so essenciais para a gerncia efetiva e de longo termo da engenharia de software, pela definio de uma base consistente sobre a qual analisar a performance passada e implementar as melhorias, por exemplo. Outro aspecto importante do gerenciamento a gesto de pessoal: polticas e procedimentos para contratar, treinar, e motivar pessoal e mentalizar o desenvolvimento da carreira so importantes no somente no nvel do projeto mas, tambm, no sucesso de longo prazo de uma organizao. Pessoal de engenharia de software pode ter treinamento nico ou gerenciamento das mudanas de pessoal (por exemplo, mantendo a atualizao num contexto onde a tecnologia subjacente sofre mudanas rpidas e contnuas. Gerncia de comunicao tambm muitas vezes mencionada como um aspecto despercebido porm importante de performance dos indivduos num campo onde o entendimento preciso das necessidades do usurio e dos requisitos e projetos complexos necessrio. Finalmente, a gerncia de portflio, que a capacidade de ter uma viso geral no somente do conjunto de software em desenvolvimento mas, tambm, do software j em uso em uma organizao, necessria. Alm do mais, reuso de software o

132

fator chave na manuteno e melhoria da produtividade e competitividade. Reuso efetivo requer uma viso estratgica que reflete a fora nica e as exigncias desta tcnica. Em adio ao entendimento dos aspectos do gerenciamento que so unicamente influenciados pelo software, engenheiros de software devem ter algum conhecimento dos aspectos mais genricos, mesmo nos quatro primeiros anos aps a graduao que so rotulados no Guia. Comportamento e cultura organizacional, e gerncia funcional da empresa em termos de aquisies, gesto da cadeia de fornecedores, marketing, vendas, e distribuio, todos tm influncia, mesmo que indireta, no processo de engenharia de software da organizao. Relevante para esta KA a noo da gerncia de projeto, como 'a construo de artefatos de software teis' normalmente gerida na forma de (talvez programas de) projetos individuais. Neste sentido, encontramos amplo apoio no Guia para o Conjunto de Conhecimentos da Gerncia de Projetos (PMBOK) (PMI00), o qual por si s inclui as seguintes KA: gerncia de integrao do projeto, gerncia de escopo do projeto, gerncia de tempo do projeto, gerncia de custo do projeto, gerncia da qualidade do projeto, gerncia de recursos humanos do projeto, e gerncia de comunicaes do projeto. Evidentemente, todos esses tpicos tm relevncia direta para a rea de conhecimento de Gerncia de Engenharia de Software. Tentar duplicar o contedo do Guia do PMBOK aqui seria tanto impossvel quanto inapropriado. Ao contrrio, sugerimos que o leitor interessado na gerncia de projeto alm do que especfico para os projetos de engenharia de software consulte o PMBOK. Gerncia de projetos tambm encontrada no captulo das Disciplinas Relacionadas Engenharia de Software. A KA Gerncia de Engenharia de Software consiste tanto do processo de gerncia de projeto de software, nas suas primeiras cinco subreas, quanto da mensurao da engenharia de software na sua ltima subrea Embora essas duas disciplinas sejam muitas vezes consideradas como sendo separadas, e sem dvida elas possuem muitos aspectos nicos, suas estreitas relaes levaram a um tratamento combinado nesta KA. Infelizmente, uma percepo comum na indstria de software que ela entrega produtos com atraso, alm do custo, de baixa qualidade e de funcionalidade incerta. Gerncia de mensurao informada - um

133

princpio assumido de qualquer verdadeira disciplina de engenharia - pode ajudar a mudar essa percepo. Na essncia, gerenciamento sem mensurao, qualitativa e quantitativamente, sugere uma falta de rigor, e mensurao sem gerenciamento sugere uma falta de finalidade ou contexto. Da mesma forma, entretanto, gerenciamento e mensurao sem conhecimento tcnico especializado intil, por isso, devemos ter cuidado para evitar o excesso de nfase nos aspectos quantitativos da Gerncia de Engenharia de Software (GES). A gerncia efetiva requer a combinao de ambos: nmeros e experincia. As seguintes definies de trabalho so adotadas aqui: Gerncia de processo refere-se s atividades que so feitas com o fim de garantir que os processos de engenharia de software so realizados de uma maneira consistente com as polticas, objetivos e padres da organizao. Mensurao refere-se atribuio de valores e rtulos aos aspectos de engenharia de software (produtos, processos e fontes so definidos por [Fen98]) e os modelos que so derivados a partir deles, se esses modelos so desenvolvidos usando estatstica, conhecimento tcnico especializado ou outras tcnicas. As subreas da gerncia de projetos da engenharia de software fazem uso extensivo da subrea de medio de engenharia de software. No inesperadamente, esta KA est intimamente relacionada a outras no Guia SWEBOK e ler as descries das seguintes KAs em conjunto com esta seria particularmente til:

Requisitos de Software, onde algumas das atividades a serem realizadas durante a definio da fase de Iniciao e Escopo do projeto so descritas. Gerncia de Configurao de Software, como esta trata a identificao, controle, status de contabilizao e auditoria da configurao do software junto com a gerncia de lanamento e entrega.

Processo de Engenharia de Software, porque processos e projetos so intimamente ligados (esta KA tambm descreve a medio de processos e produtos).

Qualidade de Software, como qualidade uma meta constante da gerncia e um objetivo de muitas atividades que devem ser gerenciadas.

134

Como a KA de Gerncia de Engenharia de Software vista aqui como um processo organizacional o qual incorpora a noo de gerncia de processo e de projetos, ns criamos uma estrutura que tanto baseada em tpicos quanto baseada no ciclo de vida. Entretanto, a principal base para a estrutura de tpico de nvel mais superior o processo de gerncia de um projeto de engenharia de software. Existem seis grandes subreas As cinco primeiras subreas seguem largamente o Processo de Gerenciamento da IEEE/EIA 12207. As seis subreas so:

Iniciao e definio de escopo, a qual vai de encontro com a deciso de iniciar um projeto de engenharia de software. Planejamento do projeto de software, a qual orienta as atividades empreendidas para preparar para o sucesso a engenharia de software a partir de uma perspectiva de gerenciamento.

Formalizao do projeto de software, a qual aborda as atividades de gerncia de engenharia de software geralmente aceitas que ocorrem durante a engenharia de software.

Anlise e avaliao, a qual trata da garantia de que o software seja satisfatrio. Fechamento (encerramento), que trata das atividades de ps-realizao de um projeto de engenharia de software. Mensurao da engenharia de software, a qual aborda o desenvolvimento e implementao efetiva de programas de mensurao nas organizaes de engenharia de software (IEEE12207.0-96). A estrutura de tpicos para a KA de Gerncia de Engenharia de Software

mostrada na Figura 22.

135

Figura 22: Tpicos da KA Gerncia de Engenharia de Software

2.1.3.7.1 Iniciao e Definio de escopo O foco deste conjunto de atividades est na eficaz determinao de exigncias de software via mtodos de elicitao e avaliao do desenvolvimento da prtica do projeto, olhando de vrios pontos de vista. Uma vez a prtica sendo estabelecida, as tarefas restantes dentro deste processo passam a ser a especificao de requisitos e modificao dos procedimentos (ver tambm as Exigncias de Software KA). a) Determinao e Negociao de Requisitos Mtodos de requerimentos de software para elicitao de requisitos (por exemplo, observao), anlise (por exemplo, modelagem de dados, modelagem de casos de uso), especificao, e validao (por exemplo, prototipagem) deve ser selecionado e aplicado, considerando-se as perspectivas de todas partes interessadas. Isto leva determinao de alcance de projeto, objetivos e constrangimentos. Isto exige, muitas vezes alguns "campos" de estimao, esforo e custo baseados em mtodos adequados (por exemplo, tcnicas de analogia informadas por perito).[Dor02: v2c4; Pfl01: c4; Pre04: c7; Som05: c5]

136

b) Anlise de Viabilidade (tcnica, operacional, financeira, Poltica/Social) Engenheiros de software devem estar seguros sobre a capacidade adequada e se os recursos esto disponveis (pessoas, especializao, instalaes, infraestrutura e apoio) quer interna ou externamente, para garantir que o projeto tenha xito em tempo oportuno e eficaz em termos de custos (usando, por exemplo, um requisito capacidade matriz). Isto muitas vezes necessita alguma estimativa "aproximada" de esforo e preo baseado em mtodos apropriados (por exemplo, informao de perito e analogia tcnica).[Pre04: c6; Som05: c6] c) Processo para Anlise e Reviso de Requisitos Dada a inevitabilidade da mudana, fundamental que o acordo entre as partes interessadas seja realizado no incio. Para isso as exigncias e o acordo devem ser revisados (por exemplo, atravs de mudanas na gesto dos procedimentos). Isto implica, claramente, que os requisitos no sero "gravados na pedra", mas podem e devem ser revistos em pontos como o processo se desdobra (por exemplo, na reviso de desenhos, reviso de gerenciamentos). Se mudanas so aceitas, ento alguma forma de rastreabilidade, anlise de risco (ver tpico 2.5 Gesto de Riscos) deveria ser utilizada para aferir o impacto dessas mudanas. A gesto de abordagem das mudanas deveria ser igualmente til se na hora de analisar o resultado do projeto, o escopo e requisitos formam uma base para a avaliao do sucesso. [Som05: c6] Ver tambm as subreas de configurao de controle de software em Software Configuration Management KA. 2.1.3.7.2 Planejamento de Projeto de Software O processo de planejamento iterativo informado pelo alcance e exigncias e pelo estabelecimento de praticabilidade. Nesse ponto, os processos de ciclo de vida de software so avaliados e a parte mais apropriada (dado a natureza do projeto, o seu grau de novidade, a sua complexidade funcional e tcnica, as suas exigncias de qualidade, e assim por diante) selecionada. Onde relevante, o prprio projeto ento planejado na forma da decomposio hierrquica de tarefas, os resultados finais de cada tarefa so especificados e caracterizados em termos de qualidade e outros atributos de acordo com determinadas exigncias, e esforo detalhado, horrio, e preo a estimativa empreendida. Os recursos ento so alocados s

137

tarefas para otimizar produtividade de pessoal (no individual, equipe, e nveis organizacionais), equipamento e utilizao de materiais, e aderncia para planejar. A gerncia de riscos detalhada empreendida e o perfil de riscos do projeto discutido e aceito por todas as partes relevantes interessadas. Na gerncia de qualidade de software abrangente os processos so determinados como parte do processo de planejamento na forma de procedimentos e responsabilidades por software asseguramento da qualidade, verificao e validao, revistas, e auditorias (ver a Qualidade de Software KA). Como um processo iterativo, vital que os processos e responsabilidades pela gerncia de plano contnuo, a anlise, e a reviso sejam, tambm claramente afirmadas e aceitas. a) Planejamento de Processo Seleo do modelo de ciclo de vida de software apropriado (por exemplo, espiral, prototipao evolutiva) e a adaptao e implantao de software de ciclo de vida por processos apropriados, so realizadas em funo das especialidades dos requisitos do projeto. Mtodos relevantes e os instrumentos tambm so selecionados. [Dor02: v1c6, v2c8; Pfl01: c2; Pre04: c2; Rei02: c1, c3, c5; Som05: c3; Tha97: c3] Ao nvel do projeto, ferramentas e mtodos apropriados so utilizados para decompor o projeto em funes, com os insumos, resultados, concluso e condies de realizao (por exemplo, estrutura de emergncia de trabalho). [Dor02: v2c7; Pfl01: c3; Pre04: c21;Rei02: c4,c5; Som05: c4; Tha97: c4,c6] Este, por sua vez, influencia as decises na programao e organizao estrutural do projeto. b) Determinar os Resultados Finais O(s) produto(s) de cada tarefa (por exemplo, desenho arquitetnico, relatrio de inspeo) so especificados e caracterizados. [Pfl01: c3; Pre04: c24; Tha97: c4] Oportunidades de reutilizar componentes de software previamente desenvolvidos ou a utilizao de produtos de software so avaliados. Uso de terceiros, bem como adquirir software planejado e fornecedores so selecionados. c) Esforo, Programao, e Estimativa de Preo Com base na repartio de tarefas, entradas, sadas e, a variedade necessria de esforo esperada para cada tarefa determinada usando uma

138

estimativa baseada no modelo histrico do tamanho do esforo quando os dados disponveis e relevantes, ou outros mtodos como peritos so avaliados. As dependncias de tarefa so estabelecidas e os gargalos potenciais so identificados usando mtodos convenientes (por exemplo, anlise de caminho crtico). Os gargalos so resolvidos onde possvel e o tempo estimado de tarefas com tempos de partida projetados, duraes, e tempo limite para produo so produzidos (por exemplo, um grfico PERT). Requerimentos de recursos (pessoas, ferramentas) so traduzidos em estimativas de custos. [Dor02: v2c7; Fen98: c12; Pfl01: c3; Pre04: c23,c24; Rei02: c5,c6; Som05: c4,c23; Tha97: c5] Isto uma atividade altamente iterativa que deve ser negociada e revisada at que o consenso seja conseguido entre todas as partes afetadas (principalmente engenharia e gerncia). d) Alocao de Recurso Equipamentos, instalaes, e as pessoas esto associados tarefas agendadas, incluindo a atribuio de responsabilidades para a concluso (utilizando, por exemplo, um grfico Gantt). Esta atividade informada e condicionada pela disponibilidade de recursos e a sua utilizao otimizada, nestas condies, bem como pelas questes relativas ao pessoal (por exemplo, produtividade dos indivduos / equipes, equipe dinmica e estruturas organizacionais). e) Gesto de Riscos Identificao e anlise de risco (o que pode dar errado, como e por qu, e quais so as consequncias provveis), avaliao crtica de riscos (quais so os riscos mais significativos em termos de exposio, o que podemos fazer em termos de iniciao), compensao de risco e contingncia de planejamento (formulao de uma estratgia para lidar com riscos e para gerenciar o perfil de risco) so todas realizadas. Mtodos de avaliao de riscos (por exemplo, rvores de deciso e simulaes de processo) devem ser usados para destacar e avaliar os riscos. A poltica de abandono de projeto deve ser determinada neste ponto na discusso com todas partes interessadas. [Dor02: v2c7; Pfl01: c3; Pre04: C25; Rei02: C11; Som05: c4; Tha97: c4]. Aspectos de riscos de software, como a tendncia de engenheiros de software em acrescentarem recursos indesejveis ou os riscos ligados natureza intangvel do software, devem influenciar a gesto de risco do projeto.

139

f) Gesto de Qualidade A qualidade definida em termos de atributos pertinentes ao projeto especfico e qualquer produto(s) associado(s), possivelmente tanto em requisitos quantitativos quanto qualitativos. Essas caractersticas de qualidade sero determinadas na especificao dos requerimentos detalhados do software. Veja tambm os Requerimentos de Software KA. Os limiares para aderncia qualidade so definidos para cada indicador de acordo com as expectativas dos intervenientes com relao ao software. Procedimentos relativos SQA em curso ao longo do processo e verificao e validao de produto (realizaes) so tambm especificadas neste estgio (por exemplo, revises e inspees tcnicas) (veja tambm Qualidade de Software KA). g) Gesto de Plano Como o projeto e o plano sero geridos tambm deve ser planejado. Reportando, monitorando e controlando o projeto deve estar de acordo com o processo de engenharia de software selecionado e s realidades do projeto, e devem ser refletidos nos variados artefatos que sero usados para geri-lo. Mas, num ambiente onde a mudana esperada ao invs de um choque, vital que os planos sejam geridos por si ss. Isso exige que a aderncia aos planos seja sistematicamente dirigida, monitorada, revista, reportada, e, onde apropriado, revisada. Planos associados a outros processos de suporte orientados para gesto (por exemplo, documentao, gesto de configurao de software, e soluo de problema) tambm precisam ser geridos da mesma maneira. 2.1.3.7.3 Formalizao do Projeto de Software Os planos so, ento, implementados e os processos consubstanciados nos planos so formalizados. Em tudo, h o foco na aderncia aos planos, com uma expectativa prioritria de que tal aderncia ir levar bem sucedida satisfao dos requisitos do stakeholder e ao alcance dos objetivos do projeto. Fundamental para a formalizao so as atuais atividades de mensurao, monitorao, controle e relatrios (divulgao de informaes).

140

a) Implementao dos Planos O projeto iniciado e as atividades do projeto so realizadas de acordo com o cronograma. No processo, recursos so utilizados (por exemplo, esforo pessoal, financiamento) e entregas so produzidas (por exemplo, documentos de projeto da arquitetura, casos de teste). b) Gerncia de Contrato de Fornecedores Prepare e execute contratos com fornecedores, monitore o desempenho dos fornecedores, e aceite o fornecedor de produtos, incorporando-os como for apropriado. c) Implementao da Mensurao de Processos O processo de mensurao formalizado junto com o projeto de software, assegurando que os dados relevantes e teis so coletados. d) Acompanhamento do Processo A aderncia aos variados planos continuamente avaliada em intervalos prdeterminados. Resultados e condies de concluso de cada tarefa so analisados. Entregas so avaliadas em termos de suas caractersticas requeridas (por exemplo, atravs de revises e auditorias). Esforo despendido, adeso ao cronograma e custos para entrega em dia so investigados e o recurso utilizado examinado. O perfil de risco do projeto revisto e a aderncia aos requisitos de qualidade avaliada. Medies de dados so modeladas e analisadas. Anlise de variaes baseada nos desvios dos resultados e valores atuais e esperados efetuada. Isto pode ser feito na forma de custos extrapolados, cronograma ultrapassado e coisas parecidas. Identificaes atpicas, anlise da qualidade e outras mensuraes de dados so realizadas (por exemplo, anlise da densidade dos defeitos). A influncia de e a exposio a riscos so recalculadas e rvores de deciso, simulaes e outros mais so refeitos luz dos novos dados. Essas atividades habilitam a deteco de problemas e a identificao de excees com base nos limites excedidos. Os resultados so relatados medida do preciso e, com certeza, onde

141

os limites aceitveis so superados. e) Controle do Processo Os resultados das atividades de acompanhamento do processo fornecem as bases nas quais as aes de deciso so tomadas. Onde for apropriado, e onde o impacto e os riscos associados forem modelados e gerenciados, as mudanas podem ser feitas no projeto. Isto pode ter a forma de aes corretivas (por exemplo, retestar certos componentes), ela pode envolver a incorporao das contingncias de forma que ocorrncias similares sejam evitadas (por exemplo, a deciso de usar prototipao para ajudar na validao dos requisitos do software), e/ou ela pode acarretar a reviso de vrios planos e documentos do projeto (por exemplo, especificao de requisitos) para acomodar os resultados inesperados e suas implicaes. Em alguns casos, ela pode levar ao abandono do projeto. Em todos os casos, procedimentos de controle de mudanas e gerncia de configurao de software so cumpridos (veja tambm a KA de Gerncia de Configurao de Software) para que as decises sejam documentadas e comunicadas a todos os interessados, planos so revistos e revisados quando preciso e dados importantes so gravados na base de dados central. f) Relatrio Nos perodos especificados e acordados, o cumprimento dos planos relatado, tanto internamente para a organizao (por exemplo, para o comit diretor de portflios de projeto) quanto externamente para os stakeholders (por exemplo, clientes, usurios). Relatrios desta natureza devem focar-se no cumprimento geral em oposio aos relatrios detalhados frequentemente exigidos pela equipe interna do projeto. 2.1.3.7.4 Anlise e Avaliao Em pontos crticos do projeto, o progresso geral voltado para o alcance dos objetivos definidos e para a satisfao dos requisitos do stakeholder avaliado. Analogamente, avaliaes da efetividade do processo como um todo para prazos, pessoal envolvido e ferramentas e mtodos empregados tambm so realizados nos

142

marcos particulares. a) Determinando a Satisfao dos Requisitos Desde que a obteno da satisfao do stakeholder (usurio e cliente) um dos nossos principais objetivos, importante que o progresso deste objetivo seja formal e periodicamente avaliado. Isto ocorre no atingimento dos principais marcos do projeto (por exemplo, confirmao da arquitetura do projeto de software, anlise tcnica da integrao do software). Variaes das expectativas so identificadas e as aes adequadas so tomadas. Como acima, na atividade de controle do processo (veja tpico 3.5 Controle do Processo), em todos os casos procedimentos de controle de mudanas e gerncia de configurao de software so cumpridos (veja tambm a KA de Gerncia de Configurao de Software) para que as decises sejam documentadas e comunicadas a todos os interessados, planos so revistos e revisados quando preciso e dados importantes so gravados na base de dados central (veja tambm 6.3 Execuo do Processo de Medio/'Mensurao'). Mais informaes podem ser encontradas na KA de Teste de Software, tpico 2.2 Objetivos de Testes e na KA de Qualidade de Software, tpico 2.3 Revises e Auditorias. b) Analisando e Avaliando o Desempenho/Performance Revises peridicas de desempenho para o pessoal do projeto fornecem esclarecimentos quanto a probabilidade de cumprimento dos planos tanto quanto a possveis reas de dificuldade (por exemplo, conflitos entre membros da equipe). Os vrios mtodos, ferramentas, e tcnicas empregados so avaliados por sua efetividade e adequao, e o processo por si s sistemtica e periodicamente avaliado por sua relevncia, utilidade e eficcia no contexto do projeto Onde apropriado, mudanas so feitas e gerenciadas. 2.1.3.7.5 Fechamento O projeto alcana o fim quando todos os planos e processos envolvidos tenham sido formalizados e completados. Neste estgio, o critrio para o sucesso do projeto revisto. Uma vez que o fechamento/trmino seja estabelecido, atividades post mortem, de melhoria do processo e de arquivamento so realizadas.

143

a) Determinando o Fechamento As tarefas como especificada nos planos so completadas e o alcance satisfatrio da completude dos critrios confirmado. Todos os produtos planejados so entregues com caractersticas aceitveis. Requisitos so verificados e confirmados como satisfeitos, e os objetivos do projeto so alcanados. Esses processos normalmente envolvem todos os stakeholders e resultam na documentao da aceitao do cliente e quaisquer relatos de problemas remanescentes reconhecidos. b) Atividades de Fechamento Aps o fechamento ser confirmado, o arquivamento dos materiais do projeto toma lugar alinhado com a concordncia do stakeholder quanto a mtodos, localizao e durao. A base de dados de mensuraes/medies da organizao atualizada com os dados finais do projeto e anlises ps-projeto so realizadas. O post mortem de um projeto feito de forma que questes, problemas e oportunidades encontradas durante o processo (particularmente atravs de revises e avaliaes, veja subrea 4 Anlises e Avaliaes) so analisadas, e lies so desenhadas a partir do processo e alimentam o aprendizado organizacional e melhoram os empreendimentos. (veja tambm a KA Processo de Engenharia de Software). 2.1.3.7.6 Mensurao/Medio de Engenharia de Software A importncia da mensurao e sua funo nas melhores prticas de gerenciamento vastamente reconhecida e, assim, sua importncia tende a crescer nos anos vindouros. Mensurao efetiva tem se tornado uma das pedras fundamentais da maturidade organizacional. Termos chave na medio de software e nos mtodos de medio tem sidos definidos na [ISO 15939-02] com base no vocabulrio ISO internacional de mensurao [ISO93]. Contudo, leitores iro encontrar diferenas de terminologia na literatura; por exemplo, o termo mtrica algumas vezes usado no lugar de medidas. Este tpico segue o padro internacional ISO/IEC 15939, o qual descreve um processo que define as atividades e tarefas necessrias para implementar um processo de mensurao de software bem como inclui um modelo de informaes

144

de mensurao. a) Estabelea e Sustente o Compromisso de Medies Aceite as exigncias por mensuraes/medies. Cada empreendimento de medio deve ser guiado por objetivos organizacionais e orientado por um conjunto de requisitos de medies estabelecidos pela organizao e pelo projeto. Por exemplo, um objetivo organizacional deve ser "ser o primeiro no mercado com novos produtos." [Fen98: c3,c13; Pre04: c22] Isto, por sua vez, poderia gerar um exigncia de que os fatores que contribuam para esse objetivo sejam medidos de forma que os projetos possam ser gerenciados para ir de encontro a esse objetivo. Defina o escopo da mensurao. A unidade organizacional na qual cada exigncia de medio para ser aplicada deve ser definida. Isso pode consistir de uma rea funcional, um nico projeto, um nico site ou mesmo a empresa inteira. Todas as tarefas subsequentes relacionadas a esse requisito devem estar dentro do escopo definido. Adicionalmente, os stakeholders devem ser identificados. Compromisso da gerncia e equipe para medies. O compromisso deve ser formalmente estabelecido, comunicado e apoiado por recursos (veja o prximo item). Comprometa/confirme recursos para as medies. O compromisso da organizao para as medies um fator essencial de sucesso, como evidenciado pela alocao de recursos para implementar o processo de mensurao/medio. A alocao de recursos inclui a designao de responsabilidade para as vrias tarefas do processo de mensurao (tais como usurio, analista e documentador) e o fornecimento de financiamento adequado, treinamento, ferramentas, e apoio para conduzir o processo como uma moda duradoura. b) Planeje o Processo de Mensurao/Medio Caracterize a unidade organizacional. A unidade organizacional fornece o contexto para a mensurao/medio, ento ela importante para tornar esse contexto explcito e para articular as proposies que ela incorpora e as restries que a ela so impostas. A caracterizao pode ser em termos de processos organizacionais, domnios de aplicaes, tecnologia e fronteiras organizacionais. Um modelo de processo organizacional tambm tipicamente um elemento de caracterizao da unidade organizacional [ISO 15939-02: 5.2.1].

145

Identifique as informaes necessrias. Informaes necessrias so baseadas nas metas, restries, riscos e problemas da unidade organizacional. Elas podem ser derivadas a partir do negcio, da organizao, regulamentao e/ou objetivos do produto. Elas devem ser identificadas e priorizadas. ento, um subconjunto a ser tratado deve ser selecionado e seus resultados documentados, comunicados e revisados pelos stakeholders [ISO 15939-02: 5.2.2]. Selecione as medidas. Medidas candidatas devem ser selecionadas, com vnculos claros s informaes necessrias. Medidas devem, ento, ser selecionadas baseado nas prioridades das informaes necessrias e outros critrios tais como custo da coleta, grau de ruptura do processo durante a coleta, facilidade de anlise, facilidade de obteno de acurcia, consistncia dos dados, e outros mais [ISO 15939-02: 5.2.3 e Apndice C]. Defina os procedimentos de coleta de dados, anlise e relatrios. Isso engloba os procedimentos de coleta e cronograma, armazenamento, verificao, anlise, divulgao de relatrios e gerncia de configurao dos dados [ISO 1593902: 5.2.4]. Defina os critrios para a avaliao dos produtos de informao. Critrios para avaliao so influenciados pelos objetivos tcnicos e de negcio da unidade organizacional. Produtos de informao incluem aqueles associados com o produto sendo produzido, bem como aqueles associados com os processos em uso para gerenciar e medir o projeto [ISO 15939-02: 5.2.5 e Apndices D e E]. Revise, aprove e fornea recursos para as tarefas de mensurao/medio. O plano de medies deve ser revisado e aprovado pelos stakeholders apropriados. Isso inclui todos os procedimentos de coleta de dados, armazenamento, anlise e procedimentos de divulgao de relatrios; critrios de avaliao; cronograma e responsabilidades. Critrios para avaliao desses artefatos devem ser estabelecidos no nvel da unidade organizacional ou nvel superior e devem ser usados como base para essas revises. Tais critrios devem considerar as experincias anteriores, a disponibilidade de recursos e o potencial de interrupo do projeto quando mudanas nas prticas atuais so propostas. A aprovao demonstra o compromisso com o processo de medio [ISO 15939-02: 5.2.6.1 e Apndice F]. Recursos devem ser disponibilizados para a implementao das tarefas de

146

mensurao/medio planejadas e aprovadas. A disponibilidade de recursos pode ser especulada/experimentada nos casos onde as mudanas esto para ser praticadas antes de um amplo emprego dessas mudanas. Consideraes devem ser feitas quanto aos recursos necessrios para o emprego com sucesso dos novos procedimentos ou medidas [ISO 15939-02: 5.2.6.2]. Adquira e empregue tecnologias de apoio. Isto inclui a avaliao de tecnologias de apoio disponveis, seleo das tecnologias mais apropriadas, aquisio e emprego dessas tecnologias [ISO 15939-02: 5.2.7]. c) Execute o Processo de Mensurao/Medio Integre os procedimentos de medio com os processos relevantes. Os procedimentos de medio, tais como coleta de dados, devem ser integrados nos processos que eles esto medindo. Isto pode envolver a mudana dos processos atuais para acomodar a coleta de dados ou gerao de atividades. Ela pode envolver tambm a anlise dos processos atuais para minimizar os esforos adicionais e a avaliao do efeito sobre os empregados para garantir que os procedimentos de medio sero aceitos. Questes morais e outros fatores humanos precisam ser considerados. Adicionalmente, os procedimentos de medidas devem ser comunicados queles que fornecem os dados, pode ser preciso providenciar treinamento, e apoio/suporte deve tipicamente ser providenciado. Anlise de dados e procedimentos de divulgao de relatrios devem tipicamente ser integrados aos processos e/ou projetos organizacionais de uma forma similar [ISO 15939-02:5.3.1]. Colete dados. Os dados devem ser coletados, verificados e armazenado [ISO 15939-02: 5.3.2]. Analise os dados e desenvolva as informaes de produtos. Dados podem ser agregados, transformados ou registrados como parte do processo de anlise, usando um nvel de rigor adequado natureza dos dados e informaes necessrias. Os resultados dessas anlises so tipicamente indicadores que devem ser interpretados, resultando em concluses iniciais a serem apresentadas aos stakeholders. Os resultados e concluses devem ser revisados, usando um processo definido pela organizao (o qual pode ser formal ou informal). Fornecedores dos dados e usurios das medidas devem participar na reviso dos

147

dados para garantir que elas so significativas e acuradas/precisas e que elas podem resultar em aes razoveis [ISO 15939-02: 5.3.3 e Apndice G]. Comunique os resultados. As informaes dos produtos devem ser documentadas e comunicadas aos usurios e stakeholders [ISO 15939-02: 5.3.4]. d) Avalie as Medidas Avalie as informaes dos produtos. Avalie as informaes dos produtos contra os critrios de avaliao especificados e determine os pontos fortes e fracos das informaes dos produtos. Isto pode ser realizado por um processo interno ou por uma auditoria externa e deve incluir o feedback (retorno) dos usurios das medies. Registre as lies aprendidas numa base adequada [ISO 15939-02: 5.4.1 e Apndice D]. Avalie o processo de mensurao/medio. Avalie o processo de medio contra os critrios de avaliao especificados e determine os pontos fortes e fracos do processo. Isto pode ser realizado por um processo interno ou por uma auditoria externa e deve incluir o feedback (retorno) dos usurios das medies. Registre as lies aprendidas numa base adequada [ISO 15939-02: 5.4.1 e Apndice D]. Identifique melhorias potenciais. Tais melhorias podem ser mudanas nas formas dos indicadores, mudanas nas unidades de medida ou reclassificao das categorias. Determine os custos e benefcios das melhorias potenciais e selecione as aes de melhoria adequadas. Comunique as proposies de melhoria aos proprietrios do processo de medio e aos stakeholders para reviso e aprovao. Tambm comunique a falta de melhorias potenciais caso a anlise falhe ao identificar as melhorias [ISO 15939-02: 5.4.2]. 2.1.3.8 Processo de Engenharia de Software O processo de engenharia de software KA pode ser estudado em 2 nveis. O primeiro nvel engloba as atividades tcnicas e gerenciais dentro do processo do ciclo de vida do software que so realizados durante aquisio, desenvolvimento, manuteno e retirada. O segundo o meta nvel, que se concentra na definio, implementao, avaliao, mensurao, gerncia, mudana, melhoria do processo de ciclo de vida software em si. O primeiro nvel coberto por outra guia KA. Este KA est concentrado no segundo.

148

O termo processo de engenharia de software pode ser interpretado de diferentes maneiras, e isto pode causar confuso. A primeira maneira, onde a palavra o usada, como o processo de engenharia de software, poderia implicar que existe somente uma maneira correta de se executar tarefas de desempenho de engenharia de software. Este significado evitado neste Guia, porque no existe tal processo. Padres como IEEE12207 falam sobre o processo de engenharia de software, de maneira que existem muitos processos envolvidos, tais como processo de desenvolvimento, ou gerencia de processo de configurao. Uma segunda maneira refere-se discusso geral do processo para engenharia de software relatado. Esta a maneira entendida nesta KA, e sua maior inteno. Finalmente, a terceira maneira poderia significar a atual forma das atividades realizadas dentro das organizaes, a qual pode ser visualizado como um processo, especialmente dentro de uma organizao. Esta interpretao usada no KA em poucos exemplos. A KA se aplica a qualquer parte do gerenciamento do processo de ciclo de vida do software onde mudanas de processos ou de tecnologia so inicialmente introduzidas atravs da melhoria de processos ou produtos. Processo de engenharia de software relevante no somente para grandes organizaes. Pelo contrrio, as atividades relacionadas com o processo podem, e tem sido executadas com sucesso por pequenas organizaes, equipes e indivduos. O objetivo do gerenciamento do ciclo de vida do processo de software implementar um novo ou melhores processos nas atuais prticas, sejam elas individuais, de projeto ou organizacional. Esta KA no especifica o gerenciamento de recursos humanos (HRM), por exemplo, como os baseados em pessoas CMM (Cur02) e processo de engenharia de sistemas [ISO1528-028;IEEE 1220-981]. Tambm se deve reconhecer que muitos problemas de processo de engenharia de software esto intimamente relacionados com outras disciplinas, tais como o gerenciamento, embora tecnologias diferentes sejam usadas.

149

2.1.3.8.1 Processo de implementao e mudana Este subrea concentra-se na mudana organizacional. Ela descreve a infraestrutura, atividades, modelos, e consideraes prticas para o processo de implementao e mudana. descrita aqui a situao em que os processos so implantados pela primeira vez (por exemplo, introduo de um processo de inspeo em um projeto ou um mtodo que abrange todo o ciclo de vida), e onde os processos atuais esto mudando (por exemplo, introduo de uma ferramenta, ou otimizao de um procedimento). Isto tambm pode ser denominado processo de evoluo. Em ambos os casos, existe prticas que devem ser modificadas. Se as modificaes so grandes, ento mudanas na cultura da organizao podem ser necessrias.

Figura 23: Tpicos para a KA Processo de Engenharia de Software

a) Processo de Infraestrutura Este tpico inclui o conhecimento relacionado para o processo de engenharia de infraestrutura de software. Para estabelecer o ciclo de vida do processo de software, necessrio ter um

150

local com infraestrutura apropriada, o que significa que os recursos devem estar disponveis (pessoal competente, ferramentas e recursos financeiros) e responsabilidades definidas. Quando as tarefas forem completadas, ser a indicao de desempenho do gerenciamento para a apropriao, e desempenho do processo de engenharia de software. Varias diretorias poder ter que vir a ser criadas, tais como diretoria de superviso do desempenho do processo de engenharia de software. Uma descrio geral de uma infraestrutura para o processo de melhoria mostrada no [MCF96]. Dois principais tipos de infraestrutura so usados na prtica: o Grupo de Engenharia de Processo de Software e a Fbrica de Experincia. Grupo de Engenharia de Processo de Software (SEPG). O SEPG destinado a ser o foco central da engenharia de melhoria de software, e ela tem uma srie de responsabilidades em para iniciar e manter essa posio, os quais so descritas em [Fow90]. Experincia Fbrica (EF). O conceito de EF separa o projeto organizacional (por exemplo, a organizao de desenvolvimento de software,) da rea de melhoria. A rea de projeto organizacional se preocupa com o desenvolvimento e manuteno de software, enquanto EF se preocupa com a melhoria da engenharia do processo de software. A EF destinada a institucionalizar o aprendizado coletivo de uma rea pelo desenvolvimento, atualizando, e entregando rea de projetos pacotes experientes (por exemplo, guias, modelos e cursos de treinamento), tambm referidos como processos ativos. A organizao do projeto Exemplos de pacotes experientes so apresentados in [Bas92]. b) Gerenciamento do ciclo do Processo de software O gerenciamento de processo de software consiste de quatro atividades sequenciadas o que permitindo um ciclo iterativo para um contnuo feedback e melhoria do processo de software: Atividade de Estabelecer o Processo Infraestrutura consiste em estabelecer compromisso para o processo de implementao e mudana (incluindo obteno management buy-in) e na criao de uma infraestrutura adequada (recursos e responsabilidades) para as atividades.

151

A meta da atividade Planejamento entender os objetivos do negcio corrente e necessidades do indivduo, projeto, ou organizao, para identificar seus pontos fortes e fracos, e fazer um plano para processo de implementao e mudana. A meta da atividade de Processo de Implementao e Mudana executar o plano, implantar os novos processos (os quais podem envolver, por exemplo, implantao de ferramentas e treinamento do grupo), e/ou mudar os processos existentes.

Processo Avaliao se preocupa em descobrir o quo bem a implementao das mudanas atenderam ou no as expectativas e se os benefcios esperados foram alcanados. Os resultados so ento usados como entrada para ciclos sequentes.

c) Modelos Para Processos de Implementao e Mudana Dois modelos gerais que tem emergido para orientar processos de implementao e mudana so o Paradigma de Melhoria de Qualidade (QIP) [SEL96] e o Modelo IDEAL [McF96]. Os dois paradigmas so comparados em [SEL96]. Os Resultados da avaliao do processo de implementao e mudana podem ser qualitativos ou quantitativos. d) Consideraes Prticas Processo de implementao e mudana constitui um exemplo de mudana organizacional. A mudana organizacional mais bem sucedia trata a mudana como um projeto prprio, com planos apropriados, monitoramento, e revises. A Orientaes sobre o processo de implementao e mudana da engenharia de software dentro de organizaes, inclui aes de planejamento, formao, gesto de patrocnio, desempenho, e a seleo de projetos piloto, que abrangem tanto processos como ferramentas, so apresentados em [Moi98; San98; Sti99]. Estudos empricos sobre fatores de sucesso para processos de mudana so relatados em (EIE99a). O papel dos agentes de mudana nesta atividade discutido em (Hut94). O processo de implementao e mudana tambm pode ser visto como uma instncia de consulta (seja interna ou externa).

152

Uma mudana organizacional tambm pode ser vista a partir da perspectiva da transferncia de tecnologia (Rog83). Artigos de engenharia de software que discutem a transferncia de tecnologia e as caractersticas dos destinatrios da nova tecnologia (que pode incluir tecnologias relacionadas com o processo) esto em (Pfl99; Rag89). Existem duas formas de abordar a avaliao do processo de implementao e mudana, quer em termos de alteraes do prprio processo ou em termos de alteraes do processo de resultados (por exemplo, medir o retorno sobre o investimento para realizar a alterao). Um olhar pragmtico para o que pode ser alcanado a partir desses estudos de avaliao dado em (Her98). Um panorama das formas de avaliar processo de implementao e mudana, e os exemplos de estudos, pode ser encontrado em [Gol99], 9kit98; Kra99; McG94. 2.1.3.8.2 Definio de Processo A definio de processo pode ser um procedimento, uma poltica, ou uma norma. Processos de ciclo de vida de software so definidos por uma srie de razes, incluindo o incremento da qualidade do produto, melhorias da compreenso humana e comunicao, apoio ao processo de melhoria, apoio aos processos de gesto, orientao aos processos automatizados, e providenciando a execuo de suporte automatizado. Os tipos de definies exigidas no processo dependero, pelo menos parcialmente, do motivo da definio. Tambm importa notar que o contexto do projeto e da organizao iro determinar a definio do tipo de processo que mais til. Variveis importantes a considerar incluem a natureza do trabalho (por exemplo, a manuteno ou desenvolvimento), o domnio da aplicao, o modelo do ciclo de vida, e da maturidade da organizao. a) Modelos de Ciclo de Vida de Software Os modelos de Ciclo de vida de software servem como um alto nvel de definio das fases que ocorrem durante o desenvolvimento. Eles no so destinados a fornecer definies pormenorizadas, mas em destacar as principais atividades e suas interdependncias. Exemplos de modelos de ciclo de vida software so os modelo cascata, o modelo prototipagem descartvel, desenvolvimento evolucionrio, entrega incremental/iterativo, o modelo espiral, o modelo de software

153

reutilizvel, e uma sntese automatizado de software. A comparao destes modelos fornecidos em [Com97], (Dav88), e um mtodo de seleo dentre eles em (Ale91). b) Ciclo de vida do processo de software Definies do ciclo de vida de processos software tendem a ser mais detalhados do que os modelos ciclo de vida de software. No entanto, processos de ciclo de vida de software no devem tentar ordenar o seu processo em tempo til. Isto significa que, em princpio, o ciclo de vida do processo software pode ser disposto para caber em qualquer dos modelos de ciclo de vida do software. A principal referncia nesta rea IEEE / EIA 12207,0: Tecnologia da Informao Software Life Cycle Processes [IEEE 12207.0-96]. O padro IEEE 1074:1997 de desenvolvimento de processos de ciclo de vida tambm fornece uma lista de processos e atividades de desenvolvimento e manuteno de software [IEEE1074-97], bem como uma lista de atividades do ciclo de vida que possam ser mapeadas em processos e organizadas no mesmo de modo que todos os modelos de ciclo de vida do software. Alm disso, identifica outros padres de software ligados ao IEEE para estas atividades. Em princpio, IEEE Std 1074 pode ser usada para construir processos em conformidade com qualquer dos modelos de ciclo de vida. Normas que se concentram nos processos de manuteno so IEEE Std 1219-1998 e ISO 14764: 1998 [IEEE 1219-98]. Outros padres importantes que fornecem a definies de processo incluem: IEEE Std 1540: Software Risk Management (IEEE1540-01) IEEE Std 1517: Software Reuse Processes (IEEE 1517-99) ISO/IEC 15939: Software Measurement Process [ISO15939-02]. Veja tambm o gerenciamento de engenharia de software KA para a descrio detalhada deste processo. Em algumas situaes, processos de engenharia de software devem ser definidos tendo em conta os processos organizacionais de gesto da qualidade. ISO 9001 [ISO9001-00] provem requisitos para gerenciamento de processos da qualidade, e ISO/IEC 90003 que interpretam esses requisitos para as organizaes de desenvolvimento de software (ISO90003-04). Alguns ciclos de vida de softwares enfatizam processos de entrega rpida e forte participao dos usurios, chamados de mtodos geis, como Extreme

154

Programming (Bec99]. Uma forma do problema da seleo diz respeito escolha, ao longo do plano de direo do mtodo base Uma abordagem de risco de como tomar essa deciso descrito em (Boe03a). c) Notaes pra definio de processos Este processo pode ser definido em diferentes nveis de abstrao (por exemplo, definies genricas vs definies adaptadas, descritiva vs prescritivo vs proscritiva) [Pfl01]. Vrios elementos de um processo podem ser definidos, por exemplo, atividades, produtos (artefatos), e os recursos. Quadros detalhados que estruturam os tipos de informaes necessrias para definir os processos so descritos em (Mad94). H uma srie de anotaes sendo utilizadas para definir processos (SPC92). A grande diferena entre eles est no tipo de informaes dos quadros mencionados acima definem, capturam e usam. O engenheiro de software deve estar ciente das seguintes abordagens: diagramas de fluxo de dados, em termos de processo objetivo e os resultados [ISO15504-98], como uma lista dos processos constituintes decomposto em atividades e tarefas definidas na linguagem natural [IEEE12207.096] , Esfatechar (Har98), ETVX (Rad85), modelagem Ator Dependncia (Yu94), SADT notao (Mcg93), redes de Petri (Ban95); IDEFO (IEEE 1320.1-98), e a regra de base (Bar95). Mais recentemente, um padro de modelagem de processo foi publicado pela OMG, que visa harmonizar notaes de modelagem. Isto denominado o SPEM (Software Engineering Process Meta-Model) especificao. [OMG02]. d) Processo de Adaptao importante notar que, mesmo processos predefinidos mais usados devem ser adaptados s necessidades locais, por exemplo, um contexto organizacional, a dimenso dos projetos, requisitos regulamentar, prticas da indstria, e cultura das organizaes. Alguns padres, como o IEEE / EIA 12207, contm mecanismos e recomendaes para a realizao das adaptaes.

155

e) Automao Cada ferramenta automatizadas da suporte a execuo da definies do processo ou fornecem orientaes para os indivduos exercerem processos definidos. Nos casos onde processo de anlise realizado, algumas ferramentas permitem diferentes tipos de simulaes (por exemplo, a simulao eventos discretos). Alm disso, h ferramentas que suportam cada um dos referidos processo de definio notaes. Essas ferramentas podem executar o processo automatizado de fornecer suporte as definies dos processos reais, ou automatizar totalmente em alguns casos. Uma viso geral das ferramentas de modelagem de processos pode ser encontrada em [Fin94] e do centro de processo de ambientao em (Gar96). Trabalho, sobre a aplicao da Internet para a proviso de orientao do processo em tempo real est descrito em (Kel98).

2.1.3.8.3 Avaliao de Processo Processo de avaliao realizada utilizando tanto uma modelo de avaliao ou um mtodo de avaliao. Em alguns casos, o termo "avaliao" usado no lugar de avaliao, bem como o prazo "Capacidade de avaliao" utilizada quando a avaliao para os efeitos da adjudicao de um contrato. a) Modelos de Avaliao de Processos O modelo de avaliao de processos utiliza o que reconhecido como boas prticas. Essas prticas podem dizer respeito somente a atividades de tcnicas de engenharia software, ou podem tambm referir-se, por exemplo, gesto, engenharia de sistemas, e humanos bem como as atividade de gerenciamento dos recursos. ISO / IEC 15504 [ISO15504-98] define um modelo de avaliao exemplo e sobre outras exigncias conforme modelo de avaliao. Modelos especficos de avaliao disponvel e em uso so SW-CMM (SEI95), CMMI [SEI01], e Bootstrap [Sti99]. Capacidade de maturidade e de muitos outros modelos tm sido definidas, por exemplo, para a concepo, documentao, e mtodos formais, para citar apenas alguns. ISO 9001 outro modelo de avaliao comum, que tem sido aplicado por organizaes de software (ISO9001-00).

156

Um modelo de maturidade para a engenharia de sistemas tambm tem sido desenvolvidos, o que seria mais til quando um projeto ou organizao est envolvida no desenvolvimento e manuteno de sistemas, incluindo software (EIA/IS731- 99). A aplicabilidade dos modelos para avaliao pequenas organizaes abordado em [Joh99; San98]. Existem duas arquiteturas para uma avaliao geral modelo que faz diferentes suposies sobre a ordem em que processos devem ser avaliados: contnua e por fases (Pau94). Eles so muito diferentes, e devem ser avaliadas pela organizao considerando-as para determinar qual seriam as mais apropriada para as suas necessidades e objetivos. b) Mtodos de avaliao de processos A fim de realizar uma avaliao, um mtodo avaliao especfica deve ser seguido para produzir uma Pontuao quantitativa que caracteriza a potencialidade do processo (ou maturidade da organizao). O mtodo de avaliao CBA-IPI, por exemplo, concentra-se em processo de melhoria (Dun96), o mtodo SCE centra-se em avaliar as capacidades dos fornecedores (Bar95). Ambos foram desenvolvidos pelo SW-CMM. Ambos os tipos de mtodos de requisitos refletem o que se acredita ser boas prticas de avaliao esto previstas em [ISO15504-98], (Mas95). Os mtodos scampi so orientadas pela avaliaes CMMI [SEI01]. As atividades realizadas durante uma avaliao, so a distribuio do esforo sobre estas atividades, bem como a atmosfera durante um avaliao so diferentes quando so para a melhoria do que para uma juno. Tem havido crticas aos modelos de avaliao de processo e mtodos, por exemplo (Fay97; Gra98). A maioria dessas crticas tm se preocupado com as evidncias empricas que do suporte utilizao de modelos e mtodos de avaliao. No entanto, desde a publicao desses artigos, verificaram-se de forma sistemtica alguns elementos que sustentavam a eficcia dos processos de avaliao. (Cla97; Ele00; Ele00a; Kri99) 2.1.3.8.4 Processo e Medio de Produto Embora a aplicao de medio da engenharia de software pode ser complexa, particularmente em termos de modelagem e anlise de mtodos, existem

157

vrios aspectos de engenharia de medio de software, que so fundamentais e que so a base de muitos dos mais avanados processos de medio e anlise. Alm disso, a realizao do processo e os esforos para a melhoria dos produtos s pode ser avaliado se um conjunto de medidas de base tiver sido estabelecido. A medio pode ser executada para apoiar a iniciao ou para avaliar as consequncias da implementao de processo. E tambm, esta medio pode ser executa no prprio produto. Conceitos fundamentais sobre medidas de software e mtodos de medio foram definidos na norma ISO / IEC 15939, com base nas ISO vocabulrio internacional de metrologia. ISO / IEC 15359 tambm fornece um processo padro de medir tanto os processos quanto as caractersticas de produto. [VIM93] No entanto, os leitores vo encontrar termos divergentes na literatura, por exemplo, o termo "mtrica" s vezes usado no lugar de "medir". a) Processo de Medio O termo "processo de medio", conforme usado aqui significa que informaes quantitativas sobre o processo so recolhidas, analisadas, e interpretadas. A medio utilizada para identificar os pontos fortes e fracos dos processos e para avali-los depois que eles foram implementados e/ou modificados. O processo de medio pode servir a outros objetivos tambm. Por exemplo, til para gerenciar um projeto de engenharia de software. Aqui, o foco est no processo de medio e o objetivo na implementao e modificao de processo. O contexto afeta o relacionamento entre os processos e os resultados de processos. Isto significa que esta relao processo a processo, depende do contexto do relacionamento. Nem todo processo ter um impacto positivo em todos os resultados. Por exemplo, a introduo de software pode reduzir os ensaios de esforo e custo, mas pode aumentar o tempo decorrido, se em cada inspeo introduzir atrasos devido programao de inspeo de grandes reunies. (Vot93) Portanto, prefervel utilizar mltiplos resultados de processos que so importantes para o negcio da organizao. Embora algum esforo pode ser feito para avaliar o aproveitamento das ferramentas, o principal recurso que deve ser geridos em engenharia de software o

158

pessoal. Contudo, as principais medidas de interesse so aquelas relacionadas produtividade de equipes ou de processos (por exemplo, usando a medida de pontos de funo produzidos por unidade de personeffort) e seus respectivos nveis de experincia em engenharia de software em geral e tambm nas tecnologias. Os resultados de processo, por exemplo, podem ser qualidade do produto (faltas por KLOC (Kilo Lines of Code) ou por (PF) Function Point ), manutenibilidade (o esforo para fazer um certo tipo de modificao), produtividade (LOC (Lines of Code) ou Pontos de Funo por ms de pessoa time-to-market, ou satisfao de cliente (medido atravs de um cliente). Esta relao depende do contexto particular (por exemplo, o tamanho da organizao ou o tamanho do projeto). Em geral, estamos mais preocupados com os resultados do processo. No entanto, para alcanar os resultados de processo que ns desejamos (por exemplo, uma melhor qualidade, maior durabilidade, uma maior satisfao dos clientes), temos de aplicar os processos adequados. Evidentemente, no apenas o processo que tem um impacto sobre os resultados. Outros fatores, tais como a capacidade do pessoal e as ferramentas que so utilizadas, desempenham um papel importante. Quando avaliar o impacto de um processo de mudana, por exemplo, importante observar outras influncias. Alm disso, medida em que o processo for institucionalizado (isto , processo de fidelidade) importante, pois isso pode explicar porque "bom" processos no darem sempre os resultados esperados em um determinada situao.

159

Figura 24: Relao entre processos e resultados

Medio de tamanho. O tamanho do produto de software mais frequentemente avaliado por medidas de tamanho (por exemplo, linhas de cdigo fonte em um mdulo, pginas em um documento de especificao de requisitos de software), ou funcionalidade (por exemplo, pontos em uma funo especfica). Os princpios do tamanho da funcional , so fornecidos em IEEE Std 14143,1. Padres internacionais para medir tamanho que incluem os mtodos da funcional ISO / IEC 19761, 20926, 20968 e [IEEE 14143.1-00; ISO19761-03; ISO20926-03; ISO2096802]. Medio de estrutura. Uma variada gama de medidas de estrutura de produtos de software pode ser aplicada para alto e baixo nvel de design e artefatos de cdigo para refletir no fluxo de controle (por exemplo o cyclomatic, nmero, ns de cdigo), fluxo de dados (por exemplo, medidas de corte), otimizao (por exemplo, a medida polinomial, a medida BAND), o controlo das estruturas (por exemplo, a medida vetorial, a medida NPATH), estrutura modular e interao (por exemplo, informaes de fluxo, com base em medidas de rvore, acoplamento e coeso). [Fen98: C8; Pre04: C15]. Medio de qualidade. Como um atributo multidimensional, medio da qualidade mais difcil de definir do que as anteriores. Alm disso, algumas das dimenses da qualidade exigem a medio em termos qualitativos, e no de forma quantitativa. Uma discusso mais detalhada de mensurao do software fornecida em Qualidade do Software KA, tema 3.4. ISO modelos de qualidade de software e medies relacionadas esto descritas na norma ISO 9126, partes 1 de 4 [ISO912601]. [Fen98: c9,c10; Pre04: c15; Som05: c24]. b)Qualidade dos resultados das medies A qualidade dos resultados da medio (preciso, reproduo, repetio, converso, erros de medio) essencial para a medio de programas para proporcionar resultados eficazes e delimitados. As caractersticas chaves dos instrumentos de medio para garantir resultados de medio e qualidade foram definidas na norma ISO Vocabulrio internacional sobre metrologia. [VIM93]. A teoria de medio estabelece a base sobre a forma que as medies podem ser feitas. Esta teoria e tipos de escala so discutidas [em Kan02]. A medio definida

160

na teoria como "a atribuio de nmeros para os objetos de uma forma sistemtica de representar propriedades do objeto. " Uma avaliao da medio de software e as implicaes de cada tipo de escala em relao sua seleo posterior de mtodos de anlise de dados especialmente importante. [Abr96; Fen98: c2; Pfl01: C11] Escalas significativas so relacionada em uma classificao de escalas. A teoria da medio fornece cada vez mais formas de como realizar as medidas. Se os nmeros atribudos so apenas para fornecer etiquetas para classificar os objetos, eles so denominados como nominal. Se eles forem atribudos de uma forma que classifica os objetos (por exemplo, bom, melhor), eles so chamados como ordinais. Se eles lidam com as magnitudes de propriedade em relao a uma unidade de medio definida, eles so chamados como intervalo (e os intervalos so uniformes entre os nmeros, a menos que de outra maneira no esto especificado, e so, portanto aditivo). As medies esto em nvel de proporo se tiverem um nvel absoluto ponto zero, portanto nveis de distncias para o ponto zero so significativos. c) Modelos de Informao sobre Software Como os dados so reunidos e o repositrio de medio preenchido, nos ajudam a construir modelos de dados utilizando o conhecimento e os dados no repositrio. Estes modelos existentes para fins de anlise, classificao e previso. Tais modelos tm de ser avaliados para assegurar que os seus nveis de preciso so suficientes e que as suas limitaes so conhecidas e entendidas. O refinamento de modelos, que se realiza durante e aps os projetos so concludos, esta outra atividade importante. Modelo de construo. Modelo de construo inclui ajustes e avaliao do modelo. A meta abordagem orientada para a medio do modelo de processo de construo, na medida em que modelos so construdos para responder a perguntas pertinentes e atingir objetivos na melhoria de software. Este processo tambm influenciado pelas limitaes implcitas de medio em escalas com relao escolha de mtodos de anlise . Os modelos so ajustados (usando particularmente observaes pertinentes, por exemplo, os projetos recentes utilizam a mesma tecnologia) e sua eficcia avaliada (por exemplo, pelo seu desempenho em testes e amostras). [Fen98: C4, C6, C13; Pfl01: c3, C11, C12; Som05: C25]

161

Modelo de implementao. Modelo de implementao inclui interpretao e refinamento de modelos. Os modelos ajustados so aplicados no processo, os seus resultados so interpretados e avaliados no contexto do processo / projeto, e os modelos so ento refinados, quando necessrio. [Fen98: c6; Pfl01: c3, C11, C12; Pre04: C22; Som05: C25] d)Tcnicas de Medio de Processo Tcnicas de medio podem ser utilizadas para a anlise da engenharia de processos de software e para identificar pontos fortes e fracos. Isto pode ser realizado para iniciar a implementao e mudana do processo, ou para avaliar as consequncias desta implementao e mudana. A qualidade dos resultados de medio, como a preciso, repetio e reprodutibilidade, so as questes que no so usadas medidas de processos de engenharia de software, so instrumentos baseados em medies como, por exemplo, quando os assessores destinam uma grande quantidade para um determinado processo. Uma discusso sobre mtodos para atingir qualidade de medio so apresentados em [Gol99]. As tcnicas de medio de processo foram classificadas em dois tipos gerais: analtica e anlise comparativa. Os dois tipos de tcnicas podem ser usados em conjunto, porm, so baseado em tipos diferentes de informao. (Car91) Tcnicas analticas. As tcnicas analticas so caracterizadas como: "elementos quantitativos para determinar onde melhorias so necessrias e se uma iniciativa de melhora foi bem-sucedida. O tipo analtico exemplificado pela Quality Improvement Paradigm (QIP) constitudo por um ciclo da compreenso, da avaliao, e de embalagens [SEL96]. As tcnicas apresentadas a seguir, se destinam a outros exemplos de tcnicas analticas, e refletem o que feito na prtica. [Fen98; Mus99], (Lyu96; Wei93; Zel98). Organizaes especficas usam estas tcnicas, pelo menos parcialmente, na sua maturidade. Estudos experimentais: Experimentao envolve criao de experimentos controlados na organizao para avaliar processos. (McG94) Geralmente, um novo processo comparado com o atual e determina se o antigo tem um melhor andamento. Outro tipo de estudo experimental o processo de simulao. Este tipo de

162

estudo pode ser utilizado para a anlise do processo de comportamento, explorar a melhoria de processos, predizer se o atual processo foi alterado e controlar os processos em execuo. Dados iniciais sobre o desempenho do atual processo necessitam ser recolhidos, contudo, como uma base para a simulao. Definio de Reviso de Processos: um meio pelo qual um processo de definio (descritivo, prescritivo ou ambos) revisto, e as eficincias e melhorias do processo so identificadas. Os exemplos tpicos disto so apresentados em (Ban95; Kel98). Uma maneira fcil para analisar um processo compar-lo com um padro existente (nacional, internacional, ou um organismo profissional), tais como IEEE / EIA 12207,0 [IEEE12207.0-96]. Com esta abordagem, dados quantitativos no so reunidos no processo, caso sejam, desempenham um papel de suporte. Os indivduos realizando a anlise da definio do processo usam seus conhecimentos e capacidades para decidir sobre as mudanas necessrias para o resultado do processo. Estudos de observao tambm podem fornecer feedback til para a identificao de melhorias no processo. (Agr99) Classificao de Defeito Ortogonal: uma tcnica que pode ser utilizada para interligar faltas encontradas com causas potenciais. Baseia-se em um mapeamento entre os tipos de falhas e erros. (Chi92; Chi96) A norma IEEE sobre a classificao de falhas (ou anomalias) pode ser til neste contexto (IEEE Standard da classificao das Anomalias Software (IEEE1044-93). Controle de Estatstica do Processo: um meio eficaz para identificar a estabilidade, ou a falta dela, atravs da utilizao de grficos e controle das interpretaes. Uma boa introduo para o SPC em contexto de engenharia de software apresentado em (Flo99). Processo de Software Pessoal: define uma srie de melhorias para o desenvolvimento de prticas em uma determinada ordem [Hum95]. "bottom-up" no sentido em que prev a recolha de dados pessoais e melhorias baseadas em interpretaes dos dados. Tcnicas de teste de desempenho de um sistema. O segundo tipo de teste de desempenho de um sistema, "depende da identificao de uma organizao 'excelente' em um campo e documentao das suas prticas e instrumentos.Teste

163

de desempenho de um sistema assume isto: se a organizao proficiente adotar as prticas da organizao excelente, esta tambm ira se tornar excelente. Teste de desempenho de um sistema implica avaliar a maturidade de uma organizao ou a capacidade de seus processos. Ele exemplificado pelo processo de avaliao de software. Uma viso geral do processo de avaliao e sua aplicao est prevista no (Zah98). 2.1.3.9 Ferramentas e Mtodos da Engenharia de Software Ferramentas de desenvolvimento de software so as que se destinam a ajudar nos processos de ciclo de vida do software. As ferramentas permitem, repetir e definir aes automatizadas, reduzindo a carga cognitiva sobre a engenharia de software, deixando-o livre para concentrar-se na criatividade e aspectos do processo. As ferramentas so muitas vezes concebidas para apoiar em particular os mtodos da engenharia de software, reduzindo qualquer carga administrativa associada a mtodos aplicados manualmente. Como os mtodos de engenharia so destinados a tornar a engenharia de software mais sistemtica, eles variam o escopo para suportar tarefas individuais englobando um ciclo de vida completo. Os mtodos da engenharia de software impem na sua estrutura metas de fabricao e atividades sistemticas com a finalidade de se ter uma maior probabilidade de sucesso. Os mtodos normalmente fornecem notaes e vocabulrios, para o procedimento de tarefas identificveis e orientaes para verificar o processo e o produto. Eles variam amplamente no escopo para uma simples e completa fase do ciclo de vida. A nfase nesta KA (Knowledge Area - rea de Conhecimento), esta nos mtodos da engenharia de software englobando vrias fases do ciclo de vida, desde a fase de especificao at os mtodos cobertos por outras KAs. Embora existam manuais detalhados, ferramentas especficas e numerosos trabalhos de investigaes em relao a ferramentas inovadoras, tcnicas genricas, de escrita de ferramentas de software so relativamente escassas. Uma das dificuldades a elevada taxa de mudana nas ferramentas de software em geral. Detalhes especficos so alterados regularmente. A engenharia de software ferramentas e mtodos KA cobre todos os processos de

164

um ciclo de vida, e portanto, relacionada para toda KA neste guia.

Figura 25: Tpicos da KA Ferramentas e Mtodos da Engenharia de Software

2.1.3.9.1 Ferramentas da Engenharia de Software Os cinco primeiros tpicos nas subreas das Ferramentas de Engenharia de Software, correspondem aos cinco primeiros KAs deste Guia (Requisitos de Software, Design de Software, Construo de Software, Teste de Software e Manuteno de Software). Os prximos quatro tpicos restantes correspondem as KAs (Gesto de Configurao de Software, Gesto de Engenharia de Software, Processos de Engenharia de Software e Qualidade do Software). Um outro tpico adicional dirige-se a diversas reas, contanto que sejam semelhantes e abordadas como ferramenta de integrao tcnicas que so potencialmente aplicveis a todas as classes de ferramentas.

165

a) Ferramentas de Requisitos de Software As ferramentas para tratar os requisitos de softwares foram classificadas em duas categorias: ferramentas de modelagem e ferramentas de rastreabilidade. Ferramentas de requisitos de modelagem. Estas ferramentas so usadas para obteno, anlise, especificao e validao de requisitos de software.

Ferramentas de requisitos de rastreabilidade. [Dor02] Estas ferramentas esto crescendo e se tornando cada vez mais importantes na medida que cresce a complexabilidade do software. Desde que sejam tambm relevantes em outros processos de ciclo de vida, eles so apresentados separadamente dos requisitos de ferramentas de modelagem.

b) Ferramentas de Design de Software Este tpico refere-se s ferramentas para criao e verificao de projetos de softwares. Existe uma variedade destas ferramentas, consequentemente uma diversidade de notaes e mtodos de projeto de softwares. Apesar de existir toda esta variedade, no foi encontrado divises para este tpico. c) Ferramentas de Construo de Software Este tpico refere-se s ferramentas de construo de software. Estas ferramentas so usadas para produo e traduo da representao de um programa (por exemplo, cdigo fonte) que suficientemente detalhado e desenvolvido para permitir a execuo na mquina. Editores de programas. Estas ferramentas so usadas para a criao e modificao de programas, e possivelmente os documentos associados a eles. Eles podem ser editores de textos ou documentos de uso geral, ou podem ser editores especficos para uma determinada linguagem. Compiladores e Geradores de Cdigo. Tradicionalmente os compiladores no eram tradutores interativos de cdigo fonte, mas houve uma tendncia em integrar compiladores e programas de edio, para se ter ambientes de programao integrados. Este tpico tambm referencia processadores, linker/loaders, e geradores de cdigo. Interpretadores estas ferramentas fornecem execuo de software atravs de emulao. Elas podem apoiar as atividades de construo de softwares,

166

fornecendo um ambiente mais controlvel e observvel para a execuo de programas. Depuradores. Estas ferramentas so consideradas uma categoria separada, desde que elas deem apoio aos processos de construo de software, mas elas so diferentes dos programas de edio e dos compiladores. d) Ferramentas de Teste de Software Geradores de teste. Estas ferramentas auxiliam no desenvolvimento de casos de testes. Execuo de testes por etapas. Estas ferramentas permitem a execuo de casos de teste em um ambiente controlado onde o comportamento do objeto que est sendo testado observado. Ferramentas de avaliao de teste. Estas ferramentas suportam a avaliao dos resultados dos testes de desempenho, ajudando a determinar se o comportamento observado est de acordo com o comportamento previsto. Ferramentas de Gerenciamento de Teste. Estas ferramentas fornecem suporte para todos os aspectos do processo de testes de software.

Ferramentas de Anlise e desempenho. [Rei96] Estas ferramentas so usadas para medir e analisar o desempenho do software, que uma forma especializada de ensaios onde o objetivo avaliar o comportamento da operao e no o comportamento funcional (correo).

e) Ferramentas de Manuteno de Softwares Este tpico refere-se s ferramentas que so particularmente importantes na manuteno de software existentes e que necessitem de modificaes. So identificadas duas categorias: ferramentas de compreenso e ferramentas de reengenharia. Ferramentas de compreenso. [Re196] Estas ferramentas ajudam na compreenso humana de programas. Os exemplos incluem ferramentas de visualizao e partes animadas de programas. Ferramentas de reengenharia. Na KA manuteno de software definido como a investigao e alterao do software, ficando-o sujeito a construo de uma nova forma, incluindo implementaes subsequentes desta nova

167

forma. As ferramentas de reengenharia suportam essas atividades. Ferramentas de engenharia reversa auxiliam o processo de trabalho a criar artefatos de um produto j existente, como especificao e descries de desenhos, que podem ento ser transformados para gerar um novo produto a partir de um antigo. f) Ferramentas de Gerenciamento de Configurao de Software As ferramentas para gerenciar configurao de Software foram divididas em trs categorias: monitoramento, gerenciamento de verses e ferramentas de correo. Ferramentas para gerenciar defeito, aprimoramento, edio e monitoramento. Estas ferramentas so usadas na conexo com o monitoramento de problemas associados a um determinado produto de software. Ferramentas para gerenciar verses. Estas ferramentas esto envolvidas na gesto das vrias verses de um produto. Ferramentas de correo. Estas ferramentas so usadas para obter uma tarefa de correo e desenvolvimento de software. A categoria inclui instalao de ferramentas que se tornaram amplamente utilizadas para configurar a instalao de produtos de software. Informaes adicionais so fornecidas em Configurao e Gerenciamento de Software KA, tpico 1.3 planejamento para SCM. g) Ferramentas de gerenciamento de Engenharia de Software Ferramentas de gerenciamento de engenharia de software so subdivididas em trs categorias: planejamento e acompanhamento de projeto, gerenciamento de risco e medio. Ferramentas de planejamento e acompanhamento de projeto. Estas ferramentas de software so usadas para medir esforos e estimar custos no projeto, bem como a sincronizao de projetos. Ferramentas de gerenciamento de riscos. Estas ferramentas so usadas na identificao, estimativa e monitoramento de riscos. Ferramentas de Medio. As ferramentas de medio auxiliam na performance de atividades relacionadas na mensurao dos programas.

168

h) Ferramentas para Mtodos de Engenharia de Software Ferramentas para mtodos de engenharia de software so divididas em ferramentas de modelagem, ferramentas de gerenciamento e ambiente de desenvolvimento de software. Ferramentas para mtodos de modelagem. [Pf101] Estas ferramentas so usadas para modelar e verificar o processo de engenharia de software. Ferramentas para mtodos de gerenciamento. Estas ferramentas fornecem suporte para o gerenciar a engenharia de software. Ambiente CASE integrado. [Rei96, Som05] (ECMA55-93, ECMA69-94, IEEE1209-92, IEEE1348-95, Mul96) Engenharia de software integrada com ferramentas auxiliadas por computador ou ambientes que abrangem mltiplas fases do ciclo de vida da engenharia de software fazem parte deste sub tpico. Tais ferramentas desempenham mltiplas funes e, portanto, interagem potencialmente com o ciclo de vida a ser executado pelo processo de software. Ambiente centrado no processo de engenharia de software. [Rei96] (Gar96) estes ambientes incorporam explicitamente informaes no processo do ciclo de vida do software e orientam o monitoramento do usurio de acordo com os processo definidos. i) Ferramentas de Qualidade do Software Ferramentas de qualidade so divididas em duas categorias: verificao e anlise de ferramentas. Ferramentas de auditoria e anlise. Estas ferramentas so usadas para auxiliar na anlise e auditorias. Ferramentas de anlise esttica. [Cla96, Pfl01, Rei96] estas ferramentas so usadas para analisar artefatos de software, tais como anlises sinttica e semntica, bem como dados, controle de fluxo e anlise de dependncias. Essas ferramentas so destinadas para verificar artefatos de softwares de modo analisar conformidade ou para verificao das propriedades desejadas. j) Ferramentas para Problemas Variados Este tpico abrange assuntos aplicveis para todas as classes de

169

ferramentas. Existem trs categorias bem identificadas: ferramentas de integrao tcnica, meta ferramentas e ferramentas de evoluo. Ferramentas de integrao tcnica. [Pfl01, Rei96, Som01] (Bro94) Ferramentas de integrao so importantes para estruturar pessoas a ferramentas. Esta categoria potencialmente sobrepe com a integrao da categoria do ambiente CASE onde so aplicadas integraes tcnicas; no entanto elas so suficientemente distintas para merecer sua prpria categoria. So os modelos tpicos de ferramentas de integrao, plataformas, apresentao, processo, dados e controles. Metas ferramentas. Metas ferramentas geram outras ferramentas; um exemplo clssico compilar um cdigo / compiladores. Ferramentas de evoluo [Pfl01] (IEEE1209-92, IEEE1348-95, Mos92, Val97) Por causa da contnua evoluo da engenharia de software, ferramentas de evoluo um tpico essencial. 2.1.3.9.2 Mtodos de Engenharia de Software As sub reas dos Mtodos da Engenharia de Software so divididas em trs tpicos: relacionamento de mtodos heursticos com abordagens informais, relacionamento de mtodo formal com abordagens matematicamente baseadas e relacionamento de mtodos de prototipagem com abordagens em engenharia de software baseada em diferentes formas de prottipo. Estes trs tpicos no so separados em partes; particularmente eles representam interesses distintos. Por exemplo um objeto orientado a mtodos pode incorporar tcnicas formais e contar com um prottipo de verificao e validao. Tal como ferramentas de engenharia de software, so desenvolvidas tecnologias continuamente. Consequentemente a KA evita descrever na medida que possvel nomear metodologias particulares. a) Mtodos Heursticos Este tpico contm quatro categorias: Estruturado, orientado a dados, orientado a objetos e domnio especifico. A categoria domnio especfico inclui mtodos especializados para desenvolvimento de sistemas o qual envolve tempo real, segurana ou aspectos seguros. Mtodos estruturados [Dor02, Pfl01, Pre04, Som05] O sistema embutido

170

para um ponto de vista funcional, iniciando com uma viso de alto nvel e refinado progressivamente em um projeto mais detalhado. Mtodos orientados a dados. [Dor02, Pre04] aqui o ponto inicial so os dados estruturados que um programa manipula melhor do que a funo que executa. Mtodos orientados a objeto. [Dor02, Pfl01, Pre04, Som05] O sistema visualizado como uma coleo de objetos, em vez de funes. b) Mtodos Formais Esta subseo dividida matematicamente com mtodos de engenharia de software, e esta subdividida com os vrios aspectos de mtodos formais. Especificao de linguagens e notaes. [Cla96, Pfl01, Pre01] Este tpico foca a especificao de notao ou de linguagem usada. Linguagens de especificaes podem ser classificadas como orientado a modelo, orientado por propriedade ou orientado por comportamento. Refinamento. [Pre04] Este tpico d a forma de como o mtodo refinado (ou transformado) numa especificao de forma que seja mais prxima da forma final desejada de um programa executvel. Propriedades de verificao/confirmao [Cla96, Pfl01,Som05] Este tpico trata as propriedades de verificao que so especificas as abordagens formais, incluindo tanto o modelo de teoria como o modelo de verificao. c) Mtodos de Prototipagem Esta subseo abrange mtodos que envolvem a prototipagem de software e subdividida em estilos de prototipagem, metas e avaliaes tcnicas. Estilo de prototipagem. [Dor02, Pfl01, Pre04] (Pom96) O tpico estilo de prototipagem identifica as vrias abordagens: rejeitada, evolutiva e especificao executvel. Os objetivos de um mtodo de prototipagem podem ser os requisitos de desenho de arquitetura, ou interface do usurio. Avaliaes tcnicas de prototipagem. Este tpico abrange as maneiras pelas quais os resultados de um treinamento de prototipagem so usados.

171

2.1.3.10 Qualidade de Software O que qualidade de software, e por que to importante que este assunto faa parte do Guia SWEBOK? Durante anos, autores e organizaes tm definido "qualidade" de formas diferentes. Para Phil Crosby (Cro79), a melhor definio era "conformidade com os requisitos do usurio. Watts Humphrey (Hum89) refere-se ao termo como alcanar excelentes nveis de adequao para uso, enquanto a IBM cunhou a frase Qualidade dirigida pelo mercado que est baseada em alcanar a satisfao total do cliente. O critrio Baldrige para qualidade organizacional (NIST03) utiliza uma frase semelhante, Qualidade dirigida pelo cliente. Mais recentemente, qualidade foi definida na (ISO9001-00) como "o grau com o qual um conjunto de caractersticas intrnsecas cumpre requisitos". Este captulo trata das consideraes da qualidade de software que transcendem os processos do ciclo de vida. Qualidade de software uma questo onipresente na engenharia de software, e por isso tambm considerada em muitas das KAs. Em resumo, o Guia SWEBOK descreve vrios modos de alcanar qualidade de software. Em particular, esta KA cobrir tcnicas estticas, aquelas que no requerem a execuo do software sendo avaliado, enquanto tcnicas dinmicas so cobertas na KA Teste de Software.

Figura 26: Tpicos para a KA Qualidade de Software

172

2.1.3.10.1 Fundamentos da Qualidade de Software O entendimento dos requisitos de qualidade, bem como a clara comunicao com o engenheiro de software no que constitui qualidade, requer que vrios aspectos sejam formalmente definidos e discutidos. Um engenheiro de software deve entender os significados bsicos dos conceitos e caractersticas da qualidade e seus valores para o produto em desenvolvimento ou manuteno. O conceito fundamental o de que requisitos de software definem as caractersticas necessrias de qualidade e influenciam os mtodos de medida e critrios de aceitao na avaliao de tais caractersticas. a) Cultura e tica da Engenharia de Software Espera-se que os engenheiros de software compartilhem um compromisso com qualidade de software como parte de sua cultura. Uma robusta cultura de engenharia de software descrita em [Wie96]. A tica pode desempenhar um papel significante na qualidade de software, na cultura e nas atitudes dos engenheiros de software. O IEEE Computer Society e a ACM [IEEE99] desenvolveram um cdigo de tica e prticas profissionais baseada em oito princpios para ajudar os engenheiros de software a reforar atitudes relacionadas qualidade e independncia do seu trabalho. b) Valor e Custo da Qualidade A noo de "qualidade" no to simples quanto pode parecer. Para qualquer produto desenvolvido, existem vrias qualidades desejadas relevantes para determinadas perspectivas do produto, que devem ser discutidas e determinadas durante a definio dos requisitos. Caractersticas de qualidade podem ser requeridas ou no, podem ser requeridas em maior ou menor grau, e ainda podem existir trade-offs entre elas. [Pfl01]. O custo da qualidade pode ser diferenciado em custo de preveno, custo de avaliao, custo de fracasso interno e custo de fracasso externo. [Hou99]. A motivao por trs de um projeto de software o desejo de se criar um software que tenha valor, e este valor pode ou no pode ser quantificado como um custo. O cliente ter algum custo mximo em mente, em troca do qual se espera que o propsito bsico do software seja cumprido. O cliente tambm pode ter alguma

173

expectativa sobre a qualidade do software. s vezes clientes podem no ter pensado nas questes de qualidade ou nos custos relacionados a ela. A caracterstica meramente decorativa ou essencial ao software? Se a resposta se encontra em algum ponto entre as duas opes, como quase sempre o caso, importante que o cliente faa parte do processo de deciso, e esteja completamente a par dos custos e benefcios. O ideal que a maioria destas decises seja feita no processo de definio de requisitos do software (veja a KA Requisitos de Software), mas estas questes tambm podem surgir ao longo do ciclo de vida do software. No h nenhuma regra definida para como estas decises devem ser tomadas, mas o engenheiro de software deve apresentar as alternativas de qualidade e os seus custos. Uma discusso relativa ao custo e ao valor dos requisitos de qualidade pode ser encontrada em Wei96:c11. c) Modelos e Caractersticas da Qualidade A terminologia para caractersticas de qualidade de software diferem entre os modelos, podendo haver diferenas entre o nmero de nveis de hierarquia e a quantidade total de caractersticas. Vrios autores produziram modelos de caractersticas de qualidade de software ou atributos que podem ser teis para discusso, planejamento e avaliao da qualidade dos produtos de software. [Boe78; McC77] A ISO/IEC definiu trs modelos relacionados de qualidade de produtos de software (qualidade interna, qualidade externa e qualidade em uso) (ISO9126 -01) e um conjunto de partes relacionadas (ISO14598 -98). O gerenciamento de qualidade de software e a qualidade dos processos de engenharia de software tm um grande impacto na qualidade final do produto. Modelos e critrios que avaliam as capacidades das organizaes de software so, principalmente, organizao de projeto e consideraes de gerenciamento, e, como tais, esto cobertos nas KAs Gerncia de Engenharia de Software e Processo de Engenharia de Software. Evidentemente, no possvel distinguir completamente a qualidade do processo da qualidade do produto. Qualidade de Processo, discutida na KA Processo de Engenharia de Software deste Guia, influencia as caractersticas dos produtos de software percebidas pelo consumidor.

174

Dois importantes padres de qualidade so o TickIT e o padro ISO9001-00, junto com suas diretrizes para aplicao em software(ISO90003-04) Outro padro da industria de qualidade de software o CMMI [SEI02], tambm discutido na KA Processo de Engenharia de Software. O CMMI tem o objetivo de fornecer orientaes para melhorar processos. reas de processos especficos relacionados com gerncia de qualidade so (a) garantia da qualidade do processo e do produto, (b) verificao de processo e (c) validao de processo. O CMMI classifica, revisa e audita como formas de verificao, e no como processos especficos como a norma (IEEE12207.0-96). Inicialmente houve alguma discusso sobre qual dos dois padres (ISO9001 ou CMMI) deveria ser usado por engenheiros de software para assegurar qualidade. Esta discusso esta amplamente publicada, e, como resultado, foi tomada a posio de que os dois so complementares e que ter a certificao ISO9001 pode contribuir consideravelmente para conseguir os nveis mais altos de maturidade do CMMI. [Dac01]. O engenheiro de software primeiramente precisa determinar qual o real propsito do software. Nesta considerao, de extrema importncia ter em mente que os requisitos do cliente vm em primeiro lugar e que eles incluem requisitos de qualidade, no apenas requisitos funcionais. Assim, o engenheiro de software tem a responsabilidade de elicitar os requisitos de qualidade que geralmente no esto explcitos, e discutir sua importncia bem como o nvel de dificuldade em obt-los. Todos os processos associados com a qualidade de software (por exemplo, construo, verificao e melhoria da qualidade) sero projetados com estes requisitos em mente, e isto leva a custos adicionais. A norma (ISO9126-01) define, para dois de seus trs modelos de qualidade, as caractersticas sub caractersticas de qualidade relacionadas, e medidas que so teis para avaliar a qualidade de produtos de software. (Sur03). O significado do termo "produto" estendido para incluir qualquer artefato obtido como sada de qualquer processo usado para construir o produto final de software. Exemplos de um produto incluem, mas no so limitados a, uma especificao de requisitos de todo o sistema, uma especificao dos requisitos de software para um componente de um sistema, um mdulo do projeto, cdigo, documentao de teste ou relatrios produzidos como um resultado de tarefas de anlise de qualidade.

175

Enquanto a maioria dos tratamentos de qualidade descrita em termos do software final e do desempenho do sistema, boas prticas de engenharia exigem que avaliaes em produtos intermedirios relevantes para a qualidade sejam realizadas durante todo o processo de engenharia de software. d) Melhoria da Qualidade A qualidade de produtos de software pode ser aperfeioada atravs de um processo interativo de melhoria contnua que requer controle de gerenciamento, coordenao e avaliao de muitos processos concorrentes: (1) O ciclo de vida do processo de software, (2) o processo de deteco de defeito/erro, remoo e preveno, e (3) A melhoria da qualidade do processo. (Kin92) A teoria e os conceitos atrs da melhoria de qualidade, como qualidade em construo atravs da preveno e descoberta antecipada de erros, melhoria contnua e foco no cliente, so pertinentes engenharia de software. Estes conceitos esto baseados nos trabalhos de especialistas em qualidade que tm declarado que a qualidade de um produto est diretamente ligada qualidade do processo utilizado para desenvolv-lo. (Cro79, Dem86, Jur89) Abordagens como a Gesto da Qualidade Total (TQM), e a metodologia Planejar, Executar, Verificar, Atuar (PDCA) so ferramentas para se atingir os objetivos de qualidade. O apoio gerencial prov avaliaes de processos e produtos, e os resultados encontrados. Em seguida, um programa de melhoria desenvolvido identificando aes detalhadas e melhoria nos projetos para serem abordadas em um prazo razovel. A gerncia se certifica de que cada projeto de melhoria tenha o suficiente em recursos para alcanar a meta definida para o mesmo. O apoio gerencial frequentemente deve ser solicitado implementando atividades de comunicao preventivas. O envolvimento de grupos de trabalho, como tambm apoio de gerncias intermedirias e alocao de recursos para nveis de projeto, so discutidos na KA Processo de Engenharia de Software. 2.1.3.10.2 Processos de Gesto da Qualidade de Software A Gesto da Qualidade de Software (SQM) aplica-se a todas as perspectivas dos processos de software, produtos e recursos. Definem processos, donos e requisitos para os mesmos, medies do processo e de seus resultados, e canais de

176

avaliao. (Art93) Os processos de gesto de qualidade de software consistem de muitas atividades. Algumas podem encontrar defeitos diretamente, enquanto outras indicam onde anlises adicionais podem ser valiosas. Estas tambm so referenciadas como atividades de busca direta de defeito. Muitas atividades frequentemente se enquadram nos dois grupos. Planejamento para qualidade de software envolve: (1) Definir os requisitos do produto em termos de suas caractersticas de qualidade (descrito em mais detalhe na KA Gesto da Engenharia de Software). (2) Planejar os processos para alcanar o produto requerido (descrito nas KAs Projeto de Software e Construo de Software). Estes aspectos diferem, por exemplo, dos processos de planejamento SQM, que confrontam o planejamento de caractersticas de qualidade com a atual implementao desses planos. Os processos de gerncia de qualidade de software devem abordar a forma como os produtos de software precisam satisfazer os requisitos do cliente e das partes interessadas (stakeholders), prover valor para os clientes e outras partes (stakeholders) e prover qualidade de software necessria para satisfazer os requisitos. SQM pode ser usado para avaliar tanto os produtos intermedirios quanto o produto final. Alguns dos especficos processos SQM esto definidos no padro (IEEE12207.0-96): Processo de garantia da qualidade Processo de verificao Processo de validao Processo de reviso Processo de auditoria Estes processos incentivam a qualidade e tambm localizam possveis problemas. Mas eles diferem um pouco na sua nfase. Processos SQM ajudam garantir melhor qualidade de software em um determinado projeto. Eles tambm fornecem, como um produto secundrio, informaes gerais para gerenciamento, inclusive uma indicao da qualidade de todo o processo de engenharia de software. As KAs Processo de Engenharia de

177

Software e Gesto da Engenharia de Software discutem programas de qualidade para as organizaes de desenvolvimento de software. SQM pode fornecer feedback relevante para estas reas. Processos SQM consistem em tarefas e tcnicas para indicar como os planejamentos de software (por exemplo, gerncia, desenvolvimento, gesto de configurao) esto sendo implementados, e o quanto os produtos intermedirios e finais esto de acordo com os requisitos especificados. Os resultados destas tarefas so reunidos em relatrios de gerncia antes das aes corretivas serem tomadas. A gerncia de um processo SQM encarregada de garantir que os resultados destes relatrios sejam precisos. Como descrito nesta KA, processos SQM esto intimamente ligados; eles podem se sobrepor e s vezes at mesmo se combinar. Eles parecem largamente reativos por natureza porque abordam os processos como praticados e os produtos como produzidos; mas eles tm um papel importante no inicio da fase de planejamento sendo preventivos em termos de processos e procedimentos necessrios para atingir as caractersticas de qualidade e grau de qualidade necessrios pelas partes interessadas (stakeholders) no software. A Gerncia de Risco tambm pode desempenhar um papel importante no cumprimento da qualidade de software. Incorporar anlise disciplinada de riscos e tcnicas de gesto nos processos do ciclo de vida do software pode aumentar o potencial para se desenvolver um produto de qualidade (Cha89). Recorra KA Gesto de Engenharia de Software para material relacionado sobre gerncia de risco. a) Garantia da Qualidade de Software Os Processos SQA garantem que os produtos de software e os processos no ciclo de vida do projeto estejam em conformidade com seus requisitos de especificao, pelo planejamento, ordenamento e execuo de uma srie de atividades para fornecer a confiana adequada de que a qualidade est sendo incorporada ao software. Isto significa assegurar que o problema est clara e adequadamente declarado e que os requisitos da soluo esto corretamente definidos e expressados. SQA procura manter a qualidade ao longo do desenvolvimento e manuteno do produto pela execuo de uma variedade de

178

atividades em cada fase que pode resultar na identificao precoce de problemas, uma caracterstica quase inevitvel de qualquer atividade complexa. O papel da SQA com respeito ao processo assegurar que os processos planejados sejam apropriados e depois implementados de acordo com o planejamento, e que processos de medies pertinentes sejam fornecidos organizao apropriada. O planejamento SQA define os meios que sero usados para assegurar que o desenvolvimento de software para um certo produto satisfaa os requisitos dos usurios e seja da melhor qualidade possvel dentro das restries do projeto. Para faz-lo, em primeiro lugar preciso garantir que os objetivos da qualidade estejam claramente definidos e compreendidos. preciso considerar gerenciamento, desenvolvimento e planos de manuteno para o software. Para detalhes consulte a norma (IEEE730 -98). As atividades e tarefas especficas de qualidade so definidas, com os seus custos e requerimentos de recursos, seus objetivos globais de gesto, e o seu cronograma em relao a esses objetivos na gesto da engenharia de software, desenvolvimento ou planos de manuteno. O planejamento SQA deve ser consistente com o plano de gesto de configurao do software (consulte a KA Gesto de Configurao de Software). O planejamento SQA identifica documentos, normas, prticas e convenes que regem o projeto e como eles sero conferidos e monitorados para garantir conformidade e adequao. O planejamento SQA tambm identifica mtricas, tcnicas estatsticas, procedimentos para reportar problemas e aes de correo, recursos como ferramentas, tcnicas e metodologias, segurana para mdias fsicas, treinamento, informao e documentao de SQA. Alm disso, o planejamento SQA aborda as atividades de garantia da qualidade de software e qualquer outro tipo de atividade descritas no projeto de software, como obteno de fornecedores para o projeto ou instalao do software de prateleira (commercial offthe-shelf software - COTS), e servio aps a entrega do software. Tambm podem existir critrios de aceitao bem como relatrios e gesto de atividades que so essenciais qualidade do software. b) Verificao & validao Por questes de simplicidade, Verificao e Validao (V&V) so tratadas como um nico tpico neste Guia ao invs de em tpicos separados como na norma

179

(IEEE12207.0-96). "Verificao e Validao de Software uma abordagem disciplinada para avaliao dos produtos de software ao longo do ciclo de vida do produto. V&V se esfora para garantir que a qualidade seja incorporada ao software e que este satisfaa os requisitos do usurio (IEEE1059-93). V&V aborda diretamente a qualidade do produto de software e utiliza tcnicas de teste para localizar defeitos que, em seguida, devem ser resolvidos. Eles tambm avaliam os produtos intermedirios, e, neste caso, as etapas intermedirias dos processos do ciclo de vida. O processo V&V determina se os produtos de uma certa atividade de desenvolvimento ou de manuteno esto em conformidade com os requisitos da atividade, e se o produto final de software atende sua finalidade e satisfaz requisitos do usurio. Verificao uma tentativa de garantir que o produto seja construdo corretamente, no sentido que a atividade de desenvolvimento dos produtos rene as especificaes impostas em atividades anteriores. Validao uma tentativa de se certificar que o produto certo foi construdo, ou seja, que o produto especfico cumpre sua funo especfica. Os processos de verificao e validao comeam cedo no desenvolvimento ou fase de manuteno. Eles fornecem uma anlise das principais funcionalidades do produto tanto em relao ao produto imediatamente antecessor quanto em relao a especificaes s quais ele deve se ater. O propsito do planejamento de V&V garantir que cada recurso, papel, e responsabilidade sejam claramente assegurados. Os planos de V&V resultantes documentam e descrevem os vrios recursos, seus papis e atividades, alm das tcnicas e ferramentas a serem utilizadas. Uma compreenso dos propsitos diferentes de cada atividade de V&V ajudar no planejamento cuidadoso das tcnicas e recursos necessrios para cumprir seus propsitos. As normas (IEEE1012 -98:s7 e IEEE1059 -93: Apndice A) especificam o que normalmente acontece em um plano de V&V. O plano tambm contempla a gesto, comunicao, polticas e procedimentos de V&V e suas atividades de interao, bem como a elaborao de relatrios de defeitos e documentao de requisitos. c) Revises e Auditorias

180

Por questes de simplicidade, revises e auditorias so tratadas como um nico tpico neste Guia, ao invs de em dois tpicos separados como em (IEEE12207.0-96). Os processos de reviso e auditoria esto amplamente definidos em (IEEE12207.0-96) e em mais detalhe em (IEEE1028 -97). So apresentados cinco tipos de revises ou auditorias na Norma IEEE1028-97: Revises Gerenciais Revises Tcnicas Inspeo (Verificao) Walk-throughs Auditorias "O propsito de uma reviso gerencial monitorar o progresso, determinar o status de planos e cronogramas, confirmar requisitos e alocao de seus sistemas, ou avaliar a eficcia das abordagens de gerncia utilizadas para atingir a adequao ao objetivo" [IEEE1028-97]. Tais abordagens apoiam decises sobre mudanas e aes corretivas que so requeridas durante um projeto de software. Revises gerenciais determinam a adequao dos planos, cronogramas e requisitos, e monitoram seu progresso ou inconsistncias. Estas revises podem ser executadas em produtos tais como relatrios de auditoria, relatrios de progresso, relatrios de V&V e muitos tipos de planos, inclusive gesto de risco, gesto de projeto, gesto de configurao de software, segurana de software e avaliao de risco, entre outros. Consulte as KAs Gerenciamento de Engenharia de Software e Gerenciamento de Configurao de Software para material relacionado. "O propsito de uma reviso tcnica avaliar um produto de software para determinar se ele adequado para o uso planejado. O objetivo identificar inconsistncias a partir de normas e especificaes aprovadas. Os resultados devero fornecer evidncias confirmando (ou no) que o produto cumpre as especificaes e adere aos padres necessrios, e que mudanas so controladas" (IEEE1028 - 97). Devem ser estabelecidos papis especficos em uma reviso tcnica: um tomador de decises, um lder de revises, um relator, e uma equipe tcnica para dar assistncia s atividades de reviso. Uma reviso tcnica requer que entradas obrigatrias estejam no lugar e em ordem para proceder: Declarao de objetivos

181

Um especfico produto de software O especfico plano de gerenciamento de projeto A lista de assuntos associados com este produto O procedimento de reviso tcnica A equipe acompanha os procedimentos de reviso. Uma pessoa qualificada

tecnicamente apresenta uma viso geral do produto, e a anlise realizada durante uma ou mais reunies. A reviso tcnica estar completa uma vez que forem finalizadas todas as atividades listadas na anlise. "O propsito de uma inspeo descobrir e identificar anomalias nos produto de software (IEEE1028 -97). Duas importantes diferenas entre inspees e revises so as seguintes: Um indivduo que ocupe uma posio de gerenciamento sobre qualquer membro da equipe de inspeo no deve participar da inspeo. Uma inspeo deve ser conduzida por um facilitador imparcial treinado em tcnicas de inspeo. Inspees de software sempre envolvem o autor de um produto intermedirio ou final, enquanto outras revises no o fazem. Inspees tambm incluem um lder de inspeo, um relator, um leitor e alguns (2 a 5) inspetores. Os membros de uma equipe de inspeo podem possuir diferentes especializaes, como especializao no domnio, especializao em mtodos de design ou especializao em linguagens. As inspees so geralmente conduzidas em uma parte relativamente pequena do produto a cada momento. Cada membro da equipe deve examinar o produto de software e outra reviso aplicada antes da reunio de avaliao, talvez aplicando uma tcnica analtica (consulte a seo 3.3.3) numa pequena seo do produto, ou no produto inteiro com foco em apenas um aspecto, por exemplo, interface. Qualquer anomalia encontrada documentada e enviada ao lder de inspeo. Durante o processo, o lder de inspeo conduz a sesso e verifica se todos os participantes esto preparados para a tarefa. Um checklist, com anomalias e questes pertinentes aos assuntos de interesse, uma ferramenta comum usada em inspees. A lista resultante frequentemente classifica as anomalias (consulte a IEEE1044-93 para detalhes) e a sua completude e correo so garantidas por uma reviso da equipe. A deciso de sada da inspeo tem que corresponder a um dos trs critrios seguintes:

182

Aceitar com nenhuma ou, no mximo, com pequenas modificaes Aceitar com verificao de refactoring Inspecionar Reunies de inspeo duram, tipicamente, algumas horas, enquanto que

revises tcnicas e auditorias, em geral, possuem um escopo mais abrangente e duram mais tempo. "O propsito de um walk-through avaliar um produto de software. Um walkthrough pode ser realizado com a finalidade de educar uma audincia relacionada com o produto de software." (IEEE1028 -97) Os principais objetivos so [IEEE102897]: Encontrar anomalias Melhorar o produto de software Considerar alternativas de implementaes Avaliar conformidade a normas e especificaes O walk-through semelhante a uma inspeo, mas normalmente conduzida com menos formalidade. O walk-through principalmente organizado pelo engenheiro de software para dar aos companheiros de equipe oportunidade de revisar seu trabalho, como uma tcnica de garantia. "O propsito de uma auditoria de software fornecer uma avaliao independente da conformidade de produtos de software e processos para padres, diretrizes, planos e procedimentos" [IEEE1028 - 97]. A auditoria uma atividade formalmente organizada, com participantes que tm papis especficos, como auditor lder, outro auditor, um relator ou um iniciador, e inclui um representante da organizao examinada. A auditoria identificar exemplos de no conformidade e produzir um relatrio exigindo que a equipe entre com ao corretiva. Embora possam existir muitos nomes formais para revises e auditorias como identificados na Norma (IEEE1028 - 97), o ponto importante a se considerar que eles podem acontecer em praticamente qualquer produto e qualquer fase do desenvolvimento ou processo de manuteno. 2.1.3.10.3 Consideraes prticas a) Requisitos de Qualidade de Software Vrios fatores influenciam no planejando, gerenciamento e seleo de

183

atividades de SQM e tcnicas, incluindo: O domnio do sistema em que o software ir residir (segurana crtica, misso crtica, negcio crtico) Os requisitos de sistema e do software Os componentes que sero utilizados no sistema comercial (externos) ou padres (internos) As normas especificas de engenharia de software aplicadas. Os mtodos e ferramentas a serem utilizados no desenvolvimento, manuteno e na avaliao e melhoramento da qualidade O oramento, a equipe, a organizao do projeto, planos e cronogramas de todos os processos Os usurios destinados ao uso do sistema O nvel de integridade do sistema Informao sobre estes fatores exercem influncia em como os processos de SQM so organizados e documentados, como atividades especficas de SQM so selecionadas, que recursos so necessrios e quais devem impor limites sobre os esforos. Em casos onde falhas de sistema podem ter consequncias extremamente severas, dependncia geral (de hardware, software e humana) o principal requisito de qualidade, se posicionando acima das funcionalidades bsicas. Dependncia de software inclui caractersticas como tolerncia a falha, segurana, usabilidade. Confiabilidade tambm um critrio que pode ser definido em termos de dependncia (ISO9126). Uma base literria para sistemas deve ser indispensvel (sistemas de "alta confiana" ou "alta integridade"). A terminologia para sistemas eltricos e mecnicos tradicionais que podem no incluir software tem sido importada para discutir ameaas ou perigos, riscos, integridade de sistema e conceitos relacionados, e pode ser encontrada nas referncias citadas para esta seo. O nvel de integridade determinado baseado nas possveis consequncias de falhas no software e na probabilidade das falhas. Para softwares no qual a segurana ou garantia importante, podem ser utilizadas tcnicas como anlise de perigo ou ameaa para segurana a fim de se desenvolver uma atividade de planejamento que identificaria potenciais pontos de problemas. O histrico de falha

184

semelhantes no software tambm pode ajudar na identificao de quais tcnicas sero mais teis na identificao de falhas e na avaliao de qualidade. Nveis de integridade (por exemplo, gradao de integridade) so propostos em (IEEE1012 -98). b) Caracterizao de Defeitos Os processos de SQM encontram defeitos. A caracterizao destes defeitos conduz compreenso do produto, facilita correes do processo ou do produto e informa gerncia do projeto ou ao cliente o status do processo ou produto. Existem muitas taxonomias de falhas, e, embora tentativas tenham sido feitas para se obter uma taxonomia padronizada de erros e falhas, a literatura indica que ainda existem algumas verses diferentes em uso ([Bei90, Chi96, Gra92], IEEE1044-93). Caracterizao de defeitos tambm usada em auditorias e revises, o lder de reviso frequentemente apresenta uma lista de falhas fornecidas por membros da equipe para apreciao em uma reunio de reviso. Enquanto novos mtodos de design e linguagens evoluem, juntamente com os avanos em tecnologias de software globais, novas classes de defeitos aparecem e uma grande dose de esforo exigida para interpretar as classes definidas anteriormente. Ao localizar defeitos, o engenheiro de software est interessado no s no nmero de defeitos, mas tambm nos tipos. A informao isolada, sem nenhuma classificao, no realmente de muita utilidade na identificao das causas subjacentes dos defeitos, uma vez que alguns tipos especficos de problemas precisam ser agrupados juntos em ordem para determinar o que ser feito a respeito sobre eles. O ponto estabelecer uma taxonomia de defeito que seja significante organizao e para os engenheiros de software. SQM encontra informaes em todas as fases de desenvolvimento e manuteno de software. Na verso original em ingls deste guia, as palavras "defect" e "fault" so utilizadas como referncia ao termo "defeito". Culturas ou padres diferentes podem utilizar significados diferentes para estes termos, o que levou a tentativas de defini-los. Definies parciais tomadas, a partir da norma (IEEE610.12-90) so: Erro (error): "A diferena entre um resultado computado e o resultado correto" Defeito (fault): "Um passo, processo ou definio de dados incorreto"

185

Falha (failure): "O resultado incorreto de um defeito" Engano (mistake): "Uma ao humana que produz um resultado incorreto" Modelos de confiana so construdos a partir de dados obtidos em falhas

durante o teste ou funcionamento do software, e assim podem ser utilizados para predizer futuros fracassos e auxiliar em decises sobre quando os testes devem terminar. [Mus89] Uma provvel ao resultante do SQM encontrar e remover os defeitos do produto sujeitos a anlise. Outras aes permitem a obteno do resultado perfeito a partir das atividades do SQM. Estas aes incluem analisar e resumir os resultados, e utilizar tcnicas de medio para melhorar o produto e o processo bem como localizar e remover os defeitos. Melhoria de processos discutida principalmente na KA Processo de Engenharia de Software, sendo o processo SQM uma fonte de informao. Os dados sobre falhas e defeitos encontrados durante a implementao de tcnicas de SQM podem ser perdidos a menos que sejam registrados. Para algumas tcnicas (por exemplo, revises tcnicas, auditorias, inspees), relatores esto presentes para estabelecer informaes, junto com questes e decises. Quando ferramentas automatizadas forem usadas, a sada da ferramenta pode fornecer a informao de defeito. Os dados sobre os defeitos podem ser coletados e registrados em um SCR (pedido de mudana de software) e pode ser entrado subsequentemente em algum tipo de banco de dados, manualmente ou automaticamente, de uma ferramenta de anlise. Relatrios sobre defeitos so fornecidos administrao da organizao. c) Tcnicas de Gerenciamento de Qualidade de Software Tcnicas de SQM podem ser categorizadas em muitas formas: esttico, pessoas intensivas, analtico, dinmico. Tcnicas estticas envolvem anlise da documentao de projeto e software e outras informaes sobre os produtos de software, sem os executar. Estas tcnicas podem incluir atividades pessoas intensivas (como definido em 3.3.2) ou atividades analticas (como definido em 3.3.3) conduzidos por indivduos, com ou sem a ajuda de ferramentas automatizadas. A colocao para tcnicas de pessoas intensivas, incluindo revises e

186

auditorias, pode variar de uma reunio formal a um ajuntamento informal ou uma situao de desk-check, mas (normalmente, pelo menos) duas ou mais pessoas esto envolvidas. Uma preparao antes do tempo pode ser necessria. Outros itens de recursos de anlise podem incluir checklists e resultados de tcnicas analticas e testes. Estas atividades so discutidas em (IEEE1028 -97) nas revises e auditorias. [Fre98, Hor03] e [Jon96, Rak97] Um engenheiro de software geralmente aplica tcnicas analticas. s vezes vrios engenheiros de software utilizam a mesma tcnica, mas cada um a aplica em partes diferentes do produto. Algumas tcnicas so dirigidas por ferramentas; outras so manuais. Algumas podem encontrar defeitos diretamente, mas elas tipicamente so usadas para apoiar outras tcnicas. Algumas tambm incluem vrias avaliaes como parte da anlise de qualidade global. Exemplos de tais tcnicas incluem anlise de complexidade, anlise de controle de fluxo e anlise algortmica. Cada tipo de anlise tem um propsito especfico e nem todos os tipos so aplicados em todos os projetos. Um exemplo de uma tcnica de apoio a anlise de complexidade, que til para determinar se o projeto ou implementao ou no muito complexo para desenvolver corretamente, testar, ou manter. O resultado de uma anlise de complexidade pode tambm ser utilizado para desenvolver casos de testes. Tcnicas de encontrar defeito, tais como anlise de controle de fluxo, podem tambm ser utilizadas para apoiar outras atividades. Para softwares com muitos algoritmos, anlise algortmica importante, especialmente quando um algoritmo incorreto poderia causar um resultado catastrfico. H muitas tcnicas de anlise para listar todas aqui. A lista e referncias fornecidas podem oferecer discernimento na seleo de uma tcnica, como tambm sugestes para uma futura leitura. Outros tipos de tcnicas analticas mais formais so conhecidos como mtodos formais. Eles so usados para verificar requisitos de software e projeto. Prova de correo aplica a partes crticas de software. Elas foram principalmente utilizadas na verificao de partes cruciais de sistemas crticos, como segurana especfica e requisitos de segurana. (Nas97) Diferentes tipos de tcnicas dinmicas so executados ao longo do desenvolvimento e manuteno do software. Geralmente, so tcnicas de teste, mas tcnicas como simulao, modelo de verificao e execuo simblica tambm

187

podem ser consideradas dinmicas. Leitura de cdigo considerada uma tcnica esttica, mas engenheiros de software experientes so capazes de executar o cdigo em paralelo enquanto eles o leem Neste caso, leitura de cdigo tambm pode ser qualificada como uma tcnica dinmica. Estas diferenas na tarefa de categorizao indicam que pessoas com papis diferentes na organizao podem considerar e aplicar tais tcnicas de forma diferente. Alguns testes podem ser realizados em processos de desenvolvimento, processos SQA ou em processos V&V, mais uma vez, dependendo da organizao do projeto. Pelo fato dos planejamentos SQM lidarem com testes, esta seo inclui alguns comentrios sobre os mesmos. A KA Teste de Software fornece discusses e referncias tericas e tcnicas para teste e automao. Os processos de garantia descritos em SQA e V&V examinam cada sada relacionada com a especificao de requisitos de software com a finalidade de se garantir rastreamento, consistncia, completude, corretude e performance. Esta confirmao tambm inclui os artefatos de sada dos processos de desenvolvimento e manuteno, coletando, analisando e medindo os resultados. A SQA garante que tipos apropriados de teste sejam adequadamente planejados, desenvolvidos e implementados e a V&V desenvolve planos de teste, estratgias, casos e procedimentos. Testes so discutidos em detalhes na KA Teste de Software. Dois tipos de testes podem cair sob a pauta de SQA e V&V, devido sua responsabilidade pela qualidade dos materiais usados no projeto: Avaliao e teste das ferramentas utilizadas no projeto (IEEE1462-98) Teste de conformidade (ou reviso de teste de conformidade) de componentes e produtos COTS utilizados no produto; existe agora um padro para pacotes de software (IEEE1465-98) Em alguns casos uma organizao de V&V independente pode ser convidada para acompanhar o processo de teste e, s vezes, testemunhar a execuo para garantir que ele seja conduzido conforme procedimentos especificados. Novamente, V&V pode ser chamada para avaliar o teste propriamente dito: adequao de planos e procedimento, e adequao e preciso de resultados. Outro tipo de teste que pode cair sob a pauta da organizao de V&V o teste de terceiros. O terceiro no o desenvolvedor, nem , de qualquer forma,

188

associado com o desenvolvimento do produto. O terceiro um mecanismo independente, normalmente credenciado por algum rgo da autoridade. O seu objetivo testar um produto para conformidade de um conjunto especfico de requisitos. d) Mtricas da Qualidade de Software Os modelos de qualidade de produto de software frequentemente incluem mtricas para determinar o grau de cada caracterstica de qualidade atingida pelo produto. Se selecionadas corretamente, mtricas podem apoiar a qualidade de software (entre outros aspectos de ciclo de vida dos processos) em mltiplas formas. Elas podem ajudar no gerenciamento do processo e em tomadas de deciso. Elas podem encontrar reas problemticas e gargalos no processo de software; e elas podem ajudar os engenheiros de software a avaliar a qualidade do seu trabalho para propsitos SQA e para a melhoria de qualidade de processo a longo prazo. Com a sofisticao crescente de softwares, as questes de qualidade vo alm de simples questes como se o software funciona ou no, para algo como quo bem ele atinge metas de qualidade mensurveis. H alguns tpicos onde mtrica apoia diretamente SQM. Estes incluem ajuda para decidir quando interromper os testes. Para isto, modelos de confiana e benchmarks, ambos usando dados de falhas e fracasso, so teis. O custo dos processos SQM um assunto que quase sempre levantado durante a deciso de como um projeto deve ser organizado. frequentemente so utilizados modelos genricos de custo, que so baseados em quando um defeito encontrado e quanto esforo necessrio para corrigir o defeito em relao ao custo de se encontrar o defeito mais cedo no processo de desenvolvimento. Dados de projeto podem dar uma melhor estimativa de custo. Uma discusso sobre este tpico pode ser encontrada em [Rak97: pp. 39-50]. Informaes relacionadas podem ser encontradas nas KAs Processo de Engenharia de Software e Gesto de Engenharia de Software. Finalmente, os prprios relatrios de SQM fornecem informaes valiosas, no s sobre estes processos, mas tambm sobre como todos os processos de ciclo vida do software podem ser melhorados. Discusses sobre estes tpicos so

189

encontradas em [McC04] e (IEEE1012 -98). Enquanto as mtricas para caractersticas de qualidade e funcionalidades do produto puderem ser teis em si (por exemplo, o nmero de requisitos defeituosos ou a proporo de requisitos defeituosos), tcnicas matemticas e grficas podero ser aplicadas para ajudar na sua interpretao. Estas se encaixam nas categorias seguintes e so discutidos em [Fen97, Jon96, Kan02, Lyu96, Mus99]. Baseado em estatstica (por exemplo, anlise de Pareto, grficos de execuo , scatter plots, distribuio normal) Testes estatsticos (por exemplo, teste binomial, teste do qui-quadrado (chisquared test) Anlise de tendncias Predio (por exemplo, modelos de confiana) As tcnicas e testes baseados em estatstica frequentemente fornecem um snapshot das reas mais problemticas do produto de software sob anlise. As tabelas e grficos resultantes so visualizaes que os tomadores de decises podem usar para concentrar os recursos onde eles parecem mais necessrios. Resultados de anlise de tendncia podem indicar que um cronograma no tem sido respeitado, tais como nos testes, ou que certas classes de falhas tornam-se mais intensas a menos que seja tomada alguma ao corretiva em desenvolvimento. As tcnicas de predio ajudam no planejamento de testes e na previso de tempo de falhas. Mais discusses sobre mtricas, em geral, aparecem nas KAs Processo de Engenharia de Software e Gerenciamento de Engenharia de Software. Informaes mais especficas sobre mtricas de teste so apresentadas na KA Teste de Software. Referncias [Fen97, Jon96, Kan02, Pfl01] apresentam discusses sobre anlise de defeito, que consiste em medir a ocorrncias de defeitos e, em seguida, aplicar mtodos estatsticos para entender os tipos de defeitos que acontecem mais frequentemente, ou seja, respondendo a perguntas, a fim de avaliar suas densidades. Eles tambm ajudam a entender as tendncias, bem como tcnicas de deteco que esto trabalhando, e bem como os processos de desenvolvimento e manuteno esto progredindo. Medidas de cobertura de teste ajudam estimar quanto esforo de teste ainda precisa ser feito, e a prever possveis defeitos restantes. A partir destes mtodos de medida, podem ser desenvolvidos perfis de

190

defeito para um domnio especfico de aplicao. Ento, para o prximo sistema de software dentro daquela organizao, os perfis podem ser usados para guiar os processos de SQM, ou seja, para gastar o esforo onde os problemas so provveis de acontecer. Semelhantemente, benchmarks (pontos de referncia) ou tpica contagem de defeitos desse domnio, podem servir como um auxlio para determinar quando o produto estar pronto para entrega. A discusso sobre o uso dados de SQM para melhorar o processo de desenvolvimento e de manuteno aparece nas KAs Gesto de Engenharia de Software e Processo de Engenharia de Software.

Figura 27: Tpicos x referncias (7)

Figura 28: Tpicos x referncias (8)

191

Figura 29: Tpicos x referncias (9)

2.1.3.11 Disciplinas Relacionadas Com Engenharia de Software A fim de circunscrever a engenharia de software, necessrio identificar as disciplinas de engenharia de software com o qual partilha uma fronteira comum. Este captulo identifica, em ordem alfabtica, estas disciplinas relacionadas. Evidentemente, as Disciplinas Relacionadas tambm partilham muitas coisas em comum entre si. Usando um consenso baseado em fonte reconhecida, este captulo identifica, para cada disciplina relacionada: Uma definio informativa (quando possvel) Uma lista de reas do conhecimento

Figura 30: Disciplinas relacionadas Engenharia de Software

2.1.3.11.1 Engenharia da Computao O relatrio de desenho do volume para computador que cria o projeto Currculos de Computao 2001 (CC2001) afirma que "engenharia da computao encarna a cincia e tecnologia de concepo, construo, implementao e

192

manuteno de software e hardware componentes dos modernos sistemas de computao e equipamento controlado por computador Este relatrio identifica as seguintes reas de Conhecimento (conhecidas como reas no relatrio) para a engenharia da computao: Algoritmos e Complexidade Organizao e Arquitetura de Computadores Engenharia de Sistemas de Computao Circuitos e Sistemas Lgica Digital Estruturas Discretas Processamento de Sinal Digital Sistemas Distribudos Eletrnica Sistemas Integrados Interao Humano Computador Gesto de Informao Sistemas Inteligentes Redes de Computadores Sistemas Operacionais Programao Fundamental Probabilidade e Estatstica Questo Social e Profissional Engenharia de Software Teste e Verificao VLSI / ASIC Design

2.1.3.11.2 Cincia da Computao O relatrio final do volume de Cincia da Computao do projeto Currculo de Computao 2001 (CC2001) identifica as seguintes listas de reas do conhecimento (identificado como reas do relatrio) para computao cientfica: Estruturas Discretas Programao Fundamental

193

Algoritmos e Complexidade Organizao e Arquitetura Sistemas Operacionais Net-Centric Computing Linguagem de Programao Interao Humano Computador Computao Grfica e Visual Sistemas Inteligentes Gesto de Informao Questo Social e Profissional Engenharia de Software Computao Cientfica e Mtodos Numricos

2.1.3.11.3 Gerenciamento As diretrizes europeias do MBA definidas pela associao europeia de corpos nacionais da abonao (EQUAL) indicam que o mestre do grau da administrao de negcio deve incluir a cobertura e a instruo em: Finanas Marketing e Vendas Gerenciamento de Operaes Sistemas de Gesto da Informao Lei/Regra Gesto de Recursos Humanos Economia Anlise Quantitativa Poltica e Estratgia de Negcio

2.1.3.11.4 Matemtica Duas fontes so selecionadas para identificar a lista de reas do conhecimento para a matemtica. O relatrio intitulou de critrios de abonao e procedimentos, a Cmara Canadense de abonao da Engenharia que identificam

194

os elementos apropriados das seguintes reas e devem estar atuais em um currculo da engenharia de graduao: lgebra linear Clculo diferencial e integral Equaes diferenciais Probabilidade Estatsticas Anlise numrica Matemtica discreta Uma lista mais focalizada de tpicos matemticos (chamados unidades e tpicos no relatrio) que sustente a tecnologia de programao pode ser encontrada no relatrio de esboo do volume na tecnologia de programao do projeto de computao dos currculos 2001 (CC2001). 2.1.3.11.5 Gesto de Projetos A gesto de projeto definida na edio 2000 como um de guia ao corpo da gesto do projeto de conhecimento (PMBOK Guide 6) publicado pelo instituto da gesto do projeto e adotado como IEEE STD 1490-2003, como a aplicao do conhecimento, das habilidades, das ferramentas, e das tcnicas para projetar atividades cumprir exigncias do projeto. As reas do conhecimento identificadas no guia PMBOK para a gesto do projeto so: Gerncia da integrao do projeto Gerncia do espao do projeto Gerncia de tempo do projeto Gerncia do custo do projeto Gerncia de qualidade do projeto Gerncia de recursos humanos do projeto Gerncia de comunicao do projeto Gesto de riscos do projeto Gerncia da obteno do projeto

195

2.1.3.11.6 Gerncia de Qualidade A gerncia de qualidade definida na ISO 9000-2000 como Coordenando Atividades para Dirigir e Controlar uma Organizao no que diz Respeito Qualidade. As trs referncias selecionadas na gerncia de qualidade so: Sistemas de gesto da qualidade do 9000:2000 do ISO - Fundamentos e Vocabulrio Sistemas de gesto da qualidade do 9001:2000 do ISO Exigncias Sistemas de gesto da qualidade do 9004:2000 do ISO - Diretrizes para melhorias do Desempenho A sociedade americana para a qualidade identifica as seguintes reas do conhecimento (tpicos da avaria do primeiro nvel em seu esboo) em seu corpo para a certificao de um coordenador da qualidade: Desenvolvimento, execuo e verificao de sistemas da qualidade Planejando, controlando, e assegurando a qualidade do produto e do processo Confiabilidade e gesto de riscos Resoluo de problema e melhoria de qualidade Mtodos quantitativos

2.1.3.11.7 Ergonomia de software O campo de ergonomia definido pelo Comit Tcnico da Ergonomia no ISO 159 como segue: A ergonomia ou (fatores humanos) a disciplina cientfica relacionada com a compreenso das interaes entre o ser humano e os outros elementos de um sistema, e a profisso que aplica a teoria, os princpios, os dados e os mtodos ao projeto a fim de aperfeioar o desempenho do bem estar humano e do sistema total. Uma lista de reas do conhecimento para a ergonomia como se aplica ao software proposto abaixo: a) Cognio Cognitivo Al l: raciocinando Aprendizagem de mquina e induo da gramtica Mtodos formais na cincia cognitiva: Linguagem

196

Mtodos formais na cincia cognitiva: Raciocnio Mtodos formais na cincia cognitiva:

b) Arquitetura cognitiva Cognitivo Al ll: aprendendo Fundaes da cincia cognitiva Extrao de informao do discurso e do texto Processamento lexical Aquisio de lngua computacional A natureza de IHC (META-) Modelos de IHC

c) Uso e contexto dos computadores Organizao social e trabalho humano reas de aplicao

d) Ajuste e Interao Humano Mquina Caractersticas humanas Processamento de informao humano Linguagem, comunicao, interao Ergonomia

e) Sistema informtico e arquitetura da relao Dispositivos de entrada e de sada Tcnicas do dilogo Gnero do dilogo Grficos de computador Arquitetura do dilogo

f) Processo de desenvolvimento Aproximaes do projeto Tcnicas da execuo

197

Tcnicas da avaliao Sistemas do exemplo e estudos de caso Uma lista mais focalizada de tpicos no projeto de relao homem-mquina

(chamado unidades e tpicos no relatrio) para finalidades do currculo da tecnologia de programao pode ser encontrada no relatrio de esboo do volume da tecnologia de programao do Projeto de computao dos currculos 2001 (CC2001). 2.1.3.11.8 Engenharia de sistemas O Conselho Internacional da Engenharia de Sistemas (INCOSE) indica que a engenharia de sistemas uma aproximao interdisciplinar e significa permitir a realizao de sistemas bem sucedidos. Centra-se sobre a definio de necessidades do cliente e da funcionalidade exigida cedo no ciclo de desenvolvimento, documentando exigncias, ento continuao com sntese de projeto e validao do sistema quando considera o problema completo: operaes desempenho, teste, fabricao, custo e programao, treinamento e sustentao e eliminao. A engenharia de sistemas integra todas as disciplinas e grupos da especialidade em um esforo de equipe que d forma a um processo de desenvolvimento estruturado e que prossiga do conceito de produo operao. A engenharia de sistemas considera o negcio e as necessidades tcnicas de todos os clientes com o objetivo de fornecer um produto de qualidade que encontre as necessidades do usurio. O Conselho internacional na engenharia de sistemas (INCOSE, www.incose.org) est trabalhando em um guia ao corpo de engenharia de sistemas de conhecimento. As verses preliminares incluem as seguintes reas da competncia dos primeiros nveis: Processos de negcio e avaliao operacional (BPOA) Sistema/arquitetura da soluo/teste (SSTA) Ciclo da vida e do custo; Anlise de benefcio de custo (LCC & CBA) Servio-habilidade/logstica (S/L) Modelagem, simulao e Anlise (MS& A) Gerncia: Risco, configurao, linha de base (Mgt)

198

2.1.4 Apndices
2.1.4.1 Apndice A 2.1.4.1.1 Especificaes da Descrio de rea Para o SWEBOK Este documento apresenta a verso 1.9 das especificaes fornecidas pela Equipe Editorial ao Especialista de reas do Conhecimento quanto s Descries de reas do Conhecimento do Guia do Corpo de Conhecimento de Engenharia de Software (Verso de Ironman). Este documento comea apresentando especificaes dos contedos da Descrio da reas do Conhecimento. Os critrios e as exigncias so propostos para divises de tpicos, para a base lgica dessas divises, para a descrio sucinta dos tpicos, para selecionar materiais de referncia, e para identificar reas do Conhecimento relevantes de Disciplinas Relacionadas. Os documentos de entrada importantes tambm so identificados bem como explicado seus papeis dentro do projeto. Questes no relacionados ao contedo, como formato de submisso e diretrizes de estilos, tambm so discutidas. 2.1.4.1.2 Critrios e Exigncias para Propor as Divises de Tpicos As seguintes exigncias e critrios devem ser usados quando se propuser uma separao de tpicos dentro de uma dada rea do Conhecimento: a) Espera-se que editores associados proponham uma ou possivelmente duas divises complementares que sejam especficas sua rea do Conhecimento. Os tpicos encontrados em todos as divises dentro de uma dada rea do Conhecimento devem ser idnticos. b) Espera-se que essas divises de tpicos sejam "razoveis", no "perfeitas". O Guia do Corpo de Conhecimento de Engenharia de Software visto definitivamente como um esforo multifsico, e muitas iteraes dentro de cada fase bem como mltiplas fases sero necessrias para melhorar continuamente essas divises. c) A diviso proposta de tpicos dentro de uma rea do Conhecimento deve

199

decompor o subconjunto do Corpo de Conhecimento de Engenharia de Software que geralmente aceito. Veja abaixo uma discusso mais detalhada disto. d) A diviso proposta de tpicos dentro de uma rea do Conhecimento no deve presumir domnios de aplicao especficos, necessidades negociais, tamanhos das organizaes, estruturas organizacionais, filosofias de gerncia, modelos de ciclo de vida de software, tecnologias de software, ou mtodos de desenvolvimento de software. e) A diviso proposta de tpicos, tanto quanto possvel, deve ser compatvel com vrias escolas do pensamento dentro da engenharia de software. f) A diviso proposta de tpicos dentro das reas do Conhecimento deve ser compatvel com a diviso da engenharia de software geralmente encontrado na indstria e na literatura sobre engenharia de software e padres. g) Espera-se que a diviso proposta de tpicos seja to inclusiva quanto possvel. Julga-se que melhor sugerir tpicos demasiadamente e descart-los do que fazer ao contrrio. h) Espera-se que os Editores Associados das reas do Conhecimento adotem a posio que embora "os temas" seguintes sejam comuns atravs de todas as reas do Conhecimento, eles tambm sejam uma parte integrante de todas as reas do Conhecimento e por isso devem ser incorporados na diviso proposta de tpicos de cada rea do Conhecimento. Esses temas comuns so qualidade (em geral) e medida. Por favor observe que o problema de como tratar propriamente essa "corrida cruzada" ou tpicos ortogonais e se eles devem ser tratados de uma maneira diferente ainda no foi completamente resolvido. i) As divises propostas devem ter no mximo dois ou trs nveis de profundidade. Mesmo embora nenhum limite superior ou inferior seja imposto ao nmero de tpicos dentro de cada rea do Conhecimento, espera-se que os Editores Associados das reas do Conhecimento proponham um nmero razovel e

200

gerencivel de tpicos por rea do Conhecimento. Tambm deve-se dar nfase na seleo dos prprios tpicos e no na sua organizao em uma hierarquia apropriada. Os nomes dos tpico propostos devem ser expressivos o bastante para terem significado mesmo quando citados fora do Guia do Corpo de Conhecimento de Engenharia de Software . j) A descrio de uma rea do Conhecimento incluir um diagrama (na forma de rvore) descrevendo a diviso do conhecimento. 2.1.4.1.3 Critrios e exigncias para descrever Tpicos A descrio dos tpicos deve ser somente a necessria, assim o leitor pode selecionar o material de referncia apropriado segundo suas necessidades. 2.1.4.1.4 Critrios e exigncias para Selecionar Material de Referncia a) Materiais de referncia especficos devem ser identificados para cada tpico. Cada material de referncia naturalmente pode cobrir mltiplos tpicos. b) Os materiais de referncia propostos podem ser captulos de livros, artigos referenciados de jornais, artigos referenciados de conferncias, relatrios tcnicos ou industriais, ou qualquer outro tipo de artefato reconhecido, como documentos web. Eles devem ser disponveis de maneira geral e no devem ser de natureza confidencial. A referncia deve ser to exata quanto possvel, identificando quais captulos ou sees especficas so relevantes. c) Os materiais de referncia propostos devem ser em ingls. d) Um montante razovel de materiais de referncia deve ser selecionados para cada rea do Conhecimento. As seguintes diretrizes devem ser usadas na determinao do quanto razovel: Se o material de referncia foi escrito de uma maneira coerente seguindo a diviso proposta de tpicos e em um estilo uniforme (por exemplo, em um novo livro baseado na descrio da reas do

201

Conhecimento proposta), uma mdia razovel de nmero de pginas seria 500. Contudo, este meta pode no ser atingvel selecionando o material de referncia existente devido a diferenas em estilo, sobreposio e redundncia com outros materiais de referncia selecionados. O montante de material de referncia seria razovel se ele se consistisse do material de estudo da rea do Conhecimento para o exame de licenciamento de engenharia de software que um graduado passaria depois de concluir quatro anos de experincia de trabalho. O Guia do Corpo de Conhecimento de Engenharia de Software destinado por definio para ser seletivo na sua escolha de tpicos e materiais de referncia associados. A lista dos materiais de referncia de cada rea do Conhecimento deve ser examinada e ser apresentada como uma seleo informada e razovel e no como uma lista definitiva. Materiais de referncia adicionais podem ser includos na lista Leituras Complementares. Essas leituras complementares devem ainda estar relacionadas a diviso de tpicos. Elas tambm devem discutir o conhecimento geralmente aceito. No deve haver uma matriz entre o material de referncia enumerado em Leituras Complementares e os tpicos individuais. e) Se considerado factvel e rentvel pela Sociedade de Computao IEEE, o material de referncia selecionado ser publicado no Web site do Guia do Corpo de Conhecimento de Engenharia de Software. Para facilitar esta tarefa, deve ser dada preferncia ao referir materiais quais os direitos autorais j pertencem Sociedade de Computao IEEE. Contudo, isto no deve ser visto como um constrangimento ou uma obrigao. f) Uma matriz do material de referncia versus tpicos deve ser fornecida.

202

2.1.4.1.5 Critrios e exigncias para Identificar KAs das Disciplinas relacionadas Espera-se que os Editores Associados das reas do Conhecimento identifiquem em uma seo em separado que reas do Conhecimento das Disciplinas Relacionadas so suficientemente relevantes para as reas do Conhecimento de Engenharia de Software que foram atribudas a terem o conhecimento esperado por um graduado com quatro anos da experincia. Esta informao ser especialmente til e empenhar muito dilogo entre a inciativa do Guia do Corpo de Conhecimento de Engenharia de Software e nossas iniciativas irms responsveis por definir um currculo comum de engenharia de software e normas de realizao padro para engenheiros de software. A lista de reas do Conhecimento de Disciplinas Relacionadas pode ser encontrada na Lista Base Proposta de Disciplinas Relacionadas. Se considerado necessrio e se acompanhado de uma justificativa, os Especialistas das reas do Conhecimento tambm podem propor Disciplinas Relacionadas adicionais no includas ou identificadas na Lista Base Proposta de Disciplinas Relacionadas. (Por favor observe que uma classificao dos tpicos das Disciplinas Relacionadas foi produzida mas ser publicada no Web site em uma data posterior em um documento de trabalho separado. Por favor contate a equipe editorial para mais informao). 2.1.4.1.6 ndice dos Contedos Comuns As descries de reas do Conhecimento devem usar o seguinte ndice de contedo: Introduo Diviso de tpicos de reas do Conhecimento (para objetivos de esclarecimento, acreditamos que esta seo deve ser colocada na frente e no em um apndice no fim do documento. Tambm, deve ser acompanhado por uma figura que descreve a diviso) Matriz de tpicos versus material de Referncia Referncias recomendadas da reas do Conhecimento descrita (por favor no os misture com referncias usadas para escrever a descrio da reas do Conhecimento) Lista de Leituras Complementares

203

2.1.4.1.7 O que Queremos Dizer com Conhecimento Geralmente Aceito? O corpo de conhecimento de engenharia de software um termo tudo em um que descreve a soma do conhecimento dentro da profisso de engenharia de software. Contudo, o Guia do Corpo de Conhecimento da Engenharia de Software procura identificar e descrever qual subconjunto do corpo do conhecimento geralmente aceito ou, em outras palavras, o corpo principal do conhecimento. Para ilustrar melhor o que o conhecimento geralmente aceito quanto a outros tipos do conhecimento, a Figura 31 prope um esquema de trs categorias preliminares para classificar o conhecimento. O Instituto de Gerenciamento de Projetos no seu Guia do Corpo de Conhecimento de Gerenciamento de Projetos1 conhecimento geralmente aceito para gerenciamento de projetos da seguinte maneira: Meios geralmente aceitos que o conhecimento e as prticas descritas so aplicveis maior parte dos projetos na maior parte do tempo, tendo consenso comum sobre o seu valor e utilidade. Geralmente aceito no significa que o conhecimento e as prticas descritas so ou devem ser aplicados uniformemente em todos os projetos; a equipe de gerenciamento de projetos sempre responsvel por determinar o que apropriado para qualquer projeto dado. O Guia do Corpo de Conhecimento de Gerenciamento de Projetos agora um Padro IEEE. No encontro inicial Mont Tremblant em 1998, o Conselho Consultivo Industrial melhor definiu geralmente aceito como conhecimento a ser includo no material de estudo de um exame de engenharia de software que um graduado passaria depois de concluir quatro anos de experincia de trabalho. Essas duas definies devem ser vistas como complementares. Tambm se espera que Editores Associados das reas do Conhecimento estejam pensando a frente nas suas interpretaes, levando em considerao no s o que geralmente aceito hoje, mas o que eles esperam que seja geralmente aceito em um perodo de 3 a 5 anos.

204

Figura 31: Categorias de Conhecimento

2.1.4.1.8 Comprimento de Descrio de reas do Conhecimento Espera-se que as Descries das reas do Conhecimento estejam atualmente em torno de 10 pginas usando o formato da Conferncia Internacional de Engenharia de Software, definido abaixo. Isto inclui texto, referncias, apndices, tabelas, etc. Isto, naturalmente, no inclui os prprios materiais de referncia. Este limite no deve, contudo, ser visto como um constrangimento ou uma obrigao. 2.1.4.1.9 Papel da Equipe Editorial Alain Abran e James W. Moore so os Editores Executivos e so responsveis por manter boas relaes com a Sociedade de Computao IEEE, o Conselho Consultivo Industrial, o Conselho de Controle de Modificao Executivo, e o Painel de Peritos bem como pela estratgia geral, aproximao, organizao, e consolidao do projeto. Pierre Bourque e Robert Dupuis so os Editores e so responsveis pela coordenao, operao e logstica deste projeto. Mais especificamente, os Editores so responsveis por desenvolver o plano de projeto e a especificao da descrio das reas do Conhecimento, coordenando Editores Associados das reas do Conhecimento e suas contribuies, recrutando revisores e chefes de reviso, bem como coordenando vrios ciclos de reviso. Por isso os Editores so responsveis pela coerncia do Guia inteiro e por identificar e estabelecer conexes entre as reas do Conhecimento. Os Editores e os Editores Associados das reas do Conhecimento negociaro a resoluo de

205

lacunas e sobreposies entre reas do Conhecimento. 2.1.4.1.10 Documentos Relacionados Importantes a) P. Bourque, R. Dupuis, A. Abran, J. W. Moore, L. Tripp, e D. Frailey, Uma Lista Bsica de reas do Conhecimento da Verso Stone Man do Guia do Corpo de Conhecimento de Engenharia de Software, Universit du Qubec Montral, Montral, Fevereiro de 1999. Baseado na verso Straw Man, nas discusses mantidas e expectativas afirmadas na reunio de incio do Conselho Consultivo Industrial, em outras propostas de corpo de conhecimento, e em critrios definidos neste documento, este documento prope uma lista bsica de dez reas do Conhecimento da Verso Teste do Guia do Corpo de Conhecimento de Engenharia de Software. Esta base pode desenvolver-se naturalmente com o progresso de trabalhos e identificao de problemas durante o curso do projeto. b) P. Bourque, R. Dupuis, A. Abran, J. W. Moore, e L. Tripp, Uma Lista Bsica Proposta de Disciplinas Relacionadas da Verso Stone Man do Guia do Corpo de Conhecimento de Engenharia de Software, Universit du Qubec Montral, Montral, Fevereiro de 1999. Baseado na verso Straw Man, nas discusses mantidas e expectativas afirmadas na reunio de incio do Conselho Consultivo Industrial, e no trabalho subsequente, este documento prope uma lista bsica de Disciplinas Relacionadas e reas do Conhecimento dentro dessas Disciplinas Relacionadas. Este documento foi submetido e discutido com o Conselho Consultivo Industrial, e uma lista reconhecida de reas do Conhecimento ainda tem de ser identificada para certas Disciplinas Relacionadas. Os editores associados sero informados sobre a evoluo deste documento. c) P. Bourque, R. Dupuis, A. Abran, J. W. Moore, L. Tripp, K. Shyne, B. Pflug, M. Maya, e G. Tremblay, Guia do Corpo de Conhecimento de Engenharia de Software Verso Straw Man, relatrio tcnico, Universit du Qubec Montral, Montral, Setembro de 1998.

206

Este relatrio a base do projeto inteiro. Ele define a estratgia geral do projeto, base lgica, e princpios subjacentes, propondo uma lista inicial de reas do Conhecimento e Disciplinas Relacionadas. d) 4. J. W. Moore, Padres de Engenharia de Software, O Mapa de Caminho do Usurio, IEEE Computer Society Press, 1998. Este livro descreve o alcance, papis, usos e tendncias de desenvolvimento dos padres de engenharia de software mais amplamente utilizados. concentrado em importantes atividades de engenharia de software qualidade e gerenciamento de projetos, engenharia de sistemas, confiana, e segurana. A anlise e o reagrupamento das colees de padres expem as relaes chave entre padres. Mesmo embora o Guia do Corpo de Conhecimento de Engenharia de Software no seja um projeto de desenvolvimento de padres de engenharia de software por si s, um cuidado especial ser tomado em todas as partes do projeto quanto compatibilidade do Guia com o atual IEEE e com a Coleo de Padres de Engenharia de Software ISO. e) Glossrio Padro IEEE de Terminologia de Engenharia de Software, std 610.121990, IEEE, 1990. A hierarquia de referncias de terminologia o Dicionrio Acadmico de Merriam Webster (10 ed.), IEEE std 610.12, e novas definies propostas se necessrio. f) Tecnologia da Informao Processos de Ciclo de Vida de Software, Internacional std ISO/IEC 12207:1995 (E), 1995. Este padro considerado o padro chave quanto definio do processo de ciclo de vida e foi adotado por dois corpos de padronizao principais da engenharia de software: ISO/IEC JTC1 SC7 e o Comit de Padres de Engenharia de Software da Sociedade de Computao IEEE. Tambm foi indicado como o padro fundamental em torno o qual o Comit de Padres de Engenharia de Software (SESC) est harmonizando atualmente a sua coleo inteira de padres. Este padro foi uma entrada chave verso Straw Man. Mesmo embora no tenhamos inteno que o Guia do Corpo de

207

Conhecimento de Engenharia de Software seja totalmente 12207-compatvel, este padro permanece uma entrada chave verso Stone Man e cuidados especiais sero tomados em todas as partes do projeto quanto compatibilidade do Guia com o padro 12207. g) Merriam Websters Collegiate Dictionary (10 ed.). Veja nota para o padro IEEE 610.12. 2.1.4.1.11 Estilo e Diretrizes Tcnicas As Descries de rea do Conhecimento devem enquadrar-se com so disponveis em http://sunset.usc.edu/icse99/cfp/technical_papers.html). Espera-se que as Descries das reas do Conhecimento sigam o Guia de Estilo da Sociedade de Computao IEEE. Ver http://www. computer.org/author/style/csstyle.htm. O formato preferencial de submisso o Microsoft Word. Por favor contate a Equipe Editorial se isto no for factvel para voc. 2.1.4.1.12 Outras Diretrizes Detalhadas Referindo o guia, recomendamos que voc use o ttulo inteiro Guia do SWEBOK em vez de s "SWEBOK". Por objetivo de simplicidade, recomendamos que os Editores Associados das reas do Conhecimento evitem notas. Em vez disso, eles devem tentar incluir o seu contedo no texto principal. Recomendamos usar no texto referncias explcitas para padres, ao contrrio de inserir simplesmente nmeros que referem itens na bibliografia. Acreditamos que isto permite que o leitor seja melhor exposto fonte e ao alcance do padro. O texto que acompanha figuras e tabelas deve ser evidente ou conter texto relacionado suficiente. Isto poder assegurar que o leitor saiba o que as figuras e as tabelas significam. Assegure-se que voc usa a informao atual de referncias (verses, ttulos, etc.). Para assegurar-se que alguma informao contida no Guia do SWEBOK no

Conferncia Internacional de Procedimentos de Engenharia de Software (os padres

208

fique rapidamente obsoleta, por favor evite denominar diretamente ferramentas e produtos. Em vez disso, tente denominar suas funes. A lista de ferramentas e produtos pode sempre ser adicionada a um apndice. Espera-se que voc explique todos os acrnimos usados nos mnimos detalhes e use todos os direitos autorais apropriados, marcas de servio, etc. As Descries de reas do Conhecimento devem sempre ser escritas na terceira pessoa. 2.1.4.1.13 Edio A Equipe Editorial e os editores profissionais editaro as Descries das reas do Conhecimento. A Edio inclui a edio de cpia (gramtica, pontuao, e capitalizao), edio do estilo (conformidade ao estilo das revistas da casa, Sociedade de Computao), e edio do contedo (fluxo, significado, clareza, correo, e organizao). A edio final ser um processo colaborativo no qual a Equipe Editorial e os autores colaboraram para realizar uma Descrio das reas do Conhecimento concisa, bem expressa, e til.

2.1.4.1.14 Liberao de Direitos Autorais Todas as propriedades intelectuais associadas com o Guia do Corpo de Conhecimento de Engenharia de Software permanecero com a Sociedade de Computao IEEE. Foi pedido aos Editores Associados das reas do Conhecimento que assinassem um formulrio de liberao de direitos autorias. Tambm entendido que o Guia do Corpo de Conhecimento de Engenharia de Software ser posto em domnio pblico pela Sociedade de Computao IEEE, gratuita por meio de tecnologia web ou por outros meios.

209

2.1.4.2 Apndice B 2.1.4.2.1 Evoluo do SWEBOK Apesar de guia para o Corpo de conhecimento de engenharia de software ser uma referncia em atingir uma grande concordncia no contedo da disciplina de engenharia de software, no o fim de um processo. O guia de 2004 simplesmente a edio corrente do guia que continuar evoluindo para corresponder s necessidades da comunidade de engenharia de software. O planejamento da evoluo ainda no est completo, mas um esboo da tentativa do processo oferecido nessa seo. Como foi descrito, este processo est sendo aprovado pelo "Board" do Conselho de projetos industriais e resumido pelo "board" de governadores da Sociedade de Computao IEEE, mas ainda no est financiada ou implementada. 2.1.4.2.2 Stakeholders A Adoo me larga escala do Guia SWEBOK tem produzido uma comunidade substancial de partes envolvidas em adio prpria Sociedade de Computao. H um nmero de projetos - dentro e fora da Sociedade de Computao- que esto coordenando o seu contedo com o contedo do Guia SWEBOK.(Mais sobre isso em um momento). Algumas corporaes, incluindo alguns dos membros do "Board" do Conselho de projetos industriais, adotaram o guia para uso em seus programas internos para educao e treinamento. Em um amplo sentido, a comunidade de praticantes de engenharia de software,profissionais da comunidade desenvolvedora e comunidade da educao prestam ateno ao guia do SWEBOK para ajudar a a definir o escopo de seus esforos. Um notvel grupo de parte envolvida so os titulares de certificao da Sociedade de computao - Profissional de de Desenvolvimento de Software Certificado - porque o escopo do exame CSDP altamente alinhado com o escopo do guia SWEBOK.A sociedade de Computao IEEE e outras organizaes esto agora conduzindo um nmero de projetos que dependem da evoluo do guia SWEBOK:

O exame CSDP, inicialmente desenvolvido em paralelo com o guia SWEBOK, ir evoluir para algo mais prximo do guia, ambos em escopo e material de referncia. O currculo da sociedade de aprendizagem a distncia de computao para

210

engenheiros de software ter o mesmo escopo que o guia SWEBOK. Uma viso geral inicial do curso j est disponvel. Apesar dos objetivos da educao para estudantes no graduados difiram um pouco daqueles de desenvolvimento profissional,o projeto conjunto ACMM/IEEE-CS para desenvolver um currculo de engenharia de software para no graduados altamente reconciliados com o escopo do guia SWEBOK.

O comit de padres para Engenharia de software (SESC) tem organizado essa coleo pelas reas de conhecimento do guia SWEBOK e a associao de padres IEEE j publicou uma edio em CD-ROM dos padres de engenharia de software que refletem sua organizao.

ISO/IEC JTC1/SC7, os padres internacionais de organizao para software e engenharia de software, est adotando o guia SWEBOK como relatrio tcnico ISO/IEC 19759 e harmonizando sua coleo com a do IEEE. A editora da Sociedade de Computao IEEE, em cooperao com o SESC, est desenvolvendo uma srie de livros baseados nos padres de engenharia de software e no guia SWEBOK. O portal da sociedade de computao de engenharia de software ("SE online"), atualmente em planejamento, ser organizado por reas de conhecimento do guia SWEBOK O uso da verso trial do SWEBOK foi traduzido para o Japons. Prev-se que em 2004 a verso ser tambm traduzida em Japons, chins e possivelmente outras lnguas O CSDP adicionou uma rea de conhecimento, Prticas de negcio e

engenharia econmica,para as dez reas de conhecimento cobertas pelo guia SWEBOK. 2.1.4.2.3 O Processo de Evoluo Obviamente, um produto com tanta aceitao precisa evoluir de uma forma aberta,consultiva, deliberada e transparente para que outros projetos possam coordenar esforos com xito. A estratgia atualmente planejada evoluir o guia SWEBOK usando uma abordagem "time-boxed". A abordagem time-box selecionada porque permite que o guia SWEBOK coordene e realize revises de

211

projeto antecipadamente a uma data fixada para convergncia. O time box inicial est planejado atualmente para quatro anos em durao. No incio de cada time box, em consulta com a coordenao de projetos,um plano global para reviso de quatro anos precisa ser determinado. Durante o primeiro ano, mudanas estruturais para o guia SWEBOK (isto , mudanas em nmero ou escopo de reas de conhecimento) precisam ser determinadas. Durante o segundo e o terceiro anos,a seleo e o tratamento de tpicos de dentro das reas de conhecimento precisa ser revisado. Durante o quarto ano, o texto das descries das reas de conhecimento precisa ser revisado e referncias atualizadas precisam ser selecionadas. O projeto global precisa ser gerenciado por um comit de voluntrios da Sociedade de computao e representantes projetos de coordenao. O comit precisa ser responsvel por definir planos globais, coordenado com as partes envolvidas, e recomendar a aprovao de uma reviso final. O comit deve ser ajudado por um comit conselheiro do SWEBOK(SWAC) composto de utilizadores do guia SWEBOK. O SWAC precisa tambm focar para obter suporte financeiro corporativo para a evoluo do guia SWEBOK. Suporte financeiro corporativo passado permitiu tornar o guia SWEBOK disponvel gratuitamente em um Web Site. Suporte futuro ir permitir continuar a prtica para edies futuras. De forma fictcia, cada dos quatros anos precisa incluir um ciclo de oficina, elaborao,votao e resoluo por voto. Um ciclo anual precisa envolver as seguintes atividades: Uma oficina, organizada como parte de uma conferncia maior, precisa especificar problemas para tratamento durante o prximo ano, priorizar os problemas, recomendar abordagens para lidar com eles, e nomear redatores para implementar as abordagens. Cada redator deve escrever ou modificar a descrio da rea de conhecimento usando a abordagem recomendada pela oficina e referncias disponveis. No ano final do ciclo, os redatores devem recomendar referncias especficas atualizadas para citao no guai SWEBOK. Redatores tambm devem ser responsveis para modificar suas redaes em resposta a comentrios de votantes. Cada ciclo anual deve incluir votaes nas revises para as descries das

212

reas de conhecimento. Votantes devem revisar as redaes das descries das reas de conhecimento e referncias recomendadas, oferecer comentrios, e votar a aprovao das revises. Votao deve ser aberta a membros da sociedade de computao e outros participantes qualificados. ( No membros devem pagar honorrios para custear o despesa de votao). titulares do CSDP devem ser particularmente bem-vindos como membros do grupo de votao ou como voluntrios em outros papis. Uma resoluo do comit de votao deve ser selecionada por um comit de gerenciamento para servir como intermedirio entre os redatores e os votantes. Seu trabalho determinar o consenso para mudanas requisitadas pelo grupo de votao e para garantir que os redatores iro implementar as mudanas necessrias. Em alguns casos, o comit de resoluo de votos precisa formular questes para guiar a reviso da redao. Cada objetivo anual alcanar consenso entre o grupo de votao nas novas e revisadas reas de conhecimento e ganhar o voto de aprovao dos votantes. Apesar do guia SWEBOK no mudar at o fim do time box, o material aprovado de cada ciclo anual estar disponvel gratuitamente na concluso do time box, o produto completo, guia SWEBOK 2008, ser revisado e aprovado por um "board" da Sociedade de Computao e governadores para publicao. Se o suporte financeiro contnuo puder ser obtido, o produto estar disponvel gratuitamente em um Web Site. 2.1.4.2.4 Mudanas Antecipadas importante notar que o guia SWEBOK inerentemente um documento conservador por vrias razes. Primeiro, limita-se ao conhecimento das caractersticas de engenharia de software; ento informaes de disciplinas relacionadas - mesmo disciplinas aplicadas por engenheiros de software - omitida. Segundo, desenvolvida e aprovada por um processo consensual, para que possa apenas gravar informao para que a concordncia em grande escala possa ser obtida.

213

2.1.4.3 Apndice C 2.1.4.3.1 Distribuio dos Padres de EG da IEEE/ISO para as KAs do SWEBOK O apndice C do SWEBOK fornece uma lista com os padres de engenharia de software produzidos pelo IEEE e ISO / IEC JTC1/SC7, bem como alguns padres selecionados a partir de outras fontes. Para cada padro, o seu nmero e o ttulo fornecido. Alm disso, a coluna "Descrio" fornece o material extrado do resumo ou outro material da norma introdutria. Cada uma das normas mapeado para as reas de conhecimento do Guia SWEBOK. Em alguns casos, como o vocabulrio de normas-padro do mesmo se aplica a todos os KAS, em tais casos, aparece um X em cada coluna. Na maioria dos casos, cada norma tem uma alocao forada a uma nica e principal rea de conhecimento; esta atribuio est marcada com um "P". Em muitos casos, existem distribuies secundrias de KAs, estas so marcadas com um "S". A lista ordenada por nmero de norma, independentemente da sua categoria (IEEE, ISO, etc.).

214

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

IEEE Std 610.121990 (R2002) IEEE Std 730-2002 IEEE Std 828-1998 IEEE Std 829-1998 IEEE Std 830-1998 IEEE Std 982.11988 IEEE Std (R 2003)

Padro IEEE Vocabulrio de terminologias de Engenharia de Software Padro IEEE para qualidade e garantia de planejamento de software

Este padro o vocabulrio de terminologias de engenharia de software X X X X X X X X X X

Este padro especifica o formato e contedo dos planos de garantia e qualidade de software S S P

Padro IEEE para planejamento da Este padro especifica o contedo do plano de gerncia de configurao de software Padro IEEE para documentao de teste de software IEEE Prtica recomendada para especificao de requisitos de software Padro IEEE Dicionrio de medidas para produo de software confivel Gerncia de configurao de software juntamente com requisitos para atividades especficas Este padro descreve a forma e contedo de um conjunto bsico de documentao para planejamento, execuo e relatrio de teste de software Este documento recomenda o contedo e caractersticas da especificao de requisitos de software. So fornecidos esboos de exemplo. Este padro fornece um conjunto de medidas para avaliar a confiabilidade de um produto de software e para a obteno de previses iniciais da confiabilidade de um produto em desenvolvimento Padro IEEE para unidade de teste Este padro descreve uma abordagem slida de unidade de teste de software, e os conceitos e premissas sobre as quais se baseia. Ele tambm fornece informao, orientao e recursos. S P S S S S S S P P S P S P S

1008-1987 de software

215

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

IEEE Std e 1012a1998

Padro IEEE para verificao e

Este padro descreve o processo de verificao e validao de software que so usados para determinar se os produtos de software satisfazem os requisitos da atividade e tambm se os software satisfazem as necessidades do usurio para o fim pretendido. O escopo inclui anlise, avaliao, reviso, inspeo, avaliao e testes de produtos e processos. P

1012-1998 validao de software

IEEE Std IEEE Std (R 2002) IEEE Std (R2002) IEEE Std (R 2002)

IEEE Prtica recomendada para Padro IEEE para anlise de

Este documento recomenda o contedo e organizao das descries de design de software Este padro define cinco tipos de anlises de software e procedimentos para sua execuo. Os tipos incluem anlise de gerenciamento, anlise tcnica, inspees, simulaes e auditorias. S

1016-1998 descrio de design de software 1028-1997 software

Padro IEEE Classificao para

Este padro fornece uma abordagem uniforme para a classificao das anomalias detectadas nos softwares e sua documentao. Inclui listas teis de classificaes de anomalias de dados relacionados S S S P

1044-1993 anomalias de software

Padro IEEE para mtricas de

Este padro fornece uma terminologia consistente para medio da produtividade de software e define uma forma coerente para medir os elementos que esto inseridos nos mecanismos de produtividade de software. P S

1045-1992 produtividade de software

IEEE Std

Padro IEEE para planejamento e

Este padro descreve o formato e contedo do

216

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

1058-1998 gerenciamento de projeto de software IEEE Std Padro IEEE para Metodologia e

planejamento e gerenciamento de projeto de software Este padro descreve uma metodologia abrangendo todo o ciclo de vida para o estabelecimento dos requisitos de qualidade e identificao, implementao e validao de medidas correspondentes S S S S P

1061-1998 mtrica da qualidade de software

IEEE Std 1062, 1998 Edition

IEEE Prtica recomendada para aquisio de software

Este documento recomenda um conjunto prticas teis que podem ser selecionadas e aplicadas durante a aquisio de software. principalmente indicado para aquisies que incluem desenvolvimento ou modificao, em vez de compra de software de prateleira. S P

IEEE Std

Padro IEEE para documentao

Este padro fornece os requisitos mnimos para a estrutura, contedo e formato da documentao de usurio impressos e eletrnicos. Este padro descreve uma aproximao para a definio dos processos de ciclo de vida do software P P S

1063-2001 de software de usurio IEEE Std Padro IEEE para Processos de de Software IEEE Std 1175.12002

1074-1997 Ciclo de Vida de Desenvolvimento

Guia IEEE para ferramentas CASE Este padro o primeiro de uma srie planejada de de Interconexo, Classificao e Descrio padres sobre a integrao de ferramentas CASE dentro de um ambiente produtivo de engenharia de software. Esta parte descreve conceitos fundamentais e introduz as partes restantes (planejadas) P

217

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

IEEE Std IEEE Std

Padro IEEE para Manuteno de Padro IEEE para Aplicao e Engenharia de Sistemas

Este padro descreve um processo para manuteno de software e seu gerenciamento Este padro descreve as atividades dos sistemas de engenharia e processos necessrios ao longo de um ciclo de vida do sistema para desenvolver sistemas que unam as necessidades dos clientes e suas e limitaes.

1219-1998 Software 1220-1998 Gerenciamento dos Processos de

IEEE Std

Padro IEEE para Planejamento

Este padro descreve o contedo mnimo de um plano para aspectos de software de desenvolvimento, aquisio, manuteno e retirada de um sistema de segurana crtica S S S P

1228-1994 de Segurana de Software

IEEE Std 1233, 1998 Edition

Guia IEEE Para Especificao de Requisies de Desenvolvimento de Sistemas

Este documento fornece orientaes sobre o desenvolvimento de um Sistema de Especificao de Requisitos, abrangendo a identificao, organizao, apresentao e modificao dos requisitos. Ele tambm proporciona orientao sobre as caractersticas e qualidades dos requisitos. P

EEE Std 1320.11998

Padro IEEE para Linguagem de Modelagem Funcional Sintaxe e Semntica para IDEF0

Este padro define a modelagem IDEF0 como linguagem utilizada para representar as decises, aes, e atividades de uma organizao ou sistema.

218

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

IDEF0 pode ser usada para definir as exigncias em termos de funes a serem desempenhadas por um determinado sistema. EEE Std 1320.21998 Padro IEEE para Modelagem e Semntica para IDEF1X 97 (IDEFobject) Este padro define duas linguagens conceituais de (IDEFObject). A linguagem suporta a implementao de bancos de dados relacionais, objeto de bancos de dados e modelos de objeto. IEEE Std Guia IEEE de Tecnologia da - Conceito de Operaes (CONOPS) Documento IEEE Std 1420.11995, 1420.1a1996, and 1420.1b1999 (R2002) IEEE Std Padro IEEE Adoo do padro Este padro fornece direcionamentos para a P Padro IEEE para Tecnologia da Informao Reutilizao de Interoperabilidade da Biblioteca de Reutilizao Este documento fornece orientao sobre o formato e o contedo de um Conceito de Operaes (CONOPS) documento, descrevendo as caractersticas de um sistema de propostas do ponto de vista dos usurios. Este padro e seus suplementos descrevem informaes das bibliotecas de reutilizao de de alternncia das propriedades. P

Conceitual Sintaxe da Linguagem modelagem, chamados coletivamente IDEF1X97 S S P

1362-1998 Informao - Sistema de Definio

Software Modelo de Dados para software que devem ser capazes de mudar a ordem P

219

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

1462-1998 internacional isso/IEC 14102:1995 //ISO/IEC 5 IEEE Std //ISO/IEC 12119 Tecnologia da Informao Seleo de Ferramentas CASE Padro IEEE, Adoo do Padro 12119:1994(E), Tecnologia da Informao Pacotes de Software Qualidades de Requisitos e Testes IEEE Std 14102:199 Direcionamento para a Avaliao e

avaliao e seleo de ferramentas CASE.

Este padro descreve requisitos de qualidade especificamente adequados para pacotes de software e orientaes sobre testes de pacotes contra tais requisitos. S P

1465-1998 Internacional ISO/IEC

IEEE Prticas Recomendadas para Este documento recomenda uma estrutura conceitual e contedo para a descrio arquitetural de sistemas de software concentrados. Este documento a adoo da IEEE do Projeto de Gesto do Corpo de Conhecimento definido pelo Instituto de Gerenciamento de Projetos (PMI). Ele identifica e descreve os conhecimentos geralmente aceitos sobre gesto de projetos. P Software em Sistemas Concentrados S S P

1471-2000 Descrio de Arquitetura de

IEEE Std

IEEE Guia Adoo do Padro Gesto Corpo de Conhecimento

1490-1998 PMI Um Guia para o Projeto de

IEEE Std

Padro IEEE para Tecnologia da

Este padro fornece processos de ciclo de vida para

1517-1999 Informao - Processo do Ciclo de reutilizao sistemtica do software. Os processos Vida do Software Reutilizao de so adequados para uso com IEEE/EIA 12207

220

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

Processos IEEE Std //ISO/IEC 16085:200 3 IEEE Std IEEE Prticas Recomendadas para Este documento recomenda prticas para engenharia de pginas www para uso em ambientes de Intranet e Extranet. Este padro especifica os requisitos para um sistema de gesto de qualidade organizacional, objetivando fornecer requisitos conhecidos de produtos e aumentar a satisfao do cliente. ISO/IEC 91261:2001 Engenharia de Software Qualidade de Produto Parte 1: Modelo de Qualidade Este padro fornece um modelo para a qualidade do produto de software em relao qualidade interna, qualidade externa e qualidade em uso. O modelo sob a forma de uma taxonomia de caractersticas definidas que o software pode apresentar. IEEE/EIA 12207.01996 Implementao Industrial do Padro Internacional ISO/IEC 12207:1995, Padro para Este padro fornece uma estrutura de processos usados pelo ciclo de vida completo de software X X X X X X X P X X P S S S S P Web , Gesto de Stios Web e Ciclo de Vida de Stios Web ISO Sistemas de Gesto da Qualidade 9001:2000 - Requisitos P 2001-2002 a Internet Engenharia de Stios Padro IEEE para Processos de de Risco Este padro fornece um processo de ciclo de vida uso com IEEE/EIA 12207 S P 1540-2001 Ciclo de Vida do Software Gesto para gesto de risco. O processo adequado para

221

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

//ISO/IEC 5 IEEE/EIA 12207.11996

Tecnologia de Informao Software Implementao Industrial do Padro Internacional ISO/IEC 12207:1995, Padro para Tecnologia da Informao Processos de Ciclo de Vida de Software Ciclo de Vida de Dados Este documento fornece orientaes sobre gravao de dados resultantes do ciclo de vida dos processos IEEE/EIA 12207.0. X X X X X X X P X X

12207:199 Processos de Ciclo de Vida de

IEEE/EIA 12207.21997

Implementao Industrial do Padro Internacional ISO/IEC de Informao Processos de Ciclo de Vida de Software Consideraes de Implementao

Este documento fornece orientaes adicionais para a implementao do ciclo de vida dos processos X X X X X X X P X X

12207:1995, Padro de Tecnologia IEEE/EIA 12207.0.

IEEE Std 14143.1200// ISO/IEC 141431:1998 ISO/IEC TR

IEEE Adoo do ISO/IEC 14143-

Este padro descreve os conceitos fundamentais de

1:1998 Tecnologia da Informao uma classe de medidas conhecidas coletivamente Medida de Software Medida de como tamanho funcional. Tamanho Funcional Parte 1: Definio de Conceitos Tecnologia da Informao Engenharia de Software Este documento fornece orientao no estabelecimento de processos e atividades que P P S S S

14471:199 Direcionamentos para a Adoo de podem ser aplicados na adoo da tecnologia CASE.

222

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

9 ISO/IEC parts

Ferramentas CASE Tecnologia da Informao A srie ISO / IEC 14598 d uma viso geral dos processos de avaliao de produtos de software e fornece orientaes e requisitos para avaliao em nvel organizacional ou de projeto. Os padres fornecem mtodos de medida, estimativa e avaliao. P

14598 (Six Avaliao de Produto de Software

ISO/IEC 9 ISO/IEC 8

Tecnologia da Informao

Este padro desenvolve o processo de manuteno na ISO / IEC 12207. Ele fornece orientao na aplicao dos requisitos de processo. Este padro internacional introduz o conceito de nvel de integridade de software e requisitos de integridade de software. Ele define o conceito associado com nveis de integridade e requisitos de integridade de software e as exigncias locais de cada processo. S S P P

14764:199 Manuteno de Software Tecnologia da Informao Nveis Sistemas

15026:199 de Integridade de Software e

ISO/IEC TR 8 ISO/IEC 2 ISO/IEC

Tecnologia da Informao Guia

Este documento um guia para uso da isso/IEC P

para ISO/IEC 12207 (Processos de 12207.

15271:199 Ciclo de Vida do Software) Engenharia de Sistemas Sistema Engenharia de Software Este padro fornece uma estrutura de processos usados em todo o ciclo de vida de sistemas feitos pelo homem. Este relatrio tcnico (agora a ser revisto como um

15288:200 processos de Ciclo de Vida de

223

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

Software TR 15504 (9 parts) Process and Draft IS 15504 (5 parts) ISO/IEC 2 ISO/IEC 3 ISO/IEC 3

Avaliao de Processos

padro) fornece os requisitos de mtodos de avaliao de processo de execuo, como base para a melhoria do processo ou da determinao capacidade

Engenharia de Software

Este padro fornece um processo de ciclo de vida para medio de software. O processo adequado ao uso com IEEE/EIA 12207. Este padro descreve o COSMIC-FFP Mtodo de Medio de Tamanho Funcional, um mtodo de medio de tamanho funcional de acordo com os requisitos do padro ISO/IEC 14143-1. Este padro descreve o IFPUG 4.1 contagem de ponto de funo desajustado, um mtodo de medio de tamanho funcional de acordo com os requisitos do padro ISO/IEC 14143-1. Este padro descreve o Mk II Analisador de Pontos de Funo, um mtodo de medio de tamanho funcional de acordo com os requisitos do padro ISO/IEC 14143-1. P S S S P S S S P S S S S P S

15939:200 Processo de Medio de Software Engenharia de Software Medio de Tamanho Funcional Engenharia de Software IFPUG Tamanho Funcional Desajustado Manual de Prticas de Contagem ISO/IEC 2 Engenharia de Software Mk II Manual de Prticas de Contagem 20968:200 Anlise de Ponto de Funo

19761:200 COSMICFFP - Um Mtodo de

20926:200 4.1 Mtodo de Medio de

224

Gerncia da Configurao de Software

Manuteno de Software

Construo de software

Gerncia de Engenharia de Software

Processo de Engenharia de Software

Ferramentas e Mtodos da Engenharia de Software

Requisitos de software

Qualidade de Software

Design de software

Testes de software

Nmero padro

Nome padro

Descrio

ISO/IEC 90003

Software e Engenharia de Sistemas Orientaes para a Aplicao da ISO 9001:2000 para Software de computador

Este padro fornece orientaes para organizaes na aplicao do ISO 9001:2000 para a aquisio, suprimento, desenvolvimento, operao e manuteno de software de computador. S P

225

2.1.4.4 Apndice D 2.1.4.4.1 Classificao dos Temas Segundo a Taxonomia de Bloom Taxonomia de Bloom uma classificao bem conhecida e amplamente utilizada para objetivos educacionais cognitivos. Foi adotado com o objetivo de ajudar o pblico que deseja utilizar o guia como uma ferramenta na definio de material de curso, currculos universitrios, critrios universitrios para credenciamento de programas, descries de trabalho, descries de papis dentro de uma definio do processo de engenharia de software, caminhos de desenvolvimento profissional e programas de formao profissional entre outras necessidades. Os nveis da taxonomia de Bloom para os tpicos do guia SWEBOK so sugeridos neste apndice para uma graduao de engenharia de software com quatro anos de experincia. A graduao de engenharia de software com quatro anos de experincia , em essncia o "alvo" do Guia SWEBOK conforme definido pelo que se entende por conhecimento geral aceito. Uma vez que este apndice apenas se refere ao que pode ser considerado como conhecimento "geralmente aceito", muito importante lembrar que um engenheiro de software deve saber muito mais do que isso. Alm do conhecimento "geralmente aceito", uma graduao de engenharia de software com quatro anos deve possuir alguns elementos de disciplinas relacionadas, bem como alguns elementos de conhecimento especializado, conhecimento avanado e, possivelmente, at mesmo conhecimento de pesquisa. As seguintes suposies foram feitas quando os nveis da taxonomia proposta: As avaliaes so propostas para um engenheiro de software "generalista" e no um engenheiro de software que trabalham em um grupo especializado, como uma equipe de gerenciamento de configurao de software, por exemplo. Obviamente, como engenheiro de software, seria necessrio atingir nveis taxonomia muito maiores na rea de especialidade do seu grupo; Um engenheiro de software com quatro anos de experincia ainda est no incio de sua carreira e lhe seria atribudas relativamente poucas funes de gesto, ou pelo menos no para grandes empreendimentos. "Tpicos relacionados ao gerenciamento" no so, portanto, uma prioridade nas avaliaes propostas. Pela mesma razo, os nveis de taxonomia tendem a ser menores para "temas iniciais do ciclo de vida", tais como os relacionados

226

com os requisitos de software do que para os tpicos mais tecnicamente orientados, tais como aqueles dentro do projeto de software, software de construo ou testes de software. Assim, as avaliaes podem ser adaptadas para mais engenheiros de software snior ou engenheiros de software especializados em determinadas reas do conhecimento, nenhum tpico dado um nvel superior de Anlise de taxonomia. Isto consistente com a abordagem da Software Engineering Education Body of Knowledge (SEEK) onde a nenhum assunto atribudo um nvel superior a taxonomia Aplicao. O objetivo do SEEK definir um programa de educao do corpo de conhecimento de engenharia de software adequado para orientar o desenvolvimento dos currculos de graduao em engenharia de software. Embora distintos, nomeadamente em termos de alcance, SEEK e SWEBOK esto intimamente relacionados. A taxonomia de Bloom de domnio cognitivo proposto em 1956 contm seis nveis. A tabela 14 do apndice D do SWEBOK apresenta esses nveis e palavraschave, muitas vezes associadas a cada nvel. Maiores informaes sobre a Classificao de Bloom, esto inseridas no Apndice D do SWEBOK.

Nvel da Taxonomia de Bloom Conhecimento: Retorno de dados

Palavras-chave Associadas Define, descreve, identifica, conhece, rtulos, listas, jogos, nomes contornos, retorna, reconhece, reproduz, seleciona, afirma.

Compreenso: Entender o significado, a Compreende, converte, defende, traduo, a interpolao, e interpretao distingue, estima, explica, se estende, de instrues e problemas. Estado um problema em suas prprias palavras. Aplicao: Usa um conceito em uma situao nova ou usa espontaneamente de uma abstrao. Aplica-se o que foi generaliza, d exemplos, infere, interpreta, parfrases, prev, reescreve, resume, traduz. Aplica-se, muda, calcula, constri, demonstra, descobre, manipula, modifica, opera, prev, prepara, produz,

aprendido em sala de aula em situaes se relaciona, shows, resolve, usa.

227

Nvel da Taxonomia de Bloom novas no trabalho. Anlise: Separa o material ou conceitos em componentes de forma que sua estrutura organizacional pode ser entendida. Distingue entre fatos e inferncias. partir de elementos diversos. Coloca as peas para formar um todo, com nfase na criao de um novo significado ou estrutura. Avaliao: Faz julgamentos sobre o valor das ideias ou materiais.

Palavras-chave Associadas Analisa, divide, compara, contrasta, diagramas, desconstri, diferencia, discrimina, diferencia, identifica, ilustra, infere, define, relaciona, seleciona, separa. cria, inventa, projeta, explica, gera, modifica, organiza, planeja, se recicla, reconstri, se refere, se reorganiza, revisa, reescreve, resume, diz, escreve. Avalia, compara, conclui, os contrastes, critica, critica, defende, descreve, discrimina, avalia, explica, interpreta, justifica, diz, resume, suporta.

Sntese: Cria uma estrutura ou padro a Categoriza, combina, compila, compe,

A repartio dos assuntos nos quadros no corresponde perfeitamente repartio contida nas reas do conhecimento. A avaliao para esse anexo foi preparado, enquanto alguns comentrios ainda estavam prximos do trmino. Finalmente, e validada. lembre-se que as avaliaes do presente apndice definitivamente devem ser vistos apenas como uma proposta para ser desenvolvida

228

Requisitos de Software
Repartio dos Tpicos Nvel de Taxonomia 1. Fundamentos de requisitos de software Definio de requisitos de software Requisitos de produto e processo Requisitos funcionais e no funcionais Propriedades emergentes Requisitos quantificveis Requisitos de sistema e requisitos de software 2. Processo de requisitos Modelo de processo Atores do processo Suporte do processo e gerenciamento Qualidade do processo e aproveitamento 3. Requisitos de elicitao Origens dos requisitos Tcnicas de elicitao 4. Anlise de requisitos Classificao de requisitos Modelagem conceitual Design arquitetural e alocao de requisitos Negociao de requisitos 5. Especificao de requisitos Documento de definio do sistema Especificao dos requisitos do sistema Especificao dos requisitos de software 6. Validao de requisitos Anlise de requisitos Prototipao Validao de modelo Testes de aceitao 7. Consideraes prticas Processo de requisitos de natureza iterativa Gerenciamento de mudana Atributos de requisitos Rastreamento de requisitos AP C AP C AP AP C AP C C AP AP AP AN AN C AP C C C C C C C C C C

Requisitos de medio

AP

Design de Software
Repartio dos Tpicos 1. Fundamentos de Design de software Conceitos gerais de design Contexto de design de software Processo de design de software Tcnicas de ativao 2. Questes chave no design de software Concorrncia Controlando e carregando eventos Distribuio de componentes Erro e manejo de exceo e tolerncia a falhas Apresentao e interao Persistncia de dados 3. Estrutura e arquitetura de software Estruturas arquiteturais e pontos de vista Estilos arquiteturais Padres de design Famlias de programas e frameworks avaliao Atributos de qualidade Anlises que qualidade e tcnicas de avaliao Medies 5. Notaes de design de software Descries Estruturais Descries de comportamento 6. Estratgias e mtodos para o design de software Estratgias gerais Design orientado a funo Design orientado a objetos Design centrado na estrutura de dados Design baseado em componentes Outros mtodos AN AP AN C C C AP AP C C AN AP AN AN C AP AP AP AP AP AP C C C AN Nvel de Taxonomia

4. Anlise da qualidade do design de software e

229

Repartio dos Tpicos

Nvel de Taxonomia

Construo de Software
Repartio dos Tpicos Nvel de Taxonomia 1. Fundamentos de Construo de software Minimizar complexidade Antecipao de mudana Construo para verificao Normas de construo 2. Gesto de construo Modelos de construo Planejamento de construo Medio de construo 3. Consideraes prticas Design de construo Linguagens de construo Codificando Testando a construo Qualidade da construo Integrao AN AP AN AP AN AP C AP AP Definies e tecnologia Natureza da manuteno Necessidade de manuteno Maioria dos custos de manuteno Evoluo de software Categorias de manuteno Questes tcnicas AN AN AN AP 4. Medidas Relacionadas ao Teste Avaliao do programa sob o teste Avaliao dos testes executados 5. Processo de Teste Consideraes prticas Atividades de Teste

AN AN C AP

Manuteno de Software
Repartio dos Tpicos Nvel de Taxonomia 1. Fundamentos da Manuteno de software C C C C C AP C AP AN AN C AP AN C

2. Questes chave na manuteno de software Questes gerenciais

Testes de Software
Repartio dos Tpicos 1. Fundamentos de Teste de software Terminologia relacionada a testes Assuntos chave Relaes de testes com outras atividades 2. Nveis de teste Alvo de teste Objetivos de teste 3. Tcnicas de teste Baseada na intuio e na experincia do engenheiro Baseada na Especificao Cdigo de barras Falhas baseadas Uso baseadas Baseadas na natureza da aplicao Selecionando e combinando tcnicas AP AP AP AP AP AP AP AP AP C AP C Nvel de Taxonomia

Estimativa de custos de manuteno Medio de manuteno de software 3. Processo de manuteno Processos de manuteno Atividades de manuteno 4. Tcnicas para manuteno Compreenso d programa Engenharia reversa

Gerncia de Configurao de Software (GCS)

Repartio dos Tpicos Nvel de Taxonomia 1. Gerenciamento dos processos de GCS Contexto organizacional para GCS Restries e orientaes para GCS Planejamento para GCS GCS organizao e responsabilidades GCS fontes e programao AP AP C C

230

Repartio dos Tpicos Ferramenta de seleo e implementao Controle de Vendas/contratos Controle de interface Plano de gerenciamento de configurao de software

Nvel de Taxonomia AP C C C

Repartio dos Tpicos Auditoria de configurao de software fsico Auditorias em processo de uma base de software

Nvel de Taxonomia C C

Inspeo de gerenciamento de configurao de software GCS medidas e dimenses Entrada de processos de auditorias para GCS 2. Identificao de configurao de software Identificando itens a serem controlados Configurao de software Itens de configurao de software Itens de relacionamento de configurao de software Verses de software Ponto de partida Itens de aquisio de configurao de software Biblioteca de software 3. Controle de Configurao de software Requisio , avaliao e aprovao de mudana de software Tabela de controle de configurao de software Processo de requisio de mudana de software Implementao de mudanas de softwares Desvios e concesses software Status de informaes de configurao de software Status de relatrios de configurao de software 5. Auditoria de configurao de software Auditoria de configurao de software funcional C AP C C 4. Status da contabilidade de configurao de AP AP AP C AP AP AP AP AP AP AP C

6. Entrega e gerenciamento de liberao de software Construo de software Gerenciamento de liberao de software AP C

Gerncia de Engenharia de software

Repartio dos Tpicos 1. Iniciao e definio de escopo Determinao de negociao de requisitos Anlise de possibilidade Processos para requisitos de anlise/reviso 2. Planejamento de projeto de software Planejamento de processos Determinar resultados Estimativa de esforo, programao e custo Alocao de recursos Gerenciamento de risco Gerenciamento da qualidade Gerenciamento de projeto 3. Lei do projeto de software Implementao de projeto Gerenciamento de contratos com fornecedores Implementao de processos de medio Processo de monitoramento Controle de processos Relatrio 4. Anlise e avaliao Determinando a satisfao dos requisitos AP AN AP AP AP AP C AP AP AP C C AP AP AP C AP Nvel de Taxonomia

231

Repartio dos Tpicos Anlise e avaliao de performance 5. Fechamento Determinando fechamento Atividades de fechamento 6. Medies de engenharia de software Estabelecer e manter compromisso de medio Planejar o processo de medio Executar o processo de medio Avaliar medies c

Nvel de Taxonomia AP AP AP C C C C

Repartio dos Tpicos

Nvel de Taxonomia

Modelos de informao de software Modelo de construo Modelo de implementao Tcnicas de medio Tcnicas analticas Tcnicas de benchmarking AP C AP AP

Ferramentas e mtodos de Engenharia de software

Repartio dos Tpicos 1. Ferramentas de software Ferramentas de requisitos de software Ferramentas de design de software Ferramentas de construo de software Ferramentas de testes de software AP AP AP AP AP AP AP AP AP AP AP C AP C Nvel de Taxonomia

Processos de Engenharia de software

Repartio dos Tpicos Nvel de Taxonomia 1. Processo de Implementao e mudana Processos de infraestrutura Grupo de processo de engenharia de software Fbrica de experincia Atividades Modelos para implementao de processos e mudana Consideraes prticas 2. Definio de processos Modelos de ciclo de vida Processos de ciclo de vida do software Notaes para definies de processos Adaptao de processos Automao 3. Avaliao de Processo Modelos de avaliao de processo Mtodos de avaliao de processo 4. Medio de produto e processo Medio de processo de software Medio de produto de software Medio de tamanho Medio da estrutura Medio da qualidade Resultados da medio da qualidade AP AP AP AP AP AN C C AP C C C C C C AP K C

Ferramentas de manuteno de software Ferramentas de processos de engenharia de software Ferramentas de qualidade de software Ferramentas de gerenciamento de configurao de software Ferramentas de gerenciamento de engenharia de software Ferramenta para assuntos diversos 2. Mtodos de Engenharia de software Mtodos heursticos Mtodos formais e notaes Mtodos de prototipao Mtodos para assuntos diversos

Qualidade de Software
Repartio dos Tpicos Nvel de Taxonomia 1. Fundamentos de qualidade de software Cultura e tica em engenharia de software Valor e custo da qualidade AN AN

232

Repartio dos Tpicos

Nvel de Taxonomia

Modelos de qualidade e caractersticas Qualidade do processo de software Qualidade do produto de software Melhoria da qualidade software Garantia da qualidade de software Verificao e validao Anlise e auditoria Inspees Revises com parceria Reviso conjunta Testes Auditorias 3. Consideraes prticas Requisitos de qualidade da aplicao Criticidade dos sistemas Fidelidade Nvel de integridade de software Caracterizao de defeitos Tcnicas estticas Tcnicas com pessoas de alto nvel de conhecimento Tcnicas analticas Tcnicas dinmicas Medio de qualidade de software AP AP AP C C C AP AP AP AP AP AP AP C AP AP AN AN AP

2. Processos de gerenciamento da qualidade de

Tcnicas de gerenciamento de qualidade de software

233

3 Concluso 3.1 Apresentao dos resultados

O presente trabalho procurou fazer uma exposio da importncia do Guia para o Corpo de Conhecimento de Engenharia de Software SWEBOK. Teve como foco sua traduo e o conhecimento de temas no abordados por alguns cursos, porm tidos como importantes para a formao profissional. As reas de conhecimento de modo geral esto fortemente concisas. A KA de Requisitos de software no seu item de elicitao de requisitos apresenta um conjunto de regras para se obter os dados necessrios ao desenvolvimento de software. A KA Design de Software mostra as vrias terminologias encontradas para o design, como D-Design, PF-Design e I-Design, todas com diferentes conceitos e atuaes para diferentes objetivos. Na KA Construo de Software, o princpio de reutilizao de software mostra que o conceito bem mais que criar bibliotecas de recursos, buscase tambm a integrao dos processos de reutilizao com atividades no ciclo de vida do software. A rea de conhecimento Teste de Software trouxe uma nova abordagem de testes, onde no se pensa em testes aps a concluso do produto, mas sim em todo o processo de desenvolvimento e manuteno. A KA Manuteno de Software oferece a possibilidade de se gerir um sistema e todas as realidades inerentes a ele, como aspectos de hardware, software e firmware entre outros. Temos na Ka Gerncia de Engenharia de Software os mecanismos necessrios para a administrao de todos os pontos relativos engenharia de software e suas especificidades. Na KA Processo de Engenharia de Software o foco est onde mudanas de processos ou de tecnologia so inicialmente introduzidas atravs da melhoria de processos ou produtos. A rea de conhecimento Ferramentas e Mtodos da Engenharia de Software fornece a descrio das ferramentas utilizadas por cada rea de conhecimento assim como ferramentas para problemas variados. A rea de conhecimento Qualidade de Software se torna uma das mais importantes reas dentro do corpo de conhecimento da engenharia de software. Nela encontramos as definies para qualidade e em particular as tcnicas estticas, ou seja, os valores, conceitos e metodologias que envolvem a concepo do software. As disciplinas relacionadas com engenharia de software cederam para esta

234

um acervo de conhecimento que foi fundamental para a sua existncia. Atravs delas foram traadas as diretrizes e o contedo bsico (e distinto) para esta nova disciplina, que, tambm contriburam, atravs de seus autores, com o seu rico repositrio bibliogrfico. Neste repositrio, encontramos material de referncia que de suma importncia para pesquisas cientficas e esto organizadas por rea de conhecimento, facilitando assim seu manuseio.

3.2 Principais contribuies

Entre as contribuies advindas deste trabalho, ressalta-se, em primeiro lugar, a traduo do SWEBOK para o portugus. Tambm servir de fundamentao para outros trabalhos acadmicos e psgraduao. Para profissionais da rea de desenvolvimento, de design, de manuteno, de construo e outras reas afins, no s em se tratando de software, mas de um modo geral, o conhecimento dos tpicos aqui contidos representa um aumento substancial da bagagem necessria para que o profissional seja mai completo. Isto contribui ainda para que este profissional tenha uma viso mais ampla de todos estes processos e possa ser inserido em outros projetos da empresa. Alm disso, este trabalho torna-se extremamente til como base para informar qualquer profissional interessado em conhecer a definio de cada componente do corpo de conhecimento da engenharia de software.

3.3 Aspectos positivos e Negativos

Um importante aspecto a ser expresso que contribuir para o maior conhecimento deste guia e seus componentes foi uma atividade concluda com xito. Destaca-se tambm o aprofundamento de temas de engenharia de software, o conhecimento de novos conceitos, a interligao destes conceitos com reas de outras cincias. Isto sem dvida foi um ponto positivo deste trabalho. A dificuldade em se traduzir alguns termos para a nossa lngua culta, talvez tenha sido um ponto a ser considerado como dificultoso. Na lngua inglesa, usam-se recursos como a unio de palavras cujo sentido se torna totalmente divergente das

235

palavras originais. No raras so as vezes onde o melhor termo a ser empregado para traduo normalmente no tem nada haver com as palavras usadas na lngua inglesa.

3.4 Futuro do Guia

Analisando o por qu de sua criao e observando os rumos que as tecnologias tm tomado no sentido da padronizao, fica fcil prever que tal ferramenta, se torna imprescindvel para o crescimento e estabilizao dessa relativamente nova disciplina de Engenharia de Software. Guias como PMBoK, BABOK e outros vem se tornando referncia para consulta e instrumento ao qual profissionais das reas correlatas encontram respostas. O SWEBOK, anlogo em significado ao PMBoK, tido como o PMI da Engenharia de Software e deve ser assimilado por todas as pessoas afetas a esta rea, pois o SWEBOK uma ferramenta bastante completa e est muito a frente de outras iniciativas desta amplitude. Finalizando, o Guia para para o Corpo de Conhecimento da Engenharia de Software no deve ser negligenciado pelas instituies de ensino at mesmo por se tratar de uma ferramenta de iniciativa da IEEE que tem como uma de suas finalidades servir de referncia global em assuntos considerados, de forma generalizada pela comunidade, como pertinentes a rea de Engenharia de Software.

236

Bibliografia

[Abr96] A. Abran and P.N. Robillard, Function Points Analysis: An Empirical Study of its Measurement Processes, IEEE Transactions on Software Engineering, vol. 22, 1996, pp. 895-909. [Bas92] V. Basili et al., The Software Engineering Laboratory An Operational Software Experience Factory, presented at the International Conference on Software Engineering, 1992. [Bec02] K. Beck, Test-Driven Development by Example,Addison-Wesley, 2002. [Bec99] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999. [Bei90] B. Beizer, Software Testing Techniques,International Thomson Press, 1990, Chap. 1-3, 5, 7s4, 10s3, 11, 13. [Boe03] B. Boehm and R. Turner, Using Risk to Balance Agile and Plan-Driven Methods, Computer, June 2003, pp. 57-66. [Com97] E. Comer, Alternative Software Life Cycle Models, presented at International Conference on Software Engineering, 1997. [Dav93] A.M.Davis, Software Requirements: Objects, Functions and States: Prentice-Hall,1993. [Gog93] J.Goguen and C.Linde, Techniques for Reuirements Elicitation, presented at International Symposium on Requirements Engineering, San Diego, California, 1993. [Dor02] M. Dorfman and R.H. Thayer, eds., Software Engineering, IEEE Computer Society Press, 2002, Vol. 1, Chap. 6, 8, Vol. 2, Chap. 3, 4, 5, 7, 8. [ElE99] K. El-Emam and N. Madhavji, Elements of Software Process Assessment and Improvement, IEEE Computer Society Press, 1999. [Fen98] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, second ed., International Thomson Computer Press, 1998, Chap. 1-14. [Fen98] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, second ed., International Thomson Computer Press, 1998. [Fin94] A. Finkelstein, J. Kramer, and B. Nuseibeh, Software Process Modeling and Technology, Research Studies Press Ltd., 1994. [Fow90] P. Fowler and S. Rifkin, Software EngineeringProcess Group Guide, Software Engineering Institute, Technical Report CMU/SEI-90-TR-24, 1990 [Gol99] D. Goldenson et al., Empirical Studies of Software Process Assessment Methods [IEEE1074-97] IEEE Std 1074-1997, IEEE Standard forDeveloping Software Life Cycle Processes, IEEE, 1997. [IEEE12207.0-96] IEEE/EIA 12207.0-1996//ISO/ IEC12207:1995, Industry Implementation of Int. Std ISO/IEC 12207:95 [IEEE830-98] IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications: IEEE,1998 [ISO15504-98] ISO/IEC TR 15504:1998, Information Technology - Software Process Assessment (parts 1-9), ISO and IEC, 1998. [ISO15939-02] ISO/IEC 15939:2002, Software Engineering Software Measurement Process, ISO and IEC, 2002. [ISO9126-01] ISO/IEC 9126-1:2001, Software Engineering - Product Quality-Part 1: Quality Model, ISO and IEC, 2001. [Joh99] D. Johnson and J. Brodman, Tailoring the CMM for Small Businesses, Small Organizations, and Small Projects [Jor02] P. C. Jorgensen, Software Testing: A Craftsman's Approach, second edition, CRC Press, 2004, Chap. 2, 5-10, 12-15, 17, 20. [Kan01] C. Kaner, J. Bach, and B. Pettichord, Lessons Learned in Software Testing, Wiley Computer Publishing,

237

2001. [Kan99] C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, second ed., John Wiley & Sons, 1999, Chaps. 1, 2, 5-8, 11-13, 15. [Kot00] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques: John Wiley and Sons, 2000. [Lou95] P. Loucopulos and V. Karakostas, Systems Requirements Engineering: McGraw-Hill, 1995. [Pfl01] S. L. Pfleeger [Lyu96] M.R. Lyu, Handbook of Software Reliability Engineering, Mc-Graw-Hill/IEEE, 1996, Chap. 2s2.2, 5-7. [McF96] B. McFeeley, IDEAL: A Users Guide for Software Process Improvement, Software Engineering [Moi98] D. Moitra, Managing Change for Software Process Improvement Initiatives: A Practical Experience- Based Approach [Mus99] J. Musa, Software Reliability Engineering: More Reliable Software, Faster Development and Testing, McGraw-Hill, 1999. [OMG02] Object Management Group, Software Process Engineering Metamodel Specification, 2002, em http://www.omg.org/docs/formal/02-11-14.pdf. [Per95] W. Perry, Effective Methods for Software Testing,John Wiley & Sons, 1995, Chap. 1-4, 9, 10-12, 17, 19-21. [Pfl01] S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice Hall, 2001. [Pre04] R.S. Pressman, Software Engineering: A Practitioners Approach, sixth ed., McGraw-Hill, 2004. [Rei02] D.J. Reifer, ed., Software Management, IEEE Computer Society Press, 2002, Chap. 1-6, 7-12, 13. [Rob99] S. Robertson and J. Robertson, Mastering the Requirements Process: Addison-Wesley, 1999. [San98] M. Sanders, The SPIRE Handbook: Better, Faster, Cheaper Software Development in Small Organisations, European Commission, 1998. [SEI01] Software Engineering Institute, Capability Maturity Model Integration, v1.1, 2001, em [SEL96] Software Engineering Laboratory, Software Process Improvement Guidebook, NASA/GSFC, [Som05] I. Sommerville, Software Engineering, Seventh ed: Addison-Wesley, 2005. [Som97] I. Sommerville and P. Sawyer, Requirements engineering: A Good Practice Guide, John Wiley and Sons, 1997, Chap. 1-2. [Sti99] H. Stienen, Software Process Assessment and Improvement: 5 Years of Experiences with Bootstrap. [Tha97] R.H. Thayer, ed., Software Engineering Project Management, IEEE Computer Society Press, 1997 [VIM93] ISO VIM, International Vocabulary of Basic and General Terms in Metrology, ISO, 1993. [You01] R. R. You, Effective Requirements Practices: Addison-Wesley, 2001. [Zhu97] H. Zhu, P.A.V. Hall and J.H.R. May, Software Unit Test Coverage and Adequacy (Har98) D. Harel and M. Politi, Modeling Reactive Systems with Statecharts: The Statemate Approach, McGraw-Hill, 1998. (Hen99) S.M. Henry and K.T. Stevens, Using Belbins Leadership Role to Improve Team Effectiveness: An Empirical Investigation, Journal of Systems and Software, vol. 44, 1999, pp. 241-250. (Her98) J. Herbsleb, Hard Problems and Hard Science: On the Practical Limits of Experimentation, IEEE TCSE (Hoh99) L. Hohmann, Coaching the Rookie Manager, IEEE Software, January/February 1999, pp. 16-19. (Hsi96) P. Hsia, Making Software Development Visible, IEEE Software, March 1996, pp. 23-26. (Hum95) W. Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995. (Hum97) W.S. Humphrey, Managing Technical People: Innovation, Teamwork, and the Software Process: AddisonWesley, 1997. (Hum99) W. Humphrey, An Introduction to the Team Software Process, Addison-Wesley, 1999. (Hut94) D. Hutton, The Change Agents Handbook: A Survival Guide for Quality Improvement Champions, Irwin, 1994. (IEEE1044-93) IEEE Std 1044-1993 (R2002), IEEE Standard for the Classification of Software Anomalies, IEEE, 1993. (IEEE1061-98) IEEE Std 1061-1998, IEEE Standard for a Software Quality Metrics Methodology, IEEE, 1998. (IEEE1074-97) IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes, IEEE, 1997.

238

(IEEE1219-98) IEEE Std 1219-1998, IEEE Standard for Software Maintenance, IEEE, 1998. (IEEE1220-98) IEEE Std 1220-1998, IEEE Standard for the Application and Management of the Systems Engineering Process, IEEE, 1998. (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes, IEEE, 1996. (IEEE12207.1-96) IEEE/EIA 12207.1-1996, Industry Implementation of Int. Std ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes -Life Cycle Data, IEEE, 1996. (IEEE12207.2-97) IEEE/EIA 12207.2-1997, Industry Implementation of Int. Std ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes -Implementation Considerations, IEEE, 1997. (IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/IEC14143-1:1998, Information Technology-Software MeasurementFunctional Size Measurement-Part 1: Definitions of Concepts, IEEE, 2000. (IEEE1517-99) IEEE Std 1517-1999, IEEE Standard for Information Technology-Software Life Cycle ProcessesReuse Processes, IEEE, 1999. (IEEE1540-01) IEEE Std 1540-2001//ISO/IEC16085:2003, IEEE Standard for Software Life Cycle Processes-Risk Management, IEEE, 2001. (IEEE610.12-90) IEEE Std 610.12-1990 (R2002), IEEE Standard Glossary of Software Engineering Terminology, IEEE, 1990. (ISO14674-99) ISO/IEC 14674:1999, Information Technology - Software Maintenance, ISO and IEC, 1999. (ISO15288-02) ISO/IEC 15288:2002, Systems Engineering-System Life Cycle Process, ISO and IEC, 2002. (ISO15504-98) ISO/IEC TR 15504:1998, Information Technology - Software Process Assessment (parts 1-9), ISO and IEC, 1998. (ISO15939-02) ISO/IEC 15939:2002, Software Engineering-Software Measurement Process, ISO and IEC, 2002. (ISO19761-03) ISO/IEC 19761:2003, Software Engineering-Cosmic FPP-A Functional Size Measurement Method, ISO and IEC, 2003. (ISO20926-03) ISO/IEC 20926:2003, Software Engineering-IFPUG 4.1 Unadjusted Functional Size Measurement Method-Counting Practices Manual, ISO and IEC, 2003. (ISO20968-02) ISO/IEC 20968:2002, Software Engineering-MK II Function Point Analysis Counting Practices Manual, ISO and IEC, 2002. (ISO90003-04) ISO/IEC 90003:2004, Software and Systems Engineering - Guidelines for the Application of ISO9001:2000 to Computer Software, ISO and IEC, 2004. (ISO9001-00) ISO 9001:2000, Quality Management Systems-Requirements, ISO, 1994. (ISO9126-01) ISO/IEC 9126-1:2001, Software Engineering-Product Quality-Part 1: Quality Model, ISO and IEC, 2001. (Jac98) M. Jackman, Homeopathic Remedies for Team Toxicity, IEEE Software, July/August 1998, pp. 43-45. (Kan02) S.H. Kan, Metrics and Models in Software Quality Engineering, second ed., Addison-Wesley, 2002. (Kan97) K. Kansala, Integrating Risk Assessment with Cost Estimation, IEEE Software, May/June 1997, pp. 61-67. (Kar96) D.W. Karolak, Software Engineering Risk Management, IEEE Computer Society Press, 1996. (Kar97) J. Karlsson and K. Ryan, A Cost-Value Aproach for Prioritizing Requirements, IEEE Software, September/October 1997, pp. 87-74. (Kau99) K. Kautz, Making Sense of Measurement for Small Organizations, IEEE Software, March/April 1999, pp. 1420. (Kei98) M. Keil et al., A Framework for Identifying Software Project Risks, Communications of the ACM, vol. 41, iss. 11, 1998, pp. 76-83. (Kel98) M. Kellner et al., Process Guides: Effective Guidance for Process Participants, presented at the 5th International Conference on the Software Process, 1998. (Ker99) B. Kernighan and R. Pike, Finding Performance Improvements, IEEE Software, March/April 1999, pp. 61-65. (Kit97) B. Kitchenham and S. Linkman, Estimates, Uncertainty, and Risk, IEEE Software, May/June 1997, pp. 69-74. (Kit98) B. Kitchenham, Selecting Projects for Technology Evaluation, IEEE TCSE Software Process Newsletter, (Kra99) H. Krasner, The Payoff for Software Process Improvement: What It Is and How to Get It, presented at

239

Elements of Software Process Assessment and Improvement, 1999. (Kri99) M.S. Krishnan and M. Kellner, Measuring Process Consistency: Implications for Reducing Software Defects, IEEE Transactions on Software Engineering, vol. 25, iss. 6, November/December 1999, pp. 800-815. (Lat98) F. v. Latum et al., Adopting GQM-Based Measurement in an Industrial Environment, IEEE Software, January-February 1998, pp. 78-86. (Leu96) H.K.N. Leung, A Risk Index for Software Producers, Software Maintenance: Research and Practice, vol. 8, 1996, pp. 281-294. (Lis97) T. Lister, Risk Management Is Project Management for Adults, IEEE Software, May/June 1997, pp. 20-22. (Lyu96) M.R. Lyu, Handbook of Software Reliability Engineering, Mc-Graw-Hill/IEEE, 1996. (Mac96) K. Mackey, Why Bad Things Happen to Good Projects, IEEE Software, May 1996, pp. 27-32. (Mac98) K. Mackey, Beyond Dilbert: Creating Cultures that Work, IEEE Software, January/February 1998, pp. 48-49. (Mad94) N. Madhavji et al., Elicit: A Method for Eliciting Process Models, presented at Proceedings of the Third International Conference on the Software Process, 1994. (Mad97) R.J. Madachy, Heuristic Risk Assessment Using Cost Factors, IEEE Software, May/June 1997, pp. 51-59. (Mas95) S. Masters and C. Bothwell, CMM Appraisal Framework - Version 1.0, Software Engineering Institute (McC96) S.C. McConnell, Rapid Development: Taming Wild Software Schedules, Microsoft Press, 1996. (McC97) S.C. McConnell, Software Project Survival Guide, Microsoft Press, 1997. (McC99) S.C. McConnell, Software Engineering Principles, IEEE Software, March/April 1999, pp. 6-8. (Moy97) T. Moynihan, How Experienced Project Managers Assess Risk, IEEE Software, May/June 1997, pp. 35-41. (McG01) J. McGarry et al., Practical Software Measurement: Objective Information for Decision Makers, AddisonWesley, 2001. (Mcg93) C. McGowan and S. Bohner, Model Based Process Assessments, presented at International Conference on Software Engineering, 1993. (McG94) F. McGarry et al., Software Process Improvement in the NASA Software Engineering Laboratory, Software Engineering Institute CMU/SEI-94- TR-22, 1994, em http://www.sei.cmu.edu/pub/documents/94.reports/pdf/ tr22.94.pdf. (Nak91) T. Nakajo and H. Kume, A Case History Analysis of Software Error Cause-Effect Relationship, IEEE Transactions on Software Engineering, vol. 17, iss. 8, 1991. (Ncs98) P. Ncsi, Managing OO Projects Better, IEEE Software, July/August 1998, pp. 50-60. (Nol99) A.J. Nolan, Learning From Success, IEEE Software, January/February 1999, pp. 97-105. (Off97) R.J. Offen and R. Jeffery, Establishing Software Measurement Programs, IEEE Software, March/April 1997, pp. 45-53. (Par96) K.V.C. Parris, Implementing Accountability, IEEE Software, July/August 1996, pp. 83-93. (Pau94) M. Paulk and M. Konrad, Measuring Process Capability Versus Organizational Process Maturity, presented at 4th International Conference on Software Quality, 1994. (Pfl01) S.L. Pfleeger, Software Engineering: Theory and Practice, second ed., Prentice Hall, 2001. (Pfl97) S.L. Pfleeger, Assessing Measurement (Guest Editors Introduction), IEEE Software, March/April 1997, pp. 25-26. (Pfl97a) S.L. Pfleeger et al., Status Report on Software Measurement, IEEE Software, March/April 1997, pp. 33-43. (Pfl99) S.L. Pfleeger, Understanding and Improving Technology Transfer in Software Engineering, Journal of Systems and Software, vol. 47, 1999, pp. 111-124. (PMI00) Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute, 2000. (Put97) L.H. Putman and W. Myers, Industrial Strength Software Effective Management Using Measurement, IEEE Computer Society Press, 1997. (Rad85) R. Radice et al., A Programming Process Architecture, IBM Systems Journal, vol. 24, iss. 2, 1985, pp. 7990. (Rag89) S. Raghavan and D. Chand, Diffusing Software-Engineering Methods, IEEE Software, July 1989, pp. 81-90. (Rog83) E. Rogers, Diffusion of Innovations, Free Press, 1983.

240

(Rob99) P.N. Robillard, The Role of Knowledge in Software Development, Communications of the ACM, vol. 42, iss. 1, 1999, pp. 87-92. (Rod97) A.G. Rodrigues and T.M. Williams, System Dynamics in Software Project Management: Towards the Development of a Formal Integrated Framework, European Journal of Information Systems, vol. 6, 1997, pp. 51-66. (Rop97) J. Ropponen and K. Lyytinen, Can Software Risk Management Improve System Development: An Exploratory Study, European Journal of Information Systems, vol. 6, 1997, pp. 41-50. (Sch99) E. Schein, Process Consultation Revisited: Building the Helping Relationship, Addison-Wesley, 1999. (Sco92) R.L. v. Scoy, Software Development Risk: Opportunity, Not Problem, Software Engineering Institute, Carnegie Mellon University CMU/SEI-92-TR-30, 1992. (SEI95) Software Engineering Institute, The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995. (SEL96) Software Engineering Laboratory, Software Process Improvement Guidebook, Software Engineering Laboratory, NASA/GSFC, Technical Report SEL-95-102, April 1996, em http://sel.gsfc.nasa.gov/website/ (Sla98) S.A. Slaughter, D.E. Harter, and M.S. Krishnan, Evaluating the Cost of Software Quality, Communications of the ACM, vol. 41, iss. 8, 1998, pp. 67-73. (Sol98) R. v. Solingen, R. Berghout, and F. v. Latum, Interrupts: Just a Minute Never Is, IEEE Software, September/October 1998, pp. 97-103. (Som97) I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley & Sons, 1997. (SPC92) Software Productivity Consortium, Process Definition and Modeling Guidebook, Software Productivity Consortium, SPC-92041-CMC, 1992. (VIM93) ISO VIM, International Vocabulary of Basic and General Terms in Metrology, ISO, 1993. (Vot93) L. Votta, Does Every Inspection Need a Meeting? ACM Software Engineering Notes, vol. 18, iss. 5, 1993, pp. 107-114. (Wei93) G.M. Weinberg, Quality Software Management, First-Order Measurement (Ch. 8, Measuring Cost and Value), vol. 2, 1993. (Whi95) N. Whitten, Managing Software Development Projects: Formulas for Success, Wiley, 1995. (Wil99) B. Wiley, Essential System Requirements: A Practical Guide to Event-Driven Methods, Addison- Wesley, 1999. (Yu94) E. Yu and J. Mylopolous, Understanding Why in Software Process Modeling, Analysis, and Design, presented at 16th International Conference on Software Engineering, 1994 (Zah98) S. Zahran, Software Process Improvement: Practical Guidelines for Business Success, Addison-Wesley, 1998. (Zel98) M. V. Zelkowitz and D. R. Wallace, Experimental Models for Validating Technology, Computer, vol. 31, iss. 5, 1998, pp. 23-31. CMU/SEI-TR-95-001, 1995, em http://www.sei.cmu.edu/pub/documents/95.reports/pdf/tr001.95.pdf. http:/ /emec.mec.gov.br/ em 7 de janeiro de 2011 Http:/ /pt.wikipedia.org/wiki/Friedrich_Ludwig_Bauer em 11/01/2011 Http:/ /wapedia.mobi/pt/engenharia_de_software em 11/01/11 colocar referncia Institute CMU/SEI-96-HB-001, 1996, em http://www.sei.cmu.edu/pub/documents/96.reports/pdf/hb001.96.pdf. Method Description, Software Engineering Institute CMU/SEI-96-TR-007, 1996, em http://www.sei.org/eoc/G47/index.html. Software Process Newsletter, vol. 11, 1998, pp. 18-21, em http://www.seg.iit.nrc.ca/SPN. Technical Report SEL-95-102, April 1996, em http://sel.gsfc.nasa.gov/website/documents/online-doc/95-102.pdf.

241