Projeto de sw revisado

UNIVERSIDADE FEDERAL DE SERGIPE
PRÓ-REITORIA DE PÓS-GRADUAÇÃO E PESQUISA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
ENGENHARIA DE SOFTWARE
PLANO DE PROJETO DE SOFTWARE
SISTEMA DE CONTROLE DE ESTÁGIO
Equipe:
José Jorge Barreto Torres
Igor Peterson Oliveira Santos
Wenderson Campos Pereira
São Cristóvão,SE
2014

Sumário
1. INTRODUÇÃO ........................................................................................................................ 1
1.1. Âmbito do Projeto......................................................................................................... 1
1.2. Principais Funções do Produto de Software ................................................................. 1
1.3. Requisitos Comportamentais ou de Performance........................................................ 1
1.4. Gestão e Restrições Técnicas ........................................................................................ 2
2. ESTIMATIVA DO PROJETO ..................................................................................................... 3
2.1. Dados históricos utilizados para as estimativas................................................................. 3
2.2. Técnicas de estimativa e resultados................................................................................... 3
2.2.1. Técnica de estimativa.................................................................................................. 3
2.2.2. Resultados................................................................................................................... 4
2.3. Recursos do projeto ........................................................................................................... 4
2.3.1. Recursos humanos ...................................................................................................... 4
2.3.2. Recursos de software.................................................................................................. 5
2.3.3. Recursos de hardware................................................................................................. 5
2.3.4. Ferramentas de apoio ................................................................................................. 5
3. ANÁLISE E GESTÃO DE RISCOS .............................................................................................. 6
3.1. Riscos do projeto................................................................................................................ 6
3.1.1. Avaliação Global dos Riscos ........................................................................................ 6
3.2. Tabela de riscos.................................................................................................................. 7
3.3. Redução e gestão dos riscos .............................................................................................. 8
4. PLANEJAMENTO TEMPORAL............................................................................................... 11
4.1. Conjunto de Tarefas do Projeto ....................................................................................... 11
4.2. Diagrama de Gantt........................................................................................................... 11
5. ORGANIZAÇÃO DO PESSOAL ............................................................................................... 13
5.1. Estrutura da equipe.......................................................................................................... 13
5.2. Mecanismos de comunicação.......................................................................................... 13
5.3. Uso do edu-blog como ferramenta de apoio................................................................... 14
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A QUALIDADE DO PRODUTO DE
SOFTWARE .................................................................................................................................. 15
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................................... 16

1
Plano de Projeto Versão 1.1
Última atualização: 25/04/2014
1. INTRODUÇÃO
Aqui descreve-se o projeto de software começando pelo seu âmbito, seguido
das principais funções que o sistema deve prover. Os requisitos de tempo e
comportamento da aplicação também são enumerados além de esboçar acerca das
restrições técnicas e temporais do projeto.
1.1. Âmbito do Projeto
Ao observar a necessidade de várias empresas do ramo educacional, a
respeito da gerência e do controle no fornecimento de estagiários às empresas
coligadas, assim como as alocações e acompanhamentos desses estagiários, a
Lacertae SW decide lançar um produto de controle de estágio que efetua todo
cadastro e manutenção dos objetos envolvidos, além de emitir relatórios gerenciais.
Os usuários que utilizam o sistema possuem a característica de estarem
ligados a departamentos de recursos humanos, gente e carreira ou até centrais de
estágio especializadas em empresas do segmento educacional que fornecem
estagiários a outras empresas, inclusive como pré-requisito de formação curricular.
1.2. Principais Funções do Produto de Software
As principais funções que o sistema deve garantir são:
Controle dos estagiários, dosestabelecimentos educacionais e das empresas
vinculadas.
A capacidade de qualificar os estagiários, de acordo com suas áreas de
atuação.
O registro de acompanhamento das horas de estágio.
O histórico de alocação de vagas dos estagiários nas empresas.
Uma empresa pode estar ligada a um ramo de atuação específico e pode
possuir vários estabelecimentos que serão os destinos das alocações de
vagas.
Uma alocação de vaga deve ter o registro temporal de início e fim, bem como
informações referentes à quantidade e o valor das horas alocadas.
1.3. Requisitos Comportamentais ou de Performance
É solicitado que a interface da aplicação seja de fácil utilização, sem cores
chamativas e com suporte a dispositivos móveis. O desempenho deve ser compatível
com o de um sistema web comum. Também utilizar recursos interativos na carga de
campos do website, a fim de se evitar pageloads excessivos, tornando a experiência
do cliente mais agradável e a utilização do canal de comunicação mais leve.
Quanto aos requisitos comportamentais, toda aplicação deve estar completa,
sem faltar nenhuma funcionalidade - incluindo relatórios - antes de entrar em
produção.

