A análise conjunta de fatores críticos pode ser observada no trabalho de pesquisa de Soares (2007). Tais observações concluem que alguns fatores avaliados em conjunto sugerem a adoção de métodos como MDP, MA ou híbridos, mas que também alguns fatores são determinantes na escolha de um método e por conseqüência das práticas a serem utilizadas no desenvolvimento do software.
A seguir será relatada a análise do trabalho de Soares (2007) com relação à interferência entre fatores:
Competência Pessoal e Cultura
Com relação à avaliação conjunta de fatores Soares (2007) conclui que, o fator crítico Competência Pessoal pode influenciar o resultado do eixo do fator
Cultura no gráfico polar. Tal influência sugere que uma equipe constituída por um
percentual alto de profissionais, com níveis de habilidade 2 ou 3, pode potencializar uma cultura orientada pelo caos. Profissionais com estes níveis de competência possuem mais experiência para lidar com situações adversas (com e sem precedentes) e possuem conhecimento tácito significativo podendo tomar decisões sobre o desenvolvimento de projetos de software sem a necessidade de ter como suporte uma vasta documentação (Soares, 2007). A Figura 33 apresenta o gráfico da relação entre os dois fatores analisados.
Figura 33: Representação da interferência entre o fator Competência
Pessoal e o fator Cultura (Soares, 2007). Dinamismo e Cultura
Outra avaliação de análise conjunta de fatores pode ser observada a partir da co-relação entre os fatores Dinamismo e Cultura.
Para Soares (2007), o fator crítico Dinamismo pode influenciar o fator crítico
Cultura em contextos de desenvolvimento que apresentem um alto dinamismo. Uma
cultura orientada pela ordem ou com alto grau de formalismo pode não ser apropriada quando se está trabalhando em contextos de softwares com requisitos muito dinâmicos. No ambiente de cultura formal e burocrática as atividades destinadas à organização do desenvolvimento implicam em trabalho adicional quando ocorrem mudanças nos requisitos para melhor gerenciá-los, desta forma o dinamismo dos requisitos pode inviabilizar o trabalho burocrático proposto em empresas que estão voltadas a uma cultura de formalismo. Já uma cultura orientada pelo caos impõe menos sobrecarga quando essas mudanças ocorrem, permitindo que a equipe esteja mais preparada para lidar com mudanças constantes nos requisitos. A Figura 34 apresenta a relação entre os fatores Dinamismo e Cultura.
Figura 34: Representação da interferência entre o fator Dinamismo
e Cultura (Soares, 2007).
Por outro lado, uma conclusão apresentada no trabalho de pesquisa de Soares (2007) indica que alguns fatores isoladamente são determinantes na escolha e na redução de riscos de adoção de métodos de desenvolvimento de software. Por exemplo, o fator Criticalidade sugere fortemente a adoção de MDP, uma vez que os softwares com essas características são elaborados para serem utilizados em ambientes com riscos de vida ou alto nível de prejuízo financeiro. Desta forma, esses fatores necessitam de maior controle e gerência sobre os processos de desenvolvimento.
O fator Tamanho da equipe por sua vez induz a utilização de MDP, uma vez que requer maior controle sobre as atividades quando se está utilizando de um número maior de recursos humanos nas tarefas do desenvolvimento de software.
Uma equipe formada na sua maior por profissionais com nível de habilidade - 1 e 1B irá determinar o fator crítico Competência Pessoal e consequentemente inviabilizar a aplicação de MA, visto que esses métodos demandam uma maior quantidade de profissionais com nível de habilidade mais alto (Boehm e Turner, 2003).
Diante do exposto, é possível justificar a partir da análise dos gráficos das empresas DPI-03 e DPI-04 a utilização de boas práticas da taxonomia proposta nesse trabalho de pesquisa. Apesar de ser uma abordagem superficial e inicial, a aplicação dos questionários, o desenho gráfico e sua análise, podem fazer parte da primeira melhor prática de desenvolvimento de software sugerido na taxonomia que é o
Diagnóstico Inicial da empresa proposto no Processo de Verificação da Qualidade
A avaliação preliminar do gráfico polar da empresa DPI-03 pode conduzir fortemente para uma análise correlacionada ao concluído por Soares et al. (2008) na relação dos fatores Competência Pessoal e Cultura, uma vez que no gráfico polar da empresa pode-se observar as linhas dos eixos Competência Pessoal e Cultura voltadas ao centro sugerindo a adoção de boas práticas voltadas a MA. Mas, conforme já discutido na análise da empresa os fatores Dinamismo e Criticalidade sugerem uma empresa com características propícias à adoção de soluções de MDP. Principalmente, o fator disposto no eixo Criticalidade, onde o alto risco de prejuízo financeiro sugere uma abordagem de um método mais controlado e detalhado. Ou seja, quanto maior a organização, documentação e o controle sobre os requisitos ao longo do processo de desenvolvimento do software, maiores serão as chances de sucesso de qualidade e produtividade para essa empresa.
Diante de um contexto voltado a MDP e do fator Criticalidade sendo preponderante na influência de outros fatores de risco, é importante que a empresa DPI-03 adote elementos da taxonomia que a auxiliem na organização de fatores preliminares no desenvolvimento de software, como é o caso dos elementos sugeridos na taxonomia nos processos de Gerência de Escopo. Por exemplo, a elaboração inicial, organização e atualização de uma lista de requisitos, e a adoção de
Matrizes de Rastreabilidade irão influenciar fortemente na qualidade do
entendimento dos requisitos gerados e consequentemente sua implementação.
Com a adoção de uma lista de requisitos, para esclarecer e dar uma visão ampla a respeito das funcionalidades do software; e também as matrizes de rastreabilidade, para indicar a interdependência entre os requisitos; é importante que a empresa DPI-03 adote elementos da Gerência de Casos de Uso com a documentação constando de diagramas e descrição de casos de uso para formalizar ações, regras e atores que irão compor as funcionalidades do software em questão. Outros elementos podem ser fortemente recomendados, como por exemplo, os elementos que compõem o Processo de Desenvolvimento Iterativo na Transição /
Integração e Testes. Tais elementos são recomendados para maior planejamento e
execução de testes, como também o controle de aceite do usuário e o registro de ocorrências de erros e melhorias.
Com isso, entende-se que a empresa DPI-03 deve iniciar um processo organizado de documentação dos requisitos envolvidos no software minimizando o risco de criticalidade com relação a prejuízos financeiros.
Cabe uma avaliação da taxonomia para cada caso, estudada pelo gestor de desenvolvimento, para que sejam aplicadas de forma correta após o diagnóstico inicial.
A empresa DPI-04 sendo avaliada isoladamente no seu fator de risco Cultura, estaria induzida à adoção de boas práticas de MA, o mesmo resultando se fosse avaliada apenas pela análise do eixo Dinamismo. Porém a análise conjunta dos eixos
Dinamismo e Cultura sugerem a adoção de práticas de MDP, uma vez que o desenho
do gráfico do eixo Cultura sugere uma equipe ainda em formação. Outro fator que pode ser acrescentado na análise conjunta de eixos é o fator Competência Pessoal, que pelo desenho gráfico pode-se observar uma equipe ainda imatura de conhecimentos que possa obter sucesso com a adoção de práticas originadas de MAs.
Assim como a empresa DPI-03, é fortemente recomendado à DPI-04 buscar na taxonomia de boas práticas elementos que a auxilie na condução do desenvolvimento de software com base em práticas organizadas e formais, ou seja, práticas de MDP. Por apresentar uma equipe com pouca experiência, as práticas iniciais de MDP, além de fomentar a organização da empresa com relação aos processos de software, poderá também auxiliar na formação e na cultura da equipe com relação às práticas organizadas de desenvolvimento de software.
As práticas sugeridas para a empresa DPI-04 perpassam pela adoção de elementos da taxonomia do Processo de Desenvolvimento Iterativo, onde a empresa poderá praticar a elaboração formal de documentos iniciais de escopo e avaliação de esforço, vistos na taxonomia como elementos gerados no item Concepção/Requisito. Passando por práticas de planejamento de cronograma inicial encontrados na taxonomia no Processo de Verificação de Qualidade no item Gerência de Tempo. Bem como, a adoção de elementos da Gestão de Configuração e Mudança de
Escopo, com práticas de documentação das alterações de escopo solicitadas pelo
usuário e que estão representados na taxonomia no item Definição de Documentos de
Alteração de Escopo.
Com isso, a empresa DPI-04, de forma simples, poderá utilizar um conjunto pequeno de elementos da taxonomia que irá auxiliá-la na obtenção de um fluxo organizado de trabalho de forma a influenciar fortemente na prestação de serviços de software de qualidade.
A visão de dois mini processos ilustrativos contendo elementos da taxonomia sugeridos para representar as explicações acima para o caso da empresa DPI-04 podem ser vistos conforme o sugerido nas Figura 35 e 36.
As duas representações gráficas dos processos não foram baseadas ou inferidas com base no gráfico polar, mas foram desenhadas com base na experiência profissional do autor do trabalho e servem como um exemplo de possíveis processos que podem ser construídos levando-se em consideração ou mesmo, incluindo elementos da taxonomia proposta. As representações não pretendem esgotar todos os processos possíveis com relação ao desenvolvimento de software, mas servem como exemplo para ilustrar a construção de uma proposta de mini processo aderente a realidade de uma MPE.
A Figura 35 apresenta um fluxo inicial da concepção de um projeto de software envolvendo elementos da taxonomia para a elaboração de documento inicial de escopo e esforço, além da geração do cronograma de atividades. Esse fluxo poderá auxiliar a empresa DPI-04 na organização inicial do projeto e na formalização das requisições do Cliente. Os elementos da taxonomia podem ser identificados no fluxo a partir das setas tracejadas.
Figura 35: Fluxo de atividades iniciais de projeto baseado na notação SPEM (OMG, 2002).
A Figura 36 apresenta um fluxo de solicitação de alterações de requisitos de software por parte do Cliente e um grupo de atividades do Analista de Sistemas para avaliar o impacto dessas solicitações e a sua formalização, documentação e replanejamento do cronograma de prazos de entrega das atividades diante das novas solicitações. Os elementos da taxonomia podem ser identificados no fluxo a partir das setas tracejadas.
Figura 36: Fluxo de atividades de alteração de escopo baseado na notação SPEM (OMG, 2002).
Apesar dos dois processos desenhados para as empresas da pesquisa e da identificação de elementos da taxonomia de boas práticas que pudessem ser aplicados e utilizados pelas empresas na busca de melhoria de qualidade no desenvolvimento de software, os dois processos não foram implantados ou praticados pelas empresas.