Combinação de modelos ágeis e não ágeis em desenvolvimento de software

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO
Integrao de modelos de desenvolvimento de

software mais e menos geis
Pedro Miguel Ribeiro Veloso Gomes
VERSO FINAL
Relatrio de Dissertao
Mestrado Integrado em Engenharia Informtica e Computao
Orientador: Joo Carlos Pascoal de Faria (Doutor)
Co-orientador:
orientador: Ademar Manuel Teixeira de Aguiar (Doutor)
Julho de 2009
Integrao de modelos de desenvolvimento de software
mais e menos geis
Pedro Miguel Ribeiro Veloso Gomes
Relatrio de Dissertao
Mestrado Integrado em Engenharia Informtica e Computao
Aprovado em provas pblicas pelo Jri:
Presidente: Ana Cristina Ramada Paiva Pimenta (Professor Auxiliar)

____________________________________________________
Arguente: Jos Carlos Nascimento (Professor Auxiliar)
Vogal: Joo Carlos Pascoal de Faria (Professor Auxiliar)
15 de Julho de 2009
Resumo
A utilizao de sistemas de informao continua a ter um crescimento exponencial ao
longo dos ltimos anos e um impacto cada vez mais acrescido. Estes sistemas so
intensivamente baseados em software, pelo que a gesto de projectos de desenvolvimento desta
natureza assume uma importncia acrescida.
A gesto de um projecto de desenvolvimento de software implica a utilizao de prticas

profissionais de gesto que controlem o mbito, o custo e o prazo. Por outro lado, um projecto
de desenvolvimento de software requer a utilizao de prticas de engenharia eficientes, que
garantam solues de qualidade, sustentveis e adaptadas utilizao social e humana.
Os dados de mercado mostram que continuamos a ter uma percentagem elevada de

projectos de software cancelados e uma percentagem muito elevada de projectos que no
cumprem com os objectivos de mbito, prazo e custo estabelecidos inicialmente.
A engenharia de software recente quando comparada com outras engenharias e tem

sofrido evolues constantes ao longo dos ltimos anos. Surgiram mltiplos modelos e
evolues de modelos de desenvolvimento de software, que sendo de natureza distinta j
demonstraram ter sucesso em contextos diversos.
Mais recentemente emergiram uma srie de metodologias de desenvolvimento de software

designadas de geis, que vm dar nfase na capacidade que um processo deve ter para absorver
mudanas ao longo de um projecto e na vertente humana, de auto-organizao da equipa e de
contacto prximo com o cliente e de confiana com o mesmo.
Esta tese pretende trazer um maior esclarecimento sobre os mtodos de desenvolvimento

de software mais utilizados actualmente, os mais e menos geis, e mostrar como a sua
combinao adequada pode trazer um valor acrescido na gesto de projectos de
desenvolvimento de software. Esta combinao ser instanciada atravs de um mtodo que
fornecer critrios e pressupostos para a criao de uma metodologia adaptada s necessidades
especficas de uma organizao.
Abstract
The information systems usage has experienced an exponential growth over the past years
as well an increasing impact on human life. These systems are much more software intensive
than before and for that software project management presents itself as a crucial discipline.
The management of a software development project implies professional practices that

assure the projects scope, cost and schedule control. On the other hand, a software development
project requires efficient engineering practices that assure high quality solutions, sustained and
adapted to social and human behavior.
Market figures show that we still have a big percentage of canceled software projects, and
a very high percentage of those who fail to meet the initial objectives for scope, cost and
schedule.
Software Engineering is recent, compared to other engineering disciplines, and it has

suffered a constant evolution over the past years. Multiple models and evolution to the existent
ones came up. Although presenting distinct natures, these models have proved their way in
diverse contexts.
More recently a series of methodologies for software development emerged which put the
emphasis on the capacity for a process to absorb changes, throughout the project and also on the
human side, promoting self-directed teams, a trustworthy and close contact with the customer.
This thesis aims to bring a higher degree of clarification on the most used software
development methodologies, more and less agile, and show how their combination can bring
value added to the software development project management.
This combination will be instantiated on a method that will supply criteria and pre-
requisites for a methodology adapted to the specific organization needs.
Agradecimentos
Quero agradecer aos meus orientadores, Pascoal Faria e Ademar Aguiar pelo apoio e
conhecimento prestado.
Um agradecimento para o Jim Over do Software Engineering Institute (SEI), cujas

conversas sobre engenharia de software so sempre inspiradoras.
Uma meno para Hilel Glazer do SEI que permitiu uma conversa muito interessante sobre
a combinao de mtodos geis e no geis com uma perspectiva muito agnstica e
agregadora.
Aos meus scios e equipa do FEUP CIQS (agora Strongstep), porque acima de tudo so
meus amigos.
Por fim, e mais importante do que tudo, Susana, aos meus pais e irmos.
Pedro Gomes
ndice
1 Introduo ..........................................................................................................................1
1.1 Enquadramento ..............................................................................................................1
1.2 Motivao e objectivos ..................................................................................................4
1.3 Estrutura da dissertao..................................................................................................4
2 Gesto do desenvolvimento de software ..........................................................................6
2.1 Introduo ......................................................................................................................6
2.2 CMMI.............................................................................................................................9
2.3 PMBOK .......................................................................................................................12
2.4 TSP/PSP .......................................................................................................................13
2.5 Modelos geis ..............................................................................................................17
2.6 Scrum ...........................................................................................................................18
2.7 Extreme programming .................................................................................................20
2.8 Combinando mtodos geis e no geis.......................................................................23
3 Anlise comparativa e critrios de seleco de modelos...............................................29
3.1 Anlise comparativa dos modelos ................................................................................29
3.2 O custo da qualidade ....................................................................................................32
3.3 Critrios na seleco de modelos de desenvolvimento ................................................34
4 Mtodo de seleco de modelos de desenvolvimento de software ................................36
4.1 Mtodo de planeamento ...............................................................................................36
4.2 Eplogo .........................................................................................................................38
5 Concluses e trabalho futuro ..........................................................................................39
5.1 Satisfao dos objectivos .............................................................................................39
5.2 Trabalho futuro ............................................................................................................40
Referncias..................................................................................................................................41
6 Mapa conceptual ..............................................................................................................43
Lista de Figuras
Figura 1 - Combinando prticas geis e no geis ................................................................ 2
Figura 2 - Projectos de desenvolvimento de Software.......................................................... 3
Figura 3 - Dimenses de gesto de organizaes ................................................................ 8
Figura 4 - CMMI - Framework de modelos.......................................................................... 9
Figura 5 - CMMI - Estrutura das reas de Processo ........................................................... 10
Figura 6 - Competncia e conscincia ................................................................................ 11
Figura 7 - CMMI - Nveis de maturidade ........................................................................... 11
Figura 8 - Ciclo de vida de um projecto - PMBOK ............................................................ 12
Figura 9 - TSP/PSP - Ciclo de vida .................................................................................... 14
Figura 10 - TSP/PSP Lanamento de iterao ................................................................. 15
Figura 11- TSP/PSP - Equipas ............................................................................................ 16
Figura 12 - Scrum ............................................................................................................... 19
Figura 13 - Scrum Burndown Chart.................................................................................... 20
Figura 14 - Extreme Programming - Prticas ..................................................................... 21
Figura 15 - Extreme Programming Ciclo de vida ............................................................ 23
Figura 16 - Cinco factores para seco de mtodos ............................................................ 24
Figura 17 - Aspectos culturais na seleco do mtodo ....................................................... 25
Figura 18 - Mtodo Boehm de seleco de metodologia .................................................... 25
Figura 19 - Desenvolvimento de Sistemas de Informao e de Software........................... 28
Figura 20 - Comparando os mtodos .................................................................................. 30
Figura 21 - Posicionamento das metodologias ................................................................... 31
Figura 22 - CMMI, Scrum e TSP/PSP ................................................................................ 32
Figura 23 - Centro de gravidade de um processo................................................................ 32
Figura 24 - Custo de performance e da qualidade .............................................................. 33
Figura 25 - Mtodo para planear a qualidade ..................................................................... 37
Figura 26 - Combinando prticas geis e no geis ............................................................ 38
Lista de Tabelas
Tabela 1- Percentagem de funes realizadas por software nos avies militares ................ 7
Tabela 2 - Sucesso nos Projectos de Software ..................................................................... 7
Tabela 3 - Mtodo de seleco de metodologia .................................................................. 26
Tabela 4 - Riscos metodolgicos de Boehm ....................................................................... 26
Tabela 5 - Eficincia de remoo de defeitos ..................................................................... 34
Abreviaturas e Definies
AGILE Agilidade no desenvolvimento de software
BACKLOG Termo utilizado nos mtodos geis que designa um conjunto de

funcionalidades a serem implementadas numa release
BURNDOWN CHART Grfico que foca no esforo a realizar num projecto
CMMI Capability Maturity Model Integration
CMMI-ACQ CMMI para aquisies de software
CMMI-DEV CMMI para desenvolvimento de software
CMMI-SERV CMMI para servios de software
EARNED VALUE Mtrica de gesto de projectos que foca no trabalho realizado
ESI European Software Institute
PAIR Programao de software executada por dois programadores no

PROGRAMMING mesmo terminal
REFACTORING Redesenho de software
RELEASE Resultado produzido que marca o final de uma iterao ou sprint
RUP Rational Unified Process
SCRUM Metodologia gil de desenvolvimento de software focada na gesto

do projecto
SEI Software Engineerig Institute
SPRINT Termo utilizado nos mtodos geis que designa um intervalo fixo de
tempo destinado ao desenvolvimento de funcionalidades
SPRINT Termo utilizado nos mtodos geis que designa uma reunio de lies
RETROSPECTIVE aprendidas relativa a um sprint
SPRINT REVIEW Termo utilizado nos mtodos geis que designa uma reunio de
apresentao das funcionalidades desenvolvidas
iv
STANDUP MEETING Termo utilizado nos mtodos geis para uma reunio, que feita em
p, de ponto de situao de desenvolvimento
TSP/PSP Team Software Process / Personal Software Process
USER STORIES Requisitos escritos de uma forma funcional simplificada em forma de

histria
XP Extreme Programming - Metodologia gil de desenvolvimento de

software focada em tcnicas de engenharias software
v
1 Introduo
Este trabalho realizado no mbito do Mestrado Integrado em Engenharia Informtica e

