Você está na página 1de 78

UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

COORDENAO GERAL DE EDUCAO A DISTNCIA (EAD/UFRPE)

Fundamentos da Engenharia de Software

Danielle Rousy Dias da Silva

Volume 3

Recife, 2010

Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corra de Andrade Vice-Reitor: Prof. Reginaldo Barros Pr-Reitor de Administrao: Prof. Francisco Fernando Ramos Carvalho Pr-Reitor de Extenso: Prof. Paulo Donizeti Siepierski Pr-Reitor de Pesquisa e Ps-Graduao: Prof. Fernando Jos Freire Pr-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pr-Reitora de Ensino de Graduao: Prof. Maria Jos de Sena Coordenao Geral de Ensino a Distncia: Prof Marizete Silva Santos

Produo Grfica e Editorial Capa e Editorao: Rafael Lira, Italo Amorim e Heitor Barbosa Reviso Ortogrfica: Marcelo Melo Ilustraes: Allyson Vila Nova, No Aprgio e Igor Leite Coordenao de Produo: Marizete Silva Santos

Sumrio
Apresentao................................................................................................................. 5 Conhecendo o Volume 3 ................................................................................................ 6 Captulo 1 Gerncia de Projetos de Software ............................................................... 7 1.1 Projeto e Gerncia de Projetos ..................................................................................8 1.2 O Gerente de Projeto...............................................................................................12 1.3 Modelos de Gerenciamento de Projeto ..................................................................13 1.4 Gerncia de Projeto de Software .............................................................................14 1.5 Consideraes sobre o Planejamento .....................................................................15 1.6. Plano de Projeto de Software .................................................................................22 Captulo 2 Mtricas e Estimativas .............................................................................. 29 2.1 Importncia das Medies ......................................................................................30 2.2 Mtricas de Processo e Mtricas de Projeto ...........................................................31 2.3 Tipos de Medies ...................................................................................................32 2.4 Processo GQM (do ingls goal-question-metric) .....................................................39 2.5 Estimativas de Software...........................................................................................40 Captulo 3 PMBOK ..................................................................................................... 47 3.1 O que PMBOK? .....................................................................................................47 3.2 Breve Histrico ........................................................................................................48 3.3 Viso Geral do PMBOK ............................................................................................49 3.4 Certificao PMI.......................................................................................................57 Captulo 4 Gerncia de Configurao ......................................................................... 63 4.1 Por que gerenciar a configurao do software? ......................................................64 4.2 O que Gerncia de Configurao? ........................................................................65

4.3 Processo de Gerncia de Configurao ...................................................................66 4.4 Ferramentas de Suporte ao GC................................................................................69 Consideraes Finais .................................................................................................... 75 Conhea a Autora ........................................................................................................ 78

Apresentao
Caro(a) Cursista, Seja bem-vindo(a) terceira unidade do curso Fundamentos da Engenharia de Software. Na unidade anterior, apresentamos a Engenharia de Requisitos, o Projeto de Software e tambm conhecemos um pouco sobre Verificao e Validao de Software. Como continuao, esta terceira unidade abordar as reas de conhecimento, tambm essenciais, e que do suporte a produo do software, so elas: Gerncia de Projeto e Gerncia de Configurao e Mudana.
No se gerencia o que no se mede, no se mede o que no se define, no se define o que no se entende, no h sucesso no que no se gerencia. (William Edwards Deming)

Bons estudos! Danielle R. D. da Silva Autora

Fundamentos da Engenharia de Software

Conhecendo o Volume 3
Neste terceiro volume, voc ir encontrar a Unidade 3 da disciplina Fundamentos da Engenharia de Software. Para facilitar seus estudos, veja a organizao desta terceira unidade.

verso

Unidade 3 - Processos de suporte: aspectos gerenciais e controle de


Carga Horria da Unidade 3: 15 h/aula

Objetivo da Unidade 3:
O objetivo desta unidade apresentar brevemente algumas das atividades que do suporte ao desenvolvimento de software, so elas: a gerncia de projeto e gerncia de configurao.

Contedo Programtico da Unidade 3


Gerncia de projeto de software; Estimativas e mtricas; PMBOK; Gerncia de configurao e controle de mudana de software.

Fundamentos da Engenharia de Software

Captulo 1 Gerncia de Projetos de


Software
Vamos conversar sobre o assunto?
Atualmente, a Gerncia de Projetos uma das reas mais comentadas e discutidas por especialistas da indstria de software. O fato que uma boa gesto fundamental para que os prazos e resultados do projeto alcancem os resultados almejados ou, no mnimo, cheguem um pouco mais perto desses resultados. No h mais espao para o desenvolvimento caseiro do software no mercado hoje. preciso planejamento, conhecer os custos e os prazos do projeto antecipadamente, preciso conhecer se o software vivel tecnicamente, economicamente e mercadologicamente, antes de iniciar a produo dele. E todas essas informaes so provenientes do conjunto de atividades que compe a Gesto de Projetos! Neste captulo abordaremos o conjunto de atividades responsvel pela Gesto do Projeto de Software. Voc ver que, como as demais reas que j estudamos nessa disciplina, a Gesto de Projetos tambm representa uma rea de conhecimento complexa. Dessa forma, o intuito deste captulo ser explanar o assunto de forma breve dando uma viso geral. Devido a sua importncia, voc ter uma disciplina mais frente no curso abordando exclusivamente essa rea de conhecimento. Aqui, voc conhecer sobre: O que um projeto e quais suas caractersticas. O que gesto de projetos. Quem o gerente de projeto e quais suas responsabilidades. Qual o ciclo de vida de um projeto. Onde se encaixa a gerncia de projeto no ciclo de desenvolvimento do software.

Fundamentos da Engenharia de Software

1.1 Projeto e Gerncia de Projetos


Antes de partimos para estudar o que a gesto de projetos de software, vamos entender primeiramente o que um projeto. Na verdade, todo mundo tem ou teve ou ter algum projeto em algum momento da vida, seja a compra de um veculo, seja a compra de uma casa, seja a aprovao de um concurso pblico, seja um casamento, seja o trmino do curso superior como esse que voc est fazendo, qual o seu projeto para os prximos anos? Em se tratando das empresas e organizaes, o conceito de projeto denota uma importncia ainda maior, pois o resultado dele pode garantir competitividade e excelncia no mercado.

Fique por Dentro


Projeto um empreendimento temporrio realizado de forma progressiva para criar um produto ou servio nico.

1.1.1 O que um projeto?


Segundo o PMI (2000) um projeto pode ser definido como um esforo temporrio (tem incio e trmino definido) empreendido por pessoas para criar um produto, servio ou resultado exclusivo dentro de parmetros como: prazo, qualidade e custo. Por exemplo, o projeto de concluir essa disciplina com nota mxima! O esforo temporrio e o resultado exclusivo nota mxima para a disciplina de FES. Existem muitas outras definies para o termo projeto, contudo todas esto relacionadas a um plano para a realizao de uma ao, um esboo, com representao grfica ou escrita e acompanhada de um oramento que demonstre o custo estimado do projeto. Dessa forma um projeto deve exibir sempre caractersticas como: Ser temporrio: tem data de incio e trmino bem definido. Por exemplo, a data de incio e fim desta disciplina define o prazo para a realizao do projeto ser aprovado em FES. Ser nico: significa que todo produto ou servio gerado por um projeto diferente de outros produtos e servios. Retomando ao exemplo, fica claro que o resultado do projeto ser aprovado em FES diferente de tentar a aprovao em qualquer outra disciplina! Ser progressivo: medida que o projeto mais bem compreendido. Por exemplo, voc fica mais prximo de sua aprovao nesta disciplina medida que avaliaes so realizadas e os resultados so todos bons e positivos! So executados por pessoas! Possuem recursos limitados (tempo, dinheiro, pessoas, ferramentas, equipamentos, etc). Todo projeto precisa ser planejado, executado e controlado para atingir seus respectivos objetivos.

Voc Sabia?
Como o SWEBOK que voc estudou no primeiro fascculo desta disciplina, o PMBOK tambm representa um guia de conhecimento de melhores prticas especificamente para o gerenciamento de projetos. Esse guia genrico, e no se aplica apenas a projetos de softwares.

Voc Sabia?
A literatura tambm diferencia projetos de operaes. Esses primeiros, como j mencionamos, so temporrios e exclusivos, enquanto que os segundos so atividades contnuas e repetitivas, como o servio de call-centers, por exemplo.

Um exemplo de um esboo de projeto seria o apresentado no Quadro 1.1. Que tal torn-lo uma verdade, seria uma boa ideia no?!

Fundamentos da Engenharia de Software

Projeto: Ser aprovado por mdia em FES O intuito do projeto ser aprovado por mdia em FES. Para isso, devo realizar as aes: a. Estudar em mdia 10h semanais para a disciplina b. Participar dos fruns semanalmente c. Participar nos chats semanalmente d. Fazer todos os exerccios propostos e. Fazer e enviar a tempo todas as atividades somativas f. Fazer as avaliaes e tirar notas acima de sete Quadro 1.1 Esboo exemplo de um projeto.

1.1.2 O que Gerncia de Projetos?


Entendido o que precisamente um projeto, a pergunta agora : do que se trata a gerncia de projetos? Voltando um pouco a questo anterior, suponha que tenhamos o projeto de ser aprovado na disciplina de FES como especificado acima, nada adianta o projeto se no h atividades que apiam a realizao desse, como um planejamento de estudo, de exerccios, cronograma de atividades, etc. Por exemplo, que aes precisam ser executadas para alcanar o objetivo? Quando elas precisam ser executadas, em que tempo? Quanto elas iro me custar em termos de tempo e/ou dinheiro? Como verificar se estamos pertos ou longe de alcanar o objetivo? Caso no tenha conseguido tirar nota acima de 7 na primeira avaliao, o que deveria fazer para alcanar ainda o objetivo do projeto? Ainda possvel? A gerncia de projetos vem atender exatamente essa demanda pelo sucesso. Entenda como sucesso a demanda do projeto de alcanar os objetivos atendendo s restries de prazo, custo, escopo e qualidade. Por exemplo, no projeto ser aprovado em FES, o prazo definido pelo perodo da disciplina, o custo poderia ser no exceder o tempo de estudo recomendado semanalmente, o escopo se refere a limitar o projeto de aprovao disciplina de FES, e a qualidade, fica entendida aqui como ser aprovado por mdia, sem precisar de recuperao ou prova final. O intuito do gerenciamento maximizar a probabilidade de sucesso do projeto aplicando uma srie de conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas conquista de um conjunto de objetivos pr-definidos, como aqueles especificados no Quadro 1.1. Segundo Koontz e ODonnel (1980), gerenciar consiste em executar atividades e tarefas que tem como propsito planejar e controlar as atividades, normalmente, executadas por terceiros, para atingir os objetivos do projeto. Vale realar tambm que as atividades de gerenciamento so as primeiras executadas no desenvolvimento de um projeto, inclusive em um projeto de software. H uma srie de vantagens em adotar o gerenciamento de projetos. Em um estudo apresentado sobre a gesto de projetos no Brasil, onde foram pesquisados 373 empresas de diversos segmentos do mercado, foi identificado que a adoo de tcnicas de gerenciamento de projeto possibilitou um maior comprometimento com os objetivos e resultados finais do

Fique por Dentro


Gerenciamento de Projeto a aplicao de conhecimentos, habilidades e tcnicas na elaborao de atividades relacionadas para atingir um conjunto de objetivos pr-definidos.

Fundamentos da Engenharia de Software projeto em cerca de 68% das empresas pesquisadas, como se v na figura a seguir.

Figura 1.1 Vantagens encontradas na adoo de gerenciamento de projetos. Fonte: (Panorama de Gesto de Projetos no Brasil, 2008).

Lembrete
Vamos refletir um pouco... O bom gerenciamento no pode garantir o sucesso do projeto. Contudo, o mau gerenciamento geralmente resulta no fracasso do projeto.

As atividades de planejamento e gerenciamento envolvem normalmente criar um equilbrio entre as demandas de escopo, tempo, custo, qualidade e bom relacionamento com o cliente do projeto. Isto significa que o sucesso do projeto est associado a, no mnimo, pontos como: Entrega dos resultados do projeto no prazo previsto; Dentro do custo orado; Com nvel de desempenho adequado; Com a aceitao pelo cliente; e, Atendido de forma controlada s mudanas de escopo e respeito cultura da organizao no qual o projeto est sendo executado

Voc Sabia?
Considerando as empresas brasileiras, a Petrobras foi considerada empresa com excelncia no gerenciamento de projeto, em 2008 recebeu o prmio Top Mind em gesto de projetos. Seguido pela empresa Promon em 2.o lugar e a IBM em terceiro.

A pessoa responsvel diretamente pelo sucesso do projeto o gerente de projeto, pois este ter a atribuio direta de administrar os recursos (tempo, pessoas, ferramentas, custos, etc) destinados ao projeto para que o sucesso seja alcanado, desde o planejamento inicial ao controle da execuo. Certamente, essa atribuio no uma tarefa muito simples, envolve variveis muito complexas como interesse do cliente, da empresa, da equipe, do prprio gerente, etc ficando o gerente responsvel por manter o equilbrio entre elas. Uma das trades mais divulgadas na literatura sobre gesto de projetos a que envolve o equilbrio entre as variveis: prazo, escopo e custos (Figura 1.2). Essas variveis representam normalmente as restries do projeto e o equilbrio entre elas envolve questes como reduzir custo e diminuir qualidade ou reduzir prazo e aumentar custos, dentre outras. Por exemplo, entregar o projeto antes do prazo, provavelmente envolver aumento de custos ou sacrifcio da qualidade final. Voc saberia explicar por que isso acontece? J se aumentarmos a qualidade final do produto, isso implicaria em aumento de custos e prazo tambm.

10

Fundamentos da Engenharia de Software

Figura 1.2 Custos VS Prazo VS Escopo. Fonte: (PMI, 2004).

1.1.3 Ciclo de Vida do Projeto


De forma geral, independentemente do modelo de gerenciamento adotado, normalmente se observa que os projetos podem ter sua realizao separada em fases distintas (Figura 1.3): conceitual; planejamento; implementao (controle e execuo); finalizao.

Figura 1.3 - Ciclo de vida do projeto. Fonte: Adaptado (PMBOK, 2004).

Essa separao ajuda os profissionais envolvidos a entender os objetivos do seu trabalho em cada fase e a melhor controlar o andamento do projeto. Conceitual: fase inicial em que se define o projeto, as necessidades so identificadas. Planejamento: nessa fase se define e refina o objetivo do projeto, planejam-se as aes necessrias para atingir os objetivos e o escopo para o qual se prope o projeto. Nessa fase so desenvolvidos planos auxiliares para gesto do projeto (plano de qualidade, comunicao, riscos, suprimentos e recursos humanos). Implementao: integra as pessoas e os outros recursos para colocar em prtica o

Fique por Dentro


O ciclo de vida do projeto acompanha quatro fases: conceitual, planejamento, implementao (execuo, controle) e finalizao.

11

Fundamentos da Engenharia de Software plano do projeto. geralmente nessa fase em que ocorre a maior parte do esforo/ dispndio do projeto. Paralelamente s atividades de execuo do projeto se encontram tambm as atividades de controle que mede e monitora o progresso para identificar variaes em relao ao planejado para que aes corretivas sejam disparadas quando necessrio. Finalizao: formaliza a aceitao do projeto, servio ou resultado. Analisa a evoluo do projeto para que erros no se repitam no futuro.

Voc Sabia?
H vrias certificaes disponveis para a profisso de Gerente de Projetos, uma das mais difundidas a disponibilizada pelo PMI (Project Management Instituto). O custo desta certificao fica em torno de $ 555 dlares para no associados da Instituio. Alm disso, para tirar essa certificao voc precisa comprovar alguns pr-requisitos como: (i) experincia em gerncia de projetos; e, (ii) capacitao. Por exemplo, para profissionais graduados o exigido : 4.500 horas e 36 meses de experincia nos ltimos 6 anos

Existe uma sobreposio no tempo entre as fases e suas respectivas atividades, boa parte das atividades de planejamento se estende por todo ciclo do projeto assim como as atividades de execuo e controle. Entretanto, a intensidade de trabalho ou nvel de esforo de cada processo costuma variar como pode ser observado na figura a seguir.

Figura 1.4 Sobreposio das fases. Fonte: Adaptado (PMI, 2004).

1.2 O Gerente de Projeto


O gerente de projeto uma profisso relativamente nova e em alta no mercado (NETO e BOCOLI, 2003). Devido importncia que esse profissional tem para os resultados do projeto, hoje h um esforo nacional e internacional em melhorar a capacitao desse profissional considerando conceitos tericos e prticos da gesto de projetos, incluindo estudos de casos reais e ferramentas multimdias como jogos para auxiliar nesse aprendizado. No Brasil, um dos cursos bem reconhecido nesse sentido o MBA Pleno em Gesto de Projetos oferecido pela Fundao Getlio Vargas, contudo, existem muitos outros. H disponvel tambm uma srie de certificaes para atestar o conhecimento e experincia desse profissional. Esse profissional deve ser designado desde o incio do projeto e deve ter o apoio visvel da alta administrao, empresa ou organizao na qual o projeto est sendo executado. J imaginou executar um projeto em uma empresa onde toda alta administrao conspira para o fracasso? Que dureza! Em condies como essa, muitas vezes melhor nem assumir o cargo ou o projeto. O gerente possui muitas responsabilidades e executa muitas atividades. No contexto da Engenharia de Software, esse gerente teria como responsabilidades atribuies como: Definir e controlar os objetivos do projeto;

Fique por Dentro


O profissional que executa as atividades de planejamento, gerenciamento e controle do projeto denominado de Gerente de Projeto.

12

Fundamentos da Engenharia de Software Definir e controlar os requisitos do produto; Definir e controlar os riscos do projeto; Definir e avaliar os fatores crticos de sucesso do projeto; Definir e avaliar os pontos fortes e fracos do projeto; Definir e controlar o cronograma, Alocar e gerenciar recursos; Definir prioridades; Coordenar interaes entre os envolvidos no projeto; Assegurar que prazos e custos esto sendo mantidos dentro do planejado; Assegurar que os produtos do projeto atendam ao critrio de qualidade e que estejam de com os padres estabelecidos; Participar de reunies de acompanhamento e de reviso do projeto.

