3ª prova pós web 1ª chamada

3ª Prova Pós Web - INGRESSO: 08/08/2014 - A sua prova presencial de Recuperação - ESPECIALIZAÇÃO EM
TECNOLOGIAS PARA APLICAÇÕES WEB ocorrera em:
Dia: 27/06/2015
Horario: 08:30 as 10:00 (Horario de Brasilia)
Disciplinas: PROJETOS ÁGEIS, ANÁLISE DE SISTEMAS, BANCO DE DADOS, DESIGN DE INTERFACES,
INTERAÇÃO HUMANO-COMPUTADOR
TECNOLOGIA EM ANÁLISE DE SISTEMAS
WEB AULA 1
Unidade 1 – INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS
RESUMO:
O objetivo da presente unidade é apresentar os principais fundamentos
sobre gerenciamento de projetos. Nesse sentido,será abordado o ciclo de vida básico
de um projeto, suas principais tarefas e como esse processo contribui para o sucesso
de um projeto. Além disso, de forma resumida, será apresentado como estruturar
um projeto aplicando princípios básicos considerados boas práticas de gestão de
projetos. Ao final, será possível entender e aplicar ferramentas essenciais à gestão
eficiente de projetos desoftware.
DEFINIÇÃO DE PROJETO
Afinal de contas, o que é um projeto? Segundo o PMI (2008), projeto é “[...] um
esforço temporário empreendido para criar um produto, serviço ou resultado
exclusivo”. Ainda segundo o PMI:
 Temporário significa que todos os projetos possuem um início e um final
definidos. Embora não recomendado, muitos projetos ou não definem
claramente uma data de início ou terminam muito além do programado.
 Temporário não significa necessariamente de curta duração; muitos projetos
duram vários anos. Exemplo de projetos longos são as missões espaciais que
podem durar mais de uma década para serem concluídas.
 Temporário não se aplica ao resultado do projeto, que poderá perdurar por
muitos anos após a conclusão do projeto. As pirâmides do Egito são um
exemplo claro do resultado duradouro de um projeto.

O resultado de um projeto é exclusivo, único.
Saiba mais sobre os principais conceitos em gestão de
projetos:http://www.gestaodeprojeto.info/introducao
Mas o que pode ser administrado como um projeto?
Projetos surgem, por exemplo, de problemas ou oportunidades pessoais ou
organizacionais.Logo, projetos lidam com situações não muito comuns. Por exemplo,
uma empresa de software deseja implantar um novo procedimento de teste
de software. Nesse sentido, projetos envolvem muitas incertezas e geralmente geram
mudanças ao acrescentarem algo novo.
Então, projetos não lidam com situações do dia a dia, ou seja, projetos não
administram rotina. Rotinas geralmente não envolvem incertezas e o resultado é
previsível.

Muitas palavras novas? Baixe um pequeno dicionário de “Projetês” no
endereço:http://www.gestaodeprojeto.info/arquivos/PMBOK_Port_glossario.zip?attr
edirects=0
Entretanto, gerenciar por meio de projetos não se aplica somente no ambiente
organizacional, você pode administrar determinados objetivos pessoais por meio de
projetos. Por exemplo, o curso de especialização que você está fazendo poderia ser
administrado por meio de um projeto. Note que o curso é algo novo em sua vida, irá
acrescentar algo à sua vida profissional, deverá ser realizado num determinado
prazo, envolverá custos, riscos, ou seja, exigirá um planejamento que possibilite que
você atinja seu objetivo: ser um especialista em Desenvolvimento de Aplicações Web
Baseadas na Tecnologia JAVA.
Vídeo: o que é um projeto:
O quadro 1 apresenta algumas diferenças entre rotina e projeto.
Saiba mais:
Maximiano (2010, p. 4-13) apresenta uma visão geral sobre projetos.
CICLO DE VIDA DO PROJETO

Como os projetos são organizados? Projetos podem ser divididos em fases que
possibilitam melhor controle gerencial. O ciclo de vida do projeto define as fases que
conectam o início de um projeto ao seu final.
Segundo o PMI (2008), um ciclo de vida (vide figura 1) é um processo que determina
um conjunto de ações e atividades inter-relacionadas realizadas para obter um
conjunto pré-especificado de produtos, resultados ou serviços.
Cada uma das fases define um grupo de processos que são aplicados iterativamente
(de forma incremental) e repetitivamente. Segundo Trentim (2011), o grupo de
processo de Inicialização é responsável pela definição e autorização de um novo
projeto; o grupo de processos de Planejamento define o que será feito e como será
realizado; o grupo de processos de Execução coloca em prática o planejamento; o
grupo de processo de Monitoramento e Controle verifica se a execução está em
conformidade com o planejado e o grupo de processo de Encerramento é responsável
pela finalização do projeto.

Como pode ser percebido, o ciclo de vida do projeto ajuda a organizar todos os
processos necessários à realização do projeto. Ele estabelece uma sequência, agrupa
processos comuns, dá uma visão geral sobre todo o percurso que deverá ser realizado
entre o início e o término do projeto entre outras vantagens.
Então, o ciclo de vida de um projeto é um fatorimportante para o sucesso do projeto.
O ciclo de vida do projeto é similar a um mapa: um mapa indica o início, o destino,
a rota que conduz ao destino, os locais pelos quais deveremos passar, dá uma noção
do progresso, ou seja, onde estou no trajeto?
Ao pensar sobre o ciclo de vida de um determinado projeto, considere algumas
questões que deverão ser respondidas:
» Que trabalho técnico deve ser realizado em cada fase. Por exemplo, em qual fase
deve ser realizado o trabalho do Analista de Sistema, Programador, Administrador
do Banco de Dados (DBA), etc.
» Quando as entregas devem ser geradas em cada fase e como cada entrega é
revisada, verificada e validada. Por exemplo, quando o diagrama Entidade
Relacionamento (DER) deverá ser entregue? Quem irá revisá-lo? Quando será
revisado?

» Quem está envolvido em cada fase. Por exemplo, na fase de planejamento do
projeto deverá ser coletado os requisitos do software, então, quais são os
interessados (stakeholders)?
» Como controlar e aprovar cada fase. Por exemplo, quando sei que a atividade
Engenharia de Requisitos foi concluída, como saberei se a atividade está dentro do
prazo? Como saberei se realmente a atividade foi concluída? Quais critérios indicam
que a atividade foi concluída dentro das expectativas?
Saiba mais:
Ciclo de vida do projeto de software:
http://www.oficinadanet.com.br/artigo/1912/o_ciclo_de_vida_de_um_projeto_de_i
nformatica
Vídeo: ciclo de vida do projeto:
Normalmente um projeto envolve diretamente e indiretamente vários interessados
(stakeholders[1]) e saber quem está envolvido no projeto é um fatorimportantíssimo
para o sucesso do projeto. Por exemplo: imagine que você irá construir uma casa
nova para sua família. Esse projeto irá envolver diversas pessoas, principalmente sua
família. Então, imagine que você deixou de ouvir sua família sobre quais
características a casa deveria ter. O que você acha que aconteceria quando sua
família se mudasse para a nova casa? Será que eles a aprovariam? Bom, talvez sim,
ou talvez a desaprovassem por completo, ou talvez dissessem “acho que poderia ser
assim”, etc., etc.
Partes interessadas no projeto podem ser pessoas ou organizações ativamente
envolvidas no projeto ou cujos interesses podem ser afetados com o resultado da
execução ou do término do projeto. Eles podem também exercer influência (positiva
ou negativa) sobre os objetivos e resultados do projeto.
[1] Stakeholders é um termo em inglês muito utilizado na literatura. Nesse material, stakeholder será
empregado comointeressado.

Exemplo de interessados:
Clientes que comprarão e/ou usarão o produto resultante do projeto, órgãos ou
agências regulamentadoras que podem interferir no projeto, pessoas ou organizações
que disponibilizarão recursos ao projeto, pessoas ou organizações afetadas pelo
projeto, parceiros ou terceiros que participarão do projeto, equipe de Projeto,
fornecedores de produtos ou serviços ao projeto, competidores/concorrentes, etc.
Trentim (2011) apresenta um exemplo resumido no formato de uma tabela (vide
figura 2) de informações que poderiam ser registradas sobre as partes interessadas
no projeto. A tabela destaca, por exemplo, o interesse de cada parte interessada, a
influência dessa parte interessada no projeto e o impacto que essa parte poderia
provocar no projeto.

Quer saber mais sobre as partes interessadas? Acesse o endereço:
http://www.gestaodeprojeto.info/analise-dos-stakeholders
Gerente de Projeto
O gerente de projeto (ou GP) desempenha um papel fundamental no projeto, ele é o
responsável global por todo trabalho realizado no projeto. Além disso, o gerente atua
como um meio, uma interface, entre o projeto e os interessados nele. O GP é um
cargo temporário, ou seja, ele existe enquanto o projeto existir. Normalmente o
gerente é definido logo nas etapas iniciais do projeto.
Dentre tantas responsabilidades, o GP supervisiona o planejamento,
desenvolvimento e operação do projeto. Cleland; Ireland (2007) listam outras
responsabilidades atribuídas aos gerentes de projeto:
» redistribuem recursos conforme a necessidade do projeto;
» monitoram a competência da equipe do projeto;
» gerenciam mudanças;
» monitoram o prazo, custo, risco, qualidade, etc. do projeto;
» relatam o andamento do projeto aos interessados;

» motivam a equipe.
Saiba mais:
Ouça o PODCAST de Ricardo Vargas sobre as responsabilidade do
GP: http://www.ricardo-vargas.com/pt/podcasts/projectmanagerresponsibilities/
Vídeo: Perfil profissional do GP:
OS DESAFIOS DO PROJETO
Gerenciar projetos implica numa “batalha” diária entre algumas restrições: tempo,
custo, qualidade, escopo e satisfação do cliente. Note que essas variáveis reagem
quando se modifica uma delas.
Por exemplo, o que aconteceria se você percebesse que o projeto está atrasado e
que precisa recuperar o tempo para entregar no prazo? Bom, você poderia apontar
algumas alternativas, por exemplo: contratar mais pessoas ou trabalhar um pouco
mais (hora extra). Acredito que você tenha percebido que essas duas medidas podem

provocar um impacto na outra variável: o custo. Logo, para recuperar o tempo terei
que aumentar o custo.
Vamos assistir a vídeo aula 1
Outra alternativa para realizar o projeto dentro do tempo estimado sem aumentar o
custo seria deixar de realizar algumas tarefas. Entretanto, isso poderia impactar na
qualidade do projeto. Então, caberá ao gerente de projeto a árdua habilidade de
equilibrar essas variáveis, de decidir se aumentará o custo ou diminuirá a qualidade.
Ou melhor, qual o ponto de equilíbrio entre entre custo, tempo, qualidade e escopo
que resulte na satisfação do cliente.
PMI e PMBOK
Como você percebeu, gerenciar projetos envolve muito conhecimento, apresenta
muitos desafios e envolve muitos riscos. Logo, você poderia se perguntar, diante de
tanta complexidade, serei eu capaz de administrar um projeto? Realmente, é muito
difícil e quase sempre, diante de uma nova área, nos sentimos incapazes.
Entretanto, em 1969, na Pensilvânia (EUA), cinco voluntários também se depararam
com as mesmas questões.Então, eles decidiram fundar o PMI – Project Management
Institute (ou, em português, Instituto de Gerenciamento de Projetos). O PMI é uma
organização sem fins lucrativos e atualmente está presente em mais de 185 países
com mais de 650.000 membros associados.

