FAE FACULDADE ANGLICANA DE ERECHIM CURSO DE PÓS-GRADUAÇÃO LATO SENSU GESTÃO EM TECNOLOGIA E DESENVOLVIMENTO DA INFORMAÇÃO CHEILA BOMBANA

Transcrição

1 FAE FACULDADE ANGLICANA DE ERECHIM CURSO DE PÓS-GRADUAÇÃO LATO SENSU GESTÃO EM TECNOLOGIA E DESENVOLVIMENTO DA INFORMAÇÃO CHEILA BOMBANA ANÁLISE E IDENTIFICAÇÃO DAS VANTAGENS DA IMPLANTAÇÃO DO PROGRAMA DE MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR) EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTEMAS Erechim RS 2009

2 1 CHEILA BOMBANA ANÁLISE E IDENTIFICAÇÃO DAS VANTAGENS DA IMPLANTAÇÃO DO PROGRAMA DE MELHORIA DO PROCESSO DE SOFTWARE BRASILEIRO (MPS.BR) EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTEMAS Trabalho de Conclusão de Curso apresentado a Faculdade Anglicana de Erechim, como requisito parcial para a obtenção do título de pós-graduação em Gestão em Tecnologia e Desenvolvimento da Informação, sob orientação da professora Gema Luciane Agliardi. Erechim RS 2009

3 FOLHA DE APROVAÇÃO 2

4 3 Qualidade de software não é um trilho mas uma trilha. (Autor desconhecido)

5 4 RESUMO O desenvolvimento, implantação e manutenção de sistemas de software é uma tarefa desafiadora, devido ao fato de que a complexidade de programação e as expectativas dos clientes aumentam significativamente com a evolução tecnológica. Na realidade atual das micro, pequenas e médias empresas de desenvolvimento de software, qualidade é um fator diferencial para se ganhar vantagem competitiva, além de garantir o bom desempenho dos produtos de software comercializados. A necessidade urgente de melhorar a qualidade dos produtos e serviços de uma empresa de desenvolvimento para atingir suas metas de crescimento é o fator determinante que motivou esta pesquisa. Este trabalho apresenta uma análise bibliográfica introdutória baseada em Qualidade de Software e Modelos de Maturidade. Em seguida, descreve o diagnóstico, o plano de melhoria do processo de software e os primeiros resultados adquiridos com a implantação, utilizando o nível G (Parcialmente Gerenciado) do MPS.BR(Melhoria de Processo do Software Brasileiro) em uma empresa de desenvolvimento de software de pequeno porte. Os objetivos inicialmente propostos foram alcançados, através da análise dos processos de desenvolvimento de software da empresa, identificação das mudanças necessárias para se enquadrar ao padrão de desenvolvimento Parcialmente Gerenciado, e por fim, a avaliação dos custos e benefícios que a implantação do projeto de melhoria proporcionou a empresa. Palavras-Chaves: Processo de Software, Qualidade de Software, Gerenciamento de Projetos, Gerenciamento de Requisitos, MPS.BR.

6 5 ABSTRACT The development, implementation and maintenance of software systems is a challenging task, due to the fact that the complexity of programming and customer expectations increase significantly with technological developments. In the current reality of small and medium-sized company software development, quality is a distinguishing factor to get competitive advantage and ensure the proper performance of the software products market. The urgent need to improve the quality of products and services of a development company to achieve its goals of growth is the determining factor that motivated this research. This paper presents an introductory bibliography analysis based on Software Quality and Maturity Models. It then describes the diagnosis, a plan for improving the software process and the first results obtained with the implementation, using the standard G (Partially Managed) of MPS.BR (Process Improvement in Brazilian Software) in a development small company software. The initial goals were reached by analyzing the processes of software development company, identifying the changes necessary to fit the pattern of development Partly Managed, and finally, evaluation of the costs and benefits that the implementation of the improvement project provided the company. Key Words: Software Process, Software Quality, Project Management, Requirements Management, MPS.BR.

7 6 LISTA DE FIGURAS Figura 1 - Etapas Desenvolvimento de Software...14 Figura 4 Qualidade de Software X Modelo de Maturidade...18 Figura 5 - Modelo MPS.BR...24 Figura 6 Fluxograma Processos...31 Figura 7 Fluxograma de Trabalho...35 Figura 8 - Processo Desenvolvimento Elaboração...43 Figura 9 - Processos Desenvolvimento Construção...44

8 7 SUMÁRIO INTRODUÇÃO FUNDAMENTAÇÃO TEÓRICA QUALIDADE QUALIDADE DE SOFTWARE PROCESSO DE SOFTWARE Ciclo de Processo de Software QUALIDADE DO PROCESSO X MODELOS DE MATURIDADE ISO 9000/ NBR CMMI (CAPABILITY MATURITY MODEL INTEGRATION) MPS.BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO) Níveis de Maturidade Nível G Parcialmente Gerenciado (Processos) Nível G Parcialmente Gerenciado (Capacidade) PROCEDIMENTOS METODOLÓGICOS TIPO DE PESQUISA DELIMITAÇÃO TÉCNICA PARA COLETA DE DADOS APRESENTAÇÃO E ANÁLISE DE DADOS SITUAÇÃO ATUAL DA EMPRESA Fluxograma de Processos de Desenvolvimento APLICAÇÃO DO MPS-BR NÍVEL G (PARCIALMENTE GERENCIADO) Práticas Existentes X Resultados Esperados...35

9 Ações de Melhoria Ambiente de Apoio Treinamento dos Colaboradores AVALIAÇÃO DOS RESULTADOS Resultados Obtidos Adequações Necessárias...48 CONSIDERAÇÕES FINAIS...50 REFERENCIAS...52 ANEXOS...53 ANEXO A PLANO DE PROJETO...53 ANEXO B PLANO DE GERENCIAMENTO DE RISCOS...56

