Módulo de

MDULO DE:
ENGENHARIA de SOFTWARE

AUTORIA:

Ms. CARLOS VALENTE

Copyright 2007, ESAB Escola Superior Aberta do Brasil

SUMRIO

UNIDADE 1 .............................................................................................................................. 6
O que Engenharia de Software ? Qual a diferena entre Engenharia de Software e Engenharia
de Sistemas ? O que um mtodo de Engenharia de Software ?

UNIDADE 2 ............................................................................................................................ 10
Teoria de Sistemas Interdependncia de Sistemas

UNIDADE 3 ............................................................................................................................ 12
Quais so os atributos de um bom Software ? Quais so os desafios enfrentados pela
Engenharia de Software ?

UNIDADE 4 ............................................................................................................................ 16
Conceitos sobre a Engenharia de Software O que Software ? A Importncia do Software
SWEBOK

UNIDADE 5 ............................................................................................................................ 20
Modelos de Processo de Software - Paradigmas do desenvolvimento de Software Modelo
Balbrdia Modelo Cascata

UNIDADE 6 ............................................................................................................................ 24
Paradigmas do Desenvolvimento de Software (continuao) Modelo Incremental Prototipao

UNIDADE 7............................................................................................................................ 27
Paradigmas do desenvolvimento de Software (continuao) Modelo Espiral Modelos mistos e
caractersticas genricas


2

UNIDADE 8 ............................................................................................................................ 30
Paradigmas da Engenharia de Software: Processo, Mtodos e Ferramentas

UNIDADE 9 ............................................................................................................................ 33
Caractersticas de um bom processo Caractersticas de um bom ambiente de desenvolvimento

UNIDADE 10 .......................................................................................................................... 36
Introduo ao RUP (Rational Unified Process) Caractersticas Fases e Workflows

UNIDADE 11 .......................................................................................................................... 40
Modelos de Maturidade CMM (Capability Maturity Model)

UNIDADE 12 .......................................................................................................................... 43
Requisitos de Software Requisitos Funcionais e no Funcionais Requisitos de Usurio e de
Sistema

UNIDADE 13 .......................................................................................................................... 46
Tcnicas de Anlise de Requisitos O Documento de Requisitos de Software

UNIDADE 14 .......................................................................................................................... 49
Processos de Engenharia de Requisitos Estudosde Viabilidade

UNIDADE 15 .......................................................................................................................... 51
Modelagem UML: Unified Modeling Language Linguagem de Modelagem Unificada

UNIDADE 16 .......................................................................................................................... 54
Metodologias de Desenvolvimento gil de Software: XP - FDD e DSDM

UNIDADE 17 .......................................................................................................................... 58
Copyright 2007, ESAB Escola Superior Aberta do Brasil 3

Continuao das Metodologias de Desenvolvimento gil de Software: Scrum - Crystal - ASD e
AM

UNIDADE 18 .......................................................................................................................... 62
Engenharia de Projeto Projeto Modular Projeto de interface com o usurio

UNIDADE 19 .......................................................................................................................... 65
Arquiteturas de Sistemas Distribudos - Arquitetura de Multiprocessadores

UNIDADE 20 .......................................................................................................................... 68
Arquitetura cliente/servidor - Arquitetura de objetos distribudos

UNIDADE 21 .......................................................................................................................... 71
Mudanas em Software Dinmica da Evoluo de Programas Evoluo da Arquitetura

UNIDADE 22.......................................................................................................................... 74
Reengenharia de Software Traduo de cdigo fonte - Engenharia Reversa Melhoria de
estrutura de programa

UNIDADE 23 .......................................................................................................................... 76
Reengenharia de Dados e suas abordagens

UNIDADE 24 .......................................................................................................................... 78
Gerenciamento de Configurao Gerenciamento de Mudanas Gerenciamento de Verses e
Releases

UNIDADE 25 .......................................................................................................................... 82
(continuao) Construo de Sistemas Ferramenta CASE

