Visão Geral

O processo de desenvolvimento do software é influenciado pelos seguintes fatores:

• Fatores de domínio como, por exemplo, domínio do aplicativo, processo do negócio a ser suportado, comunidade de usuários e ofertas da concorrência.
• Fatores do ciclo de vida como, por exemplo, tempo de comercialização, expectativa da vida útil do software e releases futuros planejados.
• Fatores técnicos como, por exemplo, linguagem de programação, ferramentas de desenvolvimento, banco de dados, estruturas de componentes e sistemas de software existentes.
• Fatores organizacionais.

Esses fatores não têm a mesma importância. As seções a seguir descrevem alguns dos principais fatores, aqueles com mais probabilidade de afetarem a forma geral do processo de desenvolvimento e apresenta como são implementados o processo e as ferramentas na organização do desenvolvimento.

O contexto de negócios descreve o contexto no qual o software é desenvolvido. Há diferentes tipos de contextos de negócios que afetam como melhor personalizar o processo. Exemplos de contexto de negócios:

• Contrato de trabalho em que o desenvolvedor produz um software para uma determinada especificação do cliente e somente para esse cliente.
• Desenvolvimento especulativo ou comercial em que o desenvolvedor produz e cobre o custo de lançamento do software no mercado.
• Projetos internos em que o cliente e o desenvolvedor estão juntos na mesma organização.

Há várias situações intermediárias como, por exemplo, aquelas em que apenas parte do desenvolvimento do software é subcontratada, aquelas em que a dispersão geográfica representa um fator adicional etc. O número total de envolvidos distintos é um bom indicador do contexto de negócios.

O contexto de negócios afeta o nível de formalidade e a rigidez do processo. Quanto mais investidores - compradores, clientes, subcontratantes, órgãos reguladores e outros - envolvidos, mais provavelmente o projeto precisará produzir algum tipo de evidência formal, como documentos, relatórios e protótipos, nos principais marcos do projeto.

O Tamanho do Esforço de Desenvolvimento de Software

Refere-se à quantidade de esforço para desenvolvimento de software, conforme definido por algumas métricas, como Linhas de Código-Fonte (SLOC), Instruções de Origem Fornecidas ou Pontos de Função, número de pessoas-meses ou simplesmente o custo.

O tamanho do esforço afetará o nível de formalidade e a rigidez do processo. Quanto maior o projeto, maior a equipe de desenvolvimento e, independentemente do contexto de negócios, mais formalidade e visibilidade serão necessárias às diversas equipes e ao gerenciamento em termos de requisito, de interface e de indicador de desenvolvimento. Os problemas de comunicação decorrentes de grandes projetos se agravam ainda mais se as equipes estiverem dispersas geograficamente.

O grau de inovação baseia-se no que precedeu esse esforço de software em relação à organização do desenvolvimento e, principalmente, se o desenvolvimento estiver em um segundo ciclo ou em um ciclo subseqüente. Isso inclui a maturidade da organização e de seu processo, de seus recursos, de seu conjunto de capacidades atuais e de outras questões, como montagem e treinamento de uma equipe, aquisição de ferramentas e outros recursos.

O grau de inovação de um projeto afeta o processo de uma maneira completamente diferente. Um novo projeto, o primeiro de seu tipo, afeta significativamente a configuração dinâmica: as fases de iniciação e de elaboração serão mais demoradas, podendo estender-se por várias iterações. Uma ênfase maior também será dada na identificação e captura de requisitos, na modelagem de casos de uso, na arquitetura e na diminuição de riscos. Para um projeto que é um ciclo de evolução de um sistema anterior, o gerenciamento de mudanças é uma questão mais crítica e a incorporação de um código legado gera alguns desafios técnicos.

A inovação é relativa não só ao sistema em desenvolvimento, mas também ao amadurecimento das organizações funcionais, pois a introdução de novas técnicas ou de ferramentas afeta o processo. Em particular, a introdução do RUP (Rational Unified Process) propriamente dito em uma organização deve ser cuidadosamente dividida em passos. Uma organização apresentará uma certa inércia na adoção de um novo processo e a estratégia de adoção deverá considerar uma transição tranqüila das práticas existentes para as novas práticas.