2
1.4. Gestão e Restrições Técnicas
a. Restrições Técnicas
No que diz respeito a hardware, a equipe de desenvolvimento pode
efetuar os testes de acesso através dos próprios PCs e dispositivos
móveis.
Em software, torna-se necessária uma IDE –
IntegratedDevelopmentEnvironment – eos sistemas de apoio, que são
obtidos através da MSDNAA gratuitamente, incluindo o sistema
operacional para abrigar a ferramenta.
b. Restrições Temporais
O prazo para conclusão do projeto poderá afetar a equipe, visto que o
mesmo é insuficiente para que seja realizado o desenvolvimento e o
conjunto de testes de homologação.
Os participantes do projeto estão alocados em outras atividades
extracurriculares, o que pode resultar em um desempenho insatisfatório
com relação ao empenho dos mesmos no desenvolvimento do projeto
como um todo.

3
2. ESTIMATIVA DO PROJETO
As estimativassão úteis para o acompanhamento geral e detalhado do projeto
por todos os membros da equipe. Os cálculos de tempo desprendido em cada fase
são levados em consideração para mensurar e provisionar tal alocação.
2.1. Dados históricos utilizados para as estimativas
Um sistema semelhante sem utilização de interfacewebmulti-plataforma já foi
criado por uma equipe de desenvolvimento um pouco maior que a da Lacertae. Esse
projeto levou cerca três meses até ser colocado em produção para o usuário final.
2.2. Técnicas de estimativa e resultados
Aqui, descreve-se o método de medição e provisionamento de tempo do
projeto através de uma técnica de estimativacomum adotada pela Lacertae SW.
2.2.1. Técnica de estimativa
A técnica de estimativa de tempo eleita pela Lacertae SW é orientada a
classes e de fácil utilização, conhecida como métrica de Lorenz &Kidd (Pressman,
2011). Esta métrica envolve as classes-chave do modelo e as classes de suporte que
são calculadas através de um multiplicador que varia de acordo com o tipo de interface
utilizada no desenvolvimento da aplicação. Os fatores multiplicadores podem ser:
a. Interface não gráfica: x2
b. Baseada em texto: x2,25
c. GUI: x2,5
d. GUI complexa: x3
O cálculo das classes de suporte é realizado multiplicando-se a quantidade
de classes chaves pelo fator multiplicador correspondente ao tipo de interface
adotada. Em seguida é obtido o total de classes somando-se as classes-chave e as
classes de suporte para finalmente multiplicar o valor total de classes pelo “número
médio de unidades de trabalho” (dias/pessoa) por classe. A métrica de Lorenz &Kidd
sugere um número de 15 a 20 dias / pessoa. Segue a fórmula:
[Ch + (Ch x Mu)] x Dp onde,
Ch = Quantidade de classes-chave
Mu = Fator multiplicador
Dp = Número de dias/pessoa (15 a 20)

