A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O DESENVOLVIMENTO DE SISTEMAS

Transcrição

1 UNIVERSIDADE POSITIVO PRÓ-REITORIA DE PÓS-GRADUAÇÃO, PESQUISA E EXTENSÃO CURSO DE ESPECIALIZAÇÃO EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO PROJETO DE TRABALHO DE CONCLUSÃO DE CURSO A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O DESENVOLVIMENTO DE SISTEMAS CLÉVERSON TRAJANO PRÉCOMA PORTES DYONATA LAITENER RAMOS CURITIBA 2011

2 CLÉVERSON TRAJANO PRÉCOMA PORTES DYONATA LAITENER RAMOS A INTERAÇÃO DA QUALIDADE DE SOFTWARE COM O DESENVOLVIMENTO DE SISTEMAS Projeto de especialização apresentado ao Programa de Especialização em Gestão da Tecnologia da Informação Orientador: Anderson Ravanello. CURITIBA 2011

3 SUMÁRIO ÍNDICE DE FIGURAS 5 ÍNDICE DE TABELAS 6 1. INTRODUÇÃO 7 2. O QUE É QUALIDADE? 7 3. PROPÓSITO DA GARANTIA DA QUALIDADE DE SOFTWARE Histórico O Propósito 9 4. MPS.BR Modelo de Referência Modelo de Avaliação Modelo de Negócio CMMI INTRODUÇÃO A PESQUISA PÓS IMPLANTAÇÃO DO PROCESSO DE QUALIDADE CMMI MPS.BR APLICAÇÃO DOS QUESTIONÁRIOS Pré Implantação de Processo de Qualidade Pós Implantação de Processo de Qualidade CONCLUSÃO REFERÊNCIAS ANEXOS RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS 27

4 11.2. RESPOSTAS QUESTIONÁRIO EMPRESA E-GOVERNE RESPOSTAS QUESTIONÁRIO EMPRESA GUENKA RESPOSTAS QUESTIONÁRIO EMPRESA NVI 33

5 ÍNDICE DE FIGURAS Figura 1 - Componentes do modelo MPS 10 Figura 2 - Variação Desempenho das 65 Empresas que Adotaram o MPS e Participaram da Pesquisa Periódica imps em 2009 e Figura 3 - Variação de Desempenho das 11 Empresas com MPS que Revalidaram/Mudaram de Nível entre 2009 e Figura 4 - Variação de Desempenho de 42 Empresas com a Evolução no Modelo MPS entre 2008 e

6 ÍNDICE DE TABELAS Tabela 1 - Níveis de maturidade MPS 13

7 1. INTRODUÇÃO Atualmente vivenciamos um período na sociedade em que em todas as áreas estão focando cada vez mais em processos de qualidade, principalmente para o constante desenvolvimento de produtos/serviços para fins empresarias. As empresas estão buscando por processos e gestão da qualidade não mais como estratégias de diferenciação de mercado, mas sim como uma condição de preexistência neste mercado voraz e competitivo. Esta busca também é orientada com objetivos específicos para a implantação dos processos de qualidade nas organizações, estes objetivos são especificamente: gerenciar a lucratividade e os recursos; gerenciar riscos; gerenciar e manter orçamentos, programações e qualidade; obter dados para melhoria do processo. Porem esta tendência do mercado da implantação de processos de qualidade esta trazendo a chamada melhoria continua para as organizações, a gestão dos processos esta acontecendo, as medições realizadas, em geral o processo de qualidade esta realmente modificando os processos das organizações? Os seus objetivos vêm alcançando os resultados esperados? Além de responder as perguntas acima este artigo pretende demonstrar a importância dos processos para a geração de um produto com qualidade e também nas questões relacionadas a custo, gestão de recursos, aquisição de novos clientes e também um retrato da situação atual de diversas empresas antes de um processo de qualidade de software definido e após a implantação e aplicação de um modelo de qualidade de processo de software. Apresentaremos inicialmente dois modelos de qualidade o CMMI e o MPS.BR, que embora não façam parte do escopo deste artigo mais são de uma grande importância possuir um pequeno conhecimento do que cada modelo propõe para uma boa gestão de qualidade. 2. O QUE É QUALIDADE? Esta é a primeira pergunta que deve ser feita quando esse assunto é mencionado! Qualidade é, segundo a Sociedade Americana de Qualidade, "O grau até o qual um conjunto de características inerentes satisfaz as necessidades esperadas".

8 Um conceito moderno de qualidade diz que é importante: - A Satisfação do cliente: entendimento, avaliação, definição e gerenciamento de expectativas de forma a atender às necessidades do cliente. Isso exige uma combinação de conformidade com os requisitos (o projeto deve produzir o que afirmou que produziria) e adaptação ao uso. - Prevenção sobre Inspeção (Auditoria): o custo de prevenção de erros em geral é muito menor que o custo de corrigi-los, conforme revelado pela inspeção. - Responsabilidade da gerência: o sucesso exige a participação de todos os membros da equipe, mas é sempre responsabilidade da gerência fornecer os recursos necessários para que exista sucesso. - Melhoria contínua: o ciclo PDCA é a base da melhoria da qualidade: Plan (Planejar), Do (Fazer), Check (Verificar), Act (Atuar). Para os Modelos de Maturidade de Processos de Software CMMI e MPS.BR, qualidade é: "O grau no qual um sistema, componente ou processo satisfaz os requisitos especificados e as necessidades e expectativas do cliente ou usuário. Com base nestas definições de qualidade pode-se dizer, então que a Garantia da Qualidade "envolve um conjunto de atividades voltadas para avaliar o processo pelo qual os produtos são desenvolvidos ou manufaturados, visando fornecer confiança necessária de que estes estejam em conformidade com os requisitos técnicos especificados". 3. PROPÓSITO DA GARANTIA DA QUALIDADE DE SOFTWARE 3.1. Histórico A garantia da qualidade é uma atividade fundamental para qualquer negócio que gera produtos usados por outros. A primeira função formal de controle e garantia da qualidade foi introduzida nos Laboratórios Bell em 1916 e espalhou-se pelo mundo da manufatura. A história da garantia da qualidade no desenvolvimento de software ocorre paralelamente à história da qualidade na fabricação do hardware, entretanto, padrões de garantia da qualidade de software somente foram introduzidos na década de 70.

