• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Caso de Desenvolvimento
 

Caso de Desenvolvimento

on

  • 4,881 views

 

Statistics

Views

Total Views
4,881
Views on SlideShare
4,869
Embed Views
12

Actions

Likes
1
Downloads
123
Comments
0

1 Embed 12

http://www.slideshare.net 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Caso de Desenvolvimento Caso de Desenvolvimento Presentation Transcript

    • 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 Histórico da Revisão Data Versão Descrição Autor 23/09/2004 1.0 Este documento deve ser utilizado como Cleuber Fernandes guia do que deve ser desenvolvido e produzido pelo trabalho acadêmico das turmas de Engenharia de Software II. 15/11/2004 2.0 Foi incluído o detalhamento de fluxo de Cleuber Fernandes trabalho para a disciplina Análise e Projeto. Confidencial ©CompEduc, 2008 Página 2 de 19
    • 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 Í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 Confidencial ©CompEduc, 2008 Página 3 de 19
    • 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 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á No fim na fase de Concepção está o Marco dos Objetivos do uma visão geral e os requisitos do Ciclo de Vida. Os seguintes itens devem ser revisados para produto. Os principais casos de uso verificar se este Marco foi alcançado ou não: serão desenvolvidos. Será gerada uma lista dos principais riscos, bem 1. Consentimento dos envolvidos sobre a definição do como um plano de iteração para a objetivo e escopo do produto. próxima fase. No final da fase de 2. Consenso de que o conjunto correto de requisitos foi Concepção, será decidido se o capturado e de que existe uma compreensão compartilhada projeto será levado adiante. 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. Confidencial ©CompEduc, 2008 Página 4 de 19
    • 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 Elaboração A Fase de Elaboração analisará os No fim na fase de Elaboração está o Marco da Arquitetura requisitos e desenvolverá o protótipo do Ciclo de Vida. Nesse momento, os objetivos e o escopo de arquitetura. Após concluir a Fase detalhados do sistema, a opção de arquitetura e a resolução de Elaboração, todos os casos de uso dos principais riscos devem ser examinados. selecionados para o Release 1.0 O Marco de Protótipo de Arquitetura indica o final da Fase de terão análise e design completos. Elaboração. Este protótipo representa a verificação dos Além disso, os casos de uso de alto principais componentes da arquitetura que compõem o risco do Release 2.0 já estarão Release 1.0. analisados e projetados. O protótipo 1. A Visão e os requisitos do produto são estáveis. de arquitetura testará a viabilidade e 2. A arquitetura é estável. o desempenho da arquitetura 3. As abordagens principais a serem usadas no teste e na necessários para o Release 1.0. 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 No fim na fase de Construção está o Marco da Capacidade casos de uso restantes serão Operacional Inicial do Ciclo de Vida. Se todas as atividades analisados e projetados. Os projetos previstas para esta fase fossem realizadas, o produto estaria de componentes e banco de dados pronto para ser passado para a Equipe de Transição. Toda a serão refinados e concluídos. Não funcionalidade já teria sido desenvolvida e todos os testes alfa haverá implementação, e teriam sido concluídos. Além do software, um manual do conseqüentemente não haverá testes usuário seria desenvolvido, e existiria uma descrição do alfa, por limitação de tempo. Nesta release atual. No entanto, para este projeto a fase de fase os artefatos de projeto serão Construção apenas finalizará os artefatos de projeto. Sendo refinados e concluídos. 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 Confidencial ©CompEduc, 2008 Página 5 de 19
    • 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 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. Artefatos Como Usar Detalhes da Ferramentas Templates/ Inic Elab Const Trans Revisão Usadas 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 Para cada fase, decida entre Necessário, Recomendável, Possível ou artefato é usado no Desnecessário. ciclo de vida Detalhes da Revisão Defina o nível de Determine o nível de revisão: Formal-Externo, Formal-Interno, revisão e os Informal, Nenhum. procedimentos de revisão a serem aplicados ao artefato Ferramentas Usadas Definição das Referências aos detalhes das ferramentas utilizadas para desenvolver ferramentas usadas e manter este artefato. para produzir o artefato Templates/Exemplos Os templates a Referências aos templates e exemplos. Podem ser feitas referências serem utilizados e a templates e exemplos do RUP ou a templates e exemplos locais. exemplos de Esta coluna também pode conter referências a artefatos reais que artefatos que usam oferecem ajuda adicional aos membros do projeto. os templates Confidencial ©CompEduc, 2008 Página 6 de 19
    • 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 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”. Confidencial ©CompEduc, 2008 Página 7 de 19
    • 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 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 Es copo Muito Grande Problema Correto Definir o Trabalhar no Escopo Sistema Refinar Definição do Gerenciar o Escopo Sistema do Sistema Confidencial ©CompEduc, 2008 Página 8 de 19
    • 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 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. Glossário Visão Capturar um Vocabulário Cliente Comum Desenvolver Analista de Visão Sistemas Localizar Usuário Atores Modelo Caso de Uso Solicitações (somente atores) dos envolvidos 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 quot;podadasquot; 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. Confidencial ©CompEduc, 2008 Página 9 de 19
    • 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 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. Guia de Visão Modelagem de Glossário (Refinada) Caso de Uso Capturar um Vocabulário Desenvolver Cliente Comum Visão Analista de Sistemas Identificar Localizar Usuário Solicitações Atores e dos Envolvidos Casos de Uso Solicitações Visão dos envolvidos Modelo Caso de Uso 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. Confidencial ©CompEduc, 2008 Página 10 de 19
    • 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 Glossário Solicitações Visão Glossário (Refinado) dos envolvidos Guia de Modelagem de Visão Visão Glossário Caso de Uso (Refinada) Capturar um Vocabulário Desenvolver Comum Visão Analista de Sistemas Definir requisitos Especificador preliminares Localizar de Requisitos Atores e Casos de Uso Guia de Solicitações Especificação Modelagem de Modelo Caso Modelo Caso de Modelo Caso dos envolvidos de Requisitos Caso de Uso de Uso Uso (Refinado) de Uso (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. Especificação de Modelo Caso Visão Requisitos de Uso Documento de Arquitetura de Software Arquiteto de Priorizar (Visão de Casos de Uso) Software Casos de Uso Confidencial ©CompEduc, 2008 Página 11 de 19
    • 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 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. Guia de Especificação de Modelagem de Especificação de Modelo Caso Ator descrito Visão Requisitos caracterizado Glossário Visão Caso de Uso Requisitos de Uso Especificação Modelar Protótipo de de Requisitos Interface do Usuário Detalhar (Detalhada) Designer da Especificador Detalhar Especificação Interface do Criar um Protótipo de de Requisitos Caso de Uso de Requisitos Usuário Interface do Usuário Modelo Caso de Uso (Detalhado) Encenação de Caso Solicitações Modelo Caso Solicitações Protótipo da de Uso / Classe dos envolvidos de Uso dos envolvidos Fronteira Interface do Usuário 3.1.2 Artefatos Artefatos Como Usar Detalhes da Ferramentas Templates/ Inic Elab Const Revisão Usadas 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 N N N Formal-Externo Editor Textos Disponíveis Envolvidos Especificação de Requisitos de N N N Formal-Externo Editor Textos Disponíveis Software 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 D N P Informal Case UML e Disponíveis Encenação de Caso de Uso Editor Textos 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 Confidencial ©CompEduc, 2008 Página 12 de 19
    • 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 3.1.3 Relatórios Relatórios Como Usar Ferramentas Usadas Templates/Exemplos É necessário usar este Relatório Sintético de Modelo de relatório para sintetizar as Editor de Textos Disponíveis Casos de Uso informações sobre atores e casos de uso. 3.2 Gerenciamento de Projeto 3.2.1 Fluxo de Trabalho Conceber novo projeto Avaliar esc opo e Monitorar e risco do projeto 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 de Iniciar Projeto Projeto Plano de Iteração Confidencial ©CompEduc, 2008 Página 13 de 19
    • 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 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 Identificar e Gerente de avaliar riscos Projeto 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. Avaliação de status Problemas Monitorar e Resolver Solicitação Gerente de relatar status problemas de Projeto mudança Confidencial ©CompEduc, 2008 Página 14 de 19
    • 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 3.2.2 Artefatos Artefatos Como Usar Detalhes da Ferramentas Templates/ Inic Elab Const Revisão Usadas 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 Projetar Banco Componentes 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. Confidencial ©CompEduc, 2008 Página 15 de 19
    • 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 Especificação Documento de Requisitos Arquitetura Software Modelo Caso de Uso Análise Arquiteto de arquitetural Software Realizações de Documento Casos de Uso Modelo de Arquitetura Software (Criadas) Implantação (Atualizado) 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). Especificação Documento de Requisitos Arquitetura Software Modelo Caso de Uso Análise de Caso de Uso Designer Realizações de Casos de Uso (Completas) Modelo de Análise Confidencial ©CompEduc, 2008 Página 16 de 19
    • 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 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. Realizações de Casos de Uso Modelo de Análise Modelo Caso de Uso Projetar Classes Designer 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. Realizações de Casos de Uso Modelo de Projeto Elaborar o Projeto Designer de de Banco de Dados Modelo Lógico de Banco de Dados Banco de Dados Confidencial ©CompEduc, 2008 Página 17 de 19
    • 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 3.3.2 Artefatos Artefatos Como Usar Detalhes da Ferramentas Templates/ Inic Elab Const Revisão Usadas 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 Disponíveis Case UML D N N Formal-Interno Editor Textos e Disponíveis Modelo de Implantação Case UML D N N Formal-Interno Editor Textos e Disponíveis Modelo de Análise Case UML D N N Formal-Interno Editor Textos e Disponíveis Modelo de Projeto Case UML D N N Formal-Interno Editor Textos e Disponíveis Modelo de Banco de Dados Case BD 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. Confidencial ©CompEduc, 2008 Página 18 de 19
    • 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 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. Confidencial ©CompEduc, 2008 Página 19 de 19