(8081 - 25516) Pratica - Programacao - Web

Prática em Programação para Web
Universidade do Sul de Santa Catarina

Desenvolver um projeto web é um desafio
necessário para a formação acadêmica na área
tecnológica. A partir da estrutura conceitual do
projeto – devidamente elaborada em Prática em
Gestão de Projetos – agora é o momento para
Prática em
executar o que foi previamente planejado.
Prática em Programação para Web trará

orientações sobre a etapa de execução e
documentação do projeto.
Programação
para Web
w w w. u n i s u l . b r
Prática em
Programação
para Web
UnisulVirtual
Palhoça, 2015
Créditos
Universidade do Sul de Santa Catarina – Unisul

Reitor
Sebastião Salésio Herdt
Vice-Reitor
Mauri Luiz Heerdt
Pró-Reitor de Ensino, de Pesquisa e de Extensão

Mauri Luiz Heerdt
Pró-Reitor de Desenvolvimento Institucional
Luciano Rodrigues Marcelino
Pró-Reitor de Operações e Serviços Acadêmicos
Valter Alves Schmitz Neto
Diretor do Campus Universitário de Tubarão

Heitor Wensing Júnior
Diretor do Campus Universitário da Grande Florianópolis
Hércules Nunes de Araújo
Diretor do Campus Universitário UnisulVirtual
Fabiano Ceretta
Campus Universitário UnisulVirtual

Diretor
Fabiano Ceretta
Unidade de Articulação Acadêmica (UnA) - Educação, Humanidades e Artes

Marciel Evangelista Cataneo (articulador)
Unidade de Articulação Acadêmica (UnA) – Ciências Sociais, Direito, Negócios e
Serviços
Roberto Iunskovski (articulador)
Unidade de Articulação Acadêmica (UnA) – Produção, Construção e Agroindústria
Diva Marília Flemming (articuladora)
Unidade de Articulação Acadêmica (UnA) – Saúde e Bem-estar Social
Aureo dos Santos (articulador)
Gerente de Operações e Serviços Acadêmicos

Moacir Heerdt
Gerente de Ensino, Pesquisa e Extensão
Roberto Iunskovski
Gerente de Desenho, Desenvolvimento e Produção de Recursos Didáticos
Márcia Loch
Gerente de Prospecção Mercadológica
Eliza Bianchini Dallanhol
Cynthia Beatriz Scheffer Dutra
Flavia Lumi Matuzawa (Org.)
Prática em
Programação
para Web
Livro didático
Designer instrucional
Flavia Lumi Matuzawa
UnisulVirtual
Palhoça, 2015
Copyright © Nenhuma parte desta publicação pode ser reproduzida por
UnisulVirtual 2015 qualquer meio sem a prévia autorização desta instituição.
Livro Didático
Professoras conteudistas Projeto gráfico e capa

Cynthia Beatriz Scheffer Dutra Equipe UnisulVirtual
Flavia Lumi Matuzawa (Org.)
Diagramador
Designer instrucional Oberdan Piantino
Flavia Lumi Matuzawa
Revisora
Diane Dal Mago
005.1
P92 Prática em programação para web : livro didático / Flavia Lumi
Matuzawa, organizadora; Cynthia Beatriz Scheffer Dutra, [conteudista] ; design
instrucional Flavia Lumi Matuzawa. – Palhoça : UnisulVirtual, 2015.
50 p. : il. ; 28 cm.
Inclui bibliografia.
1. Logística empresarial. I. Oliveira, Cristina Klipp de. II. Titulo.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

Sumário
Introdução | 7
Capítulo 1
Projeto Integrador Web e a etapa de execução | 9
Capítulo 2
Etapas práticas do Projeto Integrador Web II | 17
Considerações Finais | 45
Referências | 47
Sobre o Professor Conteudista | 49

Introdução
Caro aluno,
Situações novas sempre trazem momentos de dúvidas, algumas inseguranças,

mas também há esperanças e desafios. Assim é a nossa caminhada pessoal e
profissional: a cada etapa concluída, novos desafios surgem pela frente. Uma
verdadeira caminhada de superação.
Agora é o momento de uma nova etapa em sua formação: após estudar e adquirir
conhecimentos teóricos sobre projeto, design e programação, chegou o momento
de integrar, sistematizar e consolidar esses conhecimentos.
Esse desafio acontecerá na forma da elaboração de um projeto prático. Esse

projeto está organizado em dois momentos: o primeiro acontece no estudo de
Prática em Gestão de Projetos, quando você definirá toda a estrutura do projeto,
e o segundo momento acontece em Prática em Programação para Web, quando
o desenvolverá na prática.
Cabe a esta Unidade de Aprendizagem, Prática em Programação para Web,

apresentar a você informações acerca da execução e avaliação do projeto.
Considerando que todo o desenvolvimento dele foi feito em Prática em Gestão de
Projetos, agora é o momento de executá-lo e encerrar com um relatório completo
de todo o processo.
Pode ser que em algum momento durante esta caminhada você sinta cansaço ou
insatisfação. Mas o encorajamos a usar esses momentos a seu favor, como meios
de motivação para chegar a um final exitoso. Acredite em sua capacidade de
superar obstáculos e de se organizar para desenvolver um bom projeto!
Bom trabalho!
Professoras Cynthia Beatriz Scheffer Dutra
e Flavia Lumi Matuzawa
Capítulo 1
Projeto Integrador Web e a

etapa de execução
Seções de estudo Seção 1: Uma visão geral dos elementos do

PIWEB II
Seção 2: O processo de avaliação do PIWEB II
Seção 3: A estrutura e o ponto de partida para

desenvolver o PIWEB II
Capítulo 1
Seção 1
Uma visão geral dos elementos do PIWEB II
Na Unidade de Aprendizagem Prática em Gestão de Projetos, são apresentadas
as partes e os elementos que compõem o desenvolvimento do projeto web.
Este projeto web foi referenciado como Projeto Integrador Web (PIWEB).
Para padronizar e facilitar a continuidade do desenvolvimento deste projeto,
manteremos essa nomenclatura.
O conceito de projeto integrador é crucial para o entendimento das habilidades

a serem desenvolvidas neste momento, uma vez que “a finalidade principal
do projeto integrador é o desenvolvimento de uma atividade que consolide
conhecimentos, permitindo formar profissionais com capacidade de empreender
e inovar”. (DUTRA, 2007). Estar apto para visualizar uma necessidade real e
traduzi-la em sistemas que possam contribuir ao trabalho, trazendo inovação
e tecnologia, é uma prática que requer o conhecimento geral de processos de
desenvolvimento de sistemas.
Para cumprirmos esse desafio, o projeto integrador assume duas etapas

importantes, conforme a Tabela 1 indica:
Tabela 1 – Visão geral da abrangência do Projeto Integrador Web
Unidade de Aprendizagem Desenvolvimento das Partes do Projeto
Prática em Gestão de Projetos Projeto Integrador Web I (PIWEB I)
Prática em Programação para Web Projeto Integrador Web II (PIWEB II)
Fonte: Elaboração da autora (2015).
Em Prática em Gestão de Projetos você desenvolveu a primeira parte do projeto,

que chamamos de Projeto Integrador Web I (PIWEB I). Neste momento, o foco
foi a criação de um projeto de sistema Web pelos alunos, de forma a integrar os
diversos conhecimentos adquiridos no curso até o presente módulo, objetivando
demonstrar suas habilidades e suas competências específicas adquiridas.
Agora, em Prática em Programação para Web, começamos uma fase de

execução, análise de desempenho, ajustes e encerramento do projeto como um
todo. Esse será o momento de desenvolver, na prática, o que foi planejado em
Práticas na Gestão de Projetos.
10
Atenção: neste momento, aproveite para reunir os formulários de PIWEB I,

pois eles comporão o relatório final de seu projeto, que deverá ser entregue
ao final de PIWEB II.
Lembre-se que o PIWEB possui uma concepção semelhante a de um projeto de

pesquisa. Seguindo esse entendimento, você pode perceber que o PIWEB foi
concebido com uma estrutura de análise, estudo e desenvolvimento de sistemas
computacionais em ambientes web, permitindo a criação de soluções, melhoria
de serviços e resolução de problemas. Por ter um caráter prático, o PIWEB é
considerado uma atividade de pesquisa aplicada e o aluno é considerado, neste
momento, um pesquisador.
Ao final de todo o desenvolvimento do projeto, além do projeto executável, você

precisará entregar um relatório apresentando todas as etapas desenvolvidas
nessa atividade. Adiante veremos os elementos que comporão esse relatório.
Seção 2
O processo de avaliação do PIWEB II
Está claro para você, desde Práticas em Gestão de Projetos, que os projetos
são diferentes, variando desde a escolha do tema como a própria experiência
e conhecimentos prévios. Por isso em PIWEB considera-se o todo: como o
aluno está pensando, que recursos ele consegue usar, que relações consegue
estabelecer, que operações realiza ou inventa, como é o seu desenvolvimento ao
longo das partes.
Esse desenvolvimento será acompanhado pelo professor por meio do Espaço

