TCC Ari Barreto de Oliveira

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA
DO RIO GRANDE DO NORTE

ARI BARRETO DE OLIVEIRA

EXTENSO DO PROCESSO ACADMICO SIMPLIFICADO PAS: UMA
PROPOSTA PARA APLICAO DE DIFERENTES TIPOS DE GERNCIA

NATAL-RN
2011


Trabalho de Concluso de Curso apresentado ao
Curso Superior de Tecnologia em Anlise e
Desenvolvimento de Sistemas do Instituto Federal de
Educao, Cincia e Tecnologia do Rio Grande do
Norte, em cumprimento s exigncias legais como
requisito parcial obteno do ttulo de Tecnlogo em
Anlise e Desenvolvimento de Sistemas.

Orientador: Plcido Antnio de Souza Neto, MSc.

NATAL-RN
2011

Diviso de Servios Tcnicos.
Catalogao da publicao na fonte.
IFRN / Biblioteca Sebastio Fernandes

O48e Oliveira, Ari Barrero de.
Extenso do processo acadmico simplicado - PAS : uma
proposta para aplicao diferentes tipos de gerncia / Ari Barreto de
Oliveira. 2011.
xx f.
Orientador: M.e Plcido Antnio de Souza Neto.
Trabalho de Concluso de Curso (Graduao em Tecnologia em
Anlise e Desenvolvimento de Software) Instituto Federal de
Educao, Cincia e Tecnologia do Rio Grande do Norte, 2011.
1. Desenvolvimento Software. 2. Gerenciamento de software. 3.
Processo Acadmico Simplicado - PAS. I. Ttulo.
.
CDU 004.4


Trabalho de Concluso de Curso apresentado ao
Curso Superior de Tecnologia em Anlise e
Desenvolvimento de Sistemas do Instituto Federal
de Educao, Cincia e Tecnologia do Rio Grande
do Norte, em cumprimento das exigncias legais
como requisito parcial para obteno do ttulo de
Tecnlogo em Anlise e Desenvolvimento de
Sistemas.

Aprovado em ______ de _______________ de 2011

Apresentado comisso examinadora integrada pelos seguintes membros:

__________________________________________________________________
Plcido Antnio de Souza Neto, MSc.
Orientador IFRN
__________________________________________________________________
Leonardo Reis Lucena, MSc.
Membro Examinador IFRN
__________________________________________________________________
Marilia Aranha Freire, MSc.
Membro Examinador IFRN

comunidade do IFRN que atua no to complexo
mundo da tecnologia de desenvolvimento de
sistemas.

AGRADECIMENTOS

Primeiramente agradeo a Deus pelo dom da vida, pela oportunidade que Ele
me deu de estar neste Instituto me capacitando a cada dia. A Ele toda glria pelos
mritos obtidos.
Agradeo aos meus pais, Arimats e Edileuza, que tanto me motivaram,
incentivaram e investiram em mim por mais de 25 anos, sem nunca obter nenhum
retorno financeiro com isto. Ao meu pai, administrador de sucesso, pelo seu auxlio,
experincia e exemplo como homem e profissional. E minha me, pois com seu
enorme amor e compreenso sempre me ajuda em todos os momentos, nos
mnimos detalhes. A eles a minha gratido pelo exemplo cristo que me influencia a
cada dia.
Minha gratido minha amada Mikaely, que tem estado sempre ao meu lado,
me ajudando e me apoiando em todos os momentos bons e ruins. Agradeo
tambm minha famlia, por todos os anos de ajuda e compreenso, buscando meu
crescimento pessoal e profissional.
Aos meus amigos, que tambm direta ou indiretamente me ajudaram no
prosseguir da caminhada acadmica.
Por fim, agradeo ao meu orientador, o professor Plcido Neto, pela
dedicao em me ajudar, e o esforo para que eu conclusse este trabalho.

RESUMO

O Processo Acadmico Simplificado (PAS) um modelo de processo de
desenvolvimento de software criado com objetivo de ser uma ferramenta simples e
desburocratizada para a comunidade acadmica. Este trabalho prope uma
extenso do PAS para diferentes tipos de gerncia, trazendo melhorias ao processo.
Para chegar a tal, se usou como base os conhecimentos do Project Management
Body of Knowledge (PMBOK) e do Rational Unified Process (RUP). Aps estudar o
funcionamento do PAS, e das reas de gerenciamento de projetos, foi possvel
estabelecer cinco gerncias importantes para a melhoria do PAS. Como produto
deste trabalho, foi criada uma verso estendida do PAS com as novas gerncias.
Palavras-chave: Processo de Desenvolvimento de Software. Gerenciamento de
Processo de Software. Processo Acadmico Simplificado. Eclipse Process
Framework.

ABSTRACT

The Academic Simplified Process - PAS is a model of software development
process created to be a simple and easy to use academic tool. This work proposes
an extension that the PAS that new introduces process management, areas
improving the process. To achieve our goal, we use the Project Management Body of
Knowledge - PMBOK and the Rational Unified Process - RUP. After studying the
operation of PAS, and the areas of project management, was possible to enlace the
PAS with five new management areas. As a result of this work, we created an
extended version of the PAS with the new management areas.
Key-words: Software Development Process. Software Process Management.
Simplified Academic Process. Eclipse Process Framework.

LISTA DE SIGLAS

CMMI Capability Maturity Model Integration
EPF Eclipse Process Framework
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
IFRN Instituto Federal de Educao, Cincia e Tecnologia do
Rio Grande do Norte
ISO International Organization for Standardization
ITIL Information Technology Infrastructure Library
MPS.BR Melhoria de Processos de Software Brasileiro
OMG Object Management Group
PAS Processo Acadmico Simplificado
PMBOK Project Management Body of Knowledge
PMI Project Management Institut
RH Recursos Humanos
RUP Rational Unified Process
SPEM Software Process Engineering Metamodel
TADS Tecnologia em Anlise e Desenvolvimento de Sistemas
TCC Trabalho de Concluso de Curso
UP Unified Process
XP eXtreme Programming

SUMRIO

1 INTRODUO 12
1.1 OBJETIVO GERAL 14
1.2 OBJETIVOS ESPECFICOS 14
1.3 MOTIVAO 14
1.4 METODOLOGIA 15
2 PROCESSOS DE SOFTWARE (PAS) 16
2.1 PAS - PROCESSO ACADMICO SIMPLIFICADO 16
2.1.1 Fases do PAS 18
2.1.1.1 Fase de concepo 19
2.1.1.1.1 Requisitos 19
2.1.1.1.2 Anlise e projeto 20
2.1.1.1.3 Implementao e testes 20
2.1.1.1.4 Gerncia de processo 20
2.1.1.2 Fase de elaborao 20
2.1.1.3 Fase de construo 22
2.1.1.4 Fase de validao 23
2.2 EPF - ECLIPSE PROCESS FRAMEWORK 24
2.3 PROCESSO DE SOFTWARE: TIPOS DE GERNCIA DE PROJETO 27
2.2.1 Gerncia de ambiente 29
2.3.2 Gerncia de configurao 29

2.3.3 Gerncia de qualidade 29
2.3.4 Gerncia de recursos humanos 30
2.3.1 Gerncia de risco 30
3 EXTENSO DO PAS PARA ATIVIDADES DE GERNCIA 31
3.1 ATIVIDADES DE GERNCIA PARA O PAS 31
3.1.1 Gerncia de ambiente 33
3.1.1.1 Preparar ambiente do projeto 34
3.1.1.2 Preparar ambiente para iterao 34
3.1.1.3 Preparar diretrizes para iterao 35
3.1.1.4 Suportar ambiente durante iterao 35
3.1.2 Gerncia de configurao 37
3.1.2.1 Planejar controle de configurao e mudanas 37
3.1.2.2 Preparar ambiente de gerenciamento de mudanas 38
3.1.2.3 Mudar e disponibilizar itens 38
3.1.2.4 Gerenciar verses 38
3.1.2.5 Monitorar e reportar status 39
3.1.2.6 Gerenciar pedidos de mudanas 39
3.1.3 Gerncia de qualidade 41
3.1.3.1 Desenvolver planejamento de qualidade 41
3.1.3.2 Realizar garantia da qualidade 41
3.1.3.3 Realizar controle da qualidade 42
3.1.4 Gerncia de recursos humanos 43
3.1.4.1 Desenvolver planejamento de recursos humanos 43
3.1.4.2 Contratar ou mobilizar equipe 44
3.1.4.3 Desenvolver equipe de projeto 44
3.1.4.4 Gerenciar equipe de projeto 44
3.1.5 Gerncia de risco 46
3.1.5.1 Planejar gerncia de risco 46
3.1.5.2 Identificao de riscos 47
3.1.5.3 Realizar a anlise qualitativa de riscos 47
3.1.5.4 Realizar a anlise quantitativa de riscos 47
3.1.5.5 Planejar resposta aos riscos 48
3.1.5.6 Monitorar e controlar riscos 48

3.1.6 Modelos de artefatos gerados 50
3.1.6.1 Modelo de documento de ambiente 51
3.1.6.2 Modelo de plano de gerncia de configurao 51
3.1.6.3 Modelo de plano de gerncia de qualidade 52
3.1.6.4 Modelo de plano de gerncia de recursos humanos 52
3.1.6.5 Modelo de plano de gerncia de risco 53
4 CONSIDERAES FINAIS 54
5 TRABALHOS FUTUROS 55
REFERNCIAS 61
APENDICE A Modelo de plano de gerncia de qualidade 58
APENDICE B Modelo de plano de gerncia de risco 63
APENDICE C Modelo de plano de gerncia de recursos humanos 65
APENDICE D Modelo de plano de gerncia de configurao 68

ILUSTRAES

Figura 1 - Diagrama de fases do PAS 17
Figura 2 - Diagrama das fases do PAS 18
Figura 3 - Diagrama de fluxo das disciplinas das fases do PAS 19
Figura 4 - Estruturas bsicas do EPF 26
Figura 5 - Estrutura de publicao HTML de um processo pelo EPF Composer. 27
Figura 6 - Relacionamentos do papel do gerente de projetos do PAS 28
Figura 7 - Papel do stakeholder e sua tarefa, segundo o PAS 28
Figura 8 - Papeis do PAS, com destaque para os papeis de gerncia 32
Figura 9 - Estrutura original de pacotes de contedo do PAS no EPF Composer 33
Figura 10 - Nova estrutura de pacotes de contedo do PAS no EPF Composer 33
Figura 11 - Diagrama de atividades da gerncia de ambiente, na fase de concepo
do PAS no EPF Composer 36
Figura 12 - Estrutura da gerncia de ambiente do PAS no EPF Composer 36
Figura 13 - Diagrama de atividades da gerncia de configurao na fase de
concepo do PAS no EPF Composer 40
Figura 14 - Estrutura da gerncia de configurao do PAS no EPF Composer 40
Figura 15 - Diagrama de atividades da gerncia de qualidade, na fase de concepo
do PAS no EPF Composer 42
Figura 16 - Estrutura da gerncia de qualidade do PAS no EPF Composer 43
Figura 17 - Diagrama de atividades da gerncia de recursos humanos, na fase de
concepo do PAS no EPF Composer 45
Figura 18 - Estrutura da gerncia de recursos humanos do PAS no EPF 45
Figura 19 - Diagrama de atividades da gerncia de risco na fase de concepo do
PAS no EPF Composer 49
Figura 20 - Estrutura da gerncia de risco do PAS no EPF Composer 49
Figura 21 - Produtos de trabalho descritos pelo PAS no EPF Composer, com
destaque para os novos documentos criados ou estendidos durante este TCC 50

12
1 INTRODUO

