1

2

SUMÁRIO

1.0 INTRODUÇÃO.............................................................................................................. 3

1.1 DESCRIÇÃO DO PROJETO....................................................................................

3 1.2 PRINCIPAIS FUNÇÕES DO SISTEMA..................................................................... 3 1.3 RESTRIÇÕES....................................................................................................... 3 2.0 ESTIMATIVA DO PROJETO...........................................................................................

4

2.1 DADOS HISTÓRICOS...........................................................................................

4

2.2 DADOS DE ESTIMATIVAS E RESULTADOS............................................................ 4

2.2.1 TECNICAS DE ESTIMATIVA........................................................................

4

2.3 RESULTADOS.....................................................................................................

5 2.4 RECURSOS DO PROJETO..................................................................................... 5 2.5 DIAGRAMA DE GANTT....................................................................................... 7 3.0 ANALISE E GESTÃO DE RISCOS.....................................................................................

8

3.1 RISCOS DO PROJETO..........................................................................................

8

3.2 TABELA DE RISCOS............................................................................................. 9 3.3 REDUÇÃO E GESTÃO DE RISCOS.................................................................... 10

4.0 ORGANIZAÇÃO DO PESSOAL.......................................................................................

11

4.1 ESTRUTURA DA EQUIPE.....................................................................................

11

4.2 MECANISMOS DE COMUNICAÇÃO..................................................................... 12 4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO.......................................... 12

3

1.0 INTRODUÇÃO

Esta seção descreve uma visão geral sobre o projeto de software , mostrando suas principais funcionalidades e algumas restrições na implantação na UFS. 1.1 DESCRIÇÃO DO PROJETO

Este Módulo de extensão é parte de um sistema maior de Administração acadêmica, pois na UFS administração acadêmica abrange Ensino, Pesquisa e Extensão, ficando esse último com parte social da atividade fim da UFS. A atividade de extensão na UFS passa por uma aprovação de resolução pelo conselho de ensino e pesquisa (CONEP). Sendo assim, uma atividade de extensão segundo a resolução da UFS pode ser: projetos, cursos, eventos, produtos e prestação de serviços. Com isso um professor ou um técnico administrativo de nível superior poderá solicitar aprovação de qualquer uma dessas atividades ao setor gestor (PROEX) dessa modalidade. O gestor entra com os editais e os calendários de execução dos projetos, isso deve ser definido nos perfis de cada usuário que faz login no sistema. Os professores e técnicos entram com as solicitações de suas atividades de extensão e os estudantes fazem os relatórios das atividades propostas a eles junto com os técnicos administrativos e professores. As atividades podem ser financiadas ou não por órgãos conveniados com a UFS. Os professores ou técnicos podem solicitar mais de uma atividade de extensão, sendo que o conjunto dessas atividades em numero de 5 torna-se um programa de atividades. 1.2 PRINCIPAIS FUNÇÕES DO SISTEMA As principais funções são: O sistema deve ser capaz de prover papeis de usuários para quando os mesmos fizerem o login, apenas os módulos autorizados possam ser acessados por eles; Deve prover relatórios mensais, semestrais e anuais para os gestores das atividades; Deve ser capaz de inabilitar um professor ou técnico em uma próxima temporada de solicitação de atividades caso estes não tenham cumprido as metas das atividades solicitadas anteriormente. 1.3 RESTRIÇÕES A principal restrição encontrada até o momento está na configuração de mudanças, pois muitas funcionalidades estão sendo mudadas tanto na UFS quanto na UFRN e os merges estão sendo difíceis de administrar. Merge refere-se a integração dos sistemas tanto na UFS quanto na UFRN.

4

2.0 ESTIMATIVAS DO PROJETO

Esta seção mostrará as estimativas de custo, esforços e tempo. Sabendo o prazo para cumprir

o projeto, o gestor poderá planejar melhor as questões de recursos que abrange pessoas e

custos.

2.1 DADOS HISTÓRICOS

Como se trata da primeira vez que faço esse tipo de calculo para gerência de projeto de

software, não tenho dados históricos para apresentar.

2.2 TECNICAS DE ESTIMATIVAS E RESULTADOS

