Eng software

UNIVERSIDADE FEDERAL DE SERGIPE
CENTRO DE CIÊNCIAS EXATAS E TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
AMILTON DE AZEVEDO GONÇALVES
MARCUS VINÍCIUS ANDRADE CÔRTES
PEDRO FELIPE DE LIMA
PLANO DE PROJETO DE SOFTWARE OO PARA ESCOLA
DE LÍNGUAS
SÃO CRISTÓVÃO
2014

AMILTON DE AZEVEDO GONÇALVES
MARCUS VINÍCIUS ANDRADE CÔRTES
PEDRO FELIPE DE LIMA
PLANO DE PROJETO DE SOFTWARE OO PARA ESCOLA
DE LÍNGUAS
Trabalho realizado no módulo de Gestão
de Projetos ministrado pelo docente Dr.
Rogério Patrício Chagas do Nascimento
na disciplina de Engenharia de Software
da Pós-Graduação em Ciência da
Computação (Curso de Mestrado
Acadêmico) da Universidade Federal de
Sergipe (UFS).
SÃO CRISTÓVÃO
2014

LISTA DE TABELAS
Tabela 1: Fatores multiplicativos para encontrar o nº de classes de suporte........................... 11
Tabela 2: Percentual de componentes essenciais em um projeto............................................. 12
Tabela 3: Divisão de dias trabalho em cada componente........................................................... 12
Tabela 4: Recursos humanos do projeto........................................................................................ 13
Tabela 5: Identificação dos Riscos do Projeto............................................................................... 15
Tabela 6: Riscos do Projeto.............................................................................................................. 16
Tabela 7: Planos de redução de riscos......................................................................................... 167
Tabela 8: Estrutura da Equipe........................................................................................................ 255
Tabela 9: Descrição das Atividades .............................................................................................. 265

LISTA DE ILUSTRAÇÕES
Ilustração 1: Cronograma A do Projeto........................................................................................... 21
Ilustração 2: Cronograma B do Projeto........................................................................................... 22
Ilustração 3: Cronograma C do Projeto .......................................................................................... 23
Ilustração 4: Cronograma D do Projeto .......................................................................................... 24

SUMÁRIO
1. INTRODUÇÃO......................................................................................................6
1.1. Âmbito do projeto ...........................................................................................6
1.2. Funções principais do produto de software....................................................6
1.3. Requisitos comportamentais ou de performance ...........................................7
1.4. Gestão e Restrições Técnicas .......................................................................8
2. ESTIMATIVAS DE PROJETO ..............................................................................9
2.1. Dados históricos utilizados para as estimações...........................................10
2.2. Ténicas de estimação e resultados..............................................................10
2.2.1. Técnicas de estimação..........................................................................10
2.3. Resultados ...................................................................................................11
2.4. Recursos do projeto .....................................................................................13
2.4.1. Recursos humanos...................................................................................13
2.4.2. Recursos de software ...............................................................................13
2.4.3. Recursos do ambiente de desenvolvimento .............................................13
3. ANÁLISE E GESTÃO DE RISCOS.....................................................................14
3.1. Riscos do projeto .........................................................................................14
3.2. Tabela de Identificação dos riscos ...............................................................16
3.3. Redução e gestão de risco...........................................................................17
4. PLANEJAMENTO TEMPORAL ..........................................................................19
4.1. Diagrama de Gantt.......................................................................................19
5. ORGANIZAÇÃO DO PESSOAL .........................................................................25
5.1. Estrutura da equipe......................................................................................25
5.2. Mecanismos de Comunicação .....................................................................26
5.3. Uso do Edu-Blog como ferramenta de apoio ...............................................26
6. QUALIDADE......................................................... Error! Bookmark not defined.
7. REFERÊNCIAS ..................................................................................................28

