UNIVERSIDADE FEDERAL DE UBERLNDIA

FACULDADE DE ENGENHARIA ELTRICA

PROGRAMA DE PS-GRADUAO EM ENGENHARIA ELTRICA

ADEQUAO DO PROCESSO UNIFICADO NO

DESENVOLVIMENTO DE SISTEMAS GRP
(GOVERNMENT RESOURCE PLANNING)

ORIENTADOR: EDGARD LAMOUNIER JR., Ph.D.

CO-ORIENTADOR: ALEXANDRE CARDOSO, Dr.

ORIENTADO: MAURO BORGES FRANA

Uberlndia
2012

UNIVERSIDADE FEDERAL DE UBERLNDIA

FACULDADE DE ENGENHARIA ELTRICA
PROGRAMA DE PS-GRADUAO EM ENGENHARIA ELTRICA

ADEQUAO DO PROCESSO UNIFICADO NO

DESENVOLVIMENTO DE SISTEMAS GRP
(GOVERNMENT RESOURCE PLANNING)

Dissertao apresentada como requisito parcial

obteno do grau de Mestre em Cincias, conferido
pela Universidade Federal de Uberlndia UFU, por
meio da Faculdade de Engenharia Eltrica.

Banca Examinadora:
Edgard Lamounier Junior Orientador UFU
Alexandre Cardoso Co-orientador UFU
Adriano Alves Pereira UFU
Marcos Wagner de Souza Ribeiro UFG

Uberlndia
2012

ADEQUAO DO PROCESSO UNIFICADO NO

DESENVOLVIMENTO DE SISTEMAS GRP
(GOVERNMENT RESOURCE PLANNING)

MAURO BORGES FRANA

Dissertao apresentada perante a banca abaixo como requisito parcial obteno do

grau de Mestre em Cincias, conferido pela Universidade Federal de Uberlndia UFU,
por meio da Faculdade de Engenharia Eltrica.

Prof. Edgard Lamounier Jr. PhD

Orientador

Prof. Alexandre Cardoso, Dr.

Coordenador do Curso de Ps-Graduao

Uberlndia
2012

DEDICATRIA

minha esposa Ana Carolina

Aos meus filhos Guilherme e Vitor
Aos meus pais Toninho e Neusa
Aos meus irmos Mauricio e Marina

AGRADECIMENTOS

Agradeo primeiro a DEUS pelos caminhos que tem proporcionado em minha

vida.
Agradeo a minha esposa Ana Carolina, incondicional apoio para realizao
deste projeto, sempre esteve ao meu lado me apoiando e compreendendo minhas
ausncias em momentos de dedicao a este trabalho. Muito obrigado, amo muito voc.
Aos meus filhos Guilherme e Vitor, meus agradecimentos mais profundos, pois
aceitaram minha ausncia em momentos importantes de suas vidas.
Ao meu pai pelo bom exemplo, companheirismo, afeto, amor e carinho. Mesmo
neste momento difcil de sua vida no deixou de expressar por meio de gestos seu apoio
incondicional.
A minha me iluminada, agradeo o imenso amor e carinho, o que me
proporcionaram muitas alegrias em minha vida, considero uma guerreira por tudo, mas
principalmente pelos momentos atuais.
Aos meus irmos que sempre me apoiaram e torceram por mim em toda minha
trajetria.
Aos meus amigos Edgard e Alexandre que simplesmente canalizaram suas
energias no s em orientaes, mas tambm em motivaes e momentos de amizade.
Este projeto no teria xito sem a participao de vocs e por isso muitssimo obrigado
por tudo.
Aos meus amigos da DTIC que me ajudaram, apoiaram e participaram deste
projeto.
Aos meus amigos professores de computao do IFTM que tambm tiveram
papel fundamental.
Ao Instituto Federal do Tringulo Mineiro pelo acolhimento e reconhecimento
profissional.
Enfim a todos, que direta ou indiretamente participaram neste projeto, meus
sinceros agradecimentos.

SUMRIO
LISTA DE FIGURAS ....................................................................................................... I
LISTA DE TABELAS ................................................................................................... III
RESUMO ....................................................................................................................... IV
ABSTRACT .....................................................................................................................V
1.

2.

Introduo ................................................................................................................. 1
1.1.

Motivao .......................................................................................................... 1

1.2.

Objetivo ............................................................................................................. 4

1.3.

Objetivos Especficos ........................................................................................ 4

1.4.

Estrutura da dissertao ..................................................................................... 5

Fundamentos ............................................................................................................. 6
2.1.

Introduo .......................................................................................................... 6

2.2.

Viso Geral da Engenharia de Software ............................................................ 6

2.3.

Processo de desenvolvimento de software ......................................................... 7

2.4.

Modelos de desenvolvimento de software ......................................................... 9

2.5.

Metodologias geis ......................................................................................... 10

2.5.1.

eXtreme Programming XP .................................................................... 11

2.5.2.

SCRUM .................................................................................................... 14

2.6.

Metodologias Mistas ........................................................................................ 16

2.7.

O Processo Unificado ...................................................................................... 17

2.7.1.

Dirigido por Casos de Uso ....................................................................... 17

2.7.2.

Centrado em arquitetura ........................................................................... 18

2.7.3.

As quatro fases do Processo Unificado .................................................... 19

2.7.4.

Os Cinco WorkFlows ................................................................................ 20

2.7.5.

Iteraes e Incrementos ............................................................................ 21

2.7.6.

Artefatos, trabalhadores e atividades ........................................................ 21

2.7.7.

O Processo Unificado da Rational RUP ................................................ 22

2.8.

Government Resource Planning (GRPs) ......................................................... 23

2.9.

Gerncia de Projetos de Software .................................................................... 24

2.10.

Trabalhos que abordam aspectos de adequaes ......................................... 26

2.10.1. Adequao de processos nas indstrias de software ................................ 26

2.10.2. Adaptao de processos de software ........................................................ 28
3.

Trabalhos Relacionados .......................................................................................... 31

3.1.

Introduo ........................................................................................................ 31

3.2.

Desenvolvimento gil de sistemas de Realidade Virtual ................................. 31

3.3.

Um Mtodo de Desenvolvimento de Sistemas de Grande Porte Baseado no

Processo RUP ............................................................................................................. 32

3.4.

Adaptao do Rational Unified Process (RUP) em pequenas equipes de

Desenvolvimento Distribudo ..................................................................................... 34

4.

3.5.

Integrao do desenvolvimento gil de software ao RUP ............................... 35

3.6.

Sumrio e concluses ....................................................................................... 36

Metodologia Proposta ............................................................................................. 39

4.1.

Introduo ........................................................................................................ 39

4.2.

Objetivo da MDS-GRP .................................................................................... 39

4.3.

Caractersticas .................................................................................................. 40

4.4.

As Fases da MDS-GRP.................................................................................... 41

4.4.1.

Fase de Concepo ................................................................................... 42

4.4.2.

Fases de Elaborao.................................................................................. 44

4.4.1.

Fases de Construo ................................................................................. 46

4.4.2.

Fase de Transio ..................................................................................... 47

4.5.

5.

Papis ............................................................................................................... 48

4.5.1.

Patrocinador do Projeto ............................................................................ 49

4.5.2.

Clientes do Projeto ................................................................................... 49

4.5.3.

Gerente do Projeto .................................................................................... 49

4.5.4.

Coordenador de Sistemas ......................................................................... 50

4.5.5.

Equipe de requisitos ................................................................................. 50

4.5.6.

Equipe de Desenvolvedores ..................................................................... 50

4.5.7.

Equipe de Integrao ................................................................................ 51

4.5.8.

Equipe de Transio ................................................................................. 51

Exemplo de Aplicao GRP do IFTM ................................................................ 52

5.1.

Introduo ........................................................................................................ 52

5.2.

A Empresa........................................................................................................ 52

5.3.

As Equipes ....................................................................................................... 52

5.4.

Contextualizao do problema do estudo de caso ........................................... 53

5.4.1.
6.

O Projeto GRP-IFTM ............................................................................... 54

Resultados e Limitaes da Metodologia ............................................................... 56

6.1

. Introduo ...................................................................................................... 56

7.

6.2

. Avaliao da MDS-GRP ................................................................................ 56

6.3

. Anlise da Metodologia por meio de questionrios ....................................... 62

6.4

Consideraes Finais ....................................................................................... 71

Concluses e Trabalhos Futuros ............................................................................. 72

7.1 Introduo ................................................................................................................. 72

7.2 Concluses ................................................................................................................ 72
7.3 Trabalhos futuros ...................................................................................................... 74
7.4 Consideraes finais ................................................................................................. 74
8.

Referncias ............................................................................................................. 75

ANEXO I Questionrio aplicado ................................................................................. 79

LISTA DE FIGURAS
Figura 1 - Camadas da Engenharia de Software............................................................... 7
Figura 2 - Prticas do XP (Fonte: TELES, 2004). .......................................................... 12
Figura 3 - Viso geral do processo SCRUM (adaptado de SCHWABER, 2004). ......... 16
Figura 4 - Fases e Marcos Principais do Processo Unificado (SCOTT, 2003). ............. 19
Figura 5 - Desenvolvimento Iterativo e Incremental (SCOTT, 2003). .......................... 21
Figura 6 - Viso geral das disciplinas e fases do RUP. .................................................. 22
Figura 7 - Fases, etapas e atividades em um projeto (PFLEEGER, 2004). .................... 25
Figura 8 - Ciclo de vida do desenvolvimento gil de um SRV [extrado de (MATTIOLI
et al., 2009)]. .................................................................................................................. 32
Figura 9 - Fases e disciplinas do mtodo proposto [extrado de (SOUZA et al., 2004)].
........................................................................................................................................ 33
Figura 10 - Fases e marcos do mtodo proposto [extrado de (SOUZA et al., 2004)]... 33
Figura 11 - Processo Adaptao do RUP para DDS [extrado de (ROCHA et al., 2008)].
........................................................................................................................................ 34
Figura 12 - Ciclo de Vida do processo Scrum-RUP [extrado de (ALVES et al., 2011)].
........................................................................................................................................ 36
Figura 13 - Ciclo de Vida do processo MDS-GRP. ....................................................... 41
Figura 14 - Fases da MDS-GRP. .................................................................................... 42
Figura 15 - Fase de Concepo do Projeto. .................................................................... 43
Figura 16 - Fase de Elaborao da MDS-GRP. .............................................................. 45
Figura 17 - Fase de Construo da MDS-GRP. ............................................................. 46
Figura 18 - Fase da Transio da MDS-GRP. ................................................................ 48
Figura 19 - Viso conceitual do projeto GRP-IFM. ....................................................... 55
Figura 20 - Um prottipo de tela para a funcionalidade Gerencia de Demandas. ...... 58
Figura 21 - O Diagrama de Caso de Uso da Funcionalidade "Gerenciar Demandas". .. 59
Figura 22 - Diagrama de Classe da Funcionalidade "Gerenciar Demandas". ................ 60
Figura 23 - Diagrama de Sequencia da funcionalidade "Cadastro de Demanda. ......... 61
Figura 24 - Comunicao entre as equipes de desenvolvimento aps MDS. ................. 63
Figura 25 - Anlise dos artefatos produzidos na MDS. .................................................. 64
Figura 26 - Anlise das interaes com os stakeholders. ............................................... 64

Figura 27 - Anlise de melhores resultados na viso geral do escopo do projeto e em

possveis funcionalidades. .............................................................................................. 65
Figura 28 - Anlise do uso de prottipos de telas. ......................................................... 66
Figura 29 - Anlise do entendimento da equipe de desenvolvimento por meio dos
artefatos produzidos........................................................................................................ 67
Figura 30 - Anlise dos testes de unidade funcional. ..................................................... 68
Figura 31 - Anlise do tempo gasto entre a relao "artefatos x codificao". .............. 69
Figura 32 - Anlise dos resultados obtidos na integrao das equipes do projeto. ........ 70
Figura 33 - Anlise dos resultados quanto ao controle das atividades. .......................... 71

II

LISTA DE TABELAS
Tabela 1 - Perguntas frequentes sobre software. .............................................................. 6
Tabela 2 - Principais termos envolvidos na definio de processos................................. 9
Tabela 3 - Doze princpios de um processo gil ............................................................. 11
Tabela 4 - Caractersticas do paradigma tradicional vs. paradigma gil segundo
(LEFFINGWELL, 2006) ................................................................................................ 16
Tabela 5 - Tabela comparativa entre os trabalhos relacionados. .................................... 37
Tabela 6 - Artefatos padres para fase de Concepo .................................................... 43
Tabela 7 - Artefatos padres para fase de Elaborao.................................................... 45
Tabela 8 - Artefatos padres para fase de Construo de desenvolvimento. ................. 47
Tabela 9 - Artefatos padres para fase de Transio ...................................................... 48
Tabela 10 - Identificao das equipes............................................................................. 53
Tabela 11 - Distribuio dos submdulos entre as equipes ............................................ 55

III

RESUMO
Obter um processo de software adequado ao desenvolvimento confivel, de boa
aderncia e que no dispenda tempo demasiado na gerao de artefatos forte
motivao para responder demandas de mercado, portanto requer pesquisa. Um dos
grandes desafios neste processo adequar as propostas de diferentes metodologias de
desenvolvimento de software realidade de trabalho e fora tarefa de uma equipe de
Tecnologia da Informao. Esta pesquisa prope a adequar uma metodologia baseada
em processos unificados, visando sua adaptao, em particular, ao desenvolvimento de
software para reparties pblicas. Um dos motivos desta proposta se baseou pelo fato
da inexistncia de um padro de desenvolvimento em equipes desta natureza. O
presente estudo trata-se da aplicao de uma metodologia de desenvolvimento de
sistemas para construo de sistema integrado com caractersticas de um GRPs
(Governnement Resource Plannig). Como modelo de aplicao, utilizaram-se trs
projetos com caractersticas prximas nos aspectos de complexidade e fora trabalho.
Estes projetos foram trabalhados por equipes distintas na fbrica de software do
Instituto Federal de Educao, Cincia e Tecnologia do Tringulo Mineiro IFTM.
Para alcanar as metas estabelecidas pesquisa foi aplicada durante seis meses e
apresentou resultados quantitativos quanto definio de processos padres e gerao
de artefatos. Portanto, a pesquisa conduz aplicao dos resultados obtidos em
Instituies com caractersticas semelhantes.
Palavras-Chave: Processo de Desenvolvimento de Software, Processo Unificado,
Metodologias geis, GRPs (Governnement Resource Plannig).

IV

ABSTRACT
Obtaining a suitable and trustful software development process, with good quality and
that not requires great time in generating artifacts is a strong motivation to respond to
market demands. Therefore, it requires strong research. One of the great challenges in
this process is to appropriate different software development methodologies to the
reality of an Information Technology group task force. This research proposes to adjust
a unified process based methodology in order to adapt, particularly, to the software
development within the public sector. One of the reasons for this proposal is based upon
the fact that none development pattern has been established in such groups, yet. The
present study is related to integrated systems that have Government Resource Planning
(GRPs) characteristics. As an application model, three projects that have similar
complexity aspects and task force characteristics have been used. These projects were
undertaken by distinct times within the software factory of the Instituto Federal de
Educao, Cincia e Tecnologia do Tringulo Mineiro IFTM. In order to reach
established goals the research was conducted during six months and has presented
quantitative results when taking the definition of standard patterns and artifacts
generation into account. Therefore, this research conducts to apply the obtained results
in Institutions that holds similar characteristics.

Keywords: Software Development Process Unified Process, Agile Methodology, GRPs

(Governnement Resource Plannig).

1. Introduo
1.1. Motivao
A Engenharia de Software nasceu da necessidade de desenvolver, por mtodos
de engenharia, a produo de programas de computadores, envolvendo processos e
mtricas de tempo, custo, envolvimento de pessoal, resultados e possveis avanos
(SOMMERVILLE, 2011).
Neste contexto, notrio dizer que desenvolver software de qualidade um
grande desafio para as fbricas de software, independente de seu porte. E, encontrar o
processo adequado ao desenvolvimento fator de estudos por vrios pesquisadores no
mundo. O trabalho de Machado (2000) relata que o surgimento de padres
internacionais para processos de software, como a Norma ISO/IEC 12207 e os modelos
de maturidade (CMM, TRILLIUM, BOOTSTRAP e ISO/IEC 15504) influenciaram as
organizaes a direcionar seus esforos no s na definio de processos, mas tambm,
no estabelecimento de mecanismos para melhor-los, continuamente. No entanto, o
desenvolvimento de software continua, em muitos casos, sendo uma atividade
fortemente dependente das habilidades individuais dos desenvolvedores, haja vista que
vrias organizaes ainda no possuem processos definidos e pouco conhecimento
quanto maturidade de processos.
Ressalta-se ainda que as empresas utilizam algum processo de desenvolvimento
de software, seja em pequenos, mdios ou grandes projetos, mesmo que sejam
processos informais. A adoo de metodologias de desenvolvimento orientam os
integrantes do projeto para as atividades, aes e tarefas necessrias para desenvolver
um software de alta qualidade. Um processo, segundo o IEEE, uma sequncia de
passos executados com um determinado objetivo; segundo o CMMI, um conjunto
de aes inter-relacionadas realizadas para obter um conjunto especificado de produtos,
resultados ou servios (PDUA FILHO, 2009).
Fuggetta (2000), Pressman (2006) e Osterweil (1987), afirmam que a qualidade
do processo de desenvolvimento impacta diretamente na qualidade do produto a ser
desenvolvido. Ainda, segundo Greer e Conradi (2009), a necessidade de um processo
definido reconhecida como uma estratgia de reduo de riscos para a gerncia de
projetos. O trabalho apresentado por Bertollo e Falbo (2003), acrescenta que a
1

principal causa dos problemas no desenvolvimento de software a falta de um processo

de desenvolvimento claramente definido e efetivo. Portanto, fica claro que para
reduo de problemas de desenvolvimento de software, reduo de riscos e entrega de
software de qualidade, a adoo de algum processo de desenvolvimento extremamente
importante em projetos desta natureza.
Ainda destacando a importncia no uso de processos de software, notrio dizer
que a adoo destes trazem vrios benefcios para o projeto. Dentre eles destacam-se:

A gerao de artefatos concretos produzidos durante o desenvolvimento do

software tem como objetivo ajudar a descrever as funes, arquitetura e
design do software. Booch, Rumbaugh e Jacobson (2006), afirmam que a
documentao de um projeto de software, a parte central de todas as
atividades que levam implantao bem sucedida de seu produto;

Definio de linguagem nica entre a equipe de desenvolvimento e os

usurios envolvidos no projeto;

Aes para estabelecer que todos os membros da equipe absorvam os

conhecimentos necessrios de todo processo de desenvolvimento do
software;

Identificao dos papis entre os colaboradores, com objetivo de definir as

responsabilidades para cada um dos papis;

Integrao entre as equipes, ou seja, os colaboradores compartilham tarefas

entre diferentes times;

Compartilhar processos comuns para diversos projetos;

Definir critrios para certificao de todos os processos por meio de

auditoria;

Melhorar a qualidade do software. Conforme afirma Koscianski e Soares

(2007) a qualidade de software ainda depende, principalmente, do correto
emprego de boas metodologias pelos desenvolvedores;

Facilitar a participao de novos membros da equipe, aps treinamento;

