Visão Geral de Exemplos > 
Caso de Desenvolvimento de Projeto Pequeno > 
Artefatos
Caso de Desenvolvimento para Projetos Pequenos: Artefatos
Requisitos
|
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Visão |
Rational RequisitePro, Microsoft®Word |
Sim | |
| Solicitações dos Principais Envolvidos | Rational ClearQuest | As solicitações dos principais envolvidos são registradas e gerenciadas como Solicitações de Mudança do Rational ClearQuest. | Não |
| Modelo de Casos de Uso (Atores,Casos de Uso) | Rational Rose, Rational RequisitePro | Os atores e casos de uso importantes e identificados e os fluxos de eventos serão descritos apenas para os casos de uso mais críticos. As descrições serão capturadas como documentos do Word. |
Não (entretanto, o Relatório Sintético de Caso de Uso é um produto liberado) |
| Glossário | Rational RequisitePro | Sim | |
| Especificações Suplementares | Capturado como parte do documento Vision. | Sim | |
| Protótipo de Interface de Usuário | Não |
Os seguintes relatórios são gerados do Modelo de Casos de Uso.
| Relatório |
Ferramentas Usadas
|
Produtos Liberados Formais? |
| Relatório Sintético de Caso de Uso | Rational Soda | Sim |
Para obter detalhes sobre o fluxo de trabalho, consulte Visão Geral de Análise e Design.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Prova de Conceito Arquitetural, Protótipos | Os riscos do projeto serão abordados o mais cedo possível usando os protótipos arquiteturais executáveis. | Não | |
| Modelo de Design (e todos os artefatos constituintes) | Rational Rose | Espera-se que o Modelo de Design evolua ao longo de uma série de sessões de brainstorming. Nenhum Modelo de Análise separado é criado. O Modelo de Design só será mantido enquanto os desenvolvedores o considerarem útil. |
Não
|
| Modelo de Dados | Rational Rose | Não | |
| Documento de Arquitetura de Software | Rational Soda, Microsoft Word | Será capturada uma descrição da arquitetura que descreve brevemente os casos de uso significativos arquiteturalmente (visão de casos de uso), a identificação dos principais mecanismos e dos elementos de design (visão lógica) e a definição da visão do processo e da visão da implantação. | Sim |
Para obter detalhes, consulte Visão Geral da Implementação. Este projeto é tão pequeno que nenhuma integração de subsistema separado é realizada (os componentes são diretamente integrados ao sistema geral). O planejamento de integração de nível superior é descrito na programação do projeto. O planejamento de integração detalhado é realizado informalmente e quando necessário.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Modelo de Implementação (e todos os artefatos constituintes, incluindo Componentes e Builds) |
<ferramentas de desenvolvimento - compilador, depurador etc.>, Rational Rose, Rational Test Manager, Rational Test Factory, Rational Robot, Rational PureCoverage. |
O Rational Rose será usado para gerar o código do componente inicial. Os scripts dos Testes Unitários serão elaborados usando o Rational Robot e organizados em conjuntos usando o Rational Test Manager. Os scripts gerados pelo Rational Test Factory complementarão os testes gerados manualmente. O Rational PureCoverage será usado para ajudar a determinar se o teste do componente é adequado. |
Sim |
Para obter detalhes sobre o processo, consulte Visão Geral do Teste.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Plano de Teste | Microsoft Word | Não | |
| Script de Teste, Dados de Teste |
Rational QualityArchitect, Rational Test Factory, Rational Robot, Rational Quantify, Rational Purify,<ferramenta de banco de dados usada pelo aplicativo> |
Os dados de teste e os scripts de teste do componente de Interface do Usuário (UI) são criados com o Rational Robot e o Rational Test Factory. Os dados de teste e os scripts de teste de componentes não-UI são criados com o Rational QualityArchitect.
|
Não |
| Conjunto de Testes, Log de Testes | Rational Test Manager | O Rational Test Manager é usado para criar Conjuntos de Testes e executá-los para produzir Logs de Testes e relatórios. | Não |
| Lista de Idéias de Teste |
Microsoft Word | Serão basicamente aproveitados de projetos anteriores. | Não |
| Caso de Teste | Rational Test Manager | Não | |
| Sumário de Avaliação de Testes | Microsoft Word | Não | |
| Configuração do Ambiente de Teste | Microsoft Word |
Documentado informalmente. |
Não. |
Para obter detalhes sobre o processo, consulte Visão Geral da Implantação.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Produto (incluindo Unidade de Implantação e Artefatos de Instalação) | Sim | ||
| Material de Suporte para o Usuário (incluindo Notas de Release) | Estão incluídos na ajuda on-line. | Sim |
Para obter uma descrição geral do processo, consulte Visão Geral do Gerenciamento de Configuração e Mudança.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Solicitação de Mudança | Rational ClearQuest | Não | |
| Repositório do Projeto, Espaço de Trabalho | Rational ClearCase LT | Não |
Para obter detalhes, consulte Visão Geral do Gerenciamento de Projeto.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Caso de Negócio | Microsoft Word | O caso de negócio é produzido e aprovado pela administração da empresa. Não se espera que seja mantido. | Não |
| Plano de Desenvolvimento de Software (incluindo Lista de Riscos e Plano de Iteração) |
Microsoft Word, Microsoft Project |
As informações de programação e de recursos serão geradas como relatórios fora do Microsoft Project. | Não |
| Registro de Revisão | Microsoft Word | Isso é obrigatório e liberado apenas para as revisões do cliente. | Sim |
|
Avaliação da Iteração, Avaliação do Status
|
Microsoft Word, e-mail |
A Avaliação de Status pode ser combinada à Avaliação de Iteração porque as iterações são freqüentes (uma ou mais por mês). O Gerente de Projeto reúne-se com cada membro da equipe do projeto semanalmente para determinar o andamento e ajudar a identificar e resolver problemas. Ao fim de cada iteração, a equipe reúne-se para discutir o status do projeto e fazer um brainstorm das melhorias. A intenção é captar as lições aprendidas. Em seguida, uma revisão é realizada pelo Revisor do Projeto. |
Não |
O ambiente desse projeto já está configurado. O processo é avaliado a cada iteração, e as melhorias são implementadas da maneira apropriada.
| Artefato | Ferramentas Usadas | Comentários | Produtos Liberados Formais? |
| Caso de Desenvolvimento | [editor de HTML] | Esse Caso de Desenvolvimento do projeto foi criado pela menor adaptação do Caso de Desenvolvimento de Exemplo do RUP para Projetos Pequenos. | Não |
| Guia de Modelagem de Casos de Uso | Microsoft Word | Este projeto segue o Guia de Modelagem de Casos de Uso de Exemplo do RUP sem adaptação adicional. | Não |
| Microsoft Word |
O Guia de Programação do projeto já existe. É uma versão ligeiramente adaptada do exemplo fornecido no RUP. |
Não | |
| Guia de Design | Microsoft Word | O Guia de Design do projeto já existe (aproveitado de um projeto anterior semelhante). | Não |
| Guia de Teste |
Microsoft Word |
O Guia de Teste do projeto já existe (aproveitado de um projeto anterior semelhante). | Não |
| Guia de Interface do Usuário |
Microsoft Word |
O Guia de Interface do Usuário do projeto já existe (aproveitado de um projeto anterior semelhante). | Não |
|
Rational Unified Process |
