METHODOLOGY FOR PROJECT MANAGEMENT SOFTWARE DEVELOPMENT

Transcrição

1 1 PS-182 METHODOLOGY FOR PROJECT MANAGEMENT SOFTWARE DEVELOPMENT Carla de Almeida Martins Basso (Orientadora, UNOESC Chapeco/SC, Brasil) - carla.basso@unoesc.edu.br Valdicir Anzolin (UNOESC Chapeco/SC, Brasil) - informatica@amosc.org.br This paper aims to develop a set of best practices, guidelines and consists of the main concepts of methodologies aimed at the area of software development, giving greater emphasis to the initial levels of maturity models in an objective and directed to small and medium software development companies of Santa Catarina. We tried the motivation of these companies by adopting some of these practices, thus enabling better management of their projects and consequently, products and services with quality and reliability, meeting the satisfaction of its customers. Initially, we performed an exploratory research carried out by means of literature, after the research was carried out bibliographical study. Based on the data and information collected, it was developed a methodology for managing software development projects, following the guidelines of good practice in project management recommended developers and major organs responsible for software development processes. This methodology is aimed at small and medium-sized software companies in designing their products and services, ensuring quality, reducing costs, estimating risks and monitored deadlines. Keywords: Project Management, Maturity Models, Methodologies Project Management Software. METODOLOGIA PARA GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE Este trabalho tem por objetivo desenvolver um conjunto de boas práticas, composto pelas orientações e conceitos das principais metodologias voltadas à área de desenvolvimento de software, dando maior ênfase aos níveis iniciais dos modelos de maturidade de forma objetiva e, direcionada às pequenas e médias empresas de desenvolvimento de software de Santa Catarina. Buscou-se a motivação dessas empresas pela adoção de algumas dessas práticas, possibilitando assim melhor gerenciamento de seus projetos e conseqüentemente, produtos e serviços com qualidade e confiabilidade, atendendo a satisfação de seus clientes. Inicialmente foi realizada uma pesquisa exploratória, realizada por meio de pesquisa bibliográfica, após a realização da pesquisa foi realizado estudo bibliográfico. Com base nos dados e informações coletadas, foi elaborada uma metodologia para gerenciamento de projetos de desenvolvimento de software, seguindo as orientações das boas práticas no gerenciamento de projetos recomendadas principais órgãos fomentadores e responsáveis pelos processos de desenvolvimento de software. Esta metodologia é direcionada a pequenas e médias empresas de software, na elaboração de seus produtos e serviços, garantindo qualidade, diminuindo custos, estimando seus riscos e monitorado prazos. Palavras-chave: Gerenciamento de Projetos, Modelos de Maturidade, Metodologias de Gerenciamento de Projetos de Software

2 2 1 INTRODUÇÃO A competitividade no mercado de desenvolvimento de software, a evolução tecnológica, a rapidez do processamento e publicação das informações, os novos métodos e técnicas para o desenvolvimento de soluções na busca de maior eficiência e maior eficácia na produção de produtos e serviços, têm motivado as organizações a rever e a reestruturar suas estruturas organizacionais e seus processos produtivos. Contudo, sabe-se que as empresas não desenvolvem todos os componentes de um produto ou serviço, individualmente, sem buscar apoio de outras metodologias e ferramentas. O mais comum é que alguns componentes sejam produzidos internamente e outros adquiridos, e posteriormente, todos os componentes são integrados ao produto ou ao serviço final. Nesse contexto, observa-se a necessidade das organizações em manter uma estrutura capaz de gerenciar e controlar o complexo processo relacionado a desenvolvimento e manutenção de software. A aceitação do gerenciamento de projetos pelos mercados indica que a aplicação de conhecimentos, processos, habilidades, ferramentas e técnicas adequadas produzem impactos significativos no sucesso de um projeto, mas a decisão em definir qual metodologia a ser usada pelas organizações nem sempre é uma tarefa simples. Todo programa de melhoria de processo deve ser avaliado de forma objetiva de acordo com critérios definidos e não ambíguos e não existem atualmente metodologias que se mostrem melhores para todos os casos, normalmente cada modelo criado é adaptado de acordo com a situação de determinada organização. Muitas das médias e pequenas empresas em razão de alguns fatores como estrutura organizacional inadequada, não possuem estratégias claramente definidas para seus negócios, e, a insegurança quanto às mudanças estruturais, recursos humanos, alto custo na implantação de uma metodologia de maturidade, bem como o gerenciamento de forma adequada no desenvolvimento de seus produtos e ou serviços em seus processos, causam problemas que podem ser considerados típicos na implementação de projetos: a complexidade do projeto, gerenciamento ineficiente ou amador, excesso de conflitos entre membros da equipe de projeto, falta de planejamento ou planejamento deficiente, objetivos mal definidos, excesso de alteração de escopo, incertezas e riscos, mudanças tecnológicas, estimativas de prazo e custo mal elaboradas e falta de controles ou controles ineficientes, são fatores que inviabilizam todo o esforço aplicado na tentativa de melhoria nos processos. Indispensável para converter estratégias em resultados positivos para o negócio, ou seja, é grande a relevância de entregar projetos nos prazos e atendendo orçamento. Para estes resultados serem atingidos, é preciso estabelecer prazos, definir tarefas, identificar os recursos de caminho crítico, especificar e adquirir materiais, acompanhar custos e o valor agregado. Os principais objetivos de um gerenciamento de projeto é produzir os produtos ou serviços por meio de um escopo, prazo e custos com qualidade, delimitado entre as parte interessadas, gerenciar adequadamente seus recursos humanos, aquisições, comunicação e riscos, utilizando ferramentas para analisar, planejar, monitorar e controlar as variáveis que farão a diferença entre projetos bem sucedidos e fracassados. Por excelência, além de manter a gerencia superior informada sobre o andamento do trabalho, também possibilita que determinadas medidas sejam tomadas frente a dificuldades no processo como um todo. Surge assim, a necessidade das organizações se adaptarem a essa realidade, por meio da adoção de modelos de maturidade, padrões, metodologias e diretrizes que possam

