Engenharia de Software

MDULO DE:
ENGENHARIA de SOFTWARE
AUTORIA:
Ms. CARLOS VALENTE
Copyright 2007, ESAB Escola Superior Aberta do Brasil
SUMRIO
UNIDADE 1........................................................................................................... 5
O que Engenharia de Software ? - Qual a diferena entre Engenharia de
Software e Engenharia de Sistemas ? - O que um mtodo de Engenharia de
Software ? .......................................................................................................... 5
UNIDADE 2 ........................................................................................................... 9
Teoria de Sistemas - Interdependncia de Sistemas ........................................ 9
UNIDADE 3 ......................................................................................................... 11
Quais so os atributos de um bom Software ? - Quais so os desafios
enfrentados pela Engenharia de Software ? ................................................... 11
UNIDADE 4 ......................................................................................................... 15
Conceitos sobre a Engenharia de Software - O que Software ? A
Importncia do Software - SWEBOK ............................................................... 15
UNIDADE 5 ......................................................................................................... 19
Modelos de Processo de Software - Paradigmas do desenvolvimento de
Software - Modelo Balbrdia - Modelo Cascata .............................................. 19
UNIDADE 6 ......................................................................................................... 23
Paradigmas do Desenvolvimento de Software (continuao) - Modelo
Incremental - Prototipao ............................................................................... 23
UNIDADE 7 ......................................................................................................... 26
Paradigmas do desenvolvimento de Software (continuao) - Modelo Espiral Modelos mistos e caractersticas genricas .................................................... 26
UNIDADE 8 ......................................................................................................... 29
Paradigmas da Engenharia de Software: Processo, Mtodos e Ferramentas29
UNIDADE 9 ......................................................................................................... 32
Caractersticas de um bom processo - Caractersticas de um bom ambiente
de desenvolvimento ......................................................................................... 32
UNIDADE 10 ....................................................................................................... 35
Introduo ao RUP (Rational Unified Process) - Caractersticas - Fases e
Workflows ......................................................................................................... 35
UNIDADE 11 ....................................................................................................... 39
Modelos de Maturidade CMM (Capability Maturity Model) .......................... 39
UNIDADE 12 ....................................................................................................... 42
Requisitos de Software - Requisitos Funcionais e no Funcionais - Requisitos
de Usurio e de Sistema .................................................................................. 42
UNIDADE 13 ....................................................................................................... 45
Tcnicas de Anlise de Requisitos - O Documento de Requisitos de Software
.......................................................................................................................... 45
UNIDADE 14 ....................................................................................................... 48
Processos de Engenharia de Requisitos - Estudos de Viabilidade................. 48
UNIDADE 15 ....................................................................................................... 50
Modelagem UML: Unified Modeling Language Linguagem de Modelagem
Unificada .......................................................................................................... 50
UNIDADE 16 ....................................................................................................... 53
Metodologias de Desenvolvimento geis de Software: XP - FDD e DSDM ... 53
UNIDADE 17 ....................................................................................................... 57
Continuao das Metodologias de Desenvolvimento gil de Software: Scrum Crystal - ASD e AM .......................................................................................... 57
UNIDADE 18 ....................................................................................................... 61
Engenharia de Projeto - Projeto Modular - Projeto de interface com o usurio
.......................................................................................................................... 61
UNIDADE 19 ....................................................................................................... 64
Arquiteturas de Sistemas Distribudos - Arquitetura de Multiprocessadores .. 64
UNIDADE 20 ....................................................................................................... 67
Arquitetura cliente/servidor - Arquitetura de objetos distribudos .................... 67
UNIDADE 21 ....................................................................................................... 70
Mudanas em Software - Dinmica da Evoluo de Programas - Evoluo da
Arquitetura ........................................................................................................ 70
UNIDADE 22 ....................................................................................................... 73
Reengenharia de Software - Traduo de cdigo fonte - Engenharia Reversa Melhoria de estrutura de programa.................................................................. 73
UNIDADE 23 ....................................................................................................... 75
Reengenharia de Dados e suas abordagens .................................................. 75
UNIDADE 24 ....................................................................................................... 77
Gerenciamento de Configurao - Gerenciamento de Mudanas Gerenciamento de Verses e Releases .......................................................... 77
UNIDADE 25 ....................................................................................................... 81
(continuao) Construo de Sistemas - Ferramenta CASE .......................... 81
UNIDADE 26 ....................................................................................................... 84
Sistemas Legados - Estruturas dos Sistemas Legados - Avaliao dos
Sistemas Legados ............................................................................................ 84
UNIDADE 27 ....................................................................................................... 88
Manuteno: fundamentos da fase de Manuteno de Software, tipos de
Manuteno, procedimentos, tcnicas e ferramentas ..................................... 88
UNIDADE 28 ....................................................................................................... 92
Gesto de Projetos de Software e o PMBOK .................................................. 92
UNIDADE 29 ....................................................................................................... 96
Gerenciamento de Qualidade e Estratgias de Teste de Software ................ 96
UNIDADE 30 ..................................................................................................... 100
Engenharia de Software na WEB Sistemas e Aplicaes baseadas na WEB
........................................................................................................................ 100
NIDADE
O que Engenharia de Software ? - Qual a diferena entre Engenharia de

Software e Engenharia de Sistemas ? - O que um mtodo de Engenharia de
Software ?
Objetivo: Conceituar a Engenharia de Software, apresentar diferenas e definir mtodo.
A Engenharia de Software, conforme Sommerville, um dos papas dessa rea, uma disciplina
da engenharia que se ocupa de todos os aspectos da produo de software. Isso vai desde
os estgios iniciais de especificao de um Sistema, at propriamente a Manuteno para que
esse mesmo Sistema sobreviva ao longo do tempo.
A construo de software uma das atividades mais complexas e vitais para o pleno sucesso
de um Sistema informatizado. A Engenharia de Software justamente tenta, atravs dos
princpios bsicos de outras engenharias, trazer um pouco mais de luz para essa atividade
complexa.
A cobrana hoje das reas de Informtica e de T.I. (Tecnologia da Informao)
desenvolver Sistemas de forma rpida, com qualidade, e com custos cada vez menores.
Somente atravs de tecnologias adequadas, e com as melhores prticas, podemos atender a
esses novos desafios.
A Engenharia de Software constituda de Metodologias, Mtodos e Ferramentas que
permitem ao profissional especificar, projetar, implementar e manter Sistemas, avaliando e
garantindo as qualidades especificadas pelos usurios.
Engenharia de Sistemas
A Engenharia de Sistemas mais genrica e mais abrangente do que a Engenharia de
Software. Na verdade, a segunda faz parte da primeira. A Engenharia de Sistemas mais
antiga do que a de Software. Enquanto a primeira est mais envolvida com o Sistema como
um todo e seus detalhes, a Engenharia de Software mais especfica no que tange aos
componentes do sistema, em especial ao hardware e software.
Mtodo de Engenharia de Software

Sommerville afirma que um mtodo de Engenharia de Software uma abordagem
estruturada para o desenvolvimento de software. Podemos definir como abordagem
estruturada a estratgia de desenvolver algo com uma estrutura previamente estudada, ou
baseada nas melhores prticas. O objetivo maior de tudo isso facilitar a produo, em curto
espao de tempo, de software de alta qualidade, apresentando uma relao custo-benefcio
interessante.
Um ponto importante a observar que no existe, repito, no existe um mtodo ideal. As
possibilidades e os ambientes de desenvolvimento so to complexos, que dependendo de
cada situao e momento, existe um mtodo que possa explorar mais alguns tpicos, mas
deixar outros em aberto.
Outro ponto a ressaltar que existem vrios mtodos na Engenharia de Software, mas
poucas Metodologias. Podemos entender Metodologia tanto pelas palavras de Maddison,
como sendo um conjunto recomendado de filosofias, fases, procedimentos, tcnicas, regras,
ferramentas, documentao, gerenciamento e treinamento para o desenvolvimento de um
sistema de informao, como tambm o estudo de um ou mais mtodos.
No incio da computao poucos programadores seguiam algum tipo de metodologia

baseando-se, em sua maioria, na prpria experincia. Na Engenharia de Software existem
basicamente duas grandes metodologias. Uma originria da dcada de 70, chamada de
Metodologia Estruturada, e a mais recente intitulada de Metodologia Orientada a Objetos.
Diferenas das Metodologias

Tanto a abordagem estruturada quanto a orientada a objetos promovem solues prticas. A
diferena entre as duas metodologias a vida til e facilidade de manuteno de projetos. A
possvel reutilizao de um cdigo estruturado no comum, enquanto que um cdigo
orientado a objetos por possuir embutido em sua prpria filosofia as facilidades de
reutilizao e de descrio, utilizando UML (Unified Modeling Language), aumenta
naturalmente a vida til dos cdigos.
Abordando o software sob um ponto de vista puramente estruturado, definem-se os dados do
sistema em uma posterior sequncia de eventos que acarretar na transformao do estado
do sistema.
Por outro lado, numa abordagem focada em orientao a objetos, definem-se estruturas
abstratas, denominadas classes, que sero responsveis por partes da soluo do problema.
Cada classe incorporar dada (forma) e mtodos (comportamentos). Projetos orientados a
objetos utilizam da linguagem de modelagem UML (Unified Modeling Language). Esta
linguagem fruto dos esforos, em conjunto, dos autores Booch, Rumbaugh e Jacobson.
Wikipdia
http://pt.wikipedia.org/wiki/Engenharia_de_software
http://pt.wikipedia.org/wiki/Metodologia_(engenharia_de_software)
Oua um PODCAST sobre METODOLOGIAS:
http://www.improveit.com.br/podcasts/quem-se-importa-commetodologia.mp3
Responda, por escrito, as seguintes perguntas:
O que Engenharia de Software?

Qual a diferena entre Engenharia de Software e Engenharia de
Sistemas?
O que um mtodo de Engenharia de Software?
NIDADE
Teoria de Sistemas - Interdependncia de Sistemas

Objetivo: Visualizar a interao que os sistemas possuem entre si.
Um Sistema uma coleo significativa de componentes inter-relacionados, que trabalham
em conjunto para atingir alguns objetivos (Sommerville). organizado para executar certo
mtodo, procedimento ou controle ao processar informaes. Automatiza ou apoia a
realizao de atividades humanas atravs do processamento de informaes.
As complexas relaes entre os componentes de um sistema significam que o sistema em si
maior do que simplesmente a soma de suas partes.
As Arquiteturas de Sistema so normalmente descritas com o uso de Diagramas de Blocos,
mostrando os subsistemas principais e suas relaes. Veja a figura abaixo como um exemplo
desse conceito:
Ns encontramos, nessa imagem, os elementos de ENTRADA e de SADA do SISTEMA. E na

parte interna do SISTEMA a composio da inter-relao de vrias ENTIDADES. Na parte
inferior do SISTEMA temos um importante conceito de feed-back chamado de CONTROLE do

SISTEMA.
Inicia-se esse controle com um PADRO de comparao. Atravs de um SENSOR que
mensura periodicamente as alteraes do SISTEMA, compara-se com o PADRO. Uma vez o
SISTEMA sofrendo alteraes em relao ao PADRO, o ATIVADOR ir passar parmetros
para o SISTEMA se autocorrigir.
Um bom exemplo prtico deste conceito imaginarmos o ar condicionado. Parte-se
inicialmente da base de uma temperatura estabelecida por ns (PADRO). O sensor mensura
as variaes de temperatura. E o ATIVADOR ir deixar o ar condicionado ativado at
novamente o SENSOR verificar que a temperatura est no PADRO desejado.
Wikipdia
http://pt.wikipedia.org/wiki/Teoria_de_sistemas
Acesse o documento no site abaixo e veja maiores detalhes da interessante

Teoria de Sistemas:
http://www.abdl.org.br/filemanager/download/4/teoria%
20de%20sistema.pdf
10
NIDADE
Quais so os atributos de um bom Software ? - Quais so os desafios

enfrentados pela Engenharia de Software ?
Objetivo: Definir atributos de software e contextualizar a Engenharia de Software.
Os atributos de um bom software refletem seu comportamento quando em funcionamento, a
estrutura e a organizao do programa fonte, e tambm a documentao associada
(Sommerville). Como exemplos, temos o tempo de resposta do software consulta de um
usurio e a facilidade de compreenso do cdigo do programa. Esses mesmos exemplos
tambm podem ser chamados de atributos no funcionais.
Resumidamente o software deve proporcionar ao usurio a funcionalidade e o desempenho
requeridos e deve ser passvel de manuteno, confivel, eficiente e de fcil uso (veja mais
detalhes no quadro abaixo).
ATRIBUTOS
Descrio
Facilidade de
Manuteno
O software deve ser escrito de modo que possa evoluir para atender s
necessidades mutveis dos clientes. Esse um atributo crucial, porque as
modificaes em um software so uma consequncia inevitvel de um
ambiente de negcios em constante mutao.
Nvel de
Confiana
O nvel de confiana do software tem uma gama de caractersticas que

incluem confiabilidade, proteo e segurana. O software confivel no
deve ocasionar danos fsicos ou econmicos, no caso de um defeito no
sistema.
Eficincia
O software no deve desperdiar os recursos do sistema, como memria e

ciclos do processador. A eficincia, portanto, inclui a rapidez de resposta,
o tempo de processamento, a utilizao da memria, entre outros.
Facilidade de Uso
O software deve ser utilizvel, sem esforos indevidos, pelo tipo de

usurio para quem foi projetado. Isso significa que ele deve dispor de uma
interface apropriada com o usurio e de documentao adequada.
Atributos essenciais de um bom software (adaptado de Sommerville)

11
Crise do Software e o incio da Engenharia de Software

A crise do software, termo usado nos anos 70, referia-se s dificuldades do desenvolvimento
de software da poca. Por haver um rpido crescimento da demanda por software,
imaginava-se que com toda a complexidade no desenvolvimento, haveria uma forte crise.
Com a inexistncia da Engenharia de Software nessa poca, no havia tcnicas estabelecidas
para o desenvolvimento de sistemas que funcionassem adequadamente ou que pudessem ser
validadas.
J em 1988, AMBLER afirmava: Desenvolver software no somente modelar e escrever

cdigo. criar aplicaes que resolvam os problemas dos usurios. fazer isto dentro do
prazo, de forma precisa e com alta qualidade. Logo, com a crise de software, os desafios
para a criao da disciplina de Engenharia de Software eram muito grandes.
Alguns dos tpicos problemas que essa nova disciplina enfrentou foram:
Identificar adequadamente os requisitos do Sistema, ou seja, saber o que o