O desenvolvimento de Software uma atividade que a cada dia se torna mais
complexa e competitiva, exigindo dos desenvolvedores um maior empenho para
obter produtos de maior qualidade, respeitando os prazos, custos e definies do
planejamento. Com o crescimento do mercado de software, os clientes esto cada
dia mais exigentes e, assim os projetos se tornam mais complexos, com mais
requisitos, muitas vezes com at menos recursos e a tolerncia destes clientes a
atrasos tambm reduzida. Com estes fatores, as chances de um fracasso no
desenvolvimento de software tornam-se maiores a cada dia.
Existem vrios motivos comuns que causam problemas para os
desenvolvedores de software. Alguns deles so as dificuldades de estabelecer uma
metodologia de desenvolvimento de software, de registrar corretamente os requisitos
do software, a complexidade para controlar verses e manuteno do software, a
no utilizao de um processo eficaz de desenvolvimento, e ainda a dificuldade para
efetuar manuteno em softwares mal documentados.
Diante de tais necessidades, novas ferramentas, processos e tecnologias
so criadas a cada dia para dar suporte ao desenvolvedor de software. O uso destas
ferramentas traz grandes benefcios para a empresa e/ou organizao que as utiliza,
contribuindo para o aumento da qualidade do produto e diminuindo os esforos para
produzi-lo e mant-lo.
Dentre estes novos artefatos criados, os processos de desenvolvimento de
software se apresentam como importante fator motivador de qualidade de um
software. Sommerville (2007) descreve processo de software como um conjunto de
atividades que leva produo de um produto de software.
Segundo Pressman (2002), a no utilizao de mtodos, ferramentas e
procedimentos para o desenvolvimento so a causa de existir tantos projetos
abandonados e projetos concludos que no atendem a necessidade do cliente.
Quanto ao processo utilizado, so muitas as opes disponveis. No entanto
importante que seja empregado o modelo ideal para cada situao levando-se em
considerao o tipo de equipe, projeto e as regras da empresa desenvolvedora.
A metodologia do Rational Unified Process (RUP) hoje uma das mais
aplicadas para o desenvolvimento de software, tendo como objetivo aumentar as
chances de concluso de um projeto. Outras metodologias, como a do PMI (Project
13
Management Institute) que enfoca o processo de gerenciamento, tambm tm

crescido, o que mostra que os desenvolvedores tem amadurecido e buscado um
maior planejamento, gerenciamento e controle dos seus projetos.
Os alunos do Instituto Federal de Educao, Cincia e Tecnologia do Rio
Grande do Norte (IFRN), desejando facilitar a introduo de novos alunos do curso
superior de Tecnologia em Anlise e Desenvolvimento de Sistemas (TADS) no
contexto dos processos de desenvolvimento de software, criaram em 2006 o
Processo Acadmico Simplificado (PAS). A grande vantagem do PAS em relao a
outros processos oferecer ao aluno um processo gratuito, rpido e resumido, que
facilita o desenvolvimento de aplicativos durante o curso. Este processo foi
publicado em 2008 publicado como uma pgina HTML atravs do Eclipse Process
Framework (EPF), facilitando assim sua consulta pblica (COELHO, 2009).
Devido a seu escopo inicial, atualmente o PAS no suporta algumas reas da
Engenharia de Software e Gerncia de Projetos. Muitas destas reas esto
presentes e detalhadas em outros modelos de processo de Software, como o RUP
ou o guia Project Management Body of Knowledge (PMBOK) do Project
Management Institut (PMI). Algumas destas, se criadas em um projeto, poderiam
trazer grandes benefcios aos desenvolvedores, ao processo e ao produto gerado.
Ao elencar algumas destas reas possvel destacar:

a) Gerncia de Ambiente: trata da especificao, instalao, monitoramento e
suporte de ferramentas utilizadas durante o desenvolvimento;
b) Gerncia de Configurao: diz respeito ao controle das mudanas ocorridas no
projeto durante o desenvolvimento, evitando que estas mudanas mudem o
escopo do projeto, ou causem prejuzo a este;
c) Gerncia de Qualidade: busca avaliar o sucesso de iteraes e a qualidade das
tarefas executadas durante a produo do software;
d) Gerncia de Recursos Humanos: trata das pessoas pertencentes equipe e s
incidncias que possam surgir durante o projeto;
e) Gerncia de Risco: a rea responsvel pela identificao e classificao de
riscos e planejamento do projeto para lidar com os mesmos.
Desta forma, foi observado que seria interessante a criao de uma extenso
que trouxesse novas reas de conhecimento da gerncia de projetos ao PAS. Os
professores e o prprio PAS necessitam ao mesmo tempo ensinar aos
14
alunos de forma simples e direta, e ainda assim apresentar a estes metodologias

modernas sempre, preparando-os para enfrentar o mundo do trabalho que se
torna mais competitivo e especializado.
Assim, este trabalho prope a extenso do PAS para atingir algumas destas
reas ainda no exploradas, oferecendo, atravs de gerncias, bases para que o
sucesso em determinadas reas da engenharia de software seja alcanado, sempre
que necessrio. Isto aumentar a eficincia do modelo do PAS.

1.1 OBJETIVO GERAL

Propor uma melhoria na estrutura do PAS, adicionando a este novas
Gerncias que envolvam diferentes reas do conhecimento.

1.2 OBJETIVOS ESPECFICOS

Conhecer o PAS e as suas especificaes;
Estudar sobre as gerncias de projeto de software;
Propor a agregao de novas gerncias, alm da gerncia de projetos, na
estrutura do PAS;

1.3 MOTIVAO

O guia PMBOK da PMI bem como o RUP (RUP, 2005) oferecem
possibilidades de gerenciamento de reas do conhecimento muito importantes para
o processo de desenvolvimento de software e sua gerncia. A metodologia do PMI
a que mais cresce em aceitao pelas empresas e desenvolvedores que desejam
melhorar a gerncia de projetos. Seu foco facilitar o conhecimento de forma
genrica, sem se limitar ao tipo do projeto, usando conceitos claros e que se
adaptem a qualquer projeto. O RUP tambm focado na conduo de projetos de
forma que eles tenham mais chances de serem finalizados. Ambos os mtodos
possuem fases bem definidas de desenvolvimento, desde a iniciao at o fim do
projeto. Por esta razo perfeitamente possvel a migrao de recursos destes
processos ao PAS.
15
Para a cincia, a extenso do PAS representa a elevao do nvel de um

processo de software, deixando este no patamar de outros processos de grande
valor na comunidade cientfica.
Mas tambm se podem destacar os benefcios os profissionais do
desenvolvimento de software, que tero uma ferramenta de fcil utilizao, porm
provida de gerenciamento de alta qualidade.
Ao utilizar o PAS com extenses de gerncia, o IFRN e toda a comunidade
acadmica podero encontrar um processo de fcil aprendizado, mas semelhante
aos grandes processos que so utilizados no mercado de trabalho fora das
instituies de ensino.
E para mim, o aprendizado sobre as tecnologias envolvidas, o compreender
sobre o funcionamento do PAS, e a experincia de poder continuar um trabalho que
j foi desenvolvido por tantos outros alunos antes de mim so coisas muito
gratificantes, de valor pessoal to imensurvel quanto tambm o o prprio produto
fruto deste trabalho.

1.4 METODOLOGIA

Inicialmente foi realizada uma pesquisa bibliogrfica sobre o tema:
gerenciamento de projetos de software, e suas reas de conhecimento, bem como
do PAS e sua estrutura. Em seguida, foi estudado o EPF Composer, principal
ferramenta utilizada para a publicao do website do PAS, possibilitando assim,
entender tambm a prpria estrutura de implementao do PAS no EPF. Assim, foi
possvel realizar as melhorias desejadas no PAS.

16
2 PROCESSOS DE SOFTWARE (PAS)

Ao apresentar o que foi estudado sobre esta temtica, ser possvel
compreender o trabalho que ser apresentado a partir do prximo captulo.
Objetivando apresentar o PAS como um modelo de processo com foco acadmico,
em seguida ser apresentada uma explicao a respeito do EPF, o que motivou a
sua utilizao neste projeto, e ento apresentar as gerncias de processo de
desenvolvimento que so escopo deste trabalho.

2.1 PROCESSO ACADMICO SIMPLIFICADO (PAS)

O Processo Acadmico Simplificado (PAS) foi criado no IFRN diante da
oportunidade de facilitar o aprendizado dos alunos das disciplinas de Engenharia de
Software e Gerncia de Projetos do curso superior em Tecnologia em
Desenvolvimento de Software, atualmente substitudo pelo curso superior em
Tecnologia em Anlise e Desenvolvimento de Sistemas.
Segundo Sommerville (2007), podem ser criados modelos hbridos de
processo de software, o que facilita a organizaes atender as necessidades
peculiares e os fluxos de atividades dos seus projetos. Esses modelos so baseados
em outros modelos de processo j conhecidos, e podem sofrer constantes
alteraes. Isto ocorre para que haja uma melhor adaptao s atividades
propostas, podendo desta forma unir as melhores ideias de cada processo para um
projeto especfico.
Desta maneira, os alunos do Instituto desenvolveram no ano de 2006 um
modelo de processo que tem como objetivo ser um modelo fcil, simples e
desburocratizado de desenvolvimento de software. Atualmente, segundo Silva
(2011), podemos descrever o PAS como um processo iterativo e incremental,
baseado nas prticas do UP (Unified Process) e da modelagem gil, com ideias
retiradas do RUP, do XP (eXtreme Programming) e do ICONIX.
Atualmente o seu acesso pblico, atravs do site do IFRN, onde possvel
visualizar sua estrutura e divises. Para melhor organizao, o processo
apresentado em quatro modos de visualizao: Processo, Atividades (ou
Disciplinas), Papis e Artefatos.
17
O Processo de desenvolvimento em si dividido em quatro fases:

Concepo, Elaborao, Construo e Validao (Figura 1). Cada fase possui
diferentes tarefas para cada uma das atividades que a compem (Atividade de
Requisitos, Anlise e Projeto, Implementao e Teste, e Gerncia).
As fases descritas pelo PAS so:

a) fase de concepo - quando o cliente define o projeto a ser desenvolvido, e
analisada a viabilidade do mesmo, com base na anlise dos requisitos. Para o
PAS, esta fase opcional, uma vez que os projetos em geral so de cunho
acadmico, e sua observao de viabilidade comercial nem sempre
necessria;
b) fase de Elaborao - nesta fase a arquitetura validada, os casos de uso so
detalhados e o projeto finalizado;
c) fase de Construo - nela feita grande parte da implementao do sistema.
Seu trmino se d com a finalizao do produto;
d) fase de Validao - onde so feitos os ltimos testes, a implantao,
treinamento e demais etapas previstas.

Figura 1 - Diagrama de Fases do PAS.

Fonte: PAS (2006).
18
Atravs da navegao no PAS por papis, possvel conhecer cada um dos

papis que o PAS descreve eclipse, e as suas tarefas e artefatos relacionados.
J na visualizao por Artefatos, possvel ver todos os modelos de
documentos que podem ou devem ser gerados durante o processo de
desenvolvimento. Estes templates so um guia para a produo da documentao
especfica de cada projeto.

2.1.1 Fases do PAS

Devido a sua estrutura iterativa a incremental, o PAS organizado em quatro
fases de desenvolvimento, sendo cada fase composta de quatro disciplinas (ou
atividades), a saber: Requisitos, Anlise, Implementao e Testes, e Gerncia de
Processo.
A diviso em fases propicia um melhor controle do processo. Desta forma,
cada fase iniciada e finalizada, possibilitando clareza quanto ao que deve ser feito
em cada uma delas. Como estas fases so sequenciais, o encerramento de uma
determinada fase marcado com a entrega do produto de trabalho produzido em
uma fase para outra (PMBOK, 2003).
Neste tpico sero detalhadas todas as fases contidas na estrutura do PAS
com suas respectivas disciplinas. A Figura 2 mostra o diagrama das fases do PAS.

Figura 2 - Diagrama das fases do PAS.

Fonte: PAS (2006).

Na Figura 3, possvel ver o diagrama de fluxo das disciplinas das fases de
Concepo, Elaborao, Construo e Validao do PAS.

19

Figura 3 - Diagrama de fluxo das Disciplinas das Fases do PAS.

Fonte: PAS (2006).

2.1.1.1 Fase de concepo

Esta fase de fundamental importncia para a compreenso do projeto a ser
desenvolvido. Para se determinar como termina esta fase, o sistema deve j estar
claramente visualizado pela equipe, ou seja, seu escopo, seus principais requisitos e
os desejos que o cliente tenha (PONTES; ALEIXO; MINORA, 2006).
Esta fase marcada por reunies, discusses, organizadas da seguinte
forma: Inicialmente o cliente dever expor suas necessidades, a viso que tem do
sistema e o que ele necessita do mesmo. a viso do cliente sobre o que dever
ser feito. importante considerar que normal, que o prprio cliente no saiba
exatamente o que necessita, uma vez que o comum que os clientes no
conheam por completo as tecnologias existentes, nem mesmo as possibilidades
existentes no mercado.
Aps, o primeiro momento, a equipe iniciar a sua exposio de ideias,
baseado no que puderam capturar da exposio do cliente. Segundo Montenegro
(2008), esta fase pode se tornar meramente observativa para o aluno quando o
professor trabalha como gerente. Por esta razo programado durante o decorrer
do curso superior de TADS a influncia exercida pelos professores no projeto seja
cada vez menor, semestre aps semestre.