Voc Sabia?
As empresas que possuem maior nmero de gerentes de projetos certificados pelo PMI, no Brasil so: a IBM, Unisys, HP, EDS, CPqD, Ericsson, Petrobras, Telefnica, entre outras. Fonte: (ESI - http:// www.esi-intl.com. br/sitecore/content/ Brazil/sobre-esi/ noticias/As%20 duas%20ondas%20 na%20gestao%20 de%20projetos.aspx).

De acordo com (LIMA, 2006), para executar suas atribuies, o gerente de projetos deve ter uma srie de atributos gerenciais e interpessoais, como: Habilidade para negociao; Facilidade de comunicao; Habilidade para solucionar problemas; Influncia na organizao; Liderana; Capacidade de deciso; Experincia; Relacionamentos externos.

1.3 Modelos de Gerenciamento de Projeto


Atualmente, h diversos modelos de gerenciamento de projetos. Sem dvida, um dos mais conhecidos e divulgados pelo mundo PMBOK, que adota uma abordagem tradicional para o gerenciamento. Contudo, h uma crescente adoo por modelos alternativos, como os divulgados pelos movimentos geis. O SCRUM um dos exemplos de modelo de gesto gil muito divulgado na atualidade. A diferena entre a abordagem tradicional da alternativa (gil), reside no fato dessa ltima considerar o gerenciamento de projeto como um conjunto de pequenas atividades, ao invs de um processo que identificam uma srie de passos a serem completados. Vale salientar, mais uma vez, que a adoo de um modelo a outro vai depender muito das caractersticas e restries do projeto, depende, por exemplo: do tipo de produto desenvolvido, das prticas organizacionais, da experincia do gerente de projeto, dentre outros aspectos. Uma empresa que tem como foco o desenvolvimento de projetos de curta durao, de 2 a 4 semanas, tipo projetos de desenvolvimento de jogos de propaganda ou divulgao de marcas, teria o modelo de gesto gil como um processo mais adequado ao modelo tradicional. Voc saberia explicar o porqu disso? Um estudo apresentado no 9 Encontro Internacional de Gerenciamento de Software sobre o panorama no Brasil em gesto de projetos mostrou como resultado que 76% dos projetos que adotam alguma metodologia para o gerenciamento de projetos

Voc Sabia?
Para conhecer um pouco mais sobre o modelo gil de gesto SCRUM, h vrios stios disponveis na web. Um texto bem simples que resume um artigo de referncia sobre o assunto (Scrum in Five minutes) o encontrado no blog Coding Dojo Floripa (Disponvel em:http:// dojofloripa.wordpress. com/2007/02/07/ scrum-em-2-minutos/).

13

Fundamentos da Engenharia de Software alcanam sucesso. Isso s evidencia a importncia de adotar uma metodologia de gesto de projetos.

Figura 1.5 Estudo sobre o uso de metodologia de GP. Fonte: (Panorama de Gesto de Projetos no Brasil, 2008).

1.4 Gerncia de Projeto de Software


Como percebido pelo j explanado neste captulo, o gerenciamento de projetos tambm se constitui uma tarefa de fundamental importncia no processo de desenvolvimento de software. No entanto, ele no visto como uma etapa clssica do processo de desenvolvimento, uma vez que ele acompanha a todas as etapas tradicionais: concepo (requisitos), anlise, projeto, desenvolvimento, testes e manuteno. Nesse caso, o gerenciamento de projeto visto como uma atividade guarda-chuva que apoia todas as fases de execuo do ciclo de desenvolvimento do software (Figura 1.6).

Figura 1.6 Relacionamento entre Gesto de Projeto e Desenvolvimento de Software.

14

Fundamentos da Engenharia de Software As atividades de gerenciamento em Engenharia de Software giram em torno de dois principais pontos: um o planejamento e o outro a monitorao. No quadro 1.2 h um exemplo de um pseudo-algoritmo para seguir durante o planejamento e monitorao de um projeto de software. O planejamento constitui de um conjunto de atividades que visam definir os requisitos, cronograma, recursos, esforos, custos, organograma do projeto e alocao de recursos (equipe, mquinas, softwares, etc). Segundo Pressman (2006), um projeto de engenharia de software deve estar baseado em um bom planejamento para que se possa gerenciar adequadamente a sua realizao e aumentar a probabilidade de sucesso. J a monitorao visa, sobretudo, acompanhar, avaliar, monitorar as atividades de progresso do projeto como tambm riscos, custos e infra-estrutura necessrios a execuo do projeto verificando se o progresso do projeto anda como o planejado previamente.

Fique por Dentro


Durante o planejamento voc precisa responder diversas questes. Exemplos: Em relao ao produto: quais os componentes? Quais as entregas? Em relao ao trabalho: o que se faz? Em relao ao tempo: quando e durante quanto tempo? Em relao s pessoas: por quem? Disponibilidade? Em relao ao oramento:

1.5 Consideraes sobre o Planejamento


Planejar estimar quais as atividades devero ser realizadas; quem dever realizlas; quando devem ser realizadas e finalizadas; e quanto elas devero custar. Tudo isto requer a elaborao de estimativas em relao ao nmero e dimenso dos artefatos, do nmero de pessoas necessrias, dos prazos e dos custos. Para isto, a atividade de planejamento dever resultar: Na realizao de estimativas; Na elaborao da estrutura de diviso do trabalho (tambm conhecido como WBS do ingls Work Breakdown Structure); Na definio da equipe e demais recursos; Na alocao de pessoa-atividade; Na elaborao do cronograma; Na elaborao do oramento.

Fique por Dentro


WBS (Work Breakdown Structure), tambm conhecida no Brasil como EAP (Estrutura Analtica de Trabalho), uma ferramenta para controle de projetos utilizado na metodologia PMBok. A definio tcnica descreve o WBS como uma decomposio hierrquica orientada entrega do trabalho a ser executado pela equipe do projeto (PMBok Terceira edio Pg 363)

Alm disso, a anlise de riscos e as revises peridicas do plano so fundamentais para garantir que ele seja cumprido. O planejamento est diretamente ligado ao processo de software. Conforme dissemos anteriormente, um processo de software resultado do planejamento associado a um modelo de processo (mtodo). O modelo de processo indica quais atividades devem ser realizadas e qual a dependncia entre elas. Por exemplo, no modelo cascata, deve-se especificar os requisitos, desenhar a arquitetura, fazer o design detalhado, implementar as unidades, integrar as unidades e, finalmente, entregar o software. O planejamento deve indicar quem faz estas atividades, quanto tempo necessrio para eles, quando elas sero realizadas e quanto custar cada um delas. Sem um planejamento adequado, os desenvolvedores no sabero o que fazer e no tero datas para iniciar ou terminar o trabalho. Sem estimativas, o responsvel pelo planejamento no ter como dimensionar o tamanho e a quantidade dos artefatos a serem produzidos e o esforo necessrio para produzi-los. Por fim, sem um oramento, no se ter noo quanto o software ir custar e se haver recursos para o desenvolvimento.

15

Fundamentos da Engenharia de Software


Estabelecer as restries do projeto Fazer uma avaliao inicial dos parmetros do projeto Definir os marcos e as entregas Desenhe o cronograma do projeto Enquanto o projeto no for completado ou cancelado faa: Inicie as atividades de acordo com o cronograma Espere (um pouco) Revise o progresso do projeto Revise estimativas dos parmetros do projeto Atualize o cronograma do projeto Renegocie as restries do projeto e as entregas Se (problemas surgirem) ento Inicie a reviso tcnica Fim do se Fim do enquanto Quadro 1.2 Pseudo-algoritmo para planejamento e monitorao de um projeto. Fonte: Adaptado de (Somerville, 2007).

1.5.1 Cronograma
Uma das mais importantes atividades realizadas durante o planejamento a elaborao do cronograma de execuo do projeto. Esta atividade visa distribuir o esforo estimado pela durao planejada do projeto, partilhando esse esforo pelas tarefas especficas para o desenvolvimento do software. Esse conjunto de atividades representa a estrutura analtica de diviso de trabalho do projeto, e comumente identificado como WBS. H duas perspectivas para a gerao do cronograma. A primeira, a mais comum, representa a imposio da data final do projeto pela organizao/cliente/financiadores/ mercado do projeto. Neste caso, o gerente de projeto fica responsvel por distribuir os recursos existentes considerando j essa data como final, sem muita flexibilidade de extenso de prazo. Nesse cenrio, normal acontecer reduo de escopo do software e/ou aumento do tamanho da equipe, caso o prazo seja muito agressivo. A segunda perspectiva a ideal. Nesse cenrio, o gerente de projeto faz um cronograma considerando as estimativas coletadas das atividades para fazer o cronograma, com o prazo final sendo definido. Basicamente o processo para construir um cronograma segue os passos mostrados na Figura 1.7.

Voc Sabia?
A WBS deve ser completa, organizada e pequena o suficiente para que o progresso possa ser medido, mas no detalhada o suficiente para se tornar, ela mesma, um obstculo para a realizao do projeto. Uma boa heurstica a seguir a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de durao.. Fonte: (Wikipedia)

16

Fundamentos da Engenharia de Software

Figura 1.7 Passos para construir um cronograma.

O primeiro passo levantar as atividades a serem realizadas, em seguida, identificase as dependncias entre essas atividades, estima-se os recursos necessrios para realiz-las (tempo, pessoas, software, etc), define-se quem vai realizar cada atividade, sendo gerado ao final o diagrama grfico de cronograma do projeto. Um dos formatos de diagrama mais amplamente adotados na elaborao de cronogramas o grfico de Gantt. Esse grfico parece como o mostrado na figura 1.8. Nele h especificado as atividades, durao, data de incio e trmino, dependncia (indicado na figura pela coluna predecessoras) e responsvel. H vrios softwares, muitos gratuitos, desenvolvidos exclusivamente para auxiliar na construo de cronogramas. Alguns deles so: DotProject (gratuito), Open Workbench (gratuito), e o MS Project (proprietrio).

Saiba Mais
O grfico de Gantt foi desenvolvido em 1917 pelo engenheiro social Henry Gantt, esse grfico utilizado como uma ferramenta de controle de produo. Nele podem ser visualizadas as tarefas de cada membro de uma equipe, bem como o tempo utilizado para cumpri-la. Assim, pode-se analisar o empenho de cada membro no grupo. Fonte: (Wikipedia)

Figura 1.8 Exemplo de um grfico de Gantt.

Pressman (2006) define alguns princpios para o desenvolvimento dos cronogramas.

17

Fundamentos da Engenharia de Software So eles:

Saiba Mais
O grfico de Gantt foi desenvolvido em 1917 pelo engenheiro social Henry Gantt, esse grfico utilizado como uma ferramenta de controle de produo. Nele podem ser visualizadas as tarefas de cada membro de uma equipe, bem como o tempo utilizado para cumpri-la. Assim, pode-se analisar o empenho de cada membro no grupo. Fonte: (Wikipedia)

Compartimentalizao: o projeto deve ser decomposto em um nmero de atividades e tarefas gerenciveis. Alguns especialistas em Gesto de Projetos sugerem que essas atividades tenham o prazo mximo de uma semana, caso contrrio, eles aconselham dividi-las em atividades menores at que esse prazo seja alcanado. Sendo assim, as tarefas a serem realizadas durante um projeto de desenvolvimento de software podem ser expressas na forma de uma rede (rede de tarefas) a qual apresenta todas as tarefas do projeto, assim como as suas relaes em termos de realizao (paralelismo, sequncia, pontos de encontro, etc...). Um exemplo desta representao apresentado na figura 1.9.

Figura 1.9 Exemplo de uma rede de tarefa

Interdependncia: a independncia entre as atividades deve ser estabelecida. Algumas tarefas devem ocorrer em sequncia, enquanto outras podem ocorrer em paralelo. Por exemplo, a atividade documentar os requisitos, pode ocorrer em sequncia sendo executada logo aps a atividade de anlise e negociao de requisito e em paralelo a atividade de modelagem dos requisitos. Atribuio de tempo: a cada tarefa a ser cronogramada deve ser atribudo um certo nmero de unidades de trabalho. Por exemplo, uma unidade muito utilizada a unidade horas-homem representando as horas de trabalho realizada por uma pessoa. Validao do esforo: verificar se o esforo alocado dirio no ultrapassa o limite mximo existente para o projeto. Por exemplo, voc poderia alocar 12 horashomem de trabalho para algum membro da equipe, quando o mximo so 8 horashomem. Responsabilidades definidas: cada atividade/tarefa definida no cronograma deve ser atribuda a algum membro da equipe do projeto. Resultados definidos: cada atividade/tarefa definida no cronograma dever ter um

18

Fundamentos da Engenharia de Software resultado associado. Por exemplo, documentar requisitos tem como resultado o documento de requisitos elaborado; documentar arquitetura tem como resultado a documento de arquitetura elaborado; implementar o requisito cadastro de usurio, tem como resultado a parte do cdigo responsvel por esse servio e assim sucessivamente. A especificao desses resultados ajuda ao Gerente validar se as atividades esto concludas ou no. Marcos de referncia definidos: as atividades ou conjunto de atividades devem estar associados a um marco do projeto. A definio desses marcos depende bastante do processo de desenvolvimento adotado como tambm de restries do projeto. O importante voc ter em mente que um marco representa um momento importante no projeto, normalmente associado a resultados significativos que precisaro ser validados e verificados para s ento o projeto seguir para a fase seguinte. Considerando o processo de desenvolvimento em cascata, um marco simples poderia ser definido para o fim de cada fase desse processo, isto , ao fim das fases de requisitos, anlise e projeto, codificao e testes.

Levando em considerao esses princpios e tendo alguma ferramenta auxiliar para ajudar na elaborao do cronograma, voc j capaz de fazer um cronograma de projeto! Experimente, baixe um software como o DotProject ou Open Workbench, teste-os, elabore um cronograma para o projeto passar por mdia na disciplina de FES!

1.5.2 Os Riscos do Projeto


Outro aspecto muito importante definido durante o planejamento a identificao dos riscos do projeto. Voc sabe o que um risco? No contexto da ES, um risco considerado como qualquer problema que impea a execuo de qualquer atividade definida para o projeto ocasionando possveis atrasos ou impedindo, at a concluso do projeto. Dessa forma, esses riscos devem ser cuidadosamente acompanhados e tratados durante toda a execuo do projeto. A anlise dos riscos uma das atividades essenciais para o bom encaminhamento de um projeto de software. Esta atividade est baseada na realizao de quatro tarefas, conduzidas de forma sequencial: a identificao, a projeo, a avaliao e a administrao.

1.5.2.1 A Identificao dos Riscos


Nesta primeira tarefa, o objetivo que sejam levantados, da parte do gerente e dos profissionais envolvidos no projeto, todos os eventuais riscos aos quais este ser submetido. Nesta identificao, riscos de diferentes naturezas podem ser detectados: Riscos de projeto, os quais esto associados a problemas relacionados ao prprio processo de desenvolvimento (oramento, cronograma, pessoal, etc...); Riscos tcnicos, que consistem dos problemas de projeto efetivamente (implementao, manuteno, interfaces, plataformas de implementao, etc...); Riscos de produto, os quais esto mais relacionados aos problemas que vo surgir para a insero do software como produto no mercado (oferecimento de um produto que ningum est interessado; oferecer um produto ultrapassado; produto inadequado venda; etc...).

A categorizao dos riscos, apesar de interessante, no garante a obteno de resultados satisfatrios, uma vez que nem todos os riscos podem ser identificados facilmente. Uma boa tcnica para conduzir a identificao dos riscos de forma sistemtica o estabelecimento de um conjunto de questes (checklist) relacionado a algum fator de

19

Fundamentos da Engenharia de Software risco. Por exemplo, com relao aos riscos de composio da equipe de desenvolvimento, as seguintes questes poderiam ser formuladas: So os melhores profissionais disponveis? Os profissionais apresentam a combinao certa de capacidades? H pessoas suficientes na equipe? Os profissionais esto comprometidos durante toda a durao do projeto? Algum membro da equipe estar em tempo parcial sobre o projeto? Os membros da equipe esto adequadamente treinados?

Em funo das respostas a estas perguntas, ser possvel ao planejador estabelecer qual ser o impacto dos riscos sobre o projeto.

1.5.2.2 Projeo dos Riscos


A projeo ou estimativa de riscos permite definir basicamente duas questes: Qual a probabilidade de que o risco ocorra durante o projeto? Quais as consequncias dos problemas associados ao risco no caso de ocorrncia do mesmo?

As respostas a estas questes podem ser obtidas basicamente a partir de quatro atividades: Estabelecimento de uma escala que reflita a probabilidade estimada de ocorrncia de um risco; Estabelecimento das consequncias do risco; Estimativa do impacto do risco sobre o projeto e sobre o software (produtividade e qualidade); Anotao da preciso global da projeo de riscos.

A escala pode ser definida segundo vrias representaes (booleana, qualitativa ou quantitativa). No limite cada pergunta de uma dada checklist pode ser respondida com sim ou no, mas nem sempre esta representao permite representar as incertezas de modo realstico. Uma outra forma de se representar seria utilizar uma escala de probabilidades qualitativas, onde os valores seriam: altamente improvvel, improvvel, moderado, provvel, altamente provvel. A partir destes valores qualitativos, seria possvel realizar clculos que melhor expressassem as probabilidades matemticas de que certo risco viesse a ocorrer. O prximo passo ento o levantamento do impacto que os problemas associados ao risco tero sobre o projeto e sobre o produto, o que permitir priorizar os riscos. Pode-se destacar trs fatores que influenciam no impacto de um determinado risco: a sua natureza, o seu escopo e o perodo da sua ocorrncia. A natureza do risco permite indicar os problemas provveis se ele ocorrer (por exemplo, um risco tcnico como uma m definio de interface entre o software e o hardware do cliente levar certamente a problemas de teste e integrao). O seu escopo permite indicar de um lado qual a gravidade dos problemas que sero originados e qual a parcela do projeto que ser atingida. O perodo de ocorrncia de um risco permite uma reflexo sobre quando ele poder ocorrer e por quanto tempo.

20

Estes trs fatores definiro a importncia do risco para efeito de priorizao. Um

Fundamentos da Engenharia de Software fator de risco de elevado impacto pode ser pouco considerado em nvel do gerenciamento de projeto se a sua probabilidade de ocorrncia for baixa. Por outro lado fatores de risco com alto peso de impacto e com probabilidade de ocorrncia de moderada a alta e fatores de risco com baixo peso de impacto com elevada probabilidade de ocorrncia no devem ser desconsiderados, devendo ser processados por todas atividades de anlise de risco.

1.5.2.3. Avaliao dos Riscos


O objetivo da atividade de avaliao dos riscos processar as informaes sobre o fator de risco, o impacto do risco e a probabilidade de ocorrncia. Nesta avaliao, sero verificadas as informaes obtidas na projeo de riscos, buscando prioriz-los e definir formas de controle destes ou de evitar a ocorrncia daqueles com alta probabilidade de ocorrncia. Para tornar a avaliao eficiente, deve ser definido um nvel de risco referente. Exemplos de nveis referentes tpicos em projetos de Engenharia de Software so: o custo, o prazo e o desempenho. Isto significa que se vai ter um nvel para o excesso de custo, para a ultrapassagem de prazo e para a degradao do desempenho ou qualquer combinao dos trs. Desta forma, caso os problemas originados por uma combinao de determinados riscos provoquem a ultrapassagem de um ou mais desses nveis, o projeto poder ser suspenso. Normalmente, possvel estabelecer um limite, denominado de ponto referente (breakpoint) onde tanto a deciso de continuar o projeto ou de abandon-lo podem ser tomadas. A figura 1.10 ilustra esta situao, na qual dois nveis de risco referente so considerados (o custo e o prazo). Se uma combinao de riscos conduzir a uma situao onde os limites de ultrapassagem de custo e/ou de prazo estejam acima do limite (delimitado pela curva na figura), o projeto ser abandonado (rea em cinza escuro). No breakpoint, as decises de continuar o projeto ou abandon-lo tm igual peso.

Fique por Dentro


Figura 1.10 - Ilustrao de uma situao de definio de dois nveis de riscos. Um exemplo de um plano de projeto pode ser encontrado no stio <http://www.cin.ufpe. br/~if682/templates. htm>.

1.5.2.4. Administrao e Monitorao dos Riscos


Uma vez avaliados os riscos de desenvolvimento, importante que medidas

21

Fundamentos da Engenharia de Software sejam tomadas para evitar a ocorrncia dos riscos ou que aes sejam definidas para a eventualidade da ocorrncia dos riscos. Este o objetivo da tarefa de Administrao e monitorao dos riscos. Para isto, as informaes mais importantes so aquelas obtidas na tarefa anterior, relativas descrio, probabilidade de ocorrncia e impacto sobre o processo, associadas a cada fator de risco. Por exemplo, considerando a alta rotatividade de pessoal numa equipe como um fator de risco, com base em dados de projetos passados, obtm-se que a probabilidade de ocorrncia deste risco de 0,70 (muito elevada) e que a sua ocorrncia pode aumentar o prazo do projeto em 15% e o seu custo global em 12%. Sendo assim, pode-se propor as seguintes aes de administrao deste fator de risco: Reunies com os membros da equipe para determinar as causas da rotatividade de pessoal (ms condies de trabalho, baixos salrios, mercado de trabalho competitivo, etc...); Tomada de providncias para eliminar ou reduzir as causas controlveis antes do incio do projeto; No incio do projeto, pressupor que a rotatividade vai ocorrer e prever a possibilidade de substituio de pessoas quando estas deixarem a equipe; Organizar equipes de projeto de forma que as informaes sobre cada atividade sejam amplamente difundidas; Definir padres de documentao para garantir a produo de documentos de forma adequada; Realizar revises do trabalho entre colegas de modo que mais de uma pessoa esteja informada sobre as atividades desenvolvidas; Definir um membro da equipe que possa servir de backup para o profissional mais crtico.

importante observar que a implementao destas aes pode afetar tambm os prazos e o custo global do projeto. Isto significa que necessrio poder avaliar quando os custos destas aes podem ser ultrapassados pela ocorrncia dos fatores de risco. Num projeto de grande dimenso, de 30 a 40 fatores de risco podem ser identificados; se para cada fator de risco, sete aes forem definidas, a administrao dos riscos pode tornar-se um projeto ela mesma. Por esta razo, necessrio que uma priorizao dos riscos seja efetuada, atingindo normalmente, a 20% de todos os fatores levantados. Todo o trabalho efetuado nesta tarefa registrado num documento denominado Plano de Administrao e Monitorao de Riscos, o qual ser utilizado posteriormente pelo gerente de projetos (particularmente, para a definio do Plano de Projeto, que gerado ao final da etapa de planejamento).

1.6. Plano de Projeto de Software


Considerando tudo que j foi exposto neste captulo, podemos concluir dizendo que o resultado da fase de planejamento o plano de projeto de software. Este um documento contendo a equipe, a estrutura de diviso do trabalho (WBS), a alocao pessoa-tarefa, a anlise de riscos, o cronograma, o oramento entre outras informaes. Esse documento

22

Fundamentos da Engenharia de Software ser a base da monitorao da execuo do projeto, servindo tambm como um importante documento de contrato entre os stakeholders envolvidos com o projeto. Uma estrutura de plano de projeto de software sugerida por Ian Sommerville (2007) a seguinte. 1. Introduo; 2. Organizao de projeto; 3. Anlise de riscos; 4. Requisitos necessrios de hardware e software; 5. Estrutura analtica de trabalho (WBS); 6. Cronograma de projeto; 7. Mecanismos de monitoramento e elaborao de relatrios. Esta estrutura pode variar de acordo com as caractersticas do projeto. Bem, espero que tenha gostado do exposto neste captulo. Poderamos falar muito mais sobre gerncia de projetos, contudo vamos deixar a tarefa de aprofundar os conhecimentos nesse assunto sob sua responsabilidade agora .

Atividades e Orientaes de Estudos


Para melhor assimilar o contedo deste captulo sugerimos algumas atividades de fixao. Como o assunto simples e bem objetivo, teremos basicamente os seguintes tipos de atividades para esse captulo: Atividades prticas: representam questes simples e objetivas sobre o assunto aqui abordado. Na prtica, bastar estudar o assunto contido no captulo para respond-las corretamente. Atividades de pesquisas: representam tpicos de pesquisas dirigidos no muito extensos. Para cada tpico de pesquisa sugerido indicaremos fontes que podero auxiliar na pesquisa, mas voc ter total liberdade de consultar outras fontes caso deseje. Em cima do tpico sugerido, definimos algumas questes que devero ser respondidas. Sugerimos ainda que as atividades de pesquisa sejam feitas em equipe, pois isso favorece o aprendizado e enriquece a discusso sobre o assunto. Atividades de interao: correspondem atividades que visam discutir sobre o assunto nos fruns criados para o curso.

E no esquea, na dvida, sinta-se vontade em perguntar! Interaja com seus colegas nos fruns e chats, participe! Estamos aqui para auxiliar uns aos outros na construo do saber. Seguem alguns exemplos de atividades respondidas e/ou comentadas que sero encontradas neste captulo. No forneceremos exemplos de atividades de interao, elas so atividades simples e caracterizadas pelas discusses abertas nos fruns.

Aprenda Praticando

1. Construa uma WBS para o projeto pintar uma sala.

23

Fundamentos da Engenharia de Software Resposta:

Ateno
As respostas das questes dessa seo podem ser facilmente encontradas relendo os textos do capitulo. Aproveite essa oportunidade para fixar melhor os pontos principais do contedo abordado no capitulo.

Preparao de materiais Comprar tinta; Comprar escada; Comprar pincis / rolos; Comprar removedor de papel de parede.

Preparao da sala Remoo do papel de parede antigo; Remoo das decoraes destacveis; Cobrir cho com jornais; Cobrir tomadas com fita; Cobrir mveis com lenis velhos.

Pintura da sala Pintar grandes reas com rolo; Pintar rodaps com pincel.

Limpeza da sala Jogar fora, ou guardar a tinta que sobrou; Limpar pincis e rolos; Jogar fora jornais; Remover e limpar lenis.

Aprenda Praticando: Exercicio Proposto 1.1


Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1) Com base no estudado, classifique os itens abaixo discriminando quais deles so projetos e quais so operaes. a) Definio de um processo de produo para software educacional. b) Criao da interface do sistema moodle de educao distncia. c) Processo de emprstimo de livro em uma biblioteca. d) Realizao da festa de formatura de concluso do curso. e) Desenvolvimento de um jogo no estilo pacman. 2) Indique V para Verdadeiro e F para Falso. a) ( ) comum projetos apresentarem requisitos que excedam os recursos disponveis (pessoal, tempo,..). b) ( ) O cliente em geral est desesperado para colocar o sistema em operao bem antes que a equipe do projeto julgue adequado.

