Proposta de Implementação de Qualidade de Software na Organização

Transcrição

1 Proposta de Implementação de Qualidade de Software na Organização Daniel Gonçalves Jacobsen 1 Faculdade Dom Bosco de Porto Alegre Porto Alegre RS Brasil daniel@flete.com.br Abstract. This article describes problems in the product delivered to the customer by the company I work for. Subsequently, we present the CMMI model suitable for implementation in order to solve the problems followed by a theoretical framework related to the model shown. Finally the article exposes the practices set to every problem. Resumo. Este artigo descreve problemas existentes nos produtos entregues ao cliente pela empresa em que trabalho. Posteriormente, é apresentado o modelo CMMI indicado para implantação com o intuito de sanar os problemas seguido de um referencial teórico relacionado ao modelo indicado. Por último o artigo expõe as práticas indicadas a cada problema. 1 Acadêmico do curso de Sistemas de Informação da Faculdade Dom Bosco de Porto Alegre. Consultor e Analista de Sistemas de Informação.

2 2 1. Introdução A empresa em que trabalho como Analista de Sistemas e Líder de Projetos atende nacionalmente a área de processamento e demais serviços que envolvam especificamente a área de cartões de crédito. Os clientes atendidos são bancos ou empresas financeiras que oferecem cartão de crédito. A empresa possui um sistema específico que é vendido aos clientes e modificado conforme as solicitações destes. No Rio Grande do Sul a empresa atende a dois clientes com equipes distintas, da mesma forma como faz com todos seus clientes grandes. Cada equipe possui suas próprias lideranças. Todas as equipes possuem alguns processos obrigatórios para a geração de novas versões do sistema. Estes processos englobam a padronização de nomenclaturas a serem utilizadas nos objetos de banco de dados e, basicamente, a documentação a ser entregue ao cliente juntamente com a versão do sistema. 2. Análise da Situação Atual A equipe em que trabalho atendia até um ano e meio atrás toda a parte de processamento de cartões de um cliente. Até então, a equipe era relativamente grande (cerca de 30 colaboradores) cada um com funções bem definidas. A maior parte do trabalho era o atendimento de chamados que, em sua maioria, resultavam em explicações sobre o correto funcionamento do sistema. Não eram realizadas muitas modificações no sistema. Há um ano e meio o cliente optou por passar o processamento dos cartões de crédito para outra empresa, permanecendo com a utilização do nosso sistema para boa parte de cadastramento de clientes, parametrizações e controle do processamento que passou a ser realizado pela outra empresa. Ocorreu que durante alguns meses a equipe ficou sem projetos a empresa optou por desligar a maior parte dos colaboradores, pois não tinha a garantia de que ali na frente haveriam projetos que comportassem tamanha equipe. Quando os novos projetos surgiram, foram contratados novos colaboradores. Os novos projetos demandavam diversas modificações ao sistema que, conforme citado anteriormente, antigamente pouco era alterado. Como havia pouco tempo para as entregas dos novos projetos, as modificações começaram a ser realizadas buscando entregar os projetos no menor tempo possível em vista de que novos projetos foram sendo contratados exponencialmente por questões acordadas com o cliente.

3 3 Problemas relacionados a qualidade das entregas vêm sendo encontrados nos projetos entregues ao cliente. Embora as alterações do sistema que a empresa em que trabalho dá suporte para o cliente não possa ser modificado por outra empresa, o cliente está solicitando algumas cláusulas contratuais para garantir a qualidade dos projetos entregues. Além disso, sabe-se que as entregas com qualidade abaixo da esperada pelo cliente diminuem as chances da criação de novos projetos que não sejam específicos para o nosso sistema. Dentre os problemas podemos listar o que segue: 1. Projetos entregues com funcionalidades inadequadas ao que fora solicitado; 2. Detalhes como mensagens de alerta, ordenação de colunas e descrição de labels recebem solicitações de alteração quando o projeto já se encontra em homologação; 3. Projetos entregues fora do prazo. 3. Modelo indicado Embora a equipe da empresa em que trabalho possua uma quantidade de colaboradores que pode ser considerada pequena (22 colaboradores), os projetos que vem sendo contratados pelo cliente vem gerando faturamento e lucro que não podem ser considerados como de pequenas ou médias empresas. Além disso, está sendo considerado somente uma equipe da empresa como um todo. Pode-se dizer que a solução proposta poderá ser passada para as demais equipes com o tempo. Portanto, a proposta indicada será a implantação do CMMI nível 2, que é o primeiro a ser implantado. 4. Referencial Teórico O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas. Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas [WIKIPÉDIA, 2013]. O modelo CMM foi concebido para atender a uma demanda do Departamento de Defesa Norte-Americano, que necessitava de um mecanismo objetivo para avaliar seus

