Embed Size (px)
Citation preview
UNIVERSIDADE SÃO FRANCISCO
Curso de Engenharia de Computação
Bradley Felipe Zanoni Fonseca
Proposta de unificação das metodologias RUP e Scrum através de
sua releitura
Itatiba
2012
Bradley Felipe Zanoni Fonseca RA: 002200800014
Proposta de unificação das metodologias RUP e Scrum através de
sua releitura
Itatiba
2012
Monografia apresentada ao Curso de
Engenharia de Computação da
Universidade São Francisco como
requisito parcial para a obtenção do título
de Bacharel em Engenharia de
Computação.
Orientador: Prof. Rodrigo Luiz Nolli
Brossi
Dedico este trabalho aos meus
pais Ary e Angela, a minha irmã Yasmin
e ao meu irmão Kelvyn que me apoiaram
nesta etapa da vida. Dedico também a
Débora, que sempre esteve do meu lado
me dando forças, dedicação extensiva
também aos meus amigos.
AGRADECIMENTOS
Agradeço primeiramente a Deus, por estar sempre ao meu lado, e pelas oportunidades
e desafios propostos.
Agradeço aos meus pais, Ary e Angela, por tudo. Pelo apoio durante toda a vida,
assim como durante o Curso Universitário, pelas oportunidades que possibilitaram eu ser o
que sou hoje. Aos meus irmãos, Yasmin e Kelvyn, por sempre me apoiarem e pelo
companheirismo, agradecendo também aos meus avós, tios e primos.
Também quero agradecer a Débora, minha amada e companheira, pelo seu apoio,
dedicação, força e por estar sempre ao meu lado.
Ao meu professor, orientador e amigo, Rodrigo, agradeço pelo apoio durante o curso e
a realização deste trabalho. Também são dignos de agradecimento todos os professores, pelo
empenho e dedicação ao instruir os alunos, possibilitando um aperfeiçoamento profissional,
pessoal e intelectual, aproveito reiterar meu respeito pela profissão, sendo de muito prestigio.
Agradeço a todos os meus amigos, por estarem presentes em minha vida, me
auxiliando e apoiando. A aqueles amigos da universidade e do ônibus, agradeço por todos os
momentos, e pela troca de conhecimento e cultura.
"Você pode encarar um erro como uma besteira a ser esquecida, ou como um
resultado que aponta uma nova direção".
Steve Jobs
RESUMO
Será realizada uma revisão bibliográfica e avaliação das metodologias RUP e Scrum,
além do guia de gerenciamento de projetos PMBOK, sendo assim, com estes conceitos, será
elaborado uma proposta de unificação das metodologias RUP e Scrum, buscando ainda
atender o desenvolvimento de sistemas para Web e utilizando o mínimo de recursos,
possibilitando a produção de software com baixo custo para atender pequenas organizações
ou profissionais liberais.
Palavras-chave: Gerenciamento. Projetos. Software.
ABSTRACT
There will be a bibliographic review and evaluation of RUP and Scrum
methodologies, as well as guide PMBOK project management, so with these concepts will be
elaborated a proposal for unification of the RUP and Scrum methodologies, seeking to serve
the still developing systems for Web and using minimal resources, enabling the production of
software with low cost to meet small organizations or professionals.
KEY WORDS: Management. Projects. Software.
LISTA DE ILUSTRAÇÕES
FIGURA 1 – Mapeamento dos grupos de processos e as áreas de conhecimento do
PMBOK.................................................................................................... 18
FIGURA 2 – Grupo de processos de inicialização do PMBOK...................................... 19
FIGURA 3 – Grupo de processos de planejamento do PMBOK.................................... 20
FIGURA 4 – Grupo de processos de execução do PMBOK........................................... 22
FIGURA 5 – Grupo de processos de monitoramento e controle do PMBOK................ 23
FIGURA 6 – Grupo de processos de encerramento do PMBOK.................................... 24
FIGURA 7 – Grupos de processos de gerenciamento de projetos................................... 25
FIGURA 8 – Atividade dos grupos de processos durante o projeto............................... 25
FIGURA 9 – Resumo dos processos de gerenciamento de integração de processos e
atividades do PMBOK............................................................................. 27
FIGURA 10 – Exemplo de fluxo de trabalho principal................................................... 31
FIGURA 11 – Artefatos da disciplina de modelagem de negócios................................. 32
FIGURA 12 – Artefatos da disciplina de requisitos........................................................ 33
FIGURA 13 – Artefatos da disciplina de analise............................................................ 33
FIGURA 14 – Artefatos da disciplina de implementação............................................... 34
FIGURA 15 – Artefatos da disciplina de testes.............................................................. 34
FIGURA 16 – Artefatos da disciplina de distribuição..................................................... 35
FIGURA 17 – Artefatos da disciplina de configuração e gerenciamento de
mudanças.................................................................................................. 35
FIGURA 18 – Artefatos da disciplina de gerenciamento de projeto............................... 36
FIGURA 19 – Artefatos da disciplina de ambiente......................................................... 37
FIGURA 20 – Ciclo de vida do RUP.............................................................................. 39
FIGURA 21 – Arquitetura geral do RUP........................................................................ 40
FIGURA 22 – Produtos de trabalho do RUP.................................................................. 42
FIGURA 23 – Ciclo de vida do Scrum............................................................................ 45
FIGURA 24 – Ciclo de vida da metodologia Processo Unificado Ágil.......................... 49
FIGURA 25 – Grupo de processos de inicialização......................................................... 52
FIGURA 26 – Grupo de processos de planejamento....................................................... 53
FIGURA 27 – Planejamento da construção do projeto – Backlog.................................. 54
FIGURA 28 – Grupo de processos de construção........................................................... 55
FIGURA 29 – Grupo de processos de transição.............................................................. 56
FIGURA 30 – Grupo de processos de gerenciamento de projeto.................................... 57
FIGURA 31 – Benchmark dos principais processos e grupos......................................... 59
LISTA DE ABREVIATURAS E SIGLAS
RUP – Rational Unified Process
UML – Unified Modeling Language
ERP – Enterprise Resource Planning
PMBOK – Project Management Body of Knowledge
PMI – Project Management Institute
SUMÁRIO
1 INTRODUÇÃO........................................................................................................... 13
2 OBJETIVOS................................................................................................................ 14
3 METODOLOGIA....................................................................................................... 15
4 REVISÃO BIBLIOGRÁFICA.................................................................................. 16
4.1 GERENCIAMENTO DE PROJETOS...................................................................... 16
4.1.1 O guia de gerenciamento de projetos PMBOK....................................................... 17
4.1.2 Os grupos de processos de gerenciamento de projetos do PMBOK....................... 17
4.1.2.1 Processos de Iniciação.......................................................................................... 19
4.1.2.2 Processos de Planejamento................................................................................... 20
4.1.2.3 Processos de Execução......................................................................................... 21
4.1.2.3 Processos de Monitoramento e Controle.............................................................. 22
4.1.2.4 Processos de Encerramento................................................................................... 24
4.1.3 Integração entre os grupos e processos.................................................................... 24
4.2 ENGENHARIA DE SOFTWARE............................................................................. 27
4.2.1 Evolução da Engenharia de Software..................................................................... 28
4.2.2 Processo Unificado – RUP (Rational Unified Process)........................................... 29
4.2.2.1 Princípios do RUP................................................................................................ 29
4.2.2.2 Elementos do RUP............................................................................................... 30
4.2.2.3 Disciplinas do RUP.............................................................................................. 31
4.2.2.4 Ciclo de vida do RUP........................................................................................... 37
4.2.2.5 Arquitetura geral do RUP..................................................................................... 40
4.2.2.6 Produtos de trabalho do RUP............................................................................... 41
4.2.3 Desenvolvimento Ágil – Scrum............................................................................... 42
4.2.3.1 Princípios do Scrum.............................................................................................. 43
4.2.3.2 Ciclo de vida do Scrum......................................................................................... 44
5 AVALIAÇÃO QUALITATIVA E QUANTITATIVA ENTRE OS METODOS. 47
6 PROPOSTA DA UNIFICAÇÃO DAS METODOLOGIAS.................................... 49
6.1 PAPÉIS...................................................................................................................... 50
6.2 OS GRUPOS DE PROCESSOS DA METODOLOGIA PROCESSO
UNIFICADO ÁGIL...................... 51
6.2.1 Grupo de processos de inicialização........................................................................ 51
6.2.2 Grupo de processos de planejamento....................................................................... 52
6.2.3 Grupo de processos de construção........................................................................... 55
6.2.4 Grupo de processos de transição.............................................................................. 56
6.2.5 Grupo de processos de gerenciamento do projeto................................................... 57
6.3 BENCHMARK DOS PROCESSOS DA METODOLOGIA PROCESSO
UNIFICADO ÁGIL.......................................................................................................... 59
7 CONCLUSÃO............................................................................................................. 60
8 REFERENCIAS BIBLIOGRÁFICAS...................................................................... 62
ANEXOS......................................................................................................................... 63
ANEXO A – Documento de Especificação de Requisitos............................................... 64
ANEXO B – Documento de Especificações Técnicas...................................................... 66
ANEXO C – Documentação de Gerenciamento de Mudanças........................................ 70
13
1 INTRODUÇÃO
Hodiernamente a tecnologia da informação esta cada vez mais presente no dia a dia
das pessoas e empresas de todo o mundo, tecnologias estas que auxiliam na organização e
otimização de processos. Neste aspecto, companhias de grande e algumas de médio porte
investem muito na área, possibilitando melhoramentos no desempenho, o que converge em
um aumento dos lucros.
Desta forma, a maioria das fábricas de software focam em atender e fornecer soluções
à estas empresas que muito investem na tecnologia da informação. Para uso destes grandes
clientes existem os Sistemas Integrados de Gestão Empresarial, ou E.R.P. (Enterprise
Resource Planning), que basicamente integra todos os setores e dados do negócio, tornando
fácil a administração do todo.
Em contrapartida, os pequenos negócios e profissionais liberais, que estão presentes
em grande número no mercado, são desfavorecidos quanto a soluções de tecnologia da
informação, seja por falta de opção ou por valores elevados. No caso dos sistemas integrados
é raro encontrar para esses empreendimentos, restando a opção de utilizar pequenos
softwares, os quais devem ser adquiridos especificamente para cada setor.
Já construir e manter um software de qualidade é muito difícil, ainda mais tratando de
uma equipe de desenvolvedores, onde pode ocorrer comunicação ambígua e imprecisa, e
complexidade do software subestimada comprometendo a qualidade final do produto, além
destes fatores, podemos citar ainda a falha no entendimento das necessidades do usuário,
inabilidade de tratar mudança de requisitos, arquitetura fracamente definida e testes
insuficientes.
Para tratar os problemas citados, além de aplicar padrões aos times de
desenvolvedores e prover qualidade aos produtos, temos as metodologias de gerenciamento
de projetos, que sugere uma forma padronizada de se trabalhar e gerenciar os projetos.
14
2 OBJETIVOS
A elaboração deste trabalho tem como objetivo estudar alguns tipos de metodologias
de gerenciamento de projetos.
Com os estudos realizados, será efetuada uma avalição das metodologias, afim de
elaborar uma proposta de unificação das metodologias estudadas, focando como caso de uso o
desenvolvimento de Sistemas Integrados de Gestão Empresarial para pequenas empresas,
levando em consideração percalços reais, como infraestrutura e recursos monetários
disponíveis neste tipo de empresas.
15
3 METODOLOGIA
Para a realização do trabalho, será realizado um estudo das metodologias de
gerenciamento de projetos já existentes, como as metodologias RUP, SCRUM e Um Guia do
Conhecimento em Gerenciamento de Projetos (PMBOK).
Na primeira etapa do trabalho, será realizado uma revisão bibliográfica das
metodologias citadas.
Após esta revisão, em um segundo passo, será realizado uma avaliação dos itens
estudados na primeira etapa, afim de elaborar uma proposta de unificação das metodologias
através de sua releitura.
16
4 REVISÃO BIBLIOGRÁFICA
4.1 GERENCIAMENTO DE PROJETOS
Segundo o PMI (2008), um projeto compreende em um esforço temporário para criar
um produto, serviço, ou resultado exclusivo, sendo temporário pelo fato que tem início e fim
definidos. Também é afirmado no Guia que cada projeto é exclusivo e com resultado incerto,
mesmo que esteja usando os mesmos recursos, pelo fato de que cada projeto é caracterizado
por um conjunto de entradas, ferramentas e técnicas que podem ser aplicadas e saídas
resultantes.
Diferenciamos projetos de processos por alguns aspectos, sendo o projeto temporário e
com resultados únicos e incertos, os processos são permanentes, repetitivos, com resultados
previsíveis e focados na disciplina, afirma o PMI (2008). Geralmente um processo é resultado
de um projeto. Temos também aspectos comuns entre eles que são limitados por recursos;
planejados, executados e controlados.
Gerenciamento de projetos, o PMI (2008), considera como a aplicação de
conhecimentos, habilidades, ferramentas e técnicas às atividades de um projeto, a fim de
cumprir seus requisitos com o maior desempenho possível.
Segundo o PMI (2008), o desempenho desejável em um projeto define se pelo
balanceamento de restrições conflitantes, como por exemplo, o escopo, a qualidade, o
cronograma, o orçamento, os recursos e os riscos do projeto.
Para que um projeto seja bem sucedido, o PMI (2008) recomenda que sejam adotados
processos de gerenciamento de projetos, que são na realidade “boas práticas”, isto significa
que existe um consenso geral de que a aplicação destes processos garante um fluxo eficaz e
aumentam as chances de êxito em projetos. Isto não significa também que estes
conhecimentos e habilidades devem ser empregados uniformemente em todos os projetos,
mas sim conforme o escopo, resultado esperado e ferramentas de cada projeto.
Neste âmbito, podemos encontrar diversos guias para gerenciamento de projetos, neste
trabalho será utilizado o PMBOK (Project Management Body of Knowlegde), pelo fato de que
atualmente é um dos mais utilizados no mundo.
17
4.1.1 O guia de Gerenciamento de Projetos PMBOK
O guia de gerenciamento de projetos PMBOK, está atualmente em sua quarta edição e
foi publicado pela Project Management Institute (PMI), uma das maiores organizações de
profissionais de gerenciamento de projetos do mundo. O guia aborda todo o conteúdo
relacionado a projetos e o seu gerenciamento, considerando que o gerenciamento pode ser
realizado a partir da execução de processos de forma inter-relacionada, afirma a PMI (2008).
Estes processos são divididos em cinco grupos e distribuídos em nove áreas de conhecimento.
Sendo assim, no guia PMI (2008), os processos de gerenciamento de projetos são
apresentados como elementos distintos, e cada um com sua configuração, porém na prática
eles se sobrepõem e interagem de forma que não são detalhadas no guia, pelo fato de que
existem várias formas de gerenciar um projeto.
4.1.2 Os Grupos de processos de gerenciamento de projetos do
PMBOK
O guia PMBOK apresenta os processos de gerenciamento de projetos agrupados em
cinco categorias, conforme as interações e objetivos de cada processo. Os grupos são os de
processos de inicialização, planejamento, execução, monitoramento e controle e encerramento
(FIGURA 1).
Também, cada processo definido no guia é caracterizado pela área de conhecimento,
sendo, integração, escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos
e aquisições as áreas dos processos, descreve o PMI (2008).
18
Fonte: PMBOK
FIGURA 1: Mapeamento dos grupos de processos e as áreas de conhecimento do PMBOK
19
4.1.2.1 Processos de Iniciação
Segundo o PMI (2008), os processos de inicialização são utilizados na definição de um
novo projeto ou fase de um projeto já existente, obtendo autorização das partes para inicio.
Nestes processos é definido o escopo inicial, os recursos financeiros iniciais e há uma
interação entre as partes externas e internas interessadas no projeto, para identificação dos
resultados esperados (FIGURA 2).
Fonte: PMBOK
FIGURA 2: Grupo de processos de inicialização.
Quando há projetos grandes divididos em fases, o guia recomenda que este grupo não
seja deixado de lado, pois ajuda a manter o foco nas necessidades para qual o projeto foi
criado. A inicialização é importante em um projeto, pois geralmente o envolvimento dos
clientes, ou outras partes interessadas, aumenta a probabilidade de aceitação e satisfação das
partes interessadas.
Neste grupo são descritos os objetivos do projeto, incluindo os motivos que levaram a
iniciar um novo projeto, explica o PMI (2008). A partir destas informações é elaborado um
documento, o Termo de Abertura de Projeto, que pode conter também a declaração inicial do
escopo do projeto, prazos, duração do projeto e uma breve previsão dos recursos financeiros
necessários. Este grupo de processos também é responsável pela identificação das partes
interessadas, pessoas ou organizações afetadas pelo projeto.
20
Segundo o PMI (2008), este documento originado autoriza formalmente o início do
trabalho, levando ao conhecimento das partes interessadas as necessidades e resultados
esperados do determinado projeto, para que o mesmo satisfaça as expectativas.
4.1.2.2 Processos de Planejamento
Conforme o guia, este grupo de processos tem a função de definir o escopo total do
projeto, refinar os objetivos e desenvolver rumo de ação para obter os resultados para o qual o
projeto foi criado. Estes processos de planejamento desenvolvem o plano de gerenciamento e
os documentos necessários para execução do projeto (FIGURA 3).
Fonte: PMBOK
FIGURA 3: Grupo de processos de planejamento.
21
Ao longo do planejamento, informações e características sobre o projeto são coletadas
e compreendidas, afirma o PMI (2008). O planejamento não é realizado somente uma vez,
pois durante o ciclo de vida do projeto pode ser encontrado problemas ou mudanças
necessárias fazendo com que parte do projeto seja replanejada.
Ainda, segundo o guia, este grupo de processos gera um plano de gerenciamento e
documentos, explorando características de escopo, custos, tempo, risco, qualidade,
comunicação e aquisições. Atualizações ou mudanças autorizadas impacta no plano e em seus
documentos, sendo necessário, para obter maior precisão no desenvolvimento do projeto, a
atualização dos documentos de planejamento.
A equipe envolvida no desenvolvimento do projeto deve estimular o envolvimento das
partes interessadas no projeto ao planejá-lo, para que identifiquem o máximo de problemas ou
melhoramentos nesta fase, afirma o PMI (2008).
Contudo, alguns procedimentos definidos pela organização determinam quando
encerrar o planejamento do projeto, procedimentos estes afetados pelos limites do projeto,
natureza e pelas atividades de monitoramento e controle, explica o PMI (2008).
4.1.2.3 Processos de Execução
Segundo o guia PMBOK, este grupo de processos, consiste em concluir o trabalho
definido no plano, ou seja, colocar em prática o desenvolvimento do projeto (FIGURA 4).
Este grupo, envolve a coordenação de pessoal, recursos, integração e execução das atividades
do projeto conforme o plano gerado.
22
Fonte: PMBOK
FIGURA 4: Grupo de processos de execução.
Conforme já exposto no item anterior, o guia do PMI (2008) afirma que nesta fase há a
possibilidade de necessidade de atualizações no planejamento do projeto, podendo afetar nas
durações previstas para cada atividade, produtividade, disponibilidade de recursos e riscos.
4.1.2.4 Processos de Monitoramento e Controle
O guia PMBOK também apresenta o grupo de processos de monitoramento e controle,
que basicamente consiste em acompanhar, revisar e regular o progresso e o desempenho do
projeto (FIGURA 5). Quando há inconformidades ou necessidades de alteração no projeto,
este grupo é responsável em identificar as áreas nas quais serão efetuadas as alterações, no
plano do desenvolvimento do projeto, para que estas sejam executadas.
23
Fonte: PMBOK
FIGURA 5: Grupo de processos de monitoramento e controle.
Este grupo, segundo o guia PMBOK, está associado a todos os outros grupos de
processos de gerenciamento de projeto, pois tem como função monitorar as atividades do
projeto conforme o plano e à linha de base de desempenho do projeto, controlar as mudanças
e recomendar ações preventivas e influenciar para que somente as mudanças autorizadas
sejam implementadas.
A grande importância deste grupo, segundo o PMI (2008), esta relacionada ao fato de
que devido ao monitoramento de todo o projeto e sendo este contínuo, fornece à equipe do
projeto uma melhor visão sobre a saúde e identifica as áreas que requerem maior atenção no
projeto.
24
4.1.2.5 Processos de Encerramento
Por sua vez, o grupo de processos de encerramento consiste em finalizar todas as
atividades, visando completar formalmente o projeto afirma o PMI (2008). Este grupo quando
concluído verifica se os processos estão completos em todos os grupos, para se obter a
aceitação do cliente (FIGURA 6).
Fonte: PMBOK
FIGURA 6: Grupo de processos de encerramento.
Além da aceitação do cliente, segundo o guia, é feita uma revisão pósprojeto,
registrado os impactos da adequação de algum processo, documentado as lições aprendidas,
aplicada as atualizações apropriadas aos processos organizacionais ativos, arquivados os
documentos relevantes ao projeto e encerrada às aquisições.
4.1.3 Integração entre os grupos e processos.
Os grupos e seus processos apresentados, segundo o guia PMBOK, tem interações
comuns, apesar de serem apresentados como distintos. Sendo assim, na prática os processos
interagem e se sobrepõem de forma não detalhada pelo PMBOK, pelo fato de que estas
integrações variam em cada projeto.
25
Sendo assim, os grupos e processos de gerenciamento de projetos interagem entre si,
podendo ocorrer dependências entre esses processos, ou seja, a saída de um grupo ou processo
ser à entrada de outro afirma o PMI (2008) (FIGURA 7).
Fonte: PMBOK
FIGURA 7: Grupos de processos de gerenciamento de projetos.
Ainda segundo o guia, os grupos de processos raramente são executados
exclusivamente e dificilmente ocorrem uma única vez; sendo atividades sobrepostas durante a
vida do projeto (FIGURA 8).
Fonte: PMBOK
26
FIGURA 8: Atividade dos grupos de processos durante o projeto.
O PMBOK trata do gerenciamento da integração do projeto de forma separada do
ciclo de vida principal do projeto, incluindo processos e atividades exclusivas para identificar,
definir, combinar, unificar e coordenar os vários processos e atividades dos grupos de
processos do ciclo principal. Desta forma esses processos e atividades relacionados a
integração, integra conhecimentos de unificação, consolidação, articulação e ações
integradoras, que são necessárias para que o projeto chegue ao seu fim, com as expectativas
atendidas.
Ainda conforme o guia PMBOK, estes processos de gerenciamento da integração do
projeto, requer por parte do gerente, que sejam realizadas escolhas e negociações, quanto a
recursos, objetivos e alternativas. Conforme já explicito, o guia não detalha como é realizada
a integração dos processos e atividades, cabendo ao gerente responsável, através de seus
conhecimentos e experiências, com o auxilio dos processos de integração do PMBOK, ajustar
o ciclo de vida e os processos de forma que haja interação entre eles.
Um resumo exposto pelo PMBOK dos processos de integração apresenta os processos,
os parâmetros de entrada e saída, e as ferramentas utilizadas (FIGURA 9). Ao todo são
apresentados seis processos, sendo desenvolver o termo de abertura do projeto, desenvolver o
plano de gerenciamento do projeto, orientar e gerenciar a execução do projeto, monitorar e
controlar o trabalho do projeto, realizar o controle integrado de mudanças e encerrar o projeto
ou fase.
27
Fonte: PMBOK
FIGURA 9: Resumo dos processos de gerenciamento de integração de processos e atividades do PMBOK.
4.2 ENGENHARIA DE SOFTWARE
Antigamente, por volta de 1950, os softwares começavam a ser projetados e
desenvolvidos, sem seguir um roteiro específico, afirma PRESSMAN (2006). Com a
evolução, softwares de computadores passaram a ser de grande relevância e utilizado em larga
escala, seja para fins pessoais, corporativos, científicos, dentre outros.
28
Segundo PRESSMAN (2006), esta vasta utilização, tem gerado grande demanda de
desenvolvimento de novas tecnologias e manutenção de softwares já existentes, tornando-se
necessário a utilização de metodologias de projeto e desenvolvimento de software.
Estas metodologias, por sua vez são praticamente um manual de boas práticas, tendo
em vista que seu emprego não é uniforme em todos os casos, mas aqueles que utilizam, tem
maior chance de obter sucesso, rapidez, qualidade, além de uma possível redução no
orçamento e no cronograma, explica PRESSMAN (2006). Um sistema construído desta
maneira possibilita atualizações, incrementos e manutenções de forma mais eficiente.
Os conceitos do Guia de Gerenciamento de Projetos, o PMBOK, são relativos as
metodologias de projeto e desenvolvimento de software, estas por sua vez sendo especificas
para área, ao contrário do guia que é mais genérico.
4.2.1 Evolução da Engenharia de Software
Segundo PRESSMAN (2006), as metodologias de projeto e desenvolvimento de
software, são classificadas por ciclo de vida. Estes diversos tipos de ciclos de vida evolui com
o passar do tempo e com as novas tecnologias de software e hardware, onde surgem novas
metodologias e outras ficam para traz.
Ainda conforme PRESSMAN (2006), o modelo cascata ou sequencial, uns dos
primeiros a surgir, proposto em 1970 por Winston W. Royce prevê o gerenciamento do
projeto e desenvolvimento de um software dividido em sete etapas, sendo estas executadas em
uma sequencia, um modelo simples e de fácil planejamento, porém com problemas como, por
exemplo, a impossibilidade de executar várias etapas simultaneamente.
Este modelo serviu como base para os diversos outros modelos que surgiram com o
passar do tempo, como por exemplo, modelos incrementais, evolucionários, baseado em
componentes, processo unificado e o desenvolvimento ágil, este muito utilizado nos dias de
hoje, afirma PRESSMAN (2006).
29
4.2.2 Processo Unificado - RUP (Rational Unified Process)
KROLL e KRUCHTEN (2004) afirma que o modelo RUP (Rational Unified Process),
foi criado pela Rational Software Corporation e posteriormente comprada pela IBM. Esta,
assim como as demais metodologias, também fornece técnicas a serem seguidas por
desenvolvedores de software a fim de melhorar sua produtividade.
Esta metodologia de projeto e desenvolvimento de software é um processo unificado
onde, explica KROLL e KRUCHTEN (2004), que suas bases são de natureza iterativa e
incremental, guiada por casos de uso e centralizada na arquitetura. Além destas características
fundamentais de um processo unificado, o modelo RUP, apresenta-se como bem definido e
bem estruturado, definindo claramente quem é responsável pelo que no projeto, assim como o
que deve ser feito e quando fazê-las.
Segundo KROLL e KRUCHTEN (2004), o processo RUP provê ao projeto um ciclo
de vida bem definido, definindo os pontos de decisão e os marcos essenciais. Além de tudo é
um processo flexível, ou seja, suporta uma vasta variedade de processos, configurações ou
criação de novos processos, sendo possível, desta maneira, ser utilizada por grandes ou
pequenas equipes, ou mesmo empregada para pequenos, médios ou grandes projetos de
software.
A metodologia RUP utiliza a UML (Linguagem Unificada de Modelagem, em inglês –
Unified Modeling Language) para apoiar as práticas de engenharia de software orientada a
objetos, especificando, modelando e documentando artefatos do projeto afirma PRESSMAN
(2006). Cabe ainda ressaltar que a UML não fornece o arcabouço de processos para gerenciar
as equipes de desenvolvimento de projetos, sendo esta uma linguagem muito utilizada
atualmente.
4.2.2.1 Princípios do RUP
Segundo MARTINS (2007), o modelo RUP se diferencia dos outros métodos
iterativos por conter alguns princípios básicos característico que é atacar os riscos
antecipadamente e continuamente, focar no software executável, certificar de entregar algo de
30
valor ao cliente, acomodar mudanças antecipadas, liberar um executável da arquitetura
antecipadamente, construir o sistema com componentes, trabalhar junto como equipe e fazer
da qualidade um estilo de vida, não deixando para depois.
Um princípio muito importante da metodologia RUP é o foco na garantia da qualidade
dos seus processos, buscando alcançar a qualidade de software desenvolvido, afirma
KRUTCHEN.
4.2.2.2 Elementos do RUP
A metodologia de desenvolvimento e projeto de software RUP, segundo KROLL e
KRUCHTEN (2004) possuem cinco elementos principais. O primeiro são os papéis, que
define o comportamento e as responsabilidades de uma pessoa ou grupo envolvido no projeto,
desta forma destaca-se quatro papéis, sendo o desenvolvedor, analista, testador e gerente de
projetos. Já as atividades, compreendem em unidades de trabalho realizado por um individuo
envolvido no projeto, gerando resultados importantes para o projeto. O terceiro elemento é
chamado de artefato, compreendido em um pedaço de informação que é produzido,
modificado ou utilizado em um processo do desenvolvimento do projeto. Os artefatos são
agrupados conforme as disciplinas, poderá ser visto com mais detalhes no item 4.2.2.3,
disciplinas e artefatos do RUP.
KROLL e KRUCHTEN (2004) definem que o quarto elemento é uma sequência de
atividades, chamado de fluxo de trabalho, este gera resultados importantes para o projeto e
podem ser representados por diagramas de sequência, diagramas de colaboração e diagramas
de atividades da linguagem UML. O RUP apresenta três tipos de fluxo de trabalho: os fluxos
principais que são associados as disciplinas, os fluxos de trabalho de detalhe que detalha cada
fluxo de trabalho principal, e os planos de iteração que mostram como a iteração deverá ser
executada (FIGURA 10).
31
Fonte: http://www.wthreex.com/rup/process
FIGURA 10: Exemplo de fluxo de trabalho principal.
As disciplinas, conforme MARTINS (2007), é uma coleção de atividades
relacionadas, fazendo parte do contexto do projeto, sendo este o quinto elemento do RUP. A
divisão, ou o agrupamento das atividades em disciplinas traz um melhor entendimento do
projeto, porém dificulta no momento do planejamento.
4.2.2.3 Disciplinas e artefatos do RUP
Como vimos as disciplinas, assim como os artefatos são elementos do RUP e as
disciplinas estão divididas em um total de nove.
32
Os artefatos, como já explicitado, podem ser de diversos tipos, documentos, códigos
fonte, modelos, dentro outros, sendo que este podem ser produzidos pela execução de um
processo ou fase do projeto, e utilizado como entrada de um outro processo, tudo conforme a
integração dos processos de gerenciamento afirma KROLL e KRUCHTEN (2004).
Os artefatos dos RUP (FIGURAS 11, 12, 13, 14, 15, 16, 17, 18, 19) são dispostos
conforme as disciplinas apresentadas a seguir:
a) Modelagem de negócios
Fonte: http://www.wthreex.com/rup/process
Figura 11: Artefatos da disciplina de modelagem de negócios.
33
b) Requisitos
Fonte: http://www.wthreex.com/rup/process
FIGURA 12: Artefatos da disciplina de requisitos.
c) Análise
Fonte: http://www.wthreex.com/rup/process
FIGURA 13: Artefatos da disciplina de analise.
34
d) Implementação
Fonte: http://www.wthreex.com/rup/process
FIGURA 14: Artefatos da disciplina de implementação.
e) Teste
Fonte: http://www.wthreex.com/rup/process
FIGURA 15: Artefatos da disciplina de teste.
35
f) Distribuição
Fonte: http://www.wthreex.com/rup/process
FIGURA 16: Artefatos da disciplina de distribuição
g) Configuração e gerenciamento de mudanças
Fonte: http://www.wthreex.com/rup/process
FIGURA 17: Artefatos da disciplina de configuração e gerenciamento de mudanças.
36
h) Gerenciamento de projetos
Fonte: http://www.wthreex.com/rup/process
FIGURA 18: Artefatos da disciplina de gerenciamento de projetos.
i) Ambiente
37
Fonte: http://www.wthreex.com/rup/process
FIGURA 19: Artefatos da disciplina de ambiente.
4.2.2.4 Ciclo de Vida do RUP
O modelo RUP, segundo KROLL e KRUCHTEN (2004) apresentam quatro fases em
seu ciclo de desenvolvimento. A primeira fase, nomeada de iniciação ou concepção, foca no
tratamento de riscos relacionados aos casos de negócio, comunicação com o cliente e
planejamento. Nesta fase são gerados casos de uso preliminares. A quantificação dos riscos do
projeto é uma prioridade, e é essencial, tendo em vista que enfatiza a qualidade do produto e
auxilia nas tomadas de decisão quanto a viabilidade e a possibilidade financeira de
implementação do projeto.
38
Já a segunda fase, a elaboração, além da comunicação do cliente, os riscos técnicos e
arquiteturais do projeto são enfatizados, descreve KROLL e KURCHTEN. Durante esta
segunda fase do projeto, o escopo, e os requisitos é revisado e aprimorado, gerando um
modelo genérico de processo. Os casos de uso são expandidos, possibilitando garantir que o
escopo, os riscos e os prazos permaneçam equilibrados.
Segundo KROLL e KRUCHTEN (2004), a fase de construção consiste na
implementação do projeto. Usando o modelo gerado nas fases anteriores, esta fase desenvolve
o software, ou componentes deles, tornando os casos de uso utilizáveis pelo interessados no
produto.
Em sua última fase, a chamada transição, KROLL e KRUCHTEN (2004) afirmam que
o RUP engloba as últimas atividades de construção e inicia a implantação. A versão do
software é entregue aos usuários, o software começa ser utilizado e é acompanhado com
rotinas de teste e através de relatórios dos interessados, para que em caso de necessidade de
modificações ou defeitos seja iniciado um novo ciclo para correção.
Segundo KROLL e KRUCHTEN (2004), por se tratar de uma metodologia iterativa e
incremental, o término das quatro fases do ciclo de vida não significa que o software está em
sua versão final, pois o ciclo pode iniciar novamente pelo fato de que foram encontrados
defeitos, há novas necessidades ou mesmo pela alteração da tecnologia empregada. Quando
um ciclo é concluído, uma versão do produto é lançada (FIGURA 20).
39
Fonte: http://www.ebah.com.br/content/ABAAAAsdkAG/monografia
FIGURA 20: Ciclo de vida do RUP.
Por tratar de um sistema já desenvolvido em uma primeira versão, KRUCHTEN
(2004) afirma que as fases de iniciação e elaboração são bem menores, pelo fato de que a
arquitetura e as definições básicas do produto já foram determinadas anteriormente.
40
4.2.2.5 Arquitetura Geral do RUP
MARTINS (2007) define a arquitetura geral da metodologia da Rational como
possuindo duas dimensões conforme a figura 21.
Fonte: http://www.pollysoft.com.br/?m=fabrica&p=rup
FIGURA 21: Arquitetura geral do RUP.
Conforme MARTINS (2007), no eixo vertical, ficam agrupadas as disciplinas, de
maneira lógica, este representa as atividades do processo, em relação ao tempo, que por sua
vez esta situada no eixo horizontal do gráfico. Observa-se também as fases e a incidência de
trabalho sobre cada disciplina do projeto em relação ao tempo.
41
4.2.2.6 Produtos de trabalho do RUP
Segundo PEARSON, as fases do desenvolvimento de projetos geram produtos
(FIGURA 22), onde o produto de uma fase torna a entrada de outra. Sendo assim, a fase da
iniciação prevê estabelecer uma visão global do projeto, sendo utilizado para isso documentos
chamados casos de uso. Os casos de uso descrevem os atores do software, ou seja, as pessoas
que irão interagir com o software, além das características das funcionalidades do produto.
À medida que o projeto avança em seu desenvolvimento, os casos de uso são
aprimorados afirma PEARSON. Na fase da elaboração, é produzido um conjunto de produtos
que abordam os requisitos (funcionais e não funcionais), descrição arquitetural e um projeto
preliminar.
A etapa de construção do projeto produz um modelo de implementação, que traduz as
classes dos objetos gerados na etapa anterior, em componentes de software que serão
construídos afirma PRESSMAN (2006). Há também além do modelo da implementação o
modelo de implantação que especifica os componentes físicos de informática do ambiente.
Por fim, está etapa ainda utiliza um modelo de teste que é utilizado para garantir que os casos
de uso sejam implementados adequadamente.
PRESSMAN (2006) descreve que o encerramento de um ciclo de vida do projeto, a
fase de transição, produz a medida que os usuários finais utilizam o software, relatórios de
testes e de solicitações de modificações.
42
Fonte: PRESSMAN
FIGURA 22: Produtos de Trabalho do RUP.
4.2.3. Desenvolvimento Ágil - Scrum
A metodologia de desenvolvimento e projeto de software Scrum é uma metodologia
de característica ágil. PRESSMAN (2006) afirma ainda que o “Movimento Ágil” iniciou em
2001 por Kent Beck e outros dezesseis profissionais da área.
Devido a rápida evolução da informática e do mundo atual, houve a necessidade de
agilizar o desenvolvimento de novos ou atualizações de softwares, a fim de acompanhar a
evolução rápida e continua do mundo. As metodologias baseadas no desenvolvimento ágil,
diferente das convencionais, foca na valorização das iterações, dos indivíduos, software
funcionando e não na longa documentação, colaboração com o cliente e não negociações de
contratos e atividades de acordo com as respostas de modificações sem utilização de um
plano, explica PRESSMAN (2006).
A engenharia de software ágil, conforme PRESSMAN (2006), combina algumas
diretrizes de desenvolvimento e uma filosofia que encoraja, por parte do cliente, a sofisticação
e a entrega incremental do software. As equipes de desenvolvimento também são altamente
43
motivadas, utilizando métodos informais e documentação de engenharia de software mínimos,
resultando em um desenvolvimento simplificado. Há comunicação continua entre os
desenvolvedores e os clientes.
Segundo a perspectiva de PRESSMAN (2006) afirma que os engenheiros de softwares
e os demais interessados no projeto trabalham juntos no desenvolvimento do projeto,
formando uma equipe, sendo está auto organizada e controlando seu próprio destino. Este tipo
de desenvolvimento não é aplicável à todos os projetos de software, apesar de fornecer
benefícios importantes.
Ainda, segundo PRESSMAN (2006), as atividades básicas da engenharia de software,
a comunicação com o cliente, o planejamento, a modelagem, construção, entrega e avaliação
continuam, porém foram reduzidas ao tamanho mínimo de tarefas.
Neste modelo de desenvolvimento, o produto gerado é o “incremento de software”, ou
seja, uma versão do software, tendo em vista que não há utilização de muitos documentos
neste modelo expõem PRESSMAN (2006). A equipe de desenvolvimento ao final de uma
interação, verifica se o software atende as necessidades e é entregue ao cliente. Um processo
de desenvolvimento ágil, assim como o RUP pode ter várias interações, e a cada uma delas é
gerada uma versão do produto.
Scrum é um modelo de desenvolvimento ágil. O nome é derivado de uma atividade
que ocorre durante um jogo rugby, onde os jogadores se aproximam da bola, e em equipe
movimentam a bola explica PRESSMAN (2006). Este modelo foi desenvolvido por Jeff
Sutherland e por sua equipe no inicio da década de 1990, antes do “Movimento Ágil”.
4.2.3.1 Princípios do Scrum
Assim como descrito anteriormente, quanto ao “Movimento Ágil”, o Scrum é
compatível, descreve PRESSMAN (2006), quanto aos princípios do Scrum, que consiste no
trabalho organizado em pequenas equipes, priorizando a comunicação entre os membros,
minimização da supervisão e maximização da troca de conhecimentos de formas informais.
44
Outro princípio exposto por PRESSMAN (2006) é a garantia de que seja produzido o
melhor produto possível, para isso é necessária a flexibilidade de adaptação do processo, tanto
as modificações técnicas como de negócios. Assim como o modelo RUP, é produzido por este
processo várias versões do software, ou parte deles, que possibilita teste, modificação,
expansão e documentação.
No Scrum o trabalho é particionado, o trabalho e o pessoal são divididos, incumbindo
cada pessoa com uma parte do trabalho explica PRESSMAN (2006). À medida que o produto
é construído, são elaborados documentos e testes são realizados constantemente. O processo
Scrum não impede a equipe, o cliente, ou o gerente de declarar que o produto está pronto a
qualquer momento do desenvolvimento, fato este que pode ocorrer pela necessidade do
cliente, necessidade financeira da empresa, prazo de entrega esgotado, por exemplo.
Estes princípios do modelo servem para conduzir as atividades de desenvolvimento,
afirma PRESSMAN (2006). Assim como as metodologias convencionais, o Scrum tem suas
atividades principais, sendo chamadas de requisitos, análise, projeto, evolução e entrega.
4.2.3.2 Ciclo de Vida do Scrum
O modelo Scrum, por ser de natureza iterativa e incremental tem um ciclo de vida
semelhante ao da metodologia RUP já estudada. PRESSMAN (2006) afirma que em cada
uma das atividades principais, o desempenho das tarefas é realizado conforme um padrão de
processo, chamado de Sprint (FIGURA 23).
45
Fonte: http://www.heptagon.com.br/scrum
FIGURA 23: Ciclo de vida do Scrum.
Tendo em vista que o trabalho é conduzido dentro de uma Sprint, dependendo do
tamanho e complexidade do projeto, o número de sprints, para cada atividade básica, varia,
assim como as adaptações e modificações, que é realizada em tempo real pela equipe do
Scum, afirma PRESSMAN (2006).
Ainda, segundo PRESSMAN (2006), o modelo de desenvolvimento Scrum, prioriza a
utilização de “padrões de processo de software”, pelo fato de que nos projetos que, o tempo
de entrega é curto, ou sofrem muitas mudanças nos requisitos e nos planos de negócios, estes
padrões se mostram eficazes.
PRESSMAN (2006) afirma que cada um desses padrões define um conjunto de
atividades de desenvolvimento chamadas de pendência, sprints, reuniões Scrum e demos. As
pendências consistem em uma lista que contém as características e os requisitos do projeto.
Esta lista de pendências é o que fornece o valor de negócio ao cliente. As pendências podem
ser alteradas a qualquer momento do projeto, podendo ser inseridas novas necessidades ou
modificações, e o gerente de produto examina e atualiza a lista conforme o desenvolvimento
do projeto.
As sprints, por sua vez, são unidades de trabalho necessárias para desenvolvimento de
uma pendência, tendo um intervalo de tempo predefinido para ser finalizada. PRESSMAN
(2006) ainda expõem que durante a execução de uma Sprint, as demais pendências são
46
travadas, para que não haja alteração nos requisitos durante o desenvolvimento de uma Sprint,
tornando o ambiente mais estável.
Diariamente, é realizada uma reunião com a equipe, tendo duração aproximada de
quinze minutos afirma PRESSMAN (2006). Praticamente, as reuniões abordam três itens,
sendo o que cada um realizou desde a última reunião, que obstáculos estão encontrando e o
que pretende até a próxima reunião.
As reuniões são dirigidas pelo líder da equipe, o chamado Scrum master, sendo ele que
avalia as respostas de cada um para os três itens abordados. Ainda segundo PRESSMAN
(2006) as reuniões ajudam a equipe a encontrar os problemas, o mais breve possível, promove
um compartilhamento de conhecimento e promove uma auto organização na equipe.
PRESSMAN (2006) descreve os demos como sendo a entrega de uma versão do
software ao cliente, de modo que o cliente possa visualizar e trabalhar com esta versão. Cabe
ressaltar que essas versões podem não contemplar totalmente os requisitos do projeto, porém
algumas funções já podem ser utilizadas.
PRESSMAN (2006) concluiu que a utilização do Scrum permite a equipe
desenvolvimento trabalhar em projetos de forma a conquistar o sucesso no mundo atual, onde
existe muitas incertezas, e a evolução da tecnologia da informação acontece rapidamente.
A metodologia Scrum, segundo SCHWABER e SUTHERLAND (2012) utiliza uma
única fonte de requisitos para o projeto, sendo este o documento chamado de Backlog do
produto. Este documento consiste em uma lista ordenada contemplando tudo que pode ser útil
para o produto final. O documento evoluí assim como o projeto e a cada iteração ele é
atualizado.
47
5 COMPARAÇÃO QUALITATIVA E QUANTITAVIA ENTRE
OS MÉTODOS.
As metodologias abordadas na revisão bibliográfica, apresentam características
específicas, sendo elas favoráveis ou desfavoráveis a sua aplicação na engenharia de software.
As metodologias RUP e Scrum, conforme itens 4.2.2 e 4.2.3, apresentam princípios
semelhantes, ambas de natureza iterativa e incremental, podendo ser facilmente adaptadas ao
projeto ao qual foi empregada, porém temos o Scrum como uma metodologia ágil.
Sendo assim, ao tempo que o RUP é uma metodologia pesada, com a utilização de
muitos documentos, o Scrum é simples, utilizando o mínimo de documentação para o
desenvolvimento de projetos, conforme descrito nos itens 4.2.2.6 e 4.2.3.2.
Segundo KROLL e KRUCHTEN (2004), além da documentação, a metodologia RUP
define o papel de cada pessoa dentro do desenvolvimento do projeto, onde cada integrante da
equipe tem uma função, equipes que geralmente são formadas por muitos membros,
diferentemente do Scrum, que preza pelas pequenas equipes, havendo a necessidade dos
profissionais membros da equipe serem altamente qualificados, podendo ser incumbido de
várias tarefas, explica PRESSMAN (2006), isso faz com que todos os integrantes da equipe
estejam sempre empenhados e em todas as fazes do projeto, o que não ocorre na metodologia
RUP.
PRESSMAN (2006), também cita que no Scrum o projeto é desenvolvido por meio de
negociações, ou reuniões com o cliente, já no RUP, segundo KROLL e KRUCHTEN (2004),
as etapas, ou modificações do projeto são realizadas tudo por meio de contratos o que acaba
aumentando o tempo de vida do projeto.
Os autores PRESSMAN (2006), KROLL e KRUCHTEN (2004), afirmam que no
RUP as iterações são ajustáveis ao tamanho do escopo, recursos e prazos do projeto, diferente
do Scrum que tem suas iterações com tempo determinado de duas a quatro semanas.
Tratando de um método ágil, como vimos, o Scrum preza o produto funcionando, não
enfatizando a documentação, o que faz com que a especificação detalhada inicial raramente
seja produzida, diferente do método RUP, onde primeiramente constrói-se os documentos de
especificação, fazendo com que seja possível fazer estimativas com certa precisão referente ao
projeto, o que não ocorre na metodologia ágil, onde é possível fazer estimativas somente com
o transcorrer do projeto, explica MARTINS (2007).
48
Ainda conforme MARTINS (2007), na metodologia RUP é possível obter informações
dos estados internos de cada processo da metodologia que esta sendo executado, promovendo
um melhor entendimento dos trabalhos internos. Esse entendimento, de certa forma requer um
amplo e acurado conhecimento do processo, já no Scrum, não é possível obter informações
detalhadas sobre um processo, mas sim de uma parte dela, pois este método trata o processo
como se fosse uma “caixa fechada”. MARTINS (2007) ainda expõem que diferentemente ao
RUP que exige um entendimento acurado sobre um processo, o Scrum não requer
conhecimento detalhado, pois os resultados esperados podem ser obtidos através de algumas
mudanças.
Quando trabalha-se com a metodologia Scrum há uma grande incidência de mudanças
não esperadas no projeto, fazendo com que tenha que ser empregada muitas adaptações, ao
contrário do método RUP, que as mudanças são previstas, e raramente ocorrem mudanças que
não foram planejadas no início do projeto, coloca MARTINS (2007).
MARTINS (2007) ainda explica que a metodologia de desenvolvimento RUP é
recomendada aos projetos de baixa complexidade e bem compreendido, pois estes podem ser
estudados e bem planejados com esta metodologia. Já para os projetos de alta complexidade e
também poucos compreendidos aconselha-se a utilização da metodologia Scrum, pois não
foca muito no planejamento, mas sim a resposta a mudanças.
Entretanto, cada metodologia há pontos bons e outros ruins, valendo ressaltar também,
que para uma avaliação de desempenho de uma metodologia, deve ser levado em
consideração não só os processos das metodologias, mas sim o projeto e a maneira que a
metodologia esta sendo aplicada. No mundo da Engenharia de Software, há muitos que
argumentam sobre qual seria a melhor metodologia, porém nenhum método individual
dominou a área, explica PRESSMAN (2006).
49
6. PROPOSTA DA UNIFICAÇÃO DAS METODOLOGIAS
Inicialmente, vale ressaltar que há uma caracterização dos métodos estudados a fim de
implementar novos princípios, desta forma, esta unificação das metodologias apoia-se nos
melhores recursos e características dos modelos RUP e Scrum, assim como no Guia de
Gerenciamento de Projetos (PMBOK), conforme o capítulo 4, de realizando uma releitura das
metodologias e práticas de gerenciamento de projetos. A proposta será chamada de “Processo
Unificado Ágil”.
Levando em consideração o cenário atual da Engenharia de Software, este método tem
seu ciclo de vida iterativo e incremental, assim como as demais metodologias estudadas
(capítulo 4). Este ciclo de vida foi adotado pelo fato de que a natureza incremental gera uma
nova versão do produto a cada iteração como podemos ver na Figura 24. Já tratando de um
ciclo de vida iterativo, significa que o ciclo de vida completo do projeto é dada através de
outros pequenos ciclos, onde cada um gera resultados diferentes.
FIGURA 24: Ciclo de vida da metodologia Processo Unificado Ágil.
50
Desta forma, é possível entregar versões de software, funcionando, a fim de atender as
necessidades mais urgentes do cliente em menor tempo, ou mesmo para teste da aplicação por
parte do cliente, para que nas próximas iterações do projeto esses problemas sejam resolvidos,
atendendo as necessidades do mesmo e do negócio, ou mesmo solucionando problemas de
codificação.
Uma característica muito importante e de certa forma, essencial para uma boa
metodologia de gerencia de projeto, é a flexibilidade. Esta característica possibilita que a
metodologia seja aplicada em diversos e nos mais diferentes projetos, sendo de grande ou
pequeno porte, complexo ou simples.
Como já foi dito, as metodologias são boas práticas de gerencia de projetos (capítulo
4), desta forma, não há a obrigatoriedade de ser aplicada uniformemente em todos os projetos,
pois já é conhecido que não é aplicável no mundo real. Sendo assim, esta metodologia pode
ser adaptada conforme necessidade e conhecimento do próprio gerente do projeto, adotando
utilizar ou não, ou até mesmo modelar os processos e as disciplinas conforme a aplicação.
6.1. PAPÉIS
Esta metodologia de desenvolvimento de software propõem quatro principais papéis
dentro do projeto, semelhante a metodologia Scrum, sendo o cliente, gerente de projetos,
assistente comercial e a equipe de desenvolvedores.
O cliente, é a pessoa responsável em representar a companhia interessada no projeto
perante ao assistente comercial, gerente de projetos e a equipe de desenvolvimento, de forma
a descrever as necessidades, negociar prazos, recursos, escopo e qualidade do produto final.
O assistente comercial também estará envolvido em todo o desenvolvimento do
projeto, porém de forma não técnica e indireta. Este agente, tem como principal função a
negociação com o cliente em relação aos recursos e custos do projeto.
Um outro papel importante no desenvolvimento do projeto é o gerente de projetos, que
participa diretamente e indiretamente em todo o ciclo de vida do projeto, com foco principal
nas fases de iniciação, planejamento e gerenciamento do projeto. Esta pessoa deve ter um
conhecimento técnico e ao mesmo tempo um conhecimento abstrato, gerencial.
51
A equipe de desenvolvedores, também participa de praticamente todas as fases do
projeto, porém no gerenciamento do projeto não têm participação direta. A equipe é formada
por profissionais de diversas especialidades técnicas, e esta equipe na fase de planejamento é
dividida em equipes menores conforme a especialização profissional.
6.2 OS GRUPOS DE PROCESSOS DA METODOLOGIA
PROCESSO UNIFICADO ÁGIL
Assim como as demais metodologias e o guia de gerenciamento de projetos (capitulo
4), esta metodologia esta dividida em grupos de processos de gerenciamento, como podemos
observar na figura 24.
Os processos de cada grupo do ciclo de vida, devem interagir entre si, sendo que
muitos deles é pré-requisito para outros. Desta forma, documentos ou dados gerados em um
processo pode ser utilizado por outro processo do próprio grupo ou dos demais grupos. Essa
característica da metodologia poderá ser observada nos próximos tópicos que evidenciará os
processos internos as fases do ciclo de vida, ou grupos de processos.
6.2.1 Grupo de processos de inicialização
A fase de iniciação do projeto compreende principalmente na comunicação com o
cliente, formalizando o desenvolvimento do projeto através de contratos e documentos de
marketing. Deve ser avaliado e estimado nesta fase a viabilidade, riscos, recursos necessários
e tempo de desenvolvimento do projeto (FIGURA 25).
52
FIGURA 25: Grupo de processos de inicialização.
Nesta fase do projeto, temos uma grande atuação do assistente comercial nas
negociações e do gerente de projetos que tem a capacidade de avaliar e estimar o projeto.
6.2.2 Grupo de processos de planejamento
Já a segunda fase do ciclo de vida, temos o planejamento, que é dividido em duas
etapas (FIGURA 26). A primeira, é responsável em definir os aspectos genéricos, como
definição dos atores do projeto, escopo, tempo, custo, qualidade e riscos, através do
levantamento de requisitos e modelagem de negócios, a fim de elaborar o documento de
especificações de requisitos (Anexo A). Esta primeira fase é muito importante, pois um
planejamento e a coleta de requisitos bem realizada, poderá minimizar a incidência de
mudanças que poderão ocorrer durante o desenvolvimento do projeto.
53
FIGURA 26: Grupo de processos de planejamento.
As especificações de requisitos, é um documento formal que descreve as necessidades
do cliente, devendo constar o máximo de informações possíveis a respeito do ambiente atual e
futuro a implantação do software, como funciona o atual sistema, funcionalidades do software
a ser desenvolvido, regras de negócios e políticas da empresa. Esse documento de requisitos
deve ser aprovado pelo cliente, para que não haja incompatibilidades do produto final com as
necessidades da empresa.
Com as especificações de requisitos aprovadas, a equipe, orientada e supervisionada
pelo gerente de projetos, irá adequar os requisitos especificados conforme as técnicas, lógicas,
linguagens de programação e ferramentas que serão empenhadas na codificação, gerando
assim o documento de especificação técnica.
As especificações técnicas, descreve as funcionalidades do sistema individualmente,
sendo que deve abordar quem são os atores que estarão relacionados a funcionalidade,
descrição e modelagem dos dados, regras de negócio, fluxo principal, fluxos alternativos e
fluxos de exceção (Anexo B).
54
A segunda etapa do planejamento, através do conceito de Backlog da metodologia
Scrum (capítulo 4), as especificações técnicas serão seccionadas gerando os itens do Backlog,
e esses itens serão distribuídos por áreas de conhecimento (FIGURA 27).
As especialidades para seleção dos itens, poderão ser atribuídas pelo gerente de
projetos, que adotará os grupos conforme o projeto e sua equipe de desenvolvedores. Para
essa divisão em áreas de conhecimento, poderá ser levado em consideração características em
comum dos itens e área técnica, como por exemplo existência de um grupo referente a banco
de dados, outro referente a aplicação que pode ser subdividido conforme módulos do sistema
ou conforme as especificações técnicas.
FIGURA 27: Planejamento da construção do projeto - Backlog.
Cada área de conhecimento, terá os itens de Backlog dispostos pelo gerente de
projetos, na forma de fila (primeiro a entrar, primeiro a sair), para que o desenvolvimento dos
itens aconteça de forma sequencial. Assim como no Scrum, cada um dos itens, terá sua
graduação de complexidade (pontos), prioridade, adiciona-se a eles uma estimativa de tempo
para a construção do item e uma identificação, contendo a identificação da área do
conhecimento e um número, sequencial conforme a fila. Esta estimativa é realizada com toda
a equipe, onde será exposto e discutido a opinião de todos em relação aos itens
individualmente.
Tendo os itens de Backlog dispostos em fila e com estimativa de tempo, teremos o
desenvolvimento do projeto de forma sequencial e com referencias cronológicas, o que
possibilita melhor controle de prazo pelo gerente de projetos.
55
Finalizando o planejamento, a equipe deverá ser dividida em equipes menores,
conforme a especialidade profissional dos integrantes, relacionando as especialidades ao qual
os itens de backlog foram distribuídos.
6.2.3 Grupo de processos de construção
A fase de construção do projeto, contempla genericamente a codificação do software,
onde os itens gerados na segunda fase do planejamento serão codificados e testados (FIGURA
28). Assim como descrito no planejamento, os itens deverão ser implementados de acordo
com a sequencia planejada em cada especialidade, focando finalizar a implementação do item
conforme a estimativa de tempo.
FIGURA 28: Grupo de processos de construção.
As instruções de programa que representam os itens de backlog já codificados,
deverão ser integrados aos outros conforme o transcorrer da construção do software, de modo
a interagirem entre si, constituindo um só software ou versão dele.
Ao término da codificação de cada item, é recomendável que estes sejam testados de
forma individual, para que na possível existência de erros, facilite encontrá-los e repará-los.
56
6.2.4 Grupo de processos de transição
A fase de transição, tem o nome adotado por ser o mais sugestivo para o grupo, sendo
o mesmo nome utilizado pela metodologia RUP, porém havendo diferenças. Este contempla a
realização dos testes finais, implantação e avaliação pelo cliente do produto final ou versão
(FIGURA 29).
FIGURA 29: Grupo de processos de transição.
Os testes, inicialmente deverão ser realizados pela equipe do projeto, simulando o
ambiente real e analisando os dados de saída do sistema. Uma segunda rotina de teste,
homologação, deve ser realizada pelos atores do sistema, os usuários. Geralmente estes testes
são realizados em um ambiente específico, instalado no cliente, para a homologação,
ambiente este o mais próximo do real possível.
Aprovado nos testes, o produto ou a versão será implantado no ambiente principal do
cliente, tecnicamente chamado de ambiente de produção. A implantação, consiste na entrega
oficial do software e sua documentação, configuração e instalação. Conforme o contrato com
o cliente pode haver treinamento dos usuários para utilização do sistema durante a
implantação.
57
6.2.5 Processos de gerenciamento do projeto
Neste modelo proposto, assim como o PMBOK (capitulo 4.1.2.3), este grupo tem a
visão geral do andamento do projeto, além de controlar o ciclo de vida do projeto, integração
entre os processos, mudanças, escopo, prazos, custos, qualidade, comunicação, riscos e
demais recursos necessários ao desenvolvimento do projeto (FIGURA 30).
FIGURA 30: Grupo de processos de gerenciamento do projeto.
Para o bom desenvolvimento do projeto, é necessário comunicação entre os
envolvidos no mesmo, tal que é essencial haver a comunicação entre o gerente de projetos
com o cliente e com a equipe. Desta forma, há a necessidade de ser realizadas pequenas
reuniões periódicas, de curta duração, com a equipe, para verificar o andamento do projeto e
como a equipe está se comportando frente ao projeto. Estas pequenas reuniões podem ocorrer
a qualquer momento no transcorrer do dia, podendo ser no próprio local de desenvolvimento
do software, sem nenhuma formalidade. É recomendável que seja realizada ao menos uma vez
a cada quarenta e oito horas.
58
Quando a iteração de desenvolvimento está transitando de uma fase a outra, há a
necessidade de ser realizada uma reunião, formal, refinando e ajustando o que foi e o que será
realizado, e de que forma irá transcorrer. Esta, como já esperado, poderá ter duração
aproximada de uma hora e meia, e deve ser realizada em um ambiente propício onde possa
reunir toda a equipe.
Neste grupo de processos também ressaltamos o controle de mudanças, essas que
podem ter grande incidência no transcorrer de toda iteração, principalmente durante a
construção e a transição. O controle de mudanças deve ser realizado em todo o ciclo de vida
do projeto.
Essas mudanças, podem ser simples ou complexas. As mudanças simples, conforme
orientação do gerente do projeto, poderá ser realizada durante a própria fase e nesta mesma
iteração. Já as mudanças de maior complexidade, na maior parte das vezes, necessitará de
comunicação e intervenção do cliente e possivelmente do assistente comercial, para que seja
planejada e realizada, em uma nova iteração.
Desta forma é feito um levantamento da necessidade de mudanças é elaborado o
documento de gerenciamento de mudanças (Anexo C), para que estas sejam revistas em uma
próxima iteração do projeto.
Podemos destacar também neste grupo de processos o gerenciamento da integração
entre os processos da metodologia. Inicialmente deve ser levado em consideração as entradas
e saídas dos processos, ou seja, os dados ou conhecimentos utilizados na execução de um
processo, e os resultados gerados por ele. Geralmente as entradas de um processo é o
resultado da execução de outro processo.
Desta maneira, os processos interagem entre si, mesmo estando em grupos distintos,
porém cabe ao gerente de projetos adequar a execução dos processos conforme o projeto. De
certa forma esta integração está evidenciada na descrição dos grupos de processos, porém,
tratando de uma metodologia flexível, cabe ao gerente coordenar de que forma esses
processos serão executados.
Como descrito na introdução da proposta, esta metodologia tende a proporcionar
flexibilidade ao gerenciamento de projetos de desenvolvimento de software, possibilitando
que o gerente aplique seus conhecimentos e habilidades, de forma a modelar e adaptar a
59
metodologia, os processos e a integração dos processos da maneira que atinja o desempenho
esperado.
6.3 BENCHMARK DOS PROCESSOS DA METODOLOGIA
PROCESSO UNIFICADO ÁGIL
Conforme a arquitetura da metodologia proposta, foi elaborado o gráfico (FIGURA
31), apresentando uma referência quanto a execução dos principais processos ou grupos
durante uma iteração do projeto.
FIGURA 31: Benchmark dos principais processos e grupos.
Como pode-se observar, temos na vertical a representação dos processos da
metodologia em relação ao tempo de duração da iteração do projeto, representado na
horizontal. Desta forma podemos observar o tempo e as fases em que os processos apresentam
atividades.
60
7 CONCLUSÃO
A metodologia Processo Unificado Ágil, assim como as demais, consiste em um
conjunto de boas práticas e conhecimento de gerência de projeto, sendo que o sucesso no
desenvolvimento de projetos a partir dela, necessita de um conhecimento prévio do gerente de
projetos, assim como experiências, pelo fato de que a aplicação da metodologia conforme
descrito poderá não resultar em êxito, pelo fato da distinção entre projetos.
Esta perspectiva quanto a aplicação das metodologias são fortemente citadas nas
principais fontes de conhecimento sobre gerencia de projetos, tal que os projetos são
exclusivos, de forma que apresentam tamanho e complexidades diferentes o que faz com que
a metodologia não se comporte exatamente igual em todos os projetos em que é aplicada.
Desta forma, para que aumente a probabilidade de desenvolver o projeto com o
máximo desempenho possível, pode-se realizar modificações no ciclo de vida, na execução
dos processos, e também podendo até modificar internamente os processos.
A metodologia proposta neste trabalho, tem uma forte base, estruturada a partir do
guia de gerenciamento de projetos PMBOK e das metodologias RUP e Scrum, apoiando-se
nos melhores recursos. Também foi observado ambiente real de desenvolvimento de software,
verificando as principais necessidades em relação aos processos das metodologias.
As metodologias RUP, Scrum e Processo Unificado Ágil, apresentam ciclo de vida
iterativo e incremental, este ciclo é muito importante e utilizado no cenário de gerenciamento
de projetos no mundo atual. O ciclo de vida é composto por iterações, de forma que ao fim de
cada uma haverá como resultado um incremento do produto, ou seja uma nova versão do
software. Este ciclo de vida possibilita entregas mais rápidas, podendo atender
antecipadamente as necessidades urgentes.
Conforme citado no trabalho, a metodologia RUP apresenta um conjunto de artefatos
muito pesado, o que deixa o desenvolvimento do projeto lento e burocrático, porém estes
artefatos possibilitam que o planejamento do projeto tenha seu melhor desempenho, o que
diminui a ocorrência de mudanças durante o desenvolvimento do projeto. Sendo assim, o
Processo Unificado Ágil utiliza somente alguns dos conceitos e artefatos do RUP para não
perder a característica do bom planejamento do projeto, sem que a metodologia fique pesada e
burocrática.
A metodologia Scrum, como já comparada ao RUP no transcorrer do trabalho,
apresenta um planejamento fraco, o que faz com que ocorra muitas mudanças durante o
61
desenvolvimento do projeto, desta forma aumentando a quantidade de iterações, em relação as
outras duas metodologias.
Ainda em relação ao Scrum, a metodologia proposta, não deixa de utilizar alguns de
seus conceitos, como o de Backlog, que foi inserido na metodologia proposta, de forma a
agilizar e melhorar o controle da fase de construção do produto.
De forma geral, a metodologia proposta, em relação as demais abordadas neste
trabalho, pretende ter um bom planejamento de forma a diminuir o número de iterações no
desenvolvimento de projetos, ser leve e ágil, de forma a diminuir a complexidade do
gerenciamento de projetos, e ainda controlar de maneira mais eficaz a fase de construção do
produto.
Através destes conceitos destacados da nova metodologia, pode-se concluir que esta
não necessita de muitos recursos, para o gerenciamento e desenvolvimento do software. Um
dos principais recursos no desenvolvimento de um projeto é o humano, que nesta metodologia
não há necessidade ter de uma equipe de profissionais altamente especializados, o que
diminui o custo do produto final.
Há processos de gerenciamento da metodologia Processo Unificado Ágil, que engloba
também conceitos e características do guia de gerenciamento de projetos estudado, o
PMBOK, principalmente quanto aos processos do grupo de gerenciamento do projeto e
gerenciamento da integração entre os processos.
Contudo, procurando atender as demandas de desenvolvimento de software com
recursos reduzidos, conforme foi citado na introdução do trabalho, a metodologia Processo
Unificado Ágil foi proposta, que comparada com as demais metodologias estudas, é a que
mais se aproxima ao cenário descrito, desenvolvimento de software de baixo custo para
pequenas empresas e profissionais liberais.
62
8 REFERENCIAS BIBLIOGRÁFICAS
PROJECT MANAGEMENT INSTITUTE, PMI. Um Guia do Conhecimentos em Gerenciamentos de
Projetos: Guia PMBOK. Quarta Edição. Local Pennsylvania: Four Campus Boulevard, 2008. 337p.
KROLL, Per; KRUCHTEN, Philippe. The Rational Unified Process Made Easy: A practitioner’s
Guide to the RUP. Boston: Pearson Education, 2004.
KRUCHTEN, Philippe. The Rational Unified Process An Introduction. Quarta Edição. Boston:
Pearson Education, 2004.
MARTINS, José C. C. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML.
Quarta Edição. Rio de Janeiro: Brasport, 2007.
PRESSMAN (2006), Roger S. Engenharia de Software. Sexta Edição. Editora McGraw-Hill, 2006
SCHWABER, Ken; SUTHERLAND, Jeff. Guia do Scrum. Disponível em <http://www.ebah.com.br/
content/ABAAAfOyUAI/scrum-guide-portuguese-br >. Acesso em: 09 Out. 2012.
63
ANEXOS
64
ANEXO A – Documento de Especificação de Requisitos
Documento Especificação de Requisitos
Emitido em
Responsável
Revisão
Cliente
Projeto
Aprovado em
Fase: Especificar Requisitos Etapa: Especificação de Requisitos
Introdução
Introdução sobre o documento, e o projeto.
Descrição do Ambiente
Deverá ser descrito a forma de utilização, possíveis variáveis no sistema. Nesta etapa do levantamento de
requisitos pode ser analisado o sistema utilizado atualmente, mesmo sendo manual.
Escopo
O que será abordado na funcionalidade ou no sistema, ou seja, o que ele fará e não fara, que no caso também é
muito importante citar o que o sistema não irá fazer.
Fluxo de Dados
Dados que serão controlados pelo sistema, e o fluxo desses dados. O fluxo pode ser exemplificado pela entrada
e saída de dados do sistema ou funcionalidade e qual a importância desses dados para o negócio e outras
possíveis funcionalidades.
Requisitos especificados
Deve-se abordar neste caso, de maneiro formal e não técnica, quanto as funcionalidades do sistema, atributos
funcionais ou não funcionais como por exemplo a compatibilidade do sistema com os sistemas operacionais,
documentação e recursos necessários para o desenvolvimento e implantação.
65
Controle de Alterações
O controle de alterações tem a funcionalidade de controlar as alterações realizadas neste documento.
Data Responsável Descrição da Alteração
66
ANEXO B – Documento de Especificações Técnicas
Documento Especificação Técnica
Emitido em
Responsável
Revisão
Cliente
Projeto
Aprovado em
Fase: Especificar Programas Etapa: Especificação de Programas
Objetivos
Descrição dos objetivos da funcionalidade do novo sistema.
Dados da solicitação
N° solicitação
Programa
Urgente [ ] sim [ ] não
Data Prazo
Linguagem [ ] ASP-Net [ ] Visual Age [ ] Visual Basic [ ] Visual InterDev [ ] HTML / DHTML [ ] Java [ ] Java script [ ] C [ ] C++ [ ] C-Sharp
Ambiente [ ] Client Server [ ] Web
Tipo da Solicitação [ ] Novo [ ] Alteração [ ] Complemento [ ] Erro
Complexidade [ ] Simples [ ] Fácil [ ] Médio [ ] Complexo
Malote
Recursos
Rotina
Coordenador
Grupo (Projeto)
Depto. Usuário
Analista
Ramal
Ambiente
Tecnologias adicionais
Banco de Dados
Outros
67
Funcionalidade:
Pré-condições:
Descrição das pré-condições para que a funcionalidade possa ser utilizada.
Ator(es) responsável(is):
Pessoas que usarão o sistema, descrever conforme o cargo.
Pós-condições:
O que deverá ocorrer após a execução da funcionalidade.
Fluxo Principal Deverá ser descrito os passos que serão executados na funcionalidade, em seu fluxo principal. Na tabela deve-se descrever passo-a-passo a funcionalidade, desde a abertura até o fim do fluxo. Nos passos, quando apresenta telas diferentes, pode-se fazer a referencia ao protótipo de tela inserido no documento.
Passo Ação
1
2
N
Fluxos Alternativos Deverá ser descrito os passos de fluxos alternativos, como por exemplo, funcionalidades fora do fluxo principal, ou quando o usuário opta por opções que não fazem parte do fluxo principal da funcionalidade. Pode existir diversos fluxos alternativos, assim como vários passos em cada fluxo.
Fluxo alternativo 1: Título Passo Ação
1
2
N
68
Fluxos de Exceção Deverá ser descrito os passos de fluxos de exceção, esses são os fluxos que podem ser executados em caso de erro na aplicação ou por erro dos dados de entrada, como por exemplo um usuário ou senha não autenticados pelo sistema.
Fluxo de Exceção 1: Título Passo Ação
1
2
N
Regras de Negócio
Neste item, deve-se especificar as regras de negócios da funcionalidade, ou seja, políticas, como por exemplo politicas de segurança que solicita no mínimo seis dígitos em uma senha de usuário.
Pontos de Extensão
Pontos de extensão deve ser especificado quando o fluxo principal executa uma funcionalidade fora do fluxo principal ou alternativo, sendo essa funcionalidade descrita em uma outra especificação técnica.
Instruções de Programa As instruções de programa, é a descrição dos fluxos apresentados no fluxo principal do sistema, ou seja, deve ser descrito como a funcionalidade irá tratar os dados de entrada e saída.
Instrução 1: Título
69
Banco de Dados
Neste caso, quando a funcionalidade utiliza banco de dados, qualquer que seja a operação, deve-se especificar quais tabelas ou Viewes estão sendo utilizadas pela funcionalidade.
Tabelas envolvidas
Viewes envolvidas
Protótipo
Os protótipos, é a representação da interface com o usuário da funcionalidade, onde deve ser inserida a imagem da tela e o domínio dos campos, que são as referencias dos campos de entrada ou saída na tela em relação as tabelas de banco de dados ou as variáveis da funcionalidade.
Protótipo de tela 1:
Domínio de campos: protótipo de tela 1
Ite
m
Descrição Domínio Observação
1
2
N
Controle de Alterações
O controle de alterações tem a funcionalidade de controlar as alterações realizadas neste documento.
Data Responsável Descrição da Alteração
70
ANEXO C – Documento de Gerenciamento de mudanças
Documento Gerenciamento de Mudanças
Emitido em
Responsável
Revisão
Cliente
Projeto
Aprovado em
Introdução
Introdução sobre o documento, e o projeto.
Mudanças
As mudanças solicitadas pelos envolvidos no projeto deverão ser documentadas, conforme esse documento,
apresentando a justificativa pela necessidade de mudança, riscos, e recursos que deverão ser empenhados na
mudança. Essas mudanças devem ser aprovadas e acordadas com o cliente, assistente comercial e gerente de
projetos, pois quando a mudança é grande ou complexa, demanda mudança de escopo do projeto, prazos, além
de custos ao cliente.
Controle de Alterações
O controle de alterações tem a funcionalidade de controlar as alterações realizadas neste documento.
Data Responsável Descrição da Alteração