4
2.2.2. Resultados
Pelo fato de existir uma restrição temporal a respeito da alocação dos
integrantes do desenvolvimento do produto de softwareem outros projetos, utiliza-se o
fator dias/pessoa em 20. A aplicação, como já mencionado anteriormente, deve
possuir interface web com suporte a diversas plataformas, tornando a GUI –
GraphicalUser Interface – complexae consequentemente adotando o fator
multiplicador em três (Mu=3). São identificadas no projeto, quatro classes-chave
(Ch=4). São elas: vaga, estabelecimento educacional, estagiário e alocação. Por
fim, o cálculo fica em:
[4 + (4 x 3)] x 20 = 320dias/pessoa
Já que a equipe é formada de três membros, a quantidade de tempo
estimado para o projeto é de 107 dias. Levando em consideração que um mês possui
22 dias úteis, o projeto tem uma previsão de conclusão de quatro meses e meio a
cinco meses.
Com a informação que o projeto tem uma duração total prevista para 320 dias
úteis, dividimos o tempo estimado da forma 40-20-40:
Planejamento: 3% = aprox. 9 dias.
Requisitos, análise, desenho: 39% = aprox. 125 dias.
Geração de código: 20% = 64 dias.
Testes: 38% = aprox. 122 dias.
2.3. Recursos do projeto
2.3.1. Recursos humanos
A equipe de desenvolvimento de software é formada por três profissionais
extremamente capacitados em suas áreas:
José Jorge Barreto Torres
o Gerente de projetos
o Certificado Project Management Professional – PMP
o Engenheiro de Software
Igor Peterson Oliveira Santos
o Coordenador de desenvolvimento
o Microsoft CertifiedSolutionsDeveloper – MCSD
o Engenheiro de software
Wenderson Campos Pereira
o Coordenador de testes
o Certificação Brasileira de Teste de Software – CBTS
o Microsoft CertifiedSolutionsDeveloper – MCSD
o Engenheiro de testes e de software

5
2.3.2. Recursos de software
Alguns dos softwares envolvidos, desde o desenvolvimento da aplicação até
a publicação em um ambiente de produção,são adquiridos através da licença
acadêmica MSDNAA e estão descritos a seguir:
Visual Studio 2010 Professional: Contém toda suíte de desenvolvimento
e testes necessária para o andamento do projeto.
Visual Studio 2010 Team Foundation Server: Ambiente de integração do
desenvolvimento de software, contendo diversas ferramentas
colaborativas, incluindo controle de versão.
Windows Server 2008 Enterprise: Sistema operacional que abriga os
servidores de desenvolvimento, homologação e produção. Os serviços
de apoio como IIS e outras bibliotecas adicionais estão incluídos no
S.O.
Oracle Database11gR2 Enterprise Edition: Banco de dados para
armazenamento dos objetos do sistema, com suporte a recursos de
compactação de dados, particionamento de tabelas e backup avançado.
2.3.3. Recursos de hardware
Em uma blade HP, possuímostrês servidores virtualizados no VMWare ESX
para os ambientes de testes, homologação e produção. A configuração do hardwareda
bladeé: BL 465C Gen 8 6378 (2P), com dois processadores 16-core de 2.4 GHz, 64GB
RAM e dois discos SAS de 256GB em RAID 1.
2.3.4. Ferramentas de apoio
Nas fases de concepção e planejamento do projeto, utilizamos as seguintes
ferramentas de modelagem e gerência de projetos:
Oracle SQL Developer: utilizada para criar os modelos conceituais e
lógicos de banco de dados, além de geração dos objetos físicos.
StarUML: Modelagem dos diagramas de classes e casos de uso do
sistema.
Microsoft Project: Gerência do projeto, alocação de recursos,
estimativas de tempo, etc.

