Módulo 2

MDULO DE:
ENGENHARIA de SOFTWARE
AUTORIA:
Ms. CARLOS VALENTE
Copyright 2007, ESAB Escola Superior Aberta do Brasil
SUMRIO
Contedo
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
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 Estudos de 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
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
UNIDADE 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 trazer um pouco mais de luz para essa atividade complexa. A cobrana hoje das reas de Informtica e de T.I. (Tecnologia da Informao) desenvolver Sistemas de forma rpida, com qualidade, e com custos cada vez menores. Somente atravs 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.
Engenharia de Sistemas A Engenharia de Sistemas mais genrica e mais abrangente do que a Engenharia de Software. Na verdade, a segunda faz parte da primeira. A Engenharia de Sistemas mais antiga do que a de Software. Enquanto a primeira est mais envolvida com o Sistema como um todo e seus detalhes, a Engenharia de Software mais especfica no que tange aos componentes do sistema, em especial ao hardware e software.
Mtodo de Engenharia de Software Sommerville afirma que um mtodo de Engenharia de Software uma abordagem estruturada para o desenvolvimento de software. Podemos definir como abordagem estruturada a estratgia de desenvolver algo com uma estrutura previamente estudada, ou baseada nas melhores prticas. O objetivo maior de tudo isso facilitar a produo, em curto espao de tempo, de software de alta qualidade, apresentando uma relao custo-benefcio interessante. Um ponto importante a observar que no existe, repito, no existe um mtodo ideal. As possibilidades e os ambientes de desenvolvimento so to complexos, que dependendo de cada situao e momento, existe um mtodo que possa explorar mais alguns tpicos, mas deixar outros em aberto. Outro ponto a ressaltar que existem vrios mtodos na Engenharia de Software, mas poucas Metodologias. Podemos entender Metodologia tanto pelas palavras de Maddison, como sendo um conjunto recomendado de filosofias, fases, procedimentos, tcnicas, regras, ferramentas, documentao, gerenciamento e treinamento para o desenvolvimento de um sistema de informao, como tambm o estudo de um ou mais mtodos.
7
No incio da computao poucos programadores seguiam algum tipo de metodologia baseando-se, em sua maioria, na prpria experincia. Na Engenharia de Software existem basicamente duas grandes metodologias. Uma originria da dcada de 70 chamada de Metodologia Estruturada, e a mais recente intitulada de Metodologia Orientada a Objetos.
Diferenas das Metodologias Tanto a abordagem estruturada quanto a orientada a objetos promovem solues prticas. A diferena entre as duas metodologias a vida til e facilidade de manuteno de projetos. A possvel reutilizao de um cdigo estruturado no comum, enquanto que um cdigo orientado a objetos por possuir embutido em sua prpria filosofia as facilidades de reutilizao e de descrio, utilizando UML (Unified Modeling Language), aumenta naturalmente a vida til dos cdigos. Abordando o software sob um ponto de vista puramente estruturado, define-se os dados do sistema em uma posterior sequncia de eventos que acarretar na transformao do estado do sistema. Por outro lado, numa abordagem focada em orientao a objetos, definem-se estruturas abstratas, denominadas classes, que sero responsveis por partes da soluo do problema. Cada classe incorporar dados (forma) e mtodos (comportamentos). Projetos orientados a objetos utilizam da linguagem de modelagem UML (Unified Modeling Language). Esta linguagem fruto dos esforos, em conjunto, dos autores Booch, Rumbaugh e Jacobson.
Wikipdia http://pt.wikipedia.org/wiki/Engenharia_de_software http://pt.wikipedia.org/wiki/Metodologia_(engenharia_de_software) Oua um PODCAST sobre METODOLOGIAS: http://www.improveit.com.br/podcasts/quem-se-importa-commetodologia.mp3
Responda, por escrito, as seguintes perguntas: O que Engenharia de Software? Qual a diferena entre Engenharia de Software e Engenharia de Sistemas? O que um mtodo de Engenharia de Software?
UNIDADE 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.
10
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 o ar condicionado. Parte-se inicialmente da base de uma temperatura estabelecida por ns (PADRO). O sensor mensura as variaes de temperatura. E o ATIVADOR ir deixar o ar condicionado ativado at novamente o SENSOR verificar que a temperatura est no PADRO desejado.
Wikipdia http://pt.wikipedia.org/wiki/Teoria_de_sistemas
Acesse o documento no site abaixo e veja maiores detalhes da interessante Teoria de Sistemas: http://www.abdl.org.br/filemanager/download/4/teoria% 20de%20sistema.pdf
11
UNIDADE 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 do software tem uma gama de caractersticas que incluem confiabilidade, proteo e segurana. O software confivel no deve ocasionar danos fsicos ou econmicos, no caso de um defeito no sistema. 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)
12
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 disciplina enfrentou foram: Identificar adequadamente os requisitos do Sistema, ou seja, saber o que o software deve fazer; Que ferramentas, linguagem, sistema operacional usar; Como diminuir os tempos e custos de desenvolvimento; Prever falhas antes da entrega final; Como fazer manuteno e controlar verses; Dificuldades de prever o progresso durante o desenvolvimento; Inexistncia de histrico, ou documentao, no desenvolvimento de Sistemas; Comunicao com os usurios precria; Conceitos quantitativos inexistentes tais como confiabilidade, qualidade e reusabilidade; Manuteno, no software existente, com difcil execuo.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 13
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 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 e complexos 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
UNIDADE 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 o pessoal do desenvolvimento. 2 - Meu pessoal tem ferramentas de ltima gerao, afinal de contas compramos os mais novos computadores. 3 - Se ns estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. 4 - Uma declarao geral dos objetivos suficiente para se comear a escrever programas, podemos preencher os detalhes mais tarde. 5 - Os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser facilmente acomodadas, porque o software flexvel. 6 - Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estar completo. 7 - Enquanto no tiver o programa funcionando, eu no terei realmente nenhuma maneira de avaliar sua qualidade. 8 - A nica coisa a ser entregue em um projeto bem-sucedido o programa funcionando.
Importncia do Software Um dos pontos fundamentais da importncia do software pelo seu uso cotidiano, aonde praticamente no mundo moderno, inexiste a possibilidade de no utiliz-lo. E o outro ponto pela manipulao da informao (dado - informao - conhecimento), e quem a tem possui poder.
SWEBOK O SWEBOK (Guide to the Software Engineering Body of Knowledge) o documento tcnico desenvolvido com o apoio do IEEE (Instituto de Engenheiros Eltricos e Eletrnicos, tambm popularmente chamado de I3E). Esse documento estabelece uma classificao hierrquica
17
dos tpicos tratados pela Engenharia de Software, onde o nvel mais alto so as reas do Conhecimento. As dez reas do Conhecimento tratadas pelo SWEBOK so:
Requisitos de Software Projeto de Software Construo de Software Teste de Software Manuteno de Software Gerncia de Configurao de Software Gerncia da Engenharia de Software Processo de Engenharia de Software Ferramentas e Mtodos da Engenharia de Software Qualidade de Software
Importante ressaltar as diferenas entre o SWEBOK e o PMBOK. Estaremos detalhando melhor o PMBOK na Unidade 28. Mas, somente mostrando genericamente o diferencial dos dois, que enquanto o SWEBOK dirigido especificamente para a Engenharia de Software, o PMBOK mais generalizado quanto a Gerenciamento de Projetos como um todo.
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. Assista o vdeo muito legal de um exemplo de software embutido, no caso, um circuito de controle de elevador em: http://br.youtube.com/watch?v=RSmTUsFtqdg
19
UNIDADE 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 da 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. Nesse modelo, o software tende a entrar num ciclo de somente duas fases: o de implementao e de implantao. E os ajustes ao software para atender aos novos requisitos, sempre so em clima de urgncia e de stress, motivados por vrios fatores, e principalmente por presso poltica.
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.
21
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 cada etapa e criado um nome distinto.
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
UNIDADE 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 pequeno subsistema funcional e ento adicionadas mais funcionalidades a cada verso. Pode-se ento dizer que o Modelo Incremental chega lentamente funcionalidade total, por meio dessas novas verses.
Importante observar a diferena entre INTERATIVO e ITERATIVO. As duas palavras embora com escrita extremamente parecidas, e muitas utilizadas em Informtica, possuem significados distintos. Quanto palavra ITERATIVO 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
24
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 2, 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 que o desenvolvimento do software evolui, o usurio passa a ser um co-autor do desenvolvimento.
Wikipdia http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software http://pt.wikipedia.org/wiki/Desenvolvimento_interativo_e_incremental http://pt.wikipedia.org/wiki/Prototipac%C3%A3o
Quais as diferenas bsicas entre o Modelo Incremental e a Prototipao ?!? Qual a diferena entre ITERATIVO e INTERATIVO?!? Quais dos dois modelos explicados nessa Unidade voc escolheria para o desenvolvimento de um Sistema?!?
26
UNIDADE 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.
27
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 modelo mais adequado para o desenvolvimento do Sistema. A bagagem profissional e a vivncia do desenvolvedor em outros sistemas, so estratgicas para essa fase. Dependendo da complexidade do Sistema, s vezes, necessria a presena de um consultor especialista. 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
UNIDADE 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 do software. Sua meta fundamental entregar, de maneira eficiente e previsvel um produto de software capaz de atender as necessidades de negcio, definidas pela anlise de requisitos, dos usurios. 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.
30
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 entre outras. Veremos com maior detalhes essas Metodologias nas Unidades 16 e 17.
31
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
UNIDADE 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. Adaptvel para diferentes tamanhos e tipos de projetos. Bem definido, gerencivel e repetvel. Com nomenclatura universal e mtricas para planejamento e gerenciamento do projeto. Integrado com ferramentas que o suportem.
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
Wikipdia http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software
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?
35
UNIDADE 10
Introduo ao RUP (Rational Unified Process) - Caractersticas - Fases e Workflows
Objetivo: Conceituar RUP e suas principais caractersticas. RUP (Rational Unified Process) usa a abordagem da orientao a objetos em sua concepo e projetado e documentado utilizando a notao UML (Unified Modeling Language) para ilustrar os processos em ao. Utiliza tcnicas e prticas aprovadas pelo mercado. Atualmente o RUP um produto desenvolvido e mantido pela Rational Software (Diviso IBM).Sistemas concebidos por esse processo normalmente so desenvolvidos um uma linguagem de programao orientada a objetos, como Java ou C++.
As principais caractersticas do RUP so: Desenvolvimento Interativo Gerncia de requisitos Uso de arquitetura baseada em componentes Modelagem visual Controle contnuo da qualidade Gerncia de mudanas
36
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. Implantar o produto no ambiente de produo.
Elaborao
(Elaboration)
Construo
(Construction)
Transio
(Transition)
37
Workflow de Processo Estruturar um projeto junto dimenso de componente de processo inclui as seguintes atividades:
ATIVIDADES
Descrio
Modelagem do negcio Descreve o negcio atravs de casos de uso de negcio. Requisitos 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
UNIDADE 11
Modelos de Maturidade CMM (Capability Maturity Model)
Objetivo: Conceituar Modelos de Maturidade e a sua importncia na Engenharia de Software Modelos de Maturidade O conceito de Modelo de Maturidade de Capacitao para Software, que um metamodelo de PROCESSO, foi desenvolvido pela Carnegie Mellon University atravs do seu rgo SEI (Software Engineering Institute). O SEI um centro de pesquisa e desenvolvimento criado, em 1984, pelo Departamento de Defesa dos Estados Unidos. Podemos definir Capacitao para Software como sendo a habilitao que a organizao tem em sistematicamente produzir software possuindo a qualidade esperada, dentro dos prazos concordados e com os recursos alocados.
Atente para o grfico apresentado. Ele representa que quanto maior a capacitao, menor ser a variao dos erros de estimativa (de custos, prazos, etc.) em torno da mdia. Ou seja, enquanto no grfico da esquerda as estimativas fogem muito da mdia, o da direita as variaes em relao mdia foram aprimoradas aps a implantao do CMM (nvel 5). O CMM (Capability Maturity Model) o mais famoso representante desse conceito. Ele basicamente uma metodologia de diagnstico e avaliao da maturidade da capacitao em desenvolvimento de softwares numa organizao (empresa ou instituio). O objetivo maior do CMM determinar em que estgio de maturidade uma empresa est em seu ciclo de desenvolvimento de software. Nasceu da necessidade do Departamento de Defesa americano em como avaliar as empresas terceirizadas que desenvolviam softwares para eles.
40
O uso de estratgia de melhoria de processos atravs de avaliao contnua, identificao de problemas e suas devidas aes corretivas permite estabelecer cinco nveis de maturidade (veja a tabela em seguida). CMMi (Capability Maturity Model Integration) o modelo de maturidade surgido recentemente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de melhoria corporativo. Somente por curiosidade, raras so as empresas no mundo que conseguem atingir o nvel 5, a grande maioria fica nos estgios iniciais. No Brasil, at o presente ano (2007), existiam somente 4 empresas que tinham alcanado o nvel 5 do CMMi.
Estgios Descrio
Nvel 1 Inicial
Catico, estgio aonde que a maioria das empresas de software 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
UNIDADE 12
Requisitos de Software - Requisitos Funcionais e no Funcionais - Requisitos de Usurio e de Sistema
Objetivo: Identificar os vrios tipos de requisitos e suas definies. muito comum que o cliente no saiba o que ele realmente deseja, que haja problemas na comunicao e ainda que haja mudana constante desses requisitos. O termo requisito pode ser utilizado na indstria de software tanto com o significado de algo abstrato, como matematicamente formal. Para aprimorar esse conceito A.M.Davis ilustra o seguinte case em seu livro Software requirements - objects, functions and states: Se uma empresa deseja estabelecer com contrato para o desenvolvimento de um grande projeto de software (para selecionar entre vrios fornecedores), ela tem de definir suas necessidades de maneira suficientemente abstrata para que uma soluo no seja predefinida. Os requisitos devem ser redigidos de modo que os diversos fornecedores (de software) possam apresentar propostas, oferecendo, talvez, diferentes maneiras de atender s necessidades organizacionais do cliente. Uma vez estabelecido um contrato (entre 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. Estabelecem detalhadamente as funes e as restries de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificao funcional, deve ser preciso. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor do software.
Requisitos de Sistema (ou do desenvolvedor)
43
Requisitos Funcionais
So declaraes de funes que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como deve se comportar em determinadas situaes. Em alguns casos, os requisitos funcionais podem, de forma 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 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
Et 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 ir e 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
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.
44
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
UNIDADE 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 viso do negcio do usurio/cliente. Alm de ser importante para essa atividade, todos gostam de responder questionamentos sinceros sobre as suas atividades. Princpio n 3: Deve existir um facilitador na reunio. No interessante que o prprio analista seja o condutor dessa reunio. Existindo um personagem como facilitador na reunio, ameniza problemas de discusses ou maus entendidos. Seria praticamente um animador das discusses. Princpio n 4: Foco da discusso num Desenho ou Documento, no nas pessoas. Se a discusso por ventura ficar pessoal, deve-se sempre voltar o foco da reunio para um desenho, documento ou mesmo sobre o processo envolvido. Isso abranda possveis conflitos pessoais.
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 produtividade ir aumentar. Princpio n 8: Se algo no estiver claro, sempre desenhe. Como o velho provrbio diz: Uma imagem vale mil palavras. No existe a necessidade de aplicar as tcnicas de modelagem nessa hora, mas com desenhos simples, mapas mentais, transparncias do PowerPoint, quadros e imagens ajudam muito nessa fase do projeto. DICA: visite o site www.mapasmentais.com.br para ver a tcnica que a prpria NASA utiliza em seus projetos. Princpio n 9: (a) Se voc concorda com algo, prossiga; (b) Se voc no concordar com algo, prossiga; (c) Se algo no estiver claro, e sem condies de esclarecer naquele momento, prossiga. H momentos que no adianta, como se diz no popular, dar murro em ponta de faca. Prepare-se e aguarde o momento certo para voltar a tocar num tema polmico. O uso da criatividade, na abordagem de um tema desse tipo, super estratgico. Princpio n 10: Negociar sempre no ganha-ganha. Existem vrias posturas numa negociao entre dois personagens (perde-perde, ganhaperde, perde-ganha e ganha-ganha). A melhor relao o ganha-ganha. Essa a postura dos vencedores. Ou seja, conduzida a soluo de conflitos de tal forma criativa e rica em oportunidades, que os dois lados ganham na negociao. DICA: o site http://www.golfinho.com.br/artigos/artigodomes1299.htm 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 Requisitos Funcionais o Requisitos de Interface o Requisitos no Funcionais Anlise de Risco Anexos
Wikipdia http://pt.wikipedia.org/wiki/Requisitos_de_Software
Veja o documento de Especificao de Requisitos de Software em http://www.ic.unicamp.br/~ariadne/inf301/doc-requisitos.pdf e tente voc mesmo gerar um documento com base num Sistema genrico (um sistema hipottico, ou um sistema que voc est trabalhando, ou ainda um sistema que precisaria ser desenvolvido, etc.).
48
UNIDADE 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 da continuidade no desenvolvimento do Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rpido, dever abordar fundamentalmente as seguintes questes: O Sistema proposto contribui para os objetivos gerais da organizao ? O Sistema poder ser implementado com as tecnologias dominadas pela equipe dentro das restries de custo e de prazo ? Ou precisaria de treinamentos adicionais ? O Sistema pode ser integrado, e compatvel com os outros sistemas j em operao ?
Wikipdia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos
Como estamos explorando constantemente o WIKIPDIA, queremos que voc entre no site http://pt.wikipedia.org/wiki/Engenharia_de_software e veja o que voc pode aprimorar e contribuir para melhorar cada vez mais essa fantstica enciclopdia virtual.
50
UNIDADE 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 Diagrama de Seqncia Diagrama de
Mostra atores (pessoas ou outros usurios do sistema), casos de uso (os cenrios onde eles usam o sistema), e seus relacionamentos. Diagrama as classes e os relacionamentos entre elas. Mostra objetos e uma seqncia das chamadas do mtodo feitas para outros objetos. Apresenta objetos e seus relacionamentos, colocando
51
Colaborao Diagrama de Estado Diagrama de Atividade Diagrama de Componente Diagrama de Distribuio
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.
52
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
UNIDADE 16
Metodologias de Desenvolvimento gil de Software: XP - FDD e DSDM
Objetivo: Abordar as vrias metodologias gieis 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;
54
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 que ocorrem 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 todos os envolvidos os avanos e problemas que o Projeto vai sofrendo. Para tanto, o FDD define seis marcos de referncia durante o projeto e implementao de uma caracterstica: Travessia do projeto; Projeto; Inspeo do projeto; Cdigo; Inspeo do cdigo; Promoo para a construo.
Wikipdia http://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software Outros sites: http://iscte.pt/~mms/events/agile_seminar/apresentacoes.htm http://letshyve.wordpress.com/2007/04/26/o-manifesto-agil/
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
UNIDADE 17
Continuao das Metodologias de Desenvolvimento gil de Software: Scrum Crystal - ASD e AM
Objetivo: Abordar as vrias metodologias gieis e suas aplicaes Scrum O significado peculiar desse modelo de desenvolvimento gil vem do nome da atividade de jogadores de rugby ao trabalharem fortemente juntos para deslocar a bola pelo campo. Foi desenvolvida por Jeff Sutherland, ainda na dcada de 90. Seus princpios bsicos seguem o manifesto gil. Um ponto que se destaca nesse modelo so as Reunies Scrum. Sugere-se que sejam realizadas diariamente por 15 minutos, mas com base em nossa realidade brasileira, acreditamos que o perodo ideal seria semanal, com uma durao de 1 hora (preferencialmente as sextas-feiras tarde). So somente trs questes que so apresentadas para todos os envolvidos, e com excelentes resultados. Todos devem apresentar suas respostas com base nas seguintes perguntas: O que voc fez desde a ltima Reunio Scrum ? Que obstculos voc est encontrando que podemos ajudar ? O que voc planeja realizar at a prxima Reunio Scrum ?
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 um modo que conduza ao efetiva. medida que os membros de uma equipe ASD comeam a desenvolver os componentes que fazem parte de um ciclo adaptativo, a nfase est Aprendizado tanto no aprendizado quanto no progresso em direo a um ciclo completo.
AM Agile Modeling Conforme o site que se auto-intitula The Official Agile Modeling (veja maiores detalhes, e vale a pena visitar, em: http://www.agilemodeling.com/) Scott W. Ambler, seu criador, descreve a Modelagem gil (AM) como sendo (adaptado por ns):
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 o trabalho 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
UNIDADE 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 ? Pode-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 juntas 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 toda as partes de um Sistema, antes dele mesmo existir. Veremos mais detalhes sobre Gesto de Projetos na Unidade 28. Projeto Modular A Modularidade consiste na diviso do software em componentes nomeados separadamente e endereveis, muitas vezes chamado de mdulos. Os mesmos so integrados para satisfazer aos requisitos do Sistema (adaptado de Pressman). Veja a figura abaixo, aonde apresentado os vrios mdulos do ERP da SAP.
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 ou mesmo no Brasil atravs do www.secondlifebrasil.com.br Podemos ver na tabela abaixo, as diretrizes gerais para a elaborao de uma boa interface com o usurio:
DIRETRIZES Descrio
Familiaridade com o usurio Consistncia Mnimo de surpresa Facilidade de recuperao Orientao do usurio Diversidade de usurios
Deve utilizar termos e conceitos que tenham como base a experincia das pessoas que vo utilizar o sistema. 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.
63
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
Veja com maiores detalhes da Interface Usurio-Mquina no site: http://www3.ufpa.br/wiki-clima/images/1/14/Trabalho_ESI.pdf(link inativado pelo proprietrio)
64
UNIDADE 19
Arquiteturas de Sistemas Distribudos - Arquitetura de Multiprocessadores
Objetivo: Diferenciar as vrias e principais arquiteturas de sistemas Os sistemas com base em Mainframes, ou seja, computadores de grande porte, na prtica so Sistemas Distribudos. O conceito de Sistema Distribudo a conexo de vrias mquinas iguais, ou mesmo diferentes, para processar um ou mais sistemas. Os trs principais sistemas existentes atualmente so: Sistemas pessoais Sistemas embutidos Sistemas distribudos
Nos primeiros temos como exemplo os editores de texto e as planilhas eletrnicas. Um exemplo de Sistema embutido seria a ignio eletrnica, aonde num processador existe toda uma lgica de controle. As mais importantes caractersticas dos Sistemas Distribudos so:
CARACTERSTICAS Descrio
Compartilhamento de Recursos 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. Embora tendo complexidade alta, os usurios conseguem o que querem do Sistema, e sem a necessidade de se inteirar dessa complexidade.
Concorrncia
Escabilidade
Tolerncia a Defeitos
Transparncia
Por outro lado, as principais desvantagens desse Sistema so: Alta Complexidade Segurana baixa Dificuldade de Gerenciamento Imprevisibilidade nos tempos de resposta
Veremos na prxima unidade os dois tipos de arquitetura de Sistemas Distribudos mais importantes: a arquitetura cliente-servidor e a arquitetura de objetos distribudos. De um modo geral os Sistemas Distribudos so desenvolvidos com o uso da abordagem orientada a objetos.
Arquitetura de Multiprocessadores O modelo mais simples de Sistema Distribudo a Arquitetura de Multiprocessadores. Essa arquitetura, tpica de sistemas em tempo real, consiste em uma srie de diferentes processos que podem ser executados em processadores distintos. Os Sistemas de software compostos de vrios processos no so necessariamente sistemas distribudos. Se mais de um processador estiver disponvel, ento a distribuio poder ser
implementada, mas os projetistas de sistema no precisam sempre considerar as questes de distribuio durante o processo de projeto. A abordagem de projeto para esse tipo de sistema essencialmente aquela utilizada em sistemas de tempo real.
Wikipdia http://pt.wikipedia.org/wiki/Computa%C3%A7% C3%A3o_distribu%C3%ADda
Baixe o artigo Arquitetura de Sistemas Distribudos no site: http://www3.ufpa.br/wiki-clima/images/c/c9/Artigo_carla.pdf e tente fazer uma anlise comparando com o que vimos nesta unidade.
67
UNIDADE 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. No primeiro modelo todo o processamento realizado no servidor. A segunda estrutura mais complexa e mais comum. O servidor responsvel somente pelo gerenciamento de dados. E nos clientes implementado a lgica da aplicao e as interaes com o usurio do sistema.
68
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 em diferentes plataformas e seus nomes no precisam ser conhecidos por todos os outros objetos no sistema. Os dois padres normais para o middleware so o CORBA e o DCOM. Por todas as vantagens do padro CORBA (flexibilidade, por ser genrico, sistemas operacionais adotados), organizado pelo OMG que constituda por mais de 500 empresas, deva ser o padro de fato que o mercado ir adotar.
Wikipdia http://pt.wikipedia.org/wiki/Cliente-servidor http://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_camadas http://pt.wikipedia.org/wiki/Corba
Pela importncia do conceito do modelo de 3 camadas, e do padro CORBA nos dias atuais, explore detalhadamente esses dois itens na Internet.
70
UNIDADE 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 da Manuteno, sofre alteraes na estrutura, para que o sistema torne-se mais fcil sua compreenso e tambm para alteraes (veremos mais detalhes na Unidade 22).
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 a arqutetura 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.
72
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
UNIDADE 22
Reengenharia de Software - Traduo de cdigo fonte - Engenharia Reversa Melhoria de estrutura de programa
Objetivo: Visualizar a importncia da reengenharia na Engenharia de Software. A principal diferena entre Reengenharia de Software e o desenvolvimento de um novo Sistema da onde que se parte esse prprio desenvolvimento. Num Sistema novo inicia-se com uma especificao escrita (os requisitos) dos usurios/clientes. Enquanto que, numa reengenharia, o sistema existente (normalmente um Sistema Legado) que a base para esse incio. Chikofsky e Cross chegam at definir o desenvolvimento tradicional como Engenharia Direta, para distinguir da Reengenharia de Software. Pode-se perceber, pela figura abaixo, a complexidade do processo de Reengenharia de Software. Embora, nem toda reengenharia passe por todos esses processos, essencialmente o programa reestruturado. Vejamos mais detalhadamente o que cada processo realiza (caixas 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
Visite o site abaixo, fazendo um download das transparncias do arquivo PDF: http://www3.ufpa.br/wikiclima/images/f/f2/ReengenhariaDeSoftware_2.pdf e examine o ponto de vista apresentado sobre Reengenharia de Software confrontando com o que foi apresentado nesta unidade.
75
UNIDADE 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, as possveis 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
UNIDADE 24
Gerenciamento de Configurao Gerenciamento de Verses e Releases Gerenciamento de Mudanas -
Objetivo: Abordar os principais aspectos do gerenciamento de mudanas Gerenciamento de Configurao o desenvolvimento e a aplicao de padres e procedimentos para gerenciar um Sistema em desenvolvimento. Esses procedimentos definem como registrar e processar as mudanas do Sistema, como relacion-los aos seus componentes e os mtodos utilizados para identificar as diferentes verses desse Sistema (adaptado de Sommerville). As quatro atividades principais do Gerenciamento de Configurao so:
ATIVIDADES Planejamento do Gerenciamento de Configurao 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 exemplo do formulrio CRF mostrado a seguir:
Gerenciamento de Verses e Releases Objetivo: acompanhar e identificar o desenvolvimento das diferentes verses e releases de um Sistema. Tambm chamado de versionamento. O release de um sistema uma verso que distribuda para os clientes (Sommerville). Logo, sempre 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 SAIBA MAIS.
81
UNIDADE 25
(continuao) Construo de Sistemas - Ferramenta CASE
Objetivo: Explorar o conceito da ferramenta CASE Construo de Sistemas Na construo de um Sistema, a partir dos seus componentes, devem-se questionar os seguintes pontos: 1. Todos os componentes foram includos nas instrues de construo ? 2. A verso de cada componente requerido foi includo nas instrues de construo ? 3. Todos componentes requeridos esto disponveis ? 4. Os arquivos de dados do componente utilizado 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 Rational Rose 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
UNIDADE 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 fortes candidatos 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
UNIDADE 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 em um ambiente do mundo real necessariamente tem de ser modificado ou se tornar de maneira progressiva menos til nesse ambiente; Aumento da Complexidade: medida que um programa em evoluo se modifica, sua estrutura tende a se tornar mais complexa. Recursos extras precisam ser dedicados para preservar e simplificar a estrutura.
Tipos de Manuteno A manuteno ser necessria durante todo o Ciclo de Vida til, e pode ocorrer motivada por trs tipos fundamentais: Tipos de Manuteno Manuteno para reparar os defeitos no software Manuteno para adaptar o software a um ambiente operacional diferente Manuteno para fazer acrscimos funcionalidade do sistema ou modific-la 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. Na alterao dos requisitos, devido a mudanas organizacionais, ou nos negcios, que so bastante constantes, ocorre a manuteno mais comum entre todas as outras.
89
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 desenvolvimento constantemente prejudica a produtividade. A estimativa de dificuldades e custos de desenvolvimentos so muito difceis, alm do surgimento de problemas tcnicos. Esses fatores requerem uma Anlise de Riscos cuidadosa.
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.org http://www.pmisp.org.br/exe/educacao/pmbok.asp http://superdownloads.uol.com.br/materias/gp3-gestaoprojetos/290,1.html
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
UNIDADE 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 ou para receber melhorias ? A partir de uma determinada especificao com que rapidez pode ser alterado o processo ?
(adaptado de Sommerville)
97
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 Testing seq uence Level 1 . ..
Te st d ri vers Lev el N Level N Le vel N Lev el N Lev el N s
Level 2 Le vel 2 stubs
Level 2
Le vel 2
Level 2
Test d ri v ers
Leve l N 1
Lev el N 1
Le v el N 1
Le vel 3 stubs
BOTTOM-UP
Testes Alfa e Beta 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 Teste Caixa-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
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
99
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
UNIDADE 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, o processo usado para criar WebApps (aplicaes baseadas na Web) de alta qualidade. Embora os princpios bsicos da WebE sejam muito prximos da Engenharia de Software clssica, existem 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 Disponibilidade Escabilidade Prazo de colocao no mercado
101
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. Representa o fluxo de navegao entre objetos de contedo e todas as funes da WebApp.
Projeto Esttico
Projeto de Contedo
Projeto de Navegao
102
Projeto Arquitetural
Identifica a estrutura de hipermdia para a WebApp. Desenvolve a lgica de processamento detalhada necessria para implementar os componentes funcionais.
Adaptado de Pressman
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 ser claramente separados dos aspectos da interface. Os autores sugerem um projeto de arquitetura em trs camadas (veja a figura abaixo) que desaclopa a interface da navegao, e do comportamento da aplicao. Os mesmos argumentam que manter a interface, aplicao e navegao separadas simplifica a implementao e aumenta o reuso.
co n t ro lle r
man 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 w se 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 odel
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 rp o rat e s all we b A p p st at e s clie n t d at a f ro m mo d e l
H TML d at a
view
p re p are s d at a f ro m mo 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
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
103
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. Gera requisies do usurio, seleciona comportamento do Modelo e seleciona resposta de viso. o cdigo que gera os dados dinmicos para dentro da pgina HTML.
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 SAIBA MAIS, 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 sido aprovado no mdulo anterior.
Bibliografia do mdulo
PRESSMAN, Roger. Engenharia de Software. So Paulo: McGraw-Hill Brasil, 2006 SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2005 REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Rio de Janeiro: Brasport, 2005.
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.
106

Módulo 2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Módulo 2

Загружено:

Авторское право:

Доступные форматы

MDULO DE:

Ms. CARLOS VALENTE

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

UNIDADE 30 ........................................................................................................................ 101

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

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

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

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/

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

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

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Wikipdia http://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software http://pt.wikipedia.org/wiki/Desenvolvimento_interativo_e_incremental http://pt.wikipedia.org/wiki/Prototipac%C3%A3o

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

O Modelo Espiral basicamente dividido em quatro setores:

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Wikipdia http://pt.wikipedia.org/wiki/Engenharia_de_software#. C3.81reas_de_Conhecimento http://pt.wikipedia.org/wiki/Ferramenta_CASE

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

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

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Software Engineering Institute (SEI) da Universidade Carnegie Mellon http://www.sei.cmu.edu/cmm/

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Requisitos de Sistema (ou do desenvolvedor)

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Processo de Engenharia de Requisitos conforme Sommerville

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Copyright 2007, ESAB Escola Superior Aberta do Brasil

Diagrama de Caso de Uso Diagrama de Classe Diagrama de Seqncia Diagrama de

Copyright 2007, ESAB Escola Superior Aberta do Brasil