2.1.1.1.1 Requisitos
A disciplina de requisitos tem como objetivo fazer a coleta de todas das

informaes relativas ao escopo do projeto, e compreender perfeitamente o
problema apresentado. Definir ento as funes e restries do sistema, e por ltimo
fazer a listagem dos casos de uso encontrados, com uma breve descrio dos
mesmos.

20
2.1.1.1.2 Anlise e projeto
Neste primeiro momento, a disciplina de anlise, ir trabalhar em cima dos

dados levantados na disciplina de requisitos. Seu principal objetivo a definio de
uma arquitetura para o projeto. Caso a arquitetura escolhida seja aprovada pela
equipe, ento a disciplina estar finalizada.

2.1.1.1.3 Implementao e testes
A tarefa destinada a disciplina de implementao e testes simples, trata-se

da confeco dos prottipos de tela. Os prottipos de tela so uma forma fcil de
possibilitar que as partes interessadas do projeto faam experincias com um
modelo do seu produto final, ao invs de apenas discutirem representaes
abstratas dos seus requisitos (PMBOK, 2004).

2.1.1.1.4 Gerncia de processo
A disciplina de gerncia de processo nesta primeira fase tem 15 tarefas

programadas. a gerncia que estar coordenando todos os processos ocorridos
de reunies, registrando todos os acontecimentos, e gerando os documentos que
iro reger todo o processo de desenvolvimento. importante que o gerente tente
fazer estes planejamentos o mais prximo da realidade possvel, para que os outros
membros da equipe possam ter como base estes documentos gerados durante o
processo.

2.1.1.2 Fase de elaborao

A fase de Elaborao inicia aps o entendimento da equipe acerca do
trabalho que deve ser feito. O objetivo principal, desta fase, concluir o
planejamento do sistema, para que durante a prxima fase a equipe possa ter todas
as instrues necessrias para desempenhar suas atividades. Pontes (2007) diz que
para isto podero haver tantas iteraes quantas forem necessrias, at que tudo
esteja resolvido.
21
A arquitetura tambm necessita estar definida e validada, pronta para o incio

da implementao da fase de construo, com a certeza de que poder suportar os
requisitos levantados na fase anterior, no tempo e no custo pr-determinado.
A estrutura fsica e lgica deve estar completamente definida, e todas as
ferramentas que sero utilizadas durante o processo de desenvolvimento devero
estar preparadas para o uso.

Esta disciplina tem a responsabilidade de escolher os casos de uso que sero

usados para validar a arquitetura apresentada, e complementar o detalhamento de
todos os casos de uso. Caso seja necessrio, podero haver novas entrevistas com
o cliente, a fim de esclarecer possveis dvidas que apaream nesta etapa.
importante que no sobrem dvidas neste processo, e que a descrio dos casos de
uso seja a mais completa possvel.

A Anlise de Projetos a disciplina que recebe os documentos gerados na

disciplina de Requisitos, com o intuito de criar modelos estticos e dinmicos. Ela vai
criar a modelagem que ser seguida pelos programadores nas prximas iteraes
da fase de construo (PONTES, 2007).

Os implementadores seguiro os passos que lhes foram dados,

implementando e validando a arquitetura com base nos casos de uso que lhe foram
entregues. Caso a arquitetura consiga ser validada, a disciplina se encerra, caso
contrrio, novas anlises sero feitas para corrigir os problemas encontrados.

A gerncia de processos nesta fase ir revisar o plano de desenvolvimento j

escrito, bem como continuar o acompanhamento da equipe, realizando reunies e
22
registrando seus resultados. A gerencia tambm deve suportar o ambiente da fase

corrente, tendo como suporte fsico e lgico a equipe de desenvolvimento.

2.1.1.3 Fase de construo
A fase de construo de um projeto de software geralmente a fase mais
extensa. A principal atividade realizada o desenvolvimento propriamente dito do
sistema.
A fase de construo , de certo modo, um processo industrial, no
qual enfocado o gerenciamento de recursos, controle dos custos,
prazos e qualidade. (PONTES; ALEIXO; MINORA, 2006, p. 07)

Esta fase pode durar quantas iteraes sejam necessrias, at que o produto
de software esteja pronto com base na arquitetura e no plano pr-determinados.
necessrio que este produto seja produzido com rapidez, eficincia e nos prazos e
custos j estimados. O produto passar pela anlise, desenvolvimento e teste, em
todas as funcionalidades necessrias. (PONTES, 2007)

Nesta fase, a disciplina de Requisitos, ir detalhar casos de uso restantes.

normal tambm que aconteam mudanas nos casos de uso que vo sendo
desenvolvidos pela equipe de Implementao. Neste caso, a disciplina de requisitos
especifica que estas mudanas devero sempre ser registradas, e os documentos
atualizados.

Segundo Pontes (2007), a disciplina de Anlise e Projeto transforma em

modelos conceituais o que foi capturado pelas reunies da disciplina de requisitos e
a disciplina de Implementao e Teste constri e integra os modelos definidos.

A equipe de implementao dever buscar atingir seus objetivos de forma

rpida e eficaz, minimizando os custos, evitando fragmentar e refazer o
23
desnecessrio. Deve ser desenvolvido de forma interativa e incremental um produto

completo e pronto para a validao. (PONTES, 2007)

A gerncia deve monitorar o desenvolvimento, identificando

incompatibilidades e tratando-as. Tambm atribuio da gerncia a exibio dos
resultados ao cliente, recebendo o feedback do mesmo e registrando os dados
recebidos e atualizando os planos necessrios.

2.1.1.5 Fase de validao

O PMBOK (2004, p. 335) define validao como:

A garantia de que um produto, servio ou sistema atende s
necessidades do cliente e de outras partes interessadas. Muitas
vezes, envolve a aceitao e adequabilidade com clientes
externos.

Esta fase , geralmente, composta por poucas e curtas iteraes, destinadas
aos testes do produto criado, e a sua apresentao ao cliente. Aps o cliente testar
a aplicao j desenvolvida, podem surgir modificaes, que sero enviadas para a
equipe de desenvolvimento at que tudo esteja de acordo com o especificado pelo
cliente.
Ao trmino desta fase, todos os objetivos deve ter sido atendidos e o projeto
deve estar numa posio de finalizao. (PONTES; ALEIXO; MINORA, 2006)

O objetivo desta disciplina na fase de validao verificar principalmente se

houve acrscimo de novas funcionalidades (novos casos de uso). Caso os haja,
dever ser feita a disciplina de requisitos como na fase de construo.

24
A disciplina de anlise, assim como a de requisitos, deve verificar se

houveram novos casos de uso e, em caso positivo, realizar a disciplina de anlise de
projeto da fase de construo.

A equipe deve estar focada principalmente nos testes: testes alfa, verificando
os erros, e j analisando a necessidade de se remodelar ou reimplementar, e os
testes beta, coletando sempre os resultados de aceitao, satisfao e usabilidade
dos usurios ao sistema.
Aps todos estes processos, devero ser gerados relatrios com todos os
dados coletados, concluindo se o sistema est ou no aprovado. Em caso positivo, a
fase est terminada, se no, mais testes podem ser aplicados.

A gerncia de processo da quarta fase do PAS desempenha seu papel dando

suporte ao ambiente de desenvolvimento e testes que se faz necessrio. Alm disto,
a responsvel pela apresentao do produto ao cliente, pelo registro destes
encontros, sempre observando o cumprimento pleno das especificaes
determinadas nos planos de desenvolvimento de software e de iterao e
integrao.

2.2 ECLIPSE PROCESS FRAMEWORK (EPF)

Ao se tentar aplicar processos de desenvolvimento de softwares em projetos,
os desenvolvedores enfrentam uma grande dificuldade - a necessidade de ler
extensas documentaes de vrios modelos de processos diferentes, para ento
escolher a ideal.
Um dos principais problemas que nem todo conhecimento que foi obtido
pelas leituras facilmente aplicado a diferentes projetos e prticas. Outra questo
25
que no existe uma terminologia ou linguagem comum entre os modelos, o que

dificulta a convergncia de boas prticas vindas de um modelo para outro.
O Eclipse Process Framework (EPF) surgiu justamente para suprir esta
necessidade do mercado. Os processos agora podem ser documentados,
organizados em um ambiente especialmente preparado para isto, e, por fim,
publicados, para facilitar a consulta atravs de um website simples. A ferramenta
disponibilizada pela Eclipse Foundation para a edio de processos EPF a EPF
Composer.
Inicialmente, quando a Eclipse Foundation criou o Eclipse Process Framework
Composer, objetivou apenas prover uma estrutura de gerenciamento de contedo
com gerenciamento comum, a fim de solucionar problemas internos encontrados
pela sua equipe durante a concepo de projetos (ECLIPSE, 2009). Hoje, a
plataforma ganhou sua real utilidade, definida como um ecossistema colaborativo
e aberto para processos de desenvolvimento de software evolutivos (ECLIPSE,
2009). Segundo Haumer (2007), o EPF tem dois objetivos principais:

Fornecer aos profissionais de desenvolvimento um ambiente que
permita a busca, a gerncia e a distribuio do contedo. Esse contedo pode ser
licenciado ou adquirido, e deve acomodar seu prprio contedo, como por exemplo,
definio de mtodos, princpios, melhores prticas, procedimentos internos e
regulamentaes.
Fornecer a capacidade de engenharia de mtodos, prestando desta
forma suporte aos engenheiros de mtodos e aos gerentes de projeto para que
possam selecionar, personalizar, e rapidamente escolher processos para o
desenvolvimento de projetos.

importante tambm saber que o EPF baseado na linguagem de
modelagem SPEM (Software Process Engineering Metamodel, mantida pela Object
Management Group - OMG), composta por um conjunto de construtores e regras
para definir e modelar processos de software.
Desta forma, o EPF consegue modelar todos os grandes processos
existentes no mercado, pois sua estrutura ampla e genrica, baseada em
elementos comuns a todos estes mtodos (Figura 4).

26

Figura 4 - Estruturas bsicas do EPF.

Fonte: ECLIPSE (2009).

Alm disto, atravs do website do EPF possvel descarregar diretamente o
cdigo fonte de vrios processos de desenvolvimento, para assim mescl-los e criar
o seu prprio processo com contedo derivado. Isto til para extrair padres que
no so existentes em um modelo para outro modelo que se enquadre mais as suas
necessidades.
Na atualidade, o EPF j um padro internacional usado por vrias
empresas, inclusive por empresas de certificao como CMMI, ISO e ITIL, facilitando
assim a exposio de documentaes relativas ao processo de desenvolvimento de
software para meios de certificao de processos produtos e profissionais.
Ao final da edio de um processo, o modelo gerado pelo EPF Composer
pode ser publicado em formato de pginas HTML. Este procedimento facilita o
acesso ao contedo para usurios que possuam acesso apenas a um navegador de
Internet. A Figura 5 demonstra um exemplo de publicao atravs do EPF
Composer.

27

Figura 5 - Estrutura de publicao de um processo pelo EPF Composer.

Fonte: OLIVEIRA (2011).

2.3 PROCESSO DE SOFTWARE: TIPOS DE GERNCIA DE PROJETO

A estrutura de gerncia do PAS constituda por 23 tarefas, divididas entre
as quatro fases presentes no PAS - Fase de Concepo, Fase de Elaborao, Fase
de Construo e Fase de Validao, como se pode ver na Figura 6. Tambm so
gerados cinco artefatos: Atas de Reunio, Documento de Ambiente, Documento de
Feedback, Plano de Desenvolvimento de Software e Plano de Iterao e Integrao.

28
Figura 6 - Relacionamentos do Papel do Gerente de projetos do PAS.


Segundo o modelo em foco, existem dois papeis que atuam na rea de
gerenciamento. Um deles o prprio Gerente de Projetos, j citado. Mas tambm
includo nos papis de gerncia est o Stakeholder (Figura 7). Os stakeholders so
todos os envolvidos no processo de forma permanente ou temporria. Em geral so
clientes, proprietrios, professores, usurios, etc. As orientaes dos stakeholders,
segundo Heldman (2003), so de vital importncia para um bom gerente de projetos
e este deve saber equilibrar as restries, bem como atender e exceder as
expectativas destes.