9 As necessidades e requisitos a serem tratados pelo software são cada vez mais críticos. Os sistemas são desenvolvidos para atender atividades das quais dependem milhares de pessoas ou até milhares de vidas. Hospitais, Tráfego Aéreo, Usinas de Energia, Mercado Financeiro, Comércio Interno e Internacional, Governos, Indústrias etc. são aplicações entre milhares que não podem ser tiradas de operação, pois não há como substituídas. Diante deste quadro é fácil entender porque a preocupação das organizações e dos próprios desenvolvedores de software em desenvolver aplicações com qualidade O Propósito O propósito da Garantia da Qualidade de Software é fornecer aos vários níveis de gerência, adequada visibilidade dos projetos, dos processos de desenvolvimento e dos produtos gerados. A Garantia da Qualidade de Software atua como "guardião", fornecendo um retrato do uso do Processo e não é responsável por executar testes de software. Obtendo a visibilidade desejada, a gerência pode atuar de forma pontual no sentido de atingir os quatro grandes objetivos de um projeto de desenvolvimento de software: Desenvolver software de alta qualidade; Ter alta produtividade da equipe de desenvolvimento; Cumprir o cronograma estabelecido junto ao cliente; Não necessitar de recursos adicionais não previstos.

10 4. MPS.BR Com o objetivo de favorecer e estimular principalmente a micro, pequena e média empresa brasileira de produção de software a um custo acessível, foi criado, em 2003, o projeto MPS-BR. É um projeto de Melhoria do Processo de Software Brasileiro, coordenado pela SOFTEX(Sociedade para Promoção da Excelência do Software Brasileiro), e composto por mais sete instituições brasileiras com competências na melhoria de processos de software. São elas: COPPE/UFRJ, CESAR, CenPRA, CELEPAR, ABNT, Sociedade Núcleo de Apoio à Produção e Exportação de Sotware do Rio de Janeiro RIOSOFT e Sociedade Núcleo SOFTEX 2000 de Campinas. A estrutura do modelo MPS-BR foi fundamentada com base em outros modelos e padrões já existentes, adaptando para a realidade brasileira. O ponto de partida para a definição foi à norma ISSO/IEC [2], a série de normas ISSO/IEC (SPICE) [3] e o modelo CMMI (Capability Maturity Model Integration) [4]. O modelo MPS está dividido em três (3) componentes (Figura 1): Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN- MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo MPS [1]. Figura 1 - Componentes do modelo MPS 4.1. Modelo de Referência Contém os requisitos que os processos das empresas devem atender para estar em conformidade com o modelo. Está definido em níveis de maturidade que são uma combinação entre processos e sua capacidade.

11 A definição dos processos segue os requisitos para um modelo de referência de processo apresentados na ISO/IEC , declarando o propósito e os resultados esperados de sua execução [1]. Cada nível de maturidade é uma junção entre processos e capacidade dos processos, ou seja, é composto por um conjunto de processos em um determinado nível de capacidade [5]. São definidos sete (7) níveis de maturidade para o modelo: A(Em Otimização), B(Gerenciado Quantitativamente), C(Definido), D(Largamente Definido), E(Parcialmente Definido), F(Gerenciado) e G(Parcialmente Gerenciado) Modelo de Avaliação O objetivo do modelo de Avaliação é verificar a maturidade da empresa na execução de seus processos de software. Descreve um conjunto de atividades e tarefas a serem cumpridas para atingir este propósito. Segundo [6], o Processo e o Método de Avaliação MA-MPS foram definidos de forma a: Permitir a avaliação objetiva dos processos de software de uma organização/unidade organizacional; Permitir a atribuição de um nível de maturidade do MR-MPS com base no resultado da avaliação; ser aplicável a qualquer domínio na indústria de software; Ser aplicável a organizações/unidades organizacionais de qualquer tamanho. O processo de avaliação é dividido em quatro (4) sub processos: 1. Contratar a avaliação; 2. Preparar a realização da avaliação; 3. Realizar a avaliação final; 4. Documentar os resultados da avaliação; Como resultado da execução deste processo:

12 São obtidos dados e informações que caracterizam os processos de software da organização/unidade organizacional; É determinado o grau em que os resultados esperados são alcançados e os processos atingem o seu propósito; É atribuído um nível de maturidade do MR-MPS à organização/unidade organizacional. A avaliação é válida por um período de três (3) anos a contar da data em que a avaliação final foi concluída com a empresa avaliada Modelo de Negócio Este modelo descreve as regras de negócio para implementação do MR-MPS. Para cada nível de maturidade há um guia que detalha os processos existentes que são descritos em termos de atributos de processo (AP). O atendimento destes atributos é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP). A seguir um resumo dos níveis de maturidades, seus processos associados e atributos de processo a ser atingido (Tabela 1):

13 Tabela 1 - Níveis de maturidade MPS 5. CMMI Capability Maturity Model Integration (CMMI) é uma abordagem de melhoria de processo que ajuda as organizações a melhorarem seu desempenho. CMMI pode ser utilizado para orientar a melhoria do processo através de um projeto, uma divisão, ou uma organização inteira. CMMI em engenharia de software e desenvolvimento organizacional é uma abordagem de melhoria de processo que fornece às organizações os elementos essenciais para a melhoria de processos eficazes. CMMI é registrada no Patent and Trademark Office EUA pela Carnegie Mellon University. Segundo o Software Engineering Institute [7], CMMI ajuda integrar funções organizacionais tradicionalmente separadas, gols processo de melhoria e definir prioridades, fornecer orientações para processos de qualidade, e fornecer um ponto de referência para a avaliação de processos em curso".

