Guia de Implementacao Parte 4 2011

MPS.
BR - Melhoria de Processo do Software Brasileiro
Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS
Este guia contm orientaes para a implementao do nvel D do Modelo de Referncia MR-MPS. VIGNCIA E TRANSIO: O Guia Geral:2009 entra em vigor em 30 de junho de 2011. Assim, a partir desta data podem ser realizadas avaliaes MPS usando o modelo de referncia MR-MPS:2011. Entretanto, fica definido um perodo de transio, de 30 de junho a 31 de dezembro de 2011, durante o qual podem ser realizadas avaliaes MPS usando o modelo de referncia MR-MPS:2011 ou a verso anterior MR-MPS:2009. A partir de 1 de janeiro de 2012 s sero vlidas avaliaes MPS usando o modelo de referncia MR-MPS:2011. As implementaes a serem feitas utilizando este Guia de Implementao devero levar em conta estas vigncias. Julho de 2011
Copyright 2011 - SOFTEX Direitos desta edio reservados pela Sociedade SOFTEX A distribuio ilimitada desse documento est sujeita a copyright ISBN 978-85-99334-27-0
Sumrio 1 2 3 4 Prefcio ............................................................................................................... 3 Introduo ........................................................................................................... 5 Objetivo ............................................................................................................... 6 Evoluindo do nvel E para o nvel D .................................................................... 6
5 Desenvolvimento de Requisitos (DRE) ............................................................... 7 5.1 Propsito.......................................................................................................... 7 5.2 Fundamentao terica ................................................................................... 9 5.3 Resultados esperados ................................................................................... 12 6 Integrao do Produto (ITP) .............................................................................. 19 6.1 Propsito........................................................................................................ 19 6.2 Fundamentao terica ................................................................................. 21 6.3 Resultados esperados ................................................................................... 23 7 Projeto e Construo do Produto (PCP)............................................................ 32 7.1 Propsito........................................................................................................ 32 7.2 Fundamentao terica ................................................................................. 33 7.3 Resultados esperados ................................................................................... 36 8 Validao (VAL) ................................................................................................ 42 8.1 Propsito........................................................................................................ 42 8.2 Fundamentao terica ................................................................................. 44 8.3 Resultados esperados ................................................................................... 46 9 Verificao (VER) .............................................................................................. 51 9.1 Propsito........................................................................................................ 51 9.2 Fundamentao terica ................................................................................. 53 9.3 Resultados esperados ................................................................................... 54 10 Os atributos de processo no nvel D .............................................................. 61 Referncias Bibliogrficas ........................................................................................ 62 Lista de colaboradores do Guia de Implementao Parte 4:2011 ......................... 66 Lista de colaboradores do Guia de Implementao Parte 4:2009 ......................... 67 Lista de colaboradores do Guia de Implementao Parte 4 verso 1.1 Julho/2007 ................................................................................................................................. 68 Lista de colaboradores do Guia de Implementao Parte 4 verso 1.0 Dezembro/2006 ........................................................................................................ 69
MPS.BR Guia de Implementao Parte 4:2011
2/69
Prefcio
O MPS.BR1 um programa mobilizador, de longo prazo, criado em dezembro de 2003, coordenado pela Associao para Promoo da Excelncia do Software Brasileiro (SOFTEX), que conta com apoio do Ministrio da Cincia e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Servio Brasileiro de Apoio s Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID). O objetivo do programa MPS.BR (acrnimo) a Melhoria de Processo do Software Brasileiro, com duas metas a alcanar a mdio e longo prazos: a) meta tcnica, visando criao e aprimoramento do modelo MPS, com resultados esperados tais como: (i) guias do modelo MPS; (ii) Instituies Implementadoras (II) credenciadas para prestar servios de consultoria de implementao do modelo de referncia MR-MPS; (iii) Instituies Avaliadoras (IA) credenciadas para prestar servios de avaliao seguindo o mtodo de avaliao MA-MPS; (iv) Consultores de Aquisio (CA) certificados para prestar servios de consultoria de aquisio de software e servios relacionados; b) meta de mercado, visando disseminao e adoo do modelo MPS, em todas as regies do pas, em um intervalo de tempo justo, a um custo razovel, tanto em PME (foco principal) quanto em grandes organizaes pblicas e privadas, com resultados esperados tais como: (i) criao e aprimoramento do modelo de negcio MN-MPS; (ii) cursos, provas e workshops; (iii) organizaes que implementaram o modelo MPS; (iv) organizaes com avaliao MPS publicada (prazo de validade de trs anos). O programa MPS.BR conta com duas estruturas de apoio para o desenvolvimento de suas atividades, o Frum de Credenciamento e Controle (FCC) e a Equipe Tcnica do Modelo (ETM). Por meio destas estruturas, o MPS.BR obtm a participao de representantes de universidades, instituies governamentais, centros de pesquisa e de organizaes privadas, os quais contribuem com suas vises complementares que agregam qualidade ao empreendimento. Cabe ao FCC: (i) emitir parecer que subsidie deciso da SOFTEX sobre o credenciamento de Instituies Implementadoras (II) e Instituies Avaliadoras (IA); (ii) monitorar os resultados das Instituies Implementadoras (II) e Instituies Avaliadoras (IA), emitindo parecer propondo SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. Cabe ETM apoiar a SOFTEX sobre os aspectos tcnicos relacionados ao Modelo de Referncia (MR-MPS) e Mtodo de Avaliao (MA-MPS), para: (i) criao e aprimoramento contnuo do MR-MPS, MA-MPS e seus guias especficos; (ii) capacitao de pessoas por meio de cursos, provas e workshops.
MPS.BR, MR-MPS, MA-MPS e MN-MPS so marcas da SOFTEX. A sigla MPS.BR est associada ao programa MPS.BR Melhoria do Processo de Software Brasileiro e a sigla MPS est associada ao modelo MPS Melhoria do Processo de Software. 3/69
. A criao e o aprimoramento deste Guia de Implementao so tambm atribuies da ETM, sendo que este guia faz parte do seguinte conjunto de documentos do modelo MPS:

Guia Geral:2009 [SOFTEX, 2011a]; Guia de Implementao (partes 1 a 11); Guia de Avaliao:2009 [SOFTEX, 2011b]; Guia de Aquisio:2009 [SOFTEX, 2011c].
Este Guia de Implementao fornece orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS, detalhando os processos contemplados nos respectivos nveis de maturidade e os resultados esperados com a implementao dos processos. O Guia de implementao est subdividido em onze partes, contemplando, respectivamente, os seguintes nveis de maturidade:

Parte 1: Fundamentao para Implementao do Nvel G do MR-MPS; Parte 2: Fundamentao para Implementao do Nvel F do MR-MPS:; Parte 3: Fundamentao para Implementao do Nvel E do MR-MPS; Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS; Parte 5: Fundamentao para Implementao do Nvel C do MR-MPS; Parte 6: Fundamentao para Implementao do Nvel B do MR-MPS; Parte 7: Fundamentao para Implementao do Nvel A do MR-MPS; Parte 8: Implementao do MR-MPS (Nveis G a A) em organizaes que adquirem software; Parte 9: Implementao do MR-MPS (Nveis G a A) em organizaes do tipo Fbrica de Software; Parte 10: Implementao do MR-MPS (Nveis G a A) em organizaes do tipo Fbrica de Teste; e Parte 11: Implementao e Avaliao do MR-MPS (Nveis G a A) em conjunto com o CMMI-DEV.
As alteraes deste Guia de Implementao em relao verso 2009 so decorrentes de:

mudanas realizadas na verso 2009 do Guia Geral; correo ortogrfica e gramatical; adequao das referncias bibliogrficas; incluso de notas explicativas contidas nas partes 8, 9 e 10 do Guia de Implementao.
4/69
Introduo
As mudanas que esto ocorrendo nos ambientes de negcios tm motivado as empresas a modificar estruturas organizacionais e processos produtivos, saindo da viso tradicional baseada em reas funcionais em direo a redes de processos centrados no cliente. A competitividade depende, cada vez mais, do estabelecimento de conexes nestas redes, criando elos essenciais nas cadeias produtivas. Alcanar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e servios correlatos, como dos processos de produo e distribuio de software. Desta forma, assim como para outros setores, qualidade fator crtico de sucesso para a indstria de software. Para que se tenha um setor de software competitivo, nacional e internacionalmente, essencial que os empreendedores do setor coloquem a eficincia e a eficcia dos seus processos em foco nas empresas, visando oferta de produtos de software e servios correlatos conforme padres internacionais de qualidade. Busca-se que o modelo MPS seja adequado ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, embora com especial ateno s micro, pequenas e mdias empresas. Tambm se espera que o modelo MPS seja compatvel com os padres de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competncia existente nos padres e modelos de melhoria de processo j disponveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princpios de engenharia de software de forma adequada ao contexto das empresas, estando em consonncia com as principais abordagens internacionais para definio, avaliao e melhoria de processos de software. O modelo MPS baseia-se nos conceitos de maturidade e capacidade de processo para a avaliao e melhoria da qualidade e produtividade de produtos de software e servios correlatos. Dentro desse contexto, o modelo MPS possui trs componentes: Modelo de Referncia (MR-MPS), Mtodo de Avaliao (MA-MPS) e Modelo de Negcio (MN-MPS). O modelo MPS est descrito por meio de documentos em formato de guias:
Guia Geral: contm a descrio geral do modelo MPS e detalha o Modelo de Referncia (MR-MPS), seus componentes e as definies comuns necessrias para seu entendimento e aplicao [SOFTEX, 2011a]. Guia de Aquisio: descreve um processo de aquisio de software. descrito de forma a apoiar as instituies que queiram adquirir produtos de software apoiando-se no MR-MPS [SOFTEX, 2011c]. Guia de Avaliao: descreve o processo e o mtodo de avaliao MA-MPS, os requisitos para avaliadores lderes, avaliadores adjuntos e Instituies Avaliadoras (IA) [SOFTEX, 2011b].
5/69
Guia de Implementao: srie de onze documentos que fornecem orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS. Objetivo
O Guia de Implementao fornece orientaes para implementar nas organizaes os nveis de maturidade descritos no Modelo de Referncia MR-MPS, detalhando os processos contemplados nos respectivos nveis de maturidade e os resultados esperados com a implementao dos processos. Este documento corresponde parte 4 do Guia de Implementao e aborda a implementao do nvel de maturidade D. Este documento destinado, mas no est limitado, a organizaes interessadas em utilizar o MR-MPS para melhoria de seus processos de software e a Instituies Implementadoras (II). O contedo deste documento informativo, ou seja, no se espera que uma organizao implementando o MR-MPS atenda a todos os itens citados na explicao referente aos resultados esperados. As observaes presentes neste documento procuram apenas explicitar elementos importantes na interpretao dos resultados esperados. Durante uma avaliao MPS, s requerido o atendimento aos resultados esperados definidos no Guia Geral. Os avaliadores MPS devem analisar se a implementao dos processos na organizao atende a cada resultado, com abertura a mltiplas formas vlidas de implementao. 4 Evoluindo do nvel E para o nvel D
A implementao do nvel E numa organizao tem como foco principal a padronizao dos processos da organizao, por meio da definio de processos padro, o que inclui, alm dos processos do nvel E, todos os processos que pertencem aos nveis G e F do MR-MPS. A evoluo do nvel E para o nvel D no apresenta novidades em termos dos processos e atributos de processo j implantados no nvel E, pois estes continuam com a mesma capacidade. A evoluo para o nvel D do MR-MPS implica, portanto, apenas na definio e implementao de cinco novos processos com o mesmo nvel de capacidade dos processos j implantados: Desenvolvimento de Requisitos (DRE), Integrao do Produto (ITP), Projeto e Construo do Produto (PCP), Validao (VAL) e Verificao (VER). Estes processos, junto com Gerncia de Requisitos (GRE), so geralmente mencionados como sendo relacionados engenharia do software propriamente dita. Os processos de engenharia esto intimamente relacionados e, portanto, deve-se evitar trat-los de forma isolada em uma abordagem meramente sequencial, mas execut-los de forma interativa e alinhada com o ciclo de vida definido. Os processos so descritos em ordem alfabtica nos guias, porm uma possvel sequncia de leitura mais compatvel com a ordem natural com que so executados dentro de um processo de desenvolvimento seria: Desenvolvimento de Requisitos (DRE), Projeto e Construo do Produto (PCP), Integrao do Produto (ITP), Verificao (VER) e Validao (VAL).
MPS.BR Guia de Implementao Parte 4:2011 6/69
Neste nvel so permitidas algumas excluses de resultados esperados de alguns processos conforme descrito nas Partes 8, 9 e 10 do Guia de Implementao. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) A maior diferena entre uma organizao do tipo Fbrica de Software e outros tipos de organizao est no Nvel D do MR-MPS. neste nvel que so inseridas as prticas relacionadas engenharia do produto de software. Como as Fbricas de Software tm por foco a fase de implementao (construo) do ciclo de vida, algumas atividades no so por ela realizadas, sendo, portanto, excludas do escopo da avaliao. Estas excluses so detalhadas nas prximas sees. A maior diferena entre uma organizao do tipo Fbrica de Teste e outros tipos de organizao est no nvel D do MR-MPS. neste nvel que so inseridas as prticas relacionadas aos testes de produto. Como as Fbricas de Teste tm por foco a verificao e validao, algumas atividades no so por ela realizadas, sendo, portanto, excludas do escopo da avaliao, conforme detalhado nas prximas sees. Estas excluses so detalhadas nas prximas sees. No h comentrios adicionais para este tipo de organizao.
Fbrica de Teste (Parte 10)
Desenvolvimento de Requisitos (DRE)
5.1 Propsito O propsito do processo Desenvolvimento de Requisitos definir os requisitos do cliente, do produto e dos componentes do produto. Estes trs tipos de requisitos atendem as diferentes necessidades de todos os envolvidos no projeto. Inicialmente as necessidades, expectativas, restries e interfaces do cliente so levantadas e traduzidas em requisitos do cliente. Posteriormente os requisitos do cliente so refinados e descritos em termos tcnicos originando os requisitos funcionais e no-funcionais do produto e dos componentes do produto. Uma definio desses requisitos, bem como dos cenrios e conceitos operacionais requeridos tambm devem ser elaborados em um nvel de detalhe que permita a realizao de projetos (design) tcnicos e a construo da soluo do software para resolver o problema em questo. Os requisitos devem ser analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manuteno de um produto.
O Guia Geral [[SOFTEX, 2011a]] define componente de produto como uma parte do produto final ou algo usado no seu desenvolvimento, por exemplo, um subproduto, um processo ou uma ferramenta, que faz parte da entrega. Os componentes so integrados em sucessivos nveis para compor o produto final. Um produto definido como artefato associado execuo de um processo que se pretende entregar para um cliente ou usurio final [[SOFTEX, 2011a]]. Os resultados esperados deste processo esto relacionados aos resultados esperados dos processos Projeto e Construo do Produto (PCP), Gerncia de Requisitos (GRE), Verificao (VER) e Validao (VAL), ou por serem produtos requeridos para sua execuo ou por terem uma interface com o processo propriamente dito. O conjunto de requisitos produzido pelo Desenvolvimento de Requisitos (DRE), por exemplo, o produto de trabalho requerido para se iniciar o processo Projeto e Construo do Produto (PCP). De forma semelhante, tanto os requisitos do cliente quanto os requisitos funcionais e no-funcionais do produto e de componentes do produto so produtos de trabalho que esto sob o escopo do processo Gerncia de Requisitos (GRE). Finalmente, existe uma interseo direta do ltimo resultado esperado deste processo (DRE8 Os requisitos so validados) com o processo Validao (VAL).
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes adquirentes de software o nico resultado esperado obrigatrio DRE1. Os demais resultados podem ser excludos, de acordo com o tipo de aquisio do projeto. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. De qualquer forma, mesmo quando no executa uma atividade do processo, responsabilidade da organizao adquirente monitorar a execuo do processo pelo fornecedor. Fbrica de Software (Parte 9) Para estas organizaes, apenas o resultado DRE1 obrigatrio. Os demais resultados podem ser excludos. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. O resultado DRE1 pode ser utilizado para a compreenso e aceitao das especificaes que, no mbito de uma Fbrica de Software, constituem as necessidades do projeto. Como no existem outras especificidades para organizaes do tipo Fbrica de Software, no foram includos comentrios nos resultados esperados.
8/69
Para estas organizaes, apenas o resultado DRE1 obrigatrio. A aprovao das excluses responsabilidade do avaliador lder, dependendo do tipo de teste que ser efetuado. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. O resultado DRE1 pode ser utilizado para compreenso e aceitao dos requisitos que sero utilizados para testes. Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.
5.2 Fundamentao terica Requisitos so a base de todo projeto de software. Um requisito uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir os seus objetivos [PFLEEGER, 2004]. No SWEBOK [IEEE, 2004], um requisito descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real. De acordo com o IEEE Software Engineering Standards, um requisito descrito de duas formas: (i) uma condio ou capacidade necessria para um usurio resolver um problema ou alcanar um objetivo, ou (ii) uma condio ou uma capacidade que deve ser alcanada ou estar presente num sistema para satisfazer um contrato, padro, especificao ou outro documento formalmente imposto. Um desenvolvimento de requisitos criterioso condio fundamental para o sucesso do projeto, pois os requisitos formam o alicerce para todo o ciclo do projeto, do desenvolvimento at a manuteno. Diferentes tipos de requisitos precisam ser considerados durante o desenvolvimento. Os requisitos do cliente expressam os resultados desejados para superar os problemas reais. Os requisitos funcionais e no-funcionais do produto2 definem as solues computacionais desenvolvidas utilizando sistemas novos e existentes [ALEXANDER e ROBERTSON, 2004]. Estes tipos de requisitos precisam ser pensados de maneira diferente, tendo suas definies e correlaes apresentadas de forma explcita. Segundo SOMMERVILLE [SOMMERVILLE, 2003], alguns dos problemas comuns no desenvolvimento de requisitos so resultantes da falta de uma ntida separao entre esses diferentes nveis de descrio de requisitos. Desenvolver requisitos inclui as seguintes atividades:
Elicitao, anlise, validao e comunicao das necessidades, expectativas e restries dos clientes, para obter os requisitos dos clientes, que constituem um entendimento sobre o que satisfar os envolvidos;
Os requisitos do produto podem se referir tanto aos requisitos de um sistema quanto aos produtos de software que o compem. 9/69
Coleta e coordenao das necessidades dos envolvidos, com priorizao e negociao de possveis conflitos; Estabelecimento dos requisitos do cliente; Estabelecimento dos requisitos funcionais e no-funcionais do produto e dos componentes do produto consistentes com os requisitos dos clientes.
A Engenharia de Requisitos definida como o processo de descobrir, analisar, documentar e verificar as funes e restries do sistema [SOMMERVILLE, 2003] e pode ser dividida em dois grupos de atividades relacionadas: o Desenvolvimento de Requisitos (que inclui as atividades relacionadas Elicitao, Anlise e Modelagem) e a Gerncia de Requisitos (incluindo as atividades de Identificao, Rastreabilidade e Gerncia de Mudanas). O Desenvolvimento de Requisitos cria e interpreta os requisitos e a Gerncia de Requisitos organiza, relaciona os requisitos entre si e com outros produtos de trabalho e mantm os registros destes requisitos. Alguns dos maiores desafios na criao e manuteno de produtos de software esto diretamente relacionados aos requisitos [COAD e YOURDON, 1992]: (i) compreenso do domnio do problema; (ii) comunicao efetiva com reais usurios do produto; e (iii) evoluo contnua dos requisitos. O processo Desenvolvimento de Requisitos prope atividades para minimizar os riscos associados aos desafios (i) e (ii), enquanto que a combinao dos processos Gerncia de Requisitos e Desenvolvimento de Requisitos objetiva minimizar os riscos causados pelo desafio (iii). De acordo com o SWEBOK [IEEE, 2004], o Desenvolvimento de Requisitos inclui os seguintes passos:

Elicitao de requisitos identificao de forma proativa dos requisitos; Anlise e negociao de requisitos exame dos requisitos coletados e negociao com os envolvidos, caso haja requisitos conflitantes; Especificao e Modelagem dos requisitos documentao e criao de modelos dos requisitos com o propsito de obter uma melhor compreenso do problema a ser solucionado; e Validao de requisitos exame da especificao para garantir que inconsistncias, omisses e ambiguidades tenham sido detectadas e corrigidas.
A elicitao de requisitos se inicia com a aplicao de tcnicas apropriadas para identificar requisitos do cliente, considerando as necessidades, expectativas e restries impostas pelo cliente [PRESSMAN, 2005]. Existem diversas tcnicas para elicitao de requisitos, entre as principais esto: entrevistas, prototipao, tcnica FAST (como JAD) e brainstorming. Entrevista a tcnica mais comumente utilizada. Para potencializar seus resultados, necessrio planejamento e preparao cuidadosos, identificando-se os candidatos entrevista, definindo seus objetivos e listando as questes a serem obrigatoriamente formuladas. A prototipao inclui os seguintes passos: estudo preliminar dos requisitos do usurio; construo do prottipo; e seu exame pelos usurios. Prottipos so
apenas modelos do produto final e no precisam ser completos. So muito teis para avaliao de requisitos crticos ou complexos. Tcnicas facilitadas de especificao de aplicaes ou tcnicas FAST (Facilitated Application Specification Techniques) encorajam a criao de uma equipe conjunta de clientes e desenvolvedores que trabalham juntos para [PRESSMAN, 2005]: identificar problemas; propor elementos da soluo; negociar diferentes abordagens; e especificar um conjunto preliminar de requisitos. Utilizando uma tcnica FAST, uma reunio conduzida com participao de engenheiros de software e de clientes. So estabelecidas regras para preparao e participao dessa reunio. sugerida uma agenda, com foco no problema a ser resolvido, e um facilitador controla a reunio. Um mecanismo de definio utilizado (como flip-charts, quadro negro, planilhas). A meta identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos. As abordagens mais populares de FAST so: JAD (tcnica desenvolvida pela IBM) e The Method (criada pela Performance Resources Inc.). A tcnica Brainstorming consiste na conduo de reunies onde as pessoas sugerem e exploram ideias, sendo uma tcnica muito utilizada para a gerao de novas ideias. Uma sesso brainstorming consiste em duas fases: Gerao de Ideias, na qual os participantes so encorajados a propor ideias sem crticas pelos demais; e Consolidao, na qual feita a avaliao de viabilidade e a priorizao das ideias propostas. Aps a identificao, os requisitos devem ser modelados para se obter uma melhor compreenso do produto a ser desenvolvido. O modelo dos requisitos deve focar naquilo que o produto deve fazer, no em como ele o faz. Geralmente, usa-se uma notao grfica para descrever as informaes transformadas pelo produto, o processamento das informaes, o comportamento do produto e outras caractersticas [PRESSMAN, 2005]. Os principais paradigmas de modelagem de requisitos so: Anlise Estruturada e Anlise Orientada a Objetos. Na Anlise Estruturada so criados modelos que representam o fluxo e o contedo da informao (dados e controle), o produto dividido em participaes funcionais e comportamentais e a essncia daquilo que deve ser construdo descrita. Os seguintes modelos so geralmente elaborados:

Diagramas de fluxo de dados (DFDs); Diagrama de Transio de Estado (DTE); Dicionrio de Dados.
Na Anlise Orientada a Objetos o objetivo modelar os conceitos (objetos) do domnio do produto, seus relacionamentos e comportamentos. Esse modelo refinado continuamente at se obter um modelo com detalhe suficiente para sua implementao na forma de cdigo executvel. Dentre os modelos elaborados esto:

Modelo de Casos de Uso e Cenrios; Modelo de Classes; Diagramas de Sequncia e de Atividade;

11/69
Diagramas de Estados.
5.3 Resultados esperados 5.3.1 DRE1 - As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas interfaces, so identificadas O alcance deste resultado esperado envolve a utilizao de mtodos adequados para identificar necessidades, expectativas, restries e interfaces do cliente. Devese buscar o envolvimento de representantes do cliente e utilizar tcnicas de elicitao de requisitos para identificar de forma proativa requisitos adicionais no discutidos explicitamente pelos clientes. Alguns exemplos de tcnicas de elicitao de requisitos so [IEEE, 2004; SEI, 2010; PFLEEGER, 2004; PRESSMAN, 2005; SOMMERVILLE, 2003]: entrevistas; questionrios; construo de cenrios operacionais e anlise de tarefas do usurio final; prottipos e modelos; tcnicas facilitadoras de especificao de aplicaes (como, por exemplo, JAD); casos de uso; brainstorming; observao de produtos e ambientes existentes; anlise de casos de negcio; estudo de fontes de informao como documentos, padres ou especificaes; etnografia; QFD (Quality Function Deployment); e engenharia reversa (para sistemas legados). Alm dessas tcnicas, estrias de usurios tambm podem ser utilizadas quando se desenvolve utilizando mtodos geis. Qualquer que seja a tcnica utilizada, o alcance deste resultado deve ser evidenciado por meio de registros que mostrem o levantamento das necessidades, expectativas e restries do cliente em relao ao produto e suas interfaces. Em algumas situaes, a organizao, devido ao seu ramo de atividade, pode receber os requisitos do cliente ou requisitos funcionais e no-funcionais do produto e dos componentes do produto j especificados. Mesmo neste caso necessrio que haja reviso do conjunto de requisitos recebido, de forma proativa, buscando identificar incorrees, inconsistncias e requisitos ausentes. Como resultado, haver uma nova lista de requisitos ou a confirmao da anterior, caso no tenham sido feitas alteraes.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)
Este resultado obrigatrio qualquer que seja o tipo de aquisio.
Sem comentrio adicional para este resultado.
5.3.2 DRE2 - Um conjunto definido de requisitos do cliente especificado e priorizado a partir das necessidades, expectativas e restries identificadas As necessidades, expectativas e restries do cliente identificadas anteriormente so traduzidas em requisitos do cliente. Para que isso ocorra pode ser necessria a resoluo de conflitos entre os fornecedores de requisitos e demais envolvidos no projeto relacionados especificao de requisitos. Alm disso, podem surgir questes relevantes a serem verificadas e/ou validadas. A priorizao dos requisitos auxilia na determinao do escopo do projeto, iterao ou incremento e garante que os requisitos funcionais e no funcionais que sejam crticos sejam tratados mais rapidamente [SEI, 2010].
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor. Sem comentrio adicional para este resultado.
5.3.3 DRE3 - Um conjunto de requisitos funcionais e no-funcionais, do produto e dos componentes do produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente O alcance deste resultado esperado compreende a consolidao das necessidades, expectativas e restries do cliente em um conjunto de requisitos funcionais e nofuncionais do produto e dos componentes do produto. Definir os requisitos funcionais envolve analisar os requisitos do cliente para identificar as funes requeridas no produto. Requisitos funcionais descrevem as funes ou os servios que se espera que o sistema fornea. Um requisito funcional descreve uma interao entre o sistema e seu ambiente [IEEE, 2004; SEI, 2010; SOMMERVILLE, 2003]. So exemplos de requisitos funcionais: gerar relatrio com os resultados dos testes clnicos de um paciente; formatar um texto; e cadastrar cliente.
13/69
Requisitos no-funcionais so requisitos que expressam condies ou qualidades especficas que o produto e/ou componentes do produto deve atender. Em vez de informar o que o produto far, os requisitos no-funcionais apontam restries que devem ser obedecidas. Requisitos no-funcionais so algumas vezes conhecidos como restries ou requisitos de qualidade [IEEE, 2004; SEI, 2010]. So exemplos de requisitos no-funcionais: tempo de resposta mximo para consultas deve ser trs segundos; ou, o sistema deve estar disponvel para o cliente sete dias na semana, vinte e quatro horas por dia. Requisitos no-funcionais podem ser classificados de acordo com seu tipo em diferentes categorias como: requisitos de usabilidade; requisitos de desempenho; requisitos de confiabilidade; entre outros [SOMMERVILLE, 2003]. Ao especificar os requisitos funcionais e no-funcionais possvel perceber falta de informaes, inconsistncias e erros. Nessas situaes, necessrio buscar informaes complementares e resolver as inconsistncias detectadas. Durante a execuo de um projeto, podem ocorrer mudanas nos requisitos. Essas mudanas devem ser gerenciadas por meio do processo Gerncia de Requisitos (GRE) de forma a manter os requisitos funcionais e no-funcionais consistentes com os demais produtos de trabalho e minimizar o impacto das mudanas no projeto.
5.3.4 DRE4 - Os requisitos funcionais e no-funcionais de cada componente do produto so refinados, elaborados e alocados Alcanar este resultado esperado significa elaborar os requisitos funcionais e nofuncionais de cada componente do produto nos termos tcnicos necessrios para o desenvolvimento do produto e dos componentes do produto. Para refinar os requisitos funcionais e no-funcionais podem ser utilizadas tcnicas de modelagem como especificao de casos de uso de negcio, modelos de contexto [SOMMERVILLE, 2003] e outras como as citadas na seo .2. 5 Os requisitos do cliente podem ser descritos utilizando-se os termos usados pelos clientes e podem conter descries no-tcnicas. Os requisitos funcionais e nofuncionais de cada componente do produto so a expresso dos requisitos do
cliente em termos tcnicos, de modo a poderem guiar o projeto (design) do produto e dos componentes do produto. Requisitos funcionais podem ser descritos de muitas formas como, por exemplo: funes; opes do sistema; ou ainda como servios ou mtodos Orientados a Objetos (OO). Ao definir os requisitos funcionais e no-funcionais, uma prtica comum categorizar os requisitos em grupos, por meio de um critrio. Exemplos de critrios para esse fim so [CACHERO e KOCH, 2002]: propsitos similares, dependncia funcional e dados envolvidos. O alcance deste resultado esperado pode envolver:

Derivar requisitos funcionais e no-funcionais que resultem de decises de projeto (design), tais como seleo de tecnologia; Alocar requisitos funcionais e no-funcionais e restries para cada componente do produto; Estabelecer os relacionamentos entre os requisitos do cliente e os requisitos funcionais e no-funcionais de cada componente do produto, de acordo com o processo Gerncia de Requisitos.
Como indicador de alcance deste resultado, deve-se evidenciar que o conjunto de requisitos funcionais e no-funcionais foi refinado, detalhado e documentado ao longo do ciclo de vida para o desenvolvimento do produto e dos componentes do produto. Os registros das atualizaes realizadas nesses requisitos tambm devem ser documentados como evidncia do alcance deste resultado.
5.3.5 DRE5 - Interfaces internas e externas do produto e de cada componente do produto so definidas As interfaces internas e externas do produto e de cada componente do produto devem ser especificadas e documentadas de acordo com a arquitetura definida do produto. As definies dessas interfaces so teis para projetar e construir as unidades de cdigo dos componentes do produto, bem como para servir de base
para verificar a integrao entre cada componente do produto e para verificar a integrao do produto com outros elementos externos. As definies das interfaces geralmente so definidas em termos de tipos e formatos de dados de entrada e sada entre os componentes do produto e entre elementos do sistema, especificaes de protocolos de comunicao, entre outros.
5.3.6 DRE6 - Conceitos operacionais e cenrios so desenvolvidos O alcance deste resultado esperado exige o desenvolvimento de conceitos operacionais e cenrios para o produto e os componentes do produto. Um conceito operacional para um produto depende do projeto (design) da soluo e de um cenrio, portanto so elaborados quando as decises de projeto (design) so tomadas e os requisitos detalhados. Um cenrio uma sequncia de eventos possvel de ocorrer no uso de um produto e utilizado para tornar explcitas algumas necessidades dos envolvidos [SEI, 2010]. Uma forma possvel de descrever os cenrios utilizar a modelagem de cenrios sugerida pela UML, na qual o cenrio uma sequncia especfica de aes que ilustra o comportamento de um caso de uso. Ao descrever um caso de uso, geralmente os seguintes elementos so considerados:

Fluxo principal descreve uma sequncia de aes que sero executadas considerando que nada de errado acontecer durante a execuo das aes; Fluxos Alternativos descrevem o que acontece quando o ator (papel que interage com o sistema) faz uma escolha alternativa, diferente da descrita no fluxo principal, para alcanar seu objetivo. Fluxos alternativos podem descrever escolhas exclusivas entre si; Fluxos de Exceo correspondem descrio das situaes de exceo, quando algo inesperado ocorre na interao com o sistema; Pr-condio define que hipteses so assumidas como verdadeiras para que o cenrio tenha incio. Deve ser usada em casos de uso cuja realizao no faz
16/69
sentido em qualquer momento, mas somente quando o sistema est em um determinado estado com certas propriedades;
Ps-condio estado que o sistema alcana aps o caso de uso ter sido realizado. Definir o ambiente no qual o produto operar, incluindo limites e restries; Elaborar um conceito operacional detalhado para cada produto ou componente do produto que defina a interao do produto, do usurio final, do ambiente e que satisfaa as necessidades de operao, manuteno e apoio; Revisar conceitos operacionais e cenrios para refinar e descobrir novos requisitos.
Comentrios adicionais para implementao em diferentes tipos de organizao
O alcance deste resultado esperado pode abranger:

Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)
Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor. Sem comentrio adicional para este resultado.
5.3.7 DRE7 - Os requisitos so analisados, usando critrios definidos, para balancear as necessidades dos interessados com as restries existentes Este resultado visa garantir que os requisitos, em seus diferentes nveis, sejam analisados de forma a balancear as necessidades dos interessados com as restries de projeto existentes. Os requisitos podem ser analisados juntamente com cenrios, conceitos operacionais e definies detalhadas dos requisitos, para determinar se eles so necessrios, corretos, testveis e suficientes para atingir os objetivos e requisitos de alto nvel (requisitos do cliente) [SEI, 2010]. Tcnicas de Verificao podem ser utilizadas para garantir que:

Todos os requisitos tenham sido declarados de forma no ambgua; As inconsistncias, omisses e erros tenham sido detectados e corrigidos; Os requisitos de diferentes nveis estejam consistentes entre si.
O alcance deste resultado esperado pode compreender:

Analisar as necessidades, expectativas e restries dos envolvidos, com o objetivo de organiz-las e remover possveis conflitos; Analisar cenrios e conceitos operacionais para refinar as necessidades, restries e interfaces do cliente e descobrir novos requisitos; Analisar requisitos para assegurar que eles esto completos, so factveis e verificveis, de acordo com os critrios estabelecidos no processo Verificao (VER).
Para a anlise de balanceamento entre necessidades e restries podem ser utilizados modelos, simulaes, prottipos e avaliaes de riscos nos requisitos e na arquitetura funcional. Em [KELLNER et al., 1999] so apresentados os principais conceitos relacionados a simulao de processos de software.
5.3.8 DRE8 - Os requisitos so validados Este resultado esperado visa garantir que os requisitos sejam validados utilizando-se tcnicas adequadas, de forma a garantir que o produto ter o desempenho adequado quando instalado no seu ambiente alvo. A validao aumenta a confiana de que os requisitos definidos so capazes de guiar o desenvolvimento satisfatoriamente. Quanto mais cedo problemas forem identificados, menos retrabalho e custo sero necessrios para adequar os requisitos s expectativas do cliente. As tcnicas de validao so discutidas na seo que apresenta o processo Validao (VAL). Para atender a este resultado esperado, a validao deve estar de acordo com critrios estabelecidos pelo processo Validao (VAL).
18/69
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da responsabilidade por executar a validao ser do fornecedor. De qualquer forma, o adquirente participa das atividades de validao. Sem comentrio adicional para este resultado.
Integrao do Produto (ITP)
6.1 Propsito O propsito do processo Integrao do Produto compor os componentes do produto, produzindo um produto integrado consistente com seu projeto, e demonstrar que os requisitos funcionais e no-funcionais so satisfeitos para o ambiente alvo ou equivalente. O processo Integrao do Produto diz respeito a como integrar um produto e qual a sequncia de integrao a ser usada. Trata, tambm, da criao de um ambiente operacional no qual se possa implantar o produto satisfatoriamente; da documentao dos procedimentos e critrios de integrao do produto; de como assegurar a integrao correta das partes; e da entrega do produto. Os resultados esperados deste processo esto relacionados a resultados esperados dos processos Projeto e Construo do Produto (PCP), Verificao (VER), Validao (VAL), Gerncia de Decises (GDE), Gerncia de Configurao (GCO) e Gerncia de Requisitos (GRE). A interseo deste processo com o processo Projeto e Construo do Produto (PCP) est presente no resultado esperado referente ao estabelecimento do ambiente de integrao, no que diz respeito compra, reutilizao ou desenvolvimento do ambiente. Tambm est presente no resultado esperado referente ao gerenciamento das interfaces internas dos produtos e componentes do produto, no que diz respeito ao projeto de interfaces entre componentes do produto. A interseo deste processo com o processo Verificao (VER) est presente nos resultados esperados referentes verificao das interfaces, do ambiente de integrao, dos componentes do produto e do produto integrado, no que diz respeito realizao de testes de unidades, integrao e regresso, alm de revises por pares. De maneira similar, caso haja a necessidade de validar interfaces, ambiente
de integrao, componentes de produto ou produto integrado, pode ser identificada interao com o processo Validao (VAL). A interseo deste processo com o processo Gerncia de Decises (GDE) est presente nos resultados esperados relacionados ao desenvolvimento e escolha da estratgia de integrao, caso se deseje selecionar a estratgia de integrao de acordo com um processo formal de deciso. Tambm pode haver interseo no resultado esperado relacionado ao estabelecimento do ambiente de integrao, j que a deciso sobre adquirir, reutilizar ou desenvolver o ambiente tambm pode seguir um processo formal de seleo. A interseo deste processo com o processo Gerncia de Configurao (GCO) est presente no resultado esperado referente ao gerenciamento das interfaces internas dos produtos e componentes do produto, no que diz respeito ao controle das mudanas. Tambm existe relacionamento no resultado esperado referente entrega do produto e sua documentao ao cliente, no que diz respeito liberao do produto. A interseo deste processo com o processo Gerncia de Requisitos (GRE) est presente no resultado esperado referente ao gerenciamento das interfaces internas dos produtos e componentes do produto, no que diz respeito ao gerenciamento das mudanas. Tambm existe relacionamento no resultado esperado referente a testes de regresso, uma vez que se pode fazer uso de uma matriz de rastreabilidade.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes adquirentes de software o nico resultado esperado obrigatrio ITP9. Os demais resultados podem ser excludos, de acordo com o tipo de aquisio do projeto. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. De qualquer forma, mesmo quando no executa uma atividade do processo, responsabilidade da organizao adquirente monitorar a execuo do processo pelo fornecedor. Fbrica de Software (Parte 9) So permitidas excluses dos resultados esperados do processo, dependendo do escopo de atuao da Fbrica de Software. Caso a Fbrica de Software tenha em seu escopo de trabalho a realizao de atividades de integrao do cdigo desenvolvido, este processo dever estar presente, caso contrrio, poder ser excludo do escopo da avaliao. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados e processos devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. Como no existem especificidades para organizaes do tipo Fbrica
de Software, no foram includos comentrios nos resultados esperados. Fbrica de Teste (Parte 10) Em organizaes do tipo Fbrica de Teste so permitidas excluses de todos os resultados esperados de processo. Caso a Fbrica de Teste tenha no seu escopo de trabalho, a realizao de atividades de integrao de cdigo desenvolvido, este processo dever estar presente, caso contrrio, dever ser excludo do escopo da avaliao. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.
6.2 Fundamentao terica Em projetos pequenos, a integrao pode envolver apenas algumas classes ou arquivos que precisam funcionar juntos. Em projetos grandes, pode envolver milhares de programas e componentes que formam um sistema maior. Independentemente do tamanho, alguns princpios bsicos devem ser aplicados [McCONNELL, 2004]. A integrao do produto pode abranger tanto a integrao do software como a integrao do sistema. Na integrao do software, integram-se as unidades do software, produzindo itens de software integrados. Na integrao do sistema, integram-se os elementos do sistema (incluindo itens de software, itens de hardware, operaes manuais e outros sistemas, conforme necessrio) para produzir um sistema completo [ISO/IEC, 2008]. A integrao dos componentes do produto deve ser planejada, incluindo requisitos de teste, procedimentos, dados, responsabilidades e cronograma. Esse planejamento deve ser adequadamente documentado [ISO/IEC, 2008]. Um aspecto crtico da integrao de produtos o gerenciamento de interfaces internas e externas do produto ou componentes do produto, para garantir compatibilidade entre as interfaces [SEI, 2010]. Uma interface pode ser vista, de maneira geral, como sendo uma fronteira de comunicao entre componentes, tais como partes de um software, itens de hardware ou at mesmo um usurio. Normalmente se refere a uma abstrao que um componente fornece de si mesmo para o exterior. Segundo a ISO/IEC 12119 [ISO/IEC, 1994] uma interface uma fronteira compartilhada entre duas unidades funcionais, definida por caractersticas funcionais, caractersticas fsicas comuns de interconexo e outras caractersticas, conforme apropriado. Deve-se atentar para a gerncia de interfaces ao longo do projeto.
21/69
A ordem na qual se constroem os componentes do produto influencia na ordem na qual se pode integr-los, j que no se pode integrar o que ainda no foi construdo. Tanto a sequncia de construo como a de integrao so tpicos importantes a serem considerados, pois construir e integrar software em uma ordem errada pode tornar a codificao, os testes e a depurao mais difceis [McCONNELL, 2004]. Os testes de integrao tambm tm papel importante para garantir que as diferentes partes do produto possam interagir adequadamente em conjunto, de forma a atender corretamente aos requisitos funcionais e no-funcionais pretendidos [TIAN, 2005]. O teste de integrao o processo de verificar se os componentes, juntos, executam conforme est descrito nas especificaes e no projeto de programas. A partir deste momento, outros tipos de teste so realizados: teste funcional; teste de desempenho; teste de aceitao; e teste de instalao [PFLEEGER, 2004]. A integrao do produto mais que uma nica montagem dos componentes do produto ao final do projeto e da construo. A integrao do produto pode ser incremental, usando um processo iterativo de composio de componentes do produto, avaliao e composio de mais componentes do produto [SEI, 2010]. Uma integrao incremental oferece algumas vantagens em relao a uma abordagem em que o produto totalmente integrado de uma s vez, entre elas [McCONNELL, 2004]:

mais fcil localizar os erros, uma vez que a parte do produto que est sendo integrada menor; Os membros do projeto conseguem ver o resultado de seu trabalho mais cedo no projeto, o que aumenta sua motivao; Melhor monitoramento do progresso, uma vez que o gerente pode ver claramente que poro do produto est ou no est pronta; Melhor relacionamento com o cliente, que tambm consegue ver progressos mais concretos no projeto; Os componentes do produto so testados de forma mais abrangente, uma vez que os mesmos componentes podero ser testados diversas vezes ao longo dos testes de integrao das partes; possvel reduzir o tempo de desenvolvimento, pois possvel o paralelismo nas atividades do projeto.
importante que seja definida uma estratgia de regresso, uma vez que o produto certamente sofrer alteraes durante o seu desenvolvimento ou aps ser entregue ao cliente, decorrentes de manutenes (corretivas ou evolutivas) ou incluses de novos elementos (requisitos ou mdulos). Essa estratgia deve possibilitar que o produto seja testado novamente aps uma mudana ter sido realizada, de forma a garantir que modificaes ou correes no produto no afetem e danifiquem outras partes. Teste de regresso implica em executar novamente um conjunto de testes j conduzidos anteriormente para garantir que as mudanas realizadas no produziram efeitos colaterais indesejados [PRESSMAN, 2005].
22/69
O produto, depois de integrado, testado e empacotado, entregue ao cliente e instalado no ambiente pretendido para operao. De forma geral, alguns dos benefcios esperados pelo uso de uma abordagem cuidadosa de integrao de produtos [McCONNELL, 2004] podem ser resumidos em: (i) deteco de defeitos mais fcil; (ii) menos defeitos; (iii) menor tempo para se chegar a produtos ou partes de produtos funcionais; (iv) menor tempo total de desenvolvimento; (v) melhor relacionamento com o cliente; (vi) moral elevado da equipe; (vii) maior chance de se completar o projeto; (viii) estimativas de tempo mais confiveis; (ix) relatrios de status mais precisos; (x) maior qualidade do cdigo; e (xi) menos documentao. 6.3 Resultados esperados 6.3.1 ITP1 - Uma estratgia de integrao, consistente com o projeto (design) e com os requisitos do produto, desenvolvida e mantida para os componentes do produto Deve ser definida uma estratgia, incluindo procedimentos e critrios, para conduzir a integrao dos componentes do produto, determinando quais componentes sero integrados e qual ser a sequncia de integrao. importante que a estratgia de integrao escolhida seja consistente com o projeto (design), arquitetura e com os requisitos do produto. A estratgia de integrao a ser adotada composta pela determinao da sequncia de integrao. A sequncia de integrao fornece um apoio integrao incremental e avaliao de componentes do produto. Geralmente contm informaes sobre os produtos a serem integrados em cada incremento de integrao, alm das verificaes a serem realizadas usando as definies das interfaces entre os componentes do produto. Diversas estratgias de integrao diferentes podem ser encontradas na literatura, tais como [PFLEEGER, 2004; McCONNELL, 2004]:
Integrao Bottom-Up: Cada componente no nvel inferior da hierarquia do sistema desenvolvido e testado individualmente. Os prximos componentes a serem integrados e testados so aqueles que chamam os que foram previamente integrados. Essa abordagem seguida repetidamente at que todos os componentes sejam considerados; Integrao Top-Down: Reverso da abordagem Bottom-Up. O nvel mais superior (normalmente um componente de controle principal) desenvolvido e testado. Em seguida, todos os componentes chamados pelo(s) componente(s) testado(s) so desenvolvidos, combinados e testados como uma grande unidade. Essa abordagem seguida repetidamente at que todos os componentes sejam considerados; Integrao Sanduche: Combinao entre as abordagens Top-Down e BottomUp. Primeiro, so integrados e testados os componentes de mais alto nvel (TopDown). Depois, so integrados e testados os componentes de nvel mais inferior (Bottom-Up). Ento, a integrao e os testes convergem para os componentes
23/69
do sistema de nvel intermedirio. Essas trs camadas justificam o nome da abordagem;
Integrao Orientada a Riscos: Identifica-se o nvel de riscos associado a cada componente. Com isso, analisam-se quais sero as partes mais difceis de implementar; estas so desenvolvidas e integradas primeiro. As partes mais simples so desenvolvidas, integradas e testadas mais tarde; Integrao Orientada a Funcionalidade: Consiste em desenvolver, integrar e testar uma funcionalidade por vez. Assim, as funcionalidades vo sendo integradas de maneira incremental, compondo a funcionalidade total do sistema; Integrao em Forma de T: construda e integrada uma parte completa do sistema, do nvel mais alto ao mais baixo de hierarquia, permitindo a verificao de questes arquiteturais (parte vertical do T). Depois disso, as demais funcionalidades e partes do sistema so construdas e integradas. Normalmente usada em conjunto com as abordagens orientadas a riscos e a funcionalidades.
Uma boa prtica consiste em definir sequncias de integrao alternativas para um dado produto, bem como critrios para a seleo de alternativas, e, ento, selecionar, dentre as alternativas, baseando-se nos critrios definidos, aquela que a mais adequada. Por exemplo, em um projeto se poderia selecionar uma dentre as seis estratgias de integrao descritas acima com base em critrios como: experincia da equipe no uso da estratgia; tempo necessrio para entrega de produtos intermedirios; complexidade do produto; entre outros. importante, tambm, documentar as razes pelas quais uma estratgia de integrao foi selecionada e no outra. A sequncia de integrao, assim como a estratgia de integrao a ser adotada, deve ser revista, sempre que necessrio, uma vez que esta pode ser afetada por diversos fatores, como, por exemplo, atrasos na construo, mudanas no cronograma de entregas, mudanas nas prioridades de construo.
24/69
6.3.2 ITP2 - Um ambiente para integrao dos componentes do produto estabelecido e mantido O ambiente de integrao necessrio em cada etapa do processo de integrao do produto pode incluir ferramentas de testes, simuladores (funcionando como componentes de produtos ainda indisponveis), partes de equipamentos ou componentes do produto reais, dispositivos de armazenamento, entre outros. O objetivo deste resultado esperado garantir que o ambiente para integrao dos componentes do produto foi definido e mantido conforme necessrio. O conjunto de requisitos para o ambiente de integrao do sistema pode conter requisitos de equipamentos, software ou outros recursos. Estes requisitos geralmente so identificados a partir do desenvolvimento dos requisitos e da arquitetura do produto. Critrios e procedimentos de verificao para o ambiente de integrao do produto podem ser definidos para garantir o apoio adequado do ambiente na integrao dos itens de produto. Uma deciso importante em relao ao ambiente de integrao determinar se este ser construdo internamente, reutilizado ou adquirido de um fornecedor externo. Para isso, pode ser necessrio realizar uma anlise entre desenvolver, comprar ou reutilizar (ver o resultado esperado PCP5 do processo Projeto e Construo do Produto). Vale salientar que o ambiente de integrao pode ser um ambiente do cliente.
6.3.3 ITP3 - A compatibilidade das interfaces internas e externas dos componentes do produto assegurada Muitos problemas relacionados integrao de produtos so originados de aspectos desconhecidos ou no controlados, tanto das interfaces internas como externas. Para assegurar que as interfaces internas e externas dos componentes do produto so compatveis e que sua descrio completa, as interfaces devem ser revisadas.
Alm das interfaces entre componentes do produto, podem ser consideradas, tambm, todas as interfaces com o ambiente de integrao do produto e com outros ambientes, como o de validao, o de verificao, o de operao e o de suporte, conforme necessrio. Checklists com as situaes mais comuns de problemas de consistncia e completeza nas interfaces podem ser utilizados para tornar a reviso mais objetiva e aumentar sua efetividade. As descries das interfaces podem ser peridicas e continuamente revisadas para garantir que no haja diferena entre as descries existentes e os produtos que esto sendo desenvolvidos.
6.3.4 ITP4 - As definies, o projeto (design) e as mudanas nas interfaces internas e externas so gerenciados para o produto e para os componentes do produto As definies, projetos e mudanas nas interfaces internas e externas devem ser gerenciadas, ou seja, a consistncia das interfaces deve ser mantida ao longo de todo o ciclo de vida do produto. Alm disso, resoluo de conflitos, no conformidades e questes relativas a mudanas devem ser tratadas. Uma interface declara o conjunto de servios que so fornecidos ou exigidos pelo componente. Podem ser consideradas interfaces internas a um produto de software todas as interfaces que representam comunicao apenas entre componentes do produto em questo, tais como interfaces entre funes, objetos e mdulos de um produto. J as interfaces externas a um produto so aquelas que representam a comunicao de componentes internos ao produto com itens de outros sistemas externos ao produto, como interfaces com usurios, com itens de hardware, com o ambiente em que est inserido, entre outros. Sempre que houver mudanas nas interfaces, estas devem ser documentadas, mantidas e disponibilizadas para todos os interessados, conforme pertinente. Em geral, esse gerenciamento de interfaces comea muito cedo no desenvolvimento de
um produto. As definies e projetos para interfaces podem afetar no apenas os componentes e sistemas externos, mas tambm os ambientes de verificao e de validao [SEI, 2010].
6.3.5 ITP5 - Cada componente do produto verificado, utilizando-se critrios definidos, para confirmar que estes esto prontos para a integrao Deve ser realizada a verificao dos componentes do produto para garantir que estes esto prontos para a integrao a ser realizada de acordo com a estratgia de integrao. Essa verificao deve ser baseada em critrios definidos. Exemplos de critrios incluem: defeitos bvios; conformidade com as descries; consistncia entre os componentes de produto e interfaces; entre outros. Este resultado tem uma forte relao com o processo Verificao (VER), visto que exige a realizao de verificaes nos componentes de produto, baseando-se em critrios estabelecidos. Para isso, normalmente so utilizados testes de unidades e revises por pares. Maiores informaes sobre essas tcnicas podem ser obtidas no processo Verificao (VER), resultados esperados VER3, VER4 e VER5. Um exemplo poderia ser a realizao de testes de unidades nos componentes do produto a serem integrados, de forma a garantir sua adequao. Pode-se ainda realizar revises por pares avaliando o relatrio de testes de unidades, de forma a garantir que a integrao dos componentes vivel. A avaliao do relatrio de testes de unidades permite responder questes como:

Os resultados obtidos esto de acordo com o comportamento esperado? Todos os casos de testes planejados foram executados? As unidades esto prontas para a Integrao do software e testes de Integrao do software?
27/69
6.3.6 ITP6 - Os componentes do produto so integrados, de acordo com a estratgia determinada e seguindo os procedimentos e critrios para integrao O objetivo deste resultado esperado garantir que os componentes do produto sejam integrados de acordo com a sequncia de integrao (ver o resultado esperado ITP1) e seguindo os procedimentos e critrios previamente definidos na estratgia de integrao.
6.3.7 ITP7 - Os componentes do produto integrados so avaliados e os resultados da integrao so registrados O objetivo deste resultado esperado garantir que seja realizada a avaliao dos componentes do produto integrados e que os resultados encontrados na avaliao sejam documentados. Uma forma de executar a avaliao pela realizao de testes de integrao e da anlise de seus resultados.
O teste de integrao representa um conjunto de atividades com inteno de descobrir defeitos na estrutura do software definida durante a fase de projeto. Neste contexto, os defeitos so comumente associados com as interfaces dos mdulos (componentes) que compem a arquitetura do software [BRIAND et al., 200]. Quando as unidades so combinadas, os caminhos possveis a serem percorridos pelo programa crescem bastante e podem ocorrer falhas impossveis de serem identificadas quando as unidades so testadas separadamente [VIEIRA e TRAVASSOS, 1998]. Por meio do teste de integrao ser testado se as unidades conseguem trabalhar juntas de forma correta e se comunicam sem problemas. O teste de integrao pode ter sua execuo iniciada assim que alguns componentes ficarem prontos. No contexto do ciclo de desenvolvimento, componente pronto significa componente implementado e com os testes de unidade aprovados, ou seja, componentes individuais funcionando corretamente e atingindo os seus objetivos [PFLEEGER, 2004; LIMA, 2005]. Assim, uma forma de alcance deste resultado por meio da elaborao de um plano de testes de integrao, que detalhe como os testes sero realizados, e um relatrio de testes de integrao, que contenha informaes sobre os resultados obtidos aps realizao dos testes. A avaliao do relatrio de testes de integrao permite responder questes como:

Os resultados obtidos esto de acordo com o comportamento esperado? Todos os casos de testes planejados foram executados? O cdigo integrado est pronto para o teste do software?
29/69
6.3.8 ITP8 - Uma estratgia de teste de regresso desenvolvida e aplicada para uma nova verificao do produto, caso ocorra uma mudana nos componentes do produto (incluindo requisitos, projeto (design) e cdigos associados) Este resultado esperado tem como objetivo garantir a existncia de uma estratgia para testes de regresso a ser aplicada no caso de ocorrerem mudanas nos componentes do produto incluindo requisitos, projeto (design) e cdigo associados. Teste de regresso realizado depois de uma melhoria funcional, reparo ou qualquer mudana no produto. Seu propsito determinar se a mudana introduziu erros em outras partes do produto. normalmente feito por meio de novas execues de alguns dos casos de testes do produto. O teste de regresso importante, pois mudanas e correes de erros tendem a ser mais suscetveis a erros que a primeira codificao. Um planejamento para o teste de regresso quem, como, quando tambm necessrio [MYERS, 2004]. Vale salientar que por mudana no produto no se entende apenas manutenes corretivas ou evolutivas em um produto pronto. Por exemplo, em um desenvolvimento iterativo, a incluso de novos mdulos pode implicar em repetir testes realizados em mdulos anteriores, o que pode ser considerado teste de regresso. As tcnicas para realizar testes de regresso so normalmente mais especializadas [ROTHERMEL e HARROLD, 1996; ROSENBLUM e WEYUKER, 1997], incluindo [TIAN, 2005]:
Uma anlise das diferenas entre a verso anterior do produto e a verso atual baseada em algum modelo formal ou informal para selecionar os casos de teste existentes e determinar se novos casos de testes precisam ser desenvolvidos; e Os novos casos de testes tm o foco em duas reas: (i) a nova parte desenvolvida ou atualizada, que similar ao teste de novos produtos, mas em escala menor; e (ii) as interaes envolvendo tanto as partes novas e antigas, o que similar a teste de integrao, mas com um foco em tipos especficos de interfaces e de interaes.
A matriz de rastreabilidade pode ser utilizada para determinar quais outros componentes esto relacionados quele sendo analisado. Assim, pode auxiliar na identificao de quais casos de testes precisam ser executados novamente. Logo, manter a rastreabilidade desde os requisitos at os casos de testes importante para auxiliar na garantia de que tudo que precise ser testado novamente, realmente o seja.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor.
30/69
Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)
6.3.9 ITP9 - O produto e a documentao relacionada so preparados e entregues ao cliente O produto e a documentao a serem entregues ao cliente devem ser organizados, em uma mdia adequada e entregues ao cliente. O alcance deste resultado esperado inclui, portanto, o empacotamento e distribuio de software com mtodos que podem incluir fita magntica, disquetes, documentos impressos, CDs, DVDs, Internet [SEI, 2010]. O alcance adequado deste resultado esperado inclui a entrega do produto e sua documentao ao cliente, bem como a confirmao do recebimento pelo cliente. Dependendo das restries do projeto podem ser considerados requisitos para empacotamento e distribuio do produto, tais como tipo de armazenamento e mdia de distribuio, documentao requerida, copyrights e licenas [SEI, 2010]. O ambiente operacional pode precisar ser preparado para a instalao do produto. Essa preparao pode ser de responsabilidade do cliente.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Este resultado obrigatrio qualquer que seja o tipo de aquisio. responsabilidade do fornecedor executar esta atividade com relao organizao adquirente. Entretanto responsabilidade do adquirente execut-la com relao ao cliente. Sem comentrio adicional para este resultado.
31/69
Projeto e Construo do Produto (PCP)
7.1 Propsito O propsito do processo Projeto e Construo do Produto projetar, desenvolver e implementar solues para atender aos requisitos. Uma vez que os requisitos foram desenvolvidos, tm suas mudanas controladas e esto sob o nvel apropriado de gerncia de configurao, o objetivo do processo de Projeto e Construo do Produto (PCP) projetar uma soluo, dentre as inmeras possveis solues existentes, para satisfazer aos requisitos, desenvolver e, ento, implementar a soluo projetada. O raciocnio que explica o porqu da escolha desta soluo deve ser mantido. A implementao da soluo, no caso de software, corresponde codificao das unidades de software. A documentao que descreve o projeto (design) e a implementao da soluo deve ser desenvolvida. A rastreabilidade do projeto (design) deve ser mantida em relao aos requisitos, para que possa ser verificado se os requisitos realmente foram satisfeitos. Estes requisitos, desenvolvidos durante o processo Desenvolvimento de Requisitos (DRE), esto sob o nvel apropriado de gerncia de configurao e possuem suas alteraes controladas de acordo com o processo Gerncia de Requisitos (GRE). A matriz de rastreabilidade deve prover a ligao entre os requisitos e os componentes projetados durante a execuo do processo Projeto e Construo do Produto (PCP) de modo que seja possvel determinar que componentes estejam satisfazendo determinados requisitos, apoiando a anlise de impacto no caso de ser necessrio realizar alguma mudana. Esse processo interage com os processos Desenvolvimento de Requisitos (DRE), Integrao do Produto (ITP), Verificao (VER) e Validao (VAL). O processo Projeto e Construo do Produto (PCP) recebe como entrada os requisitos desenvolvidos para projetar e construir a soluo. O processo Integrao do Produto (ITP) recebe como insumo os requisitos desenvolvidos durante a execuo do processo Desenvolvimento de Requisitos (DRE) e os componentes do produto projetados e construdos durante a execuo do processo Projeto e Construo do Produto (PCP), a fim de combin-los e verificar se as interfaces satisfazem os requisitos de interface desenvolvidos durante a execuo do processo Desenvolvimento de Requisitos (DRE). Alm disso, os componentes projetados e construdos so verificados durante o processo Verificao (VER) em relao aos requisitos e o produto final validado de forma incremental durante o processo Validao (VAL).
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes adquirentes de software nenhum resultado esperado obrigatrio. O processo ou alguns de seus resultados podem ser excludos, de acordo com o tipo de aquisio do projeto. A aprovao das excluses responsabilidade do avaliador lder.
Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. De qualquer forma, mesmo quando no executa o processo, responsabilidade da organizao adquirente definir no acordo com o fornecedor as restries de projeto, verificar a soluo de projeto adotada pelo fornecedor e monitorar a execuo do processo pelo fornecedor [HOFMANN et al., 2007] Fbrica de Software (Parte 9) Para organizaes do tipo Fbrica de Software, apenas o resultado PCP6 obrigatrio. Os demais resultados podem ser excludos. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. importante observar que os resultados PCP7 e PCP8 podem ser necessrios, caso a documentao tambm faa parte do escopo do projeto desenvolvido pela Fbrica de Software. Neste caso, estes resultados devem estar presentes e no podem ser excludos. Em organizaes do tipo Fbrica de Software, as especificaes so provenientes da organizao contratante e, portanto, a maioria dos resultados esperados para este processo no se aplica, com exceo do PCP6 (codificao), que o foco da organizao. Fbrica de Teste (Parte 10) So permitidas excluses de todos os resultados de processo em organizaes do tipo Fbrica de Teste. Normalmente, este processo excludo por estas atividades serem tipicamente executadas pelas organizaes desenvolvedoras e/ou mantenedoras do produto de software. A aprovao das excluses responsabilidade do avaliador lder, dependendo do tipo de teste que ser efetuado. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.
7.2 Fundamentao terica A execuo do processo Projeto e Construo do Produto (PCP) iniciada quando os requisitos para o problema a ser resolvido pelo software estiverem definidos, desenvolvidos e aprovados. Este processo pode ser executado tanto no contexto do software a ser desenvolvido quanto no contexto do sistema onde o software integrado. O objetivo do processo Projeto e Construo do Produto (PCP) definir atividades que permitam a elaborao do projeto (design) do software e, tambm,
possibilitem a implementao da soluo de projeto (design) para os requisitos em questo. Projeto (design) o processo criativo de transformar o problema em uma soluo, sendo que a descrio da soluo tambm chamada de projeto (design) [PFLEEGER, 2004]. Em [PRESSMAN, 2005] define-se projeto (design) como a representao significativa de alguma coisa a ser construda. O projeto (design) enfatiza uma soluo conceitual que satisfaa os requisitos e no a sua implementao. Uma descrio de um esquema de banco de dados e objetos de software ou da arquitetura do sistema um bom exemplo [LARMAN, 2004]. O processo Projeto e Construo do Produto (PCP) engloba tanto a elaborao do projeto (design) quanto a implementao do projeto (design) definido. Os clientes sabem o que o sistema deve fazer e os construtores precisam saber como o sistema funcionar. Por isso, o projeto (design) um processo iterativo constitudo de duas partes: o projeto (design) conceitual ou projeto (design) do sistema, mostra ao cliente exatamente o que o sistema far; e o projeto (design) tcnico, que uma traduo detalhada do projeto (design) conceitual, permite que os construtores do sistema saibam quais so o hardware e software necessrios para solucionar o problema do cliente [PFLEEGER, 2004]. De acordo com [SHAW e GARLAN, 1996] a definio da arquitetura do software o primeiro passo a ser tomado durante o projeto (design) de software, sendo possvel identificar trs nveis de projeto (design):
Projeto da Arquitetura: Este nvel de projeto (design) associa as capacidades do sistema identificadas na especificao de requisitos com os componentes do sistema que as implementaro, bem como mostra a interconexo entre estes componentes. Os componentes da arquitetura so, geralmente, os mdulos do sistema; Projeto do Cdigo: Este nvel de projeto (design) envolve algoritmos e estruturas de dados. Os componentes so primitivas de linguagens de programao como, por exemplo, nmeros, caracteres, ponteiros e estruturas de controle; Projeto Executvel: Este nvel de projeto (design) detalha ainda mais o cdigo, discutindo detalhes, por exemplo, de alocao de memria, de formato dos dados e de padres de bits.
Durante o projeto (design) da arquitetura tambm definido o estilo arquitetural a ser utilizado na construo do sistema. O estilo arquitetural envolve os componentes do sistema, os conectores e as restries sobre a combinao dos componentes. Como exemplos de estilos arquiteturais pode-se citar: pipe and filter; objetos; chamada implcita; formao de camadas; repositrios; interpretadores; e controle de processos [SHAW e GARLAN, 1996; PFLEEGER, 2004]. O processo Projeto e Construo do Produto (PCP) intenso em conhecimento e durante a sua execuo necessrio tomar diversas decises, pois podem existir diversas maneiras de solucionar um mesmo problema. importante armazenar o conhecimento organizacional adquirido durante a execuo do processo mantendo o registro do raciocnio pelo qual uma determinada deciso foi tomada durante a etapa de projeto (design). Isso fica claro quando se tem um problema de rotatividade de
pessoal na organizao. A alta rotatividade da equipe na indstria de software, associada com longos perodos de vida dos produtos, aumenta a probabilidade de que os projetistas originais no estejam presentes quando evolues nos produtos forem necessrias e os problemas comearem a ocorrer [BURGE, 2005]. Alm disso, muito frequentemente, o entendimento necessrio para realizar manutenes depende da compreenso de quais decises de projeto (design) foram consideradas, que suposies foram feitas, que solues alternativas foram rejeitadas e que critrios e requisitos foram satisfeitos no processo de deliberao [CONKLIN, 1989]. Este tipo de conhecimento raramente registrado e est acessvel para consulta durante o perodo de manuteno do produto. Outro problema comum nas organizaes a dificuldade de aproveitar o conhecimento de membros mais experientes durante o treinamento de novos membros das equipes, pois a dinmica de trabalho no permite que os experientes parem a execuo de suas atividades para compartilhar o seu conhecimento. Assim, em situaes de tomada de deciso, os membros iniciantes tendem a repetir os mesmos erros cometidos por outros membros das equipes que j passaram por situaes semelhantes. Estes so alguns dos motivos que ressaltam a importncia em se manter o raciocnio por trs das decises tomadas durante a execuo do processo Projeto e Construo do Produto. Em relao avaliao do projeto (design), necessrio estabelecer guias que orientem a avaliao. Em [PRESSMAN, 2005; PFLEEGER, 2004] esto relacionadas as caractersticas desejadas para um bom projeto (design):

Possuir alternativas de soluo e selecionar a alternativa mais adequada com base nos requisitos, recursos disponveis e nos conceitos de projeto (design); Ser rastrevel em relao ao modelo de anlise; No reinventar a roda, ou seja, observar padres que possam ser reutilizados; Possuir a mesma estrutura que o domnio do problema a ser resolvido pelo projeto (design); Exibir uniformidade e integrao; Permitir mudanas; Acomodar eventos no esperados de maneira adequada; Estar em um nvel de abstrao maior do que o cdigo; Ser avaliado em relao qualidade enquanto criado e no apenas depois de ter sido totalmente definido; Ser revisado para identificar erros de semntica.
35/69
7.3 Resultados esperados 7.3.1 PCP1 - Alternativas de soluo e critrios de seleo so desenvolvidos para atender aos requisitos definidos de produto e componentes de produto Para um determinado problema podem existir diversas formas diferentes de solucion-lo. Por exemplo, caso seja necessrio utilizar um algoritmo de ordenao, pode-se ter inmeras diferentes solues: quicksort, bublesort, mergesort, ordenao por seleo direta etc. Durante o projeto (design), deve-se analisar estas solues alternativas e selecionar a soluo mais adequada como base em critrios pr-estabelecidos. Como exemplos de critrios podem-se citar as caractersticas e subcaractersticas de qualidade presentes na norma ISO/IEC 9126-1 [ISO/IEC, 2001]. Outras escolhas tpicas tomadas so a escolha da arquitetura a ser utilizada, desenvolvimento personalizado versus de prateleira, modularizao dos componentes, escolhas referentes s interfaces entre os componentes, escolha da linguagem de programao, escolha do banco de dados e escolha da ferramenta de modelagem a ser utilizada pela organizao. Um processo de seleo de alternativas possui, basicamente, as seguintes atividades: definio dos objetivos de seleo; estabelecimento dos critrios de seleo; desenvolvimento das solues a serem avaliadas; avaliaes das solues com base nos critrios pr-estabelecidos e seleo da soluo mais adequada. importante destacar que o desenvolvimento das solues alternativas deve satisfazer os requisitos desenvolvidos.
7.3.2 PCP2 - Solues so selecionadas para o produto ou componentes do produto, com base em cenrios definidos e em critrios identificados Tendo identificado os critrios de seleo a serem utilizados, necessrio avaliar as solues alternativas com base nestes critrios e selecionar a soluo mais adequada. A partir da seleo de uma alternativa, novas decises podem precisar
ser tomadas e por isso a abordagem de seleo de alternativas necessita ser novamente executada. A evoluo dos cenrios criados durante o desenvolvimento dos requisitos pode ajudar na seleo da alternativa de soluo mais adequada. Em [BASS et al., 2003] possvel encontrar a descrio de templates que podem ser utilizados para a definio de cenrios. Estes cenrios so definidos com base nos requisitos desenvolvidos. Estes cenrios so desenvolvidos durante o processo Desenvolvimento de Requisitos (DRE) e evoludos durante o processo Projeto e Construo do Produto (PCP). Supondo que uma organizao queira determinar, por exemplo, se, em um determinado projeto, as chaves primrias das tabelas sero geradas automaticamente pelo banco de dados selecionado ou se sero geradas pelo software a ser desenvolvido. Tal organizao poderia selecionar dois critrios: desempenho e portabilidade. Por um lado, se o banco de dados gerar as chaves primrias automaticamente, o desempenho ser maior, mas por outro lado, a portabilidade ser menor pois pode ser que outro banco de dados no consiga entender aquele formato. O oposto ocorre caso o software gere as chaves primrias, a portabilidade aumenta, pois a chave pode ser gerada em um formato que qualquer banco de dados consiga armazenar, mas o desempenho diminui. A criao de cenrios apoia a avaliao dessas alternativas em relao aos critrios. Um determinado cenrio poderia avaliar o desempenho de cada opo ao criar, apagar e recuperar n registros no banco de dados, enquanto que outro determinado cenrio poderia avaliar a utilizao de cada soluo com bancos de dados diferentes para avaliar a portabilidade.
7.3.3 PCP3 - O produto e/ou componente do produto projetado e documentado Deve-se projetar o produto ou os componentes do produto de acordo com os requisitos especificados. Este projeto (design) geralmente constitudo de duas atividades: o projeto (design) da arquitetura do sistema e o projeto (design) do
software. O projeto (design) da arquitetura do sistema visa identificar que requisitos do sistema devem ser alocados a que elementos do sistema [ISO/IEC, 2008]. A arquitetura deve identificar itens de hardware, software e operaes manuais [ISO/IEC, 2008]. O projeto (design) do software especifica, para cada componente definido na arquitetura, um projeto (design) que atenda os requisitos definidos. Este projeto (design) refinado em nveis cada vez menores at chegar ao nvel de unidades de software que possam ser codificadas e testadas. O produto das atividades de projeto (design) a documentao necessria para a implementao do produto ou dos componentes do produto, assim como para a execuo de outras atividades do ciclo de vida do produto como a manuteno ou instalao.
7.3.4 PCP4 - As interfaces entre os componentes do produto so projetadas com base em critrios predefinidos Um recurso fundamental dos componentes a capacidade de definir interfaces. O componente precisa expor alguns dos meios para os outros componentes se comunicarem com ele [PENDER, 2004]. Uma interface declara o conjunto de servios que so fornecidos ou exigidos pelo componente. O projeto (design) deve conter a descrio das interfaces, assim como os critrios utilizados para a seleo destas interfaces. Estas descries das interfaces englobam as interfaces entre: componentes e componentes; componentes de mais baixo nvel e componentes de mais alto nvel; componentes e produtos do processo de ciclo de vida; e componentes e itens externos. A escolha da interface deve levar em considerao os requisitos definidos durante o processo Desenvolvimento de Requisitos (DRE). O processo Integrao do Produto (ITP) utilizar as interfaces projetadas de acordo com os requisitos desenvolvidos para integrar os componentes de forma consistente.
38/69
7.3.5 PCP5 - Uma anlise dos componentes do produto conduzida para decidir sobre sua construo, compra ou reutilizao Devido a fatores como a globalizao, a forte competitividade e o crescimento da complexidade dos produtos de software, as organizaes buscam melhores formas de se organizarem. As organizaes tentam focar em suas atividades principais, a fim de melhorar a gerncia dos custos. Isto levanta questes como [BOUCHRIHA, et. al., 2002]: Que recursos deveriam ser desenvolvidos para aumentar as competncias da organizao? Que atividades deveriam ser feitas por outras organizaes e que parceiros em potencial deveriam ser contratados para executar estas atividades? Que atividades internas deveriam ser preservadas e desenvolvidas pela prpria organizao? Como os recursos da organizao deveriam ser alocados em relao s atividades? vital para as organizaes que os custos de desenvolvimento dos produtos sejam reduzidos, assim como seu prazo de lanamento no mercado (time to market). Um meio de conseguir estes dois objetivos delegar a outras organizaes a confeco de componentes do produto, desde que estes componentes no faam parte da competncia central da organizao. necessrio, portanto, a existncia de uma abordagem que permita a uma organizao decidir o que lhe mais vantajoso: desenvolver um determinado componente internamente; contratar uma outra organizao para fazer este desenvolvimento; ou reutilizar um componente j disponvel na organizao. As organizaes devem ser capazes de escolher as partes do produto que sero produzidas internamente e as partes dos produtos que sero produzidas por organizaes contratadas. As abordagens existentes na literatura para responder a estas questes possuem duas correntes principais de pensamento: a primeira busca responder a pergunta sob um ponto de vista econmico e a segunda foca no ponto de vista estratgico [CNEZ et al., 2001].
39/69
7.3.6 PCP6 - Os componentes do produto so implementados e verificados de acordo com o que foi projetado Os componentes do produto devem ser implementados de acordo com o que foi especificado no projeto (design) e a documentao relacionada a estes componentes deve ser desenvolvida. A implementao do projeto (design) feita por meio da utilizao de um mtodo como, por exemplo: programao orientada a objetos; programao estruturada; programao orientada a aspectos; programao imperativa; programao orientada a eventos; reutilizao de cdigo; e gerao automtica de cdigo. Tambm necessrio revisar cada componente do produto. Esta reviso pode ser feita, por exemplo, por meio de reviso por pares e/ou testes de unidades. Assim, uma vez que as unidades sejam implementadas necessrio verific-las em relao aos requisitos e ao projeto (design). Esta verificao feita de acordo com critrios definidos - ver processo Verificao (VER).
40/69
7.3.7 PCP7 - A documentao identificada, desenvolvida e disponibilizada de acordo com os padres estabelecidos Deve-se desenvolver a documentao associada ao projeto (design) e para o usurio final, de acordo com padres. Tambm necessrio identificar que documentos sero produzidos, quando sero produzidos, por quem sero produzidos e quem so os interessados nestes documentos. A satisfao deste resultado implica na produo de um pacote de dados tcnico que descreva o produto, de uma forma que permita s diferentes pessoas que trabalharo realizarem suas tarefas de desenvolvimento ou de manuteno. Este pacote de dados tcnico contm a documentao produzida durante o projeto que tem incio com a avaliao das alternativas de soluo. O pacote de dados tcnico pode conter, por exemplo, o projeto (design) da arquitetura do sistema, o raciocnio por trs das decises tomadas, o projeto (design) dos componentes, o projeto (design) das interfaces e a rastreabilidade entre os requisitos e os componentes do projeto e interfaces.
7.3.8 PCP8 - A documentao mantida de acordo com os critrios definidos A documentao necessria para a manuteno, operao e instalao do produto deve ser mantida e revisada, de acordo com critrios previamente definidos, para garantir a consistncia em relao aos requisitos e ao projeto (design). Padres podem facilitar o entendimento e a leitura da documentao. Alguns exemplos de possveis padres so:

Fontes a serem utilizadas, dependendo do contexto (rodap, ttulo, contedo etc.); Uso de abreviaes; Tamanho das fontes; Compatibilidade com processadores de texto;
41/69
Imagens geralmente utilizadas pela organizao na documentao.
Os critrios incluem, por exemplo, como a documentao ser mantida no sentido de controlar as suas modificaes durante o projeto, mantendo-a consistente com os demais artefatos gerados durante o projeto, ou ento se a documentao ser desenvolvida aos poucos, durante as atividades do projeto, ou se ser desenvolvida toda de uma vez s, no final do projeto. Estes critrios tambm podem indicar como a documentao estar organizada e que itens/requisitos do sistema dever descrever.
Validao (VAL)
8.1 Propsito O propsito do processo Validao confirmar que um produto ou componente do produto atender a seu uso pretendido quando colocado no ambiente para o qual foi desenvolvido. O processo Validao diz respeito, portanto, a como avaliar a qualidade de um produto ou componente de produto, garantindo que atenda s necessidades de seus usurios, quando colocado em seu ambiente de uso. O objetivo da validao garantir que o produto correto est sendo desenvolvido. Os resultados esperados deste processo esto relacionados a resultados esperados dos processos Desenvolvimento de Requisitos (DRE) e Integrao do Produto (ITP). A interseo deste processo com o processo Desenvolvimento de Requisitos (DRE) est presente no resultado esperado referente validao dos requisitos desenvolvidos, desde as fases iniciais do ciclo de vida, para assegurar que o desempenho do produto, quando instalado no seu ambiente de uso, ser adequado. A interseo com o processo Integrao do Produto (ITP) est presente na avaliao dos componentes do produto integrados onde pode ser feita uma
42/69
validao desses componentes e tambm no momento da entrega do produto ao cliente, garantindo que este se comporta adequadamente em seu ambiente alvo.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes adquirentes de software os nicos resultados esperados obrigatrios so VAL1, VAL6 e VAL7. Os demais resultados podem ser excludos, de acordo com o tipo de aquisio do projeto. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. De qualquer forma, mesmo quando no executa uma atividade do processo, responsabilidade da organizao adquirente monitorar a execuo do processo pelo fornecedor. Fbrica de Software (Parte 9) So permitidas excluses dos resultados esperados do processo, dependendo do escopo de atuao da Fbrica de Software. Caso a Fbrica de Software tenha, em seu escopo de trabalho, a realizao de atividades de teste de homologao/aceitao, este processo dever estar presente, caso contrrio, poder ser excludo do escopo da avaliao. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de processos devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. Como no existem especificidades para organizaes do tipo Fbrica de Software, no foram includos comentrios nos resultados esperados. Fbrica de Teste (Parte 10) Todos os resultados do processo de Validao podem ser excludos. Os resultados do processo de Validao no podero ser excludos, caso a Fbrica de Teste tenha no seu escopo de trabalho, a realizao da validao como, por exemplo, a conduo de testes de aceitao e homologao. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. Como no existem especificidades para organizaes do tipo Fbrica de Teste, no foram includos comentrios adicionais aos resultados esperados.
43/69
8.2 Fundamentao terica A qualidade de software destaca-se como um diferencial de mercado visto que sua importncia est no fato de produzir sistemas cada vez melhores e, assim, assegurar a satisfao do cliente. Nesse contexto, a validao considerada um elemento importante para a garantia da qualidade e, portanto, deve ser planejada e executada, com eficcia, durante o desenvolvimento do software. A validao de software visa avaliar a qualidade de produtos ou componentes de produto. Como apresentado na seo .1, um componente de produto uma parte 5 do produto final ou algo usado no seu desenvolvimento que faz parte da entrega; e, produto qualquer artefato associado execuo de um processo que se pretende entregar ao cliente ou usurio final [[SOFTEX, 2011a]]. Validao a confirmao, por exame e fornecimento de evidncia objetiva, de que os requisitos especficos, para um determinado uso pretendido, so atendidos [ISO/IEC, 2008]. O objetivo da validao assegurar que o software que est sendo desenvolvido o software correto de acordo com os requisitos do usurio [ROCHA et al., 2001]. Frequentemente, a validao de software est fortemente associada verificao de software sendo que, normalmente, elas so executadas em conjunto, pois muitas vezes difcil determinar onde uma comea e onde a outra termina. De uma maneira geral, pode-se dizer que a verificao se preocupa em avaliar se o produto est sendo desenvolvido corretamente, enquanto a validao visa assegurar que se est desenvolvendo o produto correto, isto , o produto que o cliente deseja [BOEHM, 1981]. A norma internacional ISO/IEC 12207 [ISO/IEC, 2008] define que, nas atividades de desenvolvimento, a verificao refere-se ao processo de examinar o resultado de uma atividade para determinar sua conformidade com os requisitos estabelecidos para a mesma atividade, enquanto a validao se refere ao processo de examinar um produto para determinar sua conformidade com as necessidades do usurio. Esta norma define que a validao feita normalmente no produto final sob condies de operao definidas, podendo, contudo, tornar-se necessria em fases anteriores. Por exemplo, em projetos cujos requisitos no so bem conhecidos, pode-se tornar necessria uma validao dos requisitos identificados inicialmente usando um prottipo. A validao dos requisitos visa garantir que o produto a ser desenvolvido se comportar adequadamente no seu ambiente de uso. Esta norma tambm apresenta um processo de validao que pode ser usado como referncia auxiliar na implementao deste processo e na interpretao de seus resultados esperados. Atividades de validao normalmente so executadas nas etapas iniciais e finais do desenvolvimento de um produto, comeando geralmente com a validao dos requisitos e, posteriormente, terminando com a validao do produto final no ambiente operacional [TIAN, 2005]. Uma vez que a validao se preocupa com o atendimento das necessidades dos clientes e usurios do produto, recomendvel que, sempre que possvel, os usurios finais sejam envolvidos nas atividades de validao.
Uma forma de realizar a validao por meio de uma srie de testes que demonstrem que o produto correto est sendo desenvolvido. O teste um dos mais importantes mtodos de garantia da qualidade do produto e, frequentemente, o mais usado [TIAN, 2005]. Consiste em sua anlise dinmica, ou seja, na sua execuo com o objetivo de verificar a presena de defeitos e aumentar a confiana de que o produto esteja correto [ROCHA et al., 2001]. Quando o software desenvolvido para um cliente especfico, uma srie de testes de aceitao pode ser conduzida para permitir ao cliente validar o produto. Este tipo de teste pode ser conduzido pelo cliente ou pelos desenvolvedores, mas o principal participante o cliente. Os testes de aceitao podem ser conduzidos por um perodo de tempo de dias a meses, descobrindo erros que poderiam degradar o sistema ao longo do tempo. Por outro lado, quando o software desenvolvido como um produto para ser usado por diversos clientes, impraticvel realizar testes de aceitao formais com cada um deles. A maioria dos fabricantes de software utiliza um processo chamado de testes alfa e beta para detectar erros que apenas os usurios finais parecem ser capazes de encontrar. Nas duas abordagens, os testes so realizados pelo cliente, sendo que, no primeiro, o teste realizado em um ambiente controlado, com o acompanhamento do desenvolvedor, enquanto no segundo, o teste realizado em ambiente real de uso pelo cliente, que reporta os erros ao desenvolvedor [PRESSMAN, 2005]. Vale salientar que testes no contexto de verificao e de validao so complementares. Em hiptese alguma, estes devero ser encarados como atividades redundantes. Tanto um quanto o outro possui natureza e objetivos distintos, fortalecendo o processo de deteco de erros e aumentando a qualidade final do produto [BARTI, 2002]. No entanto, a validao de software no somente teste. Requisitos devem ser especificados e o uso pretendido para estes requisitos deve ser avaliado por meio da validao. Portanto, alm dos testes, diversas outras tcnicas podem ser utilizadas na validao, dentre elas: prototipao, simulaes, model checking, utilizao de cenrios de caso de uso [PFLEEGER, 2004; PRESSMAN, 2005; SUKUMARAN et al., 2006; SEYBOLD et al., 2005; SOM, 2005]. Dentre estas tcnicas, a prototipao merece destaque. Um prottipo um produto parcialmente desenvolvido, que possibilita aos clientes e desenvolvedores examinarem certos aspectos do sistema proposto e decidir se eles so ou no apropriados ou adequados para o produto acabado [PFLEEGER, 2004]. A prototipao uma tcnica de validao de requisitos bastante til, pois normalmente uma forma de validar a interpretao que os engenheiros de software tm dos requisitos e tambm de elicitar novos requisitos. A vantagem do prottipo que ele pode tornar mais fcil interpretar as suposies feitas e, quando necessrio, dar um retorno muito til sobre as interpretaes erradas [IEEE, 2004]. importante ressaltar que a realizao da validao em um projeto de software envolve um bom planejamento que determine quais produtos sero validados, quais mtodos e tcnicas sero utilizados, alm de incluir tambm a definio dos ambientes necessrios para validao, ferramentas e demais recursos que sero utilizados na validao.
Uma das possveis formas de se executar o processo de validao ao longo do desenvolvimento do produto comear com o planejamento da validao integrado ao planejamento do projeto no incio do desenvolvimento, seguindo com a execuo da validao ao longo do projeto, conforme planejado, iniciando pela validao dos requisitos e terminando com os testes do produto em seu ambiente de uso. de se esperar que a validao bem sucedida tenha como benefcios, dentre outros: (i) maior satisfao do cliente, devido ao melhor atendimento s suas necessidades; (ii) reduo de retrabalho, devido, principalmente, validao dos requisitos; (iii) reduo de custos, decorrente da reduo de retrabalho; e (iv) maior competitividade, originada na maior satisfao do cliente. 8.3 Resultados esperados 8.3.1 VAL1 - Produtos de trabalho a serem validados so identificados Este resultado esperado visa garantir que sejam identificados os produtos ou componentes de produto que sero validados ao longo do projeto. Esta identificao pode ocorrer nos estgios iniciais do projeto, com base nos artefatos que sero produzidos pelo processo. Uma boa prtica definir critrios para seleo dos produtos ou componentes de produto que sero validados e selecion-los segundo estes critrios. Pode-se, por exemplo, selecionar os produtos mais relevantes com base nas necessidades do cliente ou levando-se em considerao os riscos associados aos produtos, pois, uma vez que produtos com grande risco associado precisam ser mais confiveis, podem precisar ser mais fortemente validados. possvel, tambm, definir, em nvel organizacional, uma lista de produtos ou componentes de produto que normalmente so validados, de forma que os projetos s precisem adaptar essa lista s suas necessidades. Diretrizes tambm podem ser utilizadas para guiar a seleo.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Sem comentrio adicional para este resultado. responsabilidade da organizao adquirente definir os produtos a serem validados.
46/69
8.3.2 VAL2 - Uma estratgia de validao desenvolvida e implementada, estabelecendo cronograma, participantes envolvidos, mtodos para validao e qualquer material a ser utilizado na validao Este resultado esperado tem como objetivo garantir que as atividades de validao sejam planejadas com a definio de procedimentos, infra-estrutura necessria, cronograma, recursos e responsabilidades. Os mtodos a serem usados nas atividades de validao tambm devem ser identificados. Alguns mtodos de validao requerem um planejamento especfico que deve ser realizado, por exemplo, o planejamento dos casos de testes. Deve ser definido ainda um cronograma para as atividades de validao e os recursos necessrios execuo das atividades devem ser planejados. Este cronograma e a alocao dos recursos, tanto humanos quanto outros recursos em geral, devem estar integrados ao Plano do Projeto. Prototipao um dos mtodos para a validao de requisitos. Para isto pode ser construdo um prottipo descartvel ou um prottipo evolutivo. Prottipos tm como objetivo aprender mais sobre o problema ou explorar a viabilidade de possveis solues. Prottipos descartveis no so utilizados posteriormente. Prottipos evolutivos podem ser utilizados como a base de uma parte ou de todo o software a ser fornecido [PFLEEGER, 2004]. A validao realizada, principalmente, por meio de testes. Aps se ter o produto desenvolvido, possvel realizar uma srie de testes de desempenho para avaliar o comportamento do produto em seu ambiente de uso, tais como testes de estresse, testes de volume, testes de tempo, testes de usabilidade, dentre outros [RAKITIN, 2001]. Aps testar o sistema e garantir que ele se comporta conforme especificado, tanto para os requisitos funcionais quanto para os no-funcionais, o cliente pode avaliar o sistema para determinar se o sistema construdo o que ele deseja. Neste momento, o teste de aceitao pode ser realizado. Aps a aceitao do sistema por parte do cliente, ele pode ser avaliado quanto sua instalao no ambiente de uso. Essa avaliao feita com o teste de instalao que tem por objetivo permitir que os usurios executem as funes do sistema e documentem problemas adicionais especficos do ambiente de operao [PFLEEGER, 2004].
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)
8.3.3 VAL3 - Critrios e procedimentos para validao dos produtos de trabalho a serem validados so identificados e um ambiente para validao estabelecido O objetivo deste resultado esperado garantir que os critrios e procedimentos a serem utilizados para a validao foram identificados e que foi estabelecido um ambiente para validao, semelhante ao ambiente operacional. Devem ser definidos os critrios para a validao de cada produto ou componente do produto. Para ajudar a determinar se um critrio foi ou no atendido, algumas mtricas podem ser definidas. Alguns exemplos de critrios para validao dos requisitos so: adequao funcional e usabilidade. Para validao de um software alguns critrios de validao poderiam ser: tempo de resposta, tolerncia a falhas, recuperabilidade, uso de memria, confiabilidade e portabilidade. Algumas sugestes de critrios e mtricas que podem ser usados na validao de produtos de software podem ser encontradas nos relatrios tcnicos [ISO/IEC, 2003a; ISO/IEC, 2003b; ISO/IEC, 2004]. A preparao do ambiente de validao pode envolver identificar e disponibilizar as ferramentas, tais como ferramentas de apoio ao planejamento e execuo dos testes, os recursos de hardware, infra-estrutura de rede, entre outros recursos necessrios.
8.3.4 VAL4 - Atividades de validao so executadas para garantir que o produto esteja pronto para uso no ambiente operacional pretendido Este resultado esperado visa garantir que as atividades de validao foram realizadas nos produtos e componentes de produto conforme o planejado. Uma das principais formas de se realizar a validao executando testes. A realizao dos testes ao longo de todo o processo de desenvolvimento do software possvel por meio da execuo de quatro etapas distintas [ROCHA et al., 2001]:
Planejamento: Consiste em definir um plano de testes que determine os critrios a serem avaliados no produto a ser testado, os recursos necessrios e o cronograma para execuo dos testes; Projeto de casos de teste: Consiste em selecionar as tcnicas de testes que sero usadas, especificar os casos de teste e definir os procedimentos de teste; Execuo: Consiste em executar os casos de teste especificados seguindo os procedimentos definidos; Avaliao dos resultados: Consiste em analisar os resultados dos testes confrontando-os com os resultados esperados.
8.3.5 VAL5 - Problemas so identificados e registrados Este resultado esperado visa garantir que os problemas identificados durante a execuo das atividades de validao foram documentados e que foram definidos quais problemas sero tratados. Estes problemas devem ser acompanhados at sua concluso. Nem todos os problemas encontrados precisam ser corrigidos. A organizao pode definir critrios que facilitem essa anlise considerando os riscos para o projeto e o impacto na qualidade do produto.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9)
8.3.6 VAL6 - Resultados de atividades de validao so analisados e disponibilizados para as partes interessadas O alcance deste resultado esperado envolve realizar uma anlise dos resultados obtidos em decorrncia da execuo das atividades relacionadas a validao e disponibilizar estes resultados para o cliente, ou seu representante na execuo das atividades, e outras partes interessadas. Assim, uma forma de alcance deste resultado por meio da anlise de laudos de avaliao e relatrios de testes que contenham informaes sobre os resultados obtidos aps a realizao das atividades de validao. A avaliao destes resultados permite responder questes como:

Os critrios definidos foram satisfeitos? As aes corretivas planejadas foram concludas? A validao foi executada conforme planejado? Os resultados obtidos permitem a aprovao do artefato validado? O produto final est pronto para o uso pretendido?
Adquirentes de Software (Parte 8)
Mesmo quando as atividades de validao so delegadas ao fornecedor, responsabilidade da organizao adquirente analisar os resultados obtidos, compar-los com os critrios de aceitao estabelecidos no contrato e disponibilizar os resultados para os interessados. Sem comentrio adicional para este resultado.
8.3.7 VAL7 - Evidncias de que os produtos de software desenvolvidos esto prontos para o uso pretendido so fornecidas Quando as atividades de teste so realizadas e h evidncias que o produto satisfaz os requisitos e as expectativas do cliente, o produto pode ser considerado validado.
Para isso o produto deve ser testado em seu ambiente real de uso ou em uma reproduo deste ambiente. necessrio registrar os resultados da validao, evidenciando que o produto est pronto para o uso. Uma das formas de garantir que o produto est pronto para ser usado realizar uma reunio com os clientes e/ou usurios finais onde sejam apresentados os resultados da validao, a correo dos problemas detectados e se obtenha o aceite de que o produto est pronto para o uso.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10) Sem comentrio adicional para este resultado. Mesmo quando as atividades de validao so delegadas ao fornecedor, responsabilidade da organizao adquirente fornecer aos clientes e/ou usurios finais as evidncias de que o produto est pronto para o uso e obter o aceite. Sem comentrio adicional para este resultado.
Verificao (VER)
9.1 Propsito O propsito do processo Verificao confirmar que cada servio e/ou produto de trabalho do processo ou do projeto atende apropriadamente os requisitos especificados. O processo Verificao trata de como avaliar produtos de trabalho e servios, garantindo que atendam a seus requisitos, por meio da identificao dos itens a serem verificados, do planejamento da verificao de cada um destes itens e da execuo da verificao conforme planejado ao longo do desenvolvimento do produto. Os resultados esperados deste processo esto relacionados a resultados esperados dos processos Desenvolvimento de Requisitos (DRE), Projeto e Construo do Produto (PCP) e Integrao do Produto (ITP). A interseo deste processo com o processo Desenvolvimento de Requisitos (DRE) est presente no resultado esperado referente anlise dos requisitos desenvolvidos para garantir que estes so necessrios e suficientes, onde pode ser realizada uma verificao desses requisitos.
51/69
A interseo com o processo Projeto e Construo do Produto (PCP) est presente no resultado esperado referente implementao e verificao, de acordo com o que foi especificado no projeto (design) dos componentes do produto e a sua documentao associada. A verificao desses componentes do produto pode ser realizada por meio de reviso por pares e/ou testes. A interseo com o processo Integrao do Produto (ITP) est presente ao longo de toda a integrao, uma vez que h uma forte dependncia dos testes de integrao, que so tcnicas de verificao. Vale destacar a interseo nos resultados esperados referentes : (i) verificao dos componentes do produto para garantir que estes esto prontos para a integrao, baseando-se em critrios predefinidos; (ii) avaliao dos componentes do produto integrados onde pode ser feita uma verificao desses componentes; (iii) desenvolvimento e aplicao de uma estratgia de regresso para uma nova verificao do produto quando ocorre uma mudana nos componentes do produto; e (iv) preparao e entrega do produto ao cliente realizando a verificao final no produto antes da entrega.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Para organizaes que adquirem software nenhum resultado esperado obrigatrio. O processo ou alguns de seus resultados podem ser excludos, de acordo com o tipo de aquisio do projeto. importante, entretanto, que a organizao adquirente tenha em conta que este processo no se refere apenas a verificao de cdigo, mas, tambm, verificao de outros produtos gerados ao longo do desenvolvimento e que podem ser objeto de revises por pares. A aprovao das excluses responsabilidade do avaliador lder. Todas as excluses de resultados esperados devem estar listadas no Plano de Avaliao, no Relatrio de Avaliao e no Resultado da Avaliao. De qualquer forma, mesmo quando no executa o processo, responsabilidade da organizao adquirente monitorar a execuo do processo pelo fornecedor. Fbrica de Software (Parte 9) Como no existem especificidades para organizaes do tipo Fbrica de Software, no foram includos comentrios nos resultados esperados. No so permitas excluses de resultados deste processo. Fbrica de Teste (Parte 10) Este processo o tipicamente contratado da Fbrica de Teste, portanto nenhum resultado pode ser excludo.
52/69
9.2 Fundamentao terica O principal objetivo da engenharia de software , sem dvida, melhorar a qualidade do software. Uma vez que a qualidade de um produto de software est diretamente relacionada sua quantidade de defeitos, os defeitos de um produto de software devem ser detectados o mais cedo possvel evitando o retrabalho [PUTNAM e MYERS, 2003]. De fato, h algumas evidncias de que 40% a 50% do esforo de um projeto gasto com retrabalho que poderia ser evitado [BOEHM e BASILI, 2001]. Alm disso, o custo para detectar e corrigir defeitos cresce bastante medida que eles so propagados para fases posteriores do processo de desenvolvimento. Estudos mostram que o custo de corrigir um defeito de projeto ou de codificao na prpria fase entre 10 a 100 vezes menor do que o custo de corrigi-lo na fase de testes [ANDERSSON, 2003]. Essa uma das principais motivaes para o uso da verificao de software, que procura detectar os defeitos o quanto antes. Alm de possibilitar a deteco de defeitos mais cedo, uma verificao efetiva pode aumentar a produtividade em projetos de software [BARRETO, 2006]. O termo verificao est definido de diversas formas na literatura. A verificao pode ser vista como a garantia de que produtos de uma fase particular do processo esto consistentes com os requisitos desta fase e da fase anterior [SCHULMEYER e MACKENZIE, 1999]. A norma internacional ISO/IEC 12207 [ISO/IEC, 2008] define verificao como sendo a confirmao, por exame e fornecimento de evidncia objetiva, do atendimento aos requisitos especificados. O objetivo da verificao determinar se os produtos de software de uma atividade atendem completamente aos requisitos ou condies impostas a eles nas atividades anteriores. Esta norma tambm apresenta um processo de verificao que pode ser usado como referncia auxiliar na implementao deste processo e na interpretao de seus resultados esperados. Atividades de verificao devem ser executadas ao longo do desenvolvimento de um produto, comeando geralmente com a verificao dos requisitos, seguindo com a verificao dos produtos intermedirios (projeto (design), cdigo, dentre outros) e concluindo com a verificao do produto final. Estas avaliaes da qualidade, distribudas ao longo de todo o ciclo de vida, tm como objetivos: (i) assegurar que os requisitos estabelecidos podem ser alcanados; (ii) identificar os requisitos que no podem ser alcanados; (iii) garantir que o software desenvolvido de forma uniforme; (iv) identificar erros para tomar medidas corretivas o mais cedo possvel; e (v) tornar o projeto mais gerencivel [PRESSMAN, 2005]. A avaliao da qualidade de um produto de software deve ser baseada nos requisitos de qualidade especificados para o produto. Com o objetivo de auxiliar nesta avaliao, alguns critrios que atendam aos requisitos especificados devem ser identificados e, se satisfeitos, indicam o atendimento aos requisitos especificados. Para auxiliar na determinao da satisfao dos critrios, podem-se definir questes (checklist) a serem respondidas, ajudando na avaliao [BARRETO, 2006]. A verificao de produtos de software deve ser realizada por meio da aplicao de mtodos e tcnicas especficos ao longo do desenvolvimento do produto. Dois
mtodos de verificao so destacados na literatura [THELIN, 2002; SEI, 2010]: reviso por pares e testes. Reviso por pares um mtodo esttico de verificao no qual um artefato examinado por qualquer integrante da equipe do projeto, exceto o autor do artefato, com o propsito de detectar defeitos [LAITENBERGER et al., 2002]. Em uma reviso por pares so usados critrios objetivos para a avaliao. Por ser um mtodo esttico, isto , que no depende da execuo do cdigo, a reviso por pares pode ser aplicada desde o incio do projeto, ajudando a detectar defeitos mais cedo. Testes tm como objetivo examinar o comportamento do software por meio de sua execuo [JURISTO et al., 2003]. Como o teste baseado na execuo do cdigo, ele s pode ser usado depois que partes do software tenham sido implementadas e, portanto, em uma verificao baseada somente em testes, os defeitos provavelmente sero detectados tardiamente. Para possibilitar a deteco de defeitos to cedo quanto possvel, a proposta associar testes s revises por pares. Por isso, revises e testes devem ser vistos como mtodos complementares. As informaes obtidas durante as revises so extremamente teis para os testes, por permitirem a identificao dos mdulos crticos e propensos a erros [ROCHA et al., 2001]. Verificao de software no simples, uma vez que vrias avaliaes devem ser realizadas ao longo de um projeto e cada avaliao requer planejamento, controle e uso de tcnicas de verificao adequadas. O planejamento da verificao pode ser iniciado no planejamento do projeto e refinado ao longo do projeto. Este planejamento deve estar integrado ao plano do projeto. 9.3 Resultados esperados 9.3.1 VER1 - Produtos de trabalho a serem verificados so identificados Para atender a este resultado esperado deve-se analisar os produtos de trabalho que sero produzidos ao longo do projeto e selecionar aqueles a serem verificados. Uma boa estratgia para seleo de produtos de trabalho leva em considerao as contribuies para o alcance dos objetivos e requisitos do projeto, considerando tambm os riscos do projeto. Desta forma, os principais produtos de trabalho em um projeto so geralmente objeto de atividades de verificao. Alguns possveis produtos de trabalho selecionados para a verificao, por sua importncia, podem ser o plano do projeto, o documento de requisitos, o documento de anlise, o documento de projeto e o cdigo-fonte.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor. conveniente, entretanto, que a organizao adquirente aprove a escolha dos produtos de trabalho que sero verificados.
54/69
9.3.2 VER2 - Uma estratgia de verificao desenvolvida e implementada, estabelecendo cronograma, revisores envolvidos, mtodos para verificao e qualquer material a ser utilizado na verificao O alcance deste resultado esperado envolve definir uma estratgia de verificao descrevendo os procedimentos, a infra-estrutura necessria e as responsabilidades pelas atividades de verificao. Os mtodos que sero usados para verificao de cada produto de trabalho selecionado para verificao devem ser identificados, garantindo, em cada projeto, a realizao de algum tipo de reviso por pares e testes. As ferramentas que apoiaro a execuo das atividades de verificao tambm devem ser definidas. Alguns mtodos de verificao podem ser classificados como sendo tipos particulares do mtodo reviso por pares e diferem entre si pelo grau de formalidade e pelos papis e responsabilidades dos participantes. Dentre estes, destacam-se os mtodos Walkthrough e Inspeo [SEI, 2010; LAITENBERGER et al., 2002; SCHULMEYER e MACKENZIE, 1999]. O mtodo Walkthrough tem por objetivo avaliar um ou mais artefatos para identificar defeitos e considerar possveis solues alternativas. Consiste de uma preparao e uma reunio de avaliao de, no mximo, duas horas e da qual participam, no mximo, sete pessoas. Os participantes assumem papis especficos, tais como moderador, autor, secretrio e membros [SCHULMEYER e MACKENZIE, 1999]. Ao moderador cabe, por exemplo, definir os demais participantes, organizar o walkthrough e definir local, data e agenda da reunio. O autor o responsvel pela produo dos artefatos avaliados alm de apresent-los durante a reunio. O secretrio deve auxiliar o moderador durante a reunio enquanto os demais membros devem avaliar os artefatos, registrar os defeitos encontrados e sugerir solues. Os problemas encontrados e as solues propostas so registrados e a equipe, com base nos problemas encontrados, decide pela aceitao ou no dos artefatos avaliados. Caso julguem adequado, por exemplo, se encontrarem problemas muito graves, os participantes podem decidir pela rejeio dos artefatos. Posteriormente, o autor corrige os problemas encontrados e, caso a deciso tenha sido a rejeio dos artefatos, outra avaliao deve ser realizada [SCHULMEYER e MACKENZIE, 1999]. Uma inspeo realizada de acordo com um processo bem definido tendo como principais caractersticas a preparao para a reunio, realizada individualmente por cada participante, e o uso de checklists para facilitar a deteco de defeitos. Neste mtodo, os participantes avaliam os artefatos com base nos critrios definidos nos
checklists antes da reunio [SCHULMEYER e MACKENZIE, 1999]. Assim como no walkthrough, os inspetores, com base nos problemas encontrados, decidem pela aceitao ou no dos artefatos avaliados. Alm da inspeo e do walkthrough, a reviso por pares pode ser implementada com uma reviso simples, onde somente uma pessoa revisa o artefato, desde que: o revisor no seja o prprio autor do documento; o revisor seja um par do autor, isto , o revisor exera uma funo semelhante do autor ou, no mnimo, tenha conhecimento sobre o documento para revisar o seu contedo; e que sejam usados critrios objetivos para a reviso. Testes tm como objetivo verificar dinamicamente o comportamento de um programa, usando um conjunto de casos de teste adequadamente selecionados, em relao ao seu comportamento esperado [IEEE, 2004]. A execuo dos testes envolve vrias fases e abrange verificao e validao. Primeiro, cada unidade do programa testada, isolada das demais unidades. Esse teste, conhecido como teste de unidade, verifica se a unidade funciona de forma adequada aos tipos de entrada esperados, a partir do estudo do projeto (design) da unidade. Quando todas as unidades j tiverem sido testadas, a prxima fase realizar o teste de integrao, para assegurar que as interfaces entre as unidades foram definidas e tratadas adequadamente. Aps assegurar que as informaes so passadas entre as unidades de acordo com o que foi projetado, o momento de realizar o teste do sistema. O teste do sistema envolve: teste funcional; teste de desempenho; teste de aceitao; e teste de instalao. O teste funcional verifica se o sistema integrado realiza as funes especificadas nos requisitos. Aps garantir que as funes do sistema so executadas conforme especificado, pode-se realizar o teste de desempenho que tem como objetivo avaliar como o sistema se comporta em relao aos requisitos no-funcionais especificados, tais como tempo de resposta, uso do processador, segurana, dentre outros. Neste ponto, o produto deve operar conforme os desenvolvedores pretendem e pode-se dizer que o produto est verificado [PFLEEGER, 2004;WALLACE et al., 1996]. Para guiar os desenvolvedores durante a realizao dos testes, diversas tcnicas de teste esto definidas na literatura [TIAN, 2005; IEEE, 2004; RAKITIN, 2001; ROCHA et al., 2001]. As tcnicas de teste de software podem ser classificadas de acordo com a origem das informaes utilizadas para estabelecer os requisitos de teste. Estas tcnicas podem ser classificadas como [MALDONADO e FABRI, 2001]:
Funcional: aborda o software de um ponto de vista macroscpico e estabelece os requisitos de teste a partir da especificao do produto. Esta tcnica tambm chamada de caixa-preta ou comportamental; Estrutural: estabelece os requisitos de teste com base na implementao do cdigo. Esta tcnica tambm chamada de caixa-branca ou caixa-de-vidro; Com base em erros: estabelece os requisitos explorando os erros tpicos e comuns cometidos durante o desenvolvimento do software; Com base em mquina de estado finito: utiliza a estrutura de mquinas de estado finito e o conhecimento subjacente para determinar os requisitos de teste.
56/69
A maior diferena entre teste funcional e estrutural est na perspectiva e no foco. Teste funcional tem o foco no comportamento externo de um sistema de software ou de alguns de seus componentes, considerando o objeto a ser testado como uma caixa preta que nos impede de ver seu interior. Por outro lado, teste estrutural coloca o foco na implementao interna, considerando o objeto a ser testado como uma caixa branca que nos permite ver seu interior. Alm de identificar os mtodos de verificao que sero usados, necessrio definir os participantes envolvidos na verificao e seus respectivos papis. Tambm devem ser definidos os interessados nos resultados de cada verificao a ser realizada bem como os procedimentos para disponibilizar tais resultados. Deve ser definido, ainda, um cronograma para as atividades de verificao e os recursos necessrios execuo das atividades devem ser planejados. Este cronograma e a alocao dos recursos, tanto humanos quanto outros recursos em geral, devem estar integrados ao plano do projeto. O planejamento especfico requerido para cada mtodo de verificao tambm deve ser documentado como, por exemplo, o planejamento das revises por pares identificando os papis, a documentao para a preparao individual, a data e o local da reunio preliminar (se houver) e da reunio de inspeo, se uma reinspeo ou no e critrios para decidir se ser feita uma nova inspeo e, tambm, o planejamento dos testes. Alm disso, qualquer material necessrio verificao de um determinado produto de trabalho como, por exemplo, o material para preparao individual das revises por pares, deve ser identificado neste planejamento e disponibilizado no momento da execuo da verificao.
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor. conveniente, entretanto, que a organizao adquirente aprove a estratgia e os mtodos de verificao do fornecedor. Sem comentrio adicional para este resultado.
57/69
9.3.3 VER3 - Critrios e procedimentos para verificao dos produtos de trabalho a serem verificados so identificados e um ambiente para verificao estabelecido O alcance deste resultado esperado implica na definio dos critrios e procedimentos que sero utilizados para a verificao de cada produto de trabalho e na preparao do ambiente para verificao, disponibilizando ferramentas, recursos de hardware, infra-estrutura de rede e outros recursos necessrios execuo das atividades planejadas. Para ajudar a determinar se um critrio foi ou no atendido, questes (checklist) e/ou mtricas para cada critrio podem ser definidas. Algumas sugestes de critrios e questes para alguns artefatos podem ser encontradas em [ISO/IEC, 2008; ISO/IEC, 2001; RAKITIN, 2001; McCONNELL, 2004; MYERS, 2004; BARRETO, 2006]. Os relatrios tcnicos [ISO/IEC, 2003a; ISO/IEC, 2003b; ISO/IEC, 2004] apresentam um conjunto de critrios para avaliao de produto associados s caractersticas de qualidade do produto e mtricas relacionadas a esses critrios. Para cada mtrica so apresentados o nome e o propsito da mtrica, o mtodo para sua aplicao, as frmulas de clculo da mtrica e os elementos computacionais usados na composio da mtrica, a interpretao do valor medido, o tipo de escala da mtrica, o tipo de medida, os dados de entrada para a medio, as referncias ISO/IEC 12207 [ISO/IEC, 2008] e os usurios interessados nos resultados da mtrica. A Tabela 5.1 mostra um exemplo com caractersticas de qualidade, critrios e questes para verificao de um documento de requisitos do software utilizando reviso por pares [BARRETO, 2006]. Tabela 5.1 Exemplo de Critrios para Avaliao de Requisitos de Software [BARRETO, 2006]
Caracterstica de Qualidade Critrio Consistncia Interna Consistncia Checklist Os requisitos so consistentes entre si? Os requisitos do software so consistentes com os requisitos do cliente? Os requisitos do software so consistentes com os requisitos do sistema? O significado de cada requisito compreensvel? Clareza Clareza Os requisitos esto descritos com um nvel de detalhes suficiente para o entendimento? Os requisitos podem ser entendidos e desenvolvidos por um grupo independente? Testabilidade Adequao Segurana Viabilidade de testes Cada requisito testvel?
Consistncia Externa
Adequao s Os requisitos descritos so adequados s necessidades necessidades do cliente do cliente? Controle de acesso Todos os usurios do software esto identificados? Os requisitos de segurana esto especificados?
58/69
9.3.4 VER4 - Atividades de verificao, incluindo testes e revises por pares, so executadas Este resultado esperado visa garantir que as atividades de verificao so executadas conforme planejado, o que inclui, obrigatoriamente, a realizao de reviso por pares e testes.
9.3.5 VER5 - Defeitos so identificados e registrados Este resultado esperado visa garantir que os defeitos identificados durante a execuo da verificao so documentados e registrados. Para registro dos defeitos identificados pode-se usar uma classificao de defeitos, por exemplo, por severidade (crtico, srio, moderado) ou por origem (requisitos, projeto (design), cdigo, testes).
59/69
Aps a eliminao dos defeitos, deve-se julgar a necessidade de executar nova verificao para garantir que os defeitos foram removidos adequadamente e que novos defeitos no foram introduzidos no produto ou componente do produto. Nem todos os defeitos encontrados precisam ser corrigidos. A organizao pode definir critrios que facilitem essa anlise considerando os riscos para o projeto e o impacto na qualidade do produto.
9.3.6 VER6 - Resultados de atividades de verificao so analisados e disponibilizados para as partes interessadas O alcance deste resultado esperado envolve realizar uma anlise dos resultados obtidos em cada atividade de verificao e disponibilizar estes resultados para as partes interessadas. Assim, uma forma de alcance deste resultado pela anlise de laudos de avaliao e relatrios de testes que contenham informaes sobre os resultados obtidos aps a realizao das atividades de verificao. Exemplos de perguntas que podem ser respondidas com esta avaliao incluem: Os critrios definidos foram satisfeitos? As aes corretivas planejadas foram concludas? A verificao foi executada conforme planejado? Os resultados obtidos permitem a aprovao do artefato verificado?
Comentrios adicionais para implementao em diferentes tipos de organizao Adquirentes de Software (Parte 8) Dependendo do tipo de aquisio, este resultado pode ser excludo do escopo da avaliao da organizao adquirente pelo fato da atividade correspondente ser executada pelo fornecedor. conveniente, entretanto, que a organizao adquirente analise os resultados das atividades de verificao.
60/69
10 Os atributos de processo no nvel D A evoluo do nvel E para o nvel D no apresenta novidades em termos dos atributos de processo j implantados no nvel E. A evoluo para o nvel D do MRMPS implica, portanto, como descrito na seo 4, apenas na definio e implementao dos cinco novos processos com a mesma capacidade dos processos j implantados.
61/69
Referncias Bibliogrficas [ALEXANDER e ROBERTSON, 2004] ALEXANDER, I., ROBERTSON, S. Understanding Project Sociology by Modeling Stakeholders. IEEE Software, vol. 21, no. 1, pp. 23-27, Jan/Feb, 2004. [ANDERSSON, 2003] ANDERSSON, C., Exploring the Software Verification and Validation Process with Focus on Efficient Fault Detection, Licentiate Thesis, Lund Institute of Technology (LTH), Lund University, Sweden, 2003. [BARRETO, 2006] BARRETO, A.O.S., Apoio Verificao de Software em Ambientes de Desenvolvimento de Software Orientados Organizao, Dissertao de M. Sc., COPPE/UFRJ, Rio de Janeiro, Brasil, 2006. [BARTI, 2002] BARTI, A., Garantia da Qualidade de Software, Editora Campus, So Paulo, 2002 [BASS et al., 2003] BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice. Addison-Wesley, 2 edition, 2003. [BOEHM, 1981] BOEHM, B. Software Engineering Economics. Prentice-Hall, 1981 [BOEHM e BASILI, 2001] BOEHM, B., BASILI, V., Software Defect Reduction Top 10 List, IEEE Computer, v. 34, n.1, pp. 135-137, 2001. [BRIAND et al., 2002] BRIAND, L.C., FENG, J., LABICHE, Y., Experimenting with Genetic Algorithms and Coupling Measures to Devise Optimal Integration Test Orders. In: Technical Report TR SCE-02-03-Version 3, Outubro, Carleton University, Ottawa, Canad, 2002. [BOUCHRIHA, et. al., 2002] BOUCHRIHA, H., DAMOURS, S., LADET, P., A make or buy decision model with economies of scale, Article de confrence avec actes, 2002. [BURGE, 2005] BURGE, J. E., "Software Engineering Using design Rationale", PhD Dissertation, CS Dept., WPI, May, 2005 [CACHERO e KOCH, 2002] CACHERO, C., KOCH, N. Navigation Analysis and Navigation Design in OO-H and UWE. Technical Report 0205, Institute of Computer Science, Ludwig-Maximilians University of Munich, 2002. [CNEZ et al., 2001] CNEZ, L., PROBERT, D., PLATTS, K., Testing a Make-orBuy Process, Proceedings of the Twelfth Annual Conference of the Production and Operations Management Society, POM-2001, March 30 April 2, Orlando, 2001. [COAD e YOURDON, 1992] COAD, P., YOURDON, E. Anlise Baseada em Objetos, Editora Campus, 1992. [CONKLIN, 1989] CONKLIN, J., Design Rationale and Maintainability. Vol. II: Software Track, In: Proceedings of the Twenty-Second Annual Hawaii International Conference, Volume 2, 3-6 Jan. Page(s): 533-539. [HOFMANN et al., 2007] HOFMANN, H. F., YEDLIN, D. K., MISHLER, J. W., KUSHNER, S., 2007, CMMI for Outsourcing, Addison Wesley, 2007.
62/69
[IEEE, 2004] IEEE COMPUTER SOCIETY PROFESSIONAL PRACTICES COMMITTEE. Software Engineering Body of Knowledge SWEBOK, 2004 Disponvel em: http://www.swebok.org, verificado em Abril/2009. [ISO/IEC, 1994] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC 12119: Information Technology Software packages Quality requirements and testing, Geneve: ISO, 1994. [ISO/IEC, 2001] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-1: Software engineering - Product quality - Part 1: Quality model. Geneve: ISO, 2001. [ISO/IEC, 2003a] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-2: Software engineering - Product quality - Part 2: External metrics. Geneve: ISO, 2003. [ISO/IEC, 2003b] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-3: Software engineering - Product quality - Part 3: Internal metrics. Geneve: ISO, 2003. [ISO/IEC, 2004] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMMISSION. ISO/IEC TR 9126-4: Software engineering - Product quality - Part 4: Quality in Use. Geneve: ISO, 2004. [ISO/IEC, 2008] THE INTERNATIONAL ORGANIZATION FOR STANDARDIZATION AND THE INTERNATIONAL ELECTROTECHNICAL COMISSION. ISO/IEC 12207:2008 Systems and software engineering Software life cycle processes, Geneve: ISO, 2008. [JURISTO et al., 2003] JURISTO, N., MORENO, A.M., VEGAS, S., Limitations of Empirical Testing Technique Knowledge, Lecture Notes on Empirical Software Engineering, Series on Software Engineering and Knowledge Engineering, v. 12, pp.1-38, 2003. [KELLNER et al., 1999] KELLNER, M., MADACHY, R., RAFFO, D. Software Process Modeling and Simulation: Why, What, How. Journal of Systems and Software, Vol. 46, No. 2/3, 1999. [LAITENBERGER et al., 2002] LAITENBERGER, O., VEGAS, S., CIOLKOWOSKI, M., The State of the Practice of Review and Inspection Technologies in Germany, Tech Report Number: ViSEK/011/E, 2002. [LARMAN, 2004] LARMAN, C. Utilizando UML e Padres. 2 edio, Bookman Companhia Ed., 2004. [LIMA, 2005] LIMA, G. M. P. S., Heursticas para Identificao da Ordem de Integrao de Classes em Testes Aplicados a Software Orientado a Objetos, Tese de M. Sc., COPPE/UFRJ, Rio de Janeiro, Brasil, 2005.
[MALDONADO e FABRI, 2001] MALDONADO, J.C., FABRI, S.C. Verificao e Validao de Software. In: Qualidade de Software Teoria e Prtica, Prentice Hall, pp. 66-73, So Paulo, Brasil, 2001. [McCONNELL, 2004] McCONNELL, S., Code Complete, 2 Edio, Microsoft Press, Washington, Estados Unidos, 2004. [MYERS, 2004] MYERS, G., The Art of Software Testing, 2 Edio, John Wiley & Sons, Hoboken, New Jersey, Estados Unidos, 2004. [PENDER, 2004] PENDER, T., UML, A Bblia. Rio de Janeiro: Elsevier, 1 Edio, 2004 [PFLEEGER, 2004] PFLEEGER, S.L. Engenharia de Software Teoria e Prtica, 2 edio, Prentice Hall, So Paulo, Brasil, 2004. [PRESSMAN, 2005] PRESSMAN, R. S. Software Engineering: A Practitioner's Approach, 6th. ed., McGraw-Hill. [PUTNAM e MYERS, 2003] PUTNAM, L.H., MYERS, W., Five Core Metrics, Dorset House Publishing, 2003. [RAKITIN, 2001] RAKITIN, S.R., Software Verification and Validation for Practitioners and Managers, 2 Edio, Artech House Publishers, Norwood, Estados Unidos, 2001. [ROCHA et al., 2001] ROCHA, A.R.C., MALDONADO, J.C., WEBER, K.C., Qualidade de Software Teoria e Prtica, Prentice Hall, So Paulo, Brasil, 2001. [ROSENBLUM e WEYUKER, 1997] ROSENBLUM, D. S. and WEYUKER,E. J., Using coverage information to predict the cost effectiveness of regression testing strategies. IEEE Trans. on Software Engineering, 23(3): 146-156, 1997. [ROTHERMEL e HARROLD, 1996] ROTHERMEL, G. and HARROLD, M. J., Analyzing regression test selection techniques. IEEE Trans. on Software Engineering, 22(8):529-55 1, 1996. [SCHULMEYER e MACKENZIE, 1999] SCHULMEYER, G.G., MACKENZIE, G.R., Verification & Validation of Modern Software-Intensive Systems, New Jersey, Prentice-Hall Inc, 1999. [SEI, 2010] SOFTWARE ENGINEERING INSTITUTE - SEI. CMMI for Development (CMMI-DEV), Version 1.3, Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2010. [SEYBOLD et al., 2005] SEYBOLD, C., GLINZ, M., MEIER, S., "Simulation-based Validation and Defect Localization for Evolving, Semi-Formal Requirements Models", In:Proceedings of the 12th Asia-Pacific Software Engineering Conference, pp.408-420, 2005. [SHAW e GARLAN, 1996] SHAW, M., GARLAN, D., Software Architectures-Perspectives on an Emerging Discipline, Prentice Hall, 1996. [SOFTEX, 2011a] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral:2011, junho 2011. Disponvel em www.softex.br.
[SOFTEX, 2011b] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de avaliao:2011, maio 2011. Disponvel em www.softex.br. [SOFTEX, 2011c] ASSOCIAO PARA PROMOO DA EXCELNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia de Aquisio:2011, junho 2011. Disponvel em www.softex.br. [SOM, 2005] SOM, S., "Use Cases based Requirements Validation with Scenarios", In: Proceedings of the 2005 13th IEEE International Conference on Requirements Engineering, pp.465-466, 2005. [SOMMERVILLE, 2003] SOMMERVILLE, I. Engenharia de Software, Addison Wesley, 6a edio, 2003. [SUKUMARAN et al., 2006] SUKUMARAN, S., SREENIVAS, A., VENKATESH, R., "A rigorous approach to requirements validation", In: Proceedings of the Fourth IEEE International Conference on Software Engineering and Formal Methods, pp.236-245, 2006. [THELIN, 2002] THELIN, T., Empirical Evaluations of Usage-Based Reading and Fault Content Estimation for Software Inspections, Doctoral Thesis, Lund University, Sweden, 2002. [TIAN, 2005] TIAN, J., Software Quality Engineering - Testing, Quality Assurance, and Quantifiable Improvement, John Willey & Sons, Hoboken, Estados Unidos, 2005. [VIEIRA e TRAVASSOS, 1998] VIEIRA, M.E.R., TRAVASSOS, G.H., An Approach to Perform Behavior Testing in Object-Oriented Systems. Technology of ObjectOriented Languages and Systems, Setembro, pp 318-328, 1998. [WALLACE et al., 1996] WALLACE, D.R., IPPOLITO, L.M., CUTHILL, B., Reference Information for the Software Verification and Validation Process, National Institute of Standards and Technology, NIST Special Publication 500-234, 1996.
65/69
Lista de colaboradores do Guia de Implementao Parte 4:2011
Editores: Gleison dos Santos Souza Ana Regina C. Rocha Revisores: Ana Liddy Cenni C. Magalhes Danilo Scalet QualityFocus e UFMG CELEPAR COPPE/UFRJ COPPE/UFRJ (Coordenadora da ETM)
66/69
Lista de colaboradores do Guia de Implementao Parte 4:2009
Editores: Ana Regina C. Rocha Gleison dos Santos Souza Mariano Angel Montoni COPPE/UFRJ (Coordenadora da ETM) COPPE/UFRJ COPPE/UFRJ
Revisores Ana Liddy C. C. Magalhes Ana Regina C. Rocha Edmeia Leonor Pereira de Andrade QualityFocus e Universidade FUMEC COPPE/UFRJ (Coordenadora da ETM) EMBRAPA e UCB
67/69
Lista de colaboradores do Guia de Implementao Parte 4 verso 1.1 Julho/2007
Editores: Ana Regina C. Rocha Mariano Angel Montoni Revisores: Danilo Scalet Edmeia Leonor Pereira de Andrade Fbio Bianchi Campos CELEPAR MAPA Universidade Catlica de Braslia COPPE/UFRJ (Coordenadora da ETM) COPPE/UFRJ
68/69
Lista de colaboradores do Guia de Implementao Parte 4 verso 1.0 Dezembro/2006
Editoras: Ana Regina C. Rocha Kthia Maral de Oliveira Colaboradores: Ahilton Barreto Andrea Soares Barreto Svio Figueiredo Tayana Conte Revisores: Danilo Scalet Kthia Maral de Oliveira CELEPAR Universidade Catlica de Braslia COPPE/UFRJ COPPE/UFRJ COPPE/UFRJ COPPE/UFRJ COPPE/UFRJ (Coordenadora da ETM) Universidade Catlica de Braslia
69/69

Guia de Implementacao Parte 4 2011

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Guia de Implementacao Parte 4 2011

Transféré par

Droits d'auteur :

Formats disponibles

MPS.

BR - Melhoria de Processo do Software Brasileiro

Guia de Implementao Parte 4: Fundamentao para Implementao do Nvel D do MR-MPS

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

As alteraes deste Guia de Implementao em relao verso 2009 so decorrentes de:

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Fbrica de Teste (Parte 10)

Desenvolvimento de Requisitos (DRE)

MPS.BR Guia de Implementao Parte 4:2011

Fbrica de Teste (Parte 10)

MPS.BR Guia de Implementao Parte 4:2011

Modelo de Casos de Uso e Cenrios; Modelo de Classes; Diagramas de Sequncia e de Atividade;

MPS.BR Guia de Implementao Parte 4:2011

Este resultado obrigatrio qualquer que seja o tipo de aquisio.

Sem comentrio adicional para este resultado.

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

O alcance deste resultado esperado pode abranger:

Sem comentrio adicional para este resultado.

O alcance deste resultado esperado pode compreender:

MPS.BR Guia de Implementao Parte 4:2011

Integrao do Produto (ITP)

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

do sistema de nvel intermedirio. Essas trs camadas justificam o nome da abordagem;

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 4:2011

Projeto e Construo do Produto (PCP)

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Imagens geralmente utilizadas pela organizao na documentao.

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Sem comentrio adicional para este resultado.

Sem comentrio adicional para este resultado.

Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

Adquirentes de Software (Parte 8)

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

MPS.BR Guia de Implementao Parte 4:2011

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.

Sem comentrio adicional para este resultado.

MPS.BR Guia de Implementao Parte 4:2011

Fbrica de Software (Parte 9) Fbrica de Teste (Parte 10)

Sem comentrio adicional para este resultado.