Figura 7 - Papel do Stakeholder e sua tarefa, segundo o PAS.

Fonte: PAS (2006).

A Engenharia de Software, porm, no se limita a estas atividades de
gerncia, possuindo muitas outras reas de conhecimento em gerenciamento, das
quais cinco so foco deste trabalho e esto descritas neste documento.

29
2.3.1 Gerncia de ambiente

A gerncia de ambiente tem como objetivo prover um ambiente propcio para
o desenvolvimento do projeto. formado pelas ferramentas e processos
necessrios capazes de suportar as atividades que a equipe venha a desempenhar.
Todo o processo de escolha, instalao e suporte de ferramentas e
tecnologias utilizadas durante o processo registrado e acompanhado de forma que
o processo fique o mais transparente possvel, facilitando o processo futuro de
atualizao, manuteno e migrao dos sistemas utilizados, por exemplo.

2.4.2 Gerncia de configurao

Uma grande quantidade de informaes produzida durante o processo de
desenvolvimento de um software (documentos, manuais, cdigo fonte, dados em
geral). Frequentemente necessrio efetuar mudanas nestes dados, e por isto
essencial o registro, acompanhamento e controle destas mudanas.
O no registro e acompanhamento das mudanas efetuadas em um software
podem gerar a uma discrepncia entre o produto projetado e o obtido no
desenvolvimento.

2.4.3 Gerncia de qualidade

A definio de qualidade muito antiga, e sua definio muito ampla. Na
engenharia de software, a qualidade entendida como o grau at o qual um
conjunto de caractersticas inerentes satisfaz as necessidades (PMBOK 2004).
Desta forma, podemos entender como um projeto com qualidade aquele que foi
concludo com conformidade com seus requisitos, especificaes e adequaes ao
uso.
Para que esta qualidade seja assegurada em um projeto, essencial que
sejam obedecidos os padres e normas pr-estabelecidas. A gerncia de qualidade
tenta manter o software nos padres especificados durante seu desenvolvimento.

30
2.4.4 Gerncia de recursos humanos

Esta gerncia responsvel por supervisionar as atividades da rea de
recursos humanos do projeto. Inclui o recrutamento, seleo, treinamento e
capacitao dos membros da equipe. O gerente de recursos humanos da equipe
deve liderar a equipe durante o desenvolvimento, influenciando os membros a
trabalharem de forma mais eficaz possvel, impedindo que fatores de recursos
humanos venham a impactar o projeto. Tambm deve observar e resolver
problemas pessoais dentro da equipe, trazendo aos membros um comportamento
tico e profissional.

2.2.1. Gerncia de risco

Os Riscos podem ser definidos como um conjunto de eventos que podem
ocorrer durante o processo de desenvolvimento de software. Estes eventos podem
influenciar o software de forma positiva ou negativa caso ocorram (PMBOK 2004). A
gerncia de risco tem objetivo principal impedir que o projeto venha a ser impactado
com eventos no esperados durante seu desenvolvimento, trazendo mudanas no
seu cronograma, nos seus custos, na qualidade final do produto, ou em qualquer
aspecto que possa ferir plano de desenvolvimento de software.

31
3 EXTENSO DO PAS PARA ATIVIDADES DE GERNCIA

O foco deste captulo apresentar a extenso do Processo Acadmico
Simplificado (PAS), desenvolvida durante este TCC
1
. O principal esforo realizado
foi a criao de cinco novas gerncias, ampliando desta forma as reas de
conhecimento gerenciadas pelo processo, porm sem alterar a estrutura original do
mesmo.
Alm disto, tambm foi feita a converso da estrutura do PAS para a verso
1.5 do EPF (Eclipse Process Framework) Composer, e a traduo por completo do
mesmo para o idioma portugus brasileiro, atravs da adaptao de um pacote de
idioma disponvel no site do fabricante do EPF Composer. Adicionalmente, foram
traduzidos ao portugus alguns templates de documento do processo, que tambm
estavam em ingls desde a primeira publicao do modelo de Processo.

3.1 ATIVIDADES DE GERNCIA PARA O PAS

O PAS possui dois papis relacionados com a gerncia do processo de
desenvolvimento de software (Figura 8). Um deles o papel dos stakeholders, que
desempenham apenas uma tarefa: o auxlio na definio inicial do projeto. O
segundo papel o do gerente de projetos, que desempenha todas as tarefas de
gerncia descritas no PAS.

1
AextensodoPAScriadapodeseracessadaemhttp://www.arioliveira.com/pas
32
Figura 8 - Papeis do PAS, com destaque para os papeis de gerncia.

Fonte: PAS (2006).

A proposta deste trabalho apresentar novas gerncias, que ampliem as
possibilidades de gerncia do PAS para as cinco novas reas. Para isto, as
principais fontes de pesquisa utilizadas, dentre outras, foram os prprios processos
do PMBOK para as gerncias de Recursos Humanos, Qualidade e Risco, e o do
RUP para as gerncias de Ambiente e Configurao. Adicionalmente, tambm foram
criados cinco novos papeis de gerncia: Gerente de Ambiente, Gerente de
Configurao, Gerente de Qualidade, Gerente de Recursos Humanos e Gerente de
Riscos.
Para tal procedimento, foi necessrio primeiramente conhecer a estrutura do
PAS no EPF Composer. O PAS foi criado em estrutura de Content Packages.
Content Package um pacote que descreve as atividades, papis, artefatos e
orienta a utilizao no mesmo contexto, Haumer (2007). Assim, foram criados
Content Packages ou simplesmente Pacotes de Contedo para vrias funes
diferentes do PAS (Figura 9).

33
Figura 9 - Estrutura original de Pacotes de Contedo do PAS no EPF Composer.


Para estender o PAS a novas categorias de gerencia propostas, foram
criados cinco novos pacotes de contedo dentro do pacote
gerencia_todas_as_fases, abrangendo agora as cinco novas reas de
conhecimento foco deste trabalho, conforme pode ser visualizado na Figura 10.

Figura 10 - Nova estrutura de Pacotes de Contedo do PAS no EPF Composer.


Neste captulo ser feito o detalhamento de como foram criadas as cinco
gerncias propostas por este TCC.

3.1.1 Gerncia de ambiente

A gerncia de ambiente aqui registrada foi inspirada na disciplina de ambiente
definida pelo RUP. Apesar de no ter claramente uma rea de conhecimento sobre
ambiente, o PMBOK tambm fornece tcnicas para gerenciamento de ambiente em
34
suas definies de cada rea. Estas foram as fontes de pesquisa utilizadas para a
realizao da pesquisa.
As tarefas criadas para a Gerncia de Ambiente desta extenso do PAS
foram:
a) preparar ambiente do projeto;
b) preparar ambiente para iterao;
c) preparar diretrizes para iterao;
d) suportar ambiente durante a iterao.

3.1.1.1 Preparar ambiente do projeto

Esta tarefa inclui uma anlise geral de tudo que ser utilizado para o
desenvolvimento do software. Dentre os itens avaliados, pode-se citar:
a) sistema Operacional que ser usado no desenvolvimento;
b) ferramentas que sero utilizadas durante o desenvolvimento;
c) ferramentas especficas para a gerncia organizar e coordenar o projeto;
d) ferramenta ou mtodo colaborativo para facilitar o trabalho em equipe (uso de
repositrio, por exemplo);
e) instalao ou configurao das ferramentas para uso.
Deve ser criado um Documento de Ambiente, onde todas as informaes
referentes ao Ambiente sero armazenadas, bem como as aes planejadas para o
decorrer do projeto.
Alm disto, nesta atividade est includa a criao de templates de elementos-
chave especficos para o projeto em questo, para assim padronizar os artefatos do
desenvolvimento, deixando-os de acordo com um padro definido no prprio
Documento de Ambiente.

3.1.1.2 Preparar ambiente para iterao

o refinamento do processo realizado na tarefa anterior, mas agora
especificamente para uma Iterao. Dentre as etapas descritas para esta atividade
podemos citar:
a) Concluir o Documento de Ambiente, com informaes sobre a Iterao;
b) Preparar ou adaptar as ferramentas especficas para esta iterao;
35
c) Verificar se as ferramentas esto instaladas e prontas para uso;

d) Produzir templates de elementos-chave especficos para a Iterao.

3.1.1.3 Preparar diretrizes para iterao

Nesta atividade necessrio descrever o conjunto de instrues, indicaes e
regras que iro reger e conduzir a iterao que se inicia. Estas diretrizes geradas
devem ser armazenadas tambm no documento de ambiente do projeto.

3.1.1.4 Suportar ambiente durante iterao

Esta atividade envolve vrios servios tcnicos relacionados Iterao, como
a manuteno da infraestrutura de software e hardware para o desenvolvimento,
administrao do sistema, criao de backups, criao e reproduo de
documentos, telecomunicaes, e atividades relacionadas.

As atividades desta gerncia foram compiladas em um diagrama de fluxo de
tarefas, que est representado pela Figura 11.

36
Figura 11 - Diagrama de Atividades da Gerncia de Ambiente, na fase de

Concepo do PAS no EPF Composer.

Atravs do EPF Composer foi criada a estrutura de arquivos, composta pela
funo e pelas tarefas, que sero utilizadas durante todas as fases (Figura 12).

Figura 12 - Estrutura da Gerncia de Ambiente do PAS no EPF Composer.

37
3.1.2 Gerncia de configurao

Assim como na gerncia de risco, para a criao da extenso do PAS para a
gerncia de configurao foi necessrio um aprofundamento terico sobre a
estrutura desta gerncia e ento reunir os dados necessrios.
Para esta gerncia, o modelo de tarefas foi baseado nas atividades de
Gerncia de Configurao e Mudana do RUP. Apesar do PMBOK no possuir
nenhuma rea de conhecimento focada na gerncia de configurao, foi possvel
extrair algumas definies das Atividades de Desenvolver Plano de gerenciamento
do Projeto - Plano de gerenciamento de Configurao.
As tarefas criadas para a Gerncia de Configurao desta extenso do PAS
foram:
a) Planejar controle de configurao e mudanas;
b) Preparar ambiente de gerenciamento de mudanas;
c) Mudar e disponibilizar itens;
d) Gerenciar verses;
e) Monitorar e reparar status;
f) Gerenciar pedidos de mudanas.

3.1.2.1 Planejar controle de configurao e mudanas

O objetivo desta tarefa criar o Plano de Configurao e Mudanas, seus
procedimentos, regras e responsabilidades. Este documento tambm vai especificar
os padres que sero seguidos pela equipe durante o desenvolvimento, como por
exemplo:
a) Nomenclatura de arquivos;
b) Variveis;
c) Classes;
d) Atributos;
e) Mtodos;
f) Banco de Dados, tabelas.

38
Esta tarefa ocorre apenas na fase de concepo e executada pelo gerente

de configurao, tendo como entrada o plano de desenvolvimento de software e
como sada o plano de gerncia de configurao e mudanas.

3.1.2.2 Preparar ambiente de gerenciamento de mudanas

o processo em que o gerente de configurao trabalha junto com o
administrador de sistemas e com o gerente de ambiente para alocar recursos fsicos
necessrios para o desenvolvimento do projeto. So analisados requisitos de
memria, espao em disco, rede e repositrios, por exemplo.
Esta tarefa ocorre nas quatro fases de desenvolvimento e executada pelo
gerente de configurao, tendo como entrada sempre o plano de gerncia de
configurao e mudanas.

3.1.2.3 Mudar e disponibilizar itens

Esta atividade diz respeito a como os profissionais iro acessar os dados,
realizar as mudanas e ento adicion-las ao produto. importante que todas as
modificaes sejam aprovadas e, posteriormente, comunicadas a todos da equipe.

3.1.2.4 Gerenciar verses

O objetivo desta atividade garantir que os baselines (de acordo com o RUP
so componentes individualmente testados por vrios implementadores e equipes
de desenvolvimento, combinados para funcionarem juntos como um produto) sejam
devidamente rotulados, e formem verses do produto. Cada verso ter seu rtulo
de baseline, onde possvel acompanhar o nvel de maturidade, estabilidade e
qualidade do produto.
39
3.1.2.5 Monitorar e reportar status

o processo de acompanhamento do andamento do projeto frente s
mudanas ocorridas, incluindo o controle dos prazos e custos para a finalizao do
projeto, caso as mudanas tenham causado impactos diretamente nestes.

3.1.2.6 Gerenciar pedidos de mudanas