UNIDADE 26 .......................................................................................................................... 85

Sistemas Legados Estruturas dos Sistemas Legados Avaliao dos Sistemas Legados

UNIDADE 27 .......................................................................................................................... 89
Manuteno: fundamentos da fase de Manuteno de Software, tipos de Manuteno,
procedimentos, tcnicas e ferramentas

UNIDADE 28 .......................................................................................................................... 93
Gesto de Projetos de Software e o PMBOK

UNIDADE 29 .......................................................................................................................... 97
Gerenciamento de Qualidade e Estratgias de Teste de Software

UNIDADE 30........................................................................................................................ 101
Engenharia de Software na WEB Sistemas e Aplicaes baseadas na WEB


5

U

NIDADE

1

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
trazerem 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 tecnologias adequadas, e com as
melhores prticas, podemos atender a esses novos desafios. A Engenharia de Software
constitudo de Metodologias, Mtodos e Ferramentas que permitem ao profissional
especificar, projetar, implementar e manter Sistemas, avaliando e garantindo as qualidades
especificadas pelos usurios.


6

Engenharia de Sistemas A Engenharia deSistemas 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.
7


No incio da computao poucos programadores seguiam algum tipo de
metodologiabaseando-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, define-se os dados do sistema em uma posterior seqncia 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.


8

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, asseguintes 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?


9

U

NIDADE

2

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 apia 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 auto-corrigir. Um bom exemplo prtico deste conceito imaginarmos oar
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


11

U

NIDADE

3

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
Facilidade de Manuteno

Descrio
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
conseqncia inevitvel de um ambiente de negcios em constante mutao. O nvel de
confiana dosoftware 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. 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.

Nvel de Confiana

Eficincia

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)

Crise do Software e o incio da Engenharia de Software A crise do software, termo usado nos
anos 70, referia-se as 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 haviam 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 disciplinaenfrentou 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.

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 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. 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. 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 ecomplexos com
a qualidade desejada, e em curto espao de tempo.

O desafio do legado

O desafio da heterogeneidade

O desafio do fornecimento


14

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?


15

U

NIDADE

4

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)


16

Mitos do Software 1 - J temos um manual repleto de padres e procedimentos para a
construo de software. Isso j suficiente para opessoal 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

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 deSoftware
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.


18

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 aonde contm todas as especificaes tcnicas das dez reas do
Conhecimento abordadas por essa importante referncia na Engenharia de Software.


19

U

NIDADE

5

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. Deve-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 pode 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.


20

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. Nessemodelo, 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.


21

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 seqenciais 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 seqenciais, provocaria demoras excessivas, esperas indesejadas e
problemas quando houvesse necessidade de voltar em etapas anteriores. Repare nas duas
figuras abaixo. Embora as duas referem-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 cadaetapa e criado um nome distinto.


22

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??


23

U

NIDADE

6

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 pequenosubsistema 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

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.


25

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.

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 modelosexplicados nessa Unidade voc
escolheria para o desenvolvimento de um Sistema?!?


26

U

NIDADE

7

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 seqncia 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.

O Modelo Espiral basicamente dividido em quatro setores:
SETORES Descrio

ATIVAO

Define-se os objetivos especficos, identifica-se as restries para o processo e preparado um
plano de gerenciamento detalhado. Identifica-se tambm os riscos sem analis-los
profundamente (foco da prxima fase). 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. Fundamentado pelas fases anteriores,
escolhe-se o modelomais 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. 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.

ANLISE de RISCOS

DESENVOLVIMENTO

PLANEJAMENTO

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.
28


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 adequadamente
modularizado, a problemtica. E outro ponto que so altos, por exemplo se existir a no
dominadas pela equipe.nesse modelo que se o sistema no puder ser construo de
componentes necessrios ao RAD ser o RAD pode no ser adequado quando os riscos
tcnicos necessidade de uma aplicao usufruir tecnologias novas

Um 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


29

U

NIDADE

