PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW

UNIVERSIDADE FEDERAL DE SERGIPE CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA

DEPARTAMENTO DE COMPUTAÇÃO SISTEMAS DE INFORMAÇÃO

PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW

Daiana Joyce Rodrigues Costa 201010007310

Matheus Costa Rezende 201210009526

Mike Santos Farias 201110006540

São Cristóvão

2016


DEPARTAMENTO DE COMPUTAÇÃO

PLANO DO PROJETO DE SOFTWARE OO para produtos da Lacertae SW

Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como nota para disciplina Gerência de Projetos do curso de graduação em Sistemas de Informação – Bacharelado da Universidade Federal de Sergipe (UFS).

Discipina: Gerência de Projetos

Docente: Prof. Dr. Rogério Patrício Chagas

Equipe: Daiana Joyce, Matheus Costa e Mike Farias

São Cristóvão

2016 1



Sumário 1. Introdução .................................................................................................................. 03

1.1 Âmbito do Projeto ...................................................................................................... 03 1.2 Funções principais do produto de software ............................................................... 03 1.3 Requisitos comportamentais ou de performance ....................................................... 04 1.4 Gestão e Restrições Técnicas ..................................................................................... 05 1.5 Gestão e Restrições Técnicas ………………………………………………………. 05 1.6 Requisitos comportamentais ou de performance ………………………………...… 05

2. Estimativas do Projeto .............................................................................................. 06

2.1 Dados históricos utilizados para as estimações ………………………………….. 06 2.2 Técnicas de estimação e resultados …………………………………………….... 06 2.2.1 Técnica de estimação …………………………………………………………... 06 2.3 Resultados ……………………………………………………………………...… 07 2.4 Recursos do projeto ……………………………………………………………..... 08 2.4.1 Recursos Humanos ……………………………………………………………... 08 2.4.2 Recursos de Software …………………………………………………………... 09 2.4.3 Recursos de Hardware …………………………………………………………. 09 3. Análise e Gestão de Riscos ........................................................................................ 10

3.1 Riscos do projeto ………………………………………………………………..... 10 3.2 Tabela de riscos …………………………………………………………………... 11 3.3 Redução e Gestão do Risco ……………………………………………………..... 12 4. Planejamento temporal ............................................................................................. 18

4.1 Conjunto de Tarefas do Projeto …………………………………………………..… 18 4.2 Diagrama de Gantt ………………………………………………………………..... 19 5. Organização do pessoal ............................................................................................. 20

5.1 Estrutura da equipe …………………………………………………….................... 20

5.2 Mecanismos de comunicação …………………………………………………….... 21

5.3 Uso do Edublog como ferramenta de apoio ………………………………….…… 21 6. Precauções tomadas para assegurar e controlar a qualidade do produto de software

………………………………………………………………………………………………… 22

São Cristóvão

2016 2



1.0 INTRODUÇÃO

1.1 Âmbito do Projeto O módulo Diploma permite gerenciar o processo de emissão de diplomas

para os diversos níveis de ensino. Os módulos Stricto Sensu e Graduação já foram implantados. Nesse momento o foco se dará ao Lato Sensu. No módulo Diploma é possível cadastrar o livro de registro de diplomas, emitir diplomas de forma coletiva e individual, segunda via entre outras funcionalidades. 1.2 Funções principais do produto de software

As principais funções do Módulo Diploma são as seguintes:

Registrar diploma individual; Registrar diplomas para um grupo de alunos; Cadastrar assinaturas do diploma; Auditar a geração de diplomas; Auditar a requisição de número de registros; Consultar dados do discente; Atualizar dados pessoais dos discentes; Gerenciar livros de registro de diplomas; Buscar registros de diplomas; Buscar registros coletivos de diplomas; Editar observações do registro do aluno; Permitir Remover um Registro de Diploma; Imprimir diploma individual; Imprimir diploma coletivo; Imprimir segunda via de diploma; Listar alunos para assinatura no ato da colação.

São Cristóvão

2016 3



1.3 Diagrama de Caso de Uso

Figura 1 Diagrama de Caso de Uso

São Cristóvão

2016 4



1.4 Papéis

O sistema deve disponibilizar as funções de acordo com os seguintes papéis:

Gestor de Diplomas Lato, Gestor de Diplomas Stricto e Gestor de