14 6. INTRODUÇÃO A PESQUISA Há cerca de alguns anos, o mercado que podemos intitular como indústria de software, era ainda um nicho pequeno com poucas empresas, poucos produtos e com algumas grandes empresas se destacando. Com o passar dos anos, o aumento da tecnologia, da dependência do ser humano e de processos computacionais o cenário mudou significativamente obrigando as empresas a mudarem seus paradigmas e investirem na otimização de fatores como custo, tempo e qualidade. Porem com esse aumento significativo da demanda do mercado muitas empresas não estavam preparadas para receber tantos projetos ao mesmo tempo e trabalhar cada vez mais com um número menor de pessoas em cada projeto, com isso formou-se um cenário onde existia uma grande falha no processo de desenvolvimento de software com empresas que não estavam capacitadas em prestar este serviço juntamente com um processo de qualidade de produto. Com relação à afirmação acima foi realizada uma pesquisa [11], onde foi possível ter uma visão da imaturidade das indústrias de software através dos seguintes indicadores: Mais de 30% dos projetos são cancelados antes de serem finalizados. Mais de 70% dos projetos falham nas entregas das funcionalidades esperadas. Os custos extrapolam em mais de 180% os valores originalmente previstos. Os prazos excedem mais de 200% os cronogramas iniciais. Para que esse cenário seja alterado é necessário que as organizações estejam apoiadas em modelos de processo organizacionais focados em qualidade de processo e também em qualidade de desenvolvimento. Citando estes modelos podemos novamente voltar a falar em CMMI e MPS.BR que foram explanados anteriormente e alguns frameworks de desenvolvimento de software como SCRUM e XP. Citamos anteriormente ambos os modelos de qualidade e otimização de desenvolvimento de software, pois a qualidade do produto está diretamente relacionada à qualidade do processo de desenvolvimento. Desta forma, é comum que a busca por um software de maior qualidade passe pela estruturação e implantação de um processo de qualidade de desenvolvimento de software.

15 É importante que se procure melhorar a qualidade do produto, mas devemos nos preocupar de forma mais ampla em melhorar a qualidade de trabalho, de serviço, de informação, de processo e de pessoal. Enfim é necessário adequar um processo de qualidade de processo juntamente com o desenvolvimento pessoal da equipe de forma a se buscar uma melhoria continua do processo de produção de software com o objetivo focado em qualidade de produto, diminuição de custos, e economia de tempo. 7. PÓS IMPLANTAÇÃO DO PROCESSO DE QUALIDADE Com base nas premissas que foram apresentadas anteriormente as empresas deste setor buscaram implantar processos certificados que pudessem garantir uma melhoria continua em seus processos e em consequência aumentar a qualidade do processo e produto final para os seus clientes. Para isso foram utilizados os modelos que já foram explanados neste documento, sendo eles: CMMI e MPS.BR. O que iremos apresentar agora é um relato sobre os resultados de melhoria de processos baseadas nestes modelos. Os resultados foram obtidos através de apresentações em conferencias públicas, artigos publicados e colaborações individuais. Juntos, estes resultados fornecem a prova de conceito sobre o potencial de melhoria dos modelos apresentados CMMI Iremos apresentar agora como estão algumas empresas que implantaram o CMMI em seus processos e conseguiram coletar métricas de como as suas organizações se encontravam na época anterior a implantação do processo de qualidade e após a obtenção no nível mais elevado do modelo de qualidade de software.

16 Lembrando que apenas a decisão de implantar o CMMI em sua organização não é o suficiente, é preciso fazer uma boa definição de processos, utilizar o novo processo, contabilizar e medir os resultados, e fazer a melhoria continua com base nas lições aprendidas e das métricas que foram coletadas dentro de cada projeto. Os resultados [8] obtidos foram baseados nos resultados de 2010 de seis organizações de defesas, sendo elas: Raytheon, Harris, Northrop Grumman, AIS, Armament SEC, Lockeed Martin. Os resultados foram divulgados em uma pesquisa realizada pelo Software Engineering Institute Carnegie Mellon University, e apresentado em Maio de Os resultados apresentados são o comparativo do pré e pós implantação do processo de qualidade em empresas que possuíam um nível 3 do CMMi e adquiriram o nível 5 no ano de Entregas no prazo aumentaram em 5%. Diminuição de erros e retrabalho em mais de seis vezes. Esta contagem foi realizada no inicio da fase de testes dos sistemas, este ganho de seis vezes menos erros nos sistemas representa de 5-6 meses de ganho no cronograma dos projetos, considerando um projeto grande. Diminuição em cerca de 58% em horas trabalhadas para corrigir erros nos sistemas. Os custos dos projetos reduziram cerca de 28%. Aumento de 85% na remoção prévia de erros, antes do inicio da fase de testes. Aumento de 42% da produtividade das organizações. Aumento de 50% na satisfação do cliente com o processo e produto entregue Redução das horas extras e pressão interna nos projetos Diminuição do replanejamento do escopo do projeto. Diminuição com horas de treinamento, a documentação do processo habilita o processo de transferência do conhecimento para novos membros das organizações. Retenção da mão de obra e satisfação da equipe de trabalho.