Permitir que qualquer membro da equipe afaste do projeto para frias ou

outro motivo qualquer, sem parar o processo de desenvolvimento.

Os benefcios citados deixam claro que a adoo de um processo para o

desenvolvimento de qualquer sistema essencial para o sucesso do projeto. Vale
2

destacar que tais processos geram artefatos que caracterizam informaes sobre o
domnio do software em construo e estes so elementos fortemente defendidos neste
trabalho.
A adoo de uma metodologia depende de vrios outros aspectos importantes,
que tambm se destacam:

Tamanho da equipe;

Participao de colaboradores com perfil adequado em conformidade com a

equipe;

Conhecimento dos colaboradores em alguma metodologia j existente;

Experincias anteriores de outras fbricas de software;

Integrao entre os membros das equipes.

Dentre estes processos, destacam-se os mtodos tradicionais e os mtodos geis.

Algumas empresas julgam que o software que produzem pode ser compreendido
simplesmente ao ler seu cdigo-fonte (mtodos geis). Outras fbricas documentam
seus produtos de forma intensiva (mtodos tradicionais) (SHACH, 2009).
Entretanto, centros de desenvolvimento de software de reparties pblicas
apresentam problemas na adoo de mtodos tradicionais ou geis. Isto porque possuem
caractersticas distintas daquelas comumente encontradas nas demais indstrias de
software. Dentre estas se destacam: nmero reduzido de profissionais, alta rotatividade,
processos demorados de licitao, equipes heterogneas, falta de padres, falta de
documentaes ou documentaes incompletas.
Neste sentido, a aplicao dos mtodos tradicionais em reparties pblicas
apresenta como principal problema a necessidade de grandes equipes para atenderem
todas as fases e papis definidos por estes modelos. J os processos geis que,
normalmente, so aplicados em empresas com foco comercial (com o propsito de
busca por maior competitividade, produtividade e lucro), tm se mostrado pouco vivel
para reparties pblicas. De fato, uma vez que so orientadas a codificao, fica a
cargo do desenvolvedor a realizao de cdigos auto-documentveis, podendo ocorrer
riscos devido alta rotatividade e a no transferncia do conhecimento tcito.
Alguns trabalhos de adequaes ou combinaes de metodologias foram
realizados nos ltimos anos. Em destaque o trabalho apresentado em Alves Paim et al.
(2011), que aborda dois aspectos interessantes quanto a investigao desta rea: (1)
3

