Exemplo Plano de Projecto - EduMobile

MS Word to PDF Batch Convert Multiple Documents Software - Please purchase
license to remove this.

Projecto: Software de Apoio a Professores e Pedagogos em Dispositivos PDA
Equipa: RangersTeam (Celso Brito, Renato Santos, Michael Viegas)
Plano do Projecto de Software OO

para produtos da Lacertae SW
1.0 INTRODUÇÃO
Esta secção descreve uma visão geral sobre o projecto de software, iniciando
com uma descrição do seu âmbito, de seguida enumera as principais funções que
o sistema deve assegurar. Descreve-se também quais são os requisitos de
comportamento e temporais da aplicação e seguidamente fala-se das restrições
técnicas e temporais existentes no projecto.
1.1 Âmbito do Projecto
Este projecto tem o objectivo de desenvolver um produto de software para a

empresa Lacertae SW que consiste numa aplicação em PDA (Personal Digital
Assistant) que auxilie o trabalho de um professor na gestão da avaliação dos seus
alunos.
Para este projecto não existe um cliente específico, vamos tentar atingir
uma quota de mercado com um produto pois, apesar de já existir algo semelhante
para PC, ainda não existe para dispositivos ubíquos, neste caso o PDA.
O professor deverá usar o nosso produto maioritariamente durante as

aulas, de modo a poder registar todos os dados relativos à avaliação dos alunos
de forma fácil, prática e segura. Para isso o professor deverá criar um perfil de
avaliação no início de cada período lectivo, ou seja, equacionar o peso ou
percentagem que cada factor avaliativo (comportamento, assiduidade, testes,
fichas, trabalhos) terá em relação à nota final de modo a que o sistema possa
fazer o cálculo da mesma.
O sistema terá ainda um administrador responsável pela introdução e

alteração de dados (professores, escola, alunos, turmas e disciplinas) na base de
dados, tendo em conta que esse administrador poderá ser o próprio professor.
Inicialmente este produto irá abranger apenas estabelecimentos de ensino

do 2º/3º ciclo e ensino secundário, podendo no futuro ser estendido a outros tipos
de ensino e deverá ter uma interface útil e de fácil utilização para que possa ser
utilizado por professores sem grande experiência com novas tecnologias.
Universidade do Algarve 1
Faculdade de Ciência e Tecnologia
1.2 Funções principais do produto de software
As principais funções que esta ferramenta deverá assegurar são:
• Deve ser um sistema seguro – deverá ter um sistema de autenticação

vulgarmente conhecido como login onde o utilizador (Professores ou
administrador) se irá identificar por meio de uma password;
• A marcação de presenças, faltas disciplinares ou de material;
• Efectuar todo e qualquer registo sobre o comportamento e momentos de
avaliação (testes, trabalhos e afins);
• Efectuar cálculo da nota final;

• Os métodos de avaliação devem ser personalizáveis ou seja no início de
cada ano lectivo os utilizadores (Professores ou pedagogos) devem poder
escolher quais os aspectos mais relevantes que contabilizam para a
avaliação dos alunos daquela turma especifica;
• O professor ou pedagogo poderá associar diferentes perfis de avaliação às
várias turmas que lecciona, fazendo deste software um produto dinâmico;
• Escolha do estabelecimento de ensino dos vários existentes onde o
utilizador lecciona;
1.3 Requisitos comportamentais ou de performance
Em termos de performance, o software terá que responder adequadamente

a certos requisitos, sendo os essenciais sobretudo a interface e acessibilidade. É
necessário que a interface que o software apresenta seja agradável e apelativa ao
utilizador mas no entanto também deve ser bastante simples e fácil de utilizar,
uma vez que esta vai ser implementada num sistema ubíquo (PDA), sendo que a
introdução de dados é feita através dum touch-screen. Terá que ser composto por
um conjunto de opções seleccionáveis de modo a que a escrita seja minimizada,
assim deste modo um professor não despende muito tempo na introdução dos
dados, mas que estes sejam, ao mesmo tempo, os necessários para descriminar
correctamente as avaliações dos alunos.
No que diz respeito aos requisitos comportamentais, todas as