6
3. ANÁLISE E GESTÃO DE RISCOS
Segundo (Pressman,2011) (Sommerville, 2007), o gerenciamento de riscos
consiste em prever os riscos que podem afetar o cronograma do projeto ou a
qualidade do software que está sendo desenvolvido e tomar providências para evitar
riscos que possam vir a acontecer. Um gerenciamento eficiente de riscos torna mais
fácil lidar com os problemas e assegurar que eles não conduzam a um orçamento
inaceitável ou atraso no cronograma.
O gerenciamento de riscos é particularmente importante para projetos de
software, devido às incertezas inerentes à maioria dos projetos. Eles se originam de
requisitos mal definidos, dificuldades na estimativa de prazos e recursos necessários
para o desenvolvimento de software, dependência de habilidades individuais e
mudanças de requisitos devido às mudanças nas necessidades dos
clientes(Sommerville, 2007).
Diante disso, as próximas seções apresentam riscos detectados para o
projeto do software deste documento, Sistema de Controle de Estágio, assim como o
plano de redução, supervisão e gestão de risco (RSGR).
3.1. Riscos do projeto
Risco Projeto Técnico Negócio Comum Especial
Retenção de talentos X X
Custo associado com atraso na
entrega
X X X
O cliente não tem ideia
completa do produto
X X
Problemas em detectar
Requisitos governamentais
X X X
Garantia de disponibilidade do
software
X
Subestimativas do esforço X X
Tabela 1: Identificação dos Riscos do Projeto
3.1.1. Avaliação Global dos Riscos
A seguir estão algumas perguntase respostas, quanto à avaliação global dos
Riscos.
a) O gestor de Software dá suporte ao projeto?
Sim. O gestor é fundamental para o andamento do projeto.
b) Os clientes estão entusiasmados com o projeto e o produto?
Sim. Afinal, eles são os principais beneficiados com os recursos e
facilidades que o software propõe.
c) Os engenheiros de Software compreenderam bem os requisitos?

7
Sim. O processo de análise de requisitos é definido em conjunto com
todas as partes envolvidas do software, o que contribui, dessa forma,
para um conhecimento geral de como o software deve ser concebido.
d) Os clientes estiveram envolvidos na definição de requisitos?
Sim. Como foi respondido anteriormente, os clientes e usuários finais
estão envolvidos e aptos a ajudar para a criação do software.
e) O âmbito do projeto é estável?
Até o momento, sim. Mesmo que os requisitos possam ser modificados
e riscos possam ocorrer, estamos atentos e preparados para possíveis
modificações do projeto.
f) Os engenheiros de softwarepossuem as competências requeridas?
Sim. Os engenheiros têm experiências no mercado e a soma dessas
experiências contribuirá para o bom desenvolvimento do projeto.
g) Os requisitos do projeto estão estáveis?
Os principais requisitos se encontram estáveis, mas esses e outros
podem vir a sofrer modificações a depender de processos futuros no
desenvolvimento ou na detecção de novos requisitos fundamentais
para o projeto.
h) A equipe de desenvolvimento tem experiência na tecnologia que será
utilizada?
A equipe tem experiência com boa parte das tecnologias adotadas,
embora estejam sempre propensos a aprender e agregar
conhecimento para o projeto.
i) É adequado o número de pessoas da equipe de trabalho?
Sim. Afinal, o tamanho do projeto condiz com o prazo estimado para o
desenvolvimento do software. Dessa forma, a equipe de trabalho
trabalhará focada na qualidade e no prazo do projeto.
3.2. Tabela de riscos
Os riscos do projeto são identificados através das seguintes categorias:
tamanho do produto, impacto de negócio, cliente, maturidade do software, tecnologia e
pessoas.Estes riscos podem ser vistos na Tabela 2, e estão organizadosem ordem
decrescente de impactos e probabilidades:
Risco Categoria Probabilidade Impacto
R_01:Garantir a alta disponibilidade Tecnológico 50% Catastrófico
R_02:Ausência de equipe de testes
dedicada
Maturidade do
SW
90% Crítico
R_03:Número de clientes que utilizam
o produto
Negócio 70% Crítico
R_04:Comportamento duvidoso em Tecnológico 60% Crítico