software deve fazer;
Que ferramentas, linguagem, sistema operacional usar;
Como diminuir os tempos e custos de desenvolvimento;
Prever falhas antes da entrega final;
Como fazer manuteno e controlar verses;
Dificuldades de prever o progresso durante o desenvolvimento;
Inexistncia de histrico, ou documentao, no desenvolvimento de Sistemas;
Comunicao com os usurios precria;
Conceitos quantitativos inexistentes tais como confiabilidade, qualidade e
reusabilidade;
Manuteno, no software existente, com difcil execuo.
12
Esse incio difcil da Engenharia de Software, com tantos desafios, gerou vrios paradigmas e
modelos de desenvolvimento. Iremos ver nas prximas unidades quais foram as formas que a
engenharia clssica veio a ajudar nesse difcil incio.
Desafios da Engenharia de Software

Atualmente os principais desafios da Engenharia de Software, conforme Sommerville so:
DESAFIOS
Descrio
O desafio do
legado
Ainda os grandes sistemas de software existentes foram

desenvolvidos no passado, e com importantes funes
corporativas. O desafio fazer a manuteno e atualizao desses
softwares a custos baixos e com qualidade.
O desafio da
heterogeneidade
Os sistemas exigem em ambientes distribudos por redes de

diferentes tipos de computadores e sistemas de apoio. O desafio
desenvolver tcnicas para construir softwares flexveis para lidar
com a heterogeneidade.
O desafio do
fornecimento
Nos dias atuais existe uma demanda enorme de sistemas que

sejam desenvolvidos no menor tempo possvel e com facilidade de
adaptao. O desafio fornecer sistemas cada vez maiores e
complexos com a qualidade desejada, e em curto espao de
tempo.
13
Wikipdia
http://pt.wikipedia.org/wiki/Crise_do_software
Responda, por escrito, as seguintes perguntas com os seus prprios

comentrios a respeito:
Quais so os atributos de um bom Software?
Quais so os desafios enfrentados pela Engenharia de Software?
14
NIDADE
Conceitos sobre a Engenharia de Software - O que Software ? A Importncia

do Software - SWEBOK
Objetivo: Abordar a Engenharia de Software e os seus principais tpicos (viso geral).
A Engenharia de Software basicamente tenta apresentar processos, ferramentas e mtodos
que permitam desenvolver de forma racional e controlvel um Sistema Computacional. Todo
o foco a Qualidade, utilizando um mtodo eficaz e o uso de ferramentas adequadas.
Caractersticas do software
desenvolvido/projetado por engenharia, no fabricado

No se desgasta, mas deteriora!! Veja a figura abaixo o comparativo entre a taxa
de falhas do hardware com as de software
Ainda hoje a maioria feita sob encomenda em vez de ser montada a partir de
componentes
Tipos de Software
Tempo real
Software bsico
Sistema de informao
Embutido
Tcnicos
Especialistas
Apoio deciso
Jogos
Apoio (processador de textos)
15
Mitos do Software
1 - J temos um manual repleto de padres e procedimentos para a construo de software.
Isso j suficiente para o pessoal do desenvolvimento.
2 - Meu pessoal tem ferramentas de ltima gerao, afinal de contas compramos os mais
novos computadores.
3 - Se ns estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o
atraso.
4 - Uma declarao geral dos objetivos suficiente para se comear a escrever programas,
podemos preencher os detalhes mais tarde.
5 - Os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser
facilmente acomodadas, porque o software flexvel.
6 - Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho
estar completo.
7 - Enquanto no tiver o programa funcionando, eu no terei realmente nenhuma maneira
de avaliar sua qualidade.
8 - A nica coisa a ser entregue em um projeto bem-sucedido o programa funcionando.
Importncia do Software
Um dos pontos fundamentais da importncia do software pelo seu uso cotidiano, aonde
praticamente no mundo moderno, inexiste a possibilidade de no utiliz-lo. E o outro ponto
pela manipulao da informao (dado - informao - conhecimento), e quem a tem possui
poder.
SWEBOK
O SWEBOK (Guide to the Software Engineering Body of Knowledge) o documento tcnico
desenvolvido com o apoio do IEEE (Instituto de Engenheiros Eltricos e Eletrnicos, tambm
popularmente chamado de I3E). Esse documento estabelece uma classificao hierrquica
16
dos tpicos tratados pela Engenharia de Software, onde o nvel mais alto so as reas do
Conhecimento.
As dez reas do Conhecimento tratadas pelo SWEBOK so:
Requisitos de Software
Projeto de Software
Construo de Software
Teste de Software
Manuteno de Software
Gerncia de Configurao de Software
Gerncia da Engenharia de Software
Processo de Engenharia de Software
Ferramentas e Mtodos da Engenharia de Software
Qualidade de Software
Importante ressaltar as diferenas entre o SWEBOK e o PMBOK. Estaremos detalhando

melhor o PMBOK na Unidade 28. Mas, somente mostrando genericamente o diferencial dos
dois, que enquanto o SWEBOK dirigido especificamente para a Engenharia de Software, o
PMBOK mais generalizado quanto a Gerenciamento de Projetos como um todo.
17
Wikipdia sobre o SWEBOK

