Universidade Federal do Rio de Janeiro Escola Polit ecnica Departamento de Eletr onica e de Computa c ao

Sistema de Gerenciamento de Tarefas para usu arios de Scrum

Autor:

Andreza Cristina da Silva Orientador:

Prof. Ant onio Cl audio G omez Sousa Examinador:

Prof Sergio Palma da Justa Medeiros, D. Sc. Examinador:

Prof. Marcelo Luiz Drumond Lanza

DEL Fevereiro de 2011

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO Escola Polit ecnica - Departamento de Eletr onica e de Computa c ao Centro de Tecnologia, bloco H, sala H-217, Cidade Universit aria Rio de Janeiro - RJ CEP 21949-900

Este exemplar e de propriedade da Universidade Federal do Rio de Janeiro, que poder a inclu -lo em base de dados, armazenar em computador, microlmar ou adotar qualquer forma de arquivamento. permitida a men E c ao, reprodu ca o parcial ou integral e a transmiss ao entre bibliotecas deste trabalho, sem modica c ao de seu texto, em qualquer meio que esteja ou venha a ser xado, para pesquisa acad emica, coment arios e cita c oes, desde3 que sem nalidade comercial e que seja feita a refer encia bibliogr aca completa. Os conceitos expressos neste trabalho s ao de responsabilidade do(s) autor(es) e do(s) orientador(es).

ii

 DEDICATORIA

Dedico este Projeto de Gradua ca o a `s duas pessoas mais importantes da minha vida: meu pai e minha m ae, que zeram sacrif cios durante os 3 anos do meu ensino m edio para que eu pudesse ter a op ca o de estudar, segundo a minha opini ao, na melhor universidade do Brasil.

iii

AGRADECIMENTO

Agrade co em primeiro lugar a ` minha maravilhosa fam lia, que sempre me apoiou em quaisquer decis oes que z, mesmo achando que eu pudesse estar errada. A liberdade de escolha que voc es me deram foi fundamental pra eu me tornar a pessoa que hoje eu sou. Quanto ao amor que voc es me deram nesses 24 anos, eu n ao tenho nem palavras. M ae e Pai, obrigada por todo o apoio que voc es me deram. Kinha, obrigada por me aturar mesmo nos meus momentos de crise e estresse extremos, que n ao foram poucos nesses 5 anos Engenharia Eletr onica! Imposs vel deixar de agradecer a ` fam lia que eu escolhi pra mim: meus amigos. Sem eles eu n ao seria nada! Amigos, obrigada por tornarem o meu tempo muito mais divertido ao lado de voc es, por todas as vezes que eu precisei de voc es do meu lado e voc es estavam l a para n ao me deixar cair. N ao querendo ser redundante, mas j a sendo, gostaria e agradecer a companhia dos meus queridos amigos-colegas de pross ao, alguns que caram comigo desde o primeiro per odo at e o nal, outros que caram pelo caminho ou os que chegaram depois. Eu tenho quase certeza que se n ao fossem voc es, a miss ao de me tornar Engenheira Eletr onica e de Computa ca o seria incrivelmente mais dif cil. Obrigada ao meu orientador Ant onio Cl audio por aceitar a tarefa de me orientar neste projeto e que foi sempre t ao paciente, me dando a luz necess aria sempre que tudo parecia escuro. N ao poderia tamb em deixar de agradecer ao Professor Jos e Manoel de Seixas e ao Laborat orio de Processamento de Sinais, onde fui aluna de Inicia ca o Cient ca por quase 2 anos. Sem a experi encia adquirida no LPS e, principalmente, no CERN, eu n ao seria nem de longe a pessoa e prossional que sou. Ao coordenador do curso de Engenharia Eletr onica e de Computa c ao, Professor Carlos Jos e Ribas DAvila, vai meu agradecimento por sempre estar disposto

iv

a resolver os eventuais problemas, fossem eles causados pelo SIGA ou por maus entendidos meus. Aos Professores Sergio Palma da Justa Medeiros e Marcelo Luiz Drumond Lanza, obrigada pelos conhecimentos passados em sala de aula (sem d uvida foram alguns dos melhores cursos que z ao longos desses 5 anos) e por fazerem parte da minha banca de Projeto de Gradua c ao. Ao Professor Edson Watanabe, do Programa de Engenharia El etrica, pelo apoio que me foi dado recentemente. Agrade co tamb em a todos os professores da Escola Polit ecnica, em especial aos do DEL, que n os alunos, no desespero nosso de cada dia, nem sempre reconhecemos o valor que eles t em. J a estou com saudades de conviver com esses g enios diariamente. N ao poderia tamb em deixar de agradecer aos meus queridos companheiros de trabalho na empresa Chemtech que, desde o primeiro dia de est agio, estiveram prontos para tirar quaisquer d uvidas que eu pudesse ter, muitas vezes me oferecendo ajuda antes mesmo de eu descobrir que precisava. E tamb em por que n ao agradecer por fazer meu dias bem mais engra cados? Por m, gostaria de agradecer a incr vel diculdade do nosso curso de Engenharia Eletr onica e de Computa ca o, que nos prepara para o mundo, pois depois de passar por isso, qualquer coisa ca f acil!

RESUMO

Este trabalho apresenta a idealiza c ao, projeto e implementa c ao do iPlan, um sistema voltado para usu arios da metodologia agil Scrum, cujo principal objetivo e auxiliar no gerenciamento de tarefas necess arias ao completo desenvolvimento de um ou mais projetos. Atrav es do iPlan e poss vel cadastrar usu arios, equipes, projetos, tarefas, al em de planejar quando e por quem estas ser ao executadas, tudo isto de acordo com a framework do Scrum. Palavras-Chave: Scrum, iPlan, gerenciamento de tarefas, Engenharia de Software, Metodologia Agil

vi

ABSTRACT

This paper presents the idealization, project and implementation of iPlan, a software especially developed for users of the agile methodology Scrum, which main goal is to help managing the demanded tasks to accomplish the development of one or more projects. The software iPlan allows the register of users, teams, projects, tasks, besides planning when and by whom these will be executed, all according to the Scrum framework. Key-words: Scrum, iPlan, task management, Software Engineering, Agile Methodology

vii

SIGLAS

UFRJ - Universidade Federal do Rio de Janeiro PGPS - Plano Para o Gerenciamento de Projeto de Software ERS - Especica ca o de Requisitos de Software C#: Linguagem de programa c ao orientada a objeto da Microsoft BD: Banco de dados SGBD: Sistema de Gerenciamento de Banco de Dados
A L TEX: Ferramenta de tipograa muito apropriada para textos t ecnicos e cient cos;

MVC - Model-View-Control

viii

Sum ario
1 Introdu c ao 1.1 1.2 1.3 1.4 1.5 1.6 Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Delimita c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Justicativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Descri ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 1 2 2 2 3 5 5 6 6 7 7 9 9

2 Scrum 2.1 Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 2.1.2 2.1.3 2.2 2.3 Origem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Principais Caracter sticas . . . . . . . . . . . . . . . . . . . .

Os Valores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Funcionamento do Scrum

A Framework do Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 2.3.2 2.3.3 Pap eis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Artefatos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Reuni oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 19

3 Planejamento 3.1

Apresenta c ao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.1.1 3.1.2 Sum ario do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 19 Evolu ca o do Plano . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 3.3

Refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Deni co es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ix

3.4

Organiza c ao do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.1 3.4.2 3.4.3 Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . 22 Estrutura Interna . . . . . . . . . . . . . . . . . . . . . . . . . 22 Pap eis e Responsabilidades . . . . . . . . . . . . . . . . . . . . 22

3.5

Processos de Gerenciamento . . . . . . . . . . . . . . . . . . . . . . . 22 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 Partida do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 22 Plano de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . 24 Planos de Controle . . . . . . . . . . . . . . . . . . . . . . . . 25 Plano de Gerenciamento de Riscos . . . . . . . . . . . . . . . 26 Plano de Encerramento . . . . . . . . . . . . . . . . . . . . . . 28

3.6

Processos T ecnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 3.6.1 3.6.2 3.6.3 3.6.4 Modelo dos Processos . . . . . . . . . . . . . . . . . . . . . . . 28 M etodos, Ferramentos e T ecnicas . . . . . . . . . . . . . . . . 28 Infra-estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Plano para Aceita ca o do Produto . . . . . . . . . . . . . . . . 29

3.7

Planos para os processos de Suporte . . . . . . . . . . . . . . . . . . . 29 3.7.1 3.7.2 3.7.3 3.7.4 3.7.5 3.7.6 3.7.7 3.7.8 Gerenciamento de Congura c ao . . . . . . . . . . . . . . . . . 29 Plano de Verica c ao e de Valida ca o . . . . . . . . . . . . . . . 29 Documenta ca o . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Plano para Assegurar a Qualidade . . . . . . . . . . . . . . . . 30 Revis oes e Auditorias . . . . . . . . . . . . . . . . . . . . . . . 30 Plano para a Resolu c ao de Problemas . . . . . . . . . . . . . . 30 Gerenciamento de Subcontrata c oes . . . . . . . . . . . . . . . 31 Plano de Aperfei coamento . . . . . . . . . . . . . . . . . . . . 31

3.8

Planos Adicionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32

4 Especica c ao de Requisitos de Software 4.1

Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 Finalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Deni c oes, Acr onimos e Abreviaturas . . . . . . . . . . . . . . 33 Refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 x

4.2

Descri ca o Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 Perspectiva do Produto . . . . . . . . . . . . . . . . . . . . . . 33 Fun co es do Produto . . . . . . . . . . . . . . . . . . . . . . . 33

Caracter sticas do Usu ario . . . . . . . . . . . . . . . . . . . . 35 Restri c oes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Pressupostos e Depend encias . . . . . . . . . . . . . . . . . . . 35 Postergar Requisitos . . . . . . . . . . . . . . . . . . . . . . . 35

4.3

Requisitos Espec cos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . 36 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . 36 Requisitos de Desempenho . . . . . . . . . . . . . . . . . . . . 53 Restri c oes de Projeto . . . . . . . . . . . . . . . . . . . . . . . 53 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Outros Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 54 55

5 Descri c ao de Projeto de Software 5.1

Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.1.1 5.1.2 5.1.3 Finalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Deni c oes, Acr onimos e Abreviaturas . . . . . . . . . . . . . . 55

5.2 5.3

Refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Decomposi ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3.1 5.3.2 5.3.3 Decomposi c ao em M odulos . . . . . . . . . . . . . . . . . . . . 56 Decomposi c ao em Processos Concorrentes . . . . . . . . . . . 61 Decomposi c ao de Dados . . . . . . . . . . . . . . . . . . . . . 61

5.4

Descri ca o das Depend encias . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.1 5.4.2 5.4.3 Depend encias entre m odulos . . . . . . . . . . . . . . . . . . . 66 Depend encias entre processos . . . . . . . . . . . . . . . . . . 68 Depend encias entre dados . . . . . . . . . . . . . . . . . . . . 68

5.5 5.6

Descri ca o das Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 68 Projeto Detalhado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.6.1 5.6.2 Projeto Detalhado dos M odulos . . . . . . . . . . . . . . . . . 68 Projeto Detalhado das Entidades de Dados . . . . . . . . . . . 68 xi

6 Plano de Testes 6.1

74

Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.1.1 6.1.2 6.1.3 Identicador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Finalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Refer encias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2

Descri ca o Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Vis ao Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Suspens ao ou Conclus ao . . . . . . . . . . . . . . . . . . . . . 75 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Tarefas e Cronograma . . . . . . . . . . . . . . . . . . . . . . 76 Riscos e Gerenciamento . . . . . . . . . . . . . . . . . . . . . 76

6.3

Especica ca o dos Testes . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3.1 6.3.2 6.3.3 Especica c ao 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Especica c ao 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Especica c ao 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.4

Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 6.4.1 6.4.2 6.4.3 Caso de teste 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Caso de teste 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Caso de teste 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 88

6.5

Procedimentos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . 88 6.5.1 6.5.2 6.5.3 Procedimento 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Procedimento 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Procedimento 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 90 95

7 Manual Do Usu ario 7.1 7.2 7.3

Introdu ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Descri ca o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Utiliza ca o do iPlan . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.3.1 7.3.2 7.3.3 Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 P agina Principal . . . . . . . . . . . . . . . . . . . . . . . . . 96 Usu arios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 xii

7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 8 Conclus ao Bibliograa

Projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Grupos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Planejar Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 109 112 114

xiii

Lista de Figuras
1.1 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4 5.5 Modelo de Processos: Cascata - Linear Sequencial . . . . . . . . . . . Forma ca o Scrum no Rugby. . . . . . . . . . . . . . . . . . . . . . . . Funcionamento B asico do Scrum, por Mountain Goat Software. . . . 3 6 8

Amostra de backlog do projeto. . . . . . . . . . . . . . . . . . . . . . 11 Burndown Chart de sprint bem planejada. . . . . . . . . . . . . . . . 12 Burndown Chart de sprint subestimada. . . . . . . . . . . . . . . . . 13 Burndown Chart de sprint superestimada. . . . . . . . . . . . . . . . 13 Exemplo de um Quadro de Tarefas. . . . . . . . . . . . . . . . . . . . 14 Algumas cartas do baralho utilizado no Planning Poker. . . . . . . . 16

Equipe no momento da reuni ao di aria. . . . . . . . . . . . . . . . . . 17 Modelo Cascata Linear-Sequencial . . . . . . . . . . . . . . . . . . . . 20 Cronograma de atividades do projeto . . . . . . . . . . . . . . . . . . 21 Backlog do projeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Diagrama de Casos de Uso para Administradores do Sistema. . . . . 37

Diagrama de Casos de Uso para Product Owners. . . . . . . . . . . . 38 Diagrama de Casos de Uso para Scrum Masters. . . . . . . . . . . . . 39 Diagrama de Casos de Uso para membros da equipe desenvolvedora. . 40 Diagrama de Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Estrutura de Forms e UserControls. . . . . . . . . . . . . . . . . . . . 57 Arquitetura do M odulo de Acesso. . . . . . . . . . . . . . . . . . . . . 58 Arquitetura do M odulo de Equipe. . . . . . . . . . . . . . . . . . . . 59 Arquitetura do M odulo de Projeto. . . . . . . . . . . . . . . . . . . . 60 Arquitetura do M odulo de Backlog. . . . . . . . . . . . . . . . . . . . 61

xiv

5.6 5.7 5.8 5.9

Diagrama de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Diagrama de tarefa para incluir uma nova tarefa. . . . . . . . . . . . 69 Diagrama de sequ encia para incluir uma nova tarefa. . . . . . . . . . 70 Modelo L ogico do Banco de Dados para o iPlan. . . . . . . . . . . . . 71

5.10 Modelo F sico do Banco de Dados para o iPlan. . . . . . . . . . . . . 71 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9 P agina principal do iPlan. . . . . . . . . . . . . . . . . . . . . . . . . 96 Modulo de Usu arios. . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Usu arios listados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Formul ario para a adi ca o de novo usu ario. . . . . . . . . . . . . . . . 98 Formul ario para a edi ca o de usu ario cadastrado. . . . . . . . . . . . . 99 Procedimento necess ario para desfazer exclus ao de usu ario. . . . . . . 100 M odulo de Projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Busca de Projetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Formul ario a ser preenchido para adicionar um projeto. . . . . . . . . 102

7.10 M odulo de grupos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 7.11 Exemplo de Resultado de Busca de Grupos. . . . . . . . . . . . . . . 104 7.12 Linha em branco para adi c ao de novo grupo. . . . . . . . . . . . . . . 105 7.13 M odulo de Sprints. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 7.14 M odulo de Tarefas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 7.15 Exemplo de busca de tarefas com respectivos v nculos. . . . . . . . . 108 7.16 Adicionar Tarefa a Sprints. . . . . . . . . . . . . . . . . . . . . . . . . 109 7.17 Exemplo de tarefas planejadas para grupo e sprint exibidos. . . . . . 110 7.18 Op ca o de prioridades para que o usu ario selecione a desejada. . . . . 111

xv

Lista de Tabelas
3.1 3.2 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 Datas de in cio de m de cada sprint. . . . . . . . . . . . . . . . . . . 24 Riscos previstos para o projeto. . . . . . . . . . . . . . . . . . . . . . 27 Atributos da Classe User . . . . . . . . . . . . . . . . . . . . . . . . . 63 Atributos da Classe Group . . . . . . . . . . . . . . . . . . . . . . . . 63 Atributos da Classe Position . . . . . . . . . . . . . . . . . . . . . . . 64 Atributos da Classe Group Member . . . . . . . . . . . . . . . . . . . 64 Atributos da Classe Sprint . . . . . . . . . . . . . . . . . . . . . . . . 64 Atributos da Classe Project . . . . . . . . . . . . . . . . . . . . . . . 65 Atributos da Classe Status . . . . . . . . . . . . . . . . . . . . . . . . 65 Atributos da Classe Priority . . . . . . . . . . . . . . . . . . . . . . . 66 Atributos da Classe Eort . . . . . . . . . . . . . . . . . . . . . . . . 66

5.10 Atributos da Classe Task . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.11 Atributos da Classe Sprint Task . . . . . . . . . . . . . . . . . . . . . 67 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 Cronograma. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Entradas e Sa das Esperadas do Caso de Teste 1. . . . . . . . . . . . 85 Entradas e Sa das Esperadas do Caso de Teste 1. . . . . . . . . . . . 86 Entradas e Sa das Esperadas do Caso de Teste 1. . . . . . . . . . . . 87 Entradas e Sa das Esperadas do Caso de Teste 3. . . . . . . . . . . . 91 Entradas e Sa das Esperadas do Caso de Teste 3. . . . . . . . . . . . 92 Entradas e Sa das Esperadas do Caso de Teste 3. . . . . . . . . . . . 93 Entradas e Sa das Esperadas do Caso de Teste 3. . . . . . . . . . . . 94

xvi

Cap tulo 1 Introdu c ao

1.1 Tema

O tema do trabalho e o desenvolvimento de um sistema gerenciador de tarefas do Scrum, uma metodoloia agil para o gerenciamento de projetos. Pretende-se desenvolver um sistema que auxilie os membros de uma equipe a planejar e acompanhar as tarefas a serem desenvolvidas, o momento em que come car ao a ser executadas, o prazo em que elas devem ser implementadas e o esfor co utilizado por cada membro da equipe em sua execu c ao.

1.2

Delimita c ao

O objeto de estudo e o gerenciamento das atividades a serem realizadas no desenvolvimento de um software quando h a utiliza ca o do Scrum. Neste sentido o sistema desenvolvido dever a permitir ao usu ario cadastrar tarefas a serem realizadas durante a elabora ca o de um produto, associ a-las ao esfor co gasto para sua implementa c ao, ao ciclo em que dever a ser realizada, sua atual situa c ao, ou seja, deve fornecer ao primeiro um meio de gerenciar o desenvolvimento de eu produto.

1.3

Justicativa

Por ser f acil de ser compreendido, n ao necessitar de treinamentos extensos e aprensentar produtividade maior, quando se comparado a m etodos tradicionais, o uso do Scrum vem crescendo bastante como metodologia empregada no desenvolvimento de software dentro de empresas. Al em disso o emprego do Scrum acaba por unir a equipe em torno de um objetivo comum, no caso o desenvolvimento de um produto. Contudo, para ser realmente eciente, e preciso que as atividades que ser ao realizadas a cada sprint ao longo do desenvolvimento do produto nal, sejam bem planejadas, que as devidas prioridades sejam atribu das, e respeitadas, de forma que haja um desenvolvimento gradual coerente, para que ao m de cada sprint um novo produto (parcial) possa ser lan cado. Atualmente as tarefas de um projeto que utiliza Scrum s ao geralmente gerenciadas utilizando planilhas de Excel ou similar, o que diculta o compartilhamento de informa co es pela equipe, al em de tais planilhas n ao serem otimizadas para o uso do Scrum. Nesse sentido, o presente projeto representa um software livre para gerenciamento de tarefas para projetos que utilizam esta metodologia.

1.4

Objetivos

O objetivo geral e desenvolver um sistema que possa armazenar as atividades a serem realizadas ao longo de um projeto, relacion a-las a `s sprints, para assim auxiliar o scrum master a planejar, acompanhar, analisar as tarefas realizadas no desenvolvimento de um sistema.