8
sistemas móveis
R_05:Problemas de consistência de
dados
Tamanho do
Produto
60% Crítico
R_06:Garantia da performance em
caso de muitos acessos simultâneos
Tecnológico 40% Crítico
R_07:Custo associado com atraso na
entrega
Negócio 40% Crítico
R_08:Retenção de talentos Pessoas 40% Crítico
R_09:Requisitos governamentais Negócio 20% Crítico
R_10:Não acompanhar as fases do
projeto
Cliente 90% Moderado
R_11:Tem pouco tempo para dedicar
no projeto
R_12:Não entende os requisitos
técnicos
R_13:Falta de acompanhamento da
qualidade de software por equipe
especializada
Maturidade do
SW
90% Moderado
R_14:O cliente não tem ideia
completa do produto
R_15:Custo associado com produto
defeituoso
Negócio 50% Moderado
R_16:Número de usuários do produto
Tamanho do
Produto
60% Moderado
R_17:Reutilização de código de SW
Tamanho do
Produto
30% Marginal
R_18:Condições ruins de ambiente de
trabalho
Pessoas 20% Marginal
R_19:Recrutamento de especialistas
com habilidades
Pessoas 20% Marginal
R_20:Não conhece o processo de
E.S.
Cliente 90% Desprezível
Tabela 2: Riscos do Projeto
3.3. Redução e gestão dos riscos
Para a elaboração de um plano de redução, supervisão e gestão de riscos
(RSGR), define-se um ponto de corte dos nove primeiros riscos identificados na
Tabela 2. Estes são apresentados a seguir.
R_01: Garantira alta disponibilidade
RISCO: 01-2014 PROB: 50% IMPACTO: Catastrófico
Descrição: Garantia que o software esteja sempredisponível.
Estratégia de Redução: Monitoramento constante da saúde dos serviços de infraestrutura.
Plano de contingência: Adoção de um sistema de Clusters de Alta Disponibilidade.
Pessoa responsável: José Jorge Barreto Torres
Status: Analisando propostas de fornecedores em (12/04/2014).

9
R_02: Ausência de equipe de testes dedicada
RISCO: 02-2014 PROB: 90% IMPACTO: Crítico
Descrição: Não possui equipe de testes especializada e/ou pessoas alocadas para se dedicar
a testes do software.
Estratégia de Redução:Dedicar mais horas relativas ao teste de softwarepor parte dos
desenvolvedores
Plano de contingência: Contratação de testadores certificados.
Pessoa responsável: José Jorge Barreto Torres.
Status: Efetuando pesquisa de mercado por recursos humanos especializadosem
(12/04/2014).
R_03: Número de clientes que utilizam o produto
Descrição: Grande quantidade de clientes utilizando o produto ao mesmo tempo.
Estratégia de Redução: Efetuar testes de stress para detectar os limites de utilização do
produto e realizar tunning dos serviços.
Plano de contingência: Adaptar hardware dos servidores quando o tunning não fizer mais
diferença no desempenho.
Pessoa responsável: José Jorge Barreto Torres
Status:Implementandotunning de performanceem (12/04/2014).
R_04: Comportamento duvidoso em sistemas móveis
Descrição:Falhas no acesso e uso do software ou dos dados da aplicação móvel.
Estratégia de Redução: Monitorar o sistema nos diferentes tipos de Sistemas Operacionais e
realizar casos de testes para detectar as diversas falhas que possam surgir.
Plano de contingência: Disponibilizar outro sistema, temporariamente, com as
funcionalidades principais e mais utilizadas.
Pessoa responsável:Wenderson Campos Pereira
Status: Analisando as informações de uso do sistema em (15/04/2014).
R_05: Problemas de consistência de dados
Descrição: Problemas de consistência no banco de dados do software.
Estratégia de Redução: Monitorar periodicamente a qualidade dos dados que são inseridos
no banco de dados.
Plano de contingência: Fazer a restauração do banco de dados.
Status: Verificando as informações inseridas pelos usuáriosem (15/04/2014).
R_06: Garantia da performance em caso de muitos acessos simultâneos
Descrição: Garantir o bom desempenho do software quando houver vários acessos
simultâneos no software.
Estratégia de Redução: Habilitar a compressão GZIP (GNU Zip) para o conteúdo das
páginas web do sistema antes de enviar para o usuário.
Plano de contingência: Diminuir a quantidade de dados trafegando pelo canal de
comunicação com a finalidade de evitar sobrecarga.
Status: Avaliando os resultados de resposta das páginas do sistemaem (15/04/2014).