4 4 fornecedores de software. Entretanto, o CMM, e mais recentemente o CMMI, tornaram-se um padrão de mercado para mensurar a capacidade de entrega e a maturidade das empresas fornecedoras de software e serviços. Os modelos são representações simplificadas do mundo real. Os modelos de maturidade de capacitação (Capability Maturity Models - CMMs) possuem os elementos essenciais de processos eficientes para uma ou mais áreas de conhecimento. Estes modelos fornecem direcionamentos a serem utilizados no desenvolvimento de processos. Processos são pontos de apoio da melhoria sustentada de uma organização [CHRISSIS, 2003]. O CMMI está dividido em cinco níveis de maturidade: Nível 1 Inicial - Imaturidade Organizacional. o Processos são improvisados e geralmente não são seguidos; o Compromissos de prazo e custo não são cumpridos; o O planejamento não é feito com base em estimativas; o As qualidades, procedimentos e conhecimentos pertencem às pessoas e não aos projetos; o As chances de sucesso dependem das habilidades pessoais dos gerentes e desenvolvedores. Nível 2 Gerenciado. o Políticas e procedimentos para gerenciar o desenvolvimento de software estão definidas e são obedecidas; o O planejamento é baseado em estimativas e na experiência anterior de outros projetos; o Os projetos utilizam processos definidos, usados, disseminados, documentados, medidos e fiscalizados com rotinas de melhoria; o Os processos afetados são puramente gerenciais (não técnicos) e pertencem aos projetos e não às pessoas. Nível 3 Definido. o Os processos utilizados são estabelecidos e padronizados em toda a organização; o Processos técnicos passam a ser considerados ao lado dos processos gerenciais; o Tanto os processos gerenciais quanto os técnicos passam a ser repetidos; o Os processos pertencem a organização e não mais aos projetos.

5 5 Nível 4 Quantitativamente Gerenciado. o São estabelecidas metas quantitativas para os processos e produtos; o Medidas de qualidade e produtividade são coletadas em todos os projetos; o É estabelecido controle estatístico de processos; o A gestão passa a ser feitas com bases quantitativas. Nível 5 Otimização. o A organização está engajada na melhoria contínua de seus processos; o Identificação de pontos fracos e defeitos; o Ações preventivas sobre causas; o Mudanças mais significativas de processos e/ou tecnologias são feitas a partir de análise de custo/benefício com base em dados quantitativos. No nível de maturidade 2, estão contempladas as áreas de processos descritas abaixo. Este trabalho irá se ater apenas ao nível 2 em virtude de ser o escolhido para indicação aos problemas identificados [CHRISSIS, 2003]. Gerenciamento de Requisitos (Requirements Management) o Esta área objetiva gerenciar os requisitos dos produtos e componentes de produtos do projeto identificando as inconsistências entre estes requisitos e os planos e os produtos de trabalho do projeto. Planejamento do Projeto (Project Planning) o Esta área objetiva estabelecer e manter planos que definem as atividades do projeto. Monitoramento e Controle do Projeto (Project Monitoring andcontrol) o Esta área objetiva oferecer um entendimento do progresso do projeto, de maneira que as ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto se desviar significativamente do plano. Gerenciamento de Acordos com Fornecedores (Supplier AgreementManagement) o Esta área objetiva gerenciar a aquisição de produtos de fornecedores para os quais existe um acordo formal. Medições e Análises (Measurement and Analysis) o Esta área objetiva desenvolver e sustentar a capacidade de medições que é utilizada para suportar as necessidades de gerenciamento de informações.