Diplomas Graduação são responsáveis pelo gerenciamento dos livros de registro e emissão de diplomas para os seus respectivos níveis de ensino.

1.5 Requisitos comportamentais ou de performance

O produto apresentado tem como requisito uma interface de fácil

usabilidade e o atendimento às restrições de acesso. Como foi mostrado, usuários com o devido papel terão acesso as funcionalidades específicas no sistema. Ao efetuar o login, será detectado se o usuário tem acesso ao sistema.

Quanto à performance, os registros de diploma não poderão ser excluídos do sistema, pois é necessário que fiquem armazenados para consultas posteriores, geração de segunda via, entre outros.

Também será garantido que apenas usuários com privilégios de acesso de Gestor de Diploma poderão acessar o módulo e executar as funcionalidades, e ainda o sistema deverá ser acessado completamente via navegador web.

1.6 Gestão e Restrições Técnicas

Existem restrições que afetarão a maneira de conduzir o projeto por

exemplo os recursos limitados e datas de entrega inflexíveis. Aqui são apontadas as abordagens técnicas do desenvolvimento de software (processo de software utilizados, entre outros).

2.0 ESTIVAMIVAS DO PROJETO

Nesta seção, serão apresentadas as estimações de tempo necessário para a realização do projeto baseadas em dados, técnicas e recursos.

São Cristóvão

2016 5



2.1 Dados históricos utilizados para as estimações

Sendo este o primeiro projeto desta equipe, não existem dados históricos a serem utilizados para as estimações.

2.2 Técnicas de estimação e resultados

Para estimar o tempo é necessária a utilização de uma técnica de estimativa. A técnica escolhida em nosso projeto foi a de Lorenz & Kidd, Orientada a Objetos, adotada pela Lacertae Software.

2.2.1 Técnica de estimação

Para a utilização da técnica Lorenz & Kidd foi preciso primeiramente realizar uma contagem do total de classeschaves presentes no diagrama de classes de domínio. Classeschaves são classes do Diagrama de Classes de Domínio que estão diretamente ligadas com a regra de negócio, identificadas na elicitação dos requisitos.

Após definir o número de classeschave, é preciso classificar o tipo de interface para a aplicação, que poderá ter uma interface baseada em texto, ou uma interface gráfica de usuário convencional, ou uma interface gráfica de usuário complexa, ou até mesmo nenhuma interface gráfica. E cada tipo de interface está associada a um multiplicador (2,0 para nenhuma interface, 2,25 para interface baseada em texto, 2,5 para interface convencional e 3,0 para a interface complexa) que será utilizado para estimar o número de classes de apoio (suporte). Para obter o número estimado de classes de apoio basta calcular a multiplicação entre o número de classeschave e o valor multiplicador relacionado com a interface da aplicação.

Em seguida, será necessário multiplicar o número total de classes (classechave + classe de apoio) pelo número médio de unidades de trabalho por classe. Lorenz e Kidd surgerem 15 a 20 pessoasdia por classe. O resultado será a estimativa do tempo necessário para a realização do projeto.

São Cristóvão

2016 6



2.3 Resultados

Para a realização das estimações através da técnica de Lorenz & Kidd utilizamos o diagrama de Classes de Domínio na figura 2.1. Após a análise do diagrama e das considerações da técnica utilizada, foi possível obter as seguintes conclusões:

Figura 2 Diagrama de Classes de Dominíno

1. Quantidade de classes chave: 4 (ResgistroDiploma, ResponsavelAssinatura, ObservaçãoRegistroDiploma, RegistroEntrada);

2. Tipo das classes de suporte: interface concencional; 3. Valor Multiplicador: 2,5; 4. Classes de suporte: 4 (classes chave) x 2,5 (Valor multiplicador) = 10 classes de

suporte; 5. Total de classes: 4 (chave) + 10 (suporte) = 14; 6. Número médio de unidades de trabalho: 20 diaspessoa; 7. Tempo previsto: 14 (classes) x 20 (dias) = 280 dias por pessoa para a construção

das classes. Tendo em vista que a equipe é formada por 3 integrantes chegase ao total de aproximadamente 93 dias;

São Cristóvão

2016 7



8. Como um mês possui em média 22 dias úteis, feriados e pontos facultativos, o tempo total do projeto será de 4 meses e 5 dias.

2.3.1 Resultados no Projeto Real