O PMI está organizado em capítulos que são estabelecidos nos mais diferentes países.
São mais de 250 capítulos estabelecidos em todo mundo. No Brasil já foram
estabelecidos 13 capítulos. Segundo o PMI, essas comunidades, abertas a membros
do PMI e dirigidas por voluntários, dão suporte para a troca de conhecimento e para
redes de trabalho, pontos centrais da missão do PMI.
Saiba mais sobre o PMI:
Acesse o endereço: http://brasil.pmi.org
Entre os principais objetivos do PMI encontra-se o desenvolvimento de
conhecimentos para gerenciamento de projetos e, certamente, uma das principais
contribuições do PMI é o guia PMBOK – Project Management Body of Knowledge (ou,
em português, Guia para o Corpo de Conhecimento em Gerenciamento de Projetos).
PODCAST: PMBOK quarta edição:
http://www.ricardo-vargas.com/pt/podcasts/newpmbok/
Segundo o PMI (2008), o Guia PMBOK identifica um conjunto de conhecimento em
gerenciamento de projetos amplamente reconhecido como uma boa prática. O PMI
ainda enfatiza que “boa prática” significa que existe um consenso geral de que a
aplicação correta dessas habilidades, ferramentas e técnicas pode aumentar as
chances de sucesso em uma ampla gama de projetos.

Logo, o Guia PMBOK é uma fonte indispensável de conhecimento para quem pretende
gerenciar um projeto. Os conteúdos do Guia PMBOK estão separados por área de
conhecimento para as quais são definidos e explicados os processos necessários à
sua aplicação. Deve-se deixar claro, entretanto, que cabe ao usuário do Guia definir
como o conhecimento será aplicado, então, o Guia apenas sugere boas práticas e,
portanto, cabe ao usuário avaliar sua pertinência em relação ao projeto ao qual se
pretende aplicar as boas práticas propostas pelo Guia.
O Guia é constantemente atualizado e encontra-se atualmente em sua 4ª edição,
distribuída em 2008. Nessa edição, o conteúdo do Guia apresenta 42 processos. Os
42 processos podem ser divididos de duas formas (vide figura 3): agrupados por
áreas de conhecimento ou agrupados por grupos de processos.

Fonte:
http://www.pmtech.com.br/artigos/Processos_PMBOK_4a_Mauro_Sotille.pdf.
Na figura 3, do lado direito, pode-se observar uma legenda. Nessa legenda são
apresentadas as 9 áreas de conhecimento com sua respectiva cor e ícone:
Integração, Escopo, Tempo, Custos, Qualidade, RH (Recursos Humanos),
Comunicação, Riscos e Aquisição. Pode-se perceber ainda na figura 3 que os
processos (retângulos numerados) possuem uma cor e um ícone (Figura 4).
Considerando esses dados e tomando como exemplo o processo “4.1 Desenvolver o
termo de abertura do projeto” localizado no topo do lado esquerdo da figura,
podemos classificar esse processo na área de conhecimento Integração. Então, todo
retângulo na cor “amarelo claro” e que apresenta o ícone “estrela” é classificado como

um processo de Integração. Você perceberá que existem 6 processos de integração
espalhados pela figura.
Também perceberá que os processos espalhados pela figura, na verdade, estão
contidos dentro de uma divisão. Cada uma das divisões é um grupo de processos.
Tomando ainda como exemplo o processo 4.1 “Desenvolver o termo de abertura do
projeto”, você perceberá que ele está numa divisão intitulada “Processos de
Iniciação”. Você notará ainda que apenas dois processos são classificados como
processo de Iniciação.
Vídeo: Grupos de processos PMBOK:
Esses dois modos de visualizaros processos de gerenciamento sugeridos pelo PMBOK
estão relacionados e são úteis da seguinte forma, por exemplo: Se você estiver na
fase de Planejamento de um projeto, quais processos você poderia empregar para
planejar seu projeto? Considerando a figura 3, você perceberá que o PMBOK sugere
20 processos que podem ser realizados no planejamento de um projeto.
Quer saber mais sobre o PMI e PMBOK? Acesse o
endereço:http://www.linhadecodigo.com.br/artigo/974/iniciacao-ao-pmbok-no-
gerenciamento-de-projetos.aspx
Por outro lado, se você estiver avaliando os possíveis riscos de seu projeto, quais
processos poderiam ser realizados? Nesse caso você irá localizarna figura 3 todos os

seis processos que possuem o ícone “raio” (eles estão distribuídos em dois grupos de
processos: “Planejamento” e “Monitoramento e Controle”). Esses processos são
processos relacionados ao gerenciamento de riscos de um projeto.
O Guia PMBOK é um tema relativamente extenso. O propósito aqui foi propiciar uma
visão ampla sobre seu conteúdo e organização. Conhecer as boas práticas
apresentadas pelo Guia certamente é uma leitura recomendada para todos aqueles
que querem aprofundar seus conhecimentos em gerenciamento de projetos.
O Guia PMBOK é uma leitura obrigatória para quem tem interesse em gestão de
projetos.
Você pode obter mais informações sobre a aquisição do Guia PMBOK no
endereço:http://brasil.pmi.org/brazil/PMBOKGuideAndStandards.aspx
GRUPOS DE PROCESSO
Como apresentado anteriormente, os 42 processos do PMBOK estão agrupados em
5 grupos: Iniciação, Planejamento, Monitoramento e Controle, Execução e
Finalização. A intenção em agrupar os 42 processos é organizá-los e permitir que se
tenha uma visão do progresso do andamento do projeto.

Segundo o PMI (2008), cada grupo de processo possui, de modo geral, as seguintes
responsabilidades.
Grupo de Processos de inicialização: Os processos desse grupo têm por
objetivo definir, iniciar um novo projeto ou nova etapa do projeto. Uma vez o
projeto seja autorizado a iniciar, nessa etapa é definido o gerente do projeto,
identificadas as partes interessadas e alocado os recursos entre outros processos.
Grupo de processos de planejamento: Define o escopo do projeto, ou seja, o
que será responsabilidade do projeto, refina os objetivos e estabelece as ações que
conduzirão ao objetivo geral do projeto.
Grupo de processos de execução: é formado pelos processos responsáveis
pela execução do trabalho definido no planejamento.
Grupo de processos de monitoramento e controle: nesse grupo estão os
processos responsáveis pelo monitoramento do projeto, ou seja, averigua se tudo
está ocorrendo como previsto, realizado como planejado e, caso contrário, toma
medidas para contornar da melhor forma possível eventuais problemas.
Grupo de processos de encerramento: Agrupa os processos encarregados de
finalizar todos os procedimentos, documentar as lições aprendidas, registrar todas
as informações entre outros.
Definir os processos de um projeto é como um jogo de xadrez, cada projeto
(partida) exige uma estratégia diferente.
CERTIFICAÇÕES DO PMI
Para os interessados em gerenciamento de projetos, o PMI oferece seis certificações
profissionais que tem por objetivo demonstrar que o profissional possui

conhecimento, experiência e competências em determinadas áreas do gerenciamento
de projetos.
As certificações emitidas pelo PMI são reconhecidas mundialmente e os profissionais
que as possui são muito valorizados no mercado. Atualmente o PMI oferece seis
certificações.
 Certificação PMP – Profissional de Gerenciamento de Projetos (PMP).
 Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos.
 Certificação PgMP – Profissional de Gerenciamento de Programas.
 Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI.
 Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI.
 Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI.
PODCAST: Ouça o podcast sobre a certificação CAPM:
http://www.ricardo-vargas.com/pt/podcasts/capm-certification-part-1-of-2/
Para obter uma certificação do PMI, você deve primeiramente atender aos requisitos
de elegibilidade delineados no portal do PMI e detalhados nos manuais de

certificações. A seguir, você deve fazer três avaliações – a revisão da inscrição, o
exame da certificação e a avaliação múltipla.
Quer saber mais sobre as certificações do PMI? Acesse o
endereço:http://brasil.pmi.org/brazil/FAQ/CertificationFAQ.aspx
PROJETOS DE SUCESSO
Segundo o PMI (2008), o ciclo de vida do projeto apresenta algumas características
comuns entre diferentes projetos (Figura 6). Essas informações são valiosas
principalmente para quem está iniciando em gestão de projetos.
Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante
as fases intermediárias e caem rapidamente conforme o projeto é finalizado.
Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as
incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem
ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as
características finais do produto do projeto, sem impacto significativo sobre os
custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final
do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos
das mudanças e correções de erros geralmente aumentam significativamente
conforme o projeto se aproxima do término.
Os níveis de custos e de pessoal são baixos no início, atingem o valor máximo durante
as fases intermediárias e caem rapidamente conforme o projeto é finalizado.

Para saber mais sobre a importância do planejamento, leia o artigo disponível em
Ainda segundo o PMI (2008), a influência das partes interessadas, os riscos e as
incertezas são maiores durante o início do projeto (vide Figura 7). Esses fatores caem
ao longo da vida dele. O PMI ainda afirma que, a capacidade de influenciar as
características finais do produto do projeto, sem impacto significativo sobre os
custos, é mais alta no início. Por outro lado, mudanças no projeto já no curso final
do projeto podem provocar sérios impactos negativos ao projeto. Ou seja, os custos
das mudanças e correções de erros geralmente aumentam significativamente
conforme o projeto se aproxima do término.
Segundo o PMI (2008), para que um projeto seja bem sucedido, a equipe deve:
» Selecionar processos adequados;
» Usar uma abordagem apropriada;
» Cumprir os requisitos dos interessados;
» Equilibrar as demandas (escopo, tempo, custo, qualidade e satisfação do cliente).
Vídeo: Obtendo resultados com Gerenciamento de Projetos:
.
RESUMO
Nessa unidade foi apresentado a definição de projeto, seus benefícios e aplicações e
diferenças em relação às rotinas. Assim como outras áreas, os projetos possuem um
ciclo de vida comum, genérico, composto pelas etapas: iniciação, planejamento,
execução, acompanhamento e controle e finalização. Também foi enfatizado que é
fundamental identificar todas as partes interessadas no projeto, bem como as
principais atribuições do responsável direto pelo projeto: o gerente de projeto. Além
disso, foi apresentado a norma internacional PMBOK, mantida pelo PMI, a qual
apresenta boas práticas em gestão de projetos. Também foi descrito como os
profissionais podem obter maior aceitação no mercado por meio de certificações
profissionais. Finalmente, foram destacadas algumas características gerais sobre
projetos e fatores de sucesso.
Primeiros passos, acesse o endereço: http://www.gestaodeprojeto.info/7passos

CLELAND, David, I.; IRELAND, Lewis R. Gerenciamento de projetos. Rio de
Janeiro: LTC, 2007.
MAXIMIANO, Antonio Cesar Amaru. Administração de projetos: como
transformar ideias em resultados. 4. ed. São Paulo: Atlas, 2010.
MOURA, Dácio Guimarães de; BARBOSA, Eduardo F. Trabalhando com
projetos: planejamento e gestão de projetos educacionais. 2. ed. Petrópolis: Vozes,
2007.
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em
gerenciamento de projetos, 4. ed. Newton Square, PA: PMI, 2008.
TRENTIM, Mário Henrique. Gerenciamento de projetos: guia para certificações
CAPM e PMP. São Paulo: Atlas, 2011.
TECNOLOGIA EM ANÁLISE DE SISTEMAS
WEB AULA 1
Unidade 2 – PLANEJANDO UM PROJETO
RESUMO:
O objetivo da presente unidade é apresentar os passos básicos
sobre o planejamento de um projeto e uma visão geral sobre métodos ágeis. Nesse
sentido, será discutido o objetivo do projeto e seu papel no planejamento do
projeto. Você também irá conhecer como definir as responsabilidades de um
projeto por meio da definição do escopo. Além disso, aprenderá como dividir todo o
trabalho necessário para realizar um projeto por meio da Estrutura Analítica do
Projeto (EAP). Também entenderá porque a EAP é um dos instrumentos
fundamentais para planejar um projeto: tempo, responsabilidades, estimativas de
custo, tarefas, etc. Finalmente, será apresentada uma visão geral sobre os métodos
ágeis e, em particular, uma visão um pouco mais aprofundada sobre a abordagem
ágil SCRUM.
INICIANDO UM PROJETO: O OBJETIVO

