folha de aprovaÇÃo - cheila10.files.wordpress.com · folha de aprovaÇÃo . 3 qualidade de...

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 BRASIL EIRO

(MPS.BR) EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTE MAS

Erechim – RS

2009

1

CHEILA BOMBANA

ANÁLISE E IDENTIFICAÇÃO DAS VANTAGENS DA IMPLANTAÇÃ O DO

PROGRAMA DE MELHORIA DO PROCESSO DE SOFTWARE BRASIL EIRO

(MPS.BR) EM UMA EMPRESA DE DESENVOLVIMENTO DE SISTE MAS

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

2

FOLHA DE APROVAÇÃO

3

Qualidade de software não é um trilho

mas uma trilha.

(Autor desconhecido)

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.

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.

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

7

SUMÁRIO

INTRODUÇÃO............................................................................................................9

1. FUNDAMENTAÇÃO TEÓRICA.............................. ...........................................11

1.1 QUALIDADE .................................... .................................................................11

1.2 QUALIDADE DE SOFTWARE......................... ..................................................12

1.3 PROCESSO DE SOFTWARE........................................................................15

1.3.1 Ciclo de Processo de Software ...................... .............................................16

1.4 QUALIDADE DO PROCESSO X MODELOS DE MATURIDADE ...... ...........18

1.5 ISO 9000/ NBR 13596....................................................................................19

1.6 CMMI (CAPABILITY MATURITY MODEL INTEGRATION) ....... ...................21

1.7 MPS.BR (MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO )......22

1.7.1 Níveis de Maturidade............................... .....................................................24

1.7.2 Nível G – Parcialmente Gerenciado (Processos)...... .................................26

1.7.3 Nível G – Parcialmente Gerenciado (Capacidade)..... ................................26

2. PROCEDIMENTOS METODOLÓGICOS ..........................................................28

2.1 TIPO DE PESQUISA..........................................................................................28

2.2 DELIMITAÇÃO .................................. ...............................................................28

2.3 TÉCNICA PARA COLETA DE DADOS.................. ...........................................28

3. APRESENTAÇÃO E ANÁLISE DE DADOS .................... .................................29

3.1 SITUAÇÃO ATUAL DA EMPRESA.......................... .....................................29

3.1.1 Fluxograma de Processos de Desenvolvimento ......... ..............................31

3.2 APLICAÇÃO DO MPS-BR NÍVEL G (PARCIALMENTE GERENCIAD O).....34

3.2.1 Práticas Existentes X Resultados Esperados......... ...................................35

8

3.2.2 Ações de Melhoria.................................. ......................................................40

3.2.3 Ambiente de Apoio .................................. .....................................................45

3.2.4 Treinamento dos Colaboradores ...................... ..........................................45

3.3 AVALIAÇÃO DOS RESULTADOS........................... .....................................46

3.3.1 Resultados Obtidos................................. .....................................................46

3.3.2 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

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

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.

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)

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:

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.

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.

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.

16

1.3.1 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;

Produtos

e

Serviços A t i v i d a d e s

Pessoas Materiais Equipamentos Procedimentos

Requisitos

Idéias

Tempo

Figura 2 – Definição de Processo

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

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.

Medir o Processo

Controlar o Processo

Melhorar o Processo

Definir o Processo

Executar o Processo

Figura 3 – Ciclo de Processo

18

1.4 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.

Figura 4 – Qualidade de Software X Modelo de Maturidade

Qualidade do Produto de Software

Qualidade do Processo de Desenvolvimento de

Modelo de Maturidade (MPS.BR)

Gerenciamento de Projetos

É obtida por meio de

É alcançada mais facilmente se baseada em

Tem como base

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 13596

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 1991. 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 13596. (INTHURN; CÂNDIDA, 2001, p. 35)

20

A norma ISO/IEC 9126 / NBR 13596 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

conjunto de funções que satisfazem necessidades explícitas e implícitas, e suas propriedades específicas.

- Adequação - Acuraria (precisão) - Interoperabilidade - 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 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

- Inteligibilidade - Apreensibilidade (aprendizagem) - Operacionabilidade

Eficiência Relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, sob condições estabelecidas.

- Tempo - Recursos

Manutenibilidade Refere-se ao esforço necessário para fazer modificações específicas no software.