É demonstrado aqui como efetuar o cálculo para encontrar o prazo total de duração do projeto (em dias). Foi utilizada a métrica de Lorenz & Kidd, aconselhada pela Lacertae Software para estimar o prazo total deste projeto. 2.2.1 TECNICAS DE ESTIMATIVA Foi utilizada a técnica de estimativa do CPD UFS Produção de Software Ltda que é uma métrica orientada a classes onde se destaca por ser simples e fácil de utilizar e segue as regras da métrica de Lorenz & Kidd. 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. Calculo 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 de fator de multiplicação

5

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

1. Quantidade de classes chaves = 10; 2. Este sistema rodará na WEB então utilizarei a interface gráfica GUI = 2,5; 3. Classes chaves x multiplicador (10 x 2,5) = 25 classes de suporte; 4. Classes chaves + classes de suporte (10 + 25) = 35 classes projetada para o sistema; 5. Como na empresa não tenho experiência para saber exatamente a quantidade de dias-

pessoa, escolherei o valor mínimo sugerido por Lorenz & Kidd. Neste caso 15 dias-pessoa;

6. Posso agora calcular a quantidade de esforço estimada: (35 x 15) = 525 dias de trabalho;

7. Agora vou calcular os dias corridos para construir o sistema, incluindo os fins de semana, fazendo a multiplicação dos dias de trabalho com os 30 dias do mês e dividirei por 22 dias uteis: (525 x 30) = 15.750 ÷ 22 = 715,90 ≈ 716 dias corridos. Para saber os meses corridos basta dividir o resultado por 30. (716 ÷ 30) = 23,86 ≈ 24 meses corridos.

A equipe para desenvolvimento deste projeto contem 4 membros, posso então calcular a distribuição dos dias de trabalho por pessoa. Com isso tenho 525 ÷ 4 = 131,25 ≈ 131 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% 525 x 3% ≈ 16

Requisito-Analise-Desenho 40% 40% 525 x 40% 210 Geração de código 20% 20% 525 x 20% 105

Testes 37-38% 37% 525 x 37% ≈194

Resultado 525 Tabela dos dias para termino do projeto

2.4 RECURSOS DO PROJETO Os recursos usados para elaboração deste projeto serão: humanos, de software, hardware e bibliográficos. Em relação aos recursos humanos, como esse sistema na UFS trata-se muito mais de gerencia de configuração e mudanças, a fase que trata do planejamento: modelagem do negócio, requisitos, analise e design, implementação, teste e implantação que é a principal fase de construção do sistema, está a cargo dos profissionais da instituição UFRN, então esta instituição será colocada como um dos profissionais responsáveis pelo sistema e aparecerá no diagrama de Gantt.

6

Recursos humanos: A equipe de desenvolvimento do projeto é formada por quatro membros, são eles: UFRN · Gestor de Projeto · Analista de sistemas Sigelman Araujo · Gestor de Projeto · Analista de sistemas Diego Cortes · Analista de Sistemas · Programador de Software · Engenheiro de Software Vinicius · Programador de Software Carla Cássia · Testadora de Software Recursos de Software: Para o desenvolvimento deste projeto foram utilizadas as seguintes ferramentas de software: · Eclipse, software que dá apoio ao desenvolvimento em Linguagem de programação JAVA. · Java, linguagem de programação orientada a objetos, para a construção e manutenção dos softwares com recursos para WEB. · Postgres, sistema de gerência de banco de dados relacional muito usado em empresas e por grandes sistema corporativos. · Pgadmin, software para facilitar os acessos ao banco de dados para uma melhor administração visual do mesmo. · MsProject, utilizado para facilitar a administração do projeto. · Microsoft word, para fazer documentações simples. · Internet Explorer, browser de Internet. · Mozila Firefox, browser de Internet. . Linux Ubuntu ou Debian, sistemas operacionais. . Windows 7, sistema operacional. . Hibernate, Software utilizado para fazer relação objeto-relacional. . Struts, software utilizado para relacionar regras de negócio. Recursos Hardware: Os hardwares utilizados para elaboração do projeto são: · Computadores Pessoais PC da HP · 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