10 9 INTRODUÇÃO A informática nos apresenta um novo mundo, que quebra todas as barreiras de comunicação e modifica a própria estrutura da indústria de consumo. O consumidor e a indústria passaram a valorizar não somente o produto final, mas todas as fases do processo de construção/elaboração, incluindo a fase de entrega. Então, começa uma maior preocupação com a intelectualidade e comprometimento com a qualidade, que passa a ser fator de competitividade. O desenvolvimento de software tem exigido a aprendizagem e reciclagem constante de seus profissionais, em busca de novos métodos para a transformação em resultados. O desenvolvimento de sistemas de informação, com qualidade e capacidade de atender às reais necessidades dos usuários exige a utilização de metodologias eficazes. O processo de software, portanto, é essencial para que tenhamos qualidade nos produtos de software e consigamos atender a expectativa, orçamento, prazos e recursos definidos no projeto. Organizações que sejam capazes de integrar, harmonizar, acelerar seus processos de desenvolvimento e manutenção de software terão a preferência do mercado. Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços relacionados, como dos processos de produção e distribuição de software. Desta forma, assim como para outros setores, qualidade é fator crítico de sucesso para a indústria de software. Para que o Brasil possua um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando a oferta de produtos de software e serviços em conformidade com padrões internacionais de qualidade. O objetivo deste estudo é identificar a importância da implantação de um programa de melhoria de processo de software para a qualidade final dos produtos e serviços oferecidos por uma empresa de desenvolvimento de software. Toda empresa de desenvolvimento necessita da definição e normatização de processos

11 10 de desenvolvimento para apresentar um software de qualidade, que atenda as expectativas dos clientes de forma satisfatória. O MPS.BR ou Melhoria de Processos do Software Brasileiro, é um programa criado, mais adequado a realidade das empresas nacionais, que oferece padrões a serem seguidos para melhoria da qualidade de software. Este trabalho foi realizado inicialmente com uma pesquisa bibliográfica sobre Qualidade e Processo de Software, e após, direcionado para Modelos de Maturidade, especificamente o MPS.BR (Melhoria de Processos do Software Brasileiro). Em seguida, foram analisados os processos de desenvolvimento de uma empresa de desenvolvimento de software, identificando mudanças que precisam ser realizadas para que a mesma se enquadre ao padrão de desenvolvimento MPS.BR nível G (Parcialmente Gerenciado). Por fim, foram identificados os benefícios que a implementação deste projeto de melhoria de processos de software proporcionou a empresa.

12 11 1. FUNDAMENTAÇÃO TEÓRICA O desenvolvimento desse estudo, apóia-se em autores que melhor definem qualidade de maneira geral e também aliada à qualidade de software. Torna-se necessário o estudo de padronizações internacionais que buscam a melhoria dos processos e conseqüentemente dos produtos de software. Padrões nacionais recentemente criados, também serão analisados para serem aplicados de forma prática. 1.1 QUALIDADE No dicionário qualidade é definida como: Característica essencial de alguma coisa, inerente ou distinto caráter, grau ou graduação de excelência. (MICHAELIS, 1998). Encontramos várias definições conceituais para qualidade, más todas essencialmente levam a uma única conclusão, qualidade está relacionada à bem estar, por isso a tão falada qualidade de vida é muito discutida nos dias atuais. Todo ser humano quer qualidade, mas cada um tem sua definição para a mesma, conforme as suas próprias necessidades. Sendo assim, o que tem qualidade para um pode não ter para outro. Dessa forma, só vai conseguir produzir e oferecer qualidade quem souber identificar o que o seu cliente realmente necessita, quais são suas reais expectativas sobre aquele produto ou serviço. Mais importante do que rotular e definir qualidade é conseguir explicar claramente o conceito. As organizações precisam encontrar uma forma de traduzir o conceito de qualidade para algo mais prático, da forma mais simples e clara possível, e fazendo com que todas as pessoas envolvidas no processo, entendam como ele funciona e porque ele acontece dessa forma, conforme o ramo de atuação de cada empresa. Qualidade é tudo aquilo que alguém faz ao longo de um processo para garantir que um cliente, interno ou externo a organização obtenha exatamente aquilo que deseja. (INTHURN; CÂNDIDA, 2001, p. 5)

13 12 Podemos afirmar que qualidade é atitude, e que só vai conseguir qualidade a empresa que se preocupar com ela como um todo. A satisfação dos funcionários, que são os clientes internos da empresa, é essencial para que o produto que chega ao usuário final, o cliente, seja de qualidade satisfatória. Temos o produtor da qualidade, que é responsável pela geração de produtos e serviços, e o consumidor da qualidade, que é o responsável pela utilização desses produtos ou serviços, que vai usufruir do resultado. Só poderemos afirmar que existe qualidade quando houver uma sincronização perfeita entre o produtor e o consumidor. A oferta deve atender a expectativa, caso contrário, é provável que a qualidade não existirá ou estará comprometida. A qualidade está diretamente relacionada à produtividade e a competitividade, através dela é possível diminuir os desperdícios, baixando custos, e aumentar as vendas, mantendo a empresa no mercado. Sabemos que a produtividade é aumentada com a melhoria da qualidade, e que hoje, a qualidade não é mais diferencial, é necessidade para a sobrevivência de qualquer empresa. 1.2 QUALIDADE DE SOFTWARE Qualidade de software é um conjunto de propriedades a serem satisfeitas de modo que o software atenda as necessidades de seus usuários. (INTHURN; CÂNDIDA, 2001, p. 22) A padronização na produção de bens tem seus primórdios na Revolução Industrial do século XVIII, desde então os padrões tem sido utilizados em todas as áreas de conhecimento do homem. No que diz respeito à qualidade de software, a aplicação de padrões começou a ser estudada na década de 70 e ganhou expressão a partir da segunda metade da década de 80. A qualidade no desenvolvimento de software é um assunto amplo e ainda bastante complexo, sendo que são vários os fatores que devem ser levados em consideração para definir se um software tem ou não qualidade. Como para qualquer produto, vale a afirmação de que a qualidade está diretamente relacionada à satisfação do cliente, ou nesse caso, do usuário. As propriedades do software são definidas a partir das necessidades do usuário, portanto, qualidade em desenvolvimento de sistemas significa:

14 13 alinhamento total entre as necessidades/expectativas dos usuários e as especificações geradas; alinhamento total entre as especificações aprovadas e o produto construído e; produto final com a menor quantidade de erros possível. A construção de um sistema é algo bastante complexo, que envolve várias etapas, desde a sua concepção até a implantação para o usuário final. O produto de software, nada mais é, que o resultado dos processos de desenvolvimento, portanto, chegou-se a conclusão que o caminho é focar na melhoria da qualidade dos processos para se obter um software de qualidade. Para entendermos o motivo das dificuldades em se obter um produto de software qualificado é necessário conhecer alguns conceitos de Engenharia de Software. A criação de um software passa por quatro etapas básicas desde sua concepção até o usuário final, independente do modelo de desenvolvimento utilizado. São elas: Análise de Requisitos: fase inicial, onde são identificadas as necessidades do cliente, nessa fase é importante esclarecer e detalhar as idéias do cliente/usuário para definir as funcionalidades do sistema de forma correta. Projeto: é a fase que se encarrega de transformar os resultados da Análise de Requisitos em um documento ou conjunto de documentos capazes de serem interpretados diretamente pelo programador. Codificação: também chamada de implementação, esta fase é uma simples questão de tradução do projeto para um código. Testes: o teste do software consiste na sua utilização para a identificação de defeitos, deve ser avaliada a qualidade do sistema e a conformidade em relação aos requisitos inicialmente levantados.

15 14 Figura 1 - Etapas Desenvolvimento de Software Em cada uma dessas fases existem ferramentas e principalmente pessoas envolvidas, o que torna os processos suscetíveis a erros, conforme podemos observar na Figura 1. Ao longo do desenvolvimento algumas distorções podem ocorrer com relação à idéia original e erros vão sendo inseridos no produto, ocasionando a geração de um produto final bem diferente do que era esperado, comprometendo a qualidade do software. Para minimizar esse problema, evitando erros que afetam a credibilidade das empresas, é necessário trabalhar na qualidade dos processos, usando padronizações, para se obter um produto final com a qualidade esperada. A norma internacional ISO/IEC 9126, publicada em 1991, define qualidade de software como: A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas. (MOLINARI; LEONARDO, 2003, p. 24) Entendemos por necessidades explícitas os objetivos e as condições propostas por aqueles que produzem o software, refere-se ao controle de qualidade dos processos de desenvolvimento do produto. Podem ser percebidos apenas pelas pessoas que trabalham direta ou indiretamente no seu desenvolvimento. Trata-se da qualidade do processo.

16 15 As necessidades implícitas são as dos usuários, que podem ser operadores, destinatários dos resultados do software ou mantenedores, são também conhecidos como fatores externos e podem ser percebidos tanto pelos desenvolvedores quanto pelos usuários. Essas necessidades são também chamadas de qualidade em uso e devem permitir aos usuários atingir suas metas de forma efetiva, com produtividade, segurança e satisfação, dentro de um contexto de uso que deve ter sido especificado. Refere-se à qualidade do produto. 1.3 PROCESSO DE SOFTWARE Processo de software é um conjunto de atividades inter-relacionadas ou interativas, que transforma insumos (entradas) em produtos (saídas). (ISO 9000, 2000). Podemos entender o processo de software como sendo um conjunto de atividades, que envolvem métodos e práticas aplicadas na produção de um software. Os insumos (entradas) são constituídos por requisitos, idéias e tempo, enquanto a saída é o produto de software e os serviços relacionados a ele. O sistema pronto para ser utilizado pelo cliente/usuário é o resultado dos processos utilizados no seu desenvolvimento. As atividades que são realizadas ao longo do desenvolvimento de um sistema envolvem impreterivelmente, pessoas, materiais, equipamentos e procedimentos, são esses quatro itens que necessitam ser trabalhados constantemente para melhoria de um processo de software, conforme Figura 2.

17 16 Pessoas Materiais Equipamentos Procedimentos Requisitos Idéias Tempo A t i v i d a d e s Produtos e Serviços Figura 2 Definição de Processo Ciclo de Processo de Software O ciclo de vida de um processo de software é composto pelas seguintes etapas: Definição, Uso, Medição, Controle e Melhoria, conforme Figura 3. Os seguintes fatores devem estar presentes nos processos de software: Procedimentos e métodos que descrevam a relação existente entre as atividades que compõe o processo; Ferramentas e equipamentos que dêem apoio a realização destas tarefas, simplificando e automatizando o trabalho; Pessoas treinadas nos métodos e ferramentas e capazes de realizar as atividades de forma adequada. Existe a necessidade de controlar o processo para mantê-lo dentro de seus limites normais de desempenho, sendo que o processo deve se comportar de forma consistente. Controlar o processo envolve, primeiramente sua medição. As medidas são base para: Verificar se o processo está sento executado conforme a sua definição;

18 17 Identificar desvios com relação ao desempenho aceitável para o processo; Identificar oportunidades de melhoria. Com a medição será possível detectar variações no processo, bem como, a causa dessas variações, corrigindo e, se necessário, redefinindo o processo Melhorar o Processo Definir o Processo Controlar o Processo Medir o Processo Executar o Processo Figura 3 Ciclo de Processo A melhoria no processo de software deve ser colocada em prática continuamente. Melhorar o processo envolve entender suas características e os fatores que afetam a sua capacidade. È necessário planejar e implementar ações que modifiquem o processo para atender as necessidades de negócio. Porém, toda melhoria a ser proposta deve ser antes avaliada, tendo em vista seus impactos e benefícios. Processos de software devem ser tecnologicamente competitivos, adaptáveis e flexíveis, também adequados com relação ao tempo, devem ser capazes de produzir produtos que atinjam as necessidades do cliente e do negócio conforme a cultura organizacional da empresa. Para isso, existe a necessidade de definir processos que apóiem os objetivos técnicos e de negócio da empresa, além de fornecer a infra-estrutura necessária para apoiar as atividades do processo (métodos, práticas e pessoas) e assegurar que a organização possua as habilidades necessárias para executar o processo.