Computao da Faculdade de Engenharia da Universidade do Porto e visa fornecer uma
perspectiva sobre a utilizao integrada e adequada de modelos de desenvolvimento de
projectos de software mais e menos geis.
Pretende-se promover alguma clarificao sobre os diversos modelos existentes, a sua
natureza, os seus pontos comuns e os seus pontos distintos.
Com a introduo dos modelos de desenvolvimento geis surgiu uma certa confuso na
comunidade profissional, ao nvel de gestores e tcnicos sobre as caractersticas efectivas de
cada modelo e o seu correcto modo de utilizao. Este trabalho vai revisitar as caractersticas de
cada modelo especfico, dos mais proeminentes, e promover um mtodo que permita a uma
organizao, ou a um projecto, conseguir tirar o melhor partido dos mesmos (ver Anexo A
Mapa conceptual).
Este trabalho promoveu uma recolha de referncias sobre a literatura mais relevante para
os tpicos em questo, nomeadamente atravs da consulta dos autores mais relevantes, dos
artigos publicados nos ltimos anos, com subsequente consulta de referncias a outros artigos,
conferncias da especialidade, e com reunies com algumas pessoas de referncia do Software
Engineerig Institute (SEI).
1.1 Enquadramento
There is no question that better management helps, but I soon realize that until we
changed the practices of software professionals themselves, we could never achieve a truly
expert software engineering capability.1
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
Continuous attention to technical excellence and good design enhances agility. 2
1
Winning with software An executive strategy Watts S. Humphrey Addison Wesley 2002
2
Agile Manifesto http://agilemanisfesto.org 2001
Introduo
For any given project, the project manager, in collaboration with the project team, is
always responsible for determining which processes are appropriate, and the appropriate
degree of rigor for each process.3
Embora estas trs frases estejam alinhadas no essencial do seu contedo elas provm de
correntes completamente distintas de metodologias de gesto. Provavelmente indica-nos que a
sua essncia provavelmente est correcta e que necessrio perceber qual a adequabilidade dos
contextos de aplicao.
Boehm utiliza a metfora do macaco e do elefante para ilustrar a diferena entre os

mtodos geis e no geis de desenvolvimento de software [Boehm2004]. O macaco que reage
rapidamente s adversidade e consegue atingir pontos elevados da floresta e o elefante que
suporta grandes pesos, e que depois de estar em andamento consegue percorrer grandes
distncias de uma forma robusta.
Figura 1 - Combinando prticas geis e no geis

Cada um destes animais est mais adaptado para determinadas situaes especficas e em
conjunto conseguem alcanar mais resultados, do que se operarem de uma forma separada.
O desenvolvimento de software apresenta-se como uma tarefa essencial no mundo actual,

dada a dependncia crescente na utilizao de sistemas de informao. Esta dependncia que
exponencialmente crescente, no est sustentada por processos de engenharia maduros, tais
como os casos da engenharia civil, electrotcnica, mecnica, etc.
Na engenharia de software tem existido uma evoluo nos modelos e boas prticas que
regem o seu funcionamento. Estas boas prticas, que tm uma tradio da engenharia de
sistemas promoveram a qualidade tcnica dos produtos implementados, sustentada por
processos de desenvolvimento.
Tais boas prticas, que tiveram origem para contextos especficos de desenvolvimento de
software, promoveram a elaborao de documentao detalhada em cada projecto, para que a
sustentao das decises e o capital de conhecimento adquirido pudesse ser reaproveitado nas
evolues e nos projectos futuros. Por outro lado, os modelos de qualidade utilizados de base,
com uma tradio histrica na indstria automvel japonesa, estavam orientados para a
optimizao de processos que se baseavam em trabalhadores industriais por contraponto com a
sociedade e trabalhadores do conhecimento actual. Aliado a estes factores, um ltimo parece ter
contribudo para o nascer de uma filosofia gil de gesto e desenvolvimento de projectos, que
o facto de que os processos de desenvolvimento precisam de ser adaptados realidade dos
clientes, empresas e projectos especficos.
3
Project Management Body of Knowledge 4th edition Project Management Institute - 2008
2
Introduo
Figura 2 - Projectos de desenvolvimento de Software
Cada projecto de software envolve um fornecedor (ou mais) com determinada experincia,
com determinados processos intrnsecos, envolve tambm clientes, com nveis de experincia
diferentes, que por sua vez tm uma relao com nveis de maturidades especficos. Por outro
lado, estas duas entidades, cliente e fornecedores, implementam um projecto de software que
afecta determinado sistema, que envolve pessoas, processos e tecnologias. Os processos
envolvidos podem ter diferentes graus de criticidade e dinamismo variveis (Figura 2).
Dadas todas estas condicionantes envolvidas, existir um nico processo que responde de
forma satisfatria a todo o tipo de projectos de software?
E o que se entende por responder de forma satisfatria a um projecto?
Tanto as comunidades de profissionais geis e menos geis parecem ser pouco

conhecedoras das prticas que ambas advogam, tomando por isso perspectivas pouco agnsticas
sobre a adopo de modelos de desenvolvimento. Por outro lado, alguns profissionais, parecem
ter encontrado nas filosofias geis o pretexto ideal para deixar de efectuar algumas prticas que
no esto relacionadas directamente com a codificao de produtos de software, que promovem
uma gesto sustentada, quantitativa e assente numa viso de mdio e longo prazo no
desenvolvimento de software.
Por outro lado os movimentos geis vieram tornar mais explcito e trazer de novo para a
ordem do dia a importncia do factor humano, na gesto das equipas, na relao entre o cliente e
o fornecedor (parceiro).
Este trabalho foi realizado no seio de uma organizao que um grupo de inovao em
qualidade de software que se depara regularmente com os desafios de empresas de
desenvolvimento de software, que tem parcerias com os maiores referncias mundiais na rea
do desenvolvimento de software, nomeadamente o SEI e o European Software Institute (ESI).
Aps uma experincia de gesto de dezenas de projectos de desenvolvimento de software,

de diferentes dimenses, diferentes nveis de criticidade, com modelos de organizao
internacionais e com impactos organizacionais e sociais distintos, e aps o contacto com
dezenas de empresas de desenvolvimento de software, nacionais e internacionais, foi possvel
constatar que no existe uma orientao esclarecida sobre a forma de abordagem dos projectos
de desenvolvimento de software, adaptada s diferentes realidades sociais e tecnolgicas,
3
Introduo
relao entre os actores envolvidos, maturidade e s caractersticas intrnsecas de cada

projecto. Talvez como consequncia da natureza humana, as organizaes tendem a replicar
frmulas conhecidas, assentes sobre modelos em que se sentem confortveis, para diferentes
problemas e contextos.
1.2 Motivao e objectivos

A motivao deste trabalho fornecer um contributo para a gesto do desenvolvimento de
software atravs da indicao de formas de utilizao e articulao de modelos de
desenvolvimento de software mais e menos geis.
Este trabalho deve conseguir responder s seguintes questes:

Quais as diferenas principais entre os principais modelos de desenvolvimento de
software, mais e menos geis?
Que tipo de modelo de desenvolvimento de software deve uma organizao
adoptar?
Para que tipo de projectos se aplica cada tipo de modelo?
Para este objectivo foi efectuado um levantamento sobre os modelos de desenvolvimento

mais utilizados a nvel mundial, nomeadamente: o Capability Maturity Model Integration
(CMMI), o Team Software Process (TSP/PSP), o SCRUM e o Extreme Programming (XP),
consolidada numa anlise detalhada comparativa.
Durante o levantamento foram efectuados alguns comentrios que se focaro no
levantamento de pistas para a integrao e conjugao de modelos.
Foram tambm analisados os principais esforos da comunidade cientfica e empresarial,

para a articulao dos diferentes modelos de desenvolvimento.
Baseada na informao recolhida proposto um mtodo que permite definir, de acordo

com a natureza do sistema envolvido no desenvolvimento do projecto, quais os modelos de
desenvolvimento a aplicar.
1.3 Estrutura da dissertao
Para alm da introduo, esta dissertao contm mais 4 captulos.
No captulo Gesto do desenvolvimento de software, descrito o estado da arte

associado aos modelos de desenvolvimento de software e so apresentados respectivos trabalhos
relacionados com a articulao entre os diversos modelos.
No captulo Anlise comparativa e critrios feita uma anlise das principais prticas
que podem afectar a deciso relativa ao planeamento da gesto do desenvolvimento de software.
No captulo Mtodo de seleco de modelos de desenvolvimento de software

consolidada a informao do captulo anterior e proposto um mtodo, para apoio na seleco
das prticas de desenvolvimento de software para um determinado projecto.
4
Introduo
No captulo Concluses e trabalho futuro, so apresentadas as concluses do trabalho e

perspectivas de trabalho futuro.
5
2 Gesto do desenvolvimento de software
Neste captulo so percorridas as maiores tendncias metodolgicas inerentes ao

desenvolvimento de software, tanto nas reas ditas mais como menos geis.
Em primeiro lugar ser focada a crescente utilizao de software no mundo actual e a

necessidade de processo, pessoas e ferramentas capazes para o sucesso do projecto.
De seguida so analisadas as principais correntes associadas gesto de projectos de

desenvolvimento de software, comeando pelo modelo CMMI focado na gesto de processos de
uma organizao, de seguida o PMBOK, orientado para as melhores prticas de gesto de
projectos, de seguida feita uma anlise do TSP/PSP que pode ser considerada uma das
metodologias mais maduras (grau de definio, implementao e gesto quantitativa) em termos
de desenvolvimento de software, e por fim dois mtodos de desenvolvimento geis: Scrum mais
orientado para a gesto de projecto e o XP mais orientado para a engenharia.
Por fim feita uma anlise das iniciativas de combinao dos mtodos mais e menos geis.
2.1 Introduo
Cada vez mais o nosso mundo depende de informao e conhecimento, que so
maioritariamente suportados por sistemas de informao e como tal o desenvolvimento e
utilizao de software so um factor exponencialmente crescente veja-se o exemplo da
utilizao de software na aviao militar americana (Tabela 1).
Gesto do desenvolvimento de software
Tabela 1- Percentagem de funes realizadas por software nos avies militares 4
Apesar da importncia crescente do software nas organizaes espantoso verificar os

nmeros associados a projectos que terminam com sucesso, que so cancelados ou desafiados
(Tabela 2).
Tabela 2 - Sucesso nos Projectos de Software 5
Aproximadamente 22% dos projectos de software em 2008 foram cancelados

Aproximadamente 44% dos projectos de software em 2008 foram desafiados, ou seja,
terminaram sem cumprir de uma forma satisfatria um ou mais dos objectivos mbito,
prazo ou custo.
Estes nmeros, caso no sejam suficientemente esclarecedores, representam milhares de

milhes de euros de perdas directas e outros mais de perdas indirectas.
4
Winning with Software An executive summary, Watts S. Humphrey, Addison-Wesley, 2002
5
Standish group report Successful software Projects - 2008
7
O nmero de projectos desafiados, que no cumpriram com o mbito, custo ou prazo