24

Fundamentos da Engenharia de Software c) ( ) Dentro das restries tpicas de um projeto (prazo, custo, qualidade), a restrio custo a mais fcil de ser negociada. d) ( ) Trocas de ferramentas CASE durante a execuo de um projeto podem aumentar os riscos de um projeto porque alteram o processo padro de trabalho da equipe. e) ( ) Para obter xito em um projeto absolutamente necessrio implementar todos os requisitos. 3) Considerando o que voc estudou sobre a gesto de projeto, explique a importncia do Gerente para o sucesso do Projeto? 4) O que Gerncia de Projetos? 5) O que um stakeholder? Lembre-se falamos sobre eles no fascculo anterior. 6) Quem voc consideraria como possveis stakeholders de um projeto de software? 7) Cite e descreva as fases do ciclo de vida de um projeto. 8) Qual a importncia do planejamento para Gerncia de Projetos? 9) Escolha um projeto e desenvolva e documente os resultados do planejamento referentes aos seguintes pontos: a - Escopo: i. Definio do Escopo ii. Criar WBS b. Tempo: i. Definio das Atividades ii. Sequenciamento das Atividades iii. Estimativa dos Recursos para as Atividades iv. Estimativa de Durao das Atividades v. Desenvolvimento do Cronograma c. Riscos: i. Identificao dos riscos 10) Em equipe de 3-4 pessoas elabore um plano de projeto para um projeto a sua escolha. Defina um ciclo de vida para o projeto e faa o planejamento de todas as suas fases.Valide o escopo do projeto escolhido com o professor. a.Entre outros itens, o plano de projeto deve incluir: i. Escopo ii. Data de incio e trmino iii. Fases e atividades iv. Produtos e/ou servios entregues v. Equipe (incluindo parceiros) vi. Oramento vii. Cronograma viii. Riscos

25

Fundamentos da Engenharia de Software ix. Detalhar/ajustar o planejamento, definindo: a durao de cada fase.

Aprenda Pesquisando: Pesquisa Proposta 1.1


A fim de aprofundar um pouco mais seu conhecimento sobre modelos de gerenciamento de projeto, selecionamos alguns tpicos para pesquisa. 1) Em equipe faa uma pesquisa sobre, pelo menos, dois diferentes modelos de gerenciamento de projeto (por exemplo, PMBOK, Prince ou Scrum). Explique suas caractersticas, principais fases e atividades. 2) Pesquise sobre ferramentas destinadas a gesto de projetos. Cite pelo menos duas delas. Quais so as principais funes dessas ferramentas? Com que outras ferramentas elas podem ser integradas? Quanto elas custam?

Aprenda Interagindo: Exercicio de Interao 1.1


Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o capitulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. 1. (**) Durante muitos anos a indstria hospitalar tinha apenas uma vaga ideia da extenso dos erros no processo de medicao de pacientes. Todos os hospitais tinham regras exigindo que as enfermeiras reportassem prontamente os erros de medicao ao administrador do hospital. Entretanto, em muitos hospitais as enfermeiras haviam aprendido que, quando faziam esses relatrios, muitas vezes se expunham a culpas injustificadas. Por isso, deixaram de faz-los. Um estudo realizado por um perito no pertencente indstria hospitalar mostrou que (a) cerca de 7% das medicaes envolviam erros, alguns bastante srios, e (b) o grosso dos erros se relacionava ao controle gerencial, portanto erros dos mdicos e no das enfermeiras. Baseando-se neste cenrio: a. Pense no que este caso sugere quanto a diferena entre sensores de qualidade humanos e tecnolgicos. b. O que voc faria para aperfeioar a qualidade desse processo? 2. O que devemos fazer quando a gerncia exige que cumpramos uma data de entrega impraticvel? Comente a respeito.

Conhea Mais
Existem diversos stios, artigos e livros que falam sobre Gerenciamento de Projetos. Aqui estamos sugerindo algumas leituras adicionais para complementar o seu conhecimento sobre o assunto. O artigo Gerenciamento de Projetos disponibilizado online pelo sitio Promon.com

26

Fundamentos da Engenharia de Software fornece uma viso generalizada sobre o assunto abordando os principais conceitos, definies, modelos e processos sobre gesto de projetos. Disponvel em: < http:// www.promon.com.br/portugues/noticias/download/PBTR%20GE_para%20web. pdf > Recomendamos a leitura do quinto captulo do livro de Ian Sommerville, 8 edio. Outro artigo sobre gerncia de projetos. Disponvel em: <http://www.macoratti. net/ger_proj1.htm> Outra referncia sobre gerncia de projetos pode ser encontrada no blog <http:// tudosobreprojetos.blogspot.com/2008_04_06_archive.html>. Guia para elaborao de uma WBS. Disponvel em: <http://www.slideshare.net/ espig/estrutura-analitica-do-projeto> Recomendamos a leitura do artigo As cinco doenas do gerenciamento de projeto escrito por Allan Elder e disponvel em <http://www.heptagon.com.br/5dgp>.

Voc Sabia?
Veja algumas curiosidades atualizadas sobre gerenciamento de projetos. Voc sabia que... O Project Management Institute (PMI), fundada em 1969, por cinco voluntrios, hoje a principal associao mundial sem fins lucrativos em gerenciamento de projetos, cujo principal objetivo difundir a gesto de projetos no mundo, de forma a promover tica e profissionalismo no exerccio desta atividade. Esta associao ocupa posio de liderana global no desenvolvimento de padres para a prtica da profisso de gerente de projetos, atualmente com mais de 150.000 associados em todo o mundo. Fonte: PMI. Disponvel em: <www.pmi.org>.

Dica de Cinema
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns video-aula curtinhos disponibilizados livremente na Internet (You Tube). O contedo claro, objetivo e correto. Vale a pena ser visto! Um vdeo bem humorado, curtinho (~7min), sobre as dificuldades normalmente encontradas na gesto de projetos. Disponvel em: <http://www.youtube.com/watch?v=qhLJFkpgwo> Outro vdeo de humor descrevendo um algoritmo que determina se o projeto ser um sucesso ou no, abstraindo-se dos erros de portugus, o vdeo educativo e divertido. Disponvel em: http://www.youtube.com/watch?v=0WBrGqXxvyc Vdeo introdutrio motivador dando uma viso geral sobre a gesto de projetos. Disponvel: <http://www.youtube.com/watch?v=yWxt86yprdk>

27

Fundamentos da Engenharia de Software

Vamos Revisar?

Resumo
Uma boa gerncia de projetos essencial para o sucesso de um projeto. A natureza intangvel do software causa problemas para o gerenciamento. O planejamento e a estimativa so processos iterativos, que continuam durante o curso de um projeto. Um marco de projeto o resultado previsto de uma atividade em que algum relatrio formal de progresso deve ser entregue gerncia. Os riscos podem ser riscos de projeto, riscos de produto ou riscos de negcios.

28

Fundamentos da Engenharia de Software

Captulo 2 Mtricas e Estimativas


Vamos conversar sobre o assunto?
J imaginou construir a casa dos seus sonhos sem ter a mnima noo de quanto ela custar? Saber quantos metros de cermicas precisar comprar? Quanto de fiao eltrica? De cimento? De tijolos? E a mo de obra? Tempo de construo? E assim sucessivamente. Seria uma loucura no?! Hoje, algum que siga esse caminho ser provavelmente chamado de louco. E muito provvel que seu projeto de construir a casa dos sonhos se transforme em um grande fiasco. Os conceitos de mtrica e estimativa focam exatamente nisso. Podemos dizer que tanto as mtricas quanto as estimativas so conceitos genricos e presentes em quase todo projeto independente da rea de atuao. Por exemplo, na construo civil, no projeto de um carro, no projeto de uma nova mquina de automao industrial, e tambm no desenvolvimento de um software. As mtricas e estimativas so fundamentais para o sucesso de um projeto e um gerenciamento mais efetivo. Este captulo um complemento da rea de gerenciamento de projetos e tem por objetivo apresentar os conceitos fundamentais envolvidos com as mtricas e estimativas de software, essenciais para o planejamento e melhoria da qualidade. Ao final do capitulo voc conhecer: O que uma mtrica de software? Qual a importncia da mtrica para o desenvolvimento e gerenciamento do projeto? Tipos de mtricas de software O que uma estimativa? Algumas tcnicas de estimativas de software

29

Fundamentos da Engenharia de Software

2.1 Importncia das Medies


Por que importante medir? Em primeiro lugar, importante estar ciente que as medidas so uma forma clara de avaliao da produtividade no desenvolvimento de software. Sem medidas impossvel haver um gerenciamento efetivo. Como afirma Pressman (2006), as medies representam uma ferramenta de gesto. E isso verdade no apenas para Engenharia de Software, mas para reas como a gesto domstica de uma casa, a gesto pessoal financeira, a gesto da manuteno de um carro, etc.

Fique por Dentro


As medies so ferramentas de apoio a gesto.

A importncia das mtricas se apresenta tanto com objetivos referentes ao produto em si, a fim de atestar a aderncia de suas caractersticas finais com o que foi estabelecido na especificao, por exemplo, medir a qualidade, a manutenibilidade, etc; como objetivos referentes ao processo em que ele foi desenvolvido, a fim de encontrar oportunidades de melhoria (o processo foi efetivo? Foi correto? As ferramentas foram adequadas?). Sem informaes quantitativas a respeito do processo de desenvolvimento de softwares por parte de uma empresa ou equipe de desenvolvedores de produto, impossvel tirar qualquer concluso sobre de que forma est evoluindo a produtividade e o progresso do projeto. Precisamos saber, por exemplo, quanto do cdigo j foi implementado, quanto dos requisitos j foram testados, se o processo adotado est adequado ao tipo de projeto, e assim sucessivamente. Dessa forma, podemos elencar como objetivo das mtricas os seguintes pontos: Entender: no sentido que ajuda a entender o comportamento e o funcionamento de produtos de software. Avaliar: nesse sentido as mtricas so utilizadas para determinar padres, metas e critrios de aceitao. Controlar: utilizadas para controlar processos, produtos e servios de software. Prever: utilizadas para prever valores de atributos. E a importncia das mtricas no contexto do software pode ser resumido em: Quantificar a qualidade do software como produto; Avaliar a produtividade dos elementos envolvidos no desenvolvimento do produto; Avaliar os benefcios de mtodos e ferramentas para o desenvolvimento de software; Formar uma base de dados para as estimativas; Justificar o pleito e aquisio de novas ferramentas e/ou treinamento adicional para membros da equipe de desenvolvimento.

Lembrete
Processos so colees de atividades relacionadas ao desenvolvimento de software. Produtos so quaisquer artefatos que resultam de uma atividade do processo.

Como muitas das atividades executadas em ES, o processo de medio realizado tambm em etapas. Contudo, antes de qualquer medio, preciso um planejamento. Nesta etapa preciso definir que atributos precisam ser avaliados durante o ciclo de produo do software, por exemplo, definir que o atributo produtividade algo importante a medir para o sucesso do projeto. Precisa-se definir que medidas precisam ser realizadas para que a avaliao dos atributos seja realmente feita e seja efetiva. Precisa-se definir a mtrica associada s medidas, como tambm definir os indicadores que avaliam se o que est sendo medido est bom ou ruim, por exemplo, a produtividade est baixa ou alta? Dessa forma, quando se falar em uma mtrica, fique certo que se tem uma ou mais medidas e um indicador associada a ela. Outro ponto importante nesse planejamento definir quem ir avaliar as mtricas, quem ir coletar e com que periodicidade (semanalmente, mensalmente, a cada 15 dias...). Sem essas definies bsicas para o processo de medio,

30

Fundamentos da Engenharia de Software corre-se o risco de nenhuma medio ocorrer e nem a qualidade do processo e produto ser avaliada e consequentemente melhorada no decorrer do tempo. E isso poder ter um preo salgado a mdio e longo prazo para o sucesso do projeto e tambm da organizao!

2.1.1 Definies Bsicas


Antes de falarmos um pouco mais sobre mtricas, vamos entender alguns conceitos fundamentais. Precisamos saber o que e qual a diferena entre uma medida, uma mtrica e um indicador.
1) O que uma medida? Representa uma avaliao tendo como base um padro de medida. Por exemplo, 200 LOC uma medida e representa a contagem do nmero de linhas de cdigo (representado pelo padro LOC) de um pequeno programa. 2) O que uma mtrica? Representa uma forma de avaliar a presena de um determinado atributo. Considere atributo algo que se deseje avaliar constantemente no processo ou projeto, por exemplo, produtividade, eficcia dos testes, etc. Vale salientar tambm que uma mtrica pode ser calculada ou composta por 2 ou mais medidas. Exemplo: a eficcia dos testes poderia ser medida contando o nmero de rodadas de testes e tambm a quantidade de defeitos encontrados (duas medidas). Alguns outros exemplos de mtricas so nmero de linhas de cdigo (LOC), nmero de mudanas no documento de requisitos, nmero de classes de um sistema. 3) O que um indicador? Representa um aparelho ou varivel que pode ser configurado com base na ocorrncia de uma condio. Em outras palavras, uma interpretao de uma mtrica num determinado contexto. Exemplo: aumento significativo do nmero de defeitos.

Entendido o que medida, mtrica e indicador, vamos estudar um pouco sobre as medidas de processo e de projeto.

2.2 Mtricas de Processo e Mtricas de Projeto


Basicamente, podemos dividir as mtricas em dois grandes grupos. Um relacionado s mtricas de processo e outro s mtricas de projeto. As mtricas de processo esto associadas aos atributos que quando avaliados contribuiro para a melhoria do processo de produo, em nosso caso, da produo do software. Essas medidas poderiam nos dar informaes de que fase do ciclo de produo do software est exigindo mais esforos dos desenvolvedores. Atravs da obteno de medidas relativas produtividade e qualidade, possvel que metas de melhorias no processo de desenvolvimento sejam estabelecidas como forma de incrementar estes dois importantes fatores da ES. Por exemplo, atravs dessas medidas voc poderia identificar que uma ferramenta inadequada ao processo de desenvolvimento, pois no se integra com as demais ferramentas do processo e assim exige do desenvolver um tempo adicional para duplicar informaes em ferramentas distintas. As mtricas de processo so coletadas em todos os projetos de uma empresa e/ou

Fique por Dentro


As mtricas de processo esto associadas com o planejamento estratgico da empresa ou organizao, enquanto que as mtricas de projeto esto associadas ao planejamento ttico.

31

Fundamentos da Engenharia de Software organizao, no so especficas do projeto. A inteno com elas realmente a melhoria do processo de produo, fazendo parte dessa forma, do planejamento estratgico da empresa.

Para Refletir...
Mtricas de software permitem quando voc deve chorar ou rir. (Tom Gilb) O que voc acha dessa afirmao? Concorda com ela?