10
R_07: Custo associado com atraso na entrega
Descrição:Problemas em adicional de custo do software associado com atraso na entrega do
mesmo.
Estratégia de Redução: Monitoramento constante do projeto e de suas tarefas.
Plano de contingência: Ter parceiros terceirizados para desenvolvimento de parte do projeto.
Pessoa responsável: Igor Peterson Oliveira Santos
Status: Monitorando projeto em (16/04/2014).
R_08: Retenção de talentos
Descrição:Busca contínua em manter os talentos das diversas áreas do desenvolvimento do
software.
Estratégia de Redução: Verificar ambiente de trabalho e ofertas de emprego fora da
companhia.
Plano de contingência: Criar planos de motivação para os funcionários.
Status: Desenvolvendo planos de motivação e ambiente de trabalho em (16/04/2014).
R_09: Requisitos governamentais
RISCO: 09-2014 PROB:20% IMPACTO:Crítico
Descrição:Atividades de estágio não compatíveis com o que é descrito na Lei nº 11.788
(2008).
Estratégia de Redução:Buscar sempre ficar atualizado quanto à lei que regulariza as
atividades dos estagiários.
Plano de contingência:Alocar e concentrar desenvolvedores para adequar o sistema as
mudanças na lei de forma imediata.
Status:Colhendo informações sobre a lei no portal do MEC (Ministério da Educação) de forma
periódica.

11
4. PLANEJAMENTO TEMPORAL
Nesta seção descreve-se o conjunto de tarefas do projeto. Após isso, as
datas e os responsáveis pela execução dessas tarefas são representados através do
Diagrama de Gantt.
4.1. Conjunto de Tarefas do Projeto
Na subseção de resultados da estimativa do projeto, estima-se um tempo de
320 dias para o desenvolvimento completo do sistema. Embora esse tempo seja
calculado para uma pessoa somente,uma equipe de três compõe o desenvolvimento
do projeto. Conclui-se que o tempoprevisto para conclusão do sistema é reduzido
para,aproximadamente, 107 dias úteis. A divisão de tarefas pela porcentagem é
apresentada na Tabela 3.
Tarefas Porcentagem do
Tempo
Dias úteis de
atividade
Planejamento 3% 3
Requisitos, análise, desenho 39% 41
Geração de código 20% 22
Testes 38% 41
Tabela 3: Divisão das tarefas
4.2. Diagrama de Gantt
O Diagrama de Gantt é responsável pela programação de cada atividade.
Além disso, as tarefas estão associadas a um ou mais elementos do projeto. Na
Figura 1, está a representação do Diagrama de Gantt para o projeto do Sistema de
Controle de Estágio.
No Diagrama podemos destacar a etapa de Requisitos, Análise e Desenhono
qual possui uma duração de 41 dias.Inicialmente, realiza-se o levantamento dos
requisitos necessários para o desenvolvimento do sistema, que tem uma duração de
10 dias. Os próximos 5 dias ficam dedicados para a Definição de Casos de Uso dos
sistema e para o desenvolvimento do Diagrama de Classes. Após isso, aloca-se um
período de 18 dias para oprojeto do Banco de Dados para, por fim, realizar e
apresentar os Protótipos do Sistema em 8 dias.
Na etapa de Construção, estão definidas as quatro classes-chave do projeto,
as quais servem de base para mensuração do tempo de duração do projeto.
Sãoalocados22 dias para o desenvolvimento dessas classes.A mesma quantidade de
dias está definida para o gerenciamento de controle de versões.
Para o período de Testes e Transição do Sistema,há uma dedicação de41
dias. Nesteperíodo a quantidade de dias é maior que o de desenvolvimento,pois trata-
se de uma etapa onde é averiguada a qualidade do que foi desenvolvido até o

12
momento. Para isso, está definido um período de 22 dias para os Casos de Testes. O
processo final do projeto faz parte da implantação do sistema, que é uma parte bem
delicada e que merece atenção, que possui duração de 15 dias úteis.
Figura 1: Diagrama de Gantt do projeto