17 7.2. MPS.BR Para avaliação de empresas que implantaram o modelo MPS foi utilizado como base o documento imps 2010 [9] que relata o desempenho de empresas certificadas no MPS.BR. Nesta análise foram utilizados os seguintes indicadores: A) Variação do faturamento B) Número de clientes no país C) Número de funcionários D) Custo médio dos projetos E) Prazo médio dos projetos F) Tamanho médio dos projetos G) Produtividade H) Qualidade I) Retorno do investimento para implementação e avaliação do modelo Neste trabalho iremos analisar somente os indicadores A, D, G, H e I por refletirem melhor nosso objetivo. Figura 2 - Variação Desempenho das 65 Empresas que Adotaram o MPS e Participaram da Pesquisa Periódica imps em 2009 e 2010

18 Pela Figura 2 pode-se observar uma tendência de aumento no Faturamento nas empresas entre 2009 e Isto pode ser explicado por outro indicador, o Custo Médio dos Projetos, onde houve uma redução significativa do mesmo para a maioria das empresas entre as avaliações. No indicador de Produtividade percebe-se uma redução ou manutenção nos resultados medidos. Isto pode ser explicado pelo controle mais rigoroso no processo de desenvolvimento que o próprio MPS exige na definição dos mesmos. Quanto ao retorno do investimento, apenas 14% relataram que não obtiveram retorno algum. O restante das empresas afirmou já ter obtido algum ou todo o retorno investido na implantação do processo de qualidade. Além disso, deve ser feito uma investigação mais precisa para entender se estas empresas foram avaliadas recentemente, o que impediria obter este retorno. O indicador Qualidade, que nesta avaliação é medido em termos de capacidade de encontrar defeitos (número de defeitos / unidade de tamanho do software), mostra uma pequena tendência de aumento. Porém, entre os indicadores, este é o que se obteve menor número de respostas entre as empresas e consequentemente possui o menor nível de confiança do resultado. Figura 3 - Variação de Desempenho das 11 Empresas com MPS que Revalidaram/Mudaram de Nível entre 2009 e 2010

19 Outra análise foi realizada entre as empresas avaliadas entre 2009 e 2010 que mudaram ou revalidaram seus níveis de maturidade como mostra a figura 3. Nesta análise pode ser visto um aumento ou manutenção do faturamento entre as empresas, nenhuma obteve redução neste indicador. É possível observar também redução em custos e prazos o que pode ser explicado pela redução no tamanho dos projetos e reflexo da adoção de práticas e controles que a adoção de um processo de maturidade exige. Neste gráfico não podemos tirar uma conclusão sobre o indicador qualidade devido poucas empresas terem respondido e ao baixo nível de confiança. Figura 4 - Variação de Desempenho de 42 Empresas com a Evolução no Modelo MPS entre 2008 e 2010 Consolidando a tendência de melhoria dos resultados com a implantação de um modelo de qualidade, foram verificados os dados entres as empresas que evoluíram no modelo entre 2008 e 2010 e tiveram todos os questionários respondidos no período. Como pode ser visto no gráfico da figura 4 a tendência de melhora nos indicadores é verificada pelo aumento de faturamento, número de clientes, funcionários e redução do custo médio dos projetos.

20 8. APLICAÇÃO DOS QUESTIONÁRIOS Para fundamentar ainda mais os resultados obtidos e explanados no tópico anterior este projeto ainda irá apresentar questionários que foram realizados com empresas que implantaram recentemente um modelo de qualidade. Como forma de demonstrar as principais alterações que sofrem os processos internos das organizações pré e pós implantação de um modelo de qualidade foram realizadas doze perguntas a quatro organizações diferentes. Estas perguntas foram formalizadas para representar as principais alterações que uma organização identifica com a melhoria continua e definição de processos com base em um modelo de qualidade. A seguir é possível verificar uma visão geral que as quatro organizações partilharam em seus questionários Pré Implantação de Processo de Qualidade 1. Como era o processo de gerenciamento de projetos? No geral não havia um processo definido. 2. Como era feita a estimativa de prazos dos projetos? Na maioria dos casos a estimativa era feita com base na experiência dos gerentes do projeto e da equipe técnica, somente uma das empresas estimava prazos com a técnica de UCP (Use Case Point). 3. Como era feito o controle das alterações de escopo dos projetos? No geral não havia um controle sobre as alterações e nem como medir o impacto destas alterações no escopo. 4. Como era feita a estimativa de custos dos projetos? Nas empresas que a realizavam a estimativa era feita com base na experiência dos profissionais envolvidos ou no calculo entre o número de horas planejado pelos recursos utilizados no projeto, uma vez que o planejamento de

21 horas também era realizado com base na experiência teríamos aqui uma estimativa de custos que muitas vezes ficava longe do real custo do projeto. 5. Como era a satisfação do cliente com o processo e os produtos entregues? Não havia um processo definido para a medição da satisfação do cliente, porém as empresas alegaram que recebiam muitas reclamações referentes aos erros que continham no produto final. Com isso podemos entender que mesmo entregando o produto no prazo a qualidade do mesmo era questionada pelo cliente. 6. Como era feita a documentação na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Não existia um padrão de documentação entre os projetos das organizações, as informações poderiam ser passadas desde um documento Word até de forma informal, uma conversa entre Analista e Desenvolvedor. A não definição de um padrão ocasionava muitos erros nos projetos e um retrabalho muito grande, o que impactava diretamente no prazo e custo do projeto Pós Implantação de Processo de Qualidade 1. Como é o atual processo de gerenciamento de projetos? Em todos os casos foram definidos planos de projetos, aonde são mapeadas todas as fases do projeto, quem serão os responsáveis, uma definição clara do escopo, plano de riscos, matriz de rastreabilidade de requisitos, plano de testes, plano de comunicação, cronograma. No geral o plano de projeto contempla todas as definições do projeto, contemplando todas as fases e definindo todos os processos que serão realizados e inclusive já prevenindo os riscos que possam ocorrer no decorrer do projeto. O Plano de projeto foi criado para que os projetos sejam muito bem definidos já na sua fase de negociação e planejamento e que é utilizado para a definição dos novos projetos e manutenção dos já existentes.