3 3 auxiliar a organização a aprimorar o desenvolvimento e a manutenção de seus produtos e serviços, assegurando confiabilidade, solidez e prosperidade ao negócio. Neste contexto, este trabalho inicialmente identificou e agrupou alguns dos principais modelos de melhoria de processos de software disponíveis atualmente no mercado. Estes modelos apontados servem como referência, para a avaliação de processos, e fornecem um conjunto de boas práticas e como os processos de área desenvolvimento de software podem ser melhorados. O objetivo deste trabalho foi elaborar um conjunto de boas práticas composta por orientações e conceitos utilizando-se das principais metodologias voltadas à área de desenvolvimento de software através da disponibilização de um roteiro com templates dos documentos e das principais etapas sugeridas, de modo prático e ágil, facilitando a sua aplicação e incentivando a adoção destas práticas nas empresas de desenvolvimento de software. Inicialmente são apresentadas as principais práticas de gerenciamento dos projetos de software, e suas boas práticas como uma forma de maior controle dos processos envolvidos em todas as fases do desenvolvimento, desde o levantamento de requisitos até a entrega do produto final ao cliente. Após é apresentada a metodologia utilizada neste trabalho e em seguida é apresentada a metodologia de gerenciamento de projetos de software proposta. 2 GERENCIAMENTO DE PROJETOS Em nosso cotidiano, habitualmente, utiliza-se de forma leiga algumas atividades referente à criação, execução e controle de projetos para nossas vidas, por exemplo, uma viagem de férias, uma festa comemorativa, a aquisição de um carro entre outras coisas, atividades que nem sempre se utiliza de uma grande precisão para chegar a nossos objetivos, ou seja, simples atividades que consegue-se gerenciar sem auxílio de um processo gerencial, porém, quando esses projetos atingem um maior número de pessoas envolvidas na geração/manutenção de um novo produto ou serviços, a orientação é utilizarse de métodos mais adequados na realização dessas atividades, para que os objetivos propostos pelo grupo possam ser atendidos, é nesse momento que deve-se utilizar a gerência de projetos. A definição de Projetos encontrada no PMBOOK (Project Management Body of Knowledge) (2004), Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos definidos pelo PMI (Project Management Institute ) Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. Sua natureza temporária indica um inicio e um término definido, a definição de término esta relacionada ao fato dos objetivos definidos foram alcançados ou ao se concluir que objetivos não serão atingidos e o projeto é encerrado, temporário não significa pouca duração. Assim, percebe-se a importância na definição clara dos objetivos, em realizar um planejamento para a execução, planejar os recursos humanos envolvidos, definir cronograma de inicio e fim, os custos envolvidos, com determinado um grau de credibilidade e qualidade aos resultados esperados. Partindo dessas premissas, concluí-se a necessidade da adoção de uma forma de gerenciar esses projetos utilizando de boas práticas, o PMBOOK (2004) trás como definição para gerência de projetos, como sendo a aplicação de conhecimentos, habilidades, ferramentas e técnicas, a fim de satisfazer ou exceder as necessidades e expectativas dos stakeholders (interessados e envolvidos com o projeto)

4 4 A gerência de projetos é classificada em cinco grupos de processos: iniciação, planejamento, execução, controle e encerramento, descritos por Vargas (2005, p. 14), o inter-relacionamento entre as fases do um projeto é demonstrado na figura 1. Fase de Inicialização É a fase inicial do projeto, quando uma determinada necessidade é identificada e transformada em um problema estruturado a ser resolvido por ele. Nessa fase, a missão e o objetivo do projeto são definidos, bem como as melhores estratégias são identificadas e selecionadas; Fase de Planejamento É a fase responsável por detalhar tudo aquilo que será realizando pelo projeto, incluindo cronogramas, interdependências entre atividades, alocação dos recursos envolvidos, análise de custos, etc., para que no final dessa fase, ele esteja suficientemente detalhado para ser executados em dificuldades e imprevistos. Nessa fase, os planos auxiliares de comunicação, qualidade, riscos aquisições e recursos humanos também são desenvolvidos; Fase de Execução É a fase que materializa tudo aquilo que foi planejado anteriormente. Qualquer erro cometido nas fases anteriores fica evidente nesta fase. Grande parte do orçamento e do esforço do projeto é consumida nessa fase; Fase de Monitoramento e Controle É a fase que acontece paralelamente ao planejamento operacional e a execução do projeto. Tem como objetivo acompanhar e controlar aquilo que esta sendo realizado pelo projeto, de modo a propor ações corretivas e preventivas no menor espaço de tempo possível após a detecção da anormalidade. O objetivo do controle é comparar o status atual do projeto como o status previsto pelo planejamento, tomando ações corretivas em caso de desvios; Fase de Encerramento É a fase quando a execução dos trabalhos é avaliada através de uma auditoria interna ou externa (terceiros), os livros e os documentos do projeto são encerrados e todas as falhas ocorridas durante o projetos são discutidas e analisadas para que erros simples não ocorram em novos projetos (aprendizado). Figura 1: Inter-relacionamento entre as fases em um projeto (PMI, 2004) Fonte: Manual Prático do Plano de Projeto utilizando o PMBOK Guide - 3ª Edição 2.1 METODOLOGIAS DE GERENCIAMENTO DE PROJETOS PMI - Project Management Institute Project Management Institute (PMI) é uma organização referência mundial em gerenciamento de projetos. Instituída na Pensilvânia nos Estados Unidos, em 1969, é uma instituição sem fins lucrativos dedicada ao avanço nas boas práticas em gerenciamento de projetos a meta principal do PMI é avançar na prática, na ciência e na profissão de gerenciamento de projetos em todo o mundo, de uma maneira consciente e pró-ativa, para