Tipo de Aplicativo

Há diferentes tipos de aplicativos como, por exemplo, os sistemas incorporados em tempo real, os sistemas de informações distribuídos, os sistemas de telecomunicações, as ferramentas de Engenharia de Software Auxiliadas por Computador (CASE) e assim por diante. O tipo de aplicativo afetará o processo, principalmente em relação a restrições específicas, impostas pelo domínio no desenvolvimento, como restrições de segurança, desempenho, internacionalização, memória etc.

O tipo de aplicativo poderá afetar o processo se for um aplicativo de missão crítica; por exemplo, o sistema de controle de vôo de um avião. Um sistema de missão crítica geralmente requer um nível maior de formalidade, tanto para rastrear requisitos quanto para garantir a qualidade do produto. Esse tipo de aplicativo também requer o uso de mais recursos durante testes.

O tipo de desenvolvimento, ou domínio de destino, levanta algumas questões de processo como estas:

• Técnicas e ferramentas para suportar tarefas específicas; por exemplo, geração automática de código para máquinas de estado finito.
• Procedimentos de certificação; por exemplo, para instrumentação médica.
• Conformidade com padrões; por exemplo, para assuntos contábeis ou fiscais e para equipamento de telecomunicações.

Tipo de Desenvolvimento

Há vários tipos de desenvolvimento, como:

• Contrato de trabalho em que você desenvolve um produto para um cliente específico. Em um contrato de trabalho, é preciso gerenciar e negociar com um número maior de investidores. Há sempre a necessidade de produtos de trabalho externos formais, porque o cliente ou os representantes desejam monitorar o progresso e permanecer informados. Verifique se os produtos de trabalho revistos pelo cliente são fáceis de serem compreendidos. Algumas vezes, há necessidade de definir um marco que permita ao projeto oferecer um preço fixo para o restante do projeto. Nesse caso, você talvez precise incluir um novo marco ou ajustar os marcos existentes. Em outros casos, você talvez precise ajustar o modelo de ciclo de vida usado pelo cliente de acordo com os outros marcos e fases.
• Desenvolvimento especulativo em que você desenvolve um produto para um mercado em massa. Nesse desenvolvimento, um gerente de marketing (produto) dentro da própria organização age como cliente. Geralmente, no desenvolvimento especulativo, o tempo de comercialização é mais importante do que a funcionalidade e necessita de menos revisões formais.
• Desenvolvimento interno em que você desenvolve um produto que será liberado para outro departamento da empresa. Você talvez precise fazer um ajuste para outro modelo de ciclo de vida caso libere o produto para outro projeto que não utiliza o RUP. Pode ser aceitável uma descrição mais técnica dos produtos de trabalho, pois a maioria deles será revista por outros pares.
• Estudos prévios em que normalmente você não desenvolve um produto. A finalidade de um projeto de estudos prévios é descobrir se é possível criar um produto. Esse tipo de projeto não possui os mesmos marcos que um projeto normal.

Processo de Desenvolvimento Atual

Na maioria dos casos, não haverá substituição do processo de desenvolvimento de software em prática no momento na organização já que, geralmente, você implementará o novo processo de desenvolvimento passo a passo, concentrando-se primeiro nas áreas mais críticas e importantes. Alguns passos do processo de desenvolvimento de software poderão continuar existindo por algum tempo e, até mesmo, para sempre.

Problemas e Causas-Raiz

Quais problemas são identificados e priorizados para o projeto influenciará as áreas do processo nas quais você se concentrará, no início da implementação do processo. É importante observar que, se não houver nenhum método de trabalho estabelecido na organização, talvez não seja possível detectar os problemas. Consulte Conceito: Implementando um Processo em um Projeto. Nesse caso, você talvez precise identificar as causas-raiz dos problemas. Para eliminar os problemas, você se concentrará nas causas-raiz, aprimorando o processo, introduzindo ferramentas que automatizam o processo e treinando pessoas. 

Exemplos de problemas comuns