“Nenhum caminho adiantará se você não sabe aonde ir.”
Definir o objetivo do projeto certamente é um dos principais passos para um projeto.
Os objetivos são descrições concretas do que o projeto está tentando alcançar. Iniciar
um projeto sem tê-lo definido claramente é praticamente sentenciar o projeto ao
fracasso.
Os objetivos do projeto (geral e específico) devem incluir os critérios mensuráveis do
sucesso do projeto: técnicos, de negócios, custo, cronograma e qualidade. Isto é,
deve ser descrito de tal forma que seja possível verificar ao final do projeto se eles
foram ou não atingidos. Nesse sentido, os objetivos do projeto podem incluir metas
de custo, cronograma e qualidade. Ou seja, Um objetivo bem escrito será específico,
mensurável, alcançável/realizável, realístico e com uma clara indicação do tempo.
Um contraexemplo de escrita de um objetivo: “Melhorar a qualidade no
atendimento ao cliente por meio da implantação de um call center”. Nesse
contraexemplo não está claro como o objetivo poderá ser verificado, pois não faz
referência a custo, tempo, datas ou critérios de qualidade. Deste modo, não seria
possível verificar se o projeto atendeu aos critérios.

Agora, leia a escrita de um objetivo que contém elementos que podem ser
verificados: “O projeto objetiva entregar no prazo de 180 dias a contar a partir
da data de 01/10/2008, com custo de investimento de R$ 5 milhões dentro
do padrão internacional NPCS 3001 atualmente praticados pela
corporação um serviço de call center para suportar o atendimento à clientes
da rede de Lojas Fictícia”.
Note que na descrição do objetivo constam a entrega do projeto (sublinhado
contínuo) e elementos mensuráveis (sublinhado pontilhado), ou seja, possíveis de
serem verificados: valores, prazo, data e norma de qualidade. Portanto, um objetivo
atua como um farol para um navio, um ponto de referência para onde se quer chegar.
Logo, o objetivo deve ser escrito de tal forma que fique claro o resultado pretendido.
Ouça o PODCAST sobre objetivo de um projeto:
http://www.ricardo-vargas.com/pt/podcasts/smart_objective/
O objetivo do projeto pode ser subdividido em objetivos menores. Por exemplo,
imagine que você pretenda viajar para um determinado destino, você mora em São
Paulo e pretende ir para Osasco – SP (Figura 1). Por se tratar de um trajeto curto,
aproximadamente 23 Km, normalmente, você não se preocuparia muito, pois se trata
de um trajeto relativamente simples.

Agora, imagine que você pretende ir de São Paulo para Dourados no Mato Grosso do
Sul (Figura 2). Bom, agora você vai pensar, é uma rota relativamente extensa,
aproximadamente 1000 Km e, para complicar, você não conhece muito bem o
trajeto. Então, o que você faria? Provavelmente, você estabeleceria a rota, ou seja,
pontos intermediários até o ponto final: São Paulo a Ourinhos, Ourinhos a Presidente
Prudente, Presidente Prudente a Presidente Epitácio, Presidente Epitácio a Glória de
Dourados e, finalmente, Glória de Dourados a Dourados. Bom, por que você varia
dessa maneira? Porque seria mais seguro você alcançar seu destino final por meio
do alcance de destinos mais curtos. A soma dos objetivos mais curtos é igual à soma
de todo o trajeto até o destino final. Essa estratégia diminui a complexidade ao lidar
com problemas menores, você resolve um problema de cada vez e, ao resolver todos
os problemas menores, você teoricamente resolveria todo o problema.
Então, considerando o exemplo acima, o destino final é nosso objetivo geral, e os
destinos intermediários são nossos objetivos intermediários.
ESCOPO
Após definiro objetivo ou objetivos do projeto, devemos reunir todos os interessados
no projeto e tratar do escopo do projeto. Mas, o que é escopo? Segundo Maximiano

(2010), escopo do projeto é o produto ou conjunto de produtos que o projeto deve
entregar – a um cliente, patrocinador ou usuário.
Uma analogia: imagine que o escopo do projeto é como um quebra-cabeça de
montagem de peças. Somente estará completo e terá significado se todas as peças
estiverem no seu devido lugar. Agora, considere um exemplo real: é comum
empresas de software desenvolverem para um cliente um produto de software, mas
será apenas o software a única entrega do projeto? Acredito que na maioria dos casos
não. Por exemplo, não basta apenas entregar o software, em muitos casos é
necessário instalá-lo no ambiente do cliente, logo, a implantação/instalação
do software também é uma entrega do projeto. Outras possíveis entregas seriam:
treinamento dos usuários, entrega do manual do sistema, entrega do instalador,
migração de dados do sistema antigo para o novo sistema (quando se tratar de uma
atualização), etc.
Percebe-se, portanto, que a definição do escopo, ou seja, das entregas (em inglês,
no singular,delivery) é uma parte fundamental do processo de gerenciamento de
projetos. A definição incorreta do escopo pode provocar o fracasso de um projeto.
Pensar no escopo é definir realmente o deve ser entregue. Muitos projetos definem
entregas desnecessárias que não contribuem para o objetivo do projeto.
É comum na descrição do escopo do projeto, para torná-lo mais claro ainda, não só
a descrição das entregas, mas também a descrição do que NÃO será entregue, ou
seja, àquelas entregas que não farão parte do escopo. Por exemplo: não faz parte
do escopo do projeto:
» Fornecer licenças de qualquer tipo de software necessário ao funcionamento
do software objeto do projeto.
» Projetar, instalar e configurar qualquer tipo de infraestrutura de redes de
computadores.

» Fornecedor qualquer tipo de hardware necessário ao funcionamento
» Realizar qualquer tipo de treinamento, exceto o treinamento de uso
Saiba mais.
Veja um exemplo de declaração do escopo do projeto:
https://docs.google.com/viewer?a=v&pid=sites&srcid=Zmd2Z3AxMC5tYXVyaWNpb3ZpZWl
yYS5uZXR8bG9naXN0aWNhLXNhbHZhZG9yLTIwMTR8Z3g6NTU2NzE0MzU2NmY0NTU
ESTRUTURA ANALÍTICA DO PROJETO (EAP)
Relembrando a analogia do mapa, o projeto possui um objetivo geral que pode ser
subdividido em objetivos menores. Essa estratégia permite diminuir a complexidade
do projeto pois, geralmente, partes menores são mais fáceis de administrar. E, após
concluir cada uma das partes, a soma delas formaria o todo, ou seja, o projeto.
Segundo Trentim (2011, p. 99), EAP é o “Processo de subdivisão das entregas e do
trabalho do projeto em componentes menores de modo a facilitar as estimativas e o
gerenciamento do trabalho”.
A EAP permite decompor todo o trabalho do projeto em partes menores que serão
mais fáceis de estimar e gerenciar.
A EAP – Estrutura Analítica do Projeto (ou, em inglês, WBS – Work Breakdown
Structure) é uma abordagem que permite decompor todo o trabalho do projeto em
partes menores, mais fáceis de gerenciar. Existe diversas representações para a EAP,
mas a mais comum é na forma de uma árvore invertida (Figura 3).

Nessa representação, como pode ser observado na Figura 3, o primeiro nível pode
representar o produto final, ou serviço, ou ainda todo o trabalho do projeto. O
segundo nível representa a primeira decomposição do primeiro nível, ou seja, “Pintar
uma sala” foi dividida em: Preparação de materiais, preparação da sala, pintura da
sala e limpeza da sala. O terceiro nível representa a divisão de cada elemento do
segundo nível. Por exemplo, a “Preparação de materiais” ainda foi dividida em:
comprar tintas, comprar escada, comprar rolos e comprar removedor de papel de
parede.
Quer saber mais sobre a EAP? Leia o material disponível em:
http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto
A EAP pode ter vários níveis. Sua profundidade dependerá do nível de detalhamento
necessário que se deseja dar ao projeto. Alguns níveis podem ser mais detalhados
que outros, por exemplo, considerando a Figura 4, a qual apresenta uma outra forma

de representar uma EAP, “Pesquisa” e “Escrita” foram subdivididas para o terceiro
nível. Entretanto, a “Apresentação” não foi dividida.
A cada nível da EAP pode ser atribuído um número. Os números também obedecem
a hierarquia dos níveis (Figura 5). Como ainda pode ser percebido na Figura 5, uma
EAP também pode ser representada no formato textual. Você já percebeu, portanto,
que a divisão dos trabalhos acadêmicos normalmente empregam a abordagem da
EAP.
A EAP de um projeto pode ser representada em diversos formatos: gráfico, textual,
tabular, hierarquia, etc.
Regra dos 100%
A regra dos 100% é um princípio aplicado à EAP a qual define que a soma de cada
elemento imediatamente abaixo de um nível decomposto é igual a 100% do elemento
imediatamente acima. Segundo o PMI (2008), a aplicação desta regra vale para todos
os níveis na hierarquia: a soma de todo o trabalho dos níveis "filhos" deve ser igual
a 100% do trabalho representado pelo "pai" e a EAP não deve incluir qualquer
trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do
que 100% do trabalho...”.

Vídeo sobre EAP
http://www.ricardo-vargas.com/pt/videos/140/
Para ilustrar, considerando a Figura 7 (parte do exemplo apresentado na Figura 6),
você deve ter notado que o nível 1, “Trabalho da disciplina” representa o projeto
inteiro. Entretanto, todo esse projeto foi divididoem três partes. Cada uma das partes
representa uma porção do projeto inteiro, logo, a soma dessas partes deve ser igual
a todo o trabalho do projeto. Também deve ter notado que as partes possuem
quantidade de trabalho diferentes, ou seja, as partes não precisam ter a mesma
quantidade de trabalho, entretanto, a soma de trabalho dessas partes deve totalizar
100% do trabalho total.
Você também deve ter notado na Figura 6 que a regra dos 100% pode ser aplicada
para todos os níveis da EAP. Por exemplo, considerando a Figura 8, todo trabalho do
item “Pesquisa” foi dividido ainda em duas tarefas: “Resumo Livros” e “Resumo
Artigos”. Note que o trabalho “Pesquisa” representa 40% de todo o trabalho do
projeto. Entretanto, todo esse trabalho, ou seja, 100% do trabalho “pesquisa” foi
dividido em duas tarefas e cada uma delas representará 50% de todo o trabalho
“Pesquisa”. Nesse caso, o trabalho foi dividido em duas tarefas com a mesma
quantidade de trabalho. Esse raciocínio pode ser aplicado os demais níveis da EAP e
é o gerente de projeto junto ao interessado que deve definir o nível de detalhamento
da EAP, bem como as estimativas de trabalho de cada nível.

Até quando decompor a EAP?
Segundo o PMI (2008), os responsáveis pelo escopo devem “subdividir as entregas
do projeto em componentes menores e mais GERENCIÁVEIS, até que as entregas do
trabalho estejam definidas no nível de PACOTES DE TRABALHO” (PMBOK, 2004).
Saiba mais.
Ouça o PODCAST sobre EAP e uma técnica de decomposição:
http://www.ricardo-vargas.com/pt/podcasts/wbs/
E, o que é pacote de trabalho?
Segundo Maximiano (2010), pacote de trabalho é o “conjunto delimitado de
atividades do projeto […] atribuídas a uma pessoa ou unidade funcional”. Em outras
palavras, o pacote de trabalho é o último nível da EAP, a folha, e é sobre o pacote de
trabalho que se deve embasar o planejamento e estimativas do projeto.

Um nível, ao ser dividido, deve gerar pelo menos dois outros subníveis, ou seja, um
nível não pode ser subdividido em apenas mais um nível (veja contraexemplo na
Figura 9 – Nível 4). Mas a principal do pacote de trabalho é facilitar o planejamento.
Para cada pacote de trabalho pode ser definido, por exemplo: objetivo, tarefa(s),
entrega(s), recurso(s), orçamento, duração e critérios de aceitação.
O pacote de trabalho é a unidade que permite estimar com mais precisão diversos
indicadores do projeto, como: tempo, custo, recursos, etc.
Quer saber mais? Ouça um PODCAST sobre como definir o tamanho de um pacote
de trabalho:
http://www.ricardo-vargas.com/pt/podcasts/when-much-sometimes-is-too-much/

Tomando como exemplo a Figura 11, que apresenta a EAP para uma coleta de dados,
teríamos seis pacotes de trabalho. Para cada um deles poderíamos definir: objetivo,
tarefa(s), entrega(s), recurso(s), entregas, orçamento, duração, critérios de
aceitação.
A Figura 12 ilustra o planejamento do pacote de trabalho “Roteiro” da EAP
apresentada na Figura 11. A EAP apresentada na Figura 11 associada ao
detalhamento do pacote de trabalho apresentado na Figura 12 pode ser utilizado
como referência para a elaboração do cronograma do projeto. O cronograma do
projeto é uma ferramenta indispensável que permite o controle e acompanhamento

