Roteiro de Redução de Tempo

ANDR LUIZ DIAS RIBEIRO
UM ROTEIRO PARA A REDUO DE TEMPO NO

DESENVOLVIMENTO DE PROJETOS DE SOFTWARE
SO PAULO
2006
UM ROTEIRO PARA A REDUO DO TEMPO NO

Dissertao apresentada Escola

Politcnica da Universidade de So
Paulo para a obteno do ttulo de
Mestre em Engenharia.
rea de Concentrao:
Sistemas Digitais
Orientador:
Prof. Dr. Reginaldo Arakaki
SO PAULO
2006
UM ROTEIRO PARA A REDUO DO TEMPO NO

Dissertao apresentada Escola

Politcnica da Universidade de So
Paulo para a obteno do ttulo de
Mestre em Engenharia.
rea de Concentrao:
Sistemas Digitais
Orientador:
Prof. Dr. Reginaldo Arakaki
SO PAULO
2006
FICHA CATALOGRFICA
Ribeiro,
Ribeiro,
Andre
Andre
LuizLuiz
DiasDias
Um Um
roteiro
roteiro
parapara
a reduo
a reduo
de tempo
de tempo
no desenvolvimento
no desenvolvimento
de de
projetos
projetos
de software
de software
/ A.L.D.
/ A.L.D.
Ribeiro.
Ribeiro.
-- So
-- So
Paulo,
Paulo,
2006.
2006.
p. 124.
p.
Dissertao
Dissertao
(Mestrado)
(Mestrado)
- Escola
- Escola
Politcnica
Politcnica
da Universidade
da Universidade
de So
de So
Paulo.
Paulo.
Departamento
Departamento
de Engenharia
de Engenharia
de Computao
de Computao
e e
Sistemas
Sistemas
Digitais.
Digitais.
1.Engenharia
1.Engenharia
de software
de software
2.Desenvolvimento
2.Desenvolvimento
de software
de software
I.Universidade
I.Universidade
de So
de So
Paulo.
Paulo.
Escola
Escola
Politcnica.
Politcnica.
Departamento
Departamento
de Engenharia
de Engenharia
de Computao
de Computao
e Sistemas
e Sistemas
Digitais
Digitais
II.t. II.t.
AGRADECIMENTOS
Agradeo a Deus pela vida e sade em todas as minhas realizaes.
Aos meus pais e irmos pela base de conhecimento, perseverana e dignidade na

realizao de meus objetivos.
Ao amigo e orientador Reginaldo Arakaki pelo incentivo, apoio e diretrizes essenciais

para esta realizao.
A todos que, direta ou indiretamente, colaboraram na execuo deste trabalho, em

especial a amiga Cristina Coelho de Abreu Pinna e ao amigo Renato Manzan pelas
contribuies, revises e indicaes.
minha querida esposa Patrcia Salles Souza Ribeiro e s minhas filhas Andreza e
Natlia pelo companheirismo, compreenso e constante incentivo durante toda esta
etapa de nossas vidas.
RESUMO
A realizao de projetos dentro do prazo estabelecido um fator comum em
diversas reas de produo como a engenharia civil, de aviao, qumica,
transportes, indstria em geral, entre outras.
No entanto, na engenharia de software, a questo do tempo na construo de um
produto um desafio de processo a ser superado em cada novo projeto. O
cumprimento de prazos no desenvolvimento de software to crtico que o prprio
controle de atrasos no ciclo de produo um fator a ser considerado na anlise de
reduo do tempo de desenvolvimento.
A complexidade do ambiente de software, a competitividade de mercado, as
mudanas de requisitos constantes durante o projeto e o tempo disponvel cada vez
mais restrito, aumentam as chances de insucesso quando analisado o indicador de
tempo na produo de software.
O objetivo deste trabalho reunir e organizar as prticas e tcnicas de engenharia
de software em um roteiro que permita a reduo do tempo no desenvolvimento do
software. Neste roteiro, descrita a utilizao organizada e planejada das prticas
de engenharia de software que auxiliam no planejamento, na criao da arquitetura
de soluo, na definio da infra-estrutura tcnica para reutilizao e a utilizao da
engenharia simultnea, visando proporcionar ganhos reais no tempo de produo do
software e no aumento da produtividade.
Palavras-Chaves: Engenharia de Software, Reduo de Tempo, Arquitetura de

Software, Gerenciamento de Projetos.
ABSTRACT
The completion of software project within schedule is a common goal in several
industries like building engineering, aviation, chemical, transport, wares and so on.
However, in software engineering, the schedule is a process challenge from the
beginning of each new project. The time is so critical that the delay control is an
analysis point for cycle time reduction in software development.
The complex environment, the pressure to reduce time-to-market, frequent
requirements changes during the project life-cycle, increase the failure chance of
software projects when we analyze the time indicator in the software development
process.
The dissertation goal is to meet and to organize of software engineering practices
and techniques in an organized roadmap aiming cycle time reduction in software
development. In this roadmap, the practices are organized to help software planning,
solution architecture, component based development definition, to promote reuse
and concurrent engineering with purpose to reduce cycle time software development
and improve productivity.
Keywords: Software Engineering, Cycle Time Reduction, Software Architecture,

Project Management.
LISTA DE FIGURAS
FIGURA 1.1 REPRESENTAO GRFICA DA ORGANIZAO DO TRABALHO .........................19
FIGURA 2.1 GRUPO DE PROCESSOS DE PLANEJAMENTO DO PMBOK (PMI, 2004) ......... 25
FIGURA 2.2 INTERAES ENTRE OS PROCESSOS DE CONTROLE DO PMBOK
(PMI, 2004)...................................................................................................26
FIGURA 2.3 ATIVIDADES DE PLANEJAMENTO E CONTROLE DE PROJETO
(KERZNER, 2003) ..........................................................................................28
FIGURA 2.4 MODELO CASCATA .........................................................................................30
FIGURA 2.5 MODELO PROTOTIPAO EVOLUTIVA (MCCONNELL, 1996) ..........................31
FIGURA 2.6 MODELO ESPIRAL DE BOEHM (PRESSMAN, 2005) ......................................... 31
FIGURA 2.7 MODELO ITERATIVO (PRESSMAN, 2005) ........................................................33
FIGURA 3.1 PAPEL DA ARQUITETURA DE SOFTWARE (GARLAN, 2000) .............................37
FIGURA 3.2 ATIVIDADES DO PROJETO DE ARQUITETURA (HOFMEISTER ET AL., 2005)...... 39
FIGURA 3.3 DESENVOLVIMENTO TIMEBOX (MCCONNELL, 1996) ...................................... 42
FIGURA 3.4 CICLO DE PROTOTIPAO ADAPTADO (LUQI, 1989) ...................................... 44
FIGURA 3.5 REPRESENTAO DE UM PARTICIONAMENTO ..................................................45
FIGURA 3.6 DESENVOLVIMENTO BASEADO EM COMPONENTES (PRESSMAN, 2005) ......... 47
FIGURA 3.7 OBJETIVOS DA ENGENHARIA SIMULTNEA (DWIVEDI ET AL., 1990)................53
FIGURA 4.1 FATORES DE REDUO DE TEMPO (BLACKBURN; SCUDDER;
W ASSENHOVE, 2000) ....................................................................................59
FIGURA 4.2 ALOCAO DE TEMPO POR FASE (BLACKBURN; SCUDDER;
W ASSENHOVE, 2000) ....................................................................................60
FIGURA 5.1 PRTICAS DE DESENVOLVIMENTO EM ENGENHARIA DE SOFTWARE
(MCT,2002) ..................................................................................................65
FIGURA 5.2 PRTICAS DE GESTO DE PROJETOS EM ENGENHARIA DE SOFTWARE
(MCT, 2002) .................................................................................................66
FIGURA 5.3 UTILIZAO DAS PRTICAS DE ENGENHARIA DE SOFTWARE DO ROTEIRO
PROPOSTO .....................................................................................................70
FIGURA 6.1 MAPEAMENTO DOS CONCEITOS QUE IMPACTAM NA REDUO DE TEMPO........ 77
FIGURA 6.2 MAPEAMENTO DOS ELEMENTOS QUE COMPEM O ROTEIRO PROPOSTO ....... 79
FIGURA 6.3 FLUXO DE ATIVIDADES DO ROTEIRO ............................................................... 87
LISTA DE TABELAS
TABELA 2.1 PARMETROS DE CAPACIDADE DOS CICLOS DE VIDA ADAPTADO
(MCCONNELL, 1996) .....................................................................................33
TABELA 3.1 COMPARAO DAS ESTRATGIAS DE REUSO (RAVICHANDRAN E
ROTHENBERGER, 2003).................................................................................50
TABELA 3.2 ELEMENTOS CHAVES DA ENGENHARIA SIMULTNEA ADAPTADO
(KARANDIKAR ET AL, 1993) ............................................................................ 53
TABELA 4.1 OBJETIVOS PARA REDUO DO CICLO DE DESENVOLVIMENTO
(COLLIER; COLLOFELLO, 1995). ....................................................................58
TABELA 5.1 PRTICAS ENGENHARIA DE SOFTWARE SEPIN (MCT, 2002).................64
TABELA 5.2 PERFIL DE QUALIDADE DAS EMPRESAS PARTICIPANTES DA ENQUETE ............ 69
TABELA 5.3 PRTICAS DE GERENCIAMENTO DE PROJETOS ..............................................69
TABELA 5.4 MODELOS DE CICLOS DE VIDA UTILIZADOS ....................................................70
TABELA 5.5 NVEL DE NO APLICAO DAS PRTICAS DE ENGENHARIA DE SOFTWARE ...71
TABELA 5.6 RESULTADO DA APLICAO DA PRTICA DE PROTOTIPAO ..........................71
TABELA 5.7 RESULTADO DA APLICAO DAS PRTICAS DE COMPONENTIZAO E
REUSO ........................................................................................................... 72
TABELA 5.8 RESULTADO DA APLICAO DA PRTICA DE ENGENHARIA SIMULTNEA ......... 72
TABELA 6.1 QUADRO COMPARATIVO ENTRE AS ABORDAGENS DE REDUO DE TEMPO ...75
TABELA 6.2 COMPARATIVO ENTRE OS OBJETIVOS DAS ABORDAGENS DE REDUO
DE TEMPO ...................................................................................................... 76
TABELA 6.3 TCNICAS E PRTICAS QUE CONTRIBUEM PARA A REDUO DE TEMPO ........ 76
TABELA 6.4 MAPEAMENTO DAS PRTICAS E TCNICAS COM OS OBJETIVOS DE
REDUO DE TEMPO......................................................................................78
TABELA 6.5 PONTOS FORTES E PONTOS FRACOS NO USO DA ENGENHARIA
SIMULTNEA...................................................................................................85
TABELA 6.6 PRODUTOS RESULTANTES DA APLICAO DO ROTEIRO .................................99
TABELA 7.1 RESULTADOS OBTIDOS COM A APLICAO DO ROTEIRO NO PROJETO 1 ...... 104
TABELA 7.2 RESULTADOS OBTIDOS COM A APLICAO DO ROTEIRO NO PROJETO 2 ...... 106
TABELA 7.3 AES CORRETIVAS PARA TRATAR AS DIFICULDADES ENCONTRADAS
COM A EQUIPE DE PROJETO ......................................................................... 109
TABELA 7.4 AES CORRETIVAS PARA TRATAR AS DIFICULDADES ENCONTRADAS
COM O CLIENTE ............................................................................................ 110
SUMRIO
1 INTRODUO ...............................................................................................................13
Objetivo do Captulo ....................................................................................................... 13
1.1. O Problema do Tempo no Desenvolvimento de Software ..............................13
1.2. Motivao ..................................................................................................................15
1.3. Justificativa do Trabalho........................................................................................16
1.4. Objetivos do Trabalho ............................................................................................18
1.5. Organizao do Trabalho .......................................................................................18
1.6. Notaes e Convenes Utilizadas...................................................................... 20
2 O PLANEJAMENTO DE PROJETOS DE SOFTWARE............................................ 21
2.1. A Importncia do Planejamento de Projetos......................................................21
2.2. Monitoramento e Controle do Projeto .................................................................25
2.3. Planejamento do Ciclo de Vida para Desenvolvimento do Software............ 29
2.4. Concluses do Captulo .........................................................................................34
3 CONCEITOS DAS TCNICAS E PRTICAS DE ENGENHARIA DE
SOFTWARE ...................................................................................................................35
3.1. A Arquitetura de Software......................................................................................36
3.2. Desenvolvimento Timebox ....................................................................................41
3.3. Prototipao do Sistema ........................................................................................43
3.4. Particionamento do Software................................................................................44
3.5. Desenvolvimento Baseado em Componentes e Reutilizao ........................45
3.6. Engenharia Simultnea...........................................................................................51
4 ABORDAGENS PARA A REDUO DE TEMPO NO DESENVOLVIMENTO

SOFTWARE ...................................................................................................................55
4.1. Principais Iniciativas para a Reduo do Ciclo de Desenvolvimento de
Software ............................................................................................................................55
5 AVALIAES SOBRE A UTILIZAO DAS PRTICAS E TCNICAS DE
ENGENHARIA DE SOFTWARE NO BRASIL ............................................................... 63
5.1. Pesquisa sobre Qualidade e Produtividade no Setor de Software Brasileiro
............................................................................................................................................. 63
5.2. Enquete para Verificao da Utilizao das Prticas de Engenharia de
Software ............................................................................................................................66
6 O ROTEIRO PARA REDUO DE TEMPO NO DESENVOLVIMENTO DE
SOFTWARE.......................................................................................................................74
6.1. Definio da Estrutura do Roteiro para a Reduo de Tempo.......................74
6.2. Os Elementos do Roteiro para Reduo de Tempo no Desenvolvimento de
Software ............................................................................................................................79
6.3. Fluxo de Atividades para a Aplicao do Roteiro para Reduo do Tempo
de Desenvolvimento de Software ................................................................................86
6.4. Concluses do Captulo ....................................................................................... 100
7 APLICAO DO ROTEIRO EM PROJETOS DE SOFTWARE............................. 101
Objetivo do Captulo ..................................................................................................... 101
7.1. Critrios de Escolha do Projeto.......................................................................... 101
7.2. Caractersticas dos Projetos e Condies de Aplicao .............................. 101
7.3. Resultados da Aplicao do Roteiro nos Projetos......................................... 103
7.4. Dificuldades Encontradas na Aplicao do Roteiro....................................... 107
7.5. Concluses do Captulo ....................................................................................... 110
8 CONSIDERAES FINAIS........................................................................................ 111

Objetivo do Captulo ..................................................................................................... 111
8.1. Resumo das Contribuies do Trabalho .......................................................... 111
8.2. Concluses do Trabalho ...................................................................................... 113
8.3. Trabalhos Futuros ................................................................................................. 114
REFERNCIAS ............................................................................................................... 116
ANEXO 1 - QUESTIONRIO APLICADO NA ENQUETE ......................................... 121
13
___________________________________________________________________
1 INTRODUO
Objetivo do Captulo
O objetivo deste captulo apresentar os motivos que levaram ao desenvolvimento

deste trabalho, destacando sua relevncia e objetivos. Tambm apresentada a
metodologia utilizada e a estruturao da dissertao.
1.1. O Problema do Tempo no Desenvolvimento de Software
Com o avano da tecnologia e com o aumento da competitividade no mercado, os

clientes esto se tornando cada vez mais exigentes em relao ao aumento da
qualidade do software e reduo do tempo de desenvolvimento.
Alm da exigncia do cliente e da demanda do mercado, a adequao s diretrizes
e normas governamentais que alteram os procedimentos e regras de mercado e que
necessitam de solues rpidas e dentro do prazo definido mais um fator relevante
a ser considerado na anlise do tempo de produo de software.
Diversas pesquisas realizadas em mbito internacional mostram que mais da
metade dos projetos de software resultaram em insucesso, apresentando problemas
em relao ao escopo, prazo, custo e a qualidade. Em pesquisa realizada pelo
Standish Group (2004), a questo do tempo foi classificada como um dos cinco
maiores fatores de insucesso dos projetos, sendo responsvel por dez por cento dos
problemas no universo pesquisado. Essa proporo estvel no decorrer do tempo.
Algumas dificuldades apontadas por McConnell (1996) como causas de insucesso
no processo de desenvolvimento de software ainda persistem nos dias atuais. Os
estudos recentes do Standish Group (2004) mostram que a maioria das empresas
de
desenvolvimento
de
software
continuam
enfrentando
problemas
na
implementao de solues que eliminem ou minimizem seus efeitos na produo

de software. Entre estas dificuldades destacam-se as seguintes:
14
1) Falta de motivao da equipe;

2) Planejamento deficiente;
3) Abandono do planejamento original em funo da presso do tempo;
4) Erro nas estimativas de durao das atividades;
5) Caractersticas necessrias ao projeto excedidas;
6) Falha no contrato comercial.
A alternativa mais utilizada pelas empresas para eliminar os efeitos destas

dificuldades a aplicao de normas e modelos de qualidade de software que
descrevem diretrizes, processos e guias de avaliao, visando a aplicao de
tcnicas e prticas de engenharia para a obteno de melhoria em seus processos.
As principais caractersticas e objetivos de algumas dessas normas e modelos so
descritas a seguir.
A ISO IEC 12207 uma norma que tem como objetivo descrever os processos
necessrios ao ciclo de vida de desenvolvimento de software, bem como aumentar o
controle e permitir melhorias no ciclo de produo. constituda por trs processos
principais: os processos fundamentais que descrevem a execuo do processo de
desenvolvimento, os processos de apoio que descrevem os procedimentos para a
melhoria da qualidade do produto e os processos organizacionais que descrevem os
procedimentos de gerenciamento e melhoria do processo de desenvolvimento.
A Norma NBR 13596 (ISO IEC 9126) Tecnologia da Informao - Caractersticas e
Mtricas de Qualidade de Software descreve os aspectos de qualidade de
software referentes
funcionalidade,
confiabilidade,
usabilidade,
eficincia,
manuteno e portabilidade na viso do usurio sobre a avaliao da qualidade do

produto. Essa norma deve ser aplicada em conjunto com a Norma ISO IEC 14598
que um guia que orienta o planejamento e execuo do processo de avaliao da
qualidade e tm como objetivo principal fornecer resultados de qualidade dos
produtos desenvolvidos sob a tica de aceitao pelos envolvidos.
O modelo de software CMMI (Capability Maturity Model Integration), desenvolvido
pelo Software Engineering Institute (SEI/CMU), um modelo de referncia para
melhoria da capacidade de processo das empresas abordando vrias disciplinas que
permitem a melhoria na qualidade do produto, aumento da produtividade, maior
controle sobre o prazo e oramento e aumento da satisfao do cliente.
15
Embora estes trabalhos forneam procedimentos e processos que permitam

melhorias no desenvolvimento de software, os resultados apresentados pelo
mercado de produo de software mostram que muitas das recomendaes no so
aplicadas de maneira adequada e que a maioria dos problemas encontrados nos
projetos esto de alguma forma relacionados presso que o fator tempo impe aos
projetos. Como resultados destas dificuldades tm-se, ao final do projeto, o prazo
comprometido, custos excedidos, baixa qualidade e confiabilidade do produto e a
insatisfao do cliente.
Baseado nessas informaes possvel concluir que se torna necessrio organizar
e aplicar as tcnicas de engenharia de software de forma conjunta e iterativa,
visando reduzir o ciclo de vida de desenvolvimento do produto para atender o
requisito de tempo sem afetar os demais requisitos do projeto.
1.2. Motivao
A realizao de projetos dentro do prazo estabelecido um fator comum em

diversas reas de produo como a engenharia civil, de aviao, qumica,
transportes, indstria em geral, entre outras.
No entanto, na engenharia de software, a questo do tempo de construo de um
produto um desafio de processo a ser superado em cada novo projeto. O
cumprimento de prazos no desenvolvimento de software to crtico que, alm do
objetivo de execuo do projeto dentro do prazo, o prprio controle de atrasos no
ciclo de produo um fator a ser considerado na anlise de reduo do tempo de
desenvolvimento. A complexidade do ambiente de software, a competitividade de
mercado, as mudanas de requisitos constantes durante o projeto e o tempo
disponvel cada vez mais restrito aumentam as chances de insucesso quando
analisado o indicador de tempo na produo de software.
A agilidade e rapidez com que os ambientes de produo de software evoluem
atualmente tornam o fator de reduo do tempo no ciclo de vida do desenvolvimento
um diferencial para as empresas de desenvolvimento de sistemas.
Outro fator relevante para o desenvolvimento de software que, embora as prticas
e tcnicas de engenharia de software sejam amplamente divulgadas e de
16
conhecimento da maioria das empresas de desenvolvimento, estas no utilizam ou

utilizam-nas de forma isolada no obtendo os benefcios que estas poderiam
proporcionar durante a construo dos sistemas. Algumas causas relacionadas a
este cenrio podem ser descritas atravs dos seguintes itens (Ribeiro; Arakaki,
2005):
1) Falta de investimentos em tecnologia;
2) Treinamento deficiente;
3) Descrena na efetividade da utilizao das tcnicas;
4) Falta de domnio tcnico das equipes de projeto;
5) Aplicao inadequada das prticas e tcnicas;
6) Falta de recursos financeiros.
A motivao deste trabalho mostrar que as tcnicas de engenharia de software

utilizadas em conjunto, de forma organizada e interdependente permitem a reduo
do tempo de desenvolvimento, proporcionando ganhos reais de produtividade na
execuo dos projetos, ajudando as empresas atingirem o prazo estabelecido.
1.3. Justificativa do Trabalho
O aumento da produtividade e a reduo do tempo de desenvolvimento de software

so os principais objetivos das empresas responsveis pela construo de
aplicaes (Clincy,2003). Estes objetivos visam reduzir os custos, melhorar os
servios prestados aos clientes e obter vantagens competitivas no mercado de
produo de software (Wetherbe; Frolick, 2000).
Analisando o estado da arte sobre a reduo de tempo de desenvolvimento
encontra-se dois modelos cujos esforos so relevantes at os dias atuais: o
Desenvolvimento Rpido de Aplicao (RAD - Rapid Application Development)
proposto por Martin em 1991 e o Desenvolvimento Rpido Evolutivo (Rapid
Evolutionary Development) proposto por Arthur em 1992.
O RAD (Rapid Application Development) possui cinco pontos focais: equipes
reduzidas, prototipao evolutiva, uso de ferramentas CASE, Joint Application
Design (JAD) e rgidos limites de tempo no desenvolvimento de software (timebox).
17
Este trabalho muito significante para a rea por servir de base para outros esforos
sobre a reduo de tempo de desenvolvimento.
O Desenvolvimento Rpido Evolutivo (Rapid Evolutionary Development) baseado
no desenvolvimento evolutivo tradicional aliado ao forte uso da prototipao, o que
significa interao com o cliente e administrao das alteraes de requisitos. Os
benefcios deste modelo so: a reduo dos riscos e a produo de resultados
tangveis em tempo reduzido.
Outros trabalhos significantes nesse tema tratam alguns aspectos importantes como
a diminuio dos canais de comunicao atravs de equipes pequenas (at 15
pessoas), a reduo do nvel de comunicao formal no projeto e a produo da
documentao mnima necessria para o projeto como fatores que auxiliam na
reduo do tempo de desenvolvimento do software (Clyncy, 2003).
Collier e Collofello (1995) descrevem que a questo de reduo de tempo est
relacionada s caractersticas ambientais e do produto a ser construdo. As
caractersticas ambientais incluem o modelo de processo, a disponibilidade de
recursos,
mtodos,
procedimentos
as
prticas
utilizadas
durante
desenvolvimento do software. As caractersticas do produto esto relacionadas ao

