PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC 15504

Transcrição

1 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DE ACORDO COM A NORMA ISO/IEC MARCELO NORTE DE OLIVEIRA 1 marcelonorte.ti@gmail.com IREMAR NUNES DE LIMA 2 iremar.prof@uol.com.br RESUMO: Este artigo trata da norma ISO IEC 15504, especificamente da seção que trata da engenharia de software. São discutidos os motivos do surgimento das normas de qualidade e como elas podem contribuir para a organização atingir os seus objetivos. São identificados também, diversos parâmetros que podem nortear as organizações de Tecnologia da Informação que desejam otimizar seus processos de desenvolvimento software baseados na norma ISSO IEC PALAVRAS-CHAVE: Norma ISO/IEC 15504, Desenvolvimento de Software, Spice, Qualidade de Software. INTRODUÇÃO A ISO/IEC 15504, também conhecida como Spice, é um modelo que possui como foco a melhoria dos processos de desenvolvimento de software e a determinação da capacidade de processos de uma organização (FELIPE, 2006). A sua existência se justificou em função de estudos que comprovaram que a grande maioria dos projetos de software não atendem aos objetivos traçados (RINCON, 2009). Em contrapartida à grande importância que o software tem tido no cenário mundial, Rincon afirma que, de acordo com esses estudos, isso é decorrente da falta de processos adequados nas organizações em que eles são desenvolvidos. Ainda segundo Rincon, desde o final das décadas de 80, modelos de maturidade de software estão sendo criados ou vem evoluindo em todo mundo justamente para mudar essa realidade. Daí surgiram modelos como o do SEI Software Engineering Institute que publicou o SW-CMM Capability Maturity Model for Software em 1987 e o CMMI Capability Maturity Model Integration em 2002 e a ISO/IEC International Organization for Standardization / International Electrotechnical Commission (ISO, 2009) que publicou as normas ISO/IEC e ISO/IEC nos anos 90. Nosso foco de interesse é a norma ISO/IEC que foi desenvolvida para ser utilizada por organizações envolvidas em planejar, gerenciar, monitorar, controlar e melhorar a aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software (MAIARA, 2009). O estudo do tema justifica-se pela crescente importância do software para a economia mundial. A ciência da computação levou tempo para desenvolver ferramentas extremamente eficientes para construção de softwares, como linguagens de programação, ambientes integrados de desenvolvimento, entre outros, mas o software construído, apesar da qualidade da ferramenta, ainda apresenta sérios problemas. NORMAS E METODOLOGIAS PARA A QUALIDADE DE SOFTWARE Rezende, em sua obra Engenharia de Software e Sistemas de Informação, cita que a expressão crise do software começou a ser utilizada na década de 60, e referese a um conjunto de problemas recorrentes enfrentados no processo de desenvolvimento de software. Coloca ainda que é uma enorme variedade de problemas que caracterizam esse período. Vasconcelos, Rouiller, Machado e Medeiros caracterizam os problemas típicos da crise do software da como sendo previsão pobre, baixa qualidade, alto custo de manutenção e duplicação de esforços. Rincon acrescenta ainda o fato de os softwares não atenderem aos objetivos colimados. Ainda segundo esses autores, reconhecida a crise do software, foi proposto que o seu desenvolvimento deixasse de ser puramente artesanal e passasse a ser baseado em princípios de Engenharia, seguindo um enfoque estruturado e metódico. O termo Engenharia de Software se refere ao desenvolvimento de software usando princípios de engenharia de modo a produzir software de qualidade, de forma eficaz e dentro de custos aceitáveis Diante do exposto, a demanda por qualidade de software tem motivado o desenvolvimento de modelos para a qualidade deste produto que é largamente determinada pela qualidade dos processos utilizados para o desenvolvimento (IAHN, 1999). PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN l 125