19 QUALIDADE DO PROCESSO X MODELOS DE MATURIDADE Mesmo as melhores pessoas não conseguem trabalhar de forma eficiente se o processo é problemático ou mal compreendido. O processo é a ponta do triângulo que unifica os outros aspectos. Sem processos claros e eficientes, uma empresa não é escalável. (RIBEIRO; ADRIELE, 2007) A qualidade de um produto, qualquer que seja, está diretamente ligada a qualidade dos processos utilizados para sua criação. Quando se fala em produtos de software não é diferente, a qualidade dos processos de desenvolvimento é fundamental para se produzir um software de qualidade. Investimentos em tecnologia sem um guia que defina como utilizá-la é um desperdício de recursos, por isso o uso de modelos de maturidade baseados em gerenciamento de projetos está cada vez mais sendo difundido entre as empresas de desenvolvimento. Qualidade do Produto de Software É obtida por meio de Qualidade do Processo de Desenvolvimento de É alcançada mais facilmente se baseada em Modelo de Maturidade (MPS.BR) Tem como base Gerenciamento de Projetos Figura 4 Qualidade de Software X Modelo de Maturidade

20 19 O gerenciamento de projetos se preocupa em entregar o sistema de software no prazo e de acordo com os requisitos estabelecidos, levando em conta sempre as limitações de orçamento e tempo. A gerência de projetos de software se caracteriza por tratar sobre um produto intangível, muito flexível e com processo de desenvolvimento com baixa padronização. As atividades que envolvem o planejamento sofrem com dificuldades típicas de desenvolvimento de software. A produtividade não é linear em relação ao tamanho da equipe e o aumento de produtividade não é imediato devido aos custos de aprendizado de novos membros. A diminuição de qualidade para acelerar o desenvolvimento constantemente prejudica futuramente a produtividade. A estimativa de dificuldades e custos de desenvolvimentos são muito difíceis, além do surgimento de problemas técnicos. Esses fatores requerem uma análise de riscos cuidadosa. Além da própria identificação dos riscos é necessário a sua gestão. Seja evitando ou resolvendo, os riscos necessitam ser identificados, estimando o seu impacto. Sugerimos a criação de planos para resolução de problemas. Em meio a todas essas dificuldades, os modelos de maturidade são usados como alternativa para organização e melhoraria constantemente dos processos. Um modelo de maturidade tem como características principais: Definir os requisitos a que os processos devem atender, apresentando flexibilidade em relação a como atendê-los; Permitir avaliações dos processos de forma objetiva e a detecção de pontos fortes e fracos; Especialmente os estruturados por estágio, definir um caminho evolucionário para melhoria de processo; São repositórios de melhores práticas que vêm sendo utilizadas ao longo de vários anos com sucesso. 1.5 ISO 9000/ NBR A ISO (Organização Internacional de Padrões) publicou uma norma que representa a atual padronização mundial para a qualidade de produtos de software. Esta norma chama-se ISO/IEC 9126 e foi publicada em Ela é uma das mais antigas na área de qualidade de software e possui sua tradução para o Brasil, publicada em agosto de 1996 como NBR (INTHURN; CÂNDIDA, 2001, p. 35)

21 20 A norma ISO/IEC 9126 / NBR lista o conjunto de características que devem ser verificadas em um software para que ele possa ser considerado um software de qualidade. Essa norma fornece um modelo de propósito geral o qual define seis amplas categorias de características de qualidade de software que são, por sua vez, subdivididas em sub-características: Quadro 01 Categorias da ISO/IEC 9126 Característica Significado Sub-caracterísica Funcionalidade Refere-se á existência de um - Adequação conjunto de funções que - Acuraria (precisão) satisfazem necessidades - Interoperabilidade explícitas e implícitas, e suas propriedades específicas. - Conformidade - Segurança de Acesso Confiabilidade Capacidade de o software manter seu nível de desempenho, sob condições estabelecidas, por um período de tempo. - Maturidade - Tolerância a falhas - Recuperabilidade Utilizabilidade Eficiência Refere-se ao esforço necessário para utilizar o software, bem como o julgamento individual desse uso, por um conjunto de usuários explícitos ou implícitos Relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas. Manutenibilidade Refere-se ao esforço necessário para fazer modificações específicas no software. Portabilidade Refere-se à habilidade do software de ser transferido de um ambiente para outro. - Inteligibilidade - Apreensibilidade (aprendizagem) - Operacionabilidade - Tempo - Recursos - Analisabilidade - Modificabilidade - Estabilidade - Testabilidade - Adaptabilidade - Capacidade de ser instalado - Conformidade - Capacidade para substituir O modelo proposto pela ISO/IEC 9126 (NBR 13596) tem por objetivo servir de referência básica na avaliação de produto de software. Além de ter força de norma internacional, ela cobre os aspectos mais importantes para qualquer produto de software. Essa norma se aplica na definição dos requisitos da qualidade do software