grau de complexidade, a independncia entre os subsistemas e o tamanho do
software a ser construdo.
Em pesquisa realizada entre 1996 e 1999 com empresas de desenvolvimento de
software nos Estados Unidos, Europa e Japo, Blackburn, Scudder e Wassenhove
(2000) identificaram algumas tcnicas e prticas de engenharia que auxiliam na
reduo de tempo de desenvolvimento. Entres estas, se destacam a engenharia
simultnea, o desenvolvimento baseado em componentes, a reutilizao e a
prototipao como os mais efetivos nos ganhos de tempo na produo de software.
Segundo Howard (2002), existem muitas discusses sobre os efeitos e resultados
dessas abordagens, desde a efetividade dos modelos em projetos maiores,
questes entre a incompatibilidade de qualidade com desenvolvimento rpido at a
questo de manuteno dos custos dos projetos. Nessas vertentes, h aqueles que
utilizam e acreditam na materializao dos resultados tangveis dos modelos de
reduo de tempo e aqueles que permanecem relutantes em adot-los por questes
de averso ao risco ou alterao da zona de conforto na qual se encontram.
18
Sobre esse ambiente e abordagens citadas para reduo de tempo no

desenvolvimento de software foram mapeados e organizados os conceitos deste
trabalho.
1.4. Objetivos do Trabalho
O principal objetivo deste trabalho elaborar um roteiro que rena e organize as

prticas e tcnicas de engenharia de software para permitir a reduo de tempo no
desenvolvimento de software.
No roteiro deste trabalho descrita a utilizao organizada e planejada das prticas
de engenharia de software que auxiliam no planejamento, na definio da
arquitetura do software, no estabelecimento do desenvolvimento baseado em
componentes e reutilizao e na engenharia simultnea que, aplicadas de forma
conjunta, proporcionam ganhos reais na reduo do tempo de produo de software
e o aumento da produtividade.
1.5. Organizao do Trabalho
Este trabalho foi organizado em sete captulos conforme representao esquemtica

da Figura 1.1.
No Captulo 1 so apresentados os motivos que levaram o desenvolvimento deste

trabalho, sua justificativa, seus objetivos, a estruturao do trabalho e as
convenes utilizadas.
No Captulo 2 descrita a importncia do planejamento no desenvolvimento de
software, o processo de monitoramento e controle durante a execuo do projeto,
bem como uma definio dos ciclos de desenvolvimento que deve ser definido no
incio do projeto.
No Captulo 3 concentram-se a fundamentao terica dos conceitos das tcnicas e
prticas relacionadas ao roteiro como a arquitetura de software, a prototipao
evolutiva, o desenvolvimento timebox, particionamento do sistema, componentizao
e engenharia simultnea que so partes integrantes do roteiro proposto.
19
No Captulo 4 so apresentadas as principais iniciativas existentes sobre a reduo

de tempo no desenvolvimento de software, seus conceitos, caractersticas e focos
principais.
O Captulo 5 apresenta um panorama nacional sobre as prticas de Engenharia de
Software adotadas pelas empresas no Brasil realizadas pela Secretaria Especial de
Informtica MCT (2002) e o resultado de uma enquete realizada pelo autor para
verificao do grau de utilizao das prticas de engenharia de software propostas
pelo roteiro no mercado brasileiro.
No Captulo 6 apresentado o roteiro para reduo de tempo no desenvolvimento
de software descrevendo sua estruturao, os elementos que o compe e as
atividades a serem realizadas na sua aplicao, seus produtos, aspectos de
utilizao e suas restries.
No Captulo 7 so descritos os resultados da aplicao do roteiro em projetos de
software vivenciados pelo autor e as principais dificuldades observadas durante a
sua utilizao.
No Captulo 8 so apresentadas as consideraes finais com a descrio das
concluses, as contribuies do trabalho e os trabalhos futuros que podem ser
desenvolvidos a partir deste estudo.
Roteiro para Reduo

de Tempo no
Desenvolvimento de
Software
Captulo 1
Introduo
Captulo 2
O Planejamento de
Projetos de Software
Captulo 3
Conceitos das
Tcnicas e Prticas
de Engenharia de
Software
Captulo 5
Captulo 4
As Abordagens para
Avaliaes sobre a
a Reduo de Tempo
Utilizao de Prticas
no Desenvolvimento
e Tcnicas de
de Software
Engenharia
Captulo 6
O Roteiro para
Reduo de Tempo
de Desenvolvimento
de Software
Captulo 7
Aplicao do Roteiro
em Projetos de
Software
Figura 1.1 Representao grfica da organizao do trabalho
Captulo 8
Consideraes Finais
20
1.6. Notaes e Convenes Utilizadas
As tabelas e figuras que no possuem referncia foram desenvolvidas pelo autor

utilizando diagramas de classes e de atividades da linguagem UML Unified
Modeling Language (OMG, 2006) ou representaes clssicas de fluxograma.
21
___________________________________________________________________
2 O PLANEJAMENTO DE PROJETOS DE
SOFTWARE
Objetivo do Captulo
O objetivo deste captulo descrever a importncia do planejamento no

desenvolvimento de software, apresentar os conceitos do processo de controle
durante a execuo do projeto e mostrar os conceitos dos diversos ciclos de vida
que podem ser aplicados na produo de software, visando criar subsdios para a
definio do ciclo de vida adequado a cada projeto.
Este captulo foi desenvolvido com base no estudo dos seguintes trabalhos:
Boehm; Turner(2004), McConnell(1996), Bersoff; Davis(1991), Howard(2002),
Pinna(2004), Kirk(2004), Krutchen(2000), Pressman(2005), PMI(2004), Kerzner
(2003).
2.1. A Importncia do Planejamento de Projetos
O planejamento uma das principais atividades a ser realizada na concepo de um

sistema de software (Kerzner, 2003), pois com base na anlise dos requisitos do
produto a ser construdo, nas suas premissas e restries que o desenvolvimento do
software adequado ao tempo disponvel e ao custo estabelecido. Alm disso, na
fase de planejamento que novas dependncias, requisitos, riscos e oportunidades
so identificados e resolvidos pela equipe do projeto.
A inexistncia ou a falta de um planejamento adequado podem trazer diversas
conseqncias a um projeto, contribuindo para o insucesso do mesmo. Segundo
Kerzner (2003), cinco itens se destacam como resultado dessa deficincia:
1. Incio do projeto sem a definio dos requisitos;

2. Entusiasmo excessivo da equipe do projeto;
22
3. Decepo com os resultados no alcanados;

4. Procura por culpados pelo fracasso e punio de inocentes;
5. Premiao e reconhecimento de no participantes no projeto.
Para evitar estas conseqncias, deve ser elaborado um planejamento adequado

realidade de cada projeto, com a definio clara dos requisitos do projeto, onde a
mensurao inicial de esforo e de prazo o ponto de partida para viabilizar a
execuo do projeto dentro do tempo disponvel.
O planejamento pode ser elaborado de forma detalhada, total ou parcial, de acordo
com as caractersticas do projeto a ser desenvolvido e do mtodo de gesto de
projetos que se utiliza (Kirk, 2004). No entanto, segundo o PMBOK (PMI, 2004), o
planejamento deve ser divulgado a todos os envolvidos e formalmente aprovado
pelo cliente.
Para atender essas necessidades podem ser realizadas reunies direcionadas com
a presena de todos os envolvidos com o objetivo de discutir e aprovar todas as
questes relevantes, permitindo o alinhamento antecipado das expectativas sobre o
produto e a melhoria dos canais de comunicao (Boehm; Turner, 2004).
Na impossibilidade de elaborar o planejamento conjunto, deve-se promover reunies
de kickoff atravs da qual todos os envolvidos so informados do plano elaborado
pela equipe do projeto, criando condies de avaliao e discusso sobre o
planejamento apresentado. Esse plano deve ser ajustado durante a execuo do
projeto sob as mesmas condies de aprovao de todos os envolvidos..
Segundo Kerzner (2003), o planejamento do projeto deve ser sistemtico, flexvel,
disciplinado por revises e controles e capaz de aceitar e incorporar mudanas
durante a realizao do projeto.
Independente da abordagem utilizada pelas equipes de projeto, uma referncia
comum para a elaborao do planejamento de projetos o PMBOK, Guide of the
Project Management Body of Knowledge (PMI, 2004). Este guia especifica os grupos
de processos de iniciao, planejamento, execuo, controle e fechamento para a
realizao de um projeto.
23
A seguir so descritos resumidamente os processos de planejamento de acordo com

o PMBOK (PMI, 2004).
1 Planejamento do Escopo: Descreve como o escopo do projeto deve ser
definido, verificado e controlado;
2 Definio do Escopo: Fornece o detalhamento do escopo que serve de
baseline de requisitos;
3 Elaborao da EAP (Estrutura Analtica do Projeto): a estrutura que define
os principais produtos de trabalho do projeto. Serve como base para a execuo dos
processos seguintes;
4 Definio das Atividades: Identifica as principais atividades necessrias para a
construo dos produtos de trabalho;
5 Seqenciamento das Atividades: Identifica as dependncias entre as
atividades definidas;
6 - Estimativa de Recursos das atividades: Estima a quantidade e o tipo de
recursos necessrios para a realizao de cada atividade;
7 Estimativa de Durao das Atividades: Estima o tempo necessrio para
realizao de cada atividade;
8 Desenvolvimento do Cronograma: Analisa os itens de 4 a 7 para criao do
cronograma do projeto;
9 Estimativa de Custos: Desenvolve os custos aproximados para a realizao
das atividades;
10 Elaborao do Oramento: Agrega as estimativas individuais de custo das
atividades para definir o custo total do projeto;
11 Planejamento da Qualidade: Identifica quais so os padres de qualidades e
como so atendidos;
12
Planejamento
de
Recursos
Humanos:
Identifica
os
papis
responsabilidades da equipe do projeto;

13 Planejamento das Comunicaes: Determina como sero as comunicaes
entre todos os envolvidos no projeto;
24
14 Planejamento de Riscos: Define como os riscos sero gerenciados durante o

projeto;
15 Identificao de Riscos: Determinam quais so os riscos que afetam o projeto
e documenta suas caractersticas;
16 Anlise Qualitativa de Riscos: Realiza a priorizao dos riscos e avalia sua
probabilidade de ocorrer e seu impacto sobre o projeto;
17 Anlise Quantitativa de Riscos: Analisa numericamente os efeitos dos riscos
sobre o projeto;
18 Elaborao do Plano de Respostas aos Riscos: Desenvolve as aes para
reduzir, eliminar ou transferir os riscos do projeto;
19 Elaborao do Plano de Terceirizao: Determina o qu, quando e como
adquirir recursos externos necessrios ao projeto;
20 Plano de Contratao: Define e documenta os produtos que sero contratados
e identifica os potenciais fornecedores.
Os processos mostrados na Figura 2.1 podem ser executados tantas vezes quantas
forem necessrias, dentro de cada fase do projeto (PMI, 2004), pois so interativos e
devem ser realizados durante todo o ciclo de vida do projeto. Entretanto, os
processos so referncias para a elaborao do planejamento, no sendo
necessria a execuo de todos os processos para a concluso do planejamento.
Segundo Kerzner (2003), um planejamento sistemtico e aderente realidade de
cada projeto permite s organizaes atingirem os objetivos e contribui para:
Eliminar e reduzir as incertezas;
Obter melhor entendimento dos objetivos;
Prover a base para o monitoramento e controle do trabalho;
Melhorar a eficincia da operao.
25
Embora o planejamento seja essencial para o projeto, ele no deve se tornar uma
atividade burocrtica que demande esforo considervel e consumo de tempo
excessivo da equipe do projeto durante sua execuo. (Boehm; Turner, 2004).
Figura 2.1 Grupo de Processos de Planejamento do PMBOK (PMI, 2004)
2.2. Monitoramento e Controle do Projeto
Embora o planejamento seja importante para a realizao de um projeto, o controle

e o monitoramento das atividades que permite ao gerente de projeto observar e
controlar sua realizao de acordo com o plano de desenvolvimento.
26
Segundo o PMBOK (2004), o grupo de processos de monitoramento e controle tem

como objetivos identificar problemas, permitir a tomada de aes corretivas durante
a execuo do projeto, controlar as mudanas e recomendar aes preventivas.
Figura 2.2 Interaes entre os Processos de Controle do PMBOK (PMI, 2004)
As atividades de monitorao e controle realizadas durante o desenvolvimento do

projeto consistem em:
- Acompanhar o progresso das tarefas;
- Comparar os resultados atuais com os previstos no planejamento;
- Analisar o impacto das alteraes que ocorrem durante o projeto;
- Realizar os ajustes necessrios para manter as metas do projeto.
27
Para a realizao dessas atividades, os seguintes processos so previstos pelo

PMBOK (2004) para o controle e monitoramento do projeto e esto ilustrados na
Figura 2.2.
1 Monitorar e Controlar o Projeto: o processo responsvel por coletar, medir e

disseminar informaes sobre o desempenho e avaliar as tendncias para efetuar as
melhorias no processo;
2 Controle Integrado das Mudanas: Controla os fatores que criam mudanas,
determina se ocorreu uma mudana e gerencia as mudanas aprovadas. realizado
durante todo o projeto;
3 Verificar o Escopo: Formaliza a aceitao das entregas de produtos realizadas;
4 Controlar o Escopo: Controla as mudanas feitas no escopo do projeto;
5 Controlar o Cronograma: Controla as alteraes realizadas que impactam no
cronograma do projeto;
6 Controlar os Custos: Controla e monitora as variaes no oramento do
projeto;
7 Realizar o Controle da Qualidade: Monitora as entregas para determinar se
esto de acordo com os padres de qualidade;
8 Gerenciar a Equipe do Projeto: Acompanha o desempenho dos membros da
equipe, fornece feedback e coordena mudanas para melhorar o desempenho do
projeto;
9 Elaborar Relatrios de Desempenho: Coleta e distribui informaes sobre o
andamento do projeto;
10 Gerenciar os Stakeholders: Gerencia a comunicao a fim de satisfazer os
requisitos e resolver problemas com os stakeholders;
11 Monitorar e Controlar os Riscos: Acompanha os riscos, identifica novos
riscos, executa o plano de respostas aos riscos e avalia sua eficincia durante todo o
projeto;
12 Administrar Contratos: Gerencia o contrato quando o projeto envolve relao
entre comprador e fornecedor.
28
Embora existam doze processos de controle, para cada projeto devem ser definidos
quais desses processos devem ser aplicados no ciclo de desenvolvimento do
software, considerando suas caractersticas especficas e o ambiente da
organizao que o desenvolve.
Um processo de planejamento e controle resumido apresentado por Kerzner
(2003) para se estabelecer um nvel adequado de controle sobre o projeto, onde as
seguintes atividades mnimas devem ser realizadas durante sua execuo e so
ilustradas na Figura 2.3.
As caixas superiores representam as atividades de planejamento e as caixas
inferiores identificam as atividades de controle.
Figura 2.3 Atividades de Planejamento e Controle de Projeto (Kerzner, 2003)
A partir da definio das metas e objetivos so definidos os pacotes de trabalho da

Estrutura Analtica do Projeto (EAP) e o ciclo de desenvolvimento a ser utilizado
durante a execuo do projeto. As atividades so determinadas para a realizao de
cada pacote de trabalho e o cronograma e o oramento so elaborados para servir
de base para o controle do progresso do projeto.
O acompanhamento do projeto realizado atravs do monitoramento das atividades
em relao ao cumprimento dos prazos, gastos planejados versus o realizado e a
29
qualidade dos produtos a serem entregues ao cliente. Os relatrios de desempenho

so utilizados para verificar a aderncia ao planejamento original e corrigir possveis
desvios, gerando replanejamentos que se tornam a nova referncia para o controle e
monitoramento do projeto.
Este processo representa um fluxo contnuo e repetitivo de atividades que devem
ocorrer durante o ciclo de vida de um projeto at a sua efetiva concluso.
2.3. Planejamento do Ciclo de Vida para Desenvolvimento do Software
A definio do ciclo de desenvolvimento de um projeto faz parte da fase de

planejamento e sua definio, como qualquer ao tomada nesta fase, pode
determinar o grau de sucesso ou insucesso do projeto.
A definio do modelo de processo do ciclo de vida orienta o processo de
desenvolvimento do software e determinar os critrios de avaliao da evoluo do
projeto. A escolha apropriada do modelo pode aumentar a velocidade do
desenvolvimento, melhorar a qualidade, facilitar o acompanhamento e controle,
minimizar os riscos ou melhorar a relao com o cliente. Enquanto a escolha errada
do modelo pode gerar baixa produtividade, retrabalho, insatisfao do cliente e a
realizao de atividades desnecessrias (McConnell, 1996).
Existem muitos modelos de ciclos de vida para escolha e aplicao pelas equipes de
desenvolvimento de software. Entretanto, para este trabalho so apresentadas as
principais caractersticas dos quatro modelos mais utilizados atualmente: o modelo
cascata, a prototipao evolutiva, o modelo espiral e o modelo iterativo.
2.3.1) Modelo Cascata

o modelo mais antigo e o mais conhecido atualmente, sendo utilizado como
referncia para o desenvolvimento dos demais modelos. denominado como
modelo clssico.
O modelo consiste na execuo seqencial das atividades de especificarprojetar-construir (Howard, 2002), onde ao final de cada fase so realizadas
avaliaes para determinar se o projeto passa para a prxima fase ou
30
permanece na fase atual. Outra caracterstica que os documentos

produzidos em cada fase so subsdios para a fase subseqente. Esse
modelo apresentado na Figura 2.4.
O modelo cascata adequado para projetos com baixo nvel de alterao de
requisitos e que no necessitam de resultados visveis em curto prazo, pois
os produtos so gerados ao final do modelo (McConnell, 1996).
Anlise
Projeto
Implementao
Testes
Figura 2.4 Modelo Cascata
2.3.2) Prototipao Evolutiva

um modelo baseado no desenvolvimento de um prottipo como fonte para a
identificao das necessidades do cliente e validao dos requisitos nas fases
iniciais de desenvolvimento do software. Os prottipos so construdos e
apresentados aos clientes para avaliao e continuam neste ciclo at a
aprovao final pelo cliente, quando o produto final construdo.
Tornou-se muito popular por reduzir os custos e os riscos nas fases iniciais do
projeto (Bersoff; Davis, 1991) e atualmente, usado em conjunto com outros
modelos auxiliando tambm, na reduo do tempo de desenvolvimento do
software.
A Figura 2.5 apresenta graficamente o modelo de prototipao evolutiva.
31
Requisitos
Iniciais
Elaborao do
Prottipo Inicial
Refinamento do
Prottipo at a
aceitao
Implementao e
testes
Figura 2.5 Modelo Prototipao Evolutiva (McConnell, 1996)
Este modelo apresenta ainda como vantagens a melhoria da comunicao

entre o cliente e a equipe do projeto, flexibilidade de adequao em cenrios
de constantes alteraes de requisitos e proporcionar ao cliente uma viso
funcional do sistema a baixo custo.
2.3.3) Modelo Espiral

O modelo espiral um modelo orientado a riscos desenvolvido por Boehm em
1988, incorporando as melhores caractersticas do modelo clssico e da
prototipao, dividindo-se em quatro atividades conforme ilustrado na Figura
2.6.
Figura 2.6 Modelo Espiral de Boehm (Pressman, 2005)
32
A atividade de planejamento consiste na determinao dos objetivos,

alternativas e restries para a realizao do projeto. A identificao e anlise
dos riscos so realizadas a seguir visando determinar e tratar os possveis
problemas nas fases iniciais do desenvolvimento e servirem como referncia
para monitorao durante todo o ciclo de vida. Aps estas atividades inicia-se
o desenvolvimento de uma verso do produto que, aps a concluso,
submetido avaliao do cliente.
A cada iterao ao redor da espiral uma verso mais completa do software
construda
(Pinna,
2004).
Os
requisitos
vo
sendo
detalhados
implementados a cada iterao e, ao final de cada iterao so realizadas

anlises de tomada de deciso sobre o andamento do projeto.
A principal vantagem deste modelo o carter evolutivo e os resultados
tangveis que so alcanados medida que o projeto evolui.
2.3.4) Modelo Iterativo

o modelo desenvolvido a partir do modelo espiral, caracterizado pelo
desenvolvimento em vrios ciclos, entregas constantes de produtos e pela
anlise de riscos, permitindo a identificao de problemas nas fases iniciais
do projeto e a tomada de aes visando corrigir o curso do desenvolvimento
no tempo adequado e de maneira eficiente (Krutchen, 2000).
No modelo iterativo, a primeira iterao rene os requisitos bsicos do
produto que so validados pelo cliente. Um plano desenvolvido para a
prxima interao visando satisfazer as necessidades do cliente. Esse
processo repetido aps cada iterao at que o produto completo seja
produzido. Diferente dos outros modelos, o modelo iterativo objetiva a
elaborao de um produto operacional a cada iterao (Pressman, 2005).
O modelo iterativo permite flexibilidade em ambientes de projeto onde existem
indefinies de requisitos inicias e a determinao do foco nos pontos mais
crticos do projeto.
Outras vantagens deste modelo so a deteco o mais cedo possvel de
inconsistncias entre os requisitos e a implementao, a produo de
33
resultados tangveis a cada iterao e a identificao de melhorias contnuas

no processo (Krutchen, 2000).
As fases do modelo iterativo so apresentadas na Figura 2.7.
Iterao 1
Anlise
Projeto
Iterao 2
Primeira
Entrega
Codificao
Teste
Projeto
Codificao
Anlise
Iterao 3
Anlise
Projeto
Teste
Segunda
Entrega
Codificao
Teste
Terceira
Entrega
Tempo decorrido
Figura 2.7 Modelo Iterativo (Pressman, 2005)
A definio do modelo adequado para cada projeto depende de vrios fatores como
as caractersticas do projeto, as necessidades do cliente e o tempo disponvel para
realizao do trabalho.
A partir dos conceitos apresentados sobre os modelos, alguns parmetros podem
ser avaliados contra as foras e fraquezas de cada modelo, conforme demonstrado
na Tabela 2.1 adaptada da proposta de McConnell (1996).
Tabela 2.1 Parmetros de Capacidade dos Ciclos de Vida adaptado (McConnell, 1996)
Capacidade do Modelo
Cascata
Prototipao
Espiral
Iterativo
Requisitos Instveis
Fraco
timo
timo
timo
Arquitetura Indefinida
Fraco
Razovel
timo
timo
Gerenciamento Riscos
Fraco
Razovel
timo
timo
Flexibilidade de Adequao s
Fraco
timo
Razovel
timo
Fraco
timo
timo
timo
Requer Baixo Gerenciamento
Razovel
Razovel
timo
Razovel
Nvel de Planejamento
Razovel
Razovel
timo
timo
timo
timo
Razovel
Razovel
mudanas
Visibilidade de Progresso
Velocidade de Desenvolvimento
34
2.4. Concluses do Captulo
Este captulo apresentou as principais caractersticas dos quatro modelos de ciclo de

vida mais utilizados no desenvolvimento de software atualmente, os conceitos
relacionados ao planejamento, controle e monitoramento de um projeto de software.
A escolha do modelo de ciclo de vida para o desenvolvimento de software deve
estar adequado s caractersticas de cada projeto, pois a elaborao do
planejamento segue as premissas e restries que cada modelo possui e orienta as
atividades de controle que so aplicadas durante a execuo do projeto.
Para a realizao das atividades da fase de planejamento devem ser considerados
os aspectos de tempo disponvel e o nvel de detalhe esperado, pois o excesso de
esforo nestas atividades pode gerar atraso no projeto e a preparao de
cronogramas que no refletem as condies reais de desenvolvimento.
Embora o planejamento seja essencial, o acompanhamento e a monitorao do
projeto exercem um papel fundamental no sucesso do projeto, visto que atravs
dessas atividades que os desvios so identificados e corrigidos, permitindo a
adaptao s novas condies do ambiente ou a situaes no previstas no plano
original do projeto.
35
___________________________________________________________________
3 CONCEITOS DAS TCNICAS E PRTICAS DE ENGENHARIA