o processo que garante que as mudanas solicitadas durante o processo de
desenvolvimento sero devidamente registradas e avaliadas, que sero analisados
os possveis impactos que estas mudanas podem causar e que os stakeholders
sejam tambm informados.
Desta forma, o processo de controle mudanas seguir um padro
consistente e todos os envolvidos sero notificados tanto antes quanto depois das
mudanas.
configurao e mudanas e como sada tambm o plano de gerncia de

40
Figura 13 - Diagrama de Atividades da Gerncia de Configurao na fase de



Figura 14 - Estrutura da Gerncia de Configurao do PAS no EPF Composer.


41
3.1.3 Gerncia de qualidade

A gerncia de qualidade bem descrita tanto pelo PMBOK quanto pelo RUP,
e at por outros modelos de processo, por ser um tema muito buscado por gerentes
de desenvolvimento de software.
Desta forma, para a criao da extenso do PAS para esta gerncia foram
usados como fonte de pesquisa a rea de conhecimento do PMBOK de
Gerenciamento de Qualidade do Processo. Para a elaborao do modelo de Planos
de Gerncia de Qualidade foi utilizado como inspirao o Plano de Garantia de
Qualidade, atribudo ao Gerente de Projetos do RUP.
As tarefas criadas para a Gerncia de Qualidade desta extenso do PAS
foram:
a) desenvolver planejamento de qualidade;
b) realizar garantia de qualidade;
c) realizar controle de qualidade.

3.1.3.1 Desenvolver planejamento de qualidade

o processo de identificao dos padres de qualidade que so realmente
relevantes para um projeto e a determinao de como satisfaz-los. Normalmente
este planejamento ocorre juntamente com o planejamento do projeto geral, pois as
suas mudanas interferem diretamente nos prazos e custos do projeto.
Ao final desta tarefa deve ser entregue o Plano de Gerncia de Qualidade,
que contempla todos os objetivos da qualidade, bem como planos de reviso e
auditoria, testes e registros envolvidos com a qualidade.
Esta tarefa ocorre apenas na fase de concepo e executada pelo gerente
de qualidade, tendo como entrada o plano de desenvolvimento de software e como
sada o plano de gerncia de qualidade.

3.1.3.2 Realizar garantia da qualidade

a real aplicao das atividades programadas no planejamento de qualidade,
para assegurar que o projeto est realmente empregando os processos necessrios
para atender os requisitos do projeto.
42

gerente de qualidade, tendo como entrada sempre o plano de gerncia de
qualidade.

3.1.3.3 Realizar controle da qualidade

A atividade de controle da qualidade est relacionada com o monitoramento
de resultados especficos do projeto a fim de verificar se os padres de qualidade
estabelecidos anteriormente foram atendidos, bem como com a identificao de
possveis perdas de desempenho e as maneiras de solucionar as causas deste.
gerente de qualidade, tendo como entrada sempre o plano de gerncia de
qualidade.

Figura 15 - Diagrama de Atividades da Gerncia de Qualidade, na fase de



43
Figura 16 - Estrutura da Gerncia de Qualidade do PAS no EPF Composer.


3.1.4 Gerncia de recursos humanos

Apesar do RUP no descrever nenhuma gerncia ou plano de organizao
para a gerncia de Recursos humanos, esta bem descrita pelo PMBOK. Esta rea,
inclusive, uma importante rea da Administrao, e por isto, suas tcnicas so
amplamente difundidas.
Desta forma, para a criao da extenso do PAS para esta gerncia foram
usados como fonte de pesquisa a rea de conhecimento do PMBOK, e seus
conceitos foram utilizados para a criao do Modelo do Plano de Recursos Humanos
do projeto.
As tarefas criadas para a Gerncia de Recursos Humanos desta extenso do
PAS foram:
a) desenvolver planejamento de recursos humanos;
b) contratar ou mobilizar equipe;
c) desenvolver equipe de projeto;
d) gerenciar equipe de projeto.

3.1.4.1 Desenvolver planejamento de recursos humanos

Nesta atividade gerado o Plano de Gerncia de Recursos Humanos. Neste
documento definida a hierarquia da equipe, responsabilidades, regras para
treinamento e definies sobre bonificao e recursos.

44
3.1.4.2 Contratar ou mobilizar equipe

Em alguns casos, as equipes de desenvolvimento de uma determinada
empresa j esto definidas antes do incio do projeto. Em outros casos, h a
necessidade de escolher as pessoas que trabalharo em um determinado projeto,
ou mesmo de contratar novos membros que faro parte deste grupo. Nesta atividade
devem ser escolhidos os membros e relacionados que papis e atividades tero at
o fim do projeto.

3.1.4.3 Desenvolver equipe de projeto

A atividade de desenvolver equipe de projeto o processo de melhoria de
competncias, interaes e ambiente global dos profissionais da equipe, visando
melhoria do desempenho geral em um projeto. Em alguns casos, este trabalho
tambm pode ser realizado em juno com o gerente de ambiente, para que as
ferramentas e tecnologias usadas sejam plenamente dominadas pela equipe.
Tambm importante a motivar, inspirar, auxiliar e incentivar os membros da equipe
para que alcancem um alto desempenho e cumpram os objetivos do projeto.

3.1.4.4 Gerenciar equipe de projeto

Gerenciar equipe de projeto o processo de acompanhar os membros da
equipe, buscando resolver problemas que possam otimizar o desempenho da
equipe. Tambm necessrio coordenar as mudanas necessrias durante este
processo, para evitar conflitos e melhorar o desempenho individual. Quando
necessrio, mudanas so feitas, e o plano de gerncia de recursos humanos
atualizado com os registros do ocorrido.

45

Figura 17 - Diagrama de Atividades da Gerncia de Recursos Humanos, na fase de


Figura 18 - Estrutura da Gerncia de Recursos Humanos do PAS no EPF Composer.

46
3.1.5 Gerncia de risco

Para a implementao das atividades da gerncia de risco no PAS foi
necessrio primeiramente reunir os dados necessrios para preencher os pr-
requisitos do EPF Composer.
No caso desta gerncia, o modelo de tarefas foi inspirado no modelo do
PMBOK na rea de conhecimento nomeada Gerenciamento de Riscos do Projeto.
O detalhamento e criao de etapas individuais para cada tarefa foi feita com auxlio
de outros autores, como Martins (2005). Os modelos de documento foram criados
baseando-se nos modelos apresentados pela documentao do RUP para a
atividade de Desenvolver Plano de Gerenciamento de Riscos, atribuda ao Gerente
de Projetos.
As tarefas criadas para a Gerncia de Risco desta extenso do PAS foram:
a) planejar gerncia de risco;
b) identificao de riscos.
c) realizar a anlise qualitativa de riscos;
d) realizar anlise quantitativa de riscos;
e) planejar resposta aos riscos;
f) monitorar e controlar riscos.

3.1.5.1 Planejar gerncia de risco

Nesta tarefa, o objetivo do gerente abordar e planejar as atividades de
gerenciamento de risco para o projeto. Como sada desta tarefa, temos o Plano de
Gerncia de Risco, com todas as especificaes sobre os riscos do projeto, e aes
realizadas.
Esta tarefa ocorre apenas na fase de concepo do projeto e executada
pelo Gerente de Risco, tendo como entrada o documento de Arquitetura do sistema
e o documento de viso, e como sada o plano de gerncia de Risco.

47
3.1.5.2 Identificao de riscos

Esta tarefa executada prioritariamente pelo gerente de risco, mas toda a
equipe envolvida pode e deve auxiliar no processo de identificao. Todos os riscos,
desde os mais improvveis at os iminentes, desde os com impacto pequeno at os
catastrficos devem ser listados e suas caractersticas analisadas.
Esta tarefa ocorre nas fases de concepo e elaborao, e executada pelo
gerente de risco, com a ajuda de todos os outros papis da equipe de
desenvolvimento. Tem como entrada as atas de reunio, documentos de feedback,
plano de gerncia de qualidade, plano de gerncia de risco e sua sada o prprio
plano de gerncia de risco.

3.1.5.3 Realizar a anlise qualitativa de riscos

O processo de anlise qualitativa de riscos diz respeito priorizao de riscos
para anlise ou ao posterior com base em sua possibilidade de ocorrer ou no seu
impacto no projeto caso ocorra. Alm disto, outros fatores podem ser analisados,
como prazo, tolerncia, cronograma, escopo, etc.
Esta tarefa ocorre nas fases de concepo e elaborao e executada pelo
gerente de risco, tendo como entrada o plano de gerncia de risco e como sada o
prprio plano de gerncia de risco.

3.1.5.4 Realizar a anlise quantitativa de riscos

A anlise quantitativa a anlise numrica dos riscos encontrados para o
projeto. Ela realizada em cima dos riscos encontrados na fase de anlise
qualitativa, selecionando apenas os riscos realmente vlidos, e adicionando-os ao
projeto. Desta forma possvel estimar melhor os custos e prazos do projeto, as
probabilidades de que o projeto venha a ter xito, facilitando a tomada futura de
decises na presena da incerteza.
prprio plano de gerncia de risco e o plano de desenvolvimento de software.

48

3.1.5.5 Planejar resposta aos riscos

Os riscos encontrados durante o processo de gerncia de risco sempre
podem: ser aceitos (no evitar o risco), evitados (cancelar ou mudar parte do
projeto), gerenciados (criar caminhos alternativos quando houver o problema) ou
transferidos (terceirizar parte do projeto). O planejamento de respostas aos riscos
tem como objetivo listar todas as aes futuras relacionadas com os riscos
detectados.
prprio plano de gerncia de risco e o plano de desenvolvimento de software.

3.1.5.6 Monitorar e controlar riscos

um processo contnuo durante o desenvolvimento, de acompanhar
individualmente cada risco, verificar se est se tornando mais ou menos provvel e
se seus impactos no projeto mudaram.
gerente de risco, tendo como entrada sempre o plano de gerncia de risco e como
sada o prprio plano de gerncia de risco e o plano de desenvolvimento de
software.

49
Figura 19 - Diagrama de atividades da Gerncia de Risco na Fase de Concepo do

PAS no EPF Composer.



Figura 20 - Estrutura da Gerncia de Risco do PAS no EPF Composer.


50
3.1.6 Modelos de artefatos gerados

Artefato todo subproduto concreto gerado num processo de
desenvolvimento de software. Algumas das tarefas das gerncias propostas por este
trabalho tinham como sada alguns artefatos com o objetivo de manter o controle de
execuo das tarefas do gerente durante o processo. Segundo Montenegro (2008),
so eles que regulam as atividades desenvolvidas no ambiente de produo,
aplicao e execuo do produto; regulam a relao da equipe com o cliente; e, as
demais reas de especializao.
A figura 21 mostra os modelos de artefatos presentes no PAS atravs do EPF
Composer, com destaque aos documentos que foram foco deste TCC: modelos de
Documento de Ambiente, Plano de Gerncia de Configurao, Plano de Gerncia de
Qualidade, Plano de Gerncia de Recursos Humanos e Plano de Gerncia de Risco.

Figura 21 - Produtos de Trabalho descritos pelo PAS no EPF Composer, com
destaque para os novos documentos criados ou estendidos durante este TCC.


51
Assim, os modelos de documentos

2
criados ou estendidos para complementar
as atividades de gerncia do PAS foram:

3.1.6.1 Modelo de documento de ambiente

Este foi o nico documento que j estava presente na verso atual do PAS. O
gerente de projetos responsvel pela edio do Documento de Ambiente. O
trabalho feito foi a padronizao deste documento, e a insero de tpicos que
contemplem a gerncia de Ambiente. Desta forma, caso a gerncia de ambiente no
seja utilizada em algum projeto utilizando a verso do PAS com extenso para
Gerncias, o Gerente de Projetos ainda poder realizar tarefas relacionadas com
ambiente que esto contidas neste modelo, e tambm so de responsabilidade do
seu papel.
O documento gerado a partir deste modelo registrar uma lista de sistemas,
ferramentas e tecnologias, a sua forma de uso, manuteno e configurao, para
que todas as iteraes estejam suportadas com a especificao necessria para o
desenvolver das atividades da equipe.
Sua estrutura inspirada na documentao equivalente da disciplina de Ambiente
do RUP.

3.1.6.2 Modelo de plano de gerncia de configurao
3