Virtual de Aprendizagem (EVA). Nesse espaço, o aluno poderá enviar as etapas de
seu projeto e interagir com o professor.
As atividades a distância a serem avaliadas estão organizadas em formulários.
Nos formulários ficarão registradas todas as etapas do trabalho, bem

como contribuições, descobertas, reflexões realizadas pelo aluno/grupo de
alunos. O professor, por sua vez, terá bases claras e objetivas para avaliar o
desenvolvimento do aluno.
11
Capítulo 1
Os seguintes critérios serão observados para avaliação do PIWEB:
•• consonância do projeto concluído com o que foi proposto;

•• clareza e objetividade das atividades descritas para o projeto;
•• lógica da apresentação dos conteúdos em relação ao alcance dos
objetivos propostos;
•• criatividade, ideias inovadoras, capacidade de argumentação teórica
e prática, pertinência e/ou relação com os conteúdos programáticos
do curso;
•• utilidade e aplicabilidade dos resultados alcançados para a
organização do objeto de investigação e/ou para o meio;
•• utilização dos recursos do EVA para integração com a equipe e
entre equipes;
•• participação em debates propostos nas ferramentas de
comunicação do EVA;
•• preenchimento correto dos campos de todos os formulários;
•• pontualidade no cumprimento dos prazos de envio das atividades,
preestabelecidos no cronograma da unidade de aprendizagem,
disponível no EVA.
Algumas observações importantes:
•• a sua avaliação nessas duas unidades de aprendizagem - Práticas

em Gestão de Projetos e Prática em Programação para web -
será verificada por meio do desempenho progressivo frente aos
objetivos propostos no plano de ensino e contabilizada por meio das
Avaliações a Distância (AD), que estão disponibilizadas no Espaço
UnisulVirtual de Aprendizagem (EVA);
•• os professores deverão atribuir notas de zero a dez para cada uma
das atividades propostas. Será considerado aprovado o aluno que
obtiver a média mínima estabelecida no Manual do Curso;
•• não ocorrerá Avaliação Final em Práticas em Gestão de Projetos e
Prática em Programação para Web. A avaliação dessas disciplinas
sempre será o resultado da construção progressiva do projeto
desenvolvido pelo aluno.
12
Seção 3
A estrutura e o ponto de partida para
desenvolver o PIWEB II
Para o desenvolvimento do PIWEB II, será necessário o cumprimento de algumas
etapas propostas como atividades. A sugestão para o bom andamento do seu
projeto é que você primeiro leia as atividades que deverá fazer, estude seu
detalhamento teórico e, em seguida, realize as atividades propostas.
Em PIWEB I você realizou a etapa de planejamento de atividades, análise e

definição dos recursos mobilizados, e viabilizou a integração dos recursos,
distribuindo as tarefas entre os membros da equipe. Podemos dar por concluídas
quatro etapas do desenvolvimento do projeto. Essas etapas foram:
•• Etapa 1 – identificação do escopo do projeto;

•• Etapa 2 – escopo do projeto;
•• Etapa 3 – análise do projeto;
•• Etapa 4 – planejamento do projeto.
Agora, em PIWEB II, você inicia a etapa de acompanhamento da execução,

com a medição dos resultados obtidos e revisão, quando, então, o ciclo reinicia,
se necessário. Passamos a realizar o projeto propriamente dito: execução,
acompanhamento, avaliação e encerramento do projeto. Para isso, iremos realizar
as etapas subsequentes do desenvolvimento, ou seja, serão implementadas em
PI Web II:
•• Etapa 5 – execução e avaliação do projeto;

•• Etapa 6 – encerramento de projeto;
•• Etapa 7 – documentação do Projeto Integrador Web.
Essas três etapas finais serão organizadas para serem entregues em dois
momentos marcados pelas Avaliações a Distância 1 e 2. Observe no quadro
a seguir.
13
Capítulo 1
Quadro 1 – Visão geral das atividades propostas para a primeira etapa do Projeto Integrador
Web II (PIWEB II)
Prazo de
Etapa Atividade Descrição Desdobramento da atividade entrega
1 Relatórios de • Cronograma atualizado. AD1

acompanhamento
• Verificação de índices de
desempenho
1. Execução e avaliação do Projeto
2 Revisão do Projeto • Modificações
• Ajustes
3 Protótipo • Apresentação
• Demonstrativo
• Simulação
4 Projeto-piloto • Apresentação
• Implantação
• Testes
• Validação
5 Projeto Final • Entrega/apresentação final AD2
• Medição dos resultados

2. Encerramento do Projeto
6 Considerações finais • Lições aprendidas
• Novas ideias e oportunidades
7 Referências • Reunir todas as referências

utilizadas durante o PIWEB
8 Anexos e apêndices • Reunir dados, cálculos,

programas, algoritmos etc.
• Material de apoio para a

execução do projeto
9 Documentação • Reunir todas as partes do

3. Documentação
PIWEB I e II
Fonte: Dutra (2007, p. 32).
14
Observe que você terá a etapa de (a) Execução e avaliação do projeto; (b) o
Encerramento do Projeto e (c) a Documentação. Essas três etapas deverão
ser desenvolvidas neste semestre letivo e culminar com a entrega do projeto
finalizado, executável e devidamente documentado.
15
Capítulo 2
Etapas práticas do Projeto

Integrador Web II
Seções de estudo Seção 1: Etapa 5: execução e avaliação do projeto
Seção 2: Etapa 6: encerramento de projeto
Seção 3: Etapa 7: documentação do Projeto

Integrador Web.
Capítulo 2
Seção 1
Etapa 5: execução e avaliação do projeto
É a hora de partir para a ação. Aqui a equipe deverá executar o que foi planejado
na primeira etapa de seu projeto. Como ponto de partida, será utilizado o
fluxograma, desenvolvido em PIWEB I, o qual corresponde à etapa de execução
das atividades.
Nesta etapa de execução e avaliação do projeto, a equipe deve fazer uso dos
recursos materiais que foram mobilizados e iniciar o desenvolvimento das
atividades designadas a um dos membros no planejamento da divisão do
trabalho. Boa parte do esforço e orçamento do projeto é consumida nesta fase.
Durante a execução, em muitos momentos, a equipe precisará se reunir e tomar

decisões importantes que estão relacionadas ao controle da execução do projeto.
Segundo (FACCIONI, 2006), a tomada de decisão durante um projeto envolve
quatro passos:
1. identificar possíveis modos de ação e chegar a um entendimento

comum do que cada opção significa;
2. identificar as ramificações de cada opção, incluindo vantagens e
desvantagens;
3. discutir e avaliar cada uma dessas ramificações;
4. escolher o modo de ação mais vantajoso e então partir para ele.
Observe que há a necessidade da constante avaliação das opções possíveis e

disponíveis. Em um projeto de desenvolvimento de uma inovação tecnológica, de
um software, de um novo produto, haverá, com certeza, várias reuniões, dessa
forma, caberá a cada um de vocês interferir para garantir o seu bom andamento.
É interessante que cada integrante da equipe tenha uma visão do conjunto do
projeto e não apenas das partes. Com isso, as discussões entre os membros
da equipe nas reuniões auxiliarão a definir as próximas ações do projeto. Daí a
sua importância.
O início da execução do projeto deve acontecer com uma reunião. Nessa reunião,
o escopo do projeto deve ser exposto com a maior clareza possível, os detalhes
devem ser discutidos até a exaustão, o plano de trabalho deve ser detalhado, as
tarefas divididas e as responsabilidades delegadas.
Durante as reuniões do projeto deve ser designado um membro da equipe para

anotar todos os pontos principais discutidos, bem como as resoluções adotadas,
a fim de compor relatórios de acompanhamento de projeto.
18
Veja um exemplo de relatório de acompanhamento para o “Sistema Hydros”,

supondo que foram realizadas as atividades do 1º. Bimestre de 2006.
Avaliação do acompanhamento dos trabalhos em 01 de abril de 2006
“Verificou-se um pequeno atraso na definição da forma de acesso, levando a um

atraso no início da etapa 4. Entretanto, a primeira parte dos trabalhos realizados
na etapa 4 foi finalizada antes do prazo estipulado, já a segunda parte está
bastante adiantada.
Por conta do atraso na chegada da plataforma de controle referente à etapa 2,

foi determinado um adiantamento no início da atividade de “leitura das entradas”,
sendo esta executada junto com a atividade “acionamento dos motores”. Dessa
maneira, não houve comprometimento do cronograma dos trabalhos seguintes,
tanto que a parte seguinte “abertura e fechamento das válvulas” está dentro
do prazo planejado. Também, devido ao atraso na entrega da plataforma de
desenvolvimento da interface Web, o início da parte “criação das telas” foi atrasada,
o que levou a um atraso nos trabalhos seguintes. Apesar do atraso no início
dos trabalhos e da morosidade na execução, o projeto como um todo não está
comprometido, pois o resultado dos trabalhos desta fase somente é integrado ao
sistema na etapa final do projeto.
Desse modo, um fator fundamental para o bom andamento do trabalho é a clara