1.5

Metodologia

No desenvolvimento do software, ser a utilizado o modelo de processos em cascata, como mostrado na gura 1.1. A cada etapa do modelo ser ao geradas documenta co es tais como planejamento, especica c ao de requisitos, diagrama de casos de uso, diagrama de classe e plano de testes. 2

Figura 1.1: Modelo de Processos: Cascata - Linear Sequencial

A linguagem utilizada na codica c ao ser a C# e a programa c ao, orientada a objeto. Devido a isso, a an alise utilizada ser a a An alise Orientada a Objetos. J a para o armazenamento de dados, ser a feito em um banco de dados relacional, e ser a utilizado SQL Server.

1.6

Descri c ao

No cap tulo 2 ser a feita uma breve introdu ca o sobre a metodologia a gil Scrum, onde ser ao apresentados ao leitor suas principais caracter sticas, artefatos, origem e foco principal. Em seguida, no ca putlo 3, ser a apresentado o planejamento realizado para que o sistema pudesse ser desenvolvido. Neste, ser ao apresentados o cronograma detalhado do projeto, medidas de gerenciamento de risco, entre outros. Os requisitos denidos para o software s ao apresentados no cap tulo 4. Nele constar ao os diagramas de casos de uso para cada grupo de usu ario, bem como os casos de uso detalhados e o diagrama de classes. Um maior detalhamento do projeto ser a especicado no cap tulo 5, onde constar ao seu modelo de banco de dados, arquitetura de cada m odulo denido, as classes reais e seus principais m etodos.

No cap tulo seguinte, ser ao abordados os testes planejados para validar o que foi desenvolvido. Em seguida est ao detalhadas todas as funcionalidades e sua respectivas interfaces, no manual do usu ario, para auxiliar o usu ario na utiliza ca o do sistema. Por m, o trabalho e conclu do no cap tulo 8, onde s ao abordados os resultados atingidos com seu desenvolvimento, sua import ancia na utiliza ca o do Scrum e os planos para o futuro.

Cap tulo 2 Scrum

2.1 Introdu c ao

Scrum e uma metodologia a gil geralmente, por em n ao exclusivamente, utilizada para o desenvolvimento de software. Devido a ` atual frequente mudan ca de requisitos de projetos e exig encia de entrega em curtos prazos, faz-se cada vez mais necess aria a utiliza ca o de processos a geis de desenvolvimento. Neste sentido, o Scrum tem como princ pios [1]: Criar um ambiente favor avel a mudan cas de requisitos, mesmo durante o desenvolvimento do produto e, consequentemente proporcionar entregas mais r apidas do produto ao cliente Refor car o planejamento constante do projeto, evitando portanto riscos Priorizar ao m aximo a satisfa c ao do cliente Conforme j a citado, apesar de ser bastante utilizado no desenvolvimento de software, o Scrum pode ser utilizado em qualquer situa ca o em que pessoas necessitem trabalhar em equipe, desde grandes projetos de engenharia a ` organiza ca o de pequenos eventos.

2.1.1

Origem

Originalmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabrica ca o de autom oveis e produtos de consumos, por Takeuchi e Nonaka [2], que notaram que melhores resultados eram obtidos ao utilizar equipes menores e multidisciplinares. Desta percep ca o surgiu o nome Scrum, uma analogia com a forma c ao Scrum do jogo de Rugby1 , quando os jogadores de ambos os times de uma partida se unem para recolocar a bola em jogo. Nesse momento, oito jogadores de cada equipe posicionam-se uns contra os outros, conforme mostra a gura 2.1. Ap os um jogador da equipe que n ao cometeu a penalidade lan car a bola no espa co entre os jogadores, estes devem tentar, com os p es, recuperar a bola tendo, assim, que trabalhar em equipe para alcan car um objetivo comum [3].

Figura 2.1: Forma c ao Scrum no Rugby.

2.1.2

Principais Caracter sticas

Mais do que uma metodologia, Scrum e uma framework, o que faz com que boa parte das decis oes de como executar tarefas ou resolver problemas que a crit erio
1

Esporte coletivo de intenso contato sico semelhante ao futebol, praticado com uma bola oval,

cujo objetivo e marcar o maior n umero de pontos

da equipe desenvolvedora, j a que geralmente esta sabe melhor como lidar com os problemas que est a enfrentando. Com isso, e poss vel notar uma das caracter sticas mais fortes no uso do Scrum, que e a exist encia de uma equipe autogerenci avel. Como veremos adiante, apesar de existerem pap eis pre-denidos na equipe, esta deve ser disciplinada e multidisciplinar, n ao necessitando de um l der. Um bom diferencial em rela c ao ao m etodo tradicional de desenvolvimento e o r apido progresso do produto gerado, pois uma nova vers ao, contendo novas funcionalidades a cada ciclo. Ainda, deve ser destacada a quantidade de reuni oes no Scrum. H a quatro tipos de reuni oes que devem acontecer de tempos em tempos, sendo elas: reuni ao di aria, reuni ao de planejamento de sprint, reuni ao de revis ao de sprint e reuni ao de sprint. Cada uma dessas ser a abordada mais adiante.

2.1.3

Os Valores

Segundo [4], os principais valores das metedologias a geis devem ser: Indiv duos e intera c oes ao inv es de processos e ferramentas Software funcional ao inv es de uma documenta ca o abrangente Participa c ao do cliente ao inv es de uma negocia ca o por contrato Adapta ca o a mudan cas ao inv es de seguir um plano

2.2

Funcionamento do Scrum
Antes de entrar em detalhes sobre o funcionamento do Scrum e necess ario

denir o que e uma sprint. Sprints s ao itera c oes de per odos de tempo, com dura ca o aproximada de duas a, no m aximo, quatro semanas. Durante esse tempo, uma nova vers ao do produto desenvolvido e idealizada, implementada e testada. 7

Para um bom funcionamento do Scrum, conhecimento da capacidade da equipe e melhor planejamento de tarefas, e aconselh avel que as sprints tenham dura ca o xa para cada equipe. Tendo isso denido, podemos ent ao dizer que, basicamente, o Scrum funciona da seguinte forma: todas as tarefas necess arias para o desenvolvimento de um produto cam armazenadas e devidamente priorizadas num reposit orio chamado Product Backlog, ou Backlog do Produto. no in cio de cada sprint e realizada uma reuni ao, na qual a equipe seleciona as tarefas do Backlog do Produto que ser ao executadas da sprint que se inicia, formando o Sprint Backlog, ou Backlog da Sprint. todos os dias os membros da equipe devem atualizar uns aos outros sobre as tarefas em execu c ao, de modo que todos estejam sempre cientes do que cada um est a fazendo ao nal de cada sprint uma nova vers ao do produto e lan cada e enviada ao cliente. A gura 2.2 ilustra o que foi descrito acima.

Figura 2.2: Funcionamento B asico do Scrum, por Mountain Goat Software.

2.3

A Framework do Scrum

De acordo com [5], a framework do Scrum e composta essencialmente por pap eis, reuni oes e artefatos que ser ao denidos e detalhados a seguir.

2.3.1

Pap eis

Apesar de n ao ter fun co es espec cas para cada membro integante da equipe, h a tr es pap eis pre-denidos. 2.3.1.1 Product Owner

O Product Owner, ou Dono do Produto, e o respons avel por denir o produto a ser desenvolvido e a data em que deve estar pronto, al em de cuidar da lucrabilidade daquele. O Product Owner pode ser o cliente ou um membro da equipe com amplo conhecimento do que e desejado pelo primeiro. A ele cabe a tarefa de priorizar todas tarefas de acordo com seu valor de mercado, bem como alterar requisitos e prioridades, caso necess ario, a cada sprint. Por m, e o Product Owner que aceita ou rejeita o que foi produzido. 2.3.1.2 ScrumMaster

O ScrumMaster e a gura que mais se aproxima do l der em uma equipe de Scrum. dele a tarefa de garantir que os princ E pios e valores do Scrum sejam seguidos, al em de eliminar poss veis impedimentos e proteger a equipe de interfer encias externas, lidando ele pr oprio com os problemas, garantindo assim que a equipe desenvolvedora esteja totalmente funcional e produtiva. 2.3.1.3 Equipe Desenvolvedora

a respons aconselh E avel por desenvolver o produto a ser entregue. E avel que as equipes desenvolvedoras n ao sejam muito grandes, contendo geralmente de cinco a nove pessoas, de diferentes a reas (programadores, testadores, designers, ...).

Como citado anteriormente, deve ser autogerenci avel, o que, neste caso, signica que os pr oprios membros selecionam as tarefas a serem executadas durante uma sprint e cada um tem a liberdade de escolher aquilo que vai fazer, dentre as tarefas selecionadas. Com raras exce c oes (no caso de administradores de banco de dados, por exemplo), os membros desta equipe n ao devem dividir seu tempo com outras equipes e, a m de evitar complica c oes no decorrer das sprints, e desej avel que n ao haja mudan ca de membros no decorrer das mesmas.

2.3.2
2.3.2.1

Artefatos
Backlog do Produto

O Backlog do Produto, ou Product Backlog e essencialmente um resposit orio onde todas as tarefas necess arias ao completo desenvolvimento do produto cam armazenadas. Diferentemente do m etodo tradicional, no Scrum geralmente todos os pr e-requisitos do produto n ao s ao denidos quando o projeto se inicia. O que costuma acontecer e o armazenamento do maior n umero de tarefas poss veis para que o projeto possa ao menos ser iniciado e no decorrer do projeto, mais tarefas v ao sendo adicionadas ou at e mesmo removidas, conforme a demanda. As tarefas armazenadas no backlog podem ser de diferentes naturezas, tanto t ecnicas, quanto relativas a ` coordena ca o, suporte, etc. A maneira com que aquele vai ser organizado cabe exclusivamente ao seu criador. As tarefas contidas no backlog do produto devem estar priorizadas de acordo com seus respectivos valores de mercado ou sua necessidade ao bom desenvolvimento do projeto. Com isso, as tarefas mais importantes s ao realizadas antes das demais tarefas. Devido a isso, e natural que com o passar do tempo, algumas tarefas, antes menos priorit arias, tornem-se desnecess arias, e n ao h a nenhum mal em retir a-las do backlog, ao passo que novas tarefas podem se fazer urgentes, sendo executadas antes de muitas tarefas j a constantes no backlog. 10

A gura 2.3 respresenta uma amostra de backlog do produto, retirada do site Mountain Goat Software [7].

Figura 2.3: Amostra de backlog do projeto.

2.3.2.2

Backlog da Sprint

O backlog da sprint nada mais e que as tarefas do backlog do produto selecionadas para serem executadas em uma sprint. Como ser a mais detalhado mais adiante, a cada sprint s ao selecionadas as tarefas mais importantes para serem executadas, de modo que a equipe consiga nalizar sua implementa ca o ao nal do tempo determinado. Como mencionado em [1] e em [5], e importante que as tarefas e cada sprint n ao sejam atribu das aos integrantes da equipe, e sim que cada um escolha aquelas que deseja executar, facilitando assim a motiva ca o da equipe por desenvolver o trabalho.

11

No decorrer da sprint, o backlog da mesma vai sendo atualizado pelo ScrumMaster, atrav es da sinaliza c ao, de algum modo de que a tarefa foi conclu da e de quanto falta para que isto ocorra. Para auxiliar esse acompanhamento, podem ser usados os artefatos abaixo descritos: o Burndown Chart e o Task Board. 2.3.2.3 Burndown Chart

O burndown chart e simplesmente um gr aco, gerado manualmente ou atrav es de algum software que pode ser utilizado tanto para acompnhamento de uma sprint (Sprint Burndown Chart ) quanto para o acompanhamento do desenvolvimento do produto nal (Release Burndown Chart ). No Burndown Chart e representada a uma linha de refer encia e a uma outra, que representa a realidade. Na gura 2.4 temos o exemplo de um burndown chart de uma sprint de 10 dias bem planejada, j a que as linhas seguem bem pr oximas uma da outra.

Figura 2.4: Burndown Chart de sprint bem planejada.

J a as guras 2.5 e 2.6 representam gr acos de sprints, tamb em de 10 dias, mal planejadas. Como e poss vel observar, no gr aco da gura 2.5, as tarefas do sprint backlog foram subestimadas, fazendo com que seus executores levassem um tempo superior para desenvolv e-las do que aquele que foi planejado. O resultado e o t ermino da sprint sem o t ermino do desenvolvimento das tarefas planejadas. 12

Figura 2.5: Burndown Chart de sprint subestimada. J a o gr aco da gura 2.6, mostra o acompanhamento de uma sprint cujas tarefas foram superestimadas. Neste caso, os membros da equipe levaram um tempo bem inferior no desenvolvimento das tarefas, fazendo com que estas fossem nalizadas antes do t ermino da sprint.

Figura 2.6: Burndown Chart de sprint superestimada.

2.3.2.4

Task Board

O Task Board, ou Quadro de Tarefas e um quadro onde s ao representadas as tarefas de uma sprint e sua situa ca o no momento, conforme representado na gura bastante u 2.7. E til para ter uma clara e r apida ideia das tarefas que devem ser desenvolvidas e das que j a fora terminadas.

13

Figura 2.7: Exemplo de um Quadro de Tarefas. Cada equipe deve montar o seu quadro de tarefas com as colunas que achar necess arias, mas em geral s ao representadas as seguintes situa co es: Story - Breve descri c ao da necessidade do usu ario do sistema To Do - Breve descri c ao das tarefas que ainda n ao come caram a ser executadas, contendo tamb em o esfor co estimado para execut a-las e, possivelmente, um identicador do integrante que as desenvolver ao Doing - Breve descri c ao das tarefas que est ao sendo desenvolvidas no momento, tamb em contendo o esfor co restante para naliz a-las e um identifcador do integrante que as est ao executando Done - Breve descri c ao das tarefas que j a foram executadas, contendo o esfor co total utilizado para naliz a-las e um identicador do membro que as executou. O quadro de tarefas e utilizado atrav es da transfer encia das tarefas atrav es das colunas, conforme a atual situa c ao de cada uma delas. Em geral, essa transfer encia e feita durante a reuni ao di aria, que ser a melhor descrita mais adiante. 14

Os quadros de tarefas podem ser feitos tamb em da maneira que a equipe julgar conveniente, sendo bastante comum sua constru ca o utilizando um cartaz e post-its contendo as stories e as descri c oes das tarefas.

2.3.3
2.3.3.1

Reuni oes
Reuni ao de Planejamento de Sprint

A reuni ao de planejamento de sprint deve acontecer a todo in cio de sprint e e divida em duas etapas. Na primeira parte da reuni ao, devem estar presentes a equipe do Scrum, o Product Owner e quem mais for pertinente, como o cliente com alto conhecimento dos requisitos e suas prioridades. Durante esta etapa, as tarefas do Product Backlog s ao brevemente descritas e o cliente ou Product Owner prioriza cada uma delas. Dependendo do tamanho do Product Backlog, n ao e necess ario descrever cada uma das atividades, mas apenas as mais priorit arias e que possivelmente preenchem uma sprint. Ao passar pelas tarefas, os membros da equipe podem interagir com o Product Owner e dar opini oes sobre as depend encias t ecnicas entre as tarefas e possibilidade de algumas delas serem desenvolvidas em alguma outra sprint, ao inv es de na sprint que se inicia. Todos os presentes, ent ao denem um objetivo para ser realizado no pr oximo ciclo, como o fechamento de um conjunto de novas funcionalidades. Ap os essa parte, todos que n ao fazem parte da equipe do Scrum, inclusive o Product Owner se retiram e a primeira decide que tarefas realmente selecionar para o Sprint Backlog, com base naquilo que foi discutido anteriormente e na diculdades das tarefas a serem executadas. Para auxiliar no bom planejamento sprint, principalmente no que diz respeito a ` quantidade de tarefas a serem selecionadas, existe uma t ecnica chamada Planning

15

Poker [9]. O Planning Poker consiste no uso de cartas de baralho especiais, conforme ilustrado na gura 2.8, para estimar o esfor co gasto para realizar cada tarefa. O funcionamento e bem simples e intuitivo. Ap os serem denidas todas as atividades, os membros da equipe as selecionam, uma a uma, e cada membro escolhe, secretamente, uma carta que representa o esfor co que ele acha que aquela tarefa demanda. Havendo discord ancia entre as pessoas, cada um levanta seus argumentos, e chegado a um consenso e denido o esfor co para realizar cada uma das tarefas.