O modelo de plano de gerncia foi um dos documentos criados para este
trabalho. Sua estrutura inspirada nos padres da Gerncia de Configurao e
Mudana do RUP.
O objetivo deste documento detalhar os planos da gerncia de
Configurao, as ferramentas que sero utilizadas, os mtodos e os aspectos dos
baselines que sero avaliados. Tambm so registrados relatrios de auditorias,
marcos e treinamentos.

2
Os apndices deste documento concentram os modelos de artefato criados para este trabalho.
3
Ver Apndice D
52
3.1.6.3 Modelo de plano de gerncia de qualidade

4

O modelo de plano de gerncia de qualidade desenvolvido para o PAS

baseado no Plano de Garantia de Qualidade, de responsabilidade do gerente de
projetos do RUP.
O documento gerado atravs do modelo de plano de qualidade ir descrever
com detalhes os objetivos do planejamento de qualidade para este projeto, como
ser organizado e como sero organizadas as tarefas. Alm disto, ser apresentada
neste documento a listagem de documentos necessrios para garantir a qualidade
do projeto, as guias de padres a serem seguidos, alm de planejar a auditoria e os
testes necessrios.

3.1.6.4 Modelo de plano de gerncia de recursos humanos
5

Nem o PMBOK nem o RUP oferecem modelos do plano de gerncia de
recursos humanos de um projeto. Desta forma, foi desenvolvido, atravs dos dados
necessrios especificados pelo PMBOK um modelo de plano de gerncia de
Recursos Humanos.
O objetivo do documento gerado a partir desde modelo fornecer
primeiramente ao gerente de recursos humanos um planejamento para suas aes
durante o projeto. Alm disto, este plano importante para a equipe, por conter
informaes sobre a organizao da equipe, contatos, hierarquia dentro do grupo,
facilitando desta forma o relacionamento interpessoal dos membros da equipe.
Tambm so enunciadas todas as responsabilidades dos membros da
equipe, o que facilita na tomada de decises, quando necessrio atribuir alguma
atividade para algum dos membros da equipe, sem se saber qual est realmente
mais disponvel. Alm disto, ao se substituir ou realocar um membro da equipe,
ficaro claras as atribuies do membro substitudo, agilizando o processo de
insero do novo membro.
O documento ainda trata de treinamentos e bonificaes que podem ocorrer
em ocasies especficas.

4
Ver Apndice A
5
Ver Apndice C
53
3.1.6.5 Modelo de plano de gerncia de risco

6

O modelo de plano de gerencia risco adicionado ao PAS para este projeto foi
inspirado no Plano de Gerenciamento de Riscos, atribudo ao Gerente de Projetos
do RUP.
O objetivo do plano de gerncia de risco so organizar a gerncia de risco
durante o projeto, registrar todos os riscos encontrados, as tarefas e estratgias
usadas na conteno de risco, atribuio de responsabilidades e as ferramentas a
serem usadas para este fim.

6
Ver Apndice B
54
4 CONSIDERAES FINAIS

Atravs deste trabalho possibilitou-se verificar que possvel estender o
Processo Acadmico Simplificado - PAS, criando um processo com um timo nvel
de gerenciamento, ou mesmo at adicionar outras funcionalidades que venham a
cobrir uma necessidade especfica de uma equipe, ramo ou situao especial.
Foi necessrio inicialmente conhecer bem os elementos desta pesquisa: o
PAS, o EPF e as gerncias. O PAS um processo relativamente novo, criado em
2006, e por isto, ainda possui pouco material para pesquisa. Temos apenas artigos e
algumas monografias.
Desta forma foi necessrio um estudo aprofundado da documentao
encontrada e do prprio processo, para assim entender a sua diviso de fases,
atividades, papis, artefatos, diagramas, etc.
Quanto ao estudo do EPF, os avanos foram melhores. Por ser desenvolvido
pela conhecida Eclipse Foundation, o EPF Composer possui ampla documentao
disponvel, manuais, artigos e muitos trabalhos relacionados, ampliando o leque de
possibilidades para a pesquisa. Apesar de no haver muitas publicaes em idioma
portugus brasileiro, o contedo disponvel na Internet, suficiente para pesquisa e
aprendizado.
As gerncias escolhidas para este trabalho causaram um pouco de trabalho
para a coleta de dados, somente pelo fato que os principais processos disponveis
no mercado no abrangem todas as cinco reas de conhecimento escolhidas de
uma vez s. Desta forma, foi necessria a consulta em diversas fontes de pesquisa,
que trouxeram importantes informaes sobre os temas abordados. Assim, foi
possvel estender o PAS com as atividades das gerncias de Ambiente,
Configurao, Qualidade, Recursos Humanos e Risco.
A estrutura original do PAS foi preservada, foram apenas adicionados novos
itens organizados separadamente. Estes novos itens de gerncia so do tipo
opcionais, indicando que o PAS pode continuar sendo usado como era antes, e,
caso se faa necessrio, as novas funes de gerncia podem ser utilizadas. Assim,
espera-se que aps um perodo de testes desta soluo, esta verso do PAS
estendida venha at a substituir a atual verso publicada do PAS no website do
IFRN.

55
5 TRABALHOS FUTUROS

A realizao deste trabalho trouxe melhorias para o PAS, deixando o
processo em um novo nvel de maturidade de gerenciamento, se usadas as mtricas
de modelos de qualidade de processo como o CMMI ou MPS.BR. Foram
adicionadas cinco novas gerncias, que, em conjunto com a gerncia de projetos j
existente, formam uma base forte de desenvolvimento, que tenta ajudar na gerao
de mais qualidade e eficcia de produtos e processos de software.
O que ainda pode ser feito a comprovao da eficcia e efetividade destas
novas gerncias em projetos gerenciados reais. Isto traria uma consolidao e
aceitao maior deste modelo, confirmando os estudos realizados neste trabalho.
Porm, isto no tudo, ainda h muito a ser feito. O PMBOK, por exemplo,
retrata outras reas do conhecimento no exploradas por este trabalho, mas que
representariam tambm um ganho para a comunidade cientfica ao serem
implementadas junto ao PAS. Dentre estas reas, podemos citar:
a) Gerncia de Integrao do Projeto: busca melhorar a integrao entre as
partes de um projeto, para garantir que todas elas funcionem juntas.
b) Gerncia de Escopo: a rea que se foca em fazer com que um projeto atinja
os objetivos inicias, e somente eles, no se desviando dos objetivos
inicialmente projetados.
c) Gerncia de Tempo: uma gerncia especfica para trabalhar as questes de
prazos, garantindo assim que o projeto no tenha atrasos e cumpra todo o
cronograma de atividades.
d) Gerncia de Custos: gerencia o planejamento, estimativas, oramentos e
controle de custos de um projeto at sua concluso.
e) Gerncia de Aquisies: realiza do gerenciamento de todas as compras e
contrataes necessrias a um projeto, bem como a administrao de seus
fornecedores e executores.
f) Gerncia de Comunicaes: inclui os processos necessrios para assegurar
que as informaes de um projeto sejam geradas, coletadas, distribudas,
armazenadas, recuperadas e organizadas de maneira apropriada.
Desta forma, pode-se concluir que esta rea da engenharia de software
muito rica, e deixa ainda muitas possibilidades em aberto para novos pesquisadores
que desejem aprofundamento.
56
REFERNCIAS

ALEIXO, Fellipe A; MINORA, Leonardo A; PONTES, Bruno P. Processo acadmico
simplificado: um processo de software. Revista Holos, Natal: Instituto Federal de
Educao, Cincia e Tecnologia do Rio Grande do Norte, dez. 2006.

COELHO, Keivilany Janielle de Lima. Instanciao do processo acadmico
simplificado no Eclipse process framework. Trabalho de Concluso de Curso
(Graduao em Tecnologia em Desenvolvimento de Software) Instituto Federal de
Educao, Cincia e Tecnologia do Rio Grande do Norte, Natal, 2009.

ECLIPSE, Process Framework Project (EPF) Composer. Version 1.5.0.4. 2009.
Disponvel em: <http://www.eclipse.org/epf/>. Acesso em: 10 jul. 2011.

HAUMER, P. Overview to Eclipse framework composer. Eclipse Foundation, 2007

HELDMAN, Kim. Gerncia de projetos: guia para o exame oficial do PMI. 2. ed. Rio
de Janeiro: Editora Campus, 2003.

MARTINS, Jos Carlos Cordeiro. Gerenciando projetos de desenvolvimento de
software com PMI, RUP e UML. 2. ed. Rio de Janeiro : Brasport, 2005.

MONTENEGRO, Moreno M. D. Estudo de caso aplicando planejamento e
gerncia de projetos no processo acadmico simplificado. Trabalho de
Concluso de Curso (Graduao em Tecnologia em Desenvolvimento de Software)
Instituto Federal de Educao, Cincia e Tecnologia do Rio Grande do Norte,
Natal, 2008.

PROCESSO Acadmico Simplificado. Natal: IFRN, 2006. Disponvel em:
<www.datinf.cefetrn.br/cursos/superiores/praticas/pas> Acesso em: 10 de jul. 2011.

PONTES, Bruno Pereira. SIGES: Um Estudo De Caso Aplicando O Processo
Acadmico Simplificado (PAS). Trabalho de Concluso de Curso (Graduao em
Tecnologia em Desenvolvimento de Software). Natal: IFRN, 2007.

PRESSMAN R.S., Engenharia de software. 5. ed. Rio de Janeiro: McGraw Hill,
2002.

RATIONAL Unified Process: viso geral. Disponvel em: <http://wthreex.com/rup>.
Acesso em: 10 jul. 2011.

SILVA, Lucilvan Freitas. Extenso do processo acadmico simplificado - PAS,
para implementao das tcnicas de TDD e planning poker. Trabalho de
concluso de Curso (Graduao em Tecnologia em Anlise e Desenvolvimento de
Sistemas). Instituto Federal de Educao, Cincia e Tecnologia do Rio Grande do
Norte, Natal, 2011.

SOMMERVILLE, Ian. Engenharia de software. 8. ed. So Paulo: Pearson Addison-
Wesley, 2007.

57
PROJECT MANAGEMENT INSTITUTE (PMI). Um guia do conjunto de

conhecimentos em gerenciamento de projetos (guia PMBOK). 3. ed. Project
Management Institute, inc, 2004.
58
APENDICE A Modelo de plano de gerncia de qualidade

<Nome do Projeto>
Plano de Gerncia de Qualidade

[Observao: O texto em azul exibido entre colchetes e em itlico (style=InfoBlue) foi includo
para orientar o autor e deve ser excludo antes da publicao do documento. Qualquer
pargrafo inserido aps esse estilo ser definido automaticamente como normal
(estilo=BodyText).]

Histrico da Reviso
Data Verso Descrio Autor
<dd/mmm/aa> <x.x> <detalhes> <nome>

