• Nenhum resultado encontrado

Gestão de Alterações

No documento UML, Metodologias e Ferramentas CASE (páginas 72-76)

Em qualquer projecto de sistemas de informação, é fundamental que estejam previstos mecanismos de controle das alterações num processo em curso, já que tal como dizia o filósofo grego Heraclito, "a única certeza é a mudança permanente". A capacidade de monitoriza- ção das alterações e do seu impacto no sistema dá ao gestor do projecto o meio para avaliar e controlar a qualidade do mesmo. Áreas que apresentam alterações frequentes e imprevisíveis são normalmente consideradas áreas de risco e indiciam que a tarefa de análise foi re- alizada deficientemente.

CAPÍTULO 2 – O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

4 7

2.5.2 Planeamento

Alguns autores não consideram o Planeamento como uma tarefa integrante do processo de desenvolvimento de software, incluindo as actividades por nós identificadas e englobadas nesta tarefa num âmbito de um planeamento global e estratégico dos sistemas informação da organização, e portanto não se enquadrando no âmbito da Engenharia de Software. Outros consideram-na como uma das tarefas horizontais e permanentes ao longo do processo, fazendo parte da tarefa de gestão de projectos. De facto, muitas das actividades e técnicas aplicáveis a esta tarefa são típicos de qualquer gestão de projectos.

Neste livro, nós consideramos uma tarefa de planeamento logo no início do processo, não só para apresentar a perspectiva mais abrangente, mas sobretudo porque é necessário ter uma visão global sobre o âmbito do trabalho a realizar de modo a elaborar um planeamento e a efectuar uma análise de viabilidade do projecto. Este tipo de abordagem pode significar que, a partir de um problema manifestado por um cliente, seja detectada a necessidade de desencadear vários projectos. A nossa perspectiva é que só temos um projecto depois do seu plano estar apro- vado, e é esse o principal objectivo desta tarefa.

Existem ainda várias circunstâncias particulares em que esta tarefa deve ser realizada, por exemplo:

§ Num projecto que envolve a selecção de entidades para posterior implementação do software, a elaboração de cadernos de encargos e a avaliação de propostas pode ser englobada nesta tarefa.

§ Pode significar apenas uma investigação inicial, com recolha de informação suficiente sobre o problema ou oportunidade de modo a determinar se a situação actual justifica o desenvolvimento de uma solução suportada por um sistema de informação.

A grande preocupação desta fase é que a partir de um levantamento de alto nível das necessidades do negócio seja possível elaborar um plano do projecto a executar nas fases subsequentes, com identificação de actividades, recursos, prazos e custos. Para isso, existem um conjunto de actividades que deverão ser realizadas, designadamente:

§ Identificar e envolver todos interessados e afectados pela introdução do sistema.

§ Obter uma visão de alto nível do funcionamento do sistema actual, caso ele exista.

§ Definir o âmbito do sistema.

§ Elaborar uma descrição de alto nível do problema. § Identificar restrições, problemas e riscos do projecto.

§ Identificar alternativas de implementação, proceder à sua avaliação e selecção.

§ Apresentar resultados e recomendações, com justificação técnica, funcional e financeira.

§ Elaborar e obter aprovação de um plano de projecto. § Definir o processo de controlo do projecto.

Como se constata desta lista (não exaustiva) de actividades a realizar, muitas são actividades que qualquer gestor de projectos (independente- mente da área do conhecimento humano em que trabalhe) deve saber executar. Por isso, também a maioria das técnicas a utilizar não são específicas dos sistemas de informação, mas comuns à área de gestão, tais como: análise financeira de custos e/ou benefícios; elaboração de estimativas; elaboração de planos de projectos (identificação de tarefas, elaboração de diagramas Pert e/ou Gantt); identificação de riscos e medidas de os controlar; elaboração de árvores ou tabelas de decisão; aplicação de técnicas de modelação de processos.

No final da tarefa, e como consta da lista de actividades, deverá ser obtida a aprovação para continuar com o projecto, sendo fundamental que esta concordância seja obtida de todos os interessados no projecto, em particular, do patrocinador do mesmo (o cliente/utilizador que tem mais interesse na resolução do problema e/ou que despoletou todo o processo), pela área de informática e muitas vezes (em função do volume de investimentos ou das políticas internas estabelecidas) por orgãos superiores da organização.

CAPÍTULO 2 – O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

4 9

1 - Introdução (Âmbito e propósito do documento, Objectivos do projecto, Funções mais relevantes, Questões de performance, Restrições técnicas e de gestão)

2 - Contexto do projecto (Visão estratégica do negócio, Descrição de funções) 3 - Especificações de alto nível dos requisitos

4 - Estimativas do projecto (Dados históricos utilizados nas estimativas, Técnicas de estimação)

5 - Riscos do projecto (Análise de risco: Identificação, Estimação, Avaliação; Gestão do risco: Opções para evitar risco, Procedimentos de monitorização dos riscos)

6 - Recursos do projecto (Pessoas - Estrutura da equipa, Hardware e Software, Outros) 7 - Calendarização (Work breakdown structure, Diagramas de Pert e de Gantt)

8 - Mecanismos de acompanhamento e controle 9 - Análise custos / beneficios

10 - Análise de alternativas

O principal output desta tarefa será um plano de projecto (ver exemplo acima), que deverá reflectir sustentadamente a visão que se tem nesta fase do processo sobre as actividades a desenvolver futuramente, quer seja relativamente à sua inventariação, recursos, prazos e custos envolvidos, como também em relação aos benefícios potenciais que o sistema apresentará no futuro para toda a organização.

2.5.3 Análise

A tarefa de análise efectua o estudo detalhado do domínio do problema, e culmina na elaboração de um documento onde os requisitos funcio- nais da solução a implementar e outras questões relevantes (por exem- plo, restrições, âmbito, fluxos de informação) são enumerados. Tem normalmente dois grandes momentos ou sub-tarefas (que tipicamente são realizados em simultâneo):

No documento UML, Metodologias e Ferramentas CASE (páginas 72-76)