Portal da Informática e Educação
Fábrica de Softwares
Definição de Processo de Desenvolvimento de Software ________________________________________________________________________________________________________________________________________________
Caso de Desenvolvimento
Versão 2.0
Título do Projeto Número Projetos Acadêmicos 01/2008
Gerente do Projeto Cleuber Fernandes
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 2 de 19
Histórico da Revisão Data Versão Descrição Autor
23/09/2004 1.0 Este documento deve ser utilizado como guia do que deve ser desenvolvido e produzido pelo trabalho acadêmico das turmas de Engenharia de Software II.
Cleuber Fernandes
15/11/2004 2.0 Foi incluído o detalhamento de fluxo de trabalho para a disciplina Análise e Projeto.
Cleuber Fernandes
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 3 de 19
Índice Analítico 1. Introdução 4
1.1 Finalidade 4 1.2 Visão Geral 4
2. Visão Geral do Caso de Desenvolvimento 4 2.1 Modelo de Ciclo de Vida 4 2.2 Disciplinas 5 2.3 Configuração de Disciplinas 6
2.3.1 Fluxo de Trabalho 6 2.3.2 Artefatos 6
2.4 Classificação de Artefatos 7 2.5 Procedimentos de Revisão 7 2.6 Planos de Iteração de Exemplo 7
2.6.1 Fase de Iniciação 7 2.6.2 Fase de Elaboração 7 2.6.3 Fase de Construção 8
3. Disciplinas 8 3.1 Requisitos 8
3.1.1 Fluxo de Trabalho 8 3.1.2 Artefatos 12 3.1.3 Relatórios 13
4. Papéis 18
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 4 de 19
1. Introdução
1.1 Finalidade
Este documento visa adaptar o processo RUP ao projeto específico desenvolvido pelos alunos da disciplina de ES II da UNIP. Esta adaptação pretende identificar as fases, disciplinas, papéis, atividades e artefatos essenciais para garantir a elaboração de um processo de software customizado que garanta a qualidade do produto final.
1.2 Visão Geral
A seção 2 deste documento apresenta uma descrição do Modelo de Ciclo de Vida do processo Unificado e as disciplinas que serão utilizadas no desenvolvimento dos Projetos Acadêmicos. A seção 2 também explica como será mostrada a configuração de cada disciplina na seção 3.
2. Visão Geral do Caso de Desenvolvimento
2.1 Modelo de Ciclo de Vida
O Ciclo de Vida será composto pelas fases de Concepção, Elaboração e parte da fase de Construção, não sendo necessária a fase Transição. Isto se justifica pela limitação de tempo durante o semestre letivo, levando a empregar o tempo disponível às fases que produzirão artefatos em nível de compreensão do negócio, análise e projeto do sistema.
Fases Resumo Marcos
Concepção A fase de Concepção desenvolverá uma visão geral e os requisitos do produto. Os principais casos de uso serão desenvolvidos. Será gerada uma lista dos principais riscos, bem como um plano de iteração para a próxima fase. No final da fase de Concepção, será decidido se o projeto será levado adiante.
No fim na fase de Concepção está o Marco dos Objetivos do
Ciclo de Vida. Os seguintes itens devem ser revisados para verificar se este Marco foi alcançado ou não:
1. Consentimento dos envolvidos sobre a definição do objetivo e escopo do produto. 2. Consenso de que o conjunto correto de requisitos foi capturado e de que existe uma compreensão compartilhada desses requisitos. 3. Consenso de que as prioridades, os riscos e o processo de desenvolvimento são adequados. 4. Todos os riscos foram identificados e existe uma estratégia atenuante para cada um.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 5 de 19
Elaboração A Fase de Elaboração analisará os requisitos e desenvolverá o protótipo de arquitetura. Após concluir a Fase de Elaboração, todos os casos de uso selecionados para o Release 1.0 terão análise e design completos. Além disso, os casos de uso de alto risco do Release 2.0 já estarão analisados e projetados. O protótipo de arquitetura testará a viabilidade e o desempenho da arquitetura necessários para o Release 1.0.
No fim na fase de Elaboração está o Marco da Arquitetura do Ciclo de Vida. Nesse momento, os objetivos e o escopo detalhados do sistema, a opção de arquitetura e a resolução dos principais riscos devem ser examinados. O Marco de Protótipo de Arquitetura indica o final da Fase de Elaboração. Este protótipo representa a verificação dos principais componentes da arquitetura que compõem o Release 1.0. 1. A Visão e os requisitos do produto são estáveis. 2. A arquitetura é estável. 3. As abordagens principais a serem usadas no teste e na avaliação foram comprovadas. 4. O teste e a avaliação de protótipos executáveis demonstraram que os principais elementos de risco foram tratados e resolvidos com credibilidade. 5. Os planos de iteração para a fase de construção têm detalhes e fidelidade suficientes para permitir o avanço do trabalho.
Construção Durante a Fase de Construção, os casos de uso restantes serão analisados e projetados. Os projetos de componentes e banco de dados serão refinados e concluídos. Não haverá implementação, e conseqüentemente não haverá testes alfa, por limitação de tempo. Nesta fase os artefatos de projeto serão refinados e concluídos.
No fim na fase de Construção está o Marco da Capacidade
Operacional Inicial do Ciclo de Vida. Se todas as atividades previstas para esta fase fossem realizadas, o produto estaria pronto para ser passado para a Equipe de Transição. Toda a funcionalidade já teria sido desenvolvida e todos os testes alfa teriam sido concluídos. Além do software, um manual do usuário seria desenvolvido, e existiria uma descrição do release atual. No entanto, para este projeto a fase de Construção apenas finalizará os artefatos de projeto. Sendo assim, deverão ser revisados apenas:
1. O modelo de design atualizado com todos os elementos de design necessários e em nível de detalhamento suficiente para suportar a implementação funcional.
2. O modelo de dados normalizado e atualizado com todos os elementos necessários para suportar a implementação persistente (por exemplo, tabelas, índices, etc).
2.2 Disciplinas
Neste projeto serão empregadas as disciplinas abaixo, que se justifica por serem responsáveis por produzir artefatos de compreensão, análise e projeto do sistema.
- Requisitos
- Análise e Design
- Teste
- Gerenciamento de Projeto
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 6 de 19
Por limitação de tempo, neste projeto nenhum componente será implementado, o que justifica a não utilização das disciplinas Implementação e Implantação por que objetivam a codificação dos componentes do sistema e a colocação do sistema em produção, bem como a realização de testes de unidade, de integração e homologação.
2.3 Configuração de Disciplinas
A finalidade desta seção é explicar como funciona a configuração de disciplinas. Isso inclui uma explicação da finalidade das diversas tabelas e de cada seção que descreve as várias disciplinas listadas na seção intitulada Disciplinas.
2.3.1 Fluxo de Trabalho
Esta seção detalha todas as mudanças feitas na estrutura do fluxo do trabalho de cada disciplina. As mudanças usuais incluem a retirada de atividades do fluxo de trabalho que não se aplicam a este projeto.
2.3.2 Artefatos
Usando um formato tabular, esta seção descreve como o artefato será usado.
Como Usar Artefatos
Inic Elab Const Trans
Detalhes da
Revisão
Ferramentas
Usadas
Templates/
Exemplos
2.3.2.1 Explicação da tabela
Nome da Coluna Finalidade Conteúdo/Comentários
Artefatos O nome do artefato Uma referência ao artefato no RUP ou à definição de um artefato local mantida como parte do caso de desenvolvimento.
Como Usar Explique como o artefato é usado no ciclo de vida
Para cada fase, decida entre Necessário, Recomendável, Possível ou Desnecessário.
Detalhes da Revisão Defina o nível de revisão e os procedimentos de revisão a serem aplicados ao artefato
Determine o nível de revisão: Formal-Externo, Formal-Interno, Informal, Nenhum.
Ferramentas Usadas Definição das ferramentas usadas para produzir o artefato
Referências aos detalhes das ferramentas utilizadas para desenvolver e manter este artefato.
Templates/Exemplos Os templates a serem utilizados e exemplos de artefatos que usam os templates
Referências aos templates e exemplos. Podem ser feitas referências a templates e exemplos do RUP ou a templates e exemplos locais. Esta coluna também pode conter referências a artefatos reais que oferecem ajuda adicional aos membros do projeto.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 7 de 19
2.4 Classificação de Artefatos
Um artefato é um produto liberado do processo. Geralmente, ele é desenvolvido dentro de uma disciplina. Os artefatos são organizados na disciplina em que são criados. Para descrever como um artefato deve ser utilizado, use o seguinte esquema de classificação:
• (N) Necessário: Você precisa usar este artefato. É um artefato importante e, se ele não for produzido, futuramente pode causar problemas no desenvolvimento.
• (R) Recomendável: Você deve ter este artefato, se for possível, mas isso é negociável. Se não produzir este artefato, você deve ser capaz de justificar por quê.
• (P) Possível: Significa que este artefato não precisa ser produzido. Ele só é produzido se agregar valor e se houver tempo suficiente.
• (D) Desnecessário: Isso significa que você não usará este artefato. Isso pode ocorrer onde um artefato do Rational Unified Process é substituído por um artefato local.
2.5 Procedimentos de Revisão
O RUP propõe quatro níveis de revisão de artefatos: • (FE) Formal-Externo: Este artefato faz parte da liberação em um marco específico e requer alguma forma
de aprovação pelo cliente, pelo patrocinador ou por algum outro envolvido externo. Como exemplo, os artefatos de visão do negócio e modelo de caso de uso precisam ser revisados por cliente/usuários.
• (FI) Formal-Interno: Este artefato é formalmente revisto internamente pelo projeto. Por exemplo, os artefatos modelo de dados e modelo de projeto precisam ser revisados por membros da equipe do projeto.
• (I) Informal: Este artefato é revisto, mas não é aprovado formalmente. Projetar classes e projetar componentes são exemplos típicos de artefatos que não são revistos formalmente. Ainda assim alguém, talvez um colega, o revisará.
• (N) Nenhum: Este artefato não precisa ser revisado ou aprovado. Normalmente uma informação de trabalho que será descartado quando o projeto for concluído.
Este projeto usará apenas o nível de revisão Formal-Interno. Apesar de alguns artefatos serem de interesse dos
envolvidos externos, não temos disponibilidade destes envolvidos para realizar esta revisão. Dessa forma, todos os artefatos serão revisados pelos membros da equipe do projeto.
2.6 Planos de Iteração de Exemplo
Nesta seção encontram-se definidas as iterações de cada fase do processo. Cada iteração possui um plano como referência.
2.6.1 Fase de Iniciação
Iteração Preliminar ou Iteração I1: Ver referência “Plano de Iteração Preliminar”.
2.6.2 Fase de Elaboração
Em princípio, a fase de Elaboração terá apenas uma iteração. Contudo esta definição pode mudar e mais iterações poderão ser necessárias.
Iteração E2: Ver referência “Plano de Iteração E2”.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 8 de 19
2.6.3 Fase de Construção
A fase de Construção terá somente uma iteração, uma vez que não haverá implementação e testes de produtos executáveis. Esta iteração tem como objetivo apenas refinar e concluir alguns artefatos de projeto.
Iteração C3: Ver referência “Plano de Iteração C3”.
3. Disciplinas Esta seção apresenta as disciplinas do Processo Unificado que serão utilizadas na realização dos Projetos
Acadêmicos. Para cada disciplina há uma descrição do fluxo de trabalho para a realização da mesma e também uma tabela mostrando quais artefatos serão desenvolvidos para a disciplina.
É importante lembrar que o RUP não está sendo utilizado por completo para a realização destes projetos. O Engenheiro de Processo é o responsável por identificar quais artefatos são essenciais para o desenvolvimento dos projetos.
3.1 Requisitos
3.1.1 Fluxo de Trabalho
Analisar o
Problema
Compreender as Necessidades dos Envolvidos
Problema Incorreto
Definir o
Sistema
Problema Correto
Gerenciar o Escopo
do Sistema
Refinar Definição do
Sistema
Trabalhar no Escopo
Escopo Muito Grande
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 9 de 19
Detalhamento do fluxo de trabalho “Analisar o problema”
Este fluxo de trabalho visa estabelecer acordo sobre o problema a ser resolvido, identificar os envolvidos, definir as fronteiras do sistema (o que é e o que não é escopo do sistema) e identificar restrições impostas ao sistema.
Cliente
Usuário
Analista de
Sistemas
Glossário
Capturar um
Vocabulário
Comum
LocalizarAtores
DesenvolverVisão
Solicitaçõesdos envolvidos
Visão
Modelo Caso de Uso(somente atores)
Pode-se utilizar a técnica brainstorming para identificar e definir as características do problema, as necessidades e
restrições. A atividade de brainstorming implica que todas as pessoas da sala do workshop se dediquem durante um curto período de tempo, digamos 15 minutos, a expressar tudo o que acham importante para o projeto. Depois disso, um facilitador conduzirá o grupo durante a organização e priorização dos resultados. As regras de brainstorming são as seguintes:
- Começar definindo claramente o objetivo da sessão de brainstorming. - Gerar o maior número possível de idéias. - Deixar a imaginação fluir. - Não permitir críticas ou debates durante a reunião de informações. - Depois da reunião das informações, transformar e combinar as idéias.
A reunião das informações normalmente é muito informal. As idéias são expressas para o facilitador, que as anota em folhas de blocos de anotações. As informações são então "podadas" para que as idéias semelhantes sejam combinadas e as idéias inadequadas sejam eliminadas. Todos devem priorizar cada idéia por categoria (por exemplo, muito importante, importante e desejável), com pesos atribuídos a elas (por exemplo, 3, 2, 1). A soma das prioridades de cada idéia identificará a sua importância em relação às outras.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 10 de 19
Detalhamento do fluxo de trabalho “Compreender as necessidades dos envolvidos”
A principal atividade é identificar solicitações dos principais envolvidos usando entrevistas. Os principais produtos são conjuntos de características priorizadas e seus atributos críticos, que serão usados na definição do sistema e no gerenciamento do escopo do sistema. Essas informações resultam em um refinamento do documento de visão, bem como em uma melhor compreensão dos atributos dos requisitos. Além disso, durante esse detalhamento do fluxo de trabalho, deve-se começar a discutir os requisitos funcionais do sistema em termos de casos de uso e atores. Uma representação inicial, em termos do modelo de caso de uso, é produzido.
Visão
Cliente
Usuário
Analista de
Sistemas
Glossário
Capturar umVocabulário
Comum
Guia deModelagem deCaso de Uso
IdentificarSolicitações
dos Envolvidos
Solicitaçõesdos envolvidos
LocalizarAtores e
Casos de Uso
Modelo Caso
de Uso
Desenvolver
Visão
Visão
(Refinada)
Detalhamento do fluxo de trabalho “Definir o Sistema”
A finalidade desse detalhamento é criar uma compreensão comum do sistema dentro da equipe do projeto, realizar uma análise de alto nível sobre os resultados da coleta de solicitações dos principais envolvidos, refinar a visão para que contenha as características a serem incluídas no sistema, juntamente com os atributos adequados, refinar o modelo de casos de uso para incluir os casos de uso descritos, documentar com mais formalidade os resultados em modelos e documentos. Na Definição do Sistema, deve-se concentrar-se em identificar atores e casos de uso inteiramente, bem como elaborar uma especificação preliminar dos requisitos funcionais e não funcionais de forma a suportar a priorização de casos de uso.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 11 de 19
Visão
Analista de
Sistemas
Glossário
Capturar umVocabulário
Comum
Guia de
Modelagem de
Caso de Uso
Solicitaçõesdos envolvidos
LocalizarAtores e
Casos de Uso
Modelo Caso de
Uso (Refinado)
Desenvolver
Visão
Visão(Refinada)
Glossário
(Refinado)
Modelo Casode Uso
Especificadorde Requisitos
Glossário
Definir requisitospreliminares
Guia deModelagem deCaso de Uso
Modelo Casode Uso
Visão
Solicitaçõesdos envolvidos
Especificação
de Requisitos(Preliminar)
Detalhamento do fluxo de trabalho “Gerenciar o escopo do sistema”
Este detalhamento visa priorizar e refinar as informações fornecidas para selecionar as características e os requisitos que serão incluídos na iteração atual. Definir o conjunto de casos de uso (ou cenários) que representam alguma funcionalidade central e significativa. O escopo de um projeto é definido pelo conjunto de requisitos alocados para ele. O gerenciamento do escopo do projeto para se adequar aos recursos disponíveis (tempo, pessoas e dinheiro) é primordial para o gerenciamento de projetos com êxito. Gerenciar o escopo é uma atividade contínua que requer desenvolvimento iterativo ou incremental.
Arquiteto de
Software
Visão
Priorizar
Casos de Uso
Especificação deRequisitos
Modelo Caso
de Uso
Documento de
Arquitetura de Software(Visão de Casos de Uso)
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 12 de 19
Detalhamento do fluxo de trabalho “Refinar definição do sistema”
A meta deste detalhamento é refinar os requisitos para descrever com detalhes o fluxo de eventos do caso de uso. Detalhar a Especificação de Requisitos de Software. Modelar e criar o protótipo da interface do usuário. O refinamento da definição do Sistema começa com o detalhamento dos casos de uso descritos. A saída desse detalhamento do fluxo de trabalho é uma compreensão mais aprofundada da funcionalidade do sistema expressa em casos de uso detalhados e Especificação de Requisitos detalhada, bem como elementos da interface de usuário.
Especificadorde Requisitos
Visão
Detalhar
Caso de Uso
Especificação de
Requisitos
Modelo Casode Uso
Especificaçãode Requisitos
(Detalhada)
Glossário
Detalhar
Especificaçãode Requisitos
Solicitações
dos envolvidos
Guia deModelagem de
Caso de Uso
Modelo Caso
de Uso
(Detalhado)
Designer da
Interface doUsuário
Visão
Criar um Protótipo deInterface do Usuário
Especificação de
RequisitosModelo Caso
de Uso
Protótipo daInterface do Usuário
Solicitaçõesdos envolvidos
Ator descritocaracterizado
Modelar Protótipo de
Interface do Usuário
Encenação de Casode Uso / Classe
Fronteira
3.1.2 Artefatos
Como Usar Artefatos
Inic Elab Const
Detalhes da
Revisão
Ferramentas
Usadas
Templates/
Exemplos
Ator N N N Informal Case UML Disponíveis Classe de Fronteira D N N Informal Case UML Disponíveis Glossário N N N Formal-Externo Editor Textos Disponíveis Solicitações dos Principais Envolvidos
N N N Formal-Externo Editor Textos Disponíveis
Especificação de Requisitos de Software
N N N Formal-Externo Editor Textos Disponíveis
Caso de Uso N N N Formal-Externo Case UML Disponíveis Modelo de Casos de Uso N N N Formal-Externo Case UML Disponíveis
Encenação de Caso de Uso D N P Informal Case UML e
Editor Textos Disponíveis
Protótipo da Interface do Usuário D N P Formal-Externo Desenho / RAD Visão N N N Formal-Externo Editor Textos Disponíveis
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 13 de 19
3.1.3 Relatórios
Relatórios Como Usar Ferramentas Usadas Templates/Exemplos
Relatório Sintético de Modelo de Casos de Uso
É necessário usar este relatório para sintetizar as informações sobre atores e casos de uso.
Editor de Textos Disponíveis
3.2 Gerenciamento de Projeto
3.2.1 Fluxo de Trabalho
Conceber novo
projeto
Avaliar escopo e
risco do projeto
Monitorar e
controlar o projeto
Detalhamento do fluxo de trabalho “Conceber novo projeto”
A finalidade deste detalhamento do fluxo de trabalho é apresentar um projeto desde a origem de uma idéia até o ponto em que é possível tomar decisões fundamentadas para continuar ou abandonar o projeto.
Gerente deProjeto
Iniciar Projeto
Plano de Iteração
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 14 de 19
Detalhamento do fluxo de trabalho “Avaliar escopo e risco do projeto”
Este detalhamento do fluxo de trabalho visa identificar e avaliar as características do projeto, bem como os riscos associados a elas. Esta identificação e avaliação é realizada inicialmente na fase de concepção do projeto e continua sendo revisada e atualizada durante todo o ciclo de vida.
Informações detalhadas e diretrizes de como construir uma lista de riscos podem ser encontradas na aula 11.
Visão
Gerente de
Projeto
Identificar eavaliar riscos
Lista de Riscos
Detalhamento do fluxo de trabalho “Monitorar e controlar o projeto”
Este detalhamento visa monitorar continuamente o projeto em termos de riscos e revisões objetivas do andamento e da qualidade. Mantêm relatório regular do status do projeto, garantindo cumprimento das atividades e prazos estabelecidos nos planos de iterações.
Problemas
Gerente de
Projeto
Monitorar erelatar status
Avaliação de
status
Resolver
problemasSolicitação
demudança
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 15 de 19
3.2.2 Artefatos
Como Usar Artefatos
Inic Elab Const
Detalhes da
Revisão
Ferramentas
Usadas
Templates/
Exemplos
Plano de Iteração N N N Formal-Interno Editor Textos Disponíveis Lista de Riscos N N N Formal-Interno Editor Textos Disponíveis Solicitação de Mudança N N N Formal-Interno Editor Textos Disponíveis
3.3 Análise e Projeto
3.3.1 Fluxo de Trabalho
Definir uma Sugestão de
Arquitetura
Analisar
Comportamento
Projetar
Componentes
Projetar Banco
de Dados
Detalhamento do fluxo de trabalho “Definir uma Sugestão de Arquitetura”
A finalidade deste detalhamento do fluxo de trabalho é construir uma realização para cada caso de uso previamente identificado e especificado na iteração preliminar. A realização objetiva especificar quais objetos e como eles se comunicam para realizar a funcionalidade proposta pelo caso de uso em questão. Além disso, neste fluxo de trabalho também deve ser produzido o modelo de implantação, que objetiva definir a configuração dos nós de processamento em tempo de execução e os vínculos de comunicação entre eles. Este modelo deve ser atualizado no artefato de arquitetura de software. Os três diagramas produzidos neste fluxo de trabalho devem ser desenvolvidos usando UML.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 16 de 19
Arquiteto de
Software
Análise
arquitetural
Especificaçãode Requisitos
DocumentoArquitetura Software
Modelo Caso
de Uso
Modelo deImplantação
DocumentoArquitetura Software
(Atualizado)
Realizações deCasos de Uso
(Criadas)
Detalhamento do fluxo de trabalho “Analisar Comportamento”
O detalhamento Analisar Comportamento visa concluir as realizações de caso de uso iniciadas no fluxo de trabalho anterior. No entanto, a principal finalidade deste detalhamento é analisar o comportamento dos casos de uso para criar um Modelo de Análise (diagrama de classes apenas com atributos, sem métodos e sem detalhes como tipos, modificadores, retorno) definindo a associação entre essas classes (associação simples, agregação, composição e herança).
Designer
Análise deCaso de Uso
Especificaçãode Requisitos
DocumentoArquitetura Software
Modelo Casode Uso
Realizações deCasos de Uso(Completas) Modelo de Análise
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 17 de 19
Detalhamento do fluxo de trabalho “Projetar Componentes”
Este fluxo de trabalho tem por finalidade melhor detalhar as classes de análise presentes no modelo de
análise, produzindo assim o Modelo de Projeto. Este modelo é constituído por um diagrama de classes com detalhes suficientes para a implementação. As classes desse modelo são consideradas componentes, e dessa forma seu projeto deve ser minuciosamente detalhado, contendo atributos e métodos, com tipos, parâmetros e modificadores bem definidos. Além disso, o comportamento de cada método deve ser especificado de forma procedimental usando uma linguagem estruturada. Ao final dessa atividade, o diagrama de classes deve estar detalhado ao ponto de subsidiar completamente a implementação dos componentes.
Designer
Projetar
Classes
Modelo Caso
de Uso
Realizações deCasos de Uso Modelo de Análise
Modelo de Projeto
Detalhamento do fluxo de trabalho “Projetar Banco de Dados”
A atividade Projetar Banco de Dados visa elaborar um modelo lógico relacional de um banco de dados que seja suficiente para armazenar os dados persistentes dos objetos identificados nas atividades anteriores. O modelo de dados deve ser criado com apoio de alguma ferramenta case, de preferência gratuita (DbDesigner), e deve possuir definição completa de entidades, atributos com respectivos tipos e domínios, chaves primária, alternativa e estrangeiras, bem como regras de negócio mapeadas pelos relacionamento, cardinalidades e respectivas integridades. Além disso, tabelas, campos e relacionamentos devem ser precisamente comentados, para que uma documentação contendo dicionário de dados possa ser gerada pela ferramenta case.
Designer deBanco de Dados
Elaborar o Projeto
de Banco de Dados
Realizações deCasos de Uso Modelo de Projeto
Modelo Lógico deBanco de Dados
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 18 de 19
3.3.2 Artefatos
Como Usar Artefatos
Inic Elab Const
Detalhes da
Revisão
Ferramentas
Usadas
Templates/
Exemplos
Plano de Iteração D N N Formal-Interno Editor Textos Disponíveis Realização de Caso de Uso D N N Formal-Interno Editor Textos e
Case UML Disponíveis
Modelo de Implantação D N N Formal-Interno Editor Textos e
Case UML Disponíveis
Modelo de Análise D N N Formal-Interno Editor Textos e
Case UML Disponíveis
Modelo de Projeto D N N Formal-Interno Editor Textos e
Case UML Disponíveis
Modelo de Banco de Dados D N N Formal-Interno Editor Textos e
Case BD Disponíveis
4. Papéis Nenhuma mudança foi realizada sobre os papéis para este projeto. Segue uma breve descrição das responsabilidades de cada papel aqui utilizado.
Analista de Sistemas
O papel analista de sistemas lidera e coordena a identificação de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais são os atores e casos de uso existentes e como eles interagem.
Especificador de Requisitos
O papel especificador de requisitos detalha a especificação de uma parte da funcionalidade do sistema, descrevendo o aspecto Requisitos de um ou de vários casos de uso e outros requisitos de software de apoio. Arquiteto de Software
O papel arquiteto de software lidera e coordena as atividades e os artefatos técnicos no decorrer do projeto. O arquiteto de software estabelece a estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento dos elementos e as interfaces entre esses principais agrupamentos. Portanto, comparado aos outros papéis, a visão do arquiteto de software é ampla, e não detalhada. Designer da Interface do Usuário
O designer de interface de usuário lidera e coordena a construção do protótipo e o design da interface do usuário da seguinte forma:
- capturando os requisitos da interface do usuário, incluindo requisitos de usabilidade; - construindo protótipos de interface do usuário; - incluindo outros envolvidos da interface de usuário, como usuários, nas revisões de usabilidade e nas
sessões de teste de uso; - revisando e fornecendo o feedback apropriado sobre a implementação final da interface do usuário, se
criada por outros desenvolvedores, ou seja, designers e implementadores.
Definição de Processo de Desenvolvimento de Software Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD Projeto Número
Projetos Acadêmicos 01/2004 Gerente do Projeto Data
Cleuber Fernandes 23/09/04
Confidencial CompEduc, 2008 Página 19 de 19
Designer
O papel designer define as responsabilidades, as operações, os atributos e os relacionamentos de uma ou de várias classes e determina como eles serão ajustados para o ambiente de implementação. Além disso, o papel designer pode ser responsável por um ou mais pacotes de design ou subsistemas de design, incluindo todas as classes pertencentes aos pacotes ou subsistemas.
Top Related