Eng software

390 visualizações

Publicada em

Trabalho Final Mestrado disciplina Engenharia de Software 2014.

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
390
No SlideShare
0
A partir de incorporações
0
Número de incorporações
19
Ações
Compartilhamentos
0
Downloads
4
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Eng software

  1. 1. UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA DEPARTAMENTO DE COMPUTAÇÃO PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO AMILTON DE AZEVEDO GONÇALVES MARCUS VINÍCIUS ANDRADE CÔRTES PEDRO FELIPE DE LIMA PLANO DE PROJETO DE SOFTWARE OO PARA ESCOLA DE LÍNGUAS SÃO CRISTÓVÃO 2014
  2. 2. AMILTON DE AZEVEDO GONÇALVES MARCUS VINÍCIUS ANDRADE CÔRTES PEDRO FELIPE DE LIMA PLANO DE PROJETO DE SOFTWARE OO PARA ESCOLA DE LÍNGUAS Trabalho realizado no módulo de Gestão de Projetos ministrado pelo docente Dr. Rogério Patrício Chagas do Nascimento na disciplina de Engenharia de Software da Pós-Graduação em Ciência da Computação (Curso de Mestrado Acadêmico) da Universidade Federal de Sergipe (UFS). SÃO CRISTÓVÃO 2014
  3. 3. LISTA DE TABELAS Tabela 1: Fatores multiplicativos para encontrar o nº de classes de suporte........................... 11 Tabela 2: Percentual de componentes essenciais em um projeto............................................. 12 Tabela 3: Divisão de dias trabalho em cada componente........................................................... 12 Tabela 4: Recursos humanos do projeto........................................................................................ 13 Tabela 5: Identificação dos Riscos do Projeto............................................................................... 15 Tabela 6: Riscos do Projeto.............................................................................................................. 16 Tabela 7: Planos de redução de riscos......................................................................................... 167 Tabela 8: Estrutura da Equipe........................................................................................................ 255 Tabela 9: Descrição das Atividades .............................................................................................. 265
  4. 4. LISTA DE ILUSTRAÇÕES Ilustração 1: Cronograma A do Projeto........................................................................................... 21 Ilustração 2: Cronograma B do Projeto........................................................................................... 22 Ilustração 3: Cronograma C do Projeto .......................................................................................... 23 Ilustração 4: Cronograma D do Projeto .......................................................................................... 24
  5. 5. SUMÁRIO 1. INTRODUÇÃO......................................................................................................6 1.1. Âmbito do projeto ...........................................................................................6 1.2. Funções principais do produto de software....................................................6 1.3. Requisitos comportamentais ou de performance ...........................................7 1.4. Gestão e Restrições Técnicas .......................................................................8 2. ESTIMATIVAS DE PROJETO ..............................................................................9 2.1. Dados históricos utilizados para as estimações...........................................10 2.2. Ténicas de estimação e resultados..............................................................10 2.2.1. Técnicas de estimação..........................................................................10 2.3. Resultados ...................................................................................................11 2.4. Recursos do projeto .....................................................................................13 2.4.1. Recursos humanos...................................................................................13 2.4.2. Recursos de software ...............................................................................13 2.4.3. Recursos do ambiente de desenvolvimento .............................................13 3. ANÁLISE E GESTÃO DE RISCOS.....................................................................14 3.1. Riscos do projeto .........................................................................................14 3.2. Tabela de Identificação dos riscos ...............................................................16 3.3. Redução e gestão de risco...........................................................................17 4. PLANEJAMENTO TEMPORAL ..........................................................................19 4.1. Diagrama de Gantt.......................................................................................19 5. ORGANIZAÇÃO DO PESSOAL .........................................................................25 5.1. Estrutura da equipe......................................................................................25 5.2. Mecanismos de Comunicação .....................................................................26 5.3. Uso do Edu-Blog como ferramenta de apoio ...............................................26 6. QUALIDADE......................................................... Error! Bookmark not defined. 7. REFERÊNCIAS ..................................................................................................28
  6. 6. 6 1. INTRODUÇÃO O objetivo deste documento é definir com detalhes os fatores relevantes de panejamento, execução e acompanhamento do desenvolvimento do Software Yázigi On-line. Além disso, descrever uma visão geral sobre o projeto de software. O Yázigi On-line é um software de gerenciamento para escolas de línguas da rede Yázigi de ensino, com possibilidade de se adaptar a outras escolas de línguas, caso haja necessidade. O software, desenvolvido inicialmente para ser acessado via Web tem como objetivo permitir que os alunos, docentes e funcionários possam ter uma comunicação mais dinâmica e interagir através de serviços oferecidos online. 1.1. ÂMBITO DO PROJETO Seu objetivo principal é gerenciar matrículas e turmas, para isso o software utiliza-se de uma interface usável e responsivo para quebrar as barreiras da sala de aula, sendo possível qualquer dispositivo com acesso a internet, seja ele um computador pessoal ou qualquer dispositivo móvel, acessar o software. Além do programa um dashboard, contendo detalhes de suas atividades e conta com vários serviços online, gerando comodidade e agilidade aos seus usuários, possibilitando uma interação dos serviços das unidades de línguas além das fronteiras da sala de aula. 1.2. FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE O sistema deve colaborar nas atividades acadêmicas entre o corpo docente e discentes. E auxiliará no gerenciamento da unidade. Mais especificamente, o sistema pretende facilitar a comunicação entre professores,
  7. 7. 7 alunos, unidade escolar e o controle da unidade, oferecendo, entre outras opções de serviços. Seguem subsequente enumerado os requisitos descritos no escopo do produto do software. i. Autenticar usuários para acesso ao mesmo, aonde o utilizador (aluno, docente, administrador ou funcionário), irá se identificar através de login e senha, sendo assim apenas os módulos autorizados acessados pelo mesmo; ii. Disponibilizar relatórios diários para os gestores das atividades; iii. Gerar atas de frequência de acordo com as solicitações do docente da turma; iv. Oferecer ao docente e aluno uma ata de presença; v. Registrar todo e qualquer tipo atividade sobre a turma (avaliações, métricas de desempenho dos alunos e turma, frequência dos alunos e atividades extras; vi. Disponibilizar ao docente a inserção das notas dos alunos, sendo assim os alunos podem visualizar suas notas após as atividades e avaliações no sistema e acompanhar seu desempenho diante as atividades elaboradas na turma; vii.Oferecer uma área para os alunos realizarem matrículas; viii. Permitir à visualização dos dados de uma solicitação de aluno a secretária da escola; ix. Permitir aos alunos a visualização de seu histórico de atividades e notas no sistema; x. Consultar diariamente as matrículas e mensalidades com pagamento pendente. 1.3. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE Os requisitos comportamentais ou de performance são os seguintes: i. Sobre os requisitos comportamentais, as funcionalidades são consideradas críticas, através do ponto de vista da importância do correto funcionamento para amplitude das atividades disponíveis.
  8. 8. 8 ii. O sistema deve funcionar on line, conectado ao bancos de dados, com tempo de resposta máximo de 2 segundos para cada ação solicitada pelo usuário e atender a cerca de mais de 250 usuários on line e simultâneos. iii. Será necessário que a interface apresentada seja agradável, com acessibilidade, simples e fácil de utilizar em todos os dispositivos, e sua interação deve ir além disso, terá que ser composta por um conjunto de opções selecionáveis de modo que a escrita seja minimizada, já que o software deve esta disponível para a grande maioria dos dispositivos móveis. iv. O sistema deverá ser bastante intuitivo quanto ao uso de suas funções, requerendo pouco ou nenhum treinamento para ser utilizado. Testes de usabilidade serão necessários para se garantir tal requisito. v. As atualizações de versões do software devem acontecer de maneira automática, a partir do deploy1 do desenvolvimento. vi. O sistema deverá evitar que pessoas não autorizadas tenham acesso ao conteúdo privado e de outros usuários. Será exigido o login para certificar-se sobre o acesso ao sistema. 1.4. GESTÃO E RESTRIÇÕES TÉCNICAS O cliente tem a expectativa de receber o software em no máximo 4 meses, mas o prazo será negociado com base nas estimativas produzidas neste plano de projeto. O projeto será utilizará metodologias ágeis de gerenciamento e execução. A principal será o framework Scrum. Framework – É uma abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. 1.4.1 Restrições Técnicas: O hardware pertencente à equipe não é compatível com a tecnologia adotada. Sendo necessária a compra de novos equipamentos que atendam a necessidade; 1 É a tarefa de instalar uma aplicação em diversas estações de maneira simples e eficiente visando organizar, facilitar e agilizar a manutenção da rede local após sua implementação.
  9. 9. 9 Em termos de software, a escolha de software open source2 para os desenvolvedores facilitou o trabalho no desenvolvimento da aplicação; Falta de capacitação técnica da equipe, sendo necessário um treinamento específico; Falta de experiência e prática nas ferramentas e métodos utilizados para o desenvolvimento do software. 1.4.2 Restrições Temporais: O prazo definido pelo cliente é curto para o desenvolvimento do projeto e para uma boa formação nas ferramentas escolhidas, sendo assim será negociado com o cliente o desenvolvimento e entrega de forma incremental, definindo marcos a serem entregues. O planejamento de maneira bem sucedida, respeitando as estimativas e limitações do projeto são essenciais para obter o sucesso do desenvolvimento do projeto, para isso, é necessário um conhecimento razoavelmente coerente sobre o desempenho dos participantes no projeto, 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 correta, tornando-se por isso uma restrição em termos temporais. 2. ESTIMATIVAS DE PROJETO As estimações do projeto são importantes para ter uma maior velocidade na tomada de decisões no período de levantamento da viabilidade do projeto, ou seja, o tempo total do projeto. Reforçando que a estimativa é essencial para saber lidar com as previsões e cronogramas, e por sua vez, estimar custos, esforços e efetuar os cálculos necessários para determinar o tempo de cada fase do projeto, fase de panejamento, requisitos, análise, desenho, implementação e testes. 2 Open Source – O termo código aberto (open source, em inglês), diz respeito a software de utilização livre, cuja licença não é cobrada e cujo código fonte é disponibilizado, de forma gratuita, pelo autor.
  10. 10. 10 2.1. DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMAÇÕES De momento não existem informações históricas por conta que nenhum membro da equipe possui a experiência na realização de projetos de software. Sendo assim não possuímos dados históricos para relato. 2.2. TÉNICAS DE ESTIMAÇÃO E RESULTADOS Nesta seção é demonstrado como efetuar todo o cálculo para encontrar o tempo total de duração do projeto (em dias). Para encontrar esse tempo é necessário aplicar uma técnica de estimativas e neste caso utilizaremos a métrica de Lorenz & Kidd, aconselhada pela Lacertae Software. 2.2.1. Técnicas de estimação Para este projeto a métrica usada em projetos de Software Orientados a Objetos da Lacertae Software. Essa técnica é a Lorenz & Kidd. Trata-se de uma métrica orientada a classes, a qual 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, que esta na Tabela 1 e desenvolver um Multiplicador para as Classes de Suporte. 3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter uma estimativa do número de classes de suporte. 4. Calcular a quantidade total de Classes, somando o nº de Classes- Chave com o nº de Classes de Suporte.
  11. 11. 11 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. Deve-se escolher um número entre 15-20 dias-pessoa e justificar a escolha. 6. Determinar a quantidade de esforço estimada. 7. Cálcular o tempo previsto para a elaboração do projeto. Interface Multiplicador Não gráfica 2,0 Baseada em textos 2,25 GUI 2,5 GUI complexa 3,0 Tabela 1: Fatores multiplicativos para encontrar o nº de classes de suporte Na Tabela 1 são apresentados os tipos de interfaces com o usuário. Para o projeto foi escolhido a interface GUI onde o fator multiplicador é 2,5. Foi escolhido essa interface tendo visto a necessidade de uma interface mais interativa com o usuário. Detalhes da escolha da interface será mostrado na subseção 2.3 deste projeto. 2.3. RESULTADOS Com base na métrica de Lorenz & Kidd, obtivemos os seguintes resultados: 1. Nº de classes chave = 5; 2. Foi escolhida a Interface com base na aplicação gráfica que irá ter o produto final. Multiplicador do GUI = 2,5; 3. 5 X 2,5 = 12,5 . Logo teremos 12,5 Classes de Suporte. 4. O número total de classes é igual a: Nº Classes Chave + Nº Classes de Suporte = 5 + 12,5 = 17,5 5. Foi escolhido 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 20 dias-pessoa devido ao fato de ser a
  12. 12. 12 primeira experiência que o processo scrum será utilizado com as ferramentas de trabalho disponibilizadas na empresa. 6. Sendo assim, o cálculo da quantidade do esforço estimada é: 17,5 X 20 = 350 dias de trabalho. Novamente com base nos dias de trabalho total (350 dias), estes dias serão distribuídos de acordo com as seguintes percentagens de distribuição dos componentes essenciais em um projeto. Componentes Essenciais Percentual Planejamento 2% à 3% Requisitos – Análise – Desenho 40% Geração de Código 20% Testes 37% à 38% Tabela 2: Percentual de componentes essenciais em um projeto Na Tabela 2 são apresentados o percentual de componentes essenciais em um projeto. Os componentes essenciais foram dividos em: Planejamento com 2% à 3%; Requisitos – Análise – Desenho com 40%; Geração de código com 20% e testes com 37% à 38%. Componentes Essenciais Percentual Utilizado Dias de Trabalho Planejamento 3% 10,5 Requisitos – Análise – Desenho 40% 140 Geração de Código 20% 70 Testes 37% 129,5 Total dias de Trabalho 350 Tabela 3: Divisão de dias trabalho em cada componente Na Tabela 3 são apresentados a divisão de dias de trabalho em cada componente. Os componentes foram dividos em: Planejamento; Requisitos – Análise – Desenho; Geração de código e testes. Pode-se calcular agora os dias de trabalho por pessoa. Sendo assim haverá 3 membros da equipe para este projeto e 350 dias de trabalho. Dividindo o
  13. 13. 13 total de dias pelos membros da equipe ficaremos com aproximadamente 116,66 ≈ 117 dias de trabalho para cada membro da equipe. 2.4. RECURSOS DO PROJETO 2.4.1. Recursos humanos O projeto contará com três pessoas que exercerão os diversos papéis necessários à execução do projeto para o desenvolvimento do software conforme Tabela 4: Papéis Responsável Gerente de projeto Marcus Analise de sistema Amilton e Marcus Arquiteto Pedro Desenvolvedor Amilton e Pedro Testador Marcus Tabela 4: Recursos humanos do projeto Na Tabela 4 são apresentados os recursos humanos envolvidos no projeto e o papel que cada um. O fato de ser uma equipe pequena alguns membros da equipe terão que assumir mais de um papel. 2.4.2. Recursos de software Não serão utilizados componentes de software, uma vez que não foram encontrados componentes reutilizáveis que atendam aos requisitos especificados para o nosso projeto. 2.4.3. Recursos do ambiente de desenvolvimento Para o projeto será disponibilizado um ambiente com os seguintes recursos:
  14. 14. 14 Hardware: Três notebooks que servirão para o desenvolvimento do projeto e dois computadores em rede local que servirão como servidor de homologação, banco de dados e aplicações. Software: Para o desenvolvimento do projeto foram utilizadas as seguintes ferramentas de software: ● Star UML (Linguagem de Modelagem Unificada), software que modela vários tipos de diagramas; ● MindMeister (www.mindmeister.com), uma ferramenta online para criação de fluxogramas, mapas mentais e diagramas em geral; ● BROffice, processamento de texto para a criação dos documentos disponibilizados; ● Microsoft Project 2007, utilizado para fazer o panejamento de todas as tarefas do projeto; ● Chorme, browser de Internet. 3. ANÁLISE E GESTÃO DE RISCOS 3.1. RISCOS DO PROJETO Há uma categoria de riscos que estão presentes em qualquer projeto de software. Estes riscos são denominados riscos gerais e podem ser vistos na Tabela 5: Risco Projeto 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
  15. 15. 15 Sub-estimativa do esforço x x Desistência do único cliente potencial x x Tabela 5: Identificação dos Riscos do Projeto A Tabela 5 apresenta a identificação dos riscos do projeto, comum a maioria dos projetos. Porém alguns riscos estão presentes em mais de uma categoria, o que demanda mais atenção para o seu gerenciamento. Avaliação Global do Risco: 1. O Gestor de Software dá suporte ao projeto? Sim, o gestor de software é um participante importante e presente e todo o desenvolvimento do projeto, inclusive na comunicação com os usuários. 2. Os Clientes estão entusiasmados com o projeto e o produto? Sim, pois trará maior agilidade no processo de gestão das escolas e seus serviços internos. 3. Os Engenheiros de Software compreenderam bem os requisitos? Sim, os engenheiros de software estão bem conscientes dos requisitos do projeto. Pois todos acompanharam o processo de como funciona a gestão das escolas. 4. Os Clientes estiveram envolvidos na definição dos requisitos? Sim, pois é de grande interesse por parte dos clientes que o sistema contemple todas as funcionalidades. 5. O âmbito do projeto é estável? Até o presente momento sim, pois como os clientes participaram do levantamento dos requisitos, ainda não foram detectadas falhas que implicassem na modificação do projeto. 6. Os engenheiros de software têm as competências requeridas? Os engenheiros de software são competentes, já fazem parte de diversos projetos da empresa. 7. Os requisitos do projeto são estáveis? Não, pois existe a possibilidade de mudar os usuários responsáveis pelas definições dos requisitos. 8. A equipe de desenvolvimento tem experiência na tecnologia que será utilizada?
  16. 16. 16 Sim, a equipe tem experiência com a tecnologia, pois já trabalha com a mesma a algum tempo. 9. É adequado o número de pessoas da equipa de trabalho? Sim, pois o tamanho do projeto e o prazo estimado atendem as necessidades da empresa e dos clientes. 3.2. TABELA DE IDENTIFICAÇÃO DOS RISCOS Na seguinte Tabela 6, encontram-se descritos todos os riscos identificados no projeto. Os riscos estão enumerados da seguinte forma, na primeira coluna encontra-se ID dos riscos, na segunda a descrição do risco, na terceira coluna a categoria do risco, na quarta a probabilidadede o risco acontecer e na quinta o tamanho de impacto que o risco pode causar no projeto. ID Risco Categoria Probabilidade Impacto 04 Falta de acompanhamento da qualidade de software por equipe especializada maturidade 90% 5 02 Custo associado com produto defeituoso negócios 90% 5 07 Novos métodos de engenharia de software tecnologia 50% 4 05 Número de clientes que utilizam o software tecnologia 60% 4 03 Retenção de talentos pessoas 90% 4 08 Contratação de pessoas com habilidades pessoas 50% 4 01 Equipe sem treinamento necessário pessoas 80% 4 06 Custo com o atraso da entrega do produto negócios 50% 4 09 Interface para usuário específico tecnologia 20% 4 10 Dedicação dos funcionários pessoas 30% 4 11 Não acompanhar as fases do projeto cliente 70% 3 Tabela 6: Riscos do Projeto Na Tabela 6 estão apresentados os riscos encontrados no projeto, organizado pela categoria, probabilidade de ocorrência e seu impacto esperado no projeto. As estratégias de redução dos mesmos podem ser observadas na seção 3.3.
  17. 17. 17 3.3. REDUÇÃO E GESTÃO DE RISCO Dos riscos elencados, escolhemos nove deles para descrevermos as suas atividades de redução, supervisão e gestão do risco. Risco: 01 Prob: 80% Impacto: Crítico Descrição: Equipe sem treinamento necessário Estratégia de redução: Surgerir que os membros participem de treinamentos e discursões em grupo como atividade corporativa. Plano de contigência: Realizar treinamentos e fazer parcerias com centros de treinamentos especialisados. Pessoa responsável: Pedro Felipe de Lima Status: Adquirindo informações para iniciar o treinamento Risco: 02 Prob: 90% Impacto: Catastrófico Descrição: Custo associado com produto defeituoso Estratégia de redução: Utilizar processos de testes no produto. Plano de contigência: Iniciar o processo de testes paralelo ao desenvolvimento, para reduzir o número de erros. Pessoa responsável: Pedro Felipe de Lima Status: Planejando processo de testes Risco: 03 Prob: 90% Impacto: Crítico Descrição: Retenção de talentos Estratégia de redução: Acompanhar a motivação dos funcionários em relação às suas atividades e investigar suas necessidades diante do ambiente de trabalho. Desenvolver atividades motivadoras para os membros. Plano de contingência: Realizar backups e Manutenção nos computadores Pessoa responsável: Pedro Felipe de Lima Status: Criando atividades motivadoras Risco: 04 Prob: 90% Impacto: Catastrófico Descrição: Falta de acompanhamento da qualidade de software por equipe especializada.
  18. 18. 18 Estratégia de redução: Dedicar pessoas e tempo aos testes de software. Plano de contingência: Selecionar novos engenheiros de testes. Pessoa responsável: Amilton José Status: Realizando pesquisas Risco: 05 Prob: 60% Impacto: Crítico Descrição: Número de clientes que utilizam o software Estratégia de redução: Iniciar testes de stress para avaliar o desempenho e identificar os limites de utilização do software. Plano de contingência: Aumentar o número de servidores dedicados ao produto e realizar acompanhamento diário do desempenho do produto. Pessoa responsável: Amilton José Status: Implementando testes de peformance Risco: 06 Prob: 50% Impacto: Crítico Descrição: Custo com o atraso da entrega do produto Estratégia de redução: Acompanhamento intesivo do desenvolvimento do projeto e suas atividades. Plano de contingência: Parcerias com empresas de desenvolvimento terceirizada. Pessoa responsável: Amilton José Status: O acompanhamento das atividades de desenvolvimento foram iniciados. Risco: 07 Prob: 50% Impacto: Crítico Descrição: Novos métodos de engenharia de software Estratégia de redução: Treinar a equipe de desenvolvimento com as versões mais atuais para desenvolvimento. Plano de contingência: Renegociar data de entrega do produto. Pessoa responsável: Marcus Côrtes Status: Treinamento realizado. Risco: 08 Prob: 50% Impacto: Crítico Descrição: Contratação de pessoas com habilidades Estratégia de redução: Realizar um seleção rigorosa durante a contração do envolvidos no desenvolvimento do projeto. Plano de contingência: Contratar novos desenvolvedores habilitados.
  19. 19. 19 Pessoa responsável: Marcus Côrtes Status: Seleção realizada Risco: 09 Prob: 20% Impacto: Moderado Descrição: Interface para usuário específico Estratégia de redução: Desenvolver interface desde do inicío do projeto para despositivos móveis e respeitando regras de usabilidade e acessibilidade. Plano de contingência: Contratar uma equipe tercerizada focada em desenvolvimento acessivel. Pessoa responsável: Marcus Côrtes Status: Desenvolviemento iniciado pela própria equipe Tabela 7: Planos de redução de riscos Na Tabela 7 estão apresentados os planos de redução de riscos do projeto. São apresentados os riscos ao processo de desenvolvimento, à segurança, implementação do sistema e qualidade. 4. PLANEJAMENTO TEMPORAL Nesta seção, apresentam-se as tarefas e as suas dependências de forma a estimar a duração total do projeto. Por toda a secção, deverão ser apresentadas as saídas (gráficos, relatórios, etc.) da ferramenta de apoio utilizada na Gestão do Projeto (MS Project, etc.). Portanto, explorem bastante a ferramenta automatizada para a gestão de projecto que a sua equipa está utilizando. 4.1. DIAGRAMA DE GANTT Aqui são apresentados o modelo de processo escolhido e as suas atividades e tarefas que foram escolhidas para serem apresentadas nesta secção. O diagrama de gantt é responsável pela organização de cada atividade. Visto que as tarefas estão associadas a um ou mais elementos do projeto. Na Ilustração 1, está o diagrama de gantt para o projeto do sistema para escola de línguas.
  20. 20. 20
  21. 21. 21 Ilustração 1: Cronograma A do Projeto
  22. 22. 22 Ilustração 2: Cronograma B do Projeto
  23. 23. 23 Ilustração 3: Cronograma C do Projeto
  24. 24. 24 Ilustração 4: Cronograma D do Projeto
  25. 25. 25 5. ORGANIZAÇÃO DO PESSOAL A equipe do projeto segue um processo democrático, pois acredita que assim o projeto terá mais resultados, as decisões são tomadas em conjunto e em consenso de todos os envolvidos, onde há comunicação. Sendo assim acabamos tendo um ambiente melhor e satisfatório para trabalhar. 5.1. ESTRUTURA DA EQUIPE A tabela a seguir mostra como a equipe é formada, por três membros, onde no início dos trabalhos foram definidos claramente as funções de cada um, sendo: Nome Email Papéis Amilton Azevedo amilton_a2@hotmail.com Engenheiro de Software, Desenvolvedor e Analista de Qualidade Pedro Felipe pedroo_felipe@hotmail.com Engenheiro de Software, Desenvolvedor e Arquiteto Marcus Côrtes Marcus_cortes@hotmail.com Gerente de Projetos e Analista de Sistemas Tabela 8: Estrutura da Equipe Na Tabela 8 são apresentados a estrutura da equipe com os membros envolvidos no projeto, contato de email e o papel que cada um. A tabela abaixo mostra a descrição das atividades que são utilizadas e executadas pelos membros da equipe Papel Descrição Gerente de Projetos Responsável pelo Planejamento e acompanhamento das atividades. Aloca recursos, dimensiona tarefas e interage com o cliente.
  26. 26. 26 Analista de Sistemas Realiza o levantamento e análise de requisitos do software. Engenheiro de Software Responsável pelo desenvolvimento do projeto e pelo design da aplicação. Analista de Qualidade Identifica e gerencia iniciativas de melhoria da qualidade no âmbito organizacional, apoia a gerência em atividades de controle de projetos de captação de recursos e eventos; adota e mantém normas de qualidade da organização. Arquiteto de Software O arquiteto conhece diversas tecnologias e possui uma vasta experiência em projetos. Terá um grau de responsabilidade em definir qual a melhor solução para um certo problema na empresa. Tabela 9: Descrição das Atividades Na Tabela 9 são apresentados a descrição das atividades do envolvidos no projeto. Dividido por: Gerente de Projetos; Analista de Sistemas; Engenheiro de Software; Analista de Qualidade e Arquiteto de Software. 5.2. MECANISMOS DE COMUNICAÇÃO O processo de comunicação foi feito através de ferramentas de mensagens instantaneas e Emails como: WhatsApp, Skype, Email, Google Docs e Dropbox. O acompanhamento do projeto ocorrerá semanalmente de forma presencial com todos os membros da equipe, de forma a discurtir e criar soluções para o andamento do projeto, resolver problemas em conjunto e distribuir as tarefas. 5.3. USO DO EDU-BLOG COMO FERRAMENTA DE APOIO O Edu-blog foi uma ótima ferramenta de grande utilidade para o aprendizado e a organização do projeto. Permitiu uma comunicação do professor e o alunos muito
  27. 27. 27 satisfatória, pois o professor disponibilizava o conteúdo referente a disciplina e realizava atividades nas aulas. A ideia do Edu-blog é levar aos membros aprendizado, concepção de ideias, organização e satisfação de parte de todos os membros da equipe. 6. QUALIDADE A equipe fez uso dos itens a seguir durante todo o projeto de forma a garantir e controlar a qualidade do produto de software: Gestão do Projeto de Software – É realizado um acompanhamento constante das atividades desenvolvidas por parte de todos os envolvidos no projeto. Revisões Técnicas Formais – As revisões são realizadas por pessoas capacitadas durante todo o ciclo, visando à identificação de erros nas fases iniciais do projeto, onde o custo para a manutenção é menor. Gestão de Configuração do Software – Existe um controle a cada versão do software e dos documentos gerados, visando à integridade de ambos ao longo do seu ciclo de vida. Métricas de Quantidade – São realizadas medições para verificar o quanto o software atende aos requisitos impostos pelo usuário/cliente. Análise de Riscos – Identificação, análise e controle dos riscos, elaborando-se planos de redução e de contingência. Testes – São realizados testes dentro de um processo definido, com o objetivo de identificar possíveis erros antes que estes se transformem em defeitos e tornem-se riscos, trazendo prejuízos para a empresa.
  28. 28. 28 7. REFERÊNCIAS Nascimento, R. P. (27 de Outubro de 2010). Edu - Blog > Engenharia de Software :: PROCC. Acesso em 8 de Abril de 2014, disponível em http://pt.scribd.com/doc/40267617/Modelo-Plano-Projeto-de-SW- OO Pressman, R. S. (2011). Engenharia de Software - Uma Abordagem Profissional (7ª ed.). Porto Alegre: AMGH. Pressman, R. S. (s.d.). R.S. Pressman & Associates, Inc. Acesso em 4 de Abril de 2014, disponível em http://www.rspa.com/docs/Projectplan.html SCRUM.ORG, Scrum, disponível em http://scrum.org. Acesso em: 14 abril 2014 WIKIPEDIA, Scrum (development), disponível em: http://en.wikipedia.org/wiki/Scrum_(development) Acesso em: 14 abril 2014

×