Unid 2 PDF

MODELAGEM DE SISTEMAS DE INFORMAÇÃO
Unidade II
3 METODOLOGIA E DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÃO
3.1 Ciclo de vida
Os sistemas de informação são desenvolvidos visando atender às necessidades de uma organização

e com base nos requisitos fornecidos pelo cliente.
Quando de seu desenvolvimento, acredita-se que todo sistema de informação será para sempre.
Entretanto, todo e qualquer sistema pode sofrer intervenções do mercado, mudanças de legislação,
alterações estruturais da organização, impactos etc. Se o sistema não passar por avaliações e por uma
melhoria contínua, ele terá seu fim decretado rapidamente.
Um sistema de informação tem seu fim anunciado quando entra em desuso, desatualização ou
quando uma nova tecnologia é adquirida pela organização.
Quando mal estruturados ou mal desenvolvidos, os sistemas de gestão empresarial tentem a ter uma
vida curta e um fim natural por descrédito. Durante seu período ativo, todo sistema deve passar por:
• manutenção;
• melhorias;
• implementações;
• manutenção para atender à legislação;
• correção de eventuais erros.
Comparado ao ser humano, um sistema de informação tem um ciclo de vida com início, meio e fim,
como podemos observar na figura a seguir:
Maturidade
Implantação
Implantação Manutenção
Construção
Declínio
Concepção
Declínio
Morte
Figura 22 – Ciclo de vida de um sistema de informação
43
Unidade II
Cada uma das fases de existência de um sistema de informações abrange:
• concepção ou nascimento: é o momento de estudo preliminar sobre os requisitos levantados. É

importante levar em consideração uma análise do sistema atual ou anterior. Essa fase é importante,
pois deve ser definida e desenhada de forma a contemplar a necessidade real da solicitação do
cliente/organização;
• construção: nesse momento, contemplam-se a análise de sistemas e o desenvolvimento ou

construção da programação de códigos de sistemas de informação;
• implantação: ocorre após a realização de todos os testes de sistemas e a construção da

documentação do sistema de informação. É o momento de disponibilizar ao cliente o sistema que
foi desenvolvido;
Observação
A documentação é de extrema importância para o sistema de informação,

pois todo o sistema de informação bem documentado garante sua consulta
e seu conhecimento completo para possíveis alterações e atualizações.
• implementação: essa fase tem o sentido de otimizar processos, agregar valor, adaptar funções
ou realizar melhorias no sistema. Mesmo sendo uma fase executada com grande proximidade em
relação à primeira entrega, ela é uma etapa importante, pois garante que a real necessidade do
cliente e a transparência das informações sejam mantidas;
• maturidade: essa é a etapa de utilização total do sistema, ou seja, do atendimento completo dos
requisitos funcionais e da sedimentação do sistema. Esse é o momento de medir a satisfação do
cliente;
• declínio: ocorre quando o sistema de informação não atende mais o que se espera dele, o que
gera a impossibilidade de agregações e a insatisfação do cliente;
• manutenção: ocorre em decorrência de uma exigência legal, correção de erros ou atualizações,

tendo como principal foco a sobrevivência do sistema;
• morte: é quando ocorre a descontinuidade de um sistema de informação.
Observação
Quando as primeiras fases do ciclo de vida de um sistema de informação

são realizadas de forma incorreta e desatenta, a possibilidade do fim desse
sistema é intensificada.
44
Já para sistemas de informações gerenciais, a falta de atenção no que

diz respeito a atualizações e manutenções também antecipam o seu fim.
3.2 A metodologia
Há diversas formas de se denominar uma metodologia. Podemos chamá-la de método, forma de

trabalho, técnica ou de forma organizada de se atingir um objetivo mediante passos preestabelecidos.
Podemos dizer que essa forma organizada permite o uso de uma ou de diversas técnicas para o
desenvolvimento do sistema de informação, permitindo, assim, a utilização da técnica que melhor
atende à necessidade de desenvolvimento.
Essa metodologia é utilizada como auxílio no desenvolvimento de sistemas de informação, de

softwares e de projetos, de modo que as necessidades do cliente/organização sejam atendidas com
recursos disponíveis e dentro do prazo definido.
Além disso, ela deve ser utilizada por toda a organização e não só para a área de desenvolvimento
de sistemas, pois, assim, toda a organização obterá ganhos e retorno em suas metas estimadas. A
metodologia deve ser discutida, detalhada e sempre revisitada, revisada, atualizada e complementada
na medida do desenvolvimento solicitado.
Como premissa de metodologia, temos a modularidade, que se divide num sistema complexo de
módulos menores gerenciáveis individualmente, já que, dessa forma, o sistema tem o poder de ser
decomposto em um conjunto de módulos coesos e fortemente ligados, o que facilita sua compreensão.
É importante saber que não se desenvolve um sistema de forma metodológica sem a modularidade.
Todo desenvolvimento precisa de uma ordem e de um padrão a serem seguidos. Por isso, a metodologia
também é uma premissa importante no desenvolvimento de sistemas.
No entanto, por que devemos usar o desenvolvimento metodológico de sistemas?
A resposta é que todo e qualquer projeto ou sistema deve ser arquitetado segundo uma metodologia
estruturada, moderna e que ofereça principalmente uma documentação completa e de qualidade.
Dentro da organização, a metodologia tem o papel de efetividade, continuidade, perenidade, segurança

e transparência, sendo aceita e implementada pelos gestores, clientes, usuários e desenvolvedores.
Podemos dizer também que a utilização da metodologia de desenvolvimento de sistemas:
• fornece visão do estado do projeto a qualquer instante;

• serve como meio de comunicação entre os envolvidos;
• indica o nível de participação de todos os envolvidos;
• detalha os níveis adequados aos interesses da equipe envolvida;
45
Unidade II
• mantém um histórico documental do sistema;
• cria uma base de dados para fases e subfases futuras.
3.3 Fases da metodologia de desenvolvimento
Observando o ciclo de vida de um sistema de informação, podemos dizer que as fases da metodologia
de desenvolvimento seguem as etapas do ciclo de vida humano. No entanto, essas etapas não funcionam
necessariamente como ciclo de vida porque na metodologia de desenvolvimento o processo possui um
dinamismo muito maior.
Observação
Em toda metodologia de desenvolvimento devem-se respeitar pontos de avaliação de qualidade e

realizar a revisão da qualidade do projeto e a validação formal com os envolvidos.
As fases da metodologia são:
• estudo preliminar;
• análise do sistema atual;
• projeto lógico;
• projeto físico;
• projeto de implantação.
Projeto de Estudo
implantação preliminar
Projeto físico Análise do

sistema atual
Projeto
lógico
Figura 23
Dentro de cada fase da metodologia de desenvolvimento, existem atividades que funcionam como
um guia de utilização. Essas fases são denominadas subfases do desenvolvimento de sistemas e são
ajustadas conforme o valor, o tipo, a estrutura e a realidade da organização.
46
Ao discorrermos sobre cada uma das fases, descreveremos também suas subfases e os produtos
gerados por elas.
3.3.1 Estudo preliminar
O estudo preliminar tem por objetivo compreender a necessidade e a estrutura do sistema a partir de
suas origens e envolvidos, valendo-se de uma visão global e genérica e concebendo um protótipo com a
primeira definição dos requisitos funcionais desejados, objetivos, abrangências, integrações, limitações,
impactos e áreas englobadas.
As subfases do estudo preliminar são:
• Equipe:
— determinar os stakeholders ou os envolvidos. Nessa fase, são definidos o patrocinador, o gestor

do projeto, a equipe técnica e os responsáveis por seus respectivos departamentos e funções.
É de extrema importância que os usuários por parte do cliente estejam bem envolvidos no
projeto, pois são eles que vão transmitir a necessidade real da organização.
• Diretrizes e necessidades:
— receber as diretrizes da alta direção da organização ou do cliente;
— planejar as atividades das subfases; rever a metodologia; se necessário, elaborar uma forma de
trabalho para o projeto; reunir os formulários do projeto; definir as datas previstas e os recursos
necessários para atendê-la; definir as atribuições de cada pessoa na equipe, ou seja, o papel e
as responsabilidades de cada um; e, caso necessário, realizar o treinamento aos envolvidos;
— realizar o levantamento das necessidades que o projeto pretende atender para satisfazer o
cliente e também elencar os requisitos de forma preliminar;
— levantar os principais problemas da organização que levaram à solicitação do projeto.
• Requisitos funcionais:
— definir os objetivos do projeto e detalhar com o cliente os requisitos funcionais (entrada,

processamento e saída), para os quais se devem dimensionar quantitativamente e
qualitativamente os dados levantados;
— delimitar a abrangência do projeto, ou seja, especificar suas fronteiras, pois isso permite que o
projeto seja atendido de forma correta sem que haja perda de tempo e de dinheiro e desgaste
da equipe. Nessa delimitação, para se ter um escopo bem definido, devem-se observar também
os sistemas interligados ou que terão comunicação no futuro e as áreas da organização que
serão envolvidas;
47
Unidade II
— identificar impactos e propor soluções mitigadoras, já que a mudança de cultura, filosofia ou

política em uma organização pode causar grandes danos ao projeto e até mesmo interrompê-lo.
Esses impactos devem ser levantados em relação não somente a sistemas de informação, mas
também a processos administrativos, comportamentais, financeiros e culturais da organização;
— elencar as possíveis limitações do projeto, tais como fatores ambientais, de mercado, financeiros,
culturais, de recursos humanos, materiais e tecnológicos;
— para melhor compreensão dos envolvidos, deve-se criar um dicionário de dados ou um glossário
com todos os termos utilizados, pois podemos adicionar a ele termos técnicos e conceitos
do negócio da organização, fazendo com que, assim, todos os envolvidos entendam qual o
assunto em questão;
— identificar soluções alternativas para os problemas apresentados, estando sempre alinhado ao

atendimento das necessidades principais do projeto relatadas pelo cliente;
— realizar o levantamento da estimativa de prazo e elaborar o primeiro cronograma para

apresentar aos envolvidos;
— analisar a viabilidade do projeto e seus benefícios mensuráveis ou não.
Observação
Custo e prazo são pontos fundamentais e de constante discussão em

projetos, por isso devem receber atenção especial, já que o pressuposto é
que os projetos sejam entregues dentro do prazo e do curso acordados.
Além disso, um terceiro pilar é de extrema importância: a qualidade. Sem
ela, o custo e o prazo estão incompletos.
• Estratégia de análise:
— rever a metodologia utilizada, definir papéis e responsabilidades e elaborar uma forma única de
trabalho para cada projeto, o que é uma maneira de personalizar e garantir qualidade. Vale a seguinte
observação nesse ponto: mesmo o projeto sendo único, é interessante ter uma base de dados com
as lições aprendidas durante sua execução, pois são essas lições que servirão de base para projetos
futuros. Esse é o momento também de analisar o sistema atual e, com isso, encontrar seus pontos
fracos, que merecem atenção, e seus pontos fortes, que podem ser reutilizados;
— rever o cronograma proposto e concluir sua elaboração com o envolvimento de toda a equipe.
• Estudo preliminar:
— realizar uma pré-avaliação da satisfação do cliente e da equipe nos quesitos qualidade e

produtividade e quanto à documentação do projeto. Criar uma pasta física e outra digital
48
para guardar, de forma segura, gráficos, diagramas, documentação e informações importantes

relacionadas ao projeto;
— elaborar um termo de compromisso para a aprovação de toda a equipe do projeto e,

posteriormente, apresentá-lo em uma reunião formal aos patrocinadores do projeto juntamente
com a gestão do projeto e os demais envolvidos.
3.3.2 Análise do sistema atual
Essa fase é útil para o conhecimento do ambiente e do produto a partir da utilização de uma
visão global do atual sistema, relatando os requisitos funcionais atuais e observando suas vantagens e
desvantagens por meio do levantamento de dados e organização das informações.
As subfases dessa fase são:
• Rever o estudo preliminar:
— realizar uma nova análise do estudo preliminar entregue e verificar se há a necessidade