2 Sabendo-se que grande parte do problema dos softwares não atenderem efetivamente ao objetivo a que se proponham foi atribuído ao processo de desenvolvimento de software caótico, sendo assim identificou-se uma clara necessidade de estudar e aplicar processos de qualidade de software para que os projetos tenham mais chances de sucesso (RINCON, 2009). Hoje no mercado existem diversas normas em voga, entre elas se destacam, por exemplo as normas ISO 9000 para suporte ao desenvolvimento de software, que retiramos da obra Introdução à engenharia de software e à qualidade de software de Vasconcelos, Rouiller, Machado e Medeiros: - Norma ISO/IEC 9126 (NBR 13596): Define as características de qualidade de software que devem estar presentes em todos os produtos (Funcionalidade, Confiabilidade, Eficiência, Usabilidade, Manutenibilidade e Portabilidade). - Norma ISO/IEC 12119: Estabelece os requisitos de qualidade para pacotes de software. - Norma ISO/IEC : Define um processo de avaliação da qualidade de produto de software. - Norma ISO/IEC 12207: Define um processo de ciclo de vida de software. - Norma ISO/IEC : Apresenta diretrizes para a aplicação da ISO 9001 por organizações que desenvolvem software ao desenvolvimento, fornecimento e manutenção de software. - Norma ISO15504: Aprovada como norma em 2003 é focada na avaliação de processos organizacionais. Um outro modelo de qualidade, retirado da mesma obra, é o CMMI, cuja sigla representa as iniciais de Capability Maturity Model Integration e nomeia tanto um projeto, quanto os modelos resultantes deste projeto. O CMMI é uma iniciativa da Software Engineering Institute (SEI), em cooperação com a indústria e governo americanos. Sua arquitetura é composta basicamente pela definição de um conjunto de áreas de processo, organizadas em duas representações diferentes: uma como um modelo por estágio, semelhante ao SW-CMM, e outra como um modelo contínuo semelhante à ISO/IEC (VAS- CONCELOS, ROUILLER, MACHADO, MEDEIROS, 2006). A norma ISO/IEC surgiu em 1993 através do projeto SPICE que foi um trabalho conjunto da ISO/IEC-International Organization for Standardization/International Electrotechnical Commission (VASCONCELOS, ROUILLER, MACHADO, MEDEI- ROS, 2006). Objetivo era obter um consenso através da análise dos diversos métodos de avaliação do processo de software. A norma ISO15504, cuja versão completa foi publicada entre 2003 e 2006, atualmente representa um padrão internacional que estabelece um framework para construção de processos de avaliação e melhoria do processo de software (VAS- CONCELOS, ROUILLER, MACHADO, MEDEIROS, 2006). Nove documentos, alguns de caráter informativo, outros normativo, compõem a ISO15504, são eles: ISO , ISO , ISO , ISO , ISO , ISO , ISO , ISO e ISO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE A ISO define um modelo de referência de processo e um modelo de capacitação do processo que pode compor a base para a definição e avaliação de um processo de software Este modelo de referência possui uma abordagem bidimensional, conforme pode ser vista abaixo: 126 PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN

3 Vasconcelos, Rouiller, Machado e Medeiros distinguem a primeira dimensão como auxiliar para que os engenheiros definam os processos necessários em uma ODS (Organização de Desenvolvimento de Software), e sua adequação à ISO A segunda dimensão, similar ao CMM, e segundo os mesmos autores, tem por objetivo determinar a capacidade do processo da ODS, avaliando-o através de um conjunto de atributos pré-estabelecidos. De acordo com o Technical Report ISO/IEC TR , são cinco grupos de processos definidos pela ISO : 1. Fornecedor-Cliente (CUS-Custormer-Supplier): são os processos que de alguma forma impactam diretamente o cliente: dentre eles o suporte para desenvolvimento e transações de software para o cliente, fornecimento de operações corretas e uso do produto de software ou serviço; 2. Engenharia (ENG-Engineering): esta categoria agrupa os processos que especificam, implementam e mantêm o produto de software, sua relação com o sistema e a documentação do cliente; 3. Suporte (SUP-Support): São processos que podem ser empregados em algum dos outros processos e em vários pontos no ciclo de vida do software objetivando dar suporte a eles; 4. Gerenciamento (MAN-Management): são processos que contêm práticas gerenciais que podem ser utilizadas por alguém que gerencia algum tipo de projeto ou processo dentro do ciclo de vida do software; 5. Organização (ORG-Organization): são processos que estabelecem as finalidades dos processos de desenvolvimento e da organização, do produto, e dos recursos, que, quando utilizados por projetos na organização, realizarão as metas do negócio. O processo que será abordado é a engenharia, mas a título de esclarecimento as ISO e ISO servem como guias para avaliação de processo. Determinam procedimentos para: a definição das entradas da avaliação, a determinação das responsabilidades, a especificação do processo propriamente dito da avaliação e os resultados que devem ser guardados (VASCONCE- LOS, ROUILLER, MACHADO, MEDEIROS, 2006). Do artigo Introdução à engenharia de software e à qualidade de software de Vasconcelos, Rouiller, Machado e Medeiros retiramos a figura abaixo que apresenta a estrutura básica do modelo de avaliação da ISO e seu relacionamento com a ISO Este modelo de avaliação expande o modelo de referência adicionando a definição e uso de indicadores de avaliação. Os indicadores de avaliação são definidos para que os assessores possam julgar o desempenho e capacidade de um processo implementado PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN l 127