DE SOFTWARE
Objetivo do Captulo
O objetivo deste captulo descrever os conceitos que sustentam as prticas e

tcnicas de Engenharia de Software que so aplicadas no roteiro, fornecendo
subsdios tericos sobre a utilizao de cada uma delas.
Neste captulo so apresentadas as principais caractersticas e conceitos da
arquitetura e sua importncia na reduo de tempo no desenvolvimento de software.
Tambm so apresentados os fundamentos da prtica do desenvolvimento timebox
que busca manter o foco nas principais caractersticas do produto e na
sensibilizao da restrio de tempo equipe do projeto.
So descritos os conceitos da prototipao evolutiva como ferramenta para reduo
de riscos e obteno de um melhor entendimento dos requisitos, bem como as
caractersticas do particionamento para a reduo da complexidade e como
elemento facilitador do processo de controle do projeto.
Tambm so conceituadas as tcnicas do desenvolvimento baseado em
componentes e da reutilizao, seus efeitos na reduo da complexidade, nos
ganhos de produtividade e no aumento do paralelismo das tarefas de
implementao.
Finalmente, so apresentados os conceitos da engenharia simultnea e sua
significativa contribuio na reduo do tempo de desenvolvimento.
McConnell(1996), Pinna (2004), Krutchen (2000), Luqi(1989), Boehm (1994), Garlan
(2000), Ran (2001), You-Sheng; Yu-Yun (2003), Kent; Howse; Lauder (2000), Park
(1999), Dwiwedi et al. (1990), BlackBurn; Scudder; Wassenhove (2000), Smith
(1997), Amundsen; Hutchison (1990), Brookes; Backhouse (1997), Karandikar et al
(1993), IEEE 1471-2000, Subramanian e Chung (2005), Sadou, Tamzalit e Oussalah
(2005), Hofmeister et al. (2005), Vitharana (2003), Bass; Clements; Kazman (2003),
Ravichandran e Rothenberger (2003).
36
3.1. A Arquitetura de Software
3.1.1 Conceitos de Arquitetura de Software
A definio da arquitetura um passo chave para os efetivos ganhos em tempo de

desenvolvimento e de produtividade na construo de software. Sua abrangncia
no est restrita a estrutura de implementao do sistema, mas tambm s questes
de usabilidade, funcionalidade, desempenho, confiabilidade, reuso e restries
econmicas e tecnolgicas (Krutchen, 2000).
De acordo com o padro IEEE 1471-2000, a arquitetura definida como uma prtica
para a organizao fundamental do sistema, a incorporao de seus componentes,
seus relacionamentos com outros componentes e o ambiente, os princpios que
orientam o design e a evoluo do projeto com o objetivo de identificar seus
elementos bsicos para o entendimento e o controle do sistema.
Para Subramanian e Chung (2005), a arquitetura de software desenvolvida para
satisfazer os requisitos funcionais de um problema e constituda de componentes
que renem os requisitos funcionais, as conexes entre estes componentes, suas
restries de uso para atender as necessidades do negcio e estabelece padres e
estilos para a construo do software.
Para Garlan (2000), com o aumento do tamanho e da complexidade dos sistemas de
software modernos a arquitetura exerce um papel importante no desenvolvimento de
software, atuando como um elo de ligao entre os requisitos e o cdigo, conforme
ilustrado na Figura 3.1.
O papel da arquitetura neste elo facilitar o entendimento do sistema atravs de
diferentes nveis de abstrao, permitir a definio da estratgia de desenvolvimento
e viabilizar as especificaes de componentes para aumentar o grau de reuso na
construo do software (Garlan, 2000).
Segundo Ran (2001) arquitetura de software um conjunto de conceitos e decises
de projeto sobre a estrutura do software a ser construdo que deve ser realizado nas
fases iniciais do desenvolvimento para permitir a efetiva satisfao dos requisitos
funcionais e sistmicos.
37
Requisitos
Arquitetura
Software
Cdigo
Figura 3.1 Papel da Arquitetura de Software (Garlan, 2000)
Para Sadou, Tamzalit e Oussalah (2005) a arquitetura de software oferece um alto

nvel de abstrao para a descrio dos sistemas, permitindo a equipe do projeto
direcionar esforos na estrutura global do sistema.
Essas definies mostram a importncia da arquitetura na construo dos sistemas
modernos, onde passa a ser parte do ciclo de vida do software e torna-se a base
fundamental para viabilizar a utilizao do desenvolvimento baseado em
componentes, o aumento da reutilizao e a maximizao das atividades
concorrentes para se obter ganhos reais de tempo no desenvolvimento do software.
Porm, para se obter os benefcios da arquitetura na construo de sistemas, alguns
fatores crticos de sucesso devem ser observados segundo Boehm (1994):
1)
Domnio
tcnico
do
negcio
maturidade
do
processo
de
desenvolvimento de software e conhecimento do ambiente;

2) Desenvolvimento de componentes reutilizveis orientao do
desenvolvimento baseado em componentes com a preocupao de reuso;
3) Treinamento das equipes de projeto Experincia e conhecimento da
arquitetura pela equipe do projeto;
4) Reduo de riscos uso do processo de desenvolvimento e provas de
conceito;
5) Benefcios na reduo do ciclo de vida experincia da equipe,
componentes, grau de reuso e atividades concorrentes.
38
Embora esses fatores crticos tenham sido citados por Boehm em 1994, os seus
conceitos permanecem atuais e aplicveis por se tratarem de fundamentos para a
verificao dos ganhos obtidos com a aplicao da arquitetura de software, visando
atingir os seguintes objetivos:
Estabelecer uma base tcnica para a fase de projeto, permitindo o

entendimento da estrutura do software a ser desenvolvido;
Criar condies bsicas para a implementao de componentes e sua

efetiva reutilizao;
Simplificar as tarefas de codificao;
Maximizar as atividades concorrentes.
3.1.2 Desenvolvimento do Projeto de Arquitetura de Software
Existem diversos mtodos para a implementao da prtica de arquitetura de

software no desenvolvimento de sistemas de informao. Esses mtodos descrevem
tcnicas, processos e melhores prticas para facilitar o entendimento e o
desenvolvimento do projeto de arquitetura de um sistema.
Hofmeister et al. (2005), desenvolveu um estudo para estabelecer um modelo geral
de projeto de arquitetura de software baseado na anlise comparativa entre diversos
mtodos, onde foram analisadas as foras e fraquezas de cada um para definir o
conjunto de atividades que devem ser realizadas durante a definio da arquitetura.
Os seguintes mtodos de projeto de arquitetura de software foram analisados nesse
estudo: Attribute-Driven Design (ADD) desenvolvido pela SEI (Software
Engineering Institute), Siemens 4 Views (S4V) desenvolvido pela Siemens
Corporate Research, Viso 4+1 RUP desenvolvido pela Rational Software,
Bussiness Architecture Process and Organization (BAPO) desenvolvido pela
Philips Research e Architectural Separation of Concerns (ASC) desenvolvido pela
Nokia.
O detalhamento desses mtodos no est no escopo deste trabalho, sendo o foco
apresentar o modelo para o projeto de arquitetura definido pelo estudo de
Hofmeister et al. (2005).
39
Como resultado dessa anlise comparativa, foi desenvolvido um modelo com as

atividades essenciais a serem realizadas durante a definio do projeto de
arquitetura.
Baseado no contexto do projeto e nos requisitos no funcionais de interesse da
arquitetura, a anlise arquitetural identifica os problemas que a arquitetura deve
resolver e organiza os requisitos mais significativos para a soluo. A sntese
arquitetural tem por objetivo propor solues alternativas, denominadas arquiteturas
candidatas, que so avaliadas e medidas contra os requisitos, resultando na
arquitetura final da soluo (Hofmeister et al., 2005).
Sntese
Arquitetural
Requisitos Arquiteturais
Solues Arquiteturais
Significantes
Candidatas
Interesses
Arquiteturais
Anlise
Arquitetural
Requisitos Arquiteturais
Significantes
Avaliao
Arquitetural
Arquitetura
Validada
Contexto
Figura 3.2 Atividades do Projeto de Arquitetura (Hofmeister et al., 2005).
A seguir so descritas as principais atividades do modelo apresentado na Figura 3.2.
a) Interesses Arquiteturais:
So os requisitos no funcionais do sistema tais como: desempenho,
confiabilidade, segurana, distribuio e escalabilidade. O grau de variao
desses requisitos direciona e influencia as decises tcnicas que devem ser
observadas durante a anlise arquitetural.
b) Contexto:
Determinam
conjunto
de
requisitos
relativos
ao
ambiente
de
desenvolvimento operacional que podem afetar o sistema. Alm desses,
40
devem ser observados os fatores organizacionais, tecnolgicos e do produto

a fim de identificar suas principais caractersticas.
c) Anlise Arquitetural:
Define o problema que a arquitetura ir resolver, baseado na anlise dos
requisitos arquiteturalmente significantes e do contexto do sistema.
As preocupaes e a anlise detalhada sobre os requisitos de portabilidade,
integrao com outros sistemas, modularidade, flexibilidade, qualidade e
segurana so significativas para a definio da arquitetura.
d) Requisitos Arquiteturalmente Significantes:

A partir do conjunto de requisitos identificados, so escolhidos aqueles que
afetam diretamente a arquitetura. Devem ser observados aqueles que tm
maior impacto nos objetivos de negcio e na decomposio do sistema.
e) Sntese Arquitetural:
Apresenta solues alternativas que refletem as decises sobre a estrutura do
software e o atendimento aos requisitos estabelecidos. Compreende a
identificao de possveis solues, tomada de decises de projeto que
direcionam a avaliao arquitetural.
f) Solues Arquiteturais Candidatas:
So as solues alternativas que devem ser avaliadas atravs de simulaes
dos diversos cenrios ou com o desenvolvimento de prottipos arquiteturais
para prover os fundamentos para a avaliao arquitetural.
g) Avaliao Arquitetural:
Avalia as solues alternativas apresentadas contra os requisitos mais
significativos da arquitetura com o objetivo de definir a que melhor atende s
necessidades do projeto. Os cenrios e os prottipos devem ser refinados
atravs da construo de provas de conceitos que permitam a avaliao dos
resultados das solues.
41
h) Arquitetura Validada:
Consiste
na
escolha
da
arquitetura
consistente
com
os
requisitos
arquiteturalmente significantes e que satisfaa as premissas e restries

estabelecidas para atender s necessidades do projeto.
Em funo da complexidade das tarefas, essas atividades no so executadas

sequencialmente. Elas devem ocorrer de forma progressiva e repetida vezes at que
a arquitetura esteja completa e validada (Hofmeister et al., 2005).
Esse modelo define as atividades fundamentais para a execuo do projeto de
arquitetura durante o ciclo de vida de construo do software, sendo a sua utilizao
adequada de acordo com as caractersticas de cada projeto ou ao mtodo escolhido
para o desenvolvimento da arquitetura do software.
3.2. Desenvolvimento Timebox
O desenvolvimento timebox uma prtica que auxilia a manter o foco nas principais
caractersticas do software, evidenciar o senso de restrio de tempo equipe do
projeto e reduzir o tempo de desenvolvimento do software (McConnell, 1996).
O procedimento central desta prtica enquadrar os requisitos centrais do projeto
ao tempo disponvel, enquanto os demais requisitos so incorporados em outros
timeboxes com menor prioridade. A prioridade destes requisitos definida
conjuntamente pelo cliente e pela equipe do projeto, permitindo a reduo do tempo
de desenvolvimento.
A aplicao dessa prtica requer a utilizao conjunta com a prtica de prototipao,
alm de necessitar do envolvimento significativo do usurio final e de revises
constantes da equipe do projeto. Aps a construo, o sistema avaliado pelo
cliente, podendo ser aceito completamente ou retornar para ajustes
de
funcionalidades ou de qualidade, conforme ilustrado na Figura 3.3.

A aplicao do desenvolvimento timebox facilitada pelo suporte provido pela
arquitetura definida para a construo do software, onde o atendimento aos
requisitos de modularidade e flexibilidade do sistema prov melhores condies de
sua utilizao.
42
Requisitos
Desenvolvimento Timebox
Sistema
Prototipado
Desenvolver o
Prottipo
Revises do
Cliente
Solicitao Alteraes
Sistema Rejeitado
Sistema
Avaliado
Sistema
Aceito
Figura 3.3 Desenvolvimento Timebox (McConnell, 1996)
Embora seja uma prtica da fase de projeto e de construo, a definio dos

timeboxes deve ser parte da fase de planejamento, onde o cliente participa
diretamente da definio e limitao dos principais requisitos que so atendidos
dentro de cada timebox, bem como da validao dos prottipos e das decises
gerenciais.
Segundo McConnell (1996), existem duas recomendaes que devem ser
consideradas na aplicao do desenvolvimento timebox:
1) Cada timebox deve ter durao mxima de 120 dias, pois duraes
maiores podem no ter o senso de urgncia necessrio aplicao desta
tcnica;
2) Envolvimento constante do cliente durante o desenvolvimento do projeto.
As principais condies de sucesso desta prtica que a data final estabelecida
para cada timebox no seja alterada, o cliente esteja de acordo com os requisitos
definidos e a limitao rgida do escopo seja atendida (McConnell,1996). Qualquer
mudana nessas condies deve ser tratada como um novo timebox para no
comprometer os prazos estabelecidos.
43
3.3. Prototipao do Sistema
uma tcnica que permite que os requisitos do sistema sejam mapeados em

interfaces amigveis para o cliente, facilitando o entendimento das necessidades e a
adequao s mudanas (McConnell,1996). Deve ser desenvolvido em parties
conforme a definio dos timeboxes e do particionamento do sistema.
Esta prtica melhora significantemente a visibilidade do progresso das atividades do
projeto junto ao cliente, permite aumentar o nvel de definio dos requisitos e
contribui para a reduo de tempo na construo do software.
Existem duas formas para realizao da prototipao:
a) Prototipao de Interface
b) Prototipao Evolutiva
Na prototipao de interface o objetivo validar os requisitos do sistema junto ao
cliente atravs de telas que demonstrem funcionalmente o software a ser construdo.
As ferramentas utilizadas para a elaborao do prottipo podem ser desde esboos
em papel at o uso de softwares especficos para a criao de interfaces. Ao final do
trabalho o prottipo escrito na linguagem apropriada. Tem como principais
vantagens a rapidez com que produzido e na reduo de riscos.
A prototipao evolutiva segue os mesmos objetivos da prototipao de inteface,
porm diferencia-se pelo fato do cdigo produzido ser aproveitado no cdigo final,
portanto deve-se utilizar a linguagem de desenvolvimento do software e ser
submetido s avaliaes de qualidade quanto a aderncia aos padres de
codificao.
Recomenda-se o uso da prototipao evolutiva quando os requisitos so mais
estveis e nas parties do sistema. Para os sistemas de mdio e grande porte,
ambas as abordagens podem ser utilizadas (McConnell, 1996).
No ciclo apresentado na Figura 3.4, com a determinao da parte do sistema a ser
desenvolvida, inicia-se a construo do prottipo que discutido em interaes
constantes de validao com o usurio, onde so capturadas as modificaes
necessrias at se obter o entendimento comum entre os envolvidos. Com o aceite
44
do usurio a construo iniciada e o ciclo se repete at a concluso de todo o

projeto.
Deterrminar os
requisitos
Requisitos
No
Validao
usurio
Construir o
Prottipo
Prottipo
Apresentar o
Prottipo
Sim
Construir a
partio do
sistema
Sistema
Pronto
Figura 3.4 Ciclo de Prototipao Adaptado (Luqi, 1989)
Os potenciais benefcios da prototipao dependem da habilidade de se realizar

modificaes no prottipo com esforo bem menor que o requerido para modificar o
software pronto (Luqi, 1989).
3.4. Particionamento do Software
O desenvolvimento de um projeto em uma nica partio complexo, de difcil

controle gerencial e os resultados produzidos so tardios para o cliente, gerando
aumento de expectativas e de conflitos entre os envolvidos no projeto.
O particionamento do projeto visa subdividir o produto a ser construdo em unidades
menores e mais gerenciveis permitindo o controle e avaliao do progresso das
atividades que geram os produtos. Uma vez definido o escopo do trabalho, deve-se
subdividir o trabalho em unidades que orientam a estratgia de desenvolvimento e
os produtos a serem entregues ao cliente.
45
Para definir os particionamentos, a equipe do projeto deve agrupar as

funcionalidades similares do sistema de forma que cada partio seja um executvel
independente, onde o cliente tenha condies de validar o atendimento dos
requisitos do projeto.
No h um tamanho definido para cada partio, cabendo a equipe do projeto, em
conjunto com o cliente, dividir o sistema de forma a atender s principais regras de
negcio e a ordem que so entregues para avaliao. Cada partio pode ser
dividida em sub-parties com o objetivo de simplificar a tarefa de desenvolvimento
e proporcionar resultados visveis mais rapidamente. A Figura 3.5 exemplifica o
particionamento de um projeto.
Projeto
X
Partio 1
Partio 2
Sub-Partio
2.1
Partio "n"
Sub-Partio
2.2
Figura 3.5 Representao de um particionamento
Embora no reduza diretamente o tempo de desenvolvimento do software, esta

prtica permite a reduo substancial dos riscos atravs da simplificao das
tarefas, melhoria do controle gerencial e a produo de resultados visveis mais
rpidos para o cliente, aumentando as chances de sucesso do projeto.
3.5. Desenvolvimento Baseado em Componentes e Reutilizao
3.5.1 Desenvolvimento Baseado em Componentes

Com o aumento da complexidade do ambiente e das caractersticas do
software, as preocupaes das equipes de projeto no so apenas com os
46
requisitos funcionais, mas envolve tambm abordagens em relao ao

desempenho, concorrncia, facilidade de manuteno e reuso (You-Sheng;
Yu-Yun, 2003).
Suportado pela arquitetura definida para a construo do software, o
desenvolvimento de software baseado em componentes tem por objetivo
definir as especificaes de interfaces genricas de cada elemento para que
os mesmos possam ser utilizados no projeto sem a necessidade de
conhecimento especializado. Estes componentes so caixas pretas que
encapsulam as regras de negcio e a complexidade da tecnologia envolvida.
Para Pressman (2005), um componente definido com uma parte no-trivial
de um sistema, praticamente independente e substituvel, que exerce um
papel claro no contexto de uma arquitetura definida.
Segundo Vitharana (2003), um componente definido como um pedao de
software executvel com uma interface publicada.
O modelo de processo de software baseado em componentes (CBSE
Component-Based Software Engineering) definido por Bass; Clements e
Kazman (2003) como um processo que d nfase a construo de sistemas
usando componentes de software reusveis, onde a implementao d lugar
integrao como foco no processo de desenvolvimento.
No CBSE a identificao dos componentes comea a ser definida ainda na
fase de entendimento dos requisitos, com foco nas necessidades de negcio,
e estende-se at a fase de projeto onde so identificados os componentes
relacionados arquitetura, linguagem de programao utilizada, interao
com sistemas externos e na comunicao com a infra-estrutura de hardware e
software do ambiente. Cada componente um software independente que
prov o acesso s suas funcionalidades atravs das interfaces definidas.
Todos os componentes identificados e criados so armazenados em um
repositrio central para compartilhamento entre a equipe do projeto. Esse
repositrio central tambm chamado de biblioteca de componentes.
O modelo CBSE sugere a incorporao do desenvolvimento de componentes
dentro do ciclo de vida do projeto, realizando as atividades descritas na Figura
3.6, durante a fase de construo do software.
47
Identificar os
componentes
necessrios
Construir o
software
Procurar
Componentes na
biblioteca
Armazenar novos
Componentes na
biblioteca
Extrair os
componentes
disponveis
Construir novos
componentes
Figura 3.6 Desenvolvimento Baseado em Componentes (Pressman, 2005)
A partir da identificao dos componentes necessrios ao projeto, a primeira

atividade da equipe verificar sua existncia no repositrio. Se estiver
disponvel, o componente extrado para utilizao. Caso contrrio, o
componente desenvolvido ou adquirido no mercado para atender s
necessidades do projeto. Aps isso, so armazenados na biblioteca para
utilizao posterior em outros projetos.
O desenvolvimento baseado em componentes apresenta vrias vantagens se
comparados com o desenvolvimento tradicional (Kent; Howse; Lauder,2000):
1) Reduo dos custos de manuteno Uma vez construdos e

testados os componentes tornam-se estveis e o esforo de
manuteno menor;
2) Aumento da produtividade atravs da reutilizao Atravs dos
componentes o esforo de implementao subseqente reduzido
com o reaproveitamento das funcionalidades e a eliminao de
codificao adicional;
48
3) Isolamento da interface com sistemas externos Os componentes

so caixas pretas para o programador, isolando a necessidade de
conhecimento sobre todas as interfaces do sistema;
4) Maior portabilidade do sistema De acordo com a tecnologia
utilizada, a construo de componentes permite maior flexibilidade de
utilizao nas diversas plataformas.
Embora as vantagens do desenvolvimento baseado em componentes sejam
muitas, existem aspectos que necessitam ser observados durante a utilizao
dessa prtica na construo de software.
Vitharana (2003) aponta os seguintes riscos e desafios para a implementao
do desenvolvimento baseado em componentes:
1) Evoluo dos requisitos As evolues dos requisitos devem ser

observadas e documentadas para evitar que os componentes fiquem
obsoletos;
2) Alto investimento inicial A adoo do CBSE envolve gastos iniciais
para organizao da estrutura, no desenvolvimento dos componentes e
no estabelecimento do processo;
3) Versionamento A publicao das atualizaes de verses dos
componentes exige coordenao para manter a sincronizao dos
componentes;
4) Testes dos componentes O processo de testes mais complexo
por no se conhecer exatamente como os componentes so utilizados
nos diversos sistemas.
O desenvolvimento baseado em componentes a base para a prtica da

reutilizao e permite ganhos considerveis de produtividade e de reduo de
tempo no desenvolvimento de software. Segundo Pressman (2005) os
componentes podem reduzir em at 70% (setenta por cento) o tempo de
desenvolvimento de um software e aumentar em at 55% (cinqenta e cinco
por cento) a produtividade da equipe de projeto.
49
3.5.2 Reutilizao de Componentes
Reutilizar o software existente aumenta a produtividade no desenvolvimento

de software (Park, 1999) e uma conseqncia do desenvolvimento baseado
em componentes.
Para Ravichandran e Rothenberger (2003), o reuso de software em vrios
projetos uma importante estratgia para melhorar a eficincia no
desenvolvimento de software e aumentar sua qualidade.
Existem trs estratgias para reutilizao de componentes que podem ser
aplicadas ao desenvolvimento de software, cuja anlise comparativa
apresentada na Tabela 3.1:
1. Reuso Caixa-Branca: Nessa abordagem, os desenvolvedores podem
modificar o cdigo dos componentes existentes para adequ-los s
suas necessidades e aos novos requisitos.
2. Reuso Caixa-Preta, desenvolvido pela prpria empresa: Nessa
estratgia o reuso est na recuperao de componentes desenvolvidos
internamente pelas equipes de projeto, no permitindo a modificao
do cdigo pelos desenvolvedores. Os componentes devem ser
utilizados conforme suas especificaes de interface.
3. Reuso Caixa-Preta, adquirido no mercado: Essa abordagem permite
aos
desenvolvedores
procurar
os
componentes
no
mercado,
aumentando as chances de identificar quele que melhor se encaixa as