de algum ajuste ou implementação. Essa prática é importante para que não haja nenhum
problema futuro com o cliente.
• Estudo do ambiente:
— levantar os sistemas existentes na organização e suas ligações com o sistema pretendido por ela;
— procurar saber quais departamentos farão parte do projeto e qual o envolvimento dessas áreas
com o novo sistema e com os sistemas atuais;
— fazer o levantamento do perfil principal dos clientes e dos usuários do sistema;
— determinar a abrangência do novo sistema, ou seja, quais as fronteiras que ele pode atingir,
contando sempre com a ajuda dos envolvidos e deixando claro ao cliente que essa abrangência
não envolve atualizações no sistema atual;
— realizar um levantamento de toda a documentação dos processos, procedimentos, modelos,

regras e padrões dos sistemas existentes na organização.
Observação
O fator abrangência é de extrema importância, pois o cliente pode

acreditar que a presença da equipe de levantamento/desenvolvimento
poderá salvá-lo de todos os problemas, incluindo o do sistema ou processo
existente. Isso nem sempre é verdade, principalmente se o projeto for para
o desenvolvimento de um novo sistema.
49
Unidade II
• Levantar pontos críticos:
— entender os pontos fortes e fracos, pois desse modo poderemos identificar fatores positivos do
sistema atual e, com isso, otimizar o desenvolvimento do novo projeto;
— no quesito pontos fracos ou desvantagens, é preciso verificar os pontos críticos, os gargalos, as

limitações e a defasagem do sistema de informação;
— utilizar fatores de sucesso para o êxito do processo;
— anotar todas as sugestões do cliente, pois elas poderão ter utilidade no futuro.
• Desenhar o sistema atual:
— atualizar ou refinar o dicionário de dados levantados com os termos já existentes e com os

previstos para o novo sistema, principalmente no fator negócio. Esse desenho se desdobra
sobre a ação de elencar os diagramas, o processo e o fluxo de dados do sistema existente na
organização.
• Definir o projeto lógico:
— por meio da identificação das rotinas e dos processos existentes na organização, é possível
estabelecer quais serão as prioridades do novo projeto e, com isso, se ele terá divisões;
— fazer uma análise de viabilidade para a elaboração do projeto lógico, contendo custo total do
projeto e seus benefícios, sejam eles viáveis ou inviáveis;
— rever a metodologia a ser adotada, a equipe e como os recursos serão utilizados, lembrando
dos treinamentos e da capacitação para que toda a equipe atenda à necessidade do cliente de
forma clara, concisa e, principalmente, com qualidade;
— com a identificação de impacto, podem-se evitar o retrabalho e o aumento de custo e de

prazo. O levantamento dos impactos cultural, financeiro, político, administrativo, de recursos
humanos, ambientais, logísticos etc. já foi feito anteriormente, porém é o momento de revê-
los, pois é importante para um projeto sempre fazer a revisão de alguns pontos, principalmente
de pontos críticos.
• Validar a análise atual:
— elaborar um documento com o parecer do cliente contendo a avaliação deste e da equipe sobre
a produtividade, a qualidade e o foco nos objetivos do projeto;
— arquivar de forma segura toda a documentação do projeto juntamente com papéis de trabalho
e estudos de caso e viabilidade na pasta eletrônica e física do projeto;
50
— realizar mais uma revisão da fase anterior para verificar a necessidade de ajustes, correções e
melhorias;
— apresentar ao patrocinador, ao gestor, à equipe do projeto e aos demais stakeholders (envolvidos)

a documentação do projeto para validação por meio de assinaturas e de datação.
3.3.3 Projeto lógico
Nessa fase, define-se o que o sistema fará. É nela que uma macroproposta de solução é confeccionada,
os requisitos funcionais reais são definidos e o detalhamento da lógica ideal do projeto é desenhado.
Além disso, é nesse ponto que se conhecem o ambiente e o produto existentes.
As subfases do projeto lógico são:
• Rever a análise atual:
— revisitar novamente a análise do sistema atual, incluindo o estudo preliminar, com o objetivo
de constatar que não há nenhum ajuste a ser realizado e, caso exista, implementá-lo.
Lembrete
Para que tantas revisões? Em cada nova fase se fala de uma revisão, e
isso parece cansativo para o projeto. Entretanto, é uma etapa importante
dentro das fases, pois, se conseguirmos constatar falhas e corrigi-las antes
da conclusão do projeto, poderemos apresentá-lo com qualidade e em
conformidade com as necessidades do cliente.
• Definir a macroproposta:
— elencar as alternativas a serem propostas ao cliente. Essas alternativas devem abranger desde o
desenvolvimento interno até a proposta de desenvolvimento externo (terceirização, compra de
pacotes, entre outros). Para cada alternativa, devem-se sempre apresentar dados importantes
de custo-benefício, como valor, prazo, qualidade e o que a organização terá de melhorias com
a utilização dessa ferramenta ou software;
— adotar a solução que acredita-se ser a mais correta, com base no estudo de viabilidade realizado
sobre as macropropostas apresentadas e demais estudos.
Observação
Quando se realiza um estudo de viabilidade, devem ser levados em
conta fatores econômicos, técnicos, mercadológicos, de segurança,
comportamentais, legais e operacionais, além do prazo e do custo.
51
Unidade II
• Descrever a lógica:
— analisar os requisitos levantados e distribuí-los em módulos. Nessa etapa, devem-se realizar

ajustes com base nas fases anteriores;
— o desenho ou diagrama é a melhor forma de entendimento entre a equipe de levantamento

de requisitos e aqueles que irão desenvolver, programar e codificar o sistema. Dessa forma,
a transmissão das informações pode ser mais clara e conter mais recursos do que a mera
forma escrita. Quando os requisitos são colocados em um diagrama de forma lógica, é possível
também reler o que foi documentado e corrigir ou ajustar possíveis falhas;
— o dicionário de dados deve ser complementado e refinado com todas as informações

levantadas até o momento. Ele deve ser detalhado com base nos requisitos funcionais reais,
sendo que esse detalhamento deve ser feito com uma linguagem natural e clara, de modo
que facilite o entendimento de todos, ou seja, qualquer pessoa que ler o dicionário de dados
deverá compreender os conceitos que estão nele descritos. Nesse dicionário, também são
contemplados os processos, os fluxos, o depósito de dados e as entidades externas, pois ele
também é utilizado para a modelagem de banco de dados quando houver um SGBD (sistema
de gerenciamento de banco de dados);
— desenhar os documentos que serão utilizados pela organização. Esses documentos são
chamados de documentos de entrada e documentos de saída e são formados por layouts
de telas, formulários e relatórios, contemplando tamanho, formato, estilo de letra e outros
detalhes;
— analisar e detalhar a forma de integração com outros sistemas e/ou projetos, se houver.
• Forma de trabalho do projeto físico:
— ainda estamos dentro do projeto lógico, mas não podemos deixar passar o momento para
realizar o planejamento do projeto físico, pois, na maioria das vezes, as fases de um projeto se
misturam para que todas sejam cumpridas dentro do prazo;
— realizar um estudo e definir qual tecnologia o novo sistema utilizará, sendo elas hardware,
sistema operacional, software e aplicativos, entre outros que se fizerem necessários;
— rever os impactos que o novo sistema causará na organização, como os impactos cultural,
financeiro, filosófico, político, administrativo, ambiental, comportamental, de recursos
humanos, de processos operacionais etc.;
— realizar uma análise dos requisitos logísticos para o desenvolvimento do projeto e verificar as
instalações e a infraestrutura necessárias a ele. Com base nessas informações, montar o plano
logístico para atender a essas necessidades;
52
— rever novamente a equipe, as responsabilidades, os prazos e o cronograma, verificando também

se existe a necessidade de substituição de algum membro da equipe;
— realizar uma análise de custo-benefício do projeto, levando em consideração valores do projeto

anterior e, com isso, verificar a viabilidade do projeto em desenvolvimento.
• Validar o projeto lógico:
— avaliar se o projeto está em conformidade com os requisitos solicitados, se satisfaz o cliente e a

equipe, se atende às demandas de qualidade e de produtividade e se está com a documentação
correta;
— revisar as fases anteriores com o objetivo de verificar a necessidade de ajustes e correções;
— arquivar a documentação do projeto de forma organizada e estruturada na pasta física e digital

do projeto, contendo nessa documentação os papéis de levantamento, as atas de reunião e os
estudos de caso, entre outros;
— elaborar um documento que será apresentado à equipe para que haja concordância no que está
sendo realizado. Esse documento deve ser datado e nele deve haver as assinaturas de todos os
envolvidos da equipe para validar e ratificar o projeto. Além disso, esse documento pode ser
chamado de termo de compromisso, termo de concordância ou termo de formalização;
— após a elaboração e a assinatura do documento, ele deve ser apresentado em reunião formal
ao patrocinador do projeto, ao gestor da empresa e aos demais envolvidos para a aprovação
formal.
3.3.4 Projeto físico
No projeto físico, define-se como o sistema fará o que se propõe a fazer, como será sua execução,
como se dará a confecção de seus respectivos subsistemas e como será a configuração do layout de
entrada e saída. Essa etapa é elaborada para que se obtenha uma visão sistêmica do ponto de vista físico
e de segurança dos resultados.
Observação
No início de cada nova fase, é importante fazer a revisão da fase anterior,
pois, com esse procedimento, pode-se encontrar algum ponto que precisa
ser melhorado e, com isso, a fase em questão terá um rendimento melhor.
• Rever o projeto lógico:
— realizar uma nova revisão no projeto lógico, incluindo nela um estudo preliminar e a análise do
sistema atual, visando a ajustes ou correções.
53
Unidade II
• Elaborar um modelo de dados:
— finalizar o dicionário de dados já iniciado em fases anteriores, fazendo um refino nas informações
e ajustando-o e complementando-o quando necessário;
— elaborar o modelo de dados com desenhos e diagramas, visando ajustar o banco de dados e
eliminar os procedimentos do sistema que não serão mais utilizados;
— reestruturar os dados e analisar as dependências e redundâncias.
• Padronizar a arquitetura:
— definir os arquivos de depósito de dados e transformá-los em arquivos físicos que possam ser
acessados por outros sistemas;
— a segurança também faz parte do projeto e ela é muito importante. Assim, esse é o momento
de definir o plano de segurança das informações, controle de acesso, sistema de backup, cópias
de segurança e um plano de recuperação.
• Desenvolver o sistema:
— concluir a definição do layout das telas de entrada e saída de dados, sempre seguindo a
linguagem que foi previamente definida e a tecnologia escolhida;
— iniciar o desenvolvimento do projeto, ou seja, a etapa geralmente chamada de construção ou

codificação do sistema, na qual, com base nos requisitos levantados e em toda a documentação
do projeto, o analista transforma toda a redação em algo prático e concreto, ou seja, constrói
o sistema que a organização solicitou. Se houver necessidade, é nesse estágio que são
construídos, paralelamente, sistemas e softwares que possam agregar valor ao negócio ou
mesmo ao sistema principal, foco do projeto. Esses programas ou softwares paralelos visam
facilitar a utilização ou implementação do projeto.
• Conclusão do sistema:
— a fase de teste, muitas vezes considerada desimportante pelas empresas por poder fazer
com que o projeto tenha retrabalho devido a falhas e possíveis correções, é uma fase que
evita o desgaste com o cliente e garante que o projeto seja entregue com qualidade. Nessa
fase, elabora-se o plano de teste contendo todas as telas que serão testadas e cada teste que
será executado, com tempo de execução e formato, entre outros. Os módulos, programas e
componentes devem ser testados de forma isolada e integrada para garantir as funcionalidade
e a integração entre todo o sistema;
— desenhar os fluxos operacionais e descrever os procedimentos operacionais que os embasam,

