plano de projeto de software - sisconi

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

DEPARTAMENTO DE COMPUTAÇÃO Gerência de Projetos 2013.2

PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW

GRUPO 3

Felipe Oliveira Carvalho Ramon Batista Ramos

Rodrigo Losano Fontes Calheiros Washington Cavalcante da Silva

São Cristóvão – Sergipe 2014

Felipe Oliveira Carvalho Ramon Batista Ramos

Rodrigo Losano Fontes Calheiros Washington Cavalcante da Silva

PLANO DO PROJETO DE SOFTWARE PARA PRODUTOS DA LACERTAE SW

Trabalho apresentado ao Prof. Dr. Rogério Patrício Chagas do Nascimento como parte avaliativa da disciplina Gerência de Projetos do Curso de Graduação em Sistemas de Informação da Universidade Federal de Sergipe – UFS.

São Cristóvão – Sergipe 2014

Sumário

1. INTRODUÇÃO.................................................................................................................... 4

1.1 Âmbito do Projeto ...................................................................................................... 4

1.2 Funções principais do produto de software ............................................................ 4

1.3 Requisitos comportamentais ou de performance ................................................... 5

1.4 Gestão e Restrições Técnicas .................................................................................. 6

2. ESTIMATIVAS DO PROJETO ............................................................................................ 6

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

2.2 Técnicas de estimação e resultados ........................................................................ 7

2.3 Resultados ................................................................................................................. 8

2.4 Recursos do projeto .................................................................................................. 9

2.4.1 Recursos Humanos ............................................................................................ 9

2.4.2 Recursos de Software .......................................................................................11

2.4.3 Recursos de Hardware ......................................................................................12

3. ANÁLISE E GESTÃO DE RISCOS ...................................................................................12

3.1 Riscos do projeto ......................................................................................................12

3.2 Tabela de riscos ........................................................................................................14

3.3 Redução e Gestão do Risco .....................................................................................16

4. PLANEJAMENTO TEMPORAL ........................................................................................21

4.1 Conjunto de Tarefas do Projeto ...............................................................................21

4.2 Diagrama de Gantt ....................................................................................................21

5. ORGANIZAÇÃO DO PESSOAL ........................................................................................23

5.1 Estrutura da equipe ..................................................................................................23

5.2 Mecanismos de comunicação ..................................................................................25

5.3 Uso do Edu-blog como ferramenta de apoio ..........................................................25

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO

PRODUTO DE SOFTWARE .....................................................................................................25

7. ANEXOS............................................................................................................................27

1. INTRODUÇÃO

1.1 Âmbito do Projeto

O SISCONI (Sistema de Controle de Internação) foi desenvolvido em 2012 com

o objetivo de auxiliar o processo de Internação do Hospital Universitário da

Universidade Federal de Sergipe. Além de auxiliar esse processo, ele também atua

como fonte de informações estatísticas e históricas para os processos de tomada de

decisão na gerência do hospital.

Com o SISCONI é possível agilizar o processo de internação, manter

centralizadas as informações referentes aos leitos do hospital, manter um cadastro de

pacientes e informações à respeito de suas internações. Permite também o

remanejamento de leitos, além do controle de altas dadas pelos médicos aos pacientes

internados.

Através das Figuras 1.1 e 1.2 mostradas no anexo (seção 7) deste documento

é possível observar respectivamente os diagramas de classe do domínio do projeto e o

digrama do modelo lógico do banco de dados. Com estes digramas é possível obter

uma abstração da estrutura do sistema.

1.2 Funções principais do produto de software

O sistema desenvolvido é composto de diversas funcionalidades. Todas elas

com maior ou menor importância dentro do projeto, mas que juntas formamo software

necessário para a atividade do cliente.

As principais funcionalidades com seus respectivos usuários serão detalhadas

na Tabela 01 abaixo.

Funcionalidade Usuários

Cadastrar os dados de pacientes a serem

internados

Atendente

Localizar dados de pacientes; Atendente

Atualizar dados de pacientes Atendente

Verificar o histórico de internações de um

paciente

Atendente

Cadastrar um leito Gestor

Bloquear um leito Gestor

Desbloquear um leito Gestor

Liberar um leito Atendente