do projeto pelo gerente do projeto. A Figura 13 apresenta um exemplo de
cronograma elaborado com base na EAP da Figura 11 e pacote de trabalho ilustrado
na Figura 12. Cada nó (item que é desmembrado) é transformado numa tarefa
agrupadora (tarefa resumo) e os pacotes de trabalho são transformados em tarefas
do projeto.
Saiba mais.
Ouça o PODCAST e saiba mais sobre EAP e Pacote de Trabalho:
http://www.ricardo-vargas.com/pt/podcasts/work_package_tasks_dictionary/
MÉTODOS ÁGEIS
Os método ágeis surgiram do encontro de 17 metodologistas, em 2001. O grupo
formou a Aliança Ágil. Com base em um manifesto, o grupo definiu um conjunto de
princípios que deveria dar uma resposta aos seguintes pontos:
» Aos chamados métodos pesados (ou peso pesados) que tornavam o
desenvolvimento desoftware moroso e complexo.
» Alto índice de fracasso dos projetos da área de TI.
» Distanciamento dos interessados, ou seja, as metodologias de desenvolvimento
mantinham os interessados distantes do processo de desenvolvimento de software.
» Paradigma comando e controle (gerência e equipe). Essa abordagem torna a equipe
apenas uma executora de tarefas.

Métodos ágeis foi a resposta que a comunidade encontrou como alternativa para o
gerenciamento de projetos mais flexível.
Pesquisas apontam (Figura 14) que os método ágeis são mais efetivos que os
métodos tradicionais. Pesquisa realizada pelo Standish Group apontou que 42% dos
projetos ágeis alcançaram sucesso frente a apenas 14% dos métodos tradicionais,
no caso, o método Cascata (Waterfall).
As abordagens tradicionais focam o tempo e custo e, como você sabe, quando nós
direcionamos maior prioridade para uma dessas variáveis, a outra ou outras variáveis
sofrem as consequências. Por exemplo, para cumprir os contratos principalmente em
relação ao custo e tempo, muitas empresas acabam por diminuir as entregas, ou
seja, o escopo. Então, o cliente recebe um produto bem menor que o combinado
inicialmente.

Os métodos ágeis buscam o equilíbrio das variáveis escopo, tempo e custo com foco maior
na variável escopo, ou seja, é uma abordagem orientada ao produto.
Diferentemente das abordagens tradicionais, os métodos ágeis focam o escopo, ou
seja, é dada a preferência para as entregas do projeto. Mas, você poderia perguntar?
Como fica o tempo e o custo? Bom, funciona assim: uma lista de necessidades por
ordem de prioridade é definida e, se o tempo ou o custo forem atingidos antes de
terminar a lista, teoricamente, todas as necessidades de maior prioridade foram
entregues ao cliente restando, portanto, as necessidades de menor prioridade.
Alguns dos principais métodos ágeis:
» Programação Extrema – eXtreme Programming (XP).
» Framework Scrum.
» Desenvolvimento Dirigido à Funcionalidade (FDD – Feature Driven Development).
» Método de desevolvimento de Sistemas Dinâmicos – DSDM (Dynamic Systems
Development Method).
» Desevolvimento Adaptável de Software – Adaptive Software Development.
» Crystal.
» Programação Pragmática – Pragmatic Programming.
» Desenvolvimento Dirigido a Teste – Test Driven Development.
» Modelagem ágil – Agile Modeling.
As abordagens ágeis são estruturadas segundo alguns valores (Figura 16) e princípios
estabelecidos pelos metodologistas no encontro de 2001. Esses valores, no total 4,
e princípios, no total 12, formam a base dessas metodologias.
Saiba mais sobre os princípios ágeis:

http://agilemanifesto.org/iso/ptbr/principles.html
SCRUM
Scrum é um framework de gerenciamento ágil de projeto de software proposto por
Jeff Sutherland em 1993. Todo trabalho é dividido em pequenos ciclos de
desenvolvimento chamados Sprints. CadaSprint dura entre uma a quatro semanas.
Ao final de cada Sprint é entregue uma parte funcional do produto.
SCRUM aceita que inevitavelmente haverá mudanças no projeto.
O processo de gerenciamento proposto pelo Scrum é relativamente simples:
1. Inicialmente é eleito um responsável pelos requisitos, ou proprietário do produto
(product owner) que define a mantém atualizada uma lista com todos os requisitos
(product backlog) do usuário ou cliente.
2. Numa 1ª reunião (Sprint Planning Meeting), são selecionados o “mediador”
(Scrum Master) e os requisitos (prioridade e tempo).

3. Numa 2ª reunião, a equipe (Scrum Team) calcula e divide as tarefas (sprint Backlog).
Essa porção de requisitos (interação) que será desenvolvida é chamada de sprint e
dura entre 1 e 4 semanas. Ao final de um sprint é entregue uma parte funcional do
produto.
4. Durante uma sprint são realizadas reuniões diárias com duração de 15 minutos. Ao
final da sprint é realizada a reunião de revisão e preparação para o próximo sprint.
Vídeo sobre a implantação do Scrum na Globo.com:
Equipe Scrum e seus Papéis
O Product Owner (proprietário do produto) é a única pessoa responsável pelo
gerenciamento doBacklog do Produto e por garantir o valor do trabalho realizado pelo
Time. O Product Owner (ou PO) pode ser o cliente, um gerente de produto, um
usuário, etc. É recomendado que o Product Owner conheça o produto que será
desenvolvido e que tenha uma boa interação com os demais interessados no projeto,
visto somente ele ser o responsável pelos requisitos do produto.

Times (multifuncionais) auto-organizados de desenvolvedores, analistas,
engenheiros, especialistaem banco de dados, etc. transformam o Backlog do Produto
em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. É
importante destacar que os Times Scrum devem ser pequenos para que de fato
produzam resultados satisfatórios. Muitas experiências com Times grandes (com 10
ou mais integrantes) tem mostrado que a produtividade diminui significativamente.
Isto porque o Time Scrum deve se comunicar intensamente e, Times com muitos
integrantes tendem a ter dificuldades no processo de comunicação.
O Scrum Master é responsável por garantir que o Time Scrum esteja aderindo aos
valores do Scrum, às práticas e às regras. Ele não tem autoridade (no sentido de
chefe), mas é o responsável pela equipe, coordena os eventos, avalia os resultados
(produtividade), ou seja, é a interface da equipe perante os demais interessados,
assim como o Product Owner é a interface dos interessados (lado cliente/usuário).
TimeBox

Timebox (caixa do tempo) significa a delimitação no tempo de uma tarefa/evento.
Vários eventos no Scrum são limitados no tempo, por exemplo, uma Sprint deve ser
realizada entre 1 e quatro semanas e as reuniões tem duração entre 15 minutos a 4
horas (dependendo da reunião).
Quer saber mais sobre Timebox? Leia o artigo disponível em:
http://blog.myscrumhalf.com/2011/11/time-box-no-scrum/
Planejando a Sprint
Como você já deve ter percebido, Sprint (Figura 18) é uma porção de todo o processo
supostamente necessário para desenvolver o produto final. Geralmente, uma Sprint
deve durar entre duas e quatro semanas. As Sprints de um projeto devem ter a
mesma duração.
Como você deve ter percebido na Figura 18, uma Sprint implementa uma parte dos
requisitos (ou histórias) listados no Product Backlog, essa porção de requisitos que
será implementado na Sprint é chamado de Sprint Backlog. Ao final de uma Sprint,
deve-se entregar o resultado planejado para a Sprint e, esse resultado, deve
acrescentar algo ao produto, incrementá-lo, além, é claro, de ser funcional.

Saiba mais sobre o que são histórias de usuários:
Antes de ser iniciada, a Sprint é planejada na Reunião de Planejamento 1. Nessa
reunião os requisitos ou histórias são selecionados de tal forma que caibam dentro
do tempo definido para a Sprint. Os requisitos ou histórias selecionados devem ser
sempre os de maior prioridade. A prioridade dos requisitos é definida pelo Product
Owner. Uma vez a lista esteja pronta (Sprint Backlog), é realizada a Reunião de
Planejamento 2. Essa reunião tem por objetivo subdividir os requisitos ou histórias
em tarefas. Os integrantes do Time selecionam as tarefas que desejam realizar.
Executando a Sprint
Uma vez definidas as tarefas e seus responsáveis, é iniciada a execução da Sprint. À
medida que aSprint é executada, o Time compara o planejado ao realizado.
Diariamente são realizadas reuniões pelo Time, os quais discutem o andamento e
impedimentos da Sprint. Essas reuniões, normalmente realizadas em pé, ocorrem no
início da manhã ou final da tarde e duram em média 15 minutos. A reunião aborda
os seguintes temas: 1) O que você fez ontem? 2) O que você fará hoje? E, 3) Há
impedimentos no seu caminho?

Finalizando a Sprint
Após o término da Sprint, é realizada a reunião de Revisão. Participam dessa reunião
o Time, Scrum Master (SM) e Product Owner (PO). O Time apresenta os resultados
ao PO que por sua vez avalia se os requisitos (histórias) foram implementadas
satisfatoriamente. Se não for aceito, os requisitos reprovados voltam para o Product
Backlog e farão parte de uma nova Sprint. Após o término da reunião de Revisão
também é realizada a reunião de Retrospectiva. Nessa reunião são discutidos os
pontos negativos e positivos da Sprint. São propostas melhorias que farão parte da
nova Sprint.
Quer saber mais?
Leia o glossário SCRUM:
http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario/
RESUMO
Nessa unidade, nós discutimos um pouco sobre como iniciar um projeto, bem como
a importância sobre a definição clara, mensurável e precisa do objetivo do projeto.
Vimos também que todo projeto deve definir o escopo do projeto, ou seja, o que faz
e o que não faz parte do projeto. Aprendemos que a EAP ou Estrutura Analítica do
Projeto é um instrumento fundamental para descrever e planejar um projeto.
Finalmente, discutimos sobre um pouco sobre uma nova abordagem de gestão de
projeto: os métodos ágeis. Percebemos que os métodos ágeis tem apresentado, nos
últimos anos, resultados melhores que métodos tradicionais como o método Cascata.
Vimos também sobre o Scrum, uma abordagem ágil muito utilizada por empresas de
desenvolvimento de software. Finalmente, discutimos alguns detalhes sobre o
Scrum: valores, princípios, processo, papéis envolvidos e dinâmicas.

Revisão sobre o Scrum, Assista ao vídeo que apresenta um resumo sobre o
Scrum:
Visão geral
Apresentação da disciplina:
CURSO: especialização em Tecnologias para Aplicações WEB
DISCIPLINA: ANÁLISE DE SISTEMAS
DOCENTE: iolanda cláudia sanches catarino
Apresentação do Professor:
Sou a professora Iolanda, mestre em Ciência da Computação pela
UFSCar, docente da UNOPAR na graduação e pós-graduação desde
1996 e atuo na área de engenharia de software como analista de
sistemas.
Sejam bem-vindos à disciplina de Análise de Sistemas!
Primeiramente, abordarei uma contextualização do paradigma
orientado a objetos, daUnified Modeling Language (UML), do
Processo Unificado e uma visão geral da metodologia Enterprise
Knowledge Development (EKD) que é uma abordagem para a
modelagem organizacional, facilitando a compreensão do negócio
para iniciar a modelagem das atividades de Análise de Requisitos e
Análise.
Na sequência, trabalharemos com os dois principais diagramas da
atividade de Análise – o Diagrama de Casos de Uso e o Diagrama de
Classes, integrando-os com o Diagrama de Atividades que se aplica
a qualquer domínio de software.
Objetivos:
 Conhecer fundamentos sobre o paradigma orientado a
objetos;
 Conhecer a Linguagem de Modelagem Unificada – UML e suas
técnicas de modelagem;
 Conhecer e aplicar técnicas de modelagem da atividade de
