MDS_doc.dot

(1)

INFORMAÇÃO

ACTI

-MAPA

Metodologia e Acompanhamento dos Projetos ACTI

(2)

1.1 OBJETIVO...4

1.2 O PROCESSO...4

1.3 FASES DO PROCESSO DE MODELAGEM DE NEGÓCIO...4

1.4 FASES DO PROCESSO DE ENGENHARIA DE SOFTWARE...4

1.5 ATIVIDADES...5

1.6 ARTEFATOS... 6

1.7 DOCUMENTAÇÃO DE APOIO...6

1.8 PROCESSO DE MODELAGEM DE NEGÓCIO...7

1.9 OBJETIVOS...7

1.10 DIAGRAMA DE ATIVIDADES PARA MODELAGEM DE NEGÓCIO...8

1.11 DESCRIÇÕES DAS ATIVIDADES...9

1.12 RESUMO DOS ARTEFATOS...12

1.13 DOCUMENTAÇÃO DE APOIO...12

2 PROCESSO DE ENGENHARIA DE SOFTWARE...13

2.1 OBJETIVOS...13

2.2 FASES DO PROCESSO DE ENGENHARIA DE SOFTWARE...13

3 PROCESSO DE ENGENHARIA DE SOFTWARE - FASE DE INICIAÇÃO...14

3.1 OBJETIVOS...14

3.2 VISÃO GERAL...14

3.3 DIAGRAMA DE ATIVIDADES PARA A FASE DE INICIAÇÃO...15

3.4 DESCRIÇÕES DAS ATIVIDADES...16

3.5 RESUMO DOS ARTEFATOS...18

3.6 DOCUMENTAÇÃO DE APOIO...19

4 PROCESSO DE ENGENHARIA DE SOFTWARE - FASE DE CONCEPÇÃO...20

4.1 OBJETIVOS...20

4.2 DIAGRAMA DE ATIVIDADES...21

4.3 DESCRIÇÕES DAS ATIVIDADES...21

4.4 RESUMO DOS ARTEFATOS...23

4.5 DOCUMENTAÇÃO DE APOIO...23

5 PROCESSO DE ENGENHARIA DE SOFTWARE - FASE DE ELABORAÇÃO...24

5.1 OBJETIVOS...24

5.2 DIAGRAMA DE ATIVIDADES...25

5.3 DESCRIÇÕES DAS ATIVIDADES...26

(3)

7.2 DIAGRAMA DE ATIVIDADES...45

7.3 DESCRIÇÕES DAS ATIVIDADES...46

7.4 RESUMO DOS ARTEFATOS...47

(4)

1.1 OBJETIVO

O objetivo deste documento é descrever o processo de Gerenciamento e Desenvolvimento de

Sistemas do Sistema Indústria, listando primeiramente a Processo de Modelagem de Negócio, que na

versão atual está separada do restante do processo de Engenharia de Software. O Processo de Engenharia

de Software está separado em fases, atividades, respectivos responsáveis, produtos e as normas de apoio

que poderão ser aplicadas no processo de desenvolvimento de sistemas.

1.2 O PROCESSO

O Processo atual está separado em dois momentos:

1. Processo de Modelagem de Negócio;

2. Processo de Engenharia de Software;

1.3 FASES DO PROCESSO DE MODELAGEM DE NEGÓCIO

Nesta versão a modelagem de negócio possui somente uma fase. Este capítulo será detalhado no

decorrer deste documento.

1.4 FASES DO PROCESSO DE ENGENHARIA DE SOFTWARE