necessidades do projeto.
A escolha de qual estratgia deve ser adotada pela organizao deve ser
avaliada contra os custos de aquisio do componente no mercado, os custos
de customizao dos componentes existentes e da taxa de reuso alcanada
com cada estratgia (Ravichandran;Rothenberger, 2003).
Uma possvel seqncia para a escolha da estratgia de reuso, apresentada
por Ravichandran e Rothenberger (2003), pode ser descrita da seguinte
maneira:
50
a) Adotar o reuso caixa-preta interno, se os componentes existentes

no repositrio atendem s necessidades;
b) Se no existe componentes caixa-preta para atender ao projeto e o
custo de customizao reduzido, adotar a estratgia de reuso
caixa-branca;
c) Se o custo de customizao elevado e no existe componente
caixa-preta no repositrio, deve-se buscar um componente no
mercado ou desenvolver um novo componente. Nesse caso, a
deciso deve ser avaliada em relao ao custo e tempo para
desenvolvimento ou obteno do componente.
Tabela 3.1 Comparao das Estratgias de Reuso (Ravichandran e Rothenberger, 2003)

Item
Caixa-Preta
Caixa-Branca
Interno
Taxa de
reuso
Flexibilidade
Escopo do
reuso
Custo de
Construo
Custo de
Uso
Qualidade
Tempo de
Retorno
Repositrio
Mercado
Alta taxa de reuso pela

capacidade de
modificao dos
componentes existentes.
Alta Flexibilidade.
Provavelmente, menor
taxa de reuso pela
necessidade de encontrar
um componente exato.
Flexibilidade limitada.
Reuso moderado, pela

maior possibilidade de
encontrar um componente
adequado.
Flexibilidade limitada.
Reuso local e restrito ao

grupo da mesma
localizao.
Baixo custo de
construo
Reuso local, mas pode ser

ampliado para uso em
diversos lugares.
Maior custo de construo
para parametrizao das
interfaces.
Baixo custo de busca e de
customizao.
Componentes adquiridos
do mercado. Uso
diversificado.
Maior custo de construo
para parametrizao das
interfaces.
Alto custo de busca e baixo
custo de customizao.
Conhecida pela
organizao.
Retorno somente aps
existir massa crtica no
repositrio.
Alta taxa de reuso para
cobrir o investimento.
Pode no ser conhecida.

Maior risco de uso.
No requer investimento
para construir o repositrio.
Crescimento linear do
tamanho do repositrio.
Controle de verses
importante e mais simples.
Limitada necessidade de
um repositrio local.
Responsabilidade de
verses do vendedor.
Custo moderada de
procura e alto custo de
customizao.
Conhecida pela
organizao.
Retorno somente aps
existir massa crtica no
repositrio.
Taxa de reuso moderada
para cobrir o
investimento.
Crescimento exponencial
do tamanho do
repositrio. Controle de
verses essencial.
Independente da estratgia de reuso utilizada, a definio clara do processo

para criao das bibliotecas, de publicao e recuperao dos componentes
existentes e o treinamento da equipe no processo so fundamentais para a
51
eficincia desta prtica, pois a maior barreira para a reutilizao so as

dificuldades na localizao e uso desses componentes e a cultura dos
desenvolvedores.
Com o aumento do grau de reuso do software, obtm-se ganhos reais no
tempo de desenvolvimento atravs da reduo do esforo de codificao e da
reduo da necessidade de testes sobre o software reutilizado.
3.6. Engenharia Simultnea
O termo engenharia simultnea vem sendo aplicado desde o final dos anos 80 no
processo de desenvolvimento de software, onde o paralelismo das atividades e a
integrao funcional so partes do processo de desenvolvimento. As idias atrs do
conceito da engenharia simultnea so simples, mas produzem resultados
significativos no tempo de produo do software (Smith, 1997) e estabelece
mecanismos de melhoria de desempenho para as empresas (Brookes; BackHouse,
2000).
Segundo Amundsen e Hutchison (1990), engenharia simultnea uma abordagem
sistemtica para criar um produto que considera todos os elementos do ciclo de vida
de desenvolvimento. Engenharia simultnea no a eliminao arbitrria de alguma
fase do ciclo de vida, mas a realizao de atividades em paralelo para a otimizao
do tempo de produo.
Para BlackBurn, Scudder e Wassenhove (2000) a engenharia simultnea o
gerenciamento de tcnicas para reduzir o time-to-market e aumentar a produtividade
no desenvolvimento de um produto, atravs da execuo de tarefas em paralelo por
diferentes grupos e do fluxo controlado de informaes para suportar as equipes de
desenvolvimento.
O suporte e a flexibilidade de desenvolvimento fornecido pela arquitetura e pelo
desenvolvimento baseado em componentes so essenciais para se alcanar um alto
grau de execuo de tarefas concorrentes, atingido atravs da estruturao do
sistema de forma mais independente possvel entre as diversas parties, da diviso
do software em camadas e do aumento do nvel de reutilizao de componentes.
52
A aplicao da engenharia simultnea no desenvolvimento de software consiste em

quatro elementos (Amundsen; Hutchison, 1990):
1) Tarefas em paralelo: o produto dividido em subsistemas que tenham o

mnimo de interao entre si;
2) Compartilhamento de informaes: a comunicao entre os grupos
recebe ateno especial para permitir a troca de informaes e
alinhamento das expectativas;
3) Suporte e confiabilidade: prover a equipe de desenvolvimento condies
de avaliar a qualidade do produto;
4) Equipe de projeto: Gerenciamento colaborativo com os envolvidos no
projeto durante todas as fases do ciclo de vida e dos subsistemas.
Com a utilizao da engenharia simultnea na produo de software pretende-se

atingir os seguintes objetivos representados esquematicamente na Figura 3.7
(Dwivedi et al,1990).
a) Reduo dos custos Distribuir as atividades de forma que possam ser

realizadas no menor tempo possvel;
b) Eliminao de gastos Alocar os recursos com o perfil adequado
necessrio realizao da tarefa;
c) Reduo do tempo de desenvolvimento Com a execuo das
atividades em paralelo possvel reduzir o tempo de desenvolvimento do
software;
d) Aumento da qualidade Realizar as atividades de anlise e projeto antes
da construo do produto para garantir a aderncia aos requisitos do
produto;
e) Melhoria contnua do produto Verificao progressiva da qualidade
dos produtos gerados.
53
Esses objetivos so amplos e ambiciosos. Porm, atravs da realizao desses

objetivos da engenharia simultnea possvel atingir resultados tangveis mais
breves durante o ciclo de vida do projeto (Dwivedi et al., 1990).
Reduo de
custos
Reduo do tempo
de
desenvolvimento
Eliminao de
gastos
Aumento da
qualidade
Melhoria
Contnua
Engenharia
Simultnea
Resultados
Tangveis
Figura 3.7 Objetivos da Engenharia Simultnea (Dwivedi et al., 1990)
A execuo da engenharia simultnea uma tarefa complexa que exige um nvel de

gerenciamento diferenciado,
onde alguns
elementos
chaves
precisam
observados, conforme ilustrado na Tabela 3.2 (Karandikar et al, 1993).

Tabela 3.2 Elementos chaves da Engenharia Simultnea Adaptado (Karandikar et al, 1993)
Elementos Chaves
Foco no Cliente
Requisitos
-
Interao com o cliente

Constante ateno na satisfao do cliente
Definio da metodologia
Identificao e controle do processo
Definio do gerenciamento
Formao da equipe
Treinamento da equipe
Definio de medidas de desempenho
Sistema de Gerenciamento
Gerenciamento de riscos
Mecanismos de produo rpida
Prototipao
Utilizao de ferramentas
Adoo de tcnicas e prticas apropriadas
Habilidade de responder as alteraes
Ateno nos objetivos das tarefas

Mtodos comuns, ferramentas e processo.
Foco no Processo
Estratgia do projeto
Agilidade
Disciplina
ser
54
A aplicao da engenharia simultnea permite o planejamento e a execuo das

atividades do projeto com paralelismo, mas necessita de elevado grau de
gerenciamento das atividades para a minimizao do retrabalho e de melhoria da
comunicao, com o objetivo de desenvolver a cultura de trabalho em grupo nas
pessoas envolvidas no projeto.
Neste captulo foram mostradas as prticas e tcnicas de engenharia de software

utilizadas no roteiro para reduo de tempo no desenvolvimento de software.
Uma vez iniciado o projeto, a preocupao da equipe deve estar em estabelecer o
particionamento adequado do software s necessidades do cliente com o objetivo de
definir claramente a prioridade das partes que devem ser construdas.
O desenvolvimento timebox associado com a protipao evolutiva permite aos
envolvidos no projeto definirem e validarem os requisitos que devem ser atendidos
prioritariamente na partio, delimitando o escopo do projeto para cada timebox
estabelecido e obtendo o compromisso de todos.
A arquitetura de software o fundamento bsico que permite a organizao e
aplicao da prtica do desenvolvimento baseado em componentes e da
reutilizao. Ela deve ser definida e validada o mais breve possvel dentro do ciclo
de vida do projeto.
Para se estabelecer o processo de desenvolvimento baseado em componentes
(CBSE) necessrio que a equipe do projeto esteja consciente dos ganhos de
produtividade que podem ser obtidos e dos benefcios que o reuso proporciona ao
processo de construo do software. Para isso, o processo CBSE deve ser parte do
ciclo de vida do projeto e as regras de utilizao do repositrio de componentes
publicada a todos os envolvidos no projeto.
A aplicao da tcnica de engenharia simultnea resulta em uma diminuio
substancial do tempo de desenvolvimento atravs da execuo das tarefas em
paralelo, proporcionada pela estrutura e organizao estabelecida no planejamento
do projeto, na definio clara do escopo e na arquitetura de software bem definida.
Porm, necessita de elevado grau de controle gerencial e de comunicao entre
todos os envolvidos no projeto.
55
___________________________________________________________________
4 ABORDAGENS PARA A REDUO DE TEMPO NO

DESENVOLVIMENTO DE SOFTWARE
Objetivo do Captulo
O objetivo deste captulo apresentar as principais iniciativas existentes sobre a

reduo de tempo no desenvolvimento de software, seus conceitos, caractersticas e
focos principais.
Os fundamentos e resultados obtidos do estudo dessas abordagens so utilizados
como referncias para a elaborao do roteiro de reduo de tempo no
desenvolvimento de software proposto por este trabalho.
BlackBurn; Scudder; Wassenhove (2000), Collier; Collofello (1995), Clincy (2003) e
Wetherbe; Frolick (2000); Howard (2002).
4.1. Principais Iniciativas para a Reduo do Ciclo de Desenvolvimento de

Software
A indstria de desenvolvimento de software, aps a ateno dispensada aos fatores

de produtividade e de qualidade na produo de software durante os anos 80, iniciou
os anos 90 com o objetivo de reduzir o tempo de desenvolvimento de software
(Collier; Collofello, 1995).
Aumentar a produtividade e reduzir o tempo do ciclo de desenvolvimento de software
so os principais objetivos das organizaes responsveis pela construo de
software na atualidade (Clincy, 2003).
A partir deste objetivo, o foco das pesquisas sobre a reduo do tempo do ciclo de
desenvolvimento nas empresas de tecnologia est na reduo dos custos, na
melhoria dos servios ao cliente e na obteno de vantagens competitivas no
mercado de software (Wetherbe; Frolick, 2000).
56
A primeira iniciativa para reduo de tempo na construo de software foi o

Desenvolvimento Rpido de Aplicao (RAD - Rapid Application Development)
desenvolvido por James Martin em 1991, cujos objetivos principais so entregar os
produtos com maior rapidez e aumentar a qualidade enquanto diminui os custos.
Nesse modelo, o desenvolvimento fortemente baseado no uso de ferramentas
CASE (Computer-Aided Software Engineering) e constitudo de cinco pontos focais:
1. Equipes reduzidas Melhora a comunicao dentro do projeto;

2. Prototipao evolutiva Auxilia na identificao de requisitos na fase de
entendimento do sistema;
3. Uso de ferramentas CASE O apoio de ferramentas CASE aumenta a
produtividade atravs da nfase na automao;
4. Joint Application Design (JAD) Reunies com todos os envolvidos no
projeto com o objetivo de esclarecer e validar os requisitos;
5. Rgidos limites de tempo no desenvolvimento (timebox) Controle do
escopo e limitao dos requisitos atendidos.
Segundo Howard (2002), os benefcios obtidos com a aplicao do RAD so

reconhecidos pela maioria das organizaes. Porm, ainda existem discusses
sobre sua aplicao em projetos de maior porte, efetividade na manuteno da
qualidade e o uso excessivo de ferramentas de automao para aumentar a
produtividade.
No entanto, esse trabalho significante para a rea por servir de base para outros
esforos sobre a reduo de tempo de desenvolvimento (Collier;Collofello, 1995).
O
Desenvolvimento
Rpido
Evolutivo
(Rapid
Evolutionary
Development)
desenvolvido por Arthur (1992) um modelo de ciclo de vida com o objetivo de

reduzir o tempo de desenvolvimento de software.
baseado no desenvolvimento evolutivo tradicional aliado ao forte uso da
prototipao, o que significa maior interao com o cliente e acomodao das
alteraes de requisitos durante as fases iniciais do projeto (Collier; Collofello, 1995).
57
Segundo Arthur (1992), as principais caractersticas desse modelo so:

1. Prototipao Facilita a captura e o entendimento dos requisitos;
2. Uso da Lei de Pareto Chamada regra 80/20. Sugere que 20% dos
produtos possuem 80% do valor esperado. O foco desse modelo
desenvolver os requisitos que se enquadram nos 20% dessa regra;
3. Interao com o cliente Permite a validao constante dos requisitos e
produtos durante o projeto.
A partir dessas caractersticas, o Rapid Evolutionary Development visa reduzir os

riscos, o retrabalho e a complexidade dos produtos e dos processos durante o
desenvolvimento do software.
Segundo Collier e Collofello (1995), a questo de reduo de tempo est
relacionada s caractersticas ambientais e s caractersticas do produto a ser
construdo.
As caractersticas ambientais incluem o modelo de processo, a disponibilidade de
recursos, mtodos, procedimentos e prticas utilizadas durante o desenvolvimento
do software.
As caractersticas do produto esto relacionadas ao grau de complexidade, a
independncia entre os subsistemas e o tamanho do software a ser produzido.
Para cada projeto deve ser realizada a anlise dessas caractersticas identificandose aquelas que podem contribuir para a reduo de tempo das tarefas,
categorizando-as de acordo com o impacto e aplicando-as de forma a obter os
resultados esperados.
Uma vez realizada essa anlise inicial, a avaliao dessas caractersticas deve ser
constante durante o ciclo de desenvolvimento do software, a fim de permitir
correes e melhorias na realizao das tarefas.
A combinao dessas caractersticas ambientais e do produto proporciona a base
para estabelecer um conjunto de objetivos para reduzir o ciclo de desenvolvimento
de software, conforme ilustrado na Tabela 4.1.
58
Uma importante preocupao dessa abordagem no reduzir os requisitos de

qualidade em funo da reduo do tempo de desenvolvimento. A qualidade pode
ser mantida pela reduo do acoplamento entre os mdulos, o aumento da coeso e
reduo da complexidade das tarefas, proporcionando melhorias na capacidade de
manuteno e na confiabilidade do software.
Tabela 4.1 Objetivos para Reduo do Ciclo de Desenvolvimento (Collier; Collofello, 1995).
Caractersticas Ambientais
Caractersticas do produto
Objetivos
Reuso de Software
Desenvolver novos componentes
Maximizao do reuso
para o repositrio
Alteraes de Requisitos
Determinar as interdependncias
Parties independentes
das parties e sua
Reduo da complexidade
complexidade
Gerenciamento de Riscos
Identificar os riscos e determinar
Minimizar a ocorrncia dos
o grau de impacto
riscos
Produtividade Pessoal
Nenhum impacto
Disponibilidade de Recursos
Nenhum impacto
Validao e Verificao
Qualidade
Determinar os efeitos do
Garantia de correo e
retrabalho
completeza
Determinar os efeitos do
Garantia da qualidade
retrabalho
Estratgia de Integrao
Determinar tarefas concorrentes
Baixo acoplamento
Reduzir o caminho crtico
Simplificao das tarefas
Outro estudo relacionado reduo de tempo foi realizado por Blackburn, Scudder e
Wassenhove em um levantamento realizado entre 1996 e 1999, com 145 empresas
de desenvolvimento de software nos Estados Unidos, Europa e Japo, onde foram
identificados onze fatores que auxiliam na reduo do tempo de desenvolvimento de
software, apresentados na Figura 4.1.
Nesse estudo, as empresas foram divididas em dois grupos: um grupo com as
empresas consideradas rpidas (diminuram em mais de 25% o tempo de
desenvolvimento
nos
desenvolvimento normal.
ltimos
cinco
anos)
empresas
com
tempo
de
59
Esses fatores receberam classificao de um a cinco e esto ordenados de acordo

com o grau de importncia atribudo pelas empresas pesquisadas:
1) Equipes treinadas e capacitadas;
2) Melhoria da comunicao entre os membros do projeto;
3) Melhoria das especificaes iniciais do cliente;
4) Melhoria do processo de gesto de projetos;
5) Estratgias de testes adequadas;
6) Engenharia Simultnea;
7) Reuso de cdigo ou mdulos;
8) Reduo do retrabalho;
9) Uso de prototipao;
10) Uso adequado da tecnologia e ferramentas CASE;
11) Particionamento.
Na comparao entre os fatores adotados pelos dois tipos de empresas, os que
mais contriburam para a melhoria do tempo de desenvolvimento so os
relacionados a: equipes treinadas e capacitadas, prototipao e reduo do
retrabalho, sendo responsveis por 35% dessa melhoria.
Fatores de Reduo de Tempo
Eq
Tr
ei
na
C
om
da
un
ic
a
Es
o
pe
c
.In
G
es
ici
ta
al
o
Pr
oj
et
o
En
Te
g
st
Si
e
m
ul
t
ne
a
M
en
R
or
e
Re uso
tra
ba
Pr
lh
ot
Fe
o
ot
rr
ip
am
a
en
o
ta
sC
Pa
r ti
AS
ci
E
on
am
en
to
Grau Importncia
4
3,5
3
2,5
2
1,5
1
0,5
0
Figura 4.1 Fatores de Reduo de Tempo (Blackburn; Scudder; Wassenhove, 2000)
60
Outras observaes sobre o efeito desses fatores sobre a reduo do tempo de

desenvolvimento foram:
A aplicao da engenharia simultnea no ciclo de desenvolvimento melhora a

produtividade das equipes de desenvolvimento e reduz substancialmente o
tempo de desenvolvimento;
Equipes reduzidas tendem a ser mais produtivas e reduzem os problemas de

comunicao;
A utilizao de ferramentas CASE recebeu baixa importncia em termos de

reduo de tempo de desenvolvimento;
A produtividade e de reduo de tempo no so perfeitamente correlatos, pois

possvel
reduzir o tempo de desenvolvimento sem aumentar a
produtividade.
Outra avaliao realizada por este estudo foi verificar o relacionamento entre a
velocidade do desenvolvimento e a alocao do tempo em cada fase do projeto.
O resultado ilustrado no Figura 4.2, onde possvel observar que as empresas
consideradas mais rpidas consumiram mais tempo nas fases iniciais que nas fases
subseqentes, exceto na fase de codificao.
Alocao de Tempo por Fase de Projeto
% Dedicao
30
25
20
15
10
5
Te
st
e/
In
te
g.
C
od
ifi
ca
P
ro
je
to
P
la
ne
ja
m
en
to
R
eq
ui
si
to
s
0
Desenv. Rpido
Desenv. Lento
Figura 4.2 Alocao de Tempo por Fase (Blackburn; Scudder; Wassenhove, 2000)
Esta concluso mostra que para reduzir o tempo no ciclo de desenvolvimento,

necessrio ser mais lento nas fases iniciais para se atingir o objetivo. Para aumentar
a velocidade e produtividade deve-se investir mais tempo em entender as
61
necessidades,
produzir
especificaes
sem
ambigidades
elaborar
um
planejamento adequado ao projeto (Blackburn; Scudder; Wassenhove, 2000).

Segundo Clincy (2003), para reduzir o tempo de desenvolvimento tambm
necessrio reduzir os canais de comunicao com a alocao de equipes pequenas
(at 15 pessoas), diminuir o nvel de comunicao formal dentro do projeto e
produzir a documentao mnima essencial ao desenvolvimento do projeto.
A partir de uma anlise comparativa entre essas abordagens, pode-se observar que
vrios aspectos e prticas de engenharia de software utilizadas so comuns e
apresentam resultados efetivos na reduo do tempo de desenvolvimento de
software. Para os objetivos deste trabalho, os seguintes pontos comuns devem ser
destacados:
1. Equipes Reduzidas: Diminui os canais de comunicao e facilita o

controle da execuo das tarefas;
2. Reduo dos Canais de Comunicao: Reduz os problemas de
comunicao atravs da diminuio do nvel de formalidade e de
documentao do projeto;
3. Interao Constante com o Cliente: Diminui os conflitos com a equipe do
projeto e melhora a validao dos requisitos do software;
4. Prototipao: Facilita a captura e entendimento dos requisitos, reduzindo
o retrabalho e simplificando as tarefas.
Alm desses pontos comuns, as prticas de engenharia de software relacionadas ao

desenvolvimento baseado em componentes (CBSE), ao reuso, engenharia
simultnea e ao desenvolvimento timebox tambm so citadas como relevantes na
reduo do tempo de desenvolvimento, auxiliando no aumento da produtividade, na
reduo da complexidade, na simplificao das tarefas do projeto e na maximizao
das tarefas concorrentes.
62
Neste captulo foram descritas as principais abordagens sobre a reduo do tempo

no desenvolvimento de software, suas caractersticas e prticas utilizadas.
Desde a definio do modelo RAD (Desenvolvimento Rpido de Aplicao), diversos
trabalhos buscam abordar a questo da reduo de tempo na produo de software
seguindo as diretrizes bsicas de aumento da produtividade, reduo do retrabalho,
diminuio da complexidade e simplificao das tarefas. Alm dessas diretrizes, as
abordagens descritas neste captulo mostram que a aplicao da engenharia
simultnea uma prtica que contribui diretamente na reduo do ciclo de
desenvolvimento atravs da maximizao de tarefas concorrentes dentro do
processo de construo do software.
Embora essas prticas sejam eficientes na diminuio do ciclo de produo de
software, a sua utilizao conjunta dentro de um processo bem definido, maximiza
os resultados finais de reduo do tempo de desenvolvimento de software.
A partir dos resultados da anlise dessas abordagens, obtm-se os subsdios
tcnicos para a elaborao do roteiro deste trabalho, permitindo identificar e
selecionar as prticas de engenharia de software que contribuem para a reduo do
tempo e a manuteno dos nveis de qualidade nos projetos.
63
___________________________________________________________________
5 AVALIAES SOBRE A UTILIZAO DAS PRTICAS E

TCNICAS DE ENGENHARIA DE SOFTWARE NO BRASIL
Objetivo do Captulo
O objetivo deste captulo apresentar um panorama nacional sobre a utilizao das

tcnicas e prticas de engenharia de software, atravs dos resultados da pesquisa
realizada pelo Ministrio da Cincia e Tecnologia (MCT) sobre qualidade e
produtividade no setor de software brasileiro em 2001. So apresentados tambm,
os resultados de uma enquete realizada pelo autor com o objetivo de avaliar o grau
de utilizao das tcnicas e prticas que contribuem para a reduo de tempo no
Os resultados dessas avaliaes, juntamente com as abordagens sobre reduo de
tempo apresentadas no Captulo 4, orientaram a definio das tcnicas e prticas de
engenharia de software que compem o roteiro deste trabalho.
MCT (2002), Westfall (1987) e contribuio do autor.
5.1. Pesquisa sobre Qualidade e Produtividade no Setor de Software Brasileiro
Em 2001, foi realizada pela Secretaria de Poltica de Informtica a 5 edio da