Verificar a ocupação dos leitos Atendente

Iniciar uma internação Atendente

Agendar uma internação Atendente

Dar alta a um paciente Médico

Remanejar uma internação Gestor, Médico

Encerrar uma internação Atendente

Cancelar um agendamento de internação Atendente

Efetuar login no sistema Atendente, Médico, Gestor

Gerar estatísticas de ocupação dos leitos Gestor

Tabela 01 – Funcionalidades e Usuários do SISCONI.

1.3 Requisitos comportamentais ou de performance

Para que o SISCONI possa atender de forma eficiente aos seus usuários, o

sistema deve:

1. Ser fácil de usar, possuindo uma linguagem de acordo com o ambiente do

negócio.

2. Ser capaz de estar funcionando a todo momento (próximo às 24 horas do

dia).

3. Todos os possíveis usuários do SISCONI deverão ter acesso restrito às

funcionalidades que lhe são cabíveis, mediante um código de acesso e

uma senha.

4. As informações disponibilizadas pelo SISCONI deverão ser íntegras e

passíveis de auditoria.

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

As restrições técnicas que definem o escopo do SISCONI são:

1. O Sistema de Gerenciamento de Banco de Dados utilizado pelo SISCONI

será o MySQL.

2. A linguagem de programação a ser utilizada será a JAVA.

3. Todas as máquinas do Hospital Universitário devem possuir um browser

web para o acesso ao SISCONI.

4. O funcionamento do SISCONI depende de uma infraestrutura de rede

intranet entre os diversos computadores que o utilizarão.

2. ESTIMATIVAS DO PROJETO

Serão descritas nesta seção, as etapas utilizadas para calcular o tempo total de

execução deste projeto. Para isso, a métrica de Lorenz&Kidd será aplicada a fim de

estimar o esforço em termos de dias por pessoa.

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

Este é o primeiro projeto desenvolvido pela equipe, não existindo assim, dados

históricos para balizar as estimativas dos cálculos.

2.2 Técnicas de estimação e resultados

Como descrito anteriormente, neste projeto será utilizada a métrica de

Lorenz&Kidd para o cálculo do tempo de execução do projeto. Esta técnica leva em

consideração as classes que serão construídas no projeto. Assim, as seguinte etapas

serão utilizadas para essa estimação:

1. Com base no diagrama de classes de domínio, determinam-se as classes-chave

do projeto.

2. Classifica-se o tipo de interface do produto e desenvolve-se um multiplicador

para encontrar o número de classes de suporte. Para isso, são usadas as

informações contidas na Tabela 02.

Interface Multiplicador

Interface não gráfica 2

Baseada em texto 2,25

GUI 2,5

GUI complexa 3

Tabela 02 - Interface x Multiplicador.

3. Calcula-se o produto entre o número de classes-chave pelo multiplicador

selecionado na etapa anterior, encontrando assim o número de classes de

suporte.

4. Calcula-se o total de classes do projeto (classes-chave + classes de suporte)

5. Determinam-se os dias por pessoa necessários para construção de uma única

classe.

6. Multiplica-se a quantidade total de classes (chave mais suporte) pelo fator

encontrado na etapa anterior, encontrando assim a quantidade que uma pessoa

levaria para a desenvolvimento do projeto, ou seja, o esforço estimado.

7. Por fim, calcula-se o tempo necessário (previsto) para o desenvolvimento do

projeto.

2.3 Resultados

Através da aplicação da técnica de Lorenz &Kidd, os seguintes cálculos e

resultados foram obtidos:

1. Após a análise do diagrama de classes de domínio, o número de classes-chave

encontrado foi de 8 classes.

2. Devido a sua natureza, a interface do sistema foi considerada apenas como

GUI, recebendo como multiplicador o valor 2,5.

3. Foi determinado o número de classes de suporte, tendo como base o

multiplicador escolhido na etapa anterior. Assim, multiplicando 8 x 2,5 obteve-se

um total de 20 classes de suporte.

4. O número de total de classes (chave + suporte) é de 28 classes.

5. Como não há registros históricos anteriores, usa-se como base a sugestão da

técnica de Lorenz &Kidd (15 a 20 dias/pessoa). Assim, determinou-se 15

dias/pessoa para o desenvolvimento de uma única classe.

