Diretrizes: Discriminadores do Processo
Tópicos
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, frameworks 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, ou seja,
aqueles com mais probabilidade de afetar a forma geral do caso de desenvolvimento,
e apresenta como são implementados o processo e as ferramentas na organização
do desenvolvimento.
Há diferentes tipos de contexto de negócios que afetam o modo de configuração do processo de forma mais apropriada.
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 dos negócios.
O contexto dos 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.
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 dos 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.
No caso de
um projeto que é um ciclo evolutivo de um sistema anterior,
o gerenciamento de mudanças é uma questão mais importante 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 Rational Unified Process (RUP) 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; além disso, o caso de desenvolvimento deverá considerar uma transição tranqüila das práticas existentes para as novas práticas.
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 atividades 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.
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 envolvidos.
Geralmente, são necessários artefatos externos mais formais porque o cliente ou os representantes desejam
monitorar o progresso e permanecer informados. Verifique se os artefatos 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.
É permitida uma descrição mais técnica dos artefatos 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.
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.
Um aspecto importante para compreender uma organização de desenvolvimento de software é entender os problemas que ocorrem no processo existente de desenvolvimento de software.
Isso 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 Conceitos: 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 mudanças
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
Para implementar o processo em uma organização, vários fatores organizacionais devem ser considerados como, por exemplo, estrutura organizacional, experiência 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ê poderá se esforçar ainda mais no sentido de facilitar a compreensão e a utilização do caso de desenvolvimento, verificando se ele remete exatamente às partes no RUP que terão mais utilidade.
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.
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 mudanças tecnológicas na indústria e sabem
como elas afetam os negócios?
Sinais de atitudes negativas podem incluir declarações como estas:
- "O processo não ajuda, ele prejudica."
- "Processar significar produzir muitos documentos."
- "O processo é cumulativo."
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,
em primeiro lugar, ser considerado um "sistema de ajuda", que será
utilizado para você procurar diretrizes, definições etc.
- 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 dos 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 formalidade, inclusive mais marcos e revisões formais, além de mais artefatos.
- Maior complexidade técnica, com a introdução de técnicas, papéis e ferramentas específicas e, portanto, de mais atividades.

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