1. Introduo
[A introduo do Plano de Garantia de Qualidade fornece uma viso geral de todo o
documento. Ela contm a finalidade, o escopo, as definies, os acrnimos, as abreviaes,
as referncias e a viso geral deste Plano de Garantia de Qualidade.]
1.1 Finalidade
[Especifique a finalidade deste Plano de Garantia de Qualidade.]
1.2 Escopo
[Uma breve descrio do escopo deste Plano de Garantia de Qualidade; a que Projetos ele
est associado e tudo o mais que seja afetado ou influenciado por este documento.]
1.3 Definies, Acrnimos e Abreviaes
[Esta subseo fornece as definies de todos os termos, acrnimos e abreviaes
necessrias adequada interpretao do Plano de Garantia de Qualidade. Essas
informaes podem ser fornecidas mediante referncia ao Glossrio do projeto.]
1.4 Referncias
[Esta subseo fornece uma lista completa de todos os documentos mencionados no Plano
de Garantia de Qualidade. Identifique cada documento por ttulo, nmero do relatrio (se
aplicvel), data e organizao de publicao. Especifique as fontes a partir das quais as
referncias podem ser obtidas. Essas informaes podem ser fornecidas mediante referncia
59
a um apndice ou outro documento. Para o Plano de Garantia de Qualidade, essas

referncias devero incluir:
Plano de Documentao
Plano de Mtricas
Plano de Teste
Plano de Desenvolvimento de Software
Plano de Resoluo de Problemas
Plano de Gerenciamento de Configurao
Plano de Gerenciamento de Subcontratantes
Plano de Gerenciamento de Riscos]
1.5 Viso Geral
[Esta subseo descreve o que o restante do Plano de Garantia de qualidade contm e
explica como o documento est organizado.]
2. Objetivos de Qualidade
[Esta seo precisa fazer referncia seo da Especificao de Requisitos de Software que
aborda os requisitos de qualidade.]
3. Gerenciamento
3.1 Organizao
[Descreva a estrutura da organizao responsvel pela Garantia de Qualidade.]
3.2 Tarefas e Responsabilidades
[Descreva as vrias tarefas de Garantia de Qualidade que sero executadas neste projeto e
indique como elas sero sincronizadas com os marcos principais e secundrios do projeto.
Essas tarefas incluiro:
Revises Conjuntas
Auditorias de Processo
Revises de Processo
Auditorias do Cliente
Para cada tarefa, identifique o membro da equipe responsvel por sua execuo.]
4. Documentao
[Inclua o artefato Plano de Documentao fazendo referncia a ele.
Alm disso, liste a documentao mnima que dever ser produzida durante o projeto para
assegurar que o produto de software que for desenvolvido satisfaa os requisitos. O conjunto
mnimo sugerido :
Plano de Desenvolvimento de Software (SDP)
Plano de Teste
Planos de Iterao
Especificao de Requisitos de Software (SRS)
Documento de Arquitetura de Software
Documentao do Usurio (por exemplo, manuais, guias)
60
Plano de Gerenciamento de Configurao

Fornea ponteiros para o Caso de Desenvolvimento a fim de mostrar em que momento do
processo a adequao desses documentos ser avaliada.]
5. Padres e Guias
[Esta seo faz referncia a padres e guias que se espera que sejam usados no projeto e
aborda como a conformidade com esses padres e guias dever ser determinada. Os
artefatos relevantes so includos atravs de referncias a eles. O conjunto sugerido :
Caso de Desenvolvimento
Guia de Modelagem de Negcios
Guia de Interface do Usurio
Guia de Modelagem de Caso de Uso
Guia de Design
Guia de Programao
Guia de Teste
Manual de Guia de Estilo]
6. Mtricas
[Esta seo descreve as mtricas do produto, do projeto e do processo que devero ser
capturadas e monitoradas para o projeto. Essas mtricas geralmente so abordadas
incluindo-se o artefato Plano de Mtricas atravs de referncias a ele.]
7. Plano de Reviso e de Auditoria
[Esta seo contm o Plano de Reviso e de Auditoria. Esse plano especifica a programao,
os recursos, os mtodos e os procedimentos a serem usados na conduo de revises e
auditorias do projeto. O plano descreve os vrios tipos de revises e auditorias a serem
executados durante o projeto e identifica todas as agncias externas que se espera que
aprovem ou regulem os artefatos produzidos pelo projeto.
Esta seo deve identificar:
Tarefas de Reviso e de Auditoria
Descreva brevemente cada tipo de reviso e de auditoria que ser executado no projeto.
Para cada tipo, identifique os artefatos do projeto que sero alvos da reviso ou da
auditoria. Entre eles, podero estar includas: Revises Tcnicas e de Gerenciamento
Conjuntas de Cliente e Desenvolvedor, Revises e Auditorias de Processo, Auditorias
de Cliente, Revises Tcnicas e de Gerenciamento Internas.
Programao
Descreva detalhadamente aqui a programao das revises e auditorias. Ela dever
conter as revises e auditorias programadas para os marcos do projeto, assim como as
revises geradas pela liberao de artefatos do projeto. Esta subseo poder fazer
referncia ao projeto ou ao plano de iterao.
Organizao e Responsabilidades
Liste aqui as pessoas ou grupos especficos que estaro envolvidos em cada uma das
atividades de reviso e de auditoria identificadas. Descreva brevemente as tarefas e as
61
responsabilidades de cada um deles. Alm disso, liste todas as agncias externas que
se espera que aprovem ou regulem qualquer produto do projeto.
Resoluo de Problemas e Ao Corretiva
Esta subseo descreve os procedimentos necessrios para reportar e solucionar
problemas identificados durante as revises e auditorias do projeto. Poder ser feita
referncia ao Plano de Resoluo de Problemas.
Ferramentas, Tcnicas e Metodologias
Descreva aqui todas as ferramentas, tcnicas ou metodologias que devero ser usadas
para executar as atividades de auditoria e de reviso identificadas nesse plano. Voc
deve descrever o processo explcito a ser seguido para cada tipo de reviso ou de
auditoria. necessrio que sua organizao tenha um Manual de Procedimentos de
Reviso e de Auditoria padro, que poder ser consultado. Essas descries de
procedimentos tambm devem abordar a coleta, o armazenamento e o arquivamento
dos Registros de Reviso do projeto.
Um conjunto sugerido de revises e auditorias que poder ser usado como uma base para o
planejamento o seguinte:
Reviso de Requisitos (remete tradicional Reviso de Especificao de Software)
Reviso de Arquitetura (remete tradicional Reviso de Design Preliminar)
Reviso de Design (remete tradicional Reviso Crtica de Design)
Auditoria da configurao funcional (a fim de verificar se todos os requisitos da SRS
foram atendidos)
Auditoria da configurao fsica (a fim de verificar se o software e sua documentao
esto completos e prontos para serem liberados)
Auditorias de processo
Revises de processo
Revises gerenciais (Reviso de Aprovao do Projeto, Reviso de Planejamento do
Projeto, Reviso do Plano de Iterao, Reviso do Projeto PRA)
Revises de post-mortem (Reviso de Aceitao da Iterao, Reviso dos Marcos de
Ciclo de Vida, Reviso de Aceitao do Projeto).]
8. Avaliao e Teste
[Esta seo faz referncia ao Plano de Desenvolvimento de Software (seo Plano de
Avaliao) e ao Plano de Teste.]
9. Resoluo de Problemas e Ao Corretiva
[Esta seo faz referncia ao Plano de Resoluo de Problemas.]
10. Ferramentas, Tcnicas e Metodologias
[Uma lista de todas as ferramentas, tcnicas e metodologias que devero ser usadas durante
a execuo das atividades de Garantia de Qualidade.]
11. Gerenciamento de Configurao
[Esta seo faz referncia ao Plano de Gerenciamento de Configurao.]
62
12. Controles de Fornecedor e de Subcontratante

[Esta seo faz referncia ao Plano de Gerenciamento de Subcontratantes.]
13. Registros de Qualidade
[Descries dos vrios registros de qualidade que sero mantidos durante o projeto, incluindo
como e onde cada tipo de registro ser armazenado e por quanto tempo.]
14. Treinamento
[Liste aqui todas as atividades necessrias para que a equipe do projeto atenda s
necessidades do Plano de Garantia de Qualidade.]
15. Gerenciamento de Riscos
[Esta seo faz referncia ao Plano de Gerenciamento de Riscos.]

63
APENDICE B Modelo de plano de gerncia de risco

<Nome do Projeto>
Plano de Gerncia de Risco

[Observao: O texto em azul exibido entre colchetes e em itlico (style=InfoBlue) foi includo para
orientar o autor e deve ser excludo antes da publicao do documento. Qualquer pargrafo inserido
aps esse estilo ser definido automaticamente como normal (estilo=BodyText).]
Histrico da Reviso
dd/mm/aaaa 1.0 <breve descrio da reviso> <autores da reviso>
dd/mm/aaaa 1.1 <breve descrio da reviso> <autores da reviso>

1. Introduo
[A introduo do Plano de Gerenciamento de Riscos deve fornecer uma viso geral de todo o
documento. Ela deve incluir a finalidade, o escopo, as definies, os acrnimos, as abreviaes, as
referncias e a viso geral deste Plano de Gerenciamento de Riscos.]
1.1 Finalidade
[Especifique a finalidade deste Plano de Gerenciamento de Riscos.]
1.2 Escopo
[Uma breve descrio do escopo deste Plano de Gerenciamento de Riscos; a que Projeto(s) ele est
associado e tudo o mais que seja afetado ou influenciado por este documento.]
[Esta subseo deve fornecer as definies de todos os termos, acrnimos e abreviaes
necessrias adequada interpretao do Plano de Gerenciamento de Riscos.]
1.4 Referncias
[Esta subseo deve fornecer uma lista completa de todos os documentos mencionados em qualquer
outra parte do Plano de Gerenciamento de Riscos. Cada documento dever ser identificado por ttulo,
nmero do relatrio (se aplicvel), data e organizao de publicao. Especifique as fontes a partir
das quais as referncias podem ser obtidas. Essas informaes podero ser fornecidas fazendo-se
referncia a um apndice ou a outro documento.]
1.5 Viso Geral
[Esta subseo descreve o que o restante do Plano de Gerenciamento de Riscos contm e explica
como o documento est organizado.]
2. Resumo dos Riscos
64
[Uma breve descrio do projeto e um resumo dos riscos gerais envolvidos nele.]
3. Tarefas de Gerenciamento de Riscos
[Uma breve descrio das tarefas de gerenciamento de riscos a serem executadas durante o projeto.
Nesta seo, voc deve descrever o seguinte:
O mtodo a ser usado para identificar riscos e como a lista de riscos ser analisada e
priorizada.
As estratgias de gerenciamento de riscos que sero usadas, incluindo estratgias de
diminuio, impedimento e/ou preveno para os riscos mais significativos ("dez principais
riscos").
Como o status de cada risco significativo e suas atividades de diminuio sero
monitoradas.
Reviso dos riscos e programaes de relatrios. Uma reviso dos riscos dever fazer
parte da reviso de aceitao de cada iterao/fase.]

4. Organizao e Responsabilidades
[Uma lista dos grupos e pessoas especficos que estaro envolvidos nas atividades de gerenciamento
de riscos do projeto e uma descrio das tarefas e responsabilidades de cada um.]
5. Oramento
[O oramento disponvel para o gerenciamento dos riscos do projeto (quando essas informaes
ainda no estiverem includas no oramento geral do projeto).]
6. Ferramentas e Tcnicas
[Uma lista das ferramentas e/ou tcnicas que sero usadas para armazenar informaes sobre riscos,
avaliar riscos e rastrear os status dos riscos ou gerar relatrios de gerenciamento de riscos.]
7. Itens de Risco a Serem Gerenciados
[Uma lista dos itens de risco que foram identificados. Poder ser um link para Artefato: Lista de
Riscos do projeto.
Uma das melhores prticas da indstria publicar e manter visvel uma lista dos "Dez principais"
riscos considerados significativos o suficiente para que sejam despendidos recursos para gerenci-
los no projeto. Voc poder manter uma lista maior se a prtica organizacional ou o contrato assim
exigir.
Para cada risco listado, so identificados indicadores de que o risco est se concretizando e
estratgias de diminuio, impedimento ou preveno. Alguns riscos tambm exigiro uma descrio
da ao contingente caso venham a se concretizar.]
65
APENDICE C Modelo de plano de gerncia de recursos humanos

<Nome do Projeto>
Plano de Gerncia de Recursos Humanos

(estilo=BodyText).]
Histrico da Reviso

1. Introduo
[A introduo do Plano de Gerncia de Recursos Humanos fornece uma viso geral de
todo o documento. Ela contm a finalidade, o escopo, as definies, os acrnimos, as
abreviaes, as referncias e a viso geral deste Plano de Garantia de Qualidade.]
1.1 Finalidade
[Especifique a finalidade deste Plano de Gerncia de Recursos Humanos.]
1.2 Escopo
[Uma breve descrio do escopo deste Plano de Gerncia de Recursos Humanos; a que
Projetos ele est associado e tudo o mais que seja afetado ou influenciado por este
documento.]
[Esta subseo fornece as definies de todos os termos, acrnimos e abreviaes
necessrias adequada interpretao do Plano de Gerncia de Recursos
Humanos. Essas informaes podem ser fornecidas mediante referncia ao Glossrio do
projeto.]
1.4 Referncias
[Esta subseo fornece uma lista completa de todos os documentos mencionados no Plano
de Gerncia de Recursos Humanos. Identifique cada documento por ttulo, nmero do
relatrio (se aplicvel), data e organizao de publicao. Especifique as fontes a partir das
66
quais as referncias podem ser obtidas. Essas informaes podem ser fornecidas mediante
referncia a um apndice ou outro documento.]
1.5 Viso Geral
[Esta subseo descreve o que o restante do Plano de Gerncia de Recursos
Humanos contm e explica como o documento est organizado.]
2. Organograma do Projeto
[Inserir a imagem de um organograma da hierarquia de trabalho da Equipe. Apresentar
Equipes, subequipes, divises, gerentes, subordinados, e demais relaes de trabalho.]