6 6 Garantia da Qualidade do Processo e do Produto (Process andproduct Quality Assurance) o Esta área objetiva fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Gerenciamento de Configurações (Configuration Management) o Esta área objetiva estabelecer e manter a integridade dos produtos de trabalho, utilizando a identificação da configuração, controle da configuração, comunicação do status da configuração e auditorias de configurações. 5. Solução Proposta A Solução proposta é a implantação do nível 2 de maturidade do CMMI. Abaixo serão descritos os sub níveis, metas e práticas indicadas para solucionar os problemas. Serão abordadas as práticas necessárias para sanar os problemas identificados. As práticas que não se enquadram entre os problemas ou que já são realizadas não serão abordadas Gerenciamento de Requisitos O sub nível Gerenciamento de Requisitos indica que devem ser gerenciados todos os requisitos recebidos ou gerados pelo projeto. Os requisitos devem ser revisados com o cliente para resolver questões e prevenir o mau entendimento, antes que os requisitos sejam incorporados aos planos do projeto. Uma vez que o fornecedor e o receptor dos requisitos cheguem a um acordo, é obtido um compromisso dos participantes do projeto sobre os requisitos. O projeto gerencia as mudanças feitas nos requisitos conforme eles evoluem e identifica quaisquer inconsistências que ocorram entre planos, produtos de trabalho e requisitos. Parte do gerenciamento de requisitos é documentar as mudanças nos requisitos e suas justificativas, e manter a rastreabilidade bidirecional entre os requisitos fonte e todos os requisitos de produtos e componentes de produtos. A implantação deste sub nível atenderá aos problemas 1 e 2. A prática específica SP1.1 Obter um Entendimento dos Requisitos referente a meta específica SG1 Gerenciar Requisitos auxilia no desenvolvimento de um entendimento com os fornecedores dos requisitos sobre o significado de todos os requisitos. Esta prática define que devem ser estabelecidos critérios para determinar os canais apropriados ou fontes oficiais para

7 7 recepção dos requisitos. Os requisitos devem ser analisados juntamente com o fornecedor destes visando o correto entendimento. O resultado desta análise é um conjunto de requisitos acordados. Esta prática auxiliará na solução dos problemas 1 e 2, pois deixará claro entre as partes os requisitos que deverão ser atendidos [CHRISSIS, 2003]. A prática específica SP1.2 Obter Compromissos com os Requisitos referente a meta específica SG1 Gerenciar Requisitos trata dos acordos e compromissos entre as pessoas que executarão as atividades de implementação dos requisitos. Esta prática assegura que a evolução dos requisitos seja identificada por todos os participantes do projeto e que estes se comprometam tanto com os requisitos atuais aprovados quanto com as mudanças ocorridas. Esta prática auxiliará na solução dos problemas 1 e 2, pois resulta no comprometimento dos envolvidos [CHRISSIS, 2003]. A prática específica SP1.3 Gerenciar as Mudanças de Requisitos referente a meta específica SG1 Gerenciar Requisitos trata do essencial gerenciamento de acréscimos e mudanças de requisitos. Faz-se necessário que a fonte de cada um dos requisitos seja conhecida e que a justificativa de cada mudança seja documentada e acordada. Esta prática auxiliará na solução dos problemas 1 e 2 garantindo que as mudanças de requisitos serão devidamente avaliadas e gerenciadas [CHRISSIS, 2003]. A prática específica SP1.4 Manter a Rastreabilidade Bidirecional de Requisitos referente a meta específica SG1 Gerenciar Requisitos trata de manter a rastreabilidade bidirecional dos requisitos para cada nível de decomposição do produto. Quando os requisitos são bem gerenciados, a rastreabilidade pode ser estabelecida, desde um requisito fonte até seus requisitos de mais baixo nível e destes de volta para o seu requisito fonte. Tal rastreabilidade bidirecional auxilia a determinar se todos os requisitos fonte foram completamente tratados e se todos os requisitos de mais baixo nível podem ser rastreados para uma fonte válida. A rastreabilidade é particularmente necessária na condução da análise do impacto de mudanças de requisitos nos planos do projeto, atividades e produtos de trabalho. Esta prática auxiliará na solução dos problemas 1 e 2 possibilitando que sejam identificadas as mudanças nos requisitos e seus detalhes [CHRISSIS, 2003].