funcionalidades são criticas, pelo que devem estar a funcionar correctamente para
o bom funcionamento do software.
1.4 Gestão e Restrições Técnicas
Restrições técnicas:
No que diz respeito ao hardware e software do trabalho conseguimos preencher

todos os requisitos mínimos para concepção do nosso trabalho.
• Em termos de hardware um elemento da equipa possuía um aparelho PDA

para testar a aplicação que desenvolvemos.
• Em termos de software, a escolha de software de download livre através da
licença académica que cada aluno possui no MSDN, facilitaram imenso o
trabalho no desenvolvimento da nossa aplicação.
• Uma potencial restrição que impede de certa forma o avanço no projecto é
a falta de experiência ou desconhecimento de métodos de trabalho com as
ferramentas de trabalho seleccionadas.
Restrições Temporais:
• De facto também seremos afectados por restrições temporais, visto que o

projecto tem data de conclusão de 12 de Dezembro o tempo é insuficiente
para uma correcta formação nas ferramentas escolhidas. Este prazo
previamente definido revela-se algo curto para a realização do projecto que
tivemos em mente desde o princípio, o que se constituiu como uma
potencial restrição à procura de um maior desenvolvimento.
• O planeamento correcto é essencial ao sucesso do desenvolvimento do

projecto, para isso, é necessário um conhecimento razoavelmente coerente
sobre o desempenho dos participantes no projecto, a duração das tarefas,
as fases e os requisitos que temos de definir e outros tópicos essenciais.
Alguns desses requisitos exigem um cálculo instintivo da sua duração, pelo
que nem sempre esta estimação é a correcta, tornando-se por isso uma
restrição em termos temporais.
2.0 ESTIMAÇÕES DO PROJECTO
As estimações do projecto são importantes no sentido em que o gestor terá

uma maior percepção da longevidade que o projecto terá ou seja o tempo total do
projecto. Por sua vez também pode efectuar os cálculos necessários para
determinar o tempo de cada fase do projecto, fase de planeamento, requisitos-
analise-desenho, implementação e testes.
2.1 Dados históricos utilizados para as estimações
De momento não possuímos quaisquer dados históricos visto que nenhum

elemento da equipa contém experiência na realização de projectos de software.
2.2 Técnicas de estimação e resultados
Nesta secção é demonstrado como efectuar todo o calculo para encontrar o

tempo total de duração do projecto (em dias) e para encontrar esse tempo é
necessário aplicar uma técnica de estimação, que neste caso utilizaremos a
métrica de Lorenz & Kidd, aconselhada pela Lacertae Software.
2.2.1 Técnica de estimação
Para este projecto vamos utilizar a técnica de estimação usada em projectos de

SW OO da Lacertae Software, técnica essa que é a Lorenz & Kidd que é uma
métrica orientada a classes onde se destaca por ser simples e fácil de utilizar.
Posso então mencionar a definição de métrica para que não restem duvidas do
que é uma métrica: “Medida quantitativa do grau de posse de um atributo dado
por parte de um sistema, componente ou processo”
Para usar a métrica de Lorenz & Kidd temos

que:
Interface Multiplicador
1. Definir o número de classes chave.
não gráfica 2
2. Encontrar o número de classes de

suporte, que para isso temos que baseada em texto 2,25
classificar o tipo de Interface do Produto e
desenvolver um Multiplicador para as
GUI 2,5
Classes de Suporte
Tabela 1.1 - Factores multiplicativos para GUI complexa 3,0

encontrar o nº de classes de suporte
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma

estimação do número de classes de suporte
4. De seguida, 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 projecto
2.3 Resultados
Com base na métrica de Lorenz & Kidd em cima descrita obtivemos os resultados
seguintes:
1. Nº classes chave = 9
2. Escolhemos o Interface com base na aplicação gráfica que irá ter o produto
final. Multiplicador do GUI = 2,5
3. 9 X 2.5 = 22.5
Logo teremos 22,5 Classes de Suporte.
4. O número total de classes é igual a:
Nº Classes Chave + Nº Classes de Suporte = 22.5 + 8 = 30.5
5. De seguida escolhe-se o número médio de unidades de trabalho

(dias-pessoa) por classe onde a métrica Lorenz & Kidd sugere entre 15 e
20 dias-pessoa por classe. Em conjunto optamos por escolher 18 dias-
pessoa devido ao facto de não estarmos muito ou quase nada
familiarizados com as nossas ferramentas de trabalho, como por exemplo o
“Enterprise Architect”, o “Microsoft Visual Studio .NET 2003”,
“Microsoft SQL Server 2005” e o “Microsoft Project 2003”, em relação a
deixar as coisas para fazer à última hora até não é o nosso lema de
trabalho, mas por vezes como existem outros trabalhos paralelamente nem
sempre é possível fazer tudo como pretendíamos.
6. Sendo assim o cálculo da quantidade do esforço estimada é:
30.5 X 18 = 549 dias de trabalho
7. Agora se pretendemos ter os dias/meses corridos (incluindo os fins de

semana), temos que multiplicar os dias de trabalho com os 30 dias corridos e
de seguida dividir pelos os 22 dias úteis.
549 X 30 = 16470 / 22 = 748.64 749 dias corridos
748.64 / 30 = 24.95 25 Meses corridos
Poderemos calcular agora os dias de trabalho por pessoa, e sendo assim

temos 3 elementos na equipa para este projecto a dividir por 549 dias de trabalho
ficaremos com aproximadamente 183 dias de trabalho para elemento de equipa.
Sabendo-se os dias de trabalho totais (549 dias), estes dias são agora
distribuídos de acordo com as seguintes percentagens de distribuição dos
componentes essenciais num projecto:
1) Planeamento: 2-3%
2) Requisitos – Análise – Desenho: 40%
3) Geração de Código: 20%
4) Testes: 37-38%
Os valores calculados são:
1) Planeamento: 549 * 3% = 16 dias de trabalho

2) Requisitos – Análise – Desenho: 549 * 40% = 220 dias de trabalho
3) Geração de código: 549 * 20% = 110 dias de trabalho
4) Testes: 549 * 37% = 203 dias de trabalho_
549 Dias de trabalho
2.4 Recursos do projecto
De seguida enumera-se todos os recursos usados para elaboração desde

projecto, os recursos podem ser: humanos, de software, hardware e bibliográficos.
Recursos humanos:
A equipa de desenvolvimento do projecto é formada por três elementos,
sendo eles:
Celso Brito - Nº 25074
• Gestor de Projecto
• Programador de Software
Renato Santos - Nº 24143
• Programador de Software
• Engenheiro de Software
Michael Viegas - Nº 22618
• Analista de Sistemas
• Testador de Software
Recursos de Software:
Para o desenvolvimento de todo o nosso projecto foram utilizadas as
seguintes ferramentas de software:
• Enterprise Architect 6.1 da empresa Sparx para suporte ao

desenho do sistema.
• Visual Studio .NET 2003 da empresa Microsoft para a criação da

aplicação de software para o PDA.
• Microsoft Office 2003, processamento de texto para a criação dos

vários documentos a disponibilizar ao director e aos clientes.
• Microsoft Project 2003, utilizado para fazer o planeamento de todas

as tarefas do projecto.
• Microsoft SQL Server 2005, sistema de gestão de base de dados

da Microsoft muito usado em empresas e por grandes sistema
corporativos.
• Microsoft Power point, utilizado para fazer a apresentação final do