A seguir são apresentados exemplos de alguns problemas comuns:

• Incapacidade de gerenciar o escopo - geralmente a organização tenta fazer mais do que realmente faz no final.
• Incapacidade de capturar requisitos - dificuldade em especificar requisitos.
• Incapacidade de gerenciar mudanças em requisitos.
• Incapacidade de gerenciar requisitos - os requisitos não dizem respeito ao produto final.
• Incapacidade de fazer uma estimativa - otimismo excessivo sobre a capacidade de liberação no planejamento.
• Deficiência de design - atende aos requisitos, mas apresenta deficiência ao projetar os sistemas. Quais são os tipos de problemas de design que eles possuem? Os sistemas são difíceis de serem mantidos e aprimorados? Eles apresentam problemas de desempenho, de usabilidade, de capacidade etc.?
• Incapacidade de produzir produtos de qualidade - o produto possui muitos defeitos devido à falta de testes, mas, geralmente, isso também está relacionado a uma incapacidade de capturar e gerenciar requisitos, além de uma deficiência de design.
• Desempenho de software inaceitável.
• Baixa usabilidade.
• Desenvolvedores divergentes - há uma falta de controle sobre propriedade e gerenciamento da configuração, de modo que os desenvolvedores fazem alterações conflitantes, causando a perda do trabalho.
• Descoberta tardia de problemas. 
• Problemas que variam desde casos de uso até problemas de design.

Exemplos de causas originais

Geralmente, um problema é um sintoma que indica que algo está errado. É necessário que as causas originais dos problemas sejam identificadas. A seguir, estão exemplos de algumas causas-raiz comuns:  

• Gerenciamento de requisitos insuficiente
• Comunicação ambígua e imprecisa
• Arquiteturas deficientes
• Alta complexidade
• Inconsistências não detectadas em requisitos, designs e implementações
• Número insuficiente de testes
• Avaliação subjetiva do status do projeto
• Redução tardia de riscos devido a um desenvolvimento em cascata
• Propagação de mudança descontrolada
• Automação insuficiente
• Falta de método sistemático para a criação de interfaces de usuário
• Impossibilidade de passar dos casos de uso para o design

Fatores Organizacionais

Para implementar o processo em uma organização, vários fatores organizacionais devem ser considerados, tais como: a adaptabilidade da organização para mudanças, estrutura organizacional, cultura em organização e gerenciamento de projeto, competências e habilidades disponíveis, experiências anteriores e atitudes adotadas.

Os fatores organizacionais também afetam o modo de configuração do processo. Por exemplo, se as pessoas da organização tiverem seguido anteriormente uma descrição de processo de desenvolvimento de software, será mais fácil iniciar o uso do RUP. Por outro lado, se nenhuma descrição de processo de desenvolvimento de software tiver sido usada ainda, você poderá optar por limitar o escopo da descrição do processo. Você também poderá se esforçar ainda mais, no sentido de tornar a descrição do processo fácil de compreender e de utilizar, assegurando que ele inclua (ou referencie) as informações que fornecerão o mais importante valor.

Se o produto for um software "de prateleira", destinado a um mercado competitivo, pode ser necessário tornar o processo mais ágil, pois com um processo leve é maior a possibilidade de lançar em tempo reduzido, antes que os concorrentes o façam. Por outro lado, se o software é uma nova versão de um produto com grande base instalada, o processo deve se preocupar com a questão qualidade, pois os clientes não ficarão satisfeitos com um produto de qualidade inferior ao da versão anterior. Todas essas questões dependem obviamente da disposição da organização a correr riscos, e à sua competência em mudar seus processos de desenvolvimento de acordo com as necessidades.

Se algumas áreas forem novas para várias pessoas, ficará mais fácil fazer a transição se forem desenvolvidas diretrizes eficazes. Por exemplo, se a linguagem de programação for novidade para várias pessoas, será necessário desenvolver um Guia de Programação e um Guia de Design muito bons para auxiliar nesse aprendizado.

Atitudes