5 5 que as organizações em todos os lugares apóiem, valorizem e utilizem o gerenciamento de projetos. Uma das grandes contribuições do PMI, para a divulgação das boas práticas de gerenciamento de projetos, foi a publicação de um documento denominado "A guide to the Project Management Body of Knowledge (PMBOK)". Publicado pela primeira vez em 1987, se encontra atualmente na 4º edição lançada no inicio de 2008, possuindo tradução para vários idiomas, inclusive o português, sob o título "Um Guia de Conjunto de Conhecimentos em Gerenciamento de Projetos" PMBOK - Project Management Body of Knowledge O guia PMBOK é uma publicação disponibilizada pelo Project Management Institute (PMI), conhecido no Brasil como Conjunto de Conhecimentos em Gerenciamento de Projetos, PMBOK tem como objetivo reunir todo o conjunto de conhecimento reconhecidos como boas praticas no gerenciamento de projetos, abrangendo nove áreas de conhecimento que descrevem os conhecimento e práticas de gerencia de projetos em termos de um ou mais processos, cada processo é detalhado em entradas, saídas e ferramentas, entradas e saídas são documentos ou itens documentáveis, ferramentas e técnicas são mecanismos que transformam entradas em saídas. As áreas de conhecimentos estão descritas como: gerência de integração, gerência de escopo, gerência de qualidade, gerência de recursos humanos, gerência de comunicação, gerência de tempo, gerência de custos, gerência de riscos e gerência de aquisições conforme demonstrada pela figura 2. Figura 2: Visão Geral das áreas de conhecimento em gerenciamento de projetos e seus processos Fonte: Manual Prático do Plano de Projeto utilizando o PMBoK Guide - 4ª Edição No detalhamento das áreas de conhecimento descritas no PMBoK (2008), cada área traz seus procedimentos, artefatos, entradas e saídas, detalham uma visão geral das áreas de conhecimento e do processo de gerenciamento. Gerenciamento de Integração: Inclui processos e as atividades necessárias para identificar, definir, combinar, unificar e coordenar os vários processos e atividades dos

6 6 grupos de processo de gerenciamento inclui-se, elaboração de termo de abertura, declaração do escopo preliminar, plano de gerenciamento de projeto, execução do plano do projeto; monitorar e controlar o trabalho do projeto, controle integrado de mudanças e encerrar projeto; Gerenciamento do Escopo: Trata das informações que contemplam o que será desenvolvido no projeto exclusivamente o que foi acordo com o cliente controlando o que será incluído ou não no projeto inclui-se, planejamento do escopo, definição do escopo, definição da estrutura analítica do projeto (EAP), verificação do escopo e controle do escopo. Gerenciamento do Tempo: Garantem o comprimento dos prazos definidos em um cronograma de atividades inclui-se, definição das atividades, seqüenciamento das atividades, estimativa de recursos das atividades, estimativa de duração das atividades, criação de cronograma e controle do cronograma; Gerenciamento de Custos: Garantir que o projeto será concluído dentro do orçamento aprovado inclui-se, estimativa, orçamento, controle de custos; Gerenciamento de Qualidade: Garantir ao projeto atingir nível de qualidade desejado pelo cliente inclui-se, satisfação ao cliente, prevenção de erros, responsabilidades, melhoria contínua, planejamento de qualidade; garantia de qualidade; controle de qualidade; Gerencia de Recursos Humanos: gerenciam a equipe do projeto suas funções e responsabilidade de cada membro da equipe inclui-se, planejamento de recursos humanos; contratar e mobilizar a equipe do projeto, desenvolvimento da equipe, gerenciamento da equipe do projeto; Gerenciamento das Comunicações: tem como objetivo coletar, distribuir, armazenar e recuperar as informações referentes ao projeto para que todos os membros da equipe tenham conhecimento da atual situação inclui-se, planejamento das comunicações, distribuição das informações, relatórios de desempenho, gerenciamento das partes interessadas; Gerenciamento de Riscos: tem como objetivo identificar, analisar, responder, monitorar e controlar o planejamento de riscos inclui-se, planejamento do gerenciamento dos riscos, identificação dos riscos, análise qualitativa do risco, analise quantitativa do risco, planejamento de resposta a risco, monitoramento e controle de riscos; Gerenciamento de Aquisições: tem como objetivo dar condições na realização do projeto através da aquisição de bens, produtos e serviços de fornecedores inclui-se, planejamento de compras e aquisições, plano e contratação, solicitação de resposta dos fornecedores, seleção dos fornecedores, manutenção do contrato, encerramento do contrato; A equipe de voluntários do PMI realizou uma revisão na terceira edição do Guia PMBOK e adequaram as melhorias e incorporaram em uma nova versão lançada em 2008 o Guia PMBOK Quarta edição, essas modificações reduziram o numero de processos das áreas de conhecimento de 44 para 42, no gerenciamento de escopo o processo planejamento do escopo passou a coletar requisitos, em gerenciamento das comunicações foi incluído identificar as partes interessadas e em processo gerenciamento de aquisições conta com o processo d o plano de aquisições, realizar compras, administrar contratos e fechar contratos. Outro conceito importante é o ciclo de vida o qual define as fases entre o início do projeto e o seu fim, e colaboram em muito com os gerentes de projetos evidenciarem as saídas e os requisitos esperados em cada fase permitindo um controle com maior qualidade, o ciclo de vida está associado à natureza do projeto e com seu produto final e seus produtos intermediários, denominados deliverables (entregas), a equipe de gerenciamento de projetos deve entender esse contexto amplamente, para que possa

