Trabalho final(25 03 2013)
Upcoming SlideShare
Loading in...5
×
 

Trabalho final(25 03 2013)

on

  • 447 views

Trabalho final de Gerencia de Projetos - Turma de Sistemas de informação UFAM ministrada pelo Prof Rogério Patricio - 2013

Trabalho final de Gerencia de Projetos - Turma de Sistemas de informação UFAM ministrada pelo Prof Rogério Patricio - 2013

Statistics

Views

Total Views
447
Views on SlideShare
292
Embed Views
155

Actions

Likes
0
Downloads
0
Comments
0

8 Embeds 155

http://fp-ufam2012.blogspot.com.br 123
http://fp-ufam2012.blogspot.ru 19
http://fp-ufam2012.blogspot.com 8
http://fp-ufam2012.blogspot.co.at 1
http://fp-ufam2012.blogspot.pt 1
http://fp-ufam2012.blogspot.com.ar 1
http://fp-ufam2012.blogspot.it 1
http://fp-ufam2012.blogspot.se 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Trabalho final(25 03 2013) Trabalho final(25 03 2013) Document Transcript

  • UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAÇÃO PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SWAugusto Rozendo Ribeiro de Arruda – 20901910 Denise Maciel Sena - 21000963 Diana Santos Lemos - 21001000 MANAUS 2013
  • UNIVERSIDADE FEDERAL DO AMAZONAS INSTITUTO DE COMPUTAÇÃOAugusto Rozendo Ribeiro de Arruda – 20901910 Denise Maciel Sena - 21000963 Diana Santos Lemos - 21001000 Trabalho apresentado para graduação em sistemas de informação, com o tema “PLANO DO PROJETO DE SOFTWARE OO PARA PRODUTOS DA LACERTAE SW” para obtenção de nota parcial na disciplina IEC921 - GERENCIA DE PROJETOS, ministrada pelo Prof.Rogerio Patricio Chagas do Nascimento. MANAUS 2013
  • Índice1. INTRODUÇÃO ............................................................................................................................................ 4 1.1 ÂMBITO DO PROJETO ......................................................................................................................... 4 1.2 FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE .......................................................................... 4 1.3 REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE .................................................................. 5 1.4 GESTÃO E RESTRIÇÕES TÉCNICAS.................................................................................................... 62. ESTIMATIVAS DO PROJETO.................................................................................................................. 8 2.1 DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMATIVAS ......................................................................... 8 2.2 TÉCNICAS DE ESTIMAÇÃO E RESULTADOS............................................................................................... 8 2.2.1 TÉCNICA DE ESTIMATIVAS..................................................................................................................... 8 2.3 RESULTADOS ........................................................................................................................................... 9 2.4 RECURSOS DO PROJETO ....................................................................................................................... 11 2.4.1 RECURSOS HUMANOS ........................................................................................................................ 11 2.4.2 RECURSOS DE SOFTWARE ................................................................................................................. 11 2.4.3 RECURSOS DE HARDWARE ................................................................................................................ 123.0 ANÁLISE E GESTÃO DE RISCOS ..................................................................................................... 13 3.1 RISCOS DO PROJETO ............................................................................................................................. 13 3.2 AVALIAÇÃO GLOBAL DOS RISCOS .......................................................................................................... 14 3.3 TABELA DE RISCOS ................................................................................................................................ 15 3.4 REDUÇÃO E GESTÃO DO RISCO ............................................................................................................ 164.0 PLANEJAMENTO TEMPORAL ........................................................................................................... 20 4.1 CONJUNTO DE TAREFAS DO PROJETO .................................................................................................. 20 4.2 DIAGRAMA DE GANTT ............................................................................................................................ 21 4.3 COMPARATIVO DE PLANEJAMENTO........................................................................................................ 215.0 ORGANIZAÇÃO DO PESSOAL .......................................................................................................... 22 5.1 ESTRUTURA DA EQUIPE ......................................................................................................................... 22 5.2 MECANISMOS DE COMUNICAÇÃO ........................................................................................................... 23 5.3 USO DO EDU-BLOG COMO FERRAMENTA DE APOIO .............................................................................. 246.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DOPRODUTO DE SW ........................................................................................................................................ 26ANEXO 1 – DIAGRAMA DE CLASSES A................................................................................................ 29ANEXO 2 - DIAGRAMA DE CLASSES B................................................................................................. 30ANEXO 3 – DIAGRAMA DE GANNT ........................................................................................................ 31
  • 1. Introdução1.1 Âmbito do Projeto O Sistema de Gerenciamento de Projetos de Pesquisa e Desenvolvimento tempor objetivo auxiliar a secretaria e os professores autorizadosque atuarão comocoordenadoresno gerenciamento de projetos atrelados ao Instituto de Computação daUniversidade Federal do Amazonas. O Sistema permite ao usuário administrar asdespesas pertencentes às rubricas de um determinado projeto, realizando ainda umserviço de upload de documentos importantes para consultas futuras, como notasfiscais, documentos de propostas de projeto, editais, etc, além de ter a funcionalidadede gerar relatórios das movimentações realizadas no projeto.1.2 Funções principais do produto de software As principais funcionalidades do Sistema de Controle de Projetos de Pesquisa eDesenvolvimento são: ● Cadastrar Unidade de Fomento ● Editar Unidade de Fomento ● Excluir Unidade de Fomento ● Pesquisar Unidade de Fomento ● Cadastrar Projetos ● Editar Projetos ● Excluir Projetos ● Pesquisar Projetos ● Cadastrar Rubricas ● Editar Rubricas ● Excluir Rubricas ● Pesquisar Rubricas 4
  • ● Consulta de saldo por Rubrica ● Registrar Datas (Início, Término, Prestação de Contas). ● Solicitar/ Registrar Gastos ● Gerar Relatórios Detalhados/Simplificados de Rubricas ● Movimentar Saldo de Rubricas O sistema deve permitir as seguintes funcionalidades para os usuários dosistema:Secretaria ● Gerenciamento das Unidades de Fomento ● Gerenciamento dos Projetos ● Gerenciamento de Rubricas ● Conceder acesso a CoordenadoresCoordenador ● Consultar as rubricas do projeto ● Manipular dados do projeto quando autorizado1.3 Requisitos comportamentais ou de performance ● Disponibilidade: ○ Rodará durante 24hs por dia, sete dias por semana. ● Segurança: ○ O sistema não deve permitir acesso por usuários não autorizados. ○ Senhas devidamente criptografadas e especificas por usuários. ● Portabilidade: ○ O sistema deve ser executado em plataformas Linux e Windows, XP ou superior. ○ O sistema deve ser compatível com os browsers Mozilla Firefox e Google Chrome. 5
  • ● Eficiência: ○ Em condições normais, o sistema deve responder a qualquer requisição no máximo em 3 segundos. ○ Em condições de pico de uso, o sistema deve responder a qualquer requisição no máximo em 6 segundos. ● Integridade: ○ O sistema deverá exibir os dados de um projeto somente para seus respectivos coordenadores e secretaria. ○ Um coordenador só poderá manipular um projeto relacionado a ele. ○ Somente a secretaria e o coordenador mediante autorização poderão manipular dados de projetos. ○ Somente a secretaria poderá gerenciar projetos de todos os coordenadores. ● Usabilidade: ○ Interface simples: o sistema exibe uma barra de menu contendo todas as funcionalidades disponíveis ao usuário. ○ Interface amigável e de fácil manuseio pelo usuário, processos são bem descritos.1.4 Gestão e Restrições Técnicas As restrições encontradas na descrição do sistema que poderão limitar o escopopodem ser: ● O produto deve ser implementado como uma aplicação web e portável a várias plataformas; ● O produto deve ser implementado na linguagem de programação PHP, HTML utilizando o Framework Joomla; ● O produto deve utilizar Banco de Dados Mysql; ● Datas de entrega inflexíveis, pois o processo de desenvolvimento ágil (SCRUM) exige uma apresentação em datas previamente estipuladas; 6
  • ● Falta de experiência prática com as ferramentas e métodos utilizados para o desenvolvimento.● Falta de capacitação técnica da equipe, sendo necessário um treinamento específico para alguns componentes da equipe com ferramentas que serão utilizadas; 7
  • 2. ESTIMATIVAS DO PROJETO Estimativa é avisão de um resultado que não podemos dizer que é correto e nemexato, é, contudo, um resultado aproximado. As estimativas são importantes, poisproporcionarão ao gestor uma maior percepção da duração totaldo projeto. Naestimativa serão efetuados os cálculos necessários para determinar o tempo de cadafase do projeto, usando a metodologia SCRUM.2.1 Dados históricos utilizados para as estimativas Dentre muitos projetos desenvolvidos pela equipe, este é o pioneiro, no qualocálculo para estimativa da duração total do projeto se apresenta em dias. Destaca-secomo dado relevante a equipe ser composta por acadêmicos inexperientes na área deGestão de Projetos.2.2 Técnicas de estimação e resultados Para encontrar o tempo, será necessário aplicar uma técnica de estimativa.Neste caso iremos utilizar a métrica adotada pela Lacertae Software, Lorenz & Kidd(orientada a classes). 2.2.1 Técnica de estimativas Para o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento foiutilizado à técnica de estimativa Lorenz & Kidd definida pela Lacertae Software. Trata-sede uma métrica orientada a classes, que consiste em: 1 Determinar a quantidade de classes chaves do projeto. 8
  • 2 Encontrar o número de classes de suporte, identificando o tipo de interface do produto e usando o multiplicador correspondente para calcular o número declasses de suporte. 3 Multiplicar a quantidade de Classes-chave pelo valor Multiplicador, obtendo o número de Classes de suporte; 4 Cálculo da quantidade total de classes (Classes-chave + Classes de suporte); 5 Multiplicar o total de classes pelo número médio de unidades de trabalho (dias- pessoa); 6 Determinar a quantidade de esforço estimada; 7 Cálculo do tempo previsto para a realização do projeto. Abaixo, a tabela apresenta os fatores de multiplicação utilizados para encontrar aquantidade de classes de suporte: INTERFACE VALOR MULTIPLICADORInterface Valor multiplicador Não gráfica 2Baseada em texto 2,25GUI 2,5GUI Complexa 32.3 Resultados Com a aplicação da métrica de Lorenz & Kidd definida pela Lacertae Software,os seguintes resultados foram obtidos: 9
  • 1 O número de classes chaves do projeto foram escolhidas através dos diagramas de classes apresentados nos anexos 1 e 2. 2 Como o projeto é um sistema para ambiente WEB, utilizará interface GUI complexa, dessa forma o fator multiplicador serão 3. 3 O número de classes de suporte pode ser encontrado a partir do número de classes chave x multiplicador, dessa forma, 4 x 3 = 12 classes de suporte. 4 O total de classes do projeto será número de classes chave + número de classes de suporte, onde 4 + 12 = 16 classes. 5 Pelo fato da equipe não possuir experiência em projetos deste gênero e a quantidade de classes serem baixas, foi escolhido o número mínimo de unidades de trabalho por pessoa, 15 dias-pessoa. 6 O cálculo do esforço estimado ficou da seguinte forma: 16 classes x 15 dias- pessoa, onde 240 dias de trabalho. 7 Considerando 3 pessoas envolvidas no projeto e 22 dias úteis de trabalho por mês => 240/3 = 80 dias, aproximadamente 3,3 meses. Considerando que os dias de trabalho totais são 240 dias, esses dias agora sãodistribuídos de acordo com as seguintes percentagens de distribuição dos componentesessenciais no projeto, sugeridas pela Lacertae Software:1) Planejamento: 2-3%2) Análise e Projeto: 20%3) Geração de Código: 40%4) Testes: 37-38% Os valores calculados são:1) Planejamento: 420 * 3% = 7,2 dias de trabalho2) Análise e Projeto: 420 * 20% = 48 dias de trabalho3) Geração de código: 420 * 40% = 96 dias de trabalho4) Testes: 420 * 37% = 88,8 dias de trabalho 10
  • 2.4 Recursos do projeto Os recursos que serão utilizados no desenvolvimento do projeto serão descritosabaixo de acordo com a metodologia, tecnologias e ambiente disponível. 2.4.1 Recursos Humanos De acordo com a metodologia ágil, onde as funções mudam conforme as sprints,o projeto de Gerenciamento de Projetos de Pesquisa e Desenvolvimento contará comquatro pessoas, sendo três de desenvolvimento/teste e um de gerenciamento, queexercerão diferentespapéis necessários à execução, conforme descrito abaixo:Sprint 1 Sprint 2Período: 07/01 à 23/01 Período: 28/01 à 20/02Scrum Master: Augusto Arruda Scrum Master: Darlison OsórioDeveloper 1: Darlison Osório Developer 1: Denise SenaDeveloper 2: Diana Lemos Developer 2: Augusto ArrudaTester: Denise Sena Tester: Diana LemosSprint 3 Sprint 4Período: 25/02 à 13/03 Período: 18/03 à 03/04Scrum Master: Denise Sena Scrum Master: Diana LemosDeveloper 1: Diana Lemos Developer 1: Augusto ArrudaDeveloper 2: Darlison Osório Developer 2: Denise SenaTester: Augusto Arruda Tester: Darlison Obs.. O testador não deve testar o seu próprio programa, mas ele deve testar ode outro programador. 2.4.2 Recursos de Software O projeto irá usufruir dos seguintes softwares para composição do produtodesoftware, além do projeto de gerência de produção: 11
  • Xampp – Composto do módulo Apache e MySQL, responsável pelo serviço detransação de dados para a Web e gerenciamento da base de dados do software.NetBeans 7.2.1 e Notepad ++ v6.2.2 – IDE a ser utilizada na implementação doproduto de software final.PHP – Linguagem de programação a ser utilizada para o desenvolvimento do softwarefinal.Joomla 2.5 – É CMS para gerenciamento de conteúdo no qual será gerado umcomponente que gerenciará os projetos de Pesquisa e Desenvolvimento no site doInstituto de Computação - IComp.OpenOffice e Microsoft Word – Editores de texto usados na documentação, relatóriose documentos afins.MSProject – Software gerenciador de projetos que servirá de base para gestãoatualizada e confiável do projeto do produto. 2.4.3 Recursos de Hardware Para documentação, implementação e gestão do projeto de software, nossosrecursos iniciais de hardware estão agrupados em três notebooks. 12
  • 3.0 ANÁLISE E GESTÃO DE RISCOS Esta análise consiste em uma série de passos que permitem compreender egerir os riscos incertos que podem ocorrer no projeto. Desta forma, os riscos foramidentificados, avaliados quanto à probabilidade de ocorrência e estimados segundo oseu impacto no projeto de software para administrá-los corretamente.3.1 Riscos do projeto Os riscos do projeto que foram identificados que precisam ser monitoradosdurante o projeto são:Risco Projeto Técnico Negócio Comum EspecialEquipamento indisponível xRequisitos Incompletos e x x xRegras de Negócios nãodefinidasRequisitos em constante xmudançasUso de metodologias x xespeciaisFalta experiência com as xtecnologias específicas e aequipe não obtertreinamento adequado 13
  • Falha na integração com os x xdemais sistemasRotatividade da Equipe xMembro se ausentar do x xprojeto3.2 Avaliação global dos riscos ● O Gestor de Software dá suporte ao projeto? ○ Sim, pois o gestor é um dos participantes direto que possui muito conhecimento adquirido sobre o projeto. ● Os Clientes estão entusiasmados com o projeto e o produto? ○ O cliente e usuários estão entusiasmados para adquirir o produto final e contribuem para o desenvolvimento do projeto. ● Os Engenheiros de Software compreenderam bem os requisitos? ○ Sim, todos sabem o que o sistema deve conter através dos requisitos descritos inicialmente, porém a ocorrência de mudanças no decorrer de cada interação será constante. ● Os Clientes estiveram envolvidos na definição dos requisitos? ○ Sim, houve a elicitação dos requisitos com o cliente por meio de umareunião inicial e foram esclarecidos serviços que o sistema deve realizar ● O âmbito do projeto é estável? ○ Sim, o âmbito do nosso projeto não foi alterado. ● Os engenheiros de Software têm as competências requeridas? ○ Os engenheiros de Software não possuem capacidade e competência necessária para a elaboração deste projeto, no entanto, deverão ser treinados para apresentar melhores resultados. ● Os requisitos do projeto são estáveis? 14
  • ○ Não, os requisitos não são estáveis, pois haverá mudançasno decorrer do projeto. ● A equipe de desenvolvimento tem experiência na tecnologia a implementar? ○ Não, a equipe não possui conhecimentos nas tecnologias especificadas. ● É adequado o número de pessoas da equipe de trabalho? ○ Não, é um trabalho extenso para um número reduzido de pessoas o que levará a um esforço complementar de cada um.3.3 Tabela de riscos Conforme os riscos identificados, abaixo serão apresentados a sua probabilidadede ocorrência e impacto esperado no projeto.Nº Risco Probabilidade Impacto Requisitos em constantes 1 90% Catastrófico mudanças. Falta de Experiência na 2 80% Catastrófico Metodologia de Desenvolvimento 3 Prazo de entrega não sercumprido. 50% Catastrófico 4 Uso de novas tecnologias. 50% Catastrófico Membros trabalhando em partes do 5 80% Crítico tempo. Membro se ausentar ou abandonar 6 60% Crítico o projeto. Dúvidas sobre a implementação de 7 30% Marginal requisitos do sistema. 15
  • 3.4 Redução e Gestão do Risco Para garantir as estratégias de redução, supervisão e gestão dos riscos (RSGR)identificados, estão descrito abaixo os principais:1. Requisitos e constantes mudançasProbabilidade: 90% Impacto: CatastróficoDescrição:Mudanças constantes no escopo inicial do projeto podem atrasar o projetodevido ao replanejamento das atividades necessárias para adequar o projeto aosnovos requisitosEstratégia de redução: Realizar reuniões periódicas com o cliente para esclarecerrequisitos e regras de negócio conforme o projeto é desenvolvido .Plano de Contingência: Adequar e replanejar atividades para atender e acomodaras mudanças nos requisitos atualizando diagrama de classes gráfico de Gannt e etc.Responsável: Augusto ArrudaStatus: Em andamento2. Falta de Experiência na Metodologia de DesenvolvimentoProbabilidade: 80% Impacto: CatastróficoDescrição:Equipe não possui experiência em desenvolvimento de sistema com ametodologia SCRUM.Estratégia de redução: Realizar estudos sobre a metodologia SCRUM que foiestipulada a ser adotada pela equipe. 16
  • Plano de Contingência: Investir em treinamento na metodologia solicitada e realizarpráticas no desenvolvimento do projeto.Responsável: Augusto ArrudaStatus: Finalizada3. Prazo de entrega não ser cumpridoProbabilidade: 50% Impacto: CatastróficoDescrição: Prazo estimado do projeto (3 meses e 3 semanas, quase 4 meses) émaior que o prazo disponível para desenvolvimento do projeto (3 meses).Estratégia de redução: Realizar acompanhamento e controle do andamento doprojeto com ajuda de ferramentas e priorizar atividades que sejam mais importantespara o atendimento dos requisitos do usuário.Plano de Contingência: No caso de o prazo disponível não ser suficiente, o softwaredeverá ser entregue com as funcionalidades mais importantes de Gerenciamento deProjetos de Pesquisa e Desenvolvimento.Responsável: Augusto Arruda4. Uso de novas TecnologiasProbabilidade: 50% Impacto: CatastróficoDescrição: Todos os membros não possuem experiência na tecnologia especificadapara desenvolver o projeto.Estratégia de redução: Promover plano de estudos introdutórios da tecnologia.especificada para todos da equipe 17
  • Plano de Contingência: Investir em treinamento na tecnologia solicitada e criar umaatividade no cronograma para estudos da tecnologia e ferramentas.Responsável: Denise SenaStatus: Risco ocorreu de fato. O treinamento foi um aprendizado força bruta dasferramentas especificadas e houve pouco tempo para a equipe adquirir conhecimentonecessário para o desenvolvimento do projeto.5. Membro trabalhando em partes do tempoProbabilidade: 80% Impacto: CríticoDescrição: Alguns membros da equipe não possuem tempo integral para dedicaçãono desenvolvimento do projeto.Estratégia de redução: Planejar atividades de forma que os integrantes possamcompletá-las no prazo estimado de acordo sua disponibilidade.Plano de Contingência: Incentivar o empenho da equipe em finais de semana,feriados e folgas.Responsável: Denise SenaStatus: Risco ocorreu de fato. O Planejamento das atividades foram realizadas paraalguns membros da equipe.6. Membro se ausentar ou abandonar o projeto.Probabilidade: 60% Impacto: CríticoDescrição: Um dos integrantes da equipe está com dificuldades para estar reunido 18
  • com a equipe no desenvolvimento do projeto, há o risco deste se ausentar durante aexecução do projeto ou até mesmo abandoná-lo.Estratégia de redução: Distribuição das atividades do membro em questão para osdemais da equipe e treinamento de possíveis substitutos e sua função.Plano de Contingência: No caso do afastamento ou abandono deste membro daequipe, todas suas tarefas deverão ser redistribuídas e replanejadas em todo escopodo projeto a ser concluído.Responsável: Denise SenaStatus: Risco ocorreu de fato. Atividades do membro em questão foramredistribuídas para os demais da equipe.7. Duvidas sobre a implementação dos requisitos do sistemaProbabilidade: 30% Impacto: MarginalDescrição: Devido à equipe adotar o processo SCRUM que é uma metodologiaágil,a cada nova interação há uma série de dúvidas quanto ao que algunsrequisitosrepresentam em uma determinada parte no sistema.Estratégia de redução: Elaborar um relatório sobre os requisitos apresentados nodocumento de especificação de requisitos, abordando o que ele representará emcada parte que o mesmo será utilizado no sistema.Plano de Contingência: Realizar a consulta no Relatório elaborado sobre osrequisitos para a melhor compreensão do requisito na hora da implementação dosistema e maior interação com o usuários/clientesResponsável: Diana Lemos 19
  • 4.0 PLANEJAMENTO TEMPORAL No Planejamento Temporal são definidas as datas de execução das tarefasassim como, os responsáveis por cada uma delas através do Diagrama de Ganttelaborado pelo Scrum Master da primeira sprint de comum acordo com os demaiscomponentes da equipe.4.1 Conjunto de Tarefas do Projeto Aqui são apresentados o Modelo de Processo escolhido e as suas atividades etarefas que foram escolhidas para serem apresentadas nesta secção.Com base nos cálculos descritos na seção 2 presente no item 2.3 (Resultados), oesforço estimado para a realização do projeto é de 240 dias trabalhados, abaixo estásendo exibido o plano temporal das fases do projeto.Fase Projeto Cálculo Dias TrabalhadosPlanejamento 3% 420X3% 7,2Análise requisitos 20% 420X20% 48Geração de Código 40% 420X40% 96Testes 37% 420X37% 88,8 TOTAL 240 20
  • 4.2 Diagrama de Gantt Com o uso do diagrama de Gantt, se obtém maior detalhamento das etapas dedesenvolvimento do sistema, exibindo o tempo programado para execução de cadauma delas além de expor o desenrolar de cada uma das atividades. Para tanto o usou-se a ferramenta MsProject para a criação do Diagrama de Gantt (anexo 3).4.3 Comparativo de planejamento Baseado no que foi descrito pelo tópico 4.1 é notório que os cálculos elaboradospara desenvolvimento dosartefatos não se aplicam a realidade do projeto em questãono que tange ao tempo estimado de 240 dias. O projeto Controle de Projetos dePesquisa e Desenvolvimento, por ser tratar de um projeto acadêmico teve suas dataspreviamente definidas pelo orientador do projeto impossibilitando ultrapassar o prazoestipulado do semestre, mesmo que o projeto não seja concluído. 21
  • 5.0 ORGANIZAÇÃO DO PESSOAL Conforme a estimativa elaborada do esforço a ser empregado por cada membroda equipe para a criação do projeto e, observando os papéis definidos à organizaçãopessoal, o grupo se organiza usando comunicações das mais variadas que vai docompartilhamento de documentos, usando ferramentas online, chats, e-mail,telefonesentre outros para a integração com o cliente do projeto.5.1 Estrutura da equipe A equipe é formada por 4 integrantese o cliente do sistema. Sendo todosrelacionados com atividades que devem ser executadas para a implementação dosoftware usando modelo de desenvolvimento ÁGIL – que prima pelo planejamento daversão para entrega sendo mudadas as funções dos membros a cada interação, ouseja, a cada nova Sprint. O modelo Ágil exigirá reunião diária, a revisão das metas a cada final da sprint,analisando as tarefas e os atrasos em retrospectiva para melhoramento das metas. Ospapéis descritos são: Scrum Master, Developer 1, Developer 2 eTester, sendo oProduct Owner o Prof Dr. Arilo Dias.ScrumMaster O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindoaos valores do Scrum, às práticas e às regras, levando-o a ser mais produtivo e adesenvolver produtos de maior qualidade.Desenvolvedores Desenvolvedores são os membros com todas as habilidades necessárias paratransformar os requisitos do Product Owner em uma parte do artefato entregáveldoproduto ao final de cada Sprint. 22
  • Product Owner O Product Owner é a única pessoa responsável pelo gerenciamento do Backlogdo Produto e por garantir o valor do trabalho realizado pelo Time Scrum, garantindo queseja visível para todos da equipe.Tester ou Testador O Tester faz a integração com a equipe de análise e desenvolvimentoprocurando entender as regras de negócio, arquitetura e funcionamento das atividadesno sistema para validar o sistema.5.2 Mecanismos de comunicaçãoTime Scrum Time Srum é onde os desenvolvedores transformam o Backlog do Produto emincrementos de funcionalidades potencialmente entregáveis em cada Sprint e sãointerdisciplinares: membros do Time devem possuir todo o conhecimento necessáriopara criar um incremento no trabalho, realizados sempre ao iniciar uma nova sprint.Sprint A Sprint é uma iteração, com duração fixa, na qual tanto a composição do timequanto as metas de qualidade devem permanecer constantes durante a Sprint. AsSprints contêm e consistem na reunião de Planejamento de Sprint com todos osenvolvidos e é onde o trabalho de desenvolvimento é mais executado.Product Backlog O Procut Backlog são os requisitos do produto que o Time está desenvolvendo eestão listados no Backlog do Produto. O Product Owner é o responsável pelo Backlog.Neste houve uma interação de todos os envolvidos para terem ciência sobre todo oescopo do projeto.Redmine 23
  • Redmine é um software livre, gerenciador de projetos baseados na web eferramenta de gerenciamento de bugs. Ele contém calendário e gráficos de Gantt paraajudar na representação visual dos projetos e seus deadlines (prazos de entrega). Neleos documentos foram centrados para consulta da equipe por todos os envolvidos e paraacompanhamento de mudanças na documentação relacionado ao projeto.E-mail e Chats A comunicação da equipe se deu da seguinte forma: houve algumas reuniõespresenciais e, em frequência bem superior, houve as reuniões virtuais operadas atravésdos e-mails e chats pessoais de cada integrante da equipe, as quais ocorreramacompanhando as mudanças e evoluções do projeto.Telefone Vale ressaltar que a comunicação telefônica foirealizada para obteresclarecimentos e muitas vezes tirar algumas dúvidas sobre mudanças ou para saber oandamento do projeto.5.3 Uso do Edu-blog como ferramenta de apoio O Edu-Blog é uma excelente via para o conhecimento, pois não se limita atextos, mastambém a programas. É um espaço onde acadêmicos apreciadores da área e o público em geralpodem comentar ou criticar as postagens feitascom baseem pesquisas científicas e decotidiano, trabalhando o pesquisar, o entender e o escrever. Assim, as formas maiseficientes de comunicação, produção de textos e conhecimento de tecnologias,elencando o professor que além de orientador passa a ser também observador dostrabalhos. Tais fatos nos leva a crer que os Blogs Educacionais, em especial o Edu-blog ésem dúvida,uma ferramenta de conhecimento que provem da facilidade decomunicação dada pela praticidade e rapidez da interação da linguagem representativaque aparece no meio digital, ou seja, é usar a tecnologia para ensinar por ela própria. 24
  • Mas, toda e qualquer ideia, pode sim ser melhorada e a contribuição de nossa equipepara melhoria, está no fato de escrever sobre temas onde existe uma gama enorme deinformações e fazer isso com uma frequência, ainda que sem um retorno. Por maissimples que seja essa tarefa, acaba desmotivando o autor acadêmico do blog, pelacerteza ou não de que sua exposição está satisfazendo ou não o público alvo, paratanto a sugestão é usar outros acadêmicos de outros períodos ou professores da áreapara contribuírem com sugestõesvisitando os blogs e gerando críticas sobre eles, com amoderação feita pelo professor da disciplina. 25
  • 6.0 PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE SW Atividades de teste serão aplicadas ao final do desenvolvimento de cadafuncionalidade para assegurar que são atendidas conforme foram especificadas. Seráfeito acompanhamento contínuo do trabalho desenvolvido por todos os participantes doprojeto, aplicar-se-ão revisões técnicas, análise e controle contínuo de riscos, bemcomoserão geradas documentações do projeto e produto.Seguimento e Controle do Projeto de Software É realizado um acompanhamento constante das atividades desenvolvidas porparte de todos os envolvidos no projeto e principalmente validação com o cliente.Revisões Técnicas Formais As revisões são realizadas na etapa de Análise e Projeto, visando à identificaçãode erros nas fases iniciais do projeto, onde o custo para a manutenção é menor.Produção de Documentação Para o controle de qualidade do processo de desenvolvimento, foi elaboradadocumentação nas etapas de Especificação, Codificação e Teste em todo o processode execução do projeto. Assim descritas:1ª SprintEspecificação:Instalação de sistemas para desenvolvimento XAMP, JoomlaConfiguração e importação da base de dados ICOMPModelagem das tabelas de Banco de Dados da base ICOMPPlanning pokerCodificação:Crud coordenadorCrud Fomento 26
  • Crud despesasTeste:Criação de testes das históriasTeste dos artefatos criadosApresentação da Sprint 1 ao ProdutcOwner2ª SprintEspecificação:Reavaliação da Sprint 1Ajustes do ProdutcBacklog para sprint 2Codificação:Crud de ProjetosCrud de RubricasConsulta CoordenadoresCrud de GastosTeste:Teste dos artefatos criadosApresentação da Sprint 2 ao Produtc Owner3ª SprintEspecificação:Reavaliação da Sprint 2Ajustes do Produtc Backlog para sprint 3Codificação:Crud de Rubricas especificas do projetoRelatório dos Cruds de Rubricas e FomentoAjustes de regras de négocioTeste:Teste dos artefatos criadosApresentação da Sprint 3 ao ProdutcOwner 27
  • 4ª SprintEspecificação:Reavaliação da Sprint 3Ajustes do ProdutcBacklog para sprint 4Codificação:Crud de criação de DatasRelatório dos Cruds de Despesas e Rubricas de despesasRelatório de datas agendadasAjustes das regras de negócioTeste:Teste dos artefatos criadosApresentação da Sprint 4 ao ProdutcOwnerConclusão do Projeto e EntregaCRUD: Acrônimo de Create, Read, Update e Delete em língua Inglesa, para as quatrooperações básicas utilizadas em bancos de dados relacionais (RDBMS) ou em interfacepara usuários para criação, consulta, atualização e destruição de dados. 28
  • Anexo 1 – Diagrama de Classes A 29
  • Anexo 2 - Diagrama de Classes B 30
  • Anexo 3 – Diagrama de GANNT 31