0
UNIJUÍ – UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL
DCEEng – DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE
CASO COM NÍVEL G DO MPS-BR COMO UMA ALTERNATIVA
PARA MICRO E PEQUENAS EMPRESAS
MonografiaJONATAN ELISANDRO FONSECA POMMER
Ijuí – RS 2011
JONATAN ELISANDRO FONSECA POMMER
APLICABILIDADE DA QUALIDADE DE SOFTWARE: ESTUDO DE
CASO COM NÍVEL G DO MPS-BR COMO UMA ALTERNATIVA
PARA MICRO E PEQUENAS EMPRESAS
Trabalho de Conclusão de Curso apresentado ao Curso de Informática - Sistemas de Informação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Informática - Sistemas de Informação.
Orientador: Ms. Romário Lopes Alcântara
Ijuí – RS 2011
2
Dedico este trabalho a minha família amada.
AGRADECIMENTOS
Gostaria de agradecer primeiramente a Deus por ter me dado a vida, e me abençoado com a inteligência, por sempre me ajudar nos momentos complicados de minha vida e por ter me dado uma família maravilhosa que tenho. Obrigado, Pai!
Aos meus dedicados pais, Edimir e Irani, que sempre estiveram comigo em todos os momentos de minha trajetória me apoiando e me dando força, pelo exemplo de luta e pelos ensinamentos de caráter e dignidade. Levarei esses ensinamentos por toda minha vida.
A minha irmã, Larissa, pela torcida e também pelo apoio.
A minha esposa Alcéli, que durante toda essa trajetória fez a diferença. Foi amiga, companheira me dando força e apoio nos piores momentos. Serei eternamente grato por cuidar de nossa filha Yasmin durante as noites em que estive ausente em detrimento aos meus estudos, seu amor e dedicação como mulher e como mãe levarei em meu coração para sempre. FAMÍLIA AMO VOCÊS ALÉM DA CONTA!
A minha querida vó Sibila, que foi minha segunda mãe, que me cuidou e me deu amor desde criança, serei grato o resto de minha vida.
Ao meu professor e orientador, Ms. Romário
Lopes Alcântara, pelos conhecimentos
construídos nas disciplinas de “Tópicos Avançados em Informática I e Engenharia de Software”, pela extrema paciência que teve e tem comigo, por sua amizade e principalmente por acreditar no meu potencial.
Agradeço, enfim, a todas as pessoas que participaram de forma direta e indireta para a concretização desta conquista! MEU MUITO OBRIGADO!
4
“O sucesso nasce do querer, da determinação e persistência em se chegar a um objetivo. Mesmo não atingindo o alvo, quem busca e vence obstáculos, no mínimo fará coisas admiráveis”. (José de Alencar)
RESUMO
Diante do cenário das micro e pequenas empresas que trabalham com desenvolvimento de software o objetivo deste trabalho foi descrever os conceitos de qualidade de software e discutir a implantação de um modelo de melhoria no processo de software em uma empresa de pequeno porte: o modelo MPS-BR (Melhoria de Processo de software Brasileiro). A empresa participante da pesquisa estando ciente da necessidade constante de investimentos em razão da concorrência e da qualidade dos produtos desenvolvidos por empresas e profissionais do segmento de TI buscou realizar um estudo de caso para futuramente implantar o MPS-BR em função do elevado número de projetos e orçamentos com o cronograma a cima do previsto, o modelo foi escolhido devido a sua proposta de melhorar o processo de software de uma forma gradual e com um baixo custo. O modelo se tornou uma alternativa viável para implantação de melhorias normatizando e criando regras para as boas práticas na aquisição, avaliação e implementação de software voltado á realidade da empresa.
Palavras chave: Qualidade de Software, Melhoria do Processo de Software,
6
ABSTRACT
Against the backdrop of micro and small companies working with software development the aim of this study was to describe the concepts of software quality and discuss the implementation of a model of software process improvement in a small business; model MPS-BR (software Process Improvement Brazilian). The company survey participant being aware of the constant need for investment because of competition and the quality of the products developed by companies and professionals in IT attempts to make a case study to further deploy the MPS-BR due to the high number of projects and budgets to the top of the planned schedule, the model was chosen because its proposal to improve the software process in a gradual manner and with a low cost. The model has become a viable alternative to the implementation of improvements and creating rules for standardizing the best practices in the acquisition, evaluation, and implementation of software directed to the reality of the company.
Keywords: Software Quality, Software Process Improvement, Software Process
LISTA DE ABREVIATURAS E SIGLAS
CMMI: Capability Maturity Model Integration Checklist: Lista de Checagem
ENGSOFT: Empresa Implementadora de Soluções em Melhoria de Processos GRE: Gerência de Requisitos
IAs: Instituições Avaliadoras
ISO: International Standartization Organization – Organização Internacional para
Padronização
IEC: International Electrotechnical Commission
IOGES: Instituição Organizadora de Grupos de Empresas do MPS-BR MPS-BR: Melhoria de Processos do Software Brasileiro
MR-MPS: Modelo de Referência – Melhoria de Processos do Software MA-MPS: Método de Avaliação – Melhoria de Processos do Software MN-MPS: Modelo de Negócio para Melhoria de Processo de Software SOFTEX: Associação para Promoção da Excelência do Software Brasileiro SPICE: Software Process Improvement and Capability Determination
8
LISTA DE TABELAS
Tabela 1 – Atributos relacionados à qualidade de software ... 17 Tabela 2 – Normas ISO 9000 para suporte ao desenvolvimento de software ... 19
LISTA DE FIGURAS
Figura 1 – Qualidade de software conforme McCall ... 17 Figura 2 – Componentes do MPS-BR ... 23 Figura 3 – Descreve os processos existentes em cada nível do MPS-BR ... 24 Figura 4 – Tabela referente ao custo de implementação e avaliação do MPS-BR ... 32
10
SUMÁRIO
1 INTRODUÇÃO ... 12
1.1 Justificativa ... 13
1.2 Definições dos Objetivos do Estudo ... 14
1.2.1 Objetivo Geral ... 14
1.2.2 Objetivos Específicos ... 14
1.3 Organização do Trabalho ... 14
2 ASPECTOS GERAIS DA QUALIDADE DE SOFTWARE ... 16
2.1 Fatores que Afetam a Qualidade de Software ... 17
2.2 Qualidade de Software e a Norma ISO ... 18
2.2.1 Norma ISO/IEC 12207 ... 19
2.2.2 Norma ISO/IEC 15504 ... 20
2.3 Qualidade de Software e o Modelo MPS-BR ... 20
2.3.1 Componentes do MPS-BR ... 22
2.3.2 Níveis de Maturidade ... 23
2.3.3 Nível G (Parcialmente Gerenciado) ... 24
2.3.4 Processo: Gerência de Projetos ... 25
2.3.5 Processo: Gerência de Requisitos – GRE ... 26
2.4 As Garantias e Padrões de Qualidade ... 27
2.4.1 Controle e Garantia de Qualidade ... 29
2.4.2 Garantia de Qualidade ... 30 2.4.3 Controle de Qualidade ... 30 2.4.4 Custo da Qualidade ... 31 3 METODOLOGIA ... 33 3.1 Tipo de Pesquisa ... 33 3.2 Procedimentos Metodológicos ... 34
4 ESTUDO DE CASO DA APLICABILIDADE ... 36
4.1 Descrição da Empresa ... 36
4.2 Objetivos da Implantação do MPS-BR ... 37
4.3 Processo de Implementação ... 38
4.4 Definição do Cronograma ... 39
4.6 Resultados Alcançados – Comparativo com Guia de Implementação – Nível
G ... 40
4.7 Dificuldades Encontradas ... 42
5 QUALIDADE DO MPS-BR (RELATOS DE ALGUNS USUÁRIOS) ... 44
CONCLUSÃO ... 45
REFERÊNCIAS BIBLIOGRÁFICAS ... 47
12
1 INTRODUÇÃO
Este trabalho tem como foco principal o modelo de melhoria e avaliação do processo de software (MPS-BR), aplicado a uma empresa de desenvolvimento de pequeno porte, levando em consideração alguns níveis de implantação para proporcionar uma compreensão dos conceitos básicos e das principais questões relacionadas com a qualidade do software brasileiro, a qualidade de software é uma subárea da engenharia de software que visa basicamente mensurar medir a qualidade do processo de desenvolvimento de software e para isso necessita de modelos para realizar tal tarefa.
Atualmente muitas organizações têm implementado esses serviços com o propósito de garantir a qualidade e assegurar que os objetivos planejados no início do projeto sejam cumpridos gerando sistemas de qualidade para obtenção da melhoria contínua de seus produtos e serviços, partindo desses princípios pensamos em trabalhar com o modelo MPS-BR focando a implementação do Nível G.
O MPS-Br (Melhoria do Processo de Software no Brasil) tem suas principais características baseados no SOFTEX que é responsável por promover a qualidade de software no Brasil sendo uma das norteadoras da melhoria do software no Brasil e responsável por mudar o perfil do software nacional, que vem se expandindo pelos países vizinhos.
Com o grande avanço tecnológico dos dias atuais as empresas se deparam com a necessidade de mudar suas estruturas e processos, saindo de uma visão antiga que busca eficiência nas áreas funcionais para uma visão nova, que busca a satisfação do cliente, como a competitividade é muito grande ela depende de uma ligação entre áreas produtivas até o produto final. Para as empresas criadoras de
software a qualidade não implica apenas na qualidade do produto como também na
qualidade dos processos de distribuição de software (SOFTEX, 2007).
Atualmente são vários os modelos de melhoria de processo de software disponíveis no mercado, dos quais se destacam: CMMI, ISO 15504, ISO 12207 e o modelo brasileiro MPS-BR que se adapta a realidade de diferentes empresas com enfoque nas micros, pequenas e médias. Todos têm em comum a busca da
qualidade nos processos, o que normalmente implica na melhoria da qualidade dos produtos.
1.1 Justificativa
Segundo Softex (2005), visando contribuir com soluções para o cenário brasileiro da qualidade de software, o projeto MPS-BR Melhoria do Processo de
Software Brasileiro, está em desenvolvimento desde 2003, por sete renomadas
instituições brasileiras, com competência complementares na melhoria de processo de software em empresas, que busca estabelecer um padrão de software baseado em guias que auxiliam para a medição da qualidade do produto.
Devido ao custo dessas certificações ser muito alto e muitas vezes se tornam inviáveis para empresas de micro, médio e pequeno porte, através de uma parceria entre a Softex, e o Governo e Universidades surgiu o projeto MPS-BR (Melhoria do Processo de Software Brasileiro) que é uma solução brasileira compatível com o modelo internacional CMMI, AL além de ser elaborada com base na realidade brasileira.
Proporcionando as empresas que trabalham com desenvolvimento de
software a oportunidade de adotar o modelo MPS-BR para ter um diferencial no
mercado competitivo, adquirindo essa certificação com um custo reduzido em relação às normas estrangeiras, o modelo MPS-BR vem tendo grande expansão nos últimos anos atingindo os países vizinhos como Chile, Peru, Costa Rica, Argentina e Uruguai. O Brasil esta entre um dos países cujo, desenvolvimento de software é um dos maiores do mundo, o que faz com que cada vez mais os clientes exijam produtos de melhor qualidade e cada vez mais complexos.
Com o uso de software de qualidade garantimos qualidade e segurança das transações, dos negócios, das pessoas envolvidas e mantém alta disponibilidade dos serviços, assim produtos e serviços são considerados aceitáveis se apresentarem desempenho dentro do esperado, o aumento de qualidade é acompanhado por aumento de produtividade, no caso de software isso pode significar reaproveitamento de código de programas, menor prazo para entrega, menor custo em manutenção e maior satisfação do cliente, que vai refletir em maior campo de abrangência no mercado competitivo.
1.2 Definições dos Objetivos do Estudo
1.2.1 Objetivo Geral
O objetivo geral desse trabalho é a descrição e discussão de ações e atividades relacionadas a implantação de melhorias no processo de desenvolvimento em uma empresa de pequeno porte utilizando o modelo MPS-BR. Com a implantação do modelo a empresa espera-se obter um aumento significativo na qualidade de seus produtos, uma melhoria no gerenciamento de seus projetos e, consequentemente, aumento do número de clientes.
O modelo MPS-BR foi escolhido, pois se adapta a realidade brasileira, tendo como proposta de melhorar o processo de software de micro, pequenas e médias empresas, de forma gradual atendendo suas necessidades de negócio.
1.2.2 Objetivos Específicos
Através da fundamentação teórica, pretendemos adquirir suporte para por em prática o desenvolvimento do assunto proposto neste estudo, revisionando a parte teórica estudada para o desenvolvimento do Trabalho de Conclusão de Curso e aplicação da mesma para análise dos problemas, sendo desenvolvido através de uma profunda análise, envolvendo o desenvolvimento de software, níveis de avaliação para medir a qualidade do processo de software, custos, benefícios, geração de novos negócios bem como as suas vantagens e desvantagens.
1.3 Organização do Trabalho
O conteúdo deste trabalho está estruturado em cinco capítulos:
• No Capítulo 1 foi feita uma breve introdução, apresentando a justificativa para a escolha do tema proposto para o desenvolvimento do trabalho bem como os objetivos do mesmo.
• O Capítulo 2 discute os conceitos de engenharia e qualidade de software, melhoria no processo de software e normas, modelos e métodos da qualidade de
software, o mesmo é baseado em um referencial teórico a fim de garantir o melhor
• A metodologia utilizada para a concepção deste trabalho é mostrada no Capítulo 3.
• No Capítulo 4 são apresentados os resultados e discussões acerca do estudo realizado.
16
2 ASPECTOS GERAIS DA QUALIDADE DE SOFTWARE
Assim, Qualidade de Software é uma área da Engenharia de Software que objetiva garantir a qualidade do mesmo, através de normas e processo de desenvolvimento. Mesmo o principal foco dos modelos seja no processo o objetivo é a qualidade no produto final, de modo que satisfaça as exigências do cliente. (PRESSMAN, 1995)
Desenvolver software com qualidade vem sendo um grande desafio do mercado atualmente, pois devemos cumprir prazos, atender a requisitos do software, estimar custos e recursos, o que não são tarefas fáceis, pois se faz necessário um controle muito grande dos processos que envolvem a fabricação do software, desde a sua elaboração até a entrega do produto final ao cliente.
No mercado atual, vários controles de qualidade são aplicados sobre o produto, geralmente quando este já está sendo utilizado e, o cliente está sofrendo as consequências de suas falhas. Isso ocorre porque se acredita que enquanto o produto (software) não estiver funcionando, não existe uma maneira de avaliar a sua qualidade, já, os testes necessários para garantir o seu correto funcionamento são feitos quando o software já está pronto.
Dados indicam que cerca de 50% a 70% dos esforços gastos em um programa serão perdidos depois que o programa for entregue ao cliente.
O processo deve ser determinado como uma padronização, mas perfeitamente adaptável às exigências de cada projeto ou cliente, garantindo a mesma qualidade em todos os casos (BERTOLLO, 2006).
Ao focarmos o processo, podemos garantir a qualidade desde o início do desenvolvimento do software, pois controlamos passo a passo e medimos a sua qualidade. Os testes são feitos ao final de cada etapa do desenvolvimento, evitando que erros sejam passados de uma fase para a outra, o que minimiza consideravelmente as falhas finais evitando assim que o cliente seja prejudicado por um mau comportamento do produto.
A qualidade dos processos que envolvem o desenvolvimento do software vai definir a qualidade do produto gerado, ou seja, um software altamente confiável, entregue dentro do prazo estabelecido, que atenda as expectativas do cliente e da organização como um todo, é indicativo de possibilidades de melhoria do produto.
Segundo Sommerville (2008), os atributos essenciais de um bom software são:
Tabela 1 – Atributos relacionados à qualidade de software
Característica do produto Descrição
Facilidade de manutenção O software deve ser desenvolvido para atender ás necessidades de mudança futura dos clientes Confiança Um software tem que ser confiável e seguro.
Não pode causar dano de nenhuma natureza Eficiência O software deve usar os recursos do sistema de
forma eficiente
Usabilidade O software deve apresentar interface e documentação adequada para o usuário Fonte: Sommerville (2008).
2.1 Fatores que Afetam a Qualidade de Software
Pressman (1995) caracteriza os fatores que afetam a qualidade em dois grupos amplos:
- fatores que podem ser medidos diretamente;
- fatores que podem apenas ser medidos indiretamente. Observando que em cada caso deve ocorrer medição.
Já Pressman (1995 apud McCALL, 1997) propôs alguns fatores que afetam a qualidade de software. Estes fatores focalizam três aspectos importantes de um
software: suas características operacionais, sua manutenibilidade e sua
adaptabilidade a novos ambientes, como mostra a figura 1.
Figura 1 – Qualidade de software conforme McCall Fonte: Pressman (1995).
Em relação a esses fatores apresentados na figura 1, Pressman (1995 apud McCALL, 1977) mostra as seguintes descrições:
- corretitude: à medida que um programa satisfaz sua especificação e cumpre os objetivos visados pelo cliente;
- confiabilidade: à medida que se pode esperar que um programa execute sua função pretendida com a precisão exigida;
- eficiência: a quantidade de recursos de computação e de código exigida para que um programa execute sua função;
- integridade: à medida que o acesso ao software ou a dados por pessoas não autorizadas pode ser controlado;
- usabilidade: o esforço para aprender, operar, preparar a entrada e interpretar a saída de um programa;
- manutenibilidade: o esforço exigido para localizar e reparar erros num programa;
- flexibilidade: o esforço exigido para modificar um programa operacional; - testabilidade: o esforço exigido para testar um programa a fim de garantir
que ele execute a sua função pretendida;
- portabilidade: o esforço exigido para transferir o programa de um ambiente de hardware ou software para outro;
- reusabilidade: à medida que um programa, ou parte de um programa pode ser reusado em outras aplicações;
- interoperabilidade: o esforço exigido para se acoplar um sistema a outro.
2.2 Qualidade de Software e a Norma ISO
A International Organization for Standardization (ISO) é uma organização não governamental, fundada em 23 de fevereiro de 1947, com sede em Genebra – Suíça. A existência da ISO foi motivada pela necessidade de referências internacionais para regulamentar obrigações contratuais entre fornecedores e compradores, que focalizassem a garantia de manutenção e uniformidade da qualidade de produtos.
As normas da ISO há muito tempo são relacionadas à qualidade. Atualmente, a norma ISO 9001:2000 é modelo base para auditorias de certificação da família ISO
9000. A norma é um padrão internacional que “específica requisitos para um sistema gerencial de qualidade de uma organização”.
Devido ao crescimento significativo das indústrias de software e levando-se em conta que a produção de software apresenta características peculiares, a ISO tem trabalhado na definição de várias normas que podem ser utilizadas como guias e padrões para diversas áreas de atuação dentro do contexto da ciência da computação.
A tabela abaixo apresenta algumas normas ISO aplicadas à qualidade de
software, focadas em produto ou processo de software.
Tabela 2 – Normas ISO 9000 para suporte ao desenvolvimento de software
Nome Descrição
Norma ISO/IEC 9126 (NBR 13596) Define as características de qualidade de software que devem estar presentes em todos os produtos
(funcionalidade, eficiência, usabilidade e portabilidade) Norma ISO/IEC 12119 Estabelece os requisitos de qualidade para pacotes de
software
Norma ISO/IEC 14598-5 Define um processo de avaliação da qualidade de produto de software
Norma ISO/IEC 12207 Define um processo de ciclo de vida de software Norma ISO/IEC 9000-3 Apresenta diretrizes para a aplicação da ISO 9001 por
organizações que desenvolvem software ao
desenvolvimento, fornecimento e manutenção de software Norma ISO 15504 Aprovada como norma em 2003 é focada na avaliação de
processos organizacionais Fonte: Roullier et al. (2003).
Dentre as normas citadas, é importante observar a norma ISO 12207 e a ISO 15504 que compuseram a base técnica utilizada para a construção do modelo MPS-BR utilizado neste trabalho.
2.2.1 Norma ISO/IEC 12207
A Norma ISO/IEC 12207 foi criada pela ISO e o International Electrotechnical
Commission (IEC) dentro de um esforço conjunto dessas organizações. O principal
objetivo da norma ISO/IEC 12207 é estabelecer uma estrutura comum para os processos de ciclo de vida de software, com uma terminologia bem definida, que pode ser referenciada pela indústria de software.
A estrutura contém processos, atividades, tarefas, propósitos e resultados que servem para ser aplicados durante a aquisição de um sistema que contém software,
de um produto de software independente ou de um serviço de software, e durante o fornecimento, desenvolvimento, operação e manutenção de produtos de software (MACHADO, 2003).
A norma descreve a arquitetura dos processos de ciclo de vida de software, mas não específica os detalhes de como implementar ou executar as atividades e tarefas incluídas no processo. Como também, não prescreve um modelo específico de ciclo de vida ou método de desenvolvimento de software.
As partes envolvidas é que são responsáveis pela adaptação dos processos, atividades e tarefas da norma para atender ao modelo de ciclo de vida para o projeto de software e isso é feito através do projeto de adaptação. As partes envolvidas são também responsáveis pela seleção e aplicação dos métodos de desenvolvimento
software (MACHADO, 2003).
2.2.2 Norma ISO/IEC 15504
Em setembro de 1992, a ISO – Standard for Information Technolog – realizou um estudo chamado “Necessidades e Exigências para uma Norma de Avaliação de Processos de Software”. O trabalho concluiu que era pertinente a elaboração de um padrão que fosse aplicável à melhoria de processos e à determinação da capacidade.
Este padrão deveria considerar os métodos e normas já existentes (como por exemplo, o SW-CMM® e a ISO 9001), abranger todos os processos de software e ser construído pelos especialistas que já desenvolviam e trabalhavam com os métodos e normas existentes à época.
Como resultado desse primeiro trabalho, a ISO iniciou em janeiro de 1993 o projeto SPICE (Software Process Improvement and Capability Determination) com o objetivo de produzir inicialmente um Relatório Técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 originando assim a Norma ISO/IEC 15504 (ISO/IEC, 2003).
2.3 Qualidade de Software e o Modelo MPS-BR
O MPS-BR é um programa para Melhoria de Processo do Software Brasileiro, está em desenvolvimento desde dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software
Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID).
(Guia Geral, Softex ,2009)
O MPS-BR tem como base requisitos de melhoria de software de acordo com o contexto das empresas brasileiras, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de
software (SOFTEX, 2007).
De acordo com o Guia Geral (SOFTEX, 2007), o MPS-BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. Dentro desse contexto, o MPS-BR possui três componentes:
- modelo de referência (MR-MPS); - método de avaliação (MA-MPS); e - modelo de negócio (M4-MPS).
O MPS-BR está descrito por meio de documentos em formato de guias:
- Guia Geral: contém a descrição geral do MPS-BR e detalha o Modelo de
Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação.
- Guia de Aquisição: descreve um processo de aquisição de software e
serviços correlatos. É descrito como forma de apoiar as instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS.
- Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS,
os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA).
- Guia de Implementação: composto de 7 partes, cada uma delas
descrevendo como implementar um determinado nível do MR-MPS.
Um dos objetivos do MPS-BR é atingir as micros, pequenas e médias empresas, fazendo um modelo que seja aplicável à indústria de software e conhecido tanto nacional como internacionalmente (WIKIPÉDIA, 2008).
Segundo Oliveira (2006) com a padronização de processos há uma melhoria significativa, pois só existindo uma padronização é possível:
- identificar possibilidades; - disseminar melhores práticas;
- melhorar controle e acompanhamento; - coibir práticas nocivas.
A melhoria busca estabelecer processos: - praticados, treinados, documentados; - efetivos, eficientes;
- apropriado às pessoas, flexíveis; - medidos, gerenciados, controlados - melhorados constantemente.
Assim, para começar com o uso de uma metodologia, é indispensável o apoio e o comprometimento de todos e, principalmente, da alta administração, para que ela se comprometa a abrir suas portas e mentes para garantir o sucesso da metodologia, considerando que esta se baseia na crença de que existe sempre uma maneira melhor de fazer qualquer coisa e que é imprescindível encontrar essa maneira. (SILVIANO, 2005)
2.3.1 Componentes do MPS-BR
O MPS-BR é baseado nas Normas 4BR ISO/IEC 12207, ISO/IEC 15504 (SPICE) e compatível com CMMI e está dividido em três componentes dantes citados:
- modelo de referência (MR-MPS); - método de avaliação (MA-MPS); e - modelo de negócio (MN-MPS).
Cada componente é descrito pela SOFTEX por meio de guias de documentos do MPS-BR, conforme mostra a figura (SOFTEX, 2007).
Figura 2 – Componentes do MPS-BR Fonte: Softex (2007).
De acordo com o Guia Geral da SOFTEX o Modelo de Referência (MR-MPS) contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o modelo. Ele contém as definições dos níveis de maturidade, processos e atributos do processo. O MR-MPS está em conformidade com os requisitos de modelos de referência de processo da norma ISO/IEC 15504 (SPICE) (SOFTEX, 2007).
O Guia de Aquisição é um documento complementar destinado a organizações que pretendam adquirir software e serviços correlatos. O Guia de Aquisição não contém requisitos do Modelo de Referência (MR-MPS), mas boas práticas para a aquisição de software e serviços correlatos (SOFTEX, 2007).
O Guia de Implementação, composto de sete partes descreve como programar cada um dos níveis do MR-MPS. O Guia de Avaliação contém o processo e o método de avaliação MA-MPS.
2.3.2 Níveis de Maturidade
Os níveis de maturidade são a combinação entre processos e sua capacidade, o progresso e o alcance de um nível de maturidade do MPS-BR se obtêm quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecido para aquele nível.
A existência de mais níveis é mais adequada para pequenas e médias empresas, pois garante maior visibilidade dos programas de melhoria e a redução dos custos de obtenção de cada nível de forma satisfatória.
Conforme o Guia de Implementação do MPS-BR (SOFTEX, 2007), os níveis de maturidade se assemelham a uma escada, nas quais estão os processos, e a evolução destes indica o grau em que o processo está.
O Modelo de Referência (MR) define sete níveis de maturidade como mostra a figura a seguir:
Figura 3 – Descreve os processos existentes em cada nível do MPS-BR Fonte: Softex (2007).
2.3.3 Nível G (Parcialmente Gerenciado)
De acordo com o Guia de Implementação MPS-BR (2009), o nível G é o primeiro nível de maturidade do MR-MPS. O objetivo da implantação deste nível é nortear a organização para que ela seja capaz de gerenciar parcialmente seus projetos de desenvolvimento de software.
O Nível G (Parcialmente Gerenciado) dá início ao processo de amadurecimento organizacional, com a utilização de normas e regras vem disciplinando atividades de Gerência de Projetos no que se refere a esforço, custos, cronograma equipe, dados e riscos, entre outros.
Segundo a Softex (2009) “ao final da implantação a organização será capaz de gerenciar parcialmente seus projetos de software”. A implantação do nível G apresenta dois grandes desafios para a organização: a necessidade da mudança cultural da empresa e a redefinição do que é projeto para a organização.
O ciclo de vida escolhido deve ser capaz de gerar os produtos de trabalho especificados para que possa alcançar os objetivos propostos e esperados, apesar de não ter nenhum controle formal da qualidade, e de modo geral incluir atividades
básicas de teste do produto em construção. Estas atividades devem ser estimadas e integradas ao plano do projeto, que é revisado por todos os interessados e utilizado ao longo do projeto como referência para acompanhamento das atividades.
De acordo com o Guia de Implementação (SOFTEX, 2007) o nível G abrange dois processos:
2.3.4 Processo: Gerência de Projetos
•••• Propósito
Tem como objetivo da gerência de projetos identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos, que um projeto necessita para produzir um produto ou serviço, no contexto dos seus requisitos e restrições do projeto, bem como prover informações sobre o andamento do mesmo, que permitam a realização de correções quando houver desvios significativos no desempenho do projeto.
Ciclo de vida em geral inclui atividades básicas de teste, porém sem nenhum controle formal da qualidade. O Plano do projeto é revisado por todos os interessados e utilizado ao longo do projeto como referência para acompanhamento.
•••• Resultados esperados
- GPR 1: o escopo do trabalho para o projeto está definido;
- GPR 2: o escopo, os produtos de trabalho e as tarefas do projeto são estimados, através de métodos apropriados;
- GPR 3: as fases do ciclo de vida do projeto são definidas;
- GPR 4: 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;
- GPR 5: as tarefas, os recursos e a infraestrutura necessários para completar o trabalho são planejados;
- GPR 6: o cronograma e o orçamento do projeto são estabelecidos e mantidos;
- GPR 7: os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridades de tratamento são determinados e documentados;
- GPR 8: os dados relevantes do projeto são identificados, coletados, armazenados e distribuídos. Um mecanismo é estabelecido para acessá-los, incluindo (se pertinente) questões de privacidade e segurança;
- GPR 9: os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;
- GPR 10: o esforço e o custo para os produtos de trabalho e tarefas são estimados baseados em dados históricos ou referências técnicas;
- GPR 11: o envolvimento dos interessados no projeto é planejado;
- GPR 12: o planejamento do projeto é revisado com todos os interessados e o compromisso com o mesmo é obtido;
- GPR 13: o planejamento do projeto é monitorado no que se referem a cronograma, custos, recursos, riscos, envolvimento dos interessados e dados;
- GPR 14: revisões são realizadas em marcos do projeto conforme estabelecido no planejamento;
- GPR 15: registros e análise dos problemas identificados nas monitorações são estabelecidos;
- GPR 16: ações corretivas são estabelecidas quando necessário e gerenciadas até a sua conclusão.
2.3.5 Processo: Gerência de Requisitos – GRE
•••• Propósito
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.
Requisitos são aprovados segundo critérios objetivos Planos e produtos de trabalho gerados são revisados, visando identificar e corrigir inconsistências em relação aos requisitos.
•••• Resultados esperados
- GRE 1: uma comunicação contínua com os fornecedores de requisitos é estabelecida;
- GRE 3: a aceitação dos requisitos é estabelecida por meio de critérios objetivos;
- GRE 4: o comprometimento com os requisitos é estabelecido e mantido; - GRE 5: a rastreabilidade entre os requisitos, os planos do projeto e os
produtos de trabalho é estabelecida e mantida;
- GRE 6: inconsistências entre os planos do projeto, os produtos de trabalho e os requisitos são identificadas e corrigidas;
- GRE 7: mudanças nos requisitos são gerenciadas ao longo do projeto. Contudo esses processos são os mais importantes para a aplicação do nível G, eles que irão adequar a empresa aos processos do MPS-BR. Após realizar a análise desses itens faz-se uma avaliação para verificar se a empresa se enquadra em algum e verifica também o que deve ser feito para melhorar esses processos, para torná-los prática no dia-a-dia da empresa.
Também é necessário definir ferramentas que serão utilizadas para produção, armazenamento, documentação dos softwares; outro aspecto importante é deixar todos os colaboradores cientes das mudanças que vão ocorrer e principalmente adequá-los ao novo sistema.
2.4 As Garantias e Padrões de Qualidade
Podemos dizer que, as atividades de garantia de qualidade definem uma estrutura para atingir a qualidade de software. Esse processo envolve definir ou selecionar os padrões que devem ser aplicados no processo de desenvolvimento de
software ou produtos de software. Os processos podem ser apoiados pelo uso de
ferramentas que integram o conhecimento dos padrões de qualidade (SOMMERVILLE, 2003).
Sommerville (2003) também destaca dois tipos de padrões que podem ser estabelecidos como parte do processo de garantia de qualidade:
- Padrões de Produto: são os padrões que se aplicam ao produto de software em desenvolvimento. Inclui padrões de documentos, como a estrutura do
documento de requisitos a ser produzido; padrões de documentação, como um cabeçalho-padrão de comentário para uma definição de classe de objeto, e padrões de codificação, que definem como uma linguagem de programação deve ser utilizada.
- Padrões de Processo: são os padrões que definem os processos a serem
seguidos durante o desenvolvimento de software. Eles podem incluir definições de especificação, processos de projeto e validação, e uma descrição dos documentos que devem ser gerados no curso desses processos.
A garantia da qualidade do software é uma atividade que deve ser levada em consideração ao longo de todo o processo de engenharia de software, processo esse que abrange métodos e ferramentas de análise, projeto, codificação e testes.
Qualidade é o grau no qual um conjunto de características inerentes satisfaz aos requisitos. Ou seja, pode-se afirmar que se algum produto ou serviço atende aos requisitos especificados, este mesmo produto ou serviço possui a qualidade desejada.
A qualidade pode ser medida através do nível de satisfação em que as pessoas avaliam determinado produto ou serviço oferecido. No entanto, perante a ótica de visão esse produto ou serviço pode ter qualidade para algumas pessoas e para outras nem tanto, ou seja, a qualidade é algo subjetivo.
Tian (2005) afirma que as expectativas de qualidade para sistemas de
software estão relativamente ligadas em dois aspectos:
a) “o sistema de software deve fazer o que é suposto que se faça. Em outras palavras, eles devem fazer de forma correta as coisas” (TIAN, 2005, p. 35);
b) “eles devem realizar estas tarefas específicas corretamente e satisfatoriamente. Em outras palavras, eles devem fazer as coisas certas” (TIAN, 2005, p. 35).
Indiretamente, as duas afirmações de Tian (2005) estão com base na ISO 9000:2005, sendo que o sistema deve fazer o que se espera que ele faça, de acordo com seus requisitos levantados e especificados levando em conta as exigências do cliente final bem como as necessidades do negócio.
Levando em consideração a qualidade possui alguns princípios básicos, como:
- tentar prevenir defeitos ao invés de consertá-los, pois isso gera retrabalho, perda de tempo e dinheiro;
- ter a certeza que os defeitos que foram encontrados, sejam corrigidos o mais rápido possível, buscando sempre trabalhar com redundância para garantir a eficiência e eficácia, tendo soluções alternativas;
- estabelecer e eliminar as causas, bem como os sintomas dos defeitos, buscar estar em contato com o usuário final para se chegar ao resultado esperado;
- auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos, levando em consideração os padrões e normas estabelecidas para o desenvolvimento do produto software.
Contudo a qualidade, seja ela vista no contexto de software ou de produtos e serviços, hoje não mais é uma obrigação e sim, um diferencial das empresas, se tornou um padrão em qualquer ramo de atividade e indústria, sendo assim necessária para garantir a satisfação do cliente. Qualidade hoje em dia, não é apenas um diferencial de mercado para as empresas conseguirem vender e lucrar mais, é um pré-requisito que se deve conquistar para conseguir colocar o produto ou serviço no Mercado Global.
2.4.1 Controle e Garantia de Qualidade
Para Sommerville (2003) o controle de qualidade envolve supervisionar o processo de desenvolvimento de software a fim de assegurar que os procedimentos e os padrões de garantia e qualidade de software sejam seguidos. Os produtos elaborados pelo processo de software são verificados em relação aos padrões definidos de projeto, no processo de controle de qualidade.
O “Controle da Qualidade” define as atividades de avaliação da qualidade que serão executadas ao longo do projeto, visando desenvolver produtos e processos para atender às necessidades dos clientes. Inclui inicialmente entender essas necessidades, desenvolver características de produto a elas alinhadas e identificar processos e padrões capazes de produzi-las.
Pressman (2005) sugere que a qualidade de software seja implementada e não somente uma ideia ou desejo que uma organização venha a ter.
Sendo assim, podemos ainda definir como Garantia de Qualidade “o conjunto de atividades de apoio para fornecer confiança de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido” (LEWIS, 2004, p. 18).
A “Garantia da Qualidade” visa avaliar a aderência das atividades executadas e dos produtos de trabalho gerados a padrões, processos, procedimentos e requisitos estabelecidos e aplicáveis. Além de verificar se o processo está adequado, sendo seguido e trabalhando a favor da organização (evitando retrabalho, melhorando custos e prazos), busca-se identificar desvios o quanto antes e acompanhar a sua resolução até que sejam concluídos.
O controle da qualidade é projetado para detectar defeitos e corrigir esses defeitos encontrados, enquanto que a garantida da qualidade é orientada através da prevenção de defeitos.
Visando comparar estes dois conceitos, vamos levantar e apresentar as principais diferenças entre “garantia” e “controle” da qualidade.
2.4.2 Garantia de Qualidade
- Foco: garantir e estabelecer que o projeto empregue todos os processos e padrões necessários para atender os requisitos.
- Forma mais usual: auditoria de processo e de produto, sendo orientada por checklist.
- Utilizar métodos, procedimentos e padrões para comparar previsto com realizado.
- Assegurar que o processo empregado é definido e apropriado. - É orientada a processos, visando à prevenção de defeitos.
- Cuida da monitoração e melhoria dos processos e padrões empregados. - Assegura que se faz da maneira correta (diz o que faz e faz o que diz).
2.4.3 Controle de Qualidade
- Foco: descobrir defeitos em produtos de trabalho gerados ao longo do projeto e eliminar suas causas.
- Forma mais usual: testes diversos e revisões por pares (simples, inspeção, walkthrough).
- Utiliza casos de teste, checklist para compara o esperado com o obtido. - Assegura que os produtos de trabalho gerados então consistentes e
- É orientado a produto, visando à detecção e correção de defeitos.
- Cuida da monitoração e da consistência dos produtos em relação aos requisitos e a utilização.
- Assegurar que se façam as coisas certas (faz certo o que atende a necessidade e o uso pretendido).
A garantia da qualidade fornece ao controle da qualidade evidência e confiança na habilidade do processo utilizado em gerar um produto que atenda aos requisitos definidos.
2.4.4 Custo da Qualidade
Levando em consideração, que os custos estão diretamente ligados e envolvidos na procura da qualidade, sendo assim seguindo normas e padrões, vamos ver alguns fatores importantes que influenciam diretamente no custo de uma aplicação levando alguns fatores em consideração.
•••• Prevenção - Planejamento.
- Revisões técnicas formais. - Equipe de testes.
- Formação.
•••• Avaliação
- Inspeção no processo e entre os processos.
- Calibragem, afinação e manutenção de equipamentos. - Testes.
•••• Falhas - Retrabalho. - Reparação.
- Análise das modalidades de falhas.
•••• Externas
- Gestão de queixas.
- Devolução e substituição de produtos. - Linhas de ajuda.
De acordo com Alcântara (2010) o MPS-BR envolve dois custos, de implementação no qual uma Instituição Implementadora é contratada para realizar a implementação e custo com a avaliação, em que uma Instituição Avaliadora realiza a avaliação para capacitar a empresa a um determinado nível.
Através da tabela a seguir podemos verificar os custos:
Figura 4 – Tabela referente ao custo de implementação e avaliação do MPS-BR Fonte: Softex (2009).
3 METODOLOGIA
A metodologia empregada é um estudo de caso, cujo corpus se constitui de dados coletados através de um questionário, que foi aplicado em uma pequena empresa no setor específico de desenvolvimento de software. Fundamenta-se em teorias tecnológicas como Softex, Pressman, Bertollo, Sommerville, Oliveira, Tian, entre outros que deram sustentação para a realização da pesquisa monográfica. Também apresenta a descrição de como o estudo de caso foi realizado.
3.1 Tipo de Pesquisa
O método de pesquisa utilizado neste trabalho foi o estudo de caso fundamentado em pesquisa bibliográfica e documental.
Segundo Yin (2001), o estudo de caso representa uma investigação empírica e compreende um método abrangente, com a lógica do planejamento, da coleta e da análise de dados. Pode incluir tanto estudos de caso único quanto de múltiplos, assim como abordagens quantitativas e qualitativas de pesquisa.
Um estudo de caso é considerado uma importante ferramenta para os pesquisadores que têm por finalidade entender “como” e “por que” funcionam as “coisas”.
Conforme Jung (2004), a pesquisa bibliográfica tem por finalidade principal formar uma consistente base “mental” a partir daquilo que é existente, e oportunizar uma ampla aquisição de conhecimentos para o entendimento substancial do assunto, viabilizando ao pesquisador “ousar” ao propor novos argumentos que justifiquem as descobertas.
Santos (2000) refere que:
Documentos são as fontes de informação que ainda não receberam organização, tratamento analítico e publicação. São fontes documentais as tabelas estatísticas, relatórios de empresas, documentos informativos arquivados em repartições públicas, associações, igrejas, hospitais, sindicatos; fotografias, epitáfios, obras originais de qualquer natureza, correspondência pessoal ou comercial etc. A pesquisa documental é a que se serve dessas fontes.
3.2 Procedimentos Metodológicos
A pesquisa foi realizada no período de janeiro a novembro de 2011.
Inicialmente, foi realizada uma revisão bibliográfica sobre os aspectos da engenharia de software, qualidade de software, melhoria do processo de software e normas, modelos e métodos da qualidade de software. Foram consultados livros, monografias, teses e dissertações disponibilizadas na Internet e na literatura de modo geral. Em seguida, buscou-se conhecer a empresa, através de algumas reuniões em alguns momentos em sua sede ou através do estudo e análise de seus documentos de processos obtidos ao longo dos anos.
Para levantar o modelo atual da organização duas metodologias foram utilizadas. Na primeira, quantitativa, foi elaborado um questionário cujas perguntas tinham o objetivo de identificar quais resultados esperados do processo do MPS-BR estão conformes (Anexo I). O questionário foi elaborado de acordo com o Guia de Implementação – Parte 1 [MPS-BR 2009] do nível G. Dessa forma, poderia se comparar o estado atual com o estado desejado, que é o nível Parcialmente Gerenciado.
Na segunda metodologia, qualitativa, as informações foram obtidas através de conversas informais com os membros da equipe de desenvolvimento. Foram discutidos os principais problemas e dificuldades que eles podiam identificar cotidiano do trabalho.
Busca-se analisar e descrever o processo de desenvolvimento de software da empresa, com foco nas implantações de melhorias utilizando o modelo MPS-BR.
Para realizar o estudo proposto foram acompanhados e investigados os seguintes procedimentos:
- realização de reuniões com a direção para a aprovação do trabalho na empresa e a definição dos recursos necessários para o desenvolvimento; - realização de diagnóstico da empresa para a elaboração do planejamento
das atividades e identificar o estado atual da empresa, com relação aos elementos requeridos no nível G do modelo MPS-BR;
- elaboração de um Plano de Ação, onde foram descritas as atividades para a execução do projeto, a estimativa de duração e um cronograma. O Plano de Ação serviu também como base para o acompanhamento do projeto durante a sua execução;
- institucionalização do processo através da escolha de um projeto, nomeado como projeto piloto, onde foram verificados o uso do processo, as inconsistências e erros existentes.
36
4 ESTUDO DE CASO DA APLICABILIDADE
A partir desta seção, apresenta-se o estudo de caso realizado e as principais atividades que foram executadas para alcançar a melhoria do processo de desenvolvimento de software da empresa, também serão mostrados os resultados do estudo de caso: o processo definido e seu plano de ação.
4.1 Descrição da Empresa
Para a realização do estudo de caso, foi selecionada uma microempresa da área de tecnologia da informação. Essa empresa se chama BKR Sistemas, se encontra instalada no município de Chiapetta – RS.
Seu principal ramo de atuação é o desenvolvimento de software desenvolvendo soluções eficientes, se destacando pelo uso diferenciado da informática com comprometimento com as metas e resultados que trazem grandes transformações gerando retornos financeiros e operacionais para seus clientes, a maioria dos produtos desenvolvidos são voltados para setores públicos e automação comercial.
Seus principais clientes são repartições públicas. A maioria deles prefeituras de cidades do estado do Rio Grande do Sul, tanto do interior como da zona metropolitana (Grande Porto Alegre).
A empresa conta com uma equipe de desenvolvimento de software formada por quatro pessoas, podemos descrever o organograma em três níveis. No primeiro nível, se encontra a diretoria, no segundo nível estão os desenvolvedores e no terceiro está a equipe de suporte.
Existem dois tipos de atividades de desenvolvimento de software na organização. A primeira é o desenvolvimento de um novo produto de software, onde uma necessidade é identificada, e a solução é desenvolvida através de um novo produto. Na segunda, acontece quando um contato com um cliente é realizado a fim de apresentar o produto e a partir dai realizar determinadas mudanças conforme a necessidade do cliente.
Apesar da organização ter mais de 12 anos no mercado e ter concluído projetos de desenvolvimentos, é possível apontar várias falhas no processo. Entre elas podemos destacar:
- gerência de projetos rudimentar; - não existe gerência de requisitos;
- dificuldade de estimar o prazo das tarefas;
- existência de retrabalho devido ao reuso de código ineficiente.
A necessidade de mudança e melhoria no processo de software da motivação para o início da implementação. Nesse caso, podemos verificar a necessidade de melhoria motivada pela ineficiência do processo e também é interessante para a empresa a adequação ao nível G do MPS-BR, garantindo que o processo é gerenciado.
O patrocinador do esforço pode ser identificado como a diretoria da organização. Ela deverá fornecer os recursos necessários para o projeto, além disso, deverá dispor de parte de seu tempo para participar das atividades do processo de mudança e também terá que se adaptar às mudanças sugeridas pelo esforço.
Devido ao pequeno quadro de funcionários da empresa, não será necessário alocar muitas pessoas para o projeto de mudança, todos os recursos físicos necessários para o esforço estão disponíveis na empresa.
4.2 Objetivos da Implantação do MPS-BR
Como a equipe de desenvolvimento não segue nenhum padrão de processo de desenvolvimento de software e não possui nenhuma certificação os projetos acabam ficando mal documentados, mal gerenciados e muitas vezes se deparam com problemas do tipo:
- os projetos entram em produção sem nenhum controle de escopo;
- os requisitos não são registrados e nem as mudanças não são gerenciadas de forma correta;
- atrasos no cronograma dos projetos;
- falta de definição nos contratos com os clientes que solicitam o serviço; - muito retrabalho com manutenção em projetos finalizados.
Diante dessas dificuldades encontradas no cotidiano, a diretoria decidiu modelar um plano de melhoria de qualidade de processos de software. A fim de alcançar os seguintes objetivos:
- aumento da qualidade do produto entregue; - diminuição do retrabalho;
- maior produtividade;
- redução do tempo para atender o mercado; - maior competitividade;
- maior precisão nas estimativas;
- monitoramento da satisfação do cliente.
Espera-se que com a implantação do MPS-BR e em particular do nível G, a gerência tenha maior controle sobre o projeto e os requisitos sejam controlados de forma adequada. Tal meta só será possível com a motivação de toda equipe, esta meta pretende ser alcançada através de reuniões onde serão expostos os benefícios da implantação de um programa de melhoria.
4.3 Processo de Implementação
Definimos o processo de implantação em algumas etapas:
- entrevista e relatório: levantamento e diagnóstico inicial da empresa;
- treinamento: foi realizado um treinamento informal para os membros da equipe, com o objetivo de orientá-los sobre a utilização dos novos modelos, durante todo o processo de implantação um membro da equipe responsável pelo projeto, esteve a disposição para acompanhar e esclarecer as duvidas que surgiam por parte da equipe, sempre motivando todos com a ideia de que o sucesso do projeto dependia do empenho de todos;
- projeto piloto: entre os projetos existentes e em andamento na empresa foi escolhido 1 para ser chamado de “Projeto Piloto”, levando em consideração toda a documentação de processos existentes tendo como produto final um book do mesmo;
- consultoria para implantação: como se trata de um estudo de caso hipotético, não tivemos o acompanhamento de uma equipe específica para avaliação dos processos.
4.4 Definição do Cronograma
Segundo Vasconcelos et al. (2006), o cronograma divide o projeto em tarefas e estima o tempo e os recursos requeridos para terminar cada tarefa. Surgindo novas possibilidades de adequação, devem ser definidas tarefas concorrentes de modo a fazer o melhor uso do pessoal, cronograma é uma atividade contínua, desde a concepção inicial do sistema até a sua entrega.
Portanto, a definição de bons cronogramas depende da percepção e da experiência dos gerentes do projeto, sendo que não existe uma ciência exata que determine a melhor forma de se elaborar um cronograma. Dentre os principais problemas relacionados a confecção de um cronograma, pode-se citar:
- estimar o esforço associado à resolução dos problemas e, consequentemente, a mensuração do custo do desenvolvimento de uma solução é muito difícil. A produtividade não é igual para as pessoas que estão trabalhando em determinada tarefa;
- adicionar pessoas a um projeto que já há atraso pode fazer com que ele se atrase ainda mais. Isso ocorre devido ao exagero de comunicação, tendo que enterrar os novos membros ao projeto;
- o inesperado sempre acontece, sempre permita a contingência no planejamento a uma “folga” no cronograma;
- as tarefas não devem ser muito pequenas, de maneira que não haja uma interrupção dos desenvolvedores pelo gerente do projeto. Assim é, recomendado que as tarefas tenham a duração entre uma e duas semanas.
4.5 Ações Implementadas
Para se adequar ao processo e atender as exigências do modelo MPS-BR nível G a empresa passou por alguns reajustes como:
- foi criado um menu para os projetos da empresa – todos os projetos da empresa são cadastrados juntamente com toda a documentação relacionada ao projeto, assim o cliente consegue acompanhar o andamento do projeto durante todo seu ciclo de vida;
- ajuste nos modelos existentes – a empresa já utilizada alguns modelos, mas esses tiveram que ser ajustados para se adequar ao MPS-BR;
- foi criado um menu para os processos da empresa – nesse menu estão disponíveis todos os modelos de documentos utilizados no ciclo de vida de um projeto. Apenas os membros da empresa tem acesso a esse menu; - criação da área de testes – precisou ser criada uma área de testes, hoje,
todo software passa pela área de teste antes de ser entregue ao cliente; - criação de uma planilha para área de teste – o responsável pela área de
teste específica nessa planilha as correções que deverão ser feitas e encaminhada para o desenvolvedor. Feito as correções, a planilha retorna para área de testes. E somente quando esta estive concluída o software é liberado para o cliente;
- criação comitê de processos – alguns colaboradores da empresa foram escolhidos para fazer parte desse comitê e auxiliar na implantação do processo;
- formação procedimentos suporte – o departamento de suporte passou a atender as necessidades dos membros através de um sistema de Ordem de Serviço;
- formação política atendimento ao cliente – a política de atendimento ao cliente também precisou ser ajustada para se adequar ao processo.
4.6 Resultados Alcançados – Comparativo com Guia de Implementação – Nível G
Devido a empresa nunca ter trabalhado com uma processo definido e otimizado o resultado do questionário foi que a organização tinha um nível muito baixo de implementação da gerência do processo. Apenas um resultado esperado foi totalmente implementado e alguns poucos parcialmente implementados. O quadro a seguir mostra os resultados esperados que são implementados atualmente pela organização. Os resultados omitidos não foram alcançados.
Resultados Esperados Implementação GPR 5: O orçamento e o cronograma do projeto,
incluindo marcos e/ou pontos de controle, são estabelecidos e mantidos.
Verificar se o orçamento e o cronograma foram definidos, bem como revistos e atualizados ao longo do desenvolvimento, conforme necessário.
Verificar também se o cronograma possui marcos e/ou pontos de controle e se registra possíveis dependências entre tarefas.
Parcialmente implementado
- Menu de projetos e de processos (documento de visão)
- Cronograma
GPR 6: Os riscos do projeto são identificados e o seu impacto, probabilidade de ocorrência e prioridade de tratamento são determinados e documentados.
Verificar se existe uma lista dos riscos identificados para o projeto e se foi realizada uma análise destes riscos para determinar o impacto, o grau de
importância, a probabilidade e a prioridade de cada risco.
Parcialmente implementado
- Cronograma
- Comitê de processos
GPR 8: As tarefas, os recursos e o ambiente de trabalho necessários para executar o projeto são planejados.
Verificar se a EAP (Estrutura Analítica do Projeto) ou estrutura equivalente foi refinada até o nível de tarefas e se, para cada tarefa, foram planejados os recursos e o ambiente de trabalhos necessários.
Parcialmente implementado
- Plano do projeto que envolve menu de projetos e processos existentes na empresa (documento de visão)
- Cronograma GPR 9: 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, se pertinente, questões de privacidade e segurança. Verificar se existe um plano para gerência de dados, que relacione todos os documentos gerados no projeto, sua distribuição, mídia para armazenamento, forma de proteção (segurança e sigilo) e
recuperação dos dados.
Parcialmente implementado
- Comitê de processos
GPR 10: (Até o nível F). Planos para a execução do projeto são estabelecidos e reunidos no Plano do Projeto.
Verificar se as informações de planejamento do projeto foram documentadas, organizadas e
relacionadas entre si, de forma a comporem o plano de projeto.
Totalmente implementado
- Menu de projetos
- Histórico
- Menu de processos
- Ajuste nos modelos existentes GPR 11: 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.
Verificar se a viabilidade do projeto é avaliada, a partir da visão geral dos objetivos e características dos resultados pretendidos, dos recursos financeiros, técnicos, humanos, bem como das restrições
impostas pelo cliente, ambiente externo e interno e condições de desenvolvimento.
Parcialmente implementado
- Área de testes
- Planilha de testes
GPR 12: O Plano do Projeto é revisado com todos os interessados e o compromisso com ele é obtido. Verificar se há registro de que todos os interessados tomaram conhecimento, revisaram e se
comprometeram com o planejamento do projeto.
Parcialmente implementado
- Comitê de processos
- Cronograma Quadro comparativo de processo. Fonte: Empresa objeto do estudo
De acordo com o resultado do questionário o único resultado que foi Totalmente implementado foi o GPR 10, que trata do uso de dados históricos ou referências técnicas para a estimativa do esforço e custo dos produtos de trabalho.
Já no GPR 5, com a criação de um menu para processos e projetos é possível identificar dependências existentes entre tarefas, porem os marcos do cronograma não são definidos.
Os resultados GPR 6, que relaciona o uso do cronograma e orçamento, não está Totalmente implementado porque ao se elaborar o cronograma o caminho crítico não é observado.
Já no GPR 8, pode-se notar a falta de uma política de segurança para dados do projeto, apesar de serem distribuídos e gerenciados.
No caso do GPR 9, foi verificado que existe planejamento de recursos humanos e que a alocação dos recursos humanos é feita de acordo com o perfil e conhecimento técnico do mesmo. Em contrapartida, o resultado esperado falha no que se refere à necessidade de treinamento, na qual ela não é verificada ou o treinamento não é executado.
O resultado GPR 11, que está relacionado com o planejamento da comunicação, também está parcialmente implementado, já que os interessados são identificados assim como suas respectivas necessidades de informação. Porém a comunicação não é gerenciada para garantir que cada interessado tenha acesso às informações necessárias ao longo do projeto.
Finalmente no GPR 12, foi verificado que ajustes são realizados no planejamento de acordo com a necessidade dos interessados, entretanto não é obtido um compromisso com os mesmos, sendo também parcialmente implementado.
Pode-se observar que todos os resultados esperados para a Gerência de Requisitos (GRE) não se encontram na tabela. Com isso, podemos concluir que não há gerência de requisitos na organização.
4.7 Dificuldades Encontradas
A ausência de práticas administrativas no desenvolvimento de software é a principal causa de sérios problemas enfrentados pela organização; são exemplos: atrasos em cronogramas, custo maior do que o esperado e presença de defeitos, ocasionando uma série de inconveniências para os
usuários e grande perda de tempo e de recursos. Até hoje esta afirmação vem sido confirmada por vários autores. (HUMPHREY, 1989)
As principais dificuldades verificadas para a implantação do novo processo de
software foram: a falha de comunicação entre os colaboradores da empresa, a
cultura organizacional e a falta de consenso em relação ao estabelecimento do melhor processo.
Apesar do treinamento e das várias campanhas de conscientização sobre a importância de se ter um processo definido, algumas pessoas tinham certa resistência em utilizar o novo modelo. Contudo, a etapa de institucionalização viabilizou a implantação das melhorias através do treinamento realizado e da escolha de projetos pilotos.
As melhorias ajudaram, através dos novos artefatos gerados ao longo do processo, também a reduzir falhas na comunicação entre os colaboradores da empresa.
Com base na Softex (2009), dois pontos são instigantes na implantação do nível G; (1) modificação na cultura organizacional, com a devida orientação sobre a definição e melhorias dos processos de desenvolvimento de software, (2) definição do conceito sobre o que é “projeto” para a organização. Podemos observar claramente esses dois pontos no decorrer da implantação.
A busca da qualidade do processo mostrou-se um importante elemento para melhoria da qualidade dos produtos, principalmente devido ao perfil da organização, que emprega profissionais que muitas vezes nunca tiveram uma experiência prática com desenvolvimento de software para o mercado. Existe uma carência de profissionais no mercado com qualificação para trabalharem na área de Qualidade de Software, principalmente pessoas recém formadas em cursos de graduação.