7 7 selecionar as fases do ciclo de vida, os processos, as ferramentas e técnicas adequadas ao projeto MPS.BR O MPS.BR é o Programa de Melhoria de Processos de Software Brasileiro foi criado no ano de 2003, coordenado pelo SOFTEX (Associação para Promoção da Excelência do Software Brasileiro), com apoio do Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID), MPS.BR - Guia Geral [2009, p. 4]. O modelo MPS.BR está baseado 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, possui três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS) e está descrito por meio de documentos em formato de guias no MPS.BR - Guia Geral [2009, p. 7]. Guia Geral: contém a descrição geral do modelo MPS 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 [SOFTEX, 2009b]; 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) [SOFTEX, 2009a]; Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS [SOFTEX, 2009c], [SOFTEX, 2009d], [SOFTEX, 2009e], [SOFTEX, 2009f], [SOFTEX, 2009g], [SOFTEX, 2009h], [SOFTEX, 2009i], [SOFTEX, 2009j], [SOFTEX, 2009k] e [SOFTEX, 2009l]. Para definição do modelo usa a base técnica das normas e ISO/IEC 12207:2008 fornecendo uma arquitetura de alto nível para determinar o ciclo de vida de software, desde a sua concepção até sua descontinuidade, especialmente adequado para aquisições e definido em processos, atividades e tarefas para aquisição, fornecimento, desenvolvimento e operação e manutenção do software e a norma ISO/IEC fornecendo informações gerais sobre os conceitos de avaliação do processo e seu uso nos dois contextos de melhoria de processos e determinação de capacidade de processo, e em conformidade com o CMMI-DEV que é um conceituado modelo de maturidade. O modelo MPS está dividido em três (3) componentes (Figura 1): Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN- MPS). Cada componente é descrito por meio de guias e/ou documentos do modelo MPS no MPS.BR - Guia Geral [2009, p. 13], conforme demonstra a figura

8 8 Figura 3: Componentes do Modelo MPS Fonte: MPS.BR - Guia Geral O modelo de referência contém os requisitos que os processos devem atender para estar em conformidade com o MR-MPS contêm definições dos níveis de maturidade, processos e atributos do processo. O guia de aquisição é um documento complementar destinado a organizações que pretendam adquirir software e serviços, contém as boas práticas para a aquisição de software e serviços, sugere formas para implementação dos níveis do MR.MPS, os diferentes níveis de capacidade dos processos são descritos por nove atributos de processo (AP), o atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo e quando esse nível é alcançado o próximo nível deve adaptado acumulando as definições de cada um dos níveis anteriores. Assim para cada atributo do processo (AP) determinado a um nível possuirá um conjunto de Resultados esperados do Atributo do Processo (RAP), a tabela a seguir apresenta os níveis de maturidade do MR-MPS, os processos e os atributos de processo correspondentes a cada nível, a escala de maturidade se inicia no nível G e em função do crescimento da maturidade chega ao nível A, demonstrados na figura 4. Os noves níveis de atributos do processo (AP) definidos para a capacidade do processo (SOFTEX, 2009) atribuídos no MPS são: AP 1.1 Processo executado; AP Processo gerenciado; AP 2.2 Produtos de trabalho do processo são gerenciados; AP 3.1 Processo é definido; AP Processo está implementado; AP 4.1 Processo é medido; AP 4.2 Processo é controlado; AP 5.1 O processo é objeto de inovações; AP 5.2 O processo e otimizado continuamente; O trabalho busca a utilização dos artefatos sugeridos pelo modelo MPS para se chegar à certificação do nível G, irá focar no Guia de Implementação Parte 1 Nível G (SOFTEX, 2009) para se chegar a essa certificação e necessário que as organizações realizar os processos de gerência de projeto e a gerência de requisitos

9 9 Figura 4: Níveis de maturidade do MR-MPS Fonte: MPS.BR - Guia Geral Methodwhere - Metodologia de gerenciamento de projetos É uma metodologia totalmente alinhada com o PMBOK A Guide to the Project Management Body of Knowledge, 4ª edição, definindo os processos necessários para gerenciar projetos, desde a sua concepção até o seu encerramento. A primeira versão dessa metodologia foi elaborada em 2003 e tem sido, desde então, adaptada e implantada em organizações pela Beware Consultoria Empresarial. Enquanto o PMBOK aborda somente o que é necessário para o gerenciamento de projetos, a Methodware demonstra como esses processos podem ser realizados e em que seqüência. A metodologia adota o conceito de que o gerenciamento de projetos é um ramo da administração que trata da inicialização, planejamento, execução, controle e fechamento do projeto envolvendo aplicação de conhecimento, habilidades, ferramentas e técnicas as atividades com o objetivo de atender seus requisitos, para o atendimento dessas atividades foi utilizado o PMBOK que propõe oito áreas de conhecimento descritas como: escopo, tempo, custo, qualidade, recursos humanos, comunicações, riscos e aquisições adicionado a essas áreas uma nona área denominada Integração que será responsável pela coordenação dessas áreas. Assim estão definidos os grupos e processos da metodologia e suas áreas de conhecimento de gerenciamento de projeto representadas por meio das figuras 5 e

10 10 Figura 5: Grupos de Processos da metodologia de gerenciamento de projetos Fonte: Metodologia de Gerenciamento de Projetos Methodwhere. Figura 6: Áreas de conhecimento do gerenciamento de projetos Fonte: Metodologia de Gerenciamento de Projetos Methodwhere. Conforme a publicação Xavier et al. (2005, p.8) as conceituações das áreas de conhecimento são descritas da seguinte forma: Gerenciamento de Integração: processos que integram os diversos elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos; Gerenciamento do Escopo: processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário para que o projeto seja concluído com sucesso; Gerenciamento de Tempo: processos necessários para que a conclusão do projeto aconteça dentro do prazo programado; Gerenciamento de Custos: processos envolvidos em planejamento, estimativa, orçamento e controle de custos; Gerenciamento da qualidade do projeto: processos envolvidos na garantia de que o projeto irá satisfazer os objetivos pelo qual ele foi realizado; Gerenciamento dos recursos humanos: processos que organizam e gerenciam a Equipe do projeto; Gerenciamento das comunicações: processos relativos a geração, coleta, disseminação, armazenamento e destinação final das informações de forma oportuna e adequada;