22 2. Como é feita a estimativa de prazos dos projetos? Cada empresa seguiu para uma linha de estimativa, seja pelo calculo de UCP ou seja por uma planilha definida internamente com variáveis que sejam de suma importância para o calculo de horas do projeto. O importante é que foi definido um processo de qualidade e quantificado por fatores que agregam valor para uma estimativa de prazo coerente. O mais importante é que a estimativa de prazos afeta diretamente no cronograma, pois com uma estimativa de qualidade o cronograma do projeto passa a ser bem mais realista e fundamentado para uma estimativa muito próxima do real. 3. Como são gerenciadas as alterações de escopos dos projetos? No geral agora toda mudança é previamente analisada pelos responsáveis do projeto, verifica-se qual é o tipo da alteração, verifica-se o impacto desta alteração no escopo, isto caso a organização possua uma matriz de rastreabilidade dos artefatos e por fim obtêm-se a aprovação do cliente para tal alteração já considerando as mudanças no custo e prazo do projeto. Após todo este processo de análise são realizadas as devidas alterações no escopo e no cronograma, somente após estes procedimentos é iniciada a fase de desenvolvimento das alterações necessárias. 4. Como é realizada a estimativa de custos dos projetos? Agora as organizações têm processos definidos para estimativa do custo com base nos recursos envolvidos e nas horas que cada recurso irá trabalhar no projeto. Algumas organizações também levam em consideração os recursos tecnológicos que serão utilizados assim como todos os treinamentos, viagens e até mesmo custos de implantação e despesas indiretas (administrativas). 5. Como é medida a satisfação do cliente com o processo e os produtos entregues? Na maioria dos casos ainda não possui um processo definido de medição. Algumas empresas fazem esta medição através da diminuição das reclamações de erros nos sistemas, que podemos salientar que diminuíram

23 consideravelmente possibilitando ainda a aquisição de novos contratos de projetos com os mesmos clientes. 6. Qual é a padronização de documento na qual um Analista de Sistemas envia para um programador desenvolver um requisito no projeto? No geral as empresas agora estão utilizando UML (Unified Modeling Language), como diagrama de classes, especificação de casos de uso, modelo de testes, protótipos e modelo de dados. Estes documentos diminuíram consideravelmente os erros de sistema, o re-trabalho e ainda foi possível aumentar a produtividade da equipe técnica após passar a curva aprendizado do novo processo. Algumas organizações ainda possuem revisores destes documentos, o que diminui ainda mais a ocorrência de erros nos sistemas. 9. CONCLUSÃO Com este trabalho verificou-se que a percepção e constatação de que a implantação de um processo de qualidade de software proporciona melhoria no produto final é cada vez mais evidente. Isto se reflete na quantidade de empresas que vem adotando um padrão de qualidade. A concorrência e as exigências do mercado estão obrigando as empresas a se enquadrar em um novo modelo de desenvolvimento de software, que é o desenvolvimento através de um processo bem definido, alcançando assim o que chamamos de processo de qualidade de software. O que identificamos, na maioria dos casos, foi que esta busca esta sendo movida não mais em busca de um diferencial de processo/produto, mas sim como uma forma de sobrevivência para o mercado. Com base nesta afirmação foram realizados questionários com diversas empresas para identificar qual é o verdadeiro impacto desta busca pela qualidade nos processos diferenciados das empresas, e verificou-se que ela realmente é benéfica. Pela percepção dos pesquisadores, o sucesso de implantação de um processo de qualidade depende diretamente do apoio da alta gerência da empresa, uma análise

24 da organização como um todo incluindo aí aspectos culturais, um bom planejamento e principalmente o comprometimento dos funcionários na manutenção do mesmo após a implantação. Percebeu-se também que em um primeiro momento o processo implantado pode gerar uma diminuição na produtividade geral, o que pode ser explicado pelos controles impostos pelo próprio processo de desenvolvimento. Porém, em variáveis como prazo, retrabalho, número de defeitos, cronograma é perceptível algum tipo de mudança para melhor. Com a institucionalização dos processos a tendência é de aumento na produtividade. Outro ponto de vista dos pesquisadores após toda a pesquisa efetuada e após todas as respostas de diferentes empresas foi identificar melhorias nos processos, definições de padrões de desenvolvimento, elaboração de métricas de acompanhamento de qualidade e melhoria, entre outros. Tudo isso independente de qual foi o objetivo que iniciou a busca da qualidade de software pelas empresas. Enfim, em todas as organizações foi possível identificar uma maior maturidade nos processos e a busca continua pela melhoria do produto final, tanto nos fatores qualidade, tempo e custo. Embora o custo e tempo de implantação de um processo de qualidade sejam altos, ele acaba retornando o investimento no médio e longo prazo para as organizações. Nas pesquisas realizadas junto às empresas foi constatada a inexistência de indicadores consistentes que retratassem o período anterior à implantação dos modelos de qualidade. Devido a isso, a pesquisa levou em conta a percepção dos profissionais. Porém pesquisas realizadas mais de uma vez após a implantação de um processo de qualidade, isto é, em instituições que já internalizaram o processo com indicadores de medição já definidos, pode verificar-se a melhora nos mesmos. Além disso, permitiu verificar um crescimento das mesmas, apontado pelos indicadores de número de funcionários, faturamento e número de clientes. Este crescimento pode estar ligado à redução nos custos dos projetos e na capacidade de oferecer produtos com maior qualidade. Concluindo assim que os processos de qualidade não são apenas tendências de mercado, mas sim diferencias de desenvolvimento de processo que impactam beneficamente no custo, tempo e qualidade do seu produto final, trazendo assim benefícios para as organizações. Dessa forma a instituição de um processo de qualidade está se tornando um requisito indispensável em empresas de desenvolvimento de software que desejam ter produtos de qualidade e manter-se num mercado competitivo.