Muito pouco ainda se sabe sobre os reais benefcios dos mtodos geis, pois at o presente
momento, foram realizados poucos estudos empricos com um padro aceitvel de
confiabilidade e validade (DYB e DINGSYR, 2008)(DYB e DINGSYR, 2009.
(2) Apesar dos esforos para levantar as reais implicaes do uso de mtodos geis e
de sua combinao com abordagens tradicionais, pouca evidncia emprica foi
apresentada at o momento concernente a processos de desenvolvimento de software
(RAMSIN e PAIGE, 2008)(ROMBACH e SEELISCH, 2007). Estas abordagens
evidenciam que a rea ainda pouco explorada e h um nmero ainda pequeno de
pesquisas no que concerne a processos de desenvolvimento de software com adoo de
tcnicas mistas.
Neste escopo, surge como desafio a escolha de uma metodologia mais adequada
para a realidade das reparties pblicas. importante que esta metodologia seja
projetada para permitir agilidade e acompanhamento de todo o processo do setor de
desenvolvimento.

1.2. Objetivo
Este trabalho prope investigar um conjunto de tcnicas computacionais e
gerenciais, adequando a integrao de metodologias de processos unificados e mtodos
geis s caractersticas ambientais do setor de desenvolvimento de software em
reparties pblicas.

1.3. Objetivos Especficos

Avaliar metodologias e processos de software adotados para empresas que

possuem um perfil de pequena e mdia empresa, destacando suas limitaes;

Propor uma metodologia aderente s caractersticas inerentes a uma classe

comum de reparties pblicas, tendo como referncia a fbrica de software
do Instituto Federal de Educao, Cincia e Tecnologia do Tringulo
Mineiro - IFTM;

Desenvolver prova de conceito com a equipe de TI do IFTM;

Avaliar a metodologia proposta por meio de anlises qualitativas;

Apresentar os resultados da aplicao da metodologia e encaminhar

propostas de melhoramentos;

O resultado da avaliao em produtividade da proposta ser por meio de estudo a

ser aplicado no Instituto Federal de Educao, Cincia e Tecnologia do Tringulo
Mineiro localizado na cidade de Uberaba (MG). Neste estudo, sero coletados dados por
meio de questionrios a serem aplicados aos coordenadores de sistemas e
desenvolvedores, e sero analisados junto ao processo de produtividade das equipes.
Estes resultados sero avaliados em relao a situaes anteriores vivenciadas pelas
mesmas equipes que participarem da pesquisa.

1.4. Estrutura da dissertao

Este trabalho est divido em sete captulos. So eles:

Captulo 1 apresenta a contextualizao do problema, a motivao para

pesquisa e os objetivos a serem alcanados com sua aplicao.

Captulo 2 apresenta conceitos e definies necessrias para o

entendimento da proposta, sendo estas definies relacionadas s reas de
conhecimento envolvidas nesta pesquisa. Neste captulo, foram abordadas
algumas metodologias de desenvolvimento, atualmente, aplicadas nas
indstrias de software, tcnicas de gerencia de projetos e conceitos de GRP.

Captulo 3 apresenta a reviso da literatura com alguns trabalhos

relacionados pesquisa em questo.

Captulo 4 apresenta a proposta da MDS-GRP (Metodologia de

Desenvolvimento de Sistemas Governnament Resource Planning),
definindo todas as fases a serem seguidos, os artefatos gerados e os
processos a serem atendidos.

Captulo 5 apresenta o exemplo de aplicao, contextualizando o problema da

realidade antes da pesquisa e demonstrando a estrutura do Projeto GRP-IFTM.

Captulo 6 apresenta os passos utilizados para validar a metodologia

proposta em um dos projetos do estudo de caso. Apresenta tambm uma
anlise dos resultados obtidos, a fim de avaliar a eficcia da proposta.

Captulo 7 apresenta as concluses desta pesquisa e discute sugestes de

trabalhos futuros relacionados ao tema.

2. Fundamentos
2.1. Introduo
Neste captulo so apresentados e discutidos os conceitos fundamentais
relacionados s reas de conhecimento mencionadas nesta dissertao para uma maior
compreenso da pesquisa conduzida.

2.2. Viso Geral da Engenharia de Software

Na sociedade da informao e comunicao, a Engenharia de Software possui
como principal finalidade viabilizar o desenvolvimento profissional de software, por
meio de tcnicas que possibilitam o direcionamento de especificaes, projetos e
evolues de programas. A fim de visualizar, em linhas gerais, conceitos sobre software
e sua engenharia, Sommerville (2011) apresenta perguntas e respostas destinadas
compreenso da dinmica da Engenharia de Software, na Tabela 1.
Tabela 1 - Perguntas frequentes sobre software.
Pergunta
O que software?

Quais so os atributos de
um bom software?
O que engenharia de
software?
Quais so as principais
atividades da engenharia
de software?
Qual a diferena entre
engenharia de software e
cincia da computao?
Qual a diferena entre
engenharia de software e
engenharia de sistemas?

Resposta
Softwares so programas de computador e documentao
associada. Produtos de software podem ser desenvolvidos
para um cliente especfico ou para o mercado em geral.
Um bom software deve prover a funcionalidade e o
desempenho requeridos pelo usurio; alm disso, deve ser
confivel e fcil de manter e usar.
uma disciplina de engenharia que se preocupa com todos
os aspectos de produo de software.
Especificao de software, desenvolvimento de software,
validao de software e evoluo de software.

Cincia da computao foca a teoria e os fundamentos;

engenharia de software preocupa-se com o lado prtico do
desenvolvimento e entrega de softwares teis.
Engenharia de sistemas se preocupa com todos os aspectos
do desenvolvimento de sistemas computacionais, incluindo
engenharia de hardware, software e processo. Engenharia
de software uma parte especfica desse processo mais
genrico.
Quais so os principais Lidar com o aumento de diversidade, demandas pela
desafios da engenharia diminuio do tempo para entrega e desenvolvimento de
de software?
software confivel.
Quais so os custos da Aproximadamente 60% dos custos de software so de
engenharia de software? desenvolvimento; 40% so custos de testes. Para software
customizado, os custos de evoluo frequentemente
6

Quais so as melhores
tcnicas e mtodos da
engenharia de software?

Quais diferenas foram

feitas pela internet na
engenharia de software?

superam os custos de desenvolvimento.

Enquanto todos os projetos de software devem ser
gerenciados e desenvolvidos profissionalmente, tcnicas
diferentes so adequadas para tipos de sistemas diferentes.
Por exemplo, jogos devem ser sempre desenvolvidos
usando uma srie de prottipos, enquanto sistemas de
controle crticos de segurana requerem uma especificao
analisvel e completa. Portanto, no se pode dizer que um
mtodo melhor que outro.
A Internet tornou servios de software disponveis e
possibilitou o desenvolvimento de sistemas altamente
distribudos baseados em servios. O desenvolvimento de
sistemas baseados em Web gerou importantes avanos nas
linguagens de programao e reuso de software.

Fonte: (Sommerville, 2011).

Em virtude dessas especificaes, infere-se que os softwares em todas as suas
formas e campos de aplicao, devem ser desenvolvidos por meio de procedimentos de
Engenharia (PRESSMAN, 2011).

2.3. Processo de desenvolvimento de software

O contexto desta pesquisa volta-se para a adequao do processo unificado para
elaborao de um software governamental. Para isso, torna-se necessrio a compreenso
do que seja um processo de software (ou metodologia de desenvolvimento de software).
Nesse sentido, para indicar a relevncia do processo de desenvolvimento de software no
contexto da engenharia, Pressman (2011) relata que a Engenharia de Software uma
tecnologia estruturada, conforme Figura 1.

Ferramentas
Mtodos
Processo
Foco na qualidade
Figura 1 - Camadas da Engenharia de Software.

Ao analisar a Figura 1, a base para a Engenharia de Software so os processos,

os quais interligam e mantm as dinmicas coesas de tecnologia e possibilitam seu
desenvolvimento racional e tempestivo.

Nessa perspectiva, o processo estabelece os mtodos que devem ser adotados

para a concluso efetiva da tecnologia de Engenharia de Software. Desse modo, o
processo forma a base para o controle da gesto de projetos de software e determina o
contexto no qual so aplicados mtodos tcnicos, gerados os produtos derivados
(modelos, documentos, dados, relatrios, formulrios e entre outros), incluindo a
definio de marcos, em que a qualidade assegurada e as mudanas so conduzidas
adequadamente (PRESSMAN, 2011).
Segundo Pfleeger (2004), um processo uma cadeia de etapas que abrangem
atividades, restries e recursos para conseguir as metas almejadas. Para Pdua Filho
(2009), as definies se voltam para o IEEE no qual este define processo como uma
sequncia de passos realizados para um determinado objetivo. Este autor tambm
emprega os conceitos apresentados no CMMI1 em que processo um conjunto de aes
e atividades interligadas e realizadas para alcanar um grupo especfico de produtos,
resultados ou servios. Por sua vez, Shach (2009), em uma viso mais simplificada,
define processo como o modo pelo qual se produz um software. Pressman (2011) define
processo como um grupo de procedimentos, aes e tarefas efetuadas na formalizao
de algum produto de trabalho. De acordo com Sommerville (2011), um processo de
software um grupo de atividades relacionadas que se destinam fabricao de um
produto de software.
Existe uma proximidade entre todos esses conceitos, porm ao agrup-los
infere-se que processo de software o contguo de atividades agrupadas em etapas que
formam o desenvolvimento de um sistema computacional, a saber: especificao do
projeto, determinao de pr-requisitos, anlise, projeto, desenvolvimento, teste e
implantao. Essas etapas envolvem profissionais que desempenham papis prdefinidos, sendo que tais atividades originam produtos que so definidos como
componentes do sistema.

___________________________
1

CMMI Capability Maturity Model Integration: um modelo de referncia que contm prticas

(Genricas ou Especficas) necessrias maturidade em disciplinas especficas de software.

Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI
procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes
modelos e disciplinas.

Pdua Filho (2009) constri uma tabela (Tabela 2) com os termos essenciais
envolvidos no conceito de processos.
Tabela 2 - Principais termos envolvidos na definio de processos
Termo
Insumo
Papel

Definio
(Praxis) Qualquer coisa que consumida num processo.
(SPEM) Conjunto correlato de proficincias, competncias e
responsabilidades, desempenhado por uma ou mais pessoas.
Etapa
(Praxis) Tempo genrico para uma diviso temporal de um processo.
Processo de
(UML)Conjunto de passos e diretrizes para o desenvolvimento de
desenvolvimento um produto.
Produto
1. (PMBOK) Um objeto produzido, quantificvel, e que pode ser um
item final ou um item componente.
2. (CMMI) Resultado que se pretende entregar a um cliente ou
usurio.
Produto de
1. (SPEM) Qualquer coisa consumida, produzida ou modificada por
trabalho
tarefas.
2. (CMMI) Coisa til que resulta de um processo.
Projeto
1. (CMMI) Conjunto gerido de recursos inter-relacionados, que
entrega um ou mais produtos a um cliente ou usurio, com incio
definido e que, tipicamente, opera conforme um plano. Cf. produto.
2. (PMBOK) Um empreendimento temporrio realizado para criar
um produto, servio ou resultado distinto.
Resultado
(PMBOK) Uma sada dos processos e atividades de um projeto.
Fonte: (Pdua Filho, 2009).

2.4. Modelos de desenvolvimento de software

O primeiro passo na definio do processo de software propor um modelo de
ciclo de vida. Essa proposta ir detalhar a maneira mais apropriada de se satisfazer as
necessidades do usurio, chegando a quando e como este obter a primeira verso
operacional do sistema. Importante destacar que no h modelo ideal, uma vez que o
software depende de fatores como a complexidade do propsito a ser atendido, o tempo
para sua confeco, o custo estimado, a equipe envolvida, o ambiente operacional. Esses
aspectos influenciaro diretamente na opo pelo ciclo de vida de software a ser
elaborado (PFLEEGER, 2004).
Segundo Pfleeger (2004), os ciclos de vida podem se comportar de forma
sequencial (fases seguem determinada ordem) e/ou incremental (diviso de escopo) e/ou
iterativa (retroalimentao de fases) e/ou evolutiva (software aprimorado).

Uma preocupao relevante, a qual ser levantada por toda organizao que
procura adotar uma nova metodologia, a quantidade de empresas que j empregam tal
mtodo, com sucesso, h determinado tempo. Infelizmente, de comum acordo entre
muitos grupos de TI de instituies pblicas que no existe praticamente nada
determinado estatisticamente. necessrio valer-se de alguns poucos estudos,
conduzidos informalmente, para verificar as tendncias do mercado.

2.5. Metodologias geis

Na sociedade contempornea, as metodologias geis tm concentrado o interesse
das indstrias de software no mercado mundial, expressando evidncias em diferentes
casos na melhoria da produtividade. Ressalta-se que a iniciativa para criao de
mtodos geis iniciou-se em 2001, motivados pela viso de que os profissionais que
lidam com o desenvolvimento de software nas mais diversas organizaes se
encontravam presos a processos cada vez mais burocrticos. Para tanto, um grupo de
profissionais e pesquisadores de TI, coligaram-se para traar valores e princpios de
desenvolvimento de software que viabilizaram, s equipes de desenvolvimento,
produzi-lo rapidamente e responder s mudanas. Esses pioneiros da metodologia gil
intitularam-se de Aliana gil, trabalhando por dois dias para criar tais valores. O
resultado foi o Manifesto da Aliana gil (MARTIN, 2002), apesar de que estas
metodologias que compem o movimento gil esto no mercado h alguns anos, sob a
designao de metodologias leves. Desde ento, o Manifesto gil considerado
oficialmente como o incio do movimento gil.
Os conceitos chave do Manifesto gil so:

Indivduos e interaes mais que processos e ferramentas;

Software em funcionamento mais que documentao abrangente;

Colaborao com o cliente mais que negociao de contratos;

Responder a mudanas mais que seguir um plano (BECK et al., 2001).

Alm dos conceitos chaves, esse Manifesto tambm enuncia os doze princpios
de um processo gil, conforme apresentado na Tabela 3 (BECK et al., 2001).

10

Tabela 3 - Doze princpios de um processo gil

ID
P1

Princpio
A prioridade satisfazer ao cliente atravs de entregas contnuas e
frequentes;
P2
Receber bem as mudanas de requisitos, mesmo em uma fase avanada do
projeto;
P3
Entregas com frequncia, sempre na menor escala de tempo.
P4
As equipes de negcio e de desenvolvimento devem trabalhar juntas
diariamente;
P5
Manter uma equipe motivada fornecendo ambiente, apoio e confiana
necessrios;
P6
A maneira mais eficiente da informao circular atravs de uma conversa
face-aface;
P7
Ter o sistema funcionando a melhor medida de progresso;
P8
Processos geis promovem o desenvolvimento sustentvel;
P9
Ateno contnua a excelncia tcnica e a um bom projeto aumentam a
agilidade;
P10
Simplicidade essencial;
P11
As melhores arquiteturas, requisitos e projetos provm de equipes
organizadas;
P12
Em intervalos regulares, a equipe deve refletir sobre como se tornar mais
eficaz.
Fonte: (Beck et al., 2001).
Com base nesses princpios, segundo Abrahamsson (2003), uma metodologia
considerada gil quando efetua o desenvolvimento de software de modo incremental
(disponibilizao de pequenas verses, em iteraes de curta durao), colaborativa
(investidor e profissionais do software trabalhando juntos, em permanente interao),
direta (mtodo simplificado de aprender e modificar) e adaptativa (hbil em responder
s mudanas at o ltimo instante).
Nesse conceito, destacam-se as seguintes metodologias geis: Extreme
Programming (XP), Scrum, Crystal, Feature Driven Development (FDD), Dynamic
Systems Development Method (DSDM), Open Source Software Development. Embora
esses mtodos utilizem princpios semelhantes, so diferentes em suas prticas e formas
de conduo do processo de desenvolvimento. Dentre os mtodos mais utilizados pela
indstria de software destaca-se o XP e o SCRUM (PADUA FILHO, 2009).

2.5.1. eXtreme Programming XP

O XP um modelo gil de desenvolvimento de software inventado, na dcada
de 1990, mais especificamente em 1996, por Kent Bech no departamento de
11

computao da montadora de carros Daimler Chyrsler. Esse modelo detm vrias

diferenas em relao a outros modelos, j que pode ser empregado em projetos de alto
risco e com pr-requisitos dinmicos, conduzidos por equipes de tamanhos mdio e
pequeno (TELES, 2004).
Como toda metodologia gil, o XP busca responder com velocidade as
mudanas nas especificaes do projeto, com base em princpios, valores e prticas
bastante delineados. Esse mtodo reala o desenvolvimento rpido, assegurando a
satisfao do cliente e cumprindo as estimativas do projeto.
A Figura 2 apresenta todas as prticas do XP de forma resumida.

Figura 2 - Prticas do XP (Fonte: TELES, 2004).

O XP baseia-se em cinco valores que compem o desenvolvimento:

comunicao, coragem, feedback, respeito e simplicidade. Segundo Beck et al. (2001),
o mtodo oferece ainda 12 prticas, a saber:

Planejamento: momento em que se decide o que precisa ser feito e o que

pode ser adiado no projeto, lembrando que a XP se fundamenta em
requisitos atuais para seu desenvolvimento e no em requisitos futuros.

Entregas frequentes: a construo do software deve ser simples e,

conforme as necessidades aparecem, h uma atualizao do mesmo.
12

Metfora: so descries do software sem os termos tcnicos, promovendo

a compreenso do cliente e direcionando o desenvolvimento de software.

Projeto simples: o programa construdo pelo mtodo XP precisa ser o mais

simples possvel e atender aos requisitos atuais, no se preocupando com os
requisitos futuros.

Testes: XP enfoca a validao do projeto durante o processo de

desenvolvimento, fazendo com que os profissionais programem o software
criando inicialmente os testes.

Refatorao: deve ser realizada somente se for necessria, ou seja, quando

um dos profissionais da dupla, ou os dois, notam que possvel simplificar o
mdulo atual sem perder nenhuma funcionalidade.

Programao em pares: o desenvolvimento do cdigo realizado em

dupla, ou seja, dois profissionais trabalham em um nico computador.
Enquanto um deles est no controle do teclado e do mouse implementando o
cdigo, o outro observa ininterruptamente o trabalho que est sendo
realizado, buscando reconhecer os erros sintticos e semnticos e analisando
como se pode aprimorar o cdigo que est sendo desenvolvido. Esses papis
podem e devem ser alternados sucessivamente, viabilizando a aprendizagem
mtua.

Propriedade coletiva: o cdigo do projeto pertence a todos os membros da

equipe. Isto implica dizer que todos os profissionais ao notarem que podem
adicionar valor a um cdigo, ainda que no o tenha desenvolvido, pode
efetu-lo, desde que implemente a bateria de testes necessria. O grande
benefcio dessa prtica que, se um membro da equipe deixar o projeto antes
de sua finalizao, a equipe consegue continuar o projeto sem dificuldades,
uma vez que todos conhecem as partes do software, mesmo que no seja de
forma aprofundada.

Integrao contnua: a ideia interatuar e arquitetar o sistema de software

continuamente, mantendo os programadores em sintonia, possibilitando
processos geis.

40 horas de trabalho semanal: XP sugere no ser necessrio fazer horas

extras excessivamente. Caso seja preciso trabalhar mais de 40 horas pela
segunda semana consecutiva, h um problema grave no projeto que deve ser
13

solucionado no com o aumento de horas trabalhadas, mas sim com melhor

planejamento.

Cliente presente: o cliente necessita estar disponvel para solucionar todas

as imprecises, a fim de evitar atrasos e at mesmo construes equivocadas
no software.

Cdigo padro: uniformizao na arquitetura do cdigo, para que possa ser

partilhado entre todos os profissionais da equipe.

2.5.2. SCRUM
Outra metodologia gil que apresenta uma comunidade grande de usurios o
Scrum (BEEK, 1999). Sua meta oferecer um processo apropriado para o projeto cujo
desenvolvimento orientado a objeto. O Scrum detm uma abordagem emprica que
adota ideias da teoria de controle de processos industriais no desenvolvimento de
softwares, reinserindo conceitos de flexibilidade, adaptabilidade e produtividade. O foco
do mtodo encontrar uma maneira para que os profissionais da equipe atuem de forma
flexvel para se produzir o software em um ambiente de constantes mudanas.
A ideia principal do Scrum que o desenvolvimento de softwares envolve
diferentes variveis tcnicas e de ambiente: requisitos, recursos e tecnologia, que podem
ser alterados durante o processo. Isso faz com que o processo de desenvolvimento seja
imprevisvel e complexo, demandando flexibilidade para acompanhar as mudanas. O
resultado do processo deve ser um software que realmente til para o cliente
(SCHWABER, 2004).
Importante ressaltar que metodologia do Scrum anloga aos princpios da XP:
equipes menores, requisitos pouco estveis ou desconhecidos e iteraes curtas para
gerar visibilidade no desenvolvimento. Entretanto, as dimenses em Scrum diferem de
XP (SOMMERVILLE, 2011).
O Scrum decompe o desenvolvimento em iteraes (sprints) de trinta dias.
Equipes pequenas, compostas por at dez profissionais, so constitudas por projetistas,
programadores, engenheiros e gerentes de qualidade. Essas equipes atuam voltadas para
as funcionalidades (os requisitos, em outras palavras), determinadas no incio de cada
sprint, sendo a equipe responsvel pelo desenvolvimento desta funcionalidade
(SCHWABER, 2004).
14

No Scrum, segundo Schwaber (2004), h reunies dirias de acompanhamento,

sendo de curta durao (por volta de quinze minutos), nas quais so discutidos os pontos
realizados desde o ltimo encontro, definindo o que precisa ser desenvolvido at a
prxima sesso. As dificuldades localizadas e os fatores de impedimento (bottlenecks)
so reconhecidos e solucionados. O ciclo de vida do Scrum, de acordo com Schwaber
(2004), subdividido em trs fases principais. A seguir o detalhamento destas fases e a
Figura 3 representa de forma grfica o processo.

Pr-planejamento (Pre-game phase): os requisitos so descritos em um

documento denominado backlog. Em seguida, so priorizadas e apresentadas
as estimativas de empenho para o desenvolvimento de cada requisito. O
planejamento inclui, entre outras atividades, a delimitao da equipe de
desenvolvimento, as ferramentas a serem empregadas, os provveis riscos do
projeto, bem como as demandas de treinamento. Aps o planejamento,
sugerida uma arquitetura de desenvolvimento, sendo que eventuais
mudanas nos requisitos detalhados no backlog so reconhecidos, bem como
seus possveis riscos.

Desenvolvimento (game phase): as diferentes variveis tcnicas e de

ambiente so reconhecidas antecipadamente, observadas e dominadas
durante o desenvolvimento. Ao invs de considerar essas variveis apenas no
incio do projeto, como no caso das metodologias tradicionais, no Scrum o
controle feito continuamente, o que aumenta a flexibilidade para
acompanhar as mudanas. Nesta fase o software desenvolvido em ciclos
(sprints) em que novas funcionalidades so adicionadas. Cada um desses
ciclos desenvolvido de forma tradicional, ou seja, primeiramente faz-se a
anlise, em seguida o projeto, implementao e testes. Cada um desses ciclos
planejado para durar de uma semana a um ms.

Ps-planejamento (post-game phase): aps a fase de desenvolvimento so

realizadas reunies para avaliar o progresso do projeto e apresentar o
software atual para os clientes. Nessa etapa, so efetuadas a integrao, os
testes finais e a documentao.

15

Figura 3 - Viso geral do processo SCRUM (adaptado de SCHWABER, 2004).

2.6. Metodologias Mistas

Nas ltimas dcadas foram criadas vrias estratgias de desenvolvimento de
software, conforme Rasmsin e Paige (2008), normalmente, apoiadas em metodologias
geis ou convencionais. Segundo Alves Paim et al. (2011), a natureza complexa do
desenvolvimento de software e a ampla variedade de mtodos existentes geram
comparaes difceis e imprecisas entre metodologias geis e tradicionais. Nessa
perspectiva, Leffingwell (2006) discute essas diferenas, as quais so sumarizadas na
Tabela 4.

Tabela 4 - Caractersticas do paradigma tradicional vs. paradigma gil segundo

(LEFFINGWELL, 2006)
Ponto de vista
Medida de sucesso
Cultura gerencial
Requisitos e arquitetura
Garantia de teste e
qualidade
Planejamento e
cronograma

Tradicional
Conformidade com o plano
Chefia e controle
Grande e no incio
Grande, planejado/teste
tardio.
Detalhado, escopo fixo,
tempo e recursos estimados.

gil
Resposta mudana, cdigo
operacional.
Liderana / colaborao
Contnuo / emergente
Contnuo / concorrente / teste cedo.
Planejamento em dois nveis, data
fixa, escopo estimado.

Fonte: (Alves Paim, 2011).

Sumariamente, nota-se que, enquanto o padro tradicional tem sido indicado a
projetos de larga escala e alto risco, o paradigma gil tem se mostrado mais adequado
para projetos de baixo risco e de equipes pequenas (BOEHM; TURNER, 2004;
LINDVALL; COSTA, 2004; COHEN; NORD; TOMAYKO, 2006; RAMSIN; PAIGE,
2008). Normalmente, os grandes projetos crticos podem ser prejudicados pela ausncia
16

de rigor e previsibilidade dos mtodos geis, ao passo que projetos de menor porte e de
baixo risco podem ter um custo e prazo elevados sem necessidade, por falta de
simplicidade e flexibilidade da abordagem tradicional, que comumente impe
procedimentos complexos e documentao ampla. Diante de todos esses julgamentos, a
adaptao de metodologias se tornou uma prtica comum na adeso ao processo de
produo de software. Dessa forma, as indstrias de software buscam customizar os
processos de software em sintonia com sua estrutura organizacional.

2.7. O Processo Unificado

O Processo Unificado enquadra-se no conceito geral de processo: um conjunto
de aes efetuadas para transpor os pr-requisitos do cliente em um sistema de software.
Por sua vez, o Processo Unificado uma estrutura generalizada que pode ser
personalizada, adicionando-se ou eliminando-se atividades segundo as necessidades
particulares do cliente, pautadas nos recursos orados para um projeto (SCOTT, 2003).
O Processo Unificado faz uso extensivo da Unified Modeling Language UML,
cujo ncleo est o modelo, o qual na dinmica de um processo de desenvolvimento de
software uma simplificao da realidade que colabora na compreenso da
complexidade inerente a sistemas de software (SCOTT, 2003).
Nesse contexto, segundo Scott (2003), a UML foi projetada para subsidiar os
profissionais que compartilham as atividades de desenvolvimento de software, ao
auxiliar na visualizao do sistema, detalhando sua estrutura e seu comportamento,
auxiliando na sua construo, alm de documentar as decises necessrias durante o
processo. Muitas das tarefas que o Processo Unificado envolve, abarca uso de UML
associado a um ou mais modelos. Suas atividades so baseadas num princpio de
trabalho iterativo e incremental. Isto , um conjunto repetitivo de tarefas e reunies que
apresentam um aumento da produtividade tanto de artefatos quanto do produto, a cada
iterao. A seguir, sero apresentadas algumas caractersticas do Processo Unificado.

2.7.1. Dirigido por Casos de Uso

Um Caso de Uso uma sequncia de aes, executadas por um ou mais atores
(pode ser pessoas ou entidades no humanas fora do sistema) e pelo prprio sistema,
que produz um ou mais resultados de valor para um ou mais atores (JACOBSON;
BOOCH; RUMBAUGH, 1999). Um dos principais aspectos do Processo Unificado a
17

utilizao dos Casos de Uso como forma condutora do processo de desenvolvimento de

sistemas. A expresso dirigido por Casos de Uso refere-se ao fato de se utiliz-los
para dirigir todo o trabalho de desenvolvimento, desde a captao inicial e negociao
de requisitos at a aceitao do cdigo (SCOTT, 2003).

2.7.2. Centrado em arquitetura

O termo centrado em arquitetura serve como alicerce para fundamentar o
sistema como um todo. Inclui-se no entendimento deste termo aspectos como
desempenho,

escalabilidade,

reuso

restries

econmicas

tecnolgicas

(JACOBSON; BOOCH; RUMBAUGH, 1999).

Segundo Scott (2003), no contexto do Processo Unificado, a arquitetura
especifica os elementos necessrios para descrio da arquitetura.

Entendendo a Viso Global: Seguindo a modelagem de forma minuciosa

e dada a devida ateno construo dos diagramas UML, isto associada
ao texto de apoio, contribuiro em muito para tornar a descrio da
arquitetura o eixo central para um melhor entendimento da viso
global do novo sistema.

Organizando o Esforo de Desenvolvimento: Definio dos padres

arquitetnicos, a fim de auxiliar a dar forma ao esforo de
desenvolvimento em vrios nveis. (Cliente/servidor, trs camadas e N
camadas so exemplos de padres bem conhecidos).

Facilitando as Possibilidades de Reuso: Permitir que as equipes de

desenvolvimento identifiquem oportunidades para possveis reuso de
qualquer outro componente de outros sistemas facilita o trabalho e
otimiza tempo.

Facilitando a Evoluo do Sistema: Estabelecer uma arquitetura slida

para oferecer um conjunto de pontos de referncia essenciais sobre os
quais o trabalho de desenvolvimento futuro poder se apoiar.

Dirigindo os Casos de Uso: Os Casos de Usos dirigem a arquitetura de

um sistema, pois dirigem o esforo de desenvolvimento.

18

2.7.3. As quatro fases do Processo Unificado

A vida de um sistema de software pode ser representada como uma srie de
ciclos. Cada ciclo termina com a liberao de uma verso do sistema para os clientes.
No Processo Unificado, cada ciclo contm quatro fases. Uma fase simplesmente o
tempo decorrido entre dois marcos principais, em que gerentes tomam decises
importantes sobre se prosseguem com o desenvolvimento e, se este for o caso, o que
necessrio em relao ao escopo, oramento e cronograma do projeto (SCOTT, 2003).
A Figura 4 apresenta as fases e os principais marcos do Processo Unificado.
Nesta figura, pode-se observar que cada fase contm uma ou mais iteraes (SCOTT,
2003).
Concepo

Iterao 1

Objetivos do
Ciclo de Vida

Elaborao

Construo

Transio

Iterao 2

Iterao x + 1

Iterao y + 1

.
.
.

.
.
.

.
.
.

Iterao x

Iterao y

Iterao z

Arquitetura do
Ciclo de Vida

Capacidade
Operacional Inicial

Liberao do
Produto

Figura 4 - Fases e Marcos Principais do Processo Unificado (SCOTT, 2003).

A seguir so apresentadas vises gerais de cada fase do Processo:

Concepo: O objetivo principal da fase de Concepo estabelecer a

viabilidade do sistema proposto. A definio do escopo, a arquitetura
candidata, a anlise econmica so os aspectos predominantes desta fase.

Elaborao: Esta fase tem como principais aspectos a captura dos requisitos
funcionais vlidos restantes, estabelecer uma base arquitetnica, abordar os
possveis riscos significativos e preparar o plano para orientar a prxima fase
(construo).

Construo: Nesta fase fica a responsabilidade da construo do sistema em

questo. Este dever ser capaz de operar bem em ambientes de teste, onde o
prprio cliente os realiza.

Transio: O principal objetivo da fase de Transio entregar o sistema

completamente funcional aos clientes. O principal marco associado fase de
Transio chamado de Liberao do Produto.

19

2.7.4. Os Cinco WorkFlows

O Processo Unificado trabalha com cinco fluxos que atravessam as quatro fases
do modelo: Requisitos, Anlise, Projeto, Implementao e Teste.

Requisitos: Alguns aspectos devem ser observados para definir as atividades

do fluxo de requisitos, por exemplo, a definio do campo de atuao que o
projeto ir operar. O campo poder ser um banco ou uma indstria. Alm do
campo o modelo de negcio que em linhas gerais a necessidade do produto
desejado na forma conceitual. Outro ponto importante e que deve ser
destacado busca pelo refinamento dos requisitos, que acontece por meio de
reunies entre os membros da equipe de requisitos e os clientes, detectando
as funcionalidades do produto em questo (SCHACH, 2009).

Anlise: O objetivo do fluxo de Anlise analisar as necessidades dos

clientes para obteno dos detalhes a serem compreendidos a fim de resultar
no desenvolvimento correto do projeto de software e que facilite a sua
manuteno futura. Para exemplificar melhor seria o fluxo de requisitos
como a necessidade do cliente expressa em texto natural como portugus e o
fluxo de Anlise expresso em notao UML que facilite a compreenso dos
trabalhadores para os fluxos de trabalho de projeto e de implementao.
(SCHACH, 2009).

Projeto: Para o fluxo de projeto cabe a construo do modelo ideal, ou seja,

o que o produto deve fazer e demonstra como o produto ir fazer isso. De
certa forma o fluxo de projeto ir refinar os artefatos do fluxo de anlise at
que o material fique com uma forma que possa ser implementado pelos
desenvolvedores (SCHACH, 2009).

Implementao:

fluxo

de

implementao

descreve

como

ser

implementado os elementos do fluxo de projetos, tais como os cdigosfonte, as bibliotecas e os componentes executveis do sistema (SCOTT,
2003).

Teste: As principais atividades do fluxo de teste visam construo do

modelo de teste que sero realizados nas unidades funcionais do sistema.
Este modelo ser por meio de casos de testes que sero derivados de Casos
de Uso, onde os testadores efetuam teste de caixa-preta usando o texto
20

original de Casos de Uso e o teste de caixa-branca das realizaes destes

Casos de Uso, como especificado no modelo de anlise.

2.7.5. Iteraes e Incrementos

Outro aspecto de grande relevncia ao PU ser iterativo e incremental, onde
cada fluxo de trabalho consiste em uma srie de etapas, e, para realizar esses fluxos de
trabalho, as etapas destes fluxos so realizadas repetidamente, at que os membros da
equipe de desenvolvimento fiquem satisfeitos por terem chegado a um modelo UML
acurado do produto de software que querem desenvolver (SCHACH, 2009).
A natureza dos produtos de software tal que praticamente tudo tem de ser
desenvolvido de modo iterativo e incremental. De acordo com que o projeto de software
caminha os melhores diagramas UML possveis so elaborados, ou seja, medida que
acumulado mais conhecimento sobre o sistema real que est sendo modelado, os
diagramas vo se tornando mais precisos (iterao) e abrangentes (incrementao)
(SCHACH, 2009).
A Figura 5 apresenta a essncia do enfoque iterativo e incremental para
desenvolvimento de software.

Figura 5 - Desenvolvimento Iterativo e Incremental (SCOTT, 2003).

2.7.6. Artefatos, trabalhadores e atividades

Para cada Workflow do Processo Unificado sero envolvidos elementos chaves
para sua aplicao (SCOTT, 2003):

Artefatos: Qualquer informao envolvida no projeto pode ser considerada

um artefato de sistema, por exemplo, os diagramas UML, os prottipos de
21

interface, textos, cdigos fontes ou quaisquer outros documentos envolvidos

na construo do sistema.

Trabalhadores: O Trabalhador definido pelo Processo Unificado como um

papel que uma pessoa ir desempenhar no projeto. Qualquer indivduo
poder atuar como mais de um tipo de trabalhador.

Atividades: Cada workflow contm vrias atividades dentro do projeto,

portanto tais atividades vo desde a construo do modelo de domnio at
implementao de uma classe.

2.7.7. O Processo Unificado da Rational RUP

Segundo Scott (2003) o RUP (Rational Unified Process) uma instncia
especfica e fortemente detalhada do Processo Unificado. O RUP um produto
comercializado pela IBM Rational pelo site www.rational.com/products/rup.
O RUP uma metodologia para gerenciar projetos de desenvolvimento de
software que usa o UML como ferramenta para especificao de sistemas. O RUP
composto por um conjunto de disciplinas que fornecem diretrizes para definio das
tarefas e para atribuio das responsabilidades. A Figura 6 apresenta as disciplinas e
fases do RUP.

Figura 6 - Viso geral das disciplinas e fases do RUP.

O objetivo do RUP garantir a criao de softwares de alta qualidade, que

atendam s necessidades expressas pelo cliente e pelos usurios, e s restries de prazo
22

e custo. Conforme mencionado no Processo Unificado o RUP tambm baseado em

desenvolvimento iterativo e incremental, gerenciamento de requisitos, arquitetura
baseada em componentes, modelagem visual do software, verificao constante da
qualidade e controle de mudanas (MARTINS, 2006).

2.8. Government Resource Planning (GRPs)

Atualmente, a sociedade est em plena transformao social e econmica, que
alcana todos os setores, incluindo as instituies governamentais, que necessitam
reorganizar-se para se adaptarem nova realidade. Esse novo panorama demanda novos
modelos de gesto integrada, voltada para a excelncia, respeitando-se suas
caractersticas e particularidades (FERRER et al., 2004).
Esse novo modelo, conforme Ferrer et al. (2004) denomina-se Government
Resource Planning (GRP), em portugus Sistema Integrado de Gesto Pblica e possui
como foco basilar o gestor pblico, profissional-chave para tal mudana. De fato, o
GRP oferece ao gestor pblico um Painel de Controle densamente articulado aos fatos e
dados, viabilizando tomar decises com respostas cleres e eficientes, mesmo com
recursos humanos e financeiros insuficientes.
Como o GRP so sistemas baseados em ERP (Enterprise Resource Planning)
Mendes et al. (2002) considera-se que esse modelo consiste em:

Reviso e automao de processos de negcio;

Estratgias de redimensionamento, realocao, capacitao e valorizao do

servidor pblico;

Reduo de custos;

Melhoria da qualidade dos servios prestados.

O GRP traz aos rgos da Administrao Pblica ganhos em escala, pois os

dados e fatos tornam-se transparentes, pois permitem centralizar ou descentralizar
decises e operaes, diminuindo os custos, alm de aperfeioar o relacionamento com
rgos, setores, poderes relacionados e o cidado, realizando o ajuste fiscal de modo
certo e irreversvel (FERRER et al., 2004).
Nessa linha de raciocnio, o GRP permite reinventar os processos, uma vez que
automatiza os processos-meios, assegurando a incorporao de novas formas de criao
de valor, ao deslocar os recursos humanos e fsicos das atividades-meio para as
23

atividades-fim (FERRER et al., 2004). Dessa forma, valorizam-se os profissionais e as

equipes, j que o servidor ter uma valorizao voltada para as oportunidades de exercer
e cumprir seu papel, com qualidade e eficincia. Essa estabilizao ser construda ao
longo do processo de transformao, mediante a adaptabilidade individual, por meio de
aes de capacitao, requalificao e integrao.
Com efeito, o GRP leva ao aumento na qualidade, porque aprimora a interface
homem/mquina

na

prestao

de

servios

(internos

externos),

alterando

comportamentos, expectativas, cultura de servio, confiabilidade, segurana, entre

outras dimenses da qualidade de vida (FERRER et al., 2004).
Configura-se, segundo Ferrer et al. (2004), uma nova imagem do Servio
Pblico, porquanto alm das implicaes financeiras (imediatas), esse Novo Modelo de
Gesto produz resultados qualitativos de natureza comportamental, que dinamiza as
mudanas na opinio pblica pelo reconhecimento da qualidade dos servios
proporcionados. Nesse cenrio, assegura ao gestor maior visibilidade dos processos e
maior domnio sobre os resultados de suas deliberaes. Na verdade, o administrador
pblico tem garantido o amparo legal de suas decises e a continuidade de suas aes.

2.9. Gerncia de Projetos de Software

O gerenciamento de projetos, segundo Martins (2006) tem evoludo desde a
dcada de 60. Na realidade, os grandes desafios do sculo XXI, os quais sugerem a
necessidade no aumento da eficincia em todas as atividades, viabilizaram a difuso do
conceito de gerncia de projetos de software e sua utilizao. Importante ressaltar que a
disciplina gerncia de projetos originou-se junto indstria blica e aeroespacial
americana, sendo posteriormente utilizada na construo civil e em outras reas da
engenharia.
Na atualidade, o seu conceito passou a ser estendido a diversos segmentos da
economia, inclusive Engenharia de Software. O Project Management Institute (PMI)
precursor na uniformizao e propagao desse conhecimento.

Realmente, o PMI

especificou uma gama de procedimentos que objetivam padronizar a teoria associada

gerncia de projetos. A teoria de gesto definida pelo PMI est registrada em um
documento chamado Project Management Body Of Knowledge (PMBOK) (MARTINS,
2006).
24

Nas pesquisas de Pdua Filho (2009), conforme o PMBoK [PMI04], um projeto

um esforo temporrio empreendido para criar um produto, servio ou resultado
exclusivo. Nesse sentido, o gerenciamento de projetos de software tornou-se uma
dimenso efetiva da engenharia de software, uma vez que os projetos necessitam ser
gerenciados, considerando-se que a engenharia de software profissional est
subordinada aos oramentos organizacionais e restries de cronograma.
Para Sommerville (2011), a principal atribuio do gerente de projetos
assegurar que o software atenda e supere tais restries, alm de fornecer ao mercado
produtos de alta qualidade. Destaca que o xito do projeto no assegurado apenas por
um gerenciamento adequado. Contudo, o mau gerenciamento normalmente
consequncia da falha do projeto, j que o software geralmente entregue com atraso,
aumentando os custos em relao ao inicialmente estimado, quando no se consegue
satisfazer as expectativas dos clientes.
O ciclo de vida de desenvolvimento de software, conforme Pfleeger (2004)
detm diferentes etapas, sendo que h aquelas que so repetidas at que o produto esteja
concludo, com a concomitante satisfao dos usurios. Dessa forma, os projetos de
software podem ser divididos e implementados em uma sucesso de fases, sendo que
cada fase comporta diferentes etapas, podendo estas serem subdivididas, quando
necessrio, a exemplo da Figura 7.

Figura 7 - Fases, etapas e atividades em um projeto (PFLEEGER, 2004).

No entanto, antes de utilizar os recursos destinados a projeto de

desenvolvimento e/ou manuteno de software, normalmente o cliente busca uma
estimativa do valor do projeto e qual ser a sua durao.
25

2.10.Trabalhos que abordam aspectos de adequaes

2.10.1. Adequao de processos nas indstrias de software
Um processo fabril forma-se na confeco de produtos em massa, inclusive
operaes centralizadas de ampla escala, atividades simples e padronizadas, controles
uniformizados, funcionrios especializados, mas com poucas habilidades, para a
separao de trabalho, mecanizao e automao do processo. Dessa maneira, a
vinculao do termo indstria ao desenvolvimento de software prope que se apliquem
tcnicas para produo em ampla escala, de modo coordenado e com qualidade.
Entretanto, na questo especfica de uma fbrica de software, demanda uma
organizao mais totalizante, que considere diferentes fatores como gesto de pessoas,
gesto empresarial, qualidade de software, melhoria de processos e de produtos, uso de
ferramentas, entre outros. Nesse cenrio, a pesquisa de Rocha et al. (2004) concentra no
fator processo de desenvolvimento, provendo um mapeamento desde os tipos de
processo segundo sua execuo at as diferentes concepes de indstria de Software.
Nos anos recentes, Greenfield (2003 apud ROCHA et al., 2004) nos apresenta
uma viso semelhante, onde o conceito de Fbrica de Software est motivado no
desenvolvimento fundamentado em elementos, direcionados a modelos e a linhas de
produto de software que distinguiriam uma iniciativa de fbrica, objetivando tornar a
montagem de aplicaes mais barata por meio de reutilizao sistemtica, viabilizando a
formao de cadeias de produo.
Para Fernandes (2004) as fbricas de software detm um processo estruturado,
manipulado e aperfeioado de maneira contnua, considerando os enfoques de
engenharia industrial, direcionado para o atendimento a diferentes demandas de carter
e escopo distintos. Tudo isso para objetivar a gerao de produtos de software, segundo
os requerimentos registrados dos usurios e/ou clientes, da maneira mais produtiva e
econmica possvel.
Normalmente, o processo de software pode ser entendido como o conjunto de
atividades indispensveis para transpor os requisitos do usurio em software. Assim
sendo, um processo de software constitudo por um conjunto de fases parcialmente
ordenadas, relacionados a conjuntos de artefatos, pessoas, recursos, estruturas
organizacionais e restries e tem como objetivo produzir e manter os produtos de
26

software finais requeridos. Desse modo, diferentes tipos de informao devem ser
agregados em um modelo de processo para indicar quem, quando, onde, como e por que
os comandos so efetivados.
No processo tradicional, diferente do processo gil, existe certa burocracia, j
que integra mais tarefas para as suas aes. Assim, pode haver inadaptabilidade, em que
a realidade (prazo, escopo, processo, pessoas) diferente do planejado / registrado, e
fundamentado em workflows de processo; direcionado a planejamentos; segurana alta
de desenvolvimento; equipes e produtos amplos; projetado para apoiar requisitos
correntes e desconhecidos. Dessa forma, o modelo de desenvolvimento de software
completo, inclusive suporte a ferramentas; atributos centrados nos fins das atividades;
viabiliza ser instanciado e padronizado segundo o domnio da aplicao ou da
organizao.
Por sua vez, no processo gil, a escala por equipes grandes ou dispersas e a
mudana de cultura organizacional revisa-se o cdigo constantemente. Dessa maneira, a
equipe testar o software incluindo o cliente, alm tornar a atividade diria, com
arquitetura que ser definida e apurada todo o momento. No processo gil, existem
interaes curtas caracterizadas por minutos e horas, pois se constitui de mdulos no
nvel de desenvolvimento do processo; orientado para as pessoas (ROCHA et al., 2004).
Nesse panorama, nas fbricas de software voltadas apenas para o cdigo, que
demanda maior agilidade e pouco formalismo na documentao do produto final, os
processos geis poderiam ser bem empregados, desde que sejam considerados os
requisitos mnimos de documentao e gerncia requeridos a uma fbrica de software
institucionalizada. Isso porque a velocidade e o dinamismo desse tipo de processo
confere o ritmo necessrio para o sucesso da operao, porm, deve-se preservar
pequenas equipes cujos integrantes estejam reunidos em um mesmo ambiente fsico.
Com relao s fbricas de componentes de software, os desenvolvedores
tambm podem se adaptar ao escasso formalismo dos processos geis, optando por
registrar os componentes somente por meio de ferramentas como JavaDoc. Nessa
perspectiva, assim como na fbrica de cdigo, o dinamismo dos mtodos geis pode ser
o diferencial da fbrica, mas, algum formalismo ou processo complementar precisa ser
determinado para a catalogao e repartio dos elementos gerados. Sendo assim, as

27

restries quanto a pequenas equipes cujos integrantes estejam reunidos em um mesmo

ambiente fsico tambm devem ser observadas.
Nas fbricas de projeto, segundo Rocha et al. (2004), que semelhante a grande
parte das fbricas que desenvolvem aplicaes personalizadas, a dependncia por
mtodos tradicionais ou vem maior destaque, pois se faz necessrio registrar e no
raramente, validar formalmente com o cliente as decises de requisitos ou projeto. Esses
produtos tambm tm um ciclo de vida maior, o que passa a ser corriqueiro, durante o
desenvolvimento de um determinado projeto a entrada e sada de pessoal, o que
atrapalharia o emprego de um processo orientado a pessoas como os processos geis.
H tambm as fbricas ou indstrias que lidam com o outsourcing de sistemas
que demanda, alm de maior formalismo, maior manipulao por parte do cliente dos
indicadores produzidos pela indstria de software, prtica corriqueira nessa situao,
orientado a processos tradicionais. muito comum, e at mesmo exigido pelo prprio
cliente, a documentao da fbrica em um modelo de qualidade identificado
mundialmente, o que refora a utilizao de processos bem definidos com coleta e
acompanhamento de metas de produo.

2.10.2. Adaptao de processos de software

Uma das principais implicaes do amplo crescimento experimentado pela
indstria do software nos ltimos anos o aumento da complexidade do software e as
demandas cada vez maiores do mercado. Tal mercado requer das empresas que
desenvolvem software, que os sistemas sejam desenvolvidos com prazo e custo
definidos previamente e satisfaam a padres de qualidade. Para atender a essas
exigncias, foi preciso investir no processo de desenvolvimento de software, dada a
intensa relao entre sua qualidade e a do software produzido.
Nesse panorama, o processo padro um conjunto de componentes
fundamentais que se quer incorporar em todo o processo de desenvolvimento
estabelecido para os projetos de certa organizao de software, assegurando, dessa
forma, a consonncia com os padres de qualidade e processos adotados por estas
organizaes (MAIA, 2004). Como em qualquer software, o processo padro deve
apontar as atividades a serem concretizadas e as amarraes entre elas. Para cada
atividade, so confirmadas tambm as misses dos recursos humanos que a
28

desempenham, os artefatos de software consumidos e produzidos, como ainda o

oramento necessrio.
Considerando-se a relevncia do processo padro e a sua necessidade de
adaptao, busca-se, geralmente, um modelo para colaborar com o Engenheiro de
Processos na adaptao do processo padro de uma determinada indstria de software
para um projeto especfico, fundamentado nas particularidades do projeto, nas diretrizes
de adaptao do processo padro e nos conhecimentos sobre as adaptaes realizadas
anteriormente.
Convm lembrar que a adaptao uma atividade que emprega amplamente
diferentes tipos de conhecimento, sendo que h modelos sustentados no suporte ao
gerenciamento para se obter o conhecimento necessrio adaptao, verificando as
caractersticas do projeto, os parmetros que norteiam a adaptao do processo padro e
o conhecimento alcanado durante as adaptaes realizadas anteriormente, por meio de
mecanismos hbeis em raciocinar sobre tal conhecimento, segundo (MAIA, 2004).
Com relao ao modelo de processo, trata-se de uma estrutura empregada para
simbolizar tanto o processo padro quanto os processos adaptados. Essencialmente, um
modelo de processo constitudo pelo conjunto de atividades a serem efetuadas e de
dependncias entre si. Para toda atividade, podem ser apontados as responsabilidades
dos recursos humanos que a desempenham, os artefatos de entrada e sada e os recursos
suficientes.
Quanto s caractersticas do projeto, estas podem ser utilizadas para
particularizar um determinado software, tais como o tipo de aplicativo a ser
desenvolvido, a crtica ao projeto, assim como a repartio geogrfica das equipes.
Esses projetos caracterizados simbolizam os futuros softwares a serem administrados
pela organizao, nos quais ser aplicado o processo padro depois de adaptado. Um
projeto caracterizado constitudo essencialmente por um conjunto de caractersticas de
projeto, cada um detendo um valor e um peso (relevncia ao projeto).
Entretanto, para Maia (2004), existem certas normas na adaptao que so as
diretrizes que a norteiam, especficas de cada processo padro, cujo teor recomenda em
que condies uma determinada atividade do processo ser habilitada ou no no
processo adaptado, em que a abordagem usada orientada a atividades. O elemento
29

condicional de uma norma essencialmente formada por testes sobre os valores das
caractersticas de projeto.
No que se referem aos casos de adaptao, trata-se de registros de adaptaes j
alcanadas, de maneira a conter o conhecimento imprescindvel para ser empregado em
adaptaes futuras, por meio do mtodo de raciocnio baseado em casos. Este caso, na
pesquisa de Maia (2004), constitudo pelo problema (projeto de software a ser
implementado na organizao), a soluo (processo adaptado apropriado s caractersticas
desse projeto) e a avaliao dos efeitos do processo adaptado no projeto de software real.
Na etapa que consiste na caracterizao do projeto, fundamentado num
planejamento inicial e no conjunto de caractersticas disponveis, o Engenheiro de
Processos estabelece as caractersticas do projeto de software em questo. Na prxima
etapa, a reutilizao dos casos, com base no projeto caracterizado, o modelo proposto
cultua um mtodo de comparao para buscar, em um repertrio de casos de adaptao,
o projeto mais anlogo e reusar o processo adaptado vinculado, com adaptaes se
necessrio. Nessa etapa, a interveno do Engenheiro de Processos pode ser precisa, se
mais de um caso de adaptao tiver sido resgatado ou em situaes em que um
componente do processo padro tiver sido inserido ou excludo no/do processo adaptado
restaurado, em deciso oposta do modelo.
Em seguida, no ato de adaptar o processo, realizada uma varrio nas
atividades do processo padro em busca daquelas que ainda no foram inseridas no
processo originado na fase anterior. Para todas essas atividades, se no houver restries
de uso (condies a serem testadas sobre as caractersticas do projeto atual), sero
includas diretamente no processo adaptado, ou seno, essas condies sero
inicialmente testadas.
Nesse aspecto, o resultado dessa etapa um processo adaptado que pode ser
livremente modificado pelo engenheiro de processos na fase de ajuste, conforme as
necessidades do projeto. Realizados s adaptaes manuais necessrias, nas palavras de
Maia (2004), produzido um caso de adaptao (constitudo pelo projeto caracterizado
e pelo processo adaptado) e o processo adaptado concludo para ser instanciado
(alocao de recursos e agentes, fixao de cronograma) e usado no projeto de software
real. Todavia, vale ressaltar que o suporte instanciao e execuo de processos de
software est fora do escopo deste trabalho.
30

3. Trabalhos Relacionados
3.1. Introduo
Este captulo apresenta os trabalhos relacionados ao tema proposto,
evidenciando pontos de contribuies e limitaes em cada abordagem.
Vrios esforos ocorrem no sentido de adaptar metodologias geis e tradicionais
a fim de atender as particularidades das organizaes. Uma das metodologias mais
conhecida e que, constantemente, tem sido investigada nas indstrias de software para
adaptao natureza de uma empresa o RUP Rational Unified Process. Este possui
as mesmas razes do Processo Unificado PU (SCOTT, 2003). Porm, existem vrias
outras publicaes relevantes que utilizam combinao de metodologias geis e
tradicionais (ALVES et al., 2011).
Acredita-se que os processos de desenvolvimento de software sempre so
adequados em conformidade com o ambiente aplicado. Alguns trabalhos apresentam
adequaes de processos ao domnio do desenvolvimento das aplicaes, considerando
os cenrios inerentes a tais domnios: tamanho e qualificao da equipe de
desenvolvimento, estrutura da fbrica de software que hospeda a equipe, experincia da
gerncia e conjunto de artefatos derivados do processo.
A seguir sero apresentados quatro trabalhos correlatos pesquisa em questo,
nestes sero abordados aspectos relevantes de limitaes para aplicao do estudo de
caso deste trabalho.

3.2. Desenvolvimento gil de sistemas de Realidade Virtual

A pesquisa apresentada em Mattioli et al. (2009) revela particularidades
relacionadas construo de Sistemas de Realidade Virtual, cujo desenvolvimento gil
de software uma abordagem de atuao, diferenciada pela adaptabilidade, pela
habilidade em admitir mudanas, sejam estas nas variveis de mercado, na configurao
do sistema, na tecnologia de criao ou nas equipes de projeto. Para tal, a metodologia
gil XP foi utilizada como metodologia base, onde buscou-se adapt-la para
atendimento as especificidades de sistemas em SRV.
As principais atividades apresentadas por Mattioli et al.(2009) so: 1) Spike de
arquitetura; 2) Requisitos de interatividade; 3) Planejamento da iterao; 4)
31

