Como mencionado, o objetivo do desenvolvimento de um modelo capaz de explicar o setor de Telecomunicações utilizando uma norma desenvolvida especificamente para empresas de software (ISO/IEC 12207) era criar um referencial capaz de categorizar de maneira semelhante as empresas de Telecomunicações e as empresas de software.
Apesar de ter sido validado como um referencial apropriado para descrever o setor de Telecomunicações durante a execução do projeto “Novas Formas de Organização do Trabalho – Setor Telecomunicações”, na análise da cadeia de valor resultante de um processo de “Emancipação Digital” (FLEURY et al., 2006 a) e para estudo de diversos outros setores industriais, como o setor automotivo, o setor aéreo e o setor têxtil (FLEURY; FLEURY, 2004 b; FLEURY; FLEURY, 2006), algumas questões sugerem que a aplicação do modelo proposto para o setor de Telecomunicações no setor de software não é apropriada.
A primeira questão refere-se ao fato de que, dependendo do contexto em que a análise é elaborada, uma determinada empresa pode ser considerada simultaneamente “Integradora” ou “Desenvolvedora”, tornando o modelo inconsistente. Por exemplo, o desenvolvimento de um software ERP (Enterprise
Resource Planning) requer a integração de diversos software “básicos” para a
geração da nova aplicação, como sistemas operacionais, bancos de dados, geradores de interface e geradores de relatórios. Neste contexto, a empresa que desenvolve o ERP (como por exemplo Microsiga e Datasul) pode ser considerada uma “Integradora”, já que utilizou diversas “soluções” desenvolvidas anteriormente para a criação do seu “sistema”. Por outro lado, a customização e a implementação deste tipo de produto apresentam-se como projetos complexos, usualmente realizados por outras empresas, normalmente consultorias especializadas (como por exemplo Accenture e Procwork). Nesta segunda análise sobre o mesmo evento, a empresa que desenvolveu o ERP deixa de ser “Integradora” e apresenta-se como “Desenvolvedora”, e a empresa de consultoria assume a posição de “Integradora”. Outra questão relevante surge a partir da análise do papel das “Produtoras”, empresas especializadas em processos de fabricação. No modelo proposto para o setor de Telecomunicações, estas empresas interagem apenas com as “Desenvolvedoras” e têm pouca influência no processo de levantamento dos requisitos do sistema (produto). No setor de software, empresas especializadas em processos de desenvolvimento e reutilização de componentes são caracterizadas como “Fábricas de Software”. Elas se comportam de maneira diferente das “Produtoras” do segmento de Telecomunicações, já que, além das “Desenvolvedoras”, estas podem interagir diretamente com as “Integradoras” ou até mesmo com o cliente final (“Operadoras”), e assim, têm grande influência no
processo de levantamento de requisitos e definição das características do sistema. Mais ainda, eventualmente todas as empresas que atuam no segmento de software possuem áreas especializadas de desenvolvimento, podendo implantar “Fábricas de
Software” internas.
Desta forma, o modelo proposto para o setor de Telecomunicações apresenta aderência limitada quando o contexto analisado envolve apenas empresas especializadas no desenvolvimento de software.
5 DINÂMICAS ORGANIZACIONAIS DO SETOR DE SOFTWARE
Apesar de criar um modelo consistente, capaz de definir e descrever diferentes categorias de empresas que atuam no setor de Telecomunicações e explicar processos de “Emancipação Digital” ambientados nesta cadeia de valor, a primeira iniciativa de pesquisa em campo teve resultados limitados na geração de um modelo que pudesse vir a ser aplicado para um melhor entendimento das diferentes categorias de empresas que atuam no setor de software. Porém, por ser capaz de explicar o funcionamento do setor de Telecomunicações, este modelo será novamente utilizado na exploração de um estudo de caso apresentado no próximo capítulo, já que o seu funcionamento é relevante no processo de analise das características de empresas que desenvolvem software embutido.
Por este motivo, a segunda etapa da pesquisa de campo deste projeto de doutorado teve novamente como objetivo analisar a primeira questão da pesquisa, levantando informações que pudessem evidenciar a existência de diferentes categorias de empresas de software. Para isto foi elaborada e aplicada uma survey exploratória, cujos resultados preliminares foram divulgados em diferentes congressos (FLEURY; SPINOLA, 2005 a; FLEURY; SPINOLA, 2005 b; FLEURY et al., 2005) e serão apresentados a seguir.
5.1 REVISÃO BIBLIOGRÁFICA
Buscando definir uma estratégia para formulação, aplicação e análise dos resultados da survey, foram revisadas pesquisas com escopo semelhante, ou seja, que analisaram como o processo de desenvolvimento de software (cujos principais conceitos foram apresentados no capítulo 2) é efetivamente estruturado nas corporações. A pesquisa “Estado da Prática em Engenharia de Software”, publicada na revista IEEE Software Magazine em dezembro de 2003 (GLASS, 2003), apresenta uma extensa revisão sobre as práticas de desenvolvimento executadas de forma corrente em empresas de software que atuam em diferentes países. De maneira geral, cada artigo analisa práticas de desenvolvimento em um determinado
estágio do processo de desenvolvimento de software, e uma breve descrição destas iniciativas é apresentada a seguir:
• Cusumano et al. (2003) analisaram 104 projetos de software na Índia, Japão, Estados Unidos, Europa e Israel utilizando questionários enviados por correio aos participantes. A pesquisa constatou que os desenvolvedores aparentam elaborar mais linhas de código por dia quando possuem especificações funcionais completas e especificações detalhadas de arquitetura relacionam-se com menores índices de defeitos. Porém, estas situações são possíveis quando os requisitos são estabilizados, e para uma empresa de software, estabilizar os requisitos nos primeiros estágios do projeto pode inviabilizar a construção de produtos inovadores destinados a um mercado em constante evolução. A pesquisa constatou ainda que a utilização de protótipos e de versões beta cria oportunidades para que os clientes avaliem os resultados parciais do projeto, aprimorando seus objetivos futuros e resultando em menores taxas de defeitos; esta constatação permite explicar por que procedimentos ágeis, como, por exemplo, a XP, podem compensar as ineficiências decorrentes de especificações incompletas.
• Neil e Laplante (2003) elaboraram um questionário baseado na Web para avaliar práticas de gerenciamento de requisitos em empresas multinacionais. Os autores constataram que modelos formais raramente são utilizados, o modelo cascata ainda é bastante popular e técnicas orientadas a objeto não são comuns entre as empresas pesquisadas.
• Birk et al. (2003) analisaram linhas de produção de software em cinco organizações, e a pesquisa constatou que algumas práticas são mais comuns e difundidas entre as empresas participantes, mas as especificidades das linhas de produção de software dependem de fatores corporativos, tais como a estrutura de desenvolvimento da organização, as características dos produtos e os modelos de negócios adotados.
• Lethbridge et al. (2003) realizaram estudos para analisar as práticas de documentação mais comumente executadas pelos engenheiros de software. A pesquisa constatou que documentos sobre arquitetura e outras abstrações do
normalmente trazem orientações para a evolução do produto, que pode ser útil para os mantenedores do software. Freqüentemente a documentação está desatualizada, e alguns sistemas possuem excesso de documentação com pouca utilidade. Os padrões de documentação apresentados por referenciais como o CMMI ou o processo unificado são considerados demasiadamente detalhados, e sua implementação completa é capaz de gerar atrasos no cronograma e aumentar o custo do projeto.
• Ramesh et al. (2003) analisaram o desenvolvimento de diferentes aplicações baseadas na Web. A pesquisa constatou que o direcionador mais importante para o desenvolvimento de software para Internet é a velocidade, e as atividades de gerenciamento são significativamente diferentes para projetos desta categoria, pois não existe um início ou final claro para as atividades de desenvolvimento, que são realizadas continuamente. A manutenção de software é considerada como um pequeno ciclo de vida do software, e neste tipo de projeto, os desenvolvedores parecem ser menos substituíveis.