3 - documentos e modelo

Documentos típícos

Contrato de trabalho: Descrição preliminar das funcionalidades desejadas, geralmente produzidas pelo usuário.

Especificações dos requisitos de software: Descreve o que o software final irá fazer.

Modelo de objetos: Apresenta as classes e os objetos principais.

2Prof. Adelcio Marcos de Lima - FAP 2010


Cenários de casos de uso: Mostram a seqüência de possíveis comportamentos do ponto de vista do usuário.

Cronograma do projeto: Descreve a ordem das tarefas e as estimativas de tempo e esforço necessário.



Plano de teste de software: Descreve como o software será testado para garantir o comportamento apropriado.

Teste de aceitação: Testes elaborados pelo cliente para determinar a aceitação do programa.

Projeto de software: Descreve a estrutura do software



Projeto arquitetural: Estrutura do alto nível com as interconexões.

Projeto detalhado: Projeto de baixo nível dos módulos ou objetos.

Plano da garantia da qualidade: Descreve as atividades que serão desenvolvidas para garantir a qualidade.



Manual do usuário: Descreve como usar o software.

Código Fonte: O código do software.

Relatório de teste: Descreve como os testes foram feitos e como o sistema se comportou.



Relatório de Falhas: Descreve as insatisfações do cliente com os comportamentos específicos do sistema, geralmente falhas ou erros do mesmo.


Modelos de Ciclo de Vida

Tambem conhecidos como modelos de processo de desenvolvimento de software, são escolhidos baseado na natureza do projeto e aplicação, nos métodos e ferramentas a serem utilizados e nos controles e entregas requeridos.

Os quatro modelos mais comuns são: Modelo Linear Sequencial (Cascata) Modelo de Prototipagem (Evolucionário) Modelo Incremental Modelo Espiral (Melhorias Iterativas)


Modelos de Ciclo de Vida

Definido pela ISO/IEC 12207, como sendo um quadro que contem os processos, atividades e tarefas envolvidos no desenvolvimento, operação e manutenção de um produto de software, contemplando a vida do sistema desde a definição dos seus requisitos até ao fim da sua utilização.

São descritivos (para monitorar), mas também prescritivos (para planear)


Modelo Linear (cascata)

Seu diagrama parece com uma série de cascatas. Descrito por Royce em 1970, foi a primeira realização de uma seqüência padrão de tarefas.

Existem muitas versões deste modelo, onde uma ou outra tarefa podem estar descritas juntas.



Verificação no fim de cada fase para certificar-se que seus resultados são consistentes com as entradas e com os requisitos do sistema.

Requisitos do usuário são “congelados” antes do início do projeto.

Permite pouca interferência do usuário após este congelamento, pois retarda a fase de codificação.

Útil quando os requisitos são bem conhecidos antes do início do projeto.


Modelo linear (cascata)



Problemas do modelo linear sequêncial:

Projetos reais raramente seguem a ordem sequencial proposta e mudanças nessas propostas podem causar confusão na equipe de projeto.

É difícil para o usuário definir todos os requisitos explicitamente. O modelo requer esta definição e é difícil acomodar incertezas nos requisitos.

O cliente deve ter paciência. Uma versão do sistema só será disponibilizada no fim do projeto. Erros percebidos somente nesta fase podem se tornar um desastre.


Modelo de Prototipagem

Este modelo constrói uma versão descartável (protótipo).

Visa testar conceitos e requisitos e será usado para mostrar o comportamento do software para o cliente.

Permite ao cliente “perceber” o programa antes da sua real finalização.



Após concordância do cliente, o software final é desenvolvido, seguindo as mesmas fase do modelo linear.

Seu esforço no protótipo é compensado pelo não desenvolvimento de características desnecessárias.



Problemas do modelo de prototipagem:

O cliente vê o que parece ser uma versão que funciona do software. Apesar das grandes mudanças que devem ser feitas para que o software se torne um software completo e com qualidade, o cliente pode querer fazer “remendos” no protótipo para iniciar o uso.

Práticas não desejáveis de codificação podem ser utilizadas para a construção do protótipo e depois serem “esquecidas”, tornando-se a solução definitiva.


Modelos Evolucionários

A natureza evolucionária do software não é considerada explicitamente nem no modelo linear sequencial nem no de prototipagem.

Os modelos evolucionários são iterativos, ou seja, são caracterizados de maneira que permitem aos engenheiros de software, construções com versões cada vez mais completas do software.

Dois tipos deste modelo são: Incremental e Espiral.


Modelo Incremental

Combina elementos do modelo linear seqüencial (aplicado repetitivamente) com a filosofia iterativa do modelo de prototipagem.

O Objetivo era projetar e entregar ao cliente um conjunto mínimo do sistema que continuasse a ser um sistema usável.

A cada incremento o usuário pode utilizar o produto gerado ou fazer uma revisão detalhada.


Modelo Incremental

O próximo incremento deve implementar as solicitações do usuário, mais as novas funcionalidades planejadas.

O processo é repetido até o produto completo ser entregue.

Ex: Processador de texto Primeiro entregas as funções básicas de manipulação de arquivo. Depois, entregar as funcionalidades de produção e edição de

texto mais avançadas. No terceiro incremento, entregar verificação de grafia e

gramática. ...


Modelo Incremental


Modelo Incremental

O modelo incremental, como o de prototipagem, é iterativo. Mas diferentemente do de prototipagem, ele foca em entregar um produto operacional a cada incremento.


Modelo Espiral

Definido por Barry Boehm em 1988 no seu artigo: A Spiral Model of Software Development and Enhancement

É um modelo que acopla, assim como o incremental a natureza iterativa da prototipagem com os aspectos sistemáticos e controlados do modelo linear sequêncial.

O software é desenvolvido em uma série de “releases” incrementais: nas primeiras iterações podem ser apenas um modelo em papel ou um protótipo, nas últimas, versões cada vez mais complexas do software são produzidas.


Modelo Espiral

O modelo espiral é dividido em um número de atividades, chamadas regiões e tarefas. Tipicamente existem de 3 a 6 regiões.

Cada região possui um conjunto de tarefas, que são adaptadas às características do projeto a ser iniciado.

A espiral gira em sentido horário, iniciando do centro.

Não termina quando o software é entregue: pode ser adaptado até o fim do ciclo de vida do software.


Modelo Espiral


Modelo Espiral

Problemas do modelo Espiral:

Sua utilização por ser um pouco mais complexa, é apenas utilizado em grandes projetos.

O modelo não é usado na mesma extensão que os anteriores por isso, não foi “testado” o suficiente.


Trabalho (0 a 1 ponto) 1 - Para cada um dos seguintes documentos, indique a

fase do ciclo de vida do software em que são desenvolvidos: manual do usuário, projeto arquitetural, especificação dos requisitos de software, código fonte, plano de teste, documentações, relatório de testes, estimativa de custo, projeto detalhado, plano da garantia de qualidade do software, cronograma do projeto, contrato de trabalho e relatório de falhas.

2 - Ordene as seguintes tarefas em termos do modelo seqüencial linear (cascata): teste Beta, Entrega, Análise de Custos, Cronograma, Teste de unidade, Implementação, Projeto arquitetural, viabilidade, elucidação dos requisitos, Teste de aceitação, Projeto em baixo nível.


Trabalho (0 a 1 ponto) Resumo sobre o video, descrevendo os pontos

principais do analista de sistema das empresas de software.


3 - documentos e modelo

Documents