J as mtricas de projeto permitem ao gerente de projeto acompanhar o projeto em andamento, ajudando no acompanhamento dos riscos potenciais, na identificao de reas problemas, na acomodao de tarefas e atividades, dentre outros pontos importantes para o sucesso do projeto especfico. Um dos usos mais comuns de mtricas no contexto do projeto na definio de estimativas (estudaremos mais sobre estimativas nas sees seguintes). Nesse caso, os dados histricos de projetos anteriores so usados como base para mensurar o projeto em termos de tamanho, prazo e custo, por exemplo. Alm disso, esse tipo de mtrica pode auxiliar a responder perguntas como: Que tipos de requisitos so os mais passveis de mudanas? Quais mdulos do sistema so os mais propensos a erros? Quanto de teste deve ser planejado para cada mdulo? Quantos erros (de tipos especficos) pode-se esperar quando o teste se iniciar?

Independente se as mtricas so de processo ou projeto, Pressman (2006) identifica um pequeno conjunto de etiquetas para o uso de mtricas de software. Podemos citar algumas delas: 1) Usar bom senso e sensibilidade empresarial quando interpretando os dados de mtricas. 2) Fornecer regularmente realimentao (retorno sobre a anlise das mtricas) aos indivduos e equipes que coletam medidas e mtricas. 3) No usar mtricas para avaliar indivduos. Caso contrrio, voc correr o risco de ter medidas irreais, pois o indivduo poder no apresentar os dados reais com medo de ser avaliado negativamente, por exemplo. 4) Nunca usar as mtricas para ameaar os indivduos ou equipes. 5) No usar os dados de mtricas que indicam uma rea problemtica como negativos, e sim, como uma oportunidade de melhoria de processo ou projeto. Dos itens listados acima, podemos dizer que os itens indicados pelos pontos 3) e 4) merecem uma ateno maior. Voc saberia explicar por qu? Resumindo um pouco, podemos dizer que o uso de mtricas de qualidade, tanto do produto como do processo, so fundamentais para o gerenciamento. Com base em mtricas, o gerente tem condies de avaliar se o planejamento est sendo cumprido ou no. Neste caso, as mtricas podem apontar as causas dos problemas e permitir as revises no planejamento.

2.3 Tipos de Medies


Alm da classificao de mtricas como de processo e projeto, tem-se tambm

32

Fundamentos da Engenharia de Software a classificao das medies como diretas ou indiretas. Presman (2006) considera como medidas diretas do processo de engenharia de software o custo, o esforo aplicados no desenvolvimento e manuteno do software e do produto, a quantidade de linhas de cdigo produzidas, o total de defeitos registrados durante um determinado perodo de tempo, a capacidade de memria consumida, etc. Porm, a qualidade, a funcionalidade do software, a complexidade, a confiabilidade, ou mesmo a capacidade de manuteno so consideradas como medidas indiretas, pois so difceis de ser avaliadas diretamente. Pressman (2006) divide as mtricas tambm segundo o domnio como: mtricas de produtividade, mtricas de qualidade, mtricas tcnicas, mtricas orientada a tamanho e mtricas orientada a funo e mtricas orientadas s pessoas. No Quadro 2.1 h uma breve descrio de cada um desses tipos de mtricas.
Quadro 2.1 Tipos de mtricas segundo o domnio. Mtricas Produtividade Descrio So baseadas na sada do processo de desenvolvimento do software com o objetivo de avaliar o prprio processo. Permitem indicar o nvel de resposta do software s exigncias explcitas e implcitas do cliente. Concentram-se nas caractersticas do software (por exemplo, complexidade Tcnicas lgica, grau de modularidade) e no no processo por meio do qual o software foi desenvolvido. Orientado a tamanho Orientado as pessoas Orientado a funo So usadas para compilar as medies diretas da sada e da qualidade da engenharia de software. Compilam informaes sobre a maneira segundo a qual as pessoas desenvolvem software de computador e percepes humanas sobre a efetividade das ferramentas e mtodos. Fornecem medidas indiretas.

Fique por Dentro


Muitos dos princpios definidos para a especificao de um bom projeto podem ser transformados em atributos de medio de software, por exemplo, modularidade, acoplamento, etc.

Qualidade

Figura 2.1 Diviso de mtricas segundo Presman (2006).

33

Fundamentos da Engenharia de Software Falaremos um pouco mais sobre alguns desses tipos de mtricas nas prximas sees.

2.3.1 Mtricas Orientadas ao Tamanho


Como j mencionado, esta classe de mtricas abrange todas as possveis medidas obtidas diretamente do software (Pressman, 2006). Um exemplo de tal classe de medidas mostrado na tabela a seguir. Como pode ser verificado na tabela desta figura, cada projeto caracterizado por um conjunto de parmetros que permite obter diversas informaes tanto sobre a produtividade do processo quanto sobre a qualidade do software obtido. Pode-se, ento definir algumas grandezas tais como as mostradas no Quadro 2.2.
Quadro 2.2 Mtricas orientadas ao tamanho. Fonte: Adaptado de (CORDEIRO, 2000). Produtividade KLOC/pessoa-ms Qualidade Erros/KLOC Custo $/KLOC Documentao Pgs/KLOC

A despeito da facilidade em sua obteno, existe muita discusso em torno das mtricas orientadas ao tamanho. Um caso bastante discutido o da utilizao do nmero de linhas de cdigo como medida de dimenso. Esta tcnica baseada como o prprio nome sugere na contagem das linhas de cdigo do programa em KLOC (mil linhas de cdigo). Com posse desse dado, possvel calcular a produtividade, qualidade, custo e documentao conforme os exemplos mostrados no Quadro 2.3. Os que defendem o uso desta mtrica, afirmam que um aspecto de fcil obteno e, portanto, de fcil aplicao a qualquer projeto de software, alm de destacar a quantidade de informao existente com base nesta mtrica.
Quadro 2.3 Exemplo de mtricas. Projeto Proj.01 Proj.02 Proj.03 Esforo 24 62 43 Custo 168 440 314 Custo 12,1 27,2 20,2 Pgs 365 1224 1050 Erros 29 86 64 Pessoas 3 5 6

Os que discutem o uso desta informao, alertam para a forte dependncia da linguagem no uso desta tcnica. Voc saberia explicar o porqu dessa dependncia? Alm disso, a mtrica orientada ao tamanho tende a penalizar os programas bem estruturados. uma mtrica que, na verdade, deixa de ser precisa principalmente por causa dos diversos novos fatores introduzidos pelas linguagens de programao mais recentes, alm de ser de difcil aplicao para efeito de estimativas, uma vez que necessrio descer a um nvel de detalhe que no desejvel na etapa de planejamento do projeto.

2.3.2 Mtricas Orientadas Funo


Esta classe de mtricas baseada em medidas indiretas do software e do processo utilizado para obt-lo. Em lugar da contagem do nmero de linhas de cdigo, esta mtrica

34

Fundamentos da Engenharia de Software leva em conta aspectos como a funcionalidade e a utilidade do programa. Uma abordagem proposta nesta classe a do ponto-por-funo (do ingls, function point - FP), a qual baseada em medidas indiretas sobre a complexidade do software. No inteno desta seo explicar detalhadamente o processo de contagem de FP, para isso recomendamos leituras adicionais, contudo na Figura 2.2 ilustrado brevemente o processo adotado para medir os pontos de funo de um sistema.

Voc Sabia?
CFPS Certified Function Point Specialist: a certificao conferida pelo International Function Point Users Group s pessoas aprovadas no exame de certificao.

Figura 2.2 Processo de medio de tamanho por FP.

J na Figura 2.3 ilustrada uma tabela que deve ser preenchida para que se possa obter uma medida sobre a complexidade do software em FP. Os valores a serem computados so os seguintes: nmero de entradas do usurio (EE), nmero de sadas do usurio (SE), nmero de consultas do usurio (CE), nmero de arquivos (ALI) e nmero de interfaces externas (AIE). Uma vez computados todos os dados, um valor de complexidade associado a cada contagem. Feito isto, obtm-se o valor de pontos-por-funo utilizando-se a do Quadro 2.4.
Quadro 2.4 Frmula para o clculo de FP. FP = Contagem Total * [0,65 + 0,01 * SOMA(Fi)]

Na frmula acima, alm da Contagem Total, obtida diretamente da tabela da figura 4.6, Fi (para i = 1 a 14) corresponde a um conjunto de valores de ajuste de complexidade.

35

Fundamentos da Engenharia de Software

Figura 2.3 - Computao da mtrica ponto-por-funo.

Estes valores de ajustes so obtidos a partir de respostas dadas a perguntas feitas a respeito da complexidade do software. No Quadro 2.5, mostramos os parmetros da equao acima, assim como os pesos apresentados na Figura 4.6 (relativos aos nveis de complexidade) so obtidos empiricamente.
Quadro 2.5 Fatores de ajustes do FP. Pontue cada fator (Fi) numa escala de 0 a 5, considerando que: Pontuao 0 sem influncia no sistema Pontuao 1 influncia mnima no sistema Pontuao 2 influncia moderada Pontuao 3 influncia mdia Pontuao 4 influncia significativa Pontuao 5 forte influncia 1. O sistema requer backup e recuperao confiveis? ____ 2. So exigidas comunicaes de dados? ____ 3. O desempenho crtico? ____ 4. H funes de processamento distribuda? ____

36

Fundamentos da Engenharia de Software

5. O sistema funcionar em um ambiente operacional existente, intensivamente utilizado? __ 6. O sistema requer muitas entradas de dados? ____ 7. Existe muita interao homem-mquina? ____ 8. A entrada, sada, arquivos ou consultas so complexos? ____ 9. O processamento interno complexo? ____ 10. A converso e instalao esto includas no projeto? ____ 11. O sistema projetado para mltiplas instalaes em diferentes organizaes? ____ 12. A aplicao projetada de forma a facilitar mudanas e o uso pelo usurio? ____ 13. O sistema requer muita entrada de dados? ____ 14. Existe muita atualizao de arquivos on-line? ____

Enfim, os passos para contar os FP so apresentados de forma breve no quadro a seguir.


Quadro 2.6 Passos para contar FP.

1. Contam-se os nmeros de entradas, sadas, consultas, arquivos e interfaces do sistema; 2. Multiplica-se cada um desses nmeros por um peso, de acordo com a complexidade do sistema e soma-se os resultados; 3. Responde-se a uma srie de perguntas, as quais fornecem, cada uma, um valor de 0 a 5,soma-se os valores obtidos; 4. Finalmente, calcula-se o nmero de pontos de funo com a equao do Quadro 2.5

Tambm apresentamos um pequeno exemplo no Quadro 2.7.

37

Fundamentos da Engenharia de Software


Quadro 2.7 Exemplo de contagem de FP. Calcule os pontos de funo para um sistema que mantm um Cadastro de Clientes onde possvel tirar uma listagem por ordem alfabtica e exportar o cadastro para outro sistema atravs de um arquivo texto. Contagem: Entradas = 01 (Processo de incluso) Sadas = 01 (Listagem por ordem alfabtica) Consultas = 01 (Exportao de Arquivo Texto) Arquivos = 01(Arquivo de Clientes) Interface ext. = 0 Considerando todos os tipos de funo nesse exemplo de complexidade BAIXA. Contagem Total = Arquivos x 7 + Inferface ext. x 5 + Entradas x 3 + Sadas x 4 + Consultas x 3 Contagem Total = 1 x 7 + 0 x 5 + 1 x 3 + 1 x 4 + 1 x 3 = 17 (Pontos de funo no ajustados) Contado-se os fatores de ajuste segundo os nveis de influncia temos, considerando-se Nt(total) = 45, temos: Fator de Ajustes = 0,65 + (0,01*45 ) = 1,1 (Fator de Ajuste) FP = Fator de Ajustes x Contagem Total = 1,1 x 17 = 18,7 O tamanho da complexidade do Cadastro dado por 18,7 fp.

Voc Sabia?
Cobol uma linguagem de programao. DB2 sistema gerenciador de bando de dados da IBM. RAD uma metodologia de desenvolvimento de software.

Da mesma maneira que a medida em metros quadrados do tamanho de uma casa no permite deduzir a velocidade com a qual a casa pode ser construda ou o seu tempo de construo, o tamanho em Pontos de Funo no mede a produtividade ou o esforo de desenvolvimento. Pontos de funo medem o tamanho do que o software faz, ao invs de como ele desenvolvido e implementado. Isto significa que, dado um conjunto de requisitos de usurio, o tamanho funcional do software ser mesmo, seja ele desenvolvido com a utilizao de Cobol ou DB2, usando desenvolvimento rpido de aplicaes (RAD), ou mtodos estruturados de desenvolvimento. Outra medida por funo pontos de caso de uso ou UCP (do ingls, use case points). O UCP foi criado por Gustav Karner em 1993 como uma adaptao especfica dos pontos de funo. Podemos dizer que o UCP ainda no to divulgado nem utilizado na indstria quanto o FP, contudo, h muitas pesquisas acadmicas sobre o assunto. Na seo Saiba mais recomendamos artigos sobre esse assunto.

38

Fundamentos da Engenharia de Software

2.4 Processo GQM (do ingls goal-questionmetric)


Muitos processos de medio comeam medindo o que conveniente ou fcil de medir, em vez de medir o que necessrio. O GQM se baseia na crena de que a medio, para ser efetiva, tem que ser focada em objetivos especficos.

Figura 2.4 Abordagem GQM. Fonte: (BASILI ET AL., 2002)

O processo GQM simples. Inicia-se com a identificao dos interessados na medio. Com base nos interessados, estabelecem-se os principais objetivos da medio para a organizao, o projeto ou uma tarefa especfica. Ex: reduzir defeitos, aumentar produtividade, etc. A partir dos objetivos, geram-se perguntas cujas respostas diro se os objetivos foram ou no alcanados (ex: Qual a taxa de defeito atual? Qual a taxa de defeito aps a implantao do novo processo?) A partir das perguntas, definem-se mtricas: que dados sero necessrios? Quais os formatos? Como coletar (frmula e processo)? Onde armazenar e como utilizar? Um exemplo de GQM apresentado no Quadro 2.8.
Quadro 2.8 Exemplo de GQM. Objetivo: Assegurar que todos os defeitos so corrigidos antes do software ser liberado para uso. Perguntas: Quantos defeitos temos atualmente? Qual o status de cada defeito? Qual a cobertura dos testes? Mtricas: Nmero de defeitos Nmero de defeitos por status Nmero de casos de testes planejados x executados Nmero de requisitos testados

Voc Sabia?
O GQM foi proposto por Basili and Rombachs, GoalQuestion-Metrics Paradigm, IEEE Transactions on Software Engineering, 1988.

39

Fundamentos da Engenharia de Software O GQM hoje empregado com sucesso em diversos ambientes industriais e tem como objetivo fornecer um autoconhecimento das prticas vigentes, e serve ainda como base para anlise quantitativa dos processos, sendo assim bastante til para organizaes que almejam aplicar melhoria nos mesmos e at mesmo conseguir atender requisitos de modelos especficos de qualidade.

2.5 Estimativas de Software


Como podemos notar, a estimativa de software uma das principais atividades do planejamento de um projeto de software e ela est estritamente associada com as mtricas. Por exemplo, da estimativa depende a viabilidade do projeto (isto , a verificao se vale realmente desenvolver o projeto em termos de custos, mercado, prazo, etc?). A estimativa exerce tambm grande influncia no processo de desenvolvimento de software, pois dela depende a alocao e distribuio de recursos do projeto durante todo o ciclo de produo, por exemplo. Dessa forma, estimar fundamental. Na prtica, as estimativas podem ser realizadas de trs formas: a) por analogias: nesse caso, as estimativas so baseadas na experincia de quem faz. Quanto mais estimativas feitas, maior o conhecimento e maior a possibilidade de acerto. Como vantagens dessa forma de fazer as estimativas, podemos citar que baseada em experincia passada, aplicvel para projetos com baixo nvel de detalhe e, normalmente, tem o compromisso do grupo que produziu a estimativa. Como desvantagens, citamos: est sujeito presso, necessita de especialistas da Empresa, pode apresentar grande desvio, altamente dependente de experincia passada, no deve ser utilizado para projetos grandes e no produz indicadores. b) Modelos algoritmos: nesse caso, utiliza-se de algoritmos para gerar os dados estimados. Um dos mais conhecidos o mtodo COCOMO (do ingls, Constructive Cost Model). Esse mtodo foi desenvolvido para estimar esforos de desenvolvimento, prazo e tamanho de equipe para um projeto de sistemas. Ele baseado no nmero de instrues fontes (nmero de linhas de cdigo ) e supe que as especificaes dos requisitos no sero alteradas substancialmente aps a fase de Planejamento e Requisitos. Como vantagens, citamos: baseado em experincia passada, fundamentado em frmula matemtica e pode ser aplicado nas diversas fases do ciclo de desenvolvimento. Como desvantagens, citamos: dependente da tecnologia, dependente de experincia passada e no produz indicadores. c) Anlise de funcionalidade: uma das mtricas mais utilizadas nesse sentido o ponto de funo (FP) que como vimos mede o tamanho do software pela quantificao de sua funcionalidade externa, baseada no projeto lgico ou a partir do modelo de dados, abrange a funcionalidade especfica requerida pelo usurio para o projeto. Como vantagens, citamos: a estimativa feita em funo da viso do usurio; facilidade de aprendizagem e aplicao da tcnica, independncia de tecnologia, apoiar e acompanhar a avaliao de produtividade e de qualidade de projetos de software, prover um fator de comparao de softwares, possibilitar a coleta de dados para obteno de diversos indicadores de acompanhamento, aplicabilidade nas diversas fases de desenvolvimento. Como desvantagens, citamos: necessita acompanhamento constante das medies para gerar os diversos indicadores possveis, a aplicabilidade nas diversas fases requer esforo de contagens de pontos de funo para cada fase e requer um meio eficiente de armazenamento das informaes obtidas nas contagens.

40

Fundamentos da Engenharia de Software Como as estimativas so feitas antes ou no incio do desenvolvimento, elas podem estar equivocadas por estarem baseadas em requisitos errados ou incompletos. Contudo, isso uma caracterstica natural, pois inicialmente tratamos de dados estimados, caso contrrio teramos dados exatos, que seria o cenrio ideal, mas quase impossvel de ser conquistado em ES J. Ento, bom se acostumar com a ideia de estimar baseados em dados ainda em evoluo, o importante considerar sempre um intervalo de erro tanto para mais quanto para menos nas estimativas. Tambm importante ter em mente que o processo de estimativa de software seja contnuo e est sujeito a mudanas. Enfim, o problema de estimar um projeto de software nunca ser um problema fcil de resolver, pois existe um grande nmero de variveis que podem influenci-lo. Porm, em sua grande maioria, envolve a previso, sobretudo, de quatro variveis: o tamanho, o esforo, custos, os prazos e a qualidade. De uma forma generalizada, podemos resumir o processo de estimativa nos seguintes passos: 1. Estimar o tamanho do produto 2. Estimar o esforo 3. Estimar o prazo 4. Estimar os custos 5. Fornecer estimativas dentro de uma faixa permitida e refinar essa faixa medida que o projeto progride Normalmente, o esforo, o prazo e custos so derivados da estimativa do tamanho do produto de software. Para se estimar o tamanho do software de forma mais precisa possvel, essencial para o gerente de um projeto ter um bom domnio com relao ao problema e requisitos envolvidos do sistema. o primeiro procedimento do processo de estimativa e a preocupao em med-lo surgiu com o objetivo de estimar o esforo e custo de trabalho dos desenvolvedores. Como vimos nas sees anteriores, a estimativa de tamanho do software pode ser baseada em mtricas como linhas de cdigo (LOC) ou pontos de funo (FP), dentre outras existentes. A partir do resultado da estimativa do tamanho, o prazo e os custos, por exemplo, podem ser derivados. Na estimativa de esforo, alm do tamanho estimado do software tambm pode ser considerada a mtrica sobre a produtividade da equipe. Por exemplo, imaginemos um projeto no qual obtemos um total de 100 FP, numa fase que corresponde a 20% do Projeto, com uma equipe de 4 pessoas, considerando uma produtividade mdia de 20hs/FP, considerando uma jornada de 6 horas dirias e considerando um valor de R$35,00 o valor de 1 hora de trabalho. Poderamos definir uma estimativa assim: 20% de 100 FP = 20 FP. Assim, iremos estimar o esforo para implementar 20 FP. Esforo considerando a produtividade como 20hs/FP ento: produtividade x tamanho resulta no esforo. Assim, temos: 20hs/FP x 20FP = 400h de esforo Prazo leva em considerao o esforo e o tamanho da equipe e quantidade real de horas trabalhadas. Assim, 400h/(4 x 6) = 16,7 Dias Custo - 400h x R$ 35,00 = R$ 14.000,00