11 11 Gerenciamento de riscos: processos relativos à realização do gerenciamento das ameaças e oportunidades de um projeto; Gerenciamento de aquisições: processos que compram ou adquirem, produtos, serviços ou resultados, além dos necessários ao gerenciamento de contratos. O Ciclo de vida da metodologia é determinado por fases do projeto geralmente em uma ordem seqüencial de execução, essas fases são pedaços menores onde os nomes e a quantidade é definida por meio da necessidade de controle da organização, cada fase possui um grupo de atividades denominadas entregas (deliverable), as entregas vêm a ser um produto ou serviço palpável e verificável produzido para a conclusão ou parte do projeto. As revisões realizadas por meio de reuniões e inspeções ao termino de cada fase irão determinar se o projeto passará para a próxima fase, detectar e corrigir erros que afetem o projeto. Figura 7: Processo para o planejamento do projeto. Fonte: Metodologia de Gerenciamento de Projetos - Methodwhere Outra característica da metodologia, como ela esta alinhada ao PMBOOK, que define em o que fazer a metodologia Methodwhere demonstra como fazer por meio de modelos ou templates para todas as atividades do processo. O ciclo de vida do processo é composto por diversas fases geralmente em ordem seqüencial, estas fases são pedaços menores de atividades a conclusão dessas fases são as entregas, o objetivo é de melhor planejar, executar e controlar o projeto, o nome e a quantidade de fases vai depender das necessidades de controle da organização Metodologias ágeis O uso de metodologias em projetos de desenvolvimento de sistemas em uma organização não é uma tarefa de fácil decisão, em sua grande maioria os projetos de desenvolvimento de software podem ser descritos como programar e corrigir sem um planejamento adequado das suas atividades, ocasionando um grande número de erros elevando consideravelmente os prazos e custos inicialmente propostos. O movimento original de melhoria no setor foi o que introduziu a noção de metodologia, uma abordagem disciplinada para o desenvolvimento de software com o

12 12 objetivo de tornar o processo mais previsível e eficiente (FOWLER, 2005 apud Banki; Tanaka, 2008, p.23). Mediante observações realizadas, em diversas organizações e, a constatação que os projetos estavam atrelados a processos cada vez mais burocráticos, um grupo profissional da área de desenvolvimento reuniu-se para avaliar e traçar valores e princípios que permitissem as equipe de desenvolvedores produzirem e responderem mais rapidamente as mudanças, dois dias de trabalho foi necessário para o grupo desenvolver um conjunto de valores denominados Manifesto da Aliança Ágil (MARTIN, 2002) considerado oficialmente o início do movimento ágil, desses valores quatro são os principais: Indivíduos e Interações primeiro que Processos e Ferramentas; Software funcionando primeiro que Documentação Compreensiva; Colaboração do Cliente primeiro que Negociação Contratual; Resposta a Mudanças primeiro que Conformidade com Planejamento; Apesar da importância dos itens citados acima na direita, os métodos ágeis valorizam mais os itens da à esquerda e, juntamente com esses quatro valores básicos o manifesto ágil também definiu princípios que auxiliam na apresentação de suas idéias assim definidas: A maior prioridade é a satisfação do cliente por meio de entregas rápidas e contínuas de software que traga valor; Mudanças de requisitos são aceitas, mesmo em estágios avançados do desenvolvimento; Software que funciona e entregue frequentemente, em períodos que variam de semanas a meses, quanto menos o tempo de uma entrega melhor; As pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar juntas no dia a dia; Construa projetos formados por indivíduos motivados, fornecendo o ambiente e o suporte necessário e confiando na realização do trabalho; O modo mais eficiente e eficaz de transmitir informação dentro e fora do time de desenvolvimento é a comunicação face a face; A principal mediada de progresso é software funcionando; Processos ágeis promovem o desenvolvimento e um ritmo sustentável. Os investidores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante; Cuidar continuamente da excelência técnica e do bom design ajuda a aprimorar a agilidade; Simplicidade o ato de maximizar a quantidade de trabalho não necessário é essencial; Os melhores requisitos, arquiteturas e design surgem de equipes auto-gerenciadas; Em intervalos regulares o time se reúne e reflete sobre como se tornar mais eficiente, refinando e ajustando seu comportamento apropriadamente. Essas características trazem dinamismo para o desenvolvimento, motivação para o time e informações mais precisas sobre a verdadeira situação do projeto para o cliente. Segundo Abrahamsson (2002 apud Banki; Tanaka, 2008, p.23), uma metodologia pode ser dita ágil quando efetua o desenvolvimento de software de forma incremental (liberação de pequenas versões, em iterações de curta duração), colaborativa (cliente e desenvolvedores trabalhando juntos, em constante comunicação), direta (o método em si é simples de aprender e modificar) e adaptativa (capaz de responder às mudanças até o último instante). Neste conceito, incluem-se as metodologias ágeis como Extreme Programming (XP), Scrum, Crystal, Feature Driven Development (FDD), Dynamic Systems Development Method (DSDM), Open Source Software Development