8

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 dosoftware. 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.


30

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. Esse 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). Metodologias de Desenvolvimento gil: Existem varias metodologias
que podem ser consideradas como abordagens geis: XP, ASD, DSDM, Scrum, Crystal, FDD, AM
entreoutras. Veremos com maior 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 ?!?


32

U

NIDADE

9

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
seqncia 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. Adaptvelpara 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.


33

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.


34


Pesquise em sua empresa, ou na de um colega, como constitudo o ambiente de
desenvolvimento da equipe de Sistemas. Como a sua infra-estrutura? Que ferramental
possuem 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.


35

U

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).Sistemasconcebidos 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

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

Descrio

Iniciao
(Inception)

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.

Elaborao
(Elaboration)

Construo
(Construction)

Transio
(Transition)

Implantar o produto no ambiente de produo.


37

Workflow de Processo Estruturar um projeto junto dimenso de componente de processo
inclui asseguintes atividades:
ATIVIDADES

Descrio

Modelagem do negcio Descreve o negcio atravs de casos de uso de negcio. Requisitos
Anlise e Projeto Implementao Testes Distribuio
Narrativa da viso do sistema. Descrio das funes do sistema. Descrio de como o sistema
ser realizado na etapa de implementao. Produo do cdigo que resultar em um sistema
executvel. Verificar a integrao entre todos os componentes de software, identificar e
corrigir erros de implementao. Gerar um release do produto. Entrega do produto e
treinamento dos usurios.


38

Workflow de Suporte

ATIVIDADES

Descrio Especifica um conjunto de princpios a aplicar na gesto de projetos no nvel da
alocao de recursos, planejamento, identificao e gesto de riscos, etc. Controla as
mudanas e mantm a integridade dos artefatos do projeto. Cobre a infra-estrutura necessria
para desenvolver um sistema (seleo de ferramentas, definio das regras de negcio,
interface, testes, etc)

Gesto de Projetos Gesto de Configurao e Mudana Definio do Ambiente

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


39

U

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 deMaturidade 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


40

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)
omodelo 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 encontram-se. Capacidade de
repetir sucessos anteriores atravs do acompanhamento de custos, cronogramas e
funcionalidades. O processo de software bem definido, documentado e padronizado. Realiza
uma gerncia quantitativa e qualitativa do processo de software e do produto. Usa a
informao quantitativa para melhorar continuamente e gerenciar o processo de software.

Nvel 2 Repetitivo

Nvel 3 Definido

Nvel 4 Gerenciado

Nvel 5 Em Otimizao


41

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 ?!?


42

U

NIDADE

12

Requisitos de Software - Requisitos Funcionais e no Funcionais - Requisitos de Usurio e de
Sistema
Objetivo: Identificar os vrios tipos de requisitos e suasdefinies. 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 as ambas 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.


43

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.
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 explicita, declarar o que o sistema no deve fazer.
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

Requisitos Funcionais

Requisitos no Funcionais

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 r e q u ir e m e n t s

O r g an iz a t io n a l r e q u ir e m e n t s

E x te r n a l r e q u ir e m e n t s

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 r e q u ir e m e n t s

Po rt a b il it y r e q u ir e m e n t s

I n t e ro p e r a b il it y r e q u ir e m e n t s

E t hi c a l r e q u ir e m e n t s

U s ab il it y r e q u ire m e n t s

D e l iv e r y r e q u ir e m e n t s

I m p l e m e n t a t io n r e q u ir e m e n t s

S t a n d ar d s r e q u ir e m e n t s

L e g is la t iv e r e q u ir e m e n t s

P e r f o rm a n c e r e q u ir e m e n t s

S p a ce r e q u ir e m e n t s

P r iv a c y r e q u ir e m e n t s

S a f e ty r e q u ir e m e n t s


44

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.


45

U

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,
implementada 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 visodo 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.


46

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 produtividadeir 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.


47

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 RequisitosFuncionais 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.).


48

U

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