25 10. REFERÊNCIAS [1] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR Guia Geral: 2009, maio Disponível em [2] ISO/IEC 12207:1995/Amd 1:2002/Amd 2:2004. Technology Information Software Life Cycle Processes. [3] ISO/IEC Technology Information Process Assessment Part 1 Concepts and vocabulary; part 2 Per-forming an assessment; part 3 Guidance on performing an assessment; part 4 Guidance on use for process improvement and process capability determination; and part 5 An exemplar process assessment model. [4] Chrissis, M. B., Konrad, M, Shrum, S. CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley, [5] Weber, K., Araújo, E., Rocha, A. R., Oliveira, K., Rouiller, A. C., Wangenheim, C. G., Araújo, R., Salviano, C., Macha-do, C. F., Scalet, D., Galarraga, O., Amaral, M. P., Yoshida, D. Melhoria de Processo de Software Brasileiro (MPS.BR): Um Programa Mobilizador [6] Rocha, A. C. Lições Aprendidas em Avaliações MPS, In: MPS.BR Lições Aprendidas [7] Software Engineering Institute. Disponível em http/ Acessado no dia 13 de março de [8] Benefits of CMMI Within the Defense Industry: Disponível em: acessado no dia 07 de junho de [9] imps 2010, Desempenho das Empresas que Adotaram o Modelo MPS de 2008 a 2010: 20Baixa.pdf acessado no dia 07 de junho de [10] Sally Godfrey (2008) What is CMMI?. Apresentação da NASA. Acessado no dia 13 Março de 2011.

26 [11] Pádua, C. F., Mendes, M. S. A busca da qualidade no desenvolvimento de software: acessado no dia 22 de abril de 2011.

27 11. ANEXOS RESPOSTAS QUESTIONÁRIO EMPRESA TREE TOOLS Pré Implantação de Processo de Qualidade 1. Como era o processo de gerenciamento de processos? Tree Tools: Bom, vou responder como gerenciamento de projetos. Não havia nada formal, nem atividades definidas e nem papel definido. 2. Como era feita a estimativa de prazos dos projetos? Tree Tools: Já utilizámos a estimativa por UCP Use Case Points, mas o seu preenchimento não tinha critérios objetivos, ou seja, dependia de quem preenchia a planilha. 3. Como era feito o controle das alterações de escopo dos projetos? Tree Tools: Não havia controle formal e nem formas de avaliar o impacto sobre as alterações solicitadas. 4. Como era feita a estimativa de custos dos projetos? Tree Tools: Através de cálculo envolvendo prazo versus recursos alocados. 5. Como era a satisfação do cliente com o processo e os produtos entregues? Tree Tools: Na realidade o cliente era pouco afetado, pela política da empresa, de cumprir sempre os contratos. O maior afetado era a própria Tree Tools que pagava pela falta de processos, tendo que realizar mais do que o previsto. 6. Como era feita a documentação na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Tree Tools: Era informal, sem padrão, as vezes verbal. Pós Implantação de Processo de Qualidade 1. Como é o atual processo de gerenciamento de processos?

28 Tree Tools: Para manter a coerência vou responder sobre gerenciamento de projetos. Após a implantação do MPS-BR temos um processo bem definido para gerenciamento de projetos. Na fase de Iniciação é feito um Plano do Projeto, com definição clara do escopo, WBS, matriz de riscos, plano de testes, plano de comunicação, plano de implantação, cronograma, etc. Durante o projeto são realizadas reuniões de Monitoramento e Controle onde são tratados em torno de 16 itens, tais como utilização do processo, riscos, cronograma, etc. 2. Como é feita a estimativa de prazos dos projetos? Tree Tools: A planilha de UCP foi totalmente reformulada, com critérios objetivos para que os resultados sejam os mesmos independentemente de quem a preenche. Além disso, a planilha já distribui todos os tempos de todas as atividades do cronograma. O cronograma é então inserido na ferramenta Project Builder, que é atualizado via browser por todos os envolvidos no projeto. 3. Como são gerenciadas as alterações de escopos dos projetos? Tree Tools: Uma vez definido o escopo no Plano do Projeto, qualquer alteração deve ser formalmente solicitada, é feita uma análise de impacto sobre o projeto em termos de prazo e custo, e se aprovada a solicitação de mudança é registrada e acompanhada até a sua implantação. Para apoiar a análise de impacto é utilizada a matriz de rastreabilidade de artefatos, alimentada nas fases do ciclo de vida do projeto. 4. Como é realizada a estimativa de custos dos projetos? Tree Tools: Todos os custos são controlados pela ferramenta Project Builder. Como o principal insumo é pessoa, o custo deste é obtido pela ferramenta multiplicando o valor da pessoa pela quantidade de horas alocadas no projeto. 5. Como é medida a satisfação do cliente com o processo e os produtos entregues? Tree Tools: Ainda não temos um processo formal desta medição. Estamos este ano implementando o nível F do MPS-BR que possui a área de processo chamada Medição. Vamos analisar a possibilidade e formas de medirmos este indicador. 6. Qual é a padronização de documento na qual um Analista de Sistemas envia para um programador desenvolver um requisito no projeto?