comunicação entre a equipe e interessados (no caso o orientador/tutor) sobre
o andamento do projeto. As reuniões devem estar embasadas na proposta de
planejamento do Gráfico de Gantt, buscando cumprir etapas de acordo com o
estabelecido no cronograma de atividades original. A comunicação, seja inicial ou
a cada etapa do projeto, deve se dar sobre tal gráfico e deve ser acompanhada
da marcação sobre o “já realizado” e sobre o que falta realizar. A comunicação
clara das atividades deve ser feita a cada momento importante, tal como inícios
e encerramentos de etapas do projeto. Uma vez anotado o acompanhamento
do projeto no cronograma, mantendo o Gantt atualizado, fica mais claro
que decisões tomar em caso de atrasos, e até mesmo verificar quem são
os responsáveis.
Veja o Gantt atualizado para o “Sistema Hydros”, Figura 1, supondo que foram
realizadas as atividades do 1º. Bimestre de 2006.
Os triângulos mostram as datas iniciais e finais de cada tarefa previstas no

cronograma inicial. As barras refletem as adequações do cronograma para as
tarefas ainda não realizadas (barras mais escuras), em curso (barras parcialmente
preenchidas) e a duração das tarefas já finalizadas (barras mais claras).
19
Capítulo 2
Figura 1 – Gráfico de GAntt do projeto “Sistema Hydros”, atualizado após o 1º bimestre
Fonte: elaboração da autora, 2015.
De posse do Diagrama de Gantt atualizado, com acompanhamento constante

das etapas realizadas, você poderá fazer o controle e gerenciamento do tempo
e dos recursos do projeto, sabendo dos custos envolvidos e do tempo gasto a
cada momento. Além disso, considerando que estamos gerenciando qualidade,
recursos e tempo, precisamos buscar a “perfeição” para atingir nossa meta
de projeto. Essa “perfeição” pode ser interpretada como ausência de erros. É
nessa fase que precisamos verificar os indicadores de desempenho do projeto
para poder saber quão perto (ou longe) estamos de alcançar nossos objetivos
específicos, que compõem o projeto como um todo. Ações corretivas e /ou
preventivas, no menor espaço de tempo possível, devem ser tomadas após a
detecção de anormalidades. A busca por esta qualidade total exige entusiasmo
e motivação no dia a dia de cada etapa do projeto. Deve-se fazer a revisão do
projeto analisando os resultados encontrados na medição do desempenho e o
acompanhamento no cronograma de Gantt. Pode-se ainda fazer uso de outras
ferramentas como gráficos e tabelas de custo, listagem de atividades em aberto,
pautas discutidas em reuniões, relatórios de acompanhamento etc. Dependendo
dos valores encontrados em relação aos indicadores de desempenho, é possível
replanejar o projeto e avaliar as condições de tempo restante e de recursos
disponíveis e ainda necessários.
Veja um exemplo de como verificar os indicadores de desempenho para o

“Sistema Hydros”, após ter realizado as atividades do 1º. Bimestre de 2006.
20
Avaliando os indicadores:
• Cronograma: Atraso na execução.

Houve atraso, mas conseguiu-se compensar o desvio adiantando outras
etapas e contornando o problema original.
• Orçamento: Não houve violação dos valores orçados.

O orçamento permanece controlado dentro dos valores esperados.
• Tecnologia/ Operacionais:
Esses indicadores não podem ser avaliados, pois são variantes que ainda
não entraram na execução do projeto.
Atenção!
Replanejar pode ser o estopim de um conflito na equipe. O trabalho em equipe é,

quase sempre, um ambiente de conflitos. Isso acontece devido ao dinamismo dos
pensamentos e sentimentos humanos em constante movimento e readequação.
Considerando tal possibilidade, será função do gestor escolher a maneira de
lidar com o conflito, garantindo tranquilidade ao andamento do projeto, dentro
dos prazos e metas estabelecidos previamente. Com certeza, a melhor forma
de administrar os conflitos ocorre quando são percebidos o mais cedo possível.
Como o caso de muitas doenças, se o conflito for detectado no início é mais fácil
de curar e, se muito tarde, pode ser impossível, por isso a atenção do gestor
é primordial (FACCIONI, 2006). O conhecimento prévio dos principais tipos de
conflitos que podem se desenvolver no projeto auxilia na tomada de decisões,
que permite minimizar ou lidar melhor com eles em cada etapa do projeto.
Veja outro exemplo que aborda agora o replanejamento do projeto feito sem
análise, sem consultar a equipe de desenvolvimento, gerando conflitos de
tal proporção que causou o fracasso de um projeto ( consequentemente, de
uma empresa).
Mau planejamento – Techlink
O objetivo do projeto dessa empresa era o desenvolvimento de equipamentos que

permitissem a negociação financeira por meio de cartões de crédito/débito. Esses
equipamentos, chamados de PDV (postos de venda), consistiam de uma unidade
de leitura do cartão, display e teclado, e outra que permitia a conexão telefônica
com a operadora do cartão. Apesar dos componentes utilizados serem importados,
toda a tecnologia do equipamento era própria.
21
Capítulo 2
O desenvolvimento iniciou tendo-se uma ideia do que seria o produto final, porém,
sem formalização das etapas do desenvolvimento nem das características finais.
Não havia “tempo” para planejar – as etapas do projeto foram sendo desenvolvidas
de forma independente. No momento de integrá-las, foram encontrados vários
problemas conceituais, devido à falta de comunicação e definições de projeto entre
os membros de diferentes equipes.
Por conta disso, várias características foram modificadas para minimizar o problema.
Quando finalmente o projeto estava se encaminhando para o produto final, houve
uma nova alteração. Para satisfazer o desejo de um dos diretores em incorporar
uma determinada funcionalidade adicional (não prevista no projeto inicial, mas que
segundo ele promoveria vendas em números estratosféricos), uma série de ajustes
e modificações foram solicitadas pela direção, para a equipe de desenvolvimento.
Como se não bastasse, em paralelo, a empresa “vendeu” a ideia de que o
equipamento já era capaz de realizar integralmente todas as funcionalidades.
Devido às mudanças no projeto, novos problemas foram aparecendo, obrigando
funcionários a trabalhar madrugadas e finais de semana para tentar finalizar o
desenvolvimento na data prevista. A pressão foi tanta que os conflitos não paravam
de aparecer e acontecer. Agora, eram técnicos, interpessoais e interequipes
de desenvolvimento. Mesmo com carga excessiva de trabalho, a entrega dos
equipamentos foi sendo adiada repetidas vezes. Com a série de atrasos ocorridos,
o cliente acabou cancelando a compra. A empresa que contava com essa venda
para financiar o desenvolvimento de novos projetos acabou abandonando o projeto
e demitindo todos os seus funcionários. Faliu em menos de seis meses, e ainda
acumulou vários processos trabalhistas que permanecem tramitando na justiça.
A ideia do produto era boa e os projetistas excelentes. O que deu errado?

Basicamente, tudo – por falta de planejamento! A pressão e os conflitos gerados
venceram a capacidade técnica da equipe. Com uma “ajudinha” da péssima
gestão, é claro.
Lembre-se!
A execução é o momento crucial do projeto. Temos que ter em mente que,

durante a execução, estamos trabalhando com pessoas: gestor e membros de
equipe. O grande desafio é mantê-los integrados e focados no objetivo geral do
projeto. E isso não é uma tarefa fácil! Não basta manter todos trabalhando no
projeto, é preciso que o façam com harmonia.
22
Em geral, quanto melhor for o planejamento anterior, as definições do escopo e

a identificação de recursos e de atividades, melhor deve ser o resultado neste
período de execução do projeto, menos interrupções e menos retrabalhos. A
execução do projeto deve, simplesmente, espelhar o que foi previsto. Fazer
acontecer o plano de trabalho do projeto – executando as atividades neles
contidas – é nosso objetivo nesta fase do projeto (MENEZES, 2001).
Ações de execução diretas de projeto <nível_1>
Enumeramos, agora, algumas atividades consideradas típicas da execução de

projeto (MENEZES, 2001). Você poderá utilizá-las como um checklist para realizar
o acompanhamento de seu projeto e ainda agregar as atividades específicas que
seu projeto exige que sejam desenvolvidas:
1. Verificar o escopo: a ação de verificação do escopo compreende

a formalização do conhecimento e do conteúdo dos trabalhos
que devem ser desenvolvidos. Introduz uma postura proativa
ao desenvolvimento do projeto, ao se procurar fazer o trabalho
segundo o esperado;
2. Ativar a comunicação entre os membros da equipe de
execução: essa ação compreende o fornecimento de informações
e de entradas/insumos necessárias à execução das atividades
do projeto;
3. desenvolver a equipe de execução: tal ação diz respeito às
atividades necessárias para que as habilidades individuais e
em equipe possam ser potencializadas para o alcance de bons
indicadores de desempenho no projeto. Essa atividade compreende
identificar as necessidades de cada membro da equipe e dar o
devido atendimento para todas aquelas que forem vitais para a
consecução do projeto;
4. garantir a disponibilidade de recursos: quando falamos em
disponibilidade de recursos, estamos tratando de lidar com
fornecedores externos ao projeto. Essa ação de garantia de
recursos disponíveis envolve fazer os pedidos, análises de preços,
ofertas e propostas de aquisição etc., para garantir a entrega
nas condições desejadas e prazos estipulados. É o gestor da
equipe que deve relacionar-se com os fornecedores e garantir a
disponibilidade de recursos previstos durante o planejamento para a
fase da execução;
5. mobilizar a equipe, equipamentos e materiais: sempre que
falamos em mobilizar recursos, estamos nos referindo à busca
de recursos internos da empresa ou organização vinculada
23
Capítulo 2
ao projeto. A mobilização de recursos constitui a ação de