7

2.5 DIAGRAMA DE GANTT O diagrama de Gantt é ilustrado a seguir, trata-se de um gráfico que mostra todas as tarefas

planejadas com suas datas de inicio e fim e os recursos utilizados.

Imagem do diagrama de Gantt parte 1

Imagem do diagrama de Gantt parte 2

8

3.0 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 Existe um subconjunto de riscos que estão presentes em qualquer projeto de software, riscos gerais, que são indicados na tabela seguinte: Risco Projeto Técnico Negócio Comum Especial

Equipamento não disponivel X Requisitos incompletos X X

Uso de metodologias especiais X X Problemas na busca da confiabilidade requerida

X X

Retenção de pessoas chave X X Sub-estimativa do esforço X X

Tabela de subconjunto de riscos

Avaliação global dos riscos:

1. O Gestor de Software dá suporte ao projecto? Sim, os gestores do software tanto na UFRN quanto na UFS, principalmente o primeiro, que tem uma gestão de solicitações e demandas, para dar total suporte ao projeto como um todo.

2. Os Clientes estão entusiasmados com o projecto e o produto? Sim, os clientes ao fazerem treinamentos nas versões colocadas para este fim, ficaram entusiasmados com a possibilidade de implantação do sistema no ambito da UFS.

3. Os Engenheiros de Software compreenderam bem os requisitos? De acordo com as resoluções da UFRN, os requisitos foram bem compreendidos, faltando apenas analisar se haverá alguma mudança em relação as resoluções da UFS, porém as mudanças serão minimas, pois se tratam de dois orgão afins.

4. Os Clientes estiveram envolvidos na definição dos requisitos? Não posso afirmar em relação a UFRN, porém em relação a UFS, os clientes estão bem envolvidos, participando de todos os treinamentos e discutindo as possibilidades de mudanças e querendo saber o que tem e o que não tem implantado no sistema para satisfazer suas necessidades.

5. O âmbito do projeto é estável? Por enquanto o projeto ainda não está estável na UFS, pois as confi gurações e mudanças, principalmente nas tabelas de banco de dados de dominio, ainda estamos trabalhando muito com elas.

6. Os engenheiros de Software têm as competências requeridas? Sim, os engenheiros são bem capacitados para gerir as configurações e mudanças no sistema.

9

7. Os requisitos do projeto são estáveis? Sim, de acordo com os treinamentos, os requisitos implantados, parece não precisar de mudanças, se alguma mudança for feita, será mais para acrescentar do que para tirar ou alterar.

8. A Equipe de Desenvolvimento tem experiência na tecnologia a implementar? Todos na UFS foram capacitados com cursos nas tecnologias, principalmente de software, para a implantação do sistema.

9. É adequado o número de pessoas da equipa de trabalho? Não. Mas como as dificuldades de contratação de pessoal é grande, exigirá muito esforço por parte da equipe.

3.2 TABELA DE RISCOS Segue abaixo a lista dos riscos identificados no projeto: Risco Categoria Probabilidade Impacto

Insuficiência de pessoas na equipe

Pessoal 80% Crítico

Prazo para entrega curto

Tecnico 80% Crítico

Treinamento Usuários Docente e Discentes

Características do Cliente

30% Marginal

Mudanças nos requisitos

Projeto 10% Crítico

Falta de Motivação Pessoal 70% Marginal Rotatividade de pessoal

Pessoal 20% Catastrófico

Conflitos Pessoal 20% Marginal Tecnologia e infraestrutura (danos)

Tecnico 10% Catastrófico

Capacidade da equipe

Pessoal 10% Crítico

Perda de dados na Integração dos sistemas

Técnico 80% Catastrófico

Tabela dos riscos encontrados no projeto

10

3.3 REDUÇÃO E GESTÃO DE RISCOS

Dos itens elencados foram escolhidos dois com impacto critico e um com impacto

catastrófico para descrevermos as suas atividades de redução, supervisão e gestão do risco.

Na instituição existe um numero pequeno de profissionais de TI, até mesmo pela dificuldade na contratação dos mesmos, pois para isso deve-se abrir concurso