6. Tendo como parâmetro 15 dias/pessoa para o desenvolvimento de uma classe,

calcula-se 15 x 28, totalizando-se 420 dias/pessoa para a consecução do

sistema.

7. Tendo em vista que o projeto é composto por 4 (quatro) integrantes, chega-se

ao total de 105 dias para o desenvolvimento do projeto.

Considerando as porcentagens de distribuição de componentes essenciais no

projeto, sugeridas pelas diretrizes da Lacertae Software, os 105 dias estimados para o

desenvolvimento do projeto são distribuídos nas respectivas fases do projeto,

mostradas na Tabela 03.

Fase Estimativa Dias de Trabalho

Planejamento 3% 105 x 3% = 3 dias

Análise e Projeto 20% 105 x 20% = 21 dias

Geração de Código 40% 105 x 40% = 42 dias

Testes 37% 105 x 37% = 39 dias

Tabela 03–Estimativa dos dias de trabalho por fase do projeto.

O resultado obtido nessa estimativa aproximou-se a realidade do que ocorreu no

projeto. Quando desenvolvido, o projeto foi executado em 240 dias, sendo que haviam

duas pessoas no desenvolvimento. Isso dá um total 480 dias por pessoa.

2.4 Recursos do projeto

Os recursos utilizados no projeto serão explanados nas sessões abaixo. Eles se

subdividem em Recursos Humanos, Recursos de Software e Recursos de Hardware.

2.4.1 Recursos Humanos

Com o objetivo de manter o bom relacionamento e a interatividade da equipe,

será utilizada a Scrum como metodologia ágil de gerenciamento do projeto. Além disso

será utilizada a XP como metodologia ágil de desenvolvimento que tem como

característica principal a programação em pares. Com o objetivo de envolver todos os

integrantes em todas as áreas da construção do software, o cronograma será dividido

em quatro fases, onde todos passarão por todos os papéis, como segue nas Tabelas

04a a 04d abaixo.

Sprint 1 Período: 13/01/2014 à 07/02/2014

Scrum Master Washington Silva

Developer 1 Rodrigo Calheiros

Developer 2 Felipe Carvalho

Tester Ramon Ramos

Tabela 04a–1ª Sprint de desenvolvimento.

Sprint 2 Período: 10/02/2014 à 07/03/2014

Scrum Master Ramon Ramos

Developer 1 Washington Silva

Developer 2 Rodrigo Calheiros

Tester Felipe Carvalho

Tabela 04b–2ª Sprint de desenvolvimento.

Sprint 3 Período: 10/03/2014 à 04/04/2014

Scrum Master Felipe Carvalho

Developer 1 Ramon Ramos

Developer 2 Washington Silva

Tester Rodrigo Calheiros

Tabela 04c–3ª Sprint de desenvolvimento.

Sprint 4 Período: 07/04/2014 à 25/04/2014

Scrum Master Rodrigo Calheiros

Developer 1 Felipe Carvalho

Developer 2 Ramon Ramos

Tester Washington Silva

Tabela 04d –4ª Sprint de desenvolvimento.

2.4.2 Recursos de Software

Para a construção do software serão utilizados alguns outros softwares que

auxiliarão no processo de desenvolvimento. Dentro de um conjunto de softwares estão

contidos editor de texto, servidor HTTP, máquina virtual, IDE de Desenvolvimento,

entre outros.

Apache Tomcat 7.0 - Servidor HTTP produzido pela Apache e distribuído como

software livre.

Java - Linguagem de programação utilizada no desenvolvimento do projeto.

JRE - Máquina virtual Java.

Eclipse Java EE IDE Kepler - IDE de codificação do software.

Astah - Ambiente de modelagem dos diagramas UML.

Microsoft Office Word –Editor de texto para a documentação do software.

Open Project - Ambiente de gerenciamento e criação de cronogramas a serem

executados durante o processo de desenvolvimento do software.

Google Drive - Software de armazenamento em nuvem.

GIT- Sistema livre de controle de versão.

GitHub - Armazenamento em nuvem do controle de versão implementado pelo

GIT.

2.4.3 Recursos de Hardware

Com o objetivo de centralizar os artefatos gerados no processo de