Esse projeto foi executado no Núcleo de Tecnologia da Informação da Universidade Federal de Sergipe. Nesse projeto a equipe de desenvolvimento foi formada por cinco membros, como segue abaixo o cálculo de estimações.

1. Quantidade de classes chave: 4; 2. Tipo das classes de suporte: interface concencional; 3. Valor Multiplicador: 2,5; 4. Classes de suporte: 4 (classes chave) x 2,5 (Valor

multiplicador) = 10 classes de suporte; 5. Total de classes: 4 (chave) + 10 (suporte) = 14; 6. Número médio de unidades de trabalho: 20 diaspessoa; 7. Tempo previsto: 14 (classes) x 20 (dias) = 280 dias por

pessoa para a construção das classes.A equipe foi formada por 5 integrantes chegase ao total de aproximadamente 56 dias;

8. Como um mês possui em média 22 dias úteis, feriados e pontos facultativos, o tempo total do projeto será de 2 meses e 12 dias.

2.4 Recursos do projeto

Nesta secção serão especificados os recursos necessários para realização

do projeto. Os recursos foram divididos em 3 (três) categorias, humanos, de software e de hardware.

2.4.1 Recursos Humanos

Os profissionais necessários para o desenvolvimento deste projeto

são os seguintes: 01 Gerente de Projeto; 02 Analista de Sistemas; 01 Analista de Testes; 02 Programador; 02 Testador.

São Cristóvão

2016 8



Como a equipe só dispõe de apenas 3 (três) integrantes, alguns papéis terão incomum a mesma pessoa. 2.4.2 Recursos de Software

O projeto irá utilizar os seguintes recursos de software:

PostgreSQL: permitirá a gerência do banco de dados usado na

composição do produto final; Eclipse/Java: IDE e linguagem de programação a ser utilizada na

implementação do produto de software final; OpenOffice e Microsoft Word: editores de texto usados na

documentação, relatórios e documentos afins; Smart Sheet: gerenciador de projetos que servirá de base para

gestão atualizada e confiável do projeto do produto; SVN: ferramenta utilizada para o controle de versão a ser utilizado

para permitir desenvolvimento distribuído do software; StarUML: ambiente de modelagem dos diagramas UML; Mozila Firefox: navegador web; JBoss 4.2: servidor HTTP.

2.4.3 Recursos de Hardware

Deverão ser utilizados 3 estações de trabalhos com a seguinte configuração de hardware:

Processador Intel® Core™ i76500U Processor (4M Cache, up to

3.10 GHz) ou superior; 4 GB de memória RAM ou superior; 500 GB de armazenamento ou superior; 2 telas de 17 polegadas ou superior.

3.0 Análise e Gestão de Riscos

Nesta seção serão apresentados os possíveis riscos do projeto e como serão gerenciados.

São Cristóvão

2016 9

http://ark.intel.com/pt-br/products/88194/Intel-Core-i7-6500U-Processor-4M-Cache-up-to-3_10-GHz

http://ark.intel.com/pt-br/products/88194/Intel-Core-i7-6500U-Processor-4M-Cache-up-to-3_10-GHz



3.1 Riscos do projeto

Riscos Projeto Técnico Negócio Comum Especial

Não conseguir reutilizar o código desse projeto. x x

Cliente não tem muito tempo para levantamento de requisitos x Perda de algum dado do banco de dados x Problemas com Interação entre sistemas diferentes x x Perda de membros da equipe x x O produto pode ser alterado depois da entrega x Custos associados ao mal funcionamento da ferramenta utilizada no desenvolvimento

x

Expectativas não satisfeitas x Pouco treinamento da equipe x x Baixo conhecimento prévio dos usuários x x

Quadro 1 Riscos do projeto

3.2 Tabela de riscos

Tabela com os riscos identificados a sua probabilidade de ocorrência e impacto esperado.

São Cristóvão

2016 10



Riscos % Probabilidade Impacto

Não conseguir reutilizar o código desse projeto.

75% Catastrófico

Cliente não tem muito tempo para levantamento de requisitos

75% Catastrófico

Perda de algum dado do banco de dados

75% Catastrófico

Falta de conhecimento do negócio

75% Catastrófico

Problemas com Interação entre sistemas diferentes

30% Crítico

Perda de membros da equipe 30% Crítico

O produto pode ser alterado depois da entrega

30% Crítico

Custos associados ao mal funcionamento da ferramenta utilizada no desenvolvimento