8 Planejamento do Projeto O sub nível Planejamento do Projeto inclui estimar os atributos dos produtos de trabalho e tarefas, determinar os recursos necessários, negociar compromissos, produzir um cronograma e identificar e analisar os riscos do projeto. Iterações destas atividades podem ser necessárias para estabelecer o plano do projeto. O plano do projeto fornece a base para a execução e controle das atividades de projeto que tratam dos compromissos com o cliente do projeto. O plano do projeto normalmente precisará ser revisado, conforme o projeto evolui, para tratar mudanças nos requisitos e compromissos, estimativas imprecisas, ações corretivas e mudanças no processo. O termo plano do projeto é utilizado em todas as práticas genéricas e específicas desta área de processo para se referir ao plano geral de controle do projeto. A implantação deste sub nível atenderá ao problema 3. A prática específica SP2.2 Identificar os Riscos do Projeto referente a meta específica SG2 Desenvolver um Plano de Projeto envolve a identificação de potenciais questões, perigos, ameaças, vulnerabilidades, etc que podem afetar negativamente os esforços de trabalho e planos. Os riscos devem ser identificados e descritos de uma forma compreensível, antes que possam ser analisados. Esta prática auxiliará a solução do problema 3, induzindo a uma melhor avaliação do tempo necessário para a implementação [CHRISSIS, 2003] Monitoramento e Controle do Projeto Tão importante quanto planejar o projeto é realizar o seu monitoramento. Este sub nível indica o que é necessário para monitorar o projeto. O progresso deve ser determinado pela comparação dos atributos reais de produtos de trabalho e tarefas, esforço, custo e cronograma com o que foi planejado. A visibilidade apropriada possibilita a ação corretiva pontual a ser tomada quando o desempenho desvia significativamente do plano. Um desvio é significativo se, quando deixado sem resolução, impede que o projeto atinja seus objetivos. Quando o status real se desvia significativamente dos valores esperados, as ações corretivas são tomadas conforme apropriado. Estas ações podem exigir o replanejamento, que pode incluir a revisão do plano original, estabelecimento de novos acordos ou inclusão de atividades de mitigação de riscos adicionais dentro do plano atual. Este sub nível, juntamente com o sub nível de Planejamento do Projeto atenderá ao problema 3 [CHRISSIS, 2003].

9 9 A prática específica SP1.2 Monitorar Compromissos referente a meta específica SG1 Monitorar o Projeto Contra o Plano envolve uma revisão regular para identificar se os compromissos externos e internos estão sendo cumpridos ou correm o risco de não serem cumpridos. Esta prática auxiliará a solução do problema 3 forçando um gerenciamento mais efetivo quanto os compromissos que afetam as entregas [CHRISSIS, 2003]. A prática específica SP1.3 Monitorar os Riscos do Projeto referente a meta específica SG1 Monitorar o Projeto Contra o Plano define que os riscos previamente identificados deve ser monitorados periodicamente e a documentação deve ser revisada, conforme novas informações que surgirem, para que as mudanças sejam incorporadas. Esta prática auxiliará também na solução do problema 3, pois permite um controle maior sobre os possíveis riscos que podem impactar nas entregas [CHRISSIS, 2003].

10 10 Referências Bibliográficas WIKIPÉDIA. "CMMI". Disponível em: < >. Acessado em 17 de Junho de CHRISSIS, Mary B.; KONRAD M.; SHRUM S. CMMI: Guidelines for Process Integration and Product Improvement. SEI, Addison Wesley, 2003.