Figura 2.8: Algumas cartas do baralho utilizado no Planning Poker.

v E alido aqui comentar que o modo mais comum de representar o esfor co de um tarefa e atrav es de n umeros, como os da sequ encia de Fibonacci, ou a mesma adaptada, cujos valores s ao 1, 2, 3, 5, 8, 13, 20, 40, 60 e 100. Entretanto, h a tamb em equipes que usam outros meios para quantizar suas tarefas, como animais, sendo uma formiga, por exemplo atribuido a tarefas mais f aceis, enquanto o touro, a `s mais dif ceis. Neste projeto consideraremos a sequ encia de Fibonacci adaptada para o Scrum. Ainda, e desej avel que as tarefas n ao sejam muito grandes, ou seja, n ao exijam mais do que 16 horas para serem terminadas. Caso haja tarefas grandes, o melhor a fazer e dividi-las, at e que existam tarefas, cujo tempo de desenvolvimento seja menor que o previamente dito.

16

Tendo ent ao denidos os esfor cos para cada tarefa, e feita uma estimativa do esfor co total que a equipe pode gastar durante toda a sprint. Este valor s o pode ser estimado pelos pr oprios integrantes da equipe, levando em considera ca o as compet encias de cada um do grupo, o tempo de trabalho, a concentra c ao de cada um. Este valor total do esfor co de todos da equipe e chamado de Sprint Velocity. Dizemos que o Sprint Backlog est a planejado e a reuni ao encerrada quando a soma das tarefas selecionadas e igual a ` Sprint Velocity. importante ressaltar que E e fundamental que os integrantes da equipe sejam realistas ao planejarem cada Sprint, n ao selecionando tarefas a mais ou a menos que a equipe e capaz de executar. Um bom planejamento, e essencial para o bom funcionamento do Scrum. 2.3.3.2 Reuni ao Di aria

Para acompanhar o andamento da sprint, todos os dias deve ser feita um reui ao di aria, tamb em conhecida como Daily Scrum, ou Scrum Di ario, onde os integrantes da equipe se reunem por no m aximo 15 minutos e falam o que j a zeram, o que far ao e se houve ou se h a a possibilidade de haver algum impedimento.

Figura 2.9: Equipe no momento da reuni ao di aria.

Quaisquer problemas levantados nesse momento devem ser discutidos posteriormente, de prefer encia com o ScrumMaster, j a que ele e o encarregado de eliminar os obst aculos existentes.

17

2.3.3.3

Reuni ao de Revis ao de Sprint

Ao nal de cada sprint e feita uma reuni ao entre os membros da equipe, Product Owner, clientes e quem mais for convidado. Esta reuni ao deve ser bastante informal, n ao deve usar slides e nem demorar mais do que duas horas para ser preparada. Deve ser uma simples exibi c ao dos resultados obtidos no ciclo que se encerrou, basicamente atrav es da apresenta c ao de uma demonstra ca o do produto ou nova vers ao deste landa cada. 2.3.3.4 Reuni ao de Restrospectiva de Sprint

Tamb em ao nal da sprint e feita uma breve reuni ao, que deve demorar em torno de 15 a 30 minutos para avaliar o que foi bom e o que fui ruim, o que funcionou para o grupo no ciclo encerrado e o que pode ser melhorado no futuro. Deste reuni ao participam toda a equipe, incluindo o Product Owner e, talvez os clientes. essencial que n E ao haja tarefas executadas em uma sprint al em das que foram planejadas, por em na pr atica, observamos que no decorrer de um ciclo, certas tarefas podem perder ou ganhar prioridade. Portanto, e fundamental um bom acompanhamento das tarefas por parte do ScrumMaster para que tais mudan cas sejam evitas ao m aximo, por em caso sejam inevt aveis, a atitude certa seja tomada.

18

Cap tulo 3 Planejamento

3.1
3.1.1
3.1.1.1

Apresenta c ao
Sum ario do Projeto
Finalidades, Escopo e Objetivos

O presente projeto consiste de um software que ir a permitir o registro de atividades, sua visualiza ca o e manipula c ao, de forma a permitir um eciente gerenciamento de sprints por parte de Scrum Masters. 3.1.1.2 Postulados e Restri co es

O software em desenvolvimento n ao conta com restri co es de or camento ou tecnologia, visto que as ferramentas que ser ao utilizadas j a foram adquiridas e suas licen cas foram obtidas gratuitamente atrav es do Programa MSDN Academic Alliance [11]. Contudo, existe restri c ao de tempo de densenvolvimento, j a que o projeto deve ser nalizado at e Dezembro de 2010. 3.1.1.3 Libera c oes Parciais

Neste projeto, ser a seguido o modelo cascata linear-sequencial, ilustrado na gura 3.1, no qual primeiramente e feito o planejamento e em seguida, s ao abordados an alise, desenho, codica ca o e integra c ao do projeto. Os produtos liberados seguir ao o seguinte planjamento:

19

Figura 3.1: Modelo Cascata Linear-Sequencial Planejamento para o Gerenciamento de Projeto de Software Especica co es de Requisitos de Software Descri ca o de Projeto de Software Plano de Testes Manual de Usu ario Vers ao alfa do sistema Documenta ca o Total 3.1.1.4 Sum ario de Cronograma e Or camento

A gura 3.2 representa o cronograma a ser seguido para o desenvolvimento do projeto. Como j a mencionado anteriormente, n ao h a or camento programado para este projeto.

3.1.2

Evolu c ao do Plano

O PGPS ser a analisado pelo orientador deste projeto e caso seja necess aria alguma altera ca o, o primeiro ser a refeito e posteriormente entregue ao professor, como uma nova vers ao. Ainda, se, durante o processo de desenvolvimento for notada alguma necessidade de altera ca o do produto ou de alguma especica ca o, o PGPS tamb em 20

Figura 3.2: Cronograma de atividades do projeto ser a refeito. Esse procedimento ser a repetido quantas vezes forem necess arias, at e que o PGPS seja totalmente aprovado.

3.2

Refer encias

As refer encias bibliogr acas encontram-se no nal deste documento.

3.3

Deni co es

Visual Studio: Pacote de programas da Microsoft para desenvolvimento de softwares; SQL Server: SGBD da Microsoft, que ser a utilizado no presente projeto;

21

3.4
3.4.1

Organiza c ao do Projeto
Interfaces Externas

O projeto a ser desenvolvido foi proposto como Projeto de Gradua ca o do curso de Engenharia Eletr onica e de Computa c ao da UFRJ e ser a orientado pelo professor Ant onio Cl audio. A comunica ca o entre a aluna e o orientador ser a feita em reuni oes a cada 15 dias e via email sempre que necess ario.

3.4.2

Estrutura Interna

O projeto ser a desenvolvido pela aluna Andreza Cristina da Silva, autora deste documento, que ser a respons avel por todas as tarefas propostas. O controle de qualidade ser a feito por seu orientador, Ant onio Cl audio, atrav es das reuni oes realizadas no decorrer da execu ca o do projeto.

3.4.3

Pap eis e Responsabilidades

Como dito anteriormente, a respons avel pela execu c ao de todas as tarefas necess arias para o desenvolvimento do projeto proposto e a aluna Andreza Cristina da Silva.

3.5
3.5.1
3.5.1.1

Processos de Gerenciamento
Partida do Projeto
Previs oes

No desenvolvimento do projeto ser a utilizada a metodologia agil Scrum, portanto foi feito um backlog com as atividades a serem executadas. Caso, durante a execu ca o do projeto, surjam novas atividades, essas ser ao adicionadas ao backlog referido e ser a realizado um novo planejamento, levando-se em

22

considera ca o a prioridade, o esfor co das atividades pendentes e o prazo nal de entrega. O backlog inicial do projeto pode ser visualizado na gura 3.3 e as datas em que ser ao iniciadas e nalizadas as sprints podem ser vistas na tabela 3.1.

Figura 3.3: Backlog do projeto.

3.5.1.2

Equipe

Como citado no item Interfaces Internas, a equipe e composta apenas por uma pessoa, que possui conhecimento avan cado da linguagem de programa ca o C#, utiliza ca o do software Visual Studio e SQL Server, ferramentas essas que ser ao utilizadas no desenvolvimento do projeto. 3.5.1.3 Plano para a Aquisi c ao de Recursos

Como todos os recursos necess arios j a est ao dispon veis, este item n ao se aplica a esse projeto. 23

Sprint 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

In cio 19/Maio 26/Maio 9/Junho 23/Junho 7/Julho 21/Julho 4/Agosto 18/Agosto 1/Setembro 15/Setembro 29/Setembro 13/Outubro 27/Outubro 10/Novembro 24/Novembro 8/Dezembro

Fim 25/Maio 8/Junho 22/Junho 6/Julho 20/Julho 3/Agosto 17Agosto 31/Agosto 14/Setembro 28/Setembro 12/Outubro 26/Outubro 9/Novembro 23/Novembro 7/Dezembro 22/Dezembro

Tabela 3.1: Datas de in cio de m de cada sprint. 3.5.1.4 Plano de Treinamento da Equipe

Como mencionado no item Equipe, as ferramentas que ser ao utilizadas j a s ao familiares ` a equipe, portanto, n ao ser a necess ario trein a-la. Quaisquer diculdades n ao planejadas ser ao solucionadas atrav es de consultas a ` internet e da ajuda do orientador.

3.5.2
3.5.2.1

Plano de Trabalho
Atividades

As atividades desenvolvidas nesse projeto est ao especicadas na gura 3.2.

24

3.5.2.2

Prazos

Os prazos para a realiza c ao das tarefas do projeto encontram-se na gura 3.3 e na tabela 3.1. 3.5.2.3 Aloca c ao de Recursos

Todos os recursos necess arios para o desenvolvimento do projeto j a foram devidamente adquiridos, portanto n ao se faz neces aria a aloca ca o de recursos. 3.5.2.4 Aloca c ao de Or camento

Como n ao h a necessidade de compra de material ou pagamento de m ao-de-obra, esse item n ao se aplica a este projeto.

3.5.3
3.5.3.1

Planos de Controle
Controle de Requisistos

Ao dar in cio ao desenvolvimento do projeto, caso haja requisitos que sejam invi aveis a ` realiza ca o da proposta, os requisitos inicialmente propostos, especicados no documento ERS ser ao revistos e alterados de forma que viabilizem a realiza ca o do projeto. Ao ser feito isso, uma nova vers ao da ERS ser a feita e as atividades do backlog do projeto, planejadas novamente. 3.5.3.2 Controle de Prazos

Como j a mencionado, ser a utilizada a metodologia Scrum no desenvolvimento do sistema. Com isso, ao nal de cada sprint ser ao vistas as atividades que foram conclu das e, caso haja atividades n ao nalizadas no tempo previsto, ser a realizado um novo planejamento das sprints seguintes, para que o prazo nal seja atendido. 3.5.3.3 Controle de Or camento

Como j a citado anteriormente, n ao h a custo para o desenvolvimento da proposta feita, portanto n ao e necess ario o controle de or camento.

25

3.5.3.4

Controle de Qualidade

O controle de qualidade ser a feito atrav es das reuni oes com o orientador do projeto, realizadas a cada duas semanas. Caso este julgue necess ario, ser ao realizadas altera co es no material j a elaborado. 3.5.3.5 Plano de Relat orios

Caso se fa ca necess ario, ser ao emitidos relat orios para serem apresentados nas reuni oes quinzenais entre a equipe e o orientador do projeto. 3.5.3.6 Plano de Medidas

A principal medida tomada ser a o esfor co para cada tarefa ser realizada. O esfor co estimado para a realiza c ao de cada tarefa est a representado na gura 3.3. A cada tarefa conclu da, ser a adicionado ao backlog do projeto o esfor co real para realiz a-la e, caso necess ario, ser ao analisadas as causas entre a poss vel diferen ca entre os esfor cos planejado e real.

3.5.4

Plano de Gerenciamento de Riscos

Os riscos previstos est ao relacionados na tabela 3.2. RMMM1 Monitoramento: Acompanhamento das atividades desenvolvidas atrav es do burndown chart e avan co no backlog Pol tica Pr o-ativa: Planejamento de cada sprint de forma que que a equipe n ao que sobrecarregada nem com menos atividades que o necess ario Pol tica Reativa: Novo planejamento das sprints seguintes RMMM2 Monitoramento: Manter backups virtuais e em disco.

26

Risco Entrega do prazo Falta de capacita ca o ou fora

Categoria Equipe

Probabilidade 20%

Impacto Catastr oco

RMMM RMMM1

Equipe

10%

Cr tico

experi encia da equipe Perda de documentos Mudan ca requisitos Uso de ferramentas inadequadas Falta de experi encia equipe Complexidade do sistema Tabela 3.2: Riscos previstos para o projeto. Pol tica Pr o-ativa: Manter backups virtuais e em disco a cada nova vers ao feita de arquivos fonte e de documentos gerados. Pol tica Reativa: Resgatar a u ltima vers ao em backup, antes de ocorrer o problema de perdas. RMMM3 Monitoramento: Verica c ao de complexidade do sistema ao realizar an alise e tamb em projeto de software. Pol tica Pr o-ativa: Tentar utilizar o m aximo de funcionalidades j a existentes e utlizar os conhecimentos de Engenharia de Software. Pol tica Reativa: Reduzir os requisitos inicialmente propostos, para adeTecnol ogica 30% Cr tico RMMM3 da Equipe 10% Cr tico Equipe 10% Marginal de Cliente/Equipe 40% Marginal Tecnol ogica 20% Catastr oco RMMM2

27

quar a complexidade do projeto ao tempo dispon vel para sua realiza ca o.

3.5.5

Plano de Encerramento

A maior parte da documenta ca o do projeto ser a elaborada durante o per odo de desenvolvimento, sendo esta apresentada ao orientador conforme planejado. A documenta ca o restante, ser a elaborada ap os a elabora c ao do sistema. Ap os o completo desenvolvimento do sistema e sua documenta c ao, esta ser a entregue a ` banca avaliadora, que assistir a uma apresenta ca o sobre o projeto e o julgar a.

3.6
3.6.1

Processos T ecnicos
Modelo dos Processos

Como dito anteriormente, neste projeto ser a usado o Modelo Cascata - Linear Sequencial, representado na gura 3.1. As libera co es parciais foram mencionadas no item Libera co es Parciaise o marcos est ao estabelecidos como o m de cada sprint, cujas datas podem ser observadas na tabela 3.1.

3.6.2

M etodos, Ferramentos e T ecnicas

A Para gerar toda a documenta ca o ser a utilizado L TEX.

As linguagens de programa ca o utilizadas ser ao C#, para a codica ca o da aplica c ao e SQL para o banco de dados. Para tais, ser a feito o uso dos softwares Microsoft Visual Studio e SQL Server, respectivamente. Como a linguagem escolhida e orientada a objeto, ser a feita a An alise Orientada a Objeto. Caso fa ca-se necess ario o uso de mais ferramentas estas ser ao escolhidas ao decorrer do desenvolvimento do projeto.

28

3.6.3

Infra-estrutura

O ambiente de desenvolvimento ser a Windows Vista e os computadores utilizados no processo ser ao de uso pessoal. As lincen cas eventuais necess arias, ser ao adquiridas atrav es do programa MSDN Academic Alliance, como ateriormente mencionado. Toda a documenta ca o gerada estar a no padr ao ABNT [12].

3.6.4

Plano para Aceita c ao do Produto

Para avaliar se as funcionalidades do sistema est ao de acordo com seus requisitos, ser ao realizados os testes previstos no Plano de Testes. Al em disso, ser ao feitas reuni oes peri odicas com o orientador do projeto, que homologar a o funcionamento do sistema.

3.7
3.7.1

Planos para os processos de Suporte

Gerenciamento de Congura c ao

Como, nesse projeto, a equipe e formada por apenas 1 (uma) pessoa, o controle de vers oes n ao se faz t ao necess ario. Ao inv es de utilizar softwares para controlar vers oes, ser ao feitos backups em disco e de forma eletr onica a cada documento gerado e/ou funcionalidade implementada.

3.7.2

Plano de Verica c ao e de Valida c ao

Como j a mencionado, para vericar o funcionamento do projeto, ser ao realizados os testes contidos no Plano de Testes, que ser a entregue ao orientador antes de o in cio da codica ca o do sistema.

3.7.3

Documenta c ao

Como documenta ca o n ao liber avel, est ao as mensagens de e-mail trocadas entre a aluna e seu orientador, assim como as vers oes parciais dos documentos a serem

29

entregues. Como documenta ca o liber avel est ao o presente documento, a ERS, o Plano de Testes, a Descri c ao de Projeto de Software e a documenta ca o exigida para a avalia c ao do projeto. A elabora c ao dos documentos ser a de responsabilidade da aluna, enquanto a avalia ca o destes ser a de responsabilidade de seu orientador durante o desenvolvimento do projeto e da banca avaliadora, no momento de sua defesa.

3.7.4

Plano para Assegurar a Qualidade

Durante a elabora c ao dos documentos ser ao feitas revis oes por parte da aluna antes de sua entrega ao professor. Este u ltimo far a a verica ca o nal, assegurando a qualidade dos produtos desenvolvidos. Analogamente, no processo de desenvolvimento ser ao feitas avalia co es e testes das funcionalidades at e ent ao terminadas, vericando se est ao de acordo com o previsto. Durante as reuni oes quinzenais com o professor, este tamb em vericar ao funcionamento do sistema.

3.7.5

Revis oes e Auditorias

O revisor nal de toda a documenta c ao elaborada e o projeto desenvolvido ser a o orientador do projeto. O produto lhe ser a entregue (em forma de papel no caso da documenta ca o e por meio eletr onico, do sistema) nas reuni oes quinzenais e eventualmente por correio eletr onico, quando for necess ario. Caso novas vers oes do produto desenvolvido forem necess arias, o processo se repetir a at e que aquele seja aceito.

3.7.6

Plano para a Resolu c ao de Problemas

Caso algum problema previsto no item Plano de Gerenciamento de Riscos ocorra, ser ao tomas as medidas previstas para tentar solucion a-lo.

30

Para problemas de diculdade relevante n ao previstos, ser ao discutidas algumas poss veis solu c oes nas reuni oes realizadas entre a aluna e seu orientador.

3.7.7

Gerenciamento de Subcontrata co es