sendo que ambos precisam estar ligados ao sistema;
54
— complementar a documentação que vinha sendo gerada desde o início do projeto e organizá-
la na pasta do projeto. Nessa documentação devem constar os manuais do sistema para o
usuário final, o manual de negócio e o manual técnico.
• Definir o projeto de implantação:
— elencar as necessidades para o projeto de implantação, tais como a definição de equipe,

responsabilidades, atribuições, materiais, cronograma e outros recursos necessários;
— capacitar a equipe, verificar a necessidade de capacitação da equipe e contratar os treinamentos

necessários para os envolvidos no projeto;
— montar um plano de conversão de dados para que não se percam informações importantes
existentes em outros sistemas na hora da migração. Elaborar também um plano de recuperação
e armazenamento dos dados.
• Validar o projeto físico:
— avaliar se o projeto físico está em conformidade com os requisitos solicitados, se satisfaz o

cliente e a equipe, se atende aos itens de qualidade e produtividade e se está em conformidade
com a documentação;
— revisar as fases anteriores com o objetivo de verificar a necessidade de ajustes e correções;
— arquivar a documentação do projeto de forma organizada e estruturada em uma pasta física

e digital, nas quais constará toda a documentação do projeto, como papéis de levantamento,
atas de reunião, estudos de caso etc.;
— elaborar um documento que será apresentado à equipe para a concordância do que está sendo
realizado. Esse documento deve ser datado e ter as assinaturas de todos os envolvidos da equipe,
validando e concordando com o projeto. Ele pode ser chamado de termo de compromisso,
termo de concordância ou termo de formalização;
— após a elaboração e assinatura do documento, ele deve ser apresentado em reunião formal ao
patrocinador do projeto, ao gestor da empresa e aos demais envolvidos para aprovação formal.
3.3.5 Projeto de implantação
Ao iniciarmos a conclusão da metodologia de desenvolvimento, é na fase de implantação que se

elabora o plano real entre usuário com características reais de qualidade, produtividade e continuidade.
Nesse momento de disponibilização, são feitos o planejamento da implantação, o treinamento, a
capacitação do cliente e/ou usuário e o acompanhamento pós-implantação.
55
Unidade II
• Rever o projeto físico:
— revisitar novamente o projeto físico, incluindo o estudo preliminar, a análise do sistema atual
e o projeto lógico, com o objetivo de constar que não há nenhum ajuste a ser realizado e, caso
exista, implementá-lo.
• Refinar o plano de implementação:
— definir o cronograma de implantação. Se ele já estiver escrito, revisá-lo, pois o momento é de

ajustar os recursos humanos e materiais necessários, as atribuições e responsabilidades e as
datas. Esse cronograma deve ser concluído nessa fase, pois é com base nele que se realizará a
implantação;
— finalizar o plano de conversão com a definição de onde serão armazenadas as informações;
— para que toda a implantação funcione como esperado, é necessário que toda a equipe saiba
usar o novo sistema. Para isso, é necessária a especialização ou o treinamento dos usuários no
sistema que irão utilizar. Essa é a fase em que essa capacitação deve ser concluída, para que a
implantação possa ser finalizada e a entrega do sistema ao cliente, concluída.
• Concluir o sistema:
— fase muitas vezes crítica no projeto, pois precisamos praticar o desapego (brincadeira). No
entanto, sempre existe a rotina de se ter aquele projeto, trabalhar nele e, quando ele acaba, o
que fazer? Falei em tom de brincadeira que devemos nos desapegar do projeto, mas isso ocorre
exatamente em razão de as pessoas não quererem terminar o projeto para que possam ficar
junto dele, que é tratado como um filho por alguns;
— momento de melhorar a massa de dados e refinar os testes, que devem ser realizados com
intensidade para que os erros encontrados possam ser corrigidos;
— finalizar a documentação, o que inclui o manual técnico, o de negócio, o operacional e os guias

rápidos, caso haja.
• Entregar o sistema definitivamente:
— instalar o sistema para o cliente em versão definitiva para utilização.
• Pós-implantação:
— realizar o acompanhamento pós-implantação é fundamental para o sucesso do projeto, pois

com ele mede-se a satisfação do cliente e de seus usuários até a sedimentação completa do
sistema. Também é importante medir se todos os requisitos funcionais solicitados e acordados
estão sendo atendidos de forma completa, correta e com qualidade.
56
• Finalizar o projeto:
— realizar a avaliação final do projeto, se ele está em conformidade com todos os requisitos
funcionais solicitados e se a qualidade implantada atende ao acordado;
— avaliar a produtividade e consolidar toda a documentação do projeto na pasta já criada,

mantendo uma cópia digital dela em local seguro;
— realizar a última reunião do projeto com todos os stakeholders (envolvidos), sendo eles
patrocinador, cliente, responsável por parte do cliente, responsável pela equipe do projeto,
gestor do projeto, gerente do projeto e toda a equipe envolvida. Nessa reunião, deve ser
apresentado um parecer de como foi o projeto. É interessante apresentar os pontos fortes e
fracos do projeto, sempre indicando que o projeto foi bem-sucedido e que houve o ganho em
aprendizado com os pontos fracos encontrados;
— após essa apresentação, o parecer final do projeto deve ser assinado por todos de maneira
formal, pois esse documento completa e conclui a pasta do projeto em questão.
3.4 Artefatos gerados nas fases
Artefatos são produtos gerados nas fases de desenvolvimento. Esses produtos podem ser desde
protótipos de tela, o sistema em si, a documentação do projeto etc.
3.4.1 Estudo preliminar
Visa compreender a necessidade e a estrutura do sistema a partir de suas origens e envolvidos:
• documento de solicitação do projeto;
• termo de abertura do projeto;
• atas de reunião;
• anotações realizadas durante as entrevistas e as reuniões;
• lista dos requisitos funcionais solicitados;
• levantamento preliminar;
• relação da equipe e de suas atividades e responsabilidades;
• dicionário de dados;
• análise de custos;
57
Unidade II
• documento com benefícios e viabilidades;
• termos utilizados;
• plano do projeto.
3.4.2 Análise do sistema atual
Momento de obter conhecimento do ambiente e do produto a partir da utilização de uma visão

global do atual sistema:
• funções do sistema;
• documentos de análise;
• relação de requisitos existentes no sistema atual;
• análise do perfil do cliente e/ou usuário;
• desenhos;
• descrições narrativas;
• relatórios do projeto com suas subfases;
• relatório de fatores críticos do projeto;
• relatório de vantagens e desvantagens.
3.4.3 Projeto lógico
Hora de definir o que o sistema fará:
• descrição lógica dos programas;
• desenho do processo;
• descrição lógica do dicionário de dados;
• esboço dos documentos de entrada;
• esboço dos documentos de saída;
• relação de requisitos funcionais reais ao projeto.

58
3.4.4 Projeto físico
Hora de definir como o sistema fará o que se propõe a fazer:
• programas;
• procedimentos;
• layout das telas;
• arquivos físicos;
• relatórios referentes a telas;
• modelos de dados;
• resultado de testes;
• relatório do projeto com as subfases.
3.4.5 Projeto de implantação
Hora de elaborar o plano real entre usuário com características reais de qualidade, produtividade e
continuidade:
• plano de implantação;
• relatório com os recursos necessários para a implantação;
• resultados finais dos testes realizados;
• capacitação com treinamentos à equipe;
• manual técnico;
• manual operacional;
• manual de negócios;
• relatório final do projeto.
Vale lembrar que para cada subfase foram gerados ainda cronogramas, termos de aceite e diversos
documentos que não foram citados, pois não são considerados documentos de entrega e sim documentos
de trabalho. Mesmo assim, todos os documentos têm igual importância ao projeto.
59
Unidade II
3.5 Modelos utilizados em projetos
Os modelos descritos a seguir são exemplos que podem ser utilizados em diversos projetos como
documentação complementar ou principal. Vale lembrar que, por serem modelos, podem ser modificados
de acordo com a necessidade de cada projeto. Utilize-os como base de apoio.
Em todos eles deve haver um cabeçalho contendo o título ou nome do projeto, a data de seu início
e os nomes dos responsáveis por ele nos cargos/atribuições de gerente, patrocinador e cliente.
3.5.1 Modelo de termo de abertura do projeto
Observe a seguir um modelo de termo de abertura com os itens que devem constar no projeto:
• objetivo: definir o que a organização pretende obter com o resultado do projeto;
• demanda: descrever por que o projeto está sendo realizado e qual é sua justificativa e alinhamento
estratégico;
• escopo: apontar o que é e o que não é escopo do projeto e descrever sucintamente os subprodutos
que serão e que não serão entregues;
• stakeholders (interessados): mencionar os principais envolvidos interna ou externamente com

o projeto ou aqueles que serão afetados positiva ou negativamente com sua execução;
• interfaces com projetos existentes: mencionar outros projetos que possam interferir de alguma
forma no desenvolvimento do projeto em questão;
• prazo estimado para a conclusão do projeto: definir uma estimativa de prazo para a entrega
do trabalho;
• orçamento estimado para a conclusão do projeto: definir uma estimativa de custo para a
entrega do trabalho;
• equipe básica: citar os especialistas que, inicialmente, ajudarão a compreender e planejar o

projeto;
• restrições: mencionar os fatores que podem limitar as opções da equipe do projeto;
• premissas: mencionar os fatores que, para fins de planejamento, serão considerados verdadeiros;
• gerente do projeto: indicar o gerente do projeto, suas principais atribuições e seu nível de
autoridade.
Esse documento deve ser datado e concluído com as assinaturas da alta direção e do patrocinador.
60
3.5.2 Modelo de documento de equipe
Observe a seguir um modelo de documento de equipe:
Figura 24
Observação
É importante ressaltar que toda a documentação deve ter o nome do

patrocinador e seu cargo, além do nome do cliente e gerente do projeto.
No final de cada documento deve haver ainda a assinatura datada de cada
um deles, pois somente dessa forma toda a documentação do projeto será
validada.
3.5.3 Modelo de plano para gerenciamento de escopo e de mudanças
Observe a seguir um modelo de plano para gerenciamento de escopo e de mudanças no projeto:
• Aspectos gerais:
— descrever os aspectos gerais do gerenciamento de escopo e de mudanças;
61
Unidade II
— inserir o procedimento para coletar requisitos (reuniões com clientes, avaliação de documentos
e informações, contratação de consultoria, investigação e visitas in loco) e definir e detalhar os
requisitos (reuniões com cliente, usuários etc.);
— inserir o procedimento para solicitação de mudanças, análise dos impactos da mudança

(aumento de escopo, cronograma, orçamento, qualidade, RH etc.) e confecção de relatório
para aprovação da mudança pelo cliente e pelo patrocinador;
— criar um documento de solicitação de mudanças e de aprovação anexo ao final do plano de

gerenciamento de projeto.
• Processo de gerenciamento de escopo e de mudanças:
— descrever o processo a ser seguido para definir, detalhar e controlar o escopo (fluxograma);
— descrever o processo para tratar as mudanças (fluxograma).
• Comitê de controle de mudanças:
— relacionar as pessoas responsáveis por analisar as solicitações de mudança.
• Processo de gerenciamento de configuração:
— descrever como será feito o controle dos itens, relacionando a forma de armazenamento, o
acesso, o registro de alterações e a identificação das versões.
• Itens de configuração e responsáveis:
— relacionar os itens passíveis de mudanças, que serão controlados, e indicar os responsáveis por
sua atualização. O documento deve ser datado e concluído com as assinaturas do gerente de
projetos, do cliente e do patrocinador.
3.5.4 Modelo de declaração de escopo do projeto
Observe a seguir um modelo de declaração de escopo do projeto:
• Resumo do projeto:
— descrever a situação que gerou a necessidade do projeto, o motivo pelo qual ele foi iniciado, as
expectativas frente a seus resultados e possíveis soluções;
— descrever o produto ou o serviço do projeto e a solução para o problema contextualizado