Desenvolvimento e 5) Testes.

Para Mattioli et al. (2009) a interatividade se

transformou no elemento central de diversos sistemas de Realidade Virtual,

desempenhando um papel de fundamental relevncia na deliberao da aplicabilidade
desses sistemas. Dessa forma, a anlise criteriosa e o estabelecimento dos requisitos de
interatividade, que esto intimamente relacionados crescente tecnologia em ambientes
de RV, ocupa uma posio de destaque dentro do processo de desenvolvimento de SRV.

Figura 8 - Ciclo de vida do desenvolvimento gil de um SRV [extrado de (MATTIOLI et al., 2009)].

Como aspecto relevante ao trabalho de Mattioli et al. (2009), a fase de requisitos

de interatividade ocupa posio de destaque dentro do processo de desenvolvimento,
uma vez que, na construo de solues de sistemas de Realidade Virtual primordial
ponderar a usabilidade e a interatividade com o sistema. Entretanto, para a aplicao
deste modelo em fbricas de software de reparties pblicas para construo do
sistema integrado, observa-se como fator limitador o tempo gasto para conceber a fase
de requisitos de interatividade desnecessria pela caracterstica do projeto.

3.3. Um Mtodo de Desenvolvimento de Sistemas de Grande

Porte Baseado no Processo RUP
Este trabalho apresenta um mtodo com as mesmas fases do processo RUP, com
a diferena de que elas so realizadas no apenas no escopo do sistema, mas tambm de
cada subsistema, havendo, ainda, um revezamento entre elas ao longo do tempo
(Figuras 9 e Figura 10). Isso permite que, aps a fase de Transio (implantao) do(s)
primeiro(s) subsistema(s), o conhecimento adquirido e os artefatos produzidos em seu
desenvolvimento sejam devidamente explorados nos subsistemas que ainda restam,
alm de possibilitar condio de avaliao do andamento e das estimativas do projeto
32