10% Marginal

Ponto de corte

Expectativas não satisfeitas 10% Marginal

Pouco treinamento da equipe

10% Marginal

Baixo conhecimento prévio dos usuários

10% Marginal

Desenvolvedores não possuem tempo integral para desenvolvimento do produto

30% Crítico

São Cristóvão

2016 11



Quadro 2 Riscos do projeto identificando probabilidade 3.3 Redução e Gestão do Risco

Para garantir a Redução, Supervisão e Gestão dos Riscos (RSGR) foram utilizadas as seguintes estratégias.

1 Não conseguir reutilizar o código desse projeto.

Probabilidade: 75% Impacto: Catastrófico

Descrição: Haverá uma reutilização de código, pois esse sistema já existe aplicado a outros níveis de ensino.

Estratégia de Redução: Avaliação do módulo já implantado.

Plano de Contigência: Devese identificar as prioridades do projeto e negociar um prazo maior. O projeto também deve ser remodelado de acordo com as tecnologias dominadas pelos integrantes.

Responsável: Daiana Joyce

Status: Em andamento

Quadro 3 Estratégia de redução e gestão de risco

2 Cliente não tem muito tempo para levantamento de requisitos


Descrição: Cliente não tempo muito tempo disponível para discutir os requisitos do projeto.

Estratégia de Redução: Prepararse bem para a entrevista, gravála para consultas futuras e seguir notas e depoimentos no projeto.

Plano de Contigência: Solicitar ao cliente que indique uma pessoa disponível para esta etapa do projeto. Esta pessoal deve conhecer o negócio e saber expressar o que o

São Cristóvão

2016 12



cliente deseja.

Responsável: Matheus



3 Problemas com Interação entre sistemas diferentes

Probabilidade: 30% Impacto: Crítico

Descrição: O módulo Diploma deverá comunicarse diretamente com o módulo Lato Sensu.

Estratégia de Redução: Realizar uma ampla gama de testes para garantir o funcionamento correto.

Plano de Contigência: Corrigir as falhas detectadas na fase de testes.

Responsável: Mike



4 Perda de membros da equipe


Descrição: Há apenas 3 pessoas envolvidas no projeto e não há garantia que todos permaneçam até o final do projeto

Estratégia de Redução: Integrantes devem se reunir regularmente para que possam acompanhar o trabalho um do outro. Além disso, devem compartilhar os artefatos disponíveis e resultados atingidos para que possam motivar os integrantes a permanecerem no projeto até o final.

Plano de Contigência: Caso um integrante saia, devese identificar as prioridades do projeto, negociar um prazo maior com a promessa de entregar incrementos neste período.

São Cristóvão

2016 13






5 O produto pode ser alterado depois da entrega


Descrição: Ápos a entrega o cliente pode solicitar mais alterações que estão fora do escopo.

Estratégia de Redução: Criar protótipo para validar os requisitos e também criar um Documento de Escopo, acordando tudo que será entregue no projeto.

Plano de Contigência: Ampliar o escopo, redefinindo prazos e valores do projeto.




6 Custos associados ao mau funcionamento das ferramentas utilizadas no desenvolvimento

Probabilidade: 10% Impacto: Marginal

Descrição: Peda de tempo útil ocasionada por problemas (configuração ou mal funcionamento) acasionados por ferramentas utilizadas no desenvolvimento do produto de software.

Estratégia de Redução: Pesquisar, analisar e testar a utilização destas ferramentas em projetos de terceiros, quais os prós e possíveis contras.

Plano de Contigência: Suspender a utilização da ferramenta e se possível passar a utilizar outra semelhante.

Responsável: Mike

Status: Em Andamento

São Cristóvão

2016 14




7 Expectativas não satisfeitas


Descrição: Apesar do acompanhemento do cliente no densevolvimento do produto de sofware, o mesmo pode não ficar satisfeito com o que foi entregue.

Estratégia de Redução:Verificar quais são as expectativas do cliente, e separálas por nível de importância e buscar sempre alcançar as mais importantes.

Plano de Contigência: Buscar no próximo projeto satisfazer as expectativas do cliente.




8 Perda de algum dado do banco de dados.


Descrição: Possibilidade de haver alguma falha no banco de dados e perder dados importantes.

Estratégia de Redução: Utilizar espelhamento de banco de dados.

Plano de Contigência: Fazer uso periódico de backup