sensibilizar e disponibilizar os recursos para o início da execução
de cada atividade;
6. executar as atividades previstas no plano de trabalho do
projeto: detalhar a execução das atividades – como previsto –
nada mais é que a ação de concretização dos planos e o uso
dos recursos disponibilizados pelas ações anteriores. Durante a
execução podem ser necessários procedimentos específicos para a
análise e a solução de problemas;
7. assegurar a qualidade: assegurar a qualidade na execução do
projeto é uma ação, em geral, mantida pelo uso dos mecanismos de
controle e avaliação desenvolvidos e pelo emprego dos indicadores
de desempenho e medidas de análise e solução de problemas,
frente às tendências que se apresentam para os resultados das
atividades do projeto;
8. monitorar o uso de recursos: essa ação envolve o dia a dia da
execução do projeto. Deve ser feito um apontamento sobre a
alocação dos recursos, de modo a otimizar seu uso pela equipe
durante a execução do projeto;
9. distribuir as informações: ação que significa obter informações,
tratá-las, avaliá-las e distribuí-las a todos os envolvidos no projeto,
conforme o plano de comunicação estabelecido entre a equipe;
10. gerar alternativas de ação em direção ao planejado: observados
os desvios no projeto, a equipe deve reunir-se para buscar
alternativas de soluções que restabelecem o rumo da execução aos
objetivos do projeto.
11. reprogramar atividades: feita a análise e avaliação de desvios
e posterior geração de alternativas, resta provocar ações que
definitivamente permitirão retornar ao caminho planejado
originalmente. A revisão das atividades deve sempre ser feita como
uma maneira de voltar ao que havia sido previamente estabelecido
para o projeto.
24
Avaliação – acompanhamento da execução do projeto

O acompanhamento da execução do projeto é possível quando se consegue
obter informações precisas sobre seu andamento. Há um pressuposto básico
para essa avaliação: se não houve planejamento, então não há como fazer o
controle ou acompanhamento da execução.
As ações de avaliação podem ser de dois tipos: proativa ou reativa. Com o

acompanhamento proativo garante-se que as atividades planejadas ocorram tal
como foi planejado, as atividades não planejadas sejam avaliadas e introduzidas
quando necessário, e as indesejáveis não aconteçam durante a execução do
projeto. No acompanhamento reativo, variações das atividades em relação ao que
foi planejado são identificadas, analisadas e corrigidas (MENEZES, 2001).
As funções do controle (ou acompanhamento da execução) do projeto são:
• monitorar a execução: significa acompanhar fisicamente a execução passo a

passo, dia a dia;
• analisar as distorções: ação de comparar os dados obtidos sobre o que foi

realizado e o que se tinha planejado. Dessa análise, surgirão diferenças que
deverão ser corrigidas por intervenções nas atividades a serem desenvolvidas
ou por novas atividades reativas/corretivas a serem planejadas;
• apresentar alternativas de solução: implica resolver as distorções que

acontecem entre o executado e o planejado de um projeto. É importantíssimo
para o sucesso do projeto;
• revisar/replanejar o projeto: significa refletir sobre as intervenções no projeto

para estabelecer um conjunto de ações integradas que restaurem a execução
ao estado planejado originalmente.
Na verdade, o acompanhamento do desempenho deve andar junto com a

execução. A todo instante, você deve monitorar as atividades, e quando
notar algum desvio, propor uma notificação – formal ou não – ao gestor do
projeto, visando a uma análise e a uma alternativa de solução. Esses desvios
ou anomalias devem ser monitorados e avaliados com base nos indicadores
de desempenho, pré-definidos no planejamento do projeto. Por meio de uma
reunião de avaliação e consenso, a equipe pode avaliar que decisão tomar,
inclusive replanejar o projeto. Nesse caso, você deve reportar-se ao formulário de
modificação de projeto quando necessário.
25
Capítulo 2
É importante relembrar que a comunicação entre a equipe deve ser feita com
periodicidade para permitir a correção de eventuais desvios, antes que eles
transformem-se em desvios acentuados no projeto. Dependendo do porte e da
fase do projeto, as reuniões podem ser semanais (ou até mesmo diárias), para
manter a equipe interada das informações sobre ele.
Agora vamos tratar de duas etapas importantes do desenvolvimento de

seu projeto:
•• o protótipo;
•• o projeto piloto.
Você sabe o quê caracteriza cada um?
a. Protótipo do projeto – modelo de execução

Durante a execução, precisamos detalhar o projeto, e um elemento fundamental
dessa etapa é a modelagem. Você aprendeu em Gestão de Projetos e de Equipes
(FACCIONI, 2006) que:
O modelo de um objeto é uma representação, é uma simplificação desse

objeto, de forma que possamos entendê-lo de maneira abrangente.
Um modelo é uma representação em pequena escala de algo grande. Modelos

são usados para facilitar a visão do futuro, ou seja, o modelo pode ajudar
a realizar o projeto e chegar ao resultado final esperado. Você estudou os
diferentes tipos de modelos existentes. O fluxograma de atividades não deixa
de ser uma forma de modelar o sistema, o chamado modelo diagramático.
Agora você precisa construir um modelo que represente com alto grau de
semelhança o seu projeto, do ponto de vista físico. Esse modelo é normalmente
denominado protótipo.
O protótipo pode ser entendido como uma versão funcional do seu

projeto, representativa do todo, ou de parte dele, com a finalidade de
analisar, predizer ou descrever seu comportamento.
Assim, esse modelo de representação é uma idealização do sistema físico e nos

auxilia na análise e na solução dos problemas, pois permite visualizar e pensar
sobre detalhes do sistema que não estavam claros antes de sua construção.
Outra característica do protótipo é que ele é um modelo interativo, podendo ser

revisto e melhorado durante os ensaios de simulação, com base nos requisitos
26
de cliente e no escopo do projeto. Uma vez construído um protótipo do projeto,

pode-se realizar sobre ele as primeiras simulações, reduzindo o tempo na
análise e corrigindo distorções de comportamento que possam aparecer.
Por meio de simulações, várias medidas podem ser obtidas para auxiliar na
configuração do protótipo e no entendimento do próprio sistema. Isso é possível
porque os indicadores de desempenho podem ser medidos pelo protótipo e,
posteriormente, associados e reavaliados no projeto real.
Assim, para desenvolver seu projeto, você precisará, antes de tudo, criar um
modelo ou protótipo desse projeto.
Na etapa da execução devem ocorrer as primeiras implementações do projeto,

por exemplo, a escrita das primeiras versões de um software, a criação do
protótipo, os testes iniciais, as simulações etc. Esse processo exige revisões
dinâmicas do processo de execução, até se atingir um padrão de qualidade
compatível com os requisitos do cliente e com o escopo do projeto.
Os projetos podem ter resultados melhores se forem testados em etapas, com

o objetivo de se obter resultados parciais. Qualquer problema que você detecta
nessas etapas deve ser resolvido imediatamente. Não existe razão para aguardar
até o final do projeto. Nesse sentido, é importante que cada atividade do projeto
tenha sua implementação, análise e simulação, buscando conseguir um resultado
palpável ao final da etapa, dentro dos indicadores de desempenho estipulados.
Em projetos de software, existe ainda a possibilidade de dividir o sistema em

módulos, de tal forma que, cada um tenha características específicas, definidas
inicialmente e que, atingi-las significa o objetivo a ser alcançado no final da
etapa. Quanto maior a divisão de etapas, ou seja, de objetivos intermediários,
mais fácil será para você detectar possíveis problemas e corrigi-los a tempo
(FACCIONI, 2006).
Veja o que diz este artigo disponível na Wikipedia, a enciclopédia livre, sobre o
uso de protótipo em software:
Prototipagem de software
Origem: Wikipédia, a enciclopédia livre.
Prototipagem
As técnicas e ferramentas de software existem para identificar requisitos ambíguos
e em falta. Esses problemas são fatores importantíssimos no desenvolvimento de
qualquer sistema de software. Contudo, estas questões tornam-se ainda mais
27
Capítulo 2
complicadas com a emergente troca de requisitos de software ao longo do seu

desenvolvimento. Projetos de larga escala estão em grande expansão nos dias de
hoje, e qualquer alteração no percurso da criação de um sistema pode acarretar
sérios problemas, que levam a um aumento significativo dos custos. [11]
A prototipagem está ganhando uma aceitação crescente nas comunidades de