produto.
• Mozilla Firefox, browser de Internet.
• Internet Explorer, browser de Internet.
Recursos Hardware:
Em relação aos recursos de hardware utilizados para elaboração do
projecto são basicamente os computadores pessoais dos elementos da
equipa e o dispositivo ubíquo para testar a aplicação.
• Toshiba Pocket PC e400
• Computadores Portáteis e Desktops dos membros da Equipa
Recursos Bibliográficos:
Estes são os recursos mais importantes na ausência de conhecimento
sobre algum tema ou área específica, assim sendo foram utilizamos para
ganhar os tais conhecimentos que nos faltavam para conseguirmos
elaborar este projecto.
• Monteiro, Manuela Matos, Caderneta de Registos do Professor - 5

Turmas, Porto Editora
• Nascimento, Rogério – Engenharia de Software,
http://w3.ualg.pt/~rnascimento/
• Feio, Rui A. L., Gestão de Projectos com o Microsoft Project 2003,
FCA, 2004
• Nunes, Mauro, O’Neill Henrique, Fundamental de UML, FCA
• Silva, Alberto, Videira, Carlos, UML, Metodologias e Ferramentas
Case, Centro Atlântico, Lda., 2001
• Kimmel, Paul, “Managing SQL in Visual Studio .NET”,

http://www.developer.com/db/article.php/3092741
• Pinheiro, Nilton, “Instalando e Configurando o SQL Server 2005
Express”,
http://www.mcdbabrasil.com.br/modules.php?name=News&file=articl
e&sid=67
• MSDN Library, “Visual Studio .NET”, http://msdn2.microsoft.com/en-
us/library/aa973739(VS.71).aspx
• Maestro, Daniela Cristina, “Visual Basic 5”, retirado de
www.apostilando.com
3.0 ANÁLISE E GESTÃO DE RISCOS
Um risco é um problema potencial e todos os projectos estão sujeitos a

determinados riscos que não podem ser ignorados, antes pelo contrário, devem
ser alvos de uma exaustiva análise e há que saber geri-los de forma a tentar evitá-
los ou minimizá-los.
3.1 Riscos do projecto
Existe um subconjunto de riscos que estão presentes em qualquer projecto

de software, riscos gerais, que são indicados na tabela seguinte:
Risco Projecto Técnico Negócio Comum Especial

Equipamento não
X
disponível
Requisitos incompletos X X
Uso de metodologias
X X
especiais
Problemas na busca da
X X
confiabilidade requerida
Retenção de pessoas
X X
chave
Sub-estimativa do esforço X X
Tabela 2.1- Tabela que indica os riscos de projectos na generalidade.
Avaliação Global do Risco:
1. O Gestor de Software dá suporte ao projecto?

Sim, o gestor de software é um participante activo em todo o
desenvolvimento do projecto.
2. Os Clientes estão entusiasmados com o projecto e o produto?

De momento não possuí-mos clientes para o projecto, porque passam a ser
apenas clientes no acto de adquirirem o produto final.
3. Os Engenheiros de Software compreenderam bem os requisitos?

Sim, os engenheiros estão bem conscientes dos requisitos do projecto
4. Os Clientes estiveram envolvidos na definição dos requisitos?

Não, porque não temos um cliente específico, apenas trocamos algumas
impressões através de diálogos informais com um potencial cliente.
5. O âmbito do projecto é estável?

Não, o âmbito do nosso projecto já foi alterado várias vezes na procura de
uma maior viabilidade do produto.
6. Os engenheiros de Software têm as competências requeridas?

Apesar de pouco experientes, os engenheiros de Software têm óptimas
capacidades e a competência necessária para a elaboração deste projecto.
7. Os requisitos do projecto são estáveis?

Não, tal como o âmbito também os requisitos têm sofrido algumas
alterações de forma a melhorar a qualidade do software.
8. A Equipa de Desenvolvimento tem experiência na tecnologia a

implementar?
Não, infelizmente a experiência da Equipa de Desenvolvimento na
tecnologia é praticamente nula mas todos os elementos estão motivados
para aprender.
9. É adequado o número de pessoas da equipa de trabalho?