4 A ISO detalha os processos (primeira dimensão do modelo de referência da ISO ) associando a eles algumas práticas básicas. Artefatos e atributos são sugeridos e associados às práticas básicas com o intuito de estabelecer sua realização A parte do documento ISO/IEC TR que trata dos processos de engenharia de software traz um conjunto de processos universais que são fundamentais para uma boa engenharia de software e abrange as melhores práticas, ela provê um modelo de referencia que pode ser usado em outras partes da ISO/IEC TR A seção da ISO/IEC que traz um modelo de referência para processos e capacidade de processos define um modelo de referencia de processos de software e capacidade de processos que fornece a base do processo de avaliação de software. Esse modelo de referência define em alto nível os objetivos que são fundamentais para uma boa engenharia de software. De acordo com a ISO/IEC 15504, as definições de alto nível descrevem os objetivos que devem ser alcançados e como alcançá-los. Este modelo de referencia pode ser aplicado a qualquer empresa desenvolvedora de software que deseja estabelecer uma melhoria em seus processos de aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software. O modelo concebido não presume uma organização com características estruturais particulares, filosofia gerencial, modelo de ciclo de vida de software, tecnologia ou metodologia de desenvolvimento de software. A arquitetura deste modelo de referencia organiza os processos para auxiliar a organização a entendê-los e utilizá-los para uma melhoria continua do gerenciamento dos processos de software. Por processo de avaliação de software, um assessor utiliza um modelo mais detalhado compatível com este modelo de referencia da ISO/IEC, contendo um conjunto abrangente de indicadores de performance e capacidade de processos para fazer juízo das condições dos processos da organização. O documento da ISO/IEC TR define que um nível de capacidade é caracterizado por um conjunto de atributos que trabalham juntos para prover um maior aprimoramento da capacidade de realizar um processo. Cada nível prove um maior aprimoramento de capacidade de realização de um processo. Os níveis constituem um meio racional de progredir através da melhoria da capacidade de execução de qualquer processo. São seis os níveis de capacidade no modelo de referencia: - Nivel 0: Incompleto. Há falha geral no atendimento do propósito do processo. Há poucos ou nenhum produto de trabalho facilmente identificável ou saídas do processo. - Nivel 1: Realizado. O propósito do processo é geralmente alcançado, ainda que a sua realização não seja rigorosamente planejada e rastreada. Há elementos na organização que reconhecem que uma ação deveria ter sido realizada, e é consenso geral que esta ação é realizada quando exigida. É possível identificar produtos do trabalho realizado através do processo, e isto comprova que o propósito foi alcançado. - Nível 2 Gerenciado. O processo planejado e rastreado entrega produtos que atendem a padrões e exigências, de acordo com procedimentos especificados. A primeira distinção do nível realizado é que a realização do um processo agora entrega produtos que atendem exigências de qualidade dentro de prazos e necessidades de recursos definidos. - Nível 3 Estabelecido. O processo é realizado e gerenciado usando um processo definido baseado nos bons princípios da engenharia de software. Implementações individuais do processo são de uso aprovado, versões adaptadas de um padrão, processos documentados para alcançar os resultados. Os recursos necessários para estabelecer a definição de processo também são colocados. A primeira distinção do nível gerenciado é que o processo do nível estabelecido usa um processo definido que é capaz de obter o resultado pretendido. - Nível 4 Previsível. O processo definido é colocado em prática consistentemente dentro de limites de controle definidos para alcançar os objetivos colimados. Medições detalhadas da execução são coletadas e analisadas. Isto conduz a um entendimento quantitativo da capacidade do processo e uma melhoria da habilidade de predizer e gerenciar a execução que é quantitativamente gerenciada. A qualidade dos produtos é quantitativamente conhecida. A primeira distinção entre o processo estabelecido é que o processo definido é agora executado consistentemente dentro de limites definidos para alcançar o resultado pretendido. - Nível 5: Otimizado. A realização de um processo é otimizada para encontrar atuais e futuras necessidades do negócio, e o resultado do processo é repetitivamente voltado para os objetivos do negócio. A eficácia do processo e eficiência do objetivo são quantitativamente estabelecidas, baseadas nos objetivos da organização. Monitoramento continuo de processos contra esses objetivos é obtido através de um feedback quantitativo e o melhoramento é alçando através da análise dos resultados. Otimizar um processo envolve a condução de idéias e tecnologias inovadoras e tornar processos não efetivos em produtores de resultados alcançando seus objetivos. A primeira distinção entre o nível otimizado e o previsível é a definição e padronização de processos agora dinamicamente modificados e adaptados para encontrar os objetivos atuais e futuros do negócio. O item da ISO/IEC TR tem como título Engineering process category (ENG), que podemos traduzir como 128 PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN

5 Categoria de processo de software (ENG). De acordo com esse documento, a categoria de processo de software consistem em processos que especificam diretamente, implementa ou mantém o produto de software, sua relação com o sistema e documentação do cliente. Em circunstâncias onde o sistema é composto totalmente de software, a engenharia de processos conforma somente com a construção e manutenção de tal software. Os processos e suas respectivas descrições retirados do item da ISO/IEC TR que pertencem a categoria de engenharia de software são: - ENG.1 Processo de desenvolvimento - ENG.1.1 Análise de requerimentos de sistema e desenho de processo - ENG.1.2 Processo de análise de requerimentos de software - ENG.1.3 Processo de projeto de software - ENG.1.4 Processo de construção de software - ENG.1.5 Processo de integração de software - ENG.1.6 Processo de teste de software - ENG.1.7 Processo de Integração de sistema e testes - ENG.2 Processo de manutenção de sistema e software A seguir, será analisado brevemente,cada um destes processos. ENG.1 PROCESSO DE DESENVOLVIMENTO (PROCESSO BÁSICO) O propósito do processo de desenvolvimento é transformar um conjunto de requerimentos em um produto de software funcional ou sistema baseado em software que vai de encontro às necessidades dos clientes como resultado da implementação de sucesso de um processo. Um produto intermediário de trabalho será desenvolvido, e ao final do processo deve ficar comprovado de que os requisitos foram atendidos. Para isso, uma consistência será estabelecida entre os requisitos e o projeto, o que evidenciará que o produto final atendeu os requisitos. O produto final será instalado no ambiente operacional do cliente e aceito por ele. ENG 1.1 Análise de requerimento de sistemas e desenho de processo são componentes do processo ENG 1 (Processo de desenvolvimento), seu propósito é estabelecer os requerimentos funcionais e não funcionais do sistema e sua arquitetura identificando quais requerimentos precisam ser alocados para quais elementos do sistema e quais versões. Como resultado de uma implementação de sucesso, a solução será proposta para atender as necessidades dos clientes e irá identificar os principais elementos do sistema. A estratégia de lançamento de versão será desenvolvida para atender a prioridade de implementação nos requisitos do sistema que serão aprovados e atualizados quando necessário. A solução proposta e seus relacionamentos serão comunicados a todas as partes afetadas. ENG 1.2 PROCESSO DE ANÁLISE DE REQUERIMENTOS DE SOFTWARE É um componente do processo ENG 1, seu propósito é estabelecer os requisitos dos componentes de um sistema. Como resultado de uma implementação de sucesso, os requisitos alocados para os componentes do sistema e suas interfaces serão definidos de forma a atender as necessidades dos clientes, eles serão analisados e corrigidos, os que forem passíveis de testes serão desenvolvidos. O impacto dos requisitos de software no ambiente operacional serão estudados. Uma estratégia de lançamento de versões será desenvolvida observando-se uma prioridade de implementação dos requisitos de software que serão atualizados se necessário. Será estabelecida uma coerência entre os requisitos de sistema e o desenho dos requisitos de software que serão comunicados às partes afetadas. ENG 1.3 PROCESSO DE DESENHO DE SOFTWARE Componente do processo ENG 1, seu propósito é definir um desenho de software que implementa os requisitos e possa ser testado. Como resultado de implementação de sucesso, um desenho da arquitetura será desenvolvido, ele descreve a maior parte dos componentes de software que serão implementados. Uma interface interna e externa de cada componente de software será definida, e um desenho detalhado que descreve as unidades que podem ser construídas e testadas do software será criado. Será estabelecida uma coerência entre os requisitos e os projetos de software. ENG 1.4 PROCESSO DE CONSTRUÇÃO DE SOFTWARE Componente do processo ENG 1, seu propósito é produzir as unidade de software executável e verificar se elas refletem corretamente o projeto do software. Como resultado de uma implementação de sucesso, um critério de verificação será definido para todas unidades confrontando com seus requisitos. Uma coerência será estabelecida entre o projeto de software e os componentes produzidos. Será realizado o confrontamento das unidades de software serão com seus projetos. ENG 1.5 PROCESSO DE INTEGRAÇÃO DE SOFTWARE É parte do processo ENG 1, seu objetivo é combinar as unidade de software, produzindo integração dos itens de software e verificar se as unidades de software integradas refletem corretamente o projeto de software. Uma integração de sucesso pro- PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN l 129

