Os Padrões ISO/IEC 12207 e 15504 e a Modelagem de Processos da Qualidade de Software

8/14/2019 Os Padres ISO/IEC 12207 e 15504 e a Modelagem de Processos da Qualidade de Software

1/6

Os Padres ISO/IEC 12207 e 15504 e a Modelagem de Processos da Qualidade de

Software

Carlos LahozInstituto de Aeronutica e Espao (IAE)

Centro Tcnico Aeroespacial (CTA)[email protected]

Nilson SantAnnaInstituto Nacional de Pesquisas Espaciais

(INPE)

[email protected]

Abstract

Nowadays, in the software engineering community, it is

an general consensus that improving the software

development processes, we improve the quality of the

generated products These processes must be clearly

understood and well defined so that they can be

implemented in an organization that design and develop

software. This work presents a Support processes study,

proposed by ISO/IEC12207 and 15504 standards, for the

definition, modeling and implantation of the Software

Quality processes in process centered environments. The

modeling language SPEM - Software Process

Engineering Metamodel - is used to express these

processes models.

1. Introduo

Uma das reas de pesquisa de destaque atual daEngenharia de Software a do estudo e melhoria dos

processos pelos quais osoftware construdo. De modogeral, processo desoftware a denominao do conjuntode polticas, estruturas organizacionais, tecnologias,

procedimentos e artefatos necessrios para conceber,desenvolver, construir e manter um produto de software[2], tendo impacto direto na qualidade dos produtosgerados.

A gesto da qualidade, neste contexto, tem um papelatuante na definio de processos que possibilitem que os

produtos gerados tenham um nvel de qualidade aceitvele de forma a extrair informaes em todo odesenvolvimento dos produtos. A qualidade deve buscarcontinuamente formas de melhoria de processo e de

produto.Diversos modelos de processo de desenvolvimento de

software surgiram nos ltimos anos como, por exemplo,os apresentados pelos padres 12207 [5] e 15504 [6]. O

padro 12207 prescreve um processo para o

desenvolvimento e manuteno de software, atravs dadeterminao de um conjunto de atividades essenciais quedevem ser completadas para se obter um produto desoftware. J o padro 15504 define uma estrutura paraavaliao e melhoria de processos de engenharia de

software, e prescreve prticas bsicas que devem serrealizadas para que se atinjam certos nveis dematuridade.

Estes modelos representam o processo desoftware soba tica de seu funcionamento, mas no apresentam comoestes processos devem ser definidos, ficando estaresponsabilidade uma atribuio das organizaesfabricantes desoftware.

Para a definio e modelagem dos processos daqualidade, como ponto de partida, foram utilizados asabordagens destes dois padres, 12207 e 15504, eescolhida a linguagem de modelagem SPEM[11].Segunda a viso proposta pelo trabalho, os processos

Suporte so diretamente relacionados com a gesto daqualidade e devero, futuramente, ser implementados noAmbiente Integrado para o desenvolvimento e gesto de

projetos desoftware [9], projeto oriundo do INPE, queatualmente apoiado pelo Programa de Capacitao deRecursos Humanos (RHAE) do CNPq.

O artigo foi divido da seguinte forma: a seo 2apresenta os padres de processo de software utilizadoscomo base do estudo. Na seo 3, uma definio para agesto qualidade neste contexto. Na 4, modelagem de

processo e, em particular, a linguagem de modelagem deprocesso SPEM, so apresentadas. Na seo 5, ilustradouma idia mais prtica sobre modelagem de processo.

Finalmente as consideraes sobre este estudo soapresentadas na seo 6.

2. Padres de Processo deSoftwareA melhoria de processo desoftware tem sido praticada

h aproximadamente vinte anos, e teve um grandeimpulso por volta de 1987, quando o Software

Engineering Institute (SEI) em Pittsburgh, EUA, lanouseu Capability Maturity Model, que originou o Capability


2/6

