plano de projeto de software para produtos da lacertae sw

UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO

SISTEMAS DE INFORMAÇÃO*

PLANO DE PROJETO DE SOFTWARE

para produtos da Lacertae SW

Fernando Lucas de Oliveira Farias – 200920001082

Jairo Charnosky do Nascimento - 200820005298

São Cristóvão

2016

UNIVERSIDADE FEDERAL DE SERGIPE

CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO

SISTEMAS DE INFORMAÇÃO*

PLANO DE PROJETO DE SOFTWARE

para produtos da Lacertae SW

Projeto apresentado ao Prof. Dr. Rogério Patrício Chagas

do Nascimento como parte do processo de avaliação da

disciplina Gerência de Projetos no curso de graduação em

Sistemas de Informação – Bacharelado da Universidade

Federal de Sergipe

São Cristóvão

2016

SUMÁRIO

1. INTRODUÇÃO ...................................................................................................................... 4

1.1 Âmbito do Projeto ..................................................................................................................... 4

1.2 Funções principais do produto de software .............................................................................. 4

1.3 Requisitos comportamentais ou de performance ...................................................................... 8

1.4 Gestão e Restrições Técnicas .................................................................................................... 8

2. ESTIMAÇÕES DO PROJETO................................................................................................... 8

2.1 Técnicas de estimação e resultados....................................................................................... 9

2.1.1 Técnica de estimação ..................................................................................................... 9

2.2 Resultados ........................................................................................................................... 10

2.3 Recursos do projeto............................................................................................................. 11

3. ANÁLISE E GESTÃO DE RISCOS ........................................................................................ 12

3.1 Riscos do projeto..................................................................................................................... 12

3.2 Tabela de riscos................................................................................................................... 13

3.3 Redução e Gestão do Risco................................................................................................. 13

4. PLANEAMENTO TEMPORAL .............................................................................................. 15

4.1 Conjunto de Tarefas do Projeto .......................................................................................... 15

4.2 Diagrama de Gantt .............................................................................................................. 15

5. ORGANIZAÇÃO DO PESSOAL ............................................................................................ 18

5.1 Estrutura da equipe ............................................................................................................. 18

5.2 Mecanismos de comunicação ............................................................................................. 19

5.3 Uso do Edu-blog como ferramenta de apoio ...................................................................... 19

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO

PRODUTO DE SW ...................................................................................................................... 19

7. REFERÊNCIAS ........................................................................................................................ 19

1. INTRODUÇÃO

1.1 Âmbito do Projeto

Criar um sistema integrado para gerenciamento das atividades administrativas de um

Centro de Formação de Condutores. Proporcionando melhorias no cotidiano dos gestores e

colaboradores destes estabelecimentos através do fornecimento de ferramentas e indicadores

KPI que auxiliem na gestão e apoio a decisões de cunho tático e/ou estratégico.

1.2 Funções principais do produto de software

As funcionalidades e seus respectivos usuários constam na tabela abaixo:

Funcionalidade Usuário

GerenciarAgendamentodeAulas Aluno

GerenciarAlunos Atendente

GerenciarTurmas Atendente

GerenciarVeiculos Administrador

GerenciarUsuarios Administrador

GerenciarPlanodeContas Administrador

Tabela 01 - Principais funcionalidades e usuários

Figura 1 – Diagrama de Casos de Uso

Figura 2 – Diagrama de Classes “Agendamento de Aulas”

Figura 3 – Diagrama de Classes “GerenciarAluno”

Figura 3 – Diagrama de Classes “GerenciarFuncionario”

Figura 4 – Diagrama de Classes “GerenciaTurmas”

Figura 5 – Diagrama de Classes “GerenciaUsuario”

Figura 6 – Diagrama de Classes “GerenciaVeiculo”

1.3 Requisitos comportamentais ou de performance

Os clientes necessitam que o sistema disponha dos seguintes requisitos:

Interfaces deverão proporcionam uma experiência rica para usuário em termos de

ergonomia e usabilidade, ao tempo em que deverão considerar as heurísticas de nielsen;

Usuários poderão operar o sistema e conseguir atingir seus objetivos sem dificuldade.