29 Tree Tools: O programador recebe a especificação do caso de uso, o protótipo (quando aplicável), o modelo de dados e o roteiro de testes do caso de uso. - A especificação do caso de uso é feita pelo Analista de Sistemas em MS-Word; - O protótipo (quando aplicável) é feito pelo Analista de Sistemas normalmente em HTML ou ZK; - O modelo de dados é feito pelo Analista de Sistemas em Toad Data Modeler; - O roteiro de testes é feito pelo Analista de Testes no Testlink RESPOSTAS QUESTIONÁRIO EMPRESA E-GOVERNE Pré Implantação de Processo de Qualidade 1. Como era o processo de gerenciamento de Projetos? Só existia o monitoramento quanto à execução das atividades de desenvolvimento de software, não existia um planejamento. Não existia o gerenciamento de riscos e reuniões de acompanhamento de projetos, que causava muita falha de comunicação. 2. Como era feita a estimativa de prazos dos projetos? As estimativas eram sempre baseadas na experiência do profissional, portanto, o mesmo projeto tinha estimativas diferentes sob o ponto de vista de dois gerentes de projetos. 3. Como era feito o controle das alterações de escopo do projeto? Simplesmente não havia um controle de mudança de escopo, tudo o que o cliente solicitava era feito. Isso causava um grande prejuízo para os projetos, tanto na questão financeira, quanto na motivacional, pois as equipes sempre faziam horas extras para entregar as demandas, porém o projeto nunca acabava.

30 4. Como era a satisfação do cliente com o processo e os produtos entregues? Recebíamos muitas reclamações referentes a erros básicos. E em muitas vezes escutávamos: Esta funcionalidade estava funcionando na versão anterior. Como é que pode? Conserta uma coisa e estraga outra.. Isso também causava grande desmotivação na equipe do projeto que quanto mais se empenhava para corrigir problemas, mais erros apareciam. 5. Como era feita a documentação na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Em alguns projetos, as informações eram repassadas através de um documento Word, porém, não existia um padrão, cada analista colocava as informações que julgasse necessário, e na ordem que bem entendesse. Em outros projetos, não havia documentação, em muitas vezes, a descrição das atividades era feita por conversa. Pós Implantação de Processo de Qualidade 1. Como é o atual processo de gerenciamento de projetos? Existe um modelo de plano de projeto em que o Gerente de Projeto documenta formalmente todo o planejamento do projeto: escopo, cronograma, equipe, descrição de atividades, treinamentos necessários para a equipe do projeto, qual será a forma de homologação, a comunicação entre os principais envolvidos no projeto, inclusive o cliente, entre outras. Sem contar que periodicamente, são realizadas reuniões de acompanhamento do projeto com a equipe, nessas reuniões são analisadas algumas métricas para monitoramento do projeto, como por exemplo, tendência de atraso, esforço gasto, porcentagem de conclusão. 2. Como é feita a estimativa de prazos dos projetos? Hoje utilizamos a estimativa de Pontos por Caso de Uso. Identificamos todos casos de uso com seu grau de complexidade. Esta estimativa nos tá um total de horas x, essas horas são distribuídas no cronograma do projeto. 3. Como é gerenciado as alterações de escopo do projeto?

31 Após a obtenção do comprometimento do cliente com o escopo, toda mudança, seja inclusão, alteração ou exclusão de requisitos, deve obrigatoriamente ter uma avaliação dos impactos de mudança. E esses impactos (aumento de custo e/ou prazo, etc), devem ser acordados com o cliente. Desta forma não há sustos na entrega do produto. 4. Como é medida a satisfação do cliente com o processo e os produtos entregues? Principalmente na diminuição de solicitações de correções de erros e conseqüentemente na assinatura de novos contratos. 5. Qual é a padronização de documento na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Existe todo um processo, desde o levantamento do requisito com o cliente, até seu desenvolvimento através de linhas de código. Depois de mapeados todos os casos de uso, esses são especificados em um documento padrão, que após sua elaboração, é revisado por outro profissional com mesmo perfil do que especificou o caso de uso. Essa padronização facilitou a localização de informações dentro do documento e garantiu que todas as informações necessárias para a codificação do caso de uso estão presentes no documento RESPOSTAS QUESTIONÁRIO EMPRESA GUENKA Pré Implantação de Processo de Qualidade 1. Como era o processo de gerenciamento de processos? Não havia um processo definido para o gerenciamento de processos. 2. Como era feita a estimativa de prazos dos projetos? Com base na opinião e experiência dos gerentes de projetos e pessoal técnico. 3. Como era feito o controle das alterações de escopo dos projetos?

32 Alterados conforme demanda do cliente, sem procedimentos de análise de impacto. 4. Como era feita a estimativa de custos dos projetos? Com base na opinião e experiência dos gerentes de projetos e pessoal técnico identificava-se o esforço necessário, com isso calculava-se o custo que demandaria para recursos humanos e infra-estrutura. 5. Como era a satisfação do cliente com o processo e os produtos entregues? Nunca foi medida. 6. Como era feita a documentação na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Uma documentação muito superficial, o Programador sempre necessitava da presença do Analista de Sistemas para sanar dúvidas em relação ao documentado. Pós Implantação de Processo de Qualidade 1. Como é o atual processo de gerenciamento de processos? Há um responsável por coordenar o processo de melhoria, o qual conta com grupos de analista, programadores e tester para apoiar no desenvolvimento de novos processos e ajustes dos já existentes. 2. Como é feita a estimativa de prazos dos projetos? Uma metodologia baseada na complexidade dos requisitos foi criada, mas ainda permanece a opinião especializada, visto que ainda não há uma base sólida de informações referentes as medições realizadas. 3. Como são gerenciadas as alterações de escopos dos projetos? Hoje qualquer mudança de escopo deve ser analisada por um comitê, que aprova ou não a alteração, sempre levando em conta o impacto e o custo. 4. Como é realizada a estimativa de custos dos projetos?