Lembrete
Quando falamos de produto de software, lembre-se que isto inclui no apenas o programa, mas todos os artefatos associados como documento de requisitos, manuais, modelo de projeto, etc. Assim, as estimativas devem incluir todos esses itens.

Entenderam?! No quadro 2.9 apresentamos resumidamente as frmulas usadas nas estimativas com FP.

41

Fundamentos da Engenharia de Software


Quadro 2.9 Tcnica de estimativa usando FP. Produtividade no desenvolvimento: Horas por FP Esforo de desenvolvimento: Produtividade (H/FP) * Tamanho (FP) Custo de software: Tamanho (FP) * Custo (R$/FP) Taxa de produo de software: FP/Ms; FP/Ano Taxa de manuteno de software: FP manuteno / FP aplicativo

Muitos fatores podem interferir na produtividade da equipe, entre eles est o nmero de integrantes e o nvel de interao e respeito entre os mesmos. O conhecimento com relao plataforma tecnolgica empregada (linguagens de programao, frameworks, bibliotecas, etc.), o domnio no qual est inserido o sistema a ser desenvolvido e a experincia adquirida em projetos anteriormente realizados influenciam de forma decisiva na mensurao da estimativa de esforo. Tambm podem influenciar na produtividade o nvel de reutilizao utilizado no desenvolvimento e o uso de metodologia de desenvolvimento de software. Vamos a mais um exemplo prtico. Considere o cenrio de um projeto de uma Empresa em que: A taxa de produtividade diria da equipe de = 80 % a mdia de produtividade da Empresa. Produtividade mdia para um determinado tipo de projeto da Empresa = 15 pf / hora Tamanho do projeto estimado = 1520 pf Calendrio = no se trabalha aos sbados, domingos e feriados

Como responder as perguntas: Qual a durao prevista do projeto? Qual a data de trmino se o incio ocorrer em 03 de maio? Qual a data de incio se o trmino deve ocorrer em 17 de junho?

Vamos aos clculos. Respondendo a primeira pergunta: qual a durao prevista do projeto? Neste caso, devemos calcular. Produtividade + realista dado que a equipe s produz na taxa de 80% da mdia, assim a produtividade real = 15 * 0,8 = 12 pf / hm

42

Fundamentos da Engenharia de Software Jornada diria = 8 h * 0,8 = 6,4 hm Durao em horas: 1520 pf / 12 pf / hm = 126,7 hm Durao em dias : 126,7 / 6,4 = 19,8 dias teis Respondendo a segunda pergunta: qual a data de trmino se o incio ocorrer em 03 de maio? 03/mai + 19 dias uteis = 28 / mai Respondendo a terceira pergunta: qual a data de incio se o trmino deve ocorrer em 17 de junho ? 17/06 19 dias teis = 21/05 Apesar das estimativas serem um pouco de arte e um pouco de cincia, esta importante atividade no deve ser conduzida de forma desordenada. As estimativas podem ser consideradas a fundao para todas as outras atividades de planejamento de projeto.

Atividades e Orientaes de Estudos


Para melhor assimilar o contedo deste captulo sugerimos algumas atividades de fixao exatamente como o capitulo anterior. Como o assunto simples e bem objetivo, teremos basicamente os mesmos tipos de atividades definidos para o captulo anterior, so elas: Atividades prticas: representam questes simples e objetivas sobre o assunto aqui abordado. Na prtica, bastar estudar o assunto contido no captulo para respond-las corretamente. Atividades de pesquisas: representam tpicos de pesquisas dirigidos no muito extensos. Para cada tpico de pesquisa sugerido indicaremos fontes que podero auxiliar na pesquisa, mas voc ter total liberdade de consultar outras fontes caso deseje. Em cima do tpico sugerido, definimos algumas questes que devero ser respondidas. Sugerimos ainda que as atividades de pesquisa sejam feitas em equipe, pois isso favorece o aprendizado e enriquece a discusso sobre o assunto. Atividades de interao: correspondem atividades que visam discutir sobre o assunto nos fruns criados para o curso.

Como as atividades seguem o mesmo modelo do capitulo anterior, no forneceremos exemplos respondidos. Caso tenha dvidas a respeito, consulte-nos! Estamos aqui para auxiliar uns aos outros na construo do saber.

Aprenda Praticando: Exerccio Proposto 2.1


Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1) Explique com suas palavras, por que to importante medir o software? 2) Explique a diferena entre mtricas de processo e projeto? Use suas prprias palavras, ok?! 3) D exemplos de atributos diretos e indiretos do software que podem ser medidos?

43

Fundamentos da Engenharia de Software 4) Da afirmao de Yourdon e Constantine (1979) descrita abaixo identifique que atributos diretos so mencionados e que atributo indireto eles afetam na medio do software. Projetos de software que possuem mdulos com baixo acoplamento entre si e alta coeso do origem a cdigos mais confiveis e fceis de manter. (YOURDON, E.; CONSTANTINE, L. L. Structured Design. Prentice Hall, Englewood Cliffs, NJ, 1979) 5) Explique por que algumas mtricas precisam ser mantidas privadas, isto , visveis a um pequeno grupo de pessoas da empresa ou organizao? Cite exemplos. 6) Indique as vantagens e desvantagens de adotar a mtrica de tamanho LOC para o projeto de software. 7) Apresente um argumento contra o uso da contagem de linhas de cdigo como indicador da produtividade (questo adaptada de Pressman (2006)). 8) A equipe A encontrou 342 erros durante o processo de engenharia de software anterior entrega. A equipe B encontrou 184 erros. Que medidas adicionais deveriam ser tomadas com relao aos projetos A e B para determinar qual das equipes eliminou erros mais eficientemente? Que mtricas voc proporia para ajud-lo a fazer essa determinao? (PRESMAN, 2006). 9) Suponha que ser desenvolvido um sistema e que depois de ser realizada a fase de Anlise do Sistema, chegou-se s seguintes caractersticas: a. Nro de entradas do usurio: 32 b. Nro de sadas do usurio: 60 c. Nro de consultas do usurio: 24 d. Nro de arquivos: 8 e. Nro de interfaces externas: 2 Compute o valor do Ponto por Funo (PF) desse sistema, considerando os valores de ajuste como sendo mdios. 1) Vamos supor o cenrio GQM em que voc tem como objetivo aumentar o rendimento no curso. Estabelea, no mnimo, duas perguntas e duas mtricas para que se possa avaliar o alcance desse objetivo. 2) Tendo como base no tamanho de FP do sistema definido na questo 09, calcule estimativas de esforo, prazo e custo (dias) considerando que a produtividade mdia em FP 12 fp/hm, o custo de 1 FP RS 120,00, e jornada diria de 6,4hm.

Aprenda Pesquisando: Pesquisa Proposta 2.1


A fim de aprofundar um pouco mais seu conhecimento sobre as Mtricas e Estimativas de Software, selecionamos alguns tpicos para pesquisa. 1) Pesquise sobre pontos de caso de uso. Descreva-o em duas a trs pginas, dando informaes de como funciona, com exemplos de contagem de complexidade e descrevendo vantagens e desvantagens dessa mtrica.

44

Fundamentos da Engenharia de Software

Aprenda Interagindo: Exercicio de Interao 2.1


Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o capitulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. bom sempre lembrar que ser preciso voc acessar o ambiente para realizar as atividades de interao. No esquea: voc tambm ser avaliado pelas participaes significativas nos fruns de discusso apresentados no ambiente. 1) Quando voc contrata o servio de um pedreiro, ele, aps saber exatamente o que tem que fazer, faz alguns clculos e lhe d o preo final do seu trabalho. O mesmo ocorre nas reas de engenharia civil, mecnica, etc. Por que to difcil estimar o valor de um projeto de software ? Por que to complexo fazer estimativas nesta rea? Tente responder a pergunta baseado no que estudamos at agora e explicando como as mtricas podem ajudar nesse sentido. 2) Voc capaz de estimar quanto de esforo e custo esse curso j demandou e ainda demandar para voc? Pense sobre isso, reflita! Verifique se o que voc gasta em termos de esforo na realidade no curso, est prximo do que realmente necessrio.

Saiba Mais
Para conhecer um pouco mais sobre mtricas e estimativas de software h vrios livros e artigos disponveis, seguem algumas boas sugestes. Recomendamos a leitura do artigo Mtricas e Estimativas de Software - O incio de um rally de regularidadeescrito por Alvaro Eduardo Gomes e diponibilizado eletrnicamente no stio Linha de Cdigo. Disponvel em: <http://www. linhadecodigo.com.br/Artigo.aspx?id=102> Recomendamos a leitura das notas de apresentao de Manoel Abrantes sobre Mtricas de Software em Projetos de Sistemas de Informao. Disponvel em: <http://www.pmidf.org/encontrogp/palestras/manoel.pdf>. Recomendamos a leitura dos captulos 22 e 23 do livro do Presman (2006). Repositrio com vrios artigos falando sobre anlise por pontos de funo (em ingls). Disponvel em: <http://www.iturls.com/english/SoftwareEngineering/ SE_23.asp> Outro repositrio de artigos sobre pontos de funo. Disponvel em: < http://www. bfpug.com.br/artigos.htm>. Artigo em portugus que explica em maiores detalhes a anlise de pontos por funo. Disponvel em: <http://www.inf.ufes.br/~falbo/download/aulas/es-g/20051/APF.pdf>. Um artigo que descreve um estudo de caso do uso de pontos de caso de uso como mtricas para as estimativas do software. Disponvel em: <http://www.inf.furb.br/ seminco/2005/artigos/130-vf.pdf>

45

Fundamentos da Engenharia de Software