Como nesse projeto n ao ser a realzado nenhum tipo de contrata ca o, esse item n ao se aplica.

3.7.8

Plano de Aperfei coamento

Durante as reuni oes de in cio/m de sprint, ser a avaliado se as ferramentas utilizadas no desenvolvimento do projeto s ao realmente as mais indicadas, j a que o tempo dispon vel para a realiza c ao deste e um fator cr tico. Caso necess ario e vi avel, ser a realizada nova escolha de ferramentas.

3.8

Planos Adicionais

Ainda n ao existe nenhum plano adcional para esse projeto.

31

Cap tulo 4 Especica c ao de Requisitos de Software

4.1
4.1.1

Introdu c ao
Finalidade

Esta ERS tem como nalidade permitir o entendimento de como ser a feito o sistema, al em de estruturar o projeto para facilitar o desenvolvimento do mesmo. Este documento e dirigido ao orientador Ant onio Cl audio G omez Sousa e a ` banca examinadora do projeto.

4.1.2

Escopo

O iPlan e um sistema de gerenciamento de tarefas para Usu arios de Scrum e tem por objetivo facilitar o planejamento de tarefas de um projeto a serem executadas por usu arios da metodologia a gil Scrum. Atrav es do iPlan, Product Owners poder ao gerenciar diferentes projetos e os grupos que os executar ao, Scrum Masters ser ao capazes adicionar tarefas a serem desenvoldidas em seus respectivos projetos, al em de planejar quando estas dever ao ser executadas.

32

Ainda, membros da equipe desenvolvedora poder ao observar o planejamento feito pelos Scrum Masters. O sistema ser a desenvolvido de forma a ser acessado via web, por em sua execu ca o se dar a localmente (atrav es do download da aplica ca o) pelos usu arios, que compartilhar ao um mesmo servidor de banco de dados.

4.1.3

Deni co es, Acr onimos e Abreviaturas

As deni co es necess arias encontram-se no in cio desta documenta c ao.

4.1.4

Refer encias

As refer encias bibliogr acas encontram-se no nal deste documento.

4.1.5

Resumo

Esta ERS mostra com detalhes o funcionamento do iPlan. Suas depend encias e requisitos ser ao especicadas, assim como suas funcionalidades, esclarecidas atrav es dos diagramas de casos de uso e das especica c oes de cada caso. Nesse documento tamb em e apresentado o diagrama de classes. Informa co es adicionais sobre o funcionamento do iPlan constar ao no Manual do Usu ario e na Descri c ao de Projeto de Software.

4.2
4.2.1

Descri c ao Geral
Perspectiva do Produto

O sistema a ser desenvolvido e independente de qualquer outro sistema.

4.2.2

Fun c oes do Produto

Usu arios Inclus ao

33

 Edi ca o Exclus ao Visualiza ca o Grupos de usu arios Inclus ao Edi ca o Exclus ao Visualiza ca o Inser ca o de integrantes Projetos Inclus ao Edi ca o Exclus ao Visualiza ca o Sprints Inclus ao Edi ca o Exclus ao Visualiza ca o Tarefas Inclus ao Inclus ao de tarefa lha Edi ca o Exclus ao Visualiza ca o

34

 Filtro por diferentes par ametros Login e Logout de usu arios

4.2.3

Caracter sticas do Usu ario

O iPlan e destinado a equipes que utilizam o Scrum como forma de organiza ca o e gerenciamento do projeto, principalmente aos Scrum Masters. Portanto, os usu arios previstos s ao pessoas com idade entre 18 a 65 anos, n ao importando o g enero. O tempo de dura ca o de uso do software depende da dura c ao do projeto desenvolvido pelos usu arios.

4.2.4

Restri co es

A u nica restri ca o ao uso do sistema e a utiliza c ao de Windows como sistema operacional.

4.2.5

Pressupostos e Depend encias

O software desenvolvido ser a compat vel apenas com sistema operacional Windows. Para que dados sejam salvos e acessados ser a criado um banco de dados no momento da instala ca o do sistema e acessado sempre que necess ario. Tendo em vista que o sistema desenvolvido ter a interface amig avel e utiliza c ao intuitiva, os demais pressupostos desse projeto s ao a utiliza ca o de um banco de dados u nico atrav es de uma rede por parte dos usu arios e a leitura do Manual do Usu ario, que ser a liberado juntamente com a vers ao alfa do sistema.

4.2.6

Postergar Requisitos

Duas desej aveis funcionalidades futuras do sistema s ao a possibilidade de o usu ario adicionar mais dados em tarefase a exporta ca o dos dados observados para arquivos de formato .xls ou .pdf, por exemplo.

35

4.3
4.3.1
4.3.1.1

Requisitos Espec cos

Interfaces Externas
Interfaces dos Usu arios

A interface com os usu arios se dar a atrav es de uma aplica c ao executada localmente, por em cujo acesso ser a feito atrav es da WEB. Um maior detalhamento da interface com usu arios pode ser encontrado no Manual do Usu ario. 4.3.1.2 Interfaces de Hardware

Como o sistema desenvolvido n ao se comunica com hardwares, n ao haver a interfaces de hardware. 4.3.1.3 Interfaces de Software

Como esse sistema n ao se comunica com nenhum outro software, n ao haver a interfaces de software. 4.3.1.4 Interfaces de Comunica c ao

Como ser a utilizado um banco de dados concentrado, o software ter a como interface de comunica ca o a WEB.

4.3.2

Requisitos Funcionais

Casos de Uso Os diagramas de casos de uso s ao ilustrados nas guras 4.1, 4.2, 4.3 e 4.4, de acordo com o grupo de usu ario. A especica c ao de cada caso e feita a seguir:

Listar Usu arios Ator: Administrador, Product Owner, Scrum Master, Membro Equipe 36

Figura 4.1: Diagrama de Casos de Uso para Administradores do Sistema. Pr e-condi co es: Estar autenticado pelo sistema Casos de Uso associados: Incluir Usu ario, Editar Dados de Usu ario Cadastrado, Excluir Usu ario P os-condi co es: NA Fluxo Principal: 1. Usu ario acessa a tela relativa a usu arios 2. Sistema lista na tela os usu arios cadastrados Fluxo Alternativo: 3a. Usu ario ordena usu arios listados por nome, nome de usu ario ou email Incluir Usu ario 37

Figura 4.2: Diagrama de Casos de Uso para Product Owners. Ator: Administrador Pr e-condi co es: Estar autenticado pelo sistema e ter listado usu arios Casos de Uso associados: Listar Usu arios P os-condi co es: Haver a mais um usu ario cadastrado no sistema Fluxo Principal: 1. Usu ario seleciona op c ao de incluir usu ario 2. Sistema exibe um formul ario 3. Usu ario preenche as informa co es do novo usu ario e solicita o armazenamento dos dados 4. Sistema exibe informa ca o conrmando inclus ao do usu ario Fluxo Alternativo:

38

Figura 4.3: Diagrama de Casos de Uso para Scrum Masters. 4a. Sistema exibe mensagem de erro caso alguma informa c ao n ao esteja correta ou haja campos obrigat orios n ao preenchidos 5a. Retorna ao Fluxo Principal Editar Informa co es de Usu ario Cadastrado Ator: Administrador Pr e-condi co es: Estar autenticado pelo sistema, ter listado usu arios e haver pelo menos um usu ario cadastrado no sistema Casos de Uso associados: Listar Usu arios P os-condi co es: Os dados de um usu ario cadastrado no sistema ser ao alterados 39

Figura 4.4: Diagrama de Casos de Uso para membros da equipe desenvolvedora. Fluxo Principal: 1. Usu ario seleciona um usu ario previamente cadastrado no sistema 2. Usu ario seleciona op c ao de edi ca o de dados 3. Sistema exibe um formul ario com informa co es cadastradas preenchidas 4. Usu ario altera as informa co es desejadas 5. Sistema exibe informa ca o conrmando edi ca o de dados do usu ario Fluxo Alternativo: 5a. Sistema exibe mensagem de erro caso alguma informa c ao n ao esteja correta 6a. Retorna ao Fluxo Principal 5b. Sistema exibe mensagem informando que n ao h a dados para serem alterados 6b. Retorna ao Fluxo Principal Excluir Usu arios Ator: Administrador Pr e-condi co es: Estar autenticado pelo sistema, ter listado usu arios e existir ao 40

menos 1 (um) usu ario, al em do pr oprio, cadastrado no sistema Casos de Uso associados: Listar Usu arios P os-condi co es: Os usu arios selecionados ser ao exclu dos logicamente do sistema Fluxo Principal: 1. Usu ario seleciona um ou mais usu arios dentre os listados 2. Usu ario seleciona op c ao para excluir o(s) usu ario(s) selecionado(s) 3. Sistema exibe informa ca o conrmando a exclus ao do usu ario Listar Projetos Ator: Administrador, Product Owner, Scrum Master, Membro Equipe Pr e-condi co es: Estar autenticado pelo sistema Casos de Uso associados: Incluir Projeto, Editar Dados de Projeto Cadastrado, Excluir Projeto P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona a tela relativa a projetos 2. Sistema lista os projetos cadastrados relacionados aos grupos do usu ario logado e os projetos sem nenhum grupo relacionado, caso haja Incluir Projeto Ator: Administrador Pr e-condi co es: Estar autenticado pelo sistema e ter acessado a tela relativa a projetos Casos de Uso associados: Listar Projetos P os-condi co es: Haver a mais um projeto cadastrado no sistema Fluxo Principal: 1. Usu ario seleciona op c ao de incluir novo projeto 2. Sistema exibe formul ario 3. Usu ario preenche informa co es relativas ao projeto 4. Sistema exibe informa ca o conrmando a inclus ao do projeto 41

Fluxo Alternativo: 4a. Sistema exibe mensagem de erro caso alguma informa ca o digitada pelo usu ario n ao seja aceita 5a. Retorna ao Fluxo Principal Editar Informa co es de Projeto Cadastrado Ator: Product Owner Pr e-condi co es: Estar autenticado pelo sistema, ter listado projetos e haver pelo menos 1 (um) projeto cadastrado no sistema Casos de Uso associados: Listar Projetos P os-condi co es: Os dados de um projeto cadastrado no sistema ser ao alterados Fluxo Principal: 1. Usu ario seleciona um projeto previamente cadastrado no sistema 2. Usu ario seleciona op c ao de edi ca o de dados do projeto 3. Sistema exibe um formul ario com informa co es cadastradas preenchidas 4. Usu ario altera as informa co es desejadas 5. Sistema exibe informa ca o conrmando edi ca o de dados do projeto Fluxo Alternativo: 5a. Sistema exibe mensagem de erro caso alguma informa c ao n ao esteja correta 6a. Retorna ao Fluxo Principal 5b. Sistema exibe mensagem informando que n ao h a dados para serem alterados 6b. Retorna ao Fluxo Principal Excluir Projetos Ator: Product Owner Pr e-condi co es: Estar autenticado pelo sistema, ter acesso a tela relativa a projetos e existir ao menos 1 (um) projeto cadastrado no sistema Casos de Uso associados: Listar Projetos 42

P os-condi co es: Os projetos selecionados ser ao exclu dos logicamente do sistema Fluxo Principal: 1. Usu ario seleciona um ou mais projetos a serem exclu dos 2. Usu ario seleciona op c ao de exclus ao de projeto 3. Sistema exibe informa ca o conrmando a exclus ao do(s) projeto(s) Fluxo Alternativo: 3a. Caso haja tarefas n ao nalizadas para o projeto, usu ario poder a escolher entre cancelar as mesmas e proceder com a exclsu ao ou cancelar a exclus ao do projeto 4a. Retorna ao Fluxo Principal Listar Grupos Ator: Administrador, Product Owner, Scrum Master, Membro Equipe Pr e-condi co es: Estar autenticado pelo sistema Casos de Uso associados: Incluir Grupo, Inserir Integrantes ao Grupo, Editar Informa co es de Grupo Cadastrado, Excluir Grupo P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona a tela relativa a grupos 2. Sistema lista os grupos cadastrados dos quais o usu ario logado faz parte (no caso do administrador, o sistema lista todos os grupos existentes) Fluxo Alternativo: 3a. Usu ario ordena grupos por descri c ao ou projeto Incluir Grupo Ator: Administrador Pr e-condi co es: Estar autenticado pelo sistema e ter listado grupos Casos de Uso associados: Listar Grupos, Inserir Integrantes ao Grupo, Excluir Grupos 43

P os-condi co es: Haver a mais um grupo cadastrado no sistema Fluxo Principal: 1. Usu ario seleciona a op ca o para incluir um grupo 2. Sistema exibe uma linha nova onde est ao listados os grupos 3. Usu ario preenche informa co es relativas ao grupo 4. Sistema exibe uma mensagem conrmando a inclus ao do grupo Fluxo Alternativo: 4a. Sistema exibe mensagem de erro caso alguma informa ca o esteja incorreta 5a. Retorno ao Fluxo Principal 5b. Usu ario insere integrantes ao grupo criado Editar Dados de Grupo Cadastrado Ator: Administrador, Product Owner Pr e-condi co es: Estar autenticado pelo sistema, existir ao menos 1 (um) grupo cadastrado no sistema e ter selecionado grupo Casos de Uso associados: Listar Grupos P os-condi co es: Dados de um grupo cadastrado no sistema ser ao alterados Fluxo Principal: 1. Usu ario seleciona op c ao de edi ca o de dados de grupo 2. Usu ario altera dados desejados do grupo 3. Sistema exibe mensagem conrmando a edi ca o de dados da grupo Fluxo Alternativo: 3a. Sistema exibe mensagem de erro, cada alguma informa c ao n ao esteja correta 4a. Retorno ao Fluxo Principal Inserir Integrantes a Grupo Ator: Administrador, Product Owner, Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, ter listado grupos e existir ao

44

menos 1 (um) grupo cadastrado no sistema Casos de Uso associados: Listar Grupos P os-condi co es: Haver a um ou mais integrantes cadastrados em um grupo Fluxo Principal: 1. Usu ario seleciona grupo dentre os listados na tela 2. Usu ario seleciona op c ao de incluir integrantes no grupo selecionado 3. Sistema exibe tela com os usu arios existentes e os usu arios j a relacionados ao grupo, caso existam 4. Usu ario adiciona ou exclui usu arios do grupo, nas posi co es desejadas 5. Sistema exibe mensagem conrmando a altera ca o nos usu arios do grupo Excluir Grupos Ator: Administrador, Product Owner Pr e-condi co es: Estar autenticado pelo sistema, ter listado os grupos e existir ao menos 1 (um) grupo cadastrado no sistema Casos de Uso associados: Listar Grupos P os-condi co es: Os grupos selecionados ser ao exclu dos logicamente do sistema Fluxo Principal: 1. Usu ario seleciona um ou mais grupos dentre os listados na tela 2. Usu ario seleciona a op ca o que exclui os grupos selecionados 3. Sistema exibe mensagem informando que grupos foram exclu do com sucesso Fluxo Alternativo: 3a. Caso haja sprints e/ou tarefas planejadas para o grupo, o usu ario poder a escolher entre excluir a(s) sprint(s) e cancelar as tarefas para proceder com a exclus ao ou cancelar a u ltima. 4a. Retorna ao Fluxo Principal Listar Sprints Ator: Product Owner, Scrum Master, Membro Equipe

45

Pr e-condi co es: Estar autenticado pelo sistema Casos de Uso associados: Incluir Sprint, Editar Dados de Sprint Cadastrada, Excluir Sprints P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona tela relativa a sprints 2. Sistema exibe sprints cadastradas para os grupos dos quais o usu ario logado faz parte Fluxo Alternativo: 3a. Usu ario ordena sprints por Descri c ao, Data de In cio ou Data de Fim Incluir Sprint Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema e ter listado sprints Casos de Uso associados: Listar Sprints P os-condi co es: Haver a mais uma sprint cadastrada no sistema Fluxo Principal: 1. Usu ario seleciona op c ao de inclus ao de nova sprint 2. Sistema exibe uma linha em branco onde as sprints est ao listadas 3. Usu ario preenche dados da sprint adicionada 4. Sistema exibe mensagem conrmando a inclus ao da nova sprint Fluxo Alternativo: 4a. Sistema exibe mensagem de erro, caso alguma informa c ao n ao esteja correta 5a. Retorno ao Fluxo Principal Editar Dados de Sprint Cadastrada Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, existir ao menos 1 (uma) sprint cadastrada no sistema e ter selecionado sprint 46

Casos de Uso associados: Listar Sprints P os-condi co es: Dados de uma sprint cadastrada no sistema ser ao alterados Fluxo Principal: 1. Usu ario seleciona op c ao de edi ca o de dados de sprint 2. Usu ario altera dados desejados da sprint 3. Sistema exibe mensagem conrmando a edi ca o de dados da sprint Fluxo Alternativo: 3a. Sistema exibe mensagem de erro, caso alguma informa c ao n ao esteja correta 4a. Retorno ao Fluxo Principal Exluir Sprints Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, ter listado sprints e existir ao menos 1 (uma) sprints cadastrada no sistema Casos de Uso associados: Listar sprints P os-condi co es: As sprints selecionadas ser ao exclu das logicamente do sistema Fluxo Principal: 1. Usu ario seleciona uma ou mais sprints dentre as listadas na tela 2. Usu ario seleciona a op ca o de exclus ao das sprints selecionadas 3. Sistema exibe mensagem conrmando a exclus ao das sprints Fluxo Alternativo: 3a. Caso haja tarefas planejadas para a sprint, o usu ario dever a escolher entre cancelar as tarefas planejadas para proceder com a exclus ao da sprint ou cancelar a exclus ao da u ltima 4a. Retorna ao Fluxo Principal Visualizar Tarefas Ator: Product Owner, Scrum Master, Membro Equipe Pr e-condi co es: Estar autenticado pelo sistema 47

Casos de Uso associados: Filtrar Tarefas, Incluir Tarefa, Editar Dados de Tarefa Cadastrada, Excluir Tarefas, Exibir Tarefas N ao Conclu das P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona tela relativa a tarefas 2. Sistema exibe tela relativa a tarefas, com todos os ltros que podem ser utilizados pelo usu ario Filtrar Tarefas Ator: Product Owner, Scrum Master, Membro Equipe Pr e-condi co es: Estar autenticado pelo sistema e ter acessado tela de tarefas Casos de Uso associados: Incluir Tarefa, Editar Dados de Tarefa Cadastrada, Excluir Tarefas, Exibir Tarefas N ao Conclu das P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona valores a serem levados em considera c ao nos ltros dispon veis, que ser ao: T tulo, Prioridade, Grupo, Status, Respons avel, Sprint, Esfor co e Observa ca o 2. Sistema exibe as tarefa de acordo com os ltros realizados pelo usu ario Fluxo Alternativo: 3a. Usu ario ordena tarefas pelo t tulo Incluir Tarefa Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema e ter listado tarefas Casos de Uso associados: Filtrar Tarefas P os-condi co es: Haver a mais uma tarefa cadastrada no sistema Fluxo Principal: 1. Usu ario seleciona op c ao de inclus ao de nova tarefa 2. Sistema exibe uma nova linha onde o usu ario desejar 3. Usu ario preenche formul ario com informa co es da tarefa 48

4. Sistema exibe mensagem conrmando inclus ao da nova tarefa Fluxo Alternativo: 4a. Sistema exibe mensagem de erro, caso alguma informa c ao dada pelo usu ario esteja incorreta 5a. Retorno ao Fluxo Principal Delegar Sprints a Tarefa Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, ter listado tarefas e haver ao menos uma tarefa cadastrada Casos de Uso associados: Filtrar Tarefas P os-condi co es: Haver a uma ou mais sprints em que a tarefa deve ser executada Fluxo Principal: 1. Usu ario seleciona uma tarefa listada na tela 2. Usu ario seleciona op c ao de delegar sprints a tarefa 3. Sistema exibe formul ario contendo as sprints existentes para o grupo e poss veis esfor cos planejado e real 4. Usu ario seleciona sprints em que a tarefa deve ser executada, assim como seus respectivos esfor cos planejados (ou real tamb em, caso tarefa j a tenha sido executada) e solicita o armazenamento dos dados 5. Sistema exibe mensagem conrmando a persist encia dos dados Tornar Tarefa(s) Filha(s) de Outra Tarefa Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, haver pelo menos 2 (duas) tarefas cadastradas no sistema e ter ltrado tarefas Casos de Uso associados: Filtrar tarefas P os-condi co es: Haver a uma tarefa relacionada como lha de outra tarefa Fluxo Principal: 1. Usu ario seleciona tarefa(s) que deve(m) se tornar lha(s) da tarefa imediatamente acima 49

2. Usu ario seleciona op c ao de tonar tarefa(s) lha(s) da tarefa acima 3. Sistema exibe mensagem conrmando a rela ca o entre as tarefas Desfazer V nculo entre Tarefas Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, haver pelo menos 2 (duas) tarefas cadastradas no sistema e haver rela ca o de pai e lha entre as tarefas Casos de Uso associados: Filtrar tarefas P os-condi co es: Tarefa antes relacionada como lha, ser a irm a de outra tarefa Fluxo Principal: 1. Usu ario seleciona tarefa(s) lha(s) que deve(m) ter o v nculo desfeito 2. Usu ario seleciona op c ao de desfazer v nculo entre tarefas pai e lha 3. Sistema exibe mensagem conrmando a opera ca o Editar Dados de Tarefa Cadastrada Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, existir ao menos 1 (uma) tarefa cadastrada no sistema e ter selecionado tarefa Casos de Uso associados: Listar tarefas P os-condi co es: Dados de uma tarefa cadastrada no sistema ser ao alterado Fluxo Principal: 1. Usu ario seleciona op c ao de edi ca o de dados de tarefa 2. Usu ario edita informa c oes desejadas da tarefa 3. Sistema exibe mensagem conrmando edi c ao de dados da tarefa Fluxo Alternativo: 3a. Sistema exibe mensagem de erro, caso alguma informa c ao dada pelo usu ario esteja incorreta 4a. Retorno ao Fluxo Principal Excluir Tarefas Ator: Scrum Master 50

Pr e-condi co es: Estar autenticado pelo sistema, ter listado tarefas e existir ao menos 1 (uma) tarefa cadastrada no sistema Casos de Uso associados: Listar tarefas P os-condi co es: As tarefas selecionadas ser ao exclu das logicamente do sistema Fluxo Principal: 1. Usu ario seleciona uma ou mais tarefas dentre as exibidas na tela 2. Usu ario seleciona a op ca o de exclus ao das tarefas selecionadas 3. Sistema exibe mensagem conrmando a exlcus ao das tarefas selecionadas Criar ou Editar Backlog da Sprint Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema, existir pelo menos 1 sprint e uma tarefa cadastradas no sistema Casos de Uso associados: Importar tarefas por status, Importar tarefa por prioridade, Filtrar tarefas, Editar Dados de tarefa Cadastrada P os-condi co es: Haver a mais uma sprint planejada no sistema Fluxo Principal: 1. Usu ario acessa tela relativa ao planejamento da sprint 2. Usu ario preenche o grupo e a sprint que deseja planejar 3. Sistema exibe, caso existam, as tarefas j a planejadas para a sprint selecionada e seu esfor co total planejado 4. Usu ario salva informa co es desejadas Fluxo Alternativo: 4a. Usu ario importa tarefas atrav es de status e prioridade 5a. Usu ario planeja tarefas ltradas para a sprint selecionada 6a. Retorno ao Fluxo Principal Importar Tarefas por Status Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema e ter acessado cria ca o ou edi ca o

51

de backlog de sprint Casos de Uso associados: Criar ou Editar Backlog de Sprint tarefas P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona op c ao de importa c ao de tarefas por status 2. Sistema exibe tarefas cadastradas no sistema, planejadas para sprints anteriores que ainda n ao foram conclu das Fluxo Alternativo: 3a. Usu ario planeja atividades importadas para sprint selecionada Importar Tarefas por Prioridade Ator: Scrum Master Pr e-condi co es: Estar autenticado pelo sistema e ter acessado cria ca o ou edi ca o de backlog de sprint Casos de Uso associados: Criar ou Editar Backlog de Sprint tarefas P os-condi co es: NA Fluxo Principal: 1. Usu ario seleciona op c ao de importa c ao de tarefas por prioridade 2. Sistema exibe tela para que usu ario preencha o valor de prioridade m nimo desejado 3. Sistema exibe tarefas cadastradas no sistema ainda n ao conclu das com os prioridade igual ou maior que o selecionado pelo usu ario Diagrama de Classes O diagrama de classes pode ser visualizado atrav es da gura 4.5. Um maior detalhamento das classes e seus respectivos dicion arios de dados ser ao apresentados na Descri ca o de Projeto de Software.

52

Figura 4.5: Diagrama de Classes.

4.3.3

Requisitos de Desempenho

Visto que a aplica ca o desenvolvida ser a rodada localmente, n ao e necess ario o suporte de v arios usu arios simultaneamente, entretando, o servidor de banco de dados usado dever a permitir acesso de diferentes usu arios. Al em disso, ca estabelecido o tempo m aximo para consultas e persist encia no banco de dados de 1 segundo.

4.3.4

Restri co es de Projeto

Devido ` a escolha das ferramentas Microsoft Visual Studio e Microdoft SQL Server, o projeto ser a compat vel apenas com sistema operacional Windows.