Maturity Modelpara Software, ou SW-CMM. Desdeento, no s o SW-CMM teve um desenvolvimentoconsidervel, como tambm outros mtodos de melhoriade processo de software surgiram, como o ISO/IEC15504/SPICE e o ISO/IEC 12207.

Apesar de terem se originado de comunidades

diferentes, os padres 12207 e o 15504 foramdesenvolvidos praticamente ao mesmo tempo e tm muitoem comum. O padro 15504, que comeou com ochamado WG10 (estabelecido pela ISO/IEC/JTC1 SC7do SPICE, SoftwareProcess Improvement and CapabilitydEtermination), publicado em julho de 1995 preocupa-secom as atividades de avaliao e melhoria de processos,enquanto que o ISO/IEC 12207, publicado em agosto de1995, o enfoque principal est nos ciclo de vida dedesenvolvimento de software, incorporando os processosde desenvolvimento, aquisio, fornecimento egerenciamento desoftware. Ambos, no entanto, baseiam-se num modelo muito semelhante.

2.1. O ISO/IEC 12207

O padro internacional ou modelo de refernciaISO/IEC 12207 - Processos do Ciclo de Vida do Softwaretem como principal objetivo fornecer uma estrutura nica

para que o adquirente, fornecedor, desenvolvedor,mantenedor, operador, gerentes e tcnicos envolvidoscom o desenvolvimento de software utilizem umalinguagem comum que estabelecida na forma de

processos bem definidos.A estrutura da norma foi concebida de maneira a ser

flexvel, modular e adaptvel s necessidades de quem a

utiliza. Para isto, ela est fundamentada em dois princpios bsicos: modularidade e responsabilidade.Modularidade, no sentido de processos com mnimoacoplamento e mxima coeso. Responsabilidade, nosentido de estabelecer um responsvel nico por cada

processo, facilitando a aplicao da norma em projetosonde vrias pessoas podem estar legalmente envolvidas.

Agrupa as atividades que podem ser executadasdurante o ciclo de vida em processos primrios oufundamentais, de suporte, e organizacionais. Os processosfundamentais atendem ao contrato entre fornecedor eadquirente e execuo do desenvolvimento, da operaoou da manuteno de produtos desoftware durante o seu

ciclo de desenvolvimento. Os processo de apoio, auxiliame contribuem para o sucesso e a qualidade do projeto desoftware. Os processos organizacionais so empregadospor uma organizao para estabelecer e implementar umaestrutura constituda pelos processos do ciclo de vida e

pelo pessoal envolvido no seu desenvolvimento. Cadaprocesso divido em um conjunto de atividades, e cadaatividade em um conjunto de tarefas. Os processos deapoio e organizacionais devem existir independentemente

da organizao e do projeto que est sendo executado. Osprocessos fundamentais so instanciados de acordo com asituao. Estes processos, atividades e tarefas podem seradaptados de acordo com as caractersticas de um projetodesoftware

2.2. O ISO/IEC 15504

O padro, ou modelo de referncia ISO/IEC 15504 foidesenvolvido como um framework para avaliao de

processos de engenharia desoftware e da organizao do projeto e do negcio. Ele organiza e classifica asmelhores prticas em duas dimenses: categorias de

processo e nveis de capacidade. Cada uma das categoriasde processo detalhada em processos mais especficos,ou subcategorias (Cliente-fornecedor, Engenharia,Projeto, Suporte e Organizao). Este modelo visatambm avaliar a capacidade da organizao em cada

processo, permitindo assim sua melhoria. Cada um dos

processos deve ser classificado em nveis (incompleto,executado, gerenciado, estabelecido, previsvel eotimizado).

Seu modelo de referncia serve de base para oprocesso de avaliao como um conjunto padronizado de processos fundamentais, que orientam para uma boaengenharia de software. Cada uma das categorias de

processo detalhada em processos mais especficos, ousubcategorias. O resultado de uma avaliao um perfilda instituio em forma de matriz, onde temos os