Voc Sabia?
Veja algumas curiosidades atualizadas sobre Pontos de Funo: Voc sabia que... Alm do IFPUG , o NESMA tambm promove o uso de pontos de funo e publica o seu prprio manual de contagem complacente com o manual do IFPUG. O manual da NESMA apresenta trs tipos de contagens por pontos de funo: a contagem indicativa de ponto de funo, a contagem estimada de ponto de funo e a contagem detalhada de pontos de funo. A contagem indicativa muito usada, nela so identificados os grupamentos de dados relativos natureza do negcio, conforme a viso do usurio. Estes grupamentos so classificados como Internos (mantidos pela aplicao e Externos (referenciados ou consultados pela aplicao). Para calcular o tamanho de uma aplicao em Pontos de Funo no Ajustados (PFNA) a NESMA recomenda a seguinte frmula: PFNA = ( 35 * I) + ( 15 * E ). Fonte: NESMA. Disponvel em: <http://www.nesma.nl/english/nesma&ifpug.htm>

Dica de Cinema
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns vdeos de apenas 10 minutos, cada, disponibilizados livremente na Internet (You Tube). O contedo claro, objetivo e correto. Vale a pena ser visto! Um vdeo de humor, curto, desenvolvido por alunos de curso de sistema de informao descrevendo os problemas de um projeto de software que no se utilizou de mtricas para seu planejamento e execuo. Disponvel em: <http://www.youtube.com/watch?v=f3xGRlTuXTI> Caso queira conhecer um pouco mais sobre anlise de ponto de funo, voc pode consultar o vdeo seguinte: <http://www.youtube.com/watch?v=IJB5GmOBXQI>.

Vamos Revisar?

Resumo
A medio permite a gerentes e profissionais melhorar e aperfeioar o processo de software, colaborar no planejamento, acompanhamento e controle de um projeto de software, e avaliar a qualidade do produto (software) que produzido. Medidas de atributos especficos do processo, projeto e produto so usadas para calcular mtricas de software. Essas mtricas podem ser analisadas para obter indicadores que orientam as aes gerenciais e tcnicas. Quando se fala em estimativas, est-se tratando na realidade de diversos tipos de estimativas: tamanho, esforo, recursos, tempo e custos. Geralmente, a realizao de estimativas comea pelas estimativas de tamanho. A partir delas, estima-se o esforo necessrio e, na sequncia, alocam-se os recursos necessrios, elabora-se o cronograma do projeto (estimativas de tempo) e, por fim, estima-se o custo do projeto.

46

Fundamentos da Engenharia de Software

Captulo 3 PMBOK
Vamos conversar sobre o assunto?
Atualmente, mudanas em diversos aspectos da vida humana (culturais, tecnolgicos, polticos, econmicos, sociais, etc) esto ocorrendo em velocidade cada vez maior. De uma maneira geral, comum associarmos as mudanas significativas ao resultado de projetos (VIEIRA, 2002). Como consequncia, gerenciar projetos de forma eficiente nessa era de grandes mudanas um dos grandes desafios do executivo dos tempos modernos (KERZNER, 2001). Superar este desafio estar preparado para gerenciar projetos de forma planejada e profissional. Como o captulo anterior, o captulo 3 desta unidade tambm uma complementao do conhecimento de Gerncia de Projetos. Aqui, abordado brevemente o Corpo de Conhecimento sobre Gerenciamento de Projetos definido pelo PMI, o chamado PMBOK. Abordaremos resumidamente os tpicos: O que o PMBOK Histrico do PMBOK Viso geral Conjunto de processos

3.1 O que PMBOK?


Nos dois ltimos captulos tivemos uma viso geral sobre Gerncia de Projetos e tambm aprendemos um pouco sobre mtricas e estimativas, assuntos esses, essenciais para o planejamento e gesto do projeto. Para complementar ainda mais seu conhecimento sobre a rea, vamos falar sobre um dos guias mais conhecido em Gerenciamento de Projetos O PMBOK (2004), denominado como o Corpo de Conhecimento em Gesto de Projetos. O PMBOK foi desenvolvido pelo Instituto de Gesto de Projetos (PMI Project Management Institute) e descreve a soma de conhecimento para profisso de gesto de projeto (PMI, 2000) de forma similar ao SWEBOK estudado nos primeiros captulos deste

Fique por Dentro


O SWEBOK representa um guia do Corpo de Conhecimento da Engenharia de Software. Esse guia rene as melhores prticas e conhecimentos para ES.

47

Fundamentos da Engenharia de Software curso, voc lembra? O objetivo principal do Corpo de Conhecimento em Gesto de Projetos identificar e descrever o conhecimento e as prticas de gesto aplicveis maioria dos projetos, independente de sua natureza. Alm disso, o Corpo de Conhecimento em Gesto de Projetos prov uma linguagem comum para as atividades de gesto de projetos. Tambm importante frisar que o PMBOK descreve aquele conjunto de conhecimentos em gerenciamento de projeto que geralmente aceito. Geralmente aceito significa que o conhecimento e as prticas descritas so aplicveis na maioria dos projetos e na maioria dos casos e que existe um amplo consenso sobre seus valores e sua utilidade. O conjunto de conhecimentos organizado em nove reas. Algumas dessas reas podem ser menos relevantes em alguns projetos do que em outros, dependendo do tipo, do enfoque ou do tamanho do projeto. No entanto, as caractersticas bsicas so sempre as mesmas e a pertinncia de cada rea deveria ser ao menos contemplada. No captulo 1 deste fascculo, descrevemos alguns dos conceitos fundamentais e comum a rea, como o que projeto, quais as caractersticas, ciclo de vida e etc. Atualmente, o PMBOK est em sua 4 edio, publicado oficialmente em 2008. As diferenas entre esta e a verso anterior est na reduo do nmero de processos, que de 44 passaram a ser 42. Antes de conhecer esses processos, vamos aprender um pouco da histria desse guia.

3.2 Breve Histrico


O Instituto de Gesto de Projetos (PMI) foi fundado em 1969 por cinco voluntrios. O estado da Pennsylvania, Estados Unidos, emitiu artigos de incorporao que significaram o incio oficial da organizao. No mesmo ano, o primeiro Seminrio e Simpsio do Instituto de Gesto de Projetos foi realizado em Atlanta, com a participao de 83 pessoas.

Fique por Dentro


Stakeholders representam pessoas envolvidas ou interessadas no desenvolvimento e nos resultados do projeto em execuo. Por exemplo, clientes, usurios finais.

Na dcada de 1970 foi realizada a primeira publicao do Peridico Trimestral de Gesto de Projetos (PMQ Project Management Quarterly), o qual mais tarde foi chamado de Jornal da Gesto de Projetos (PMJ Project Management Journal). Foi realizado o primeiro Seminrio e Simpsio Anual fora dos Estados Unidos, o primeiro Captulo do Instituto de Gesto de Projetos foi estabelecido e o Programa de Prmio do Profissional foi estabelecido. No final da dcada, os membros do Instituto de Gesto de Projetos totalizavam em 2000 em todo o mundo. Durante a dcada de 1980, os membros, programas e servios do Instituto de Gesto de Projetos continuaram a crescer. Foi adotado um Cdigo de tica para a profisso e o primeiro exame de certificao de Profissional de Gesto de Projetos (PMP Project Management Professional) foi realizado. O primeiro padro de gesto de projetos foi publicado e, devido ao sucesso, deu origem a Diviso de Publicao, estabelecida na Carolina do Norte. Em 1990, os membros do Instituto de Gesto de Projetos eram mais de 8500 e, em 1993, a taxa anual de crescimento subiu para 20 por cento. Nesta dcada foi publicado o Guia para o Corpo de Conhecimento em Gesto de Projetos. Hoje, o Instituto de Gesto de Projetos possui mais de 100.000 membros em 125 pases, os quais estudam e praticam a gesto de projetos em diferentes reas da indstria, incluindo aeroespacial, automotiva, negcios, construo, engenharia, finanas, tecnologia da informao, farmacutica e telecomunicaes. O PMI estima que aproximadamente 25% do PIB mundial so gastos em projetos e que cerca de 16,5 milhes de profissionais esto envolvidos diretamente com gerncia de projetos no mundo.

48

Fundamentos da Engenharia de Software

3.3 Viso Geral do PMBOK


Segundo o PMBOK (2004), a gerncia de projeto a aplicao de conhecimentos, habilidades, ferramentas e tcnicas em atividades do projeto, a fim de satisfazer ou exceder necessidades e expectativas dos interessados e envolvidos (stakeholders). Essa definio, inclusive, j foi dada no captulo 1 deste fascculo. Entenda como satisfazer ou exceder as necessidades e as expectativas a capacidade de equilibrar demandas concorrentes em termos de: integrao, escopo, tempo, custo, qualidade, recursos humanos, comunicao, riscos e aquisio. Escopo, prazo, custo e qualidade; Interessados e envolvidos com necessidades e expectativas diferenciadas; Requisitos identificados (necessidades) e requisitos no identificados (expectativas).

O PMBOK divide as prticas de gesto de projetos em processos dentro de 9 reas de conhecimento, conforme ilustra a Figura 3.1. Cada rea de conhecimento refere-se a um aspecto a ser considerado dentro da gerncia de projetos, por exemplo, definio de escopo, gerenciamento do tempo (cronograma), etc. A no-execuo de um desses processos ir afetar negativamente o projeto, pois o projeto um esforo integrado. Por exemplo, uma mudana de escopo quase sempre afeta o custo do projeto. Entretanto, ela pode ou no afetar a moral da equipe e a qualidade do produto (PMI, 2000).

Figura 3.1 As nove reas de conhecimento do PMBOK.

Segue uma descrio resumida de cada rea. Gerncia de integrao: descreve os processos necessrios para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. A integrao envolve tomada de deciso e escolhas diretamente ligadas aos objetivos do projeto e aos processos das etapas de desenvolvimento e execuo do plano do projeto, assim como ao processo de controle de alteraes. O gerenciamento da integrao composto pelos processos: desenvolvimento do plano do projeto, execuo do plano do projeto e controle integrado de mudanas. Gerncia de escopo: envolve os processos necessrios para assegurar que o projeto contenha todo o trabalho necessrio para completar o projeto com sucesso. Seu foco principal na definio e controle do que est ou no includo no projeto; Gerncia de tempo: envolve os processos necessrios para assegurar que o projeto termine dentro do prazo previsto. Ele composto pelos processos: definio das atividades, sequenciamento das atividades, estimativa da durao das atividades,

Saiba Mais
No Brasil h a Associao Brasileira de Gerncia de Projetos (ABGP) que adota a certificao e padro IPMA de Gerncia de Projetos. Fonte: ABGP. Diponvel em: <HTTP://www. abgp.org.br>

49

Fundamentos da Engenharia de Software desenvolvimento do cronograma e controle do cronograma; Gerncia de custo: descreve os processos necessrios para assegurar que o projeto termine dentro do oramento aprovado. Ele composto pelos processos: planejamento dos recursos, estimativa dos custos, oramento dos custos e controle dos custos. No projeto, vrias atividades afetam os custos do projeto e, desta forma, o planejamento e controle dos custos so fundamentais; Gerncia da qualidade: envolve os processos requeridos para assegurar que o projeto satisfaa as necessidades para as quais foi criado. Isso inclui todas as atividades de gerncia geral que determinam os objetivos, a poltica e as responsabilidades em relao qualidade e a suas implementaes, tais como: planejamento,controle, garantia e melhoria de qualidade dentro do sistema de qualidade; Gerncia de recursos humanos: envolve os processos necessrios para proporcionar a melhor utilizao das pessoas envolvidas no projeto. Embora seja uma rea de conhecimento, na maioria das vezes, complexa e subjetiva exige constante pesquisa, sensibilidade e muita vivncia do dia-a-dia para saber lidar com o ser humano. Ela composta pelos processos: planejamento organizacional, montagem da equipe e desenvolvimento da equipe; Gerncia de comunicao: descreve os processos necessrios para assegurar a gerao, captura, distribuio, armazenamento e pronta apresentao das informaes do projeto para que sejam feitas de forma adequada e no tempo certo. A gesto da comunicao frequentemente ignorada pelos gerentes de projeto, no entanto nos projetos concludos com sucesso o gerente gasta 90% do seu tempo envolvido com algum tipo de comunicao (formal, informal, verbal, escrita). Este gerenciamento composto pelos processos: planejamento das comunicaes, distribuio das informaes, relato de desempenho e encerramento administrativo; Gerncia de risco: descreve os processos que dizem respeito identificao, anlise e resposta aos riscos do projeto. Segundo Gates (1999), grandes vitrias demandam grandes riscos. A prtica deste gerenciamento no ainda muito comum na maioria das organizaes e alguns autores citam que gerenciar projetos gerenciar riscos. O gerenciamento de riscos muito importante para o sucesso do projeto e composto pelos seguintes processos: planejamento da gerncia de fisco, identificao dos riscos, anlise qualitativa de riscos, anlise quantitativa de riscos, desenvolvimento das respostas aos riscos e controle e monitorao de riscos. Falamos sobre alguns desses pontos no captulo 1 deste fascculo, lembra?! Gerncia de aquisio: envolve os processos requeridos para adquirir bens e servios externos organizao Essa rea de conhecimento descreve os processos necessrios para a aquisio de mercadorias e servios fora da organizao que desenvolve o projeto Este gerenciamento discutido do ponto de vista do comprador na relao comprador-fornecedor. Ele composto pelos processos: planejamento das aquisies, preparao das aquisies, obteno de propostas, seleo de fornecedores, administrao dos contratos e encerramento do contrato.

Saiba Mais
Uma entidade alternativa ao PMI a International Project Management Association (IPMA), mais difundida na Europa. A Associao Brasileira de Gerenciamento de Projetos (ABGP) est filiada, desde julho de 2002, IPMA. O documento IPMA Competence Baseline (ICB), correspondente do PMBOK, foi a principal referncia para a elaborao do Referencial Brasileiro de Competncias (RBC) em Gerenciamento de Projetos, utilizado pela ABGP/IPMA na certificao de Gerentes de Projetos no Brasil.

importante ressaltar que no necessrio que todo o conhecimento e prticas descritos pelo PMBOK sejam aplicados uniformemente em todos os projetos. Sendo assim, deve ser estabelecido um time responsvel para determinar o que apropriado para cada projeto. Cada rea de conhecimento em si descrita por um conjunto de processos, em que se apresentam as entradas e as sadas do processo, as ferramentas adotadas para apoiar a execuo dos processos, e, por fim, apresenta as tcnicas principais adotadas para executar

50

Fundamentos da Engenharia de Software o referido processo. Baseado nos processos das reas de conhecimento, o PMBOK tambm agrupa esses processos em cinco categorias baseado no ciclo de vida do projeto. Podemos dizer tambm que a classificao desses processos tem certa correspondncia com o conceito do ciclo PDCA (do ingls Plan - Do - Check - Act ou Planejar - Fazer - Verificar - Agir). O grupo de Planejamento corresponde ao Planejar; Execuo, ao Fazer; e Monitoramento e controle englobam Verificar e Agir. E como a natureza dos projetos finita, o PMBOK ainda caracteriza os grupos de processos que iniciam (Iniciao) e finalizam (Encerramento) um projeto. Os grupos de processos so: Processos de iniciao: define e autoriza um projeto ou uma fase do projeto, em outras palavras, esses processos so responsveis por dar o pontap de incio do projeto, atravs do termo de abertura, por exemplo; Processos de planejamento: define e refina os objetivos e planeja a ao necessria para alcanar os objetivos e o escopo para os quais o projeto foi realizado. So esses processos que resultam no cronograma, na anlise de riscos, na alocao de recursos, dentre outros pontos; Processos de execuo: integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto para o projeto; Processos de monitoramento e controle: mede e monitora regularmente o progresso para identificar variaes em relao ao plano de gerenciamento do projeto, de forma que possam ser tomadas aes corretivas quando necessrio para atender aos objetivos do projeto; Processos de encerramento: formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado.

Na Figura 3.2 mostramos os relacionamentos entre os grupos de processos e na Figura 3.3 mostramos alguns resultados alcanados com a execuo das atividades dos grupos de processos. J a Figura 3.4 ilustra a relao entre os grupos de processos e as reas de conhecimento. Cada cor representa uma rea de conhecimento.

Figura 3.2 Cinco classes de processos definidos pelo PMBOK (2008).

51

Fundamentos da Engenharia de Software


Grupo de Processos Iniciao Ferramentas / Processos Proposta aprovada Dados do projeto: objetivos; Cronograma Bsico Dados do projeto: EAP e EOP; Cronogramas Riscos e fatores crticos de sucesso Execuo das tarefas Acompanhamento das tarefas Controle Pontos de controle Controle de mudanas Controle de pendncias Relatrio final Encerramento Lies aprendidas Desmobilizaes Figura 3.3 Cinco classes de processos definidos pelo PMBOK.

Planejamento Execuo

A Figura 3.4 demonstra os processos das reas de conhecimento por grupos de processos. Por exemplo, no grupo de iniciao h os processos de desenvolvimento de abertura do projeto, identificao das partes interessadas.

Figura 3.4 Relacionamento entre grupos de processos e reas de conhecimento.

A seguir so descritas as reas de conhecimento do modelo com o detalhamento de alguns dos principais processos, os quais tero identificados os grupos a que pertencem

52

Fundamentos da Engenharia de Software entre parnteses, aps o nome. Alm disso, sero apresentadas as entradas, ferramentas e sadas relacionadas a cada um. Quem desejar conhecer mais sobre os demais processos no descritos aqui, aconselhamos a leitura do prprio PMBOK.

3.3.1 Gerncia da Integrao do Projeto


Como j mencionamos a Gerncia da Integrao do Projeto envolve os processos necessrios para assegurar que os diversos elementos do projeto sejam adequadamente coordenados. Envolve as negociaes dos conflitos entre os objetivos e alternativas concorrentes, com a finalidade de atingir ou superar as necessidades e expectativas das partes interessadas. Os principais processos envolvidos com a integrao so: desenvolvimento do termo de abertura (do ingls Project charter); desenvolvimento do plano de projeto; gerenciamento da execuo do projeto; monitoramente e controle do projeto; controle integrado de mudanas e encerramento do projeto ou fase. Detalharemos alguns desses: Desenvolvimento do plano do projeto (planejamento) integrar e coordenar os resultados dos outros processos de planejamento construindo um documento coerente e consistente.
Entradas Outras sadas do planejamento; Informaes histricas; Polticas organizacionais; Restries; Premissas Ferramentas e Tcnicas Metodologia de planejamento de projetos; Habilidades e conhecimentos das partes envolvidas; Sistema de informao para a gesto de projetos; Gesto do valor agregado Plano do projeto; Detalhes de suporte Sadas

Execuo do plano do projeto (execuo) executar o planejamento do projeto por meio da realizao das atividades nele includas.
Entradas Plano do projeto; Detalhes de suporte; Polticas organizacionais, Aes preventivas; Aes corretivas Ferramentas e Tcnicas Habilidades gerais de gesto; Habilidades tcnicas e conhecimento do produto; Sistema de autorizao de trabalho; Reunies de reviso de status; Sistema de informao para gesto de projetos; Procedimentos organizacionais Sadas Resultados do trabalho; Requisies de mudanas

Controle integrado de mudanas (controle) coordenar as mudanas ocorridas em todo o projeto.


Entradas Plano do projeto; Relatrios de desempenho; Requisies de mudanas Ferramentas e Tcnicas Sistema de controle de mudanas; Gerncia de configurao; Medidas de desempenho; Planejamento adicional; Sistema de informao para a gesto de projetos Sadas Atualizaes no plano do projeto; Aes corretivas; Lies aprendidas

53

Fundamentos da Engenharia de Software

3.3.2 Gerncia do Escopo do Projeto


A Gerncia do Escopo do Projeto envolve os processos necessrios para assegurar que o projeto englobe todo o trabalho necessrio, e to somente o trabalho necessrio, para que o projeto seja concludo com sucesso. A preocupao fundamental compreende definir e controlar o que est ou o que no est includo no projeto. No contexto de projeto, o termo escopo se refere a: Escopo do produto aspectos e funes que caracterizam o produto ou servio. Escopo do projeto o trabalho que deve ser feito com a finalidade de entregar um produto de acordo com os aspectos e as funes especificados.

A concluso do escopo do projeto mensurada considerando o plano do projeto, enquanto a concluso do escopo do produto mensurada considerando os requisitos. Ambos os tipos de gerncia de escopo devem ser integrados para garantir que o trabalho do projeto resulte na entrega do produto especificado. Nessa rea de conhecimento encontram-se os processos: coleta de requisitos; definio do escopo; definio da estrutura analtica do projeto; verificao do escopo e controle do escopo. Detalharemos alguns desses processos. Coleta de requisitos (planejamento) Definir e documentar as funes do projeto e do produto necessrias para atender as necessidades e expectativas das partes interessadas.
Entradas Termo de abertura do projeto; Registro das partes interessadas Ferramentas e Tcnicas Entrevistas; Dinmicas de grupo; Questionrios e pesquisas; Oficinas; Prottipos; Observao Sadas Documentao de requisitos; Plano de gerenciamento de requisito; Matriz de rastreabilidade

Definio do escopo (planejamento): subdividir os principais produtos do projeto em componentes menores e mais gerenciveis.
Entradas Documento de requisitos; Restries; Premissas; Sadas de outros planejamentos Ferramentas e Tcnicas Modelos de estrutura analtica de trabalho; Decomposio Sadas Estrutura analtica do projeto (EAP/WBS); Atualizaes na declarao de escopo

Controle de mudanas do escopo (controle): controlar as mudanas de escopo do projeto.


Entradas Estrutura analtica de trabalho; Relatrios de desempenho; Requisies de mudana; Plano de gerncia do escopo Ferramentas e Tcnicas Controle de mudanas do escopo; Medio de desempenho; Planejamento adicional Sadas Mudanas do escopo; Aes corretivas; Lies aprendidas, Linha base ajustada

3.3.3 Gerenciamento do Tempo


Envolve processos como: definio de atividades; definio do sequenciamento das atividades; estimativa de recursos; estimativa da durao das atividades; desenvolvimento

54

Fundamentos da Engenharia de Software do cronograma e controle do cronograma. Detalharemos um pouco mais estimativa da durao das atividades e desenvolvimento do cronograma. Estimativa da durao das atividades (Planejamento) estimar a quantidade de perodos de trabalho que sero necessrios para a concluso de cada atividade.
Entradas Lista de atividades; Restries; Premissas; Recursos requeridos; Competncia dos recursos; Informaes histricas, Riscos identificados Ferramentas e Tcnicas Avaliao especializada; Estimativas por analogia; Duraes baseadas quantitativamente; Tempo reserva (contingncia) Sadas Estimativas de durao das atividades; Bases para a estimativa; Atualizaes da lista de atividades

Desenvolvimento do cronograma (Planejamento) analisar a sequncia e a durao das atividades, alm dos recursos requeridos, para criar o cronograma do projeto.
Entradas Diagrama de rede do projeto; Estimativas de durao das atividades; Recursos requeridos; Descrio do quadro de recursos; Calendrios; Restries; Premissas; Folgas e flutuaes; Plano de gerncia de riscos; Atributos das atividades Ferramentas e Tcnicas Anlise matemtica; Compreenso da durao; Simulao; Nivelamento heurstico dos recursos; Softwares de gesto de projeto; Estrutura de codificao Sadas Cronograma do projeto; Detalhes de suporte; Plano de gerncia do cronograma; Atualizao dos recursos requeridos

3.3.4 Gerenciamento de Custos


Essa rea, fundamentalmente, consiste nos custos dos recursos necessrios implementao das atividades do projeto. Entretanto, a gerncia do custo do projeto deve tambm considerar os efeitos das decises do projeto no custo de utilizao do produto do projeto. Esta viso mais ampla da gerncia do custo do projeto , frequentemente, chamada de custo do ciclo de vida. Seus principais processos so: estimativas de custos, definio de oramento, controle de custos. Detalharemos o primeiro desses processos. Estimativa dos custos (Planejamento): desenvolver a estimativa dos custos dos recursos necessrios implementao das atividades do projeto.
Entradas Estrutura analtica de trabalho; Recursos requeridos; Custos dos recursos; Estimativas da durao das atividades; Divulgao das estimativas; Informaes histricas; Plano de contas; Riscos Ferramentas e Tcnicas Estimativas por analogias; Modelo paramtrico; Estimativas de baixo para cima (bottom-up); Ferramentas computadorizadas; Outros mtodos de estimativas de custo Estimativas de custo; Detalhes de suporte; Plano de gerncia do custo Sadas

3.3.5 Gerenciamento da Qualidade


Dentre os processos dessa rea de conhecimento esto: planejamento da qualidade, execuo da garantia da qualidade e execuo do controle da qualidade.

55

Fundamentos da Engenharia de Software Falaremos planejamento da qualidade. Planejamento da qualidade (Planejamento): identificar quais padres de qualidade so relevantes para o projeto e determinar a forma de satisfaz-los.
Entradas Poltica da qualidade; Declarao do escopo; Descrio do produto; Padres e regulamentaes; Sadas de outros processos Ferramentas e Tcnicas Anlise de custo/benefcio; Comparao de prticas (benchmarking); Fluxograma; Projeto de experimentos; Custo da qualidade Sadas Plano de gerncia da qualidade; Definies operacionais; Listas de verificao; Entradas para outros processos

Controle da qualidade (Controle): monitorar os resultados especficos do projeto para determinar se eles esto de acordo com os padres de qualidade relevantes e identificar as formas para eliminar as causas de desempenhos insatisfatrios.
Entradas Ferramentas e Tcnicas Anlise de custo/benefcio; Resultados do trabalho; Plano de gerncia da qualidade; Definies operacionais; Listas de verificao Comparao de prticas (benchmarking); Fluxograma; Projeto; inspeo; Grficos de controle; Diagrama de Pareto; Amostragem estatstica; Fluxograma; Anlise de tendncia o de experimentos; Custo da qualidade Plano de gerncia da qualidade; Definies operacionais; Listas de verificao de melhoria da qualidade; Decises de aceitao; Re-trabalho; Listas de verificao preenchidas; Ajustes no processo; Entradas para outros processos Sadas

3.3.6 Gerenciamento de Recursos Humanos


Envolve os processos necessrios para possibilitar o uso mais efetivo das pessoas envolvidas com o projeto. Isto inclui todos os interessados pelo projeto patrocinadores, clientes, parceiros, contribuintes individuais e outros. Dentre os processos esto: planejamento do desenvolvimento de recursos humanos, aquisio da equipe, desenvolvimento da equipe e gerenciamento da equipe. Desenvolvimento da equipe (Execuo): desenvolver habilidades individuais e competncias de grupo para aumentar o desempenho do projeto.
Entradas Pessoal do projeto; Plano do projeto; Plano de gerncia de pessoal; Relatrios de desempenho; Retorno externo Ferramentas e Tcnicas Atividades de formao da equipe; Habilidades gerais de gerncia; Sistemas de reconhecimento e recompensa; Arranjo fsico da equipe; Treinamento Sadas Melhorias de desempenho; Entrada para avaliao de desempenho

3.3.7 Gerenciamento de Comunicao


H quatro processos em comunicao, so eles: identificao de stakeholder, planejamento da comunicao, distribuio das informaes, gerenciamento das

56

Fundamentos da Engenharia de Software expectativas do stakeholder e reportagem de desempenho. Vamos entender as entradas, sadas e ferramentas do primeiro desses processos. Identificao das partes interessadas (stakeholder) (planejamento): o processo de identificar todas as pessoas ou organizaes que possam ser afetadas pelo projeto e de documentar as informaes relevantes ao seus interesses, envolvimento e impacto no sucesso do projeto.
Entradas Termo de abertura do projeto, documentos de aquisio, fatores ambientais da empresa, ativos de processos organizacionais Anlise das partes interessadas, opinio de especialistas Ferramentas e Tcnicas Sadas Registro das partes interessadas, estratgia para gerenciamento das partes interessadas.

3.3.8 Gerenciamento de Riscos


composta dos seguintes processos: planejamento do gerenciamento de riscos, identificao dos riscos, anlise quantitativa dos riscos, anlise qualitativa dos riscos, planejamento das respostas aos riscos, monitoramento e controle dos riscos. As entradas, sadas e ferramentas do processo de identificao dos riscos so mostradas a seguir. Identificao dos riscos (planejamento): determinar quais os riscos so mais provveis de afetar o projeto e documentar suas caractersticas.
Entradas Plano de gerncia dos riscos; Sadas do planejamento do projeto; Categorias dos riscos; Informaes histricas Ferramentas e Tcnicas Reviso da documentao; Tcnicas de reunio de informaes; Listas de verificao; Anlise de premissas; Tcnicas de diagramao Sadas Riscos; Eventos potenciais de risco; Entradas para outros processos

3.3.9 Gerenciamento de Aquisies


O gerenciamento de aquisies como j dito envolve os processos necessrios obteno de bens e servios externos organizao executora. Os processos relacionados so: planejamento das aquisies e contrataes, realizao das contrataes, gerenciamento das contrataes e encerramento das contrataes. Encerramento das contrataes (encerramento): completar e liquidar o contrato incluindo a resoluo de qualquer item pendente.
Entradas Documentao do contrato Ferramentas e Tcnicas Auditorias de aquisio Sadas Arquivamento do contrato; Aceitao e fechamento formais

3.4 Certificao PMI


Desde 1984 o PMI tem se dedicado a desenvolver e manter um rigoroso programa

57

Fundamentos da Engenharia de Software de certificao profissional para promover o crescimento da profisso de Gerenciamento de Projetos e reconhecer as realizaes de indivduos no tema. A certificao de Project Management Professional do PMI (PMP) a credencial mais reconhecida mundialmente para indivduos envolvidos com o Gerenciamento de Projetos. Em 1999, o PMI se tornou a primeira organizao no mundo a ter seu Programa de Certificao reconhecido pela ISO 9001. Sendo assim, o PMI conta com dois tipos de certificaes profissionais aceitos e reconhecidos mundialmente. So eles: certificao para o Profissional de Gesto de Projetos (PMP do ingls Project Management Professional) e certificao para o Associado Certificado em Gesto de Projetos (CAPM do ingls Certified Associate in Project Management). A certificao profissional PMP a certificao de maior reconhecimento, a qual indica que o profissional tem slida base de conhecimento em gesto de projetos. Para ser certificado como PMP, o profissional de gesto de projetos deve realizar treinamento especfico, atender requisitos de experincia e concordar em seguir ao cdigo de conduta profissional. Tendo atendido os critrios mencionados, o profissional passa ento por um exame, administrado globalmente, para avaliar e medir seu conhecimento em gesto de projetos. Alm disso, os profissionais certificados como PMP devem demonstrar comprometimento com a gesto de projetos satisfazendo o Programa de Requisitos de Certificao Continuada do PMI. J a certificao profissional CAPM indicada para profissionais que realizam atividades de gesto de projetos, porm so novos na profisso, sendo um passo anterior ao PMP. Os candidatos ao CAPM tambm devem realizar treinamentos especficos e atender requisitos de experincia para ento passarem pelo exame.

Atividades e Orientaes de Estudos


O assunto deste captulo praticamente uma continuao dos captulos anteriores. Dessa forma, permanece vlido todas as orientaes de estudo j fornecida nos captulos anteriores: E no esquea, na dvida, sinta-se vontade em perguntar! Interaja com seus colegas nos fruns e chats, participe! Estamos aqui para auxiliar uns aos outros na construo do saber. Seguem alguns exemplos de atividades respondidas e/ou comentadas que sero encontradas neste captulo. No forneceremos exemplos de atividades de interao, elas so atividades simples e caracterizadas pelas discusses abertas nos fruns.

Aprenda Praticando: Exerccio Proposto 3.1


Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1) Indique V para Verdadeiro e F para Falso: a. ( ) O PMBOK representa um conjunto de padres e boas prticas adotados obrigatoriamente no gerenciamento de projetos. b. ( ) No contexto da ES, de responsabilidade do gerenciamento de escopo juntamente com os processos de iniciao definir os requisitos do sistema.