22 21 e na avaliação (medição, pontuação e julgamento) dos produtos de software. Tornando possível, através dela: definir os requisitos da qualidade de um produto de software; avaliar a especificação do software, para verificar se ele irá satisfazer os requisitos de qualidade durante todo o seu ciclo de vida de desenvolvimento; descrever as particularidades e atributos do software implementados, através da elaboração de manuais do usuário e; avaliar o software desenvolvido, antes da entrega e aceitação do usuário final. 1.6 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) Mas, o que é CMMI? É uma metodologia criada pela SEI (Software Engineering Institute) para ser um guia destinado a melhorar os processos organizacionais e a habilidade desses em gerenciar o desenvolvimento, a aquisição e a manutenção de produtos e serviços. O CMMI organiza as práticas, que já são consideradas efetivas, em uma estrutura que visa auxiliar a organização a estabelecer prioridades para melhoria e também fornece um guia para a implementação dessas melhorias. (MOREIRA DE SOUZA; ADILSON, 2005). O CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. Ele surgiu da percepção de que software básico e aplicações são desenvolvidos em contextos integrados. Além disso, o novo modelo reforça aspectos relacionados à gestão de fornecedores e poderá assimilar outros processos futuramente. O CMMI está dividido em cinco estágios: Realizado 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 o momento; Gerenciado Gerenciamento de requisitos, planejamento de projeto, monitoramento e controle de projeto, gerenciamento de fornecedores, medição e análise, garantia da qualidade do processo e do produto, gerenciamento de configuração. São estabelecidos processos básicos de gerenciamento de projeto para planejar e acompanhar custos, prazos e funcionalidades;

23 22 Definido Desenvolvimento de requisitos, solução técnica, integração do produto, verificação e validação, foco no processo organizacional, definição do processo organizacional, treinamento organizacional, gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução. Atividades de gerenciamento básico e as de Engenharia de Software são documentadas, padronizadas e integradas em processos-padrão; Quantitativamente Gerenciado Gerenciamento quantitativo do projeto, performance do processo organizacional. Métricas detalhadas do processo de software e da qualidade do produto são coletadas. Tanto o processo como o produto de software são quantitativamente compreendidos, avaliados e controlados; Otimização Análise causal e resolução, inovação organizacional e implantação. A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa e da implantação planejada e controlada de tecnologias e idéias inovadoras. Projetos-piloto são realizados para a absorção e internalização de novas tecnologias. Tipicamente, um alto nível de qualidade e de satisfação dos clientes é alcançado rotineiramente, com grande foco na melhoria contínua. O projeto CMMI, além de integrar modelos e reduzir custos com melhorias de processo, também tem outros objetivos que serão facilmente percebidos com sua implementação. São eles: aumento do foco das atividades; integração dos processos existentes; eliminar inconsistências; reduzir duplicações; fornecer terminologia comum (padronização) e; flexibilidade e extensão. 1.7 MPS.BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO) A qualidade de um produto está diretamente relacionada à qualidade do processo de desenvolvimento, desta forma, é comum que a busca por um software

24 23 de maior qualidade passe necessariamente por uma melhoria no processo de desenvolvimento. O MPS.BR motiva para o foco no processo de software, visando à qualidade do processo, e tendo como conseqüência prática: aumento da qualidade do produto; diminuição do retrabalho; maior produtividade; redução do tempo para atender o mercado; maior competitividade e; maior precisão nas estimativas. É muito importante ressaltar que, o foco de um programa de melhoria de processos, que define suas estratégias, políticas, atividades e responsabilidades, deve estar vinculado aos objetivos de negócio da organização. O programa mobilizador para Melhoria de Processo do Software Brasileiro (MPS.BR) está em desenvolvimento desde dezembro de É coordenado pela Associação para a Promoção da Excelência do Software Brasileiro (SOFTEX), com apoio do Ministério da Ciência e Tecnologia(MCT), da Financiadora de Estudos e Projetos(FINEP) e Banco Interamericano de Desenvolvimento (BID). O propósito do programa MPS.BR é a Melhoria de Processo do Software Brasileiro. Este programa mobilizador visa à criação e aprimoramento do modelo MPS, em conformidade com as Normas Internacionais ISO/IEC Software life cycle processes e ISO/IEC Process assessment, compatível com o CMMI, baseado nas melhores práticas da engenharia de software, adequado à realidade das empresas brasileiras; à disseminação e adoção do modelo MPS, a um custo razoável, em todas as regiões brasileiras, tanto em PMEs 1 (foco principal) quanto em grandes organizações privadas e governamentais. (CHAVES WEBER; KIVAL, 2008) A base técnica utilizada para a construção do MPS.BR é composta pelas normas NBR ISO/IEC Processo de Ciclo de Vida de Software e suas emendas 1 e 2 e a ISO/IEC Avaliação de Processo 2, portanto o modelo 1 Micro, pequenas e médias empresas. 2 Software Process Improvement and Capability Determination (SPICE) e seu Modelo de Avaliação de Processo de Software ISO/IEC

25 24 está totalmente aderente a essas normas. O MPS.BR também cobre o conteúdo do CMMI-SE/SW, através da inclusão e resultados de processos em relação aos processos da Norma NBR ISO/IEC12207, conforme Figura 5. Figura 5 - Modelo MPS.BR Níveis de Maturidade O MR-MPS define sete níveis de maturidade de processos para organizações que produzem software: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). O nível G é o primeiro estágio de maturidade e o nível A é o mais maduro. Cada um dos níveis de maturidade possui um conjunto de processos e atributos de processos que indicam onde a unidade organizacional tem que colocar esforço para melhoria, de forma a atender aos seus objetivos de negócio e ao MRMPS. Assim, os níveis de maturidade são definidos em duas dimensões: a dimensão de capacidade de processos e a dimensão de processos. O processo de avaliação é estagiado. Isto é, podemos definir os níveis de maturidade como estágios. Cada estágio possui seus processos e atributos necessários. Existe um nível de maturidade associado à organização como um todo. Cada nível tem uma distribuição de atributos como é mostrado no quadro a seguir. É importante observar que os atributos dos processos são cumulativos em

26 25 relação aos níveis. Isto é, o nível F tem os atributos do nível G adicionado com AP 2.2, e assim sucessivamente. Isso torna óbvio que para uma organização obter o nível F, necessita obter primeiro o G. Daí por diante. Quadro 02 Níveis de Maturidade