6
1. INTRODUÇÃO
O objetivo deste documento é definir com detalhes os fatores relevantes
de panejamento, execução e acompanhamento do desenvolvimento do Software
Yázigi On-line. Além disso, descrever uma visão geral sobre o projeto de software.
O Yázigi On-line é um software de gerenciamento para escolas de línguas
da rede Yázigi de ensino, com possibilidade de se adaptar a outras escolas de
línguas, caso haja necessidade. O software, desenvolvido inicialmente para ser
acessado via Web tem como objetivo permitir que os alunos, docentes e
funcionários possam ter uma comunicação mais dinâmica e interagir através de
serviços oferecidos online.
1.1. ÂMBITO DO PROJETO
Seu objetivo principal é gerenciar matrículas e turmas, para isso o
software utiliza-se de uma interface usável e responsivo para quebrar as barreiras
da sala de aula, sendo possível qualquer dispositivo com acesso a internet, seja ele
um computador pessoal ou qualquer dispositivo móvel, acessar o software. Além do
programa um dashboard, contendo detalhes de suas atividades e conta com vários
serviços online, gerando comodidade e agilidade aos seus usuários, possibilitando
uma interação dos serviços das unidades de línguas além das fronteiras da sala de
aula.
1.2. FUNÇÕES PRINCIPAIS DO PRODUTO DE SOFTWARE
O sistema deve colaborar nas atividades acadêmicas entre o corpo
docente e discentes. E auxiliará no gerenciamento da unidade. Mais
especificamente, o sistema pretende facilitar a comunicação entre professores,