58

Fundamentos da Engenharia de Software c. ( ) O PMBOK adotado apenas no contexto da ES.

d. ( ) A 4 edio do PMBOK composta de 42 processos ao invs de 44 como era na verso anterior. e. ( ) Os 42 processos definidos pela 4.a edio do PMBOK so agrupados em 5 classes de processos assim definidas: iniciao, planejamento, controle e monitoramento, execuo e encerramento. f. ( ) As reas de conhecimentos definidos pelo PMBOK so: escopo, requisitos, tempo, riscos, integrao, qualidade, custos, aquisio, recursos humanos. ) O PMBOK a base de metodologia do PMBOK.

g. (

h. ( ) O plano de projeto, segundo as prticas do PMBOK, elaborado dentro dos processos de iniciao. i. ( ) No h pr-requisitos para tirar a certificao definida pelo PMI com base no PMBOK, isto , qualquer pessoa pode tirar a certificao desde que estude para tal. ( ) O PMBOK apenas uma das vrias metodologias e/ou padres para o gerenciamento de projetos. ( ) Entrevistas, questionrios, revises, dinmicas de grupo so todas tcnicas adotadas no processo de coleta de requisitos.

j. l.

m. ( ) H dois processos na rea de gerenciamento de riscos responsveis por quantificar os riscos, so eles: anlise qualitativa de riscos e anlise quantitativa de riscos. n. ( ) O cronograma do projeto feito pelos processos de gerenciamento de integrao junto com o plano de projeto. o. ( ) Segundo o PMBOK no necessrio realizar nenhuma atividade de encerramento do projeto, elas so feitas de forma automtica. p. ( ) H dois tipos de certificao definido pelo PMI, so eles: PMP e CAPM.

q. ( ) Um dos principais difusores do gerenciamento de projetos e da profissionalizao do gerente de projetos o Instituto de Gerenciamento de Projetos (PMI - Project Management Institute). r. ( ) O PMBOK formaliza diversos conceitos em gerenciamento de projetos, como a prpria definio de projeto e do seu ciclo de vida, reconhece 5 grupos de processos de gerenciamento de projetos e 10 reas de conhecimento.

s. ( ) Revises e inspees so tcnicas adotadas de controle da qualidade do projeto. 2) Utilizando suas prprias palavras, descreva qual a importncia na adoo de uma metodologia como o PMBOK para o gerenciamento de projetos de software?

Aprenda Pesquisando: Pesquisa Proposta 3.1


A fim de aprofundar um pouco mais seu conhecimento sobre ferramentas case aplicada aos testes, selecionamos alguns tpicos para pesquisa. 1) Pesquise sobre o PMBOK e faa um resumo de duas pginas, descrevendo as

59

Fundamentos da Engenharia de Software mudanas ocorridas entre a 3 e 4 edio deste guia.

Aprenda Interagindo: Exercicio de Interao 3.1


Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o captulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. bom sempre lembrar que ser preciso voc acessar o ambiente para realizar as atividades de interao. No esquea: voc tambm ser avaliado pelas participaes significativas nos fruns de discusso apresentados no ambiente. 1) Comente sobre o trecho de texto descrito a seguir. ...Como profissionais de projetos, no devemos ficar somente na parte tcnica da disciplina. Estabelecer processos, aplicar o PMBOK e fazer bons relatrios s uma pequena parte do sucesso de um projeto. Uma parcela muito grande est na influncia e harmonia que o gerente consegue estabelecer com os stakeholders. Voc concorda com essa afirmao? Explique seu posicionamento a respeito. 2) A afirmao abaixo verdadeira ou falsa? Comente a respeito. Quando o chefe se torna muito amigo dos subordinados, alguns certamente tomaro isso como sinal de que no precisam se esforar tanto, de que podem enrolar o chefe, e de que se eles errarem ou no cumprirem suas metas, o amigo ir defend-los. Para o chefe, a situao mais complicada ainda. Como administrar situaes nas quais voc nota que seu amigo est fazendo corpo mole, ou pior ainda, que ele no ganhar a promoo desejada ou ter que ser demitido?

Saiba Mais
Para conhecer mais profundamente sobre testes de software, voc pode consultar os stios abaixo relacionados. H uma verso antiga traduzida do PMBOK fornecida pelo chapter PMI de Minas Gerais, disponvel gratuitamente na internet. Disponvel em: <http://www.decex. ensino.eb.br/peg/PMBok/PMBok1-Introducao.pdf>. Um guia de recomendaes para a certificao PMP pode ser encontrado no stio a seguir. Disponvel em: <http://pontogp.files.wordpress.com/2007/01/resumopmp2004.
pdf>.

60

Fundamentos da Engenharia de Software

Dica de Cinema
Para complementar o conhecimento que foi exposto neste captulo, voc pode acessar alguns vdeos de aula com cerca de 10 minutos de durao e so disponibilizados livremente na Internet (You Tube). O contedo claro, objetivo e correto. Vale a pena ser visto! Vdeo introdutrio sobre gerenciamento de projetos e PMBOK realizado pelo prof. Hermano Perrelli do CIn-UFPE. Disponvel em: <http://www.youtube.com/ watch?v=bNQJEAJvDRc> Um vdeo mostrando a organizao dos fluxos de processos definidos no PMBOK, 4 Edio Parte I. Disponvel em: <http://www.youtube.com/watch?v=PD7ZRNkTX70> Continuao da aula que mostra a organizao dos fluxos de processos definidos no PMBOK, 4 Edio Parte II. Disponvel em: <http://www.youtube.com/watch?v=YiF4X YdPuEQ&feature=related>

Voc Sabia?
Veja algumas curiosidades atualizadas sobre Gerncia de Projetos. Voc sabia que... Alm do PMI, outras organizaes ao redor do planeta congregam profissionais da rea, organizam metodologias e promovem congressos e simpsios, como o caso da International Project Management Association (IPMA), na Europa, o Australian Institute for Project Management (AIPM), na Austrlia, e o Russian Project Management Association (Sovnet), na Rssia, apenas para citar outros trs exemplos.As metodologias, tcnicas e ferramentas de gerenciamento de projetos desenvolvidas por essas organizaes compilam o conhecimento de dcadas de melhores prticas na conduo de projetos e podem representar uma quebra de paradigma para mudar a freqncia de insucessos nos projetos. Atualmente, existem tambm muitas oportunidades de treinamento nessas metodologias, facilitando o acesso a esse conhecimento e contribuindo para a adoo de prticas mais adequadas. Fonte: Educao Continuada Gesto de Projetos Governamentais (2006).

Vamos Revisar?

Resumo
O PMBOK representa o Corpo de Conhecimento em Gerncia de Projetos mantido pelo PMI. Esse corpo de conhecimento rene as melhores prticas de gerenciamento de projetos. O PMBOK formaliza diversos conceitos em gerenciamento de projetos, como a prpria definio de projeto e do seu ciclo de vida, reconhece 5 grupos de processos de gerenciamento de projetos e 9 reas de conhecimento. Cada rea de conhecimento abrange diversos processos de gerenciamento de projetos. Escopo, Tempo, Custos e Qualidade so os principais focos para o objetivo de um projeto: entregar um resultado de acordo com o escopo, o prazo e o custo definidos, com qualidade adequada. Recursos Humanos e Aquisies so os insumos que movem um projeto. Comunicaes e Riscos so elementos aos quais deve haver sempre ateno e

61

Fundamentos da Engenharia de Software tratamento constantes em um projeto. E Integrao abrange a orquestrao de todos estes aspectos.

62

Fundamentos da Engenharia de Software

Captulo 4 Gerncia de Configurao


Vamos conversar sobre o assunto?
De tudo que vimos at agora sobre ES, h um fato quase que incontestvel: o software um dos produtos que mais sofrem mudanas no decorrer de sua vida til, seja pelas mudanas corretivas, como correes de defeitos ou mudanas evolutivas, como a introduo e remoo de requisitos. Desse cenrio, surgem importantes questes: como controlar essas mudanas no decorrer do tempo? Como saber em que verso um requisito X foi liberado? Ou a partir de que verso o software falhou? Como controlar o cdigo de um mesmo sistema feito por mais de um desenvolvedor concorrentemente? A Gerncia de Configurao e Mudana (GCM) visa apoiar o desenvolvimento auxiliando exatamente nessas questes. Esse ltimo captulo aborda outra rea de conhecimento que auxilia a produo do software de qualidade: a Gerncia de Configurao. Neste captulo chamaremos resumidamente essa rea de GC. Os conceitos associados com a GC so muito prticos. Para melhor perceber a importncia que essa rea de conhecimento para a produo do software, o ideal seria vivenciar a prtica do desenvolvimento. Contudo, nos esforaremos para que os conceitos fundamentais sejam aprendidos. Abordaremos resumidamente os tpicos: O que Gerncia de Configurao Definies bsicas

63

Fundamentos da Engenharia de Software Processo de Gerncia de Configurao Controle de verso e controle de mudana

Ateno
A maioria das modificaes no software justificvel. Assim, no vale a pena nos queixarmos delas. Em vez disso, precisamos nos certificar de que dispomos de mecanismos para cuidar delas. (PRESSMAN, 2006)

4.1 Por que gerenciar a configurao do software?


muito comum para ES que o software sofra mudanas no decorrer de sua vida til (desde o desenvolvimento at a manuteno). Erros so sempre encontrados e corrigidos e a incluso de novos requisitos uma prtica comum. Agora, imagine trabalhar em um ambiente de desenvolvimento de software no qual essas mudanas ou esse desenvolvimento no estejam sendo controladas!? Tambm fato que hoje em dia o desenvolvimento do software cada vez mais complexo e realizado por equipes, algumas vezes at distribudas geograficamente. Ento como controlar esse desenvolvimento? Nesses cenrios, no seria surpresa voc se deparar com problemas como: Ningum saber qual a ltima verso do software. Ela est onde? Com quem? Partes de cdigos corretos sobrescritos por outros e ningum saber quem sobrescreveu o cdigo, ou quando isso foi feito. Enviar a verso errada do software para o Cliente. Ningum saber que verso precisa ser novamente testada. Ningum saber responder a partir de que mudana o software passou a falhar. Etc.

O gerenciamento de configurao representa uma rea de conhecimento de apoio ao desenvolvimento de software que visa auxiliar o controle de configurao e mudana do software. O objetivo dessa rea minimizar problemas como os apresentados acima. Apesar da proposta da rea parecer simples, ela constituda de atividades fundamentais ao apoio do desenvolvimento, muitas vezes complexas, principalmente, devido complexidade e tamanho dos softwares atuais, que so cada vez maiores e mais complexos, com recursos cada vez mais distribudos, e mudanas so cada vez mais frequentes e inevitveis. Alm disso, GC uma rea tambm fundamental para garantir a qualidade do software, por exemplo, GC abordada em diversos modelos de qualidade como o CMMi ou MPS-BR. Infelizmente, pelo menos no Brasil, as prticas de GC passaram a ter importncia reconhecida pelas Empresas h muito pouco tempo. No seria difcil encontrar empresas nacionais que trabalham ainda usando meios no recomendados de controle de verso como: a cada cdigo gerado, cpias do cdigo em um novo diretrio do projeto (em mquina local) so realizadas, ou o cdigo do software est armazenado localmente em uma mquina qualquer, ou algo assim. Tambm importante frisar que o profissional especializado nessa rea ainda bem escasso no Brasil. As formaes especficas ainda so poucas. Vamos entender melhor o que gerncia de configurao (GC).

Voc Sabia?
CMMI uma evoluo do CMM e procura estabelecer um modelo nico para o processo de melhoria corporativa, integrando diferentes modelos e disciplinas. Saiba mais, consulte: <http://www. asrconsultoria.com>.

64

Fundamentos da Engenharia de Software

4.2 O que Gerncia de Configurao?


Da literatura podemos dizer que GC um conjunto de atividades de apoio que permite a absoro controlada das mudanas inerentes ao desenvolvimento de software, mantendo a estabilidade na evoluo do projeto. O que isso significa? Significa, por exemplo, que para liberar a verso 1.0 de um software X, foram executadas diversas atividades que garantem que essa verso constituda do cdigo correto, j revisado, testado e aprovado, como tambm est em integridade com os demais artefatos do produto, como documento de requisitos, por exemplo. Pressman (2006) define que GC uma atividade guarda-chuva, exatamente como a gesto de projetos, pois aplicada ao longo de toda a produo do software. E representa um conjunto de atividades projetadas para gerir modificaes, identificando os produtos de trabalhos que podem ser modificados, estabelecendo relacionamentos entre eles, definindo mecanismos para administrar as diferentes verses desses produtos de trabalho, controlando as modificaes impostas e fazendo auditoria, e preparando relatrios sobre as modificaes efetuadas. Nesse contexto, as atividades de GC focam principalmente em: (1) Identificar as modificaes; (2) Controlar as modificaes; (3) Garantir que as modificaes sejam adequadamente implementadas; e, (4) Relatar as modificaes a outros que possam ter interesse. Apesar de existir pessoal especializado para assumir o papel de gerente ou engenheiro de GC, todos envolvidos na produo do software executam as atividades de GC, seja o desenvolvedor, o testador ou mesmo o gerente de projetos. Isso porque as modificaes do software podem ser feitas em diversos artefatos gerados durante a produo como nos manuais, planos, documento tcnicos, cdigo e etc. Essas modificaes, normalmente, sero realizadas pelo pessoal tcnico especializado e contratado para fazlas. Por exemplo, se for cdigo ser o desenvolvedor, se for relativa aos casos de testes, ser o testador, se algo no plano de projeto, ser o gerente, e assim sucessivamente. No ser papel do engenheiro ou gerente de configurao fazer qualquer modificao nos itens de configurao, exceo apenas aos artefatos que eles sejam realmente responsveis como o plano de gerenciamento de configurao. O papel destes ser definir como essas mudanas sero incorporadas de forma segura, confivel e mantendo integridade com os demais itens de configurao do projeto. Os objetivos do gerente/engenheiro de configurao so garantir que os procedimentos e polticas para criar, modificar e testar o cdigo esto sendo seguidos, bem como tornar acessvel a informao sobre o projeto para todos os interessados. Para implementar tcnicas para manter controle sobre modificaes, esse gerente introduz mecanismos a fim de fazer solicitao oficial de modificaes, para avali-las, e para autorizar as modificaes. O gerente cria e distribui listas de tarefa para os engenheiros e basicamente cria o contexto do projeto. Ele tambm coleta estatsticas sobre componentes do sistema de software, tais como determinao de informao sobre quais componentes do sistema so problemticos.

Fique por Dentro


GC um conjunto de atividades de apoio que permite a absoro controlada das mudanas inerentes ao desenvolvimento de software, mantendo a estabilidade na evoluo do projeto.

4.2.1 Definies Bsicas da GC


Algumas definies bsicas sobre GC so fundamentais para o entendimento do assunto. So elas:

65

Fundamentos da Engenharia de Software Configurao: a sada do processo de desenvolvimento do software que pode ser os programas de computador (cdigo e executvel), os produtos de trabalho (artefatos como documento de requisitos, arquitetura, modelo de projeto) e os dados. Item de configurao: qualquer item que estiver dentro da configurao de software e que seja importante acompanhar as mudanas dele durante o ciclo de produo. Por exemplo: cdigo, documento de arquitetura, documento de requisitos, plano de projeto, plano de GC, etc. Os itens de configurao devem ser identificados unicamente (possuir nome, descrio e responsvel). Referencial: representa uma especificao ou produto que foi formalmente revisto e aprovado, o qual da em diante serve como base para o desenvolvimento futuro e que pode ser modificado apenas por meio de procedimentos formais de controle de modificao (IEEE, 1990). Todo item de configurao em determinado momento ser um referencial. Por exemplo, o documento de projeto quando revisado e aprovado ser um referencial para codificao. Linha de base (do ingls, baseline): uma linha de base normalmente representa um marco no projeto, por exemplo, uma linha de base pode indicar o fim de uma fase de desenvolvimento de software como a fase de requisitos ou codificao. Normalmente, essa linha de base composta por vrios itens de configurao que j se tornaram referencial. Repositrio: como o prprio nome indica, o local lgico em que so armazenados os artefatos produzidos pelo projeto, se no todos, pelo menos aqueles relevantes, por exemplo, cdigo e documentao. Em outras palavras, representa um banco de dados dos itens de configurao do projeto como tambm dos demais. Vamos entender agora um pouco sobre o processo de gerncia de configurao.

Fique por Dentro


Principais atividades de GC: 1) identificar as modificaes 2) controlar as modificaes 3) garantir que as modificacoes sejam adequadamente implementadas 4) relatar as modificacoes aos interessados

Para Refletir...
Voc acha que todo artefato produzido em um projeto de software um item de configurao? Pense sobre isto.

4.3 Processo de Gerncia de Configurao


De acordo com o SWEBOK (2004) e a norma ISO/IEC 12207, basicamente o processo de gerncia de configurao composto pelos passos ilustrados na Figura 4.1.

66

Fundamentos da Engenharia de Software

Figura 4.1 Processo de GC.

Da Figura 4.1 podemos descrever mais detalhadamente as seguintes atividades: 1) Planejar a gerncia de configurao: o resultante desta atividade gera o plano de GC. Esse plano deve conter quais os itens de configurao a acompanhar, que padres e procedimentos sero adotados para controlar as verses, quem sero responsveis pela execuo das atividades, como ser executado o pedido de uma mudana, como ser incorporada essa mudana, qual o planejamento das auditorias, dentre outros pontos importantes em GC. 2) Identificar os itens de configurao: essa atividade faz parte do planejamento, contudo ela de extrema importncia, pois a partir da identificao dos itens a controlar pode-se identificar necessidades especficas em relao ao que controlar e ao como controlar. 3) Controlar a configurao: representa as atividades realizadas para controlar a configurao do software (verses e mudanas). Neste conjunto de atividades estaria a forma como uma solicitao de mudana pode ser requisitada e incorporada ao projeto, por exemplo. 4) Reportar situao: reportar o status das mudanas (que mudanas foram realizadas, quando, por quem, etc). 5) Realizar auditoria de configurao: periodicamente o engenheiro ou gerente de configurao dever auditar o projeto a fim de identificar no conformidades as polticas e prticas de GC. 6) Realizar liberao das entregas (do ingls, release): a cada entrega dos produtos, o engenheiro ou gerente de configurao realiza uma srie de pequenas atividades para liberar a entrega ou para o Cliente ou para uma prxima fase do projeto. Uma das atividades realizadas para esse fim a elaborao das notas de liberao (do ingls, release notes), nesse documento contm informaes do nmero da verso do produto liberado, o que h de novo na verso, e que erros permanecem e o empacotamento dos produtos de trabalho dentro da linha de base. O mais importante em um processo de GC que uma vez definido, ele seja capaz de responder as seguintes questes bsicas identificadas por Pressman (2006): Como a equipe de projeto identifica os elementos discretos de uma configurao

