Académique Documents
Professionnel Documents
Culture Documents
ENGENHARIA de SOFTWARE
AUTORIA:
SUMRIO
UNIDADE 1........................................................................................................... 5 O que Engenharia de Software ? - Qual a diferena entre Engenharia de Software e Engenharia de Sistemas ? - O que um mtodo de Engenharia de Software ? .......................................................................................................... 5 UNIDADE 2 ........................................................................................................... 9 Teoria de Sistemas - Interdependncia de Sistemas ........................................ 9 UNIDADE 3 ......................................................................................................... 11 Quais so os atributos de um bom Software ? - Quais so os desafios enfrentados pela Engenharia de Software ? ................................................... 11 UNIDADE 4 ......................................................................................................... 15 Conceitos sobre a Engenharia de Software - O que Software ? A Importncia do Software - SWEBOK ............................................................... 15 UNIDADE 5 ......................................................................................................... 19 Modelos de Processo de Software - Paradigmas do desenvolvimento de Software - Modelo Balbrdia - Modelo Cascata .............................................. 19 UNIDADE 6 ......................................................................................................... 23 Paradigmas do Desenvolvimento de Software (continuao) - Modelo Incremental - Prototipao ............................................................................... 23 UNIDADE 7 ......................................................................................................... 26 Paradigmas do desenvolvimento de Software (continuao) - Modelo Espiral Modelos mistos e caractersticas genricas .................................................... 26 UNIDADE 8 ......................................................................................................... 29 Paradigmas da Engenharia de Software: Processo, Mtodos e Ferramentas29 UNIDADE 9 ......................................................................................................... 32 Caractersticas de um bom processo - Caractersticas de um bom ambiente de desenvolvimento ......................................................................................... 32 UNIDADE 10 ....................................................................................................... 35 Introduo ao RUP (Rational Unified Process) - Caractersticas - Fases e Workflows ......................................................................................................... 35
Copyright 2007, ESAB Escola Superior Aberta do Brasil 2
UNIDADE 11 ....................................................................................................... 39 Modelos de Maturidade CMM (Capability Maturity Model) .......................... 39 UNIDADE 12 ....................................................................................................... 42 Requisitos de Software - Requisitos Funcionais e no Funcionais - Requisitos de Usurio e de Sistema .................................................................................. 42 UNIDADE 13 ....................................................................................................... 45 Tcnicas de Anlise de Requisitos - O Documento de Requisitos de Software .......................................................................................................................... 45 UNIDADE 14 ....................................................................................................... 48 Processos de Engenharia de Requisitos - Estudos de Viabilidade................. 48 UNIDADE 15 ....................................................................................................... 50 Modelagem UML: Unified Modeling Language Linguagem de Modelagem Unificada .......................................................................................................... 50 UNIDADE 16 ....................................................................................................... 53 Metodologias de Desenvolvimento geis de Software: XP - FDD e DSDM ... 53 UNIDADE 17 ....................................................................................................... 57 Continuao das Metodologias de Desenvolvimento gil de Software: Scrum Crystal - ASD e AM .......................................................................................... 57 UNIDADE 18 ....................................................................................................... 61 Engenharia de Projeto - Projeto Modular - Projeto de interface com o usurio .......................................................................................................................... 61 UNIDADE 19 ....................................................................................................... 64 Arquiteturas de Sistemas Distribudos - Arquitetura de Multiprocessadores .. 64 UNIDADE 20 ....................................................................................................... 67 Arquitetura cliente/servidor - Arquitetura de objetos distribudos .................... 67 UNIDADE 21 ....................................................................................................... 70 Mudanas em Software - Dinmica da Evoluo de Programas - Evoluo da Arquitetura ........................................................................................................ 70 UNIDADE 22 ....................................................................................................... 73
Reengenharia de Software - Traduo de cdigo fonte - Engenharia Reversa Melhoria de estrutura de programa.................................................................. 73 UNIDADE 23 ....................................................................................................... 75 Reengenharia de Dados e suas abordagens .................................................. 75 UNIDADE 24 ....................................................................................................... 77 Gerenciamento de Configurao - Gerenciamento de Mudanas Gerenciamento de Verses e Releases .......................................................... 77 UNIDADE 25 ....................................................................................................... 81 (continuao) Construo de Sistemas - Ferramenta CASE .......................... 81 UNIDADE 26 ....................................................................................................... 84 Sistemas Legados - Estruturas dos Sistemas Legados - Avaliao dos Sistemas Legados ............................................................................................ 84 UNIDADE 27 ....................................................................................................... 88 Manuteno: fundamentos da fase de Manuteno de Software, tipos de Manuteno, procedimentos, tcnicas e ferramentas ..................................... 88 UNIDADE 28 ....................................................................................................... 92 Gesto de Projetos de Software e o PMBOK .................................................. 92 UNIDADE 29 ....................................................................................................... 96 Gerenciamento de Qualidade e Estratgias de Teste de Software ................ 96 UNIDADE 30 ..................................................................................................... 100 Engenharia de Software na WEB Sistemas e Aplicaes baseadas na WEB ........................................................................................................................ 100
NIDADE
O que Engenharia de Software ? - Qual a diferena entre Engenharia de Software e Engenharia de Sistemas ? - O que um mtodo de Engenharia de Software ?
Objetivo: Conceituar a Engenharia de Software, apresentar diferenas e definir mtodo. A Engenharia de Software, conforme Sommerville, um dos papas dessa rea, uma disciplina da engenharia que se ocupa de todos os aspectos da produo de software. Isso vai desde os estgios iniciais de especificao de um Sistema, at propriamente a Manuteno para que esse mesmo Sistema sobreviva ao longo do tempo. A construo de software uma das atividades mais complexas e vitais para o pleno sucesso de um Sistema informatizado. A Engenharia de Software justamente tenta, atravs dos princpios bsicos de outras engenharias, trazer um pouco mais de luz para essa atividade complexa. A cobrana hoje das reas de Informtica e de T.I. (Tecnologia da Informao) desenvolver Sistemas de forma rpida, com qualidade, e com custos cada vez menores. Somente atravs de tecnologias adequadas, e com as melhores prticas, podemos atender a esses novos desafios. A Engenharia de Software constituda de Metodologias, Mtodos e Ferramentas que permitem ao profissional especificar, projetar, implementar e manter Sistemas, avaliando e garantindo as qualidades especificadas pelos usurios.
Engenharia de Sistemas A Engenharia de Sistemas mais genrica e mais abrangente do que a Engenharia de Software. Na verdade, a segunda faz parte da primeira. A Engenharia de Sistemas mais antiga do que a de Software. Enquanto a primeira est mais envolvida com o Sistema como um todo e seus detalhes, a Engenharia de Software mais especfica no que tange aos componentes do sistema, em especial ao hardware e software.
Mtodo de Engenharia de Software Sommerville afirma que um mtodo de Engenharia de Software uma abordagem estruturada para o desenvolvimento de software. Podemos definir como abordagem estruturada a estratgia de desenvolver algo com uma estrutura previamente estudada, ou baseada nas melhores prticas. O objetivo maior de tudo isso facilitar a produo, em curto espao de tempo, de software de alta qualidade, apresentando uma relao custo-benefcio interessante. Um ponto importante a observar que no existe, repito, no existe um mtodo ideal. As possibilidades e os ambientes de desenvolvimento so to complexos, que dependendo de cada situao e momento, existe um mtodo que possa explorar mais alguns tpicos, mas deixar outros em aberto. Outro ponto a ressaltar que existem vrios mtodos na Engenharia de Software, mas poucas Metodologias. Podemos entender Metodologia tanto pelas palavras de Maddison, como sendo um conjunto recomendado de filosofias, fases, procedimentos, tcnicas, regras, ferramentas, documentao, gerenciamento e treinamento para o desenvolvimento de um sistema de informao, como tambm o estudo de um ou mais mtodos.
6
No incio da computao poucos programadores seguiam algum tipo de metodologia baseando-se, em sua maioria, na prpria experincia. Na Engenharia de Software existem basicamente duas grandes metodologias. Uma originria da dcada de 70, chamada de Metodologia Estruturada, e a mais recente intitulada de Metodologia Orientada a Objetos.
Diferenas das Metodologias Tanto a abordagem estruturada quanto a orientada a objetos promovem solues prticas. A diferena entre as duas metodologias a vida til e facilidade de manuteno de projetos. A possvel reutilizao de um cdigo estruturado no comum, enquanto que um cdigo orientado a objetos por possuir embutido em sua prpria filosofia as facilidades de reutilizao e de descrio, utilizando UML (Unified Modeling Language), aumenta naturalmente a vida til dos cdigos. Abordando o software sob um ponto de vista puramente estruturado, definem-se os dados do sistema em uma posterior sequncia de eventos que acarretar na transformao do estado do sistema. Por outro lado, numa abordagem focada em orientao a objetos, definem-se estruturas abstratas, denominadas classes, que sero responsveis por partes da soluo do problema. Cada classe incorporar dada (forma) e mtodos (comportamentos). Projetos orientados a objetos utilizam da linguagem de modelagem UML (Unified Modeling Language). Esta linguagem fruto dos esforos, em conjunto, dos autores Booch, Rumbaugh e Jacobson.
Responda, por escrito, as seguintes perguntas: O que Engenharia de Software? Qual a diferena entre Engenharia de Software e Engenharia de Sistemas? O que um mtodo de Engenharia de Software?
NIDADE
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
Copyright 2007, ESAB Escola Superior Aberta do Brasil 9
inferior do SISTEMA temos um importante conceito de feed-back chamado de CONTROLE do SISTEMA. Inicia-se esse controle com um PADRO de comparao. Atravs de um SENSOR que mensura periodicamente as alteraes do SISTEMA, compara-se com o PADRO. Uma vez o SISTEMA sofrendo alteraes em relao ao PADRO, o ATIVADOR ir passar parmetros para o SISTEMA se autocorrigir. Um bom exemplo prtico deste conceito imaginarmos o ar condicionado. Parte-se inicialmente da base de uma temperatura estabelecida por ns (PADRO). O sensor mensura as variaes de temperatura. E o ATIVADOR ir deixar o ar condicionado ativado at novamente o SENSOR verificar que a temperatura est no PADRO desejado.
Wikipdia http://pt.wikipedia.org/wiki/Teoria_de_sistemas
Acesse o documento no site abaixo e veja maiores detalhes da interessante Teoria de Sistemas: http://www.abdl.org.br/filemanager/download/4/teoria% 20de%20sistema.pdf
10
NIDADE
Quais so os atributos de um bom Software ? - Quais so os desafios enfrentados pela Engenharia de Software ?
Objetivo: Definir atributos de software e contextualizar a Engenharia de Software. Os atributos de um bom software refletem seu comportamento quando em funcionamento, a estrutura e a organizao do programa fonte, e tambm a documentao associada (Sommerville). Como exemplos, temos o tempo de resposta do software consulta de um usurio e a facilidade de compreenso do cdigo do programa. Esses mesmos exemplos tambm podem ser chamados de atributos no funcionais. Resumidamente o software deve proporcionar ao usurio a funcionalidade e o desempenho requeridos e deve ser passvel de manuteno, confivel, eficiente e de fcil uso (veja mais detalhes no quadro abaixo). ATRIBUTOS
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 consequncia 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.
Crise do Software e o incio da Engenharia de Software A crise do software, termo usado nos anos 70, referia-se s dificuldades do desenvolvimento de software da poca. Por haver um rpido crescimento da demanda por software, imaginava-se que com toda a complexidade no desenvolvimento, haveria uma forte crise. Com a inexistncia da Engenharia de Software nessa poca, no havia tcnicas estabelecidas para o desenvolvimento de sistemas que funcionassem adequadamente ou que pudessem ser validadas.
J em 1988, AMBLER afirmava: Desenvolver software no somente modelar e escrever cdigo. criar aplicaes que resolvam os problemas dos usurios. fazer isto dentro do prazo, de forma precisa e com alta qualidade. Logo, com a crise de software, os desafios para a criao da disciplina de Engenharia de Software eram muito grandes. Alguns dos tpicos problemas que essa nova disciplina enfrentou foram: Identificar adequadamente os requisitos do Sistema, ou seja, saber o que o software deve fazer; Que ferramentas, linguagem, sistema operacional usar; Como diminuir os tempos e custos de desenvolvimento; Prever falhas antes da entrega final; Como fazer manuteno e controlar verses; Dificuldades de prever o progresso durante o desenvolvimento; Inexistncia de histrico, ou documentao, no desenvolvimento de Sistemas; Comunicao com os usurios precria; Conceitos quantitativos inexistentes tais como confiabilidade, qualidade e reusabilidade; Manuteno, no software existente, com difcil execuo.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 12
Esse incio difcil da Engenharia de Software, com tantos desafios, gerou vrios paradigmas e modelos de desenvolvimento. Iremos ver nas prximas unidades quais foram as formas que a engenharia clssica veio a ajudar nesse difcil incio.
Desafios da Engenharia de Software Atualmente os principais desafios da Engenharia de Software, conforme Sommerville so:
DESAFIOS
Descrio Ainda os grandes sistemas de software existentes foram desenvolvidos no passado, e com importantes funes corporativas. O desafio fazer a manuteno e atualizao desses softwares a custos baixos e com qualidade. Os sistemas exigem em ambientes distribudos por redes de diferentes tipos de computadores e sistemas de apoio. O desafio desenvolver tcnicas para construir softwares flexveis para lidar com a heterogeneidade. Nos dias atuais existe uma demanda enorme de sistemas que sejam desenvolvidos no menor tempo possvel e com facilidade de adaptao. O desafio fornecer sistemas cada vez maiores e complexos com a qualidade desejada, e em curto espao de tempo.
O desafio do legado
O desafio da heterogeneidade
O desafio do fornecimento
13
Wikipdia http://pt.wikipedia.org/wiki/Crise_do_software
Responda, por escrito, as seguintes perguntas com os seus prprios comentrios a respeito: Quais so os atributos de um bom Software? Quais so os desafios enfrentados pela Engenharia de Software?
14
NIDADE
Ainda hoje a maioria feita sob encomenda em vez de ser montada a partir de componentes
Tipos de Software Tempo real Software bsico Sistema de informao Embutido Tcnicos Especialistas Apoio deciso Jogos Apoio (processador de textos)
15
Mitos do Software 1 - J temos um manual repleto de padres e procedimentos para a construo de software. Isso j suficiente para o pessoal do desenvolvimento. 2 - Meu pessoal tem ferramentas de ltima gerao, afinal de contas compramos os mais novos computadores. 3 - Se ns estamos atrasados nos prazos, podemos adicionar mais programadores e tirar o atraso. 4 - Uma declarao geral dos objetivos suficiente para se comear a escrever programas, podemos preencher os detalhes mais tarde. 5 - Os requisitos de projeto modificam-se continuamente, mas as mudanas podem ser facilmente acomodadas, porque o software flexvel. 6 - Assim que escrevermos o programa e o colocarmos em funcionamento, nosso trabalho estar completo. 7 - Enquanto no tiver o programa funcionando, eu no terei realmente nenhuma maneira de avaliar sua qualidade. 8 - A nica coisa a ser entregue em um projeto bem-sucedido o programa funcionando.
Importncia do Software Um dos pontos fundamentais da importncia do software pelo seu uso cotidiano, aonde praticamente no mundo moderno, inexiste a possibilidade de no utiliz-lo. E o outro ponto pela manipulao da informao (dado - informao - conhecimento), e quem a tem possui poder.
SWEBOK O SWEBOK (Guide to the Software Engineering Body of Knowledge) o documento tcnico desenvolvido com o apoio do IEEE (Instituto de Engenheiros Eltricos e Eletrnicos, tambm popularmente chamado de I3E). Esse documento estabelece uma classificao hierrquica
Copyright 2007, ESAB Escola Superior Aberta do Brasil 16
dos tpicos tratados pela Engenharia de Software, onde o nvel mais alto so as reas do Conhecimento. As dez reas do Conhecimento tratadas pelo SWEBOK so:
Requisitos de Software Projeto de Software Construo de Software Teste de Software Manuteno de Software Gerncia de Configurao de Software Gerncia da Engenharia de Software Processo de Engenharia de Software Ferramentas e Mtodos da Engenharia de Software Qualidade de Software
Importante ressaltar as diferenas entre o SWEBOK e o PMBOK. Estaremos detalhando melhor o PMBOK na Unidade 28. Mas, somente mostrando genericamente o diferencial dos dois, que enquanto o SWEBOK dirigido especificamente para a Engenharia de Software, o PMBOK mais generalizado quanto a Gerenciamento de Projetos como um todo.
17
Navegue pelo site do SWEBOK (http://www.swebok.org/) e tente baixar gratuitamente o documento PDF que contm todas as especificaes tcnicas das dez reas do Conhecimento abordadas por essa importante referncia na Engenharia de Software.
18
NIDADE
Modelos de Processo de Software - Paradigmas do desenvolvimento de Software - Modelo Balbrdia - Modelo Cascata
Objetivo: Entender os principais modelos de processo de software. Os Modelos de Processo de Software descrevem basicamente as principais etapas do desenvolvimento de software, desde a produo at a sua prpria manuteno. Existem vrios Modelos de Processo de Software, mas praticamente todos eles seguem o princpio das trs principais macro-etapas: Requisitos - o analista deve obter respostas a vrias perguntas junto aos usurios: O que exatamente se espera que seja feito? Qual a abrangncia do software? Quais os limites, ou o escopo do sistema? Por que se faz aquilo daquela forma? Quais as restries que existem nos procedimentos e dados utilizados? E muitas outras. Projeto/Desenvolvimento - o analista faz especificaes tcnicas detalhando a soluo criada para atender ao usurio conforme os requisitos anteriores. Os programadores codificam os programas em alguma linguagem de programao. Devem-se testar os programas exaustivamente para atingir um alto nvel de qualidade, e aps isso liber-los para o uso. Implantao/Manuteno - na implantao do software podem ocorrer vrios problemas no previstos nas fases anteriores. E a manuteno permanecer durante toda sua vida til e pode ocorrer motivada por 03 fatores: a correo de algum problema existente no software, sua adaptao decorrente de novas exigncias (internas ou externas da empresa) e algum melhoramento funcional que seja incorporado ao software.
19
Cabe ressaltar que no existe um consenso sobre o nome mais adequado para Modelos de Processo de Software. Os principais autores se referem a esse mesmo conceito com os seguintes nomes: Modelos de Ciclo de Vida de Software; Modelos Prescritivos de Processo Paradigmas do Ciclo de Vida; Paradigmas do Desenvolvimento de Software; Modelagem do Ciclo de Vida.
Modelo Balbrdia Como falamos anteriormente, no incio da computao, poucos programadores seguiam algum tipo de metodologia baseando-se, em sua maioria, na prpria experincia. Era o que chamamos hoje de Modelo Balbrdia, sistemas desenvolvidos na informalidade sem nenhum tipo de projeto ou documentao. Nesse modelo, o software tende a entrar num ciclo de somente duas fases: o de implementao e de implantao. E os ajustes ao software para atender aos novos requisitos, sempre so em clima de urgncia e de stress, motivados por vrios fatores, e principalmente por presso poltica.
20
Portanto, havia a necessidade se criar um Ciclo de Vida mais inteligente para o desenvolvimento de Software. Ou seja, um Ciclo de Vida semelhante prpria natureza, com incio, meio e fim bem definidos. Modelo Cascata Essa foi a proposta do Modelo Cascata (ou do ingls Waterfall), da dcada de 70. Onde cada etapa do ciclo de vida pressupe atividades que devem ser completadas antes do incio da prxima etapa. Ou ainda, um modelo basicamente de atividades sistemticas e sequenciais onde para cada etapa cumprida, segue-se a etapa imediatamente posterior, como se fosse uma cascata. O Modelo Cascata extremamente clssico e antigo, por isso tambm chamado de Ciclo de Vida Clssico. Originou-se dos velhos modelos de engenharia na elaborao de projetos. E na verdade, hoje em dia, somente uma grande referncia. Vivemos num mundo de atividades paralelas, e esse modelo de atividades sequenciais, provocaria demoras excessivas, esperas indesejadas e problemas quando houvesse necessidade de voltar em etapas anteriores. Repare nas duas figuras abaixo. Embora as duas refiram-se ao Modelo Cascata observe como a terminologia dessas imagens distinta. Cada etapa praticamente tem um nome diferente em cada figura. Isso ocorre devido a no existir um padro para esse modelo. Embora sendo clssico, para cada autor existe uma interpretao de cada etapa e criado um nome distinto.
21
O prprio Pressman, outro papa da Engenharia de Software, na ltima edio do seu famoso livro de Engenharia de Software, alterou os nomes da quinta edio, colocando o nome dessas fases respectivamente de: Comunicao, Planejamento, Modelagem, Construo e Implantao.
Com base nas duas ltimas imagens dessa unidade, faa uma possvel relao entre os nomes das etapas e com a proposta citada pelo Pressman. Ou seja, a primeira etapa da primeira figura seria equivalente a que etapa da segunda imagem, e com a qual do Pressman??
22
NIDADE
Importante observar a diferena entre INTERATIVO e ITERATIVO. As duas palavras embora com escrita extremamente parecidas, e muitas utilizadas em Informtica, possuem significados distintos. Quanto palavra ITERATIVA que significa, pelo prprio Aurlio, diz-se de procedimento (como algoritmo, programa, etc.) que se baseia no uso ou aplicao da iterao. Por sua vez
Copyright 2007, ESAB Escola Superior Aberta do Brasil 23
ITERAO possui o significado de: Processo de resoluo (de uma equao, de um problema) mediante uma seqncia finita de operaes em que o objeto de cada uma o resultado da que a precede. Ainda do prprio Aurlio podemos extrair a definio de INTERATIVO de, ou relativo a sistemas ou procedimentos computacionais, programas, etc. em que o usurio pode (e, por vezes, necessita) continuamente intervir e controlar o curso das atividades do computador, fornecendo novas entradas (de dados ou comandos) medida que observa os efeitos das anteriores. Portanto, no nosso caso especfico utilizamos o processo INTERATIVO, e no ITERATIVO.
Prototipao A Prototipao tem o mesmo objetivo que uma maquete para um arquiteto (ver figura abaixo). Antes da entrega final do sistema desenvolve-se rapidamente um esboo para melhorar o entendimento de desenvolvedores e clientes sobre todas as problemticas das questes.
Dentro dessa viso, o projeto passa por vrias investigaes para garantir que o desenvolvedor, usurio e cliente cheguem a um consenso sobre o que necessrio e o que deve ser proposto. Como muitos usurios no possuem uma viso ampla sobre a Tecnologia, esse mtodo de desenvolvimento bastante interessante, permitindo que o usurio interaja significativamente no Sistema. A prototipao um processo que possibilita desenvolvedor e usurios a examinarem antecipadamente os requisitos. Com isso se reduz os riscos e as incertezas do desenvolvimento.
24
Basicamente as etapas de desenvolvimento desse modelo so: 1. Comear com um conjunto bem simples de requisitos fornecidos pelos clientes e usurios; 2. Clientes e usurios fazem testes e experimentaes, e assim que eles decidem o que querem, os requisitos so revisados, alterados, detalhados, documentados e o sistema passa a ser codificado; 3. Novamente as alternativas so apresentadas e discutidas com os usurios, e voltamos para a etapa dois, at a entrega definitiva do Sistema. Logo, este modelo propicia duas grandes vantagens: velocidade de desenvolvimento no sentido de propiciar ao usurio uma viso mais real do software que se est projetando (o usurio poder enxergar as telas e os relatrios resultantes do software) e o envolvimento direto do usurio na medida em que o desenvolvimento do software evolui, o usurio passa a ser um co-autor do desenvolvimento.
Quais as diferenas bsicas entre o Modelo Incremental e a Prototipao?? Qual a diferena entre ITERATIVO e INTERATIVO?? Quais dos dois modelos explicados nessa Unidade voc escolheria para o desenvolvimento de um Sistema?!?
25
NIDADE
Paradigmas do desenvolvimento de Software (continuao) - Modelo Espiral Modelos mistos e caractersticas genricas
Objetivo: Relacionar os vrios modelos de desenvolvimento de software. Modelo Espiral Este modelo se confunde com o de Prototipagem. Mas em princpio mais adequado para sistemas mais complexos, e que exigem um alto nvel de interaes com os usurios para possibilitar a abordagem de todos os problemas desse Sistema. Foi criado por Barry W. Boehm, ainda em 1988, e ao invs de representar o processo de software como uma sequncia de atividades, a exemplo do Modelo Cascata, ele representado atravs de uma espiral (veja figura abaixo).
Cada ciclo da espiral representa uma fase do processo de software. Na parte mais interna relaciona-se o incio da viso da viabilidade do sistema. E a cada ciclo, passando por vrias etapas, vai evoluindo a visibilidade do sistema como um todo.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 26
ATIVAO
Definem-se os objetivos especficos, identificam-se as restries para o processo e preparado um plano de gerenciamento detalhado. Identificam-se tambm os riscos sem analis-los profundamente (foco da prxima fase). 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.
27
Ele um processo de software incremental que enfatiza um ciclo de desenvolvimento curto (Pressman). A estratgia para isso o uso da abordagem de construo baseada em componentes. Com isso o desenvolvimento completo de um Sistema, de relativa complexidade, chega a atingir 60 a 90 dias. Os pontos a serem ressaltados nesse modelo que se o sistema no puder ser adequadamente modularizado, a construo de componentes necessrios ao RAD ser problemtica. E outro ponto que o RAD pode no ser adequado quando os riscos tcnicos so altos, por exemplo, se existir a necessidade de uma aplicao usufruir tecnologias novas no dominadas pela equipe. Outro modelo o Processo Unificado Racional, RUP em ingls, que utiliza maciamente do UML (Unified Modeling Language). Utilizando mtodos e linguagens de programao orientada a objetos, aprimora o modelo RAD. A nfase desse modelo na arquitetura de software. Veremos mais detalhes deste modelo na unidade 10.
Wikipdia http://pt.wikipedia.org/wiki/Modelo_em_espiral
Na figura apresentada existe um erro j discutido em unidades anteriores, com base nisso qual seria esse erro?!? Para voc fazer uma reviso geral do que vimos nessas ltimas unidades, leia o texto sobre os Modelos de Ciclo de Vida: http://pt.wikipedia.org/wiki/Modelos_ciclo_de_vida
28
NIDADE
Processo O Processo de Software um conjunto de atividades, mtodos, prticas e transformaes ordenadas com a inteno de atingir a qualidade do software. Sua meta fundamental entregar, de maneira eficiente e previsvel um produto de software capaz de atender as necessidades de negcio, definidas pela anlise de requisitos, dos usurios.
29
Pode-se tambm definir sucintamente como um conjunto completo de atividades necessrias para transformar os requisitos do usurio em um produto de qualidade de software. Um processo define QUEM est fazendo O QUE, QUANDO e COMO para atingir esse objetivo.
Mtodos Mtodo uma palavra que vem do grego mthodos, que significa caminho para se chegar a um fim. O termo metodologia bastante controverso nas cincias em geral e na Engenharia de Software em particular. Muitos autores parecem tratar metodologia e mtodo como sinnimos, porm seria mais adequado dizer que uma metodologia envolve princpios filosficos que guiam uma gama de mtodos que utilizam ferramentas e prticas diferenciadas para realizar algo. As metodologias de Engenharia de Software objetivam ensinar como fazer para construir softwares. Esses mtodos incluem atividades de modelagem, construo de programas, testes e manuteno. Na Engenharia de Software as principais abordagens de Metodologias so: Metodologia Estruturada: a mais clssica das abordagens. Utiliza como ferramental Dicionrio de Dados, Diagrama de Fluxo de Dados (DFD), e o Modelo Entidade Relacionamento (MER)
Metodologia Orientada a Objetos: na Unidade 10 abordamos sobre RUP (veja maiores detalhes nessa Unidade).
30
Metodologias de Desenvolvimento gil: Existem varias metodologias que podem ser consideradas como abordagens geis: XP, ASD, DSDM, Scrum, Crystal, FDD, AM entre outras. Veremos com maiores detalhes essas Metodologias nas Unidades 16 e 17. Ferramentas Ferramenta uma palavra que vem do latim ferramentum significando qualquer utenslio empregado nas artes e ofcios (Aurlio). As ferramentas de Engenharia de Software fornecem apoio automatizado, ou semi-automatizado, para o processo e para os mtodos. Quando ferramentas so integradas de modo que a informao criada por uma ferramenta possa ser usada por outra, um sistema de apoio ao desenvolvimento de software, chamado de engenharia de software apoiada por computador (CASE), estabelecido (Pressman).
Aps a leitura dessa unidade, e pelo material na Web, quais so as suas impresses quanto a diviso da Engenharia de Software em Processo, Mtodos e Ferramentas ?!?
31
NIDADE
As principais caractersticas de um bom processo so: Configurvel para diferentes organizaes. Adaptvel para diferentes tamanhos e tipos de projetos. Bem definido, gerencivel e repetvel. Com nomenclatura universal e mtricas para planejamento e gerenciamento do projeto. Integrado com ferramentas que o suportem.
32
Caractersticas de um bom ambiente de desenvolvimento Processo de desenvolvimento definido. Integrao entre processo e ferramentas. Integrao entre ferramentas. Gerenciamento de configurao. Gerenciamento de mudanas. Gerenciamento de projetos. Automao de testes funcionais e de desempenho. Documentao consistente. E outros.
33
Wikipdia 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 infraestrutura? Que ferramental possui para desenvolver?
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE AULA e faa a Atividade 1 no link ATIVIDADES.
34
NIDADE
10
As principais caractersticas do RUP so: Desenvolvimento Interativo Gerncia de requisitos Uso de arquitetura baseada em componentes Modelagem visual
Copyright 2007, ESAB Escola Superior Aberta do Brasil 35
A soluo iterativa requer uma compreenso crescente do problema por meio de aperfeioamentos sucessivos e de desenvolvimento incremental em vrios ciclos.
Modelagem A abstrao do sistema de software atravs de modelos que o descrevem um poderoso instrumento para o entendimento e comunicao do produto final que ser desenvolvido. A maior dificuldade nesta atividade est no equilbrio entre simplicidade (favorecendo a comunicao junto ao usurio) e a complexidade (favorecendo a preciso com detalhes) do modelo. comum a utilizao de linguagens para modelagem como UML.
Fases Estruturar um projeto junto dimenso de tempo envolve a adoo das seguintes fases baseadas em tempo (veja maiores detalhes na tabela e figura abaixo):
FASES
Descrio
Iniciao
(Inception)
Estabelece a viso, o escopo e o plano inicial para o projeto. Projeta, implementa e testa a arquitetura do sistema e completa o plano do projeto. Desenvolve a primeira verso do sistema.
Elaborao
(Elaboration)
Construo
(Construction)
Transio
(Transition)
36
Workflow de Processo Estruturar um projeto junto dimenso de componente de processo inclui as seguintes atividades:
ATIVIDADES
Descrio
Modelagem do negcio Descreve o negcio atravs de casos de uso de negcio. Requisitos 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.
37
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 infraestrutura necessria para desenvolver um sistema (seleo de ferramentas, definio das regras de negcio, interface, testes, etc)
Leia adicionalmente o interessante artigo sobre a importncia do UML nos dias atuais atravs do seguinte link: http://www.anacristinamelo.eti.br/artigos/Artigo_Buscando_Novos_ Caminhos.pdf
38
NIDADE
11
Atente para o grfico apresentado. Ele representa que quanto maior a capacitao, menor ser a variao dos erros de estimativa (de custos, prazos, etc.) em torno da mdia. Ou seja, enquanto no grfico da esquerda as estimativas fogem muito da mdia, o da direita as variaes em relao mdia foram aprimoradas aps a implantao do CMM (nvel 5). O CMM (Capability Maturity Model) o mais famoso representante desse conceito. Ele basicamente uma metodologia de diagnstico e avaliao da maturidade da capacitao em desenvolvimento de softwares numa organizao (empresa ou instituio). O objetivo maior do CMM determinar em que estgio de maturidade uma empresa est em seu ciclo de desenvolvimento de software. Nasceu da necessidade do Departamento de
39
Defesa americano em como avaliar as empresas terceirizadas que desenvolviam softwares para eles. O uso de estratgia de melhoria de processos atravs de avaliao contnua, identificao de problemas e suas devidas aes corretivas permite estabelecer cinco nveis de maturidade (veja a tabela em seguida). CMMi (Capability Maturity Model Integration) o modelo de maturidade surgido recentemente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de melhoria corporativo. Somente por curiosidade, raras so as empresas no mundo que conseguem atingir o nvel 5, a grande maioria fica nos estgios iniciais. No Brasil, at o presente ano (2007), existiam somente 4 empresas que tinham alcanado o nvel 5 do CMMi.
Estgios Descrio
Nvel 1 Inicial
Catico, estgio aonde que a maioria das empresas de software encontra-se. 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
40
Para podermos visualizar melhor, de forma grfica, todos os nveis de maturidade e a interao entre eles, podemos observar a figura a seguir:
Dentro do que foi visto nesta Unidade, como voc visualiza a sua empresa dentro do conceito do CMM ? Em que estgio voc acredita que ela esteja ?!?
41
NIDADE
12
Requisitos do Usurio
So declaraes, em linguagem natural e tambm em diagramas, sobre as funes que o sistema deve fornecer, e as restries, sob as quais deve operar.
42
Estabelecem detalhadamente as funes e as restries de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificao funcional, deve ser preciso. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor do software. So declaraes de funes que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como deve se comportar em determinadas situaes. Em alguns casos, os requisitos funcionais podem, de forma explcita, declarar o que o sistema no deve fazer. So restries sobre os servios ou as funes oferecidos pelo sistema. Entre eles destacam-se restries sobre o processo de desenvolvimento, padres, entre outros.
Adaptado de Sommerville
Requisitos Funcionais
Requisitos no Funcionais
Ressalta-se que essa classificao no to precisa, e at um pouco artificial. Ou seja, por exemplo, um requisito de usurio relacionado proteo, aparenta ser um requisito no funcional. No entanto, ao detalharmos esse requisito ele pode assumir uma abrangncia mais tpica de um requisito funcional. Pois podemos necessitar de incluir recursos de autorizao de usurios no sistema.
N o n - f u n c t io n a l r e q u ir e m e n t s
P ro d u ct r e q u ir e m e n t s
O r g an iz a t io n a l r e q u ir e m e n t s
E x te r n a l r e q u ir e m e n t s
E f f ic i e n c y re q u ir e m e n t s
R e li ab il it y r e q u ir e m e n t s
Po rt a b il it y r e q u ir e m e n t s
I n t e ro p e r a b il it y r e q u ir e m e n t s
E t hi c a l r e q u ir e m e n t s
U s ab il it y r e q u 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
43
Pela figura anterior, podemos observar como os Requisitos no Funcionais so bastante abrangentes. Podem compreender desde requisitos ticos, como de desempenho ou mesmo de interoperabilidade.
Wikipdia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos
Visite o site http://www.ic.unicamp.br/~ariadne/inf301/modulo2-v.pdf e explore as informaes das transparncias com a temtica Extrao de Requisitos.
44
NIDADE
13
45
Princpio n 5: Faa sempre anotaes e documente as decises. Por mais que no se queira a memria humana fraca, muito fraca. Portanto, deve-se registrar o mximo das posies e informaes dos usurios/clientes. Voc ir se surpreender no futuro como anotou vrias coisas que nem voc no lembrava mais. E isso ser muito importante nos conflitos que ocorrem ao longo do projeto. Princpio n 6: Buscar ao mximo a colaborao de todos. Animosidades no ajudam a ningum. O bom humor ajuda muito nessa fase de levantamento. Procurar ser agradvel e simptico ameniza a grande maioria dos problemas pessoais. E por incrvel que parea, os problemas pessoais so os que mais atrapalham num projeto. Princpio n 7: Conserve-se focado, departamentalize sua discusso. Discuta cada tema profundamente. Tente evitar questionar, ou discursar sobre vrios temas simultaneamente. Vai eliminando a discusso tema a tema. A produtividade ir aumentar. Princpio n 8: Se algo no estiver claro, sempre desenhe. Como o velho provrbio diz: Uma imagem vale mil palavras. No existe a necessidade de aplicar as tcnicas de modelagem nessa hora, mas com desenhos simples, mapas mentais, transparncias do PowerPoint, quadros e imagens ajudam muito nessa fase do projeto. DICA: visite o site www.mapasmentais.com.br para ver a tcnica que a prpria NASA utiliza em seus projetos. Princpio n 9: (a) Se voc concorda com algo, prossiga; (b) Se voc no concordar com algo, prossiga; (c) Se algo no estiver claro, e sem condies de esclarecer naquele momento, prossiga. H momentos que no adianta, como se diz no popular, dar murro em ponta de faca. Prepare-se e aguarde o momento certo para voltar a tocar num tema polmico. O uso da criatividade, na abordagem de um tema desse tipo, super estratgico. Princpio n 10: Negociar sempre no ganha-ganha. Existem vrias posturas numa negociao entre dois personagens (perde-perde, ganhaperde, perde-ganha e ganha-ganha). A melhor relao o ganha-ganha. Essa a postura dos vencedores. Ou seja, conduzida a soluo de conflitos de tal forma criativa e rica em oportunidades, que os dois lados ganham na negociao. DICA: o site http://www.golfinho.com.br/artigospnl/artigodomes1299.asp apresenta vrias dicas pessoais sobre o processo de negociao ganha-ganha.
46
O Documento de Requisitos de Software O Documento de Especificao de Requisitos de Software pode variar nos detalhes de empresa para empresa, mas normalmente possui os seguintes campos: Definio do Contexto Definio de Requisitos o Requisitos Funcionais o Requisitos de Interface o Requisitos no Funcionais Anlise de Risco Anexos
Wikipdia http://pt.wikipedia.org/wiki/Requisitos_de_Software
Veja o documento de Especificao de Requisitos de Software em http://www.ic.unicamp.br/~ariadne/inf301/doc-requisitos.pdf e tente voc mesmo gerar um documento com base num Sistema genrico (um sistema hipottico, ou um sistema que voc est trabalhando, ou ainda um sistema que precisaria ser desenvolvido, etc.).
47
NIDADE
14
48
Estudos de Viabilidade O primeiro processo a ser realizado num Sistema novo o Estudo de Viabilidade. Os resultados deste processo devem ser um relatrio com as recomendaes da viabilidade tcnica ou no da continuidade no desenvolvimento do Sistema proposto. Basicamente um estudo de viabilidade, embora seja normalmente rpido, dever abordar fundamentalmente as seguintes questes: O Sistema proposto contribui para os objetivos gerais da organizao? O Sistema poder ser implementado com as tecnologias dominadas pela equipe dentro das restries de custo e de prazo? Ou precisaria de treinamentos adicionais? O Sistema pode ser integrado, e compatvel com os outros sistemas j em operao?
Wikipdia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos
Como estamos explorando constantemente o WIKIPDIA, queremos que voc entre no site http://pt.wikipedia.org/wiki/Engenharia_de_software e veja o que voc pode aprimorar e contribuir para melhorar cada vez mais essa fantstica enciclopdia virtual.
49
NIDADE
15
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
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.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 50
Diagrama de Sequncia Diagrama de Colaborao Diagrama de Estado Diagrama de Atividade Diagrama de Componente Diagrama de Distribuio
Mostra objetos e uma sequncia das chamadas do mtodo feitas para outros objetos. Apresenta objetos e seus relacionamentos, colocando nfase nos objetos que participam na troca de mensagens. Exibe estados, mudanas de estado e eventos em um objeto ou em uma parte do sistema. Apresenta as atividades e as mudanas de uma atividade para outra com os eventos ocorridos em alguma parte do sistema. Mostra os componentes de programao de alto nvel (como KParts ou Java Beans). Destaca as instncias dos componentes e seus relacionamentos.
Os use-cases so cada vez mais utilizados para a obteno de requisitos, e so uma caracterstica fundamental na notao UML. So tcnicas baseadas em cenrios para a obteno de requisitos. Os use-cases identificam os agentes envolvidos numa interao e o tipo dessa interao. Veja exemplo abaixo.
Diagramas de Sequncia podem ser utilizados para acrescentar informaes a um use-case. Esses diagramas mostram os agentes envolvidos na interao, os objetos dentro do sistema com os quais eles interagem, e as operaes que esto associadas a esses objetos. A imagem abaixo ilustra isso.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 51
Leia o excelente artigo que mostra um estudo de caso aplicado modelagem UML: http://www.cefetsp.br/edu/sinergia/6p10c.html
52
NIDADE
16
Estamos descobrindo maneiras melhores de desenvolver software fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse trabalho, passamos a valorizar: Indivduos e interao entre eles mais que processos e ferramentas; Software em funcionamento mais que documentao abrangente; Colaborao com o cliente mais que negociao de contratos; Responder a mudanas mais que seguir um plano.
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.
DICA: visite o site do MANIFESTO GIL em http://www.agilemanifesto.org/
Portanto, com base no Manifesto gil, chega-se aos seguintes princpios bsicos: Simplicidade acima de tudo; Rpida adaptao incremental s mudanas; Desenvolvimento do software preza pela excelncia tcnica; Projetos de sucesso surgem atravs de indivduos motivados, e com uma relao de confiana entre eles; Desenvolvedores cooperam constantemente e trabalham junto com os usurios/clientes;
Copyright 2007, ESAB Escola Superior Aberta do Brasil 53
Atender o usurio/cliente, entregando rapidamente e continuamente produtos funcionais em curto espao de tempo (normalmente a cada 2 semanas); Software funcionando a principal medida de progresso; Mudanas no escopo, ou nos requisitos, do projeto no motivo de chateao; A equipe de desenvolvimento se auto-organiza, fazendo ajustes constantes em melhorias.
Esse Manifesto ocorreu para ser um contraponto as Metodologias de Desenvolvimento Prescritivas. Ou seja, enquanto o RUP (visto na Unidade 10) extremamente rgido com altos nveis de controle, e forte documentao, as metodologias geis caminham ao contrrio. Destacamos que, mesmo assim, ela no inflige a uma slida prtica da Engenharia de Software.
No grfico anterior vemos num extremo o RUP enfatizando os controles, e uma poltica de trabalho rgida. Ele mais interessante de ser utilizado com equipes grandes de desenvolvimento. Na outra ponta temos o XP, que veremos a seguir, sinalizando maior liberdade e mais adequada para equipes pequenas. E num ponto intermedirio o FDD, que veremos no final desta Unidade, como um modelo conciliador dessas duas estratgias. Um dos pontos de destaque na Metodologia gil a liberdade dada para as equipes de desenvolvimento. A declarao de Ken Schwaber define isso da seguinte forma: A equipe seleciona quanto trabalho acredita que pode realizar dentro da iterao, e a equipe se compromete com o trabalho. Nada desmotiva tanto uma equipe quanto algum de fora assumir compromissos por ela. Nada motiva tanto uma equipe quanto a aceitao das responsabilidades de cumprir os compromissos que ela prpria estabeleceu.
54
XP (Extreme Programming) O modelo gil mais conhecido o XP (Extreme Programming). Ele usa preferencialmente a abordagem orientada a objetos. O XP inclui um conjunto de regras e prticas que ocorrem no contexto de quatro atividades (veja a figura ao lado): Planejamento Projeto Codificao Teste
Existe uma grande nfase ao trabalho em duplas, no qual um analista mais experiente trabalha com um novato. Enquanto o mais jovem trabalha na programao o mais antigo vai revisando o cdigo. Dessa forma ao mesmo tempo desenvolve-se a equipe, e melhora-se automaticamente a qualidade do cdigo fonte gerado.
FDD Feature Driven Development O FDD (Desenvolvimento guiado por Caractersticas), concebido por Peter Coad, teve como premissa criar um modelo prtico de processo para a Engenharia de Software orientado a objetos. No entanto, Stephen Palmer e John Felsing aprimoraram o modelo descrevendo um processo gil e adaptativo que pode ser aplicado a projetos de software tanto a projetos de mdio como de grande porte. Dentro do contexto do FDD, o significado de caracterstica vem a ser uma funo, relativamente pequena, acertada com o cliente que pode ser implementada em menos de duas semanas, com os seguintes benefcios: Sendo as caractersticas pequenos blocos de funcionalidade, os usurios e desenvolvedores tm melhor controle e entendimento de todo o processo. Organizam-se as caractersticas em um agrupamento hierrquico relacionado ao negcio, melhorando a viso para o usurio. E para os desenvolvedores facilitando o planejamento de todo o projeto.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 55
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.
Dentro da sua empresa, ou na de amigos, verifique qual das estratgias apresentadas nesta Unidade que melhor poderia ser utilizada. Se voc, como empresrio, criasse uma empresa, qual das estratgias discutidas voc adotaria?!?
56
U
Scrum
NIDADE
17
O significado peculiar desse modelo de desenvolvimento gil vem do nome da atividade de jogadores de rugby ao trabalharem fortemente juntos para deslocar a bola pelo campo. Foi desenvolvida por Jeff Sutherland, ainda na dcada de 90. Seus princpios bsicos seguem o manifesto gil. Um ponto que se destaca nesse modelo so as Reunies Scrum. Sugere-se que sejam realizadas diariamente por 15 minutos, mas com base em nossa realidade brasileira, acreditamos que o perodo ideal seria semanal, com uma durao de 1 hora (preferencialmente as sextas-feiras tarde). So somente trs questes que so apresentadas para todos os envolvidos, e com excelentes resultados. Todos devem apresentar suas respostas com base nas seguintes perguntas: O que voc fez desde a ltima Reunio Scrum? Que obstculos voc est encontrando que podemos ajudar? O que voc planeja realizar at a prxima Reunio Scrum?
57
Crystal Criado por Alistair Cockburn e Jim Highsmith com intuito de fazer uma analogia com os cristais geolgicos que apresentam na natureza com a sua prpria cor, forma e dureza. Destaca-se a manobrabilidade com o significado de um jogo cooperativo de inveno e comunicao de recursos limitados, com o principal objetivo de entregar softwares teis funcionando e com o objetivo secundrio de preparar-se para o jogo seguinte (Presman). A famlia Crystal , na verdade, um conjunto de processos geis que se mostraram efetivos para diferentes tipos de projeto. A inteno permitir que equipes geis selecionem o membro da famlia Crystal mais apropriado para o seu projeto e ambiente.
ASD Adaptative Software Development O ASD (Desenvolvimento Adaptativo de Software) foi proposto por Jim Highsmith, com o intuito de ser uma tcnica para construo de sistemas e softwares complexos. O foco desse modelo a colaborao humana e na auto-organizao da equipe de desenvolvimento. O ciclo de vida de um ASD incorpora trs fases, detalhadas na tabela abaixo:
FASES Descrio
Planejamento do ciclo adaptativo usa informaes de iniciao do Especulao projeto para definir o conjunto de ciclos de verso (incrementos de software) que sero necessrios para o projeto. Os analistas precisam confiar um no outro para: criticar sem animosidade, ajudar sem ressentimentos, trabalhar mais do que esto Colaborao acostumados, potencializar suas habilidades, e comunicar problemas de um modo que conduza ao efetiva. medida que os membros de uma equipe ASD comeam a desenvolver os componentes que fazem parte de um ciclo adaptativo, a nfase est Aprendizado tanto no aprendizado quanto no progresso em direo a um ciclo completo.
AM Agile Modeling Conforme o site que se auto-intitula The Official Agile Modeling (veja maiores detalhes, e vale a pena visitar, em: http://www.agilemodeling.com/) Scott W. Ambler, seu criador, descreve a Modelagem gil (AM) como sendo (adaptado por ns):
58
A Modelagem gil (AM) uma metodologia baseada na prtica, para modelagem e documentao efetiva de sistemas baseados em software. Modelagem gil uma coleo de valores, princpios e prticas de modelagem de software que podem ser aplicados a um projeto de desenvolvimento de software de modo efetivo e leve. Os modelos geis so mais efetivos do que os modelos tradicionais, porque eles so suficientemente bons, no precisando ser perfeitos !
Dos princpios mais importantes da Modelagem gil (AM), anunciados por Ambler, destacamos os dois mais significativos: Modelos Mltiplos: h muitos modelos e notaes diferentes que podem ser usados para descrever softwares. Importante: apenas um pequeno subconjunto essencial para a maioria dos projetos. A AM sugere que, para fornecer a viso necessria, cada modelo apresente um aspecto diferente desse sistema e que apenas aqueles modelos que ofeream valor sua pretensa audincia sejam usados. Viajar Leve: essa expresso se refere aos turistas que para no ficar carregando pesadas malas, adotam esse princpio. No caso, para a AM, ela dita que medida que o trabalho de Engenharia de Software prossegue, conserve apenas aqueles modelos que fornecero valor em longo prazo e livre-se do resto.
59
Leia adicionalmente o interessante artigo em: http://www.heptagon.com.br/?q=node/5 para ampliar o seu conhecimento sobre as Metodologias geis. Termine essa atividade revendo as principais caractersticas, diferenas e semelhanas que existem entre os diversos modelos geis.
60
NIDADE
18
61
Uma prtica de Engenharia de Software condenvel a construo de softwares monolticos. Ou seja, um software composto de um nico e grande mdulo. Isso gera uma complexidade global quanto ao nmero de caminhos de controle, intervalos de referencia, nmero de variveis, que faz um programa ter uma baixa compreenso para todos. Outro problema a manutenabilidade do Sistema. Com poucas pessoas compreendendo o Sistema, mais difcil e custoso fica sendo a sua manuteno. Por outro lado, um software com excesso de mdulos pode acarretar no mesmo erro. O bom senso novamente a melhor resposta. Projeto de interface com o usurio Os computadores atuais fornecem uma interface chamada de GUI (Graphical User Interface Interface Grfica do Usurio), mas nem sempre foi assim. As primeiras verses eram 1D (uma nica dimenso), aonde o usurio simplesmente alimentava um terminal que podia se deslocar para a direita e esquerda. Atualmente temos os de 2D (duas dimenses), graas ao mouse podemos deslocar o ponteiro por toda a tela. E como tendncia temos j as interfaces 3D (trs dimenses). Um bom exemplo seria o Second Life. DICA: visite o SECOND LIFE no site americano www.secondlife.com . Podemos ver na tabela abaixo, as diretrizes gerais para a elaborao de uma boa interface com o usurio:
DIRETRIZES Descrio
Deve utilizar termos e conceitos que tenham como base a experincia das pessoas que vo utilizar o sistema.
62
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.
Adaptado de Sommerville
63
NIDADE
19
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
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.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 64
Concorrncia
Escabilidade
Tolerncia a Defeitos
Transparncia
Embora tendo complexidade alta, os usurios conseguem o que querem do Sistema, e sem a necessidade de se inteirar dessa complexidade.
Adaptado de Sommerville
Por outro lado, as principais desvantagens desse Sistema so: Alta Complexidade Segurana baixa Dificuldade de Gerenciamento Imprevisibilidade nos tempos de resposta
Veremos na prxima unidade os dois tipos de arquitetura de Sistemas Distribudos mais importantes: a arquitetura cliente-servidor e a arquitetura de objetos distribudos. De um modo geral os Sistemas Distribudos so desenvolvidos com o uso da abordagem orientada a objetos.
Arquitetura de Multiprocessadores
65
O modelo mais simples de Sistema Distribudo a Arquitetura de Multiprocessadores. Essa arquitetura, tpica de sistemas em tempo real, consiste em uma srie de diferentes processos que podem ser executados em processadores distintos. Os Sistemas de software compostos de vrios processos no so necessariamente sistemas distribudos. Se mais de um processador estiver disponvel, ento a distribuio poder ser implementada, mas os projetistas de sistema no precisam sempre considerar as questes de distribuio durante o processo de projeto. A abordagem de projeto para esse tipo de sistema essencialmente aquela utilizada em sistemas de tempo real.
66
NIDADE
20
c2
c3
c4
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
67
responsvel somente pelo gerenciamento de dados. E nos clientes implementada a lgica da aplicao e as interaes com o usurio do sistema.
Arquitetura de 3 camadas A arquitetura de trs camadas no necessariamente representa que existam trs tipos de computadores conecados numa rede. possvel implementar esse modelo simplesmente com um servidor assumindo a camada de dados e a de negcio simultaneamente. Para visualizarmos melhor todos esses relacionamentos vejamos a prxima figura.
Do lado direito temos um Database Server - Servidor de Banco de Dados fornecendo as solicitaes do Web Server Servidor Web (Camada de Dados). Do lado oposto, esquerda, vemos os clients (clientes), na Camada de Apresentao, como interface com os usurios. E no meio, Camada de Negcio, o Web Server prove, atravs das regras de negcio, os servios desejados ao conjunto de clientes.
Arquitetura de Objetos Distribudos A Arquitetura de Objetos Distribudos uma abordagem distinta da cliente/servidor onde elimina o conceito de distinguir quem servidor ou mesmo cliente. Entretanto criado um novo conceito chamado de middleware.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 68
O middleware intermedeia os computadores a ele conectados. tambm chamado de requisitor de objetos, e seu papel fornecer uma interface contnua de comunicao entre esses objetos. Os objetos no sistema podem ser implementados com o uso de diferentes linguagens de programao, podem ser executados em diferentes plataformas e seus nomes no precisam ser conhecidos por todos os outros objetos no sistema. Os dois padres normais para o middleware so o CORBA e o DCOM. Por todas as vantagens do padro CORBA (flexibilidade, por ser genrico, sistemas operacionais adotados), organizado pelo OMG que constituda por mais de 500 empresas, deva ser o padro de fato que o mercado ir adotar.
Pela importncia do conceito do modelo de 3 camadas, e do padro CORBA nos dias atuais, explore detalhadamente esses dois itens na Internet.
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE AULA e faa a Atividade 2 no link ATIVIDADES.
69
NIDADE
21
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
70
Dinmica da Evoluo de Programas Vamos exemplificar a Dinmica da Evoluo de Programas pegando como exemplo o Microsoft Word. Ele comeou operando como um simples processador de texto, ocupando 256Kb de memria. Hoje um gigante com tantos recursos disponveis que a grande maioria dos usurios pouco os utiliza. Necessita atualmente de muitos megabytes de memria, e mais um processador gil para que possa ser executado. A evoluo desse software, na verdade, passou por vrias fases. Alguns podem achar que trabalham somente com o mais novo release desse editor de texto. No entanto, ele no uma simples sequncia de revises, mas sim um software que sofreu vrias mudanas na sua estrutura. Em certos momentos, ele passou no s por manutenes, mas tambm por reengenharias. E atualmente at evoluindo na sua arquitetura para ficar mais condizendo com o mundo da Internet.
Evoluo da Arquitetura Os principais sistemas antigos, ou mesmo os legados, foram desenvolvidos na concepo de arquiteturas centralizadas. Hoje, a tendncia geral do desenvolvimento de sistemas com arquiteturas distribudas cliente/servidor. Quando estamos alterando a arquitetura de um sistema j existente interessante que tenhamos um modelo de camadas lgicas para nos orientar. A imagem abaixo representa as estruturas de um sistema divididas por camadas, facilitando a modularizao para uma arquitetura distribuda.
A Evoluo da Arquitetura envolve modificar a arquitetura de um sistema, a partir de uma arquitetura centralizada, centrada em dados, para uma arquitetura distribuda. Tanto a interface com o usurio quanto a funcionalidade do sistema podem ser distribudas.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 71
Uma estratgia comum da Evoluo da Arquitetura, para sistemas legados em especial, encapsular o sistema legado como um servidor. E implementa-se uma interface com o usurio distribuda, que acesse a funcionalidade do sistema (por meio de um middleware de propsito especial).
Para voc fazer uma reviso geral dos principais tpicos vistos at aqui, visite o site sugerido em ESTUDO COMPLEMENTAR, e faa um resumo por escrito dos principais tpicos de seu interesse.
72
NIDADE
22
Reengenharia de Software - Traduo de cdigo fonte - Engenharia Reversa Melhoria de estrutura de programa
Objetivo: Visualizar a importncia da reengenharia na Engenharia de Software. A principal diferena entre Reengenharia de Software e o desenvolvimento de um novo Sistema da onde que se parte esse prprio desenvolvimento. Num Sistema novo inicia-se com uma especificao escrita (os requisitos) dos usurios/clientes. Enquanto que, numa reengenharia, o sistema existente (normalmente um Sistema Legado) que a base para esse incio. Chikofsky e Cross chegam at definir o desenvolvimento tradicional como Engenharia Direta, para distinguir da Reengenharia de Software. Pode-se perceber, pela figura abaixo, a complexidade do processo de Reengenharia de Software. Embora, nem toda reengenharia passe por todos esses processos, essencialmente o programa reestruturado. Vejamos mais detalhadamente o que cada processo realiza (caixas arredondadas).
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.
74
NIDADE
23
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
75
Realize uma pesquisa na Internet sobre esse importante tpico. Procure em ingls ("Data reengineering") para encontrar mais material a respeito.
76
NIDADE
24
Gerenciamento de 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:
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.
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
Copyright 2007, ESAB Escola Superior Aberta do Brasil 77
a utilizao de um formulrio intitulado de Requisio de Mudana (CRF change request form). O formulrio CRF dever conter informaes do tipo: registro da solicitao da mudana, recomendaes, custos, datas de solicitao, aprovao, implementao e validao da mudana. aconselhvel tambm existir um espao para um esboo especificando como a mudana dever ser implementada. Um exemplo do formulrio CRF mostrado a seguir:
Gerenciamento de Verses e Releases Objetivo: acompanhar e identificar o desenvolvimento das diferentes verses e releases de um Sistema. Tambm chamado de versionamento. O release de um sistema uma verso que distribuda para os clientes (Sommerville). Logo, sempre existem muita mais verses de um sistema do que releases, pois existem muitas verses criadas para testes, ou desenvolvimento interno e no so liberadas para os clientes.
78
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
79
Devido excelente qualidade dos artigos colocados no Wikipdia especificamente neste tema, e para voc explorar mais detalhadamente os assuntos dessa unidade, visite e leia todos os links mencionados no item anterior chamado ESTUDO COMPLEMENTAR.
80
NIDADE
25
Ferramenta CASE Uma ferramenta CASE (Computer-Aided Software Engineering) significa Engenharia de Software com o auxlio de computador. Ela possibilita apoiar as atividades de processo do software, como: a anlise de requisitos, a modelagem de sistema, a depurao e os testes. Ferramentas CASE so constitudas com uma ampla gama de diferentes tipos de programas.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 81
As ferramentas CASE podem tambm incluir um gerador de cdigos que, automaticamente, origina o cdigo-fonte a partir da modelagem do Sistema. Adicionalmente pode ter alguma orientao de processo, ao fornecer conselhos ao engenheiro de software sobre o que fazer em seguida. Uma diferenciao que pode existir nas ferramentas CASE a denominao Upper-CASE e Lower-CASE. As primeiras tm como utilidade de dar apoio anlise e ao projeto, ou seja, apoiar as fases iniciais do processo de software. As ferramentas Lower-CASE, por outro lado, so projetadas para dar apoio implementao e aos testes, como depuradores, sistemas de anlise de programa, geradores de casos de testes e editores de programas. Na imagem abaixo damos um destaque para telas da ferramenta CASE como o Rational Rose da IBM:
82
Wikipdia http://pt.wikipedia.org/wiki/Ferramenta_CASE
Leia o site http://www2.dem.inpe.br/ijar/case.htm e faa um comparativo com o que voc aprendeu at agora.
83
NIDADE
26
Sistemas Legados - Estruturas dos Sistemas Legados - Avaliao dos Sistemas Legados
Objetivo: Valorar a importncia dos sistemas legados para a Engenharia de Software.
As empresas continuamente evoluem em seus Sistemas, adaptando-os a sua realidade, e as constantes mudanas do mercado. No entanto, descartar Sistemas mais antigos, os legados, e puramente substitu-los por softwares mais modernos envolve riscos empresariais significativos. Podemos dar um simples exemplo atual. Imagine, de repente, mudarmos todos os Sistemas Operacionais Windows XP, de uma grande empresa, para o novo Windows Vista, ou mesmo para um Linux. A quantidade de problemas e adaptaes necessrias ser to grande, que poderia chegar a paralisar essa empresa. Empresas com grande nmero de Sistemas Legados enfrentam dilemas fundamentais. Se continuarem com os sistemas velhos, os custos de adaptao aumentam. E se substiturem por novos, tero um custo inicial alto, e com a possibilidade de no atenderem as expectativas. Exige-se estar ciente das tcnicas de Engenharia de Software para resolver esses problemas.
Estruturas dos Sistemas Legados Pode-se dividir um Sistema Legado, do ponto vista didtico, em seis partes lgicas: Hardware do Sistema, Software de Apoio, Software de Aplicao, Dados de Aplicao, Processos de Negcios e Polticas e Regras de Negcios. Mas, veremos a seguir, que na prtica, pode-se dividir um Sistema Legado de forma mais simplificada. Ao observarmos atentamente as imagens a seguir, veremos as estruturas ideais e as reais de um Sistema Legado. O ideal seria termos a estrutura da esquerda, para numa possvel migrao termos cada componente claramente separado. No entanto, na grande maioria das vezes, encontramos a estrutura da direita.
84
Os servios sobrepem interagindo com outros componentes do Sistema. A interface com o usurio e o cdigo do servio est integrada nos mesmos componentes, e pode no haver uma ntida distino entre os servios e o Banco de Dados do Sistema. Nesses casos, pode no ser possvel identificar as partes do Sistema que podem ser distribudas (Sommerville).
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.
Copyright 2007, ESAB Escola Superior Aberta do Brasil 85
Valor X Qualidade
Descrio
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.
Adaptado de Sommerville
86
Levante na sua empresa, ou na de colegas, quantos Sistemas Legados existem. Quais so as caractersticas deles? H quanto tempo eles foram desenvolvidos? Qual o processo de mant-los no ar?!?
87
NIDADE
27
Manuteno: fundamentos da fase de Manuteno de Software, tipos de Manuteno, procedimentos, tcnicas e ferramentas
Objetivo: Identificar as principais caractersticas da manuteno de software. As leis de Lehman (1985) foram produzidas com base no estudo da mudana em Sistemas. Foram examinados o crescimento e a evoluo de uma srie de grandes sistemas de software para chegar nessas leis. Duas delas que destacamos so a da: Mudana Contnua: afirma que um programa utilizado em um ambiente do mundo real necessariamente tem de ser modificado ou se tornar de maneira progressiva menos til nesse ambiente; Aumento da Complexidade: medida que um programa em evoluo se modifica, sua estrutura tende a se tornar mais complexa. Recursos extras precisam ser dedicados para preservar e simplificar a estrutura.
Tipos de Manuteno A manuteno ser necessria durante todo o Ciclo de Vida til, e pode ocorrer motivada por trs tipos fundamentais: Tipos de Manuteno Manuteno para reparar os defeitos no software Manuteno para adaptar o software a um ambiente operacional diferente Descrio A correo de erros de codificao um processo relativamente barato comparado com os erros de projeto. Os maiores custos esto nos erros de requisitos, pois ir implicar num reprojeto. a tpica manuteno de adaptao sofrida por alguma alterao no software de apoio tal como o Sistema Operacional, Banco de Dados ou mesmo o prprio hardware.
88
Na alterao dos requisitos, devido a mudanas organizacionais, ou nos negcios, que so bastante constantes, ocorre a manuteno mais comum entre todas as outras.
Adaptado de Sommerville
Procedimentos de Manuteno O Processo de Manuteno normalmente iniciado pelos pedidos de mudana por parte dos vrios usurios que utilizam o Sistema. Isso pode ser de maneira informal, ou preferencialmente formalizado, com uma documentao estruturada. Em seguida verificado o custo e o impacto das mudanas sugeridas. Com as mudanas aprovadas, um novo release do sistema planejado.
Repare atentamente na figura acima. Veja que uma vez bem estruturado um sistema, no caso o System 1, que embora tenha despendido maiores custos de desenvolvimento, exigiu no perodo de manuteno menos tempo e recursos. Ou seja, o System 2 foi desenvolvido mais rapidamente, mas por no investir, ou visualizar, nos processos de manuteno, ao chegar nessa fase, despende maior tempo e custos. Interessante observar que a manuteno segue o mesmo modelo do processo de desenvolvimento de sistema. Na figura abaixo vemos que a representao das etapas que a manuteno que est sendo realizada, segue o mesmo Modelo Espiral que estudamos na Unidade 7.
89
Existem equipes de manuteno que atuam somente em corretivas, ou seja, somente quando existir um pedido dos usurios que se atua no problema. No entanto, a melhor estratgia a Manuteno Preventiva na qual se detecta previamente onde esto ocorrendo um maior nmero de corretivas, e destaca-se uma fora-tarefa para realizar uma reengenharia nesses processos. No quadro a seguir, veja as principais perguntas a serem feitas no Processo de Manuteno:
90
Wikipdia http://pt.wikipedia.org/wiki/Manuten%C3%A7%C3%A3o_de_software
Na sua empresa como realizada a atividade de Manuteno? As equipes de Informtica esto sempre realizando corretivas, ou esto mais focadas em preventivas?!? Quanto porcentualmente no ms voc imagina dedicado para essa funo? Essa atividade especfica de uma equipe, ou a mesma de desenvolvimento?!?
91
NIDADE
28
Essas atividades sofrem com dificuldades tpicas de desenvolvimento de software. A produtividade no linear em relao ao tamanho da equipe e o aumento de produtividade no imediato devido os custos de aprendizado dos novos membros. A diminuio de qualidade para acelerar o desenvolvimento constantemente prejudica a produtividade. A estimativa de dificuldades e custos de desenvolvimentos so muito difceis, alm do surgimento de problemas tcnicos. Esses fatores requerem uma Anlise de Riscos cuidadosa.
92
PMBOK O PMBOK uma importante referncia em Gerenciamento de Projetos. Desenvolvido pelo PMI (Project Management Institute) possibilitou utilizar termos em comum para se discutir, escrever e aplicar o Gerenciamento de Projetos. O guia atualmente base para uma certificao especfica e bem remunerada no mercado. Como os profissionais de Engenharia de Software praticamente so gerentes de projetos, existe a necessidade do entendimento desse conjunto de prticas para o bom desenvolvimento de um projeto de software. A estrutura do PMBOK Guide (veja a imagem a seguir - os nmeros entre parnteses representam respectivamente os blocos da imagem) contempla nove reas de conhecimento especficas, que so:
Gerenciamento da Integrao do Projeto (4) Gerenciamento do Escopo do Projeto (5) Gerenciamento do Prazo do Projeto (6) Gerenciamento do Custo do Projeto (7) Gerenciamento da Qualidade do Projeto (8) Gerenciamento dos Recursos Humanos do Projeto (9) Gerenciamento da Comunicao do Projeto (10) Gerenciamento dos Riscos do Projeto (11) Gerenciamento das Aquisies do Projeto (12)
93
94
Para voc explorar mais adequadamente os objetivos do PMBOK, baixe o arquivo do site: http://www.prodepa.psi.br/sqp/pdf/Captulo 01 - Introduo.pdf e leia o primeiro captulo, em portugus, desse importante livro de Gerenciamento de Projetos.
95
NIDADE
29
ITENS
Perguntas At que ponto o processo est definido e com que facilidade se compreende a definio do processo? As atividades culminam em resultados ntidos, de forma que o progresso do processo seja visvel? At que ponto as atividades do processo podem ser apoiadas por ferramentas CASE?
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?
96
(adaptado de Sommerville)
Os principais fatores da qualidade de produtos de software, ou mesmo para quaisquer outros produtos intelectuais (livros, filmes, etc.), so:
A tecnologia de desenvolvimento Qualidade do pessoal Qualidade do processo (como vimos anteriormente !) Custo, tempo e cronograma
E de todos esses elementos o mais significativo o ltimo. Pois se um projeto tiver um oramento baixo, ou ainda pior, um cronograma de entrega fora da realidade, a qualidade ser diretamente afetada.
Estratgias de Teste de Software Um princpio bsico na realizao de Testes de Software (principalmente em Sistemas de media complexidade para cima) diferenciar a equipe puramente de desenvolvimento, da equipe especificamente de testes. Ou seja, quem desenvolve no testa, e quem testa no desenvolve. Uma das estratgias de Teste de Software a abordagem Top-down e a Bottom-up (veja a figura abaixo). Enquanto que a primeira (lado esquerdo da figura) tenta ver a integrao de todos os componentes de um Sistema comeando pelos nveis superiores, a segunda a Bottom-up (lado direito da figura), comea pelos nveis inferiores. As duas estratgias tm pontos positivos e negativos. O mais comum utilizar a abordagem Top-down, por ser mais natural.
Test d ri ve rs Le v e l N Le ve l N Le ve l N Le v e l N Le v e l N s
Level 2
Le vel 2
Level 2
Test d ri v e rs
Leve l N 1
Le v el N 1
Le v e l N 1
Le vel 3 stubs
BOTTOM-UP
97
Quando um software construdo especificamente para um cliente, normal ele passar por um Teste de Aceitao. Esse teste por ser conduzido pelo prprio usurio, pode passar por uma bateria de testes levando s vezes semanas, ou mesmo meses, para ser finalizado. No entanto, se o software feito para vrios clientes, o Teste de Aceitao no vivel de ser realizado por cada usurio principal. Por isso, a estratgia melhor a ser aplicada a dos Testes Alfa e Beta. Para a realizao dos Testes Alfa existe a necessidade de um ambiente controlado. Ou seja, os usurios so levados a testar o software desde os seus estgios iniciais de instalao, at a sua operao completa. Tudo isso realizado num ambiente especial, onde fiquem registradas todas as impresses dos usurios, suas reaes s interfaces homem-mquina, e assim por diante. Os Testes Beta so realizados exclusivamente no habitat do usurio. E realizado tipicamente sem a presena dos desenvolvedores, ao contrrio do Alfa. Normalmente selecionado um pblico especial de usurios, com um perfil crtico e colaborador. importante a escolha adequada de usurios nesse tipo de teste. Pois existe a necessidade do prprio usurio deixar todas suas observaes, questionamentos e sugestes, registrados de forma minuciosa e com riqueza de detalhes.
Testes Caixa-Branca e Caixa-Preta O Teste Caixa-Branca, tambm chamado de Teste Estrutural, foca-se mais nos possveis erros internos ao Sistema. E o Teste Caixa-Preta visa identificar as falhas em seu comportamento externo. Enquanto o Teste Caixa-Branca realiza testes na estrutura dos componentes de um Sistema, o Caixa-Preta refere-se aos testes que so conduzidos na interface do software. Para realizar os Testes da Caixa-Branca so utilizadas tcnicas tais como: Testes de Caminho Bsico o Notao de Grafo de Fluxo o Caminhos Independentes de Programa o Derivao de Casos de Teste o Matrizes de Grafos Testes de Estrutura de Controle o Teste de Condio o Teste de Fluxo de Dados o Teste de Ciclo
98
No caso dos Testes de Caixa-Preta que focalizam nos requisitos funcionais do software so os mais utilizados no mundo prtico. Os Caixa-Branca demandam muito tempo, e praticamente no conseguem realizar todas as possibilidades de resposta que um software fornece. As principais tcnicas utilizadas nos Testes de Caixa-Preta so: Mtodos de Teste baseados em Grafo o Modelagem de fluxo de transao o Modelagem de estado finito o Modelagem do fluxo de dados Particionamento de Equivalncia Anlise de Valor-limite Teste de Matriz Ortogonal
Responda, por escrito, aos questionamentos abaixo: Que itens voc levaria em considerao para a melhoria da qualidade de um software? Quais so as diferenas das estratgias aplicadas para testar um software?
99
NIDADE
30
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.
101
Projeto Esttico
Projeto de Contedo
Projeto de Navegao
Representa o fluxo de navegao entre objetos de contedo e todas as funes da WebApp. Identifica a estrutura de hipermdia para a WebApp. Desenvolve a lgica de processamento detalhada necessria para implementar os componentes funcionais.
Adaptado de Pressman
Projeto Arquitetural
Projeto de Componente
Arquitetura da WebApp Conforme Jacyntho, as aplicaes devem ser construdas usando camadas nas quais diferentes preocupaes so levadas em conta. Em particular, dados da aplicao devem ser separados dos contedos da pgina da Web. E esses contedos, por sua vez, devem ser claramente separados dos aspectos da interface. Os autores sugerem um projeto de arquitetura em trs camadas (veja a figura abaixo) que desaclopa a interface da navegao, e do comportamento da aplicao. Os mesmos argumentam que manter a interface, aplicao e navegao separadas simplifica a implementao e aumenta o reuso.
co n t ro ller
m an ag e s u se r re q u e st s se le ct s m o d e l b e h av io r se le ct s v ie w re sp o n se u se r re q u e st o r d at a b ro wse r v ie w se le ct io n
b e h av io r re q u e st ( st at e ch an g e )
m o del
e n cap su lat e s f u n ct io n alit y e n cap su lat e s co n t e n t o b je ct s in co r p o r at e s all we b A p p st at e s clie n t d at a f ro m m o d e l
HTML d at a
view
p re p are s d at a f ro m m o d e l re q u e st u p d at e s f ro m m o d e l p re se n t s v ie w se le ct e d b y co n t ro lle r
u p d at e re q u e st
e xt e rn al d at a
se rv e r
102
A arquitetura mais utilizada nesse caso a Modelo-Viso-Controlador (MVC Model-ViewController). Embora seja um padro de projeto arquitetural desenvolvido para o ambiente Smalltalk (linguagem de programao orientada a objeto), ele pode ser utilizado para qualquer aplicao interativa. Veja os detalhes de cada item da arquitetura MVC na tabela abaixo: ITEM do MVC MODELO 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
Veja os links colocados no ESTUDO COMPLEMENTAR, e escreva quais so as caractersticas e diferenas da Web 2.0 e da Web 3.0. Aproveite e veja com maior riqueza de detalhes a arquitetura MVC no link http://pt.wikipedia.org/wiki/MVC
103
Apresentao
O estudo da Engenharia de Software permite entender os principais aspectos da produo e manuteno de programas e Sistemas. Para tanto, abordam-se desde os estgios iniciais da construo de um Sistema, at mesmo a manuteno de Sistemas legados.
Objetivo
Apresentar conceitos bsicos da Engenharia de Software. Detalhar os principais mtodos, ferramentas e procedimentos ligados disciplina da Engenharia de Software. Discutir os principais aspectos que levam as organizaes a utilizar as melhores prticas da Engenharia de Software. Capacitar os alunos a identificar quais os mtodos, ferramentas e procedimentos mais adequados ao processo de desenvolvimento ou manuteno de softwares.
Carga horria
40 horas
Ementa
Apresentao dos mtodos, ferramentas e procedimentos da Engenharia de Software, atravs das fases do Ciclo de Vida do Desenvolvimento de Software. E como podem ajudar as organizaes a desenvolver Sistemas de acordo com os custos, prazos, recursos e qualidades planejadas.
Requisitos
Ter realizado e sido aprovado no mdulo anterior.
Bibliografia do mdulo
PRESSMAN, Roger. Engenharia de Software. So Paulo: McGraw-Hill Brasil, 2006 SOMMERVILLE, Ian. Engenharia de Software. So Paulo: Pearson Addison Wesley, 2005 REZENDE, Denis Alcides. Engenharia de Software e Sistemas de Informao. Rio de Janeiro: Brasport, 2005.
104
Sobre o autor
Professor e Consultor de Tecnologia de Informao Doutorando (ITA) e Mestre (IPT) em Engenharia de Computao, Ps-Graduado em Anlise de Sistemas (Mackenzie), Administrao (Luzwell-SP), e Reengenharia (FGVSP). Graduado/Licenciado em Matemtica. Professor e Pesquisador da Universidade Anhembi Morumbi, UNIBAN, e ESAB (Ensino a Distncia). Autor de 3 livros em Conectividade Empresarial. Prmio em E-Learning no Ensino Superior (ABED/Blackboard). Consultor de T.I. em grandes empresas como Sebrae, Senac, Granero, Transvalor, etc. Viagens internacionais: EUA, Frana, Inglaterra, Itlia, Portugal, Espanha, etc.
Antes de dar continuidades aos seus estudos fundamental que voc acesse sua SALA DE AULA e faa a Atividade 3 no link ATIVIDADES.
105
Atividade Dissertativa Desenvolva uma pesquisa gerando um texto, de 2 a 3 folhas adicionando imagens, de uma das unidades da nossa apostila, de sua livre escolha, permitindo a expanso da temtica selecionada. Ateno: Qualquer bloco de texto igual ou existente na internet ser devolvido para que o aluno realize a atividade novamente.
106