Pedro F. Carvalho Analista de Sistemas S. J. RIO PRETO

Transcrição

1 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, 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. Contexto dos Negócios 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 envolvidos (compradores, clientes, subcontratantes, órgãos reguladores etc.), mais provavelmente o projeto precisará produzir algum tipo de evidência formal, como documentos, relatórios e protótipos, em marcos importantes. Tamanho do Esforço para Desenvolvimento do Software

2 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. Grau de Inovação 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 está 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 deste tipo, afeta significativamente a configuração dinâmica: as fases de iniciação e de elaboração serão mais demoradas, podendo passar 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 é ciclo evolutivo de um sistema anterior, o gerenciamento das mudanças é uma questão mais importante e a incorporação de um código mais antigo 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. 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.

3 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. Tipo de Desenvolvimento Há vários tipos de desenvolvimento, como: O contrato de trabalho que consiste em desenvolver 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 (consulte Diretrizes: Classificação de Artefatos) pois o cliente, ou os representantes, desejam monitorar o desenvolvimento 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. O desenvolvimento especulativo consiste em desenvolver um produto para um mercado de 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. O desenvolvimento interno é o desenvolvimento de 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, onde normalmente não são desenvolvidos produtos. 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.

4 Problemas e Causas Originais 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: Implementação de um Processo em um Projeto. Nesse caso, você talvez precise identificar as causas originais dos problemas. Para eliminar os problemas, você se concentrará nas causas originais, melhorando o processo, introduzindo ferramentas que automatizem o processo e treinando funcionários. 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 - a organização tem 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 -geralmente, a organização é bastante otimista quanto à possibilidade de liberar um produto no prazo estimado. Deficiência de design - a organização atende aos requisitos, mas apresenta deficiência no design dos 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 incompatíveis, causando a perda do trabalho. Descoberta tardia dos problemas. Problemas que variam desde casos de uso até problemas de design. Exemplos de causas originais

5 Geralmente, um problema é um sintoma que indica que algo está errado. É necessário que as causas originais dos problemas sejam identificadas. Estes são exemplos de algumas causas originais 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 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. Consulte Conceitos: Implementação de um Processo em uma Organização para obter mais detalhes. 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. 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

6 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." "Processo significa produzir inúmeros 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, em primeiro lugar, ser considerado um "sistema de ajuda", que será usado para você procurar orientações, 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:

7 As pessoas confiam completamente no processo e acham que ele solucionará todos os problemas. O processo é considerado uma bala de prata ou uma fórmula mágica que, se for seguido, garantirá sucesso. A equipe envolvida no processo tem como objetivo passar um bom tempo se esforçando para adaptar o processo, sem avaliar primeiro os problemas, relacionados ao processo, que precisam de soluçã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. Complexidade Técnica e Gerencial Diferentes tipos de sistemas, e seus respectivos projetos, podem ser classificados em termos de complexidade técnica do sistema e de 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 complexidade gerencial e complexidade 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.