67

Fundamentos da Engenharia de Software

Fique por Dentro


Uma auditoria um exame cuidadoso, sistemtico e independente das atividades desenvolvidas cujo objetivo averiguar se elas esto de acordo com as disposies planejadas e/ou estabelecidas previamente, se foram implementadas com eficcia e se esto adequadas (em conformidade) consecuo dos objetivos.

de software? Como a organizao gera as vrias verses existentes de um programa (e sua documentao) para possibilitar que as modificaes sejam acomodadas eficientemente? Como a organizao controla modificaes antes e depois de o software ser entregue a um cliente? Quem tem responsabilidade pela aprovao e classificao das modificaes? Como podemos garantir que as modificaes foram feitas adequadamente? Qual o mecanismo usado para comunicar a terceiros as modificaes feitas?

Se o processo GC responde de forma eficiente todas essas perguntas, ento certamente h estabelecido um controle seguro e confivel das mudanas de configurao, garantindo a qualidade do software nesse sentido.

4.3.1 Auditoria de GC
Mesmo adotando um processo de GC, ainda poderemos ter problemas no controle das verses e mudanas do software, concorda? Por exemplo, quem vai garantir que todos os procedimentos foram seguidos por toda equipe a todo tempo? O padro de nomenclatura dos arquivos foi obedecido? O padro de codificao est conforme o definido? Etc. Dessa forma, preciso definir um mecanismo que garanta que os procedimentos, polticas e padres de GC adotados foram realmente executados e esto corretos. Um desses mecanismos a reviso tcnica. J estudamos sobre ela neste curso, voc se recorda? A reviso tcnica foca na correo tcnica do item de configurao revisado. Por exemplo, quando o item de configurao cdigo, a reviso buscaria identificar se o cdigo est correto, tem bom desempenho, est bem projetado, etc. Outro ponto a verificar durante essa reviso se os padres de GC esto sendo seguidos: nome do arquivo est correto? Est armazenado no local correto? A nomenclatura das classes, objetos, variveis seguem o padro? Esses itens provavelmente fariam parte de um checklist de verificao das revises. Relembrando que essas revises tcnicas so realizadas por qualquer membro da equipe envolvida ou com bom conhecimento sobre o item de configurao a revisar. A outra forma de garantir o uso correto dos padres de GC adotando atividades peridicas de auditorias sobre os itens de configurao. Uma auditoria um exame cuidadoso, sistemtico e independente das atividades desenvolvidas em determinada empresa ou setor, cujo objetivo averiguar se elas esto de acordo com as disposies planejadas e/ou estabelecidas previamente, se foram implementadas com eficcia e se esto adequadas (em conformidade) consecuo dos objetivos (Wikipedia auditoria). No caso de GC, seria averiguar se os padres, polticas e procedimentos foram seguidos e esto corretos. Em caso negativo, verificar o porqu dessa no conformidade. uma atividade mais ampla.

Lembrete
A reviso tcnica foca na correo tcnica do item de configurao revisado.

Os resultados das auditorias so sempre formalizados atravs de relatrios indicando as conformidades e no conformidades encontradas. Alguns desses pontos devero ser corrigidos antes do item de configurao se tornar um referencial e outros podero passar a ser escopo de uma melhoria de processo. Por exemplo, em uma auditoria como essa se pode identificar que a ferramenta de controle de verso inadequada ou no atende ao projeto. O responsvel por essa atividade so normalmente engenheiros de configurao ou mesmo o gerente de configurao. E a periodicidade e o item de configurao a ser auditado, so definidos conforme o planejamento e restries do projeto.

68

Fundamentos da Engenharia de Software

4.4 Ferramentas de Suporte ao GC


H diversas ferramentas no mercado que do suporte s atividades de GC. Basicamente essas ferramentas trabalham sob duas perspectivas: no suporte ao controle de verso e/ou no suporte ao controle de mudanas. O controle de verso combina procedimentos e ferramentas para gerir as diferentes verses de item de configurao, que so criadas durante o processo de software. Por exemplo, controle das verses 1.0, 2.0, 2.1 do documento de requisitos. Um sistema que d suporte ao controle de verso deve apresentar capacidades de criar e organizar o repositrio do projeto, de administrar e guardar todas as verses estabelecidas pelos itens de configurao (inclusive, com o histrico dessas verses), e de possibilitar para o desenvolvedor criar coletar todos os itens de configurao relevantes e construir uma verso especifica do software. O CVS (Concurrent Version System) e o SVN (Subversion) so exemplos gratuitos de sistemas como esse. Normalmente esses sistemas trabalham com uma arquitetura cliente-servidor, em que no servidor armazenado o repositrio central do projeto e todos os histricos das verses dos itens de configurao, sejam eles cdigos ou documentos (Figura 4.2). Cada membro da equipe tem uma cpia local desse repositrio, onde ele pode trabalhar livremente. Quando alguma alterao feita na cpia local, o membro da equipe pode refletir essa atualizao no repositrio central (chamados em muitos casos de ao commit). E os demais membros para enxergar essa atualizao precisaro atualizar sua cpia local (ao update). Para saber mais sobre controle de verso consulte as leituras recomendadas sobre o assunto !

Figura 4.2 Arquitetura de um sistema de controle de verso

Em termos de controle de mudana, o sistema deve possibilitar o controle sistemtico da mudana. Normalmente, esse controle est associado com um conjunto de procedimentos, como por exemplo, a definio dos passos executados para incorporar uma mudana no projeto de forma segura. O foco desse tipo de ferramenta nos procedimentos pelos quais as mudanas de um ou mais itens de configurao so propostas, avaliadas, aceitas e aplicadas. Oferece servios para identificar, rastrear, analisar e controlar as mudanas nos itens de configurao. Alguns exemplos de ferramentas de controle de mudana so: Mantis, Bugzilla e Trac. Na Figura 4.3 h descrito brevemente um fluxo de atividades para realizar uma mudana no projeto. Entenda nessa figura que especialista pode ser qualquer pessoa da equipe de projeto que tenha conhecimento suficiente para avaliar que a mudana solicitada

69

Fundamentos da Engenharia de Software pertinente para o projeto, pode ser um desenvolvedor, um testador, um analista, etc. Entenda como autoridade uma pessoa ou conjunto de pessoas que avaliem o impacto da mudana solicitada no projeto, em termos de custos, prazos, complexidade, relevncia e integridade.

Figura 4.3 Controle de mundanas.

Ainda como apoio a GC h outras ferramentas para suportar a integrao entre os itens de configurao. Por exemplo, essas ferramentas apiam a atividade de empacotar os produtos de trabalho (itens de configurao) para liberao. Alguns exemplos desse tipo de ferramenta o Ant e o Gump. No Quadro 4.1 h alguns exemplares de ferramentas de apoio ao GC.
Quadro 4.1 Algumas ferramentas de controle de verso e mudana Tipo de ferramenta Gratuitas CVS Controle de verso Subversion Arch Bugzilla Controle de mudanas Mantis Trac Comerciais Clearcase Starteam

Clearquest FogBugz

Bem, enfim a GC essencial para manter o desenvolvimento de software controlvel e ntegro. Contudo, ainda grande o nmero de empresas que ainda no utilizam nenhum tipo de GC ou que utilizam apenas o controle de verso nos seus projetos. As causas para essa situao so o desconhecimento da amplitude e importncia da GC e o

70

Fundamentos da Engenharia de Software desconhecimento das ferramentas de apoio existentes.

Atividades e Orientaes de Estudos


O assunto deste captulo praticamente uma continuao dos captulos anteriores. Dessa forma, permanecem vlidas todas as orientaes de estudo j fornecida nos captulos anteriores: E no esquea, na dvida, sinta-se vontade em perguntar! Interaja com seus colegas nos fruns e chats, participe! Estamos aqui para auxiliar uns aos outros na construo do saber. Seguem alguns exemplos de atividades respondidas e/ou comentadas que sero encontradas neste captulo. No forneceremos exemplos de atividades de interao, elas so atividades simples e caracterizadas pelas discusses abertas nos fruns.

Aprenda Praticando: Exerccio Proposto 4.1


Tomando com base o que foi explicado no captulo, responda as questes abaixo, justificando suas respostas quando apropriado. 1) O que GC? 2) Descreva com suas palavras qual a importncia de definir polticas e procedimentos para a GC em um projeto de software? 3) Cite pelo menos quatro diferentes problemas que podem acontecer durante a produo de software quando no se adota polticas e procedimentos de GC. 4) Cite algumas razes para se estabelecer referenciais em um projeto (PRESSMAN, 2006). 5) Considere que voc um gerente de um pequeno projeto. Que tipo de referenciais voc definiria para o projeto e como iria control-los? (PRESSMAN, 2006) 6) Indique V para Verdadeiro e F para Falso: a. ( ) GC uma rea de apoio ao desenvolvimento que atua apenas no incio e ao fim do projeto de software. b. ( ) Todos os envolvidos com a produo do software so tambm responsveis por alguma atividade GC. c. ( ) O SVN uma evoluo do CVS e representa uma das ferramentas de controle verso gratuita mais utilizadas na atualidade. d. ( ) GC tambm faz parte do conjunto de atividades responsveis pela garantia da qualidade do software. e. ( ) Todos os artefatos produzidos dentro do processo de desenvolvimento do software so considerados itens de configurao. f. ( ) Quando o documento de requisito alterado em funo de uma requisio formal de mudana aprovada, provvel que seja necessrio requisitar mudanas em outros documentos com os quais o documento de requisito mantm relacionamentos como o modelo de projeto e os casos de testes.

71

Fundamentos da Engenharia de Software g. (.... ) O Bugzilla uma aplicao para gesto de mudanas. Esta aplicao permite que indivduos ou grupos de programadores acompanhem os relatrios de erros ou pedidos de melhoramentos. h. ( ) Devido a urgncia em se atender aos clientes e usurios do projeto, as mudanas solicitadas so imediatamente realizadas sem necessitar de qualquer avaliao prvia. i. ( ) A auditoria um mecanismo adotado para punir as pessoas que no seguiram os procedimentos e padres de GC definidos para o projeto e organizao. ( ) A gesto de configurao uma atividade guarda chuva aplicada ao longo de todo o processo de software.

j.

7) Descreva com suas palavras em que consiste o controle de verso. 8) Descreva com suas palavras em que consiste o controle de mudana?

Aprenda Pesquisando: Pesquisa Proposta 4.1


A fim de aprofundar um pouco mais seu conhecimento sobre ferramentas case aplicada a GC, selecionamos um tpico para pesquisa. 1) Tendo como base o exposto neste captulo, pesquise uma das dezenas de ferramentas de controle de verso existente no mercado e responda as questes abaixo. a. Como a ferramenta implementa o controle de verso? b. Como a ferramenta seria utilizada para que dois desenvolvedores distintos pudessem fazer alteraes concorrentes em um mesmo item de configurao? c. A ferramenta tem integrao com alguma ferramenta de controle de mudana? Que vantagens isso traria?

Aprenda Interagindo: Exercicio de Interao 4.1


Utilizando os fruns do curso, realize as atividades de interao propostas a seguir. Sugerimos que seja criado um frum especifico para o captulo, dessa forma, torna-se fcil a indexao das discusses no curso para consulta e anlise posterior. bom sempre lembrar que ser preciso voc acessar o ambiente para realizar as atividades de interao. No esquea: voc tambm ser avaliado pelas participaes significativas nos fruns de discusso apresentados no ambiente. 1) Supondo que voc seja recrutado para ser um gerente de configurao de um pequeno projeto software, o que voc definiria como no sendo um item de configurao? 2) Com base no texto de James Bach (1998), comente com seus amigos a importncia do controle de mudanas.

72

O controle de mudanas vital, mas as foras que o tornam necessrio tambm

Fundamentos da Engenharia de Software o tornam desagradvel. Preocupamo-nos com a mudana porque uma pequena perturbao no cdigo pode criar uma grande falha no produto. Mas ela tambm pode reparar uma falha grande ou proporcionar magnficas capacidades novas. Preocupamo-nos com as mudanas porque um nico desenvolvedor preguioso pode afundar o projeto; no entanto, ideias brilhantes originam-se nas mentes desses preguiosos e um processo de controle de mudanas complicado pode efetivamente desencoraj-los a fazer trabalho criativo.

Saiba Mais
Para conhecer mais profundamente sobre GCM, consulte os stios abaixo relacionados. Um modelo de um plano de GCM. Disponvel em: <http://www.cin.ufpe.br/~gfn/ qualidade/templates/plano_de_gerencia_de_configuracao.htm> Recomendamos a leitura do captulo 27 do livro de (PRESSMAN, 2006). Tutorial sobre gerenciamento de configurao do software. Disponvel em: <http://www.pronus.eng.br/artigos_tutoriais/gerencia_configuracao/gerencia_ configuracao.php?pagNum=1> Tutorial sobre controle de verso. Disponvel em: <http://www.pronus.eng.br/ artigos_tutoriais/gerencia_configuracao/conceitos_basicos_controle_versao_ centralizado_e_distribuido.php> Para complementar o conhecimento sobre controle de verso consulte tambm o sitio da Wikipedia. Disponvel em: <http://pt.wikipedia.org/wiki/Sistema_de_ controle_de_vers%C3%A3o>

Voc Sabia?
Veja algumas curiosidades atualizadas sobre Gerncia de Configurao. Voc sabia que... A finalidade da poltica de GC consiste em definir a maneira como as atividades sero executadas, o momento adequado, os responsveis em execut-las e os conceitos envolvidos no processo GC. Entre as definies que devem contar nas polticas de Gerncia de configurao de software podemos citar: Ferramentas para automatizao do controle de revises (Sistema de controle de verso) Ferramentas para o controle de mudanas Nvel de integrao entre as ferramentas caso sejam ferramentas distintas Periodicidade e granularidade do controle de revises

Papeis a serem desempenhados pelos membros da equipe dentro do contexto de Gerncia de Configurao de Software. Frequncia e forma de realizao das auditorias de configurao. Fonte: Wikipedia (Gerncia de Configurao de Software).

73

Fundamentos da Engenharia de Software

Vamos Revisar?

Resumo
GC de software uma atividade guarda chuva aplicada ao longo de todo o processo de desenvolvimento de software. Essa rea identifica, controla, audita e relata as modificaes que invariavelmente ocorrem enquanto o software est sendo desenvolvido e depois de ele ter sido entregue ao cliente. A configurao de software composta de um conjunto de objetos interrelacionados tambm chamados de itens de configurao de software que so produzidos como resultados de alguma atividade de Engenharia de Software.

74

Fundamentos da Engenharia de Software

Consideraes Finais
Ol, Cursista! Esperamos que voc tenha aproveitado esta terceira unidade da disciplina FES. No fique triste, estamos acabando o curso, mas ainda temos uma ltima unidade a estudar, que bom no ?! Iremos permanecer juntinhos ainda mais um pouco... Na ltima unidade estudaremos a raiz de todo incio de produo de um software. Estudaremos os aspectos de qualidade associado a ele, tanto no que diz respeito ao processo de produo, como tambm, ao produto. Voc ver que a qualidade a raiz e o objetivo maior para transformar o desenvolvimento de software em Engenharia.
Estratgia a arte ou cincia de saber identificar e empregar meios disponveis para atingir determinados fins, apesar de a eles se oporem obstculos e/ou antagonismos conhecidos (Sun Tzu)

At l e bons estudos!

75

Fundamentos da Engenharia de Software

Referncias
BASILI, V.; CALDIERA, G.; ROMBACH, H. The Goal Question Metric Approach. Encyclopedia of Software Engineering. Volume 1, John Wiley & Sons, Inc., 2. ed., 2002, pp. 578-583. BEZERRA, E. Princpios de Anlise e Projeto de Sistemas com UML. [S.l]:Campus, 2002. BUDGEN, D. Software Design. 2nd Edition, Addison Wesley, 2003 CORLISS. Walkthroughs. UM COSC 198 Software Testing. Summer, 2001. Online. Atualizado em 2001. Disponvel no endereo: http://www.eng.um.edu/ corlissg/198.2001/walkthrough.html IEEE Computer Society (online). Disponivel em: <http://www.computer.org/portal/ web/guest/home> LISLE, L.; Dong, J.; Isensee, S. Case study of developmente of and ease of use web site. Proceedings of human factors & the web conferences, 1998. Online. Data de atualizao no fornecida. Disponvel no endereo: <http://www.research.att.com/ conf/hfweb/proceedings/lisle/> MYERS, Glen. The art of software testing. New York : J. Wiley, 1979 OSLON, T. How to improve your software inspection process. SEPG 99 Conference. Online. Atualizado em 1999. Disponvel no endereo: <http://www.sercenter.com/ KP/qa/SQAtutorial.pdf> PRESSMAN, R.S. Engenharia de Software. 6 edio, [S.l]:McGraw-Hill, 2006. PMI, PMBOK Guide Um Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos. Terceira edio 2004, ISBN 1-930699-74-3 SEI: Software Engineering Institute (online). Disponivel em: <http://www.sei.cmu. edu/> SEI-CMM-3-1.5. The software review process. Online. Data de atualizao no disponvel. Disponvel no endereo: <http://www2.umassd.edu/SWPI/ curriculummodule/cm3.pdf> SOMMERVILLE, I. Engenharia de Software. 6 edio, [S.l]:Pearson, 2007. SOMERVILLE, I. e KOTONYA, G., Requirements Engineering: Processes and Techniques, John Wiley & Sons, (1997). SOARES, A. L.. Introduo, Identificao e Anlise em Engenharia de Requisitos. Antnio Lucas Soares. 2005. SMITH, G. F.; BROWNE, G. J.. Conceptual Foundations of Design Problem Solving. Systems, Man and Cybernetics, IEEE Transactions on, 23(5), 12091219, 1993. TAYLOR, R. N.; VAN DER HOEK, A. Software Design and Architecture The Once and Future Focus of Software Engineering. In FOSE 07: 2007 Future of Software Engineering. (p. 226243). Washington, DC, USA: IEEE Computer Society, 2007. THAYER, T; DORFMAN, M. Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993. YOURDON, E. Walkthroughs and inspections. Modern Structured Analysis, 2nd edition, chapter 1. Online. Atualizado em 2000. Disponvel no endereo: <http://

76

Fundamentos da Engenharia de Software www.yourdon.com/books/msa2e/APPd/APPd.html>

77

Fundamentos da Engenharia de Software

Conhea a Autora
Danielle Rousy Dias da Silva
Graduada em Cincias da Computao pela Universidade Federal da Paraba/UFPB (1998), com mestrado em Computao Inteligente, especialidade Inteligncia Artificial aplicada a Jogos Digitais, pela Universidade Federal de Pernambuco/UFPE (2000). Recm doutora tambm pela UFPE tendo como tema principal de pesquisa o uso de Atores Sintticos em Jogos de Treinamento para Adultos. Desde 2006, atua, sobretudo, como Engenheira de Qualidade na pesquisa e definio de processos de desenvolvimento de jogos mveis. J atuou exercendo diversos papis, entre eles o de Engenheira de Software na Meantime Mobile Creations e tambm no C.E.S.A.R (Centro de Estudos e Sistemas Avanados do Recife). Atualmente, trabalha em EAD como professora executora e conteudista e atua como Gerente de Projetos no desenvolvimento de jogos srios.

78