O sistema deverá ter o menor número de falhas possível, e quando falhar ter formas de

auxiliar na solução do mesmo;

Segurança Criptografada com conexão TLS/SSL 3.0;

Permitir apenas o acesso as pessoas autorizadas;

Implementar os princípios da segurança da informação (Confiabilidade, integridade e

disponibilidade);

O sistema deverá operar 24h por dia todos os dias.

1.4 Gestão e Restrições Técnicas

Teremos as seguintes restrições técnicas:

● A linguagem de desenvolvimento será C#;

● Sistema de Gerenciamento do Banco de Dados será SQLServer 2012 ou superior.

● Cliente deverá ter acesso a internet para acessar o sistema.

● Arquitetura escalável de baixo acoplamento que permita customizar o produto, conforme

especificações do cliente.

2. ESTIMAÇÕES DO PROJETO

Para o desenvolvimento do sistema foi feita uma estimativa com base na métrica de

Lorenz & Kidd o qual se ajusta factivelmente ao projeto.

2.1 Técnicas de estimação e resultados

A técnica de estimação utilizada foi o Lorenz & Kidd que têm como base o cálculo

quantitativo de alguns aspectos fundamentais da Orientação a Objetos, como os atributos e

serviços, herança, coesão e acoplamento.

2.1.1 Técnica de estimação

Para usar esta métrica devemos seguir alguns passos:

1. Definir o número de classes chave;

2. Encontrar o número de classes de suporte, que para isso temos que classificar o tipo de

Interface do Produto e desenvolver um Multiplicador para as Classes de Suporte;

3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimativa

do número de classes de suporte;

4. Logo após, calcula-se a quantidade total de Classes, somando o nº de Classes-Chave com

o nº de Classes de Suporte;

5. Multiplicar a quantidade total de Classes (classes-chave + classes de suporte) pelo

“número médio de unidades de trabalho (dias-pessoa) por classe”. Lorenz & Kidd sugere entre

15 e 20 dias-pessoa por classe. Escolher um número entre 15-20 dias-pessoa e justificar a

escolha.

6. Determinar a quantidade de esforço estimada;

7. Cálculo do tempo previsto para a elaboração do projeto.

A tabela abaixo mostra os fatores de multiplicação para encontrar a quantidade de classes

de suporte:

Interface Multiplicador

Não gráfica 2

Baseada em texto 2,25

GUI 2,5

GUI complexa 3

Tabela 02 - Fator de multiplicação

2.2 Resultados

De acordo com a métrica descrita acima obtivemos os seguintes resultados:

1. Quantidade de classes chaves = 8;

a. GerenciarAluno;

b. GerenciarFuncionario;

c. GerenciarAgendamentodeAlulas;

d. GerenciarVeiculo;

e. GerenciarUsuario;

f. GerenciarTurmas;

g. GerenciarPagamentos;

h. Autenticacao;

2. Sistema WEB, então utilizaremos a interface gráfica GUI = 2,5;

3. Classes chaves x multiplicador (8 x 2,5) = 20 classes de suporte;

4. Classes chaves + classes de suporte (8 + 20) = 28 classes projetada para o sistema;

5. A nossa empresa possui os profissionais mais bem remunerados e capacitados do

mercado, logo será aplicado o melhor tempo possível de acordo com Lorenz & Kidd.

Neste caso 15 dias/pessoa;

6. Podemos agora calcular a quantidade de esforço estimada: (28 x 15) = 420 dias de

trabalho;

A equipe para desenvolvimento deste projeto contem 2 membros, podemos então calcular a

distribuição dos dias de trabalho por pessoa. Com isso tenho 420 ÷ 2 = 110 dias por pessoa.

Aplicando a distribuição dos dias de trabalho aos percentuais de cada fase tenho a seguinte

situação:

Modelo % modelo % projeto Cálculo Dias

trabalho Planejamento 2 – 3% 3% 110 x 3% 4

Requisito-Analise-Desenho 40% 40% 110 x 40% 44 Geração de código 20% 20% 110 x 20% 22

Testes 37-38% 37% 110 x 37% 40 Resultado 110

Tabela 03 - Estimativa de cada etapa do projeto

2.3 Recursos do projeto

