Processos de software Objetivos 0 objetivo deste capitulo é apresentar a idela de um processo de software — um conjunto coerente de atividedes pars a produgdo de sofware teminardelerestecapie,voct; | 2 Ais doporsn 2.3 Lidandocom mutancs + compreenderd os conceit e modelos de processos de software; | 24 RatnalUied Paces RUP) + terd sido apresentado a trés modelos genéricos de processas de software e quando eles podem ser usados; + conhecerd as atividades fundamentais do processo de engenha- ra derequlsitos de software desenvolvimento de software testes e evolugio; + entenders por que os processos devem ser orgarizados de max neira a lidar com as mudangas nos requisitos € projeta de sof ware; + compreenders como o Rational Unified Process integra boas pré- ticas de engenhatia de software para clar processos de software adaptive's 2:1. Modelos de process de software Contetido im processo de software é um conjunto de atividades relacionadas que leva & producdo de um produto de soft ware, Essas atividades podem envolver o desenvolvimento de software a partir do zero em uma linguagem padréo de programacdo como Java ou C. No entanto, aplicagdes de negécios néo sao necessariamente desenvolvidas dessa forma. Atualmente, novos softwares de negécios sao desenvolvidos por meio da extensio e modificagao de sistemas existentes ou por melo da configuracio e integraco de prateleira ou componentes do sistema, Existern muitos processos de software diferentes, mas todos dever incluir quatro atlvidades fundamentals para a lengenhatia de software 1. Fspecificagdo de software. A funcionalidade do software e as restrigées a seu funcionamento devem ser definidas, 2. Projetoe implementagao de sofware. 0 software deve ser produzido para atender as especificagoes. 3. Validagdo de software. O software deve ser validado para garantir que atenda &s demandas do cliente 4. volugao de software. 0 software deve evoluir para atender as necessidades de mudanga dos clientes, De alguma forma, essas atividades fazem parte de todos os processos de software. Na pratica, sao atividades complexas lem si mesmas, que incluem sulpatividades como validacao de requisitos, pojeto de arquitetura, testes unitérios etc. Existem também as atividades que dio apoio ao processo, como documentagao e gerenciamento de configuragso de software.Capitulo? Processos de software 19 ‘Ao descrever e discutir os processos, castumamas falar sobre suas atividades, coma a especificacéo de um modela de dads, o projeto de interface de usuario etc, bem como a organizagio dessas atividades, No entanto, assim como as atividades, as descrigées do processo também padem incluit: 1. Produtos, que sio 0s resultados de uma das atividades do processo, Por exemplo, o resultado da atividade de pro- Jeto de arquitetura pode ser um modelo da arquitetura de software, 2. Papéis, que refletem as tesponsabllidades das pessoas ervalvidas no pracessa, Exemplos de papéis sio: gerente de projeto, gerente de configuragio, programador exc. 3. Prée pés-condigées, que sto declaracdes verdadeiras antes e depo's de uma atividade do pracesso ou da produ- ‘¢éo de um produto. Por exemplo, antes do projeto de arquitetura ser inilaco, pode haver uma pré-condigao de ue todos 05 requisitos tenham sido aprovados pelo cliente e, apés a conclusdo dessa atividade, uma pés-condigao ppoderia ser a de que os modelos UML que descrevem a arquitetura tenham sido revisados Os processos de software so complexos €, como todos os processos intelectuals e crativos, dependem de pessoas para tomar decisées e fazer julgamentos. Nao existe um processo Ideal, a maioria das arganizagSes desenvolve os pré- prios processos de deserwolvimento de software. Os processos térn evoluldo de maneira a tirarem melhor proveito das capacidades das pessoas em uma organizacso, bem como das caractersticas espectficas do sistema em desenvalvimento, Para alguns sistemas, como sistemas erticos, ¢ necessaria urn processa de desenvolvimento muito bem estruturado; para sistemas de negécias, com requisites que se alteram rapidamerte, provavelmente sera mais eficaz um pracesso menos formal e mais exivel Os processos de software, ds vezes, sto categorizados come ditigidos a planos ou processes gels, Processos dirigidos a planos s80 agueles ern que todas as atividades so planejadas com antecedéncla, e 0 progresso é avaliado por compa- ragéo com 0 planejamento inicial Em pracessos Sgeis, que ciscuto no Capitulo 3,0 planejamento é gtadativo, e & mals fc alterar © processo de maneira a refletir as necessidades de mudanca dos clientes. Conforme Boehm e Turner (2003), cada abordagem é anropriada para diferentes tipos de software. Geralmente, é necessério encontrar um equilrio entre os processos drigidos a planos ¢ os processos Sgels Embora nao exista um processo ‘ideal’ de software, hd espaco, em multas organizagdes, para melhorias no proceso de software. Os processos podem incluir écnicas ultrapassadas ou no aproveltar as melhores praticas de engenharia de software da indstria, De fato, muitas empresas ainda ndo se aproveltam dos métodos da engenharia de software em seu desenvolvimento de software. Em organizagées nas quais a diversidade de pracessos de software & reduzida, os processos de software podem ser melhorados pela padronizacéo. ss0 possiblita uma melhor comunicagéo, além de reducio no periode de treinamento, e torna mals econémico 0 apoio 20 processo automatizado. A padronizacao também é um importante primeiro passo na introdugao de novos métodos e técnicas de engenharia de software, assim como as boas préticas de engenharia de software, No Capitulo 26, discuto mais detalhadamente a melhoria no pracesso de software, GG 2.1, Modelos de processo de software ‘Como expliquei no Capitulo 1, um modelo de processo de software é uma representacao simplificada de um processo de software, Cada modelo representa uma perspectiva particular de um processe e, portanto, fornece informagGes parciais sobre ele. Por exemplo, um modelo de atividade do processo pode mostrar as atividades fe sua sequéncia, mas nao mostrar os papéis das pessoas envoividas. Nesta se¢ao, apresento uma série de mo- delos gerais de processos (algumas vezes, chamados'paradigmas de process) a partir de uma perspectiva de sua arquitetura, Ou seja, nés vemos um framework do proceso, mas nao vemos os detalhes de suas atividades especiicas Esses modelos genéricos nao sto descrigées defiitivas dos pracessos de software. Pelo contrétio, 40 abs- tragdes que podem ser usadas para exolicar diferentes abordagens de desenvolvimento de software. Vocé pode vvé-ios como fiamevvorks de processos que podem ser ampliados e adaptados para criar pracessos de engenharia de software mais especificos Os modelos de processo que abordo aqui sio: 1. Omodelo em cascata. Esse modelo considera as atividades fundamentals do processo de especificacéo, desen- volvimento, validacéo e evolugao, e representa cada uma delas como fases distintas, coma: especificagao de requisitos, projeto Ge software, implementagao, teste e assim por dante20 Engenharia de software 2. Desenvoivimento incremental, Essa abordagem intercala as atividades de especificacéo, desenvolvimento e var lidagao. 0 sistema é desenvalvido como uma série de versées (incrementos}, de maneira que cada versio adiciona funcionalidade & anterior. 3. Engenharia de software orientada a redso, Essa abordagem & baseada na existéncia de um numero significative de componentes reusaveis, O proceso de desenvolvimento do sistema concentra-se na integracao desses components em um sistema jé existente em vez de desenvolver um sistema a partir do zero. Esses modelos nia sio mutuamente exclusives e muitas vezes sio usados em conjunto, especialmente para fo desenvolvimento de sistemas de grande porte. Para sistemas de grande porte, faz sentido combinar alguras ddas melhores caracteristcas do modelo em cascata e dos madelas de deservolvimento incremental. € precisa ter informagéies sobre os requisitos essenciais da sistema para projetar uma arquitetura de software que dé suporte a esses requisitos. Vocé nao pode desenolver isso incrementalmente. Os subsistemas dentro de um sistema maior podem ser deservolvidas com diferentes abordagens. As partes do sistema que sia bem compreendidas podem ser especificadas e desenvolvidas por meio de um pracesso baseado no modelo em cascata, As partes que So difceis de especificar antecipadamente, como a interface com 0 usuario, devern sempre ser desenvolvidas por ‘meio de uma abordagem incremental $25) 2.1.10 modelo em cascata 0 primeiro modele do proceso de desenvolvimento de software a ser publicado fol derivado de processos ‘mais gerais da engerharia de sistemas (ROYCE, 1970). Esse medelo é ilustrade na Figura 2.1. Por causa do encade amento entre uma fase e outra, esse modelo é conhecido como modelo em cascata, ou ciclo de vida de software. 0 modelo em cascata é um exemplo de um proceso dirfgide a planos — em principio, voce deve planejar e programar todas as atividades do processo antes de comecar a trabalhar nelas. Os principais estégios do modelo em cascata refletem diretamente as atividades fundamentals do desenvok vimento: 1. Andlise e definigdo de requistos, Os servigos, restrigGes e metas do sistema so estabelecidos por meio de consulta aos usuarios. Em sequida, s30 definidos em detalhes e funcionam como uma especificagao do sistema, 2. Projetode sistema e sofware. 0 proceso de projeto de sistemas alaca os requisitos tanto para sistemas de hard- ‘ware como para sistemas de software, por meio da definicdo de ume arquitetura geral da sistema. O projeto de software envolve identficagio e descricio das abstracdes fundamentals do sistema de software e seus relacionamentos, 3. implementagdo e teste unit, Durante esse estigio,o projeto do software & desenvolvido como um conjunto de programas ou unidades de programa, O teste unitério envolve a verificagao de que cada unidade atenda a sua especificagao, Figura2t mo Definisio de requistos ~| Projeto de sistema ‘crottware implementagée ‘testeunitarlo 1 Integracdoe tere de sistema | 1 Operioe manutengieCapitulo? Processos de software 21 A, Integrasdo e teste de sistema. As unidades individuals do programa ou pragramas so integradas e testadas ‘como um sistema completo para assegurar que as requistos do software tenham sido atendidos, Apés o teste, a sistema de software € entregue ao cliente 5. Operagdo e manutengdo, Normalmente (embora ndo necessariamente), esa & a fase mais longa do ciclo de vida. © sistema é instalado e colocado em uso. A manutengao envolve a corregao de erros que nao foram descobert0s em estigios inicials do ciclo de vida, com melhora da implementagao das unidades do sistema e ampliagao de seus servigos em resposta as descobertas de novos requistos. Em principio, 0 resultado de cada estigio é a aprovagdo de um ou mais documentos (assinados). 0 estagio seguinte no deve ser iniciado até que a fase anterior seja concluida. Na pritica, esses estagios se sobrepoem e alimentam uns aos outtas de informacdes. Durante o projeto, os praflemas com as requisits sio identficados; durante a codificacio, problemas de projeto so encontrados e assim por diante. 0 pracesso de software néo ¢um modelo linear simples, mas envalve o feedback de uma fase para outra. Assim, 0s documentos produzidos em cada fase podem ser modificados para refletiem as alteragdes feitas em cada um deles. Por causa dos custos de produgio e aprovagdo de documentos, as iteragSes podem ser disnendiosas e en- volver significativo retrabalho Assim, apes um pequeno niimero de iteracdes, & normal se congelarem partes do desenvolvimento, como a especificagso, ¢ dar-se continuidade aos estigios posteriores de desenvolvimento, A solugio dos problemas fica para mais tarde, ignorada ou progtamada, quando possivel. Esse congelamento pre- maturo dos requistos pode significar que o sistema nao fara o que o suo quer. Também pode levar a sistemas ‘mal estruturados, quando os problemas de projeto sic contornados por atiffcios de imlementagio. Durante o estagio final do ciclo de vida (operagio e manutensio), 0 software € colocado em uso, Exros & lomisses nos requisites originals do software sio descobertos, Os eros de programa e projeto aparecem e so identificadas novas necessidades funcionais. © sistema deve evolu para permanecer util, Fazer essas alteragbes [manutencio do software) pode implica repetisio de estagios anteriores do processo, ‘© modelo em cascata é consistente com outros modelos de processos de engenharia, e 2 documentagao 6 produzida em cada fase do ciclo. Dessa forma, o processo torna-se visivel, © os getentes podem monitorat 0 progresso de acordo com o plano de desenvolvimento. Seu maior problema & 2 dlvisio inflexivel do projeto em estgios distintos. Os compromissas devem ser assumidos em um estagio inicial do processo, o que dificulta que atendam 8s mudangas de requisitos dos clientes, {im principio, o modelo em cascata deve ser usado apenas quando os requisitos sdo bem compreendidos pouco provavelmente venham a ser radicalmente alterados durante o desenvolvimento do sistema, No entanto, 0 modelo em cascaia eflete 0 tipo de processo usado em autos projetos de engenharia, Como é mais facil usar um modelo de gerenciamento comum para todo 0 projeto, processos de software baseados no madelo em cascata ainda so comumente utlizados Uma vatiagae importante do modelo em cascata é o desenvolvimento formal de um sistema, em que se cria um modelo matematico de uma especificagio do sistema. Esse modelo é entéo refinado, usando transforma- oes matemiticas que preservam sua consisténcia, em cédigo executével Partindo do pressupasto de que suas transformacdes matemiticas esto corretas, vocé pode, portanto, usar um forte argumiento de que um programa gerado dessa forma é consistente com suas especiicacées Processos formals de desenvolvimento, como os baseados no métode B (SCHNEIDER, 2001; WORDSWORTH, 1996), so particularmente adequados para 0 desenvolvimento de sistemas com requisites rigorosos de segu- ranga, confiablidade e protecdo, A abordagem formal simplifica a producao de casos de sequranca ou protesao. Iss0 demonstra aos clientes ou reguladores que o sistema realmente cumpre com seus requisites de protecio ou seguranga Processos baseados em transforrmagies formals sao getalmente usados apenas no desenvolvimento de sisternas critics de seguranga ou de protegdo. les exigem conhecimentos especialzados. Para a meioria dos sistemas, esse processo néo oferece custo-benefici signiicativa sobre outras abordagens para o desenvolvimento de sistemas, 2.1.2 Desenvolvimento incremental (© desenvolvimento incremental é baseado na ideia de desenvalver uma implementagio inical, expé-la aos comentatios das ususrios e continuar por meio da criagao de varias versdes até que um sistema adequado seja desenvolvido (Figura 2.2). Atividades de especificacio, desenvolvimento e validagao sie intercaladas,e no sepa- radas, com rapido feedback entre todas as atividaces.22 Engenharia de sofware FigWa22) Sesenvclvimenta incremental ‘vida simalness Espeateagio) > Venton Versoee Deserieio |__| coesbo90 Desenvolvimento) [Titers Valagio |) ——> Versio al Desenvolvimento incremental de software, que é uma parte fundamental das abordagens Ses, é melhor do «que uma abordagem em cascatapara a maioria dos sistemas de negécios e-commerce sistemas pessoais Desen- volvimento incremental reflete a maneia como resolvemos 0s problemas, Raramente elaboramos uma completa solugéo do problema com antecedéncia; geralmente movemo-nos passo a passo em diecio a uma Solusdo, r= cuando quando percebemos que cometernos um ero, Ao desenvolver um software de forma incremental € mas barato e mais fc fazer mudangas no software durante seu desenvolvimento. Cada incremento ou versio do sistema incorpora slguma funcionalidade necesséria para o lente. Frequen: temente, os incrementos inci incluem 2 funcionalidade mais importante ou mais gente so significa que 0 cliente pode aaliaro sistema em um estégio rlativamente iricial do desenvolvimento para verse ele oferece 0 que fo requistado. Em caso negativo 56 0 incremento que estwver em denwolvimento no momento precisaré ser alterado e, passivelmente, nova furcionalidade deverd ser defnida para increrentos pasterores. 0 deserwolvimente incremental ten t@s vantagens importantes quando comparado ao modelo em cascata 1, O custo de acomodar as mudangas nos requisitos do cliente 6 reduzido, A quantidade de andlse e documen- {a0 a ser reeita & muito menor do que © necessirio no modelo em cascata 2. E mais faci obter feedback dos clientes sobre o desenvolvimento que fo feito. Os clientes podem fazer comer Uris sobre as demonstragdes do software e ver 0 quanto fol implementado. Os clientes iém dificuldade em avalar a evolucio por meio de documentos de projeto de sofware. 3. E possivel obter entrega e implementacéo répida de um software iti 20 cliente, mesmo setods 2funconalida- de no for incluids. Os clientes podem usar e obter ganhos a partir do software incial antes do que é possvel cam um processo em cascata, 0 desenvolvimento incremental, atualmente, é a abordagem mais comum para o desenvolvimento de sis temas aplicatives. Essa abordagem pode ser tanto dirigiéa a planes, igi, ou, 0 mais comum, uma mescia dessas abordagens. Em uma abordagem dirigida a planos, os incrementos do sistema so identificados previamente; se uma abordagem agil for adotaca, os incrementos inicias S40 identificados, mas o desenwolvimente de incremen tos posteriores depende do progresso e das prioridades dos clientes, Do ponto de vista do gerenciementa, a abordagem incremental tem dois problemas 1. O processo nao & vislvel, Os gerentes precisam de entregas regulares para mensurar 0 progresso, Se os sistemas sc desenvolvidos com rapidez, ndo ¢ economicamente vidvel produzir documentos que refitam cada uma das versbes do sistema 2. A estrutura do sistema tende a se degradar com a adigio dos novos incrementos. A menos que tempo € dinheito sejam dispendices em refatoragéa para melhoria do software, as constantes mudangas tendem a corromper sua estrutura. Incorporarfuturas mudangas do software torna-se cada vez mais cif e oneroso. 0s problemas do desenvolvimento incremental so particularmente criticos para os sistemas de vida-longa, grandes e complexos, nos quais varias equines desenvolvem diferentes partes do sistema, Sistemas de grande por- te necessitam de um framework ou arquitetura estivel, eas responsabildades das diferentes equipes de trabalho do sistema precisam ser claramente definidas, espeitando essa arquitetura, sso deve ser planejado com antece- déncia, endo desenvolvide de forma incrementalCapitulo? Processos de software 2B Vocé pode desenvolver um sistema de forma incremental ¢ expé-lo 20s comentarios dos clientes, sem real mente entregé-lo e implanté-lo no ambiente do cliente. Enirega e implantagdo incremental significa que o soft- ware & usado em processos operacionais reals. Isso nem sempre é possivel, pois experimentagSes com © nova software podem interromper os processos normais de negacios. As vantagens e desvantagens da entrega incre- mental séo discutidas na Seco 23.2 <@, 2.1.3 Engenharia de software orientada a retiso Na maioria dos projetos de software, hi algum retso de software Iso acontece multas vezes informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou cédigos semelhantes ac que é exigido, Flas os bbuscam, fazem as modificagdes necessétias e incorporam-nos a seus sistemas Esse retiso informal corre independentemente do pracesso de desenvolvimento que se use. No entanto, no século XX), pracessos de desenvolvimento de software com foco no retiso de software existent tornaram-se amplamente usados. Abordagens orientadas a retiso dependem de uma ampla base de components reusdveis de software € de um framework de integragio para a composicéo desses componentes. Em alguns casos, esses Componentes sao sistemas completos (COTS ou de pratelera), capazes de fornecer uma funcionalidade espectica como pracessamento de texto ou planiha. Um modelo de processo geral de desenvolvimento baseado no retiso esté na Figura 23, Embora 0 estagio de especiticagae de requisitosiniciais e o estagio de validacao sejam comparavels a outros processos de software, os estigios intermedisrios em um processo orientado a retso s8o diferentes. Esses estigios sao: 1. Andlise de componentes. Dada a especificagio de requisites, ¢feita uma busca por componentes para imple- mentar essa especificagio. Em geral, no hd correspandéncia exata, @ as companentes que podem ser usados ‘apenas fornecem algurva funcionalidade necesséria, 2. Modificagdo de requisitos. Durante esse estégio, 0s requisitos séo analisados usando-se informagées sobre os ccomponentes que foram descobertos, Em seguida, estes sero modificados para refleti os components dis- poniveis, No caso de modificacdes impossives, a atividade de andlise dos componentes pode ser reinserida na ‘busca por solugdes alternativas. 3. Projeto do sistema com reuso, Durante esse estigio,o framework do sistema é projetado ou algo existente &reu- sado, Os projetistas tém em mente os componentes que serdo teusados e erganizam o framework para eso, Alguns softwares novos podem ser necessarios, se componentes reusdvels nao estiverem disponivels. 4, Desenvolvimento e integragdo. Softwares que no poder ser adquiridos externamente so deservolvidos, e 0s componentes e sistemas COTS so integrados para criar © navo sistema, A integragio de sistemas, nesse mo- delo, pode ser parte do processo de desenvolvimento, em vez de uma atwvidade separeda Existem trés tioos de componentes de software que podem ser usados em um processo orientado a reiso: 1. Web services deservolvidos de acordo com os padrdes de servigo © que estéo disponivels para invocagao remota, 2. Colegées de objetos que sdo desenvolvidas como um pacote a ser integrado com um framework de compo- nrentes, como NET ou J2EE. 3. Sistemas de sofware st alone configuradios para uso em um ambiente particular, Engenharia de software arientada a retiso tem a vantagem dbvia de reduzir a quantidade de software a ser desenvolvido e, assim, reduzir os custos e riscos. Geralmente, também proporciona a entrega mais répida do software. No entanto, compromisos com os requisites so inevitaveis, ¢ isso pode levar a um sistema que no FIgWaRSY) Engenharia de software orientada a reaso Especiicagio Anil de ‘teragbes nos Projet de sistema requis componentes 7 tequstes 7 comreuso r Desenvolvimenta| | Vaidagto ‘eimtegragie desitems24 Engenharia de software atende as reais necessidaces dos usuérios. Além disso, algumn controle sobre a evalugéo do sistema & perdido, pols as novas vers6es dos components reusdveis no estéo sob o controle da organizagio que os esté util- zando. Redso de software & um tema muito importante, a0 qual dediquel varios capitulos na terceira parte deste livo, Questées gerais de retiso de software e redso de COTS serdo abordadas no Capitulo 16; a engenharia de software baseada em components, nos capilulos 17 e 18; sistemas orientados a servigos, no Capitulo 19, G22 Atividades do processo Processos reais de software sio intercaladas com sequéncas de atividades técnica, de colaboragio e de ge- réncia, com o intuito de especiicar, projetar,implementar e testar ur sistema de software. Os deservoWtedores de software usam uma variedade de diferentes ferramentas de software em seu trabalho, As ferramentas s80 es pecialmente iteis para apoiar a edicéo de diferentes tipas de documentos e pare gerenciar 0 imenso volume de informacées detalhadas que é gerado em um projeto de grande porte. As quatro atividades basicas do processo — especificagéo, desenvolvimento, validacéo e evolugéo — sio or garizadas deforma diferente conforme o processo de desenvolvimento, No madelo em cascatas80 orgarizadas tem sequéncia,enquanto que no desenvolvimento incremental io incercaladas. A manera como essas atvidades sero fetas depende do tipo de software, das pessoas e das estruturas organizacionals envolvidas Em extreme pro gramming, por exemple, as especifcagbes estéoescritas em cartes, Testes so executaveis e desenvolvidos antes do préptio programa. A evolugso pode demandar reestruturagio substancial do sstema ou refatoracio, 2.2.1 Especficagao de software Especificagio de software ou engenhatla de requisitos & 0 processo de compreensio e definico dos servigos requisitados do sistema e identficagdo de restrigdes relativas & operagio e a0 desenvolvimento do sistema. A engenhatia de requisitos é um estagio particularmente critica do processo de software, pols erros nessa fase ine- vitavelmente geram problemas no projeto e na implementacao do sistema 0 processo de engenharia de requistos (Figura 24) tem como ebjetivo produzir um documento de requisitos acordados que especiica um sistema que satistaz os requisitos dos stakeholders. Requisites sao geralmente apre- sentados em dois nivels de detalhe. Os usuarios finals e os clientes precisam de uma declaracao de requisites em alto nivel; desenvolvedores de sistemas precisa de uma especificagée mais detalhada do sistema, Existern quatro atividades principais do processo de engenharia de -equisitos: 1. Fstudo de viabilidade, € feita uma estimativa acerca da possiblidade de se satisfazerem as necessidades do Usuario identiicado usando-se tecnologias atuais de software e hardware. O estudo considera se o sistema FIGUERIAN) 05 requisitos da engenharia de processos Estado da Eliagio eansice vinbiidace erequ Especiagion Reltoro Validagio de viabildade de requisites Modelos de sistema t Requlsitos de usudtos ede sistema ~ Documentagse ZL derequiitosCapitulo? Processos de software 25 proposto serérentével a partir de um ponto de vistade negécioe se ele pode ser desenvolvdo no Smibito das _tuaisrestices orgamentais. Um estudo de viabilidade deve ser relativamente barsto e répida. O resultado deve informar a decisio de avangar ou no, com uma andlise mais detalhads. 2. Blctagao e andlse de requisitos Esse &.0 processo de derivagio dos reauisitos do sistema por melo da observa- {80 dos sistemas exstentes,além de discussoes com os potenciais usuérios e compradores, anise de tareas, entre outtas tapas Essa parte do processo pode envolver 0 desenvolvimento de um ou mais modelos de sistemas e protétipos, os quai nos ajudam a entender osisterna a ser especticado 3. Especificagdo de requistos. € a atividade de traduzit as informagées obtidas durante 2 aividade de analise em um documento que defina um canjunto de requistos. Dis tipas de requisitas podem ser incluidas nesse documento, Requistos do usuario sio declaragbas abstratas dos requisitos do sistema para cliente e usustio final do sistema, requistos de sistema sSo uma descrigio mais detalhada ds funcionalidade a ser provida 4. A validacao de requistos. Essa atvidade verfica os requistos quanto a realismo, consisténcia e comoletude Durante esse processo, 0s ers no documento de requisitossdo inevitavelmente descobertos Em sequida, 0 documento deve ser modificado ara corregéo desses problemas Naturalmente, as aividades no processo de equistosnéo sdoeitas em apenas uma sequéncia.Aandlse de e- quistos continua durante adefinigao e especiicagao, eneves recuisitos emergem durante 0 process Portarto,as atividades de andlse, defnigao e espectficacio sio intercaladas. Nos métodos ge, como extreme programming, 05 requisites sia desenvolvidos de forma incremental, de acordo com as priavidades do ususro, e aelctagso de reaqusitos 6 eta pelos usuarios que integram equipe de deserwolvimenta 2.2.2 Projeto e implementacao de software O estagio de implementagio do desenvolvimento de software 6 0 processo de conversio de uma especii- cagio do sistema em um sistema executvel, Sempre envolve processos de projeto e programacao de software, mas, se for usada uma abordagem incremental para o desenvolvimento, também pode envoiver 0 refinamento da especificagae do software. Um projeto de software é uma descricdo ds estrutura do software a ser implementado, dos modelos e estrur turas de dados usados pelo sistema, das interfaces entre os companentes do sistema e, 3s vezes, dos algoritmos usados. Os projet’stas no chegam um projato final imediatamente, mas desenvolvem-no de forma iterativa. les acrescentam formaldade e detalhes, enquanto desenvolvem seu projeto por meio de revises constantes para corregio de projetos anteriores. ‘A igura 25 & um modelo abstrato de proceso que mostra as entradas para 0 processo de projeto, suas ative dades e os documentos produzidos como saidas dele. O diagrama sugere que os estégios do processo de projeto so sequenciais. Na realidade, as atividades do processo sao intercaladas, Feedback de um estigio para outro e consequente retrabalno 20 inevitavels em todos os processos ‘Amaiaria das softwares interage com outros sistemas de software, incluindo o sistema aperacional,o banco de dacs, 0 middleware e outros aplicativos. Estes formam a‘plataforma de software! o ambiente em que o software seré executado, Informacdes sore essa plataforma sio entradas essenciais para 0 processo de projeto, pois os projetistas devern deciait a melhor forma de integré-la ao ambiente do software. A espacificacso de requisitos & ma descrigSo de funcionalidade que o software deve oferecer,e seus requisitos de deserspenho e confianga. Se © sistema for para processamento de dados existentes, a descricio desses dados poderia ser incluida na especif- caqdo da plataforma; caso contrétio,a descrigio dos dados deve ser uma entrada para o processo de projeto, para que a arganizagao das dados do sistema seja defini. As atvidades no processo de projeto podem variar, dependendo do tipe de sistema a ser desenvolvido, Por exemplo, sistemas de tempo real demandam projeto de timing, mas poder nao inclulr uma base de dados; nesse 250, n30 hd um projeto de banco de dados envolvido, A Figura 25 mostra quatro atividades que podem ser parte ddo processo de projeto de sistemas de informacao: 1. Projeto de arquitetura, no qual vacé pode identificar a estrutura geral do sistem, os componentes principais {algumas vezes, chamados subsistemas cu médulos), seus relactonamentos e como eles sio distribuicos 2. Projeto de interface, no qual vocé define as interfaces entre os componentes do sistema. Essa espectficagio de interface deve ser inequivoca. Com uma interface precisa, um componente pode ser usado de maneira que26 Engenharia de software FGGAET] Ur od Ends de rote Wwomaie | [Epecnae | [Baia | odes pj tojade |. (Poptede__/Pronode Tolkean (TCT ctotonms Pre de bce eds | ssde ia negtewn | [Epedteriese| [pede | | toechavie outros componentes ndo precisam saber como ele é implementado, Uma ver que as especificagdes de inter face so acordadas, os componentes podem ser projetados e desenvoividos simultaneamente. 3. Projeto de componente, no qual vocé toma cade componente do sistema e projeta seu funcionamento. Pade- -se tratar de uma simples declaragio da uncionalidade que se esgera imolementar, com o projeto espectfica para cada programacor. Pode, também, ser uma ista de alteragGes a serem leitas em um componente reusével ‘uum modelo de projeto detalhaco. O modelo de projeto pade ser usado para gerar automaticamente uma implementacéo. A, Projeto de banco de dados, no qual vocé projeta as estruturas de dados do sistema e como eles devem ser repre- sentados em um banco de dados. Novamente, o trabalho aqui depende da existéncia de um banco de dados a ser reusado ou da criagao de um novo bance de dados. Essas atividades conduzem a um conjunto de saidas do projeto, que também é mostrado na Figura 25.0 de- talhe ea apresentagao de cada uma varia consideravelmente, Para sistemas criticos, devem ser produzidos docu- mentos detalnados de projeto, indicando as descricées precisas e exatas do sistema, Se uma abordagem diigida a modelos é usada, essas saidas poder ser majoritatiamente ciagrarias. Quando os métocos égeis de desenvoly: mento so usados, as saidas do processo de projeto podem nao ser documentos de especificagao separado, mas ser representadas no c6digo do programa, Métodos estruturados para projeto foram desenvolvides nas décadas de 1970 e 1980, e foram os precursores da UML e do projeto orientado a objetos (BUDGEN, 2003}, Eles estdo relacionados com a produsio de modelos agraficos do sistema e, em muitos casos, geram cédigos automaticamente a partirdesses modelos, Desenvolvimen- to ditigide a modelos (MDD, do inglés model-driven development) ou engenharia dirigida a modelos (SCHMIDT, 2006), em que os modelos de software so ciados em diferentes niveis de abstragdo, 6 uma evolucao dos métodos estruturados, Em MDD, hé uma énfase maior nos modelos de argultetura com uma separagao entre os modelos abstratos independentes de implementagao e especicos de implementago, Os modelos sio desenvolvidos em detalhes suficientes para que o sistema executavel possa ser gerado a partir Geles, Discuto essa abordagem para o desenvolvimento no Capitule 5 desenvolvimento de um programa para implementar o sisterna decorre naturalmente dos processos de projeto de sisterna, Apesar de algumas classes de programa, como sistemas crticos de seguranca, serem normal mente projetadas em detalhe antes de se iniciar qualquer implementacao, é mais comum os estdgios posteriores de projeto @ desenvolvimento de programa serem intercalados. Ferramentas de desenvolvimento de softwate podem ser usadas para gerar um esqueleto de um programa a partir do projeto. sso inclulo cédigo para defini e implementar interfaces e, em multos casos, o deservalvedor precisa apenas acrescentar detalhes da operacao de cada componente do programa.Capitulo? Processos de software 27 Programagio & uma atividade pessoal, ndo existe um pracesso geral a ser seguido. Alguns programadores comagam carn companentes que eles compreendem, deservolvem-nos e depois passa para os companentes menos compreendidas. Outros preferem a abordagem opasta, debando para o fim os componentes familiares pois sabem como desenvolvé-los. Alguns deserwalvedores preferem defnir os dados no inicio do process ¢, em seguida, usar essa defini¢ao para digi o desenvolvimento do programa; outros deixam os dados nao especifica- dos durante o maior perioda de tempo possivel Geralmente, os programadores fazem alguns testes do cédigo que esto desenvolvendo, o que, muitas vezes, revela defeitos que devem ser retiados do programa, isso ¢ chamado debugging, Testes de defeltos e debugging sho processos diferentes. Testes estabelecem a existéncia de defeltos; debugging diz respeite &localizacdo e corre- G20 desses defeitos, Quando vocé esta realizando debugging, precisa gerar hipéteses sobre o comportamento observavel do pro- grama e, em seguida, testaressas hipoteses, na esperanca de encontrar um defeito que tenha causado uma saida anormal, 0 teste das hipoteses pade envalver o rastreia manual do cédigo do pragrama, kem cama exigir navos casos de teste para localizacao do problema, Fecramentas interativas de depurac3o, que mastram os valores in- termediarios das varidveis do programa e uma lista das instrugées executadas, podem ser usadas para apciar © processo de depurasio. <2) 2.2.3Validacio de software Validagao de software ou, mais genericamente, verificagao e validagao (V&V), tem a intengao de mostrar que um software se adequa a suas especificagdes ao mesmo tempo que satisfaz as especificagdes do cliente do sistema, Teste de programa, em que o sistema é executado com dados de testes simulados, é a principal ‘técnica de validagao, A validasae também pode envolver processos de verificagao, como inspecGes e revises, em cada estigio do processo de software, desde a definicdo dos requisitas de usuarios até o desenvolvimento do programa, Devido a predominancia dos testes, a maior parte dos custos de validacao incorre durante e apés a implementacao, Com excegao de pequenos programas, sistemas no devem ser testados como uma unidade Gnica e monolit c2.AFigura 26 mostra um processo de teste, de ts estigios, nos quais 0s companentes do sisterna sdo testados, em sequida,o sistema integrado é testado e,finalmente, o sistema & testado com as dados do cliente. idealmente, 05 defeitos de componentes so descobertos no inicio do process, e os problemas de interface so encontrados quando o sistema é integrado. No entanto, quando os defeitos sao descobertos, o programa deve ser cepurado, ¢ iss0 pode requerer que outros estagios do processo de testes sejam repetidos. Eros em comnponentes de progra- ma podem vir & luz durante os testes de sistema. O proceso é, portanto, iterativo, com informagées realimentadas de estagios posteriores para partes anteriores do pracesso, Os estigios do proceso de teste sio: 1. Testes de desenvolvimento. Os componentes do sistema so testados pelas pessoas que o desenvolveram. Cada componente é testado de forma independente, separaco dos outros. Os componentes podem ser entida des simples, como fungGes ou classes de objetos, ou podem ser agrupamentos coerentes dessas entidades. Ferramentas de automagao de teste, como JUnit (MASSOL e HUSTED, 2003), que podem reexecutar testes de componentes quando as novas verses dos componentes so criadas, s30 comnumente usadas. Testes de sistema, Componentes do sistema so integrados para crlar um sistema completo, Esse proceso se preocupa em encontrar os erros resultantes das interacbes Inesperadas entre componentes e problemas de interface do componente, Taribém visa mostrar que o sistema satsfaz seus requisitos funclonais e nao funcio- nals, bern come testar as propriedades emergentes do sistema, Para sistemas de grande porte, esse pode ser 2 Figura2.6 fstsgjos ce testes Texede ( Tenedesistema {Teste de aceltagso componente “ tL28 Engenharia desottware Figura2.7 es de testes de um processo de software drigido a planos Especiicagio Especiicagio speeonie *pecihcace Projeto de sistema = Projetodetahado Pott yt to. Pane de estes Plano de este Céeigo eeste Plano de testes ee teste deiniegragto de ntegragio Uniirioe de acer te sstema, do subsisteme emédle | [4 Teste de ntegragio)\_/Testede integragio Operagio = —— Teste deacetagso) =~ T*E,ge nies ned negra um proceso multiestégios, no qual os componentes sao integrados para formar subsistemas individualmente testados antes de serem integrados para formar o sistema final 3. Testes de aceitagio, Esse € 0 estagio final do processo de testes, antes que o sistema seja aceito para uso opers- ional. O sistema é testado com dadios fornecidos pelo cliente, e ndo com dados advinos de testes simulacos. O teste de aceitagio pode revelar ertos © omissées na definigSo dos requisitos do sistema, pois dados reais exercitam o sistema de formas diferentes dos dads de teste, Os testes de aceitagao também podem revelar problemas de requisites em que os recursos do sistema nao atendam as necessidades do usudrio ou 0 desem- penho do sistema seja inaceitével. Os processos de desenvolvimento de componentes e testes geralmente so intercalados, Os programadores criam seus préprios dados para testes e, incrementalmente, estam o codigo enquanto ele & desenvolvido. Essa é ‘uma abordagem economicamente sensivel, pois 0 programiador conhece 0 componente e, portato, éa melhor pessoa para gerar casos de teste, Se.uma abordagem incremental é usads para o desenvolvimento, cada incremento deve ser testado enauanto 6 desenvolvida — senda que esses testes devem ser baseadas nos requisitos para esse incremento. Em extreme programming, 0s testes sia desenvolvidas paralelamente aos requistos, antes de se iniclar © desenvolvimento, 0 ue ajuda testadores & desenvolvedares a compreender os requistos e garante © cumprimento dos prazos en quanto sao criados os casos de teste Quando um processo de software dirigido a planos 6 usade (por exemplo, para o desenvolvimento de sistemas crticos),o teste € impulsionado por um conjunto de planos de testes. Uma equipe independente de testadores trabalha a partir desses planos de teste pré-formulados, que foram desenvolvidos a partir das especficagées e do projeto de sistema A Figura 27 llustra como os planos de teste so 0 elo entre as atividades de teste e de desen- volvimento. Esse modelo 6, as vezes, chamado modelo V de desenvolvimento (aire a figura de lado para ver 0V) 0 teste de aceitacéo tamioém pode ser chamado ‘teste alf Sistemas sob encomenda sto desenvolvides para ‘um tinica cliente. O proceso de testes-alfa continua até que 0 desenvalvedor do sistema e o cliente concorde que o sistema entrague é uma implementacao aceitével dos requistos. Quando um sistema esté pronto para ser comercializado como um produto de software, costuma-se usar um processo de testes denominado ‘teste beta, Este teste envolue a entrega de um sistema a um numero de potenciais clientes que concordaram em usislo. Eles relatam problemas para os desenvolvedares dos sistemas. 0 produto é exposte para uso real, ¢ eros que podem nao ter side antecipados pelos construtores do sistema s80 detectados, Apbs esse feedback, o sistema & mocificado eliberado para outros testes-beta ou para venda em geral N& 2.2.4 Evolugao do software ‘ATiexbilidade dos sistemas de software é uma das principais razées pelas quais os softwares vém sendo, cada vez mais, incorporados em sistemas grandes e complexos. Uma vez que a decisio pela fabricagao do hardware foi torada, & muito caro fazer alteragSes em seu projeto. Entretanto, as mudangas no software podem ser feitas @ uaiquer momento durante ou apés 0 desenvolvimento do sistema, Mesmo grandes mudangas s80 muito mais baratas do que as correspondentes alteracées no hardware do sistemaCapitulo? Processos de software 29 FARE) Fvolucao do sistema { Definrrequiste®\_/ Avalir sistemas \__ (Propormudengss\__ (Modifica desire nientes esta, ema , ' eaten Nove sera Historicamente, sempre houve uma separagde entre o processo de desenvolvimento ¢ o de evolugao do software (manutengao de software}. As pessoas pensam no desenvolvimento de software como uma atividade criativa em que um sistema ¢ desenvolvico a partir de um conceite inicial até um sistema funcional, Por outro lado, pensar na manutengao do software como magante ¢ desinteressante. Embora os custos de manutensao sejam frequntemente mais altos que os custos inicials de desenvolvimento, os processos de manutengao sso, fem alguns casos, considerados menos desafiadores do que o desenvolvimento do software original Essa distingo entre o desenvolvimento e a manutengio é cada vez mais irelevante. Poucos sistemas de soft- ‘ware sto completamente novos, e faz muito mais sentido ver o desenvolvimento @ a manutencao como proces- 595 continuos. Em vez de dois processos separados, é mais realista pensar na engeniharia de software como um processo evolutivo (Figura 28), no qual o software & constantemente alterado durante seu periodo de vida en resposta &s mudancas de requisitos e 3s necessidades do cliente Z{G23_ Lidando com mudangas ‘Amudanga é inevitével em todos 0s grandes projetos de software. Os requisitos do sistema mudam, ao mesmo tempo que 0 negécio que adquiriu o sistema responde a presses externas e mudam as prioridades de gerencia- mento, Com a disponibilidade de novas tecnologias, emergem novos projetos ¢ possiolidades de implementagio. Portanto, qualquer que seja c modelo do software de process, é essencial que possa acomodar mudancas no software em desenvolvimento. Amudanga aumenta os custos de desenvolvimento de software, porque geralmente significa que o trabalho deve ser refeito. Iso € chamado retrabalho. Por exemplo, se os relacionamentos entre os requisitos do sistema foram analisados e novos requisites foram identificados, alguma ou toda andlise de requisitos deve ser repetida Pode, entio, ser necessério reprojetar o sistema de acordo com os novas requisitos, mudar qualquer programa que tenha sido desenvolvide e testar novamente o sistema, Existem duas abordagens que podem ser adotadas para a redugao de custos de retrabalho: 1. Prevengio de mudangas, em que o processo de software incluiatividades capazes de antecloar as mudangas possivels antes que seja necessério qualquer retrabalho. Por exemolo, um protstipo de sistema pode ser desenvolvido pare mostrar algumas caracteristicas-chave do sistema para os clientes, Eles podem experi- mentar o protétipo e refinar seus requisitos antes de se comprometer com elevados custos de producao de software, 2. Tolerancia a mudangas, em que 0 processo foi projetado para que as mudangas possam ser acomodadas a um custo relativamente baixo. Is0 normalmente envolve alguma forma de desenvolvimento incremental. As alteragdes propostas podem ser aplicadas em incrementos que ainda nao foram deserwolvidos. Se isso for impossivel,entao apenas um incremento (uma pequena parte do sistema) deve ser afterade para incorporar as mudancas Nesta seg, discuto duas maneiras de lidar com mudangas mudangas nos requisites do sistema, So elas: 1. Prototipacio de sistema, em que uma versio do sistema ou de parte dele é deservolvida rapidamente para verificar as necessidades do cliente e a viabilidade de algumas decisbes de projeto. Esse processo previne mudangas, ja que permite aos usuarios experimentarem o sistema antes da entrega e, entdo, efinarem seus requisitos. O nimero de propostas de mudangas de requisits a ser feito apés a entrega é, portanto, suscetivel de ser reduzico,30 Engenharia desottware 2. Entrega incremental, em que incrementos do sistema sio entragues 20s clientes para comentérias @ experi- mentacéo, fssa abordagem di suporte tanto para a prevengéo de mudancas quanto para a tolerancia a mux dangas. Também evita 0 comprometimento prematuro com requisites para todo o sistema © permite que rmudangas sejam incorporadas nas incrementas pastetiores com um custo relativamente baixo. A nogao de refatoracao, ou seja, melhoria da estrutura e organizagao de um programa, também & um impor tante mecanismo que suporta mudangas, Discuto esse assunto no Capitule 3, que abrange métodos eis ), /Projerararqutetura\_, /Deservelverincremento? ée requis aosinerementos éesistema desstema sistema incomplete? Valdar Iegrat Valdarsstema a (lana sistema completo? SistemaEngenharia de software Uma vez que os incrementos do sistema tenham sida identificados, os requistos dos servicos a serem entre- gues no primeira incrementa sio definidos em detalhes,e esse incremento € desenvalvido. Durante o deserwal- vimento, podem ocorrer mais andlises de requisitos para incrementos posteriores, mas mudangas nos requisitos do incrementa atual nio sto aceitas. ‘Quando um incremento & concluido e entregue, os clientes padem colocé-Jo em oneraggo Iso significa ace tara entrega antecipada de uma parte da funcionalidade do sistema, Os clientes podem exnerimentar 6 sistema, 2 1ss0 05 ajuda a compreender suas necessidades para incrementos posteriores. Assim que novos incrementos $80 conclufdos eles s40 integrados aos incrementos existentes para que a funcionalidade de sistema melhore com cada incremente entregue, Aentrega incremental ter uma série de vantagens: (0s clientes podem usar os incrementos iniciais como protétipos e ganhar experiéncla, @ qual informa seus requistos para incrementos posteriores do sistema. Ao contrério de prot6tipos, trata-se, aqui, de partes do sistema real, ou seja,ndo existe a necessidade de reaprencizagem quando o sistema completo esté disgonivel 2. Osclientes nao necessitam esperar até que todo o sistema seja entregue para obter ganhos a partir dele. O pri rmeito increment satisfaz os requistos mais criticas de maneira que eles possar sara software imediatamente 3. 0 process mantém os beneficios do desenvolvimento incremental, o que deve faclitar @ incorporacio das mudangas no sistema, 4. Quanto maior a prioridade dos servigas entregues e, em seguida, increments integrados, os servigas mais importantes recebem a maioria dos testes. Iso significa que a probabilidade de os clientes encontrarem falhas de software nas partes mais importantes do sistema é mencr. No entanto, existem problemas com a entrega increment 1. Amaioria dos sistemas exige um conjunto de recursos basicos, usados por diferentes partes do sistema, Como 1 requisitos ndo s30 definidos em detalhes até que um incremento possa ser implementado, pode ser cific identificar recursos comuns, necessérios a todos os incrementos, 2. O desenvolvimento iterativo também pode ser dificil quando um sistema substituto esta sendo desenvalvido. Usuarios querem toda 2 funcionalidade do sistema antigo e, muita vezes, cam relutantes em experimentat lum novo sistema incomplato, Portanto, é dificil obter feedbacks iteis dos clientes, 3. Aesséncia do proceso iterativo ¢ a especificagao ser desenvolvida em conjunto com o software, Is0, contue do, causa conflites com o modelo de compras de muitas organizagdes, em que a especificacao completa do sistema 6 parte do contrato de desenvolvimento do sistema. Na abordagem incremental, ndo ha especticagao completa do sistema até que o timo incremento seja especificado, o que requer uma nova forma de contrato, a qual os grandes clientes, come agéncias governamentals, podem achar dificil de se adapiar Existem alguns tioos de sistema para os quais o desenvolvimento e 2 entrega incrementals néo so a melhor abordagem. Esses sistemas s0 muito grandes, de modo que o desenvolvimento pode envolver equipes traba- Ihando em locais diferentes, além de alguns sistemas embutidos, em que o software depende do desenvolvi- mento de hardware, ede alguns sistemas crticos, em que todos os requisitos devem ser analisados na busca por interag6es capazes de comprometer 2 protesso ou 2 seguranca do sistema, Tals sistemas, naturalmente, softem com os mesmos problemas de requisitos incertos e mutévels, Portanto, para resolver esses problemas ¢ obter alguns dos beneficios do desenvolvimento incremental, pode ser usado um processo no qual um protétipo de sistema é desenvolvido de forma iterativa e usado como uma plataforma para experimentos com os requisitos e projeto do sistema. Com a experiéncla adquitida a partir do protétino, requisites defintivos podem ser, entdo, acordados, 2.3.3 Modelo espiral de Boehm Um framework de pracesso de software dirigido a rscos (o madelo em espiral (oi proposto por Boehm (1988) Isso esténa Figura 2.11. Aqui, o processo de software é representado como ume espiral,e no como uma sequén- cia de atividades com alguns retornos de uma para outra. Cada volta na espiral representa uma fase do processo de software. Dessa forma, a volta mais interna pode preocupar-se com a viabilidade do sistema o ciclo seguinte, com definigdo de requisites; 0 seguinte, com o projeto do sistema, ¢ assim por diante. O modelo em espiral combina prevencéo e tolerancia a mudancas, assume que mudancas sto um resultado de riscos de projeto e incluiativida- des explicitas de gerenciamento de riscos para sua redugéo.Capitulo? Processos de software 3B Figura2.11 mn espi Determinarebjetves, sites eretigoer vai stern, danas resolver nos nae dericoe Ande senicos Anse dericoe Protstipo Protdtipe 3 opera Protéine? nile, deracos Pt ewsho pet Simuloies, modelos, benchmark Pano derequistor | Concetode Panadecdaderiia | 9630 “Aequitas ‘sesi | / Projtode prodto Pret Fianode | lesa salad eserviento | derecustos casio Teste unin Pane deintegngio seneae Aone préxia se eres Fanwce MOORES 3.879580 Desenvlvereverficarpréome nivel de produce operas (Cada volta da espiral é dvidida em quatto setores: 1. Defnigdo de objetivas. Objetivos especticos para essa fase do projeto sio definidas; restricdes a0 processo e 120 produto sio identificadas, e um plano de gerenciamento detalhado € elaborado; os riscos do projeto so identificados. Podem ser planejadas estratégias alternativas em fungia desses riscos 2. Avaliagao ¢ redugdo de rscos. Para cada um dos riscos identificados do projeto, é feta uma analise detalhada, ‘Medidas para redusao do rsco séo tomadas. Por exemplo, se houver rsco de os requisitos serem inadequados, um proiétipe de sistema pode ser desenvolvida 3. Desenvalvimenta evalidagdo. Apés a avaiacio dos r'scos, éselecionado um modelo de desenvolvimento parao sistema, Por exemplo, a prototipacio descartavel pode ser a melhor abordagem de desenvalvimenta de inter- face de usuétio se 0s riscos forem dominantes. Se 0s riscos de seguranca forem a principal consideracao, o de- senvalvimento baseado em transformacdes formals pode ser o processo mais adequado, ¢ assim por ciante. Se «© principal risco identificado for a integragao de subsisternas, o modelo em cascata pode sera melhor apeao. 4, Plangjamento. 0 projeto & revisado, © uma decisio & tomada a respeito da continuidade do modelo com mais uma volta da espiral Caso se decide pela continuidade, planos sao elaboradios para a proxima fase do projeto. A principal diferenca entre o modelo espiral e cutras modelos de pracesso de software é seu recanhecimento explicito do isco, Um ciclo da espiral comega com a defini¢ao de abjetivos, como desempenho e funcionalidade. Em seguida, sio enumeradss formas alternativas de atingit tals objetivas e de lidar com as vestiges de cada um deles. Cada alternativa é avaliads em funcio de cada abjetivo, eas fortes de risco do projeto sia identifcadas. O ppréximo passo € resalver esses riscos por meio de atividades de coleta de informacées, coma analise mais deta- Ihada, protetipagao e simulagao. |Apés aavaliacio dos riscos, algum desenvolvimento é efetivado, seguido por uma atividade de planejamento para a préxima fase do rocesso, De maneira informal dizemos que o rsco significa, simplesmente, algo que pode dar errado. Por exemplo, se 2 intengSo & usar uma nova linguagem de programacao, um risco é o de os complla- dores disponivels nao serem confiéveis ou no produzirem um cédigo-objeto eficiente o bastante. Riscos leva a mudangas no software e problemas de projeto, como estoure de prazos e custos. Assim, o gerenciamento de riscos 6 uma atividade muito importante do projeto, consttuindo uma das partes essencials do gerenciamento de projetos, e seré abordado no Capitulo 2234 Engenharia desoftware %G@2A_ Rational Unified Process (RUP) (0 Rational Unified Process — RUP (KRUTCHEN, 2003) € um exerplo de madelo de processo maderno, der- vado de trabalhos sobre a UML ¢ o Unified Software Development Process associado (RUMBAUGH, et al, 1999; ARLOW e NEUSTADT, 2005}. ncluf uma descrigdo aqui, pois é um bom exernplo de processo hibrido. Ele retine ele- mentos de todos os modelos de pracesso genéricos (Segao 2 1), ilustra boas préticas na especificagio e no projeto (Segao 22) e apoia a prototipagdo e a entrega incremental (Segi0 23) (0 RUP reconhece que os modelos de proceso convencionais apresentam uma visso Unica do proceso, Em Ccontrapartida, o RUP 6 normalmente descrito em t8s perspectivas: 1, Uma perspective dindmica, que mostra 2s fases do modelo ao longo do tempo. 2. Uma perspectiva estética, que mostra as atlvidades relizadas no processo, 3. Uma perspectiva prética, que sugere boas praticas a serem usadas durante 0 processo. ‘A maioria das descrigdes do RUP tenta combinar as perspectivas estatica e dindmica em um Gnico diagrama (KRUTCHEN, 2003}. Por achar que essa tentativa torna o proceso mais diffi de ser compreendido, uso descrigGes separadas de cada perspectiva © RUP € um madela constituido de fases que identifica quatro fases distintas no processa de software. No tentanto, a0 contrario do modelo em cascata, no qual as fases sao equalizadas com as atividades do processo, as fases do RUP sio estreitamente relacionadas 20 negécio, endo a assuntos técnicas. A Figura 2.12 mostra as fases do RUP Si elas: 1. Concepgdo.O objetivo da fase de concencao é estabelecer um business case para o sistema, Voc® deve identi- ficat todas as entidades externas (pessoas e sistemas) que vao interagir com o sistema e definit as interacées. Entéo, vocé deve usar essas informacdes para avaliar a contribuigSo do sistema para o negécio, Se essa contr= bbuigao for pequena, entée o projeto poderd ser cancelado depois dessa fase. 2. laboragdo. As metas da fase de elaborasio séo desenvolver uma compreensia do problema dominante, es- tabelecer um framework da arquitetura para a sstema, desenvolver o plano do projeto e idertificar os maiores riscos do projeto. No fim dessa fase, vocé deve ter um modelo de requisitos para o sistema, que pode ser um conjunto de casos de uso da UML, uma descri¢o da arquitetura ou um plano de desenvalvimento do software 3. Construgdo. A fase de construcéo envolve projeto, pragramagio e testes do sistema. Durante essa fase, as partes do sistema so desenvolvidas em paralelo e integradas, Na concluséo dessa fase, vocé deve ter um sistema de software jé funcionando, bem como a documentacéo associada pronta para ser entregue aos usuarios ‘4. Transigdo. A fase final do RUP implica ransferéncia do sistema da comunidade de desenvolvimento para a co- rmunidade de usuarios e em seu funcionamente em um ambiente real. 50 6 ignorado na maioria cos madelos de processo de software, mas 6, de fato, uma atividade cara e, 8s vezes, problemstica, Na conclusdo dessa fase, vvocé deve ter um sistema de software documentado e funcionando corretamente em seu ambiente opera ional. No RUF, a iteragao é apoiada de duas maneiras. Cada fase pode ser executada de forma terativa com os resuk tados desenvolvides de forma incremental Além disso, todo 0 conjunto de fases também pode ser executado de forma incremental, como indicado pela seta curva de"transigéo'para concepgio, na Figura 2.12, A visio estitica do RUP prioriza as atividades que ocorrem durante 0 processo de desenvolvimento. Na des- crigio do RUP.essas si chamadas workflows, Existem seis workflows centrais, identificadas no proceso, @ 1185 workflows de apoio. © RUP foi projetado em conjunto com a UML, assim, a descricao do workflow é orientada em Figura2.120 = Unified Process 0 Rat Reragio de fase CO a [SS Concepsie _flaboragie Constrio TransigieCapitulo? Processos de software 35 tomo de modelos associadas & UML, como modelos de sequéncia, modelos de objatos etc. Os workflows centrals de engenhatia e de apoio esto descrtos na Tabela 2.1 Avantagem de proporcionar visbes estaticas e dinamicas & que as fases do processo de desenvolvimento nao esto associadas a workflows especificos. Ac menos em principio, todos os workflows do RUP podem estar ativos em todas as fases do processo. Nas fases inicals, pravavelmente, maiores esforgos serdo empenhados em workfl ws, como modelagem de negdcios e requisitos, e,nas fases posteriores, no teste e na implantagao. A perspectiva prtica sobre o RUP descreve as boas préticas da engenharia de software que sdo recomendadas para uso no desenvolvimento de sistemas. Seis boas praticas fundamentals sao recomendadas 1. Desenvolver software terativamente, Planejar os incrementos do sistema com base nas prioridades do cliente desenvolver 0s recursos de alta prioridade no inicio do processo de desenvolvimento. 2. Getenciar os requisites. Documentar explicitamente os requisitos do cliente e acompanhar suas mudangas, Ana- lisar o impacto das mudancas no sistema antes de aceité-as. 3. Usar arquiteturas baseadas em companentes, Esttuturar @ arquitetura do sistema em componentes, conforme discutide anteriormente neste capitulo. 4. Modelaro software visualmente. Usar modelos graficos da UML para apresentar visbes estaticas e dindmicas do software 5. Verfcar a qualidade do software. Assequtar que o software atenda aos padrées de qualidade organizacional 6. Controlaras mudangas do software. Gerenciar as mudangas do software, usando um sistema de gerenciamento dle mudangas e procedimentos e ferramentas de gerenciamente de configuragao ‘ORUP ndo é um processo adequado para todos 0s tipos de desenvolvimento, como, por exemplo, desenvol- vvimento de software emibutido, No entanto, ele representa uma abordagem que potencialmente combina os trés modelos de processo genéricos discutidos na Segao 2.1. As inovacdes mais importantes do RUP so a separagio de fases © workflows e 0 reconhecimento de que a implantacao de software em um ambiente do usudri & parte do processo. As fases sio dindmicas e tém metas. Os workflows sia estiticos e sao atividades técnicas que no sto associadas a uma tinica fase, mas podem ser utlizadas durante toda o desenvolvimento para alcangar as metas espacificas Fabel A) Workows estiticos no Rational Unified WORKFLOW DESCRIGAO Modelagem de negécios (0s processas de negci ste modelados por meio de casos de uso de egos Reguistos ‘ores ue interager come sistemas Wenticadese casos de uso sto desenvolvdos para medelar os requistos do sistema, Andlseepojeto Um modelo de projera & cade edocurmentado com models de arquiteura,madeles de components, radels de abetose modelos de sequénce Implementacio (0s components do sntera so imlerentadoseestruturados em subsstemas de implementasao. 8 (eragdoautomstica de céaigo 2 part de modelos de projet ajude 2 acelerar este proceso, Teste (teste & um pracesso iteratvo que é fet em conjunto com aimmplementagdo Oeste do sistema segue a conclusio daiplernenracio. Impiantacéo Um release do produto é rad, istbuido aos ususrios instalado em seulocal derabaho, Gerencaments: de configuacio e | tse workfiow de apoio gerenciaas mudangas do sbtema (ja 9 Capitulo 25), mudangas Gerenciamento de aaj Esse workflow de apoio gerenciao desenvolvimento do sitema (ej 0 captuls 2223) Meio ambiente Esse workfow estérelacionado com a diponibilzacio de feramentas apropriadas para a equipe de esenvolvmenta de satnareEngenharia de software \<&PONTOS IMPORTANTES << Os processos de software sio as atividades envolvidas na producio de um sistema de software. Modelos de processos de software sio representacées abstratas desses processos, Modelos gerais de processo descrevem a organizagio dos processos de software. Exemplos desses modelos gerais incluer 0 modelo em cascata, o desenvolvimento incremental e o desenvolvimento orientado a reiso. Engenharia de requisitos ¢ 0 processo de desenvolvimento de uma especticacao de software. As especiicacées destinam-se a comunicar as necessidades de sistema dos clientes para os desenvolwedores do sistema Processos de projeto e implementacao esto relacionados com a transformacio das especifcagées dos requ sitos em um sistema de software execulével. Métodos sistematicos de projeto podem ser usados como parte dessa transformacéo. Validacao de software 6 0 processe de verificagao de que o sistema esti de acordo com sua especificagao & satisfaz as necessidades reals dos usuarios do sistema Evolugio de software ocorre quando se alteram os atuais sistemas de software para atender aos novos requis tos. As mudangas sao continuas, e 0 software deve evoluir para continuar Gt Processos devem inclulr atividades para lidar com as mudancas, Pedem envolver uma fase de prototipacao, que ajuda a evitar mas decisdes sobre os requisitos e projeto, Pracessos podem ser estruturados para o desen- volvimento e a entrega iterativos, de forma que mudangas possam ser feitas sem afetar 0 sistema como um todo. 0 Rational Unified Process (RU) é um modem modelo genérico de processo, organizado em fases (concep- 20, elaboragao, consirugao e transigac), mas que separa as atividacies (requisitos, anise, projeto etc) dessas fases. <_ LEITURA COMPLEMENTAR <= Managing Software Quality and Business Rsk Esse 6 essenclalmente um livre sobre gerenciamento de software, ‘mas que inclui um excelente capitulo (Capitulo 4) sobre os modelos de proceso, (OULD, M. Managing Software (Quality and Business Risk John Wiley ane Sons Ltd, 1999) “Process Models in Software Engineering’ Essa é ums excelente visio geral de uma vasta gama de modelos de processo de engenharia de software que tém sido propostos. (SCACCH|, W. “Process Madels in Software Enginee- ring’ In: MARCINIAK, J. (Orgs). Encyclopaedia of Software Engineering. John Wiley and Sons, 2001.) Disponivel em: <. The Rational Unified Process — An Introduction (3° Edition). Esse &o livre sobre RUP mais lide no momento, Krux chen descreve bem o processo, mas eu gostarla de te lido mais sobre as difculdades priticas do uso do processo, (KRUTCHEN, P The Rational Unified Process -An Introduction, ed, Addison-Wesley, 2003) eo RERCICIOS 2.1. _Justficando sua resposta com base no tipo de sistema a ser desenvolvido, sugira © modelo genérico de processo de software mais adequado pars ser usado como base para a geréncia do desenvolvimento dos sistemas a seguir Um sistema para controlar o antibloqueio de frenagem de um carro. Um sistema de realidade virtual para dar apoio & manutengao de software Um sistema de contabilidade para uma universidade, que substitua um sistema jé existente Um sistema interat'vo de planejamento de viagens que ajude os usuarios a planejar viagens com menor impacto ambiental.Capitulo? Processos de software 37 2.2 Explique por que o desenvolvimento incremental é 0 métado mais eficaz para o desenvolvimento de siste- mas de software de nagécios. Par que esse modelo & menos adequado para a enganharia de sistemas de tempo real? 2.3 Considere o modelo de processo baseado em retiso da Figura 23 Explique por que, nesse processo, & es- sencial ter duas atividades dlstintas de engenharia de requisitos, 2.4 Sugira por que é importante, no processa de engenharia de requisitas, fazer uma distingZo entre desenvol- vimenta dos requisites da usuario e desenvolvimento de requisites de sistema, 2.5 Descreva as principais atividades do processo de projeto de software e as saidas dessas atividades. Usando lum diagrama, mostre as possives relagdes entre as saidas dessas atividades, 2.6 Explique por que, em sistemas complexos, as mudansas sio inevitiveis. Exemplifique as atvidades de pro~ ccesso de sofware que ajudam a prever as mudangas e fazer com que o software seja desenvolvido mais tolerante a mudangas (desconsidere prototipagao e entrega incremental) 2.7 Expligue por que os sistemas desenvolvides como protétipos normalmente ndo dever ser usados como sistemas de produgéo. 2.8 Explique por que o medelo em espiral de Bochm é um modelo adaptavel, que apoia tanto as atividades de prevensao de mudangas quanto as de tolerdncia a mudancas. Na pratica, esse modelo nao tem side ampla- mente usaco Sugira as possive's razbes para iss. 2.9 Quais sdo as vantagens de proporcionar visGes estéticas e dindmicas do processo de software, assim como no Rational Unified Process? 2.10 Historicamente, a introdusao de tecnologia provocou mudangas profundas no mercado de trabalhe e, pelo menos temporariamente, deixou muitas pessoas desempregadas. Discuta se a inirocugao da automacdo ‘extensiva em processos pode vir a ter as mesmas consequéncias para os engenheiros de software. Se sua resposta for nao, justiique, Se vocé acha que sim, que val reduzir as oportunidades de emprego, & resisténcia passiva ou ativa, pelos engenheiros afetados, &introdugao dessa tecnologia? <2) REFERENCIAS. <= ARLOW, J; NEUSTADT, |, UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design. 2d, Boston: ‘Addison-Wesley, 2005 BOEHM, B; TURNER, R Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley, 2003, BOEHM, &.W."A Spiral Model of Software Development and Enhancement’ IFEEComputer,¥.21,0.5, 1988, p.61-72. BUDGEN, D. Software Design, 2ed, Harlow, Reino Unido: Addison-Wesley, 2003, KRUTCHEN, P. The Rational Unified Process — An Introduction, Reading, MA: Addison-Wesley, 2003, MASSOL, V; HUSTED, T.JUnitin Action. Greenwich, Conn. Manning Publications Co, 2003. RETTIG, M.Practical Programmer: Prototyping for Tiny Fingers’ Comm. ACM, v.37, 9.4, 1994, 9. 21-7. ROYCE, W.W. "Managing the Development of Large Software Systems: Concepts and Techniques! (EEE WESTCON. Los Angeles, CA, 1970, p. 1-9, RUMBAUGH, J; JACOBSON, |; BOOCH, G.The Unified Software Development Process. Reading, Mass: Addison-Wesley, 1999, SCHMIDT, D.C.“Mede!-Driven Engineering! IEEE Computer, v.29, n.2, 2006, p. 25-31 SCHNEIDER, S. The 8 Method, Houndmills, Reino Unido: Palgrave Macmillan, 2001 WORDSWORTH, J. Software Engineering with 8. Wokingham: Addison-Wesley, 1996.