13 13 Os métodos ágeis apresentam uma abordagem bastante pragmática para o desenvolvimento de software, planos de trabalhos são feitos apenas para a fase atual do projeto, para as fases futuras os planos são considerados como rascunhos que podem se adaptar a mudanças conforme a equipe passa a conhecer melhor o sistema e as tecnologias utilizadas, isso em função de no desenvolvimento de software, é comum a mudança dos requisitos, enquanto implementações ainda estão acontecendo SCRUM O Scrum é uma metodologia de processo ágil utilizado para gerenciar e controlar, desenvolvimento de um produto de software através de práticas iterativas e incrementais, o trabalho em equipe é o ponto principal talvez o mais importante. È crucial que se tenha uma visão de equipe do que é ser ágil e praticar no dia a dia. Segundo Nascimento (2010) o processo Scrum foi estabelecido por Ken Schwaber e Jeff Sutherland baseado no manifesto ágil. O Guia do Scrum (Maio de 2009) traz o Scrum como sendo formado por Times e seus papéis associados, eventos com duração fixa, artefatos e regras. O Time tem o objetivo de otimizar a flexibilidade e produtividade, são auto-organizáveis interdisciplinares e trabalham em iterações, sugere-se que sejam compostos por no máximo 9 membros. Por definição do Guia do Scrum (Maio de 2009), cada Time Scrum possui três papéis: o Scrum Master, responsável por garantir que o processo seja entendido e seguido, gerencia processo, riscos e o planejamento; Product Owner, responsável por maximizar o valor do trabalho que o time Scrum faz, gerencia o escopo, prazos, e acompanha medição e a análise; e o Time executa o trabalho propriamente dito gerenciam configuração, riscos, requisitos e planejamento. Teles (2011) demonstra as atividades a serem desenvolvidas em um projeto pelo time são organizadas em ordem de prioridade em uma lista denominada Product Backlog a qual será utilizada em uma reunião de planejamento denominada Sprint Planning Meeting com a participação de todos os envolvidos com o projeto inclusive a participação do cliente, a partir dessa reunião de planejamento terá a origem ao inicio de uma Sprint, onde a equipe definira as atividades das quais ela terá capacidade de implementar durante a Sprint que se inicia, As atividades alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog. A Sprint geralmente é determinada para que seja realizado o seu início e fim um período de uma a quatro semanas nesse tempo a equipe devera entregar uma versão com todas a funcionalidades planejadas testadas e implementadas funcionando para o sua entrega em uma Sprint Review Metting. A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo de vida do Scrum ilustrado na figura:

14 14 Figura 8: Visão geral de atividades do SCRUM Fonte: Lucas José Severino (2009). 3 METODOLOGIA Este trabalho delimitou-se em abordar tradicionais e conceituados modelos de maturidade e metodologias de desenvolvimento de software existentes no mercado, extraindo-se de cada uma suas melhores práticas e, em uma forma seqüencial e mantendo as etapas de qualquer projeto nas pequenas e médias empresas de desenvolvimento de software. O foco consiste na motivação das empresas de desenvolvimento de software pela adoção de algumas dessas práticas, possibilitando assim melhor gerenciamento de seus projetos e conseqüentemente, produtos e serviços com qualidade e confiabilidade, atendendo a satisfação de seus clientes. O período de realização da pesquisa, foi no ano de 2011, iniciando-se com o estudo bibliográfico, e revisão das metodologias existentes e as empresadas nas empresas e após a elaboração de um meio prático e de fácil acesso para utilização pelas empresas, em formato de templates. A intenção de adotar boas práticas de modelos de maturidade e de metodologias por pequenas ou micro empresas da nossa região, é afetada por fatores como multiplicidade de opções no mercado, altos custos na implantação, estruturas organizacionais deficitárias, quebra de paradigmas adquiridos ao longo dos anos e o tempo de adaptação são fatores relevantes nessa tomada de decisão. As empresas entrevistadas fazem parte da área de desenvolvimento de sistemas de informação, com estrutura organizacional localizadas na região oeste de Santa Catarina, que atuam na área de desenvolvimento de software, das mais diferentes áreas de negócio e linguagens de programação, bem como, na prestação de serviço de suporte ao sistema de informação desenvolvido. Foi aplicado um questionário para as empresas associadas ao Pólo Tecnológico do Oeste Catarinense - DEATEC de Chapecó, da área de Tecnologia da Informação (TI) em específico as que desenvolvem softwares que responderam de forma voluntaria as seguintes questões: 1) Quais as principais práticas de gerenciamento utilizadas em desenvolvimento de softwares? 2) Quais são as metodologias utilizadas em pequenas e médias empresas na área de desenvolvimento de software, no município de Chapecó, SC?

15 15 3) Quais os principais problemas encontrados pelas pequenas e médias empresas de Chapecó, na elaboração, execução e manutenção do processo de desenvolvimento de software? 4) Como desenvolver um conjunto de boas práticas composto pelas principais metodologias? Baseada nessas informações as respostas foram tabuladas e analisadas, e proposto um roteiro com base nas melhores práticas, devendo esse ser adaptado a realidade de cada empresa do ramo de desenvolvimento de software, e assim inicie-se um processo de adoção de uma maturidade e compreensão da importância desse gerenciamento, como passo inicial para atingir níveis mais aprofundados desses modelos. 4 APRESENTAÇÃO E ANÁLISE DOS RESULTADOS A pesquisa foi elaborada através da utilização da ferramenta Google DOCS a qual proporcionou segurança, agilidade e credibilidade nos resultados das informações, encaminhadas através de para as empresas do Pólo Tecnológico de Chapecó com o intuito de atender um dos objetivos propostos em nosso estudo na identificação de quais e quantas são as empresas que baseiam o desenvolvimento de seus produtos e serviços através de modelos de maturidade e metodologias de desenvolvimento no gerenciamento de seus projetos. De acordo com as respostas concedidas pelas empresas, a avaliação é animadora, pois 80%, responderam que utilizam alguma forma de gerenciamento em seus projetos e 20% responderam que não utilizam nenhum modelo de maturidade ou metodologia em seu processo de desenvolvimento porém nas questões seguintes ficou evidenciado que este percentual que utiliza algum controle, não possui o processo formalizado e não tem uma metodologia. A pesquisa buscou informações que possibilitassem realizar uma avaliação demonstrando quais são esses Modelos, Metodologias e Ferramentas utilizadas no Gerenciamento de Projetos em suas empresas, o SCRUM aparece como as metodologias utilizadas pelo maior número de empresas pesquisa sendo utilizado em conjunto com outras metodologias como XP, PMBOOK, apenas uma utiliza apenas a metodologia SCRUM representado 11%, duas empresa utilizam SCRUM com algumas técnicas da metodologia XP correspondendo 22%, uma utilizando SCRUM com PMBOOK representando 11% e outra utilizando SCRUM, PMBOOK e técnicas do XP junto, duas empresas utilizam metodologias tradicionais como Cascata/Incremental representando também 11% das empresas, três empresas utilizam ferramentas próprias ou Open Source com o sistema Trac para seu gerenciamento totalizando 34%, sendo que uma delas esta se adaptando a metodologia MPS-BR através da realização de cursos objetivando certificação, Gráfico