pesquisa "Qualidade e Produtividade no Setor de Software Brasileiro" e a 2 edio
da "Produtividade Sistmica no Setor de Software Brasileiro", em parceria com o
Instituto Brasileiro de Qualidade e Produtividade do Paran - IBQP-PR, sobre a
utilizao das prticas de engenharia no desenvolvimento de software no Brasil
(MCT, 2002).
A pesquisa amostral, aplicada sobre uma populao alvo constituda pelas
empresas de desenvolvimento de software dos tipos: pacote para comercializao
packaged software, software sob encomenda para terceiros custom software,
software para Internet Internet software, software embarcado bundled,
embedded software.
64
A amostra efetiva da pesquisa foi de 446 empresas, cujos dados preenchidos em

formulrio prprio estruturado e no disfarado, foram criticados e consistidos
utilizando estrutura prpria criada pela Secretaria de Poltica de Informtica.
O erro calculado da amostra de 4,5%, considerando uma populao estimada para
o ano 2000 de 10.713 empresas com atividades em software no Brasil, para um
nvel de confiana de 95% sobre os resultados da pesquisa (MCT, 2002).
5.1.1 Resultados da Pesquisa
A Tabela 5.1 apresenta os resultados globais da utilizao das prticas de

engenharia de software nas empresas de tecnologia no Brasil em 2001:
Tabela 5.1 Prticas Engenharia de Software SEPIN (MCT, 2002)
Prticas de Engenharia de Software
Empresas
%
Modelagem de dados
302
70,10
Controle de verso de produto
298
69,10
Especificao de projetos
279
64,70
Especificao de requisitos
262
60,80
Especificao de programas
261
60,60
Projeto da interface com o usurio
244
56,60
Estimativa de custos
237
55,00
Mtodos orientados a objetos
232
53,80
Prototipao
220
51,00
Estimativa de esforo
197
45,70
Mtodos estruturados
173
40,10
Normas e padres da organizao
173
40,10
Anlise crtica conjunta
167
38,70
Planejamento formal de testes
163
37,80
Estimativa de tamanho
125
29,00
Gerncia de requisitos
105
24,40
Gerncia de configurao
101
23,40
Engenharia da informao
92
21,30
Gerncia de risco
51
11,80
Gesto de mudana
45
10,40
Joint Application Design JAD
35
8,1
65
Os resultados apresentados na Tabela 5.1 mostram que a maioria das empresas

pesquisadas adotam as prticas essenciais ao desenvolvimento de software como a
modelagem de dados, a especificao de requisitos, as especificaes de projetos e
programas, entre outras. No entanto, algumas prticas que auxiliam na reduo do
tempo de desenvolvimento tm sua utilizao limitada, como a prototipao utilizada
por 51% das empresas, as normas e padres da organizao por 40,1%, o
planejamento formal de testes por 37,8%, a gesto de riscos por 11,8% e a Joint
Application Design (JAD) por 8,1%.
100
90
80
70
60
50
40
30
20
10
0
70,1 69,1
64,7 60,8 60,6
56,6
55
53,8 51
45,7
40,1
M
od
el
ag
em
C
de
on
Es
tro
da
pe
do
le
ci
de
s
fic
a
ve
Es
o
rs
pe
o
de
ci
f
p
i
ca
Es
ro
pe
je
to
o
ci
s
re
fic
qu
a
In
i
si
o
te
to
pr
rfa
s
o
ce
gr
a
co
m
m
as
Es
o
tim
u
su
at
iv
r
a
io
de
cu
st
M
os
t
od
os
P
O
Es
O
tim roto
tip
at
iv
a
M
a
o
t
de
od
es
os
fo
es
r
tr u
o
tu
ra
do
s
% Utilizao
Figura 5.1 Prticas de Desenvolvimento em Engenharia de Software (MCT,2002)
A Figura 5.1 apresenta graficamente os resultados da Tabela 5.1, segmentado nas

prticas de desenvolvimento em engenharia de software, onde se observa um
aumento na utilizao dos mtodos orientados a objetos (53,8%) em relao aos
mtodos estruturados (40,1%).
Esse aumento verificado sobre o uso da orientao a objetos importante, pois
tcnicas como a componentizao e a reutilizao, que contribuem para a reduo
do tempo na produo do software, so mais efetivos com a utilizao dessa prtica.
Na Figura 5.2, observa-se que poucas empresas, menos de 25%, direcionam seus
esforos para a questo do gerenciamento de requisitos, riscos e para a gesto de
mudanas. A ausncia dessas prticas afeta diretamente o controle de prazos e de
66
custos dos projetos e, conseqentemente, so fatores crticos para a reduo de

tempo do ciclo de vida do projeto.
Prticas Engenharia de Software - Gesto
m
a
hu
JA
D
5,8
Es
t
Pl
an
ej
. fo
Ne
n
co
dr
pa
cr
t i
ca
e
m
as
lis
e
No
r
An
11,8 10,4 8,1
s
nj
rm
un
al
im
ta
de
at
iva
te
st
de
G
es
er
t
a
n
m
G
c
an
er
n ia r
ho
eq
cia
ui
sit
En con
fig os
g.
ur
Da
a
i
n
o
G
f
or
er
m
n
a
G
cia
es
t
de o
o
ris
de
co
m
ud
an
a
24,4 23,4 21,3
% Utilizao
100
90
80
70
60
50 40,1 38,7 37,8
40
29
30
20
10
0
Figura 5.2 Prticas de Gesto de Projetos em Engenharia de Software (MCT, 2002)
Verifica-se tambm um baixo ndice de utilizao de planejamento formal de testes

(37,8%), cujo objetivo principal a verificao da qualidade do software.
O resultado da pesquisa do MCT (2002) mostra que, embora exista ampla
divulgao de normas, modelos e recomendaes sobre as melhores prticas de
engenharia de software, um nmero reduzido de empresas aplicam essas prticas
dentro do seu processo de desenvolvimento.
5.2. Enquete para Verificao da Utilizao das Prticas de Engenharia de

Software
Entre os meses de novembro de 2005 e janeiro de 2006 foi realizada pelo autor uma
enquete com as empresas de desenvolvimento de software nos estados de So
Paulo, Rio de Janeiro, Minas Gerais e Distrito Federal para avaliar o nvel de
utilizao das prticas e tcnicas do roteiro proposto por este trabalho.
67
5.2.1. Objetivos da Enquete
O objetivo desta enquete foi avaliar o nvel de conhecimento e grau de aplicao das
tcnicas e prticas de engenharia de software, visando consolidar seus conceitos e
verificar sua efetividade na reduo do tempo no desenvolvimento de projetos de
software.
5.2.2. Natureza e Escopo
Foram distribudos cem questionrios (Anexo 1) descrevendo vinte e sete perguntas

sobre o uso das tcnicas e prticas de engenharia de software para as empresas de
desenvolvimento de software, cada uma delas contendo de trs a quatro opes de
mltipla escolha.
As empresas pesquisadas so constitudas por 97,7% do setor privado de produo
de software e 2,3% de empresas do governo.
5.2.3. Tcnica de Amostragem
A enquete realizada interseccional e no probabilstica, aplicada sobre um

universo constitudo pelas empresas de desenvolvimento de software no Brasil
atuantes nos segmentos de consultoria e prestao de servios, indstria,
telecomunicaes, financeiro, educao e governo, escolhidas pelo mtodo
intencional ou por julgamento.
A amostra efetiva desta enquete foi de 44 empresas, cujos dados foram preenchidos
em formulrio prprio e criticados utilizando estrutura prpria do autor.
Constituram o universo desta amostragem 31 consultorias e prestadoras de
servios, 4 empresas do ramo da indstria, 2 do segmento de telecomunicaes, 5
do segmento financeiro, 1 do segmento de educao e 1 estatal.
A maior concentrao de empresas ocorreu no estado de So Paulo (62%), seguido
pelo Rio de Janeiro (28%), Minas Gerais (7%) e Distrito Federal (3%).
68
5.2.4. Mtodo Utilizado para Coleta dos Dados
A enquete foi realizada baseada em um questionrio simples, constitudo de vinte e

sete perguntas, distribudos e recebidos atravs de meio eletrnico aos responsveis
diretos pelo processo de desenvolvimento de software das empresas pesquisadas.
A estrutura do questionrio pode ser analisada no Anexo 1.
5.2.5. Anlise e Interpretao
A partir das respostas das empresas, as informaes foram mapeadas e agrupadas

de acordo com os grupos objeto da pesquisa.
Para efeitos de interpretao, as respostas marcadas com a opo s vezes foram
mapeadas como negativas, pois o objetivo avaliar a utilizao completa da tcnica
ou prtica em questo.
5.2.6. Limitaes
Os questionrios dessa enquete foram distribudos para diversas empresas de

desenvolvimento de software do crculo de relacionamento do autor e da Escola
Politcnica da Universidade de So Paulo e no contou com a colaborao de
nenhum rgo relacionado s empresas alvo.
5.2.7. Resultados da Enquete
As empresas que responderam aos questionrios constituem um universo de

quarenta e quatro de um total de cem questionrios enviados.
Deste universo, 47,73% no possuem nenhuma certificao de processo de
qualidade, enquanto 52,27% possuem certificao ISO9000 ou CMM (Capability
Maturity Model SEI/CMU), conforme ilustrado na Tabela 5.2.
Ainda em relao s empresas que participaram da enquete, 57% podem ser
consideradas de grande porte (mais de 1000 funcionrios), 14% de mdio porte
69
(entre 100 e 1000 funcionrios) e 29% de pequeno porte (menos de 100

funcionrios).
Em relao s questes sobre gerenciamento de projetos foi verificado que 61,36%
das empresas possuem profissionais com certificao PMP (Project Management
Professional) do Project Management Institute (PMI).
Tabela 5.2 Perfil de Qualidade das empresas participantes da enquete

Requisito
Nr.
Empresas
Sem Certificao de Qualidade
21
47,73
Com Certificao de Qualidade
23
52,27
Com CMM Nvel 2
13
29,55
Com CMM Nvel 3
6,82
Com CMM Nvel 4
2,27
Com ISO 9001
13,63
Foram observados tambm fatores que indicam uma melhoria na definio do

processo de gerenciamento de projetos e no uso das tcnicas de gesto de risco e
gesto de mudanas, se comparadas com a pesquisa realizada pelo MCT (2002),
como apresentado na Tabela 5.3.
Tabela 5.3 Prticas de Gerenciamento de Projetos

Prtica
Nr.Empresas
Enquete (%)
MCT (%)
Processo de Gesto de Projetos
28
63,64
40,1
Mtrica para Estimativa de Tamanho
29
65,91
29,0
Gesto de Riscos
19
43,18
11,8
Gesto de Mudanas
23
52,27
10,4
A anlise sobre a utilizao dos ciclos de vida utilizados pelas empresas apresenta
ainda uma grande participao do modelo cascata na maioria das organizaes.
Porm, pode ser verificado um bom crescimento na utilizao do modelo iterativo
dentro das organizaes, conforme ilustrado na Tabela 5.4.
70
Outra observao importante sobre os ciclos de vida que a maioria das empresas
com certificao de qualidade utiliza mais de um modelo em seu processo de
desenvolvimento.
Ainda no universo pesquisado, 9% das organizaes no utilizam nenhum dos
modelos de ciclo de vida apresentados pela enquete.
Tabela 5.4 Modelos de Ciclos de Vida Utilizados

Modelo de Ciclo de Vida
Nr.Empresas
Iterativo
16
36,36
Cascata
13
29,55
Espiral
11
25,00
Outros
9,09
Em relao ao uso das prticas e tcnicas de engenharia de software, a enquete

mostra que a utilizao da orientao a objetos, da prototipao e a definio da
arquitetura so atividades amplamente utilizadas pelas organizaes e atingiram
altos ndices de aplicao.
Porm, as demais prticas ainda possuem baixos indicadores de emprego no
processo de desenvolvimento de software, conforme apresentado na Figura 5.3.
100
90
80
70
60
50
40
30
20
10
0
93,18
84,09
75
70,45
40,91
34,09
31,82
15,91
15,91
11,36
Ti
Ki
m
ck
eb
-o
ox
ff
en
tre
fa
Pr
se
ot
s
t
ip
o
En
E
ge
vo
lu
nh
tiv
ar
o
ia
S
im
ul
t
ne
a
na
m
C
en
om
to
po
ne
nt
iz
a
o
za
ti c
io
Pa
r
eu
ti l
i
ui
te
tu
ra
Ar
q
in
o
fn
Ki
ck
-o
f
de
In
te
r
M
t
od
o
t
ti p
Pr
o
c
io
fa
ce
18,18
O
O
% Utilizao
Utilizao das Prticas do Roteiro Proposto
Figura 5.3 Utilizao das Prticas de Engenharia de Software do Roteiro Proposto
71
Vale ressaltar que, embora as empresas realizem as reunies de kickoff no incio

dos projetos, 84,09% das empresas no utilizam esse tipo de reunio nas situaes
de mudanas de escopo ou troca de fase no processo de desenvolvimento do
projeto. A realizao da reunio de kickoff nessas situaes visa diminuir os conflitos
com o cliente em relao s expectativas de entregas de produtos e cumprimento
dos prazos estabelecidos.
Foi observado ainda que, em 52,27% das empresas, os clientes no participam
efetivamente das validaes dos artefatos e subprodutos dos projetos.
Outro fator relevante observado o nvel de desconhecimento e de no utilizao de
algumas prticas de engenharia de software por parte das organizaes
pesquisadas, o que indica que existem melhorias a serem aplicadas no processo de
desenvolvimento de software, conforme ilustrado na Tabela 5.5.
Tabela 5.5 Nvel de No Aplicao das Prticas de Engenharia de Software

Nr.Empresas
36
81,82
Participao efetiva do cliente
23
52,27
Particionamento
29
65,91
Desenvolvimento Baseado em Componentes
28
63,64
Reuso de Componentes
25
56,81
Engenharia Simultnea
39
88,64
Como anlise final sobre os resultados dessa enquete, considerando os resultados

mostrados nas Tabelas 5.6 e 5.7, observa-se que houve reduo no tempo de
produo do software pelas empresas, quando essas prticas so utilizadas no
processo de desenvolvimento de software.
Tabela 5.6 Resultado da aplicao da prtica de Prototipao

Uso da Prototipao
Reduziu o conflito com o cliente
58,06
Houve reduo do tempo de desenvolvimento
41,94
72
Tabela 5.7 Resultado da aplicao das prticas de Componentizao e Reuso

Uso da Componentizao e Reuso
Houve melhoria da qualidade dos projetos
69,70
Houve reduo do retrabalho
63,64
Reduziu o tempo de desenvolvimento do software
72,73
Para as prticas de desenvolvimento timebox e uso da engenharia simultnea, os

resultados sobre a reduo do tempo de desenvolvimento no podem ser
considerados como conclusivos em funo do baixo ndice de utilizao dessas
prticas pelas empresas pesquisadas, menos de 14%.
No entanto, considerando apenas o universo das organizaes que fazem uso
constante da engenharia simultnea durante o ciclo de desenvolvimento, pode ser
observado que em 73,73% das empresas houve melhoria da produtividade e em
63,64% houve reduo do tempo de desenvolvimento, conforme ilustrado na Tabela
5.8.
Tabela 5.8 Resultado da aplicao da prtica de Engenharia Simultnea
Uso da Engenharia Simultnea
Houve Melhoria de Produtividade
63,64
Reduziu o Tempo de desenvolvimento
73,73
A partir dos resultados apresentados pela enquete verifica-se que, com a aplicao
destas tcnicas e prticas de engenharia de software, possvel promover a
melhoria da produtividade, a diminuio do retrabalho e a reduo de tempo no
Neste captulo foi apresentado o resultado da pesquisa realizada pelo MCT (2002)
sobre qualidade e produtividade de software no Brasil e os resultados sobre a
avaliao da utilizao das tcnicas e prticas propostas pelo roteiro deste trabalho,
73
atravs de uma enquete realizada pelo autor com as empresas de desenvolvimento

de software no Brasil.
O resultado da pesquisa do MCT evidencia uma baixa maturidade das empresas em
relao ao processo de gesto de projetos, apresentando baixos ndices de
utilizao das tcnicas de gesto de riscos e gesto de mudanas que so
fundamentais durante o processo de desenvolvimento de software. Porm, essa
mesma pesquisa mostra um bom crescimento da utilizao de prticas como a
orientao a objetos, que melhora o grau do desenvolvimento baseado em
componentes e do reuso, alm do crescimento do uso da prototipao no processo
de desenvolvimento de software.
Esse resultado mostra que as organizaes necessitam aprimorar o seu processo de
gesto de projetos para melhoria dos resultados de prazo e custo dos projetos e que
as prticas de componentizao, reutilizao e prototipao auxiliam na melhoria da
qualidade e da produtividade do software.
A enquete foi realizada com o objetivo de avaliar o grau de utilizao das tcnicas e
prticas de engenharia de software propostas pelo roteiro deste trabalho e a
efetividade destas na reduo de tempo no desenvolvimento de software.
Os resultados mostram que estas prticas tm baixo nvel de uso no processo de
desenvolvimento das organizaes, principalmente pelo desconhecimento por parte
das empresas das tcnicas para aplicao das mesmas. No entanto, nas
organizaes que aplicam essas prticas, tm-se bons resultados no aumento da
produtividade, na diminuio do retrabalho e na reduo de tempo no
desenvolvimento dos projetos.
Como resultado da anlise dessas avaliaes possvel verificar que a adequada
utilizao das tcnicas e prticas de engenharia de software podem efetivamente
auxiliar as organizaes no processo de desenvolvimento, proporcionando aumento
na
produtividade
permitindo
obteno
de
ganhos
reais
no
tempo
74
___________________________________________________________________
6 O ROTEIRO PARA REDUO DE TEMPO NO

DESENVOLVIMENTO DE SOFTWARE
Objetivo do Captulo
O objetivo deste captulo apresentar a estrutura do roteiro para a reduo de

tempo no desenvolvimento de projetos de software.
A estrutura do roteiro baseada na anlise realizada sobre as principais abordagens
sobre a reduo de tempo no desenvolvimento de software discutidas no Captulo 4
e nos resultados das avaliaes apresentadas no Captulo 5.
Os resultados dessa anlise permitem definir as prticas e tcnicas de engenharia
de software para a composio do roteiro e que proporcionam ganhos reais na
reduo de tempo no desenvolvimento de software.
Este captulo constitui a contribuio do autor.
6.1. Definio da Estrutura do Roteiro para a Reduo de Tempo
A estruturao do roteiro foi elaborada considerando o estudo realizado sobre as

principais abordagens sobre a reduo de tempo no desenvolvimento de software
discutidas no Captulo 4 e nas avaliaes realizadas atravs da pesquisa do MCT
(2002) e da enquete realizada pelo o autor, discutidas no Captulo 5.
A partir da anlise sobre os modelos com foco na reduo do tempo de produo de
software como o Desenvolvimento Rpido de Aplicao (RAD), o Desenvolvimento
Rpido Evolutivo e a abordagem sobre reduo do ciclo de desenvolvimento
proposta por Collier e Collofello (1995), observa-se que algumas tcnicas e prticas
so comuns entre os modelos, conforme ilustrado na Tabela 6.1.
75
Tabela 6.1 Quadro Comparativo entre as abordagens de Reduo de Tempo

Prticas e Tcnicas de Engenharia de
Rpido
Collier e
RAD
Evolutivo
Collofello
Prototipao Evolutiva
Interao com o cliente
Software
Componentizao
Reuso
Atividades Concorrentes
Equipes reduzidas
Ferramentas CASE
Simplificao de Tarefas
JAD
X
X
O uso da prototipao para a identificao e validao de requisitos, o aumento da

interao com o cliente durante a execuo do projeto e a reduo do tamanho das
equipes de desenvolvimento (menos de 15 membros) so elementos consolidados
em vrios modelos e mostram-se efetivos na melhoria da comunicao e na reduo
dos riscos nos projetos de software (Wetherbe; Frolick, 2000).
O desenvolvimento timebox, embora abordado apenas pelo modelo RAD, uma
prtica com caractersticas que auxiliam na reduo da complexidade do software e
na reduo dos riscos, estabelecendo prioridades ao desenvolvimento do software e
obtendo o comprometimento do cliente com o projeto (Howard, 2002).
As prticas relacionadas ao desenvolvimento baseado em componentes, a
reutilizao e a execuo de atividades concorrentes atuam de forma a aumentar a
produtividade e a reduzir substancialmente o tempo de desenvolvimento do software
(Blackburn; Scudder; Wassenhove, 2000).
As abordagens desses modelos podem ser classificadas em seis objetivos principais
visando promover a reduo de tempo no desenvolvimento de software, conforme
apresentado na Tabela 6.2.
76
Tabela 6.2 Comparativo entre os objetivos das abordagens de Reduo de Tempo.

Objetivos
Rpido
Collier e
RAD
Evolutivo
Collofello
Melhoria da Comunicao
Aumento da Produtividade
Reduo de Riscos
Controle da Complexidade
Reduo do Retrabalho
Manuteno da Qualidade
No estudo realizado por Blackburn, Scudder e Wassenhove (2000) com empresas

dos EUA, Europa e Japo e na enquete realizada pelo autor, os resultados mostram
que a utilizao das tcnicas e prticas apresentadas na Tabela 6.3, produzem
resultados tangveis em relao reduo do ciclo de desenvolvimento.
Tabela 6.3 Tcnicas e Prticas que Contribuem para a Reduo de Tempo

Prticas e Tcnicas de Engenharia de
Blackburn
Enquete
Software
2000
2005
Componentizao
Reuso
Prototipao Evolutiva
Prototipao de Interface
Simplificao de tarefas
X
X
Considerando os objetivos que orientam os esforos desses modelos para a reduo

do ciclo de desenvolvimento e os resultados das avaliaes sobre a utilizao das
tcnicas e prticas de engenharia de software possvel realizar um mapeamento
entre os conceitos que impactam na diminuio de tempo no desenvolvimento de
software, conforme ilustrado na Figura 6.1.
77
Figura 6.1 Mapeamento dos conceitos que impactam na reduo de tempo
Com o foco na reduo do tempo de desenvolvimento, a definio da arquitetura

orienta a elaborao da estratgia de desenvolvimento a ser adotada, organiza a
estrutura para o desenvolvimento baseado em componentes e viabiliza a execuo
de atividades em paralelo, buscando manter a complexidade sob controle, diminuir o
retrabalho e aumentar a produtividade atravs da maximizao do reuso do
software.
O mapeamento desses conceitos permite a definio das seguintes prticas e
tcnicas para a composio do roteiro proposto por este trabalho:
1. Definio da Arquitetura de Software: Orienta e direciona todas as

atividades do roteiro;
2. Planejamento Colaborativo: Envolve o cliente em todas as fases do projeto,
obtendo o comprometimento de todos os envolvidos;
3. Particionamento: Simplifica a execuo das tarefas e facilita as validaes
do cliente;
4. Desenvolvimento
Timebox:
Permite
focar
desenvolvimento
caractersticas principais e estabelece prioridades dentro do projeto;
nas
78
5. Prototipao: Facilita o entendimento do cliente e auxilia na estabilizao