anteriormente;
62
— ressaltar o alinhamento estratégico do projeto e sua justificativa empresarial, ou seja, o que a

empresa vai ganhar executando o projeto.
• Objetivo do projeto: momento de descrever o que se espera atingir com a implementação do

projeto, seus fatores de sucesso e critérios de êxito.
• Metas do projeto: as metas do projeto são atividades que devem ser concluídas para que os
objetivos do projeto sejam atingidos. Ao descrever uma meta, certifique-se de que ela seja clara e
bem definida. A seguir, um modelo de metas smart:
— específica: é clara e concisa, para que as pessoas entendam exatamente o que você pretende atingir;
— mensurável: as metas precisam ser medidas e verificadas, ou seja, deve ser possível determinar
se a meta foi atingida ou não;
— acordada: as metas devem ser acordadas entre os stakeholders de modo a garantir que todos
estão trabalhando na mesma direção;
— realista: obviamente, as metas devem ser realistas, elas não podem ser inatingíveis;
— tempo limitado: toda meta deve ter um prazo para ser atingida/concluída.
• Lista completa de entregas e requisitos:
— deve descrever todas as entregas e requisitos do projeto.
• Exclusões de escopo:
— é importante que seja definido e registrado no documento o que não faz parte do projeto.
• Estimativas de tempo e custo:
— preencher o modelo de declaração de escopo do projeto com as estimativas de tempo e de

custo do projeto, incluir cronograma e orçamento preliminares.
• Funções e responsabilidades:
— inserir a matriz de funções e responsabilidades dos stakeholders no modelo de declaração de

escopo do projeto.
• Premissas, restrições e riscos:
— preencher no modelo de declaração de escopo do projeto os itens Premissas, Restrições e

Riscos Identificados do formulário, que são importantíssimos para o bom desenvolvimento do
projeto.
63
Unidade II
• Critérios de aceitação do produto/serviço:
— descrever o modelo de avaliação e aceitação dos resultados pelos stakeholders e incluir

formulários de aceitação com checklist de critérios para verificação.
Esse documento deve ser datado e concluído com as assinaturas do gerente do projeto, do cliente e
do patrocinador.
3.5.5 Modelo de plano para gerenciamento de tempo
O modelo de plano para gerenciamento de tempo deve conter:
• montagem do plano: descrever como serão feitas as estimativas de recursos e de tempo das
atividades para se chegar ao cronograma (opinião de especialistas, informações históricas etc.),
descrever como será controlado o cronograma, quais atividades poderão ser adiantadas ou
atrasadas, quais as restrições de tempo, como será o gerenciamento do caminho crítico etc.;
• definição de atividades, estimativa de recursos e durações: listar as atividades e tarefas

para concluir cada item da EAP (Estrutura Analítica do Projeto). A lista de atividades deve ser
consolidada em uma planilha;
• sequenciamento de atividades: desenhar um diagrama de rede e descrever a sequência lógica

das atividades para descobrir o caminho crítico. Esse sequenciamento deve ter uma forma gráfica
para facilitar sua visualização;
• cronograma: elaborar um cronograma em planilha, MS Project ou outra ferramenta para

cronograma.
O documento deve ser datado e concluído com as assinaturas do gerente do projeto, do cliente e do
patrocinador.
3.5.6 Modelo de plano para gerenciamento de custos
O modelo de plano para gerenciamento de custos deve conter:
• montagem do plano: momento de descrever como serão feitas as cotações e estimativas de

preços/custos e como será controlado e acompanhado o orçamento;
• estimativa de custos: elaborar uma planilha de estimativa dos custos dos materiais, recursos e
pessoas, entre outros;
• orçamento: consolidar as informações para criação do orçamento;
• cronograma: elaborar um cronograma de execução físico-financeiro, com as saídas de caixa

esperadas ao longo do projeto conforme a execução das atividades.
64
O documento deve ser datado e concluído com as assinaturas do gerente do projeto, do cliente e do
patrocinador.
3.5.7 Modelo de plano para recursos humanos
Um plano para recursos humanos visa descrever de forma clara e objetiva a quantidade de recursos
humanos necessários em cada especialidade para que o projeto seja realizado.
Ele deve conter informações que justifiquem a necessidade de contratação e informações sobre o
tipo de contratação (CLT, temporários ou PJ). Além disso, esse plano deve descrever a quantidade de
profissionais e as qualificações exigidas e incluir o tempo estimado de trabalho a ser realizado.
3.5.8 Modelo de plano para gerenciamento de riscos
O modelo de plano para gerenciamento de riscos descreve os aspectos gerais do gerenciamento dos
riscos, ou seja, como estes serão identificados, qualificados e quantificados. Além disso, esse modelo
permite planejar uma resposta aos riscos.
3.5.9 Modelo de plano para aquisições
Nesse plano, devem constar os aspectos gerais do gerenciamento das aquisições, com a descrição
detalhada dos itens que deverão ser comprados e de que forma a compra será realizada.
Observação
Mesmo que o modelo de plano pareça simples, sua elaboração é de

extrema importância para o projeto. Por exemplo, se um risco não for
levantado ou mitigado, ele pode comprometer totalmente a entrega do
trabalho.
3.6 Lições aprendidas
As lições aprendidas são importantes para o projeto, pois é a partir desse histórico que os novos
projetos ganham agilidade e menos problemas ou até mesmo ganham uma solução mais rápida nos
casos em que o problema foi inevitável.
Como base, há algumas perguntas que podem ser utilizadas para o levantamento das lições
aprendidas. Essas perguntas são apenas sugestões, pois em cada organização e projeto elas podem ser
melhoradas e acrescidas de informações pertinentes ao negócio.
Assim, no final do projeto, em uma reunião com todos os envolvidos, é possível fazer os seguintes
apontamentos:
65
Unidade II
• Cite três itens que, em sua opinião, mais contribuíram para que o projeto obtenha sucesso.
• 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 isso nos projetos futuros?
• Quais os principais obstáculos que afetaram o pleno desenvolvimento do projeto?
• Baseado em sua experiência no projeto, quais seriam as três recomendações que você faria para
o próximo time de projeto?
• Existiram fatores positivos no gerenciamento do projeto? Se sim, quais são eles?
• Quais itens você sugere para a melhoria do gerenciamento do projeto?
3.7 Técnicas de levantamento de dados
3.7.1 Questionário
O questionário é um formulário previamente desenvolvido de forma que apresente questões de fácil

compreensão a todos os envolvidos. A elaboração dessas questões deve partir de uma leitura crítica e
reflexiva voltada à percepção dos significados do sistema.
O questionário é um instrumento que pode ser utilizado em uma entrevista presencial ou ser
entregue para ser recolhido posteriormente. Com base em suas informações, pode-se tabular e gerar
um relatório completo com as informações coletadas.
As vantagens do questionário são as seguintes:
• ser menos dispendioso;
• possuir maior agilidade no processo;
• ter aplicação fácil;
• ter aplicação em grande número de pessoas;
• a uniformidade na mensuração;
• em determinados casos, é possível que haja o anonimato.
As desvantagens do questionário são:
• a manipulação de informações, o que gera respostas desejáveis e não reais;
• a concentração de respostas em determinada alternativa;
• ser um meio de comunicação “frio” de obtenção de informações.

66
3.7.2 Entrevista
Considerada por muitos a melhor técnica para o levantamento de dados, a entrevista é uma forma
organizada e de qualidade que contempla alguns subitens:
• Planejamento da entrevista: para que haja aproveitamento de uma entrevista, ela deve ser
previamente planejada, evitando principalmente o desperdício de tempo e de recursos. Seguem
alguns pontos importantes a serem analisados e executados quando desse planejamento:
— definir previamente o objetivo;
— planejar o local, a data, a hora e as condições ambientais;
— planejar claramente o conteúdo da entrevista com base em seu objetivo;
— preparar um checklist;
— adequar a entrevista para o nível intelectual, para a formação e para a experiência do entrevistado;
— planejar um roteiro de entrevistas que seja flexível, para que seja possível haver alterações em
sua ordem;
• Técnica: algumas informações são importantes para se realizar uma entrevista produtiva e de
qualidade:
— entrevistar primeiramente o titular (diretor, gerente, chefe) para que se obtenha a confiança do
entrevistado;
— dar a entender que deseja ajudar e não criticar o trabalho;
— priorizar perguntas simples;
— falar pouco e não emitir opinião própria sobre o assunto para não confundir o entrevistado;
— anotar as informações do entrevistado por melhor que seja sua memória;
— manter sigilo das declarações confidenciais;
— validar as informações obtidas com o superior imediato.
As vantagens da entrevista são:
• poder alterar a forma das perguntas para obter informações mais precisas ou detalhadas;
• alterar a ordem das perguntas quando essa alteração ajudar com informações precisas e valiosas;
67
Unidade II
• incluir perguntas que não constam no planejamento em virtude do desenrolar da entrevista;
• motivar o entrevistado;
• esclarecer dúvidas sobre as perguntas formuladas.
Observação
A entrevista é uma técnica extremamente útil para obter informações

que se encontram na memória da pessoa entrevistada.
3.7.3 Seminário
O seminário pode também ser chamado de workshop ou dinâmica de grupo. Ele é uma reunião
planejada de pessoas importantes para o desenvolvimento de um sistema e/ou projeto, pessoas essas
que podem ou não ser de diversas áreas. O seminário tem por fim obter informações gerais ou específicas
sobre a empresa.
Esse tipo de método proporciona vantagens na identificação de problemas de inter-relacionamento

e na visão integrada dos problemas.
Como no caso da entrevista, o seminário deve ser previamente preparado, tendo em foco desde
a postura do mediador ou condutor até a convocação (data, horário, local) e os assuntos a serem
abordados e discutidos.
3.7.4 Pesquisa
Uma forma de verificar o que já ocorre é fazer uma averiguação física de uma atividade e/ou
processo, pois assim é possível identificar prazos, volumes, ocorrências etc. Com a pesquisa, permite-se:
• identificar a real frequência dos acontecimentos;
• orientar-se por meio de volumes;
• estabelecer quais são os grandes problemas;
• confirmar possíveis dúvidas não esclarecidas anteriormente com outras técnicas.
3.7.5 Documentação
Todas as informações levantadas devem ser registradas, pois, dessa forma, garantimos um sistema
sustentável. Para isso, podemos utilizar as seguintes formas ou ferramentas de documentação:
68
• diagrama de objeto;
• diagramas de UML;
• diagramas de fluxo de dados;
• fluxograma;
• organograma;
• descrição narrativa;
• detalhamento funcional do processo.
Lembrete
Um levantamento bem feito fornece uma boa definição de sistema, de

efetividade do sistema, de diagnóstico perfeito, de soluções inteligentes e
de melhoria na imagem.
Saiba mais
Para saber mais sobre banco de dados, baixe os artigos do site Oracle
em:
ORACLE. Oracle and Big Data: transform your business with Big Data.
Acesso em: <http://www.oracle.com/us/technologies/big-data/index.
html>. Acesso em: 15 out. 2013.
4 METODOLOGIA DE DESENVOLVIMENTO ÁGIL DE SISTEMAS DE

INFORMAÇÃO
Em razão da grande quantidade de informações que trafegam nas corporações, precisamos cada vez
mais de softwares rápidos e bem desenvolvidos para que, por meio deles, seja viável converter essa gama
enorme de informações desencontradas em informações úteis à organização.
Com a constante mudança no mercado e no dia a dia das organizações, é quase impossível obter um
conjunto correto e completo de requisitos de um sistema organizacional.
Uma validação disso é que, como o software demora para ser desenvolvido devido à complexidade
do processo, quando ele é entregue já está desatualizado e não atende completamente à necessidade
69
Unidade II
do cliente. Obviamente que isso não ocorre com todos os projetos, porém, se não houver uma
metodologia e uma organização cuidando dessa estrutura, esse tipo de problema pode virar uma
regra na organização.
Como vimos, os processos de desenvolvimento de sistemas de informação são de extrema importância