análise de sistemas, priorizando os dois principais diagramas
da UML – Diagrama de Casos de Uso e Diagrama de Classes.
Conteúdo Programático:
 Paradigma Orientado a Objetos: histórico, características e
conceitos;
 A Linguagem de Modelagem Unificada - Unified Modeling
Language (UML): histórico e visão geral das técnicas de
modelagem;

 Modelo de Use Cases: Diagrama de Use Cases
e Documentação de Use Cases;
 Diagrama de Classes;
 Diagrama de Atividades;
 Diagrama de Sequência;
 Diagrama de Máquina de Estados;
 Especificação das técnicas de modelagem com
ferramenta CASE.
Metodologia:
Na unidade utilizaremos todos os recursos necessários e disponíveis
para o desenvolvimento da discussão do conteúdo, sendo assim,
faremos uso de:
 Textos da própria Web Aula e de outros sites que possam
contribuir para a discussão;
 Vídeos que possam esclarecer ou aprofundar determinados
conteúdos;
 Fóruns para discussão de tópicos onde seja possível a troca de
ideias e conteúdos entre os discentes e docentes;
 Avaliações virtuais onde será realizada a verificação do
aprendizado;
 Entre outros recursos que poderão ser utilizados visando
maior entendimento da matéria.
Avaliação Prevista:
Cada web aula conterá uma avaliação virtual composta de 5
questões (sendo assim, temos 2 web-aulas com 5 questões cada).
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação.
Critérios para Participação dos Alunos
no Fórum:
Quando houver fórum de discussão o aluno será avaliado quanto ao
conteúdo de sua postagem, onde deverá comentar o tópico
apresentando respostas completas e com nível crítico de avaliação
pertinente ao nível de pós-graduação. Textos apenas concordando
ou discordando de comentários de outros participantes do fórum
sem a devida justificativa ou complementação não acrescentam em
nada ao debate da disciplina, sendo assim, devem ser evitados. Os
textos devem sempre vir acompanhados das justificativas para a
opinião do discente sobre o conteúdo discutido, para que assim,
possamos dar continuidade ao debate em nível adequado. Além
disso, podem ser utilizados citações de artigos, livros e outros
recursos que fundamentem a opinião ou deem sustentação a sua
posição crítica sobre o assunto. Deve ser respeitado o tópico

principal do fórum, evitando debates que não tem relação com o
tema selecionado pelo professor.
Habilidades e competências
Ampliar seus conhecimentos sobre os aspectos teóricos contidos nas
diversas correntes do pensamento sobre a temática discutida na
disciplina;
Compreender a importância dos temas trabalhados para a formação
profissional;
Articular a relação teoria e prática no exercício da profissão, por
meio do entendimento da visão do mundo moderno e globalizado.
1
TECNOLOGIAS PARA APLICAÇÕES WEB
WEB AULA 1
Unidade 1 – Análise de Sistemas
Atualmente, a transformação organizacional tem sido amplamente discutida e
praticada, pois a transição entre negócios e tecnologias de informação, bem como a
integração das funcionalidades de um Sistema de Informação (SI) com os requisitos
organizacionais tem sido o grande problema das organizações e da engenharia de
sistemas. Então, iniciamos esclarecendo dois conceitos: Engenharia de
Sistemas e Engenharia de Software!
Figura 1 – Engenharia de Sistemas.
Fonte: Thinkstock (2012).
A Engenharia de Sistemas contempla todos os aspectos relacionados ao
desenvolvimento de sistemas com base em computadores,
incluindo hardware, software e engenharia de processos, e aEngenharia de
Software é uma parte da Engenharia de Sistemas que se ocupa de todos os aspectos

da produção de software (SOMMERVILLE, 2003). Para Pressman (2002), a
Engenharia de Software abrange um conjunto de 3 elementos fundamentais
(métodos, ferramentas e procedimentos), que possibilita ao gerente o controle do
processo de desenvolvimento do software e oferece ao profissional uma base para
a construção de software de alta qualidade.
O método proporciona os detalhes de “como fazer” para construir o software.
Envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de
projeto, análise de requisitos,análise e projeto, implementação e testes. Sommerville
(2003) define que um método é uma abordagem estruturada para o desenvolvimento
de software, para facilitar a produção de software de alta qualidade, apresentando
uma boa relação custo-benefício.
Todos os métodos apresentam modelos de um sistema (técnicas de modelagem) que
possam ser representados graficamente por diagramas, na maioria, ou de forma
descritiva, sendo que cada técnica de modelagem tem um objetivo e aplicabilidade
para melhor especificar o projeto. Na literatura, há vários métodos de
desenvolvimento renomados e reconhecidos pelo mercado. Não existe o método ideal
e diferentes métodos têm áreas de aplicação diversificada.
As ferramentas proporcionam apoio automatizado ou semi-automatizado aos
métodos de desenvolvimento de software, como por exemplo, as
ferramentas Computer Assited Software Engineering (CASE) - Engenharia
de Software Auxiliada por Computador, de modelagem, de banco de dados e de
linguagens de programação.
Os procedimentos definem o planejamento do projeto, a sequência de execução das
atividades, as técnicas de modelagem que são adotadas do método escolhido, a
sequência de execução das atividades e demais regras e padrões adotados no
desenvolvimento do software.
Podemos concluir que o desenvolvimento de um SI deve abranger a definição de uma
metodologia que contemple métodos, técnicas de modelagem, arquitetura e
tecnologias a serem adotados no desenvolvimento do sistema, visando
um software com qualidade que atenda plenamente os requisitos dos usuários e
assim, agregue inteligência ao negócio.
2
Os vários métodos e metodologias de desenvolvimento de sistemas dos paradigmas
Estruturado e Orientado a Objetos abrangem um conjunto de técnicas de modelagem
específicas para documentar as principais fases de um processo de desenvolvimento
– Levantamento de Dados, Análise, Projeto e Implementação, conforme ilustra a
figura a seguir.
Figura 2 – Processo de Desenvolvimento.

Fonte: Do autor (2012).
A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma
visão lógica do negócio e independente de tecnologias de desenvolvimento.
Muitos modelos de requisitos existentes descrevem o ambiente organizacional por
meio de entidades e atividades, porém não representam as razões envolvidas nos
processos de decisões, o qual dificulta o desenvolvimento de um SI que atenda
plenamente os requisitos da organização. Assim, para garantir a identificação dos
requisitos de um SI, sugere-se adotar a modelagem organizacional, previamente,
visando identificar, definir e especificar os objetivos e processos próprios da
organização (CATARINO; CAZARINI, 2008).
A Modelagem Organizacional é um processo de modelagem complexa, pois envolve
questões que necessitam de conhecimentos específicos ou tácitos dos participantes
envolvidos nos processos de negócio, questões de gestão de pessoas e questões
técnicas relacionadas aos objetos ou serviços da organização. A
metodologia Enterprise Knowledge Development (EKD) (BUBENKO, 1998) é uma
abordagem para a Modelagem Organizacional que facilita a aquisição do
conhecimento da estrutura organizacional e estratégica, auxiliando na identificação
dos requisitos organizacionais para, assim, melhorar a compreensão do domínio e a
interação entre os usuários e o SI.

Para continuar aprendendo sobre EKD, acesse os links:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-
530X2004000200006
http://www.teses.usp.br/teses/disponiveis/18/18135/tde-25112008-153952/pt-
br.php
3
1. Paradigma Orientado a Objetos
O paradigma Orientado a Objetos é uma abordagem para o desenvolvimento de
aplicações, ou seja, é uma estratégia de desenvolvimento de software que organiza
o software como uma coleção de objetos que contém tanto a estrutura dos dados
como o comportamento. É uma maneira de pensarnos problemas, utilizando modelos
organizados a partir de conceitos do mundo real.
A programação orientada a objetos teve início nos anos 1970 com a linguagem
SIMULA, parte da linguagem Smalltalk desenvolvida pela Xerox PARC, mas ganhou
grande visibilidade durante a década de 1980. Os conceitos básicos do
desenvolvimento de software orientado a objetos levaram mais de 10 anos para
amadurecerem. Da mesma forma que era difícil pensar em programação estruturada
quando as linguagens disponíveis eram Assembler e Fortran, também ficava difícil
pensar em programação orientada a objetos quando não se dispunha de linguagens
como C++, Ada e Java.
A abordagem orientada a objetos baseia-se nos conceitos da orientação a objetos,
apresentando melhorias significativas de qualidade e um aumento constante da
produtividade para o desenvolvimento de aplicações. A complexidade do
desenvolvimento de sistemas tem aumentado em função de mudanças tecnológicas
expressivas em poder de processamento e facilidade de uso, face à demanda por um
mercado competitivo e dinâmico. Sua principal característica é a uniformização dos
formalismos utilizados na análise, no projeto e na implementação. Outras
características se destacam, como:
a) Reusabilidade: refere-se à diminuição de custos por meio do reaproveitamento
(reutilização) de componentes de software e diminuição do tempo de
desenvolvimento do sistema. Segundo Booch; Jacobson e Rumbaugh (2000, p. 20),
“[...] os componentes são partes físicas e substituíveis de um sistema, que
proporcionam a realização de um conjunto de interfaces”;
b) Manutenibilidade: refere-se ao grau de impacto de alterações corretivas e
evolutivas, nosoftware , para realizar mudanças bem localizadas dos objetos, não
acarretando propagações descontroladas por todo o software;
c) Confiabilidade: refere-se a um controle de segurança e organização que é
estabelecido às classes de objetos, obtido pelo encapsulamento, tornando o acesso
às estruturas de dados privado aos objetos;
d) Extensibilidade: refere-se às partes do software que têm o seu uso estendido
a objetos pertencentes às classes criadas posteriormente. Classes genéricas podem

ser acrescidas de funcionalidades, gerando classes mais especializadas, aplicando o
conceito de herança.
Acompanhando a evolução das linguagens de programação orientadas a objetos, os
métodos de modelagem orientados a objeto surgiram entre meados da década de
1980 e 1990. Os métodos suportam os mesmos conceitos básicos da orientação a
objetos, apresentando técnicas de modelagem com notação e interpretação
particular dos elementos que compõem a técnica.
Os diversos métodos que surgiram para apoiar o paradigma orientado a objetos,
tiveram uma grande diversidade de autores. No início da década de 1990, os
pesquisadores James Rumbaugh, Ivar Jacobson e Grady Booch uniram as melhores
características destacadas em suas técnicas de modelagem e construíram um
padrão de referência para modelagem orientada a objetos, surgindo aUnified
Modeling Language (UML) – Linguagem de Modelagem Unificada.
4
O elemento principal da abordagem orientada a objetos é o conceito de objeto. Na
definição de Booch; Jacobson e Rumbaugh (2000, p. 456), um objeto é “[...] uma
entidade com uma fronteira bem-definida e uma identidade que encapsula o estado
e comportamento”. Para Rumbaugh (1994, p. 31), um objeto é “[...] um conceito,
uma abstração, algo com limites nítidos e significado em relação ao problema em
causa”. A figura a seguir ilustra um objeto.
Figura 3 – Exemplo de Objeto.
Podemos definir um objeto como sendo qualquer coisa concreta ou abstrata com
existência perceptível no mundo real que possa ser individualizado por possuir
características e comportamento próprio, ou seja, todos os objetos têm identidade
e são distinguíveis.
Para rever os conceitos da orientação a objetos, acesse o link:
http://books.google.com.br/books?id=BPVHsG17bAYC&printsec=frontcover&dq=co
nceitos+da+orienta%C3%A7%C3%A3o+a+objetos&hl=pt-
BR&sa=X&ei=TviYUNLgFIf28wSOpICYCw&ved=0CDkQ6AEwAQ#v=onepage&q=con
ceitos%20da%20orienta%C3%A7%C3%A3o%20a%20objetos&f=false