desenvolvimento do software serão utilizados os serviços disponíveis na nuvem como

Google Drive para o armazenamento da documentação do software, como também os

diagramas gerados ao decorrer do desenvolvimento. O controle de versão será

apoiado peloGitHub. Sendo assim, os computadores pessoais de cada membro da

equipe seriam os únicos hardwares diretos necessários.

3. ANÁLISE E GESTÃO DE RISCOS

Um risco é um problema em potencial, ou seja, um problema com certa

probabilidade de acontecer que pode afetar de diversas formas o andamento do

projeto.

Todo projeto está sujeito a determinados riscos. Cada risco tem um percentual

de chance de acontecer (sendo uns com maior e outros com menor possibilidade de

ocorrência), e um determinado impacto sobre o projeto. É preciso conhecê-los e

determinar as formas de minimizar a probabilidade de sua ocorrência, bem como o seu

impacto, caso ele venha a acontecer.

3.1 Riscos do projeto

Os riscos de um projeto podem ser distinguidos em riscos gerais (comuns a todo

projeto) e riscos específicos (únicos de cada projeto). Os riscos gerais são listados na

Tabela 05 abaixo

Risco Projeto Técnico Negócio Comum Especial

Equipamento não disponível X

Requisitos incompletos X X

Uso de metodologias especiais X X

Problemas na busca da confiabilidade requerida

X X

Retenção de pessoas chaves X X

Subestimativas do esforço X X

Tabela 05–Riscos gerais de um projeto de software.

Avaliação global dos riscos:

1. O Gestor de Software dá suporte ao projeto?

Sim. O gestor de software tem um papel importante para o bom andamento do

projeto, e seu apoio tem sido fundamental durante a consecução do trabalho.

2. Os Clientes estão entusiasmados com o projeto e o produto?

O cliente está muito interessado no produto pois a ferramenta automatizará o

atual processo de controle dos leitos, o que evitará os frequentes erros

incorridos pelo processo manual de trabalho.

3. Os Engenheiros de Software compreenderam bem os requisitos?

Sim, os engenheiros compreendem bem os requisitos do projeto, pois estão

participando desde o início do trabalho.

4. Os Clientes estiveram envolvidos na definição dos requisitos?

Sim. Devido ao grande interesse no sistema, eles estiveram evolvidos durante a

definição dos requisitos.

5. O âmbito do projeto é estável?

Sim.

6. Os engenheiros de Software têm as competências requeridas?

Apesar de pouco experientes, os Engenheiros de Software tem como principal

objetivo a busca por novas experiências e, consequentemente, o aumento de

suas competências.

7. Os requisitos do projeto são estáveis?

Os requisitos foram bem definidos no início do trabalho, porém algumas

alterações foram solicitadas para melhor desenvolvimento do produto. A

metodologia utilizada para o desenvolvimento do software visa lidar com essas

mudanças de maneira que não impacte tanto no desenvolvimento do trabalho.

8. A Equipe de Desenvolvimento tem experiência na tecnologia a

implementar?

Não, poucos membros da equipe tem um boa experiência técnica profissional, já

a maioria tem apenas experiência em desenvolvimento de trabalhos

acadêmicos.

9. É adequado o número de pessoas da equipe de trabalho?

Não. Apesar de o sistema não ser tão grande, é necessária a presença de mais

uma pessoa na equipe, desde que esta seja experiente, devido à falta de

experiência da equipe atual.

3.2 Tabela de riscos

Para o desenvolvimento do software, alguns riscos foram identificados e

classificados quanto a sua probabilidade e seu impacto no projeto. A Tabela 06

demostra os riscos com seus valores de probabilidade associados. Foi definido um

ponto de corte abarcando os riscos moderados com probabilidade de ocorrência maior

ou igual a 50%.

Nome do risco Probabilidade Impacto

Desistência do cliente 10% Catastrófico

Poucos programadores no

desenvolvimento

80% Crítico

Requisitos mal compreendidos 60% Crítico

Ausência de inspeções no processo de

software.

50% Crítico

Custos associados a um Produto

defeituoso

30% Crítico

Ausência de ferramentas CASE

adequadas para testes de software

80% Moderado

Dedicação integral dos

desenvolvedores ao projeto