- Analisabilidade - Modificabilidade - Estabilidade - Testabilidade

Portabilidade Refere-se à habilidade do software de ser transferido de um ambiente para outro.

- 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

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;

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

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 2003. É 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 12207 – Software life cycle processes e ISO/IEC 15504 – 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 PMEs1 (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 12207 – Processo de Ciclo de Vida de Software e suas

emendas 1 e 2 e a ISO/IEC 15504 – 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 15504-5

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

1.7.1 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

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

26

1.7.2 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.

1.7.3 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 15504-2, 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.

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.

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.

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;

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.

31

3.1.1 Fluxograma de Processos de Desenvolvimento

Figura 6 – Fluxograma Processos

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


4 – Desenvolver a Tarefa

• Codificação

• Realizar Teste Operacional de 1° nível

Responsável: desenvolvedores

33

5 – Gerar Semi-Versão

• Compilar e gerar versão na máquina de cada programador e liberar para

testes.


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.


7 – Gerar Versão

• Sincronizar banco de dados e aplicação

• Gerar executável

• Disponibilizar versão no servidor


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

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;

35

• Desenhar os processos;

• Treinar os colaboradores;

• Implantar processos melhorados em projetos pilotos;

• Fazer avaliações periódicas do uso do processo, propondo melhorias.

X

Figura 7 – Fluxograma de Trabalho

3.2.1 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

Definição Equipe

Práticas existentes

Auto-Avaliação

Resultados Esperados

Plano de Ação de Melhoria

Processo Atual

Processo Melhorado

Implantação MPS.BR – Nível G Atividades executadas sobre cada processo

Treinar Colaboradores

Desenhar Processo

Avaliar Processo

Implantar Processo

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 O escopo de trabalho do projeto é definido

NÂO

- Definir escopo detalhado dos sistemas existentes - Definir Plano de Projeto (elaborar documento), que deverá ser adotado para novos sistemas

GPR2

As tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados

NÃO

- Definir método para dimensionar tarefas baseando-se na complexidade, número de requisitos e histórico de tarefas anteriores.

GPR3 O modelo e as fases do ciclo de vida do projeto são definidos

PARCIAL

- Redefinir processos de desenvolvimento software

GPR4

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

NÃO

- Definir capacidade técnica de cada colaborador e custo de hora de trabalho, com o auxílio do setor de Recursos Humanos.

GPR5

O orçamento e o cronograma do projeto, incluindo marcos e pontos de controle, são estabelecidos e mantidos

NÃO

- Definir itens no Plano de Projeto que contemplem Orçamento e Cronograma, estipulando datas para revisão do plano, acompanhamento e monitoramento.

GPR6 Os riscos do projeto são identificados e o seu

NÃO

- Definir Plano de Gerenciamento de Riscos,

37

impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados.

para que os riscos sejam identificados, classificados em relação à sua probabilidade e impacto e priorizados em função destas características

GPR7

Os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessário para executá-lo

PARCIAL

- 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.

GPR8

As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados

NÃO

- 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.

GPR9

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

NÃO

- Planejar forma de distribuição dos dados relevantes do projeto, definir forma e periodicidade para distribuição.

GPR10

Planos para a execução do projeto são estabelecidos e reunidos no Plano de Projeto

NÃO

- Definir e descrever no Plano de Projeto as principais atividades do projeto e o plano para a entrega dessas atividades, com datas estabelecidas

GPR11

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

NÃO

- Analisar viabilidade dos projetos baseando-se na nos recursos disponíveis e nas restrições identificadas no Plano de Projeto

GPR12

O Plano de Projeto é revisado com todos os interessados e o compromisso com ele é obtido

NÃO

- Disseminar o Plano de Projeto entre as pessoas que fazem parte da equipe do projeto - Validar objetivo do projeto

38

com o cliente

GPR13

O progresso do projeto é monitorado com relação ao estabelecido no Plano de Projeto e os resultados são documentados

NÃO

- Definir forma de acompanhamento do cronograma previsto e realizado, gerando comparativo.

GPR14 O envolvimento das partes interessadas no projeto é gerenciado

NÃO

- Definir documento para envio ao cliente, que deve conter o andamento(status) das Entregas do Projeto

GPR15

Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento

NÃO

- 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.

GPR16

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

NÃO

- Definir criação de Plano de Ação para a resolução de problemas que venham a ser identificados no monitoramento do projeto

GPR17

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

- Definir forma de controlar os problemas levantados, responsáveis, resultados e monitoramento das ações de correção.

39

Quadro 04 – Processos GRE

PROCESSO: GERÊNCIA DE REQUISITOS – GRE

Id. Resultados Esperados Conformidade Ações

GRE1

O entendimento dos requisitos é obtido junto aos fornecedores de requisitos

PARCIAL

- 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 e-mail

GRE2

Os requisitos de software são aprovados utilizando critérios objetivos

PARCIAL

- Criar checklist, contendo critérios objetivos, para auxiliar na aprovação dos requisitos identificados

GRE3

A rastreabilidade bidirecional 3 entre os requisitos e os produtos de trabalho é estabelecida e mantida

NÃO

- Definir padrão de comentários que devem ser colocados em códigos fontes e bancos de dados, contendo informação sobre o requisito

GRE4

Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos

NÃO

- 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.

GRE5 Mudanças de requisitos são gerenciadas ao longo do projeto.

NÃO

- 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.

40

Requisitos na Empresa X. Para isso foi criado um Plano de Ação definindo

responsáveis, prazos e forma de realização de cada uma dessas tarefas.

3.2.2 Ações de Melhoria

A etapa inicial, e com certeza uma das mais importantes no desenvolvimento

de projetos, é o levantamento de requisitos, por isso, existe uma grande

preocupação com essa fase nos modelos de maturidade, a definição errada de um

requisito pode levar todo o projeto ao fracasso.

A definição de um documento para o registro de requisitos é muito

importante, este documento será denominado DRE (Documento de Requisitos).

Além de padronizar todas as entradas de solicitações de clientes, vai permitir que os

requisitos estejam claramente definidos junto aos fornecedores de requisitos. A

descrição dos requisitos pode conter especificações de casos de uso e deve ser

detalhado conforme uma metodologia própria da empresa.

Tão importante quanto à identificação do requisito é a sua validação, para

identificação de viabilidade e relevância. Para isso, os requisitos identificados devem

ser avaliados com base em um conjunto de critérios objetivos, previamente

estabelecidos. Alguns exemplos de critérios são: possuir identificação única; estar

claro e apropriadamente declarado; não ser ambíguo; ser relevante; ser completo;

estar consistente com os demais requisitos; ser implementável, testável e rastreável,

etc. A ação de criação de checklist, para satisfazer o resultado do GRE2 ,

identificado no quadro 4 , deve se basear nos critérios citados acima.

Para atender aos resultados esperados do processo Gerência de Projetos foi

necessário a criação de vários modelos de documentos, que serão disponibilizados

como Templates, sendo o principal deles o Plano de Projeto (ANEXO A). O

documento é orientado ao escopo do projeto, e apresenta de forma completa e

organizada, toda a concepção, fundamentação, planejamento e meios de

acompanhamento e avaliação do projeto, devendo ser referência básica para sua

execução.

Projetos têm riscos e estes precisam ser identificados, analisados e

priorizados. Para isso foi gerado o Plano de Gerenciamento de Riscos (ANEXO B),

neste documento os riscos são descritos e classificados quanto a sua probabilidade

41

de ocorrência e gravidade, também deve ser descrito as respostas planejadas para

cada risco e uma reserva de contingência, atendendo assim ao resultado do GPR6.

O GPR13 trata do gerenciamento do projeto, acompanhamento das tarefas

realizadas. Para atender a esse resultado foi definida a utilização de uma ferramenta

de planejamento, o Microsoft Project, que permite definir cronograma, uso dos

recursos e orçamento. O uso dessa ferramenta permite o acompanhamento do

cronograma comparando previsto e realizado, também permite verificar o

cumprimento de marcos do projeto. Os registros desses acompanhamentos devem

ser realizados, permitindo assim a detecção e correção de problemas.

Para atender ao resultado esperado do GPR3 redefiniu-se o processo de

desenvolvimento. O modelo de processo de software adotado é uma mistura do

modelo cascata com o espiral. Conforme o modelo cascata, todos os requisitos de

software são devidamente avaliados para serem adicionados ao plano do projeto,

em seguida são analisados e projetados para serem construídos (codificados), e por

fim passam para as fases de teste e implantação, mas vendo o projeto em um

âmbito geral, podemos perceber que, os vários requisitos do projeto são

desenvolvidos e liberados para os testes e implantação periodicamente, ou seja,

existe um ciclo de avaliação, planejamento e liberação, que é característica do

modelo espiral.

O processo passa a ser documentado de forma padronizada e organizada,

utilizando os templates definidos pela equipe, como podemos visualizar nas

legendas das Figuras 8 e 9 com a denominação de Artefatos. Também é feita a

definição dos responsáveis pela realização de cada etapa do processo de forma

mais clara, através da atribuição de diferentes Papéis aos colaboradores que fazem

parte do projeto.

Para melhor entendimento do processo ele foi separado em duas etapas:

Elaboração e Construção.

O principal objetivo da fase de Elaboração é definir uma arquitetura que

ofereça uma base estável para Análise, Projeto e Implementação. A fase de

elaboração foi dividida em duas etapas, definidas como: Requisitos e Plano,

conforme ilustra a Figura 8.

Na etapa Requisitos é feito o levantamento inicial dos requisitos, da forma

mais detalhada possível. É elaborado o Documento de Requisitos (DRE) que

contém a definição das solicitações do cliente, em seguida o mesmo é verificado e

42

enviado para a aprovação do cliente. Se o DRE for aprovado pelo cliente passa

para a etapa seguinte, caso contrário volta para a elaboração.

A próxima etapa, denominada Plano, consiste na elaboração do Plano de

Projeto, e conta com o(s) Documento(s) de Requisitos(s) como artefatos de entrada,

está sub-dividida em:

• Especificar artefatos, ferramentas, interfaces e ambiente técnico;

• Definir Escopo;

• Identificar Riscos;

• Estimar custo e esforço;

• Definir esforço

• Definir ciclo de vida.

O passo seguinte é a verificação do Plano de Projeto, que consiste

basicamente em uma revisão do plano, se estiver em conformidade vai para a

reunião de aprovação. Essa reunião deve contar com a participação de todos os

interessados no projeto e tem como objetivo obter compromisso com o cliente e

desenvolvedores.

Ao finalizar essa etapa do processo devemos ter uma descrição detalhada

dos trabalhos a serem realizados, incluindo cronograma e orçamento, ou seja, um

plano detalhado para a fase de Construção.

43

Figura 8 - Processo Desenvolvimento – Elaboração

A fase de Construção trata da implementação efetiva, que vai transformar o

requisito em um produto de software, que pode ser novo ou integrado a um sistema

já existente. Conforme podemos observar na Figura 9, o processo de Construção

está dividido em três etapas: Análise e Projeto, Construção e Testes e Implantação.

Na Análise e Projeto é definido o projeto para desenvolvimento, o Documento

de Requisitos é incrementado com a definição de Modelo ER e detalhamento de

cada requisito, baseado no Plano de Projeto, após esse refinamento do

planejamento, o DRE é liberado para a Construção. As solicitações de mudanças

em requisitos também são tratadas nessa fase, onde acontece a análise do impacto

e em seguida as mudanças são incorporadas no DRE original e encaminhadas para

desenvolvimento.

44

A fase de Construção consiste na codificação do sistema propriamente dita,

trabalhando com a criação de banco de dados e diversas ferramentas de

desenvolvimento. Em paralelo com a codificação é elaborado o Plano de Teste, que

vai ser utilizado no teste parcial do sistema, realizado ainda nessa etapa.

Na fase final, Teste e Implantação, é realizada a verificação dos códigos

fontes, que devem estar em conformidade com o DRE e com o Plano de Projeto,

após essa verificação é gerada a versão que é liberada para o teste global. O Plano

de Testes volta a ser utilizado no teste global, todas as ocorrências detectadas

durante o teste devem ser registradas. Quando o requisito não é atendido, ou seja,

quando for detectado algum erro técnico ou de conceito, ele volta para a

implementação na fase anterior, em caso de conformidade, o requisito já pode ser

liberado para a implantação.

Figura 9 - Processos Desenvolvimento – Construção

45

Após a elaboração dos documentos necessários e a definição do novo

fluxograma do processo de desenvolvimento, essa nova metodologia de trabalho

passa a ser utilizada em projetos pilotos. A gerência da empresa optou por uma

implantação gradual da nova metodologia, aplicando em projetos menores, por

causar um grande impacto na cultura organizacional da mesma e também exigir um

tempo maior para dar resultado, sendo que, resultados completamente satisfatórios

serão alcançados apenas com a maturidade do projeto.

3.2.3 Ambiente de Apoio

Os arquivos Templates criados são disponibilizados em um ambiente comum

para todos os colaboradores envolvidos nos projetos. Para a criação dos

documentos baseados em planilhas foi usada a ferramenta Microsoft Excel 2003, e a

construção de diagramas através do Microsoft Visio 2007. Também como

ferramenta de apoio é utilizado o Microsoft Project 2007, que facilita a definição e

controle dos cronogramas dos projetos. O FreeVCS é uma ferramenta que auxilia no

processo de controle de versões e que foi utilizada para facilitar a rastreabildade

bidirecional.

3.2.4 Treinamento dos Colaboradores

A implantação de um projeto de melhoria de qualidade de software depende,

fundamentalmente, do envolvimento e da colaboração das pessoas envolvidas no

projeto. Por isso todos os membros da empresa devem tomar conhecimento, desde

a gerência até os responsáveis por tarefas operacionais.

Para o desenvolvimento desse projeto, foi utilizada uma estratégia para o

plano de gerenciamento de pessoas. Esse plano consiste em tornar conhecido a

todos os colaboradores da empresa o plano de melhoria, de forma clara e objetiva.

Foi efetuado um treinamento inicial explicando e esclarecendo o que é o MPS.BR

nível G e quais as vantagens que a empresa teria em implantar esse projeto, em

seguida foi trabalhado o plano de melhoria, já direcionando conforme as funções de

cada colaborador.

46

O treinamento foi ministrado pelo membro da equipe do projeto responsável

pela orientação e apoio aos colaboradores. Esse treinamento aconteceu

informalmente, utilizando métodos como: apresentação de slides utilizando

computador e Datashow.

3.3 AVALIAÇÃO DOS RESULTADOS

3.3.1 Resultados Obtidos

A implantação do programa de melhoria de processos proporcionou um maior

controle na geração das versões dos sistemas da empresa. As versões são geradas

a partir de um conjunto de Requisições(DRE) e os testes são realizados baseados

no Plano de Testes(PT). Essa metodologia de trabalho permite a geração de

indicadores de eficiência do setor de desenvolvimento.

Tabela 01 - Eficiência Desenvolvimento

SISTEMA X - Versão xx.x

Programador Requisições

(DRE) Pendências %

Pendente

Número de erros

(PT) %

Eficiência

Programador 1 8 0 0%

1,00 89%


1,00 99%


2,00 84%

Programador 4 5 0 0% - 100%



3,00 95%


TOTAL 38 0 0%

7,00 93%

47

Conforme podemos verificar na Tabela 4, a eficiência de cada programador é

medida baseada no número de erros detectados em cada requisito testado, levando

em consideração a complexidade e o tempo para sua construção. O percentual de

eficiência da versão gerada também pode ser medido, sendo de 93% para essa

versão analisada.

Esse indicador gerado vai servir como base para o setor de Recursos

Humanos avaliar a evolução dos programadores no que diz respeito a sua

capacidade técnica. Também serve como referência para a definição das equipes de

trabalho nos Planos de Projetos, onde esforço e custo para a realização das tarefas

devem ser estimados baseados em dados históricos.

A gerência de requisitos proporcionou maior entendimento e controle dos

mesmos, aumentando assim, a qualidade dos produtos de software gerados, e

conseqüentemente a satisfação dos clientes em relação ao mesmo. O retrabalho,

que acontecia com freqüência anteriormente devido à falta de esclarecimento dos

requisitos, foi reduzido de forma considerável.

A gerência de projetos possibilitou que projetos sejam cumpridos, no seu

devido tempo, com redução de custos e com melhor alocação de recursos humanos

e materiais. Os riscos de cada projeto passam a ser tratados com maior importância

e gerenciados de forma a diminuir a possibilidade de deficiências ou fracassos dos

projetos. O gerenciamento de projetos também permitiu um melhor relacionamento

entre as pessoas envolvidas, aumentado a comunicação e a interação entre os

setores de Desenvolvimento, Implantação e Suporte da empresa.

Podemos perceber um grande aumento na qualidade dos sistemas

desenvolvidos pela empresa. O número de erros, falhas e inconformidades com os

requisitos, foi reduzido consideravelmente, sendo que essa redução se deve a

melhoria de todo o processo de desenvolvimento e principalmente, a nova

metodologia de testes implantada.

Os projetos de software em que a nova metodologia de trabalho foi aplicada

ainda não tiveram a implantação concluída, mas parcialmente a empresa já pode

identificar os seguintes resultados:

• O cumprimento de cronogramas, com entregas dos projetos nos prazos

determinados;

48

• Cliente muito mais satisfeito, pois está participando mais do projeto,

conseguindo ter maior visibilidade do que está sendo feito e como está sendo

feito, acompanhando a evolução do mesmo;

• Implantação de softwares com maior qualidade, que atendem de maneira

satisfatória as necessidades dos clientes;

• Maior lucratividade da empresa em relação a trabalhos anteriores, pois os

projetos passam a ser melhor avaliados, o que permite a definição de

orçamentos mais precisos, facilitando a justificativa dos valores junto aos

clientes e;

• Colaboradores da empresa mais motivados, pois estão trabalhando de forma

mais organizada e conseguindo alcançar resultados positivos, gerando maior

perspectiva de crescimento.

A reorganização dos processos da empresa, que foi realizada com a

aplicação do projeto de melhoria, possibilita um maior controle do que está sendo

feito. Dessa forma, a geração de indicadores de resultados que interessam a

gerência e mantém a situação das atividades visíveis, pode ser obtida de maneira

mais fácil, rápida e precisa.

O custo real para a implantação desse projeto de melhoria se restringe a um

curso de MPS.BR feito por um dos colaboradores da empresa, que repassou o

conhecimento adquirido para os colegas. O tempo gasto pela equipe na concepção

e implementação do projeto, também pode ser considerado como custo, mas o

perceptível aumento da satisfação dos clientes e da lucratividade da empresa

mostra que a iniciativa de mudança trouxe várias vantagens e benefícios.

3.3.2 Adequações Necessárias

A avaliação dos primeiros resultados da implantação do programa de

melhoria de processo de software mostra a necessidade de alguns ajustes e

melhorias, tais como:

• Adequação de templates que inicialmente aparentavam satisfazer os

resultados esperados, mas com o uso efetivo apresentaram algumas

49

deficiências, como falta de informações importantes ou informações

irrelevantes que podem ser excluídas;

• Criação de novos templates que não foram definidos inicialmente e que são

importantes para a documentação do processo;

• Como trabalho futuro, será necessário a criação ou aquisição de um software

para fazer o gerenciamento total dos documentos utilizados no controle dos

processos, que possa eliminar o uso de templates e facilitar o

gerenciamento, de forma a diminuir o tempo gasto pelos colaboradores na

geração de documentação.

50

CONSIDERAÇÕES FINAIS

Neste estudo foi demonstrado a iniciativa da implantação do Programa de

Melhoria do Processo de Software Brasileiro (MPS.BR) em uma empresa de

desenvolvimento de sistemas e os primeiros resultados obtidos, demonstrando que

mesmo em pequenas empresas é necessário e possível basear-se em um modelo

de melhoria de processos.

De posse dos resultados obtidos por este trabalho, podemos listar como uma

de suas principais contribuições a verificação de que o MPS.BR pode ser

implementado em organizações de pequeno porte com boa eficiência, sem que gere

um grande overhead4 de atividades. Trata-se de um modelo de processo que pode

ser seguido, com equipes pequenas visando a melhoraria constante da qualidade.

Podemos observar que a questão norteadora do trabalho foi respondida e

seus objetivos alcançados. A análise realizada na empresa permitiu montar um

plano de melhorias, que aplicado, trouxe resultados positivos, benefícios

organizacionais e financeiros. Com o amadurecimento do processo implantado, a

empresa pode programar a evolução para o nível F (Gerenciado) do MPS.BR, e

assim sucessivamente até o mais alto nível de maturidade. É um processo lento e

gradativo, mas que proporcionará um processo de software maduro e um produto de

software qualificado.

A qualidade de software não é uma ciência exata, por isso, modelos de

maturidade não são garantia de sucesso absoluto para nenhuma empresa. Mas

certamente servem muito bem como um guia de referência, um caminho a ser

seguido por empresas que desejam melhorar seu desempenho operacional de forma

consistente ao longo do tempo.

Observando o trabalho realizado percebemos que qualquer iniciativa de

melhoria de processo de software está condenada ao fracasso se os executores das

atividades que estão sendo descritas no processo são excluídos das discussões

4 Excesso de tempo, de materiais e de informações ou condições impeditivas para executar uma determinada tarefa.

51

referentes às mesmas. Esta falha não pode ocorrer na condução de um projeto de

melhoria, consultores e implantadores devem estar sempre atentos para isso. Outra

questão que vale a pena ressaltar é referente ao acompanhamento das atividades,

planejamento e controle são “dois lados de uma mesma moeda”. Não há muito

sentido em planejar caso não haja um monitoramento constante que avalie se o

plano está de fato sendo concretizado ou se necessita de alguma ação de correção

de rota, estando tudo isso atrelado a alguma dose de formalização.

Cabe salientar que, não se deve encarar o uso de um modelo de maturidade,

a exemplo do MPS.BR, como fim em si mesmo, ou seja, o importante é a melhoria

dos processos e das organizações de maneira geral. A implantação de um modelo

vai alavancar a evolução da empresa, mas não pode garantir o sucesso caso não

haja envolvimento e colaboração, todos devem estar interessados na melhoria da

qualidade da empresa como um todo.

52

REFERENCIAS

CHAVES WEBER, Kival, MPS.BR – Melhoria de Processo de Software Brasileiro: Resultados Alcançados e Lições Aprendidas. 2008 . Disponível em: <http://www.softex.br/portal/softexweb/uploadDocuments/_mpsbr/Artigo_CLEI_2008_vFinal11.pdf>. Acesso em: 02 fev. 2009.

INTHURN, Cândida, Qualidade & Teste de Software . Florianópolis: Visual Books Ltda, 2001.

MICHAELIS: Moderno Dicionário da Língua Portuguesa. 2007. Disponível em: <http://michaelis.uol.com.br/moderno/portugues/index.php?lingua=portugues-portugues&palavra=qualidade >. Acesso em: 10 jan. 2009.

MOLINARI, Leonardo, Teste de Software : Produzindo Sistemas Melhores e mais Confiáveis. São Paulo: Editora Érica Ltda, 2003.

MOREIRA DE SOUZA, Adilson, Implementando o CMMI (Capability Maturity Mode Integration) : Como ferramenta para gerenciamento de projetos de Software. 2005 . Disponível em: < http://kplus.cosmo.com.br/materia.asp?co=30&rv=Vivencia>. Acesso em: 10 jan. 2009.

MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIR O: Guia de Implementação – Parte 1: Fundamentação para Implementação do Nível G do MR-MPS. 2009. Disponível em: < http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_de_Implementacao_Parte_1_2009.pdf>. Acesso em: 05 jul. 2009.

MPS.BR – MELHORIA DE PROCESSO DE SOFTWARE BRASILEIR O: Guia Geral. 2009. Disponível em: <http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf>. Acesso em: 05 jul. 2009.

NBR ISO 9000: Sistemas de Gestão da Qualidade – Fundamentos e Vocabulário. 2000. Disponível em: <http://br.geocities.com/admqualidade/NBRISO9000.doc>. Acesso em: 02 fev. 2009.

REZENDE, Denis Alcides, Engenharia de Software e Sistemas de Informação . Rio de Janeiro: Brasport Livro e Multimídia Ltda, 2005.

RIBEIRO, Adriele, Gerenciamento de Projetos, MPS.BR e Qualidade em Software. 2007. Disponível em: <http://www.pmimg.org.br/downloads/GP_MPS_e_Qualidade.ppt>. Acesso em: 06 jul. 2009.

53

ANEXOS

ANEXO A – PLANO DE PROJETO

56

ANEXO B – PLANO DE GERENCIAMENTO DE RISCOS