projeto de sw revisado

UNIVERSIDADE FEDERAL DE SERGIPEPRÓ-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

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, dos estabelecimentos 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.

Plano de Projeto Versão 1.1Última atualização: 25/04/2014

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 – Integrated Development Environment – e os 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 estimativas sã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 interface web multi-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 estimativa comum 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 software em 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 – Graphical User Interface – complexa e 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 Torreso Gerente de projetos

o Certificado Project Management Professional – PMP

o Engenheiro de Software

Igor Peterson Oliveira Santoso Coordenador de desenvolvimento

o Microsoft Certified Solutions Developer – MCSD

o Engenheiro de software

Wenderson Campos Pereirao Coordenador de testes

o Certificação Brasileira de Teste de Software – CBTS

o Microsoft Certified Solutions Developer – 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ímos três servidores virtualizados no VMWare ESX para os ambientes de testes, homologação e produção. A configuração do hardware da 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écnicoNegóci

oComum Especial

Retenção de talentos X XCusto 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 XTabela 1: Identificação dos Riscos do Projeto

3.1.1. Avaliação Global dos Riscos

A seguir estão algumas perguntas e 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 software possuem 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 organizados em ordem decrescente de impactos e probabilidades:

Risco CategoriaProbabilidad

eImpacto

R_01:Garantir a alta disponibilidade Tecnológico 50% CatastróficoR_02:Ausência de equipe de testes dedicada

Maturidade do SW

90% Crítico

R_03:Número de clientes que utilizam Negócio 70% Crítico


8

o produtoR_04:Comportamento duvidoso em sistemas móveis

Tecnológico 60% Crítico

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íticoR_09:Requisitos governamentais Negócio 20% CríticoR_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 disponibilidadeRISCO: 01-2014 PROB: 50% IMPACTO: CatastróficoDescrição: Garantia que o software esteja sempre disponí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 TorresStatus: Analisando propostas de fornecedores em (12/04/2014).


9

R_02: Ausência de equipe de testes dedicadaRISCO: 02-2014 PROB: 90% IMPACTO: CríticoDescriçã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 software por parte dos desenvolvedoresPlano de contingência: Contratação de testadores certificados.Pessoa responsável: José Jorge Barreto Torres.Status: Efetuando pesquisa de mercado por recursos humanos especializados em (12/04/2014).

R_03: Número de clientes que utilizam o produtoRISCO: 03-2014 PROB: 70% IMPACTO: CríticoDescriçã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 TorresStatus: Implementando tunning de performance em (12/04/2014).

R_04: Comportamento duvidoso em sistemas móveisRISCO: 04-2014 PROB: 60% IMPACTO: CríticoDescriçã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 PereiraStatus: Analisando as informações de uso do sistema em (15/04/2014).

R_05: Problemas de consistência de dadosRISCO: 05-2014 PROB: 60% IMPACTO: CríticoDescriçã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.Pessoa responsável: Wenderson Campos PereiraStatus: Verificando as informações inseridas pelos usuários em (15/04/2014).

R_06: Garantia da performance em caso de muitos acessos simultâneosRISCO: 06-2014 PROB: 40% IMPACTO: CríticoDescriçã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.Pessoa responsável: Wenderson Campos PereiraStatus: Avaliando os resultados de resposta das páginas do sistema em (15/04/2014).


10

R_07: Custo associado com atraso na entregaRISCO: 07-2014 PROB: 40% IMPACTO: CríticoDescriçã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 SantosStatus: Monitorando projeto em (16/04/2014).

R_08: Retenção de talentosRISCO: 08-2014 PROB: 40% IMPACTO: CríticoDescriçã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.Pessoa responsável: Igor Peterson Oliveira SantosStatus: Desenvolvendo planos de motivação e ambiente de trabalho em (16/04/2014).

R_09: Requisitos governamentaisRISCO: 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.Pessoa responsável: Igor Peterson Oliveira SantosStatus: 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 tempo previsto 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 Desenho no 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 o projeto 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ão alocados 22 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 de 41 dias. Neste período a quantidade de dias é maior que o de desenvolvimento, pois


12

trata-se de uma etapa onde é averiguada a qualidade do que foi desenvolvido até o 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çãoJosé Jorge Barreto Torres [email protected] Engenheiro de

Software e Gerente de Projetos

Igor Peterson [email protected] Engenheiro de Software e Analista de Sistemas

Wenderson Campos Pereira [email protected] 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 time ocorre através da utilização de ferramentas colaborativas e de comunicação como Skype e Google Drive. Pelo menos duas vezes por semana acompanha-se o andamento do projeto de forma semipresencial, a fim de discuti-lo, solucionar problemas e delegar tarefas.


mailto:[email protected]



14

5.3. Uso do edu-blog como ferramenta de apoio

A ferramenta Edu-blog é fundamental durante todo projeto, pois oferece uma dinâ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.
