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
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
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.
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.
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.
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.
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
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.
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 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
Tabela 1 - Lista de problemas classificadas por prioridade...69 Tabela 2 - Relação problema versus solução ...107
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
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
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.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.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.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.10 Dificuldade no controle das tarefas em andamento...130
5.3 ANÁLISE GLOBAL DOS RESULTADOS...131
6 CONCLUSÃO ... 132
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.
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
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.
• 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.
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.
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.
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.
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.
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.
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.
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).
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
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
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).
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
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).
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)
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:
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
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:
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.
• 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.
• 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.
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).
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
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.
• 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.
• 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.
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).
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.
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
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
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