publico ou licitação para contratação de terceirizados e deve existir verba para

aprovação. Insuficiência de pessoas na equipe

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

Descrição: O numero de profissionais efetivos no CPD da UFS é reduzido.

Estratégia de redução: Como o CPD da UFS não tem autonomia para

contratação de pessoal, deve-se buscar com setores superiores formas de contratação de pessoal.

Plano de contingência: havendo dificuldades de abertura de concursos públicos,

abrir processo de licitação para contratação de terceirizados. Pessoa responsável: Sigelman Araujo

Status: Simulação completada

Muitas perdas de dados nos códigos ocorrem quando se faz a integração dos dados entre a UFRN e a UFS.

Perda de dados na integração dos sistemas

Risco:002 Probabilidade: 80% Impacto: Catastrófico

Descrição: Ao efetuar a integração dos repositórios UFS e UFRN, perdas de

dados existem.

Estratégia de redução: Quando desenvolvemos em paralelo com o pessoal da

UFRN, ainda está prevalecendo o repositório deles, sobrepondo as nossas

mudanças no momento da integração, então devemos trabalhar para o mais rápido possível para ficarmos independente do desenvolvimento da UFRN e

trabalharmos as nossas demandas locais sem precisar fazer a integração com

eles. Plano de contingência: Fazer todo estudo necessário com a UFRN para que a

parte essencial dos requisitos do sistema esteja de acordo com as necessidades da UFS e assim eles liberarem o módulo, deixando os profissionais deles livres

para outras tarefas e nós de cá a vontade com as nossas demandas locais. Pessoa responsável: Diego Cortes

Status: Simulação Incompleta

11

Algumas mudanças de requisitos podem ocorrer, pois apesar de as instituições

parecerem devido as suas atividades fins, algumas mudanças locais podem acontecer.

Mudanças nos requisitos

Risco:003 Probabilidade: 10% Impacto: Crítico

Descrição: Os requisitos da UFRN forem diferentes dos da UFS.

Estratégia de redução: sabendo que a fase de construção do software cabe a

UFRN, devemos alertá-los o mais rápido possível para que haja um novo versionamento do sistema para a UFS.

Plano de contingência: o Gestor deve trabalhar com a equipe da UFRN

mostrando para eles como devem ser o comportamento dos nossos requisitos.

Pessoa responsável: UFRN e Sigelman Araujo

Status: Simulação Incompleta

4.0 ORGANIZAÇÃO DO PESSOAL A nossa equipe segue uma estrutura descentralizada democrática, pois, apesar de termos um gestor competente responsável pela organização dos trabalhos, as decisões são tomadas em conjunto e com o consenso de todos e a comunicação é horizontal. Além disso, esta é a melhor estrutura para problemas complexos e que requerem muita comunicação, além de ser a que produz melhores ambientes e satisfação no trabalho. 4.1 ESTRUTURA DA EQUIPE A equipe é formada por cinco elementos e logo no inicio dos trabalhos definimos claramente as funções de cada um, sendo: UFRN - Gestor de Projeto e Analista de sistemas; Sigelman Araujo - Gestor de Projeto e Analista de sistemas; Diego Cortes - Analista de Sistemas, Programador de Software e Engenheiro de Software; Vinicius - Programador de Software e Carla Cássia - Testadora de Software. O gestor 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. O 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. O engenheiro de software estuda e seleciona tanto as ferramentas utilizadas como o hardware e plataformas onde o software será utilizado. Os programadores recebem o trabalho do analista e programam o código do novo sistema. O testador no fim testa exaustivamente todo o sistema de forma a detectar erros na implementação.

12

4.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 e MSN Messenger, e meios de comunicação telefônica. 4.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO Achamos o Edu-blog uma excelente ferramenta de apoio à disciplina, pois é fácil e agradável de utilizar, permite ao professor disponibilizar todo o material referente à disciplina e possibilita a comunicação entre o docente e todos os alunos, sendo muito útil para cada um apresentar as suas dúvidas e 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. No entanto para comunicação entre os membros da equipe, utilizamos o MSN Messenger.