Os recursos usados para elaboração deste projeto serão: humanos, de software, hardware e

bibliográficos. Recursos humanos: A equipe de desenvolvimento do projeto é formada por dois membros, Fernando Lucas de

Oliveira Farias (Bacharelando do Curso de Ciência da Computação) e Jairo Charnosky do

Nascimento (Bacharelando do Curso de Sistemas de Informação). Recursos de Software: Para o desenvolvimento deste projeto serão utilizadas as seguintes ferramentas de software: Visual Studio 2010: Software que fornece suporte ao desenvolvimento na Linguagem de

programação C# e que utiliza o framework .NET e ASP.NET MVC.

C#: Linguagem de programação orientada a objetos utilizada na construção e manutenção dos

softwares com recursos para WEB.

SQLServer: Sistema para gerência de banco de dados relacional muito usado em empresas e por

grandes sistemas corporativos.

GanttProject: Utilizado para gerenciamento da estrutura analítica do projeto (EAP).

GoogleDocs: Utilizada para elaboração da documentação técnica e colaboração entre os

membros do projeto.

Internet Explorer: Browser para homologação de funcionalidades do produto.

Mozila Firefox: Browser para homologação de funcionalidades do produto.

Google Chrome: Browser para homologação de funcionalidades do produto.

Linux Ubuntu ou Debian: Sistemas operacionais open source utilizado para homologação de

funcionalidades do produto.

Windows 7 ou 10: Sistemas operacionais proprietários utilizado para homologação de

funcionalidades do produto. Recursos Hardware: Os hardwares utilizados para elaboração do projeto são: · Computadores Pessoais PC da Sony e Samsumg · Impressora para testes de impressão Recursos Bibliográficos: O recurso bibliográfico utilizado foi o que segue: PRESSMAN, Roger S. Engenharia de Software, 6ª edição, São Paulo, McGraw-Hill, 2006

3. ANÁLISE E GESTÃO DE RISCOS

A análise de riscos é importante para um projeto, pois assim o gestor pode se prevenir para saber

administrá-los.

3.1 Riscos do projeto

RISCO PROJETO TÉCNICO NEGÓCIO COMUM ESPECIAL

Insuficiência de pessoas na

equipe X

Prazo para entrega curto X

Pouco tempo para

treinamento dos usuários X X

Mudança nos requisitos

Rotatividade de Pessoal X X

Tecnologia e Infraestrutura

(Danos) X

Quadro 1 – Riscos do Projeto

3.2 Tabela de riscos

RISCO CATEGORIA PROBABILIDADE IMPACTO

Insuficiência de pessoas na

equipe Pessoal 60% Crítico

Prazo para entrega curto Técnico 70% Crítico

Pouco tempo para

treinamento dos usuários Projeto 30% Marginal

Mudança nos requisitos Projeto 10% Crítico

Rotatividade de Pessoal Pessoal 20% Catastrófico

Tecnologia e Infraestrutura

(Danos) Técnico 10% Catastrófico

3.3 Redução e Gestão do Risco

Apresentamos aqui as ações a serem tomadas para, prever, reduzir ou gerir os riscos

identificados.

Insuficiência de pessoas na equipe

Risco:001 Probabilidade: 60% Impacto: Crítico

Descrição: O numero de profissionais efetivos na nossa equipe é reduzido.

Estratégia de redução: Contratação de estagiários e trainners para serem capacitados

pelos profissionais mais experientes do projeto.

Plano de contingência:

a. Criação de um banco de talentoso para simplificar a contratação de profissionais

com perfil desejado;

b. Terceirização de mão-de-obra com pagamento condicionado as entregas

efetivamente realizadas e após aprovação do cliente.

Pessoa responsável: Fernando Lucas de Oliveira Farias

Status: Simulação completada

Prazo para entrega curto


Descrição: O cliente exigiu cumprimento do prazo em 50% do prazo calculado

Estratégia de redução: Ampliação da equipe permanente e terceirização de parte das

entregas do projeto.

Plano de contingência:

a. Contratação de profissionais freelancers conforme etapa do projeto;

b. Contratação de fábrica de software;

c. Renegociar o prazo do projeto com cliente.