Não, é um trabalho extenso para um reduzido número de pessoas o que
levará a um esforço complementar de cada um.
3.2 Tabela de riscos
Na tabela 2.2 encontram-se descritos todos os riscos identificados no projecto. Os

riscos estão enumerados da seguinte forma, na primeira coluna encontra-se a
descrição do risco, na segunda coluna a categoria do risco, na terceira a
probabilidade de o risco acontecer e na quarta o tamanho de impacto que o risco
pode causar no projecto.
Risco Categoria Probabilidade Impacto

Data de entrega muito ajustada Negócio 80% Crítico
Âmbito instável Tamanho 70% Crítico
Objectivos mal compreendidos Negócio 60% Crítico

Indefinição de papeis e Pessoal 30% Marginal
responsabilidades
Mudança nos requisitos Negócio 80% Crítico
Ferramentas Negócio 20% Crítico

inadequadas/inexistentes
Falta de formação nas ferramentas Pessoal 80% Marginal
Insuficiente número de pessoas na Pessoal 60% Marginal

equipa
Extravio do trabalho efectuado Pessoal 10% Catastrófico
Sub-estimativa do tempo/esforço Tamanho 60% Crítico

Falta de motivação Pessoal 20% Crítico
Conflitos entre os participantes Pessoal 10% Catastrófico
Insucesso na venda do produto Negócio 90% Catastrófico
Retenção de pessoas-chave Pessoal 10% Catastrófico
Tabela 2.2 – Tabela de Riscos identificados no projecto.
3.3 Redução e Gestão do Risco
Dos riscos tabelados escolhemos quatro deles aleatoriamente para descrevermos

as suas actividades de redução, supervisão e gestão do risco.
Um dos riscos identificados foi o designado de “Ferramentas

inadequadas/inexistentes”. Devido à nossa experiência e falta de conhecimento
das funcionalidades de algumas das ferramentas utilizadas pode acontecer o facto
de estas não serem as indicadas para o que pretendemos implementar.
Ferramentas inadequadas/inexistentes
Risco: 001 Prob: 30% Impacto: Crítico
Descrição: As ferramentas utilizadas não são as próprias para implementar as

funcionalidades requeridas
Estratégia de redução: Pesquisas e/ou pedido de ajuda a pessoas mais
experientes sobre as ferramentas ideais para a realização do projecto.
Plano de contingência: Alteração das ferramentas utilizadas
Ferramentas actualmente utilizadas:
o Enterprise Architect 6.1
o Visual Studio .NET 2003
o Microsoft Project 2003
o Sql Server
Ferramentas que poderiam ser uma alternativa:
o Microsoft Visio 2000
o Microsoft Visual Basic 6.0
o MinuteMan Project Management Software
o Microsoft Access 2003
Pessoa responsável: Renato Santos (14/11/2006)
Status: Simulação completada (14/11/2006)
Tabela 2.3 – Descrição do risco “Ferramentas inadequadas/Inexistentes”.
Outro risco aqui tabelado é o “Extravio do trabalho efectuado”. Quando se trabalha

em computador corre-se sempre o risco de acontecimentos inesperados como um
erro fatal do sistema o que origina a perda do trabalho que se estava a
desenvolver. Fica aqui o nosso estudo a esse risco.
Extravio do trabalho efectuado
Risco: 002 Prob: 10% Impacto: Catastrófico
Descrição: Perda total ou parcial do trabalho realizado por falha humana ou

tecnológica.
Estratégia de redução: Guardar constantemente o trabalho que se está a
desenvolver, fazer backups e enviar rapidamente aos restantes elementos do
grupo quando se adianta algum trabalho.
Plano de contingência: Pedido de alargamento do prazo de entrega.
Pessoa responsável: Michael Viegas, Celso Brito, Renato Santos (07-10-2006)
Status: Simulação completada (07-10-2006)
Tabela 2.4 – Descrição do risco “Extravio do trabalho efectuado”.
Para além do prazo de entrega reduzido em relação à complexidade do sistema