16 16 Modelos Metodologias e Ferramentas utilizadas no Gerenciamento de Projetos pelas empresas PMBOOK, Scrum, XP 11% Scrum 11% Ferramentas de Gerenciamento 34% SCRUM, XP 22% PMBOOK, Scrum 11% Scrum Scrum, XP PMBOOK, Scrum Cascata Incremental Ferramenta Gerenciamento PMBOOK, Scrum, XP Cascata Incremental 11% Gráfico 1: Modelos, Metodologias e Ferramentas utilizadas no Gerenciamento de Projetos Fonte: Autor Na análise das informações coletadas podemos destacar apoiados pelos números que de uma forma geral a maioria das empresas pesquisadas estão com seus focos voltados à qualificação de seus produtos e serviços, adotando em suas atividades diárias determinadas boas práticas no desenvolvimento e gerenciamento de seus produtos e serviços, Percebe-se também que essas modelos e metodologias os quais estão sendo utilizados no gerenciamento dos projetos levantadas nas empresas pesquisadas, estão sendo utilizadas de uma forma não estão bem definidas entre um modelo de maturidade ou metodologia e outro, baseando-se em um agrupamento das melhores práticas apresentadas por esses modelos e que melhor se adaptam as suas estruturas organizacionais bem como ao ramo a que se destina. Outra informação relevante extraída é referente a não participação de 63% das empresas que fazem parte do pólo tecnológico de Chapecó não significando que utilizam ao não um modelo, metodologia ou ferramenta no gerenciamento de seus projetos influenciando nos resultados apresentados. Destaque para uma das empresas pesquisadas uma informou estar realizando treinamentos e cursos na busca de adaptar-se ao Modelo Brasileiro MPS-BR buscando atender suas normas de maneira a melhorar a produtividade, a qualidade e a satisfação de seus clientes no desenvolvimento de seus produtos e serviços. 4.1 A METODOLOGIA PROPOSTA PARA GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE SOFTWARE. A metodologia proposta de gerenciamento de projetos foi desenvolvida objetivando atender pequenas e médias empresas de desenvolvimento software, utilizando as boas práticas do PMBOK e com base em informações extraídas da pesquisa em empresas da região de Chapecó, realizadas no inicio deste projeto. Neste instrumento de pesquisa ficou bem evidente a baixa existência de práticas de controle de projetos, ou uma baixa

17 17 maturidade nos processos de gerenciamento dos processos de desenvolvimento de software. A seguir é apresentada a metodologia proposta, inicialmente o fluxo de processos proposto para empresas de desenvolvimento, e após, um mapa mental com as etapas do processo, e após são mostrados alguns dos templates sugeridos FLUXOGRAMA DA METOLOGIA PROPOSTA Figura 9: Fluxograma para a Metodologia Proposta para Gerenciamento de Projetos Fonte: Autor A figura 9 demonstra o fluxo da metodologia proposta, atendendo ao PMBOK, com suas cinco fases. A fase de iniciação determina o que vai ser feito e qual a finalidade da aplicação do projeto de software. Nesta Fase, a organização se compromete como o empreendimento tanto financeiro quanto em termos de responsabilidades e disponibilidades dos recursos necessários. Segundo o PMBOK 2008 trata-se de um processo onde se reconhece que o projeto ou etapa irá se iniciar. A etapa seguinte de planejamento atende as necessidades de se planejar adequadamente as atividades e recursos necessários à execução, onde se reconhece que conseguiram atingir juntos os objetivos especificados. Para o PMBOK 2008, o planejamento é o processo em que se divide em etapas e componentes menores que atendem aos objetivos acordados na fase anterior. O Planejamento é constantemente ajustado em função da elaboração progressiva do produto e por consequência da necessidade de modificações no projeto. Para o Guia PMBOK 2008 a etapa seguinte, de execução é o processo responsável por coordenar pessoas e recursos seguindo o planejado. A seguir o monitoramento e controle, com a função de controle sobre os recursos, atividades, mudanças, qualidade e outros aspectos do projeto, bucando manter sob controle as situações que aparecem decorrentes da elaboração progressiva ou da necessidade de mudanças não planejadas

18 18 Para complementar vem à fase ou etapa encerramento na qual se registra os erros ocorridos durante o desenvolvimento do projeto para que se possa aprender com eles, podem se extrair lições de valor para outros empreendimentos, é o processo em que se formaliza a aceitação do projeto como um todo ou uma fase MAPA MENTAL DA METODOLOGIA PARA GERENCIAMENTO DE PROJETO DE SOFTWARE A figura 10 apresenta o mapa mental da metodologia proposta, onde as fases estão seqüencialmente organizada atendendo as melhores práticas e, para cada uma delas, são sugeridos documentos e ações a serem realizadas. Figura 10. Metodologia Proposta para Gerenciamento de Projetos Fonte: Autor 4.4. PRINCIPAIS TEMPLATES PROPOSTOS NESTE ESTUDO Neste item são apresentados os documentos propostos, seguindo-se a seqüência sugerida na figura 10, porém os documentos na sua totalidade encontram-se disponíveis junto aos autores deste artigo. Projeto: <Nome do Projeto> DOCUMENTO DE REQUISITOS DO SOFTWARE Gerente do Projeto: <Nome da pessoa que representa o projeto com um todo> Responsável pelo Registro: <Nome da pessoa responsável pelo registro> Objetivos Este documento tem como objetivo de descrever os requisitos de forma detalhada do produto de forma a auxiliar no planejamento e na tomada de decisões. Descrever o Contexto de Problema Data do Registro: <DD/MM/AAAA>