inicialmente definidos, tem mantido uma tendncia estvel com uma pequena variao, ao longo
dos ltimos 14 anos. O nmero de projectos com sucesso sofreu uma ligeira melhoria por
contraponto com os projectos cancelados. Relativamente aos projectos cancelados, no
concludos, ou entregues e no utilizados, no deixa de ser estranho que nos ltimos 6 anos tem
existido uma tendncia consistente de crescimento.
Estamos a falar de projectos de software com uma engenharia associada recente (software),
que procura ainda encontrar o seu estado de maturidade.
O software construdo por pessoas que devem estar motivadas, essa disciplina
catalisada atravs de processos (formais e informais) e tornada mais eficiente atravs de
ferramentas so as trs dimenses crticas em que as organizaes se focam [Konrad2007].
Figura 3 - Dimenses de gesto de organizaes 6
Quando no existem processos, o sucesso dos projectos depende em grande parte dos
bombeiros das organizaes, a visibilidade sobre o estado de um projecto limitada, no h
tempo para pensar em melhorias, provocando uma postura reactiva na organizao, e por vezes
os bombeiros queimam-se e as cinzas voltam a acender-se.
A existncia de processos promove uma cultura de confiana na organizao, atravs da

previsibilidade dos procedimentos existentes, e permite uma gesto quantitativa, baseada em
factos.
Watt Humphrey [Wats2002] definiu que para uma boa gesto de software devem ser
observados trs princpios:
1. Reconhecer que estamos no negcio do software
2. A qualidade deve ser a prioridade mxima
3. Software de qualidade desenvolvido por pessoas disciplinadas e motivadas
Estes princpios reforam a importncia crescente que o software tem na sociedade actual,
como a qualidade fundamental na sua construo e como as pessoas so quem produz e utiliza
o software.
6
CMMI, 2nd Edition Guidelines for process integration and product improvement, Mary Beth Chrissis, Mike
Konrad and Sandy Shrum, Addison Wesley, 2007
8
2.2 CMMI
O Capability Maturity Model Integration (CMMI) um modelo de maturidade para
melhoria de processos de desenvolvimento de produtos e servios [Konrad2007]. Est dividido
em trs constelaes principais (Figura
( 4):
CMMI-DEV DEV Modelo de processos para organizaes que desenvolvem
produtos e servios.
CMMI-ACQ ACQ Modelo de processos para organizaes que fazem aquisies de
produtos e servios.
CMMI-SERV SERV Modelo de processos para organizaes que disponibilizam e
gerem servios.
Embora pensadas
adas no s para a indstria de software estas
stas constelaes permitem abarcar
o ciclo completo de desenvolvimento de software, desde o seu desenvolvimento ou aquisio
aqu
at a manuteno em produo. Neste trabalho ser focado o modelo de desenvolvimento
CMMI-DEV.
Figura 4 - CMMI - Framework de modelos
Este modelo de maturidade est dividido em reas de processo que fornecem prticas
processuais que as empresas
empresa devem adoptar,, no prescrevendo no entanto a forma de como o
devem fazer.
Este conceito fundamental pois ao contrrio do TSP/PSP, do Scrum ou do XP um

modelo no prescritivo, que permite que as prticas obrigatrias sejam instanciadas de formas
distintas, nomeadamente combinando diversos modelos. normal encontrar empresas que
implementam o modelo CMMI e que ao mesmo tempo, tenham prticas de gesto de projectos
alinhadas com o PMBOK, ou com normas de gesto de qualidade (ex: ex: ISO 9001) ou com
prticas geis.
9
Figura 5 - CMMI - Estrutura das reas de Processo7
As grandes reas de processo do CMMI-DEV esto relacionadas com a organizao, a

gesto de projectos, engenharia e suporte.
A rea de gesto de projectos contempla prticas de planeamento, monitorizao e
controlo, gesto de risco, gesto integrada, gesto das aquisies e gesto quantitativa de
projecto.
A rea de engenharia contempla a gesto e desenvolvimento de requisitos, a soluo
tcnica (desenho mais codificao), a integrao de produto, a verificao e a validao do
produto.
A rea de suporte prev a gesto de configuraes, mtricas, anlise e resoluo de causas
de problemas, anlise e tomada de decises, e controlo da qualidade dos produtos e dos
processos da organizao.
A fora deste modelo est relacionada por um lado com a componente de gesto da
organizao, onde esto previstas prticas para a construo e definio de processos, alinhados
com os objectivos estratgicos da empresa, gesto da formao, gesto da performance e gesto
da inovao, e por outro com as prticas genricas que definem o grau de institucionalizao
dos processos da empresa, ou seja, a forma como os processos fazem parte do dia-a-dia de cada
colaborador - competncia inconsciente da empresa (Figura 6).
7
CMMI, 2nd Edition Guidelines for process integration and product improvement, Mary Beth Chrissis, Mike
Konrad and Sandy Shrum, Addison Wesley, 2007
10
Figura 6 - Competncia e conscincia
Numa organizao, mais importante que a definio de processos a forma como os

mesmos esto embebidos na cultura e nas actividades dirias da empresa.
Mais do que o conhecimento de engenharia e de gesto de projectos que o modelo CMMI
aporta, a sua vertente de organizao deve ser fortemente considerada na definio de processos
de uma organizao.
O elemento mais conhecido do CMMI o facto de possuir uma representao de evoluo

baseada em nveis de maturidade (Figura 7):
1. Nvel de maturidade 1 Inicial (onde todas as empresas comeam)
2. Nvel de maturidade 2 Gerido
3. Nvel de maturidade 3 Definido
4. Nvel de maturidade 4 Gerido quantitativamente
5. Nvel de maturidade 5 Em optimizao
Os nveis de 4 e nveis 5 prevem uma gesto quantitativa das reas de processo.
Figura 7 - CMMI - Nveis de maturidade
11
Este elemento permite um caminho de evoluo para as empresas, com uma recomendao
de prioridade de implementao de prticas, permite uma forma de benchmarking entre
empresas e um grau de reconhecimento de mercado por parte dos contratantes.
Existe tambm uma representao contnua de evoluo, que no prescreve reas de

processo prioritrias, ficando ao critrio da organizao a evoluo desejada, rea de processo a
rea de processo. Normalmente aconselhvel uma mistura das duas representaes na
implementao de processos nas organizaes, dado que permite por um lado uma prioridade de
implementao alinhada com as necessidades da organizao com uma consequente possvel
certificao reconhecida pelo mercado.
A comunidade cientfica e o Software Engineering Institute abordam cada vez mais a

implementao conjunta, quando aplicvel do CMMI e das prticas geis [Alegria2006],
[Glazer2008], onde as principais concluses se focam na complementaridade e na necessidade
de definio dos contextos adequados de utilizao.
2.3 PMBOK
A gesto de projectos visa a concretizao de um mbito determinado, com um custo ou
investimento definido num prazo determinado [PMBOK2008].
A deciso de se avanar com um determinado projecto est intimamente ligada a retorno

previsto de investimento. No basta portanto controlar uma das variveis: mbito, prazo e custo
para que se possa considerar um projecto com sucesso. Adicionalmente podemos acrescentar os
parmetros qualidade e risco como variveis importantes de controlo: a qualidade porque
diferentes tipos de projecto podem requerer diferentes abordagens de controlo de qualidade
(quando os projectos afectam vidas humanas, ou negcios de forma estrutural); o risco porque,
por exemplo, por vezes certos projectos no podem ultrapassar, imperativamente, determinada
data ou determinado oramento.
O Project Management Body of Knowledge hoje o standard mais utilizado em termos

mundiais para a gesto de projecto. Este modelo suficientemente abrangente para funcionar
para qualquer rea de negcio, desde que complementado com prticas especficas do negcio
ou engenharia em questo.
Figura 8 - Ciclo de vida de um projecto - PMBOK
12
O ciclo de vida nos projectos no PMBOK compreende 5 fases principais com alguma
sequncia mas que se podem sobrepor no tempo:
Iniciao: onde se tomada a deciso efectiva de avanar com o projecto e se faz o
arranque formal do mesmo.
Planeamento: onde se planeiam todas as actividades do projecto.
Execuo: onde as actividades so executadas.
Monitorizao e Controlo: onde se processa a monitorizao e controlo das
variveis de gesto do projecto.
Fecho: onde se procedem s actividades de fecho do projecto.
Para as diversas fases do projecto esto previstas as seguintes actividades de gesto:

Integrao do projecto controlo das actividades de ciclo de vida de projecto, bem
como a integrao com todas as actividades necessrias.
mbito controlo do mbito global do projecto - no apenas requisitos.
Custo controlo do esforo de recursos humanos e custos de aquisies.
Tempo controlo das estimativas, prazo.
Comunicao controlo da comunicao entre os diversos stakeholders.
Recursos Humanos controlo da contratao das equipas.
Aquisies controlo de aquisies do projecto.
Qualidade controlo da qualidade dos produtos entregues.
Esta metodologia importante pois suficientemente completa para abarcar todas as

actividades inerentes gesto de projecto e por outro lado permite estar associada a diferentes
mtodos de engenharia, sejam eles de software ou no.
2.4 TSP/PSP
O Team Software Process (TSP) em conjunto com o Personal Software Process (PSP)
foram desenhados pelo SEI com o objectivo de fornecer uma estratgia e um conjunto definido
de procedimentos operacionais, para a implementao de mtodos de desenvolvimento de
software disciplinados, tanto ao nvel do indivduo como ao nvel da equipa [Watts2002]. Estas
metodologias devem ser sempre implementadas em conjunto.
O foco principal do TSP/PSP a produo de software com zero defeitos, de acordo com
os requisitos do cliente e no prazo estipulado. Caracteriza-se por utilizar mtodos quantitativos
na sua gesto, o que permite de forma rigorosa estimar e atingir os objectivos propostos como
garantir qualidade de vida s equipas envolvidas.
Segue o seguinte princpio base de funcionamento: necessrio pensar antes de executar,

e depois de executar necessrio rever, inspeccionar e testar. Este princpio garante eficincia
no processo, nomeadamente quando a dimenso, disperso e criticidade dos sistemas envolvidos
aumentam. um processo bastante prescritivo e bastante detalhado nos procedimentos que
promove de forma a garantir uma disseminao de prticas efectiva entre todos os elementos
das equipas.
13
Figura 9 - TSP/PSP - Ciclo de vida
A sua estrutura base iterativa, prevendo um processo de lanamento inicial (launch),

( para
um planeamento macro do projecto e organizao da equipa, seguido de relanamentos (Re-
launch) para cada iterao (Figura 9).
O processo de lanamento que demora tipicamente 4 dias e tem como principal objectivo o
planeamento detalhado da iterao (com uma durao tpica de 1 a 4 meses) com a construo
de uma equipa motivada, envolvida e comprometida com os resultados previstos (Figura 10).
14
Figura 10 - TSP/PSP Lanamento de iterao
Este lanamento [Humphrey2000] contempla a definio conjunta dos objectivos do

produto e de negcio do projecto, atribuio de papis e objectivos da equipa, a produo de
uma estratgia e de um processo
processo adaptado realidade do projecto, definio de uma plano
global e de um plano mais detalhado para a prxima fase, o desenvolvimento de um plano de
qualidade, a atribuio de tarefas e balanceamento de carga, uma avaliao formal do risco e
criao de respectivo plano de mitigao, preparao e apresentao do plano gesto de topo e
um post mortem do prprio lanamento.
A fase de desenvolvimento contempla as seguintes actividades embora possam ocorrer em

iteraes distintas:
Captura de requisitos e respectiva reviso e inspeco
Desenho de alto nvel e inspeco
Desenho de baixo nvel, reviso e inspeco
Codificao, reviso, testes unitrios e inspeco
Testes de integrao
Testes de sistema
A razo da utilizao obrigatria

obrig de revises e inspeces tem a ver com a eficincia que
estes mtodos possuem, face a testes realizados mais tarde no processo (ser mais frente
detalhado). A reviso feita pelo autor do artefacto em causa (cdigo ou documento), enquanto
que a inspeco efectuada por outros membros da equipa.
A gesto quantitativa do processo conseguida atravs de ferramentas que analisam a

informao de quatro mtricas base: tamanho, tempo, prazo e defeitos. Assim,
Assim cada elemento da
equipa, atravs de processos preferencialmente
preferencia automticos deve fazer o registo e classificao
de todos os defeitos que encontrou, o registo do tempo que demorou em cada tarefa, e o
processo de estimativa realizado atravs da avaliao do tamanho previsto do produto. O
acompanhamento do projecto efectuado atravs de algumas medidas entre as quais: earned
value, acompanhamento do esforo realizado e previsto de recursos, perfil de qualidade,
quantidade de defeitos eliminados em revises e inspeces.
15
A utilizao da mtrica, tamanho do produto, permite obter uma correlao entre o tempo
que foi previsto e o tempo efectivamente realizado para determinada dimenso de esforo. O
processo de estimativa segue um mtodo designado por PROBE proxy based estimation que
primeiramente identifica quais os componentes relevantes para estimativas, para a tecnologia ou
domnio concreto de desenvolvimento: classes, forms, triggers, funes, etc. De seguida as
estimativas so efectuadas sobre o nmero de componentes que se prev realizar, sendo que se
classificam com trs graus de complexidade. Para obter o tempo previsto para a realizao dos
componentes so utilizados os valores histricos do indivduo, ou no existindo, valores das
equipas, da organizao ou mdias de mercado, para a realizao de cada tarefa. Desta forma
cientfica, o grau de estimativa oferece um grau de preciso muito elevado.
Figura 11- TSP/PSP - Equipas
As equipas TSP/PSP so auto dirigidas (Figura 11) na medida em que todos os elementos
da equipa participam em todas as actividades de planeamento, monitorizao e execuo dos
trabalhos, no sendo apenas dirigidas como nas equipas mais tradicionais. Uma equipa TSP/PSP
prev uma srie de papis que podem ser acumulados por uma nica pessoa, sempre que
necessrio [Humphrey2005]:
Team leader com responsabilidade por garantir os objectivos do projecto, manter a
equipa motivada e o cliente satisfeito.
Coach com responsabilidade por garantir e treinar os elementos no desenvolvimento
das actividades TSP/PSP, normalmente externo equipa.
Gestor de planeamento com responsabilidade pelos planos do projecto e
acompanhamento das actividades individuais e do projecto.
Gestor de processo responsvel por ajudar toda a equipa em cumprir o processo
conforme foi definido.
Gestor de qualidade garantir que a equipa segue o plano de qualidade e acompanhar
os indicadores respectivos.
Gestor de suporte responsvel por ajudar na correcta utilizao de ferramentas e
gesto das configuraes.
Interface com o cliente garantir o alinhamento do projecto com os objectivos do
cliente.
Gestor de desenho garantir um desenho de grande qualidade, envolvendo toda a
equipa e fomentando a produo de boa documentao.
Gestor de implementao garantir uma boa implementao dos desenhos definidos e
com qualidade.
Gestor de testes garantir que todos os membros criam e executam os planos de testes
adequados.
16
2.5 Modelos geis
Os modelos geis de desenvolvimento de software foram primeiramente introduzidos

atravs de Mikio Aoyama em 1998 junto das fbricas de software japonesa [Aoyama1998].
Agilidade significa uma boa capacidade de adaptao a requisitos e contextos envolventes e por
isso caracterizada pelos seguintes atributos:
1. Processo de desenvolvimento incremental e evolutivo

Os processos menos geis tendem a fazer uma entrega total no final do projecto
enquanto os mtodos geis promovem entregas constantes e incrementais do produto,
promovendo a emergncia de novos requisitos e solues.
2. Processo modular e simples (lean)

Os processos devem ser simples e modulares de forma a poderem responder
rapidamente - pouco baseados na produo de documentao.
3. Orientado ao tempo
Nos processos geis o planeamento orientado a intervalos fixos de tempo (iteraes) e
no ao volume de esforo necessrio.
Estes atributos devem ser vistos e implementados como um todo e no de forma separada
para que os processos possam ser considerados geis. Estes mtodos so orientados s pessoas e
menos aos processos, dado que cada indivduo responsvel pela entrega de uma
funcionalidade completa. Nesta abordagem inicial de mtodos geis [Aoyama1998] foi referida
a componente da possibilidade do desenvolvimento distribudo mas no foi a da articulao com
o cliente.
Em 2001, uma srie de signatrios juntou-se para lanar um manifesto, que impulsionou de
forma significativa o movimento dos mtodos geis, atravs do Manifesto para o
desenvolvimento gil de Software [AgileMan2001]. A fora deste manifesto reside tambm no
facto de ter sido elaborada por personalidades proeminentes, relacionadas como
desenvolvimento de software.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Face s ideias apresentadas em 2001 sobressai o ponto de colaborao com o cliente em

relao negociao do contrato. Este ponto interessante pois uma rea de desafio forte para
estas metodologias em relao ao trabalho distribudo e relao com o cliente.
17
De acordo com os valores apresentados pelo Manifesto foram estabelecidos 12 princpios

que devem ser seguidos para que os processos de desenvolvimento sejam geis, apresentados de
seguida de forma simplificada:
As mudanas de requisitos so bem recebidas pois representam vantagens competitivas
para os clientes.
Devem existir entregas de software numa base semanal ou mensal.
As pessoas de negcio e os desenvolvedores devem trabalhar conjuntamente e
diariamente durante todo o projecto.
O trabalho deve ser realizado por indivduos motivados, sendo que para isso devem ser
providenciadas as condies e o suporte necessrios, bem como deve ser estabelecida
uma relao de confiana.
A forma mais eficiente de comunicao para e com o projecto a conversao cara a
cara.
A principal medida de progresso software que funciona.
Os processos geis promovem um desenvolvimento sustentado. Os sponsors,
desenvolvedores e utilizadores, devem estar habilitados para manter o mesmo ritmo de
desenvolvimento de forma indefinida.
Uma ateno contnua a bom desenho de solues e excelncia tcnica so
catalisadores da agilidade.
A simplicidade fundamental de forma a minimizar o trabalho a realizar.
As melhores arquitecturas, requisitos e desenhos emergem de equipas que so
autnomas, que se auto-organizam.
Em intervalos regulares as equipas reflectem em como podem ser mais eficazes e
eficientes ajustando os seus processos e mtodos de acordo com as reflexes.
Seja qual for a metodologia de desenvolvimento de software, a aplicao da maior parte

destes princpios consensual e no representam algo de inovador naquilo que foi a evoluo da
histria do desenvolvimento de software na sua componente de gesto de projectos e
engenharia. A forma como so implementados os princpios que pode por vezes suscitar
alguma discusso. Por exemplo, consensual que a forma mais eficaz de comunicao a
conversao cara a cara. Dizer isso no dizer que no deve existir documentao adequada,
para apoiar as comunicaes entre centenas de colaboradores, ou para manter um histrico
que permite tornar eficiente evolues futuras ou registar decises estratgicas relevantes.
O princpio mais desafiador o da obrigao da localizao conjunta dos elementos da

equipa, negcio e desenvolvedores, durante todo o projecto.
2.6 Scrum
O Scrum nasceu de um conceito importado do desporto rugby, onde dado nfase
comunicao entre a equipa (passes laterais e para trs) e ao avano por sprints. sobretudo um
modelo que foca na gesto de projectos e no tanto em tcnicas de engenharia de software.
Schwaber que desenvolveu o Scrum referiu que para se ser verdadeiramente gil, um processo
precisa de aceitar as mudanas em vez de procurar controlar a previsibilidade [Schwaber, 2002].
18
Figura 12 - Scrum
O Scrum tem no seu esqueleto iteraes que podem ir de duas semanas a um ms e

reunies dirias [Schwaber2004]. Cada iterao pressupe a entrega de funcionalidades que
foram definidas a partir de um backlog de funcionalidades e alocadas a um determinado sprint
(iterao).
Em cada iterao a equipa analisa os requisitos, considera a tecnologia disponvel e avalia

a sua capacidade e conhecimento para a implementao atravs do sprint planning.
Colectivamente a equipa determina como vai construir a funcionalidade, modificando a
abordagem diariamente sempre que encontra alguma dificuldade, complexidade ou surpresa.
Em cada reunio diria (daily scrum), que tem um intervalo de 15 minutos definido, cada
elemento deve responder a trs questes:
Foi efectuado alguma coisa desde a ltima reunio?
O que tem de ser feito entre esta e a prxima reunio?
O que que impede que o trabalho possa ser efectuada da forma mais eficaz
possvel?
Em cada iterao so realizadas duas reunies, um sprint review para comunicar e analisar
as funcionalidades desenvolvidas e um sprint retrospective para se analisar as lies aprendidas
de melhoria para a prxima iterao.
Este processo criativo define o corao da filosofia Scrum.
Esto definidos trs papis principais: o dono do produto, a equipa e o scrum master.
Todas as actividades de gesto esto divididas por estes trs papis. O dono do produto est
focado nas funcionalidades do produto, os objectivos em termos de retorno de investimento e
pela prioridade dos requisitos para a prxima iterao. A equipa responsvel pelo sucesso de
cada iterao e o scrum master responsvel por garantir que as regras do Scrum esto a ser
seguidas.
19
Figura 13 - Scrum Burndown Chart

A evoluo do progresso de cada iterao feita atravs de um burndown chart que mostra
o nmero de horas executadas e previstas para terminar.
2.7 Extreme programming

O Extreme Programming (XP) nasce por volta do ano 2000, por Kent Beck e visa quebrar
a premissa de que o custo de cada alterao num projecto aumenta exponencialmente medida
que o projecto avana [Beck2000]. Assim, atravs de uma srie de prticas foi desenvolvido um
modelo, que tenta tornar o custo das alteraes do projecto igual em todas as fases do projecto e
que segue os princpios dos mtodos geis.
O XP est sustentado atravs de quatro valores [Stephens2003]:

Comunicao: todas as equipas devem estar no mesmo stio para evitar problemas
de comunicao.
Simplicidade: as tarefas devem ser feitas da forma mais simples possvel a ideia
que fazer as tarefas de uma forma complexa, demora mais tempo e o resultado
obtido o mesmo.
Feedback: importante fomentar a comunicao entre a equipa e com o cliente, de
forma a obter a soluo correcta o mais depressa possvel. Seja nos requisitos, seja
na arquitectura, o feedback deve ser procurado.
Coragem: deve ser fomentada a coragem no projecto, nomeadamente para fazer
alteraes de desenho.
20
Figura 14 - Extreme Programming - Prticas
O XP constitudo por 12 prticas que tm de ser aplicadas em conjunto (Figura 14):

Test-driven development para cada classe desenvolvida de cdigo, primeiro
deve ser desenvolvido um teste que falhe, de seguida deve ser desenvolvido o
cdigo correspondente e de seguida o teste deve passar. Esta metodologia permite
implementar um custo reduzido de mudana, pois qualquer alterao efectuada
ser imediatamente verificada pelos testes previamente produzidos, permitindo
tambm incutir coragem para alteraes de arquitectura.
The planning game Nesta prtica so planeadas os requisitos, neste caso user
stories, para que se decidam em que iterao devem ser desenvolvidos e
entregues. As user stories devem ser estimveis e testveis. Cada user story (que
fica num story card) pendurada num quadro e deve ter uma estimativa de
esforo que deve variar entre duas a quatro semanas. Para cada story card, devem
ser criadas tarefas, de um a dois dias para facilitar a distribuio de trabalho. Para
cada alterao de requisito ou pedido de documentao criado um story card
com um esforo associado. O esforo total dispendido por iterao designado
por velocity e deve ser mantido constante ao longo do projecto e como tal
previsvel.
Whole team (anteriormente on-site customer) O XP advoga que o cliente deve

sentar-se com a equipa de desenvolvimento durante o projecto. Existiu uma
evoluo face ao publicado inicialmente onde agora o foco ter um nico
representante do cliente proxy (cliente esse que pode ser um conjunto de
pessoas). Esta prtica mais relaxada, parece vir responder dificuldade de um
princpio dos mtodos geis, relativamente necessidade da localizao conjunta
da equipa de desenvolvimento e do cliente.
21
Small releases Esta prtica fundamental nos mtodos geis claro

implementada pelo XP o racional por detrs o mesmo incrementar o nmero
de entregas o mais possvel. Est tambm ligado ao princpio XP de obteno de
feedback o mais cedo possvel. Recentemente o conceito de que uma release tem
de ser algo completamente funcional num ambiente de produo foi relaxado,
para algo que funcione apenas num ambiente de testes realizados por um cliente
interno algo aproximado a prottipos evoludos.
Metaphor A arquitectura de sistema complementada com uma metfora
unificadora a algo existente, como por exemplo: O sistema como uma padaria.
Tem o po, o forno, os padeiros, a mquina registadora, etc, . Esta forma
substitui a forma tradicional de documentao de arquitectura.
Simple design O princpio de que desenho simples mais simples de manter.
Mais tarde foi introduzida a prtica de design emergente, ou seja, um design que
vai sendo construdo medida que o problema e a soluo vo sendo melhor
compreendidos.
Refactoring Embora seja recomendado o design simples, tambm
recomendado que se corrija constantemente o desenho que no esteja bem feito,
tal como o cdigo duplicado. Dado que o desenho da arquitectura no feito
previamente recomenda-se que o desenho v emergindo e sendo corrigido ao
longo do tempo.
Collective ownership Cada programador responsvel por todo o cdigo,
embora sejam responsveis individualmente por cada tarefa. Por exemplo se um
programador v uma parte de cdigo que ache que no esteja bem feito deve
procurar corrigi-lo mesmo que no tenha sido ele a faz-lo. um conceito
interessante que forma uma responsabilidade colectiva por aquilo que
produzido, mas que no deve servir de forma de desresponsabilizao dos
elementos na equipa.
Pair programming Esta uma das prticas mais controversas e que diz respeito
a que cada equipa, que tem de ser par, deve ser formada por conjuntos de duas
pessoas, onde um codifica, outra verifica e ambos discutem os problemas e
solues. Dentro deste pair programming aconselhado que exista uma troca de
elementos regular entre os pares para fomentar a disseminao de conhecimento.
Continuous integration O cdigo deve ser testado e integrado em poucas horas,
no mximo um dia, e se no final do dia ainda existirem erros o cdigo deve ser
deitado fora. No dia seguinte o cdigo deve estar isento de erros.
Sustainable pace O esforo da equipa deve ser sustentado, a semana no deve
ter mais de quarenta horas, seno a qualidade diminui.
Programming standards recomendados em qualquer projecto de
desenvolvimento de software, promovem a facilidade de compreenso e
comunicao entre a equipa.
22
Figura 15 - Extreme Programming Ciclo de vida
O XP descreve quatro actividades bsicas no desenvolvimento de software: codificar,

testar, desenhar e ouvir. Por outra ordem poderamos mapear em requisitos (ouvir), desenhar
(desenho), codificar e testar.
O ciclo de vida do XP define-se por iteraes evolucionrias onde existem duas fases
principais (Figura 15): o planeamento da release e a execuo das iteraes. No confundir a
evoluo com pequenos incrementos, pois o processo de definio de requisitos, desenho,
codificao e testes feito quase em simultneo [extremeorg2006].
Cada iterao est dividida em ciclos de duas semanas, onde uma verso entregue ao
cliente interno, onde posteriormente ele decide se pretende que a verso seja testada pelo
utilizador final.
No incio de uma iterao existe uma reunio com o cliente e com os programadores, onde
so definidos as funcionalidades a implementar, atravs de user stories, os programadores
estimam o tempo necessrio para implementar cada user storie, e decido em conjunto que
funcionalidades ficam na prxima release e de fora. As user stories no devem ter muito
detalhe, sendo que o detalhe efectuado na prtica quando o cliente escreve os testes de
aceitao automatizados de relembrar que aqui o cliente um representante e pode ser algum
com background tcnico. Diariamente existe uma reunio de p (stand up meeting) onde so
discutidos problemas, solues e se promove o foco da equipa.
Esto definidos diversos papis no XP entre os quais o programador, o testador, o tracker,

responsvel por seguir o tempo associado a cada tarefa e como tal a velocidade do projecto e o
coach responsvel por treinar os elementos nas prticas XP.
2.8 Combinando mtodos geis e no geis
O ponto de partida de referncia para a anlise da combinao de modelos mais e menos

geis foi efectuado sobre o trabalho de Barry Boehm e Richard Turner Balancing agility and
discipline [Boehm2004] onde proposto um mtodo assente numa anlise de risco sobre os
factores considerados mais relevantes para a aplicao ajustada.
23
Este mtodo assenta sobre a anlise de cinco factores principais (Figura 16):
Figura 16 - Cinco factores para seco de mtodos8
1. Tamanho: as metodologias geis esto mais adaptadas para equipas pequenas enquanto
as metodologias menos geis so mais difceis de adaptar para equipas pequenas.
2. Criticidade: as metodologias geis, at hoje foram pouco testadas em sistemas de

grande criticidade, onde se adivinham dificuldades pela utilizao de design simples e
pouca documentao.
3. Dinamismo: o desenho simples de solues e refactoring constante protege o custo de

trabalho refeito em ambientes pouco estveis em termos de alterao de requisitos, mas
aumenta-o em ambientes estveis.
4. Maturidade dos membros da equipa: os mtodos geis funcionam melhor com membros
de equipas com mais capacidades ao nvel tcnico e ao nvel de entendimento
processual - como existem menos processos formais as decises ficam mais
dependentes de cada indivduo, e como tal as boas decises dependem da sua
capacidade.
5. Cultura: os mtodos geis funcionam melhor em equipas onde os membros se sentem

em ambientes com mais graus de liberdade de actuao (Figura 17).
Quanto mais a avaliao dos factores se aproxima do centro do grfico mais gil deve ser o
mtodo.
8
Balancing Agility and Discipline, Barry Boehm, Richard Turner, Addison-Wesley, 2004
24
Figura 17 - Aspectos culturais na seleco do mtodo9
Por outro lado considera tambm uma anlise de risco associada ao tipo de abordagem,
ponderando diversos factores, baseado num modelo de processo em espiral [Boehm2001] e
[MBASE2003].
Considerando estes cinco factores estabelecido um mtodo que prescreve como devem
ser utilizadas as abordagens geis e menos geis (Figura 18Figura 18 - Mtodo Boehm de
seleco de metodologia e Tabela 3).
Figura 18 - Mtodo Boehm de seleco de metodologia
9
Balancing Agility and Discipline, Barry Boehm, Richard Turner, Addison-Wesley, 2004
25
Tabela 3 - Mtodo de seleco de metodologia

Passo 1 Classificar os riscos associados de acordo com os riscos de ambiente, geis e
no geis (Tabela 4)
Passo 2a Se os riscos geis dominarem prosseguir com mtodos no geis baseados
numa gesto de riscos com foco nos riscos no geis
Passo 2b Se os riscos no geis dominarem prosseguir com mtodos geis baseados
numa gesto de riscos com foco nos riscos geis
Passo 3 Subdividir a arquitectura e adoptar a abordagem apropriada caso parte das
aplicaes possam apresentar topologias distintas.
Passo 4 Estabelecer um plano global do projecto com os riscos associados
Passo 5 Monitorizar o progresso, os riscos e oportunidades, reajustando o
balanceamento do processo conforme necessrio.
Em [Edeen2007] os autores combinam esta metodologia com o conceito de organizao

ambidestra, onde se podem dividir os projectos ou componentes de desenvolvimento, dos
projectos de software em duas subunidades da organizao separadas, vocacionadas
respectivamente para mtodos mais e menos geis. Esta abordagem enderea de forma simples
os riscos das necessidades de formao dos recursos nas respectivas abordagens metodolgicas,
A-Skill e P-Skill (Tabela 4), obrigando no entanto a uma dimenso mnima de organizao e
dupla cultura, o que implica um esforo extra de gesto.
Tabela 4 - Riscos metodolgicos de Boehm
Risco de ambiente
E-tech Incerteza tecnolgica
E-coord Complexidade de stakeholders
E-cmplx Complexidade de sistemas
Riscos geis
A-Scale Escalabilidade e criticidade
A-Yagni Uso de desenho simples
A-Churn Rotatividade de pessoal
A-Skill Poucos recursos formados em mtodos geis
Riscos mtodos no geis
P-Change Mudana rpida de requisitos ou prioridades
P-Speed Necessidade de resultados rpidos
P-Emerge Requisitos facilmente emergentes
P-Skill Poucos recursos formados em mtodos no geis
Os autores de [Boehm2005] identificam os principais desafios em combinar metodologias

geis em processos de desenvolvimento tradicionais, de acordo com trs reas principais:
processo de desenvolvimento, processo de negcio e conflitos com pessoas.
Processo de desenvolvimento
26
Variabilidade a integrao de equipas com ciclos de vida distintos pode levar ao

desenvolvimento de produtos bastante distintos e difceis de integrar.
Ciclos de vida distintos os mtodos geis focam em entregas contnuas e
antecipadas enquanto as no geis focam a sua entrega nas fases finais.
Sistemas legados os sistemas legados no so facilmente redesenhados
(refactoring), ou desacoplados para permitir entregas consecutivas e antecipadas.
Requisitos Os requisitos geis tendem a ser sobretudo funcionais e informais,
dificultando processo de verificao e validao dos mtodos no geis.
Processo de negcio
Recursos humanos: as organizaes devem aprender a acomodar assuntos
relacionados com recursos humanos tais como registos de tempos, descries de
funes, prmios e gesto de competncias. As pessoas por outro lado devem ser
capacitadas para procurar abordagens no tradicionais.
Gesto do progresso: os contractos tradicionais e as tcnicas de recolha de
informao podem ser consideradas desadequadas para suportar as prticas geis
Avaliaes de standards: a maior parte das prticas geis no esto preparadas para
suportar as evidncias necessrias, em termos de documentao, para suportar as
avaliaes relativamente a standards como o CMMI e a ISO 15504 (SPICE).
Conflitos com pessoas

Atitudes de gesto: as organizaes tradicionais tendem a definir papis rgidos
nas organizaes, enquanto nas metodologias geis promove-se a flexibilidade de
papis.
Assuntos logsticos: as equipas geis necessitam de estar colocadas de forma
prxima com ferramentas especficas para pair programming. Algumas empresas
no tm as condies necessrias em termos de espao de trabalho.
Gesto de pilotos: alguns gestores respondem aos sucessos dos pilotos geis com a
separao das equipas, com vista a uma promoo ou disseminao de boas
prticas. Este facto pode destruir as relaes de bom trabalho que vo sendo
criadas nas equipas.
Gesto da mudana lidar com recursos que se recusam a mudar de metodologia,
pode ser crtico na implementao de mtodos geis, dado que as suas prticas so
baseadas em confiana e em muita comunicao directa.
Em [Edeen2007] os autores alegam que o conceito de agilidade metodologias que so

mais orientadas s pessoas do que aos processos - tem mais a ver com a rea de sistemas de
informao (com preocupaes sociais e organizacionais) do que com o desenvolvimento de
software.
27
Figura 19 - Desenvolvimento de Sistemas de Informao e de Software
Em [Moe2008], os autores constataram que uma das maiores dificuldades na

implementao das prticas geis tem a ver com o grau de especializao de alguns dos recursos
e da dificuldade na criao de redundncia nas equipas.
Em 2008, Kalpana e Jagadish da Wipro, partilharam as suas experincias na utilizao de

mtodos geis, em ambientes de desenvolvimentos distribudos, numa das maiores empresas de
desenvolvimento de software offshore [Kalpana2008]. As suas principais concluses passaram
pela localizao das equipas junto dos clientes em diversos momentos do projecto e pela
utilizao intensiva de ferramentas para a comunicao e pela utilizao de documentao para
permitir uma melhor colaborao entre equipas.
Os autores em [Paasivaara2008] tambm reforam estes aspectos e falam da utilizao de

proxys de clientes que permitam uma comunicao directa entre pessoas. Em [Young2008] os
autores exploram a utilizao das novas tecnologias para lidar com os desafios da comunicao
e da confiana.
28
3 Anlise comparativa e critrios de
seleco de modelos
Este captulo comea apresentar uma srie de concluses sobre o estado da arte analisado
no captulo anterior, introduz o tema do custo da qualidade, e estabelece os princpios para um
mtodo global de planeamento de projectos de desenvolvimento de software, que integra os
diversos modelos referidos.
3.1 Anlise comparativa dos modelos

A anlise dos diferentes modelos, CMMI, PMBOK, TSP/PSP, Scrum, XP (Figura 20) e
dos mtodos de combinao permitem retirar as seguintes concluses (Figura 21).
O CMMI um modelo que est orientado para uma abrangncia global do

desenvolvimento de software, desde aos processos da organizao, aos de gesto de projecto e
aos de engenharia. no entanto um modelo no prescritivo e que permite a adopo e
combinao de outras metodologias ou parte delas. Em termos de certificao, de acordo com o
modelo SCAMPI, obriga apresentao das evidncias de cada uma das reas de processo, o
que para uma metodologia baseada em pouca documentao pode ser desafiante. O seu factor
distintivo est nos aspectos organizacionais: definio e controlo de processos, formao,
inovao e anlise e resoluo de causas de problemas estruturais.
O PMBOK oferece a metodologia mais completa de gesto de projectos, contemplando

aspectos como a gesto financeira, que no so abordados por nenhuma outra. Contempla
tambm um pouco de organizao mas ao nvel de gesto global de projectos numa organizao
(portfolio management).
O TSP/PSP uma metodologia iterativa de desenvolvimento de software, que abarca desde

a gesto de projectos, gesto da equipa, qualidade de software, gesto quantitativa do processo,
e prescreve uma sequncia de actividades de especificao, elaborao, reviso e inspeco do
trabalho produzido, sustentando por uma premissa de eficincia associada ao processo. No
apresenta indcios de problemas de escalabilidade ou de necessidade de localizao.
Anlise comparativa e critrios de seleco de modelos
Figura 20 - Comparando os mtodos
O Scrum uma metodologia gil iterativa, orientada para a gesto de projectos, que
promove a comunicao entre os elementos das equipas, desenho simples e pouco pensado a
nvel estratgico e pouca documentao. Est orientado para permitir mudanas de mbito ao
longo do projecto, promove entregas constantes e no muito prescritivo nas prticas de
engenharia.
O XP uma metodologia gil iterativa que foca em aspectos de engenharia, assenta sob
actividades que devem ser realizadas em conjunto, tais como o pair programming, refactoring,
simple desing e test driven development. uma metodologia prescritiva em termos de processos
de engenharia, que evita os requisitos detalhados e documentados, evita o desenho detalhado e a
documentao.
30
Figura 21 - Posicionamento das metodologias
Tanto o TSP/PSP, o Scrum como o XP assentam sobre princpios de iterao, e

reconhecimento da importncia e necessidade de empowerment das pessoas e equipas no
processo de desenvolvimento.
A necessidade de localizao do cliente junto com a equipa de desenvolvimento no parece

ser uma necessidade efectiva de nenhuma das metodologias, embora os princpios geis o
possam fazer transparecer.
As grandes diferenas entre o TSP/PSP e os mtodos geis Scrum e XP assentam

sobretudo:
na perspectiva detalhada e documental das prticas de engenharia e gesto do
projecto
na abordagem quantitativa da gesto dos processos de gesto e engenharia
no controlo de qualidade rigoroso associado
O TSP/PSP f-lo e o Scrum e XP no. O TSP/PSP portanto mais previsvel e como tal
escalvel para grandes projectos em termos de dimenso, localizao ou risco.
Como consequncia o TSP/PSP apresenta maior grau de previsibilidade e o Scrum e XP

maior grau de agilidade.
Num exerccio simplista de relacionamento do nvel de maturidade potencial de CMMI

com as metodologias TSP/PSP, XP e Scrum, o TSP/PSP estaria algures no nvel 4 [Wall2007],
devido sua gesto quantitativa e completude de definio de processos, o XP estaria a apontar
para o nvel trs, devido s prticas de engenharia j definidas, embora sem as componentes de
processo, e o Scrum no nvel dois devido ao seu foco na gesto de projectos.
31
Figura 22 - CMMI, Scrum e TSP/PSP
Foi abordado que consoante a organizao, o cliente, o projecto deve ser implementada
uma postura mais ou menos gil (Figura 23).
Figura 23 - Centro de gravidade de um processo
O modelo de Barry Boehm e Richard Turner [Boehm2004] contempla um mtodo global

de deciso sobre a aplicao de mtodos geis e no geis que pressupe a anlise do contexto
do projecto (mais ou menos gil) consoante cinco factores: maturidade da equipa, dinamismo,
criticidade, tamanho e cultura, e depois a subdiviso do projecto em eventuais perfis distintos de
agilidade e posterior gesto de risco associado a cada perfil (ver captulo Combinando mtodos
geis e no geis).
3.2 O custo da qualidade

O custo de um projecto de software pode ser analisado de acordo com o modelo apresentado
pela Ratheon em 1995 (Figura 24), que faz uma decomposio em duas vertentes principais: o
custo de performance e o custo da qualidade.
32
Figura 24 - Custo de performance e da qualidade10
O custo da performance tem a ver com todas as actividades que visam a produo de algo
que necessariamente tem que acontecer no projecto e o custo da qualidade com o custo de
actividades de controlo de conformidade (testes ou actividades de preveno) e com o custo de
actividades de correco das no conformidades (trabalho repetido ou correco de erros).
Em termos de performance as empresas podem utilizar vrias tcnicas, tais como a

reutilizao, atravs de mdulos reutilizveis, frameworks, design patterns, ou automatizao,
atravs da gerao automtica de cdigo. No podemos esquecer no entanto que as diversas
actividades relacionadas com este modelo esto dependentes e relacionadas. Se eventualmente
no fizermos qualquer tipo de investimento em anlise de requisitos, muito provavelmente os
erros encontrados vo aumentar e o trabalho repetido tambm. Pelo que importa garantir que as
actividades relacionadas com a performance devem ser executadas de acordo com as melhores
prticas.
Para evitar as actividades de no conformidade, devemos portanto investir na excelncia de

execuo de actividades de performance e devemos atingir um equilbrio com as actividades de
controlo de conformidade para uma remoo eficiente e eficaz de defeitos encontrados. As
actividades relacionadas com a preveno de defeitos esto relacionadas sobretudo com a
organizao e respectiva gesto de processos, normas, formao, etc.
10
Raytheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017
,
1995
33
Relativamente s actividades de eliminao

eliminao de controlo reactivo de conformidade, como
revises, inspeces, testes, etc, em 1996 Jones [Jones1996] publicou um estudo que analisava a
eficincia associada aos mtodos de remoo de defeitos (Tabela
( 5).
Tabela 5 - Eficincia de remoo de defeitos
A anlise efectuada eficincia de remoo de defeitos de diversos mtodos, que tem sido
confirmada atravs de estudos posteriores [Nichols2009],, vem demonstrar que os mtodos de
remoo de defeitos em fases anteriores do desenvolvimento, nomeadamente com revises e
inspeces formais, so mais eficientes do que testes unitrios, testes integrados e de sistema.
3.3 Critrios na seleco de modelos de desenvolvimento

Dentro de uma organizao um projecto avana: ou porque obrigatrio, por advir de uma
necessidade de regulamentao ou de mercado; ou porque representa um valor acrescentado
organizao. Tanto num caso como noutro existe a necessidade de garantir por todos os meios o
retorno de investimento previsto ou a maior conteno possvel de custos.
Muitas vezes alguns projectos no avanam porque no podero estar realizados em

determinado prazo, ou porque representam um custo muito
muito elevado (ou sem retorno previsto)
para a organizao. Se um projecto est assente em determinados pressupostos de custos,
prazos, risco, mbito e qualidade, os processos pelos quais o mesmo implementado devem
garantir o mximo controlo destas variveis.
varivei Este controlo est associado previsibilidade.
Alguns valores so ingredientes chave para o sucesso dos projectos, e estes esto
espelhados em todos os mtodos apresentados:: desenvolvimento em iteraes, boa comunicao
com o cliente e entre a equipa, equipa motivadas, capacitadas e comprometidas e boas prticas
de engenharia.
Uma organizao normalmente no executa apenas um projecto, pelo que devem ser
definidas polticas organizacionais para a gesto de projectos, sendo que estas polticas devem
serr suficientemente flexveis para se poderem adaptar a contextos diferentes. A organizao
34
deve procurar de forma uniforme, inovar, aprender com lies aprendidas, suportar a formao
de todos os colaboradores, ter processos definidos que evoluem e se adaptam conforme as
necessidade e devem ser geridas com mtricas.
Os processos de engenharia de software devem procurar de forma eficiente a produo de

produtos ou servios de alta qualidade, pelo qual os mecanismos implementados devem ter em
conta essa eficincia.
Talvez faltem estudos mais rigorosos que comparem os modelos econmicos associados ao
Scrum e XP quando comparados com o TSP/PSP.
Pela informao disponvel o TSP/PSP parece ser de uma perspectiva racional mais
indicado em termos de adopo como metodologia de desenvolvimento. Tem no entanto um
custo de setup inicial elevado, que deve ser encarado como um investimento.
Para projectos de pequena dimenso ou criticidade, a utilizao de mtodos mais geis vai
responder de forma mais rpida e por vezes mais ajustada, mas sem documentao sustentada
algo que por vezes o cliente pede.
Em relao ao mtodo proposto por Boehm (ver captulo Combinando ), ser feita uma
proposta de modelo que abranja de uma forma mais global, a utilizao dos modelos
mencionados para aspectos de organizao e gesto de projectos.
Ser tambm complementado com alguns critrios de seleco na componente de relao

com o cliente, na forma de detectar partes geis dos projectos e no facto da equipa estar ou no
localizada em locais distintos.
O modelo referido pressupe a anlise dos componentes para se eventualmente detectar

padres geis de abordagem, mas no refere, que para alm dos componentes, as fases dos
projectos podem ser interessantes para aplicar este tipo de metodologias. Por exemplo: Pode
fazer sentido utilizar uma abordagem gil no incio de um projecto, para a realizao de uma
prova de conceito [Edeen2007], e depois caso o projecto avance se proceda com uma
metodologia menos gil.
35
4 Mtodo de seleco de modelos de
desenvolvimento de software
Neste captulo ser apresentado um mtodo para o planeamento de um projecto de

desenvolvimento de software, baseado no modelo de Boehm, de acordo com os princpios
estabelecidos no captulo anterior. Sero dados alguns exemplos de aplicao do mtodo em
diferentes tipologias de projectos.
4.1 Mtodo de planeamento
O mtodo de planeamento est dividido 4 fases, de A a D, com alguns componentes

transversais que devem ser implementados em qualquer situao e com a primeira fase opcional
caso apenas se esteja a prever a realizao de apenas um projecto na organizao. Como
resultado possvel pode ser recomendada:
A aplicao de metodologias geis como Scrum e XP
Mtodos geis (Scrum + XP) mas com gerao de documentao
TSP/PSP
O mtodo inicia-se com a recomendao clara da necessidade de implementao de

metodologias que enderecem as necessidades da gesto de uma organizao, ao nvel de
definio e controlo de processos, formao, inovao e anlise dos problemas ou lies
aprendidas. Esta necessidade pode ser colmatada com os modelos CMMI ou SPICE, que no
so prescritivos em relao s prticas de gesto de projectos ou de engenharia. O CMMI
especialmente recomendado dado o seu grau de implementao mundial, a comunidade
envolvente que o utiliza, e o facto de fornecer uma perspectiva integrada de desenvolvimento,
servios e aquisies de software.
O segundo passo passa pela implementao de uma norma de gesto de projectos

completa, que assegure todas as actividades necessrias sua gesto. Neste caso as normas
PMBOK ou Prince so aconselhadas dada a sua implantao e grau de completude.
Mtodo de seleco de modelos de desenvolvimento de software
Figura 25 - Mtodo para planear a qualidade
O terceiro passo tem a ver com a deteco de padres de implementao de mtodos geis
nos projectos. A deteco destes padres passam pelo objectivo inicial de que existe alguma
indefinio ou volatilidade potencial ao nvel de requisitos, para se poder explorar o conceito de
agilidade, mas deve garantir que todos os pressupostos seguintes esto assegurados:
A equipa tem alguma maturidade tcnica
A equipa est preparada para uma cultura no processual
O projecto ou fase no tem uma grande dimenso
O projecto ou fase no tem uma grande criticidade
Existe uma relao de confiana com o cliente
O cliente, ou representante, tem disponibilidade fsica e temporal
A equipa de projecto no est localizada em locais distintos
O cliente no solicita documentao exaustiva
A deteco destes padres pode ser efectuada ao nvel de um componente do projecto ou

de uma fase do projecto. Caso seja encontrado este padro, uma combinao de Scrum e XP
parece aconselhada, dado que so as metodologias geis mais utilizadas a nvel mundial.
Por fim, para as fases ou mdulos restantes do projecto, deve ser adoptada uma filosofia
no gil, que pode ser baseada numa filosofia gil mas que deve ser complementada com
37
Mtodo de seleco de modelos de desenvolvimento de software
princpios mais documentados, ou no TSP/PSP. Aqui recomenda-se a aplicao da prtica a que

a equipa est mais familiarizada ou em que seja oportuno investir.
Para projectos de grande dimenso ou criticidade recomenda-se a metodologia do tipo

TSP/PSP.
Independentemente da metodologia a implementao de componentes transversais deve

estar sempre presente:
Gesto da equipa: deve ser promovida uma gesto de equipa que garantam a sua
motivao e comprometimento. Isto conseguido atravs do seu correcto
envolvimento em todas as actividades que lhes afectam directamente, atravs de
uma garantia de autonomia de actuao e com uma componente de coaching, que
promova a excelncia de prticas atravs da uma liderana baseada no exemplo.
Desenvolvimento em iteraes: todas as metodologias modernas promovem hoje a

utilizao de iteraes nos projectos. Os seus benefcios so claros, pois
promovem uma reduo do risco do projecto, atravs de momentos antecipados de
aceitao do cliente, realizaes concretas e no tericas dos projectos, emergncia
de requisitos e desenhos.
Relao prxima com o cliente: o cliente no precisa de estar presente a todo a

hora junto da equipa de desenvolvimento, mas pelo menos em pensamento sim.
Deve existir um constante foco naquilo que so as necessidades do cliente, que se
traduzem no s pelo garantir do mbito correcto mas tambm do prazo e custo.
Deve ser promovida uma relao de proximidade com o cliente, que se consegue
atravs de um contacto frequente e de confiana. Essa confiana constri-se com
feedback, com cumprimento dos pressupostos estabelecidos.
4.2 Eplogo
O tigre representa a combinao de mtodos geis e no geis (Figura 26). Tem o grau de
robustez necessrio para grandes projectos e desafios e por outro lado capaz de reagir
rapidamente a situaes imprevistas.
Figura 26 - Combinando prticas geis e no geis
38
5 Concluses e trabalho futuro
Neste captulo so apresentadas as principais concluses do trabalho, face aos objectivos

propostos e so delineadas algumas linhas potenciais de trabalho futuro.
5.1 Satisfao dos objectivos

Esta tese props-se a responder a trs questes principais:
Quais as diferenas principais entre os principais modelos mais e menos geis?
Que tipo de modelo de desenvolvimento de projectos de software deve uma
organizao adoptar?
Para que tipo de projectos se aplicam cada tipo de modelo?
Pretendia-se com isto perceber de forma mais clara quais as diferenas, semelhanas e
graus de aplicabilidade de diferentes metodologias de desenvolvimento de software, para assim
conseguir uma gesto de projectos com maior sucesso. Este sucesso medido atravs da
satisfao do cliente e das suas expectativas indissociveis: mbito, custo, prazo e qualidade.
A resposta a estas questes foi efectuada atravs da anlise dos modelos de

desenvolvimento de software mais utilizados tanto nas reas geis como nas reas menos geis
(TSP/PSP, Scrum e XP), conjugada com modelos complementares mais orientados gesto da
organizao (CMMI) ou mais gesto de projectos (PMBOK). Esta anlise revelou que mais do
que as diferenas que os distinguem, existem objectivos e contextos de aplicabilidade distintos.
Do trabalho j realizado pela comunidade cientfica e empresarial, foi escolhido um

mtodo base para uma evoluo, que fizesse emergir um novo mtodo que contempla critrios e
pressupostos de deciso consoante o tipo de projecto, organizao e cliente em causa.
Este mtodo utiliza os modelos aqui referidos para adquirir uma abrangncia que trata a
rea de gesto dos processos da organizao, a gesto dos projectos e as prticas de engenharia.
Este mtodo salientou tambm as caractersticas que so transversais a qualquer modelo
seleccionado e que passam por uma evoluo iterativa dos projectos, uma gesto cuidada das
equipas, atravs do envolvimento, comprometimento, autonomia, motivao e coaching, e por
um foco no cliente, uma relao prxima, alinhada e de confiana.
Concluses e trabalho futuro
A conjugao do movimento gerado pelos mtodos geis e pelos mtodos menos geis
pode trazer uma fora virtuosa evoluo engenharia de software uma constante preocupao
pela excelncia dos produtos entregues, atravs de processos de desenvolvimento controlados e
sustentados aliados a uma capacidade de adaptao e inovao, e a um foco cuidado nas
pessoas.
5.2 Trabalho futuro

Existem vrios caminhos que podem ser escolhidos como linhas futuras de avano deste
trabalho.
Por uma lado a experimentao do mtodo em organizaes que desenvolvem software,

percebendo se de facto a sua aplicao propicia os resultados pretendidos. Associada a esta
experimentao devem estar previstos ajustes nos requisitos e pressupostos estabelecidos,
nomeadamente para a componente de deteco de padres geis e na deteco de padres
transversais de aplicao aqueles que no podem falhar seja qual for a metodologia.
Tantos os mtodos geis como os mtodos no geis tm sofrido evolues ao longo dos
ltimos anos, bem como tm surgido novos modelos (por exemplo o mtodo gil scrum-ban).
Estes novos mtodos devem ser analisados de forma a perceber que contribuies podem trazer
para o mtodo definido.
Por outro lado ser interessante observar a abrangncia das metodologias no s na

componente de desenvolvimento mas tambm nas componentes de gesto de servio de
software, aquisies e segurana. Por exemplo interessante verificar a evoluo do CMMI
para as componentes de servios e aquisies, a evoluo de TSP/PSP para aspectos de
manuteno de aplicaes.
Deve existir uma constante ateno comunidade cientfica e indstria que continuam a
produzir contribuies sobre o tema. No fcil encontrar experincias sustentadas por dados
quantitativos, especialmente nos mtodos geis, dados que eles assentam precisamente em
processos leves que no promovem a recolha de exaustiva de mtricas.
40
Referncias
[AgileMan2001] Manifesto for Agile Software Development - http://agilemanifesto.org
[Alegria2006] Implementing CMMI using a combination of agile methods, Joe Alegria,

Maria Bastarrica, CLEI Electronics Journal, 2006
[Aoyama1998] Agile Software Process and Its Experience, Mikio Aoyama, IEEE, 1998
[Beck2000] Kent Beck, Extreme Programming Explained: Embrace Change,Addison-

Wesley, 2000
[Boehm2001] Balancing Discipline and Flexibility With the Spiral Model and MBASE,
Barry Boehm, Daniel Port, Crosstalk 2001
[Boehm2004] Balancing Agility and Discipline, Barry Boehm, Richard Turner, Addison-
Wesley, 2004
[Boehm2005] Management challenges to implementing agile processes in traditional

development organizations, IEEE Software, Boehm, Turner, 2005
[Cohen2003] Agile Software Development - A DACS State-of-the-Art Report, David

Cohen, Mikael Lindvall and Patricia Costa, 2003
[ControlChaos2009] http://www.controlchaos.com, 2009
[Edeen2007] Agility versus Discipline: Is Reconciliation Possible? G. Galal-Edeen, A.

Riad, M. Seyan, ICCES Proceedings, 2007
[extremeorg2006] http://www.extremeprogramming.org/, 2006
[Glazer2008] CMMI or Agile - Why not embrace both! Hilel Glazer, Jeff Dalton, David
Anderson, Mike Konrada, Sandy Shrum, CMU/SEI-2008-TN-003, SEI, 2008
[Humphrey2000] Introduction to Team Software Process, Watts S. Humphrey, 2000, Addison-

Wesley
[Humphrey2005] TSP - Leading a deveopment team, Watts S. Humphrey, 2005, Addison-

Wesley
[Jones1996] Software defect-removal efficiency, Jones, 1996
[Kalpana2008] Adopting agile in Distributed development, KalpanaSureshchandra, Jagadish
41
Shrinivasavadhani, 2008
[Konrad2007] CMMI, 2nd Edition Guidelines for process integration and product
improvement, Mary Beth Chrissis, Mike Konrad and Sandy Shrum, Addison
Wesley, 2007
[Livermore2007] Factors that Impact Implementing an Agile Software Development

Methodology, Jeffrey A. Livermore, Walsh College, IEEE, 2007
[MBASE2003] Guidelines for Model-Based (System) Architecting and Software

Engineering (MBASE), Center for Software Engineering, University of
South California, 2003
[MCHale2005] Technical Report Mapping TSP to CMMI SEI - James McHale, Daniel S.
Wall, April 2005
[Mikio1998] Agile Software Process and Its Experience, 1988 IEEE
[Moe2008] Understanding Self-organizing teams in Agile Software Development, Nils

Moe, Torgeir Dingsoyr, Tore Dyba19th Australian Conference, 2008
[Nichols2009] Deploying TSP on a National Scale: Na expirience report from Pilot Project
in Mexico, Carneggie Mellon 2009
[Paasivaara2008] Distributed Agile Development: Using scrum in a Large project
[PMBOK2008] PMBOK Guide 4th Edition , The Project Management Institute, 2008
[Schwaber2002] Schwaber, K. and Beedle, M., Agile Software Development with SCRUM ,
Prentice-Hall, 2002
[Schwaber2004] Agile Project Management with Scrum, by Ken Schwaber, Microsoft Press,
2004
[Standish2009] The software development project success -rates The Standish Group 2009
[Stephens2003] Extreme Programming Refactored: The Case Against XP, Matt Stephens and
Doug Rosenberg, Apress, 2003
[Wall2007] Case Study: Accelerating Process Improvement by integrating TSP and

CMMI, Daniel Wall, James McHale, Marsha Pomeriy-Huff, 2007, Technical
report SEI
[Watts2001] Watts Humphrey, Comments on eXtreme Programming, eXtreme

Programming Pros and Cons: What Questions Remain?, IEEE Computer
Society Dynabook,2001
[Watts2002] Winning with Software An executive summary, Watts S. Humphrey,

Addison-Wesley, 2002
[Young2008 ] How we did adapt agile processes tou our distributed development?, Cynick
Young, Hiroki tereshima, Agile 2008 Conference
6 Mapa conceptual

Combinação de modelos ágeis e não ágeis em desenvolvimento de software

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Combinação de modelos ágeis e não ágeis em desenvolvimento de software

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Integrao de modelos de desenvolvimento de

Orientador: Joo Carlos Pascoal de Faria (Doutor)

Pedro Miguel Ribeiro Veloso Gomes

Aprovado em provas pblicas pelo Jri:

Presidente: Ana Cristina Ramada Paiva Pimenta (Professor Auxiliar)

A gesto de um projecto de desenvolvimento de software implica a utilizao de prticas

Os dados de mercado mostram que continuamos a ter uma percentagem elevada de

A engenharia de software recente quando comparada com outras engenharias e tem

Mais recentemente emergiram uma srie de metodologias de desenvolvimento de software

Esta tese pretende trazer um maior esclarecimento sobre os mtodos de desenvolvimento

The management of a software development project implies professional practices that

Software Engineering is recent, compared to other engineering disciplines, and it has

Um agradecimento para o Jim Over do Software Engineering Institute (SEI), cujas

BACKLOG Termo utilizado nos mtodos geis que designa um conjunto de

BURNDOWN CHART Grfico que foca no esforo a realizar num projecto

CMMI Capability Maturity Model Integration

CMMI-ACQ CMMI para aquisies de software

CMMI-DEV CMMI para desenvolvimento de software

CMMI-SERV CMMI para servios de software

EARNED VALUE Mtrica de gesto de projectos que foca no trabalho realizado

ESI European Software Institute

PAIR Programao de software executada por dois programadores no

REFACTORING Redesenho de software

RELEASE Resultado produzido que marca o final de uma iterao ou sprint

RUP Rational Unified Process

SCRUM Metodologia gil de desenvolvimento de software focada na gesto

SEI Software Engineerig Institute

TSP/PSP Team Software Process / Personal Software Process

USER STORIES Requisitos escritos de uma forma funcional simplificada em forma de

XP Extreme Programming - Metodologia gil de desenvolvimento de

Este trabalho realizado no mbito do Mestrado Integrado em Engenharia Informtica e

Continuous attention to technical excellence and good design enhances agility. 2

Boehm utiliza a metfora do macaco e do elefante para ilustrar a diferena entre os

Figura 1 - Combinando prticas geis e no geis

O desenvolvimento de software apresenta-se como uma tarefa essencial no mundo actual,

Figura 2 - Projectos de desenvolvimento de Software

Tanto as comunidades de profissionais geis e menos geis parecem ser pouco

Aps uma experincia de gesto de dezenas de projectos de desenvolvimento de software,

relao entre os actores envolvidos, maturidade e s caractersticas intrnsecas de cada

1.2 Motivao e objectivos

Este trabalho deve conseguir responder s seguintes questes:

Para este objectivo foi efectuado um levantamento sobre os modelos de desenvolvimento

Foram tambm analisados os principais esforos da comunidade cientfica e empresarial,

Baseada na informao recolhida proposto um mtodo que permite definir, de acordo

1.3 Estrutura da dissertao

Para alm da introduo, esta dissertao contm mais 4 captulos.

No captulo Gesto do desenvolvimento de software, descrito o estado da arte

No captulo Mtodo de seleco de modelos de desenvolvimento de software

No captulo Concluses e trabalho futuro, so apresentadas as concluses do trabalho e

Neste captulo so percorridas as maiores tendncias metodolgicas inerentes ao

Em primeiro lugar ser focada a crescente utilizao de software no mundo actual e a

De seguida so analisadas as principais correntes associadas gesto de projectos de

Tabela 1- Percentagem de funes realizadas por software nos avies militares 4

Apesar da importncia crescente do software nas organizaes espantoso verificar os

Tabela 2 - Sucesso nos Projectos de Software 5

Aproximadamente 22% dos projectos de software em 2008 foram cancelados

Estes nmeros, caso no sejam suficientemente esclarecedores, representam milhares de

O nmero de projectos desafiados, que no cumpriram com o mbito, custo ou prazo

Figura 3 - Dimenses de gesto de organizaes 6

A existncia de processos promove uma cultura de confiana na organizao, atravs da

Figura 4 - CMMI - Framework de modelos