4.3.5

Atributos

Os atributos principais do sistemas s ao: Funcionabilidade

53

O iPlan ser a capaz de realizar com sucesso, precis ao e seguran ca todas as fun co es propostas neste documento. Conabilidade

Ap os o desenvolvimento da aplica ca o ser ao feitos repetidos testes (previstos do Plano de Testes) para que o sistema n ao apresente erros. Usabilidade

Para o p ublico para o qual foi idealizado, a utiliza ca o do sistema a ser desenvolvido ser a facilmente compreendida.

Ainda, o software ser a implementado de forma que o aprendizado do usu ario e sua operabilidade sejam facilitadas.

Como todo sistema amig avel, e esperado que o usu ario possa usar o iPlan tendo apenas lido o Manual do Usu ario. Manutenabilidade

Durante o desenvolvimento do sistema, ser ao tomadas medidas para que este seja facilmente analisado, testado e modicado, caso necess ario. Seguran ca

Dado que os usu arios do sistema devem ser autenticados para desfrutar de suas funcionalidades, os dados salvos apenas ser ao acessados por pessoas autorizadas.

4.3.6

Outros Requisitos

Para acessar o sistema, os usu arios dever ao estar cadastrados no mesmo e ser autenticados atrav es de nome de usu ario e senha.

54

Cap tulo 5 Descri c ao de Projeto de Software

5.1
5.1.1

Introdu c ao
Finalidade

O presente cap tulo tem como nalidade especicar a arquitetura do software desenvolvido, al em de estruturar o projeto para facilitar o desenvolvimento do mesmo.

5.1.2

Escopo

Atrav es deste car ao denidas as estruturas de cada m odulo do sistema desenvolvido, al em de ser apresentado o modelo de banco de dados a ser usado e os principais m etodos utilizados para realizar a persist encia de informa co es no mesmo, proporcionando, assim, um melhor entendimento do projeto ao leitor. Vela ressaltar que as classes, seus atributos e m etodos, assim como as correspondentes tabelas no banco de dados foram projetados em ingl es por uma quest ao de universaliza c ao do c odigo fonte.

5.1.3

Deni co es, Acr onimos e Abreviaturas

As deni co es necess arias foram feitas no in cio desta documenta ca o.

55

5.2

Refer encias

As refer encias bibliogr acas encontram-se no nal deste documento.

5.3
5.3.1

Decomposi c ao
Decomposi c ao em M odulos

Para elaborar a arquitetura do projeto desenvolvido foi usada a metodologia MVC (Model-View-Control ). De uma maneira geral, as camadas Model, View e Control ser ao utilizadas da seguinte forma: View

Representa a interface do usu ario com o sistema. Esta camada e codicada inteiramente em C#, utilizando os componentes Form e UserControl.

Os componentes nomeados da forma [nome]Form, [nome]RegisterForm e [nome]UserControl obedecem ` a arquitetura representada na gura 5.1.

Os componentes gen ericos BaseUserControl, BaseForm e BaseGridForm foram criados a m de evitar repeti co es desnecess arias no c odigo, agregando, assim, as funcionalidades b asicas comuns a todos os componentes que destes derivam. Control

Cont em as regras de neg ocios a serem utilizadas, al em de manipula ca o de dados enviados ao banco de dados e recebidos do mesmo. Assim como a camada anterior, e codicada em C#.

56

Figura 5.1: Estrutura de Forms e UserControls. Pelo fato de o iPlan ser um cliente-servidor, parte das regras de neg ocio car a no banco de dados, em stored procedures, para viabilizar uma boa performance. Model

Cont em a classe que realiza a conex ao com o banco de dados, assim como as classes de entidade. Igualmente a `s demais camadas, e codicada em C#.

De forma semelhante ao m odulo de interface com o usu ario, h a uma classe base denominada BaseEntity que agrega as funcionalidades u teis e comuns a todas as classes de entidade. A descri c ao dos m odulos que comp oem o sistema segue nos itens abaixo. 5.3.1.1 M odulo de Acesso

Este m odulo e relativo a ` funcionalidade de acesso dos usu arios ao sistema. Para garantir a seguran ca do acesso e dos dados dos usu arios, a senha dos mesmos e armazenada no banco de dados criptografada atrav es de SHA (Secure Hash Algorithm ). 57

A arquitetura deste m odulo est a representada pela gura 5.2.

Figura 5.2: Arquitetura do M odulo de Acesso.

5.3.1.2

M odulo de Equipe

Este m odulo agrega todas as funcionalidades relativas a usu arios e grupos, sendo essas: Visualiza ca o de Usu arios Cadastro de Usu arios Edi ca o de Dados Usu arios Exclus ao de Usu arios Visualiza ca o de Grupos Cadastro de Grupos Edi ca o de Dados Grupos

58

 Adi ca o de Integrantes a Grupo Exclus ao de Grupos A arquitetura do m odulo de equipe est a apresentado na gura 5.3.

Figura 5.3: Arquitetura do M odulo de Equipe.

5.3.1.3

M odulo de Projeto

Este m odulo agrega as funcionalidades relativas a projetos, sendo estas: Visualiza ca o de Projetos Inclus ao de Projetos Edi ca o de Dados de Projetos Exclus ao de Projetos A aquitetura do m odulo de projeto est a apresentado na gura 5.4.

59

Figura 5.4: Arquitetura do M odulo de Projeto. 5.3.1.4 M odulo de Backlog

Este m odulo agrega todas a funcionalidades relativas a tarefas, sprints e planejamento de sprints, sendo estas; Visualiza ca o de Sprint Inclus ao de Sprint Edi ca o de Dados de Sprint Exclus ao de Sprint Visualiza ca o de Tarefas Inclus ao de Tarefas Atribui c ao de Sprints a Tarefa Edi ca o de Dados de Tarefas

60

Figura 5.5: Arquitetura do M odulo de Backlog. Exclus ao de Tarefas Criar Backlog de Sprint Importa ca o de Tarefas por Status Importa ca o de Tarefas por Prioridade A arquitetura do presente m odulo est a apresentada na gura 5.5.

5.3.2

Decomposi c ao em Processos Concorrentes

Ou nico caso onde h a processos concorrentes e o de m ultiplos usu arios acessando o banco de dados. Os m ultiplos acessos s ao controlados pelo pr oprio SGBD.

5.3.3

Decomposi c ao de Dados

Na gura 5.6 est a apresentado diagrama de classes do iPlan. As classes e seus atributos est ao especicados nos itens a seguir.

61

Figura 5.6: Diagrama de classes. Com exce c ao das classes Prioirity , Eort , Status e Position , todas as classes possuem o atributo Fl Deleted , que consiste de um indicador de exclus ao, j a que, quando exclu dos, os dados ser ao exclu dos do sistema logicamente, e n ao sicamente. 5.3.3.1 Classe User

Representa uma pessoa cadastrada no sistema. Como a autentica c ao e necess aria para acessar o iPlan, somente as pessoas cadastradas no sistema podem desfrutar de suas funcionalidades. 5.3.3.2 Classe Group

Representa uma pequena associa c ao de pessoas que formam uma equipe necess aria para o desenvolvimento de projetos ou partes destes utilizando Scrum.

62

Atributo Cd User Nm User

Descri c ao C odigo num erico u nico identicador de pessoa Denomina ca o que identica a pessoa em seu documento de identidade

Cd name

User-

Combina c ao de caracteres u nica que representa o nome pelo qual o usu ario ser a reconhecido no iPlan Indica ca o de correio eletr onico Combina c ao de s mbolos que cont em a senha criptografada do usu ario Indica ca o de dia, m es e ano do nascimento da pessoa Nota aditiva sobre a pessoa

Ad Email Cd word Dt Birth Ds Observation Pass-

Tabela 5.1: Atributos da Classe User Atributo Cd Group Descri c ao C odigo num erico u nico identicador do grupo de pessoas Ds Group Cd Project Narra ca o pormenorizada do grupo C odigo relativo ao projeto ao qual o grupo est a relacionado Tabela 5.2: Atributos da Classe Group 5.3.3.3 Classe Position

Representa o papel que uma pessoa cadastrada exerce dentro de um grupo do sistema. Como certas funcionalidades est ao dispon veis apenas para certos usu arios (por exemplo: Planejamento de Sprint dispon vel apenas para Scrum Masters ), e necess ario vericar a fun ca o do usu ario no grupo. Os valores poss veis para esta classe s ao Administrador, Product Owner , Scrum Master e Membro da Equipe.

63

Atributo Cd Position

Descri c ao C odigo n umerico u nico identicador do papel do integrante de um grupo no sistema

Ds Position

Narrativa pormenorizada do papel do integrante de um grupo no sistema Tabela 5.3: Atributos da Classe Position

5.3.3.4

Classe Group Member

Representa a associa c ao entre usu arios do sistema em um grupo e a fun c ao exercida no u ltimo. Atributo Cd User Cd Group Cd Position Descri c ao C odigo referente ao usu ario na associa ca o C odigo referente ao grupo na associa ca o C odigo referente a ` posi c ao do usu ario no grupo Tabela 5.4: Atributos da Classe Group Member

5.3.3.5

Classe Sprint

Representa o per odo de tempo b asico de desenvolvimento e entrega de um novo produto no Scrum. Atributo Cd Sprint Ds Sprint Dt Initial Descri c ao C odigo num erico u nico identicador da sprint Narra ca o pormenorizada da sprint Indica ca o de dia, m es e ano que marca o in cio da sprint cadastrada Dt Final Indica ca o de dia, m es e ano que marca o m da sprint cadastrada Cd Group C odigo referente ao grupo para o qual a sprint foi planejada Tabela 5.5: Atributos da Classe Sprint

64

5.3.3.6

Classe Project

Representa o projeto cadastrado no sistema, a ser desenvolvido por um ou mais grupos cadastrados. Atributo Cd Project Nm Project Ds Project Nm Contact Descri c ao C odigo num erico u nico identicador do projeto Denomina ca o dada ao projeto Narra ca o pormenorizada do projeto Nome da pessoa que deve ser contatada para levantar requisitos ou para sanar quaisquer d uvidas Dt Initial Dt Final Indica ca o de dia, m es e ano de in cio do projeto Indica ca o estimada de dia, m es e ano para que o projeto acabe Cd Status C odigo referente ao estado atual do projeto Tabela 5.6: Atributos da Classe Project

5.3.3.7

Classe Status

Representa o estado atual de um projeto ou tarefa, podendo assumir valores xos entre eles, Em Andamento, Conclu do, Cancelado. Atributo Cd Status Ds Status Descri c ao C odigo num erico u nico identicador do estado Narra ca o pormenorizada do estado Tabela 5.7: Atributos da Classe Status

5.3.3.8

Classe Priority

Representa a prioridade atribuida a tarefas ao serem planejadas. Prioridades podem assumir valores xos m ultiplos de 100, sendo o menor deles 100 e o maior, 1000.

65

Atributo Cd Priority Ds Priority Vl Priority

Descri c ao C odigo num erico u nico identicador da prioridade Narrativa pormenorizada da prioridade. Valor num erico assumido por uma prioridade Tabela 5.8: Atributos da Classe Priority

5.3.3.9

Classe Eort

