PALAVRAS-CHAVE: Organização do Processo de Desenvolvimento de Software, Modelos de Maturidade, Qualidade do Software.
|
|
- Luiz Henrique Martins Braga
- 8 Há anos
- Visualizações:
Transcrição
1 ORGANIZAÇÃO: PRODUÇÃO ORGANIZAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE: ANÁLISE E APLICAÇÃO DE MODELOS DE MATURIDADE DO SEI 1 Álvaro Rocha (amrocha@ufp.pt) Universidade Fernando Pessoa Faculdade de Ciência e Tecnologia Praça 9 de Abril, Porto, Portugal RESUMO O desenvolvimento de software é, pela natureza inerentemente complexa do software, um processo crítico. São muitos os casos em que o software é disponibilizado para além do tempo previsto e com um custo superior ao orçamentado, bem como é muitas vezes baixa a qualidade do software resultante. Os modelos de maturidade para o processo de desenvolvimento software são instrumentos que podem ajudar a minorar estes problemas, pois baseiam-se em práticas de desenvolvimento de software provadas. Neste artigo apresentamos as características dos modelos de maturidade, analisamos os principais modelos de maturidade do Software Engineering Institute (SEI), apresentamos um estudo de casos da aplicação do Capability Maturity Model for Software (SW-CMM) no diagnóstico da maturidade, e tecemos algumas considerações em função dos resultados dos casos estudados. Assim, verificamos que o SW-CMM é muito exigente no cálculo da maturidade e que o modelo Personal Software Process (PSP) deve ser uma alternativa ou um complemento ao SW-CMM quando a organização do processo de software é pequena, imatura ou caótica. PALAVRAS-CHAVE: Organização do Processo de Desenvolvimento de Software, Modelos de Maturidade, Qualidade do Software. 1 SEI: Software Engineering Institute, centro de investigação da Carnegie Mellon University, nos Estados Unidos da América. 227
2 1. INTRODUÇÃO O desenvolvimento de software usável e fiável é um processo difícil de implementar para muitas organizações. Muitas vezes o software é entregue atrasado, excede os custos previstos e não implementa as funcionalidades requeridas ou tem outros problemas de qualidade [Vicente et al. 1996, Clark 2000]. A natureza inerentemente complexa do software amplifica os problemas e aumenta a importância e o tamanho dos projectos. Uma forma de contornar tais problemas é através de um esforço focado na melhoria da organização do processo de desenvolvimento de software. A melhoria do processo tem por objectivo melhorar a capacidade de organização para ir ao encontro das suas metas. Especificamente, as melhorias visam a predicabilidade, o controlo e a eficiência. Por melhoria da predicabilidade entende-se que as estimativas são mais próximas do esforço actual requerido. Por melhoria do controlo entende-se que a variância entre progressos de diferentes projectos para tarefas similares diminui. Por melhoria da eficiência entende-se que os recursos usados para uma dada função/tarefa diminuem. Iniciativas de processos de melhoria são geralmente tomadas com base em normas e modelos de maturidade. Neste artigo apresentamos as características dos modelos de maturidade, analisamos os principais mo delos de maturidade do Software Engineering Institute (SEI) para o processo de desenvolvimento de software, apresentamos um estudo de casos da aplicação do SW-CMM no diagnóstico da maturidade, e tecemos algumas considerações em função dos resultados dos casos estudados. 2. MODELOS DE MATURIDADE Os modelos de maturidade são referenciais que se baseiam na premissa de que as entidades (pessoas, organizações, áreas funcionais, processos, etc.) evoluem através de um processo de desenvolvimento, crescimento ou maturação ao longo tempo, em direcção à perfeição ou maturidade, atravessando um determinado número de estádios distintos. Os modelos de maturidade têm vindo a ser usados largamente em várias áreas para descrever uma grande variedade de fenómenos [Burn 1994, King e Teo 1997]. Estes modelos assumem que padrões predicáveis, conceptualizados em termos de estádios, existem no crescimento das entidades [Greiner 1972, Smith et al. 1985, Burn 1994]. Normalmente, os estádios de maturidade são [Lavoie e Culbert 1978, Rocha 2000, Klimbo 2001]: (1) sequenciais (e cumulativos) por natureza, (2) ocorrem como uma progressão hierárquica que não é facilmente reversível e (3) envolvem um largo leque de estruturas e actividades humanas e organizacionais. Vários modelos de maturidade têm sido propostos ao longo do tempo, quer para a evolução geral das organizações, quer para a evolução da Função Sistemas de Informação, quer especificamente para a evolução do Processo de Desenvolvimento de Software. Estes modelos diferem principalmente no número de estádios, variáveis de evolução e áreas de foco. Cada um destes modelos identifica certas características que tipificam o alvo em diferentes estádios de maturidade. Um trabalho pioneiro sobre o amadurecimento das organizações foi conduzido por Greiner (1972). Este focou-se na organização como um todo, desenvolvendo o entendimento da evolução das práticas de gestão com base na forma como uma organização amadurece. Greiner descreveu cinco estádios de maturidade pelos quais passa uma organização, e declarou que a idade, a dimensão e a taxa de crescimento da sua indústria são os factores de influência principais na determinação do estádio em que uma organização se encontra. Recentemente, Greiner (1998) adicionou um novo estádio ao seu modelo inicial de modo a torná-lo válido com o funcionamento em rede/parceria das organizações actuais. Nolan (1973) foi o primeiro investigador a introduzir um modelo de maturidade na área dos sistemas informação. A sua primeira proposta baseou-se no tipo de tecnologia usada e no valor do orçamento em sistemas de informação como uma indicação da maturidade da gestão da função sistemas de informação, usando uma curva em S, consistindo em quatro estádios. A última versão do modelo de Nolan [Mutsaers et al. 1997] consiste de nove estádios, usando três curvas de crescimento em S, em que cada uma das curvas corresponde a uma era de evolução da maturidade. O primeiro modelo de maturidade para o processo de desenvolvimento de software surgiu apenas em 1987 [Humphrey 1987a,b]. O modelo consistiu numa resposta a uma solicitação do Departamento de Defesa dos Estados Unidos, que delegou no SEI a tarefa de formalizar e obter um mecanismo expedito para seleccionar fornecedores no âmbito do desenvolvimento de software. Pretendia-se que fossem seleccionados apenas fornecedores que apresentassem uma maturidade superior de desenvolvimento de software. 228
3 Este modelo é o bem conhecido SW-CMM (Capability Maturity Model for Softawre). A principal assunção do SW-CMM é que a qualidade pode ser cultivada e proporcionada através de controlo. Neste caso, a entidade a ser controlada é o processo de desenvolvimento de software. O modelo SW-CMM tem cinco estádios de maturidade. O SW-CMM descreve os elementos chave para um efectivo processo de desenvolvimento de software. Os seus estádios de maturidade indicam a capacidade do processo. Cada estádio (exceptuando o primeiro) contém áreas chave. As áreas chave representam objectivos a serem alcançados pela organização de desenvolvimento de software e estão organizadas por características comuns, as quais por sua vez são baseadas em práticas chave. O modelo completo indica o caminho de melhoria do processo de desenvolvimento de software. As vantagens óbvias dos modelos de maturidade para a organização do processo de desenvolvimento de software são: a sua simplicidade, o que faz com que sejam fáceis de entender e comunicar; proporcionarem o diagnóstico e o ranking da maturidade do processo; proporcionarem a identificação dos pontos fortes e fracos do processo, sendo estes posteriormente usados como entradas em processos de planeamento da melhoria orientados pela evolução provada e sequencial proposta nos modelos de maturidade; e proporcionarem comparações entre diferentes organizações/processos de desenvolvimento de software. A abordagem original consistia de modelos de maturidade em estádios. Posteriormente foi também introduzido o conceito de modelos de maturidade contínuos. Num modelo contínuo é usado o conceito de maturidade de área do processo em vez de apenas maturidade do processo de software. Assim, a maturidade é interpretada no contexto de áreas do processo. Ou seja, uma organização de desenvolvimento de software pode desenvolver-se simultânea e distintamente em diferentes áreas do processo. 3. MODELOS DE MATURIDADE DO SOFTWARE ENGINEERING INSTITUTE (SEI) O Software Engineering Institute foi a entidade responsável pela introdução dos modelos de maturidade na área da organização do processo de desenvolvimento de software. O seu primeiro modelo é o SW-CMM [Humphrey 1987a,b]. Como o SW-CMM não cobria tópicos relacionados com a gestão das pessoas que desenvolvem software, o SEI introduziu o P-CMM (People Capability Maturity Model) [Curtis e tal. 1995] com o objectivo de o complementar. Aplicações do SW-CMM mostraram alguma dificuldade quando o modelo era seguido na íntegra por pequenas organizações e em pequenos projectos de software, e mostraram também que muitas outras organizações se encontravam no primeiro estádio de maturidade. Por esse motivo, Humphrey (1995) introduziu o PSP (Personal Software Process), pois os engenheiros de software que se encontram num alto estádio de disciplina, quando reunidos num mesmo processo, farão com que a organização esteja pelo menos no segundo estádio de maturidade do SW-CMM. Como o SW-CMM [Paulk et al. 1993] também não cobria as primeiras fases do desenvolvimento de sistemas (determinação e especificação de requisitos, etc.) levou a que o SEI introduzisse o SE-CMM (Systems Engineering Capability Maturity Model) [Bate et al. 1995]. É, pela primeira vez, e com este modelo, adoptada pelo SEI a abordagem contínua, baseado na estrutura e na norma emergente ISO 15504/SPICE [SPICE 1996], em vez da até então abordagem em estádios. Recentemente, o SEI introduziu o CMMI (Capability Maturity Model Integration) com o objectivo de integrar os seus principais modelos de desenvolvimento de sistemas e evitar, entre outras coisas, duplicações e ambiguidades entre modelos. Por enquanto vão coexistindo duas abordagens deste modelo [CMMI 2002a,b]: abordagem contínua e abordagem em estádios. Nas próximas secções apresentam-se e analisam-se resumidamente os modelos SW-CMM, PSP e CMMI. Os dois primeiros porque têm sido até ao momento grandes referências no processo de desenvolvimento de software. E o último pelo facto do SEI querer torná-lo, no futuro, o seu único modelo SW-CMM: Capability Maturity Model for Software O SW-CMM [Humphrey 1987a,b, 1989, Paulk et al. 1993a] foi o primeiro modelo desenvolvido na área da maturidade da organização do processo de desenvolvimento de software. A iniciativa pertenceu ao Departamento de Defesa dos Estados Unidos, que delegou no SEI a tarefa de formalizar e obter um mecanismo expedito para seleccionar fornecedores de software. O esforço SW-CMM foi baseado nos princípios da TQM 2 e na melhoria contínua do processo de desenvolvimento de software. Desde que foi apresentado por Humphrey (1987a,b), tem recebido grande atenção das comunidades académica e profissional [e.g., Hather et al. 1996, Mathiassen e Sorensen 1996, Vicente et al. 1996, Soares 1997, Pressman 1997, Martinig 1998, Rocha 2000]. 2 A TQM (Total Quality Management) é a forma de uma organização atingir a excelência através de melhorias graduais e contínuas dos seus processos. A procura de melhorias graduais e contínuas, quer pela resolução de problemas quer pela prospecção de oportunidades, deve ser assim uma atitude assumida pelas organizações a tempo inteiro [Zultner 1993]. 229
4 O SW-CMM v1.1 [Paulk et al. 1993a] descreve os princípios e as práticas subjacentes à maturidade do processo de desenvolvimento software e pretende ajudar as organizações a melhorar esse processo através de um caminho evolutivo que vai desde um processo "ad hoc" e caótico até um processo de software maduro e disciplinado. O modelo caracteriza o processo de software num de cinco estádios de maturidade, em que um estádio mais elevado indica uma maior maturidade do processo, que por sua vez é associado a um menor risco e a uma maior produtividade e qualidade (tabela 1): Tabela 1: O modelo SW-CMM 1.1 [adaptado de Paulk (1993a)]. Estádio Foco Áreas Chave do Processo Resultado 5 Optimizado (Realimentado) processo a ser constantemente melhorado 4 Gerido (Quantitativo) processo e produto medido 3 Definido (Qualitativo) processo definido e institucionalizado 2 Repetí vel (Intuitivo) 1 Inicial (Ad hoc) processo dependente de indivíduos processo caótico Prevenção de defeitos Gestão de alterações tecnológicas Gestão de alterações do processo Gestão quantitativa do processo Gestão da qualidade do software Organização do processo Definição do processo Formação Gestão integrada de software Engenharia de software Coordenação inter-grupos Revisões (testes) Gestão de requisitos Planeamento de projectos Acompanhamento e inspecção do projecto Gestão da subcontratação Gestão de configurações Verificação da qualidade de software Produtividade e Qualidade Risco Predição, eficiência e controlo do processo de desenvolvimento de software são os elementos chave para uma organização se mover ao longo dos cinco estádios. Excepto para o Estádio 1, cada um dos outros estádios de maturidade é decomposto em várias áreas chave. Essas áreas chave são consideradas as áreas críticas onde uma organização se deve focar para melhorar o seu processo de software. Cada área chave do processo é descrita em termos das práticas chave que contribuem para a satisfação dos seus objectivos, como ilustra a figura 1. As práticas chave descrevem a infra-estrutura e as actividades específicas que mais contribuem para a efectiva implementação e institucionalização da área chave do processo. Cada prática chave é normalmente descrita por numa única frase geralmente seguida por uma descrição mais detalhada que pode incluir exemplos. Estas práticas chave, também referidas como práticas chave de alto nível, sustentam as políticas, procedimentos e actividades, fundamentais para a área chave do processo. As componentes da descrição detalhada que as caracteriza são referidas frequentemente como sub-práticas. As práticas chave descrevem o "que" deve ser feito, mas não devem ser interpretadas como mandamento de "como" os objectivos devem ser atingidos. Práticas alternativas podem acompanhar os objectivos das áreas chave. Portanto, as práticas chave devem ser interpretadas racionalmente [Paulk et al. 1993a], ou seja, de acordo com cada caso específico. As áreas chave estão organizadas por características (configurações comuns). As configurações comuns são atributos que indicam quer a implementação quer a institucionalização da respectiva área chave do processo de modo efectivo, repetível e permanente. As áreas chave do processo foram definidas por estádios de maturidade, como ilustrado na tabela 1. O caminho para se atingirem os objectivos de uma área chave do processo pode divergir de projecto para projecto em consequência das diferenças dos diversos domínios de aplicação. No entanto, todos os objectivos constantes da área chave do processo têm de ser atingidos pela organização para satisfazer essa área chave do processo. Quando esses objectivos são atingidos numa base contínua, ao longo dos projectos, a organização pode considerar-se como tendo institucionalizado a capacidade do processo caracterizada pela área chave do processo. 230
5 Capacidade do Processo Objectivos Implementação / Institucionalização Actividades / Infraestrutura Figura 1: Estrutura do modelo SW-CMM [adaptado de Paulk (1993a)]. Nem todas as áreas do processo de desenvolvimento e manutenção de software são descritas no SW-CMM. A palavra "chave" pressupõe que existem áreas que não foram identificadas como aspectos críticos para o processo. Embora outras áreas afectem o desempenho do processo, as áreas chave do processo foram identificadas devido à sua efectividade no aperfeiçoamento dos processos das organizações. Devem ser vistas como os requisitos para atingir o estádio optimizado de maturidade. Do mesmo modo que todos os objectivos de uma área chave do processo têm de ser atingidos para a área chave do processo ser considerada satisfeita, o estádio de maturidade também somente é atingido quando se satisfazem todas as áreas chave do processo que o caracterizam. As avaliações subjacentes ao SW-CMM consistem na aplicação de um questionário de resposta booleana. Para que uma organização esteja num específico estádio de maturidade, todas as suas áreas chave, mais as dos estádios precedentes, têm de estar implementadas e institucionalizadas na organização PSP Personal Software Process O PSP é um modelo de melhoria evolutiva desenvolvido por Humphrey (1995) para o nível individual, de modo a fornecer um mecanismo de auto-aprendizagem através da experiência, medida e feedback. Este mecanismo habilita os engenheiros de software a entenderem as suas fraquezas e potencialidades bem como a melhorar a sua capacidade e desempenho. O PSP pode ser aplicado à maioria das tarefas de engenharia de software dado que a sua estrutura é simples e independente da tecnologia - não prescreve linguagens, ferramentas ou métodos de concepção específicos [Humphrey 1996]. Os conceitos de processo do PSP são apresentados numa série de passos. Cada passo, como ilustrado na figura 2, inclui todos os elementos dos passos anteriores mais os adicionados. A introdução destes conceitos ajuda os engenheiros a aprenderem métodos de disciplina pessoal. Uma das razões que levou Humphrey a desenvolver o modelo PSP deve-se ao facto da aplicação dos princípios do modelo SW-CMM ter encontrado muitas dificuldades ao nível de pequenos grupos de engenheiros de software. O SW-CMM é um modelo de melhoria do processo focado na organização que potencia e facilita bom trabalho, mas não o garante. Portanto, os engenheiros têm de usar práticas pessoais efectivas [Humphrey 1996]. O modelo PSP apresenta princípios de melhoria do processo, ao nível dos engenheiros individuais, associados à produção eficiente de produtos de qualidade. Para terem um bom desempenho, os engenheiros necessitam do suporte de um ambiente disciplinado, o que significará que o PSP será mais efectivo em organizações próximas ou acima do estádio 2 do modelo SW-CMM. O PSP e o SW-CMM suportam-se mutuamente. O SW-CMM proporciona o suporte de ambiente ordenado que os engenheiros necessitam para realizarem trabalho superior; e o PSP equipa os engenheiros de forma a realizarem trabalho de alta qualidade e participa na melhoria organizacional do processo. Por conseguinte, um 231
6 dos objectivos do PSP é expandir a grandes programas a produtividade dos engenheiros tipicamente experientes no desenvolvimento de pequenos programas. Uma das razões que levou Humphrey a desenvolver o modelo PSP deve-se ao facto da aplicação dos princípios do modelo SW-CMM ter encontrado muitas dificuldades ao nível de pequenos grupos de engenheiros de software. O SW-CMM é um modelo de melhoria do processo focado na organização que potencia e facilita bom trabalho, mas não o garante. Portanto, os engenheiros têm de usar práticas pessoais efectivas [Humphrey 1996]. O modelo PSP apresenta princípios de melhoria do processo, ao nível dos engenheiros individuais, associados à produção eficiente de produtos de qualidade. Para terem um bom desempenho, os engenheiros necessitam do suporte de um ambiente disciplinado, o que significará que o PSP será mais efectivo em organizações próximas ou acima do estádio 2 do modelo SW-CMM. O PSP e o SW-CMM suportam-se mutuamente. O SW-CMM proporciona o suporte de ambiente ordenado que os engenheiros necessitam para realizarem trabalho superior; e o PSP equipa os engenheiros de forma a realizarem trabalho de alta qualidade e participa na melhoria organizacional do processo. Por conseguinte, um dos objectivos do PSP é expandir a grandes programas a produtividade dos engenheiros tipicamente experientes no desenvolvimento de pequenos programas. Processo Cíclico PSP3 Desenvolvimento cíclico Qualidade Pessoal PSP2 Revisões de código Revisões de concepção PSP2.1 Concepção de templates Planeamento Pessoal PSP1 Estimação do tamanho Relatório de teste PSP1.1 Planeamento de tarefas Planeamento de calendarização Medida Pessoal PSP0 Processo corrente Medidas básicas PSP0.1 Codificação standard Medida de tamanho Proposta de melhoria do processo Figura 2: Evolução do processo PSP [adaptado de Humphrey (1995, 1996, 2000)]. 3.3 CMMI Capability Maturity Model Integration O modelo CMMI é um projecto iniciado em 1998 pelo SEI com o objectivo de integrar num só modelo vários dos seus modelos. Actualmente o CMMI integra os modelos (1) SW-CMM v2.0 draft C; (2) SE-CMM v1.1; e (3) IPD-CMM v0.98 draft Integrated Product Development Capability Maturity Model. Os objectivos específicos do CMMI são: substituir todos os modelos CMM por um único modelo em finais de 2003, eliminando inconsistências e reduzindo duplicações; aumentar a clareza e o entendimento pelo uso de terminologia comum, estilo consistente e componentes comuns; e assegurar conformidade com a norma emergente 15504/SPICE da ISO. O CMMI proporciona uma eficiente e efectiva avaliação e melhoria de múltiplos processos de diferentes disciplinas numa organização; a redução de custos de formação e avaliação; uma visão comum e integrada de melhoria para todos os elementos de uma organização; e um novo meio de representar informação de disciplinas específicas numa norma, por intermédio de processos de melhoria provados. A primeira versão final do CMMI v1.0 surgiu em A mais recente, CMMI v1.1, é do início de 2002 [CMMI 2002a,b]. Em cada uma das versões, o CMMI disponibiliza diferentes combinações dos modelos do SEI. O CMMI SE/SW é a combinação que mais interessa neste documento, por ser aquela que está mais relacionada e que cobre todo o processo de desenvolvimento de software. 232
7 As organizações podem optar entre duas abordagens do CMMI para melhoria do processo: (1) abordagem contínua; e (2) abordagem em estádios. No primeiro caso para uma representação contínua do processo semelhante à do modelo SE-CMM e à da norma emergente 15504/SPICE da ISO; e no segundo caso para uma representação em estádios do processo semelhante à do modelo SW-CMM. Na representação em estádios, as áreas do processo estão agrupadas entre os estádios 2-5, como o SW-CMM, num total de 5 estádios: (1) Inicial; (2) Gerido; (3) Definido; (4) Gerido Quantitativamente; e (5) Optimização. Cada área do processo contém a implementação de práticas (actividades) para atingir o objectivo da área do processo. Todas as práticas (configurações comuns) têm de ocorrer para que a área do processo atinja o objectivo. Na representação contínua, como mostra a figura 3, uma área do processo contém práticas específicas para atingir o propósito da área do processo. Algumas destas práticas podem residir em estádios de maturidade mais elevados (práticas avançadas). As práticas genéricas são agrupadas para definir estádios de maturidade e são adicionadas às práticas específicas de cada área do processo para atingir um estádio de maturidade para a área do processo. Neste caso, o número de estádios de maturidade é 6: (0) Incompleto; (1) Realizado; (2) Gerido; (3) Definido; (4) Gerido Quantitativamente; e (5) Optimização. Área do Processo 1 Área do Processo 2 Área do Processo 3 Objectivos Genéricos Objectivos Específicos Práticas Genéricas Estádios de Maturidade Práticas Específicas Figura 3. Arquitectura do CMMI abordagem contínua [adaptado de CMMI 2002a]. A representação contínua possui mais práticas específicas do que a representação em estádios, porque a primeira comporta dois tipos de práticas (básicas e avançadas) enquanto a segunda tem apenas um tipo de práticas específicas. Na representação contínua, as práticas genéricas existem para os estádios de 1 a 5, por sua vez, na representação em estádios só existem práticas genéricas nos estádios 2 e 3. Na tabela 2 apresentam-se alguns argumentos que podem ajudar a escolher entre a aplicação da abordagem em estádios ou a aplicação da abordagem contínua. Tabela 2. Abordagem em Estádios versus Abordagem Contínua. Abordagem em Estádios 1. Segue uma sequência de melhorias provada, iniciando com - práticas de gestão básicas; 2. Potencia comparações baseadas em estádios de maturidade; 3. Facilita a migração a partir do SW-CMM. Abordagem Contínua 1. Permite escolher a ordem da melhoria baseado nos objectivos do negócio e áreas de risco; 2. Potencia comparações baseadas em áreas do processo ou estádios de maturidade; 3. Potencia comparações com a ISO 15504/SPICE 4. APLICAÇÃO DO SW -CMM NA DETERMINAÇÃO DA MATURIDADE Os modelos de maturidade são instrumentos que orientam as organizações de software em direcção a uma maturidade superior, baseado em práticas já provadas. Para uma organização conhecer o estádio de maturidade em que se encontra, de modo a poder encetar um processo de melhoria, tem de o diagnosticar. Normalmente os modelos de maturidade disponibilizam um questionário para recolha de dados. Esses dados quando tratados segundo o algoritmo de cálculo subjacente ao modelo levam à determinação do estádio de maturidade. Aqui retratamos uma experiência de aplicação do questionário de maturidade do SW-CMM [Zubrow et al. 1994] em cinco organizações portuguesas. Importa referir que a aplicação do questionário não apresentou dificuldades, 233
8 tendo-se pautado como um instrumento de levantamento de dados regido por um bom grau de clareza e objectividade. O levantamento foi realizado junto de cinco organizações pertencentes a áreas de negócio distintas, a saber: banca e seguros, governo, alimentação, comércio electrónico e ensino. O número total de colaboradores, bem como os que constituem a função SI, também é diversificado entre elas. A tabela 3 apresenta estruturada e resumidamente as organizações estudadas. Tabela 3: Organizações estudadas. Emp. Negócio Colaboradores Função SI Descrição A Banca e seguros Um dos principais grupos financeiros e seguradores do país B Governo Instituto de informática e finanças de um dos maiores ministérios do governo português C Alimentação Uma das maiores empresas de bebidas do país D Comércio electrónico Uma das primeiras e das maiores empresas de comércio electrónico do país E Ensino Universidade privada A tabela 4 sintetiza os resultados de maturidade conseguidos por área chave e estádios de maturidade do processo em cada uma das organizações. Tabela 4: Síntese dos resultados da maturidade do processo de software. Áreas Chave Emp. A Emp. B Emp. C Emp. D Emp. E Gestão de Requisitos 50% 66,7% 0% 33,3% 0% Planeamento de Projectos de Software 28,6% 57,1% 28,6% 14,3% 71,4% Vigilância Acompanhamento Projectos de Software 28,6% 71,4% 14,3% 0% 71,4% Gestão da Sub-contratação de Software 37,5% 37,5% 0% 0% 0% Verificação da Qualidade de Software 50% 37,5% 0% 0% 75% Gestão de Configurações 0% 62,5% 25% 0% 62,5% 32,4% 55,5% 11,3% 7,9% 46,7% Concentração no Processo Organizacional 57,1% 85,7% 0% 14,3% 42,9% Definição do Processo Organizacional 0% 83,3% 0% 16,7% 0% Programas de Treino 100% 42,9% 57,1% 0% 71,4% Gestão da Integração de Software 0% 66,7% 0% 0% 0% Engenharia do Produto de Software 50% 50% 0% 16,7% 0% Coordenação Inter-Grupos 0% 71,4% 0% 0% 0% Revisões por Pares 0% 16,7% 33,3% 0% 0% 29,6% 59,5% 12,9% 6,8% 16,3% Gestão Quantitativa do Processo 0% 28,6% 0% 0% 0% Gestão da Qualidade de Software 0% 71,4% 0% 0% 0% 0% 50% 0% 0% 0% Prevenção de Defeitos 0% 71,4% 28,6% 14,3% 0% Gestão da Mudança da Tecnologia 42,9% 57,1% 14,3% 0% 28,6% Gestão da Mudança do Processo 14,3% 28,6% 0% 14,3% 0% 19% 52,4% 14,3% 9,5% 9,5% Sendo rigoroso na aplicação dos critérios de cálculo subjacentes ao modelo SW-CMM, todas as organizações estudadas seriam caracterizadas como residindo no primeiro estádio de maturidade (Inicial), pois qualquer área chave do processo tem que obter 100% para que todos os seus objectivos estejam atingidos. O resultado não é de estranhar, uma vez que diversos autores [e.g., Vicente et al. 1996, Soares 1997] referem o elevado grau de exigência deste modelo. Não acreditando que não haja diferenças de maturidade entre as organizações, resolvemos aplicar uma tolerância ao critério de cálculo do SW-CMM. A tabela 5 apresenta os estádios de maturidade em que se encontraria cada organização em função de valores de tolerância diferentes. 234
9 Tabela 5: Estádios de maturidade, por organização, para valores de tolerância diferentes. Tolerância Emp. A Emp. B Emp. C Emp. D Emp. E 0% % % % As organizações que apresentam melhores resultados são a A e a B. Poder-se-á concluir que, apesar de todas as organizações serem pouco maduras face aos critérios de cálculo sugeridos pelo SW-CMM, as empresas A e B são, apesar de tudo, as mais avançadas. Os estádios de maturidade obtidos seguindo rigorosamente o algoritmo do SW-CMM levam-nos a sugerir que, antes das organizações se preocuparem com a maturidade colectiva da organização do processo de software se devem preocupar com a maturidade/disciplina individual dos seus engenheiros de software (modelo PSP: [Humphrey 1995, 2000]). Quando isso acontecer, pelo menos as organizações encontrar-se-ão no segundo estádio de maturidade do SW- CMM. A partir daí, é então necessário desenvolver práticas colectivas que conduzam as organizações a estádios de maturidade superiores. Cremos também que, para além do PSP, a abordagem contínua do CMMI pode ser uma outra alternativa à grande exigência do SW-CMM, pois a maturidade é aferida no contexto de áreas do processo em vez de ser apenas no contexto da organização do processo. 5. CONCLUSÕES No presente artigo apresentamos as características dos modelos de maturidade, analisamos os principais modelos de maturidade do Software Engineering Institute, apresentamos um estudo de casos da aplicação do Capability Maturity Model for Software no diagnóstico da maturidade, e tecemos algumas considerações em função dos resultados dos casos estudados. Face aos resultados de maturidade conseguidos com a aplicação do instrumento de diagnóstico do SW-CMM em cinco organizações portuguesas, verificamos que todas se encontravam no primeiro estádio de maturidade. Isto leva-nos a concluir que o modelo SW-CMM tem um elevado grau de exigência e que não facilita a distinção de maturidade entre organizações. Nós não acreditamos que não hajam diferenças de maturidade entre as organizações estudadas. Com base nestas conclusões julgamos que o modelo PSP deve ser uma alternativa ou um complemento ao modelo SW-CMM quando a organização do processo de software é pequena, imatura ou caótica. Julgamos também que a abordagem contínua do modelo CMMI poderá proporcionar mais facilmente distinções de maturidade entre organizações. Finalizamos, dizendo que esperamos que trabalhos futuros possam vir a reforçar as conclusões aqui derivadas. 6. REFERÊNCIAS Bate, R., Kuhn, D. Wells, C., et al. (1995), A Systems Engineering Capability Maturity Model, V1.1, Software Engineering Institute, CMU/SEI-95-MM-003, November Burn, J. (1994), A revolutionary staged growth model of information systems planning, Proceedings of the Fifteenth International Conference on Information Systems, Vancouver, British Columbia, Canada, pp Clark, B. (2000), Quantifying the Effects of Process Improvement on Effort, IEEE Software, Novembro/Dezembro, pp CMMI (2002a), Capability Maturity Model Integration, Version 1.1, Continuous Representation, Software Engineering Institute, CMU/SEI TR-001/ESC-TR CMMI (2002b), Capability Maturity Model Integration, Version 1.1, Staged Representation, Software Engineering Institute, CMU/SEI TR-002/ESC-TR Curtis, B., Hefley, W. e Miller, S. (1995), People Capability Maturity Model, Software Engineering Institute, CMU/SEI-95-MM-02, September Greiner, L. (1972), Evolution and Revolution as Organizations Grow, Harvard Business Review, nº 6, pp Greiner, L. (1998), Revolution is still inevitable, Harvard Business Review, nº 3, pp Hather, R., Burd, E. e Boldyreff, C. (1996), A method for application management maturity assessment, Information and Software Technology, Vol. 38, nº 11, pp
10 Humphrey, W. (1987a), Characterizing the Software Process: A Maturity Framework, Software Engineering Institute, CMU/SEI-87-TR-11, June Humphrey, W. (1987b), A Method for Assessing the Software Engineering Capability of Contractors, Software Engineering Institute, CMU/SEI-87-TR-23, September Humphrey, W. (1989), Managing de Software Process, Addison Wesley. Humphrey, W. (1995), A Discipline for Software Engineering, Addison Wesley. Humphrey, W. (1996), Using a Defined and Measured Personal Software Process, IEEE Software, V. 13, nº 3, pp Humphrey, W. (2000), The Personal Software Process (PSP), CMU/SEI-2000-TR-022. King, W. e Teo, T. (1997), Integration between Business Planning and Information Systems Planning: Validating a Stage Hypothesis, Decision Sciences, Vol. 28, nº 2, pp Klimbo, G. (2001), Knowledge Management and Maturity Models: Building Common Understanding, Proceedings of the 2 nd European Conference on Knowledge Management, 8-9/11/2001, Bled, Slovenia. Martinig, F. (1998), Usage of quality models, Methods & Tools, Vol. 6, nº 8, pp Mathiassen, L. e Sorensen, C. (1996), The capability maturity model and CASE, Information Systems Journal, Vol. 6, nº 3, pp Mutsaers, E., Zee, H. e Giertz, H. (1997), The Evolution of Information Technology, BIK-Blad (Nolan Norton & Co., Utrecht), Vol. 2, nº 2, pp Nolan, R. (1973), "Managing de computer resource: a stage hypotesis", Communications of de ACM, Vol. 16, nº 7, pp Paulk, M., Curtis, B., Chrissis, M. e Weber, C. (1993a), Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, Carnegie Mellon University, CMU/SEI-93-TR-024. Pressman, R. (1997), Software Engineering: a practitioner s approach, 4ª ed., McGrawHill. Rocha, A. (2000), Influência da Maturidade da Função Sistema de Informação na Abordagem à Engenharia de Requisitos, Tese de Doutoramento, Universidade do Minho. Soares, N. (1997), Avaliação da Maturidade do Processo de Software, Dissertação de Mestrado, Universidade do Minho. SPICE V1.00 (1996), ISO/IEC Software Process Assessment. ISO. Vicente, B., António, C. e Barreira, J. (1996), Qualidade no Software, Projecto Aquis, Instituto Português da Qualidade. Zubrow, D. et al. (1994), Maturity Questionnaire, Special Report, CMU/SEI-94-SR-07, Software Engineering Institute. Zultner, R. (1993), TQM for Technical Teams, Communications of the ACM, Vol. 36, n. 10, pp
Qualidade de Software
Início Qualidade de Software Álvaro Rocha amrocha@ufp.pt http://www.ufp.pt/~amrocha Início>Tópicos Tópicos 1. Fundamentos 2. Qualidade e Maturidade do Processo de SW ISO 9000, ISO 12207, SW-CMM, TRILLIUM;
Leia maisQUALIDADE DE SOFTWARE AULA N.7
QUALIDADE DE SOFTWARE AULA N.7 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 CMM: DEFINIÇÃO Capability Maturity Model Um modelo que descreve como as práticas
Leia maisMODELO CMM MATURIDADE DE SOFTWARE
MODELO CMM MATURIDADE DE SOFTWARE O modelo CMM Capability Maturity Model foi produzido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo
Leia maisCMM - Capability Maturity Model
Tema da Aula Normas e Padrões de Qualidade em II CMM Prof. Cristiano R R Portella portella@widesoft.com.br CMM - Capability Maturity Model Desenvolvido pelo SEI (Instituto de Engenharia de ) Carnegie Mellon
Leia maisCAPABILITY MATURITY MODEL INTEGRATION. Prof. Késsia R. C. Marchi
CAPABILITY MATURITY MODEL INTEGRATION Prof. Késsia R. C. Marchi Modelos de maturidade Um modelo de maturidade é um conjunto estruturado de elementos que descrevem características de processos efetivos.
Leia maisUnidade VI GOVERNANÇA DE TI. Profa. Gislaine Stachissini
Unidade VI GOVERNANÇA DE TI Profa. Gislaine Stachissini Capability Maturity Model Integration CMMI SW-CMM (Software Capability Maturity Model): prove informações para o aprimoramento de processos de desenvolvimento
Leia maisDepartamento de Produção POLI
Departamento de Produção POLI Marcelo Pessoa Mauro Spinola Sarah Kohan Fevereiro 2004 Multiplicidade de Modelos Por que usar um modelo? Modelos atuam como referência para a obtenção de níveis adequados
Leia maisAPOSTILAS: NORMAS; ABNT NBR ISO; MPS BR
APOSTILAS: NORMAS; ABNT NBR ISO; MPS BR Fonte: http://www.softex.br/mpsbr/_home/default.asp Apostilas disponíveis no site 1 NORMAS: NBR ISO NBR ISO/IEC CMM SPICE Continuação... 2 NORMAS VISÃO GERAL NBR
Leia maisObjetivos. Histórico. Out/11 2. Out/11 3
Objetivos Histórico Evolução da Qualidade Princípios de Deming CMMI Conceitos Vantagens Representações Detalhamento Gerenciamento Comparação Out/11 2 Histórico SW-CMM (Software Capability Maturity Model):
Leia maisISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário. As Normas da família ISO 9000. As Normas da família ISO 9000
ISO 9000:2000 Sistemas de Gestão da Qualidade Fundamentos e Vocabulário Gestão da Qualidade 2005 1 As Normas da família ISO 9000 ISO 9000 descreve os fundamentos de sistemas de gestão da qualidade e especifica
Leia maisPadrões de Qualidade de Software
Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade
Leia maisCMMI: Capability Maturity Model Integration
CMMI: Capability Maturity Model Integration Adriano J. Holanda http://holanda.xyz 21/10/2015 Adriano J. Holandahttp://holanda.xyz CMMI: Capability Maturity Model Integration CMMI: Capability Maturity Model
Leia maisMelhorias de Processos de Engenharia de Software
Melhorias de Processos de Engenharia de Software CMMI 1 Profa. Reane Franco Goulart O que é CMMI? O Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processos que fornece às
Leia maisOrganização. Trabalho realizado por: André Palma nº 31093. Daniel Jesus nº 28571. Fábio Bota nº 25874. Stephane Fernandes nº 28591
Organização Trabalho realizado por: André Palma nº 31093 Daniel Jesus nº 28571 Fábio Bota nº 25874 Stephane Fernandes nº 28591 Índice Introdução...3 Conceitos.6 Princípios de uma organização. 7 Posição
Leia maisALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)
ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por
Leia maisCMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos. Bacharel em Sistemas de Informação
CMMI (Capability Maturity Model Integration) Thiago Gimenez Cantos Bacharel em Sistemas de Informação Faculdade de Informática de Presidente Prudente Universidade do Oeste Paulista (UNOESTE) thiago@visioncom.com.br;
Leia maisPadrões de Qualidade de Software e Métricas de Software
Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de
Leia maisPEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI
PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMM E CMMI INTRODUÇÃO Aumento da Importância do Software Software está em tudo: Elemento crítico
Leia maisGestão do Risco e da Qualidade no Desenvolvimento de Software
Gestão do Risco e da Qualidade no Desenvolvimento de Software Questionário Taxinómico do Software Engineering Institute António Miguel 1. Constrangimentos do Projecto Os Constrangimentos ao Projecto referem-se
Leia maisAUDITORIAS DE VALOR FN-HOTELARIA, S.A.
AUDITORIAS DE VALOR FN-HOTELARIA, S.A. Empresa especializada na concepção, instalação e manutenção de equipamentos para a indústria hoteleira, restauração e similares. Primeira empresa do sector a nível
Leia maisCMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)
CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis
Leia maisMODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e
MODELO SPICE Software Improvement and Capacibilty Determination Avalia o software com foco na melhoria de seus processos (identifica pontos fracos e fortes, que serão utilizados para a criação de um plano
Leia maisDelfraro Rodrigues Douglas M Gandini José Luiz CMM. Capability Maturity Model
Delfraro Rodrigues Douglas M Gandini José Luiz CMM Capability Maturity Model O que é o CMM? Modelo para avaliação da maturidade dos processos de software de uma organização Identificação das práticas chave
Leia maisIntrodução a CMMI. Paulo Ricardo Motta Gomes Renato Miceli Costa Ribeiro
Introdução a CMMI Paulo Ricardo Motta Gomes Renato Miceli Costa Ribeiro Campina Grande, 29 de setembro de 2008 Agenda Processos Motivação Sintomas de falha de processo Aprimoramento de Processos O Framework
Leia maisGARANTIA DA QUALIDADE DE SOFTWARE
GARANTIA DA QUALIDADE DE SOFTWARE Fonte: http://www.testexpert.com.br/?q=node/669 1 GARANTIA DA QUALIDADE DE SOFTWARE Segundo a NBR ISO 9000:2005, qualidade é o grau no qual um conjunto de características
Leia maisO que é CMMI? Base do CMMI. Melhorando o processo é possível melhorar-mos o software. Gerais. Processo. Produto
Gerais Processo Produto Propostas NBR ISO 9000:2005 define principios e vocabulário NBR ISO 9001:2000 define exigências para sistema de gerência de qualidade NBR ISO 9004:2000 apresenta linha diretivas
Leia maisCMM Capability Maturity Model. Silvia Regina Vergilio
CMM Capability Maturity Model Silvia Regina Vergilio Histórico O DoD patrocinou a fundação do SEI (Software Engineering Institute) na Universidade de Carnegie Mellon (Pittsburg) com o objetivo de propor
Leia maisPolíticas de Qualidade em TI
Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte I Agenda Processos CMMI Definição Histórico Objetivos Características Representações
Leia maisORGANIZAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE: ANÁLISE E APLICAÇÃO DE MODELOS DE MATURIDADE DO SOFTWARE ENGINEERING INSTITUTE
ORGANIZAÇÃO DO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE: ANÁLISE E APLICAÇÃO DE MODELOS DE MATURIDADE DO SOFTWARE ENGINEERING INSTITUTE Álvaro Rocha (amrocha@ufp.pt) Universidade Fernando Pessoa Faculdade
Leia maisGerenciamento de Qualidade. Paulo C. Masiero Cap. 24 - SMVL
Gerenciamento de Qualidade Paulo C. Masiero Cap. 24 - SMVL Introdução Melhoria nos níveis gerais de qualidade de software nos anos recentes. Diferenças em relação ao gerenciamento da qualidade na manufatura
Leia maisÁlvaro Rocha Universidade Fernando Pessoa, Faculdade de Ciência e Tecnologia, Porto, Portugal
Reflexão sobre a Aplicação de Modelos do Software Engineering Institute no Diagnóstico e na Melhoria da Maturidade do Processo de Desenvolvimento de Software Álvaro Rocha Universidade Fernando Pessoa,
Leia maisIntrodução ao Modelo de Referência para melhoria do processo de software (MR mps) Projeto: mps Br melhoria de processo do software Brasileiro
Introdução ao Modelo de Referência para melhoria do processo de software (MR mps) Realidade das Empresas Brasileiras ISO/IEC 12207 ISO/IEC 15504 CMMI Softex Governo Universidades Modelo de Referência para
Leia maisModelo Cascata ou Clássico
Modelo Cascata ou Clássico INTRODUÇÃO O modelo clássico ou cascata, que também é conhecido por abordagem top-down, foi proposto por Royce em 1970. Até meados da década de 1980 foi o único modelo com aceitação
Leia maisEngenharia de Software
Universidade São Judas Tadeu Profª Dra. Ana Paula Gonçalves Serra Engenharia de O Processo Uma Visão Genérica Capítulo 2 (até item 2.2. inclusive) Engenharia de - Roger Pressman 6ª edição McGrawHill Capítulo
Leia maisProfa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br
Modelos de Processo Pessoal e de Equipe na Melhoria da Qualidade em Produção de Software Profa. Dra. Ana Paula Gonçalves Serra prof.anapaula@saojudas.br Agenda Importância das Pessoas / Constatações Compromisso
Leia maisQualidade de software
Qualidade de software É cada dia maior o número de empresas que buscam melhorias em seus processos de desenvolvimento de software. Além do aumento da produtividade e da diminuição do retrabalho, elas buscam
Leia maisSIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI
SIPTEST System Intelligent Process Testing. Estado da arte na prática de testes tendo como referência o CMMI SIPTEST - System Intelligent Testing Link Consulting,SA Pág. 0 de 10 Índice 1 Introdução...
Leia maisImplantação de um Processo de Medições de Software
Departamento de Informática BFPUG Brazilian Function Point Users Group Implantação de um Processo de Medições de Software Claudia Hazan, MSc., CFPS claudinhah@yahoo.com Agenda Introdução Processo de Medições
Leia maisCMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)
CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia
Leia maisC.M.M. Capability Maturity Model Modelo de Maturidade da Capacidade
UNISUL Universidade do Sul de Santa Catarina. Campus da Grande Florianópolis Pedra Branca. CIÊNCIA DA COMPUTAÇÃO ENGENHARIA DE SOFTWARE ALUNO: Volnei A. Caetano Palhoça 02 de Junho de 2000 C.M.M. Capability
Leia maisGestão dos Níveis de Serviço
A Gestão dos Níveis de Serviço (SLM) Os sistemas e tecnologias de informação e comunicação têm nas empresas um papel cada vez mais importante evoluindo, hoje em dia, para níveis mais elevados de funcionamento
Leia maiswww.asrconsultoria.com.br
www.asrconsultoria.com.br TMMi Test Maturity Model integration Erika Nina Höhn erikahohn@asrconsultoria.com.br Agenda Fundamentos Estrutura do TMMi TMMi x CMMi Proposta de avaliação e diagnóstico Custos
Leia mais21. Qualidade de Produto ou Qualidade de Processo de Software?
21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento
Leia maisComeço por apresentar uma breve definição para projecto e para gestão de projectos respectivamente.
The role of Project management in achieving Project success Ao longo da desta reflexão vou abordar os seguintes tema: Definir projectos, gestão de projectos e distingui-los. Os objectivos da gestão de
Leia maisObservações. Referência Título / Campo de Aplicação Emissor Data de adoção
NP 4239:1994 Bases para a quantificação dos custos da qualidade CT 80 1995-01-01 NP 4397:2008 Sistemas de gestão da segurança e saúde do trabalho. Requisitos CT 42 2008-12-31 NP 4410:2004 Sistemas de gestão
Leia maisGERÊNCIA DE INTEGRAÇÃO DO PROJETO
GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)
Leia maisSistemas de Gestão Ambiental O QUE MUDOU COM A NOVA ISO 14001:2004
QSP Informe Reservado Nº 41 Dezembro/2004 Sistemas de Gestão O QUE MUDOU COM A NOVA ISO 14001:2004 Material especialmente preparado para os Associados ao QSP. QSP Informe Reservado Nº 41 Dezembro/2004
Leia maisXI Mestrado em Gestão do Desporto
2 7 Recursos Humanos XI Mestrado em Gestão do Desporto Gestão das Organizações Desportivas Módulo de Gestão de Recursos Rui Claudino FEVEREIRO, 28 2 8 INDÍCE DOCUMENTO ORIENTADOR Âmbito Objectivos Organização
Leia maisProcesso de Software
Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais
Leia maisProcesso de Implementação de um Sistema de Gestão da Qualidade
3 Processo de Implementação de um Sistema de Gestão da Qualidade Não existe um jeito único de se implementar um sistema da qualidade ISO 9001: 2000. No entanto, independentemente da maneira escolhida,
Leia maisENGENHARIA DE SOFTWARE I
ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis
Leia maisModelos de Maturidade. Porque estudar um Modelo de Maturidade? Descrevem as características de processos efetivos;
Versão 1.1 - Última Revisão 16/08/2006 Porque estudar um Modelo de Maturidade? Segundo o Standish Group, entidade americana de consultoria empresarial, através de um estudo chamado "Chaos Report", para
Leia maisUniversidade Paulista
Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen
Leia maisQualidade de Software. Anderson Belgamo
Qualidade de Software Anderson Belgamo Qualidade de Software Software Processo Produto Processo de Software Pessoas com habilidades, treinamento e motivação Processo de Desenvolvimento Ferramentas e Equipamentos
Leia maisIndice. Parte I - Um Modelo de Gestão de Projectos. Introdução... 1
r Indice Introdução.......................................... 1 Parte I - Um Modelo de Gestão de Projectos 1- Características da Gestão de Projectos 11 1.1 Definição de Projecto 11 1.2 Projectos e Estratégia
Leia maisUniversidade Federal de Goiás Instituto de Informática Sistemas de Informação Código da Matriz Curricular: 109P1NB
Universidade Federal de Goiás Instituto de Informática Sistemas de Informação Código da Matriz Curricular: 109P1NB Plano de Disciplina Ano Letivo: 2013-1 º Semestre Dados da Disciplina Código Disc. Nome
Leia maisGovernança de TI. ITIL v.2&3. parte 1
Governança de TI ITIL v.2&3 parte 1 Prof. Luís Fernando Garcia LUIS@GARCIA.PRO.BR ITIL 1 1 ITIL Gerenciamento de Serviços 2 2 Gerenciamento de Serviços Gerenciamento de Serviços 3 3 Gerenciamento de Serviços
Leia maisQualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207
Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta
Leia maisPlano de implementação da ISO 9001:2008 PLANO DE IMPLEMENTAÇÃO DA ISO 9001:2008
PLANO DE IMPLEMENTAÇÃO DA ISO 9001:2008 A APCER vem por este documento transmitir as disposições tomadas para a emissão de certificados acreditados durante o período de implementação definido pela IAF,
Leia maisCHECK - LIST - ISO 9001:2000
REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da
Leia maisFatores humanos de qualidade CMM E CMMI
Fatores humanos de qualidade CMM E CMMI Eneida Rios¹ ¹http://www.ifbaiano.edu.br eneidarios@eafcatu.gov.br Campus Catu 1 Curso de Análise e Desenvolvimento de Sistemas Conteúdos Fatores humanos de qualidade
Leia maisIntrodução ao MPS.BR Guia Geral. Prof. Elias Batista Ferreira
Introdução ao MPS.BR Guia Geral Prof. Elias Batista Ferreira IMPORTANTE Este NÃO é um curso oficial do MPS.BR. Este curso NÃO é apoiado pela Softex. Objetivo deste Curso Descrever os processos e resultados
Leia maisDESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004)
DESENVOLVER E GERIR COMPETÊNCIAS EM CONTEXTO DE MUDANÇA (Publicado na Revista Hotéis de Portugal Julho/Agosto 2004) por Mónica Montenegro, Coordenadora da área de Recursos Humanos do MBA em Hotelaria e
Leia maisISO/IEC 12207: Gerência de Configuração
ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que
Leia maisObservações. Referência Título / Campo de Aplicação Emissor Data de adoção
NP 4239:1994 Bases para a quantificação dos custos da qualidade CT 80 1995-01-01 NP 4397:2008 Sistemas de gestão da segurança e saúde do trabalho. Requisitos CT 42 2008-12-31 NP 4410:2004 Sistemas de gestão
Leia maisAPLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2
APLICACAÇÃO DE METRICAS E INDICADORES NO MODELO DE REFERENCIA CMMI-Dev NIVEL 2 Renan J. Borges 1, Késsia R. C. Marchi 1 1 Universidade Paranaense (UNIPAR) Paranavaí, PR Brasil renanjborges@gmail.com, kessia@unipar.br
Leia maisGerência de Projetos de Software Modelos de gerência. CMM: Capability Maturity Model ITIL: Information Technology Infrastructure Library MPS BR
Modelos de gerência CMM: Capability Maturity Model ITIL: Information Technology Infrastructure Library MPS BR Modelo de maturidade: CMM CMM (Capability Maturity Model) é um modelo subdividido em 5 estágios
Leia maisNCRF 19 Contratos de construção
NCRF 19 Contratos de construção Esta Norma Contabilística e de Relato Financeiro tem por base a Norma Internacional de Contabilidade IAS 11 - Contratos de Construção, adoptada pelo texto original do Regulamento
Leia maisCriatividade e Inovação Organizacional: A liderança de equipas na resolução de problemas complexos
Criatividade e Inovação Organizacional: A liderança de equipas na resolução de problemas complexos Dizer que o grande segredo do sucesso das empresas, especialmente em tempos conturbados, é a sua adaptabilidade
Leia maisQualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br
Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI
Leia maisPROGRAMA DE ACÇÃO COMUNITÁRIO RELATIVO À VIGILÂNCIA DA SAÚDE. PROGRAMA DE TRABALHO PARA 2000 (Nº 2, alínea b), do artigo 5º da Decisão nº 1400/97/CE)
PROGRAMA DE ACÇÃO COMUNITÁRIO RELATIVO À VIGILÂNCIA DA SAÚDE VERSION FINALE PROGRAMA DE TRABALHO PARA 2000 (Nº 2, alínea b), do artigo 5º da Decisão nº 1400/97/CE) 1. INTRODUÇÃO As actividades da União
Leia maisSEQUÊNCIA: TIPOS DE SISTEMAS DE INFORMAÇÃO. PROF. MARTIUS V R Y RODRIGUEZ, DSc TECNOLOGIA DE INFORMAÇÃO
TIPOS DE SISTEMAS DE INFORMAÇÃO 1 Prof. Martius Vicente Rodriguez y Rodriguez, DSc - 1 TECNOLOGIA DE INFORMAÇÃO 1. TIPOS DE 2. ARQUITETURAS DE SISTEMAS - CRM 3. KNOWLEDGE DISCOVERY IN DATABASE 4. SISTEMAS
Leia maisCAPABILITY MATURITY MODEL FOR SOFTWARE. Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com
CAPABILITY MATURITY MODEL FOR SOFTWARE Eduardo Mayer Fagundes e-mail: eduardo@efagundes.com 1. Introdução Após décadas de incontáveis promessas sobre como aumentar à produtividade e qualidade de software,
Leia maisEstudo do CMM e do CMMI
Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos
Leia maisGerenciamento de Problemas
Gerenciamento de Problemas O processo de Gerenciamento de Problemas se concentra em encontrar os erros conhecidos da infra-estrutura de TI. Tudo que é realizado neste processo está voltado a: Encontrar
Leia maisMBA em Gestão de Empreendimentos Turísticos
Prof. Martius V. Rodriguez y Rodriguez, DSc martius@kmpress.com.br MBA em Gestão de Empreendimentos Turísticos Gestão do Conhecimento e Tecnologia da Informação Gestão do Conhecimento evolução conceitual.
Leia maisISO 9001:2008. A International Organization for Standardization (ISO) publicou em 2008-11- 14 a nova edição da Norma ISO 9000:
A International Organization for Standardization (ISO) publicou em 2008-11- 14 a nova edição da Norma ISO 9000: ISO 9001:2008 Esta nova edição decorre do compromisso da ISO em rever e actualizar as Normas,
Leia maisRequisitos de Software
Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o
Leia maisEngenharia de Software
Engenharia de Software Roteiro Qualidade de Software Produto de Software Processo de Software Modelo de Qualidade CMM Qualidade Qualidade de Software Na visão popular: Luxo Mais caro, complexo = maior
Leia maisFACULDADE SENAC GOIÂNIA
FACULDADE SENAC GOIÂNIA NORMA ISO 12.207 Curso: GTI Matéria: Auditoria e Qualidade de Software Professor: Elias Ferreira Acadêmico: Luan Bueno Almeida Goiânia, 2015 CERTIFICAÇÃO PARA O MERCADO BRASILEIRO
Leia maisPMONow! Serviço de Implantação de um Escritório de Projetos
PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos As organizações em torno do mundo estão implantando processos e disciplinas formais
Leia maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisSumário. Engenharia de Software. Gestão da Complexidade. Objectivos. Engenharia de Software
Engenharia de Software Engenharia de Software António Rito Silva Rito.Silva@inesc-id.pt Objectivos Problemas Qualidades Técnicas Conclusões Referências Sumário Engenharia de Software 2 Objectivos A engenharia
Leia maisGerenciamento de Projetos Modulo III Grupo de Processos
Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Processos de Gerenciamento de Projetos Para que um projeto seja bem-sucedido,
Leia maisB U S I N E S S I M P R O V E M E N T
BUSINESS IMPROVEMENT A I N D E V E QUEM É A Indeve é uma empresa especializada em Business Improvement, composta por consultores com uma vasta experiência e com um grande conhecimento do mundo empresarial
Leia maisTRANSIÇÃO DA ISO 9001:2000 PARA ISO 9001:2008 DOCUMENTO SUMÁRIO DE ALTERAÇÕES ALTERAÇÕES QUE PODEM AFECTAR O SISTEMA
TRANSIÇÃO DA ISO 9001:2000 PARA ISO 9001:2008 DOCUMENTO SUMÁRIO DE ALTERAÇÕES A nova norma ISO 9001, na versão de 2008, não incorpora novos requisitos, mas apenas alterações para esclarecer os requisitos
Leia mais. evolução do conceito. Inspecção 3. Controlo da qualidade 4. Controlo da Qualidade Aula 05. Gestão da qualidade:
Evolução do conceito 2 Controlo da Qualidade Aula 05 Gestão da :. evolução do conceito. gestão pela total (tqm). introdução às normas iso 9000. norma iso 9000:2000 gestão pela total garantia da controlo
Leia mais5. Métodos ágeis de desenvolvimento de software
Engenharia de Software 5. Métodos ágeis de desenvolvimento de software Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt Desenvolver e entregar software o mais rapidamente possível é hoje em dia um dos
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisGerenciamento de Projetos Modulo III Grupo de Processos
Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento
Leia maisQUALIDADE DE SOFTWARE
QUALIDADE DE SOFTWARE AULA N.3 Curso: SISTEMAS DE INFORMAÇÃO Disciplina: Qualidade de Software Profa. : Kátia Lopes Silva 1 QUALIDADE DE SOFTWARE Objetivos: Introduzir os três modelos para implementar
Leia mais