para a organização. Contudo, existem casos nos quais a “loucura” da organização necessita de outro tipo
de metodologia para atender à sua necessidade.
Isso não significa que tudo o que vimos até aqui está errado. A metodologia padrão é bem desenvolvida
e é uma forma tradicional que vem sendo aplicada e melhorada constantemente. Entretanto, ela não
atende a alguns casos e, por esse motivo, existem outras formas de se realizar o mesmo processo de
levantamento e implantação de um sistema de informação. Uma dessas outras formas é a metodologia
ágil.
A metodologia ágil, por mais que tenha essa denominação, não está livre de ter regras, procedimentos
e boas práticas, pois somente assim se chega ao sucesso e a uma entrega bem-sucedida.
Considerado um sistema crítico no qual a análise completa é primordial, um sistema de controle

de segurança demanda uma metodologia de desenvolvimento tradicional, que passa cada item
detalhadamente e de forma específica e tem em vista a abordagem profunda e diferenciada que um
sistema de controle de segurança exige. Já no caso de um sistema de negócio não caracterizado como
crítico, a metodologia ágil pode atender à demanda de forma rápida.
Os sistemas desenvolvidos em metodologia ágil apresentam algumas características fundamentais:
• o projeto e a implementação são realizados de forma intercalada;
• a documentação é gerada automaticamente pelo ambiente de programação;
• o documento de levantamento de requisitos não é totalmente detalhado, constando nele apenas

as características importantes do sistema;
• o sistema não é desenvolvido de uma só vez e sim em uma série de versões;
• os stakeholders são envolvidos na especificação e validação de cada versão (como relatado no

outro modelo, o cliente está incluso no grupo dos stakeholders).
A cada versão, os stakeholders podem propor novos requisitos e sugerir melhorias que serão
concretizadas na próxima versão.
Há a existência de uma interface interativa com o usuário.
Dessa forma, há a possibilidade da criação de uma interação com o usuário por meio de uma tela
rápida de criação, podendo essa comunicação ser feita por figura, desenho e ícones, o que facilita a
70
conversa com o usuário final. Essa interface geralmente é desenvolvida baseada em web para navegar,
pois é um ambiente mais familiar ao usuário.
Observação
Esse tipo de metodologia é mais aplicável aos sistemas que sofrem

muitas mudanças no caminho até sua conclusão.
A metodologia ágil foi desenvolvida por grandes equipes que tinham dificuldades semelhantes, já
que passavam longos períodos trabalhando em um mesmo sistema. Um exemplo foi o projeto de um
sistema de controle de uma aeronave que durou mais de dez anos desde sua especificação inicial até sua
implantação. As equipes perdiam muito tempo em um projeto e muitas vezes não conseguiam atender
à necessidade do cliente devido às alterações constantes no mercado e seus reflexos do dia a dia, como
já mencionado anteriormente.
Com todo esse processo na década de 1990, um grupo de desenvolvedores insatisfeitos com as
abordagens pesadas de engenharia de software propôs uma metodologia chamada metodologia ágil.
Um dos pontos dessa metodologia é eliminar a documentação criada e não usada, já que muitos
documentos são criados e nunca usados no projeto.
A metodologia ágil tem sua existência baseada em um manifesto, que aponta as seguintes
constatações:
Estamos descobrindo melhores maneiras de desenvolver softwares,

fazendo-o e ajudando outros a fazê-lo. Através deste trabalho, valorizamos
mais:
• indivíduos e interações do que processos e ferramentas;
• software em funcionamento do que documentação abrangente;
• colaboração do cliente do que negociação de contrato;
• respostas a mudanças do que seguir um plano.
Ou seja, embora itens à direita sejam importantes, valorizamos mais os que

estão à esquerda (BECK, 1999).
Com base nas afirmações do Manifesto Ágil, foram criadas formas de trabalho como o Scrum, RUP,
extreme programming e outros métodos até então não considerados.
Esses métodos são baseados em desenvolvimento e entrega incremental, porém eles propõem uma
forma diferenciada de alcançar os objetivos esperados no projeto.
71
Unidade II
Nos métodos mais utilizados, ou seja, no Scrum e no extreme programming, temos fortemente
definidos os princípios da metodologia ágil, princípios esses focados no cliente, em pessoas, em
mudanças, na entrega e na simplicidade.
• cliente: o cliente tem papel fundamental no processo e deve estar totalmente envolvido nele. Ele
tem como responsabilidade fornecer e priorizar os requisitos do sistema e realizar a avaliação da
existência de suas interações;
• pessoas: cada pessoa na equipe deve encontrar e desenvolver sua maneira de trabalhar/sua
própria metodologia sem a existência de processos definidos de modo padronizado para todos.
As habilidades da equipe devem ser vistas, reconhecidas e principalmente exploradas a fim de
agregar valor aos demais membros da equipe;
• mudanças: desde o início do desenvolvimento aceita-se que haverá mudanças, assim, já se

programa como o sistema as acolherá sem maiores transtornos;
• entrega: realizada em comum acordo com o cliente, funciona de forma incremental e é realizada
a cada requisito incluído;
• simplicidade: é fundamental que a simplicidade seja mantida. Sempre que possível, é realizada
uma análise da complexidade das informações para que elas possam ser simplificadas. O trabalho
é focado sempre na simplicidade do desenvolvimento do sistema e do processo de trabalho de
cada pessoa nele envolvida.
O modelo ágil tem sido bem-sucedido no desenvolvimento de produtos como softwares em

organizações de pequeno e médio porte e sistemas personalizados dentro de organizações que não têm
processos, procedimentos e regras definidas.
Esse modelo é sempre muito atraente aos desenvolvedores e à equipe, que podem trabalhar de
forma não tão metódica. Entretanto, existem pontos fracos e riscos na metodologia ágil. São eles:
• a ideia de envolver o cliente e fazer com que ele faça parte do projeto diretamente é
genial em qualquer metodologia de grande valia, afinal, ter por perto quem entende do
negócio trabalhando e ajudando com informações valiosas ao projeto é muito bom. Ter uma
metodologia dependente desse item é arriscado, pois se fica dependente da disposição do
cliente, que esta lá para atender à equipe do projeto sempre que pode, pois sua rotina é
conturbada e cheia de compromissos;
• muitas pessoas estão acostumadas a trabalhar sob cobranças, ou seja, elas não estão habituadas a
definir sua própria forma de trabalho e ajudar o parceiro de equipe quando este tiver dificuldades.
Por isso, deve-se atentar para esse ponto frente ao envolvimento da equipe, já que a interação
entre o grupo pode vir a ser um problema, pois somente se todos trabalharem em equipe o projeto
será bem-sucedido;
72
• se houver a existência de muitos stakeholders e cada um tiver sua prioridade, o trabalho sofrerá
com as dificuldades em definir as mudanças prioritárias de forma a não gerar conflito entre os
stakeholders e atender ao máximo todas as mudanças;
• além das pressões, prazos e cronogramas, na metodologia ágil existe ainda o fator simplificação,
o que demanda a adequação da documentação a esse fator;
• em organizações nas quais já existe um processo definido e implementado, será difícil convencer
sobre a implantação de uma metodologia ágil, na qual os processos são definidos por cada
integrante da equipe. A implantação de uma metodologia leva anos e gera um trabalho árduo de
mudança cultural de equipe em equipe da empresa, daí a resistência em aceitar um novo modelo.
Uma forma recomendada para a utilização da metodologia ágil é o cliente pagar não pelos requisitos
solicitados, mas pelo tempo de desenvolvimento. O problema desse modelo é definir um cronograma
passível de ser cumprido.
Tendo em vista a minimização de documentos formais, é possível realizar a manutenção de um

sistema em desenvolvimento utilizando a metodologia ágil? Vale lembrar que a metodologia ágil é uma
forma de trabalho e não simplesmente um conjunto de pessoas fazendo as coisas de forma desordenada
e desorganizada.
No modelo ágil, a documentação formal não existe como em outras metodologias, o que existe é
outra forma de documentar, de forma mais simples, ou seja, a forma de documentação simplificada do
método ágil não pode atrapalhar ou gerar problemas em uma manutenção a ser realizada, ela é uma
documentação e deve ser útil para tal.
Assim, como recomendação, é importante que o documento de levantamento de requisitos exista e

seja bem detalhado, pois ele é uma peça importante para futuras manutenções do sistema.
Um ponto de atenção na metodologia ágil é em relação à equipe. Como não há uma consulta à
documentação e o sucesso do desenvolvimento depende do entendimento de cada pessoa da equipe
envolvida, isso poderá acarretar problemas caso haja alteração em pessoas da equipe, pois assim perde-
se perde também conhecimento.
4.1 Princípios por trás do Manifesto Ágil
Os princípios a seguir foram retirados do Manifesto Ágil existente atualmente:
Nossa maior prioridade é satisfazer o cliente por meio da entrega contínua

e adiantada de software com valor agregado.
Mudanças nos requisitos são bem-vindas, mesmo tardiamente no

desenvolvimento.
73
Unidade II
Processos ágeis tiram vantagem das mudanças visando vantagem

competitiva para o cliente.
Entregar frequentemente software funcionando, de poucas semanas a

poucos meses, com preferência à menor escala de tempo.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em

conjunto por todo o projeto.
Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário e confie neles para fazer o

trabalho.
O método mais eficiente e eficaz de transmitir informações para e entre uma

equipe de desenvolvimento é através de conversa face a face.
Software funcionando é a medida primária de progresso.
Os processos ágeis promovem desenvolvimento sustentável. Os

patrocinadores, desenvolvedores e usuários devem ser capazes de manter
um ritmo constante indefinidamente.
Contínua atenção à excelência técnica e bom design aumenta a agilidade.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado

– é essencial.
As melhores arquiteturas, requisitos e designs emergem de equipes auto-

organizáveis.
Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e

então refina e ajusta seu comportamento de acordo (MANIFESTO..., 2001).
Saiba mais
Acesse o site do manifesto ágil e entenda mais sobre a metodologia

ágil, sua criação e fundadores: <http://manifestoagil.com.br/>. Acesso em:
7 out. 2013.
74
4.2 O desenvolvimento em metodologia ágil
Na metodologia ágil, o projeto e a implementação são considerados foco central. Todas as outras
atividades, como levantamento de requisitos, teste e implementação, estão inseridas dentro desses
processos. Em uma abordagem comum, existe o levantamento de requisitos e sua especificação e, depois
do projeto e da implementação no modelo comum, os requisitos passam por uma série de processos
para amadurecimento antes de serem concluídos. Já na metodologia ágil, isso é feito internamente no
processo. Para exemplificar melhor, vamos elencar uma série de fatores que precisam ser revistos nas
questões técnicas, pessoais (humanas) e organizacionais para se encontrar um equilíbrio na utilização
de uma metodologia.
• É importantíssimo ter a especificação do projeto e o projeto totalmente detalhados antes da fase

de implantação? Se sua resposta foi sim, então esse projeto não pode utilizar uma metodologia
ágil. Utilize a comum.
Observação
A metodologia comum é qualquer outra metodologia de desenvolvimento

já citada, menos a metodologia ágil e suas diversas formas.
• Se há a necessidade de se obter a opinião rapidamente assim que se entrega o sistema (software)

ao cliente, pode-se utilizar a metodologia ágil.
• Sistemas que demandam uma análise profunda anterior à implementação, como sistemas com
requisitos complexos, muito detalhados e com diversas análises, pedem a utilização de uma
metodologia comum que visa atender à demanda.
• Qual o tamanho do sistema que está sendo desenvolvido? Se o sistema tiver uma equipe pequena
e com capacidade de comunicação informal, pode ser utilizada a metodologia ágil.
• Existe tecnologia como apoio ao sistema que está sendo desenvolvido? Se o sistema de
desenvolvimento é o IDE (Integrated Development Environment), que não possui grandes
ferramentas para analise, é importante que se tenha uma documentação mais detalhada e, por
esse motivo, se utilize a metodologia comum. Entretanto, se o projeto possui boas ferramentas de
apoio, pode-se utilizar a metodologia ágil.
• Se há a existência de questões culturais, pode haver a necessidade de se escolher a forma ou a