49

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 dacontinuidade 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.


50

U

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

Descrio

Diagrama de Caso de Uso Diagrama de Classe

Mostra atores (pessoas ou outros usurios do sistema), casos de uso (os cenrios onde eles
usam o sistema), e seusrelacionamentos. Diagrama as classes e os relacionamentos entre elas.

Diagrama de Seqncia Diagrama de Colaborao Diagrama de Estado Diagrama de Atividade
Diagrama de Componente Diagrama de Distribuio

Mostra objetos e uma seqncia 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 num objeto ou 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 Seqncia 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.

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


53

U

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 constante
e trabalham junto com os usurios/clientes;

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.


55

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 queocorrem no contexto de quatro atividades (veja a figura ao lado):
Planejamento Projeto Codificao Teste

Existe um grande nfase ao trabalho em duplas, aonde 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.

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 todosos 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?!?


57

U
Scrum

NIDADE

17

Continuao das Metodologias de Desenvolvimento gil de Software: Scrum Crystal - ASD e
AM
Objetivo: Abordar as vrias metodologias geis e suas aplicaes

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 desdea ltima Reunio
Scrum ? Que obstculos voc est encontrando que podemos ajudar ? O que voc planeja
realizar at a prxima Reunio Scrum ?


58

Crystal Criado por Alistair Cockburn e Jim Highsmith com intuito de fazer uma analogia com os
cristais geolgicos onde 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 ummodo 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):
59


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 otrabalho de Engenharia de Software
prossegue, conserve apenas aqueles modelos que fornecero valor a longo prazo e livre-se do
resto.


60

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.


61

U

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 constri 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 parasatisfazer aos requisitos do Sistema (adaptado de
Pressman). Veja a figura abaixo, aonde apresentado os vrios mdulos do ERP da SAP.


62

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.
63

Copyright 2007, ESAB EscolaSuperior Aberta do Brasil

Consistncia Mnimo de surpresa Facilidade de recuperao Orientao do usurio Diversidade
de usurios

Sempre que possvel, operaes semelhantes devem ser ativadas da mesma maneira. Os
usurios nunca devem ser surpreendidos com o comportamento do Sistema. A interface deve
incluir mecanismos para permitir aos usurios a recuperao a partir de erros humanos. Na
ocorrncia de erros fornecer feedback significativo, e oferecer recursos sensveis ao contexto
de ajuda. 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


64

U

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 Distribudosso:
CARACTERSTICAS Descrio

Compartilhamento de Recursos Abertura

Compartilha recursos de hardware e de software gerenciados por computadores centrais, ou
servidores. Pode-se facilmente incluir hardware e software de diferentes fabricantes. Vrios
processos podem operar ao mesmo tempo em diferentes computadores na rede. Em princpio,
pode-se aumentar infinitamente a capacidade dos Sistemas distribudos, somente limitado
pela capacidade de sua rede. Com a estrutura dos Sistemas Distribudos, h o potencial da
duplicao de informaes, evitando algumas falhas de hardware e software.

Concorrncia

Escabilidade

Tolerncia a Defeitos

Transparncia

Embora tendo complexidade alta, os usurios conseguem o que querem do Sistema, e sem a
necessidade de se inteirar dessa complexidade.

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


66

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 Sistemasde 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


67

U

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.

c2

c3

c4

c12 c11 Server process

c1

s1

s4 c10

c5 s2 s3 c9 c8

Client process

c6

c7

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. Noprimeiro modelo todo o
processamento realizado no servidor. A segunda estrutura mais complexa e mais comum.
O servidor


68

responsvel somente pelo gerenciamento de dados. E nos clientes implementado 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.

O middleware intermedeia os computadores a ele conectado. 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 emdiferentes 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.

Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE
AULA e faa a Atividade 2 no link ATIVIDADES.


70

U

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 Manuteno