19 19 Descrever Proposta de Solução Descrever as Oportunidades quanto a Solução Descrever Produto e seus Subprodutos Descrever Funcionalidades Esperadas (Requisitos Funcionais) Identificador Nome Descrição Prioridades Complexidade Status Versão Autor Descrever Características Técnicas dos Produtos (SW, HW) <Nome e assinatura do Responsável pela Aprovação> Cidade, <xx> de <mês> de <ano> Projeto: <Nome do Projeto> TERMO DE ABERTURA DO PROJETO Gerente do Projeto: <Nome da pessoa designada como gerente do projeto> Patrocinador: <Nome da pessoa que representa o patrocinador do projeto> Objetivos Este documento tem como objetivo comunicar formalmente a existência do projeto e designar seu responsável. Descrever os Objetivos do Projeto (cenários e problemas) Data do Registro: <DD/MM/AAAA> Descrever as necessidades básicas do Projeto (solução) Descrever Produtos e Metas Descrever Premissas e Restrições

20 20 Recursos Humanos (Autoridades e Responsabilidades) Função / Papel Descrição das responsabilidades Comprometer os Envolvidos (partes interessadas) Grupo de Interessados Foco O que este grupo precisa saber Método Quando Descrever Entregas (fases) Produto / Fase Data Prevista Descrever Análise dos Riscos Descrever Gerenciamento das Informações Investimento: < > Comentários Definir Prazo: <DD/MM/AAAA Cidade, <xx> de <mês> de <ano> <Nome e assinatura do Responsável pela Aprovação> DOCUMENTO DE DECLARAÇÃO DO ESCOPO DO PROJETO Projeto: <Nome do Projeto> Data de Entrega: <DD/MM/AAAA> Gerente do Projeto: <Nome da pessoa que representa o Gerente do projeto> Cliente do projeto: <Nome da pessoa que representa o cliente do projeto> Objetivos Este documento tem como objetivo detalhar as principais entregas, premissas e restrições, já documentadas durante a iniciação do projeto. Controle de Versões Versão Data Autor Notas de Revisão Descrever Necessidades do Cliente Os objetivos estratégicos do projeto. A razão pela qual o cliente resolveu iniciar o empreendimento

21 21 Descrever Objetivos do Projeto O que se espera conseguir com o projeto uma vez que este seja concluído Descrever Entregas do Projeto Descriminação dos produtos do projeto, o que será produzido durante sua execução e ao seu término. Descrever Pressupostos Tudo o que se assume como realidade quanto ao projeto. Descrever Requisitos Todas as necessidades do projeto, dentro do que se espera desenvolver e entregar, bem como padrões a serem seguidos. Descrever Restrições Todos os fatores que limitem o projeto de alguma forma e/ou sejam impostos como fatores para seu desenvolvimento. Descrever dos Ríscos Iníciais identificados Possíveis problemas que possam surgir durante a execução do projeto e situações que possam trazer algum benefício para o projeto. Descrever Critérios de Aceitação Definições de métricas de qualidade, padrões, etapas e testes que serão usados para determinar se o projeto está sendo executado de acordo com as expectativas do cliente e se foi entregue de acordo com as mesmas. Descrever Fora do Escopo Definições de tudo ou que será entregue ou não pelo projeto. Cidade, <xx> de <mês> de <ano> <Nome e assinatura do Responsável pela Aprovação> <Nome e assinatura do Responsável pela Empresa Cliente> Projeto: <Nome do Projeto> WBS ou EAP DO PROJETO Data de Ciação: <DD/MM/AAAA> Gerente do Projeto: <Nome da pessoa que representa o projeto com um todo> Patrocinador do Projeto: <Nome da pessoa que patrocinador do projeto> Objetivos Este documento tem como objetivo apresentar a EAP ou WBS do projeto

22 22 EAP/WBS Cidade, <xx> de <mês> de <ano> <Nome e assinatura do Responsável pela Aprovação> <Nome e assinatura do Responsável pela Empresa Cliente> Projeto: <Nome do Projeto> Objetivos do Produto (solução) PLANO GERENCIAMENTO DO PROJETO Data de Criação: <DD/MM/AAAA> Gerente do Projeto: <Nome da pessoa que representa o Gerente do projeto> Cliente do projeto: <Nome da pessoa que representa o cliente do projeto> Objetivos Este documento tem como objetivo detalhar as principais entregas, premissas e restrições, já documentadas durante a iniciação do projeto. Interessados (Stakeholders do Projeto) Questões de Desempenho Abordagem de Desenvolvimento <Engenharia de software (utilizando metodologia Tradicional ou Metodologia Ágil)> Ferramentas utilizadas no Projeto (linguagens, ferramentas de modelagem, etc...)

23 23 Estimativas do Projeto Equipe e Atividades Relacionadas Nome Função Qtd. Atividades Relacionadas Riscos do Projeto Riscos Probabilidade Impactos Exposição Riscos Estratégia Descrever Aprovações Nome Função Assinatura Registro de Alterações Data Motificado por Descrição das Mudanças Cidade, <xx> de <mês> de <ano> <Nome e assinatura do Responsável pela Aprovação> <Nome e assinatura do Responsável pela Empresa Cliente> Projeto: <Nome do Projeto> DOCUMENTO DE REGISTRO DE REUNIÕES Início do Plano: <DD/MM/AAAA> Responsável pelo Registro: <Nome da pessoa responsável pelo registro> Data da Reunião: <DD/MM/AAA > Hora da Reunião: <99:99 > Tempo de Duração: Objetivos Este documento tem como objetivo socialização e acompanhamento de decisões e/ou ações de assuntos discutidos pela equipe do projeto Objetivos da Reunião Pauta da Reunião