XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
MATURIDADE E INOVAÇÃO NO
DESENVOLVIMENTO DE SOFTWARE:
CONVERGÊNCIA OU CONFLITO
Antonio Carlos Tonini (EPUSP)
[email protected]
Guilherme Ary Plonski (EPUSP)
[email protected]
Mauro de Mesquita Spínola (EPUSP)
[email protected]
Grande parte das atividades humanas depende de aplicações da
Tecnologia da Informação (TI), fazendo com que os software sejam
desenvolvidos cada vez mais rápidamente e a um baixo custo. A
quantidade de desenvolvedores de software tem cresciido
consideravelmente, estimulada pela farta demanda e pelos altos
retornos do negócio o que, por outro lado, acirra a concorrência. A
estratégia de diferenciação, que predominou na década de 90, dá lugar
para as questões de qualidade, custo e atendimento, como elementos
decisivos para a sobrevivência. A competitividade neste mercado passa
a ser dependente de mecanismos que conduzam a um mais alto nível de
qualidade e produtividade e, por esta razão, os desenvolvedores têm
que buscar melhorias nos seus processos de trabalho. As estratégias
empresariais enfatizam o dinamismo da interatividade processomercado e consideram que a capacidade criativa do staff é o elementochave para a melhoria contínua nos processos e para a sobrevivência.
Os principais modelos de referência de governança de TI apresentam
caminhos de sucesso para atingir a plena maturidade nos seus
processos. Estes modelos destacam como fator crítico o
estabelecimento e o cumprimento estrito de um método de
desenvolvimento, mesmo que este aceite certo grau de flexibilidade.
Diversas pesquisas mostram que a maioria dos projetos de
implementação dos modelos de melhoria nos processos tem falhado em
função de estratégias não claramente definidas, falta de compromisso
das pessoas, desalinhamento estratégico, falta de persistência,
desorganização e falta de criatividadade em adaptar o modelo às
características da empresa entre outras.
A questão colocada por este trabalho é investigar se existe alguma
relação entre o controle dos processos de desenvolvimento de software
e os esforços de inovação da empresa. Para tanto, é montado um
quadro de teórico de referência tendo como base o conceito de
inovação, as características do processo de desenvolvimento de
software e as recomendações dos modelos de maturidade. Com isso é
definido claramente o problema de pesquisa e formulada a proposição
de que a inovação é condição básica para que a organização atinja a
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
maturidade no desenvolvimento de software.
O artigo apresenta também os resultados de uma pesquisa de campo,
realizada na forma de um Estudo de Casos Múltiplos envolvendo duas
organizações desenvolvedoras de software com caracteristicas
diferentes. Enquanto uma delas atende um único cliente e prioriza a
estabilidade de seus processos, a outra atende o mercado em geral e
mantém diversas linhas de produtos para arquiteturas distintas.
Palavras-chaves: Maturidade, Inovação, Desenvolvimento de software,
2
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
1. Introdução
Grande parte das atividades humanas depende de aplicações da Tecnologia da Informação
(TI), obrigando que os software sejam desenvolvidos cada vez mais rápido, de forma eficaz e
a um baixo custo. O cliente deseja que o software funcione sempre e de forma correta e, em
caso de falha, ele espera que o desenvolvedor rapidamente corrija o erro, independente do
grau de dificuldade do motivo da falha (FENTON & PFLEEGER, 1997).
Paralelamente, a quantidade de desenvolvedores tem crescido consideravelmente estimulada
pelos altos retornos do negócio e demanda crescente. Consequentemente, a concorrência tem
se acirrado e sofisticado, independente do tamanho da organização ou do volume dos
negócios. A estratégia de diferenciação, que predominou na década de 90, dá lugar para as
questões de qualidade, custo e atendimento, como elementos decisivos para a sobrevivência.
A competitividade no mercado de software tornou-se dependente de mecanismos que
conduzam a um mais alto nível de qualidade e produtividade. Os desenvolvedores têm que
buscar melhorias nos seus processos de trabalho traduzidas em menores custos e percepção
pelos clientes (FERNANDES & ABREU, 2006).
Os modelos de planejamento estratégico empresarial realçam a necessidade do dinamismo, da
interatividade processo-mercado e consideram que a capacidade criativa do staff é o
elemento-chave para a melhoria contínua nos processos e para a sobrevivência empresarial,
uma vez que é necessário que a própria organização descubra suas próprias forças e fraquezas
e gere as idéias e o conhecimentos necessários (MINTZBERG & QUINN, 2001).
Por outro lado, os principais modelos de referência de governança de TI apresentam caminhos
para que os desenvolvedores de software, partindo muitas vezes de uma situação de extrema
falta de controle atinjam a plena maturidade nos seus processos. Estes modelos enfatizam os
princípios da Engenharia de Software e da Qualidade, destacando como fator crítico o
estabelecimento e o cumprimento estrito de um método de desenvolvimento, mesmo que este
aceite certo grau de flexibilidade (CHRISSIS et al, 2003). Em outras palavras, a organização
necessita possuir um forte controle ao longo do ciclo de vida do desenvolvimento de software,
procurando mitigar os riscos e evitar que eventos inesperados atrapalhem o sucesso do
projeto. Gerenciar riscos é uma atividade primordial para o sucesso dos projetos e os
processos de trabalho devem ser os mais simples em termos de princípios, técnicas, métodos e
ferramentas. A ausência de simplicidade forma barreiras que inibem suas aplicações, tornando
difícil a identificação das estruturas mais importantes e desestimulando qualquer esforço de
melhoria.
Diversas pesquisas mostram que a maioria dos projetos de implementação dos modelos de
melhoria nos processos tem falhado por uma série de razões, tais como: estratégias não
claramente definidas, falta de compromisso das pessoas, desalinhamento estratégico, falta de
persistência, desorganização e falta de criatividadade em adaptar o modelo às características
da empresa. Por outro lado, mesmo que uma organização adote um modelo de melhoria de
processos ela deve considerar que os modelos são apenas simplificações da realidade e, por
esta razão, eles são apenas descritivos, isto é, apresentam um conjunto de idéias que
canalizam a criatividade empresarial, sem necessariamente que isto seja uma “receita” para o
3
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
sucesso. Se assim fosse, todas as organizações que atendessem o modelo, lograriam sucesso
igualmente (CARD, 2002).
A questão colocada por este trabalho é investigar se existe alguma relação entre o controle dos
processos de desenvolvimento de software e os esforços de inovação da empresa. Para tanto, é
montado um quadro de teórico de referência tendo como base o conceito de inovação, as
características do processo de desenvolvimento de software e as recomendações dos modelos
de maturidade. Com isso é definido claramente o problema de pesquisa e formulada a
proposição de que a inovação é condição básica para que a organização atinja a maturidade no
desenvolvimento de software.
O artigo apresenta também os resultados de uma pesquisa de campo, realizada na forma de
um Estudo de Casos Múltiplos envolvendo duas organizações desenvolvedoras de software
com caracteristicas diferentes. Enquanto uma delas atende um único cliente e prioriza a
estabilidade de seus processos, a outra atende o mercado em geral e mantém diversas linhas
de produtos para arquiteturas distintas.
2. Fundamentação teórica
Desde que a General Electric (GE) na década de 90 atribuiu seus altos lucros à adoção da
filosofia Seis Sigma para o controle de seus processos de trabalho, diversos autores tem
discutido a questão se existe conflito entre eficiência e criatividade (HUNTER & SCHMIDT,
1999) (MARASH, 2000).
Para alguns, uma estratégia gerencial disciplinada e quantitativa, que visa aumentar
significativamente a lucratividade das organizações através da otimização de produtos e
processos, deixa pouco espaço para a criatividade e inovação (BLAKESLEE, 1999). Para
outros, os esforços de melhoria devem ter a função de satisfazer completamente e com
lucratividade as necessidades dos clientes, o que se traduz em acertar “o alvo” por eles
estabelecido, com mínima variação e desperdício e, para isso, todos os processos podem ser
melhorados (ALLWAY & CORBETT, 2002).
2.1. Processo de inovação
O atendimento às necessidades dos clientes é uma estratégia vital para a continuidade de
qualquer negócio. A formulação de estratégias deve estar baseada nas competências
essenciais, que são os aprendizados coletivos da organização relacionados com a coordenação
e uso das diversas ferramentas de produção, a execução dos processos de trabalho,
aproveitando e integrando as múltiplas correntes tecnológicas disponíveis no ramo de atuação
(PRAHALAD & HAMEL, 1990).
A competitividade bem sucedida é aquela que sabe determinar racionalmente a capacidade de
competir fazendo convergir de forma efetiva a capacidade e a habilidade empresarial (pontos
fortes e fracos da organização) com as oportunidades sinalizadas pelo mercado (ZAIRI,
1997).
Isto significa que toda e qualquer mudança no relacionamento empresa–cliente deve ser feita
de forma planejada e baseada em fatos, reclamações, sugestões ou desafios de melhoria. Este
princípio chama a atenção para a racionalidade de toda e qualquer mudança, a qual está
4
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
diretamente atrelada a capacidade de competitividade da empresa (ANSOFF &
McDONNELL, 1984).
Inovar se constitui na transformação de uma idéia ou de uma oportunidade em um conjunto de
ações internas (processo produtivo) produzindo algo novo e diferente (inovação no produto)
ou modificando total ou parcialmente a forma de fazer (inovação no processo). As inovações
radicais provocam mudanças na organização, nos clientes e no relacionamento entre ambos;
as inovações incrementais são inerentes ao processo e contínuas ao longo do tempo
(DODGSON & GRIFFITHS, 2004).
Os fatores que mais influem na intensidade da inovação são a urgência e a importância que
ela representa para o cliente interessado, o grau de complexidade tecnológica envolvida para
transformar a idéia em realidade e o retorno que ela proporciona para a organização que a
implementa (GOFFIN & PFEIFFER, 2001).
A inovação de um produto ou serviço deve ser entendida também como um processo, pois ela
se fundamenta em uma base de conhecimento, experiência e uso já existente. As principais
fases do processo de inovação são as seguintes (TIDD et al., 2005):
− Busca: é a detecção e processamento dos sinais relevantes de mudanças necessárias no
ambiente onde a organização atua;
− Seleção: é a escolha da alternativa que seja mais aderente aos objetivos estratégicos e às
competências essencias da empresa;
− Implementação: corresponde a efetiva adoção da inovação, transformando a idéia em
realidade e, para tanto, é necessário:
o Aquisição dos conhecimentos necessários: novos conhecimentos podem ser adquiridos
pela invenção ou pela combinação da base de conhecimento existente, com o devido
apoio de testes no mercado através da divulgação da idéia;
o Execução: corresponde a parte central do processo de inovação, ou seja, transformar a
idéia e processos de trabalho;
o Lançamento: consiste em tornar público e disponível para os clientes o novo produto ou
a nova forma de produzí-lo, promovendo os ajustes necessários
o Sustentação: consiste nas ações técnico-gerenciais para garantir a longevidade do novo
lançamento;
− Aprendizado: é a formação da base de conhecimento explícita sobre o novo produto oou
processo e capitalizar todos os acertos e erros para futuras inovações.
Sob a ótica financeira, as atividades de inovação formam dois ciclos – lançamento e produção
– sendo que cada qual contem uma carga inevitável de custo. Estes ciclos, conforme mostra a
figura 2, são marcados e delimitados pelos seguintes eventos: 1 – oportunidade, 2 –
percepção, 3 – investigação, 4 – definição, 5 – entrega e 6 – aprovação e 7 – extinção
(PATTERSON, 1998).
5
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
Figura 1 – Ciclos de lançamento e produção (adaptado de PATTERSON, 1998)
De uma forma geral, a pesquisa aplicada e o desenvolvimento de tecnologia são bancados e
realizados, na sua maioria, pelas empresas, cabendo à academia com o apoio do governo, o
desenvolvimento da pesquisa básica. Esta divisão de tarefas não é uma idéia nova. Francis
Bacon (1561-1626), acreditando que a ciência levaria ao desenvolvimento de tecnologia e à
produção de riqueza, propôs que o apoio do Estado às atividades de pesquisa acadêmica era
fundamental. Esta idéia foi desenvolvida mais tarde dando origem ao conhecido Triângulo de
Sábato e a Hélice Tríplice de Relações Universidade-Indústria-Governo (PLONSKI, 2005).
2.2. Processos de desenvolvimento de software
Os produtos de software são atualmente os maiores componentes do orçamento de muitas
organizações, o que as leva a exigir um alto nível de qualidade e capacidade para absorver
maiores funcionalidades.
No entanto, os Relatórios do Standish Group (CHAOS, 2000) demonstram que a produção de
software no mundo ainda tem muito espaço para melhorar tanto em termos de processo
quanto em termos de qualidade, podendo oferecer produtos a custos muito mais convidativos.
A tabela 1, mostra que ainda cerca de um quarto dos projetos não são concluídos e que,
aproximadamente a metade é entregue com falha.
RESULTADO DOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE
Resultado de Projetos
1994
Entregues com sucesso
16 %
Não entregues por falha
31 %
Entregues com falha
53 %
Fonte: Standish Group - Chaos (2000)
1996
27 %
40 %
33 %
1998
26 %
28 %
46 %
2000
28 %
23 %
49 %
Tabela 1 – Distribuição percentual de projetos de desenvolvimento de software
Segundo Pressman (2004), as principais falhas estão relacionadas com o não entendimento de
requisitos (o software faz o não deve ou não faz o que deve fazer), com o custo acima do
orçado e com os atrasos na entrega. Estes dados traduzem também a falta de maturidade em
grande parte das organizações. Neste sentido, a tabela 2 mostra as principais características
dos dois tipos extremos de processos de desenvolvimento de software (PAULK et al., 1997).
CARACTERÍSTICAS DOS TIPOS EXTREMOS DE EMPRESAS DESENVOLVEDORAS DE SOFTWARE
Processo Imaturo
Não é rigorosamente seguido
O cumprimento não é controlado
Baixa visão do progresso
Baixa visão da qualidade do produto
A qualidade e as funcionalidades podem ficar
aquém do negociado para cumprir o prazo
Processo maduro
Consistente com a maneira que o trabalho é realmente
executado
Definido, documentado, compreendido, utilizado, vivo
e ativo
Tem o apoio visível da alta administração e outras
gerências
Bem controlado – fidelidade ao processo é objeto de
auditoria e de controle
Uso disciplinado de tecnologia
6
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
É arriscado, se houver mudança de tecnologia
Processo improvisado por profissionais e gerentes
Elevados custos de manutenção
O processo e o produto são medidos regularmente
A cultura organizacional transmite o processo
Processos institucionalizados permanecem, mesmo
depois que as pessoas que o definiram, deixam a
organização
Fonte: Paulk et al. (1997)
Tabela 2 – Características dos dois tipos extremos de processos
O paradigma tradicional de desenvolvimento de software, conhecido como “ciclo de vida”,
foi concebido de forma a mostrar a seqüência de realização das atividades (entendimento dos
requisitos, modelagem, codificação e testes). As atividades são organizadas em etapas que
devem ser executadas na ordem prevista e associam os métodos, as ferramentas e os
procedimentos necessários à execução. Os modelos especificam ou uma estrutura de alto nível
apenas (modelos estruturais) ou detalham mais pormenorizadamente os procedimentos
(modelos processuais). A escolha do modelo mais adequado depende da natureza do projeto,
dos métodos adotados, das ferramentas a serem usadas, dos controles e dos produtos
desejados e da infra-estrutura computacional (PRESSMAN, 2004).
Este paradigma obriga os desenvolvedores a respeitar as fases de desenvolvimento sem rotas
alternativas. Como o insumo para a próxima fase depende do resultado da fase anterior e,
assim sucessivamente até o produto estiver concluido e, existe a possibilidade de haver mais
de uma pessoa envolvida, é necessário um rigor maior na documentação do trabalho
executado além do próprio trabalho realizado.
A popularização do uso dos recursos de TI, as facilidades oferecidas pelo ambiente WEB e a
difusão do sistema operacional Linux com a permissividade de uso e implementação de novos
componentes estimularam o crescimento da quantidade de software escrito sem qualquer
formalidade ou rigor (POPPENDIECK, 2001). Paralemente, é lançado o “manifesto ágil”
propondo uma nova metodologia para desenvolvimento de software, realçando a importancia
dos indivíduos e das interações sobre os processos e ferramentas, do funcionamento do
software sobre a documentação completa e detalhada, da colaboração com o cliente sobre a
negociação contratual e da adaptação às mudanças sobre o plano original de trabalho (COHN
& FORD, 2003).
A escolha de uma representação afeta diretamente como uma equipe de desenvolvimento é
estruturada, quando e como os membros desta equipe interagem, quem tem autoridade e quem
é responsável por cada parte (COSTA, 1999).
2.3. Modelos de maturidade
Se a globalização na indústria de software é uma realidade, a estratégia de garantir a
satisfação do cliente, cumprindo o escopo, prazo e custo, é bastante razoável. Por esta razão,
obter um certificado de qualidade ajuda a demonstrar a qualidade ao cliente. O certificado é
uma maneira de selecionar fornecedores e, muitas vezes, é um pré-requisito para o começo de
um novo negócio. Ter o certificado não é garantia de boa qualidade mas, não tê-lo, é uma
desvantagem competitiva (CARD, 2002).
7
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
Segundo este raciocínio, na década de 90 surgiram um considerável número de modelos,
normas e melhores práticas no campo de TI. Entre estes, o mais notório e de maior utilização
mundial, é conhecido como “Modelo de Maturidade da Capacidade” ou simplesmente CMM
(Capability Maturity Model). Este modelo foi originado a partir de um framework idealizado
por Watts Humphrey nos anos 80 para que o Software Engineering Institute (SEI) pudesse
selecionar fornecedores de software cada vez mais qualificados e capazes de cumprir seus
contratos junto ao Departamento de Defesa Norte-americano (US DoD), um dos maiores
compradores de software do mundo (FENTON & PFLEEGER, 1997).
Embora nenhum dos conceitos fosse novo, a idéia em si era original e ímpar: integrar a
disciplina de software junto com as melhores práticas da qualidade total dentro de uma grade
evolutiva de maturidade, como mostra a figura 2(a), que pudesse não só distribuir o esforço de
melhoria em etapas como também servir para endereçar inicialmente os pontos mais críticos
(barreiras) dos programas de melhoria.
O Capability Maturity Model Integration (CMMI), atualmente na versão v1.2, é resultado da
evolução a família CMM, para a qual, a capacidade descreve os resultados esperados após a
aplicação de um processo de software na organização e a maturidade representa o potencial de
crescimento da capacidade e indica a riqueza do processo de software e a consistência do
mesmo quando replicado para outros projetos. O modelo classifica a maturidade em cinco
níveis, lidando com um número possível, finito e tangível de problemas típicos enfrentados
pela engenharia de software, dando assim oportunidade às organizações de crescerem
(amadurecerem) suas capacidades de forma incremental, atingindo patamares sucessivos de
melhoria cada vez mais sofisticados, conforme demonstra a figura 2(b).
Figura 2 – Concepção do modelo da família CMM (adaptado de FENTON & PFLEEGER, 1997)
O modelo CMMI trata a questão da inovação de forma explícita apenas no nível 5, através de
ações específicas de melhoria contínua com base no entendimento estatístico dos resultados
do conjunto de processos da organização ou mesmo do projeto específico. Os objetivos de
melhoria da organização são estabelecidos quantitativamente e continuamente monitorados e
revisados, de sorte a refletir todas as mudanças nos objetivos do negócio. Isto significa
selecionar e colocar em utilização somente aquelas melhorias incrementais e inovativas, que
de forma mensurável melhoram os processos e tecnologia da organização. As melhorias
devem suportar os objetivos da qualidade e desempenho de processos da organização desde
8
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
que eles sejam derivados dos objetivos de negócio. Em outras palavras, isto significa melhorar
de forma consistente, gradual e com visibilidade para os negócios (CHRISSIS, 2003).
2.4. Quadro de referencia
A inovação pode ser contrária aos hábitos, maneiras e ritos estabelecidos dos processos de
trabalho, até porque as pessoas são resistentes a qualquer tipo de mudança. Apesar de
aparentemente conflitantes, na verdade inovar e ser eficiente são ações complementares e
sinérgicas, sendo ambas necessárias para o sucesso sustentável das organizações. A melhoria
da produtividade, assim como a manutenção da fidelização do cliente, aumenta a
lucratividade; as ações de inovação melhoram a relação com o cliente, contribuindo
positivamente a fidelização do mesmo. A gestão dos negócios passa a ser, então, a
responsável por adequar e alinhar os esforços em melhoria de produtividade e ações de
inovação (ANSOFF & McDONNELL, 1984).
Para tornar realidade uma idéia inovadora, a empresa precisa acreditar e investir na idéia,
bancando os obstáculos, enfrentando os riscos e a forte possibilidade de fracassar. (TIDD et
al., 2005). Os esforços de melhoria da produtividade não podem ser implementados sem que
sejam adaptados à realidade e às características particulares da organização e também não se
aplicam a todas as atividades. Os esforços de melhoria na produtividade se aplicam
eficazmente para os processos internos de características repetitivas. Para as atividades
criativas, deve-se preparar um ambiente propício ao florescimento e considerar uma margem
de liberdade adequada (ANSOFF & McDONNELL, 1984).
O software é resultado de uma interação, iteração e acordo intelectual entre usuários e
desenvolvedores (PRESSMAN, 2004) exigindo de ambos criatividade para buscar a solução
mais adequada. Como visto acima, o desenvolvimento de software, depois da idéia formada,
passa ser algo repetitivo e prescritivo.
Analisando-se os processos de desenvolvimento de software (paradigmas tradicional e as
novas tendências) bem como as proposições do modelo de referencia CMMI, pode-se admitir
a proposição de que a inovação (lado criativo do software) é uma condição básica para galgar
maiores níveis de maturidade. Deve haver uma predisposição da empresa para a organização,
independente do paradigma adotado para o seu processo produtivo de software.
3. Estudo de caso múltiplo
No sentido de investigar como as empresas de software lidam com as questões de melhoria e
inovação dos seus processos de desenvolvimento, este artigo apresenta o resultado de uma
pesquisa empírica, de natureza qualitativa, conduzida por meio do método de Estudo de Casos
Múltiplos (YIN, 1998). O uso do Estudo de Casos Múltiplos permitiu entender os contextos
empresariais específicos e os motivos que levam estas organizações melhorar seus processos e
promover inovações. Não obstante haver similaridades com outras empresas, a pesquisa não
permite generalizações (CLAVER et al., 2000).
A pesquisa foi realizada em duas organizações brasileiras desenvolvedoras de software que
aplicam sistematicamente procedimentos de melhoria nos seus processos de desenvolvimento.
9
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
A proposição que orientou a pesquisa foi a de que “a inovação é a condição básica para que
a organização atinja a maturidade no desenvolvimento de software”.
A escolha das empresas ocorreu em função da diversidade de negócio das mesmas. Enquanto
uma delas atende um único cliente e prioriza a estabilidade de seus processos, a outra atende o
mercado em geral e mantém diversas linhas de produtos para arquiteturas distintas. Para a
coleta de dados, foram realizadas entrevistas semi-estruturadas com gestores e
desenvolvedores em ambas as organizações. O foco das entrevistas foi entender os processos
de desenvolvimento de software, as melhorias executadas nestes processos e como elas agem
em termos de inovação nestes processos. As opiniões foram confrontadas com o quadro
teórico, o que permitiu entender o quanto estão aderentes com a literatura.
4.1. Caso 1
A Unidade de Análise 1 (UA1) é um instituto de pesquisa sediado em importante centro
econômico do Estado de São Paulo, fundado com o propósito de pesquisa e desenvolvimento
de novas tecnologias de TI. No início de suas operações, contou com o aporte de capital
público na forma de incentivos fiscais. Com uma gestão dinâmica, orientada pelas
oportunidades do mercado, e uma estrutura enxuta, ágil, flexível, de baixo overhead e
altamente qualificada, teve seus processos-chave certificados segundo as normas de qualidade
ISO 9001 e de maturidade pelo CMMI nível 2 (1999), nível 3 (2000), nível 4 (2005) e nível 5
(2007). Convém notar que faz parte da maioria dos contratos, que a UA1 tem que demonstrar
alta maturidade nos processos de software.
Pelo fato de viabilizar aos clientes os benefícios proporcionados pela Lei de Informática, os
projetos celebrados junto aos clientes são de longa duração (mínimo de cinco anos); para
tanto, cada cliente é tratado como uma unidade de negócio; as equipes são totalmente
separadas, graças a especialidade exigida pelo cliente e no encerramento do contrato, todo
conhecimento produzido e, às vezes também os engenheiros de software, são transferidos para
o cliente.
O levantamento de dados para este artigo foi feito junto com a unidade de negócio especialista
em produtos para a Tecnologia da Informação e Comunicação (TIC) e envolveu o gerente de
desenvolvimento da unidade de negócio de software embarcado, um engenheiro de software e
um analista da garantia da qualidade.
Para atender os diversos modelos de estruturação de processos de software, a UA1
desenvolveu um modelo próprio, altamente flexível e abrangente. É diretriz corporativa
somente desenvolver projetos de acordo com o modelo interno de desenvolvimento,
independentemente da exigência do cliente. O modelo interno está totalmente alinhado com as
áreas de processo do modelo de maturidade CMMI e normas específicas, como a norma NBR
ISO/IEC 12.207:1998 e, por isso, suporta qualquer modelo específico de algum cliente. Todos
os processos estão definidos, conhecidos, praticados estabilizados e padronizados, o que
contribui de forma positiva para treinar e capacitar os desenvolvedores.
Cada projeto representa uma instância do modelo padrão de processos e contém apenas
aqueles processos, práticas e artefatos que lhes são necessários. Esta customização envolve o
nível de atividades e tarefas, mantendo-se o perfil em nível de processos, isto é,
planejamento, projeto e execução. Tanto a produção de novos softwares, como a manutenção
posterior, são feitas somente por encomenda.
10
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
Foi um fato motivador e gratificante para os desenvolvedores descobrir que a ação de “definir
processos de software” nada mais significou do que traduzir em palavras o que realmente era
executado. No início, a resistência foi grande, pela falta de conhecimento de como “descrever
o processo”. No entanto, vencida a resistência inicial, isto se transformou em um fator crítico
de sucesso (FCS) para a melhoria dos processos de desenvolvimento.
Uma parte do desenvolvimento é terceirizada, sendo que a gestão dos recursos humanos ora é
feita internamente ora é também contratada. Todos os engenheiros de software,
independentemente do fato de serem mão-de-obra própria ou de terceiros, recebem
treinamento específico sobre os processos de desenvolvimento adotados pela UA1 e exigidos
pelos clientes. As necessidades de treinamento são acusadas pelas métricas de defeitos pós
entrega e de produtividade. Além disso, existe um fluxo significativo de interesse em
treinamento por parte dos desenvolvedores, no sentido de se capacitar e contar com o apoio da
organização (efeito sinérgico).
Uma das maiores dificuldades apontadas pela UA1 reside na capacitação dos gestores
externos, quando é feita a contratação para o desenvolvimento de um produto. Via de regra,
os gestores externos são avessos a qualquer tipo de controle. Para minimizar este problema,
tem se tornado um dos itens mais importantes da seleção de fornecedores, a demonstração da
qualificação dos gestores externos, em relação aos seus conhecimentos de gestão de projetos,
manuseio de técnicas estatísticas e gestão de pessoas.
Os esforços de melhoria dos projetos se manifestam pelo incentivo à inovação e o histórico
aponta para as seguintes inovações adotadas:
(a) capacitar todos os gerentes em metodologias de projeto, de forma a estabelecer uma
linguagem padrão com todos os clientes;
(b) capacitar as equipes a descrever os processos de desenvolvimento de software,
envolvendo regras de programação e de lógica computacional. Note que grande parte
dos software desenvolvidos é embarcada nos produtos e devem ter uma dimensão
bastante pequena;
(c) criar uma biblioteca de componentes em todas as linguagens de programação voltadas
para o ambiente de software embarcado;
(d) criar comunidades de discussão, inclusive com técnicos de empresas concorrentes,
melhorando a capacidade profissional dos membros das equipes;
(e) criar incentivos especiais através de concursos internos de conhecimento sobre
tecnologias e metodologias de desenvolvimento de software;
(f) contratar especialistas em diferentes tecnologias (ambiente Windows, Mainframe,
Linux, Web e outros);
(g) celebrar acordos com universidades que mantém centros de pesquisa na melhoria da
qualidade dos processos de desenvolvimento e também no próprio desenvolvimento
de software.
11
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
4.2. Caso 2
A unidade de análise 2 (UA2) é uma organização genuinamente nacional, líder no mercado
nacional e na América Latina de Sistemas Integrados de Gestão, conhecidos como ERP
(Enterprise Resource Planning). Está presente também nos EUA, através de duas empresas
franqueadas para atender clientes com matriz no Brasil e através de uma empresa franqueada
em Portugal. Recentemente, o grupo adquiriu mais duas outras empresas de destaque neste
mercado. Seus produtos são certificados pelo sistema ISO 9001:2000, seus processos de
desenvolvimento estão reconhecidos pelo modelo CMMI nível 4, passaporte necessário para
entrar no mercado europeu e o corpo gerencial pratica as disciplinas de gerenciamento de
projetos segundo o PMI (Project Management Institute). Participaram da entrevista, o gerente
de desenvolvimento de sistemas e dois engenheiros de software.
Pelo fato de contar com uma carteira de mais de 10.000 clientes, a UA2 procura manter
equipes especialistas para cada um dos modelos de desenvolvimento, tanto tradicional como
segundo as tendências mais recentes (orientação a objetos, metodologias ágeis, ambiente
Linux, sistemas para WEB e cliente-servidor).
Os engenheiros de software são treinados constantemente quanto às inovações tecnológicas,
são estimulados a participar de grupos independentes de pesquisa e são estimulados a dar
sugestões que possa tornar o trabalho mais produtivo, menos vulnerável a erro e aumentar a
qualidade nos produtos entregues aos clientes.
Os coordenadores de cada equipe têm por obrigação manter o conjunto de procedimentos de
cada um dos ambientes de desenvolvimento, o mais atualizado possível.
Como a meta é atingir o mais rapidamente a certificação conforme o nível 5 do modelo
CMMI, desde o lançamento deste modelo (iniciaram o processo do modelo CMMI em 2000;
obtiveram as certificações nível 2 e 3 ainda em 2002, o nível 4 em 2005 e esperam ser
distinguidos com o nível 5 no início de 2009). Desde o início, existe uma preocupação com a
melhoria contínua, de acordo com a filosofia kaizen (melhorias pequenas e constantes). As
principais inovações que fizeram no processo de desenvolvimento foram:
(a) obrigar que os desenvolvedores façam estágio periódico nas empresas clientes, junto
com as equipes de implantação para conhecer as reais necessidades dos usuários e
entender os requisitos;
(b) distribuir versões alfa e beta dos produtos junto a determinados clientes que,
reconhecidamente fazem teste de aceitação de novas versões do sistema;
(c) criar uma universidade interna orientada para análise de sistemas (modelo de negócio),
tecnologia da informação;
(d) capacitar o corpo gerencial com certificações em gestão de projetos;
(e) adquirir componentes de software para integrar as diferentes camadas de software:
aplicação, regras de negócio, banco de dados e apresentação;
(f) contratar especialistas em diferentes tecnologias (Windows, Mainframe, Linux, Web e
outros);
12
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
(g) contratar especialistas em diferentes metodologias de desenvolvimento (desde as
tradicionais, até as mais modernas, com ênfase em ambiente WEB);
(h) estimular a criação de redes de conhecimento, promovendo eventos de tecnologia e
metodologia;
(i) distribuir gratuitamente cópias de software nas universidades, colaborando com a
formação técnica dos estudantes;
(j) criar um setor de P&D em tecnologias de desenvolvimento de sistemas e
estabelecimento de contratos de transferência de tecnologia com empresas
desenvolvedoras de linguagens de programação e sistemas operacionais;
(k) criar concursos de conhecimentos em metodologia e tecnologia com premiação;
(l) criar bibliotecas de componentes de software e estimular o uso em vez do redesenvolvimento da funcionalidade.
4.3. Resultados
Analisando-se as respostas de ambas as organizações, percebe-se que todas as inovações
implementadas nos processos de desenvolvimento são melhorias pontuais e incrementais e
foram agrupadas em ações: externas às empresas, organizacionais, pessoais (técnicos e
gerentes), metodologia e tecnologia, conforme resume a tabela 3. Todas as ações indicadas
denotam preocupação das Unidades de Análise com o futuro de seus negócios e com a criação
de vantagem competitiva., Destaca-se os seguintes itens:
− os resultados dos acordos com as Universidades só ocorrerão depois de algum prazo, uma
vez que eles estão condicionados à formação dos alunos. No entanto, os objetivos de ambas
as Unidades de Análise são distintos; uma procura parceria para desenvolver componentes
para os clientes enquanto a outra objetiva gerar mercado futuro para seus produtos;
− o envolvimento dos clientes para testar os sistemas tem por objetivo fidelizar o cliente;
− a criação de um centro de pesquisa interno envolve custo, mas diminui a dependência da
organização em relação a terceiros;
− a capacitação gerencial, o estágio dos engenheiros nos ambientes dos clientes, a contratação
de especialistas, os estímulos para desenvolvimento pessoal e a criação de uma
Universidade corporativa têm por objetivo assegurar qualificação e disponibilidade da mãode-obra;
− a descrição dos processos de trabalho pelos atores que o executam garante que os trabalhos
serão executados de maneira natural e minimiza os efeitos de resistência às mudanças;
− a criação de bibliotecas de códigos e aquisição de componentes traduz uma inovação que
reduz tempo e garante padronização do processo de desenvolvimento.
RESUMO DAS INICIATIVAS DE INOVAÇÃO NOS PROCESSOS DE SOFTWARE
Tipo da
inovação
Externo
Organizacional
Pessoal
Alvo da
inovação
P&D Externo
Clientes
P&D Interno
Capacitação
gerencial
Capacitação
Detalhe da inovação
Acordos com Universidades
Distribuição de versões para teste
Criar centro de pesquisa interno
Capacitar os gerentes em metodologias de projeto
Estágio nos clientes
UA1
UA2
X
X
X
X
X
X
X
X
13
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
Metodologia
Tecnologia
técnica
Capacitação
técnica
Busca
de
talentos
Network
Motivacional
Metodologia
Linguagens
de
programação
Universidade corporativa
X
Contratação de especialistas
Criação de comunidade de conhecimento
Incentivos e premiação através do estudo
Capacitar as equipes a descrever os próprios
processos
Criação de biblioteca de componentes
Aquisição de componentes de software para 4
camadas
X
X
X
X
X
X
X
X
X
X
Fonte: o autor
Tabela 3 – Ações inovativas nos processos de software nas Unidades de Análise
5. Considerações finais
Como o desenvolvimento de software apresenta características de criatividade com
seguimento de modelos pré-definidos, as melhorias implementadas sempre se traduzem na
forma de ações inovativas que variam do “fazer melhor” ao “fazer diferente”. Elas podem ser
aplicadas para qualquer situação em que a empresa se encontra e para qualquer processo de
trabalho.
A prioridade da implementação deve priorizar as ações mais simples e que produzem os
efeitos mais benéficos tanto para os clientes quanto para os desenvolvedores.
Assim como os projetos de desenvolvimento e as situações são passageiras e temporárias, as
ações inovativas devem ser aplicadas no momento e na intensidade exata. A quantidade mais
adequada de mudança só vai ser conhecida na medida em que o exercício contínuo de
melhoria for uma política adotada pela organização.
Referências
ALLWAY, M. & CORBETT, S. Shifting to Lean Service: Stealing a Page from Manufacturer’s Playbooks.
Journal of Organizational Excellence. Spring 2002.
ANSOFF, H.I. & McDONNELL, E.J. Implementing Strategic Management. Prentice-Hall, 1984.
BLAKESLEE JR., J. A. Achieving quantum leaps in quality and competitiveness: implementing the Six Sigma
solution in your company. Proc. of the 53th Annual Quality Congress, American Society for Quality, Anaheim:
Califórnia, 486–496, May 1999.
CARD, D. N. Managing software quality with defects. Proceedings. 26th Computer Software and Applications
Conference, IEEE Computer Society, p.472-474, 2002.
CHAOS.
The
Chaos
Report,
2000.
<<Acesso
[http://www.agilealliance.org/system/article/file/1053/file.pdf].
em
26/03/20087>>,
disponível
em:
CLAVER, E. & GONZALEZ, R. & LLOPIS, J. An analysis of research in information systems (1981-1997).
In: Information & Management, v.37, n.4, p.181-195, Apr. 2000.
COHN, M. & FORD, D. Introducing an agile process to an organization. IEEE Computer Magazine, jun 2003,
s.1, p.74-78.
14
XXVIII ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO
A integração de cadeias produtivas com a abordagem da manufatura sustentável.
Rio de Janeiro, RJ, Brasil, 13 a 16 de outubro de 2008
COSTA, I. Contribuição para o aumento da qualidade e produtividade de uma fábrica de software através da
padronização do processo de recebimento de serviços de construção de softwares. Tese (Doutorado), Escola
Politécnica da USP, Departamento de Engenharia da Produção, 2003.
CHRISSIS, M. B. &; KONRAD, M. & SHRUM, S. CMMI: Guide for Process Integration and Product
Improvement. Boston: Addison-Wesley, 2003.
DODGSON, M. & GRIFFITHS, A. Sustainability and innovation. International Journal of Innovation
Management. Vol 6, n.3, 2004.
FENTON, N. E. & PFLEEGER, S. L. Software metrics: a rigorous approach, 2a ed. International Thomson
Computer Press, 1997.
FERNANDES, A.A. & ABREU, V.F. Implantando a Governança de TI. Rio de Janeiro: Brasport, 2006.
GOFFIN, K. & PFEIFFER, R. Competing in the innovation pentathlon. Innovation: Management, Policy and
Practice, v.4, n.1 e 3, p.143-150.
HUNTER, D. & B. SCHMIDT. Six sigma: benefits and approaches. Chemical Week, v.161, n.37, p.35-36, out,
1999.
MARASH, S. A. Six Sigma: Business Results Though Innovation. Proc of the 54th Annual Quality Congress of
the American Society for Quality, Indianapolis, Indiana, 627–630, May 2000.
MINTZBERG, H. &; QUINN, J. B. O processo da estratégia, 3ª ed. Porto Alegre: Bookman, 2001.
PATTERSON, M. From Experience: Key Opportunities for Improving Innovation Cycle Time. The CERTI
Conference on Rapid Development of Technology-based Products, Santa Catarina - Brasil, September 17, 1998.
PAULK, M. C. & WEBER, C. V. & CURTIS, B.& CHRISSIS, M. B. The Capability Maturity Model:
Guidelines for Improving the Software Process. SEI, Addison-Wesley Longman Inc. 1997.
PLONSKI, G.A. Bases para um Movimento pela Inovação Tecnológica no Brasil. São Paulo em perspectiva,
Vol. 19, n. 1, p. 25-33, jan./mar. 2005.
POPPENDIECK, M. Lean programming. Software Development Magazine. May-jun, 2001. Disponível em
<HTTP://www.agilealliance.org/articles/LeanProgramming.htm>. Acesso em 23/out/2007.
PRAHALAD, C. K. & HAMEL, G. The Core Competence of the Corporation. Harvard Business Review,
May-June 1990. p. 79-91, 1990.
PRESSMAN, R.S. Software Engineering: A Practitioner's Approach, 5a. ed. Mcgraw-hill / Tecmedd, 2004.
TIDD, J. & BESSANT, J. & PAVITT, K. Managing Innovation: integrating technological, market and
organizational change. 3rd Ed. Chichester: John Wiley & Sons, 2005
YIN, R.K. Case Study Research: Design and Methods. Newbury Park, Rev. ed. Sage Publications,1998.
15