27 Nível G Parcialmente Gerenciado (Processos) O primeiro nível de maturidade é o G (Parcialmente Gerenciado), atuando na Gerência de Requisitos e Gerência de Projetos. Este nível é composto pelos processos mais críticos de gerência. De modo a melhorar o controle dos projetos, a organização deve implementar processos de apoio para o desenvolvimento de software. Estes processos constituem o próximo nível do MRMPS, o F (Gerenciado). O foco do Nível G está em planejar, executar e controlar o processo de desenvolvimento/manutenção de software, estabelecendo compromissos para a realização do processo e mantendo a situação das atividades do processo visíveis para a gerência. Gerência de Projetos (GPR) - O propósito do processo Gerência de Projetos é identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios no desempenho do projeto. Gerência de Requisitos (GRE) - 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 esses requisitos e os planos e produtos de trabalho do projeto Nível G Parcialmente Gerenciado (Capacidade) A dimensão de capacidade de processos do MR-MPS é constituída de um framework de medição. Dentro do framework, a medida da capacidade é baseada em um conjunto de atributos de processo (AP). O MR-MPS, em total conformidade com a ISO/IEC , define nove APs, cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizados para avaliar a implementação de um AP. Para medição dos processos do nível parcialmente gerenciado trabalha-se com dois deles: AP 1.1 O processo é executado medida de quanto o processo atinge seu propósito. AP 1.2 O processo é gerenciado medida de quanto à execução do processo é gerenciada.

28 27 Atributo de Processo (AP) Resultado do Atributo de Processo (RAP) AP 1.1 RAP 1 AP 1.2 RAP 2 RAP 3 RAP 4 RAP 5 RAP 6 RAP 7 RAP 8 RAP 1 O processo atinge seus resultados definidos. RAP 2 Existe uma política organizacional estabelecida e mantida para o processo. RAP 3 A execução do processo é planejada RAP 4 A execução do processo é monitorada e ajustes são realizados para atender aos planos. RAP 5 Os recursos necessários para a execução do processo são identificados e disponibilizados. RAP 6 As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência. RAP 7 A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto. RAP 8 Métodos adequados para monitorar a eficácia e adequação do processo são determinados.

29 28 2. PROCEDIMENTOS METODOLÓGICOS 2.1 TIPO DE PESQUISA O trabalho realizado classifica-se, quanto aos objetivos, como pesquisa exploratória, e quanto aos procedimentos metodológicos como estudo de caso. 2.2 DELIMITAÇÃO A pesquisa têm como objetivo a análise e melhoria dos processos de desenvolvimento da Empresa X. Portanto, definimos como universo a ser pesquisado, o setor de desenvolvimento desta empresa de software, incluindo metodologias, ferramentas e colaboradores. 2.3 TÉCNICA PARA COLETA DE DADOS Para realização do trabalho proposto foi feito um estudo do tema, através da pesquisa bibliográfica, aprofundando-se no assunto específico a ser trabalhado, o nível de maturidade G (Parcialmente Gerenciado), do Programa de Melhoria do Processo de Software Brasileiro. Posteriormente, foi feita uma análise da metodologia de desenvolvimento de sistemas da empresa X, estudando os processos de desenvolvimento praticados atualmente na empresa. Baseado no referencial teórico, foi realizada uma análise comparativa da metodologia de trabalho atual da empresa, com o modelo padrão para se adequar ao nível de maturidade G do MPS.BR, identificando as mudanças necessárias a serem implementadas, bem como, as melhorias e vantagens que essas mudanças proporcionarão a empresa. Foram adquiridos dados reais da empresa, através de uma pesquisa de campo, tendo como método de aquisição de dados: documentos relacionados ao método de desenvolvimento dos sistemas e depoimentos das pessoas envolvidas no processo. A análise foi realizada a partir do mês de março de 2009.

30 29 3. APRESENTAÇÃO E ANÁLISE DE DADOS 3.1 SITUAÇÃO ATUAL DA EMPRESA A análise e implantação do MPS (Nível G) foi realizada em uma empresa de desenvolvimento de sistemas, cujo nome não será divulgado. Vamos tratá-la como Empresa X por motivo de sigilo. A Empresa X, localizada na região norte no estado do Rio Grande do Sul, atua no ramo de desenvolvimento de software há aproximadamente 14 anos. Desde sua fundação atua exclusivamente no desenvolvimento de soluções para o Agronegócio, possuindo clientes nos diferentes setores da atividade agrícola em todo o Brasil. Atualmente, possui portfólio amplo de produtos diferenciados para uso da informação, com aplicativos para gerenciamento de clientes em cooperativas e revendas, automação de crédito rural e sistemas de gestão de propriedades rurais. Da época de sua concepção até o momento atual a Empresa X teve um crescimento significativo nesse segmento, aumentando consideravelmente o número de clientes e também a complexidade dos projetos a serem desenvolvidos. A falta de definição de seus processos de desenvolvimento de software, e também a falta de uso de uma padronização de documentação e metodologia de controle, ocasionou um quadro considerado preocupante: Aumento na manutenção de projetos finalizados; Novos projetos entravam em produção sem nenhum controle do escopo; Dificuldade no cumprimento de contratos com os clientes, devido aos contratos serem mal definidos; Dificuldade em realizar orçamento de novos projetos, devido à grande variação de custos; Dificuldade na definição e cumprimento de cronogramas; Dificuldade em controlar versões de sistemas e manter versões estáveis;