Responsável: Mike

Status:Em andamento


9 Pouco treinamento da equipe

São Cristóvão

2016 15




Descrição: Integrantes não possuem treinamento necessário

Estratégia de Redução: Utilizar cursos online, fóruns na internet e orientação de profissionais da área

Plano de Contigência: Contratar cursos e treinamento para os integrantes




10 Baixo conhecimento prévio dos usuários


Descrição: A equipe não tem conhecimeno prévio dos usuários.

Estratégia de Redução: A equipe deve manter contato com os usuáris ápos as reuniões, para se necessário sanar qualquer dúvida, mesmo antes das reuniões definidas.

Plano de Contigência: Aumentar o número de reuniões.

Responsável: Mike



11 Desenvolvedores não possuem tempo integral para desenvolvimento do produto


Descrição: Integrantes realizam outras atividades e não podem se dedicar exclusivamente ao projeto.

Estratégia de Redução: Evitar desperdício de tempo e recursos

São Cristóvão

2016 16



Plano de Contigência: Fazer bom uso do tempo disponível e utilizar ferramentas de nuvem que possibilitem alterações por múltiplas pessoas em tempo rel.




12 Falta de conhecimento do negócio

Probabilidade: 75% Impacto: Ctastrófico

Descrição: Negócio do projeto é desconhecido por todos os integrantes

Estratégia de Redução: Estudar a respeito do negócio e motivar a participação do cliente no projeto.

Plano de Contigência: Contatar o cliente sempre que necessário

Responsável: Mike


Quadro 14 Estratégia de redução e gestão de risco 4.0 Planejamento Temporal

Nesta seção serão apresentadas as tarefas e as suas dependências estimando a duração total do projeto.

4.1 Conjunto de Tarefas do Projeto

No desenvolvimento do módulo Diploma, para o nível de ensino Lato Sensu, foi utilizado o modelo de processo incremental e iterativo, utilizando a metodologia ágil Scrum.

As tarefas do projeto podem ser visualizadas nas seções 1.2 e 1.3, Funções principais do produto de software e Diagrama de Caso de Uso, respectivamente.

São Cristóvão

2016 17



4.2 Diagrama de Gantt

O diagrama de Gant tem como objetivo disponibilizar aos membros da equipe todo o planejamento do projeto, considerando prazos e atribuições, de forma visual e de fácil compreensão.

O desenvolvimento do diagrama de gantt do projeto foi baseada na metodologia Scrum, a mesma metodologia utilizada na execução do projeto. O tempo estimado para cada etapada do projeto não foi baseada na estimativa 4/2/4 (RequisitosAnáliseDesenho 40% / Geração de Código 20% / Testes 40%) sugerida pela literatura de Engenharia de Software, por dois motivos discutidos entre os membros da equipe:

O uso da metodologia Scrum, na qual o desenvolvimento de software visa o atendimento das necessidades do cliente e realizar entregas do projeto em partes(sprints) para validação do cliente, que pode resultar em mudanças no planejamento; e

Considerando a experiência no mercado em desenvolvimento dos membros da equipe, na qual o tempo gasto no desenvolvimento do software sempre demanda mais tempo que todas as outras etapas.

A figura 1, apresenta as 4 etapas planejadas para execução e finalização do

projeto: Planejamento, Especificação do Projeto, Desenvolvimento e Transição. Em cada etapa, são descritas as tarefas que devem ser executadas, os membros da equipe responsáveis pela execução, data início e data fim para execução, total de dias para execução da tarefa e ao lado uma linha do tempo de execução da tarefa dentro dos prazos definidos para cada tarefa.

A linha do tempo citada anteriormente, que caracteriza um diagrama de gantt, tem início no dia 20 de janeiro de 2016 e encerra no dia 25/05/2016, tempo estimado para execução e finalização do projeto.

Para preservar a legibilidade do diagramas, a linha temporal não foi apresentada completamente. Mas a Figura 1, Figura 2 e diagrama completo

São Cristóvão

2016 18



podem ser acessados através do link: https://drive.google.com/folderview?id=0B8yfhL4YTZTGdFJKdXNsSGZYSHc&usp=sharing .

Figura 1 Diagrama de Gantt Resumido. Farias, Mike (2016).

A figura 2, apresenta as 4 sprints, apresentadas anteriormente, de forma expandida. Cada sprint possue suas respectivas tarefas e um tempo médio de execução de 17 dias.