50% Moderado

Atraso na entrega 50% Moderado

Ponto de corte

Disponibilidade do cliente para o

desenvolvimento

30% Moderado

Falta de treinamento da equipe nas

ferramentas de desenvolvimento

20% Moderado

Grande número de classes 20% Moderado

Restrições governamentais 30% Marginal

Grande volume de dados 25% Marginal

Manutenção associada às tecnologias e 20% Marginal

ferramentas livres

Grande número de usuários 15% Marginal

Ausência de integração das

ferramentas de desenvolvimento

50% Desprezível

Tabela 06–Tabela de riscos específicos.

3.3 Redução e Gestão do Risco

Deve-se garantir a redução da probabilidade dos riscos identificados na seção

anterior, bem como seu impacto em caso de ocorrência. Nas Tabelas 07a a 07h serão

descritas as formas de redução além do plano de contingência necessário em caso de

ocorrência.

1. Desistência do Cliente

Probabilidade: 10% Impacto: Catastrófico

Descrição: Insatisfação do cliente com o andamento do projeto ou

desinteresse pode levá-lo a desistir do projeto.

Estratégia de redução: Envolver o cliente em todas as fases do projeto,

para que ele se sinta parte importante no processo de desenvolvimento,

mostrando sempre a evolução do software.

Plano de contingência:Fazer a prospecção de novos clientes durante o

desenvolvimento do projeto

Responsável: Washington Silva

Status: Iniciado

Tabela 07a–Estratégia de redução de riscos em caso de desistência do cliente.

2. Poucos programadores no desenvolvimento

Probabilidade: 80% Impacto: Crítico

Descrição: O número de programadores no desenvolvimento do projeto

deste software é pequeno.

Estratégia de redução: Melhorar a produtividade dos programadores

através de incentivos financeiros e pessoais ou contratar mais alguns

programadores.

Plano de contingência: Fazer com que os programadores alocados para

o projeto participem somente deste projeto. Não iniciar projetos novos.

Responsável: Felipe Carvalho

Status: Iniciado

Tabela 07b–Estratégia de redução de riscos em caso de haverem poucos programadores.

3. Requisitos mal compreendidos


Descrição: Diferentes stakeholderstêm em mente diferentes requisitos e

podem expressá-los de maneiras distintas.

Estratégia de redução: Combinar o uso das mais diversas técnicas de

elicitação no processo de descoberta dos requisitos pelosstakeholders.

Plano de contingência: Analisar com os stakeholders os artefatos

oriundos da elicitação dos requisitos e encontrar os pontos comuns e os

pontos conflitantes.

Responsável: Ramon Ramos

Status: Em andamento

Tabela 07c–Estratégia de redução de riscos em caso de ocorrência de requisitos mal

compreendidos.

4. Ausência de inspeções no processo de software


Descrição: A inspeção de software pode não ser executada, geralmente,

devido a atrasos no cronograma.

Estratégia de redução: Não saltar etapas do processo de software

estabelecido na Organização. O processo de software deve ser seguido.

Plano de contingência: Intensificar os testes de sistema.

Responsável: Ramon Ramos


Tabela 07d–Estratégia de redução de riscos em caso de ausência de inspeções no processo

de software.

5. Custos associados a um produto defeituoso


Descrição: Qualquer software possui erros. Com isso, as correções deles

são custosas a depender de quando são encontrados. Além disso eles

podem gerar grandes prejuízos a instituição usuária do software.

Estratégia de redução: Enfatizar a fase de teste no processo de

desenvolvimento de software. A equipe de teste deve testar

exaustivamente o software sempre procurando pelos erros.

Plano de contingência: Focar a equipe desenvolvedora do software na

resolução do erro.

Responsável: Rodrigo Calheiros


Tabela 07e–Estratégia de redução de riscos em caso de ocorrência de custos associados a um

produto defeituoso.

6. Ausência de ferramentas CASE adequadas para testes de software

Probabilidade: 80% Impacto: Moderado

Descrição: O processo de gerar testes automatizados auxilia na produção

de um software com mais qualidade. Neste contexto, a ausência de

ferramentas CASE que dão suporte a essa atividade obriga a execução de

testes manuais exaustivos.