Engenharia de Software, sendo encarada cada vez mais como um modelo credível
de criação de sistemas. [7] A prototipagem de sistemas de software pretende ser
usada, principalmente, para animar e demonstrar os requisitos de um sistema.
Pretende-se, assim, ajudar os clientes e os responsáveis pelo desenvolvimento
do projeto a testar e a melhorar o sistema, antes mesmo de ser finalizado. Na
engenharia de requisitos, a prototipagem é empregada para gerar protótipos de
interfaces com o utilizador, em conjunto com cenários [2], facilitar a compreensão,
por parte dos interessados, do sistema de software a ser desenvolvido, no
levantamento e validação de requisitos [5], reduzir a ambiguidade, inconsistência e
falta de compreensão quando da recolha de requisitos [3, 4] e ainda modificar, de
forma organizada, especificações e implementações já realizadas [6].
Experiências realizadas ao longo dos tempos e da nova era tecnológica mostram

que a prototipagem de sistemas de software reduz até 40% o tamanho de um
sistema e o esforço dos respectivos programadores. [1] A prototipagem vem sendo
usada com um sucesso, permitindo que desde muito cedo se ganhe uma melhor
percepção dos requisitos do sistema e também simplificando o seu desenho.
Um protótipo pode ser considerado uma implementação concreta, embora parcial,

de um programa. Os protótipos podem ser criados para explorar múltiplas questões
durante o desenvolvimento do software.
Por exemplo, um protótipo de uma interface com o utilizador tem como principal
funcionalidade conseguir captar as necessidades efetivas e concretas do
utilizador. [8]
Um protótipo requer a participação de cerca de 30% da equipe de desenvolvimento

de uma aplicação de software. Assim, solicita-se que criem uma ou duas versões
focando vários aspectos do sistema. A ideia não é que se produza código efetivo,
ou seja, que se comece a desenvolver já módulos do programa, visto que um
protótipo pode ser usado para uma continuação do progresso do sistema ou ser
completamente descartado. Apenas quando algumas especificações resultantes
de experiências realizadas com o protótipo forem examinadas se deve dar início ao
desenvolvimento formal do processo. “A prototype produces “running” software and
the production development produces “working” software.” [1]
Há diversas opções para fazer protótipos de sistemas de software. As técnicas

variam consoante aos custos e ao esforço investido para a realização do protótipo e
também pela fidelidade e generalidade dos resultados. Abaixo estão as técnicas de
prototipagem mais usuais para a prática da engenharia de usabilidade:
28
• Storyboard
• Protótipo em papel
• Feiticeiro de Oz
• Máquina de Cenários
• Prototipagem rápida
• Prototipagem evolutiva
• Storyboarding: essa técnica utiliza a especificação por meio de

imagens, para descrever certas situações. Fortemente ligado à
técnica de cenários, o storyboarding pode atuar de forma conjunta
com esses. Entretanto, pela sua forma de descrição, os cenários são
mais adequados à análise de tarefas, enquanto o storyboarding se
encaixa melhor na validação do formato visual desses cenários e na
elaboração de protótipos não operacionais.
• Protótipo em papel: é certamente o método mais simples a utilizar;

apenas com o material existente num escritório é possível fazer um
esboço de uma aplicação, isto é, com papel (ou “post-it”), lápis
e caneta pode-se criar caixas de diálogo, menus, mensagens de
erro… Assim que parte do sistema esteja esquematizado, pede-se
aos potenciais utilizadores que testem o protótipo, interagindo com
a interface em papel. Além disso, caso algo não esteja correto e se
queira mudar, é extremamente fácil de se (re)fazer.
• Feiticeiro de Oz: Uma pessoa (wizard) simula as respostas do

sistema de acordo com as entradas do utilizador, pela seguinte
ordem: – Interpreta os inputs de um utilizador segundo um algoritmo –
Controla computador para simular o output desejado – Usa a interface
real ou um “mock-up” A técnica do Feiticeiro de Oz ou “Wizard of
Oz” é utilizado para simular a adição de funcionalidades complexas e
também para testar ideias futuristas. Máquina de cenários: o protótipo
traduz-se, apenas, por alguns ecrãs 1 que sustentam uma quantidade
considerável de informação sobre “se” e “como” é que o desenho
do sistema vai de encontro com os objetivos e as expectativas do
utilizador; a “máquina de cenários” inclui ainda alguma programação
em lógica a qual permite que os utilizadores possam “navegar” por de
uma sequência pré-definida de cenários.
1 O Ecrã ou Écran é a superfície sobre a qual se projeta uma imagem ou parte de um aparelho
que exibe informações visuais resultantes do processamento ou recepção de sinal ou dados.
29
Capítulo 2
• Prototipagem Rápida: é usada para reduzir os riscos dos requisitos;

o protótipo é desenvolvido a partir de uma especificação inicial, é
entregue/dado a conhecer aos clientes finais e aos responsáveis pelo
projeto e depois é “deixado de lado”. Um protótipo rápido nunca deve
ser considerado como uma versão (quase) final do sistema, pois a
prototipagem rápida é pouco estruturada e difícil de se manter do
início ao final do projeto.
• Prototipagem Evolutiva: o principal ponto aqui é adquirir

funcionalidade para demonstrar uma parte do sistema ao utilizador
final, de modo a que algum feedback seja conseguido do lado
do cliente. [11] À medida que o sistema vai sendo desenvolvido,
diversas funcionalidades são adicionadas ao protótipo e traduzidas
numa eficiente implementação. No final, o sistema estará pronto
no seu todo.
Perigos da prototipagem…
A técnica de prototipagem na identificação de requisitos pode nem sempre ser

benéfica. Algumas empresas e/ou organizações podem encarar os protótipos
como sendo “inimigos” seus. A adaptação ao protótipo, a eficiência de utilização, a
aplicabilidade e o comportamento dos potenciais utilizadores e também dos clientes
que “compram” um sistema de software pode ter um impacto negativo.
Se a maquete do sistema for construída sem cuidado especial, pode ser que essa
resolva, teoricamente, o problema errado, ou seja, aparentemente o protótipo
pode parecer muito bom e estar muito bem feito, mas não vai ao encontro das
necessidades básicas dos potenciais utilizadores.
Para além disso, o fato de um protótipo dar a conhecer apenas algumas “peças do
puzzle”, pode levar a menosprezar partes fundamentais do sistema, tornando-se
incompleto. Saltar passos fundamentais no desenho de um software pode conduzir
à “primeira solução” (mais fácil e simples), em vez de nos levar à “melhor solução”.
A prototipagem tem ainda outro problema que deve ser levado em conta: se for
demasiado perfeito e permitir que o utilizador navegue pelo sistema já com um
grau de profundidade elevado, pode levar o cliente a pensar que o projeto já
está praticamente pronto, desvalorizando, assim, a quantidade de trabalho ainda
por realizar.
Concluindo, o processo de prototipagem pode ser muito eficaz, mas também ter
custos de produção elevados e ocupar uma quantidade de tempo exagerada.
Todos estes pontos devem ser bem medidos, tanto pelos engenheiros de software,
que estão à frente de qualquer projeto, quanto também pela parte dos clientes.
30
Conclusão: Há muito tempo já se escreve sobre as melhores práticas para o

desenvolvimento de aplicações de software, mas existe “a melhor maneira”.
Há diversas formas de encarar a realidade tecnológica, e a criação de novos
sistemas de software não é exceção. Tanto a prototipagem como os requisitos são
necessários. O uso do método de “tentativa-erro” no processo de análise e síntese
na Engenharia de Software é cada vez mais frequente. “Bottom-up” é síntese.
“Top-down” é análise. “Bottom-up” é prototipagem. “Top-down” é desenvolvimento
de requisitos. A prototipagem facilita a comunicação entre o cliente e o responsável
pelo desenho da aplicação. A escrita formal dos requisitos do sistema de software
é necessária para estabelecer uma definição clara do projeto, permitindo controlar
as alterações que vão sendo efetuadas ao longo de todo o processo e facilitando a
comunicação entre o cliente e o gestor do projeto. [1]
Referências
[1] Larry Bernstein, Importance of Software Prototyping http://www.dacs.dtic.mil/