dos requisitos;
6. Desenvolvimento Baseado em Componentes: Permite aumentar o
paralelismo das atividades e viabiliza a reutilizao;
7. Reutilizao: Aumenta a produtividade e prov melhoria da qualidade;
8. Engenharia Simultnea: Permite a realizao de tarefas concorrentes em
todas as fases do projeto, reduzindo o tempo de desenvolvimento.
A Tabela 6.4 mostra a relao entre as prticas e tcnicas do roteiro com os

objetivos das abordagens de reduo de tempo.
Tabela 6.4 Mapeamento das Prticas e Tcnicas com os Objetivos de Reduo de Tempo
Objetivos
Melhoria da Comunicao
Aumento da produtividade
Reduo de Riscos
Controle da Complexidade
Reduo do Retrabalho
Manuteno da Qualidade
Prticas e Tcnicas
Planejamento Colaborativo
Prototipao
Arquitetura de Software
Reuso
Prototipao
Timebox
Particionamento
Timebox
Reuso
Desenvolvimento baseado em Componentes
Reuso
Prototipao
Desenvolvimento baseado em Componentes
Reuso
Embora essas tcnicas e prticas tenham sido selecionadas para constiturem este
roteiro, o grupo de atividades apresentado na Figura 6.1 pode ser utilizado como
referncia para a criao de outros roteiros ou para incluso de outras tcnicas ou
prticas de engenharia de software que auxiliem na reduo de tempo no
79
6.2. Os Elementos do Roteiro para Reduo de Tempo no Desenvolvimento de

Software
A finalidade deste roteiro organizar a utilizao ordenada e conjunta das prticas e

tcnicas de engenharia de software descritas no item 6.1 com o objetivo de obter
ganhos reais de tempo no processo de desenvolvimento de software.
Com a definio das tcnicas e prticas de engenharia de software que so
utilizadas neste roteiro, pode-se estabelecer um mapeamento entre esses elementos
conforme ilustrado na Figura 6.2.
Figura 6.2 Mapeamento dos Elementos que compem o Roteiro Proposto
O processo de desenvolvimento dividido em trs abordagens principais: a

elaborao do planejamento, a definio da estratgia da soluo e a definio da
arquitetura de software a ser utilizada durante o projeto.
No planejamento definido o ciclo de vida a ser utilizado e os pacotes de trabalho
que representam os produtos entregveis ao cliente durante o projeto.
80
Orientada pela definio da arquitetura de software, a estratgia da soluo avalia e

estabelece como o projeto ser desenvolvido utilizando as tcnicas de prototipao,
do desenvolvimento timebox e do particionamento, visando simplificar as tarefas,
diminuir os riscos e aumentar o grau de atividades concorrentes.
A arquitetura de software deve orientar o desenvolvimento baseado em
componentes e o reuso, aumentado a produtividade e a execuo das atividades
concorrentes.
A execuo do projeto apoiada e orientada por dois processos:
1. Processo de gesto de projetos Deve haver um processo de
gerenciamento de projetos estabelecido com o objetivo de coordenar todas as
atividades previstas no roteiro.
2. Metodologia de desenvolvimento de software - Para a produo de
software em escala, a metodologia de desenvolvimento deve estar bem
definida e de conhecimento de toda a equipe do projeto para proporcionar a
correta execuo das atividades.
Esses dois processos so considerados pr-requisitos para a aplicao deste roteiro
e no so detalhados neste trabalho.
A seguir so descritos os elementos que compem o roteiro e os pr-requisitos
mnimos necessrios para a utilizao adequada de cada prtica ou tcnica.
1) Planejamento do Projeto
O planejamento deve ser realizado de forma colaborativa entre a equipe do

projeto e o cliente e adequado realidade das necessidades de cada projeto.
A definio do ciclo de vida de desenvolvimento direciona a escolha entre os
modelos espiral ou iterativo por serem mais adequados em funo da flexibilidade
e da gerao de resultados tangveis mais rpidos.
A anlise de viabilidade e a identificao dos pontos de aplicao da engenharia
simultnea devem comear a ser verificados a partir do planejamento.
81
Outro fator a ser observado durante o planejamento a preparao da reunio de

kickoff do projeto que deve conter as principais atividades do projeto, os pontos
de controle, os principais riscos e as dependncias associadas ao projeto.
Os seguintes pr-requisitos devem ser observados para a elaborao do
planejamento do projeto:
Participao efetiva do cliente na tomada de decises;
Conhecimento da equipe do projeto nos modelos de ciclo de vida iterativo

ou espiral;
Metodologia de desenvolvimento definida;
Processo de gerenciamento do projeto estabelecido.
2) Definio da Estratgia da Soluo
A estratgia da soluo consiste na anlise das caractersticas do projeto e na

definio de como ele ser organizado e dividido.
A equipe de projeto, em conjunto com o cliente, deve realizar reunies para
determinar os requisitos principais do projeto com a finalidade de se obter:
1. Reduo do tempo de desenvolvimento;
2. Aumento progressivo da visibilidade do projeto;
3. Reduo de riscos.
As principais tcnicas e prticas que auxiliam na definio dessa estratgia so:
2.1 Particionamento do Projeto
O particionamento visa diminuir a complexidade do projeto e auxilia na

definio das atividades concorrentes nas fases iniciais do projeto.
Os seguintes pontos devem orientar a definio das parties do projeto:
82
Maximizao da independncia entre as parties para permitir

maior paralelismo das atividades;
Priorizao das principais necessidades de negcio.
2.2 Desenvolvimento Timebox
O procedimento central desta prtica enquadrar as principais caractersticas

do projeto em perodos de tempo que permitam o atendimento das
necessidades do cliente dentro do menor tempo possvel. Os timeboxes
definidos devem ser analisados e aprovados em conjunto com o cliente.
Os
seguintes
pontos
devem
ser
seguidos
para
aplicao
do
desenvolvimento timebox:
O projeto deve estar com o particionamento definido;
Os timeboxes devem ter durao mxima de 120 dias para criar o

senso de urgncia equipe (McConnell, 1996);
Utilizao da prototipao evolutiva para auxiliar no entendimento

dos requisitos;
O cliente deve participar da definio dos timeboxes.
2.3 Prototipao Evolutiva
A elaborao do prottipo permite a validao do cliente do entendimento dos

requisitos e auxilia na definio dos timeboxes.
Os seguintes pr-requisitos devem ser atendidos para a utilizao da
prototipao evolutiva:
O cliente que participa da definio do prottipo deve ter domnio

dos
requisitos
desenvolvido;
de
negcio
funcionais
que
deseja
ver
83
O cdigo produzido deve estar de acordo com a tecnologia que

ser utilizada no desenvolvimento para permitir o reaproveitamento
do cdigo.
3) Definio da Arquitetura de Software
A definio da arquitetura de software de vital importncia na produo de

software em escala e define o sucesso ou insucesso de um projeto (Zhang,2003).
A definio da arquitetura de software a ser utilizada o passo chave para os
efetivos ganhos em tempo de desenvolvimento e produtividade pela equipe do
projeto. Alm de direcionar a estratgia de desenvolvimento, a arquitetura
viabiliza o desenvolvimento baseado em componentes, a reutilizao e a
utilizao da engenharia simultnea.
Para a definio da arquitetura os seguintes pr-requisitos devem ser observados:
Conhecimento das premissas e restries de tecnologia do ambiente de

desenvolvimento;
Utilizao de desenvolvimento orientado a objetos;
Experincia da equipe na tecnologia definida.
4) Desenvolvimento baseado em Componentes e Reutilizao
Uma vez definida a arquitetura, a modelagem do sistema deve ser cuidadosa e

ampla, com o objetivo de definir quais so os componentes de negcio que
devem ser desenvolvidos, adquiridos ou reutilizados pelas diversas parties do
sistema.
Tambm devem ser desenvolvidos e aplicados os componentes de infra-estrutura
definidos para o ambiente de execuo do software. Entre eles tm-se: conexes
com a base de dados, controles de sesso, permisses de usurios, aplicaes,
entre outros.
84
Com a utilizao dos componentes e, conseqente reutilizao do software, a

reduo de tempo de desenvolvimento d-se atravs da reduo do esforo de
codificao e da eliminao da necessidade de aplicao de testes sobre o
software reutilizado.
Para a utilizao do desenvolvimento componentizado e da reutilizao os
seguintes pr-requisitos devem ser atendidos:
A arquitetura de software deve orientar o desenvolvimento baseado em

componentes;
Existncia do repositrio ou biblioteca de componentes reutilizveis;
Definio do responsvel pela administrao dos componentes;
Facilidade de identificao e busca de componentes;
Documentao de utilizao dos componentes atualizada e disponvel;
Processo de divulgao e atualizao de componentes estabelecido;
Treinamento e mentoring das equipes de projeto.
5) Engenharia Simultnea
Dentro do roteiro proposto, a engenharia simultnea o conceito que mais

contribui para a reduo do tempo de produo do software.
A engenharia simultnea uma abordagem que permite a realizao de vrias
atividades ao mesmo tempo, sem a eliminao de passos essenciais para a
construo do software. Sua aplicao desde as fases iniciais do projeto permite
a execuo das atividades do projeto com o paralelismo necessrio para reduzir o
tempo final do processo de desenvolvimento.
Porm, a realizao de atividades concorrentes exige uma comunicao eficiente
entre os membros da equipe e maior controle durante a execuo do projeto
visando evitar o retrabalho e o aumento dos riscos no projeto. A Tabela 6.5
mostra os pontos fracos e pontos fortes do uso da engenharia simultnea.
85
Tabela 6.5 Pontos Fortes e Pontos Fracos no uso da Engenharia Simultnea
Pontos Fortes
Pontos Fracos
Paralelismo das atividades reduz o tempo de

desenvolvimento.
Reduo de custos.
Produo de resultados mais rpidos.

Melhoria no processo de comunicao.
Necessidade de maior grau de controle

gerencial na execuo das atividades.
Mudanas constantes de requisitos no
controladas podem gerar retrabalho e
aumento de custos.
Alto grau de paralelismo pode aumentar os
riscos do projeto.
Resistncia ao uso por equipes com averso
ao riscos.
Aumento da produtividade.
Para reduzir os pontos fracos descritos na Tabela 6.5, as seguintes atividades

devem ser consideradas:
O maior obstculo para o uso da engenharia simultnea a constante

alterao de requisitos. Esse problema pode ser diminudo gastando-se
mais tempo nas fases iniciais do projeto para fortalecer a estabilidade dos
requisitos e aderncia s necessidades do cliente (Collier e Collofello,
1995);
Uso da prototipao para auxiliar no entendimento e validao do cliente;
Utilizao de equipes reduzidas para a diminuio dos canais de

comunicao;
Fluxo de comunicao da equipe deve ser livre e informal para garantir a

troca de informaes;
Outra dificuldade na engenharia simultnea est relacionada em determinar o que

ser desenvolvido de forma concorrente dentro do projeto. Essa definio est
diretamente
relacionada
caractersticas
do
projeto
que
est
sendo
desenvolvido, ao modelo do ciclo de vida escolhido, o nmero de recursos

disponveis e a flexibilidade da arquitetura que est sendo utilizada. No entanto,
alguns critrios podem ser utilizados como referncia para auxiliar nesta
definio:
1. A elaborao do prottipo e a definio dos timeboxes so atividades que
podem ser desenvolvidas de forma concorrente;
2. As parties independentes definidas na estratgia da soluo devem ser
analisadas para determinar o grau de paralelismo aplicvel ao projeto;
86
3. Essas parties independentes so candidatas a serem subprojetos com

desenvolvimento completo at a entrega ao cliente;
4. A definio da arquitetura pode ser paralela fase de definio de
requisitos;
5. O levantamento e anlise dos componentes reutilizveis so atividades
independentes podendo ocorrer em qualquer fase do processo de
desenvolvimento.
6.3. Fluxo de Atividades para a Aplicao do Roteiro para Reduo do Tempo

de Desenvolvimento de Software
O conjunto de tcnicas e prticas de engenharia de software definidas pelo roteiro

deste trabalho devem ser realizados na seqncia estabelecida com o objetivo de
viabilizar a utilizao da tcnica seguinte, e assim sucessivamente, at a obteno
do produto final. Este fluxo de atividades ilustrado esquematicamente na Figura
6.3.
O fluxo de atividades do roteiro composto por quatorze atividades, agrupadas em
cinco fases de acordo com a correlao entre elas, visando organizar a seqncia
de execuo e facilitar a aplicao do roteiro.
A seguir so descritos os objetivos das cinco fases definidas pelo roteiro:
Fase 1 - Planejamento do projeto

Consiste na anlise dos objetivos e dos requisitos iniciais do projeto visando definir
quais so as atividades necessrias para a execuo do projeto.
Fase 2 - Definio da Estratgia da soluo

O objetivo desta fase analisar e definir as possveis estratgias que sero
aplicadas no desenvolvimento do projeto.
Fase 3 - Formalizao e Incio do Desenvolvimento do Software

Visa apresentar para todos os envolvidos no projeto a estratgia de desenvolvimento
a ser aplicada durante a execuo do projeto e obter sua aprovao.
87
Fase 4 - Definio dos componentes e reutilizao

O objetivo desta fase publicar os novos componentes e orientar o reuso equipe
do projeto para eliminar as redundncias e reduzir o tempo de desenvolvimento.
Fase 5 - Desenvolvimento das parties

Caracterizada pela construo das parties definidas na estratgia da soluo.
Figura 6.3 Fluxo de Atividades do Roteiro
88
Fase 1 Planejamento do Projeto
A fase 1 consiste em executar as atividades preliminares para analisar os objetivos e

requisitos iniciais do projeto a fim de revisar e determinar as atividades necessrias
para a execuo do projeto, a definio do ciclo de desenvolvimento a ser utilizado e
identificar e reunir os principais riscos e pendncias sobre o escopo do projeto. Estes
dados servem de base para a execuo das atividades da fase 2.
- Atividades Executadas
1) Definio da Estrutura Analtica do Projeto (EAP)
Baseado na especificao inicial dos requisitos do projeto e de acordo com

o processo de desenvolvimento da empresa deve ser realizada a anlise
dos principais produtos de entrega ao cliente para elaborao da EAP que
o documento principal para a definio do escopo do projeto e base para
futuras negociaes de mudanas no projeto.
2) Definio do Ciclo de Vida
Na fase inicial do planejamento importante a definio do ciclo de vida a

ser utilizado durante a execuo do projeto, pois um fator determinante
para permitir a reduo do tempo de desenvolvimento.
Conforme definies apresentadas no captulo 2, o ciclo de vida
recomendado pelo roteiro o modelo iterativo e incremental, que
proporciona resultados tangveis rapidamente e maior flexibilidade s
mudanas que ocorrem durante o projeto.
3) Preparao para a reunio de Kickoff do projeto
A partir da definio da EAP e do ciclo de vida para o projeto, so

realizadas as atividades iniciais para anlise dos riscos e verificao das
pendncias e dvidas sobre os requisitos do projeto e ento, mapeadas no
89
documento
de
pendncias
ou
no
mapa
de
riscos
para
futuro
acompanhamento.
Nesta atividade, elabora-se o cronograma preliminar de tarefas do projeto,
alinhado com o ciclo de vida definido e orientado construo dos
produtos previstos na EAP. Aps a concluso do cronograma,
recomendvel a criao da linha de base do projeto que serve de
referncia para o controle e acompanhamento do prazo e do custo do
projeto.
- Produtos de Trabalho Resultantes da Fase 1
Como resultado das atividades realizadas nesta fase, os seguintes artefatos so

elaborados:
Estrutura Analtica do Projeto (EAP): Define os produtos que devem ser

entregues ao cliente. Deve ser elaborada em formato grfico para facilitar
o entendimento e organizados por fases;
Mapa de Riscos: Os riscos do projeto so identificados, analisados, as

respostas aos riscos so desenvolvidas e armazenadas para o
acompanhamento durante o projeto. O mapa de riscos deve conter, no
mnimo, a descrio do risco, a descrio do evento que indica que o risco
est para ocorrer, o grau de impacto e a probabilidade de ocorrncia para
definio da prioridade, a data limite para resoluo, a descrio do
impacto, as aes de resposta e contingncia a ser aplicada caso o risco
venha a ocorrer;
Cronograma Preliminar: Cronograma com a definio das atividades

orientado para a construo dos produtos definidos na EAP e de acordo
com o ciclo de desenvolvimento definido;
Plano do Projeto preliminar: So identificados os principais elementos

que sero utilizados na reunio de incio do projeto. Deve conter os
seguintes elementos: Objetivo do projeto, as datas de incio e trmino,
90
cronograma sumarizado, principais pontos de controle, organograma da

equipe, EAP, as dependncias, premissas e restries do projeto e os
principais riscos envolvidos.
- Restries Identificadas
Como as atividades desta fase so preliminares, as mesmas podem sofrer

alteraes durante a execuo da fase 2, onde realizada uma anlise mais ampla
e com a participao de todos os envolvidos.
A falta de conhecimento do ambiente onde o projeto ser desenvolvido pode gerar
uma estimativa inicial inadequada sobre a durao das atividades e ou a
identificao de riscos que afetam o projeto.
- Aspectos de utilizao do roteiro
As atividades e produtos previstos nesta fase so essenciais para o entendimento

dos requisitos e estabelecem uma viso inicial sobre as dificuldades do projeto, e
devem ser executados obrigatoriamente.
Apenas a atividade de definio do ciclo de vida pode sofrer alteraes, pois o
modelo iterativo e incremental muitas vezes no de domnio das empresas e da
equipe do projeto, podendo gerar resistncias ao roteiro. Neste caso, a nica
recomendao a no utilizao do modelo cascata, pois este apresenta diversas
desvantagens, conforme apontado no Captulo 2.
Fase 2 Estratgia da soluo
Uma vez que os principais produtos e problemas envolvidos no projeto foram

identificados, a prxima etapa a definio da estratgia a ser aplicada no
desenvolvimento do projeto.
Nesta fase, a anlise deve estar com foco na definio das principais caractersticas
do projeto, na priorizao das entregas, na escolha da arquitetura de sistema, na
pesquisa dos componentes que sero reutilizados e, principalmente, a definio o
grau de paralelismo das atividades a ser aplicado no projeto.
91
Esta fase determinante para o sucesso do projeto e deve contar com a

participao efetiva do cliente para a obteno do comprometimento e aprovao
formal da estratgia de desenvolvimento do software.
1) Definir o Particionamento
A definio das parties estabelece como o projeto ser desenvolvido e

entregue ao cliente para validao. A durao destas parties deve estar
entre duas e seis semanas dependendo das caractersticas de cada projeto,
permitindo a verificao rpida dos resultados do projeto.
Duas atividades devem ser executadas para complementarem essa definio:
1.1 Desenvolver o Prottipo: Desenvolver o prottipo nesta fase pode

ser de grande valia para a verificao das principais funcionalidades e
entendimento
claro
das
caractersticas
pelo
cliente.
prottipo
desenvolvido pode ser evolutivo ou apenas de interface, mas o mais amplo

possvel para apoiar na definio dos timeboxes.
1.2 Definir os Timeboxes: A partir da identificao das principais
caractersticas do projeto, deve ser desenvolvido em conjunto com o cliente
a priorizao dos requisitos e o seu agrupamento nas parties definidas
de acordo com o prazo disponvel e s necessidades do negcio.
Dependendo das decises estabelecidas nos timeboxes podem haver
revises nas parties definidas.
2) Definir a Arquitetura do Software
A finalidade desta atividade apresentar a soluo tcnica a ser

desenvolvida. Devem ser observadas as caractersticas do ambiente do
cliente e eventuais pr-requisitos estabelecidos sobre o hardware disponvel,
softwares bsicos utilizados e as especificaes tcnicas como linguagem de
programao e banco de dados que devero ser utilizados.
92
Na inexistncia destes requisitos preliminares, a equipe de projeto deve

apresentar as solues tcnicas disponveis no mercado, com as respectivas
vantagens e desvantagens para a definio com a equipe tcnica do cliente.
A orientao da arquitetura para os sistemas WEB deve seguir o estilo MVC
(Model-View-Controller) e utilizao de linguagem orientada a objetos, cujas
caractersticas so direcionadas para o desenvolvimento baseado em
componentes e para o reuso.
3) Consultar Componentes para Reuso:
Esta atividade consiste na pesquisa e identificao de possveis componentes

existentes que podem ser reutilizados no projeto. O foco esta em verificar os
componentes de infra-estrutura e de negcio disponveis para reuso e
verificar a necessidade de aquisio ou desenvolvimento de novos
componentes.
4) Analisar a Estratgia de Engenharia Simultnea:
O objetivo desta atividade identificar, priorizar e verificar o grau de

acoplamento entre as tarefas de forma a analisar a viabilidade da sua
execuo em paralelo.
Deve ser realizada em paralelo com todas as atividades desta fase, pois
atravs do grau de paralelismo de desenvolvimento das parties que o
tempo de desenvolvimento pode ser reduzido substancialmente.
Durante toda a anlise da engenharia simultnea deve ser levado em
considerao o grau de risco envolvido para cada soluo apresentada.
5) Preparar o Plano do Projeto Definitivo:
Baseado nas definies obtidas e validadas nesta fase, o plano do projeto

preliminar deve ser alterado para conter o particionamento e a estratgia de
paralelismo das parties que ser apresentado no incio da fase 3.
93
Como resultado desta fase, os seguintes artefatos so produzidos:
Roteiro das parties: Descreve o contedo das parties que sero

desenvolvidas, a prioridade, a dependncia entre elas e a ordem de
validao e aceite a ser realizado pelo cliente. Neste artefato que
mostrado o grau de paralelismo aplicado ao projeto.
Prottipo: Apresenta a viso preliminar das funcionalidades que sero

desenvolvidas. refinado durante o ciclo de desenvolvimento dentro de
cada partio.
Documento de Arquitetura do Sistema: Documento que define os

padres de desenvolvimento que devem ser seguidos durante a
construo das parties. Deve conter o diagrama de distribuio da
aplicao, um modelo da arquitetura de software e os padres de
codificao estabelecidos.
Lista de Componentes: Relaciona os componentes identificados para

reuso, sua localizao e os documentos de referncia para sua utilizao.
Tambm
so
descritos
aqueles
que
devem
ser
adquiridos
ou
desenvolvidos.
Cronograma de Trabalho: Desenvolvido a partir do cronograma

preliminar elaborado na fase 1, acrescido das estratgias de soluo
definidas nesta fase. Devem ser observados os novos pontos de controle
para acompanhamento do projeto e as datas de validaes do cliente.
Plano do Projeto definitivo: Adiciona as informaes complementares da

estratgia da soluo ao documento preliminar elaborado na fase 1. As
principais informaes desta fase esto relacionadas aos timeboxes
definidos, as parties de desenvolvimento, as definies de arquitetura e
94
as datas dos principais pontos de controle do projeto e as datas de

entregas das parties.
Durante a aplicao do roteiro foram observadas as seguintes restries para esta

fase:
- A construo do prottipo nem sempre possvel nesta fase. Neste caso, a
definio dos timeboxes baseada na experincia e conhecimento do
negcio do representante do cliente e da equipe do projeto;
- No caso de ausncia do cliente nesta fase os riscos aumentam

substancialmente pela posio unilateral da soluo. Este fator pode ser
minimizado atravs da reunio de kickoff, cuja presena dos envolvidos
obrigatria e todas as questes sobre o projeto so apresentadas;
- Outra restrio verificada a posio do cliente em no validar as parties

aps a entrega, deixando para uma avaliao nica aps todas as entregas.
Nesta situao cabe um esclarecimento e apresentao das vantagens da
validao parcial para o sucesso e cumprimento dos prazos.
A definio dos timeboxes, a organizao das parties e a definio da arquitetura