Status: Simulação Incompleta

Pouco Tempo para Treinamento dos Usuários

Risco:003 Probabilidade: 30% Impacto: Marginal

Descrição: Os treinamentos serão executados em turnos corridos de forma a reduzir

em 30% da carga horária originalmente definida

Estratégia de redução: Elaborar parte do conteúdo para ser disponibilizado

modalidade EAD para os participantes

Plano de contingência: a. Estruturação de um Ambiente Virtual de Aprendizagem para disponibilizar partes do

treinamento;

b. Execução de dinâmicas de grupo e estudos dirigidos para simplificar o aprendizado

determinados conteúdos;

c. Disponibilização de videoaulas para redução do tempo das exposições teóricas.



Mudanças nos requisitos


Descrição: A falta de conhecimento detalhado das regras de negócios por parte do

cliente pode resultado em mudanças nos requisitos do projeto

Estratégia de redução: Documentar a elicitação de requisitos com ateste por parte do

cliente

Plano de contingência: a. Estabelecer fator de correção para custo e cronograma do projeto por pontos de

função alterados;


Status: Simulação Completa

Rotatividade de Pessoal

Risco:005 Probabilidade: 20% Impacto: Catastrófico

Descrição: A perda de profissionais para o serviço público pode prejudicar a execução

do cronograma junto ao cliente

Estratégia de redução: Criação de plano de carreira com remuneração conforme

resultado e tempo na empresa

Plano de contingência: a. Criar plano de carreira com cargos e salários;

b. Política agressiva de valorização dos profissionais pelo tempo na empresa

c. Contrato de permanência mínima na empresa independente de projetos.



Tecnologia e Infraestrutura (Danos)

Risco:006 Probabilidade: 10% Impacto: Catastrófico

Descrição: Danos no hardware dos servidores de aplicação ou máquinas dos membros

da equipe podem comprometer os prazos e entregas planejadas

Estratégia de redução: Compra de máquinas e hardware sobressalentes e estrutura

redudante para servidores e serviços de missão crítica

Plano de contingência: a. Compra de computadores sobressalentes

b. Compra de servidores redundantes

c. Contratação de link dedicado redundante de internet



4. PLANEAMENTO TEMPORAL

4.1 Conjunto de Tarefas do Projeto

TAREFAS MACRO PORCENTAGEM TEMPO (DIAS DE TRABALHO)

Planejamento 3% 4

Análise de Requisitos e Modelagem 40 44

Codificação 20% 22

Testes 37% 40

4.2 Diagrama de Gantt

Na figura 1, são representadas todas as tarefas que serão realizadas durante o processo de

desenvolvimento do projeto e seu tempo de duração.

Figura 7 – Diagrama de Gantt - EAP do Projeto

A fase de planejamento foi dividida em:

● Levantamento de requisitos: Definindo e delimitando o problema.

○ Entrevista com os clientes: Forma inicial de obtenção de dados, onde utilizamos

de uma conversa direcionada ao problema através de “pergunta-resposta”.

○ Reunião com os administradores: Reunião com os administradores do negócio,

obtendo desta forma informações mais específicas do problema.

● Validação de requisitos: Sub fase onde validaremos o documento produzido com o

sistema que o cliente deseja.

A fase de análise e projeto foi dividida em:

● Criação de casos de uso: Cada caso de uso descreve a interação com o seu usuário, ou

outro sistema.

● Criação de diagramas de classe de domínio: As classes de domínio identificam os

conceitos relacionados a requisitos do sistema e analisa o problema sob a perspectiva

conceitual.

● Definição da arquitetura do projeto: A Arquitetura do Projeto é baseado no padrão MVC

pela predominância web da plataforma, permitindo abstrair as regras de negócios

(controller) da apresentação dos dados (Models e Views) simplicando customizações do

projeto.

● Criação do diagrama de classes de projeto: Representação dos objetos ou entidades do

projeto e seus relacionamentos a exemplo de funcionário, aluno, veículos, entre outros.

● Criação do diagrama de sequência: Utilizado para demonstrar a interação ou trocas de

mensagens entre vários objetos de um determinado contexto (Figura. 8).