Os sistemas normalmente evoluem de uma arquitetura mais centralizada, para uma
arquitetura cliente/servidor (veremos a seguir nesta mesma Unidade). Quando a estrutura fica
estvel, mas sofre modificaes para adaptar a novos requisitos dos usurios (veremos mais
detalhes na Unidade 27). Ao contrrio daManuteno, sofre alteraes na estrutura, para que
o sistema torne-se mais fcil sua compreenso e tambm para alteraes (veremos mais
detalhes na Unidade 22).

Reengenharia


71

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 utilizam. 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
seqncia 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 aarqutetura de um sistema, a partir de uma
arquitetura centralizda, centrada em dados, para uma arquitetura distribuda. Tanto a
interface com o usurio quanto a funcionalidade do sistema podem ser distribudas.

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.im.ufba.br/pub/Residencia/MaterialModuloTI1/
slides_aula04arquiteturadesoftware.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.


73

U

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 deReengenharia de Software. Embora, nem toda reengenharia
passe por todos esses processos, essencialmente o programa reestruturado. Vejamos mais
detalhadamente o que cada processo realiza (caixas arrendodadas).

Processo de Reengenharia conforme a viso de Sommerville
74


PROCESSOS

Descrio

Traduo de cdigo-fonte Engenharia Reversa Melhoria de estrutura do programa
Modularizao de programa Reengenharia de dados

O programa convertido da linguagem de programao original para uma verso mais
moderna ou mesmo para uma nova linguagem mais adequada. O programa analisado
conforme essas tcnicas e as informaes so extradas dele, a fim de ajudar a documentar sua
organizao e funcionalidade. 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.
Partes em comum do programa so agrupadas e, quando apropriado, a redundncia
removida. Em alguns casos, esse estgio pode envolver a transformao da arquitetura. 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


75

U

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 chamado de
Reengenharia de Dados. Vejamos, a seguir, aspossveis abordagens visualizadas por
Sommerville:

ABORDAGENS

Descrio

Limpeza de dados

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.

Extenso de dados

Migrao de dados


76

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.


77

U

NIDADE

24
Gerenciamento de Mudanas -

Gerenciamento de Configurao Gerenciamento de Verses e Releases

Objetivo: Abordar os principais aspectos do gerenciamento de mudanas Gerenciamento
deConfigurao 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 Gerenciamento de Mudanas

Descrio Descreve os padres e os procedimentos que devem ser utilizados para o
Gerenciamento de Configurao. 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 Construo de Sistemas

Consiste em acompanhar e identificar o desenvolvimento das diferentes verses e releases de
um Sistema. 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

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 exemplodo 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 existe 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.


79

Para a devida identificao de componentes existem trs tcnicas bsicas:
TCNICAS BSICAS

Descrio Esse o esquema de identificao mais comum. Atribu-se um nmero, explcito e
nico, de verso ao componente (ver figura) Cada componente recebe um nome e um
conjunto de atributos (que no nico em todas as verses). Alm do anterior associado
uma ou mais solicitaes de mudana.

Numerao de verses

Identificao baseada em atributos Identificao orientada a mudanas


80

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 a excelente qualidade dos artigos colocados no Wikipdia especificamente neste tema,
e para voc explorar mais detalhamente os assuntos dessa unidade, visite e leia todos os links
mencionados no item anterior chamado ESTUDO COMPLEMENTAR.


81

U

NIDADE

25

(continuao) Construo de Sistemas - Ferramenta CASE
Objetivo: Explorar o conceito daferramenta 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 igual 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 de 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.

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 tem 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
RationalRose da IBM:


83

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.


84

U

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, sero to
grandes, 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 a par 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.


85

Os servios sobrepem interagindo com outros componentes do Sistema. A interface com o
usurio e o cdigo do servio esto integrados 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.

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. Manter sistemas desse tipo em operao
dispendioso, e a taxa de retorno de investimento para os negcios bastante pequena. Esses
sistemas so fortescandidatos a receberem nenhum investimento, e mesmo a serem
descartados. 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.
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.

Baixo Valor de Negcios X Baixa Qualidade

Alto Valor de Negcios X Alta Qualidade

Baixo Valor de Negcios X Alta Qualidade


87

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?!?


88

U

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: aonde afirma
que um programa utilizado emum 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 Manuteno para reparar
os defeitos no software Manuteno para adaptar o software a um ambiente operacional
diferente Descrio 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. 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.


89

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.


90

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 aonde se detecta previamente aonde 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:


91

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?!?


92

UNIDADE

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 caracterizam 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 desenvolvimentoconstantemente 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.
93


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 parntesis
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)


94


95

Wikipdia http://pt.wikipedia.org/wiki/PMBOK
http://pt.wikipedia.org/wiki/Gerenciamento_de_Projetos

Site do PMBOK, e no Brasil
http://www.pmi.orghttp://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.


96

U

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 At que ponto o processo est definido e com que facilidade se compreende a
definio do processo ? As atividades culminam em resultado ntidos, de forma que o
progresso do processo seja visvel ? At que ponto as atividades do processo podem ser
apoiadas por ferramentas CASE ?

Facilidade de compreenso Visibilidade Facilidade de suporte

Aceitabilidade O processo aceitvel e utilizvel pelos desenvolvedores ? Confiabilidade
Robustez Facilidade de manuteno Rapidez
Os erros podem ser evitados ou identificados antes que o produto seja entregue aos usurios ?
Existe continuidade no processo mesmo que surjam problemas inesperados ? Existe evoluo
no processo para refletir os requisitos mutveis da organizao oupara receber melhorias ? A
partir de uma determinada especificao com que rapidez pode ser alterado o processo ?
97


(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 tem pontos positivos e negativos. O mais comum
utilizar a abordagem Top-down, por ser mais natural.

TOPLevel 1 Testin g sequen ce Level 1 . ..

Test d ri ve rs Le v e l N Le ve l N Le ve l N Le v e l N Le v e l N s

Level 2 Le vel 2 stubs

Level 2

Le vel 2

Level 2
Test d ri v e rs

Leve l N 1

Le v el N 1

Le v e l N 1

Le vel 3 stubs

BOTTOM-UP

Testes Alfa e Beta


98

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 dos seus estgios iniciais de
instalao, at a sua operao completa. Tudo isso realizado num ambiente especial, aonde
fiquem registrados 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 so selecionados 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,
registrado 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 TesteCaixa-Branca realiza testes na
estrutura dos componentes de um Sistema, o Caixa-Preta refere-se s 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


99

No caso dos Testes de Caixa-Preta que focaliza 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?


100

U

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 utilizado a sigla WebE, oprocesso 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 peculiariedades 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 freqentemente, 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 as 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
101


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 Projeto de
Interface Descrio Descreve a estrutura e organizao da interface com o usurio. Atenta
para os esquemas de cor, leiaute, fonte, uso de grficos, etc. Define a estrutura e o esboo de
todo o contedo, relacionando os objetos de contedo.
102

Projeto Esttico

Projeto de Contedo


Projeto de Navegao

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

Projeto Arquitetural

Projeto de Componente

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 serclaramente 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 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

b e h av io r re q u e st ( st at e ch an g e )

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
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

u p d at e re q u e st

e xt e rn al d at a

se rv e r


103

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 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. Gerarequisies do usurio, seleciona
comportamento do Modelo e seleciona resposta de viso. o cdigo que gera
os dados dinmicos para dentro da pgina HTML.

VISO CONTROLADOR

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


104

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, aborda-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 qualidade planejadas.

Requisitos
Ter realizado e sidoaprovado 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.
105


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.

Antes de dar continuidades aos seus estudos fundamental que voc acesse
sua SALA DE AULA e faa a Atividade 3 no link ATIVIDADES.


106

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 o
aluno realize novamente.


107

Módulo de

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Módulo de

Enviado por

Direitos autorais:

Formatos disponíveis

MDULO DE:

Você também pode gostar