http://pt.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge
Site do IEEE, e no Brasil
http://www.ieee.org/
http://www.ieee.org.br/
Navegue pelo site do SWEBOK (http://www.swebok.org/) e tente baixar

gratuitamente o documento PDF que contm todas as especificaes
tcnicas das dez reas do Conhecimento abordadas por essa
importante referncia na Engenharia de Software.
18
NIDADE
Modelos de Processo de Software - Paradigmas do desenvolvimento de

Software - Modelo Balbrdia - Modelo Cascata
Objetivo: Entender os principais modelos de processo de software.
Os Modelos de Processo de Software descrevem basicamente as principais etapas do
desenvolvimento de software, desde a produo at a sua prpria manuteno. Existem
vrios Modelos de Processo de Software, mas praticamente todos eles seguem o princpio das
trs principais macro-etapas:
Requisitos - o analista deve obter respostas a vrias perguntas junto aos usurios: O que
exatamente se espera que seja feito? Qual a abrangncia do software? Quais os limites, ou o
escopo do sistema? Por que se faz aquilo daquela forma? Quais as restries que existem nos
procedimentos e dados utilizados? E muitas outras.
Projeto/Desenvolvimento - o analista faz especificaes tcnicas detalhando a soluo
criada para atender ao usurio conforme os requisitos anteriores. Os programadores
codificam os programas em alguma linguagem de programao. Devem-se testar os
programas exaustivamente para atingir um alto nvel de qualidade, e aps isso liber-los para
o uso.
Implantao/Manuteno - na implantao do software podem ocorrer vrios problemas
no previstos nas fases anteriores. E a manuteno permanecer durante toda sua vida til e
pode ocorrer motivada por 03 fatores: a correo de algum problema existente no software,
sua adaptao decorrente de novas exigncias (internas ou externas da empresa) e algum
melhoramento funcional que seja incorporado ao software.
19
Cabe ressaltar que no existe um consenso sobre o nome mais adequado para Modelos de
Processo de Software. Os principais autores se referem a esse mesmo conceito com os
seguintes nomes:
Modelos de Ciclo de Vida de Software;

Modelos Prescritivos de Processo
Paradigmas do Ciclo de Vida;
Paradigmas do Desenvolvimento de Software;
Modelagem do Ciclo de Vida.
Modelo Balbrdia
Como falamos anteriormente, no incio da computao, poucos programadores seguiam
algum tipo de metodologia baseando-se, em sua maioria, na prpria experincia. Era o que
chamamos hoje de Modelo Balbrdia, sistemas desenvolvidos na informalidade sem
nenhum tipo de projeto ou documentao.
Nesse modelo, o software tende a entrar num ciclo de somente duas fases: o de
implementao e de implantao. E os ajustes ao software para atender aos novos requisitos,
sempre so em clima de urgncia e de stress, motivados por vrios fatores, e principalmente
por presso poltica.
20
Portanto, havia a necessidade se criar um Ciclo de Vida mais inteligente para o

desenvolvimento de Software. Ou seja, um Ciclo de Vida semelhante prpria natureza,
com incio, meio e fim bem definidos.
Modelo Cascata
Essa foi a proposta do Modelo Cascata (ou do ingls Waterfall), da dcada de 70. Onde
cada etapa do ciclo de vida pressupe atividades que devem ser completadas antes do incio
da prxima etapa. Ou ainda, um modelo basicamente de atividades sistemticas e
sequenciais onde para cada etapa cumprida, segue-se a etapa imediatamente posterior,
como se fosse uma cascata.
O Modelo Cascata extremamente clssico e antigo, por isso tambm chamado de Ciclo de
Vida Clssico. Originou-se dos velhos modelos de engenharia na elaborao de projetos. E na
verdade, hoje em dia, somente uma grande referncia.
Vivemos num mundo de atividades paralelas, e esse modelo de atividades sequenciais,
provocaria demoras excessivas, esperas indesejadas e problemas quando houvesse
necessidade de voltar em etapas anteriores.
Repare nas duas figuras abaixo. Embora as duas refiram-se ao Modelo Cascata observe como
a terminologia dessas imagens distinta. Cada etapa praticamente tem um nome diferente
em cada figura. Isso ocorre devido a no existir um padro para esse modelo. Embora sendo
clssico, para cada autor existe uma interpretao de cada etapa e criado um nome
distinto.
21
O prprio Pressman, outro papa da Engenharia de Software, na ltima edio do seu famoso
livro de Engenharia de Software, alterou os nomes da quinta edio, colocando o nome
dessas fases respectivamente de: Comunicao, Planejamento, Modelagem, Construo e
Implantao.
Wikipdia
http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
http://pt.wikipedia.org/wiki/Modelo_em_cascata
http://www.macoratti.net/proc_sw1.htm
Com base nas duas ltimas imagens dessa unidade, faa uma
possvel relao entre os nomes das etapas e com a proposta citada
pelo Pressman. Ou seja, a primeira etapa da primeira figura seria
equivalente a que etapa da segunda imagem, e com a qual do
Pressman??
22
NIDADE
Paradigmas do Desenvolvimento de Software (continuao) - Modelo

Incremental - Prototipao
Objetivo: Entender os principais modelos de desenvolvimento de software.
Modelo Incremental
Como vimos anteriormente o tradicional Modelo Cascata mais um modelo terico do que
prtico. Na prtica o usurio quer sempre o Sistema para ontem, e com qualidade. Para
tanto, o Modelo Incremental parte do pressuposto que prefervel o usurio receber o
Sistema em partes, permitindo que esses recursos j sejam utilizados, enquanto os demais
esto sendo desenvolvidos.
O Modelo Incremental, ou Interativo, desenvolvido com o conceito de verses. Nesse
modelo o sistema ser especificado na documentao dos requisitos, e quebrado em
subsistemas por funcionalidades. As verses so definidas, comeando com um pequeno
subsistema funcional e ento adicionadas mais funcionalidades a cada verso. Pode-se ento
dizer que o Modelo Incremental chega lentamente funcionalidade total, por meio dessas
novas verses.
Importante observar a diferena entre INTERATIVO e ITERATIVO. As duas palavras embora

com escrita extremamente parecidas, e muitas utilizadas em Informtica, possuem
significados distintos.
Quanto palavra ITERATIVA que significa, pelo prprio Aurlio, diz-se de procedimento
(como algoritmo, programa, etc.) que se baseia no uso ou aplicao da iterao. Por sua vez
23
ITERAO possui o significado de: Processo de resoluo (de uma equao, de um

problema) mediante uma seqncia finita de operaes em que o objeto de cada uma o
resultado da que a precede.
Ainda do prprio Aurlio podemos extrair a definio de INTERATIVO de, ou relativo a
sistemas ou procedimentos computacionais, programas, etc. em que o usurio pode (e, por
vezes, necessita) continuamente intervir e controlar o curso das atividades do computador,
fornecendo novas entradas (de dados ou comandos) medida que observa os efeitos das
anteriores. Portanto, no nosso caso especfico utilizamos o processo INTERATIVO, e no
ITERATIVO.
Prototipao
A Prototipao tem o mesmo objetivo que uma maquete para um arquiteto (ver figura
abaixo). Antes da entrega final do sistema desenvolve-se rapidamente um esboo para
melhorar o entendimento de desenvolvedores e clientes sobre todas as problemticas das
questes.
Dentro dessa viso, o projeto passa por vrias investigaes para garantir que o
desenvolvedor, usurio e cliente cheguem a um consenso sobre o que necessrio e o que
deve ser proposto. Como muitos usurios no possuem uma viso ampla sobre a Tecnologia,
esse mtodo de desenvolvimento bastante interessante, permitindo que o usurio interaja
significativamente no Sistema.
A prototipao um processo que possibilita desenvolvedor e usurios a examinarem
antecipadamente os requisitos. Com isso se reduz os riscos e as incertezas do
desenvolvimento.
24
Basicamente as etapas de desenvolvimento desse modelo so:

1. Comear com um conjunto bem simples de requisitos fornecidos pelos clientes e
usurios;
2. Clientes e usurios fazem testes e experimentaes, e assim que eles decidem o que
querem, os requisitos so revisados, alterados, detalhados, documentados e o sistema
passa a ser codificado;
3. Novamente as alternativas so apresentadas e discutidas com os usurios, e voltamos
para a etapa dois, at a entrega definitiva do Sistema.
Logo, este modelo propicia duas grandes vantagens: velocidade de desenvolvimento no
sentido de propiciar ao usurio uma viso mais real do software que se est projetando (o
usurio poder enxergar as telas e os relatrios resultantes do software) e o envolvimento
direto do usurio na medida em que o desenvolvimento do software evolui, o usurio passa a
ser um co-autor do desenvolvimento.
Wikipdia
http://pt.wikipedia.org/wiki/Desenvolvimento_interativo_e_incremental
http://pt.wikipedia.org/wiki/Prototipac%C3%A3o
Quais as diferenas bsicas entre o Modelo Incremental e a

Prototipao??
Qual a diferena entre ITERATIVO e INTERATIVO??
Quais dos dois modelos explicados nessa Unidade voc escolheria
para o desenvolvimento de um Sistema?!?
25
NIDADE
Paradigmas do desenvolvimento de Software (continuao) - Modelo Espiral Modelos mistos e caractersticas genricas
Objetivo: Relacionar os vrios modelos de desenvolvimento de software.
Modelo Espiral
Este modelo se confunde com o de Prototipagem. Mas em princpio mais adequado para
sistemas mais complexos, e que exigem um alto nvel de interaes com os usurios para
possibilitar a abordagem de todos os problemas desse Sistema.
Foi criado por Barry W. Boehm, ainda em 1988, e ao invs de representar o processo de
software como uma sequncia de atividades, a exemplo do Modelo Cascata, ele
representado atravs de uma espiral (veja figura abaixo).
Cada ciclo da espiral representa uma fase do processo de software. Na parte mais interna
relaciona-se o incio da viso da viabilidade do sistema. E a cada ciclo, passando por vrias
etapas, vai evoluindo a visibilidade do sistema como um todo.
26
O Modelo Espiral basicamente dividido em quatro setores:

SETORES
Descrio
ATIVAO
Definem-se os objetivos especficos, identificam-se as restries

para o processo e preparado um plano de gerenciamento
detalhado. Identificam-se tambm os riscos sem analis-los
profundamente (foco da prxima fase).
ANLISE de RISCOS
Com base nos riscos identificados na fase anterior so realizadas

anlises detalhadas, e tomadas providncias para amenizar
esses riscos. Criam-se vrias verses de prottipos para apoiar
essa fase.
DESENVOLVIMENTO
Fundamentado pelas fases anteriores, escolhe-se o modelo mais

adequado para o desenvolvimento do Sistema. A bagagem
profissional e a vivncia do desenvolvedor em outros sistemas
so estratgicas para essa fase. Dependendo da complexidade
do Sistema, s vezes, necessria a presena de um consultor
especialista.
PLANEJAMENTO
O projeto revisto nessa fase, e tomada uma deciso de

realizar um novo ciclo na espiral ou no. Se continuar com o
aperfeioamento do Sistema, traado um plano para a prxima
fase do projeto.
Um diferencial nesse modelo comparado com outros, a explcita considerao de riscos

dentro do projeto como um todo. Para tanto, criou-se uma fase especfica de Anlise de
Riscos nesse modelo.
Modelos Mistos e outros

Existem mais modelos fora os clssicos que ns vimos anteriormente. Alguns no deixam de
ser um mix desses modelos. Misturam dois ou mais conceitos dos modelos estudados.
Mas gostaria de concentrar nos modelos mais atuais, e que so aplicados hoje em dia. Um
deles o Modelo RAD (Rapid Application Development). Em contraposto aos modelos
clssicos que ficavam na tentativa de tentar abordar todos os principais tpicos, o RAD focou
na varivel tempo.
27
Ele um processo de software incremental que enfatiza um ciclo de desenvolvimento curto

(Pressman). A estratgia para isso o uso da abordagem de construo baseada em
componentes. Com isso o desenvolvimento completo de um Sistema, de relativa
complexidade, chega a atingir 60 a 90 dias.
Os pontos a serem ressaltados nesse modelo que se o sistema no puder ser
adequadamente modularizado, a construo de componentes necessrios ao RAD ser
problemtica. E outro ponto que o RAD pode no ser adequado quando os riscos tcnicos
so altos, por exemplo, se existir a necessidade de uma aplicao usufruir tecnologias novas
no dominadas pela equipe.
Outro modelo o Processo Unificado Racional, RUP em ingls, que utiliza maciamente do
UML (Unified Modeling Language). Utilizando mtodos e linguagens de programao
orientada a objetos, aprimora o modelo RAD. A nfase desse modelo na arquitetura de
software. Veremos mais detalhes deste modelo na unidade 10.
Wikipdia
http://pt.wikipedia.org/wiki/Modelo_em_espiral
Na figura apresentada existe um erro j discutido em unidades

anteriores, com base nisso qual seria esse erro?!?
Para voc fazer uma reviso geral do que vimos nessas ltimas
unidades, leia o texto sobre os Modelos de Ciclo de Vida:
http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida
28
NIDADE
Paradigmas da Engenharia de Software: Processo, Mtodos e Ferramentas

Objetivo: Entender os elementos dos paradigmas da Engenharia de Software.
A Engenharia de Software uma tecnologia em camadas (Pressman). Conforme a figura a
seguir, podemos observar que todo o foco desta disciplina na qualidade, que a base de
todas as camadas. O alicerce da Engenharia de Software, para tal, fica sendo no PROCESSO,
aonde a partir da temos os MTODOS a serem aplicados, e as FERRAMENTAS como apoio a
todo esse esquema. O arcabouo deste conjunto conhecido paradigma de Engenharia de
Software.
Processo
O Processo de Software um conjunto de atividades, mtodos, prticas e transformaes
ordenadas com a inteno de atingir a qualidade do software. Sua meta fundamental
entregar, de maneira eficiente e previsvel um produto de software capaz de atender as
necessidades de negcio, definidas pela anlise de requisitos, dos usurios.
29
Pode-se tambm definir sucintamente como um conjunto completo de atividades necessrias

para transformar os requisitos do usurio em um produto de qualidade de software. Um
processo define QUEM est fazendo O QUE, QUANDO e COMO para atingir esse objetivo.
Mtodos
Mtodo uma palavra que vem do grego mthodos, que significa caminho para se chegar a
um fim. O termo metodologia bastante controverso nas cincias em geral e na Engenharia
de Software em particular. Muitos autores parecem tratar metodologia e mtodo como
sinnimos, porm seria mais adequado dizer que uma metodologia envolve princpios
filosficos que guiam uma gama de mtodos que utilizam ferramentas e prticas
diferenciadas para realizar algo.
As metodologias de Engenharia de Software objetivam ensinar como fazer para construir
softwares. Esses mtodos incluem atividades de modelagem, construo de programas,
testes e manuteno. Na Engenharia de Software as principais abordagens de Metodologias
so:
Metodologia Estruturada: a mais clssica das abordagens. Utiliza como ferramental

Dicionrio de Dados, Diagrama de Fluxo de Dados (DFD), e o Modelo Entidade
Relacionamento (MER)
Metodologia Orientada a Objetos: na Unidade 10 abordamos sobre RUP (veja maiores

detalhes nessa Unidade).
30
Metodologias de Desenvolvimento gil: Existem varias metodologias que podem ser

consideradas como abordagens geis: XP, ASD, DSDM, Scrum, Crystal, FDD, AM entre
outras. Veremos com maiores detalhes essas Metodologias nas Unidades 16 e 17.
Ferramentas
Ferramenta uma palavra que vem do latim ferramentum significando qualquer utenslio
empregado nas artes e ofcios (Aurlio). As ferramentas de Engenharia de Software
fornecem apoio automatizado, ou semi-automatizado, para o processo e para os mtodos.
Quando ferramentas so integradas de modo que a informao criada por uma ferramenta
possa ser usada por outra, um sistema de apoio ao desenvolvimento de software, chamado
de engenharia de software apoiada por computador (CASE), estabelecido (Pressman).
Wikipdia
http://pt.wikipedia.org/wiki/Engenharia_de_software#.
C3.81reas_de_Conhecimento
http://pt.wikipedia.org/wiki/Ferramenta_CASE
Aps a leitura dessa unidade, e pelo material na Web, quais so as suas

impresses quanto a diviso da Engenharia de Software em Processo,
Mtodos e Ferramentas ?!?
31
NIDADE
Caractersticas de um bom processo - Caractersticas de um bom ambiente de

desenvolvimento
Objetivo: Contextualizar um ambiente de desenvolvimento de software.
Processos de Engenharia de Software
Processo de software, ou processo de Engenharia de Software, uma sequncia coerente de
prticas, que objetiva o desenvolvimento ou evoluo de sistemas de software. Estas prticas
englobam as atividades de especificao, projeto, implementao, testes e caracterizam-se
pela interao de ferramentas, pessoas e mtodos.
As principais caractersticas de um bom processo so:
Configurvel para diferentes organizaes.

Adaptvel para diferentes tamanhos e tipos de projetos.
Bem definido, gerencivel e repetvel.
Com nomenclatura universal e mtricas para planejamento e gerenciamento do
projeto.
Integrado com ferramentas que o suportem.
32
Caractersticas de um bom ambiente de desenvolvimento
Processo de desenvolvimento definido.

Integrao entre processo e ferramentas.
Integrao entre ferramentas.
Gerenciamento de configurao.
Gerenciamento de mudanas.
Gerenciamento de projetos.
Automao de testes funcionais e de desempenho.
Documentao consistente.
E outros.
33
Wikipdia
Pesquise em sua empresa, ou na de um colega, como constitudo o

ambiente de desenvolvimento da equipe de Sistemas. Como a sua
infraestrutura? Que ferramental possui para desenvolver?
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua
SALA DE AULA e faa a Atividade 1 no link ATIVIDADES.
34
NIDADE
10
Introduo ao RUP (Rational Unified Process) - Caractersticas - Fases e

Workflows
Objetivo: Conceituar RUP e suas principais caractersticas.
RUP (Rational Unified Process) usa a abordagem da orientao a objetos em sua concepo e
projetado e documentado utilizando a notao UML (Unified Modeling Language) para
ilustrar os processos em ao. Utiliza tcnicas e prticas aprovadas pelo mercado.
Atualmente o RUP um produto desenvolvido e mantido pela Rational Software (Diviso
IBM). Sistemas concebidos por esse processo normalmente so desenvolvidos um uma
linguagem de programao orientada a objetos, como Java ou C++.
As principais caractersticas do RUP so:

Desenvolvimento Interativo
Gerncia de requisitos
Uso de arquitetura baseada em componentes
Modelagem visual
35
Controle contnuo da qualidade

Gerncia de mudanas
A soluo iterativa requer uma compreenso crescente do problema por meio de

aperfeioamentos sucessivos e de desenvolvimento incremental em vrios ciclos.
Modelagem
A abstrao do sistema de software atravs de modelos que o descrevem um poderoso
instrumento para o entendimento e comunicao do produto final que ser desenvolvido. A
maior dificuldade nesta atividade est no equilbrio entre simplicidade (favorecendo a
comunicao junto ao usurio) e a complexidade (favorecendo a preciso com detalhes) do
modelo. comum a utilizao de linguagens para modelagem como UML.
Fases
Estruturar um projeto junto dimenso de tempo envolve a adoo das seguintes fases
baseadas em tempo (veja maiores detalhes na tabela e figura abaixo):
FASES
Iniciao
(Inception)
Elaborao
(Elaboration)
Construo
(Construction)
Transio
(Transition)
Descrio
Estabelece a viso, o escopo e o plano inicial para o projeto.

Projeta, implementa e testa a arquitetura do sistema e completa
o plano do projeto.
Desenvolve a primeira verso do sistema.
Implantar o produto no ambiente de produo.
36
Workflow de Processo
Estruturar um projeto junto dimenso de componente de processo inclui as seguintes
atividades:
ATIVIDADES
Descrio
Modelagem do negcio Descreve o negcio atravs de casos de uso de negcio.

Requisitos
Narrativa da viso do sistema. Descrio das funes do

sistema.
Anlise e Projeto
Descrio de como o sistema ser realizado na etapa de

implementao.
Implementao
Produo do cdigo que resultar em um sistema

executvel.
Testes
Verificar a integrao entre todos os componentes de

software, identificar e corrigir erros de implementao.
Distribuio
Gerar um release do produto. Entrega do produto e

treinamento dos usurios.
37
Workflow de Suporte
ATIVIDADES
Descrio
Gesto de Projetos
Especifica um conjunto de princpios a aplicar na gesto

de projetos no nvel da alocao de recursos,
planejamento, identificao e gesto de riscos, etc.
Gesto de
Configurao e
Mudana
Controla as mudanas e mantm a integridade dos

artefatos do projeto.
Definio do Ambiente
Cobre a infraestrutura necessria para desenvolver um

sistema (seleo de ferramentas, definio das regras de
negcio, interface, testes, etc)
Wikipdia
http://pt.wikipedia.org/wiki/Rational_Unified_Process
http://pt.wikipedia.org/wiki/UML
Leia adicionalmente o interessante artigo sobre a importncia do UML

nos dias atuais atravs do seguinte link:
http://www.anacristinamelo.eti.br/artigos/Artigo_Buscando_Novos_
Caminhos.pdf
38
NIDADE
11
Modelos de Maturidade CMM (Capability Maturity Model)

Objetivo: Conceituar Modelos de Maturidade e a sua importncia na Engenharia de Software.
Modelos de Maturidade
O conceito de Modelo de Maturidade de Capacitao para Software, que um metamodelo
de PROCESSO, foi desenvolvido pela Carnegie Mellon University atravs do seu rgo SEI
(Software Engineering Institute). O SEI um centro de pesquisa e desenvolvimento criado,
em 1984, pelo Departamento de Defesa dos Estados Unidos. Podemos definir Capacitao
para Software como sendo a habilitao que a organizao tem em sistematicamente
produzir software possuindo a qualidade esperada, dentro dos prazos concordados e com os
recursos alocados.
Atente para o grfico apresentado. Ele representa que quanto maior a capacitao, menor
ser a variao dos erros de estimativa (de custos, prazos, etc.) em torno da mdia. Ou seja,
enquanto no grfico da esquerda as estimativas fogem muito da mdia, o da direita as
variaes em relao mdia foram aprimoradas aps a implantao do CMM (nvel 5).
O CMM (Capability Maturity Model) o mais famoso representante desse conceito. Ele
basicamente uma metodologia de diagnstico e avaliao da maturidade da capacitao em
desenvolvimento de softwares numa organizao (empresa ou instituio).
O objetivo maior do CMM determinar em que estgio de maturidade uma empresa est em
seu ciclo de desenvolvimento de software. Nasceu da necessidade do Departamento de
39
Defesa americano em como avaliar as empresas terceirizadas que desenvolviam softwares

para eles.
O uso de estratgia de melhoria de processos atravs de avaliao contnua, identificao de
problemas e suas devidas aes corretivas permite estabelecer cinco nveis de maturidade
(veja a tabela em seguida).
CMMi (Capability Maturity Model Integration) o modelo de maturidade surgido
recentemente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros
modelos de processos de melhoria corporativo. Somente por curiosidade, raras so as
empresas no mundo que conseguem atingir o nvel 5, a grande maioria fica nos estgios
iniciais. No Brasil, at o presente ano (2007), existiam somente 4 empresas que tinham
alcanado o nvel 5 do CMMi.
Estgios
Descrio
Nvel 1 Inicial
Catico, estgio aonde que a maioria das

empresas de software encontra-se.
Nvel 2 Repetitivo
Capacidade de repetir sucessos anteriores

atravs do acompanhamento de custos,
cronogramas e funcionalidades.
Nvel 3 Definido
O processo de software bem definido,

documentado e padronizado.
Nvel 4 Gerenciado
Realiza uma gerncia quantitativa e

qualitativa do processo de software e do
produto.
Nvel 5 Em Otimizao
Usa a informao quantitativa para

melhorar continuamente e gerenciar o
processo de software.
40
Para podermos visualizar melhor, de forma grfica, todos os nveis de maturidade e a

interao entre eles, podemos observar a figura a seguir:
Software Engineering Institute (SEI) da Universidade Carnegie Mellon

http://www.sei.cmu.edu/cmm/
Dentro do que foi visto nesta Unidade, como voc visualiza a sua
empresa dentro do conceito do CMM ? Em que estgio voc acredita
que ela esteja ?!?
41
NIDADE
12
Requisitos de Software - Requisitos Funcionais e no Funcionais - Requisitos

de Usurio e de Sistema
Objetivo: Identificar os vrios tipos de requisitos e suas definies.
muito comum que o cliente no saiba o que ele realmente deseja, que haja problemas na
comunicao e ainda que haja mudana constante desses requisitos. O termo requisito pode
ser utilizado na indstria de software tanto com o significado de algo abstrato, como
matematicamente formal. Para aprimorar esse conceito A.M.Davis ilustra o seguinte case em
seu livro Software requirements - objects, functions and states:
Se uma empresa deseja estabelecer com contrato para o desenvolvimento de um grande
projeto de software (para selecionar entre vrios fornecedores), ela tem de definir suas
necessidades de maneira suficientemente abstrata para que uma soluo no seja
predefinida. Os requisitos devem ser redigidos de modo que os diversos fornecedores (de
software) possam apresentar propostas, oferecendo, talvez, diferentes maneiras de atender
s necessidades organizacionais do cliente. Uma vez estabelecido um contrato (entre ambas
as partes), o fornecedor (que ganhou) precisa preparar uma definio de sistema para o
cliente, com mais detalhes, de modo que o cliente compreenda e possa validar o que o
software far. Esses dois documentos podem ser chamados de documentos de requisitos do
sistema.
As atividades de Anlise de Requisitos concentram-se na identificao, especificao e
descrio dos requisitos do sistema de software. Em resumo, requisito uma necessidade
que o software deve cumprir. H vrias interpretaes e classificaes sobre requisitos tais
como:
Tipos de Requisitos
Descrio
Requisitos do Usurio
So declaraes, em linguagem natural e tambm em

diagramas, sobre as funes que o sistema deve fornecer,
e as restries, sob as quais deve operar.
42
Requisitos de Sistema
(ou do desenvolvedor)
Estabelecem detalhadamente as funes e as restries

de sistema. O documento de requisitos de sistema,
algumas vezes chamado de especificao funcional, deve
ser preciso. Ele pode servir como um contrato entre o
comprador do sistema e o desenvolvedor do software.
Requisitos Funcionais
So declaraes de funes que o sistema deve fornecer,

como o sistema deve reagir a entradas especficas e como
deve se comportar em determinadas situaes. Em alguns
casos, os requisitos funcionais podem, de forma explcita,
declarar o que o sistema no deve fazer.
Requisitos no
Funcionais
So restries sobre os servios ou as funes oferecidos

pelo sistema. Entre eles destacam-se restries sobre o
processo de desenvolvimento, padres, entre outros.
Adaptado de Sommerville
Ressalta-se que essa classificao no to precisa, e at um pouco artificial. Ou seja, por

exemplo, um requisito de usurio relacionado proteo, aparenta ser um requisito no
funcional. No entanto, ao detalharmos esse requisito ele pode assumir uma abrangncia mais
tpica de um requisito funcional. Pois podemos necessitar de incluir recursos de autorizao
de usurios no sistema.
N o n - f u n c t io n a l
r e q u ir e m e n t s
P ro d u ct
E f f ic i e n c y
re q u ir e m e n t s
R e li ab il it y
U s ab il it y
P e r f o rm a n c e
O r g an iz a t io n a l
Po rt a b il it y
D e l iv e r y
S p a ce
E x te r n a l
I n t e ro p e r a b il it y
I m p l e m e n t a t io n
E t hi c a l
S t a n d ar d s
L e g is la t iv e
P r iv a c y
S a f e ty
43
Pela figura anterior, podemos observar como os Requisitos no Funcionais so bastante

abrangentes. Podem compreender desde requisitos ticos, como de desempenho ou mesmo
de interoperabilidade.
Wikipdia
http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos
Visite o site http://www.ic.unicamp.br/~ariadne/inf301/modulo2-v.pdf

e explore as informaes das transparncias com a temtica Extrao
de Requisitos.
44
NIDADE
13
Tcnicas de Anlise de Requisitos - O Documento de Requisitos de Software

Objetivo: Identificar um documento de requisito de software e suas tcnicas.
Tcnicas de Anlise de Requisitos
Existem 10 princpios bsicos, e engraados, sugeridos por Pressman, implementados por
ns, no processo de levantamento de requisitos junto aos usurios numa reunio presencial:
Princpio n 1: Escute, escute e escute.
Esta talvez seja a atitude mais importante na hora da captao dos requisitos de usurios.
Se associado ao princpio 5, transforma-se num ponto estratgico para que o usurio/cliente
perceba que voc est querendo entender todos os seus problemas.
Princpio n 2: Prepare-se bem antes de se comunicar.
Gere bastantes perguntas fundamentais resoluo e viso do negcio do usurio/cliente.
Alm de ser importante para essa atividade, todos gostam de responder questionamentos
sinceros sobre as suas atividades.
Princpio n 3: Deve existir um facilitador na reunio.
No interessante que o prprio analista seja o condutor dessa reunio. Existindo um
personagem como facilitador na reunio, ameniza problemas de discusses ou maus
entendidos. Seria praticamente um animador das discusses.
Princpio n 4: Foco da discusso num Desenho ou Documento, no nas pessoas.
Se a discusso por ventura ficar pessoal, deve-se sempre voltar o foco da reunio para um
desenho, documento ou mesmo sobre o processo envolvido. Isso abranda possveis conflitos
pessoais.
45
Princpio n 5: Faa sempre anotaes e documente as decises.

Por mais que no se queira a memria humana fraca, muito fraca. Portanto, deve-se
registrar o mximo das posies e informaes dos usurios/clientes. Voc ir se surpreender
no futuro como anotou vrias coisas que nem voc no lembrava mais. E isso ser muito
importante nos conflitos que ocorrem ao longo do projeto.
Princpio n 6: Buscar ao mximo a colaborao de todos.
Animosidades no ajudam a ningum. O bom humor ajuda muito nessa fase de
levantamento. Procurar ser agradvel e simptico ameniza a grande maioria dos problemas
pessoais. E por incrvel que parea, os problemas pessoais so os que mais atrapalham num
projeto.
Princpio n 7: Conserve-se focado, departamentalize sua discusso.
Discuta cada tema profundamente. Tente evitar questionar, ou discursar sobre vrios temas
simultaneamente. Vai eliminando a discusso tema a tema. A produtividade ir aumentar.
Princpio n 8: Se algo no estiver claro, sempre desenhe.
Como o velho provrbio diz: Uma imagem vale mil palavras. No existe a necessidade de
aplicar as tcnicas de modelagem nessa hora, mas com desenhos simples, mapas mentais,
transparncias do PowerPoint, quadros e imagens ajudam muito nessa fase do projeto.
DICA: visite o site www.mapasmentais.com.br para ver a tcnica que a prpria NASA utiliza
em seus projetos.
Princpio n 9: (a) Se voc concorda com algo, prossiga;
(b) Se voc no concordar com algo, prossiga;
(c) Se algo no estiver claro, e sem condies de esclarecer
naquele momento, prossiga.
H momentos que no adianta, como se diz no popular, dar murro em ponta de faca.
Prepare-se e aguarde o momento certo para voltar a tocar num tema polmico. O uso da
criatividade, na abordagem de um tema desse tipo, super estratgico.
Princpio n 10: Negociar sempre no ganha-ganha.
Existem vrias posturas numa negociao entre dois personagens (perde-perde, ganhaperde, perde-ganha e ganha-ganha). A melhor relao o ganha-ganha. Essa a postura
dos vencedores. Ou seja, conduzida a soluo de conflitos de tal forma criativa e rica em
oportunidades, que os dois lados ganham na negociao.
DICA: o site http://www.golfinho.com.br/artigospnl/artigodomes1299.asp apresenta vrias
dicas pessoais sobre o processo de negociao ganha-ganha.
46
O Documento de Requisitos de Software

O Documento de Especificao de Requisitos de Software pode variar nos detalhes de
empresa para empresa, mas normalmente possui os seguintes campos:
Definio do Contexto
Definio de Requisitos
o Requisitos Funcionais
o Requisitos de Interface
o Requisitos no Funcionais
Anlise de Risco
Anexos
Wikipdia
http://pt.wikipedia.org/wiki/Requisitos_de_Software
Veja o documento de Especificao de Requisitos de Software em

http://www.ic.unicamp.br/~ariadne/inf301/doc-requisitos.pdf e tente voc
mesmo gerar um documento com base num Sistema genrico (um
sistema hipottico, ou um sistema que voc est trabalhando, ou ainda
um sistema que precisaria ser desenvolvido, etc.).
47
NIDADE
14
Processos de Engenharia de Requisitos - Estudos de Viabilidade

Objetivo: Conceituar os processos de engenharia de requisitos e a viabilidade tcnica.
A Engenharia de Requisitos um processo que envolve todas as atividades exigidas para
criar e manter o Documento de Requisitos de Sistema (Sommerville). Pela imagem logo
abaixo podemos observar as quatro atividades genricas de alto nvel (caixas arredondadas):
Estudo de Viabilidade, Obteno e Anlise de Requisitos, Especificao de Requisitos e
Validao de Requisitos.
Segundo Rumbaugh, alguns analistas consideram a Engenharia de Requisitos como um
processo de aplicao de um mtodo estruturado, como a anlise orientada a objetos. No
entanto, a Engenharia de Requisitos possui muito mais aspectos do que os que so
abordados por esses mtodos.
Processo de Engenharia de Requisitos conforme Sommerville
48
Estudos de Viabilidade
O primeiro processo a ser realizado num Sistema novo o Estudo de Viabilidade. Os
resultados deste processo devem ser um relatrio com as recomendaes da viabilidade
tcnica ou no da continuidade no desenvolvimento do Sistema proposto.
Basicamente um estudo de viabilidade, embora seja normalmente rpido, dever abordar
fundamentalmente as seguintes questes:
O Sistema proposto contribui para os objetivos gerais da organizao?

O Sistema poder ser implementado com as tecnologias dominadas pela equipe
dentro das restries de custo e de prazo? Ou precisaria de treinamentos
adicionais?
O Sistema pode ser integrado, e compatvel com os outros sistemas j em
operao?
Wikipdia
http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos
Como estamos explorando constantemente o WIKIPDIA, queremos que

voc entre no site http://pt.wikipedia.org/wiki/Engenharia_de_software e
veja o que voc pode aprimorar e contribuir para melhorar cada vez mais
essa fantstica enciclopdia virtual.
49
NIDADE
15
Modelagem UML: Unified Modeling Language Linguagem de Modelagem

Unificada
Objetivo: Explicar o processo de modelagem utilizando o UML.
O UML (Unified Modeling Language - Linguagem de Modelagem

Unificada) um padro para a modelagem orientada a objetos.
uma linguagem de diagramao ou notao para especificar,
visualizar e documentar modelos de sistemas de software Orientados
a Objeto. O UML controlado pela OMG (Object Management Group OMG). Veja, na figura abaixo, a rvore de diagramas do UML.
DICA: tenha a oportunidade de conhecer o site da OMG em www.uml.org
Principais DIAGRAMAS
Diagrama de Caso de
Uso
Diagrama de Classe
Descrio
Mostra atores (pessoas ou outros usurios do sistema),

casos de uso (os cenrios onde eles usam o sistema), e
seus relacionamentos.
Diagrama as classes e os relacionamentos entre elas.
50
Diagrama de Sequncia
Diagrama de
Colaborao
Diagrama de Estado
Diagrama de Atividade
Diagrama de
Componente
Diagrama de
Distribuio
Mostra objetos e uma sequncia das chamadas do mtodo

feitas para outros objetos.
Apresenta objetos e seus relacionamentos, colocando
nfase nos objetos que participam na troca de mensagens.
Exibe estados, mudanas de estado e eventos em um
objeto ou em uma parte do sistema.
Apresenta as atividades e as mudanas de uma atividade
para outra com os eventos ocorridos em alguma parte do
sistema.
Mostra os componentes de programao de alto nvel
(como KParts ou Java Beans).
Destaca as instncias dos componentes e seus
relacionamentos.
Os use-cases so cada vez mais utilizados para a obteno de requisitos, e so uma

caracterstica fundamental na notao UML. So tcnicas baseadas em cenrios para a
obteno de requisitos. Os use-cases identificam os agentes envolvidos numa interao e o
tipo dessa interao. Veja exemplo abaixo.
Diagramas de Sequncia podem ser utilizados para acrescentar informaes a um use-case.

Esses diagramas mostram os agentes envolvidos na interao, os objetos dentro do sistema
com os quais eles interagem, e as operaes que esto associadas a esses objetos. A
imagem abaixo ilustra isso.
51
Wikipdia
http://pt.wikipedia.org/wiki/UML
http://pt.wikipedia.org/wiki/Caso_de_uso
http://pt.wikipedia.org/wiki/Casos_de_Uso
Leia o excelente artigo que mostra um estudo de caso aplicado

modelagem UML:
http://www.cefetsp.br/edu/sinergia/6p10c.html
52
NIDADE
16
Metodologias de Desenvolvimento geis de Software: XP - FDD e DSDM

Objetivo: Abordar as vrias metodologias geis e suas aplicaes
Atravs do Manifesto for Agile Software Development (Manifesto para Desenvolvimento gil
de Software) criado em 2001 por Kent Beck, e mais 16 notveis desenvolvedores, se
reuniram para defender as seguintes regras:
Estamos descobrindo maneiras melhores de desenvolver software

fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse
trabalho, passamos a valorizar:
Indivduos e interao entre eles mais que processos e

ferramentas;
Software em funcionamento mais que documentao
abrangente;
Colaborao com o cliente mais que negociao de
contratos;
Responder a mudanas mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os

itens esquerda.
DICA: visite o site do MANIFESTO GIL em http://www.agilemanifesto.org/
Portanto, com base no Manifesto gil, chega-se aos seguintes princpios bsicos:
Simplicidade acima de tudo;
Rpida adaptao incremental s mudanas;
Desenvolvimento do software preza pela excelncia tcnica;
Projetos de sucesso surgem atravs de indivduos motivados, e com uma

relao de confiana entre eles;
Desenvolvedores cooperam constantemente e trabalham junto com os

usurios/clientes;
53
Atender o usurio/cliente, entregando rapidamente e continuamente

produtos funcionais em curto espao de tempo (normalmente a cada 2
semanas);
Software funcionando a principal medida de progresso;
Mudanas no escopo, ou nos requisitos, do projeto no motivo de

chateao;
A equipe de desenvolvimento se auto-organiza, fazendo ajustes

constantes em melhorias.
Esse Manifesto ocorreu para ser um contraponto as Metodologias de Desenvolvimento

Prescritivas. Ou seja, enquanto o RUP (visto na Unidade 10) extremamente rgido com altos
nveis de controle, e forte documentao, as metodologias geis caminham ao contrrio.
Destacamos que, mesmo assim, ela no inflige a uma slida prtica da Engenharia de
Software.
No grfico anterior vemos num extremo o RUP enfatizando os controles, e uma poltica de
trabalho rgida. Ele mais interessante de ser utilizado com equipes grandes de
desenvolvimento. Na outra ponta temos o XP, que veremos a seguir, sinalizando maior
liberdade e mais adequada para equipes pequenas. E num ponto intermedirio o FDD, que
veremos no final desta Unidade, como um modelo conciliador dessas duas estratgias.
Um dos pontos de destaque na Metodologia gil a liberdade dada para as equipes de
desenvolvimento. A declarao de Ken Schwaber define isso da seguinte forma: A equipe
seleciona quanto trabalho acredita que pode realizar dentro da iterao, e a equipe se
compromete com o trabalho. Nada desmotiva tanto uma equipe quanto algum de fora
assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitao das
responsabilidades de cumprir os compromissos que ela prpria estabeleceu.
54
XP (Extreme Programming)
O modelo gil mais conhecido o XP (Extreme
Programming). Ele usa preferencialmente a
abordagem orientada a objetos.
O XP inclui um conjunto de regras e prticas que
ocorrem no contexto de quatro atividades (veja a
figura ao lado):
Planejamento
Projeto
Codificao
Teste
Existe uma grande nfase ao trabalho em duplas,

no qual um analista mais experiente trabalha com
um novato. Enquanto o mais jovem trabalha na
programao o mais antigo vai revisando o cdigo.
Dessa forma ao mesmo tempo desenvolve-se a
equipe, e melhora-se automaticamente a
qualidade do cdigo fonte gerado.
FDD Feature Driven Development

O FDD (Desenvolvimento guiado por Caractersticas), concebido por Peter Coad, teve como
premissa criar um modelo prtico de processo para a Engenharia de Software orientado a
objetos.
No entanto, Stephen Palmer e John Felsing aprimoraram o modelo descrevendo um processo
gil e adaptativo que pode ser aplicado a projetos de software tanto a projetos de mdio
como de grande porte.
Dentro do contexto do FDD, o significado de caracterstica vem a ser uma funo,
relativamente pequena, acertada com o cliente que pode ser implementada em menos de
duas semanas, com os seguintes benefcios:
Sendo as caractersticas pequenos blocos de funcionalidade, os usurios e

desenvolvedores tm melhor controle e entendimento de todo o processo.
Organizam-se as caractersticas em um agrupamento hierrquico relacionado
ao negcio, melhorando a viso para o usurio. E para os desenvolvedores
facilitando o planejamento de todo o projeto.
55
A equipe tem metas de desenvolvimento dessas caractersticas a cada duas

semanas.
O FDD enfatiza mais as diretrizes e tcnicas de gesto de projetos do que outros mtodos
geis. O projeto muito bem acompanhado, ficando claro para todos os envolvidos os
avanos e problemas que o Projeto vai sofrendo. Para tanto, o FDD define seis marcos de
referncia durante o projeto e implementao de uma caracterstica:
Travessia do projeto;
Projeto;
Inspeo do projeto;
Cdigo;
Inspeo do cdigo;
Promoo para a construo.
Wikipdia
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
Outros sites:
http://iscte.pt/~mms/events/agile_seminar/apresentacoes.htm
Dentro da sua empresa, ou na de amigos, verifique qual das estratgias

apresentadas nesta Unidade que melhor poderia ser utilizada. Se voc,
como empresrio, criasse uma empresa, qual das estratgias discutidas
voc adotaria?!?
56
NIDADE
17
Continuao das Metodologias de Desenvolvimento gil de Software: Scrum Crystal - ASD e AM

Objetivo: Abordar as vrias metodologias geis e suas aplicaes.
Scrum
O significado peculiar desse modelo de desenvolvimento gil vem do nome da atividade de
jogadores de rugby ao trabalharem fortemente juntos para deslocar a bola pelo campo. Foi
desenvolvida por Jeff Sutherland, ainda na dcada de 90. Seus princpios bsicos seguem o
manifesto gil.
Um ponto que se destaca nesse modelo so as Reunies Scrum. Sugere-se que sejam
realizadas diariamente por 15 minutos, mas com base em nossa realidade brasileira,
acreditamos que o perodo ideal seria semanal, com uma durao de 1 hora
(preferencialmente as sextas-feiras tarde).
So somente trs questes que so apresentadas para todos os envolvidos, e com excelentes
resultados. Todos devem apresentar suas respostas com base nas seguintes perguntas:
O que voc fez desde a ltima Reunio Scrum?

Que obstculos voc est encontrando que podemos ajudar?
O que voc planeja realizar at a prxima Reunio Scrum?
57
Crystal
Criado por Alistair Cockburn e Jim Highsmith com intuito de fazer uma analogia com os
cristais geolgicos que apresentam na natureza com a sua prpria cor, forma e dureza.
Destaca-se a manobrabilidade com o significado de um jogo cooperativo de inveno e
comunicao de recursos limitados, com o principal objetivo de entregar softwares teis
funcionando e com o objetivo secundrio de preparar-se para o jogo seguinte (Presman).
A famlia Crystal , na verdade, um conjunto de processos geis que se mostraram efetivos
para diferentes tipos de projeto. A inteno permitir que equipes geis selecionem o
membro da famlia Crystal mais apropriado para o seu projeto e ambiente.
ASD Adaptative Software Development

O ASD (Desenvolvimento Adaptativo de Software) foi proposto por Jim Highsmith, com o
intuito de ser uma tcnica para construo de sistemas e softwares complexos. O foco desse
modelo a colaborao humana e na auto-organizao da equipe de desenvolvimento. O
ciclo de vida de um ASD incorpora trs fases, detalhadas na tabela abaixo:
FASES
Descrio
Planejamento do ciclo adaptativo usa informaes de iniciao do

Especulao projeto para definir o conjunto de ciclos de verso (incrementos de
software) que sero necessrios para o projeto.
Os analistas precisam confiar um no outro para: criticar sem
animosidade, ajudar sem ressentimentos, trabalhar mais do que esto
Colaborao acostumados, potencializar suas habilidades, e comunicar problemas de
um modo que conduza ao efetiva.
medida que os membros de uma equipe ASD comeam a desenvolver
os componentes que fazem parte de um ciclo adaptativo, a nfase est
Aprendizado tanto no aprendizado quanto no progresso em direo a um ciclo
completo.
AM Agile Modeling
Conforme o site que se auto-intitula The Official
Agile Modeling (veja maiores detalhes, e vale a
pena visitar, em:
http://www.agilemodeling.com/) Scott W.
Ambler, seu criador, descreve a Modelagem gil
(AM) como sendo (adaptado por ns):
58
A Modelagem gil (AM) uma metodologia baseada na prtica, para

modelagem e documentao efetiva de sistemas baseados em software.
Modelagem gil uma coleo de valores, princpios e prticas de modelagem
de software que podem ser aplicados a um projeto de desenvolvimento de
software de modo efetivo e leve. Os modelos geis so mais efetivos do que
os modelos tradicionais, porque eles so suficientemente bons, no
precisando ser perfeitos !
Dos princpios mais importantes da Modelagem gil (AM), anunciados por Ambler,
destacamos os dois mais significativos:
Modelos Mltiplos: h muitos modelos e notaes diferentes que podem ser usados para
descrever softwares. Importante: apenas um pequeno subconjunto essencial para a maioria
dos projetos. A AM sugere que, para fornecer a viso necessria, cada modelo apresente um
aspecto diferente desse sistema e que apenas aqueles modelos que ofeream valor sua
pretensa audincia sejam usados.
Viajar Leve: essa expresso se refere aos turistas que para no ficar carregando pesadas
malas, adotam esse princpio. No caso, para a AM, ela dita que medida que o trabalho de
Engenharia de Software prossegue, conserve apenas aqueles modelos que fornecero valor
em longo prazo e livre-se do resto.
59
Wikipdia
http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
Outros sites:
http://www.heptagon.com.br/?q=scrum
Leia adicionalmente o interessante artigo em:

http://www.heptagon.com.br/?q=node/5 para ampliar o seu
conhecimento sobre as Metodologias geis. Termine essa atividade
revendo as principais caractersticas, diferenas e semelhanas que
existem entre os diversos modelos geis.
60
NIDADE
18
Engenharia de Projeto - Projeto Modular - Projeto de interface com o usurio

Objetivo: Apresentar as principais diretrizes para projetos e das interfaces com o usurio
O que Projeto de Software? Podem-se pegar as interessantes palavras de Mitch Kapor
para definir bem essa ao:
onde voc se instala com um p em dois mundos o mundo da
tecnologia e o mundo das pessoas e objetivos humanos e voc
tenta juntar os dois...
Portanto, um lugar de criatividade aonde os requisitos do usurio/cliente, as necessidades
do negcio, e as consideraes tcnicas se juntam na formulao de um produto ou sistema.
o momento mgico aonde o engenheiro de software modela, cria e constroi a estrutura de
todas as partes de um Sistema, antes dele mesmo existir. Veremos mais detalhes sobre
Gesto de Projetos na Unidade 28.
Projeto Modular
A Modularidade consiste na diviso do software em componentes nomeados separadamente
e endereveis, muitas vezes chamado de mdulos. Os mesmos so integrados para
satisfazer aos requisitos do Sistema (adaptado de Pressman). Veja a figura abaixo, aonde
apresentado os vrios mdulos do ERP da SAP.
61
Uma prtica de Engenharia de Software condenvel a construo de softwares monolticos.

Ou seja, um software composto de um nico e grande mdulo. Isso gera uma complexidade
global quanto ao nmero de caminhos de controle, intervalos de referencia, nmero de
variveis, que faz um programa ter uma baixa compreenso para todos.
Outro problema a manutenabilidade do Sistema. Com poucas pessoas compreendendo o
Sistema, mais difcil e custoso fica sendo a sua manuteno. Por outro lado, um software com
excesso de mdulos pode acarretar no mesmo erro. O bom senso novamente a melhor
resposta.
Projeto de interface com o usurio
Os computadores atuais fornecem uma interface chamada de GUI (Graphical User Interface Interface Grfica do Usurio), mas nem sempre foi assim. As primeiras verses eram 1D
(uma nica dimenso), aonde o usurio simplesmente alimentava um terminal que podia se
deslocar para a direita e esquerda. Atualmente temos os de 2D (duas dimenses), graas ao
mouse podemos deslocar o ponteiro por toda a tela. E como tendncia temos j as interfaces
3D (trs dimenses). Um bom exemplo seria o Second Life.
DICA: visite o SECOND LIFE no site americano www.secondlife.com .
Podemos ver na tabela abaixo, as diretrizes gerais para a elaborao de uma boa interface
com o usurio:
DIRETRIZES
Descrio
Familiaridade com o usurio
Deve utilizar termos e conceitos que tenham como base

a experincia das pessoas que vo utilizar o sistema.
62
Consistncia
Sempre que possvel, operaes semelhantes devem ser

ativadas da mesma maneira.
Mnimo de surpresa
Os usurios nunca devem ser surpreendidos com o

comportamento do Sistema.
Facilidade de recuperao
A interface deve incluir mecanismos para permitir aos

usurios a recuperao a partir de erros humanos.
Orientao do usurio
Na ocorrncia de erros fornecer feedback significativo, e

oferecer recursos sensveis ao contexto de ajuda.
Diversidade de usurios
A interface deve fornecer recursos de interao

apropriados a diferentes tipos de usurios do sistema.
Wikipdia
http://pt.wikipedia.org/wiki/Interface_%28ci%C3%AAncia_da
_computa%C3%A7%C3%A3o%29
http://pt.wikipedia.org/wiki/Interface_do_utilizador
http://pt.wikipedia.org/wiki/Interface_gr%C3%A1fica_do_utilizador
63
NIDADE
19
Arquiteturas de Sistemas Distribudos - Arquitetura de Multiprocessadores

Objetivo: Diferenciar as vrias e principais arquiteturas de sistemas
Os sistemas com base em Mainframes, ou seja, computadores de grande porte, na prtica
so Sistemas Distribudos. O conceito de Sistema Distribudo a conexo de vrias mquinas
iguais, ou mesmo diferentes, para processar um ou mais sistemas.
Os trs principais sistemas existentes atualmente so:
Sistemas pessoais
Sistemas embutidos
Sistemas distribudos
Nos primeiros temos como exemplo os editores de texto e as planilhas eletrnicas. Um

exemplo de Sistema embutido seria a ignio eletrnica, aonde num processador existe toda
uma lgica de controle.
As mais importantes caractersticas dos Sistemas Distribudos so:
CARACTERSTICAS
Descrio
Compartilhamento
de Recursos
Compartilha recursos de hardware e de software gerenciados por

computadores centrais, ou servidores.
Abertura
Pode-se facilmente incluir hardware e software de diferentes

fabricantes.
Concorrncia
Vrios processos podem operar ao mesmo tempo em diferentes

computadores na rede.
Escabilidade
Em princpio, pode-se aumentar infinitamente a capacidade dos

Sistemas distribudos, somente limitado pela capacidade de sua
rede.
Tolerncia a
Defeitos
Com a estrutura dos Sistemas Distribudos, h o potencial da

duplicao de informaes, evitando algumas falhas de hardware e
software.
64
Embora tendo complexidade alta, os usurios conseguem o que

querem do Sistema, e sem a necessidade de se inteirar dessa
complexidade.
Transparncia
Por outro lado, as principais desvantagens desse Sistema so:
Alta Complexidade
Segurana baixa
Dificuldade de Gerenciamento
Imprevisibilidade nos tempos de resposta
Veremos na prxima unidade os dois tipos de arquitetura de Sistemas Distribudos mais

importantes: a arquitetura cliente-servidor e a arquitetura de objetos distribudos. De um
modo geral os Sistemas Distribudos so desenvolvidos com o uso da abordagem orientada a
objetos.
Arquitetura de Multiprocessadores
65
O modelo mais simples de Sistema Distribudo a Arquitetura de Multiprocessadores. Essa

arquitetura, tpica de sistemas em tempo real, consiste em uma srie de diferentes processos
que podem ser executados em processadores distintos.
Os Sistemas de software compostos de vrios processos no so necessariamente sistemas
distribudos. Se mais de um processador estiver disponvel, ento a distribuio poder ser
implementada, mas os projetistas de sistema no precisam sempre considerar as questes de
distribuio durante o processo de projeto. A abordagem de projeto para esse tipo de sistema
essencialmente aquela utilizada em sistemas de tempo real.
Wikipdia
http://pt.wikipedia.org/wiki/Computa%C3%A7%
C3%A3o_distribu%C3%ADda
66
NIDADE
20
Arquitetura cliente/servidor - Arquitetura de objetos distribudos

Objetivo: Apresentar as caractersticas das principais arquiteturas
Arquitetura cliente-servidor
Pela definio de Orfali e Harkey, em uma arquitetura cliente-servidor (client/server), uma
aplicao modelada como um conjunto de servios que so fornecidos por servidores e um
conjunto de clientes que utilizam desses servios. Veja o modelo lgico de uma arquitetura
cliente-servidor distribuda na figura abaixo.
c3
c2
c4
c12
c11
c1
s1
Server process
s4
c10
c5
Client process
s2
c6
c7
s3
c9
c8
Um projeto de sistema cliente-servidor deve refletir a estrutura lgica da aplicao que est
sendo desenvolvida (Sommerville). O tipo de arquitetura cliente-servidor mais utilizada em
aplicaes de baixa complexidade a arquitetura cliente-servidor de duas camadas. Nessa
situao a aplicao reside em um ou mais servidores, e um conjunto de clientes usufruindo
desse servio.
Existem basicamente dois tipos: Thin client, ou cliente magro, e Fat client (s vezes
chamado de thick client), ou cliente gordo. No primeiro modelo todo o processamento
realizado no servidor. A segunda estrutura mais complexa e mais comum. O servidor
67
responsvel somente pelo gerenciamento de dados. E nos clientes implementada a lgica

da aplicao e as interaes com o usurio do sistema.
Arquitetura de 3 camadas
A arquitetura de trs camadas no necessariamente representa que existam trs tipos de
computadores conecados numa rede. possvel implementar esse modelo simplesmente com
um servidor assumindo a camada de dados e a de negcio simultaneamente. Para
visualizarmos melhor todos esses relacionamentos vejamos a prxima figura.
Do lado direito temos um Database Server - Servidor de Banco de Dados fornecendo as

solicitaes do Web Server Servidor Web (Camada de Dados). Do lado oposto, esquerda,
vemos os clients (clientes), na Camada de Apresentao, como interface com os usurios. E
no meio, Camada de Negcio, o Web Server prove, atravs das regras de negcio, os
servios desejados ao conjunto de clientes.
Arquitetura de Objetos Distribudos

A Arquitetura de Objetos Distribudos uma abordagem distinta da cliente/servidor onde
elimina o conceito de distinguir quem servidor ou mesmo cliente. Entretanto criado um
novo conceito chamado de middleware.
68
O middleware intermedeia os computadores a ele conectados. tambm chamado de

requisitor de objetos, e seu papel fornecer uma interface contnua de comunicao entre
esses objetos.
Os objetos no sistema podem ser implementados com o uso de diferentes linguagens de
programao, podem ser executados em diferentes plataformas e seus nomes no precisam
ser conhecidos por todos os outros objetos no sistema. Os dois padres normais para o
middleware so o CORBA e o DCOM.
Por todas as vantagens do padro CORBA (flexibilidade, por ser genrico, sistemas
operacionais adotados), organizado pelo OMG que constituda por mais de 500 empresas,
deva ser o padro de fato que o mercado ir adotar.
Wikipdia
http://pt.wikipedia.org/wiki/Cliente-servidor
http://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_camadas
http://pt.wikipedia.org/wiki/Corba
Pela importncia do conceito do modelo de 3 camadas, e do padro

CORBA nos dias atuais, explore detalhadamente esses dois itens na
Internet.
69
NIDADE
21
Mudanas em Software - Dinmica da Evoluo de Programas - Evoluo da

Arquitetura
Objetivo: Contextualizar os impactos das mudanas de software.
Depois que os sistemas so entregues aos usurios/clientes, os softwares tem que sofrer
mudanas para que possam responder s exigncias das constantes mudanas impostas
pelos mercados cada vez mais competitivos. Conforme Warren, existem diversas estratgias
para essas mudanas:
ESTRATGIAS
Descrio
Evoluo da
Arquitetura
Os sistemas normalmente evoluem de uma arquitetura mais

centralizada, para uma arquitetura cliente/servidor (veremos a
seguir nesta mesma Unidade).
Manuteno
Quando a estrutura fica estvel, mas sofre modificaes para

adaptar a novos requisitos dos usurios (veremos mais detalhes
na Unidade 27).
Reengenharia
Ao contrrio da Manuteno, sofre alteraes na estrutura, para

que o sistema torne-se mais fcil sua compreenso e tambm
para alteraes (veremos mais detalhes na Unidade 22).
70
Dinmica da Evoluo de Programas

Vamos exemplificar a Dinmica da Evoluo de Programas pegando como exemplo o
Microsoft Word. Ele comeou operando como um simples processador de texto, ocupando
256Kb de memria. Hoje um gigante com tantos recursos disponveis que a grande maioria
dos usurios pouco os utiliza.
Necessita atualmente de muitos megabytes de memria, e mais um processador gil para
que possa ser executado. A evoluo desse software, na verdade, passou por vrias fases.
Alguns podem achar que trabalham somente com o mais novo release desse editor de texto.
No entanto, ele no uma simples sequncia de revises, mas sim um software que sofreu
vrias mudanas na sua estrutura. Em certos momentos, ele passou no s por
manutenes, mas tambm por reengenharias. E atualmente at evoluindo na sua
arquitetura para ficar mais condizendo com o mundo da Internet.
Evoluo da Arquitetura
Os principais sistemas antigos, ou mesmo os legados, foram desenvolvidos na concepo de
arquiteturas centralizadas. Hoje, a tendncia geral do desenvolvimento de sistemas com
arquiteturas distribudas cliente/servidor.
Quando estamos alterando a arquitetura de um sistema j existente interessante que
tenhamos um modelo de camadas lgicas para nos orientar. A imagem abaixo representa as
estruturas de um sistema divididas por camadas, facilitando a modularizao para uma
arquitetura distribuda.
A Evoluo da Arquitetura envolve modificar a arquitetura de um sistema, a partir de uma

arquitetura centralizada, centrada em dados, para uma arquitetura distribuda. Tanto a
interface com o usurio quanto a funcionalidade do sistema podem ser distribudas.
71
Uma estratgia comum da Evoluo da Arquitetura, para sistemas legados em especial,

encapsular o sistema legado como um servidor. E implementa-se uma interface com o
usurio distribuda, que acesse a funcionalidade do sistema (por meio de um middleware de
propsito especial).
Wikipdia
www.twiki.dcc.ufba.br/pub/Residencia/MaterialModuloTI1/slides_aula04
arquiteturadesoftware.pdf
Para voc fazer uma reviso geral dos principais tpicos vistos at aqui,
visite o site sugerido em ESTUDO COMPLEMENTAR, e faa um resumo
por escrito dos principais tpicos de seu interesse.
72
NIDADE
22
Reengenharia de Software - Traduo de cdigo fonte - Engenharia Reversa Melhoria de estrutura de programa
Objetivo: Visualizar a importncia da reengenharia na Engenharia de Software.
A principal diferena entre Reengenharia de Software e o desenvolvimento de um novo
Sistema da onde que se parte esse prprio desenvolvimento. Num Sistema novo inicia-se
com uma especificao escrita (os requisitos) dos usurios/clientes. Enquanto que, numa
reengenharia, o sistema existente (normalmente um Sistema Legado) que a base para
esse incio.
Chikofsky e Cross chegam at definir o desenvolvimento tradicional como Engenharia
Direta, para distinguir da Reengenharia de Software.
Pode-se perceber, pela figura abaixo, a complexidade do processo de Reengenharia de
Software. Embora, nem toda reengenharia passe por todos esses processos,
essencialmente o programa reestruturado. Vejamos mais detalhadamente o que cada
processo realiza (caixas arredondadas).
Processo de Reengenharia conforme a viso de Sommerville
73
PROCESSOS
Descrio
Traduo de
cdigo-fonte
O programa convertido da linguagem de programao original

para uma verso mais moderna ou mesmo para uma nova
linguagem mais adequada.
Engenharia
Reversa
O programa analisado conforme essas tcnicas e as informaes

so extradas dele, a fim de ajudar a documentar sua organizao
e funcionalidade.
Melhoria de
estrutura do
programa
A estrutura de controle do programa analisada e modificada, a

fim de torn-la mais fcil de ser lida e compreendida. Visa-se a
manutenabilidade do sistema.
Modularizao
de programa
Partes em comum do programa so agrupadas e, quando

apropriado, a redundncia removida. Em alguns casos, esse
estgio pode envolver a transformao da arquitetura.
Reengenharia
de dados
Os dados processados pelo programa so modificados, a fim de

refletir as mudanas feitas nele. Ou mesmo adota-se uma nova
estrutura de Banco de Dados.
Wikipdia
http://pt.wikipedia.org/wiki/Reengenharia
http://pt.wikipedia.org/wiki/Reengenharia_de_Processos
74
NIDADE
23
Reengenharia de Dados e suas abordagens

Objetivo: Abordar os vrios aspectos da reengenharia de dados.
A necessidade de analisar, reorganizar a estrutura dos dados, e mesmo os valores contidos
num Sistema chamada de Reengenharia de Dados. Vejamos, a seguir, as possveis
abordagens visualizadas por Sommerville:
ABORDAGENS
Limpeza
de dados
Extenso
de dados
Migrao
de dados
Descrio
Os registros e valores de dados so analisados, a fim de

melhorar sua qualidade. As duplicaes so removidas, as
informaes redundantes so excludas e um formato
consistente aplicado a todos os registros. Normalmente, isso
no deve requerer quaisquer mudanas nos programas
associados.
Nesse caso, os dados e programas associados passam pelo
processo de reengenharia, a fim de eliminar os limites no
processamento de dados. Isso pode exigir mudanas no
programas para aumentar a extenso de campos, modificar
limites superiores na tabelas e assim por diante. Os dados em si
podem precisar ser reescritos e limpos, para que reflitam as
mudanas no programa.
Nesse caso, ocorre a migrao dos dados para o controle de um
Sistema de Gerenciamento de Banco de Dados. Os dados
podem ser armazenados em arquivos separados ou serem
gerenciados por um tipo de sistema de gerenciamento de Banco
de Dados antigo. Essa situao ilustrada na figura abaixo.
75
Strategies for Data Reengineering

http://www.info.fundp.ac.be/~dbm/publication/2003/FNRSReEngineering.pdf
Realize uma pesquisa na Internet sobre esse importante tpico. Procure em

ingls ("Data reengineering") para encontrar mais material a respeito.
76
NIDADE
24
Gerenciamento de Configurao Gerenciamento de Verses e Releases
Gerenciamento
de
Mudanas
Objetivo: Abordar os principais aspectos do gerenciamento de mudanas.

Gerenciamento de Configurao
o desenvolvimento e a aplicao de padres e procedimentos para gerenciar um Sistema
em desenvolvimento. Esses procedimentos definem como registrar e processar as mudanas
do Sistema, como relacion-los aos seus componentes e os mtodos utilizados para
identificar as diferentes verses desse Sistema (adaptado de Sommerville).
As quatro atividades principais do Gerenciamento de Configurao so:
ATIVIDADES
Planejamento do
Gerenciamento de
Configurao
Descrio
Descreve os padres e os procedimentos que devem ser
utilizados para o Gerenciamento de Configurao.
Gerenciamento de
Mudanas
Com as constantes mudanas exercidas em cima dos

softwares, as mesmas devem ser registradas e aplicadas ao
sistema de forma prtica e econmica.
Gerenciamento de
Verses e Releases
Consiste em acompanhar e identificar o desenvolvimento das

diferentes verses e releases de um Sistema.
Construo de
Sistemas
Processo de compilar e ligar componentes de software em um

programa que executado em uma configurao-alvo
especfica.
Gerenciamento de Mudanas
Durante os testes de sistemas, ou ainda depois da entrega do software ao cliente, devem
sofrer os procedimentos de Gerenciamento de Mudanas. O primeiro passo desse processo
77
a utilizao de um formulrio intitulado de Requisio de Mudana (CRF change request

form).
O formulrio CRF dever conter informaes do tipo: registro da solicitao da mudana,
recomendaes, custos, datas de solicitao, aprovao, implementao e validao da
mudana. aconselhvel tambm existir um espao para um esboo especificando como a
mudana dever ser implementada. Um exemplo do formulrio CRF mostrado a seguir:
Gerenciamento de Verses e Releases

Objetivo: acompanhar e identificar o desenvolvimento das diferentes verses e releases de
um Sistema. Tambm chamado de versionamento.
O release de um sistema uma verso que distribuda para os clientes (Sommerville).
Logo, sempre existem muita mais verses de um sistema do que releases, pois existem
muitas verses criadas para testes, ou desenvolvimento interno e no so liberadas para os
clientes.
78
Para a devida identificao de componentes existem trs tcnicas bsicas:

TCNICAS BSICAS
Descrio
Numerao de verses
Esse o esquema de identificao mais comum.

Atribu-se um nmero, explcito e nico, de
verso ao componente (ver figura)
Identificao baseada em
atributos
Cada componente recebe um nome e um

conjunto de atributos (que no nico em
todas as verses).
Identificao orientada a
mudanas
Alm do anterior associado uma ou mais

solicitaes de mudana.
79
Wikipdia
http://pt.wikipedia.org/wiki/Ger%C3%AAncia_de
_Configura%C3%A7%C3%A3o_de_Software
http://pt.wikipedia.org/wiki/Sistema_de_controle
_de_vers%C3%A3o
Devido excelente qualidade dos artigos colocados no Wikipdia

especificamente neste tema, e para voc explorar mais
detalhadamente os assuntos dessa unidade, visite e leia todos os links
mencionados no item anterior chamado ESTUDO COMPLEMENTAR.
80
NIDADE
25
(continuao) Construo de Sistemas - Ferramenta CASE

Objetivo: Explorar o conceito da ferramenta CASE.
Construo de Sistemas
Na construo de um Sistema, a partir dos seus componentes, devem-se questionar os
seguintes pontos:
1. Todos os componentes foram includos nas instrues de construo?
2. A verso de cada componente requerido foi includo nas instrues de construo?
3. Todos componentes requeridos esto disponveis?
4. Os arquivos de dados do componente utilizado so iguais aos da mquina-alvo?
5. A verso do compilador e outras ferramentas esto disponveis?
Ferramenta CASE
Uma ferramenta CASE (Computer-Aided Software Engineering) significa Engenharia de
Software com o auxlio de computador. Ela possibilita apoiar as atividades de processo do
software, como: a anlise de requisitos, a modelagem de sistema, a depurao e os testes.
Ferramentas CASE so constitudas com uma ampla gama de diferentes tipos de programas.
81
As ferramentas CASE podem tambm incluir um gerador de cdigos que, automaticamente,

origina o cdigo-fonte a partir da modelagem do Sistema. Adicionalmente pode ter alguma
orientao de processo, ao fornecer conselhos ao engenheiro de software sobre o que fazer
em seguida.
Uma diferenciao que pode existir nas ferramentas CASE a denominao Upper-CASE e
Lower-CASE. As primeiras tm como utilidade de dar apoio anlise e ao projeto, ou seja,
apoiar as fases iniciais do processo de software. As ferramentas Lower-CASE, por outro lado,
so projetadas para dar apoio implementao e aos testes, como depuradores, sistemas de
anlise de programa, geradores de casos de testes e editores de programas.
Na imagem abaixo damos um destaque para telas da ferramenta CASE como o Rational Rose
da IBM:
82
Wikipdia
http://pt.wikipedia.org/wiki/Ferramenta_CASE
Leia o site http://www2.dem.inpe.br/ijar/case.htm e faa um

comparativo com o que voc aprendeu at agora.
83
NIDADE
26
Sistemas Legados - Estruturas dos Sistemas Legados - Avaliao dos Sistemas

Legados
Objetivo: Valorar a importncia dos sistemas legados para a Engenharia de Software.
As empresas continuamente evoluem em seus Sistemas, adaptando-os a sua realidade, e as

constantes mudanas do mercado. No entanto, descartar Sistemas mais antigos, os legados,
e puramente substitu-los por softwares mais modernos envolve riscos empresariais
significativos.
Podemos dar um simples exemplo atual. Imagine, de repente, mudarmos todos os Sistemas
Operacionais Windows XP, de uma grande empresa, para o novo Windows Vista, ou mesmo
para um Linux. A quantidade de problemas e adaptaes necessrias ser to grande, que
poderia chegar a paralisar essa empresa.
Empresas com grande nmero de Sistemas Legados enfrentam dilemas fundamentais. Se
continuarem com os sistemas velhos, os custos de adaptao aumentam. E se substiturem
por novos, tero um custo inicial alto, e com a possibilidade de no atenderem as
expectativas. Exige-se estar ciente das tcnicas de Engenharia de Software para resolver
esses problemas.
Estruturas dos Sistemas Legados

Pode-se dividir um Sistema Legado, do ponto vista didtico, em seis partes lgicas: Hardware
do Sistema, Software de Apoio, Software de Aplicao, Dados de Aplicao, Processos de
Negcios e Polticas e Regras de Negcios. Mas, veremos a seguir, que na prtica, pode-se
dividir um Sistema Legado de forma mais simplificada.
Ao observarmos atentamente as imagens a seguir, veremos as estruturas ideais e as reais de
um Sistema Legado. O ideal seria termos a estrutura da esquerda, para numa possvel
migrao termos cada componente claramente separado. No entanto, na grande maioria das
vezes, encontramos a estrutura da direita.
84
Os servios sobrepem interagindo com outros componentes do Sistema. A interface com o

usurio e o cdigo do servio est integrada nos mesmos componentes, e pode no haver
uma ntida distino entre os servios e o Banco de Dados do Sistema. Nesses casos, pode
no ser possvel identificar as partes do Sistema que podem ser distribudas (Sommerville).
Avaliao dos Sistemas Legados
Podemos atravs da figura acima caracterizar tipicamente as aes que devemos tomar
quanto aos Sistemas Legados. Enquanto num eixo mensuramos a importncia que um
Sistema Legado tem para o negcio da empresa, no outro quantificamos a sua respectiva
qualidade. Vamos, a seguir, tabular essas aes a serem tomadas.
85
Valor X Qualidade
Descrio
Alto Valor de Negcios

X
Baixa Qualidade
So sistemas com importante contribuio empresa e no

devem ser descartados. Contudo, pela sua baixa qualidade,
os custos operacionais so altos, de modo que so fortes
candidatos reengenharia ou substituio total do
sistema.
Baixo Valor de
Negcios
X
Baixa Qualidade
Manter sistemas desse tipo em operao dispendioso, e a

taxa de retorno de investimento para os negcios bastante
pequena. Esses sistemas so fortes candidatos a receberem
nenhum investimento, e mesmo a serem descartados.
Alto Valor de Negcios

X
Alta Qualidade
Sistemas com essas caractersticas devem ser mantidos em

operao pela sua importncia. E pela sua alta qualidade
significa que no necessrio investir na sua transformao
ou substituio. Portanto, devem continuar a manuteno
normal no sistema.
Baixo Valor de
Negcios
X
Alta Qualidade
So sistemas que no contribuem muito para os negcios,

mas por outro lado, a manuteno no muito dispendiosa.
No vale o risco de substituir esses sistemas, de modo que a
manuteno normal pode ser continuada ou eles podem ser
descartados.
86
Artigo Uma Proposta de Evoluo em Sistemas Legados:

http://wer.inf.pucrio.br/WERpapers/artigos/artigos_WER04/Luciana_Paiva.pdf
Levante na sua empresa, ou na de colegas, quantos Sistemas

Legados existem. Quais so as caractersticas deles? H quanto
tempo eles foram desenvolvidos? Qual o processo de
mant-los no ar?!?
87
NIDADE
27
Manuteno: fundamentos da fase de Manuteno de Software, tipos de

Manuteno, procedimentos, tcnicas e ferramentas
Objetivo: Identificar as principais caractersticas da manuteno de software.
As leis de Lehman (1985) foram produzidas com base no estudo da mudana em Sistemas.
Foram examinados o crescimento e a evoluo de uma srie de grandes sistemas de software
para chegar nessas leis. Duas delas que destacamos so a da:
Mudana Contnua: afirma que um programa utilizado em um ambiente do mundo

real necessariamente tem de ser modificado ou se tornar de maneira progressiva
menos til nesse ambiente;
Aumento da Complexidade: medida que um programa em evoluo se modifica,

sua estrutura tende a se tornar mais complexa. Recursos extras precisam ser
dedicados para preservar e simplificar a estrutura.
Tipos de Manuteno
A manuteno ser necessria durante todo o Ciclo de Vida til, e pode ocorrer motivada por
trs tipos fundamentais:
Tipos de Manuteno
Descrio
Manuteno para reparar

os defeitos no software
A correo de erros de codificao um processo

relativamente barato comparado com os erros de projeto. Os
maiores custos esto nos erros de requisitos, pois ir
implicar num reprojeto.
Manuteno para adaptar

o software a um
ambiente operacional
diferente
a tpica manuteno de adaptao sofrida por alguma

alterao no software de apoio tal como o Sistema
Operacional, Banco de Dados ou mesmo o prprio hardware.
88
Manuteno para fazer

acrscimos
funcionalidade do
sistema ou modific-la
Na alterao dos requisitos, devido a mudanas

organizacionais, ou nos negcios, que so bastante
constantes, ocorre a manuteno mais comum entre todas
as outras.
Procedimentos de Manuteno
O Processo de Manuteno normalmente iniciado pelos pedidos de mudana por parte dos
vrios usurios que utilizam o Sistema. Isso pode ser de maneira informal, ou
preferencialmente formalizado, com uma documentao estruturada. Em seguida verificado
o custo e o impacto das mudanas sugeridas. Com as mudanas aprovadas, um novo release
do sistema planejado.
Repare atentamente na figura acima. Veja que uma vez bem estruturado um sistema, no
caso o System 1, que embora tenha despendido maiores custos de desenvolvimento, exigiu
no perodo de manuteno menos tempo e recursos. Ou seja, o System 2 foi desenvolvido
mais rapidamente, mas por no investir, ou visualizar, nos processos de manuteno, ao
chegar nessa fase, despende maior tempo e custos.
Interessante observar que a manuteno segue o mesmo modelo do processo de
desenvolvimento de sistema. Na figura abaixo vemos que a representao das etapas que a
manuteno que est sendo realizada, segue o mesmo Modelo Espiral que estudamos na
Unidade 7.
89
Existem equipes de manuteno que atuam somente em corretivas, ou seja, somente quando
existir um pedido dos usurios que se atua no problema. No entanto, a melhor estratgia
a Manuteno Preventiva na qual se detecta previamente onde esto ocorrendo um maior
nmero de corretivas, e destaca-se uma fora-tarefa para realizar uma reengenharia nesses
processos.
No quadro a seguir, veja as principais perguntas a serem feitas no Processo de Manuteno:
90
Wikipdia
http://pt.wikipedia.org/wiki/Manuten%C3%A7%C3%A3o_de_software
Na sua empresa como realizada a atividade de Manuteno? As

equipes de Informtica esto sempre realizando corretivas, ou esto
mais focadas em preventivas?!?
Quanto porcentualmente no ms voc imagina dedicado para essa
funo? Essa atividade especfica de uma equipe, ou a mesma de
desenvolvimento?!?
91
NIDADE
28
Gesto de Projetos de Software e o PMBOK

Objetivo: Apresentar os princpios da gesto de projetos e a base do PMBOK.
Gesto de Projetos de Software
A Gerncia de Projetos se preocupa em entregar o sistema de software no prazo e de acordo
com os requisitos estabelecidos, levando em conta sempre as limitaes de oramento e
tempo.
A Gesto de Projetos de Software se caracteriza por tratar sobre um produto intangvel,
muito flexvel e com processo de desenvolvimento com baixa padronizao. Ou seja, no
trata de processos rotineiros ou de prvio conhecimento.
A gesto efetiva de projetos de software focaliza os quatros Ps: (P)essoal, (P)roduto,
(P)rocesso e (P)rojeto (Pressman). Quanto ao PESSOAL existe at um padro equivalente ao
CMM, estudado anteriormente, intitulado de PM-CMM. Um dos pontos importantes do
PRODUTO a determinao adequada dos objetivos e o escopo do projeto. No PROCESSO
estabelecido o ferramental para apoiar um plano abrangente de desenvolvimento de
software. E finalmente no PROJETO as diretrizes do PMBOK (que veremos a seguir) auxiliam
na construo de um projeto de sucesso.
O planejamento de um projeto de desenvolvimento de software inclui:
Organizao do Projeto (incluindo equipes e responsabilidades)

Estruturao das Tarefas (WBS - Work Breakdown Structure)
Cronograma do Projeto (normalmente um Diagrama de Barras)
Anlise de Risco
Essas atividades sofrem com dificuldades tpicas de desenvolvimento de software. A

produtividade no linear em relao ao tamanho da equipe e o aumento de produtividade
no imediato devido os custos de aprendizado dos novos membros. A diminuio de
qualidade para acelerar o desenvolvimento constantemente prejudica a produtividade.
A estimativa de dificuldades e custos de desenvolvimentos so muito difceis, alm do
surgimento de problemas tcnicos. Esses fatores requerem uma Anlise de Riscos cuidadosa.
92
PMBOK
O PMBOK uma importante referncia em Gerenciamento de Projetos. Desenvolvido pelo
PMI (Project Management Institute) possibilitou utilizar termos em comum para se discutir,
escrever e aplicar o Gerenciamento de Projetos.
O guia atualmente base para uma certificao especfica e bem remunerada no mercado.
Como os profissionais de Engenharia de Software praticamente so gerentes de projetos,
existe a necessidade do entendimento desse conjunto de prticas para o bom
desenvolvimento de um projeto de software.
A estrutura do PMBOK Guide (veja a imagem a seguir - os nmeros entre parnteses
representam respectivamente os blocos da imagem) contempla nove reas de conhecimento
especficas, que so:
Gerenciamento da Integrao do Projeto (4)

Gerenciamento do Escopo do Projeto (5)
Gerenciamento do Prazo do Projeto (6)
Gerenciamento do Custo do Projeto (7)
Gerenciamento da Qualidade do Projeto (8)
Gerenciamento dos Recursos Humanos do Projeto (9)
Gerenciamento da Comunicao do Projeto (10)
Gerenciamento dos Riscos do Projeto (11)
Gerenciamento das Aquisies do Projeto (12)
93
94
Wikipdia
http://pt.wikipedia.org/wiki/PMBOK
http://pt.wikipedia.org/wiki/Gerenciamento_de_Projetos
Site do PMBOK, e no Brasil

http://www.pmi.org
http://www.pmisp.org.br/exe/educacao/pmbok.asp
Para voc explorar mais adequadamente os objetivos do PMBOK,

baixe o arquivo do site:
http://www.prodepa.psi.br/sqp/pdf/Captulo 01 - Introduo.pdf
e leia o primeiro captulo, em portugus, desse importante livro de
Gerenciamento de Projetos.
95
NIDADE
29
Gerenciamento de Qualidade e Estratgias de Teste de Software

Objetivo: Visualizar os elementos da qualidade e de teste de software.
Existe uma relao direta entre a qualidade do produto de software desenvolvido, e qualidade
do processo de software utilizado para criar esse produto. Ou seja, qualquer melhoria no
processo de software ir resultar diretamente um impacto na qualidade do produto final.
Portanto, os principais itens do PROCESSO que devero receber ateno especial do
desenvolvedor para a melhoria da qualidade, e as perguntas mais significativas a serem
questionadas so:
ITENS
Perguntas
Facilidade de
compreenso
At que ponto o processo est definido e com que facilidade se

compreende a definio do processo?
Visibilidade
As atividades culminam em resultados ntidos, de forma que o

progresso do processo seja visvel?
Facilidade de
suporte
At que ponto as atividades do processo podem ser apoiadas por

ferramentas CASE?
Aceitabilidade O processo aceitvel e utilizvel pelos desenvolvedores?

Confiabilidade
Os erros podem ser evitados ou identificados antes que o produto

seja entregue aos usurios?
Robustez
Existe continuidade no processo mesmo que surjam problemas

inesperados?
Facilidade de
manuteno
Existe evoluo no processo para refletir os requisitos mutveis da

organizao ou para receber melhorias?
Rapidez
A partir de uma determinada especificao com que rapidez pode

ser alterado o processo?
96
(adaptado de Sommerville)
Os principais fatores da qualidade de produtos de software, ou mesmo para quaisquer outros

produtos intelectuais (livros, filmes, etc.), so:
A tecnologia de desenvolvimento
Qualidade do pessoal
Qualidade do processo (como vimos anteriormente !)
Custo, tempo e cronograma
E de todos esses elementos o mais significativo o ltimo. Pois se um projeto tiver um

oramento baixo, ou ainda pior, um cronograma de entrega fora da realidade, a qualidade
ser diretamente afetada.
Estratgias de Teste de Software

Um princpio bsico na realizao de Testes de Software (principalmente em Sistemas de
media complexidade para cima) diferenciar a equipe puramente de desenvolvimento, da
equipe especificamente de testes. Ou seja, quem desenvolve no testa, e quem testa no
desenvolve.
Uma das estratgias de Teste de Software a abordagem Top-down e a Bottom-up (veja a
figura abaixo). Enquanto que a primeira (lado esquerdo da figura) tenta ver a integrao de
todos os componentes de um Sistema comeando pelos nveis superiores, a segunda a
Bottom-up (lado direito da figura), comea pelos nveis inferiores. As duas estratgias tm
pontos positivos e negativos. O mais comum utilizar a abordagem Top-down, por ser mais
natural.
TOPLevel 1
Testin g
sequen ce
Level 2
Le vel 2
stubs
Level 1
Test
d ri ve rs
. ..
Le v e l N
Level 2
Le vel 2
Le ve l N
Le v e l N
Le v e l N
Level 2
Test
d ri v e rs
Le vel 3
stubs
Le ve l N
Leve l N 1
Le v el N 1
Le v e l N 1
BOTTOM-UP
Testes Alfa e Beta
97
Quando um software construdo especificamente para um cliente, normal ele passar por
um Teste de Aceitao. Esse teste por ser conduzido pelo prprio usurio, pode passar por
uma bateria de testes levando s vezes semanas, ou mesmo meses, para ser finalizado.
No entanto, se o software feito para vrios clientes, o Teste de Aceitao no vivel de
ser realizado por cada usurio principal. Por isso, a estratgia melhor a ser aplicada a dos
Testes Alfa e Beta.
Para a realizao dos Testes Alfa existe a necessidade de um ambiente controlado. Ou seja,
os usurios so levados a testar o software desde os seus estgios iniciais de instalao, at
a sua operao completa. Tudo isso realizado num ambiente especial, onde fiquem
registradas todas as impresses dos usurios, suas reaes s interfaces homem-mquina, e
assim por diante.
Os Testes Beta so realizados exclusivamente no habitat do usurio. E realizado
tipicamente sem a presena dos desenvolvedores, ao contrrio do Alfa. Normalmente
selecionado um pblico especial de usurios, com um perfil crtico e colaborador.
importante a escolha adequada de usurios nesse tipo de teste. Pois existe a necessidade do
prprio usurio deixar todas suas observaes, questionamentos e sugestes, registrados de
forma minuciosa e com riqueza de detalhes.
Testes Caixa-Branca e Caixa-Preta

O Teste Caixa-Branca, tambm chamado de Teste Estrutural, foca-se mais nos possveis erros
internos ao Sistema. E o Teste Caixa-Preta visa identificar as falhas em seu comportamento
externo.
Enquanto o Teste Caixa-Branca realiza testes na estrutura dos componentes de um Sistema,
o Caixa-Preta refere-se aos testes que so conduzidos na interface do software.
Para realizar os Testes da Caixa-Branca so utilizadas tcnicas tais como:
Testes de Caminho Bsico

o Notao de Grafo de Fluxo
o Caminhos Independentes de Programa
o Derivao de Casos de Teste
o Matrizes de Grafos
Testes de Estrutura de Controle
o Teste de Condio
o Teste de Fluxo de Dados
o Teste de Ciclo
98
No caso dos Testes de Caixa-Preta que focalizam nos requisitos funcionais do software so os
mais utilizados no mundo prtico. Os Caixa-Branca demandam muito tempo, e praticamente
no conseguem realizar todas as possibilidades de resposta que um software fornece. As
principais tcnicas utilizadas nos Testes de Caixa-Preta so:
Mtodos de Teste baseados em Grafo
o Modelagem de fluxo de transao
o Modelagem de estado finito
o Modelagem do fluxo de dados
Particionamento de Equivalncia
Anlise de Valor-limite
Teste de Matriz Ortogonal
Wikipdia
http://pt.wikipedia.org/wiki/Qualidade_de_Software
http://pt.wikipedia.org/wiki/Teste_de_software
Responda, por escrito, aos questionamentos abaixo:

Que itens voc levaria em considerao para a melhoria da qualidade
de um software?
Quais so as diferenas das estratgias aplicadas para testar um
software?
99
NIDADE
30
Engenharia de Software na WEB Sistemas e Aplicaes baseadas na WEB

Objetivo: Apresentar as diferenciaes quanto ao desenvolvimento na WEB.
A Engenharia de Software na Web, tambm utilizada pela sigla WebE, o processo usado
para criar WebApps (aplicaes baseadas na Web) de alta qualidade. Embora os princpios
bsicos da WebE sejam muito prximos da Engenharia de Software clssica, existem
peculiaridades especificas e prprias.
Com o advento do B2B (e-business) e do B2C (e-commerce), e ainda mais com aplicaes
para a Web 2.0, maior importncia ficou sendo esse tipo de engenharia. Como as WebApps
evoluem continuamente, devem ser estabelecidos mecanismos para controle de configurao,
garantia de qualidade e suporte continuado.
Tipicamente as WebApps so desenvolvidas incrementalmente, sofrendo modificaes
frequentemente, e possuindo cronogramas extremamente curtos. Por tudo isso,
normalmente, o modelo de processo utilizado na WebE o da filosofia do desenvolvimento
gil, por ter uma abordagem de desenvolvimento simples e com ciclos rpidos de
desenvolvimento.
Os mtodos adotados na WebE so os mesmos conceitos e princpios da Engenharia de
Software. No entanto, os mecanismos de anlise, projeto e teste devem ser adaptados para
acomodar as caractersticas prprias das WebApps.
Quanto s ferramentas e tecnologias aplicadas na WebE englobam vrias linguagens de
modelagem (HTML, VRML,XML, etc.), recursos baseados em componentes (CORBA,COM,
ActiveX, .NET, AJAX, etc.), navegadores, ferramentas multimdia, ferramentas de autoria de
sites, ferramentas de conectividade de Banco de Dados, ferramentas de segurana,
servidores e utilitrios de servidor, e ferramentas de gesto e anlise de sites.
Para quem desenvolve aplicaes na Web deve observar os seguintes requisitos de
qualidade:
Usabilidade
Funcionalidade
Confiabilidade
Eficincia
Manutenibilidade
Segurana
100
Disponibilidade
Escabilidade
Prazo de colocao no mercado
Pirmide de Projeto da WebE

Um projeto no contexto de Engenharia da Web leva a um modelo que contm a combinao
adequada de esttica, contedo e tecnologia. Repare na figura a seguir. Enquanto a base da
pirmide a tecnologia (technology), todos os seus itens so direcionados para atender o
usurio (user).
user
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
technology
Cada nvel da pirmide representa uma atividade de projeto. Veja maiores detalhes de cada
fase no quadro abaixo, vendo a pirmide de cima para baixo:
Nvel da Pirmide
Descrio
Projeto de Interface
Descreve a estrutura e organizao da interface com o

usurio.
Projeto Esttico
Atenta para os esquemas de cor, leiaute, fonte, uso de

grficos, etc.
Projeto de Contedo
Define a estrutura e o esboo de todo o contedo,

relacionando os objetos de contedo.
101
Projeto de Navegao
Projeto Arquitetural
Projeto de Componente
Representa o fluxo de navegao entre objetos de

contedo e todas as funes da WebApp.
Identifica a estrutura de hipermdia para a WebApp.
Desenvolve a lgica de processamento detalhada
necessria para implementar os componentes funcionais.
Adaptado de Pressman
Arquitetura da WebApp
Conforme Jacyntho, as aplicaes devem ser construdas usando camadas nas quais
diferentes preocupaes so levadas em conta. Em particular, dados da aplicao devem ser
separados dos contedos da pgina da Web. E esses contedos, por sua vez, devem ser
claramente separados dos aspectos da interface.
Os autores sugerem um projeto de arquitetura em trs camadas (veja a figura abaixo) que
desaclopa a interface da navegao, e do comportamento da aplicao. Os mesmos
argumentam que manter a interface, aplicao e navegao separadas simplifica a
implementao e aumenta o reuso.
co n t ro ller
m an ag e s u se r re q u e st s
se le ct s m o d e l b e h av io r
se le ct s v ie w re sp o n se
b e h av io r re q u e st
( st at e ch an g e )
u se r re q u e st
o r d at a
b ro wse r
v ie w se le ct io n
m o del
e n cap su lat e s f u n ct io n alit y
e n cap su lat e s co n t e n t o b je ct s
in co r p o r at e s all we b A p p st at e s
clie n t
d at a f ro m m o d e l
HTML d at a
view
u p d at e re q u e st
e xt e rn al d at a
p re p are s d at a f ro m m o d e l
re q u e st u p d at e s f ro m m o d e l
p re se n t s v ie w se le ct e d b y
co n t ro lle r
se rv e r
102
A arquitetura mais utilizada nesse caso a Modelo-Viso-Controlador (MVC Model-ViewController). Embora seja um padro de projeto arquitetural desenvolvido para o ambiente
Smalltalk (linguagem de programao orientada a objeto), ele pode ser utilizado para
qualquer aplicao interativa. Veja os detalhes de cada item da arquitetura MVC na tabela
abaixo:
ITEM do MVC
MODELO
VISO
CONTROLADOR
Descrio
Encapsula funcionalidade, objetos de contedo e incorpora todos os
estados da WebApp. o contedo em si, normalmente armazenado
num Banco de Dados externo.
Prepara dados do Modelo, requisita atualizaes dele, apresenta viso
selecionada pelo Controlador. Geralmente a prpria pgina HTML.
Gera requisies do usurio, seleciona comportamento do Modelo e
seleciona resposta de viso. o cdigo que gera os dados dinmicos
para dentro da pgina HTML.
Wikipdia
http://pt.wikipedia.org/wiki/MVC
http://pt.wikipedia.org/wiki/Web_2.0
http://pt.wikipedia.org/wiki/Web_3.0
Veja os links colocados no ESTUDO COMPLEMENTAR, e escreva quais so

as caractersticas e diferenas da Web 2.0 e da Web 3.0. Aproveite e veja
com maior riqueza de detalhes a arquitetura MVC no link
http://pt.wikipedia.org/wiki/MVC
103
MDULO: ENGENHARIA de SOFTWARE
Apresentao
O estudo da Engenharia de Software permite entender os principais aspectos da

produo e manuteno de programas e Sistemas. Para tanto, abordam-se desde os
estgios iniciais da construo de um Sistema, at mesmo a manuteno de Sistemas
legados.
Objetivo
Apresentar conceitos bsicos da Engenharia de Software. Detalhar os principais mtodos,

ferramentas e procedimentos ligados disciplina da Engenharia de Software. Discutir os
principais aspectos que levam as organizaes a utilizar as melhores prticas da
Engenharia de Software.
Capacitar os alunos a identificar quais os mtodos, ferramentas e procedimentos mais

adequados ao processo de desenvolvimento ou manuteno de softwares.
Carga horria
40 horas
Ementa
Apresentao dos mtodos, ferramentas e procedimentos da Engenharia de Software,

atravs das fases do Ciclo de Vida do Desenvolvimento de Software. E como podem
ajudar as organizaes a desenvolver Sistemas de acordo com os custos, prazos,
recursos e qualidades planejadas.
Requisitos
Ter realizado e sido aprovado no mdulo anterior.
Bibliografia do mdulo
PRESSMAN, Roger. Engenharia de Software. So Paulo: McGraw-Hill Brasil, 2006
SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2005
REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Rio de

Janeiro: Brasport, 2005.
104
Sobre o autor
Professor e Consultor de Tecnologia de Informao
Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em

Anlise de Sistemas (Mackenzie), Administrao (Luzwell-SP), e Reengenharia (FGVSP). Graduado/Licenciado em Matemtica.
Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB (Ensino a

Distncia). Autor de 3 livros em Conectividade Empresarial. Prmio em E-Learning no
Ensino Superior (ABED/Blackboard).
Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor, etc.
Viagens internacionais: EUA, Frana, Inglaterra, Itlia, Portugal, Espanha, etc.
105
Atividade Dissertativa
Desenvolva uma pesquisa gerando um texto, de 2 a 3 folhas adicionando
imagens, de uma das unidades da nossa apostila, de sua livre escolha, permitindo
a expanso da temtica selecionada.
Ateno: Qualquer bloco de texto igual ou existente na internet ser devolvido
para que o aluno realize a atividade novamente.
106

Engenharia de Software

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Engenharia de Software

Enviado por

Direitos autorais:

Formatos disponíveis

MDULO DE:

Ms. CARLOS VALENTE

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

O que Engenharia de Software ? - Qual a diferena entre Engenharia de

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Mtodo de Engenharia de Software

Copyright 2007, ESAB Escola Superior Aberta do Brasil

No incio da computao poucos programadores seguiam algum tipo de metodologia

Diferenas das Metodologias

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Responda, por escrito, as seguintes perguntas:

O que Engenharia de Software?

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Teoria de Sistemas - Interdependncia de Sistemas

Ns encontramos, nessa imagem, os elementos de ENTRADA e de SADA do SISTEMA. E na

inferior do SISTEMA temos um importante conceito de feed-back chamado de CONTROLE do

Acesse o documento no site abaixo e veja maiores detalhes da interessante

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Quais so os atributos de um bom Software ? - Quais so os desafios

O nvel de confiana do software tem uma gama de caractersticas que

O software no deve desperdiar os recursos do sistema, como memria e

O software deve ser utilizvel, sem esforos indevidos, pelo tipo de

Atributos essenciais de um bom software (adaptado de Sommerville)

Crise do Software e o incio da Engenharia de Software

J em 1988, AMBLER afirmava: Desenvolver software no somente modelar e escrever

Identificar adequadamente os requisitos do Sistema, ou seja, saber o que o

Desafios da Engenharia de Software

Ainda os grandes sistemas de software existentes foram

Os sistemas exigem em ambientes distribudos por redes de

Nos dias atuais existe uma demanda enorme de sistemas que

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Responda, por escrito, as seguintes perguntas com os seus prprios

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Conceitos sobre a Engenharia de Software - O que Software ? A Importncia

desenvolvido/projetado por engenharia, no fabricado

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Importante ressaltar as diferenas entre o SWEBOK e o PMBOK. Estaremos detalhando

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Wikipdia sobre o SWEBOK

Navegue pelo site do SWEBOK (http://www.swebok.org/) e tente baixar

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Modelos de Processo de Software - Paradigmas do desenvolvimento de

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Modelos de Ciclo de Vida de Software;

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Portanto, havia a necessidade se criar um Ciclo de Vida mais inteligente para o

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Paradigmas do Desenvolvimento de Software (continuao) - Modelo

Importante observar a diferena entre INTERATIVO e ITERATIVO. As duas palavras embora

ITERAO possui o significado de: Processo de resoluo (de uma equao, de um

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Basicamente as etapas de desenvolvimento desse modelo so:

Quais as diferenas bsicas entre o Modelo Incremental e a

Copyright 2007, ESAB Escola Superior Aberta do Brasil

O Modelo Espiral basicamente dividido em quatro setores:

Definem-se os objetivos especficos, identificam-se as restries

Com base nos riscos identificados na fase anterior so realizadas

Fundamentado pelas fases anteriores, escolhe-se o modelo mais

O projeto revisto nessa fase, e tomada uma deciso de

Um diferencial nesse modelo comparado com outros, a explcita considerao de riscos

Modelos Mistos e outros