1 Introdução A Engenharia de Software é uma ciência bastante recente se comparada às outras áreas de engenharia como a Civil, Naval dentre outras [Sommerville,2007] e, portanto, muitas áreas não possuem padrões definidos com as melhores práticas, processos que sempre devem ser seguidos e regras que nunca podem ser deixadas de lado. Isso torna qualquer trabalho que envolva o desenvolvimento de software uma tarefa de definições de caminhos a serem seguidos e decisões a serem tomadas que muitas vezes nunca foram vistas antes. No desenvolvimento de software, o como chegar ao caminho perfeito é através da definição de processos, que estão sempre sendo analisados, revistos e aprimorados para aperfeiçoar esse desenvolvimento. Na Gerência de Requisitos, esse aperfeiçoamento constante não se faz diferente. Aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], e o esforço para gerenciá-los corretamente evita o re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários de software [Kotonya & Sommerville,1998]. O trabalho realiza um estudo sobre as melhores práticas adotadas hoje em dia no mercado, em relação à Gerência de Requisitos, e propõe um processo customizado para um ciclo de vida de desenvolvimento de software, de um setor de desenvolvimento de software, de uma média empresa. 1.1 Motivação Antes da gestão do Presidente em exercício as empresas do Sistema FIRJAN (Serviço Social da Indústria - SESI, Serviço Nacional de Aprendizagem Industrial - SENAI, Federação das Indústrias do Rio de Janeiro - FIRJAN, Centro Industrial do Rio de Janeiro - CIRJ e Instituto Euvaldo Lodi - IEL) atuavam de forma independente tanto em suas estruturas de apoio (Recursos Humanos, Contabilidade, Financeiro e etc) quanto na Tecnologia da Informação - TI. Elas possuíam apenas o mesmo presidente, ou Diretor Regional conforme fosse o caso. A Tecnologia da Informação era organizada através de um Centro de Processamento de Dados (CPD) terceirizado, por duas empresas, e de núcleos de informática que atendiam as demandas dos usuários em micro-informática e que eram compostos por funcionários da empresa. O CPD era o setor responsável pelo desenvolvimento, suporte e operação dos principais sistemas de apoio tais como o de Recursos Humanos, Contabilidade, Financeiro, Cadastro Industrial, Estatístico de Atendimento e etc. Os núcleos de informática tinham a responsabilidade de dar suporte operacional de micro-informática, dar manutenção nos computadores, organizar as necessidades de compra em informática e levantar, avaliar e priorizar junto ao CPD as necessidades de melhorias nos sistemas. Quando o atual Presidente assumiu foi iniciada uma corporativação, unificando todas as áreas das empresas de forma a atender as novas demandas do negócio, reduzir custos e aumentar a auto-sustentabilidade. A estratégia foi unificar em apenas uma (1) as áreas que fossem consideradas de apoio (Recursos Humanos, Contabilidade, Financeiro, Jurídico, Administração, Tecnologia da Informação, Compras, entre outras) com isso, reduzindo o quadro de pessoas e gerando uma padronização de atuação para as 5 empresas do grupo. Na área de TI, os núcleos que eram independentes passaram a ficar sob a coordenação do Gerente de Informática, que logo virou Gerente de Tecnologia da Informação, criando a Divisão de Atendimento aos Usuários. No CPD houve o movimento de contratação dos funcionários das empresas terceirizadas criando as estruturas internas de Desenvolvimento de Sistemas e Suporte/Operação. Com o crescimento da demanda de informatização as equipes de desenvolvimento de sistemas foram aumentando, mas de forma desordenada e sem estruturação de processos. Durante muitos anos foram se adaptando as equipes, com diversas configurações, mas pouco se fez em termos de estruturação de processos. Atualmente as equipes de desenvolvimento de sistemas são dividas por áreas de negócio (saúde, lazer, educação, financeiro, entre outras) e cada área possui um líder (especialista de negócio) e uma equipe que varia de 1 a 3 desenvolvedores sendo cada equipe responsável tanto pelo desenvolvimento de novos projetos em sua área quanto ao suporte, manutenção e treinamento dos sistemas de sua responsabilidade. Para aumentar a capacidade de desenvolvimento de novos projetos foi contratada uma fábrica de software para dar maior fôlego ao desenvolvimento dos projetos com a intenção de também permitir maior paralelismo de projetos (projetos concorrentes). Esta fábrica de software está geograficamente distante e com isso existe a necessidade de estruturar melhor o ambiente (Gerência de Configuração). Durante o processo de seleção de um fornecedor para apoiar na estruturação do ambiente houve uma mudança de foco para essa consultoria fazendo com que o projeto se tornasse avaliar o grau de aderência dos processos internos às atividades sugeridas pelo Capability Maturity Model Integration (CMMI) especificamente em desenvolvimento de sistemas versão 2 com foco de priorizar quais investimentos seriam tomados primeiro e em que áreas de processos (PA). Dessa forma a consultoria escolhida avaliou todos os pontos e como resultado indicou que a maior necessidade de investimentos seria na área de Gerência de Requisitos. Como já citado aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], segundo Blaschek em seu artigo [Blaschek, 2002] muitos erros poderiam ser evitados se as organizações tivessem um processo de engenharia de requisitos definido, controlado, medido e aprimorado e este propõe um conjunto de atividades para elicitar, documentar, analisar e validar requisitos, porém os modelos de qualidade, principalmente o MPS.BR [MPS.Br, 2007c] propõem a necessidade de existência um processo para gerenciamento dos requisitos de um projeto O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Sendo assim, a motivação do trabalho é poder contribuir com a melhoria organizacional dos processo de gerenciamento de requisitos da empresa. 1.2 Objetivo do Trabalho Como objetivo da organização não é obter qualquer tipo de certificação e sim melhorar os processos internos, trazendo mais qualidade para o produto entregue ao cliente e também formar uma metodologia consistente e adequada aos padrões de qualidade do mercado, principalmente devido a relações com fornecedores externos, e como se trata de uma organização sem fins lucrativos em que a política e a relação com o Governo estão fortemente presentes, foi escolhido como base para este trabalho o modelo de qualidade Melhoria do Processo de Software - MPS.Br para evolução da maturidade em gerenciamento de requisitos O MPS.Br é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Por ser uma iniciativa nacional possui menor custo e permite empresas de pequeno e médio porte, com menos possibilidade de investimento, melhorar a capacidade de seus processos evoluindo em mais níveis (G a A) [MPS.Br, 2007a] O propósito deste trabalho é demonstrar um método para que a empresa possa atingir um nível melhor de capacidade em gerenciamento de requisitos em seus projetos. 1.3 Organização do Trabalho Este trabalho encontra-se organizado da seguinte forma: a seção 2 apresenta a conceituação dos assuntos que serão abordados neste trabalho, que são: Requisitos e Gerência de Requisitos e dos Modelos de Qualidade, descrevendo CMMI e MPS.Br. A seção 3 tem como propósito customizar o modelo de avaliação de maturidade do MPS.Br para produzir uma avaliação interna a organização. A seção 4 traz processos e técnicas para Gerência de Requisitos, propondo atividades que permitam a organização atender as práticas sugeridas pelo modelo MPS.Br nível F, demonstrando a quais práticas do modelo a atividade está relacionada, indicando ferramentas e técnicas para que as mesmas sejam atendidas. A seção 5 apresenta o plano de implantação da Gerência de Requisitos, criando uma maneira de priorizar os itens não atendidos na avaliação e um plano para que a organização possa implementar as ferramentas e técnicas propostas na seção 4. Finalizando o trabalho, a seção 6 apresenta a conclusão e identifica possíveis trabalhos futuros. 2 Teorias de Fundamentação 2.1 Definição de Requisitos Levantar corretamente os requisitos é umas das tarefas mais importantes no desenvolvimento de um sistema, aos requisitos estão associados aos principais problemas do desenvolvimento de software como re-trabalho, atrasos no cronograma, problemas com custos e insatisfação do requerente. A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deve realizar, sua interface com os demais elementos e sob quais restrições o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema não deve fazer e o que ele deve fazer ao invés de como isto será feito. [Antunes Da Silva, Bonin & Paludo] Eles podem ser demandados por humanos, como usuários, clientes, órgãos reguladores ou desenvolvedores e também podem ser demandados por não humanos, como sistema de rede, sistema legado, bases de dados e ambientes. [Antunes Da Silva, Bonin & Paludo] Seu levantamento facilita o entendimento das necessidades do usuário e a identificação de inconsistências, garantindo melhor qualidade no processo de desenvolvimento do produto. Requisitos mal especificados produzem dor de cabeça, re-trabalho e atrasos no projeto. Requisitos são sentenças que devem descrever de modo claro, sem ambigüidades, conciso e consistente todos os aspectos significativos do sistema proposto. Devem conter informações suficientes para permitir que se construa um sistema que atenda os requerentes. Podem ser coletados em fontes humanas, ambiente onde o sistema funcionará, estudos de viabilidade, processo de coleta, técnicas de levantamento de dados, análise dos produtos competidores e etc. [Bourque & Dupuis, 2004] A seguir os principais tipos: 2.1.1 Requisitos de Negócio Correspondem aos objetivos de negócio ou do usuário que devem ser satisfeitos pelo sistema. Normalmente são descritos por um documento de visão ou escopo de sistema. 2.1.2 Requisitos de Uso Correspondem às atividades que os usuários vão poder fazer utilizando o sistema. Ex: Casos de uso. 2.1.3 Requisitos Funcionais Descrevem o que o sistema deve fazer, serviços ou funções que ele deve realizar. 2.1.4 Requisitos não Funcionais Restrições impostas tanto ao sistema quanto ao seu desenvolvimento. Descreve como deve ser feito. Para melhor organização dos requisitos, podemos separar em diferentes tipos, tais como: 2.1.4.1 Requisitos do Produto: Usabilidade; Confiabilidade; Desempenho; Segurança; Distribuição; Portabilidade; etc. 2.1.4.2 Requisitos do Processo Padrões; Linguagens de programação; etc. 2.1.4.3 Requisitos Externos Integração; Interoperabilidade; etc. 2.2 Gerência de Requisitos O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema, controlando assim as mudanças. Considerado o principal problema dos projetos de software, a Gerência de Requisitos tem como objetivo principal controlar a evolução dos requisitos de um sistema, seja por constatação de novas necessidades, seja por constatação de deficiências nos requisitos registrados até um momento. Normalmente um sistema é particionado em uma hierarquia de elementos. Cada requisito do sistema deve ser alocado a estes elementos (por exemplo: subsistemas, programas). Chama-se esta tarefa de alocação de requisitos, e é fundamental para realizar o acompanhamento e rastreabilidade dos requisitos. Não importa o quão cuidadoso você seja sobre a definição dos seus requisitos, sempre haverá mudanças. O que torna complexo o gerenciamento dos requisitos, não apenas porque um requisito mudado implicará mais ou menos tempo gasto na implementação de uma determinada característica nova, mas também porque a mudança em um requisito terá impacto em outros requisitos. Você precisa certificar-se de compor uma estrutura de requisitos que seja adaptável a mudanças, e de usar vínculos de rastreabilidade para representar as dependências entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O gerenciamento de mudança inclui atividades como estabelecer uma linha de base, determinar quais dependências são importantes de serem rastreadas, estabelecer a rastreabilidade entre itens correlatos e o controle de mudança. Para apoiar um gerenciamento efetivo de requisitos funcionais, os indicadores de estabilidade e rastreabilidade são formas de representação quantificáveis de características de produtos e processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo [Hazan & Leite]. Segundo Emam [EMAM, 1997], os principais problemas relacionados à gerência de requisitos são os seguintes: • Dificuldades de elicitar claramente as mudanças nos requisitos; • Falta de habilidade para chegar a um consenso sobre as mudanças chave para os stakeholders; • Falta de habilidade para manter o documento de requisitos consistente; • Falta de habilidade para estimar adequadamente os recursos necessários para implementar as mudanças nos requisitos. A Tabela 1 abaixo apresenta o conjunto de atividades de um processo de gerência de requisitos. Estas atividades visam apoiar a identificação, controle e rastreamento dos requisitos, bem como o tratamento das mudanças nos requisitos. [Kotonya & Sommerville,1998] 2.3 Modelos de Qualidade 2.3.1 CMMI - Capability Maturity Model Integration O CMMI - Capability Maturity Model Integration é o mais recente modelo de maturidade para desenvolvimento de software do SEI (Software Engineering Institute – Carnegie Mellon University – EUA), um dos maiores influenciadores em gestão de processo de software do mundo. Derivado principalmente dos modelos SW-CMM (CMM for Software, voltado ao desenvolvimento de software básico, ou de infra-estrutura) e SE-CMM (CMM for Systems Engineering, voltado ao desenvolvimento de aplicações de software), o CMMI surgiu da percepção de que software básico e aplicações são desenvolvidos em contextos integrados. (CONTART, 2004) Sendo reconhecido mundialmente por atestar a maturidade dos processos de desenvolvimento da organização, reúne diretrizes e boas práticas, tanto acadêmicas quanto de mercado, às quais devem ser incorporadas pelas empresas em seus processos. Esse conjunto robusto de orientações, que se bem interpretadas e adaptadas, respeitando-se o contexto de cada empresa, levam a melhorar a qualidade, produtividade e eficácia das organizações que os aplicam. Por causa das heranças de outros modelos e a dificuldade de se criar apenas uma representação, o CMMI ficou com duas representações: Contínua (para uma única área de processo ou um conjunto de áreas de processo) • Níveis de Capacidade • Agrupamento das Áreas de Processo por Categoria • Avaliação da capacidade das Áreas de Processo Por Estágios (para um conjunto de áreas de processo estabelecidas pela organização) • Níveis de Maturidade • Agrupamento de Áreas de Processo por Nível • Avaliação da Organização como um todo Figura 1 - Representação Contínua x Por Estágios [Vasconcelos, 2006] 2.3.1.1 Representação Contínua Caso você escolha a representação contínua para sua organização, você pode esperar que o modelo: • Permita que você selecione a ordem de aperfeiçoamento que melhor atende aos objetivos comerciais de sua organização, diminuindo as áreas de risco. • Permita comparações internas e entre organizações, de área de processos a base da área de processos, comparando os resultados através da utilização de staging equivalente. • Forneça uma migração facilitada do padrão Electronic Industries Alliance Interim Standard (EIA/IS) 731 para o CMMI. • Seja capaz de realizar uma comparação do aperfeiçoamento do processo (Afford an easy comparison of process improvement to International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 15504), porque a organização das áreas de processos é similar à do ISO/IEC 15504. 2.3.1.2 Representação por Estágio Caso você escolha a representação por estágio para sua organização, você pode esperar que o modelo: • Forneça uma seqüência comprovada de aperfeiçoamentos, começando com práticas básicas de gerenciamento e progredindo através de um caminho predefinido e comprovado de níveis sucessivos – cada um servindo como base para o próximo. • Permita comparações internas e entre organizações, através do uso dos níveis de maturidade. • Ofereça a fácil migração do SW-CMM para o CMMI. • Forneça uma nota avaliativa única que sumarize os resultados de certificações, e permita comparações entre as organizações Os componentes do modelo são os mesmos para as duas representações: São eles: Áreas de processo, metas específicas, práticas específicas, metas genéricas, práticas genéricas, produtos de trabalho típicos, sub-práticas, amplificações de disciplinas, elaboração de práticas genéricas e referências As organizações necessitam planejar a absorção de novos conceitos, aprendê-los, interiorizá-los e praticá-los. Isso acontece paulatinamente. E é por esse motivo que o CMMI tem, na sua representação contínua os “níveis de capacidade”. São cinco os níveis de capacidade do CMMI, cada um deles indicando o estágio do programa de melhoria de qualidade no qual a organização está. [Caram, 2008] 2.3.2 Níveis de Capacidade Figura 2 - Níveis de Capacidade [Vasconcelos, 2006] Já na representação por estágios, temos cinco níveis de maturidade, onde cada nível representa uma camada na base para a melhoria contínua do processo. 2.3.3 Níveis de Maturidade Figura 3 - Níveis de Maturidade [CITS] A seguir seguem as áreas de processo para representação por estágio [Vasconcelos, 2006]: 1 - Inicial • Estágio inicial – completa falta de planejamento e controle dos processos. Os funcionários estão focados basicamente em atividades corretivas que surgem a todo momento. 2 - Gerenciado • Gerência de Requisitos – REQM • Planejamento de Projeto – PP • Acompanhamento e Controle De Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Garantia da Qualidade de Processo e Produto – PPQA • Gerência de Configuração – CM • Medição e Análise - MA 3 - Definido • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Gerência Integrada de Projeto - IPM • Gerência de Risco – RSKM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação – VAL • Análise de Decisão e Resolução - DAR 4 – Quantitativamente Gerenciado • Desempenho do Processo Organizacional – OPP • Gerência Quantitativa de Projeto - QPM 5 - Otimizado • Análise Causal e Resolução – CAR • Inovação e Melhoria Organizacional - OID Tabela 2 - Quadro de Competências por Estágio [Vasconcelos, 2006] As áreas de processo para representação contínua são divididas em quatro categorias [Vasconcelos, 2006]: Gerência de Processo • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Desempenho do Processo Organizacional – OPP • Inovação e Melhoria Organizacional - OID Gerência de Projeto • Planejamento de Projeto – PP • Acompanhamento e Controle de Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Gerência Integrada de Projeto – IPM • Gerência de Risco – RSKM • Gerência Quantitativa de Projeto - QPM Engenharia • Gerência de Requisitos – REQM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação - VAL Suporte • Gerência de Configuração – CM • Garantia da Qualidade de Processo e Produto – PPQA • Medição e Análise – MA • Análise de Decisão e Resolução – DAR • Análise Causal e Resolução - CAR Tabela 3 - Quadro de Competências Contínua [Vasconcelos, 2006] 2.4 MPS.Br O MPS.Br ou Melhoria de Processos do Software Brasileiro, é um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação às normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. O modelo MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS. (Wikipédia, 2008) 2.4.1 Estrutura do Modelo Figura 4 - Estrutura 1 do Modelo MPS.Br [Vasconcelos, 2007] • ISO/IEC 12207 (Processos de Ciclo de Vida de Software) • ISO/IEC 15504 (Framework para Avaliação (e Melhoria) de Processo) • CMMI (Modelo para Melhoria de Processos de Software) Figura 5 - Estrutura 2 do Modelo MPS.Br [Vasconcelos, 2007] O modelo MR-MPS define: • 21 processos baseados em processos selecionados da ISO/IEC 12207 Amd.2 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. • 5 perfis de capacidade de processo, expressos em termos de processos e de cinco atributos de processo (AP1.1, AP2.1 e 2.2, AP3.1 e 3.2) • 7 níveis de maturidade. Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores e eventualmente, acrescenta novos atributos de processo a todos os processos. 7 Níveis 21 Processos 5 Atributos de Processo(Capacidade) A – Em Otimização • Implantação de Inovações na Organização – IIO • Análise de Causas e Resolução - ARC AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 B – Gerenciado Quantitativamente • Desempenho do Processo Organizacional – DEP • Gerência Quantitativa do Projeto – GQP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 C - Definido • Gerência de Riscos – GRI • Análise de Decisão e Resolução – ADR AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 D – Largamente Definido • Desenvolvimento de Requisitos – DRE • Solução Técnica – STE • Validação – VAL • Verificação – VER • Integração do Produto – ITP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 E – Parcialmente Definido • Treinamento – TER • Definição do Processo Organizacional – DFP • Avaliação e Melhoria do Processo Organizacional – AMP • Adaptação do Processo para Gerência de Projeto – APG AP 1.1, AP 2.1, AP 2.2, AP 3.1 (processo padrão é definido) e AP 3.2 (processo padrão está implementado possibilitando demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo ) F - Gerenciado • Gerência de Configuração – GCO • Garantia da Qualidade – GQA • Medição – MED • Aquisição - AQU AP 1.1, AP 2.1 e AP 2.2 (produtos de trabalho do processo são gerenciados) G – Parcialmente Gerenciado • Gerência de Projeto – GPR • Gerência de Requisitos – GRE AP 1.1 (processo é executado) e AP 2.1(processo é gerenciado) Tabela 4 - Níveis de Maturidade do MR-MPS e Atributos de Processo [Antonioni, 2007] • AP 1.1: O processo é executado O processo atinge seu propósito • AP 2.1: O processo é gerenciado O atributo de gerência de execução é uma medida da extensão na qual a execução do processo é gerenciada • AP 2.2: Os produtos de trabalho do processo são gerenciados Extensão na qual os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente • AP 3.1: O processo é definido Um processo-padrão é mantido para apoiar a implementação do processo definido • AP 3.2: O processo está implementado O processo-padrão é efetivamente implementado como um processo definido para atingir seus resultados 2.4.2 Processos Figura 6 - Processos do MPS.Br [Vasconcelos, 2007] 2.4.3 MR-MPS: Modelo de referência para melhoria do processo de software O MPS.Br apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são: A - Em Otimização; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado; Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento). Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistas. 2.4.4 MA-MPS – Método de avaliação para melhoria do processo de software Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresas e organizações que implementaram o MR-MPS. Elaboração de guia de aquisição, desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras. 2.4.5 MN-MPS – Modelo de negócio para melhoria do processo de software Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica. 2.5 Comparação do MPS.Br com o CMMI O CMMI varia do 1 ao 5 e o MPS.Br varia do G ao A, sendo que ao contrário do CMMI, o primeiro nível já exige que a empresa tenha determinados processos definidos. A escala de níveis pode ser expressa da seguinte forma [Pinto, 2006]: • G – Parcialmente Gerenciado • F – Gerenciado • E – Parcialmente Definido • D – Largamente Definido • C – Definido • B – Gerenciado Quantitativamente • A – Em Otimização Os níveis do MPS.Br também são compostos por Áreas de Processos, que são os tópicos mais importantes para um processo de desenvolvimento de software e através deles foi possível criar a seguinte tabela de equivalência dos níveis do CMMI e do MPS.Br: Figura 7 - Comparação dos Níveis de Maturidade do CMMI e do MPS.Br [Pinto, 2006] Analisando a tabela, verifica-se que os níveis do MPS.Br permitem que a empresa implante processos de uma forma mais gradual. Essa idéia refletida para o mercado brasileiro de software permite que empresas de pequeno porte, que não possuem muito dinheiro para investir em metodologias e processos, possam tomar a iniciativa de definir processos. Hoje, o MPS.Br e o CMMI em termos de qualidade de software possuem níveis equivalentes, mas com a vantagem do MPS.Br ser muito mais barato e existir financiamento do BID para grupos de empresas que desejam se certificar. 3 Avaliação Atual da Maturidade em Gerência de Requisitos de uma Organização Conforme citado na seção 1 deste trabalho, o objetivo da organização é obter melhoria nos processos sendo assim foi criado um método para avaliação e priorização dos investimentos nas ações de padronização, baseado no modelo de avaliação do MPS.BR [MPS.Br, 2007b]. Segundo o guia de implementação parte 1 [MPS.Br, 2007c] os seguintes resultados de processo são esperados para a gerência de requisitos : Resultados de Processo do MPS.BR GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos GRE2 Os requisitos de software são aprovados utilizando critérios objetivos GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto Tabela 5 - Resultados de Processos Esperados para a Gerência de Requisitos Cada um destes itens será avaliado seguindo o processo descrito abaixo: O processo de avaliação interna é composto de 3 sub-processos: 1) Preparar a avaliação 2) Realizar avaliação Interna 3) Consolidar resultados da avaliação A figura abaixo ilustra os sub-processos do processo de avaliação: A tabela abaxo relaciona as atividades a serem realizadas para execução do procedimento de avaliação interna: Processo De Avaliação Interna Sub-processo Atividade Preparar a avaliação Planejar a avaliação Agendar as entrevistas Preparar as planilhas para entrevista Realizar avaliação Interna Conduzir a avaliação Registrar resultados Consolidar resultados da avaliação Organizar os resultados Consolidar as informações Priorizar os Resultados Tabela 6 - Atividades a Serem Realizadas para Execução do Procedimento de Avaliação Interna de Maturidade A figura abaixo demonstra as atividades de forma gráfica: Figura 9 - Fluxo de Atividades de Avaliação Interna de Maturidade em Gerência de Requisitos Como resultado do processo obteremos: o Os detalhes de realização de cada uma das atividades executadas pela organização o São determinados as frequências em que cada resultado do processo é obtido com as atividades das equipes o São gerados a priorização de investimentos nos resultados de processo que devem ser investidos inicialmente Durante a atividade de condução da avaliação as equipes deverão apresentar evidências do atingimento do resultado de cada resultado esperado. Serão consignados para cada resultado esperado as respostas “Sempre”, “As Vezes” e “Nunca” indicando quando se obtem o resultado nos projetos que a equipe conduz. Durante a atividade de consolidação, os resultados esperados serão ordenados pela maior quantidade de “Nunca”, depois maior quantidade de “As Vezes” e depois maior quantidade de “Sempre”. Os investimentos em melhoria de processo devem ser priorizados de acordo com a ordenação anterior (“Nunca”, “As Vezes” e “Sempre”). 4 Processos e Técnicas para a Gerência de Requisitos Este capítulo tem o objetivo de apresentar uma sugestão para implantação de processo de Gerência de Requisitos, levando em consideração as limitações e características da empresa, para atender às práticas sugeridas no nível F do MPS.Br. A tabela a seguir apresenta os resultados esperados nas práticas do MPS.Br e as atividades propostas para que os mesmos sejam atendidos: Práticas MPS.BR Resultados esperados nas práticas Atividades Propostas GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; • Identificar os fornecedores no plano de projeto e documentar; • Realizar reuniões freqüentes sempre registradas através de atas e e-mails, sendo estes aprovados pelos fornecedores e analistas GRE2 Os requisitos de software são aprovados por meio de critérios objetivos; • Elaborar checklist para possibilitar melhor entendimento dos problemas da organização em relação à especificação de requisitos; • Realizar reuniões de kick off, onde se apresenta o projeto como um todo (incluindo seus requisitos) GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; • Confeccionar cronogramas; • Utilizar contagem por ponto de função; • Utilizar ferramenta de controle de versões (CVS, VSS,...). GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; • Aplicar técnica de revisão por pares GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto. • Deve haver registro do histórico de requisitos de mudanças. Tabela 7: Processo de Gerência de Requisitos – GRE 4.1 Elaboração do Plano de Projeto O que deve ser feito para cumprir práticas propostas no modelo MPS.Br é a documentação do plano do projeto, identificando os fornecedores, ou seja, os usuários que irão fornecer os requisitos para a elaboração do software. 4.2 Captura de requisitos Deve ser feita a captura de requisitos funcionais e não funcionais junto ao fornecedor. As solicitações feitas pelos fornecedores, indicados no Plano de Projeto, devem ser sempre registradas, realizando reuniões freqüentes, documentadas através de atas ou e-mails aprovados pelos fornecedores e pelos analistas. A cada novo projeto deve ser gerado um documento de visão, que é o documento que fornece uma visão geral sobre o sistema, quem são os stakeholders (interessados pelo projeto), escopo, limitações do sistema, descrição do problema e da solução, entre outros. Para definir os requisitos funcionais do sistema deve ser utilizado o modelo de casos de uso, que é composto pelo diagrama de casos de uso e atores e pelo documento de especificação dos casos de uso, que contém uma descrição sumária, atores, fluxo principal, sub-fluxos, fluxos alternativos, requisitos não-funcionais específicos do caso de uso, pré-condições e pós-condições. 4.3 Elaboração do documento de requisitos Para ajudar na confecção do documento de requisitos deve ser feito um checklist que contenha todos os itens que devem constar em um documento de requisitos, para ser seguido por quem for realizar. Para apresentar este documento devem ser realizadas reuniões de kick off. Todas as mudanças devem ficar em um histórico. 4.4 Estabelecimento de Métricas Após reuniões e documentos aprovados, deve haver uma métrica para o acompanhamento das atividades. Esta métrica sugerida como contagem por ponto de função. A partir daí, deve ser confeccionado o cronograma do projeto, que já existe somente com a fase de requisitos até então. Isso serve para que, a qualquer solicitação do fornecedor, o mesmo saiba o tempo, o custo e o ponto em que está o projeto. 1 Introdução A Engenharia de Software é uma ciência bastante recente se comparada às outras áreas de engenharia como a Civil, Naval dentre outras [Sommerville,2007] e, portanto, muitas áreas não possuem padrões definidos com as melhores práticas, processos que sempre devem ser seguidos e regras que nunca podem ser deixadas de lado. Isso torna qualquer trabalho que envolva o desenvolvimento de software uma tarefa de definições de caminhos a serem seguidos e decisões a serem tomadas que muitas vezes nunca foram vistas antes. No desenvolvimento de software, o como chegar ao caminho perfeito é através da definição de processos, que estão sempre sendo analisados, revistos e aprimorados para aperfeiçoar esse desenvolvimento. Na Gerência de Requisitos, esse aperfeiçoamento constante não se faz diferente. Aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], e o esforço para gerenciá-los corretamente evita o re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários de software [Kotonya & Sommerville,1998]. O trabalho realiza um estudo sobre as melhores práticas adotadas hoje em dia no mercado, em relação à Gerência de Requisitos, e propõe um processo customizado para um ciclo de vida de desenvolvimento de software, de um setor de desenvolvimento de software, de uma média empresa. 1.1 Motivação Antes da gestão do Presidente em exercício as empresas do Sistema FIRJAN (Serviço Social da Indústria - SESI, Serviço Nacional de Aprendizagem Industrial - SENAI, Federação das Indústrias do Rio de Janeiro - FIRJAN, Centro Industrial do Rio de Janeiro - CIRJ e Instituto Euvaldo Lodi - IEL) atuavam de forma independente tanto em suas estruturas de apoio (Recursos Humanos, Contabilidade, Financeiro e etc) quanto na Tecnologia da Informação - TI. Elas possuíam apenas o mesmo presidente, ou Diretor Regional conforme fosse o caso. A Tecnologia da Informação era organizada através de um Centro de Processamento de Dados (CPD) terceirizado, por duas empresas, e de núcleos de informática que atendiam as demandas dos usuários em micro-informática e que eram compostos por funcionários da empresa. O CPD era o setor responsável pelo desenvolvimento, suporte e operação dos principais sistemas de apoio tais como o de Recursos Humanos, Contabilidade, Financeiro, Cadastro Industrial, Estatístico de Atendimento e etc. Os núcleos de informática tinham a responsabilidade de dar suporte operacional de micro-informática, dar manutenção nos computadores, organizar as necessidades de compra em informática e levantar, avaliar e priorizar junto ao CPD as necessidades de melhorias nos sistemas. Quando o atual Presidente assumiu foi iniciada uma corporativação, unificando todas as áreas das empresas de forma a atender as novas demandas do negócio, reduzir custos e aumentar a auto-sustentabilidade. A estratégia foi unificar em apenas uma (1) as áreas que fossem consideradas de apoio (Recursos Humanos, Contabilidade, Financeiro, Jurídico, Administração, Tecnologia da Informação, Compras, entre outras) com isso, reduzindo o quadro de pessoas e gerando uma padronização de atuação para as 5 empresas do grupo. Na área de TI, os núcleos que eram independentes passaram a ficar sob a coordenação do Gerente de Informática, que logo virou Gerente de Tecnologia da Informação, criando a Divisão de Atendimento aos Usuários. No CPD houve o movimento de contratação dos funcionários das empresas terceirizadas criando as estruturas internas de Desenvolvimento de Sistemas e Suporte/Operação. Com o crescimento da demanda de informatização as equipes de desenvolvimento de sistemas foram aumentando, mas de forma desordenada e sem estruturação de processos. Durante muitos anos foram se adaptando as equipes, com diversas configurações, mas pouco se fez em termos de estruturação de processos. Atualmente as equipes de desenvolvimento de sistemas são dividas por áreas de negócio (saúde, lazer, educação, financeiro, entre outras) e cada área possui um líder (especialista de negócio) e uma equipe que varia de 1 a 3 desenvolvedores sendo cada equipe responsável tanto pelo desenvolvimento de novos projetos em sua área quanto ao suporte, manutenção e treinamento dos sistemas de sua responsabilidade. Para aumentar a capacidade de desenvolvimento de novos projetos foi contratada uma fábrica de software para dar maior fôlego ao desenvolvimento dos projetos com a intenção de também permitir maior paralelismo de projetos (projetos concorrentes). Esta fábrica de software está geograficamente distante e com isso existe a necessidade de estruturar melhor o ambiente (Gerência de Configuração). Durante o processo de seleção de um fornecedor para apoiar na estruturação do ambiente houve uma mudança de foco para essa consultoria fazendo com que o projeto se tornasse avaliar o grau de aderência dos processos internos às atividades sugeridas pelo Capability Maturity Model Integration (CMMI) especificamente em desenvolvimento de sistemas versão 2 com foco de priorizar quais investimentos seriam tomados primeiro e em que áreas de processos (PA). Dessa forma a consultoria escolhida avaliou todos os pontos e como resultado indicou que a maior necessidade de investimentos seria na área de Gerência de Requisitos. Como já citado aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], segundo Blaschek em seu artigo [Blaschek, 2002] muitos erros poderiam ser evitados se as organizações tivessem um processo de engenharia de requisitos definido, controlado, medido e aprimorado e este propõe um conjunto de atividades para elicitar, documentar, analisar e validar requisitos, porém os modelos de qualidade, principalmente o MPS.BR [MPS.Br, 2007c] propõem a necessidade de existência um processo para gerenciamento dos requisitos de um projeto O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Sendo assim, a motivação do trabalho é poder contribuir com a melhoria organizacional dos processo de gerenciamento de requisitos da empresa. 1.2 Objetivo do Trabalho Como objetivo da organização não é obter qualquer tipo de certificação e sim melhorar os processos internos, trazendo mais qualidade para o produto entregue ao cliente e também formar uma metodologia consistente e adequada aos padrões de qualidade do mercado, principalmente devido a relações com fornecedores externos, e como se trata de uma organização sem fins lucrativos em que a política e a relação com o Governo estão fortemente presentes, foi escolhido como base para este trabalho o modelo de qualidade Melhoria do Processo de Software - MPS.Br para evolução da maturidade em gerenciamento de requisitos O MPS.Br é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Por ser uma iniciativa nacional possui menor custo e permite empresas de pequeno e médio porte, com menos possibilidade de investimento, melhorar a capacidade de seus processos evoluindo em mais níveis (G a A) [MPS.Br, 2007a] O propósito deste trabalho é demonstrar um método para que a empresa possa atingir um nível melhor de capacidade em gerenciamento de requisitos em seus projetos. 1.3 Organização do Trabalho Este trabalho encontra-se organizado da seguinte forma: a seção 2 apresenta a conceituação dos assuntos que serão abordados neste trabalho, que são: Requisitos e Gerência de Requisitos e dos Modelos de Qualidade, descrevendo CMMI e MPS.Br. A seção 3 tem como propósito customizar o modelo de avaliação de maturidade do MPS.Br para produzir uma avaliação interna a organização. A seção 4 traz processos e técnicas para Gerência de Requisitos, propondo atividades que permitam a organização atender as práticas sugeridas pelo modelo MPS.Br nível F, demonstrando a quais práticas do modelo a atividade está relacionada, indicando ferramentas e técnicas para que as mesmas sejam atendidas. A seção 5 apresenta o plano de implantação da Gerência de Requisitos, criando uma maneira de priorizar os itens não atendidos na avaliação e um plano para que a organização possa implementar as ferramentas e técnicas propostas na seção 4. Finalizando o trabalho, a seção 6 apresenta a conclusão e identifica possíveis trabalhos futuros. 2 Teorias de Fundamentação 2.1 Definição de Requisitos Levantar corretamente os requisitos é umas das tarefas mais importantes no desenvolvimento de um sistema, aos requisitos estão associados aos principais problemas do desenvolvimento de software como re-trabalho, atrasos no cronograma, problemas com custos e insatisfação do requerente. A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deve realizar, sua interface com os demais elementos e sob quais restrições o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema não deve fazer e o que ele deve fazer ao invés de como isto será feito. [Antunes Da Silva, Bonin & Paludo] Eles podem ser demandados por humanos, como usuários, clientes, órgãos reguladores ou desenvolvedores e também podem ser demandados por não humanos, como sistema de rede, sistema legado, bases de dados e ambientes. [Antunes Da Silva, Bonin & Paludo] Seu levantamento facilita o entendimento das necessidades do usuário e a identificação de inconsistências, garantindo melhor qualidade no processo de desenvolvimento do produto. Requisitos mal especificados produzem dor de cabeça, re-trabalho e atrasos no projeto. Requisitos são sentenças que devem descrever de modo claro, sem ambigüidades, conciso e consistente todos os aspectos significativos do sistema proposto. Devem conter informações suficientes para permitir que se construa um sistema que atenda os requerentes. Podem ser coletados em fontes humanas, ambiente onde o sistema funcionará, estudos de viabilidade, processo de coleta, técnicas de levantamento de dados, análise dos produtos competidores e etc. [Bourque & Dupuis, 2004] A seguir os principais tipos: 2.1.1 Requisitos de Negócio Correspondem aos objetivos de negócio ou do usuário que devem ser satisfeitos pelo sistema. Normalmente são descritos por um documento de visão ou escopo de sistema. 2.1.2 Requisitos de Uso Correspondem às atividades que os usuários vão poder fazer utilizando o sistema. Ex: Casos de uso. 2.1.3 Requisitos Funcionais Descrevem o que o sistema deve fazer, serviços ou funções que ele deve realizar. 2.1.4 Requisitos não Funcionais Restrições impostas tanto ao sistema quanto ao seu desenvolvimento. Descreve como deve ser feito. Para melhor organização dos requisitos, podemos separar em diferentes tipos, tais como: 2.1.4.1 Requisitos do Produto: Usabilidade; Confiabilidade; Desempenho; Segurança; Distribuição; Portabilidade; etc. 2.1.4.2 Requisitos do Processo Padrões; Linguagens de programação; etc. 2.1.4.3 Requisitos Externos Integração; Interoperabilidade; etc. 2.2 Gerência de Requisitos O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema, controlando assim as mudanças. Considerado o principal problema dos projetos de software, a Gerência de Requisitos tem como objetivo principal controlar a evolução dos requisitos de um sistema, seja por constatação de novas necessidades, seja por constatação de deficiências nos requisitos registrados até um momento. Normalmente um sistema é particionado em uma hierarquia de elementos. Cada requisito do sistema deve ser alocado a estes elementos (por exemplo: subsistemas, programas). Chama-se esta tarefa de alocação de requisitos, e é fundamental para realizar o acompanhamento e rastreabilidade dos requisitos. Não importa o quão cuidadoso você seja sobre a definição dos seus requisitos, sempre haverá mudanças. O que torna complexo o gerenciamento dos requisitos, não apenas porque um requisito mudado implicará mais ou menos tempo gasto na implementação de uma determinada característica nova, mas também porque a mudança em um requisito terá impacto em outros requisitos. Você precisa certificar-se de compor uma estrutura de requisitos que seja adaptável a mudanças, e de usar vínculos de rastreabilidade para representar as dependências entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O gerenciamento de mudança inclui atividades como estabelecer uma linha de base, determinar quais dependências são importantes de serem rastreadas, estabelecer a rastreabilidade entre itens correlatos e o controle de mudança. Para apoiar um gerenciamento efetivo de requisitos funcionais, os indicadores de estabilidade e rastreabilidade são formas de representação quantificáveis de características de produtos e processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo [Hazan & Leite]. Segundo Emam [EMAM, 1997], os principais problemas relacionados à gerência de requisitos são os seguintes: • Dificuldades de elicitar claramente as mudanças nos requisitos; • Falta de habilidade para chegar a um consenso sobre as mudanças chave para os stakeholders; • Falta de habilidade para manter o documento de requisitos consistente; • Falta de habilidade para estimar adequadamente os recursos necessários para implementar as mudanças nos requisitos. A Tabela 1 abaixo apresenta o conjunto de atividades de um processo de gerência de requisitos. Estas atividades visam apoiar a identificação, controle e rastreamento dos requisitos, bem como o tratamento das mudanças nos requisitos. [Kotonya & Sommerville,1998] 2.3 Modelos de Qualidade 2.3.1 CMMI - Capability Maturity Model Integration O CMMI - Capability Maturity Model Integration é o mais recente modelo de maturidade para desenvolvimento de software do SEI (Software Engineering Institute – Carnegie Mellon University – EUA), um dos maiores influenciadores em gestão de processo de software do mundo. Derivado principalmente dos modelos SW-CMM (CMM for Software, voltado ao desenvolvimento de software básico, ou de infra-estrutura) e SE-CMM (CMM for Systems Engineering, voltado ao desenvolvimento de aplicações de software), o CMMI surgiu da percepção de que software básico e aplicações são desenvolvidos em contextos integrados. (CONTART, 2004) Sendo reconhecido mundialmente por atestar a maturidade dos processos de desenvolvimento da organização, reúne diretrizes e boas práticas, tanto acadêmicas quanto de mercado, às quais devem ser incorporadas pelas empresas em seus processos. Esse conjunto robusto de orientações, que se bem interpretadas e adaptadas, respeitando-se o contexto de cada empresa, levam a melhorar a qualidade, produtividade e eficácia das organizações que os aplicam. Por causa das heranças de outros modelos e a dificuldade de se criar apenas uma representação, o CMMI ficou com duas representações: Contínua (para uma única área de processo ou um conjunto de áreas de processo) • Níveis de Capacidade • Agrupamento das Áreas de Processo por Categoria • Avaliação da capacidade das Áreas de Processo Por Estágios (para um conjunto de áreas de processo estabelecidas pela organização) • Níveis de Maturidade • Agrupamento de Áreas de Processo por Nível • Avaliação da Organização como um todo Figura 1 - Representação Contínua x Por Estágios [Vasconcelos, 2006] 2.3.1.1 Representação Contínua Caso você escolha a representação contínua para sua organização, você pode esperar que o modelo: • Permita que você selecione a ordem de aperfeiçoamento que melhor atende aos objetivos comerciais de sua organização, diminuindo as áreas de risco. • Permita comparações internas e entre organizações, de área de processos a base da área de processos, comparando os resultados através da utilização de staging equivalente. • Forneça uma migração facilitada do padrão Electronic Industries Alliance Interim Standard (EIA/IS) 731 para o CMMI. • Seja capaz de realizar uma comparação do aperfeiçoamento do processo (Afford an easy comparison of process improvement to International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 15504), porque a organização das áreas de processos é similar à do ISO/IEC 15504. 2.3.1.2 Representação por Estágio Caso você escolha a representação por estágio para sua organização, você pode esperar que o modelo: • Forneça uma seqüência comprovada de aperfeiçoamentos, começando com práticas básicas de gerenciamento e progredindo através de um caminho predefinido e comprovado de níveis sucessivos – cada um servindo como base para o próximo. • Permita comparações internas e entre organizações, através do uso dos níveis de maturidade. • Ofereça a fácil migração do SW-CMM para o CMMI. • Forneça uma nota avaliativa única que sumarize os resultados de certificações, e permita comparações entre as organizações Os componentes do modelo são os mesmos para as duas representações: São eles: Áreas de processo, metas específicas, práticas específicas, metas genéricas, práticas genéricas, produtos de trabalho típicos, sub-práticas, amplificações de disciplinas, elaboração de práticas genéricas e referências As organizações necessitam planejar a absorção de novos conceitos, aprendê-los, interiorizá-los e praticá-los. Isso acontece paulatinamente. E é por esse motivo que o CMMI tem, na sua representação contínua os “níveis de capacidade”. São cinco os níveis de capacidade do CMMI, cada um deles indicando o estágio do programa de melhoria de qualidade no qual a organização está. [Caram, 2008] 2.3.2 Níveis de Capacidade Figura 2 - Níveis de Capacidade [Vasconcelos, 2006] Já na representação por estágios, temos cinco níveis de maturidade, onde cada nível representa uma camada na base para a melhoria contínua do processo. 2.3.3 Níveis de Maturidade Figura 3 - Níveis de Maturidade [CITS] A seguir seguem as áreas de processo para representação por estágio [Vasconcelos, 2006]: 1 - Inicial • Estágio inicial – completa falta de planejamento e controle dos processos. Os funcionários estão focados basicamente em atividades corretivas que surgem a todo momento. 2 - Gerenciado • Gerência de Requisitos – REQM • Planejamento de Projeto – PP • Acompanhamento e Controle De Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Garantia da Qualidade de Processo e Produto – PPQA • Gerência de Configuração – CM • Medição e Análise - MA 3 - Definido • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Gerência Integrada de Projeto - IPM • Gerência de Risco – RSKM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação – VAL • Análise de Decisão e Resolução - DAR 4 – Quantitativamente Gerenciado • Desempenho do Processo Organizacional – OPP • Gerência Quantitativa de Projeto - QPM 5 - Otimizado • Análise Causal e Resolução – CAR • Inovação e Melhoria Organizacional - OID Tabela 2 - Quadro de Competências por Estágio [Vasconcelos, 2006] As áreas de processo para representação contínua são divididas em quatro categorias [Vasconcelos, 2006]: Gerência de Processo • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Desempenho do Processo Organizacional – OPP • Inovação e Melhoria Organizacional - OID Gerência de Projeto • Planejamento de Projeto – PP • Acompanhamento e Controle de Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Gerência Integrada de Projeto – IPM • Gerência de Risco – RSKM • Gerência Quantitativa de Projeto - QPM Engenharia • Gerência de Requisitos – REQM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação - VAL Suporte • Gerência de Configuração – CM • Garantia da Qualidade de Processo e Produto – PPQA • Medição e Análise – MA • Análise de Decisão e Resolução – DAR • Análise Causal e Resolução - CAR Tabela 3 - Quadro de Competências Contínua [Vasconcelos, 2006] 2.4 MPS.Br O MPS.Br ou Melhoria de Processos do Software Brasileiro, é um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação às normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. O modelo MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS. (Wikipédia, 2008) 2.4.1 Estrutura do Modelo Figura 4 - Estrutura 1 do Modelo MPS.Br [Vasconcelos, 2007] • ISO/IEC 12207 (Processos de Ciclo de Vida de Software) • ISO/IEC 15504 (Framework para Avaliação (e Melhoria) de Processo) • CMMI (Modelo para Melhoria de Processos de Software) Figura 5 - Estrutura 2 do Modelo MPS.Br [Vasconcelos, 2007] O modelo MR-MPS define: • 21 processos baseados em processos selecionados da ISO/IEC 12207 Amd.2 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. • 5 perfis de capacidade de processo, expressos em termos de processos e de cinco atributos de processo (AP1.1, AP2.1 e 2.2, AP3.1 e 3.2) • 7 níveis de maturidade. Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores e eventualmente, acrescenta novos atributos de processo a todos os processos. 7 Níveis 21 Processos 5 Atributos de Processo(Capacidade) A – Em Otimização • Implantação de Inovações na Organização – IIO • Análise de Causas e Resolução - ARC AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 B – Gerenciado Quantitativamente • Desempenho do Processo Organizacional – DEP • Gerência Quantitativa do Projeto – GQP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 C - Definido • Gerência de Riscos – GRI • Análise de Decisão e Resolução – ADR AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 D – Largamente Definido • Desenvolvimento de Requisitos – DRE • Solução Técnica – STE • Validação – VAL • Verificação – VER • Integração do Produto – ITP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 E – Parcialmente Definido • Treinamento – TER • Definição do Processo Organizacional – DFP • Avaliação e Melhoria do Processo Organizacional – AMP • Adaptação do Processo para Gerência de Projeto – APG AP 1.1, AP 2.1, AP 2.2, AP 3.1 (processo padrão é definido) e AP 3.2 (processo padrão está implementado possibilitando demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo ) F - Gerenciado • Gerência de Configuração – GCO • Garantia da Qualidade – GQA • Medição – MED • Aquisição - AQU AP 1.1, AP 2.1 e AP 2.2 (produtos de trabalho do processo são gerenciados) G – Parcialmente Gerenciado • Gerência de Projeto – GPR • Gerência de Requisitos – GRE AP 1.1 (processo é executado) e AP 2.1(processo é gerenciado) Tabela 4 - Níveis de Maturidade do MR-MPS e Atributos de Processo [Antonioni, 2007] • AP 1.1: O processo é executado O processo atinge seu propósito • AP 2.1: O processo é gerenciado O atributo de gerência de execução é uma medida da extensão na qual a execução do processo é gerenciada • AP 2.2: Os produtos de trabalho do processo são gerenciados Extensão na qual os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente • AP 3.1: O processo é definido Um processo-padrão é mantido para apoiar a implementação do processo definido • AP 3.2: O processo está implementado O processo-padrão é efetivamente implementado como um processo definido para atingir seus resultados 2.4.2 Processos Figura 6 - Processos do MPS.Br [Vasconcelos, 2007] 2.4.3 MR-MPS: Modelo de referência para melhoria do processo de software O MPS.Br apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são: A - Em Otimização; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado; Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento). Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistas. 2.4.4 MA-MPS – Método de avaliação para melhoria do processo de software Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresas e organizações que implementaram o MR-MPS. Elaboração de guia de aquisição, desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras. 2.4.5 MN-MPS – Modelo de negócio para melhoria do processo de software Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica. 2.5 Comparação do MPS.Br com o CMMI O CMMI varia do 1 ao 5 e o MPS.Br varia do G ao A, sendo que ao contrário do CMMI, o primeiro nível já exige que a empresa tenha determinados processos definidos. A escala de níveis pode ser expressa da seguinte forma [Pinto, 2006]: • G – Parcialmente Gerenciado • F – Gerenciado • E – Parcialmente Definido • D – Largamente Definido • C – Definido • B – Gerenciado Quantitativamente • A – Em Otimização Os níveis do MPS.Br também são compostos por Áreas de Processos, que são os tópicos mais importantes para um processo de desenvolvimento de software e através deles foi possível criar a seguinte tabela de equivalência dos níveis do CMMI e do MPS.Br: Figura 7 - Comparação dos Níveis de Maturidade do CMMI e do MPS.Br [Pinto, 2006] Analisando a tabela, verifica-se que os níveis do MPS.Br permitem que a empresa implante processos de uma forma mais gradual. Essa idéia refletida para o mercado brasileiro de software permite que empresas de pequeno porte, que não possuem muito dinheiro para investir em metodologias e processos, possam tomar a iniciativa de definir processos. Hoje, o MPS.Br e o CMMI em termos de qualidade de software possuem níveis equivalentes, mas com a vantagem do MPS.Br ser muito mais barato e existir financiamento do BID para grupos de empresas que desejam se certificar. 3 Avaliação Atual da Maturidade em Gerência de Requisitos de uma Organização Conforme citado na seção 1 deste trabalho, o objetivo da organização é obter melhoria nos processos sendo assim foi criado um método para avaliação e priorização dos investimentos nas ações de padronização, baseado no modelo de avaliação do MPS.BR [MPS.Br, 2007b]. Segundo o guia de implementação parte 1 [MPS.Br, 2007c] os seguintes resultados de processo são esperados para a gerência de requisitos : Resultados de Processo do MPS.BR GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos GRE2 Os requisitos de software são aprovados utilizando critérios objetivos GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto Tabela 5 - Resultados de Processos Esperados para a Gerência de Requisitos Cada um destes itens será avaliado seguindo o processo descrito abaixo: O processo de avaliação interna é composto de 3 sub-processos: 1) Preparar a avaliação 2) Realizar avaliação Interna 3) Consolidar resultados da avaliação A figura abaixo ilustra os sub-processos do processo de avaliação: A tabela abaxo relaciona as atividades a serem realizadas para execução do procedimento de avaliação interna: Processo De Avaliação Interna Sub-processo Atividade Preparar a avaliação Planejar a avaliação Agendar as entrevistas Preparar as planilhas para entrevista Realizar avaliação Interna Conduzir a avaliação Registrar resultados Consolidar resultados da avaliação Organizar os resultados Consolidar as informações Priorizar os Resultados Tabela 6 - Atividades a Serem Realizadas para Execução do Procedimento de Avaliação Interna de Maturidade A figura abaixo demonstra as atividades de forma gráfica: Figura 9 - Fluxo de Atividades de Avaliação Interna de Maturidade em Gerência de Requisitos Como resultado do processo obteremos: o Os detalhes de realização de cada uma das atividades executadas pela organização o São determinados as frequências em que cada resultado do processo é obtido com as atividades das equipes o São gerados a priorização de investimentos nos resultados de processo que devem ser investidos inicialmente Durante a atividade de condução da avaliação as equipes deverão apresentar evidências do atingimento do resultado de cada resultado esperado. Serão consignados para cada resultado esperado as respostas “Sempre”, “As Vezes” e “Nunca” indicando quando se obtem o resultado nos projetos que a equipe conduz. Durante a atividade de consolidação, os resultados esperados serão ordenados pela maior quantidade de “Nunca”, depois maior quantidade de “As Vezes” e depois maior quantidade de “Sempre”. Os investimentos em melhoria de processo devem ser priorizados de acordo com a ordenação anterior (“Nunca”, “As Vezes” e “Sempre”). 4 Processos e Técnicas para a Gerência de Requisitos Este capítulo tem o objetivo de apresentar uma sugestão para implantação de processo de Gerência de Requisitos, levando em consideração as limitações e características da empresa, para atender às práticas sugeridas no nível F do MPS.Br. A tabela a seguir apresenta os resultados esperados nas práticas do MPS.Br e as atividades propostas para que os mesmos sejam atendidos: Práticas MPS.BR Resultados esperados nas práticas Atividades Propostas GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; • Identificar os fornecedores no plano de projeto e documentar; • Realizar reuniões freqüentes sempre registradas através de atas e e-mails, sendo estes aprovados pelos fornecedores e analistas GRE2 Os requisitos de software são aprovados por meio de critérios objetivos; • Elaborar checklist para possibilitar melhor entendimento dos problemas da organização em relação à especificação de requisitos; • Realizar reuniões de kick off, onde se apresenta o projeto como um todo (incluindo seus requisitos) GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; • Confeccionar cronogramas; • Utilizar contagem por ponto de função; • Utilizar ferramenta de controle de versões (CVS, VSS,...). GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; • Aplicar técnica de revisão por pares GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto. • Deve haver registro do histórico de requisitos de mudanças. Tabela 7: Processo de Gerência de Requisitos – GRE 4.1 Elaboração do Plano de Projeto O que deve ser feito para cumprir práticas propostas no modelo MPS.Br é a documentação do plano do projeto, identificando os fornecedores, ou seja, os usuários que irão fornecer os requisitos para a elaboração do software. 4.2 Captura de requisitos Deve ser feita a captura de requisitos funcionais e não funcionais junto ao fornecedor. As solicitações feitas pelos fornecedores, indicados no Plano de Projeto, devem ser sempre registradas, realizando reuniões freqüentes, documentadas através de atas ou e-mails aprovados pelos fornecedores e pelos analistas. A cada novo projeto deve ser gerado um documento de visão, que é o documento que fornece uma visão geral sobre o sistema, quem são os stakeholders (interessados pelo projeto), escopo, limitações do sistema, descrição do problema e da solução, entre outros. Para definir os requisitos funcionais do sistema deve ser utilizado o modelo de casos de uso, que é composto pelo diagrama de casos de uso e atores e pelo documento de especificação dos casos de uso, que contém uma descrição sumária, atores, fluxo principal, sub-fluxos, fluxos alternativos, requisitos não-funcionais específicos do caso de uso, pré-condições e pós-condições. 4.3 Elaboração do documento de requisitos Para ajudar na confecção do documento de requisitos deve ser feito um checklist que contenha todos os itens que devem constar em um documento de requisitos, para ser seguido por quem for realizar. Para apresentar este documento devem ser realizadas reuniões de kick off. Todas as mudanças devem ficar em um histórico. 4.4 Estabelecimento de Métricas Após reuniões e documentos aprovados, deve haver uma métrica para o acompanhamento das atividades. Esta métrica sugerida como contagem por ponto de função. A partir daí, deve ser confeccionado o cronograma do projeto, que já existe somente com a fase de requisitos até então. Isso serve para que, a qualquer solicitação do fornecedor, o mesmo saiba o tempo, o custo e o ponto em que está o projeto. 1 Introdução A Engenharia de Software é uma ciência bastante recente se comparada às outras áreas de engenharia como a Civil, Naval dentre outras [Sommerville,2007] e, portanto, muitas áreas não possuem padrões definidos com as melhores práticas, processos que sempre devem ser seguidos e regras que nunca podem ser deixadas de lado. Isso torna qualquer trabalho que envolva o desenvolvimento de software uma tarefa de definições de caminhos a serem seguidos e decisões a serem tomadas que muitas vezes nunca foram vistas antes. No desenvolvimento de software, o como chegar ao caminho perfeito é através da definição de processos, que estão sempre sendo analisados, revistos e aprimorados para aperfeiçoar esse desenvolvimento. Na Gerência de Requisitos, esse aperfeiçoamento constante não se faz diferente. Aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], e o esforço para gerenciá-los corretamente evita o re-trabalho, atrasos no cronograma, custos ultrapassados e a insatisfação dos clientes e usuários de software [Kotonya & Sommerville,1998]. O trabalho realiza um estudo sobre as melhores práticas adotadas hoje em dia no mercado, em relação à Gerência de Requisitos, e propõe um processo customizado para um ciclo de vida de desenvolvimento de software, de um setor de desenvolvimento de software, de uma média empresa. 1.1 Motivação Antes da gestão do Presidente em exercício as empresas do Sistema FIRJAN (Serviço Social da Indústria - SESI, Serviço Nacional de Aprendizagem Industrial - SENAI, Federação das Indústrias do Rio de Janeiro - FIRJAN, Centro Industrial do Rio de Janeiro - CIRJ e Instituto Euvaldo Lodi - IEL) atuavam de forma independente tanto em suas estruturas de apoio (Recursos Humanos, Contabilidade, Financeiro e etc) quanto na Tecnologia da Informação - TI. Elas possuíam apenas o mesmo presidente, ou Diretor Regional conforme fosse o caso. A Tecnologia da Informação era organizada através de um Centro de Processamento de Dados (CPD) terceirizado, por duas empresas, e de núcleos de informática que atendiam as demandas dos usuários em micro-informática e que eram compostos por funcionários da empresa. O CPD era o setor responsável pelo desenvolvimento, suporte e operação dos principais sistemas de apoio tais como o de Recursos Humanos, Contabilidade, Financeiro, Cadastro Industrial, Estatístico de Atendimento e etc. Os núcleos de informática tinham a responsabilidade de dar suporte operacional de micro-informática, dar manutenção nos computadores, organizar as necessidades de compra em informática e levantar, avaliar e priorizar junto ao CPD as necessidades de melhorias nos sistemas. Quando o atual Presidente assumiu foi iniciada uma corporativação, unificando todas as áreas das empresas de forma a atender as novas demandas do negócio, reduzir custos e aumentar a auto-sustentabilidade. A estratégia foi unificar em apenas uma (1) as áreas que fossem consideradas de apoio (Recursos Humanos, Contabilidade, Financeiro, Jurídico, Administração, Tecnologia da Informação, Compras, entre outras) com isso, reduzindo o quadro de pessoas e gerando uma padronização de atuação para as 5 empresas do grupo. Na área de TI, os núcleos que eram independentes passaram a ficar sob a coordenação do Gerente de Informática, que logo virou Gerente de Tecnologia da Informação, criando a Divisão de Atendimento aos Usuários. No CPD houve o movimento de contratação dos funcionários das empresas terceirizadas criando as estruturas internas de Desenvolvimento de Sistemas e Suporte/Operação. Com o crescimento da demanda de informatização as equipes de desenvolvimento de sistemas foram aumentando, mas de forma desordenada e sem estruturação de processos. Durante muitos anos foram se adaptando as equipes, com diversas configurações, mas pouco se fez em termos de estruturação de processos. Atualmente as equipes de desenvolvimento de sistemas são dividas por áreas de negócio (saúde, lazer, educação, financeiro, entre outras) e cada área possui um líder (especialista de negócio) e uma equipe que varia de 1 a 3 desenvolvedores sendo cada equipe responsável tanto pelo desenvolvimento de novos projetos em sua área quanto ao suporte, manutenção e treinamento dos sistemas de sua responsabilidade. Para aumentar a capacidade de desenvolvimento de novos projetos foi contratada uma fábrica de software para dar maior fôlego ao desenvolvimento dos projetos com a intenção de também permitir maior paralelismo de projetos (projetos concorrentes). Esta fábrica de software está geograficamente distante e com isso existe a necessidade de estruturar melhor o ambiente (Gerência de Configuração). Durante o processo de seleção de um fornecedor para apoiar na estruturação do ambiente houve uma mudança de foco para essa consultoria fazendo com que o projeto se tornasse avaliar o grau de aderência dos processos internos às atividades sugeridas pelo Capability Maturity Model Integration (CMMI) especificamente em desenvolvimento de sistemas versão 2 com foco de priorizar quais investimentos seriam tomados primeiro e em que áreas de processos (PA). Dessa forma a consultoria escolhida avaliou todos os pontos e como resultado indicou que a maior necessidade de investimentos seria na área de Gerência de Requisitos. Como já citado aos requisitos estão associados os principais problemas do desenvolvimento de software [Leffingwell,1997], segundo Blaschek em seu artigo [Blaschek, 2002] muitos erros poderiam ser evitados se as organizações tivessem um processo de engenharia de requisitos definido, controlado, medido e aprimorado e este propõe um conjunto de atividades para elicitar, documentar, analisar e validar requisitos, porém os modelos de qualidade, principalmente o MPS.BR [MPS.Br, 2007c] propõem a necessidade de existência um processo para gerenciamento dos requisitos de um projeto O propósito do processo Gerência de Requisitos é gerenciar os requisitos dos produtos e componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Sendo assim, a motivação do trabalho é poder contribuir com a melhoria organizacional dos processo de gerenciamento de requisitos da empresa. 1.2 Objetivo do Trabalho Como objetivo da organização não é obter qualquer tipo de certificação e sim melhorar os processos internos, trazendo mais qualidade para o produto entregue ao cliente e também formar uma metodologia consistente e adequada aos padrões de qualidade do mercado, principalmente devido a relações com fornecedores externos, e como se trata de uma organização sem fins lucrativos em que a política e a relação com o Governo estão fortemente presentes, foi escolhido como base para este trabalho o modelo de qualidade Melhoria do Processo de Software - MPS.Br para evolução da maturidade em gerenciamento de requisitos O MPS.Br é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). Por ser uma iniciativa nacional possui menor custo e permite empresas de pequeno e médio porte, com menos possibilidade de investimento, melhorar a capacidade de seus processos evoluindo em mais níveis (G a A) [MPS.Br, 2007a] O propósito deste trabalho é demonstrar um método para que a empresa possa atingir um nível melhor de capacidade em gerenciamento de requisitos em seus projetos. 1.3 Organização do Trabalho Este trabalho encontra-se organizado da seguinte forma: a seção 2 apresenta a conceituação dos assuntos que serão abordados neste trabalho, que são: Requisitos e Gerência de Requisitos e dos Modelos de Qualidade, descrevendo CMMI e MPS.Br. A seção 3 tem como propósito customizar o modelo de avaliação de maturidade do MPS.Br para produzir uma avaliação interna a organização. A seção 4 traz processos e técnicas para Gerência de Requisitos, propondo atividades que permitam a organização atender as práticas sugeridas pelo modelo MPS.Br nível F, demonstrando a quais práticas do modelo a atividade está relacionada, indicando ferramentas e técnicas para que as mesmas sejam atendidas. A seção 5 apresenta o plano de implantação da Gerência de Requisitos, criando uma maneira de priorizar os itens não atendidos na avaliação e um plano para que a organização possa implementar as ferramentas e técnicas propostas na seção 4. Finalizando o trabalho, a seção 6 apresenta a conclusão e identifica possíveis trabalhos futuros. 2 Teorias de Fundamentação 2.1 Definição de Requisitos Levantar corretamente os requisitos é umas das tarefas mais importantes no desenvolvimento de um sistema, aos requisitos estão associados aos principais problemas do desenvolvimento de software como re-trabalho, atrasos no cronograma, problemas com custos e insatisfação do requerente. A Análise de Requisitos é a primeira atividade técnica no desenvolvimento do software, e pode ser entendida como responsável por definir os serviços que um sistema deve realizar, sua interface com os demais elementos e sob quais restrições o sistema deve operar. Os requisitos dos sistemas devem estabelecer o que o sistema não deve fazer e o que ele deve fazer ao invés de como isto será feito. [Antunes Da Silva, Bonin & Paludo] Eles podem ser demandados por humanos, como usuários, clientes, órgãos reguladores ou desenvolvedores e também podem ser demandados por não humanos, como sistema de rede, sistema legado, bases de dados e ambientes. [Antunes Da Silva, Bonin & Paludo] Seu levantamento facilita o entendimento das necessidades do usuário e a identificação de inconsistências, garantindo melhor qualidade no processo de desenvolvimento do produto. Requisitos mal especificados produzem dor de cabeça, re-trabalho e atrasos no projeto. Requisitos são sentenças que devem descrever de modo claro, sem ambigüidades, conciso e consistente todos os aspectos significativos do sistema proposto. Devem conter informações suficientes para permitir que se construa um sistema que atenda os requerentes. Podem ser coletados em fontes humanas, ambiente onde o sistema funcionará, estudos de viabilidade, processo de coleta, técnicas de levantamento de dados, análise dos produtos competidores e etc. [Bourque & Dupuis, 2004] A seguir os principais tipos: 2.1.1 Requisitos de Negócio Correspondem aos objetivos de negócio ou do usuário que devem ser satisfeitos pelo sistema. Normalmente são descritos por um documento de visão ou escopo de sistema. 2.1.2 Requisitos de Uso Correspondem às atividades que os usuários vão poder fazer utilizando o sistema. Ex: Casos de uso. 2.1.3 Requisitos Funcionais Descrevem o que o sistema deve fazer, serviços ou funções que ele deve realizar. 2.1.4 Requisitos não Funcionais Restrições impostas tanto ao sistema quanto ao seu desenvolvimento. Descreve como deve ser feito. Para melhor organização dos requisitos, podemos separar em diferentes tipos, tais como: 2.1.4.1 Requisitos do Produto: Usabilidade; Confiabilidade; Desempenho; Segurança; Distribuição; Portabilidade; etc. 2.1.4.2 Requisitos do Processo Padrões; Linguagens de programação; etc. 2.1.4.3 Requisitos Externos Integração; Interoperabilidade; etc. 2.2 Gerência de Requisitos O gerenciamento de requisitos é um modelo sistemático para encontrar, documentar, organizar e rastrear os requisitos variáveis de um sistema, controlando assim as mudanças. Considerado o principal problema dos projetos de software, a Gerência de Requisitos tem como objetivo principal controlar a evolução dos requisitos de um sistema, seja por constatação de novas necessidades, seja por constatação de deficiências nos requisitos registrados até um momento. Normalmente um sistema é particionado em uma hierarquia de elementos. Cada requisito do sistema deve ser alocado a estes elementos (por exemplo: subsistemas, programas). Chama-se esta tarefa de alocação de requisitos, e é fundamental para realizar o acompanhamento e rastreabilidade dos requisitos. Não importa o quão cuidadoso você seja sobre a definição dos seus requisitos, sempre haverá mudanças. O que torna complexo o gerenciamento dos requisitos, não apenas porque um requisito mudado implicará mais ou menos tempo gasto na implementação de uma determinada característica nova, mas também porque a mudança em um requisito terá impacto em outros requisitos. Você precisa certificar-se de compor uma estrutura de requisitos que seja adaptável a mudanças, e de usar vínculos de rastreabilidade para representar as dependências entre os requisitos e outros artefatos do ciclo de vida do desenvolvimento. O gerenciamento de mudança inclui atividades como estabelecer uma linha de base, determinar quais dependências são importantes de serem rastreadas, estabelecer a rastreabilidade entre itens correlatos e o controle de mudança. Para apoiar um gerenciamento efetivo de requisitos funcionais, os indicadores de estabilidade e rastreabilidade são formas de representação quantificáveis de características de produtos e processos, sendo utilizados para acompanhar e melhorar os resultados ao longo do tempo [Hazan & Leite]. Segundo Emam [EMAM, 1997], os principais problemas relacionados à gerência de requisitos são os seguintes: • Dificuldades de elicitar claramente as mudanças nos requisitos; • Falta de habilidade para chegar a um consenso sobre as mudanças chave para os stakeholders; • Falta de habilidade para manter o documento de requisitos consistente; • Falta de habilidade para estimar adequadamente os recursos necessários para implementar as mudanças nos requisitos. A Tabela 1 abaixo apresenta o conjunto de atividades de um processo de gerência de requisitos. Estas atividades visam apoiar a identificação, controle e rastreamento dos requisitos, bem como o tratamento das mudanças nos requisitos. [Kotonya & Sommerville,1998] 2.3 Modelos de Qualidade 2.3.1 CMMI - Capability Maturity Model Integration O CMMI - Capability Maturity Model Integration é o mais recente modelo de maturidade para desenvolvimento de software do SEI (Software Engineering Institute – Carnegie Mellon University – EUA), um dos maiores influenciadores em gestão de processo de software do mundo. Derivado principalmente dos modelos SW-CMM (CMM for Software, voltado ao desenvolvimento de software básico, ou de infra-estrutura) e SE-CMM (CMM for Systems Engineering, voltado ao desenvolvimento de aplicações de software), o CMMI surgiu da percepção de que software básico e aplicações são desenvolvidos em contextos integrados. (CONTART, 2004) Sendo reconhecido mundialmente por atestar a maturidade dos processos de desenvolvimento da organização, reúne diretrizes e boas práticas, tanto acadêmicas quanto de mercado, às quais devem ser incorporadas pelas empresas em seus processos. Esse conjunto robusto de orientações, que se bem interpretadas e adaptadas, respeitando-se o contexto de cada empresa, levam a melhorar a qualidade, produtividade e eficácia das organizações que os aplicam. Por causa das heranças de outros modelos e a dificuldade de se criar apenas uma representação, o CMMI ficou com duas representações: Contínua (para uma única área de processo ou um conjunto de áreas de processo) • Níveis de Capacidade • Agrupamento das Áreas de Processo por Categoria • Avaliação da capacidade das Áreas de Processo Por Estágios (para um conjunto de áreas de processo estabelecidas pela organização) • Níveis de Maturidade • Agrupamento de Áreas de Processo por Nível • Avaliação da Organização como um todo Figura 1 - Representação Contínua x Por Estágios [Vasconcelos, 2006] 2.3.1.1 Representação Contínua Caso você escolha a representação contínua para sua organização, você pode esperar que o modelo: • Permita que você selecione a ordem de aperfeiçoamento que melhor atende aos objetivos comerciais de sua organização, diminuindo as áreas de risco. • Permita comparações internas e entre organizações, de área de processos a base da área de processos, comparando os resultados através da utilização de staging equivalente. • Forneça uma migração facilitada do padrão Electronic Industries Alliance Interim Standard (EIA/IS) 731 para o CMMI. • Seja capaz de realizar uma comparação do aperfeiçoamento do processo (Afford an easy comparison of process improvement to International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 15504), porque a organização das áreas de processos é similar à do ISO/IEC 15504. 2.3.1.2 Representação por Estágio Caso você escolha a representação por estágio para sua organização, você pode esperar que o modelo: • Forneça uma seqüência comprovada de aperfeiçoamentos, começando com práticas básicas de gerenciamento e progredindo através de um caminho predefinido e comprovado de níveis sucessivos – cada um servindo como base para o próximo. • Permita comparações internas e entre organizações, através do uso dos níveis de maturidade. • Ofereça a fácil migração do SW-CMM para o CMMI. • Forneça uma nota avaliativa única que sumarize os resultados de certificações, e permita comparações entre as organizações Os componentes do modelo são os mesmos para as duas representações: São eles: Áreas de processo, metas específicas, práticas específicas, metas genéricas, práticas genéricas, produtos de trabalho típicos, sub-práticas, amplificações de disciplinas, elaboração de práticas genéricas e referências As organizações necessitam planejar a absorção de novos conceitos, aprendê-los, interiorizá-los e praticá-los. Isso acontece paulatinamente. E é por esse motivo que o CMMI tem, na sua representação contínua os “níveis de capacidade”. São cinco os níveis de capacidade do CMMI, cada um deles indicando o estágio do programa de melhoria de qualidade no qual a organização está. [Caram, 2008] 2.3.2 Níveis de Capacidade Figura 2 - Níveis de Capacidade [Vasconcelos, 2006] Já na representação por estágios, temos cinco níveis de maturidade, onde cada nível representa uma camada na base para a melhoria contínua do processo. 2.3.3 Níveis de Maturidade Figura 3 - Níveis de Maturidade [CITS] A seguir seguem as áreas de processo para representação por estágio [Vasconcelos, 2006]: 1 - Inicial • Estágio inicial – completa falta de planejamento e controle dos processos. Os funcionários estão focados basicamente em atividades corretivas que surgem a todo momento. 2 - Gerenciado • Gerência de Requisitos – REQM • Planejamento de Projeto – PP • Acompanhamento e Controle De Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Garantia da Qualidade de Processo e Produto – PPQA • Gerência de Configuração – CM • Medição e Análise - MA 3 - Definido • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Gerência Integrada de Projeto - IPM • Gerência de Risco – RSKM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação – VAL • Análise de Decisão e Resolução - DAR 4 – Quantitativamente Gerenciado • Desempenho do Processo Organizacional – OPP • Gerência Quantitativa de Projeto - QPM 5 - Otimizado • Análise Causal e Resolução – CAR • Inovação e Melhoria Organizacional - OID Tabela 2 - Quadro de Competências por Estágio [Vasconcelos, 2006] As áreas de processo para representação contínua são divididas em quatro categorias [Vasconcelos, 2006]: Gerência de Processo • Foco no Processo da Organização – OPF • Definição do Processo da Organização – OPD • Treinamento Organizacional – OT • Desempenho do Processo Organizacional – OPP • Inovação e Melhoria Organizacional - OID Gerência de Projeto • Planejamento de Projeto – PP • Acompanhamento e Controle de Projeto – PMC • Gerência de Acordos com Fornecedores – SAM • Gerência Integrada de Projeto – IPM • Gerência de Risco – RSKM • Gerência Quantitativa de Projeto - QPM Engenharia • Gerência de Requisitos – REQM • Desenvolvimento de Requisitos – RD • Solução Técnica – TS • Integração de Produto – PI • Verificação – VER • Validação - VAL Suporte • Gerência de Configuração – CM • Garantia da Qualidade de Processo e Produto – PPQA • Medição e Análise – MA • Análise de Decisão e Resolução – DAR • Análise Causal e Resolução - CAR Tabela 3 - Quadro de Competências Contínua [Vasconcelos, 2006] 2.4 MPS.Br O MPS.Br ou Melhoria de Processos do Software Brasileiro, é um movimento para a melhoria e um modelo de qualidade de processo voltada para a realidade do mercado de pequenas e médias empresas de desenvolvimento de software no Brasil. Ele é baseado no CMMI, nas normas ISO/IEC 12207 e ISO/IEC 15504 e na realidade do mercado brasileiro. No Brasil, uma das principais vantagens do modelo é seu custo reduzido de certificação em relação às normas estrangeiras, sendo ideal para micro, pequenas e médias empresas. O modelo MPS.Br é dividido em 3 partes: MR-MPS, MA-MPS, MN-MPS. (Wikipédia, 2008) 2.4.1 Estrutura do Modelo Figura 4 - Estrutura 1 do Modelo MPS.Br [Vasconcelos, 2007] • ISO/IEC 12207 (Processos de Ciclo de Vida de Software) • ISO/IEC 15504 (Framework para Avaliação (e Melhoria) de Processo) • CMMI (Modelo para Melhoria de Processos de Software) Figura 5 - Estrutura 2 do Modelo MPS.Br [Vasconcelos, 2007] O modelo MR-MPS define: • 21 processos baseados em processos selecionados da ISO/IEC 12207 Amd.2 e ISO/IEC 15504-5 e nas áreas de processo do CMMI-SE/SW. • 5 perfis de capacidade de processo, expressos em termos de processos e de cinco atributos de processo (AP1.1, AP2.1 e 2.2, AP3.1 e 3.2) • 7 níveis de maturidade. Cada nível introduz alguns processos, mantendo todos os processos dos níveis inferiores e eventualmente, acrescenta novos atributos de processo a todos os processos. 7 Níveis 21 Processos 5 Atributos de Processo(Capacidade) A – Em Otimização • Implantação de Inovações na Organização – IIO • Análise de Causas e Resolução - ARC AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 B – Gerenciado Quantitativamente • Desempenho do Processo Organizacional – DEP • Gerência Quantitativa do Projeto – GQP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 C - Definido • Gerência de Riscos – GRI • Análise de Decisão e Resolução – ADR AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 D – Largamente Definido • Desenvolvimento de Requisitos – DRE • Solução Técnica – STE • Validação – VAL • Verificação – VER • Integração do Produto – ITP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 E – Parcialmente Definido • Treinamento – TER • Definição do Processo Organizacional – DFP • Avaliação e Melhoria do Processo Organizacional – AMP • Adaptação do Processo para Gerência de Projeto – APG AP 1.1, AP 2.1, AP 2.2, AP 3.1 (processo padrão é definido) e AP 3.2 (processo padrão está implementado possibilitando demonstrar a adequação e a eficácia do processo, e avaliar onde pode ser feita a melhoria contínua do processo ) F - Gerenciado • Gerência de Configuração – GCO • Garantia da Qualidade – GQA • Medição – MED • Aquisição - AQU AP 1.1, AP 2.1 e AP 2.2 (produtos de trabalho do processo são gerenciados) G – Parcialmente Gerenciado • Gerência de Projeto – GPR • Gerência de Requisitos – GRE AP 1.1 (processo é executado) e AP 2.1(processo é gerenciado) Tabela 4 - Níveis de Maturidade do MR-MPS e Atributos de Processo [Antonioni, 2007] • AP 1.1: O processo é executado O processo atinge seu propósito • AP 2.1: O processo é gerenciado O atributo de gerência de execução é uma medida da extensão na qual a execução do processo é gerenciada • AP 2.2: Os produtos de trabalho do processo são gerenciados Extensão na qual os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente • AP 3.1: O processo é definido Um processo-padrão é mantido para apoiar a implementação do processo definido • AP 3.2: O processo está implementado O processo-padrão é efetivamente implementado como um processo definido para atingir seus resultados 2.4.2 Processos Figura 6 - Processos do MPS.Br [Vasconcelos, 2007] 2.4.3 MR-MPS: Modelo de referência para melhoria do processo de software O MPS.Br apresenta 7 níveis de maturidade (o que é um diferencial em relação aos outros padrões de processo) que são: A - Em Otimização; B - Gerenciado quantitativamente; C - Definido; D - Largamente Definido; E - Parcialmente Definido; F - Gerenciado; G - Parcialmente Gerenciado; Cada nível de maturidade possui suas áreas de processo, onde são analisados os processos fundamentais (aquisição, gerência de requisitos, desenvolvimento de requisitos, solução técnica, integração do produto, instalação do produto, liberação do produto), processos organizacionais (gerência de projeto, adaptação do processo para gerência de projeto, análise de decisão e resolução, gerência de riscos, avaliação e melhoria do processo organizacional, definição do processo organizacional, desempenho do processo organizacional, gerência quantitativa do projeto, análise e resolução de causas, inovação e implantação na organização) e os processos de apoio (garantia de qualidade, gerência de configuração, validação, medição, verificação, treinamento). Em seguida vem a Capacidade, onde são obtidos os resultados dos processos analisados, onde cada nível de maturação possui um número definido de capacidades a serem vistas. 2.4.4 MA-MPS – Método de avaliação para melhoria do processo de software Tem como objetivo orientar a realização de avaliações, em conformidade com a norma ISO/IEC 15504, em empresas e organizações que implementaram o MR-MPS. Elaboração de guia de aquisição, desenvolvimento e aplicação de diversos cursos para capacitação, credenciamento de pessoas e instituições como implementadoras e avaliadoras, ações de disseminação para incentivo a utilização pelas empresas, e outras. 2.4.5 MN-MPS – Modelo de negócio para melhoria do processo de software Instituições que se propõem a implantar os processos MPS.Br (Instituições Implementadoras) podem se credenciar através de um documento onde é apresentada a instituição proponente, contendo seus dados com ênfase na experiência em processos de software, estratégia de implementação do modelo, estratégia para seleção e treinamento de consultores para implementação do MR.MPS, estratégia para seleção e treinamento de avaliadores, lista de consultores de implementação treinados no modelo e aprovados em prova específica, lista de avaliadores treinados no modelo e aprovados em prova específica. 2.5 Comparação do MPS.Br com o CMMI O CMMI varia do 1 ao 5 e o MPS.Br varia do G ao A, sendo que ao contrário do CMMI, o primeiro nível já exige que a empresa tenha determinados processos definidos. A escala de níveis pode ser expressa da seguinte forma [Pinto, 2006]: • G – Parcialmente Gerenciado • F – Gerenciado • E – Parcialmente Definido • D – Largamente Definido • C – Definido • B – Gerenciado Quantitativamente • A – Em Otimização Os níveis do MPS.Br também são compostos por Áreas de Processos, que são os tópicos mais importantes para um processo de desenvolvimento de software e através deles foi possível criar a seguinte tabela de equivalência dos níveis do CMMI e do MPS.Br: Figura 7 - Comparação dos Níveis de Maturidade do CMMI e do MPS.Br [Pinto, 2006] Analisando a tabela, verifica-se que os níveis do MPS.Br permitem que a empresa implante processos de uma forma mais gradual. Essa idéia refletida para o mercado brasileiro de software permite que empresas de pequeno porte, que não possuem muito dinheiro para investir em metodologias e processos, possam tomar a iniciativa de definir processos. Hoje, o MPS.Br e o CMMI em termos de qualidade de software possuem níveis equivalentes, mas com a vantagem do MPS.Br ser muito mais barato e existir financiamento do BID para grupos de empresas que desejam se certificar. 3 Avaliação Atual da Maturidade em Gerência de Requisitos de uma Organização Conforme citado na seção 1 deste trabalho, o objetivo da organização é obter melhoria nos processos sendo assim foi criado um método para avaliação e priorização dos investimentos nas ações de padronização, baseado no modelo de avaliação do MPS.BR [MPS.Br, 2007b]. Segundo o guia de implementação parte 1 [MPS.Br, 2007c] os seguintes resultados de processo são esperados para a gerência de requisitos : Resultados de Processo do MPS.BR GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos GRE2 Os requisitos de software são aprovados utilizando critérios objetivos GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida GRE4 Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos GRE5 Mudanças nos requisitos são gerenciadas ao longo do projeto Tabela 5 - Resultados de Processos Esperados para a Gerência de Requisitos Cada um destes itens será avaliado seguindo o processo descrito abaixo: O processo de avaliação interna é composto de 3 sub-processos: 1) Preparar a avaliação 2) Realizar avaliação Interna 3) Consolidar resultados da avaliação A figura abaixo ilustra os sub-processos do processo de avaliação: A tabela abaxo relaciona as atividades a serem realizadas para execução do procedimento de avaliação interna: Processo De Avaliação Interna Sub-processo Atividade Preparar a avaliação Planejar a avaliação Agendar as entrevistas Preparar as planilhas para entrevista Realizar avaliação Interna Conduzir a avaliação Registrar resultados Consolidar resultados da avaliação Organizar os resultados Consolidar as informações Priorizar os Resultados Tabela 6 - Atividades a Serem Realizadas para Execução do Procedimento de Avaliação Interna de Maturidade A figura abaixo demonstra as atividades de forma gráfica: Figura 9 - Fluxo de Atividades de Avaliação Interna de Maturidade em Gerência de Requisitos Como resultado do processo obteremos: o Os detalhes de realização de cada uma das atividades executadas pela organização o São determinados as frequências em que cada resultado do processo é obtido com as atividades das equipes o São gerados a priorização de investimentos nos resultados de processo que devem ser investidos inicialmente Durante a atividade de condução da avaliação as equipes deverão apresentar evidências do atingimento do resultado de cada resultado esperado. Serão consignados para cada resultado esperado as respostas “Sempre”, “As Vezes” e “Nunca” indicando quando se obtem o resultado nos projetos que a equipe conduz. Durante a atividade de consolidação, os resultados esperados serão ordenados pela maior quantidade de “Nunca”, depois maior quantidade de “As Vezes” e depois maior quantidade de “Sempre”. Os investimentos em melhoria de processo devem ser priorizados de acordo com a ordenação anterior (“Nunca”, “As Vezes” e “Sempre”). 4 Processos e Técnicas para a Gerência de Requisitos Este capítulo tem o objetivo de apresentar uma sugestão para implantação de processo de Gerência de Requisitos, levando em consideração as limitações e características da empresa, para atender às práticas sugeridas no nível F do MPS.Br. A tabela a seguir apresenta os resultados esperados nas práticas do MPS.Br e as atividades propostas para que os mesmos sejam atendidos: Práticas MPS.BR Resultados esperados nas práticas Atividades Propostas GRE1 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos; • Identificar os fornecedores no plano de projeto e documentar; • Realizar reuniões freqüentes sempre registradas através de atas e e-mails, sendo estes aprovados pelos fornecedores e analistas GRE2 Os requisitos de software são aprovados por meio de critérios objetivos; • Elaborar checklist para possibilitar melhor entendimento dos problemas da organização em relação à especificação de requisitos; • Realizar reuniões de kick off, onde se apresenta o projeto como um todo (incluindo seus requisitos) GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; • Confeccionar GRE3 A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; • Confeccionar cronogramas; cronogramas; cronogramas;cronogramas;cronogramas;cronogramas;cronogramas;cronogramas;