há que ter em conta o facto de ser muito habitual em estudantes uma sub-
estimativa do tempo/esforço ou apenas se aplicarem a sério já muito perto da data
limite.
Sub-estimativa do tempo/esforço
Risco: 003 Prob: 60% Impacto: Crítico
Descrição: Erro na estimação do tempo necessário para a realização de tarefas
Estratégia de redução: Realização de reuniões periódicas de forma a verificar

se o desenvolvimento do projecto está a corresponder às estimativas. Redefinir o
planeamento temporal e a distribuição de tarefas sempre que necessário.
Plano de contingência: Redução das funcionalidades do sistema. Pedido de
alargamento do prazo de entrega.
Pessoa responsável: Celso Brito (21-10-2006)
Status: Simulação completada (10-11-2006)
Tabela 2.5 – Descrição do risco “Sub-estimativa do tempo/esforço”.
! "# $ % $ &
" $ '$ (#
$ $
)$ *+ $ $ ,
Insucesso na venda do produto
Risco: 004 Prob: 90% Impacto: Catastrófico
Descrição: Produto foi um fracasso e não existiu aceitação por parte dos
clientes no mercado.
Estratégia de redução: Criação de protótipos específicos (versões beta do
software) para distribuição pelos vários professores para que tenham
conhecimento das potencialidades do produto de forma a ficarem interessados
na compra final do produto.
Plano de contingência: Repensar todo o produto e verificar as funcionalidades
que seriam mais úteis com base nas opiniões dos clientes que utilizaram o
protótipo.
Pessoa responsável: Michael Viegas, Celso Brito, Renato Santos (16-11-2006)
Status: Simulação incompleta
Tabela 2.3 – Descrição do risco “Insucesso na venda do produto”.
4.0 PLANEAMENTO TEMPORAL
No planeamento temporal define-se as datas de execução das tarefas e os

responsáveis pelas tarefas, este processo designa-se Diagrama de Gantt. Sendo
a pessoa responsável pelo planeamento do Gestor de projecto.
4.1 Conjunto de Tarefas do Projecto
O modelo de processo escolhido para o desenvolvimento do nosso projecto foi o

Recursivo-Paralelo que permite desenvolver rapidamente um protótipo
executável, o que leva a uma validação concreta e não apenas a partir da
documentação. Este processo pressupõe o melhoramento incremental do
software, ou seja, permite ir adicionando gradualmente funcionalidades ao
software e ao mesmo tempo melhorar as que já tenham sido implementadas.
Outra vantagem deste modelo é o facto que através de um contacto quase
permanente com o cliente permite ajustar o software e o seu planeamento de
desenvolvimento com alguma facilidade, ao mesmo tempo que vamos concretizar
um produto que vai o mais possível de encontro às expectativas do cliente.
Após realizada a Estimação do Projecto de SW, a divisão do plano de tarefas pela

percentagem de tempo foi efectuada da seguinte maneira:
Tarefas Percentagem do Dias de Actividade

tempo
Planeamento 3% 16
Análise – Desenho 40% 220
Geração de Código 20% 110
Manutenção e testes 37% 203
Tabela 3.1 – Tabela que contém o tempo (dias de trabalho) por cada fase do projecto.
4.2 Diagrama de Gantt
O diagrama de Gantt é composto pela divisão em tarefas e sub-tarefas das várias