processos nas linhas e os nveis de capacitao nascolunas.

O 15504 possui um conjunto de nove documentos que

endeream avaliao de processo, assessoria detreinamento e competncia, determinao da capacidade emelhoria de processo e est se tornando um modelo dereferncia para outros padres como o CMMI [2],

patrocinado pelo Departamento de Defesa norte-americano, com colaboraes da indstria, governo e peloSEI. O CMMI tem como um de seus objetivos bsicos,integrar os diversos modelos CMM existentes, bem como

pretende garantir compatibilidade com a 15504, atravsda sua viso contnua de modelo, composto por reas de

processos universais e fundamentais. Possui ainda umoutra dimenso composta por uma mtrica para aavaliao da capacidade de cada processo em uma

organizao.

3. Gesto da Qualidade de SoftwareQualidade um conceito complexo, porque possui

significados diversos para diferentes pessoas, em umcontexto altamente dependente. Portanto, no trivialhaver medidas simples de qualidade aceitveis para todos.Para estimar ou melhorar a qualidade de software numaorganizao, deve-se definir as caractersticas de


3/6

qualidade, nas quais se est interessado e, ento, decidircomo sero medidas [7].

Segundo Sommerville [10] podemos identificar quatrofatores que afetam a qualidade dos produtos de software:tecnologia de desenvolvimento; qualidade dos processos;qualidade das pessoas; cronograma (recursos e tempo).

No que tange a qualidade dos processos estamos nosreferindo ao grau de satisfao e eficincia do processoou um conjunto de processos, utilizados por umaorganizao ou projeto para: planejar, gerenciar, executar,monitorar, controlar e melhorar as atividades relacionadas construo de software [12].

Dentro do aspecto qualidade de produto e de processo,a gesto da qualidade desoftware atua como um atividadeguarda-chuva, que aplicada ao longo de toda o

processo de engenharia desoftware, podendo, segundo aviso de Pressman [8] abranger (1) a definio demtodos e ferramentas para o desenvolvimento do

produto; (2) revises e tcnicas formais de avaliao que

so aplicadas durante todo o ciclo de vida do produto; (3)controle dos produtos, sua documentao e suasmudanas; (4) procedimentos para a garantia e adequaoaos padres de desenvolvimento, quando aplicveis; (5)mecanismos de medio e divulgao. Alm destasatividades, podemos acrescentar a criao de umaabordagem cultural da qualidade na organizao [13].

3.1. Os processos da gesto da qualidade

Segundo a viso da gesto da qualidade deste estudo,as atividades da qualidade esto presentes em toda aestrutura de uma organizao produtora desoftware.

Enquanto o 15504 define uma estrutura para avaliao emelhoria dos processos de engenharia de software o12207, preocupa-se com os prprios processos. Ambos

baseiam-se num modelo muito semelhante, de modo queuma abordagem baseada no 15504 est alinhada a 12207.

No padro 15504 a categoria de Gerenciamento(MAN) consiste dos processos que contm prticas denatureza genrica que podem ser usadas por gerentes de

projeto ou de processos de um ciclo de vida de software.Dentre as diversas categorias, identificamos a deGerenciamento da Qualidade, MAN.3, que tem o

propsito monitorar a qualidade dos produtos ou serviose garantir a satisfao do cliente. Este processo prope o

estabelecimento de um foco para o monitoramento daqualidade de produto e processo tanto no projeto como naorganizao.

Podemos identificar tambm nos dois modelos que nacategoria Suporte a maioria dos processos so voltadas

para as atividades da gesto da qualidade. A categoriaSUP consiste dos processos que podem ser aplicados porqualquer dos outros processos, inclusive do prprioSuporte, nos vrios pontos do ciclo de vida dosoftware

Os processos SUP incluem os processos deDocumentao, de Garantia da Qualidade, deGerenciamento da Configurao, de Verificao, deValidao, de Reviso Conjunta, de Auditoria e deResoluo de Problemas. Recentemente a 12207 sofreuuma reviso [4] que incorporou aos processos de Suporte