As atitudes negativas dos funcionários de uma organização como reação à mudança para uma nova tecnologia, para um novo processo ou para novas ferramentas são provavelmente a maior ameaça para a implementação bem-sucedida do processo e das ferramentas. Um excesso de entusiasmo em relação ao processo também pode ser considerado um problema, pois as pessoas podem acabar supervalorizando o processo.

Para avaliar as atitudes das pessoas em relação à nova tecnologia, ao novo processo e às novas ferramentas, faça perguntas do tipo:

• Quais são, para você, os benefícios da nova tecnologia? A nova tecnologia solucionará algum dos problemas atuais? Quais problemas você acha que surgirão com a nova tecnologia?
• Quais são, para você, os benefícios do novo processo? O novo processo solucionará algum dos problemas atuais? Quais problemas você acha que surgirão com o novo processo?
• Quais são, para você, os benefícios das novas ferramentas? As novas ferramentas solucionarão algum dos problemas atuais? Quais problemas você acha que surgirão com as novas ferramentas?

Para avaliar a motivação das pessoas, tente obter respostas a estas perguntas:

• Todas as pessoas da organização entendem por que a mudança é necessária?
• Todas as pessoas sabem como está sendo a ação da concorrência e como isso afeta os negócios?
• Todas as pessoas conhecem as alterações tecnológicas no segmento de mercado e sabem como elas afetam os negócios?  

Sinais de atitudes negativas podem incluir declarações como estas:

• "Processo não ajuda, atrapalha."
• "Processo significa produzir muitos documentos."
• "O processo é opressivo."

Algumas maneiras de lidar com essas atitudes negativas:

• Incentive as pessoas a indicar os problemas atuais.
• Explique que um processo não impõe o que deve ser feito. Ele deve, principalmente, ser considerado como um "sistema de ajuda", onde você procura orientações, definições e assim por diante.
• Explique que só serão usadas pequenas seções do processo. Ninguém consegue dominar todo o processo, e esse também não é o objetivo. Compare o processo a uma estante de livros, à qual você recorre quando precisa de informações.
• Demonstre um projeto-piloto bem-sucedido, apresentando o novo processo e mostrando o funcionamento das ferramentas. Inclua uma ou duas pessoas que não acreditam no projeto-piloto. 

Exemplos de sinais de excesso de entusiasmo:

• As pessoas confiam completamente no processo e acham que ele solucionará todos os problemas.
• O processo é a bala de prata ou fórmula mágica que, se seguida, garantirá sucesso.
• A equipe do projeto deseja gastar bastante tempo e esforço adaptando o processo, sem avaliar primeiro os problemas relacionados ao processo que precisam de resolução. 

Algumas maneiras de lidar com esse excesso de entusiasmo:

• Estabeleça as expectativas. O processo ajudará, mas não solucionará os problemas. As pessoas é que solucionarão os problemas.
• Converse com as pessoas sobre o tempo gasto adaptando o processo.
• Oriente as pessoas para que desenvolvam os produtos de software.

Tipos diferentes de sistemas, e seus projetos, podem ser classificados em termos da complexidade técnica do sistema e da complexidade gerencial. A figura a seguir ilustra um conceito de classificação de diferentes sistemas. Por exemplo, um típico aplicativo de planilha eletrônica sobre um pequeno negócio em geral não apresenta muita complexidade técnica, sendo fácil de ser gerenciado. O outro extremo seria um típico projeto de sistema de armamento, que geralmente é complexo não só do ponto de vista técnico, mas também do ponto de vista gerencial.

Em geral, quanto maior o tamanho do sistema, da duração do projeto ou do contexto de negócios, maior também será a complexidade gerencial. Quanto mais inovações, no domínio de problemas ou no espaço de soluções, maior a complexidade técnica. Existe uma interação entre as complexidades gerencial e técnica, vários grandes projetos também são tecnicamente complexos. Isso resulta em:

• Maior complexidade gerencial, resultando em mais formalismo, inclusive mais marcos e revisões formais, além de mais produtos de trabalho.
• Maior complexidade técnica, com a introdução de técnicas, funções e ferramentas específicas e, portanto, de mais tarefas.

Os sistemas são classificados em termos de complexidade técnica e gerencial