metodologia de desenvolvimento com base nesse quesito.
• Qual é a habilidade dos projetistas e desenvolvedores, ou seja, da equipe de desenvolvimento?

Existem diversas discussões com relação a esse ponto e uma delas é que se você não tem uma
boa ou uma excelente equipe de desenvolvimento, com habilidades e metodologias próprias, não
utilize a metodologia ágil, pois ela vai exigir mais do que sua equipe de desenvolvimento será
capaz de atender.
75
Unidade II
Engenharia Especificação Projeto e

de requisitos de requisitos implementação
Solicitação de mudança
Metodologia comum
Figura 25
Engenharia Projeto e
de requisitos implementação
Metodologia ágil
Figura 26
4.3 Metodologia extreme programming (XP)
A metodologia extreme programming (XP) é uma das mais utilizadas no método ágil de
desenvolvimento. Essa ideia surgiu com o objetivo de se ter um sistema testado ao extremo – daí a
nomenclatura XP – e, ao mesmo tempo, testado por diversos desenvolvedores com opiniões diferenciadas.
Nesse modelo, os requisitos viram cenários, que são trabalhados pelos desenvolvedores em pares. Eles
escrevem casos de teste para os códigos que serão desenvolvidos. Esse padrão tem suas características
próprias, o que difere das metodologias tradicionais, que trabalham de uma determinada forma
padronizada.
Essa metodologia envolve alguns princípios fundamentais e as boas práticas de toda a metodologia.
São princípios do extreme programming (XP):
• há a existência de releases pequenos e que acontecem com frequência para sustentar o

desenvolvimento incremental;
• os requisitos são baseados em cenários e têm como característica da metodologia ágil a

simplicidade na elaboração dos cenários;
76
• existe um envolvimento contínuo da equipe para que, dessa forma, também haja envolvimento
do cliente;
• tem que haver a participação de um responsável por parte do cliente durante todo o processo de
desenvolvimento;
• toda metodologia é sustentada por pessoas e não por processos. Utilizando o desenvolvimento
em pares, os casos serão solucionados em menos tempo, pois duas cabeças pensam em mais
possibilidades;
• as mudanças são realizadas a partir dos releases diretos para o cliente;
• como se preza pela simplicidade, a manutenção é realizada pela refeitura constante, o que gera
melhoria de qualidade no código fonte.
Selecionar cenário Dividir os cenários

em tarefas Planejar releases
Desenvolver
Testar
Liberar o sistema
Avaliar o sistema
Figura 27 – Como funciona um release no extreme programming (XP)
Além dos princípios, o método extreme programming (XP) também utiliza suas melhores práticas.
São elas:
• desenvolvimento: todo o desenvolvimento é feito em pares, ou seja, sempre um está revisando

o trabalho do outro e tendo ideias em conjunto, o que agrega valor ao trabalho e gera redução
de tempo, custo e estresse dentro do projeto, pois, na medida em que mais de uma pessoa
discute sobre o assunto, mais fica evidente que o produto gerado terá uma melhor qualidade e
entendimento;
• releases: são desenvolvidos em formas menores, com poucas funcionalidades e apresentados ao

cliente de modo mais rápido e constante, o que gera diversas aprovações e, consequentemente,
mudanças contínuas. No entanto, acredita-se que, com pequenas entregas, seja possível finalizar
mais rapidamente a entrega final;
77
Unidade II
• planejamento: aqui se desenvolve o planejamento incremental, no qual se arquiva os requisitos

em cenários distintos que serão convertidos em tarefas e, assim, enviados para desenvolvimento;
• projeto: como a metodologia prega a simplicidade, o projeto deve se ater a trabalhar sobre a
necessidade em contrato. Não é interessante ficar agregando necessidades ao projeto, pois isso o
torna muito mais longo e possivelmente sem fim;
• teste: com a existência de um framework para testes, é possível que os desenvolvedores escrevam
os testes antes mesmo do desenvolvimento ou codificação do sistema;
• refatoração: por meio de uma refeitura, os desenvolvedores conseguem deixar o código simples
e aplicar as melhorias contínuas que devem existir em qualquer boa prática de uma metodologia;
• propriedade: a integração da equipe e o desenvolvimento em pares permite que as duplas interajam

entre si e opinem em relação ao trabalho dos demais. Dessa forma, não há um proprietário único
do código, ele é coletivo;
• integração: como o sistema está sendo desenvolvido em partes, na conclusão de cada tarefa o
código no sistema é acrescido de pedaços e pode ser enviado para análises e testes de sistemas;
• sustentabilidade: na metodologia extreme programming (XP), as grandes quantidades de horas

extras não são aceitas, pois quando se fica muito tempo sobre um mesmo assunto, a produtividade
cai, o que não vai fazer com que o projeto tenha a qualidade e a produtividade esperadas;
• cliente presente: nessa metodologia, o cliente não é apenas um observador, ele é parte integrante
e importante durante todo o projeto, ou seja, ele está presente full time e em todas as fases,
opinando em todas elas.
4.3.1 Executando teste em extreme programming (XP)
O teste dentro da metodologia extreme programming (XP) funciona de maneira informal, pois não
há especificação de sistemas em seu desenvolvimento, que é todo incremental. Por essa razão, a previsão
do que deve ser testado é escrita antes mesmo dos códigos, pois ela está baseada no atendimento às
necessidades solicitadas. Não que os testes não sejam bem feitos, mas existe sempre uma preocupação
com a qualidade em todos os projetos pelo fato de os testes serem executados de maneira informal. Desse
modo, o extreme programming (XP) elaborou uma abordagem específica para testes com a intenção de
reduzir os possíveis erros: desenvolvimento test-first, desenvolvimento de teste incremental a partir do
cenário, envolvimento dos usuários e frameworks de teste automatizado.
O test-first é uma inovação do extreme programming (XP), pois funciona de forma invertida à
tradicional: em vez de se escreverem o código e, posteriormente, o teste, nesse modelo se escreve o
plano de teste e depois se desenvolve o código, gerando a possibilidade de se testar e codificar o sistema
ao mesmo tempo ou pelo menos quase simultaneamente.
78
No teste utilizando cenários, há uma série de características que fazem parte e precisam ser testadas,
tais como:
• autenticação por usuário no sistema – login;
• realização de download e upload no sistema;
• programação;
• criptografia e descriptografia das informações;
• recuperação dos dados;
• modificação dos dados;
• link para acesso do banco de dados;
• avisos do sistema.
Os desenvolvedores precisam necessariamente entender todo o processo, toda a necessidade do

sistema e suas possíveis ambiguidades. Tudo deve estar de forma clara para que o plano/caso de teste
seja escrito de forma correta e coerente.
Observação
Não se deve dar total importância para o desenvolvimento,

principalmente em decorrência de um cronograma muito justo, e deixar
os testes em segundo plano. Mesmo que sejam realizados de forma
diferenciada, os testes não deixam de ter sua extrema importância no
projeto. Com eles, evitamos muito retrabalho no futuro.
A grande dificuldade encontrada no extreme programming (XP) é o cliente, integrante full time
do projeto e muito provavelmente alguém envolvido em diversas atividades e áreas da organização.
Esse cliente se coloca apenas como um provedor de requisitos, não como o responsável por testes,
desenvolvimento, entrega e outros itens do trabalho. Uma maneira de reduzir esse impacto é discutir
todos esses pontos com o cliente e com seu superior direto no início do projeto.
A automação dos testes ocorre para que sua execução seja mais rápida e deixe mais simples a
maneira de se escreverem os testes. Com a automação, os componentes executam a simulação de uma
entrada de dados no sistema e verificam se o resultado atende ao que consta no plano de testes pré-
elaborado pelos desenvolvedores.
No modelo de teste automatizado, há sempre um conjunto de testes que podem ser executados
rapidamente e com simplicidade.
79
Unidade II
Deve-se ter atenção aos riscos nesse tipo de test-first, pois, como são escritos pelos próprios
desenvolvedores, os testes podem se valer de redução de informações para simplificar o trabalho. Mas
simplificar não significa reduzir a qualidade nem a validade das execuções. A redução pode se dar no caso
de testes reduzidos, ou seja, testes incompletos que não abrangem todas as exceções que poderiam ocorrer.
Pode haver dificuldade também na escrita de testes unitários para uma interface complexa com o
usuário. No caso de um workflow, também poderia haver problemas na geração dos planos de testes de
forma incremental.
Existe ainda a dificuldade de completude dos testes, já que muitos podem ser realizados e existe a
dificuldade em se mensurar se todos os necessários foram executados. Por exemplo, pode acontecer de
alguma parte importante e funcional do sistema não ter sido executada e, por esse motivo, não ter sido
testada, o que irá gerar um ponto falho na realização de testes.
Como são executados constantemente, passa-se a impressão de que todos os testes estão sendo
realizados. A verdade é que essa simultaneidade pode não ocorrer por uma série de motivos. Deve-se
ter atenção à área de testes para que não haja entregas de releases sem que sejam esgotadas todas as
possibilidades.
A seguir, veja o exemplo de um teste para um sistema de abastecimento de água em plantas.
Testes de verificação de abastecimento de água em plantas
Entrada
1. Um número em ml representado em uma cota única.
2. Um número que representa o número de cotas únicas por dia.
Testes
1. Teste para entradas em que a cota única é correta, mas a frequência é muito alta.
2. Teste para entradas em que a única cota é muito alta e muito baixa.
3. Teste para entradas em que a cota única x frequência é muito alta e muita baixa.
4. Teste para entradas em que a única cota x frequência é permitida.
Saída
Mensagem de Ok ou erro indicando que a dose está fora da faixa de qualidade para a
planta.
Figura 28
4.3.2 O desenvolvimento em pares
A utilização dessa forma de trabalho traz vantagens ao projeto, pois dá a ideia de liberdade coletiva
e consultada por diversas fontes de pensamento, já que a equipe tem pessoas com pensamentos
diversificados que podem dar suas opiniões e agregar valor ao projeto.
80
No desenvolvimento em pares, são formadas duplas que se sentam na mesma estação de trabalho
e desenvolvem em conjunto. No entanto, para que esse trabalho se torne dinâmico, é importante a
rotatividade dentre as duplas, ou seja, hoje um desenvolvedor 1 está com o desenvolvedor 3 e amanhã
estará com o desenvolvedor 2 e assim por diante.
Como tudo é feito de forma coletiva, se reduz a valorização do ego de cada programador, que não
poderá pensar que seu código é melhor que o do outro.
Isso se configura como uma forma indireta e informal de revisão paralela do código em pares.
Por serem de muita importância, as revisões de código são demoradas, pois é por meio delas que
um grande número de problemas é encontrado. Mesmo que não seja um processo de validação
formal, essa forma de trabalho reduz os erros porque é feita constantemente e tem a vantagem de
ter um custo menor.
Para pensar na produtividade de um desenvolvimento em pares, um estudo realizado pela