de implementao so indispensveis para a aplicao do roteiro.
De acordo com o nvel de engenharia simultnea aplicada, os riscos identificados
devem ser monitorados e acompanhados com nfase durante todo o projeto, com o
objetivo de minimizar o retrabalho nas tarefas executadas.
A inexistncia de componentes de infra-estrutura para reuso afeta diretamente a
estratgia da soluo. Neste caso, deve ser criada uma partio exclusiva para o
desenvolvimento destes componentes para permitir seu reaproveitamento nas
demais parties. O tempo gasto para esta construo deve ser recuperado nas
parties subseqentes.
95
Fase 3 Formalizao e Incio do Desenvolvimento do Software
O objetivo desta fase apresentar para todos os envolvidos no projeto as definies

e a estratgia de desenvolvimento a ser aplicada durante a execuo do projeto.
A participao das equipes que iro interagir durante o projeto essencial para se
obter o resultado esperado desta fase. A ausncia de um destes envolvidos pode
comprometer o planejamento e execuo do cronograma de trabalho.
Nesta reunio so apresentados os principais marcos de controle, as dependncias
e os maiores riscos para o sucesso do projeto. Tambm, devem ser apresentadas as
datas onde os clientes so envolvidos para validao das entregas das parties.
1) Realizao da reunio de Kickoff:
a formalizao da estratgia de desenvolvimento adotada para o projeto,

conforme descrito na fase 2. Deve ter aspecto formal e participao efetiva de
todos os envolvidos no projeto para obteno do comprometimento e aceite
do projeto, bem como dos prazos estabelecidos.
Eventuais alteraes devem ser registradas e o plano alterado para comportar
as referidas solicitaes. Porm, tratando-se de alteraes relevantes, uma
nova reunio deve ser realizada para o aceite definitivo.
2) Incio do Ciclo de Desenvolvimento do software:
Obtido o aceite o formal da estratgia de desenvolvimento, d-se incio s

atividades previstas no cronograma de trabalho.
Como resultado desta fase, o seguinte produto de trabalho elaborado:
96
Plano do Projeto aprovado: Todos os artefatos produzidos at esta fase

constituem o plano do projeto, no sendo necessria a elaborao de um
novo documento. Sua aprovao formal obtida na reunio de kickoff.
A principal restrio identificada nesta fase refere-se a ausncia de uma das partes
envolvidas no projeto na reunio de kickoff ou a recusa na realizao da mesma.
Neste caso, devem ser realizadas reunies junto ao cliente destacando a
importncia e os objetivos da realizao da mesma.
A reunio de kickoff obrigatria na aplicao do roteiro. A no realizao da

reunio ou a ausncia de um envolvido torna-se um fator impeditivo para o incio do
projeto.
Fase 4 Definio dos componentes e reutilizao
medida que as parties so desenvolvidas, outros componentes de negcio so

identificados, podendo ser reutilizados em outras parties. Nesta fase, a nfase
est em publicar estes novos componentes reutilizveis para a equipe do projeto
com o objetivo de eliminar redundncias e reduzir o tempo de desenvolvimento.
1) Definir os componentes:
Esta atividade consiste na publicao de novos componentes de negcio que

so identificados ou adquiridos durante o desenvolvimento do projeto.
Estes componentes devem ter, no mnimo, definidas as assinaturas de
acesso s suas operaes e a documentao de sua utilizao.
97
2) Definir a estratgia de reuso:
Baseado na estratgia de reutilizao de componentes descrita no Captulo 3,

a equipe do projeto deve identificar os novos componentes e analisar a
dependncia existente entre eles, compartilhando o conhecimento atravs do
repositrio central de componentes e sob a coordenao de um membro da
equipe.

Como resultado desta fase, os seguintes produtos de trabalho so elaborados:
Novos Componentes para reuso: Relaciona os novos componentes de

negcio identificados para reuso, sua localizao e os documentos de
referncia para sua utilizao.
A maior restrio verificada para esta fase est em no se utilizar linguagens
orientadas a objetos na construo dos componentes, tornando-se fator impeditivo
para aplicao das atividades desta fase. Pela sua estrutura, a orientao a objetos
permite a organizao do software em componentes e facilita o reuso em outras
aplicaes.

Deve ser dada ateno especial reutilizao dos componentes nos projetos com
alto grau de paralelismo, pois a dependncia entre as diversas tarefas concorrentes
pode dificultar o reuso adequado dentro do projeto.
As atividades de identificao, armazenamento e publicao de novos componentes
devem ser contnuas durante todo o projeto para permitir sua reutilizao em outros
projetos.
98
Fase 5 Desenvolvimento das parties

Esta fase caracterizada pela construo das parties definidas na estratgia da
soluo. Cada produto da partio desenvolvido e entregue para a validao do
cliente de acordo com a EAP e seguida de uma RTF (reviso tcnica formal).
1) Desenvolvimento da partio:
Constitui na realizao das tarefas necessrias para a construo do produto,

conforme planejado durante a fase de estratgia da soluo e definido na
EAP. Devem ser realizadas revises tcnicas formais (RTF) junto ao cliente
para o aceite formal de todos os produtos entregveis, em todas as fases do
ciclo de desenvolvimento do software.
Como resultado desta fase, os seguintes produtos de trabalho so elaborados:
Pacote: So os artefatos ou executveis definidos na EAP para a

validao do cliente, conforme o cronograma de trabalho.
Relatrio de Revises Tcnicas Formais: Para cada artefato ou

executvel definido como um produto de entrega pela EAP deve ser objeto
de reviso junto ao cliente, com o objetivo de se obter o aceite formal do
contedo do artefato ou da funcionalidade construda.
Deve conter informaes relativas ao local, data de realizao,
participantes, artefatos objetos da reviso, outros anexos de apoio, as
concluses sobre o aceite ou no do material revisado.
Documento de Gesto de Mudanas: Todas as mudanas de requisitos

identificadas durante o desenvolvimento da partio devem ser registradas
e acompanhadas com a finalidade de servirem de base para a negociao
sobre sua incorporao ou no ao projeto.
99
Deve conter informaes sobre a descrio da mudana, impactos sobre o

projeto, solicitante da mudana, data da solicitao, grau de dificuldade,
estimativas de esforo e prazo para atendimento.
Conforme descrito na fase de planejamento do projeto, no recomendada a
utilizao do modelo de ciclo de vida em cascata, pois pouco flexvel
incorporao de mudanas e aos resultados produzidos so tardios.

Eventuais mudanas de escopo devem ser tratadas em uma nova partio de forma
a no afetar as datas de entrega planejadas, salvo quando existe uma formalizao
de aceite do cliente e as novas datas so publicadas a todos os envolvidos. Porm,
estas alteraes de planejamento devem ser realizadas somente quando a
incorporao dos novos requisitos tenha carter impeditivo para atender s
necessidades do negcio.
A Tabela 6.6 apresenta, em resumo, os produtos gerados a partir do roteiro.
Tabela 6.6 Produtos resultantes da Aplicao do Roteiro
Produto
Fase do Roteiro
Nr.
1
EAP
1 - Planejamento
Mapa de Riscos
1 - Planejamento
Cronograma Preliminar
1 - Planejamento
Plano do Projeto Preliminar
1 - Planejamento
Roteiro das parties
2 Estratgia da Soluo
Prottipo
Documento de Arquitetura do Sistema
Lista de Componentes
Cronograma de trabalho
10
Plano do Projeto Aprovado
3 Formalizao e Incio
11
Lista de Novos Componentes para
4 Reuso e Componentes
reuso
12
Pacote
5 - Desenvolvimento
13
Relatrio da Reunio Tcnica Formal
5 Desenvolvimento
14
Documento de Gesto de Mudanas
5 Desenvolvimento
100
Neste captulo foi descrita a estrutura do roteiro para reduo de tempo no

desenvolvimento de software, seus elementos, as condies de utilizao de cada
tcnica e prtica de engenharia de software e o fluxo de atividades para a aplicao
do roteiro. Foram apresentadas tambm, as atividades a serem executadas, os
produtos de trabalho, as restries e os aspectos de utilizao destas atividades em
cada fase do roteiro.
O roteiro apresentado est baseado no planejamento colaborativo com o cliente e na
definio da arquitetura de software que viabilizam e permitem a definio das
prioridades de desenvolvimento do projeto utilizando o particionamento, os
timeboxes e a prototipao. Aliado a estas prticas, o desenvolvimento baseado em
componentes, do reuso e da execuo de tarefas concorrentes aumentam a
produtividade e diminuem a complexidade do software reduzindo o tempo na
produo do software.
101
___________________________________________________________________
7 APLICAO DO ROTEIRO EM PROJETOS DE

SOFTWARE
Objetivo do Captulo
O objetivo deste captulo apresentar os resultados e as dificuldades encontradas

durante a aplicao do roteiro descrito no Captulo 6 em situaes de
desenvolvimento de projetos permitindo a avaliao sobre os ganhos de tempo
obtidos durante a execuo dos projetos.
7.1. Critrios de Escolha do Projeto
Para escolha dos projetos foi analisado o ambiente de desenvolvimento de software

no ramo de consultoria e vivenciados pelo autor em sua atividade profissional.
Os projetos de software objetos deste estudo so voltados para sistemas de internet
no segmento financeiro, de tamanho mdio, com at oito meses de durao,
utilizando os ciclos de vida de desenvolvimento espiral ou iterativo e com
metodologia orientada a objetos.
Os projetos escolhidos para a avaliao da aplicao do roteiro so apresentados a
seguir:
Projeto 1 - Migrao de Servios Financeiros para a plataforma internet;
Projeto 2 - Desenvolvimento de Aplicaes Internet com integrao com o
legado.
7.2. Caractersticas dos Projetos e Condies de Aplicao
Os projetos avaliados foram desenvolvidos em um ambiente de produo de

software com metodologia de desenvolvimento de sistemas implantada e em uso por
toda a equipe de projeto h mais de trs anos. Tambm possua um processo de
gerenciamento de projetos implantado com base nos padres estabelecidos pelo
PMBOK (Project Management Body of Knowledge) (PMI, 2004).
102
As equipes de projetos eram compostas por um gerente de projeto responsvel pela

coordenao das atividades do projeto, um lder tcnico responsvel pelas decises
arquiteturais, analistas de sistemas especializados em negcio e codificao, alm
de equipes contratadas de empresas terceirizadas para o aumento de escala na
produo do software.
Os projetos avaliados estavam sob as seguintes condies de desenvolvimento,
antes da utilizao das tcnicas e prticas propostas pelo roteiro:
Projeto 1 - Migrao de Servios Financeiros para a plataforma internet:
Utilizao do ciclo de vida cascata e a arquitetura no modelo cliente-servidor. No

processo de desenvolvimento do software no era utilizada a orientao a objetos
e o desenvolvimento baseado em componentes no existia. O reuso era pouco
relevante e a fase de codificao seqencial. A gesto de mudanas era
inexistente e a gesto de riscos estava em fase de implantao.

legado:
O ciclo de vida utilizado era o modelo espiral e a arquitetura definida no padro

MVC (Model-View-Controller). A construo do software utilizava orientao a
objetos, com desenvolvimento baseado em componentes, porm sem a
existncia de um repositrio central de componentes. A taxa de reuso dos
componentes de infra-estrutura (logs, acesso a dados, controle de tempo de
sesso) era alto e o reuso dos componentes de negcio incentivado. A
engenharia simultnea era aplicada na fase de construo respeitando as
parties definidas na fase inicial do projeto. A gesto de mudanas e a gesto de
riscos eram amplamente utilizadas e aplicadas.
Com a utilizao do roteiro, os projetos avaliados foram desenvolvidos utilizando
metodologia orientada a objetos com notao UML (Unified Modeling Language)
(OMG, 2006), arquitetura MVC (Model-View-Controller) e ambiente Java J2EE
(Java 2 Enterprise Edition).
103
7.3. Resultados da Aplicao do Roteiro nos Projetos

Os principais resultados obtidos com a aplicao do roteiro proposto nos projetos
descritos no item 7.2, so apresentados a seguir.
Projeto 1 - Migrao de Servios Financeiros para a plataforma internet:

1) O envolvimento do cliente durante a fase de planejamento permitiu a
validao dos requisitos, do prottipo e a definio da estratgia de
particionamento das entregas de acordo com as expectativas do cliente;
2) O planejamento colaborativo e a aplicao da gesto de riscos durante todo o
processo de desenvolvimento permitiram a aplicao de contingncias e
reservas de tempo estabelecidas no planejamento, bem como verificar e
evitar os impactos nos prazos de entrega;
3) A aplicao da gesto de mudanas foi fundamental para o cumprimento dos
prazos, pois se tratava de um projeto de engenharia reversa de um sistema j
existente que tiveram melhorias identificadas durante a execuo do projeto.
Alm disso, as mudanas foram tratadas como novos projetos que geraram
novas oportunidades;
4) A definio da arquitetura do software e a utilizao da orientao a objetos
viabilizaram a criao de uma biblioteca de componentes de infra-estrutura e
de negcio para a reutilizao neste projeto;
5) A definio da arquitetura, com a criao dos componentes e o reuso
facilitaram a aplicao do desenvolvimento simultneo das parties
planejadas;
6) O desenvolvimento de tarefas concorrentes, em todas as fases do projeto,
proporcionou os maiores ganhos na reduo de tempo no desenvolvimento
do software;
7) Com a reuso dos componentes houve aumento da qualidade do software e a
reduo dos custos atravs da diminuio do nmero de testes;
104
8) Ganhos em escala nos projetos subseqentes com economia de custos e

esforos obtidos com a padronizao da arquitetura, o uso da engenharia
simultnea e o aumento do reuso de componentes;
9) Reduo do tempo de desenvolvimento em aproximadamente vinte e cinco
por cento em relao ao processo anterior.
A Tabela 7.1 mostra alguns parmetros comparativos observados sobre o
processo de desenvolvimento existente e os ganhos obtidos com a utilizao do
roteiro.
Tabela 7.1 Resultados obtidos com a Aplicao do Roteiro no Projeto 1
Nr
Caractersticas
Antes do roteiro
Ganhos aps o roteiro
Gerncia de Mudanas
No existente
Auxlio na limitao do escopo e

manuteno dos prazos.
Gerncia de Riscos
Baixa utilizao
Reduo do retrabalho.
Ciclo de Vida
Cascata
Espiral.
Envolvimento do cliente
Excesso de retrabalho,
Reduo dos conflitos e rapidez
aps a validao do cliente.
nas validaes.
No utilizado
Definio das funes principais
4
5
Timebox
junto com o cliente.

Uso de Prototipao
6
7
Uso limitado de
Aplicao de prottipo evolutivo
prototipao
na fase de requisitos.
Uso apenas na codificao
Uso da engenharia simultnea

desde as fases iniciais.
Desenvolvimento
No utilizado
Componentizado
9
Reutilizao
Definio dos componentes de

negcio e de infra-estrutura.
No existia
Incio do processo de reuso de

componentes
10
11
Prazo do Projeto
Qualidade do Software
Atrasos de 10% a 40% no
Entrega das parties no prazo
prazo planejado.
estabelecido.
Elevado nmero de testes
Melhoria da qualidade do
e suscetibilidade a erros
produto pelo uso de
durante a validao
componentes e pelo nvel de

reutilizao aplicado.
12
Encerramento do
Demora no aceite final do
Aceite realizado durante as
Projeto
cliente.
entregas das parties facilitou o

encerramento do projeto.
105

legado:
1) O planejamento colaborativo trouxe o comprometimento do cliente com as

parties definidas e com a estratgia de desenvolvimento apresentada,
facilitando as validaes e cumprimento dos prazos;
2) Para cada partio foi elaborado e validado um prottipo evolutivo com os
timeboxes definidos durante o planejamento colaborativo;
3) A prototipao de interface foi substituda pela prototipao evolutiva
permitindo o reaproveitamento do cdigo;
4) Como o desenvolvimento baseado em componentes e o reuso j eram
utilizados, os ganhos observados foram em relao ao aumento do reuso de
componentes de negcio e na definio de um responsvel pela administrao
dos componentes;
5) Mesmo com a existncia de um responsvel pelos componentes, ainda no foi
possvel a criao do repositrio central para compartilhamento e divulgao dos
componentes;
6) Neste projeto houve um aumento da contratao de servios de
desenvolvimento terceirizado que foi facilitado pela arquitetura definida e a
existncia de componentes bsicos de infra-estrutura e negcio;
7) A engenharia simultnea foi aplicada em todas as fases do projeto, inclusive
nas
atividades
envolvendo
as
empresas
terceirizadas,
aumentando
escalabilidade de desenvolvimento do software e a reduo de tempo no

desenvolvimento;
8) Reduo do tempo de desenvolvimento em aproximadamente quinze por
cento em relao ao processo anterior.
A Tabela 7.2 mostra alguns parmetros comparativos observados sobre o processo

de desenvolvimento existente e os ganhos obtidos com a utilizao do roteiro.
106
Tabela 7.2 Resultados obtidos com a Aplicao do Roteiro no Projeto 2
Nr
Caractersticas
Planejamento Colaborativo
Antes do roteiro
Ganhos aps o roteiro

Estabelecimento de
Conflitos de prioridades e
atraso nas validaes
prioridades conjuntas e
comprometimento do cliente.
Definio das entregas
Timebox
No utilizado
principais de acordo com o

particionamento estabelecido.
Forte utilizao da
Uso de Prototipao
Prototipao de interface
prototipao evolutiva com o

aproveitamento do cdigo.
Uso na codificao
Aplicao em todas as fases

do desenvolvimento.
Ampliao da criao de
Desenvolvimento baseado em
componentes de negcio e na
Utilizado
componentes
definio de um responsvel
pelos componentes.
Reutilizao
Aumento do reuso de
Utilizado
componentes de negcio.
Aumento de escala atravs da
Uso de Desenvolvimento
definio da arquitetura,
Limitado
Terceirizado
existncia de componentes e
reutilizao do software.
Com a caracterstica especfica desse projeto em utilizar equipes terceirizadas

para aumentar a escala de desenvolvimento pde ser observado que a definio
do maior nmero possvel de parties independentes e da arquitetura de
software so pr-requisitos para criar as condies necessrias para o
desenvolvimento
concorrente
aumentar
nvel
de
reutilizao
dos
componentes.
Com a aplicao do roteiro proposto foram verificados resultados tangveis em
relao reduo de tempo no desenvolvimento de software, no aumento da
produtividade e no controle da complexidade do software.
107
7.4. Dificuldades Encontradas na Aplicao do Roteiro
Durante a execuo do roteiro em ambos os projetos descritos no item 7.3 foram

observadas dificuldades na assimilao dos conceitos propostos, na confiana da
equipe de projeto sobre a execuo de maior nmero de tarefas concorrentes, na
criao do repositrio de componentes, nos resultados efetivos do reuso e na correta
utilizao da orientao a objetos.
As principais dificuldades verificadas durante a aplicao do roteiro podem ser
divididas em duas vises: viso da equipe de projeto e a viso do cliente.
As principais dificuldades encontradas durante a aplicao do roteiro so
apresentadas a seguir, podendo variar de acordo com os nveis de maturidade da
equipe de projeto e do cliente.
a) Dificuldades encontradas com a equipe de projeto:
1) Dificuldade na mudana do ciclo de desenvolvimento A mudana do

ciclo de desenvolvimento tradicional encontrou resistncia nas equipes
acostumadas no processo que dominavam no dia-a-dia da produo de
software;
2) Riscos na aplicao da Engenharia Simultnea A equipe do projeto

tendeu a manter a estratgia de desenvolvimento seqencial at a
codificao, por considerar a aplicao da engenharia simultnea nas fases
iniciais do projeto como um risco desnecessrio;
3) Falta de um repositrio central de componentes A orientao para o

desenvolvimento baseado em componentes no foi suficiente para sua
aplicao dentro do projeto, pois sem a facilidade de consulta e obteno dos
componentes e da documentao de utilizao a equipe tendeu a criar seus
prprios componentes;
4) Resistncia ao reuso Aliada a falta do repositrio central de componentes,

a resistncia ao reuso foi outra dificuldade encontrada em funo da falta de
108
confiana dos membros das equipes nos componentes desenvolvidos por

outras equipes ou pela m qualidade da documentao desses componentes;
5) Falta de eficincia do processo de comunicao O processo formal

estabelecido causou dificuldades na interao entre os membros da equipe,
afetando a sincronizao e acompanhamento das tarefas concorrentes.
b) Dificuldades encontradas com o cliente:
1) Falta de participao de todos os envolvidos do cliente Como o cliente

possua vrias reas interessadas ligadas ao projeto, a ausncia de uma
dessas reas causou problemas na validao dos produtos e na estratgia de
desenvolvimento do projeto;
2) Resistncia do cliente em realizar as reunies de kickoff A reunio de

kickoff foi um dos principais elementos de comunicao do projeto e a falta de
entendimento de sua finalidade pelo cliente reduziu os benefcios que esta
tcnica poderia trazer ao projeto;
3) No aceitao da incorporao das mudanas posteriores s entregas

O cliente solicitou mudanas durante todo o projeto e insistiu que fossem
includas na verso que estava sendo desenvolvida. A falta de formalizao
de um processo de gesto de mudanas e a clareza no procedimento de
incorporao de novos requisitos gerou conflitos entre a equipe de projeto e o
cliente;
4) Resistncia do cliente em receber e validar as entregas parciais Mesmo

tendo participado do planejamento e aprovado a estratgia do projeto, o
cliente no aceitou realizar as validaes das entregas parciais do sistema,
aguardando que todas as entregas fossem realizadas para proceder sua
validao;
109
5) Falta de eficincia do processo de comunicao A falta de comunicao

em todos os nveis dos envolvidos no projeto, causou conflitos e alterou as
expectativas do cliente em relao s mudanas que ocorreram durante o
projeto.
Considerando as dificuldades encontradas durante a aplicao do roteiro foram

executadas aes corretivas com o objetivo de diminuir ou eliminar seus efeitos,
conforme apresentado nas Tabelas 7.3 e 7.4.
Essas aes corretivas tiveram resultados satisfatrios durante a realizao dos
projetos descritos no item 7.3, proporcionando melhor entendimento dos objetivos e
a consolidao das tcnicas e prticas propostas pelo roteiro.
As aes junto aos clientes tambm atenderam s expectativas, porm dependem
do relacionamento estabelecido com a equipe de projeto, pois seus efeitos esto
diretamente associados aceitao por parte do cliente e ao nvel de maturidade no
desenvolvimento de software em que ele se encontra.
Tabela 7.3 Aes Corretivas para tratar as Dificuldades encontradas com a Equipe de Projeto
Dificuldades
Aes Corretivas
1 Dificuldade na mudana do ciclo de Treinamento e mentoring com a equipe mostrando

desenvolvimento.
Riscos
na
as vantagens do modelo iterativo.
aplicao
da
engenharia Treinamento e mentoring com a equipe e uso
2 simultnea.
moderado de tarefas concorrentes na fase de

construo.
3 Falta
de
Repositrio
componentes.
central
de Formalizao do desenvolvimento baseado em

componentes com o incio da criao do repositrio
de componentes e a definio de um responsvel
pelo gerenciamento do mesmo.
4 Resistncia ao reuso.
Com a melhoria da qualidade e a reduo do nmero

de testes foi possvel mostrar os benefcios do uso
de componentes e a melhoria da produtividade.
5 Falta
de
eficincia
comunicao.
no
processo de Realizao de reunies rpidas para compartilhar as

informaes e verificar o status de andamento das
atividades do projeto.
110
Tabela 7.4 Aes Corretivas para tratar as Dificuldades encontradas com o Cliente
Dificuldades
1 Falta
de
participao
de
Aes Corretivas
todos
envolvidos do cliente.
os Realizao de reunies apresentando informaes

histricas de problemas ocorridos em outros projetos
pela falta de participao dos envolvidos nos projetos.
Resistncia do cliente na realizao de Reunies

