Universidade Estadual de Maringá Centro de Tecnologia ...de software, os modelos de...
68
Universidade Estadual de Maringá Centro de Tecnologia Departamento de Engenharia de Produção Práticas de Melhoria Contínua para o Processo de Desenvolvimento Colaborativo de Software Lucas Mota Alves TCC-EP-61-2012 Maringá - Paraná Brasil
Transcript of Universidade Estadual de Maringá Centro de Tecnologia ...de software, os modelos de...
Universidade Estadual de Maringá Centro de Tecnologia Departamento de Engenharia de Produção
Práticas de Melhoria Contínua para o Processo de Desenvolvimento Colaborativo de Software
Lucas Mota Alves
TCC-EP-61-2012
Maringá - Paraná Brasil
ii
Universidade Estadual de Maringá Centro de Tecnologia
Departamento de Engenharia de Produção
Práticas de Melhoria Contínua para o Processo de Desenvolvimento Colaborativo de Software
Lucas Mota Alves
TCC-EP-61-2012
Trabalho de conclusão de curso apresentado como requisito de avaliação no curso de graduação em Engenharia de Produção na Universidade Estadual de Maringá – UEM. Orientador: Prof. Edwin Cardoza
Maringá - Paraná 2012
iii
AGRADECIMENTOS
Agradeço primeiramente a Deus, por ser presente e ter dado condições para que
concluísse mais essa etapa, por ter colocado pessoas chaves que foram responsáveis pelo
processo de aprendizado acadêmico e pessoal como:
Ao Professor Dr. Edwin Cardoza pela orientação nesse trabalho, pela dedicação e
paciência que teve em lê-lo e toda contribuição e melhoria para que obtivéssemos um
resultado satisfatório na conclusão desse trabalho. Por meio deste, pude ter os primeiros
contatos com a produção de um trabalho científico e na elaboração de uma pesquisa.
À ex-chefe do Departamento de Engenharia de Produção, Professora Dra. Márcia
Marcondes Altimari Samed que me ajudou a chegar até aqui, que não mediu esforços e foi
alicerce para a conclusão de mais essa etapa.
À minha mãe, Nilda de Paiva Alves, que foi primordial nessa conquista, que esteve
presente em todos os momentos da minha vida e até nos mais delicados, que me fez acreditar
que a vitória é possível, palavras são poucas para expressar a imensa gratidão e
reconhecimento do seu esforço para comigo, este trabalho é resultado de todo o seu empenho
e estímulo, à ti, meu muito obrigado.
À minha irmã, Deise Mota Alves, e espero um dia poder retribuir tudo que ela fez e
está fazendo por mim. Sou muito grato por toda a ajuda que me deu e, se eu cheguei até aqui,
foi porque ela sempre esteve ao meu lado e nunca me esquecerei de tudo que ela fez por mim,
sempre me ajudou, sem pedir algo em troca. Não tenho palavras para agradecer a sua amizade
e a sua ajuda em todos os momentos da minha vida.
Ao meu pai, Laci Mota Alves, e às minhas irmãs Débora Mota Alves e Lucy Mota
Alves, por todo apoio e que também exerceram papéis importantes na minha jornada, que
foram estímulos e que acreditaram no meu sonho, meus sinceros agradecimentos.
E por fim, agradeço à Universidade Estadual de Maringá (UEM) por todo o suporte
que me foi dado durante a minha vida acadêmica nessa renomada instituição e a todos aqueles
que direta ou indiretamente contribuíram para a conclusão deste trabalho.
iv
RESUMO
Este trabalho apresenta conceitos fundamentais do processo de desenvolvimento colaborativo de software, os modelos de desenvolvimentos de software que podem ser aplicados ao desenvolvimento colaborativo de software, além de apresentar uma comparação entre as melhores práticas do modelo de desenvolvimento tradicional, ágil e de software livre, exemplificando cada um desses modelos, tendo como objetivo principal apresentar modelos que auxiliem na melhoria contínua no processo de desenvolvimento colaborativo de software como o modelo CMMI e MPS.BR. Neste trabalho apresentar-se-á a caracterização de uma empresa que trabalha com desenvolvimento colaborativo de software, sendo utilizado um questionário e conversas informais com um integrante da empresa para a coleta das informações referentes ao processo de desenvolvimento seguido pela empresa, foi sugerida a aplicação do RUP para servir como guia do seu processo de desenvolvimento de software por ser uma metodologia dirigida por casos de usos, sendo útil para empresa trabalhar com casos de usos para melhor captar as necessidades do cliente e realizar os casos de testes e a implantação do modelo CMMI em todas às suas áreas de processo para que, dessa maneira, fosse possível alcançar a melhoria contínua no processo e monitorar a qualidade de todo o processo de desenvolvimento de software.
Palavras-chave: CMMI, Desenvolvimento Tradicional, Desenvolvimento de Software Livre, Desenvolvimento Ágil, RUP, XP, MPS.BR, Implantação do Modelo de Melhoria CMMI, Práticas de Melhoria Contínua no Desenvolvimento Colaborativo de Software.
v
Abstract
This paper presents the fundamental concepts of the process of collaborative software development, models of software developments that can be applied to collaborative software development is presented a comparison between the best practices of traditional development model, agile, open source and exemplifying each one of these models, with the main objective to present models that contribute to continuous improvement in the development process colaoborativo software like CMMI model and MPS.BR, this monograph is performed to characterize a company that works with collaborative development of software being used a questionnaire and informal conversations with a member of the company for the collection of information regarding the development process followed by the company, suggested the application of RUP to serve as guide the process of software development methodology to be directed by cases of uses is useful company to work with use cases to better capture customer needs and deliver the test cases and implementation of CMMI model in all areas of their process so this way it was possible to apply continuous improvement in process and monitor the quality of all the process of software development.
Key-words: CMMI, Traditional Development, Free Software Development, Agile, RUP, XP, MPS.BR, Deployment Model CMMI Improvement, Continuous Improvement Practices in Collaborative Software Development.
vi
SUMÁRIO
LISTA DE FIGURAS ....................................................................................................................................... VII
LISTA DE QUADROS .................................................................................................................................... VIII
LISTA DE ABREVIATURAS E SIGLAS ................................................................................................................ IX
1 INTRODUÇÃO ....................................................................................................................................... 1
1.1 Justificativa ....................................................................................................................................... 4
1.2 Definição e Delimitação do Problema ................................................................................................ 5
1.3 Objetivos ........................................................................................................................................... 6
1.3.1 Objetivo geral .............................................................................................................................................. 6
1.3.2 Objetivos específicos ................................................................................................................................... 6
1.4 Metodologia ...................................................................................................................................... 7
1.5 Estrutura do Trabalho ....................................................................................................................... 8
2 REVISÃO DE LITERATURA ...................................................................................................................... 9
2.1 Processo de Desenvolvimento Colaborativo de Software ................................................................... 9
2.1.1 Modelos de referências ............................................................................................................................. 11
2.1.2 Análise comparativa dos métodos tradicionais x métodos ágeis .............................................................. 16
2.2 Melhoria de Processos de Software ................................................................................................. 17
2.2.1 Análise Comparativa entre o CMMI x MPS.BR .......................................................................................... 22
2.3 Fatores Críticos de Sucesso para Implantação de Modelos de Melhoria de Processo de Software ... 25
3 DESENVOLVIMENTO ........................................................................................................................... 28
3.1 Empresa de Desenvolvimento de Software ...................................................................................... 28
3.2 Processo de Desenvolvimento de Software ...................................................................................... 30
3.3 Práticas de Desenvolvimento Colaborativo de Software .................................................................. 35
3.4 Análise dos Resultados .................................................................................................................... 38
3.5 Proposta de Melhoria ...................................................................................................................... 40
3.5.1 Método de implantação ............................................................................................................................ 42
3.5.2 Provavéis procedimentos .......................................................................................................................... 45
4 CONCLUSÕES ...................................................................................................................................... 48
4.1 Resultados Esperados com as Práticas de Melhoria Contínua no Processo de Desenvolvimento
Colaborativo de Software ......................................................................................................................... 48
4.2 Considerações Finais ....................................................................................................................... 49
4.3 Limitações da Pesquisa .................................................................................................................... 51
4.4 Atividades Futuras ........................................................................................................................... 51
REFERÊNCIAS .............................................................................................................................................. 53
APÊNDICE A ‐ QUESTIONÁRIO PARA COLETA DE INFORMAÇÕES .................................................................. 58
vii
LISTA DE FIGURAS
Figura 1 – Fluxograma do Processo de Desenvolvimento dentro da empresa (Adaptado de
JUNIOR 2007) .......................................................................................................................... 31
Figura 2 – Estrutura da VOB (Versioned Object Base) (adaptado de IBM 2012) ................... 33
viii
LISTA DE QUADROS
Quadro 1 – Análise comparativa entre os métodos tradicionais e ágeis .................................. 17
Quadro 2 – Representação dos níveis de capacidade e seu significado ................................... 19
Quadro 3 – Representação dos níveis de maturidade e seu significado ................................... 20
Quadro 4 – Análise comparativa entre dois modelos de softwares: CMMI x MPS.BR .......... 23
Quadro 5 – Ferramentas e seus respectivos fornecedores ........................................................ 29
Quadro 6 – Resultados esperados com o uso das práticas de melhoria continua ..................... 48
ix
LISTA DE ABREVIATURAS E SIGLAS
PDCS = Processo de Desenvolvimento Colaborativo de Software CMMI = Capability Maturity Model Integration CSD = Colaborative Software Development CSE = Colaborative Software Engineering RUP = Rational Unified Process UML = Unified Modeling Linguage XP = Extreme Programing CSM = Certified Scrum Master SOFTEX = Associação para Promoção da Excelência do Software Brasileiro SPICE = Software Process Improvement and Capability Determination
1
1 INTRODUÇÃO
Anderson (2009) descreve que o desenvolvimento colaborativo de software é o conjunto de
vários programadores, separados geograficamente ou não, em busca de um mesmo interesse e
dedicam parte do seu tempo na implementação, manutenção ou melhoria dos sistemas de
software livre. Esses programadores podem ser voluntários ou remunerados. Normalmente, o
paradigma do desenvolvimento colaborativo tem sido utilizado amplamente no
desenvolvimento de software livre. Por meio dele, é possível obter alguns resultados positivos
como a rapidez e a eficiência. O desenvolvimento colaborativo é um recurso que tem
evidenciado o sucesso do seu uso por diversas empresas renomadas no mercado, como a IBM,
RedHat, Sun, Oracle e até mesmo pelo difundido sistema operacional Linux.
Nayak e Suesaowaluc (2008) relatam que uma das grandes vantagens do desenvolvimento
colaborativo é a possibilidade de ter vários desenvolvedores em diversas partes do mundo
produzindo soluções e melhorias para o mesmo sistema, graças ao fuso horário, uma
codificação por quase 24 horas por dia. Isso seria praticamente inviável para uma empresa
devido ao alto custo gerado. Além disso, como não há uma pressão comercial, atualizações
das versões de softwares só são geradas depois de muitos testes e, caso algum erro seja
encontrado, é corrigido rapidamente e isso torna o código muito mais estável e seguro.
Huyen e Ochimizu (2011) afirmam que é possível identificar alguns pontos importantes no
emprego desse recurso como: a descentralização, prazos na entrega do produto, comunicação,
organização e responsabilidades, isso porque cada grupo tem o seu próprio modo de controle,
distribuição das responsabilidades e organização interna.
Lima e Reis (2007) ressaltam que a descentralização é considerada um fator bom, pois
possibilita o desenvolvimento ininterrupto do software por 24 horas ao dia, o aumento da
produtividade, reduz os custos de desenvolvimento referentes à equipe de desenvolvedores,
facilita o reuso de conhecimento e projeto, em contrapartida suas desvantagens são a
exigência de um mecanismo de comunicação e troca de informações mais eficiente,
interpretação errônea de mensagens que são trocadas entre os colaboradores, resultando em
perdas de esforço e tempo.
2
Os prazos na entrega do produto podem ser considerados um fator positivo, desde que se faça
o planejamento do cronograma levando em conta o tempo, esforço, análise de riscos, ou
negativo, se não existir uma documentação que prove o prazo acordado, forçando a empresa a
se desdobrar para atender o cliente caso o mesmo reduza o prazo de entrega do software.
No caso de organização e disciplina, suas vantagens são o fato de as pessoas que trabalham na
empresa poderem fazer seus horários, ou seja, a flexibilidade de horário para execução de
suas tarefas, cada um tem suas responsabilidades bem definidas de acordo com sua aptidão, já
as desvantagens são a falta de compromisso que pode existir por parte dos colaboradores por
não haver uma fiscalização presencial de suas atividades.
Os desafios de desenvolvimento de software como um time, podem ser reduzidos pelo uso do
groupware (sistema baseado em computador para auxiliar grupo de pessoas que estejam
envolvidas nas mesmas atividades ou com objetivos comuns e que provê interface para um
ambiente compartilhado) para coordenar e comunicar os detalhes complexos envolvidos no
processo. Tomarello e Deek (2002) ressaltam que o profissional de computação
contemporânea deve trabalhar em um ambiente onde os programas são milhares ou milhões
de linhas de código, muitas vezes são mais modificados e mantidos em vez de construídos,
são manipulados em um ambiente rico em ferramentas, onde o trabalho é geralmente um
esforço de equipe e onde a forma de uma solução tem profundo impacto no custo e no
desempenho futuro. Esses grandes sistemas precisam ser mantidos e podem ter novas
exigências ou mudança e, portanto, requerem a colaboração em grupo. Além disso, a
resolução de problemas está no centro do desenvolvimento de software.
De acordo com Tommarello e Deek (2002) enquanto se aprende a desenvolver software, os
programadores iniciantes muitas vezes encontram dificuldade de entender os conceitos
básicos na solução de problemas. Suas deficiências estão na resolução de problemas e
estratégias de conhecimento tático, equívocos sobre sintaxe, semântica e pragmática das
construções de linguagem e pedagogia ineficazes de instrução de programação. Outra barreira
à colaboração eficaz é a existência dessas condições citadas que impedem a livre expressão de
ideias em um grupo. Como, por exemplo, preconceitos de participação, características
pessoais e estrutura do grupo. No entanto, os benefícios da colaboração durante a resolução de
problemas superam as ineficiências do processo. Os grupos parecem ser capazes de lidar com
tarefas mais complexas de forma mais eficaz do que individualmente, porque os grupos têm
3
um maior leque de competências e habilidades. O estudo de Tommarello e Deek (2002)
propôs determinar se, de fato, existem ferramentas disponíveis para auxiliar na resolução
desses problemas colaborativos e no processo de desenvolvimento.
Niazi et al. (2005) defendem que diferentes avanços têm sido alcançados no processo de
melhoria de desenvolvimento de software nos padrões e modelos, como por exemplo, o CMM
(Capability Maturity Model), mais recentemente, CMMI, ISSO 15504 (SPICE). No entanto,
esses avanços não foram acompanhados na adoção dessas normas e modelos de
desenvolvimento de software que tem resultado em sucesso limitado para muitos esforços do
processo de melhoria de desenvolvimento.
Segundo Niazi et al. (2005), a importância da implementação do processo de melhoria exige
que ela seja reconhecida como um processo complexo em si mesmo e que as organizações
deveriam determinar a maturidade de implementação, no processo de melhoria de
desenvolvimento, por meio de um conjunto organizado de atividades. Na literatura, muita
atenção tem sido dada ao "quais atividades implementar" em vez de "como implementá-las".
Acredita-se que a identificação de apenas "quais" atividades implementar não seja suficiente
e, que o conhecimento de "como" implementar também se faz necessário para uma
implementação bem sucedida dos programas do processo de melhoria.
Um dos modelos de melhoria e avaliação de processos de software amplamente utilizado é o
MPS que é baseado nas normas ISO/IEC 12207 e ISO/IEC 15504 (também conhecida como
SPICE) e também tem compatibilidade com o modelo CMMI. O CMMI é composto por três
componentes: Modelo de referência para melhoria de processos de software (MR-MPS),
método de avaliação para melhoria de processos de software (MA – MPS) e modelo de
negócio para melhoria de processos de software (MN – MPS) (Kival, et al., 2005).
De acordo com Soares (2004), as empresas, visando melhorar a qualidade do software
produzido, investem em metodologias ágeis como o XP programing e SCRUM, que
permitem maior flexibilidade com relação à mudança de requisitos por parte do cliente,
rapidez de desenvolvimento, focando em pessoas em vez de processos, reduzindo o tempo
gasto com documentações e permitindo um maior esforço para a resolução de problemas de
forma iterativa.
4
Segundo SWANSON (1997), o software pode ser definido como um conjunto de atividades,
métodos e transformações que as pessoas usam para desenvolver e manter programas e
produtos associados como, por exemplo, planos de produtos, documentos de projeto, códigos,
casos de testes e manuais de usuário. A qualidade de um sistema de software é governada pela
qualidade do processo empregado para desenvolvê-lo e mantê-lo.
O foco deste trabalho é entender como se dá o processo de desenvolvimento colaborativo de
software (PDCS), as práticas de melhoria contínua utilizadas pelas empresas no setor de
software e identificar as oportunidades de melhoria contínua no PDCS. Para tanto, a próxima
seção descreve o cenário atual do desenvolvimento colaborativo de software, quais recursos
podem ser empregados para aprimorar o resultado, além de evidenciar a necessidade do uso
da melhoria contínua no processo colaborativo de software.
1.1 Justificativa
Sávio (2007) relata que o desenvolvimento colaborativo de software tem ganhado adeptos ao
redor do mundo inteiro, porém, esse crescimento rápido tem trazido algumas consequências
que devem ser analisadas com cautela. Devido à falta de organização formal, alguns fatores
desfavoráveis podem ser apontados como decorrentes da construção cooperativa, como:
redundância de esforços, problemas de comunicação, senso de prioridade, proliferação de
“grupos fechados”, falta de foco, dependências de pessoas-chave, escassez de líderes
competentes e até mesmo questões legais, pode-se ressaltar também alguns fatores técnicos
como, sincronização, concorrência, documentação, distância física, diferença de cultura e fuso
horário, o que dificulta ainda mais a comunicação.
Em todo sistema de desenvolvimento de software é necessário o emprego de recursos de
Engenharia de Software para aprimorar e obter melhores resultados. Como existem vários
desenvolvedores no método colaborativo, é necessário o emprego de algumas ferramentas
para versionamento de versões de software, técnicas que auxiliem na comunicação entre as
diversas partes, documentação que elucide as normas que devem ser empregadas para o
desenvolvimento das atividades, levantamento dos requisitos e, por fim, testes e implantação
do sistema.
5
Há qualidades que tornam o desenvolvimento de software um assunto apropriado a este
trabalho. O fato de usar o contexto de Engenharia de Software cria um conjunto de condições
e exceções para o apoio à colaboração que indicam uma solução mais elaborada, ao mesmo
tempo em que proporciona a viabilidade de instituir objetivos, métricas e outros apontadores
de qualidade e eficácia na execução das tarefas (SÁVIO, 2007).
Thiry et al. (2006) afirmam que existe uma grande necessidade de melhoria contínua nos
processos de desenvolvimento colaborativo de software de uma organização, porque muitas
vezes eles não são bem caracterizados e entendidos, falta a definição de um conjunto padrão
de processos e, mesmo quando são definidos, há uma ausência de documentação dos mesmos,
de um modelo de desenvolvimento de processos de software a ser seguido e da avaliação da
eficiência dos processos que possibilita o monitoramento e controle de todo o processo de
desenvolvimento.
O delineamento do processo colaborativo de desenvolvimento de software permitirá propor
sugestões e melhorias para motivar futuros desenvolvedores a engajarem e acreditarem na
evolução desse processo. Esses por sua vez, poderão contribuir e enriquecer projetos futuros
que podem se tornar exemplos para o ambiente colaborativo de software.
Para tanto, é necessário entender e delimitar o problema que será estudado, conhecendo-o
para que se possa ser analisado e mensurado, isso pode ser visto na próxima seção.
1.2 Definição e Delimitação do Problema
Sávio (2007) explica que quando se tem a oportunidade de participar de algum projeto que
envolva o conceito de desenvolvimento colaborativo, são encontradas algumas limitações,
que talvez, desestimulam a equipe de desenvolvimento. O líder de um projeto colaborativo
normalmente não é eleito por votos, mas sim pelo conhecimento, geralmente é detentor de
grandes talentos e assim se torna tutor e responsável pelos demais interessados em participar
do mesmo projeto. O que geralmente acontece é que nem sempre o líder tem experiência em
liderança, e isso pode trazer alguns inconvenientes para alcançar o sucesso no projeto
colaborativo. Esse é um dos problemas que pode ser citado como parte do problema. Outros
problemas como a comunicação e dependências de pessoas-chave também farão parte do
problema a ser estudado.
6
Além disso, como já citado anteriormente, não existe uma pressão comercial em torno dos
projetos colaborativos e definir as prioridades pode parecer impraticável, porém, ao contrário
do que se pensa, é necessário ter senso de prioridade, organizar metas e, nesse âmbito, a
Engenharia da Qualidade, com uso do planejamento e controle da qualidade, abrange recursos
que podem delinear excelentes alternativas para administrar e quantificar o grau de prioridade
para que se alcance o melhor planejamento e otimização do processo de desenvolvimento de
software (SÁVIO, 2007).
Reis (2003) ressalta que é desejável que o líder de um projeto desenvolvido de forma
colaborativa, tenha a capacidade de indicar quais desenvolvedores ficarão responsáveis pela
construção de um determinado componente ou subsistema, definindo as tarefas que deverão
ser realizadas e também dando suporte necessário quando surgir alguma dúvida ou
dificuldade relacionada à execução da tarefa, monitorando a eficiência de cada integrante da
equipe, a qualidade do resultado obtido, para que seja possível aplicar melhorias no processo
de desenvolvimento de software e promover a manutenção das mesmas.
1.3 Objetivos
1.3.1 Objetivo geral
Identificar e elaborar uma proposta de ações de melhoria contínua para promover o
desempenho no Processo de Desenvolvimento Colaborativo de Software.
1.3.2 Objetivos específicos
1) Descrever modelos de referências (processos e ferramentas de suporte) que guiem o
PDCS e as práticas de melhoria contínua.
2) Identificar práticas de melhoria contínua no PDCS.
3) Propor práticas de melhoria contínua no PDCS.
4) Analisar a viabilidade da proposta.
7
1.4 Metodologia
Esse tópico descreve a metodologia que será empregada, nesse trabalho, a fim de alcançar os
objetivos descritos.
Segundo Silva e Menezes (2005), esta pesquisa é classificada como uma pesquisa de natureza
básica, possui uma abordagem qualitativa, relacionada aos objetivos de caráter exploratório.
Este trabalho é constituído de duas partes: a pesquisa bibliográfica, sendo definido o processo
de desenvolvimento colaborativo de software, identificada uma lista de melhores práticas que
podem ser utilizadas em modelos de desenvolvimento distribuído de software, apresentando
os diferentes modelos de referências para o desenvolvimento de software e fazendo-se uma
comparação das características desses modelos, descrevendo metodologias utilizadas para
melhorias no processo de desenvolvimento de software e comparando suas características.
Para a coleta de informações foram utilizados questionários com questões subjetivas que
foram aplicados a um integrante da empresa e também obtidas informações relevantes por
meio de conversas informais ao telefone com esse integrante. A implantação dos métodos
sugeridos neste trabalho será feita inicialmente dentro de um pequeno grupo piloto para que
se possa analisar e quantificar os resultados obtidos e, desse modo, espera-se alcançar todos
os setores que envolvam as atividades de desenvolvimento de software.
Realizou-se uma avaliação por meio de questionários em uma empresa a partir da opinião dos
desenvolvedores sobre as metodologias e ferramentas apresentadas, com intuito de verificar a
melhoria contínua da qualidade no processo de desenvolvimento colaborativo de software,
além disso, foi apresentada uma comparação entre as ferramentas e modelos disponíveis que
podem ser usados no PDCS identificando, desse modo, as melhores ferramentas e modelos
que auxiliam na melhoria contínua e, finalmente foi feita a proposta de práticas de melhoria
continua que possam ser aplicadas no PDCS.
Foram descritas as melhores práticas de melhoria continua para serem aplicadas nos
problemas de desenvolvimento colaborativo de software, para tentar minimizar o controle do
prazo de entrega, pressão comercial, organização e compartilhamento de informação dentro
do time, em diversas partes do mundo entre outros, como já mencionado no capítulo inicial
dessa monografia.
8
1.5 Estrutura do Trabalho
Neste capítulo, foi apresentado o contexto em que se insere o trabalho, a justificativa, a
definição do problema e os principais objetivos do tema em questão. O restante do trabalho
está organizado em 5 capítulos, que serão descritos a seguir:
No Capítulo 2, é apresentada a bibliografia considerada relevante para fundamentação
teórica deste trabalho;
O Capítulo 3 descreve a empresa em que foi realizada a pesquisa, o processo de
desenvolvimento de software por ela empregado, e algumas práticas de
desenvolvimento colaborativo que são aplicados nessa empresa em questão, apresenta-
se a análise dos resultados e por fim uma proposta de melhoria, e,
O Capítulo 4 apresenta as considerações finais do trabalho, relata as limitações que
foram encontradas na pesquisa e propõe algumas possíveis atividades que podem ser
realizadas no tema abordado;
9
2 REVISÃO DE LITERATURA
2.1 Processo de Desenvolvimento Colaborativo de Software
O termo desenvolvimento colaborativo de software (CSD – Collaborative Software
Development ou CSE – Collaborative Software Engineering) tem sido usado mais
especificamente quando o pessoal envolvido encontra-se disperso entre as diversas áreas da
organização ou mesmo disperso geograficamente, conforme classificado por Cook (2005).
Nayak e Suesaowaluk (2008) relatam que o processo de desenvolvimento colaborativo de
software envolve várias equipes, trabalhando para diversas unidades empresariais dentro da
mesma unidade ou diferente e sem nenhum poder central. O desenvolvimento de software em
um cenário deste tipo, muitas vezes ultrapassa as fronteiras nacionais, linguísticas e culturais e
necessita de mudanças de natureza da gestão de risco.
Segundo Nayak e Suesaowaluk (2008), o desenvolvimento de software afastou-se do
protótipo de "estrutura de gestão simples de equipe e local único" para distribuído, equipes de
colaboração com as relações de gestão elásticas. Além disso, experiências recentes com
projetos complexos revelaram que as velhas práticas de desenvolvimento, requisitos
totalmente especificados e assinados e interfaces totalmente pré-determinada entre os
principais componentes, têm problemas substanciais e estão, em particular, suscetíveis tanto à
pressão do planejamento quanto às mudanças imprevistas e eventos.
Nayak e Suesaowaluk (2008) ressaltam que os fatores econômicos têm incentivado práticas
de desenvolvimento inter-organizacionais, por exemplo, outsourcing (terceirização) e off-
shoring (modelo de realocação de processos de negócio de um país para outro). Por estas
razões, abordagens menos centralizadas para o desenvolvimento têm sido seguidas. O
processo de desenvolvimento colaborativo de software precisa de uma visão comum do
produto e da arquitetura, a ideia ampla e troca de projeto, compartilhamento contínuo de
informação e utilização efetiva da consulta, consentimento e consenso inibido apenas pela
propriedade intelectual, privacidade e considerações de segurança.
De acordo com Kosminsky (2007) há uma exigência de softwares cada vez mais complexos
para atender as necessidades dos clientes aliada a dificuldade em se achar mão de obra
10
qualificada em um determinado local e em um ambiente globalizado em que as empresas
querem expandir o seu mercado consumidor, gerando uma descentralização do processo de
desenvolvimento de software.
Segundo Barthelmess (2003) a aplicação de uma estrutura para um plano específico provoca
um processo de criação, incluindo as responsabilidades de cada colaborador, seus respectivos
direitos de acesso e um cronograma das tarefas que devem ser criadas. Assim, o processo
produz o contexto de atividade de cada cooperador.
Reis (2003) define cinco fases essenciais para a construção de qualquer software:
Análise e definição de requisitos: esta atividade consiste em se definir as
funcionalidades do software, o que envolve a participação do cliente, já que este será o
usuário final do sistema.
Projeto Arquitetural e Detalhado: esta atividade realiza a conversão de todos os
requisitos definidos na fase de análise em uma descrição de componentes que serão
transformados em código.
Codificação: atividade em que ocorre a criação do código fonte, tendo como base os
requisitos definidos na Análise e definição de requisitos, portanto, sendo
implementadas as funcionalidades do sistema.
Teste de unidade, de integração e de sistema: São realizados testes para verificação de
erros e para o funcionamento do sistema, quando integradas todas as suas partes ou
componentes.
Manutenção e evolução: correção de erros provenientes de falhas do sistema e
alteração do software devido às novas necessidades do cliente.
Casey (2010) descreve quatro fatores como primordiais para o sucesso do desenvolvimento de
projetos distribuídos:
11
Coordenação: coordenar uma equipe virtual exige um planejamento preciso, avaliação
de ricos, divisão de tarefas segundo as habilidades e experiência dos integrantes da
equipe de projeto.
Visibilidade: é necessário que os membros do projeto tenham acesso às tarefas
executadas pelos outros integrantes da equipe, as responsabilidades devem ser
atribuídas de maneira adequada, seguindo um cronograma de atividades.
Comunicação: Adotar um vocabulário e ferramentas de comunicação comum à serem
utilizadas no projeto são essenciais para uma troca de informações eficiente.
Cooperação: Para que se alcance o sucesso no desenvolvimento de um sistema é
necessária à colaboração entre todos os membros de uma equipe, sendo imprescindível
para a resolução de problemas a troca de informações entre os colaboradores.
2.1.1 Modelos de referências
De acordo com Magdaleno (2010) existem três tipos de modelos de desenvolvimento de
software: modelo tradicional que é orientado ao planejamento, modelo ágil e modelo de
desenvolvimento de software livre.
O modelo de desenvolvimento tradicional é caracterizado pelos modelos sequenciais, de
maturidade e normas da qualidade, como o modelo CMMI, as normas ISO/IEC 12207,
ISO/IEC 15504 e MPS-BR (SOFTEX, 2012). Estes modelos de qualidade foram criados para
apoiar o desenvolvimento em ambientes de alto risco e projetos grandes e complexos que
possuem um alto custo, onde a relação entre cliente e equipe de desenvolvimento é constituída
pela a existência de um baixo nível de confiança com acordos baseados em contratos, essa
formalização contratual torna mais difícil a adaptação às mudanças (MAGDALENO, 2010).
O modelo tradicional sugere uma abordagem sistemática que orienta o desenvolvimento de
software começando pela definição de requisitos até a implantação do software, ele propõe a
coordenação por meio do comando e controle e tem como característica principal o registro
do conhecimento explícito sobre o software que está sendo desenvolvido, até a comunicação
entre todos os integrantes da equipe é formalizada por meio de documentação. Nesse modelo
12
o cliente é fundamental nas fases de especificação e validação de requisitos, já que o modelo
orientado ao planejamento considera que os requisitos são estáveis e não sofrerão mudanças
ao longo do tempo (NERUR et al., 2005). Nesse caso, qualquer alteração de requisito ou no
projeto ocasionará alteração na entrega do produto final, e, consequentemente, custos
exorbitantes serão gerados, podendo comprometer a qualidade e a confiabilidade do produto.
Pesquisas demonstram que trabalho realizado com pressão pode quadruplicar o número de
erros de software (STANDISH GROUP, 2004).
Alves et al. (2011) e Piske (2003) destacam que um dos exemplos de modelo tradicional é o
Rational Unified Process (RUP) que é uma metodologia para desenvolvimento de software
criada pela Rational Software, IBM, SoftTeam, Unisys, Alcatel e Q-Labs. O RUP pode ser
encontrado na forma de software e, como um conjunto de processos que guia o
desenvolvimento de software, possui uma estrutura formal e bem definida, constituído de
conceitos, regras e práticas. Uma das principais vantagens do RUP é o conceito de melhores
práticas, que visam reduzir os riscos e tornar o desenvolvimento de software mais eficiente. É
composto por um ciclo de desenvolvimento que é dividido em quatro fases, de acordo com o
tempo e cada fase está associada a um marco, a saber:
Iniciação: é definido o escopo do projeto, discussão sobre o problema, estimativa de
recursos necessários para a execução, analisando-se a viabilidade do projeto e
definindo se o projeto continua ou será cancelado.
Elaboração: planejamento das atividades e recursos necessários, se descreve o domínio
do problema, é estabelecida a arquitetura de desenvolvimento, eliminação de
elementos de alto risco como a mudança de requisitos por parte do cliente, mudanças
tecnológicas no que diz respeito à eficiência das ferramentas disponíveis, riscos de
habilidades dos integrantes do projeto e políticos.
Construção: Esta fase é responsável pela modelagem e desenvolvimento do software,
sendo realizada a implementação do código, deve ser adotada alguma notação
abordada pela Unified Modeling Linguage (UML).
13
Transição: Liberação do produto, sendo validados todos os requisitos exigidos, o
software é implantado no ambiente do cliente.
Segundo Alves et al. (2011), o RUP é constituído por um grupo de princípios centrais:
Dirigidos por caso de uso: é necessária a construção de vários casos de uso para a
obtenção dos requisitos, criação de um conjunto de cenários que descrevem a
interação entre os atores e o sistema, para a captação de todas as funcionalidades
requeridas.
Centrado na arquitetura: a arquitetura é a principal guia dos esforços da equipe para se
projetar, modelar e desenvolver o sistema, o RUP possibilita a utilização de diversos
modelos e visões arquiteturais, deve ser definida ao final da fase de elaboração e
servirá como base para as fases seguintes.
Iterativo e Incremental: O processo de desenvolvimento de software é executado de
modo iterativo, sendo que em cada iteração é incrementada uma funcionalidade do
sistema.
Focado em risco: o processo objetiva diminuir os riscos nas fases iniciais, os artefatos
gerados em cada iteração, principalmente na fase de elaboração, devem ser
selecionados de forma a garantir que os riscos de maior magnitude e impacto no
projeto venham a ser tratados primeiramente.
O modelo de desenvolvimento de software ágil abrange métodos tais como o XP (Extreme
Programing), SCRUM e Crystal. Beck et al. (2001) destaca quatro valores fundamentais do
manifesto ágil: maior foco em indivíduos e interações entre eles do que em processos e
ferramentas; software em funcionamento mais do que documentação abrangente; colaboração
com o cliente mais do que negociação de contratos; e responder às mudanças mais do que
seguir um plano.
Magdaleno (2010) destaca que os métodos ágeis têm como principais objetivos responder as
mudanças de requisitos que ocorrem devido às mudanças tecnológicas e necessidades dos
14
clientes, com isso o método ágil se baseia na adaptação do sistema às mudanças de mercado, é
executado de forma incremental e possui ciclos de desenvolvimento curto, este modelo exige
que se tenha um trabalho realizado de forma colaborativa com a combinação das habilidades
dos membros de uma equipe, gerando o mínimo de documentação necessária.
O XP é uma metodologia de desenvolvimento ágil, com iterações curtas, que objetiva tornar o
projeto flexível, diminuindo o custo das possíveis mudanças e utiliza o código gerado com um
indicador do progresso do projeto (LEAL, 2010). Possui um processo iterativo e incremental,
onde são realizados ajustes sucessivos e controlados durante o desenvolvimento do sistema,
esses ciclos de desenvolvimento curtos proporcionam um feedback constante por parte do
cliente e do próprio sistema. O XP também recomenda que as alterações e modificações
indicadas pelo cliente sejam bem vindas pela equipe de projeto, mesmo em uma fase
adiantada do ciclo de desenvolvimento (PINTO, 2010). Segundo Bassi (2008) a metodologia
XP está baseada em cinco valores primordiais:
Comunicação: é essencial para a criação de um produto de qualidade que venha a
suprir as necessidades do cliente. XP facilita a comunicação entre todos os integrantes
da equipe por meio de atividades colaborativas, a equipe de desenvolvimento
compartilha o mesmo objetivo, quanto maior for a comunicação entre os membros da
equipe mais sugestões para resolução de problemas vão surgir, aumentando a
colaboração para a execução de tarefas e transformando críticas em contribuições que
aprimoram as soluções antes mesmos de serem implementadas.
Simplicidade: é melhor procurar a solução mais simples para um problema e ir
melhorando-a aos poucos do que implementar uma solução complexa com
funcionalidades desnecessárias que aumentam a complexidade do código e geram uma
maior quantidade de erros, sendo necessário horas extras de programação e um
aumento da refatoração do código.
Coragem: conforme o conhecimento sobre o projeto aumenta, decisões tomadas
inicialmente têm que ser modificadas, assim, é fundamental ter coragem para
mudanças e inovação no projeto, ou seja, muitas vezes é necessário abandonar planos
e atividades já realizadas para que seja possível alcançar melhores soluções para o
desenvolvimento de sistema.
15
Feedback: tem que existir um feedback entre todos os stakeholders envolvidos no
projeto para que se possa identificar os problemas e se adaptar a eles, o quanto antes
forem identificadas barreiras, mais cedo serão minimizadas ou eliminadas. Quanto
mais avaliações forem realizadas no produto e no processo de desenvolvimento, em
um menor tempo, maiores serão as chances de identificar os problemas e as suas
respectivas soluções.
Respeito: entre as pessoas é essencial, para que os outros valores predominem. Sem o
respeito entre todos os integrantes da equipe de desenvolvimento de um projeto, a
comunicação e o feedback terão pouca eficiência e, a coragem de um integrante da
equipe poderá ser prejudicial aos demais, por não estar de acordo com os interesses e
objetivo da equipe. Toda a equipe responsável pelo desenvolvimento de um sistema
deve respeitar uns aos outros e também o trabalho que executam.
Magdaleno (2010) ressalta que o modelo de desenvolvimento de software livre é aquele que
os projetos são desenvolvidos de modo colaborativo e transparente, executados e planejados
de forma descentralizada. Os projetos de software livre normalmente têm a presença de
desenvolvedores que trabalham voluntariamente, possuem habilidades e disponibilidades
diferenciadas, distribuídos geograficamente e que se coordenam por meio de uma comunidade
virtual que utiliza a internet para se comunicar, têm um alto grau de integração e colaboração,
propiciando um ambiente voltado para inovação e criação, com pouca documentação e
sistematização do trabalho.
Na metodologia, há várias sugestões de procedimentos que proporcionam uma vasta lista de
atividades que completam a definição do projeto de software. Dentre as quais ressaltam-se o
Rational Unified Process (KRUCHTEN, 2000), pela popularidade, e o Catalysis (D'SOUZA,
WILLS, 1998), pela abrangência. Outros processos estão disponíveis, como modelo, o
desenvolvimento baseado em componentes considera o UML Components (CHESSMAN e
DANIELS, 2001) e o KORBA (ATKINSON et al., 2001). Há ainda uma convergência para a
sugestão de técnicas de criação ágeis, como, o Extreme Programming (BECK, 1999) e o
SCRUM (RISING e JANOFF, 2000).
16
Em projetos de desenvolvimento colaborativo de software, alguns itens de trabalho são
utilizados como mecanismos para coordenar tarefas e controlar o trabalho de desenvolvimento
compartilhado. O tagging é um mecanismo de computação, utilizado para comunicar assuntos
de interesse na gestão de tarefas de desenvolvimento, é adotado por muitas equipes e se
tornou uma parte significativa de muitos processos informais. Diferentes tipos de tags são
usados por várias partes interessadas em categorizar e organizar itens de trabalho. Tags são
usadas para apoiar a conclusão de tarefas, trabalho, articulação e intercâmbio de informações.
Mecanismos implícitos e explícitos evoluíram para gerenciar o vocabulário tag. O suporte
informal à ferramenta, predominante no domínio da computação social, pode desempenhar
um papel importante na melhoria da equipe base em práticas de desenvolvimento de software
(TREUDE, 2012).
Mudança de gestão é uma questão chave no desenvolvimento de software colaborativo. Em
um trabalho colaborativo, muitas mudanças aplicadas a objetos compartilhados, que são
executados simultaneamente, leva ao problema de inconsistência, causado por atividades de
mudança simultâneas em artefatos compartilhados. O CSM (Certified Scrum Master) é um
modelo de gerenciamento dinâmico do fluxo de trabalho (HUYEN, 2011).
2.1.2 Análise comparativa dos métodos tradicionais x métodos ágeis
Alguns estudos realizados por NETO (2004), SOARES (2004), BUENO et al. (2008),
SGANDERLA e LACERDA (2010), JUNIOR e YANZER (2011), descrevem as
comparações entre os métodos ágeis e tradicionais. A partir desses trabalhos é possível
enumerar as diferenças entre as metodologias tradicionais e ágeis, conforme o Quadro 1,
Adaptado de Soares (2004).
17
Quadro 1 – Análise comparativa entre os métodos tradicionais e ágeis
Descrição Métodos Tradicionais Métodos Ágeis
Exemplos RUP Scrum, XP
Enfoque/Valores Processos ou algoritmos Nas pessoas
Tempo
Muito tempo é demandado
para com o processo de
documentação
É gasto menos tempo com
processo de documentação e mais
tempo com implementação
Característica Preditivas Adaptativas
Carga de trabalho Aumento do número de carga
de trabalho
Carga de trabalho controlada e
sem exagero
Mudança de planejamento É gerado um alto custo Custo controlado
Visualização do software
final
Não é possível ter uma visão
parcial do produto final
É possível acompanhar e ver
resultados parciais do software
final
Cumprimento de prazos e
padrões de qualidade
Deixam a desejar e, muitas
vezes, não correspondem às
expectativas
Alcançados com sucesso
Tamanho das equipes Grande quantidade de
desenvolvedores
Pequenas e médias até 12
desenvolvedores
Análise de Risco Constante Não emprega muito esse recurso
Os argumentos citados no Quadro 1, referem-se aos conceitos chave do “Manifesto Ágil”,
onde foram estabelecidos os princípios comuns compartilhados por todas as metodologias
ágeis como Scrum, Extreme Programming (XP) (BECK, 2012).
2.2 Melhoria de Processos de Software
O Capability Maturity Model Integration (CMMI) é um modelo de referência para melhoria
de processos de software, dividido em áreas de processo agrupadas em quatro categorias:
gerenciamento de processos, gerência de projetos, engenharia e suporte. As áreas de processo
relacionadas à definição e melhoria de processos se concentram na categoria de
gerenciamento de processos. O CMMI se preocupa com estabelecer diretrizes, definir a
evolução e adaptação de processos padrão, treinar e acompanhar os objetivos estratégicos da
organização. Para o CMMI, uma organização é considerada madura quando melhora
18
continuamente os seus processos a partir da utilização de medições e técnicas estatísticas para
o controle do processo (MALHEIROS, 2010). De acordo com Anacleto (2004) e Gevaerd
(2009) os principais componentes do modelo CMMI são:
Áreas de processos: são várias práticas associadas a uma determinada área de processo
e que no momento em que são realizadas alcançam as metas que geram melhoria nessa
área.
Metas específicas: são metas associadas a uma área de processo, as quais definem
aspectos únicos e mostram o que tem de ser executado para atender as necessidades de
uma área de processo.
Práticas específicas: são práticas que sugerem atividades a serem executadas,
essenciais para se atingir as metas específicas.
Metas genéricas: relacionadas a mais de uma área de processo por isso são chamadas
de genéricas, se uma meta genérica é alcançada, isso quer dizer que se tem um maior
controle do planejamento e execução dos processos pertencentes à determinada área
de processo.
Práticas genéricas: dão a garantia de que será mantida a eficiência e eficácia dos
processos de uma área de processo, possibilitando o treinamento para todos os
integrantes da empresa, e que estes executem suas tarefas de maneira correta e a
manutenção da melhoria alcançada.
Segundo Gevaerd (2009), o CMMI serve para avaliar a maturidade dos processos de uma
organização e conduzir a melhoria. Consiste nas melhores práticas para a melhoria contínua
dos processos de desenvolvimento de software. Engloba diversos modelos de capacidade e
maturidade de processos de uma área específica da organização em um único modelo. A
representação para medir a melhoria nos processos de software pode ser contínua e, nesse
caso, é utilizado um nível de capacidade para mostrar o grau de maturidade do processo ou
estagiada, que utiliza um nível de maturidade, que mostra nas duas representações o mesmo
conceito de níveis.
19
Gevaerd (2009) descreve que o nível de capacidade é aplicado para atingir melhorias nos
processos organizacionais, nas áreas de processos individuais. Existem seis níveis de
capacidades, de 0 até 5, conforme representado no Quadro 2:
Quadro 2 – Representação dos níveis de capacidade e seu significado
Nível de Capacidade Significado
5 Em otimização
4 Gerenciado quantitativamente
3 Definido
2 Gerenciado
1 Executado
0 Incompleto
Fonte: Gevaerd (2009)
Castro et al (2006) descreve os seis níveis de capacidade:
Nível 0 – Incompleto: um ou mais dos objetivos específicos da área de processo não
foram alcançados e objetivos genéricos não existem;
Nível 1 – Executado: atinge os objetivos específicos da área de processo, dando
auxílio e possibilitando o trabalho necessário para a geração do software;
Nível 2 – Gerenciado: é um processo monitorado, controlado e revisado, em que existe
uma infraestrutura básica para suportar o processo.
Nível 3 – Definido: é um processo gerenciado que é adaptado, tendo como base um
grupo de processos padrões e as diretrizes da empresa.
Nível 4 – Gerenciado quantitativamente: este nível se caracteriza por um processo
definido que é controlado utilizando-se técnicas estatísticas e quantitativas.
Nível 5- Em otimização: é um processo controlado de forma quantitativa, que é
melhorado por meio do entendimento das suas causas comuns de variação, tendo
20
como objetivo a melhoria contínua da eficiência do processo com propostas de
melhorias incrementais e inovadoras.
Gevaerd (2009) relata que o nível de maturidade faz parte da representação por estágios e é
utilizado para se conseguir melhorias de processos organizacionais nas diversas áreas de
processo, considerando a empresa com um todo. Existem cinco níveis de maturidade de 1 a 5
como mostra o Quadro 3:
Quadro 3 – Representação dos níveis de maturidade e seu significado
Níveis de Maturidade Significado
5 Otimizado
4 Quantitativamente gerenciado
3 Definido
2 Gerenciado
1 Inicial
Fonte: Gevaerd (2009)
Castro et al. (2006) descreve os níveis de maturidade:
Nível 1 - Inicial: Os processos são imprevisíveis, pouco controlados, com ausência de
planejamento e acompanhamento do projeto;
Nível 2 - Gerenciado: Processos são caracterizados por projetos que têm planejamento
definido, sendo monitorados e controlados nos quesitos custo, funcionalidade e
cronograma;
Nível 3 - Definido: Processos são caracterizados para a organização e proativos;
Nível 4 - Quantitativamente Gerenciado: Processos são medidos e controlados;
Nìvel 5 - Otimizado: Foco na melhoria contínua dos processos.
21
Gevaerd (2009) discorre que o MPS.BR é um programa para avaliação e melhoria de
processo de Software brasileiro, coordenado pela Associação para Promoção da Excelência
do Software Brasileiro (SOFTEX). Sendo um modelo voltado para a melhoria de processos de
software de micro e pequenas empresas que almejam alcançar mais qualidade do produto
final. Foi criado a partir das normas ISO/IEC 12207, ISO/IEC 15504 que também podem ser
chamadas de Software Process Improvement and Capability Determination (SPICE) e CMMI
– SE/SWSM.
O Guia Geral (2011) ressalta que o MPS.BR é composto pelo Modelo de Referência (MR-
MPS), Método de avaliação (MA-MPS) e Modelo de Negócio (MN-MPS) para melhoria de
processos de software e utiliza o conceito da definição de maturidade e capacidade de
processos de software para melhoria da produtividade e qualidade do software produzido. De
acordo com Gevaerd (2009) o MPS.BR possui cinco documentos em formato de guias que
orientam as empresas que pretendem utilizá-lo, os quais são:
Guia geral: contém a descrição geral do MPS.BR, detalha o modelo de Referência
(MR-MPS), seus componentes e as definições necessárias e comuns para o seu
entendimento;
Guia de Aquisição: descreve um processo de aquisição de software com base no MR-
MPS;
Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os
requisitos para avaliadores líderes, adjuntos e instituições avaliadoras;
Guia de Implementação: constituído de sete partes, cada uma delas descrevendo como
implementar um determinado nível do MR-MPS.
Este modelo é composto de níveis de maturidade que indicam em que estágio de evolução o
processo se encontra. O MR – MPS define sete níveis de maturidade: A (Em otimização), B
(Gerenciado quantitativamente), C (Definido), D (Largamente definido), E (Parcialmente
definido), F (Gerenciado) e G (Parcialmente gerenciado). A escala de maturidade vai do nível
22
G até o A em que a empresa produz software com alta qualidade e eficiência, esse níveis
indicam onde a empresa deve realizar melhorias (GUIA GERAL, 2011).
Weber et al. (2008) ressaltam que o nível inicial G é caracterizado pela falta de padrões e
desorganização do processo, com a utilização de processos de apoio para o desenvolvimento
de software alcança-se o nível F, já no nível E deve ser usado um conjunto de processos que
apoiam a melhoria de processos padrões, no nível D o foco é a melhoria dos aspectos técnicos
do desenvolvimento de software, para atingir o nível C a empresa deve ter processos que dão
suporte à gerência de projetos. Com isso, a empresa deve buscar a prática do desenvolvimento
com base no reuso, para aumentar a produtividade e qualidade final do software.
Segundo o Guia Geral (2011), o MR-MPS define níveis de maturidade que são uma
combinação entre processos e sua capacidade, os processos são descritos a partir do seu
propósito e resultados esperados, que são utilizados para a avaliação do sucesso de
implementação do modelo, cada processo tem que gerar resultados apropriados para que
possa alcançar o propósito esperado, a medida da capacidade é baseada em um conjunto de
atributos de processo (AP), o MPS-BR define nove APs: AP 1.1 (o processo é executado),
AP 2.1 (o processo é gerenciado), AP 2.2 (os produtos de trabalho do processo são
gerenciados, AP 3.1 (o processo é definido), AP 3.2 (o processo está implementado), AP 4.1
(o processo é medido), AP 4.2 (o processo é controlado), AP 5.1 (o processo é objeto de
inovações), AP 5.2 (o processo é otimizado continuamente). Cada AP possui um resultado de
atributo de processo que serve para a avaliação da implementação do mesmo.
2.2.1 Análise Comparativa entre o CMMI x MPS.BR
Com relação aos modelos CMMI e MPS.BR, pode-se dizer que existe uma equivalência entre
eles. Contudo, essa equivalência é apenas unilateral, pois todos os requisitos das áreas de
processos do CMMI estão presentes no MPS.BR, porém a recíproca não é verdadeira (GUIA
GERAL, 2011).
A SOFTEX é uma comunidade que visa a excelência de qualidade do software brasileiro e
notou que o processo do CMMI não se adaptava com os padrões brasileiros, então, montou
um processo baseado na ISO (12207 e 15504) e CMMI, que fosse acessível às pequenas e
médias empresas. Essa alternativa se tornou uma solução para permitir que o software
23
brasileiro se tornasse um produto confiável e notório, como um produto de exportação
competitivo, visando aumentar a competitividade da indústria brasileira de software
(SOFTEX, 2012).
Rocha (2009) destaca que o MPS.BR possibilitou que as empresas se adaptassem aos padrões
de melhoria de processo de forma gradual e com custo mais baixo. Se uma empresa for
certificada pelo MPS.BR terá grande chance, se assim o desejar, de tentar a certificação do
CMMI e já com quase todo o processo enquadrado nas normas. Isso evita que as empresas
tenham gastos desnecessários, e assim o seu produto final terá um maior valor agregado.
A partir das informações disponíveis pela SOFTEX, foi possível montar um quadro
comparativo entre os processos de melhoria de software CMMI e MPS.BR esse quadro traz
os fatores chaves para o aumento de eficiência do desenvolvimento de software como o nível
otimizado, gerência quantitativa, reutilização de componentes e código, gestão de recursos
humanos, gerência de portfólios de projetos, reconhecimento internacional, custo para
certificação, porte da empresa, processo de garantia da qualidade, eliminação de
inconsistências, modelo estruturado em resultados esperados, modelo estruturado em áreas de
processos empregados no processo de desenvolvimento de software , os quais podem ser
listados no Quadro 4 (GUIA GERAL, 2011).
Quadro 4 – Análise comparativa entre dois modelos de softwares: CMMI x MPS.BR
(continua)
Fatores – Chaves Descrição
CM
MI
MPS
.BR
Otimizado A melhoria continua do processo é proporcionada pelo feedback quantitativo do processo e pelas idéias e tecnologias inovadoras.
√
Gerenciado Quantitativamente
Medidas detalhadas do processo de software e da qualidade do produto são realizadas. O processo e os produtos de software e a qualidade do produto são quantitativamente compreendidos e controlados.
√
Processo de Gerência de reutilização / Processo de
desenvolvimento para reutilização
Reúne os componentes do produto, gerando um modelo integrado consistente com o projeto e demonstra que os requisitos funcionais são satisfeitos para o ambiente alvo ou equivalente.
√
24
Quadro 4 – Análise comparativa entre dois modelos de softwares: CMMI x MPS.BR
(continuação)
Fatores – Chaves Descrição
CM
MI
MPS
.BR
RH: aquisição de pessoa / Gerência de conhecimento
O processo Gerência de Recursos Humanos inclui os requisitos da área de processo Treinamento Organizacional, mas tem requisitos relacionados à Aquisição de Pessoal e Gerência de Conhecimento que não estão presentes na área Treinamento Organizacional do CMMI. Abrange aquisição de pessoal, treinamento organizacional e gerência do conhecimento e no CMMI trata apenas de treinamento organizacional.
√
Gerência de Portfólios de Projetos
O propósito do processo Gerência de Portfólio de Projetos é iniciar e manter projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização.
√
Reconhecimento internacional
Muitas corporações têm investido na melhoria dos processos de desenvolvimento de software, visando produzir sistemas com mais qualidade, e adoção de modelos de qualidade de software com reconhecimento internacional que certifique que os sistemas desenvolvidos pelas empresas são sinônimo de qualidade. O modelo de qualidade CMMI é reconhecido internacionalmente e se tornou uma referência no mercado.
√
Custo elevado para certificação
O modelo CMMI é proprietário e um grande custo é demandado para a realização das avaliações do modelo a fim de se obter a certificação. Normalmente o custo varia de R$ 200 mil a R$1 milhão, dependendo da complexidade do processo.
√
Recomendado à empresas de grande porte
Apesar dos dois modelos de desenvolvimento terem sido criados com o mesmo propósito, o foco de atuação dos modelos é diferente. Enquanto o MPS BR é um modelo criado em função das médias e pequenas empresas, o CMMI tem um foco global, mais voltado para as empresas de maior porte.
√
Recomendado à pequenas e médias empresas
√ √
Processo Garantia da Qualidade – GQA
O propósito do processo Garantia da Qualidade é assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos.
√ √
25
Quadro 4 – Análise comparativa entre dois modelos de softwares: CMMI x MPS.BR
(conclusão)
Fatores – Chaves Descrição
CM
MI
MPS
.BR
Eliminação de inconsistências e redução de duplicidade
Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos.
√ √
Modelo estruturado com resultados esperados
A capacidade do processo é representada por um conjunto de atributos de processo, descrito em termos de resultados esperados.
√
Modelo estruturado em áreas de processos
Como é um modelo de referência de processos, o CMMI não define como o processo deve ser implementado, mas prescreve suas características estruturais e semânticas em termos de objetivos e do grau de qualidade com que o trabalho deve ser realizado.
√
Fonte: Adaptado de GUIA GERAL (2011)
2.3 Fatores Críticos de Sucesso para Implantação de Modelos de Melhoria de Processo de Software
Segundo Oliveira (2008), o CMMI é um modelo proprietário, sendo necessário um elevado
gasto financeiro com a realização de avaliações para que a empresa venha a ser certificada,
para que a organização consiga atingir os últimos níveis de maturidade, terá que dispor de
tempo para a aplicação de melhorias no seu processo de desenvolvimento, considerando que
para alcançar os últimos níveis de maturidade leva-se em média de quatro a oito anos. Essas
adversidades impossibilitam que muitas empresas brasileiras implantem esse modelo, por não
terem recursos suficientes para aderir a ele.
Para Oliveira (2008) apesar de o MPS.BR ser um modelo voltado para o aumento da
qualidade de softwares oferecidos pelas médias e pequenas empresas, por meio de melhorias
nos seus processos de desenvolvimento de software, a certificação que oferece não é
suficiente para garantir que as empresas brasileiras sejam competitivas internacionalmente.
Rocha et al. (2005) destaca que um dos maiores fatores críticos de sucesso para implantação
de modelos de melhoria de processo de software, como o CMMI e o MPS-BR é o
comprometimento da alta gerência e dos colaboradores da empresa e, quando todos os
integrantes da organização se comprometem em atender as exigências do modelo e a alta
26
administração acompanha constantemente as atividades que estão sendo executadas, se obtém
resultados positivos para empresa. Outro fator de sucesso está na motivação dos
colaboradores em aprender e melhorar o modo como executam suas atividades e na motivação
da alta gerência, implantando um modelo de melhoria sendo avaliada e certificada,
conseguindo atender as necessidades do seu cliente e ganhando competitividade frente à
concorrência.
De acordo com Rocha et al.(2005) outros fatores de sucesso para implementação do modelo
CMMI e MPS-BR são: a disponibilidade de recursos financeiros para o acompanhamento da
implementação desses modelos, o nível de experiência das equipes responsáveis pela
implementação do modelo e o conhecimento sobre os métodos de avaliação, a qualificação
dos colaboradores que estão incumbidos de implantar os modelos de melhoria que fazem
parte da Equipe de Avaliação, o alinhamento dos processos com a estratégia de negócio da
empresa, a expansão dos negócios da empresa a partir do programa de melhoria.
Os fatores de sucesso para a implementação do MPS–BR são: distribuição das atividades
entre os colaboradores, alocação de recursos para a realização das tarefas, produtividade,
organização e controle dos projetos, precisão no cumprimento de prazos e custos, cultura
organizacional, apoio ferramental, comunicação, treinamentos inadequados ou inexistentes,
resistência a mudanças, disponibilidade e rotatividade de pessoal, diferentes objetivos e
perspectivas das pessoas que fazem parte da equipe avaliadora Rodrigues e Kirner (2010).
Rodrigues (2009) destaca que a distribuição das atividades se refere a uma melhor atribuição
das atividades entre os colaboradores para que se divida a carga de trabalho de maneira igual,
sem que nenhum colaborador fique sobrecarregado, outro fator de sucesso é a alocação de
recursos de uma maneira mais eficaz e eficiente na execução das atividades da empresa. O
fator de sucesso referente à produtividade analisa se houve um aumento da produtividade com
a implantação do modelo MPS-BR.
Rodrigues (2009) ressalta que se deve avaliar também se houve uma melhor organização e
controle dos projetos, sendo analisado se a empresa alcançou um melhor gerenciamento
desses projetos e, se foi possível um maior controle sobre as atividades de cada projeto, é
indicado avaliar se com a implantação do modelo MPS-BR houve melhoria nos tempos e
custos, verificando se a organização obteve uma estimativa mais precisa do tempo gasto dos
27
seus colaboradores em um projeto e, a partir daí, conseguir mensurar com um maior grau de
acurácia o seu custo total.
Rodrigues (2009) ressalva que a cultura organizacional está relacionada ao fato de que as
organizações que se acomodam e seguem a mesma rotina de trabalho ao longo do tempo
podem não aceitar mudanças que se façam necessárias para a melhoria da qualidade do
processo de desenvolvimento de software. Já o apoio ferramental se refere ao aumento da
documentação, a utilização de softwares para o controle de versões, desenvolvimento de
código e testes, a comunicação é um fator essencial sendo necessário o estabelecimento de um
eficiente canal de comunicação entre todos os setores da empresa.
O treinamento é fundamental para que os colaboradores possam se adaptar facilmente às
mudanças que surgirão devido à implantação do modelo de melhoria MPS-BR. No caso da
disponibilidade e rotatividade de pessoal, se a empresa não possui uma equipe dedicada
unicamente à implantação do modelo de melhoria e tem uma alta rotatividade de pessoal, o
processo de implantação desse modelo pode tornar-se mais lento, dado que diferentes
objetivos e perspectivas das pessoas que fazem parte da equipe avaliadora atrapalham a
implantação do modelo MPS-BR. Nesse caso, deve sempre se estabelecer objetivos claros
para que os integrantes da equipe busquem alcançar os mesmos resultados (Rodrigues, 2009).
28
3 DESENVOLVIMENTO
3.1 Empresa de Desenvolvimento de Software
Há mais de 70 anos no mercado, tem atuado em diversas áreas como: tecnologia de ponta,
semicondutores, construções, petroquímica, naval, automobilísticas e entre outras.
A empresa tem grande destaque no Brasil, na parte de mídia como TVs, Home theaters, linhas
brancas, como máquinas de lavar, geladeiras e atualmente tem ocupado a primeira posição em
vendas, no mercado brasileiro com os lançamentos dos seus diversificados modelos de
celulares, que tem sido responsável por cerca de 60% do seu faturamento global.
A empresa tem desenvolvido uma diversidade de produtos como Celulares e tablets, TV &
Aúdio, câmeras fotográficas e, na linha de informática, apresenta uma gama de aparelhos
como notebooks, monitores e display, telas grandes (LFD), discos ópticos e impressoras, além
disso, também desenvolve produtos eletrodomésticos como refrigeradores, lavanderia
(máquinas de lavar roupa, lavadora de louças), ar condicionado, além de acessórios para
celular, para TV e suprimentos.
Além desses produtos, a empresa também produz equipamentos de grande porte como,
guindastes para construção civil, navios, carros, e semicondutores, projetados e produzidos no
exterior.
A matriz de fabricação de alguns desses produtos se encontra na cidade de Manaus, na
Amazônia e a linha de produção de celulares e tablets, monitores e impressora está localizada
em uma cidade no interior do estado de São Paulo.
A empresa tem uma diversidade de clientes, mas para o foco desse trabalho citar-se-á os
principais, relacionados ao desenvolvimento de software para celular e, dentre esses, estão as
principais operadoras de telefonia móvel do Brasil, como a Vivo, Claro, Tim, Oi e o mercado
OEM (Original Equipment Manufacturer), além das operadoras internacionais como a AMX
(Claro internacional), Movistar (Telefônica), a Vodafone e outras do mundo todo.
29
O Quadro 5 traz informações sobre os tipos de ferramentas, seus fornecedores e uma
descrição sobre as mesmas.
Quadro 5 – Ferramentas e seus respectivos fornecedores
Tipo Ferramentas Proprietária Descrição
Sof
twar
es
Perforce Perforce Software de versionamento de controle
versão
Microsoft Project Microsoft
Software de administração de projetos para auxiliar administradores de
projetos e desenvolvimento de planos, adminsitração de recursos e tarefas.
GIMP GIMP Software livre para manipulação de
imagens Windows Microsoft Sistema Operacional
Linux Linux Sistema Operacional utilizado nas máquinas de compilação de SW
Skype Microsoft Ferramenta de comunicação entre
todos da empresa
Eclipse Eclipse Software gratuito para
desenvolvimento das aplicações
Android Android Linguagem de programação para mobile (Smart phone e Tablets)
Java Oracle
corporation Linguagem de programação
DDMS (Dalvik Debug Monitor
Serve) Android Ferramenta de debug (depuração)
Source Insight Source Insight Editor de código revolucionário para
linguagens orientada a objeto
Microsoft Office Microsoft Excel, Word e Power Point, Outlook
Har
dwar
es
Desktop DELL Máquinas para compilação dos
softwares
Notebooks Samsung Máquinas portáteis para gerentes e
supervisores Monitores / TVs Samsung Monitores para uso dentro da empresa
Impressoras Samsung Impressoras
Chipset STE Fornecedora de ChipSet
Chipset Infineon Fornecedora de ChipSet
Chipset Qualcom Fornecedora de ChipSet
30
Por meio do Quadro 5 foi possível observar os softwares e hardwares utilizados pela empresa,
o nome dos seus fabricantes e também uma descrição sobre a funcionalidade de cada software
utilizado.
Dentre as principais atividades, nesse ramo de telefonia móvel, está o desenvolvimento de
software embarcado para celular, além de suporte e desenvolvimento de soluções B2B
(business to business) e B2C (business to consumer).
Para a execução das atividades de desenvolvimento de software é necessário que se tenha o
levantamento dos requisitos e das necessidades reais desses clientes para que o produto final
esteja de acordo com as suas expectativas.
3.2 Processo de Desenvolvimento de Software
A Figura 1 ilustra o processo de desenvolvimento de software que é praticado pela empresa,
por intermédio de um fluxograma que mostra passo a passo as atividades de desenvolvimento
de software de uma maneira sequencial.
31
Figura 1 – Fluxograma do Processo de Desenvolvimento dentro da empresa (Adaptado de JUNIOR 2007) A partir do fluxograma apresentado na Figura 1 foi possível observar todas as atividades
executadas pela empresa para a criação do software. Descrição das etapas no processo de
desenvolvimento de software:
Definição dos Requisitos: Essa etapa define a origem no processo de
desenvolvimento do software na empresa. São levantados todos os requisitos junto às
operadoras de telefonia, que determinam quais aplicativos serão embarcados no
software de cada modelo de celular. A equipe de PE (Engenheiros de Produto) é a
responsável por fazer esse elo de comunicação entre a empresa e os clientes e
acompanha e interage essa etapa desde o levantamento dos requisitos até a fase final
de homologação dos terminais junto à ANATEL.
32
Codificação (Customização): Depois do levantamento dos requisitos, parte-se para a
fase de codificação. Essa fase deveria envolver a parte de documentação referente ao
processo de desenvolvimento de software, porém, isso não é realizado. Não existe
documentação sobre como que a customização deverá ser implementada. O
conhecimento é passado dentro do time de forma verbal e prática, e a troca de
conhecimento entre os times do exterior é compartilhado pelas ferramentas de email e
fóruns de discussão global criados pela empresa. Essa prática é adotada pelos times de
desenvolvimento de software no Brasil, isto porque, a prioridade é a liberação do
produto e, com a demanda grande de novos produtos a serem confeccionados e prazos
curtíssimos, nunca há tempo para a criação e documentação dos mesmos.
O software é desenvolvido por vários times espalhados ao redor do mundo, porém, a
versão mais estável é confeccionada pela matriz (Ásia). O time de desenvolvimento é
dividido em outros 3 sub grupos, um responsável pelo software Europeu, outro pela
Ásia e um outro pela América (Sul, Central e Norte). Nessa fase, o software apresenta-
se estável, porém ainda com muitos “bugs” que passam a ser corrigidos durante a fase
de desenvolvimento dos modelos. A partir daí, o código é disponibilizado para todas
as matrizes para que se inicie o desenvolvimento dos modelos para as operadoras de
telefonia.
O código inteiro é disponibilizado via softwares de versionamento de versão,
antigamente era utilizado o ClearCase, que foi substituído pelo Perforce (P4). O
acesso ao código é liberado e então todos os programadores envolvidos naquele
determinado modelo fazem o download da VOB (Versioned Object Base) para a sua
máquina local, e assim passam a trabalhar localmente e integram as correções e
desenvolvimento na VOB para que todos possam ter acesso. Faz parte do processo
manter os arquivos locais sempre atualizados com o código da “main line”. A Figura 2
ilustra como o versionamento global do código está organizado. A versão inicial de
código é desenvolvida para a Europa e quando este estiver estável, um novo branch é
criado, ou seja, é realizada uma cópia inteira do código para o time que vai trabalhar
com o código da Ásia, e desse é criado um outro branch para o código da américa.
33
Figura 2 – Estrutura da VOB (Versioned Object Base) (adaptado de IBM 2012)
Pela Figura 2 é possível deduzir que cada time só poderia trabalhar na sua main line,
ou seja, desenvolvedores do Brasil não têm acesso de escrita no main line da Coréia
ou da Europa. Porém a recíproca não é verdadeira, a equipe de desenvolvimento da
Coréia ou Europa pode integrar correções e novas soluções no branch brasileiro.
Dessa maneira, são necessários merges frequentes para atualizações e correções de
problemas comuns. Esses merges trazem consequências boas como, soluções de
muitos problemas comuns nos terminais, mas também inserção de novos aplicativos, o
que altera a especificação do produto e, nesse caso, um novo processo de atualização
de requisitos tem que ser discutido junto aos clientes. Isso pode trazer consequências
ainda mais graves, como atraso na liberação do software e atraso na produção do
produto, gerando perda significativa de dinheiro.
A fase de codificação envolve a parte de customização, que é a aplicação dos
requisitos da operadora como os aplicativos, as imagens de power on e power off,
ícones dos menus das operadoras, sons específicos, jogos, habilitar features e, por fim,
a confecção de um documento chamado Especificação do Produto, que contém a
descrição de tudo o que foi aplicado no telefone. Esse documento é enviado ao
Engenheiro de Produto para validá-lo com os clientes. Após essa fase, o
desenvolvimento continua com porting de soluções e correções de bugs, mas os
clientes não têm conhecimento dessa fase. As alterações dos requisitos são muito
34
frequentes, ou porque o cliente resolveu alterar alguma coisa no software, ou porque o
levantamento de requisito não ficou claro e até mesmo o cancelamento do
desenvolvimento porque a operadora decidiu, no meio do projeto, que não tem mais
interesse pelo produto. Nota-se que não há um acordo certo entre o time de comercial
e os clientes.
Pré-testes: Esse time foi criado, há pouco tempo, como alternativa de reduzir os bugs
encontrados, durante a fase de desenvolvimento, para antecipar os problemas
encontrados pelo time oficial de teste e pelos clientes. Essa equipe é responsável por
validar as versões de softwares candidatas a serem enviadas aos clientes, então, testa
o documento de Especificação criado na fase anterior, identifica se tudo o que foi
citado no documento foi aplicado no software conforme o que o cliente pediu, além
disso, realiza testes básicos de rede e comunicação de dados, testes do Google, dentre
outros. Esse time é parceiro do time de desenvolvimento de software e tem trazido
excelentes resultados, como antecipação dos problemas que poderiam ser detectados
em fases finais de projetos, o que evita re-trabalho e adianta o processo de aprovação
das versões de software.
Avaliação pelo Cliente: Os representantes das operadoras de telefonia, responsáveis
pelo processo de homologação dos aparelhos celulares, recebem um terminal (celular)
com a última versão de software atualizada, para averiguar se tudo o que foi pedido
está aplicado no telefone. Caso não encontrem nenhuma incoerência, dá-se o aval para
prosseguir com o processo de aprovação e homologação do software final.
Liberação da versão oficial de Software: Nessa etapa, inicia o processo que é
chamado de “release”. É gerada (compilada) uma versão atualizada do código com as
últimas alterações de código (latest), essa versão contém todos os erros do código
corrigidos e validados pelo time de teste.
Realização de testes oficiais pela operadora e time de teste: Com a versão de
software final atualizada, gerada no passo anterior, tanto o cliente (operadoras de
telefonia) quanto o time de teste oficial da empresa (Reliabilty) começam os testes de
validação do software. Nota-se que o time de teste da empresa realiza testes muito
35
mais detalhados do que a operadora (cliente), quase sempre, o impedimento da
produção do produto advém desse time, em vez da operadora. Isso demonstra que a
empresa tem cuidado e está empenhada em produzir softwares com menos problemas
e aumentando a qualidade do seu produto final.
Emissão de Cartas de aprovação: Essas cartas são documentos oficiais
reconhecidos dentro do processo de desenvolvimento e produção do produto.
Certificam que esse software pode ser embarcado no telefone e que passou pelos
processos de certificação e homologação do produto. Sem elas o produto não pode ser
liberado para a produção. São necessárias 2 cartas de aprovação, e ambas precisam
estar aprovadas, uma por parte do cliente e outra por parte do time de teste
(Reliability).
Produção do dispositivo com a versão de software aprovada e homologada: Essa é
a fase que marca o “fim” do desenvolvimento de software. Não se pode dizer “fim”
porque é impossível produzir software com 100% de problemas corrigidos, há quem
diga que softwares que não apresentam erros se tornam obsoletos. Contudo, tem-se
garantia que essa versão está estável e disponível para uso pelos usuários de telefonia
móvel. É muito comum e constante a identificação de problemas no software nas
camadas de mais baixo nível (low layer) e, nesse caso, é necessária a liberação de
uma nova versão de software com os problemas corrigidos, além do processo de testes
e aprovação pelo time de teste (Reliability), porém isso não torna aparente ao cliente
(operadora), visto que os requisitos são mantidos. Essas correções muitas vezes
surgem em fases pós-produção e, nesse caso, muitas pessoas já adquiriram o
dispositivo, por isso, o software é liberado para esses usuários via software
proprietário da empresa, que gerencia e atualiza a versão de software.
3.3 Práticas de Desenvolvimento Colaborativo de Software
As informações descritas nesse tópico foram reunidas a partir de um questionário aplicado a
um dos membros da equipe de desenvolvimento de software colaborativo, responsável pela
customização das operadoras latinas, essa pesquisa foi realizada no primeiro semestre desse
ano. Para tanto, alguns elementos foram utilizados no instrumento de coleta de dados como:
36
Conhecer e definir as fases essenciais que são utilizadas para o desenvolvimento
Colaborativo de software. Isso foi bem descrito e exposto no item anterior pela Figura
1.
Entender como se dá a coordenação das equipes e divisão das tarefas e, conforme
visto, isso é realizado segundo as habilidades e experiências dos integrantes da equipe
de projeto;
Outro elemento importante é saber como é realizada a comunicação, adotou-se
algumas ferramentas como e-mail e fóruns de discussão para compartilhamento de
informação e troca de experiências;
Saber quais os valores praticados pelos desenvolvedores, como simplicidade, coragem,
respeito;
Conseguir identificar quais os métodos (tradicionais, ágeis) são empregados pelo time
de desenvolvimento;
Depois da obtenção das informações, a partir do questionário, algumas práticas de
desenvolvimento colaborativo de software podem ser descritas como:
Levantamento dos Requisitos: Os requisitos são levantados por meio de uma reunião
com o cliente, onde é explicitado verbalmente as suas necessidades e, em seguida, é
gerado um documento de requisitos contendo todas as funcionalidades do sistema;
Codificação: Um documento é gerado com os comentários e código fonte do software
desenvolvido e são emitidas cartas de aprovação para atestar que o produto está pronto
para uso, garantindo dessa maneira, que o produto já passou por todos os pré-testes de
qualidade, tendo grande quantidade de defeitos corrigidos, foi avaliado pelo cliente, a
liberação da versão oficial do software e foram realizados testes oficiais pela
operadora e time de teste;
37
Armazenamento e controle de versões e erros: Mecanismos de armazenamento,
distribuição e acompanhamento dos códigos produzidos e gerados pelos diversos
times de desenvolvimento ao redor do mundo. Essas ferramentas são vistas como uma
extensão natural do processo de desenvolvimento colaborativo, de forma que as
modificações realizadas nos arquivos possam ser rastreadas, garantindo a integridade
do sistema;
Feedback: É obtido um retorno quantitativo do processo, por meio do controle do
processo de desenvolvimento de software com a realização de testes na fase de pré-
testes e também na fase de realização de testes oficiais pela operadora e time de teste,
visando a detecção de erros e a verificação da qualidade do software produzido, a
partir da quantidade de defeitos encontrados;
Revisor de Código: Na etapa de codificação, adotou-se algumas práticas com o intuito
de aumentar a qualidade do software, como o uso de um revisor de código, que tem o
papel de analisar o código que foi implementado, buscando encontrar possíveis erros
que podem gerar complicações em outras partes do código ou até mesmo o mal
funcionamento. O revisor é uma pessoa que geralmente é considerada especialista na
linguagem de programação usada para o código que está sendo revisado. Tem
habilidades de gerenciamento para poder planejar e conduzir as revisões. Na maioria
dos projetos, esse papel é desempenhado por programadores Sênior que fazem parte
da equipe de implementação;
Multi-Compilação: Além da prática de revisão de código, também tem sido adotada
outra técnica de multi-compilação, visando detectar se o código integrado por alguém
vai gerar “quebra de binário (software final)” para o código em outros países. Isso
acontecia com bastante frequência, visto que o mesmo código é utilizado em diversos
outros países, e cada um desses, tem uma implementação de requisito diferente dos
outros, e isso é implementado por meio de diretivas dentro do código. Dessa forma,
quando um programador realizava as suas alterações e compilava o código apenas
para o seu país, o erro não aparecia, mas isso gerava problema de compilação do
mesmo software em outros países. Para diminuir a incidência desses erros, optou-se,
então, pela multi-compilação realizada num servidor, de forma a garantir que a
38
inserção desse código não provocará erros de compilação no software de outros países.
O sistema gera um certificado digital garantindo que o código passou pelo teste e fica
registrado no servidor; e
Testes: Na fase de pré-testes é gerada uma documentação que traz a descrição de todos
os erros encontrados, especificando em que parte do código houve falha. Na etapa de
avaliação pelo cliente realizam-se os testes no software por uma empresa terceirizada
e, se o produto for aprovado pelo cliente, então é elaborada uma carta de aprovação e
em seguida é realizada a compra do produto.
Na liberação da versão oficial de software, o código é compilado e embarcado no celular,
depois são realizados testes oficiais pela operadora e pelo time de teste da própria fabricante
do celular, para a localização dos possíveis defeitos no software, caso seja encontrado algum
erro nos testes da operadora, é gerado um documento especificando quais foram os problemas
encontrados, e então, esses são reportados ao time de desenvolvimento para que sejam
realizadas as devidas correções.
3.4 Análise dos Resultados
Como está descrito na seção 3.2 pode-se observar que não existe a fase de projeto para se
definir a arquitetura do sistema e dividir os componentes que cada equipe deve desenvolver
não existindo nenhuma formalização a partir de um marco que gere uma documentação, ou
seja, a divisão das atividades, que cada equipe vai realizar, é distribuída apenas de uma
maneira informal o que pode gerar conflitos como interpretação equivocada do que deve ser
realizado, resultando em um produto diferente daquele requisitado pelo cliente.
Essa empresa possui características do modelo tradicional e do modelo ágil de
desenvolvimento de software, suas características do desenvolvimento tradicional são o
enfoque de valores nos processos e algoritmos, não existindo um projeto arquitetural já se
iniciando a implementação após a especificação de requisitos, pois a empresa tem que atender
a vários clientes em um determinado prazo, não sobrando tempo para a divisão das atividades,
sendo necessário iniciar a construção do produto de maneira imediata.
39
Existe um aumento da carga de trabalho devido à antecipação do prazo de entrega do produto
por parte do cliente, isso ocorre devido à existência de uma alta concorrência entre as
operadoras, o que acaba exigindo da empresa que o produto seja entregue à operadora o mais
rápido possível.
É gerado um alto custo devido à mudança de planejamento ou dos requisitos especificados
pelo cliente, há sempre uma mudança nos requisitos dos clientes, pois a tecnologia está em
constante mudança e também porque há um alto grau de concorrência entre as empresas que
fazem com que as operados busquem utilizar em seus softwares tecnologias mais recentes e
eficientes o que leva a empresa a se adequar as novas necessidades dos seus clientes mesmo
que ela incorra em custos. Desse modo existe a necessidade de equipes constituídas por uma
grande quantidade de desenvolvedores para que consigam atender as necessidades do cliente
no tempo certo.
Já as características do modelo ágil empregadas nessa empresa são os cumprimentos de
prazos, por meio do aumento de horas extras, já que o cliente exige que o produto seja
entregue sempre antes do prazo combinado para que a operadora possa estar à frente da sua
concorrente, os padrões de qualidade são alcançados com sucesso, a partir dos vários testes
que são realizados na fase de pré-testes.
A empresa acaba se desdobrando para atingir os prazos, os padrões de qualidades são
alcançados com a equipe de teste verificando todas as funcionalidades do software, não
emprega a análise de risco, se preocupando mais com a implementação do que com o controle
de qualidade do processo, é possível a visualização parcial do software enquanto é
desenvolvido, com a apresentação de vários protótipos e casos de testes ao cliente para que
seja possível a captação de todas as suas necessidades, tanto explícitas quanto implícitas.
Possui características adaptativas, mudando as funcionalidades do software à medida que
mudam as necessidades do cliente já que surgem tecnologias mais recentes e linguagens de
programação mais eficientes, é gasto menos tempo com documentação e maior tempo com
implementação, já que o cliente precisa que o produto seja entregue o mais breve possível.
A empresa analisada possui os seguintes fatores-chaves do CMMI: trabalha com eliminação
de inconsistências e redução de duplicidades relacionadas aos requisitos, a partir de casos de
testes e protótipos que são apresentados ao cliente, modelo estruturado com resultados
40
esperados e modelo estruturado em áreas de processos, processo de gerência de reutilização e
desenvolvimento para reutilização, a empresa trabalha com o reuso de módulos e
componentes reduzindo assim a quantidade de erros já que esses módulos já foram testados
quando foram utilizados pela primeira vez, diminuindo o tempo de programação, pois o
módulo já está finalizado, apenas adequando-o para a necessidade do novo software que será
criado.
3.5 Proposta de Melhoria
De acordo com Leonel (2008), para qualquer proposta de melhoria a ser citada, utilizar-se-á a
base fundamental do conceito de melhoria contínua que é proposto por Deming, o PDCA
(Plan, Do, Check, Act). Uma de suas aplicações é na análise e na solução de problemas,
permitindo a realização do controle da qualidade em qualquer setor de uma empresa. É
preciso que esse método gerencial seja conhecido pelos membros da organização, já que
promove o tratamento adequando problemas, padronização da melhoria contínua e o
desenvolvimento de oportunidades.
Leonel (2008) ressalta que o ciclo do PDCA é composto por algumas fases:
Planejamento (Plan): o estabelecimento de metas e identificação do problema. No
estudo em questão as metas representam os requisitos do cliente, nessa etapa os dados
são relacionados ao problema, para que se possa descobrir as causas fundamentais dos
problemas gerados e então elaborar um plano de ação;
Execução (Do): Nessa fase deve-se executar as atividades conforme o plano de ação
definido na fase de planejamento. Durante essa fase, deve-se coletar os dados e as
informações que serão utilizados na próxima fase de verificação;
Verificação (Check): Esta fase corresponde às atividades de verificação e constatação
de que o que foi planejado foi de fato executado, e nesse caso algumas ferramentas de
controle foram utilizadas como cartas de controle (Homologação), relatórios de testes,
cadernos de testes da operadora, e
41
Agir corretivamente (Act): Nessa etapa, duas situações podem ser esperadas: caso as
metas não tenham sido alcançadas (ou foram deficientes), faz-se necessário buscar as
causas das inconsistências e agir de forma a prevenir a repetição dos defeitos
indesejados e, caso as metas tenham sido alcançadas, deve-se adotar como padrão as
metas definidas na fase de planejamento.
Por ser uma empresa de grande porte, com filiais em inúmeros países diferentes, é uma
empresa que possui condições financeiras para implantar o modelo de melhoria CMMI ideal
para grandes empresas. Outro modelo que pode ser implantado é o RUP por orientar o
desenvolvimento de software durante todas as etapas de desenvolvimento.
Foi escolhido o CMMI por ser um modelo de melhoria que vai ao encontro das necessidades
das empresas de grande porte que podem arcar com seus custos de implantação e obter o
credenciamento internacional, além disso, possui um modelo de melhoria voltado para as
áreas de processos para a efetivação de metas específicas visando atender às necessidades da
área de processo, define práticas específicas a serem executadas para o alcance das metas,
metas genéricas que buscam melhoria em várias áreas de processos e praticas genéricas que
proporcionam a manutenção da eficiência e eficácia de todas as áreas de processo levando a
empresa a procurar soluções e efetivar a melhoria contínua em todas as suas áreas.
O CMMI auxilia a empresa a praticar a melhoria contínua por meio de níveis de capacidade
que vão desde o nível incompleto aonde há uma ausência de objetivos genéricos e o processo
não é controlado de forma quantitativa e nem qualitativa, possibilitando que a empresa possa
ir alcançando níveis de capacidade que vão gradualmente melhorando a qualidade do
processo de desenvolvimento de software até chegar a um nível em que o processo possa ser
controlado e medido de forma quantitativa com base em dados e técnicas estatísticas.
Esse modelo de melhoria contínua CMMI trabalha também com níveis de maturidade que da
mesma forma que o nível de capacidade, vai desde o nível inicial onde os processos são
imprevisíveis, pouco controlados, com ausência de planejamento e acompanhamento de
projeto até o último nível otimizado em que o foco está na melhoria contínua dos processos,
permitindo dessa maneira que a organização possa, de forma gradual, ir alcançando níveis de
maturidade de desenvolvimento de software que lhe proporcionem uma melhor eficiência e
seja gerada uma melhor qualidade do produto final.
42
Com a adoção do modelo CMMI a empresa terá um reconhecimento internacional, pois esse
modelo possibilita o credenciamento da empresa que passa a ter uma credibilidade maior por
parte dos seus clientes, gerando a garantia da qualidade a partir do controle de qualidade de
todo o processo de desenvolvimento de software e da implantação da melhoria contínua
fazendo com que os processos estejam em conformidade com os planos, procedimentos e
padrões estabelecidos, possibilita uma maior eliminação de inconsistências e redução de
duplicidade relacionada aos requisitos e permite a melhoria em todas as áreas de processos
por ser um modelo estruturado em áreas de processos.
Foi escolhido o RUP para ser implantado nessa empresa porque é dividido em quatro fases
que guiam o desenvolvimento de software as quais são: iniciação, elaboração, construção e
transição e, por pregar princípios centrais para aumentar a qualidade no processo de
desenvolvimento de software os quais são dirigidos por casos de uso, centrado na arquitetura
do sistema e iterativo e incremental, e pelo fato da empresa analisada não trabalhar com a
linguagem UML sem a utilização de diagramas de casos de usos que mostram as
funcionalidades do sistema e possibilitam a verificação do funcionamento das mesmas na
hora da realização de testes.
3.5.1 Método de implantação
Inicialmente, será criado um grupo dentro da empresa, com algumas pessoas envolvidas nas
etapas do projeto, com o intuito de organizar as informações, estudar as normas e como
podem vir a ser aplicadas dentro da empresa. Será necessário empenho e contribuição de
todos para que se possa montar um plano de ação. Além disso, será necessário o
acompanhamento de um consultor, para que se possa acompanhar o processo de implantação
e, nesse caso, poderia ser sugerida a empresa ASR Consultoria e Assessoria em Qualidade,
que é uma empresa especializada em consultoria e treinamento em melhoria de processos
organizacionais, possui três unidades no estado de São Paulo, e que tem desempenhado
excelente trabalho em busca da melhoria contínua dos processos, através de uma abordagem
prática, utilizando padrões e modelos reconhecidos internacionalmente, como o CMMI,
MPS.BR, ISO9000, entre outras.
Com relação às documentações, deve-se definir quem as elaborará, pois podem ser
confeccionadas pela empresa de consultoria ou pelo grupo que foi separado dentro da
43
empresa. Essa decisão vai depender das pessoas envolvidas e dos custos que serão
despendidos.
Dessa maneira, é necessário conhecer a estrutura organizacional da empresa, pois uma das
metas de um projeto de implantação para melhoria de processos de software é conhecer
detalhadamente essa estrutura, facilitando posteriormente, o reconhecimento das partes
interessadas do projeto e a delimitação do escopo do problema.
A empresa em questão conta com 96 colaboradores ligados diretamente em atividades de
desenvolvimento de software colaborativo e podem ser identificados de acordo com às suas
funções:
2 gerentes Sêniors (1 do time de teste e outro do time de desenvolvimento);
5 gerentes (1 do time de teste e 4 do time de desenvolvimento);
4 coordenadores (desenvolvedores Sêniors);
52 (Analistas-desenvolvedores);
33 (Testadores dentre eles engenheiros e técnicos);
A empresa também possui outros setores comuns como a administração interna, como o setor
de Recursos Humano, financeiro, comercial e jurídico, bem como a Superintendente e suas
assessorias. Estes setores não farão parte do escopo da aplicação do projeto para implantação
da melhoria proposta por este trabalho, mas contém partes interessadas (stakeholders) que
poderão intervir sobre o projeto. Será necessário o patrocínio, por parte da Superintendente da
empresa, para a execução do projeto, e que consequentemente, desejará obter um feedback
positivo dos resultados.
Seria necessária uma análise quantitativa da carga de trabalho realizada por esse grupo num
período determinado de tempo, por sugestão três meses. Para, dessa forma, poder mensurar a
quantidade de desenvolvedores alocados para o desenvolvimento e manutenção do software.
Verificar se o acúmulo de papéis interfere na produtividade e na qualidade do produto final.
Primeiramente neste trabalho é sugerida a implantação de marcos, ou seja, para cada etapa do
desenvolvimento de software será gerada uma documentação para que se possa ter um
44
controle maior sobre o que está sendo realizado, por quem está sendo implantado, eliminando
dessa forma, o retrabalho e possibilitando maior controle de erros.
Será implantado o CMMI começando pelas áreas de processos e metas específicas subindo
gradativamente de nível até chegar ao ponto do alcance de metas genéricas e objetivos
genéricos. De forma resumida, pode-se sugerir as seguintes linhas de orientação:
Diagnóstico inicial dos processos já estabelecidos na empresa em questão se houver,
sendo efetuada uma análise de gap, identificando-se: o alinhamento dos processos
com os objetivos e práticas associados ao nível um do modelo CMMI; pontos fortes e
oportunidades de melhoria dos processos em análise; obtenção do perfil do processo
em análise;
Estabelecimento de um plano de melhorias por processo, onde, a partir dos objetivos e
práticas (do modelo CMMI) não satisfeitos, parcialmente satisfeitos, ou mesmo
satisfeitos com oportunidades de melhoria, serão propostas sugestões de alteração aos
processos;
Análise e aprovação do relatório de diagnóstico e plano de melhorias por parte do
responsável do processo na empresa;
Desenvolvimento dos processos na empresa, associados às áreas de processo em
análise do modelo CMMI;
Aprovação do processo por parte do responsável do processo na empresa;
Estabelecimento de auditorias aos processos (permitindo identificar possíveis lacunas
com os níveis do modelo CMMI);
Implementação de ações corretivas e preventivas identificadas nas auditorias
realizadas aos processos e respectiva aprovação por parte do responsável do processo
na empresa em questão;
45
Estabelecimento de workshops junto de stakeholders (partes interessadas - pessoas que
estão ativamente envolvidas no projeto), de forma a identificar potenciais melhorias
aos processos e fomentar a gestão da mudança;
Implementar os processos em projetos piloto;
Institucionalizar os processos na empresa analisada nessa pesquisa.
O RUP será implementado com caráter de urgência para possibilitar uma análise melhor de
requisitos, além de melhoria na modelagem do sistema, com a utilização de projetos
arquiteturais modularizando o sistema, sendo realizado o acoplamento, a adoção de diagramas
que gerem uma melhor visualização das funcionalidades do sistema, mostrando as
comunicações realizadas entre os módulos, esses diagramas são os diagramas de pacote, casos
de uso, comunicação, sequencia, classes.
3.5.2 Provavéis procedimentos
Os processos das fases de iniciação e planejamento para o projeto de implantação serão
baseados nas práticas recomendadas do Guia PMBOK (PMBOK, 2008). A contextualização
dessas práticas em um estudo de caso facilita o seu entendimento prático e, por este simples
motivo, esses processos serão caracterizados pela adoção de práticas com um alto nível de
controle. Um processo controlado tem a característica de parecer enrijecer a execução das
atividades. Contudo, estes procedimentos serão necessários para obter um conhecimento mais
aprofundado das técnicas e ferramentas que estão descritos no Guia (AMARAL, 2010).
Para a fase de iniciação, as seguintes entradas e saídas seriam elaboradas:
1. Termo de abertura de projeto;
2. Declaração de trabalho do projeto;
3. Caso de negócio;
4. Organização dos fatores ambientais da empresa;
5. Organização de alguns ativos de processos organizacionais;
6. Registro das partes interessadas.
Para a fase de planejamento, as seguintes entradas e saídas poderiam ser elaboradas:
1. Plano de gerenciamento de projeto;
46
2. Planilha de acompanhamento de projeto;
3. Plano de gerenciamento de requisitos;
4. Requisitos de projeto;
5. Aceitação de requisitos;
6. Matrizes de rastreabilidade;
7. Declaração de escopo do projeto;
8. Estrutura analítica do projeto (WBS);
9. Cronograma do projeto;
10. Linha de base de desempenho dos custos;
11. Plano de qualidade e métricas de qualidade;
12. Plano de recursos humanos;
13. Plano de gerenciamento dos riscos;
14. Planilha de riscos.
Os procedimentos a serem seguidos são a utilização de documentação em cada etapa do
desenvolvimento de software por parte das equipes, a utilização da UML (Linguagem
Unificada de Modelagem) que possibilita maior análise dos requisitos e funcionalidades do
sistema, possibilitando também a descrição da arquitetura do sistema por meio de diagrama de
pacotes, classes, objetos, comunicação, sequência, casos de uso, a linguagem UML está
presente no RUP, facilitando dessa maneira, a realização de testes por meio da utilização do
diagrama de caso de uso.
O CMMI será implantado primeiramente em cada área de processo começando pelos
Engenheiros de Requisitos com foco no aumento da confiabilidade de que os requisitos
registrados por meio de entrevistas com o cliente serão compreendidos e passados para a
equipe de codificação com um grau de acuracidade o maior possível para isso também serão
utilizados os diagramas da UML que estão presentes no RUP para uma melhor visualização
das funcionalidades requeridas pelo cliente e também para que seja possível efetivar a
validação dos requisitos com o cliente.
Em seguida o CMMI será implantado na etapa de Codificação gerando melhorias e garantindo
a qualidade do processo de desenvolvimento de software com enfoque em uma maior
documentação do código fonte gerado nessa etapa, verificação maior de erros, efetivação da
melhoria contínua pela modularização, acoplamento e reutilização de código.
47
Após isso, o CMMI será implantado na etapa de pré-testes como esse modelo já foi aplicado
na etapa de codificação, espera-se assim, encontrar menos erros no momento de realização de
testes dos que eram encontrados com método desorganizado e disfuncional utilizado pela
empresa, sendo utilizada a padronização de testes para aplicativos semelhantes facilitando a
procura de erros e a sua eliminação.
Na avaliação de software realizada pelos clientes será utilizado o modelo de Prototipação que
já é utilizado pela empresa, mas com o auxílio dos diagramas da UML já citados
anteriormente serão capturados os requisitos que o cliente achar que faltaram ou que foram
mal compreendidos, com isso levando a construção do software o mais próximo possível do
que o cliente deseja.
48
4 CONCLUSÕES
4.1 Resultados Esperados com as Práticas de Melhoria Contínua no Processo de Desenvolvimento Colaborativo de Software
Com o que foi apresentado nesse trabalho, é possível apresentar o quadro 6 com o processo
que a empresa vem utilizando e os resultados que se espera alcançar com as práticas de
melhoria contínua.
Quadro 6 – Resultados esperados com o uso das práticas de melhoria continua
(continua)
Descrição Cenário atual Resultado esperado com a implantação
do CMMI
Coordenação
A coordenação das equipes não tem sido eficiente. A distribuição das atividades não tem sido eficaz e tem gerado carga de trabalho desigual entre os desenvolvedores.
Com a implantação do CMMI a distribuição das atividades será realizada de maneira uniforme entre os colaboradores, ou seja, dividindo a carga de trabalho de maneira igual, pois a alocação de recursos é feita de maneira mais eficaz e eficiente.
Comunicação
A comunicação não tem sido eficiente e isso tem gerado redundância de esforços e soluções duplicadas.
O CMMI tem foco em tornar a comunicação clara e concisa, evitando trabalhos e esforços redundantes. Dessa forma, espera‐se que isso venha ser reduzido, e o trabalho possa ser canalizado para a resolução de problemas diferentes.
Quantificar o custo do projeto
Atualmente a empresa estudada não estima o quanto cada projeto custará. Isso porque a empresa assume o risco e compromisso de entregar o projeto em uma data estimada.
O CMMI permitirá estimar, de forma mais precisa, o custo que será gasto em cada fase do projeto, considerando os recursos empregados, e poderá ter visibilidade se será necessário gastos extras com treinamento da equipe, ou compra de equipamentos.
Cultura Organizacional
Nota‐se que a empresa estudada está de certa forma acomodada seguindo a mesma rotina de trabalho, e dessa forma, apresenta‐se resistente às mudanças.
O CMMI propõe metodologias de como lidar com essa questão, através de ferramentas como softwares, desenvolvimento de código e testes.
49
Quadro 6 – Resultados esperados com o uso das práticas de melhoria continua
(conclusão)
Descrição Cenário atual Resultado esperado com a implantação
do CMMI
Dependência de Pessoas chaves
Como a empresa não tem um processo de execução das atividades bem definido, a produção de documentação é quase nula. Isso faz com que o conhecimento se acumele em determinadas pessoas, que se tornam chaves no projeto. Isso é crítico visto que se essa pessoa deixar a empresa o conhecimento é levado com ela.
A documentação dos processos é definida como parte dos requisitos da implantação do CMMI, isso reduz o impacto da dependência de pessoas chave nos projetos e compartilha conhecimento entre as equipes de maneira uniforme e eficaz.
Senso de prioridade e
organização de metas
O senso de prioridade é definido pela matriz sem organização de metas. Nota‐se que tudo é prioritário, e determinam a execução de projetos com prazos curtíssimos.
Espera‐se, com a implantação do CMMI, estabelecer o senso de prioridades e metas entre todos os projetos que estão sendo desenvolvidos paralelamente. Criar planilhas que contemplem as atividades, os recursos a serem alocados, e prazos de entrega.
4.2 Considerações Finais
O presente trabalho buscou identificar e conhecer os problemas que mais afetam no processo
de desenvolvimento colaborativo de software e, dentre eles, redundância de esforços devido a
pouca coordenação nos projetos, e os grupos nos demais países acabam desenvolvendo tarefas
similares em paralelo sem conhecer o trabalho dos seus pares, gerando-se um consumo
adicional de recursos. Outro desafio identificado foi a comunicação, que embora o inglês seja
o principal idioma usado nos projetos, sabe-se que não é o idioma nativo de todos os
participantes, isso tem gerado diversos problemas de entendimento, que tendem a piorar
conforme os projetos aumentam de número de participantes ao redor do mundo.
Além disso, foi observada a dependência de pessoas chave no processo de desenvolvimento
colaborativo, e a explicação mais plausível, é que o nível de conhecimento necessário para se
analisar e entender um código-fonte de um sistema requer treinamento e experiência, e notou-
se que o esforço em adquirir esse conhecimento não é efetuado pela maioria dos
desenvolvedores. Essa dependência pode-se tornar um risco, caso a pessoa chave não possa
continuar o seu trabalho no projeto por algum motivo.
50
Nesse estudo foram propostas práticas de melhoria contínua, visando promover o desempenho
no processo de desenvolvimento colaborativo de Software, conforme foi descrito e analisado,
optou-se por implantar o CMMI, em um pequeno grupo, como teste piloto e depois implantá-
lo para os demais times de desenvolvimento de software.
Deste modo, levando-se em consideração os modelos de desenvolvimento de software aqui
apresentados (tradicional, ágil e desenvolvimento de software livre), pode-se observar que os
modelos de melhoria contínua como o CMMI que permitem um controle e avaliação do
processo de desenvolvimento de software só vem a trazer melhoria na qualidade do produto
final, reduzindo custos, possibilitando a empresa ir melhorando a qualidade de uma forma
contínua e gradativa por meio de níveis de maturidade e de capacidade, possibilitando que aos
poucos a empresa possa ir melhorando o processo de desenvolvimento de software, mesmo
que esse se encontre desorganizado.
Foram apresentadas várias metodologias que guiam o desenvolvimento de software e
analisadas suas características, foram descritas a comparação entre o desenvolvimento ágil e o
desenvolvimento tradicional relacionando suas vantagens e desvantagens, sendo que não
existe um modelo de desenvolvimento de software considerado melhor já que a escolha do
modelo de desenvolvimento de software está relacionada com as atividades e necessidades da
empresa que o utiliza.
Na empresa analisada foi observada a presença de características do modelo tradicional (como
por exemplo: o enfoque principal é no processo, apresenta um aumento do número de carga
de trabalho e o tamanho das equipes é grande) e também do modelo ágil como: menos tempo
é gasto com processo de documentação, é possível acompanhar e ver os resultados parciais do
software final; esses dois modelos foram combinados para que se adequassem ao processo de
desenvolvimento de software seguido pela empresa, foi proposta a utilização do RUP para
guiar o processo de desenvolvimento de software, pois esse paradigma possui um conjunto de
princípios centrais tais como dirigidos por casos de uso, centrado na arquitetura do sistema,
iterativo incremental e focado em risco que podem ser aplicados em todas as etapas do
desenvolvimento de software.
Outro modelo recomendado à empresa é o CMMI por proporcionar o controle e mensuração
da qualidade do processo de desenvolvimento de software e também por proporcionar a
51
melhoria contínua por meio de níveis de capacidade e maturidade, sendo que a empresa pode
implantar o CMMI mesmo que o processo não seja monitorado e controlado, podendo iniciar
sua implantação com o nível incompleto até chegar ao nível otimizado, garantindo dessa
maneira, um controle eficiente do processo de desenvolvimento de software e a aplicação
total do conceito de melhoria contínua.
4.3 Limitações da Pesquisa
Por ser uma empresa situada em Campinas, devido à distância, foi difícil conseguir
informações e conhecer o processo de desenvolvimento de software de uma forma detalhada.
Para resolver esse problema, criou-se um questionário para a captação das informações que
foi enviado via e-mail para um responsável da área. O questionário foi respondido apenas por
um dos integrantes da equipe de desenvolvimento.
Outra limitação encontrada na pesquisa foi a falta da disponibilidade dos colaboradores da
empresa em participar do questionário, pois das 16 pessoas convidadas apenas 1 se predispôs
a responder as perguntas. Pode-se deduzir que essa dificuldade pode ter ocorrido pelo fato
desta pesquisa ser de caráter acadêmico e, dessa forma, poderia não interessar à empresa
dispender o tempo dos seus colaboradores para atender ao pesquisador em questão.
Outro ponto que pode ser citado como limitador da pesquisa é a confidencialidade da
informação, que é uma das normas da empresa, pois os mesmos temem que suas ideias e
protótipos recentes e inovadores possam ser usados de forma equivocada e até mesmo serem
copiados por concorrentes. Desse modo não foi possível conseguir um agendamento para
poder participar das atividades de desenvolvimento num período de uma semana, para que
pudesse entender de forma prática como ele é desenvolvido.
4.4 Atividades Futuras
Um trabalho futuro, dando continuidade ao que foi apresentado aqui, poderá abordar as
mudanças na empresa a médio/longo prazo. Pode-se ressaltar algumas atividades como:
A elaboração de um estudo em que este processo de mudança inerente à
implementação do modelo de maturidade esteja já mais interiorizado pelas pessoas,
bem definido e com aceite dentro da organização e com um certo nível de maturidade
dos seus processos/atividades, permitirá obter resultados concretos a nível de ganhos e
52
perdas, podendo ser possível verificar se os principais problemas que os projetos de
desenvolvimento apresentam, como ao estouro de orçamentos e de calendário, a falta
de normalização nos processos, o pouco controle das atividades, serão minimizados ou
até mesmo extinguidos;
Tal como foi realizado já em outros estudos em empresas de grande dimensão como o
caso da Boeing, Siemens, o cálculo de qual foi o ganho em termos de redução de
defeitos na produção poderá ser calculado, se os custos diminuíram, se os prazos e
orçamentos passaram a ser cumpridos ou se a sua margem de erro diminuiu;
Identificar qualitativa e quantitativamente as mudanças que a implementação de um
modelo de maturidade de processos trouxe à organização e poder fazer comparações
com outras organizações certificadas em CMMI e com valores médios fornecidos pela
entidade responsável pela criação do CMMI, o SEI, permitindo assim averiguar qual a
taxa de sucesso presente na empresa.
Realizar uma apresentação com a alta gerência mostrando os resultados alcançados de
forma obter o respaldo e apoio para a continuidade da proposta;
Priorizar a documentação dos procedimentos mais importantes, para evitar perda de
informação, caso alguma pessoa chave deixe o time;
Reforçar a importância do compartilhamento das informações por meio do uso de
ferramentas como wikipedia, e-mail, fóruns;
53
REFERÊNCIAS
ALVES, N. M. M.; WILLIAN S. C.; ALEXANDRE C.; EDGAR A. L. J. Um estudo de caso industrial sobre integração de práticas ágeis no RUP, Revista Ciência e Tecnologia, Uberlândia, p. 1 – 11, jan. 2011. AMARAL, M. A. I. UMA PROPOSTA DE PROJETO PARA IMPLANTAÇÃO DO CMMI-DEV NÍVEL 2 DE MATURIDADE CONFORME O GUIA PMBOK. 175 f. Monografia (Curso de Especialização em Gerenciamento de Projetos) – Faculdade de Tecnologia de João Pessoa, Paraíba, 2010. ANACLETO, Alessandra. Método e Modelo de Avaliação para Melhoria de Processos de Software em Micro e Pequenas Empresas. 190 f. Tese (Mestrado em Ciência da Computação) - Universidade Federal de Santa Catarina, Florianópolis - Santa Catarina, 2004. ANDERSON, Cristiano. Desenvolvimento Colaborativo: Vantagens sobre o método de programação descentralizado e colaborativo, que mantém os projetos de software livre. 2009. Disponível em http://www.superdownloads.com.br/materias/desenvolvimento-colaborativo.html#ixzz1uIXts4Nl. Acesso em 05 de abril de 2012. ATKINSON, C. et al. Component-based Product-line Engineering with UML. 1st edition Canada: Addison-wesley, 2001. 528 p. ISBN-10: 0201737914. BARTHELMESS, P. Collaboration and coordination in process-centered software development environments: a review of the literature. 2003. 40 f. University of Colorado at Boulder. BASSI FILHO, D. L. Experiências com desenvolvimento ágil. 2008. 170f. Dissertação (Mestrado em Ciências) – Instituto de Matemática e Estatística da Universidade de São Paulo, São Paulo, 2008. Disponível em: <http://www.teses.usp.br/teses/disponiveis/45/45134/tde- 06072008-203515/publico/Dissertacao_Metodos_Ageis_Dairton_Bassi.pdf>. Acesso em 03 Junho de 2012. BECK, K. Extreme Programming Explained: Embrace Change, AddisonWesley, 1999, 190p. ISBN: 0321278658. BECK, K. et al. Manifesto for Agile Software Development. 2001. Disponível em <http://agilemanifesto.org/>. Acessado em 16 de maio de 2012. BUENO, C. R. Rocha; BUENO, R. S. A. Rodrigues; BORBA, P. S. Metodologias Ágeis – Extreme Programming e o Tratamento de Requisitos. PIC – Programa de iniciação científica. Revista Contexto, São Paulo, 2008. CASEY, V. Virtual Software Team Project Manegement. Journal of the Brazilian Computer Society. V. 16, n. 2, p. 83 – 96, maio, 2010, ISSN 0104-6500. CASTRO, R. de O. et al. CMMI e scampi: uma visão geral dos modelos de qualidade e de um método formal para sua avaliação. Revista de Ciências Exatas e Tecnologia, v. 1, n. 1, p. 22 – 31, 2006.
54
CHESSMAN J.; DANIELS J.; UML Components: a Simple Process for Specifying Component-Based Software. 1st edition, Canadá: Addison-Wesley, 2001, 208p. ISBN-10: 0201708515. COOK, C. Modelling and measuring Collaborative Software Engineering, 2005, Australia, Proceedings of the Twenty-eighth Australasian conference on Computer Science - Volume 38, p. 267 - 276. D'SOUZA, D., WILLS, A. C., Objects Components and Frameworks with UML: the Catalysis Approach, 1998, Addison-Wesley. GEVAERD, Guilherme de Sá, Uma Ferramenta de Avaliação de Maturidade de Processo de Software Baseado no CMMI e MPS.BR. 2009, Curso de Ciência da Computação, Trabalho de Conclusão de Curso, Universidade do Estado de Santa Catarina (UDESC), Joinville. GUIA GERAL, MPS.BR - Melhoria de Processo do Software Brasileiro, julho de 2011, Softex. Disponível em http://www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2011.pdf, acesso dia 16 de maio de 2012. HUYEN, P.T.T; OCHIMIZU, K. Toward Inconsistency Awareness in Collaborative Software Development, 2011. In: 18th Asia-Pacific Software Engineering Conference, IEEE, Ho Chi Minh, Vietnam. IBM: About VOBs, 2012, disponível em http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/index.jsp?topic=/com.ibm.rational.clearcase.hlp.doc/cc_main/about_vob.htm, acessado no dia 14 de outubro de 2012. JUNIOR, D. S. Implementação de Processo de Software para Teste de Aeroespaciais. 2007. 190f. Dissertação (Mestrado em Engenharia Elétrica) – Instituto de Engenharia Elétrica da Universidade de São Paulo, São Carlos, 2007. JUNIOR, C. H., YANZER, A. Aplicação De Métodos Ágeis em um Processo de Desenvolvimento de Software. Universidade Luterana do Brasil (Ulbra). 2011 KIVAL et al. Modelo de referência e método de avaliação para melhoria de processo de software – versão 1.0 (MR-MPS) e (MA-MPS), 2005, Rio de Janeiro, Universidade Federal do Rio de Janeiro (UFRJ), IV Simpósio Brasileiro de Qualidade de Software. KOSMINSKY, Décio. Requisitos de Ferramentas para Apoio ao Fluxo Colaborativo de Requisitos, 2007, Belo Horizonte – Minas Gerais, Universidade Federal de Minas Gerais (UFMG). KRUCHTEN, P., The Rational Unified Process: an Introduction. 2 ed. 2000, AddisonWesley. LEAL, G. C. L. UMA ABORDAGEM INTEGRADA DE DESENVOLVIMENTO E TESTE DE SOFTWARE PARA EQUIPES DISTRIBUÍDAS. 193 f. Dissertação
55
(Mestrado em Ciência da Computação) - Universidade Estadual de Maringá, Maringá - Paraná, 2010. LEONEL, P.H. Aplicação Prática da Técnica do PDCA e das Ferramentas da Qualidade no Gerenciamento de Processos Industriais para Melhoria e Manutenção de Resultados. Dissertaçao (Mestrado).75p. Universidade Federal de Juiz de Fora, MG. 2008 LIMA, A. M.; REIS, R. Q.. Compartilhamento de Informações sobre Processos em Ambientes Descentralizados de Desenvolvimento de Software. In: II WORKSHOP DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE - WDDS, 2007, Pará. p. 71 - 80. MADHAVJI, N. H., Environment Evolution: The Prism Model of Changes, 1992, Transactions on Software Engineering, v.18, n.5 (April), p. 380-392. MAGDALENO, Andrea Magalhães. Apoio a decisão para o balanceamento de colaboração e disciplina nos processos de desenvolvimento de software, julho de 2010, Rio de Janeiro, Exame de qualificação, p. 18 – 20. MALHEIROS, Viviane. Uma contribuição para a melhoria colaborativa e distribuída de processos de software. 2010. 222 f. Tese (Doutorado) – Curso de Ciências de Computação e Matemática Computacional, Universidade de São Paulo (USP), São Carlos. MANGAN, M.A.S., Aspectos de Implementação de um Modelo para Gerência do Processo de Desenvolvimento de Software: Arquitetura e Protocolos para um Gerente de DesignFlow, 1998, CPGCC/UFRGS, Dissertação de Mestrado, 104 p. MARTINAZZO, A. A. G., Considerações sobre desenvolvimento colaborativo de software para aprendizagem em plataformas móveis, 2011, SP – São Paulo, Escola Politécnica USP – Universidade de São Paulo, Dissertação de Mestrado. NAYAK, M.K.; SUESAOWALUK, P., Risk factors that affect collaborative software development, 2008 In: Management of Innovation and Technology, ICMIT. 4th IEEE International Conference on, September. NERUR, S.; Mahapatra, R.; Mangalaraj, G. Challenges of migrating to agile methodologies, 2005 Communications of ACM, v. 48, issue 5, p. 72-78. NETO, O. N. S; Análise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e Ágeis. Trabalho de conclusão de curso. Univsersidade da Amazônia. 2004. NIAZI, M.; WILSON, D.; ZOWGHI , D. A maturity model for the implementation of softwareprocessimprovement: an empirical study. Journal of Systems and Software. V. 74, issue 2, p. 155-172. 2005. OLIVEIRA, Camila da Silva. Comparando CMMI x MPS.BR: As Vantagens e Desvantagens dos Modelos de Qualidade no Brasil, 2008.
56
PINTO, M. A. P. Gestão de Projectos com Processos Ágeis. 2010. 83 f. Dissertação (Mestrado em Engenharia de Informática e Computadores) - Universidade Técnica de Lisboa, Portugal - Lisboa, 2010. PISKE, O. R. RUP – RATIONAL UNIFIED PROCESS, Mafra – Santa Catarina, Universidade do Contestado – UNC, 2003. PMBOK Guia 2008. Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. PMI. 4ª edição. 2008. REIS, Christian Robottom. Caracterização de um Processo de Software para Projetos de Software Livre, fevereiro de 2003, São Carlos – SP, Dissertação de mestrado. REICH, The Work of Nations, Vintage, 1992, 352 p. RISING, L., JANOFF, N. S., , The Scrum Software Development Process for Small Teams, 2000 IEEE Software, v.17, n.4 (July), p. 11-13. ROCHA, A. R., et al. Joint CMMI Level 3 and MPS Level C Appraisal: Lessons Learned and Recommendations, 2009 Disponível em http://www.softex.br/portal/softexweb/uploadDocuments/mpsbr2009_Li%C3%A7%C3%B5es%20Aprendidas%20Avalia%C3%A7%C3%A3oo_CMMI-MPS-100404(2).pdf), acessado em 13 de maio de 2012. ROCHA, A. R., et al. Fatores de Sucesso e Dificuldades na Implementação de Processos de Software Utilizando o MR-MPS e o CMMI, 2005, Rio de Janeiro, COPPE/UFRJ – Universidade Federal do Rio de Janeiro. RODRIGUES, J. F.; KIRNER, T. G. Benefícios, Fatores de Sucesso e Dificuldades da Implantação do Modelo MPS.BR, 2010, IX Simpósio Brasileiro de Qualidade de Software. RODRIGUES, J. F. Avaliação da Implantação do Mps.Br: Um Estudo Empírico sobre Benefícios, Dificuldades e Fatores de Sucesso. 2009. 191 f. Mestrado (Mestre) - Universidade Metodista de Piracicaba, Piracicaba, SP, 2009. SÁVIO, M. Aspectos do Trabalho Cooperativo no Desenvolvimento de Software Livre, 2007. Rio de Janeiro. Disponível em (http://pt.scribd.com/doc/13322092/Aspectos-do-Trabalho-Cooperativo-no-Desenvolvimento-de-Software-Livre), acesso em 06 de abril de 2012. SCHUMMER, T. Lost and Found in Software Space, 2001 In: Proc. of the 34th Annual Hawaii International Conference on System Sciences, IEEE, Maui, Hawaii. SGANDERLA, M. A., LACERDA, G. S. Melhorando a gerência e a construção de software com metodologias ágeis. Centro Universitário Ritter dos Reis (UNIRITTER), Porto Alegre – RS, 2010. SILVA, E. L., MENEZES, E. M. Metodologia de Pesquisa e Elaboração da Dissertação. Florianópolis. 4a edição revisada e atualizada. Universidade Federal de Santa Catarina – UFSC. 2005.
57
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, 2004, Conselheiro Lafaiete – Minas Gerais, Universidade Presidente Antônio Carlos (UNIPAC). SOFTEX: Autora do MPS-BR, 2012, disponível em http://www.softex.br, acessado no dia 18 de maio de 2012. STANDISH GROUP. CHAOS report. 586 Old Kings Highway, Dennis, MA, 02638, USA, 2004. SWANSON, E. B. Maintaining IS quality, Information and Software Technology, 1997, Los Angeles - USA v.39, issue 12, p. 845-850. THIRY, M. e outros, Uma Abordagem para a Modelagem Colaborativa de Processos de Software em Micro e Pequenas Empresas, 2006. São José – SC, Universidade do Vale do Itajaí (UNIVALI), V Simpósio Brasileiro de Qualidade de Software – SBQS. TOMMARELLO, J., D.; DEEK, F., P. Collaborative software development: a discussion of problem solving models and groupware technologies. 2002, pp. 568 – 577. System Sciences. New Jersey Institute of Technology. HICSS. Proceedings of the 35th Annual Hawaii International Conference on, January. TREUDE, C. Work Item Tagging: Communicating Concerns in Collaborative Software Development. Canada, 19p, jan. de 2012. WEBER, K. C., et al. Melhoria de processo do software braileiro: resultados alcançados e lições aprendidas, 2008, Rio de Janeiro, UFRJ.
58
APÊNDICE A - Questionário para coleta de informações
1. Qual o ramo de atuação da empresa?
2. Quais os principais produtos oferecidos pela empresa?
3. A empresa se preocupa e busca a melhoria contínua e a aplicação de ferramentas que
possibilitem o controle da qualidade do software desenvolvido?
4. Quais produtos são desenvolvidos e oferecidos pela empresa?
5. Em que local os produtos, oferecidos pela empresa, são confeccionados?
6. Quem são os clientes da empresa?
7. Quais os fornecedores e que tipos de serviços e produtos oferecem à empresa?
8. Quais as principais atividades realizadas no ramo de telefonia móvel?
9. O que é necessário para que possam ser executadas as atividades para o
desenvolvimento do software?
10. Como é o padrão e cronograma de desenvolvimento de software utilizado pela
empresa?
11. Descreva as etapas de desenvolvimento de software seguidas pela empresa
59
Universidade Estadual de Maringá Departamento de Engenharia de Produção
Av. Colombo 5790, Maringá-PR CEP 87020-900 Tel.: (44)3011-4196/3011-5833 Fax: (44)3011-4196