2. Introdução à Unified Modeling Language (UML)
A UML consiste da fusão dos métodos de Booch, Rumbaugh (OMT- Object Modeling
Technique) e Jacobson (OOSE – Object-Oriented Software Engineering). A fusão
iniciou com o trabalho de Rumbaugh e Booch, que criaram um método a partir de
pontos fortes de cada um, surgindo o Unified Method – UM 0.8, apresentado ao
público em 1995. Logo a seguir, em meados de 1996, Jacobson integrou-se ao grupo
e lançaram a UML versão 0.9. A partir daí, criaram forças com cooperação de grandes
empresas, lançando no mercado com aprovação da Agência Americana de
Padrões – Object Management Group (OMG) em julho de 1997, considerando um
padrão mundial. A concretização da UML aconteceu em 1997.
Conforme Booch; Jacobson e Rumbaugh (2000, p. 13), a UML é “[...] uma linguagem
padrão para a elaboração da estrutura de projetos de software . A UML é uma
linguagem para visualização, especificação, construção e documentação de artefatos
que façam uso de sistemas complexos desoftware ”.
A UML contempla uma representação gráfica por meio das técnicas de modelagem
que especificam vários elementos (objetos, classes, atributos etc) da abordagem
orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e
não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas
se apoia no desenvolvimento incremental, por meio de modelos que podem evoluir
com a inclusão de novos detalhes.
VÍDEO 1
00:00
00:00
Atualmente, a OMG é a organização responsável em manter e administrar a UML.
Para mais informações sobre a OMG, acesse o link:
http://www.omg.org/
Segue-se um resumo da evolução da UML:
Quadro 1 – Cronograma de evolução da UML.
Ano Versão
1995 UML 0.8 (Booch e OMT)
1996 UML 0.9 (Booch, OMT e OOSE)
1997
UML 1.0 (padronizada pelo OMG – Object Management Group)
UML 1.1 (revisada e adotada pelo OMG)
1998 UML 1.3 (nova revisão)
2001 UML 1.4
2003 UML 1.5
2005 UML 2.0
2007 UML 2.1.1 (setembro)e 2.1.2 (novembro)

2009 UML 2.2
2010 UML 2.3
2011 UML 2.4.1 (agosto)
Veja o vídeo a seguir que apresenta a evolução das tecnologias.
https://www.youtube.com/watch?v=WDFkHCfVe5Y
E a UML, porque evolui?
A UML contempla uma representação gráfica, por meio das técnicas de modelagem
que especificam vários elementos (objetos, classes, atributos etc) da abordagem
orientada a objetos. A UML não se limita a um Modelo de Engenharia de Software e
não se vincula, exclusivamente, a uma etapa do processo de desenvolvimento, mas
se apoia no desenvolvimento incremental, a partir de modelos que podem evoluir
com a inclusão de novos detalhes.
Um modelo é uma descrição simplificada da realidade, apresentado a partir de uma
perspectiva específica e criado para proporcionar uma melhor compreensão do
sistema. Cada modelo pode ser expresso em diferentes níveis de precisão,
constituindo um conjunto de diagramas consistentes entre si e acompanhados de
técnicas de modelagem textuais. Um diagrama é uma visão sobre um modelo, o qual
proporciona uma representação parcial do sistema.
Figura 4 – Modelo x Diagrama.
Booch, Jacobson e Rumbaugh (2000) consideram as principais características da
UML:
a) centrado na arquitetura: a arquitetura do sistema é utilizada como principal
artefato para a conceituação, construção, gerenciamento e evolução do sistema em
desenvolvimento, representando uma visão do projeto como um todo. O conceito de
arquitetura de software incorpora os aspectos estáticos e dinâmicos mais importantes
do sistema. A arquitetura é influenciada por muitos fatores, tais como a plataforma
de software sobre a qual o sistema vai rodar (sistema operacional, sistema
gerenciador de banco de dados, protocolos para comunicação em rede, etc.), blocos
de construção reutilizáveis (frameworks, componentes e patterns), considerações de
distribuição, sistemas legado e requisitos não funcionais;

b) orientado a Casos de Uso: os casos de uso são utilizados como o principal
artefato para o estabelecimento do comportamento desejado do sistema;
c) processo iterativo: contempla o gerenciamento de sequências de versões
executáveis e incrementais, sendo que cada nova versão incorpora os
aprimoramentos incrementais em relação às demais. Uma versão do sistema liberada
resulta em uma iteração concluída.
De uma forma geral, a UML privilegia a descrição de um sistema segundo três
perspectivas:estrutural – representa a visão estática do sistema; funcional –
representa as funcionalidades do sistema, ou seja, os serviços que o sistema
disponibiliza aos usuários; dinâmica – representa o comportamento dos objetos em
tempo de execução.
Para mais informações sobre a UML, acesse o link:
http://www.uml.org/
6
A UML 2.0 abrange quatorze técnicas de modelagem, classificadas em estrutural e
comportamental. As técnicas de modela Modularidade gem estruturais enfatizam a
estrutura dos elementos a partir da identificação dos objetos, colaborando para
modelagem estática do sistema. As técnicas de modelagem comportamentais
enfatizam o comportamento e a interação entre os elementos do sistema,
colaborando para modelagem dinâmica do sistema.
Quadro 2 – Relação das técnicas de modelagem da UML 2.0
Estruturais Comportamentais
Diagrama de Classes Diagrama de Casos de Uso
Diagrama de Objetos Documentação de Casos de Uso
Diagrama de Estruturas Compostas Diagrama de Atividade
Diagrama de Pacotes Diagrama de Máquina de Estados
Diagrama de Componentes Diagrama de Sequência
Diagrama de Implantação
Diagrama de Comunicação
Diagrama de Interação Geral
Diagrama de Tempo
Figura 5 – Técnicas de Modelagem da UML.

Para conhecer e saber mais sobre as técnicas de modelagem da UML,
acesse o link: .
A arquitetura da UML 2.0 é composta de duas bibliotecas, a Infrastructure –
metamodelo superior – e a Superstructure, que define os elementos que compõem
as notações de modelagem da UML, criadas pela extensão e acréscimo dos elementos
básicos definidos na Infrastructure. Para facilitara reutilização de um software , essa
arquitetura assegura que o projeto do software seja especificado com:
a) modularidade: organizam-se os elementos da modelagem em pacotes, ou
seja, em unidades pequenas, bem definidas e fáceis de usar;
b) camadas: representa o refinamento dos elementos de um modelo para
organizar e facilitar o uso, obtendo um refinamento dos modelos por meio da
abstração dos elementos;
c) extensibilidade: permite a personalização dos elementos existentes de um
modelo, para que, assim, novos elementos não tenham que ser criados para
solucionar novos problemas.
Para continuar aprendendo, acesse os links:
OMG Unified Modeling LanguageTM(OMG UML), Infrastructure:
http://www.omg.org/spec/UML/2.4.1/Infrastructure
OMG Unified Modeling LanguageTM(OMG UML), Superstructure:
http://www.omg.org/spec/UML/2.4/Superstructure
7
2.1 O Processo Unificado

O Unified Process (BOOCH, JACOBSON; RUMBAUGH, 2000) surgiu para apoiar o
desenvolvimento desoftware s orientado a objetos, fornecendo uma forma
sistemática e evolutiva de modelar sistemas com a UML.
O Processo Unificado consiste na repetição de uma série de ciclos durante o processo
de desenvolvimento de um sistema, permitindo uma gerência mais efetiva de
projetos complexos. Cada ciclo é concluído com uma versão do produto pronta para
distribuição e é subdividido em quatro fases sucessivas: Concepção, Elaboração,
Construção e Transição. Cada fase, por sua vez, é subdivida em iterações que
passam por todos os cincos workflows (fluxo de trabalho, atividades) do processo:
Requisitos, Análise e Projeto, Implementação e Teste.
As fases representam os aspectos dinâmicos do processo e tratam a dimensão do
tempo de execução. As atividades são executadas de forma incremental e evolutiva,
representando os aspectos estáticos do processo. A ênfase sobre as várias atividades
muda em cada fase do processo, como mostra a figura a seguir.
Figura 6 – Ciclo de vida do Processo Unificado.
Fonte: Adaptado de Medeiros (2010, p. 16).
Na fase de Concepção define-se a ideia inicial do negócio, o domínio do problema e
a delimitação do escopo do projeto. É feita a identificação dos atores que irão
interagir com o sistema, definindo a natureza dessa interação em uma perspectiva
de alto nível, destacando os principais casos de uso do sistema. Assim, esta fase
evidencia o planejamento, sendo necessário, posteriormente, identificar, definir e
analisaros requisitos do sistema. Ao término desta fase, são examinados os objetivos
do projeto para se decidir sobre a continuidade do desenvolvimento, ou seja, a
viabilidade do projeto.
A atividade principal da fase de Concepção está no entendimento dos requisitos e a
determinação do escopo do projeto.

Na fase de Elaboração define-se o comportamento funcional dos requisitos do
sistema, estabelecendo a arquitetura e mecanismos para tratar aspectos
abrangentes do sistema, conforme o domínio do problema. Assim consolida-se a fase
de concepção, agregando valor a cada iteração-incremento que sofre. As atividades
da fase de Elaboração asseguram que os requisitos, a arquitetura e os planos estão
suficientemente estáveis, podendo prever com precisão os custos e prazos para a
conclusão do desenvolvimento.
A atividade principal da fase de Elaboração é a definição e modelagem dos
requisitos, ainda que algum trabalho de projeto e implementação seja realizado
para prototipar uma versão dosoftware.
Na fase de Construção define-se uma arquitetura executável do sistema para
implementação, validação e testes do software.
As atividades principais da fase de Construção concentra-se no projeto e na
implementação, visando evoluir e melhorar o protótipo inicial, até obter o primeiro
produto operacional.
Na fase de Transição o sistema é disponibilizado à comunidade usuária com
acompanhamento constante, devido à demanda de novas funções ou ajustes do
sistema.
A atividade principal da fase de Transição é a de testes, visando garantir que o
sistema atenda os requisitos do usuário com qualidade. Além disso, usuários devem
ser treinados, características ajustadas e elementos esquecidos adicionados ao
projeto, fazendo a realimentação das atividades por fase.
Para mais informações sobre o Processo Unificado, acesse o link:
http://books.google.com.br/books?id=B1fy5scNtaIC&printsec=frontcover&hl=pt-
BR#v=onepage&q&f=false
8
3. Atividade: Análise de Requisitos
Nesta seção vamos abordar uma breve revisão da Engenharia de Requisitos para
relembrar o conceito de requisitos funcionais, que na atividade de Análise de
Requisitos ou apenas Requisitos é especificado como casos de uso.
A Engenharia de Requisitos (Requirements Engineering) preocupa-se com o quê deve
ser feito, ou seja, a compreensão do problema e não como fazer, considerando o
domínio do sistema. A Engenharia de Requisitos é o processo de descobrir, analisar,
documentar e verificar os serviços e restrições (SOMMERVILLE, 2011).
O domínio de um sistema engloba o contexto para o qual será provida uma solução,
sendo que o processo de reconhecimento do domínio caracteriza a definição de sua

fronteira. O conteúdo de um domínio compreende fatos, regras, necessidades,
conceitos, agentes etc.
Veja o vídeo a seguir:
https://www.youtube.com/user/IBMbrasil?v=LQ5RlWMNtB0
Como o projeto de um software pode atender plenamente as necessidades do
usuário?
Considerando um modelo de engenharia de software como o Processo Unificado, a
atividade de Análise de Requisitos ou, simplesmente, Requisitos visa identificar,
analisar, definir e especificar os requisitos do sistema. Os requisitos de um sistema
são as descrições do que o sistema deve fazer, os serviços que oferece e as restrições
a seu funcionamento (SOMMERVILLE, 2011).
Sommerville (2011) classifica previamente os requisitos de um sistema
em: requisitos de usuário erequisitos de sistema. Requisitos de usuário são
declarações em uma linguagem natural com complemento de diagramas ou não, de
quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais
este deve operar. Requisitos de sistema são descrições mais detalhadas das funções,
serviços e restrições operacionais do sistema de software, sendo que o documento
de requisito de sistema (especificação funcional) deve definirexatamente o que deve
ser implementado.
CONCLUINDO:
Requisitos de Usuário: expressa os requisitos abstratos de alto nível;
Requisitos de Sistema: expressa a descrição detalhada do quê o sistema deve
fazer.
Exemplo:
Os requisitos de sistema são classificados em dois tipos: Requisitos Funcionais (RF):
são declarações de serviços que o sistema deve fornecer, de como o sistema deve
reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Requisitos Não Funcionais (RNF): são restrições aos serviços