Representa a medida do esfor co para realizar tarefas, levando-se em considera c ao sua diculdade e o tempo estimado para realiz a-las. No caso iPlan os valores poss veis para esfor co ser ao n umeros pertencentes a uma s erio de Fibonacci adaptada, sendo eles: 0, 1, 2, 3, 5, 8, 13, 20, 40, 60 e 100. Atributo Cd Eort Vl Eort Descri c ao C odigo num erico u nico identicador do esfor co Valor num erico assumido pelo esfor co Tabela 5.9: Atributos da Classe Eort

5.3.3.10

Classe Task

Representa uma tarefa de um projeto a ser desenvolvida em uma ou mais sprints por membros da equipe. 5.3.3.11 Classe Sprint Task

Representa uma tarefa a ser realizada em uma sprint.

5.4
5.4.1

Descri c ao das Depend encias

Depend encias entre m odulos

O m odulo de acesso, bem como o m odulo de projeto s ao independentes dos demais. O m odulo de equipe depende da classe Projeto, pertencente ao m odulo de projeto. A depend ecia e justicada pelo fato de os grupos serem pertencentes a projetos. 66

Atributo Cd Task Ds Task Ds Observation Cd Planned Eort Cd Priority Cd Status Cd Task Cd Group Main

Descri c ao C odigo num erico u nico identicador da tarefa Narra ca o pormenorizada da tarefa Nota aditiva sobre a tarefa

C odigo relativo ao esfor co estimado necess ario para completar uma tarefa C odigo relativo a ` prioridade da tarefa C odigo relativo a ` situa c ao da tarefa C odigo relativo a ` tarefa pai da tarefa, se existir

C odigo relativo ao grupo para o qual a tarefa foi planejada Tabela 5.10: Atributos da Classe Task

Atributo Cd Task Cd Task Cd Sprint Sprint

Descri c ao C odigo num erico u nico identicador da associa ca o entre tarefa e sprint C odigo relativo a ` tarefa C odigo relativo ` a sprint para a qual a tarefa foi planejada

Cd Planned Eort Cd Real Effort Cd Status Cd Responsible

C odigo relativo ao esfor co estimado para realizar a tarefa em dada sprint C odigo relativo ao esfor co real utilizado para executar a tarefa em dada sprint C odigo relativo a ` situa c ao da tarefa na sprint C odigo relativo ao usu ario respons avel por executar a tarefa em dada sprint Tabela 5.11: Atributos da Classe Sprint Task

Por m, o m odulo de backlog depende do m odulo de equipe, o que o torna dependente tamb em do m odulo de projeto.

67

As depend encias acima explicitadas podem ser observadas atrav es da gura 5.6.

5.4.2

Depend encias entre processos

N ao se aplica.

5.4.3

Depend encias entre dados

Como foi escolhida uma linguagem orientada a objeto, as depend encias entre dados est ao tamb em representadas no item Depend encias entre m odulos.

5.5

Descri c ao das Interfaces

As interfaces do sistema com o usu arios ser ao representadas no Manual do Usu ario. J a as interfaces entre os m odulos est a representada no item Projeto Detalhados dos M odulos.

5.6
5.6.1

Projeto Detalhado
Projeto Detalhado dos M odulos

A arquitetura dos m odulos foram especicados no item Decomposi c ao em M odulose pode ser melhor compreendida atrav es do diagrama de atividade e do diagrama de sequ encia do caso de uso Incluir Tarefa, ilustrados nas guras 5.7 e 5.8, respectivamente.

5.6.2

Projeto Detalhado das Entidades de Dados

O modelo de banco de dados criado para atender a `s necessidades do iPlan est a ilustrado l ogica e sicamente nas guras 5.9 e 5.10, respectivamente. A seguir encontram-se descritos os m etodos utlilizados pelas classes reais. Para todas as classes haver a um m etodo para aquisi ca o de dados relativos a ` classe da seguinte forma:

68

Figura 5.7: Diagrama de tarefa para incluir uma nova tarefa. List<T> GetList(T object) onde T e a classe e object e o objeto da classe com os par ametros a serem buscados, caso existam. 69

Figura 5.8: Diagrama de sequ encia para incluir uma nova tarefa. Para as classes Position, Priority, Eort e Status, o m etodo acima descrito ser a ou nico existente, j a que novos valores n ao podem ser salvos para tais classes. Para as demais classes, h a ainda os m etodos gen ericos de persist encia de dados descritos abaixo. int SetObject(T object) onde T e a classe cujo objeto ser a peristido e object e o objeto em si. O valor retornado e usado para vericar se a persist encia de dados foi realizada com sucesso. List<int> SetListObjects(List<T> listObjects) 70

Figura 5.9: Modelo L ogico do Banco de Dados para o iPlan.

Figura 5.10: Modelo F sico do Banco de Dados para o iPlan. Tem seu mecanismo similar ao m etodo anterior, sendo a u nica diferen ca a persist encia de m ultiplos objetos e, portanto, o retorno tamb em m ultiplo. 5.6.2.1 Classe User

List<User> GetUsersInGroup(int groupCode, string position) Busca os todos os usu arios pertencentes ao grupo cujo identicador e passado como argumento e que ocupam a posi c ao tamb em passada. Caso seja desejado 71

buscar todos os usu arios, independente da posi ca o, basta passar uma string vazia para este campo. DataSet GetUsersInGroups() Busca todos os usu arios que s ao membros de quaisquer grupos. O DataSet e organizado agrupando-se usu arios do mesmo grupo na mesma tabela. 5.6.2.2 Classe Group

List<Group> GetUserGroups(int userCode) Busca todos os grupos dos quais um usu ario faz parte, onde userCode e o identicador do usu ario. 5.6.2.3 Classe GroupMember

Esta classe possui somente os m etodos gen ericos. 5.6.2.4 Classe Sprint

List<Sprint> GetSprints(Sprint searchSprint, DateTime beginInitialDate, DateTime endInitialDate) Busca todas as sprints de acordo com os dados preenchidos no objeto passado e cuja data de in cio est a contida no intervalo passado como argumento. string CheckSprintData(Sprint saveSprint) Verica dados da sprint que ser a salva, tais como descri c ao da sprint e se a data de in cio ou m est a dentro de outra sprint do mesmo grupo. O par ametro saveSprint contem os dados da sprint a ser vericada, enquanto o retorno ea mensagem de erro, caso exista. 5.6.2.5 Classe Project

List<Project> GetProjects(Project searchProject, DateTime beginFinalDate, DateTime endFinalDate) Busca todos os projetos de acordo com os dados preenchidos no objeto passado como argumento e cuja data prevista de t ermino est a contida no intervalo referenciado.

72

 List<Project> GetUserProjects(int userCode) Busca todos os projetos dos quais um usu ario faz parte, sendo userCode o identicador do usu ario. 5.6.2.6 Classe Task

DataTable GetProductBacklogTasks(Task searchTask, SprintTask searchSprintTask) Busca todas as tarefas do product backlog cujos dados s ao iguais aos dados passados como par ametros atrav es dos objetos searchTask e searchSprintTask. DataTable GetSprintBacklogTasks(int sprintCode) Busca todas as tarefas planejadas para dada sprint, onde sprintCode e o c odigo da sprint. List<Task> GetLateTasks(int sprintCode) Busca todas as tarefas que foram planejadas para sprints anteriores a ` sprint passada como par ametro, mas n ao foram conclu das. DataTable GetTasksByPriority(int groupCode, int priorityCode) Busca tarefas ainda n ao conclu das de determinado grupo cuja prioridade e superior a ` prioridade passada como par ametro, onde groupCode e o codigo do grupo e priorityCode e o c odigo da prioridade. 5.6.2.7 Classe Sprint Task

Esta classe possui somente os m etodos gen ericos.

73

Cap tulo 6 Plano de Testes

6.1
6.1.1

Introdu c ao
Identicador

PTiPlan

6.1.2

Finalidade

Este plano de testes e dirigido ao professor Ant onio Cl audio G omez de Sousa, orientador deste Projeto de Gradua ca o, e a ` banca examinadora do mesmo. O software a ser testado e denominado iPlan. Os testes aqui propostos ser ao realizados para a apresenta c ao do projeto desenvolvido a ` banca examinadora.

6.1.3

Refer encias

As refer encias bibliogr acas encontram-se no nal deste documento.

6.2
6.2.1

Descri c ao Geral
Itens

Os itens do projeto a serem vericados ser ao:

74

 Arquitetura. Ser a aceito se cada m odulo da arquitetura estiver funcionando, independente dos outros e cada funcionalidade proposta nos m odulos for executada com sucesso. Comunica c ao com o Banco de Dados. Ser a aceito se todos os dados forem armazenados satisfatoriamente e se as consultas corresponderem ao esperado. Valida c ao dos campos digitados pelo usu ario em formul arios de cadastro. Ser a aceito se as mensagens exibidas pelo sistema ap os o preenchimento dos campos referidos for a esperada.

6.2.2

Requisitos

Os requisitos est ao previamente denidos no cap tulo Especica c ao de Requisitos de Software, al em de os crit erios estarem denidos na programa ca o do software. Ser ao considerados aceitos os itens que corresponderem devidamente ` as expectativas.

6.2.3

Vis ao Geral

Para testar os algoritmos desenvolvidos ser ao feitas fun c oes testes, a m de inserir dados conhecidos no sistema e ser ao observados os resultados obtidos atrav es destas. Os testes ser ao realizados e repetidos quantas vezes forem necess arias, fazendo com que todas as possibilidades de erro sejam testadas e aprovadas. O processo de testes ser a terminado quando os resultados obtidos foram satisfat orios para todos os testes feitos.

6.2.4

Suspens ao ou Conclus ao

N ao h a previs ao de suspens ao dos testes a serem realizados. A conclus ao destes se dar a quando os resultados obtidos forem satisfat orios, portanto, quando todas as falhas que venham a ser encontradas, sejam devidamente corrigidas.

6.2.5

Ambiente

Para a execu c ao do iPlan, e portanto, para a realiza c ao de seus testes, s ao necess arios: 75

 Sistema Operacional Windows Servidor de Banco de Dados SQL Server Microsoft Visual Studio

6.2.6

Tarefas e Cronograma

As tarefas e o cronograma dos testes realizados est ao representados na tabela 6.1.

Item testado Arquitetura Comunica c ao com o Banco de Dados Valida c ao dos Campos digitados

Data 05 - 07 de Fevereiro 08 - 09 de Fevereiro 10 - 11 de Fevereiro

Tabela 6.1: Cronograma.

6.2.7

Riscos e Gerenciamento

Os riscos que ser ao considerados para os testes s ao: Imper cia ao realizar o teste Indisponibilidade de tempo Para evitar os riscos acima citados, as poss veis falhas identicadas dever ao ser investigadas no momento de sua ocorr encia e corrgidas o mais r apido poss vel.

6.3
6.3.1
6.3.1.1

Especica c ao dos Testes

Especica c ao 1
Identicador

Arquitetura

76

6.3.1.2

Caracater sticas

Nesta especica c ao ser a testada a arquitetura do sistema. Os itens a serem testados s ao: Tela Usu arios Ser a vericado se as funcionalidades de Filtrar, Salvar, Adicionar Usu ario, Remover Usu ario, Desfazer Remo ca o de Usu arioe Editar Dados de Usu ariofuncionam conforme abaixo especicado: Filtrar: Todos os usu arios que atendem aos ltros devem ser exibidos na tela. Salvar: Quando n ao houver mudan cas nos dados, deve ser enviada uma mensagem ao usu ario indicando a aus encia de dados a serem salvos e nada deve ser feito. Caso contr ario, as altera co es devem ser salvas no Banco de Dados. Adicionar Usu ario: Ao ser acionado o bot ao relacionado, o sistema deve exibir o formul ario de cadastro de usu ario em branco. Caso o usu ario selecione a op c ao de salvar os dados preenchidos, o Banco de Dados deve ser atualizado, caso contr ario, nada deve ser feito. Remover Usu ario: Caso o bot ao relacionado seja acionado sem que qualquer linha esteja selecionada, o sistema deve exibir uma mensagem de erro ao usu ario. Caso contr ario, o(s) usu ario(s) selecionado(s) deve(m) ser exclu do(s) logicamente do sistema. Editar Dados de Usu ario: Ao ser acionada a op c ao de edi c ao de dados, o sistema deve exibir o formul ario de cadastro de usu ario, com os respectivos dados preenchidos e a op ca o Alterar Senhavis vel. A seguir, o procedimento deve ser o mesmo para o caso de Adicionar Usu ario. Desfazer Remo c ao de Usu ario: Ao ser acionada a op ca o de edi c ao de dados de um usu ario exclu do, o formul ario deve exibir o cadastro de usu ario com os dados preenchidos, por em com os campos n ao edit aveis e a op ca o Desfazer Exclus aodeve estar vis vel. A seguir o procedimento deve ser o mesmo para o caso de Adicionar Usu ario.

77

 Tela Grupos Ser a vericado se as funcionalidades Filtrar, Salvar, Adicionar Grupo, Remover Grupoe Atribuir Usu arios a Grupofuncionam conforme abaixo especicado: Filtrar: An alogo a ` mesma funcionalidade da tela Usu arios. Salvar: An alogo a ` mesma funcionalidade da tela Usu arios, com a adi ca o da verica ca o da exist encia de linhas ou campos e branco na tela. Adicionar Grupo: Ao ser acionado o bot ao relacionado, o sistema deve exibir uma linha em branco na tela. Remover Grupo: An alogo a ` mesma funcionalidade da tela Usu arios. Atribuir Usu arios a Grupo: Ao ser acionada a op ca o relacionada, o sistema deve exibir um formul ario contendo todos os usu arios cadastrado no sistema e os cargos poss veis para serem ocupados no grupo. Ao salvar dados, deve ser vericado se foram selecionados mais de um Product Owner ou ScrumMaster. Caso haja, deve ser exibida uma mensagem de erro. Tela Projetos Ser a vericado se as funcionalidades Filtrar, Salvar, Adicionar Projetoe Remover Projetofuncionam conforme abaixo especicado: Filtrar: An alogo a ` mesma funcionalidade da tela Usu arios. Salvar: An alogo ` a mesma funcionalidade da tela Usu arios. Adicionar Projeto: ao ser acionado o bot ao relacionado, o sistema deve exibir o formul ario de cadastro de projeto em branco. Caso seja selecionada a op ca o de persist encia, os dados digitados devem ser vericados e o Banco de Dados atualizado, caso n ao haja inconsist encias. Caso haja, deve ser exibida mensagem de erro ao usu ario indicando o erro. Remover Projeto: An alogo a ` mesma funcionalidade da tela Usu arios. Tela Sprints Ser a vericado se as funcionalidades Filtrar, Salvar, Adicionar Sprint e Remover Sprint funcionam conforme abaixo especicado: Filtrar: An alogo a ` mesma funcionalidade da tela Usu arios. Salvar: An alogo ` a mesma funcionalidade da tela Grupos. 78

 Adicionar Sprint : An alogo a ` mesma funcionalidade da tela Grupos. Remover Sprint : An alogo a ` mesma funcionalidade da tela Usu arios. Tela Tarefas Ser a vericado se as funcionalidades Filtrar, Salvar, Adicionar Tarefa, Remover Tarefa, Vincular Tarefa a Outra, Desfazer V nculo entre Tarefase Atribuir Sprints a Tarefafuncionam conforme abaixo especicado: Filtrar: An alogo a ` mesma funcionalidade da tela Usu arios. Salvar: An alogo ` a mesma funcionalidade da tela Grupos. Adicionar Tarefa: An alogo ` a mesma funcionalidade da tela Grupos. Remover Tarefa: An alogo a ` mesma funcionalidade da tela Usu arios. Vincular Tarefa a Outra: Ao ser acionado o bot ao correspondente deve ser vericado se h a alguma tarefa selecionada e se h a alguma tarefa acima da selecionada, para ser pai da primeira. A numera ca o das tarefas deve ser atualizada. Desfazer V nculo entre Tarefas: Ao ser acionado o bot ao correspondente, deve ser vericado se h a alguma tarefa selecionada e se esta est a vinculada como lha de outra. A numera ca o das tarefas deve ser atualizada. Atribuir Sprints a Tarefa: Ao ser seleciona a op ca o correspondente deve ser exibido o formul ario de atibui ca o de sprints. Ao salvar dados, deve ser vericado se os esfor cos selecionados foram salvos nas sprints corretas. Tela Planejar Sprint Ser a vericado se as funcionalidades Exibir Tarefas Planejadas, Salvar, Remover Tarefa Planejada, Importar Tarefas Atrasadase Importar Tarefas por Prioridadefuncionam conforme abaixo especicado: Exibir Tarefas Planejadas: Ao ser selecionada uma sprint, automaticamente as tarefas para aquela planejadas devem ser carregadas na tela. Salvar: An alogo ` a mesma funcionalidade da tela Usu arios. Remover Tarefa Planejada: An alogo ` a mesa funcionalidade da tela Usu arios.

79

 Importar Tarefas Atrasadas: Ao ser acionado o bot ao correspondente, deve ser vericado se todas as tarefas atrasadas (e n ao canceladas) foram carregadas na tela. Importar Tarefas por Prioridade: Ao ser acionado o bot ao correspondente, o sistema deve exibir uma tela com um valor de prioridade a ser selecionado. Ao acionar o bot ao Ok, deve ser vericado se todas as tarefas de prioridade igual ou superior a ` selecionada (e n ao canceladas) foram carregadas na tela. 6.3.1.3 Renamento

