Capitulo 2 - O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE Topicos = Introducao " Processos e Metodologias * Modelos e Modelagio = Boas Praticas no Desenvolvimento de Software = Fases do Processo de Desenvolvimento de Software = Processos de Desenvolvimento de Software = Conclusio = Exercicios 2.1 Introdugao A produgio de software é frequentemente uma actividade no estruturada, por vezes cadtica, sem otientagdes de natureza estratégica e sem planos de gestiio controlo. Assim se justifica a denominacgio build and fix (programar e cortigir). Como yimos no primeiro capitulo, os problemas associados ao desenvolvimento de software sio de tal dimensio que é fundamental a definicio e aplicacio de princfpios, regras e estratégias que conduzam a melhorias significativas em todo o desenvolvimento de software. Estes principios deverio nortear sempre a interven- cio do informatico na implementagao de sis temas de informacio. Em qualquer desenvolvimento de sistemas de informacio é necessétio definir a intervencio e conjugar correctamente as interaccdes entre as pessoas, 0 processo aplicado, as caracteristicas do produto e 0 projecto que orienta as actividades a desenvolver. I 0 que Roger Pressman apelida dos “quatro P's” associados ao24 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | desenvolvimento de software [Pressman00]. $6 pessoas (informiticos, gestores ¢ utilizadores) motivadas ¢ comprometidas com 0 projecto garantem o respectivo sucesso; 86 um processo com técnicas ¢ regras bem definidas permite atingir os objectives proposto 86 compreendendo as necessidades reais dos utilizadores se pode produzir um produto de qualidade; s6 com um projecto credivel ¢ controlado é possivel cumprir ptazos ¢ custos propostos. Independentemente do método utilizado, estas deverio set sempre preocupagdes comuns a todas as imple- mentages de software. m 1996, Barry Boehm identificou sete questdes que qualquer projecto de siste- mas de informagao devera responder [Boehm96], ¢ que sio frequentemente agru- padas no que se designou pelo principio W5H. * Porque é que o sistema vai ser desenvolvido (Wy)? * O que vai / deve ser feito (Wai)? * Quando é que vai ser feito (IP/hen)? ssponsivel (Who)? " Quem éor "Onde € que as responsabilidades estio localizadas (IVbere)? * Como € que vai set feito (How)? * Quanto vai custar em termos de recursos (How mud)? Neste capitulo procuramos apresentar um coajunto de definigdes formais relacionadas com 0 desenvolvimento de software, cuja compreensio é funda- mental, ¢ sio descritas em detalhe as actividades cuja realizacio, de um ponto de vista genético, € expectivel ao longo de todo o periodo que vai desde a identificacio de uma necessidade de um utilizador até A produgo do software que sera a solucio. Gostarfamos desde ji chamar a atencio do leitor para o facto da definicio de virios dos conceitos apresentados nao ser consensual. As definigdes apresentadas reflectem a nossa visio, que tem a preocupacio de ser coerente e consistente, se basear em conhecimentos s6lidos sustentados pela experiéncia pritica, para além de procurar estar alinhada com a opinigio da maiotia dos autores de referéncia na rea de Engenharia de Software. 2.2 Processos e Metodologias Quando se fala do desenvolvimento de software, sio frequentemente aplicadas exptessOes diferentes, mas que muitas vezes representam a mesma ideia. Fi por isso fundamental a clatificagio de alguns conceitos basicos adoptados neste livro, que se encontram, em geral, associados as areas cientifica/tecnologica de “sistemas deConceito Conceito Conceito CarituLo 2 - O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 25 informacio” e de “engenharia de software”. Estes conceito: de natureza técnica, sio frequentemente mal entendidos e/ou mal aplicados. Estamos sobretudo a referir-nos aos conceitos de proceso, metodologia ¢ ciclo de vida. O processo de desenvolvimento de software é um conceito de ambito muito vasto, ¢ pretende designar uma sequéncia de actividades, normalmente agrupadas em fases € tarefas, que sio executadas de forma sistematica ¢ uniformizada, que silo realizadas por intervenientes com responsabilidades bem definidas, ¢ que a partir de um conjunto de entradas produzem um conjunto de saidas. Um processo de desenvolvimento de software pretende, segundo Booch, atingir quatro objec- tivos fundamentais [Booch94]: * Providenciar orientacio sobre a sequéncia de realizagiio das actividades envol- vidas. = Especificar os modelos descritivos do sistema que devem ser desenvolvidos. " Dirigir as tarefas dos participantes ¢ da equipa como um todo. = Providenciar critérios para monitorizacio e avaliacio dos modelos e activida- des do projecto. Nesta perspectiva, o conceito de metodologia, para além da sequéncia de etapas ¢ procedimentos recomendados para serem aplicados durante 0 processo de desenvolvimento de sistemas de informacao (ou seja, uma metodologia pressupse a existéncia de um processo), acrescenta a esta definigao a utilizacio de um conjunto de ferramentas, técnicas ¢ notacées [Booch94]. Para além disso, € normal que inclua ainda referéncias a diversos principios ¢ regras cujo objectivo é concre- tizar na pritica as orientagdes mais tedricas que sao expressas no conceito de processo, e nas quais podemos incluir: = Regras de elaboragio de estimativas (custos, prazos). "Técnicas para efectuar medigdes. = Procedimentos a seguir de forma a garantir a qualidade. = Programas de formacio. = Modelos da documentagio a produzir, vulgarmente designados por emplates. = Exemplos priticos detalhados. " ‘Técnicas para configuragio da metodologia, que poderdo ser aplicadas de modo a possibilitar a sua adaptaco a realidades especfficas. De acordo com estas definigdes de proceso e metodologia, 0 conceito de ciclo de vida pode ser encarado como um sinénimo de processo. A expressiio ciclo de vida é mais antiga, aparecendo normalmente associada as abordagens tradicionais, enquanto © termo processo aparece sobretudo no contexto das abordagens mais26 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | recentes (ver discussio sobre o tema no Capitulo 3). Gostariamos aqui de realgar mais uma vez que estes trés termos sio muitas vezes utilizados indistintamente, com o significado que nés atribuimos ao conceito metodologia (o mais abrangente de todos). Sobretudo no caso das abordagens que se baseiam no paradigma da otientagio por objectos (c em particular aquelas que utilizam UML pata a modelacio), © conceito mais utilizado é 0 de processo. xemplos disso sio o RUP (Rational Unified Process) ¢ 0 ICONIX, ambos apresentados no segundo volume deste livro, ¢ que se definem como processos, mas que segundo a definicio por nds apresentada deverio. ser considerados metodologias. Aliés, € curioso verificar que segundo Philippe Kruchten, um processo de desenvolvimento de software é “um conjunto de passos parcialmente otdenados concebidos de forma a atingir um objective, que no caso da engenharia de software, é o de construir ou alterar um produto de software” [Krutchen00]. Como se vé nfo faz qualquer referéncia a técnicas de modelagio ou ferramentas utilizadas, e que no entanto sio descritas no ambito do RUP, do qual é um dos principais mentores. A preocupacio com a utilizacao de abordagens sistematicas foi talvez levada longe demais. Por exemplo, em meados da década 90 estimava-se que existiam mais de 1.000 metodologias de desenvolvimento de sistemas de informagio a serem utilizadas em todo o mundo [Jayaratna94]. Este mimero clevado nao sé dificulta a selecgo aplicacio sistematica de uma metodologia, como é muitas vezes apontado como uma das tazdes por nao alcancar o objective de uniformizacio (como ha muitas normas, na pratica nao é adoptada nenhumal). As _metodologias actualmente existent tiveram essencialmente duas otigens distintas: (1) um primeiro grupo inclui que evoluitam de experiéncias priticas, sobretudo das grandes consultoras de sistemas de informacio, baseiam-se na aplicagio de diversas técnicas, © normalmente detam origem a produtos comerciais; (2) um segundo grupo inclui aquelas que resultaram de esforcos de investigacio em universidades € que sto frequentemente supottadas pot conceitos te6ticos muito préximos da matemitica; por vezes, apenas se encontram descritas em livros e no sfio suportadas por ferramentas. As metodologias sio por natureza de ambito geral, isto é, pretendem ser aplicadas em diferentes tipos de projectos, em diferentes indiistrias e em varias organizacdes. Muitas das metodologias sio relativamente rigidas, pois baseiam-se numa filosofia de desenvolvimento tinica com normas, técnicas € procedimentos uniformes, sem qualquer possibilidade de proceder a alteraces ou configuragées estruturais & propria metodologia. Para ultrapassar este problema houve organizacéiesConceito Conceito CapiTuLo 2—O PROcESSO DE DESENVOLVIMENTO DE SOFTWARE 27 (sobretudo as mais ligadas a industria de desenvolvimento de software) que criaram competéncias em diversas metodologias, de modo a poderem seleccionar a mais adequada para cada projecto concreto. Idealmente, as abordagens metodologicas deveriam ser flexiveis, de modo a permitirem a seleceo de caminhos alternativos dentro de uma metodologia ou mesmo a configuracio ou adaptagéo da propria metodologia. 2.3 Modelos e Modelagao Um modelo consiste na interpretagio de um dado dominio do problema (fragmento do mundo real sobre 0 qual as tarefas de modelacio ¢ construgio do sistema de informacao incidem) segundo uma determinada estrutura de conceitos. Como exemplos de modelos podemos citar 0 modelo que resulta da anilise de temas e o modelo de implementagao. Um esquema é a especificacio de um modelo usando uma determinada linguagem, a qual pode ser formal ou informal (por exemplo, linguagem natural), textual ou grafica. Quando a representagio do esquema é grafica, designa-se usualmente por diagrama. Como exemplos de esquemas ¢ de diagramas temos o esquema relacional do modelo de dados de um sistema de crédito bancétio ou 0 diagrama de classes de um sistema de facturacio. Um modelo é sempre uma interpretacio simplificada da realidade. A ciéncia em geral, e a engenharia em particular, procurou desde sempre representat a “sua realidade” através de modelos mais ou menos correctos, mais ou menos abrangentes, mais ou menos detalhados. A ideia geral é que é preferivel um mau modelo que nenhum modelo na descrigio de qualquer sistema. Outro aspecto relacionado € que um modelo apresenta apenas uma visio ou cenario de um fragmento do mundo real. por conseguinte necessario a producio de varios modelos de forma a melhor representar e compreender o sistema correspondent. Por exemplo, a construgio de uma obra de engenharia civil apresenta intimeros modelos, cada qual correspondendo a uma interpretagao ou visio da mesma “realidade”. As plantas, os algados, as perspectivas ortogonais, as maquetas, o desenho da rede cléctrica, da rede de esgotos, da rede de agua, da estrutura de betio, sao diferentes representagdes ou modelos da mesma realidade. A Figura 2.1 ilustra dois modelos complementares para uma mesma realidad perspectiva (no lado esquerdo) ¢ um alcado frontal (lado diseito da figura) da casa. maConceito 28 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | Figura 2.1: Diferentes modelos de uma mesma casa 2.3.1 Importancia da Modelagao A modelagio (ou modelizagao) é a arte ¢ ciéncia de criar modelos de uma determinada realidade. Hi uma técnica bem aceite e adoptada pela generalidade das disciplinas de engenharia conhecidas. Permite a partilha de conhecimento entre diferentes grupos de intervenientes (técnicos e niio técnicos), facilita e promove a comunicagio entre todos. Facilita a gestio mais eficaz e eficiente das equipas de Projecto, ao dar uma visio mais adequada sobre os varios produtos a descnvolver, € permite ainda que as previsées de custos © prazos sejam efectuadas segundo critérios mais realistas 0 que também contribui para a minimizagio dos tiscos associados. A engenhatia informatica, embora sendo uma engenharia significativamente mais Fecente que a engenharia civil, necessita jgualmente de adoptar notagdes ¢ lingua- gens de representacio dos seus modelos. Tal como nas restantes engenharias, também na engenharia informatica se conseguem obter beneficios através da modelacio, que segundo [Booch99] incluem os sepuintes: Os modelos ajudam a visualizar um sistema, quer seja a sua situagio no pas- sado, no presente ou no futuro, * Os modelos permitem especificar a estrututa ou o comportamento de um tema, Os modelos permitem controlar ¢ guiar 0 processo de construcio do sistema. = Os modelos documentam as decis6es tomadas.CapfTuLo 2 - O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 29 2.3.2 Principios da Modelagao ‘A experiéncia adquirida na actividade de modelagio sugete que, independente- mente do projecto, se verificam sempre um conjunto de quatro principios basicos [Booch99]. P1: A escolha dos modelos a criar tem uma profunda influéncia no modo como 0 problema é encarado e consequentemente como a solugao é obtida. Isto significa que um modelo adequado (em termos de expressividade, abstraccio ou abrangéncia) ilustrara de forma correcta determinados aspectos da consttugio de um sistema, oferecendo aos intervenientes no proceso uma clatificacio € simplificacio dos mesmos. Por outro lado, um modelo inadequado ter como con- sequéncia uma inerente confusio ¢ dificuldade de compreensio e comunicacao. P2: Cada modelo deve poder ser expresso em diferentes niveis de precis’io/abstraccio. © grau de detalhe que um modelo deve apresentar esti dependente do perfil do interveniente no projecto. Por exemplo, para o utilizador ou cliente de um sistema, apenas deveri ser relevante a perspectiva de utilizagio. Por outro lado, oa perspectiva do analista ¢ do programador do sistema, jé ser relevante a especifica- do de como é que o sistema devera ser implementado. Por exemplo, se o sistema a considetar for um comando da televisio, 0 modelo para o utilizador final sera uma descrigio da sua utilizagao, enquanto que para 0 técnico, o modelo devera especificar as mensagens trocadas entre diferentes aparelhos, tempos de atraso para garantir a boa recepeao das mensagens, etc. P3: Os melhores modelos reflectem a realidade. Este principio é um dos conhecidos “calcanhares de Aquiles” de algumas técnicas leu de modelacio, em que existe uma manifesta separagdo entre os modelos utilizados » gq " pata desctever “o que o sistema faz” ¢ outros que detalham a forma “como 0 sistema faz”. E importante corrigir este problema, porque tal separacio permite que a visio do sistema concebido ¢ a visio do si ema implementado possam divergir significativamente. P4: Nenhum modelo é suficiente por si s6. Qualquer sistema nio-trivial € representado de forma mais adequada através de um pequeno niimero de modelos, razoavelmente independentes. Tal como em engenharia civil, em que um prédio é representado pot varios modelos complementares, também na engenharia de software ocorrem situagdes semelhantes. Na Parte 2 deste livro veremos que o UML se baseia significativa- mente neste principio, a0 propor varias notacdes para a produgio de diferentes30 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE ~ VoL. | tipos de modelos. Note-se que o “‘razoavelmente independentes” significa que os modelos devem poder ser construidos de forma mais ou menos independente (até mesmo em paralelo), mas que deverao manter algum nivel de integracio, estilo, consisténcia € coesio entre si. E. preciso nfio esquecer que o sistema objecto de modelacio ¢ comum a todos os modelos. 2.4 Boas Praticas no Desenvolvimento de Software A complexidade é uma caracteristica inerente ao software. $6 um numero muito reduzido de sistemas e tendo em conta o seu ambito, niimero de pessoas afectadas ou criticidade da informagio nfo apresenta esta caracteristica, ou tem um nivel de complexidade reduzido (um bom exemplo disso é um sistema de gestio de contactos pessoais). Tal deve-se ao facto de, como Brooks sugeriu no seu famoso artigo No Silver Bulle [Brooks86], a complexidade do software é uma propriedade essencial, intrinseca 4 prépria natureza do software, e nao acidental, que ocorra espotadicamente. Segundo Booch [Booch94], esta complexidade tem otigem em quatro factores: * A complexidade do dominio do problema. " A dificuldade de gerir 0 processo de desenvolvimento. = A flexibilidade que é possivel (ou nao) implementat através de software. + Os problemas de caracterizacdio do comportamento de sistemas discretos. A incapacidade de controlar esta complexidade do software tem conduzido a projectos que ultrapassam os custos, os prazos ¢ que no respeitam os tequisitos definidos, tal como discutido no Capitulo 1. Courtois identificou varios atributos de um sistema complexo [Courtois85]: = Um sistema complexo é composto por outros sub-sistemas relacionados, ¢ assim sucessivamente, até se atingir um nivel que € considerado elementar. Pode assim dizet-se que um sistema complexo é expresso através de uma hie- rarquia de elementos. * A selec¢do dos componentes clementares de um sistema complexo ¢ arbitraria € depende de quem a efectua, pois nfo existem critérios universais para 0 fazer. Num sistema complexo, com muitos elementos, as relagdes intra-componen- tes devem ser mais fortes do que as inter-componentes. * Cada sub-sistema € normalmente composto por poucos componentes diferen- tesConceito Conceito CapiTuLo 2 — O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 31 + Um sistema complexo que funciona é invariavelmente uma evolugio de um sistema simples que jé funcionou; um sistema complexo concebido de raiz normalmente nao funciona ¢ dificilmente pode ser alterado de forma a que tal acontega, Existe uma limitagio natural da capacidade humana de lidar com a complexidade: nao conseguimos estar em dois locais a0 mesmo tempo, nem pensar em dois problemas simultaneamente. Por isso, Dijkstra sugeriu a aplicagio do famoso principio da decomposigao hierarquica, também conhecido por divide and conquer (‘dividir para conquistar”), através do qual um problema é dividido em sub- problemas mais clementares € assim sucessivamente, até que a sua resolugio seja mais simples. ‘Também a aplicagio de um mecanismo de abstracgao favorece a eliminacio da complexidade: ja que nao € possivel lidar com toda a realidade dos sistemas com- plexos, 0 ser humano opta por “esquecer” os detalhes menos importantes ¢ focar a sua aten¢io nos mais relevantes, lidando com um modelo simplificado da tealidade, mas considerado suficiente para entender e solucionar correctamente 0 problema em anilise. Para além destas duas ideias, da decomposicao hierérquica ¢ da abstracgio, sio frequentemente referidos na literatura outros principios considerados fandamen- tais para a producio de software de qualidade, designadamente: * O desenvolvimento deve ser efectuado de forma iterativa, repetindo as mes- mas actividades em momentos temporais desfasados, mas detalhando 0 ambi- to das funcionalidades do sistema (ver discussio na Seccio 2.6.2). * Efectuar uma gestio integrada dos requisitos, permitindo a verificagio da ras- treabilidade dos mesmos desde o momento da sua identificacio até a respec- tiva implementagio, facilitando todo o processo de gestio de alteragdes. * Utilizar arquitecturas baseadas em componentes reutilizveis, como forma de diminuir o esforgo de desenvolvimento e posterior manutencio. = Modelar o software através de diagramas, mais facilmente compreensiveis ¢ ijeitos a interpretacdes subjectivas. menos s " Bfectuar sistematicamente a verificagao da qualidade, nao apenas no final do processo de desenvolvimento. + Implementar um proceso sistematico de controlo de alteracdes, de forma a getir adequadamente um problema incontornavel (“os requisitos de negécio mudam frequentemente”) ¢ a definir a forma co momento em que essas alte- rages serio contempladas no sistema,32 CENTRO ATLANTICO —UML, MeTODOLOGIAS E FERRAMENTAS CASE — Vol. | Cada uma destas melhores priticas tem impacto nas outras. Por exemplo, 0 desenvolvimento iterativo favorece a implementagio de uma politica de controlo de alteragdes, uma vez. que 20 diminuir © tempo que vai desde a identificacio da necessidade até a disponibilizacio de uma versio funcional (se bem que parcial) da aplicagio, as alteracdes que entretanto ocorram podem ser incorporadas na nova iteragio. Existem outros principios que deverfo ser aplicados no sentido de garantit o sucesso no desenvolvimento de software: " Conseguir e promover o envolvimento dos utilizadores. * Utilizar uma abordagem orientada para a resolucio de problemas. * Definir e utilizar normas para o desenvolvimento ¢ documentagio. " Justificar o desenvolvimento de software como uma actividade estratépica e como investimento financeiro. Conceber sistemas de modo a facilitar a sua expansao ¢ alteracao. Vale a pena refetir que existiram diversas iniciativas que ao longo do tempo foram desenvolvidas no sentido de melhorar o processo de desenvolvimento de software, nomeadamente: "As iniciativas realizadas pelo Software Engineering Institute, que tém tido uma con- tribuigao importante no estudo e defini¢o de metodologias, estratégias ¢ téc- nicas (para mais informagdes consultar [Paulk93] ou 0 endereco ip:| [sw sei.cmucedd). + As iniciativas relacionadas com a implementacio de politicas de qualidade, em particular da série 9000 da ISO [ISO91]. = A iniciativa SPICE (Software Process Improvement Capability dEterminatiri [Dorling91}. A descri¢ao destas iniciativas sai fora do ambito deste livro, mas recomendamos a consulta das fontes acima apresentadas aos leitores mais interessados nestes temas 2.5 Fases do Processo de Desenvolvimento de Software Uma das ideias dominantes para a melhotia do desenvolvimento de software ¢ a necessidade de aplicar um proceso com fases bem definidas, que se subdivide em conceitos mais elementares (tarefas ¢ actividades). Esta nocio de proceso comegou a ser aplicada ao desenvolvimento de software a partir do momento em que se tornou dbvio que as iniciativas desenvolvidas a0 nivel das actividades deCapiTuLo 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 33 programagio (como foram a programagio estruturada) nao eram suficientes para resolver os problemas que se levantavam no desenvolvimento de software, atendendo ao seu crescimento em termos de complexidade e dimensio. 0 consiste na definigao de um Como vimos na Secgio 2.2, a nocio de proces conjunto de fases sequenciais, cada uma com tarefas bem definidas, nas quais parti- cipam pessoas com responsabilidades atribuidas € com diferentes competéncias, que tealizam diversas actividades; a natureza sequencial do processo implica que uma fase (bem como tarefa © actividade, consoante o nivel de detalhe que estejamos a considerat) tenha que estar terminada antes de outra comecar. Cada tarefa tem um conjunto de outputs bem definidos, que tém que ser produzidos antes que se possa considerar a tarefa como conchuida. Nesta perspectiva, uma fase € constituida por uma sequéncia de tarefas, ¢ estas por sua vez sio formadas por actividades. Os dois primeiros so conceitos abstractos, introduzidos de forma a agregar as actividades realizadas em funcio de critérios relativamente aos quais as actividades apresentam algumas semelhancas, como sejam objectivos a atingir, tipo de trabalho efectuado, relagbes € nivel de inter dependéncia. As actividades correspondem de facto a trabalho realizado, sendo pois a unidade mais elementar em que dividimos esta hierarquia de conceitos (se bem que alguns processos proponham ainda a divisio de uma actividade em passos mais elementares), ¢ € aquela que pode ser medida e estimada em termos de planeamento. Em cada actividade sio envolvidos diferentes membros de uma equipa, que desempenham distintos papéis, e sio produzidos diferentes modelos com vatiados niveis de abstracezo. Na Figura 2.2 pretendemos mostrar a hierarquia de conceitos ¢ a sua sequen- cialidade, de forma puramente abstracta ¢ conceptual, ¢ sem considerar nenhum ptocesso concreto existente, No ambito deste livro iremos considerar que um processo se pode dividir em trés grandes fases ou momentos que traduzem a sua evolugéo temporal: * Concepgao, cujo objectivo é identificar “o que € que o sistema deve fazer”, nomeadamente a informacio a processar, as funcionalidades a implementar, as restricdes existentes, os critérios que determinam o sucesso € a aceitacio; devem ainda ser consideradas e avaliadas diferentes alternativas ¢ efectuada a respectiva seleccio. = Implementagio, em que o objectivo é identificar “o como fazer o sistema”, © construi-lo de facto; nomeadamente, serio definidas ¢ construidas as estrutu- ras de dados, os programas, os médulos, as interfaces (internas ¢ externas), os testes a realizar; no final desta fase devera ser disponibilizado o sistema de forma funcional.34 CENTRO ATLANTICO—UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | * Manutengio, que inclui todas as alteragdes posteriores a aceitagio do produto pelo cliente final: correceiio de erros, introdugio de melhorias ¢/ou de novas fancionalidades. FASE 1 Figura 2.2: Representagan genérica da bierarquia de conctites fase, targa actividade, Se bem que a necessidade de aplicacio de um processo estruturado ao desenvolvimento de software seja consensual, o mesmo nio se pode dizer da sua defini¢io, sobretudo na identificagio das fases ¢ tarefas que o compéem ¢ respectiva sequéncia. Ao cfectuar esta classificagao temos como preocupacio fundamental respeitar varios critérios légicos (como sejam a semelhanca entre os objectivos a atingit © o tipo de actividades realizadas), para além de procurarmos apresentar uma classificacao sintonizada com a maioria dos autores da Area da Engenharia de Software (veja-se por exemplo [Pressman00] ou [Schach99). A Sequéncia das fases considerada neste livro pode ser observada na Figura 2.3, onde fepresentamos também o nivel de detalhe das tarefas. No entanto, no queremos perder a oportunidade de apresentar ao leitor algumas das diferencas mais relevantes que pode encontrar noutras classificagdes. Por exemplo, ha quem considere que o levantamento dos requisitos do sistema ¢ a Tespectiva especificigio so tarefas distintas, enquanto outros autores juntam ambas na tarefa de anilise ¢ consideram-na como duas actividades da referida tarefa (esta foi a nossa opgio, de acordo com os critérios acima apresentados). Ha também quem considere que deve existir uma tarefa de testes independente a seguir ao desenvolvimento do sistema, enquanto outros atigumentam que 0 controlo de qualidade e a realizagio de testes deve set uma preocupacio constante ¢ tealizada a0 longo de todo 0 ciclo, Apesar de concordarmos com este principio, optémos por considerar uma tarefa de testes independente, dado o volume e oCAPITULO 2 ~ O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 35 esforgo que os testes assumem no final da implementagio, e também as especifici- dades destes testes relativamente ao controlo de qualidade que é efectuado 20 longo das restantes tarefas do ciclo. Implementacao Manutengao Gestao do Projecto Gestao de Alteracbes Figura 2.3: Fases ¢ tarefas do processo desenvobiimento de software. Hi ainda quem opte por considetar que o desenho é uma tarefa que deve ser colocada na fase de concepeio, uma ver que as actividades realizadas sio de definigio e nio propriamente de implementagio. A nossa posigio é que, apesar da validade desta observacio, a tarefa de desenho tem como objectivo definir como se vai fazer, e ne sentido deve ser colocada na implementacio. Nao ¢ pelo facto da fase de implementacio ser de natureza eminentemente pritica e operacional que nao podem existir tarefas e actividades de planeamento ¢ de definigio da mesma. Tal como pode ser observado na Figura 2.3, as fases podem ser subdivididas em tarefas mais especificas: "= Planeamento, correspondendo a uma identificagao geral das necessidades, identificagio e selec¢io de alternativas e definigao de plano do trabalho. " Anilise, que inclui a identificagio detalhada das funcionalidades do sistema (Levantamento de Requisitos) a respectiva descricio (Especificagio do Sistema) de modo a que os mesmos requisitos poss n ser validados pelos uti- lizadores finais do sistema. Desenho, onde é realizada a definigao detalhada da arquitectura global da solucio (médulos, tabelas, interface, maquinas, etc.). "Desenvolvimento, tarefa na qual € realizada a programacao dos diversos componentes do sistema,36 CENTRO ATLANTIC ~ UML, METODoLOGIAS FERRAMENTAS CASE = VoL. | + Testes (ou Integracao), em que o sistema no seu global é verificado com 0 objectivo de obter a aceitagio do utilizador. * Instalagao, tarefa onde sio executadas as actividades relacionadas com a disponibilizagio do sistema para os seus utilizadores finais, e que normalmente € designada por entrada do sistema em producao. * Finalmente a Manutengao e a Operagao, que corresponde ao tempo de vida itil do sistema e durante o qual serio efectuadas todas as alteragdes posteriores 4 entrada em funcionamento do produto. Analise Priblewa Dominio da Realizagao Impk jac Dominio da rs oe Solugao Dominio do Problema Piura 2.4: Do problema para a solu. A Figura 2.4 apresenta uma visio diferente sobre o objectivo da aplicacio de um processo de desenvolvimento de software: a partir do enunciado de um problema aplica-se um conjunto de actividades de analise para determinar 0 dominio do problema; a partir do dominio do problema aplica-se um conjunto de actividades de desenho para determinar 0 dominio da solugao; 2 partir do dominio da solugio aplica-se um conjunto de actividades de implementagio para determinar 0 dominio da realizag&o, que é 0 produto final de um projecto. Esta € uma visio muito formal, mas que traduz com rigor o que é de facto realizado.CariTuLo 2—O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 37 Manutencao a E 67% Testes sistema Testes unitarios Programagao [555] 7% Desenho [il 5% Modelizacdo [3 3% Especificagdo [3 3% 0% 20% 40% 60% 80% Figura 2.5: Custos relativos de diversas tarefas do processo de desemvolimento de software, Segundo diversos estudos realizados ¢ condensados em [Schach99}, os custos rela- tivos de cada tarefa de um proceso de desenvolvimento de software podem set observados no grafico da Figura 2.5. ‘Tal como foi referido no Capitulo 1, a manutencio do software sempre foi a tarefa do processo de desenvolvimento de software que maior esforco ¢ custos relatives apresentava. Apesar das iniciativas de implementacio de boas priticas no proceso de desenvolvimento de software que se procuraram introduzir, esta proporgio continua a ser idéntica [Yourdon96]. Passamos de seguida a analisar mais detalhadamente cada uma das tarefas do gu proceso de desenvolvimento de software. 2.5.1 Tarefas Transversais Existem algumas tarefas importantes, que agrupam actividades repetidas sistema- ticamente ao longo de todo 0 processo, ou parte deste, como € 0 caso da gestiio do projecto ou a gestao de alteragdes. Gestdo do Projecto A tarefa de gestiio do projecto agrupa um conjunto de actividades relacionadas com a gestio de recursos humanos, de recursos financeiros e controle dos prazos de execugao das varias tarefas. B caracterizada essencialmente pelos seguintes grandes grupos de actividades: plancamento do projecto; controlo ¢ monitorizacio da sua execugao; intervenglo de modo a tealizar medidas correctivas. 1 este nivel que também funciona como a interface oficial para fora da38 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | equipa do projecto; o seu principal responsével designa- por “gestor de projecto” ¢ intervém directamente na elaboragio dos diversos documentos de mbito global ¢ estratégico: descrico da vistio global do negécio; glossario de termos do negécio; plano do projecto, avaliagio do projecto; plano de gestio de alteragdes. Gestao de Alteragées Em qualquer projecto de sistemas de informagio, € fundamental que estejam previstos mecanismos de controlo das alteracées num processo em curso, j4 que tal como dizia o filésofo grego Heraclito, “a imica certeza é a mudanga permanente”. A capacidade de monitorizagio das alteracdes e do seu impacto no sistema da ao gestor do projecto o meio para avaliar € controlar a qualidade do mesmo. Areas que apresentam alteragées frequentes ¢ imprevisiveis sio normal- mente consideradas areas de risco e indiciam que a tarefa de anélise foi realizada deficientemente. 2.5.2 Planeamento Alguns autores nao consideram o Planeamento como uma tarefa integrante do proceso de desenvolvimento de software, ¢ neste caso incluem as actividades por nds identificadas e englobadas nesta tarefa no Ambito de um planeamento estratégico dos sistemas de informacio da organizagio © nfo no Ambito da Engenharia de Software. Outros consideram-na como uma das tarefas horizontais e permanentes ao longo do proceso, fazendo parte da tarefa de gestio de projectos. De facto, muitas das actividades ¢ técnicas aplicdveis a esta tarefa sto tipicas de gestio de projectos. A razio pela qual nés consideramos uma tarefa de planeamento logo no inicio do proceso, é porque é necessirio ter uma visio global sobre o Ambito do trabalho a realizar, de modo a elaborar um planeamento e a efectuar uma anilise de viabilidade do projecto. A nossa perspectiva é que s6 temos um projecto depois do seu plano estar aprovado, ¢ é esse o principal objectivo desta tarefa; alias, nalgumas situagdes poder ser tomada nesta fase do projecto a decistio de nao avangar com 0 mesmo. Existem ainda varias circunsténcias particulares em que esta tatefa deve ser realizada, por exemplo: = Num projecto que envolve a seleegio de entidades para posterior implementa do software, a elaboracao de cadernos de encargos ¢ a avaliagio de pro- postas pode ser englobada nesta tarefa.CapituLo 2 — O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 39 Quando existir a necessidade de efectuar apenas uma investigacio inicial, com recolha de informacio suficiente sobre o problema ou oportunidade para determinar se a situaciio actual justifica 0 desenvolvimento de uma solugio suportada por um sistema de informacio. A grande preocupacio desta fase é que a partir de um levantamento de alto nivel das necessidades do negécio seja possivel elaborar um plano do projecto a executar nas fases subsequentes, com identificacio de actividades, recursos, prazos e custos. Para isso, existem um conjunto de actividades que deverio ser realizadas, designadamente: = Compreendet a missio organizacio da empresa. = Identificar € envolver todos os interessados ¢ afectados pela introducio do sistema, * Obter uma visio de alto nivel do funcionamento do sistema actual, caso ele exista, * Definir o ambito do sistema. # Elaborar uma desctigio de alto nfvel do problema, = Identificar restrigdes, problemas ¢ tiscos do projecto. + Identificar alternativas de implementagao, proceder sua avaliagio ¢ selecgio, = Apresentar resultados ¢ recomendacdes, com justificacio técnica, funcional e financeitn * Blaborar e obter aprovagio de um plano de projecto. + Definir 0 processo de controlo do projecto. Como se constata desta lista (nfo exaustiva) de actividades a realizar, muitas sio actividades que qualquer gestor de projectos (independentemente da area do conhecimento humano em que trabalhe) deve saber executar. Por isso, também a maioria das técnicas a utilizar nfo so especificas dos sistemas de informagio, mas comuns a Area de gestio, tais como: anilise financeira de custos e/ou beneficios; claboragio de estimativas; elaboragio de planos de projectos (identificagio de tarefas, claboracio de diagramas Pert ¢/ou Gantt); identificagio de riscos € medidas de os controlar; elaboragio de arvores ou tabelas de decisio; aplicacio de técnicas de modelagao de processos. No final da tarefa, ¢ como consta da lista de actividades, devera ser obtida a apro- vacio para continuar com projecto, sendo fundamental que esta concordancia seja obtida de todos 0s interessados no projecto, em particular, do patrocinador do mesmo (0 cliente/utilizador que tem mais interesse na resolugio do problema e/ou que despoletou todo 0 processo), pela area de informatica muitas vezes (emConceito 40 ‘CENTRO ATLANTICO = UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | fangio do volume de investimentos ou das politicas internas estabelecidas) por 6rgiios superiores da organizacio. Exemplo 2.1: Exemplo de um plano do projecto. 1 = Introdugao (Ambito © propésito do documento, Objectivos do projecto, Fungdcs mais sclevantes, Quests de performance, Resttigdes téenicas e de gestio) 2. Contexto do projecto (Visio estatégica do negécio, Descrcio de funedes) 3 - Especificagdes de alto nivel dos requisitos 4 - Estimativas do projecto (Dados histéricos utilizados nas estimativas, Técnicas de estimag ) 5 - Riscos do projecto (Anilise de risco: Identifieagic, Fstimagao, Avaliacio; Gestio do risco: Opgies para evi tsco, Procedimentos de monitorizagio dos tiscos) {6 Recursos do projecto (Pessoas - Estrurura da equipa, Hardware ¢ Software, Outros) 7 - Calendarizagio (Werk bration srature,Diagramas de Pest ¢ de Gant) 8 - Mecanismos de acompanhamento e controlo 9) Andlise custos / beneficios }10 - Aniilise de alternativas principal ompus desta tarefa sera um plano de projecto (wer exemplo acima), que devera reflectit sustentadamente a visio que se tem nesta fase do processo sobre as actividades a desenvolver futuramente, quer seja relativamente 4 sua inventariagio, recursos, prazos € custos envolvidos, como também em telacio aos beneficios potenciais que o sistema apresentar4 no futuro para toda a organizagio. 2.5.3 Andlise A tarefa de andlise efectua 0 estudo detalhado do dominio do problema, ¢ culmina na claboragio de um documento onde os requisitos funcionais da solucio a implementar e outras questées televantes (por exemplo, restrigdes, ambito, fluxos de informagio) sio enumerados. ‘Tem normalmente dois grandes momentos ou sub-tatefas (que tipicamente sao realizados em simultineo): Levantamento de Requisitos Um fequisito é uma afirmacao sobre uma funcionalidade ou condi¢io que o sistema devera possuir [Kotonya98]. Para os identificar adequadamente, é aplicadoConceito CapituLo 2-0 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 41 um conjunto de técnicas de modo a obter a percepeio detalhada daquilo que o sistema devera efectuar, Estas poderiio incluir a realizagio de reunides com os. interessados (entrevistas individuais, reunides tradicionais, de brainstorming, ou de caricter criativo), a elaboragao de questionatios, a observaciio das actividades e do funcionamento do dia-a-dia, a tecolha e anélise de documentagio diversa, a elaboragio de pequenos protdtipos do sistema que permitam validar mais facilmente a percepcao obtida (seguindo © principio que “uma imagem vale mais do que mil palavras”). Deve-se ter a preocupacio de encontrar a melhor solucio, pois por vezes aquilo que 0 cliente pede nem sempre é 0 que ele necesita (este facto esté relacionado com o seu desconhecimento do que se pode obter de um sistema de informacao). Outra questio a considerar tem a ver com a importancia de identificar no apenas as funcionalidades actuais, mas sobretudo determinar a situagao furara a atingir. Especificagao do Sistema Contrariamente ao que se poderia julgar em primeira instincia, definir e descrever 08 requisitos de um sistema nfo é tarefa facil: as interpretagdes € representagdes que cada individuo tem relativamente a um determinado sistema sio quase sempre subjectivas. O objectivo geral desta sub-tarefa é expressat sem ambiguidades o que o sistema “deve fazer” e no “o como fazer o sistema”. conjunto de todos os requisitos funcionalidades de um sistema é reunido num documento designado por “Especificagio de Requisitos”. Se bem que a designacio mais utilizada seja esta, tal ndo quer dizer que no relatério apenas estejam enumerados os requisitos. 2 normal incluir outro tipo de informagio, nomeadamente os fluxos de informagio que poderio ocorrer no sistema, a identificacdo dos respectivos componentes e das suas relacdes, as testrigdes do sistema, as reas internas e externas da organizacao afectadas. Este documento deve ser visto como um contrato, dai a importincia de ser o mais rigoroso, objective, coerente e completo possivel. A especificagio utiliza normalmente técnicas de modelagdo de processos, de definigiio de conceitos e de reptesentacio do comportamento do sistema, que serio apresentadas no préximo capitulo. Tal como na tarefa anterior, no final desta tarefa de anilise deve-se colocar a questo da continuidade do projecto, e obter das mesmas pessoas anteriormente referidas a aprovagio da especificacio de sequisitos elaborada ¢ do plano de ptojecto, agora revisto ¢ detalhado.42 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | 2.5.4 Desenho Na tarefa de desenho é efectuada a definicio do dominio da solugio. Com base nos resultados produvidos pela tarefa de andlise, procede-se a especificacdo, formal ou informal, das caracterfsticas que a implementagio do sistema pretendido devera apresentar, assim como a realizagio de determinadas optimizacdes consoante as caracteristicas da infra-estrutura tecnoldgica de suporte. Esta especificagio inclui, por exemplo, arquitecturas de computadores, tecnologias de bases de dados, sistemas de execugio de agentes, infra-estruturas de objectos ¢/ou componentes. B também nesta tarefa que deve ficar definido o ambiente e as linguagens a utilizar no desenvolvimento do sistema. Diz-se também com frequéncia que 0 desenho é a fase da especificacio técnica, uma vez que sio definidos os componentes aplicacionais (objectos, médulos, programas, servidores aplicacionais), tecnolégicos (redes, méquinas, outros servidores) ¢ os dados (estrututa de ficheiros e/ou de bases de dados, servidores a utilizar). Toda esta definicao € realizada de forma integrada; é feita a descrigio da logica e dos algoritmos das aplicacdes, as interfaces ¢ os outputs do sistema sio também modelados neste ambito. Factores como o desempenho, a seguranga ¢ a operacionalidade do sistema deverio ser tidos em conta € utilizados (para além dos tradiciomais ctitérios de custos © prazos) para seleccionar entre varias alternativas. Devem também ser claborados os planos de testes ¢ de migracao do sistema actual (ambos para cxecutar numa fase posterior), se bem que alguns autores protelem a claboracao destes planos para mais tarde, imediatamente antes da sua realizacio. 2.5.5 Implementacaéo A tarefa de implementagio inclui todas as actividades de desenvolvimento do sistema propriamente dito, ou seja, aquelas que esto relacionadas com a coneretizacio do modelo de desenho produzido na tarefa anterior, Os diversos componentes aplicacionais sio codificados e testados de forma isolada, garantindo assim a respectiva correccio interna; este tipo de testes designa-se normalmente por testes unitétios, uma vez que incidem sobre parcelas do sistema, © s realizados pot cada programador de forma independente. Preferencialmente, as actividades desta tarefa deveriam set apoiadas por ferramentas, que a partir da especificagio do modelo de desenho produzido fossem capazes de produzir automaticamente ivetsos componentes do sistema Esta possibilidade pode set concretizada por ferramentas ¢ ambientes de desenvolvimento evoluidos e integrados, de forma que a tarefa seja executada comCapiTULO 2 — O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 43 © menor esforo © no menor periodo de tempo possivel. Actualmente assiste-sc, no contexto dos sistemas de informacao cliente/servidor, 4 crescente utilizagio de ambientes de desenvolvimento bastante produtivos (designados por ambientes IDE, do inglés Integrated Development Environment), baseados em infra-estruturas de objectos/componentes evoluidos, complexos ¢ providenciando técnicas de proto- tipagem e de desenvolvimento visual. A crescente aquisi¢io pelas organizagoes de aplicagdes previamente desenvolvidas com funcionalidades mais ou menos uniformizadas para a maioria das organizagGes (designados por pacotes aplicacionais do tipo ERP, CRM, SCM, e outros), fez com que o tipo de actividades a executar ao longo desta tarefa tenha mudado de alguma forma: a programacio pura cedeu uma parte da sua importincia em favor de esforgos de integracio (entre os diversos componentes “pré-fabricados”), de paramettizagio (concretizacio de parimetros genéricos pre- vistos na aplicacio para os valores utilizados pela organizaciio) e de configuragio adicional (adaptacio de funcionalidades j4 existentes as especificidades da organi- zacio, podendo implicar desenvolvimento). 2.5.6 Testes Para além dos jé refetidos testes unitérios, executados durante a realizacio da tarefa anterior, a tarefa de testes destina-se 4 execucio dos restantes tipos de testes. O objectivo é avaliar a adequada correcefio e funcionamento de todos os compo- nentes do sistema, principalmente os executaveis. A verificacio consiste na confir- magio que a codificacio/implementagio do sistema esti conforme (correcta) a especificagao técnica produzida na tarefa de desenho, que pot sua vez resulta dos requisitos es pecificados na anilise. Estes testes deverio ser executados em condicdes idénticas aquelas que o sistema real ira possuir, mas fisicamente deverd ser suportado por outros componentes, de forma a que nao existam interferéncias entre as actividades dos programadores ¢ os testes dos utilizadores, ¢ sobretudo com 0 trabalho normal do dia-a-dia destes iltimos. Por isso, muitas organizagdes criaram uma separacio a0 nivel fisico entre 08 componentes de natuteza aplicacional que estio a ser desenvolvidos, testados ou utilizados para suportar o negécio real da empresa, nomeadamente através do suporte em miéquinas e ambientes distintos. O facto dos ambientes serem fisicamente separados nfo significa que no seja possivel aceder a virios a partir de um mesmo posto de trabalho. Os testes a realizar podem ser classificados em contextos de execugio diferentes, segundo as caracteristicas do sistema que sio avaliadas:Conceito 44 CENTRO ATLANTICO— UML, MeTODOLOGias E FERRAMENTAS CASE — VOL. | * Testes de desempenho: permitem analisar 0 tempo de resposta do sistema e, duma forma geral, verificar o nivel de utilizagio de recursos dispontveis em situagdes normais. = Testes de carga: permitem analisar ¢ avaliar 0 comportamento do sistema em situagdes de utilizacio intensiva ¢ aferir a sua capacidade de escalabilidade. * Testes de usabilidade: permitem analisar a adequabilidade do desenho das interfaces homem-maquina e constatar se o sistema ¢ de utilizagio ¢ aprendi- zagem facil. * Testes funcionais: permitem determinar a correc¢do da implementacio de funcionalidades, conforme especificadas pelos correspondentes requisitos fun- cionais, Os testes podem ainda classificar-se segundo o ambito dos componentes do sistema que sao alvo de verificagio. Por exemplo: "Testes unitarios, ja anteriormente referidos. * Testes de integragio: testes parcelares, que vitios programadores realizam conjuntamente com vista a garantir que varios componentes interactuam entre side forma adequada. * Testes de sistema: testes globais em que todos os componentes do sistema 1 integrados; possibilitam a verificagio da conformidade do sistema com todos os requisitos definidos. = Testes de aceitagao: testes formais que os utilizadores realizam sobre 0 sis- tema. Quando o sistema passa este (dificill) teste, o cliente deveri aceitar o sistema como “pronto” e consequentemente este pode ser colocado em pro- dugio, ou operagio, efectiva. Nos casos em que o desenvolvimento pretende substituir um sistema existente, uma abordagem que muitas vezes € utilizada consiste na tepeticio, no novo sistema, das actividades realizadas no sistema antigo, de forma a validar os resultados obtidos. Esta estratégia é designada por paralelo de sistemas. A vetificacio pode ser apoiada a diferentes niveis por ferramentas de depuracio (debugging) especificas & providenciadas conjuntamente ¢ de forma integrada (ou nio) com o testo do pacote do ambiente de desenvolvimento, Para além das ferramentas existem hoje em dia técnicas mais formais de tealizacio de testes, cuja descti¢io vai muito além do ambito deste livro (para mais informagio consultar [Pressman00)).Capiruto 2-0 PROCESO DE DESENVOLVIMENTO DE SOFTWARE 45 Testes de Aceitacao Testes de carga, de desempenho, etc Testes de Sistema Testes de integracao Testes unitarios Programador Analista / Controle Qualidade Analista / Controle Qualidade Analista { Controle Qualidade Utilizador Figura 2.6: Tipos de testes e respectivo responsdvel O objectivo fundamental desta tarefa é conseguir a aceitacio formal do cliente rela mesmo da decisao de colocar o sistema em funcionamento, ivamente 4 adequacio do sistema as suas necessidades, ¢ a aptovacio pelo 2.5.7 Instalagao A tarefa final da fase de implementago do sistema é a respectiva instalagio em ambiente de produgio, de forma a disponibilizar as funcionalidades concebidas para os seus verdadeiros utilizadores. Esta tarefa consiste na preparagio ¢ instalacio do sistema na infra-estrutura computacional destino e na sua sub- sequente operacio regular. Envolve um conjunto nem sempre entendido e quanti- ficivel de tarefas, que muitas vezes sio esquecidas na altura da preparacio do plano do projecto, tais como: * Configuracio ¢ paramettizagao do sistema implementado bem como dos siste- mas de suporte requeridos (por exemplo, sistemas de gestio de bases de dados, servidores aplicacionais, etc.). = InstalagZo dos componentes aplicacionais necessétios. " Definigio de perfis, de utilizadores e de niveis de seguranca. " Pormagio dos utilizadores no sistema, * _ Definicio ¢ implementagio de politicas de seguranga (por exemplo, criagio de cépias).46 CENTRO ATLANTICO—UML, METODOLOGIAS E FERRAMENTAS CASE - VoL. | ainda normalmente durante esta tarefa que sio elaborados diversos documentos sobre o sistema desenvolvido, nomeadamente documentacio de opetagio, administragio ¢ utilizagio do sistema. Uma vez que estes docu- mentos desctevem a realidade do sistema segundo diferentes perspectivas, 56 apés a conclusio do desenvolvimento, ¢ na presenga de um sistema estivel é que se pode proceder elaboracao da referida documentacio. Caso exista jA um (ou mais) sistemas em funcionamento € necessirio efectuar a migtacio para © novo sistema, de acordo com 0 que foi definido no plano anteriormente claborado. Num momento previamente acordado é efectuada a migracio para 0 novo sistema, passando os utilizadores a partir desse momento a trabalhar no novo ambiente, designado de producio. 2.5.8 Manutencao Durante a vida itil de qualquer sistema de software sio detectados problemas que no foram devidamente verificados durante a fase de implementagio (designados por bugs). Surgem também inémeras solicitacdes internas e externas relativamente a pedidos de altetagio de requisitos que nao foram contemplados originalmente na fase de concepgio, que exigem a claboracio de novas versées/actualizagdes do software. Sio ainda detectados problemas que apenas so identificados nesta fas normalmente relacionados com questdes de desempenho do sistema, ¢ que apenas se tornam perceptiveis com a sua crescente utilizagio. A Figura 2.7 mostra a Proporcio em que estas diversas situagdes ocorrem. 10% 99 $$ 60%+ 50%: 40% 30%: 18% 7 20% | in = | 0% + Novos. Eros: Melhorias Outros: Requisitos Técnicas Figura 2.7: Percentagem relativa das intervengies que ovorrem durante a manuitengéo do software. O objectivo da tarefa de manutencio de software é gatantir que a ocorréncia de alguma destas situagdes é convenientemente tratada. Actualmente, muitos autores no consideram a manuten¢io como uma tarefa com actividades prdprias, mas simConceito CapiTULo 2 —O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 47 como o perfodo que se inicia imediatamente apés a entrada em produgio do sistema, ¢ que dura enquanto o software se mantiver a funcionar. Isto porque as actividades a executar sobre 0 sistema fazem de facto parte de outras tarefas ja desctitas (anilise, desenvolvimento, testes, etc). Por isso, € mais correcto considerar que a manutengio desencadeia uma nova iteragao de todo o processo de desenvolvimento de software, perspectiva com a qual nds concordamos. Complementarmente 4 manutengo sio realizadas outras actividades que garantem © bom funcionamento do sistema segundo diversos critérios, e que tém uma intervengio sobretudo a nivel tecnolégico. Estamos a referir-nos ao conjunto de actividades que pode ser genericamente designado por operagao do sistema, ¢ que inclui, entre outras, a realizacio de cépias de seguranga do sistema, a veri- ficago dos parametros de desempenho, adefinigao de novos utilizadores, ete. 2.6 Processos de Desenvolvimento de Software A descri¢io genérica das fases ¢ tarcfas dos processos efectuada na seccio anterior € concretizada em modelos em que a sequéncia ¢ os nomes das fases ¢ tarefas assumem diversas especificidades. Independentemente das particulatidades de cada proceso, podemos distingui-los genericamente segundo duas grandes aproximagdes: aqueles que seguem uma aproximacio segundo um modelo em cascata ¢ os que tém uma aproximacio iterativa, Note-se que esta distincio é notmalmente ortogonal em relago ao facto do proceso usar uma abordagem estruturada ou otientada por objectos, conforme se poder verificar no Capitulo 3. Pode-se tet, por exemplo, um processo iterative adoptando uma abordagem struturada, ou um proc so em cascata adoptando uma abordagem otientada por objectos, ou qualquer outra combinacéo, Enquanto a iteratividade tem a ver com a sequéncia das actividades, a abordagem tem a ver com o paradigma, os conceitos base ¢ a forma de modelar e solucionar o problema. 2.6.1 Processos em Cascata Os processos tradicionais de desenvolvimento dé software sio caracterizados pot adoptarem um modelo em cascata (ver Figura 2.8), em que as’ actividades a executar sio agrupadas em tarefas, executadas sequencialmente, de forma que uma tarefa s6 tem inicio quando a tarefa anterior tiver terminado. Este tipo de ptocessos foi originalmente proposto por Barry Bochm durante a década de 1970 documentado detalhadamente em [Boehm87].48 CENTRO ATLANTICO~ UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | Planeamierto ‘Analise ‘Desenha Dasemanmente "Testes Figura 2.8: Processo enw cascata. O modelo em cascata preconiza que s6 se avanga para a tarefa seguinte quando o cliente valida ¢ aceita os produtos finais (documentos, modelos, programas) da tarefa actual; quando se avanca para a tarefa seguinte, o resultado da tarefa anterior considera-se “fechado” © nfio pode ser sujeito a posteriores alteragées (0 que, como sabemos, dificilmente se adequa 4 realidade dos nossos dias). Este tipo de Pressuposto tem por objectivo garantir que o cliente a quem se destina o software aceita os produtos do processo de desenvolvimento, comprometendo-se com eles, © que de algum modo protege a equipa de desenvolvimento das frequentes necessidades/tentativas de alteragGes com otigem em pedidos do cliente, Este tipo de salvaguarda formal di uma significativa proteccio A empresa de software quando, como € corrente, o cliente vem dizer que 0 produto final entregue iio corresponde As suas expectativas niio é 0 que ele encomendou. No entanto, esta salvaguarda nio evita que © projecto nao obtenha os resultados originalmente esperados, que 0 cliente fique desapontado, e que se tenha desperdicado tempo ¢ recursos indevidamente. © modelo em cascata apresenta ainda outras limitagées. Por exemplo, promove a compartimentagio dos esforcos ao longo das diferentes tarefas e consequente- mente desencoraja a comunicagio ¢ partilha de vis6es entre todos os intervenientes do projecto, por exemplo, entre os analistas, os responsaveis pelo desenho, os Programadotes, ¢ os utilizadores. Minimiza o impacto da compreensio adquirida no decurso de um projecto, uma vez que se um processo nao pode voltar atris de modo a alterar os modelos e as conclusdes das tarefas anteriores, é normal que as novas ideias sobre o sistema no sejam aproveitadas.Conceito Conceito CapiTuLo 2 - O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 49 De forma a eliminar este problema foi definido um novo proceso, baseado no modelo clissico em cascata, e designado por modelo em cascata revisto (ver Figura 2.9), que prevé a possibilidade de a partir de qualquer tarefa do ciclo se poder regressar a uma tarefa anterior de forma a contemplar alteragdes funcionais e/ou técnicas que entretanto tenham s urgido, em virtude de um maior conhecimento decorrente do desenrolar do projecto. © risco desta abordagem é que, na auséncia de um proceso bem definido de gestio do projecto e de controlo das alteracées, podemos passar o tempo num ciclo sem fim, sem munca se atingir o objectivo final que é disponibilizar um sistema a funcionar. jeer Figera 2.9: Proceso em cascata revist, My Ambos 0s modelos anteriores apresentam o problema da extensio do periodo de tempo que decorre entre 0 inicio do projecto ¢ a entrega do produto final, que pela sua duragio nao corresponde minimamente as expectativas do cliente. Uma solugio encontrada para resolver parcialmente este problema consistiu na aplicagio de técnicas de prototipagem logo no inicio do proceso, sendo este modelo designado pot prototipagem répida. Nao climina a necessidade de todas as restantes tarefas sequenciais, mas permite que o cliente veja ¢ valide um modelo da interface (¢ das respectivas funcionalidades) que iré ter disponivel, minimizando também os problemas inerentes da comunicagio. Neste tipo de processos é preciso ter um cuidado acrescido para nfo ceder as naturais presses do cliente, no sentido deste ‘passat a utilizar de imediato o protétipo. Hi que o protétipo € normalmente apenas constituido por uma sequén-Conceito 50 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | cia de ects sem quaisquer validagdes ou acesso a bases de dados, ¢ a disponibili- zacio destas funcionalidades requet tempo ¢ um esforco significativo. A satisfagio da pretensio do cliente significaria comprometer a qualidade do produto em detrimento de “ter qualquer coisa a funcionar” . Existe ainda o perigo de se perder a visio mais global e abrangente do sistema e respectivas funcionalidades em detrimento de uma visio mais restrita ¢ imediatista baseada em sequéncias de ects ou paginas Web. 2.6.2 Processos Iterativos e Incrementais Em contraste com os processos baseados no modelo em cascata, os processos mais recentes de desenvolvimento de software recomendam, na sua generalidade, a utilizagio do modelo iterative ¢ incremental. Com estas ideias encoraja-se a comunicacio entre todos os intervenientes de modo a produzir sistemas finais mais robustos ¢ com qualidade superior. De certa mancira, 0 proceso em cascata revisto é um antecessor destes process0os iterativos, A nogao de processo iterative corresponde & ideia de refinar pouco-a-pouco o ambito ¢ a concretizagio do sistema. Um exemplo de aplicacio do. proceso iterativo encontra-se no trabalho artistico, em que o resultado final de uma obra de arte sofre intimeras iteragdes (algumas das quais, por vezes, destrutivas para o seu resultado final). O ambito do sistema nao é alterado, mas o seu detalhe vai aumen- tando em iteracdes sucessivas. Para além dessa caracteristica, o desenvolvimento iterative apresenta ainda outras ignificativas para 0 desenvolvimento de software [Kruchten00} vantagent * Os tiscos ¢ diividas com maior importincia sio identificados no inicio do pro- cesso, nas primeiras iteracdes, quando é possivel tomar medidas para os cor- rigir. = Esta abordagem encoraja a participagio activa dos utilizadores de modo a identificar os verdadeiros requisitos do sistema. A execucio de testes continuos ¢ iterativos permite uma avaliagio objectiva do estado do projecto. * As inconsisténcias entre a aniilise, © desenho ¢ a implementagio sto identifica- das atempadamente, facilitando a rastreabilidade ao longo do projecto. = Oesforco dos diversos elementos da equipa é distribuido ao longo do tempo. = A cquipa pode aprender com experiéncias anteriores ¢ melhorar continua- mente 0 processo. = Pode ser demonstrado inequivocamente a todos os envolvidos € interessados no projecto o respective avango.Conceito Conceito CapiTULO 2 — O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 51 ‘A nogio de processo incremental corresponde a ideia de “aumentar (ow alargar) pouco-a-pouco” o ambito do sistema. Uma boa imagem para este atributo é a de uma mansio que foi construida por sucessives incrementos a partir de uma primeira casa com apenas duas divisdes (tendo’em conta o resultado final, se calhar seria mais correcto considerar 0 mesmo como um bairro de lata e nado como uma mansio). Combinando as duas ideias anteriores, 0 principio subjacente ao proceso iterativo e incremental (ver Figura 2.10) é que a equipa envolvida possa refinar e alargar pouco-a-pouco a qualidade, detalhe ¢ ambito do sistema envolvido. O projecto encontra-se organizado numa série de iteragdes, em que, por exemplo, numa primeira iteragao se identifica a visio global e determina a viabilidade econémica do sistema, e se efectua a maior parte da andlise ¢ um pouco de desenho e implementagio. Numa segunda iteracio, conclui-se a anilise, realiza-se uma patte significativa do desenho, ¢ um pouco mais de implementacio. Numa terceira iteragio, deve concluir- ¢ o desenho, faz-se parte substancial da implementagio, ¢ efectua-se parte das actividades de testes e de integra¢io; ¢ assim por diante. Ou seja, a principal consequéncia da aproximagio iterativa é que os prtodutos finais de todo o processo vio sendo amadurecidos e completados ao longo do tempo, mas cada iteragio produz sempre um conjunto de produtos finais. Existem ainda outras vantagens adicionais dos modelos iterativos ¢ incrementais, por oposigio a0 modelo em cascata, ¢ entre estas podem-se salientar as seguintes: possibilidade de avaliar mais cedo os riscos ¢ pontos criticos ou mais significativos do projecto, ¢ identificar medidas para os climinar ou pelo menos controlar; definigao de uma arquitectura que melhor possa otientar todo o desenvolvimento; disponibilizagio natural de um conjunto de regras para melhor controlar os inevitaveis pedidos de alteragées futuras; ¢ permite que os varios intervenientes possam trabalhar mais efectivamente pela interacgiio ¢ partilha de comunicagao dai resultante. Finalmente uma tltima nota. E normal encontrarmos na literatura apenas referéncias ao termo iterativo, mas em muitas situacdes a definicio que Ihe esta subjacente implica também a nogio de processo incremental, no sentido que é apresentada neste livro.52 CENTRO ATLANTICO— UML, MeToDoLoaias E FERRAMENTAS CASE — VoL. | Desemoniments versio Figura 2.10: Processo iterativo e incremental. Espiral © modelo em espiral pode ser considerado como uma pequena variante do modelo iterativo ¢ incremental. Foi proposto por Barry Bochm [Bochm88] como resposta as criticas que 0s processos existentes na altura nfo favoreciam a utilizagaio de prototipagem e reutilizacio de software. Por isso, ¢ para além das Conceito tarefas ¢ actividades previstas pelos outros processos, propde logo de seguida 4 tarefa de planeamento a realizacio de uma tarefa de prototipagem ¢ de anilise do isco, como forma de eliminar os principais problemas ¢ identificar os requisitos do sistema, 2.7 Conclusao O objectivo deste capitulo foi o de realcar a importincia da aplicacio de métodos € técnicas que contribuam para a melhoria do processo de desenvolvimento de software, nomeadamente a aplicagio dos principios da abstraccio e daCapiTuLo 2 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 53 decomposigao hierarquica face a complexidade e dimensio crescentes do software, € a utilizagao de um processo de desenvolvimento uniformizado. Foram apresentados diversos conceitos relacionados com 0 processo de desenvolvimento de software sempre numa perspectiva genética ¢ abstracta, Foi 0 que aconteceu com as definigdes dos conceitos de metodologia ¢ proceso, assim como com a discussio relativa as nocées de fases, tarefas ¢ actividades. Houve a preocupagiio de cfectuar esta apresentaciio sem estar condicionado por nenhuma abordagem metodolégica concreta. No préximo capitulo vamos analisar como é que ao longo do tempo estes conceitos tém evoluido, ¢ perceber o contexto em que surgem as abordagens orientadas por objectos, ¢ notagdes ¢ lingaagens de modelagio como é 0 caso do UML.54 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | 2.8 Exercicios Ex.8. “O conceito de metodologia concretiza (pde em pritica) 0 conceito ted- rico de processo”. Comente esta afirmagao. Ex.9. Indique algumas razdes pelas quais a estrutura de um processo de desenvolvimento tradicional ¢ criticada hoje em dia. Ex.10. Muitas metodologias defendem actualmente a importincia de se aplica- rem sistematicamente técnicas de controlo de qualidade, ¢ de se realizarem testes a0 longo de todas as fases do ciclo de vida, ¢ nao apenas postetior- mente 4 programagao, Indique de que modo é que estas actividades poderio ser concretizadas nesses outros momentos. Ex.11, Indique de que maneira é que © desenvolvimento iterative pode contri- buir para favorecer a aplicagao sistematica de técnicas de controlo de altera- oes. Fix.12. Na sequéncia das criticas apontadas ao ciclo de vida em cascata, foi suge- rida a aplicacio de técnicas de prototipagem como forma de ultrapassar esses problemas, o que resultou num novo ciclo de desenvolvimento. Concorda que, apenas por este facto, se possa considerar um novo ciclo? Justifique. Ex cio de requisitos? Estas duas tarefas sio sempre independentes uma da outra, ou existem abordagens em que esto incluidas na mesma tarefa? . Quais as diferengas que existem entre as tarefas de andlise ¢ de especifica- Ex.14, “O modelo em espiral nao traz nenhum valor acrescentado aos processos iterativos € incrementais”. Comente esta afirmacao. Bx.15. Relativamente as tarefas de um proceso de desenvolvimento de software apresentadas na Figura 2.3, existirdo situacdes em que algumas possam ser climinadas? Justifique a sua afirmacio.