7
alunos, unidade escolar e o controle da unidade, oferecendo, entre outras opções de
serviços.
Seguem subsequente enumerado os requisitos descritos no escopo do
produto do software.
i. Autenticar usuários para acesso ao mesmo, aonde o utilizador (aluno,
docente, administrador ou funcionário), irá se identificar através de login e senha,
sendo assim apenas os módulos autorizados acessados pelo mesmo;
ii. Disponibilizar relatórios diários para os gestores das atividades;
iii. Gerar atas de frequência de acordo com as solicitações do docente da
turma;
iv. Oferecer ao docente e aluno uma ata de presença;
v. Registrar todo e qualquer tipo atividade sobre a turma (avaliações,
métricas de desempenho dos alunos e turma, frequência dos alunos e atividades
extras;
vi. Disponibilizar ao docente a inserção das notas dos alunos, sendo
assim os alunos podem visualizar suas notas após as atividades e avaliações no
sistema e acompanhar seu desempenho diante as atividades elaboradas na turma;
vii.Oferecer uma área para os alunos realizarem matrículas;
viii. Permitir à visualização dos dados de uma solicitação de aluno a
secretária da escola;
ix. Permitir aos alunos a visualização de seu histórico de atividades e
notas no sistema;
x. Consultar diariamente as matrículas e mensalidades com pagamento
pendente.
1.3. REQUISITOS COMPORTAMENTAIS OU DE PERFORMANCE
Os requisitos comportamentais ou de performance são os seguintes:
i. Sobre os requisitos comportamentais, as funcionalidades são
consideradas críticas, através do ponto de vista da importância do correto
funcionamento para amplitude das atividades disponíveis.

8
ii. O sistema deve funcionar on line, conectado ao bancos de dados, com
tempo de resposta máximo de 2 segundos para cada ação solicitada pelo usuário e
atender a cerca de mais de 250 usuários on line e simultâneos.
iii. Será necessário que a interface apresentada seja agradável, com
acessibilidade, simples e fácil de utilizar em todos os dispositivos, e sua interação
deve ir além disso, terá que ser composta por um conjunto de opções selecionáveis
de modo que a escrita seja minimizada, já que o software deve esta disponível para
a grande maioria dos dispositivos móveis.
iv. O sistema deverá ser bastante intuitivo quanto ao uso de suas funções,
requerendo pouco ou nenhum treinamento para ser utilizado. Testes de usabilidade
serão necessários para se garantir tal requisito.
v. As atualizações de versões do software devem acontecer de maneira
automática, a partir do deploy1 do desenvolvimento.
vi. O sistema deverá evitar que pessoas não autorizadas tenham acesso
ao conteúdo privado e de outros usuários. Será exigido o login para certificar-se
sobre o acesso ao sistema.
1.4. GESTÃO E RESTRIÇÕES TÉCNICAS
O cliente tem a expectativa de receber o software em no máximo 4
meses, mas o prazo será negociado com base nas estimativas produzidas neste
plano de projeto. O projeto será utilizará metodologias ágeis de gerenciamento e
execução. A principal será o framework Scrum.
Framework – É uma abstração que une códigos comuns entre vários projetos de
software provendo uma funcionalidade genérica.
1.4.1 Restrições Técnicas:
O hardware pertencente à equipe não é compatível com a tecnologia adotada.
Sendo necessária a compra de novos equipamentos que atendam a necessidade;
1
É a tarefa de instalar uma aplicação em diversas estações de maneira simples e eficiente visando
organizar, facilitar e agilizar a manutenção da rede local após sua implementação.

9
Em termos de software, a escolha de software open source2 para os
desenvolvedores facilitou o trabalho no desenvolvimento da aplicação;
Falta de capacitação técnica da equipe, sendo necessário um treinamento
específico;
Falta de experiência e prática nas ferramentas e métodos utilizados para o
desenvolvimento do software.
1.4.2 Restrições Temporais:
O prazo definido pelo cliente é curto para o desenvolvimento do projeto e para
uma boa formação nas ferramentas escolhidas, sendo assim será negociado com o
cliente o desenvolvimento e entrega de forma incremental, definindo marcos a serem
entregues.
O planejamento de maneira bem sucedida, respeitando as estimativas e
limitações do projeto são essenciais para obter o sucesso do desenvolvimento do
projeto, para isso, é necessário um conhecimento razoavelmente coerente sobre o
desempenho dos participantes no projeto, a duração das tarefas, as fases e os
requisitos que temos de definir e outros tópicos essenciais. Alguns desses requisitos
exigem um cálculo instintivo da sua duração, pelo que nem sempre esta estimação é
a correta, tornando-se por isso uma restrição em termos temporais.
2. ESTIMATIVAS DE PROJETO
As estimações do projeto são importantes para ter uma maior velocidade
na tomada de decisões no período de levantamento da viabilidade do projeto, ou
seja, o tempo total do projeto. Reforçando que a estimativa é essencial para saber
lidar com as previsões e cronogramas, e por sua vez, estimar custos, esforços e
efetuar os cálculos necessários para determinar o tempo de cada fase do projeto,
fase de panejamento, requisitos, análise, desenho, implementação e testes.
2
Open Source – O termo código aberto (open source, em inglês), diz respeito a software de utilização
livre, cuja licença não é cobrada e cujo código fonte é disponibilizado, de forma gratuita, pelo autor.

10
2.1. DADOS HISTÓRICOS UTILIZADOS PARA AS ESTIMAÇÕES
De momento não existem informações históricas por conta que nenhum
membro da equipe possui a experiência na realização de projetos de software.
Sendo assim não possuímos dados históricos para relato.
2.2. TÉNICAS DE ESTIMAÇÃO E RESULTADOS
Nesta seção é demonstrado como efetuar todo o cálculo para encontrar o
tempo total de duração do projeto (em dias). Para encontrar esse tempo é
necessário aplicar uma técnica de estimativas e neste caso utilizaremos a métrica de
Lorenz & Kidd, aconselhada pela Lacertae Software.
2.2.1. Técnicas de estimação
Para este projeto a métrica usada em projetos de Software Orientados a
Objetos da Lacertae Software. Essa técnica é a Lorenz & Kidd. Trata-se de uma
métrica orientada a classes, a qual se destaca por ser simples e fácil de utilizar.
Para usar a métrica de Lorenz & Kidd temos que:
1. Definir o número de classes chave.
2. Encontrar o número de classes de suporte, que para isso temos que
classificar o tipo de Interface do Produto, que esta na Tabela 1 e desenvolver um
Multiplicador para as Classes de Suporte.
3. Multiplicar a quantidade de classes-chave pelo Multiplicador para obter
uma estimativa do número de classes de suporte.
4. Calcular a quantidade total de Classes, somando o nº de Classes-
Chave com o nº de Classes de Suporte.

11
5. Multiplicar a quantidade total de Classes (classes-chave + classes de
suporte) pelo “número médio de unidades de trabalho (dias-pessoa) por classe”.
Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por classe. Deve-se escolher um
número entre 15-20 dias-pessoa e justificar a escolha.
6. Determinar a quantidade de esforço estimada.
7. Cálcular o tempo previsto para a elaboração do projeto.
Interface Multiplicador
Não gráfica 2,0
Baseada em textos 2,25
GUI 2,5
GUI complexa 3,0
Tabela 1: Fatores multiplicativos para encontrar o nº de classes de suporte
Na Tabela 1 são apresentados os tipos de interfaces com o usuário. Para o projeto
foi escolhido a interface GUI onde o fator multiplicador é 2,5. Foi escolhido essa
interface tendo visto a necessidade de uma interface mais interativa com o usuário.
Detalhes da escolha da interface será mostrado na subseção 2.3 deste projeto.
2.3. RESULTADOS
Com base na métrica de Lorenz & Kidd, obtivemos os seguintes
resultados:
1. Nº de classes chave = 5;
2. Foi escolhida a Interface com base na aplicação gráfica que irá ter o
produto final. Multiplicador do GUI = 2,5;
3. 5 X 2,5 = 12,5 . Logo teremos 12,5 Classes de Suporte.
4. O número total de classes é igual a: Nº Classes Chave + Nº Classes de
Suporte = 5 + 12,5 = 17,5
5. Foi escolhido o número médio de unidades de trabalho (dias-pessoa)
por classe onde a métrica Lorenz & Kidd sugere entre 15 e 20 dias-pessoa por
classe. Em conjunto optamos por escolher 20 dias-pessoa devido ao fato de ser a

12
primeira experiência que o processo scrum será utilizado com as ferramentas de
trabalho disponibilizadas na empresa.
6. Sendo assim, o cálculo da quantidade do esforço estimada é: 17,5 X 20
= 350 dias de trabalho.
Novamente com base nos dias de trabalho total (350 dias), estes dias serão
distribuídos de acordo com as seguintes percentagens de distribuição dos
componentes essenciais em um projeto.
Componentes Essenciais Percentual
Planejamento 2% à 3%
Requisitos – Análise – Desenho 40%
Geração de Código 20%
Testes 37% à 38%
Tabela 2: Percentual de componentes essenciais em um projeto
Na Tabela 2 são apresentados o percentual de componentes essenciais em um
projeto. Os componentes essenciais foram dividos em: Planejamento com 2% à 3%;
Requisitos – Análise – Desenho com 40%; Geração de código com 20% e testes
com 37% à 38%.
Componentes Essenciais Percentual Utilizado Dias de Trabalho
Planejamento 3% 10,5
Requisitos – Análise – Desenho 40% 140
Geração de Código 20% 70
Testes 37% 129,5
Total dias de Trabalho 350
Tabela 3: Divisão de dias trabalho em cada componente
Na Tabela 3 são apresentados a divisão de dias de trabalho em cada componente.
Os componentes foram dividos em: Planejamento; Requisitos – Análise – Desenho;
Geração de código e testes.
Pode-se calcular agora os dias de trabalho por pessoa. Sendo assim
haverá 3 membros da equipe para este projeto e 350 dias de trabalho. Dividindo o

13
total de dias pelos membros da equipe ficaremos com aproximadamente 116,66 ≈
117 dias de trabalho para cada membro da equipe.
2.4. RECURSOS DO PROJETO
2.4.1. Recursos humanos
O projeto contará com três pessoas que exercerão os diversos papéis
necessários à execução do projeto para o desenvolvimento do software conforme
Tabela 4:
Papéis Responsável
Gerente de projeto Marcus
Analise de sistema Amilton e Marcus
Arquiteto Pedro
Desenvolvedor Amilton e Pedro
Testador Marcus
Tabela 4: Recursos humanos do projeto
Na Tabela 4 são apresentados os recursos humanos envolvidos no projeto e o papel
que cada um. O fato de ser uma equipe pequena alguns membros da equipe terão
que assumir mais de um papel.
2.4.2. Recursos de software
Não serão utilizados componentes de software, uma vez que não foram
encontrados componentes reutilizáveis que atendam aos requisitos especificados
para o nosso projeto.
2.4.3. Recursos do ambiente de desenvolvimento
Para o projeto será disponibilizado um ambiente com os seguintes
recursos:

14
Hardware: Três notebooks que servirão para o desenvolvimento do
projeto e dois computadores em rede local que servirão como servidor de
homologação, banco de dados e aplicações.
Software: Para o desenvolvimento do projeto foram utilizadas as
seguintes ferramentas de software:
● Star UML (Linguagem de Modelagem Unificada), software que modela
vários tipos de diagramas;
● MindMeister (www.mindmeister.com), uma ferramenta online para
criação de fluxogramas, mapas mentais e diagramas em geral;
● BROffice, processamento de texto para a criação dos documentos
disponibilizados;
● Microsoft Project 2007, utilizado para fazer o panejamento de todas as
tarefas do projeto;
● Chorme, browser de Internet.
3. ANÁLISE E GESTÃO DE RISCOS
3.1. RISCOS DO PROJETO
Há uma categoria de riscos que estão presentes em qualquer projeto de
software. Estes riscos são denominados riscos gerais e podem ser vistos na Tabela
5:
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 chave x x

15
Sub-estimativa do esforço x x
Desistência do único cliente
potencial
x x
Tabela 5: Identificação dos Riscos do Projeto
A Tabela 5 apresenta a identificação dos riscos do projeto, comum a maioria dos
projetos. Porém alguns riscos estão presentes em mais de uma categoria, o que
demanda mais atenção para o seu gerenciamento.
Avaliação Global do Risco:
1. O Gestor de Software dá suporte ao projeto?
Sim, o gestor de software é um participante importante e presente e todo
o desenvolvimento do projeto, inclusive na comunicação com os usuários.
2. Os Clientes estão entusiasmados com o projeto e o produto?
Sim, pois trará maior agilidade no processo de gestão das escolas e seus
serviços internos.
3. Os Engenheiros de Software compreenderam bem os requisitos?
Sim, os engenheiros de software estão bem conscientes dos requisitos do
projeto. Pois todos acompanharam o processo de como funciona a gestão das
escolas.
4. Os Clientes estiveram envolvidos na definição dos requisitos?
Sim, pois é de grande interesse por parte dos clientes que o sistema
contemple todas as funcionalidades.
5. O âmbito do projeto é estável?
Até o presente momento sim, pois como os clientes participaram do
levantamento dos requisitos, ainda não foram detectadas falhas que implicassem na
modificação do projeto.
6. Os engenheiros de software têm as competências requeridas?
Os engenheiros de software são competentes, já fazem parte de diversos
projetos da empresa.
7. Os requisitos do projeto são estáveis?
Não, pois existe a possibilidade de mudar os usuários responsáveis pelas
definições dos requisitos.
8. A equipe de desenvolvimento tem experiência na tecnologia que será
utilizada?

16
Sim, a equipe tem experiência com a tecnologia, pois já trabalha com a
mesma a algum tempo.
9. É adequado o número de pessoas da equipa de trabalho?
Sim, pois o tamanho do projeto e o prazo estimado atendem as
necessidades da empresa e dos clientes.
3.2. TABELA DE IDENTIFICAÇÃO DOS RISCOS
Na seguinte Tabela 6, encontram-se descritos todos os riscos
identificados no projeto. Os riscos estão enumerados da seguinte forma, na primeira
coluna encontra-se ID dos riscos, na segunda a descrição do risco, na terceira
coluna a categoria do risco, na quarta a probabilidadede o risco acontecer e na
quinta o tamanho de impacto que o risco pode causar no projeto.
ID Risco Categoria Probabilidade Impacto
04 Falta de acompanhamento da qualidade de
software por equipe especializada
maturidade 90% 5
02 Custo associado com produto defeituoso negócios 90% 5
07 Novos métodos de engenharia de software tecnologia 50% 4
05 Número de clientes que utilizam o software tecnologia 60% 4
03 Retenção de talentos pessoas 90% 4
08 Contratação de pessoas com habilidades pessoas 50% 4
01 Equipe sem treinamento necessário pessoas 80% 4
06 Custo com o atraso da entrega do produto negócios 50% 4
09 Interface para usuário específico tecnologia 20% 4
10 Dedicação dos funcionários pessoas 30% 4
11 Não acompanhar as fases do projeto cliente 70% 3
Tabela 6: Riscos do Projeto
Na Tabela 6 estão apresentados os riscos encontrados no projeto, organizado pela
categoria, probabilidade de ocorrência e seu impacto esperado no projeto. As
estratégias de redução dos mesmos podem ser observadas na seção 3.3.

17
3.3. REDUÇÃO E GESTÃO DE RISCO
Dos riscos elencados, escolhemos nove deles para descrevermos as
suas atividades de redução, supervisão e gestão do risco.
Risco: 01 Prob: 80% Impacto: Crítico
Descrição: Equipe sem treinamento necessário
Estratégia de redução: Surgerir que os membros participem de treinamentos e
discursões em grupo como atividade corporativa.
Plano de contigência: Realizar treinamentos e fazer parcerias com centros de
treinamentos especialisados.
Pessoa responsável: Pedro Felipe de Lima
Status: Adquirindo informações para iniciar o treinamento
Risco: 02 Prob: 90% Impacto: Catastrófico
Descrição: Custo associado com produto defeituoso
Estratégia de redução: Utilizar processos de testes no produto.
Plano de contigência: Iniciar o processo de testes paralelo ao desenvolvimento, para
reduzir o número de erros.
Status: Planejando processo de testes
Descrição: Retenção de talentos
Estratégia de redução: Acompanhar a motivação dos funcionários em relação às suas
atividades e investigar suas necessidades diante do ambiente de trabalho. Desenvolver
atividades motivadoras para os membros.
Plano de contingência: Realizar backups e Manutenção nos computadores
Status: Criando atividades motivadoras
Risco: 04 Prob: 90% Impacto: Catastrófico
Descrição: Falta de acompanhamento da qualidade de software por equipe
especializada.

18
Estratégia de redução: Dedicar pessoas e tempo aos testes de software.
Plano de contingência: Selecionar novos engenheiros de testes.
Pessoa responsável: Amilton José
Status: Realizando pesquisas
Descrição: Número de clientes que utilizam o software
Estratégia de redução: Iniciar testes de stress para avaliar o desempenho e identificar
os limites de utilização do software.
Plano de contingência: Aumentar o número de servidores dedicados ao produto e
realizar acompanhamento diário do desempenho do produto.
Status: Implementando testes de peformance
Descrição: Custo com o atraso da entrega do produto
Estratégia de redução: Acompanhamento intesivo do desenvolvimento do projeto e
suas atividades.
Plano de contingência: Parcerias com empresas de desenvolvimento terceirizada.
Status: O acompanhamento das atividades de desenvolvimento foram iniciados.
Descrição: Novos métodos de engenharia de software
Estratégia de redução: Treinar a equipe de desenvolvimento com as versões
mais atuais para desenvolvimento.
Plano de contingência: Renegociar data de entrega do produto.
Pessoa responsável: Marcus Côrtes
Status: Treinamento realizado.
Descrição: Contratação de pessoas com habilidades
Estratégia de redução: Realizar um seleção rigorosa durante a contração do
envolvidos no desenvolvimento do projeto.
Plano de contingência: Contratar novos desenvolvedores habilitados.

19
Status: Seleção realizada
Risco: 09 Prob: 20% Impacto: Moderado
Descrição: Interface para usuário específico
Estratégia de redução: Desenvolver interface desde do inicío do projeto para
despositivos móveis e respeitando regras de usabilidade e acessibilidade.
Plano de contingência: Contratar uma equipe tercerizada focada em desenvolvimento
acessivel.
Status: Desenvolviemento iniciado pela própria equipe
Tabela 7: Planos de redução de riscos
Na Tabela 7 estão apresentados os planos de redução de riscos do projeto. São
apresentados os riscos ao processo de desenvolvimento, à segurança,
implementação do sistema e qualidade.
4. PLANEJAMENTO TEMPORAL
Nesta seção, apresentam-se as tarefas e as suas dependências de forma
a estimar a duração total do projeto. Por toda a secção, deverão ser apresentadas
as saídas (gráficos, relatórios, etc.) da ferramenta de apoio utilizada na Gestão do
Projeto (MS Project, etc.). Portanto, explorem bastante a ferramenta automatizada
para a gestão de projecto que a sua equipa está utilizando.
4.1. DIAGRAMA DE GANTT
Aqui são apresentados o modelo de processo escolhido e as suas atividades
e tarefas que foram escolhidas para serem apresentadas nesta secção.
O diagrama de gantt é responsável pela organização de cada atividade. Visto
que as tarefas estão associadas a um ou mais elementos do projeto. Na Ilustração
1, está o diagrama de gantt para o projeto do sistema para escola de línguas.

21
Ilustração 1: Cronograma A do Projeto

22
Ilustração 2: Cronograma B do Projeto

23
Ilustração 3: Cronograma C do Projeto

24
Ilustração 4: Cronograma D do Projeto

25
5. ORGANIZAÇÃO DO PESSOAL
A equipe do projeto segue um processo democrático, pois acredita que
assim o projeto terá mais resultados, as decisões são tomadas em conjunto e em
consenso de todos os envolvidos, onde há comunicação. Sendo assim acabamos
tendo um ambiente melhor e satisfatório para trabalhar.
5.1. ESTRUTURA DA EQUIPE
A tabela a seguir mostra como a equipe é formada, por três membros,
onde no início dos trabalhos foram definidos claramente as funções de cada um,
sendo:
Nome Email Papéis
Amilton Azevedo amilton_a2@hotmail.com
Engenheiro de Software,
Desenvolvedor e Analista
de Qualidade
Pedro Felipe pedroo_felipe@hotmail.com
Engenheiro de Software,
Desenvolvedor e Arquiteto
Marcus Côrtes Marcus_cortes@hotmail.com
Gerente de Projetos e
Analista de Sistemas
Tabela 8: Estrutura da Equipe
Na Tabela 8 são apresentados a estrutura da equipe com os membros envolvidos no
projeto, contato de email e o papel que cada um.
A tabela abaixo mostra a descrição das atividades que são utilizadas e
executadas pelos membros da equipe
Papel Descrição
Gerente de Projetos
Responsável pelo Planejamento e
acompanhamento das atividades. Aloca recursos,
dimensiona tarefas e interage com o cliente.

26
Analista de Sistemas
Realiza o levantamento e análise de requisitos do
software.
Engenheiro de Software
Responsável pelo desenvolvimento do projeto e
pelo design da aplicação.
Analista de Qualidade
Identifica e gerencia iniciativas de melhoria da
qualidade no âmbito organizacional, apoia a
gerência em atividades de controle de projetos de
captação de recursos e eventos; adota e mantém
normas de qualidade da organização.
Arquiteto de Software
O arquiteto conhece diversas tecnologias e
possui uma vasta experiência em projetos. Terá
um grau de responsabilidade em definir qual a
melhor solução para um certo problema na
empresa.
Tabela 9: Descrição das Atividades
Na Tabela 9 são apresentados a descrição das atividades do envolvidos no projeto.
Dividido por: Gerente de Projetos; Analista de Sistemas; Engenheiro de Software;
Analista de Qualidade e Arquiteto de Software.
5.2. MECANISMOS DE COMUNICAÇÃO
O processo de comunicação foi feito através de ferramentas de
mensagens instantaneas e Emails como: WhatsApp, Skype, Email, Google Docs e
Dropbox. O acompanhamento do projeto ocorrerá semanalmente de forma
presencial com todos os membros da equipe, de forma a discurtir e criar soluções
para o andamento do projeto, resolver problemas em conjunto e distribuir as tarefas.
5.3. USO DO EDU-BLOG COMO FERRAMENTA DE APOIO
O Edu-blog foi uma ótima ferramenta de grande utilidade para o aprendizado e a
organização do projeto. Permitiu uma comunicação do professor e o alunos muito

27
satisfatória, pois o professor disponibilizava o conteúdo referente a disciplina e realizava
atividades nas aulas. A ideia do Edu-blog é levar aos membros aprendizado, concepção de
ideias, organização e satisfação de parte de todos os membros da equipe.
6. QUALIDADE
A equipe fez uso dos itens a seguir durante todo o projeto de forma a
garantir e controlar a qualidade do produto de software:
Gestão do Projeto de Software – É realizado um acompanhamento
constante das atividades desenvolvidas por parte de todos os envolvidos no projeto.
Revisões Técnicas Formais – As revisões são realizadas por pessoas
capacitadas durante todo o ciclo, visando à identificação de erros nas fases iniciais
do projeto, onde o custo para a manutenção é menor.
Gestão de Configuração do Software – Existe um controle a cada
versão do software e dos documentos gerados, visando à integridade de ambos ao
longo do seu ciclo de vida.
Métricas de Quantidade – São realizadas medições para verificar o
quanto o software atende aos requisitos impostos pelo usuário/cliente.
Análise de Riscos – Identificação, análise e controle dos riscos,
elaborando-se planos de redução e de contingência.
Testes – São realizados testes dentro de um processo definido, com o
objetivo de identificar possíveis erros antes que estes se transformem em defeitos e
tornem-se riscos, trazendo prejuízos para a empresa.

28
7. REFERÊNCIAS
Nascimento, R. P. (27 de Outubro de 2010). Edu - Blog > Engenharia de Software :: PROCC. Acesso em
8 de Abril de 2014, disponível em http://pt.scribd.com/doc/40267617/Modelo-Plano-Projeto-de-SW-
OO
Pressman, R. S. (2011). Engenharia de Software - Uma Abordagem Profissional (7ª ed.). Porto Alegre:
AMGH.
Pressman, R. S. (s.d.). R.S. Pressman & Associates, Inc. Acesso em 4 de Abril de 2014, disponível em
http://www.rspa.com/docs/Projectplan.html
SCRUM.ORG, Scrum, disponível em http://scrum.org. Acesso em: 14 abril 2014
WIKIPEDIA, Scrum (development), disponível em:
http://en.wikipedia.org/wiki/Scrum_(development) Acesso em: 14 abril 2014

Eng software

Mais conteúdo relacionado

Mais procurados (16)

Semelhante a Eng software (20)

Último (20)

Eng software