fases do projecto, onde estas tarefas tem todas uma data de inicio e dada de
conclusão, estando também sempre associado a um ou mais elementos da equipa
de desenvolvimento do projecto.
Figura 1.1 – Imagem (Parte 1) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projecto.
5.0 ORGANIZAÇÃO DO PESSOAL
A nossa equipa 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 para além de ser a que produz
melhores ambientes e satisfação no trabalho.
5.1 Estrutura da equipa
A equipa é formada por três elementos e logo no inicio dos trabalhos definimos
claramente as funções de cada um, sendo:
Celso Brito – Gestor do projecto e programador de software
Renato Santos – Programador de software e Engenheiro de Software
Michael Viegas – Analista de sistemas e testador de software
O gestor tem a responsabilidade de coordenar todo o desenvolvimento do

projecto, combinando reuniões, distribuindo tarefas, resolver conflitos e manter
a motivação e bom ambiente no seio do grupo, para alem de ser responsável
pelo planeamento temporal do projecto compondo o diagrama de Gantt.
O analista de sistema tem a função de analisar o software e desenhar os vários

diagramas do sistemas e criar as classes e interfaces a implementar.
O engenheiro de software estuda e selecciona tanto as ferramentas a utilizar

como o hardware e plataformas onde o software será utilizado
Os programadores recebem o trabalho do analista e implementam o código do

novo sistema
O testador no fim testa exaustivamente todo o sistema de forma a detectar

erros na implementação.
5.2 Mecanismos de comunicação
A comunicação entre todos os elementos da equipa é feita principalmente

através de reuniões periódicas e nas aulas onde se faz o ponto da situação,
resolvem-se problemas em conjunto e distribui-se tarefas. Para além disso são
também utilizadas os meios de comunicação electrónica, através de correio
electrónico e MSN Messenger, e meios de comunicação telefónica.
5.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 equipa, pensamos que é também interessante

na medida que permite a cada grupo partilhar com a comunidade o
desenvolvimento do seu trabalho, disponibilizando ficheiros, bem como receber
sugestões e criticas de qualquer pessoa. No entanto não nos parece ser a
ferramenta mais adequada para efectuar a comunicação entre os elementos da
equipa como foi sugerido pelo professor, para isso é muito mais prático os
meios de comunicação que referimos anteriormente.
Já agora passo indicar o endereço onde se encontra o nosso Blog, o Blog dos
Rangers é:
http://rangersteam.blogspot.com
6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E

CONTROLAR A QUALIDADE DO PRODUTO DE SW
Para assegurar e controlar a qualidade do produto de Software, é

necessário ter diversos cuidados, segue-se assim uma descrição de todas as
medidas tomadas para assegurar a qualidade dos produtos de software
desenvolvidos pela Lacertae SW e mais propriamente pela equipa
RangersTeam:
• Seguimento e Controle do Projecto de SW – Acompanhamento

contínuo ao trabalho desenvolvido por parte de todos os
participantes no projecto
• Revisões Técnicas Formais – Para além do acompanhamento,
o trabalho já desenvolvido deve também ser revisto
periodicamente com o objectivo de identificar erros a nível lógico,
funcional ou de implementação das representações do software,
verificar o cumprimento dos requisitos e garantir o seguimentos
dos standards.
• Gestão de Configuração do SW – Com o objectivo estabelecer
e manter a integridade dos produtos de software ao longo do seu
ciclo de vida, devem ser identificados os objectos básicos e
compostos da configuração e controladas as várias versões do
software produzidas.
• Produção de Documentação – Deve ser elaborados
documentos em relação ao plano do projecto e às especificações
do produto.
• Gestão de Reutilização – Deve haver por parte do programador
a responsabilidade de implementar código reutilizável.
• Medições – Realização de medições em relação á fiabilidade,
(tempo médio entre falhas), à disponibilidade (tempo médio de
falhas / tempo médio entre falhas) x 100 (%) e à segurança
(calculo da gravidade de possíveis falhas)
• Análise de Riscos – Identificar todos os riscos inerentes ao
projecto e elaborar os planos de redução e de contingência.
• Testes – Testar exaustivamente o sistema com o objectivo de
identificar possíveis erros antes que estes se transformem em
defeitos.
Todas estas medidas encontram-se inseridas durante as várias fases do