13
5. ORGANIZAÇÃO DO PESSOAL
A equipe realiza um bom trabalho em conjunto do início ao fim do projeto. As
delegações das tarefas são tomadas em consenso e a comunicação entre os
membros faz com que se organizem a ponto de produzir um projeto com melhor
qualidade.
5.1. Estrutura da equipe
A equipe é formada por três membros, descritos abaixo com as respectivas
funções:
Nome E-mail Função
José Jorge Barreto Torres jorgesamango@gmail.com Engenheiro de
Software e Gerente
de Projetos
Igor Peterson igorpeterson@gmail.com Engenheiro de
Software e Analista
de Sistemas
Wenderson Campos Pereira wendersonse@gmail.com Engenheiro de
Software e Analista
de Testes
Tabela 4: Membros da equipe, contato e suas funções.
Segue abaixo a descrição breve de cada função:
Engenheiro de Software: Responsável pelo projeto, design da
aplicação e implementação do sistema.
Gerente de Projetos: Gerenciar e controlar todo o projeto, delegar
funções aos membros da equipe com prazos, realizar controle de
qualidade e também verificar cada etapa do projeto.
Analista de Sistemas: Realiza o levantamento e análise de requisitos
do software.
Analista de Testes: Responsável pela definição do ambiente de
testes e planejamentos e execução dos casos de testes, bem comoo
reporte dos erros e defeitos encontrados.
5.2. Mecanismos de comunicação
O processo de comunicação do timeocorreatravés da utilização de
ferramentas colaborativas e de comunicação como Skype e Google Drive. Pelo menos
duas vezes por semanaacompanha-se o andamento do projeto de forma
semipresencial, a fim de discuti-lo, solucionar problemase delegar tarefas.

14
5.3. Uso do edu-blog como ferramenta de apoio
A ferramenta Edu-blogé fundamental durante todo projeto, pois oferece
umadinâmica entre o professor e os alunos da disciplina. Além disso, através dessa
ferramenta é possível organizar todo o conteúdo da disciplina em um só lugar. Tanto o
material ofertado pelo professor quanto os links para os blogs de outros alunos com as
atividades e projetos de cada grupo estão disponíveis a todos.

15
6. PRECAUÇÕES TOMADAS PARA ASSEGURAR E CONTROLAR A
QUALIDADE DO PRODUTO DE SOFTWARE
A equipe utiliza os seguintes itens com o intuito de garantir e controlar a
qualidade do produto de software:
a) Gestão de Projeto de Software–Realiza-se um acompanhamento
constante das atividades desenvolvidas por parte de todos os
envolvidos no projeto.
b) Revisões Técnicas Formais - As revisões são executadas por
pessoas capacitadas durante todo o ciclo, visando à identificação de
erros nas fases iniciais do projeto onde o custo para a manutenção é
reduzido.
c) Gestão de Configuração do Software - Conjunto de atividades
projetadas para controlar inúmeras correções, extensões e
adaptações aplicadas durante o ciclo de vida do software de forma a
assegurar um processo de desenvolvimento e evolução sistemático e
rastreável.
d) Métricas de Qualidade - São realizadas medições para verificar o
quanto o software atende aos requisitos impostos pelo usuário.
e) Análise de Riscos - Identificar, analisar e controlar os riscos,
elaborando planos de redução e de contingência.
f) Testes–Realizar testes dentro de um processo definido, com o
objetivo de fornecer informações sobre sua qualidade em relação ao
contexto em que ele deve operar. Além disso, identificar possíveis
erros antes que estes se transformem em defeitos e tornem-se riscos,
trazendo prejuízos para a empresa.

16
REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, Roger S.Engenharia de Software. 7° ed. McGraw-Hill. 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison-Wesley,
2007.

Projeto de sw revisado

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Projeto de sw revisado

Similaire à Projeto de sw revisado (20)

Projeto de sw revisado