Para este teste, ser a vericado se o sistema responde de forma correta a ` entrada de dados inconsistentes, retornando mensagens de erro sempre que necess ario. J a na exibi c ao de dados, ser a vericado se o conte udo exibido e o correspondente ao armazenado no Banco de Dados. 6.3.1.4 CT1 Identicador de Caso de Teste

6.3.2
6.3.2.1

Especica c ao 2
Identicador

Comunica c ao com Banco de Dados 6.3.2.2 Caracater sticas

Nesta especica ca o ser a testada a comunica ca o com o Banco de Dados. Os itens a ser testados ser ao: Escrita no Banco de Dados Ser a vericado se os dados est ao sendo escritos no Banco de Dados de forma correta. Leitura do Banco de Dados Ser a vericado se os dados existentes no Banco de Dados est ao sendo lidos de forma correta. 80

6.3.2.3

Renamento

Para este teste a verica c ao dos dados gravados no banco de dados se dar a visualmente atrav es da ferramenta Microsoft SQL Server. Caso seja encontrada alguma inconsist encia no armazenamento ou leitura dos dados esperados e dos dados obtidos, o erro que gerou a falha dever a ser investigado, identicado e corrigido. 6.3.2.4 CT2 Identicador de Caso de Teste

6.3.3
6.3.3.1

Especica c ao 3
Identicador

Valida ca o de Campos 6.3.3.2 Caracater sticas

Ser ao vericados os campos de preenchimento pelo usu ario dos campos de: Inclus ao ou edi ca o de dados de usu ario Inclus ao ou edi ca o de dados de projeto Inclus ao ou edi ca o de dados de grupos Inclus ao ou edi ca o de dados de sprints Inclus ao ou edi ca o de dados de atividades Inclus ao ou edi ca o de dados de atividades em uma sprint Os casos acima mencionados est ao especicados individualmente a seguir:

Inclus ao ou Edi c ao de Dados de Usu ario

81

Os campos a serem vericados s ao: Nome Deve conter entre 4 e 50 caracteres Nome de Usu ario Deve conter entre 4 e 15 caracteres, e deve ser vericado se o nome de usu ario escolhido j a existe no banco de dados. Senha Deve conter entre 4 e 15 caracteres Conrma c ao de Senha Deve conter entre 4 e 15 caracteres e ser igual ao item Senha Data de Nascimento Os valores preenchidos dever ao ser selecionados, e n ao digitados, portanto deve ser apenas vericado se o usu ario selecionou valores para dia, m es e ano ou n ao Observa c ao Campo opcional, deve conter no m aximo 100 caracteres

Inclus ao ou Edi c ao de Dados de Projeto Os campos a serem vericados s ao: a existe algum Nome Deve conter entre 4 e 20 caracteres, e deve ser vericado se j projeto cadastrado com o mesmo c odigo Descri c ao Deve conter entre 4 e 100 caracteres Respons avel Deve conter entre 4 e 50 caracteres Data de In cio Os valores preenchidos dever ao ser selecionados, e n ao digitados, portanto deve ser apenas vericado se o usu ario selecionou valores para dia, m es e ano ou n ao Data de Fim Assim como no campo acima, os valores devem ser selecionados Status Deve ser vericado se o status do projeto foi selecionado

Inclus ao ou Edi c ao de Dados de Grupos

82

Os campos a serem vericados s ao: Descri c ao Deve conter entre 4 e 50 caracteres Projeto Deve ser vericado se o projeto relacionado ao grupo foi selecionado

Inclus ao ou Edi c ao de Dados de Sprints Os campos a serem vericados s ao: a existe alguma Descri c ao Deve conter entre 4 e 20 caracteres e deve ser vericado se j sprint cadastrada com a mesma descri c ao para o mesmo grupo Grupo Deve ser vericado se o grupo foi selecionado Data de In cio Deve ser vericado se os valores preenchidos correspondem a uma data Data de Fim Assim como no campo acima, os valores preenhidos devem ser uma data

Inclus ao ou Edi c ao de Dados de Tarefas Os campos a serem vericados s ao: a existe alguma T tulo Deve conter entre 4 e 100 caracteres e deve ser vericado se j tarefa cadastrada para o mesmo projeto com o mesmo t tulo Prioridade O valor deve ser selecionado Status O valor deve ser selecionado Esfor co Planejado Campo opcional. Pode ser deixado em branco ou selecionado Grupo Deve ser vericado se o grupo foi selecionado aximo 100 caracteres Observa c ao Campo opcional. Deve ter no m

6.3.3.3

Renamento

Para testar os campos mencionados, ser ao preenchidos formul arios com valores dentro, fora e nas margens de aceita c ao, caracterizando teste de caixa preta.

83

A t ecnica a ser utilizada para os testes de valida c ao de campos consiste no preenchimento dos campos e envio dos mesmos. A an alise deste teste e feita atrav es da mensagem que ser a apresentada para o usu ario.

6.3.3.4
CT3

Identicador de Caso de Teste

6.4
6.4.1
6.4.1.1
CT1

Casos de Teste
Caso de teste 1
Identicador

6.4.1.2

Itens

Ser a vericado se os m odulos da arquitetura funcionam independentemente um dos outros.

6.4.1.3

Entrada e Sa da

As entradas e sa das esperadas relacionadas ` a inconsist encias de dados de cada funcionalidade est ao representadas nas tabelas 6.2, 6.3 e 6.4.

6.4.1.4

Ambiente

Para executar os testes acima descritos e somente necess ario que o sistema esteja sendo executado.

6.4.2
6.4.2.1
CT2

Caso de teste 2
Identicador

6.4.2.2

Itens

Ser a vericado se a escrita e a leitura de dados no Banco de Dados est a sendo feita de forma correta.

84

Funcionalidade Salvar

Tela Usu arios Entrada Sa da Esperada Nenhuma mudan ca realizada Mensagem aus encia de dados a na tela Mudan cas realizadas Nome de usu ario escolhido j a existente Nome de usu ario n ao serem salvos Dados salvos no sistema Mensagem de nome de usu ario inv alido Dados de usu ario salvos no sistema Mensagem de aus encia de

Adicionar Usu ario

Remover Usu ario

cadastrado no sistema Nenhum usu ario selecionado Um ou mais usu arios selecionados

usu arios selecionados Usu ario removido logicamente do sistema

Tela Grupos Nenhuma mudan ca realizada Mensagem aus encia de dados a Salvar na tela Mudan cas realizadas e exist encia de linhas em branco Mudan cas realizadas Nenhum grupo selecionado Um ou mais grupos selecionados Mais de um Product Owner Atribuir Usu arios a Grupo selecionado Mais de um ScrumMaster selecionado Nenhum ou um Product serem salvos Mensagem indicando linhas em branco Dados salvos no sistema Mensagem de aus encia de grupos selecionados Grupo removido logicamente do sistema Mensagem de limite de um Product Owner Mensagem de limite de um ScrumMaster Usu arios adicionados ao grupo

Remover Grupo

Owner e ScrumMaster selecionado e nenhum ou mais membros selecionados Tabela 6.2: Entradas e Sa das Esperadas do Caso de Teste 1. 6.4.2.3 Entrada e Sa da

As entradas e sa das para este caso de teste s ao livres, sendo a u nicas condi c oes de sucesso a leitura e escrita de dados nas tabelas e colunas corretas no banco de dados.

85

Funcionalidade Salvar

Tela Projetos Entrada Sa da Esperada Nenhuma mudan ca realizada Mensagem aus encia de dados a na tela Mudan cas realizadas Nome de projeto escolhido j a existente Nome de projeto n ao serem salvos Dados salvos no sistema Mensagem de nome de projeto inv alido Dados de projeto salvos no sistema Mensagem de aus encia de projetos selecionados Projeto removido logicamente do sistema

Adicionar Projeto

Remover Projeto

cadastrado no sistema Nenhum projeto selecionado Um ou mais projetos selecionados

Tela Sprints Nenhuma mudan ca realizada Mensagem aus encia de dados a Salvar na tela Mudan cas realizadas e exist encia de linhas em branco Mudan cas realizadas Nenhuma sprint selecionada Uma ou mais sprint selecionadas serem salvos Mensagem indicando linhas em branco Dados salvos no sistema Mensagem de aus encia de sprints selecionadas Sprint removida logicamente do sistema

Remover Sprint

Tabela 6.3: Entradas e Sa das Esperadas do Caso de Teste 1. 6.4.2.4 Ambiente

A execu c ao dos testes de verica c ao da comunica c ao com o Banco de Dados ser a feitas em duas etapas: Teste das procedures de leitura e escrita Nesse caso o ambiente utilizado ser a o pr oprio servido de banco de dados Microsoft SQL Server Teste dos valores observados e enviados pela aplica c ao Nesse caso o ambiente utilizado ser a o pr oprio sistema

86

Funcionalidade Salvar

Tela Tarefas Entrada Nenhuma mudan ca realizada na tela Mudan cas realizadas e exist encia de linhas em branco Mudan cas realizadas Nenhuma tarefa selecionada Uma ou mais tarefas selecionadas Nenhuma tarefa selecionada

Sa da Esperada Mensagem aus encia de dados a serem salvos Mensagem indicando linhas em branco Dados salvos no sistema Mensagem de aus encia de tarefas selecionadas Tarefa removida logicamente do sistema Mensagem de aus encia de tarefas a ser vinculada Mensagem de aus encia de tarefa pai a ser vinculada Tarefas vinculadas ` a tarefa acima

Remover Tarefa

Vincular Tarefa Uma ou mais tarefas selecionadas, sem tarefas acima destas Uma ou mais tarefas selecionadas, com tarefas acima destas Nenhuma tarefa selecionada Desvincular Tarefas Uma ou mais tarefas selecionadas, sem tarefa vinculada Uma ou mais tarefas selecionadas, com tarefa vinculada

Mensagem de aus encia de tarefas a desvincular Mensagem de aus encia de tarefa pai a desvincular Tarefas desvinculadas da tarefa pai

Tela Planejar Sprints Nenhuma mudan ca realizada Mensagem aus encia de dados a Salvar na tela Mudan cas realizadas Nenhuma tarefa selecionada Uma ou mais tarefas selecionadas serem salvos Dados salvos no sistema Mensagem de aus encia de tarefas selecionadas Tarefa removida logicamente da sprint

Remover Tarefa

Tabela 6.4: Entradas e Sa das Esperadas do Caso de Teste 1.

87

6.4.3
6.4.3.1
CT3

Caso de teste 3
Identicador

6.4.3.2

Itens

Ser a vericado se o software est a validando corretamente os campos que devem ser digitados por usu arios.

6.4.3.3

Entrada e Sa da

As entradadas e sa das esperadas est ao representadas nas tabelas 6.5, 6.6, 6.7 e 6.8.

6.4.3.4

Ambiente

Para executar os testes acima descritos e somente necess ario que o sistema esteja sendo executado.

6.5
6.5.1
6.5.1.1
PT1

Procedimentos de Teste
Procedimento 1
Identicador

6.5.1.2

Finalidade

Esse procedimento de testes diz respeito ` a especica c ao de teste Arquitetura e descreve o procedimento de como devem ser efetuados os testes especicados no caso de teste CT1.

6.5.1.3

Necessidades Especiais

N ao h a necessidades especiais.

6.5.1.4

A co es

Para a correta execu c ao do caso de teste CT1 o testador dever a ter acesso a todas as funcionalidades do sistema.

88

Deve-se executar cada uma das funcionalidades descritas no CT1 e deve ser observada a sa da dada pelo sistema.

6.5.1.5

Relat orios

N ao ser ao emitidos relat orios.

6.5.2
6.5.2.1
PT2

Procedimento 2
Identicador

6.5.2.2

Finalidade

Esse procedimento de teste diz respeito ` a especica c ao de teste Comunica c ao com Banco de Dados e descreve o procedimento de como devem ser efetuados os testes especicados no caso de teste CT2.

6.5.2.3

Necessidades Especiais

N ao h a necessidades especiais.

6.5.2.4

A co es

Para a correta execu c ao do caso de teste CT2 o testador dever a ter acesso a modicar o banco de dados e visualiz a-lo. Deve-se executar funcionalidades que alterem dados no Banco de Dados, como a inclus ao de novo usu ario e tamb em uma que precisem ler dados contidos no Banco de Dados, como a listagem de atividades cadastradas. O testador dever a consultar o banco de dados via Microsft SQL Server e vericar visualmente se os dados conferem.

6.5.2.5

Relat orios

N ao ser ao emitidos relat orios.

89

6.5.3
6.5.3.1
PT3

Procedimento 3
Identicador

6.5.3.2

Finalidade

Esse procedimento de teste diz respeito ` a especica c ao de teste Valida c ao de Campos e descreve o procedimento de como devem ser efetuados os testes especicados no caso de teste CT3.

6.5.3.3

Necessidades Especiais

N ao h a necessidades especiais.

6.5.3.4

A co es

Para a correta execu c ao do caso de teste CT3 e evitar perdas de tempo desnecessariamente, o testador dever a isolar a camada de interface com o usu ario, preencher os dados contidos na coluna Entradadas tabelas 6.5, 6.6, 6.7 e 6.8 e vericar as sa das obtidas. Deve-se proceder preenchendo um ou mais campos incorretamente por funcionalidade, para testar a eci encia do sistema em detectar m ultiplos erros.

6.5.3.5

Relat orios

N ao ser ao emitidos relat orios.

90

Campo

Campos Relativos a Usu arios Entrada Recebida Sa da Esperada Campo em Branco Mensagem de campo em branco String com menos de 3 carac- Mensagem de Nome muito peteres String de comprimento permitido String com mais de 50 caracteres Campo em Branco String com menos de 3 caracqueno Procedimento ok Mensagem de Nome muito grande Mensagem de campo em branco Mensagem de nome de usu ario muito pequeno Procedimento ok Mensagem de nome de usu ario muito grande Mensagem de campo em branco Mensagem de senha muito curta Procedimento ok Mensagem de senha muito longa Mensagem de campo em branco Mensagem de Senha e Conrma c ao de senha diferentes Procedimento ok Mensagem de Data de Nascimento n ao selecionada Procedimento ok Procedimento ok Procedimento ok Mensagem de Observa c ao muito longa

Nome

Nome de Usu ario

teres String de comprimento permitido String com mais de 15 caracteres Campo em Branco String com menos de 4 carac-

Senha

teres String de comprimento permitido String com mais de 15 caracteres Campo em Branco String diferente da existente no campo Senha String igual ` a existente no campo Senha Valor igual a ` data de hoje Valor diferente da data de hoje Campo em Branco String de comprimento permitido String contendo mais de 100 caracteres

Conrma ca o de Senha Data de Nascimento

Observa c ao

Tabela 6.5: Entradas e Sa das Esperadas do Caso de Teste 3.

91

Campo

Campos Relativos a Entrada Recebida Campo em branco String com menos de 4 caracteres String de comprimento permitido String com mais de 20 caracteres Campo em branco String com menos de 4 carac-

Projetos Sa da Esperada Mensagem de campo em branco Mensagem de Nome muito curto Procedimento ok Mensagem de Nome muito longo Mensagem de campo em branco Mensagem de Descri c ao muito curta Procedimento ok Mensagem de Descri c ao muito longa Procedimento ok Mensagem de data de m inferior a ` data de in cio Mensagem de data de in cio e m iguais Procedimento ok

Nome

Descri ca o

teres String de comprimento permitido String contendo mais de 100

Data de In cio Data de Fim

caracateres Qualquer valor selecionado Valor selecionado inferior a ` data de in cio Valor selecionado igual ` a data de in cio Valor selecionado superior a `

Status

Descri ca o

data de in cio Campo em Branco Mensagem de campo em branco Status selecionado Procedimento ok Campos Relativos a Grupos de Usu arios Campo em branco Mensagem de campo em branco String com menos de 4 carac- Mensagem de Descri c ao muito teres String de comprimento permitido String com mais de 50 caracateres Campo em Branco Projeto selecionado curta Procedimento ok Mensagem de Descri c ao muito longa Mensagem de campo em branco Procedimento ok

Projeto

Tabela 6.6: Entradas e Sa das Esperadas do Caso de Teste 3.

92

Campo Descri ca o

Campos Relativos a Sprints Entrada Recebida Sa da Esperada Campo em branco Mensagem de campo em branco String com menos de 4 carac- Mensagem de Descri c ao muito teres String de comprimento permitido String com mais de 20 caracateres Campo em Branco Grupo selecionado Campo em Branco String qualquer String no formato curta Procedimento ok Mensagem de Descri c ao muito longa Mensagem de campo em branco Procedimento ok Mensagem de campo em branco Mensagem de Data de In cio fora do formato de data Procedimento ok Mensagem de campo em branco Mensagem de Data de Fim fora formato inferior a ` do formato de data Mensagem de Data de Fim inferior ` a data de in cio Mensagem de Data de Fim igual a ` data de in cio Procedimento ok

Grupo Data de In cio

dd/mm/yyyy Campo em Branco String qualquer Data de Fim String no dd/mm/yyyy data de in cio String no

formato

dd/mm/yyyy igual ` a data de in cio String no formato superior a `

dd/mm/yyyy data de in cio

Tabela 6.7: Entradas e Sa das Esperadas do Caso de Teste 3.

93

Campo

T tulo

Campos Relativos Entrada Recebida Campo em branco String com menos de 4 caracteres String de comprimento permitido String contendo mais de 100 caracateres Campo em Branco Prioridade selecionada Campo em Branco Status selecionado Campo em Branco Esfor co Planejado selecionado Campo em Branco String de comprimento permitido String contendo mais de 100

a Tarefas Sa da Esperada Mensagem de campo em branco Mensagem de T tulo muito curto Procedimento ok Mensagem de T tulo muito longo Mensagem de campo em branco Procedimento ok Procedimento ok Procedimento ok Procedimento ok Procedimento ok Procedimento ok Procedimento ok Mensagem de Observa c ao muito

Prioridade Status Esfor co Planejado

Observa c ao

Sprint Esfor co Planejado Esfor co Real

caracteres grande Campos Relativos a Tarefas em Sprint Nenhuma sprint selecionada Procedimento ok Sprint selecionada Procedimento ok Campo em Branco Mensagem de campo em branco Esfor co Planejado sele- Procedimento ok cionado Campo em Branco Esfor co Real selecionado Procedimento ok Procedimento ok

Tabela 6.8: Entradas e Sa das Esperadas do Caso de Teste 3.

94

Cap tulo 7 Manual Do Usu ario

7.1 Introdu c ao

Este manual foi elaborado com o prop osito de orientar o usu ario do iPlan na utiliza c ao do sistema. Ser ao abordados os modos de uso de cada funcionalidade existente.

7.2

Descri c ao

O iPlan visa auxiliar usu arios da metodologia agil Scrum, principalmente os Scrum Masters, a planejarem e acompanharem o andamento das tarefas necess arias ao desenvolvimento de um ou mais produtos. Para ser utilizado por mais de uma pessoa, o iPlan deve ser acessado atrav es da internet e o banco de dados deve ser compartilhado por todos os usu arios.

7.3
7.3.1

Utiliza c ao do iPlan
Acesso

No momento do primeiro acesso do usu ario ao iPlan, ser a feito um download da aplica c ao para sua m aquina, podendo, ent ao, o acesso ser feito localmente. Por em, para consultar e salvar dados e necess ario o acesso ` a internet ou ` a rede onde o sistema ser a disponibilizado. Todos os usu arios do sistema devem ter nome de usu ario e senha pr oprios e, para tanto, devem ser cadastrados por um administrador.

95

7.3.2

P agina Principal

Ap os fazer o login no sistema, o usu ario visualizar a a tela representada na gura 7.1.

Figura 7.1: P agina principal do iPlan.

As demais funcionalidades ser ao acessadas atrav es dos bot oes contidos nesta p agina.

7.3.3

Usu arios

Acessando o m odulo de usu arios, o usu ario visualizar a a tela representada na gura 7.2. Atrav es desta tela, e poss vel realizar as seguintes opera c oes: Listar ou Buscar Usu arios Adicionar Novo Usu ario Editar Dados de um Usu ario Dadastrado Excluir ou Desfazer Exclus ao de Usu ario Os bot oes destacados na gura 7.2 siginicam: 1 - Salvar

96

Figura 7.2: Modulo de Usu arios.

2 - Adicionar 3 - Excluir 4 - Filtrar Cada uma das opera c oes citadas est a detalhada a seguir.

7.3.3.1

Listar ou Buscar Usu arios

Para listar todos os usu arios do sistema ou buscar por alguns usu arios especicamente, basta preencher os ltros desejados e pressionar o bot ao Filtrar. Ap os esse passo, os usu arios cadastrados no sistema ser ao exibidos, conforme representado na gura 7.3. Para procurar tamb em pelos usu arios que eventualmente foram exclu dos do sistema, e preciso selecionar a op c ao Usu arios Deletados.

7.3.3.2

Adicionar Novo Usu ario

Para adicionar novos usu arios ao sistema, e necess ario clicar no bot ao Adicionar.

97

Figura 7.3: Usu arios listados.

Ao solicitar a adi c ao de um novo usu ario, e exibido o formul ario representado na gura 7.4.

Figura 7.4: Formul ario para a adi ca o de novo usu ario.

Ap os o preenchimento dos campos, os dados devem ser salvos, atrav es do bot ao localizado no canto superior esquerdo da tela. Caso haja algum erro ou inconsist encia nos

98

dados preenchidos, ser a exibida uma mensagem noticando o erro ocorrido, caso contr ario, o usu ario ser a avisado que os dados foram salvos com sucesso.

7.3.3.3

Editar Dados de um Usu ario Dadastrado

Para editar dados de um usu ario, este deve ser listado na tela e, ent ao, e necess ario clicar duas vezes na coluna em branco que precede a coluna de Nome, na linha correspondente ao usu ario cujos dados ser ao alterados. A seguir, o sistema exibe o formul ario de cadastro, com os dados atuais preenchidos. Basta, ent ao modicar os dados desejados e salvar as altera c oes, do mesmo modo que e feita a inclus ao de um novo usu ario. Segue um exemplo ilustrativo:

Altera c ao de dados do usu ario herika Com os dados dos usu ario exibidos na tela, conforme a gura 7.3, clica-se duas vezes na coluna em branco ` a esquerda, na segunda linha e o sistema exibe o formul ario da gura 7.5.