33 Com base no esforço obtido pela metodologia de complexidade dos requisitos, o custo é estimado, mais ainda é considerada a opinião especializada, visto que não há uma base sólida de informações provenientes das medições. 5. Como é medida a satisfação do cliente com o processo e os produtos entregues? Ainda não está sendo medida. 6. Qual é a padronização de documento na qual um Analista de Sistemas envia para um programador desenvolver um requisito no projeto? Diagrama de casos de uso, descrição dos casos de uso, diagramas de classes e protótipos de telas RESPOSTAS QUESTIONÁRIO EMPRESA NVI Pré Implantação de Processo de Qualidade 1. Como era o processo de gerenciamento de processos? Antes da implementação do Modelo MPS.BR, a NVi já tinha implantado processos na área de desenvolvimento de software, devido à certificação ISO9001:2000. Nos processos estava prevista a realização de Análise Crítica em determinadas etapas dos projetos, para garantir o gerenciamento das mesmas e tomadas de ações corretivas, porém com menor detalhamento. 2. Como era feita a estimativa de prazos dos projetos? Não havia uma ferramenta formal para esta finalidade. Os prazos eram estimados considerando a experiência da equipe em projetos anteriores, porém não eram agregados tempos de testes, planejamento, monitoramento, passagem de código entre ambientes, etc. Isso ocasionava a entrega do produto no prazo, porém com erros devido à pressa em desenvolver dentro do prazo estipulado e com custo adicional pelo trabalho realizado em horário extraordinário. 3. Como era feito o controle das alterações de escopo dos projetos?

34 As mudanças eram requisitadas por ou discutidas em reuniões cuja formalização constava em atas. Não havia um documento específico de escopo. O detalhamento do escopo estava parte no documento de análise do projeto e parte na proposta comercial, mas não era completo. 4. Como era feita a estimativa de custos dos projetos? Não havia controle de custos de projetos. 5. Como era a satisfação do cliente com o processo e os produtos entregues? A satisfação com as funcionalidades e prazos de entrega era boa. Havia reclamações quanto a quantidade de erros (já que o cumprimento do prazo era mascarado pela falta de testes mais consistentes). Como a empresa tinha implantado a ISO, as reclamações eram tratadas por Ações Corretivas e a satisfação era freqüentemente avaliada por pesquisa formal implementada pela ISO. 6. Como era feita a documentação na qual um Analista de Sistemas enviava para um programador desenvolver um requisito no projeto? Por um formulário interno de Especificação Técnica contendo as regras de negócio, tratamento de campos, criação de novas tabelas ou campos nas estruturas do banco de dados e imagem de telas. Pós Implantação de Processo de Qualidade 1. Como é o atual processo de gerenciamento de processos? A definição dos processos continua seguindo as normas ISO9001:2000, complementadas com as exigências do Modelo MPS.BR. O processo de desenvolvimento de software foi segmentado para contemplar a Gerência de Requisitos e Gerência de Projeto. A cada fase do ciclo de vida do projeto o gerenciamento é registrado nas Revisões de Marco. Durante a fase de desenvolvimento o gerenciamento é registrado nas atas de reuniões de monitoramento, em geral semanais. Nas reuniões de monitoramento são acompanhadas as realizações das atividades do cronograma, os riscos que podem causar atrasos no projeto e respectivas ações, quando necessárias e a necessidade de alocação de novos recursos. As mudanças no escopo do projeto são também analisadas nas reuniões de monitoramento quanto ao seu impacto no projeto e quanto às alterações nos

35 documentos (rastreabilidade, cronograma, estimativa de esforço e prazo, custos, etc). Um re-planejamento do projeto é estabelecido e acompanhado até conclusão final das ações. 2. Como é feita a estimativa de prazos dos projetos? Com base na experiência da equipe, foi desenvolvida uma ferramenta interna, em planilha, para estimativa de esforço e prazo para os projetos. Na ferramenta foram incluídos os itens que antes não eram computados no esforço: planejamento, monitoramento, testes, preparação de ambiente, passagem de código e geração de scripts. A opção por desenvolver ferramenta interna para essa finalidade se baseou na falta de experiência da empresa com ferramentas de mercado, o que poderia levar a escolhas erradas além dos custos envolvidos. A opção foi acertada, tanto que, em mais de um ano de uso, as estimativas tiveram apenas duas revisões e o desvio padrão entre o esforço estimado e o realizado, não passou de 20%. 3. Como são gerenciadas as alterações de escopos dos projetos? São registradas no documento de análise, onde são detalhados o escopo, limites, requisitos e análise das regras. O versionamento do documento é alterado e enviado para análise e aprovação do cliente. Após retorno é passado para a equipe técnica que trata as alterações como mudança de projeto, devidamente registrada no documento de gerenciamento/monitoramento do projeto (vide pergunta 1). 4. Como é realizada a estimativa de custos dos projetos? Foi desenvolvida ferramenta interna, em planilha, para controle dos custos. Além dos recursos humanos envolvidos no projeto, são também inseridos recursos tecnológicos, viagens para treinamento e implantação e despesas indiretas (administrativas). Ao final do projeto, são apurados os recursos e esforços efetivamente gastos, através do gerenciamento, para cálculo do custo final realizado. 5. Como é medida a satisfação do cliente com o processo e os produtos entregues? Pela análise de indicadores de erros reportados pelo cliente, após entrega do projeto. Os indicadores de erros já eram acompanhados por exigência da ISO e novos indicadores foram criados após implementação do MPS.BR. Com o esforço da atividade de testes incorporada aos projetos, os erros foram reduzidos substancialmente.

36 6. Qual é a padronização de documento na qual um Analista de Sistemas envia para um programador desenvolver um requisito no projeto? Continuamos com o mesmo documento utilizado antes da implementação do Modelo MPS.BR. Acrescentamos apenas o registro de revisão da especificação técnica por outro colaborador da equipe técnica, para garantir a consistência entre o mesmo e o documento de análise do projeto, onde constam os requisitos aprovados pelo cliente.