Estratégia de redução: Ter um enfoque na fase de testes, elaborando

casos de teste que abranjam as possíveis entradas e combinações de

entradas do software.

Plano de contingência: Terceirizar o processo de testes do software.

Responsável: Felipe Carvalho


Tabela 07f–Estratégia de redução de riscos em caso de ausência de ferramentas CASE para

testes de software.

7. Dedicação integral dos desenvolvedores ao projeto


Descrição: A maioria dos integrantes não tem como se dedicar

exclusivamente para o projeto, principalmente por questões de

compatibilidade de horário com outros afazeres.

Estratégia de redução: Tentar adequar o trabalho de cada um com o seu

tempo disponível, sem que isto afete seu tempo de lazer. As atribuições de

cada membro serão dividas de forma a não onerar o seu tempo de

disponibilidade nem atrasar o andamento do projeto.

Plano de contingência:Promover uma melhor remuneração e motivação

aos desenvolvedores

Responsável: Washington Silva


Tabela 07g–Estratégia de redução de riscos em caso de ausência de dedicação integral dos

desenvolvedores ao projeto.

8. Atraso na entrega


Descrição: É comum o atraso na entrega do software. Entretanto é algo

que não deve acontecer. Esse é um risco que pode levar a

descredibilidade da empresa desenvolvedora além de caracterizar uma

quebra de contrato.

Estratégia de redução: Planejar o desenvolvimento do software levando

em conta todas as possíveis eventualidades, além de estimar com uma

margem o tempo do desenvolvimento. Com esse planejamento a equipe

deve seguir o cronograma e assim cumprir as atividades no tempo correto.

Plano de contingência: Focar a equipe no projeto sem dispersar com

outras atividades.

Responsável: Rodrigo Calheiros

Status: Iniciado

Tabela 07h–Estratégia de redução de riscos em caso de atraso na entrega.

4. PLANEJAMENTO TEMPORAL

Nesta seção, são definidas as datas de execução das tarefas, bem como seus

responsáveis. Para descrever esse aspecto temporal, foi elaborado o Diagrama de

Gantt.

4.1 Conjunto de Tarefas do Projeto

O modelo de ciclo de vida usado foi o processo iterativo incremental. Assim, as

atividades de planejamento, levantamento de requisitos, análise, projeto, codificação e

testes são executadas continuamente durante todo o ciclo de vida de desenvolvimento

do software.

4.2 Diagrama de Gantt

O cronograma extraído do diagrama de Gantté mostrado na Figura 01.

Figura 01 – Cronograma do diagrama de Gantt.

Uma visão mais detalhada do diagrama de Gantt pode ser vista no blogue da

equipe FRRW Gerência: http://frrw-gerencia.blogspot.com.br/2014/01/diagrama-de-

gantt-do-sisconi.html

5. ORGANIZAÇÃO DO PESSOAL

Apesar da existência do gestor do projeto, toda decisão a respeito do trabalho é

compartilhada com todos os envolvidos. Além disso, a equipe foi estruturada em papeis

para melhor condução do projeto.

5.1 Estrutura da equipe

O projeto será desenvolvido através de um processo iterativo e incremental.

Dessa forma, foi preciso definir os papéis envolvidos no projeto, bem como o perfil

necessário para o seu desempenho. Assim, os seguinte papeis e critérios foram

especificados:

Gerente de Projetos

Será o responsável pela alocação de recursos, ajuste de prioridades,

coordenação das interações entre clientes e usuários, e manter o foco da equipe na

meta. O gerente de projeto também estabelece um conjunto de práticas que garantem

a integridade e a qualidade dos artefatos do projeto. Para esse papel, algumas

habilidades são de grande valia.Por exemplo experiência anterior em gerência de

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

análise de decisões. Saber se apresentar e se comunicar de forma clara, ter a

capacidade de liderança, bom relacionamento interpessoal e boa capacidade de

gerenciamento de tempo também foram verificados.

Arquiteto de Software

http://frrw-gerencia.blogspot.com.br/2014/01/diagrama-de-gantt-do-sisconi.html

http://frrw-gerencia.blogspot.com.br/2014/01/diagrama-de-gantt-do-sisconi.html

Este papel tem como objetivo liderar e coordenar as atividades e os artefatos

