Caso de Desenvolvimento

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


Documento Sigla





Í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


Documento Sigla





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.


Documento Sigla





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


Documento Sigla





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.


Documento Sigla





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”.


Documento Sigla





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


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


Documento Sigla





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.


Documento Sigla





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


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.


Documento Sigla





Visão

Analista de

Sistemas

Glossário

Capturar umVocabulário

Comum

Guia de

Modelagem de

Caso de Uso


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


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)


Documento Sigla





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


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


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


Documento Sigla





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


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


Documento Sigla





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


Documento Sigla





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


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.


Documento Sigla





Arquiteto de

Software

Análise

arquitetural


DocumentoArquitetura Software

Modelo Caso

de Uso

Modelo deImplantação


(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



Modelo Casode Uso

Realizações deCasos de Uso(Completas) Modelo de Análise


Documento Sigla





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


Documento Sigla





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


Modelo de Análise D N N Formal-Interno Editor Textos e


Modelo de Projeto D N N Formal-Interno Editor Textos e


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.


Documento Sigla





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.

Caso de Desenvolvimento

Technology

Transcript of Caso de Desenvolvimento