como um todo, j que foi adquirida uma amostragem de desenvolvimento do sistema,

em cada uma de suas fases (SOUZA et al., 2004).

Figura 9 - Fases e disciplinas do mtodo proposto [extrado de (SOUZA et al., 2004)].

Figura 10 - Fases e marcos do mtodo proposto [extrado de (SOUZA et al., 2004)].

Este processo foi resultado de um estudo emprico no desenvolvimento de um

sistema real de grande porte (que durou quatro anos e meio) para gesto de uma
operadora nacional de planos de sade no estado do Cear (SOUZA et al., 2004).
Como demonstrado, este processo tem como caracterstica fundamental sua
aplicao em grandes projetos que contemple fbricas de software bem estruturadas.
Neste sentido, para aplicao deste processo em reparties pblicas federais (escopo
deste estudo de caso) este se torna extremamente invivel. O ponto de maior relevncia
da inviabilidade utilizao de todas as fases do RUP em todos os subsistemas.

33

3.4. Adaptao do Rational Unified Process (RUP) em pequenas

equipes de Desenvolvimento Distribudo
O trabalho de Rocha et al. (2008) apresenta uma pesquisa aplicada em adaptar o
Processo de Desenvolvimento baseado em RUP para uma pequena equipe utilizando
Desenvolvimento Distribudo de Software (DDS).
Para viabilizar este trabalho, a pesquisa foi integrada a uma disciplina de
Engenharia de Software com foco na implantao de indstrias de software que utilizam
o Desenvolvimento Distribudo de Software (DDS) para a realizao de projetos reais.
Com a demarcao dos clientes e projetos, buscou-se simular um ambiente de fbrica de
software para oferecer os produtos decididos em comum acordo com o cliente. A
fbrica relatada nessa pesquisa denominada TechnoSapiens, foi integrada por nove
estudantes, atuando de modo distribudo, com parte da equipe executando na mesma
cidade e os demais espalhados em trs outros municpios. Convm ressaltar que nenhum
dos membros havia atuado antes com outro membro da equipe, trabalhando juntos pela
primeira vez para o desenvolvimento do projeto.

Figura 11 - Processo Adaptao do RUP para DDS [extrado de (ROCHA et al., 2008)].

Esses aspectos levaram definio de uma instncia de processo fundamentada

no Rational Unified Process (RUP). O TechnoProcess, como foi chamado o processo
criado pela TechnoSapiens, foi formalizado de forma a viabilizar e atender aos fatores
acima referidos, em que a procura por um processo leve, flexvel, mas de carter
34

prescritivo, demandou reunies para definir como o processo atenderia a essas

particularidades. As principais etapas consideradas para o processo foram: pr-venda,
requisitos, anlise e projeto, reviso e aprovao, implementao, testes e implantao.
A Figura 11 apresenta o processo desta pesquisa (ROCHA et al., 2008).
O projeto foi desenvolvido em duas fases: o projeto piloto, usado para fins de
averiguao da estrutura da fbrica (infraestrutura, processo, entre outros) e o projeto
real, que teve como objetivo utilizar as melhores prticas adotadas no projeto piloto e
buscar melhorias. Em meio a pequenos impasses, o TechnoProcess necessitou ser
adaptado no decorrer do projeto para realmente atender s necessidades da fbrica. Na
fase de adequaes do processo, foram definidos ajustes nas atividades, adequando
tambm alguns templates dos artefatos propostos.
Nessa linha de pensamento, ao definir um processo de software eficiente e que
se adapte ao contexto da indstria algo de essencial relevncia para o avano de um
projeto, por isso, preciso que este seja constantemente avaliado a fim de conseguir um
nvel de adequao e funcionalidade cada vez maior.
Alm da adaptao do processo RUP, este trabalho destaca o desenvolvimento
de sistemas distribudos, esta caracterstica faz com que este apresente vrios problemas
na aplicao do processo proposto, pois demanda aspectos para mitigao dos riscos
que normalmente so maiores devidos sua caracterstica. Portanto, esta pesquisa se
torna invivel em ser aplicada no estudo de caso desta pesquisa.

3.5. Integrao do desenvolvimento gil de software ao RUP

No trabalho de ALVES et al. (2011), defende-se a proposta de um processo
hbrido Scrum-RU. Nesse caso, as decises de projeto do processo Scrum-RUP foram,
em grande parte, tomadas com base nas experincias encontradas na literatura, assim
como nos principais resultados da pesquisa na rea de mtodos geis.
Um estudo de caso industrial foi implementado em uma empresa localizada em
Uberlndia-MG, com o intuito de analisar como o processo Scrum-RUP impacta na
produtividade de desenvolvimento, em comparao ao processo RUP que a empresa
estava acostumada a utilizar.
O trabalho objetivou verificar se h diferena de produtividade entre equipes
RUP e equipes Scrum-RUP. Resultados quantitativos demonstraram ganhos expressivos
35

de produtividade em quatro dos cinco agrupamentos de projetos semelhantes. Esses

ganhos variaram entre 15% e 34%, ao passo que no grupo que no apresentou diferena
significativa, o ganho foi de -1,1%.
Esses resultados indicam que houve ganho de produtividade nos projetos ScrumRUP. Por meio deste trabalho, foi tambm possvel inferir, com relativa segurana, que
o processo foi realmente responsvel pelo ganho de produtividade. A Figura 12
demonstra o ciclo de vida do processo Scrum-RUP.

Figura 12 - Ciclo de Vida do processo Scrum-RUP [extrado de (ALVES et al., 2011)].

Para aplicao deste modelo, destacam-se dois aspectos relevantes caso este
processo estivesse implantado em ambientes de reparties pblicas, tais como: 1)
requisitos predominantes por consequncia dos clientes on-site; 2) Integrao contnua:
Necessidade por caracterstica do projeto em integrar todos os submdulos para um
melhor entendimento do conceito GRP-IFTM.

3.6. Sumrio e concluses

Para anlise comparativa dos trabalhos relacionados, a Tabela 5 apresenta os
principais critrios investigados e relacionados com o processo proposto. Estes critrios
foram identificados como necessrios para a anlise, aps diversas reunies no grupo TI
do IFTM devido a demanda dos mesmos no dia-a-dia de desenvolvimento de software
do grupo.
36

1) Iteraes e incrementos: Dividir o projeto em partes gerenciveis, de forma a

incrementar as funcionalidades continuamente at o final da construo do
produto (SCHACH, 2009).
2) Cliente on-site: Utilizado nas metodologias geis (SCRUM) e tem como
caractersticas o cliente prximo ao projeto, ou seja, clientes e desenvolvedores
prximos para resolues de requisitos mal interpretados. Conforme Boehm
(2002), Coram & Bohner (2005) e Highsmith & Cockburn (2001) os mtodos
geis funcionam melhor quando os clientes se dedicam junto com a equipe de
desenvolvimento (on site), e quando o seu conhecimento tcito suficiente para
toda a amplitude da aplicao.
3) Prototipagens de Interfaces: uma prtica utilizada para demonstrar como as
interfaces (telas, relatrios ou outros componentes do sistema) sero
apresentadas aos usurios.
4) Integrao contnua: Utilizado para o desenvolvimento contnuo do software,
onde os membros de um time integram seu trabalho frequentemente, geralmente
cada pessoa integra pelo menos diariamente podendo haver mltiplas
integraes por dia (TELES, 2004).
5) Design simplificado: A metodologia foca sua nfase em interaes com os
clientes a fim de obter melhores resultados para camada de viso. Porm design
simplificado reduz tempo e custo devido ser mais fcil de se construir, manter e
entender (CSSIO, 2006).
6) Reunies dirias: Como no SCRUM as reunies so realizadas todos os dias
nos mesmos horrios e local. aconselhvel que seja a primeira coisa realizada
como atividade do dia.
Tabela 5 - Tabela comparativa entre os trabalhos relacionados.

Iteraes e incrementos
Cliente on-site
Prototipagens de Interfaces
Integrao contnua
Design simplificado
Reunies dirias

gil
SRV
x
x
x
x

RUP N
Sub-Sistemas
x
x

RUP em
DDS
x

x
x

x
x

SCRUMRUP
x
x
x
x

37

Analisando a Tabela 5, possvel observar que nenhum dos sistemas estudados

apresenta todos os critrios de forma conjunta e integrada. Entretanto, acredita-se que
uma metodologia que contemple todos estes critrios possua um maior potencial no
impacto de produtividade de uma equipe de TI.
Portanto, este trabalho surgiu no sentido de colaborar para o estabelecimento de
uma melhor metodologia de desenvolvimento de software, criando aderncia s estas
particularidades para atendimento a equipes que possuem caractersticas de fbricas de
software de reparties pblicas. Detalhes desta metodologia so apresentados no
prximo captulo.

38

4. Metodologia Proposta
4.1. Introduo
Este trabalho prope uma integrao do Processo Unificado e metodologia gil,
visando, primordialmente, customizar o mesmo com sensvel reduo de nmero de
fases e artefatos, a fim de obter melhor gerenciamento do processo de desenvolvimento
de software em fbricas com caractersticas de reparties pblicas. Espera-se assim
contribuir na perspectiva da integrao de mdulos hierrquicos, conceitualmente
definidos em projetos corporativos governamentais, referidos como GRPs (Government
Resource Planing Sistemas Integrados Governamentais).
A metodologia aqui proposta ser referenciada por MDS-GRP que significa
Metodologia de Desenvolvimento de Sistemas. O restante do captulo voltado para a
explanao das fases e dos critrios adotados pela MDS-GRP.

4.2. Objetivo da MDS-GRP

O objetivo da MDS-GRP direcionar as equipes de desenvolvimento de
reparties pblicas, a utilizar a metodologia como um guia de referncia para
construo de mdulos e/ou submdulos que compe sistemas integrados do tipo GRPs.
importante destacar que, embora a metodologia fosse inspirada em processos comuns
de reparties pblicas relacionadas ao ensino, no existe nenhuma impossibilidade de
investigao do uso da mesma em projetos de outra natureza.
Esta MDS-GRP baseia-se em metodologias utilizadas em literaturas acadmicas
para desenvolvimento de sistemas e so apoiadas em tcnicas como o PU (Processo
Unificado), PMBOK (Project Management Body Knowledge) e UML (Unified
Modeling Language).
Alm disso, a MDS-GRP est organizada em papis, artefatos, projetos e
manutenes. Cada projeto contempla uma sequncia de fases e cada fase define fluxos
de atividades onde so realizadas reunies de planejamento, acompanhamento e gerados
artefatos de controle.

39

4.3. Caractersticas
importante destacar que esta MDS-GRP ser dirigida por Casos de Uso, em
conformidade com os fundamentos definidos no PU-Processo Unificado. Para obter um
melhor entendimento, esta caracterstica baseia-se em uma sequencia de aes,
executadas por um ou mais atores (pessoas ou entidades no humanas fora do sistema) e
pelo prprio sistema, que produz um ou mais resultados de valor para um ou mais
atores. Esta expresso refere-se ao fato de se utilizar este tipo de diagrama para dirigir
todo o trabalho de desenvolvimento, desde a captao inicial e negociao de requisitos
at a aceitao do cdigo.
Outro fator relevante a metodologia ser centrada na arquitetura, este termo
tambm importante, pois a arquitetura a organizao fundamental do sistema como
um todo, ou seja, a arquitetura ser o alicerce sobre o qual todo o sistema se erguer e
dever ser uma das principais preocupaes das equipes de desenvolvimento dos
mdulos e/ou submdulos com objetivo de obter melhores resultados.
Alm disso, esta MDS-GRP iterativa e incremental, ou seja, a execuo de um
ciclo de vida corresponde a uma verso do sistema liberada. A cada nova verso
liberada, melhorias so adicionadas em relao verso anterior. Esta caracterstica
(iterativa e incremental) baseia-se no aumento e refinamento sucessivo de um sistema
por meio de mltiplos ciclos aps definio da viso geral do submdulos por meio da
especificao do projeto. Estes ciclos so formados pelos fluxos de desenvolvimento de
anlise, de projeto, de arquitetura do sistema, de implementao, de testes e de
implantao que atravessam o conjunto das quatro fases que sero apresentadas na
prxima seo.
Ressalta-se tambm a existncia de dois outros fluxos nos quais o ciclo de vida
do processo proposto continuo: a fase de Requisitos, onde iteraes entre as equipes
de desenvolvimento e os stakeholders envolvidos no projeto, acontecem em momentos
informais, ou seja, ocorrem por meio de e-mails, verbal ou outra fonte de comunicao,
pois comum manifestaes de dvidas para resoluo de problemas que passaram
despercebidos na fase do levantamento dos requisitos.
Outra fase continua o Gerenciamento de Projetos que representa o
acompanhamento das atividades por parte das equipes que esto envolvidas no projeto.
Para realizao do acompanhamento de tais atividades, foi implantada uma ferramenta
40

de apoio ao gerenciamento de projetos que possibilite o registro das tarefas realizadas

nos projetos. Alm disso, esta ferramenta permite tambm o armazenamento de forma
organizada dos artefatos gerados no processo proposto e consequentemente a
documentao do projeto como um todo. A Figura 13 apresenta o ciclo de vida do
processo proposto.

Especificao do Projeto

Arquitetura Sistema

Anlise e Projeto

No

Validao

Requisitos

Sim

Implementao

Gerenciamento de
Projeto

No

Testes

Implantao

Validao

Sim

Figura 13 - Ciclo de Vida do processo MDS-GRP.

4.4. As Fases da MDS-GRP

A MDS-GRP est organizada em quatro fases: concepo, elaborao,
construo e transio, conforme proposto pelo PU. Entretanto, a natureza de cada fase
diferenciada em relao aos processos tradicionais do PU. De fato, em cada fase
proposta uma adequao de desenvolvimento que foi norteada por necessidades comuns
41

s equipes de desenvolvimento em ambientes pblicos. Tais ambientes possuem, em sua

essncia, caractersticas prximas para desenvolvimento de projetos de software.
A ideia proposta est relacionada com o fato de que em cada fase sejam
produzidos um conjunto de atividades e, consequentemente, um conjunto de artefatos
para documentar o processo de desenvolvimento. Portanto, ao final de cada fase,
espera-se obter tais artefatos, sejam eles diagramticos ou textuais, dependendo da fase
em questo. Abaixo a Figura 14 apresenta a estrutura das fases da MDS-GRP.

Figura 14 - Fases da MDS-GRP.

4.4.1. Fase de Concepo

A fase de Concepo tem como objetivo principal a formalizao do mdulo a
ser desenvolvido. Esta formalizao dever ser devidamente registrada pelo cliente do
mdulo com objetivo de identificar a demanda necessria para atender a rea de
negcio. Este registro ser por meio do Documento de Oficializao da Demanda
DOD que o documento oficial dentro de qualquer entidade pblica. Aps o
preenchimento do DOD sero realizadas anlises entre o Gerente de Projetos e o
patrocinador para compor a viso inicial do escopo do projeto e registrar no documento
Termo de Abertura do Projeto TAP a fim de iniciar o Plano de Projeto que contempla
o planejamento para execuo de todo processo de produo do mdulo. A Figura 15
apresenta uma viso clara da fase de Concepo.
por meio destes trs documentos que inicia o projeto, e estes devero apresentar as
condies necessrias para construo do mdulo a ser desenvolvido. A
Tabela 6 apresenta a descrio sumria dos artefatos, os papis e o seu fluxo.
A definio do conceito inicial do mdulo acontece por meio de reunies com os
stakeholders (todos os envolvidos), e destaca-se como principal demandante a figura do
patrocinador do projeto, a fim de responsabilizar-se pela concepo e motivao de
todos os envolvidos, para iniciar o projeto proposto. Assim, para cada projeto a ser
42

desenvolvido dever apresentar o patrocinador como papel chave para o processo e

prosseguimento na construo do mdulo. Para o sucesso do projeto este patrocinador
dever participar diretamente da fase de Concepo e indiretamente de todas as outras
fases.

Figura 15 - Fase de Concepo do Projeto.

Tabela 6 - Artefatos padres para fase de Concepo

Artefato
DOD Documento de
Oficializao
de Demanda
TAP Termo
de Abertura do
Projeto

PP Plano do
Projeto

Descrio

Papis

Documento mediante o qual a rea Patrocinador

solicitante ir formalizar a demanda. Esta
e
demanda dever estar devidamente Gerente de
registrada no PDTI do rgo.
Projetos
o documento que autoriza formalmente Patrocinador
o projeto. Este documento permite
e
definir mais claramente os objetivos do
Gerente de
projeto e quais as suas fronteiras, define o
Projetos
mbito do projeto bem como o produto
final.
Apresenta uma viso geral das atividades
Gerente de
a serem executadas. Este documento ir
Projetos e
concentrar informaes oriundas do DOD Coordenador
e TAP.
de Sistemas

Fluxo de
Origem
Concepo

Concepo

Concepo

43

4.4.2. Fases de Elaborao

A fase de Elaborao ser realizada pela equipe denominada Equipe de
Requisitos e ter como papel fundamental, realizar o levantamento dos requisitos da
funcionalidade demandada. Est fase dever realizar as atividades de aproximao e
comunicao entre as outras equipes que trabalham em outros mdulos do projeto GRPIFTM que ser apresentado no prximo captulo. Este alinhamento ocorrer por meio de
reunies semanais entre os Coordenadores de Sistemas das equipes. A Figura 16
apresenta os processos da fase de Elaborao.
Para demonstrar como as iteraes devero acontecer, a equipe de requisitos
dever realizar vrias reunies com os stakeholders, para que estes apresentem os
conceitos, as definies e os fluxos necessrios para atendimento da demanda requerida.
Todos estes requisitos devem ser registrados pela equipe de requisitos e posteriormente
transformados em prottipos de telas/relatrios. Alm dos prottipos, a equipe de
requisitos dever confeccionar os diagramas de Casos de Uso com objetivo de
apresentar aos stakeholders do mdulo o entendimento da interao realizada. Quando
ocorrem inconsistncias nos requisitos levantados, estes no serem validados e novas
interaes acontecem para validar a funcionalidade demandada. Este fluxo permanece
at a validao dos requisitos. Ao obter o entendimento este dever ser formalizado pelo
artefato Termo de Aceite, que conter a assinatura por um dos stakeholders indicado
pelo patrocinador ou pelo prprio patrocinador. Ainda nesta fase a equipe de requisitos
dever sempre alimentar o documento Product Backlog com as funcionalidades
registradas no mdulo, bem como as estimativas de tempo para implementar cada uma.
A Tabela 7 apresenta os artefatos gerados nesta etapa da fase de Elaborao.
Recomenda-se que para identificao de tais requisitos, o ciclo seja divido em
trs momentos, sendo o primeiro para levantar os requisitos da funcionalidade; o
segundo para apresentar os prottipos e os diagramas de Casos de Uso e realizar as
possveis adequaes; e por fim o terceiro para apresentar os ajustes realizados fechando
o ciclo da fase de levantamento de requisitos devidamente validado pelo cliente.

44

Figura 16 - Fase de Elaborao da MDS-GRP.

Tabela 7 - Artefatos padres para fase de Elaborao

Artefato

Descrio

Papis

Ata de
Reunies
Documento de
Especificao
de
Requisitos

Documento responsvel pelo detalhamento

e oficializao da reunio.
o documento que descreve os requisitos
funcionais do mdulo, provendo uma
descrio clara e consistente do que o
mdulo dever fazer.
Este documento deve conter:
Listagem de Casos de Uso;
Diagrama dos Casos de Uso;
Prototipao de Telas e Relatrios;
Documento que ser celebrado no aceite
dos requisitos por meio das prototipaes
de telas e dos Casos de Uso apresentados.
a lista de funcionalidades preparada em
conjunto com o cliente. Esta lista
organizada por prioridade de entrega e
deve incluir todas as funcionalidades
visveis ao cliente incluindo os requisitos
funcionais.

Equipe de
Requisitos
Equipe de
Requisitos

TAR Termo
de Aceite de
Requisitos
PB- Product
Backlog

Fluxo de
Origem
Elaborao
Elaborao

Equipe de
Requisitos

Elaborao

Equipe de
Requisitos

Elaborao

45

4.4.1. Fases de Construo

A fase de Construo refere-se em atividades de arquitetura de sistema,
implementao e testes. Para esta fase a equipe responsvel por todas as atividades
denomina-se Equipe de Desenvolvimento e tem como responsabilidade realizar a
codificao e os testes do mdulo proposto. Para esta fase, foi tambm projetada a
participao dos stakeholders na realizao de testes em funcionalidades liberadas. A
seguir, a Figura 17 apresenta a fase de Construo.

Figura 17 - Fase de Construo da MDS-GRP.

Para esta fase sero gerados alm dos artefatos textuais e grficos, os cdigos
fontes e toda sua estrutura de dados necessria para produo do mdulo. Ressalta-se a
necessidade de integrao dos mdulos j existentes e das estruturas de dados comuns
para atendimento a todos os componentes do GRP-IFTM, portanto a equipe de
desenvolvimento deve atentar para no haver inconsistncias e redundncias de
funcionalidades e informaes.
46

Outro ponto importante e que as equipes devem estar atentas, a padronizao

no desenvolvimento em trs camadas (modelo, controlador e viso), a fim de
estabelecer uma unidade e um alinhamento entre todos os desenvolvedores de todas as
equipes. Alm disso, as codificaes devero ser orientadas pelos artefatos definidos
pela equipe de requisitos e estes s podero ser codificados aps o termo de aceite
assinado pelo requisitante envolvido na iterao. A Tabela 8 apresenta os artefatos
produzidos nesta etapa.
Tabela 8 - Artefatos padres para fase de Construo de desenvolvimento.
Artefato
Projeto de
Banco de
Dados
TAB
Termo de
Aceite da
Verso atual

Descrio

Papis

Especifica a organizao do banco de

dados, incluindo a sua Estrutura
lgica e fsica, contedo e
aplicaes. Inclui o dicionrio de
dados e o diagrama de classe.
Documento que ser celebrado para
atestar a verso atual disponvel aps
implementao e testes da iterao

Equipe de
Desenvolvimento

Equipe de
Desenvolvimento

Fluxo de
Origem
Construo

Construo

4.4.2. Fase de Transio

Por fim a fase de Transio culmina no fechamento do ciclo de desenvolvimento
do mdulo. Nesta fase ser confeccionado um relatrio que dever registrar as possveis
integraes com outros mdulos, o treinamento dos usurios que iro operacionalizar o
mdulo e o termo de aceite final do mdulo devidamente assinado por seu patrocinador.
A Figura 18 apresenta os processos desenvolvidos na fase de Transio e a Tabela 9 os
artefatos gerados pelo processo.

47

Figura 18 - Fase da Transio da MDS-GRP.

Tabela 9 - Artefatos padres para fase de Transio

Artefato

Descrio

Papis

RIM Relatrio de
Integrao do
Mdulo

Relatrio contendo
informaes pertinentes a
possveis integraes a
outros mdulos;
Documento contendo todas
as informaes necessrias
para operacionalizao do
mdulo.
Documento que ser
celebrado para atestar a
verso final aps todas as
fases do processo de
desenvolvimento

Equipe de
Integrao

Manual do Usurio

TAB Termo de
Aceite final

Fluxo de
Origem
Encerramento

Equipe de
Transio

Encerramento

Equipe de
Transio

Encerramento

4.5. Papis
Um papel define o comportamento e responsabilidades de um profissional ou
grupo de profissionais que participam do desenvolvimento do projeto. O
48

comportamento representado por meio das atividades que cada papel deve
desempenhar ao longo do projeto. As responsabilidades normalmente esto associadas
aos artefatos que cada papel deve produzir e manter ao longo das atividades que realiza.
Na prtica, um mesmo papel pode ser desempenhado por mais de uma pessoa, assim
como uma mesma pessoa pode assumir vrios papis ao longo do projeto.

4.5.1. Patrocinador do Projeto

Este papel um dos mais importantes para o processo, pois o Patrocinador
quem ir patrocinar no projeto, caso isso no ocorra h grande probabilidade do projeto
fracassar. O Patrocinador normalmente so os profissionais que esto frente das PrReitorias ou dos Departamentos demandante que se responsabiliza pelo projeto.
Podero existir projetos com mais de um Patrocinador. Em destaque a principal
atividade do Patrocinador garantir a sustentabilidade do projeto realizando aes
estratgicas tais como:

Preencher o documento de oficializao da demanda;

Definir o escopo inicial do projeto;

Aprovar os objetivos e metas do projeto;

Tomar decises mais importantes do projeto;

Aprovar a concluso de uma fase para incio da seguinte;

Ajudar a remover obstculos do projeto;

Envolver no planejamento do projeto.

4.5.2. Clientes do Projeto

Os Clientes do Projeto so os usurios do mdulo a ser desenvolvido, ou seja, e
quem o produto ou servio concebido e que explora, pelo menos, uma das suas
funes do sistema. O Patrocinador ir selecionar alguns usurios a fim de participar na
fase de execuo dos projetos para levantar os requisitos necessrios.

4.5.3. Gerente do Projeto

Gerencia o processo de desenvolvimento por meio da aplicao da metodologia.
Define a metodologia e as diretrizes de desenvolvimento de sistemas. Atua no dilogo
com os gestores e na resoluo de problemas. Outra atividade importante a definio
das equipes para construo do mdulo.
49

4.5.4. Coordenador de Sistemas

o responsvel pelo acompanhamento do projeto. ele que oficializa as
demandas de construo do software, solicita reunies, define, valida, recebe e
homologa os requisitos levantados. Tem poder de deciso sobre todo o processo que o
sistema vai automatizar. Este papel define tambm as duas equipes que iro trabalhar
na fase de Construo.

4.5.5. Equipe de requisitos

Equipe responsvel por identificar, organizar e documentar todos os requisitos
funcionais e no funcionais do mdulo apresentados pelos clientes do projeto. So os
responsveis pelos artefatos de prottipos da interface do usurio (telas e relatrios), os
diagramas de Casos de Uso, Product Backlog e Termo de Aceite de Requisitos.

4.5.6. Equipe de Desenvolvedores

Equipe responsvel por arquitetar, implementar e testar o mdulo. Estes
processos geram os seguintes artefatos: diagrama de classe, diagrama de sequencia e
dicionrio de dados.
A seguir as principais atividades de responsabilidade das equipes de
desenvolvedores:

Construir unidades de implementao de acordo com as especificaes e

prazos estabelecidos;

Efetuar teste unitrio do componente com a massa de testes elaborada;

Criar e testar cdigo de acordo com o padro de programao estabelecido;

Executar todas as atividades necessrias para gerao dos mdulos, de

acordo com o planejamento e a esta MDS-GRP;

Apoiar o gerente de projetos em relao aos aspectos tcnicos e funcionais

do projeto ou manuteno;

Gerar verso do sistema;

Informar ao gerente de projetos o andamento e a evoluo de suas atividades

no projeto ou manuteno;

Implantar o mdulo no ambiente de produo.

50

4.5.7. Equipe de Integrao

Esta equipe possui um carter estratgico, responsvel pela elaborao do
Relatrio de Integrao. Este relatrio dever ser explicitado toda integrao do mdulo
a outros mdulos j existentes, bem como as possibilidades de haver outras integraes
com mdulos previstos.

4.5.8. Equipe de Transio

A equipe de transio se responsabiliza pela elaborao de todo material para
treinamento (apresentaes, manuais, tutorais e outros). Estes materiais so utilizados
pelos usurios na capacitao e operao dos mdulos, portanto esta capacitao inicial
dos mdulos tambm faz parte do portflio de atividades da equipe. Outra atividade de
supra relevncia a entrega final do mdulo que dever ser devidamente registrada no
termo de aceite final.

51

5. Exemplo de Aplicao GRP do IFTM

5.1. Introduo
De forma a definir prova de conceito, aplicou-se a MDS-GRP em trs equipes
equivalentes da fbrica de software do Instituto Federal de Educao, Cincia e
Tecnologia do Tringulo Mineiro com objetivo de avaliar seus pontos fortes e fracos,
para alcanar melhores resultados qualitativos no processo de desenvolvimento dos
sistemas no mbito do IFTM.

5.2. A Empresa
Os Institutos Federais de Educao, Cincia e Tecnologia foram criados em
dezembro de 2008 com a publicao da lei 11.892 com o objetivo de atender a educao
profissional e tecnolgica no contexto social do Brasil. Em consequncia as antigas
autarquias Centro Federal de Educao Tecnolgica de Uberaba CEFET-Uberaba e
Escola Agrotcnica Federal de Uberlndia EAF-Uberlndia, uniram-se e constituram
a nova instituio, o Instituto Federal de Educao, Cincia e Tecnologia do Tringulo
Mineiro IFTM. O IFTM atualmente conta com Reitoria na cidade de Uberaba e quatro
cmpus (Uberaba, Uberlndia, Ituiutaba e Paracatu) e dois cmpus Avanado
(Uberlndia e Patrocnio). Atualmente, conta com aproximadamente 700 servidores
efetivos para atendimento a 3000 alunos presenciais e 5000 alunos a distncia.

5.3. As Equipes
Para atendimento as demandas da rea de Tecnologia da Informao e
Comunicao, a estrutura organizacional da instituio possui a Diretoria de
Tecnologia da Informao e Comunicao, a fim de atender todos os projetos de
software no mbito do IFTM. Entretanto, para este estudo de caso, foram envolvidos os
colaboradores das equipes de sistemas conforme esto organizadas na Tabela 10. Estes
foram divididos em trs equipes, sendo um coordenador de sistemas e dois
desenvolvedores para cada equipe alocada. Todavia, estas equipes trabalharam de forma
integrada com objetivo de sincronizar as aes de desenvolvimento dos projetos de
software.

52

Tabela 10 - Identificao das equipes

Identificao da equipe

Quantidade de colaboradores

EQ1

Um Coordenador e dois desenvolvedores

EQ2

Um Coordenador e dois desenvolvedores

EQ3

Um Coordenador e dois desenvolvedores

5.4. Contextualizao do problema do estudo de caso

Os Institutos Federais so organizaes novas - criados em dezembro de 2008 com pouco tempo para conceber a nova estrutura organizacional. Apesar da absoro de
antigas autarquias a concepo dos institutos possuem caratersticas amplamente
diferentes. Consequentemente os modelos administrativos e gerenciais passaram por
severas mudanas com a implantao deste novo modelo de instituio, exigindo
solues emergentes na automatizao destes processos.
Foram realizadas vrias investigaes para compor o inventrio dos softwares
existentes no mbito do IFTM e observou-se, como eram desenvolvidos os sistemas
implantados nas antigas autarquias. Percebeu-se que no existia nenhuma metodologia
formalmente registrada, apenas aes individuais, onde pequenos sistemas eram
desenvolvidos para atendimento a particularidades de setores por meio da metodologia
cdigo-produto. Diante deste contexto, no foram encontrados artefatos de nenhum dos
sistemas implantados, ficando como documentaes apenas cdigos-fontes no
estruturados de alguns softwares.
Neste cenrio, o IFTM apresentou vrios problemas, tais como: integrao de
sistemas, protocolos de comunicao entre pessoas e processos; significativo tempo
gasto na deteco de soluo de problemas nos sistemas e outros oriundos da falta de
documentaes. importante destacar que cenrios como este apresentado pelo IFTM,
acredita-se que vrias outras instituies com mesmas caractersticas se encontram.
Para resolver estes problemas, importante destacar que em qualquer
organizao a informao um bem precioso, e para garantir o seu fluxo nos diversos
segmentos da organizao, necessrio sistemas de informao que sirvam como
ferramenta fundamental na realizao de seus objetivos. Entretanto, a exigncia do
dinamismo e da efetividade nas atividades pblicas vem sendo acelerada juntamente

53

com o ritmo das necessidades de estratgias organizacionais, diminuindo o ciclo das

informaes-decises-aes.
No entanto, para atendimento de tais objetivos, apresentou-se como soluo o
desenvolvimento de sistemas com estas caractersticas e estes so denominados
sistemas ERP (Enterprise Resource Planning). Outro termo tambm utilizado por
rgos pblicos, porm pouco explorado, so os GRPs (Governamment Resource
Planning), que so sistemas de informao que integram a maioria das operaes de
uma instituio em um nico software.
neste cenrio que o IFTM (local do estudo de caso) se encontra. De forma a
validar a proposta e verificar a adequao da mesma aos cenrios rotineiros dos times de
desenvolvimento de software, elaborou-se uma proposta de sistema (GRP-IFTM
Government Resource Planning do Instituto Federal do Tringulo Mineiro),
fundamentado na estratgia de desenvolvimento de software que alvo desta pesquisa.
Para tal aplicao, foram entrelaados os diversos segmentos do IFTM (equipes
de desenvolvimento, acadmicos, docentes, administrativos e apoio), de forma a
alcanar patamares de eficcia e eficincia no cumprimento de sua misso institucional.
Destacam-se os benefcios desejados, no domnio da aplicao de softwares:

Reduzir a redundncia de atividades na organizao;

Eliminar o uso de interfaces manuais;

Otimizar o fluxo da informao e a qualidade da mesma dentro da

Instituio;

Agilizar processos de tomada de deciso;

Gerar indicadores, mostrando uma viso real da atual situao da Instituio.

importante ressaltar que este sistema estar integrado ao Portal VIRTUALIF (Portal de Intranet do IFTM) e aos sites de todos os cmpus do IFTM, a fim de
dinamizar as informaes publicas nestes portais.

5.4.1. O Projeto GRP-IFTM

Como a MDS-GRP ser aplicada para construo de mdulos do GRP-IFTM,
esta seo ir apresentar o projeto GRP-IFTM.

54

Este projeto tem como objetivo, integrar os processos operacionais e gerenciais

desenvolvidos no mbito do IFTM. A Figura 19 apresenta uma viso conceitual da
diviso de seus mdulos, bem como suas integraes nos eixos centrais.
GRP-IFTM
(Sistema de Informao Integrado)

Mdulo de
Almoxarifado
Sigla: MAD-ALMOX

Mdulo de Protocolo
Sigla: MAD-PROT

Mdulos de
Pesquisa
Sigla: MPES

Mdulo de Gesto de
Gabinete
Sigla: MAD-GAB

Mdulo de Gesto de
Pessoas
Sigla: MAD-RH

Mdulos de
Planejamento
Sigla: MPLAN

INDICADORES
(Business Intelligence)

Mdulo de Gesto de
Contratos
Sigla:MADCONTRATOS

Mdulo de Compras e
Licitao
Sigla: MAD-CLT

Mdulo para controle

de produo
Sigla: MAD-PROD

Mdulo de Tecnologia
da Informao
Sigla: MAD-TI

Eixo Secundrio

VIRTUAL-IF
(Sistema de
Intranet), Portais
(Sites) e Sistema de
Educao a
Distncia - MOODLE

Eixo Secundrio

Mdulos de
Extenso
Sigla: MEXT

Mdulo de Patrimnio
Sigla: MAD-PAT

Eixo Secundrio

Mdulos
Administrativos
Sigla: MAD

Eixo Principal

Mdulos
Acadmicos
Sigla: MAC

Mdulos Administrativos - MAD

(Sistema de Informao Integrado)

Mdulo de Servios
Gerais
Sigla: MAD-SG

MAD-GA - INDICADORES
(Business Intelligence)

Figura 19 - Viso conceitual do projeto GRP-IFM.

Para este estudo de caso foram separados os submdulos MAD-ALMOX, MADGAB e MAC-PROT para aplicao da metodologia proposta.
A distribuio dos submdulos para equipes foi organizada conforme Tabela 11.
Tabela 11 - Distribuio dos submdulos entre as equipes
Equipe

Mdulo

Descrio do submdulos

EQ01

MAD-ALMOX

Mdulo de Almoxarifado

EQ02

MAC-PROT

Mdulo de Protocolo Acadmico

EQ03

MAD-GAB

Mdulo Gerenciador de Gabinete

55

6. Resultados e Limitaes da Metodologia

6.1 . Introduo
Conforme mencionado, para desenvolver um sistema computacional com
caractersticas de um GRP, necessria a definio de mtodos e tcnicas para
acompanhamento de todo processo de produo do mesmo. Portanto, para estes
mdulos iniciais aplicou-se a MDS-GRP para servir como guia de referncia no ciclo de
vida de desenvolvimento dos projetos. Esta MDS foi adotada por todos os
desenvolvedores envolvidos, com objetivo de permitir o acompanhamento das
atividades no processo de construo do GRP-IFTM.
A adoo da metodologia teve como foco melhorar as prticas na gesto de
projetos de software. Este captulo apresenta uma avaliao da adoo da MDS-GRP. A
proposta aqui apresentar os resultados e limitaes identificadas durante o uso da
metodologia no departamento de TI do IFTM Uberaba.

6.2 . Avaliao da MDS-GRP

A fim de avaliar a MDS-GRP, foi adotado um treinamento com todos os
integrantes das trs equipes (EQ1, EQ2 e EQ3, conforme apresentado no Captulo 5).
Este treinamento teve como objetivo principal apresentar a MDS para as equipes, a fim
de obterem os conhecimentos necessrios para sua aplicao. Alm disso, tambm
foram apresentadas todas as fases, os papis e os artefatos que seriam gerados.
Finalmente, foi apresentado o ambiente de gerenciamento de projeto denominado
Redmine, como ferramenta responsvel para acompanhamento das atividades/tarefas
executadas no projeto do mdulo em questo e permitir o armazenamento dos artefatos
produzidos.
Para avaliar a metodologia em seus diversos estgios, o projeto denominado
MAD-GAB (Mdulo de Gerenciamento do Gabinete mdulo que controla as
atividades, demandas, documentos oficiais e outras tarefas administrativas associadas
Reitoria do IFTM) foi escolhido como estudo de caso. Esta escolha se baseou no nvel
de envolvimento e domnio da equipe no referido projeto. A seguir, so apresentados de
forma cronolgica os eventos (passos) associados com a avaliao da metodologia.

56

Passo 1: A primeira interao, prevista como atividade na fase de Concepo

proposta, ocorreu entre o Patrocinador do projeto (normalmente, algum da alta gesto)
com o Gerente de Projetos (Figura 15). Nesta reunio, foram estabelecidas as fronteiras
do projeto e obteve-se o entendimento do escopo inicial do mesmo. Com isto foi gerado
o primeiro artefato projetado para a metodologia e definido como Documento de
Oficializao de Demanda DOD. Nesta mesma interao, foram apresentadas pelo
patrocinador as funcionalidades macros (Agenda Privada e Pblica do Reitor, Cadastro
de Demandas, Emisso de Documentos e Gerenciador de Reunies) para atendimento
da demanda requerida. Estas funcionalidades foram usadas para fomentar outro artefato
previsto: o Termo de Abertura do Projeto TAP.
De posse destes dois artefatos, DOD e TAP, foi possvel elaborar o Plano de
Projeto (PP), onde foi estabelecido um cronograma estimado, para as prximas
interaes. Como tarefa para o Gerente de Projetos, coube organizao das atividades
e tarefas do projeto no ambiente de Gerenciamento Redmine. Dentre estas atividades,
incluem-se: cadastrar os stakeholders envolvidos e referenciados por seu patrocinador,
definir os papis do time para trabalhar nas equipes especficas nas fases do projeto e
postar os primeiros artefatos gerados nesta iterao (DOD e o TAP). Uma observao
importante para atender os padres do GRP-IFTM a definio do nome do mdulo,
seguido de sua sigla para identificao no ambiente Redmine.
Passo 2: As prximas iteraes ocorreram entre a equipe de requisitos e os
stakeholders responsveis pelo conhecimento da rea especfica discutida (chefe de
gabinete, secretria executiva e assistente administrativa do gabinete). Na primeira
iterao do time, foram apresentados os artefatos anteriormente gerados (DOD, TAP e
Cronograma Estimado) e iniciou o primeiro ciclo de discusses para levantamento dos
requisitos do sistema, orientados pelas funcionalidades do mesmo, conforme previsto na
fase de Elaborao (Figura 16). Na prtica, a implementao de uma funcionalidade
gera vrios requisitos. Por exemplo, uma funcionalidade do mdulo MAD-GAB, aqui
denominada Gerencia de Demandas, gerou vrios requisitos necessrios para sua
construo. Para cada funcionalidade/requisitos identificados, a equipe responsvel
registrou estas informaes em formulrio prprio. Alm disso, como previsto, foi
elaborada uma ata com as discusses promovidas por todos os presentes.

57

Passo 3: Em seguida, as equipes responsveis por cada grupo de requisitos,

seguindo a metodologia, passaram a elaborar os prottipos de tela e os diagramas de
Casos de Uso. A ttulo de ilustrao, a Figura 20 apresenta um prottipo de tela criado
para a funcionalidade Gerncia de Demandas.

Figura 20 - Um prottipo de tela para a funcionalidade Gerencia de Demandas.

Para aprovao do design de uma tela, necessrio ter a liberao e assinatura

do Patrocinador ou um stakeholder designado pelo prprio Patrocinador (canto inferior
esquerdo da Figura 20).
Aps a realizao destas atividades, cabe ao Coordenador elaborar o plano para
a prxima reunio. Novamente, os artefatos e as informaes resultantes das iteraes
so cadastrados no sistema de gerenciamento Redmine. A seguir o diagrama de caso
de uso da funcionalidade Gerenciar Demandas apresentado.
58

Figura 21 - O Diagrama de Caso de Uso da Funcionalidade "Gerenciar Demandas".

Passo 4: Para apresentar o trabalho produzido, foram realizadas outras iteraes

a fim de aprovar os requisitos referentes de cada funcionalidade. Nesta reunio, as telas
e os Casos de Uso foram ajustados, de acordo com entendimento dos envolvidos.
Quando existem comum acordo e aceitao dos membros do projeto, dois novos
artefatos so produzidos: o Product Backlog e o Termo de Aceite (Figura 16).
importante destacar que o Product Backlog construdo e atualizado a cada iterao.
Entretanto, em sua verso final, este documento apresenta uma estimativa de esforo
como apoio para a equipe de desenvolvimento.
Passo 5: Agora, na fase de Construo, a equipe de desenvolvedores utilizam os
requisitos (e artefatos) registrado no ambiente Redmine, para elaborao do Dicionrio
de Dados, o Diagrama de Sequencia e o Diagrama de Classes (Figura 17). Em seguida,
a equipe criou os artefatos de codificaes e definies da estrutura de banco
necessrias para atendimento das funcionalidades. A seguir, a Figura 22 e a Figura 23
apresentam os Diagramas de Sequencia e de Classes da funcionalidade trabalhada.

59

Figura 22 - Diagrama de Classe da Funcionalidade "Gerenciar Demandas".

60

Figura 23 - Diagrama de Sequencia da funcionalidade "Cadastro de Demanda.

61

Conforme previsto nesta fase, a mesma equipe de desenvolvedores realiza testes

de exausto para cada funcionalidade. Com os primeiros testes realizados, a
funcionalidade foi liberada no servidor de treinamento para os stakeholders do projeto.
Aps outra srie de testes e validao, agora por parte dos stakeholders, o Termo Aceite
Atual foi formalmente registrado (Figura 17).
Passo 6: Finalmente, na fase de Transio (Figura 18), a equipe de integrao
apresenta a funcionalidade para aquelas equipes responsveis por outros componentes
do GRP e registra as possibilidades de integrao com outros mdulos do sistema. O
artefato esperado deste passo o Relatrio de Integrao.
Passo 7: Ainda na fase de Transio, a equipe de desenvolvimento implanta a
funcionalidade do mdulo no servidor de produo com objetivo de entregar o
componente funcional em operao. Para tanto, primeiro elabora-se a parte dos manuais
referentes funcionalidade aprovada. Esta etapa importante para treinar os usurios
em operar de forma eficaz e eficiente a funcionalidade liberada. O ltimo artefato do
ciclo o Termo de Aceite Final, devidamente assinado pelo stakeholder envolvido, ou
pelo Patrocinador do Projeto.

6.3 . Anlise da Metodologia por meio de questionrios

Esta seo apresenta os resultados obtidos pela anlise da aplicao da
metodologia proposta nas equipes de TI do IFTM. Foram disponibilizados trs projetos
(Gerenciador de Gabinete, Almoxarifado

e Protocolo Acadmico) para serem

trabalhados nesta pesquisa e estes foram divididos em trs equipes diferentes, conforme
relatado no Captulo 5.
Para os trs projetos, a MDS-GRP foi aplicada com objetivo de identificar os
impactos da mesma no desenvolvimento de sistemas. importante lembrar que a
fbrica de software no possua nenhuma metodologia adotada anteriormente. Assim, o
grande desafio desta proposta foi adequar metodologia conhecidas para a realidade das
equipes de TI envolvidas.
Para realizar a comparao entre as equipes, foi aplicado junto aos
coordenadores de sistemas e seus desenvolvedores, um questionrio. Neste questionrio
foram abordados aspectos relevantes para evidenciar a importncia da adoo da
metodologia. Para tanto, os avaliadores foram classificados como Coordenador de
62

Sistemas ou Desenvolvedor, e responderam dez questes de mltipla escolha sendo

as opes: Muito Satisfeito; Satisfeito e Insatisfeito. Ainda assim, para cada
questo, o questionrio permitiu ao avaliador descrever livremente opinies e/ou
possveis melhorias para adequaes da verso atual da MDS-GRP. Para explanao
deste campo, observou-se que o avaliador levou em considerao apenas quando optou
em marcar Satisfeito ou Insatisfeito.
A seguir, so apresentados os grficos gerados pelos questionrios para
demonstrar os resultados obtidos na anlise das entrevistas realizadas.

Pergunta 1: A comunicao entre a equipe de desenvolvimento por meio da

adoo da MDS-GRP obteve resultados melhores que anteriormente?
Respostas dos Coordenadores

Respostas dos Desenvolvedores

100%

100%

80%

80%

60%

60%

40%

40%

20%

20%
0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 24 - Comunicao entre as equipes de desenvolvimento aps MDS.

Para todos os avaliadores, a adoo da MDS-GRP resultou em ganhos

significativos na comunicao entre as equipes. Entretanto, na opinio de um dos
avaliadores, houve falta de comprometimento por parte das equipes e tambm o Gerente
de Projetos demorou em tomar uma posio mais firme quanto sua adoo. Neste
sentido, alguns resultados poderiam estar em melhores escalas.
A seguir relato de um outro avaliador que optou por estar Muito Satisfeito mas
utilizou o espao de explanao para dar seu parecer:
A padronizao permite um trabalho sincronizado e profissional
com facilidades de manuteno e entendimento, tornando a
capacitao das equipes equiparadas possuem o mesmo nvel de
entendimento de todos os mdulos desenvolvidos.

63

Pergunta 2: Os artefatos produzidos na MDS-GRP so suficientes para o

entendimento dos mdulos produzidos na sua equipe?
Respostas dos Coordenadores
100%
80%

Respostas dos Desenvolvedores

100%

67%

80%

60%

60%

33%

40%
20%

67%
33%

40%

0%

20%

0%

0%

0%
Muito
Satisfeito

Muito
Satisfeito

Satisfeito Insatisfeito

Satisfeito Insatisfeito

Figura 25 - Anlise dos artefatos produzidos na MDS.

Um dos avaliadores relatou que os artefatos gerados na MDS-GRP conseguem

exemplificar a viso da regra de negcio, da codificao das trs camadas e da estrutura
do banco de dados. Alm disso, outro avaliador relatou a necessidade da implantao de
padres de projetos.

Pergunta 3: As iteraes com os stakeholders apresentou melhores resultados

em termos de registro dos requisitos levantados?
Respostas dos Coordenadores
100%
80%

Respostas dos Desenvolvedores

100%

67%

60%

80%
60%

33%

40%
20%

50%

50%

40%

0%

0%

20%

0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 26 - Anlise das interaes com os stakeholders.

Os grficos acima revelam as diferentes formas de interao que ocorrem entre

as equipes envolvidas com os stakeholders. Claramente, preciso desenvolver melhores
formas de comunicao entre os stakeholders e os desenvolvedores. Particularmente,
dois fatos interessantes foram identificados:

64

1) Alm da falta de documentaes do processo de negcio (mapa dos

processos, fluxo dos processos e especificao dos processos), foram
detectados problemas relacionados ao perfil do stakeholder em no conhecer
o seu prprio processo dificultando os trabalhos da equipe de requisitos.
Analisando este fato, foi considerada a hiptese de incluir o Diagrama de
Atividades como mais um artefato, para facilitar o processo de comunicao
entre os desenvolvedores e os stakeholder.
2) Falta de registro por parte da equipe de requisitos. Este falto gerou conflitos
entre os desenvolvedores e os stakeholders sobre a existncia ou no de um
determinado requisito.

Pergunta 4: As informaes contidas nos artefatos da fase de Concepo

apresentaram de forma satisfatria a viso geral do escopo do projeto, bem como as
possveis funcionalidades iniciais?
Respostas dos Coordenadores
100%
80%

Respostas dos Desenvolvedores

100%

67%

80%

60%

60%

33%

40%

67%
33%

40%

20%

0%

0%

20%

0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 27 - Anlise de melhores resultados na viso geral do escopo do projeto e em possveis

funcionalidades.

Para esta questo algumas abordagens foram importantes e devem ser levadas
em conta para o aprimoramento da MDS-GRP. Abaixo, relato de um dos avaliadores na
seo de explanao:
A fase de Concepo possui a maior quantidade de pessoas envolvidas no
projeto, as quais podem no estar preparadas para um levantamento de
requisito adequado. Como sugesto seria interessante a elaborao de uma
capacitao para os patrocinadores do sistema, para entender conceitos,
tais como: projeto, processos, regra do negcio e auxiliar na seleo de
responsveis pelos requisitos e segmentao das funcionalidades.
65

Pergunta 5: Voc concorda que as telas prototipadas e devidamente aceitas por

parte dos stakeholders trouxeram maior segurana para implementao?
Respostas dos Coordenadores

Respostas dos Desenvolvedores

100%

100%

80%

80%

60%

60%

40%

40%

20%

20%

0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

66,67%

16,67%

Muito
Satisfeito

16,67%

Satisfeito

Insatisfeito

Figura 28 - Anlise do uso de prottipos de telas.

Em anlise das explanaes realizadas pelos avaliadores e dos resultados

apresentados pelos grficos, as equipes de requisitos e de desenvolvimento encontraram
dificuldades em conceber as telas prototipadas aos stakeholders. Tais dificuldades
foram, principalmente, quanto s modificaes constantes realizadas pelos ltimos e
muitas das vezes sem critrios de comum acordo entre os mesmos. Outro aspecto
relatado pelos avaliadores, so as mudanas constantes das telas aps estarem
implementadas. Estas demandas surgiram aps uma interao maior com as telas j
prontas, na fase de Construo.
O que se pode observar que o mecanismo de funcionamento das telas no ficou
inteiramente completo na viso dos stakeholders. Em destaque, o percentual
apresentado de 16,67% de Insatisfeito refere-se a um avaliador que relatou que
concorda que as telas prototipadas traduzem visualmente e funcionalmente o que o
stakeholder deseja.

Porm, nos projetos por ele trabalhados, este recurso no foi

amplamente utilizado. Fato este que justificou sua resposta.

66

Pergunta 6: Os trs diagramas da fase de Construo so suficientes para o

entendimento da equipe de desenvolvimento na implementao da funcionalidade
levantada?
Respostas dos Coordenadores
100%

80%

Respostas dos Desenvolvedores

100%

67%

80%

60%

33%

40%
20%

67%

60%

33%

40%
20%

0%

0%

0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 29 - Anlise do entendimento da equipe de desenvolvimento por meio dos artefatos produzidos.

Neste critrio, um dos avaliadores registrou no espao de explanao o seguinte

texto:
Na fase de Elaborao ao fazer o PB (Product Backlog) tem participao
do cliente, portanto acho que a existncia do DIAGRAMA DE
ATIVIDADES o cliente ter uma melhor viso do processo de
desenvolvimento, pois o mesmo tem como objetivo mostrar o fluxo das
atividades e suas dependncias.
Alm disso, um dos avaliadores com perfil de Coordenador respondeu estar
Insatisfeito, o que representou os 33% da porcentagem. Isto porque ele julga a
necessidade de outros diagramas de notao UML, como por exemplo, o Diagrama de
Atividades. Assim, este questionamento apontou a necessidade do Diagrama de
Atividades para auxiliar no processo de desenvolvimento das funcionalidades
trabalhadas.

67

Pergunta 7: Os testes de unidade funcional so suficientes para liberao dos

componentes dos mdulos em construo?
Respostas dos Coordenadores

Respostas dos Desenvolvedores

100%
100%

100%

80%

80%

60%

60%

40%

40%

20%

0%

0%

0%
Muito
Satisfeito

Satisfeito Insatisfeito

33%

33%

33%

20%
0%
Muito
Satisfeito

Satisfeito Insatisfeito

Figura 30 - Anlise dos testes de unidade funcional.

Apesar da totalidade dos coordenadores julgarem suficientes os testes funcionais

para liberao dos mdulos, relatos importantes foram abordados pelos desenvolvedores
que sugeriram que os testes tambm fossem realizados por equipes diferentes. Por
exemplo, a equipe EQ01 realizaria os testes das unidades funcionais da EQ02 e viceversa.
Outro ponto interessante abordado por um dos avaliadores o envolvimento das
equipes de TIs dos campus na realizao dos testes, antes das funcionalidades serem
liberadas para produo. Desta forma, a fase de testes envolveria um nmero maior de
testadores. Existe aqui um sentimento de que esta conduta produzir uma melhor
segurana quanto realizao do suporte em primeiro nvel aos usurios da
funcionalidade. Estas avaliaes refletiram a porcentagem de 33% de usurios
satisfeitos.
Alm disso, um conjunto de avaliadores detectou a necessidade de um
documento que oriente a conduo dos testes. Tal fato resultou numa quantidade de
33% de Insatisfeitos.

68

Pergunta 8: O tempo gasto na confeco dos artefatos impactou

significativamente no tempo usado para a construo dos mdulos
Respostas dos Coordenadores

Respostas dos Desenvolvedores

100%

100%

67%

80%
60%

80%
60%

33%

40%
20%

50%

50%

40%

0%

0%

20%

0%

0%
Muito
Satisfeito

Satisfeito

Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 31 - Anlise do tempo gasto entre a relao "artefatos x codificao".

Nesta questo foi detectada a necessidade de capacitao para alguns membros

das equipes de requisitos. Este fato refletiu numa quantidade menor (33%) de
Coordenadores no quesito Satisfeito, quando comparado com os Desenvolvedores
(50%).
Alm disso, importante destacar que um grupo de Satisfeitos da classe de
Desenvolvedores sinalizou que tiveram dificuldades na confeco dos artefatos, por
falta de conhecimentos do conjunto de notaes da linguagem de modelagem (UML).
Neste contexto, a busca pelo conhecimento de tais notaes e o aumento desta atividade
(gerao de artefatos) que anteriormente no eram realizados, teve como consequncia
um maior tempo na construo dos mdulos. Finalmente, a porcentagem apresentada no
perfil de Coordenador de 33% como Satisfeito sinalizou um cenrio de necessidade de
fora trabalho para realizar todas as fases da metodologia, inclusive a confeco dos
artefatos.

69

Pergunta 9: A adoo da metodologia ajudou na melhoria da integrao entre

as equipes e no desenvolvimento do sistema?
Respostas dos Coordenadores
100%

Respostas dos Desenvolvedores

100%

100%

80%

80%

60%

60%

40%

40%

20%

20%

0%

0%

50%
33%
17%

0%

0%
Muito
Satisfeito

Satisfeito Insatisfeito

Muito
Satisfeito

Satisfeito

Insatisfeito

Figura 32 - Anlise dos resultados obtidos na integrao das equipes do projeto.

Pontos importantes foram abordados por ambos os perfis (Coordenadores e

Desenvolvedores). Em anlise ao grfico do perfil de Coordenador, 100% responderam
que esto satisfeitos com a integrao.

Porm, com opinies e entendimento

divergentes. Este conflito justificado pelos seguintes itens:

1) A integrao entre as equipes permitiu a reutilizao de cdigos e troca
de experincias. Porm, ela necessita de cuidados no desenvolvimento
de mdulos que demandem implementaes de forte integrao, sendo
necessrio a aproximao destas para desenvolver a funcionalidade em
questo.
2) Necessidades de alteraes das tabelas comuns, afetando a dinmica dos
trabalhos da equipe.
3) A integrao independe da adoo da metodologia. Este autor,
particularmente, discorda deste fato, pois por meio dos processos
definidos na metodologia possvel atingir maiores integraes entre as
equipes para desenvolvimento do projeto proposto (GRP-IFTM).
O outro grfico representado pelo perfil de desenvolvedor demonstrou que 50 %
esto satisfeitos e 17% Insatisfeitos. Para estes Insatisfeitos sua angustia a falta de
critrios de programao, deixando aberta a forma com que cada equipe desenvolve
seus mdulos. Aqueles que responderam estar satisfeitos focaram no fato de disciplinar
as fases e os fluxos da metodologia. Principalmente, na realizao das reunies
sistemticas dirias e principalmente, de incio da semana. Para estes tambm seria
70

necessria a confeco de atas para registrar as discusses e socializar com seus

desenvolvedores.
Pergunta 10: A adoo da MDS-GRP apresentou maior controle nas atividades
rotineiras?
Respostas dos Coordenadores
100%

Respostas dos Desenvolvedores

100%

100%

80%

80%
60%

60%

40%

40%

20%

0%

0%

67%
33%

20%

0%

0%

0%
Muito
Satisfeito

Satisfeito Insatisfeito

Muito
Satisfeito

Satisfeito Insatisfeito

Figura 33 - Anlise dos resultados quanto ao controle das atividades.

Os 33% dos desenvolvedores que classificaram como satisfeitos declararam que

determinadas atividades no foram executadas conforme proposto, devendo haver maior
comprometimento dos envolvidos nos projetos. Entretanto, para a maioria a MDS-GRP
proporcionou ganhos nos aspectos organizacionais, melhorando o fluxo e o controle das
atividades.

6.4 Consideraes Finais

Este captulo apresentou a avaliao da aplicao da MDS-GRP no estudo de
caso proposto. Os grficos apresentados neste captulo proporcionaram vises em vrios
aspectos que devem ser trabalhados para obteno de melhores resultados qualitativos
na gerao de artefatos textuais, grficos e cdigos-fontes. Os Coordenadores de
Sistemas e os Desenvolvedores demonstraram pontos de suma importncia que devero
ser discutidos entre as equipes de TIs para realizaes de possveis adequaes.
Em geral, pode-se concluir que a metodologia proposta proporcionou um melhor
mecanismo de desenvolvimento e documentao no cotidiano das equipes de TI
envolvidos. O prximo captulo apresenta as concluses finais e sugestes para
trabalhos futuros.

71

7. Concluses e Trabalhos Futuros

7.1 Introduo
Esta pesquisa apresentou como um resultado uma integrao de diferentes
metodologias (processo unificado e metodologias geis) na busca por melhores prticas
de desenvolvimento de software. Neste captulo destacam-se os principais pontos
estudados nesta dissertao. Alm disso, sero apresentadas sugestes para possveis
trabalhos futuros proveniente desta pesquisa e por fim as consideraes finais de sua
contribuio.

7.2 Concluses
Em um levantamento bibliogrfico durante a pesquisa, constatou-se a existncias
de trabalhos correlacionados que adaptaram metodologias de desenvolvimento para
aplicaes em projetos de software. Porm, a maioria destas no considerava uma
realidade com caractersticas inerentes de reparties pblicas.
Diante disso, este trabalho apresentou uma proposta em adequar o Processo
Unificado, apoiado por boas prticas de metodologias geis, para o desenvolvimento de
software, neste contexto. Para tanto, foi customizado o Processo Unificado de forma a
reduzir o nmero de fases e artefatos. Tal customizao teve como objetivo principal a
obteno de melhores critrios no gerenciamento do processo de desenvolvimento de
software em fbricas com caractersticas inerentes s equipes do estudo de caso
proposto.
Os estudos conduzidos nesta pesquisa resultaram em uma metodologia que foi
definida como MDS-GRP. As quatro fases trabalhadas no Processo Unificado
(Concepo, Elaborao, Construo e Transio), tambm foram utilizadas para este
trabalho. Porm foram customizadas cada etapa, definindo seus processos com seus
respectivos fluxos, os responsveis pela execuo destes e por fim os artefatos a serem
gerados.
Um estudo de caso com realidade de fbricas de software de reparties pblicas
foi utilizado como forma de avaliar os resultados inerentes a sua adoo. Com isso, a
fbrica em questo foi do Instituto Federal de Educao, Cincia e Tecnologia do
Tringulo Mineiro.
72

Antes da aplicao da proposta foi apresentado o projeto GRP-IFTM que

representa um sistema corporativo governamental. Este projeto j se encontrava em
andamento no momento desta pesquisa. Porm sem a utilizao de nenhuma
metodologia formalmente aprovada. A apresentao do GRP-IFTM teve como intuito
estabelecer o entendimento das principais caractersticas dos mdulos a serem
desenvolvidos. Neste sentido, aplicou-se a metodologia em trs mdulos do projeto
GRP-IFTM (Gerenciador de Gabinete, Almoxarifado e Protocolo Acadmico) com
aspectos prximos nos quesitos de complexidade e tamanho, e para cada um, uma
equipe com colaboradores diferentes. Porm para contextualizar tal aplicao foram
apresentados passos apenas de um dos projetos para demonstrar os seus diversos
estgios.
A adoo da metodologia teve como resultado, melhores prticas na gesto de
projetos de software e espera-se assim contribuir na perspectiva da integrao de outros
mdulos hierrquicos do Projeto GRP-IFTM.
importante ressaltar que atravs das anlises dos resultados dos questionrios
aplicados aos Coordenadores de Sistemas e Desenvolvedores, puderam demonstrar
alguns ajustes necessrios para o aprimoramento deste trabalho.
Como concluses da aplicao da metodologia, por meio do estudo de caso
apresentado, alguns pontos em destaque so abordados e conclui-se que:

A aplicao da MDS-GRP possibilitou melhores resultados nos aspectos

de comunicao entre as equipes de desenvolvimento.

Uma reviso quanto prtica de prototipaes de interfaces para

apreciao dos stakeholders se faz necessria.

Para obteno de melhores resultados nas atividades relacionadas aos

levantamentos de requisitos junto aos clientes, pertinente considerar
sugestes oriundas dos avaliadores quanto ao artefato Diagrama de
Atividades, sendo fundamentado para melhor aderncia do processo.
Entretanto, foram

considerados

suficientes

os

demais

artefatos

trabalhados para compreenso do mdulo.

A necessidade de capacitao de alguns membros das equipes para

confeco dos diagramas UML.

Deve haver maiores detalhes para execuo do processo de testes, antes

da liberao do produto final.
73

7.3 Trabalhos futuros

Diante de todos os aspectos demonstrados neste trabalho, alguns pontos foram
detectados durante o processo de aplicao e demandam maiores atenes. Portanto,
devem ser relacionados para possibilidades de trabalhos futuros:

Avaliao da aplicao do framework MPS.BR (Melhoria de Processos do

Software Brasileiro) para aprimorar a aderncia da MDS-GRP. Tal aplicao
destina-se a melhorar a capacidade de desenvolvimento do GRP-IFTM.

Aplicao da metodologia com outros mdulos a serem desenvolvidos

dentro do escopo do GRP-IFTM, a fim de avaliar o comportamento em
projetos com diferentes naturezas de desenvolvimento.

Outro aspecto quanto aos padres de projetos que tambm foram

sinalizados nas avaliaes desta pesquisa e demanda um estudo mais
profundo para aplicao conjuntamente com esta MDS.

7.4 Consideraes finais

Este trabalho apresentou transformaes na fbrica de software do estudo de
caso, pois atualmente a proposta deixou de ser sugestiva e se transformou em realidade.
Ela est sendo utilizada como metodologia padro para construo de todos os mdulos
do projeto GRP-IFTM. Percebe-se que este modelo poder ser utilizado por
organizaes de mesmo porte. Portanto, este trabalho buscou apresentar ao mundo
cientifico as vantagens de integrar mtodos tradicionais e mtodos geis para alcanar
melhores resultados no desenvolvimento de software.

74

8. Referncias
ALVES, N. Integrao de princpios de desenvolvimento gil de software ao
rup: um estudo emprico. 2011. 137 f. Tese (Doutorado) - Universidade Federal de
Uberlndia, Uberlndia, 2011. Cap. 4.
ALVES, N., CARVALHO, W., CARDOSO, A., LAMOUNIER JUNIOR, E.. Um
estudo de caso industrial sobre integrao de prticas geis no RUP. Revista
Cincia

Tecnologia,

Amrica

do

Norte,

14,

mar.

2012.

Disponvel

em:http://revistavirtual.unisal.br:81/seer/ojs-2.2.3/index.php/123/article/view/169.
Acesso em: 21 Jul. 2011.
ABRAHAMSSON, P. et al.. New Directions on Agile Methods: A Comparative
Analysis. International Conference on Software Engineering. Oregon: IEEE Computer
Society. 2003.
BECK, K. et al. Manifesto for Agile Software Development, 2001. Disponivel em:
<http://www.agilemanifesto.org>. Acesso em: 21 Agosto de 2012.
BECK, K. Extreme Programming Explained: Embrace Change. Reading: AddisonWesley, 2001.
BERTOLLO, Gleidson; FALBO, Ricardo de Almeida. Apoio Automatizado
Definio de Processos em Nveis. In: II Simpsio Brasileiro de Qualidade de
Software, 2003, Fortaleza, Cear. Anais do II Simpsio Brasileiro de Qualidade de
Software, 2003. p. 77-91.
BOEHM, B.; TURNER, R. Balancing Agility and Discipline: Evaluating and
Integrating Agile and Plan-Driven Methods. International Conference on Software
Engineering. Washington, DC, USA: IEEE Computer Society. 2004a.
BOOCH, Grady; RUMBAUCH, James; JACOBSON, Ivar. UML: Guia do Usurio. 2
ed. So Paulo: Elsevier, 2006.
COHEN, D.; LINDVALL, M.; COSTA, P. An Introduction to Agile Methods.
Amsterdam: Elsevier, v. 62, 2004.

75

DYB, T.; DINGSYR, T.. Empirical studies of agile Software development: A

systematic review. Information and Software Technology, v. 50, 2008.
DYB, T.; DINGSYR, T.. What Do We Know about Agile Software
Development? IEEE Software, 2009.
FERNANDES, A. A.; TEIXEIRA, D. S.. Fbrica de Software: Implantao e gesto
de Operaes. So Paulo: Atlas, 2004.
FERRER, Florencia; SANTOS, Paula; SOLA, Pier Carlo. Governo digital: origem do
conceito e modelo para discusso. In: FERRER, Florencia; SANTOS, Paula (Org.).
E-Government: o governo eletrnico no Brasil. So Paulo: Saraiva, 2004. p.114-119.
FUGGETTA, Alfonso. Software Process: A Roadmap. In: 22nd International
Conference on on Software Engineering (ICSE), Proceedings of the Conference on the
Future of Software Engineering, New York: ACM Press, 2000. pp. 25-34.
GREER, D.; CONRADI, R.. Software Project Initiation and Planning: An
Empirical Study. Institution Of Engineering And Technology, Northern Ireland, UK,
v. 5, n. 3, p.356-368, 01 out. 2009.
ISO/IEC 12207, 1995, Information Techonology Software Life-Cycle Processes
JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. Unified Software Development
Process. Reading: Addison-Wesley, 1999.
KOSCIANSKI, Andr; SOARES, Michel Dos Santos. Qualidade de Software:aprenda
as metodologias e tcnicas mais modernas para o desenvolvimento de software. 2 ed.
So Paulo: Novatec, 2007
LEFFINGWELL, D. Scaling Software Agility. Reading: Addison Wesley, 2006.
MACHADO, Luis Filipe Dionisio Cavalcanti. MODELO PARA DEFINIO DE
PROCESSOS DE SOFTWARE NA ESTAO TABA. 2000. 123 f. Dissertao
(Mestrado) - Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2000. Cap. 1.
MAIA, Anderson Baia; FREITAS, Ana Vitoria Piaggio de; NUNES, Daltro Jos. Um
Modelo para Auxiliar a Adaptao de Processos de Software. In: Anais do IV
76

CONGRESSO BRASILEIRO DE COMPUTAO, Itaja - Santa Catarina: Univali,

2004. p. 155 - 160.
MARTINS, Jos Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de
Software com PMI, RUP e UML. 3 ed. Rio de Janeiro: Brasport, 2006.
MATTIOLI, F.E.R.; LAMOUNIER Jr., E. A.; CARDOSO, A.; Alves, N.M.M; Uma
proposta para o desenvolvimento gil de ambientes virtuais. In: Anais do VI
Workshop de Realidade Virtual e Aumentada WRVA2009, Santos, SP, 2009.
MENDES, Juliana Veiga; ESCRIVO FILHO, Edmundo. Sistemas integrados de
gesto ERP em pequenas empresas: um confronto entre o referencial terico e a
prtica empresarial. Gesto & Produo, So Carlos: Ufscar, v.9, n.3, p.277-296, dez.
2002.
NORD, R.; TOMAYKO, J. Software Architecture-Centric Methods and Agile
Development. IEEE Software, 2006.
PAULA FILHO, Wilson de Pdua. Engenharia de Software: Fundamentos, Mtodos e
Padres. 3 ed. Rio de Janeiro: Ltc, 2009.
PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prtica. 2 ed. So
Paulo: Pearson, 2004.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos.
4.ed.Project Management Institute, Inc. 2008
PRESSMAN, Roger S.. Software Engineering: A Practitioner's Approach. 6th New
York: Mcgraw-hill, 2006.
PRESSMAN, Roger S.. Engenharia de Software: Uma Abordagem Profissional. 7 ed.
Porto Alegre: Amgh, 2011.
OSTERWEIL, L.. Software Process Are Software Too. In: 9th International
Conference on Software Engineering (ICSE), Monterey, Estados Unidos, 1987, p. 2-13.
RAMSIN, R.; PAIGE, R. F. Process-Centered Review of Object Oriented Software
Development Methodologies. ACM Computing Surveys, v. 40, n. 1, 2008.
77

ROCHA, Rodrigo. et al. Uma Experincia na Adaptao do RUP em Pequenas

Equipes

de

Desenvolvimento

Distribudo.

In:

II

WORKSHOP

DE

DESENVOLVIMENTO DISTRIBUDO DE SOFTWARE - WDDS, 2008, CampinasSP. Anais do II Workshop de Desenvolvimento Distribudo de Software WDDS. Campinas-SP: Universidade Estadual de Maring (UEM), 2008. p.81-90
ROCHA, Thayssa guila da; OLIVEIRA, Sandro Ronaldo Bezerra; VASCONCELOS,
Alexandre Marcos Lins de. Adequao de Processos para Fbricas de Software. In:
VI SIMPSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE
SOFTWARE, 2004, So Paulo-SP. Anais do VI Simpsio Internacional de Melhoria de
Processos de Software. So Paulo- SP: SIMPROS, 2004. p.131-142.
ROMBACH, D.; SEELISCH, F. Formalisms in Software Engineering: Myths
Versus Empirical Facts. Central and East European Conference on Software
Engineering Techniques. Poznan: Springer. 2007. p. 13-25.
SCHWABER, K.; Agile Project Management with Scrum: Microsoft Press, 2004
SCOTT, Kendall. O Processo Unificado Explicado. So Paulo: Bookman, 2003.
SHACH, Stephen R.. Engenharia de Software: Os Paradigmas Clssico Orientado a
Objetos. 7 ed. So Paulo: Mcgraw-hill, 2009.
SOMMERVILLE, Ian. Engenharia de Software. 9 ed. So Paulo: Pearson, 2011.
SOUZA, Francisco Flavio de ; BRAGA, R. T. V. . Um Mtodo de Desenvolvimento
de Sistemas de Grande Porte Baseado no Processo RUP. In: 1 Simpsio Brasileiro
de Sistemas de Informao, 2004, Porto Alegre - RS. Anais do 1 SBSI, 2004. p. 31-38.
TELES, Vincius Manhes. Extreme Programming. So Paulo: Novatec, 2004.

78

ANEXO I Questionrio aplicado

Avaliador:
( ) Coordenador

Avaliao da Proposta MDS-GRP

Data Avaliao:
( ) Desenvolvedor

Assinale, por favor, a opo que melhor traduz a sua opinio.

Evidncia a adoo da MDS-GRP

1. A comunicao entre a equipe de desenvolvimento por meio da adoo da MDSGRP obteve resultados melhores que anteriormente?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (ausncia
de alguma atividade, etc).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
2. Os artefatos produzidos na MDS-GRP so suficientes para o entendimento dos
mdulos produzidos na sua equipe?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (ausncia
de algum artefato, etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
3. As iteraes com os stakeholders apresentou melhores resultados em termos de

registro dos requisitos levantados?

(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (natureza
dos formulrios usados na iterao, artefatos resultantes da fase de aprovao
temos de aceite etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

79

4. As informaes contidas nos artefatos da fase de Concepo apresentaram de

forma satisfatria a viso geral do escopo do projeto, bem como as possveis
funcionalidades iniciais?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (quais
informaes estes poderiam ser acrescentadas para o entendimento do escopo
inicial; a necessidade de mais alguns artefatos como complemento e quais seriam
estes e etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
5. Voc concorda que as telas prototipadas e devidamente aceitas por parte
do stakeholder trouxe maior segurana para implementao?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo. (real
necessidade das telas prototipadas e assinadas e etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
6. O trs diagramas da fase de Construo so suficientes para o entendimento da
equipe de desenvolvimento na implementao da funcionalidade levantada?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (ausncia
ou excluso de algum artefato e etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
7. Os testes de unidade funcional so importantes no impacto para liberao dos
componentes dos mdulos em construo?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (algum
procedimento poderia contribuir e etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

80

8.

O tempo gasto na gerao dos artefatos impactou significativamente no tempo

usado para a construo dos mdulos
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (necessita
de mtricas que comtemplem o tempo para confeco dos artefatos e etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
9. A adoo da metodologia ajudou na melhoria da interao entre as equipes e no
desenvolvimento do sistema?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo (reunies
semanais para estabelecer as possveis integraes e padres de desenvolvimento).
Alm disso, agradecemos se for o caso, a gentileza de explicar COMO a adoo da
metodologia ajudou nesta melhoria.

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
10. A adoo da MDS-GRP apresentou maior controle nas atividades rotineiras?
(

) Muito Satisfeito (

) Satisfeito

) Insatisfeito

Caso sua opo no for Muito satisfeito, favor explanar abaixo o motivo.
(necessidade de rotinas mais definidas etc.).

________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________

Comentrios/ Observaes:

81