31 30 Solicitações de clientes não registradas corretamente, sem detalhamento dos requisitos; Mudanças nos requisitos sem controle e gerenciamento; Falta de padronização e organização dos documentos. Motivados por alguns insucessos e buscando aumentar seu portfólio, a empresa X se depara com a necessidade urgente de melhorar a qualidade de seus produtos e serviços, para assim conseguir atingir suas metas de crescimento, continuando a oferecer soluções que atendam as expectativas de seus clientes. Existe a necessidade de modelar um plano de melhoria de qualidade de processo de desenvolvimento de software. Dentre os planos existentes, foi escolhido o MPS.BR por se tratar de um modelo brasileiro, tem seu foco principal, embora não exclusivo, no grupo de micro, pequenas, médias empresas e compatível com os padrões aceitos internacionalmente. A análise realizada nos processos existentes na empresa, comparando com os padrões de desenvolvimento propostos pelo Nível G (Parcialmente Gerenciado) do MPS.BR, poderá contribuir para a tomada de decisão, no que diz respeito à implantação completa do projeto de melhoria de processos de software na empresa.

32 Fluxograma de Processos de Desenvolvimento Figura 6 Fluxograma Processos

33 32 A seguir temos uma descrição mais detalhada de cada item do fluxograma de processos de desenvolvimento da Figura 6, com definição e responsável: 1 - Gerar Requisição Criar documento referente à solicitação, que pode ser do cliente ou interna, contendo a descrição da mudança no sistema. A requisição de software pode ser originária de: - Bug (erro no sistema) - Solicitação do Cliente (Alteração ou Inovação) - Melhorias ou adequações legais necessárias - Novos Projetos Responsável: setores de implantação e suporte 2 Analisar a Requisição Analisar a viabilidade e necessidade de realização de casa requisição, validar as Requisições Responsável: coordenador do desenvolvimento 3 Gerar Cronograma Analisar a tarefa de forma mais detalhada Determinar o prazo para entrega Determinar o responsável pela tarefa Definir datas para a geração de versões Ferramenta utilizada: Microsoft Office Project Responsável: coordenador do desenvolvimento 4 Desenvolver a Tarefa Codificação Realizar Teste Operacional de 1 nível Responsável: desenvolvedores

34 33 5 Gerar Semi-Versão Compilar e gerar versão na máquina de cada programador e liberar para testes. Responsável: desenvolvedores 6 Liberar fontes para Geração de Versão Sincronizar banco de dados e aplicação com o servidor que centraliza os códigos fontes de todos os projetos. Responsável: desenvolvedores 7 Gerar Versão Sincronizar banco de dados e aplicação Gerar executável Disponibilizar versão no servidor Responsável: coordenador do desenvolvimento 8 Testar Versão Fazer uso do sistema na busca de erros conceituais e erros de codificação Responsável: setores de implantação e suporte Analisando o processo geral de desenvolvimento podemos facilmente identificar dois pontos bastante críticos, que precisam ser trabalhados isoladamente; a geração de cronograma (item 3) e a geração de versões (item 7). Problemas que já haviam aparecido como preocupantes na lista de dificuldades da empresa. Para melhor elaborar o cronograma e conseguir definir prazos mais realistas, é necessário um melhor detalhamento das solicitações que vem dos clientes e uma definição clara de prioridades. As versões precisam ser controladas com determinação de prazos para serem geradas e definição de requisições que serão liberadas em cada versão. Nos processos em que ocorre a integração com outros setores também podemos observar uma urgente necessidade de melhoria devido a uma grande falha de comunicação entre os mesmos: suporte, implantação e desenvolvimento. A solicitação do cliente, que gera uma requisição (item 1) para desenvolvimento, deve

35 34 ser detalhada e seguir um padrão de elaboração. Os testes dos sistemas (item 8) também estão bastante comprometidos, sendo necessária a definição de uma equipe de testes e a elaboração de um plano de testes. Existe a necessidade de elaboração de documentos padronizados que permitam a medição e controle dos processos. Também é necessária a geração de indicadores para medir a capacidade dos processos e a eficiência dos colaboradores envolvidos. 3.2 APLICAÇÃO DO MPS-BR NÍVEL G (PARCIALMENTE GERENCIADO) Inicialmente, foi definido o grupo responsável pela implantação do projeto de melhoria, com a missão de identificar, analisar e assegurar a execução de ações que garantam a melhoria contínua do processo de software da organização. Este grupo de trabalho foi o responsável pelo planejamento e execução das ações de melhoria de processo nos projetos da empresa. A primeira ação foi realizar uma reunião para oficializar o plano de melhoria e explicar para todos os colaboradores da empresa o que era um plano de melhoria de processos, e porque o MPS.BR foi escolhido, também foi explicada a importância da colaboração de todos para que as mudanças tivessem sucesso. Conforme podemos observar na Figura 7, após a definição da equipe de trabalho, foi encaminhado um trabalho de auto-avaliação, quando foram realizadas análises dos processos de desenvolvimento da empresa. Não foram encontrados os indicativos diretos existentes na empresa que satisfazem o nível G do MPS.BR, os procedimentos existentes eram iniciativas isoladas que não tinham sido padronizadas e não serviam de base para melhorias. Uma vez identificado e analisados os resultados, procedeu-se a definição das próximas tarefas para definição do plano de ação a ser executado para satisfazer o nível G do MPS.BR. Abaixo, as atividades seguintes: Identificar as práticas existentes na empresa; Comparar práticas existentes com resultados esperados nos processos do nível G do MPS.BR; Elaboração do plano de ação de melhorias;

36 35 Desenhar os processos; Treinar os colaboradores; Implantar processos melhorados em projetos pilotos; Fazer avaliações periódicas do uso do processo, propondo melhorias. Definição Equipe Implantação MPS.BR Nível G Atividades executadas sobre cada processo Auto-Avaliação Treinar Colaboradores Implantar Processo Práticas existentes X Resultados Esperados Desenhar Processo Avaliar Processo Plano de Ação de Melhoria Processo Atual Processo Melhorado Figura 7 Fluxograma de Trabalho Práticas Existentes X Resultados Esperados Para análise das práticas existentes na empresa e definição do plano de ação para melhoria do processo de desenvolvimento de software, avaliou-se de dois processos de software, Gerência de Projetos e Gerência de Requisitos, que são os