ou funções oferecidos pelo sistema. Incluem restrições de tempo, restrições no
processo de desenvolvimento e restrições impostas pelas normas organizacionais.
Muitas vezes, aplicam-se ao sistema com o um todo. Surgem por meio das
necessidades dos usuários, devido a restrições de orçamentos, políticas
organizacionais etc.
CONCLUINDO:
Requisitos Funcionais: descrevem o que o sistema deve fazer – funcionalidades;
Requisitos Não Funcionais: expressam restrições que o software deve atender
ou qualidades específicas que o software deve ter.
9
Exemplos de definição de requisitos em linguagem natural:
 O sistema deve prover um cadastro de cursos de extensão – RF;
 O sistema deve prover um cadastro de autores (professor responsável pelo
curso) dos cursos – RF;
 O sistema deve prover um cadastro dos candidatos (internos: alunos e
externos: pessoas da comunidade externa) – RF;
 O sistema deve prover um cadastro das inscrições para os cursos de extensão
– RF;
 O sistema deve prover um relatório de inscritos nos cursos de extensão
diariamente e por período – RF;
 O sistema deve prover um relatório dos cursos de extensão por situação
(Ativo, Confirmado, Encerrado ou Cancelado) – RF;
 O período mínimo de inscrições de um curso de extensão deve ser de 20 dias
– RNF;
 O cadastro de candidatos externos deve ser via Web – RNF;
 O cadastro das inscrições para um curso de extensão dever ser via Web –
RNF;
 O cadastro dos candidatos internos deve ser integrado com o sistema
acadêmico (cadastro de funcionários – professores) – RNF;
 O candidato ao se inscrever em um curso deve receber um e-mail de
confirmação como tempo máximo de 10 segundos após a transação – RNF.
Para modelar os requisitos funcionais de um sistema podemos adotar o Diagrama
de Casos de Uso que, posteriormente, guiará o processo de desenvolvimento,
conforme o Processo Unificado. Das técnicas da UML, o Diagrama de

Sequência também pode ser adotado para especificar o cenário de cada caso de
uso.
Para continuar aprendendo sobre Requisitos, acesse o link:
http://www2.dbd.puc-rio.br/pergamum/tesesabertas/0210666_06_cap_02.pdf
RESUMO:
Com a competitividade na era do conhecimento as organizações contam com
sistemas computacionais, principalmente, os Sistemas de Informação para prover
apoio à tomada de decisão de gestores táticos e estratégicos de forma que agregue
inteligência ao negócio. Esta Web Aula apresentou uma contextualização da
Engenharia de Sistemas, uma introdução da Unified Modeling Language (UML),
descrevendo seu histórico, principais características e técnicas de modelagem da UML
2.0, uma visão do Processo Unificado com suas fases e atividades de
desenvolvimento e uma introdução à atividade de Análise de Requisitos.
Vamos iniciar o nosso fórum!
As técnicas de modelagem da UML atendem a documentação de todos os
tipos de sistemas de software? Qual a sua opinião?
Figura 7 – Sistemas de Software.
BOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: guia do usuário. Rio de
Janeiro: Campus, 2000.

BUBENKO Janis; STIRNA, Janis; BRASH, Danny. EKD user guide. Dpt of computer
and systems sciences. Stockholm: Royal Institute of Technology, 1998.
CATARINO, I. C. S.; CAZARINI, E. W. Utilizando a metodologia enterprise knowledge
development no processo de desenvolvimento de sistemas de apoio à
decisão. UNOPAR Científica Ciências Exatas Tecnológicas. Londrina, v. 7, p. 77-
84, nov. 2008. Disponível em:. Aceso em: nov. 2012.
MEDEIROS, Ernani. Desenvolvendo software com UML 2.0 - definitivo. São
Paulo: Pearson Brasil, 2010.
PRESSMAN, Roger S. Engenharia de software. 5. ed. São Paulo: Makron Books,
2002.
SOMMERVILLE, Ian. Engenharia de software. 6. ed. São Paulo: Addison-Wesley,
2003.
SOMMERVILLE, Ian. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
THINKSTOCK. Logical graph webshop, online store, internet shop. 2012. Disponível
em: <http://www.thinkstockphotos.com/image/stock-photo-logical-graph-
webshop-online-store-
internet/140810423/popup?al=140810423&sq=140810423/c=431,253,632,254,93
,28,34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,47
7,623,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,
696,344,629,614,647/f=PIHVX/s=DynamicRank>. Acesso em: nov. 2012.
THINKSTOCK. Smartphone with cloud of application icons. 2012. Disponível em:
<http://www.thinkstockphotos.com/image/stock-photo-smartphone-with-cloud-of-
application-
icons/131404860/popup?al=131404860&sq=131404860/f=PIHVX/s=DynamicRank
>. Acesso em: nov. 2012.
THINKSTOCK. Software architecture class diagram. 2012. Disponível em:
http://www.thinkstockphotos.com/image/stock-photo-software -architecture-class-
diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,
34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62
3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,
344,629,614,647/f=PIHVX/s=DynamicRank Acesso em: nov. 2012.
THINKSTOCK. Software architecture class diagram. Disponível
em:http://www.thinkstockphotos.com/image/stock-photo-software -architecture-
class-
diagram/91568967/popup?al=91568967&sq=91568967/c=431,253,632,254,93,28,
34,260,263,13,176,621,648,579,528,590,151,268,515,586,64,663,641,165,477,62
3,215,445,637,144,675,2,452,451,109,277,161,588,626,68,700,591,460,291,696,
344,629,614,647/f=PIHVX/s=DynamicRankAcesso em: nov. 2012.
THINKSTOCK. Software engineering word cloud. 2012. Disponível em:
SUGESTÕES DE LEITURA
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2.
ed. Rio de Janeiro: Elsevier, 2007.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. The unified modeling
language: user guide. Massachussets: Longman, 2000.

BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed.
Rio de Janeiro: Elsevier, 2006.
GUEDES, Gilleanes T. A. UML: uma abordagem prática. 3. ed. São Paulo: Novatec,
2008.
JACOBSON, Ivar; BOOCH, Grady; RUMBAUGH, James.The unified
software development process. New York: Addison-Wesley, 2000.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto
orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman,
2007.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.2: do conceitual à
implementação. Rio de Janeiro: Brasport, 2010.
PENDER, Tom. UML, a bíblia. Rio de Janeiro: Elsevier, 2004.
RUMBAUGH, James et al. Modelagem e projetos baseados em objetos. Rio de
Janeiro: Campus, 1994.
TECNOLOGIAS PARA APLICAÇÕES WEB
WEB AULA 1
Unidade 2 – Análise de Sistemas
4. Atividade: Análise
A atividade de Análise consiste em documentar o quê o sistema deve fazer em uma
visão lógica do negócio e independente de tecnologias de desenvolvimento.
As técnicas de modelagem propostas pela UML não estão vinculadas, diretamente, a
uma atividade (Análise, Projeto, Implementação e Testes) do processo de
desenvolvimento de software e não dizem quem deve fazer o quê, quando e como.
Alguns autores como Ernani Medeiros (2010) e Bezerra (2007) sugerem a adoção do
Diagrama e Documentação de Casos de Uso, do Diagrama de Classes, do Diagrama
de Objetos e do Diagrama de Estruturas Compostas para modelar a atividade de
Análise e, posteriormente, fazer um refinamento dessas técnicas e complementar
com os diagramas de iteração para modelar a atividade de Projeto, representando
uma visão física de desenvolvimento.
Para mais informações sobre a UML acesse o catálogo da OMG:
http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
Na UML, os agrupamentos que organizam um modelo (conjunto de diagramas) são
chamados de pacotes. O Diagrama de Pacotes tem por objetivo representar os
subsistemas ou submódulos englobados por um sistema de forma a determinar as
partes que o compõem. Demonstra como os elementos estão organizados nos

pacotes e as dependências que existem entre os elementos e os próprios pacotes
(GUEDES, 2008).
A notação do Diagrama de Pacotes contempla a representação dos pacotes e da
dependência entre os pacotes. Pacotes são utilizados para agrupar elementos, para
modelar subsistemas e para a modelagem de subdivisões da arquitetura de uma
linguagem. Um Pacote pode se subdividir em outros pacotes. O nome do Pacote deve
ser representativo e único. Um relacionamento de Dependência representa as
dependências entre os pacotes, indicando que o elemento necessita, de alguma
forma, do elemento do qual depende. A Figura 8 exemplifica um Diagrama de
Pacotes.
Figura 8 – Exemplo de Diagrama de Pacotes:
1
4.1 Diagrama de Casos de Uso
Para melhorar a compreensão do domínio e garantir que um sistema atenda às reais
necessidades dos usuários, o Diagrama de Casos de Uso auxilia a fase de Análise
de Requisitos, ajudando a especificar, visualizar e documentar as características e
serviços do sistema. Na fase de Análise, o Diagrama de Casos de Uso representa um
refinamento dos requisitos funcionais do sistema. A técnica de modelagem de casos
de uso foi idealizada por Ivar Jacobson, na década de 1970.
Segundo Bezerra (2007), o Modelo de Casos de Uso (MCU) é uma representação
das funcionalidades externamente observáveis do sistema e dos elementos externos
ao sistema que interagem com ele. O MCU é um modelo de análise que representa
um refinamento dos requisitos funcionais do sistema em desenvolvimento.
Segundo Guedes (2008), o Diagrama de Casos de Uso demonstra o comportamento
externo do sistema, procurando apresentar o sistema por meio de uma perspectiva
do usuário, demonstrando as funções e serviços (casos de uso) oferecidos e quais
usuários (atores) poderão utilizar cada serviço. Para Booch; Jacobson e Rumbaugh
(2006), o Diagrama de Casos de Uso representa os aspectos dinâmicos do sistema,
tendo um papel central para a modelagem do comportamento de um sistema, de um

subsistema ou de uma classe. Cada um mostra um conjunto de casos de uso e atores
e seus relacionamentos.
O Diagrama de Casos de Uso representa as funcionalidades do sistema e os
elementos externos ao sistema que interagem com ele. É o diagrama mais abstrato,
flexível e informal da UML, sendo utilizado no início da modelagem do sistema, na
atividade de análise, embora venha a ser consultado e, possivelmente, modificado
durante todo o processo de engenharia do software. Apresenta uma linguagem
simples e de fácil compreensão para que os usuários possam ter uma ideia geral de
como o sistema irá se comportar, sendo um modelo com uma perspectiva externa
do sistema.
Um Diagrama de Casos de Uso é representado pelos elementos. Atores, Casos de
Uso eRelacionamentos. Um Diagrama de Casos de Uso deve ser feito com base na
especificação da fronteira do sistema, permitindo identificar um subsistema ou o
sistema completo, assim delimitando o contexto do sistema.
Atores: os Atores representam os papéis desempenhados pelos diversos usuários
que poderão utilizar ou interagir com os serviços (funcionalidades) do sistema, ou
seja, é qualquer elemento externo ao sistema que interage com ele. A interação
significa que um Ator troca informações com o sistema, enviando dados para o
sistema processar ou recebendo informações processadas. Normalmente, o Ator
inicia a interação com o sistema.
Eventualmente um Ator pode representar algum hardware especial ou mesmo um
outro software que interaja com o sistema. Assim, um ator pode ser qualquer
elemento externo que interaja com osoftware (GUEDES, 2008).
Os Atores são representados por símbolos de “bonecos magros”, contendo uma breve
descrição logo abaixo do seu símbolo que identifica qual o papel que o Ator assume
dentro do diagrama. Cada ator deve representar um único papel. A Figura 9 ilustra a
notação de Ator e a Figura 9 ilustra o exemplo de alguns Atores.
Figura 9 – Exemplo de Atores.
Casos de Uso: um Caso de Uso (use case) representa qualquer interação de serviços
entre um Ator e o sistema, sem revelar a estrutura e o comportamento interno do
sistema. Cada serviço deve ser representado, individualmente, como um Caso de
Uso. A Figura 10 ilustra o exemplo de alguns Casos de Uso.
Os Casos de Uso referem-se aos serviços, tarefas ou funções oferecidas pelo sistema.
São utilizados para expressar e documentar os comportamentos pretendidos para as
funções do sistema (GUEDES, 2008).
2
Os Casos de Uso são documentados, demonstrando o comportamento pretendido
para o Caso de Uso e quais funções ele executará quando for solicitado. Os Casos de

