PLANO DO PROJECTO DE SOFTWARE OO para produtos da Lacertae SW

Transcrição

1 PLANO DO PROJECTO DE SOFTWARE OO para produtos da Lacertae SW 1.0 INTRODUÇÃO 1.1 Âmbito do Projecto O produto destina-se a todos os estabelecimentos de ensino do 2º/3º Ciclo e Ensino Secundário e deverá ser usado pelos professores ou pedagogos principalmente durante o seu horário da componente lectiva, visto que, estes serão os principais intervenientes na avaliação dos seus alunos. Para se proceder a essa mesma avaliação os professores e pedagogos deverão equacionar a ponderação de cada factor avaliativo (comportamento, assiduidade, testes, fichas, trabalhos) criando assim, ao que chamaremos perfil de avaliação, para que seja calculada a sua nota final. Já o administrador do sistema fará maior uso do produto no início de cada ano lectivo para introdução de dados (professores, alunos, turmas e disciplinas) no PDA. As funcionalidades que o software implementa são as descritas em baixo: Deve ser um sistema seguro Para isso cada utilizador (Professores ou pedagogos) deve conter uma conta que estará protegida com palavra-chave. Um utilizador (Professores ou pedagogos) poderá inserir ou actualizar alguns dados casuais de aluno ou Encarregado de Educação. Assinalar faltas de presença, disciplinar ou material, informação esta que servirá também para cálculo da nota final. Efectuar todo e qualquer registo sobre o comportamento e momentos de avaliação (testes, trabalhos e afins) 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. Ter uma Interface útil e de fácil utilização, para que qualquer professor ou pedagogo mesmo sem estar ambientado com as novas tecnologias o possa utilizar. Possibilidade de transferência da base de dados existente no estabelecimento de ensino, todos os dados dos alunos/professores/encarregados de educação directamente para o PDA, sendo o administrador do sistema encarregue de o fazer. 1

2 1.2 Funções principais do produto de software Decomposição inicial das funções para serem usadas na estimação e planeamento temporal. Aqui serão listados os futuros métodos das Classes-chave (ou seja, as operações, serviços ou métodos que dizem respeito ao domínio do problema), seus dados de entrada e saída. 1.3 Requisitos comportamentais ou de performance Quaisquer requisitos relacionados com a performance (tempos de execução, sincronização com equipamentos ligados ao software) do sistema e aspectos especiais de comportamento (características da interface, etc.). 1.4 Gestão e Restrições Técnicas Restrições que afectarão a maneira de conduzir o projecto (ex. recursos limitados, datas de entrega inflexíveis). Aqui também são apontadas as abordagens técnicas do desenvolvimento de software (processo de software utilizados, téetc.) 2

3 2.0 ESTIMAÇÕES DO PROJECTO 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 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. Para usar a métrica de Lorenz & Kidd temos que: 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 Interface não gráfica 2 Multiplicador baseada em texto 2,25 3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimação do número de classes de suporte GUI 2,5 GUI complexa 3,0 Imagem 1: Factores multiplicativos para encontrar o nº 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 dias-pessoa e justificar a escolha. 6. Determinar a quantidade de esforço estimada. 3

4 7. Calculo do tempo previsto para a elaboração do projecto 2.3 Resultados 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, 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 = = Em conjunto escolhemos 18 dias-pessoa devido ao facto de não estarmos muito ou quase nada familiarizados com as nossas ferramentas de trabalho, como o Enterprise Architect, o Visual Studio.NET 2003 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. O calculo 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 = / 22 = dias corridos / 30 = meses corridos 4

5 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 Recursos humanos: A equipa de trabalho é formada por três elementos, sendo eles: Celso Brito - Nº Gestor de Projecto Programador de Software Renato Santos - Nº Programador de Software Engenheiro de Software Michael Viegas - Nº Analista de Sistemas 2. Testador de Software 5

6 Recursos 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 Power point, utilizado para fazer a apresentação final do produto. Mozilla Firefox, browser de Internet. Internet Explorer, browser de Internet. Recursos Hardware: Toshiba Pocket PC e400 Computadores Portáteis e Desktops dos membros da Equipa Recursos Bibliográficos: Fundamental de UML 2º Edição actualizada, FCA Gestão de Projectos com o Microsoft Project 2003, FCA 6

7 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 disponível 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 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. 7

8 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 Aqui fica a tabela com os riscos identificados: 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 8

9 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. 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 Pessoa responsável: Renato Santos (14/11/2006) Status: Simulação completada (14/11/2006) 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: Micheal Viegas, Celso Brito, Renato Santos () Status: Simulação completada () 9

10 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 () Status: Simulação completada () 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: Celso Brito () Status: Simulação completada () 10

11 4.0 PLANEAMENTO TEMPORAL 4.1 Conjunto de Tarefas do Projecto O modelo de processo escolhido para o desenvolvimento do nosso projecto foi o modelo recursivo paralelo. A divisão do plano de tarefas foi efectuada da seguinte maneira: Tarefas Percentagem do tempo Dias de Actividade Planeamento 3% 16 Analise Desenho 40% 220 Geração de Codigo 20% 110 Manutenção e testes 37% Diagrama de Gantt 11

12 12

13 13

14 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. 14

15 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 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, 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. 15

16 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 Revisões Técnicas Formais Garantia de Qualidade do SW Gestão de Configuração do SW Produção de Documentação Gestão de Reutilização Medições Análise de Riscos Testes 16