Exemplo Plano de Projecto EduMobile

MS Word to PDF Batch Convert Multiple Documents Software - Please purchase licen
se 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 d
escrição do seu âmbito, de seguida enumera as principais funções que o sistema deve assegu
rar. Descreve-se também quais são os requisitos de comportamento e temporais da apli
caçã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 Dig
ital 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 u
ma 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 is
so o professor deverá criar um perfil de avaliação no início de cada período lectivo, ou s
eja, 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 si
stema possa fazer o cálculo da mesma. O sistema terá ainda um administrador responsáve
l pela introdução e alteração de dados (professores, escola, alunos, turmas e disciplina
s) na base de dados, tendo em conta que esse administrador poderá ser o próprio prof
essor. 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 en
sino e deverá ter uma interface útil e de fácil utilização para que possa ser utilizado po
r professores sem grande experiência com novas tecnologias.
Universidade do Algarve Faculdade de Ciência e Tecnologia
1
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 auten
garmente conhecido como login onde o utilizador (Professores ou administrador) s
e irá identificar por meio de uma password; A marcação de presenças, faltas disciplinare
s ou de material; Efectuar todo e qualquer registo sobre o comportamento e momen
tos 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 utiliza
dores (Professores ou pedagogos) devem poder escolher quais os aspectos mais rel
evantes que contabilizam para a avaliação dos alunos daquela turma especifica; O pro
fessor ou pedagogo poderá associar diferentes perfis de avaliação às várias turmas que lec
ciona, fazendo deste software um produto dinâmico; Escolha do estabelecimento de e
nsino dos vários existentes onde o utilizador lecciona;
• •
1.3 Requisitos comportamentais ou de performance Em termos de performance, o sof
tware terá que responder adequadamente a certos requisitos, sendo os essenciais so
bretudo a interface e acessibilidade. É necessário que a interface que o software ap
resenta seja agradável e apelativa ao utilizador mas no entanto também deve ser bast
ante simples e fácil de utilizar, uma vez que esta vai ser implementada num sistem
a ubíquo (PDA), sendo que a introdução de dados é feita através dum touch-screen. Terá que
er composto por um conjunto de opções seleccionáveis de modo a que a escrita seja mini
mizada, 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 correctamen
te as avaliações dos alunos. No que diz respeito aos requisitos comportamentais, tod
as as funcionalidades são criticas, pelo que devem estar a funcionar correctamente
para o bom funcionamento do software.
2
1.4 Gestão e Restrições Técnicas Restrições técnicas: No que diz respeito ao hardware e sof
re do trabalho conseguimos preencher todos os requisitos mínimos para concepção do nos
so trabalho. • • • Em termos de hardware um elemento da equipa possuía um aparelho PDA p
ara testar a aplicação que desenvolvemos. Em termos de software, a escolha de softwa
re de download livre através da licença académica que cada aluno possui no MSDN, facil
itaram 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 desconhecim
ento 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 q
e 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 revel
a-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, pa
ra 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 po
r isso uma restrição em termos temporais.
•
3
2.0 ESTIMAÇÕES DO PROJECTO
As estimações do projecto são importantes no sentido em que o gestor terá uma maior perc
epção da longevidade que o projecto terá ou seja o tempo total do projecto. Por sua ve
z também pode efectuar os cálculos necessários para determinar o tempo de cada fase do
projecto, fase de planeamento, requisitosanalise-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 projec
tos de software. 2.2 Técnicas de estimação e resultados Nesta secção é demonstrado como efe
tuar 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 ut
ilizaremos a métrica de Lorenz & Kidd, aconselhada pela Lacertae Software. 2.2.1 Téc
nica de estimação Para este projecto vamos utilizar a técnica de estimação usada em projec
tos 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
antitativa do grau de posse de um atributo dado por parte de um sistema, compone
nte ou processo” Para usar a métrica de Lorenz & Kidd temos que: 1. Definir o número d
e classes chave. Interface não gráfica Multiplicador 2
2. Encontrar o número de classes de suporte, que para isso temos que baseada em te
xto 2,25 classificar o tipo de Interface do Produto e desenvolver um Multiplicad
or para as GUI 2,5 Classes de Suporte
Tabela 1.1 - Factores multiplicativos para encontrar o n de classes de suporte
GUI complexa
3,0
4
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma e
stimaçã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. Multipl
icar 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 just
ificar a escolha. 6. Determinar a quantidade de esforço estimada. 7. Calculo do te
mpo previsto para a elaboração do projecto 2.3 Resultados Com base na métrica de Loren
z & 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. Mul
tiplicador 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
5. De seguida escolhe-se o número médio de unidades de trabalho (dias-pessoa) por cl
asse onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Em
conjunto optamos por escolher 18 diaspessoa devido ao facto de não estarmos muito
ou quase nada familiarizados com as nossas ferramentas de trabalho, como por exe
mplo o “Enterprise Architect”, o “Microsoft Visual Studio .NET 2003”, “Microsoft SQL Serve
r 2005” e o “Microsoft Project 2003”, em relação a deixar as coisas para fazer à última hor
té não é o nosso lema de trabalho, mas por vezes como existem outros trabalhos paralel
amente nem sempre é possível fazer tudo como pretendíamos. 6. Sendo assim o cálculo da q
uantidade do esforço estimada é: 30.5 X 18 = 549 dias de trabalho 7. Agora se preten
demos ter os dias/meses corridos (incluindo os fins de semana), temos que multip
licar 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 748.64 / 30 = 24.95 749 dias corrido
s
25 Meses corridos
Poderemos calcular agora os dias de trabalho por pessoa, e sendo assim temos 3 e
lementos na equipa para este projecto a dividir por 549 dias de trabalho ficarem
os 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 c
om as seguintes percentagens de distribuição dos componentes essenciais num projecto
: 1) 2) 3) 4) Planeamento: 2-3% Requisitos – Análise – Desenho: 40% Geração de Código: 20%
estes: 37-38%
Os valores calculados são: 1) 2) 3) 4) Planeamento: Requisitos – Análise – Desenho: Geração
de código: Testes: 549 * 3% = 549 * 40% = 549 * 20% = 549 * 37% = 16 dias de traba
lho 220 dias de trabalho 110 dias de trabalho 203 dias de trabalho_ 549 Dias de
trabalho
6
2.4 Recursos do projecto De seguida enumera-se todos os recursos usados para ela
boração desde projecto, os recursos podem ser: humanos, de software, hardware e bibl
iográficos.
Recursos humanos: A equipa de desenvolvimento do projecto é formada por três element
os, 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 util
izadas as seguintes ferramentas de software: • • • • Enterprise Architect 6.1 da empresa
Sparx para suporte ao desenho do sistema. Visual Studio .NET 2003 da empresa Mi
crosoft para a criação da aplicação de software para o PDA. Microsoft Office 2003, proce
ssamento 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 toda
s as tarefas do projecto. 7
•
Microsoft SQL Server 2005, sistema de gestão de base de dados da Microsoft muito u
sado 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 pro
jecto são basicamente os computadores pessoais dos elementos da equipa e o disposi
tivo ubíquo para testar a aplicação. • • Toshiba Pocket PC e400 Computadores Portáteis e De
ktops dos membros da Equipa
Recursos Bibliográficos: Estes são os recursos mais importantes na ausência de conheci
mento 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 E
ditora 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 Nune
s, Mauro, O’Neill Henrique, Fundamental de UML, FCA Silva, Alberto, Videira, Carlo
s, UML, Metodologias e Ferramentas Case, Centro Atlântico, Lda., 2001 8
• •
• •
Kimmel, Paul, “Managing SQL in Visual Studio .NET”, http://www.developer.com/db/arti
cle.php/3092741 Pinheiro, Nilton, “Instalando e Configurando o SQL Server 2005 Exp
ress”, http://www.mcdbabrasil.com.br/modules.php?name=News&file=articl e&sid=67 MS
DN Library, “Visual Studio .NET”, http://msdn2.microsoft.com/enus/library/aa973739(V
S.71).aspx Maestro, Daniela Cristina, “Visual Basic 5”, retirado de www.apostilando.
com
9
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 exa
ustiva análise e há que saber geri-los de forma a tentar evitálos ou minimizá-los. 3.1 R
iscos 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 Equipamento não disponível Requisitos incompletos Uso de metodologias especiai
s Problemas na busca da confiabilidade requerida Retenção de pessoas chave Sub-estim
ativa do esforço Projecto Técnico Negócio Comum Especial
X X X X X X X X X 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 gest
or 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 adquiri
rem o produto final. 3. Os Engenheiros de Software compreenderam bem os requisit
os? Sim, os engenheiros estão bem conscientes dos requisitos do projecto 4. Os Cli
entes 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 pot
encial cliente. 5. O âmbito do projecto é estável? Não, o âmbito do nosso projecto já foi a
terado várias vezes na procura de uma maior viabilidade do produto.
10
6. Os engenheiros de Software têm as competências requeridas? Apesar de pouco experi
entes, os engenheiros de Software têm óptimas capacidades e a competência necessária par
a a elaboração deste projecto. 7. Os requisitos do projecto são estáveis? Não, tal como o â
bito 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 imple
mentar? Não, infelizmente a experiência da Equipa de Desenvolvimento na tecnologia é p
raticamente 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 reduzid
o número de pessoas o que levará a um esforço complementar de cada um. 3.2 Tabela de r
iscos Na tabela 2.2 encontram-se descritos todos os riscos identificados no proj
ecto. 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 probabi
lidade de o risco acontecer e na quarta o tamanho de impacto que o risco pode ca
usar no projecto. Risco Data de entrega muito ajustada Âmbito instável Objectivos ma
l compreendidos Indefinição de papeis responsabilidades Mudança nos requisitos Ferrame
ntas inadequadas/inexistentes Falta de formação nas ferramentas Categoria Probabilid
ade Negócio Tamanho Negócio e Pessoal Negócio Negócio Pessoal 80% 70% 60% 30% 80% 20% 80
% 60% 10% Impacto Crítico Crítico Crítico Marginal Crítico Crítico Marginal Marginal Catas
trófico 11
Insuficiente número de pessoas na Pessoal equipa Extravio do trabalho efectuado Pe
ssoal
Sub-estimativa do tempo/esforço Falta de motivação Conflitos entre os participantes In
sucesso na venda do produto Retenção de pessoas-chave
Tamanho Pessoal Pessoal Negócio Pessoal
60% 20% 10% 90% 10%
Crítico Crítico Catastrófico Catastrófico 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 aleatoriame
nte para descrevermos as suas actividades de redução, supervisão e gestão do risco. Um d
os riscos identificados foi o designado de “Ferramentas inadequadas/inexistentes”. D
evido à 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 par
a 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 funcionalidad
es requeridas Estratégia de redução: Pesquisas e/ou pedido de ajuda a pessoas mais exp
erientes sobre as ferramentas ideais para a realização do projecto. Plano de contingên
cia: Alteração das ferramentas utilizadas Ferramentas actualmente utilizadas: o Ente
rprise Architect 6.1 o Visual Studio .NET 2003 o Microsoft Project 2003 o Sql Se
rver Ferramentas que poderiam ser uma alternativa: o Microsoft Visio 2000 o Micr
osoft Visual Basic 6.0 o MinuteMan Project Management Software o Microsoft Acces
s 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”.
12
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 fa
tal do sistema o que origina a perda do trabalho que se estava a desenvolver. Fi
ca aqui o nosso estudo a esse risco. Extravio do trabalho efectuado Risco: 002 P
rob: 10% Impacto: Catastrófico
Descrição: Perda total ou parcial do trabalho realizado por falha humana ou tecnológic
a. Estratégia de redução: Guardar constantemente o trabalho que se está a desenvolver, f
azer backups e enviar rapidamente aos restantes elementos do grupo quando se adi
anta algum trabalho. Plano de contingência: Pedido de alargamento do prazo de entr
ega. Pessoa responsável: Michael Viegas, Celso Brito, Renato Santos (07-10-2006) S
tatus: 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 subestimativa do tempo/esf
orço ou apenas se aplicarem a sério já muito perto da data limite. Sub-estimativa do t
empo/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
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 d
e tarefas sempre que necessário. Plano de contingência: Redução das funcionalidades do s
istema. Pedido de alargamento do prazo de entrega. Pessoa responsável: Celso Brito
(21-10-2006)
13
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 merca
do. Estratégia de redução: Criação de protótipos específicos (versões beta do software) par
tribuiçã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 co
ntingê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 incomple
ta
Tabela 2.3 – Descrição do risco “Insucesso na venda do produto”.
14
4.0 PLANEAMENTO TEMPORAL
No planeamento temporal define-se as datas de execução das tarefas e os responsáveis p
elas tarefas, este processo designa-se Diagrama de Gantt. Sendo a pessoa responsáv
el 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 Rec
ursivo-Paralelo que permite desenvolver rapidamente um protótipo executável, o que l
eva 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 gradualm
ente funcionalidades ao software e ao mesmo tempo melhorar as que já tenham sido i
mplementadas. 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 dese
nvolvimento com alguma facilidade, ao mesmo tempo que vamos concretizar um produ
to que vai o mais possível de encontro às expectativas do cliente. Após realizada a Es
timação do Projecto de SW, a divisão do plano de tarefas pela percentagem de tempo foi
efectuada da seguinte maneira: Tarefas Planeamento Análise – Desenho Geração de Código Ma
nutenção e testes Percentagem tempo 3% 40% 20% 37% do Dias de Actividade 16 220 110
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-t
arefas das várias fases do projecto, onde estas tarefas tem todas uma data de inic
io e dada de conclusão, estando também sempre associado a um ou mais elementos da eq
uipa de desenvolvimento do projecto.
15
Figura 1.1 – Imagem (Parte 1) do diagrama de Gantt que contém todas as tarefas a ela
borar em cada fase do projecto.
16
17
18
5.0 ORGANIZAÇÃO DO PESSOAL
A nossa equipa segue uma estrutura descentralizada democrática pois, apesar de ter
mos um gestor competente responsável pela organização dos trabalhos, as decisões são tomad
as 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 t
rabalhos definimos claramente as funções de cada um, sendo: Celso Brito – Gestor do pr
ojecto e programador de software Renato Santos – Programador de software e Engenhe
iro de Software Michael Viegas – Analista de sistemas e testador de software O ges
tor tem a responsabilidade de coordenar todo o desenvolvimento do projecto, comb
inando reuniões, distribuindo tarefas, resolver conflitos e manter a motivação e bom a
mbiente no seio do grupo, para alem de ser responsável pelo planeamento temporal d
o projecto compondo o diagrama de Gantt. O analista de sistema tem a função de anali
sar o software e desenhar os vários diagramas do sistemas e criar as classes e int
erfaces a implementar. O engenheiro de software estuda e selecciona tanto as fer
ramentas a utilizar como o hardware e plataformas onde o software será utilizado O
s programadores recebem o trabalho do analista e implementam o código do novo sist
ema O testador no fim testa exaustivamente todo o sistema de forma a detectar er
ros na implementação.
5.2 Mecanismos de comunicação A comunicação entre todos os elementos da equipa é feita pri
ncipalmente através de reuniões periódicas e nas aulas onde se faz o ponto da situação, re
solvem-se problemas em conjunto e distribui-se tarefas. Para além disso são também uti
lizadas os meios de comunicação electrónica, através de correio electrónico e MSN Messenge
r, e meios de comunicação telefónica.
19
5.3 Uso do Edu-blog como ferramenta de apoio Achamos o Edu-blog uma excelente fe
rramenta de apoio à disciplina pois é fácil e agradável de utilizar, permite ao professo
r disponibilizar todo o material referente à disciplina e possibilita a comunicação en
tre 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 interessant
na medida que permite a cada grupo partilhar com a comunidade o desenvolvimento
do seu trabalho, disponibilizando ficheiros, bem como receber sugestões e critica
s de qualquer pessoa. No entanto não nos parece ser a ferramenta mais adequada par
a efectuar a comunicação entre os elementos da equipa como foi sugerido pelo profess
or, 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
20
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 dive
rsos cuidados, segue-se assim uma descrição de todas as medidas tomadas para assegur
ar a qualidade dos produtos de software desenvolvidos pela Lacertae SW e mais pr
opriamente pela equipa RangersTeam: • • Seguimento e Controle do Projecto de SW – Acom
panhamento contínuo ao trabalho desenvolvido por parte de todos os participantes n
o projecto Revisões Técnicas Formais – Para além do acompanhamento, o trabalho já desenvol
vido 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 cu
primento dos requisitos e garantir o seguimentos dos standards. Gestão de Configur
ação do SW – Com o objectivo estabelecer e manter a integridade dos produtos de softwa
re ao longo do seu ciclo de vida, devem ser identificados os objectos básicos e co
mpostos 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 especifi
ações do produto. Gestão de Reutilização – Deve haver por parte do programador a responsabi
idade de implementar código reutilizável. Medições – Realização de medições em relação á fi
empo médio entre falhas), à disponibilidade (tempo médio de falhas / tempo médio entre f
alhas) x 100 (%) e à segurança (calculo da gravidade de possíveis falhas) Análise de Ris
cos – Identificar todos os riscos inerentes ao projecto e elaborar os planos de re
dução e de contingência. Testes – Testar exaustivamente o sistema com o objectivo de ide
ntificar 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.
21

Exemplo Plano de Projecto EduMobile

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Exemplo Plano de Projecto EduMobile

Enviado por

Direitos autorais:

Formatos disponíveis

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

Você também pode gostar