São Cristóvão

2016 19

https://drive.google.com/folderview?id=0B8yfhL4YTZTGdFJKdXNsSGZYSHc&usp=sharing

https://drive.google.com/folderview?id=0B8yfhL4YTZTGdFJKdXNsSGZYSHc&usp=sharing



Figura 2 Diagrama de Gantt Expandido. Farias, Mike (2016). 5.0 Organização do Pessoal

Nesta seção será apresentada a forma de distribuição dos recursos humanos no projeto e qual a função das pessoas envolvidas de acordo com o perfil necessário para o seu desempenho.

5.1 Estrutura da equipe

Para execução do projeto contaremos com a participação de 3 (três) integrantes que desempenharão papéis necessários para garantir o andamentos e o sucesso final do projeto. Abaixo veremos a tabela 4.1, onde são descritas as responsabilidades de cada papel, seu responsável e o perfil necessário para ocupar este papel.

São Cristóvão

2016 20



Responsável Papel Descrição Perfil

Daiana Joyce Gerente de Projeto

Responsável pela alocação de recursos, ajuste de prioridades, coordenação das interações entre clientes e usuários, manter o foco da equipe na meta, e acompanhar as atividades executadas pela equipe do projeto.

Possuir experiência em gerência de projetos, análise, gerenciamento de riscos, estimativas e planejamento.

Ter bom relacionamento interpessoal.

Possui capacidade de liderança.

Matheus Costa e Mike Santos

Analista de Sistemas

Responsável pelo levantamento de requisitos e atividades de análise e projeto no qual irá elaborar todos os diagramas necessários para a implementação (codificação) do produto de software.

Ter bom conhecimento do negócio.

Comunicarse bem.

Daiana Joyce Analista de Testes

Responsável por identificar e definir os teste necessários, monitorar a abrangência dos testes e avaliar a qualidade obtida ao realizar os testes.

Ser atencioso e detalhista. Conhecer bem o domínio

do produto de software. Possuir exepriência em

esforços de teste.

Matheus Costa e Mike Santos

Programador Responsável pela implementação do produto de software.

Possuir experiência em coficiação.

Matheus Costa e Daiana Joyce

Testador Responsável pela realização dos testes sistémicos.

Possuir experiência em testes.

Tabela 4.1 5.2 Mecanismos de comunicação

A comunicação foi por meio de reuniões semanais entre os membros da

equipe. Estas reuniões serviram para discutir o andamento do projeto. Entre cada reunião, qualquer dúvida em relação ao projeto deverá ser exposta por meio de

São Cristóvão

2016 21



um grupo de email a ser criado pela gerente do projeto e composto por todos os membros da equipe.

5.3 Uso do Edublog como ferramenta de apoio

A utilização do Edublog fez com que nossa equipe compreendesse as principais metodologias ágeis que são utilzidas diariamente por várias empresas. E a partir deste aprendizado adquirido tentamos encaixálo na execução deste projeto.

O Edublog facilitou também na interação entre nossa equipe e as outras esquipes da disciplina, fazendo com que adiquiríssemoos conhecimento sobre os assuntos abordados pelas outras equipes. Como por exemplo, a utilização de ferramentas para o gerenciamento de um projeto, ou a utilização da computação em nuvem para auxiliar no desenvolvimento de um produto de software.

Este jeito fácil e empolgante de aprender sobre outros assuntos de diversas áreas por meio de uma ferramenta deste tipo só veio a somar no aprendizado desta equipe.

6.0 Precauções tomadas para assegurar e controlar a qualidade do produto de software

Dentre as medidas utilizadas para assegurar e controlar a qualidade do produto de SW, destacamse a utilização da ferramenta SVN para controle de versão e a utilização de conceitos presentes na metodologia ágil Scrum.

A ferramenta SVN foi utilizada para garantir o controle de todas as versões do produto e para o trabalho em conjunto de toda a equipe.

Na utilização de conceitos presentes no Scrum, foi possível interagir de forma efetiva com o cliente, desde a análise de requisitos até a validação das 4 sprints (partes entregáveis do produto de sw). Cada sprint passou por revisão, testes e validação do usuário.

São Cristóvão

2016 22



São Cristóvão

2016 23

PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW

Software

Transcript of PLANO DE PROJETO DE SOFTWARE para produtos da Lacertae SW