awareness/newsletters/technews2-1/prototyping.html, acesso em: 29 dez, 2005.
10h11
[2] M. Elkoutbi, I. Khriss & R.K. Keller. Generating User Interface Prototypes from
Scenarios, IEEE Int’l. Symp. On Requirements Eng., 1999.
[3] R.D. Acosta, C.L. Burns, W.E. Rzepka & J.L. Sidoran. A Case Study of Applying
Rapid Prototyping Techniques in the Requirements Engineering Environment. Fisrt
IEEE Int’l Conf. on Requirements Engineering, 1994.
[4] B. Ramesh & Luqi. Process Knowledge Based Rapid Prototyping for
Requirements Engineering, 1993.
[5] A. Sutcliff e, A Technique Combination Approach to Requirements
Engineering, 1997.
[6] M.B. Ozcan & J.I.A. Siddiqi. Validating and Evolving Software Requirements in a
Systematic Framework, 1994.
[7] C. Ryan, A. Annie, D. Aldo, W. Laurie. Evolving Beyond Requirements Creep: A
Risk-Based Evolutionary Prototyping Model
[8] M. Rosson, J. Carroll. Usability Engineering: Scenario-Based Development of
Human Computer Interaction, Morgan Kaufmann Publishers, 2002.
[9] Gerald Kotonya and Ian Sommerville, John Wiley & Sons, Requirements
Engineering Processes and Techniques , 1998.
[10] Dean Leffi ngwell, Don Widrig. Managing Software Requirements: a Use Case
approach. 2nd Edition. Addison-Wesley, 2003.
[11] Joseph Urban. Software Prototyping and Requirements Engineering, 1992
http://www.dacs.dtic.mil/techs/prototype/DACS-Prototype.pdf
[12] Scalon, T. Paper prototypes: still our favourite http://www.uie.com/articles/
paper_prototyping, 28-12-2005, 15h53.
FONTE: WIKIPÉDIA, A ENCICLOPÉDIA LIVRE. Prototipagem de software. Disponível em: <http://

pt.wikipedia.org/wiki/Prototipagem_de_software>. Acesso em: 14 jun. 2006.
31
Capítulo 2
Em projetos mais complexos, o uso de simuladores computacionais pode facilitar

as revisões e as análises, assim como o do protótipo.
As ferramentas devem ser utilizadas como solução para busca de melhorias

e para conquistas parciais, permitindo uma visão global, por meio de testes
variados, a fim de atingir as metas do projeto. As dificuldades relacionadas ao uso
de simuladores estão na própria escolha do aplicativo e nas limitações que um
pacote genérico apresenta, uma vez que ele não foi desenvolvido apenas para o
seu projeto. No entanto, o uso de simuladores pode auxiliar no desenvolvimento
do projeto, pois reduz o trabalho da equipe, uma vez que esSes softwares são
pré-testados e apresentam garantias de usabilidade que o protótipo não tem.
Quando a equipe constrói seu protótipo, uma das vantagens que se destaca
é a de desenvolver algumas funcionalidades que auxiliem no refinamento do
projeto. Pode-se programar funções embutidas no protótipo que permitam, após
cada simulação, gerar dados, por meio de gráficos, planilhas e/ou tabelas, e
comparar resultados anteriormente obtidos com os atuais. Além disso, pequenos
diagnósticos locais podem ser automaticamente gerados e apresentados, junto
com os resultados dos ensaios de simulação, para auxiliar a tomada de decisões.
Feito os ensaios de simulação e as devidas análises com o protótipo, é hora de

colocar o projeto à prova.
b. Projeto-Piloto (versão Beta)

Finalizados os ensaios de simulação, passamos a implantação do projeto, com
a criação de um piloto. No Projeto Integrador, esse piloto nada mais é que uma
versão Beta do projeto final, que deverá ser entregue previamente para que o
professor realize uma análise do funcionamento e possa auxiliar na otimização
das funcionalidades e na finalização do projeto propriamente dito. O projeto-
piloto torna possível fazer um diagnóstico e ver os resultados das etapas em
funcionamento. Dessa forma, são criados métodos de procedimentos para a
validação dos resultados esperados com o produto do projeto final.
Versão Beta O projeto-piloto visa a testar a eficácia das etapas, consolidando

é como ficou os resultados prévios e buscando garantir o sucesso do projeto.
popularmente
conhecida a
Após o processo ter sido implementado no projeto-piloto,
versão de um precisamos avaliar o esforço despendido, ou seja, validar os
projeto que resultados atingidos em comparação ao escopo proposto para o
precede sua
projeto. Os objetivos foram atingidos? Esta é a principal pergunta
versão final, ou
seja, que ainda a se fazer aqui.
está inacabada
e/ou em fase Segundo Faccioni (2006), a validação do projeto deve ser feita
de validação. por etapas e por simulações, sendo que no final de cada etapa
32
e mesmo durante cada uma delas, um processo de revisão contínua é a melhor

solução de qualidade de continuidade de um projeto de sucesso. Existem vários
tipos de revisões a serem feitas no decorrer do projeto, visando a testes contínuos
e validação a cada etapa. Especificamente, sobre os projetos, as revisões e os
testes são os seguintes:
•• revisão do escopo do projeto, que analisa constantemente

se o projeto está adequado às intenções e necessidades dos
usuários/clientes;
•• revisão de análise, que verifica se os problemas anunciados
no escopo estão sendo cuidados;
•• revisão do projeto, que verifica se o projeto preenche as
especificações, os padrões de qualidade e se tem condições
de ser implementado;
•• revisão da programação e do sistema, que verifica se os
resultados dos testes do protótipo estão adequados;
•• revisão da aceitação, que verifica se após os testes do
protótipo já é possível colocar o resultado do projeto
em produção;
•• revisão de produção, que verifica se o sistema de produção
está adequado e se há oportunidades de melhoria
no produto;
•• revisão dos aspectos técnicos do projeto;
•• revisão dos aspectos comerciais;
•• revisão pós-projeto, que busca aprender com os resultados
finais do projeto.
Observamos que essas revisões se aproximam muito das ações de execução

direta, citadas anteriormente. Essa comparação reflete a realidade: simulações,
testes e revisões são atividades do dia a dia do projeto, interferindo, inclusive,
no seu final. Ao encerrarmos estas atividades, teremos o final do projeto, que é,
justamente, o nosso próximo assunto.
33
Capítulo 2
O que entregar ao final desta primeira etapa de PIWEB II?

Na fase de execução e avaliação de projeto, você precisará preencher o
formulário de execução e acompanhamento de projeto, disponível no EVA.
Os Quadros 1 e 2, apresentados nas páginas seguintes, exemplificam o
formulário específico preenchido para o projeto “Sistema Hydros”, nosso
exemplo de estudo.
Observe que este formulário específico é a base de envio de duas atividades a

distância, a AD1 e a AD2, da Unidade de Aprendizagem Prática em Programação
para Web.
Esse formulário agregará valor, à medida que se desenvolver o cronograma do

projeto. Deverão ser incorporados a ele:
•• Entrega Conjunta, contendo arquivos com elementos de referência

sobre o protótipo (e posteriormente sobre o piloto);
•• Documentos Associados, onde deve ser inserido o cronograma
atualizado, bem como podem ser entregues outras planilhas que
julgar importantes para o projeto. O professor emitirá seu parecer no
próprio formulário, em espaço reservado aos seus comentários.
34
Quadro 1 – Modelo de Formulário de Execução e Avaliação de Projetos, folha 01/02
FORMULÁRIO DE IDENTIFICAÇÃO DO PROJETO [FOLHA 01/02]
FORMULÁRIO DE EXECUÇÃO E ACOMPANHAMENTO DE PROJETO

Nome da equipe: P & D
Título: Sistema Hydros
RELATÓRIO DE ACOMPANHAMENTO
Última data de verificação do projeto: 15 Julho 2014
Avaliação do acompanhamento dos trabalhos em 15 de Julho de 2014.
Verificou-se um pequeno atraso na definição da forma de acesso, levando a um

atraso no início da etapa 4. Entretanto, a primeira parte dos trabalhos realizados na
etapa 4 foi finalizada antes do prazo estipulado, e a segunda parte está bastante
adiantada.
Por conta do atraso na chegada da plataforma de controle referente à etapa 2, foi

determinado um adiantamento no início da atividade de “leitura das entradas”
executadas junto com a atividade de “acionamento dos motores”. Dessa maneira,
não houve comprometimento do cronograma dos trabalhos seguintes, tanto que a
“a abertura e fechamento das válvulas” está dentro do prazo planejado.
Devido ao atraso na entrega da plataforma de desenvolvimento da interface web, o

início da parte “criação de telas” começou mais tarde, o que levou a um atraso nos
trabalhos seguintes. Apesar do atraso no início dos trabalhos e a morosidade na
execução, o projeto como um todo não está comprometido, pois o resultado dos
trabalhos desta fase é integrado ao sistema somente na etapa final do projeto.
VERIFICAÇÃO DE INDICADORES DE DESEMPENHO
Avaliando os indicadores para o 1º bimestre, temos:
Cronograma: atraso na execução

Houve atraso, mas conseguiu-se compensar o desvio adiantando outras etapas e
contornando o problema original.
Orçamento: não houve violação dos valores orçados.

O orçamento permanece controlado dentro dos valores esperados.
Tecnologia/Operacionais:
Esses indicadores não podem ser avaliados, pois são variantes que ainda não
entraram na execução do projeto.
Fonte: Elaborado pela autora, 2015.
35
Capítulo 2
Quadro 2 – Modelo de Formulário de Execução e Avaliação de Projetos, folha 02/02
FORMULÁRIO DE IDENTIFICAÇÃO DO PROJETO [FOLHA 02/02]
FORMULÁRIO DE EXECUÇÃO E ACOMPANHAMENTO DE PROJETO