Figura 8 – Diagrama de Sequência – Novo Agendamento

A fase de codificação foi dividida em:

● GerenciarAluno;

● GerenciarFuncionario;

● GerenciarAgendamentodeAlulas;

● GerenciarVeiculo;

● GerenciarUsuario;

● GerenciarTurmas;

● GerenciarPagamentos;

● Autenticacao;

A fase de testes foi dividida nos seguintes níveis:

● Teste de unidade: Tem por objetivo explorar a menor unidade do projeto, procurando

provocar falhas ocasionados por defeitos de lógica e de implementação de cada módulo,

separadamente.

● Teste de integração: Provocar falhas nas interfaces entre os módulos.

● Teste de sistema: Teste em busca de falhas como se fosse um usuário final.

● Teste de aceitação: Teste junto ao usuário final, validando a o comportamento do

software com o solicitado pelo cliente.

5. ORGANIZAÇÃO DO PESSOAL

5.1 Estrutura da equipe

A equipe é composta por: Fernando Lucas de Oliveira Farias e Jairo Charnosky do

Nascimento, a tabela abaixo destrincha as funções de cada um:

Integrante Função Sumário de atividades

Fernando Lucas

de Oliveira Farias

Gestor do projeto Tem a responsabilidade de coordenar todo

o desenvolvimento do projeto,

combinando reuniões, distribuindo tarefas,

resolver conflitos e manter a motivação e

bom ambiente no seio do grupo, alem de

ser responsável pelo planejamento

temporal do projeto compondo o diagrama

de Gantt.

Jairo Charnosky

do Nascimento e

Fernando Lucas

de Oliveira Farias

Analista de sistema tem a função de analisar o software e

desenhar os vários diagramas do sistema e

criar as classes e interfaces a implementar.

Fernando Lucas

de Oliveira Farias

Arquiteto do software Desenvolver a arquitetura do sistema,

inclusive os diagramas de projeto.

Jairo Charnosky

do Nascimento e

Fernando Lucas

de Oliveira Farias

Programadores Desenvolver o código do sistema.

Jairo Charnosky

do Nascimento e

Fernando Lucas

de Oliveira Farias

Testadores Testar os casos de uso do software.

Tabela 1 - Funções dos integrantes da equipe.

5.2 Mecanismos de comunicação

A comunicação entre todos os elementos da equipe é feita principalmente através de

reuniões periódicas, resolvem-se problemas em conjunto e distribuem-se tarefas. Além disso, são

também utilizados os meios de comunicação eletrônica, através de correio eletrônico,

mensageiros instantâneos e videoconferência.

5.3 Uso do Edu-blog como ferramenta de apoio

Edu-blog se mostrou uma excelente ferramenta de suporte à disciplina, pelo aspecto simplório,

interativo e agradável, permitindo ao docente disponibilizar o material de apoio a disciplina. Por

conseguinte, possibilitou a comunicação dinâmica entre o docente e todos os alunos, sendo muito

útil a cada discente na apresentação de suas dúvidas e/ou sugestões.

Em relação aos blogs de cada equipe, achamos que é também interessante na medida em que

permite a cada grupo partilhar com a comunidade o desenvolvimento do seu trabalho,

disponibilizando arquivos, bem como receber sugestões e criticas de qualquer pessoa.

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A

QUALIDADE DO PRODUTO DE SW

Implementar uma gerência de configuração sólida e bem difundida entre os membros do

projeto com procedimentos bem documentados para realização de commit, branches e tags no

repositório do projeto que utilizará a ferramenta SVN.

Contratar um consultor em gerência de qualidade para aferição dos artefatos

desenvolvidos e auxiliar na normatização dos procedimentos

Instituir as boas práticas do CMMI no desenvolvimento do produto, tendo como meta

manter-se entre os níveis 3 (Definido) e 4 (Gerenciado quantitativamente) de maturidade.

7. REFERÊNCIAS

SOMMERVILLE, Ian. Engenharia de Software. 9 ed. São Paulo. Pearson, 2011.

PRESSMAN, Roger. Engenharia de Software. 6 ed. Macgraw-Hill Interamericana, 2006.

plano de projeto de software para produtos da lacertae sw

Education