projecto de modo que a sua qualidade final seja substancialmente mais
elevada. Isto pode ser verificado no diagrama de Gantt, onde estão descritas
todas as tarefas elaboradas ao longo do desenvolvimento do projecto.

Exemplo Plano de Projecto - EduMobile

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Exemplo Plano de Projecto - EduMobile

Diunggah oleh

Hak Cipta:

Format Tersedia

MS Word to PDF Batch Convert Multiple Documents Software - Please purchase

license to remove this.

Plano do Projecto de Software OO

1.1 Âmbito do Projecto

Este projecto tem o objectivo de desenvolver um produto de software para a

O professor deverá usar o nosso produto maioritariamente durante as

O sistema terá ainda um administrador responsável pela introdução e

Inicialmente este produto irá abranger apenas estabelecimentos de ensino

1.2 Funções principais do produto de software

As principais funções que esta ferramenta deverá assegurar são:

• Deve ser um sistema seguro – deverá ter um sistema de autenticação

• Efectuar cálculo da nota final;

1.3 Requisitos comportamentais ou de performance

Em termos de performance, o software terá que responder adequadamente

No que diz respeito aos requisitos comportamentais, todas as

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

No que diz respeito ao hardware e software do trabalho conseguimos preencher

• Em termos de hardware um elemento da equipa possuía um aparelho PDA

• De facto também seremos afectados por restrições temporais, visto que o

• O planeamento correcto é essencial ao sucesso do desenvolvimento do

2.0 ESTIMAÇÕES DO PROJECTO

As estimações do projecto são importantes no sentido em que o gestor terá

2.1 Dados históricos utilizados para as estimações

De momento não possuímos quaisquer dados históricos visto que nenhum

2.2 Técnicas de estimação e resultados

Nesta secção é demonstrado como efectuar todo o calculo para encontrar o

2.2.1 Técnica de estimação

Para este projecto vamos utilizar a técnica de estimação usada em projectos de

Para usar a métrica de Lorenz & Kidd temos

2. Encontrar o número de classes de

Tabela 1.1 - Factores multiplicativos para GUI complexa 3,0

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

4. De seguida, calcula-se a quantidade total de Classes, somando o nº de

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

6. Determinar a quantidade de esforço estimada.

7. Calculo do tempo previsto para a elaboração do projecto

Logo teremos 22,5 Classes de Suporte.

4. O número total de classes é igual a:

Nº Classes Chave + Nº Classes de Suporte = 22.5 + 8 = 30.5

5. De seguida escolhe-se o número médio de unidades de trabalho

6. Sendo assim o cálculo da quantidade do esforço estimada é:

30.5 X 18 = 549 dias de trabalho

7. Agora se pretendemos ter os dias/meses corridos (incluindo os fins de

549 X 30 = 16470 / 22 = 748.64 749 dias corridos

748.64 / 30 = 24.95 25 Meses corridos

Poderemos calcular agora os dias de trabalho por pessoa, e sendo assim

Os valores calculados são:

1) Planeamento: 549 * 3% = 16 dias de trabalho

2.4 Recursos do projecto

De seguida enumera-se todos os recursos usados para elaboração desde

Celso Brito - Nº 25074

Renato Santos - Nº 24143

Michael Viegas - Nº 22618

• Enterprise Architect 6.1 da empresa Sparx para suporte ao

• Visual Studio .NET 2003 da empresa Microsoft para a criação da

• Microsoft Office 2003, processamento de texto para a criação dos

• Microsoft Project 2003, utilizado para fazer o planeamento de todas

• Microsoft SQL Server 2005, sistema de gestão de base de dados

• Microsoft Power point, utilizado para fazer a apresentação final do

• Mozilla Firefox, browser de Internet.

• Internet Explorer, browser de Internet.

• Toshiba Pocket PC e400

• Computadores Portáteis e Desktops dos membros da Equipa

• Monteiro, Manuela Matos, Caderneta de Registos do Professor - 5