Arisholm et al. (2007) constataram que o que é produzido por um par de desenvolvedores (4 pessoas)
em um dia é a metade do que produziriam dois desenvolvedores individuais (2 pessoas) no mesmo
período. Isso aponta que realmente se gasta um tempo mais elevado, porém, se analisarmos por
outro lado que não o tempo, os dois conseguem ter visões diferentes e, com isso, produzem algo
com mais qualidade e dentro da necessidade do cliente, o que gera redução de retrabalhos e erros
no entendimento da necessidade do cliente. Essa pode ser considerada uma grande vantagem da
utilização do desenvolvimento em pares.
4.4 Gerenciamento
O foco principal de um gerente de projetos dentro da metodologia ágil é garantir que o projeto
seja entregue no prazo e dentro do orçamento estimado. Essa abordagem é muito diferente do
gerenciamento de projetos em outras metodologias, pois no gerenciamento comum há a elaboração
de planos com responsabilidade, entregáveis e a partir de uma visão estática. No modelo ágil, os
gerentes também supervisionam as atividades que estão sendo realizadas conforme o cronograma
estipulado, porém, o fazem de forma que se faça o melhor uso do tempo e dos recursos disponíveis
para a equipe.
4.5 Metodologia scrum
O método scrum é ágil e tem como foco o gerenciamento do desenvolvimento de forma interativa
no lugar das técnicas ditas para a metodologia ágil. Esse método tem foco principal no planejamento
de sistemas.
Dentro da metodologia scrum, há etapas ou ciclos a serem cumpridos para a entrega do produto
final. Ela também é portadora de uma nomenclatura própria que conta com os seguintes termos: sprint,
product backlog, sprint planning, product owner, sprint backlog, daily scrum, sprint retrospective, review
meeting e scrum team. Detalharemos cada um desses tópicos e o funcionamento de todos eles juntos
no processo.
81
Unidade II
Daily Scrum Meeting

24 horas
Product Backlog
Sprint Backlog
Product
Figura 29
4.5.1 Product owner
Product owner é a pessoa da equipe que definirá os itens que comporão o product backlog e sua
prioridade nas reuniões, ou seja, nos scrum sprint planning meetings.
Observação
Esses são termos-padrão utilizados na metodologia scrum. Mesmo que
os nomes desses itens em inglês soem estranhos, não é usual que eles sejam
traduzidos no momento de sua utilização.
Fazendo uma comparação com a metodologia tradicional, podemos dizer que o product owner tem
o papel de gerente, pois é ele que define os papéis e os itens que serão realizados durante o projeto.
4.5.2 Scrum team
O scrum team é formado pelos integrantes da equipe que irá desenvolver o projeto proposto com
base na lista de tarefas apresentada ao sprint.
A equipe tem uma regra a ser cumprida durante seu trabalho: quando recebe um sprint, ela deve
executá-lo até o final, ou seja, novos sprint ou requisitos não devem ser aceitos durante a realização do
sprint inicial. Dessa maneira, a equipe terá foco integral em seu objetivo.
O product owner faz parte integral da equipe e se compromete com ela a não apresentar novos
sprints até que os sprints iniciais estejam concluídos.
Se as mudanças são constantes e bem-vindas na metodologia ágil, na metodologia scrum não é

diferente, com a exceção de que as mudanças não podem interromper a realização de um scrum. Dessa
forma, as mudanças serão realizadas quando for mais propício ao projeto.
82
O scrum time realiza a entrega dos produtos no final de uma interação, sempre visando às
prioridades.
4.5.3 Product backlog
O product backlog é uma lista de funcionalidades levantadas com base na necessidade do cliente. Os
itens dessa lista devem passar por um processo de categorização no qual serão atribuídas prioridades
para cada um deles.
O product backlog não precisa estar completo já no início do projeto, ele pode ser preenchido
conforme este for sendo desenvolvido. Inicialmente, coloca-se nessa lista tudo o que parece pertencer
ao projeto, inclusive os itens óbvios, pois com o conhecimento do negócio e o entendimento melhor da
expectativa e da necessidade do cliente, uma lista mais coerente pode ser montada.
A priorização dos itens do product backlog ocorre durante a reunião (sprint planning meeting) com a
equipe, que é capaz de determinar o que consegue ou não produzir durante uma interação ou um sprint.
Um product backlog pode ser composto de tarefas técnicas ou atividades diretamente relacionadas às
funcionalidades solicitadas pelo cliente.
4.5.4 Sprint planning meeting
O sprint planning meeting é uma reunião realizada com todas as pessoas envolvidas no projeto e/ou
qualquer pessoa da parte do cliente que queira participar dela. Nessa reunião, é obrigatória a presença
do product owner, do scrum master e de todo o scrum team.
Durante o sprint planning meeting, a prioridade das funcionalidades é definida em conjunto e não
pode haver a possibilidade de quebrar as funcionalidades levantadas em tarefas técnicas, pois são essas
tarefas que darão origem ao sprint backlog.
Não é necessário descrever no product owner todos os itens do product backlog. Essa descrição
depende da agilidade da equipe e de seu tamanho, ou seja, pode ser suficiente descrever apenas os itens
de maior prioridade, deixando a discussão dos itens de menor prioridade para a próxima reunião – sprint
planning meeting.
Com o objetivo traçado para o sprint, ele será avaliado no sprint review meeting.
Depois do sprint planning meeting, a equipe do projeto se reúne para discutir sobre tudo o que
foi dito e tomar a decisão sobre seu comprometimento e o que o que irão realizar naquele sprint.
Em alguns casos, poderá haver negociação com o product owner sobre o que será feito, porém
sempre é responsabilidade da equipe determinar o quanto ela será capaz de se comprometer a
fazer.
83
Unidade II
4.5.5 Sprint backlog
O sprint backlog é uma lista de tarefas que a equipe – scrum team – se compromete a fazer em um
sprint.
Os itens do sprint backlog são gerados por meio do product backlog e pela equipe, baseando-se
nas prioridades definidas por esta e pelo product owner e levando em consideração o tempo que será
necessário para completar todas as funcionalidades.
É de responsabilidade da equipe definir a quantidade de itens do product backlog que serão colocados
no sprint backlog, uma vez que ela se comprometerá a implementá-los.
Enquanto ocorre o sprint, o scrum master mantém o sprint backlog atualizado para expor quais
tarefas são completadas e quanto tempo será necessário para completar as demais, como se fosse um
cronograma.
O sprint burndown chart, por sua vez, reflete diariamente o que ainda falta para ser entregue no
sprint.
4.5.6 Sprint review meeting
Após a conclusão de cada sprint, um sprint review meeting deve ser realizado. O sprint review
meeting é uma nova reunião na qual a equipe – scrum team – apresenta o que foi alcançado durante
o sprint.
Como no modelo scrum, o sprint review meeting tem um formato diferenciado de demonstração
das novas funcionalidades. Nessa etapa, é interessante envolver o product owner, o scrum team, o
scrum master, a gerência, os clientes e os engenheiros de outros projetos.
No sprint review meeting, o projeto é avaliado em relação aos objetivos do sprint, determinados
durante o sprint planning meeting. A avaliação se detém sobre a concretização ou não desses objetivos.
Nessa reunião, seria interessante que a equipe tenha completado cada um dos itens do product backlog
trazidos para fazer parte do sprint, ou seja, o importante é que a equipe atinja o objetivo geral do sprint.
4.6 Funcionamento do scrum
O funcionamento do scrum começa com a descrição de todas as funcionalidades a serem

implementadas em um projeto e com a inserção delas em uma lista chamada product backlog.
Como citado anteriormente, o projeto é dividido por fases (sprints) e, no início de cada uma delas,
realiza-se um sprint planning meeting, uma reunião de planejamento na qual o product owner define as
prioridades dos itens do product backlog e a equipe define quais atividades será capaz de implementar
durante o sprint. As tarefas definidas em um sprint são transferidas do product backlog para o sprint
backlog.
84
Dentro de um sprint, a equipe faz uma breve reunião diariamente. É recomendado que essa reunião,
denominada daily scrum, ocorra pela manhã. Seu objetivo é disseminar o conhecimento sobre o que
foi feito no dia anterior, identificar eventuais impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um sprint, a equipe deve apresentar as funcionalidades implementadas em um sprint

review meeting.
Para finalizar o funcionamento do scrum, realiza-se um sprint retrospective e a equipe parte para o
planejamento do próximo sprint.
Estudo de caso
Dando continuidade ao estudo de caso da Pizza One que vimos na primeira unidade, nesta vamos
abordar os itens estudados sobre metodologia e desenvolvimento de sistemas de informação e
metodologia de desenvolvimento ágil de sistemas de informação.
Utilizando da metologia de desenvolvimento de sistemas de informação, temos as fases que veremos

a seguir, conforme o item 3.3 (fases da metodologia de desenvolvimento).
Em estudo preliminar, definimos que a equipe será formada por um analista de negócio, um gerente
do cliente, um analista de requisitos, um analista técnico, um desenvolvedor e um gerente de projeto,
além de contar com todos os usuários do cliente (ou seja, todas as pessoas que estão por trás do site de
pizzas on-line), pois são essas pessoas que podem transmitir alguns pontos importantes para o sistema.
Levantamento dos requisitos
RF1 – a tela inicial do site deve apresentar duas divisões verticais.
Na divisão da esquerda devem aparecer os ícones intitulados Logar, Pizzas,
Bebidas, Visualizar pedido, Pedidos anteriores, Concluir pedido e Opinar.
RF2 – a tela inicial do site deve apresentar duas divisões verticais.
Na divisão da esquerda, devem aparecer os ícones intitulados Logar, Pizzas, Bebidas, Visualizar
pedido, Pedidos anteriores, Concluir pedido e Opinar.
Na divisão da direita deve carregar o modulo escolhido pelo usuário quando selecionar os itens já
descritos anteriormente. Por padrão deve também carregar o módulo Escolha das pizzas, que poderá
ser chamado também por meio do botão Pizzas.
Essa divisão contém ainda um ícone Adicionar pizza escolhida ao pedido, permitindo que o cliente
escolha outros itens após.
85
Unidade II
RF3 – o item Logar deverá permitir que o cliente se autentique no sistema, o que é necessário para
que ele possa concluir seu pedido.
Este módulo solicita ao cliente que informa seu nome_login e sua senha para logá-lo. Caso o
cliente não esteja cadastrado, esse módulo deverá permitir que o cliente solicite a execução do módulo
Autorregistrar, em que poderá se cadastrar.
RF4 – o item Bebidas deverá apresentar uma divisão horizontal em que, na parte superior, deverão
ser apresentados os tipos de bebidas oferecidas (suco, refrigerante e cerveja) e, após a escolha do tipo
desejado, o sistema deverá apresentar na segunda divisão todas as bebidas do tipo escolhido disponíveis,
permitindo ao usuário selecionar e adicionar aos pedidos quantas bebidas desejar.
RF5 – o item Visualizar Pedido deverá apresentar todos os itens escolhidos pelo cliente (pizzas e
bebidas) até o momento, bem como o valor total do pedido, permitindo que o cliente exclua algum item,
se assim o desejar.
RF6 – o item Fechar Pedido deverá permitir que o cliente conclua o pedido.
Neste processo, o cliente dever obrigatoriamente se logar, caso ainda não o tenha feito, podendo
alterar seus dados, se desejar, ou se cadastrar no sistema, caso seja a primeira vez que o cliente realiza
um pedido no site de pizzas. Após essa verificação, o sistema deverá executar o módulo Visualizar
pedido para apresentar os itens escolhidos pelo cliente. Em seguida o módulo deverá apresentar o
endereço de entrega (que pode ser modificado), tempo de preparo (levando em consideração os itens
mais demorados) e o tempo médio de entrega, solicitando a seguir a confirmação. Caso o cliente confirme
o pedido, o sistema marcará como concluído e “dará baixa” no estoque de todos os itens necessários
para a execução do pedido, incluindo os ingredientes necessários para a produção de cada pizza.
RF7 – o item Pedidos anteriores deverá apresentar uma lista de todos os pedidos já solicitados pelo
cliente, permitindo que este solicite novamente um pedido já realizado, podendo realizar modificações
no pedido, se assim desejar.
RF8 – o item Opinar só poderá ser utilizado caso o cliente tenha se autenticado. Essa opção deverá
permitir que o cliente dê sua opinião sobre o atendimento da Pizza One, se referindo tanto à qualidade
dos produtos como da entrega. Dessa forma, é necessário manter informações referentes a qual
funcionário fez a pizza e qual fez a entrega.
Depois de tantas informações levantadas, é hora de elaborar um parecer, um documento contendo