Figura 7.5: Formul ario para a edi ca o de usu ario cadastrado.

Como e poss vel ver, o campo nome de usu ario, que funciona como a identidade do usu ario no iPlan, n ao pode ser alterado. Para alterar quaisquer outros dados, basta escrev e-los ou selecion a-los, conforme no caso de adi c ao de usu ario.

99

Para alterar a senha cadastrada, e necess ario selecionar a op c ao Alterar Senha, e os campos de Senhae Conrma c ao de Senhatamb em ser ao exibidos.

7.3.3.4

Excluir ou Desfazer Exclus ao de Usu ario

Para excluir um usu ario do sistema, basta selecionar a linha em que seus dados est ao exibidos na tela representada pela gura 7.3 e acionar o bot ao Remover. Vale lembrar que o usu ario selecionado e aquele cuja linha possui uma seta preta. No caso da gura 7.3, o usu ario selecionado e o de nome de usu ario andreza. Para conrmar a exclus ao do usu ario, basta acionar o bot ao Salvar. J a para desfazer a exclus ao de um usu ario, basta ltrar utilizando a op c ao Usu arios Deletadose, a seguir, proceder como se fosse editar os dados do usu ario exclu do. A diferen ca consiste da op c ao Desfazer Exclus ao, exibida, conforme ilustrado na gura 7.6. Para realizar o retorno do usu ario ao sistema, basta selecionar a op c ao Desfazer Exclus aoe acionar o bot ao Salvar.

Figura 7.6: Procedimento necess ario para desfazer exclus ao de usu ario.

7.3.4

Projetos

Acessando o m odulo de projetos, o usu ario pode visualizar a tela representada pela gura 7.7. Atrav es desta tela, o usu ario pode:

100

Figura 7.7: M odulo de Projetos.

Listar ou Buscar Projetos Adicionar Projetos Editar Dados de Projetos Excluir ou Desfazer a Exclus ao de Projetos

7.3.4.1

Listar ou Buscar Projetos

De forma an aloga ao m odulo de usu arios, para buscar projetos cadastrados, basta preencher os ltros conforme desejado e acionar o bot ao Filtrar. Como pode ser notado atrav es da gura 7.7, h a duas op c oes quanto ao ltro de data. O usu ario pode decidir entre visualizar somente projetos cuja data de m pertence ao intervalo selecionado, ou projetos independentemente da data de m, atrav es da marca c ao da op c ao Qualquer Data. A gura 7.8 representa um resultado obtido ap os a busca de projetos.

101

Figura 7.8: Busca de Projetos. 7.3.4.2 Adicionar Projetos

Para adicionar projetos, basta que o bot ao Adicionarseja acionado, o formul ario exibido (representado pela gura 7.9) preenchido e os dados salvos, de forma semelhante ao procedimento de adi c ao de usu arios.

Figura 7.9: Formul ario a ser preenchido para adicionar um projeto.

102

7.3.4.3

Editar Dados de Projetos

Para editar dados de um projeto, o procedimento a ser realizado e o mesmo do caso de edi c ao de dados do usu ario. Basta clicar duas vezes em um projeto listado na tela, editar os dados exibidos no formul ario e salvar as altera c oes.

7.3.4.4

Excluir ou Desfazer a Exclus ao de Projetos

Tamb em de forma an aloga ao m odulo de usu arios, para excluir um projeto e preciso acionar os bot oes Removere, em seguida, Salvar, enquanto para desfazer a exclus ao de um projeto, basta, ao editar seus dados, selecionar a op c ao Desfazer Exclus aoe conrmar a opera c ao atrav es do bot ao Salvar.

7.3.5

Grupos

Figura 7.10: M odulo de grupos.

Ao acessar o m odulo de grupos, o usu ario visualizar a a tela da gura 7.10. Atrav es desta tela e poss vel: Listar ou Buscar Grupos

103

 Adicionar Grupos Editar Dados de Grupo Cadatrado Excluir ou Desfazer Exclus ao de Grupo

7.3.5.1

Listar ou Buscar Grupos

Da mesma forma dos m odulos anteriores, para buscar grupos, basta preencher os par ametros desejados e acionar o bot ao Filtrar. A gura 7.11 representa resultados de uma busca de grupos.

Figura 7.11: Exemplo de Resultado de Busca de Grupos.

7.3.5.2

Adicionar Grupos

Para adicionar grupos ao sistema, basta acionar o bot ao Adicionar. O sistema ent ao exibir a uma nova linha em branco abaixo da linha selecionada, caso haja, onde os dados do grupo devem ser preenchidos, conforme representado na gura 7.12. A seguir, o usu ario deve preencher os dados de grupo de acionar o bot ao Salvar.

104

Figura 7.12: Linha em branco para adi c ao de novo grupo.

Vale ressaltar que nesse caso, podem ser adicionados mais de um grupo ao mesmo tempo, se assim for desejado. Para isso, basta adicionar mais linhas em branco ` a tela e preencher o dados dos novos grupos.

7.3.5.3

Editar Dados de Grupo Cadatrado

Para editar dados de um grupo cadastrado, basta sobre-escrever os dados do grupo desejado, exibidos na tela e acionar o bot ao Salvar.

7.3.5.4

Excluir ou Desfazer Exclus ao de Grupo

Para excluir um grupo, h a duas formas poss veis: alterar o valor da coluna Deletadopara Sim, ou utilizar o procedimento realizado para exclus ao de usu arios e projetos. Para desfazer a exclus ao de um grupo, basta alterar o valor da coluna Deletado, de Simpara N aodos usu arios exclu dos.

105

7.3.6

Sprints

Ao acionar o bot ao relativo ao m odulo de Sprints, o usu ario tem acesso ` a tela ilustrada na gura 7.13.

Figura 7.13: M odulo de Sprints.

Atrav es desta tela e poss vel: Listar ou Buscar Sprints Adicionar Sprints Editar Dados de Sprints Excluir ou Desfazer Exclus ao de Sprints Este m odulo funciona de forma semelhante ao m odulo de Grupos, sendo a adi c ao de novas sprints feita atrav es do preenchimento de campos de novas linhas exibidas na tela, a dele c ao de usu arios podendo ser feitas das duas formas j a citadas e o retorno de sprints ao sistema atrav es da altera c ao do valor da coluna Deletada.

7.3.7

Tarefas

Ao acessar o m odulo de Tarefas, o usu ario visualiza a tela representada pela gura 7.14.

106

Figura 7.14: M odulo de Tarefas.

Atrav es deste m odulo e poss vel: Filtrar Tarefas Adicionar Tarefa Editar Dados de Tarefa Excluir ou Desfazer Exclus ao de Tarefa Vincular Tarefa como Filha de Outra Tarefa Desfazer V nculo entre Tarefas Adicionar Tarefa a Sprints Os novos bot oes visualizados na tela t em as seguintes fun c oes: 5 - Desvincular Tarefas 6 - Vincular Tarefas 7 - Adicionar Tarefa a Sprints

107

As funcionalidades Filtrar Tarefas, Adicionar Tarefas, Editar Dados de Tarefase Excluir ou Desfazer Exclus ao de Tarefase d ao de forma semelhante ao m odulo de Sprints. As demais funcionalidades est ao descritas a seguir.

7.3.7.1

Vincular Tarefa como Filha de Outra Tarefa

Para vincular uma tarefa como lha de uma outra, basta selecionar a tarefa lha e acionar o bot ao Vincular Tarefase a tarefa acima da selecionada ser a vinculada como pai desta. Para identicar tarefas lhas e tarefas pais h a uma numera c ao na primeira coluna, sem t tulo. Tarefas lhas em t em sua numera c ao a numera c ao da tarefa pai com a adi c ao de um sub ndice. Al em disso, tarefas pais s ao destacadas pela fonte em negrito. A gura 7.15 ilustra um exemplo de busca de tarefas com os respectivos v nculos.

Figura 7.15: Exemplo de busca de tarefas com respectivos v nculos.

7.3.7.2

Desfazer V nculo entre Tarefas

Para desfazer o v nculo entre uma tarefa e a respectiva tarefa pai, basta selecionar a primeira e acionar o bot ao Desvincular Tarefas. A tarefa ent ao, ser a recuadaem um n vel, caso poss vel.

108

7.3.7.3

Adicionar Tarefa a Sprints

Para planejar uma ou mais sprints em que certa tarefa deve ser executada, e necess ario selecionar uma tarefa e acionar o bot ao Adicionar Tarefa a Sprints . O sistema ent ao exibe o formul ario ilustrado na gura 7.16.

Figura 7.16: Adicionar Tarefa a Sprints.

O procedimento a ser realizado, ent ao, e a sele c ao de sprints em que a tarefa deve ser executada e a estima c ao do esfor co, atrav es do preenchimento do campo Esfor co Planejado. poss E vel ainda preencher o esfor co de fato realizado para executar tal tarefa atrav es do preenchimento do campo Esfor co Real.

7.3.8

Planejar Sprint

Ao acessar a tela Planejar Sprint , o usu ario deve selecionar o grupo e a respectiva sprint que deseja planejar e, automaticamente, as tarefas previamente planejadas para a u ltima s ao carregadas na tela, conforme ilustrado na gura 7.17. Como e poss vel notar, a presente tela faz o c alculo da velocity da sprint (localizado no canto superior direito da tela) automaticamente. Os novos bot oes exibidos nesta tela possuem as seguintes nalidades: 8 - Importar Tarefas Atrasadas

109

Figura 7.17: Exemplo de tarefas planejadas para grupo e sprint exibidos.

9 - Importar Tarefas por Prioridade A tela supracitada possui as funcionalidades abaixo, que ser ao detalhadas em seguida. Remover tarefas da sprint Importar tarefas de atrasadas Importar tarefas por prioridade

7.3.8.1

Remover Tarefas da Sprint

Para remover uma uma tarefa da sprint selecionada, basta selecionar a tarefa desejada e acionar o bot ao Removerou alterar o valor da coluna Deletadapara Sim. Vale ressaltar que tal tarefa n ao ser a removida do sistema, apenas n ao ser a planejada para ser executada na presente sprint.

7.3.8.2

Importar Tarefas Atrasadas

Para importar ` a sprint atual tarefas planejadas para sprints anteriores, por em que n ao foram conclu das, basta acionar o bot ao Importar Tarefas Atrasadas.

7.3.8.3

Importar Tarefas por Prioridade

Para importar tarefas de determinada prioridade planejadas para sprints futuras, basta acionar o bot ao Importar Tarefas por Prioridade.

110

O sistema, ent ao, exibe ao usu ario as poss veis prioridades de uma tarefa, conforme ilustrado na gura 7.18.

Figura 7.18: Op c ao de prioridades para que o usu ario selecione a desejada.

Ao selecionar a prioridade desejada e clicar no bot ao Ok, o sistema exibe tarefas cadastradas de acordo com a prioridade selecionada, somadas ` as tarefas previamente planejadas para a presente sprint.

111

Cap tulo 8 Conclus ao

O presente trabalho apresentou a idealiza c ao, projeto e implementa c ao do iPlan, um sistema cujo objeto e facilitar a vida de usu arios da metodologia agil Scrum, principalmente Product Owners e ScrumMasters no que diz respeito ao gerenciamento de tarefas necess arias para a elabora c ao de um projeto. Atrav es do iPlan Product Owners e ScrumMasters poder ao contar com um ambiente completamente adaptado ` a framework do Scrum para planejar e executar projetos, ao inv es de utilizar planilhas, dicultando, portanto, a n ao conformidade de dados com o ambiente do Scrum e perda acidental daqueles. Ainda, como o c odigo-fonte ser a disponibilizado aos interessados e foi tomado o cuidado de deix a-lo claro, bem documentado e manuten vel, o iPlan pode ser facilmente adaptado por outras pessoas ` as suas necessidades. Todos os objetivos tra cados para o sistema foram alcan cados, entretanto, a funcionalidade de exibi c ao de tarefas, no que se refere ao v nculo entre tarefas pais e lhas, teve sua complexidade alterada para que o projeto pudesse ser nalizado a tempo. A metodologia adotada para o desenvolvimento do projeto se mostrou satisfat oria, dado o baixo tempo de aprendizado necess ario, j a que a mesma j a havia sido previamente utilizada pela aluna. O mesmo pode ser falado dos softwares escolhidos para o desenvolvimento do projeto, j a que n ao s ao dif ceis de serem manipulados, possuem extensa documenta c ao e suas respectivas licen cas est ao dispon veis gratuitamente para alunos da UFRJ.

112

Apesar de possuir mais de um ano de experi encia com Scrum, o desenvolvimento deste projeto me permitiu um conhecimento mais profundo das ra zes e particularidades desta metodologia. Do meu ponto de vista, esta e bastante utiliz avel, n ao s o em empresas, como em projetos acad emicos, por facilitar o conhecimento e dom nio de todos de uma equipe as v ` arias nuances do objeto estudado ou desenvolvido, al em de facilitar a substitui c ao das pessoas de uma equipe a longo prazo, j a que o conhecimento n ao ca restrito a uma pequena parte dos integrantes. Por m, durante a elabora c ao do projeto foram pensadas em maneiras de deix a-lo ainda mais robusto e adapt avel a diferentes equipes, como uma maior exibilidade quanto a quantidades de par ametros de uma tarefa. Deste modo, como trabalho trabalho futuro, tem-se o desenvolvimento de novas funcionalidades a m de tornar o iPlan adapt avel a diferentes equipes sem que seja necess aria manipula c ao de seu c odigo-fonte.

113

Refer encias Bibliogr acas

[1] FERREIRA, P., TORREAO, P., MARC AL, A. S., Entendendo Scrum para Gerenciar Projetos de Forma Agil, MundoPM, v. 1, n. 17, 2007. [2] Scrum, http://pt.wikipedia.org/wiki/Scrum, (Acesso em 08 Fevereiro 2011). [3] Scrum (rugby), http://en.wikipedia.org/wiki/Scrum (rugby), (Acesso em 09 Fevereiro 2011). [4] BECK, K., BEENDLE, M., BENNEKUM, A. V., et al., Manifesto for Agile Software Development, http://agilemanifesto.org, 2001, (Acesso em 01 Fevereiro 2011). [5] COHN, Scrum M., to A your Resusable team, Scrum Presentation. and Product Introduce Owner,

ScrumMaster

http://www.mountaingoatsoftware.com/scrum-a-presentation, 2002, Acesso em 31 Janeiro 2011. [6] Learining Scrum The Product Backlog, Acesso

http://www.mountaingoatsoftware.com/scrum/product-backlog, em 09 Fevereiro 2011.

[7] Scrum Training and Agile Training from ScrumMaster Mike Cohn, http://www.mountaingoatsoftware.com/, Acesso em 09 Fevereiro 2011. [8] COHN, M., Agile Training on Sprint Planning Meeting,

http://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting, Acesso em 31 Janeiro 2011. [9] Planning Poker, http://www.planningpoker.com/, Acesso em 09 Fevereiro 2011. 114

[10] Scrum

Is

an

Innovative

Approach

to

Getting

Work

Done,

http://www.scrumalliance.org/pages/what is scrum, Acesso em 20 Agosto 2010. [11] MSDN Academic Alliance, http://msdn.microsoft.com/en-

us/academic/default.aspx, Acesso em 23 Agosto 2010. [12] Associa c ao Brasileira de Normas T ecnicas, http://www.abnt.org.br/, Acesso em 25 Agosto 2010.

115