Seguindo os preceitos do RUP (

Rational Unified Process

) e PMBOK (

Project Management

(5)



Fase de Concepção:

Nesta fase é realizado a concepção do Projeto, com descrição das

atividades a serem realizadas, alocação de recursos e cronograma.



Fase de Elaboração:

Nesta fase é aprofundado o conhecimento do negócio através da

identificação de todos os casos de uso e elaboração de planos de gerenciamento do projeto.



Fase de Construção:

Nesta fase os riscos já foram tratados e a especificação está

praticamente concluída, o esforço está concentrado no desenvolvimento dos casos de uso,

testes e homologação.



Fase de Transição:

Com o término da implementação e testes internos, restam a esta fase o

fechamento da documentação e a implantação do sistema.

Figura 01 – Fases do Processo de Engenharia de Software

1.5 ATIVIDADES

As atividades aqui descritas compõem o que normalmente deverá ser feito em cada fase nos projetos

da ACTI. Elas serão apresentadas em uma seqüência que geralmente ocorre, mas isso não significa que a

ordem não possa ser mudada, pois, como sabemos cada projeto pode transcorrer de forma diferente.

É importante destacar que nem sempre é necessário executar todas essas atividades. Porém, existem

algumas delas que deverão ser obrigatoriamente executadas, principalmente aquelas relacionadas

diretamente aos objetivos descritos em cada fase.

MAPA 4.0 © Sistema Indústria Página 5 de 47

Iniciação

Concepção

Gerenciamento

do Projeto

Elaboração

Construção

Transição

(6)

1.6 ARTEFATOS

Os artefatos são gerados como componentes do produto final dos projetos a serem desenvolvidos e

serão apresentados, nos subitens: “Resumo dos Artefatos” em tabelas, no final de cada fase, com as

seguintes informações:



Artefatos: Informa os nomes dos artefatos previstos para a fase.



Aplicação: Define a forma de aplicação do artefato na fase com a seguinte legenda:



“C”: indica que o artefato é criado na fase;



“R” : indica que o artefato é revisado na fase.



Ferramenta: Informa a ferramenta na qual deverá ser elaborado o artefato.



Modelo: Informa o nome do arquivo modelo do artefato, caso exista.

Nota:

1. Os modelos de artefatos estão localizados no diretório: Artefatos, distribuídos por

áreas de negócio, conforme o arquivo:

Planilha de Artefatos.xls.

2. A obrigatoriedade de cada artefato está destacada na planilha, caso o projeto não

produza algum artefato obrigatório deverá descrever o motivo no artefato: “Plano do

Projeto”.



Descrição: Apresenta uma descrição resumida do artefato.

1.7 DOCUMENTAÇÃO DE APOIO

A documentação de apoio descreve de que forma as normas técnicas de apoio ao processo de

desenvolvimento devem ser seguidas no projeto. Serão apresentadas em tabelas, no final de cada fase,

com as seguintes informações:



Documento: Define o nome do documento de apoio.



(7)

Nota: Os documentos referentes às normas e padrões estão localizados no repositório CVS

1.8 PROCESSO DE MODELAGEM DE NEGÓCIO

1.9 OBJETIVOS

No Processo de Modelagem de Negócio podemos destacar as seguintes finalidades:



Fornecer uma visão geral abrangente da estrutura e da finalidade do negócio;



Entender a estrutura e a dinâmica da organização na qual um sistema deve ser inserido;



Entender os problemas atuais da entidade e identificar as possibilidades de melhoria;



Estabelecer um meio de comunicação entre o analista de processo do negócio e o cliente;



Derivar os requisitos de sistema necessários para sustentar a entidade;



Definir as principais capacidades e mecanismos do negócio.

Para atingir essas metas, a fase de modelagem de negócios descreve como desenvolver uma visão

da Unidade/Entidade e, com base nesta visão, definir os processos, os papéis e as responsabilidades dessa

organização em um Modelo de Casos de Uso composto de Diagrama de Escopo de Negócio e

Especificação de Processo de Negócio. Podemos contar também com o artefato Diagrama de Atividade de

Negócio para melhorar o entendimento, caso necessário.

(8)

1.10 DIAGRAMA DE ATIVIDADES PARA MODELAGEM DE NEGÓCIO

ad Modelagem de Negócio

1.3 Realizar Modelagem de Negócio iterativ e 1.2 Av aliar Satus do Negócio Início Nessecita de Modelagem? Identificar os Processos de Negócio Fim Refinar Definições dos Processos de Negócios 1.2.1 Encerrar o processo de Modelagem de Negócio Realizar o Diagrama de Escopo de Negócio Realizar a Especificação de Processo de Negócio Necessita de Diagrama de Atividade de Negócio? Realiza o Diagrama de Ativ idades de Negócio 1.1 Solicitar Sistema com Modelagem de Negócio 1.4 Validação da Modelagem de Negócio Não Sim Não Sim

(9)

1.11 DESCRIÇÕES DAS ATIVIDADES

Item Responsável Descrição da Atividade

1.1 Gestor do Projeto Solicitar Sistema com Modelagem de Negócio

 O Gestor de Projeto, interessado no sistema, envia uma solicitação ao Gerente de Sistemas da Área Compartilhada ou de Negócio de acordo com a área do projeto. Esta solicitação poderá ser enviada por e-mail. Na solicitação deve estar devidamente explícito a solicitação de uma Modelagem de Negócio.

Artefato(s): Entrada:



-Saída:

 Solicitação de Sistemas com Modelagem de Negócio. 1.2 Gerente de Sistemas

(Área Compartilhada ou de Negócio)

Avaliar Status do Negócio

 O Gerente de Sistemas avalia se o cliente já possui uma modelagem de negócio e está validado pelo usuário atual. As principais finalidades desta atividade são:

 Avaliar o status da organização na qual o sistema resultante deve ser implantado (a organização-alvo).

 Entender como o projeto deve ser classificado e identificar o cenário de modelagem de negócios mais adequado, para melhor informação consulte em material de apoio, no diretório de diretrizes o documento: Escopo da Modelagem de Negócios.

 Tomar decisões sobre como dar continuidade ao trabalho na iteração atual e definir como será o trabalho nas próximas iterações com os artefatos de modelagem de negócios.

 Desenvolver um entendimento inicial das metas e dos objetivos, uma Visão do Negócio, da organização-alvo que podem ser aprovados pelos envolvidos e pela equipe de modelagem de negócios.

 Caso a solicitação seja aceita, o Gerente de Sistemas deve priorizar o atendimento desta solicitação e definir um Analista de Negócio responsável por este projeto, comunicando esta escolha ao Gestor do Projeto;

 Caso a solicitação não seja aceita, o Gerente de Sistemas deve enviar ao Gestor do Projeto uma comunicação de cancelamento (item 1.2.1).

 Solicitação de Sistemas com Modelagem de Negócio.

Saída:

 Solicitação de Sistemas Aprovada ou Cancelada.

(10)

1.2.1 Gerente de Sistemas (Área Compartilhada ou de Negócio)

Encerrar o Processo de Modelagem de Negócio

 O Gerente de Sistemas deve enviar ao solicitante um comunicado informando o cancelamento da Modelagem de negócio ou cancelamento do Projeto.

 Solicitação de Sistemas com Modelagem de Negócio.

Saída:

 Comunicado de cancelamento. 1.3 Analista de Negócio Realizar a Modelagem de Negócios

 Após a priorização, caso o Analista de Negócio julgue necessário para o bom entendimento e sucesso do projeto, deverá ser feita a modelagem de negócios da área em que está sendo desenvolvido o projeto;

 O Analista de Negócio efetua o levantamento e faz o mapeamento dos processos existentes, na área de interesse do negócio, podendo abranger apenas uma unidade ou partes maiores ou a organização como um todo, se for necessário;

 Este levantamento servirá como base para o desenvolvimento de novos projetos a serem feitos na mesma área.

 Solicitação de Sistemas.

Saída:

 Modelo de Casos de Uso de Negócio:  Diagrama de Escopo de Negócio  Especificação de Processo de Negócio  Diagrama de Atividades de Negócio

1.4 Gestor do Projeto Validação da Modelagem de Negócio

 O Gestor do Projeto e o Analista de Negócio analisam a Modelagem de Negócio;

 Caso a Modelagem de Negócio seja aprovada, o Gestor do Projeto aprova o documento final, assina e o projeto é encerrado. O Analista de Negócio executa todos os procedimentos para armazenar e distribuir o resultado do projeto para o conjunto de interessados.

 Caso a modelagem não seja aprovada, o Gerente de Sistemas deve verificar o motivo, se houver cancelamento, o Gerente do Projeto deve enviar ao Gestor do Projeto uma comunicação de cancelamento (item 1.2.1) se não foi cancelado deve solicitar ao Analista de Negócio que retorne à modelagem do negócio (item 1.3) e repasse os motivos do não cumprimento do prazo.

(11)

(12)

1.12 RESUMO DOS ARTEFATOS

Artefatos Aplicação Ferramenta Modelo Descrição

Solicitação de Sistemas com Modelagem de Negócio

C Microsoft Word SiglaDoProjeto_Solici

tacaoSistema.dot Tem por finalidade iniciar o processo dedesenvolvimento ou aquisição de software para atender a necessidade de uma área ou pessoa. No caso do acréscimo da modelagem de negócio o Analista deve explicitar esta requisição no documento.

Diagrama de Escopo de Negócio

C Enterprise

Architect --- Visa mostrar o domínio do negócio através dainteração entre atores de negócio, trabalhadores de negócio e casos de uso de negócio de uma organização ou unidade de organização. Traz a visão sobre o que a organização ou unidade da organização faz. Especificação de

Processo de Negócio

C Microsoft Word SiglaDoProjeto_EspC asoUsoNegocio_Nom

eCasoUso.dot

Visa detalhar as tarefas/atividades que compõem um caso de uso de negócio . Diagrama de

Atividades de Negócio

C Enterprise

Architect --- Este diagrama é utilizado para mostrar,graficamente, as atividades de negócio especificadas no caso de uso de negócio. Normalmente é utilizado quando o caso de uso de negócio é complexo e de difícil entendimento.

Glossário C Microsoft Word SiglaDoProjeto_Gloss

ario.dot

Engloba as definições, acrônimos e

_{abreviações utilizadas nos documentos}

do projeto.

Aplicação : C indica que o artefato é criado na fase; R indica que o artefato é revisado na fase. Modelos : Ver Anexo I - Tabela de Artefatos

1.13 DOCUMENTAÇÃO DE APOIO

Documento Aplicação Descrição

Norma para Edição de Documentos

T Documento que orienta na formatação e edição dos artefatos gerados pela MAPA.

Perfis Profissionais T Documento que tem por objetivo descrever os perfis profissionais pertinentes a CNI-ACTI e que estão envolvidos na MAPA.

Escopo da Modelagem de Negócio

T Documento que orienta os

diferentes escopos dependendo do

contexto e da necessidade da modelagem de negócio

Aplicação: T documento totalmente aplicável à fase; P documento parcialmente aplicável à fase.

(13)

2

2 PROCESSO DE ENGENHARIA DE SOFTWARE

PROCESSO DE ENGENHARIA DE SOFTWARE

2.1 OBJETIVOS

A partir de uma perspectiva de gerenciamento, Processo de Engenharia de Software - PES está

dividido em cinco fases seqüenciais, cada uma concluída por um marco principal, ou seja, cada fase é

basicamente um intervalo de tempo entre dois marcos principais. Em cada final de fase é executada uma

avaliação para determinar se os objetivos da fase foram alcançados. Uma avaliação satisfatória permite que

o projeto passe para a próxima fase.

2.2 FASES DO PROCESSO DE ENGENHARIA DE SOFTWARE

As fases não são idênticas em termos de programação e esforço. Embora isso varie muito de

acordo com o projeto, um ciclo de desenvolvimento inicial típico para um projeto de médio

tamanho deve prever a seguinte distribuição de esforço e programação:

Iniciação

Concepção

Elaboração

Construção

Transição

Esforço

2%

8%

20 %

60%

10%

Programação

2%

5%

30 %

53%

10%

Que pode ser descrito graficamente como:

(14)

3

3 Processo de Engenharia de Software - FASE DE INICIAÇÃO

Processo de Engenharia de Software - FASE DE INICIAÇÃO

3.1 OBJETIVOS

A fase de Iniciação marca o início dos trabalhos de um novo projeto a partir de uma solicitação do

usuário.

Podemos destacar como objetivos principais desta fase:



Formalizar o início do projeto;



Levantar os requisitos do sistema;



Definir o escopo inicial do projeto e obter sua aprovação.

(15)

3.3 DIAGRAMA DE ATIVIDADES PARA A FASE DE INICIAÇÃO

ad Iniciação 1.1 Solicitar Sistema 1.2 Av aliar Solicitação Solicitação foi aprovada?

1.3 Realizar Lev antamento Preliminar de Requisitos 1.4 Av aliar Proj eto Projeto foi aprovado? 1.5 Realizar Checklist 1.2.1 Comunicar Cancelamento Início Fim Checklist realizado? Projeto foi Cancelado? 1.6 Documentar Lições Aprendidas Sim Não Sim Não Não Sim Sim Não

(16)

3.4 DESCRIÇÕES DAS ATIVIDADES

1.1 Gestor do Projeto Solicitar Sistemas

 O Gestor de Projeto, interessado no sistema, envia uma solicitação ao Gerente de Sistemas da Área Compartilhada ou de Negócio de acordo com a área do projeto. Esta solicitação poderá ser enviada por e-mail.

Artefato(s): Entrada:  -Saída:  Solicitação de Sistemas. 1.2 Gerente de Sistemas (Área Compartilhada ou de Negócio) Avaliar Solicitação

 O Gerente de Sistemas avalia se o sistema solicitado existe; se está previsto no Planejamento Anual de Sistemas; se está em desenvolvimento ou tem alguma ligação com algum sistema existente;

 Caso a solicitação seja aceita, o Gerente de Sistemas deve priorizar o atendimento desta solicitação e definir um Analista de Negócio responsável por este projeto, comunicando esta escolha ao Gestor do Projeto;

 Caso a solicitação não seja aceita, o Gerente de Sistemas deve enviar ao Gestor do Projeto uma comunicação de cancelamento (item 1.2.1).

Saída:

 Solicitação de Sistemas Aprovada ou Cancelada. 1.2.1 Gerente de Sistemas

(Área Compartilhada ou de Negócio)

Comunicar Cancelamento

 O Gerente de Sistemas deve enviar ao solicitante um comunicado informando o cancelamento da solicitação de sistemas ou cancelamento do Projeto.

Saída:

(17)

1.3 Analista de Negócio Realizar o Levantamento Preliminar de Requisitos

 O Analista de Negócio efetua um Levantamento inicial de requisitos para permitir a montagem do escopo do sistema;

 Após o levantamento inicial, o Analista de Negócios avalia a disponibilidade de pacotes no mercado e suas customizações necessárias e solicita - caso julgue necessário - ao Analista de Sistemas que avalie os mesmos requisitos na hipótese de um desenvolvimento interno do sistema solicitado;

 Feitos os levantamentos, o Analista de Negócio elabora um Documento de Visão com o escopo definido, previsão de prazos, custos, recursos necessários, requisitos, premissas, restrições de acordo com as soluções encontradas para atender a solicitação e inicia a elaboração do documento de Glossário,

com as

definições, acrônimos e abreviações utilizadas nos documentos do

projeto.

 Solicitação de Sistemas;

 Modelagem de Negócio (Caso exista):  Diagrama de Escopo de Negócio  Especificação de Processo de Negócio  Diagrama de Atividades de Negócio (Caso exista).

Saída:

 Documento de Visão;

 Solicitação de Sistemas assinada;  Glossário

 Checklist 1.4 Gestor do Projeto Avaliar Projeto

 O Gerente de Sistemas e o Analista de Negócio analisam juntamente com o Gestor do Projeto o Documento de Visão com as soluções propostas;

 Caso o projeto seja aprovado, o Gerente de Sistemas e o Analista de Negócio decidem se o desenvolvimento será interno ou se será adquirida uma solução pronta no mercado. Após esta decisão, o Analista de Negócio prepara a versão final do Documento de Visão do Projeto que deverá ser assinado pelo Gestor do Projeto;

 Caso o projeto não seja aprovado, o Gerente de Sistemas deve verificar se houve cancelamento, neste caso deve enviar ao Gestor do Projeto uma comunicação de cancelamento (item 1.2.1) se não foi cancelado deve solicitar ao Analista de Negócio que retorne ao levantamento de requisitos (item 1.3).

 Solicitação de Sistemas;  Documento de Visão.

Saída:

 Documento de Visão revisado.

(18)

1.5 Analista de Negócio Realizar Checklist

 O Analista de Negócio com o objetivo de encerrar a fase de Iniciação do Projeto, efetua uma conferência dos artefatos que foram produzidos até o momento, que deverão ser gravados em um CD e disponibilizados na pasta do projeto;  Caso seja encontrada irregularidade(s), o Analista de Negócio deverá

resolvê-la(s) nesta atividade;

 Caso não seja encontrada nenhuma irregularidade, o Analista de Negócio poderá executar a próxima fase.

 Artefatos gerados até o momento.

Saída:

 Checklist.

1.6 Analista de Negócio Documentar Lições Aprendidas

 O Analista de Negócio deve avaliar o trabalho feito na fase. Essa avaliação consiste em reunir com os participantes do projeto ao final da fase, levantar todos os aspectos positivos e negativos e documentar para formar uma base de conhecimento tanto para o projeto atual, quanto para outros projetos futuros do Sistema Indústria.

Saída:

 Lições Aprendidas.

3.5 RESUMO DOS ARTEFATOS

Solicitação de Sistemas

C Microsoft Word SiglaDoProjeto_Solici tacaoSistema.dot

Tem por finalidade iniciar o processo de desenvolvimento ou aquisição de software para atender a necessidade de uma área ou pessoa.

Documento de Visão

C Microsoft Word SiglaDoProjeto_DocV isao.dot

Seu escopo engloba a definição dos envolvidos, suas necessidades e das características essenciais do sistema.

(19)

futuros projetos.

3.6 DOCUMENTAÇÃO DE APOIO

Norma para Edição de Documentos

T Documento que orienta na formatação e edição dos artefatos gerados pela MAPA.

Perfis Profissionais T Este item tem por objetivo descrever os perfis profissionais pertinentes a CNI-ACTI e que estão envolvidos nesta metodologia.

Diretriz de solicitação de

mudança T As Solicitações de Mudança são usadas para documentar e controlardefeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto.

Norma para a Modelagem de Caso de Uso

P O objetivo deste documento é estabelecer conceitos básicos e normas a serem levadas em consideração durante as atividades de levantamento e modelagem utilizando casos de uso.

Aplicação: T documento totalmente aplicável à fase; P documento parcialmente aplicável à fase. Documentos: Estão localizados no diretórioH:/Processo ACTI/Metodologia/Material de Apoio

(20)

4

4 Processo de Engenharia de Software - FASE DE CONCEPÇÃO

Processo de Engenharia de Software - FASE DE CONCEPÇÃO

4.1 OBJETIVOS

A fase de concepção é onde faremos uma estimativa de tempo, investimento e pessoal que será

utilizado para colocar o projeto em prática. Existe também o levantamento de requisitos, que irá definir todas

as funcionalidades do sistema.

O Analista de Negócio deve ter atenção especial a essa fase, pois o planejamento de projetos é um

trabalho complexo e exige uma grande integração da equipe para que os resultados saiam a contento.

Existe também um grande cuidado com a arquitetura e os riscos do sistema, ao final dessa fase o

Analista de Negócio deverá minimizar ou eliminar todos os riscos do sistema utilizando o Plano de Riscos

para documentá-los.

Podemos destacar como objetivos principais desta fase:



Realizar contagem estimada de pontos de função para o novo projeto;



Revisar o escopo do Projeto;



Elaborar o Levantamento de requisitos;



Minimizar ou Eliminar os riscos arquiteturais através do Plano de Gerenciamento de Riscos e

Projeto Arquitetural;



Mapear os casos de uso arquiteturalmente significantes;



Elaborar Plano do Projeto e obter sua aprovação.

(21)

4.2 DIAGRAMA DE ATIVIDADES

ad Concepção

Início da Fase de Planejamento

Fim da Fase de Planejamento

2.1 Rev isar

Documento de Visão 2.2 Elaborar Planodo Proj eto

2.3 Av aliar Plano do Proj eto 2.4 Realizar Checklist Plano do Projeto Aprovado? Checklist realizado? Não Sim Sim Não

4.3 DESCRIÇÕES DAS ATIVIDADES

2.1 Analista de Negócio Revisar Documento de Visão

 O Analista de Negócio revisa o documento de visão, ao longo desta fase, a partir de reuniões com os usuários .

 Documento de Visão.

Saída:

 Documento de Visão revisado. 2.2 Analista de Negócio Elaborar Plano do Projeto

 O Analista de Negócio elabora o Plano do Projeto contendo as informações necessárias ao gerenciamento do projeto.

(22)

 É recomendável que nesta fase a contagem de Pontos de Função seja a Contagem Estimada, pois não existem informações detalhadas sobre os requisitos de todo o projeto, na próxima fase, será realizada uma nova contagem. Consultar o modelo para a contagem de pontos de função.

 Documento de Visão;

 Modelo de Casos de Uso de Negócio (Caso exista);  Diagrama de Atividade de Negócio (Caso exista);

Saída:

 Plano de Projeto



WBS;

 Documento de Análise de Ponto de Função



Cronograma;



Matriz de Risco;



Matriz de Comunicação;



Matriz de Responsabilidades. 2.3 Gerente de Sistemas Avaliar Plano do Projeto

 O Gerente de Sistemas analisa juntamente com o Analista de Negócio o Plano de Projeto para fins de aprovação;

 Caso o Plano de Projeto não seja aprovado, o Analista de Negócio deverá retornar ao item 2.2 (Elaborar Plano do Projeto);

 Caso o Plano de Projeto seja aprovado, o Analista de Negócio deverá executar a próxima atividade.

 Plano de Projeto.

Saída:

 Plano de Projeto Aprovado. 2.4 Analista de Negócio Realizar Checklist

 O Analista de Negócio, com o objetivo de encerrar a fase de concepção do Projeto, efetua uma conferência dos artefatos que foram produzidos até o momento, que deverão ser gravados em um CD e disponibilizados na pasta do projeto;

(23)

4.4 RESUMO DOS ARTEFATOS

Documento de Visão

R Microsoft Word SiglaDoProjeto_DocV isao.dot

Seu escopo engloba a definição dos envolvidos, suas necessidades e das características essenciais do sistema.

Glossário R Microsoft Word SiglaDoProjeto_Gloss

ario.dot

Engloba as definições, acrônimos e

_{abreviações utilizadas nos documentos}

do projeto.

Plano do Projeto

C Microsoft Word SilglaDoProjeto_Plan oProjeto.dot

O Plano do Projeto contém as informações de Matriz de Risco, Matriz de Comunicação, Documento de Análise de Ponto de Função e Matriz de Responsabilidades.

WBS C WBS Chart Pro ---

Work Breakdown Structure - utilizado

para estruturação do escopo de projetos

sob a forma de atividades e

sub-atividades.

Documento de Análise de Ponto de Função

C Microsoft Excel SiglaDoProjeto_APF.

xls

Documento que armazena as

_{informações sobre as estimativas criadas}

para a aplicação da análise de ponto de

função para um projeto.

Cronograma C Microsoft®

Project

---

Possibilita o planejamento das atividades

no decorrer do tempo por meio de

diagramas, gráficos e planilhas.

Checklist C Microsoft Word SiglaDoProjeto_Chec

kList.dot Este documento contém os artefatos a seremverificados na fase e informações de data da entrega do artefato, data da aprovação do artefato e ultima versão – a mais atual. Lições

Aprendidas R Microsoft Word SiglaDoProjeto_LicoesAprendidas.dot Este documento visa documentar asexperiências relatadas pelos membros do projeto, a fim de que estas sejam utilizadas em futuros projetos.

4.5 DOCUMENTAÇÃO DE APOIO

Norma de Armazenamento de

Arquivos e Documentos T

Perfis Profissionais T

Como criar uma WBS T

Aplicação : T documento totalmente aplicável à fase; P documento parcialmente aplicável à fase. Documentos : Estão localizados no diretórioH:/Processo ACTI/Metodologia/Material de Apoio

(24)

5

5 Processo de Engenharia de Software - FASE DE ELABORAÇÃO

Processo de Engenharia de Software - FASE DE ELABORAÇÃO

5.1 OBJETIVOS

Nesta fase existe um detalhamos todos os requisitos levantados no Documento de Visão, com o

objetivo de termos a garantia de que todos os requisitos foram levantados e aprovados pelos envolvidos no

projeto e uma atualização do plano do projeto para guiar o processo de execução e controle dos trabalhos.

A fase de Elaboração é marcada pelos diagramas UML que precisam ser produzidos e planos de

gerenciamento de projetos, exigindo habilidades dos membros da equipe em orientação a objetos,

modelagem UML e familiaridade com as ferramentas de modelagem adotadas. Podemos destacar como

objetivos principais desta fase:



Revisar o Plano do Projeto;



Elaborar Planos de Gerenciamento de Projetos;



Elaborar Modelo Conceitual;

(25)

5.2 DIAGRAMA DE ATIVIDADES

ad Elaboração

Início da Fase de Análise e Projeto

3.12 Rev isar Plano do Projeto 3.1 Realizar a Modelagem de Casos de Uso 3.2 Produzir o Documento de Especificações Suplementares Levantamento de Requisitos 3.3 Elaborar o Protótipo 3.4 Elaborar o Modelo Conceitual 3.4.1 Elaborar o Modelo de Entidade e Relacionamento 3.4.2 Elaborar o Diagrama de Classes de Negócio 3.4.3 Elaborar o Diagrama de Ativ idade e/ou

Sequência

3.5 Rev isar Contagem de Pontos de Função 3.6 Atualizar WBS 3.7 Atualizar Cronograma 3.8 Elaborar o Plano Arquitetural 3.9 Elaborar Plano de Implantação 3.10 Elaborar Plano de Gerenciamento de Riscos 3.11 Elaborar o Plano de Teste 3.13 Atualizar o Documento de Visão 3.14 Atualizar Glossário 3.15 Elaborar o Documento de Lições Aprendidas 3.16 Atualizar o Checklist Levantamento de Requisitos Validado?

Artefatos do Plano do Projeto Não

Sim

(26)

5.3 DESCRIÇÕES DAS ATIVIDADES

3.01 Analista de Negócio Realizar a Modelagem de Casos de Uso

 O Analista de Negócio cria e detalha o Modelo de Casos de Uso de Sistema através de reuniões de levantamento de requisitos junto aos usuários;

 Os casos de uso deverão ter um grande nível de detalhes do negócio e serão de fundamental importância para que haja uma boa construção do aplicativo. Os casos de uso são artefatos importantes para encontrar as classes a serem implementadas e servirão como base para os testes do aplicativo produzido;

Consultar a norma para modelagem de casos de uso na pasta Material de Apoio

 Documento de Visão.

Saída:

 Modelo de Casos de Uso de Sistema;  Documento de Visão revisado.

3.02 Analista de Negócio Produzir o Documento de Especificações Suplementares

 As Especificações Suplementares capturam os requisitos de sistema que não são capturados imediatamente nos casos de uso do modelo de casos de uso, também chamados de requisitos não-funcionais.

 O analista de Negócio é responsável pela produção das Especificações Suplementares. As Especificações Suplementares e o modelo de casos de uso juntos devem capturar o conjunto completo de requisitos no sistema.

 Entre os requisitos da Especificação Suplementar estão incluídos:  Requisitos legais e de regulamentação e padrões de aplicativo

 Atributos de qualidade do sistema a ser criado, incluindo requisitos de usabilidade, confiabilidade, desempenho e suportabilidade

 Outros requisitos, como sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de design;

 Modelo de Casos de Uso de Sistema;  Documento de Visão.

(27)

3.03 Analista de Negócio Elaborar Protótipo

 O Analista de Sistemas deve montar um protótipo de interface do Modelo de Casos de Uso de Sistema para a validação do Analista de Negócios e logo após, do Gestor do Projeto. Caso necessário, deverá solicitar ao Analista WEB que revise o conteúdo da Arquitetura da Informação (no documento de visão), detalhando e atualizando o Diagrama de Arquitetura e o Wireframe do projeto para auxiliar na criação do referido protótipo de interface;

 Uma vez validado o protótipo, o modelo de dados final deverá ser definido para ser encaminhado ao Administrador de Banco de Dados, o qual irá criar o banco de dados do sistema (item 4.3).

 Nesta atividade, o Analista de Negócio deverá iniciar, junto aos usuários, a construção da Arquitetura da Informação, baseado no Modelo de Caso de Uso;  A Arquitetura da Informação consiste na atividade de nomear, mapear e

organizar as informações em um site ou sistema, tornando as informações claramente identificáveis e sua distribuição bem definida, criando uma organização lógica com as opções agrupadas de forma intuitiva para o usuário. Possui dois artefatos básicos: o Diagrama de Arquitetura, que demonstra a organização das informações, através de um gráfico hierárquico de distribuição das mesmas (menus, opções, etc.), primando à facilidade de buscar ou pesquisar o que se procura e o Wireframe, que dá a idéia da navegação e mapeia os pesos e prioridades das informações. Se necessário poderá ser utilizada a Matriz de Priorização, para identificar a relevância ou visibilidade das informações ou funcionalidades ou ainda o Mapa de Navegação que define os objetos e navegação do Site ou Sistema.

 Modelo de Casos de Uso de Sistema;  Especificações Suplementares  Documento de Visão.

Saída:

 Modelo de Casos de Uso de Sistema revisado;  Documento de Visão revisado;

 Especificações Suplementares revisado;  Protótipo.

3.04 Analista de Negócio Elaborar Modelo Conceitual

 O Analista de Negócio deve elaborar os artefatos com o auxílio dos Analistas de Sistemas e Administrador de Dados e Objetos que apresentem o conhecimento do negócio identificado através dos requisitos;

 O Administrador de Dados e Objetos deverá identificar as classes persistentes no design; projetar estruturas de banco de dados apropriadas a fim de armazenar as classes persistentes; definir mecanismos e estratégias de armazenamento e recuperação de dados persistentes de modo a atender os critérios de desempenho do sistema;

 Nessa atividade é necessária atenção especial em relação à utilização de novas

(28)

tabelas corporativas, cuja responsabilidade principal recai sobre a equipe de administração de dados e objetos;

 Na criação do MER (Físico), o Analista de Negócio deverá documentar toda a descrição da modelagem na ferramenta (Dicionário de dados).

Os artefatos que compõem a elaboração da modelagem conceitual são: 3.4.1 Elaborar o Modelo Entidade e Relacionamento

 O modelo de dados é usado para descrever a estrutura lógica e possivelmente física das informações persistentes gerenciadas pelo sistema. O modelo de dados é especificamente necessário quando a estrutura de dados persistentes não pode ser obtida mecânica e automaticamente da estrutura de classes persistentes no modelo de design. Além de definir estruturas de dados persistentes, ele é usado para definir o mapeamento entre classes de design persistentes e estruturas de dados persistentes. Consulte a norma para Padronização da Nomenclatura de BD

 Está disponibilizado também o artefato “Interface de Caso de Uso” Seu escopo abrange a descrição do caminho e das características dos campos que deverão compor cada interface relativa ao caso de uso em questão. Caso este caso de uso seja responsável pela emissão de relatórios, a formatação e as informações que compõem os respectivos relatórios também estarão especificadas neste documento.

3.4.2 Elaborar o Diagrama de Classe de Negócio

 O Diagrama de Classe contém as classes de análise e qualquer artefato associado. O modelo de análise pode ser um artefato temporário, como no caso em que evolui para um modelo entidade e relacionamento, ou pode continuar a existir através de parte ou de todo o projeto e, talvez, servindo como uma visão geral conceitual do sistema.

3.4.2 Elaborar o Diagrama de Atividade

 O fluxo de trabalho de um caso de uso o que o sistema deve fazer para fornecer o valor que o ator servido requer. O caso de uso consiste em uma seqüência de atividades que, juntas, produzem algo para o ator. O fluxo de trabalho geralmente consiste em um fluxo básico e um ou mais fluxos alternativos. A estrutura do fluxo de trabalho é descrita graficamente com a ajuda de um diagrama de atividades.

(29)

os objetos interagem para executar o comportamento total ou parcial de um caso de uso. Um ou mais diagramas de seqüência podem ilustrar as interações de objetos que constituem um caso de uso. Uma organização típica deve ter um diagrama de seqüência para o fluxo principal de eventos e um diagrama de seqüência para cada subfluxo independente do caso de uso. Geralmente os diagramas de seqüência são aplicados somente aos casos de uso de grande complexidade de entendimento.

 Documento de Visão;  Modelo de Caso de Uso;  Especificações suplementares;  Protótipo.

Saída:

 Modelo de Entidades e Relacionamentos - MER;  Diagrama de Classes;

 Diagrama de Seqüência;  Diagrama de Atividades;

 Modelo de Casos de Uso de Sistema revisado. 3.05 Analista de Negócio Revisar Contagem de Pontos de Função

 Após a Contagem Estimada de Ponto de Função elaborada na fase anterior, o Analista de Negócio deve produzir a Contagem Detalhada, pois neste momento possui todas as informações para fazer uma contagem mais aproximada do sistema em questão;

 A Análise de Ponto de Função é um método padrão para a medição do desenvolvimento de software de ponto de vista do usuário;

3.06 Analista de Negócio Atualizar WBS

 A WBS – Work Breakdown Structure é uma estrutura que quebra o projeto em partes menores para serem melhor gerenciadas. A WBS define o escopo do projeto, ou seja, o que deverá ser produzido. A WBS é importantes para:

 Ajudar a pensar no projeto antes de ser realizado, é um instrumento de planejamento por excelência;

 Ajuda a deixar claro uqe trabalho será feito;

 Servirá de base para o processo de estimativas de custo, tempo, recurso e riscos;

 Ajuda na organização do projeto;

 Excelente ferramenta de comunicação e ajuda no controle de mudanças durante a execução do projeto.

 Modelo de Casos de Uso de Sistema;  Especificações suplementares;

 Plano do Projeto e seus artefatos (WBS e Cronograma).

Saída:

(30)

 WBS Atualizada 3.07 Analista de Negócio Atualizar Cronograma

 O Analista de Negócio revisa o Cronograma, ao longo desta fase, baseado no Modelo de Casos de Uso de Sistema revisado e nos planos de gerenciamento do projeto elaborados nesta fase.

 Plano do Projeto e seus artefatos (WBS e Cronograma).

Saída:

 Cronograma atualizado 3.08 Administrador de Dados

e Objetos

Elaborar Plano Arquitetural

 O Analista de Negócio deve elaborar o Plano Arquitetural junto com o Administrador de Dados e Objetos com a definição da melhor arquitetura para o sistema, de preferência procurando não ampliar o número de plataformas existentes; Este artefato já deve estar pronto, o Analista de Negócio irá introduzi-lo na documentação do projeto para que os desenvolvedores sigam os padrões estabelecidos no documento.

 O Plano Arquitetural deve compor o Plano do Projeto.

 Documento de Visão;  Plano do Projeto;

 Modelo de Casos de Uso;  Especificações Suplementares.

Saída:

 Plano Arquitetural;  Plano do Projeto revisado. 3.09 Analista de Suporte Elaborar Plano de Implantação

 O Analista de Negócio deve elaborar o Plano de Implantação junto com o Analista de Suporte com a definição inicial dos requisitos necessários para a implantação do sistema;

(31)

 O Analista de Negócio deve identificar os riscos, montar estratégias para diminuir os impactos destes no projeto, controlá-los e auxiliar na tomada de ações que protejam o projeto de seus efeitos negativos, bem como avaliar as oportunidades identificadas;

 O Analista de Negócio deve verificar a necessidade de envolver outros membros da área da Tecnologia de Informação (TI) a fim de contribuir para a elaboração deste Plano, tais como: Analista de Sistemas, Analista de Suporte, Administrador de Dados e Objetos, Administrador de Banco de Dados e a Gestor do Projeto, se necessário;

 O Plano de Gerenciamento de Riscos deve compor o Plano do Projeto.

 Documento de Visão;  Plano do Projeto;

 Modelo de Casos de Uso;  Especificações Suplementares.

Saída:

 Plano de Gerenciamento de Riscos;  Plano do Projeto revisado.

3.11 Analista de Teste Elaborar Plano de Teste

 O Analista de Negócio deve elaborar o Plano de Teste junto com o Analista de Sistemas com a definição das regras que deverão nortear os testes. Este documento contém, por exemplo, a estratégia, os tipos de testes e as ferramentas a serem utilizadas;

 O Plano de Teste deve compor o Plano do Projeto.

 Modelo de Casos de Uso de Sistema;  Especificações suplementares.  Projeto Arquitetural.

Saída:

 Plano de Teste;

 Plano do Projeto revisado.

(32)

3.12 Analista de Negócio Revisar Plano do Projeto

 O Analista de Negócio revisa o Plano do Projeto, ao longo desta fase, baseado no Modelo de Casos de Uso de Sistema revisado e nos planos de gerenciamento do projeto elaborados nesta fase.

 Plano do Projeto e todos os seus artefatos (WBS, Cronograma, ).

Saída:

 Plano do Projeto revisado 3.13 Analista de Sistemas Atualizar o Documento de Visão

 Após todo o planejamento, análise e projeto é recomendável que seja verificado se o documento de visão não deve ser atualizado;

 Outra recomendação é verificar se existe documentação que comprove a necessidade que gerou a alteração no Documento de Visão. Isto possivelmente servirá como justificativa para uma alteração de prazo, escopo ou custo do projeto.

3.14 Analista de Negócio Atualizar Lições Aprendidas

Saída:

 Lições Aprendidas. 3.15 Analista de Negócio Documentar Lições Aprendidas

(33)

3.16 Analista de Negócio Atualizar Checklist

 O Analista de Negócio, com o objetivo de encerrar a fase de Elaboração, efetua uma conferência dos artefatos que foram produzidos até o momento, que deverão ser gravados em um CD e disponibilizados na pasta do projeto;  Caso seja encontrada irregularidade(s), o Analista de Negócio deverá

resolvê-la(s) nesta atividade;

Saída:

 Checklist.

5.4 RESUMO DOS ARTEFATOS

Diagrama de Casos de Uso de Sistema

C Enterprise

Architect --- Visa fornecer o domínio do problema atravésda diagramação entre atores, casos de uso e suas respectivas associações.

Especificação Caso de Uso de Sistemas

C Microsoft Word SiglaDoProjeto_EspC asoUsoSist_NomeCa

soUso.dot

Visa detalhar as atividades a serem executadas através da descrição dos tópicos do fluxo principal, fluxo alternativo, pré-condições e pós-pré-condições.

Especificações

Suplementares C Microsoft Word SiglaDoProjeto_EspSuplementar.dot A proposta deste documento é definir osrequisitos do sistema que não são capturados diretamente através dos casos de uso. Este documento será breve e deverá conter requisitos como: tempo de retorno de consulta, tempo limite de processamento de funcionalidade.

Protótipo C --- SiglaDoProjeto_DocA

pres.dot

Versão beta do sistema a ser construído, com a finalidade de validar as informações coletas nas fases anteriores. Servindo ainda, como elemento de validação da arquitetura candidata do sistema em questão.

Poderá ser utilizado também o documento de Apresentação que contém o Diagrama de Arquitetura da Informação e o Wireframe. Modelo de

Entidades e Relacionamentos

C Enterprise

Architect --- Visa representar o modelo lógico detalhadoque captura a estrutura dos dados organizacionais, independente de qualquer sistema de gerenciamento de banco de dados. Diagrama de

Classes

C Enterprise

Architect

--- Este documento permite a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como demonstra como as classes do diagrama se relacionam, complementam e transmitem

(34)

informações entre si. Diagrama de

Seqüências

C Enterprise

Architect

--- Este diagrama procura determinar a seqüência de eventos que ocorrem em um determinado processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo específico. Diagrama de

Atividades C EnterpriseArchitect --- Visa descrever os passos a serem percorridospara a conclusão de um método ou algoritmo específico.

Documento de Análise de Ponto de Função

R Microsoft Excel SiglaDoProjeto_APF.

xls

Documento que armazena as

_{informações sobre as estimativas criadas}

para a aplicação da análise de ponto de

função para um projeto.

WBS - Work Breakdown Structure

R

WBS ChartPro ---

Work Breakdown Structure - utilizado

para estruturação do escopo de projetos

sob a forma de atividades e

sub-atividades.

Cronograma R

Microsoft Project

--- Atualização do

_{atividades no decorrer do tempo por meio}

planejamento das

de diagramas, gráficos e planilhas.

Plano Arquitetural

C Microsoft Word SiglaDoProjeto_ProjA rquit.dot

Este documento descreve a estrutura da aplicação, focando em requisitos funcionais e não funcionais (segurança, reusabilidade, desempenho).

Plano de Implantação

C

Microsoft Word SiglaDoProjeto_PImp .dot

Seu escopo abrange a definição dos requisitos de hardware e software necessários para a instalação do produto, bem como os recursos humanos necessários para a execução das atividades previstas no procedimento de instalação

Plano de Gerenciamento de Riscos

C

Microsoft Word SiglaDoProjeto_Plano

Risco.dot A proposta deste documento é apresentar edescrever os riscos associados ao projeto e o processo de gerenciamento destes riscos. Seu escopo abrange a definição das características dos riscos do projeto, a forma de manifestação dos mesmos durante do projeto e o plano de contingência aplicável. As atividades e responsabilidades necessárias ao processo de gerenciamento destes riscos, também são estabelecidos através deste documento.

Plano de Teste C Microsoft Word SiglaDoProjeto_Plano Teste.dot

Este documento apresenta os requisitos a serem testados, os métodos de qualificação, a estratégia adotada para a execução dos testes, a descrição dos testes, os recursos humanos e computacionais necessários, bem

(35)

Wireframe com a estrutura do conteúdo de cada página, indicando o peso e relevância de cada elemento do layout e sua relação com os demais elementos formadores do todo.

ario.dot

Engloba as definições, acrônimos e

_{abreviações utilizadas nos documentos}

do projeto.

Lições Aprendidas

R Microsoft Word SiglaDoProjeto_Licoe sAprendidas.dot

Este documento visa documentar as experiências relatadas pelos membros do projeto, a fim de que estas sejam utilizadas em futuros projetos.

kList.dot Este documento contém os artefatos a seremverificados na fase e informações de data da entrega do artefato, data da aprovação do artefato e ultima versão – a mais atual.

5.5 DOCUMENTAÇÃO DE APOIO

Norma de Armazenamento de Arquivos e Documentos T Padrão de Arquitetura de Sistemas T Perfis Profissionais T

Manual de Identidade Visual P Padronização da

Nomenclatura de BD T Este documento tem como objetivo propor a nomenclatura, que será utilizada na criação dos modelos de banco de dados dos sistemas desenvolvidos e adquiridos pelo Sistema Indústria.

Norma para modelagem de casos de uso

T Este documento tem como objetivo estabelecer conceitos básicos e recomendações a serem levadas em consideração durante as atividades de levantamento e modelagem utilizando casos de uso.

(36)

6

6 Processo de Engenharia de Software - FASE DE CONSTRUÇÃO

Processo de Engenharia de Software - FASE DE CONSTRUÇÃO

6.1 OBJETIVOS

A fase de Construção e Teste é marcada pela construção dos casos de uso de tal forma que o

desenvolvimento do sistema esteja finalizado ao final desta fase.

Podemos destacar como objetivos principais desta fase:



Revisar Modelo Conceitual e Plano do Projeto;



Elaborar documentação de suporte ao usuário;



Construir, testar e obter a homologação do sistema.

6.2 DIAGRAMA DE ATIVIDADES

ad Construção

Início da Fase de Construção

4.1 Refinar Modelo Conceitual 4.2 Criar Banco de Dados 4.3 Gerar Código Fonte 4.7 Testar 4.5 Rev isar Plano

do Proj eto 4.6 Elaborar documentação de Suporte ao Usuário 4.8 Homologar Pacote 4.9 Atualizar Lições Aprendidas 4.11 Atualizar Checklist 4.4 Elaborar o Roteiro de Teste 4.10 Atualizar Artefatos

(37)

6.3 DESCRIÇÕES DAS ATIVIDADES

4.1 Analista de Negócio Refinar Modelo Conceitual

 O Analista de Negócio, Analista de Sistemas e Administrador de Dados e Objetos revisam os modelos conceituais ajustando de acordo com o melhor conhecimento do sistema.

 Modelo de Casos de Uso de Sistema;  Diagrama de Classes;  Diagrama de Atividades;  Diagrama de Seqüência;  Protótipo  MER. Saída:

 Diagrama de Classes revisado;  Diagrama de Seqüência revisado;  Diagrama de Atividade revisado;  MER revisado.

4.2 Administrador de Banco

de Dados Criar banco de dados_ _{O Analista de Negócio deve verificar se há um ambiente de desenvolvimento} adequado, se não existir deverá solicitar ao Analista de Suporte que providencie a criação deste ambiente, observando as definições estabelecidas no Plano de Implantação;

 O Analista de Negócio disponibiliza ao Administrador de Banco de Dados os modelos de dados referentes ao sistema para criação do banco de dados no ambiente de desenvolvimento. Artefato(s): Entrada:  Diagrama de Classes;  MER (Físico). Saída:

 Script de criação do banco. 4.3 Desenvolvedor Gerar código fonte

 O Desenvolvedor efetua a codificação por pacote dos componentes do sistema no ambiente de desenvolvimento, de acordo com as definições elaboradas pelo Analista de Negócio.

 MER (Físico);

 Modelo de Casos de Uso de Sistema;  Diagrama de Classes;

 Diagrama de Seqüência;  Documento de Visão;

(38)

 Protótipo.

Saída:

 Pacotes codificados.

4.4 Testador Elaborar o Roteiro de Testes

 O Roteiro de teste é a definição (geralmente formal) de um conjunto específico de entradas(inputs) de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um item de Teste-alvo.

 Com base no Plano de Teste e no Modelo de Caso de Uso o Testador elabora um roteiro de testes para serem aplicados na validação do sistema efetua a codificação por pacote dos componentes do sistema no ambiente de desenvolvimento, de acordo com as definições elaboradas pelo Analista de Negócio.

 Não há representação em UML para este artefato.

 MER (Físico);

 Modelo de Casos de Uso de Sistema;  Diagrama de Classes;  Diagrama de Seqüência;  Documento de Visão;  Protótipo. Saída:  Roteiro de Teste. 4.5 Analista de Negócio Revisar Plano do Projeto

 O Analista de Negócio revisa os Planos de Risco, Implantação, Arquitetural e de Testes.

 Plano do Projeto:

 Plano de Gerenciamento de Riscos;  Plano de Implantação;

 Plano Arquitetural;  Plano de Testes.

Saída:

(39)

4.6 Analista de Negócio Elaborar Documentação

 O Analista de Negócio deverá elaborar a documentação do sistema que servirá de suporte ao usuário, conforme acerado nos produtos à serem entregues no Documento de Visão.

 Modelos de caso de uso;  Plano Arquitetural;  Plano de Implantação;  Modelos conceituais.

Saída:

 Documentação de Suporte ao Usuário:  Manual do usuário;

 Manual do sistema. 4.7 Analista de Testes Testar

 O Analista de Testes deve executar testes nos pacotes do sistema de acordo com o Plano de Testes e registrar os resultados no documento de Roteiro de Teste. Após este procedimento, deve disponibilizar este sumário ao Analista de Negócio para testes e validação do pacote;

 O Analista de Negócio deve validar os componentes à medida que os pacotes forem sendo entregues, registrando os resultados no Roteiro de Teste e devolvendo ao Analista de Testes para que realize os ajustes necessários no sistema.

 Modelo de Casos de Uso de Sistema;  Plano de Teste;

 Pacotes codificados.

Saída:

 Plano de Teste revisado;  Roteiro de Testes revisados;  Testes executados.

(40)

4.8 Gestor do Projeto Homologar Pacote

 O Analista de Negócio deve verificar se há um ambiente de homologação adequado, se não existir deverá solicitar ao Analista de Suporte que providencie a criação deste ambiente, observando as definições estabelecidas no Plano de Implantação;

 Uma vez criado o ambiente de homologação, o Analista de Negócio deve verificar com o Gestor do Projeto as pessoas que irão realizar os testes no sistema;

 Após a validação e testes de todos os pacotes do sistema, além do teste integrado do mesmo, o Analista de Negócio deve solicitar ao Gestor do Projeto a assinatura do Termo de homologação do sistema;

 O Analista de Negócio deve revisar os Planos de Implantação e Arquitetural com o objetivo de detectar ajustes necessários, decorrentes de erros detectados durante os testes de homologação.

 Sumário de resultados dos testes;  Plano do Projeto.

Saída:

 Sumário de resultados dos testes;  Plano do Projeto revisado;  Termo de Homologação. 4.9 Analista de Negócio Documentar Lições Aprendidas

 O Analista de Negócio deverá avaliar o trabalho feito na fase. Essa avaliação consiste em reunir com os participantes do projeto ao final da fase, levantar todos os aspectos positivos e negativos e documentar para formar uma base de conhecimento tanto para o projeto atual, quanto para outros projetos futuros do Sistema Indústria.

Saída:

 Lições Aprendidas. 4.10 Analista de Negócio Atualizar Artefatos

(41)

4.11 Analista de Negócio Atualizar Checklist

 O Analista de Negócio, com o objetivo de encerrar a fase de Construção e Teste do Projeto, efetua uma conferência dos artefatos que foram produzidos até o momento, que deverão ser gravados em um CD e disponibilizados na pasta do projeto;

 Caso seja encontrada irregularidade(s), o Analista de Negócio deverá resolvê-la(s) nesta atividade;

Saída:

 Checklist.

6.4 RESUMO DOS ARTEFATOS

Plano de Gerenciamento de Riscos

R

Microsoft Word SiglaDoProjeto_Plano Risco.dot

A proposta deste documento é apresentar e descrever os riscos associados ao projeto e o processo de gerenciamento destes riscos. Seu escopo abrange a definição das

características dos riscos do projeto, a forma de manifestação dos mesmos durante do projeto e o plano de contingência aplicável. As atividades e responsabilidades necessários ao processo de gerenciamento destes riscos também são estabelecidos através deste documento.

Plano de Implantação

R

Microsoft Word SiglaDoProjeto_PImp .dot

Seu escopo abrange a definição dos requisitos de hardware e software necessários para a instalação do produto, bem como os recursos humanos necessários para a execução das atividades previstas no procedimento de instalação

Plano Arquitetural

R Microsoft Word SiglaDoProjeto_ProjA rquit.dot

Este documento descreve a estrutura da aplicação, focando em requisitos funcionais e não funcionais (segurança, reusabilidade, desempenho).

Plano de Teste R Microsoft Word SiglaDoProjeto_Plano

Teste.dot Este documento apresenta os requisitos aserem testados, os métodos de qualificação, a estratégia adotada para a execução dos testes, a descrição dos testes, os recursos humanos e computacionais necessários, bem como os relatórios que darão suporte ao processo de avaliação de resultados.

Diagrama de Classes

R Enterprise

Architect

--- Este documento permite a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como demonstra como as classes do diagrama se relacionam, complementam e transmitem informações entre si.

Diagrama de R Enterprise --- Este diagrama procura determinar a seqüência

(42)

Seqüência Architect de eventos que ocorrem em um determinado processo, ou seja, quais condições devem ser satisfeitas e quais métodos devem ser disparados entre os objetos envolvidos e em que ordem durante um processo específico. Diagrama de

Atividades

R Enterprise

Architect

--- Visa descrever os passos a serem percorridos para a conclusão de um método ou algoritmo específico.

Protótipo R --- --- Versão beta do sistema a ser construído, com

a finalidade de validar as informações coletas nas fases anteriores. Servindo ainda, como elemento de validação da arquitetura candidata do sistema em questão.

ario.dot

Engloba as definições, acrônimos e

_{abreviações utilizadas nos documentos}

do projeto.

Pacotes Codificados

C --- --- Constituem os arquivos físicos para execução

da aplicação, neles estão descritos de forma sistêmica as regras de negócio da solução. Roteiro de Teste C Microsoft Word SiglaDoProjeto_Rotei_{roTeste_NomeCasoU}

so.dot

Visa fornecer um resumo das informações resultantes do teste, a fim de conferir o grau de qualidade do sistema.

Documentação de suporte ao usuário

C Microsoft Word --- A documentação de suporte ao usuário contém as seguintes informações:

Manual do Usuário – orienta quanto à correta utilização do sistema.

Manual do Sistema – orienta quanto à correta implantação e configuração do sistema. Termo de

Homologação C Microsoft Word SiglaDoProjeto_TermoHomolog.dot Este termo visa atestar que os serviços eprodutos realizados foram concluídos e estão em conformidade com os requisitos levantados junto ao usuário.

Lições

Aprendidas C Microsoft Word SiglaDoProjeto_LicoesAprendidas.dot Este documento visa documentar asexperiências relatadas pelos membros do projeto, a fim de que estas sejam utilizadas em futuros projetos.

kList.dot Este documento contém os artefatos a seremverificados na fase e informações de data da entrega do artefato, data da aprovação do artefato e ultima versão – a mais atual.

(43)

Manual de Identidade Visual P Padronização da

Nomenclatura de BD

T Este documento tem como objetivo propor a nomenclatura, que será utilizada na criação dos modelos de banco de dados dos sistemas desenvolvidos e adquiridos pelo Sistema Indústria.