todas essas informações e avaliações da equipe, para ser entregue aos stakeholders, pois somente com
a validação desse documento passaremos para a fase de o que o projeto fará, ou seja, a fase de projeto
lógico.
Já com o projeto aprovado, vamos definir agora o custo do nosso projeto e o prazo para a sua
execução.
86
O prazo para o desenvolvimento é de 8 meses, sendo ele definido da seguinte forma:
• 1 mês para levantamento (ajustes e outros pontos que foram esquecidos, detalhes);
• 1 mês de análise;
• 3 meses de desenvolvimento;
• 1 mês de testes;
• 2 meses de implantação.
Já no projeto físico, vamos definir o que o banco de dados deve conter e o que será necessário para
a implantação desse sistema para que seja entregue perfeito e com qualidade ao cliente final, ou seja,
como o sistema fará o que se propôs a fazer.
Para o banco de dados, foram definidas as seguintes classes:
• Cliente: tem a função de armazenar as informações relativas aos clientes da pizzaria.
• Opinião: armazena as opiniões registradas pelos clientes relativas ao seu nível de satisfação sobre
os pedidos realizados.
• Cargo: armazena informações sobre os cargos dos funcionários da empresa.
• Funcionário: armazena as informações dos funcionários da empresa.
• Pedido: armazena informações relacionadas aos pedidos solicitados pelos clientes.
• Pizza: armazena as informações sobre as pizzas solicitadas em um determinado pedido.
• Sabor: armazena informações sobre os sabores das pizzas existentes.
• Ingrediente: armazena informações referentes aos ingredientes necessários para preparar os

sabores de pizzas oferecidos pela Pizza One.
• Bebida: armazena informações sobre as bebidas existentes na empresa.
• Compra: armazena informações sobre os pedidos de compras feitos pela pizzaria a fornecedores.
• Fornecedores: armazena informações de fornecedores de bebidas e ingredientes para pizza, bem

como outros itens da pizzaria, como embalagens e materiais de limpeza.
87
Unidade II
Observação
Não descrevemos aqui os atributos e métodos das classes, pois isso

ocorre na modelagem de processos.
Para a implantação desse sistema foi levantada a necessidade de um servidor web, dois servidores
de aplicação, um servidor de segurança e um SGBD – servidor de gerenciamento de banco de dados.
Vale ressaltar que cada servidor deve suportar os seguintes itens:
Servidor de web:
Hardware necessário para suportar o software que deverá gerenciar os múltiplos acessos de clientes
da Pizza One.
Servidor de aplicação:
1 – representa o servidor que deve suportar o subsistema de vendas da Pizza One.
2 – representa o servidor que deve suportar o subsistema administrativo da Pizza One.
Servidor de segurança:
Representa uma máquina que irá rodar um sistema de segurança denominado Firewall, que procura
impedir que pessoas não autorizadas acessem indevidamente o sistema da pizzaria.
Servidor de Banco de dados:
Representa o equipamento de hardware que deverá executar um sistema de gerenciador de banco

de dados, que deverá armazenar e recuperar informações necessárias ao sistema.
Resumo
O ciclo de vida de desenvolvimento de sistemas é composto por

uma sequência de fases semelhante à trajetória da vida humana, com a
concepção, o desenvolvimento e a fase final, ou seja, a morte.
Nesta unidade, vimos que, para a existência de um projeto ou de um

sistema, é necessário que haja etapas. Elas vêm de um estudo de caso no
qual analisamos o que pode ser feito na organização para que ela cresça e
tenha aumento produtivo e de competitividade no mercado externo.
88
Na sequência dos acontecimentos, temos a fase de decisão, na qual

escolhemos desenvolver em casa ou contratar uma empresa terceirizada
para realizar o serviço. Independentemente dessa escolha, as próximas
etapas serão iguais: levantamento de dados, nova análise, desenvolvimento
do projeto, implementação, implantação, testes e manutenção.
Podemos chamar a fase de manutenção de pós-venda, pois ela decorre

da necessidade de ajustes após a implantação do sistema. Essa é uma
fase muito importante, uma vez que, para ser bem concluído, um projeto
necessita de melhorias constantes.
No caminho de desenvolvimento de um sistema, vimos a existência

da programação tradicional e também da metodologia ágil, que traz uma
nova roupagem à forma de se trabalhar um sistema de informação.
Descobrimos que a metodologia ágil é proveniente de um manifesto

que visa a uma forma mais simples de trabalho mas não menos eficiente
que outras metodologias. Nela, encontramos o modelo scrum, que tem
como foco o gerenciamento do desenvolvimento de modo interativo e com
destaque para o planejamento de sistemas.
Composta por vários ciclos de vida, a metodologia XP, por sua vez, tem
como meta a existência de um sistema testado ao extremo.
Independentemente da metodologia aplicada, os projetos de

desenvolvimento de sistemas são suscetíveis tanto ao sucesso como ao
fracasso. Tudo depende da forma, da qualidade e do processo a partir
dos quais as informações foram coletadas, analisadas, entendidas e
processadas.
Vale lembrar que o sucesso de todo projeto depende exclusivamente

da forma de trabalho, da dedicação da equipe e de todos os envolvidos, da
qualidade da metodologia escolhida ou desenvolvida e, principalmente, da
total integração e envolvimento da equipe de projeto.
Exercícios
Questão 1. Quando de seu desenvolvimento, acredita-se que todo sistema de informação será
para sempre. Entretanto, todo e qualquer sistema pode sofrer intervenções do mercado, mudanças de
legislação, alterações estruturais da organização, impactos etc. Se o sistema não passar por avaliações e
por uma melhoria contínua, ele terá seu fim decretado rapidamente. Portanto, os sistemas de informação
possuem um ciclo de vida.
89
Unidade II
Sabendo disso, qual das alternativas a seguir se refere à fase de construção dos sistemas de
informação?
A) Momento em que os requisitos funcionais são levantados.
B) Momento no qual se contemplam a análise de sistemas e o desenvolvimento da programação de

códigos de sistemas de informação.
C) Momento após a realização de todos os testes e da documentação do sistema de informação.
D) Momento de disponibilizar ao cliente o sistema que foi desenvolvido.
E) Momento de utilização total do sistema, ou seja, do atendimento completo dos requisitos

funcionais e da sedimentação do sistema.
Resposta correta: alternativa B.
Análise das alternativas
A) Alternativa incorreta.
Justificativa: o levantamento de requisitos é realizado antes do início da construção.
B) Alternativa correta.
Justificativa: é o momento da construção por meio da programação de códigos.
C) Alternativa incorreta.
Justificativa: nesta fase o sistema já foi construído.
D) Alternativa incorreta.
Justificativa: nesta fase o sistema já foi construído e testado.
E) Alternativa incorreta.
Justificativa: nesta fase o sistema já foi construído, testado e disponibilizado.
Questão 2. Parte importante de qualquer projeto é o termo de abertura. Esse documento deve ser
datado e concluído com as assinaturas da alta direção e do patrocinador. Marque a seguir os itens que
devem obrigatoriamente constar no termo.
A) Objetivo, demanda, escopo, stakeholders, configuração, interfaces, prazo, orçamento, equipe,

restrições, premissas.
90
B) Objetivo, demanda, escopo, stakeholders, prazo, orçamento, equipe, restrições, premissas, gerente
do projeto.
C) Objetivo, demanda, escopo, stakeholders, configuração, interfaces, prazo, orçamento, equipe,

restrições, premissas, gerente do projeto.
D) Objetivo, demanda, escopo, stakeholders, interfaces, prazo, orçamento, equipe, restrições,

premissas, gerente do projeto.
E) Objetivo, demanda, stakeholders, interfaces, prazo, orçamento, equipe, restrições, premissas,

gerente do projeto.
Resolução desta questão na plataforma.
91

Unid 2 PDF

Enviado por

Dados do documento

Descrição original:

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

Unid 2 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

MODELAGEM DE SISTEMAS DE INFORMAÇÃO

3.1 Ciclo de vida

Os sistemas de informação são desenvolvidos visando atender às necessidades de uma organização

Figura 22 – Ciclo de vida de um sistema de informação

Cada uma das fases de existência de um sistema de informações abrange:

• concepção ou nascimento: é o momento de estudo preliminar sobre os requisitos levantados. É

• construção: nesse momento, contemplam-se a análise de sistemas e o desenvolvimento ou

• implantação: ocorre após a realização de todos os testes de sistemas e a construção da

A documentação é de extrema importância para o sistema de informação,

• manutenção: ocorre em decorrência de uma exigência legal, correção de erros ou atualizações,

• morte: é quando ocorre a descontinuidade de um sistema de informação.

Quando as primeiras fases do ciclo de vida de um sistema de informação

Já para sistemas de informações gerenciais, a falta de atenção no que

Há diversas formas de se denominar uma metodologia. Podemos chamá-la de método, forma de

Essa metodologia é utilizada como auxílio no desenvolvimento de sistemas de informação, de

No entanto, por que devemos usar o desenvolvimento metodológico de sistemas?

Dentro da organização, a metodologia tem o papel de efetividade, continuidade, perenidade, segurança

• fornece visão do estado do projeto a qualquer instante;

• mantém um histórico documental do sistema;

• cria uma base de dados para fases e subfases futuras.

3.3 Fases da metodologia de desenvolvimento

Em toda metodologia de desenvolvimento devem-se respeitar pontos de avaliação de qualidade e

As fases da metodologia são:

• análise do sistema atual;

Projeto físico Análise do

3.3.1 Estudo preliminar

As subfases do estudo preliminar são:

— determinar os stakeholders ou os envolvidos. Nessa fase, são definidos o patrocinador, o gestor

— receber as diretrizes da alta direção da organização ou do cliente;

— levantar os principais problemas da organização que levaram à solicitação do projeto.

— definir os objetivos do projeto e detalhar com o cliente os requisitos funcionais (entrada,

— identificar impactos e propor soluções mitigadoras, já que a mudança de cultura, filosofia ou

— identificar soluções alternativas para os problemas apresentados, estando sempre alinhado ao

— realizar o levantamento da estimativa de prazo e elaborar o primeiro cronograma para

— analisar a viabilidade do projeto e seus benefícios mensuráveis ou não.

Custo e prazo são pontos fundamentais e de constante discussão em

— realizar uma pré-avaliação da satisfação do cliente e da equipe nos quesitos qualidade e

para guardar, de forma segura, gráficos, diagramas, documentação e informações importantes

— elaborar um termo de compromisso para a aprovação de toda a equipe do projeto e,

3.3.2 Análise do sistema atual

As subfases dessa fase são:

• Rever o estudo preliminar:

— realizar uma nova análise do estudo preliminar entregue e verificar se há a necessidade

— fazer o levantamento do perfil principal dos clientes e dos usuários do sistema;

— realizar um levantamento de toda a documentação dos processos, procedimentos, modelos,

O fator abrangência é de extrema importância, pois o cliente pode

• Levantar pontos críticos:

— no quesito pontos fracos ou desvantagens, é preciso verificar os pontos críticos, os gargalos, as

— utilizar fatores de sucesso para o êxito do processo;

• Desenhar o sistema atual:

— atualizar ou refinar o dicionário de dados levantados com os termos já existentes e com os

• Definir o projeto lógico:

— com a identificação de impacto, podem-se evitar o retrabalho e o aumento de custo e de

• Validar a análise atual:

— apresentar ao patrocinador, ao gestor, à equipe do projeto e aos demais stakeholders (envolvidos)

3.3.3 Projeto lógico

As subfases do projeto lógico são:

• Rever a análise atual:

— analisar os requisitos levantados e distribuí-los em módulos. Nessa etapa, devem-se realizar

— o desenho ou diagrama é a melhor forma de entendimento entre a equipe de levantamento

— o dicionário de dados deve ser complementado e refinado com todas as informações

• Forma de trabalho do projeto físico: