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

Transcrição

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

2 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. 1

3 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. 2

4 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. 3

5 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, 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 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 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: 1. Definir o número de classes chave. Interface Multiplicador não gráfica 2 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 baseada em texto 2,25 GUI 2,5 Tabela Factores multiplicativos para encontrar o nº de classes de suporte GUI complexa 3,0 4

6 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 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, 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 = =

7 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 diaspessoa 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 = / 22 = dias corridos / 30 = 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 6

8 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º Gestor de Projecto Programador de Software Renato Santos - Nº Programador de Software Engenheiro de Software Michael Viegas - Nº 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. 7

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

10 Kimmel, Paul, Managing SQL in Visual Studio.NET, Pinheiro, Nilton, Instalando e Configurando o SQL Server 2005 Express, e&sid=67 MSDN Library, Visual Studio.NET, Maestro, Daniela Cristina, Visual Basic 5, retirado de 9

11 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 Avaliação Global do Risco: Tabela 2.1- Tabela que indica os riscos de projectos na generalidade. 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. 10

12 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 11

13 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 3.3 Redução e Gestão do Risco Tabela 2.2 Tabela de Riscos identificados no projecto. 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. 12

14 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 ( ) Status: Simulação completada ( ) 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/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 ( ) 13

15 Status: Simulação completada ( ) 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 ( ) Status: Simulação incompleta Tabela 2.3 Descrição do risco Insucesso na venda do produto. 14

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

17 Figura 1.1 Imagem (Parte 1) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projecto. 16

18 Figura 1.2 Imagem (Parte 2) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projecto. 17

19 Figura 1.3 Imagem (Parte 3) do diagrama de Gantt que contém todas as tarefas a elaborar em cada fase do projecto. 18

20 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. 19

21 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 é: 20

22 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. 21