SWEBOK traduzido

  • Upload
    mrogerio

  • View
    7.757

  • Download
    42

Embed Size (px)

DESCRIPTION

Este é o guia SWEBOK, leitura essencial para disciplinas de engenharia de software, traduzido para o português.

Citation preview

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

AgradeciemtosAgradeo 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.

ResumoEste 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.

2

SumrioResumo.............................................................................................................................................................................................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

3

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

4

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

5

Lista de abreviaturasADL 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

6

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

7

Lista de figurasFigura 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

8

1 Introduo 1.1 Formulao do problemaA 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.

9

1.2 Reviso de LiteraturaEsta 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 geraisPromover 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 JustificativaRoger 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 temaEste 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 pesquisaEste 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 trabalhoEste 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 Software2.1.1 HistriaEm 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 iniciaisO 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 SoftwareFigura 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 SistemasFigura 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 conhecimento2.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