6 duz uma estratégia de integração que será desenvolvida para as unidades de software de forma coerente com o plano de versões. Critérios de verificação dos itens de software que assegura a observância dos requisitos de software serão desenvolvidos e o resultado dos testes de integração serão armazenados. Uma coerência deve estar estabelecida entre os requisitos e os itens de software. Uma estratégia de regressão será desenvolvida para reverificação dos itens de software que deverão ser modificados. ENG 1.6 PROCESSO DE TESTE DE SOFTWARE Componente do processo ENG 1, tem o propósito de testar o software integrado produzindo um produto que irá satisfazer os requisitos de software. Uma implementação de sucesso deste processo gera um critério de aceitação para o software integrado que será desenvolvido de forma que se verifique a observância dos requisitos de software. Os resultados de testes serão armazenados e uma estratégia de regressão será desenvolvida para retestar, de acordo com as demandas, os itens de software que forem refeitos. ENG 1.7 PROCESSO DE INTEGRAÇÃO DE SOFTWARE E TESTES Componente do processo ENG 1, seu propósito é integrar os componentes de software com outros componentes, como operações manuais ou hardware, produzindo um sistema completo que vai satisfazer as expectativas dos clientes expressas em requisitos de sistema. Os recursos alocados para a integração de sistema inclui alguém familiar com o componente de software. Uma implementação de sucesso deste processo produz uma estratégia de integração que será desenvolvida para construir as unidades agregadas de acordo com a estratégia de liberação de versão. Será criado um critério de aceitação para cada agregação para verificar a conformidade com os requisitos de sistema (funcionais, não funcionais, operações e manutenção) alocados para as unidades e uma validação que completa o conjunto de componentes entregáveis. O resultado dos testes serão armazenados e uma estratégia de regressão será criada para retestar as agregações no sistema integrado para as mudanças em componentes que forem realizadas. Os testes de regressão serão realizados sempre que necessário. ENG 2 PROCESSO DE MANUTENÇÃO DE SISTEMA E SOFTWARE (PROCESSO BÁSICO) Seu propósito é administrar a modificação, migração e retirada de componentes do sistema (como software, hardware, operações manuais e rede se existir) em resposta a pedidos do cliente. A origem dos pedidos poderia ser a descoberta de um problema ou a necessidade de uma melhoria ou adaptação. O objetivo é modificar e/ou retirar sistemas e/ou software preservando a integridade das operações da organização. Uma implementação de sucesso deste processo resulta na criação de uma estratégia de administração da modificação, migração e retirada de componentes do sistema de acordo com o plano de versões. O impacto nas interfaces e operações nos sistemas existentes será definido. Especificações, design de documentos e estratégias de teste serão atualizados. Os componentes modificados do sistema serão desenvolvidos associados aos testes que demonstram que requisitos de sistema não foram comprometidos. Os sistemas e softwares do cliente serão atualizados no ambiente do cliente. E a pedido deste, softwares e sistemas serão retirados de uso de maneira controlada que minimize os distúrbios causados aos clientes. CONCLUSÃO A ISO/IEC veio contribuir para o melhoramento dos processos de desenvolvimento de software que sofria pela falta de padrões de controle que proporcionasse um produto final que atendesse com êxito as expectativas dos clientes. Como vimos, a ISO IEC não é a única metodologia disponível no mercado, cabe então a organização interessada em otimizar seus processos a escolha da norma que melhor atende as suas aspirações. É interessante notar a abrangência dos grupos de processos da ISO IEC que trazem opções que vão desde a engenharia de software propriamente dita e seus processos de gerenciamento até orientação ao cliente e gestão dos produtos instalados no cliente na forma de alterações e inclusões de programas e operações, passando pelo suporte ao cliente e gerenciamento de projetos de software e ciclo de vida de software. A possibilidade de a empresa adotar a uma parte específica da ISO IEC a torna bastante dinâmica. Por exemplo, a seção que trata da Engenharia de Software pode ser aplicada especificamente na padronização e otimização de seus processos correlatos. Uma outra vantagem é a integração dos grupos de processos, pois a engenharia de software integra-se ao suporte que está alinhado ao gerenciamento de processos organizacionais que visam o incremento do resultado dos clientes. Dessa forma, a ISO IEC é abrangente, e cabe a cada organização avaliar seu procedimentos internos e definir onde aplicá-la. REFERÊNCIAS BIBLIOGRÁFICAS RINCON, André Mesquita. Qualidade de Software. Disponível em: < Qualidade_de_Software.pdf>. Acessado em: 17 de ago às 19:30. CANCIAN, Maiara Heil. Uma proposta de guia de referencia para 130 PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN

7 provedores de software como um serviço. < br/~maiara/files/dissert_maiara.pdf>. Acessado em: 20 de ago às 15:00. FELIPE, Pabro Fernando. C.M.M.I. e Spice: Um estudo comparativo na abordagem da engenharia de requisitos. < br/~pmr/qualidade/monografia.pdf>. Acessado em: em: 20 de ago às 15:00. VASCONCELOS, Marcos Lins de; ROUILLER, Ana Cristina; MACHADO, Cristina Angela Filipak; MEDEIROS, Tereza Maria Maciel. Introdução à engenharia de software e à qualidade de software. Disponível em: < ia&qualidadesoftware_v pdf>. Acessado em: 02 set às 21:40h. IAHN, Anísio. Avaliação de processos de software utilizando a norma ISO/IEC Disponível em: < tccs/1999-i/1999-1anisioiahnvf.pdf>. Acessado em: 02 set às 21:40h. REZENDE, Alcides Denis. Engenharia de Software e Sistemas de Informação. Disponível em: < BR&lr=&id=rtBvl_L-1mcC&oi=fnd&pg=PT23&dq=crise+do+softwar e&ots=9ybo_i0swm&sig=slwginajjdybiils0xar93s7qzm#v=onepa ge&q=crise%20do%20software&f=false>. Acessado em: 14 set às 20:30h. ISO/IEC. Information tecnology Software process assessment Part 2: A reference model for processes and processes capabality. Disponível em: < >. Acessado em: 05 de out às 19:30h. NOTAS DE RODAPÉ 1 Graduando do curso de Sistemas de Informação do Centro Universitário Newton Paiva. 2 Professor do Centro Universitário Newton Paiva. PÓS EM REVISTA DO CENTRO UNIVERSITÁRIO NEWTON PAIVA 1/ EDIÇÃO 5 - ISSN l 131