2 reunies de kickoff.
com
apresentao
das
vantagens
objetivos esperados com o kickoff.
3 No aceitao de incorporao das Apresentao dos impactos nos prazos das entregas,
mudanas posteriores s entregas.
caso
as
mudanas
fossem
incorporadas
imediatamente.
4 Resistncia em receber e validar as Criao de parties que permitam a avaliao de um
entregas parciais.
ciclo de negcio completo pelo cliente.
5 Falta de eficincia no processo de Realizao de reunies de kickoff nas principais

comunicao.
mudanas do projeto e entre as fases para o

alinhamento das expectativas de prazo com o cliente.
Neste captulo foram descritas os principais resultados obtidos com a aplicao do

roteiro e as dificuldades encontradas durante sua utilizao em dois projetos de
software.
As dificuldades encontradas so limitaes para a aplicao do roteiro e foram
tratadas conforme as aes corretivas descritas nas Tabelas 7.3 e 7.4 durante a
execuo dos projetos apresentando resultados satisfatrios durante o processo de
Os resultados obtidos com a aplicao do roteiro nos projetos apresentados no item
7.3 mostram que a utilizao das tcnicas e prticas propostas pelo roteiro podem
reduzir o tempo no desenvolvimento do software, dependendo do nvel de
maturidade em que se encontra o processo de desenvolvimento da empresa, a
maturidade e o conhecimento da equipe de projeto e do nvel de envolvimento do
cliente.
111
___________________________________________________________________
8 CONSIDERAES FINAIS
Objetivo do Captulo
O objetivo deste captulo apresentar as concluses e as contribuies deste

trabalho, bem como descrever os aspectos positivos e as dificuldades encontradas
na aplicao do roteiro para a reduo do tempo de desenvolvimento de software.
Tambm so descritos possveis trabalhos futuros que podem ser desenvolvidos a
partir dos assuntos aqui discutidos.
8.1. Resumo das Contribuies do Trabalho
O roteiro proposto para a reduo de tempo no desenvolvimento de software

apresentado neste trabalho, mostra de forma ordenada e interdependente, a
utilizao das prticas e tcnicas de engenharia de software com o objetivo de
permitir s empresas realizarem o desenvolvimento de um projeto em tempo
reduzido e com maior produtividade.
Nas avaliaes realizadas com a utilizao do roteiro, os seguintes aspectos
positivos devem ser destacados:
1. A aplicao ordenada e conjunta das prticas e tcnicas de engenharia de

software propostas por este trabalho permite a construo dos projetos de
software em um menor espao de tempo;
2. A participao efetiva do cliente durante o planejamento e da definio da

estratgia da soluo permite a priorizao adequada das parties e do
atendimento dos requisitos principais dentro do prazo estabelecido;
3. Durante a definio das parties deve-se procurar diminuir ao mximo o

acoplamento
entre
elas,
desenvolvimento concorrente;
visando
aumentar
as
possibilidades
de
112
4. A utilizao da prototipao evolutiva, de acordo com os padres de

codificao e alinhada tecnologia na qual o projeto ser desenvolvido
permite obter ganhos no tempo de desenvolvimento;
5. A definio da arquitetura de software deve priorizar a reduo da

complexidade e o desacoplamento entre os elementos de software, pois ser
a base para viabilizar a engenharia simultnea, o desenvolvimento baseado
em componentes e o reuso;
6. A aplicao da engenharia simultnea desde as fases iniciais do projeto,

constitui um fator relevante para a reduo do tempo de desenvolvimento e o
aumento da produtividade;
7. Alm da questo da reduo do tempo de desenvolvimento, a definio dos

timeboxes e a aplicao da gesto de mudanas durante a construo do
software possibilitam a entrega dos produtos dentro do prazo estabelecido;
8. A utilizao de equipes reduzidas no projeto melhora a comunicao e facilita

a reutilizao dos componentes;
9. Atravs da estrutura definida pelo roteiro possvel aumentar a escala de

desenvolvimento
com
utilizao
de
servios
terceirizados,
sem
comprometer a qualidade do software produzido.
No entanto, durante a aplicao do roteiro alguns fatores crticos que afetam a

execuo do projeto foram observados e devem ser tratados previamente para
potencializar os resultados:
1. O alto grau de paralelismo das atividades no projeto necessita de maior

controle gerencial para a coordenao das atividades e de um alto nvel de
comunicao dentro da equipe do projeto;
113
2. A resistncia ao reuso de componentes um problema cultural dos

desenvolvedores e deve ser tratada com especial ateno antes da utilizao
do roteiro;
3. A implantao do repositrio de componentes deve preceder aplicao do

roteiro, pois maximiza o nvel de reutilizao e auxilia na cultura da equipe de
projeto;
4. As prticas e tcnicas discutidas no roteiro so aplicveis a qualquer estilo de

linguagem. Porm, a no utilizao de linguagens orientadas a objetos pode
trazer maiores dificuldades em sua aplicao, especialmente em relao ao
desenvolvimento baseado em componentes e reutilizao;
5. A resistncia do cliente em participar das definies do planejamento e da

estratgia da soluo prejudica a aplicao do roteiro, uma vez que no se
obtm o comprometimento adequado no processo de desenvolvimento;
6. A incorporao das
mudanas de requisitos
detectadas
durante o
desenvolvimento das parties j definidas compromete o cumprimento dos

prazos.
8.2. Concluses do Trabalho
Este trabalho apresentou um roteiro que rene e organiza tcnicas e prticas de

engenharia de software com o objetivo de criar condies que permitam a reduo
no tempo de desenvolvimento de projetos de software.
A arquitetura de software a base para a implementao do roteiro criando as
condies de escalabilidade e flexibilidade necessria para a definio do
particionamento do sistema, do desenvolvimento baseado em componentes e da
reutilizao e na maximizao das atividades concorrentes no processo de
114
Outro aspecto importante o planejamento colaborativo que permite o alinhamento

das expectativas do cliente com a equipe do projeto em relao a como o software
ser construdo e avaliado por todos os envolvidos.
A engenharia simultnea a prtica que mais contribui para a reduo de tempo na
construo do software. Para tanto, o planejamento e a arquitetura devem direcionar
a soluo para permitir o mximo de desacoplamento entre as parties a serem
desenvolvidas.
Nos experimentos realizados, a aplicao do roteiro proposto mostrou-se eficaz na
reduo do tempo de desenvolvimento de software, na reduo da complexidade e
no aumento da produtividade da equipe do projeto. Porm, outros tipos de projeto ou
situaes peculiares que no foram observadas durante este estudo podem gerar
novos requisitos que necessitariam de estudos complementares para futuras
adequaes. No entanto, as caractersticas do roteiro proposto so genricas e
flexveis
para
eventuais
adequaes
necessidades
especficas
de
desenvolvimento de projetos de software.
8.3. Trabalhos Futuros
Alguns aspectos no abordados neste trabalho podem ser desenvolvidos com o

objetivo de expandir as discusses sobre a reduo no tempo de desenvolvimento
de software e serem objeto de trabalhos futuros:
1. Aplicao do roteiro proposto em outras situaes de projeto, com a finalidade

de verificar possveis ajustes e melhorias nas atividades propostas;
2. Enquadramento do roteiro a uma metodologia de desenvolvimento de

software para avaliao da sua flexibilidade de adequao aos processos
existentes nas empresas;
3. Verificao atravs de pesquisas e questionrios dos resultados obtidos em

empresas que utilizaram o roteiro, para avaliao complementar de sua
eficcia na reduo do tempo de desenvolvimento;
115
4. Implementao do roteiro em empresas de desenvolvimento de software com

o objetivo de estabelecer medidas de ganhos na reduo de tempo e
indicadores de melhoria contnua no processo de desenvolvimento de
software.
5. Criao de novos roteiros a partir do mapeamento dos conceitos que
impactam na reduo de tempo no desenvolvimento de softwares ilustrados
na Figura 6.1 com outras tcnicas ou prticas de engenharia de software que
auxiliem na reduo de tempo no desenvolvimento de software
116
___________________________________________________________________
REFERNCIAS BIBLIOGRFICAS
AMUNDSEN, M; HUTCHISON, K, A Synergistic Approach to Concurrent

Engineering, ACM, 1990.
BASS; CLEMENTS; KAZMAN, Software Architecture in Practice, 2. Edio.

New York: Ed. Addison-Wesley, 2003.
BERSOFF, E; DAVIS, A, Impacts of Life Cycle Models on Software, ACM,
1991.
BLACKBURN, J; SCUDDER, G; WASSENHOVE, L, Concurrent Software
Development, ACM, 2000.
BOEHM, B, Software Architecture: Critical Success Factors and Cost Driven,
ACM, 1994.
BOEHM, B; TURNER, R, Balancing Agility and Discipline: A Guide for the

Perplexed. Boston: Ed. Pearson, 2004.
BOYD, W, Pesquisa Mercadolgica. 7a edio. Rio de Janeiro: Ed. Fundao
Getlio Vargas, 1987.
BROOKES, N.J; BACKHOUSE, C.J, Implementing Concurrent Engineering in
Different Environment: Factors for Success, ACM, 2000.
CLINCY, V, Software Development Productivity and Cycle Time Reduction,

ACM, Consortium Computing Sciences in Colleges, 2003.
COLLIER, K; COLLOFELLO, J, Issues in Software Cycle Time Reduction,

IEEE, 1995.
117
DWIVEDI, S; SHARAN, R, Concurrent Engineering Why and What ?, ACM,

1990.
GARLAN D, Software Architecture: a Roadmap. In: International Conference on
Software Engineering. Ireland, 2000. Anais. New York: ACM Press, 2000. P.91
101.
HOFMEISTER, C; KRUCHTEN, P; NORD, R, Generalizing a Model of Software

Architecture Design from Five Industrial Approaches, IEEE, 2005.
HOWARD, A, Rapid Application Development: Rough and Dirty or Value-for

Money Engineering, Communications of the ACM, 2002.
IEEE 1471-2000, Recommended Practice for Architectural Description of

Software -Intensive Systems, 2000.
ISO/IEC 12207, Software Life Cycle Processes, 1995.

ISO/IEC 9126, Quality Characteristics and guidelines for their use, 1991.
ISO/IEC 14598-2, Software production evaluation. Planning and management,
2000.
ISO/IEC 14598-3, Software production evaluation. Process for developers,
2001.
KARANDIKAR, H; FOTTA, M, Assessing Organizational Readiness for
Implementing Concurrent Engineering Practices and Collaborative
Technologies, IEEE, 1993.
KENT, S; HOWSE, J; LAUDER, A, Modeling Software Components, University

of Brighton, Reino Unido, 1999.
118
KERZNER, Software Architecture in Practice, 2. Edio, Boston: Ed. Addison

Wesley, 2003.
KIRK, D, A Flexible Software Process Model, IEEE, 2004.
KRUTCHEN, P, The Rational Unified Process: An Introduction, 2. Edio,

New Jersey: Ed. Addison Wesley, 2000.
LUQI, Software Evolution Through Rapid Prototyping, IEEE, 1989.
MARTIN, J, Rapid Application Development. Nova York: Ed. Macmillan, 1991.
McCONNELL, S, Rapid Development: Taming Wild Software Schedule. So

Paulo: Ed. Microsoft Press, 1996.
MCT WEB SITE, Ministrio da Cincia e Tecnologia Secretaria de Poltica de

Informtica, Produtividade e Qualidade do Software Brasileiro, Braslia, 2002,
disponvel em: <http://www.mct.gov.br/Temas/info/Dsi/Quali2001/remtab2001.htm>.
Acesso em: 30 jan 2006.
OMG WEB SITE, Object Management Group. Processos e Padres sobre

Orientao a Objetos e UML (Unified Modeling Language), disponvel em:
<http://www.omg.org>. Acesso em: 16 nov 2006.
PARK, Y, Organizing and Retrieving Class Components based on Types for

Reuse, ACM, 1999.
PINNA, C. A, Um Roteiro Centrado em Arquitetura para Minimizao de Riscos

e Incertezas em Projetos de Software, Dissertao de Mestrado Escola
Politcnica, Universidade de So Paulo, So Paulo, 2004.
PMI, PMBOK Guide A Guide of the Project Management Body of

Knowledge. Pennsylvania, 2004.
119
PRESSMAN, R. S., Software engineering: A Practitioners Approach,

6a. Edio, New York: McGraw-Hill, 2005.
PYSTER, A, Software Development Productivity, ACM, 1982.
RAVICHANDRAN, T; ROTHENBERGER, A, Software Reuse Strategies and

Component Markets, Communications of the ACM, 2003, Volume 46, Nr 8.
RIBEIRO, A; ARAKAKI, R, Proposta de um Roteiro para a Reduo do Tempo

de Desenvolvimento em Projetos de Software, in: SUCESU 7o Seminrio de
Gesto de Projetos, So Paulo, 2005. Anais. So Paulo, 2005b.
RAN, A, Fundamental Concepts for Practical Software Architecture, ACM,

2001.
SADOU, N; TAMZALIT, D; OUSSALAH, M, A unified Approach for Software

Architecture Evolution at different abstraction levels, 8o International Workshop
on Principles of Software Evolution (IWPSE05), 2005, p. 65-70.
SEI WEB SITE Software Engineering Institute. Pittsburgh, Capability Maturity

Model Integration, disponvel em: <http://www.sei.cmu.edu/cmmi>. Acesso em: 15
nov 2006.
STANDISH GROUP, Chaos Research Report, West Yarmouth, Massachusetts,

USA, 2004, disponvel em:
<http://www.standishgroup.com/sampleresearch/PDFpages/extremechaos.pdf>.
Acesso em: 30 jan 2006.
SUBRAMANIAN, N; CHUNG, L, Relationship between the Whole of Software

Architecture and its Parts: An NFR Perspective, 6o International Conference on
Software Engineering, 2005.
120
SMITH, R P, The Historical Roots of Concurrent Engineering Fundamentals,

IEEE, 1997.
VITHARANA, P, Risks and Challenges of Component-Based Software

Development, Communications of the ACM, 2003, Volume 46, Nr 8.
WETHERBE, J; FROLICK, M, Cycle Time Reduction: Concepts and Case
Studies, ACM, 2000.
YOU-SHENG; YU-YUN, Architecture-Based Software Process Model, ACM,
2003.
121
___________________________________________________________________
ANEXO 1 - QUESTIONRIO APLICADO NA ENQUETE

Questo
1
Defina o ramo de atividade de
R-1
R-2
R-3
R-4
R-5
Consultoria
Indstria
Telecom
Finanas
Outras
At 50
50 a 100
100 a
1000 a
Mais de
1000
2000
2000
sua empresa:
2
Qual o nmero de funcionrios

de sua empresa?
Sua empresa possui alguma das
ISO9000
CMM
CMMI
SPICE
Nvel 2
Nvel 3
Nvel 4
Nvel 5
Sim
No
No possui
Pouco
Utilizado
Utilizado
Sempre
certificaes?
4
Se possuir CMM ou CMMI, qual

o nvel em que se encontra?
Sua empresa possui

profissionais certificados PMP?
Sua empresa utiliza algum

processo de Gesto de Projetos
estabelecido?
Responda s questes abaixo em relao ao processo de Gesto de Projetos utilizado pela

sua empresa:
6.1 Qual mtrica utilizada para
Nenhum
mensurao dos projetos?
Pontos de
Pontos
funo
de casos
Outros
de uso
6.2 O projeto particionado para
reduzir a complexidade?
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
6.3 A gesto de riscos realizada

durante todo o projeto?
6.4 Existe um processo de gesto de
mudanas de requisitos?
6.5 Durante a execuo do projeto,

qual a freqncia de reunies
A cada 15
Por
Por Semana
dias
Por ms
produto
No utiliza
Iterativo
Espiral
Cascata
Anlise
Formaliza
de
Gesto de
Riscos
Mudanas
de acompanhamento com o
cliente?
7
Qual metodologia para o

desenvolvimento de projetos de
software utilizada?
Na fase de planejamento do
projeto, sua empresa gera quais
dos artefatos listados abaixo?
Cronograma
EAP
122
Reunies de kickoff so realizadas no incio do projeto e de cada fase para alinhar as

expectativas dos envolvidos e para a formalizao do planejamento do projeto. Com base
nesta afirmativa, responda s questes 9 e 10
9
No incio do projeto realizada

uma reunio de kickoff com o
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
cliente ?
10
Nas demais fases do projeto a

reunio de kickoff realizada ?
TimeBox uma tcnica que tem como objetivo enquadrar as caractersticas principais do
projeto restrio do tempo estabelecido para o projeto, permitindo o atendimento das
mesmas na prioridade necessria para o atendimento dos prazos. Com base nesta afirmativa
responda questo 11:
11
Sua empresa conhece ou

utiliza a prtica denominada
No
conhece
Conhece e Utiliza s
Utiliza
no usa
vezes
sempre
Utiliza s
Utiliza
vezes
Sempre
Prottipo
Prottipo
Ambos os
de
Evolutivo
prottipos
TimeBox?
12
Sua empresa utiliza a tcnica

de prototipao no
No utiliza
desenvolvimento de software?
13
Qual tcnica de prototipao

aplicada nos projetos de
Nenhuma
14
Interface
O cliente participa efetivamente

das validaes de todos os
Nunca
Sempre
s vezes
artefatos desenvolvidos ?
15
Se as respostas das questes de 9 a 14 foram respondidas como Sempre, responda

s questes 15.1 e 15.2:
15.1 Houve reduo dos conflitos de

escopo com o cliente?
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
No
Sim
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
15.2 Foi verificado pela sua empresa

melhorias no cumprimento dos
prazos estabelecidos com o
cliente ?
16
Sua empresa utiliza orientao

a objetos?
17
Sua empresa utiliza o modelo

MVC (Model-View-Controller)
na arquitetura para
18
A arquitetura de implementao
da aplicao definida nas
123
fases iniciais do projeto?

19
A fase de projeto orienta o

desenvolvimento de
Nunca
Sempre
s vezes
No
Informal
Formal,
Formal com
sem
processo
componentes para a
reutilizao?
20
O reuso de componentes
difundido em sua empresa de
difundida
que forma?
21
processo
Qual o nvel de reutilizao

utilizado em sua empresa?
Nenhum
Dentro de
Entre
um projeto
vrios
Na empresa
projetos
22
Se as respostas de 16 a 19 foram respondidas como Sempre, responda s questes

22.1 a 22.4:
22.1 Houve melhoria da qualidade

do software?
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
22.2 Existiram ganhos de

produtividade, permitindo a
reduo do tempo de
desenvolvimento?
22.3 Houve reduo de retrabalho
nas fases finais do projeto?
22.4 Auxiliou no cumprimento do
prazo com o cliente?
A Engenharia simultnea (ES) uma tcnica que permite o planejamento da execuo de

atividades em paralelo durante o ciclo de desenvolvimento do software. Com base nesta
afirmativa, responda as questes abaixo:
23
No desenvolvimento de
software sua empresa utiliza
No
Conhece e Utiliza s
conhece
no usa
vezes
Sempre
Requisitos
Anlise
Projeto
Cdigo
No
Sim
Nunca
Sempre
s vezes
Nunca
Sempre
s vezes
Engenharia Simultnea?
24
Em que fase do ciclo de

produo a Engenharia
Simultnea aplicada ?
25
A ES na fase de codificao
aplicada baseada no reuso?
26
Com a aplicao da ES foram

verificados ganhos de
produtividade nos projetos?
27
Com a aplicao da ES houve

reduo do tempo de
desenvolvimento do software?
Testes
124

Roteiro de Redução de Tempo

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Roteiro de Redução de Tempo

Hochgeladen von

Copyright:

Verfügbare Formate

ANDR LUIZ DIAS RIBEIRO

UM ROTEIRO PARA A REDUO DE TEMPO NO

ANDR LUIZ DIAS RIBEIRO

UM ROTEIRO PARA A REDUO DO TEMPO NO

Dissertao apresentada Escola

ANDR LUIZ DIAS RIBEIRO

UM ROTEIRO PARA A REDUO DO TEMPO NO

Dissertao apresentada Escola

Aos meus pais e irmos pela base de conhecimento, perseverana e dignidade na

Ao amigo e orientador Reginaldo Arakaki pelo incentivo, apoio e diretrizes essenciais

A todos que, direta ou indiretamente, colaboraram na execuo deste trabalho, em

Palavras-Chaves: Engenharia de Software, Reduo de Tempo, Arquitetura de

Keywords: Software Engineering, Cycle Time Reduction, Software Architecture,

4 ABORDAGENS PARA A REDUO DE TEMPO NO DESENVOLVIMENTO

8 CONSIDERAES FINAIS........................................................................................ 111

O objetivo deste captulo apresentar os motivos que levaram ao desenvolvimento

1.1. O Problema do Tempo no Desenvolvimento de Software

Com o avano da tecnologia e com o aumento da competitividade no mercado, os

implementao de solues que eliminem ou minimizem seus efeitos na produo

1) Falta de motivao da equipe;

A alternativa mais utilizada pelas empresas para eliminar os efeitos destas

manuteno e portabilidade na viso do usurio sobre a avaliao da qualidade do

Embora estes trabalhos forneam procedimentos e processos que permitam

A realizao de projetos dentro do prazo estabelecido um fator comum em

conhecimento da maioria das empresas de desenvolvimento, estas no utilizam ou

A motivao deste trabalho mostrar que as tcnicas de engenharia de software

1.3. Justificativa do Trabalho

O aumento da produtividade e a reduo do tempo de desenvolvimento de software

desenvolvimento do software. As caractersticas do produto esto relacionadas ao

Sobre esse ambiente e abordagens citadas para reduo de tempo no

1.4. Objetivos do Trabalho

O principal objetivo deste trabalho elaborar um roteiro que rena e organize as

1.5. Organizao do Trabalho

Este trabalho foi organizado em sete captulos conforme representao esquemtica

No Captulo 1 so apresentados os motivos que levaram o desenvolvimento deste

No Captulo 4 so apresentadas as principais iniciativas existentes sobre a reduo

Roteiro para Reduo

Figura 1.1 Representao grfica da organizao do trabalho

1.6. Notaes e Convenes Utilizadas

As tabelas e figuras que no possuem referncia foram desenvolvidas pelo autor

O objetivo deste captulo descrever a importncia do planejamento no

2.1. A Importncia do Planejamento de Projetos

O planejamento uma das principais atividades a ser realizada na concepo de um

1. Incio do projeto sem a definio dos requisitos;

3. Decepo com os resultados no alcanados;

Para evitar estas conseqncias, deve ser elaborado um planejamento adequado

A seguir so descritos resumidamente os processos de planejamento de acordo com

responsabilidades da equipe do projeto;

14 Planejamento de Riscos: Define como os riscos sero gerenciados durante o

Eliminar e reduzir as incertezas;

Obter melhor entendimento dos objetivos;

Prover a base para o monitoramento e controle do trabalho;

Melhorar a eficincia da operao.

Figura 2.1 Grupo de Processos de Planejamento do PMBOK (PMI, 2004)

2.2. Monitoramento e Controle do Projeto

Embora o planejamento seja importante para a realizao de um projeto, o controle

Segundo o PMBOK (2004), o grupo de processos de monitoramento e controle tem

Figura 2.2 Interaes entre os Processos de Controle do PMBOK (PMI, 2004)

As atividades de monitorao e controle realizadas durante o desenvolvimento do

Para a realizao dessas atividades, os seguintes processos so previstos pelo

1 Monitorar e Controlar o Projeto: o processo responsvel por coletar, medir e

Figura 2.3 Atividades de Planejamento e Controle de Projeto (Kerzner, 2003)

A partir da definio das metas e objetivos so definidos os pacotes de trabalho da

qualidade dos produtos a serem entregues ao cliente. Os relatrios de desempenho