37 36 processos avaliados no nível de maturidade G (Parcialmente Gerenciado) do MPS.BR. Nos quadros 3 e 4 vamos visualizar os processos e seus resultados esperados, identificando se os processos existentes hoje na empresa estão em conformidade com a padronização, no caso de não conformidade, serão definidas as ações a serem tomadas para a adequação. A coluna Conformidade identifica se o Identificador (Id.) está sendo atendido, sim, não ou parcialmente. Quadro 03 Processos GPR PROCESSO: GERÊNCIA DE PROJETOS GPR Id. Resultados Esperados Conformidade Ações GPR1 GPR2 GPR3 GPR4 GPR5 GPR6 O escopo de trabalho do projeto é definido As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados O modelo e as fases do ciclo de vida do projeto são definidos O esforço e o custo para a execução das tarefas e dos produtos de trabalho são estimados com base em dados históricos ou referências técnicas O orçamento e o cronograma do projeto, incluindo marcos e pontos de controle, são estabelecidos e mantidos Os riscos do projeto são identificados e o seu NÂO NÃO PARCIAL NÃO NÃO NÃO - Definir escopo detalhado dos sistemas existentes - Definir Plano de Projeto (elaborar documento), que deverá ser adotado para novos sistemas - Definir método para dimensionar tarefas baseando-se na complexidade, número de requisitos e histórico de tarefas anteriores. - Redefinir processos de desenvolvimento software - Definir capacidade técnica de cada colaborador e custo de hora de trabalho, com o auxílio do setor de Recursos Humanos. - Definir itens no Plano de Projeto que contemplem Orçamento e Cronograma, estipulando datas para revisão do plano, acompanhamento e monitoramento. - Definir Plano de Gerenciamento de Riscos,

38 37 GPR7 GPR8 GPR9 GPR10 GPR11 GPR12 impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados. Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessário para executá-lo As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados Os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo questões de privacidade e segurança Planos para a execução do projeto são estabelecidos e reunidos no Plano de Projeto A viabilidade de atingir as metas do projeto, considerando as restrições e os recursos disponíveis, é avaliada. Se necessário ajustes são realizados O Plano de Projeto é revisado com todos os interessados e o compromisso com ele é obtido PARCIAL NÃO NÃO NÃO NÃO NÃO para que os riscos sejam identificados, classificados em relação à sua probabilidade e impacto e priorizados em função destas características - Elaborar documento com definição de perfil e capacidade técnica de cada colaborador (setor de RH). - No Plano de Projeto criar item para definição da Equipe do Projeto. - Definir no Plano de Projeto, no Item Orçamento a avaliação dos recursos necessários para o projeto, para poder planejar a aquisição de recursos especiais, quando necessário. - Planejar forma de distribuição dos dados relevantes do projeto, definir forma e periodicidade para distribuição. - Definir e descrever no Plano de Projeto as principais atividades do projeto e o plano para a entrega dessas atividades, com datas estabelecidas - Analisar viabilidade dos projetos baseando-se na nos recursos disponíveis e nas restrições identificadas no Plano de Projeto - Disseminar o Plano de Projeto entre as pessoas que fazem parte da equipe do projeto - Validar objetivo do projeto

39 38 com o cliente GPR13 GPR14 GPR15 GPR16 GPR17 O progresso do projeto é monitorado com relação ao estabelecido no Plano de Projeto e os resultados são documentados O envolvimento das partes interessadas no projeto é gerenciado Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento Registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas Ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecida, implementadas e acompanhadas até sua conclusão NÃO NÃO NÃO NÃO NÃO - Definir forma de acompanhamento do cronograma previsto e realizado, gerando comparativo. - Definir documento para envio ao cliente, que deve conter o andamento(status) das Entregas do Projeto - Definir periodicidade para realização de reuniões, onde deve ser avaliado o andamento para as entregas do projeto e verificado se os marcos estabelecidos no plano estão sendo mantidos. - Definir criação de Plano de Ação para a resolução de problemas que venham a ser identificados no monitoramento do projeto - Definir forma de controlar os problemas levantados, responsáveis, resultados e monitoramento das ações de correção.

40 39 Quadro 04 Processos GRE PROCESSO: GERÊNCIA DE REQUISITOS GRE Id. Resultados Esperados Conformidade Ações GRE1 GRE2 GRE3 GRE4 GRE5 O entendimento dos requisitos é obtido junto aos fornecedores de requisitos Os requisitos de software são aprovados utilizando critérios objetivos A rastreabilidade bidirecional 3 entre os requisitos e os produtos de trabalho é estabelecida e mantida Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos Mudanças de requisitos são gerenciadas ao longo do projeto. PARCIAL PARCIAL NÃO NÃO NÃO - Definir documento padrão pra a geração de requisitos - Adotar a criação de Casos de Uso e Modelos Entidade Relacionamento(MER) para o detalhamento de requisitos mais complexos - Validar requisitos com os fornecedores formalmente, através de documento ou - Criar checklist, contendo critérios objetivos, para auxiliar na aprovação dos requisitos identificados - Definir padrão de comentários que devem ser colocados em códigos fontes e bancos de dados, contendo informação sobre o requisito - Definir a realização de revisões para avaliar se mudanças nos requisitos tiveram impacto no projeto - Verificar se as mudanças nos requisitos foram incorporadas no escopo e no cronograma do projeto. - Definir forma de registrar mudanças que ocorrem em requisitos, dever ser avaliado influência em outros requisitos, expectativa dos interessados, esforço, cronograma, riscos e custo. Conforme identificado no quadro 3 e quadro 4 várias ações devem ser implementadas para melhoria dos processos de Gerenciamento de Projetos e de 3 O grau em que o relacionamento pode ser estabelecido entre dois ou mais produtos de desenvolvimento de software.