3. Diretrio da Equipe do Projeto (Team Directory)
[Inserir um quadro de informaes da Equipe, para identificar os componentes mais
facilmente, bem como para facilitar o contato.]
N Nome rea E-mail Telefone
1 [nome] [Designer] [endereo de e-
mail]
[telefone]
2 [nome] [Gerente de RH] [endereo de e-
mail]
[telefone]
3 [nome] [Gerente de
Qualidade]
[endereo de e-
mail]
[telefone]

4. Matriz de Responsabilidades

N Nome rea
Planos
E
s
c
o
p
o

C
u
s
t
o

Q
u
a
l
i
d
a
d
e

R
H

D
e
s
i
g
n

[
o
u
t
r
o
s
]

1 [nome] [Analista] R A S
67
RH]
A R R
Qualidade]
S R A
R Responsvel / A Apoio / S - Suplente
5. Novos recursos, realocao e substituio de membros
[Descrever as regras para entrada de novos recursos no projeto e para mudanas no corpo
de membros envolvidos.]

6. Treinamento
[Descrever como ser o processo de treinamento para a equipe, em funes necessrias
durante o processo de desenvolvimento.]
7. Avaliao de resultados da equipe de projeto
[Definir a programao das avaliaes de resultados de acordo com o sistema de avaliao
utilizado (interno, externo) e a escala de medio de resultado (0 a 10, conceitual).]
8. Bonificao
[Descrever a bonificao prometida aos membros de acordo com os resultados obtidos nas
avaliaes.]
9. Frequncia de Avaliao consolidada dos resultados da Equipe
[Definir a frequncia das avaliaes a serem realizadas]
10. Alocao Financeira para o gerenciamento de RH
[Definir , caso exista, custos do treinamento, impresso, equipamentos, que no estejam
previstos no projeto]
11. Administrao do Plano de Gerenciamento de RH
11.1 Responsvel pelo plano
[Listar os responsveis]
11.2 Frequncia de atualizao do plano de gerenciamento de RH
[O plano sofrer alteraes sempre que mudanas forem necessrias.]
12. Outros assuntos relacionados ao gerenciamento de RH do projeto
no previstos neste plano
[Informaes sobre o patrocinador, sobre permisses do gerente, e outros itens no previstos
neste documento.]

68
APENDICE D Modelo de plano de gerncia de configurao

<Nome do Projeto>
Plano de Gerncia de Configurao

(estilo=BodyText).]

Histrico da Reviso

1. Introduo
[A introduo do Plano de Gerenciamento de Configurao oferece uma viso geral de
todo o documento. Ela inclui a finalidade, o escopo, as definies, os acrnimos, as
abreviaes, as referncias e uma viso geral deste Plano de Gerenciamento de
Configurao.]
1.1 Finalidade
[Especifique a finalidade deste Plano de Gerenciamento de Configurao.]
1.2 Escopo
[Uma breve descrio do escopo deste Plano de Gerenciamento de Configurao; o
modelo ao qual ele est associado e tudo o que afetado ou influenciado por este
documento.]
[Esta subseo apresenta as definies de todos os termos, acrnimos e abreviaes
necessrios para a correta interpretao do Plano de Gerenciamento de
Configurao. Essas informaes podem ser fornecidas mediante referncia ao Glossrio
do projeto.]
1.4 Referncias
[Esta subseo apresenta uma lista completa de todos os documentos mencionados
no Plano de Gerenciamento de Configurao. Identifique os documentos por ttulo, nmero
69
de relatrio (se aplicvel), data e organizao responsvel pela publicao. Especifique as

fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser
fornecidas por um anexo ou outro documento.]
1.5 Viso Geral
[Esta subseo descreve o contedo restante do Plano de Gerenciamento de
Configurao e explica como o documento est organizado.]
2. Gerenciamento de Configurao de Software
2.1 Organizao, Responsabilidades e Interfaces
[Descreva quem ser o responsvel pela execuo das diversas atividades de
Gerenciamento de Configurao (CM) descritas na Disciplina Processo de CM.]
2.2 Ferramentas, Ambiente e Infraestrutura
[Descreva o ambiente de computao e as ferramentas de software a serem utilizadas para
desempenhar as funes de CM em todo o ciclo de vida do projeto ou produto.
Descreva as ferramentas e os procedimentos necessrios utilizados para o controle de
verso dos itens de configurao gerados no ciclo de vida do projeto ou produto.
As questes envolvidas na configurao do ambiente de CM incluem:
tamanho previsto dos dados do produto
distribuio da equipe do produto
localizao fsica dos servidores e clientes]
3. O Programa de Gerenciamento de Configurao
3.1 Identificao da Configurao
Mtodos de Identificao
[Descreva como os artefatos do projeto ou produto devem ser nomeados, marcados e
numerados. O esquema de identificao deve abranger o hardware, o software do sistema,
os produtos de terceiros (COTS) e todos os artefatos de desenvolvimento de aplicativos
listados na estrutura de diretrios do produto; por exemplo, planos, modelos, componentes,
software de teste, resultados e dados, executveis e assim por diante.]
Baselines do Projeto
[As baselines funcionam como um padro oficial no qual os trabalhos subsequentes so
baseados. Somente mudanas autorizadas podem ser efetuadas nas baselines.
Descreva em que pontos do ciclo de vida do projeto ou produto as baselines devem ser
estabelecidas. As baselines mais comuns devem ser definidas ao final de cada uma das
fases de Iniciao, Elaborao, Construo e Transio. Elas tambm podem ser geradas no
final de iteraes ocorridas dentro das vrias fases ou com freqncia ainda maior.
Descreva quem autoriza uma baseline e o que ela contm.]
3.2 Controle de Configurao e Mudana
Processamento e Aprovao de Solicitaes de Mudana
70
[Descreva o processo pelo qual os problemas e as mudanas so submetidos, revisados e

dispostos.]
Comit de Controle de Mudana (CCB)
[Descreva a participao e os procedimentos para processar solicitaes e aprovaes de
mudana a serem seguidos pelo CCB.]
3.3 Estimativa do Status de Configurao
Processo de Armazenamento de Mdia e Liberao do Projeto
[Descreva as polticas de reteno e os planos de backup, erros irreversveis e recuperao.
Descreva tambm como a mdia deve ser mantida - on-line, off-line, tipo de mdia e formato.
O processo de liberao deve descrever o contedo do release, a quem ele se destina e se
h quaisquer problemas conhecidos e instrues de instalao.]
Relatrios e Auditorias
[Descreva o contedo, o formato e a finalidade dos relatrios e auditorias de configurao
solicitados.
Os relatrios so usados para avaliar a "qualidade do produto" em qualquer fase do ciclo de
vida do projeto ou produto. Os relatrios sobre defeitos com base em solicitaes de
mudana podem fornecer alguns indicadores de qualidade proveitosos e, dessa forma, alertar
a administrao e os desenvolvedores para determinadas reas prioritrias do
desenvolvimento. Geralmente os defeitos so classificados por prioridade (alta, mdia e
baixa) e podem ser reportados com base nos seguintes aspectos:
Vencimento (Relatrios Baseados em Perodos): H quanto tempo defeitos de diversos
tipos esto pendentes? Qual o "tempo de retardo" de quando so encontrados defeitos
no ciclo de vida em comparao com o tempo necessrio para corrigi-los?
Distribuio (Relatrios Baseados em Contagens): Existem quantos defeitos nas
diversas categorias por proprietrio, prioridade ou estado de correo?
Tendncia (Relatrios Relacionados a Perodos e Contagens): Qual o nmero
acumulado de defeitos encontrados e corrigidos no decorrer do tempo? Qual a
classificao dos defeitos detectados e corrigidos? Qual a "lacuna de qualidade" em
termos de defeitos pendentes versus defeitos corrigidos? Qual a mdia de tempo de
correo de um defeito?]
4. Marcos
[Identifique os marcos internos e de cliente relacionados ao esforo de CM do projeto ou
produto. Esta seo deve incluir detalhes sobre quando o Plano CM deve ser atualizado.]
5. Treinamento e Recursos
[Descreva as ferramentas de software, o pessoal e o treinamento necessrios para
implementar as atividades de CM especificadas.]
6. Controle de Software de Subcontratados e Fornecedores
[Descreva de que forma o software desenvolvido fora do ambiente do projeto ser
incorporado.]

TCC Ari Barreto de Oliveira

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TCC Ari Barreto de Oliveira

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA

DO RIO GRANDE DO NORTE

ARI BARRETO DE OLIVEIRA

ARI BARRETO DE OLIVEIRA

2.3.2 Gerncia de configurao 29

3.1.5.6 Monitorar e controlar riscos 48

Management Institute) que enfoca o processo de gerenciamento, tambm tm

alunos de forma simples e direta, e ainda assim apresentar a estes metodologias

Para a cincia, a extenso do PAS representa a elevao do nvel de um

2 PROCESSOS DE SOFTWARE (PAS)

O Processo de desenvolvimento em si dividido em quatro fases:

Atravs da navegao no PAS por papis, possvel conhecer cada um dos

A disciplina de requisitos tem como objetivo fazer a coleta de todas das

2.1.1.1.2 Anlise e projeto

Neste primeiro momento, a disciplina de anlise, ir trabalhar em cima dos

A tarefa destinada a disciplina de implementao e testes simples, trata-se

A disciplina de gerncia de processo nesta primeira fase tem 15 tarefas

A arquitetura tambm necessita estar definida e validada, pronta para o incio

Esta disciplina tem a responsabilidade de escolher os casos de uso que sero

A Anlise de Projetos a disciplina que recebe os documentos gerados na

Os implementadores seguiro os passos que lhes foram dados,

A gerncia de processos nesta fase ir revisar o plano de desenvolvimento j

registrando seus resultados. A gerencia tambm deve suportar o ambiente da fase

Nesta fase, a disciplina de Requisitos, ir detalhar casos de uso restantes.

Segundo Pontes (2007), a disciplina de Anlise e Projeto transforma em

A equipe de implementao dever buscar atingir seus objetivos de forma

desnecessrio. Deve ser desenvolvido de forma interativa e incremental um produto

A gerncia deve monitorar o desenvolvimento, identificando

O objetivo desta disciplina na fase de validao verificar principalmente se

2.1.1.6.2 Anlise e projeto

A disciplina de anlise, assim como a de requisitos, deve verificar se

A gerncia de processo da quarta fase do PAS desempenha seu papel dando

que no existe uma terminologia ou linguagem comum entre os modelos, o que

Figura 6 - Relacionamentos do Papel do Gerente de projetos do PAS.

2.3.1 Gerncia de ambiente

2.4.4 Gerncia de recursos humanos

3 EXTENSO DO PAS PARA ATIVIDADES DE GERNCIA

Figura 8 - Papeis do PAS, com destaque para os papeis de gerncia.

Figura 9 - Estrutura original de Pacotes de Contedo do PAS no EPF Composer.

c) Verificar se as ferramentas esto instaladas e prontas para uso;

Figura 11 - Diagrama de Atividades da Gerncia de Ambiente, na fase de

Fonte: OLIVEIRA (2011).

3.1.2 Gerncia de configurao

Esta tarefa ocorre apenas na fase de concepo e executada pelo gerente

3.1.2.5 Monitorar e reportar status

Figura 13 - Diagrama de Atividades da Gerncia de Configurao na fase de

Fonte: OLIVEIRA (2011).

3.1.3 Gerncia de qualidade

Esta tarefa ocorre nas quatro fases de desenvolvimento e executada pelo

Figura 16 - Estrutura da Gerncia de Qualidade do PAS no EPF Composer.

3.1.4.2 Contratar ou mobilizar equipe

Fonte: OLIVEIRA (2011).

Figura 18 - Estrutura da Gerncia de Recursos Humanos do PAS no EPF Composer.

Fonte: OLIVEIRA (2011).

3.1.5 Gerncia de risco

3.1.5.2 Identificao de riscos

Figura 19 - Diagrama de atividades da Gerncia de Risco na Fase de Concepo do

3.1.6 Modelos de artefatos gerados

Assim, os modelos de documentos

3.1.6.3 Modelo de plano de gerncia de qualidade

O modelo de plano de gerncia de qualidade desenvolvido para o PAS

3.1.6.5 Modelo de plano de gerncia de risco

PROJECT MANAGEMENT INSTITUTE (PMI). Um guia do conjunto de

APENDICE A Modelo de plano de gerncia de qualidade