universidade do sul de santa catarina daniel …pergamum.unisul.br/pergamum/pdf/94307_daniel.pdf ·...
TRANSCRIPT
UNIVERSIDADE DO SUL DE SANTA CATARINA
DANIEL PROCHNOW
HUINDSON JOSÉ DA SILVA
MELHORIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – ESTUDO DE CASO
Palhoça
2008
DANIEL PROCHNOW
HUINDSON JOSÉ DA SILVA
MELHORIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – ESTUDO DE CASO
Trabalho de Conclusão de Curso do curso de Ciência da Computação e Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel de Ciência da Computação e Sistemas de Informação.
Orientadora: Vera Rejane Niedersberg Schuhmacher,M.Sc.
Palhoça
2008
DANIEL PROCHNOW
HUINDSON JOSÉ DA SILVA
MELHORIA DE QUALIDADE NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE – ESTUDO DE CASO
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Ciência da Computação e Sistemas de Informação e aprovado em sua forma final pelo Curso de Ciência da Computação e Sistemas de Informação, da Universidade do Sul de Santa Catarina
Palhoça, 10 de junho de 2008
_________________________________________ Prof. e orientadora Vera Rejane Niedersberg Schuhmacher, M.Sc.
Universidade do Sul de Santa Catarina
_________________________________________ Convidado Marcelo Sartor, M.Sc.
Universidade do Sul de Santa Catarina
_________________________________________ Prof. Maria Inés Castiñeira, M.Sc.
Universidade do Sul de Santa Catarina
Dedico este trabalho a minha família, que sempre me apoiou, acolheu, amou e por estarmos sempre juntos.
Daniel
Dedico este trabalho a minha família, que sempre esteve ao meu lado em todos os momentos de minha vida.
Huindson
AGRADECIMENTOS
Daniel Prochnow
Obrigado, a todos que de alguma forma ajudaram a alcançar este objetivo.
Obrigado ao todos meus colegas de trabalho que sempre compartilharam
comigo a alegria e o prazer de trabalhar na Procel e correr juntos à um objetivo.
Também obrigado aos colegas/amigos/diretores/pai/etc... Bruno, Geraldo,
Celso, Christian e Jean, por todos estes anos de luta, parceria, reuniões, discussões,
crescimentos, e por compartilhar comigo todo este delicioso e apaixonante stress de
fazer a empresa crescer.
Obrigado ao meu colega de monografia Huindson, pela parceria e pela
sincronia nesta empreitada.
Obrigado a toda minha família e meus amigos que sempre me
incentivaram a concluir esta (longa!!) fase da minha vida.
A minha esposa Tatiane, por entender todas muitas ausências, por me
incentivar incondicionalmente, por me ajudar de todas as formas que estavam a seu
alcance e por me fazer tão feliz.
Obrigado, obrigado e obrigado, ao meu pai, por formar quem eu sou, por
me ajudar a chegar onde cheguei, por cada bronca ou sermão, por estender sua
mão mesmo após eu tropeçar feio por não tê-lo escutado, por vinte anos trabalhando
lado a lado em parceria e perfeita simetria. Mais uma vez obrigado.
Obrigado a todos os professores que auxiliaram em nossa formação
profissional e especialmente a nossa querida professora e orientadora Vera, pela
sua sabedoria, paciência e afeto.
E finalmente a Deus, por me dar força e sabedoria para vencer todos os
deliciosos desafios da vida.
Huindson José da Silva
Agradeço a toda minha família em especial a minha esposa e filho, pela
compreensão demonstrada por eles nos momentos em que não estive presente
durante todo o período acadêmico, foram muitos dias chegando mais tarde em casa,
além das tardes de sábado estudando, principalmente durante a elaboração desta
monografia.
Obrigado a todos os professores pelo conhecimento que adquiri ao longo
desses anos na universidade. Momentos que me fizeram refletir e chegar a
conclusão que juntamente com o conhecimento prático, o conhecimento teórico
passado na faculdade consolida nosso aprendizado.
Agradeço também a meu companheiro de monografia, que apesar de
muitas vezes divergirmos em alguns pontos de vista, não nos faltou força de vontade
e determinação, para que chegássemos a conclusão deste trabalho acadêmico.
.
RESUMO
Esta monografia apresenta um estudo sobre a melhoria de qualidade no processo de
desenvolvimento de software, na forma de um estudo de caso aplicado em uma
empresa de desenvolvimento de software. Foram estudadas metodologias de
desenvolvimento de software, padrões de desenvolvimento, técnicas, métodos e
conceitos relacionados a qualidade. A partir do estudo detalhado do ambiente da
empresa e seus processos atuais de controle, foi feita a descrição dos problemas
identificados. Com base na análise desses problemas, foram propostas soluções
para cada problema, que foram implementadas pela empresa com o
acompanhamento dos autores, obtendo resultados práticos positivos conclusivos.
Palavras-chaves: Qualidade, Processo de Desenvolvimento de Software,
Metodologias de Desenvolvimento de Software
ABSTRACT
This monograph presents a study of the quality improvement in a software
development process, on a study case applied in a software development company.
Methodologies of software development, standards of development, techniques,
methods and concepts related to quality had been studied. From the detailed study of
the companies environment and its current control processes, a complete
specification of the identificated problems was made. Based on the analysis of the
problems, solutions for each problem had been proposed, and had been
implemented by the company, with the accompaniment of the authors, getting
positive and conclusive practical results.
Key words: Quality, Process of Development of Software, Methodologies.
LISTA DE ILUSTRAÇÕES
Figura 1 – Principais fatores da qualidade de produtos de software .........................28
Figura 2 – Logotipo do Mps-Br ..................................................................................31
Figura 3 – Base para formação do modelo de referencia MPS BR...........................32
Figura 4 – Componentes do Mps-Br .........................................................................33
Figura 5 – Conceitos básicos do RUP.......................................................................36
Figura 6 – Visão Geral do RUP.................................................................................37
Figura 7 – As fases e os marcos de um projeto do RUP..........................................39
Figura 8 – Ciclo de desenvolvimento do RUP...........................................................39
Figura 9 – Fluxos de processo do Scrum..................................................................48
Figura 10 – Fases para a metodologia de desenvolvimento: ....................................55
Figura 11 – Setor de desenvolvimento......................................................................60
Figura 12 – Setor de implantação .............................................................................61
Figura 13 – Setor de suporte.....................................................................................62
Figura 14 – Tela principal do CO...............................................................................64
Figura 15 – Tela de edição de um chamado .............................................................65
Figura 16 – Formulário principal do Jedi ...................................................................66
Figura 17 – Formulário de Check Out .......................................................................66
Figura 18 – Fluxo de processo utilizando a fila de desenvolvimento.........................77
Figura 19 – Simulação de fila de desenvolvimento ...................................................78
Figura 20 – Simulação de fila de desenvolvimento com indicação de técnico ..........78
Figura 21 – Fluxo para alteração de prioridade dos chamados da fila de
desenvolvimento .......................................................................................................79
Figura 22 – Alteração de prioridade utilizando o mouse ...........................................79
Figura 23 – Fluxo para determinação do tempo previsto ..........................................80
Figura 24 – Formulário de Check Out .......................................................................81
Figura 25 – Gráfico de chamados atendidos.............................................................82
Figura 26 – Gráfico de rendimento dos desenvolvedores .........................................83
Figura 27 – Fluxo de verificação de padronização ....................................................84
Figura 28 – Diff/Merge do Jedi, comparando duas versões de código fonte.............86
Figura 29 – Fluxograma para atendimento dos chamados do Desenvolvimento......98
Figura 30 – Fila de Desenvolvimento do CO...........................................................109
Figura 31 – Opção Obter Chamado do CO.............................................................110
Figura 32 – Horas realizadas do CO.......................................................................111
Figura 33 – Tempo previsto para execução em chamados do CO .........................112
Figura 34 – Gráfico de chamados em desenvolvimento .........................................113
Figura 35 – Gráfico de Chamados atendidos..........................................................114
Figura 36 – Acesso a documentações através do CO ............................................115
Figura 37 – Capítulo sobre preparação de estação de trabalho..............................116
Figura 38 – Lista de prefixos da nomenclatura de objetos ......................................117
Figura 39 – Regra sobre escrita de comentários.....................................................118
Figura 40 – Versões dos chamados relacionadas ao CO .......................................119
Figura 41 – Texto de solução técnica do chamado com indicativo de versão.........120
Figura 42 – Definição do técnico que executa a compilação ..................................121
Figura 43 – Chamados relacionados às versões ....................................................121
Figura 44 – Definição do técnico que executa a compilação ..................................122
Figura 45 – Apresentação do resumo, antes da compilação ..................................122
Figura 46 – Sincronização dos códigos fontes do repositório .................................123
Figura 47 – Compilação do executável pelo Delphi ................................................123
Figura 48 – Backup realizados pelo CompG3.........................................................124
Figura 49 – Executável compilado já copiado para o local de distribuição..............125
Figura 50 – Chamado com informação de chamado executado .............................125
LISTA DE TABELAS
Tabela 1 - Lista de problemas classificadas por prioridade.......................................69
Tabela 2 - Relação problema versus solução .........................................................107
LISTA DE SIGLAS
BTO - Business Tecnology Optimization
CMMI - Capability Maturity Model Integration
CO – Call Organizer
CompG3 – Compilador de executáveis do G3
CRC – Classe – Responsabilidade – Colaborador
DER - Diagrama Entidade-Relacionamento
DOS – Disk Operating System
ECF – Emissor de Cupom Fiscal
EUA – Estados Unidos da América
FNQ – Fundação Nacional da Qualidade
FTP – File Transfer Protocol
IDC – International Data Corporation
IDE - Integrated Development Environment
IEC - International Electrotechnical Commission
ISO – International Organization for Standardization
JEDI VCS– Jedi Version Control System
MA-MPS – Método de Avaliação – Melhoria de Processo de Software
MN-MPS – Modelo de Negócio – Melhoria de Processo de Software
MR-MPS – Modelo de Referência – Melhoria de Processo de Software
MPS-BR – Melhoria de Processo de Software Brasileiro
PDV - Ponto De Venda
RAE – Revista de Administração de Empresas
RAM – Random Access Memory
RUP – Rational Unified Process
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro
SQL – Structured Query Language
TEF – Transferência Eletrônica de Fundos
TI – Tecnologia da Informação
Unisul – Universidade do Sul de Santa Catarina
UML – Unified Modeling Language
VNC - Virtual Network Computing
XP – Extreme Programming
SUMÁRIO
1 INTRODUÇÃO .......................................................................................................19
1.1 PROBLEMA ........................................................................................................20
1.2 OBJETIVOS ........................................................................................................21
1.2.1 Objetivo Geral.................................................................................................21
1.2.2 Objetivos Específicos ....................................................................................21
1.3 JUSTIFICATIVA...................................................................................................22
1.4 APRESENTAÇÃO DA EMPRESA .......................................................................23
1.5 DELIMITAÇÃO DO TRABALHO..........................................................................24
1.6 METODOLOGIA CIENTÍFICA APLICADA AO TRABALHO.................................24
1.7 ESTRUTURA DA MONOGRAFIA .......................................................................25
2 REVISÃO BIBLIOGRÁFICA..................................................................................26
2.1 QUALIDADE........................................................................................................26
2.1.1 Qualidade de Software...................................................................................27
2.1.2 Qualidade do Processo..................................................................................29
2.1.3 Qualidade do Produto ....................................................................................30
2.1.4 Qualidade de Processo vs Qualidade de Produto.......................................30
2.2 MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRO (MPS-BR) ...........31
2.2.1 Componentes do MPS-BR .............................................................................32
2.2.1.1 Modelo de Referência MR-MPS....................................................................33
2.2.1.2 Método de Avaliação MA-MPS......................................................................33
2.2.1.3 Modelo de Negócio MN-MPS ........................................................................33
2.2.2 Base técnica do MPS-BR...............................................................................34
2.2.2.1 ISO/IEC 12207 ..............................................................................................34
2.2.2.2 ISO/IEC 15504 ..............................................................................................34
2.3 METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE.............................35
2.3.1 Rational Unified Process – RUP....................................................................35
2.3.2 Metodologias Ágeis........................................................................................42
2.3.2.1 Extreme Programming – XP..........................................................................43
2.3.2.2 Scrum............................................................................................................48
2.3.3 Considerações finais sobre metodologias ..................................................49
2.4 NECESSIDADE DA CAPACITAÇÃO NA ÀREA DE TI ........................................49
2.5 GERÊNCIA DE PROJETO ..................................................................................50
2.6 MODELAGEM DE PROCESSOS .......................................................................51
2.7 PADRÕES DE DESENVOLVIMENTO.................................................................53
2.8 CONSIDERAÇÕES FINAIS ................................................................................54
3 METODOLOGIA ....................................................................................................55
3.1 IDENTIFICAÇÃO.................................................................................................55
3.1.1 Técnicas de Identificação ..............................................................................55
3.1.1.1 Entrevista ......................................................................................................55
3.1.1.2 Observação direta .........................................................................................56
3.1.1.3 Análise documentacional...............................................................................56
3.1.1.4 Brainstorming ................................................................................................57
3.1.2 Relacionamento de problemas .....................................................................57
3.2 ANÁLISE DA SOLUÇÃO .....................................................................................57
3.3 APLICAÇÃO........................................................................................................58
3.4 ANÁLISE DE RESULTADOS...............................................................................58
3.5 CONSIDERAÇÕES FINAIS ................................................................................58
4 DESENVOLVIMENTO............................................................................................59
4.1 IDENTIFICAÇÃO.................................................................................................59
4.1.1 Descrição dos setores da empresa e divisão das responsabilidades.......59
4.1.1.1 Desenvolvimento...........................................................................................60
4.1.1.2 Implantação...................................................................................................61
4.1.1.3 Suporte..........................................................................................................62
4.1.1.4 Comercial ......................................................................................................62
4.1.1.5 Administrativo................................................................................................63
4.1.2 Métodos atuais de controle dos trabalhos...................................................63
4.1.2.1 Software para controle de tarefas – Call Organizer.......................................63
4.1.2.2 Software para controle de compartilhamento de código-fonte – Jedi VCS....65
4.1.3 Relacionamento dos problemas detectados................................................67
4.1.3.1 Desenvolvimento...........................................................................................67
4.1.3.2 Implantação...................................................................................................68
4.1.3.3 Suporte..........................................................................................................68
4.1.4 Classificação dos problemas por prioridade...............................................68
4.1.5 Seleção dos problemas que serão tratados.................................................69
4.1.5.1 Dificuldade na priorização das atividades de desenvolvimento.....................70
4.1.5.2 Incompatibilidade entre ambientes de desenvolvimento ...............................71
4.1.5.3 Dificuldade na administração das versões ....................................................71
4.1.5.4 Performance do Software Insatisfatória.........................................................72
4.1.5.5 Padronização de código inadequada ............................................................72
4.1.5.6 Desconhecimento das regras de negócio do software..................................73
4.1.5.7 Solicitações mal definidas .............................................................................74
4.1.5.8 Ausência de processo de teste de software ..................................................74
4.1.5.9 Dificuldade na análise sobre o rendimento dos desenvolvedores.................75
4.1.5.10 Dificuldade no controle das tarefas em andamento ....................................75
4.2 ANÁLISE DAS PROPOSTAS DE SOLUÇÃO......................................................75
4.2.1 Solução para: Dificuldade na priorização das atividades...........................76
4.2.1.1 Fila de desenvolvimento................................................................................76
4.2.1.1.1 Alteração de prioridade dos chamados da fila de desenvolvimento...........79
4.2.1.1.2 Visibilidade da fila de desenvolvimento ......................................................80
4.2.1.2 Tempo previsto para execução .....................................................................80
4.2.1.3 Gráfico de acompanhamento de chamados em execução............................81
4.2.1.4 Gráfico de chamados atendidos....................................................................82
4.2.2 Solução para padronização de código inadequada ....................................84
4.2.2.1 Criação do manual de padronização.............................................................85
4.2.2.2 Validação do código fonte por um coach.......................................................86
4.2.3 Solução para: Dificuldade na administração de versões e incompatibilidade entre ambientes de desenvolvimento ....................................87
4.2.3.1 Implementações necessárias do Call Organizer ...........................................88
4.2.3.2 O computador compilador .............................................................................89
4.2.3.2.1 Jedi.............................................................................................................90
4.2.3.2.2 Delphi e os componentes do G3 ................................................................90
4.2.3.2.3 WinRAR......................................................................................................90
4.2.3.2.4 VNC............................................................................................................91
4.2.3.3 O aplicativo compilador do G3 – CompG3 ....................................................91
4.2.4 Solução para: Performance do software inadequada .................................93
4.2.5 Solução para dificuldade na análise sobre o rendimento dos desenvolvedores .....................................................................................................94
4.2.6 Solução para dificuldade no controle das tarefas em andamento.............95
4.2.7 Definição de papeis e responsabilidades ....................................................95
4.2.7.1 Gerência de demanda de desenvolvimento ..................................................96
4.2.7.2 Gerente de tecnologia ...................................................................................99
4.2.7.3 Gerência de Engenharia de Software..........................................................100
4.2.7.4 Gerência de automação comercial ..............................................................100
4.2.7.5 Gerência de estrutura e framework do Procel G3 .......................................102
4.2.7.6 Gerência de conhecimento e treinamento...................................................102
4.2.7.7 Database Administrator - DBA ....................................................................103
4.2.7.8 Gerência de regras de negócio ...................................................................104
4.2.7.9 Gerência estratégica ...................................................................................105
4.2.7.10 Gerência de requisitos...............................................................................105
4.2.8 Relação entre problemas e soluções .........................................................106
4.3 CONSIDERAÇÕES FINAIS ..............................................................................107
5 APRESENTAÇÃO DOS RESULTADOS..............................................................108
5.1 ADOÇÃO E IMPLEMENTAÇÃO DAS PROPOSTAS DE SOLUÇÃO ................108
5.1.1 Fila de Desenvolvimento .............................................................................108
5.1.2 Tempo previsto para execução ................................................................... 111
5.1.3 Gráfico de acompanhamento de chamados em execução.......................112
5.1.4 Gráfico de chamados atendidos .................................................................113
5.1.5 Controle de qualidade e padronização de código fontes .........................114
5.1.5.1 Manual do desenvolvedor ...........................................................................115
5.1.5.2 Validação do código fonte por um coach.....................................................118
5.1.6 Computador compilador de executáveis ...................................................119
5.1.6.1 Implementações realizadas no Call Organizer ............................................119
5.1.6.2 O computador compilador ...........................................................................120
5.1.6.3 O compilador CompG3................................................................................120
5.2 VALIDAÇÃO DA RESOLUÇÃO DOS PROBLEMAS.........................................126
5.2.1 Dificuldade na priorização das atividades .................................................126
5.2.2 Incompatibilidade entre ambientes de desenvolvimento .........................127
5.2.3 Dificuldade na administração das versões ................................................128
5.2.4 Performance do software insatisfatória .....................................................128
5.2.5 Padronização de código inadequada .........................................................129
5.2.6 Desconhecimento das regras de negócio do software.............................129
5.2.7 Solicitações mal definidas...........................................................................129
5.2.8 Ausência de processo de teste de software ..............................................130
5.2.9 Dificuldade na análise sobre o rendimento dos desenvolvedores..........130
5.2.10 Dificuldade no controle das tarefas em andamento................................130
5.3 ANÁLISE GLOBAL DOS RESULTADOS...........................................................131
6 CONCLUSÃO ......................................................................................................132
REFERÊNCIAS.......................................................................................................134
19
1 INTRODUÇÃO
Obter qualidade em software é um constante desafio do mercado de
desenvolvimento de software, um desafio extremamente difícil de encarar e de vencer.
A melhoria da qualidade de um software pode ser obtida pelo uso de métodos
de testes, definição de processos, estabelecimento de controles e padrões. Os padrões
de software podem ser fornecidos por normas ISO (International Organization for
Standardization), métodos e técnicas e prescrevem itens do software que devem estar em
perfeita simetria, orientando à busca pela melhoria do processo e do produto.
A busca pela satisfação do cliente pode ser a maior justificativa para se obter a
qualidade. A satisfação do cliente está ligada ao cumprimento total da satisfação de suas
necessidades e requisitos, e isso só é possível com um produto de software de qualidade
reconhecido (MOLINARI, 2003). O reconhecimento da qualidade do software pelo
mercado é um fator estratégico da empresa desenvolvedora.
A qualidade do produto pode ser a meta, mas intimamente ligada a ela temos a
qualidade do processo. Um processo maduro e otimizado executa o desenvolvimento do
software de forma mais rápida, com menor custo apoiando automaticamente um resultado
final de qualidade e controlável.
Para o segmento de gestão e automação comercial, é fundamental que o
software seja preciso, pois ele lida com informações vitais das empresas e conduz a
decisões operacionais e estratégicas baseando-se nos dados com os quais opera.
Dezenas são os problemas que podem surgir ao utilizarmos um software com
inconsistências: desde informações armazenadas de forma errônea até a apresentação
de projetos de telas e relatórios aquém das necessidades reais do usuário. O objetivo final
de um processo de qualidade deve ser assegurar que o produto forneça a qualidade
requerida, atendendo as necessidades explícitas e implícitas dos usuários do software
incluindo neste escopo operadores, usuários finais e mantenedores do software.
Este trabalho procura apresentar sugestões que podem ser aplicados em
equipes de desenvolvimento de software, proporcionando a melhoria da qualidade do
produto final e do seu processo de desenvolvimento em uma empresa desenvolvedora de
software, sob a forma de um estudo de caso.
20
1.1 PROBLEMA
Com o crescimento do uso dos softwares no ambiente corporativo e o
cresimento da dependência por eles, fica cada vez mais clara a relação entre o processo
operacional das empresas e o processo computacional do software de gestão que o
administra (BARTIÉ, 2002).
É extremamente comum vermos empresas inteiras pararem de trabalhar porque
o sistema está “fora do ar”, provando a dependência direta e exclusiva do software.
Em períodos anteriores, o pouco envolvimento dos softwares no processo da
empresa fazia com que suas falhas fossem facilmente ignoradas, não impedindo ou
atrasando o trabalho, atualmente vemos uma realidade totalmente diferente (BARTIÉ,
2002).
Os softwares disponíveis no mercado costumam ter uma quantidade
considerável de problemas, bug´s, inconsistências, processos mal projetados e falta de
padrões que comprometem sua qualidade e dificultam ou impedem sua adaptação nas
empresas.
Estes problemas que comprometem seu bom funcionamento geram prejuízos
diretos e indiretos, muitas vezes trazendo prejuízos financeiros ou até dificultando o
crescimento da empresa devido ao não sucesso da automatização.
Pode-se citar problemas como reclamações dos usuários, travamentos em
momentos críticos, geração de dados incorretos no banco de dados, condução
inadequada nos processos, dificuldade de auto-aprendizado, entre outros. Estas
conseqüências são extremamente custosas tanto para o cliente usuário como para o
produtor do software, além de comprometer gravemente a imagem do software e do
produtor. Muitas empresas desenvolvedoras “quebram” devido a fracassos extremados
dessa natureza.
A má qualidade do produto de software normalmente é resultado de um
processo de desenvolvimento mal estruturado, feito de forma subjetiva, sem controle,
sendo feito conforme a cultura da empresa formada apenas pela sua experiência de vida
(MOLINARI, 2003). Sob o ponto de vista da empresa desenvolvedora o desenvolvimento
baseado na produção sem observância para questões de qualidade do processo e do
produto gera para a empresa um custo elevado para as equipes envolvidas na
21
manutenção do produto, a falta de controle no processo de desenvolvimento e a eterna
insegurança sobre a qualidade do produto que oferece ao mercado.
Observando este cenário, é elencada a questão de pesquisa relativa a este
projeto.
É possível obter a melhor qualidade do produto melhorando a qualidade no
processo de desenvolvimento?
1.2 OBJETIVOS
Os objetivos deste projeto são determinados em objetivo geral e objetivos
específicos.
1.2.1 Objetivo Geral
O objetivo deste trabalho é promover a melhoria da qualidade do software
melhorando seu processo de desenvolvimento. Em um estudo de caso, serão propostas
técnicas, metodologias, procedimentos e métodos de controle de qualidade para
solucionar um conjunto de problemas relatados pela empresa em estudo.
1.2.2 Objetivos Específicos
São objetivos específicos do projeto:
• Fazer um levantamento dos principais problemas detectados no
diagnóstico
• Orientar os técnicos de controle de qualidade a validar e melhorar a
qualidade do software produzido.
• Criar fluxos de processos para orientar a execução das principais rotinas
operacionais, focando o desenvolvimento de software.
22
• Criar métodos de controle para a aplicação das novas regras para o
processo produtivo.
• Reduzir o índice de retrabalho nas atividades de desenvolvimento e
suporte.
• Automatizar alguns processos que são possíveis de serem
automatizados, garantindo agilidade e padronização do resultado.
1.3 JUSTIFICATIVA
Para conquistar um mercado mais exigente e lucrativo é necessário que o
software atenda a critérios rígidos de qualidade e ofereçam diferenciais competitivos.
Para que a empresa tenha condições de produzí-lo, ela precisa estar bem
organizada com relação ao seu fluxo de trabalho. O seu setor de desenvolvimento de
software deve trabalhar sob metodologias claras e implantadas, seguindo regras, fluxos
operacionais e ter uma equipe de desenvolvedores bem preparada e comprometida com
o resultado, em suma a empresa deve aplicar a engenharia de software, para conduzir o
processo de desenvolvimento de software em busca de um produto final de alta
qualidade.
Este conjunto de ações visa melhorar o processo de desenvolvimento do
software e consequentemente vai levar a um software de maior qualidade e lucratividade.
Algumas metodologias existentes no mercado são complexas, dificultando seu
entendimento e consequentemente sua implantação. Ocorre também que muitas
empresas não realizam pesquisas sobre métodos que venham a ajudá-las, pois focam
seus esforços em suas rotinas de desenvolvimento sem conseguir melhorar seu próprio
processo.
23
1.4 APRESENTAÇÃO DA EMPRESA
Este trabalho está sendo executado tendo como base a experiências da Procel
Software, uma empresa desenvolvedora de software para automação comercial.
Estabelecida a mais de vinte anos e a dezoito atuando exclusivamente com
software de gestão e automação comercial, a Procel conta com cerca de trinta
funcionários diretos atuando no desenvolvimento de software, implantação, treinamento,
suporte ao usuário, comercial e administrativo.
Seu primeiro software foi desenvolvido na linguagem Clipper 5.1 e atendia o
comércio crediarista. Na seqüência foram desenvolvidos sistemas de estoque, financeiro,
faturamento, frente de caixa entre outros relacionados que ainda rodam no comércio da
Grande Florianópolis.
A partir de 1997, iniciou-se o desenvolvimento do primeiro software para rodar
na plataforma Windows, o Procel Loja Light é hoje um software considerado “de
prateleira” e é vendido para todo o Brasil.
A partir de 2001, a Procel iniciou seu plano de expansão conquistando revendas
em vários estados do pais para distribuir seus pacotes de software.
Atualmente, a Procel está focada no seu novo software de gestão, o Procel G3,
que atende satisfatoriamente o mercado em que atua, fazendo um forte trabalho em
atacados e distribuições, redes de lojas, prestadores de serviços, e o comércio varejista.
A Procel está homologada nos estados brasileiros em que atua e também está
homologada para a Transferência Eletrônica de Fundos - TEF, em várias modalidades.
Mais informações sobre a Procel Software, seus produtos e serviços podem ser
acessados através do seu site (PROCEL, 2007). Outras informações relevantes para o
desenvolvimento deste trabalho sã apresentadas no capítulo 4.
24
1.5 DELIMITAÇÃO DO TRABALHO
Apesar de se basear em algumas metodologias de processo como RUP
(Rational Unified Process), XP (Extreme Programming) e Scrum, e ter um caso de
implantação parcial prático, este trabalho não têm a pretensão de levar a empresa a
buscar uma certificação.
Aspectos organizacionais relacionados aos setores comercial e administrativo
não serão considerados ou tratados no projeto.
Algumas propostas sugerem alterações em software existentes na empresa e
criação de novos softwares de apóio. Porem não serão observados aspectos de
engenharia de software sobre estes aplicativos desenvolvidos, cabendo apenas a análise
do resultado obtido por estes.
Não serão propostas soluções para todos os problemas levantados.
Todas as implementações a serem realizadas na empresa por seguimento das
propostas serão de responsabilidade total da empresa, cabendo aos autores apenas
orientar a execução.
1.6 METODOLOGIA CIENTÍFICA APLICADA AO TRABALHO.
Cervo e Bervian (1983, p.50) definem a pesquisa como “uma atividade voltada
para a solução de problemas, através do emprego de processos científicos”. Neste
sentido, percebe-se a importância da pesquisa, como meio de comprovação e obtenção
de dados que auxiliam no processo decisório.
A natureza da pesquisa adotada para o estudo em questão, será do tipo
Aplicada, uma vez que existe a necessidade de gerar conhecimento prático sobre os
processos que envolvem o desenvolvimento de software, este conhecimento será
necessário para que ao final, seja possível identificar quais os pontos que levam a
melhoria significativa na qualidade do produto final.
25
Durante o estudo constatou-se que, a fonte de pesquisa esta no ambiente
interno da empresa, nos processos e no produto final que é gerado como resultado, os
processos que englobam as atividades da empresa serão o ponto chave, adotando assim
uma abordagem qualitativa.
Esta monografia será do tipo exploratória, e do ponto de vista técnico será um
estudo de caso, pois se baseia em fatos reais que ocorrem em uma empresa de
desenvolvimento de software, levando em consideração a experiência das pessoas que
trabalham nesta empresa.
1.7 ESTRUTURA DA MONOGRAFIA
Este trabalho está subdividido em 5 capítulos, conforme descrito a seguir:
1 - Introdução - Este capítulo apresenta a introdução, justificativa, objetivos,
problemas e a solução proposta como trabalho.
2 – Revisão Bibliográfica - Neste capítulo serão referenciadas tecnologias e
métodos cujo conhecimento se faz necessário para o desenvolvimento da solução do
problema como qualidade de software, modelagem de processos, técnicas de testes.
3 – Metodologia – Definição dos passos a serem seguidos para o
desenvolvimento da proposta monográfica.
4 – Desenvolvimento – Aplicação da Metodologia definida no capitulo anterior.
5 – Apresentação dos Resultados – Este capitulo apresenta a implementação
das propostas de soluções adotadas para o tratamento dos problemas levantados.
6 – Conclusão - Neste capítulo serão apresentadas as conclusões e
considerações sobre a monografia.
26
2 REVISÃO BIBLIOGRÁFICA
Neste capitulo é apresentado a revisão sobre as áreas temáticas desta
monografia. O bom entendimento do tema é fundamental para a seleção de novos
processos e aplicação de metodologias adequadas. São áreas temáticas da monografia:
Qualidade de software, Gerência de Projeto, Modelagem de Processos, Padrões de
Desenvolvimento, Metodologia de Desenvolvimento de Software e Metodologia de Teste
de Software.
2.1 QUALIDADE
A definição geral sobre qualidade pode ser entendida como satisfação total de
desejos ou necessidades, não apresentação de inconformidades, e falha no cumprimento
de prazos.
Segundo Pressman (2006), O American Heritage Dicionary define qualidade
como “uma característica ou atributo de alguma coisa”. Como atributo de um item, a
qualidade se refere as características mensuráveis – coisas que nós podemos comparar
com padrões conhecidos tais como comprimento, cor, propriedades elétricas e
maleabilidade.
O dicionário Webster´s define qualidade como “característica essencial de
alguma coisa, inerente ou distinto caráter, grau ou graduação de excelência” (MOLINARI,
2003, p. 20).
O conceito geral de qualidade esta ligado ao atendimento de padrões, métricas,
inconformidades, entre outros, no entanto quando fala-se especificamente sobre
qualidade de software, esta-se referindo a uma entidade intelectual, que é mais difícil de
conceituar do que a qualidade de objetos físicos.
27
2.1.1 Qualidade de Software
“Qualidade de software é a satisfação de requisitos funcionais e de desempenho explicitamente declarados, normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo o software desenvolvido profissionalmente” (SOMMERVILLE, 2003, p. 349).
As necessidades explícitas são as condições e objetivos propostos pelo
desenvolvedor do produto.
As necessidades implícitas incluem diferentes características como diferenças
entre os usuários, a portabilidade do produto, a evolução no tempo, questões
relacionadas a usabilidade, confiabilidade e as questões de segurança, entre outras
características.
Segundo Crosby (1979 apud SOMMERVILLE 2003, p. 458), a noção de
qualidade tem sido a de que o produto desenvolvido deve cumprir com sua especificação.
Observa-se pelas citações de diferentes autores a dificuldade em se obter um
conceito único, a conceituação de qualidade varia de acordo com as expectativas e
objetivos desejados.
Atingir um alto nível de qualidade de produto ou serviço é o objetivo da maioria das organizações. Atualmente, não é mais aceitável entregar produtos com baixa qualidade e reparar os problemas e as deficiências depois que os produtos foram entregues ao cliente. A esse respeito, o software é igual a qualquer outro produto manufaturado, como carros, televisões e computadores (SOMMERVILLE, 2003, p. 458).
Nas últimas décadas programas de qualidade passam a fazer parte dos
quesitos que determinam a competitividade do produto de software.
Na década de 50, o norte-americano W. Edwards Deming trabalhou na indústria
automobilística japonesa. Buscando a melhoria da qualidade, aplicou seus conhecimentos
buscando o desenvolvimento dos processos de manufatura (SOMMERVILLE, 2003).
A partir de então, deu-se início a uma revolução que ainda não terminou, nunca
mais se fizeram carros do mesmo jeito. A partir dos anos 80, montadoras japonesas
instalaram-se nos Estados Unidos, como a Honda, que logo passou a ser considerada
uma das mais produtivas do país.
28
Também a Toyota, que ficou famosa por sua eficiência e velocidade, superando
seus concorrentes como Ford e GM.
A melhoria do processo de qualidade, iniciado por Deming baseia-se na
melhoria contínua dos processos de trabalho. A partir destes resultados iniciou-se a
discussão do impacto da qualidade do processo de produção sobre a qualidade do
produto final.
“De diferencial de mercado, a qualidade transformou-se em condição básica
para a sobrevivência das empresas...” (FNQ, 2007).
No início do século, tinha-se como conceito de qualidade apenas observar a
qualidade do produto final após a produção.
Os bons resultados redundantes da aplicação na qualidade do processo foram
adotados também na indústria de software. Segundo Sommerville (2003), existem quatro
fatores que afetam diretamente a qualidade de produtos de software:
Figura 1 – Principais fatores da qualidade de produtos de software Fonte: Sommerville (2003)
A qualidade do processo de desenvolvimento de software é o principal fator que
vai determinar a qualidade do software, principalmente em projetos maiores, onde os
principais problemas são de integração, gerência de projeto e a comunicação.
A tecnologia de desenvolvimento é essencialmente importante, principalmente
para projetos pequenos, onde a equipe fica mais focada no planejamento e
implementação do software. Boas ferramentas aumentam significativamente a
produtividade. Grandes equipes gastam mais tempo com comunicação, compreendendo
outras partes do sistema e integrando os trabalhos, fazendo com que as ferramentas de
desenvolvimento façam menos diferença no resultado.
29
O custo, tempo e cronograma são elementos fundamentais para a qualidade do
produto. Muitas vezes a qualidade pode ser afetada mesmo com o melhor processo,
tecnologia e equipe, se o prazo não for humanamente viável e o custo coerente.
Na briga diária para sobreviver em um mercado altamente competitivo, muitos
projetos acabam tendo o custo reduzido para poder ganhar os contratos de
desenvolvimento, o que acaba inevitavelmente afetando a qualidade do produto
(SOMMERVILLE, 2003).
Segundo Bartié (2002) é impossível obter software de qualidade com processos
de desenvolvimento frágeis e deficientes, sendo necessário construir um processo de
garantia de qualidade que esteja focado no produto de software e no seu processo de
desenvolvimento. Tem-se então uma discussão entre a maior importância da qualidade do
processo e da qualidade do produto.
2.1.2 Qualidade do Processo
Todos os procedimentos realizados durante o processo de desenvolvimento do
software vão afetar diretamente a qualidade do produto. Cada decisão tomada durante
este processo, vai influenciar o resultado final.
A estruturação deste processo deve criar mecanismos que inibam as falhas e
oriente a codificação de forma mais bem estruturada e padronizada. Um erro identificado
ainda no processo de desenvolvimento, tem um custo de ajuste bem inferior do que se
identificado na fase de testes.
Todos os artefatos1 gerados durante o processo de desenvolvimento devem ter
procedimentos que validem sua qualidade, e eles também devem ser produzidos sob uma
determinada ordem que deve ser seguida e constantemente validada.
Esta visão voltada a processos é comumente ignorada em muitas empresas. Na
maioria dos casos, não existe nenhum processo formal de desenvolvimento deixando
tudo a cargo da “boa criatividade” das pessoas. Ou então, existe algo muito superficial no
papel, porém não é seguido.
1 Os “artefatos” são considerados quaisquer saídas produzidas no ciclo de desenvolvimento, como documentação de análise de requisitos, modelos, especificações de negócio, arquitetura de hardware, modelagem do banco de dados, classes, códigos fonte e assim por diante (RUP, 2007).
30
2.1.3 Qualidade do Produto
Podemos definir que a qualidade do produto é uma conseqüência natural de um
processo de software bem definido (CAROSIA, 2003, p. 28).
A qualidade do produto é claramente um dos resultados do desenvolvimento de
software quando tem-se um processo de software bem definido. A maioria das empresas
de desenvolvimento tem algum processo (mesmo que simples), de teste de software. O
principal objetivo desta fase de testes é validar e garantir a qualidade do produto gerado
no ciclo de desenvolvimento. As atividades desta fase buscam identificar e evidenciar
falhas, inconformidades que passaram despercebidas pelo processo de desenvolvimento.
Observa-se que empresas que aplicam estas atividades, sem ter um processo
de desenvolvimento bem definido, acabam tendo uma baixíssima eficiência, pois são
identificados tantos problemas, que toda a fase final do desenvolvimento acaba sendo
substituída por atividades de correção e manutenção. Ou então o próprio processo de
teste de software também não é bem definido, causando a não identificação dos
problemas relevantes.
Um processo de teste bem definido deve contar com atividades de testes como
testes de funcionalidade, desempenho, usabilidade, processos de automação de testes,
entre outros. (BARTIÉ, 2002)
2.1.4 Qualidade de Processo vs Qualidade de Produto
Observa-se que muitas empresas têm apenas uma visão sobre a qualidade do
produto, destinando uma fase do desenvolvimento para a realização de testes, o mais
interessante é que a fase de testes faça parte de todo o processo de desenvolvimento,
sendo mais uma das várias fases, todas bem definidas, gerenciadas e controladas.
Se concentrarmos esforços na definição de um controle de qualidade de
produto final e deixarmos de lado as demais fases, corre-se o risco de obtermos uma
infinidade de erros e inconformidades que voltarão a ser reimplementados pelo mesmo
31
processo desorganizado, fazendo com que de nada tenha valido o bom processo de
teste.
Ao contrário, se tivermos um processo de desenvolvimento bem definido e um
foco reduzido nos testes, tende-se apenas a que poucos erros sejam passados a diante
pois o produto de forma geral já tem um nível satisfatório de qualidade.
Conclui-se que o correto é ter preocupação constante com relação a qualidade
em todo o processo de desenvolvimento, desde o levantamento de requisitos, design até
a fase final de testes, todas as ferramentas que auxiliem no processo de produção de
software são bem vindos, podemos citar como exemplo o MPS-BR, que é abordado na
seqüência deste trabalho.
2.2 MELHORIA DE PROCESSO DO SOFTWARE BRASILEIRO (MPS-BR)
O MPS-BR é um modelo de referência para guiar a melhoria do processo de
produção de software voltado à realidade das empresas de pequeno e médio porte do
mercado nacional (MPS-BR, 2006).
Figura 2 – Logotipo do Mps-Br Fonte: Mps-Br (2006)
O MPS-BR está em desenvolvimento deste 2003 pela Associação para
Promoção da Excelência do software Brasileiro (SOFTEX) com sede em Campinas-SP, e
tem o apoio de instituições governamentais, universidades, grupos de pesquisa, bancos e
associações.
Este projeto visa promover a qualificação das empresas nacionais com os
padrões de qualidade aceitos pela comunidade de software, a custos acessíveis, tendo
em vista que o custo das certificações como o CMMI (Capability Matutiry Model
Integration) apresentam um custo muito alto para empresas de pequeno porte.
32
A base deste modelo são as normas ISO/IEC(International Electrotechnical
Commission) 12207, ISO/IEC 15504 e o modelo CMMI, sendo estes adaptados em um
formato simplificado que facilita a viabilidade de implantação.
Figura 3 – Base para formação do modelo de referencia MPS BR Fonte: Mps-Br (2006)
Uma das características destes modelos de referências é que eles apenas
determinam o resultado esperado de cada processo, não orientando de forma alguma,
como proceder para alcançar estes resultados.
A definição dos processos descrevem o propósito e os resultados esperados de
sua execução. Com isso, é possível avaliar e medir a aderência da execução dos
processos ao modelo.
Os processos são agrupados e organizados de acordo com sua natureza, ou
seja, o seu objetivo principal no ciclo de vida de software
2.2.1 Componentes do MPS-BR
O programa MPS-BR é dividido em três componentes (figura 2). O Modelo de
Referência (MR-MPS), o Método de Avaliação (MA-MPS) e o Modelo de Negócio (MN-
MPS). Estes componentes são descritos por guias e documentos do MPS-BR (MPS-BR,
2006).
33
Figura 4 – Componentes do Mps-Br Fonte: Mps-Br (2006)
2.2.1.1 Modelo de Referência MR-MPS
O Modelo de Referência MR-MPS lista os requisitos que os processos das
empresas devem atender para estar em conformidade com o MPS-BR. As definições de
requisitos do MR-MPS estão divididas e classificadas conforme o nível de maturidade que
se deseja alcançar. Os níveis de maturidade que são uma combinação entre processos e
sua capacidade (MPS-BR, 2006) estão bastante relacionados ao modelo CMMI, porém
com mais divisões que facilitam a implementação e avaliação em micro e pequenas
empresas, e também viabilizam resultados a prazos mais curtos (MPS-BR, 2006).
2.2.1.2 Método de Avaliação MA-MPS
O Método de Avaliação MA-MPS, descrito no Guia de Avaliação, descreve o
processo e o método de avaliação, com os requisitos para avaliadores e instituições
avaliadoras. Este método está em conformidade com a norma ISO/IEC 15504 (THIRY,
2005).
2.2.1.3 Modelo de Negócio MN-MPS
O Modelo de Negócio MN-MPS descreve as regras de negócio para
implementação do MR-MPS pelas instituições implementadoras, avaliação seguindo o
34
MA-MPS, organização de grupos de empresas para estudo e implementação do MR-MPS
(MPS-BR, 2006).
2.2.2 Base técnica do MPS-BR
O MPS-BR tem como base técnica as normas ISO/IEC 12207, ISO/IEC 15504 e
o modelo CMMI.
2.2.2.1 ISO/IEC 12207
A norma ISO/IEC 12207 e suas emendas 1 e 2 estabelecem uma arquitetura
comum para o ciclo de vida de processos de software, contendo processos inter-
relacionados, atividades e tarefas a serem aplicadas à todo ciclo de vida do software.
2.2.2.2 ISO/IEC 15504
A ISO/IEC 15504 avalia os processos de software com dois objetivos: a
melhoria de processos e a determinação da capacidade de processos de empresa. Para a
melhoria de processos, a empresa pode fazer uma avaliação para gerar um perfil dos
processos atuais para realizar um plano de melhorias e determinação de novos processos
(MPS-BR, 2006).
A norma é definida por 47 processos agrupados em categorias e grupos. Cada
processo descreve o objetivo geral e os resultados esperados que indicam o alcance
bem sucedido do propósito do processo (THIRY, 2005).
35
2.3 METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE
As metodologias de desenvolvimento são conjuntos de regras, práticas,
conceitos, valores que ajudam o orientar as tarefas relacionadas ao desenvolvimento de
software.
Existem atualmente algumas metodologias no mercado e algumas com
princípios bem diferentes e distintos. Existem metodologias mais tradicionais e formais
que valorizam a organização e a documentação, já outras que são as consideradas ágeis,
contam mais com o conhecimento dos envolvidos, defendendo valores como
comunicação, comprometimento, prazos entre outros.
Abordaremos neste tópico algumas metodologias são elas RUP, XP e Scrum.
2.3.1 Rational Unified Process – RUP
Uma metodologia extremamente utilizada em grandes equipes é a Rational
Unified Process (RUP, 2007). O RUP é uma metodologia com seus valores voltados à
organização, gerenciamento, documentação e controle.
O Rational Unified Process® (também chamado de processo RUP®) é um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um cronograma e de um orçamento previsíveis. (IBM, 2007)
36
Figura 5 – Conceitos básicos do RUP Fonte: RUP (2007)
O RUP, é um modelo de desenvolvimento de software interativo, incremental,
orientado a objetos, com foco na criação de uma arquitetura robusta, analise de risco e
utilização de casos de uso para o desenvolvimento.
O RUP, esta dividido em duas dimensões principais, uma representa a parte
estática com os principais processos envolvidos no desenvolvimento, e uma segunda
dimensão que focaliza a parte dinâmica do processo onde estão localizadas as fases do
RUP, conforme figura abaixo:
37
Figura 6 – Visão Geral do RUP Fonte: RUP (2007)
A primeira parte conhecida como estática com base no RUP (2007), é dividida
em nove disciplinas, são elas:
• Modelagem de Negócios: A modelagem de negócio é utilizada para
entender a estrutura e a dinâmica da empresa onde o sistema será
implantado, serve também para entender os problemas atuais e
identificar possíveis melhorias, além de assegurar que os usuários
tenham conhecimento da empresa como um todo.
• Requisitos: Os requisitos são responsáveis por estabelecer e manter a
concordância entre os clientes e envolvidos no projeto sobre o que o
sistema deve fazer, define as fronteiras do sistema, fornece a base para
planejar as iterações, estima o custo e tempo do projeto e define uma
interface de usuário para o sistema.
• Análise e Design: Esta disciplina tem como meta transformar os
requisitos em um design do sistema, desenvolvendo uma arquitetura
moderna, adaptando o design para que ele corresponda ao ambiente de
implementação.
• Implementação: A implementação tem por objetivo definir a organização
do código em termos de subsistemas de implementação sob forma de
camadas, além de implementar as classes e os objetos como
38
componentes do sistema, testar os componentes individualmente e
integrar os resultados produzidos individualmente ao sistema principal.
• Teste: Esta disciplina se ocupa de localizar e documentar defeitos
referentes a qualidade do software, validar as suposições feitas na fase
de design e requisitos e verificar se os requisitos foram implementados
de forma adequada.
• Implantação: Descreve as três formas possíveis de implantação do
sistema, sendo a primeira a instalação personalizada, a segunda o
produto em uma forma compactada e a ultima o acesso pela web. Em
cada uma das formas de implantação a ênfase é testar o produto no local
onde ele foi desenvolvido, fazendo-se o teste beta antes de disponibiliza-
lo ao cliente.
É possível observar que a fase com maior volume de atividades é a de transição, mas
algumas atividades ocorrem em fases anteriores ao planejamento e preparação para
implantação.
• Gerenciamento de configuração e mudança: Disciplina responsável pela
identificação dos itens de configuração, restrição de mudanças, auditoria
e definição do gerenciamento das configurações.
• Gerenciamento de Projeto: Envolve a análise dos objetivos da
concorrência, gerência de riscos e superação de obstáculos para liberar
com sucesso o produto conforme as necessidades do cliente.
• Ambiente: Disciplina responsável pelas atividades de suporte a equipe
de desenvolvimento, através de processos e ferramentas que orientam o
desenvolvimento de software.
A segunda parte da divisão feita pelo o RUP é denominada de dinâmica e esta
dividida em quatro fases denominadas de Iniciação, Elaboração, Construção e Transição.
E com base em RUP (2007), elas são descritas uma a uma da seguinte forma:
39
Figura 7 – As fases e os marcos de um projeto do RUP Fonte: RUP (2007)
A passagem pelas quatro fases completam um ciclo de desenvolvimento, além
de produzir a geração de software. Os ciclos que seguem após o ciclo inicial são
denominados de ciclos de evolução.
Figura 8 – Ciclo de desenvolvimento do RUP Fonte: RUP (2007)
• Iniciação: Definir os objetivos dos ciclos de vida do projeto, sendo que
esta fase tem muita importância nas novas implementações, onde os
riscos de negócio e de requisitos precisam ser bem tratados para não
comprometer o andamento do projeto.
• Elaboração: Criar sustentação para a arquitetura do sistema, além de
fornecer uma base estável para a fase de construção, isso é possível
através de um exame a fundo nos requisitos que tem mais impacto na
arquitetura do sistema, fazendo uma avaliação de risco sobre estes.
• Construção: Essa fase é um processo de manufatura, com ênfase no
gerenciamento de recursos e controle de operações para otimizar custos
e qualidade. Aqui tudo que até então era propriedade intelectual passa
para a implementação prática do que foi visto anteriormente.
40
• Transição: Esta fase tem como objetivo principal, garantir que o produto
que esta sendo disponibilizado, esta pronto para ser manipulado pelos
usuários finais, envolvendo atividades de pequenos ajustes e feedback
com os usuários.
Além das características apresentadas até aqui, o RUP possui uma forte visão
baseada em papéis.
Segundo IBM (2007) Um papel é uma definição abstrata de um conjunto de
atividades executadas e dos respectivos artefatos.
No RUP esses papéis são desempenhados por uma pessoa ou grupo de
pessoas que trabalham em equipes, eles descrevem como as pessoas se comportam
dentro do projeto, além de definir suas responsabilidades, são eles:
• Analistas: Lidera a identificação de requisitos e a modelagem de casos
de uso.
• Desenvolvedores: Organizam os papéis envolvidos principalmente no
design e desenvolvimento de software. Estão sub-divididos em designers
de Cápsula, Revisor de Código, Designers de Banco de Dados,
Implementador, Integrador, Arquiteto de software, Revisor de Arquitetura,
Revisor de Design, Designer e Designer de Teste.
• Testadores: Responsável pelos testes, conduzindo e registrando os
resultados dos testes, incluindo a Identificação da abordagem ideal para
realizar o teste, testes individuais, configuração e execução dos testes e
análise de erros de execução.
• Gerentes: Organizam os papéis envolvidos principalmente no
gerenciamento e na configuração do processo de engenharia de
software. Esse papel de forma geral é responsável por dar suporte ao
desenvolvimento, fornecendo infra estrutura geral de gerenciamento,
sendo que é sub dividido em: Engenheiro de Processo, Gerente de
Projeto, Gerente de Controle de Mudança, Gerente de Configuração,
Gerente de Implantação, Revisor do Projeto e Gerente de Testes.
41
• Outros: É definido como qualquer pessoa que participa e afeta o
resultado final do produto, desde o cliente passando pelos investidores,
acionistas do projeto até o escritor da documentação.
O RUP baseia-se na arquitetura do software, onde se define a visão geral do
software e seus módulos. Logo nas primeiras iterações do projeto se define o protótipo da
arquitetura, e o desenvolvimento a seguir vai complementando esta arquitetura.
O RUP oferece um conjunto de melhores práticas para o desenvolvimento de
software como atividades, processos, métodos e uma linguagem de modelagem. No RUP
as atividades são bem definidas, atribuídas a papéis, com documentação definida,
interdependências, guias de execução e diagramas da Unified Modeling Language –
UML.
No RUP existe preocupação constante com o treinamento e capacitação dos
integrantes do projeto, sendo que após a preparação de todo o ambiente para
desenvolvimento do projeto, são realizados workshop.
Segundo RUP(2007), a finalidade de um workshop é fazer com que os
participantes do projeto fiquem informados acerca de como usar o novo processo e as
novas ferramentas o mais rápido possível.
O workshop não substitui os treinamentos padrões, denominados pelo RUP
como plano de treinamentos, que são quaisquer treinamentos especiais necessários aos
integrantes da equipe do projeto, com as datas-alvo identificando quando os treinamentos
deverão ser concluídos, e qual conteúdo abordado RUP (2007).
Utilizando-se uma metodologia como o RUP é possível obter qualidade de
software, produtividade no desenvolvimento, controle sobre o desenvolvimento e
estimativa de prazos e custos do projeto.
42
2.3.2 Metodologias Ágeis
As metodologias consideradas tradicionais são orientadas a planejamento e
controle. As documentações aplicadas ao desenvolvimento de software são muitas vezes
limitadores para desenvolvedores. Ocorre também que muitas empresas de menor porte
não possuem recursos disponíveis para criar e manter esta documentação, fazendo com
que muitas não adotem metodologia de desenvolvimento.
Em 2001, um conjunto de programadores reuniu-se com o objetivo de encontrar
melhores formas para melhorar o desempenho em seus projetos de software. Cada
profissional tinha seu conhecimento e experiência, porém todos concordavam com um
conjunto de princípios que estavam relacionados ao sucesso em alguns projetos. Criou-se
então o Manifesto para o Desenvolvimento Ágil de Software, e que chamamos hoje de
Manifesto Ágil. (TELES, 2007a).
Segundo Pressman (2006, p. 58), os grandes princípios do manifesto ágil são:
• Indivíduos e interações mais do que processos e ferramentas.
• Software funcionando mais do que documentação abrangente.
• Colaboração com o cliente mais do que negociação de contratos.
• Responder a mudanças mais do que seguir um plano.
A partir destes princípios básicos, desenvolveram-se metodologias com maior
detalhamento de suas características, criando um conjunto de práticas que orientam o
desenvolvimento ágil de softwares de qualidade.
As metodologias ágeis vêem com a proposta de focar fortemente nas pessoas,
valorizando o conhecimento e a comunicação ao invés de basear-se em processos de
documentações (SOARES, 2007).
O manifesto ágil não elimina ferramentas, documentos, processos e
planejamentos, apenas fortalece o foco em características humanas, fazendo que os
demais artefatos tenham importância secundária.
“Metodologias ágeis têm sido apontadas como uma alternativa às abordagens
tradicionais para o desenvolvimento de software.” (SOARES, 2007).
43
2.3.2.1 Extreme Programming – XP
Uma das metodologias de grande destaque na comunidade de
desenvolvedores é a Extreme Programming – XP.
Segundo Beck (apud SOARES, 2007) a XP é uma metodologia ágil para ser
aplicada em pequenas e médias equipes de desenvolvimento que trabalham em projetos
com requisitos vagos e que modificam rapidamente.
Segundo Astels (2002), A XP contém princípios e práticas que orientam um
projeto e sua equipe de desenvolvimento.
Esses princípios são empregados como um processo de desenvolvimento de
software, abaixo serão citados os princípios um a um e logo após será abordado o
funcionamento de forma geral do XP:
• Trabalhe com os seus clientes;
Segundo Astels (2002), Talvez o mais extremo dos princípios da XP seja a
sua insistência em fazer um cliente real trabalhar diretamente no projeto.
A necessidade de envolvimento do cliente no projeto é de suma importância
no XP, uma vez que é o cliente que sabe quais são as reais necessidades
dele e de seus colegas que utilizarão o sistema no dia a dia.
Ao cliente é dado o poder de tomar decisões com relação as prioridades,
recursos e riscos envolvidos.
• Use as metáforas para descrever os conceitos difíceis;
Uma metáfora é uma forma poderosa de relacionar uma idéia difícil em uma
área desconhecida. (ASTELS, 2002)
A metáfora é uma representação de um conceito ou recurso e não significa
que ela é precisa em todos os sentidos, ela fornece um contexto geral para
discutir os problemas e soluções a serem aplicadas.
• Planeje;
Na XP não se prioriza um planejamento longo, que leve em consideração
todos os detalhes que possam ser encontrados no decorrer do projeto, ao
invés disto ela orienta que o planejamento deve ser curto e continuo uma
44
vez que as variáveis constantes em um projeto são inúmeras e com certeza
o planejamento sofrerá mudanças no decorrer do projeto.
• Mantenha as reuniões curtas;
As reuniões não são bem vindas pelos desenvolvedores, e a XP defende
reuniões curtas e diárias com duração de aproximadamente 15 minutos,
onde todos ficam de pé, e cada um fala sobre o que fez desde o ultimo
encontro e o que pretende fazer até a próxima reunião.
Segundo Astels (2002), As reuniões são valiosas como um fórum de
comunicação, mas apenas enquanto elas são breves e focalizadas.
• Teste primeiro;
Com esta prática a XP defende que o teste passa a fornecer uma definição
ou documentação do comportamento desejado, além de ser possível saber
quando se tem a funcionalidade total e corretamente implementada.
• Seja simples;
A XP defende a teoria de que o processo seja simples, onde não se deve
preocupar com o que pode acontecer, esse pensamento faz sentido a partir
do momento que a preocupação antecipada com tudo que pode acontecer
mesmo antes de se concretizar, pode trazer a perda de um tempo precioso
de desenvolvimento, deixando de lado algo que é essencialmente
indispensável, e faz parte dos requisitos do projeto.
• Programe em pares;
Na XP utiliza-se a programação em pares, esta metodologia prega o
princípios de que dois programadores trabalhando juntos são melhores do
que trabalhando em separado.
Na XP enquanto um desenvolvedor pilota (codificando), o parceiro mantém
em mente nos objetivos gerais do projeto.
• Codifique dentro dos padrões;
A XP defende a necessidade de se adotar algum padrão de código para o
desenvolvimento, adotando esta prática o código permanece limpo e facilita
a manutenção por parte de outros desenvolvedores.
45
• Faça a propriedade coletiva;
Tradicionalmente em um projeto de software a propriedade das classes
normalmente são de responsabilidade de um membro especifico que
controla a distribuição entre os demais desenvolvedores, ou através da
utilização de algum aplicativo para controle de liberação e bloqueio de leitura
das classes.
Segundo Astels (2002). A XP prescreve a propriedade da equipa para tudo.
Se uma alteração for necessária, a pessoa que tiver melhores condições
pode fazê-la.
• Integre continuamente;
Na XP o ideal é integrar seu código produzido ao código base do projeto a
cada término de uma tarefa, ou pelo menos diariamente, este procedimento
força a realização de testes a cada tarefa concluída, e mantém a qualidade
do projeto como um todo.
• Faça o refactoring;
Refactoring é o processo de alterar um sistema de software de tal forma que ele não altere o comportamento externo do código e melhore a sua estrutura interna. Essa é uma forma disciplinada de limpar o código que minimiza as chances de introdução de bugs (ASTELS, 2002).
• Faça releases em incrementos pequenos;
A XP defende a idéia de disponibilizar releases freqüentes, com a utilização
de releases pequenos, se coloca a nova funcionalidade nas mãos dos
usuários o mais cedo possível.
Deve se observar que mesmo sendo pequeno um release deve estar
completo, e fazer sentido, ou seja, agregar alguma nova funcionalidade ao
projeto, o tempo de um release na XP é de aproximadamente 1 mês, sendo
que 6 meses já é considerado um período longo.
• Não se desgaste;
A XP prima pela qualidade no ambiente de trabalho, e segundo seus
princípios uma semana de trabalho não deve ter mais de 40 horas.
46
• Adote as alterações;
Segundo Astels (2002), a alteração dos requisitos é uma necessidade no
ambiente de negócios em rápida evolução no qual todos trabalhamos.
Atualmente não só na área de desenvolvimento de software como em
muitas outras áreas profissionais, só existe uma regra, e essa regra diz que
em algum momento haverá uma mudança.
Não se tem certeza do que pode ocorrer no transcorrer de um projeto de
desenvolvimento de software, mas inevitavelmente uma mudança se fará
necessária no meio do percurso, e a XP encara a mudança como uma
constante no processo de desenvolvimento de software.
A XP é um conjunto de regras e práticas inclusas em quatro atividades
principais: planejamento, projeto, codificação e teste (PRESSMAN, 2006).
Na atividade de planejamento, criam-se as user stories que são pequenas
descrições de partes do negócio e que são escritas pelo próprio cliente. Estas user stories
são analisadas pela equipe de desenvolvimento e a elas são atribuídas um custo (tempo
de desenvolvimento). De posse de todas as user stories, estas são classificadas de
acordo com o custo e complexidade, e é decidido quais serão entregues na primeira
iteração do projeto. As user stories mais complexas são executadas primeiro.
Durante o andamento do projeto, o cliente pode fazer alterações na user
stories, bem como criar e eliminar outras, fazendo com que a equipe de desenvolvimento
tenha que considerar as mudanças e re-planejar as próximas versões.
Na atividade de projeto, objetiva-se manter a simplicidade, mantendo o foco nas
características originais das user stories, desencorajando o projeto de funcionalidades
que os desenvolvedores acham que serão necessárias posteriormente.
A XP orienta o uso de cartões CRC (Classe-Responsabilidade-Colaborador),
que identificam e organizam as classes. Se considerarmos orientação a objetos este é o
principal resultado da fase de projeto quando a metodologia utilizada é a XP.
47
A atividade de codificação é a fase em que é feita a implementação do código. A
XP recomenda que antes da escrita do código, sejam desenvolvidos testes unitários que
vão executar cada user storie aprovando assim o código tão logo ele foi produzido.
Uma das características mais polêmicas da XP é a programação em pares, que
orienta que dois programadores sentem diante de um computador, um fazendo a
codificação direta e o outro orientando e revisando o código em tempo real, garantindo a
qualidade do código e auxiliando para que ambos mantenham o foco no desenvolvimento.
Na seqüência, a estratégia da integração contínua reúne o código desenvolvido pelos
vários pares de programadores, re-compilando com certa freqüência o código do projeto,
com o objetivo de identificar rapidamente problemas de compatibilidade (PRESSMAN,
2006).
Na atividade de teste, podemos automatizar a execução de todos os testes
unitários, ou um sub-conjunto de testes focados na parte do projeto que foi alterada.
Também são realizados os testes de aceitação que envolvem o cliente na validação das
características e funcionalidades do sistema.
A XP também orienta que os envolvidos em um projeto XP organizem-se,
atribuindo papéis, tanto na equipe do cliente como na equipe de desenvolvedores. Entre
os desenvolvedores, podemos citar papeis como o técnico, acompanhador, facilitador, e o
arquiteto (ASTELS, 2002).
48
2.3.2.2 Scrum
O Scrum é um modelo ágil de desenvolvimento com característica parecidas
com a XP, reforçando idéias de flexibilidade, adaptabilidade e produtividade (SOARES,
2007).
Figura 9 – Fluxos de processo do Scrum Fonte: Scrum (2007)
Equipes pequenas são organizadas para facilitar a comunicação e minimizar a
supervisão, maximizando assim o compartilhamento do conhecimento tático.
Modificações técnicas e de regras de negócio são aceitas e introduzidas no projeto.
Uma das características fortes do Scrum são os períodos pré-determinados de
entrega de versões chamados de sprints. Cada sprint tem cerca de 30 dias, e durante
este período, não são introduzidas novas mudanças, fazendo com que neste período, os
requisitos sejam estáveis.
As scrum meetings são reuniões que ocorrem diariamente que duram cerca de
15 minutos. Nestas reuniões são discutidos os trabalhos realizados deste a última
reunião, são discutidos as dificuldades encontradas e planejadas as atividades do dia.
O ciclo de vida do Scrum é baseado em três fases principais (SOARES, 2007).
49
No Pré-planejamento, é feito o levantamento e a documentação dos requisitos,
posteriormente estes são priorizados e é estimado o custo de cada um. Nesta fase
também é definida a equipe de desenvolvimento, as ferramentas, tecnologias. Também
são calculados os riscos e necessidades de treinamento.
Na fase de Desenvolvimento, é realizada a codificação, que é dividida em
sprints de 30 dias. Em cada sprint, é feito a análise, o projeto, a implementação e testes.
Nesta fase evita-se ao máximo a inclusão de novos requisitos, negociando-se ao máximo
para o próximo sprint.
No Pós-planejamento, são realizadas reuniões de análise do progresso do
projeto e cumprimento dos objetivos. Também são realizados os testes finais e a
apresentação final do software ao cliente (SOARES, 2007).
2.3.3 Considerações finais sobre metodologias
A leitura e o estudo dos modelos apresentados, mostra a importância no
processo para algumas questões pontuais como a modelagem de processo, e gerência
de projetos, a padronização e a capacitação dos funcionários
2.4 NECESSIDADE DA CAPACITAÇÃO NA ÀREA DE TI
Atualmente é cada vez mais difícil encontrar mão de obra qualificada na área de
TI, um estudo recente do IDC (International Data Corporation) financiado pela Symantec
comprova essa afirmação.
Muitas organizações de TI implantam tecnologia sem saber como usá-la de forma eficaz, o que resulta em perda significativa de tempo e dinheiro devido ao uso incorreto da tecnologia ou à falta de otimização de sua funcionalidade", diz Cushing Anderson, diretor de programa da área de Serviços de Treinamento do IDC. Segundo ele, com o treinamento apropriado, as organizações de TI podem aprimorar de forma significativa sua base de conhecimento e capacitação, ficando assim mais preparadas para gerenciar e minimizar riscos de TI, o que ajuda no sucesso dos negócios em geral. (THESIS, 2008)
Equipes mais bem treinadas economizam tempo e agregam maior valor ao
produto final. Apesar dos treinamentos terem um custo para as organizações, este valor
50
retorna para a empresa em forma de reconhecimento no mercado e diferencial
competitivo.
Segundo Thesis (2008) equipes de TI (Tecnologia da Informação) citam que o
treinamento prático, complementado com bibliotecas de referência e informações online,
ajudam muito o trabalho de aprendizado e crescimento profissional.
O aprimoramento continuo de uma equipe de desenvolvimento de software,
municia os envolvidos no processo, com mais conhecimento, para lidar com situações
diversas que possam surgir no dia a dia dessas equipes.
Com base em Thesis(2008) entrevistas realizadas com aproximadamente 200
equipes funcionais de TI da América do Norte, compostas de dois ou três funcionários,
comprova-se que os membros de uma equipe bem treinada são mais capazes de
antecipar vários problemas, implementar ações preventivas e trabalhar para desenvolver
técnicas operacionais graças a sua familiaridade com as funcionalidades das tecnologias
implantadas.
Estando a equipe de TI bem treinada e motivada, as atividades dentro da
empresa passam a ser cumpridas com maior qualidade, e em menor tempo, facilitando ou
melhorando a gerência das equipes envolvidas no processo.
2.5 GERÊNCIA DE PROJETO
Gerenciamento de projetos é um conjunto de ferramentas gerenciais que permitem que a empresa desenvolva um conjunto de habilidades, incluindo conhecimento e capacidades individuais, destinados ao controle de eventos não repetitivos, únicos e complexos, dentro de um cenário de tempo, custo e qualidade pré-determinados.(VARGAS, 2002)
Observa-se em todos os segmentos do mercado mundial que é forte a
tendência de mudança de cultura das empresas, atualmente as empresas que mais se
destacam no mercado, utilizam o conceito de planejamento baseado em projetos, fazendo
com que haja a quebra de paradigmas, sempre em busca da qualidade.
Segundo Vargas (2002), Projeto é um empreendimento não repetitivo,
caracterizado por uma seqüência clara e lógica de eventos, com inicio, meio e fim, que se
51
destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de
parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidade.
A gerência de projetos tem papel fundamental, principalmente quando fala-se
de empresas de desenvolvimento de software, onde o gerenciamento de projetos não faz
parte apenas de uma cultura ou filosofia de trabalho, mas sim é através dele que teremos
o produto final da empresa, que é o software pronto e de qualidade.
Uma empresa de desenvolvimento de software se utiliza muito da criatividade e
capacidade intelectual dos envolvidos, exigindo mais ainda da área de gerência de
projetos, que tem a tarefa de não tirar a criatividade da equipe e ao mesmo tempo não
permitir que o projeto tenha seu foco destorcido ou comprometido.
Segundo Vieira(2003). “os gerentes de projeto devem também ter
conhecimentos e experiência em gerenciamento geral e devem conhecer bem a área de
aplicação do projeto”.
Como exemplo é possível citar, que um projeto para automatizar o
departamento de vendas de uma empresa, necessita de um gerente de projetos, que
tenha conhecimento dos processos que envolvem a área de vendas.
Sendo assim um gerente de projeto necessita de contínuo aprendizado nas
mais diversas áreas profissionais existentes, este conhecimento facilita a modelagem dos
processos que envolvem o projeto em questão.
2.6 MODELAGEM DE PROCESSOS
Um modelo é uma abstração de alguma coisa, cujo propósito é permitir que se
conheça essa coisa antes de se construí-la. (RUMBAUGH, 1994).
Com base em Cordeiro (2003), a ênfase dos estudos sobre modelagem de
processos de software recaiu, sobretudo, na necessidade de definição e representação
dos processos de software e na seleção adequada desses modelos frente aos processos
necessários para desenvolver e manter produtos de software.
A modelagem de processos é a atividade que se caracteriza por estudar um
processo existente, e através da aplicação de técnicas e aplicativos de softwares
desenvolvidos especificamente para este fim, chega-se a um modelo que pode ser o
52
modelo atual do que se estuda, e a partir deste modelo pode-se desenvolver um modelo
de processo otimizado que busca a melhoria no processo de produção.
Segundo Humphrey (1989 apud Cordeiro 2003, p. 45) ressaltam que a
descrição de processos contribui sob vários aspectos no processo de desenvolvimento,
dentre eles:
• A padronização do processo é necessária para permitir o treinamento,
elaboração de guias, gerenciamento, revisão e automação;
• Com a padronização de métodos, cada experiência de projeto pode
contribuir para uma melhoria global em uma organização;
• Processos padronizados provêem uma infra-estrutura básica para
melhoria, avaliação e mensuração;
• Porque a definição de processos exige tempo e esforço para ser
produzido, é impraticável produzir novos processos para cada novo
projeto;
• Porque tarefas básicas são comuns em muitos projetos de software,
apenas algumas customizações seriam necessárias para um processo
padrão atender à maioria das necessidades de projetos.
Com base em Cordeiro (2003), inúmeros problemas podem decorrer da falta da
definição desses processos como aumento no custo de desenvolvimento, atraso na
entrega do produto e baixa qualidade do produto.
Considerando a capacidade de captar informações de um processo de negócio,
os métodos de modelagem mais utilizados são: fluxogramas; workflow; metodologia de
definição integrada; modelagem de negócio CIMOSA, linguagem de modelagem unificada
- UML; modelos de simulação dinâmica; modelos de relação entre entidades; diagramas
de causa e efeito; diagramas de pareto; etc.
Segundo Sutton e Osterweil (1997 apud CORDEIRO 2003, p. 46) analisando
diversas linguagens e processos de software apresentam um conjunto básico de
requisitos que uma linguagem de modelagem de processos de software deve conter:
• Descrição das atividades: definir os passos contidos em um processo;
53
• Descrição dos artefatos: definir o sistema de software que está sendo
construído, incluindo o código-fonte e todos os outros artefatos
produzidos;
• Descrição dos recursos: especificar os recursos humanos e
computacionais disponíveis para utilização nas atividades;
• Relacionamento entre atividades: indicar os vários tipos de interconexões
semânticas entre atividades, artefatos e recursos.
A utilização da modelagem de processos no desenvolvimento de software, é de
fundamental importância para que os resultados esperados com o projeto sejam
alcançados. A modelagem de processos da empresa propiciam o melhor controle do
desenvolvimento favorecendo a implementação de padrões.
2.7 PADRÕES DE DESENVOLVIMENTO
Segundo Pressman (2006, p. 192), “padrões de projeto incorporam
modularidade”.
Em engenharia de software, a modularidade é a decomposição de um software
em partes menores, dividindo um problema em vários problemas menores, facilitando seu
desenvolvimento e manutenção. Ao se trabalhar com um único software grande,
facilmente os desenvolvedores perdem o foco e se preocupam com aspectos não
diretamente relacionados com o problema que estão tratando.
Segundo Fowler (apud PRESSMAN 2006, p 203), “Padrões são semi prontos –
o que significa que você sempre tem que acabá-los e adaptá-los ao seu próprio ambiente”
A utilização de padrões como forma de solucionar problemas, busca garantir
qualidade e segurança a equipe de trabalho, ao invés de se reinventar, adota-se uma
estrutura que já existe e é comprovadamente eficaz, e nesta estrutura pode-se proceder
alterações para adaptá-la a realidade do problema em questão.
54
2.8 CONSIDERAÇÕES FINAIS
Através da revisão bibliográfica, foram estudadas as áreas de conhecimentos
específicas relacionadas ao processo de desenvolvimento de software.
A abordagem adotada para a utilização correta de itens importantes para o
desenvolvimento de software como modelagem de processos, padrões de
desenvolvimento e metodologia de desenvolvimento, é fator preponderante para o
sucesso dos projetos de uma empresa de desenvolvimento de software.
Em contra partida, a não observância para estes itens, acarreta o não
cumprimento de prazos, a falta de qualidade do produto final, conseqüentemente a
insatisfação do cliente e por fim a perda de competitividade da empresa desenvolvedora
no mercado.
.
55
3 METODOLOGIA
A metodologia de desenvolvimento do projeto foi definida a partir de quatro
fases, são elas:
Figura 10 – Fases para a metodologia de desenvolvimento: Fonte: Elaboração dos autores, 2008.
3.1 IDENTIFICAÇÃO
A etapa de identificação deve determinar os problemas assinalados como
críticos no processo de desenvolvimento.
Para a melhor identificação, entendimento, classificação e priorização nas
necessidades, será necessário o levantamento organizacional das funcionalidades da
empresa, identificando seus setores, funções e seus inter-relacionamentos. Outro ponto
importante é observar a cultura empresarial e a maneira como ela conduz atualmente à
solução dos seus problemas.
3.1.1 Técnicas de Identificação
Para a realização desta identificação, utilízam-se técnicas formais e informais
de levantamento de dados que orientam as respostas, como entrevista, observação
direta, análise documentacional e brainstorming.
3.1.1.1 Entrevista
A entrevista, segundo Rosa e Arnoldi (2006 apud SANTOS, 2006) não é um
simples diálogo, mas uma discussão orientada para um objetivo definido, em que o
entrevistado é levado a falar sobre temas específicos. Ainda destacam que “toda
entrevista é uma construção comunicativa de um simples registro de discursos dos
56
entrevistados”. Para as autoras esse discurso ocorre em resposta a uma investigação em
que se encontram presentes entrevistador e entrevistado.
Existem vários tipos de entrevistas, e para a execução deste trabalho, utilizou-
se entrevistas de coleta de dados, que objetivam a coleta de dados específicos e a
identificação de informações relevantes (TCU, 1998).
Entrevistados de nível gerencial normalmente conhecem todo ou a maioria do
fluxo operacional da instituição e observam a relação dos sistemas de informação com a
atividade principal. Já os entrevistados de nível operacional, normalmente conhecem
muito bem as atividades que executam, podendo fornecer detalhes fundamentais que
fazem a diferença no resultado final, e são normalmente os que conhecem melhor as
dificuldades.
3.1.1.2 Observação direta
A técnica de observação direta consiste em observar a rotina de trabalho, suas
entradas, processos e saídas.
Nas entrevistas, os entrevistados poderão ocultar informação de forma
intencional ou não intencional. De forma intencional quando de alguma maneira, a
informação compromete alguma atividade que não está alinhada ao foco da empresa. De
forma não intencional quando simplesmente esquece, ou não se lembra de alguma
informação que seria importante para o entrevistador.
3.1.1.3 Análise documentacional
Análise Documentacional consiste em observar especificamente qualquer tipo
de documento produzido. Relatórios, documentos oficiais, documentos internos, planilhas,
fluxogramas, rascunhos, entre outros são todos objetos de análise, de onde pode-se
extrair conclusões que virão a complementar as informações coletadas através de outras
técnicas.
57
3.1.1.4 Brainstorming
O Brainstorming, ou “tempestade de idéias” é uma técnica onde o grupo de
pessoas envolvidas é incentivado a usar a criatividade e expressar o maior número
possível de idéias. No Brainstorming não é aceito críticas nem discussões polêmicas. O
objetivo é que os participantes vão completando seus pensamentos utilizando idéias dos
demais participantes de forma intensa. No final do período estipulado, as idéias são
traduzidas e validadas, para então observar aspectos negativos em relação à conclusão
alcançada. (RUP, 2007)
3.1.2 Relacionamento de problemas
Após a aplicação das técnicas de identificação, obter-se-á uma lista de
problemas identificados, que deverão ser devidamente classificados.
Os problemas deverão ser primeiramente classificados por setor e dentro de
cada setor, os problemas deverão estar listados em ordem de prioridade.
Da relação obtida, serão escolhidos alguns problemas para serem
solucionados, nos quais este trabalho vai manter o foco.
3.2 ANÁLISE DA SOLUÇÃO
Após a identificação e classificação dos problemas serão estudas propostas de
solução utilizando o conhecimento obtido a partir da revisão bibliográfica, do
conhecimento adquirido no curso e experiência profissional da equipe.
Estas propostas serão detalhadamente especificadas e apresentadas à diretoria
da empresa, para que esta autorize a sua aplicação.
58
3.3 APLICAÇÃO
A aplicação das propostas de solução será realizada diretamente sobre os
setores envolvidos e isso afetará também seus processos de controle atuais como seus
softwares de controle.
3.4 ANÁLISE DE RESULTADOS
Após a aplicação das propostas deve ser realizada uma nova identificação, para
verificar se os principais problemas foram solucionados com a aplicação das propostas.
Serão realizadas entrevistas para verificar o nível de satisfação de clientes e funcionários
e o impacto de sua implementação.
3.5 CONSIDERAÇÕES FINAIS
Através da metodologia proposta espera-se propor o melhor conjunto possível
de soluções a partir do levantamento mais adequado dos problemas podendo assim
contribuir para o desenvolvimento da empresa e a conclusão desta monografia.
59
4 DESENVOLVIMENTO
Este capítulo vai apresentar a aplicação da metodologia prevista no capítulo 3.
4.1 IDENTIFICAÇÃO
A primeira etapa a ser realizada foi a de identificação dos problemas. Para isso
foram realizadas entrevistas e reuniões onde foram levantados:
• Descrição dos setores da empresa e divisão das responsabilidades
• Métodos atuais de controles dos trabalhos
• Descrição dos problemas
• Prioridade para resolução dos problemas
Para a identificação e classificação dos problemas, foram realizadas duas
reuniões de brainstorming envolvendo os autores, os diretores e gerentes de setores da
empresa. Nestas reuniões observou-se que existia certo consenso sobre a maioria dos
problemas, além de alguns problemas específicos de cada setor, nesses casos cada
respectivo gerente tinha maior detalhamento.
Após as reuniões, também foram entrevistados de forma informal alguns dos
colaboradores para obter destes alguns detalhes mais operacionais e também verificar a
existência de mais alguns problemas que possam não ser de total conhecimento da
gerência. Observaram-se relatos muito parecidos aos apresentados pelas gerências,
deixando claro então, que já se tinham as informações corretas para iniciar o
desenvolvimento do trabalho.
4.1.1 Descrição dos setores da empresa e divisão das responsabilidades
Ao estudar a organização da empresa, observou-se a formação dos setores e a
divisão das responsabilidades.
60
Segundo o RUP (RUP, 2007), as responsabilidades dos colaboradores são
divididas por papéis, onde um colaborador pode assumir mais de um papel. Na empresa,
observou-se que a principal divisão era de gerência e colaboradores, sem maior
detalhamento.
Naturalmente algumas responsabilidades eram atribuídas a um ou outro
colaborador, mas não existe uma organização clara dos papéis, e se existe, é feita de
forma muito informal e não documentada.
Sobre os setores, estes são bem definidos e cada um tem sua função bem
clara, são eles desenvolvimento, implantação, suporte, comercial e administrativo.
4.1.1.1 Desenvolvimento
O setor de desenvolvimento é responsável pela criação e manutenção dos
softwares comercializados pela empresa. Seus colaboradores são responsáveis pela
análise, projeto, codificação e manutenção dos softwares. É sobre este setor que este
trabalho tem seu maior foco.
Os colaboradores deste setor são divididos apenas pelos sistema que eles
atendem. Observa-se a necessidade de redistribuição dos papéis entre os colaboradores,
aplicando maior detalhamento em nível de atribuições e tarefas, incluindo gerentes e
colaboradores.
Figura 11 – Setor de desenvolvimento Fonte: entrevista com gerentes.
Atualmente, o setor conta com dez colaboradores, sendo que destes, sete são
programadores envolvidos diretamente com o principal produto da empresa, o Procel G3.
61
4.1.1.2 Implantação
O setor de implantação é responsável por acompanhar todo o processo de
implantação do software nos clientes. São eles que fazem o levantamento da situação das
empresas, suas necessidades, configuram o software, negociam ajustes no software para
adaptar à necessidade da empresa, orientam, realizam treinamentos e acompanhamento
inicial, até que a empresa entre em produção com o software.
O setor de implantação realiza implantações apenas do produto Procel G3, isso
devido ao foco que a empresa dá ao produto e também por suas características, como a
necessidade de um processo específico de implantação. Os demais produtos da Procel
são implantados diretamente pelo setor de suporte.
Identifica-se que os profissionais da implantação devem ser bons conhecedores
das regras de negócio do ramo de atividade das empresas que são atendidas. A
qualidade deste acompanhamento na empresa, nesta fase considerada crítica, pode ser a
diferença entre o sucesso e o fracasso do projeto de implantação.
Os clientes são atendidos por este setor somente durante um determinado
tempo chamado de período de implantação. Nesta fase, os profissionais de implantação
alocam muitas horas de sua agenda para o atendimento destes clientes. Normalmente,
um implantador não mantém mais que três clientes em implantação ao mesmo tempo.
Figura 12 – Setor de implantação Fonte: entrevista com gerentes.
Este setor faz a implantação somente do Procel G3, os demais sistemas tem
nível de complexidade menor e são instalados pelo setor de suporte.
Após o período de implantação, o cliente passa a ser atendido pelo setor de
suporte.
62
4.1.1.3 Suporte
O setor de suporte é responsável pelo atendimento aos clientes que já tiveram
a implantação realizada.
Após o setor de implantação terminar o processo de implantação do software,
com avaliação final e aprovação do cliente, o cliente passa a ser atendido pelo setor de
suporte.
No período de suporte, o nível de solicitações do cliente cai bastante, e as
atividades desenvolvidas focam-se mais em atendimento a dúvidas de operação,
treinamento de novos funcionários dos clientes, suporte a problemas de software ou de
estrutura que impactam no correto funcionamento do sistema.
Os colaboradores do suporte podem ter menos conhecimento do
funcionamento global das empresas, porém conhecem mais detalhes operacionais do
software, podendo ser responsáveis pelo atendimento de mais de 15 clientes por
colaborador.
Figura 13 – Setor de suporte Fonte: entrevista com gerentes.
O setor de suporte conta atualmente com dez colaboradores, sendo quatro para
o Procel G3, três para os produtos Loja Light e Checkwin e dois para os sistemas
modulares DOS.
Os produtos Loja Light, Checkwin e sistemas modulares são implantados
diretamente pelo setor de suporte, pois tem menor nível de complexidade.
4.1.1.4 Comercial
O setor comercial é responsável pela comercialização do produto, prospecção
de revendas, estudo de necessidades de mercado e outras atividades não técnicas que
63
objetivam divulgar os produtos e a empresa no mercado nacional. O setor comercial não
será estudado neste trabalho.
4.1.1.5 Administrativo
O setor administrativo engloba as demais áreas da empresa como financeiro,
recursos humanos, operacional, limpeza e conservação e não serão estudadas neste
trabalho.
4.1.2 Métodos atuais de controle dos trabalhos
A seguir são apresentados alguns métodos de controle existentes na empresa.
4.1.2.1 Software para controle de tarefas – Call Organizer
A Procel controla seu fluxo de trabalho per meio do Call Organizer – CO,
desenvolvido em Delphi, pela própria equipe da Procel.
O CO faz a administração do fluxo de trabalho de todos os colaboradores da
Procel, sem exceção, e sua indisponibilidade compromete diretamente o andamento dos
trabalhos.
O CO possui uma lista com todos os clientes e contatos corporativos, bem
como os sistemas dos clientes e o status de relacionamento com a Procel. Possui
também uma lista padrão com todos os chamados que estão sob responsabilidade do
técnico logado, bem como consultas personalizadas.
Os técnicos, os setores, e os sistemas comercializados pela empresa também
são cadastrados e administrados pelo sistema.
64
Figura 14 – Tela principal do CO Fonte: PROCEL, 2008a.
Para cada ocorrência ou atividade a ser lançada no CO, é aberto um chamado.
Neste chamado é informado o cliente que esta sendo atendido, o sistema que ele utiliza, a
pessoa de contato, o assunto e uma seqüência de textos adicionada a cada nova
interação com este chamado.
65
Figura 15 – Tela de edição de um chamado Fonte: PROCEL, 2008a.
4.1.2.2 Software para controle de compartilhamento de código-fonte – Jedi VCS
A administração do compartilhamento de códigos fonte dos softwares é feita
pelo Jedi Version Control System.
O Jedi é uma aplicação de livre distribuição e está disponível para download
diretamente pelo site (JEDI, 2008). Os códigos fontes dos programas ficam armazenados
em um banco de dados no servidor da empresa, e os clientes (os desenvolvedores)
utilizam uma interface para se conectar e solicitar acesso aos fontes.
66
Figura 16 – Formulário principal do Jedi Fonte: JEDI, 2008.
O acesso à edição de um arquivo de código fonte, exige login no Jedi, a
seleção do projeto e o arquivo desejado e a solicitação do seu Check Out. É registrado no
servidor que este arquivo está em uso pelo usuário que o solicitou.
Figura 17 – Formulário de Check Out Fonte: JEDI, 2008.
Após realizar as modificações necessárias, o desenvolvedor seleciona o
arquivo no Jedi e solicita o Check In, enviando assim o arquivo alterado para o servidor.
O Jedi já está em uso pela empresa à cerca de nove anos.
67
4.1.3 Relacionamento dos problemas detectados
Em cada setor foram identificados problemas em seus processos conforme
relacionados a seguir:
Para cada problema, será apresentado um nome resumido e uma descrição. O
nome resumido será utilizado para identificar rapidamente o problema.
4.1.3.1 Desenvolvimento
1 - Dificuldade na priorização das atividades - Dificuldade na administração das
prioridades das atividades de desenvolvimento.
2 - Incompatibilidade entre ambientes de desenvolvimento - Problema de
incompatibilidade de configuração de ambiente de desenvolvimento, gerando
executáveis com características diferentes com o mesmo código fonte em
computadores diferentes.
3 - Dificuldade na administração das versões - Dificuldade na identificação e
controle das versões geradas pelos vários desenvolvedores.
4 – Performance do software insatisfatória - Problemas de performance em
vários pontos do sistema e de forma crítica em alguns procedimentos de alto
uso no sistema.
5 – Padronização de código inadequada - Código confuso e não totalmente
padronizado.
6 – Desconhecimento das regras de negócio do software - Falta de
conhecimento global sobre as regras de negócio do produto.
7 – Solicitações mal definidas - Desenvolvedores nem sempre recebem as
solicitações bem definidas.
8 – Ausência de processo de teste de software - Não existe um processo bem
definido de teste de software.
9 – Dificuldade na análise sobre o rendimento dos desenvolvedores.
10 – Dificuldade no controle das tarefas em andamento.
68
4.1.3.2 Implantação
1 - Pouco conhecimento de negócio dos analistas de implantação.
2 - Índice insatisfatório de comprometimento dos colaboradores com o resultado
final.
3 - Falta de material de treinamento para técnicos e usuários.
4.1.3.3 Suporte
1 - Pouco conhecimento do produto para boa parte dos colaboradores
2 - Excesso de clientes por técnico
4.1.4 Classificação dos problemas por prioridade
A partir da identificação, os problemas foram classificados por prioridade
observando-se o possível impacto na qualidade do processo,
Para a classificação por prioridade atribuímos os valores de 1 a 3 com as
seguintes importâncias:
1 – Alta – Serão os primeiros problemas a serem resolvidos, apontados pela
gerência como fundamentais.
2 – Média – São os problemas que apresentam um impacto menor mas que
também afetam o processo de qualidade.
3 – Baixa – São os problemas de menor prioridade e com baixo impacto na
qualidade do processo e que srão trabalhados futuramente.
A seguir apresentamos a tabela com a classificação por prioridade de cada
problema detectado.
69
Tabela 1 - Lista de problemas classificadas por prioridade
Problema Prioridade
1 – Desenvolvimento
1.1 - Dificuldade na priorização das atividades 1
1.2 - Incompatibilidade entre ambientes de desenvolvimento 1
1.3 - Dificuldade na administração das versões 1
1.4 - Performance do software insatisfatória 1
1.5 – Padronização de código inadequada 2
1.6 - Desconhecimento das regras de negócio do software 2
1.7 - Solicitações mal definidas 1
1.8 - Ausência de processo de teste de software 3
1.9 – Dificuldade na análise sobre o rendimento dos desenvolvedores 2
1.10 – Dificuldade no controle das tarefas em andamento 2
2 – Implantação
2.1 - Pouco conhecimento de negócio dos analistas de implantação 2
2.2 - Índice insatisfatório de comprometimento dos colaboradores com o resultado final
2
2.3 - Falta de material de treinamento 1
3 – Suporte
3.1 - Pouco conhecimento do produto para boa parte dos colaboradores
2
3.2 - Excesso de cliente por técnico 2 Fonte: Elaboração dos autores, 2007.
4.1.5 Seleção dos problemas que serão tratados
Finalizada a etapa de identificação e priorização dos problemas, foram
determinados alguns que serão objeto de proposta de solução durante o período de
execução deste projeto.
A seguir é apresentada a descrição detalhada dos problemas selecionados.
70
4.1.5.1 Dificuldade na priorização das atividades de desenvolvimento
O grande volume de chamados enviados ao desenvolvimento e o número
considerável de desenvolvedores, faz com que a distribuição de tarefas entre eles se
torne uma tarefa demorada, consumindo duas ou mais horas por dia e ainda assim com
alta possibilidade de erro humano.
Para delegar uma tarefa a um desenvolvedor, o gerente deve considerar muitas
características como complexidade da tarefa, necessidade de análise técnica mais
apurada, perfil e experiência do desenvolvedor para a tarefa, nível de pressão do cliente,
prazo necessário, entre outros. Após tomar a decisão, a tarefa é enviada ao
desenvolvedor pelo software CO e fica em sua lista de tarefas aguardando o início de sua
execução. E assim é feito com cada nova tarefa, o que contabiliza uma média de quinze
novas tarefas por dia.
Com o passar dos dias, cada desenvolvedor fica com dezenas de tarefas
esperando o início da produção, e é extremamente comum o gerente ficar olhando a lista
de tarefas de cada um, alterando a prioridade, trocando de desenvolvedor, devido a
constante reavaliação das prioridades, vinda da comunicação com as demais gerências,
pressões de clientes, estimativas iniciais imprecisas, e assim por diante. Ocorre que para
esta administração, o gerente de desenvolvimento deve saber constantemente de tudo o
que ocorre com os desenvolvedores, os clientes e principalmente, o software, pois além
de todo o fluxo de trabalho, ainda é necessário decidir sobre todas as implementações de
software mantendo assim conhecimento sobre o escopo do produto de software.
Para que as demais gerências da empresa saibam do andamento das tarefas,
estas tem que consultar a lista de tarefas de cada um dos 10 desenvolvedores, ou então
questionar diretamente a gerência que por sua vez tem que obter conhecimento sobre a
situação atual das tarefas para disponibilizar a resposta.
O resultado deste fluxo de trabalho adotado é a sobrecarga na gerência de
desenvolvimento, que acaba muitas vezes falhando nesta tarefa. As informações
imprecisas e não disponíveis de forma rápida, dificultam decisões estratégicas de outros
setores, principalmente no que diz respeito ao contato com o cliente, pois por regra geral,
a equipe de desenvolvimento não se relaciona com o usuário final, apesar de ocorrerem
71
exceções. Respostas a solicitações de clientes não são dadas de forma rápida, gerando
descontentamentos.
Este fluxo de trabalho também faz com que a gerência não possa se ausentar
por muito tempo, pois outros gerentes terão dificuldade de administrar o andamento
destes trabalhos.
4.1.5.2 Incompatibilidade entre ambientes de desenvolvimento
Os executáveis do Procel G3 para serem compilados com sucesso e ter todas
as suas características pré-determinadas, dependem de uma série de configurações de
ambiente de sistema operacional e do Delphi. A equipe conta com 10 programadores com
seus 10 computadores, onde os executáveis são gerados conforme cada programador
conclui sua tarefa. As não conformidades ou incompatibilidades são ocasionadas por
configurações inadequadas de ambiente. São situações como tamanho do executável que
varia em quase 100%, mensagens de caixa de diálogo que em inglês ao invés de
português, configuração de localização de código-fonte de projeto que faz um executável
ser compilado com uma versão errada de código-fonte, entre outros problemas.
4.1.5.3 Dificuldade na administração das versões
Ao se concluir um trabalho de desenvolvimento de qualquer natureza, faz-se
necessária a distribuição do novo executável gerado para os respectivos destinos.
Exemplo: um cliente relata um bug no sistema, o desenvolvedor corrige o bug, e o novo
executável deve ser gerado e entregue ao cliente.
Existem situações onde as configurações de ambiente dos desenvolvedores
não estão totalmente compatíveis. Alterações que são realizadas com o tempo,
possibilitam um código fonte idêntico em duas máquinas, gerando executáveis com
características diferentes.
Também ocorre a possibilidade do desenvolvedor prover uma solução, liberar o
executável ao cliente, e por alguma razão, não armazenar os fontes alterados no
repositório, fazendo com que as demais máquinas da equipe compilem o executável sem
72
aquelas alterações, ou até mesmo ocorrer uma perda do código fonte por um problema na
máquina local.
Mesmo com o código fonte seguro e com o executável gerado, começa a
maratona de armazenar este executável no servidor de arquivos, publicar as informações
sobre as alterações realizadas, relatar no CO que para solucionar o problema relatado é
necessário atualizar o executável por este de versão x.y.z compilado na data “tal”. Como
são muitas versões diferentes e a cópia deve ser feita para vários destinos, é comum o
desenvolvedor esquecer de alguma cópia ou até mesmo copiar para uma pasta errada. A
conseqüência deste erro, é muito custosa, pois só será percebido muito tempo depois
quando um executável errado for instalado em outro cliente podendo gerar dados
incorretos.
4.1.5.4 Performance do Software Insatisfatória.
Ao operar o sistema Procel G3, observa-se em vários pontos, sérios problemas
de performance. Ao abrir alguns formulários, ou executar determinados procedimentos, o
sistema demora muitos segundos, passando muitas vezes do aceitável.
Durante a navegação entre os formulários, um tempo aproximado de 1 a 3
segundos para carregar, o suficiente para irritar o usuário. Também foi observado que
alguns procedimentos específicos demoram muito tempo, além do aceitável. Exemplo:
observou-se que em uma base de dados de um cliente, com cerca de cinco mil produtos
cadastrados, que ao realizar um orçamento, o sistema fica lento ao lançar mais de
cinqüenta itens de orçamento.
4.1.5.5 Padronização de código inadequada
Para o principal produto da empresa, o Procel G3, estão alocados sete
desenvolvedores dedicando-se em tempo exclusivo ao projeto, isso sem considerar
gerentes e outros envolvidos, Esse código é compartilhado entre os desenvolvedores que
utilizam o software Jedi para gerenciar este compartilhamento.
73
A rotatividade de desenvolvedores na Procel é considerada razoável e muitos
deles vem de outras empresas, trazendo padrões e culturas muito diferentes, ao juntar
estas culturas em uma grande equipe focada em um único projeto, o resultado é partes de
códigos escritos de formas diferentes, o que dificulta muito a manutenção. Por se tratar de
um projeto grande e de ciclo de vida longo, a maioria das implementações são de
alterações de características para melhoramento ou edição de regras, e normalmente são
realizadas por desenvolvedores diferentes.
Comentários são hora ausentes e hora excessivos, e muitas vezes não é
identificado o autor da alteração, o que pode ser necessário para uma consulta posterior.
É comum ocorrer de um desenvolvedor olhar uma linha de código e questionar “Quem
escreveu esta porcaria?” ou “Quem foi que desabilitou esta linha que fazia tudo
funcionar?”, e assim por diante.
Observa-se que sem muito controle, vários desenvolvedores editam o mesmo
código, de forma que todos se envolvam, mas ninguém fica efetivamente responsável.
4.1.5.6 Desconhecimento das regras de negócio do software
Os sistemas da Procel são desenvolvidos para controlar regras de negócios
empresariais que conduzem processos como financeiro, faturamento, estoque, compras,
vendas e assim por diante. O conhecimento necessário para implementar nos sistemas
estas regras vem do conhecimento dos gerentes e programadores que vão aprendendo
ao longo dos anos o funcionamento das empresas e assim vão implementando as
soluções.
Este conhecimento não está escrito de forma explícita, e cada novo colaborador
da equipe precisa aprender essas regras utilizando o próprio software sem entender
diretamente as regras. É fato que existe um conhecimento muito valioso de posse dos
principais colaboradores e sócios da empresa, mas este conhecimento precisa sempre
ser consultado diretamente com eles.
74
4.1.5.7 Solicitações mal definidas
As solicitações de ajustes, implementações ou relatos de bug´s nem sempre
são bem definidas, sendo comum os textos serem escritos de forma muito resumida e
sem a preocupação de transmitir a informação de forma completa.
Em caso de bug´s, normalmente seus relatos não explicam bem como eles
ocorrem, e qual é a situação e ambiente em que é possível simular o bug, para então
corrigi-lo.
Em caso de solicitações de ajustes ou novas implementações, é comum que a
descrição venha de forma incompleta ou se valendo das conversas informais, em casos
extremos, “Conforme conversamos, segue a solicitação sobre o assunto X”. Assim se um
técnico que não participou da discussão se envolver no problema, a documentação
existente não será suficiente para que ele colabore sendo necessário conversar
novamente com quem originou o chamado.
Também é comum que sejam solicitadas algumas soluções para determinados
problemas do cliente, porém a “solução” é estudada por pessoas sem o conhecimento
técnico necessário para propor uma análise, ou que não entendem o problema de fato. É
necessário que um analista experiente entenda realmente o problema para então propor
uma solução.
4.1.5.8 Ausência de processo de teste de software
Atualmente quando uma nova versão é liberada pelo desenvolvimento, esta é
testada apenas pelo próprio desenvolvedor, e as vezes superficialmente pelo técnico que
solicitou o ajuste junto ao cliente. E esta situação facilmente permite que a versão seja
entregue ao cliente com bug´s ou que o entregue não seja exatamente o que foi
solicitado.
75
4.1.5.9 Dificuldade na análise sobre o rendimento dos desenvolvedores
Com uma equipe de dez desenvolvedores onde muitos processos produtivos
ainda não são totalmente definidos e organizados, fica difícil determinar quando um
programador não está tendo o rendimento adequado. Pela falta de controle e medição
pode-se apenas observar de uma forma geral que o rendimento global da equipe está
fraco, ou então analisar o rendimento individual de forma muito subjetiva, sem dados
estatísticos.
4.1.5.10 Dificuldade no controle das tarefas em andamento
Após as tarefas já terem sido iniciadas pelos desenvolvedores, o gerente
precisa constantemente avaliar se elas estão ocorrendo no tempo certo, se o tempo não
está excedendo, se o desenvolvedor precisa de auxílio técnico. Atualmente, o gerente
precisa estar analisando constantemente a lista de chamados de cada um ou mesmo
questionar a cada um como está o andamento do trabalho. Este tempo de análise de toda
a equipe costuma durar cerca de quinze minutos e ocorre várias vezes ao dia. É
necessário uma alternativa para facilitar esta administração.
4.2 ANÁLISE DAS PROPOSTAS DE SOLUÇÃO
Nesta etapa serão apresentadas as propostas de solução para os problemas
identificados.
Para determinar quais seriam as primeiras propostas de solução, foram
observados os problemas identificados como prioridade 1 na tabela de problemas
identificados, (capítulo 4.1.3). Segundo a empresa estes são os problemas que mais
rapidamente devem ser solucionados.
76
4.2.1 Solução para: Dificuldade na priorização das atividades
As propostas de solução para os problemas relacionados a desempenho na
administração da priorização das atividades, foram:
• Implantação da fila de desenvolvimento ;
• Definição do processo de tempo previsto para execução;
• Implantação do gráfico de acompanhamento de chamados em execução;
• Implantação do gráfico de chamados atendidos;
4.2.1.1 Fila de desenvolvimento
Uma das propostas foi a eliminação da lista de tarefas de todos os
desenvolvedores e a criação de uma lista única, chamada fila de desenvolvimento.
Justificativa: a fila de desenvolvimento servirá pra centralizar o processo de
análise das prioridades.
A gerência atualmente perde muito tempo analisando a fila particular de
prioridades de cada colaborador, o que também gera muito descontentamento. Observa-
se que o trabalho mais importante e que realmente não deve ser eliminado é o de análise
de cada chamado e a essência de seu conteúdo.
A centralização destas prioridades também deve permitir que todos os setores
se envolvam no processo de decisão sobre a priorização dos chamados.
Resultados Esperados: com uma única fila de prioridades relacionadas ao setor
de desenvolvimento, espera-se que a tarefa de administração das prioridades fique muito
mais fácil e rápida, focando os esforços da gerência apenas na priorização dos chamados
e análise de seus conteúdos. Espera-se também que a partir de então, todos os setores
possam visualizar esta fila de forma a estarem cientes sobre as decisões de priorização.
A programação de projeto envolve dividir o trabalho total de um projeto em atividades distintas e avaliar o tempo necessário para completar essas atividades. De modo geral, algumas dessas atividades são realizadas em paralelo. Os programadores de projeto devem coordenar essas atividades paralelas e organizar o trabalho, de modo que a força de trabalho seja otimizada. Eles devem evitar uma
77
situação em que todo o projeto é atrasado porque uma tarefa importante não foi concluida. (SOMMERVILLE, 2005, p. 66).
Funcionamento: por regra geral, cada desenvolvedor terá sempre uma única
tarefa em sua lista de tarefas, que será a que está em desenvolvimento naquele
momento.
A forma de funcionamento dessa proposta é mostrada na figura a seguir.
Figura 18 – Fluxo de processo utilizando a fila de desenvolvimento Fonte: Elaboração dos autores, 2008.
78
Todas as tarefas novas são analisadas e colocadas em uma fila única, chamada
Fila de Desenvolvimento. Assim, o gerente de desenvolvimento faz a análise técnica,
registra o parecer, e envia para a fila de desenvolvimento, ficando na última posição.
Cada tarefa da fila de desenvolvimento, terá uma prioridade que vai de 1 até o
número de tarefas da fila. A primeira tarefa da fila será sempre a de número 1 e será a
próxima a ser iniciada por qualquer um dos desenvolvedores.
Prioridade Cliente Assunto Sistema
1 Mercado ABC Ajuste no relatório de inventário G3 Comercial 2 Super Peça Auto Peças Bug ao cadastrar produto G3 Comercial
3 Super Peça Auto Peças Rateio de desconto entre itens não est... Checkwin
4 Xyz Atacado Verificar sincronização Palm G3 Comercial
5 Mercado ABC ECF com problema no fechamento da... Checkwin
6 Mercado ABC Código de barra gerado pela balança ... Checkwin
Figura 19 – Simulação de fila de desenvolvimento Fonte: Elaboração dos autores, 2007.
O CO, quando acessado por um usuário do setor de desenvolvimento, deverá
ter uma opção “Obter chamado” que vai automaticamente selecionar a primeira tarefa da
fila de desenvolvimento e alocar para o desenvolvedor, já a colocando na situação “em
desenvolvimento”.
A princípio, as tarefas da fila de desenvolvimento poderão ser obtidas por
qualquer desenvolvedor, mas existem situações onde é necessário fazer um
direcionamento específico. Para isso, o gerente antes de enviar uma tarefa para a fila de
desenvolvimento, poderá opcionalmente, determinar qual ou quais os desenvolvedores
que estão aptos a iniciar esta tarefa. Se o gerente não informar nada, qualquer
desenvolvedor poderá resolvê-la.
Prioridade Cliente Assunto Sistema Técnico
1 Mercado ABC Ajuste no relatório de inventário G3 Comercial [qualquer] 2 Super Peça Auto Peças Bug ao cadastrar produto G3 Comercial [qualquer]
3 Super Peça Auto Peças Rateio de desconto entre itens ... Checkwin José 4 Xyz Atacado Verificar sincronização Palm G3 Comercial Maria, José 5 Mercado ABC ECF com problema no fechame... Checkwin [qualquer]
6 Mercado ABC Código de barra da balança dev... Checkwin [qualquer]
Figura 20 – Simulação de fila de desenvolvimento com indicação de técnico Fonte: Elaboração dos autores, 2007.
79
Assim, se a primeira tarefa da fila estiver alocada para o desenvolvedor A ou B,
e o desenvolvedor C acionar a opção “Obter chamado”, o CO vai buscar a próxima tarefa
da fila, realizando a mesma verificação, e assim por diante.
4.2.1.1.1 Alteração de prioridade dos chamados da fila de desenvolvimento
O gerente deverá ter a possibilidade de alterar a qualquer momento a ordem
dos chamados da fila de desenvolvimento, de forma rápida e prática.
Figura 21 – Fluxo para alteração de prioridade dos chamados da fila de desenvolvimento Fonte: Elaboração dos autores, 2008.
A sugestão é que ele possa com o mouse, clicar, arrastar e soltar uma tarefa
sobre outra, assumindo assim uma nova posição, e reorganizando assim o número de
prioridade das demais.
Figura 22 – Alteração de prioridade utilizando o mouse Fonte: Elaboração dos autores, 2007.
80
O gerente também deverá ter condição de delegar esta alteração de prioridade
para outras gerências, como a gerência de implantação, que tem sempre o conhecimento
mais atualizado das maiores necessidades e prioridades dos usuários finais.
4.2.1.1.2 Visibilidade da fila de desenvolvimento
A fila de desenvolvimento deve ser visualizada por todos os usuários do CO, o
que compreende toda a organização, de forma que todos saibam em tempo real, as
próximas tarefas que entrarão em produção. Lembrando que apenas os gerentes podem
editá-la.
De posse destas informações, todos os colaboradores que fazem contato com
os clientes em atendimento, terão informações sobre o que está sendo feito para eles.
4.2.1.2 Tempo previsto para execução
Quando um gerente inclui uma tarefa na fila de desenvolvimento, ou quando o
desenvolvedor inicia seu desenvolvimento, deverá ser negociado entre gerente e
desenvolvedor o tempo previsto para a execução, que deverá ser estimado em horas e
informado no chamado em um campo específico para esta finalidade.
Figura 23 – Fluxo para determinação do tempo previsto Fonte: Elaboração dos autores, 2008.
Segundo Sommerville (2005, p. 65) “Os gerentes estimam o tempo e os
recursos exigidos para completar as atividades e os organizam em uma seqüência
coerente”.
Existe uma variação muito grande no tempo de execução dos chamados
podendo variar entre minutos e semanas, e quando um chamado previsto para quatro
81
horas, ultrapassou seu prazo, passa a ser necessário o acompanhamento técnico de
algum colega ou do próprio gerente.
A gerência deverá ter uma forma prática de detectar quando um desenvolvedor
ultrapassa o tempo previsto.
4.2.1.3 Gráfico de acompanhamento de chamados em execução
Deverá ser criado um gráfico para apresentar o tempo já investido por cada
desenvolvedor no chamado em execução no momento, comparando sempre o tempo
previsto com o realizado, conforme figura abaixo.
Figura 24 – Formulário de Check Out Fonte: Elaboração dos autores, 2007.
O gráfico deverá ter para cada desenvolvedor duas barras, uma na cor azul
para o tempo previsto e outra para o tempo realizado, ficando verde quando o tempo for
menor que o previsto e vermelho quando maior. Se por alguma razão, não for definido o
tempo previsto, deve ficar apenas uma barra de cor neutra com o tempo realizado.
Logo abaixo do gráfico devem ser listados os chamados em desenvolvimento
por desenvolvedor, possibilitando a rápida análise da relação do tempo com o assunto do
chamado.
Este gráfico poderá ficar visível a todos, tornando público inclusive o
desempenho pessoal de cada desenvolvedor.
82
4.2.1.4 Gráfico de chamados atendidos
Deverá ser criado um gráfico disponível apenas para a gerência, apresentando
o rendimento de cada desenvolvedor por semana.
Este rendimento poderá ser calculado de duas formas.
• Quantidade de chamados atendidos por período
A forma mais simples do gráfico seria apresentar simplesmente a quantidade de
chamados atendidos por cada desenvolvedor por período, onde sugerimos um período
semanal.
Figura 25 – Gráfico de chamados atendidos Fonte: Elaboração dos autores, 2007.
Esta apresentação não oferece uma leitura muito precisa pois o tempo
necessário para cada chamado varia em grandes proporções, porém, sabe-se que as
informações necessárias para construir este gráfico já estão disponíveis no CO, sendo
necessário apenas montar o gráfico.
83
• Média do rendimento.
Para este gráfico devemos calcular o rendimento para cada chamado e então
fazer uma média do rendimento por período.
Segundo Humphrey (apud Sommerville 2005, p. 484):
O conjunto de métricas de processo é essencial para a melhoria do processo. Ele também sugere que a medição tem um importante papel a ser desempenhado, em menor escala, na melhoria de processos de pessoal.
O rendimento será obtido pela relação tempo previsto/tempo realizado. Assim,
se o desenvolvedor demorou cinco horas para realizar um trabalho previsto de cinco
horas, seu rendimento foi de 100%. Se tivesse feito em seis horas, seu rendimento seria
de 83,3%.
Figura 26 – Gráfico de rendimento dos desenvolvedores Fonte: Elaboração dos autores, 2007.
Para que este gráfico apresente dados concisos, é necessário que todos os
chamados tenham o tempo previsto informado, e para isso é necessário que o
preenchimento desta informação torne-se um hábito, ou então, deve-se criar uma regra
para que nenhum chamado possa ser colocado na fila de desenvolvimento ou seja
enviado para um desenvolvedor, sem o tempo previsto informado.
Segundo Sommerville (2005, p. 484) “As métricas de processo propriamente
ditas podem ser utilizadas para avaliar se a eficiência de um processo foi melhorada ou
não. Por exemplo, o esforço e o tempo devotados a testes podem ser monitorados”.
84
4.2.2 Solução para padronização de código inadequada
Para melhorar e normatizar a padronização do desenvolvimento de software
melhorando assim a qualidade do código fonte, propõe-se algumas soluções, entre elas:
• Criação do manual de padronização
• Validação do código fonte por um coach2
A padronização da escrita do código fonte é fundamental para que toda a
equipe tenha um entendimento comum e se comuniquem adequadamente através deste
código fonte. Decisões importantes de projeto devem ser comentadas nos locais onde
estas impactaram mudanças de código fonte. Nomes de variáveis e componentes devem
seguir uma nomenclatura única e conhecida por todos.
A empresa já teve algumas iniciativas de padronização com resultados
razoáveis, mas atualmente não existe um método de controle que impeça uma falha de
padronização de ir para o repositório.
A proposta é criar um manual de padronização e um processo de verificação de
padronização antes de realizar o Check In dos códigos fontes no repositório.
Figura 27 – Fluxo de verificação de padronização Fonte: Elaboração dos autores, 2007.
2 Coach – Termo do inglês que significa técnico, no contexto de desenvolvimento usa-se para denotar o programador mais experiente da equipe.
85
4.2.2.1 Criação do manual de padronização
O manual de padronização será uma pequena cartilha que apresentará o
método de padronização adotado de forma objetiva. O manual deverá ter poucas páginas,
ser de rápida leitura, e com exemplos baseados no próprio Procel G3, de forma a agilizar
ao máximo o entendimento em relação ao conhecimento do fonte.
As equipes de garantia de qualidade que estiverem desenvolvendo padrões, normalmente deverão basear os padrões organizacionais nos padrões nacionais e internacionais. Com a utilização desses padrões, como ponto de partida, a equipe de garantia de qualidade deve elaborar um manual de padrões, que deve definir aqueles apropriados para sua organização. (SOMMERVILLE, 2005, p. 461).
As regras do manual devem ser criadas considerando um comum acordo de
todos os desenvolvedores, de forma que todos assumam o compromisso de segui-las.
Quando um novo desenvolvedor integrar a equipe, ele facilmente poderá se
adaptar ao padrão de desenvolvimento, pois ele inicialmente terá acesso ao manual e em
seguida encontrará um código fonte e uma cultura de equipe em acordo com este manual.
Em acordo com o setor de desenvolvimento, foi observado a necessidade de
padronizar e documentar os seguintes itens:
• Preparação de computador de desenvolvimento
• Configurações de ambiente de desenvolvimento
• Manualização de regras para edição do banco de dados
• Padronização de código-fonte
o Identação
o Declaração de variáveis
o Organização de functions e procedures nos códigos fontes
o Normas para escrita de comentários
o Normas para comentar o relacionamento das alterações
realizadas com os números dos chamados do CO
86
4.2.2.2 Validação do código fonte por um coach
Este processo propõe que um desenvolvedor da equipe solicite a validação de
um colega da equipe designado para esta função.
O processo de verificação de padronização será executado antes de o
desenvolvedor fazer o Check In dos códigos fontes no repositório. Este processo vai
envolver o desenvolvedor e um coach. O coach é um dos desenvolvedores integrantes da
equipe que vai receber a atribuição de fazer a verificação dos códigos fontes
desenvolvidos por seus colegas. Para o desenvolvedor apresentar o código alterado ao
coach de forma rápida e prática, ele deverá entrar no Jedi, e executar a opção Diff/Merge
Module que lista as diferenças entre dois arquivos de código fonte. O primeiro arquivo
será o que está em Check Out com o desenvolvedor e o segundo será o último arquivo
válido adicionado no repositório. A opção Diff/Merge Module vai listar os dois arquivos
lado a lado, apresentado indicativos que quais linhas foram adicionadas, excluídas ou
editadas. Assim, o coach poderá fazer uma leitura rápida e conferir se as novas
alterações estão padronizadas, assim como também poderá fazer alguma eventual crítica
ou questionamento sobre o próprio código.
Figura 28 – Diff/Merge do Jedi, comparando duas versões de código fonte. Fonte: JEDI, 2008.
87
Na figura anterior, pode-se observar:
1 – Código fonte em Check Out, alterado pelo programador.
2 – Indicador de linhas incluídas, excluídas ou alteradas.
3 – Versão anterior do código fonte armazenado no repositório.
4 – Exemplo de código fonte que existia na versão do repositório e foi excluída
e alterada.
Pode-se comparar este processo com um dos critérios da metodologia ágil XP,
que propõe a programação em pares, porém, nesta proposta, o acompanhamento de um
segundo desenvolvedor é feito apenas na fase de conclusão do trabalho.
4.2.3 Solução para: Dificuldade na administração de versões e incompatibilidade entre ambientes de desenvolvimento
Para facilitar e automatizar a compilação e administração de versões, e resolver
o problema de incompatibilidade entre ambientes de desenvolvimento, foram
desenvolvidas as seguintes soluções:
• Criação do computador compilador de executáveis do G3
• Criação do aplicativo compilador do G3 – CompG3
• Implementações no Call Organizer para integração com o CompG3
Para automatizar o processo de geração de versão de sistemas, a proposta é a
preparação de um computador que será utilizado exclusivamente para compilar os
executáveis. Este computador deverá ser chamado de compilador.
Quando um programador concluir um trabalho de desenvolvimento, ele deverá
enviar os arquivos de código fonte ao repositório do Jedi, ir no compilador e através de
um processo automatizado, “solicitar” a compilação do sistema desejado.
Para forçar o processo de documentação dos trabalhos realizados e gerar um
histórico de relacionamentos entre os chamados do CO com as alterações executadas, o
88
desenvolvedor deve informar no chamado o sistema e a versão que está trabalhando e
que deseja compilar, em seguida, no compilador, deve informar o código do chamado em
um aplicativo desenvolvido para este fim, e este vai conectar a base de dados do CO para
verificar quais são as versões que devem ser compiladas.
O compilador também será um cliente do Jedi, pois antes de iniciar uma
compilação, ele deve conectar ao repositório para sincronizar o código fonte das versões
que serão compiladas.
Uma alternativa mais recente é a integração continua. Nela você integra de forma freqüente e continua, se não continuamente. O uso de uma ferramenta como o CVS torna isso mais fácil. A qualquer momento, você pode atualizar seus arquivos de trabalho através de repositório.(eXtreme programming, 2002, pág. 164).
Os esforços da equipe de desenvolvimento concentram-se 80% sobre o projeto
G3. Por este projeto ser o mais importante para a empresa e por ter características
específicas de configuração de ambiente de desenvolvimento, a solução proposta estará
focada apenas para o projeto Procel G3.
4.2.3.1 Implementações necessárias do Call Organizer
Para formar um relacionamento não apenas textual dos chamados do CO com
as versões geradas, deverão ser feitas algumas implementações no CO para que este
possa receber as indicações de versões.
No formulário do chamado, na caixa de texto escrita pelo usuário deve ser
disponibilizado uma opção que dará acesso a outro formulário onde será informado o
sistema e as versões. Os sistemas e cada versão existente deverão ser previamente
cadastrados.
O gerenciamento de versões e releases consiste no processo de identificar e acompanhar o desenvolvimento de diferentes versões e releases de um sistema. Os gerentes de versão preparam procedimentos, a fim de garantir que diferentes versões de um sistema possam ser acessadas quando necessário e que elas não sejam modificadas acidentalmente. Eles também podem trabalhar com o pessoal responsável pelo relacionamento com o cliente para planejar quando novos releases de um sistema devem ser distribuidos. (SOMMERVILLE, 2005, p. 556).
Para o controle das versões do G3 deverá ser utilizados quatro números
indicativos:
89
Formato “V.v.R.B”, onde:
• V - versão principal
• v - sub-versão
• R - release
• B - build
No CO, para cada sistema, deverá ser cadastrado a versão até o terceiro
número, ou seja “V.v.R”. Pois esta é a versão de um projeto, e sobre esta, são tomadas as
decisões de implementação, da mesma forma, no Jedi e nas pastas locais, os projetos do
G3 estão cadastrados e organizados por versão no formato “g3 – V.r.R”. A informação do
build representada pelo quarto número, será disponibilizada através da leitura do build
diretamente do executável gerado pelo Delphi, pois este possui um método de auto
incremento de numeração de builds.
4.2.3.2 O computador compilador
O compilador deverá ser um computador desktop com um processador de alto
desempenho, deve estar conectado e ter identidade própria na rede da empresa. O
compilador não precisa ter monitor de vídeo.
Para preparação do compilador, sugerimos um computador desktop com as
seguintes configurações:
• Processador Intel Pentium de 2 GHz ou compatível
• Memória RAM de 1 Gb
• Disco rígido de 160 Gb ou superior
• Placa de rede
• Mouse, teclado, caixa de som e demais periféricos básicos
• No break
A seguir serão apresentados os aplicativos que devem ser instalados no
compilador que vão viabilizar a compilação e a solução proposta.
90
4.2.3.2.1 Jedi
Deverá ser instalado o Jedi. Nos testes realizados, foi utilizado a versão 2.4 que
já estava em uso na empresa contendo as características necessárias para o processo
proposto.
O Jedi será utilizado para sincronizar o código fonte do G3 no compilador para
ser compilado em seguida pelo Delphi.
O administrador deve cadastrar no repositório de Jedi, um usuário chamado
“compilador” que deve ter acesso a todos os projetos do repositório somente para leitura,
a senha deste usuário deverá ser conhecida pelo aplicativo compilador CompG3.
Para realizar a sincronização, será utilizado o Jedi em sua versão de linha de
comando, o jvcs.exe, que será executado a partir do aplicativo CompG3.
4.2.3.2.2 Delphi e os componentes do G3
Deverá ser instalado a linguagem Delphi versão 6, assim como os pacotes de
componentes do Procel G3. Este processo, apesar de ainda manual, pode ser realizado
sem dificuldades pela equipe de desenvolvimento.
Ao final deste processo deverá ser possível executar uma compilação “manual”
do Procel G3.
4.2.3.2.3 WinRAR
Deverá ser instalado o aplicativo compactador WinRAR, já utilizado pela
empresa. Ele será utilizado para realizar as cópias de segurança e compactar os
executáveis que serão distribuídos após compilados.
91
4.2.3.2.4 VNC
Deverá ser instalado o aplicativo de controle remoto Virtual Network Computing
- VNC. Ele será utilizado para que os desenvolvedores possam ter acesso ao compilador
sem necessidade de deslocamento. A versão já em uso pela empresa é a 4.0 (REALVNC,
2008).
4.2.3.3 O aplicativo compilador do G3 – CompG3
Para viabilizar a compilação automatizada deverá ser desenvolvido um
aplicativo específico com as seguintes funções: irá conectar ao repositório do Jedi para
atualizar o código fonte, executar o Delphi para realizar a compilação, realizar cópias de
segurança do código fonte e executável.
De modo geral, os processos de gerenciamento de configuração são padronizados e envolvem a aplicação de procedimentos predefinidos. Eles exigem o gerenciamento cuidadoso de quantidades de dados muito grandes, e a atenção aos detalhes é essencial. Quando de constrói um sistema a partir de versões de componentes, um único erro de gerenciamento de configuração pode significar que o software não funcionará adequadamente. Como conseqüência, a ferramenta CASE de apoio é essencial para o gerenciamento de configuração... (SOMMERVILLE, 2005, p. 562).
Este aplicativo poderá ser desenvolvido em Delphi pela própria equipe da
Procel. Não é objetivo desta monografia envolver-se no processo de desenvolvimento
deste aplicativo, e sim apenas, observar se os resultados foram alcançados.
O CompG3, como poderá ser chamado, terá como entrada de dados, apenas o
usuário desenvolvedor e os números dos chamados que ele trabalhou.
Após informar os chamados, o CompG3 vai se conectar ao banco de dados do
CO para ler os chamados informados e obter dele, o registro das versões informadas em
cada chamado, em seguida, estas versões serão apresentadas ao usuário para que este
possa conferir se as versões a serem compiladas conferem com as que ele trabalhou.
Caso tenha ocorrido algum esquecimento ou engano do usuário, ele será forçado a
cancelar a compilação, voltar ao CO em sua estação de trabalho e informar as versões
corretas para então continuar.
92
Quando um programador trabalha em um chamado do CO, é comum que as
implementações sejam realizadas em várias versões do G3, bem como é comum que ele
reúna vários chamados com pequenos ajustes e deseja compilar tudo de uma vez só. Por
esta razão, caso o usuário informe vários chamados, e nestes tiver versões repetidas, o
CompG3 deverá ter o cuidado de não repetir uma compilação da mesma versão.
Para iniciar a compilação de uma versão, o compG3 deverá executar os
seguintes procedimentos:
1 – Apagar todas as pastas que contem códigos fontes do G3 do compilador. Os
códigos fontes ficam sempre armazenados em “D:\fontes procel\fontes g3\g3 V.v.r”. Isso
vai garantir que falhas de configuração do Delphi apontem para versões erradas sem
impedir a compilação.
2 – Verificar se o usuário não tem algum arquivo em CheckOut no Jedi. Caso
houver, não permitir a compilação.
3 – Conectar-se ao Jedi, executando o jvcs.exe, para sincronizar a versão
desejada. O nome do projeto no Jedi chama-se sempre “g3 – V.v.R”, exemplo: “g3 –
1.5.3”.
4 – Apagar o último executável gerado.
5 – Executar o Delphi como linha de comando enviando os parâmetros “-c” que
indica o início imediato da compilação e o nome do arquivo de projeto da versão, que é
um arquivo de extensão “dpr” localizado na pasta da versão compilada.
6 – Após compilar, verificar se o novo executável foi gerado.
7 – Ler diretamente do executável, a informação completa de versão, no
formato “V.v.R.B”. Esta informação deverá estar disponível devido a uma opção do Delphi
que disponibiliza e incrementa de forma automática o build a cada compilação.
8 – Fazer uma cópia de segurança da pasta de fontes e armazenar em uma
pasta de backup a ser escolhida pela empresa.
9 - Guardar em uma pasta de backup uma cópia do executável gerado,
alterando seu nome, incluindo a versão e a data, de forma a ficar facilmente reconhecido,
exemplo: “g3com 1.5.3.247 de 15-01-2008.exe”.
93
10 – No banco de dados do CO, fazer um registro na tabela de builds, indicando
o novo build gerado, relacionando à versão.
11 – Nos chamados do CO informados no CompG3, adicionar o seguinte texto:
“Versões geradas automaticamente pelo compilador:” e em seguida relacionar todas as
versões geradas naquele momento, contendo todas as informações do executável.
12 – Modificar o status do chamado para “Executado”. Normalmente durante o
desenvolvimento, os chamados ficam no status “Em desenvolvimento”.
13 – Copiar o executável gerado para o servidor de arquivos da empresa na
pasta de distribuição de executáveis e em FTP se for o caso.
14 – Emitir um aviso sonoro indicando o sucesso ou fracasso da operação, isso
é importante, pois como o compilador é compartilhada, todos ficam sabendo que alguém
gerou uma nova versão.
Existem algumas críticas de segurança adicionais que o CompG3 deve realizar,
uma importante é verificar se o build gerado já não está cadastrado no CO. Isso pode
ocorrer nos casos em que há alguma falha nas configurações de controle de versão do
projeto. Caso isso ocorrer o CompG3 deve interromper o processo, não liberando assim
os executáveis e informando ao usuário o ocorrido.
4.2.4 Solução para: Performance do software inadequada
Para solucionar o problema de performance, foi feito uma análise detalhada do
código fonte do Procel G3 nos pontos onde foi observado lentidão e sugerido uma
reestruturação do código fontes em pontos estratégicos do Procel G3
Foi observado que na maioria dos formulários do sistema, são realizadas
consultas ao banco de dados, trafegando consultas SQL, buscando por campos que na
maioria das vezes não eram utilizados. Sempre eram trazidos todos os campos que
poderiam vir a ser consultados e na aplicação eram ocultados todos os que não eram
interessantes. Em todos os grids do sistema, existe um comando chamado “customizar
colunas” em que ele lista todas as colunas de campos que podem ser visualizados. O
problema é que mesmo uma coluna não sendo visualizada ela sempre é buscada pelo
SQL. Em alguns casos, observou-se consultas trazendo mais de trezentos campos, e
94
sendo apresentados apenas dez ou vinte campos. Exemplos como estes existem vários
no sistema o que justifica a demora no transito de telas.
A solução para esta situação é uma reestruturação deste processo de
consultas, modificando radicalmente o método de realização das consultas e
consequentemente, o comando “customizar colunas”
O comando customizar colunas deve listar quais os campos que devem ser
listados na consulta do SQL, e ao confirmar, deve refazer a consulta, assim os campos
que serão consultados no banco serão somente aqueles que vão ser realmente
apresentados no grid de consulta.
A idéia proposta foi a criação de uma nova versão, criada a partir da versão
atual, onde seria feita uma reestruturação radical no processo de cadastros, mas sem
desativar a hierarquia antiga.
4.2.5 Solução para dificuldade na análise sobre o rendimento dos desenvolvedores
Para facilitar a análise sobre o rendimento dos desenvolvedores, far-se-á o uso
de soluções já apresentadas nos capítulos anteriores, são eles:
• Tempo previsto para execução (4.2.1.2)
• Gráfico de acompanhamento de chamados em execução (4.2.1.3)
• Gráfico de chamados atendidos (4.2.1.4)
Analisando a relação entre o tempo previsto para execução e o tempo já
investido em um chamado que pode ser obtido no gráfico, o gerente pode facilmente
identificar atrasos e agir de forma a auxiliar o desenvolvedor.
Para analisar o rendimento em relação aos chamados já realizados, pode-se
analisar as duas variações do gráfico de chamados atendidos.
95
4.2.6 Solução para dificuldade no controle das tarefas em andamento
Para auxiliar no controle das tarefas em andamento, far-se-á o uso de soluções
já apresentadas nos capítulos anteriores, são eles:
• Fila de desenvolvimento (4.2.1.1)
• Gráfico de acompanhamento de chamados em execução (4.2.1.3)
A análise do gráfico de acompanhamento de chamados em execução permite
uma visão em tempo real dos chamados em execução naquele momento apresentando a
relação de tempo previsto e investido.
4.2.7 Definição de papeis e responsabilidades
Analisando a estrutura organizacional do setor de desenvolvimento, observou-
se que a única divisão formal é a de gerentes e programadores. Apesar de não ser
relatado nenhum problema pela empresa em relação a isso, constatou-se que esta é uma
necessidade implícita, para o bom funcionamento do processo.
Observou-se que parte do trabalho realizado pelo gerente de desenvolvimento
pode ser transferido para outros funcionários, permitindo ao gerente ter uma atuação mais
estratégica sobre a equipe e a empresa. Partiu-se então para o estudo das
responsabilidades e seu relacionamento com possíveis papeis.
Identificadas as responsabilidades, as mesmas foram atribuídas a novas
gerências, são elas:
• Gerência de Demanda de Desenvolvimento
• Gerência de Tecnologia
• Gerência de Engenharia de Software
• Gerência de Automação Comercial
• Gerência de Estrutura e Framework do Procel G3
• Gerência de Conhecimento e Treinamento
• DBA
96
• Gerência de Regras de Negócio
• Gerência Estratégica
• Gerência de Requisitos
• Gerência de Testes e Controle de Qualidade
4.2.7.1 Gerência de demanda de desenvolvimento
Objetivo: Gerenciar as demandas de trabalhos de desenvolvimento e o
fornecimento de informações técnicas.
Funções:
• Receber chamados com solicitações de desenvolvimento e obter,
entendimento e análise.
• Garantir que os chamados tenham as solicitações bem definidas e com
dados suficientes para a execução do trabalho.
• Enviar os chamados para a fila de desenvolvimento e administrar suas
prioridades.
• Acompanhar o andamento dos trabalhos dos desenvolvedores,
observando quando estão demorando demais ou estão com dificuldades
técnicas.
• Validar os chamados concluídos, analisando o que foi solicitando e
efetivamente executado.
• Receber todas as solicitações de informações dos demais setores
garantindo que os desenvolvedores não sejam interrompidos.
Perfil:
• Bom relacionamento com todos os colaboradores da empresa,
habilidade de negociação, percepção, pró-atividade e iniciativa, forte
comprometimento com os resultados da equipe, conhecimento
97
operacional avançado sobre o Procel G3, conhecimento avançado sobre
parâmetros, configurações e estrutura de banco de dados do Procel G3.
O Gerente de Demanda de Desenvolvimento será a pessoa responsável por
receber todos os chamados do CO encaminhados para o setor de desenvolvimento pelos
outros setores. Por regra já estabelecida pela empresa, nenhum funcionário de outro setor
pode enviar um chamado para um programador diretamente sem a total autorização do
gerente do setor.
Este gerente ao receber um chamado deve fazer uma análise detalhada sobre
a solicitação e obter o total entendimento da necessidade do cliente. É muito comum que
os chamados venha descritos de forma inadequada, sem as informações necessárias
para o real entendimento.
Também é comum e já venham soluções propostas de formas inadequadas
para problemas não bem descritos, e estas soluções muitas vezes vem diretamente do
cliente ou do primeiro técnico, que algumas vezes são pessoas que não tem condições de
fazer uma análise adequada de soluções para problemas empresariais. É necessário
garantir que a solução proposta para cada problema seja feita por profissionais
capacitados para tal.
Caso o chamado não esteja bem definido, este gerente deve negociar com o
solicitante para que este faça um melhor detalhamento, ou então a real necessidade do
cliente deve ser discutida, chegando posteriormente então a uma solução ideal.
Após o chamado estar bem definido, ele deve ser enviado para a fila de
desenvolvimento e sua prioridade deve ser estabelecida. O gerente de demanda de
desenvolvimento deverá estar constantemente a par das prioridades do clientes e a quem
deve ser dado maior prioridade. Ele deve também ter bom relacionamento com as demais
gerências dos demais setores e estar em constante contato.
Este gerente pode ter como atividade secundária a programação, mas sob
hipótese alguma esta deve ter mais importância que a atividade de gerência.
Quando o programador terminar o desenvolvimento, este vai encaminhar o
chamado para o gerente de demanda para que este então faça uma validação e controle
98
de qualidade do chamado. Se qualquer coisa não estiver de acordo com as
especificações ou algum bug for encontrado, o chamado retorna ao programador.
No fluxograma apresentado na figura a seguir está detalhado o processo a ser
seguido pelo Gerente de Demanda no exercício de sua atividade:
Figura 29 – Fluxograma para atendimento dos chamados do Desenvolvimento Fonte: Elaboração dos autores, 2008.
Neste simples processo, o que mais fica claro é que haverá a partir de então
uma pessoa exclusiva para realizar estas análises. Esta atividade é atualmente realizada
pelo gerente de desenvolvimento mas de fato nunca consegue fazer nem a análise
preliminar nem o posterior controle de qualidade.
Outro processo proposto é que todo o relacionamento de dúvidas técnicas se
concentrem no gerente de demanda, somente se o gerente não souber responder é que
ele resolve qual é o programador que vai auxiliar. Atualmente observa-se que todos os
técnicos dos demais setores e vendedores escolhem algum programador para tirar suas
dúvidas ou pedir orientações técnicas, informações sobre parâmetros específicos, tirando
assim a concentração destes, e isso ocorre várias vezes ao dia. Até o programador voltar
99
seu pensamento ao que estava fazendo e voltar ao ritmo, perde-se alguns minutos, com o
risco do programador perder seu foco.
Além de eliminar as interferências externas aos programadores, o gerente de
demanda vai cada vez mais ter conhecimentos avançados sobre o produto e suas regras
de negócio, e assim ele pode focar seu conhecimento nisso. Preocupações como
tecnologia de desenvolvimento, estratégias da empresa e engenharia de software não
serão seu alvo de estudo.
4.2.7.2 Gerente de tecnologia
Objetivo: Gerenciar o conhecimento sobre as tecnologias empregadas e
estudar novas tecnologias
Funções:
• Conhecer todas as tecnologias empregadas nos softwares desenvolvidos
e capacitar os demais desenvolvedores a utilizá-las.
• Estudar novas tecnologias estudando sua viabilidade de implantação.
Perfil: Pró-atividade, iniciativa, criatividade, inteligência, senso crítico,
conhecimento avançado em programação, principalmente Delphi
O Gerente de Tecnologia será responsável por estudar e conhecer todas as
novas tecnologias que possam ser aplicadas aos softwares em desenvolvimento.
Qualquer novo componente de software ou então uma nova configuração para um
componente já em uso deve ser estudado e testado por este gerente.
Ele também deve manter conhecimento sobre tecnologias de hardware
compatíveis com os necessários para o uso do software, como computadores,
impressoras fiscais, balanças, scanners, em conjunto com o gerente de automação
comercial que será discutido a seguir. Ferramentas auxiliares de apoio como softwares de
acesso remoto e controle, transferência de arquivos pela internet, email, redes privadas e
100
quaisquer outras estruturas que possam fornecer apoio ao software e ao processo de
manutenção dele no cliente, também devem ser estudadas pelo gerente de tecnologia.
4.2.7.3 Gerência de Engenharia de Software
Objetivo: Estudar o apresentar propostas para implantação de métodos e
atividades relevantes a Engenharia de Software:
Funções:
• Estudar e aprofundar seus conhecimentos em metodologias e técnicas.
• Analisar a implantação de aspectos relevantes a engenharia de software
e acordo com a capacidade de absorção da empresa.
Perfil: Pró-atividade, criatividade, inteligência, boa comunicação e muito
comprometimento com o resultado da empresa.
A Engenharia de Software é um tema extremamente abrangente e novo,
cabendo um estudo aprofundado identificando várias atividades que podem ser
diretamente implantadas em uma empresa de software. Sugerimos a criação de uma
gerência de engenharia de software para que esta prossiga com os estudos sobre este
tema e proponha mudanças para o crescimento contínuo da empresa.
Esta gerência deve estar em constante comunicação com a alta gerência da
empresa e com o gerente de tecnologia sempre estudando propostas de soluções para os
aspectos relevantes.
4.2.7.4 Gerência de automação comercial
Objetivo: Gerenciar o desenvolvimento de software ao que está diretamente
relacionado à automação comercial.
101
Funções:
• Implementar e dar manutenção no software em todos os aspectos
relacionados ao Emissor de Cupom Fiscal - ECF.
• Implementar e dar manutenção no software em todos os aspectos
relacionados ao TEF.
• Realizar os processos de homologação de TEF junto à certificadora de
TEF.
• Realizar os processos de homologação do software junto as Secretarias
da Fazenda dos estados brasileiros.
• Implementar e dar manutenção no software aos demais aspectos
relacionados a automação comercial, como balanças pesadoras, leitores
de código de barras, teclados especiais, etc.
Perfil: Pró-atividade, iniciativa, criatividade, inteligência, conhecimento
avançado em programação com Delphi, coragem, auto-confiança.
Como a empresa desenvolve software para gestão e automação comercial, é
importante que o setor de desenvolvimento tenha um responsável por dar manutenção no
software em todos os aspectos que dizem respeito a automação comercial.
O software de automação comercial é normalmente chamado de Checkout ou
Ponto de Venda – PDV, e rapidamente é identificado como aquele software que fica nos
caixas dos supermercados. Ao PDV estão conectados vários hardwares e softwares
auxiliares como emissores de cupom fiscal – ECF, leitores de cartões de crédito, os
PinPad´s, Transferência Eletrônica de Fundos – TEF, teclados com características
especiais, leitores de códigos de barras, balanças pesadoras de vários modelos e assim
por diante. E com cada equipamento deste existe um processo de comunicação e uma lei
vigente a ser seguida. O PDV também deve ser comunicar com o software de retaguarda
que no caso da empresa em estudo pode ser o software da empresa ou outro software de
retaguarda qualquer.
Para o gerente de automação comercial, seus maiores desafios são o ECF, e o
TEF.
102
4.2.7.5 Gerência de estrutura e framework do Procel G3
Objetivo: Gerenciar o desenvolvimento do framework do Procel G3
Funções:
• Acompanhar os desenvolvedores de forma a garantir que todos criem e
alterem os formulários seguindo corretamente a hierarquia de
desenvolvimento do projeto
• Estudar novas formas de implementar a base hierárquica de código-fonte
objetivando obter um modelo ideal
Perfil: Pró-atividade, iniciativa, criatividade, inteligência, conhecimento
avançado em programação com Delphi.
Este gerente deve estar atento e decidir sobre as questões de estrutura e
hierarquia de objetos e componentes do projeto. A orientação de objetos e hierarquia dos
formulários básicos são seus principais desafios.
4.2.7.6 Gerência de conhecimento e treinamento
Objetivo: Gerenciar os processos de armazenamento e socialização do
conhecimento necessário para o exercício das funções na empresa.
Funções:
• Estudar e implementar métodos de armazenamento dos conhecimentos
gerados pela empresa.
• Organizar as documentações e garantir que todos tenham acesso a elas.
• Realizar ou gerenciar o treinamento de novos funcionários.
• Incentivar e organizar treinamentos internos avançados sobre
conhecimentos específicos.
103
• Implementar e dar manutenção ao sistema de Help on-line do Procel G3.
Perfil: Boa capacidade de redigir e contextualizar assuntos e problemas, ter
bom português e boa capacidade de transmitir conhecimento.
Foi observado que na empresa existe uma dificuldade para a administração do
conhecimento necessário para o exercício de suas atividades.
Da mesma forma o conhecimento das regras de negócio do software estão
esparsas e não existem documentos. Para o Procel G3 simplesmente não existe sistema
on line de Help ao usuário, e na atual estrutura não existe nem previsão para que isso
seja implantado de forma efetiva.
4.2.7.7 Database Administrator - DBA
Objetivo: Gerenciar os modelos de dados relacionados aos software do pacote
Procel G3
Funções:
• Criar e manter atualizado o Diagrama Entidade-Relacionamento - DER
do Procel G3 e outros softwares do pacote Procel G3.
• Criar e manter atualizado o Dicionário de Dados do Procel G3.
• Decidir sobre a criação de qualquer objeto no banco de dados.
• Estudar sobre outros bancos de dados e analisar o impacto sobre
mudanças.
Perfil: Pró-atividade, iniciativa, criatividade, inteligência, conhecimento
avançado em programação com banco de dados, principalmente Interbase/Firebird,
conhecimento avançado sobre modelagem de banco de dados
O banco de dados do Procel G3 atualmente não é administrado de uma forma
totalmente controlada.
104
Observa-se também a necessidade de uma documentação completa do banco
de dados e a sua diagramação através de um Diagrama Entidade-Relacionamento – DER
e de um dicionário de dados.
4.2.7.8 Gerência de regras de negócio
Objetivo: Gerenciar e prover informações sobre regras de negócios
empresariais
Funções:
• Gerenciar o conhecimento relacionado a regras de negócios
empresariais, como regras financeiras, de faturamento, estoque.
• Observar as implementações dos software para verificar seu atendimento
as regras de mercado.
• Conforme a demanda, obter informações específicas com profissionais
de outros setores envolvidos, como contadores, fiscais da Secretaria da
Fazenda, analistas e desenvolvedores de outras empresas de software
que trabalham em parceria com a empresa.
• Decidir sobre regras como funcionamento de notas fiscais, ECF,
questões contábeis, legais, etc.
Perfil: Inteligência, bom relacionamento inter-pessoal, alto nível de
conhecimento de gestão e administração.
A gerência de regras de negócio é responsável pelo conhecimento das regras
de negócio relacionadas a área de atuação do software.
Por exemplo: um software que faz a emissão de nota fiscal é regido por um
grande conjunto de regras relacionadas a notas fiscais que são determinadas pela
Secretaria da Fazenda dos Estados. Da mesma forma para um controle de contas a pagar
e receber existe um conhecimento administrativo e financeiro. O entendimento destas
regras e a constante atualização sobre este conhecimento são de responsabilidade do
gerente de regras de negócio.
105
Quando alguma dúvida em relação a alguma regra precisa ser discutida com
empresários, contadores ou fiscais da Secretaria da fazenda, é este gerente que deve
tomar frente, esclarecer e documentar esta regra.
4.2.7.9 Gerência estratégica
Objetivo: Gerenciar de forma estratégica as ações da empresa e as demais
gerências
Funções:
• Gerenciar o alinhamento estratégico das ações da empresa em relação a
seus objetivos.
• Gerenciar o desenvolvimento das demais gerências.
• Estudar a criação de novas gerências.
• Observar a necessidade de criação de novos métodos organizacionais
objetivando o crescimento contínuo da estrutura e capacidade de
atendimento.
Perfil: Empreendedorismo, conhecimentos em administração, bom
relacionamento inter-pessoal, capacidade de liderança.
Enfim aos atuais gerentes de desenvolvimento cabe a tarefa de ter uma
atuação estratégica sobre as demais gerências e sobre todo o funcionamento do setor de
desenvolvimento e também sobre o conjunto da empresa.
4.2.7.10 Gerência de requisitos
Objetivo: Gerenciar o processo de coleta de requisitos junto ao cliente.
106
Funções:
• Auxiliar os consultores de implantação a coletar requisitos de forma mais
completa, obtendo um real entendimento da necessidade ou problema
do cliente.
• Desenvolver métodos que auxiliem a coleta de requisitos e sua inserção
no ciclo de vida dos processos produtivos de software.
Atualmente a verificação do gerente de demanda é criteriosa mas não
necessariamente baseada em estudos avançados sobre gerência de requisitos. Objetiva-
se padronizar documentos para definição da estrutura física dos clientes, estrutura de
sistemas e configurações e regras específicas, além do próprio processo de levantamento
de requisitos. Também devem ser estudadas ferramentas específicas de apóio a este
processo.
4.2.8 Relação entre problemas e soluções
As soluções propostas nem sempre são itens de relação direta aos problemas
apresentados, alguns soluções auxiliam a mais de um problema e da mesma forma
alguns problemas precisam de mais de uma solução. Para facilitar o entendimento desta
relação problema versus solução, foi preparada a tabela abaixo:
107
Tabela 2 - Relação problema versus solução
Problemas (capítulo 4.1.3).
Solução
Dificuldade na priorização das atividades Fila de Desenvolvimento (4.2.1), Gráfico de acompanhamento de chamados em execução (4.2.3) e
Criação de sub-gerências de tecnologia (4.2.8)
Incompatibilidade entre ambientes de desenvolvimento
Computador Compilador de Executáveis (4.2.6)
Dificuldade na administração das versões Computador Compilador de Executáveis (4.2.6)
Performance do software insatisfatória Reestruturação do código fontes em pontos estratégicos do Procel G3 (4.2.7)
Padronização de código inadequada Controle de Qualidade e Padronização de Código Fontes (4.2.5)
Desconhecimento das regras de negócio do software
Solicitações mal definidas Criação de sub-gerências de tecnologia (4.2.8)
Ausência de processo de teste de software Criação de sub-gerências de tecnologia (4.2.8)
Dificuldade na análise sobre o rendimento dos desenvolvedores
Tempo previsto para execução (4.2.2), Gráfico de acompanhamento de chamados em execução (4.2.3) e
Gráfico de chamados atendidos (4.2.4)
Dificuldade no controle das tarefas em andamento
Fila de Desenvolvimento (4.2.1) e Gráfico de acompanhamento de chamados em execução (4.2.3)
Fonte: Elaboração dos autores, 2008.
4.3 CONSIDERAÇÕES FINAIS
Durante o desenvolvimento deste trabalho pudemos observar a rotina diária de
uma empresa de desenvolvimento de software e suas dificuldades. Tivemos a
oportunidade de propor soluções à problemas apresentados e descrever a implementação
prática das propostas para alguns dos problemas.
108
5 APRESENTAÇÃO DOS RESULTADOS
Neste capítulo estaremos apresentando as soluções que foram efetivamente
implantadas na empresa e a como foi o resultado obtido.
5.1 ADOÇÃO E IMPLEMENTAÇÃO DAS PROPOSTAS DE SOLUÇÃO
Das propostas apresentadas, a maioria foi adotada e implementada, tendo
estas sido realizadas entre 2007 e 2008 em períodos diferentes. Para cada proposta,
foram envolvidos os gerentes das áreas e foram implantadas uma a uma.
É importante considerar que um elemento facilitador na implementação das
propostas foi a autonomia de um dos autores pelo fato dele ser gerente de
desenvolvimento na empresa.
5.1.1 Fila de Desenvolvimento
A primeira solução implementada foi a fila de desenvolvimento, pois segundo a
empresa, essa era uma das maiores prioridades.
Quando a implementação foi realizada no CO, a versão foi atualizada para
todos os desenvolvedores. O gerente, de posse de todos os chamados em mãos, de
todos os desenvolvedores os enviou para a fila de desenvolvimento, gerando uma fila de
cerca de 30 chamados. Estes chamados foram organizados por ordem de importância.
109
Figura 30 – Fila de Desenvolvimento do CO Fonte: Procel, 2008a.
Para mudar a prioridade dos chamados na fila de desenvolvimento, os
desenvolvedores implementaram da seguinte forma: o usuário deve clicar sobre o
chamado que se deseja mudar de posição, pressionar a tecla Ctrl e clicar sobre o
chamado que está na posição que o anterior deve assumir. Assim, o primeiro chamado
assume a posição do segundo, que vai para a próxima posição. O recurso de clicar sobre
o chamado e colocar em uma nova posição ficou extremamente prático e funcionou
adequadamente.
Com os chamados todos organizados na fila de desenvolvimento, foi feito uma
reunião com a equipe de desenvolvimento para apresentar a nova forma de operação do
CO.
Foi explanado para todos como seria utilizado a opção “Obter chamado” que foi
implementada na forma de um botão disponível na tela principal do CO. Este botão é
visível apenas para os usuários do setor de desenvolvimento.
110
Figura 31 – Opção Obter Chamado do CO Fonte: Procel, 2008a.
Conforme proposto pelos autores, ao clicar sobre o botão “Obter Chamado”, o
primeiro chamado da fila de desenvolvimento é transferido para o usuário solicitante e o
status do chamado é alterado para “em andamento”, em seguida o chamado é
automaticamente apresentado ao usuário.
Entre os tipos já existentes de status dos chamados foi criado o “em
andamento” relativo a proposta “em desenvolvimento” dos autores. Foi também
implementada a regra de que um usuário não pode ter mais que um chamado com o
status “em andamento”. Isso foi necessário pois foi criado um método de cálculo de horas
aplicadas de forma automática, e o simples fato de um chamado ser colocado em
andamento, dispara um contador de minutos no banco de dados. Quando o chamado
muda para outro status, os minutos acumulados são armazenados em uma tabela
específica, possibilitando a emissão de gráficos e relatórios posteriores.
Em virtude das implementações realizadas no CO a partir das propostas desta
monografia, outras implementações foram realizadas de forma independente pela
111
empresa. Uma delas foi a apresentação do total acumulado de horas aplicadas sobre
cada chamado. Em todas as telas de consulta, a última coluna é a de “Horas realizadas”
Figura 32 – Horas realizadas do CO Fonte: Procel, 2008a.
A implementação da fila de desenvolvimento foi implementada em 2007 e desde
então tem sido utilizada de forma intensa.
5.1.2 Tempo previsto para execução
Para informar o tempo previsto para execução dos chamados, foram
implementadas duas formas de edição:
A primeira é no próprio chamado, criando um campo específico para este fim.
112
Figura 33 – Tempo previsto para execução em chamados do CO Fonte: Procel, 2008a.
Outra forma de edição é através de um comando executado diretamente a partir
da consulta principal, não precisando abrir o chamado para informar. Clicando com o
botão esquerdo do mouse sobre o chamado e escolhendo no sub-menu “Tempo previsto
para execução”, assim abre uma tela de edição rápida onde o tempo é informado.
A análise do tempo previsto em relação ao realizado pode ser realizada através
do gráfico de acompanhamento de chamados em execução, apresentado a seguir.
5.1.3 Gráfico de acompanhamento de chamados em execução
Para o acompanhamento dos chamados atualmente em execução, foi criado
um gráfico que foi disponibilizado em uma aba chamada “Em Desenvolvimento”.
113
Figura 34 – Gráfico de chamados em desenvolvimento Fonte: Procel, 2008a.
Para cada técnico é apresentado a quantidade de horas investidas pelo técnico
(coluna verde), por sugestão da empresa, a quantidade de horas totais, que incluem as
horas de quaisquer outros técnicos que também tenham se envolvido no chamado
(coluna amarela) e a quantidade de horas previstas (coluna azul).
Abaixo do gráfico são listados os chamados em execução direta pelos
desenvolvedores.
5.1.4 Gráfico de chamados atendidos
O gráfico de chamados atendidos ainda não foi adicionado no CO, pois ainda
está em análise a sua eficácia. Sua visualização por enquanto está sendo feita por um
programa avulso que se conecta a base de dados do CO.
114
As informações do gráfico abaixo são uma estatística real dos desenvolvedores
e apresenta os chamados atendidos nos dois primeiros meses de 2008 em intervalos
semanais.
Figura 35 – Gráfico de Chamados atendidos Fonte: Procel, 2008a.
5.1.5 Controle de qualidade e padronização de código fontes
Para a realização do controle de qualidade e padronização do código fonte, foi
criado o “Manual do desenvolvedor” e implantado o processo de validação de código fonte
por um coach.
115
5.1.5.1 Manual do desenvolvedor
O Manual do desenvolvedor está disponibilizado a todos através do CO,
acessando a aba Documentação.
Figura 36 – Acesso a documentações através do CO Fonte: Procel, 2008a.
O manual de padronização foi escrito por um dos desenvolvedores sob
orientação dos autores, e o resultado foi um documento de trinta e uma páginas com as
orientações necessárias para a aplicação da padronização ao desenvolvimento.
116
Figura 37 – Capítulo sobre preparação de estação de trabalho Fonte: Procel, 2008b.
Um dos capítulos orienta o desenvolvedor a instalar e configurar uma estação
de trabalho, desde a instalaçãos dos aplicativos e as suas configurações necessárias até
a sincronização dos códigos fontes a partir do repositório.
117
Figura 38 – Lista de prefixos da nomenclatura de objetos Fonte: Procel, 2008b.
Para montar a lista dos prefixos da nomenclatura dos objetos foi primeiro feito
uma lista dos prefixos já utilizados pelo projeto Procel G3, que já possuía um certo
padrão. Com base nesta lista, foram feitos ajustes e adicionados os prefixos para objetos
ainda não definidos.
118
Figura 39 – Regra sobre escrita de comentários Fonte: Procel, 2008b.
Para os comentários, foram criadas regras para seus diversos tipos de uso,
como comentário de unit, de procedure, comentário de laço, de linha, etc...
5.1.5.2 Validação do código fonte por um coach
A implantação do processo de validação por um coach está em fase inicial de
implantação, e ainda não está sendo realizada como proposto.
A escolha e o treinamento do coach ainda não foi realizada. O setor de
desenvolvimento está reestruturando as sub-gerências e este novo papel ainda não foi
definido.
A empresa ainda quer fazer uma melhor validação deste processo através do
uso do comando Diff/Merge Module do Jedi.
119
5.1.6 Computador compilador de executáveis
O processo do computador compilador foi implantado com sucesso e já está em
uso.
Sua implementação seguiu a sugestão dos autores em sua totalidade e o
resultado foi muito satisfatório.
5.1.6.1 Implementações realizadas no Call Organizer
Primeiramente foi implementado no CO o lançamento das versões relacionadas
ao chamado.
Figura 40 – Versões dos chamados relacionadas ao CO Fonte: Procel, 2008a.
120
O usuário ao lançar o texto do chamado, deve clicar no botão “ver” conforme
imagem acima e selecionar o sistema e a(s) versão(ões). Mantendo assim um
relacionamento entre o assunto chamado e a versão a ser gerada.
Figura 41 – Texto de solução técnica do chamado com indicativo de versão Fonte: Procel, 2008a.
Para que o compilador identifique uma versão para compilação é obrigatório
que o sistema seja lançado em um texto classificado como “Solução técnica” conforme
imagem acima. Esta classificação já era utilizada pelo CO.
5.1.6.2 O computador compilador
Conforme proposto, foi adquirido um computador de características compatíveis
com as sugeridas e instalados os aplicativos de desenvolvimento como o Jedi, o Delphi e
seus componentes, WinRar e o VNC.
5.1.6.3 O compilador CompG3
O aplicativo compilador CompG3 foi desenvolvido pela equipe da Procel sob
orientação dos autores.
O CompG3 é de interface simples, contendo apenas quatro telas em seqüência.
121
A primeira para obter o usuário desenvolvedor.
Figura 42 – Definição do técnico que executa a compilação Fonte: Procel, 2008c.
A segunda para obter os chamados do CO que desejam compilar versões.
Figura 43 – Chamados relacionados às versões Fonte: Procel, 2008c.
122
A terceira para apresentar a conferência das versões encontradas nos
chamados do CO.
Figura 44 – Definição do técnico que executa a compilação Fonte: Procel, 2008c.
A quarta para iniciar a compilação e apresentar o andamento da compilação.
Figura 45 – Apresentação do resumo, antes da compilação Fonte: Procel, 2008c.
123
Ao iniciar o processo é iniciada a compilação de cada projeto e versão
solicitada, e para cada processo são sincronizados os fontes do repositório através do
aplicativo Jedi versão de linha de comando.
Figura 46 – Sincronização dos códigos fontes do repositório Fonte: Procel, 2008c.
Após a sincronização, o Delphi é iniciado e o usuário tem a incumbência de
comandar a compilação, salvar o projeto e fechar o Delphi.
Figura 47 – Compilação do executável pelo Delphi Fonte: Procel, 2008c.
124
Este processo não ficou perfeitamente automatizado devido a um problema na
geração automática de número de build, pois quando a compilação era comandada
diretamente por linha de comando, o número de build não era incrementado pela IDE do
Delphi. Ficou constatado que o auto incremento só era realizado quando o usuário
compilava “manualmente” a versão.
Quando o Delphi é fechado e o novo arquivo executável está disponível no
diretório, é verificada a versão do novo arquivo para validar em relação a última versão
compilada. Qualquer problema de seqüência de numeração é identificado, avisado ao
usuário e o processo é abortado.
Também são feitos os backup dos fontes utilizados em uma pasta específica e
também é armazenada uma cópia do executável renomeado com nome, data e versão.
Figura 48 – Backup realizados pelo CompG3 Fonte: Procel, 2008c.
Segundo a empresa, este backup da cópia dos executável já foi acessada
várias vezes pelo setor de suporte, nas necessidades de realizar simulações utilizando a
versão exata em posse do cliente.
Após a compilação, os executáveis são compactados e distribuídos na rede nos
locais específicos para este fim, onde os setores de implantação e suporte fazem uso.
125
Figura 49 – Executável compilado já copiado para o local de distribuição Fonte: Procel, 2008c.
As informações sobre o sucesso da compilação também são lançadas nos
chamados que originaram as compilações.
Figura 50 – Chamado com informação de chamado executado Fonte: Procel, 2008a.
126
Após a compilação, é adicionado um texto pelo compilador, com as informações
de data, versão, local e nome do executável. Este texto tem identificação específica
conforme imagem acima.
O chamado também muda de status, ficando como “chamado executado”,
estando pronto para ser encaminhado ao solicitante.
5.2 VALIDAÇÃO DA RESOLUÇÃO DOS PROBLEMAS
São apresentados a seguir os dados referentes ao nível de resolução dos
problemas através da aplicação das propostas de solução.
As respostas abaixo foram obtidas através de reuniões com funcionários e
gerentes, bem como durante conversas informais.
5.2.1 Dificuldade na priorização das atividades
O processo de priorização das atividades de desenvolvimento foi facilitado.
Segundo a gerência, a implantação da fila de desenvolvimento, modificou radicalmente a
rotina de administração do gerente de desenvolvimento.
Atualmente, todos os cerca de 30 colaboradores podem consultar a fila de
desenvolvimento e ter conhecimento das prioridades do desenvolvimento, antigamente
nem as gerências tinham acesso rápido a essas informações.
Após a implantação da fila de desenvolvimento e do gráfico de
acompanhamento de chamados em execução, a análise e determinação de prioridades
pode ser feita apenas uma vez ao dia. O tempo total diário investido nesta tarefa passou
de 2 horas para 20 minutos.
A necessidade de realizar uma reunião a fim de modificar ordens de prioridade
a partir das gerências tornou-se mais fácil pois o processo está visível no computador .
Por meio de reuniões informais, percebeu-se que 80% dos colaboradores
afirmam que o processo de priorização ficou mais eficiente e que facilitou as negociações
127
da equipe de gerentes, 100% aprovaram a fila de desenvolvimento, principal responsável
pela melhora no processo de priorização das atividades.
Em reunião recente com a gerência, questionou-se sobre o uso da fila de
desenvolvimento, o retorno foi considerado positivo. Todos os setores técnicos consultam
regularmente a fila de desenvolvimento para alinharem o andamento dos chamados e
realizam assim suas cobranças. As equipes de desenvolvedores observam que podem ter
uma clara noção sobre o desenvolvimento da equipe, sem que hajam especulações .
A empresa tem interesse em expandir o uso da fila de desenvolvimento. A idéia
é criar uma configuração para cadastrar várias filas, de acordo com a necessidade da
empresa controlando demandas de outros setores, é o caso por exemplo do próprio setor
de desenvolvimento que já identifica esta necessidade.
5.2.2 Incompatibilidade entre ambientes de desenvolvimento
Com a implantação do computador compilador de executáveis, observou-se que
o trabalho de configuração dos computadores dos programadores não mudou muito, mas
garantiu que mesmo com configurações diferentes, o executável distribuído mantivesse
consistência.
Foi realizado um teste modificando configurações de idioma das mensagens
padrões do Delphi, configuração de número de versão e outras diretivas de compilação e
foi constatado que todas estas foram ignoradas levando apenas em consideração as
configurações constantes no compilador. As mensagem padrões do executável
compilador saíram todas em português, nenhuma das diretivas modificadas foram
consideradas e o mais importante, o número de série do executável foi sendo
incrementado corretamente a cada nova compilação, mesmo sendo os números de
versões nos computadores dos programadores diferentes.
Com o compilador de executáveis reduziu-se de 10 para apenas 1, o número de
computadores que distribuem executáveis, refletindo diretamente o resultado final.
128
5.2.3 Dificuldade na administração das versões
Com a implantação do computador compilador de executáveis, a geração de
novas versões ficou totalmente automatizada.
A implantação de um controle de versões com build modificou a forma em que o
setor de suporte controla as versões. Antigamente o único parâmetro era a versão com
três níveis, cujo ciclo de vida levava meses com centenas de compilações. A substituição
ocorreu por um controle de versão com build com quatro números significativos. Segundo
os setores de implantação e suporte, este controle de versão aumentou em mais de 50%
a confiança em relação ao conteúdo dos executáveis sobre o ciclo de vida das versões.
Os chamados do CO agora mantêm registrado as versões relacionadas com as
solicitações, desde a versão do cliente, a(s) versão(ões) que o gerente de
desenvolvimento orienta implementar e as versões geradas pelo computador compilador
que são registradas automaticamente no chamado. Dessa forma é gerado um histórico
que permite realizar a rastreabilidade entre problema e solução
5.2.4 Performance do software insatisfatória
O processo de reestruturação proposto foi iniciado com a implementação da
versão 2.0.3 do sistema Procel G3. Nesta versão, foi recriado uma nova hierarquia de
cadastros, sem destruir a estrutura atual, isso permitiu que os programadores
acreditassem na reestruturação pois caso algo não desse certo era só continuar usando a
estrutura antiga.
Seguindo este ritmo, a versão 2.0.3 já está em implementação a cerca de três
meses, e todos os cadastros e consultas foram recriados, com fortes mudanças nos
processos de consulta ao banco de dados.
Rapidamente observou-se uma melhora de cerca de 95% nos processos de
aberturas de consultas e de 40% na abertura dos formulários de edição.
Atualmente estão sendo reestruturados os processos de movimentação de
estoque e em seguida serão feitos os demais processos dos sistema. Mas ficou claro que
todos os programadores querem estar envolvidos nesta versão que já deu certo.
129
5.2.5 Padronização de código inadequada
A padronização do código melhorou sutilmente, mas ainda precisa ser melhor
trabalhada, o manual de padronização foi criado e ficou muito bom, mas não foi
totalmente disseminado entre os programadores. A validação por um coach está sendo
feita de forma informal para auxiliar questões técnicas mas não está sendo dado muito
foco à padronização.
Este processo está programado para o segundo semestre de 2008, para que a
empresa resolva melhor esta problemática.
5.2.6 Desconhecimento das regras de negócio do software
As solução para este problema ainda está estudo e está agendado como
trabalho futuro a ser realizado pela empresa.
5.2.7 Solicitações mal definidas
Uma solução de alta eficiência ainda está em estudo, pois não foi possível
devido ao tempo disponível para esta monografia, porem em virtude da definição da
gerência de demanda de desenvolvimento, e a alocação de um profissional da equipe
para tal, as tarefas passaram a ser realmente analisadas e validadas por um gerente que
foca seu tempo para esta atividade. E quando as solicitações não estavam totalmente
claras ou apresentavam propostas de soluções inadequadas, o próprio gerente negociava
diretamente com os demais setores e com o cliente, melhorando em muito a preocupação
com a qualidade da informação.
130
5.2.8 Ausência de processo de teste de software
Nenhuma solução foi apresentada para este problema, em virtude do tempo
disponível para a monografia.
Porém com a visão de criação de novas gerências, alguns desenvolvedores
foram incentivados a estudar o tema de teste de software para que posteriormente a
gerência estratégica possa ou não identificar um destes desenvolvedores como possíveis
novos gerentes, com habilidades para assumir a causa do teste de software e
desenvolver soluções para este tema.
5.2.9 Dificuldade na análise sobre o rendimento dos desenvolvedores
Com a implantação dos gráficos propostos e do tempo previsto para execução,
o gerente pode ter uma visão mensurável em relação ao rendimento atual e realizado dos
programadores, o que antes não existia.
Com o tempo previsto para execução, o gerente tem negociado a horas
necessárias com o programador antes de iniciar a execução. Isso triplicou o
comprometimento dos programadores e reduziu em mais da metade o índice de
distração. Isso é observado pela quantidade de vezes que os programadores saem para
tomar café ou fazem conversas paralelas. Observou-se claramente o aumento do silêncio
no ambiente de desenvolvimento.
Em conversas informais com os programadores eles também tem observado
uma melhora no desempenho da equipe.
5.2.10 Dificuldade no controle das tarefas em andamento
Com o gráfico de acompanhamento dos chamados em execução e a
determinação do tempo previsto, o gerente faz uma verificação rápida de quatro a seis
vezes ao dia pra ver se alguém está alcançando o tempo previsto ou já superou, para
então fazer um acompanhamento técnico e realizar uma eventual cobrança.
131
Não ocorreram mais situações em que um programador excedeu em mais de
100% um tempo previsto sem um devido acompanhamento ou reprogramação da
expectativa de tempo.
5.3 ANÁLISE GLOBAL DOS RESULTADOS
Na fase de análise de resultados pudemos observar que as propostas foram
implementadas de forma muito aderente ao que foi proposto e os resultados foram
bastante satisfatórios.
132
6 CONCLUSÃO
Com os estudos e trabalhos realizados nesta monografia, concluímos que é
possível obter a melhor qualidade do produto melhorando a qualidade no processo de
desenvolvimento, porém o desafio da qualidade é custoso sendo necessário melhorar
centenas de processos e sub-processos em uma empresa de desenvolvimento de
software.
Percebemos o grande desafio que é a produção de software de qualidade. A
complexidade do software, o grande número de pessoas envolvidas, as muitas regras de
negócio dos clientes e o curto tempo disponível para a disponibilização das soluções
dificultam o alcance da qualidade, que é fator primordial para obter boa colocação no
mercado.
São muitas as dificuldades encontradas pelas empresas desenvolvedoras e
existe uma grande carência por conhecimento especializado no processo produtivo de
software. Muitas pessoas têm bons conhecimentos específicos que evoluem bem em
partes do processo, mas poucas pessoas conseguem integrar todo o trabalho a ponto de
obter um bom software a um custo satisfatório.
Com a situação atual do trabalho pudemos selecionar e estudar um conjunto de
conhecimentos que nos auxiliou na apresentação de soluções para os problemas
identificados.
Tivemos dificuldades para fazer a integração do escopo acadêmico com a vida
prática. Ambos autores são empresários e proprietários de empresas de desenvolvimento,
e ambos estão diretamente envolvidos com o processo produtivo de software em suas
empresas, e este envolvimento vem de muitos anos, muito antes mesmo que o próprio
início da vida acadêmica, então sobre este aspecto, o longo conhecimento prático foi
inclusive um item dificultador ao exercício da criatividade e obtenção de soluções, para
para cada solução, já era conhecida uma lista de considerações.
A equipe está cada vez mais motivada e confiante no projeto, principalmente
com as mudanças realizadas nos últimos meses em relação a criação das novas
gerências.
133
A alta gerência da empresa tem a visão clara de que mudanças são cada vez
mais necessárias para que o software se diferencie neste mercado que está cada vez
mais aquecido, principalmente na região da Grande Florianópolis.
Em relação a questão de pesquisa, concluímos que é possível obter a melhor
qualidade do produto melhorando a qualidade no processo de desenvolvimento, porém o
desafio da qualidade é custoso sendo necessário melhorar centenas de processos e sub-
processos em uma empresa de desenvolvimento de software, bem como aplicar
profundamente conceitos de engenharia de software, metodologias, técnicas, etc...
A elaboração de um trabalho acadêmico está sendo grande desafio para os
autores que tem um ritmo profissional acelerado e muito focado em seus negócios, porém
está apresentando uma visão mais organizada e formal ao trabalho, ajudando a quebrar
paradigmas. Este trabalho continuará em desenvolvimento na empresa cada vez mais
forte, porém de forma bem menos acadêmica, objetivando sempre o resultado.
134
REFERÊNCIAS
ÁGILE MANIFESTO. Manifesto for Agile Software Development. Disponível em: <http://agilemanifesto.org/>. Acesso em 03 set 2007.
ARAUJO, Luis César G. De. Organização, sistemas e métodos e as modernas ferramentas de gestão organizacional: arquitetura, benchmarking, empowerment, gestão pela qualidade total, reengenharia. São Paulo: Atlas, 2001.
ARENA. Arena – Forward Visibility for Your Business Disponível em <http://www.arenasimulation.com>. Acesso em 01 out. 2007.
ASTELS, David. Extreme programming: Guia Prático; David Astels, Granville Miller, Miroslav Novak; tradução de Kátia Roque. Rio de Janeiro: Campus, 2002.
BARTIÉ, Alexandre. Garantia da Qualidade de Software. Rio de Janeiro: Campus, 2002.
CAROSIA, Jaciara Silva. Levantamento da Qualidade do Processo de Software com Foco em Pequenas Organizações. Dissertação de Mestrado – São José dos Campos: INPE, 2003.
CERVO, Amado Luiz; BERVIAN, Pedro Alcino. Metodologia científica: para uso dos estudantes universitários. 3. ed. São Paulo: Makron Books do Brasil, 1983.
CORDEIRO. Edson dos Santos. Modelagem Descritiva Iterativa e Incremental de Processo de Software. Dissertação de Mestrado. Universidade Federal de Santa Catarina – Curso de Ciências da Computação, 2003.
FNQ. Fundação Nacional da Qualidade. Disponível em <http://www.fnq.org.br/>. Acesso em 24 nov. 2007.
FURTADO, André. Pontas de Iceberg do Caos no Desenvolvimento de Software. Disponível em <http://www.microsoft.com/brasil/msdn/Tecnologias/Carreira/DesenvolvimentoSoftware.mspx>. Acesso em 01 out 2007.
GONÇALVES, José Ernesto Lima. As Empresas são Grandes Coleções de Processos. RAE - Revista de Administração de Empresas . São Paulo, v. 40 – n. 1 – p. 6-19. Jan./Mar. 2000.
135
JEDI. JEDI Version Control System. Disponível em <http://jedivcs.sourceforge.net/downloads.html>. Acesso em 21 fev. 2008.
JEDI SOUCE. JEDI Version Control System – Building from Source. Disponível em <http://jedivcs.sourceforge.net/building_from_source.html>. Acesso em 24 mar. 2008.
MOLINARI, Leonardo. Testes de Software: Produzindo Sistemas Melhores e Mais Confiáveis. São Paulo: Érica, 2003a.
______. BTO: Otimização da Tecnologia de Negócio: Qualidade de Software na Prática. São Paulo: Érica, 2003b.
MPS-BR. Guia Geral – Versão 1.1. SOFTEX 2006.
PRESSMAN, Roger S. Engenharia de Software; tradução Rosângela Delloso Penteado, revisão técnica Fernão Stella R. Germano, José Carlos Maldonado, Paulo César Masiero. 6 ed. São Paulo: McGraw-Hill, 2006.
PROCEL. Procel Software. Disponível em <http://www.procel.com.br>. Acesso em 15 nov. 2007.
______. Call Organizer. Modificado em fev. 2008a.
______. Manual do Desenvolvedor. Padronização da escrita do código fonte dos aplicativos Procel Software – 2008b.
______. CompG3. Compilador de Executáveis do Procel G3. Modificado em fev. 2008c.
RealVNC. RealVNC remote control software. Disponível em <http://www.realvnc.com>. Acesso em 25 fev. 2008.
RUMBAUGH, James. Modelagem e projetos baseados em objetos. tradução Dalton Conde de Alencar. Rio de Janeiro: Campus 1994
RUP. Rational Unified Process. Disponível em <http://www.wthreex.com/rup/>. Acesso em 27 nov. 2007.
SALVIANO, Clênio Figueiredo. Uma proposta orientada a perfis de Capacidade de Processo para Evolução da Melhoria do Processo de Software. Tese de Doutorado, Universidade Estadual de Campinas – Faculdade de Engenharia Elétrica e de Computação, 2006.
136
SANTOS, Robson Luís Gomes dos. Usabilidade de interfaces para sistemas de recuperação de informação na web : estudo de caso de bibliotecas on-line de universidades federais brasileiras. Rio de Janeiro : PUC, Departamento de Artes e Design, 2006.
SCRUM. What is Scrum? Disponível em <http://www.controlchaos.com/about/>. Acesso em 17 set. 2007.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. InfoComp, Journal of Computer Science, Volume 3, número 2. Disponível em <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em 03 set. 2007.
______. Metodologias Ágeis Extreme Programming e Scrum para o Desenvolvimento de Software. RESI Revista Eletrônica de Sistemas de Informação, Edição 4: Ano III Volume III Número I, Novembro 2004.
SOMMERVILLE, Ian. Engenharia de Software ; tradução André Maurício de Andrade Ribeiro ; revisão técnica Kechi Hirama. São Paulo: Addison Wesley, 2003.
TCU. Técnicas de entrevista para auditorias. - TCU - Tribunal de Contas da União, Secretaria de Auditoria e Inspeções. Brasília, 1998.
TELES, Vinícius Manhães.. Um estudo de caso da adoção das práticas e valores do Extreme Programming. Dissertação (Mestrado em Informática) – Universidade Federal do Rio de Janeiro - UFRJ, IM / DCC, 2005
TELES, Vinícius Manhães. Extreme Programming. Disponível em <http://www.nce.ufrj.br/conceito/artigos/2006/015p1-3.htm>. Acesso em 03 set. 2007a.
______. Extreme Programming. Disponível em <http://www.improveit.com.br/xp>. Acesso em 01 out 2007b.
THESIS. Treinamento e Desenpenho. Disponível em <http://www.e-thesis.inf.br/index.php?option=com_content&task=view&id=1483&Itemid=52> . Acesso em 05 fev. 2008.
THIRY, Marcello. Wangenheim, Christian Gresse von. Analisando a Integração da ISSO/IEC 15504, CMMI-SE/SW e MPS.BR. Laboratório de Qualidade e Produtividade de Software – LQPS. 2005.
137
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos. Rio de Janeiro: Brasport, 2002.
VERNADAT, F.B. Enterprise modeling and integration: principles and applications. London – UK: Chapman & Hall, 1996.
VIEIRA, Marconi Fábio. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro: Campus, 2003.
XPRIO. eXtremme Programming - Rio. Disponível em <http://tech.groups.yahoo.com/group/xprio/> . Acesso em 24 nov. 2007.
YOURDON, Edward. Projetos Virtualmente Impossíveis: Guia Completo do Desenvolvedor de Software para Sobreviver aos Projetos Virtualmente Impossíveis ; tradução Regina Cláudia Loverri ; revisão técnica Paulo César Masiero / São Paulo: Makron Books, 1999.