sexta-feira, 20 de abril de 2012

Ciclo de vida de sistemas


O ciclo de vida do projeto tradicional

 

O ciclo de vida do projeto tradicional é aquele que envolve pouca ou nenhuma utilização da tecnologia estruturada. Esta figura serviria também para descrever um ciclo de vida que envolvesse programação estruturada; mas a introdução de Projeto Estruturado e Análise Estruturada, causará modificação substancial. Normalmente, a fase de análise não é a primeira fase do projeto. Via de regra, ela é precedida por algum tipo de levantamento, ou Estudo de Viabilidade, cujos propósitos são:

·        Determinar se existe alguma nova maneira de se fazer o trabalho (novos procedimentos, novos dispositivos, novas áreas de trabalho) que justifique os gastos de projeto.

·        Documentar os parâmetros que iriam guiar tal projeto.

Nisto, o levantamento tenta definir o que será construído, produzir informações para orçamento e cronograma; é muito semelhante à fase da análise. De fato, o levantamento, na maior parte das empresas é uma fase de minianálise. Realiza todas as tarefas comumente associadas à fase de análise, mas não tão profundamente.

[...]

Dados reunidos, retirados através do diálogo com os usuários, constituem o principal insumo para o levantamento. Em geral, os resultados do levantamento são agregados em algo chamado de Documento de Viabilidade, ou Documento de Requisitos Técnicos, ou algum nome parecido. Este documento torna-se, então, uma das entradas-chave, para a fase de análise.

A fase de análise possui duas entradas principais: o Documento de Viabilidade e novamente o fluxo de informações dadas diretamente pelos usuários.Estas entradas são transformadas nas principais saídas da fase, o Documento Alvo (quase sempre referenciado como uma Especificação Funcional), orçamento, cronograma, e algum tipo de informação quanto aos requisitos físicos, que é necessário para o estudo do hardware.

O estudo de hardware tem insumos tanto de análise quanto de projeto preliminar, e os utiliza para utilizar um novo hardware, ou para planejar a expansão do hardware em uso, ou para avaliar o efeito do novo sistema na configuração corrente.

O principal produto da fase de análise, a Especificação Funcional, passa por um projeto preliminar, a primeira das duas fases do projeto. Outros nomes para esta fase incluem projeto de sistema, projeto externo ou projeto filosófico.

A fase do projeto preliminar utiliza a sua entrada, a Especificação Funcional, para resultar com a Especificação do Sistema. Isto geralmente envolve a seleção de módulos, o desenho de um fluxograma ou o equivalente, redigir algum tipo de narrativa sobre cada módulo, e talvez definir e esquematizar as áreas de dados e tabelas mais importantes. O plano de teste é geralmente formado nesta fase.

A especificação de Sistema passa então para a última fase, o projeto detalhado (ou projeto de programa). Nesta fase, o corajoso trabalho de projeto estará concluído. Isto geralmente envolve projeto interno de módulo, fluxograma, definição de dados, documentação de interface intermódulo etc. Os resultados do projeto detalhado levam à composição da especificação de programa, que passa então às fases de implementação.

As fases subseqüentes do ciclo de vida tradicional são, geralmente, codificação, teste de unidade, teste de subsistema, integração, teste de sistema, teste de aceitação e operação. Superposição ocorre com freqüência entre estas fases, apesar dos padrões da empresa, e não em razão deles - a maioria dos padrões exige uma progressão puramente linear das fases de implementação.

Tom Demarco tem apresentado a fase tradicional de análise, com se ela tivesse quatro saídas - o Documento Alvo, requisitos físicos, orçamento e cronograma, mas ela possui outras. Em particular, os pontos a seguir deveriam ser considerados legítimos subprodutos da fase de análise:

·        Uma configuração de equipamento experimental. Freqüentemente é necessário atingir um dimensionamento capaz de produzir a imagem do orçamento.

·        Um documento relativo ao desempenho. Pode ser necessário, para justificar nossas expectativas, sermos capazes de controlar a carga total necessária, dentro dos limites de gastos estabelecidos pelo orçamento.

·        Um projeto experimental. Algumas considerações de projeto são necessárias durante a fase de análise, como parte do teste contínuo de viabilidade, que deve prosseguir durante o processo de especificação. É razoável documentá-lo; não é razoável considerá-lo como uma relação de ligação com a abordagem de projeto.

·        Uma solicitação de Proposta (Request For Proposal - RFP ). Se o software for contratado externamente, a RFP é geralmente escrita durante a fase de análise.

·        Layouts de arquivos e dados. São, algumas vezes, necessários para justificarem gastos com equipamento junto ao orçamento.

·        Análise de recursos (por exemplo, dimensionamento de memória e disco). Pode ser necessária para estimativas orçamentais.

·        Informações de Planejamento de Projeto. Podem incluir Gráficos de Gantt, Gráficos Pert e produtos provisórios.

[...]

Fonte
MARCO, Tom de. Ciclo de vida de sistemas. Disponível em: <http://www.geocities.com/puc3ware/ciclo_de_vida_demarco.html>.

Nenhum comentário:

Postar um comentário