Processo de desenvolvimento de software para projetos acadêmicos

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

Fase Concepção
Documento Sigla
Caso de Desenvolvimento CD
Projeto Número
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

Fase Concepção
Documento Sigla
Projeto Número

Í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


Fase Concepção
Documento Sigla
Projeto Número

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.


Fase Concepção
Documento Sigla
Projeto Número
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


Fase Concepção
Documento Sigla
Projeto Número
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


Fase Concepção
Documento Sigla
Projeto Número
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”.


Fase Concepção
Documento Sigla
Projeto Número
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
Es copo Muito Grande

Problema Correto

Definir o Trabalhar no Escopo
Sistema

Refinar Definição do
Gerenciar o Escopo Sistema
do Sistema


Fase Concepção
Documento Sigla
Projeto Número
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.


Fase Concepção
Documento Sigla
Projeto Número
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.


Fase Concepção
Documento Sigla
Projeto Número

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


Fase Concepção
Documento Sigla
Projeto Número
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
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


Fase Concepção
Documento Sigla
Projeto Número
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


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


Fase Concepção
Documento Sigla
Projeto Número
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


Fase Concepção
Documento Sigla
Projeto Número
3.2.2 Artefatos
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 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.


Fase Concepção
Documento Sigla
Projeto Número

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


Fase Concepção
Documento Sigla
Projeto Número
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


Fase Concepção
Documento Sigla
Projeto Número
3.3.2 Artefatos
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
Modelo de Análise
Case UML
Modelo de Projeto
Case UML
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.


Fase Concepção
Documento Sigla
Projeto Número
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.


Processo de desenvolvimento de software para projetos acadêmicos

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (6)

Semelhante a Processo de desenvolvimento de software para projetos acadêmicos

Semelhante a Processo de desenvolvimento de software para projetos acadêmicos (20)

Mais de Robson Silva Espig

Mais de Robson Silva Espig (20)

Processo de desenvolvimento de software para projetos acadêmicos