O documento descreve o status de projetos de TCC de alunos de Sistemas de Informação. Apresenta 13 projetos diferentes, com seus respectivos nomes, objetivos e integrantes. Fornece detalhes adicionais sobre o projeto "FCP - Ferramenta de Controle Patrimonial", incluindo seu escopo, funcionalidades, arquitetura e cronograma.
3. Os próximos slides fazem parte de uma
atividade realizada pelos alunos da turma
SIN-NA7 (7º semestre de Sistemas de
Informação – 1º semestre de 2014)
Tema da atividade: Status Report do ProjetoTCC
4. # Nome do Projeto
1 FCP – Ferramenta de Controle Patrimonial
2 GEFI - Gestão Financeira
3 Sistema GOOCC
4 MaSoft
5 MKOFFICE
6 Sistema de gerenciamento de pedido para bares
7 Sistema de Pregão Online
8 SAF – Sistema de Agendamento de Formatura
9 Sistema Gerenciador de Processos Jurídicos
10 S.I.A – Sistema Integrado de Agendamento
11 Smart
12 Synergy
13 Appolo CMS
5. PRONTUÁRIO NOME
11101445 Carlos EduardoTorres
11104146 Felipe de Sousa Marques
11100647 Igor Luiz de Sousa Santos
11101418 Nilton José PiresGonçalves Junior
Índice
7. PRONTUÁRIO NOME
11101445 Carlos Eduardo Torres
11104146 Felipe de Sousa Marques
11100647 Igor Luiz de Sousa Santos
11101418 Nilton José Pires Gonçalves Junior
9. Atualmente, o processo de controle
patrimonial é feito de forma manual.
O sistema de chamados técnicos para itens
defeituosos é bem demorado para ser
resolvido e não há um controle efetivo.
Além disso, deve-se evitar que equipamentos
sejam furtados, pois alguns deles custam na
faixa de R$ 30.000 reais, convertidos do
dólar.
10. Desenvolver um sistema que realize o
controle patrimonial de uma empresa,
Fazer a abertura de chamados técnicos (itens
defeituosos)
Identificar quando uma tentativa de subtração
de um patrimônio acontecer.
11. Tornar o processo de inventário do
patrimônio fixo da empresa mais rígido e
mais preciso.
Tornar as aberturas e atendimentos de
chamados mais eficientes, permitindo
consultar o status do atendimento do
chamado.
Controlar a locomoção dos recursos dentro
do ambiente previnindo subtrações destes.
12. Sistema web, desenvolvido em PHP e banco
de dados MySQL. Para se fazer o controle
patrimonial
Utilização da tecnologia de captura de dados
com RFID (Identificação por rádio frequência)
◦ Utilização de um leitor de curto alcance para
efetuar a captura de dados dos recursos.
◦ Utilização de um leitor de longo alcance para
monitorar a locomoção dos recursos dentro do
ambiente.
13. Diagrama de Caso de Uso;
Diagrama de Classe;
Descrição de Caso de Uso;
Diagrama de Sequência;
Modelo Descritivo;
Modelo de Entidade Relacionamento (MER):
◦ Mapeamento do MER para modelo Relacional;
◦ Modelo Lógico de dados;
◦ Normalização, Dicionário de dados;
◦ Modelo Físico de dados, Scripts SQL (DDL e DML e DQL);
Apresentação do sistema.
14.
15. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O projeto deve estar concluído até o final deste ano R
O sistema deverá ser desenvolvido na plataforma web R
O projeto deverá ser concluído sem alteração de
membros da equipe.
P
Igor será responsável pela documentação do projeto P
Carlos será responsável pelo desenvolvimento do
projeto
P
Semanalmente deverá ser apresentado protótipos da
aplicação para os Steakholders
P
17. PAPEL RESPONSABILIDADES
Carlos Eduardo Torres Desenvolvedor
Felipe Marques Gerente do projeto; Desenvolvedor
Igor Luiz Sousa Analista de requisitos; DBA
Nilton Gonçalves Analista de Testes
19. 2° Semana de Maio
◦ Criação do módulo de cadastro de usuários;
◦ Encaminhamento do módulo para o testador;
◦ Atualização da documentação de Banco de Dados;
◦ Criação do Módulo de Cadastro de Inventário;
◦ Encaminhamento do módulo para o testador;
3° Semana de Maio
◦ Criação do módulo de cadastro/alteração de recurso;
◦ Encaminhamento do módulo para p testador;
◦ Elaboração de protótipos da aplicação para amostragem ;
◦ Apresentação dos protótipos para os stakeholders;
20. 4° Semana de Maio
◦ Criação do módulo de Abertura de Chamados técnicos;
◦ Criação do módulo de relatórios sobre os recursos;
◦ Encaminhamento dos módulos para o testador;
5° Semana de Maio
◦ Validação da documentação da aplicação;
◦ Ajustes finais na documentação a ser entregue para os stakeholders;
◦ Criação da apresentação da aplicação parcial para os stakeholders;
1° Semana de Junho
◦ Apresentação da aplicação parcial para os stakeholders;
21. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não Atendimento
do prazo
N 15 Mitigar Fazer um bom
gerenciamento do
tempo. Prever
possíveis atrasos.
Paralelizar funções
2 Sáida de um
membro da
equipe
N 9 Eliminar Motivar a equipe;
melhorar o
entrosamento do
grupo
3 Não atendimento
ao escopo
N 10 Eliminar Realizar pontos de
verificação dentro do
projeto, para
averiguar se está
dentro do escopo
22. DATA DESCRIÇÃO DA MUDANÇA
10/05/2014 Adição de novos atributos em algumas entidades no
modelo de entidades relacional (MER)
10/05/2014 Remoção de Relacionamentos no modelo de entidades
relacional (MER)
10/05/2014 O desenvolvimento do módulo de usuários será realizado
na 3° semana de maio
23. # DESCRIÇÃO
1
Realmente é importante possuir uma documentação atualizada
para auxiliar os desenvolvedores
2
Os desenvolvedores devem sempre comunicar o responsável pela
documentação sobre alterações nos módulos da aplicação
3 O comprometimento de todos é essencial
4 É necessário que todos possuam bom humor
5 Discussões sempre são necessárias
29. O dia-a-dia das pessoas é cada vez mais
exaustivo, não permitindo tanto tempo para
se organizarem.
Nem sempre o uso de planilhas ou até
aplicativos de controle financeiros, são
sinônimos de controle eficiente de despesas.
O GEFI foi desenvolvido com uma visão mais
detalhada do processo para suprir as
necessidades do cliente.
30. O GEFI visa facilitar o gerenciamento das
despesas pessoais, permitindo que o usuário
tenha maior controle de seus gastos.
Evita maiores gastos com juros e acréscimos
que são causados pela falta de tempo,
organização e planejamento.
31. A diminuição dos gastos;
Evita desperdícios de dinheiro (juros e
acréscimos);
Melhor organização das despesas;
Maior conhecimento das finanças.
32. Utilizando o GEFI o usuário terá controle das
datas de vencimentos das contas já
cadastradas pelo mesmo;
O valor a ser pago, caso a conta esteja
atrasada;
Lembretes informativos de vencimento de
suas contas ou lembretes opcionais ,como
por exemplo, o cliente quer ser avisado uma
semana antes da conta vencer.
33. Descritivo do sistema;
Documentação de regra de negócios;
Especificação funcional;
Caso de Uso;
Diagrama de Casos de Uso;
Descritivo dos Atores;
Diagrama de Classes;
Diagrama Sequencial;
Cronograma;
Protótipos de tela;
Apresentação do sistema.
34. GEFI
Documentação
Engenharia De
Software
Descrição de
Casos de Usos
Regras de
Negócio
Requisitos
Funcionais
Diagramas
Diagrama de
Classes
Diagrama de
Sequência
Diagrama de
Casos de Uso
Testes
Plano de Testes
Script de Testes
Evidências de
Testes
Levantamento
de Dados
Relatório de
Pesquisas
Banco de Dados
Descritivo Modelos
ER
Relacional
Lógico
Scripts
DDL
DQL
DML
Sistema
Cadastros
Despesa Lembrete
Comum
Retroativo
Usuários Administrador
Relatórios
Controle de
acesso
Usuários
Administrador
Implantação
Manual do
usuário
35. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
A equipe é composta por 4 membros Premissa
O sistema será finalizado em julho de 2014 Premissa
Possui dois desenvolvedores Premissa
O projeto deve ser concluído antes da primeira semana
de dezembro
Restrições
O numero de integrantes do grupo não pode ultrapassar
a 5 e nem ser inferior a 2
Restrições
O projeto deve ser desenvolvido apenas na Linguagens
C#, Java ou PHP
Restrições
O projeto deve conter apenas 1 diferencial Restrições
36. Tamires Andrade
Gerente de Projeto
Nicole Mitie e Helio
Trindade
Documentador
Hélio Trindade e
Rafael Petrus
Analista de negócios
Rafael Petrus e
Tamires Andrade
Desenvolvedor
Nicole Mitie, Helio
Trindade e Rafael
Petrus
DBA
37. PAPEL RESPONSABILIDADES
Gerente do Projeto Realizar a gestão do projeto, acompanhar o
desenvolvimento e gestão de prazos.
Desenvolvedor Desenvolver o sistema
Analista de negócios Levantar os requisitos e as regras de
negocio para desenvolver o projeto
DBA Criar a documentação e a estrutura do
Banco de Dados
39. Finalização da documentação de Banco de
Dados
Processo de desenvolvimento da
documentação do Sistema
Início do desenvolvimento do Sistema
40. Requisitos Funcionais
Diagrama de Classes
Diagrama de Casos de Uso
Documentação de Banco de Dados(DDL, DML,
DQL)
41. # DESCRIÇÃO TP CRITIC. SIT. AÇÕES
1 Entrega fora do prazo N 25 Mitigar Negociar com a banca para
aumentar o prazo
2 Só ficar um membro do
grupo
N 05 Aceitar Procurar novos membros para o
grupo
3 O tema for reprovado
pelos professores
N 10 Mitigar Melhorar as funcionalidades do
sistema ou mudar o tema
4 Os dois desenvolvedores
saírem do grupo
N 03 Aceitar Mudar a linguagem de programação
do sistema para uma linguagem que
o restante do grupo conheça
5 Faculdade não aceitar o
C# como linguagem de
desenvolvimento do TCC
N 03 Aceitar Mudar a linguagem de programação
do sistema
6 Entrega antes do prazo P 10 Melhorar Realizar um cronograma para
antecipar as entregas
7 Software diferente da
documentação
N 06 Mitigar Fazer alterações no software ou
alterar a documentação
42. DATA DESCRIÇÃO DA MUDANÇA
01.02.2014 Nicole entrou no grupo
20.02.2014 Rafael entrou no grupo
02.03.2014 Mudança no escopo do projeto (funcionalidade Evento)
43. # DESCRIÇÃO
1 Melhorar a comunicação do grupo/ distribuição de tarefas
2 Não deixar as coisas para a última hora
3 Realizar pesquisas mais aprofundadas
49. Devido a carência de soluções na área de
construção civil, o GOOCC irá auxiliar no
controle de projetos.
50. Gerenciamento de etapas, custos e
orçamentos de diversos tipos de projetos
voltados à construção civil
51. Controle de custos, redução de desperdícios,
geração de indicadores e maior controle de
prazos
52. Sistema web instalado em um datacenter
desenvolvido em ASP.net e linguagem de
programação C#, usando um banco de dados
SQL Server e Crystal Reports para
desenvolvimento de relatórios
53. Diagrama de Casos de Uso;
Diagrama de Classes;
Diagrama de Sequência;
Modelo Entidade e Relacionamento;
Dicionário de dados;
Modelos físico e lógico de dados.
54. Documentação de Engenharia de Software;
Documentação de Banco de Dados;
Desenvolvimento do Software;
Apresentação do projeto;
55. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
Os cinco integrantes realização a apresentação do projeto (P)
A apresentação ocorrerá na UNIFIEO (P)
A UNIFIEO disponibilizará internet no dia da apresentação (P)
O TCC será finalizado sem mudanças de membros do grupo (P)
A nota do TCC não pode ser inferior à 6 (R)
A entrega e a apresentação devem ocorrer em novembro de
2014
(R)
O grupo pode ter no máximo 5 integrantes (R)
O sistema pode ser desenvolvido nas linguagens: C#, Java e
PHP
(R)
A apresentação deverá durar até 15 minutos (R)
57. PAPEL RESPONSABILIDADES
Gerente de Projeto Delegar as tarefas entre os membros da
equipe do projeto, acompanhar as etapas
de desenvolvimento
Engenheiro de Software Realizar a documentação do sistema
Analista de Teste Testar e reportar os erros do sistema para
os desenvolvedores e o gerente
DBA Administrar o banco de dados do sistema
60. Fim de maio: apresentação para pré-banca e
entrega da documentação;
Dezembro: apresentação para banca e
entrega da documentação atualizada com
versão final do projeto
61. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não
atendimento
ao prazo
(N) 5 Em mitigação Gerenciamento do
tempo para
desenvolvimento do
projeto
2 Saída de
membros da
equipe
(N) 4 Em mitigação Redistribuição das
tarefas relacionadas ao
projeto entre os
membros restantes
3 Finalização
antes do
prazo
(P) 1 Em mitigação Manter o modo em que
o grupo vem
trabalhando, uma vez
que este mostrou-se
eficaz e aumentou as
chances desse risco
acontecer.
62. DATA DESCRIÇÃO DA MUDANÇA
Mai/14 Inclusão das áreas de Contrato, de Cotação e de Etapas no
escopo do projeto.
Início do desenvolvimento desses novos itens.
63. # DESCRIÇÃO
1
Dividir bem as tarefas entre cada membro do grupo, valorizando
o que cada indivíduo tem de melhor para oferecer ao
desenvolvimento do projeto, e respeitando também, as limitações
de cada um
2
É necessário registrar cada mudança e avanço dentro do projeto,
para assegurar que o desenvolvimento está fiel ao escopo e que
será finalizado dentro do prazo
3
Consultar frequentemente stakeholders internos e externos (cada
um com sua frequência, de acordo com a necessidade), para
notificá-los de progresso/regresso no decorrer do projeto, além
de solicitar orientação, quando necessária
4
5
65. PRONTUÁRIO NOME
11101013 Augusto Cesar Camarotto
11102716 Gilvan Gomes da Silva Junior
11100414 Guilherme Alencar
11101199 Rodrigo Pereira de Souza
Índice
67. Dados do Grupo
Prontuário Nome
11101013 Augusto Cesar Camarotto
11102716 Gilvan Gomes da Silva Junior
11100414 Guilherme Alencar
11101199 Rodrigo Pereira de Souza
69. Foi escolhido o tema devido a carência
do mercado de sistemas para atender a
norma de Segurança da Informação
chamada PCI DSS.
70. Desenvolver um sistema para facilitar o
atendimento a norma PCI DSS.
71. Criar um preenchimento de SAQ mais intuitivo.
Dar mais controle da conformidade dos
estabelecimentos para as adquirentes.
Facilitar os processos dos envolvidos com a
norma.
72. Um sistema WEB desenvolvido em .NET de
preenchimento online de SAQs e controle do
nível de conformidade de um
estabelecimento quanto a norma do PCI DSS.
73. Aprender mais sobre a norma PCI DSS.
Desenvolver um sistema.
Documentar o que foi desenvolvido.
74. Projeto MaSoft
Gerente do
Projeto
Plano de
Gerenciamento
- Planejamento dos Requisitos.
- Planejamento do Escopo.
- Planejamento do Cronograma.
Produção
- Gerenciamento de conteúdo.
- Preparação e edição do conteúdo.
Testes.
Encerramento
- Divulgação.
- Especificações do produto.
- Avaliação do produto.
- Lições aprendidas.
- Encerramento do Projeto.
75. Descrição
(P )
Premissa
(R )
Restrição
Tem que conter no máximo cinco
integrantes
R
O projeto precisa ser concluido no prazo R
É preciso que o integrante Guilherme
participe das atividades
P
77. Papel Responsabilidade
Desenvolvedor
Codificar o sistema de acordo com a documentação gerada
pelo Analista de Sistemas.
Gerente de
Projetos
Coordenar a equipe, estabelecer prazos e metas.
Analista de
Sistemas
Documentar o sistema de acordo com as orientações do
Analista de Requisitos.
Analista de
Requisitos
Aprender tudo sobre o tema e levantar as necessidades do
cliente e documenta-las.
79. Setembro Outubro Novembro Dezembro
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Documentação Responsável
Mer. Guilherme
Modelo Relacional. Augusto
Diagrama de Caso de Uso. Guilherme
Diagrama de Sequência. Augusto
Modelo Descritivo. Guilherme
Dicionário de Dados. Rodrigo
Desenvolvimento. Gilvan
Normalização. Juninho
80. Entrega Atividade
10/05/20
14
Status Report
13/05/20
14
MER, Modelo Relacional, Modelo Descritivo,
Diagrama de caso de uso.
30/05/20
14
MER, Modelo Relacional, Modelo Descritivo,
Diagrama de caso de uso, MER para Modelo
Relacional, Dicionário de dados.
81. # Descrição Tipo Critic.
Situa
ção
Ações
1
O Projeto ser aprovado com a
nota máxima.
Positivo Media Continuar se dedicando ao projeto.
2
A não conclusão do projeto no
prazo.
Negativo Alta
Se dedicar, não iguinorar os conselhos
do orientador e manter o grupo
unido.
3
Um membro da equipe ficar
nervoso e não conseguir
apresentar bem o projeto.
Negativo Pequena Treinar todos os membros da equipe.
82. Data Descrição da Mudança
20/07/2014 Acrescentar mais SAQs ao sistema.
22/07/2014 Alterar documentação
25/07/2014 Incluir "Wizzard" ao sistema
26/07/2014 Alterar documentação
83. # Lições aprendidas
1 Realizar reuniões semanais.
2
Ajudar os colegas de grupo até mesmo em
atividades não relacionadas ao projeto.
3 Ficar atento aos prazos.
4 Cada detalhe é fundamental para o sucesso.
89. Atualmente as consultoras não costumam fazer
anotações sobre vendas, pedidos, clientes,
produtos, etc. Há exceções de consultoras que
fazem anotações em cadernos, ou até mesmo
criam um documento em formato de planilha
(.xls).
Este projeto irá fazer com elas possuam todos os
dados do negocio em um único lugar, visando
dar mais praticidade as suas atividades e
possibilitar uma visão geral do andamento de seu
negocio. Assim as consultoras poderão tomar
decisões mais precisas em relação às quais
produtos solicitar à Mary Kay e quais os clientes
que devem ter atenção em seus atendimentos.
90. Prover o gerenciamento total do negocio
fornecendo funcionalidades para o controle
de equipes, clientes, produtos, pedidos e
vendas.
91. Prover de forma completa o gerenciamento
do negócio das consultoras.
92. Sistema web, desenvolvido na linguagem
JAVA e banco de dados MySQL.
93. Documentos de Engenharia de Software
Documentos de Banco de Dados
Produto
Apresentação do Produto
97. PAPEL RESPONSABILIDADES
Gerente de Projeto Acompanhar as atividades da equipe;
Criar os planos do projeto.
Analista de Negócios Levantar os requisitos junto ao cliente.
Analista de Testes Realizar testes e validações no produto.
Desenvolvedor Desenvolver o produto.
Documentador Criar a documentação do projeto.
99. 1 2 3 4 5 1 2 3 4 1 2 3 4 5 1 2 3 4
DOCUMENTAÇÃO RESPONSÁVEL
DESCRIÇÃO DE CASO DE USO
Mapear requisitos funcionais Thiago
Mapear requisitos não funcionais Thiago
Mapear regras de negócio Thiago
Criar documento Thiago
Inserir diagramas Thiago
DIAGRAMA DE CASO DE USO
Identificar atores Thiago
Definir casos de uso Thiago
Criar diagramas Thiago
DIAGRAMA DE CLASSE
Criar diagrama Thiago
BANCO DE DADOS
Modelo Entidade e Relacionamento Thiago
Mapeamento do MER para o modelo Relacional Thiago
Dicionario de Dados Thiago
Normalização Thiago
SISTEMA
Relatorios
Relatorios Christopher
Layout
Layout Christopher
JUNHO JULHO AGOSTOMAIO
100. Descrição Data
Entrega para a disciplina Tópicos
Avançados em Desenvolvimento de
Software
09/05/2014
Entrega para a disciplina de Gestão
de Projetos e Empreendedorismo
10/05/2014
Entrega da documentação para a
pré-qualificação do TCC
30/05/2014
101. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Entrega do
Projeto
N 5 Em mitigação Não atrasar as
entregas
2 Possibilidade de
Empreender o
projeto
P 3 Em mitigação Divulgar o projeto
para as consultoras
109. Prover uma ferramenta que realize o
gerenciamento do pedido em bares com foco
na divisão de contas individualmente em uma
mesa e a informatização da realização de
pedidos via dispositiveis móveis
110. Desenvolver uma ferramenta cujo foco é a
automação e informatização de
estabelecimentos (bares) que façam uso de
comandas. Prover o gerenciamento da divisão
de contas de forma justa e a informatização
via dispositivos móveis na forma como é
realizada os pedidos nesses
estabelecimentos.
111. Divisão de contas de forma igual e justa.
Agilidade, automação e informatização na
realização de pedidos. Emissão de relatórios
gerenciais. Eliminação de desperdícios de
produtos.
112. Sistema web, hospedado internamente no
cliente, desenvolvido em C# e HTML5, com
banco de dados em SQL com interface
interativa acessível através de tablets onde
será possível realizar os pedidos no
estabelecimento
113. Diagrama de caso de uso
Diagrama de classe
Diagrama de entidade relacional
Descrição de caso de uso
Script de testes a serem realizados
Requisitos mínimos para instalação do projeto
Apresentação do sistema
Treinamento para funcionários
Manual de configuração do sistema
114. Sistema de gerenciamento de pedidos em
bares
Documentação
Descrição de
Caso de Uso
Regras de
Negócio
Requisitos
Funcionais
Requisitos Não
Funcionais
Diagrama de
Caso de Uso
Diagrama de
Classes
Testes
Plano de Testes
Script de
Testes
Evidências de
Testes
Levantamento
de Dados
Entrevistas com
os Clientes
Relatórios de
Pesquisas
Sistema NENP
Cadastros
Usuário
Cliente
Funcionários
Relatórios
Controle de
Acesso
117. PAPEL RESPONSABILIDADES
Gerente de Projeto Realizar acompanhamento do cronograma,
Validação da documentação,Gerenciamento
de escopo,Gerenciamento de riscos;
Documentador Desenvolvimento das documentações,
Validações de diagramas, Auxílio no
levantamento das regras de negócio;
Programador(a) Codificação do sistema,Validar script de
testes unitários a serem realizados
DBA
Desenvolver a arquitetura do banco de
dados, Suporte técnico para a equipe de
desenvolvimento, Desenvolvimento de
documentação técnicas
Testador
Realizar plano de testes unitários na
ferramenta, Registrar resultado dos testes
119. Maio Junho Julho Agosto
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
DOCUMENTAÇÃO RESPONSÁVEL
LEVANTAMENTO DE REQUISITOS
Mapear requisitos funcionais Alessandro
Mapear requisitos não funcionais Tiago
Mapear regras de negócio Alessandro
Inserir diagramas Bruno
Validar com stakeholder Alessandro
CRIAÇÃO DE DOCUMENTAÇÃO
Identificar atores Alessandro
Definir casos de uso Bruno
Criação da descrição de caso de uso Tiago
Documentação de banco de dados Bruno
Criação do diagrama de classe Tiago
Criação de diagrama de sequência Tiago
Criação de script de testes Tiago
SISTEMA
CADASTROS
Usuário
Arquitetura e desenv. do banco de
dados
Karoline
Codificação Módulos Karoline
Realizar testes unitários Vinicius
Encaminhar módulo para o testador Karoline
120. DocuDATA DESCRIÇÃO DA ENTREGA
09-Maio Entrega da apresenteção de pré-banca para Waldomiro
30-Mai Entrega documentação final para pré-banca
121. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1
Saída do membro
da equipe
Negati
vo
5 Explorar
alocar outro recurso
interno para realizar
tarefas do membro
desligado
2 Falta de validação
por parte do
stakeholder
Negati
vo
8 Explorar
agendar follow up
semanalmente para
cobrir os itens a serem
validados
3 Indisponibilidade
do cliente durante
validação
Negati
vo
6 Mitigar
agendar follow up
semanalmente para
cobrir os itens a serem
validados
4 Falta de recursos
financeiros para
dar andamento ao
projeto (budget
excedido)
Negati
vo
5 Mitigar
estudar com o cliente
a possibilidade de
acordar um novo plano
de custos
123. # DESCRIÇÃO
1 Necessidade de reaunião semanal
2 Fazer uso do status report com os atuais stakeholders do projeto
3 Documentar toda e qualquer possível idéia/mudança no projeto
4
Realizar o estudo de caso de risco com criticidade com o objetivo
de evitar com que o prazo seja afetado
5
Validar constantemente documentação com os professores
responsáveis.
129. Facilitar a compra de produtos com o melhor
custo.
Oferecendo uma alternativa viável e de fácil
acesso.
130. Desenvolver um sistema de pregão online
para proporcionar às empresas a compra de
produtos(através de uma lance) obtendo o
menor custo.
131. Reduzir tempo de procura.
Reduzir o custo.
Atender a demanda.
132. O sistema será desenvolvido em PHP.
Utilizando MySQL, Jquery, Ajax.
133. Diagrama de Caso de Uso.
Diagrama de Fluxo de Dados.
Descrição de Caso de Uso.
Plano de Testes.
Modelo Entidade Relacionamento.
Apresentação do Sistema.
Treinamento para os usuários.
Requisitos Funcionais.
134. Sistema de
Pregão Online
Documentação
Descrição de
Caso de Uso
Regras de
Negócio
Requisitos
Funcionais
Requisitos Não
Funcionais
Diagrama de
Caso de Uso
Diagrama de
Fluxo de Dados
Testes
Plano de Testes
Script de Testes
Validação dos
Testes
Levantamento
de Dados
Entrevistas
com
Fornecedores
Relatórios de
Pesquisas
Sistema
Cadastros
Produto
Pregoeiro
Fornecedores
Compra
Relatórios
Segurança e
Controle de
Acesso
135. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O TCC será finalizado sem mudanças de membros do
grupo.
P
O sistema precisa permitir vários acessos simultâneos. P
O projeto precisar ser viável e gerar retorno. P
O projeto precisa ser concluído antes de Junho/2014 R
Atender todas as regras e documentações R
137. PAPEL RESPONSABILIDADES
Analista de Negócios Validar documentação e analisar as regras
de negócio e requisitos.
Desenvolvedor Desenvolver o sistema e principais
recursos.
Gerente de Projeto Planejar o projeto para obter o resultado
esperado.
139. Maio/2014: Validar o Modelo Entidade
Relacionamento e finalizar o banco de dados
com as principais consultas. Concluir o
desenvolvimento dos principais cadastros e
consultas e também a documentação do
software.
Junho/2014: Validação do conteúdo do
projeto.
140. Modelo Entidade Relacionamento.
Banco de Dados completo incluindo as
principais consultas.
Diagramas de Fluxo de Dados e Caso de Uso.
Requisitos Funcionais.
Apresentação finalizada para validação.
141. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não atendimento
ao prazo.
N 5 Eliminado Conforme planejado
com a equipe, os
prazos serão
atendidos.
2 Saída de
membros da
equipe
N 5 Eliminado Todos os integrantes
já concordaram em
continuar na equipe.
142. DATA DESCRIÇÃO DA MUDANÇA
05/05/2014 Alteração no organograma da equipe.
143. # DESCRIÇÃO
1
Realizar reuniões semanais com a equipe do projeto, para não
impactar no prazo de entrega das atividades.
2 Validar com os “stakeholders” as principais rotinas.
149. A principal justificativa do desenvolvimento
deste projeto é a automatização, controle e
agilidade na organização de formaturas. O
aplicativo será voltado para empresas que
atuam neste ramo.
150. Facilitar a organização e o agendamento de
formaturas. O sistema possibilita ter um
maior controle principalmente sob as
formaturas, convites e convidados
151. Facilitar a análise dos dados da formatura,
fazendo com que a empresa consiga
determinar a quantidade ideal de recursos a
serem utilizados no evento. Além disso, a
possibilidade de acesso do próprio aluno a
dados pessoais e agenda da formatura
flexibiliza o cadastro destes, diminuindo
erros e melhorando o relacionamento com os
clientes.
152. Sistema Web
Desenvolvido em linguagem PHP
Banco de Dados MySQL
153. Requisitos Funcionais
DFD
Diagrama de Sequência
Diagrama de Caso de Uso
Diagrama de Classe
Diagrama de Colaboração
Descrição de Caso de Uso
Modelo Descrito
MER
Modelo Lógico
Dicionário de Dados
Script
Manual do Sistema
Testes
Apresentação
154. SAF
Sistema
Cadastros
Relatórios
Controles
Documentação
Banco de Dados
Modelo Descritivo
Modelo
Conceitual -MER
Modelo Relacional
Mapeado
Modelo Lógico
Normalização
Dicionário de
Dados
Modelo Físico –
Scripts
Engenharia de
Software
Requisitos
Funcionais
Diagrama de
Classe
Descrição de
Caso de Uso
Diagrama de
Sequência
Diagrama de
Colaboração
155. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O projeto será desenvolvido por três pessoas PREMISSA
Aprender mais sobre a linguagem (PHP) que estamos
desenvolvendo o projeto.
PREMISSA
O projeto precisa ser concluído até Novembro de 2014. RESTRIÇÃO
O tempo estimado da apresentação é de 15 minutos. RESTRIÇÃO
156. Thaís e Rosimere
Gerente do Projeto
Thaís
Documentadora
Testadora
Banco de Dados
Rosimere
Programadora
Documentadora
157. PAPEL RESPONSABILIDADES
Gerente de Projeto
Responsável por supervisionar as atividades,afim
de garantir o cumprimento das entregas.
Testadora Testar todos os módulos do sistema.
Banco de Dados
Responsável por toda a parte do Banco de Dados.
Criação do MER, Mapeamento e Normalização.
Documentadora
Criar a documentação do projeto. E validar
informações com professores
Testadora Testar todos os módulos do sistema.
160. Modelo Físico – Scripts
Apresentação
Artigo Sistema
Testes
Manual do Sistema
161. DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Entregas fora do
prazo Negativo Alta
Estimar o tempo maior ao
habitual
2 Não validação de
algum
documento
Negativo Alta Não validação de algum
documento
3 Inserir app
mobile no
sistema
Positivo Alta Sendo avaliado Implementar no sistema
162. DATA DESCRIÇÃO DA MUDANÇA
04/2014 Adoção de novos perfis no sistemas
04/2014 Novas regras de negócios inseridas
163. DESCRIÇÃO
1
Se antecipar na preparação das atividades, para não ficar fora do
prazo de entrega.
2 Sempre reunir o grupo pra realizar as atividades.
3 Procurar sempre validar a documentação antes da entrega final.
169. Com a concorrência e alta demanda no
mercado de advocacia, percebemos a
necessidade de desenvolver um sistema para
gerenciar e informatizar toda ação num
escritório de advocacia, administrando
informações conforme preferencia do
cliente.
170. O projeto tem como proposta informatizar e
viabilizar o controle de prazos processuais,
por meio de alertas; obter o cadastro de
clientes e contratos; acompanhar processos
jurídicos; possibilidade de gerar relatórios.
171. Funcionamento do Escritório Nieves & Quattrone
sem a implantação do Sistema.
172. Alertas de compromissos (reunião,
audiência, aniversariante, visita e etc)
do dia, mês e ano.
Gerenciar os documentos gerados ou
trazidos, para facilitar e organizar o
arquivamento e busca.
Cadastrar cliente no sistema.
Gerar contratos via sistema.
Acompanhar processos judiciais.
Gerar relatórios (cliente, contrato,
processos).
173. Sistema será web (instalado no servidor
empresa ou num datacenter), desenvolvido em
.NET Framework 4.5, linguagem C# e banco de
dados SQL Server 2008;
174. Regra de Negócio
Diagrama E-R
Descrição de Caso de Uso
Diagrama de Caso de Uso
Diagrama de Classe
Diagrama de Sequência
Modelo R-E
Mapeamento do MER
Dicionário de Dados
Apresentação do Projeto
Plano de Testes
Treinamento aos usuários
175. Projeto SGPJ
Documentação
Engenharia de
Software
Regras de
Negócio
Descrição de
Casos de Uso
Requisitos
Funcionais
Requisitos
Não
Funcionais
Engenharia de
Software
Diagrama de
Caso de Uso
Diagrama de
Classes
Diagrama de
Sequencia
Testes
Plano de
Testes
Levantamento
de Dados
Encontros
com
empresa
Banco de
Dados
MER
Mapeamento
Normalização
Modelo
Relacional
Modelo
Relacional
Sistema
Cadastros
Usuário
Cliente
Advogado
Relatórios
Prazos
Contratos
Processos
Controle de
Acesso
176. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
A empresa irá disponibilizar informações para o
levantamento de requisitos
P
A Bruna, advogada, irá acompanhar etapas do projeto P
O TCC será finalizado sem mudanças de membros P
O projeto precisa ser concluído antes de 14/11/14 R
177. Juan Garcia
Gerente de Projeto
Sérgio França
Analista de Requisitos
Rogério
Oliveira
Desenvolvedor
Juan e Sérgio
Analista de Testes
Rogério e Juan
DBA
178. PAPEL RESPONSABILIDADES
Gerente de Projeto Realizar o acompanhamento e organizar o
cronograma.
Documentador Conhecer profundamente o projeto.
Testadora Realizar testes juntamente com o cliente.
Programador
Implementar projeto, conforme regra de
negócios e requisitos.
182. Banco de Dados: Scripts SQL (Consulta);
Entrega atualizada do MER, Normalização,
Dicionário de Dados.
Engenharia de Software: Validação da nova
Regra de Negócio(atualizada).
183. # DESCRIÇÃO TP CRIT. SITUAÇÃO AÇÕES
1 Surpreender o cliente
com funcionalidades
adicionais
(P) 12 Melhorar Implementação nova
2 Indefinições no Escopo (N) 20 Mitigar Atualizando escopo
3 Não entregar sistema
dentro do tempo
proposto
(N) 12 Mitigar
Encontros na semana
com a equipe
4 Não aceitação de
alguma funcionalidade
do sistema
(N) 6 Eliminar
Apresentar protótipo
para empresa
184. DATA DESCRIÇÃO DA MUDANÇA
12/05/14 Iremos validar novamente a Regra de Negócio, para
assim implementar em todo escopo do projeto.
12/05/14 Agendaremos uma reunião com a empresa para
identificar um diferencial, para implementar no
projeto.
185. # DESCRIÇÃO
1
Com alguns atrasos no Projeto, percebemos a necessidade de
priorizar o desenvolvimento do Projeto de TCC.
2 Marcamos encontros da equipe durante a semana.
3 Não deixe para amanhã o que pode-se fazer hoje.
4
5
191. Por lei, as empresas precisam que seus funcionários
passem por uma avaliação médica que ateste se estão
aptos ou não para o cargo que irão exercer, ou em caso de
desligamento, é necessário atestar se a saúde do
funcionário não foi comprometida de alguma maneira
após atuar no cargo contratado. O nosso cliente é uma
clínica médica com foco na realização de exames
ocupacionais para os funcionários das empresas
conveniadas.
Atualmente, existem poucos sistemas voltados para a área
da saúde ocupacional. A maioria são antigos, limitados,
com manutenção constante e de Alto Custo. O S.I.A foi
construído visando eliminar estes problemas e para
melhorar o desempenho das clínicas médicas no
atendimento aos seus clientes.
192. Desenvolver uma aplicação que possibilite
controlar e facilitar todos os processos que
envolvem os exames ocupacionais dentro de
uma clínica médica, desde os Agendamentos
até Emissão do Atestado de Saúde
Ocupacional (A.S.O).
193. Otimizar o tempo para agendamento de
exames, permitindo que as próprias
empresas agendem os exames para seus
funcionários.
Permitir consultas rápidas aos resultados dos
exames e prontuários médicos.
Unificar todos os controles que envolvem o
processo de Exames Ocupacionais em uma
única ferramenta.
194. As empresas conveniadas terão a opção de agendar os exames
diretamente pelo sistema, mas se preferirem também poderão solicitar
para a clínica, como é feito hoje. Isso será possível através do controle
de acessos por Grupos.
As funcionalidades do sistema estarão distribuídas nos seguintes
módulos a saber, cada módulo pertence a um Grupo:
• Módulo Administrativo:
o Grupo: Admin
o Para Gerenciamento dos Grupos de acessos e usuários.
• Módulo Módulo Cadastros
o Grupos: Clínica e Admin
o Para cadastros auxiliares que servem de apoio ao sistema (Cargos, Departamentos,
Equipe Médica, Exames, Calendário e empresas). Além da Funcionalidade Realizar
Exames.
• Módulo Empresas
o Grupos: Clínica, Admin e Empresas
o Para Cadastro de Funcionários.
• Módulo Agendamento:
o Grupos: Clínica, Admin e Empresas
o Para Agendamento dos exames;
195. O S.I.A é um sistema que será desenvolvido
para facilitar o agendamento e realização dos
exames ocupacionais, visando também
otimizar o controle de todo processo e
consulta dos resultados.
196. S.I.A
Documentação
Descrição de
Caso de Uso
Regras de
Negócio
Requisitos
Funcionais
Banco de Dados
MER
Diagrama de
Caso de Uso
Diagrama
de Classes
Testes
Plano de
Testes
Execução de
Testes
Evidências
de Testes
Levantamento
de Requisitos
Entrevistas com
os Clientes
Sistema
Cadastros
Departamentos
Cargos
Funcionários
Equipe
Médica
Exames
Calendário
Cadastro de
Empresas
Cadastro de
Funcionários
Agendamento
Agendar
Exames
Controle de
Acesso
Cadastro de
Usuários
197. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O cliente disponibilizará um usuário do sistema em
meio período por uma semana para levantamento dos
requisitos.
P
Clínica e Empresas conveniadas precisaram de Acesso á
internet para utilizar o sistema
P
O Servidor será disponibilizado no cliente (Clínica) P
A entrega do projeto não deverá ultrapassar a data
limite (Nov/2014)
R
198. Juliana/Iris/
Wanderlei
Gerente de Projeto
Juliana Lima
Analista de Requisitos
Iris de Melo
Analista de Requisitos
Wanderlei
Dias
Desenvolvedor
Juliana Lima
Desenvolvedora
Iris de Melo
Analista de Testes
Wanderlei
Dias
DBA
199. PAPEL RESPONSABILIDADES
Gerente de Projetos Elaboração e acompanhamento do
Cronograma. Validar Documentações e as
funcionalidades disponibilizadas no
sistema.
Analista de Requisitos Levantamento de Requisitos e Elaboração
das documentações.
Desenvolvedor Construção da arquitetura do sistema e
desenvolvimento.
DBA Modelagem de Dados e Administração do
Banco de Dados.
Analista de Testes Elaboração de Plano, Execução e Evidência
de Testes.
201. Nome da tarefa Duração Início Término Predecessoras Nomes dos recursos
S.I.A 29 dias Qui 01/05/14 Ter 10/06/14
Alteração de Documentação 9 dias Qui 01/05/14 Ter 13/05/14
Diagrama de Casos de Uso 2 dias Qui 01/05/14 Sex 02/05/14 Juliana Lima
Descrição de Casos de Uso 3 dias Seg 05/05/14 Qua 07/05/14 3Juliana Lima
Diagrama de Classes 4 dias Qui 08/05/14 Ter 13/05/14 4Juliana Lima
MER 1 dia Qui 01/05/14 Qui 01/05/14 Iris de Melo
Levantamento de Requisitos 21 dias Sex 02/05/14 Sex 30/05/14
Levantamento 14 dias Sex 02/05/14 Qua 21/05/14 6Iris de Melo
Documentação 7 dias Qui 22/05/14 Sex 30/05/14 8Iris de Melo
Correções Sistêmicas 6 dias Qua 14/05/14 Qua 21/05/14
Autenticação e Autorização 2 dias Qua 14/05/14 Qui 15/05/14 5Juliana Lima
Regras de Agendamento 2 dias Sex 16/05/14 Seg 19/05/14 11Juliana Lima
Regras Tela Realizar Exame 2 dias Ter 20/05/14 Qua 21/05/14 12Juliana Lima
Novas Demandas 18 dias Qui 01/05/14 Seg 26/05/14
ASO em PDF 2 dias Qui 01/05/14 Sex 02/05/14 Wanderlei Dias
Enviar ASO por Email 3 dias Seg 05/05/14 Qua 07/05/14 15Wanderlei Dias
Relatórios 2 dias Qui 08/05/14 Sex 09/05/14 16Wanderlei Dias
Integração 3 dias Seg 12/05/14 Qua 14/05/14 17Wanderlei Dias
Módulo Financeiro 5 dias Qui 15/05/14 Qua 21/05/14 18Wanderlei Dias
Correções 1 dia Qui 22/05/14 Qui 22/05/14 19Wanderlei Dias
Validação 2 dias Sex 23/05/14 Seg 26/05/14 20Juliana Lima
Testes 7 dias Seg 02/06/14 Ter 10/06/14
Roteiros 3 dias Seg 02/06/14 Qua 04/06/14 9Iris de Melo
Excução 2 dias Qui 05/06/14 Sex 06/06/14 23Iris de Melo
Evidências 2 dias Seg 09/06/14 Ter 10/06/14 24Iris de Melo
202.
203. ASO em PDF
Enviar ASO por Email
Relatórios
Integração
Módulo Financeiro
204. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Alterações no
Escopo
N 3 Mitigar Mapear Alterações e
identificar o que
pode ser tratado em
próxima versão.
2 Novo Membro P 3 Aceitar Apresentar Sistema e
Dividir Tarefas.
3 Atraso
Desenvolvimento
N 5 Mitigar Direcionar toda
equipe para o
Desenvolvimento.
206. # DESCRIÇÃO
1 Dividir as tarefas igualmente visando respeitar os prazos.
2
Organizar as atividades e indicar os responsáveis para evitar
atrasos.
3 Gerenciamento constante do trabalho.
212. O projeto tem por finalidade a disseminação
do conhecimento artístico e cultural.
A solução propõe uma aliança entre a arte e a
tecnologia para que os apreciadores possam
desfrutar de diversos recursos de mídia para
ampliar e consolidar a sua bagagem cultural,
além de absorver conhecimentos sobre os
diversos contextos em que aquela obra está
situada.
213. Desenvolvimento de um sistema que permita
mapear obras de um acervo no qual os
visitantes de uma determinada exposição
possam, através de um dispositivo móvel,
conhecer mais sobre qualquer obra exposta
ao realizar a leitura de um QR Code com o
dispositivo móvel.
214. Oferecer aos visitantes das exposições uma
forma ágil de obter o maior número de
informações possíveis sobre determinada
obra exposta, além de realizar o mapeamento
do acervo com o intuito de que os
Administradores saibam a localização exata
de cada obra.
215. Sistema Web desenvolvido em PHP e banco de
dados MySQL;
Criação de uma aplicação para dispositivos
móveis (Android) para a consulta de
informações;
Criação de um serviço centralizado onde a
aplicação WEB e o sistema de dispositivo
móvel possam buscar informações coerentes.
216. Diagramas de Casos de Uso;
Diagrama de Classes;
Diagramas de Sequência;
Modelo Entidade Relacionamento;
Modelo Lógico;
Plano de Testes;
Plano de Treinamento para o Usuário.
217. SMART
Documentação
Engenharia
Diagrama
de Caso de
Uso
Descrição de
Caso de Uso
Regras de Negócio
Requisitos Funcionais
Requisitos Não
Funcionais
Diagrama
de Classes
Diagrama de
Sequencia
Testes
Plano de
Testes
Script de Testes
Evidências de
Testes
Banco de
Dados
MER
Descritivos
Modelo
Logico
Modelo
Físico
Dicionário
de Dados
Mapeamen
to
Levantamento
de Dados
Pesquisas
Sistema
Cadastros
Funcionári
o
Obra
Artista
Fatos do
Artista
Local
Exposição
Exposições
Ambiente
Movimento
s Culturais
Fatos
Movimento
Relatórios
Obras
Artistas
Técnicas
Movimento
s Culturais
Funcionári
os
Tipo Obra
Controle
de Acesso
Android
QRCode
218. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
Eder, Vinícius e Joice participarão do projeto P
Os professores orientarão o projeto de acordo com o
que esperam como produto final
P
O projeto deve ser concluído antes do dia 31.10.2014
(sexta- feira)
R
A apresentação deve ser montada de acordo com
template disponibilizado pela coordenadora
R
220. PAPEL RESPONSABILIDADES
Gerente de Projetos Gerenciar a equipe e distribuir tarefas aos integrantes
conforme cronograma. Além disso, distribuir as prioridades das
entregas referentes a cada stakeholder.
Gerente de Projetos Documentar cada módulo do projeto sendo eles: Banco de
Dados, Engenharia de Software, além de fazer as devidas
análises de mercado.
Testadores Testar o software de acordo com a especificação da análise de
requisitos do sistema, verificando as consistências entre
módulos e campos e também, validando a regra de negócio.
Programador Desenvolver o software de acordo com a análise de requisitos.
DBA Desenvolver a estrutura do banco de dados de acordo com o
levantamento realizado, gerando o MER e o Modelo Lógico.
223. Geração e Impressão do QR Code
Finalização da aplicação Android
Elaboração do Manual do Usuário
Elaboração da Documentação Final
224. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Entrega
fora do
prazo
Negativo 15 Explorar Escalar coordenação
2 Entrega
antes do
prazo
Positivo 10 Transferir Trabalhar para
chegar ao resultado
ok
3 Falhas no
levantamen
to de
requisitos
Negativo 15 Explorar Levantar os
requisitos
necessários para o
cumprimento do
projeto
225. DATA DESCRIÇÃO DA MUDANÇA
01/05/2014
Inclusão de uma nova tabela na base de dados, para
controlar todas as mudanças de local de uma
determinada obra
03/05/2014 Inclusão dos níveis de segurança das obras
226. # DESCRIÇÃO
1
É necessário utilizar alguma ferramenta para o gerenciamento do
projeto de modo que todos os integrantes possuam um controle
eficiente das entregas e suas respectivas datas
2
Validar os artefatos com todos os professores que possivelmente
estarão envolvidos na banca
3
Efetuar os testes em etapas de modo que não fique
sobrecarregado no final do cronograma
4 Realizar reuniões periódicas com a equipe do projeto
232. O Synergy irá solucionar o problema de
gerenciamento e catalogação de projetos
SCRUM, além de causar maior cooperação
entre os membros e times de uma instituição.
233. Desenvolver um sistema para controle de
projetos SCRUM, que seja flexível a
mudanças. E desenvolver satélites que
possam facilitar o andamento do projeto e a
instituição como um todo.
234. Controle de capacity
Controle de andamento do projeto
Geração de um portfólio organizado
235. Sistema web ASP.NET com banco de dados
SQL Server. E um WCF com comunicação XML
para integração com sistemas antigos.
236. Diagrama de Caso de Uso
Diagrama de Classe
Descrição de Caso de Uso
Apresentação do sistema
Protótipo
237.
238. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O Synergy é desenvolvido seguindo os conceitos de Scrum. P
O projeto precisa ser concluído antes do fim do
segundo semestre de 2014.
R
O sistema rodará em redes internas, mas o cliente
poderá acompanhar o progresso de criação do produto
via internet.
P
O cliente somente terá acesso ao Product Owner para
iniciação do projeto e para qualquer alteração eventual
durante o percurso das operações.
R
240. PAPEL RESPONSABILIDADES
Product Owner Verificar as necessidades iniciais do projeto
e repassar ao SM e Team.
Scrum Master Gerenciar a equipe de maneira a firmar a
conexão entre os membros.
Programador Desenvolve o banco e o core do projeto.
Gerente do Projeto Trabalha com a documentação do software
e as validações com o professor.
Design Desenvolve o design da Aplicação e
aumenta a experiência com o usuário.
Documentador Enriquecimento de experiência com o
usuário e documentação.
244. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não atendimento
do prazo
N 20 Eliminar Atualizar o
cronograma sempre
que possível
2 Mudança nos
padrões de
documentação
N 8 Aceitar Redigir os
documentos
3 Adição de escopo N 6 Mitigar Iniciar com o escopo
mais completo se
possível
4 Mudança da data
de entrega
N 6 Aceitar Realinhar o
cronograma
245. DATA DESCRIÇÃO DA MUDANÇA
22/03/2014 Inserção de novos sistemas ao SCRUM.
07/04/2014 Mudanças no modelo descritivo e casos de uso.
18/04/2014 Criação da interfaces do sistema e integração do core.
03/05/2014 Alterações em algumas interfaces para obedecer aos
requisitos.
246. # DESCRIÇÃO
1 Se orientar ao máximo pelos stakeholders na avaliação antecipada
do projeto.
2 Realizar reuniões semanais com a equipe do projeto para
verificação do andamento.
3 Dar prioridade aos prazos estabelecidos pela equipe.
4 Enriquecer o sistema através da avaliação com o usuário final.
1 Se orientar ao máximo pelos stakeholders na avaliação antecipada
do projeto.
252. Nosso sistema possui o diferencial da rapidez,
prática e simplicidade no preenchimento do
conteúdo WEB, para que todos que contratem o
mesmo, possam utilizar a ferramenta sem
problemas, e complexidade.
253. Desenvolver um sistema, que torne prático e
eficaz o preenchimento de Páginas WEB, com
diversos conteúdos implantados.
254. Esperamos que o sistema, apresente da
melhor forma, o seu desempenho e que todo
seu conteúdo, seja satisfatório para o cliente.
Todo o planejamento do cliente, relacionado
ao software, tenha sucesso nas suas tarefas
adquiridas atreladas ao sistema.
255. Sistema para gerenciamento de conteúdo
Web, interface gráfica, de fácil manuseio e
acessibilidade a todos os tipos de clientes.
256. .1. Itens que compõem o escopo do projeto
O projeto é identificado através das documentações
abaixo, fornecidas:
- Regra de Negócios
- Casos de Uso
- Diagrama de Classes
- Diagrama de Sequencia
- Diagrama de Colaboração
- Diagrama do Fluxo de Dados
- Necessidades e Características do Mercado
- Plano de Negócios
- Modelo de Dados
- Requisitos Funcionais
257. APPOLO
Documentaçã
o
Descrição de
Caso de Uso
Regras de
Negócio
Requisitos
Funcionais
Diagrama
de Caso de
Uso
Modelo
de Dados
Diagram
a de
Classes
Diagrama
de
Sequencia
Diagrama
de Caso de
uso
Diagrama de
Colaboração
Diagrama de
Caso de Uso
Diagrama de
Sequencia
Diagrama
de Fluxo
de Dados
Testes
Documentaç
ão de Testes
Unitários
Evidencias
de Testes
Planos de
Testes
Levantamen
to de Dados
Necessidade
s e
Característic
as do
mercado
Planos de
Negócios
Sistema
Cadastros
Usuário
Páginas
Conteúd
o Web
Visualização
de Conteúdo
Páginas
Conteúd
o Web
Controle
de
Acesso
Usuário
258. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
Para que o projeto tenha uma execução com sucesso, deve ser
estabelecido ao cliente que o mesmo possua colaboradores ou até
mesmo uma pequena noção, relacionado a parte técnica do sistema.
Pois cabe ao cliente, que manipule e altere todas as
informaçõescaracterísticas do mesmo, desta forma se adequando o
sistema para sua funcionalidade específica.
P
Fica determinado características físicas e técnicas para que o Sistema
execute seu fluxo normalmente.
P
Projeto entregue dentro do prazo definido pelo cliente. R
O custo de instalação e configuração do sistema não deve ultrapassar o
valor estabelecido pelo cliente.
R
259. João Guilherme
CEO
Daiane Sena
Analista de Sistemas
Leônidas do
Nascimento
Analista de Sistemas
Rodolpho Vinicius
Desenvolvedor
João Guilherme
Desenvolvedor
Leônidas do
Nascimento
Gerente de projeto
260. PAPEL RESPONSABILIDADES
CEO
Fornecer ideias de desenvolvimento e visões sobre o mercado relacionado
ao projeto em um contexto macro; ponto inicial de contato do projeto com
os stakeholders;
Gerente de projeto (Nível
Auxiliar)
Auxiliar na especificação e detalhamento das ideias e visões sugeridas
pelo CEO; elaborar cronograma, distribuição de atividades e planos
estratégicos do projeto; elaborar apresentações para os stakeholders.
Analista de sistemas
Elaborar documentos técnicos com base nas especificações detalhadas (e
filtradas) passadas pelo gerente de projeto; elaborar soluções para
problemas no software; atualizar documentações; manter a base de
dados;
Desenvolvedor
Entender a documentação técnica, planejar e desenvolver as soluções
elaboradas pelos analistas de sistemas; entender e elaborar frameworks
de desenvolvimento.
264. # DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não Cumprir os
prazos (atraso nas
entregas)
N 12 Mitigação Motivar a equipe a "entrar" no
projeto, fazendo-os entender a
sua importância. Solicitar que
cada um dos membros da
equipe deem seus próprios
prazos de entrega e discutir
cada um deles visando ajusta-
los com o prazo final.
2 Não atente as
especificações
N 20 Eliminação Fazer com que os membros da
equipe entendam a proposta e
visão do projeto de software
através de reuniões; envolve-los
nas etapas de analise e
documentação; reforçar a
necessidade de cumprimento do
cronograma.
3 Expansão do projeto P 25 Explorar Atentar-se ao mercado e suas
possibilidades. Caso uma
proposta de expansão dos
serviços propostos seja feita,
fazer uma boa analise de
impacto e procurar a melhor
maneira de implementação
adequando-se ao cronograma.
265. DATA DESCRIÇÃO DA MUDANÇA
09/05/14 Alterações na Documentação, relacionado a matéria de Desenvolvimento
do sistema, alterar nomenclaturas, conforme o sistema está, de forma
atualizada, manter a documentação no estágio do Projeto.
07/05/14 Alterações, realizadas fisicamente no Banco de Dados do sistema, criação e
alteração de tabelas e procedures.
07/05/14 Alteração e inclusão de documentos novos, relacionados ao Banco de
Dados do sistema
05/05/14 Tela inicial de Login, do sistema finalizada, com sua programação
concluída.
266. # DESCRIÇÃO
1
Realizar Reuniões se possível mensais para alinhar todos os
detalhes.
2
Validar documentações, com os responsáveis por cada área de
projeto.
3 Alinhas as informações dentre os componentes do grupo.
4
Aproveitar todo o tempo disponível para, focar no projeto e
objetivo final.
5
Avaliar cada, parte do projeto individualmente para assim, pode
explorar como um todo, cada requisito dentro o grupo