Nome da equipe: P & B
Título: Sistema Hydros
DOCUMENTOS ASSOCIADOS
( X ) Gantt atualizado
( ) Lista de atividades
( ) Fluxograma
( ) Planilha de custos
( ) Outros:..................................................................
ENTREGA CONJUNTA
( X ) Protótipo
( ) Piloto
( ) Projeto Final
( ) Obs.:
ESPAÇO RESERVADO PARA AS CONSIDERAÇÕES FINAIS
VERIFICAÇÃO DO PROFESSOR
Relatório
Indicadores
Documentos Associados
Entrega Conjunta
36
Seção 2
Etapa 6: encerramento do projeto
Uma das causas possíveis de encerramento do projeto é a própria data-limite, ou
prazo final (como no nosso caso). Não temos como discutir a data previamente
estipulada, pois não haverá prorrogações, uma vez que o encerramento do
semestre letivo coincide com o prazo máximo de envio do projeto. Então, temos
que trabalhar sabendo que essa data é definitiva. Nesse caso, o controle mais
rigoroso do tempo deve ser feito no Gantt, preenchendo as atividades realizadas
e comparando com o previsto, conforme já citado anteriormente. Segundo
(FACCIONI, 2006), a finalização do projeto pode acontecer por dois motivos:
•• As coisas deram certo e o resultado esperado foi alcançado;

•• As coisas deram errado e é melhor finalizar antes que piore.
A avaliação de que o resultado está sendo atingido é feita por medições

dos indicadores de desempenho, a cada etapa do trabalho. Atingir um grau
satisfatório em cada uma das medições faz o projeto caminhar rumo ao objetivo
final. Quando avaliamos um projeto, geralmente o fazemos sob quatro aspectos:
prazos, custos, recursos e benefícios. Se algum deles não foi contemplado, temos
indícios de fracasso.
Por isso, encerrado o projeto, é o momento de discutir e analisar possíveis falhas,

para que não ocorram em projetos futuros, concluindo, então, o aprendizado.
Percebemos que as lições tiradas de experiências ruins também auxiliam,

em geral, o desenvolvimento de técnicas de gestão e controle, podendo ser
incorporadas pouco a pouco.
A melhoria contínua do processo depende do aprendizado a partir de sucessos

e fracassos e da subsequente aplicação das experiências anteriores em novos
projetos. Além disso, discorrer sobre aprendizagem e sobre o projeto em si, seja
de sucesso ou fracasso, serve de pretexto para dar origem a novas ideias e,
quem sabe, um novo projeto.
Pode-se fazer um checklist de encerramento, avaliando a satisfação do cliente,

fazendo uma análise crítica do projeto, documentando a memória dele e as
dificuldades encontradas no decorrer do projeto, entre outros.
Uma forma de realização dessa análise, da finalização do projeto, consiste em

fazer uso de um formulário em que cada um dos membros da equipe coleta
informações e opiniões pessoais sobre o projeto.
37
Capítulo 2
Esse formulário, chamado comumente de “Lições Aprendidas”, deverá ser

preenchido por cada um, separadamente (e sem a intervenção dos demais
membros de sua equipe), para que se obtenha o máximo de confiabilidade.
Em “Lições Aprendidas” você deve registrar as causas das variações, razões sob
os planos de ação para eliminação de situações insatisfatórias, análise de erros
cometidos no gerenciamento de prazo, custo, qualidade, escopo e risco, análise
de acertos realizados durante o projeto.
O objetivo deste formulário é avaliar o aprendizado, considerando a autoavaliação

de cada aluno sobre sua atuação e de sua equipe em seu projeto. Essas
informações devem ser poucas e sucintas para que o mais importante venha à
tona (MENEZES, 2001). Preencha tal formulário, tal como o do modelo do Quadro
3, a seguir, e o envie a seu professor com a documentação do projeto.
38
Quadro 3 – Modelo de formulário de Lições Aprendidas
[FOLHA 01/01]
FORMULÁRIO PARA DOCUMENTAÇÃO

Nome do aluno:
Papel desenvolvido no projeto:
Título:
LIÇÕES APRENDIDAS
Data de início do projeto:
Data de entrega do projeto:
Em sua opinião, cite três itens que

mais contribuíram para que o sucesso
no projeto pudesse ser obtido.
Em sua opinião, quais os três itens
que contribuíram para que o projeto
falhasse e o que pode ser feito para
evitar/prevenir isso em projetos
futuros?
Identifique os obstáculos críticos ou
ponto chave que impediram o
desenvolvimento e o progresso do
projeto.
Identifique os fatores críticos que
geraram um desvio significativo na
equipe..
Baseado em sua experiência neste
projeto, quais seriam as três
recomendações que você faria para
uma próxima equipe de projeto?
Identifique pontos positivos no
processo de desenvolvimento do seu
projeto.
Identifique oportunidades de melhoria
no processo de desenvolvimento do
seu projeto.
NOVAS IDEIAS E OPORTUNIDADES
Perspectivas futuras:
Outras informações relevantes:
39
Capítulo 2
Seção 3
Etapa 7: documentação do Projeto Integrador Web
Fechado o projeto, é importante você avaliar as estatísticas quanto ao tempo
gasto, os recursos utilizados, os riscos previstos que aconteceram e não
aconteceram, se os custos foram suficientes e todos os demais dados que
possam compor o projeto e ajudar a entender a gestão para os próximos
projetos. Avalie se as expectativas do cliente foram atendidas. Esse é o momento
de reunir toda a documentação (obrigatoriamente) para que se preserve a história
do desenvolvimento do projeto, permitindo avançar em melhorias no futuro
(FACCIONI, 2006).
Reunir a documentação é colocar em ordem, fazer os últimos ajustes e entregar

a versão final de seu projeto, juntamente com o produto obtido (mesmo que seja
apenas um protótipo). A documentação final do projeto, normalmente chamada
memória do projeto, deve conter:
•• os formulários preenchidos sobre o escopo e planejamento;

•• os relatórios de acompanhamento de execução;
•• a quantificação sobre o cumprimento de objetivos, para o “aceite”
do projeto;
•• uma análise de custos reais do projeto, com a evolução financeira
dos gastos e das receitas;
•• uma avaliação técnica, relatando técnicas de desenvolvimento e
execução, ações que contribuíram para o projeto e dificuldades
encontradas no decorrer do projeto;
•• um informativo tecnológico, reportando aquisição de know-how,
banco de dados ou softwares para desenvolvimento do projeto;
•• entre outras informações, que você considera relevante.
Pode ser que você ainda tenha algo a descrever e a acrescentar em sua
documentação, por isso, leia algumas dicas para redigir seu projeto:
40
• adote um estilo de linguagem simples, claro e direto;
• desenvolva uma ou duas ideias em cada parágrafo, para melhorar a

compreensão do texto como um todo;
• prefira parágrafos curtos, com ideias claras;
• utilize vocabulário adequado ao tema, evitando-se modismos e gírias;
• obedeça às regras gramaticais, fatores como ortografia, concordância e

pontuação podem modificar o sentido da frase;
• dê preferência ao uso de substantivos e de verbos na voz ativa;
• evite o uso abusivo de advérbios e de adjetivos;
• utilize a terceira pessoa do singular, evitando-se expressões como eu acho...,

eu penso, na primeira pessoa do singular;
• pronomes possessivos também devem ser abolidos como meu trabalho...,

minha pesquisa..., meus estudos...;
• use tabelas, gráficos, equações, quando necessário, para facilitar a melhor

compreensão do texto;
• evite o uso de abreviaturas, pois podem gerar ambiguidade e mal-entendidos;
• não esqueça de citar os autores das ideias utilizadas para que não se
caracterize o plágio;
• siga as normas da ABNT para referenciar a bibliografia consultada;
• faça revisão periódica do que foi escrito. Uma leitura em voz alta facilita a
correção de frases sem sentido ou/e confusas.
Atenção!
Lembre-se de que a documentação do projeto deve ser atualizada SEMPRE no

decorrer do projeto! Não deixe tudo para o final!
Confira a seguir a estrutura que sua documentação final deve contemplar.
41
Capítulo 2
1 IDENTIFICAÇÃO DO ESCOPO DO PROJETO
1.1 Definição e Apresentação do Tema
1.2 Categoria do Projeto
1.3 Contexto do Projeto
1.3 Equipe do Projeto
2 DESCRIÇÃO DETALHADA DO PROJETO
2.1 Descrição
2.2 Objetivos
2.2.1 Objetivo Geral
2.2.2 Objetivos Específicos
2.3 Justificativa
2.4 Resultados Esperados
2.5 Coleta e Interpretação de Dados
3 ANÁLISE DO PROJETO
3.1 Estudo de Necessidades – Planejamento de Atividades
3.2 Estudo de Recursos Mobilizados
3.3 Estudo de Viabilidade
3.4 Estudo de Riscos
4 PLANEJAMENTO DE PROJETO
4.1 Plano de Trabalho
4.1.1 Fluxo de Atividades
4.1.2 Detalhamento das Atividades
4.1.3 Cronograma das Atividades (gráfico de Gantt)
4.2 Equipes de Trabalho
4.2.1 Divisão de Tarefas
4.2.2 Divisão de Responsabilidades
42
5 EXECUÇÃO DO PROJETO
5.1 Relatórios Parciais de Execução
5.2 Verificação de Índices de Desempenho
5.3. Ajustes/ Modificações de Projeto
5.4. Protótipo do Projeto
5.5. Projeto Piloto
6 ENCERRAMENTO DO PROJETO
6.1 Validação do Projeto
6.2 Entrega / Apresentação Final
6.3 Medição dos Resultados
7 CONSIDERAÇÕES FINAIS
7.1 Lições Aprendidas
7.2 Novas Ideias e Oportunidades
REFERÊNCIAS e APÊNDICES
ANEXOS
43
Considerações Finais
Caro aluno,
Você chegou ao fim de uma árdua caminhada. Foram dois semestres trabalhando