técnicos no decorrer do projeto. Além disso, o arquiteto de software estabelece a

estrutura geral de cada visão de arquitetura: a decomposição da visão, o agrupamento

dos elementos e as interfaces entre esses principais agrupamentos. Para esse papel,

contam as habilidades como grande conhecimento geral, maturidade, visão e profunda

experiência que permita identificar problemas rapidamente.

Analista de Sistemas

Terá a responsabilidade de liderar e coordenar a equipe na identificação de

requisitos e na modelagem de casos de uso, delimitando o sistema e definindo sua

funcionalidade. Como critério para escolha do integrante para este papel, qualidades

como bom conhecimento do negócio e facilidade de comunicação foram observadas.

Analista de Teste

Será o responsável por identificar e definir os testes necessários, monitorar a

abrangência dos testes e avaliar a qualidade obtida ao realizar os testes. Além disso,

será responsável por desenvolver e testar componentes de acordo com os padrões

adotados para o projeto, para fins de integração com subsistemas maiores. Para esse

papel, foram observados as seguintes habilidades: boa habilidade analítica, atenção

aos detalhes e tenacidade, entendimento de falhas de software comuns, conhecimento

do domínio, conhecimento do sistema ou aplicativo em teste e experiência em vários

esforços de teste.

Com base nos papéis e habilidades descritas anteriormente, a alocação da

equipe se dará como especificado na Tabela 08.

Papel Integrante

Gerente de Projetos Washington Silva

Analista de Sistemas Felipe Carvalho

Arquiteto de Software Rodrigo Calheiros

Analista de Testes Ramon Ramos

Tabela 08–Equipe de desenvolvimento.

5.2 Mecanismos de comunicação

Para a efetiva comunicação entre os participantes da equipe, diversas

ferramentas foram abordadas. Dentre elas, é possível destacar:

● O e-mail foi a ferramenta mais utilizada, principalmente por sua

onipresença entre os participantes.

● Ferramentas de colaboração como o Google Drive, que permitiu a

confecção dos diversos documentos de trabalho, bem como a comunicação

instantânea entre os participantes por meio do Google Hangout.

● Reuniões presenciais também serviram para tratar dúvidas e problemas

relacionados com o projeto.

5.3 Uso do Edu-blog como ferramenta de apoio

É uma ferramenta bastante simples e de acesso facilitado, que apoia a

colaboração entre pessoas como fonte de disseminação de conhecimentos.

A utilização do blog durante o desenvolvimento desse trabalho foi importante

para o seu bom andamento. Um importante papel do blog foi compartilhar os

conhecimentos por nós elencados, bem como compartilhar informações com outras

equipes que serviram como base para a edição deste documento.

6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A

QUALIDADE DO PRODUTO DE SOFTWARE

A fim de assegurar a qualidade do software, algumas atividades foram

desenvolvidas durante o projeto, sendo elas:

Testes: Os testes de software foram elaborados e colocados em prática

durante todo o ciclo de desenvolvimento do projeto. A contínua

aplicação de testes permite que os defeitos sejam descobertos o mais

cedo possível, causando assim um menor impacto nos custos de

modificações do software. Isso se dá pelo fato de que quanto mais cedo

um defeito é descoberto, mais fácil é de se consertá-lo.

Seguimento e controle do projeto de software: As atividades

desenvolvidas durante todo o ciclo de desenvolvimento são

acompanhadas constantemente e todos os requisitos são validados com

os clientes.

Produção de documentação: Todas as informações obtidas nas etapas

do desenvolvimento foram compiladas e documentadas. A produção de

documentação fornece um parâmetro para avaliar o que foi feito na

prática em comparação que foi descrito.

Programação Pareada: É uma das técnicas de metodologias de

desenvolvimento ágil como o XP. Através da programação pareada, um

desenvolvedor escreve o código enquanto o outro analisa. Isso permite

que o observador encontre erros que não foram percebidos por quem

está escrevendo o código. Os papeis são trocados com frequência

visando uma melhor produtividade.

7. ANEXOS

Figura 1.1 – Diagrama de Classes de domínio do SISCONI

Figura 1.2 – Diagrama lógico do banco de dados do SISCONI

plano de projeto de software - sisconi

Education