Uso são representados por uma elipse, contendo uma breve descrição dentro do seu
símbolo que identifica qual serviço o Caso de Uso assume. Recomenda-se nomear
um Caso de Uso com verbo no infinitivo mais substantivo(s). Exemplo: Cadastrar
Curso ou Manter Curso, Realizar Avaliação, Lançar Nota de Avaliação.
Figura 10 – Exemplo de Casos de Uso.
Relacionamentos: a interação entre um Ator e um Caso de Uso é representada por
um relacionamento. Os relacionamentos possíveis são: associação, generalização,
extensão e inclusão.
Associação: é um tipo de relacionamento entre os Atores que interagem com o sistema, entre os
Atores e os Casos de Uso ou os relacionamentos entre os Casos de Uso e outros Casos de Uso. Uma
associação entre um Ator e um Caso de Uso demonstra que o Ator utiliza-se, de alguma maneira, da
função representada pelo Caso de Uso (GUEDES, 2011).
Uma Associação é representada por uma reta, ligando o Ator ao Caso de Uso,
podendo indicar a Navegabilidade da Associação, que indica se as informações são
fornecidas pelo Ator ao Caso de Uso, se são transmitidas pelo Caso de Uso ao Ator
ou ambos (não indica a navegabilidade). Uma Associação pode possuiruma descrição
própria ou um nome, quando há necessidade de esclarecer alguma informação que
está sendo transmitida. A Figura 11 ilustra a notação de Associações e a Figura 12
ilustra o exemplo de associações entre os Atores e Casos de Uso.
No relacionamento de Associação entre um Ator e Caso de Uso pode-se indicar a
multiplicidade, o qual especifica o número de vezes que um Ator pode utilizar um
determinado Caso de Uso.
Figura 11 – Notação de Associação.
Figura 12 – Exemplo de Associação entre Atores e Casos de Uso.

3
Generalização é um tipo de relacionamento entre Casos de Uso ou entre Atores. A
Generalização de Atores é uma representação abstrata de papéis e a Generalização
de Casos de Uso representa dois ou mais Casos de Uso que apresentam
características semelhantes. Representa-se um Caso de Uso Geral (Generalização),
que descreve as características compartilhadas por todos os Casos de Uso
Especializados (Especialização). A estrutura do Caso de Uso Geral é herdada pelos
Casos de Usos Especializados. A Figura 13 ilustra o exemplo de Generalização de
Atores e Casos de Uso.
Figura 13 – Exemplo de Generalização entre Atores e Casos de Uso.
A Extensão representa um relacionamento estendido entre Casos de Uso, indicando
que o Caso de Uso “base” incorpora implicitamente o comportamento de outro Caso
de Uso em um local especificado pelo Caso de Uso “estendido”. Um relacionamento

estendido é utilizado para a modelagem da parte de um Caso de Uso que o usuário
poderá considerar como um comportamento opcional do sistema ou de um subfluxo
separado, que é executado somente sob determinada condição. O relacionamento de
dependência <<extend>> é representado por uma seta que parte do Caso de Uso
“estendido” para o Caso de Uso “base”. A Figura 14 ilustra um exemplo de Extensão
entre os Casos de Uso.
Às vezes, não está claro qual é a condição para que um Caso de Uso estendido seja
executado, assim, pode-se acrescentar uma Restrição. Restrições são representadas
por uma nota explicativa, contendo o texto que determina a condição entre chaves.
Figura 14 – Exemplo do Relacionamento de Extensão.
O relacionamento de Inclusão representa um relacionamento de dependência entre
Casos de Uso, indicado pelo estereótipo <<include>>. Esse relacionamento é
utilizado quando existe uma situação ou rotina comum a mais de um Caso de Uso. A
inclusão indica uma obrigatoriedade com outro Caso de Uso, sendo que a execução
do primeiro obriga também a execução do segundo. Um relacionamento de Inclusão
pode ser comparado à chamada de uma sub-rotina. O relacionamento de
dependência <<include>> é representado por uma seta que parte do Caso de Uso
“base” para o Caso de Uso “incluído”. A Figura 15 ilustra um exemplo de Inclusão
entre os Casos de Uso.
Figura 15 – Exemplo do Relacionamento de Inclusão.

Para mais informações sobre Use Cases acesse:
http://www.ivarjacobson.com/resource.aspx?id=1282
4
Após a criação do Diagrama de Casos de Uso, complementam-se os Casos de Uso
com uma documentação. O formato de documentação de um Caso de Uso é flexível,
permitindo que se documente o Caso de Uso da forma que se considerar melhor, até
mesmo pelo uso de pseudocódigo ou de código de uma linguagem de programação.
O formato usual é em cenários – principal e alternativos.
Para continuar aprendendo sobre Documentação de Casos de Uso, acesse
os links:
http://books.google.com/books?isbn=8574524441
http://books.google.com/books?isbn=8574522546
VÍDEO 2
00:00
00:00
4.2 Diagrama de Classes
Considerando que o Diagrama de Casos de Uso está concluído, a próxima etapa é
analisar os Casos de Uso para iniciar o trabalho de identificação das classes de
objetos, o qual se faz necessário compreender como o sistema está estruturado
internamente para que as funcionalidades sejam executadas. As classes de objetos
muitas vezes podem ser identificadas, também, como substantivos nas descrições
do domínio do problema.
A partir da elaboração de um primeiro estágio do Diagrama de Classes, o mesmo
evoluirá à medida que o sistema é desenvolvido, o qual o diagrama deve ser
incrementado com novos detalhes, assim tendo novos estágios refinados do
Diagrama de Classes.
O Diagrama de Classes representa a modelagem da parte estática do sistema,
representando um conjunto de Classes com seus atributos, operações e
relacionamentos.
O objetivo do Diagrama de Classes é permitir a visualização das classes utilizadas
pelo sistema e como estas se relacionam. Esse diagrama apresenta uma visão
estática de como as classes estão organizadas, preocupando-se em definir sua
estrutura lógica (GUEDES, 2008).
O Diagrama de Classes é a principal técnica de modelagem da UML, assim vamos
explorar nesta seção os principais componentes do Diagrama de Classes, tratando-o
como um diagrama da atividade Análise. Posteriormente, recomendo evoluir o
Diagrama de Classes em várias visões até obter um grau de refinamento com

detalhes de implementação, sendo considerado um Diagrama de Classes da atividade
Projeto.
A seguir apresentamos os principais elementos do Diagrama de Classes.
Classe: uma Classe é representada por um retângulo com, no máximo, três partes.
Na primeira parte (de cima para baixo) é exibido o nome da Classe. Por convenção,
o nome é apresentado no singular e com as palavras compostas começando por letra
maiúscula. Na segunda parte são declarados os atributos que correspondem aos
dados que um objeto armazena. Para cada atributo está associado um valor que esse
atributo pode assumir. E na terceira parte, são declaradas as operações que
correspondem às ações que um objeto sabe realizar, sendo que os objetos de uma
classe compartilham as mesmas operações.
O nome de um atributo é declarado por um substantivo ou expressão que representa
alguma propriedade da classe, tipicamente, em letra minúscula e, para palavras
compostas, usa-se concatená-las, sendo que a partir da segunda palavra inicia-se
com letra maiúscula, por exemplo,dataNascimento. O nome de uma operação é
declarado por um verbo ou uma locução verbal breve, usando a mesma convenção
de letras minúsculas e maiúsculas dos atributos. A Figura 16 ilustra a notação de
Classe e a Figura 17 ilustra alguns exemplos de representação de Classes.
Figura 16 – Notação de Classe.
Figura 17 – Exemplos de Classes com Notações Diferentes.
5
Relacionamentos: na UML, os modos pelos quais os itens podem estar conectados
a outros, isto é, logicamente ou fisicamente, são modelados como relacionamentos,

que permitem compartilhar informações e colaboram para a execução dos processos
pelo sistema (GUEDES, 2008).
Existem 4 tipos de relacionamentos:
a) Associações: são relacionamentos estruturais entre instâncias. Tipos de
associações: Unária (autoassociação ou reflexiva), binária, ternária, classe
associativa e agregação.
b) Generalizações: conectam classes generalizadas a outras mais especializadas,
o que é conhecido como relacionamento Generalização e Especialização;
c) Dependências: são relacionamentos de utilização entre casos de uso, classes,
pacotes e anotações;
d) Realizações: são relacionamentos que especificam um contrato de execução
entre classes e interfaces.
O relacionamento do tipo Associação é representado por uma reta, ligando as
classes envolvidas, podendo também possuir setas em suas extremidades para
indicar a navegabilidade da associação, o que representa o sentido em que as
informações são transmitidas entre os objetos das classes envolvidas. As Associações
podem também possuirnomes (títulos). A Figura 18 ilustra a notação de Associação.
Figura 18 – Notação de Associação
O atributo a ser transmitido na Associação é um atributo implícito, não sendo
apresentado na classe para a qual foi transmitido. Em cada extremidade da
associação deve ser definida a multiplicidade da associação.
A multiplicidade procura determinar o número mínimo e máximo de objetos
envolvidos em cada extremidade da Associação, especificando quantas instâncias de
uma classe relacionam-se a uma única instância de uma classe associada.
A multiplicidade depende de pressupostos e de como são definidas as fronteiras de
um problema, conforme as regras de negócio. O quadro a seguir ilustra os tipos de
multiplicidade.
Quadro 1 – Tipos de Multiplicidades.
Multiplicidade Significado
0..1
No mínimo zero (nenhum e no máximo um). Indica que os obje
classes associadas não precisam obrigatoriamente estar relacio
se houver relacionamento indica que apenas uma instância da
relaciona com as instâncias da outra classe.
1..1
Um e somente um. Indica que apenas um objeto da classe se r
com os objetos de outra classe.

0..*
No mínimo nenhum e no máximo muitos. Indica que pode ou n
instâncias da classe participando do relacionamento.
*
Muitos. Indica que muitos objetos da classe estão envolvidos n
relacionamento.
1..*
No mínimo 1 e no máximo muitos. Indica que há pelo menos u
envolvido no relacionamento, podendo haver muitos objetos en
Intervalo
específico
Define-se um intervalo inicial e final, indicando que existem pe
um número específico inicial de instância envolvidas no relacion
com um número limite de instâncias.
6
A Associação Unária ou Reflexiva ocorre quando existe um relacionamento de um
objeto de uma classe com objetos da mesma classe. Cada objeto tem um papel
distinto nessa associação. A associação reflexiva é representada por uma linha,
iniciando e terminando na mesma classe. A Figura 19 ilustra um exemplo de
Associação Unária.
Figura 19 – Notação e Exemplo de Associação Unária.
A Associação Binária ocorre quando são identificados relacionamentos entre
objetos de duas classes.A existência de uma associação entre dois objetos possibilita
a troca de mensagens entre eles. Uma associação é representada por uma linha reta,
ligando as classes às quais pertencem os objetos relacionados. A Figura 20 ilustra
um exemplo de Associação Binária.
Figura 20 – Notação e Exemplo de Associação Binária.
A Associação Ternária ou N-ária ocorre quando conectam objetos de mais de
duas classes, ou seja, uma associação pode ter grau maior que dois. São
representadas por um losango para onde convergem todas as ligações da
Associação. A Figura 21 ilustra um exemplo de Associação Ternária.
Figura 21 – Notação e Exemplo de Associação Ternária.

3ª prova pós web 1ª chamada

3ª prova pós web 1ª chamada

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 3ª prova pós web 1ª chamada

Similaire à 3ª prova pós web 1ª chamada (20)

Dernier

Dernier (20)

3ª prova pós web 1ª chamada