os processos de Usabilidade e Avaliao de Produto.

4. Modelagem de Processos

Na ltima dcada surgiram numerosos formalismos elinguagens de modelagem, tambm chamadas deLinguagens de Modelagem de Processos (ProcessModeling Languages PMLs), que permitem representar,de maneira precisa e compreensvel, vrias dascaractersticas ou elementos do processo desoftware.

Segundo Fuggeta [3], a modelagem de processos podeser utilizada com diversos propsitos como por exemplo

para (1) o entendimento do processo, (2) representar a

estrutura e organizao, (3) projeto de um novo processo,(4) treinamento e aprendizado de equipes sobreprocedimentos e operaes organizacionais, (5) avaliaode problemas e propostas de melhorias

Os elementos mais comuns que esto presentes em ummodelo de processo, segundo Acua [1] so agentes ouatores, papis, atividades e artefatos ou produtos. Osagentes ou atores so entidades que executam um

processo e podem ser pessoas, sistemas ou ferramentas.Um ator pode desempenhar vrios papis. Os papisdescrevem um conjunto de responsabilidades de atores ougrupos, os direitos e as habilidades necessrias pararealizar uma atividade especfica do processo desoftware.

Uma atividade inclui e implementa os procedimentos, asregras, as polticas e os objetivos para gerar e modificarum conjunto de artefatos. Um artefato ou produto o(sub)produto e a matria prima de um processo. Os(sub)produtos podem ser criados, acessados oumodificados durante a atividade do processo.

As PMLs podem ser classificadas em executveis,quando permitem que o modelo seja executado, ou noexecutveis, quando provem construes que permitemsomente a especificao de um processo

4.1. A Linguagem de Modelagem SPEM

O SPEM, SoftwareProcess Engineering Metamodel, um metamodelo, ou seja,um conjunto de construtores eregras para a criao de modelos. que pode ser usado paradescrever um processo concreto ou uma famlia de

processos de desenvolvimento desoftware. Ela permitesomente a especificao de um processo de software, nosua execuo. A execuo do processo (enactment) noest no escopo deste modelo, o que o coloca, portanto, na


4/6

classe das linguagens de modelagem de processo noexecutveis.

A linguagem foi desenvolvido pelo OMG (ObjectManagement Group), organizao internacional que

promove a teoria e prtica da tecnologia da orientao aobjetos no desenvolvimento de software. Foi liberada ao

uso em dezembro de 2001, para tentar suprir anecessidade de um padro para as tcnicas de modelagemde processo surgidas nos ltimos anos. Define o conjuntomnimo de elementos de modelagem necessrios paradescrever qualquer processo de desenvolvimento de

software, utilizando uma abordagem orientada a objetos ea UML (Unified Modeling Language) como notao.

Um fator que favorece a escolha do SPEM para adefinio de processos que ele se beneficia daexpressividade da UML. Assim, desenvolvedores de

software que estejam familiarizados com a UML podemreutilizar seus conhecimentos de modelagem de softwareno domnio da modelagem de processos desoftware.

5. Um exemplo prtico

De acordo com o padro 12207, a atividade deGarantia do Produto implica em garantir que os planos e

produtos definidos no contrato estejam sendo produzidos,sejam consistentes conforme o especificado e fiquem

prontos em tempo hbil. Ela tambm estabelece que estesprodutos desoftware satisfaam totalmente os requisitoscontratuais especificados e sejam aceitos pelo adquirente(cliente). Na 15504, a prtica bsica 5 do processoSuporte, denominado Garantia da Qualidade estabeleceque devem existir atividades para prover confiana de que

os produtos do trabalho estejam sendo feitos de acordocom padres e requisitos da qualidade. O padro sugereque deve ser conduzida uma estratgia para a garantia daqualidade de forma a identificar a aderncia dos produtosaos padres, procedimentos e requisitos estabelecidos,identificando problemas ou no conformidades, comotambm relatar os resultados das atividades realizadas aosenvolvidos. Nos dois padres a garantia da qualidade seutiliza de outros processos, como o de Verificao,Validao, Reviso Conjunta, Auditoria e Resoluo deProblemas como parte de suas funes, isto , comoresultado da atividade da gesto da qualidade.

5.1. A Garantia de Produto

Uma das atividades principais da qualidade, durante odesenvolvimento dos produtos de um projeto de software a garantia de que os produtos gerados esto de acordocom o especificado no contrato e no projeto, no que tangeaos padres de desenvolvimento (documentos, contedo,

padro de cdigo, etc), funcionalidade, atendimento arequisitos, configurao de desenvolvimento e entrega ao

cliente. Na proposta deste estudo, estabelecido que ao segerar um produto de software (qualquer documento

preliminar, ou final, ou cdigo unitrio, por exemplo)pela primeira vez, deve ser feito seu encaminhamento aGerncia da Qualidade, para sua devida aprovao, e emcaso de parecer conforme o produto ficar liberado

automaticamente para o controle de configurao. Paraisto fica-se estabelecido que primeiramente se instanciarum processo de Verificao, observando-se se os mtodose processos de desenvolvimento esto sendo aplicadoscorretamente. Posteriormente, caso o produto seja cdigo,se far sua Validao, atravs de testes previamentedefinidos. Ao se alcanar um marco especfico, porexemplo, o marco de entrega do produto ao cliente, seriniciado o processo de Auditoria. Os produtos oriundosde modificaes devem passar tambm pelo mesmoencaminhamento. Caso o produto obtenha parecerconforme, outro processo ser disparado, que ser o deControle de Configurao. Caso obtenha parecer no

conforme, o processo a ser instanciado o de Resoluode Problema que tratar de emisso de investigao dano conformidade para soluo e futuro encaminhamento.

5.2. O Processo de Garantia de Produto

Os envolvidos e as atividades do processo de garantiade produtos consiste do Autor do Produto, que encaminhao produto para ser controlado, o Gerente da Qualidadeque abre um Formulrio de Encaminhamento de Produto,e determina um cdigo que identificar tanto a categoriado produto a ser revisado como o tipo de processo a serexecutado (Verificao, Validao, Auditoria). A partir

da so notificados todos os envolvidos com aqueleProduto (Gerente Geral, Revisor, Autor, Gerente daConfigurao, e se for o caso o Cliente). alocado umRevisor para a Verificao e Validao, que estarencarregado da reviso do produto, definindo os critrios

para a reviso, realizando a reviso, tirando possveisdvidas com o Autor do Produto, bem como emitindo o

parecer do Revisor. Em seguida, o Gerente da Qualidadedeve emitir o parecer final. O processo estar encerradocom a notificao dos envolvidos sobre o parecer.

6. Consideraes Finais

Processos de desenvolvimento bem definidos soessenciais na engenharia de software. Neste trabalho,modelos de processo de Suporte do ISO/IEC 12207 edo15504 so apresentados como ponto de partida para adefinio dos processos da qualidade que devem serimplantados em um Ambiente Integrado.

Estes padres prescrevem prticas e atividades quedevem ser realizadas pelo processo de desenvolvimentoespecfico de um projeto ou organizao. No entanto,


5/6

Garantia do Produto do

Trabalho

*

*

*

*

* *

**

*

**

*

*

**

*

*

*

Autor doProduto

Gerente

Projeto

verificar

produto

validar

produto

auditar

produto

Revisor

Gerente

Configurao

GerenteQualidade

Cliente

*

*

*

*

*

*

*

*

*

*

Figura 1. Use case Garantia do Produto do Trabalho.

no definem realmente como deve ser o processoseguido por uma organizao que desenvolve software.

Para exemplificar um dos vrios aspectos de ummodelo de processo de software, utilizou-se o diagramade caso de uso e de atividade da linguagem SPEM.Atravs do diagrama de casos de uso, Figura 1, pode-semostrar as relaes entre os papis e as principaisdefinies de trabalho da Garantia do Produto. J nodiagrama de atividades, Figura 2, permite-se apresentao da seqncia de atividades com seus

produtos de trabalho de entrada e sada, bem como osestados do fluxo de objetos do processo de Verificao.Raias so utilizadas para separar as responsabilidadesdos diferentes envolvidos no processo.

Modelos, expressos em uma linguagem como o SPEM,so utilizados para a definio clara e precisa dos

processos da qualidade, visando a posteriorimplementao destes em um ambiente de engenharia desoftware voltado a processo, os chamados Ambientes deEngenharia de Software Centrados em Processo (Process-centered Software Engineering Environment PSEEs) Anotao padro UML utilizada pelo SPEM facilita aatividade de modelagem de processos, uma vez que se

podem reutilizar os conhecimentos desta linguagemobtidos na prtica da modelagem desoftware.No exerccio de modelagem da seo 5 apresentou-se

apenas a viso de processo, atravs do diagrama de casode uso e de atividades. Outras vises do processo podemser modeladas, por exemplo, a do diagrama de estados, domodelo, suas transies e seus estados. que usado parailustrar o comportamento dos seus elementos

Referncias

[1] Acua, S.; Ferr, X.; Software Process Modelling, Proceedings of the5th World Multiconference on Systemics,Cibernetics and Informatics (SCI 2001), Orlando, Florida, USA.

[2] CMMI Product Development Team, CMMI for Systems Engineering/ Software Engineering/ Integrated Product and

Process Development, Software Engineering Institute, Carnegie

Mellon University, Version 12, (CMU/SEI-2000-TR-031), 2000.

[3] Fuggetta, A., Software Process: A Roadmap, Future ofSoftware Engeneering, Limerick Ireland, 2000.

[4] International Standard for Information Technology,Software life cycle processes, ISO/IEC JTC1/SC7 N2529r

Amendment1, 2001.

[5] International Standard for Information Technology,Softwarelife cycle processes, ISO/IEC 12207 Standard, 1995.

[6]Information Technology Software Process Assessment Part5: An assessment model an indicator guidance, ISO/IEC,TR15504-1, 1998

[7] Kitchenham B.; Pfleeger, S. L, Software Quality: TheElusive Target, IEEE Software, January, 1996.

[8] Pressman, R. S., Engenharia de Software, Makron Books,So Paulo, 1995

[9] Sant'Anna, N., Um ambiente integrado para apoio aodesenvolvimento e gesto de projetos de software para sistemasde controle de satlites, So Jos dos Campos: INPE, 2000(INPE - 8306 - TDI/765).


6/6

Gerente daQualidade

Autor do

Produto

Produto do

Trabalho

Abrir Verificao

Relatrio da

Verificao

(cdigo de

identificao)

Definio dosCritrios da

Verificao

Chekclist

da

Verificao

Revisor

Relatrio da Verificao(critrios estabelecidos)

Conduzir Verificaosolucionar

dvidas soluo no OK

Fechamento da

Verificao

Relatrio da Verificao

(parecer final)

soluo OK

Encaminhar

Produto

dvida

Figura 2. Diagrama de atividades Verificar Produto

[10] Sommerville, I., Software Engineering, 6th edition,Reading: Person Education Limited, Essex, 2001.

[11] SPEM - Software Process Engineering MetamodelSpecification, Object management Group -Software Version 1.0,

formal, 02-11-14,November2002.

[12] Terry R, Software Process Assesment, Part1 Concepts andIntroductory Guide, version 1, SPICE project, ISO/IEC, 1995.

[13] Zulmer, Richard E., Software Quality Engineering: TheDeming Way,American Programmer, June 1989.

Documents

Os Padrões ISO/IEC 12207 e 15504 e a Modelagem de Processos da Qualidade de Software