no Projeto Integrador Web. Na teoria, 180 horas de trabalho – na prática,
provavelmente muito mais...
Nossa expectativa é que a utilização deste livro, aliado a sua capacitação, tenha
tornado possível a construção de seu PI Web. Durante esse processo, você
deve ter encontrado muitas dificuldades e talvez tenha sentido necessidade de
melhor compreensão dos temas aqui apresentados. Com toda a certeza, não
conseguimos esgotar o assunto, pois
existem muitas linhas e estilos diferentes para a condução e a aplicação de

conceitos de gestão de projetos e de equipes.
Mas acreditamos que, com base neste livro (e nos demais referenciados), você
tenha o devido suporte para buscar conhecimentos em outros materiais e, até
mesmo, gerar conhecimento, a partir das ideias inovadoras que possam ter lhe
ocorrido durante esta importante etapa de seu curso.
Com toda certeza, a conclusão desse primeiro projeto lhe abrirá as portas para
um mundo fascinante de pesquisa e desenvolvimento, sobretudo, de uma vida
profissional plena com a habilitação de tecnólogo em Web Design e Programação.
Comemore muito, pois não é todo dia que temos o prazer de uma vitória assim!
Sucesso, hoje e sempre!
Professora Cynthia Beatriz Scheffer Dutra
45
Referências
AMBONI, Nério; AMBONI, Narcisa de Fátima. Pesquisa e avaliação: livro
didático. 3. ed. rev. e atual. Palhoça: UnisulVirtual, 2005. 122 p.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6023: referências:

elaboração. Rio de Janeiro, 2002.
BOUTINET, Jean-Pierre. Antropologia do projeto. Lisboa: Instituto Piaget, 1990.
FAGUNDES, Léa da Cruz; SATO, Luciane Sayuri; MAÇADA, Débora Laurino.

Aprendizes do futuro: as inovações começaram! Coleção Informática para a
Mudança
da Educação. Secretaria de Educação a Distância. Ministério da Educação.

Governo Federal. Disponível em <http://www.inf.ufsc.br/~edla/mec/livro03.pdf>.
Acesso em: 05 jun. 2006.
FACCIONI FILHO, Mauro. Gestão de projetos e equipes. 2. ed. rev. 296 p.

Palhoça: UnisulVirtual, 2006.
MENEZES, Luis César de Moura. Gestão de projetos. São Paulo: Atlas, 2001.
UNIVERSIDADE DO SUL DE SANTA CATARINA. UnisulVirtual. Curso superior

de tecnologia em web design e programação: modalidade a distância:
manual do curso. 2. ed. rev. e atual. Palhoça: UnisulVirtual, 2006. 26 p.
UNIVERSIDADE DO SUL DE SANTA CATARINA. UnisulVirtual. Guia para

desenvolvimento do projeto integrador em gestão da tecnologia da
informação (PIGTI). Palhoça: UnisulVirtual, 2006. 48 p.
47
Sobre o Professor Conteudista
Cynthia Beatriz Scheffer Dutra é doutora em Automação e Sistemas pela UFSC,

com doutorado “sanduíche” pela Universidade de Sevilha/Espanha. Enfoque
de pesquisa em aplicação prática de otimização e supervisão de controle de
processos. Graduada em Engenharia de Controle e Automação Industrial,
também pela UFSC, obteve mérito estudantil com índice de aproveitamento
9,26. Com a formação multidisciplinar nas áreas Elétrica, Mecânica e Informática,
trabalhou em projetos de pesquisa financiados pelo CNPq e CAPES, em
diferentes modalidades, desde a graduação. Na UNISUL, atua como professora
do ensino presencial nos cursos de Engenharia, Computação, Sistemas de
Informação e no ensino virtual nos cursos de Web Design e Programação e de
Gestão da Tecnologia da Informação.
Para informações mais detalhadas, acesse seu currículo completo, disponível

para consulta on-line no banco de dados do CNPq, no endereço http://lattes.
cnpq.br.
49
Desenvolver um projeto web é um desafio
necessário para a formação acadêmica na área
tecnológica. A partir da estrutura conceitual do
projeto – devidamente elaborada em Prática em
Gestão de Projetos – agora é o momento para
Prática em
executar o que foi previamente planejado.
Prática em Programação para Web trará

orientações sobre a etapa de execução e
documentação do projeto.
Programação
para Web
w w w. u n i s u l . b r

(8081 - 25516) Pratica - Programacao - Web

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

(8081 - 25516) Pratica - Programacao - Web

Enviado por

Direitos autorais:

Formatos disponíveis

Prática em Programação para Web

Universidade do Sul de Santa Catarina

Prática em Programação para Web

Universidade do Sul de Santa Catarina – Unisul

Pró-Reitor de Ensino, de Pesquisa e de Extensão

Diretor do Campus Universitário de Tubarão

Campus Universitário UnisulVirtual

Unidade de Articulação Acadêmica (UnA) - Educação, Humanidades e Artes

Gerente de Operações e Serviços Acadêmicos

Professoras conteudistas Projeto gráfico e capa

1. Logística empresarial. I. Oliveira, Cristina Klipp de. II. Titulo.

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

Sobre o Professor Conteudista | 49

Situações novas sempre trazem momentos de dúvidas, algumas inseguranças,

Esse desafio acontecerá na forma da elaboração de um projeto prático. Esse

Cabe a esta Unidade de Aprendizagem, Prática em Programação para Web,

Projeto Integrador Web e a

Seções de estudo Seção 1: Uma visão geral dos elementos do

Seção 2: O processo de avaliação do PIWEB II

Seção 3: A estrutura e o ponto de partida para

O conceito de projeto integrador é crucial para o entendimento das habilidades

Para cumprirmos esse desafio, o projeto integrador assume duas etapas

Tabela 1 – Visão geral da abrangência do Projeto Integrador Web

Unidade de Aprendizagem Desenvolvimento das Partes do Projeto

Prática em Gestão de Projetos Projeto Integrador Web I (PIWEB I)

Prática em Programação para Web Projeto Integrador Web II (PIWEB II)

Fonte: Elaboração da autora (2015).

Em Prática em Gestão de Projetos você desenvolveu a primeira parte do projeto,

Agora, em Prática em Programação para Web, começamos uma fase de

Atenção: neste momento, aproveite para reunir os formulários de PIWEB I,

Lembre-se que o PIWEB possui uma concepção semelhante a de um projeto de

Ao final de todo o desenvolvimento do projeto, além do projeto executável, você

Esse desenvolvimento será acompanhado pelo professor por meio do Espaço

As atividades a distância a serem avaliadas estão organizadas em formulários.

Nos formulários ﬁcarão registradas todas as etapas do trabalho, bem

Os seguintes critérios serão observados para avaliação do PIWEB:

•• consonância do projeto concluído com o que foi proposto;

Algumas observações importantes:

•• a sua avaliação nessas duas unidades de aprendizagem - Práticas

Em PIWEB I você realizou a etapa de planejamento de atividades, análise e

•• Etapa 1 – identiﬁcação do escopo do projeto;

Agora, em PIWEB II, você inicia a etapa de acompanhamento da execução,

•• Etapa 5 – execução e avaliação do projeto;

1 Relatórios de • Cronograma atualizado. AD1

2 Revisão do Projeto • Modificações

5 Projeto Final • Entrega/apresentação final AD2

• Medição dos resultados

6 Considerações finais • Lições aprendidas

• Novas ideias e oportunidades

7 Referências • Reunir todas as referências

8 Anexos e apêndices • Reunir dados, cálculos,

• Material de apoio para a

9 Documentação • Reunir todas as partes do

Fonte: Dutra (2007, p. 32).

Etapas práticas do Projeto

Seções de estudo Seção 1: Etapa 5: execução e avaliação do projeto

Seção 2: Etapa 6: encerramento de projeto

Seção 3: Etapa 7: documentação do Projeto

Durante a execução, em muitos momentos, a equipe precisará se reunir e tomar

1. identificar possíveis modos de ação e chegar a um entendimento

Observe que há a necessidade da constante avaliação das opções possíveis e

Durante as reuniões do projeto deve ser designado um membro da equipe para

Veja um exemplo de relatório de acompanhamento para o “Sistema Hydros”,