UFES Universidade Federal do Espírito Santo CEUNES Centro Universitário Norte do Espírito Santo DECOM Departamento de Engenharias e Computação

Transcrição

1 UFES Universidade Federal d Espírit Sant CEUNES Centr Universitári Nrte d Espírit Sant DECOM Departament de Engenharias e Cmputaçã CURSO DE ENGENHARIA DE COMPUTAÇÃO Cmpilaçã de Texts pr Maria das Graças da Silva Teixeira Sã Mateus, ES

2 SUMÁRIO 1 SOFTWARE PANORAMA SOBRE SOFTWARE O PRODUTO DE SOFTWARE (OU SIMPLESMENTE SOFTWARE) OS CUSTOS DO SOFTWARE EVOLUÇÃO DO SOFTWARE CONCEITOS SOBRE SOFTWARE Definiçã Características Reusabilidade CATEGORIAS DO SOFTWARE SOFTWARE LEGADO PROBLEMAS COM SOFTWARES E SUAS CAUSAS Prblemas enfrentads pels desenvlvedres de sftware MITOS DO SOFTWARE LEITURA RECOMENDADA ENGENHARIA DE SOFTWARE ALGUMAS DEFINIÇÕES OBJETIVOS DA ENGENHARIA DE SOFTWARE DIFERENÇAS RESPONSABILIDADE PROFISSIONAL E ÉTICA OS ATRIBUTOS DE UM BOM SOFTWARE ASPECTOS HISTÓRICOS Ns Primórdis A Crise de Sftware PRINCÍPIOS DA ENGENHARIA DE SOFTWARE OS ELEMENTOS FUNDAMENTAIS DA ENGENHARIA DE SOFTWARE PARADIGMAS DA ENGENHARIA DE SOFTWARE OS MÉTODOS ADOTADOS PELA ENGENHARIA DE SOFTWARE FASES DA ENGENHARIA Detalhand Resumind LEITURA RECOMENDADA O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PANORAMA SOBRE PROCESSO DE SOFTWARE O QUE É PROCESSO? ATIVIDADES TÍPICAS DO PROCESSO DE SOFTWARE CICLO DE VIDA DE SOFTWARE MODELOS DE PROCESSO DE SOFTWARE Selecinand um Mdel de Prcess Resumind Panrama sbre Mdels Prescritivs de Prcess Cde and Fix (Cnstrói e Cnserta) Clássic / Em Cascata Incremental RAD (Rapid Applicatin Develpment) Mdels Evlucináris Prttipagem Espiral u Evlutiv Cncrrente Desenvlviment basead em Cmpnentes O mdel de Métds Frmais... 47

3 Desenvlviment de sftware rientad a aspects Prcess Unificad (PU) DESENVOLVIMENTO ÁGIL Panrama sbre Desenvlviment Ágil O que é agilidade O que é um prcess ágil Plítica de Desenvlviment ágil Fatres Humans Extreme Prgramming (XP) Scrum FDD (Feature Driven Develpment) AUTOMATIZAÇÃO DO PROCESSO DE SOFTWARE Autmatizaçã de Prcesss de Sftware A Estaçã TABA TEXTO COMPLEMENTAR LEITURA RECOMENDADA ENGENHARIA DE REQUISITOS CONCEITUAÇÃO ENGENHARIA DE REQUISITOS Dificuldades a serem enfrentadas Atividades da Engenharia de Requisits Estud de Viabilidade Elicitaçã de Requisits Mdelagem de Requisits Verificaçã e Validaçã Gestã de Requisits UML - LINGUAGEM DE MODELAGEM UNIFICADA LEVANTAMENTO DE REQUISITOS Técnicas de Levantament de Requisits Cleta de Dads Mdelagem de Cass de Us RESUMO Dcumentaçã ANÁLISE DE REQUISITOS Técnicas de Análise de Requisits Análise Orientada a Objets Dcumentaçã LEITURA RECOMENDADA DESIGN DE SOFTWARE CONCEITUAÇÃO IMPORTÂNCIA DO PROJETO MODELOS DE ESPECIFICAÇÃO CARACTERÍSTICAS COMUNS DOS MÉTODOS GUIDELINES E PRINCÍPIOS PARA O PROJETO CONCEITOS FUNDAMENTAIS DE DESIGN DE SOFTWARE PROJETOS Prjet de Arquitetura Prjet de Dads Prjet de Interface Prjet de Cmpnentes PROJETO ORIENTADO A OBJETOS DESIGN PATTERNS (PADRÕES DE PROJETO) Fábrica Abstrata Métd Mdel Prcuradr Observadr DICAS DE LEITURA IMPLEMENTAÇÃO E TESTES

4 6.1 IMPLEMENTAÇÃO TESTES Estratégias de Teste Verificaçã x Validaçã Organizaçã de Teste de Sftware Fases de Teste Teste de Unidade Teste de Integraçã Teste de Validaçã Teste de Sistema A Arte da Depuraçã Técnicas de Teste DICAS DE LEITURA ENTREGA E MANUTENÇÃO DE SOFTWARE ENTREGA MANUTENÇÃO Intrduçã Definiçã de Manutençã Características da Manutençã Manutençã estruturada versus nã-estruturada Cust de Manutençã Prblemas Manutenibilidade Tarefas da Manutençã Flux de Events Cnservaçã de Registrs Avaliaçã Efeits Claterais da Manutençã de Sftware Manutençã de Códig Alienígena ReEngenharia Engenharia Reversa DICAS DE LEITURA GERÊNCIA DE PROJETOS DE SOFTWARE REGRAS BÁSICAS PARA ADMINISTRAR TECNOLOGIA DA INFORMAÇÃO SOBRE GERENCIAMENTO DE PROJETOS DE SOFTWARE ETAPAS DA GERÊNCIA DE PROJETOS PLANEJAMENTO DE PROJETO Definiçã de Planejament Objetivs d Planejament Organizaçã de Atividades Seleçã de Equipe de Prjet Fases d Planejament Iniciaçã d Prjet O Plan de Prjet Planejament Preliminar Escp Escp d Prjet x Escp d Prdut Definiçã de Escp de Prjet Estrutura Analítica de Prjet (EAP) Desenvlviment d Crngrama d Prjet Diagramas de Barras e Redes de Atividades Caminh Crític GESTÃO DE RISCOS GESTÃO DE PESSOAS Seleçã de pessal Mtivaçã de pessas Gerenciament de Grups Ambientes de trabalh

5 8.6.5 O Mdel de Maturidade de Capacitaçã de Pessal ESTIMATIVAS Sbre Estimativas Estimativas de Recurss Estimativas de Prjets Estimativas de Cust Medida de Prdutividade Técnicas de Estimativa Técnicas de Decmpsiçã Mdel Mdel Mdel Mdels Empírics de Estimativas Mdel COCOMO (COnstructive COst MOdel) Mdel COCOMO II Mdel de Pnt pr Funçã (PF) / Functin Pint (FP) PMI PROJECT MANAGEMENT INSTITUTE Pnts básics PMI O que é Gerência de Prjets - PMI As áreas de Cnheciment d PMI O Certificad PMP DICAS DE LEITURA GARANTIA E CONTROLE DE QUALIDADE INTRODUÇÃO À QUALIDADE DE SOFTWARE Principais tópics Requisits de Qualidade O prcess de sftware Garantia de qualidade de sftware DEFINIÇÕES E CONCEITOS NORMAS E MODELOS DE QUALIDADE DE PROCESSO DE SOFTWARE REVISÕES DOCUMENTAÇÃO GERÊNCIA DE CONFIGURAÇÃO MÉTRICAS E MEDIÇÃO DICAS DE LEITURA

6 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 6 1 SOFTWARE O mund precisa de sftware. [Steve Jbs, criadr d Apple II] Quand um sftware de cmputadr é bem-sucedid quand satisfaz às necessidades das pessas que usam, tem desempenh sem falhas pr um lng períd, é fácil de mdificar e ainda mais fácil de usar ele pde e efetivamente mdifica as cisas para melhr. Mas, quand sftware falha quand seus usuáris ficam insatisfeits, quand tem tendências a errs, quand é difícil de mdificar e ainda mais difícil de usar pdem e efetivamente acntecem cisas desagradáveis. Tds nós desejams cnstruir sftwares que trnem as cisas melhres, evitand s prblemas que espreitam na smbra ds esfrçs malsucedids. Para bter sucess, precisams de disciplina quand sftware é prjetad e cnstruíd. Precisams de uma abrdagem de engenharia. [Rger Pressman, 2006] As citações acima destacam a imprtância que sftware adquiriu na chamada Sciedade da Infrmaçã. Mas, cm destaca Rger Pressman (2006), nem tds defendem, também existem autres que lançaram uma série de bras cnsideradas anti-cmputadres. Para exemplificar essa situaçã pde ser dada a seguinte citaçã, de Andy Rney: Os cmputadres trnam mais fácil fazer uma série de cisas, mas a mair parte das cisas que eles facilitam nã precisa ser feita. 1.1 PANORAMA SOBRE SOFTWARE Origem: Engenharia de Sftware, Rger Pressman, O que é? Sftware de cmputadr é prdut que s prfissinais de sftware cnstrem, e depis, mantêm a lng d temp. Abrange prgramas que executam em cmputadres de qualquer tamanh e arquitetura, cnteúd que é apresentad a prgrama a ser executad e dcuments tant em frma impressa quant virtual, que cmbinam tdas as frmas de mídia eletrônica; Quem faz? Engenheirs de sftware cnstrem e mantêm, e praticamente, tdas as pessas d mund industrializad usam direta u indiretamente; Pr que é imprtante? Prque afeta praticamente tds s aspects de nssas vidas e trnu-se difundid n nss cmérci, na nssa cultura e nas nssas atividades d dia-a-dia; Quais sã s passs? Vcê cnstrói sftware de cmputadres cm cnstrói qualquer prdut bem-sucedid, aplicand um prcess ágil e adaptável que leva a um resultad de alta qualidade e que satisfaz às necessidades das pessas que vã usar prdut. Vcê aplica uma abrdagem de engenharia de sftware; Qual é prdut d trabalh? D pnt de vista d engenheir de sftware, prdut d trabalh sã s prgramas, cnteúd (s dads) e dcuments que cmpõe um sftware de cmputadr. Mas, d pnt de vista d usuári, prdut d trabalh é a infrmaçã resultante que, de algum md, trna melhr mund d usuári. 1.2 O PRODUTO DE SOFTWARE (OU SIMPLESMENTE SOFTWARE) Origem: Engenharia de Sftware, Ntas de Aula, prf. Denise Franztti Tgneri, FAESA O prdut de sftware é prdut que s engenheirs de sftware prjetam e cnstrem. Ele englba s prgramas que sã executads dentr de um cmputadr de qualquer tamanh e

7 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 7 arquitetura, s dcuments, que englbam frmuláris virtuais e material impress prduzid pr cmputadr (hard-cpy), e dads, que cmbinam númers e text, mas também incluem representações de infrmações em áudi, víde e pictóricas. O prdut de sftware (u simplesmente sftware) é cmpst de (Pressman, 2002): (1) as instruções (s prgramas de cmputadr) que quand executads frnecem a funçã e desempenh desejads; (2) as estruturas de dads que permitem as prgramas manipular as infrmações de frma adequada; (3) s dcuments que descrevem a peraçã e us ds prgramas. O prdut de sftware é cmpnente lógic de um sistema infrmatizad, e nã físic. Sã prduzids pel prcess e pelas suas atividades e servem de matéria-prima para s mesms. Pr exempl: dcument de requisits, prgrama executável. Hje, prdut de sftware tem um papel dupl. Ele é um prdut, e a mesm temp é um veícul para distribuir um prdut. Cm prdut, ele distribui ptencial cmputacinal persnificad através d hardware d cmputadr. Tant residind dentr de um telefne celular u send executad em um mainframe, prdut de sftware é um transfrmadr de infrmaçã - prduzind, gerenciand, adquirind, mdificand, exibind u transfrmand infrmaçã. Cm veícul usad para distribuir um prdut, prdut de sftware atua cm base para cntrle de cmputadres (sistemas peracinais), cmunicaçã de infrmaçã (sftwares de gerenciament de redes) e criaçã e cntrle de utrs prgramas (ambientes e ferramentas). O prdut de sftware distribui que muits acreditam ser mais imprtante prdut de sécul XXI - a infrmaçã (Pressman, 2002). 1.3 OS CUSTOS DO SOFTWARE O principal desafi nas três primeiras décadas a partir d surgiment d cmputadr, era prduzir um hardware que reduzisse cust de prcessament e armazenagem de dads. A lng da década de 80 desafi era de melhrar a qualidade (e reduzir s custs) de sluções baseadas em cmputadr. Sluções que sã implementadas cm sftware. Existe um imens ptencial industrial que pde ser melhrad através d us de nvas tecnlgias. O sftware é um ds principais mecanisms que ns pssibilita aprveitar e dar a vazã a esse ptencial. Ian Smmerville (2007) destacu seguinte sbre s custs d sftware: Os custs de sftware dminam s custs de sistemas cmputacinais. Em um PC, s custs de sftware sã frequentemente maires que cust d hardware; Manter um sftware custa mais que desenvlvê-l. Para sistemas cm uma lnga vida, s custs de manutençã pdem ser muit maires que s custs de desenvlviment; A engenharia de sftware dedica-se a desenvlviment de sftware cm custs adequads. O mesm autr prssegue, identificand s custs d sftware, apresentand que: Aprximadamente 60% ds custs sã custs de desenvlviment e 40% sã custs de testes. Para sftware sb encmenda, s custs de evluçã nrmalmente excedem s de desenvlviment; Os custs variam, dependend d tip de sistema que está send desenvlvid e ds requisits de atributs de sistema, tais cm desempenh e cnfiabilidade; A distribuiçã de custs depende d mdel de desenvlviment que é usad.

8 Disciplina: Engenharia de Sftware Matéria: Sftware Página: EVOLUÇÃO DO SOFTWARE Batch d Cnsumidr Multius Temp Real Base de Dads Prduts Distribuid Inteligentemente Hardware Barat Sistemas Ptentes Orientad a Objets Redes Neurais Cmputaçã Paralela Os primeirs ans ( Iníci ans 60) Distribuiçã limitada; Sftware custmizad; Sem dcumentaçã; Sistemas Batch; Na épca muit se sabia sbre a implementaçã de sistemas baseads em cmputadr, mas sabia-se puc sbre engenharia de sistemas de cmputadr. Segunda Era (Mei Ans Iníci Ans 70) Multi usuáris; Sistemas Interativs; Sftware Huses ( sftware era desenvlvid para ampla distribuiçã n mercad); Manutençã; Banc de dads; Temp real; Sftware cmeça a ser encarad cm prdut. Terceira Era (Mei Ans Mei Ans 80) Cmunicações digitais de largura de banda; Redes glbais e lcais; Inteligência embutida; Sistemas distribuíds; Hardware de baix cust; Impact de cnsum;

9 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 9 Crescente demanda de acess instantâne; Deslcament de cust d hardware para sftware; Ferramentas CASE; Crise de Sftware. Quarta Era (Mei Ans ) Redes Neurais Artificiais; Cmputaçã Paralela; Sistemas de desktp pderss; Tecnlgia Orientada a Objet; Sistemas Especialistas; Sistemas Hipermídia; Cmputadr na Educaçã (ITS Sistemas Tutriais Inteligentes). Quinta Era ( ) Rbtizaçã Pesada; Arquiteturas de cmputaçã radicalmente diferentes, e seu sftware crrelat exercem um prfund impact sbre equilíbri d pder plític e industrial em td mund; Sciedade da Infrmaçã. 1.5 CONCEITOS SOBRE SOFTWARE DEFINIÇÃO A definiçã mais cnhecida e aceita sbre sftware de cmputadr é aquela que indica que tal prdut é cmpst pr três itens: Prgramas de cmputadr que, quand executads, prduzem a funçã e desempenh desejads; Estruturas de dads que pssibilitam que s prgramas manipulem adequadamente a infrmaçã; Dcuments que descrevem a peraçã e us ds prgramas. Para respnder à pergunta O que é sftware? Ian Smmerville (2007) indica seguinte: Prgramas de cmputadr e dcumentaçã assciada, tais cm requisits, mdels de prjets e manuais de usuári. OBS.: Nesta definiçã nã está send destacada a Estrutura de Dads; Prduts de sftware pdem ser desenvlvids para um cliente particular u para um mercad geral, se destacand basicamente em dis grups: Genérics desenvlvids para serem vendids para uma grande variedade de clientes, pr exempl, sftwares para PC, tais cm Excel e Wrd; Persnalizads desenvlvids para um únic cliente de acrd cm as suas especificações;

10 Taxa de Falhas CEUNES / UFES Disciplina: Engenharia de Sftware Matéria: Sftware Página: 10 Um sftware nv pde ser criad através d desenvlviment de nvs prgramas, da cnfiguraçã de sistemas de sftware genérics u da reutilizaçã de um sftware existente CARACTERÍSTICAS Apesar de ser um prdut, sftware pssui uma série de características que diferencia de um prdut habitual. Entre essas características pdem ser citadas: Element de sistema lógic e nã físic; Seus custs estã cncentrads n trabalh de engenharia. Iss significa que s prjets de sftware nã pdem ser regids cm se fssem prjets de manufatura, ist é, nã é fabricad n sentid clássic; Nã é sensível as prblemas ambientais, cm crre cm hardware (e pr iss diz-se que hardware se desgasta); Sua alta qualidade é btida mediante um bm prjet; Nã existe peça de repsiçã para sftware, cm crre cm hardware; Tda falha de sftware indica um err n prjet u n prcess pr mei d qual prjet fi traduzid em códig executável pr máquina; Cm pucas exceções, nã existem catálgs de publicaçã, mas smente uma ba unidade cmpleta, sftwares nã sã cm cmpnentes que pssam ser mntads nvamente em nvs prgramas (apesar de existirem avançs em tal sentid); Sftware nã se desgasta, mas se deterira, pis durante a sua vida ele enfrentará mudanças (manutençã). Quand estas sã feitas, é prvável que nvs defeits sejam intrduzids. Essa situaçã fica melhr destacada nas figuras a seguir. Curva das Falhas d Hardware Temp

11 Taxa de Falhas Taxa das Falhas CEUNES / UFES Disciplina: Engenharia de Sftware Matéria: Sftware Página: 11 Curva Ideal das Falhas d Sftware Temp Curva Real das Falhas d Sftware Temp REUSABILIDADE A reusabilidade é uma característica imprtante de sftware de alta qualidade; Um cmpnente deve ser prjetad e implementad de frma que pssa ser reusad em muits prgramas diferentes; Na década de 60, cnstruíam-se biblitecas de sub-rtinas que reusavam algritms bem definids efetivamente, mas tinham um dmíni de aplicaçã limitad. Atualmente, ampliu-se a visã de recu a fim de envlver nã smente algritms, mas também estruturas de dads e interface; As interfaces interativas de hje frequentemente sã cnstruídas utilizand-se cmpnentes reusáveis que pssibilitam a criaçã de janelas gráficas, menus pull-dwn e uma ampla variedade de mecanisms de interaçã. As estruturas de dads e detalhes de prcessament exigids para se cnstruir a interface cm s usuáris estã cntidas numa bibliteca de cmpnentes reusáveis para cnstruçã de interfaces.

12 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 12 Observaçã: Ainda que muita cisa tenha sid escrita sbre reusabilidade de sftware, estams apenas cmeçand a ver as primeiras implementações bem-sucedidas d cnceit. 1.6 CATEGORIAS DO SOFTWARE Sftware pde ser incluíd basicamente em qualquer situaçã, desde que previamente especificad pr um algritm. Pde ser usad para diverss tips de prcesss cm, pr exempl, cntrlar uma máquina autmatizada que recebe e frnece várias infrmações e prduz cmands de máquina individuais em rápida sucessã. Nessa situaçã, prgrama só aceita dads cm uma rdem prédefinida, executa s algritms e frnece s resultads em um relatóri u em frmat gráfic, e essas aplicações sã determinadas. Nã é cm um sistema peracinal, que aceita entradas de dads sem uma rdem crnlógica e sã indeterminads. Algumas categrias de sftware que indicam tamanh das aplicações ptenciais para sftware estã a seguir destacadas. Vale destacar que existem utras classificações, e que um sftware pde se encaixar em mais de uma categria. Sftware Básic (Sftware de Sistema) Esse sftware pde ser caracterizad cm váris prgramas reunids para dar assistência a utrs prgramas, tant ns que prcessam as infrmações cmplexas e determinadas, cm s que prcessam infrmações amplamente indeterminadas; A área d sftware básic é caracterizada pr frte interaçã cm hardware de cmputadr, intens us pr múltipls usuáris, cmpartilhament de recurss e sfisticada administraçã d prcess, estruturas de dads cmplexas e múltiplas interfaces externas; Alguns exempls: Sistemas Operacinais, cmpiladres, gerenciadres de banc de dads, editres, gerenciadres de redes. Sftware Cmercial (de aplicaçã) É a mair área de aplicaçã de sftware; Cnsiste de prgramas islads que reslvem uma necessidade específica d negóci; Nesse sistema, a aplicaçã d sftware irá atuar n prcess de infrmações cmerciais. Atua nas áreas tant administrativas quant de prduçã de uma empresa, dand acess a um u mais bancs de dads cntend infrmações cmerciais; Alguns exempls: flha de pagament, cntrle de estque, administraçã de uma lja. Sftware Científic e de Engenharia Tem sid caracterizad pr algritms de prcessament de númers. Atua em diverss camps de pesquisa dentr da área científica e de engenharia. As nvas aplicações estã se afastand ds algritms numérics cnvencinais. Auxiliad pr um cmputadr, ele simula váris sistemas e utrs tips de aplicações.

13 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 13 Sftware Embutid Reside na memória só de leitura de alguns equipaments e é usad para cntrlar prduts e sistemas para s mercads industriais e de cnsum. Pde executar funções muit limitadas e particulares u ferecer recurss funcinais de cntrle significativs; Alguns exempls: Teclad para frn de micrndas, cmputadr de brd de um autmóvel. Sftware para linhas de prdut Desenvlvid para frnecer uma capacidade específica a ser utilizada pels mais variads clientes. Exempls: editres de text, planilha eletrônica, calculadra. Aplicações da Web As aplicações de cmérci eletrônic e B2B estã crescend em imprtância, que destaca a relevância das aplicações Web, que estã evluind para ambientes cmputacinais cada vez mais sfisticads e interativs. Sftware de Inteligência Artificial Faz us de algritms nã-numérics para reslver prblemas cmplexs que nã sejam favráveis à cmputaçã u à análise direta. A área mais ativa é a ds sistemas especialistas. Outras áreas de aplicaçã para sftware de AI sã: recnheciment de padrã, jgs, demnstraçã de teremas. Um simuladr de estrutura ds prcesss cerebrais, chamad redes neurais artificiais também está se destacand. O que está acima identificad é referente a apenas uma classificaçã. Outras também pdem ser cnsideradas, tend-se assim nvas categrias. Alguns exempls: sftware de temp real, sftware de cmputadr pessal. 1.7 SOFTWARE LEGADO Um sftware legad é um sftware mais velh, prém que permanece vital para bm andament das atividades de uma empresa. Dad seu grau de imprtância, tal sistema, mesm send antig, cntinua send amplamente utilizad, recebend manutenções, prém sem ser trcad / migrad. E as nvas aquisições de sftware da empresa precisam ser integradas a este sftware legad. Cnfrme destacu Rger Pressman (2006) um sftware legad é caracterizad pr lngevidade e criticalidade para negóci. O mesm autr ainda destaca que talvez seja mair prblema deste tip de sftware: a má qualidade. Sistemas legads, algumas vezes, têm prjets nã extensíveis, códig cmplicad, dcumentaçã pbre u inexistente, cass de teste e resultads que nunca fram arquivads, um históric de mdificações mal gerad... Prém nã pde deixar de ser cmentad que, se sftware cntinuar em us e atendend as necessidades d cliente entã ele nã está danificad e nã precisa ser cnsertad.

14 Disciplina: Engenharia de Sftware Matéria: Sftware Página: PROBLEMAS COM SOFTWARES E SUAS CAUSAS N cmeç: Os sistemas baseads em cmputadres eram desenvlvids para a área de hardware, pis estes eram mair item de rçament particular d desenvlviment d sistema. Para ver cust d hardware s gerentes instituíram frmas e padrões técnics e exigiam análises d prjet antes que alg fsse cnstruíd visand sempre melhrias; O desenvlviment d sftware era vist cm uma frma de arte, havia pucs métds e pucas pessas usavam, send que muits pr tentativas e errs. O palavread era um grande desafi e muit indisciplinad. A medida que temp passu, cnfrme destacu Pressman (2006) sftware trnu-se fatr dminante na ecnmia d mund industrializad. A figura d prgramadr slitári d iníci da cmputaçã fi substituída pr equipes de desenvlviment de sistemas, cm várias especialidades cmplementares. N entant, algumas das questões que prgramadr slitári fazia cntinuam send feitas pela equipe mderna. Entre essas questões pde-se citar: Pr que demra tant temp para que s sftwares sejam cncluíds? Pr que s custs sã tã elevads? Pr que nã sã descberts tds s errs antes da entrega d sftware as clientes? Pr que se gasta tant temp e esfrç para realizar manutençã ns sftwares? Pr que tems dificuldade em medir prgress enquant sftware está send desenvlvid? PROBLEMAS ENFRENTADOS PELOS DESENVOLVEDORES DE SOFTWARE Cnfrme destacu Rger Pressman (2006):... as pessas apstam seus empregs, sua segurança e suas próprias vidas em sftwares de cmputadr. É melhr que esteja crret.. Ou seja, a respnsabilidade que desenvlvedr de sftware tem é enrme. N entant, uma série de prblemas sã enfrentads para que tal prfissinal pssa realizar suas tarefas, e entre esses prblemas pdem ser destacads: A sfisticaçã d hardware ultrapassu nssa capacidade de cnstruir um sftware que extraia td ptencial d hardware; Nssa capacidade de cnstruir prgramas nã pde acmpanhar ritm da demanda de nvs prgramas; Nssa capacidade de manter s prgramas existentes é ameaçada pr prjets ruins e recurss inadequads. 1.9 MITOS DO SOFTWARE O que é um mit? Parecem ser infrmações verdadeiras, razáveis, mas nã sã; Infrmações criadas para prpagar cnfusã em pessas desinfrmadas d assunt; Atitudes engansas que têm causad séris prblemas para usuáris dméstics, gerentes e técnics.

15 Disciplina: Engenharia de Sftware Matéria: Sftware Página: 15 Tips de Mits: 1. Administrativs 2. D Cliente 3. D Prfissinal Mits Administrativs Os Gerentes que têm respnsabilidade pel sftware frequentemente se encntram sb pressã para manter rçament e melhrar a qualidade. Tais gerentes muitas vezes se agarram a uma crença de um mit de sftware cas esse mit atenue, mesm que temprariamente, a pressã que pesa sbre ele. Alguns exempls de mits: Pssuíms nrmas, entã está tud cntrlad; Pssuíms as melhres máquinas e ferramentas entã terems qualidade; Pdems sempre cntratar mais pessas para cntrlar atras n prjet; Cm prjet está terceirizad, entã terceir é respnsável pr ele. Mits d Cliente O cliente que exige um sftware acha que este pde ser elabrad pr uma pessa qualquer, e em muits cass, cliente acredita ns mits sbre sftware, prque nrmalmente s prfissinais respnsáveis puc fazem para crrigir a desinfrmaçã. Os mits levam a falsas expectativas (pr parte d cliente), e levam a insatisfaçã cm desenvlvedr. Alguns exempls pdem ser: Basta definir em geral s requisits ds prcesss para que desenvlvedr saiba que é precis; Sftware deve ser flexível, prtant mudanças pdem ser facilmente acmdadas. Mits d Prfissinal Muits mits merecem crédit ds prfissinais de sftware até hje, send que fram sustentads pr décadas de cultura de prgramaçã. Durante s primórdis d sftware, a prgramaçã era vista cm frma de arte, e cm velhas maneiras e atitudes demrar a serem superadas, ainda hje existem esses mits. Alguns exempls que se destacam sã: Quand um prgrama funcina está prnt; Enquant prgrama nã estiver rdand nã pss avaliar a qualidade d mesm; Só se deve entregar prgrama executável utilizad; Cm us de Engenharia de Sftware vai-se criar uma dcumentaçã vlumsa e desnecessária, que causa atras.

16 Disciplina: Engenharia de Sftware Matéria: Sftware Página: LEITURA RECOMENDADA PRESSMAN, Rger. Engenharia de sftware Makrn Bks. Capítul 1 Sftware e Engenharia de Sftware. Frnece uma idéia de cm era há alguns ans atrás; PRESSMAN, Rger. Engenharia de sftware McGraw-Hill. Capítul 1 Sftware e Engenharia de Sftware; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 1 Uma intrduçã à engenharia de sftware; Mits da Tecnlgia: O que é Sftware? Blg d Prf. Jair C Leite, UFRN:

17 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 17 2 ENGENHARIA DE SOFTWARE Assuma a respnsabilidade pel sftware que vcê prduz. Identifique seu cliente e suas necessidades; pense nelas em terms de entradas e saídas. Pesquise que já fi feit. Mantenha cntrle intelectual ds seus esfrçs e dcumente aquil que faz. Quand um prblema fr muit difícil, divida-, sempre tentand manter fc. E quand vcê tiver feit tud direitinh, virã às mudanças; prtant, esteja prnt para elas. [Dick Hamlet & Je Maybee, em "The Engineering f Sftware"] Apesar de gerentes e prfissinais recnhecerem a necessidade de uma abrdagem mais disciplinada para sftware, eles cntinuam a debater a frma pela qual essa disciplina deve ser aplicada. Muits indivídus e empresas ainda desenvlvem sftware a acas, mesm quand cnstrem sistemas para servir às tecnlgias mais avançadas da atualidade. Muits prfissinais e estudantes descnhecem s métds mderns. Em decrrência diss, a qualidade d sftware que prduzims é sfrível e cisas ruins acntecem. Além diss, cntinua debate e a cntrvérsia sbre a verdadeira natureza da abrdagem de engenharia de sftware. O estad atual da engenharia de sftware é um estud de cntrastes. As atitudes mudaram, huve prgress, mas muit resta a ser feit antes que a disciplina alcance maturidade ttal. [Rger Pressman, 2006] 2.1 ALGUMAS DEFINIÇÕES Nã existe um cnsens sbre uma única definiçã para a disciplina de Engenharia de Sftware e, prtant, várias sã aceitas. Algumas estã abaix identificadas. A definiçã mais cnhecida de Engenharia de Sftware fi prpsta pr Fritz Bauer na primeira grande cnferência [NAU69] dedicada a assunt: O estabeleciment e us de sólids princípis de engenharia para que se pssa bter ecnmicamente um sftware que seja cnfiável e que funcine eficientemente em máquinas reais. Uma segunda definiçã que vale a pena destacar é aquela apresentada pel IEEE, cnfrme citu Pressman (2006). Engenharia de Sftware é: (1) aplicaçã de uma abrdagem sistemática, disciplinada e quantificável, para desenvlviment, peraçã e manutençã d sftware, ist é, a aplicaçã da engenharia a sftware. (2) O estud de abrdagens cm as de (1). Pressman (2006) destaca ainda que a Engenharia de Sftware é uma tecnlgia em camadas, que tem cm base a qualidade, se alicerça em prcess, dispõe de métds que frnecem a técnica de cm fazer e utiliza api autmatizad de ferramentas. Iss está representad na figura abaix.

18 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: OBJETIVOS DA ENGENHARIA DE SOFTWARE Pdem ser destacads s seguintes bjetivs para a Engenharia de Sftware: Aplicaçã de teria, mdels, frmalisms, técnicas e ferramentas da ciência da cmputaçã e áreas afins para desenvlviment sistemátic de sftware; Aplicaçã de métds, técnicas e ferramentas para gerenciament d prcess de desenvlviment; Prduçã de dcumentaçã frmal / semi-frmal destinada à cmunicaçã entre s membrs da equipe de desenvlviment, bem cm as clientes e usuáris. 2.3 DIFERENÇAS Entre Engenharia de Sftware e Ciência da Cmputaçã Ciência da Cmputaçã abrda as terias e fundaments; Engenharia de Sftware está interessada ns aspects prátics de desenvlver e entregar n praz um sftware de qualidade. Entre Engenharia de Sftware e Engenharia de Sistemas A Engenharia de Sistemas está interessada em tds s aspects de um sistema basead em cmputadr, incluind hardware, sftware, fatres humans, infrmaçã e prcess; A Engenharia de Sftware é parte dela. 2.4 RESPONSABILIDADE PROFISSIONAL E ÉTICA Cnfrme destacu Smmervile (2006): Cmprtament étic significa mais d que respeitar a lei. A Engenharia de Sftware envlve respnsabilidades mais abrangentes d que simplesmente a aplicaçã de habilidades técnicas. Os engenheirs devem se cmprtar de uma frma hnesta e eticamente respnsável se eles pretendem ser respeitads cm prfissinais. Algumas questões de respnsabilidade prfissinal: Cnfidencialidade - Os engenheirs devem respeitar a cnfidencialidade de seus funcináris e/u clientes, independente de ter u nã assinad um acrd frmal; Cmpetência - Os engenheirs nã devem desvirtuar seu nível de cmpetência. Eles nã devem cnscientemente aceitar um trabalh que esteja fra de sua cmpetência; Direits sbre prpriedade intelectual - Os engenheirs devem estar cientes das leis que regem us de prpriedade intelectual, tais cm patentes, direits autrais, etc. Eles devem tmar cuidad para assegurar que a prpriedade intelectual ds funcináris e clientes seja prtegida; Mau us de cmputadres - Os engenheirs de sftware nã devem usar as suas habilidades técnicas para fazer mau us ds cmputadres. O mau us de cmputadres varia desde relativamente trivial (execuçã de jgs na máquina d funcinári, pr exempl) até extremamente séri (disseminaçã de vírus).

19 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 19 Destacand a imprtância que tal assunt tem ganhad, uma série de instituições trabalham n sentid de apresentar Códigs de Ética para s prfissinais de Cmputaçã. Um ds mais cnhecids é d ACM/IEEE, que cnsta de it princípis étics: PÚBLICO - Os engenheirs de sftware devem agir cnsistentemente cm interesse públic; CLIENTE E EMPREGADOR - Os engenheirs de sftware devem agir dentr ds melhres interesses d seu cliente e empregadr, de frma cnsistente cm interesse públic; PRODUTO - Os engenheirs de sftware devem assegurar que seus prduts e as mdificações a eles relacinadas atendam as mais alts padrões prfissinais pssíveis; JULGAMENTO - Os engenheirs de sftware devem manter integridade e independência n seu julgament prfissinal; GERENCIAMENTO - Os gerentes e líderes de engenharia de sftware devem cntribuir e prmver uma abrdagem ética para gerenciament de desenvlviment e manutençã de sftware; PROFISSÃO - Os engenheirs de sftware devem prmver a integridade e a reputaçã da prfissã de frma cnsistente cm interesse públic; COLEGAS - Os engenheirs de sftware devem ser hnests e clabrativs cm seus clegas; INDIVÍDUO - Os engenheirs de sftware devem participar, a lng da vida, aprendend, respeitand e prmvend uma abrdagem ética na prática da prfissã. A lng de sua vida prfissinal um engenheir de sftware pde se ver envlvid em diverss dilemas étics, e ter um guia, cm um códig de ética, pde auxiliar na decisã que irá tmar frente a tal dilema. 2.5 OS ATRIBUTOS DE UM BOM SOFTWARE Ian Smmerville (2007) ressalta s seguintes atributs para um bm sftware: O sftware deve frnecer a funcinalidade e desempenh requerids para usuári e deve ser manutenível, cnfiável e aceitável; Facilidade de manutençã - O sftware deve evluir para atender às necessidades de mudança; Cnfiança - O sftware deve ser cnfiável; Eficiência - O sftware nã deve desperdiçar s recurss d sistema; Usabilidade - O sftware deve ser bem-aceit pels usuáris para qual fi prjetad. Iss significa que ele deve ser cmpreensível, usável e cmpatível cm utrs sistemas.

20 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: ASPECTOS HISTÓRICOS Origem: Engenharia de Sftware, Ntas de Aula, Prf. Antôni Maria Pereira de Resende, UFLA Alguns ajustes NOS PRIMÓRDIOS O desenvlviment de sftware era puramente artesanal; Os desenvlvedres de sistemas erravam cnstantemente nas suas estimativas de cust e temp; Os sistemas cntinham muits errs; Cnsertar errs geralmente prduzia mais errs; Sistemas crescend a base de remends mal feits; Estud feit em 1979 pel gvern ds Estads Unids em relaçã a sftware prduzid indicu sbre tal prdut: 2% funcinava; 3% funcinaria cm pucas crreções; 45% entregues, mas nunca fram usads cm sucess; 20% usads, mas tremendamente mdificads u abandnads; 30% pags, mas nunca fram terminads e/u entregues. Estud feit em 2009 pel Standish Grup em relaçã a sftware prduzid indicu sbre tal prdut: Aprximadamente 18% ds prjets sã cancelads pr atrass e rçaments esturads; Aprximadamente 52% ds prjets esturam rçament e/u praz; Aprximadamente 30% de tds s prjets de TI atingem seus bjetivs dentr de praz e cust estimads A CRISE DE SOFTWARE O que se trnu destacad cm a ppularizaçã d sftware: A inexistência u nã aplicaçã de métds, prcediments e ferramentas capazes de auxiliar e nrmatizar prcess de desenvlviment causa prejuízs cm s descrits acima; Após as estatísticas levantadas pel gvern ds EUA (antes ds ans 80) e verificar-se tantas perdas, chegu-se a cnsens da necessidade de desenvlver-se métds, técnicas e ferramentas capazes de auxiliar n desenvlviment metódic de sftware e cnsequentemente reduzir as perdas; Desde a década de 60 uma crise acmpanha a indústria de sftware. A crise é questinável quand bserva-se significad da palavra. Crise quer dizer um pnt decisiv n curs de alg, mment, etapa u event decisiv u crucial. Nã huve crise na área de sftware apenas uma cntínua mudança, lenta e evlucinária; Métds de desenvlviment de sftware existentes nã sã bns bastante para desenvlviment de sftware de grande prte;

21 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 21 N mment nã se cnhece uma cura para esta crise, apenas paliativs para reduzir s impacts muit desastrss; Os principais prblemas que envlvem a Crise de Sftware sã: As estimativas de praz e de cust frequentemente sã imprecisas; A prdutividade das pessas da área de sftware nã tem acmpanhad a demanda pr seus serviçs; A qualidade de sftware, às vezes, é menr d que a adequada; Dificuldade de manutençã; Nã é dedicad temp para cletar dads sbre prblema a ser reslvid; A insatisfaçã cm sistema cncluíd crre muit frequentemente. Há falha de cmunicaçã; Os cmputadres estã cada vez mais rápids, sfisticads e barats. Ist gera uma demanda cada vez mair de sftware. Pr sua vez, s sftwares estã cada vez maires e mais sfisticads, e a prdutividade nã acmpanha a demanda; Dentre as principais causas ds prblemas que envlvem a Crise de Sftware pde-se citar: Dedica-se puc temp à cleta de dads (requisits ds clientes u especificaçã de requisits). Nrmalmente apenas um subcnjunt das necessidades reais d cliente é levad em cnta. Os prfissinais estã sempre cm muita pressa para cmeçar a prgramar e esquecem que planejar é imprtante; A qualidade geralmente é suspeita prque testes sistemátics e tecnicamente cmplets raramente sã feits. Nrmas, mdels e padrões de qualidade sã deixads de lad. A cncrrência cm sftware barat, mas sem qualidade, feit pr pessas sem qualificaçã adequada é muit grande. O cliente leig infelizmente nã sabe quais s fatres devem ser cnsiderads e, prtant, lha apenas preç; Nã há muit interesse em se gastar temp para se entender mais a respeit de estimativas, prdutividade, precisã e eficácia de nvs métds e nvas ferramentas, etc; A resistência a mudanças é grande. Muits ainda acham que desenvlver um sistema é uma arte pessal e nã aplicam s devids métds, técnicas e ferramentas; Cm sftware é um element lógic, iss trna um desafi para as pessas que desenvlvem; Pessas desqualificadas recebem a respnsabilidade pel desenvlviment d prjet. Os prblemas ds dias atuais estã cncentrads principalmente na imensa demanda de nvas aplicações e a desenvlviment de técnicas que pssam suprir essa demanda. A criaçã dessas técnicas faz surgir utr prblema: capacidade de manter esses sftwares. Smmerville (2007) destaca s seguintes prblemas, cm send desafis-chaves da área: Hetergeneidade - Técnicas de desenvlviment para cnstruçã de sftware que pdem lidar cm ambientes hetergênes; Entrega - Técnicas de desenvlviment para cnduzir a entrega mais rápida de sftware; Cnfiança - Técnicas de desenvlviment que mstram que sftware pde ter a cnfiança ds seus usuáris.

22 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 22 Existe sluçã para essa crise? Algumas pssibilidades sã: A esclha e us das melhres e mais adequadas técnicas, métds e ferramentas; Mais treinament as funcináris envlvids n prcess. Atualmente se investe muit puc nesta linha, prém quadr vem mudand lentamente. 2.7 PRINCÍPIOS DA ENGENHARIA DE SOFTWARE A fim de nrtear seu desenvlviment e evluçã, a Engenharia de Sftware adta alguns princípis. Entre eles: Frmalidade Trabalhar de maneira sistemática, btend prduts mais cnfiáveis, cntrle de cust e mais cnfiança n desempenh d sftware; Abstraçã Identificar s aspects imprtantes, ignrand s detalhes; Decmpsiçã Dividir prcess em atividades específicas, atribuídas a diferentes especialistas; Generalizaçã Send mais geral é bem pssível que a sluçã pssa ser reutilizada; Flexibilizaçã Mdificaçã cm facilidade. 2.8 OS ELEMENTOS FUNDAMENTAIS DA ENGENHARIA DE SOFTWARE MÉTODOS Cm cnstruir sftware. Envlvem um ampl cnjunt de tarefas que incluem: planejament e estimativa de prjet, análise de requisits de sftware e de sistema, design da estrutura de dads, arquitetura e algritms de prcessament, cdificaçã, testes e manutençã. FERRAMENTAS Suprte (semi-)autmatizad as métds. Prprcinam api autmatizad u semi-autmatizad as métds. Atualmente existem ferramentas para sustentar cada um ds métds citads anterirmente. Ferramentas CASE (Cmputer Aided Sftware Engineering). Sftware cuj bjetiv é frnecer api autmatizad as atividades d prcess de sftware. Exempls: MS-Prject Ratinal Rse Pwer Designer PROCEDIMENTO Sequência de aplicaçã ds métds. Definem a sequência em que s métds serã aplicads, sã el de ligaçã que mantém junts s métds e as ferramentas e pssibilita desenvlviment racinal e prtun de sftware de cmputadr.

23 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: PARADIGMAS DA ENGENHARIA DE SOFTWARE A Engenharia de Sftware cmpreende um cnjunt de atividades que envlvem métds, ferramentas e prcediments. Essas atividades pdem ser executadas em diferentes sequências e agrupadas em diferentes etapas. Os cnjunts de regras que definem essas etapas e sequências sã chamads de paradigmas da engenharia de sftware. Para se esclher entre um u utr paradigma devem ser levads em cnsideraçã diverss fatres, entre eles: Prcess de desenvlviment a ser adtad; Tip de aplicaçã a ser desenvlvida (natureza d prjet); Métds e ferramentas a serem utilizads; Cntrles e prduts que precisam ser entregues; Expectativas d cliente. Origem: a%22+%22engenharia+de+sftware%22&hl=pt-br&ct=clnk&cd=10&gl=br Pde-se cnsiderar 3 tips de paradigmas que nrteiam a atividade de desenvlviment de sftware: Desenvlviment de sftware cm um artesanat: prjetista é um artesã. As diversas legislações sbre sftware de váris países cnsiderand sftware prtegid pela lei de direit autral pdem ser vistas nesse cntext; Métds que auxiliam desenvlviment de sftware nã fazem muit sentid aqui; Prgramas sã bras pessais ; Quand se cnsidera grandes sistemas desenvlvids em ambientes industriais, trna-se (n mínim) inadequad esse paradigma. Matemática cm mdel de desenvlviment de sftware. Um prgrama é um algritm escrit em uma linguagem; Desenvlver algritms é reslver prblemas, que é uma atividade básica da matemática; Prtant, desenvlver sftware é uma atividade intelectual muit próxima da matemática; Us de métds frmais em td cicl de desenvlviment de sftware. Desenvlviment de sftware cm engenharia. Leva à abrdagem empírica; A pesquisa está na busca de métds e técnicas que aprximem a máxim prcess de desenvlviment de sftware d desenvlviment das características de prduts em áreas tradicinais de engenharia; A precupaçã em se cnseguir visualizar prdut de sftware já nas fases iniciais de desenvlviment é um resultad da aplicaçã desse paradigma. A tendência em buscar paradigmas em utras áreas de cnheciment é natural, dada a tenra idade da cmputaçã. À medida que se cria um prdut, sistema d qual sftware faz parte, que será usad e mantid, ns aprximams da engenharia.

24 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 24 À medida que esse prdut nã tem a slidez de uma máquina u bra civil, ns afastams da engenharia e ns aprximams de sua analgia cm uma bra intelectual, de autria. Pde-se dizer que prcess de desenvlviment de sftware é um nv híbrid desses paradigmas. Esse prcess, chamad de engenharia de sftware, é uma disciplina que englba métds, ferramentas e técnicas para desenvlviment de sftware OS MÉTODOS ADOTADOS PELA ENGENHARIA DE SOFTWARE Ian Smmerville (2007) cmenta sbre s métds que a Engenharia de Sftware prcura adtar: Abrdagens estruturadas para desenvlviment de sftware que incluem mdels de sistema, ntações, regras, recmendações de prjet e guia de prcess. Descrições de mdel de sistema - Descrições de mdels gráfics que devem ser prduzids; Regras - Restrições aplicadas as mdels de sistema; Recmendações - Recmendações de bas práticas de prjet; Guia de prcess - Quais atividades devem ser seguidas FASES DA ENGENHARIA DETALHANDO... Origem: Existem várias prpstas e denminações para as fases d cicl de vida de um sftware. Nssa prpsta identifica 4 fases que sã delimitadas pr events típics em diverss cicls de vida. Cada fase inclui um cnjunt de atividades u disciplinas que devem ser realizadas pelas partes envlvidas. Essas fases sã: Definiçã; Desenvlviment; Operaçã; Retirada. Fase de Definiçã A fase de definiçã d sftware crre em cnjunt cm utras atividades cm a mdelagem de prcesss de negócis e análise de sistemas. Nesta atividade, diverss prfissinais buscam cnheciment da situaçã atual e a identificaçã de prblemas para que pssam elabrar prpstas de sluçã de sistemas cmputacinais que reslvam tais prblemas. Dentre as prpstas apresentadas, deve-se fazer um estud de viabilidade, incluind análise cust-benefíci, para se decidir qual sluçã será esclhida. O resultad desta atividade deve incluir a decisã da aquisiçã u desenvlviment d sistema, indicand infrmações sbre hardware, sftware, pessal, prcediments, infrmaçã e dcumentaçã. Cas seja decidid pel desenvlviment d sistema, n escp da engenharia de sftware, é necessári elabrar dcument de prpsta de desenvlviment de sftware. Esse dcument pde ser a base de um cntrat de desenvlviment. Prfissinais de engenharia de sftware atuam nesta atividade cm bjetiv de identificar s requisits de sftware e mdels de dmíni que serã utilizads na fase de desenvlviment. Os

25 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 25 requisits sã também fundamentais para que engenheir pssa elabrar um plan de desenvlviment de sftware, indicand em detalhes s recurss necessáris (humans e materiais), bem cm as estimativas de prazs e custs (crngrama e rçament). Nã existe um cnsens sbre que caracteriza final da fase de definiçã. Ist varia de acrd cm mdel de prcess adtad. Em algumas prpstas, a fase de definiçã é cnsiderada cncluída cm a apresentaçã da prpsta de desenvlviment apenas. Outrs mdels de prcess cnsideram que prcess apenas está cmpletamente definid cm a especificaçã de requisits e cm a elabraçã d plan de desenvlviment de sftware. De acrd cm mdel de prcess adtad, pde-se iniciar atividades da fase de desenvlviment mesm que a fase de definiçã nã esteja cmpletamente cncluída. Fase de Desenvlviment A fase de desenvlviment u de prduçã d sftware inclui tdas as atividades que tem pr bjetiv a cnstruçã d prdut. Ela inclui principalmente design, a implementaçã e a verificaçã e validaçã d sftware. Design A atividade de design cmpreende td esfrç de cncepçã e mdelagem que têm pr bjetiv descrever cm sftware será implementad. O design inclui: Design cnceitual; Design da interface de usuári; Design da arquitetura d sftware; Design ds algritms e estruturas de dads. O design cnceitual envlve a elabraçã das idéias e cnceits básics que determinam s elements fundamentais d sftware em questã. Pr exempl, um sftware de crrei eletrônic tradicinal inclui s cnceits: mensagem, caixa de entrada, caixa de saída, etc. A mensagem, pr sua vez, inclui s cnceits de para, cc, bcc, assunt, crp, etc. Embra seja um design adtad pela mairia ds sftwares, nvs mdels cnceituais pdem vir a ser adtads. O cnceit de cnversaçã d Gmail é um exempl. O design cnceitual exerce influência na interface de usuári e na arquitetura d sftware. O design da interface de usuári envlve a elabraçã da maneira cm usuári pde interagir para realizar suas tarefas, a esclha ds bjets de interfaces (btões, menus, caixas de text, etc.), layut de janelas e telas, etc. A interface deve garantir a ba usabilidade d sftware e é um fundamental fatr de sucess d sftware. O design de arquitetura de sftware deve elabrar uma visã macrscópica d sftware em terms de cmpnentes que interagem entre si. O cnceit de cmpnente em arquitetura varia de acrd cm a visã arquitetônica adtada. Sã exempls de visões arquitetônicas, a visã cnceitual, visã de móduls, visã de códig e visã de execuçã. Na visã cnceitual, s cmpnentes de sftware sã derivads d design cnceitual. Estes cmpnentes sã abstrações que devem definir utrs elements mens abstrats. Exempls sã arquiteturas cliente-servidr e arquitetura em camadas. Na visã de códig, deve-se determinar cm as classes e/u funções estã rganizadas e interagind entre si. Estas classes implementam s cmpnentes abstrats u cnceituais. Na visã de móduls, deve-se determinar quais sã s móduls que serã utilizads na implementaçã e cm eles rganizam as classes e/u funções. Na visã de execuçã, a arquitetura deve descrever s diferentes prcesss que sã ativads durante a execuçã d sftware e cm eles interagem entre si. Enquant as anterires ferecem uma visã estática, esta é uma visã dinâmica d sftware. O design de algritms e estrutura de dads, também cnhecid cm design detalhad, visa determinar, de maneira independente da linguagem de prgramaçã adtada, as sluções algrítmicas e as estruturas de dads assciadas. Deve-se decidir, pr exempl, cm as infrmações pdem ser rdenadas (algritm de blha u quicksrt) e em qual tip de estrutura de dads (array, lista encadeada) elas vã ser armazenadas.

26 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 26 Implementaçã A implementaçã envlve as atividades de cdificaçã, cmpilaçã, integraçã e testes. A cdificaçã visa traduzir design num prgrama, utilizand linguagens e ferramentas adequadas. A cdificaçã deve refletir a estrutura e cmprtament descrits n design. Os cmpnentes arquiteturais devem ser cdificads de frma independente e depis integrads. Os testes pdem ser iniciads durante a fase de implementaçã. A depuraçã de errs crre durante a prgramaçã utilizand algumas técnicas e ferramentas. É fundamental um cntrle e gerenciament de versões para que se tenha um cntrle crret de tud que está send cdificad. Verificaçã e validaçã Verificaçã e validaçã destinam-se a mstrar que sistema está de acrd cm a especificaçã e que ele atende às expectativas de clientes e usuáris. A validaçã visa assegurar se prgrama está fazend aquil que fi definid na sua especificaçã (fazend a cisa certa). A verificaçã visa verificar se prgrama está crret, ist é, nã pssui errs de execuçã (fazend cert a cisa). Existem diferentes frmas de verificaçã e validaçã. Inspeçã analítica e revisã de mdels, dcuments e códig-fnte sã frmas que pdem ser usadas antes mesm que prgrama seja cmpletamente cdificad. Os testes de crreçã, desempenh, cnfiabilidade, rbustez, usabilidade, dentre utrs, visam avaliar diverss fatres de qualidade a partir da execuçã d sftware. Diferentes técnicas de testes pdem ser aplicadas para cada um destes fatres. Fase de Operaçã A fase de peraçã envlve diferentes tips de atividades: Distribuiçã e entrega; Instalaçã e cnfiguraçã; Utilizaçã; Manutençã. A distribuiçã e entrega pde ser feita diretamente pel desenvlvedr (em cas de sftware persnalizad), u em um pacte a ser vendid em prateleiras de ljas u para ser baixad pela Internet (em cas de sftware genéric). O prcess de instalaçã e cnfiguraçã, nrmalmente, pde ser feit cm a ajuda de sftware de instalaçã dispnibilizad pels fabricantes ds ambientes peracinais. A atividade de utilizaçã é bjet d desenvlviment d sftware. A qualidade da utilizaçã é a usabilidade d sftware. A manutençã nrmalmente crre de duas frmas: crretiva e evlutiva. A manutençã crretiva visa a resluçã de prblemas referentes à qualidade d sftware (falhas, baix desempenh, baixa usabilidade, falta de cnfiabilidade, etc.). A manutençã evlutiva u adaptativa visa à prduçã de nvas versões d sftware de frma a atender a nvs requisits ds clientes, u adaptar-se às nvas tecnlgias que surgem (hardware, platafrmas peracinais, linguagens, etc). Mudanças n dmíni de aplicaçã implicam em nvs requisits e incrpraçã de nvas funcinalidades. Surgiment de nvas tecnlgias de sftware e hardware e mudanças para uma platafrma mais avançada também requerem evluçã. Fase de retirada A fase de retirada é um grande desafi para s temps atuais. Diverss sftwares que estã em funcinament em empresas pssuem excelentes níveis de cnfiabilidade e de crreçã. N entant, eles precisam evluir para nvas platafrmas peracinais u para a incrpraçã de nvs requisits. A retirada desses sftwares legads em uma empresa é sempre uma decisã difícil: cm abrir mã daquil que é cnfiável e a qual s funcináris estã acstumads, após ans de treinament e utilizaçã?

27 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: 27 Prcesss de reengenharia pdem ser aplicads para viabilizar a transiçã u migraçã de um sftware legad para um nv sftware de frma a prprcinar uma retirada mais suave RESUMINDO... Fase de Definiçã = Fc n QUE Deve-se analisar s requisits, recurss e restrições para Apresentar prpstas iniciais de sluções; Estudar a viabilidade; Planejar e gerenciar desenvlviment; Realizada a partir de estimativas e análise de riscs que se utilizam de métricas; Etapas: Análise / Especificaçã d Sistema; Planejament d Prjet de Sftware (Estud de viabilidade, estimativas); Análise de Requisits; Esta fase encerra-se cm cntrat de desenvlviment. Fase de Desenvlviment = Fc n COMO Etapas: Design de Sftware - Design cnceitual, design da interface de usuári, design da arquitetura de sftware, design de algritms e estruturas de dads; Cdificaçã / Implementaçã e integraçã - Cdificaçã, cmpilaçã, integraçã e verificaçã de prgramas (testes, inspeçã, depuraçã); Validaçã da qualidade - Testes beta, avaliaçã de usabilidade, avaliaçã de desempenh, etc. Fase de Operaçã A utilizaçã d sftware; Distribuiçã e entrega; Instalaçã e cnfiguraçã; Utilizaçã e administraçã; Manutençã = Fc na TROCA (crreções e melhrias). Crretiva crreçã de errs; Evlutiva u adaptativa nvas versões. Nvs requisits; Nvas situações de peraçã hardware, sistemas peracinais. Fase de Retirada Parand de usar sftware. Migraçã; ReEngenharia; Engenharia Reversa.

28 Disciplina: Engenharia de Sftware Matéria: Engenharia de Sftware Página: LEITURA RECOMENDADA PRESSMAN, Rger. Engenharia de sftware Makrn Bks. Capítul 1 Sftware e Engenharia de Sftware; PRESSMAN, Rger. Engenharia de sftware McGraw Hill. Capítul 2 Prcess: Uma visã Genérica; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 1 Uma intrduçã à engenharia de sftware; PÁDUA FILHO, Wilsn. Engenharia de Sftware: Fundaments, Métds e Padrões LTC. Capítul 1 - Engenharia de Sftware; Ntas de Aula Princípis da Engenharia de Sftware. Link: ULBRA-Engenharia/ULBRA-ENGENHARIA pdf; Ntas de Aula Engenharia de Sftware, prf. Ricard Falb. Link: Text sbre a situaçã atual de prjets de sistema (indicaçã de André de Matts Ferraz):

29 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 29 3 O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE É mais fácil escrever um prgrama incrret d que entender um crret. [Alan Perlis] Um prcess define quem está fazend quê, quand e cm para alcançar um cert bjetiv. [Ivar Jacbsn, Grady Bch e James Rumbaugh] Se prcess fr frac, prdut final sfrerá inevitavelmente, mas uma ênfase exagerada n prcess também é perigsa. [Rger Pressman, 2006] 3.1 PANORAMA SOBRE PROCESSO DE SOFTWARE Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? Quand vcê elabra um prdut u sistema é imprtante percrrer uma série de passs previsíveis um rteir que ajuda a criar a temp um resultad de alta qualidade. O rteir que vcê segue é chamad de Prcess de Sftware; Quem faz? Os engenheirs de sftware e seus gerentes adaptam prcess a suas necessidades e depis seguem. Além diss, pessal que slicitu sftware tem um papel a desempenhar n prcess de definí-l, cnstruí-l e testá-l; Pr que é imprtante? Prque frnece estabilidade, cntrle e rganizaçã para uma atividade que pde, se deixada sem cntrle, trnar-se bastante caótica. N entant, uma abrdagem mderna de engenharia de sftware precisa ser ágil. Precisa exigir apenas aquelas atividades, cntrles e dcumentaçã adequads à equipe de prjet e a prdut que deve ser prduzid; Quais sã s passs? Em nível de detalhe, prcess adtad depende d sftware que vcê está cnstruind. Um prcess pderia ser aprpriad à criaçã de sftwares para sistema de aviônica de uma aernave, enquant um prcess inteiramente diferente seria indicad para a criaçã de um site; Qual é prdut d trabalh? D pnt de vista de um engenheir de sftware, s prduts d trabalh sã s prgramas, dcuments e dads prduzids em cnsequência das atividades e tarefas definidas pel prcess; Cm tenh certeza de que fiz crretamente? Existem diverss mecanisms de avaliaçã d prcess de sftware que permitem às rganizações determinar a maturidade d seu prcess de sftware. Tdavia, a qualidade, pntualidade e viabilidade a lng praz d prdut que vcê cnstrói sã s melhres indicadres da eficácia d prcess usad. 3.2 O QUE É PROCESSO? Sbre Prcess de Sftware, Shari L. Pfleeger (2004) destaca s seguintes itens: Cnjunt de tarefas rdenadas; Uma série de etapas que envlvem atividades, restrições e recurss para alcançar a saída desejada; Quand envlve a elabraçã de um prdut, pdems chamar de Cicl de Vida;

30 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 30 Descreve a vida d prdut de sftware desde a cncepçã até a implementaçã, entrega, utilizaçã e manutençã. Há autres que defendem, n entant, que cicl de vida é uma parte de um prcess de desenvlviment de sftware, fcad nas atividades e na sequência em que elas devem ser executadas. E que prcess apresenta utrs itens, cm ferramentas e pessal envlvid. Cnsiderand a farta variedade de prblemas que pdem ser reslvids através da elabraçã de um sftware, diferentes prcesss de desenvlviment pdem ser aplicads. Para cntemplar essa situaçã, diferentes Mdels de Prcess de Desenvlviment de Sftware estã dispníveis na literatura, servind cm base para que uma rganizaçã elabre seu própri mdel, mais adequad às suas características individuais. 3.3 ATIVIDADES TÍPICAS DO PROCESSO DE SOFTWARE Diferentes autres cnsideram diferentes atividades cm send básicas para a definiçã de um prcess. Prém, mesm que se cnsiderem diferentes nmeclaturas e divisões, elas cntém essencialmente a mesma idéia, quand cnsideradas em cnjunt. Um exempl bastante cmum, de grup de atividades básicas é seguinte: Desenvlviment Análise, Design e Implementaçã. As funcinalidades e as restrições sã especificadas e sftware é prduzid; Validaçã & Verificaçã O sftware é testad. Observaçã: Verificaçã x Validaçã. Verificaçã Checar se realizu tdas as atividades (Fazend cert a cisa). Validaçã Checar se artefat está crret (Fazend a cisa certa); Manutençã O sftware sfre crreções, adaptações e ampliações.

31 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 31 Já Pressman (2006) destaca seguinte cnjunt de atividades genéricas de um prcess: Cmunicaçã Essa atividade envlve alta cmunicaçã e clabraçã cm cliente (e utrs stakehlders) e abrange levantament de requisits e utras atividades relacinadas; Planejament Essa atividade estabelece um plan para trabalh de engenharia de sftware. Descreve as tarefas técnicas a serem cnduzidas, s riscs prváveis, s recurss que serã necessáris, s prduts de trabalh a serem prduzids e um crngrama de trabalh; Mdelagem Essa atividade inclui a criaçã de mdels que permitam a desenvlvedr e a cliente, entender melhr s requisits d sftware e prjet que vai satisfazer a esses requisits; Cnstruçã Essa atividade cmbina geraçã de códig (manual u autmática) e s testes necessáris para revelar errs n códig; Implantaçã O sftware é entregue a cliente, que avalia prdut e frnece feedback. Pressman (2006) cmplementa que as atividades genéricas sã cmplementadas pr uma série de atividades guarda-chuva, entre as quais pdem ser citadas: Acmpanhament e cntrle de prjet de sftware; Gestã de risc; Garantia de qualidade de sftware; Revisões técnicas frmais; Mediçã; Gestã de cnfiguraçã de sftware; Gestã de reusabilidade; Preparaçã e prduçã d prdut d trabalh. O mesm autr ainda cmenta seguinte: Tda rganizaçã de Engenharia de sftware deveria descrever um cnjunt específic de atividades de arcabuç para (s) prcess(s) de sftware que adta. Deveria preencher cada atividade de arcabuç cm um cnjunt de ações de engenharia de sftware e definir cada açã em terms de um cnjunt de tarefas que identifique trabalh (e prduts de trabalh) a ser realizad para satisfazer às metas de desenvlviment. Deveria, entã, adaptar mdel de prcess resultante para acmdar a natureza específica de cada prjet, pessal que vai fazer trabalh e ambiente n qual trabalh vai ser cnduzid. Independentemente d mdel de prcess que seja selecinad, s engenheirs de sftware tem tradicinalmente esclhid um arcabuç de prcess genéric que inclui as seguintes atividades de arcabuç: cmunicaçã, planejament, mdelagem, cnstruçã e implantaçã. 3.4 CICLO DE VIDA DE SOFTWARE Cm td prdut industrial sftware tem um cicl de vida: Ele é cncebid a partir da percepçã de uma necessidade; É desenvlvid, transfrmand-se em um cnjunt de itens entregue a um cliente; Entra em peraçã, send usad dentr de algum prcess de negóci e sujeit a atividades de manutençã, quand necessári; É retirad de peraçã a final de sua vida útil.

32 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 32 Assim pde-se fazer a seguinte definiçã para Cicl de Vida: O cicl de vida d sftware é uma sequência de diferentes atividades executadas a lng da existência d sftware. Cada fase d cicl de vida tem divisões e subdivisões. É interessante destacar que a fase de cdificaçã, que representa a escrita final de um prgrama em frma inteligível para um cmputadr, é apenas uma pequena parte d cicl de vida. Para a mairia das pessas, inclusive muits prfissinais, essa ainda parece ser a única tarefa de um prdutr de sftware. Segue abaix um esquema simplificad de Cicl de Vida de Sftware. Cicl de Vida Percepçã da Necessidade Operaçã Retirada Cncepçã Elabraçã Transiçã Desenh Arquitetônic Desenvlviment Cnstruçã Liberaçã Testes de Aceitaçã Desenh detalhad Cdificaçã Teste De Unidade Assim, pde-se dizer que cicl de vida básic d sftware: Cmeça na cncepçã d prblema; Termina quand sistema sai de us. A seguir está dispnibilizada uma lista das atividades mais cmumente realizadas durante cicl de vida de um sftware. Estud de Viabilidade: Determina se desenvlviment prpst é viável; Análise de Mercad: Determina se existe mercad ptencial para prdut; Levantament de Requisits: Determina quais funcinalidades sftware deve ter; Elicidaçã ds Requisits: Obtém s requisits d usuári; Análise de Dmíni: Identifica e caracteriza ambiente (dmíni) n qual está prblema que sftware pretende slucinar;

33 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 33 Planejament de Prjet: Determina cm desenvlver sftware; Análise de Custs: Determina a estimativa ds custs; Elabraçã de Crngrama: Identifica crngrama para desenvlviment; Garantia da Qualidade de Sftware: Determina atividades irã ajudar a garantir a qualidade d prdut; Definiçã da Estrutura de Decmpsiçã d Trabalh: Determina as sub-tarefas necessárias para desenvlviment d prdut; Elabraçã d Design: Determina cm sftware deverá prver as funcinalidades (características técnicas/tecnlógicas); Elabraçã d Design Arquitetural: Prjeta a estrutura d sistema; Elabraçã d Design de Interface: Especifica as interfaces entre as partes d sistema; Elabraçã d Design Detalhad: Prjeta s algritms e estrutura de dads para cada cmpnente; Elabraçã d Design de Banc de Dads: Especifica (s) mdel(s) de banc de dads; Implementaçã: Cnstruçã d sftware; Teste: Execuçã d sftware cm dads para ajudar a garantir que sftware funcina crretamente; Teste de Unidade: Teste d desenvlvedr riginal; Teste de Integraçã: Teste durante a integraçã d sftware; Teste d Sistema: Teste d sftware em um ambiente semelhante a ambiente peracinal; Teste Alpha: Teste pel cliente n ambiente d desenvlvedr; Teste Beta: Teste pel cliente n seu ambiente; Teste de Aceitaçã: Teste para satisfazer cliente; Teste de Regressã: Teste de armazenament da versã anterir para garantir que a nva versã pssui tdas as capacidades anterires; Entrega: Prvê cliente cm uma sluçã de sftware eficiente; Implantaçã: Trna sftware dispnível n ambiente peracinal d cliente; Treinament: Ensina usuári cm perar sftware; Help desk: Respnde a questões d usuári; Manutençã: Atualizaçã e evluçã d sftware para garantir usabilidade cnstante.

34 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: MODELOS DE PROCESSO DE SOFTWARE Cnfrme destaca Pressman (2006):... A aplicaçã inteligente de qualquer mdel de prcess de sftware deve recnhecer que a adaptaçã (a prblema, a prjet, à equipe e à cultura rganizacinal) é essencial para sucess. Mas s mdels de prcess diferem fundamentalmente: N flux geral de atividades e tarefas e interdependências entre atividades e tarefas; N grau em que as tarefas de trabalh sã definidas dentr de cada atividade de arcabuç; N grau em que s prduts d trabalh sã identificads e slicitads; Na maneira cm as atividades de garantia de qualidade sã aplicadas; N md cm mnitrament de prjet e as atividades de cntrle sã aplicadas; N grau geral de detalhes e rigr em que prcess é descrit; N grau em que clientes e utrs interessads estã envlvids n prjet; N nível de autnmia da equipe de prjet de sftware; N grau em que a rganizaçã da equipe e s papéis sã prescrits. Mdels de prcess que enfatizam a definiçã, identificaçã e aplicaçã detalhada de atividades e tarefas de prcess têm sid aplicads na cmunidade de engenharia de sftware durante s últims trinta ans. Quand esses Mdels Prescritivs de Prcess sã aplicads, bjetiv é melhrar a qualidade d sistema para trnar s prjets mais gerenciáveis, as datas de entrega e s custs mais previsíveis e para guiar equipes de engenheirs de sftware à medida que eles realizam trabalh necessári para cnstruir um sistema. Infelizmente, tem havid épcas em que esses bjetivs nã têm sid alcançads. Se s mdels prescritivs frem aplicads dgmaticamente e sem adaptaçã, eles pdem aumentar nível de burcracia assciad à cnstruçã de sistemas baseads em cmputadr e, inadvertidamente, criar dificuldades para desenvlvedres e clientes. Mdels de prcess que enfatizam a agilidade d prjet e seguem uma série de princípis que levam a uma abrdagem mais infrmal (mas, segund seus prpnentes, nã mens efetiva) d prcess de sftware fram prpsts ns últims ans. Esses Mdels de Prcess Ágil enfatizam a manbrabilidade e a adaptabilidade. Eles sã adequads a muits tips de prjet e sã particularmente úteis quand aplicações Web passam pr engenharia. Que filsfia de prcess de sftware é melhr? Essa questã tem prvcad um debate emcinal entre engenheirs de sftware [...]. Pr hra, é imprtante ntar que essas duas filsfias de prcess têm bjetiv cmum criar sftwares de alta qualidade que satisfaçam às necessidades d cliente -, mas abrdagens diferentes SELECIONANDO UM MODELO DE PROCESSO Origem: Engenharia de Sftware, Rger Pressman, 2006 [...] Cada açã de engenharia de sftware é representada pr um númer diferente de cnjunts de tarefas cada um cm uma cleçã de tarefas de trabalh de engenharia de sftware, prduts de trabalh relacinads, pnts de garantia de qualidade e marcs de prjet. O cnjunt de tarefas esclhid é que melhr acmda as necessidades d prjet e as características da equipe. Iss implica que uma açã de engenharia de sftware (pr exempl, prjet) pde ser adaptada às necessidades específicas d prjet de sftware e às características da equipe d prjet. N que se refere diretamente as mdels de prcess, Pressman ainda cmplementa: [...] Um cnjunt de elements de prcess atividades de arcabuç, ações de engenharia de sftware, tarefas, prduts de trabalh, mecanisms de garantia de qualidade e de cntrle de mdificações

35 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 35 para cada prjet. Cada mdel de prcess também prescreve um flux de trabalh ist é, a maneira cm s elements d prcess se inter-relacinam uns cm s utrs. Origem: Wikipedia Os mdels existentes pssuem diferentes graus de sfisticaçã e cmplexidade. Para prjets que envlvem uma equipe de desenvlviment puc numersa e experiente, mais adequad será prvavelmente um prcess simples. N entant, para sistemas maires que envlvem equipes de dezenas u centenas de elements e milhares de utilizadres, um prcess simples nã é suficiente para ferecer a estrutura de gestã e disciplina necessárias à engenharia de um bm prdut de sftware. Desta frma, é necessári alg mais frmal e disciplinad. É imprtante fazer ntar que ist nã significa que se perca em invaçã u que se põe entraves à criatividade. Significa apenas que é utilizad um prcess bem estruturad para permitir a criaçã de uma base estável para a criatividade. Pr mais simples u cmplex que pssa parecer, um mdel de cicl de vida de um prjet é, de fat, uma versã simplificada da realidade. É supst ser uma abstraçã e, tal cm tdas as bas abstrações, apenas a quantidade de detalhe necessária a trabalh em mãs deve ser incluída. Qualquer rganizaçã que deseje pôr um mdel de cicl de vida em prática irá necessitar de adicinar detalhes específics para dadas circunstâncias e diferentes culturas. Pr exempl, a Micrsft quis manter uma cultura de pequena equipe e a mesm temp trnar pssível desenvlviment de grandes e cmplexs prduts de sftware. Dependend d tip de sistema em desenvlviment pde nã ser cmpletamente pssível u até aprpriad seguir s mdels rigrsamente RESUMINDO Sbre Mdels de Prcess: Especificam as atividades que, de acrd cm mdel, devem ser executadas, assim cm a rdem em que devem ser executadas; Prduts de sftware pdem ser cnstruíds utilizand-se diferentes mdels de prcess; Alguns mdels sã mais adequads que utrs para determinads tips de aplicaçã; A pçã pr um determinad mdel deve ser feita levand-se em cnsideraçã prdut a ser desenvlvid, as pessas envlvidas, s recurss dispníveis, e váris utrs parâmetrs; Objetivs: Auxiliar n prcess de prduçã Prduts de alta qualidade, prduzids mais rapidamente e a um cust cada vez menr; Atributs: cmplexidade, visibilidade, aceitabilidade, cnfiabilidade, manutenibilidade, segurança, etc; Pssibilitam: A gerente: cntrlar prcess de desenvlviment de sftware; A desenvlvedr: bter a base para prduzir, de maneira eficiente, sftware que satisfaça s requisits pré-estabelecids.

36 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: PANORAMA SOBRE MODELOS PRESCRITIVOS DE PROCESSO Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? Mdels prescritivs de prcess definem um cnjunt distint de atividades, ações, tarefas, marcs e prduts de trabalh que sã necessáris para fazer engenharia de sftware cm alta qualidade. Esses mdels de prcess nã sã perfeits, mas efetivamente frnecem um rteir útil para trabalh da engenharia de sftware; Quem faz? Engenheirs de sftware e seus gerentes adaptam um mdel de prcess prescritiv a suas necessidades e depis seguem. Além diss, pessal que slicitu sftware tem um papel a desenvlver à medida que mdel de prcess é seguid; Pr que é imprtante? Prque frnece estabilidade, cntrle e rganizaçã a uma atividade que pde, se deixada sem cntrle, trnar-se bastante caótica. Alguns têm-se referid a mdels prescritivs de prcess cm mdels de prcess rigrss, prque eles frequentemente incluem as capacitações sugeridas pel CMMI. N entant, cada mdel de prcess deve ser adaptad para que seja usad efetivamente em um prjet de sftware específic; Quais sã s passs? O prcess dirige uma equipe de sftware pr mei de um arcabuç de atividades guarda-chuva que sã rganizadas em um flux de prcess que pde ser linear, incremental u evlutiv. A terminlgia e s detalhes de cada mdel de prcess diferem, mas as atividades genéricas de arcabuç permanecem razavelmente cnsistentes; Qual é prdut d trabalh? D pnt de vista de um engenheir de sftware, s prduts de trabalh sã s prgramas, dcuments e dads que sã prduzids em cnsequência das atividades e tarefas definidas pel prcess; Cm tenh certeza de que fiz crretamente? Existem diverss mecanisms de avaliaçã de prcess de sftware que permitem às rganizações determinar a maturidade d seu prcess de sftware. Tdavia, a qualidade, pntualidade e viabilidade n lng praz d prdut que vcê cnstrói sã s melhres indicadres da eficácia d prcess usad. Ainda sbre Mdels de prcesss prescritivs autr destaca seguinte: Se s mdels prescritivs de prcess buscam estrutura e rdem, serã aprpriads a mund d sftware que busca mdificações? N entant, se rejeitarms mdels de prcesss cnvencinais (e a rdem que eles implicam) e s substituirms pr alg mens estruturad, trnams impssível bter crdenaçã e cerência n mund de sftware? Nã há respstas fáceis para essas questões, mas existem alternativas dispníveis para s engenheirs de sftware. A seguir serã apresentads alguns ds mdels prescritivs de prcess mais cnhecids CODE AND FIX (CONSTRÓI E CONSERTA) O cde-and-fix nã é um mdel prescritiv de prcess, mas uma primeira ideia de um prcess de sftware. O prdut é cnstruíd sem qualquer especificaçã u design. Nã existe um rteir definid de atividades, simplesmente vai-se se implementand à medida que cntat cm cliente vai identificand nvas necessidades. O prdut é refeit quantas vezes frem necessárias para satisfazer cliente. Este mdel pde funcinar razavelmente para micr prjets. N entant para prjets maires ele é inadequad. A Figura a seguir caracteriza mdel.

37 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: CLÁSSICO / EM CASCATA Este mdel é classificad cm send um Mdel Prescritiv de Prcess. Apesar de tds s seus prblemas, mdel em cascata é utilizad há muits ans, além de ser mais antig ds mdels. Atualmente, devid à cmplexidade cada vez mair ds sistemas, ele é puc utilizad. Suas principais características: Métd sistemátic e sequencial; O resultad de uma fase se cnstitui na entrada de utra - Cada atividade é uma fase distinta. Só após seu ttal términ é que a próxima atividade cmeça; O nível de abstraçã vai diminuind à medida que se avança n prcess enquant frmalism aumenta; Cada fase é estruturada cm um cnjunt de atividades que pdem ser executadas pr pessas diferentes; Os requisits d prblema devem estar bem cmpreendids. Diferentes autres pdem cnsiderar diferentes atividades a serem trabalhadas (mesm que elas tenham características em cmum). N entant que está acima descrit se aplica a qualquer cnjunt de atividades cnsideradas. Pressman (2006), pr exempl, a invés das atividades que estã abaix identificadas trabalha cm as atividades que chama de arcabuç, e que já fram previamente citadas.

38 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 38 Atividades d Cicl de Vida Clássic Alguns prblemas d Cicl de Vida Clássic: Os prjets reais raramente seguem flux sequencial que mdel prpõe. Alguma iteraçã sempre crre e traz prblemas na aplicaçã d paradigma; Muitas vezes é difícil para cliente declarar tdas as exigências explicitamente. O cicl clássic tem dificuldade de acmdar a incerteza natural que existe n cmeç de muits prjets; Uma versã de trabalh d(s) prgrama(s) só estará dispnível em um pnt muit tardi d crngrama d prjet. O cliente deve ter paciência; N mdel em cascata s subprcesss sã executads em estrita sequência, que permite demarcá-ls cm pnts de cntrle bem definids. Essa característica facilita a gestã ds prjets. Pr utr lad, se interpretad literalmente, é um prcess rígid e burcrátic, em que as atividades devem ser muit bem dminadas, pis nã sã permitids errs (retrnar após uma etapa ter sid cncluída); [...] A natureza linear d mdel em cascata leva a estads de blquei ns quais alguns membrs da equipe de prjet precisam esperar que utrs membrs cmpletem as tarefas dependentes. Realimentaçã entre fases Na prática, é sempre necessári permitir que, em fases psterires, haja revisã e alteraçã de resultads das fases anterires. Pr exempl, s mdels e dcuments de prjet pdem ser alterads durante a implementaçã, à medida que s prblemas vã send descberts. Uma variante que permite superpsiçã entre fases e a realizaçã de crreções é um mdel mais realista, cm realimentaçã entre as fases. Esta realimentaçã dificulta gerenciar prjets baseads neste mdel de prcess.

39 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: INCREMENTAL Este mdel é classificad cm send um Mdel Prescritiv de Prcess. O mdel incremental e iterativ fi prpst cm uma respsta as prblemas encntrads n mdel em cascata. Um prcess de desenvlviment segund essa abrdagem divide desenvlviment de um prdut de sftware em cicls, cm sftware send desenvlvid em partes (increments). Em cada cicl de desenvlviment, pdem ser identificadas tdas as fases d prjet. Essa característica cntrasta cm a abrdagem clássica, na qual as fases d prjet sã realizadas uma única vez. Cada um ds cicls cnsidera um subcnjunt de requisits. Os requisits sã desenvlvids uma vez que sejam alcads a um cicl de desenvlviment. N próxim cicl, um utr subcnjunt ds requisits é cnsiderad para ser desenvlvid, que prduz um nv increment d sistema que cntém extensões e refinaments sbre increment anterir. Assim, desenvlviment evlui em versões, através da cnstruçã incremental e iterativa de nvas funcinalidades até que sistema cmplet esteja cnstruíd. Vale destacar que apenas uma parte ds requisits é cnsiderada em cada cicl de desenvlviment. Na verdade, um mdel iterativ e incremental pde ser vist cm uma generalizaçã da abrdagem em cascata: sftware é desenvlvid em increments e cada increment é desenvlvid em cascata (figura abaix). A abrdagem incremental e iterativa smente é pssível se existir um mecanism para dividir s requisits d sistema em partes, para que cada parte seja alcada a um cicl de desenvlviment. Essa alcaçã é realizada em funçã d grau de imprtância atribuíd a cada requisit.

40 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: RAD (RAPID APPLICATION DEVELOPMENT) Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e incremental. O desenvlviment rápid de aplicaçã é um mdel de prcess de desenvlviment de sftware incremental que enfatiza um cicl de desenvlviment extremamente curt (pr exempl, de 60 a 90 dias). É uma adaptaçã d mdel cascata, n qual desenvlviment rápid é cnseguid cm us de uma abrdagem de cnstruçã baseada em cmpnentes, requerend que s requisits sejam bem cmpreendids, s bjetivs prpsts e haja diferentes equipes de desenvlviment envlvidas. (PRESSMAN, 2006). Pressman (2006) ainda destaca s pssíveis prblemas de tal abrdagem: Aument da necessidade de recurss humans (tamanh das equipes), a medida que escp d prblema aumenta;; Necessidade de mair envlviment e cmprmetiment, para cumprir s prazs curts; O prblema precisa ser adequadamente mdularizad, para que haja atuaçã das diferentes equipes; Em prjets de alt desempenh, cm interfaces de móduls muit interligadas, há mair prbabilidade de errs; Pde nã ser a abrdagem mais adequada quand s riscs técnics sã alts, cm pr exempl, na utilizaçã de uma nva tecnlgia.

41 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: MODELOS EVOLUCIONÁRIOS Sbre mdels de prcess evlucináris Pressman (2006) destaca seguinte: O sftware, cm td sistema cmplex, evlui cm passar d temp. Os requisits d negóci e d prdut mudam frequentemente à medida que desenvlviment prssegue, dificultand um caminh diret para um prdut final; prazs reduzids de mercad trnam impssível cmpletar um prdut de sftware abrangente, mas uma versã reduzida pde ser elabrada para fazer frente à cmpetitividade u às pressões d negóci; um cnjunt de requisits básics de um prdut u sistema é bem entendid, mas s detalhes das extensões d prdut u sistema ainda precisam ser definids. Nesse cas, e em situações semelhantes, s engenheirs de sftware precisam de um mdel de prcess que tenha sid explicitamente prjetad para acmdar um prdut que evlui cm temp. O mesm autr ainda prssegue, destacand a necessidade ds mdels evlucináris: [...] sftware de cmputadr mdern é caracterizad pr mdificações cntínuas, prazs muit curts e pr uma enfática necessidade de satisfaçã d cliente/usuári. Em muits cass, períd até a clcaçã n mercad é requisit gerencial mais imprtante. Se um nich de mercad é perdid, prjet de sftware em si pde ser insignificante. Pressman (2006) destaca também alguns prblemas que esse tip de mdel acarreta: Dificulta planejament de prjet, pis há um númer incert de cicls para cnstruir prdut; A velcidade da evluçã pde acarretar prblemas n própri prdut; Sã prcesss fcads na flexibilidade e extensibilidade, em detriment de utrs critéris de qualidade.

42 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: Prttipagem A prttipagem pde ser cnsiderada cm um mdel de prcess de desenvlviment de sftware, mas que pde funcinar cncmitantemente cm qualquer utr tip de mdel. N desenvlviment de um sftware, a prttipagem é um esbç de uma parte d sistema. Prtótips sã cnstruíds para telas de entrada, de saída, para subsistemas u mesm para td um sistema. A cnstruçã de prtótips cstuma utilizar as denminadas linguagens de prgramaçã visuais. Exempls sã Delphi, PwerBuilder e Visual Basic que cstumam ter ambientes cm facilidades para a cnstruçã da interface gráfica (telas, frmuláris etc.). Além diss, alguns sistemas gerenciadres de bancs de dads também frnecem ferramentas para a cnstruçã de telas de entrada e saída de dads. Fim Iníci Cleta e Refinament ds Requisits Engenharia d Prdut Prjet Rápid Refinament d Prtótip Cnstruçã d Prtótip Avaliaçã d Prtótip pel Cliente Esse mdel cnstrói uma versã descartável (u prtótip). Esse prtótip visa a testar cnceits e requisits e será usad para demnstrar cmprtament as clientes. Após a cncrdância ds clientes, sftware é desenvlvid seguind as mesmas fases d mdel clássic, u de algum utr mdel que seja adtad. O esfrç despendid n prtótip geralmente é cmpensad pel nã desenvlviment de características desnecessárias. Pde assumir 3 frmas: (1) Um prtótip em papel u autmatizad; (2) Um prtótip de trabalh que implementa algum subcnjunt da funçã exigida d sftware desejad; (3) Um prgrama existente que executa parte u tda a funçã desejada. O funcinament básic é seguinte: A prttipaçã inicia-se cm a cleta ds requisits. O desenvlvedr e cliente reúnem-se e definem s bjetivs glbais para sftware. Ocrre entã a elabraçã de um design rápid. O design rápid leva a cnstruçã de um prtótip que é avaliad pel cliente/usuári e é usad para refinar s requisits para sftware a ser desenvlvid. Idealmente, prtótip serve cm um mecanism para identificar s requisits de sftware, quand há muitas dúvidas entre estes. A prttipaçã é fundamental à medida que cresce a imprtância da interface cm usuári. O prtótip pde servir cm primeir sistema sistema esse que recmenda-se seja jgad fra. O prblema é que alguns usuáris tendem a encarar prtótip cm alg já cnfiável, u seja, cm se já fsse parte d sftware real.

43 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 43 Na mairia ds prjets, primeir sistema cnstruíd, se fr via prtótip, dificilmente é usável. Ele pde ser muit lent, muit grande, desajeitad em us, u tds s três. Nã resta utra alternativa senã cmeçar tud de nv, mas cm mais habilidade técnica. O desenvlvedr pde nã utilizar as técnicas de prgramaçã adequadas, pensand apenas na rapidez. Um prtótip nrmalmente precupa-se apenas cm a interface, nã tratand ds algritms e regras de negóci. Esse é, prtant mais um mtiv para que ele seja descartad, a invés de servir de base para sftware final. Ainda que pssam crrer prblemas, a prttipaçã é um paradigma eficiente da engenharia de sftware. A chave é definir-se as regras d jg lg n cmeç, u seja, cliente e desenvlvedr devem ambs cncrdar que prtótip seja cnstruíd para servir cm um mecanism afim de definir s requisits. Ele será depis descartad (pel mens em parte) e sftware real será prjetad Espiral u Evlutiv Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e evlucinári. Cleta inicial ds Requisits e Planejament d Prjet Planejament Análise ds Riscs Análise ds riscs baseada ns requisits iniciais Análise ds riscs baseada na reaçã d cliente Planejament basead ns cmentáris d cliente Decisã de Prsseguir u nã Na direçã de um sistema cncluid Avaliaçã d cliente Avaliaçã d Cliente Engenharia Prtótip de Sftware inicial Prtótip de nível seguinte Sistema cnstruid pela engenharia Este é um mdel que atende s seguintes cass: O prblema a ser reslvid nã está ttalmente entendid; A realidade pde mudar enquant sistema está send desenvlvid; A própria sluçã adtada pde ter algum efeit clateral descnhecid; A precupaçã está centrada mais na qualidade e funcinalidade d que se prduz. O mdel espiral para a engenharia de sftware fi desenvlvid para abranger as melhres características tant d cicl de vida clássic (n que se refere a sistematizaçã e cntrle) cm da prttipaçã (n que se refere a iteratividade), acrescentand, a mesm temp, um nv element a análise ds riscs que falta a esses paradigmas. O mdel, representad pela espiral, define quatr imprtantes atividades representadas pels quatr quadrantes da figura, send elas:

44 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: Planejament: determinaçã ds bjetivs, alternativas e restrições. 2. Análise ds riscs: análise de alternativas e identificaçã/resluçã ds riscs. 3. Engenharia: desenvlviment d prdut n nível seguinte. 4. Avaliaçã pel cliente: avaliaçã ds resultads da engenharia. N mdel em Espiral prdut é desenvlvid em uma série de iterações. Cada nva iteraçã crrespnde a uma vlta na espiral. Iss permite cnstruir prduts em prazs curts, cm nvas características e recurss que sã agregads à medida que a experiência descbre sua necessidade. As atividades de avaliaçã sã usadas para identificar prblemas. Seus registrs frnecem dads para definir s requisits das próximas liberações. As versões prgressivamente mais cmpletas d sftware sã cnstruídas a lng de cada iteraçã da espiral. Durante iníci d gir, s bjetivs, alternativas e restrições sã definids, e s riscs sã identificads e analisads. A cnclusã da análise ds riscs resulta numa decisã de prsseguir u nã. Se s riscs frem muit grandes, prjet pde ser encerrad. Há desenvlviment de parte d prgrama, que é dispnibilizad para testes. Entã cliente avalia trabalh de engenharia e apresenta sugestões para mdificações. Cada passagem pela regiã de planejament resulta em ajustes n plan de prjet. O cust e crngrama sã ajustads cm base n feedback derivad d cliente após a entrega. Além diss, gerente d prjet ajusta númer planejad de iterações necessárias para cmpletar sftware (Pressman, 2006). Deve-se ntar que númer de atividades de desenvlviment que crre n quadrante inferir direit eleva-se à medida que as atividades se afastam d centr da espiral. O paradigma d mdel espiral usa a prttipaçã cm um mecanism de reduçã ds riscs, pssibilitand que desenvlvedr aplique a abrdagem de prttipaçã em qualquer etapa da evluçã d prdut. O mdel espiral exige uma cnsideraçã direta ds riscs técnics em tdas as etapas d prjet e, se adequadamente aplicad, deve reduzir s riscs antes que eles se trnem prblemátics. Ele exige cnsiderável experiência na avaliaçã ds riscs e fia-se nessa experiência para sucess. Se um grande risc nã fr descbert, indubitavelmente crrerã prblemas. O principal prblema d cicl de vida em espiral é que ele requer gestã muit sfisticada para ser previsível e cnfiável. E pde ser difícil cnvencer s clientes sbre a realizaçã de cntrle em tal frma de trabalh, vist s cnstantes ajustes que sã realizads. Vale destacar que mdel em espiral pde ser cntinuamente utilizad, após a cnclusã inicial d sftware, para a realizaçã das manutenções que mesm deverá sfrer a lng d temp. Uma utra figura interessante é apresentada pr Smmerville (2007), e está a seguir destacada.

45 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: Cncrrente Este mdel é classificad cm send um Mdel Prescritiv de Prcess, e evlucinári. O mdel cncrrente é representad através de uma série de atividades e seus estads crrespndentes. Sbre ele pde ser dit seguinte: As atividades pdem crrer em paralel, mas estã em diferentes estads; O mdel define uma série de events que vã disparar transições de estad para estad, para cada uma das atividades; Em vez de usar uma sequência cm mdel cascata, ele define uma rede de atividades; Pde ser aplicad a td tip de desenvlviment de sftware e frnece uma visã exata de cm está estad d prjet. Um exempl de uma rede de atividades pde ser cm da figura a seguir.

46 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 46 nne Mdeling act ivit y Under develpment represents the state f a sftware engineering activity r task Await ing changes Under review Under revisin Baselined Dne DESENVOLVIMENTO BASEADO EM COMPONENTES Origem: Engenharia de Sftware, Rger Pressman, 2006 É um mdel desenvlvid para apiar a reusabilidade, necessária a atual desenvlviment de sftware, pr suas principais cnsequências: reduçã de praz e cust. Tal mdel se utiliza de cmpnentes de sftware cmercial de prateleira, ist é, cmpnentes que apresentam funcinalidade e interface bem definidas e que pdem ser utilizads integrads n sftware em desenvlviment. Incrpra muitas das características d mdel espiral. É um mdel evlucinári pr natureza, demanda uma abrdagem iterativa. Nrmalmente, apresenta s seguintes passs: Pesquisa e avaliaçã de cmpnentes dispníveis n mercad; Análise das necessidades de integraçã/implementaçã; Prjet da arquitetura de sftware, cnsiderand s cmpnentes; Integraçã e Implementaçã que fr necessária; Validaçã rigrsa.

47 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: O MODELO DE MÉTODOS FORMAIS Origem: Engenharia de Sftware, Rger Pressman, 2006 Os mdels de métds frmais abrangem um cnjunt de atividades que levam à especificaçã matemática frmal d sftware de cmputadr. Sã mdels que se apóiam na aplicaçã de uma rigrsa ntaçã matemática. Tem ganhad adepts quand há necessidade d desenvlviment de sftwares crítics em terms de segurança, devid à sua prmessa de um prdut livre de errs. Vantagens: Ambiguidades, incnclusões e incnsistências pdem ser descbertas e crrigidas mais facilmente, pr mei de análise matemática; Prblemas: O desenvlviment de mdels frmais é atualmente muit lent e dispendis; Cm pucs desenvlvedres de sftware têm prepar necessári para aplicar métds frmais, trna-se necessári um treinament extensiv; É difícil usar s mdels cm um mecanism de cmunicaçã, cm clientes despreparads tecnicamente DESENVOLVIMENTO DE SOFTWARE ORIENTADO A ASPECTOS Origem: Engenharia de Sftware, Rger Pressman, 2006 Certas precupações transversais cbrem tda a arquitetura de um sistema, nã send exclusivas de uma funcinalidade, característica u infrmaçã. Pr exempl: segurança, tlerância a falhas, transações, geraçã de lgs. Assim, pde-se definir: Aspects: mecanisms que transcendem subrtinas e herança para lcalizar a expressã de uma precupaçã transversal, afetand tda a arquitetura de sftware. Nã existe ainda prcess rientad a aspects que seja cnsiderad suficientemente madur, mas é prvável que adte características tant d mdel de prcess espiral quant d cncrrente. Alguns terms que cmeçam a se trnar cnhecids: POA Prgramaçã Orientada a Aspects; DSOA Desenvlviment de Sftware Orientad a Aspects.

48 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: PROCESSO UNIFICADO (PU) Origem: Engenharia de Sftware, Rger Pressman, 2006 Engenharia de Sftware, Ntas de Aula, prf. Ricard de Almeida Falb, UFES De acrd cm Pressman (2006), PU é uma tentativa de apiar-se ns melhres recurss e características ds mdels cnvencinais de prcess de sftware, mas caracterizá-ls de um md que implemente s melhres princípis de desenvlviment ágil de sftwares. O Prcess Unificad é um prcess de engenharia de sftware desenvlvid pr três ds principais gurus da indústria de sftware: Ivar Jacbsn, James Rumbaugh e Grady Bch, send resultad de mais de 30 ans de experiência acumulada. É primeir prcess de desenvlviment a explrar integralmente as capacidades d padrã UML e baseia-se nas práticas cmuns as prjets de sftware cm mais alt ROI d mercad. Prcess de Sftware Unificad (Ratinal Unified Prcess) = Prcess + Métds + Linguagem (UML) Históric: O desenvlviment de sistemas seguind RUP é um prcess: Dirigid pr cass de us (use cases); Centrad na arquitetura; Iterativ e incremental.

49 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 49 O RUP trata um cnjunt de atividades: Bem definidas; Cm respnsáveis; Cm artefats de entrada e saída; Cm dependências e rdem de execuçã; Cm mdel de cicl de vida; Cm uma descriçã sistemática de cm executá-las; Usand linguagem UML.

50 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 50 Cnceits-chave d RUP: fnte: O Prcess Unificad prpst pela Ratinal (Ratinal Unified Prcess RUP) fi criad para apiar desenvlviment rientad a bjets, frnecend uma frma sistemática para se bter reais vantagens n us da Linguagem de Mdelagem Unificada (Unified Mdeling Language UML). De fat, ele nã é exatamente um prcess: é uma infraestrutura genérica de prcess que pde ser especializada para uma ampla classe de sistemas de sftware, para diferentes áreas de aplicaçã, tips de rganizaçã, níveis de cmpetência e tamanhs de prjets. O RUP está fundamentad em três princípis básics: rientaçã a cass de us, arquitetura e iteraçã. Ele é dit dirigid a cass de us, pis sã s cass de us que rientam td prcess de desenvlviment. Cm base n mdel de cass de us, sã criads uma série de mdels de análise, design e implementaçã, que realizam estes cass de us. É centrad em arquitetura, pis defende a definiçã de um esquelet para a aplicaçã (a arquitetura), a ganhar crp gradualmente a lng d desenvlviment. Finalmente, RUP é iterativ e incremental, ferecend uma abrdagem para particinar trabalh em prções menres u mini-prjets. Esses três cnceits sã igualmente imprtantes. A arquitetura prvê a estrutura para guiar desenvlviment d sistema em iterações, enquant s cass de us definem as metas e cnduzem trabalh de cada iteraçã. O cicl de vida adtad n RUP é tipicamente evlutiv. Cntud, uma frma de rganizaçã em fases é adtada para cmprtar s cicls de desenvlviment, permitind uma gerência mais efetiva de prjets cmplexs. A cntrári d tradicinalmente definid cm fases na mairia ds mdels de cicl de vida planejament, levantament de requisits, análise, prjet, implementaçã e testes, sã definidas fases rtgnais a estas, a saber: Cncepçã: nesta fase, é estabelecid escp d prjet e suas frnteiras, determinand s principais cass de us d sistema. Esses cass de us devem ser elabrads cm a precisã necessária para se prceder estimativas de prazs e custs. As estimativas devem

51 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 51 ser glbais para prjet cm um td e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sbre planejament e, pr cnseguinte, é necessári levantar requisits d sistema e preliminarmente analisá-ls. A términ dessa fase, sã examinads s bjetivs d prjet para se decidir sbre a cntinuidade d desenvlviment; Elabraçã: prpósit desta fase é analisar mais refinadamente dmíni d prblema, estabelecer uma arquitetura de fundaçã sólida, desenvlver um plan de prjet para sistema a ser cnstruíd e eliminar s elements de prjet que ferecem mair risc. Embra prcess deva sempre acmdar alterações, as atividades da fase de elabraçã asseguram que s requisits, a arquitetura e s plans estã suficientemente estáveis e que s riscs estã suficientemente mitigads, de md a se pder prever cm precisã s custs e prazs para a cnclusã d desenvlviment. Cnstruçã: durante esta fase, um prdut cmplet é desenvlvid de maneira iterativa e incremental, para que esteja prnt para a transiçã à cmunidade usuária. Transiçã: nesta fase, sftware é dispnibilizad à cmunidade usuária. Após prdut ter sid clcad em us, naturalmente surgem nvas cnsiderações que vã demandar a cnstruçã de nvas versões para permitir ajustes d sistema, crrigir prblemas u cncluir algumas características que fram pstergadas. É imprtante realçar que dentr de cada fase, um cnjunt de iterações, envlvend planejament, levantament de requisits, análise, prjet e implementaçã e testes, é realizad. Cntud, de uma iteraçã para utra e de uma fase para a próxima, a ênfase sbre as várias atividades muda, cm mstra a figura 1 abaix, em que a cr preta indica grande ênfase, enquant a cr branca indica muit puca ênfase. Na fase de cncepçã, fc principal recai sbre entendiment ds requisits e a determinaçã d escp d prjet (planejament e levantament de requisits). Na fase de elabraçã, enfque está na captura e mdelagem ds requisits (levantament de requisits e análise), ainda que algum trabalh de prjet e implementaçã seja realizad para prttipar a arquitetura, evitand certs riscs técnics. Na fase de cnstruçã, enfque cncentra-se n prjet e na implementaçã, visand evluir e rechear prtótip inicial, até bter primeir prdut peracinal. Finalmente, a fase de transiçã cncentra-se ns testes, visand garantir que sistema pssui nível adequad de qualidade. Além diss, usuáris devem ser treinads, características ajustadas e elements esquecids adicinads. Além ds cnjunts de iterações em cada fase, as fases em si pdem crrer de frma iterativa. Cm mstra a figura 2, elas nã necessariamente têm a mesma duraçã. O esfrç realizad em cada uma varia frtemente em funçã das circunstâncias específicas d prjet.

52 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 52 Autr: RICARDO DE ALMEIDA FALBO (fnte: Pressman (2006) destaca que as fases prpstas n PU pdem ser encaradas da mesma frma que as atividades de arcabuç pr ele prpstas, cnfrme destacad na figura abaix: Prcess de Engenharia de Sftware na visã d RUP

53 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 53 Um prcess é um cnjunt de passs rdenads cm a intençã de atingir uma meta. Em engenharia de sftware, a meta é criar um sftware u aperfeiçar um existente; em engenharia de prcesss, a meta é desenvlver u aperfeiçar um prcess. N RUP, eles sã rganizads em um cnjunt de disciplinas para psterirmente definirem s fluxs de trabalh e utrs elements d prcess. Em terms de mdelagem de negócis, prcess de desenvlviment de sftware é um prcess de negócis, e Ratinal Unified Prcess (RUP) é um prcess de negócis genéric para engenharia de sftware rientada a bjets. Ele descreve uma família de prcesss de engenharia de sftware relacinads, que cmpartilham uma estrutura cmum, uma arquitetura de prcesss cmum. Ele prprcina uma abrdagem disciplinada para a atribuiçã de tarefas e de respnsabilidades dentr de uma rganizaçã de desenvlviment. Sua meta é garantir a prduçã de sftware de alta qualidade que atenda às necessidades ds usuáris, dentr de uma prgramaçã e um rçament previsíveis. O RUP captura muitas das melhres práticas d desenvlviment de sftware mdern, de frma que pssam ser adaptadas para uma grande variedade de prjets e de rganizações. Quand um sistema de sftware é desenvlvid cmeçand d zer, desenvlviment é prcess de criaçã de um sistema a partir ds requisits. Prém, depis que s sistemas tiverem tmad frma (u seja, tiverem passad pel cicl de desenvlviment inicial), s desenvlviments subsequentes serã prcess de adaptaçã d sistema as requisits nvs u mdificads. Iss se aplica durante td cicl de vida d sistema. Pressman (2006) destaca que nem tda tarefa identificada para um flux de trabalh d PU é cnduzida para qualquer prjet de sftware. A equipe adapta prcess (ações, tarefas, subtarefas e prduts de trabalh) para satisfazer às suas necessidades. 3.6 DESENVOLVIMENTO ÁGIL PANORAMA SOBRE DESENVOLVIMENTO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? A engenharia de sftware ágil cmbina uma filsfia e um cnjunt de diretrizes de desenvlviment. A filsfia encraja a satisfaçã d cliente e a entrega incremental de sftware lg de iníci; equipes de prjet pequenas, altamente mtivadas; métds infrmais; prduts de trabalh de engenharia de sftware mínims e simplicidade glbal de desenvlviment. As diretrizes de desenvlviment enfatizam a entrega em cntrapsiçã à análise e a prjet (apesar dessas atividades nã serem desencrajadas) e a cmunicaçã ativa e cntínua entre desenvlvedres e clientes; Quem faz? Engenheirs de sftware e utrs interessads n prjet (gerentes, clientes e usuáris finais) trabalham junts em uma equipe ágil uma equipe que é aut-rganizada e cntrla seu própri destin. Uma equipe ágil enfatiza a cmunicaçã e a clabraçã entre tds que a cmpõe; Pr que é imprtante? O ambiente mdern de negócis que cria sistemas baseads em cmputadr e prduts de sftware é apressad e sempre mutável. A engenharia ágil de sftware representa uma alternativa razável para a engenharia de sftware cnvencinal para certas categrias de sftware e certs tips de prjet de sftware. Tem sid demnstrad que ela entrega rapidamente sistemas bem-sucedids; Quais sã s passs? O desenvlviment ágil pderia ser melhr denminad pequena engenharia de sftware. As atividades básicas de arcabuç cmunicaçã cm cliente, planejament, a mdelagem, cnstruçã, entrega e avaliaçã permanecem. Mas elas sã

54 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 54 reduzidas a um cnjunt mínim de tarefas que leva a equipe de prjet à cnstruçã e entrega (alguns alegariam que iss é feit à custa da análise d prblema e prjet da sluçã); Qual é prdut d trabalh? Clientes e engenheirs de sftware que têm adtad a filsfia ágil têm a mesma impressã únic prdut de trabalh realmente imprtante é um increment de sftware peracinal que é entregue a cliente na data de entrega cmbinada; Cm tenh certeza de que fiz crretamente? Se a equipe ágil cncrdar que prcess funcina e prduz increments de sftware em cndições de serem entregues e que satisfaçam a cliente, vcê fez crretamente. Cmentáris: Os mdels de prcess ágeis fram desenvlvids em um esfrç para vencer as fraquezas percebidas e reais da engenharia de sftware cnvencinal; Pde frnecer imprtantes benefícis, mas ele nã é aplicável a tds s prjets, prduts, pessas e situações; Nã é cntrári à sólida prática de engenharia de sftware, prevalecend cm uma filsfia sbre trabalh de sftware; Os engenheirs de sftware devem ser ágeis suficiente para respnder a um ambiente de negócis mutante. E a engenharia de sftware está evluind para se adaptar a essa nva necessidade de agilidade. Pressman (2006) apresenta ainda Manifest d Desenvlviment Ágil de Sftware, nde é declarad: Estams descbrind melhres mds de desenvlviment de sftware, fazend- e ajudand utrs a fazê-l. Pr mei desse trabalh passams a valrizar: Indivídus e interações em vez de prcesss e ferramentas. Sftwares funcinand em vez de dcumentaçã abrangente. Clabraçã d cliente em vez de negciaçã de cntrats. Respsta a mdificações em vez de seguir um plan. Ist é, ainda que haja valr ns itens à direita, valrizams mais s itens à esquerda O QUE É AGILIDADE Pressman (2006) destacu que nã se deve cmeter err de cnsiderar que agilidade dá a engenheir de sftware a licença de imprvisar sluções. A agilidade está relacinada a: Capacidade de respnder rapidamente a mudanças; Estruturas e atitudes de equipe que trnam a cmunicaçã mais fácil; Entrega rápida de sftware peracinal; Menr imprtância para prduts de trabalh intermediáris; Adçã ds clientes cm parte da equipe de desenvlviment; Planejament em um mund incert tem limites e um plan de prjet deve ser flexível. O mesm autr ainda destaca 12 princípis (prpsts pel Manifest Ágil) que devem ser seguids para se alcançar agilidade, send eles:

55 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 55 A mais alta priridade é a satisfaçã d cliente, pr mei da liberaçã mais rápida e cntínua de sftware de valr; Receba bem as mudanças de requisits, mesm em estágis tardis d desenvlviment. Prcesss Ágeis devem admitir mudanças que trazem vantagens cmpetitivas para cliente; Libere sftware frequentemente (em intervals de 2 semanas até 2 meses), dand preferência para uma escala de temp mais curta; Mantenha pessas ligadas a negóci (cliente) e desenvlvedres trabalhand junts a mair parte d temp d prjet; Cnstrua prjets cm indivídus mtivads, dê a eles ambiente e suprte que precisam e cnfie neles para ter trabalh realizad; O métd mais eficiente e efetiv para repassar infrmações entre uma equipe de desenvlviment é pela cmunicaçã face-a-face; Sftware funcinand é a principal medida d prgress de um prjet de sftware; Prcesss ágeis prmvem desenvlviment sustentad. Assim, patrcinadres, desenvlvedres e usuáris devem ser capazes de manter cnversaçã pacífica indefinidamente; A atençã cntínua para a excelência técnica e um bm prjet (design) aprimram a agilidade; Simplicidade a arte de maximizar a quantidade de trabalh nã feit é essencial, devend ser assumida em tds s aspects d prjet; As melhres arquiteturas, requisits e prjets emergem de equipes aut-rganizadas; Em intervals regulares, as equipes devem refletir sbre cm se trnaram mais efetivas, e entã refinarem e ajustarem seu cmprtament de acrd O QUE É UM PROCESSO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 Qualquer prcess ágil é caracterizad de md que atenda a três supsições-chave: É difícil prever antecipadamente quais requisits de sftware vã persistir e quais serã mdificads. É igualmente difícil prever cm as priridades d cliente serã mdificadas à medida que prjet prssegue; O prjet e a cnstruçã sã intercalads, ist é, as duas atividades devem ser realizadas juntas de md que s mdels de prjet sejam cmprvads à medida que sã criads. É difícil prever quant de prjet é necessári antes que a cnstruçã seja usada para cmprvar prjet; Análise, prjet, cnstruçã e testes nã sã tã previsíveis (d pnt de vista d planejament) cm gstaríams. Pergunta: Cm criar um prcess que pssa gerenciar a imprevisibilidade? Respsta: Um prcess ágil deve ser adaptável e ser adaptad incrementalmente, cm base n feedback d cliente.

56 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: POLÍTICA DE DESENVOLVIMENTO ÁGIL Origem: Engenharia de Sftware, Rger Pressman, 2006 Ninguém é cntra a agilidade (defensres de cada categria de mdels de prcess), que se tem sã respstas diferentes para as seguintes perguntas: Qual melhr md de alcançar a agilidade? Cm cnstruir sftwares que satisfaçam às necessidades d cliente atual e exiba características de qualidade que lhe permitam ser estendid e ampliad para satisfazer às necessidades d cliente n lng praz? Nã há respstas abslutas para as perguntas acima lançadas. Há muit a ser ganh cnsiderand que huver de melhr em cada abrdagem FATORES HUMANOS Origem: Engenharia de Sftware, Rger Pressman, 2006 O desenvlviment ágil enfca s talents e habilidades ds indivídus, mldand prcess a pessas e equipes específicas. Características-chave que devem existir entre as pessas de uma equipe ágil e na equipe entre si: Cmpetência; Fc cmum; Clabraçã; Capacidade de tmada de decisã - autnmia; Habilidade de reslver prblemas vags; Respeit e cnfiança mútua; Aut-rganizaçã. A equipe serve cm sua própria gerência. A equipe ágil rganiza-se para trabalh a ser feit; A equipe rganiza prcess para melhr acmdar seu ambiente lcal; A equipe rganiza crngrama de trabalh para cnseguir melhr entrega d increment de sftware. Alguns mdels ágeis de prcess que pdem ser destacads sã s seguintes: EXTREME PROGRAMMING (XP) Origem: Wikipédia, a enciclpédia livre. Prgramaçã extrema (d inglês extreme Prgramming), u simplesmente XP, é uma metdlgia ágil para equipes pequenas e médias e que irã desenvlver sftware cm requisits vags e em cnstante mudança. Para iss, adta a estratégia de cnstante acmpanhament e realizaçã de váris pequens ajustes durante desenvlviment de sftware. Os quatr valres fundamentais da metdlgia XP sã: cmunicaçã, simplicidade, feedback e cragem. A partir desses valres, pssui cm princípis básics: feedback rápid, presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalh de qualidade.

57 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 57 Dentre as variáveis de cntrle em prjets (cust, temp, qualidade e escp), há um fc explícit em escp. Para iss, recmenda-se a pririzaçã de funcinalidades que representem mair valr pssível para negóci. Desta frma, cas seja necessári a diminuiçã de escp, as funcinalidades mens valisas serã adiadas u canceladas. A XP incentiva cntrle da qualidade cm variável d prjet, pis pequen ganh de curt praz na prdutividade, a diminuir qualidade, nã é cmpensad pr perdas (u até impediments) a médi e lng praz. Práticas Para aplicar s valres e princípis durante desenvlviment de sftware, XP prpõe uma série de práticas. Há uma cnfiança muit grande na sinergia entre elas, s pnts fracs de cada uma sã superads pels pnts frtes de utras. Jg de Planejament (Planning Game): O desenvlviment é feit em iterações semanais. N iníci da semana, desenvlvedres e cliente reúnem-se para pririzar as funcinalidades. Essa reuniã recebe nme de Jg d Planejament. Nela, cliente identifica priridades e s desenvlvedres as estimam. O cliente é essencial neste prcess e assim ele fica sabend que está acntecend e que vai acntecer n prjet. Cm escp é reavaliad semanalmente, prjet é regid pr um cntrat de escp negciável, que difere significativamente das frmas tradicinais de cntrataçã de prjets de sftware. A final de cada semana, cliente recebe nvas funcinalidades, cmpletamente testadas e prntas para serem pstas em prduçã. Pequenas Versões (Small Releases): A liberaçã de pequenas versões funcinais d prjet auxilia muit n prcess de aceitaçã pr parte d cliente, que já pde testar uma parte d sistema que está cmprand. As versões chegam a ser ainda menres que as prduzidas pr utras metdlgias incrementais, cm RUP. Metáfra (Metaphr): Prcura facilitar a cmunicaçã cm cliente, entendend a realidade dele. O cnceit de rápid para um cliente de um sistema jurídic é diferente para um prgramadr experiente em cntrlar cmunicaçã em sistemas em temp real, cm cntrle de tráfeg aére. É precis traduzir as palavras d cliente para significad que ele espera dentr d prjet. Prjet Simples (Simple Design): Simplicidade é um princípi da XP. Prjet simples significa dizer que cas cliente tenha pedid que na primeira versã apenas usuári "teste" pssa entrar n sistema cm a senha "123" e assim ter acess a td sistema, vcê vai fazer códig exat para que esta funcinalidade seja implementada, sem se precupar cm sistemas de autenticaçã e restrições de acess. Um err cmum a adtar essa prática é a cnfusã pr parte ds prgramadres de códig simples e códig fácil. Nem sempre códig mais fácil de ser desenvlvid levará a sluçã mais simples pr parte de prjet. Esse entendiment é fundamental para bm andament d XP. Códig fácil deve ser identificad e substituíd pr códig simples. Time Ces (Whle Team): A equipe de desenvlviment é frmada pel cliente e pela equipe de desenvlviment. Testes de Aceitaçã (Custmer Tests): Sã testes cnstruíds pel cliente e cnjunt de analistas e testadres, para aceitar um determinad requisit d sistema. Ritm Sustentável (Sustainable Pace): Trabalhar cm qualidade, buscand ter ritm de trabalh saudável (40 hras/semana, 8 hras/dia), sem hras extras. Hras extras sã permitidas quand truxerem prdutividade para a execuçã d prjet. Outra prática que se verifica neste prcess é a prática de trabalh energizad, nde se busca trabalh mtivad sempre. Para ist ambiente de trabalh e a mtivaçã da equipe devem estar sempre em harmnia. Reuniões em pé (Stand-up Meeting): Reuniões em pé para nã se perder fc ns assunts, prduzind reuniões rápidas, apenas abrdand tarefas realizadas e tarefas a realizar pela equipe.

58 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 58 Psse Cletiva (Cllective Ownership): O códig-fnte nã tem dn e ninguém precisa slicitar permissã para pder mdificar mesm. O bjetiv cm ist é fazer a equipe cnhecer tdas as partes d sistema. Prgramaçã em Pares (Pair Prgramming): é a prgramaçã em par/dupla num únic cmputadr. Geralmente a dupla é frmada pr um iniciante na linguagem e utra pessa funcinand cm um instrutr. Cm é apenas um cmputadr, nvat é que fica à frente fazend a cdificaçã, e instrutr acmpanha ajudand a desenvlver suas habilidades. Desta frma prgrama sempre é revist pr duas pessas, evitand e diminuind assim a pssibilidade de errs (bugs). Cm ist busca-se sempre a evluçã da equipe, melhrand a qualidade d códig fnte gerad. Padrões de Cdificaçã (Cding Standards): A equipe de desenvlviment precisa estabelecer regras para prgramar e tds devem seguir estas regras. Desta frma parecerá que td códig-fnte fi editad pela mesma pessa, mesm quand a equipe pssui 10 u 100 membrs. Desenvlviment Orientad a Testes (Test Driven Develpment): Primeir crie s testes unitáris (unit tests) e depis crie códig para que s testes funcinem. Esta abrdagem é cmplexa n iníci, pis vai cntra prcess de desenvlviment de muits ans. Só que s testes unitáris sã essenciais para que a qualidade d prjet seja mantida. Refatraçã (Refactring): É um prcess que permite a melhria cntínua da prgramaçã, cm mínim de intrduçã de errs e mantend a cmpatibilidade cm códig já existente. Refabricar melhra a clareza (leitura) d códig, divide- em móduls mais cess e de mair reaprveitament, evitand a duplicaçã de códig-fnte. Integraçã Cntínua (Cntinuus Integratin): Sempre que prduzir uma nva funcinalidade, nunca esperar uma semana para integrar à versã atual d sistema. Ist só aumenta a pssibilidade de cnflits e a pssibilidade de errs n códig-fnte. Integrar de frma cntínua permite saber status real da prgramaçã. Origem: Engenharia de Sftware, Rger Pressman, 2006 O XP usa uma abrdagem rientada a bjets cm seu paradigma de desenvlviment preferencial. A metdlgia d Extreme Prgramming pssui 4 atividades de arcabuç:

59 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 59 Planejament: Prjet: Cdificaçã: Teste: Criaçã de um cnjunt de histórias que descrevem as características e funcinalidades requeridas. O cliente atribui uma priridade para cada história, cm base n valr de negóci glbal da história. Membrs da equipe atribuem um cust às histórias medid em semanas de desenvlviment. Se uma história precisar de mais de 3 semanas, pede-se a cliente para dividir a história em histórias menres. Nvas histórias pdem ser escritas a qualquer mment. A equipe e cliente reúnem-se para agrupar as histórias na versã seguinte e identificar md cm elas serã desenvlvidas. Calcula-se a velcidade de prjet quantidade de histórias implementadas na primeira versã para ajudar a estimar datas futuras e verificar cmprmetiment cm as histórias. Segue rigrsamente princípi KIS (keep it simple mantenha simples), frnecend apenas diretrizes de implementaçã. Encraja us de cartões CRC (Classe-Respnsabilidade-Clabraçã) para identificar e rganizar as classes rientadas a bjets que sã relevantes para increment. Se um prblema de prjet difícil é encntrad, recmenda-se a criaçã imediata de um prtótip peracinal, denminad Sluçã de Pnta. Encraja-se a refabricaçã prcess de mdificar um sistema de tal md que ele nã altere cmprtament extern d códig, mas aperfeiçe a estrutura interna. O prjet é vist cm um artefat prvisóri, cntinuamente mdificad. Desenvlviment de testes unitáris das histórias antes da cdificaçã, exercitand a interface, as estruturas de dads e a funcinalidade d cmpnente e pssibilitand um feedback mais rápid quand códig é cncluíd. Prgramaçã em pares. Os fcs sã um puc diferentes, pderia-se ter um prgramadr pensand ns detalhes d códig e utr n atendiment das nrmas de prgramaçã. Integraçã diária ds códigs desenvlvids pels pares de prgramadres. Testes de regressã cm s testes unitáris gerads anterirmente. Teste de integraçã. Teste de validaçã. Teste de aceitaçã XP (testes d cliente).

60 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: SCRUM Origem: Wikipédia, a enciclpédia livre. Scrum é um métd ágil para Gerenciament de prjets. Inicialmente, Scrum fi cncebid cm um estil de gerenciament de prjets em empresas de fabricaçã de autmóveis e prduts de cnsum, pr Takeuchi e Nnaka n artig "The New New Prduct Develpment Game". Eles ntaram que prjets usand equipes pequenas e multidisciplinares (crss-functinal) prduziram s melhres resultads, e assciaram estas equipes altamente eficazes à frmaçã Scrum d Rugby (utilizada para reiníci d jg em certs cass). Jeff Sutherland, Jhn Scumnitales, e Jeff McKenna dcumentaram, cnceberam e implementaram Scrum, cm descrit abaix, na empresa Easel Crpratin em 1993, incrprand estils de gerenciament bservads pr Takeuchi e Nnaka. Em 1995, Ken Schwaber frmalizu a definiçã de Scrum e ajudu a implantá-l em desenvlviment de sftware em td mund. Scrum junta cnceits de Lean, desenvlviment iterativ e d estud de Takeuchi e Nnaka. A funçã primária d Scrum é ser utilizad para gerenciament de prjets de desenvlviment de sftware. Ele tem sid usad cm sucess para iss, assim cm Extreme Prgramming e utras metdlgias de desenvlviment. Prém, tericamente pde ser aplicad em qualquer cntext n qual um grup de pessas necessitem trabalhar juntas para atingir um bjetiv cmum, cm iniciar uma escla pequena, prjets de pesquisa científica, u até mesm planejament de um casament. Mesm que Scrum tenha sid idealizad para ser usad em gestã de prjets de desenvlviment de sftware, ele também pde ser usad para gerenciar equipes de manutençã, u cm uma abrdagem para gestã de prgramas: Scrum de Scrums. Características de Scrum Cada sprint é uma iteraçã que segue cicl PDCA e entrega increment de sftware prnt; Um backlg é um cnjunt de requisits, pririzad pel Prduct Owner (cliente); Há entrega de cnjunt fix de itens d backlg em uma série de iterações curtas u sprints; Breve reuniã diária, u scrum, em que cada participante fala sbre prgress cnseguid, trabalh a ser realizad e/u que impede de seguir avançand (também chamad de Standup Meeting u Daily Meeting, já que s membrs d time geralmente ficam em pé); Breve sessã de planejament, na qual s itens d backlg para uma sprint (iteraçã) sã definids; Retrspectiva, na qual tds s membrs da equipe refletem sbre a sprint passada. O Scrum é facilitad pr um Scrum Master, que tem cm funçã primária remver qualquer impediment à habilidade de uma equipe de entregar bjetiv d sprint. O Scrum Master nã é líder da equipe (já que as equipes sã aut-rganizadas), mas atua cm um firewall entre a equipe e qualquer influência desestabilizadra. Outra funçã extremamente imprtante de um Scrum Master é de assegurar que a equipe esteja utilizand crretamente as práticas de Scrum, mtivand-s e mantend fc na meta da Sprint. Scrum permite a criaçã de equipes aut-rganizadas, encrajand a cmunicaçã verbal entre tds s membrs da equipe e entre tdas as disciplinas que estã envlvidas n prjet. Um princípi chave d Scrum é recnheciment de que desafis fundamentalmente empírics nã pdem ser reslvids cm sucess utilizand uma abrdagem tradicinal de "cntrle". Assim, Scrum adta uma abrdagem empírica, aceitand que prblema nã pde ser ttalmente entendid u definid, fcand na maximizaçã da habilidade da equipe de respnder de frma ágil as desafis emergentes. Um ds grandes defeits d Scrum, prém, é a abrdagem de "receita de bl" d gerenciament de prjets exemplificad n Prject Management Bdy f Knwledge u PRINCE2, que tem cm bjetiv atingir qualidade através da aplicaçã de uma série de prcesss prescrits.

61 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 61 Backlg de prdut e backlg de sprint Um backlg é uma lista de itens pririzads a serem desenvlvids para um sftware. O backlg de prdut é mantid pel Prprietári d Prdut e é uma lista de requisits que tipicamente vêm d cliente. O backlg de sprint é uma interpretaçã d backlg d prdut e cntém tarefas cncretas que serã realizadas durante próxim sprint para implementar alguns ds itens principais n backlg d prdut. O backlg de prdut e de sprint sã, entã, duas cisas ttalmente diferentes, primeir cntend requisits de alt-nível e segund cntend infrmações sbre cm a equipe irá implementar s requisits. Planejament de sprint Antes de td sprint, Prprietári d Prdut, Scrum Master e a Equipe decidem n que a equipe irá trabalhar durante próxim sprint. O Prprietári d Prdut mantém uma lista pririzada de itens de backlg, backlg d prdut, que pde ser repririzad durante planejament d sprint. A Equipe selecina itens d tp d backlg d prdut. Eles selecinam smente quant de trabalh eles pdem executar para terminar. A Equipe entã planeja a arquitetura e design de cm backlg d prdut pde ser implementad. Os itens d backlg d prdut sã entã destrinchads em tarefas que se trnam backlg d sprint. Scrum simplificad Muitas rganizações têm sid resistentes às metdlgias intrduzidas em baixs níveis da rganizaçã. Prém, a adaptabilidade d Scrum permite que ele seja intrduzid de frma invisível ("stealth"), usand s três passs: Agende uma demnstraçã d sftware cm seu cliente em um mês a partir de agra; Cm equipe, tme um mês para deixar sftware prnt para uma dem, cm funcinalidades prntas, nã simplesmente telas; Na demnstraçã, btenha feedback e use- para guiar seu próxim mês de trabalh de desenvlviment. Algumas características de Scrum Clientes se trnam parte da equipe de desenvlviment (s clientes devem estar genuinamente interessads na saída); Entregas frequentes e intermediárias de funcinalidades 100% desenvlvidas; Plans frequentes de mitigaçã de riscs desenvlvids pela equipe; Discussões diárias de status cm a equipe; A discussã diária na qual cada membr da equipe respnde às seguintes perguntas: O que fiz desde ntem? O que estu planejand fazer até amanhã? Existe alg me impedind de atingir minha meta? Transparência n planejament e desenvlviment; Reuniões frequentes cm s stakehlders (tds s envlvids n prcess) para mnitrar prgress; Prblemas nã sã ignrads e ninguém é penalizad pr recnhecer u descrever qualquer prblema nã vist; Lcais e hras de trabalh devem ser energizadas, n sentid de que "trabalhar hras extras" nã necessariamente significa "prduzir mais".

62 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 62 Agendand discussões diárias Um mment bm para as discussões diárias é depis d almç. Durante a manhã pde ser cmplicad. Estas discussões de status nã demram e uma frma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadr negr. Cm as pessas tendem a ficar cansadas depis d almç, ter uma viva reuniã em pé nessa hra permite que a equipe mantenha a sua energia alta. Cm tds estiveram trabalhand durante a manhã, suas mentes estã fcadas n trabalh e nã em questões pessais. Scrum Sl Scrum é basead em pequenas equipes. Ele permite a cmunicaçã entre s membrs da equipe. Entretant, há uma grande quantidade de sftwares desenvlvids pr prgramadres sls. Um sftware send desenvlvid pr um só prgramadr pde ainda se beneficiar de alguns princípis d Scrum, cm: um backlg de prdut, um backlg de sprint, um sprint e uma retrspectiva de sprint. Scrum Sl é uma versã adaptada para us de prgramadres sl. Origem: Engenharia de Sftware, Rger Pressman, 2006 Algumas características seguidas pel SCRUM: Pendência lista pririzada de requisits u características d prjet que frnecem valr de negóci para cliente. Itens pdem ser adicinads a qualquer hra; Sprints unidades de trabalh que sã necessárias para satisfazer a um requisit definid na pendência que precisa ser cumprid em um interval de temp definid (tipicamente 30 dias). Durante sprint, s itens em pendência a que as unidades de trabalh d sprint se destinam sã cngelads; Reuniões Scrum sã reuniões curtas (nrmalmente 15 minuts) feitas diariamente pela equipe. Três questões-chave sã feitas e respndidas pr tds: O que vcê fez desde a última reuniã de equipe? Que bstáculs vcê está encntrand? O que vcê planeja realizar até a próxima reuniã? Dems entrega increment de sftware a cliente de md que a funcinalidade implementada pssa ser demnstrada e avaliada pel cliente.

63 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: FDD (FEATURE DRIVEN DEVELOPMENT) Origem: Wikipédia, a enciclpédia livre A FDD - Feature Driven Develpment (Desenvlviment Guiad pr Funcinalidades) é uma das seis metdlgias ágeis riginais, cujs representantes redigiram Manifest Ágil para Desenvlviment de Sftware, em Nessa casiã, representante da FDD fi Jn Kern, que trabalhava na TgetherSft, substituind Peter Cad. Origens A FDD nasceu num prjet em Cingapura, entre 1997 e 1999, a partir d Métd Cad (uma metdlgia cmpleta para Análise, Desenh e Prgramaçã Orientads a Objets, desenvlvida pr Peter Cad nas décadas de 1980 e 1990) e das técnicas de gerenciament iterativ, incremental e enxut de prjets utilizadas pr Jeff De Luca, um gerente de prjets australian. Seu lema é "Resultads frequentes, tangíveis e funcinais". A primeira descriçã ficial ds prcesss fi publicada n livr "Java Mdeling in Clr with UML", pr Peter Cad, Eric Lefebvre e Jeff De Luca, em O livr de referência é "A Practical Guide t Feature-Driven Develpment", pr Stephen Palmer e Jhn Mac Felsing, publicad em 2002 pela Prentice-Hall, cmpnd uma série editada pel própri Peter Cad. FDD e a Família Ágil Cm relaçã às utras metdlgias de desenvlviment de sftware, situa-se numa psiçã intermediária entre as abrdagens mais prescritivas (Prcess Unificad, Cascata tradicinal - Waterfall) e as abrdagens Ágeis (XP - Prgramaçã Extrema, Scrum, Crystal, etc.). Oferece um cnjunt ces de princípis e práticas tant para a Gestã de Prjets quant para a Engenharia de Sftware, mas cnvive bem cm abrdagens mais especialistas, cm Scrum.

64 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 64 Apesar de algumas divergências pntuais cm a XP, várias práticas prpstas pr esta última também sã utilizadas pr equipes usand FDD, cm s testes unitáris, refatraçã, prgramaçã em pares, integraçã cntínua, entre utras. Apenas a ênfase na FDD é que nã é tã grande quant na XP. A FDD também prpõe práticas cm inspeçã frmal (de desenh e de códig) e psse individual/situacinal de códig/classe, que pdem cntrastar cm algumas das práticas fundamentais da XP. A experiência da equipe e ds gerentes é que deve julgar quais práticas sã mais aprpriadas. Os Prcesss A FDD é, classicamente, descrita pr cinc prcesss: Desenvlver um Mdel Abrangente: pde envlver desenvlviment de requisits, análise rientada a bjets, mdelagem lógica de dads e utras técnicas para entendiment d dmíni de negóci em questã. O resultad é um mdel de bjets (e/u de dads) de alt nível, que guiará a equipe durante s cicls de cnstruçã. Cnstruir uma Lista de Funcinalidades: decmpsiçã funcinal d mdel d dmíni, em três camadas típicas: áreas de negóci, atividades de negóci e passs autmatizads da atividade (funcinalidades). O resultad é uma hierarquia de funcinalidades que representa prdut a ser cnstruíd (também chamad de prduct backlg, u lista de espera d prdut). Planejar pr Funcinalidade: abrange a estimativa de cmplexidade e dependência das funcinalidades, também levand em cnsideraçã a priridade e valr para negóci/cliente. O resultad é um plan de desenvlviment, cm s pactes de trabalh na sequência aprpriada para a cnstruçã. Detalhar pr Funcinalidade: já dentr de uma iteraçã de cnstruçã, a equipe detalha s requisits e utrs artefats para a cdificaçã de cada funcinalidade, incluind s testes. O prjet para as funcinalidades é inspecinad. O resultad é mdel de dmíni mais detalhad e s esquelets de códig prnts para serem preenchids. Cnstruir pr Funcinalidade: cada esquelet de códig é preenchid, testad e inspecinad. O resultad é um increment d prdut integrad a repsitóri principal de códig, cm qualidade e ptencial para ser usad pel cliente/usuári.

65 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 65 Origem: Engenharia de Sftware, Rger Pressman, 2006 Característica é uma funçã valrizada pel cliente que pde ser implementada em duas semanas u mens; Define cinc atividades de arcabuç clabrativas (prcesss); O FDD clca mais ênfase em diretrizes e técnicas de gestã de prjet d que muits utrs métds ágeis. Benefícis: Cm as características sã pequens blcs de funcinalidade passíveis de entrega, s usuáris pdem descrevê-las mais facilmente, entender cm elas se relacinam umas cm as utras e revisá-las melhr quant a ambiguidades, errs u missões; As características pdem ser rganizadas em um agrupament hierárquic relacinad a negóci; Cm uma característica é um increment de sftware passível de entrega d FDD, a equipe desenvlve características peracinais a cada duas semanas; Cm as características sã pequenas, suas representações de prjet e de códig sã mais fáceis de inspecinar; Planejament de prjet, crngramaçã e mnitraçã sã guiads pela hierarquia de características em vez de pr um cnjunt de tarefas de engenharia de sftware arbitrariamente adtad.

66 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: AUTOMATIZAÇÃO DO PROCESSO DE SOFTWARE AUTOMATIZAÇÃO DE PROCESSOS DE SOFTWARE Origem: Dissertaçã de Mestrad - DEFINIÇÃO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autr: Gleidsn Bertl. UFES Devid à influência d prcess de sftware n desenvlviment de prduts de sftware de qualidade, muit trabalh tem sid feit n sentid de apiar rganizações em seus esfrçs pela busca da qualidade de prcess. Cnfrme apntad pr ARBAOUI et al. (2002), as pesquisas na área de prcesss de sftware ns últims ans têm explrad duas principais vertentes: (i) abrdagens para mdelagem, análise e melhria d prcess de sftware; (ii) tecnlgia de api a prcess de sftware. A primeira vertente fcaliza abrdagens para estruturaçã, rganizaçã, dcumentaçã e descriçã de prcesss de sftware e inclui nrmas e mdels de qualidade de prcess de sftware, tais cm as apresentadas na seçã anterir. A segunda vertente está vltada para desenvlviment de Ambientes de Desenvlviment de Sftware (ADSs), que buscam cmbinar técnicas, métds e ferramentas para apiar engenheir de sftware na cnstruçã de prduts de sftware, abrangend tdas as atividades inerentes a prcess, tais cm planejament, gerência, desenvlviment e cntrle da qualidade. Os benefícis da utilizaçã de ADSs incluem (PRESSMAN, 2005): Facilitar a transferência de infrmaçã entre ferramentas e, cnsequentemente, entre passs d prcess de sftware; Reduzir s esfrçs para realizar atividades de gerência de cnfiguraçã, garantia de qualidade e prduçã de dcumentaçã; Aumentar cntrle d prjet, através de melhr planejament, mnitrament e cmunicaçã; Prver crdenaçã entre s recurss humans que estã trabalhand em um grande prjet de sftware. A integraçã de ferramentas ainda é um ds maires desafis ds ADSs, pis demanda representaçã cnsistente da infrmaçã, interfaces padrnizadas, significads hmgênes para a cmunicaçã entre engenheirs de sftware e ferramentas, e uma efetiva abrdagem que pssibilite prtar s ADSs para várias platafrmas (PRESSMAN, 2005). THOMAS e NEJMEH (1992), TRAVASSOS (1994), FALBO (1998) e PFLEEGER (2001), dentre utrs, prpõem que a integraçã de ferramentas em ADSs seja tratada através de uma infraestrutura que cntemple várias dimensões, dentre elas: Integraçã de Dads: trata de serviçs de repsitóri de dads, prvend armazenament e gerência de bjets, e integraçã de dads, permitind cmpartilhament de infrmações entre as ferramentas; Integraçã de Apresentaçã: diz respeit a serviçs de interface cm usuári. As interfaces de um ADS devem ser hmgêneas e cnsistentes, permitind que s desenvlvedres alternem entre as ferramentas que utilizam, sem mudanças substanciais de estil; Integraçã de Cntrle: está relacinada as serviçs de gerência de funcinalidades e mensagens, permitind uma ferramenta ntificar u iniciar uma açã em utra ferramenta, cntrland s events crrids e cmpartilhand funcinalidades; Integraçã de Prcess: é btida pela ligaçã explícita entre ferramentas e prcess de sftware. Para integrar ferramentas, é precis ter um fc frte n gerenciament d prcess de sftware. O prcess deve definir que ferramentas um engenheir de sftware pde utilizar e quand deverá ter acess às mesmas, em funçã da atividade que está realizand; Integraçã de Platafrma: trata da independência da platafrma sbre a qual funcinará a ferramenta;

67 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 67 Integraçã de Cnheciment: diz respeit as serviçs de gerência de cnheciment, permitind capturar cnheciment durante s prjets de sftware e ferecer api basead em gerência de cnheciment as engenheirs de sftware durante a realizaçã de atividades d prcess. Devid às dificuldades inerentes a cntrle de prcesss de sftware, a integraçã de prcess tem se mstrad tã imprtante que deu rigem a uma nva classe de ambientes, s Ambientes de Desenvlviment de Sftware Centrads em Prcess (ADSCPs). ADSCPs integram ferramentas para apiar desenvlviment d sftware e para apiar a mdelagem e a execuçã d prcess de sftware utilizad para desenvlver este prdut (HARRISON et al., 2000; FUGGETTA, 2000). Um ADSCP explra uma definiçã explícita d prcess de sftware e pde ser vist cm a autmatizaçã parcial desse prcess, incluind mecanisms para (CHRISTIE, 1995): (i) guiar a sequência de atividades definida; (ii) gerenciar s prduts que estã send desenvlvids; (iii) executar ferramentas necessárias para a realizaçã das atividades; (iv) permitir cmunicaçã entre as pessas; (v) clher dads de métricas autmaticamente; (vi) reduzir errs humans e (vii) prver cntrle d prjet à medida que este vai send executad. Prcesss mdelads em um ADSCP tipicamente descrevem as atividades a serem realizadas, s respnsáveis pr cada uma delas e as ferramentas de sftware a serem utilizadas. Sã criads para váris prpósits, dentre eles: dcumentaçã d prcess de sftware, melhria d prcess de sftware, gerenciament d flux de trabalh e autmatizaçã (GRUHN, 2002). Desta frma, a prver meis de descrever e implementar prcesss de engenharia de sftware, ADSCPs prvêem um mecanism de integraçã de prcess e ferramentas e, parcialmente, de autmatizaçã de tarefas (HARRISON et al., 2000). Alguns exempls de ADSCPs citads em (HARRISON et al.,2000) incluem: Adele, Arg, PCTE e SPADE. Em (ARBAOUI et al., 2002) sã citads TEMPO e APEL (cnstruíds a partir d Adele), LEU, PEACE, PIE e OZ. HOLZ et al. (2001) e RICHTER e MAURER (2003) enfcam ADSCP MILOS (Mdeling Language and Operatinal Supprt fr Sftware Prcesses), que prvê meis para definir um mdel de prcess genéric e cnfigurar plans de prjet cncrets baseads neste mdel. N cntext deste trabalh, dis ADSCPs merecem destaque: ambiente ODE (FALBO et al., 2003), n qual este trabalh fi desenvlvid, e a Estaçã TABA (BERGER, 2003) que adta uma filsfia de definiçã de prcesss crrelata à apresentada neste trabalh. A seguir, esses dis ambientes sã apresentads cm maires detalhes A Estaçã TABA Origem: Dissertaçã de Mestrad - DEFINIÇÃO DE PROCESSOS EM UM AMBIENTE DE DESENVOLVIMENTO DE SOFTWARE. Autr: Gleidsn Bertl. UFES A Estaçã TABA, desenvlvida desde 1990 (ROCHA et al., 1990), é um meta-ambiente capaz de gerar ambientes de desenvlviment de sftware adequads às particularidades de rganizações, prcesss de sftware e prjets específics. Para tal, utiliza atualmente a abrdagem de geraçã de ambientes mstrada na Figura 2.3.

68 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 68 Figura Geraçã de ambientes a partir da Estaçã TABA (BERGER, 2003) Inicialmente, é necessári criar um Ambiente Cnfigurad a partir das características da rganizaçã e de sua maturidade em desenvlver sftware. O ambiente cnfigurad cntém prcess padrã da rganizaçã e s prcesss especializads para s paradigmas de desenvlviment utilizads na rganizaçã. Esse ambiente armazena e prvê cnheciment capturad pela rganizaçã, imprtante para desenvlviment e a manutençã de sftware. Um ambiente cnfigurad cntém uma ferramenta para apiar a instanciaçã de prcesss, que tem a capacidade de gerar, a partir ds prcesss instanciads, ambientes de desenvlviment de sftware para prjets específics, s dits Ambientes de Desenvlviment de Sftware Orientads a Organizaçã (ADSOrg). Os ambientes instanciads sã s ambientes que apóiam desenvlviment ds prduts de sftware e cntêm utras ferramentas de api a desenvlviment (BERGER, 2003). A Estaçã TABA é também um ADS Centrad em Prcess, pis pssibilita mdelar explicitamente um prcess de sftware e cntrlá-l n ambiente instanciad. O ambiente pssibilita, ainda, a gestã d cnheciment da rganizaçã, definind um repsitóri de cnheciment que pde ser acessad pels ADSOrg instanciads. O prcess de instanciaçã descreve as atividades necessárias para se realizar a adaptaçã (instanciaçã) de um prcess especializad para um prjet específic, dentr d cntext de um Ambiente Cnfigurad, a saber (BERGER, 2003): Pré-Cndiçã: Identificaçã de Atividades Obrigatórias 1. Caracterizar Prjet 1.1 Definir Prjet 1.2 Identificar Características d Prjet 2. Planejar Prcess 2.1 Incluir Atividades d Tip de Sftware 2.2 Definir Mdel de Cicl de Vida 2.3 Mapear Atividades d Mdel de Cicl de Vida Verificar a Existência de Mapeament Anterir Realizar Mapeament

69 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: Excluir Atividades Nã Pertinentes 2.5 Incluir Nvas Atividades 2.6 Selecinar Técnicas de Avaliaçã 2.7 Selecinar Ferramentas 3. Instanciaçã de ADSOrg para prjet As atividades descritas sã de respnsabilidade d gerente d prjet. O resultad da instanciaçã é um prcess instanciad que cnstitui Plan d Prcess de Desenvlviment para um prjet específic. A cada nv prjet deve ser instanciad um nv ambiente (BERGER, 2003). 3.8 TEXTO COMPLEMENTAR O Ambiente ODE Origem: ODE, Labratóri de Sftware, UFES ( Alta qualidade e prdutividade sã fatres crítics n desenvlviment de sftware. Neste cntext, trna-se essencial prver ferramentas para ajudar engenheir de sftware em suas tarefas. O suprte de ferramentas influencia diretamente temp de desenvlviment d sftware, seu cust e a qualidade d prdut desenvlvid [1]. Assim, diversas ferramentas, cnhecidas cm ferramentas CASE (Cmputer-Aided Sftware Engineering), têm sid amplamente utilizadas n desenvlviment de sftware. Entretant, essas geralmente sã ferramentas isladas, que nã sã capazes de cmpartilhar serviçs, u sequer infrmações. Muit embra us de ferramentas individuais pssa trazer benefícis em atividades separadas, real pder dessas ferramentas de api smente pde ser alcançad através da integraçã [2]. Dessa frma, Ambientes de Desenvlviment de Sftware (ADSs) têm ganhad cada vez mais imprtância. Tais ambientes buscam cmbinar técnicas, métds e ferramentas para apiar engenheir de sftware na cnstruçã de prduts de sftware, abrangend tdas as atividades inerentes a prcess, tais cm de gerência, desenvlviment e cntrle da qualidade [3]. Um ADS tem bjetiv de ser um ambiente cmplet, capaz de suprtar td prcess de sftware, cm diversas ferramentas integradas trabalhand em cnjunt. ODE (Ontlgy-based sftware Develpment Envirnment) é um ADS centrad em prcess, fundamentad em ntlgias. O ambiente ODE vem send desenvlvid n Labratóri de Engenharia de Sftware da UFES (LabES) e é implementad em platafrma livre, utilizand Java cm linguagem de prgramaçã e banc de dads PstgreSQL. Algumas características de ODE que merecem destaque sã: a unifrmidade de cnceits prvida pelas ntlgias, que facilita a integraçã, deixa ambiente mais hmgêne e trna mais efetiva a cmunicaçã entre pessas e entre ferramentas; a frte base em cnheciment, que permite que ambiente fereça um suprte especializad a usuári na realizaçã de suas tarefas e pssibilita que as infrmações geradas mantenham-se interligadas e cnsistentes a lng de td prcess; e fc em ferramentas gerenciais, uma vez que a gerência é uma área de grande imprtância e ainda é bastante carente em terms de ferramentas. A seguir, sã brevemente apresentads s principais móduls e ferramentas integradas atualmente a ambiente ODE.

70 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 70 - Cntrle de Prjets (Manutençã e Caracterizaçã) ODE é direcinad a prjets. Assim, a mair parte das funcinalidades d ambiente é acessada n cntext de um prjet. O Ambiente permite que váris prjets sejam criads e cntrlads. Dessa frma, s usuáris têm acess apenas as prjets em que estejam alcads. Outr pnt relevante é a Caracterizaçã de Prjets que pssibilita a cmparaçã entre prjets e, entã, a recuperaçã de prjets similares, muit imprtante nas tarefas que fazem us de dads histórics. - Cadastr de Cnheciment (sbre Prcesss, Riscs e Qualidade) Permite que s dads rganizacinais sejam registrads n ambiente. Cm base nas ntlgias existentes atualmente em ODE, é pssível armazenar infrmações a respeit de prcesss (mdels de cicl de vida, atividades, recurss, artefats, prcediments etc.), riscs e métricas de qualidade. Cm as ferramentas integradas ferecem suprte frtemente basead nesse cnheciment, é pssível frnecer a usuári api direcinad a cnheciment rganizacinal. <<Cncept>> Prcedure 0..* sub-activity pssible adptin 0..* 0..* 0..* <<Cncept>> 0..* Activity prduct 0..* <<Cncept>> Artifact 0..* 0..* 0..* 0..* input <<Cncept>> Prcess 1 use 0..* <<Cncept>> Sftware Tl <<Cncept>> Resurce implementatin * <<Cncept>> Human Resurce <<Cncept>> Prject 0..* 0..* team allcatin 0..* <<Cncept>> Team - Cadastr de Recurss Organizacinais Gerencia s recurss humans, ferramentas de sftware e recurss de hardware da rganizaçã, assim cm s usuáris d ambiente. Pssibilita que s clabradres sejam assciads às funções que estã apts a realizar, apiand a alcaçã de recurss às atividades. Além diss, registra as ferramentas de sftware utilizadas pela rganizaçã através d ambiente, sejam elas parte integrante d ambiente, u ferramentas externas desenvlvidas independentemente dele.

71 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 71 - Definiçã de Prcesss Pr ser centrad em prcess, ODE tem esta cm uma de suas ferramentas mais centrais. É nela que sã definids s prcesss que guiarã s prjets da rganizaçã. A ferramenta utiliza um efetiv suprte d cnheciment para apiar gerente na definiçã de um mdel de cicl de vida para prcess, de suas atividades, ds artefats a serem prduzids e cnsumids, ds recurss humans, de sftware e de hardware necessáris à execuçã, e ds métds, técnicas, rteirs e nrmas utilizads. Devid à definiçã d prcess, ambiente é capaz de se cnfigurar de frma a melhr atender a prcess definid, exibind as ferramentas que devem apiar cada usuári nas atividades em que sã necessárias. - Acmpanhament de Prjets Assim que um prjet é iniciad, é pssível acmpanhá-l pr esta ferramenta. O prcess d prjet é apresentad na frma de um graf que exibe as atividades, destacand sua hierarquia, rdem de execuçã e estads atuais. Para cada uma das atividades, sã mstradas infrmações relevantes cm seus artefats, prcediments, recurss alcads e datas. Dessa frma, gerente pde mnitrar e cntrlar andament ds prjets. - Alcaçã de Recurss Humans Esta ferramenta apóia a definiçã de equipes para prjets e a alcaçã de seus membrs às atividades definidas. Cm base na necessidade de recurss humans de cada atividade (estipulada na definiçã de prcesss), s clabradres da rganizaçã pdem ser alcads às atividades, send definids seus papéis, datas de alcaçã e dedicaçã. A partir da alcaçã, ambiente se cnfigura para permitir as clabradres acess apenas às funcinalidades necessárias à realizaçã das atividades em que estã alcads.

72 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 72 - Alcaçã de Ferramentas de Sftware De frma semelhante à alcaçã de recurss humans, esta ferramenta permite alcar as ferramentas da rganizaçã às atividades que delas necessitam. A alcaçã é válida tant para ferramentas internas quant externas e também é necessária à cnfiguraçã d ambiente, dispnibilizand as ferramentas ns mments em que devem ser utilizadas. - GeRis - Gerência de Riscs Gerenciar riscs é um fatr de grande imprtância em qualquer prjet. GeRis apóia a gerência de riscs ds prjets de sftware e a elabraçã de um plan de riscs. Cm base n cnheciment rganizacinal sbre riscs, gerente pde identificar s riscs relevantes a cada prjet; avaliá-ls segund suas prbabilidades, impacts, e cnsequências; selecinar ações adequadas de mitigaçã e cntingência e, pr fim, gerar um plan de riscs para prjet. - Agenda e Registr de Esfrç Através da ferramenta de agenda, s usuáris d ambiente pdem visualizar a quais atividades de que prjets estã alcads, as datas previstas e efetivas e esfrç registrad até mment. A gerente de prjets, é frnecida uma visã mais ampla d andament das atividades. A ferramenta permite ainda que s usuáris registrem s esfrçs despendids diariamente nas atividades em que estã alcads. - EstimaODE - Estimativas de Tamanh e Esfrç Esta ferramenta pssui uma estrutura cmum que cntempla três abrdagens de estimativas: - Análise de Pnts de Funçã: apóia a realizaçã de estimativas de tamanh, utilizand a técnica de

73 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 73 pnts de funçã. Pssibilita que usuári inicie as estimativas, infrme s dads das funções d sistema, registre s níveis de influência relacinads e gere um relatóri cm s pnts de funçã determinads. Permite ainda que sejam feitas recntagens ds pnts de funçã n decrrer d prjet, aprveitand a cntagem anterir e mantend um históric para efeit cmparativ. - Análise de Pnts de Cass de Us: utiliza a técnica de pnts de cass de us para também dar suprte à realizaçã de estimativas de tamanh. Uma vez iniciada a estimativa, é pssível determinar s pess de atres e cass de us, s fatres técnics e calcular s pnts de cass de us. Também permite a geraçã de relatóris e a recntagem de pnts. - Estimativa pr Decmpsiçã d Prcess: apóia a realizaçã de estimativas de esfrç utilizand decmpsiçã d prcess e dads histórics de prjets similares. Permite estimar esfrç de prjets e suas atividades baseand-se em dads de esfrçs reais btids de prjets já realizads n ambiente. - Gerência de Cnheciment Gerenciar cnheciment prduzid durante desenvlviment de sftware é um fatr de grande imprtância e que traz vantagens à realizaçã de prjets. ODE pssui uma infra-estrutura de gerência de cnheciment que é cmpsta pr uma memória rganizacinal e pr serviçs que permitem a criaçã, recuperaçã, disseminaçã, us e manutençã de cnheciment. Alguns itens de cnheciment cm s quais ambiente lida sã lições aprendidas e artefats em geral. Cm a utilizaçã da gerência de cnheciment, s usuáris pdem registrar cnheciment que adquirem n decrrer ds prjets n própri ambiente, assim cm buscar cnheciment registrad pr utras pessas da rganizaçã. Cm pôde ser bservad, ambiente ODE pssui um abrangente crp de ferramentas úteis a várias tarefas d desenvlviment de sftware. Cntud, a pesquisa e desenvlviment cntinuam. Dessa frma, algumas ferramentas que já se encntram em fase de cnstruçã e em breve serã incrpradas a ambiente sã:

74 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 74 - Definiçã de Prcesss em Níveis A evluçã da ferramenta de definiçã de prcesss permitirá que s prcesss sejam definids em váris níveis. Assim a rganizaçã pderá definir seu Prcess Padrã, criar prcesss especializads a partir deste e instanciar s prcesss de prjets específics. Essa hierarquizaçã pssibilita que s prcesss nã sejam mais definids "a partir d zer", ecnmizand temp e esfrçs e garante uma padrnizaçã entre s prcesss, além de utras características de qualidade. Além diss, ambiente dará suprte à criaçã de váris prcesss pr prjet, permitind assim, cntrle de utrs Nrmas e Mdels de Qualidade, Cultura Organizacinal Tecnlgia de Desenvlviment, Dmíni d Prblema e Paradigma Particularidades Prcess Especializad 1 Definiçã Prcess Padrã Especializaçã Prcess de Prjet 1 Prcess Especializad n Instanciaçã Prcess de Prjet m d Prjet prcesss além d de desenvlviment, tais cm prcesss de gerência, de avaliaçã da qualidade, de frneciment, de manutençã etc. - Manipulaçã de Cnheciment Organizacinal O cnheciment sbre a rganizaçã é de grande imprtância em prjets de sftware. Se este cnheciment fr incrprad a ambiente, a realizaçã de diversas tarefas pde ser melhrada. De psse de cnheciment sbre as unidades rganizacinais, cargs, pessal, cmpetências e atividades da rganizaçã, ambiente pderá apiar, cm muit mais eficácia, tarefas cm a definiçã de prcesss, alcaçã de recurss, direcinament de perguntas, envi de infrmações úteis a andament d prjet, entre utras. - XMLDc - Dcumentaçã Autmatizada Pr ser um ambiente integrad, ODE armazena em um repsitóri únic tdas as infrmações manipuladas em suas ferramentas. Dessa frma, a dcumentaçã é amplamente facilitada. Dcuments cm plans de prjet, definiçã de prcesss, plans de riscs, realizaçã de estimativas, alcaçã de recurss, mdels e diagramas, registrs de esfrçs e utrs mais pdem ser facilmente recuperads a partir de XMLDc. A ferramenta encntra-se em reestruturaçã e permitirá a extraçã de dads d repsitóri para dcuments XML, que entã, serã transfrmads para diverss frmats cm HTML, PDF e RTF. - OODE Mdelagem UML OODE é uma ferramenta gráfica para mdelagem UML que permite a cnstruçã de diverss diagramas de frma integrada. Atualmente sã cntemplads s diagramas de cass de us, classes, bjets, estads, atividades, sequência, clabraçã, cmpnentes e implantaçã. Além diss, a OODE permite a exprtaçã e imprtaçã de mdels n frmat XMI (frmat XML padrã para intercâmbi de mdels UML), criand cmpatibilidade cm ferramentas externas. A ferramenta encntra-se em fase de aperfeiçament e testes.

75 Disciplina: Engenharia de Sftware Matéria: O Prcess de Desenvlviment de Sftware Página: 75 ODE pssui hje uma grande gama de ferramentas capazes de apiar, de frma integrada, várias atividades d desenvlviment de sftware. Diversas delas estã prntas para serem utilizadas em prjets reais, tant que já apóiam a realizaçã de alguns prjets acadêmics. Cm intuit de atender nã só as interesses de pesquisa, mas também as de mercad, LabES dispõem-se a estabelecer parcerias cm rganizações de sftware. N cntext de uma parceria realizada entre LabES e uma empresa de desenvlviment de sftware capixaba, uma primeira versã de ODE fi implantada na rganizaçã em utubr de 2004, visand apntar prtunidades de melhria n ambiente cm um td tmand pr base situações reais da rganizaçã. Cm um primeir feedback btid, algumas melhrias fram realizadas e uma segunda versã fi liberada em fevereir de [1] HARRISON, W., OSSHER, H., TARR, P. Sftware Engineering Tls and Envirnments: A Radmap, In: Prc. f The Future f Sftware Engineering, ICSE 2000, Limerick, Ireland, [2] PRESSMAN, R.S. Sftware Engineering: A Practitiner's Apprach, 5th Editin, New Yrk: McGraw-Hill, [3] FALBO, R.A. Integraçã de Cnheciment em um Ambiente de Desenvlviment de Sftware. Tese de Dutrad, COPPE/UFRJ, Ri de Janeir, LEITURA RECOMENDADA PRESSMAN, Rger. Engenharia de sftware McGraw Hill. Capítul 2 Prcess: uma visã genérica; Capítul 3 Mdels Prescritivs de Prcess; Capítul 4 Desenvlviment Ágil; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 4 Prcess de Sftware; PÁDUA FILHO, Wilsn. Engenharia de sftware: fundaments, Métds e Padrões LTC. Capítul 5: Prcesss de Sftware; BERTOLLO, Gleidsn. Dissertaçã de Mestrad. Definiçã de prcesss em um ambiente de desenvlviment de sftware. UFES Ntas de Aula Engenharia de Sftware, prf. Ricard Falb. Link: Ambiente ODE, Labratóri de Sftware, UFES. Link:

76 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 76 4 ENGENHARIA DE REQUISITOS A parte individual mais difícil da cnstruçã de um sistema de sftware é decidir que cnstruir. Nenhuma parte d trabalh danifica tant sistema resultante se fr feita errad. Nenhuma utra parte é mais difícil de cnsertar depis [Fred Brks] Uma das principais medidas d sucess de um sftware é grau n qual ele atende as bjetivs e requisits para s quais fi cnstruíd. De frma geral, a Engenharia de Requisits de Sftware é prcess de identificar tds s envlvids, descbrir seus bjetivs e necessidades e dcumentá-ls de frma aprpriada para análise, cmunicaçã e psterir implementaçã [4] [Ricard Falb, ntas de Aula, Engenharia de Sftware, 2005] O bjetiv básic das fases de Levantament de Requisits e Análise de Requisits é identificar, caracterizar e cmpreender prblema cuja sluçã será prpsta através de um sftware. E realizar tais cisas significa fazer tratament de requisits, das mais diferentes frmas. 4.1 CONCEITUAÇÃO As definições assciadas a requisit de sftware sã as mais variadas. De acrd cm Smmerville (2007): Requisits de um sistema sã descrições ds serviçs que devem ser frnecids pr esse sistema e as suas restrições peracinais Frnecida pel IEEE (1997): "Uma cndiçã u capacidade slicitada pr um usuári para reslver um prblema u para atender um bjetiv seu"; "Uma cndiçã u capacidade que um sistema u cmpnente deve pssuir para satisfazer um cntrat, um padrã, uma especificaçã, u utr dcument frmalmente estabelecid"; "Uma representaçã frmal (dcumentada) de uma cndiçã u capacidade descrita acima". Pde-se citar ainda : O cmprtament geral de um sistema visã d Cliente; O que cliente quer que sistema faça visã d Desenvlvedr; Uma especificaçã d que deve ser implementad. Assim cm há diferentes definições, existem também várias classificações para requisits. Nrmalmente apenas dis tips sã cnsiderads: Funcinais e Nã-funcinais. Uma classificaçã um puc mais cmpleta define s seguintes tips: Requisits de Negóci Os bjetivs de mais alt nível de uma rganizaçã (cntext de negóci); Requisits d Usuári As tarefas que usuári deve estar apt a realizar para pder utilizar sistema da melhr frma pssível; Requisits Funcinais As funcinalidades a serem cnstruídas (Especificaçã de Requisits descrições detalhadas d prblema);

77 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 77 Requisits Nã-Funcinais Representam as restrições impstas a sistema, u a desenvlviment deste. Exempl: desempenh, segurança, usabilidade. A fim de nrtear a identificaçã de requisits sã definids atributs destes. Alguns ds atributs que habitualmente devem ser cnsiderads na identificaçã ds requisits de um sftware sã s seguintes: Cmplet; Factível; Necessári; Nã ambígu. Questões que precisam ser respndidas: Cm capturar e categrizar adequadamente as necessidades d cliente para um dad prdut? Que artefats devems criar para representar esse cnheciment? 4.2 ENGENHARIA DE REQUISITOS Origem: Os diverss relacinaments e restrições que s requisits exercem uns sbre s utrs sã muit difíceis de serem cntrlads e gerenciads. Principalmente se cnsiderarms que algumas decisões de design que afetam um u mais requisits só serã tmadas mais adiante n desenvlviment. Pr este mtiv, s requisits precisam ser gerenciads durante td desenvlviment. Um exempl simples é a decisã de requisits de segurança mais restrits que pdem ir de encntr a requisit de melhr desempenh. A imprtância e cmplexidade de tdas as atividades relacinadas as requisits levaram, n iníci ds ans 90, a surgiment da Engenharia de Requisits. O bjetiv desta denminaçã é ressaltar que prcess de definir s requisits de sftware é uma atividade extremamente imprtante e independente das utras atividades da engenharia de sftware. Ela requer fundamentaçã e prcesss própris, e que devem ser planejads e gerenciads a lng de td cicl de vida. Os bjetivs da Engenharia de Requisits pdem ser categrizads em três grups principais [Zave]: Investigaçã de bjetivs, funções e restrições de uma aplicaçã de sftware. Ultrapassar as barreiras de cmunicaçã; Gerar estratégias para cnverter bjetivs vags em prpriedades u restrições específicas; Cmpreender priridades e graus de satisfaçã; Assciar requisits cm s váris agentes d dmíni; Estimar custs, riscs e crngramas; Assegurar cmpletude; Especificaçã d sftware. Integrar representações e visões múltiplas; Avaliar estratégias de sluções alternativas que satisfaçam s requisits; Obter uma especificaçã cmpleta, cnsistente e nã ambígua;

78 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 78 Validar a especificaçã - verificar que ela satisfaz as requisits; Obter especificações que sejam aprpriadas para as atividades de design e implementaçã; Gerenciament da evluçã e das famílias d sftware. Reutilizaçã de requisits durante prcess de evluçã; Reutilizaçã de requisits n desenvlviment de sftware similares; Recnstruçã de requisits; A engenharia de requisits é inerentemente abrangente, interdisciplinar e aberta. Ela lida cm a descriçã de bservações d mund real através de ntações aprpriadas. Os benefícis da Engenharia de Requisits sã: Cncrdância entre desenvlvedres, clientes e usuáris sbre trabalh a ser feit e quais s critéris de aceitaçã d sistema; Uma base precisa para a estimativa ds recurss (cust, pessal, prazs, ferramentas e equipaments); Melhria na usabilidade, manutenibilidade e utras qualidades d sistema; Atingir s bjetivs cm mínim de desperdíci. Uma ba especificaçã de requisits deve ser: Clara e nã-ambígua; Cmpleta; Crreta; Cmpreensível; Cnsistente; Cncisa; Cnfiável. [...] (Fim d artig) DIFICULDADES A SEREM ENFRENTADAS Trata-se de uma área até recentemente nã muit estudada. N entant a necessidade de melhrar sftware e a identificaçã deste nich cm pssível sluçã deu um grande impuls à área. Errs mais cmuns cmetids durante Levantament de Requisits: Ignrar uma parcela de clientes; Omitir um grup de requisits; Permitir incnsistências entre grups de requisits; Aceitar requisit inadequad, incrret, indefinid, u imprecis; Aceitar um requisit ambígu e incnsistente.

79 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 79 Alguns prblemas relativs à Cmunicaçã: Definiçã de cm apresentar s dads; Prblemas cm abstraçã (generalizaçã x especializaçã); Estabeleciment de uma Linguagem de cmunicaçã (vcabulári, terms utilizads). Se nã cnseguirms uma cmunicaçã adequada, cm querer extrair s requisits crretamente? Ist é, cm evitar um Dmíni de aplicaçã mal definid? Definiçã das Fntes de Infrmaçã. Cm especificar requisits sem saber de nde retirar s dads necessáris? Dads demais causam: Atrass n crngrama; Trnam difícil a identificaçã ds requisits reais d sistema; Dads de mens causam: Prvavelmente s requisits nã refletirã a real necessidade d usuári (se é que sftware pderá ser cnstruíd em um cas assim). Prblemas enfrentads pel Desenvlvedr: É frustrante tmar cnheciment da real funcinalidade desejada quand sistema já se encntra prnt; Escrevem funcinalidades implícitas e dcumentações de requisits incmpletas; Sfrem interrupções n andament d prjet; Nã discutem as necessidades e desejs cm afinc; É difícil decidir que precisa ser exatamente implementad; Pensam que já sabem que cliente necessita; Minimizam a qualidade d prdut. Prblemas enfrentads pel Cliente: Usam um prdut de sftware que nã executa as tarefas desejadas; Sente-se inibid para cmunicar as mudanças crridas; Acreditam que temp perdid na fase de cleta de requisits só irá atrasar a entrega d prdut final ( Build-me a system nw!!! ). A utilizaçã de técnicas aprpriadas permitem reslver / minimizar estes prblemas.

80 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: ATIVIDADES DA ENGENHARIA DE REQUISITOS Existem diferentes classificações sbre quais atividades sã assciadas à Engenharia de Requisits. Algumas cmumente encntradas sã: Elicitaçã de Requisits; Mdelagem de Requisits; Validaçã de Requisits. Além delas ainda pdem ser citadas atividades de api, cm pr exempl: Estud de Viabilidade; Gestã de Requisits. O estud de viabilidade cstuma crrer lg n iníci d desenvlviment d sftware, durante Planejament d Prjet. A Gestã de Requisits deve crrer durante td cicl de vida d sftware. As atividades relacinadas à Engenharia de Requisits sã cmumente realizadas durante etapas cnhecidas cm Levantament de Requisits (descberta ds requisits) e Análise de Requisits (cmpreensã e mdelagem ds requisits). A seguir há um rápid detalhament sbre tais atividades Estud de Viabilidade Um estud de viabilidade decide se sistema prpst: Cntribui para s bjetivs da rganizaçã; Pde ser cnstruíd utilizand a tecnlgia e equipe dispníveis, dentr d crngrama necessári; Pde ser integrad cm utrs sistemas. Questões a serem respndidas pelas pessas da rganizaçã: E se sistema nã fsse implementad? Quais sã s prblemas ds prcesss crrentes? Cm sistema prpst ajudará? Quais serã s prblemas de integraçã? É precis nva tecnlgia? Quais as facilidades que devem ser suprtadas pel sistema prpst? Elicitaçã de Requisits É necessári um envlviment cm ambiente de trabalh d cliente; Objetiv: Descberta de infrmações sbre prcess que deverá ser atendid pel sftware. Cnsequentemente, identificaçã das fntes destas infrmações: pessas, livrs, leis, sistemas anterires; Meis de extrair as infrmações: leitura de dcuments, engenharia reversa, bservaçã, entrevistas, questináris, etc;

81 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 81 Envlve a equipe técnica trabalhand cm clientes para cnhecer melhr dmíni da aplicaçã, s serviçs que sftware deverá prver e as restrições peracinais d mesm; Pde envlver usuáris finais, gerentes, engenheirs, especialistas de dmíni, etc. Genericamente sã chamads stakehlders (tds s envlvids de alguma frma cm prjet); Há 03 tarefas principais: Identificaçã de fntes de infrmaçã. Principais fntes: Agentes (Atres, Usuáris); Outras fntes: Dcumentaçã d macr-sistema, Plíticas, Manuais, Memrands, atas, cntrats..., Livrs sbre tema, Outrs sistemas da empresa, Outrs sistemas externs; Imprtante: Pririzar as Fntes de Infrmaçã. Atres mais imprtantes; Dcuments mais mencinads; Rede de cmunicações entre s cmpnentes d macr-sistema. Cleta de Dads a captura das infrmações necessárias. Existem diferentes maneiras de se cletar dads, entre elas pdem ser citadas: Leitura de dcuments; Observaçã; Entrevistas; Questináris; Análise de Prtcls; Reuniões; Reutilizaçã; Recuperaçã (engenharia reversa) de prjet d sftware; Cmunicaçã frma de cntat entre tds s envlvids n prjet. O que cstuma utilizar: Ferramentas, Pessal, Métds Mdelagem de Requisits Os resultads da atividade de elicitaçã sã mdelads (especificads) na frma de mdels cnceituais, para que sejam melhr cmpreendids e estruturads de frma a auxiliar a fase seguinte, de design; Prcura definir: Entradas, Saídas, Prcesss, Interfaces, Infrmações; Diferentes mdels pdem ser prduzids cada um para mments diferentes e situações diferentes; Exempls: mdels de cas de us, diagrama de classes Verificaçã e Validaçã Origem: Engenharia de Sftware, Ian Smmerville, 8ª. Ediçã A validaçã de requisits dedica-se a mstrar que s requisits definem sistema que cliente realmente deseja e está relacinada a descberta de prblemas envlvend requisits. Cstuma crrer em cnjunt cm a atividade de análise de requisits. Custs de errs de requisits sã alts e, desse md, a validaçã é muit imprtante. O cust da reparaçã de um err de requisits depis da entrega pde equivaler a 100 vezes cust de reparaçã de um err de implementaçã. As verificações realizadas nrmalmente envlvem: Verificaçã de validade. O sistema frnece as funções que melhr apóiam as necessidades d cliente?

82 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 82 Verificaçã de cnsistência. Existe algum tip de cnflit de requisits? Verificaçã de cmpleteza. Tdas as funções requisitadas pel cliente fram incluídas? Verificaçã de realism. Os requisits pdem ser implementads cm rçament e a tecnlgia dispníveis? Facilidade de verificaçã. Os requisits pdem ser verificads? Há uma série de técnicas quem pdem ser aplicadas individualmente u em cnjunt, destacand-se: Revisões de requisits - Análise manual sistemática ds requisits; Prttipaçã - Us de um mdel executável d sistema para verificar requisits; Geraçã de cass de teste - Desenvlviment de testes para requisits a fim de verificar a testabilidade. Revisã de Requisits Revisões regulares devem ser feitas enquant a definiçã de requisits está send realizada; Ambs, cliente e frnecedr, devem ser envlvids nas revisões; Revisões pdem ser frmais (cm dcuments cmplets) u infrmais. Uma ba cmunicaçã entre desenvlvedres, clientes e usuáris pde reslver prblemas ns estágis iniciais. A verificaçã a ser prcedida deve checar, entre utrs: Cnsistência; Cmpleteza; Facilidade de verificaçã. O requisit é realisticamente testável? Facilidade de cmpreensã. O requisit é adequadamente cmpreendid? Rastreabilidade. A rigem d requisit é claramente estabelecida? Adaptabilidade. O requisit pde ser mudad sem um grande impact em utrs requisits? Gestã de Requisits É prcess de gerir as mudanças ns requisits durante prcess de engenharia de requisits e própri prcess de desenvlviment de sistemas; Requisits sã inevitavelmente incmplets e incnsistentes. Nvs requisits emergem durante prcess, pis as necessidades d negóci mudam e a cmpreensã ds requisits melhra; Pde haver cntradiçã ns requisits; Mudança de requisits. A priridade de requisits diferentes pde mudar durante prcess de desenvlviment; O negóci pde sfrer alterações durante desenvlviment.

83 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: UML - LINGUAGEM DE MODELAGEM UNIFICADA Origem: Autr: Brun Rque Data: 13/11/2006 Artig: UML Que rais é iss? OBS.: Breves ajustes [...] A UML u Unified Mdeling Language (que nada tem a ver cm XML, HTML, XLS, DML, DHTML) é uma linguagem de mdelagem nã prprietária de terceira geraçã. Ela fi criada para facilitar e unifrmizar a frma de especificaçã de prjets de desenvlviment de sftware. Agra vcê deve estar se perguntand "Vu ter que aprender mais uma metdlgia?". Bem, na verdade metdlgia nã, pis a UML nã é um métd, é uma ntaçã. Um métd nrmalmente é cmpst pr uma linguagem de mdelagem (ntaçã gráfica) e pr um prcess 1 (passs para elabraçã d prjet). Dessa frma a UML, pde ser usada cm qualquer prcess já que é independente dele. [...] Breve História Para entender prque a UML se trnu um padrã mundial é interessante cnhecerms cm ela nasceu e cm se desenvlveu até chegar a sua versã atual (versã 2.0). N iníci ds cnceits de O.O. (Orientaçã a Objets), diverss métds fram apresentads para a cmunidade. Chegaram a mais de 50 entre s ans de 1989 a 1994, prém a mairia deles cmeteu err de tentar estender s métds estruturads da épca. Cm iss s maires prejudicads fram s usuáris, n cas nós, que nã cnseguiam encntrar uma maneira satisfatória de mdelar seus sistemas. Essa situaçã ficu cnhecida cm a guerra ds métds. Fi a partir da década de 90 que cmeçaram a surgir terias que prcuravam trabalhar de frma mais ativa cm paradigma da rientaçã a bjets. Diverss autres famss cntribuíram cm publicações de seus respectivs métds. Pr vlta de 1993 existiam 3 métds que mais cresciam n mercad, eram eles Bch 93 de Grady Bch, OMT-2 de James Rumbaugh e OOSE de Ivar Jacbsn. Cada um deles pssuía pnts frtes em alguma parte. O OOSE pssuía fc em cass de us (use cases), OMT-2 se destaca na fase de análise de sistemas de infrmaçã e Bch 93 era mais frte na fase de prjet. O sucess desses métds se deu principalmente a fat de nã terem tentad estender s métds já existentes. Seus métds já cnvergiam de maneira independente, entã seria mais prdutiv cntinuar de frma cnjunta. Em utubr de 1994 cmeçaram s esfrçs para unificaçã ds métds. Já em utubr de 1995 Bch e Rumbaugh lançaram um rascunh d Métd Unificad, unificand Bch 93 e OMT-2, após iss Jacbsn se juntu à equipe d prjet e Métd Unificad passu a incrprar OOSE. E fi em junh de 1996 que s três amigs, cm já eram cnhecids, lançaram a primeira versã cm s três métds, a versã 0.9 que fi batizada cm UML. Daí em diante surgiram várias nvas versões, cm pdems acmpanhar através d gráfic abaix:

84 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 84 A OMG 3 lançu uma RFP (Request fr Prpsals) para que utras empresas pudessem cntribuir cm a evluçã da UML, daí se chegu a versã 1.1. Após alcançar esta versã, a OMG passu a adtá-la cm padrã 4 e a se respnsabilizar (através da RTF Revisin Task Frce) pelas revisões. Essas revisões sã cntrladas de frma a nã prvcar uma grande mudança n escp riginal. E realmente fi iss que acnteceu, se bservarms as diferenças entre as versões, verems que de uma para a utra nã huve grande impact, que facilitu sua disseminaçã pel mund. Visã Geral A UML permite mdelar: Elements Estruturais Classes, interfaces, clabrações, cmpnentes, cass de us, classes ativas, nós; Cmprtamentais Interações, máquinas de estad; Grups de elements Pactes, subsistemas, mdels; Outrs Ntas. Relacinaments Dependências; Assciações; Generalizações; Mecanisms de Extensibilidade Estereótips; Implementações (realizatin). Tagged value; Regras (cnstraints).

85 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 85 Diagramas Um Diagrama é uma representaçã gráfica parcial u ttal de um mdel. Ist é, apresentaçã gráfica de uma cleçã de elements de mdel, geralmente prcessads cm um gráfic de arcs (relacinaments) e vértices (utrs elements de mdel) cnectads. A UML 2.0 (versã atual) define 13 tips de diagramas dividids em 2 categrias (Estruturais e Cmprtamentais). Mdels Estátics u Estruturais Diagramas estátics u estruturais definem estaticamente a arquitetura de um mdel. Sã usads para mdelar as cisas que cmpõem um mdel - as classes, s bjets, as relações e s cmpnentes físics. Além diss, também sã usads para mdelar s relacinaments e as dependências entre elements. Abaix tems uma tabela cm s diagramas estruturais e suas respectivas descrições: Diagrama de pactes Diagrama de classes Diagrama de bjets Diagrama de estrutura cmpsta Diagrama de cmpnentes Diagrama de instalaçã É usad para dividir mdel em cntainers lógics u em "pactes" e descreve as interações entre eles em alt nível. Define s elements básics de um mdel - as classes e s relacinaments. Similar a diagrama de classes, prém sua principal diferença é que ele apresenta s atributs cm valres. Crrespnde a uma instância d diagrama de classes, mstrand estad de um sistema em um determinad pnt d temp. Frnece meis de definir a estrutura de um element e de fcalizá-la n detalhe, na cnstruçã e em relacinaments interns. Apresenta as dependências ente cmpnentes de sftwares, incluind implementaçã de classes, arquivs de códig fnte, arquiv de códig binári, arquivs executáveis e scripts. Mstra a cnfiguraçã ds elements de prcessament em temp de execuçã, além ds cmpnentes, prcesss e bjets d sistema neles existentes.

86 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 86 Mdels Dinâmics u de Cmprtament Os diagramas dinâmics u de cmprtament apresentam as variedades da interaçã e d estad instantâne dentr de um mdel enquant é executad. Diagrama cass de us Diagrama de máquina de estads Diagrama de atividades Diagrama de cmunicaçã Diagrama de sequência Diagrama de Temp Diagrama de Interatividade É usad para mdelar interações d usuári/sistema. Definem cmprtament, as exigências e resultad esperad de uma funcinalidade. Representa as ações crridas em repsta a recebiment de um event, nde cada pnt de parada representa um estad da aplicaçã. É uma variaçã d diagrama de máquina de estads. Representa a execuçã das ações e as transições que sã acinadas pela cnclusã de utras ações u atividades. Exibe uma interaçã, cnsistind de um cnjunt de bjets e seus relacinaments, incluind as mensagens que pdem ser trcadas entre eles. É usad para representar cmprtament das perações, métds (prcediments u funções) entre classes de um cenári. É a fusã d diagrama de sequência e estad, apresentand cmprtament ds bjets e sua interaçã em uma escala de temp, u seja, estad ds bjets em relaçã a temp e as mensagens que mdificam esse estad. É a fusã d diagrama de atividades e sequência. Ele permite que fragments das interações sejam facilmente cmbinads as pnts e fluxs de decisã. [...] Observações: 1 - É respnsabilidade d prcess decidir quais e quand s artefats serã prduzids, a equipe e atividades necessárias para criar e manter esses artefats. 2 - Exempls: Requisits, Cas de Us, Plan de Teste, códig-fnte, plans de prjets, etc.. 3 A OMG é uma rganizaçã internacinal, fundada em Prmve teria e prática da tecnlgia rientada a bjets em desenvlviment de sistemas. 4 A versã 1.1 fi ferecida a OMG em Julh de 1997 e fi aceita em Setembr d mesm an. Em 14 de Nvembr de 1997, a UML 1.1 passu a ser adtada cm padrã pela OMG. 4.4 LEVANTAMENTO DE REQUISITOS O levantament de requisits é a etapa mais imprtante em terms de retrn em investiments feits para um prjet de desenvlviment. Muits sistemas fram abandnads u nem chegaram a us prque s membrs da equipe nã dispensaram temp suficiente para cmpreender as necessidades d cliente em relaçã a nv sistema. Em um estud basead em sistemas feit em 1997, Carper Jnes mstru que s custs resultantes da má realizaçã desta etapa de entendiment pdem chegar a 200 vezes realmente necessári (Jnes, 1997). (

87 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 87 A grande pergunta a ser respndida neste mment é: O que cliente deseja d sistema a ser desenvlvid? Diferentes metdlgias prpõem diferentes maneiras de se prceder a levantament de requisits. Hje em dia, as tarefas que cstumam ser realizadas sã: Definiçã d Escp; Descberta / Cleta de requisits; Mdelagem de Requisits (Exempl: Cass de Us). É precis ter-se em mente seguinte: O Levantament de Requisits é a etapa nde sã identificadas as necessidades d cliente, e cnsequentemente as características d prblema que deve ser reslvid pel sftware em cnstruçã; É fcada em cmpreender O QUE é prblema, sem se precupar em COMO a sluçã d prblema será implementada; Antes de efetivamente iniciar a identificaçã ds Cass de Us, e seu detalhament, é necessári gerar alguma cmpreensã sbre prblema, que pde vir através de uma Descriçã de Mini-Mund, u ainda a definiçã d Escp d Prblema. N Escp habitualmente sã identificads: O Ambiente da Empresa descriçã da empresa e d ambiente de trabalh nde sistema será desenvlvid; O Prblema identificaçã das principais características d prblema que precisará ser transprtad para sftware, destacand as dificuldades que cliente vem enfrentand atualmente pr nã ter um sistema infrmatizad, u pr ter um sistema infrmatizad que nã atende as suas reais necessidades; A prpsta de sluçã identificaçã das principais características da sluçã a ser prpsta para cliente, sem entrar em detalhes, mas cmentand cm serã reslvids s prblemas listads anterirmente; Os benefícis esperads identificaçã ds principais benefícis que cliente irá adquirir em seu ambiente de trabalh a utilizar a sluçã prpsta; Os limites / restrições cas sistema a ser desenvlvid tenha algum limite / restriçã de us u de prcesss a serem implementads, identificads desde 1º. mment é interessante já deixá-l caracterizad desde este mment. Principais dcuments gerads em tal etapa: Definiçã de Requisits Basicamente, uma lista sucinta de requisits. Tal dcument pde nã ser gerad, cnsiderand-se que psterirmente s requisits devem estar cntemplads na Especificaçã de Requisits. Prém sua elabraçã pde auxiliar à Gestã de Requisits. Além de ser interessante para identificaçã de requisits nã-funcinais; Especificaçã de Requisits a ser detalhad psterirmente. OBS.: Em anex a este material há mdels / exempl ds dcuments acima identificads TÉCNICAS DE LEVANTAMENTO DE REQUISITOS Cleta de Dads A cleta de dads é a atividade referente à captura ds requisits que cmpõe prblema send mapead. Um ds bjetivs da Engenharia de Requisits é ultrapassar barreiras de cmunicaçã entre clientes e usuáris e s Engenheirs de Sftware, para que s requisits pssam ser cletads eficientemente. Dentre as várias técnicas de cleta de dads dispníveis, três pdem ser destacadas:

88 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 88 Entrevistas; Observaçã; Investigaçã. Estas técnicas sã cmplementares e pdem ser usadas em cnjunt. A Entrevista é nrmalmente a técnica mais utilizada. Engenheirs de Sftware entrevistam clientes para definir s bjetivs gerais e restrições que sftware deverá ter (em um primeir mment). A medida que cmpreendem as características d prblema, nvas entrevistas sã agendadas, cm bjetiv de descbrir nvs requisits, bem cm retirar dúvidas sbre requisits já identificads. A entrevista deve ser feita de frma bjetiva, visand bter máxim pssível de infrmações d cliente. Diversas seções de entrevistas pdem ser realizadas. E existem várias técnicas de se realizar e registrar uma entrevista. Na Observaçã s engenheirs de sftware devem estar inserids na rtina de trabalh da instituiçã, tentand entender e descrever as principais atividades que sã realizadas. O ambiente é bservad, mas nã há interaçã entre s bservadres e s bservads. Devem ser identificadas quais as atividades que pdem ser autmatizadas, quem sã s ptenciais usuáris, quais tarefas eles querem realizar cm a ajuda d sftware e cm tais tarefas sã realmente realizadas. Uma Investigaçã vem cmplementar as técnicas acima cm api da análise de dcuments, pis há infrmações que sã difíceis de serem btidas através de entrevistas e/u bservações. Em tal técnica pde-se bter infrmações cm quais tips de dcuments sã gerads, seus frmats, descrições de prcediments padrões, leis, cntext da rganizaçã Mdelagem de Cass de Us Origem: Análise de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. Capítul 3 Mdelagem de Cass de Us. OBS.: Breves adaptações Quand um nv sistema precisa ser cnstruíd, surge uma imprtante questã: Cm caracterizar s requisits d sistema de um md adequad para a Engenharia de Sftware, uma vez que, é necessári identificar quais s bjets/entidades relevantes, cm eles se relacinam e cm se cmprtam n cntext d sistema. Além diss, é precis especificar e mdelar prblema de maneira que seja pssível criar um prjet efetiv e pssibilitar uma cmunicaçã eficiente. O desenvlviment de sistemas é um prcess de cnstruçã de mdels, que tipicamente cmeça cm um mdel de requisits e termina cm um mdel de implementaçã (códig). Mdels de bjets (diagramas de classes, diagramas de interaçã,etc...) e mdels estruturads (diagramas de entidades e relacinaments, diagramas de flux de dads, etc...) incluem detalhes, tais cm, a estrutura interna ds bjets/entidades, suas assciações, cm eles interagem dinamicamente e cm invcam cmprtament ds demais. Estas infrmações sã necessárias para prjetar e cnstruir um sistema, mas nã sã suficientes para cmunicar requisits. Elas nã capturam cnheciment sbre as tarefas d dmíni e, prtant, é difícil verificar se um mdel deste tip realmente crrespnde a sistema que tem de ser cnstruíd [Jacbsn96]. Assim, primeir mdel d sistema a ser cnstruíd deve ser passível de cmpreensã tant pr desenvlvedres - analistas, prjetistas, prgramadres e testadres - cm pela cmunidade usuária - clientes e usuáris. Mdels estruturads e de bjets sã muit cmplexs e, prtant, nã servem para este prpósit. Este mdel inicial deve descrever sistema, seu ambiente e cm sistema e ambiente estã relacinads. Em utras palavras, ele deve descrever sistema segund uma perspectiva externa. Mdels de cas de us (use cases) sã uma frma de estruturar esta visã externa. Cm própri nme sugere, um cas de us é uma maneira de usar sistema. Usuáris interagem cm sistema, interagind cm seus cass de us. Tmads em cnjunt, s cass de us de um sistema representam tud que s usuáris pdem fazer cm este sistema. Cass de us sã s itens que um desenvlvedr vende a seus clientes.

89 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 89 Deve-se ntar que mdels de cas de us sã independentes d métd de análise a ser usad. Desenvlvedres devem mdelar s cass de us explicitamente n iníci d desenvlviment de sftware. Em td prjet, para que seja bem sucedid, cass de us devem ser identificads [Jacbsn96]. Em suma, prcess de desenvlviment de sftware cmeça pel entendiment de cm sistema será usad. Uma vez que as maneiras de usar sistema tenham sid definidas, a mdelagem d negóci pde, entã, ser iniciada. Cass de Us Nenhum sistema cmputacinal existe isladamente. Td sistema interage cm atres humans u utrs sistemas, que utilizam esse sistema para algum prpósit e esperam que sistema se cmprte de acrd cm as maneiras previstas. Um cas de us especifica um cmprtament de um sistema segund uma perspectiva externa e é uma descriçã de um cnjunt de sequências de ações realizadas pel sistema (e pel(s) atr(es) que interage(m) cm ele) para prduzir um resultad de valr bservável pr um atr [Bch00]. Em essência, um cas de us (use case) é uma interaçã típica entre um atr (usuári human, utr sistema cmputacinal u um dispsitiv) e um sistema. Um cas de us captura alguma funçã visível a atr e, em especial, busca atingir uma meta d usuári [Fwler97]. Os cass de us frnecem uma maneira para s desenvlvedres chegarem a uma cmpreensã cmum cm s usuáris finais d sistema e cm s especialistas d dmíni. Além diss, servem para ajudar a validar e verificar sistema à medida que ele evlui durante seu desenvlviment. Assim, s cass de us nã apenas representam cmprtament desejad d sistema, mas também pdem ser utilizads cm a base de cass de teste para sistema, principalmente s testes de integraçã e de sistema [Bch00]. Cass de us têm dis imprtantes papéis: 1. Eles capturam s requisits funcinais de um sistema. Um mdel de cas de us define cmprtament de um sistema (e a infrmaçã assciada) através de um cnjunt de cass de us. O ambiente d sistema é definid pela descriçã ds diferentes usuáris. Estes usuáris utilizam sistema através de um númer de cass de us. 2. Eles ferecem uma abrdagem para a mdelagem de sistemas. Para gerenciar a cmplexidade de sistemas reais, é cmum apresentar s mdels d sistema em um númer de diferentes visões. Em uma abrdagem guiada pr cass de us, pde-se cnstruir uma visã para cada cas de us, ist é, em cada visã sã mdelads apenas aqueles elements que participam de um cas de us específic. Um particular element pde, é clar, participar de váris cass de us. Ist significa que um mdel d sistema cmplet só é vist através de um cnjunt de visões uma pr cas de us. Encntra-se tdas as respnsabilidades de um element de mdel, lhand tds s cass de us nde este tem um papel. Além de serem uma ferramenta essencial na caracterizaçã ds requisits de um sistema, cass de us têm um papel fundamental n planejament e cntrle de prjets iterativs. A captura ds cass de us é a primeira atividade a ser realizada n desenvlviment, prpriamente dit. A mairia ds cass de us é nrmalmente gerada durante a fase de levantament de requisits, mas utrs cass de us pdem ser descberts à medida que trabalh prssegue. Td cas de us é um requisit ptencial e, enquant um requisit nã é capturad, nã é pssível planejar cm tratá-l. Usualmente, em primeir lugar, cass de us sã listads e discutids, para só entã, se realizar alguma mdelagem. Entretant, em alguns cass, a mdelagem cnceitual ajuda a descbrir cass de us. Um cas de us pde ser capturad através de cnversas cm usuáris típics, discutind as várias cisas que eles querem fazer cm sistema. Cada uma dessas interações discretas cnstitui um

90 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 90 cas de us. Dê a ela um nme e escreva uma descriçã textual pequena (nã mais d que uns pucs parágrafs). Nã tente capturar tds s detalhes de um cas de us lg n iníci. Os bjetivs d usuári pdem ser pnt de partida para a elabraçã ds cass de us. Prpnha um cas de us para satisfazer cada um ds bjetivs d usuári. A partir deles, estude as pssíveis interações d usuári cm sistema e refine mdel de cass de us. Diagramas de Cass de Us Pde-se dizer que um diagrama de cass de us é uma representaçã gráfica de quem faz que. Diagramas de cass de us especificam as funcinalidades que um sistema tem de ferecer, segund diferentes perspectivas ds usuáris. Basicamente, um diagrama de cass de us apresenta dis elements: s atres e s cass de us. Um atr é um papel que um usuári, utr sistema u dispsitiv desempenha cm respeit a sistema. Cass de us representam funcinalidades requeridas externamente. Uma assciaçã entre um atr e um cas de us significa que estímuls pdem ser enviads entre atres e cass de us. Os atres pderã estar cnectads as cass de us smente pr mei de assciações. A assciaçã entre um atr e um cas de us indica que atr e cas de us se cmunicam entre si, cada um cm a pssibilidade de enviar e receber mensagens [Bch00]. A figura 3.1 mstra a ntaçã básica da Linguagem de Mdelagem Unificada UML [Bch00] para diagramas de cass de us. Um atr mdela qualquer cisa que precise interagir cm sistema, tais cm usuáris e utrs sistemas que se cmunicam cm sistema em questã. Atres sã externs a sistema; s cass de us cmprtam s elements de mdel que residem dentr d sistema. Assim, a se definir frnteiras entre atres e cass de us, está-se delimitand escp d sistema. Pr estarem fra d sistema, atres estã fra d cntrle de nssas ferramentas de mdelagem e nã precisam ser descrits em detalhes. Atres representam tud que tem necessidade de trcar infrmaçã cm sistema. Nada mais extern a sistema deve ter impact sbre sistema. É imprtante realçar a diferença entre atr e usuári. Um usuári é uma pessa que utiliza sistema, enquant um atr representa um papel específic que um usuári pde desempenhar. Váris usuáris em uma rganizaçã pdem interagir cm sistema da mesma frma e, prtant, desempenham mesm papel. Um atr representa exatamente um cert papel que diverss usuáris pdem desempenhar. Assim, atres pdem ser pensads cm classes, ist é, descrições de um cmprtament, enquant usuáris pdem desempenhar diverss papéis e, assim, servir cm instâncias de diferentes classes de atres. A lidar cm atres, é imprtante pensar em terms de papéis a invés de usuáris. Um bm pnt de partida para a identificaçã de atres é verificar pr que sistema deve ser desenvlvid, prcurand bservar que atres sistema se prpõe a ajudar. Quand um atr interage cm sistema, nrmalmente, ele realiza uma sequência cmprtamentalmente relacinada de ações em um diálg cm sistema. Tal sequência cmpreende um cas de us. Um cas de us é, de fat, uma maneira específica de utilizar

91 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 91 sistema, através da execuçã de alguma parte de sua funcinalidade. Cada cas de us cnstitui um curs cmplet de events cm um atr e especifica a interaçã que acntece entre atr e sistema. O cnjunt de tdas as descrições de cass de us especifica tdas as maneiras de se usar sistema e, cnsequentemente, a sua funcinalidade cmpleta. Um bm cas de us cmpreende uma sequência de transações realizadas pel sistema, que prduz um resultad de valr bservável para um particular atr. Pr prduzir um resultad de valr bservável, querems dizer que um cas de us tem de garantir que um atr realiza uma tarefa que tem um valr identificável. Iss é imprtante para se bter cass de us que nã sejam muit pequens. Pr utr lad, a identificaçã de um particular atr é imprtante na btençã de cass de us que nã sejam muit grandes. Uma ba fnte para identificar cass de us sã s events externs. Pense sbre tds s events d mund extern para s quais sistema deve reagir. Identificar estes events pde ajudá-l a identificar s cass de us. Para sistemas grandes, pde ser difícil prpr uma lista de cass de us. Nestas situações, é mais fácil chegar primeir a uma lista de atres e tentar elabrar s cass de us para cada atr. Para cada curs cmplet de events cm um atr, um cas de us é identificad. Nem sempre está clar qual funcinalidade deve ser clcada em cass de us separads u que é apenas uma variante (um cenári) de um cas de us. A priri, se as diferenças frem pequenas, elas pdem ser descritas cm variantes d cas de us; cas cntrári, devem ser descritas cm cass de us separads. Qualquer que seja a abrdagem utilizada, devems sempre identificar s atres de um cas de us, descbrir qual é bjetiv real d usuári e cnsiderar mds alternativs de satisfazer estes bjetivs. Descriçã de Cass de Us Um cas de us deve descrever O QUE um sistema faz. Geralmente, um diagrama de cass de us é insuficiente para este prpósit. Assim, deve-se especificar cmprtament de um cas de us pela descriçã textual de seu flux de events, de md que alguém de fra pssa cmpreendê-l. A escrever flux de events, deve-se incluir cm e quand cas de us inicia e termina, quand cas de us interage cm s atres e utrs cass de us e quais sã as infrmações transferidas e flux básic e fluxs alternativs d cmprtament [Bch00]. Uma vez que cnjunt inicial de cass de us estiver estabilizad, cada um deles deve ser descrit em mais detalhes. Primeir, deve-se descrever flux de events principal (u curs básic), ist é, curs de events mais imprtante, que nrmalmente crre. Esse curs básic pde ainda ser rganizad em cenáris / sub-fluxs. Events e errs que pssam vir a crrer devem ser descrits em curss alternativs. Nrmalmente, um cas de us pssui apenas um únic curs básic (para cada pssível cenári), mas diverss curss alternativs. Tmems cm exempl, um caixa autmátic de banc, cuj diagrama de cass de us é mstrad na figura 3.2.

92 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 92 O cas de us Efetuar Saque pderia ser descrit da seguinte maneira: Curs Principal Uma mensagem de saudaçã é apresentada. O cliente insere seu cartã n caixa autmátic, que lê códig da tarja magnética e checa se ele é aceitável. Se cartã é aceitável, caixa pede a cliente para infrmar a senha e fica aguardand até que ela seja infrmada. O cliente infrma a senha. Se a senha estiver crreta, caixa slicita que cliente infrme tip de transaçã e fica aguardand. O cliente selecina a pçã saque. O caixa mstra uma tela para que seja infrmada a quantia. O cliente infrma a quantia a ser sacada. O caixa envia uma requisiçã para sistema bancári para que seja efetuad um saque na quantia especificada. Se saque é autrizad, as ntas sã preparadas para serem entregues, cartã é ejetad, um recib é emitid e as ntas liberadas. Curss Alternativs O cartã nã é aceitável: Se cartã nã é aceitável prque sua tarja magnética nã é passível de leitura u é de um tip incmpatível, cartã é ejetad cm um bip. Senha incrreta: Se a senha infrmada está incrreta, uma mensagem deve ser mstrada para cliente que pderá entrar cm a senha crreta. Cas cliente infrme três vezes senha incrreta, cartã deverá ser cnfiscad. Saque nã autrizad: Se saque nã fr aceit pel Sistema Bancári, uma mensagem infrmand cliente é mstrada pr 10 segunds e cartã é ejetad. Cancelament: O cliente pde sempre cancelar a transaçã em qualquer mment que lhe seja perguntada alguma infrmaçã. Ist resultará na ejeçã d cartã e n términ da transaçã. Cm vist pel exempl anterir, um cas de us pde ter um númer de curss alternativs que pdem levar cas de us pr diferentes fluxs. Tant quant pssível, esses curss alternativs, frequentemente curss de exceçã, devem ser antads durante a especificaçã de um cas d us. Assciações entre Cass de Us Uma vez que um mdel de cas de us expressa apenas a visã externa d sistema, cmunicações internas entre elements dentr d sistema nã devem ser mdeladas. Cntud, para permitir uma descriçã mais apurada ds cass de us em um diagrama, três tips de relacinaments entre cass de us pdem ser empregads. Cass de us pdem ser descrits cm versões especializadas de utrs cass de us (relacinament de generalizaçã/especializaçã); cass de us pdem ser incluíds cm parte de utr cas de us (relacinament de inclusã); u cass de us pdem estender cmprtament de um utr cas de us básic (relacinament de extensã). O bjetiv desses relacinaments é trnar um mdel mais cmpreensível, evitar redundâncias entre cass de us e permitir descrever cass de us em camadas. O relacinament de inclusã entre cass de us significa que cas de us base incrpra explicitamente cmprtament de utr cas de us. O lcal em que esse cmprtament é incluíd deve ser indicad na descriçã d cas de us base, através de uma referência explícita à chamada a cas de us incluíd. Um relacinament de inclusã é empregad quand há uma prçã de cmprtament que é similar a lng de um u mais cass de us e nã se deseja repetir a sua descriçã. Para evitar redundância e assegurar reus, extrai-se essa descriçã e cmpartilhase a mesma entre diferentes cass de us. Um relacinament de inclusã é representad pr uma dependência, esteretipada cm inclui (include), cm mstra a figura 3.3.

93 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 93 N exempl d caixa autmátic, pdems perceber que tds s três cass de us têm em cmum uma prçã que diz respeit à transaçã inicial d cartã. Neste cas, um relacinament inclui deve ser empregad, cm mstra a figura 3.3. O cas de us Validar Cliente pderia ser descrit da seguinte frma: Curs Nrmal Uma mensagem de saudaçã é apresentada. O cliente insere seu cartã n caixa autmátic, que lê códig da tarja magnética e checa se ele é aceitável. Se cartã é aceitável, caixa pede a cliente para infrmar a senha e fica aguardand até que ela seja infrmada. O cliente infrma a senha. Se a senha estiver crreta, caixa slicita que cliente infrme tip de transaçã e fica aguardand. Curss Alternativs O cartã nã é aceitável: Se cartã nã é aceitável prque sua tarja magnética nã é passível de leitura u é de um tip incmpatível, cartã é ejetad cm um bip. Senha incrreta: Se a senha infrmada está incrreta, uma mensagem deve ser mstrada para cliente que pderá entrar cm a senha crreta. Cas cliente infrme três vezes uma senha incrreta, cartã deverá ser cnfiscad. Cancelament: O cliente pde sempre cancelar a transaçã em qualquer mment que lhe seja perguntada alguma infrmaçã. Ist resultará na ejeçã d cartã e n términ da transaçã. Cm esta captura islada d cas de us de Validar Cliente, cas de us Efetuar Saque passaria a apresentar a seguinte descriçã: Curs Nrmal O cliente executa cas de us Validar Cliente. O cliente selecina a pçã saque. O caixa slicita que seja infrmada a quantia. O cliente infrma a quantia a ser sacada. O caixa envia uma requisiçã para sistema bancári para que seja efetuad um saque na quantia especificada. Se saque é autrizad, as ntas sã preparadas para serem entregues, cartã é ejetad, um recib é emitid e as ntas liberadas.

94 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 94 Curss Alternativs Saque nã autrizad: Se saque nã fr aceit pel Sistema Bancári, uma mensagem infrmand cliente é mstrada pr 10 segunds e cartã é ejetad. Cancelament: O cliente pde sempre cancelar a transaçã em qualquer mment que lhe seja perguntada alguma infrmaçã. Ist resultará na ejeçã d cartã e n términ da transaçã. O relacinament de generalizaçã entre cass de us significa que cas de us filh herda cmprtament e significad d cas de us pai. O cas de us filh deverá acrescentar u sbrescrever cmprtament de seu pai e pderá ser substituíd em qualquer lcal n qual pai apareça [Bch00]. Vltand a exempl d sistema de caixa autmátic, supnha que haja duas frmas adtadas para se validar cliente: a primeira através de senha, cm descrit anterirmente, e a segunda pr mei de análise da retina d cliente. Neste cas, pderiam ser criadas duas especializações d cas de us Validar Cliente, cm mstra a figura 3.4. Um relacinament de extensã entre cass de us significa que cas de us base incrpra implicitamente cmprtament de um utr cas de us em um lcal especificad em sua descriçã cm send um pnt de extensã. O cas de us base pderá permanecer islad, mas, sb certas circunstâncias, seu cmprtament pderá ser estendid pel cmprtament de um utr cas de us [Bch00]. Um relacinament de extensã é utilizad para mdelar uma parte de um cas de us que usuári cnsidera cm pcinal. Desse md, separa-se cmprtament pcinal d cmprtament brigatóri. Um relacinament de extensã também pderá ser empregad para mdelar um subflux separad, que é executad smente sb determinadas cndições. Assim cm relacinament de inclusã, relacinament de extensã é representad cm uma assciaçã de dependência, agra esteretipada cm estende (extend). O relacinament estende ns permite capturar s requisits funcinais de um sistema cmplex de frma incremental. Inicialmente, as funções básicas sã entendidas, para só entã a cmplexidade ser intrduzida. Na mdelagem de cass de us, devems primeir descrever s cass de us básics, para só entã estendê-ls para permitir descrever cass de us mais avançads. O cas de us n qual a nva funcinalidade é adicinada deve ter um curs de events cmplet e significativ pr si própri. Assim, sua descriçã deve ser cmpletamente independente. Supnha que, n exempl d caixa autmátic, deseja-se cletar dads estatístics sbre us da transaçã de saque para alimentar caixa eletrônic cm as ntas mais adequadas para saque. Para tal, pderíams estender cas de us Efetuar Saque, de md que, quand necessári, um utr cas de us, denminad Cletar Infrmações Estatísticas de Saque, cntasse e acumulasse tip das ntas entregues em um saque. A figura 3.5 ilustra este cas.

95 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 95 O relacinament estende é usad, entã, para mdelar extensões a utrs cass de us cmplets e é utilizad para mdelar: Partes pcinais de cass de us; Curss cmplexs e alternativs; Sub-sequências que sã executadas apenas em certs cass; u A inserçã de diverss cass de us diferentes dentr de um utr. A quebra de um cas de us em váris pde crrer tant na fase de levantament de requisits, quant nas fases de análise e prjet. Na fase de levantament de requisits, é interessante desmembrar aqueles cass de us que se apresentam muit cmplicads. Entretant, há cass de us cuja cmplexidade glbal nã deve ser detalhada antes da fase de prjet. Para utilizar s relacinaments de inclusã e extensã, aplique as seguintes regras: Utilize relacinament estende quand estiver descrevend uma variaçã de um curs nrmal; Utilize relacinament inclui quand huver repetiçã em dis u mais cass de us separads e fr desejável evitar esta repetiçã. Diagrama de Pactes Durante a análise e descriçã detalhada ds cass de us, sistema é cuidadsamente estudad. Uma vez que, geralmente, s cass de us enfcam uma particular funcinalidade, é pssível analisar a funcinalidade ttal d sistema de maneira incremental. Deste md, cass de us para áreas funcinalmente diferentes pdem ser desenvlvids independentemente e, mais tarde, reunids para frmar um mdel de requisits cmplet. Cm iss, permite-se enfcar um prblema de cada vez, abrind caminh para um desenvlviment incremental. À medida que s mdels crescem, é imprtante dividi-ls para facilitar a leitura e entendiment. Dividir um sistema cmplex em subsistemas é sempre uma ba pçã. Para dividir e reunir cass de us em grups relacinads cnceitual e semanticamente, a UML ferece cm ferramenta de mdelagem s pactes. A figura 3.6 mstra um exempl n cntext de um sistema bancári. Neste exempl, sistema bancári nã está mais send cnsiderad um utr sistema, mas um subsistema d mesm sistema d caixa autmátic. A assciaçã de dependência entre s pactes mstrada nessa figura indica que pacte Caixa Autmátic slicita serviçs d pacte Cntas.

96 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 96 Uma vez que a funcinalidade d sistema tiver sid capturada ns cass de us, ela deve ser alcada a diferentes elements de mdelagem. Um element de mdelagem, bviamente, pde ser cmum a diverss cass de us. Basicamente, mapeament de um cas de us em elements de mdel pde ser apiad pels seguintes princípis: As funcinalidades ds cass de us que lidam cm registr e a manipulaçã de infrmaçã sã mapeadas diretamente para elements em um mdel de análise. As funcinalidades diretamente dependentes d ambiente d sistema representam funcinalidades requeridas pela interface d sistema e, prtant, sã tratadas na fase de design, especificamente n design da interface d sistema. Finalmente, funcinalidades que tipicamente envlvem cntrle de uma aplicaçã devem ser mapeadas em elements n prjet d cntrle d sistema RESUMO Origem: Mdelagem Orientada a Objet, Engenharia de Sftware, , UNESP Diagramas de Cas de us Especificam a visã externa d sistema; Descrevem cm sistema é percebid pr seus usuáris; Descrevem as interações entre s usuáris e sistema; Descrevem uma sequência de ações que representam um cenári principal (perfeit) e cenáris alternativs, demnstrand cmprtament de um sistema; Objetiv da mdelagem de cass de us: Separar as funcinalidades d sistema, agrupand um cnjunt de ações que tenham um bjetiv bem definid; Ntaçã: Cas de Us 1 Atr Cas de Us 2

97 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 97 Atr Representa um cnjunt cerente de papéis que s usuáris de cass de us desempenham quand interagem cm esses cass de us; Ser human, dispsitiv de hardware, u utr sistema; Os atres nã sã parte d sistema: representam interações individuais cm sistema de maneira específica; Os atres se cnectam as cass de us smente pr assciaçã. A assciaçã indica que atr e cas de us se cmunicam, cada um cm a pssibilidade de enviar e receber mensagens; Cas de Us Descreve que um sistema faz, mas nã especifica cm iss é implementad; Deve ter um nme que distingue ds demais cass de us; O cmprtament de um cas de us é especificad através de um, u mais, cenáris; Outr exempl de uma descriçã simplificada e parcial de Cas de Us: Dicas para a mdelagem ds Cass de Us: 1 Pde-se iniciar identificand uma lista de atres u uma lista de cass de us (a partir de uma lista pde-se chegar à utra).

98 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 98 2 Dad um cas de us, identificams seus atres a partir de questões cm: Quais atres sã respnsáveis pr este cas de us? 3 Dad um atr, identificams sua interaçã cm sistema: Quais sã s serviçs que sistema deve ferecer a esse atr? 4 Identificar cenáris cmuns a váris cass de us. (fatraçã ds cenáris cmuns em cass de us separads) e dispnibilizá-ls através de assciações entre cass de us DOCUMENTAÇÃO Existem várias prpstas sbre pssíveis dcuments que pdem ser utilizads cm artefats d Levantament de requisits. Dis deles estã a seguir cmentads. Dcument de Definiçã de Requisits: Uma declaraçã em linguagem natural ds serviçs que sistema deverá prver e suas limitações peracinais. Exempl: O sftware deve prver meis para representaçã e acess a arquivs externs criads pr utras ferramentas ; Deve cnter tant s requisits funcinais quant s nã-funcinais; N mdel prpst que acmpanha este material dcument de definiçã de requisits apresenta três listas de requisits: Aprvads, Adiads e Cancelads. Dcument de Especificaçã de Requisits: Um dcument estruturad cntend de frma detalhada descrições ds serviçs. Escrit cm um cntrat entre cliente e frnecedr. Exempl: O usuári deve ter facilidades para definir tip ds arquivs externs; Cada arquiv extern pde ter uma ferramenta assciada, a qual pde ser aplicada a arquiv; Cada arquiv extern pde ser representad cm um ícne específic na tela d cmputadr; Nã é um dcument de design. Na medida d pssível, deverá definir QUE d sistema em vez de COMO sistema deverá ser feit; Serve de base para design e a implementaçã; Deve-se garantir que tds s requisits aprvads que cnstam d dcument de Definiçã de Requisits estarã aqui cntemplads; N mdel prpst que acmpanha este material dcument de especificaçã de requisits apresenta Escp d Sistema e a Mdelagem de Cass de Us. Sbre Descriçã de Cas de Us Existem várias maneiras pssíveis de se elabrar um cas de us, vist que ele é basicamente uma descriçã textual. O que mais imprta é que tds s detalhes d prcess estejam ali identificads, de uma maneira clara e cmpleta, que pderá ser avaliada e cmpreendida pr tds s envlvids n prcess de desenvlviment de sftware. Segue abaix um ds mdels de descriçã de cas de us. Apesar dele ser muit textual, nrmalmente ficand mais lng d que utrs mdels, ele deixa s detalhes d cas de us bem caracterizads. O mdel separa cas de us em 4 partes:

99 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 99 Objetiv nde ficam descrits bjetiv d cas de us e as bservações que frem julgadas pertinentes; Curs Nrmal nde fica(m) descrit(s) (s) prcess(s) principal(is) tratad(s) n cas de us. Ele é rganizad frtemente através ds passs que prcess segue para ser executad, caracterizand basicamente a cmunicaçã que deverá ser realizada entre (s) atr(es) d cas de us e sistema a ser desenvlvid; Curs Alternativ Descriçã de prváveis trataments de err e exceções que prcess pssa cnter, e que sã para cá transcrits a fim de destacar curs nrmal, bem cm facilitar a leitura d cas de us; Regras de Negóci nde pdem ficar descrits as fórmulas, cálculs e prcediments executads dentr de algum ds curss acima identificads e que sã aqui definids para facilitar a leitura, além de permitir uma mair cncentraçã e destaque n prcediment. E também facilitar reutilizaçã de text quand este prcediment fr ser descrit em mais de um lcal d cas de us, u mesm em cass de us diferentes. 4.5 ANÁLISE DE REQUISITOS Origem: Análise de Sistemas, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. Cm inserçã de cmentáris própris. A cntrári d Levantament de Requisits, que pde ser realizad cm etapa inicial para praticamente qualquer metdlgia, a análise de requisits, mais fcada na elabraçã de mdels, irá requerer a esclha de uma metdlgia. N cas dessa disciplina estará send descrita a Análise de Requisits Orientada a Objet. O bjetiv da Análise Orientada a bjets é definir tdas as classes relevantes a prblema, suas perações e atributs, seus relacinaments, seu cmprtament. As classes identificadas neste mment sã denminadas Classes de Negóci (pis sã relacinadas a prblema, enquant que durante a fase de Design sã identificadas as Classes de Sftware). Pde ser vista literalmente cm a traduçã de bjets d mund real para mund cmputacinal ( cmeç, pel mens). Quand um nv sistema precisa ser cnstruíd e decidims utilizar paradigma rientad a bjets (OO) em seu desenvlviment, surge uma imprtante questã: Cm mdelar s requisits d sistema de um md adequad para a Engenharia de Sftware OO? Uma vez que, essencialmente, este paradigma trabalha cm bjets, é necessári identificar quais s bjets relevantes, cm eles se relacinam e cm eles se cmprtam n cntext d sistema. Além diss, é precis especificar e mdelar prblema de maneira que seja pssível criar um prjet OO efetiv. Tds estes aspects sã tratads dentr d cntext da Análise Orientada a Objets (AOO) [Pressman00]. O prpósit da Análise Orientada a Objets (AOO) é definir tdas as classes (cm seus atributs, perações e s relacinaments assciads a ela) que sã relevantes para prblema a ser reslvid. Para tal, um númer de tarefas deve crrer: Identificaçã de Classes; Especificaçã de Relacinaments (Generalizaçã/Especializaçã, Cmpsiçã/Agregaçã, Assciaçã); Definiçã de Atributs; Mdelagem de Cmprtament;

100 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 100 Descriçã de Operações. É imprtante ntar que estas atividades sã dependentes umas das utras e que, durante desenvlviment, elas sã realizadas, tipicamente, de frma iterativa. A ênfase da fase de análise, n entant, deve ser sempre entendiment d dmíni d prblema, sempre descnsiderand aspects de implementaçã. A ppularidade da rientaçã a bjets fez surgir dezenas de métds OO para análise e prjet. Cada um deles, intrduz um prcess para analisar um sistema, um cnjunt de mdels que evluem a lng d prcess e uma ntaçã que permite a engenheir de sftware criar cada mdel de maneira cnsistente [Pressman00]. Entre s principais métds existentes pdems citar Métd de Bch [Bch94], OMT [Rumbaugh94], OOSE [Jacbsn92] e Métd de Cad & Yurdn [Cad92][Cad93]. Ainda que, à primeira vista, estes métds pssam parecer substancialmente diferentes, ist nã é verdade. Tds eles cnsideram, de alguma frma, as tarefas listadas anterirmente. Essencialmente, as maires diferenças estã nas diretrizes e heurísticas frnecidas, ns mdels utilizads, suas ntações e n prcess sugerid. Tentativas para se definir um métd padrã têm sid realizadas, mas têm encntrad cm principal bstácul a definiçã de um prcess padrã de análise e prjet. Assim, um primeir pass fi dad a se prpr a Linguagem de Mdelagem Unificada (UML), que estabelece, para um cnjunt de mdels nrmalmente utilizads n desenvlviment OO, uma ntaçã padrã. [...] TÉCNICAS DE ANÁLISE DE REQUISITOS [...] Neste text, nã adtams nenhum métd específic, mas, a mesm temp tds. Ist é, prcurams incrprar as características que julgams serem as mais úteis de cada um ds métds em uma abrdagem básica para desenvlviment OO. O prcess de desenvlviment deve ser definid cas a cas, levand-se em cnta as particularidades d prjet em questã, d dmíni de aplicaçã e das características da equipe de desenvlviment, entre utras. Mas a abrdagem aqui prpsta pde ser vista cm pnt de partida para esta definiçã. Quant as mdels e suas ntações, adtams, basicamente, aqueles definids na UML [Furlan98]. (Origem: Análise de Sistemas, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática.) Análise Orientada a Objets Origem: Análise de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. Capítul 5 Análise Orientada a Objets. OBS.: Breves adaptações. A análise é uma interpretaçã que se faz de um prblema. A análise rientada a bjets é a traduçã de bjets d mund real para mund cmputacinal, através da identificaçã das classes de negóci (enquant que na atividade de design serã mapeadas as classes de sftware). Cnfrme citad anterirmente a análise pde ser dividida em sub-tarefas, que estã abaix detalhadas.

101 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 101 Identificaçã de Classes O prblema realmente difícil é descbrir em primeir lugar quais sã s bjets [classes] crrets. [Carl Argila] Cm base na especificaçã de requisits e ns diagramas de cass de us e suas descrições, é pssível iniciar trabalh de mdelagem d sistema. O mdel de bjets ds requisits ds usuáris para sistema a ser gerad deve ser tã independente de sua futura implementaçã quant pssível. Nã há nada mais central e crucial para qualquer métd rientad a bjets d que prcess de descberta de quais classes devem ser incluídas n mdel. O cerne de um mdel OO é exatamente seu cnjunt de classes [Yurdn94]. A figura 5.1 mstra a ntaçã básica da UML para classes em um Diagrama de Classes. Cm a AOO, um engenheir de sftware estuda, filtra e mdela dmíni d prblema. Dizems que engenheir de sftware filtra dmíni, pis apenas uma parte desse dmíni fará parte das respnsabilidades d sistema. Assim, um dmíni de prblema pde incluir várias infrmações e funcinalidades, mas as respnsabilidades de um sistema neste dmíni pdem incluir apenas uma pequena parcela deste cnjunt. As classes de um mdel representam a expressã inicial d sistema. As atividades subsequentes da AOO buscam bter uma descriçã cada vez mais detalhada d cntext, em terms de assciações, atributs e perações. Assim, a identificaçã das classes é uma tarefa crucial para desenvlviment de um sistema OO. Para facilitar a identificaçã das classes d sistema [Cad92] pdem ser realizadas as seguintes tarefas: Estude dmíni de aplicaçã; Faça uma bservaçã geral n ambiente real nde existe prblema; Prcure uvir atentamente s especialistas d dmíni d prblema; Verifique, se existirem, resultads de AOOs anterires em dmínis semelhantes; Observe utrs sistemas n mesm dmíni u em dmínis similares; Cnsulte fntes bibligráficas; Um aspect fundamental n prcess de análise é a interaçã cnstante cm s especialistas de dmíni. Técnicas de cleta de dads, tais cm entrevistas, revisã de dcuments e reuniões infrmais cm s usuáris, têm um papel imprtante nesta etapa. O espaç d prblema em si, junt cm quaisquer diagramas, figuras e infrmaçã textual prvids pels usuáris, pde ser uma imprtante fnte para este trabalh. Para descbrir as classes de um dmíni de aplicaçã, bserve s seguintes elements: Objets físics u cnceituais que frmam uma abstraçã cesa, sbre s quais sistema precisa manipular infrmações; Outrs sistemas e terminadres externs que se cmunicam u interagem cm sistema em questã, atentand para as infrmações que estã send trcadas; Dispsitivs físics cm s quais sistema em estud terá de interagir, sem cnsiderar a tecnlgia para implementar sistema em si.

102 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 102 Um primeir pass n prcess de identificaçã de classes deve ser a revisã e discussã da especificaçã de requisits. Wirfs-Brck, Wilkersn, Wiener [Wirfs-Brck90] e Jacbsn [Jacbsn92] sugerem que uma ba estratégia para identificar bjets é ler a especificaçã de requisits prcurand pr substantivs. Esses autres argumentam que um bjet é, tipicamente, descrit pr um nme n dmíni e, prtant, aprender sbre a terminlgia d dmíni d prblema é um bm pnt de partida. O mair prblema aqui é cnfundir uma classe cm um atribut (que também é nrmalmente identificad cm um substantiv), u mesm um simples text de api. Uma heurística mens vaga sugere que s seguintes elements sejam cnsiderads cm ptenciais candidats a classes [Cad92]: Cisas que sã parte d dmíni de infrmaçã d prblema; crrências u events que precisam ser registrads e lembrads pel sistema; Papéis desempenhads pelas diferentes pessas que interagem direta u indiretamente cm sistema; Lcais físics u gegráfics e lugares que estabelecem cntext d prblema; Unidades rganizacinais (departaments, divisões, etc...) que pssam ser relevantes para sistema. Uma vez identificadas as ptenciais classes, deve-se prceder uma avaliaçã para decidir que cnsiderar u recusar. Dentre s critéris para inclusã de classes pdem ser citads [Cad92]: Lembrança necessária: sistema precisa se lembrar de alguma cisa sbre s bjets da classe? Nrmalmente, devem ser necessáris, pel mens, dis u mais atributs; Funcinalidade necessária e essencial: deve ser pssível identificar uma u mais perações para as classes prpstas, ist é, bjets destas classes têm de fazer alg para justificar a sua existência. Além diss, a funcinalidade identificada para a classe prpsta deve ser relevante e necessária a despeit da tecnlgia de hardware e sftware a ser usada para implementar sistema; cas cntrári, a classe prpsta é uma classe de prjet u de implementaçã e sua inclusã n mdel deve ser adiada até respectiv estági de desenvlviment; Atributs e perações cmuns: s atributs e as perações da classe devem ser aplicáveis a tdas as suas instâncias, ist é, as bjets da classe. Para ser cnsiderada uma classe legítima n mdel de análise, uma classe candidata tem de satisfazer a tdas (u quase tdas) as características acima. Além diss, bserve se existem várias instâncias da classe. Uma classe que pssui uma única instância também nã deve ser cnsiderada uma classe de negóci. O resultad principal desta atividade é a btençã de uma lista de ptenciais classes para sistema em estud. Especificaçã de Relacinaments - Hierarquias de Generalizaçã / Especializaçã Um ds principais mecanisms de estruturaçã de cnceits é a generalizaçã / especializaçã. Cm este mecanism é pssível capturar similaridades entre classes, dispnd-as em hierarquias de classes. A figura 5.2 mstra a ntaçã da UML usada para representar a estrutura de generalizaçã - especializaçã. É imprtante realçar que esta estrutura reflete um mapeament entre classes e nã entre bjets.

103 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 103 As seguintes diretrizes pdem ser usadas para analisar as hierarquias mdeladas: Uma hierarquia de classes deve mdelar relações é-um-tip-de, u seja, tda subclasse deve ser um tip específic das suas superclasses; Uma subclasse deve suprtar tda a funcinalidade (atributs, relacinaments e perações) definida pr suas superclasses, e pssivelmente mais; A funcinalidade cmum a diversas classes deve ser psicinada mais alt pssível na hierarquia; Classes abstratas nã pdem herdar de classes cncretas; Classes que nã adicinam funcinalidade devem ser eliminadas. Pr adicinar funcinalidade quer se dizer adicinar nva funcinalidade u redefinir uma funcinalidade existente em uma superclasse. Se a única distinçã entre as especializações fr seu tip, u se as classes de especializaçã nã adicinarem nenhuma funcinalidade, entã a estrutura de generalizaçã/especializaçã nã é necessária. Cada especializaçã deve ser nmeada de frma a ser aut-explicativa. Um nme aprpriad para a especializaçã pde ser frmad pels nmes de suas generalizações, acmpanhads pr um nme qualificadr que descreve a natureza da especializaçã. As classes geradas através de generalizaçã-especializaçã devem atender, além ds critéris para inclusã discutids na seçã anterir, as seguintes critéris: As ptenciais especializações e/u generalizações devem estar n dmíni d prblema e devem fazer parte das respnsabilidades d sistema; e Se uma classe é dita sub-classe de utra, tdas as instâncias da sub-classe têm de ser também, pr definiçã, instâncias da super-classe, ist é, tud que é dit sbre a superclasse (relacinaments, atributs e perações) tem de ser válid também para a subclasse. A figura 5.3 ilustra uma hierarquia de classes dentr d cntext de uma aut-escla. Há uma pequena e imprtante sutileza neste exempl que precisa ser realçada: a figura 5.3 indica explicitamente que nã há instâncias da classe Veícul per se; as únicas instâncias (u bjets) crrem n nível de especializaçã de Carr, Mt, Ônibus, u Caminhã. Iss é indicad pel nme da classe Veícul que está escrit em itálic, em cntraste cm s demais nmes de classes. Este é padrã de ntaçã para classes abstratas na UML (também pderia ser utilizada uma etiqueta {abstract}).

104 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 104 Um recurs adicinal que muitas vezes facilita entendiment das estruturas de generalizaçã / especializaçã, principalmente quand há várias classificações para uma mesma classe, é indicar critéri de rganizaçã de cada hierarquia, adicinand um rótul junt a símbl de classificaçã (triângul). Especificaçã de Relacinaments Assciaçã Relacinaments sã representações estáticas que mdelam ligações entre bjets (u assciações entre classes), um ds mecanisms de estruturaçã de bjets. Cada classe desempenha um papel na assciaçã, a qual pde ser dad um nme. Cada papel pssui também uma cardinalidade, que indica quants bjets pdem participar de um dad relacinament. Em geral, a cardinalidade indica as frnteiras inferir e superir para s bjets participantes, cm mstra a figura 5.5. Há várias maneiras de nmear assciações. Os seguidres da mdelagem de dads tradicinal, nrmalmente, têm hábit de usar um verb u frase verbal de md que relacinament pssa ser lid cm uma sentença ( que faz mais sentid durante a mdelagem d prblema, a fim de auxiliar na cmpreensã). Na mdelagem OO, cntud, há uma utra pçã de nmeaçã, que cnsiste em utilizar nmes para rtular um u mais papéis, indicand a respnsabilidade ds bjets na assciaçã. Além diss, só devems nmear uma assciaçã se ist melhra entendiment que tems sbre mdel. Tmems exempl da figura 5.6. Em uma empresa, um empregad está ltad em um departament e, pcinalmente, pde chefiá-l. Um departament, pr sua vez, pde ter váris empregads nele ltads, mas apenas um chefe. Sem nmear estas assciações, mdel fica cnfus. Rtuland s papéis, mdel trna-se muit mais clar. Na figura 5.6, um departament exerce papel de departament de ltaçã d empregad e, neste cas, um empregad tem um e smente um departament de ltaçã. N utr relacinament, um empregad exerce papel de chefe e, prtant, um departament pssui um e smente um chefe. E iss ainda vai depender das próprias características d prblema (pderia-se pensar em atualizações de chefe e/u departament, e a necessidade de manter um cntrle sbre iss um históric).

105 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 105 A figura 5.7 ilustra de frma genérica a maneira de se nmear papéis em uma assciaçã. Alguns tips de relacinaments merecem uma discussã adicinal: s relacinaments muits-para muits, s relacinaments recursivs e s relacinaments n-áris. Relacinaments Recursivs (u Assciações Unárias) Pdem crrer assciações entre bjets de uma mesma classe. Tdas as cnsiderações feitas para relacinaments de maneira geral sã também válidas para estes cass. A figura 5.8 ilustra um relacinament deste tip. Relacinaments muits-para-muits u N:N Relacinaments N:N sã perfeitamente legais em um mdel rientad a bjets, cm mstra exempl da figura 5.9. Entretant, é precisamente neste tip de relacinament nde mais prvavelmente surgem crrências e events que precisam ser registrads e lembrads. Neste cas, uma classe d tip event-lembrad deve ser mdelada, nã prque esta classe deve mapear um relacinament N:N, mas prque registrar este event u crrência é um requisit d sistema. O exempl da figura 5.9 ilustra uma situaçã deste tip.

106 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 106 N exempl da figura 5.9, pderíams cnsiderar Alcaçã cm send uma classe de assciaçã. Uma classe de assciaçã pde ser vista cm uma assciaçã que tem prpriedades de classe, ist é, atributs, perações e/u relacinaments. A figura 5.10 mstra este mesm exempl, send mdelad cm uma classe de assciaçã, segund a ntaçã da UML. Múltipls Relacinaments entre Objets das Mesmas Classes Às vezes, é necessári mais de um relacinament entre bjets de duas classes. Nestes cass, trna-se imprescindível nmear s relacinaments, cm n exempl da figura 5.6. Assciações n-árias Sã assciações entre três u mais classes. Assciações ternárias u superires sã mstradas cm lsangs cnectads às classes através de linhas, cm mstra a figura Um símbl de classe de assciaçã pde ser anexad a lsang pr uma linha tracejada [Furlan98].

107 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 107 Especificaçã de Relacinaments Agregaçã/Cmpsiçã Uma agregaçã é uma frma especial de assciaçã utilizada para mstrar que um tip de bjet é cmpst, pel mens em parte, de utr em uma relaçã td/parte [Furlan98]. Um carr, pr exempl, tem um mtr e rdas cm suas partes. Entretant, muitas vezes é difícil perceber a diferença entre uma agregaçã e um relacinament cmum. De fat, nã há uma definiçã única aceita pr tds s métds d que seja a diferença entre agregaçã e relacinament. Ainda assim, a UML apresenta ntações para agregaçã, cm mstra a figura É imprtante realçar que, uma vez que uma agregaçã é, na verdade, um tip de relacinament, cardinalidades devem ser indicadas. A se utilizar a ntaçã de agregaçã, espera-se que as partes vivam e mrram cm td, ist é, na criaçã d bjet-td, s bjets-parte sã criads e a remçã d bjet-td deve ser aplicada em cascata às suas partes. Esta remçã em cascata é frequentemente cnsiderada cm send uma característica da definiçã de agregaçã, cntud, ela é impsta pr qualquer papel cuja cardinalidade é Cntud, na agregaçã, s bjets-parte nã pdem ser destruíds pr utr bjet a nã ser pel bjet-td que s criu. Esta cndiçã nã é brigatória para bjets em uma assciaçã cmum. A UML ferece ainda ntações para alguns tips de agregaçã, chamadas de cmpsiçã. A utilizar uma cmpsiçã, está-se afirmand que bjet-parte pde pertencer a apenas um td, send pis um tip mais frte de agregaçã.

108 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 108 Definiçã de Atributs Um atribut é um dad (infrmaçã de estad) para qual cada bjet em uma classe tem seu própri valr. Os atributs adicinam detalhes às abstrações e sã apresentads na parte central d símbl de classe. Atributs sã muit similares a assciações. De fat, cnceitualmente, nã há diferença entre atributs e assciações. Pdems dizer que atributs representam assciações entre as classes d dmíni d prblema e classes básicas, tais cm strings, datas, inteirs e reais. Exatamente pr estas classes serem básicas e crrerem em quase tds s dmínis de prblemas, elas nã sã representadas e, prtant, atributs sã descrits cm uma infrmaçã de um determinad tip. A estratégia para a definiçã de atributs envlve: Descberta de atributs; Psicinament ds atributs em uma hierarquia de classes; Revisã ds relacinaments entre classes; Especificaçã ds Atributs. É bm realçar que, cm temp, as classes d dmíni de prblemas permanecem relativamente estáveis, enquant s atributs prvavelmente se alteram. Atributs sã bastante vláteis, em funçã das respnsabilidades d sistema, quand cmparads cm a própria classe. Descberta de Atributs A AOO nã prvê nenhuma técnica mágica para se descbrir s atributs que um bjet requer para realizar seus bjetivs. A tarefa é essencialmente a mesma usada em qualquer frma de análise de sistemas: estud d dmíni da aplicaçã, entrevistas cm usuári, etc. Busca-se ns mesms artefats ns quais fram identificadas as classes. Cada atribut deve capturar um cnceit atômic (um únic valr u um agrupament de valres frtemente relacinads) que ajude a descrever um bjet e que seja de respnsabilidade d sistema. Um atribut representa uma infrmaçã de estad de um bjet que precisa ser lembrada/manipulada. Uma vez que, cnceitualmente, atributs e assciações sã a mesma cisa, nã devems incluir na lista de atributs de uma classe, atributs representand assciações. Estas já têm sua presença indicada pela linha que cnecta as classes que se relacinam. Psicinament de Atributs Cada atribut deve ser clcad na classe mais adequada. Para classes em uma hierarquia de generalizaçã-especializaçã, atributs genérics devem ser psicinads n tp da estrutura, de md a serem aplicáveis a cada uma das especializações. Em utras palavras, se um atribut é aplicável a um nível inteir de especializações, entã ele deve ser psicinad na generalizaçã crrespndente. Pr utr lad, se algumas vezes um atribut tiver um valr significativ, mas em utras ele nã fr aplicável, deve-se rever psicinament d atribut u a estratégia da estrutura de generalizaçã-especializaçã adtada. Esta estratégia é válida também para perações. Revisã da Hierarquia de Classes Inevitavelmente, prcess detalhad de designar atributs a classes cnduz a um entendiment mais cmplet d que era pssível em estágis anterires d desenvlviment. Assim, devems esperar que algumas revisões de definições de classes e suas hierarquias resultem deste pass.

109 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 109 Especificaçã de Atributs Um aspect bastante imprtante na especificaçã de atributs é a esclha de nmes. Deve-se prcurar utilizar vcabulári padrnizad para dmíni d prblema, usand nmes legíveis e abrangentes. O nme d atribut é uma sequência de caracteres de identificaçã, cmeçand tipicamente, cm letra minúscula. Cncatena-se as demais palavras que cmpõem nme, preservand-se a primeira letra de cada palavra em maiúscula [Furlan98], pr exempl, limitedecredit. Pde-se também desprezar prepsições. Assim, exempl anterir assumiria a seguinte frma: limitecredit. A especificaçã de atributs pde incluir unidade de medida, interval, limite, enumeraçã, precisã, valr default e brigatriedade, entre utrs. Cas valha a pena, em terms de cust-benefíci, pde ser imprtante adicinar uma descriçã breve para cada atribut. A ntaçã da UML para atributs é a seguinte: visibilidade nme: tip = valrdefault, nde visibilidade é um ds seguintes símbls: +, públic, ist é, atribut pde ser acessad pr qualquer classe-cliente; #, prtegid, ist é, atribut só é passível de acess pela própria classe u pr uma de suas especializações; e -, privad, ist é, atribut só pde ser acessad pela própria classe. A final ds passs descrits até mment terá-se cnstruíd Diagrama de Classes, identificand as classes, seus atributs e seus relacinaments. O pass seguinte irá tratar da determinaçã ds métds. Determinaçã d Cmprtament Os Diagramas de Classes, gerads pelas atividades anterirmente descritas, representam apenas s elements estátics de um mdel de análise OO. É precis analisar, ainda, cmprtament dinâmic da aplicaçã. Para tal, devems representar cmprtament d sistema cm uma funçã d temp e de events específics. Um mdel de cmprtament indica cm sistema irá respnder a events u estímuls externs e auxilia prcess de descberta das perações das classes d sistema. Para apiar a mdelagem d cmprtament d sistema, a UML ferece pel mens duas ferramentas: Diagramas de Estads: descrevem tds s estads pssíveis pels quais um particular bjet pde passar e suas transições, cm resultads de estímuls (events) que atingem bjet. Representa cmprtament de uma classe a lng d temp, pdend envlver váris cass de us; Diagramas de Interaçã: sã mdels que descrevem cm grups de bjets clabram em um cert cmprtament. Representa cmprtament de uma, u mais, classes na realizaçã de um cenári de cas de us. Diagramas de Transiçã de Estads Diagramas de Estads sã uma técnica já bastante familiar para descrever cmprtament de um sistema. N entant, n cntext d desenvlviment OO, diagramas de transiçã de estads têm um caráter bastante peculiar: cada diagrama é cnstruíd para uma única classe, cm bjetiv de mstrar cmprtament a lng d temp de vida de um bjet. Diagramas de Estad descrevem tds s pssíveis estads pels quais um bjet pde passar e as alterações ds estads cm

110 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 110 resultad de events (estímuls) que atingem bjet [Furlan98]. A figura 5.13 mstra a ntaçã básica da UML para diagramas de estad. Estads sã representads pr retânguls cm s cants arredndads e transições pr setas, send que ambs pdem ser rtulads. O rótul de um estad pde cnter, além de seu nme, uma indicaçã de que estad pssui uma atividade assciada a ele, cuja sintaxe é: faça: atividade O rótul de uma transiçã pde ter até três partes, tdas elas pcinais: Event [cndiçã] / açã Basicamente a semântica de um diagrama de estads é a seguinte: quand um event crre, se a cndiçã é verdadeira, a transiçã crre e a açã é realizada. O bjet passa, entã, para um nv estad. Se neste estad, uma atividade deve ser realizada, ela é iniciada. O fat de uma transiçã nã pssuir um event assciad, indica que a transiçã crrerá tã lg a atividade assciada a dad estad tiver sid cncluída, desde que a cndiçã seja verdadeira. Quand uma transiçã nã pssuir uma cndiçã assciada, entã ela crrerá sempre quand event crrer. Embra ambs s terms açã e atividade dentem prcesss, tipicamente implementads pr métds da classe, eles nã devem ser cnfundids. Ações sã assciadas a transições e sã cnsideradas prcesss instantânes, ist é, crrem muit rapidamente, nã send passíveis de interrupçã. Atividades sã assciadas a estads, pdend durar bastante temp. Assim, uma atividade pde ser interrmpida pr algum event. Diagramas de Interaçã Uma das cisas mais difíceis de cmpreender e capturar em um sistema rientad a bjets é flux glbal de cntrle. Diagramas de interaçã têm pr bjetiv ajudar a visualizar esta sequência. Tipicamente, um diagrama de interaçã captura cmprtament de um grup de bjets em um cas de us islad, mstrand um númer de bjets-exempls e as mensagens que sã passadas entre esses bjets n cntext d cas de us [Furlan98]. Há dis tips de diagramas de interaçã: diagramas de sequência e diagramas de cmunicaçã (clabraçã). Diagrama de Sequência Tal diagrama fca a sequência tempral de execuçã de um cnjunt de mensagens. Em um diagrama de sequência, um bjet é mstrad cm um retângul cm uma linha vertical pntilhada anexada. Esta linha é chamada de linha de vida d bjet e representa a vida d bjet durante a interaçã. Cada mensagem é representada pr uma seta cheia entre as linhas de vida de dis bjets. A rdem na qual as mensagens crrem é mstrada d alt para pé da página. Cada mensagem é rtulada cm pel mens nme da mensagem. Adicinalmente, pde incluir também seus arguments e alguma infrmaçã de cntrle. Infrmações de cntrle pdem ser uma cndiçã ([cndiçã = verdadeira ]), indicand que a mensagem só é enviada se a cndiçã fr verdadeira, e um marcadr de iteraçã (*), dentand que

111 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 111 a mensagem é enviada várias vezes para múltipls bjets receptres, cm n cas de uma iteraçã sbre uma cleçã de bjets. O diagrama pde incluir ainda, um retrn, indicand retrn de uma mensagem e nã uma nva mensagem. Para diferenciar, retrns sã simblizads pr uma seta nã sólida. A figura 5.14 sumariza a ntaçã básica da UML para diagramas de sequência. Uma técnica bastante útil para facilitar entendiment de um diagrama de seqüência cnsiste em inserir descrições textuais d que está acntecend a lng d lad esquerd d diagrama de sequência. Ist envlve a redaçã de um blc de text alinhad cm a mensagem aprpriada n diagrama. Diagrama de Clabrações/Cmunicaçã Tal diagrama fca relacinament entre classes durante a execuçã de um cnjunt de mensagens. Um diagrama de cmunicaçã tem mesm prpósit que um diagrama de sequência e, prtant, ambs sã similares, u seja, trabalham cm as mesmas abstrações (bjets-exempls, mensagens e sequências). Assim, habitualmente selecina-se apenas um deles para ser trabalhad. Em um diagrama de clabrações, s bjets-exempls sã mstrads cm ícnes e mensagens cm setas. A sequência, pr sua vez, é indicada pr uma numeraçã das mensagens. A figura 5.15 mstra a ntaçã básica da UML para diagramas de clabrações.

112 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 112 A numeraçã de mensagens trna a visualizaçã da sequência mais difícil d que ns diagramas de sequência. Entretant, este layut permite mstrar mais facilmente utras cisas. A UML adta um esquema de numeraçã decimal (1, 1.1, 1.1.1, 2,...) cm bjetiv de trnar mais clar que peraçã está chamand que utras perações, embra pssa ser difícil ver a sequência glbal. Tant diagramas de sequência quant diagramas de clabrações nã sã muit aprpriads para representar prcesss cm muit cmprtament cndicinal e repetitiv. Para estes cass, ainda que seja pssível utilizar cndições e marcadres de iterações, é melhr utilizar diagramas separads para cada cenári. Deve-se ressaltar, ainda, que s diagramas de interaçã sã bns para mstrar clabrações entre bjets em um cas de us. Para bservar cmprtament de um bjet islad a lng de váris cass de us, deve-se utilizar um diagrama de transiçã de estads. Vale destacar que cada peraçã identificada em um ds diagramas de cmprtament deverá estar declarada na classe afetada n diagrama de classes crrespndente. Descriçã das Operações Uma vez estudad cmprtament d sistema, tem-se uma base para a descriçã das perações das classes que cmpõem sistema. Na ntaçã da UML, em um diagrama de classes, perações sã apresentadas na seçã inferir d símbl de classe, cm a seguinte sintaxe: visibilidade nme(lista_de_parâmetrs): tip_de_retrn nde a visibilidade tem a mesma sintaxe e semântica definida para atributs. Nrmalmente, perações que simplesmente manipulam atributs (s getters e setters) nã sã representadas, já que pdems deduzir que elas existem, tais cm: Operações que btêm valres de atributs: apenas retrnam um valr de um atribut e nã fazem mais nada; Operações que clcam valres em atributs: apenas clcam um valr em um atribut e nã fazem mais nada. Além dessas, perações para criar uma nva instância da classe, selecinar e eliminar uma instância da classe também nã sã nrmalmente mstradas n diagrama de classes. Entretant, afra s sistemas muit simples, utras perações devem ser capturadas, entre elas: Operações assciadas às mensagens ns diagramas de interaçã; Operações assciadas as relacinaments entre bjets ns diagramas de classes, ist é, perações para assciar e desassciar instâncias específicas que se relacinam. Em utras palavras, sã as perações que permitem que um relacinament seja estabelecid u desfeit; Operações sugeridas pels diagramas de estads. Especificaçã das Operações Finalmente, as perações pdem ser descritas, detalhand-se cmprtament das classes. Cada peraçã pde dar rigem a um u mais métds a serem executads quand uma mensagem fr recebida. Se s bjets tiverem sid bem definids, entã cada métd será pequen e altamente ces. Assim, é pssível descrever uma peraçã cmpactamente em alguma ntaçã semi-frmal, cm um prtuguês-estruturad.

113 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 113 Nrmalmente as perações especificadas sã apenas aquelas cnsideradas necessárias (há um cert grau de cmplexidade envlvid). Identificaçã de Subsistemas Um mdel de análise para uma aplicaçã cmplexa pde ter centenas de classes e dezenas de estruturas e, prtant, pde ser necessári definir uma representaçã cncisa capaz de rientar um leitr em um mdel desta natureza. O agrupament de classes em subsistemas serve basicamente a este prpósit, pdend ser útil também para a rganizaçã de grups de trabalh em prjets extenss. A base principal para a identificaçã de subsistemas é a cmplexidade d dmíni d prblema. Através da identificaçã e agrupament de classes em subsistemas, é pssível cntrlar a visibilidade d leitr e, assim, trnar mdel mais cmpreensível. Quand uma cleçã de classes clabram entre si para realizar um cnjunt ces de respnsabilidades, elas pdem ser vistas cm um subsistema. Assim, um subsistema é uma abstraçã que prvê uma referência para mais detalhes em um mdel de análise. Quand vist de fra, um subsistema pde ser tratad cm uma caixa preta que cntém um cnjunt de respnsabilidades e pssui suas próprias clabrações [Pressman00]. O agrupament de classes em subsistemas permite apresentar mdel glbal em uma perspectiva mais alta. Este nível ajuda leitr a rever mdel. Além diss, cnstitui também um bm critéri para rganizaçã da dcumentaçã. Os cass de us sã um bm pnt de partida para agrupament de classes em subsistemas. A mdelar grups cess de cass de us cm subsistemas, estams relacinand as infrmações cntidas ns mdels de classe e de cass de us. A UML prpõe s chamads diagramas de pactes, para rganizar grups de classes. A ntaçã é mstrada na figura 5.4. Um Recurs Adicinal - Cntrats Um recurs muit útil, empregad pel métd CRC [Wirfs-Brck90] é a definiçã de cntrats. Um cntrat define um cnjunt de requisições que um cliente pde fazer a um servidr, cm a garantia de que servidr é capaz de respndê-las. Agrupar funcinalidades em cntrats auxilia entendiment de um mdel e estabelece claramente as respnsabilidades de uma classe. Uma classe pde suprtar váris cntrats, apesar de ser bastante cmum encntrar classes que suprtam apenas um únic cntrat. Cada respnsabilidade de uma classe pde ser parte de um cntrat, mas nem tdas respnsabilidades sã (Respnsabilidades incluem tant a infrmaçã mantida pelas instâncias da classe (estad ds bjets) quant as ações que essas instâncias pdem executar (cmprtament ds bjets) [Wirfs-Brck90]). Algumas respnsabilidades representam um cmprtament que a classe deve apresentar, mas que nã pde ser requisitad pr bjets de utras classes. Tais respnsabilidades sã ditas respnsabilidades privadas. As seguintes diretrizes ajudam a determinar que respnsabilidades pertencem a que cntrats:

114 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 114 Agrupe funcinalidades usadas pels mesms clientes. Um cntrat representa um cnjunt ces de respnsabilidades. Uma maneira de encntrar respnsabilidades cesas é prcurar pr funcinalidades que serã utilizadas sempre pels mesms clientes; Maximize a cesã das classes. Assim cm um cntrat deve ser cmpst de um cnjunt ces de respnsabilidades, uma classe deve suprtar um cnjunt ces de cntrats. Maximizar a cesã tende a minimizar númer de cntrats suprtads pr uma classe; Minimize númer de cntrats. Sem vilar princípi de cesã ds cntrats, a melhr maneira de reduzir númer de cntrats é prcurar pr funcinalidades similares que pssam ser generalizadas, permitind, assim, que essas, e s cntrats ds quais elas sã partes, pssam ser mvids para pnts mais alts na hierarquia de classes. Deste md, um cntrat pde ser definid smente em uma classe, a superclasse, e as várias classes que suprtam pdem herdá-l da superclasse. Uma estratégia simples para a definiçã de cntrats, cmeça pela definiçã ds cntrats das classes lcalizadas n tp de suas hierarquias. Nvs cntrats só precisam ser definids para as subclasses que adicinam nva funcinalidade, a ser usada pr utrs clientes. Assim, deve-se examinar as respnsabilidades adicinadas pr cada uma das subclasses, avaliand se elas representam nva funcinalidade u se apenas definem maneiras mais específicas de expressar respnsabilidades herdadas, cas em que já sã parte d cntrat herdad DOCUMENTAÇÃO Para pder melhr trabalharms cm a Especificaçã de Análise de Requisits segue em anex a este material um mdel de um dcument de Especificaçã de Análise de Requisits simplificad. A seguir encntra-se algum detalhament sbre tal mdel. O mdel separa dcument em 4 partes: Intrduçã uma breve descriçã sbre dcument e que será tratad. Exempl de Text: Este dcument cntém a especificaçã de análise para prjet de infrmatizaçã da <...>. Esta atividade fi desenvlvida em duas etapas principais, a primeira fcand na estrutura de infrmaçã d sistema (classes, atributs e assciações), a segunda em seu cmprtament (perações e trcas de mensagem entre bjets). Na seçã 2, sã apresentads s prduts da primeira etapa, a saber: Diagrama de Pactes, Diagramas de Classes (um para cada pacte). Na seçã 3, sã apresentads s prduts da segunda etapa: Diagramas de Transiçã de Estads (para as classes cm cmprtament variável a lng d temp), Diagramas de Sequência (agrupads pr cass de us) e as Descrições ds Atributs e Operações, fechand cnjunt de prduts gerads na fase de análise. Mdelagem Estática Cntém a descriçã da sluçã d sistema de maneira estática, identificand as classes e atributs, perações e relacinaments. A mdelagem estática é basicamente representada pr dis tips de diagramas: Diagrama de Pactes cas tenha sid elabrad n Dcument de Especificaçã de Requisits deve ser aqui repetid, cas cntrári deverá ser criad neste mment (se fr julgad necessári). Deve-se sempre ter em mente que s pactes identificads devem agrupar classes de negóci, mais d que uma funcinalidade similar; Diagrama de Classes deve ser criad pel mens um diagrama de classe para cada pacte identificad anterirmente. Um diagrama de classe irá cnter a identificaçã das classes, cm seus atributs, perações e relacinaments;

115 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Engenharia de Requisits Página: 115 Mdelagem Dinâmica Cntém a mdelagem d prblema cnsiderand seu aspect dinâmic (cmprtamental), identificand s estads pels quais uma classe pde passar e a sequência de execuçã de cada um ds prcesss que cmpõe s cass de us, já cnsiderand as perações das classes que devem ser executadas. A mdelagem dinâmica é basicamente representada pr dis tips de diagramas: Diagrama de Estads deve ser criad um diagrama de estad para cada classe cuja variaçã de estads seja interessante de ser mapeada. A sua cnstruçã nã é brigatória, mas apenas em cass nde existirem classes cm váris estads, cuj mapeament facilite entendiment d prblema; Diagrama de Sequência deve ser criad um diagrama de sequência para cada cas de us d sistema, descrevend as perações de cada classe que devem ser executadas na realizaçã d cas de us; Descriçã de Atributs e Operações cntém a descriçã detalhada ds atributs e perações de cada classe, que frem julgadas pertinentes. Vale destacar que n cas ds atributs descreve-se significad de cada atribut, e n cas das perações descreve-se bjetiv e principais características de cada peraçã (uma espécie de algritm para guiar prgramadr sem lhe tirar a liberdade de criaçã de códig-fnte). OBSERVAÇÃO: Para melhr acmpanhament e fixaçã das atividades de Levantament e Análise de requisits, em anex a este cnteúd estã prpsts alguns mdels (e exempls) de dcuments habitualmente gerads em tais atividades. Os dcuments sã s seguintes: Levantament de Requisits: Definiçã de Requisits (mdel); Especificaçã de Requisits (mdel e exempl); Análise de Sistemas: Especificaçã de Análise (mdel e exempl). 4.6 LEITURA RECOMENDADA PRESSMAN, Rger. Engenharia de sftware McGraw-Hill. Capítul 7 Engenharia de Requisits; Capítul 8 Mdelagem de Análise; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 6 Requisits de Sftware; Capítul 7 Prcesss de Engenharia de Requisits; Capítul 8 Mdels de sistemas; LARMAN, Graig. Utilizand UML e padrões Bkman; FURLAN, Jsé Davi. Mdelagem de bjets através da UML; Site da UML: Apstila: Análise de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. Capítul 2 Técnicas de Levantament de Requisits.

116 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: DESIGN DE SOFTWARE O que é prjet? É nde vcê se instala cm um pé em dis munds mund da tecnlgia e mund das pessas e bjetivs humans e vcê tenta juntar s dis... O crític rman de arquitetura Vitruvius adiantu a nçã de que edifícis bem prjetads eram aqueles que exibiam firmeza, cmdidade e prazer. O mesm pderia ser dit de bm sftware. Firmeza: um prgrama nã deve ter quaisquer errs que inibam sua funçã. Cmdidade: um prgrama deve ser adequad às finalidades para s quais fi prjetad. Prazer: a experiência de usar prgrama deve ser agradável. Tems aí iníci de uma teria de prjet de sftware. [Mitch Kapr, 1990, Manifest de Prjet de Sftware] OBS: O nme riginal da etapa é DESIGN, send traduzid tant para Prjet quant para Desenh. Apesar d nme prjet ser mais cnhecid ele pde causar cnfusã cm fat de trabalh cm um td também ser cnhecid cm prjet (fala-se prjet de desenvlviment de sftware ). 5.1 CONCEITUAÇÃO Transfrma a infrmaçã d mdel de dmíni/prblema (btida na análise) em estruturas que pdem ser implementadas n sftware mdel da sluçã; Na Análise investigams O QUE deve estar n sistema. N Prjet definims COMO iss será feit. Assim, prjet é a PONTE entre a análise e a efetiva implementaçã; Prdut principal: Especificaçã de Design; Cnfrme destacad pr FALBO [Ntas e Aula, Prjet de Sistemas, 2003], uma especificaçã de prjet deve: Cntemplar tds s requisits explícits cntids ns mdels de Análise e tds s requisits implícits desejads pel cliente;

117 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 117 Ser um guia legível e cmpreensível para aqueles que irã cdificar, testar e manter sftware; Prver um quadr d sftware, tratand aspects funcinais, de interface, cmprtamentais e de dads, segund uma perspectiva de implementaçã. Durante prcess de design s requisits d sftware sã mapeads em mdels de design, que descrevem s detalhes da arquitetura d sftware, estrutura de dads, interface e cmpnentes; O design é mment em que a qualidade é fmentada durante prcess de desenvlviment, n que se refere à sluçã a ser adtada; O design é prcess pel qual s requisits d sftware sã traduzids numa representaçã d sftware que permite sua realizaçã física, através da cmpreensã e definiçã das necessidades tecnlógicas d sftware; O bjetiv principal é acrescentar tecnlgia as requisits definids na etapa anterir, planejand que deverá ser cdificad na fase de implementaçã (até tal mment as características e limitações da tecnlgia nã estavam send cnsiderads). Devid a iss é precis cnhecer a tecnlgia dispnível, bem cm as facilidades d ambiente nde sistema irá ser desenvlvid e/u executad; É a primeira das 3 atividades técnicas de desenvlviment de sftware: design, cdificaçã e teste. Mdel Funcinal Outrs Requisits Mdel de Infrmaçã Prjet Mdel Cmprtamental Prjet Arquitetural Prjet de Interface Prjet de Dads Cdificaçã Prjet Prcedimental Prgrama Teste 5.2 IMPORTÂNCIA DO PROJETO O prjet frnece representações d sftware que pdem ser avaliadas quant à qualidade; É uma maneira pela qual pde-se traduzir cm precisã s requisits de um cliente num prdut de sftware acabad, send mment de se planejar e esbçar a sluçã; É uma atividade base para que se fundamente a qualidade tecnlógica d sftware. Sem a atividade de design estams ns arriscand a cnstruir um sftware instável. É durante esta atividade que sã tmadas uma série de decisões / definições que tem um grande impact sbre a qualidade d sftware, cm pr exempl, n que se refere à manutenibilidade e usabilidade.

118 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 118 Manutençã Teste Implementaçã Prjet COM prjet Manutençã Teste Implementaçã SEM prjet 5.3 MODELOS DE ESPECIFICAÇÃO Os mdels habitualmente desenvlvids durante Design de sftware sã s seguintes: MODELO ARQUITETURAL: desenvlver uma estrutura mdular d sftware e representar as relações de cntrle entre s móduls; MODELO DE DADOS: selecinar representações lógicas ds dads identificads na fase de Especificaçã de Requisits, ist é, definir e especificar as estruturas de dads necessárias; MODELO DE INTERFACE: estabelecer s mecanisms de interaçã e layut para a interaçã hmem-máquina (Interface cm Usuári), cm utrs sistemas (Interface Externa), entre cmpnentes (Interface Interna); MODELO DE COMPONENTES (Prcedural): especificar detalhes ds cmpnentes d sftware, cm pr exempl, s algritms (de cada métd principal identificad). 5.4 CARACTERÍSTICAS COMUNS DOS MÉTODOS Há diferentes métds prpsts para desenvlviment d Design de sftware. N entant eles cstumam apresentar as seguintes características: Um mecanism para a traduçã da representaçã d dmíni d prblema em uma representaçã de design (dmíni da sluçã); Uma ntaçã para representar s cmpnentes funcinais e suas interfaces; Heurísticas para refinament e divisã em partições; Diretrizes para a avaliaçã da qualidade; Api de Ferramentas CASE. 5.5 GUIDELINES E PRINCÍPIOS PARA O PROJETO Dicas para a realizaçã de um bm design: Exibir ba estrutura arquitetural; Cnter representações distintas de dads, arquitetura, interface e cmpnentes; Cnduzir a cmpnentes que tem características funcinais independentes (criaçã de móduls cm Alta Cesã e Baix Acplament).

119 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 119 Princípis para realizaçã da etapa de design: Pesquisar e utilizar abrdagens alternativas; Acmpanhar s requisits d mdel de análise; Nã reinventar (utilizar padrões); Lembrar que Prjetar nã é cdificar ; Revisar para minimizar errs semântics. Cmprmisss d Prjet: Alguns requisits e slicitações pdem ser incmpatíveis e, prtant alguns cmprmisss precisam ser assumids. Exempl: Perfrmance x Cust. 5.6 CONCEITOS FUNDAMENTAIS DE DESIGN DE SOFTWARE Alguns cnceits fundamentais a serem cnsiderads: ABSTRAÇÃO Cada pass n prcess de Engenharia de Sftware é um aprimrament d nível de abstraçã de uma sluçã; Pssibilita que engenheir represente s prcediments, s dads e cntrle em váris níveis de detalhes; Níveis de Detalhament: A sluçã é declarada em terms ampls usand a linguagem d ambiente d prblema; A sluçã é descrita usand uma terminlgia rientada à implementaçã; Uma sluçã para prblema é estabelecida de uma frma que pssa ser diretamente implementada; Tips de Abstraçã: Abstraçã Prcedimental: uma sequência de instruções designadas que têm uma funçã específica e limitada; Abstraçã de Dads: uma cleçã designada de dads que descreve um bjet de dads; Abstraçã de Cntrle: implica um mecanism de cntrle d prgrama sem especificar detalhes interns. REFINAMENTO O refinament pass a pass é uma antiga estratégia de prjet tp-dwn (1971), nde a arquitetura de um prgrama é desenvlvida refinand-se sucessivamente s níveis de detalhes prcedimentais e de dads; O refinament é um prcess de elabraçã. Faz cm que engenheir elabre a declaraçã riginal ferecend um númer cada vez mair de detalhes à medida que sucessivs refinaments (elabrações) crrem.

120 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 120 MODULARIDADE Cnceit relacinad diretamente à arquitetura d sftware; O sftware é dividid em cmpnentes (partes administráveis) denminads móduls, que sã integrads para atender as requisits ditads pel prblema; Argument basead em bservações sbre a resluçã de prblemas humans: C(x) - funçã que define a cmplexidade de um prblema x; E(x) - funçã que define esfrç exigid para reslver prblema x; Sejam 2 prblemas p1 e p2: Observu-se que Se C(p1) > C(p2) entã E(p1) > E(p2) prblema mais difícil. demra mais para se reslver um C(p1 + p2) > C(p1) + C(p2) a cmplexidade de um prblema que cmbine p1 e p2 é mair d que a cmplexidade percebida quand cada prblema é cnsiderad separadamente. E(p1 + p2) > E(p1) + E(p2) é mais fácil reslver um prblema cmplex quand ele é dividid em partes. OBS.: Atençã Mdularizar em exager pde se trnar um prblema, vist que a necessidade de integraçã entre s móduls irá aumentar, prtant é precis ter bm-sens e encntrar equilíbri entre s móduls. ARQUITETURA DE SOFTWARE Deriva de um prcess de divisã em partições que relacina elements de uma sluçã de sftware a partes de um prblema d mund real; Relacinad as cnceits de Móduls e de Estruturas de Dads. Sub-cnceit: HIERARQUIA DE CONTROLE u ESTRUTURA DO PROGRAMA Representa a rganizaçã de cmpnentes de prgrama; Nã representa aspects prcedimentais de sftware (sequência, decisões u repetições); Ntaçã cmum para representar a hierarquia de cntrle: Diagrama em árvres; Medidas da Estrutura: Prfundidade: indica númer de níveis de cntrle; Largura: indica espaç de cntrle glbal; "Fan-Out": indica númer de móduls que sã diretamente cntrlads pr utr módul; "Fan-In": indica quants móduls cntrlam diretamente determinad módul; Relacinament entre s móduls: Um módul que cntrla utr módul é superrdenad a ele; Um módul cntrlad pr utr mdul é subrdinad a cntrladr. Outras Características: Visibilidade: indica cnjunt de cmpnentes de prgrama que pde ser invcad u usad cm dads pr determinad cmpnente;

121 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 121 Cnectividade: indica cnjunt de cmpnentes que é diretamente invcad u usad cm dads pr determinad cmpnente. ESTRUTURA DE DADOS É uma representaçã d relacinament lógic entre elements de dads individuais. Determina a rganizaçã, métds de acess, grau de assciatividade e alternativas de prcessament de infrmaçã; Estruturas de Dads clássicas: item escalar (variáveis simples), vetr sequencial, espaç n- dimensinal, lista interligada e árvre hierárquica; As estruturas de dads clássicas frmam blcs de cnstruçã para estruturas mais sfisticadas. PROCEDIMENTO DE SOFTWARE Fcaliza s detalhes de prcessament de cada módul individualmente, cmplementand a hierarquia de cntrle; O Prcediment deve ferecer uma especificaçã mais precisa d prcessament (sequência de events, pnts de decisã, perações repetitivas e até mesm estrutura e rganizaçã de dads). OCULTAMENTO DE INFORMAÇÕES O cnceit de mdularidade leva engenheir de sftware a uma questã fundamental: "cm decmpr uma sluçã de sftware para bter melhr cnjunt de móduls?" O princípi da "cultaçã de infrmações" sugere que s móduls sejam "caracterizads pelas decisões de prjet que (cada módul) escnde de tds s utrs"; Os móduls devem ser especificads e prjetads de tal frma que as infrmações (prcediments e dads) cntidas num módul sejam inacessíveis a utrs móduls que nã tenham necessidade de tais infrmações; A cultaçã implica em uma mdularidade ande um cnjunt de móduls independentes cmunicam entre si smente aquelas infrmações que sã necessárias para se bter a funçã d sftware. PARTICIONAMENTO ESTRUTURAL Particinament hrizntal e vertical; Define as três partições - Entrada, Prcessament e Saída. 5.7 PROJETOS PROJETO DE ARQUITETURA Origem: Prjet de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. O mdel de arquitetura mapeia s requisits essenciais da fase de análise em uma arquitetura técnica. Uma vez que muitas arquiteturas diferentes sã pssíveis, prpósit d prjet arquitetural é esclher a melhr cnfiguraçã (u talvez a mens pir ). O prcess de prjetar a arquitetura inclui:

122 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 122 A cleta de estatísticas de vlumes de dads, frequência de dispar de events e expectativas de temps de respsta para mdel essencial; A dcumentaçã da tplgia gegráfica d negóci; A determinaçã da distribuiçã gegráfica ds lcais de cmputaçã; A definiçã d particinament de dads e prcesss entre s lcais de cmputaçã; A determinaçã d tráfeg em rede e tamanh das bases de dads para várias cnfigurações; e A validaçã d mdel de arquitetura cntra mdel essencial. Objetivs d Prjet Arquitetural Até prjet arquitetural, a questã d hardware ainda nã fi tratada, já que na fase de análise pressupõe-se tecnlgia perfeita. Este é mment para reslver cm este mdel ideal irá executar em uma platafrma restrita. É imprtante realçar que nã existe a sluçã perfeita. O prjet da arquitetura é uma tarefa de negciaçã, nde se faz cmprmisss entre sluções sub-ótimas. Em suma, prjet arquitetural cnsiste na alcaçã d mdel essencial de requisits em uma tecnlgia específica, determinand que prcesss rdarã em quais prcessadres, nde s dads serã armazenads e quanta cmunicaçã entre prcessadres será necessária. A términ d prjet arquitetural, a equipe de desenvlviment deve ter determinad: A distribuiçã gegráfica ds requisits cmputacinais; Os cmpnentes de hardware para as máquinas clientes; Os cmpnentes de hardware para as máquinas servidras; A cnfiguraçã e númer de camadas de hardware cliente-servidr; A platafrma de sftware de implementaçã, incluind linguagens de cdificaçã e apresentaçã (interface cm usuári), sistemas peracinais, s mecanisms e linguagens de cmunicaçã em rede e sistema gerenciadr de banc de dads; A lcalizaçã u lcalizações ds prcesss; A lcalizaçã u lcalizações ds dads físics; e As estratégias de sincrnizaçã para dads distribuíds gegraficamente. Muitas dessas decisões já terã sid tmadas previamente, seja pr uma rdem da gerência, seja pel fat da rganizaçã já pssuir uma platafrma de hardware e sftware para implementaçã. Assim, prjet de arquitetura é a busca pr um mei mens bjetável de atingir s requisits d negóci, recnhecend as limitações da platafrma a ser utilizada. A Arquitetura Cliente-Servidr A cmputaçã cliente-servidr é um prcessament cperativ de infrmações de negóci pr um cnjunt de prcessadres, n qual múltipls clientes gegraficamente distribuíds iniciam requisições que sã realizadas pr um u mais servidres centrais. Primrdialmente, term cliente-servidr é usad para descrever sftware que executa em mais de um hardware de md a realizar uma tarefa d negóci. A separaçã de hardware é a nrma em aplicações cliente-servidr, embra algumas pessas utilizem term para descrever diferentes cmpnentes de sftware se cmunicand uns cm s utrs, ainda que rdand em uma mesma máquina. A distância entre prcessadres remts varia desde cmputadres lcalizads na mesma sala u prédi, até aqueles lcalizads em diferentes prédis, cidades u mesm espalhads pel planeta. Atualmente, há muits tips diferentes de prcessadres, que pdem ser melhr utilizads para serem clientes u servidres. Máquinas de grande prte (mainframes), pr exempl, sã pdersas,

123 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 123 mas requerem grande habilidade para perá-las e sã subutilizadas para uma ampla variedade de requisições cmuns. Cmputadres pessais (PCs), pr sua vez, sã bem melhres para gerenciar apresentações (interface cm usuári), necessitam de mens habilidades d usuári para perá-ls e prvêem prcessament eficiente e barat para muitas das tarefas de uma rganizaçã. O us mais cmum para arquiteturas cliente-servidr é explrar pder ds PCs para gerenciar interfaces gráficas cm usuári, mantend a integridade ds dads d negóci em uma máquina hspedeira central. Em sua frma mais simples, a arquitetura cliente-servidr envlve múltipls clientes fazend requisições para um únic servidr, cm mstra a figura 2.2. Este mdel mstra uma arquitetura de hardware em duas camadas (tw-tier). É fácil imaginar que, nesta arquitetura de hardware, a prçã sftware de interface ficará n cliente, enquant armazenament de dads deverá ser feit em um u mais servidres centrais. Mas e restante da aplicaçã? Nã há respstas fáceis. Antes de explrar as pssibilidades, vams cmplicar um puc mais a questã, intrduzind mais camadas na arquitetura cliente-servidr. A figura 2.3 mstra uma arquitetura cliente-servidr em três camadas, na qual máquinas-cliente estã cnectadas via uma rede lcal a um servidr lcal de aplicaçã que, pr sua vez, se cmunica cm um servidr de dads central. Em uma arquitetura de três camadas, a nçã de cliente e servidr cmeça a se trnar nebulsa. Um PC que hspeda uma aplicaçã de interface é certamente um cliente e a máquina hspedeira da base de dads é certamente um servidr. Mas e servidr lcal de aplicaçã? Ele é algumas vezes um cliente e utras um servidr, dependend da direçã de cmunicaçã. Esta arquitetura pde ser estendida para n camadas (n-tier), cm mstra a figura 2.4. Nestes cass, a distinçã entre cliente estrit e servidr estrit é destruída, trnand term um padrã cnceitual.

124 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 124 Camadas de Sftware Cliente-Servidr Para discutir desenvlviment de sftware em uma arquitetura multi-camada de hardware, é necessári primeir dissecar a aplicaçã de sftware em camadas. Os cmpnentes de uma aplicaçã de negóci pdem ser agrupads em pel mens três categrias principais, cm mstra a figura 2.5: Camada de Apresentaçã: é a camada mais externa d sistema de sftware. Sua funçã é capturar estímuls de events externs e realizar alguma ediçã ds dads de entrada. É

125 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 125 encarregada também de apresentar respstas as events para mund exterir. Geralmente, é lcalizada em uma máquina cliente, tal cm um PC, entretant, esta nã é uma regra rigrsa; Camada de Lógica d Negóci: cntém códig que executa e impõe a plítica d negóci. Regras, regulaments e cálculs sã encntrads nesta camada. É a camada mais móvel, pdend ser lcalizada em clientes remts, n servidr central u em qualquer utr lcal intermediári; Camada de Gerência de Dads: prvê acess a dads crprativs. Gerencia requisições cncrrentes de acess às bases de dads, assim cm a sincrnizaçã de elements de dads distribuíds. Muit desta camada estará n mesm lcal físic que s dads. Cliente Pesad x Servidr Pesad Uma classificaçã, relativamente incrreta, tem sid para utilizada para designar a filsfia adtada em um prjet n que se refere à lcalizaçã da mair parte da camada de lógica d negóci. O term cliente pesad indica que a camada de lógica d negóci é clcada principalmente na máquina cliente e servidr é dedicad a acess, distribuiçã e armazenament de dads, respndend a requisições de clientes. O term servidr pesad descreve uma alcaçã de respnsabilidades na qual cliente é limitad à apresentaçã da interface e ediçã mínima, enquant a mair parte da lógica de negóci e a impsiçã de regras sã executadas n servidr central. É clar que esta é uma visã muit simplificada, já que arquiteturas cliente-servidr em n-camadas pdem suprtar uma gama de cmplexa de camadas de sftware. A primeira geraçã de ferramentas ppulares de desenvlviment de aplicações cliente-servidr cm interfaces gráficas assumia uma arquitetura de hardware de duas camadas e encrajava uma abrdagem de prjet arquitetural de sftware d tip cliente pesad, nde a lógica d negóci era ttalmente amarrada à camada de apresentaçã da aplicaçã. Estas mesmas ferramentas têm sid utilizadas, em um segund mment, cm uma filsfia d tip servidr pesad, nde a lógica de negóci é frtemente mapeada n servidr de dads, na frma de stred-prcedures e triggers em bancs de dads. Respndend às demandas pr linguagens mais flexíveis de desenvlviment, a segunda geraçã de ferramentas desta natureza recnhece a necessidade de separar a camada de lógica d negóci. Esta separaçã traz várias vantagens, cm reusabilidade, prtabilidade e manutenibilidade. A reusabilidade tem sid apntada cm a principal razã para a separaçã. Classes de apresentaçã sã extremamente fáceis de reutilizar dada sua natureza altamente mecânica. Classes de negóci, pr utr lad, sã altamente cmplexas e pdem desempenhar diferentes papéis dentr

126 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 126 ds sistemas crprativs. A meta é criar classes que garantam tdas as regras de negóci para uma particular classe de negóci e reutilizá-la em tds s cntexts que lidem cm a mesma. Esta abrdagem é pssível em uma filsfia de servidr pesad, mas impssível em uma de cliente pesad. A prtabilidade é a segunda razã para se efetuar a separaçã. A habilidade de mver a lógica de negóci a lng da arquitetura cliente-servidr permite que se tire prveit de diferentes platafrmas de hardware e sftware, sem ter que reescrever grandes prções d códig. Finalmente, a separaçã favrece a manutençã, já que cncentra a lógica de negóci em uma camada única da arquitetura de sftware, facilitand a lcalizaçã das alterações e evluções a serem feitas n sistema PROJETO DE DADOS Origem: Prjet de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. Um aspect fundamental da fase de prjet cnsiste em estabelecer de que frma serã armazenads s dads d sistema. Em funçã da platafrma de implementaçã, diferentes sluções de prjet devem ser adtadas. Ist é, se sftware tiver de ser implementad em um banc de dads hierárquic, pr exempl, um mdel hierárquic deve ser prduzid, adequand a mdelagem cnceitual de dads (ER u diagrama de classes) a esta platafrma de implementaçã. Atualmente, a platafrma de implementaçã para armazenament de dads mais difundida é a ds Bancs de Dads Relacinais. OBS.: Maires detalhes sbre Prjet de Dads serã discutids na disciplina de Banc de Dads PROJETO DE INTERFACE Origem: Prjet de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. A mairia ds sistemas atuais é desenvlvida para ser utilizada pr pessas. Assim, um aspect fundamental n prjet de sistemas é a interface cm usuári (IU). Nesta etapa d prjet, sã definids s frmats de janelas e relatóris, entre utrs, send a prttipagem bastante utilizada, buscand auxiliar desenvlviment e a seleçã ds mecanisms reais de interaçã. A IU capta cm um usuári cmandará sistema e cm sistema apresentará as infrmações a ele. O princípi básic para prjet de interfaces cm usuári, em geral, é seguinte: Cnheça usuári e as tarefas. O prjet de interface cm usuári envlve nã apenas aspects de tecnlgia (facilidades para interfaces gráficas, multimídia, etc), mas principalmente estud das pessas. Quem é usuári? Cm ele aprende a interagir cm um nv sistema? Cm ele interpreta uma infrmaçã prduzida pel sistema? O que ele espera d sistema? Estas sã apenas algumas das muitas questões que devem ser levantadas durante prjet da interface cm usuári (Pressman, 2002). De maneira geral, prjet de interfaces cm usuári segue seguinte prcess glbal, cm mstra a figura 3.1: 1. Delinear as tarefas necessárias para bter a funcinalidade d sistema: este pass visa capturar as tarefas que as pessas fazem nrmalmente n cntext d sistema e mapeá-las em um cnjunt similar (mas nã necessariamente idêntic) de tarefas a serem implementadas n cntext da interface hmem-máquina. 2. Estabelecer perfil ds usuáris: A interface d sistema deve ser adequada a nível de habilidade ds seus futurs usuáris. Assim, é necessári estabelecer perfil destes ptenciais usuáris e classificá-ls segund aspects cm nível de habilidade, nível na rganizaçã e membrs em diferentes grups. Uma classificaçã pssível cnsidera s seguintes grups:

127 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 127 Usuári Nvat: nã cnhece s mecanisms de interaçã requerids para utilizar a interface eficientemente (cnheciment sintátic) e cnhece puc a aplicaçã em si, ist é, entende puc as funções e bjetivs d sistema (semântica da aplicaçã); Instruíd, mas intermitente: pssui um cnheciment razável da semântica da aplicaçã, mas tem relativamente puca lembrança das infrmações sintáticas necessárias para utilizar a interface; Instruíd e frequente: pssui bm cnheciment tant sintátic quant semântic e buscam atalhs e mds abreviads de interaçã. 3. Cnsiderar aspects gerais de prjet de interface, tais cm temp de respsta, facilidades de ajuda, mensagens de err, tips de cmands, entre utrs. 4. Cnstruir prtótips e, em última instância, implementar as interfaces d sistema, usand ferramentas aprpriadas. A prttipaçã abre espaç para uma abrdagem iterativa de prjet de interface cm usuári, cm mstra abaix. Entretant, para tal é imprescindível suprte de ferramentas para a cnstruçã de interfaces, prvend facilidades para manipulaçã de janelas, menus, btões, cmands, etc Avaliar resultad: Cletar dads qualitativs e quantitativs (questináris distribuíds as usuáris d prtótip). Aspects Gerais de Interface cm Usuári Cm relaçã as aspects gerais de um prjet de interface, citads n item 3, devems cnsiderar, pel mens, seguinte cnjunt: Temp de Respsta: É imprtante mstrar prgress d prcessament para s usuáris, principalmente para events cm temp de respsta lng u cm grande variaçã de temps de respsta. Facilidade de Ajuda (Help). Definir: Quand estará dispnível e para que funções d sistema; Cm ativar (btã, tecla de funçã, menu);

128 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 128 Cm representar (janela separada, lcal fix da tela); Cm retrnar à interaçã nrmal (btã, tecla de funçã); Cm estruturar a infrmaçã (estrutura plana, hierárquica, hipertext). Mensagens de Err e Aviss. Devem: Descrever prblema cm um vcabulári passível de entendiment pel usuári; Prver assistência para recuperar err; Indicar quaisquer cnsequências negativas d err; Ser acmpanhadas de uma dica visual u snra; Ser sem censura a usuári. Tips de Cmands. Em muitas situações deve-se prver a usuári a pçã de utilizaçã de cmands. Nestes cass, definir e avaliar: Se tda pçã de menu terá um cmand crrespndente; A frma d cmand (cntrle de sequência (^Q), teclas de funçã (F1), palavra); Quã difícil é aprender e lembrar cmand; Pssibilidade de custmizaçã de cmands (macrs); Padrões para td sistema e cnfrmidade cm utrs padrões. Algumas rientações adicinais devem ser cnsideradas e sã listadas na sequência. Diretrizes Gerais: Seja cnsistente (frmat cnsistente para seleçã de menus, entrada de cmands, apresentaçã de dads,...); Ofereça retrn significativ a usuári (cmunicaçã cm usuári); Peça cnfirmaçã para ações destrutivas (deletar arquiv, sbrepr infrmaçã, terminar a aplicaçã,...); Permita reversã fácil da mairia das ações (funçã UNDO); Reduza a quantidade de infrmaçã que precisa ser memrizada entre ações; Busque eficiência n diálg (mvimentaçã, teclas a serem apertadas); Trate pssíveis errs d usuári ( sistema deve se prteger de errs, casuais u nã, prvcads pel usuári); Classifique atividades pr funçã e rganize gegraficamente a tela de acrd (menus pulldwn); Prveja facilidades de ajuda sensíveis a cntext; Use verbs de açã simples u frases verbais curtas para nmear funções e cmands. Diretrizes para Apresentaçã de Infrmaçã: Mstre apenas infrmações relevantes a cntext crrente; Use frmats de apresentaçã que permitam assimilaçã rápida da infrmaçã (gráfics, figuras, etc.);

129 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 129 Use rótuls cnsistentes, abreviaturas padrã e cres previsíveis; Prduza mensagens de err significativas; Prjete adequadamente layut de infrmações textuais (letras maiúsculas e minúsculas, identaçã, agrupament de text, etc.); Use janelas para separar diferentes tips de infrmaçã; Use frmas de representaçã análgas às d mund real para facilitar a assimilaçã da infrmaçã (figuras, cres, etc.). Diretrizes para a Entrada de Dads: Minimize númer de ações de entrada requeridas (seleçã de dads a partir de um cnjunt pré-definid de valres de entrada, macrs, etc.); Mantenha cnsistência entre apresentaçã e entrada de dads (características visuais: tamanh d text, cr, lcalizaçã, etc.); Permita a usuári custmizar a entrada (cmands custmizads, dispensar algumas mensagens de avis e verificações de ações, etc.); Flexibilize a interaçã, permitind afiná-la a md de entrada preferid d usuári (cmands, btões, plug-and-play, digitaçã, etc.); Desative cmands inaprpriads para cntext das ações crrentes; Prveja ajuda para assistir tdas as ações de entrada de dads; Prveja valres default, sempre que pssível; Nunca requeira que usuári entre cm uma infrmaçã que pssa ser adquirida autmaticamente pel sistema u cmputada pr ele PROJETO DE COMPONENTES Origem: Engenharia de Sftware, Rger Pressman, 2006 O que é? Um cnjunt cmplet de cmpnentes de sftware é definid durante prjet arquitetural. Mas as estruturas de dads internas e detalhes de prcessament de cada cmpnente nã sã representads em um nível de abstraçã próxim a códig. Prjet n nível de cmpnente define as estruturas de dads, algritms, características de interface e mecanisms de cmunicaçã alcads a cada cmpnente de sftware; Quem faz? Um engenheir de sftware realiza prjet n nível de cmpnentes; Pr que é imprtante? Vcê precisa determinar se sftware vai funcinar antes de cnstruíl. O prjet n nível de cmpnentes representa sftware de um md que lhe permite revisar s detalhes d prjet quant à crreçã e cnsistência cm as primeiras representações d prjet (u seja, s prjets de dads, arquitetural e de interface). Ele frnece meis para avaliar se as estruturas de dads, interfaces e algritms vã funcinar; Quais sã s passs? Representações de prjet ds dads, arquitetura e interfaces frmam a fundaçã para prjet n nível de cmpnentes. A definiçã de classes u narrativa de prcessament para cada cmpnente é traduzida em um prjet detalhad que faz us de frmas diagramáticas u baseadas em text que especificam as estruturas de dads internas, detalhes de interface lcal e lógica de prcessament. A ntaçã de prjet inclui diagramas UML e representações suplementares. O prjet prcedural é especificad pr mei de um cnjunt de cnstruções da prgramaçã estruturada;

130 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 130 Qual é prdut d trabalh? O prjet de cada cmpnente, representad em ntaçã gráfica, tabular u baseada em text, é principal prdut de trabalh prduzid durante prjet n nível de cmpnente; Cm tenh certeza de que fiz crretamente? Um walk-thrugh, u inspeçã de prjet, é cnduzid. O prjet é examinad para determinar se as estruturas de dads, interfaces, sequências de prcessament e cndições lógicas estã crretas e vã prduzir as transfrmações adequadas ds dads u cntrle atribuídas a cmpnente durante s primeirs passs de prjet. 5.8 PROJETO ORIENTADO A OBJETOS Origem: Prjet de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. A Análise Orientada a Objets identifica e define classes que refletem diretamente dmíni d prblema e as respnsabilidades d sistema dentr dele. O Prjet Orientad a Objets (Object- Oriented Design - OOD) transfrma mdel de análise em um mdel de prjet que serve de base para a cnstruçã d sftware. A cntrári ds métds de prjet de sftware cnvencinais, prjet rientad a bjets resulta em um prjet que btém um númer de diferentes níveis de mdularidade. Os cmpnentes principais d sistema sã rganizads em móduls de nível de sistema, chamads subsistemas u pactes. Os dads e as perações que s manipulam sã encapsulads em classes. Além diss, OOD deve descrever a estrutura de dads específica ds atributs e s detalhes prcedurais de perações individuais. A análise geralmente transcrre cm a supsiçã de que há uma tecnlgia perfeita dispnível; já n prjet, sabe-se que sistema será implementad em uma platafrma de hardware, sb um sistema peracinal, usand uma linguagem de prgramaçã. Em suma, a análise interessa-se pel que sistema deve fazer, enquant prjet diz respeit a cm s requisits serã implementads e, prtant, pressupõe uma infra-estrutura de implementaçã e é frtemente influenciad pr ela. Assim, prjet de um sistema rientad a bjets é dependente de aspects cm: Características da linguagem de prgramaçã a ser utilizada: Qual tip de linguagem a ser usada (rientada a bjets, baseada em bjets, cnvencinal,...)? Se é uma LPOO, qual nível de herança suprtad (simples, múltipla)? Quais s mecanisms de acess a atributs e perações?, etc. Mdel de persistência de bjets: Que mecanism de persistência de bjets será utilizad (banc de dads rientad a bjets, banc de dads relacinal, arquivs, persistência da própria linguagem de prgramaçã)? Características da platafrma de implementaçã: A platafrma de hardware é multiprcessada? O sistema é distribuíd? etc... Características da interface cm usuári: Que tip de interface cm usuári será utilizada (interfaces gráficas, rientadas a caracter,...)? O Prjet Orientad a Objets identifica e define classes adicinais, refletind requisits de implementaçã. Deste md, as ferramentas de mdelagem utilizadas na fase de análise - Diagrama de Classes, Diagramas de Interaçã e Diagramas de Transiçã de Estads - sã utilizadas também na fase de prjet, agra cm intuit de capturar s requisits de implementaçã. Entretant, a perspectiva de implementaçã existente n prjet, tipicamente, demanda extensões à ntaçã da análise para permitir representar visibilidade, persistência, cncrrência, exceções e restrições. Assim, ainda que a UML nã especifique explicitamente que ntações destes diagramas devem ser utilizadas nas fases de análise e de prjet, algumas de suas facilidades devem ser utilizadas apenas na fase de prjet, tais cm as ntações de visibilidade de atributs e perações e navegabilidade de relacinaments.

131 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 131 Ainda que a terminlgia e s passs d prcess de prjet sejam diferentes para cada um ds métds de prjet rientad a bjets, s prcesss glbais de prjet sã razavelmente cnsistentes (Pressman, 2002). De md geral, dis grandes passs pdem ser identificads: Prjet da Arquitetura d Sistema: descreve cada um ds subsistemas, de um md passível de implementaçã, e as cmunicações entre eles; Prjet de Objets: descreve aspects de implementaçã de cada uma das classes d sistema, incluind, prjet prcedural de cada peraçã, a definiçã de classes internas e prjet de estruturas de dads para s atributs das classes. Prjet da Arquitetura d Sistema A primeira tarefa a ser realizada n OOD cnsiste em definir uma arquitetura para a aplicaçã. Será sbre esta arquitetura que prjetista pderá intrduzir s aspects de implementaçã em um mdel de análise. Em sistemas cmplexs, a definiçã da arquitetura d sftware deve ser iniciada durante a fase de análise para permitir uma melhr rganizaçã ds mdels de análise, evitand a cmplexidade. A arquitetura de um sftware deve indicar cm sistema irá funcinar em um ambiente peracinal e frnecer s meis necessáris para a definiçã ds cmpnentes d sftware, das interações entre eles e ds padrões necessáris para que td esse ambiente cpere para prduzir sftware que está send prjetad (Magela, 1998). Uma ba arquitetura de sftware pde ser btida através da aplicaçã de duas idéias fundamentais (Magela, 1998): Prduçã de sftware em camadas cm níveis de abstraçã definids; e Separaçã entre interface e implementaçã. Desta frma, uma ba arquitetura de sftware deve ser elabrada em terms ds cmpnentes que cmpõem este sftware. Dificilmente é pssível cmpreender prjet de um sftware cm um td. A cntrári, é melhr dividi-l em cmpnentes gerenciáveis, de cmplexidade reduzida. Esta quebra deve ser refletida n prjet da arquitetura d sistema. Além diss, a arquitetura deve levar em cnsideraçã requisits tecnlógics u nã-funcinais, tais cm segurança, desempenh, manutenibilidade e ecnmia (Magela, 1998). A rganizaçã de classes em pactes deve ser pnt de partida para a definiçã da arquitetura, já que é um mei de estabelecer níveis de abstraçã para mdel. Esses níveis de abstraçã pdem ser rganizads em camadas e, assim, tratads separadamente durante a fase de prjet. A rganizaçã de classes em pactes é útil também para permitir a prduçã de cmpnentes para reus. Uma frma bastante utilizada para rganizaçã em pactes cnsiste em agrupar classes de acrd cm tip de funçã que exercem n sistema, ist é, seu estereótip. Uma classe pssui smente um estereótip. Nã pdems ter uma classe cm dis estereótips, uma vez que ela pssuiria duas respnsabilidades distintas, que deveria levar a duas classes distintas (Magela, 1998). Além da rganizaçã pr estereótips, pde ser útil agrupar classes em funçã d dmíni d prblema. A rganizaçã pr dmíni de prblema cnduz à cnstruçã de pactes verticais, levand à prduçã de cmpnentes de negóci (Magela, 1998). Cntud, esta abrdagem islada é, nrmalmente, insuficiente. Assim, uma vez que um pacte pde cnter utrs pactes, uma abrdagem mais eficiente, sbretud para sistemas cmplexs, cnsiste em realizar primeiramente uma rganizaçã pr dmíni d prblema e, psterirmente, fazer uma subdivisã ds pactes d dmíni em estereótips. Quand esta abrdagem baseada n dmíni d prblema fr adtada, primeir pass a ser dad cnsiste em particinar mdel de análise para definir cleções cesas de classes, relacinaments e cmprtament, empactand-s em pactes u subsistemas.

132 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 132 De fat, este pass é uma revisã da identificaçã de subsistemas feita na fase de análise, agra levand em cnta requisits de implementaçã. Subsistemas devem ser definids e prjetads em cnfrmidade cm s seguintes critéris (Pressman, 2002): Um subsistema deve pssuir uma interface bem definida através da qual tda cmunicaçã cm restante d sistema crre. Cm exceçã de um pequen númer de classes de cmunicaçã, as classes dentr de um subsistema devem clabrar apenas cm utras classes deste mesm subsistema. O númer de subsistemas deve ser mantid pequen. Subsistemas pdem ser particinads internamente para auxiliar a reduzir a cmplexidade. Esta subdivisã pderá ser feita ainda segund critéri dmíni d prblema (para prblemas muit cmplexs) u usand critéri de agrupament pr estereótips. Cmpnentes de Prjet A cmunidade de Smalltalk desenvlveu uma metáfra simples, mas elegante, para uma arquitetura de prjet, cnhecida cm Mdel-Visã-Cntrladr (Mdel-View-Cntrller) - MCV. Essencialmente, ela sugere que uma arquitetura típica de prjet rientad a bjets pssui três cmpnentes principais: um grup de classes que mdela a aplicaçã em si; um grup de classes que prvê uma visã da interface cm s usuáris; e um grup de classes que cntrla, u sincrniza, cmprtament ds demais. A arquitetura MCV é um bm pnt de partida. Cntud, ela descnsidera um imprtante cmpnente: a gerência de dads. Ist se deve a fat de, em Smalltalk, tds s bjets serem naturalmente persistentes. Assim, durante prjet da arquitetura d sistema, um engenheir de sftware deve cnsiderar quatr (e nã apenas três) cmpnentes básics, cm mstra a figura 5.1 (Cad et al., 1993): Cmpnente d Dmíni d Prblema: crrespnde as subsistemas respnsáveis pr implementar diretamente s requisits ds usuáris; Cmpnente de Interaçã Humana: crrespnde as subsistemas que implementam as interfaces cm usuári; Cmpnente de Gerência de Tarefa: crrespnde as subsistemas respnsáveis pr cntrlar e crdenar tarefas; Cmpnente de Gerência de Dads: crrespnde as subsistemas respnsáveis pel armazenament e recuperaçã de bjets (persistência ds bjets). A idéia básica dessa arquitetura é simples, mas crucial: ela vai buscar as mesmas classes que fram dcumentadas n mdel de análise e, entã, as envlve cm classes adicinais para tratar aspects relacinads à implementaçã de gerência de tarefa, gerência de dads e interaçã humana. Essa arquitetura nã só preserva mdel de análise, cm também utiliza cm cerne d mdel de prjet.

133 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 133 Deve-se ntar que, pr detrás dessa arquitetura, há uma filsfia de prjet que sugere que as classes centrais, rientadas à aplicaçã na CDP, nã devem estar cientes d mund exterir e nã têm de saber cm interagir cm tal mund. Este é um pnt fundamental, já que, sem uma atençã cnsciente a esta filsfia, pdems chegar a uma arquitetura na qual cada classe: (i) sabe cm interagir cm usuári final e (ii) sabe cm ler e escrever seus dads permanentes em arquivs de disc. Uma abrdagem assim pderia funcinar (quem sabe até de maneira mais rápida), mas seria muit suscetível a mudanças na interface cm usuári u n mdel de persistência. Além diss, fatalmente trnaria a estrutura interna das classes mais cmplexa d que se tivessem de estar cientes apenas de seus detalhes essenciais, ligads a dmíni da aplicaçã. Assim, seguind a arquitetura básica prpsta pr Cad e Yurdn (Cad et al.,1993), tems quatr estereótips: Dmíni d Prblema; Interface cm Usuári; Gerência de Tarefas; Gerência de Dads. De fat, utrs estereótips pdem ser usads para rganizar classes, tais cm Classes Limítrfes, Utilitáris, Classes de Exceções, Cntrladres, etc. Prjet da Cmpnente d Dmíni d Prblema N OOD, s resultads da OOA fazem parte da Cmpnente de Dmíni d Prblema (CDP). Em muits cass, mdel de análise desenvlvid pde ser transpst para dentr da CDP sem qualquer alteraçã adicinal. Mas, algumas vezes, ele pde ser mdificad u estendid, de acrd cm as necessidades d prjet. Alterações pdem advir da necessidade de: reutilizar prjets anterires e classes já prgramadas: uma vez que uma das principais mtivações da rientaçã a bjets é a reutilizaçã de sftware, é imprtante que na fase de prjet seja levada em cnta a existência de biblitecas de classes passíveis de serem reusadas. Tipicamente, ajustes feits para incrprar tais classes envlvem alterações nas hierarquias de generalizaçã-especializaçã d mdel, de md a tratar as classes aprpriadas da OOA cm subclasses de classes de bibliteca pré-existentes, btend a vantagem ttal da habilidade de herdar atributs e métds de tais classes. ajustar mdel a nível de herança suprtad: em funçã d nível de herança suprtad pela linguagem de prgramaçã a ser usada na implementaçã, mdel da OOA pde ter de ser alterad. Se, pr exempl, mdel da OOA envlve herança múltipla e a linguagem de implementaçã nã ferece tal recurs, alterações n mdel serã necessárias. ajustar mdel para melhrar desempenh: desempenh pde ser uma precupaçã se há um alt tráfeg de mensagens entre bjets, se a linguagem de prgramaçã implementa herança ineficientemente, u pr várias utras razões advindas da abrdagem rientada a bjets. Nestes cass, prjetista pde alterar mdel de análise para melhr acmdar s ajustes necessáris. ajustar mdel para facilitar prjet de interfaces cm usuári amigáveis: cm bjetiv de incrprar a característica de qualidade facilidade de us, pde ser imprtante cnsiderar nvas classes que facilitem a apresentaçã de listas para seleçã d usuári, pr exempl. A CDP pde ser alterada, ainda, para cmprtar utrs requisits tecnlógics, tais cm segurança, cnfiabilidade, etc. Prjet da Cmpnente de Interface cm Usuári A premissa fundamental que justifica a existência deste cmpnente é a seguinte: a prçã d sistema que lida cm a interface cm usuári deve ser mantida tã independente e separada d rest da arquitetura d sftware quant pssível. A razã para tal é evidente: aspects de interface cm usuári prvavelmente serã alv de alterações a lng de tda a vida prdutiva d sistema,

134 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 134 e essas alterações devem ter um impact mínim (idealmente, nenhum impact) nas partes específicas da aplicaçã d sistema. A Cmpnente de Interface cm Usuári (CIU) adicina detalhes sbre prjet da interaçã humana, incluind frmat de janelas e relatóris, entre utrs. Nesta etapa, a prttipaçã é geralmente utilizada, buscand auxiliar desenvlviment e a seleçã ds mecanisms reais de interaçã. A CIU capta cm um usuári cmandará sistema e cm sistema apresentará as infrmações a ele. Cm citad anterirmente, princípi básic para prjet de interfaces cm usuári é seguinte: Cnheça usuári e as tarefas. Assim send, mdel de cass de us deve ser guia para esta atividade, já que mdela exatamente a interaçã entre atres (classes de usuáris) e cass de us (tarefas u funcinalidades d sistema). N desenvlviment rientad a bjets, pnt de partida para prjet da CIU é mdel de cass de us e seus cenáris e descrições de atres. Cm base ns cass de us, devems prjetar uma hierarquia de cmands, definind barras de menu, menus pulldwn, ícnes, etc., que levem a ações quand acinads pel usuári. A hierarquia de cmands deve respeitar cnvenções e estils existentes cm s quais usuári já esteja familiarizad. Nte que a hierarquia de cmands é, de fat, um mei de apresentar a usuári as várias funcinalidades dispníveis n sistema, u, lhand sb utr pnt de vista, as várias mensagens que usuári pde enviar para as classes dentr d sistema. A hierarquia de cmands deve ser refinada até que tds s cass de us pssam ser implementads, através da navegaçã nesta hierarquia. Uma vez definida a hierarquia de cmands, as interações detalhadas entre usuári e sistema devem ser prjetadas. Neste mment, bserve us de terms, passs e ações cnsistentes. Observe, também, aspects relacinads a desempenh, temp de respsta e facilidade de us e aprendizagem. Nã brigue usuári a ter de lembrar cisas. Frneça ajuda interativa. Nrmalmente, nã é necessári prjetar as classes básicas de interfaces gráficas cm usuári. Existem váris ambientes de desenvlviment de interfaces, ferecend classes reutilizáveis (janelas, ícnes, btões,...) e, prtant, basta especializar as classes e instanciar s bjets que pssuem as características aprpriadas para prblema em questã. Em ambientes cm interfaces gráficas, a hierarquia de classes básica para a CIU terá tipicamente uma superclasse janela e as janelas da aplicaçã serã cnstruídas adicinand s utrs bjets gráfics necessáris, tais cm btões, menus, ícnes. Prjet da Cmpnente de Gerência de Tarefas A Cmpnente Gerência de Tarefas (CGT) cmpreende a definiçã de tarefas e a cmunicaçã e crdenaçã entre elas. O bjetiv básic desta etapa d prjet é definir e classificar as tarefas. Algumas funcinalidades nã sã facilmente distribuídas nas classes da CDP, principalmente aquelas que peram sbre váris bjets. Uma pssibilidade para reslver tal prblema é pulverizar esse cmprtament a lng de váris bjets da CDP u da CIU. Cntud, esta nã é uma ba sluçã segund uma perspectiva de alterabilidade. Uma alteraçã em tal funcinalidade pderia afetar diverss bjets, e assim ser difícil de ser incrprada. Uma abrdagem mais interessante é mdelar as classes da CGT cm gerenciadres u crdenadres de tarefas, respnsáveis pela realizaçã de tarefas sbre um determinad cnjunt de bjets. Tipicamente, esses gerenciadres agem cm aglutinadres, unind utrs bjets para dar frma a um cas de us. Cnsequentemente, gerenciadres de tarefa sã nrmalmente encntrads diretamente a partir ds cass de us. Os tips de funcinalidade tipicamente atribuíds a gerenciadres de tarefa incluem: cmprtament relacinad a transações, sequências de cntrle específicas a um cas de us, u funcinalidades que separam bjets da CDP e da CIU. É imprtante bservar, ainda, que s aspects dinâmics de um mdel de análise mstram a existência, u nã, de cncrrência entre bjets (u subsistemas). Se bjets (u subsistemas) nã têm de estar ativs em um mesm mment, entã nã há necessidade de prcessament cncrrente e, prtant, prcessament d sistema pde ser atribuíd a um únic prcessadr. Cas cntrári, duas pções de alcaçã devem ser cnsideradas (Pressman, 2002):

135 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 135 Alcar cada subsistema a um prcessadr independente: esta abrdagem requer sistemas multi-prcessads u distribuíds; Alcar s subsistemas para mesm prcessadr e prver suprte a cncrrência através de características de sistemas peracinais: neste cas, serã necessárias nvas classes de gerência de tarefas, respnsáveis pr este suprte. Em um esbç preliminar, pde-se atribuir um gerenciadr de tarefa para cada cas de us, send que s seus cenáris dã rigem a perações da classe que representa cas de us. Nesta abrdagem, a alterabilidade é facilitada, uma vez que, detectad um prblema em um cas de us, é fácil identificar a classe que trata d mesm. Um pssível prblema, cntud, é desempenh: para sistemas grandes, cm muits cass de us, haverá muitas classes de gerência de tarefa e, para realizar uma tarefa, pde ser necessária muita cmunicaçã entre essas classes. Uma sluçã diametralmente psta cnsiste em definir uma única classe de aplicaçã para td sistema. Neste cas, s cenáris de tds s cass de us dã rigem a perações dessa classe. Fica evidente que, excet para sistemas muit pequens, a classe de aplicaçã será extremamente cmplexa e, prtant, esta abrdagem nã seria prática. Nrmalmente, uma sluçã intermediária entre as duas anterirmente apresentadas cnduz a melhres resultads. Nesta abrdagem, cass de us cmplexs sã designads a classes de gerência de tarefas específicas. Cass de us mais simples e de alguma frma relacinads sã tratads pr uma mesma classe de aplicaçã. Uma cisa é certa: pel mens um gerenciadr de tarefa será sempre necessári a classe Aplicaçã, representand sistema cm um td. Os bjets desta classe representam as várias sessões (execuções) d sistema. Obviamente, é necessári levar em cnta, ainda, quants executáveis devem ser gerads para sistema. Se mais d que um fr necessári, cada executável terá de dar rigem a uma classe de aplicaçã. Outrs fatres que afetam esta decisã sã aspects de distribuiçã gegráfica e se sistema será um aplicativ u um sistema rdad a partir de um navegadr. A hierarquia de tarefas a serem realizadas ferece um recurs bastante útil para a definiçã das janelas, menus u utrs cmpnentes de interaçã necessáris para cada uma dessas tarefas. Assim s prjets das cmpnentes de interaçã humana e de gerência de tarefa estã bastante relacinads, e devem ser realizads cnjuntamente, uma vez que, muitas vezes, sã as tarefas que determinam a necessidade de elements de interface cm usuári para sua execuçã. Prjet da Cmpnente de Gerência de Dads A Cmpnente de Gerência de Dads (CGD) prvê a infra-estrutura básica para armazenament e a recuperaçã de bjets n sistema. Sua finalidade é islar s impacts da tecnlgia de gerenciament de dads sbre a arquitetura d sftware (Cad et al.,1993). A questã primrdial neste mment d prjet é: Cm trnar persistentes s bjets d sistema? De md geral, sã quatr as pções atualmente dispníveis para suprtar a persistência de bjets: Us de arquivs: Neste cas, é necessári estabelecer uma estratégia para escrita e leitura de uma série de bjets em um arquiv simples. Um layut simples para um arquiv pde ser pensad em terms de um bjet pr linha, cm s atributs d bjet iniciand e terminand em psições específicas. As facilidades ferecidas pelas próprias linguagens de prgramaçã para manipular arquivs devem ser utilizadas. Persistência de bjets frnecida pela própria linguagem de prgramaçã, cm é cas de Smalltalk (arquiv IMAGE) e Eiffel (classe STORABLE). Em Smalltalk, tds s bjets sã persistentes e, a encerrar uma sessã, estad de td ambiente é salv em um arquiv. Neste cas, nã há prjet da CGD. Eiffel, pr sua vez, ferece a classe STORABLE, que ferece mecanisms para salvar e recuperar bjets persistentes. Neste cas, prjet da CGD cnsiste em definir que classes devem ser definidas cm subclasses de STORABLE.

136 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 136 Bancs de dads de bjets: Em um ambiente rientad a bjets, a sluçã ideal para essa questã seria usar um Sistema de Gerenciament de Bancs de Dads Orientad a Objets (SGBDOO), nde cada uma das classes persistentes na arquitetura de sftware crrespnderia a exatamente uma base de dads gerenciada pel SGBDOO. Bancs de dads relacinais: Ainda que haja diferenças entre a abrdagem relacinal e paradigma de bjets, s bancs de dads relacinais tem sid utilizads pela mairia ds desenvlvedres OO para armazenar bjets (Ambler, 1998). Alguns ambientes de prgramaçã, tais cm certs ambientes C++ e ambiente Delphi (Object Pascal), ferecem facilidades de interface cm alguns bancs de dads relacinais. Neste cas, prjet da CGD é frtemente dependente d nível de suprte ferecid. Cas ambiente encapsule ttalmente banc de dads relacinal, prjet pde ser muit semelhante a prjet usand um banc de dads OO; cas cntrári, prjetista deve efetuar um prjet de bases de dads relacinais, definind suas tabelas, para só entã pder utilizá-las n prjet OO da CGD. Utilizand SGBDs relacinais, geralmente, prcess de prjet cmeça pela traduçã das classes n mdel rientad a bjets para a terceira frma nrmal padrã. Para cada tabela em terceira frma nrmal, derivada deste prcess de nrmalizaçã de bjets, uma tabela na base de dads é definida. A despeit da pçã de persistência adtada, utra questã deve ser cnsiderada: Que classes devem suprtar a persistência ds bjets? Uma alternativa seria trnar cada classe, a lng de tda a arquitetura d sftware, respnsável pr suas próprias atividades de leitura e escrita. Obviamente, nesta abrdagem, a arquitetura trna-se cmpletamente dependente da tecnlgia de persistência e, se, pr exempl, a rganizaçã migra de um sistema de arquiv para um SGBD relacinal, u mesm de um SGBD relacinal para utr, essa migraçã impactaria tdas as classes a lng d sistema. Uma abrdagem mais elegante cnsiste em fazer cm que apenas uma parte da arquitetura de sftware fique ciente da tecnlgia de persistência adtada. Essa parte, a CGD, serve cm uma camada intermediária para as classes de bjets persistentes, tipicamente da CDP, estabelecend um prtcl para a persistência ds bjets. Via cnexões de mensagem, a CGD lê e escreve dads, estabelecend uma cmunicaçã entre a base de dads e s bjets d sistema. O preç a ser pag pr este tip de cultament de infrmaçã é desempenh: cada requisiçã para ler u escrever um bjet envlve nã apenas s cmands físics de leitura/gravaçã, mas também uma trca de dads (via parâmetrs de mensagem) entre a CGD e bjet n sistema (Yurdn, 1994). Nesta abrdagem, as perações de armazenament e recuperaçã de bjets nã sã clcadas nas classes da CDP, mas sim em uma u mais classes salvadras de bjets dentr da CGD. A abrdagem mais direta para esta camada de persistência cnsiste em prver uma classe smbra na CGD para cada classe persistente ns demais cmpnentes da arquitetura. Tal classe salvadra de bjets encapsula a funcinalidade necessária para se implementar a persistência ds bjets da classe crrespndente. Uma abrdagem mais elegante e cmplexa cnsiste em prver classes genéricas que estabelecem prtcls para cmunicaçã cm s meis de armazenament secundáris e utilizá-las para a persistência ds bjets das classes crrespndentes. [... Cnteúd referente a mair detalhament sbre a Persistência de Dads fi eliminad] Prjet de Objets N cntext d Prjet Orientad a Objets, devems desenvlver um prjet detalhad ds atributs, das assciações e das perações que cmpõem cada classe, e uma especificaçã das mensagens que cnectam as classes cm seus clabradres. Inicialmente, uma descriçã de prtcl para cada classe deve ser prvida, estabelecend cnjunt de mensagens da classe (sua interface) e uma descriçã da peraçã a ser executada quand um bjet da classe receber uma dessas mensagens. Neste mment, deve-se definir, prtant, que perações e atributs devem ser públics u privads à classe. A seguir, deve-se fazer

137 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 137 uma descriçã da implementaçã da classe, prvend detalhes interns necessáris para a implementaçã, mas nã necessáris para a cmunicaçã entre bjets. N que tange as atributs, esta descriçã deve cnter uma especificaçã das estruturas de dads privadas da classe, cm indicações de itens de dads e tips para s atributs. Deve-se definir, também, a navegabilidade das assciações. Esta decisã cnduzirá à definiçã de nvas variáveis na classe, bem cm d seu tip e estrutura de dads. Para as perações, deve-se definir s tips e estruturas de dads para as interfaces, bem cm uma especificaçã prcedural de cada peraçã (prjet algrítmic). N cas de perações cmplexas, é uma ba pçã mdularizá-las, criand sub-perações, estas privadas à classe. O prjet algrítmic de uma peraçã pde revelar a necessidade de variáveis lcais as métds u de variáveis glbais à classe para tratar detalhes interns. Critéris de Qualidade de Prjet OO Há váris prjets pssíveis que pdem implementar crretamente um cnjunt de requisits. Um bm prjet equilibra cust e benefíci de md a minimizar cust ttal d sistema a lng de seu temp de vida ttal. Cad e Yurdn prpõem alguns critéris baseads na bservaçã e estuds de cass reais de desenvlviment OO, entre eles (Cad et al., 1993): Acplament: diz respeit a grau de interdependência entre cmpnentes de sftware. O bjetiv é minimizar acplament, ist é, trnar s cmpnentes tã independentes quant pssível. N OOD, estams precupads principalmente cm acplament entre classes e entre subsistemas. A meta é minimizar númer de mensagens trcadas e a cmplexidade e vlume de infrmaçã nas mensagens. Cesã: define cm as atividades de diferentes cmpnentes de sftware estã relacinadas umas cm as utras. Vale a pena ressaltar que cesã e acplament sã interdependentes e, prtant, uma ba cesã, geralmente, cnduz a um pequen acplament. N OOD, três níveis de cesã devem ser verificads: Cesã de métds individuais: um métd deve executar uma e smente uma funçã; Cesã de classes: atributs e serviçs encapsulads em uma classe devem ser altamente cess, ist é, devem estar estreitamente relacinads; e Cesã de uma hierarquia de classes: a cesã de uma hierarquia pde ser avaliada examinand-se até que extensã uma subclasse redefine u cancela atributs e métds herdads da superclasse. Clareza: um prjet deve ser passível de entendiment pr utrs prjetistas. Reutilizaçã: bns prjets devem ser fáceis de serem reutilizads. Efetiv Us da Herança: para sistemas médis, cm aprximadamente 100 classes, as hierarquias devem ter de 2 a 7 níveis de generalizaçã-especializaçã. Prjets cm us intensiv de herança múltipla devem ser evitads, pis sã mais difíceis de serem entendids e, cnsequentemente, de serem reutilizads e mantids. Prtcl de Mensagens Simples: prtcls de mensagem cmplexs sã uma indicaçã cmum de acplament excessiv entre classes. Assim, a passagem de muits parâmetrs deve ser evitada. Operações Simples: s métds que implementam as perações de uma classe devem ser bastante pequens. Se um métd envlve muit códig, é uma frte indicaçã de que as perações da classe fram pbremente mdularizadas. Habilidade de avaliar pr cenári : é imprtante que um prjet pssa ser avaliad a partir de um cenári particular esclhid. Revisres devem pder representar cmprtament de classes e bjets individuais, e assim, verificar cmprtament ds bjets nas circunstâncias desejadas.

138 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 138 Revisã d Dcument de Prjet Assim cm s demais dcuments, dcument de prjet deve ser revisad. Os seguintes aspects devem ser bservads: Aderência a padrões de dcument de prjet; Aderência a padrões de nmenclatura, incluind nmes de classes, atributs, perações, mensagens, etc; Cerência cm s mdels de análise e de especificaçã de requisits. D pnt de vista de cerência entre mdels, s seguintes aspects devem ser bservads: As classes da cmpnente d dmíni d prblema devem ser necessárias e suficientes para cumprir as respnsabilidades apntadas pels cass de us d dcument de especificaçã de requisits, agra já cm uma perspectiva de implementaçã. As classes da cmpnente de interaçã humana devem ser necessárias e suficientes para permitir acess e a realizaçã de tds s cass de us d dcument de especificaçã de requisits e seus cenáris. As classes da cmpnente de gerência de tarefas devem cntrlar tds s cass de us dcumentads na especificaçã de requisits e seus cenáris; As classes da gerência de dads devem ser necessárias e suficientes para tratar d armazenament e recuperaçã de bjets de tdas as classes persistentes d sistema (tipicamente, as classes da cmpnente d dmíni d prblema); Alterações nã decrrentes da tecnlgia, mas da detecçã de um err de especificaçã de requisits u de análise, devem ser atualizadas ns crrespndentes mdels de especificaçã de requisits u análise. 5.9 DESIGN PATTERNS (PADRÕES DE PROJETO) Origem: Prjet de Sistemas, Ntas de Aula. prf. Ricard Falb, UFES, Departament de Infrmática. Prjetar sftware é uma tarefa difícil. A mairia ds prjetistas é capaz de cmpreender cnceits cm classes, bjets, interfaces e herança. O desafi reside em aplicá-ls para cnstruir sftware flexível e reutilizável. Prjetistas nvats tendem a se perder cm as muitas pções dispníveis e a recrrer a técnicas nã rientadas a bjets cm as quais têm certa familiaridade. Prjetistas experientes, pr sua vez, tendem a fazer bns prjets. Eles sabem que nã se deve reslver td e qualquer prblema partind de princípis básics (classes, bjets, herança, relacinaments, agregaçã,...). A cntrári, deve-se buscar reutilizar sluções que funcinaram n passad. Esta é a mtivaçã para estud de padrões de prjet, u design patterns. Assim, um padrã é um par nmead prblema/sluçã, que pde ser utilizad em nvs cntexts, cm rientações sbre cm utilizá-l em nvas situações [Larman00]. O bjetiv de um design pattern é registrar uma experiência n prjet de sftware OO, na frma de um padrã passível de ser efetivamente utilizad pr prjetistas. Cada padrã sistematicamente nmeia, explica e avalia um imprtante prjet que crre repetidamente em sistemas OO (Gamma et al., 1995). Um prjetista familiarizad cm padrões de prjet pde aplicá-ls diretamente a prblemas de prjet sem ter que redescbrir abstrações e s bjets que as capturam. Uma vez que um padrã é aplicad, muitas decisões de prjet decrrem autmaticamente. Em geral, um padrã tem quatr elements essenciais: Nme: identificaçã de uma u duas palavras, que se pssa utilizar para descrever prblema de prjet, suas sluções e cnsequências. Prblema: descreve quand aplicar padrã. Explica prblema de prjet e seu cntext.

139 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 139 Sluçã: descreve s elements que cmpõem prjet, seus relacinaments, respnsabilidades e clabrações. Nã descreve um particular prjet cncret u implementaçã. Um padrã prvê uma descriçã abstrata de um prblema de prjet e cm uma rganizaçã geral de classes e bjets reslve este prblema. Cnsequências: sã s resultads e s cmprmetiments feits a se aplicar padrã, tais cm, biblitecas de classes necessárias, que prblemas acarreta, etc. O Catálg prpst pr (Gamma et al., 1995) Um ds principais catálgs de padrões OO publicads até mment é apresentad em (Gamma et al., 1995). A descriçã ds padrões neste catálg é mais detalhada e cnsiste de: Nme: nme dad a padrã neste catálg. Classificaçã: é feita segund dis critéris: prpósit e escp. O prpósit reflete que padrã faz, ist é, sua funcinalidade. Segund este critéri, um padrã pde ser: criativ, diz respeit a prcess de criaçã de bjets; estrutural, lida cm a cmpsiçã de classes u bjets; u cmprtamental, caracteriza s meis pels quais classes u bjets interagem e distribuem respnsabilidades. O escp, pr sua vez, especifica se padrã está centrad em classes (e neste cas, faz intens us de herança) u em bjets (e, prtant, mais apiad em assciações). Intençã (Prpósit): descreve sucintamente que faz padrã, seu prpósit e prblema endereçad. Também cnhecid cm: apresenta utrs nmes pels quais padrã é cnhecid (se huver). Mtivaçã: apresenta um cenári que ilustra prblema endereçad pel padrã e cm a estrutura prpsta pel padrã reslve este prblema. Aplicabilidade: trata de situações nas quais padrã pde ser aplicad e cm recnhecer essas situações. Estrutura: apresenta mdel de classes d padrã e, pcinalmente, diagramas de interaçã para ilustrar sequências de requisições e clabrações entre bjets. Participantes: frnece uma descriçã das classes e/u bjets que participam d padrã e suas respnsabilidades. Clabrações: descreve cm s participantes clabram para realizar suas respnsabilidades. Cnsequências: trata ds cmprmetiments e resultads quand se aplica padrã, tant psitivs cm negativs. Implementaçã: discute armadilhas e sugestões na implementaçã d padrã, bem cm técnicas e questões específicas de linguagem. Códig-Exempl: apresenta fragments de códig em C++ u Smalltalk que ilustram cm padrã pde ser implementad. Uss cnhecids: apresenta exempls de us d padrã encntrads em sistemas reais. Padrões relacinads: faz referência a utrs padrões prximamente relacinads cm padrã em questã, discutind diferenças. Relacina, também, utrs padrões que devem ser utilizads juntamente cm este. Tend em vista a classificaçã prpsta pr (Gamma et al., 1995), é pssível apntar s bjetivs gerais de cada grup de padrões. Quant a prpósit, s seguintes bjetivs sã válids: Padrã Criativ: abstrai prcess de instanciaçã (criaçã) de bjets, ajudand a trnar um sistema independente de cm seus bjets sã criads, cmpsts e representads.

140 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 140 Padrã Criativ de Classe: utiliza herança para variar a classe instanciada, adiand alguma parte da criaçã de bjets para subclasses. Padrã Criativ de Objet: delega a instanciaçã de um bjet para utr bjet u adia alguma parte da criaçã de um bjet para utr bjet. Padrã Estrutural: diz respeit a cm classes e bjets sã cmpsts para frmar estruturas maires. Padrã Estrutural de Classe: utiliza herança para cmpr classes. Padrã Estrutural de Objet: descreve meis de cmpr bjets a partir de utrs bjets, visand bter nva funcinalidade. A flexibilidade adicinal da cmpsiçã de bjets advém da habilidade de alterar uma cmpsiçã em temp de execuçã, que é impssível cm a cmpsiçã estática de classes. Padrã Cmprtamental: diz respeit a algritms e a atribuiçã de respnsabilidades entre bjets. Padrã Cmprtamental de Classe: utiliza herança para distribuir cmprtament entre classes, u seja, para descrever algritms e fluxs de cntrle. Padrã Cmprtamental de Objet: utiliza cmpsiçã de bjets para distribuir cmprtament. Descreve cm um grup de bjets cpera para realizar uma tarefa que nenhum bjet pderia realizar szinh. A tabela 5.1 apresenta catálg de padrões prpst pr (Gamma et al., 1995). Na sequência, é apresentada uma breve descriçã de cada um ds padrões. Padrões de Classe Métd-Fábrica: define uma interface para a criaçã de bjets, mas deixa que uma classe adie a instanciaçã para suas subclasses.

141 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 141 Adaptadr: cnverte a interface de uma classe em utra interface, permitind que classes trabalhem em cnjunt, quand ist nã seria pssível pr causa da incmpatibilidade de interfaces. Métd Mdel: define esquelet de um algritm em uma peraçã, adiand alguns de seus passs para as subclasses, permitind que as subclasses redefinam certs passs d algritm sem alterar sua estrutura. Interpretadr: Dada uma linguagem, define uma representaçã para sua gramática, junt cm um interpretadr que utiliza essa representaçã para interpretar sentenças na linguagem. Padrões de Objets Cnstrutr: separa a cnstruçã de um bjet cmplex de sua representaçã de md que mesm prcess de cnstruçã pde criar diferentes representações. Fábrica Abstrata: prvê uma interface para a criaçã de famílias de bjets relacinads u dependentes, sem especificar suas classes cncretas. Prtótip: especifica s tips de bjets que pdem ser criads a partir de uma instância prttípica e cria nvs bjets cpiand este prtótip. Singular: garante que uma classe pssui uma única instância e prvê um pnteir glbal para acessá-la. Cmpst: cmpõe bjets em estruturas de árvre para representar hierarquias td-parte, permitind que clientes tratem bjets individuais e cmpsts unifrmemente. Decradr: anexa respnsabilidades adicinais a um bjet dinamicamente, permitind estender sua funcinalidade. Fachada: prvê uma interface unificada para um cnjunt de interfaces em um subsistema. Define uma interface de nível mais alt para subsistema, trnand- mais fácil de ser usad. Pes-Msca: utiliza cmpartilhament para suprtar eficientemente um grande númer de bjets de granularidade muit fina. Pnte: desacpla uma abstraçã de sua implementaçã, de md que ambas pssam variar independentemente. Prcuradr: prvê um substitut/prcuradr (prxy) que tem autrizaçã para cntrlar acess a um bjet. Cadeia de Respnsabilidades: evita acplament entre bjet emissr de uma mensagem e receptr, dand chance para mais de um bjet tratar a slicitaçã. Encadeia s bjets receptres e passa a mensagem adiante na cadeia até que um bjet a trate. Cmand: encapsula uma requisiçã cm um bjet, permitind, assim, parametrizar clientes cm diferentes requisições e desfazer perações (cmand und). Iteradr: prvê um mei de acessar sequencialmente s elements de um bjet agregad sem expr sua representaçã básica. Mediadr: define um bjet que encapsula cm um cnjunt de bjets interage. Memrial: sem vilar encapsulament, captura e externaliza estad intern de um bjet de md que se pssa psterirmente restaurar bjet para este estad. Observadr: define uma dependência um-para-muits entre bjets de md que quand um bjet muda de estad, tds s seus dependentes sã ntificads e atualizads autmaticamente. Estad: permite que um bjet altere seu cmprtament quand seu estad intern muda, fazend parecer que bjet mudu de classe.

142 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 142 Estratégia: define uma família de algritms, encapsula cada um deles e s trna intercambiáveis. Deste md, algritm varia independentemente ds clientes que utilizam. Visitadr: representa uma peraçã a ser executada sbre s elements de uma estrutura de um bjet. Permite definir uma nva peraçã sem alterar as classes ds elements sbre as quais ele pera. Gamma et al. (1995) sugerem que, para se utilizar um padrã d catálg, s seguintes passs devem ser seguids: 1. Leia padrã uma vez para bter uma visã geral, cncentrand a atençã nas seções de Aplicabilidade e Cnsequências para garantir que este é padrã cert para seu prblema. 2. Vlte e estude as seções de Estrutura, Participantes e Clabrações. Tenha a certeza de que cmpreendeu as classes e bjets n padrã e cm se relacinam entre si. 3. Olhe a seçã Códig de Exempl para ver um exempl cncret d padrã em códig. Ist irá ajudá-l a aprender a implementar padrã. 4. Esclha nmes para s participantes (classes e/u bjets) d padrã que sejam significativs n cntext da aplicaçã. Os nmes em um padrã de prjet sã geralmente muit abstrats para aparecerem diretamente em uma aplicaçã. Cntud, é útil incrprar nme d participante d padrã de prjet a seu nme na aplicaçã, de md a trnar padrã mais explícit na implementaçã. 5. Defina as classes. 6. Defina nmes específics da aplicaçã para as perações n padrã. 7. Implemente as perações para realizar as respnsabilidades e clabrações d padrã. Padrões de prjet nã devem ser aplicads indiscriminadamente. Frequentemente, eles alcançam flexibilidade e variabilidade através da intrduçã de níveis adicinais de indireçã que pdem cmplicar um prjet e/u resultar em queda de desempenh. Um padrã de prjet só deve ser aplicad quand a flexibilidade que ele prprcina fr realmente necessária. A seçã de Cnsequências é muit útil para a avaliaçã ds benefícis e brigações de um padrã. Padrões de prjet sã bastante úteis para a criaçã de prjets rbusts, apts a suprtar determinadas mudanças, garantind que sistema pde ser alterad de certas maneiras específicas. Cada padrã permite que algum aspect da estrutura d sistema varie de frma independente de utrs aspects, trnand sistema mais rbust para um particular tip de alteraçã. A seguir, sã parcialmente apresentads alguns ds padrões de prjet prpsts em (Gamma et al., 1995) FÁBRICA ABSTRATA Classificaçã: Padrã Criativ de Objet. Prpósit: Prver uma interface para criar famílias de bjets relacinads u dependentes, sem especificar suas classes cncretas. Também cnhecid cm: Kit. Mtivaçã: Tlkit de Interface Gráfica cm Usuári, suprtand diferentes padrões de apresentaçã (Mtif, Presentatin Manager,...). Cada padrã de apresentaçã define diferentes cmprtament e aparência para bjets de interface, tais cm janelas, btões, barras de scrll, etc. Para ser prtável a lng de diferentes padrões de apresentaçã, uma aplicaçã nã pde se cmprmeter cm um padrã específic.

143 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 143 Aplicabilidade: Estrutura: Sistema deve ser independente de cm seus prduts sã criads, cmpsts e representads. Sistema deve ser cnfigurad cm uma dentre várias famílias de prduts. Uma família de prduts relacinads fi prjetada para ser usada em cnjunt e esta restriçã tem de ser garantida. Participantes: Fábrica Abstrata: declara uma interface para perações que criam bjets-prdut abstrats; Fábrica Cncreta: implementa as perações para criar bjets-prdut cncrets; Prdut Abstrat: declara uma interface para um tip de bjet prdut. Prdut Cncret: implementa a interface abstrata de Prdut Abstrat e define um bjet-prdut a ser criad pela Fábrica Cncreta crrespndente. Cliente: utiliza apenas as interfaces declaradas pr Fábrica Abstrata e Prdut Abstrat. Clabrações: Fábrica Abstrata adia a criaçã de bjets-prdut para suas subclasses Fábricas Cncretas. Cnsequências: Isla classes cncretas: uma vez que uma fábrica encapsula a respnsabilidade e prcess de criaçã de bjets-prdut, ela isla clientes das classes de implementaçã. Fica mais fácil a trca de uma família de prduts, bastand trcar a fábrica cncreta usada pela aplicaçã. Prmve cnsistência entre prduts. Quand bjets-prdut em uma família sã prjetads para trabalhar junts, é imprtante que uma aplicaçã utilize apenas bjets desta família.

144 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 144 O suprte a nvs tips de prduts é dificultad, já que a interface da Fábrica Abstrata fixa cnjunt de prduts que pdem ser criads. Para suprtar nvs tips de prduts, é necessári alterar a interface da fábrica, que envlve alterações na Fábrica Abstrata e em tdas as suas subclasses MÉTODO MODELO Classificaçã: Padrã Cmprtamental de Classe. Prpósit: Definir esquelet de um algritm em uma peraçã, adiand alguns passs para as subclasses. Aplicabilidade: Para implementar partes invariantes de um algritm apenas uma vez e deixar a carg das subclasses a implementaçã d cmprtament variável. Estrutura: Participantes: Classe Abstrata: implementa um métd mdel, definind esquelet de um algritm e define perações primitivas abstratas que as subclasses cncretas têm de definir para implementar s passs d algritm; Classe Cncreta: implementa as perações primitivas para realizar passs d algritm que sã específics da subclasse. Clabrações: A Classe Cncreta cnta cm a Classe Abstrata que implementa s passs invariantes d algritm.

145 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 145 Padrões Relacinads: Métd Fábrica: métds-fábrica nrmalmente sã chamads pr métds-mdel; Estratégia: enquant s métds-mdel utilizam herança para variar partes de um algritm, as estratégias usam delegaçã para variar algritm inteir PROCURADOR Classificaçã: Padrã Estrutural de Objet Prpósit: prvê um substitut/prcuradr que tem autrizaçã para cntrlar acess a bjet. Também cnhecid cm: Substitut, Prxy. Mtivaçã: Uma razã para se cntrlar acess a um bjet é tentar adiar alt cust de criaçã e inicializaçã deste bjet até mment em que ele fr ser realmente utilizad. Cnsidere um editr de text que pde embutir bjets gráfics em um dcument. Alguns desses bjets, cm figuras cmplexas, pdem ter um alt cust de criaçã. Cntud, a abertura de um dcument deve ser rápida. Assim, é desejável evitar a criaçã de tds esses bjets n mment em que dcument é abert, até prque muits deles nã estarã visíveis a mesm temp. Esta restriçã sugere a criaçã ds bjets cmplexs sb demanda, ist é, bjet só será criad n mment em que sua imagem se trnar visível. Mas que clcar n dcument n lugar da imagem? E cm escnder essa abrdagem sem cmplicar a implementaçã d editr? A sluçã cnsiste em criar um utr bjet, prcuradr (prxy) da imagem, que atuará cm substitut para a imagem real. Este prcuradr agirá exatamente cm a imagem e cuidará de sua instanciaçã quand a mesma fr requerida. O prcuradr da imagem criará a imagem real smente quand editr de text requisitar a ele que exiba a imagem, através da peraçã desenhar(). A partir daí, prcuradr passará adiante as requisições subsequentes diretamente para a imagem, cm ilustra diagrama de sequência abaix. Aplicabilidade: O padrã Prcuradr é aplicável sempre que huver necessidade de uma referência mais versátil u sfisticada d que um simples pnteir. A seguir sã listadas algumas situações nas quais este padrã é aplicável: Um Prcuradr Remt prvê uma representaçã lcal para um bjet que se encntra em um utr espaç de endereçament. Um Prcuradr Virtual cria bjets cmplexs sb demanda, cm n cas d exempl da mtivaçã.

146 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 146 Estrutura: Um Prcuradr de Prteçã cntrla acess a bjet riginal. Este tip de prcuradr é amplamente utilizad quand há diferentes direits de acess a bjet riginal. Neste cas, prcuradr serve cm uma espécie de filtr. Um Prcuradr de Referência Inteligente é uma substituiçã para um pnteir simples, que realiza perações adicinais quand bjet é acessad. Ist pde ser útil em muitas situações, tais cm: Cntar númer de referências a bjet real, de frma tal que ele pssa ser liberad autmaticamente quand nã huver mais referências a ele; Carregar um bjet persistente para a memória quand ele fr referenciad pela primeira vez; Verificar se bjet real nã está blquead antes de permitir um acess a ele, garantind que nenhum utr bjet pderá alterá-l. Participantes: Assunt: define uma interface cmum para ObjetReal e para Prcuradr, de md que prcuradr pssa ser usad n lugar d bjet real; Prcuradr: representa um substitut para bjet real. Para tal, mantém uma referência a bjet real, que permite acessar este bjet. Sua interface deve ser idêntica à d bjet real, de md que pssa ser pr ele substituíd. Além diss, cntrla acess a bjet real e pde ser respnsável pela criaçã e exclusã d mesm. Outras respnsabilidades pdem lhe ser atribuídas em funçã d tip d prcuradr; ObjetReal: define bjet real que prcuradr representa. Clabrações: O prcuradr envia requisições para bjet real, quand fr aprpriad, dependend d tip de Prcuradr. Cnsequências: O padrã Prcuradr intrduz um nível de indireçã quand se acessa bjet. Esta indireçã adicinal tem muits uss, dependend d tip de prcuradr. Um Prcuradr Remt, pr exempl, pde escnder fat de um bjet residir em um espaç de endereçament diferente. Um Prcuradr Virtual pde realizar timizações, cm criar um bjet sb demanda. Prcuradres de Prteçã e de Referência Inteligente, pr sua vez, permitem tarefas adicinais de gerenciament quand um bjet é acessad.

147 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 147 Padrões Relacinads: Adaptadr: um adaptadr prvê uma interface diferente para bjet que ele adapta. O prcuradr prvê a mesma interface. Decradr: Um decradr adicina respnsabilidades a um bjet, enquant prcuradr cntrla acess a bjet OBSERVADOR Classificaçã: Padrã Cmprtamental de Objet Prpósit: define uma dependência um-para-muits entre bjets de md que quand um bjet muda de estad, tds s seus dependentes sã ntificads e atualizads autmaticamente. Também cnhecid cm: Dependentes. Mtivaçã: É uma ba pçã para ferramentas de interfaces gráficas cm usuári separar aspects de apresentaçã ds respectivs dads da aplicaçã. As classes ds cmpnentes de dmíni d prblema e de interface cm usuári pdem ser reutilizadas independentemente, assim cm pdem trabalhar juntas. Pr exempl, s mesms dads estatístics pdem ser apresentads em frmat de gráfic de barras u planilha, usand apresentações diferentes. O gráfic de barras e a planilha devem ser independentes, de md a permitir reus. Cntud, eles têm de se cmprtar cnsistentemente, ist é, quand um usuári altera a infrmaçã na planilha, gráfic de barras reflete a trca imediatamente e vice-versa.

148 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 148 Este cmprtament implica que a planilha e gráfic de barras sã dependentes d mesm bjet de dads e, prtant, devem ser ntificads quand crre alguma mudança n estad desse bjet. O padrã Observadr descreve cm se estabelecem estes relacinaments. Os bjets principais deste padrã sã Sujeit e Observadr. O sujeit, n exempl bjet X, pde ter qualquer númer de bservadres, n cas a planilha e gráfic de barras. Tds s bservadres sã ntificads sempre que crre uma mudança n estad d sujeit. Em respsta, cada bservadr irá cnsultar sujeit para sincrnizar seu estad cm estad d sujeit. Aplicabilidade: O padrã Prcuradr é aplicável em qualquer uma das seguintes situações: Estrutura: Quand uma abstraçã pssui dis aspects, um dependente d utr. Encapsular esses aspects em bjets separads permite variá-ls e reutilizá-ls independentemente. Quand uma alteraçã em um bjet requer alterações em utrs e nã se sabe quants bjets precisam ser alterads. Quand um bjet deveria ser capaz de ntificar utrs bjets sem fazer nenhuma supsiçã sbre cm sã esses bjets, u seja, nã se quer esses bjets frtemente acplads.

149 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 149 Participantes: Sujeit: cnhece seus bservadres e prvê uma interface para adicinar e remver bjets bservadres. Qualquer númer de bservadres pde bservar um sujeit. Observadr: define uma interface de atualizaçã para s bjets que devem ser ntificads das mudanças n sujeit. SujeitCncret: armazena estad de interesse para s bservadres cncrets e envia ntificações para eles quand seu estad é alterad. ObservadrCncret: mantém uma referência para um bjet SujeitCncret, armazena estad que deve ficar cnsistente cm estad d sujeit e implementa a interface de atualizaçã d Observadr, de md a manter seu estad cnsistente cm d sujeit. Clabrações: O sujeit cncret ntifica seus bservadres sempre que crre uma alteraçã que pde trnar estad de seus bservadres incnsistente cm seu estad. Após ser infrmad de uma mudança n sujeit cncret, um bjetobservadrcncret pde cnsultar sujeit, usand esta infrmaçã para recnciliar seu estad cm estad d sujeit. Cnsequências: O padrã Observadr permite variar sujeits e bservadres independentemente. Deste md é pssível reutilizar sujeits sem reutilizar bservadres e vice-versa. Iss permite adicinar bservadres sem mdificar sujeit u utrs bservadres. Outrs benefícis e brigações desse padrã incluem: Acplament abstrat entre Sujeit e Observadr: Tud que um sujeit sabe é que ele pssui uma lista de bservadres, tds em cnfrmidade cm a interface simples da classe abstrata Observadr. O sujeit nã cnhece a classe cncreta de nenhum bservadr. Assim, acplament entre sujeits e bservadres é abstrat e mínim. Suprte para cmunicaçã bradcast: A cntrári de uma ntificaçã individual, a ntificaçã que um sujeit envia nã precisa especificar seus receptres. A ntificaçã é enviada autmaticamente para tds s bjets interessads. Assim, a respnsabilidade de um sujeit é limitada apenas à ntificaçã de seus

150 CEUNES/UFES Disciplina: Engenharia de Sftware Matéria: Design de Sftware Página: 150 bservadres. Iss ferece liberdade de adicinar e remver bservadres a qualquer mment. Atualizações inesperadas: Uma vez que s bservadres nã têm cnheciment da presença uns ds utrs, eles pdem nã ser cnscientes d cust de uma alteraçã n sujeit. Assim, uma peraçã aparentemente inócua sbre sujeit pde prvcar uma atualizaçã em cascata para seus bservadres e bjets dependentes. Além diss, critéris de dependência nã bem definids geralmente levam a atualizações falsas que pdem ser difíceis de prpagar DICAS DE LEITURA PRESSMAN, Rger. Engenharia de sftware Makrn Bks. Capítul 9 Engenharia de Prjet; Capítul 10 Prjet Arquitetural; Capítul 11 Prjet n nível de Cmpnentes; Capítul 12 Prjet de Interface cm Usuári; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 11 Prjet de arquitetura; Capítul 14 Prjet Orientad a Objets; Capítul 16 Prjet de interface cm usuári; Capítul 18 Reus de Sftware; SCHACH, Stephen R.. Engenharia de sftware: s paradigmas clássics e rientad a bjet McGrawHill. Capítul 8 Reusabilidade de prtabilidade; LARMAN, Graig. Utilizand UML e padrões Bkman; Ntas de Aula. Prjet de Sistemas. prf. Ricard Falb, UFES, Departament de Infrmática.

151 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: IMPLEMENTAÇÃO E TESTES Origem: Engenharia de Sftware, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. Engenharia de Sftware, livr, Rger Pressman, Cmentáris adicinais. Uma vez que sftware tenha seu design elabrad, é necessári cnstruir s cmpnentes que implementem esse prjet e testá-ls. 6.1 IMPLEMENTAÇÃO Implementaçã é prcess de cnverter prjet detalhad em códig. Quand iss é feit pr um únic indivídu, prcess é relativamente bem cmpreendid. Prém, hje em dia, a mairia ds prduts sã muit grandes para serem implementads pr apenas um prgramadr dentr das restrições de temp. Em vez diss, prdut é implementad pr uma equipe, cm tds trabalhand a mesm temp em diferentes cmpnentes d prdut. [Stephen R. Schach, 2007] Ainda que um prjet bem elabrad facilite sbremaneira a implementaçã, essa tarefa nã é necessariamente fácil. Muitas vezes, s prjetistas nã cnhecem em detalhes a platafrma de implementaçã e, prtant, nã sã capazes de (u nã desejam) chegar a um prjet algrítmic passível de implementaçã direta. Além diss, questões relacinadas à legibilidade, alterabilidade e reutilizaçã têm de ser levadas em cnta. Deve-se cnsiderar, ainda, que prgramadres, geralmente, trabalham em equipe, necessitand integrar, testar e alterar códig prduzid pr utrs. Assim, é muit imprtante que haja padrões rganizacinais para a fase de implementaçã. Esses padrões devem ser seguids pr tds s prgramadres e devem estabelecer, dentre utrs, padrões de nmeclatura, frmat de cabeçalhs de prgramas e frmat de cmentáris, recus e espaçament, de md que códig e a dcumentaçã a ele assciada sejam clars para quaisquer membrs da rganizaçã. Padrões para cabeçalh, pr exempl, pdem infrmar que códig (prgrama, módul u cmpnente) faz, quem escreveu, cm ele se encaixa n prjet geral d sistema, quand fi escrit e revisad, apis para teste, entrada e saída esperadas etc. Essas infrmações sã de grande valia para a integraçã, testes, manutençã e reutilizaçã [3]. Além ds cmentáris feits n cabeçalh ds prgramas, cmentáris adicinais a lng d códig sã também imprtantes, ajudand a cmpreender cm cmpnente é implementad. Pr fim, us de nmes significativs para variáveis, indicand sua utilizaçã e significad, é imprescindível, bem cm us adequad de recu e espaçament entre linhas de códig, que ajudam a visualizar a estrutura de cntrle d prgrama [3]. Além da dcumentaçã interna, escrita n própri códig, é imprtante que códig de um sistema pssua também uma dcumentaçã externa, incluind uma visã geral ds cmpnentes d sistema, grups de cmpnentes e da inter-relaçã entre eles [3]. Ainda que padrões sejam muit imprtantes, deve-se ressaltar que a crrespndência entre s cmpnentes d prjet e códig é fundamental, caracterizand-se cm a mais imprtante questã a ser tratada. O prjet é guia para a implementaçã, ainda que prgramadr deva ter certa flexibilidade para implementá-l cm códig [3]. Cm resultad de uma implementaçã bem-sucedida, as unidades de sftware devem ser cdificadas e critéris de verificaçã das mesmas devem ser definids.

152 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: TESTES Otimism é risc cupacinal da prgramaçã; teste é tratament. [Kent Beck] Nã seja relaxad a pnt de pensar que teste é uma rede de segurança que pegará tds s errs que crrem pr causa de práticas incnsistentes de engenharia de sftware. Nã pegará. Enfatize qualidade e detecçã de errs a lng de td prcess de sftware. [Rger Pressman, 2006] Uma vez implementad códig de um sftware, mesm deve ser testad para descbrir tants errs quant pssível, antes da entrega d prdut a seu cliente. Cnsiderand s cnceits definids pela Engenharia de Sftware é imprtante destacar dis terms que habitualmente sã tratads cm sinônims: ERROS e DEFEITOS. Um err é alguma falha encntrada em um artefat da engenharia de sftware, u em algum resultad a ser prduzid, que é encntrad ANTES d sftware ser entregue a cliente. Um defeit se refere a falhas encntradas DEPOIS d sftware ser entregue a cliente. O teste é um cnjunt de atividades que pdem ser planejadas antecipadamente e cnduzidas sistematicamente. Pr essa razã, um gabarit para teste de sftware um cnjunt de passs n qual pdems incluir técnicas de prjet de cass de teste e métds de teste específics deve ser definid para prcess de sftware O teste é uma atividade de verificaçã e validaçã d sftware e cnsiste na análise dinâmica d mesm, ist é, na execuçã d prdut de sftware cm bjetiv de verificar a presença de errs n prdut e aumentar a cnfiança de que mesm está crret [4]. Além da identificaçã e cnsequente crreçã de errs, s testes tem utrs benefícis: teste demnstra que sftware funcina de acrd cm a especificaçã (requisits e prjet), bem cm trata s requisits nãfuncinais que sã necessáris/desejads n prdut de sftware. Vale ressaltar que, mesm se um teste nã detectar defeits, iss nã quer dizer necessariamente que prdut é um prdut de ba qualidade. Muitas vezes, a atividade de teste empregada pde ter sid cnduzida sem planejament, sem critéris e sem uma sistemática bem definida, send, prtant, s testes de baixa qualidade [4]. Assim, bjetiv é prjetar testes que ptencialmente descubram diferentes classes de errs e fazêl cm uma quantidade mínima de esfrç [1]. Ainda que s testes nã pssam demnstrar a ausência de defeits, cm benefíci secundári, pdem indicar que as funções d sftware parecem estar funcinand de acrd cm especificad. A idéia básica ds testes é que s defeits pdem se manifestar pr mei de falhas bservadas durante a execuçã d sftware. Essas falhas pdem ser resultad de uma especificaçã errada u falta de requisit, de um requisit impssível de implementar cnsiderand hardware e sftware estabelecids, prjet pde cnter defeits u códig pde estar errad. Assim, uma falha é resultad de um u mais defeits [3]. Sã imprtantes princípis de testes a serem bservads [1, 3]: Teste cmplet nã é pssível, u seja, mesm para sistemas de tamanh mderad, pde ser impssível executar tdas as cmbinações de caminhs durante teste. Teste envlve váris estágis. Geralmente, primeir, cada módul é testad isladamente ds demais móduls d sistema (teste de unidade). À medida que s testes prgridem, fc se deslca para a integraçã ds móduls (teste de integraçã), até se chegar a sistema cm um td (teste de sistema). Teste deve ser cnduzid, preferencialmente, pr terceirs. Os testes cnduzids pr utras pessas que nã aquelas que prduziram códig têm mair prbabilidade de encntrar defeits. O desenvlvedr que prduziu códig pde estar muit envlvid cm ele para pder detectar defeits mais sutis.

153 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 153 Testes devem ser planejads antes de serem realizads. Um plan de testes deve ser utilizad para guiar tdas as atividades de teste e deve incluir bjetivs d teste, abrdand cada tip (unidade, integraçã e sistema), cm serã executads e quais critéris a serem utilizads para determinar quand teste está cmplet. Uma vez que s testes estã relacinads as requisits ds clientes e usuáris, planejament ds testes pde cmeçar tã lg a especificaçã de requisits tenha sid elabrada. À medida que prcess de desenvlviment avança (análise, design e implementaçã), nvs testes vã send planejads e incrprads a plan de testes. O prcess de teste envlve quatr atividades principais [3, 4]: Planejament de Testes: trata da definiçã das atividades de teste, das estimativas ds recurss necessáris para realizá-las, ds bjetivs, estratégias e técnicas de teste a serem adtadas e ds critéris para determinar quand uma atividade de teste está cmpleta. Prjet de Cass de Testes: é a atividade chave para um teste bem-sucedid, u seja, para se descbrir a mair quantidade de defeits cm menr esfrç pssível. Os cass de teste devem ser cuidadsamente prjetads e avaliads para tentar se bter um cnjunt de cass de teste que seja representativ e envlva as várias pssibilidades de exercíci das funções d sftware (cbertura ds testes). Existe uma grande quantidade de técnicas de teste para apiar s testadres a prjetar cass de teste, ferecend uma abrdagem sistemática para teste de sftware. Execuçã ds testes: cnsiste na execuçã ds cass de teste e registr de seus resultads. Avaliaçã ds resultads: detectadas falhas, s defeits deverã ser prcurads. Nã detectadas falhas, deve-se fazer uma avaliaçã final da qualidade ds cass de teste e definir pel encerrament u nã de uma atividade de teste. As atividades de teste nrmalmente requerem s seguintes artefats de entrada: Definiçã de Requisits; Especificaçã de Requisits; Especificaçã de Análise de Requisits; Especificaçã de Design; Códig-fnte ds prgramas / cmpnentes. E as mesmas atividades cstumam gerar s seguintes artefats de saída: Uma Especificaçã/Plan de Teste, que especifica s prcediments de teste que a equipe de testes deverá adtar, cntend a estratégia de teste a ser seguida, bem cm as técnicas de teste que deverã ser aplicadas. Os testes a serem cnduzids deverã ser detalhads através de um cnjunt de cass de teste, que cntém s pré-requisits, s prcediments a serem seguids, e s resultads esperads de cada teste realizad; Os resultads btids a lng da execuçã ds testes. Testabilidade Testabilidade de sftware é simplesmente quã fácil [um sftware] pde ser testad. As seguintes características levam a um sftware testável: Operabilidade. Quant melhr funcina, mais eficientemente pde ser testad ; Observabilidade. O que vcê vê é que vcê testa ; Cntrlabilidade. Quant melhr vcê pde cntrlar sftware, mais teste pde ser autmatizad e timizad ;

154 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 154 Decmpnibilidade. Cntrland escp d teste, pdems islar prblemas mais rapidamente e realizar retestagem mais racinalmente ; Simplicidade. Quant mens huver a testar, mais rapidamente pdems testá-l ; Estabilidade. Quant mens mdificações, mens interrupções n teste ; Cmpreensibilidade. Quant mais infrmações tems, mais racinalmente vams testar. Característica d teste. Atributs para um bm teste: Tem alta prbabilidade de encntrar um err; Nã é redundante; Deve ser de ba cepa ; Nã deve ser muit simples nem muit cmplex ESTRATÉGIAS DE TESTE Estratégias de teste sã relacinadas à cnduçã ds testes. Uma estratégia de teste de sftware integra métds de prjet de cass de teste em uma série bem planejada de passs, que resultam na cnstruçã bem-sucedida de sftware. A estratégia frnece um rteir que descreve s passs a serem cnduzids cm parte d teste, quand esses passs sã planejads e depis executads, e quant de esfrç, temp e recurss serã necessáris. Assim, qualquer estratégia de teste deve incrprar planejament de teste, prjet de cass de teste, execuçã de teste e a resultante cleta e avaliaçã de dads. Algumas características genéricas pdem ser identificadas, e sã independentes de qualquer estratégia adtada: Para realizar teste efetiv, uma equipe de sftware deve cnduzir revisões técnicas frmais. A fazer iss, muits errs serã eliminads antes d iníci d teste; O teste cmeça n nível de cmpnente e prssegue para fra, em direçã à integraçã de td sistema basead em cmputadr; Diferentes técnicas de testes sã adequadas em diferentes mments; O teste é cnduzid pel desenvlvedr d sftware e (para prjets grandes) um grup de teste independente. Uma estratégia de teste deve acmdar testes de baix nível, para verificar se um pequen segment de códig-fnte fi crretamente implementad, bem cm testes de alt nível, que validam as principais funções d sistema cm base ns requisits d cliente. Uma estratégia deve frnecer diretrizes para prfissinal e um cnjunt de referenciais para gerente. Cm s passs da estratégia de teste crrem quand a pressã d praz de entrega cmeça a crescer, prgress deve ser mensurável e s prblemas devem aparecer tã ced quant pssível Verificaçã x Validaçã O teste de sftware é um element de um aspect mais ampl, que é frequentemente referid cm verificaçã e validaçã. Verificaçã se refere a cnjunt de atividades que garante que sftware implementa crretamente uma funçã específica. (Estams cnstruind prdut crretamente?). Já Validaçã se refere a um

155 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 155 cnjunt de atividades diferente que garante que sftware cnstruíd crrespnde as requisits d cliente. (Estams cnstruind prdut cert?). Ambas abrangem um ampl cnjunt de atividades de qualidade, que inclui revisões técnicas frmais, auditria de qualidade e cnfiguraçã, mnitrament de desempenh, simulaçã, estud de viabilidade, revisã de dcumentaçã, revisã da base de dads, análise de algritms, teste de desenvlviment, teste de usabilidade, teste de qualificaçã e teste de instalaçã Organizaçã de Teste de Sftware Em cada prjet de sftware há um cnflit de interesses inerente que crre quand teste inicia. Cnflit de interesses: quem cnstruiu sftware tentará mstrar que prgrama funcina. O teste prcura identificar justamente que nã funcina! Algumas cncepções equivcadas, e que deve efetivamente crrer: O desenvlvedr nã deve realizar nenhum teste. Desenvlvedres devem realizar testes unitáris e pdem cnduzir testes de integraçã. Apenas depis de a arquitetura d sftware ser cmpletada, um grup independente de teste cmeça a ser envlvid; O sftware deve ser jgad pr cima d mur, para estranhs que vã testá-l impiedsamente. O papel d grup independente é remver s prblemas inerentes assciads cm deixar cnstrutr testar a cisa que ele cnstruiu. O engenheir e grup independente trabalham junts para garantir testes rigrss; Os testadres se envlvem cm prjet apenas quand s passs de teste estã para cmeçar. O grup independente é parte da equipe d prjet, estand envlvid desde a análise e prjet. Alguns tópics estratégics imprtantes na cnsideraçã da estratégia de teste a ser definida: Especifique s requisits d prdut de um md quantificável muit antes de teste cmeçar; Enuncie explicitamente s bjetivs d teste; Entenda s usuáris d sftware e desenvlva um perfil para cada categria de usuári; Desenvlva um plan de teste que enfatize teste de cicl rápid ; Cnstrua sftware rbust que é prjetad para testar a si própri; Use revisões técnicas frmais efetivas cm filtr antes d teste; Cnduza revisões técnicas frmais para avaliar a estratégia de teste e s cass de teste prpriamente dits; Desenvlva uma abrdagem de aperfeiçament cntínu para prcess de teste Fases de Teste O prjet efetiv de cass de teste é imprtante, mas nã suficiente para sucess da atividade de testes. A estratégia, ist é, a série planejada de realizaçã ds testes, é também crucial [1]. Basicamente, pdem ser cnsideradas as seguintes fases de teste:

156 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 156 Teste de Unidade: tem pr bjetiv testar a menr unidade d prjet (um cmpnente de sftware que nã pde ser subdividid), prcurand identificar errs de lógica e de implementaçã em cada módul separadamente. N paradigma estruturad, a menr unidade refere-se a um prcediment u funçã. N paradigma rientad a bjets pde-se cnsiderar uma classe u um métd; Teste de Integraçã: visa descbrir errs assciads às interfaces entre s móduls quand esses sã integrads para frmar a estrutura d prdut de sftware, fcand assim na arquitetura d sftware; Teste de Validaçã: tem pr bjetiv identificar errs de funções (requisits funcinais) e características de desempenh, entre utrs, (requisits nã-funcinais) que nã estejam de acrd cm as especificações; Teste de Sistema: testa sftware e s utrs elements d sistema d qual sftware faz parte. Tmand pr base essas fases, a atividade de teste pde ser estruturada de md que, em cada fase, diferentes tips de errs e aspects d sftware sejam cnsiderads [4]. Tipicamente, s primeirs testes fcalizam cmpnentes individuais e aplicam testes caixa-branca e caixa-preta para descbrir errs. Após s cmpnentes individuais terem sid testads, eles precisam ser integrads, até se bter sistema pr inteir. Na integraçã, fc é prjet e a arquitetura d sistema. Finalmente, uma série de testes de alt nível é executada quand sistema estiver peracinal, visand a descbrir errs ns requisits [1,3] Teste de Unidade O teste de unidade fcaliza esfrç de verificaçã na menr unidade de prjet d sftware cmpnente u módul de sftware. Enfca a lógica interna de prcessament e as estruturas de dads dentr ds limites de um cmpnente. Tips de testes: Testes de interface; Estrutura lógica de dads; Cndições-limites; Caminhs independentes; Caminhs de manipulaçã de errs.

157 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: / Ns testes de unidade e de integraçã, faz-se necessári cnstruir pequens cmpnentes para permitir testar s móduls individualmente e a integraçã incremental, s dits drivers e stubs. Um driver é um prgrama respnsável pela ativaçã e crdenaçã d teste de uma unidade. Ele é respnsável pr receber s dads de teste frnecids pel testadr, passar esses dads para a unidade/integraçã send testada, bter s resultads prduzids pr essa unidade/integraçã e apresentá-ls a testadr. Um stub é uma unidade que substitui, na hra d teste, uma utra unidade chamada pela unidade/integraçã que está send testada. Em geral, um stub simula cmprtament da unidade/integraçã chamada cm mínim de cmputaçã u manipulaçã de dads [4].

158 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: Teste de Integraçã O Teste de integraçã é uma técnica sistemática para cnstruir a arquitetura d sftware enquant, a mesm temp, cnduz testes para descbrir errs assciads às interfaces. É interessante a ideia de utilizar integraçã incremental a invés de integrar tds s cmpnentes de uma só vez. A abrdagem de integraçã de móduls pde ter impact na quantidade de drivers e stubs a ser cnstruída. Sejam as seguintes abrdagens: Integraçã ascendente u bttm-up: Nessa abrdagem, primeiramente, cada módul n nível inferir da hierarquia d sistema é testad individualmente. A seguir, sã testads s móduls que chamam esses móduls previamente testads. Esse prcediment é repetid até que tds s móduls tenham sid testads [3]. Neste cas, apenas drivers sã necessáris. Seja exempl da figura 7.1. Usand a abrdagem de integraçã ascendente, s móduls seriam testads da seguinte frma. Inicialmente, seriam testads s móduls d nível inferir (E, F e G). Para cada um desses testes, um driver teria de ser cnstruíd. Cncluíds esses testes, passaríams a nível imediatamente acima, testand seus móduls (B, C e D) cmbinads cm s móduls pr eles chamads. Neste cas, testams junts B, E e F bem cm C e G. Nvamente, três drivers seriam necessáris. Pr fim, testaríams tds s móduls junts. Integraçã descendente u tp-dwn: A abrdagem, neste cas, é precisamente cntrári da anterir. Inicialmente, nível superir (geralmente um módul de cntrle) é testad szinh. Em seguida, tds s móduls chamads pr este módul testad sã cmbinads e testads cm uma grande unidade. Essa abrdagem é repetida até que tds s móduls tenham sid incrprads [3]. Neste cas, apenas stubs sã necessáris. Tmand exempl da figura 7.1, teste iniciaria pel módul A e três stubs (para B, C e D) seriam necessáris. Na sequência seriam testads junts A, B, C e D, send necessáris stubs para E, F e G. Pr fim, sistema inteir seria testad. Teste de regressã é a reexecuçã de algum subcnjunt de testes que já fi cnduzid para garantir que as mdificações nã prpaguem efeits claterais indesejáveis. Esse subcnjunt cntém 3 diferentes classes de cass de teste: Uma amstra representativa de testes que vã exercitar tdas as funções d sftware; Testes adicinais que fcalizam funções d sftware, que serã prvavelmente afetadas pela mdificaçã; Testes que fcalizam s cmpnentes de sftware que fram mdificads. Teste fumaça é prjetad cm mecanism de marca-pass para prjets de praz crític, permitind à equipe avaliar seu prjet em bases frequentes. Abrange as seguintes atividades: Cmpnentes que fram traduzids para códig sã integrads em uma cnstruçã, que inclui tds s arquivs de dads, biblitecas, móduls reusáveis e cmpnentes submetids a engenharia, que sã necessáris para implementar uma u mais funções d prdut.

159 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 159 Uma série de testes é prjetada para expr errs que impeçam a cnstruçã de desempenhar adequadamente a sua funçã. O prpósit deve ser descbrir errs blqueadres que têm a mair prbabilidade de clcar prjet fra d crngrama. A cnstruçã é integrada cm utras cnstruções e prdut inteir passa pel teste fumaça diariamente. A abrdagem de integraçã pde ser descendente u ascendente. Alguns benefícis esperads d teste fumaça: 276 / O risc de integraçã é minimizad; A qualidade d prdut final é aperfeiçada; Diagnóstic e crreçã de errs sã simplificads; Prgress é fácil de avaliar. Muitas utras abrdagens, algumas usand as apresentadas anterirmente, pdem ser adtadas, tal cm a integraçã sanduíche [3], que cnsidera uma camada alv n mei da hierarquia e utiliza as abrdagens ascendente e descendente, respectivamente para as camadas lcalizadas abaix e acima da camada alv. Outra pssibilidade é testar individualmente cada módul e só depis de testads individualmente integrá-ls (teste big-band). Neste cas, tant drivers quant stubs têm de ser cnstruíds para cada módul, que leva a muit mais cdificaçã e prblemas em ptencial [3]. Módul Crític A medida que teste de integraçã é cnduzid, testadr deve identificar s móduls crítics. Um módul crític tem uma u mais das seguintes características: Abrda váris requisits d sftware; Tem um alt nível de cntrle (situa-se em um pnt relativamente alt na estrutura d prgrama); É cmplex u prpens a err; u Tem requisits de desempenh bem definids Teste de Validaçã Uma vez integrads tds s móduls d sftware, parte-se para s testes de validaçã, quand se busca bservar se sftware funcina cnfrme esperad pel cliente. A validaçã d sftware é cnseguida pr intermédi de uma série de testes que demnstram cnfrmidade cm s requisits. Tant plan quant prcediment sã prjetads para garantir que tds s requisits funcinais sejam satisfeits, tdas as características cmprtamentais sejam seguidas, tds s requisits de desempenh sejam alcançads, a dcumentaçã esteja crreta, usabilidade e utrs requisits nã-funcinais sejam satisfeits (cm cmpatibilidade, recuperaçã de err e manutenibilidade). Se sftware é desenvlvid cm um prdut a ser usad pr váris clientes, nã é prática realizar testes frmais de aceitaçã cm cada um. A mairia ds cnstrutres de prduts de sftware usa s prcesss denminads Teste Alfa e Teste Beta para descbrir errs que apenas usuári final parece ser capaz de descbrir. Teste Alfa é cnduzid na instalaçã d desenvlvedr cm s usuáris finais. O sftware é usad em um ambiente natural cm desenvlvedr lhand sbre s mbrs ds usuáris típics e registrand errs e prblemas de us. Testes alfa sã cnduzids em um ambiente cntrlad. Teste Beta é cnduzid nas instalações ds usuáris finais. Diferente d teste alfa, desenvlvedr geralmente nã está presente. Cnsequentemente, teste beta é uma aplicaçã a viv d sftware em um ambiente que nã pde ser cntrlad pel usuári final. O cliente registra tds s

160 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 160 prblemas que sã encntrads durante teste beta e s relata a desenvlvedr em intervals regulares Teste de Sistema Teste de Sistema sã uma série de testes cuja finalidade principal é exercitar pr cmplet Sistema de Infrmaçã Basead em Cmputadr. Os tips de teste de sistema mais cmumente realizads sã s seguintes: Teste de Recuperaçã é um teste de sistema que frça sftware a falhar de diverss mds e verifica se a recuperaçã é adequadamente realizada. Se a recuperaçã é autmática, a reinicializaçã, s mecanisms de verificaçã, a recuperaçã ds dads e reiníci sã avaliads quant à crreçã. Se a recuperaçã requer intervençã humana, temp médi para repar é avaliad para determinar se está dentr de limites aceitáveis;279 / Teste de Segurança verifica se s mecanisms de prteçã incrprads a um sistema vã de fat prtegê-l de invasã imprópria; Teste de Estresse executa um sistema de tal frma que demanda recurss em quantidade, frequência u vlume anrmais; Teste de Desempenh é prjetad para testar desempenh d sftware durante a execuçã, para sistemas em temp real e embutids A ARTE DA DEPURAÇÃO A depuraçã crre cm cnseqüência de teste bem-sucedid. Ist é, quand um cas de teste descbre um err, a depuraçã é a açã que resulta na reparaçã d err. Apesar de a depuraçã pder e dever ser um prcess rdenad, é ainda excessivamente uma arte. Um engenheir de sftware, avaliand s resultads de um teste, é frequentemente cnfrntad cm uma indicaçã sintmática de um prblema d sftware. Ist é, a manifestaçã externa d err e a causa interna d err pdem nã ter relaçã óbvia uma cm a utra. O prcess mental mal cmpreendid que cnecta um sintma cm uma causa é a depuraçã. A depuraçã nã é teste, mas sempre crre cm cnsequência d teste. O prcess de depuraçã pde ser bservad na figura abaix.

161 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: 161 Pr que a depuraçã é tã difícil? O sintma e a causa pdem ser gegraficamente remts. Estruturas de prgramas altamente acpladas agravam essa situaçã; O sintma pde desaparecer (temprariamente) quand utr err é crrigid; O sintma pde, na verdade, ser causad pr nã-errs (pr exempl, imprecisões de arredndament); O sintma pde ser causad pr err human (que nã é facilmente rastread); O sintma pde ser resultad de prblemas de temp, em vez de prblemas de prcessament; Pde ser difícil reprduzir precisamente cndições de entrada (pr exempl, uma aplicaçã em temp real na qual a rdem das entradas é indeterminada); O sintma pde ser intermitente. Iss é particularmente cmum em sistemas embutids, que acplam hardware e sftware inextricavelmente; O sintma pde ser devid a causas que estã distribuídas entre várias tarefas send executadas em diferentes prcessadres. Cnsiderações psiclógicas A depuraçã é uma das partes mais frustrantes da prgramaçã. Tem elements de sluçã de prblemas u de quebra-cabeças, cmbinads cm recnheciment desagradável de que vcê cmeteu um err. A elevada ansiedade e a má vntade em aceitar a pssibilidade de errs aumentam a dificuldade da tarefa. Felizmente, há um suspir de alívi e uma diminuiçã da tensã quand defeit é finalmente... crrigid. [Shneiderman, 1980] Abrdagens de Depuraçã Frça bruta A mais cmum. Sã feitas listagens de memória, sã invcads rastreadres de execuçã e prgrama é carregad cm cmands de saída. Tud em busca de uma pista d err; Rastreament Partind d lcal em que sintma fi descbert, códig-fnte é rastread até que lugar da causa seja encntrad; Eliminaçã de causa Os dads relacinads a err sã rganizads para islar causas em ptencial, que sã depis testadas e sucessivamente eliminadas, até que a verdadeira causa seja encntrada e cnsiga-se islar err. Crreçã d Err Uma vez encntrad um err, ele precisa ser crrigid. Mas deve-se estar atent a fat de que a crreçã de um err pde intrduzir n sistema nvs errs. Três perguntas simples que devem ser feitas antes da crreçã de um err: A causa d err está reprduzida em utra parte d prgrama? Qual próxim err que pde ser intrduzid pel cnsert que estu prestes a fazer? O que pderíams ter feit para prevenir a crrência deste err?

162 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: TÉCNICAS DE TESTE Técnicas de teste sã relacinadas a Prjet de Testes. Para testar um módul, é necessári definir um cas de teste, executar módul cm s dads de entrada definids pr esse cas de teste e analisar a saída. Um teste é um cnjunt limitad de cass de teste, definid a partir d bjetiv d teste [3]. Diversas técnicas de teste têm sid prpstas visand apiar prjet de cass de teste. Essas técnicas pdem ser classificadas, segund a rigem das infrmações utilizadas para estabelecer s bjetivs de teste, em, dentre utras categrias, técnicas funcinal, estrutural u baseadas em máquinas de estad [4]. Os testes funcinais u caixa-preta utilizam as especificações (de requisits, análise e prjet) para definir s bjetivs d teste e, prtant, para guiar prjet de cass de teste. O cnheciment sbre uma determinada implementaçã nã é usad [4]. Assim, s testes sã cnduzids na interface d sftware. Os testes caixa-preta sã empregads para demnstrar que as funções d sftware estã peracinais, que a entrada é adequadamente aceita e a saída é crretamente prduzida e que a integridade da infrmaçã externa (uma base de dads, pr exempl) é mantida [1]. Os testes estruturais u caixa-branca estabelecem s bjetivs d teste cm base em uma determinada implementaçã, verificand detalhes d códig. Caminhs lógics interns sã testads, definind cass de testes que exercitem cnjunts específics de cndições u laçs [1]. Os testes baseads em máquinas de estad sã prjetads utilizand cnheciment subjacente à estrutura de uma máquina de estads para determinar s bjetivs d teste [4]. É imprtante ressaltar que técnicas de teste devem ser utilizadas de frma cmplementar, já que elas têm prpósits distints e detectam categrias de errs distintas [4]. À primeira vista, pde parecer que realizand testes caixa branca rigrss pderíams chegar a prgramas crrets. Cntud, cnfrme anterirmente mencinad, iss nã é prátic, uma vez que tdas as cmbinações pssíveis de caminhs e valres de variáveis teriam de ser exercitadas, que é impssível. Iss nã quer dizer, entretant, que s testes caixa-branca nã sã úteis. Testes caixabranca pdem ser usads, pr exempl, para garantir que tds s caminhs independentes (Um caminh independente é qualquer caminh a lng de um módul que intrduz pel mens um nv cmand de prcessament u cndiçã [1]) de um módul tenham sid exercitads pel mens uma vez [1]. Há diversas técnicas de testes caixa-branca, cada uma delas prcurand apiar prjet de cass de teste fcand em algum u váris aspects da implementaçã. Dentre elas, pdem ser citadas [1]: Testes de estrutura de cntrle: cm própri nme diz, enfcam as estruturas de cntrle de um módul, tais cm cmands, cndições e laçs. Teste de cndiçã é um tip de teste de estrutura de cntrle que exercita as cndições lógicas cntidas em um módul. Um teste de flux de dads, pr sua vez, selecina caminhs de teste tmand pr base a lcalizaçã das definições e ds uss das variáveis ns móduls. Testes de cicl u laç fcalizam exclusivamente s laçs (lps). Teste de caminh básic: define uma medida de cmplexidade lógica de um módul e usa essa medida cm guia para definir um cnjunt básic de caminhs de execuçã. Assim cm há diversas técnicas de teste caixa-branca, mesm acntece em relaçã a teste caixa-preta. Dentre as diversas técnicas de teste caixa-preta, pdem ser citadas [1]: Particinament de equivalência: divide dmíni de entrada de um módul em classes de equivalência, a partir das quais cass de teste sã derivads. A meta é minimizar númer de cass de teste, ficand apenas cm um cas de teste para cada classe, uma vez que, a princípi, tds s elements de uma mesma classe devem se cmprtar de maneira equivalente. Análise de valr limite: a prática mstra que um grande númer de errs tende a crrer nas frnteiras d dmíni de entrada de um módul. Tend iss em mente, a análise de valr limite leva à seleçã de cass de teste que exercitem s valres limítrfes.

163 CEUNES - UFES Disciplina: Engenharia de Sftware Matéria: Implementaçã e Testes Página: DICAS DE LEITURA PRESSMAN, Rger. Engenharia de sftware Makrn Bks. Capítul 13 Estratégias de Teste de Sftware; Capítul 14 Técnicas de Teste de Sftware; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 22 Verificaçã e Validaçã; Capítul 23 Teste de Sftware; SCHACH, Stephen R.. Engenharia de sftware: s paradigmas clássics e rientad a bjet McGrawHill. Capítul 6 Testes; Capítul 14 - Implementaçã.

164 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: ENTREGA E MANUTENÇÃO DE SOFTWARE 7.1 ENTREGA Certifique-se de que seu cliente sabe que esperar antes de um increment de sftware ser entregue. Cas cntrári, vcê pde apstar que cliente vai esperar mais d que vcê entrega. [Rger Pressman, 2006] Origem: Engenharia de Sftware, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. Cmentáris própris. A entrega nã é meramente uma frmalidade. N mment em que sistema é instalad n lcal de peraçã e devidamente aceit, é necessári, ainda, ajudar s usuáris a entenderem e a se sentirem mais familiarizads cm sistema. Neste mment, duas questões sã cruciais para uma transferência bem-sucedida: treinament e dcumentaçã [1]. Além d própri planejament da entrada em peraçã d sistema. A peraçã d sistema é extremamente dependente de pessal cm cnheciment e qualificaçã. Prtant, é essencial que treinament de pessal seja realizad para que s usuáris e peradres pssam perar sistema adequadamente. Uma utra vantagem d treinament é a minimizaçã da resistência a us d sftware daqueles usuáris que nã estiveram cmpletamente envlvids n prjet. A dcumentaçã que acmpanha sistema também tem papel crucial na entrega, afinal ela será utilizada cm material de referência para a sluçã de prblemas u cm infrmações adicinais. Essa dcumentaçã inclui, dentre utrs, manuais d usuári e d peradr, guia geral d sistema, tutriais, ajuda (help), preferencialmente n-line e guias de referência rápida [1]. Destaque na entrega é a Implantaçã, que é mment em que sftware é dispnibilizad para peraçã pel cliente, cntempland tdas as tarefas necessárias para permitir a peraçã (cm preparaçã d ambiente, da base de dads, infra-estrutura e recurss requerids, pssível treinament). A ideia é garantir uma transiçã d desenvlviment para a peraçã mais tranquila pssível. 7.2 MANUTENÇÃO Manutenibilidade e inteligibilidade de prgramas sã cnceits paralels: quant mais difícil é entender um prgrama, mais difícil é mantê-l. [Gerald Berns] Vcê pde ns pagar puc agra u ns pagar muit mais depis. [Rger Pressman, cartaz em uma cncessinária de autmóveis sugerind uma revisã] Origem: Internet (lcais diverss). Cm cmentáris própris INTRODUÇÃO A manutençã de sftware pde ser respnsável pr mais de 80% de td esfrç despendid pr uma rganizaçã de sftware em relaçã a um prdut. Pr este mtiv é interessante que exista uma equipe na rganizaçã que se dedique à manutençã de sftware, vist haver diferenças entre tratament dad a desenvlviment e à manutençã.

165 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 165 É precis desenvlver mecanisms para avaliar, cntrlar e mdificar sftware desenvlvid, pis a mudança é inevitável quand se cnstrói sistemas baseads em cmputadr. O bjetiv principal da inserçã da característica de Manutenibilidade de sftware é facilitar estas mudanças e reduzir a quantidade de esfrç despendid em manutençã DEFINIÇÃO DE MANUTENÇÃO Algumas pessas pderiam questinar se realmente gastam 80% de seu temp cnsertand errs n sftware desenvlvid, mas a manutençã de sftware é muit mais que apenas cnsertar errs. A manutençã de sftware pde ser definida em quatr atividades que sã verificadas após a entrada em peraçã d prgrama. Sã elas a manutençã crretiva, manutençã adaptativa, manutençã perfectiva e manutençã preventiva. A Manutençã Crretiva é caracterizada pel prcess que diagnstica e crrige s errs durante us d prgrama, pis as atividades de testes antes da entrega deste nã sã capazes de detectar tds s errs d prgrama, muits prblemas só sã descberts durante seu us. A Manutençã Adaptativa é utilizada para adaptar sftware as rápidas mudanças que crrem na cmputaçã, cm nvs sistemas peracinais, nvas gerações de hardware, equipaments periférics. Mdifica-se sftware para que ele tenha uma interface adequada às mudanças crridas n ambiente da cmputaçã. Manutençã Perfectiva/Evlutiva crre quand um sftware é bem sucedid. Recmendações de nvas capacidades, de mdificações em funcinalidades que existem sã slicitadas pel usuári à medida que ele é usad. Ela é respnsável pela mair parte de td esfrç despendid em manutençã de sftware. Manutençã Preventiva crre quand sftware é mdificad para melhrar a cnfiabilidade u a manutenibilidade futura, u para ferecer uma base melhr para futuras ampliações. Ela habitualmente utiliza técnicas cm Engenharia Reversa e ReEngenharia. A precupaçã em manutençã de sftware pr parte de alguns prfissinais da área se cncentra na segunda e terceira atividades. Para adaptar u aperfeiçar sftware deve-se determinar nvs requisits, reprjetar, gerar códig e testar u seja, executa-se nvamente um Prcess de Desenvlviment de Sftware (u parte dele) CARACTERÍSTICAS DA MANUTENÇÃO Era uma fase deixada de lad n prcess de engenharia de sftware. Existem pucs lançaments sbre manutençã quand cmparad cm utras áreas da cmputaçã. É precis destacar que a manutençã pde afetar nã só códig-fnte, mas artefats gerads a lng de td prcess de desenvlviment de sftware, cm as especificações de requisits, análise e design. Além de gerar seus própris artefats. A manutençã pde ser descrita a partir de características cm: O tip de manutençã As atividades exigidas para realizar esta fase, cm u sem a abrdagem de engenharia; Os custs, prazs e recurss necessáris; Os prblemas pré e pós a serem cnsiderads quand a manutençã é realmente levada a séri.

166 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: MANUTENÇÃO ESTRUTURADA VERSUS NÃO-ESTRUTURADA Quand únic mecanism dispnível para realizaçã de uma manutençã é códig-fnte, a atividade cmeça cm uma pensa avaliaçã d códig-fnte, nrmalmente cmplicada pela dcumentaçã interna ruim e cm grande pssibilidade de ser mal interpretada. A repetiçã ds testes é impssível de ser realizada, prque nã existe nenhum registr de testes. Este é alt preç a ser pag pr nã se utilizar uma Manutençã Estruturada. Se existir uma cnfiguraçã de sftware cmpleta, inicia-se a manutençã cm uma avaliaçã da dcumentaçã d prjet. O prjet é estudad e uma abrdagem é planejada. Os artefats afetads sã atualizads e testes sã realizads. Esta sequência é chamada Manutençã Estruturada. Ela nã garante uma manutençã sem prblemas, mas a quantidade de esfrç é diminuída e a pssibilidade de sucess é aumentada CUSTO DE MANUTENÇÃO Na década de 1970 a manutençã era respnsável pr 35% a 40% d rçament de sftware. Atualmente este valr pde chegar a 80% d cust. Devid à falta de rganizaçã e planejament na realizaçã de manutençã, as prtunidades de investir n desenvlviment d sftware se trnam priridade secundária prque s recurss dispníveis devem ser canalizads para tarefas de manutençã. Alguns custs intangíveis sã:

167 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 167 Mdificações slicitadas pel cliente que nã pdem ser encaminhadas devid a temp; Reduçã na qualidade glbal d sftware devid às mudanças que intrduzem errs n sistema; Insatisfaçã d funcinári em trabalhar em uma manutençã PROBLEMAS A deficiência na maneira cm sftware fi planejad u desenvlvid é respnsável pr váris ds prblemas na manutençã de sftware. Alguns prblemas cmumente enfrentads sã: Quand sftware tem muitas versões é difícil rastrear a evluçã d sftware; É difícil rastrear prcess cm fi criad; É difícil interpretar sftware de utra pessa e esta utra pessa nrmalmente nã está pr pert u nã tem temp de explicar sftware; A dcumentaçã nã existe u é muit ruim; Nrmalmente sftware nã é prjetad para sfrer mdificações; Há frustraçã d funcinári a realizar um trabalh de manutençã MANUTENIBILIDADE A manutenibilidade pde ser definida qualitativamente cm a facilidade cm que um sftware é entendid, crrigid, adaptad e/u aumentad. Ela é uma das metas primrdiais que rientam s passs de um prcess de engenharia de um sftware. Diverss fatres afetam a manutenibilidade de um sftware. Uma cnfiguraçã de sftware ruim pde causar um impact negativ, mesm quand s passs técnics fram realizads anterirmente. Alguns fatres que pdem estar relacinads a ambiente de desenvlviment: Dispnibilidade de pessal de sftware qualificad; Estrutura cmpreensível d sistema; Facilidade de manusei d sistema; Us de linguagens de prgramaçã padrnizadas; Us de sistemas peracinais padrnizads; Estrutura de dcumentaçã padrnizada; Dispnibilidade de cass de teste; Facilidades de depuraçã embutidas; Dispnibilidade de um cmputadr adequad para realizar a manutençã. Pssivelmente, fatr mais imprtante a afetar a manutenibilidade seja seu planejament. Se sftware fr vist cm um element de sistema que inevitavelmente sfrerá mudanças, as chances de que um sftware de fácil manutençã seja prduzid têm a prbabilidade de se elevar substancialmente.

168 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 168 A manutenibilidade de sftware é um term difícil de quantificar, assim cm a qualidade e a cnfiabilidade. Para tentar quantificar a manutenibilidade relacinada a esfrç despendid durante a manutençã, alguns elements que pdem ser medids sã: Temp de recnheciment d prblema. Temp de retard administrativ; Temp de cleta de ferramentas de manutençã; Temp de análise d prblema; Temp de especificaçã das mudanças; Temp de crreçã (u mdificaçã) ativa; Temp de testes lcais; Temp de testes glbais; Temp de revisã de manutençã; Temp de recuperaçã ttal. Além dessas medidas rientadas para temp, a manutenibilidade pde ser medida indiretamente, a se cnsiderar as medidas da estrutura de prjet e as métricas de cmplexidade d sftware. Em cada nível d prcess de revisã da engenharia de sftware, a manutenibilidade deve ser cnsiderada. Durante a revisã ds requisits, as áreas de futurs acréscims e ptencial revisã sã antadas, as questões de prtabilidade d sftware sã discutidas e as interfaces d sftware que pderiam causar um impact sbre a manutençã d sftware sã cnsideradas. Durante as revisões de design, s mdels de dads, arquitetural, prcedimental e de interfaces sã avaliads quant à facilidade de mdificaçã e qualidade de design glbal. Finalmente, cada etapa de teste pde ferecer pistas sbre partes d prgrama que pdem exigir manutençã preventiva antes que sftware seja frmalmente liberad. A própria tarefa de manutençã d sftware deve ser revisada para a cnclusã de cada prjet de sftware TAREFAS DA MANUTENÇÃO As tarefas assciadas à manutençã de sftware iniciam-se muit temp antes que um pedid de manutençã seja feit. Inicialmente, uma equipe de manutençã deve ser estabelecida, prcediments de avaliaçã e relatóris devem ser descrits e uma sequência de events padrnizada deve ser definida para cada tip de manutençã. A rganizaçã reduz a cnfusã e melhra flux de atividades de manutençã a estabelecer um prcediment de trabalh. Embra nã seja necessári estabelecer uma rganizaçã de manutençã frmal, uma delegaçã de respnsabilidade infrmal é abslutamente essencial até mesm para pequens desenvlvedres de sftware. Um desses esquemas é mstrad na figura a seguir.

169 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 169 Autridade Cntrladra de Mudanças Pedids de Manutençã Supervisr de Sistemas Cntrladr de Manutençã Administradr de Cnfiguraçã Pessal de manutençã Os Pedids de Manutençã sã canalizads a um Cntrladr de Manutençã que apresenta cada pedid para ser avaliad pr um supervisr de sistemas. O Supervisr de Sistemas é um membr d pessal técnic a quem fi atribuída a respnsabilidade de se familiarizar cm um pequen subcnjunt de prgramas em peraçã. Lg que uma avaliaçã é feita, uma Autridade Cntrladra de Mudanças deve determinar a açã a ser tmada. Cada um ds psts de trabalh descrits anterirmente serve para estabelecer uma área de respnsabilidade pela manutençã. O cntrladr e a autridade cntrladra de mudanças pdem ser uma única u (para grandes sistemas) um grup de gerentes e pessal técnic sênir. O supervisr de sistemas pde ter utras brigações, mas ele cnstitui um cntat cm um pacte de sftware específic. Tds s pedids de manutençã de sftware devem ser apresentads padrnizadamente. O desenvlvedr de sftware nrmalmente elabra um Frmulári de Pedid de Manutençã (Maintenance Request Frm MRF). Se um err fr encntrad, uma descriçã cmpleta das circunstâncias que levaram a err deve ser incluída. O MRF é um dcument elabrad externamente, usad cm base para planejar a tarefa da manutençã. Internamente, a rganizaçã de sftware desenvlve um Relatóri de Mudanças de Sftware (Especificaçã de Manutençã e/u Plan de Manutençã) que indica: a magnitude d esfrç exigid para satisfazer um MRF; a natureza das mdificações exigidas; a priridade d pedid; e dads psterires a fat sbre a mdificaçã FLUXO DE EVENTOS Um pssível flux de events estabelecid em atendiment a um pedid de manutençã pde ser cm mstrad a seguir.

170 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 170 Em relaçã a flux mstrad acima, um pedid de manutençã crretiva inicia-se cm uma avaliaçã da gravidade de err. Se existir um err grave é designada uma equipe sb a direçã d supervisr de sistemas e a análise d prblema inicia-se imediatamente. Para errs mens graves, pedid de manutençã crretiva é avaliad e categrizad, e depis prgramad em cnjunt cm utras tarefas que exijam recurss de desenvlviment de sftware. Os pedids de manutençã adaptativa/preventiva e/u perfectiva seguem um caminh diferente. As adaptações/prevenções sã avaliadas e categrizadas antes de serem clcadas numa fila para sfrerem manutençã. Os acréscims passam pela mesma avaliaçã. Prém nem tds s tips de acréscims sã levads a efeit. O event final d flux de manutençã é uma revisã que revalida tds s elements da cnfiguraçã d sftware e garante que MRF tenha sid, de fat, atendid CONSERVAÇÃO DE REGISTROS A cnservaçã de registrs sbre manutençã de sftware nã está crrend, u crre de maneira precária. Pr essa razã, frequentemente nã é pssível avaliar a efetividade das técnicas de manutençã. O primeir prblema encntrad na cnservaçã de registrs sbre manutençã cnsiste em entender quais dads valem a pena serem guardads. Alguns dads sã citads abaix: Identificaçã d prgrama; Tamanh d códig-fnte e d execuçã; Linguagem de prgramaçã usada; Data de instalaçã d prgrama; Númer de execuções d prgrama desde a instalaçã; Númer de falhas de prcessament assciadas a item anterir;

171 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 171 Númer de instruções-fnte adicinadas, suprimidas e/u alteradas pela mudança n prgrama; Númer de pessas-hra empregadas pr mudança; Identificaçã d engenheir de sftware; Identificaçã d MRF AVALIAÇÃO Uma avaliaçã das atividades de manutençã de sftware frequentemente é cmplicada pela falta de dads cncrets, prém pdems ns basear na seguinte lista de medidas em ptencial: Númer médi de falhas de prcessament pr execuçã d prgrama; Ttal de pessas/hra empregadas em cada categria de manutençã; Númer médi de pessas/hra empregada pr instruções-fnte adicinadas/suprimidas/alteradas devid à manutençã; Média de pessas/hra empregadas pr tecnlgia; Prcentagem de pedids de manutençã pr tip. As medidas descritas acima pdem prprcinar uma estrutura quantitativa a partir da qual pdem ser tmadas decisões sbre a técnica de desenvlviment, esclha da linguagem, prjeções sbre esfrç de manutençã, alcaçã de recurss e muitas utras questões. A partir de uma avaliaçã cm essa é pssível estabelecer e evluir cnjunt de tarefas de manutençã de uma empresa EFEITOS COLATERAIS DA MANUTENÇÃO DE SOFTWARE Um efeit clateral é um err u cmprtament indesejável que crre devid a uma mdificaçã. Os principais tips de efeit clateral sã: Efeits claterais na cdificaçã: Quand uma mdificaçã n códig-fnte d prgrama prvca prblemas de funcinament n sftware. Às vezes um err minúscul pde levar a muits utrs; Efeits claterais ns dads: Quand mexe-se na estrutura de dads frequentemente crrem efeits claterais. Pdems imaginar, pr exempl, que a mudar uma tabela n banc de dads prgramadr pde nã perceber tdas as rtinas que acessam a tabela. Iss pderia ser evitad cm us de bas práticas de dcumentaçã; Efeits claterais na dcumentaçã: quand se é feita qualquer alteraçã n sftware deve-se lembrar também de alterar a dcumentaçã, d cntrári a mesma nã mais será fiel a sftware, que pde acrescentar prblemas nas próximas manutenções u até mesm a inviabilidade das mesmas MANUTENÇÃO DE CÓDIGO ALIENÍGENA Códig-fnte alienígena é códig já antig em que nenhum funcinári da empresa participu da fabricaçã d mesm. Geralmente mesm nã tem dcumentaçã, nenhuma metdlgia de prjet e tem prjet de dads ruim. Send, prtant um códig-fnte de manutençã dificultada.

172 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 172 Alguns passs que pdem ajudar na manutençã destes códigs: Avaliar a dcumentaçã existente, fazend seus própris cmentáris se puder ser útil; Respeitar estil de frmataçã d prgrama. Indicar n códig quais instruções fram alteradas / incluídas / excluídas; Nã tentar cmpartilhar us das variáveis já existentes. Criar variáveis próprias; Manter registrs detalhads das alterações; Inserir verificaçã de errs REENGENHARIA A reengenharia é prcess que visa alterar parcialmente, u pr cmplet, a funcinalidade riginal d sistema, paradigma de desenvlviment e/u alguma(s) da(s) tecnlgia de infrmaçã. Para decidir se devems desenvlver um prcess de reengenharia, é necessári fazer uma análise de cust / benefíci. Para iss é precis respnder a perguntas cm as seguintes: Cm identificar aplicativs que devem ser bjet de reengenharia? Cm calcular s benefícis ptenciais d esfrç de reengenharia? ENGENHARIA REVERSA Cm própri nme indica, a Engenharia Reversa é uma engenharia "a cntrári", prtant, é uma atividade que trabalha cm um prdut existente e tenta entender cm este prdut funcina e que ele faz exatamente (tdas as suas prpriedades em quaisquer circunstâncias). Fazems engenharia reversa quand querems trcar u mdificar uma peça (u um sftware) pr utr, cm as mesmas características, mas nã tems tdas as infrmações sbre essa peça. Faz-se us da Engenharia Reversa ns seguintes cass: Para adaptar sftware a nva tecnlgia; Para atualizar sftware (nvas biblitecas, nvas linguagens de prgramaçã, nvas ferramentas); Para adaptar sftware a nvas regras (trca de meda); Para dispnibilizar nvas funcinalidades; Para crrigir bugs. O prcess de Engenharia Reversa é feit em etapas bem definidas. Extraçã de fats d sistema a analisar; Análise Estática d Códig; Análise Dinâmica d Códig; Análise de Dads; Análise de Dcumentaçã; Análise de utras fntes de infrmaçã; Tratament ds fats; Visualizaçã ds resultads.

173 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 173 Na Análise Estática d Códig prcura-se: Determinar quais sã s cmpnentes básics d sistema, cm arquivs, rtinas, variáveis, etc. Relações de Definiçã: diretóri de determinad arquiv, arquiv nde se encntram determinadas variáveis, etc. Relações de Referência: qual arquiv depende de utr, qual rtina depende de utra, etc. Existem ferramentas para fazer este tip de análise - sã s "Parsers" - e a análise é chamada de "parsing". Algumas linguagens de prgramaçã permitem facilmente um parsing (cm Delphi - Pascal, pr exempl). Na Análise Dinâmica executa-se prgrama e se mnitra s valres das variáveis, quais funções sã chamadas, etc. As ferramentas utilizadas sã denminadas de "Debuggers". Quand um sistema pssuir um banc de dads, este pde servir de fnte de infrmaçã sbre própri sistema. Dcumentaçã é tud que nã está send usad pel cmputadr para fazer funcinar sistema, mas faz parte d prcess. Pdem ser texts, diagramas, helps, etc. Cm utras fntes de alimentaçã te-se a linguagem de prgramaçã que fi utilizada, sistema peracinal, tip de prcessadr, etc. Uma vez que se tenham infrmações suficientemente claras e precisas, passams para etapa de tratament ds fats, nde é pssível alterar códig e ir até a estrutura de um sistema (u prgrama) utilizand várias técnicas. Dentr da engenharia de sftware, uma fase recnhecidamente prblemática se refere à manutençã de sftware, respnsável pr custs de prprções superires às das demais fases d cicl de vida de sistemas [Schach 1994]. A atividade de manutençã cnsiste basicamente de três etapas: entendiment, mdificaçã e revalidaçã d sistema [Schneidewind 1987]. Ntadamente, as etapas de entendiment e mdificaçã estã muit relacinadas cm a dispnibilizaçã das infrmações d sftware, u seja, se apóiam na existência, cnsistência, cmpleteza e atualizaçã crreta ds dcuments que cmpõem. A Engenharia Reversa é uma técnica utilizada para recuperar infrmações a partir ds artefats dispníveis de um sftware visand a btençã de sua representaçã em um nível mais alt de abstraçã. Dessa frma, pde facilitar entendiment de sistemas. A engenharia reversa pde bter um cnjunt de infrmações sbre um prjet a partir d códigfnte de um prgrama, prém nível de abstraçã, a inteireza da dcumentaçã, grau em que analista trabalha em cnjunt cm as ferramentas, e a direcinalidade d prcess variam muit. O nível de abstraçã de um prcess de engenharia reversa refere-se à sfisticaçã das infrmações btidas a partir d códig-fnte. À medida que nível de abstraçã se eleva, engenheir recebe nvas infrmações que permitirã cmpreender prgrama mais facilmente. A inteireza refere-se a nível de detalhes que se cnsegue bter em um determinad nível de abstraçã. Geralmente quant mair nível de abstraçã menr é a inteireza, prém quant mais a pessa faz análises sbre determinad prcess, a inteireza aumenta. A interatividade refere-se a grau que ser human interage cm as ferramentas de auxíli. Esse grau tende a aumentar à medida que a abstraçã aumenta cas cntrári a inteireza será prejudicada.

174 Disciplina: Engenharia de Sftware Matéria: Entrega e Manutençã de Sftware Página: 174 Se a direcinalidade fr unidirecinal, tdas as infrmações extraídas d códig-fnte pderã ser utilizadas pel engenheir diretamente, cas cntrári as infrmações serã ferecidas à ferramenta de reengenharia que tentará reestruturar u regenerar legad. 7.3 DICAS DE LEITURA PRESSMAN, Rger. Engenharia de sftware Makrn Bks. Capítul 5 Prática: Uma visã genérica, item 5.6 Implantaçã; Capítul 31 - ReEngenharia; SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 21 Evluçã de Sftware; SCHACH, Stephen R.. Engenharia de sftware: s paradigmas clássics e rientad a bjet McGrawHill. Capítul 15 Manutençã pós-entrega.

175 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: GERÊNCIA DE PROJETOS DE SOFTWARE Um prjet é cm uma viagem em uma rdvia. Alguns prjets sã simples e rtineirs, cm dirigir até uma lja em plena luz d dia. Mas, a mairia ds prjets que valem a pena é mais parecida cm dirigir um caminhã fra da estrada, nas mntanhas. [Cem kaner, James Bach, Bret Pettichrd] 8.1 REGRAS BÁSICAS PARA ADMINISTRAR TECNOLOGIA DA INFORMAÇÃO Origem: Livr Sistemas de Infrmaçã Gerenciais, autr: Tadeu Cruz, editra Atlas, 3ª. Ediçã (2003). Capítul 04 Regras Básicas para Administrar Tecnlgia da Infrmaçã. A administraçã de qualquer área de Tecnlgia da Infrmaçã é cmpsta pr regras, assim cm qualquer utr setr. O mínim que um gerente, u administradr, deve implementar é: 1 a. regra: Ser Organizad Planejar dia a dia Facilita para gerenciar e alcar recurss dispníveis, sem cnflits de interesse. Planejar cm antecedência events imprtantes de preferência n papel, a fim de identificar melhr as variáveis mais imprtantes. Planejament de atividades ds membrs pels quais é respnsável Tarefas, datas e prgress. Estas atividades crescem em imprtância à medida que a equipe cresce. 2 a. regra: Ser Pró-ativ Antecipar-se as prblemas, indicar sluções, ensinar a simplificar, buscar encntrar caminhs alternativs, de preferência antes que usuári perceba que existe alg que precise ser melhrad. Vale destacar: sem rganizaçã mal é pssível ser reativ, quem dirá pró-ativ. Prcurar estar sempre junt às áreas usuárias, assim identificand as necessidades. Nã se deve bancar prfissinal avestruz, tentand islar Departament de Infrmática. 3 a. regra: Ser Educad e Plític Nã permitir que s prblemas particulares cntaminem ambiente de trabalh, nem descntar ns utrs a incmpetência própria, as frustrações. Estas características já sã suficientemente ruins em qualquer prfissinal, em um gerente pdem trnar-se um verdadeir desastre! É precis ser um verdadeir Diplmata. 4 a. regra: Ser Cntrladr Ist é, mantenha a situaçã sb cntrle. Nã basta fazer planejament, é precis acmpanhar s resultads e tmar atitudes quand necessári. É precis criar mecanisms que dêem cndições de supervisã e cntrle a quem tem pr brigaçã manter uma equipe rientada, cesa e eficiente.

176 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: a. regra: Estar Sempre Preparad A se preparar para enfrentar s prblemas, tds na equipe, incluind s usuáris/clientes, ganham. 6 a. regra: Ser Mais Executiv Existem n departament de Tecnlgia da Infrmaçã duas psturas: técnica e gerencial. Os gerentes devem fcar sua atençã ns negócis, que pde trnar-se difícil se fr cnsiderad que ba parte ds gerentes de TI tem rigem em curss da área técnica/engenharia. 8.2 SOBRE GERENCIAMENTO DE PROJETOS DE SOFTWARE Origem: Engenharia de Sftware, Ian Smmerville, 8ª. Ediçã. O gerenciament de prjets: Está relacinad às atividades envlvidas em assegurar que sftware será entregue dentr d praz/cust definid n crngrama e de acrd cm s requisits das rganizações que desenvlvem e adquirem sftware; É necessári prque desenvlviment de sftware está sempre sujeit às restrições de rçament e de crngrama que sã estabelecidas pela rganizaçã que desenvlve sftware. Pr que gerenciament de prjets de sftware é nrmalmente mais difícil de ser realizad d que gerenciament de prjets de utrs prduts? O prdut é intangível; O prdut é nrmalmente flexível; A engenharia de sftware nã é recnhecida cm uma disciplina da engenharia, nem pssui mesm status de utras engenharias, tais cm a Mecânica, Elétrica, Civil, etc; O prcess de desenvlviment de sftware nã cstuma ser padrnizad; Muits prjets de sftware sã prjets únics. E cnsiderand tais questões nã é de surpreender que s prjets nrmalmente esturem crngrama. 8.3 ETAPAS DA GERÊNCIA DE PROJETOS Origem: Internet e utrs. Basicamente, as atividades realizadas pel gerente de prjet pdem ser agrupadas em três etapas: Planejament de Prjets de Sftware Sã as atividades iniciais de gerenciament. Cnsistem em analisar s bjetivs d prjet e, cm base neles, desenvlver Plan Geral de Desenvlviment de Sftware, que irá incluir a definiçã das atividades, alcaçã de pessal para realizá-las, estimativas de crngrama, cust e qualidade, etc; Cntrle / Mnitria / Acmpanhament de Prjets de Sftware Cnsiste em cntrlar e mnitrar prgress d prjet, verificand se estad atual está de acrd cm as

177 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 177 estimativas de custs e prazs, e realizar as alterações/adaptações que frem necessárias a lng d prjet; Encerrament / Análise Final Cnsiste em analisar td prcess de desenvlviment, visand assim um aprendizad em relaçã a quais práticas u prcediments fram vantajsas, adequadas e quais nã fram. A partir dessa análise, gerente de prjet pde sugerir melhrias a serem implementadas em nvs prjets. Essas etapas sã realizadas a lng de td Prcess de Desenvlviment de Sftware, e se dividem em uma série de atividades. Assim, pde-se dizer que prcess gerencial cmeça antes d trabalh técnic, prssegue n desenvlviment e se encerra smente quand sftware é apsentad. Um gerente nã trabalha szinh. As atividades d gerente estã diretamente relacinadas cm tds s utrs desenvlvedres. Assim, a etapa de planejament pde ser realizada em cnjunt cm, pr exempl, analista de requisits, cm parte das atividades d prcess de desenvlviment de sftware. Junts, eles deverã, entre utrs: Analisar bjetiv d sftware; Analisar escp d sftware; Cnsiderar sluções alternativas; Cnsiderar restrições; Realizar estimativas. Analista: se precupa mais cm lad técnic; Gerente: se precupa em esclher a melhr abrdagem cm base em restrições impstas pr prazs, rçament, dispnibilidade de pessal, interfaces técnicas, etc. Durante as três etapas citadas, gerente de prjet realiza várias atividades, send algumas das principais: Definiçã de Escp; Realizaçã de Medições; Identificaçã de atividades da equipe; Identificaçã de Estimativas (custs, prazs, recurss); Gerenciament de riscs; Elabraçã de crngrama; Criaçã e manutençã d Plan de Prjet. Já Smmerville (2007) destaca as seguintes atividades realizadas pr um gerente de prjets de sftware: Elabraçã de Prpsta; Planejament e desenvlviment de Crngrama d prjet; Identificaçã d Cust d prjet; Realizaçã de mnitraçã e revisões de prjet;

178 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 178 Seleçã e avaliaçã de pessal; Elabraçã de relatóris e apresentações. Alguns elements-chave d prcess gerencial A iníci d prjet deve-se estabelecer: Os bjetivs (metas glbais); O Escp (prcesss principais); Pssíveis sluções alternativas; Pssíveis restrições administrativas / técnicas. Medidas e Métricas Medida valr; Métrica a frma de se chegar a valr; Mede-se Prcess em um esfrç para melhrá-l; Mede-se Prdut para ter mais Qualidade; Mede-se para Quantificar. Quantifica-se para Administrar; Cntrvérsias Quais as métricas aprpriadas? A prdut; A prcess. É just cmparar pessas? Prcesss? Prduts? Estimativas Identificam, entre utrs: Esfrç human exigid; Duraçã crnlógica; Custs; Cm fazer? Usar de Técnicas / Métds de Estimativa; Basear n Escp d Prjet; Utilizar Históric de aferições passadas. Usar as experiências passadas, de prjets devidamente registrads; Identificar semelhanças entre prjets (tamanh e funções); Dividir prjet em partes menres (etapas) e realizaçã de estimativas individuais de cada etapa; Dicas: Estabelecer crngrama mais real pssível e acrescentar uma Margem de Segurança (de 5% a 20% - dependend d grau de incerteza, riscs,...) as valres btids, cm uma frma de segurança, para cntrabalançar s riscs identificads;

179 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 179 Aplicar técnicas diferentes, a fim de pder realizar cmparações ns valres btids; Reavaliar crngrama a fim de cada etapa. Determinaçã de Tarefas. Identificaçã d cnjunt de tarefas; Estabeleciment de interdependência entre as tarefas; Estimativa de esfrç / praz para cada tarefa; Os gerentes cncentram-se nã apenas n praz final, mas na duraçã de cada uma das tarefas de um prjet. Gestã de Riscs. Alguns riscs Técnics: As ferramentas adequadas estã dispníveis? Os desenvlvedres têm experiência? As funções desejáveis sã realmente implementáveis? Alguns riscs de Prjet: O Prjet pde ser desenvlvid dentr d praz estipulad? As necessidades d cliente fram realmente atendidas? Existem funções cultas? Mudanças n prjet acarretam mudanças n crngrama? Atividades habituais: Identificar s riscs; Avaliar s riscs; Prpr sluçã para s riscs; Mnitrar s riscs. Mnitraçã e Cntrle - Acmpanhament de cada tarefa. 8.4 PLANEJAMENTO DE PROJETO Origem: Gerência em Prjets Pesquisa, Desenvlviment e Engenharia, Valerian, 1998, Capítul 7 Planejament: Aspects Gerais; Engenharia de Sftware, Rger Pressman, 1995, Capítul 4 Gerenciament de Prjets: Planejament; Engenharia de Sftware, Ian Smmerville, 2007, capítul 5 Gerenciament de Prjets; Internet; Cmentáris própris. Uma das máximas que deverá ser seguida em se tratand de um prjet é: Tud que deverá ser executad deve ser antes planejad, para que pssa ser cntrlad durante a sua execuçã. Smmerville (2007) destaca sbre Planejament de Prjet: É, prvavelmente, a atividade de gerenciament de prjet que tma mais temp; É uma atividade cntínua que vai d cnceit inicial até a entrega d sftware. Os plans devem ser regularmente revisads, à medida que infrmações nvas se trnem dispníveis;

180 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 180 Váris tips diferentes de plan pdem ser desenvlvids para apiar Plan principal de prjet de sftware que está relacinad a Crngrama e a Orçament DEFINIÇÃO DE PLANEJAMENTO Planejament é prcess que visa estabelecer cm antecedência as decisões e as ações a serem executadas em um dad futur, para atingir um bjetiv definid, em um cert praz, cm um cert cust, e cm certs recurss. Dele resulta um Plan de Prjet, que explicita s cmprmisss da equipe ns camps: O que fazer? Cm fazer? Quem irá fazer? Cm que insums? Quand irá fazer? Pr Quant irá fazer? Em quant temp irá fazer? Onde irá fazer? E cntém infrmações sbre: Escp: Entender prblema e trabalh que deve ser feit; Estimativa: Quem? Quant esfrç? Quant temp? Quant custa? Risc: O que pde dar errad? Cm evitar? Crngrama: Cm alcar s recurss a lng d temp? Marcs? Cntrle: Cm cntrlar a qualidade? E as mudanças? As versões? Smmerville (2007) destaca que além d Plan de Prjet, s gerentes pdem também precisar elabrar utrs tips de Plan, cm s que estã abaix destacads: Smmerville (2007) prssegue, destacand pnts-chaves que devem ser lembrads a se realizar gerenciament de um prjet: Um bm gerenciament é essencial para sucess d prjet; A natureza intangível d sftware causa prblemas para gerenciament; Gerentes têm papéis diverss, mas suas atividades mais significantes sã planejament, elabraçã de estimativas e desenvlviment de crngrama; Planejament e elabraçã de estimativas sã prcesss iterativs que cntinuam a lng d curs de um prjet;

181 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 181 Um marc de prjet é um estad previsível nde um relatóri de prgress frmal é apresentad à gerência; O desenvlviment d crngrama de prjet envlve a preparaçã de várias representações gráficas mstrand atividades de prjet, suas durações e também pessal envlvid; O gerenciament de riscs está relacinad à identificaçã de riscs que pdem afetar prjet e a planejament para assegurar que esses riscs nã resultarã em maires ameaças OBJETIVOS DO PLANEJAMENTO Os cmprmisss básics d gerente e sua equipe situam-se ns camps: Técnic ( que fazer); Crnlógic (quand); Financeir (pr quant). Ou seja: Fazer estimativas (que pdem ser de melhr e pir cas) razáveis de: Cust, Recurss, Praz. Seus prblemas peracinais sã: Cm que (quais recurss e serviçs)? Cm (quais metdlgias, técnicas, prcesss, ferramentas)? Pr que (cm que finalidade u justificativa)? Onde (em que u para qual lcal)? Pr quem (qual departament, rganizaçã, terceir, pessal, etc)? O Planejament d prjet tem pr bjetiv determinar e dcumentar estes aspects para servir de rientaçã para a execuçã e cntrle. Tds estes pnts sã balanceads durante planejament a fim de se bter s melhres cmprmisss entre eles ORGANIZAÇÃO DE ATIVIDADES Em um prjet, as atividades devem ser rganizadas para prduzirem saídas tangíveis para que gerenciament julgue prgress. Para se identificar essas saídas, tem-se: Marcs sã pnt final de uma atividade de prcess; Prduts a serem entregues sã resultads d prjet dispnibilizads para s clientes. A figura abaix apresenta as pssíveis atividades envlvidas na especificaçã de requisits, e s marcs assciads a tais atividades.

182 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: SELEÇÃO DE EQUIPE DE PROJETO Pde nã ser pssível indicar as pessas ideais para trabalhar em um prjet. Algumas pssíveis causas para tal situaçã pdem ser: O rçament d prjet pde nã ser suficiente para cntratar uma equipe muit bem remunerada; Uma equipe cm experiência adequada pde nã estar dispnível; Uma rganizaçã pde querer desenvlver as habilidades de seus funcináris pr mei de um prjet de sftware. Gerentes têm de trabalhar dentr dessas restrições, especialmente quand existe carência de pessal treinad FASES DO PLANEJAMENTO O Planejament quase sempre é realizad de frma interativa, em passs e crreções, sucessivamente detalhads, até se chegar a nível de detalhament necessári. E crreções durante a própria execuçã d Plan de Prjet cstumam crrer. As fases habituais de um planejament de prjet sã: Iniciaçã d Prjet (Prjet Executiv); Planejament Preliminar (para aprvaçã) (Plan Básic); Negciaçã da Prpsta; Cntrataçã d Prjet; Planejament Detalhad (para rientaçã da execuçã e cntrle) (Plan Executiv). As 02 fases d Planejament (Preliminar e Detalhad) apesar de seguirem metdlgias semelhantes, diferem quant à Finalidade, Grau de Detalhament e Equipe Elabradra. Grau de Detalhament Questã: Estabelecer s respectivs níveis de detalhes necessáris a cada plan; O Planejament Preliminar habitualmente estará limitad a pucs níveis de detalhament, apenas suficiente para a cmpreensã d prjet, de tal frma que pssam ser realizadas as tarefas de Prpsta, Negciaçã e Aprvaçã; O Planejament Detalhad, pr sua vez, é mais extens, crrespndend a níveis mais inferires da Estrutura de Decmpsiçã de Trabalh é precis estabelecer s níveis necessáris a uma firme cnduçã da execuçã;

183 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 183 Nã se pde esquecer, n entant, que ambs s planejaments devem ser cmpatíveis; O grau de detalhament deve ser: O NECESSÁRIO Para nã deixar dúvidas nem prmver desajustes futurs; O SUFICIENTE Para nã impr restrições, cmprmetiments dispensáveis e inúteis, nem tlher as iniciativas ds executantes. Cngelament d Planejament: Linha de Base Há um limite entre nível de perfeiçã que se busca para um plan e limite de prtunidade para alcançá-l; Deve-se sempre ter em mente que s plans sã passíveis de revisã (atualizaçã / crreçã); É precis estabelecer um mment de parada d refinament d plan, quand s dads sã cngelads, frmand uma linha de base (baseline), que é pnt de partida para a aprvaçã e a execuçã d plan; Entre s cmpnentes cngelads destacam-se: Crngrama (prazs, custs, recurss); Cnfiguraçã d Prdut. Smmerville (2007) apresenta um algritm que pde ser cnsiderad a se tratar das atividades de Planejament e de sua execuçã (ist é, d mnitrament). O algritm em questã se encntra abaix dispst INICIAÇÃO DO PROJETO Um prjet pde ser iniciad de 03 maneiras básicas: Iniciativa interna à própria rganizaçã desenvlvedra; Slicitaçã externa clcada à rganizaçã. Editais, carta-cnvite, pedids de prpsta, Oferta da rganizaçã à entidade externa. Resultad desta etapa: Prjet Executiv (dcument preparad pela direçã da empresa indicand respnsáveis e recurss pela realizaçã de um estud de viabilidade e de planejament preliminar para um prjet).

184 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: O PLANO DE PROJETO Um plan de prjet estabelece: Os recurss dispníveis para prjet; A estrutura analítica de trabalh; Um crngrama para trabalh. Basicamente, um plan de prjet deve cnter a seguinte estrutura: Intrduçã Descreve s bjetivs d prjet e pssíveis restrições; Organizaçã de prjet Identifica a rganizaçã da equipe, ist é, as pessas envlvidas, suas respnsabilidades e atribuições; Análise de riscs Caracteriza s riscs e apresenta um Plan de Cntingência; Requisits de recurss de hardware e de sftware dispõe ds recurss de hardware e sftware necessáris a prjet. Em cas de aquisiçã devem ser incluíds s prazs e custs de tal cmpra; Estrutura analítica Apresenta tdas as atividades que devem ser executadas a lng d prjet, bem cm s prduts (artefats de entrada e saída) e marcs a serem cnsiderads em cada uma das atividades identificadas; Crngrama de prjet Apresenta as dependências entre as tarefas, temp estimad para cada atividade e alcaçã das pessas envlvidas; Mecanisms de mnitraçã e elabraçã de relatóris Identifica s relatóris que devem ser prduzids, quand eles devem ser prduzids e quais mecanisms de mnitrament serã estabelecids Planejament Preliminar O plan de prjet está em cnstante evluçã, cmeçand cm pucs níveis de detalhament e se expandind / revisand da maneira que fr necessária. Cnsiderand um plan inicial, pderia-se destacar as seguintes atividades: Estabelecer Escp d sftware; Discriminar s cass de us e/u s cenáris básics de peraçã que irã nrtear as principais decisões de prjet; Definir uma arquitetura candidata a satisfazer s cenáris básics; Estimar s custs e prazs para prjet cm um td (e realizar estimativas mais detalhadas para a etapa de elabraçã que segue); Estimar ptencial de riscs; Preparar ambiente de api para prjet. Resultad desta etapa: Plan Básic Cletânea de dcuments preparads pel gerente de prjet e pr sua equipe cm bjetiv de prpr e bter a aprvaçã d prjet, tend as seguintes características: Finalidades e frmat extern - Para apresentar prjet visand sua aprvaçã; Limitad a pucs níveis de detalhament (suficiente para a cmpreensã d prjet);

185 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 185 Dcuments/Tópics: Visã d Prdut Declaraçã de Objetiv e Metas OBJETIVO: é pnt fcal d prjet, para qual cnvergem tdas as ações, desde iníci d prjet. Enquant bjetiv d prjet nã estiver definid cm clareza nada deve ser feit, excet prcurar defini-l. O prjet deve pssuir apenas um bjetiv principal, s demais devem ser cnsiderads cm secundáris. Se nã sabes andes ir, cm saberás quand chegar lá? META: resultad intermediári u parcial, quantificad u qualificad, que deve ser alcançad em um praz definid. Mdel de Cass de us/cenáris principais Nã é necessária a realizaçã de uma descriçã cmpleta. Requisits funcinais: Principais Funções (Cnjunt de funções que viabilizam s cass de us principais). Requisits nã funcinais: Desempenh, qualidade, eficácia, eficiência, satisfaçã, intuitividade,... Ambiente: cndições e restrições. Ambiente u cntext de peraçã u de us - Usuáris, equipament, ambiente físic e rganizacinal; Plan de Iterações - Principais fases para cicl de desenvlviment (paradigma), u seja, Mdel d Prcess de Desenvlviment; Estimativas - Definiçã de equipe, custs, prazs, infra-estrutura; Análise de riscs - Identificaçã ds principais riscs, e de um plan para seu mnitrament e administraçã; Crngrama preliminar - Detalhament limitad as principais fases de desenvlviment ESCOPO O Escp é a cntextualizaçã d prblema, uma delimitaçã alt-nível, sem detalhes, das principais funcinalidades que sftware deverá ter, e a identificaçã d ambiente nde mesm estará inserid. O escp precisa ser: Delimitad; Nã-ambígu; Cmpreensível a tds; Nrmalmente escp irá cnter as seguintes infrmações de um prjet: Infrmações principais; Funçã / Desempenh desejads; Restrições / Cnfiabilidade necessárias; Interfaces críticas. A viabilidade d escp deve ser avaliada em cima ds seguintes tópics: Tecnlógic; Financeir; Temp; Recurss. Para mapear / entender escp é precis analisar as seguintes variáveis: As necessidades d cliente; O cntext; O ambiente d prjet; As mtivações d cliente;

186 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 186 As pssíveis mudanças; Entenda que... mesm assim... nada é garantid! O escp, devid sua imprtância tem uma gerência própria: Gerência d Escp. Esta é cmpreendida basicamente pels seguintes itens: Term de Abertura; Planejament d Escp; Detalhament d Escp; Validaçã d Escp; Cntrle de Mudanças d Escp. Dica de Leitura: Revista Mund MP ( ediçã 22, agst/setembr 2008 (dispnível n link de Dwnlad). Artig: Cletar Requisits - Nv Prcess d PMBOK Escp d Prjet x Escp d Prdut Origem: Artig - Cadê Escp d Prjet?, autr: Marcel Jacinth. Link: Amigs de área de T.I., se vcês nunca se precuparam cm este tal de Escp, u até mesm nunca entendeu mesm nde encntrá-l, quem ele é, u cm interpretá-l, simplesmente acalmese! Pis, durante um cicl de desenvlviment de um prjet, vcê e ele, escp, estã temp inteir em cnstante cnfrnt para atingir s bjetivs deste prjet, estes últims determinads e influenciads pelas necessidades de negóci e anseis em geral de clientes e patrcinadres. Ist nã significa que Escp é um adversári, prém é inegável imens desafi que é gerenciál, abrangend definiçã e cntrle d Escp d Prjet e d Prdut. O que, afinal, é Escp d Prjet? E Escp d Prdut? Apresent aqui uma breve definiçã destes cnceits: Escp d Prdut aspects e funções que caracterizam um prdut u serviç. Escp d Prjet trabalh que deve ser feit cm a finalidade de frnecer um prdut de acrd cm s aspects e as funções especificadas. Escp d prjet é mensurad cntra plan d prjet, enquant que escp d prdut é mensurad cntra s requisits d prdut. Ambs s tips de gerenciament de escp devem ser integrads para garantir que trabalh d prjet resulte na entrega d prdut especificad. O gerente de prjet define as atividades e ações, junt a sua equipe, para satisfazer a escp d sistema, ist é, desenvlver e entregar as funcinalidades acrdadas para sistema. Gerenciar escp d prjet e d sistema sã atividades críticas principalmente quand se é frçad a absrver mudanças de requisits, de utilizaçã de recurss, cm rçament, desenvlvedres. Vale muit nestes mments de identificaçã e absrçã de mudanças bm sens d gerente de prjet, principalmente para valrizar as ações de avaliaçã de impact destas mudanças sbre td escp restante d sistema. Pr acas, um nv requisit está influenciand em determinads requisits de frma a mudar a execuçã destes? Existem requisits frtemente dependentes de um dad requisit que está sfrend mudanças? Desde iníci d prjet é salutar que gerente tenha a percepçã ds requisits mais instáveis, e ds que ainda carecem de mair definiçã e cmpreensã entre a equipe e cliente. Enfim, cntrlar efetivamente s requisits d sistema, e a partir dist prpr um planejament de prjet, nde está caracterizada a estratégia de atender a estes requisits, a cnstruir sistema acrdad, passa pr uma visã criterisa e priritária ns escps de sistema e de prjet.

187 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: Definiçã de Escp de Prjet Origem: Artig - Quer definir Escp de meu Prjet!, autr: Marcel Jacinth. Link: Cmpanheir(a) de desenvlviment e gerenciament de prjets, esper que títul deste artig seja a traduçã d que está instigand sua cnsciência, quand, pr mais um dia de trabalh, depara-se cm um verdadeir caminhã de infrmações cnflitantes, desvis, crreções, demandas, pendências, gerand stress e pirand ainda mais a já nã tã perfeita cmunicaçã que (prventura) existe na equipe. Em um determinad mment de um prjet, n qual s cenáris de riscs já fram deflagrads, e, resumind, váris prblemas já crreram, e várias bmbas já estã prestes a expldir, nã é que aparece um sensacinal prfissinal, que simplesmente declara: é clar que estams cm tdas essas dificuldades, nã tem nada definid!!! Calma, muita calma, pis paciência e esperança ainda precisam perdurar para nss própri bem... Brincadeiras filsóficas a parte, vams tentar visualizar um cenári nde nã acreditams muit que pssa existir um efetiv cntrle d Escp: a gerenciar um prjet que tem cm mair priridade cumprir um praz cngelad, custe que custar, nã só em terms financeirs, muit mais até em verdadeirs sacrifícis de esfrç da equipe, refletind nas hras extras regadas de pizza fria e refrigerante quente, e fins de semana de sl send aprveitads dentr d escritóri, prque cliente quer sistema em prduçã em uma data certa... E agra? Nã existe uma técnica mágica, mas que deve ser cnstante é a disciplina de tds da equipe, sem exceçã. Ora, disciplina n cumpriment de melhres práticas de gerenciament de prjet, seguind bas práticas riginárias na própria rganizaçã, enfim, nã pdems abrir espaç para imprviss, gatilhs, e jeitinhs. Ist nã garante sucess de um prjet de T.I. Antes de mais nada, se a equipe nã cnseguir executar uma primeira definiçã d escp d sistema, cm estará bem respaldada para gerar um bm primeir escp de prjet? É vital a identificaçã apurada de fntes de requisits, e de pessas que estã efetivamente cm pder de validar requisits, e executar atividades de levantament, análise e especificaçã de requisits, a fim de bter destes validadres, através de suas sugestões, críticas e validações prpriamente ditas, desenh prgressiv d escp d sistema que a equipe precisa entregar. Daí, gerente cmeça a ter capacidade de vislumbrar se precisará cntratar mais prfissinais, se precisará usar de mdels de cicl de vida cm prttipaçã, espiral, u iterativ, enfim, efetivamente definir escp d prjet, inclusive estimativas de praz e cust cm mair acurácia, mirand n que efetivamente será cumprid, ist é, realizad. O interessante é que nã basta escrever pr escrever s requisits. É impressinante cm existe uma altíssima frequência deste hábit de, simplesmente, escrever suficiente para própri escritr entender, e smente ele entender, d que se trata aquele requisit. O gerente precisa sensibilizar cnstantemente a sua equipe para gerar artefats de prjet de frma clara e cmpleta, perante tds s envlvids d prjet. A percepçã d atendiment as níveis de qualidade de um prjet está diretamente ligada à capacidade e imprtância que gerente u líder de equipe efetivamente aplicam para a definiçã de escps de prjet e de sistema, junt as membrs da equipe, e junt a clientes, patrcinadres, usuáris finais e demais envlvids. E nã há cm cbrar disciplina ds membrs da equipe sem terms própri ambiente rganizacinal cm nrmas, padrões e prcesss, baseads em melhres práticas de mercad, devidamente implantads. Cm iss tud expst, pdems cntemplar que, a analisarms tud que pde estar influenciand cumpriment d escp de um prjet de desenvlviment de sistema, pde-se determinar sluções que nã necessariamente serã atividades e ações descritas em um crngrama.

188 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: ESTRUTURA ANALÍTICA DE PROJETO (EAP) Uma das atividades d Planejament é decmpr as grandes tarefas em tarefas pequenas. Iss significa encntrar partes identificáveis das tarefas, bem cm Expedições e Marcs, que pdem ser usads para medir prgress. A Estrutura Analítica d Prjet (EAP) u Estrutura de Decmpsiçã de Trabalh (EDT), u Wrk Breakdwn Structure (WBS), é nrmalmente uma estrutura de árvre. O nível mais elevad de decmpsiçã geralmente se identifica cm mdel de prcess usad na rganizaçã. O próxim nível de decmpsiçã pde se identificar cm as atividades d mdel de prcess da rganizaçã. Níveis mais baixs sã usads para subdividir as tarefas em utras menres e mais gerenciáveis. A seguir estã as regras para se cnstruir uma estrutura aprpriada de decmpsiçã de trabalh: 1. A WBS deve ser uma estrutura de árvre Nã devem existir laçs nem cicls na WBS. Ações iterativas devem ser mstradas n mdel de prcess; 2. Tda tarefa e descriçã expedida devem ser cmpreendidas e nã-ambíguas - O prpósit da WBS é a cmunicaçã entre membrs da equipe. Se s membrs da equipe interpretarem mal que a tarefa u dcument sugere fazer, haverá prblemas; 3. Tda tarefa deve ter um critéri de cmpletude (sempre alg a expedir) Deve existir uma maneira de decidir quand uma tarefa está cmpleta, prque subtarefas que nã pssuem um final definid incentivam expectativas de fals prgress. Essa decisã é chamada de Critéri de Cmpletude. Pde ser uma expediçã, pr exempl, um prjet cmplet. Nesse cas, uma revisã de pares pde decidir se está cmplet; 4. Tds s artefats devem ser identificads Um artefat tem que ser prduzid pr alguma tarefa, u ele nã será prduzid; 5. Términ psitiv de uma tarefa deve implicar n términ de uma tarefa cm um td O prpósit desse fluxgrama de decmpsiçã de tarefa é identificar as subtarefas necessárias para cmpletar a tarefa tda. Se imprtantes tarefas u artefats estã faltand, a tarefa cmpleta nã será alcançada; 6. Ela é resultad de um trabalh de equipe, em que tds s aspects d prjet devem estar representads; 7. Ela deve explicitar a Estrutura de Decmpsiçã d Prdut (EDP) e as tarefas técnicas, gerenciais e administrativas necessárias para btê-l. Principais bjetivs de uma WBS: Melhrar a precisã das estimativas (cust, esfrç, recurss); Atribuir respnsabilidades; Definir uma Organizaçã Hierárquica; Servir cm pnt de partida e a referência básica para a rganizaçã de tdas as áreas relacinadas a prjet, servind assim cm um guia para s envlvids. A EAP cnsiste em uma criterisa decmpsiçã tant d prdut cm ds prcesss para btê-l, bem cm das tarefas administrativas e/u gerenciais necessárias. Ela cstuma ser apresentada de 02 maneiras: Estrutura de Árvre; Estrutura de Tópics (lista / tabela). As duas frmas sã equivalentes. A EAP pde ser cnstruída cm s seguintes móduls: Estrutura de Decmpsiçã d Prdut (EDP) - Cm funções básicas a serem atribuídas a prjet, estã as de desenvlver tdas as partes, integrá-las sucessivamente até ser atingid bjetiv d prjet, que é desenvlviment d prdut. A EDP representa prdut dividid em suas partes lógicas, inter-relacinadas hierarquicamente, cm s itens u cmpnentes mais elementares na parte inferir da EDP, send sucessivamente integrads até se chegar a prdut final;

189 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 189 Estrutura de Gestões Específicas - Além das funções diretamente ligadas a desenvlviment d prdut, há utras, de caráter gerencial, e gerente pderá atribuí-las a auxiliares imediats, tais cm: qualidade, cnfiguraçã, interfaces, dcumentaçã, etc. Estas gestões específicas pdem ser agrupadas em um módul paralel à EDP; Estrutura Administrativa - Pr mair que seja api prestad pela rganizaçã a prjet, sempre haverá encarg de fazer as ligações cm diverss órgãs para tratar d flux de recurss materiais e financeirs, de pessal, relatóris e prestações de cntas, etc. Pde ser elabrad um módul cmplementar as 2 anterires, e que cuidará justamente desta parte administrativa. A seguir é apresentad um exempl simples, cm as etapas d prcess de desenvlviment d sftware. Árvre Lista 0.0 Prjet Exempl 1.0 Gestã 1.1 Qualidade 1.2 Cnfiguraçã 2.0 Desenvlviment 2.1 Levantament de Requisits 2.2 Análise 2.3 Prjet 3.0 Aquisiçã 2.4 Implantaçã 2.5 Validaçã 2.6 Implantaçã

190 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: DESENVOLVIMENTO DO CRONOGRAMA DO PROJETO Origem: Engenharia de Sftware, Ian Smmerville, 8a. Ediçã; Engenharia de Sftware, Wilsn de Pádua Paula Filh, 3ª. Ediçã. Elabrar um crngrama de prjet, requer, entre utras tarefas: Dividir prjet em tarefas (elabrar a WBS) e estimar temp e recurss necessáris para cmpletar cada tarefa (realizar Alcaçã); Organizar tarefas simultâneas para fazer us timizad da frça de trabalh; Minimizar as dependências de tarefas para evitar atrass causads pel fat de uma tarefa ter de aguardar a finalizaçã de utra; É dependente da intuiçã e experiência ds gerentes de prjet. Um pssível prcess de desenvlviment d crngrama d prjet está abaix destacad: Alguns prblemas encntrads n desenvlviment de um crngrama estã abaix destacads: É precis fazer uma estimativa das dificuldades e ds prblemas; pr essa razã, é difícil estabelecer cust de uma sluçã; A prdutividade nã é prprcinal a númer de pessas que trabalham em uma tarefa; A inclusã de pessas em um prjet atrasad, atrasa ainda mais devid as verheads de cmunicaçã; O inesperad sempre crre. Deve-se sempre cnsiderar a cntingência n planejament Diagramas de Barras e Redes de Atividades Sbre Diagramas de Barras e Redes de Atividades pde ser dit seguinte: Sã ntações gráficas usadas para ilustrar crngrama de prjet; Mstram a quebra d prjet em tarefas que nã devem ser muit pequenas. Elas devem levar aprximadamente uma u duas semanas; Redes de Atividades mstram as dependências entre as tarefas e Caminh Crític; Diagramas de Barras mstram Crngrama em cntraste cm temp d calendári. Deve-se, inicialmente, determinar as atividades, suas durações e as respectivas interdependências. Também pde ser interessante identificar s Marcs que cnfiguram cada uma das atividades definidas. Um exempl diss pde ser encntrad abaix:

191 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 191 Essa tabela tem suas tarefas identificadas a partir da WBS cnstruída para prjet. As dependências entre as tarefas devem ser estabelecidas de acrd cm a dispnibilizaçã ds recurss, e a necessidade de sequenciaçã entre as tarefas. A duraçã é estimada de acrd cm as técnicas selecinadas pel gerente. Para melhr destacar as dependências existentes entre as atividades deve-se elabrar uma Rede de Atividades, crrespndente à tabela de durações e dependências. Prsseguind n exempl acima pderia-se ter a seguinte rede: Cmplementar à Rede de Tarefas pde ser desenvlvid um Diagrama de Barras (u Gráfic de Gantt), que mstra claramente as datas de iníci e fim de cada atividade. Tal diagrama também

192 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 192 pde apresentar a flexibilidade de términ nas datas de cada atividade (na figura abaix iss é destacad cm uma barra smbreada). As alcações demnstradas acima fcam nas atividades que serã desenvlvidas em um prjet exempl. Além d Crngrama de Atividades também é precis cnsiderar a Alcaçã de Recurss, ist é, identificar quem será respnsável pelas atividades. Um exempl de alcaçã de recurss está identificad na figura abaix. É a partir da tabela de atividades, durações e dependências, bem cm das alcações de recurss identificadas que sã estabelecidas as datas de iníci e fim das atividades (send que a primeira data é a data de iníci d prjet). O cálcul de tais datas nrmalmente é realizad através de alguma ferramenta e utiliza PERT / CPM (Prgram Evaluatin and Review Technique / Critical Path Methd).

193 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 193 Para crret cálcul de tais datas também é necessári estabelecer um calendári para prjet. Pde ser precis que cada recurs alcad tenha um calendári própri, se huver hráris diferenciads. E pde ser que recurs deva dividir seu temp, se estiver alcad em mais de uma tarefa Caminh Crític Origem: Wikipédia, a enciclpédia livre. Caminh Crític é um term criad para designar um cnjunt de tarefas vinculadas a uma u mais tarefas que nã têm margem de atras. Matematicamente, sabems que uma tarefa é crítica quand temp mais ced da tarefa é igual a temp mais tarde que a tarefa pde ter sem alterar a data final d prjet. O valr d temp mais ced (Time Earlier) e d temp mais tarde (Time Later) pde ser calculad através d diagrama de Rede AON (Activity On Ndes). O caminh crític é a sequência de atividades que devem ser cncluídas nas datas prgramadas para que prjet pssa ser cncluíd dentr d praz final. Se praz final fr excedid, é prque n mínim uma das atividades d caminh crític nã fi cncluída na data prgramada. É imprtante entender a sequência d caminh crític para saber nde vcê tem e nde vcê nã tem flexibilidade. Pr exempl, vcê pderá ter uma série de atividades que fram cncluídas cm atras, n entant, prjet cm um td ainda será cncluíd dentr d praz, prque estas atividades nã se encntravam n caminh crític. Pr utr lad, se seu prjet está atrasad, e vcê alcar recurss adicinais em atividades que nã estã n caminh crític nã fará cm que prjet termine mais ced. O Métd d Caminh Critic (CPM - Critical Path Methd) é um ds váris métds de análise de planejament de prjets. O CPM está diretamente ligad n planejament d temp, cm bjetiv de minimizar temp da duraçã ttal d prjet. As atividades u tarefas críticas definem assim caminh crític, u seja, revela a sequência de tarefas que cndicinam a duraçã ttal d prjet. Cm ist, frnece também infrmaçã útil para que cm iss se pssa elabrar um prjet atendend as recurss necessáris em funçã das restrições aliadas às tarefas críticas, cnseguind entã uma equilibrada gestã de recurss pr td prjet (Tavares et al., 1996, p. 109). TAVARES, L. Valadares; OLIVEIRA, Rui Carvalh; THEMIDO, Isabel Hall; CORREIA, F. Nunes - Investigaçã Operacinal. Nva Irque: McGraw Hill, ISBN OBS.: Em anex a tal material se encntram dispníveis dis exempls de Plans de Prjet. O primeir deles, elabrad pel prfessr Ricard Falb (UFES) apresenta detalhes interessantes sbre prcess definid n prjet e a realizaçã de estimativas. O segund deles, elabrad pel prfessr Edsn ds Sants Crdeir (material dispnível na Internet) segue a estrutura apresentada pr Ian Smmerville (2007), send um mdel mais simples.

194 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: GESTÃO DE RISCOS Origem: Engenharia de Sftware, Ian Smmerville, 8ª. Ediçã; Internet. Um risc é a prbabilidade de que alguma circunstância adversa crrerá. Onde estã s riscs? N futur... que pde ser duvids e causar mudanças; Nas mudanças... que pdem ser inúmeras e causar decisões; Nas decisões... que pdem nã ser as mais crretas. Durante a realizaçã d planejament de prjet, inclusive durante a cnstruçã d crngrama e estabeleciment de estimativas, deve-se sempre ter em mente s riscs as quais prjet está sujeit. Assim, é necessári realizar uma gestã de riscs. Riscs em Engenharia de Sftware: N futur d ambiente intern e extern... mercad, tecnlgia, ecnmia, gvern; Nas mudanças d ambiente... ns requisits ds clientes, em ambientes tecnlógics, equipaments, plítica ecnômica e tecnlógica, leis e prgramas de api a P&D, rçaments; Nas decisões... O que prduzir? Cm que métds e ferramentas? Cm que equipe? Cm que nível de qualidade? Cm qual rçament? A Gestã de Riscs está relacinada à identificaçã de riscs e à elabraçã de plans para minimizar esses efeits em um prjet. Categrias de riscs: Os Riscs de Prjet afetam crngrama u s recurss; Os Riscs de Prdut afetam a qualidade u desempenh d sftware que está send desenvlvid; Riscs de Negóci afetam a rganizaçã que desenvlve u adquire sftware. Obviamente, alguns fatres pdem afetar mais de um element (alguns riscs pdem se encaixar em mais de uma categria). Pr exempl, se um prgramadr experiente abandnar prjet: Pderá ser um risc de prjet, prque a entrega pde atrasar; Pderá ser um risc a prdut, prque substitut pde nã ser tã experiente, u nã entender ttalmente códig e cmeter errs. Alguns ds riscs mais cmumente encntrads estã definids na tabela abaix.

195 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 195 O Prcess de Gestã de Riscs basicamente envlve s seguintes estágis, e artefats: Identificaçã de Riscs - Identifica s riscs de prjet, de prdut e de negóci; Etapa de se fazer perguntas; Embra alguns riscs sejam mais prváveis que utrs, inicialmente é precis identificar tds eles, u pel mens, busca-se identificar a mairia. O ideal é cnsiderar mesm aqueles que aparentemente têm muit puca prbabilidade de se cncretizarem; O prcess de identificar riscs pde ser feit: Individualmente pel gerente, cm base em suas experiências pessais; u Em grup, cas em que a equipe pde discutir idéias; É precis identificar qual mais adequad a prjet. Pde-se também utilizar uma lista prnta de riscs gerais e verificar quais deles se aplicam a prjet em questã; Há pel mens seis tips de riscs que pdem surgir, cnfrme destacads na tabela abaix. O gerente pde analisar cada um deles separadamente, prcurand identificar s riscs d atual prjet.

196 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 196 Pr exempl, para identificar riscs de pessal, ele pderia fazer as seguintes perguntas: Sã as melhres pessas dispníveis? As pessas têm a cmbinaçã certa de habilidades? Há pessas suficientes à dispsiçã? O pessal está cmprmetid cm tda a duraçã d prjet? Algum membr d pessal d prjet estará trabalhand smente em temp parcial neste prjet? O pessal tem as expectativas certas sbre trabalh que tem à mã? Os membrs d pessal receberam necessári treinament? A rtatividade entre pessal será baixa bastante para permitir cntinuidade? Análise de Riscs - Avalia a prbabilidade e as cnsequências desses riscs. Avaliar a prbabilidade e a seriedade (efeit) de cada risc; Essa avaliaçã nrmalmente acntece em 4 etapas: Estabeleciment de uma escala de prbabilidade de riscs; Delineament das cnsequências de cada risc; Estimativa d impact de cada risc sbre prjet e prdut; Antaçã de uma medida de cnfiabilidade da avaliaçã ds riscs; A prbabilidade pde ser muit baixa, baixa, média, alta e muit alta; Os efeits de risc pderiam ser catastrófics, séris, tleráveis u insignificantes; Estabeleciment de uma Escala de Prbabilidades A escala de prbabilidades pde ser definida de diversas frmas. Pr exempl, pdese simplesmente avaliar cada risc identificad n primeir estági cm Prvável u Imprvável ; N entant, na prática é quase impssível prever tã precisamente se risc vai acntecer u nã; Pderia-se também dar uma avaliaçã numérica, mas é igualmente difícil estabelecer um valr exat; Prtant, a abrdagem mais adequada é avaliar cada risc utilizand uma escala qualitativa, cm intervals de prbabilidades. Pr exempl: Altamente imprvável; Imprvável; Mderad; Prvável; Altamente prvável;

197 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 197 Outr exempl de escala é: Muit baixa (mens de 10% de prbabilidade); Baixa (10 a 25%); Mderada (25 a 50%); Alta (50-75%); Muit alta (mais de 75% de prbabilidade); Além da experiência pessal, gerente pde utilizar dads de prjets passads para chegar a um valr numéric de prbabilidade. Pr exempl, supnha a análise de 45 prjets realizads anterirmente pela empresa; Se desses 45, 37 prjets experimentaram dbr de mudanças feitas pel cliente d que as riginalmente previstas, a prbabilidade de que um nv prjet experimente númers de mudança excessivs é 37/45 = 0,82. Ou seja, 82% de prbabilidade; Obviamente, nem sempre esse métd é mais adequad; Pr exempl, se ns meus prjets anterires s clientes eram de um tip A e neste prjet s clientes sã d tip B, entã as medidas anterires nã sã muit úteis. Pr exempl, se ns 45 prjets anterires eu tinha clientes leigs em infrmática e agra tenh clientes experts, iss certamente irá influenciar pedid de mudanças. Delineament das cnsequências de cada risc Inicialmente deve-se pensar nas cnsequências imediatas cas cada risc acnteça; Pr exempl, supnhams exempl de um desenvlvedr abandnand prjet. As cnsequências imediatas sã, entre utras: Prcess de seleçã para cntratar nv desenvlvedr; Temp de treinament d nv desenvlvedr; Destacar um membr da equipe para realizar treinament d nv desenvlvedr; Gasts cm quebra de cntrat; Gasts cm nv cntrat. Impact ds riscs A partir das cnsequências listadas, pde-se prever impact de cada risc; Três fatres afetam impact: As cnsequências listadas na segunda etapa (a natureza d risc); Seu escp a gravidade d risc + a distribuiçã glbal (quant d prjet será afetad u quants clientes serã prejudicads); Seu temp de crrência pr quant temp se sentirã s impacts d risc? Analisand esses três fatres, pde-se entã gerar uma lista cm três elements: risc + prbabilidade + impact Pde-se entã criar uma tabela rdenada de acrd cm as maires prbabilidades u de acrd cm s impacts mais graves. A análise de riscs resulta, assim, em uma tabela, cm a apresentada a seguir.

198 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 198 Há autres que recmendam identificar e mnitrar s dez maires riscs, mas bviamente nem sempre esse prcediment é mais adequad. Depende d prjet; Naturalmente, também, a lng d prjet a prbabilidade u avaliaçã d impact pde se mdificar, à medida que mais infrmações sbre s riscs se trnam dispníveis e s plans de gerenciament cmeçam a ser implementads; Prtant, essa tabela deve ser re-avaliada e atualizada a lng d prcess de desenvlviment d sftware. Cnfiabilidade da Avaliaçã Após realizar s 3 passs anterires, gerente deve assinalar, para cada risc, qual é a cnfiabilidade da avaliaçã; Ou seja, se ele tinha muits dads e infrmações sbre um determinad risc, entã a cnfiabilidade é alta; Pr utr lad, se ele tinha pucas infrmações e teve que chutar muita cisa, a cnfiabilidade é baixa; É imprtante assinalar a cnfiabilidade, pis assim gerente se lembrará de vltar a analisar s riscs cm cnfiabilidade baixa, assim que mais dads frem send dispnibilizads; Além diss, ele já sabe que nã pde cnfiar muit na prbabilidade assciada a esses riscs. Planejament de Riscs - Elabra plans para evitar u minimizar s efeits ds riscs; Cnsiderar cada risc e desenvlver uma estratégia para gerenciar esse risc. Esse planejament cnsiste em tmar s riscs cnsiderads de mair impact u cm mair prbabilidade de crrer e definir estratégias de cm agir cas algum deles realmente venha a crrer. Existem três categrias de estratégias: Estratégias Preventivas - A prbabilidade de risc crrer é eliminada. Sã aquelas estratégias tmadas pel gerente de prjet de frma a evitar que s riscs crram;

199 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 199 Pr exempl, supnha que exista risc de se utilizar cmpnentes defeituss. Para evitar esse risc, pde-se pririzar a cmpra apenas de cmpnentes cm cnfiabilidade recnhecida (ainda que mais cars); Estratégias de Minimizaçã - O impact d risc sbre prjet u prdut será reduzid. Sã aquelas estratégias tmadas pel gerente de prjet para minimizar s impacts d risc; Pr exempl, supnha risc de denças em equipe. Para evitar um grande prblema cas iss crra, a estratégia é rganizar a equipe de maneira que haja sbrepsiçã de trabalh e, prtant, as pessas cmpreendam as tarefas umas das utras; Estratégias de Cntingência - Sã plans para lidar cm s riscs, cas eles crram. Sã estratégias que sã clcadas em prática para cnter um risc prestes a crrer. Em utras palavras, estratégias para reverter uma situaçã de risc; Pr exempl, supnha risc de a rganizaçã sfrer prblemas financeirs. Nesse cas, é útil que gerente de prjet tenha prnt um dcument infrmativ para a alta gerência, mstrand cm prjet presta uma cntribuiçã muit imprtante para s bjetivs da empresa. Para exemplificar melhr, supnha que em uma rganizaçã, na fase de avaliaçã ds riscs fi identificada uma prbabilidade de 70% de que a rtatividade de funcináris seja elevada, cm um pssível aument de 12% ns custs e extensã d crngrama em 15%. Sabend iss, gerente tma as seguintes prvidências: Reúne-se cm pessal atual para tentar determinar as causas da rtatividade de pessal (cndições de trabalh ruins, saláris baixs, etc); Tma prvidências para eliminar aquelas causas que estejam sb seu cntrle, antes que prjet se inicie; Organiza equipes de prjet de frma que as infrmações a respeit de cada atividade sejam amplamente difundidas; Define padrões de dcumentaçã e estabelece mecanisms para se certificar de que s dcuments sejam desenvlvids de maneira adequada; Realiza revisões de td trabalh cm s clegas de frma que mais de uma pessa esteja a par das atividades desenvlvidas; Define um membr d pessal que sirva de backup para cada prfissinal mais crític. É fácil perceber que clcar essas estratégias em prática também pde requerer cust e temp. Pr exempl, temp gast para prver backup de um prfissinal crític custa dinheir; Prtant, gerente deve avaliar se s custs cmpensam s benefícis; N exempl acima, vims que se huver alta rtatividade de pessal cust d prjet pderá aumentar em até 15%. Prtant, se as estratégias para evitar/minimizar esse risc tiverem um cust de implementaçã de frma que cust excedente seja mair d que 15%, entã bviamente nã vale a pena levá-ls adiante; Deve-se levar em cnsideraçã também que talvez apenas uma parte das estratégias tenha alt cust. Nesse cas, em vez de simplesmente nã utilizar estratégias, deve-se apenas selecinar as de mais baix cust. Cncluind: Uma vez que se tenha realizad a análise de riscs deve-se identificar estratégias para eliminar / minimizar esses riscs, cm está exemplificad na tabela a seguir.

200 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 200 Mnitraçã de Riscs - Acmpanha s riscs a lng d prjet. Avaliar, regularmente, cada um ds riscs identificads para decidir se está u nã se trnand mens u mais prvável de crrer; Avaliar também se s efeits d risc mudaram; Cada risc-chave deve ser discutid nas reuniões de acmpanhament d prgress. Deve-se estar atent a fatres que frneçam indícis a respeit da prbabilidade d risc e seus efeits. Esses fatres sã dependentes ds tips de riscs. Alguns fatres que pdem ser cnsiderads estã destacads na tabela a seguir.

201 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: GESTÃO DE PESSOAS Origem: Engenharia de Sftware, Ian Smmerville, 8ª. Ediçã. Deve-se sempre ter em mente que um prjet de sftware envlve um grup variad de pessas, e é precis prvidenciar para que relacinament entre essas pessas (e delas mesmas cm própri prjet), seja melhr pssível, enquant prjet durar. O gerenciament de pessal envlve a realizaçã de gerenciament n que se refere a trabalh cm indivídu u em grups. Pessas n Prcess As pessas sã patrimôni mais imprtante de uma rganizaçã; As tarefas de um gerente sã essencialmente rientadas às pessas. A mens que haja cmpreensã entre as pessas, gerenciament será um fracass; O gerenciament inadequad de pessas é uma das maires causas de falha de prjet. Fatres de Gerenciament de Pessas Cnsistência - Os membrs de uma equipe devem ser tds tratads de maneira unifrme, sem favrits u discriminaçã; Respeit - Os diferentes membrs de uma equipe têm habilidades diferentes, e essas diferenças devem ser respeitadas; Inclusã - É envlver tds s membrs de uma equipe e ter certeza de que as visões das pessas sã cnsideradas; Hnestidade - Em um prjet, vcê deve ser sempre hnest sbre que está ind bem e que nã está SELEÇÃO DE PESSOAL Uma imprtante tarefa de gerenciament de prjet é a Seleçã da Equipe, ist é, a definiçã ds membrs que farã parte da equipe; As infrmações necessárias pdem ter diferentes rigens. Entre elas: Frnecidas pels candidats; Obtidas pr mei de entrevistas e cnversas cm s candidats; Recmendações e cmentáris de utras pessas que cnhecem u que trabalharam cm s candidats. A seguir é apresentad um estud de cas envlvend seleçã de pessal.

202 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 202 Lições que pdem ser btidas a partir d estud de cas acima: Em uma empresa, s gerentes pdem desejar nã perder pessas para um nv prjet. O envlviment em temp parcial pde ser inevitável; Habilidades, tais cm prjet de UI e interface de hardware estã em baixa ferta; Recém-frmads pdem nã ter habilidades específicas, mas pde ser uma maneira de intrduzir nvas habilidades; Prficiência técnica pde ser mens imprtante que habilidades sciais, dependend d prjet. A tabela a seguir apresenta alguns fatres de seleçã de pessal.

203 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: MOTIVAÇÃO DE PESSOAS A mtivaçã está relacinada à rganizaçã d trabalh e d ambiente de trabalh de frma que as pessas se sintam estimuladas a trabalhar tã eficientemente quant pssível; Um ds papéis mais imprtantes de um gerente é mtivar as pessas que trabalham em um prjet; A mtivaçã é um tópic cmplex, mas ela aparece em seus diferentes tips de mtivações baseads em: Necessidades básicas (pr exempl, aliment, sn, etc.); Necessidades pessais (pr exempl, respeit, aut-estima); Necessidades sciais (pr exempl, ser aceit cm parte de um grup). Existem várias terias sbre mtivaçã de pessas. Uma das mais cnhecidas é a Teria da Hierarquia de Necessidades Humanas, e que está apresentada na figura a seguir.

204 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 204 É estabelecid que primeir deve-se satisfazer as necessidades mais básicas, e apenas após uma necessidade mais básica ter sid satisfeita passa-se para a necessidade seguinte. Algumas indicações de nde gerente deve investir: Scial (fazer parte de um grup) - Frnecer lugares cmuns. Permitir cmunicações infrmais; Aut-estima (ser recnhecid pel grup) - Recnheciment das realizações. Remuneraçã aprpriada; Aut-realizaçã (desenvlviment pessal) - Treinament (as pessas querem aprender mais). Respnsabilidade. A seguir é apresentad um estud de cas envlvend mtivaçã de pessas. A hierarquia de necessidades é, prvavelmente, uma breve simplificaçã da mtivaçã na prática, pis cnsidera apenas lad pessal da questã. A mtivaçã deve também levar em cnta s diferentes tips de persnalidade: Orientad a tarefas - A mtivaçã para realizar trabalh é trabalh em si; Aut-rientads - O trabalh é um mei de atingir as metas pessais pr exempl, ficar ric, jgar tênis, viajar, etc; Orientad a interações - A principal mtivaçã é a presença e as ações de seus clegas de trabalh. As pessas vã a trabalh prque gstam.

205 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 205 Balanç da mtivaçã Mtivações individuais sã cnstituídas de elements de cada classe; O balanç pde mudar dependend de circunstâncias pessais e de events externs; Cntud, as pessas nã sã smente mtivadas pr fatres pessais, mas também pr serem parte de um grup u cultura; As pessas cm trabalh gratificante vã a trabalh prque elas sã mtivadas pelas pessas cm quem elas trabalham e pel trabalh que realizam GERENCIAMENTO DE GRUPOS A mair parte da engenharia de sftware é uma atividade de grup. O crngrama de desenvlviment para a mairia ds prjets de sftware nã triviais é tal que eles nã pdem ser cmpletads pr uma pessa trabalhand szinha. A interaçã d grup é uma chave determinante d desempenh de grup, e cnsequentemente sucess d prjet. Um gerente de prjet se precupa cm grup td e cm cada membr da equipe individualmente. A flexibilidade na cmpsiçã d grup é limitada. Os gerentes devem fazer melhr que pdem cm as pessas que estiverem dispníveis. Fatres que influenciam trabalh em grup. Cmpsiçã d Grup. Existe equilíbri cert entre as habilidades, experiências e persnalidades na equipe? Um grup cmpst pr membrs que cmpartilham a mesma mtivaçã pde ser prblemátic. Se as mtivações sã Individuais: Orientad a tarefas tds querem fazer suas próprias cisas; Aut-rientad tds querem ser chefe; Orientad a interações muita cnversa, trabalh insuficiente. Pr utr lad, se as mtivações sã Cmplementares: Orientad a tarefas mais frtes tecnicamente; Aut-rientad impulsinam trabalh para a frente; Orientad a interações facilitam a cmunicaçã. Um grup eficiente tem um balanç de tds s tips, em vez de só habilidades técnicas. Iss pde ser difícil de atingir, pis s engenheirs de sftware sã, frequentemente, rientads a tarefas; Pessas rientadas a interações sã muit imprtantes quand pdem detectar e diminuir eventuais tensões. Prsseguind n estud de cas iniciad anterirmente, tem-se seguinte quadr:

206 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 206 Se nã huver persnalidades cmplementares, gerente precisará de mair atuaçã nesse sentid. Quant mais as infrmações frem cmpartilhadas, menr será a prbabilidade de que se tme decisões individuais. Liderança de Grup. O líder d grup dirige técnica e administrativamente a equipe (pdend essas duas direções serem, inclusive, assumidas pr membrs diferentes); A liderança depende d respeit e nã d status d titular; Pde haver ambs, um líder técnic e um administrativ; A liderança demcrática é mais eficiente que a liderança autcrática na mair parte das situações. Depende também da situaçã e da própria experiência da equipe. Cesã d Grup. O grup pensa em si cm uma equipe, em vez de cm um cnjunt de indivídus que trabalham junts? Em um grup ces s membrs cnsideram grup mais imprtante que qualquer indivídu pertencente a ele Frnecem api e ajuda mútus; As vantagens de um grup ces sã: Os padrões de qualidade d grup pdem ser desenvlvids; Os membrs d grup trabalham rigrsamente junts e, assim, as inibições causadas pela ignrância sã reduzidas; Os membrs da equipe aprendem e cnhecem trabalh uns ds utrs; Uma prgramaçã sem egísm, nde s membrs se empenham para melhrar prgrama uns ds utrs, pde ser praticada O códig-fnte nã pertence a um, mas a tds. Prsseguind n estud de cas, tem-se seguinte quadr: Desenvlviment Ces. A cesã é influenciada pr fatres, tais cm a cultura rganizacinal e as persnalidades n grup; A cesã pde ser encrajada pr mei de: Events sciais;

207 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 207 Desenvlviment de uma identidade e um territóri de grup; Atividades de frmaçã de equipes explícitas; A abertura de infrmações é uma maneira simples de assegurar que tds s membrs d grup se sintam parte dele. Lealdade a grup. Os membrs de grup tendem a ser leais em grups cess; O pensament de grup (grupthink) é a preservaçã d grup, independente de cnsiderações técnicas u rganizacinais; O gerenciament deve agir psitivamente para evitar pensament de grup (pis pde-se tentar islar grup), frçand envlviment extern cm cada grup. Cmunicaçã d Grup. Os membrs d grup se cmunicam eficazmente uns cm s utrs? A cmunicaçã d grup é essencial para um trabalh em grup eficiente; As infrmações devem ser trcadas sbre status d trabalh, as decisões de prjet e as mudanças nas decisões prévias; Bas cmunicações também frtalecem a cesã d grup, uma vez que prmvem entendiment; Sbre um grup devem ser cnsiderads s seguintes itens: Tamanh d grup. Em grups maires, mais difícil é as pessas se cmunicarem cm utrs membrs d grup; Estrutura d grup. A cmunicaçã é melhr em grups estruturads infrmalmente d que em grups estruturads hierarquicamente; Cmpsiçã d grup. A cmunicaçã é melhr quand existem tips diferentes de persnalidade em um grup e quand s grups sã misturads, a invés de um únic sex; O ambiente físic de trabalh. Uma ba rganizaçã d lcal de trabalh pde auxiliar e encrajar as cmunicações. Organizaçã d Grup. O grup está rganizad de maneira que cada pessa se sinta valrizada e satisfeita cm seu papel n grup? Grups pequens de engenharia de sftware sã, geralmente, rganizads infrmalmente, sem uma estrutura rígida; Para prjets de grande prte, pde existir uma estrutura hierárquica nde grups diferentes sã respnsáveis pr diferentes subprjets; Grups infrmais O grup age cm um td e chega a um cnsens sbre as decisões que afetam sistema; O líder de grup serve cm uma interface externa, mas nã alca itens específics de trabalh. A invés diss, trabalh é discutid pel grup cm um td, e as tarefas sã alcadas de acrd cm a habilidade e a experiência de cada um; Essa abrdagem é bem sucedida para grups nde tds s membrs sã experientes e cmpetentes.

208 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 208 Grups de Extreme Prgramming. Grups de Extreme Prgramming sã variantes de uma rganizaçã infrmal e demcrática; Em grups de Extreme Prgramming, algumas decisões de gerenciament sã repassadas para s membrs d grup; Os prgramadres trabalham em pares e assumem uma respnsabilidade cletiva pel códig que é desenvlvid. Equipes de prgramadr-chefe. Cnsistem em um núcle de especialistas auxiliad pr utrs adicinads a prjet, quand necessáris; A mtivaçã pr trás d seu desenvlviment é a grande diferença de habilidades entre prgramadres; Equipes de prgramadr-chefe frnecem um api de ambiente para prgramadres muit capazes serem respnsáveis pr td desenvlviment d sistema; Prblemas: Essa abrdagem de prgramadr-chefe, em frmas diferentes, fi bem sucedida em algumas implementações. Cntud, ela sfre de uma série de prblemas: Prjetistas e prgramadres talentss sã difíceis de encntrar. Sem um pessal excepcinal nesses papéis a abrdagem falhará; Outrs membrs d grup pdem se ressentir d prgramadr-chefe, que ganha crédit d sucess e, assim, pde, deliberadamente, nã determinar seu papel; Existe um alt risc de prjet, vist que prjet falhará se ambs, chefe e prgramadr assistente, nã estiverem dispníveis; As estruturas e grades rganizacinais de uma empresa pdem ser incapazes de acmdar esse tip de grup. Vale destacar que pequens grups cstumam ser mais prdutivs AMBIENTES DE TRABALHO O frneciment de lcal físic de trabalh tem um efeit imprtante sbre a prdutividade e satisfaçã das pessas: Cnfrt; Privacidade; Recurss. As cnsiderações sbre saúde e segurança devem ser levadas em cnta: Iluminaçã; Aqueciment; Mbília. Fatres de ambiente Privacidade cada engenheir exige uma área para trabalh sem interrupções; Cnsciência externa as pessas preferem trabalhar cm luz natural; Persnalizaçã as pessas adtam práticas diferentes de trabalh e gstam de rganizar seu ambiente de maneiras diferentes.

209 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 209 Organizaçã d espaç de trabalh Os espaçs de trabalh devem frnecer espaçs privativs nde as pessas pssam trabalhar sem interrupções. O frneciment de escritóris individuais para pessal tem mstrad aument de prdutividade; Cntud, as equipes que trabalham juntas também exigem espaçs nde as reuniões frmais e infrmais pssam ser realizadas. A seguir está apresentad um pssível Layut de escritóri O MODELO DE MATURIDADE DE CAPACITAÇÃO DE PESSOAL O Mdel de Maturidade de Capacitaçã de Pessal fi prpst cm um framewrk para gerenciament d desenvlviment das pessas envlvidas n desenvlviment de sftware. Objetivs d P-CMM (Peple Capability Maturity Mdel ) Melhrar a capacidade rganizacinal cm aument da capacidade de sua frça de trabalh; Assegurar que a capacidade de desenvlviment de sftware nã é dependente de um númer pequen de pessas É da rganizaçã e nã ds indivídus; Alinhar a mtivaçã de pessas cm a da rganizaçã; Auxiliar na manutençã de pessas cm cnheciment e habilidades críticas, evitand assim a rtatividade. Níveis d P-CMM É definid um Mdel de cinc estágis, send tais estágis: Inicial - Gerenciament específic de pessas; Repetível - Plíticas desenvlvidas para melhria de capacidade; Definid - Gerenciament padrnizad de pessas na rganizaçã; Gerenciad - Metas quantitativas para gerenciament de pessal; Otimizaçã - Fc cntínu na melhria da cmpetência individual e na mtivaçã da frça de trabalh.

210 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 210 A figura abaix ilustra tais níveis: Pnts-chave Fatres de seleçã de pessal incluem educaçã, experiência de dmíni, adaptabilidade e persnalidade; As pessas sã mtivadas pelas interações, pel recnheciment e pel desenvlviment pessal; Grups de desenvlviment de sftware devem ser pequens e cess. Os líderes devem ser cmpetentes e devem ter api administrativ e técnic; A cmunicaçã d grup é afetada pel status, pel tamanh, pela rganizaçã e pela cmpsiçã de sexs e persnalidades d grup; Ambientes de trabalh devem incluir espaçs para interaçã e espaçs privad para trabalh; O Mdel de Maturidade de Capacitaçã de Pessal é um framewrk para a melhria das capacidades d pessal de uma rganizaçã.

211 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: ESTIMATIVAS A arte e a ciência de se realizar previsões SOBRE ESTIMATIVAS Estimativa é cnsiderada tant uma arte quant uma ciência; Medidas frnecem estimativas históricas (experiências anterires); É precis saber que vai dar errad... Estimativa tem risc inerente. As estimativas cstumam ser realizadas tend pr base: O escp d sftware; Medidas de prjets já cncluíds; Empreg de métds e mdels de estimativas. As estimativas realizadas durante Planejament d prjet envlvem: Trabalh a ser feit (esfrç); Recurss necessáris (pessas, hardware, sftware); Temp que será gast; Cust d prjet. Algumas infrmações sbre Prjet que devem estar dispníveis: Declaraçã de bjetiv e metas; Mdel de cass de us (principais) / Escp; Especificaçã Funcinal: Principais Funções; Especificaçã Nã Funcinal: Desempenh e qualidade; Ambiente: cndições e restrições. O us de infrmações e medidas históricas pde ser bastante útil. Ajudam a reduzir risc das estimativas devid a cnsideraçã da experiência já adquirida; Sbre s atributs ds dads histórics: Devem ser razavelmente preciss; Devem ser cletads para mair númer de prjets pssíveis; As medidas devem ser interpretadas da mesma maneira durante td prjet; As aplicações devem ser similares as d prjet que se quer estudar. A estimativa ds Recurss, Custs, Prazs e Prgramaçã das Atividades para um esfrç de desenvlviment de sftware exige: Experiência; Acess a bas infrmações históricas; Cragem para se cmprmeter cm medidas quantitativas quand só existirem dads qualitativs. As estimativas sã afetadas pr muitas variáveis. Pdem ser citadas: Humanas, técnicas, ambientais, plíticas; As estimativas sã realizadas após a definiçã d Escp, que irá identificar mínim para se realizar as estimativas: funções, desempenh esperad, restrições, interfaces, cnfiabilidade; Apesar das estimativas serem previstas antes d desenvlviment d sftware em si, sã atualizadas a lng d prjet, de acrd cm as necessidades verificadas durante acmpanhament;

212 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 212 Objetivs da realizaçã de estimativas: Adequar s recurss a prblema; Cbrar prdutividade ds desenvlvedres na medida certa; Adquirir dads para cmparaçã; Verificar a viabilidade de prjets; Antecipar custs, recurss, prazs, qualidade; Auxiliar a gestã de riscs. Fatres que influenciam na estimativa: Cmplexidade d Prjet. Quant mais cmplex fr prjet, mais difícil será estimar s recurss necessáris; Pr utr lad, a familiaridade cm tip de aplicaçã anula/reduz esta dificuldade (depende da experiência da equipe); Tamanh d Prjet. À medida que prjet cresce, as interdependências aumentam; Uma mudança ns requisits exige mudanças em váris móduls; O tamanh dificulta as estimativas, pis à medida que um sftware cresce, aumentam as cnexões entre s váris elements desse sftware, dificultand a decmpsiçã d prblema. Cm a decmpsiçã d prblema é uma das principais abrdagens para a realizaçã de estimativas, a dificuldade da decmpsiçã implica na dificuldade de realizar estimativas; Grau de Estruturaçã / Grau de Incerteza Estrutural. A Estrutura se refere a grau n qual s requisits fram slidificads; Dispnibilidade de Infrmações Históricas. Quant mair a dispnibilidade de dads sbre prjets realizads anterirmente, melhres serã as estimativas, dada a experiência existente; Verificand históric de recurss, gasts cm aplicações e a qualidade de sftwares já prduzids, pde-se estimar s recurss necessáris e a qualidade d sftware que será desenvlvid; Falta de Dads Cncrets. Embra se deseje estimativas quantitativas, ainda nã existem muits dads sbre prjet a ser desenvlvid. Sugestã: Dadas as restrições de cada técnica a ser apresentada a seguir é sugerid que se estime cm mais de uma técnica e tente chegar a um cnsens, a cmparar s valres estimads pr tais técnicas ESTIMATIVAS DE RECURSOS O gerente de prjets deve realizar estimativas relacinadas a recurss humans, de hardware e de sftware; Em relaçã a recurss humans deve-se especificar: Habilidades/perfis exigids; Dispnibilidade; Duraçã de Tarefas; Data de Entrada n Prjet. O respnsável pels Recurss Humans deve cnsiderar: Cargs Gerente, analista, desenvlvedr, cnsultr,... Especialidades telecmunicações, sistemas de infrmaçã, timizaçã,... Habilidades linguagens de prgramaçã, bancs de dads, ferramentas CASE,... Tamanh da Equipe;

213 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 213 Dispnibilidade; Duraçã de Tarefas; Data de Entrada n Prjet. Ainda sbre recurss humans deve-se destacar: a quantidade de pessas necessárias para um prjet só pde ser determinada depis de ser feita uma estimativa d esfrç d desenvlviment. Em um primeir mment que se determina é carg e a especialidade; Em relaçã a recurss de hardware / sftware, deve-se especificar: Descriçã; Dispnibilidade; Duraçã d Us; Data de Entrega. Sbre Recurss de Hardware: As questões relativas a hardware devem ser cnsideradas sb dis aspects principais: Hardware de Desenvlviment aquele necessári para desenvlver sftware; Hardware de Prduçã aquele n qual sftware desenvlvid será executad; O primeir tip dependerá d segund, já que ideal é testar sistema n ambiente em que ele será executad; Deve-se levar em cnsideraçã também a capacidade de armazenament e a cmunicaçã entre cmputadres, permitind assim interaçã entre s stakehlders. Sbre Recurss de Sftware: Pdem ser utilizadas diversas ferramentas a lng d desenvlviment, tais cm ferramentas de mdelagem, ambientes de linguagem de prgramaçã, cmpiladres; Destaca-se us de ferramentas CASE (Cmputer Aided Sftware Engineering). Algumas das principais categrias de Ferramentas CASE sã: Ferramentas de Planejament de Sistemas de Infrmaçã. Essas ferramentas auxiliam desenvlvedres a reslver diversas questões que direcinarã desenvlviment, tais cm nde se riginam s dads crítics a negóci?, Para nde vã essas infrmações?, Cm elas sã utilizadas?. Assim, sistema distribuirá adequadamente as infrmações certas para as pessas certas; Ferramentas de Api. De uma frma geral, abrangem sftwares que auxiliam a cmunicaçã, tais cm crrei eletrônic, bulletin bards e ferramentas de gerenciament de cnfiguraçã; Ferramentas de Gerenciament de Prjets. Estas ferramentas auxiliam gerente de prjets a realizar estimativas de cust, esfrç e duraçã de um prjet de sftware; aplicar métricas (tal cm ajudar a traçar uma baseline); planejar atividades e mnitrar prjets. Exempl: MS-Prject; Ferramentas de Análise e Prjet. Auxiliam engenheir a criar um mdel d sistema e a avaliar sua qualidade. Exempl: Ratinal Rse; Ferramentas de Prgramaçã. Além de ferramentas cmuns, cm editres, cmpiladres e debuggers, incluem também ambientes visuais, ferramentas de prgramaçã rientadas a bjet, entre utrs;

214 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 214 Ferramentas de Integraçã e Testes. Existem diverss tips de ferramentas de teste. Algumas auxiliam desenvlvedr a prjetar cass de teste, enquant utras auxiliam a aplicaçã de diferentes metdlgias de teste de sftware. Pdem auxiliar ainda a testar a integraçã entre móduls distints de um sftware; Ferramentas de Cnstruçã de Prtótips e Simulaçã. Existem diversas ferramentas deste tip. Algumas sã bem simples, apenas ajudand a desenhar telinhas. Outras sã bastante sfisticadas, tais cm aquelas que auxiliam a simulaçã de ambientes multi-prcessadres u de temp real. Neste cas, ajudam a avaliar desempenh d sistema prpst antes de seu desenvlviment; Ferramentas de Manutençã. Este tip de ferramenta auxilia desenvlvedr a realizar alterações em um sftware sem intrduzir errs. Além diss, auxiliam a engenharia reversa u reengenharia de uma aplicaçã; Ferramentas de Framewrk. Estas ferramentas dispnibilizam uma platafrma para a criaçã de ambientes integrads de suprte a prjets (IPSE, u Integrated Prject Supprt Envirnment). Essa platafrma permite que se utilize diferentes ferramentas CASE, prduzidas pr diferentes cmpanhias n desenvlviment de um únic prjet. Pr exempl, utilizar: 1) uma ferramenta de mdelagem, 2) um ambiente de prgramaçã e 3) uma ferramenta de teste de sftware de frma integrada. O ambiente facilita que a saída de uma ferramenta seja frnecida cm entrada para utra ferramenta. ADSCP Ambientes de Desenvlviment de Sftware Centrads em Prcess. Cnsiderações sbre Reusabilidade. O reus de códig permite a reduçã ds custs de desenvlviment e acelera a entrega d prdut; Outr recurs que pde ser utilizad para desenvlviment sã trechs de códig já cnstruíds, u seja, em vez de se desenvlver um sftware cmpletamente pdese reutilizar prcediments, funções u móduls já desenvlvids para utrs sftwares; N entant diverss cuidads e preparativs sã necessáris. O ideal é que quand se prduza um sftware já sejam tmadas prvidências que permitam que partes d códig sejam reutilizadas psterirmente. Alguns cuidads sã: Ba dcumentaçã; Catalgaçã e padrnizaçã; Categrizaçã em biblitecas; Validar as integrações necessárias; Basicamente, pdem ser classificads em 4 categrias: Cmpnentes de prateleira; Cmpnentes de experiência plena (ttalmente testads); Cmpnentes de experiência parcial; Cmpnentes nvs; O gerente de prjets deve cnsiderar: O cust para cmprar trechs prnts d códig será quase sempre menr d que cust para desenvlvê-ls; Cas pacte exija mdificaçã para pder ser utilizad, quase sempre cust de cmpra + mdificaçã será mair u igual d que cust para desenvlviment; A reusabilidade deve ser visualizada já na etapa de Planejament, e nã apenas na de implementaçã, cas cntrári nã haverá temp para planejar adequadamente e fazer estimativas de cust e temp.

215 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: ESTIMATIVAS DE PROJETOS Cmpstas pelas estimativas de Esfrç, Cust e Praz; Errs nas estimativas de custs de um prjet pdem inviabilizá-l, u fazer a diferença entre lucr e prejuíz; Antes de estimar prjet de sftware, gerente de prjet deve entender escp d sftware a ser cnstruíd e gerar uma estimativa d seu tamanh; Estimativa e desenvlviment de crngrama de prjet sã atividades de gerenciament intercaladas; A precisã da estimativa de um prjet de sftware depende de uma série de fatres, entre eles: O grau cm que planejadr estimu adequadamente tamanh d prdut a ser cnstruíd; A aptidã para traduzir a estimativa de tamanh em esfrç human, temp e cust (em funçã da dispnibilidade de medidas cnfiáveis de prjets anterires, pr exempl); O grau cm que plan de prjet reflete a capacidade da equipe; A estabilidade ds requisits e d ambiente de desenvlviment. Para realizar estimativas mais cnfiáveis há várias pções: Atrasar as estimativas. O que nrmalmente nã é viável, pis elas devem ser feitas n iníci d prjet, para serem úteis; Basear as estimativas em prjets similares já cncluíds; Nrmalmente as estimativas serã mais eficientes quant mair fr históric de dads dispnível. Estimativas tendem a ser mais acertadas cm passar d temp; Usar Técnicas de Decmpsiçã. Dividir para cnquistar ; Divisã em etapas d desenvlviment de sftware, a fim de que as estimativas sejam feitas cnsiderand tais etapas; Fazer us de Mdels Empírics para cust e esfrç. Sã utilizads cm cmplement das técnicas de decmpsiçã; Uma representaçã: d = f(v i ), linhas de códig; Onde: d = uma série de fatres estimads esfrç, cust, duraçã v i = parâmetrs independentes selecinads, tais cm númer de Utilizar ferramentas autmatizadas. Pdem implementar tant técnicas de decmpsiçã quant mdels empírics; O desenvlvedr infrma características da rganizaçã (tais cm experiência e ambiente) e d sftware a ser cnstruíd (tais cm cmplexidade e dmíni). E cm base nessas infrmações as estimativas serã geradas; Aquelas cm uma interface hmem-máquina eficiente pdem ser bastante eficazes em auxiliar a geraçã de estimativas; N entant, de um md geral as estimativas serã mais eficientes quant mair fr históric de dads dispníveis. Assim, as estimativas tendem a ser mais acertadas cm passar d temp. A estimativa de Esfrç permite diferentes interpretações:

216 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 216 ESFORÇO = pessas mês/ ttal d prjet (pm) Exempl: Esfrç = 60 pm pde ser encarad cm 5 pessas durante 12 meses, u 12 pessas durante 5 meses, entre utras pssibilidades Estimativas de Cust Deve-se cnsiderar sbre Cust: Custs de esfrç ( fatr dminante na mairia ds prjets). Os saláris ds engenheirs envlvids n prjet; Custs sciais e de segur; Os custs de esfrç devem levar em cnta s verheads: Custs de edifíci, aqueciment, iluminaçã; Custs de rede e cmunicações; Custs de recurss cmpartilhads (pr exempl, bibliteca, restaurante d pessal, etc). Custs nã cmpreendem apenas s custs ds saláris ds desenvlvedres d sftware; Para saber cust é necessári saber quants meses e quantas pessas trabalharã n prjet, u seja: é precis saber esfrç; Os custs incluem diversas categrias, tais cm: Custs de hardware e sftware; Custs de viagens e treinaments; Custs relativs a frneciment de energia; Custs cm recurss humans de api, cm cntadres, secretáris, faxineirs, etc; Custs cm perações em rede e cmunicações; Cust cm instalações centrais, cm bibliteca, sanitáris, instalações recreativas, etc; Custs cm previdência scial e benefícis, tais cm plan de saúde; Quand se cnsideram tdas essas despesas, valr pr cabeça chega a um valr médi de dbr d salári ds engenheirs de sftware; Ou seja, se um engenheir recebe R$5.000,00 pr mês, a empresa terá um cust de até R$10.000,00 vezes númer de engenheirs de sftware. Quand se estima preç que será pedid a cliente, geralmente é alg d tip: cust + lucrs. Assim, se cada engenheir recebe R$5.000,00 pr mês e s cálculs mstraram que precis de 5 engenheirs trabalhand pr dis meses, cust será de (5.000 x 5)x2 = R$50.000,00. Ainda é precis cnsiderar cust além d salári. Prtant, preç de venda para cliente será de aprximadamente R$50,000,00 + lucr desejad. Supnha um lucr de 30%. Valr final: R$65.000,00; Deve-se levar em cnta váris fatres a decidir a margem de lucr, tais cm: Oprtunidade de mercad - Pde-se ptar pr um preç baix, cm bjetiv de iniciar um nv segment d mercad de sftware. Aceitand um lucr menr, pdese bter melhres lucrs a lng praz; Incerteza da estimativa - Quand uma empresa nã está segura das estimativas, estima cust clcand um lucr bem acima d nrmal, prevend que surgirã despesas imprevistas; Cndições cntratuais - Se desenvlvedr quiser manter a prpriedade d códigfnte para reutilizá-l, geralmente cbra um preç menr; Vlatilidade ds requisits - Se existe a prbabilidade de que s requisits sejam mdificads, uma empresa pde baixar s preçs para ganhar cliente e, mais tarde, cbrar preçs mais alts pelas mudanças;

217 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 217 Saúde financeira - Em épca de vacas magras, aceita-se um preç reduzid, mas que mantenha a empresa funcinand a lng praz MEDIDA DE PRODUTIVIDADE Medida de prdutividade é uma medida da taxa na qual s engenheirs individuais envlvids n desenvlviment de sftware prduzem sftware e sua dcumentaçã assciada; Nã é rientada à qualidade, embra a garantia de qualidade seja um fatr da avaliaçã de prdutividade; Essencialmente, deseja-se medir a funcinalidade útil prduzida pr unidade de temp; As medidas de prdutividade sã as seguintes: Medidas Relacinadas a Tamanh sã baseadas em alguma saída d prcess de sftware. Pdem ser linhas de códig-fnte entregues, instruções de códig-bjet, etc; Medidas Relacinadas a Funções sã baseadas na estimativa da funcinalidade d sftware entregue. Pnts de funçã é a mais cnhecida desse tip de medida; Alguns prblemas enfrentads n estabeleciment das medidas: Estimativa d tamanh da medida (pr exempl, quants pnts de funçã); Estimativa d númer ttal de prgramadr/mês que passu; Estimativa da prdutividade d cntratante (pr exempl, equipe de dcumentaçã) e da incrpraçã dessa estimativa na estimativa glbal. Linha de Códig É mais bjetiva; A medida fi prpsta quand s prgramas eram escrits em cartões, send uma declaraçã pr cartã. Assim, númer de LOC = númer de cartões; Cm a linha de códig crrespnde às declarações, tal cm em Java, que pdem ser distribuídas em várias linhas, u nde pde haver várias declarações em uma linha, trna-se difícil estabelecer um relacinament simples entre as declarações de prgrama e as linhas de uma listagem; Quais prgramas devem ser cntads cm parte d sistema? Esse mdel assume que há um relacinament linear entre tamanh de sistema e vlume de dcumentaçã. Cmparações de Prdutividade (anrmalidades encntradas): Quant mais baix nível da linguagem, mais prdutiv prgramadr - A mesma funcinalidade precisa de mais códig para se implementada em uma linguagem de baix nível d que em uma de alt nível; Quant mais prlix prgramadr, mair a prdutividade - Medidas de prdutividade baseadas em linhas de códig sugerem que s prgramadres que escrevem códigs prlixs sã mais prdutivs que prgramadres que escrevem códigs cmpacts. Pnt pr Funçã É mais subjetiva;

218 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 218 Uma alternativa para us de tamanh de códig cm atribut de prdut estimad é usar alguma medida de funcinalidade de códig. A mais cnhecida dessas medidas é a cntagem de pnts de funçã; É basead em uma cmbinaçã de características de prgrama, send elas: Entradas e saídas externas; Interações de usuáris; Interfaces externas; Arquivs usads pel sistema; Um pes é assciad cm cada uma dessas características e a cntagem de pnt de funçã é btida pela multiplicaçã de cada cntagem inicial pel pes estimad e smand tds s valres. UFC = (númer de elements de dad tip) x (pes) O pnt de funçã é mdificad pela cmplexidade d prjet; Os FPs pdem ser usads para estimar LOC dependend d númer médi de LOC pr FP para uma dada linguagem. LOC = AVC x númer de pnts de funçã; AVC é um fatr dependente de linguagem que varia de 200 a 300 para linguagem Assembly e de 2 a 40 para 4GL; FPs sã muit subjetivs. Eles dependem d estimadr. A cntagem ttalmente autmática ds pnts da funçã é impssível. Pnts de Objet Pnts de bjet (alternativamente chamads pnts de aplicaçã) sã uma medida alternativa relacinada a funções quand as linguagens 4GLs u similares sã usadas n desenvlviment; Pnts de bjet NÃO sã mesm que classes de bjet; O númer de pnts de bjet em um prgrama é uma estimativa pnderada. D númer de telas separadas que sã apresentadas; D númer de relatóris que sã prduzids pel sistema; D númer de móduls de prgrama que devem ser desenvlvids para suplementar códig de banc de dads; Os pnts de bjet sã mais fáceis de estimar a partir de uma especificaçã que pnts de funçã, à medida que eles estã relacinads simplesmente cm telas, relatóris e móduls de linguagem de prgramaçã. Eles pdem, prtant, ser estimads bem n iníci d prcess de desenvlviment. Nesse estági, é muit difícil estimar númer de linhas de códig em um sistema TÉCNICAS DE ESTIMATIVA Nã existe uma maneira simples de fazer uma estimativa precisa d esfrç necessári para desenvlver um sftware. As estimativas iniciais sã baseadas em infrmações inadequadas de uma definiçã de requisits de usuári; O sftware pde perar em cmputadres nã familiares u usar uma nva tecnlgia;

219 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 219 As pessas n prjet pdem ser descnhecidas; As estimativas de cust pdem ser aut-suficientes. A estimativa define rçament, e prdut é ajustad para atender a esse rçament; Algumas técnicas de estimativa estã expstas na tabela abaix: TÉCNICAS DE DECOMPOSIÇÃO As estimativas de LOC e FP sã técnicas distintas, prém cm várias características em cmum. O gerente de prjet cmeça cm uma declaraçã d escp e a partir dela tenta decmpr sftware em funções que pdem ser estimadas individualmente. LOC u FP é entã estimada para cada funçã. O gerente pde utilizar utras medidas para dimensinar, cm classes u bjets. A utilizaçã de LOC e FP é semelhante. O sftware é decmpst em partes; Estima-se LOC / FP para cada parte; Estima-se s valres requerids de esfrç, praz e cust cm base ns valres encntrads para LOC / FP; As estimativas de cada parte sã utilizadas para gerar estimativas glbais d prjet. As estimativas pdem ser: Otimistas (a); Prváveis (b); Pessimistas (c); Calcula-se valr de uma estimativa pnderada (esperada) cm send, pr exempl: E = a + 4b + c 6 A calcular a estimativa pnderada para cada sub-funçã identificada, calcula-se a estimativa glbal d prjet. OBS.: Essa é apenas uma das pssibilidades, pde-se variar também pes que é dad a cada estimativa. Algumas técnicas de decmpsiçã já bastante tradicinais estã a seguir apresentadas.

220 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: Mdel 1 Estima-se LOC/FP para cada sub-funçã, utilizand-se as visões Otimista, Prvável e Pessimista; Calcula-se valr esperad, cm base nas três visões; Calcula-se Ttal de Esfrç (E) e Cust. De dads histórics btêm-se valres de prdutividade e cust médi; Aplicam-se s dads histórics para se bter s valres d atual prjet. Exempl: Funções Estimativa LOC timista(a) prvável(b) pessimista(c) Esperad Funçã Funçã Funçã Funçã Funçã Funçã Funçã LOC ESTIMADO De prjets passads (dads histórics) btém-se: Prdutividade Média = 596 LOC/pessa-mês. Cust Médi = R$19,7/LOC. Da última tabela bteve-se LOC ESTIMADO = E partind daí pde-se bter s valres desejads: ESFORÇO = LOC ESTIMADO / prdutividade média. ESFORÇO = / 596 = 56 pessas-mês. CUSTO = LOC ESTIMADO x cust médi. CUSTO = x 19,7 = R$ Mdel 2 Estima-se LOC/FP para cada sub-funçã; De prjets passads (dads histórics) btém-se: Diferentes valres de prdutividade, de acrd cm a cmplexidade de cada subfunçã; O CUSTO e ESFORÇO sã calculads separadamente para cada sub-funçã; Calcula-se Ttal de Esfrç e Cust, cm base ns sub-ttais btids.

221 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 221 Exempl: Funções Estimativa LOC LOC / pm Cust / Cust Otimista Prvável Pessimista Esperad pm(h) prjet () LOC (H) Prjet (x) Funçã , Funçã , Funçã , Funçã , Funçã , Funçã , Funçã , LOC ESTIMADO Esfrç Estimad 144,5 Cust Estimad Mdel 3 Quand nã existem experiências anterires, é muit cmplicad realizar estimativas. Nesses cass, uma pssível técnica cnsiste ds seguintes passs: Decmpr prjet em cmpnentes elementares (sub-funções); Identificar as atividades necessárias à implementaçã de cada cmpnente que será de acrd cm prcess de desenvlviment de sftware que fr seguid; Estimar ESFORÇO exigid para cada atividade; Aplicar a TAXA de trabalh (relativ a uma pessa pr mês) a cada uma das etapas de cnstruçã d sftware; Calcular CUSTO para cada etapa e ttal. Exempl: Funções Etapas d Desenvlviment Ttal Análise Prjet Cdificaçã Teste Funçã ,5 3,5 7 Funçã ,5 9,5 26 Funçã 3 2, ,5 Funçã Funçã 5 1, ,5 27 Funçã 6 1,5 6 3, Funçã Ttal 14, ,5 50,5 152,5 (Esfrç Estimad pm) Taxa (R$) Cust Estimad (R$)

222 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: MODELOS EMPÍRICOS DE ESTIMATIVAS Mdels empírics utilizam fórmulas derivadas de dads btids em prjets anterires; Pr iss, nenhum mdel empíric é aprpriad para tds s tips de aplicaçã de sftware e tds s ambientes de desenvlviment; Os chamads mdels de recurss cnsistem de uma u mais equações empiricamente derivadas que estimam: esfrç, duraçã d prjet, entre utrs. Pde-se dividir s mdels de recurss em 4 classes: Mdels Estátics de Variáveis Simples Pssuem frmat: Recurs = c1 x (características estimadas) c2 Recurs pde ser esfrç, duraçã u LOC; As cnstantes c1 e c2 sã valres derivads ds dads cmpilads em prjets passads; A característica estimada pde ser LOC, esfrç, etc; A versã básica d Mdel de Cust Cnstrutiv, u COCOMO (Cnstructive Cst Mdel) é um exempl desta classe. Mdels Estátics de Múltiplas Variáveis Sã baseads em dads histórics, cm s anterires; N entant, sã baseads nã apenas em uma, mas em várias características; Seu frmat, entã, é seguinte: Recurs = c11e1 + c21e cijei Send que ei sã características e cij sã cnstantes. Mdels Dinâmics de Múltiplas Variáveis Este mdel tenta prjetar s requisits de recurss cm uma funçã d temp; Cada pass d prcess é assciad a uma prcentagem d esfrç; A partir de entã, prjeta-se s recurss a lng d temp, de acrd cm esfrç assciad a cada pass; É feita uma curva de dispêndi de recurss a lng d temp; Um exempl de mdel desta classe é Mdel de Putnam. Mdels Teórics Analisam características cmplexas d códig-fnte, cm númer de perands e peradres Mdel COCOMO (COnstructive COst MOdel) É um mdel estátic de variáveis simples, prpst ns ans 80; Englba uma hierarquia de 3 mdels: Mdel 1: COCOMO Básic - Cmputa esfrç e temp de desenvlviment d sftware cm uma funçã d tamanh d prgrama express em linhas de códig estimadas; Mdel 2: COCOMO Intermediári - Cmputa esfrç de desenvlviment cm uma funçã d tamanh d prgrama e um cnjunt de direcinadres d cust, que incluem avaliações subjetivas d prdut, d hardware, d pessal e ds atributs d prjet; Mdel 3: COCOMO Avançad - Incrpra tdas as características da versã intermediária e adicina uma avaliaçã d impact ds direcinadres de cust sbre cada pass (análise, prjet, etc) d prcess de engenharia de sftware. O mdel COCOMO pde ser aplicad em três classes de prjets de sftware: Md Orgânic. Prjets de sftware simples e pequens;

223 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 223 Equipes cm ba experiência em aplicações; Cnjunt de requisits nã tã rígids; Md Semi-destacad. Prjet intermediári em tamanh e cmplexidade; Equipe cm níveis de experiências mists; Alguns requisits rígids e utrs nã; Md Embutid. Cnjunt rígid de restrições peracinais, de hardware e de sftware. Os atributs chamads de Direcinadres d Cust pdem ser agrupads em 4 categrias: Atributs d Prdut. Cnfiabilidade exigida d sftware; Tamanh d banc de dads da aplicaçã; Cmplexidade d prdut; Atributs d Hardware. Restrições a desempenh de runtime; Restrições de memória; Vlatilidade d ambiente de máquina virtual; Temp para cmpletar cicl exigid; Atributs de Pessal. Capacidade de análise; Capacidade em engenharia de sftware; Experiência em aplicações; Experiência em máquina virtual; Experiência em linguagens de prgramaçã; Atributs de Prjet. Us de ferramentas de sftware; Aplicaçã de métds de engenharia de sftware; Crngrama de atividades de desenvlviment exigid. Cada um desses atributs é classificad de acrd cm uma escala de 6 pnts (de acrd cm a imprtância e valr): 0,1 Muit baix 0,2 Baix 0,3 Mderad 0,4 Médi 0,5 Elevad 0,6 Extremamente elevad N entant, cm vist a seguir essa classificaçã só é utilizada ns mdels Intermediári e Avançad; Cada um ds 3 mdels COCOMO utiliza fórmulas básicas cm base na classe de prjet. COCOMO Básic E = ab * KLOC bb D = cb * E db Onde: E é esfrç em pessas-mês. D é temp de desenvlviment em meses. KLOC é númer de milhares de linhas de códig. ab, cb, bb e dd sã ceficientes frnecids de acrd cm a tabela a seguir: Prjet de Sftware ab bb cb db Orgânic 2,4 1,05 2,5 0,38 Semi-destacad 3,0 1,12 2,5 0,35 Embutid 3,6 1,20 2,5 0,32

224 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 224 COCOMO Intermediári E = ai * KLOC bi * EAF D = cb * E db Onde: E é esfrç em pessas-mês. KLOC é númer de linhas de códig. EAF sã Fatres de Ajustament de Esfrç, baseads ns atributs direcinadres d cust (vem a partir de uma série de tarefas publicadas pr Behm). Os ceficientes ai e bi sã frnecids de acrd cm a tabela a seguir: Prjet de Sftware ai bi Orgânic 3,2 1,05 Semi-destacad 3,0 1,12 Embutid 2,8 1, Mdel COCOMO II Inicialmente, em 1981, mdel COCOMO fi estabelecid da frma apresentada anterirmente. N entant, a lng ds ans mdel fi mdificad e aprimrad, dand rigem a nvas versões. Uma das versões mais recentes é a COCOMO II estabelecida n an Nessa versã, as fórmulas nã sã simples, pis levam em cnsideraçã inúmers fatres. Ou seja, anterirmente s valres eram definids cm base apenas n prjet de sftware, que pderia ser rgânic, semidestacad e embutid. Já neste mdel, váris fatres sã cnsiderads (nã é mais apenas pela classificaçã), tais cm: A familiaridade ds desenvlvedres cm tip de aplicaçã; A flexibilidade ds requisits; Númer de cmpnentes; Manutenibilidade; Custs detalhads. O COCOMO II é uma hierarquia de mdels de estimativa que apresenta as seguintes áreas, de acrd cm Pressman (2006): Mdel de Cmpsiçã da Aplicaçã Usad ns primeirs estágis da engenharia de sftware, quand a prttipagem das interfaces cm usuári, a cnsideraçã da interaçã d sftware cm sistema, a avaliaçã d desempenh e julgament da maturidade tecnlógica sã de extrema imprtância; Mdel d Primeir Estági d Prjet Usad após s requisits terem sid estabilizads e a arquitetura básica d sftware ter sid estabelecida; Mdel para Estági Após a Arquitetura Usad durante a cnstruçã d sftware. Smmerville (2007) ainda acrescenta a seguinte área: Mdel de Reus. Usad para calcular esfrç de integraçã de cmpnentes reusáveis. Três diferentes pções de dimensinament estã dispníveis, cm parte da hierarquia de mdels: Pnts pr Objet; Pnts pr Funçã; Linhas de Códig-fnte.

225 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 225 O mdel de Cmpsiçã da Aplicaçã, pr exempl, utiliza Pnts pr Objet. Uma sequência para realizaçã da estimativa pde ser a seguinte: Calcula-se a quantidade de telas, relatóris e cmpnentes para sftware; Classifica-se s itens encntrads em níveis de cmplexidade (simples, médi, difícil); Pndera-se a quantidade de telas, relatóris e cmpnentes de acrd cm a classificaçã feita. Pde ser cnsiderada a seguinte tabela de fatr de pnderaçã: Tip de Objet Pes da Cmplexidade Simples Médi Difícil Tela Relatóri Cmpnente 10 A cntagem de pnts pr bjet é entã determinada multiplicand a quantidade riginal de instâncias d bjet pel fatr de pnderaçã e smand para bter a cntagem ttal de pnts pr bjet; Se necessári trabalhar cm reus de cmpnentes, deve-se estimar uma prcentagem de reus e a cntagem de pnts pr bjet deve ser ajustada, cnfrme fórmula abaix: NOP = (pnts pr bjet) * [(100 - % de reus)/100] Em que NOP é definid cm nvs pnts pr bjet; Para derivar uma estimativa de esfrç, cm base n valr de NOP calculad, uma Taxa de Prdutividade precisa ser derivada. Um exempl está escrit abaix: Experiência/capacidade d desenvlvedr Muit baixa Baixa Nrmal Alta Muit alta Maturidade/capacidade d ambiente Muit baixa Baixa Nrmal Alta Muit alta PROD Uma vez determinada a Taxa de Prdutividade, a estimativa d esfrç d prjet pde ser derivada cm: Esfrç = NOP / PROD Em mdels COCOMO II mais avançads, uma variedade de fatres de escala, direcinadres de cust e prcediments de ajuste sã necessáris. Maires detalhes pdem ser encntrads em Smmerville (2007).

226 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: Mdel de Pnt pr Funçã (PF) / Functin Pint (FP) O mdel PF surgiu da necessidade de se estimar tamanh e a cmplexidade d sftware. Organiza-se em 5 Funções Principais, que sã: Entradas Externas; Saídas Externas; Cnsultas Externas; Arquivs Lógics Interns; Arquivs de Interface Externs; As funções sã pntuadas cnfrme: Nível de Cmplexidade; Fatres de Pnderaçã (um critéri subjetiv da rganizaçã). Entradas Externas (External Input EI) Prcess elementar n qual s dads atravessam s limites d sistema de fra para dentr. Estes dads pdem vir de uma tela de entrada u de uma utra aplicaçã para atualizar um u mais arquivs interns; Cada entrada que prprcine dads distints é cntada; Onde EI = External Input, ILF = Internal Lgical File DET (Data Element Type) é um únic e nã repetid camp de dad, recnhecível pel usuári; FTR (Files Types Referenced): arquivs atualizads u referenciads. Nível de Cmplexidade Saídas Externas (External Output - EO) Prcess elementar n qual dads derivads atravessam s limites d sistema de dentr para fra. Os dads criam relatóris u arquivs de saída que sã enviads para utras aplicações Envi de dads u infrmaçã de cntrle para fra das frnteiras da aplicaçã; Cada saída que prprcine infrmações é cntada;

227 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 227 DET: Se um mesm DET é usad tant na saída cm na entrada, ele é cntad apenas uma vez; FTR: Se um mesm FTR é usad tant na saída cm na entrada, ele é cntad apenas uma vez. Nível de Cmplexidade Cnsulta Externa (External Inquiry -EQ) Prcess elementar n qual cmpnentes tant de entrada cm de saída resultam na recuperaçã de dads de um u mais arquiv intern. A entrada nã atualiza qualquer arquiv intern e a saída nã cntém dad derivad Uma entrada de dads casina uma recuperaçã imediata de dads; Cada cnsulta distinta é cntada; O prcess nde uma entrada de dads casina uma recuperaçã imediata de dads. Os dads exibids nã envlvem fórmulas, cálculs u nenhum tip de dads derivads. Nível de Cmplexidade Arquivs Interns (Internal Lgical Files -ILF) Arquivs cnvencinais e/u tabelas de Banc de Dads; Grup de dads lgicamente relacinads que reside internamente as limites d sistema e que é mantid pr entradas externas. Um ILF é cmumente referenciad cm FTR; RET (Recrd Element Type) é um sub-grup de elements de dads dentr de um arquiv intern u extern; DET (Data Element Type) é um únic e nã repetid camp de dad, recnhecível pel usuári.

228 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 228 Nível de Cmplexidade Arquivs Externs (External Lgical Files - ELF) Grup de dads lgicamente relacinads que reside externamente as limites d sistema e que é mantid pr utras aplicações. Um ELF é cmumente referenciad cm FTR; Tdas as interfaces legíveis pr máquina sã cntadas arquivs de dads destinads a utrs sistemas; É um grup de dads de cntrle a ser utilizad pela aplicaçã, mas mantid pr utra, u vice-versa. Nível de Cmplexidade Valres para Pnderaçã: Transações Arquivs

229 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 229 Tabela para cntabilizaçã de pnts: Fatr de Ajuste de Cmplexidade (FAI): É um critéri subjetiv da rganizaçã; É definid a partir de 14 questões sbre desempenh, prcessament distribuíd, interatividade, manutenibilidade, entre utrs; A tabela nrmalmente utilizada está abaix definida: Ajuste da Cmplexidade Item F i Pnts 1 O sistema requer backup e recuperaçã cnfiáveis? 2 Sã exigidas cmunicaçã de dads? 3 Há funções de prcessament distribuídas? 4 O desempenh é crític? 5 O sistema funcinará num ambiente peracinal existente, intensamente utilizad? 6 O sistema requer entrada de dads n-line? 7 A entrada de dads n-line exige que a transaçã de entrada seja elabrada em múltiplas telas u perações? 8 Os arquivs-mestres sã atualizads n-line? 9 A entrada, saída, arquivs u cnsultas sã cmplexs? 10 O prcess intern é cmplex? 11 O códig fi prjetad de frma a ser reusável? 12 A cnversã e a instalaçã estã incluídas n prjet? 13 O sistema é prjetad para múltiplas instalações em diferentes rganizações? 14 A aplicaçã é prjetada de frma a facilitar mudanças e us pel usuári? SOMA(F i ):

230 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 230 Escala de Pnts da tabela anterir: 0 Sem influência 1 Incidental 2 Mderad 3 Médi 4 Significativ 5 Essencial Cálcul de Pnts pr Funçã: FP = cntagem ttal * (0,65+0,01 Fai) 8.8 PMI PROJECT MANAGEMENT INSTITUTE Origem: Internet e utrs PONTOS BÁSICOS O PMI Prject Management Institute (Institut de Gerenciament de Prjets), sediad na Pensilvânia, Estads Unids, é uma assciaçã sem fins lucrativs de prfissinais da área de Gerenciament de Prjets; O PMI visa prmver e ampliar cnheciment existente sbre gerenciament de prjets, assim cm melhrar desempenh ds prfissinais e rganizações dessa área; Desde sua fundaçã, em 1969, PMI cresceu para ser a rganizaçã ds prfissinais de gerência de prjets ; O PMI é hje a rganizaçã mais imprtante de sua área; O PMI estabelece padrões, prvê semináris, prgramas educacinais e certificaçã prfissinal que cada vez mais as rganizações exigem de seus líderes de prjet; O PMI apóia a criaçã de redes de infrmaçã e intercâmbi entre s prfissinais em td mund. Alguns de seus prjets sã: PMI Chapters; PMP Prject Management Prfessinal: Certificaçã prfissinal cm recnheciment de qualificaçã internacinal; PMBOK A Guide t the Prject Management Bdy f Knwledge (Crp de Cnheciment em Gerência de Prjets) é um guia de cnheciment e de melhres práticas para a prfissã de gerência de prjets; O que é um prjet segund PMI: Um prjet é um empreendiment temprári (tem um pnt definid de iníci e fim) cuj bjetiv é criar um prdut u serviç distint e únic ( prdut d prjet pde ser diferenciad de utrs); O que é gerência de prjets segund PMI: É a aplicaçã de cnheciments, habilidades, ferramentas e técnicas em prjets cm bjetiv de atingir u até mesm exceder às necessidades e expectativas ds clientes e demais partes interessadas d prjet PMI Origem: Wikipédia, a enciclpédia livre. Estabelecid em 1969 e situad ns arredres da Filadélfia, Pensilvânia, Estads Unids, Prject Management Institute (PMI) Institut de Gerenciament de Prjet fi fundad pr cinc vluntáris. A cmunidade americana da Pensilvânia emitiu artigs de empresas para PMI que resultaram na cncretizaçã ficial da rganizaçã. Durante aquele mesm an, primeir Simpósi e Seminári PMI fi realizad em Atlanta, Geórgia, Estads Unids, e cmpareciment fi de 83 pessas.

231 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 231 O PMI também é respnsável pela publicaçã: PMBOK (Prject Management Bdy f Knwledge) Cnheciment d Crp de Gerenciament de Prjet. O PMI ferece dis níveis de certificaçã. Um Certificad de Assciad em Gerência de Prjet Certified Assciate in Prject Management (CAPM) demnstru uma base cmum d cnheciment e ds terms n camp da gerência de prjet. Ele requer 1500 hras d trabalh em uma equipe de prjet u 23 hras/aula em gerência de prjet; Um Prfissinal da Gerência de Prjet Prject Management Prfessinal (PMP ) cntem curs de especializaçã e experiência, cncrdand em aderir a um códig da cnduta prfissinal, e aprvaçã para avaliar e medir bjetivamente cnheciment da gerência de prjet. Além diss, um certificad PMP deve estar sempre atualizad cm risc de perda da certificaçã. Em 2005, PMI tinha mais de membrs e mais de prfissinais da gerência de prjet (PMPs) em 125 países O QUE É GERÊNCIA DE PROJETOS - PMI Origem: Finalizar prjets dentr d previst em terms de cust e praz é snh de td gerente de prjets. Cincidência u nã - e eu acredit que nã -, desde que adtams......prject Management Bdy f Knwledge (PMBOK) cm base de nssa metdlgia de gerenciament, nsss prjets vêm terminand desta frma. O PMBOK é a cnslidaçã das melhres práticas e métds usads para gerenciar um prjet, seja de cnstruçã civil u de implementaçã de sistemas de infrmática. Trata-se de um prdut d Prject Management Institute (PMI), um ds mais cnceituads instituts mundiais sbre essa ciência. Cnheciment distribuíd Para PMI, existem nve áreas de cnheciment nesse camp: integraçã, cust, praz, qualidade, escp, recurss humans, riscs, cmunicaçã e sub-cntrataçã. Em uma matriz bidimensinal, PMI cruzu essas nve áreas cm cinc grandes grups de prcesss (de iniciaçã, de planejament, de execuçã, de cntrle e de fechament). Cm iss, fi criad um mapa vltad para gerenciament de prjets, qual indica prcesss a serem realizads e que, pr sua vez, sã referentes a um ds cinc grups de prcesss e a uma das áreas de cnheciment. Segund PMI, um gerente de prjet deverá estar atent a td cntext que dirá respeit à sua gerência, a cicl de vida (divisã pr fases), as stakehlders (s envlvids direta e indiretamente cm prjet), às influências rganizacinais e às influências sóci-ecnômicas. Destacam-se cm habilidades gerenciais a liderança, a cmunicaçã, a negciaçã, a resluçã de prblemas e a influência na rganizaçã. Neste artig, quer tratar d gerenciament da integraçã, que tem pr bjetiv assegurar que s elements d prjet estejam aprpriadamente crdenads pel gerente respnsável. Sã prcesss d gerenciament da integraçã, d desenvlviment d plan d prjet, da execuçã d plan d prjet e d cntrle glbal de mudanças.

232 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 232 Aprendend cm s utrs Um grande dilema entre as áreas cmerciais e as áreas de entrega de empresas que executam prjets é mment da cnfecçã de uma prpsta. Na mairia ds cass, as prpstas sã cnfeccinadas cm base nas lições aprendidas em prjets similares, sbre as quais é pssível prever, cm certa segurança, praz, a quantidade de recurss e, entã, preç final. Clar que surpresas acntecem. Pr iss, melhr mment para gerar uma prpsta é após a cnfecçã d plan d prjet. Essa área de cnheciment tem nme de gerência da integraçã prque s prduts de seus prcesss sã resultad e/u a cnslidaçã ds resultads de utrs prcesss, tmand cm exempl desenvlviment d plan d prjet, que tem cm entrada a execuçã de prduts, tais cm: detalhament de escp, WBS (Wrk Breakdwn Structure, divisã lógica de tdas as atividades), crngrama, rçament, planejament de riscs, entre utrs. É fácil ntar que grup de prcesss de planejament é, de lnge, que tem mair númer. Dessa frma, fica clara a mensagem principal d PMI: fazer um planejament bem feit para executál de frma mais acertada. Pés n chã A execuçã d plan d prjet, pr sua vez, tem cm principal característica a requisiçã de mudanças; u seja, nada que estiver fra d planejad será executad sem as prévias autrizações (que fram também mapeadas durante planejament para s mments de decisões). Em grandes prjets, nrmalmente se cnstitui um Change Cntrl Bard, u seja, um grup de pessas respnsáveis pr analisar, aceitar u rejeitar mdificações que estejam fra d escp, u definir caminh a ser percrrid quand huver mais de uma pçã. Pr últim, tems prcess de cntrle glbal de mudanças, que tem cm um ds principais bjetivs manter a integridade das medidas básicas d prjet, cnhecidas cm baselines. Enfim, a própria cmplexidade ds prcesss da gerência da integraçã está diretamente ligada à qualidade ds resultads de seus predecessres, que, pr si só, justifica a adçã de medidas previstas pel PMI. N fund, tud está diretamente ligad à velha - mas ainda atual - arte de planejar prfundamente qualquer iniciativa e entã executá-la de uma maneira u de utra. Gerência de prjets é uma área que muit pucs desenvlvedres cnhecem, mas que pderia ajudar muit em seus prjets, a rganizá-ls melhr e até a nã atrasá-ls. Gerência de prjets englba tdas as atividades administrativas de um prjet que sã necessárias para seu bm e cntínu andament, levand prdut final desenvlvid a atingir, e de preferência exceder, as expectativas d cliente. Tds nós querems um cliente feliz, mas nem sempre cnseguims. Para que tenhams um cliente feliz, tems que, pel mens entregar nsss prduts (entenda-se aqui também serviçs), n cust, n praz acertad cm cliente e cm a qualidade que cliente espera. Obviamente, se pdems exceder esta expectativa melhr ainda. Para que pssams atingir esta meta tems, dentr da gerência de prjet, algumas áreas cm análise de escp, planejament, qualidade, riscs, cntrle (temp, gasts), cmunicaçã dentr e fra d prjet, entre utrs... Para que tdas as atividades crram de maneira rdenada, existem alguns prcesss relativs a gerência de prjets, send que mais fams é PMI (Prject Management Institute), que prvê a certificaçã PMP (Prject Manager Prfessinal). Este prcess une tdas as áreas acima citadas, e serve para que tenhams cntrle d prjet, e cnsequentemente d prdut final. Trazend para nss dia-a-dia Quer ver estes cnceits n seu dia-a-dia, em seu trabalh de web? Imagine seguinte: Um cliente te prcura e quer um site para sua empresa. Este site deve ser interativ, pssuind assim funcinalidade de armazenagem de dads ds usuáris (nme, endereç, , empresa). Deve ter

233 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 233 um design cm animações em flash, mstrand s 3 prduts da empresa. Deve-se também ter uma lja para a venda ds 3 prduts. Digams que estes sã s dads que cliente te dá. Agra vejams a parte em que vcê entra: 1) Definiçã de escp: pegand s dads d cliente, vcê já terá uma idéia sbre que seu prjet vai ter que entregar. Em nss cas, serã 10 páginas HTML (pr exempl), 4 animações em Flash, prgramaçã em PHP, utilizaçã de banc de dads, criaçã da lja. 2) Planejament: vcê precisa saber quand pderá entregar site rdand para cliente. Para iss, vcê deve ter uma idéia u estimativa d quant de temp gasta em cada atividade, quais atividades dependem uma da utra, se haverá a necessidade de buscar alguém para lhe ajudar, etc... 3) Cntrle: será que estu desenvlvend as atividades de acrd cm a quantidade de hras planejadas? Se sim, beleza. Se nã, que dev fazer para tirar atras? 4) Cmunicaçã: cm dev infrmar cliente quant a andament d prjet? Reuniões semanais? Relatóris? 5) Qualidade: site está rdand perfeitinh? Tem tratament de errs? Cntinua cm mesm aspect mesm em brwsers diferentes? O Banc de dads da lja está segur? Guarda s dads crretamente? Agra, para nã alngar demais, gstaria de saber se vcês, a fazerem seus trabalhs, pensam nestes pnts... Vams a discussã! AS ÁREAS DE CONHECIMENTO DO PMI Origem: Autr: Thiag Pastrell Gervazni Nem tds s autres e prfissinais cncrdam que estas categrias representem a essência d gerenciament de prjets. O própri PMI faz aperfeiçament a cada atualizaçã de sua publicaçã. Existem ainda utras rganizações internacinais que também abrdam assunt, cm a APM (Assciatin fr Prject Management), cm base na Inglaterra, e a IPMA (Internatinal Prject Management Assciatin), que é uma federaçã de diversas entidades nacinais. Nesta cluna abrdams apenas mdel PMI, uma tentativa sólida e estruturada de rganizar cnheciment necessári para uma ba gerência de prjets. As três primeiras áreas a serem estudadas pel PMI, Prazs, Custs e Qualidade, frmam que se chama de Trinômi Sagrad d gerenciament de prjets, cm vems na figura 1. A alterar qualquer uma das pntas cnsequentemente irá mver utra, u seja, se diminu praz, a qualidade u cust serã afetads. Abrdarems abaix tdas as disciplinas abrdadas pel PMI.

234 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 234 Figura 1 - O Trinômi Sagrad 1) Gerenciament de temp A crrida cntra as datas d calendári estabelece ritm de trabalh, e temp é um padrã imprtante para avaliar sucess em prjets. É uma característica que marca as atividades d cmeç a fim, e que faz cm que trabalh em prjets se destaque de trabalhs de natureza peracinal u de prcesss. Em prjets cmplexs, abrdagens baseadas em sistemas sfisticads ajudam a cntrlar temp. Técnicas de redes de interdependência, cm PERT, COM u PDM, apiadas pr sistemas infrmatizads, sã usadas n planejament e n cntrle das atividades d prjet. 2) Gerenciament de custs Pde-se expressar prjets em terms financeirs smand-se s custs de equipaments, materiais, mã de bra, assistência técnica, bens imóveis e financiaments. Até temp pde ser apresentad em terms mnetáris. O gerenciament de prjets é respnsável pel cntrle ds custs glbais para manter s prjets dentr d rçament aprvad. E a administraçã d flux de caixa clabra para timizar a utilizaçã ds recurss financeirs durante períd de existência d empreendiment. As equipes de prjets enfrentam tant desafis financeirs quant ecnômics, à medida que trilham estreit caminh entre s funds rçads e as despesas realizadas. Em última análise, s prjets resumem-se a dinheir e gasts. É ist que faz cm que prjet prgrida e é a razã da sua existência: gerar mais recurss u benefícis para prprietári u rganizaçã patrcinadra d prjet. 3) Gerenciament de Qualidade A atençã para cm a qualidade é uma das metas principais d gerenciament de prjets. Os padrões de qualidade sã ditads pels requisits d prjet, especificações e adequaçã a us. Esses padrões sã usads cm base para mnitrar desempenh d prjet. Mesm em prjets que nã usam especificações detalhadas para estabelecer padrões de qualidade, espera-se um mínim de qualidade funcinal. E as pressões exercidas pr utrs fatres, cm cust e temp, pdem prvcar negciações ("trade ffs") nas quais a qualidade será cmprmetida em favr d crngrama u d rçament. Cntud, a defesa da qualidade d prjet permanece cm uma das respnsabilidades primrdiais d gerenciament de prjet. Estuds psterires transfrmaram a triângul inicial num quadrad, a incluir Escp.

235 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 235 Figura 2 - As quatr áreas 4) Gerenciament de escp (abrangência) O escp refere-se à definiçã das frnteiras entre determinadas tarefas, atividades, cntrats, atribuições, respnsabilidades e missões. Ele define nde termina um trabalh e cmeça utr, já que muits prjets têm áreas inadequadamente definidas. Cm escp deverá realmente ser gerenciad? Eis algumas respstas: pel planejament e dcumentaçã de itens que passam, através das interfaces, de uma área para utra. Grande parte d gerenciament d escp pde ser feita pr mei de crdenaçã diária e da realizaçã de reuniões periódicas. Outrs cntrles de escp incluem us de prcediments frmais, frmuláris e sistemas de mnitraçã. O gerenciament d escp d prjet ajuda a definir que a equipe realizará td e smente trabalh necessári para que prjet seja bem-sucedid. Psterirmente mais quatr áreas fram incluídas a saber: Recurss Humans, Riscs, Cmunicações e Aquisições. Figura 3 - As it áreas 5) Gerenciand recurss humans Os recurss humans ns prjets requerem gerenciament a partir de três ânguls diferentes. Em primeir lugar, lad administrativ e burcrátic exige atençã para garantir que se atendam às necessidades ds funcináris. Estas atividades abrangem a funçã de pessal, incluind recrutament e seleçã, administraçã de saláris, benefícis, férias etc.

236 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 236 Administrar a alcaçã de mã-de-bra é utr lad d gerenciament de recurss humans. Quantas pessas e cm que qualificações serã necessárias durante qual períd de temp em cada atividade? E finalmente lad cmprtamental desse gerenciament requer atençã para assunts cm: qual treinament e desenvlviment necessáris à equipe? Cm mtivar a equipe durante td empreendiment? Cm reslver cnflits crrids? Administrar bem s recurss humans é a chave para atender às necessidades d prjet, uma vez que tdas as ações sã tmadas direta u indiretamente pr pessas. 6) Gerenciand as cmunicações Gerenciar cmunicações em um prjet englba cnjunt de prcesss que asseguram a geraçã, cleta, armazenament e distribuiçã aprpriada das infrmações d prjet. É precis que as cmunicações atendam a planejament estratégic, a planejament d prjet prpriamente dit, às nrmas, as padrões e as prcediments. O sucess de um prjet depende da eficácia das infrmações, e a atençã gerencial precisa ser rientada para definir s canais de cmunicaçã que irã atender às necessidades desse prjet. As cmunicações interpessais também requerem atençã, pis s membrs da equipe precisam ter habilidades para interagir cm eficácia. E as cmunicações cm a cmunidade em geral, cm enfque em relações publicas, pde ser necessári para quebrar resistências e influenciar públic u futurs usuáris. A cmunicaçã de infrmações gerenciais deve se precupar, pr exempl, em cm a infrmaçã será rganizada e cmunicada às pessas? Através de impresss, pr mei de crrei eletrônic, através de página/site na internet u em reuniões? Cm que frequência, cm que bjetivs e que linguagem usar para cada públic alv? 7) Gerenciand risc Em um ambiente estável, as decisões pdem ter pr base a experiência, dads histórics u cnheciment prátic (tácit). Em situaçã de certeza verdadeira, as decisões pdem ser prgramadas cnfrme a seguinte diretriz: "Se A acntecer, faça X, se B acntecer, faça Y". Regras simples pdem ser aplicadas e decisões facilmente tmadas. Pr utr lad, decisões tmadas sb cndições de risc u incerteza nã sã prgramáveis. Sb tais circunstâncias, prjet é caracterizad pr diversas cndições ambientais que exigem que a equipe d prjet se adapte a nvas situações. Assim, gerenciar riscs deve ser um prcess sistemátic de definir, analisar e respnder as pssíveis riscs d prjet, visand diminuir grau de incerteza interna e externa d mesm. Alguns riscs a serem gerenciads incluem: dads físics, scilações ecnômicas e de mercad, riscs tecnlógics, riscs empresariais e cmerciais e de mudanças sciais. 8) Gerenciand aquisições N gerenciament de prjets é precis lidar cm s terceirs que frnecem serviçs, mã-de-bra, materiais e equipaments. O destin d prjet depende da capacidade da equipe de esclher bns frnecedres e prestadres de serviçs, chegar a terms cntratuais adequads e crdenar as atividades destes terceirs. A qualidade final d prjet dependerá d trabalh executad pr terceirs. Prtant, s esfrçs gerenciais devem ser feits n sentid de selecinar as empresas certas que irã executar as tarefas a serem cntratadas. Os terms cntratuais negciads devem assegurar atendiment das necessidades d prjet. E, finalmente, requer-se um esfrç de crdenaçã e diligenciament para garantir que a parte cntratada realmente frneça as mercadrias u serviçs dentr d praz estabelecid e cm a qualidade especificada. Finalmente uma última área fi acrescentada, integraçã.

237 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 237 Figura 4 - As nve áreas 9) Gerenciand a integraçã Sua funçã principal é cnseguir cm que cada uma das it disciplinas acima descritas funcine crreta e harmnicamente. Ou seja, gerenciar integraçã é assegurar a crdenaçã entre elements distints d prjet e cntrlar eventuais mudanças durante sua realizaçã. Nã basta entregar n praz se s custs triplicarem, nã basta manter custs sb cntrle se a qualidade nã é mantida, nã basta entregar cm tds s quesits, e nã ter equipe para próxim prjet, pis a sua atuaçã em RH fi péssima e ninguém mais quer trabalhar cm vcê, e nã basta fazer bas aquisições se estas aumentarem s riscs d prjet. Assim, gerenciar a integraçã é cm mntar um quebra-cabeça, e tud deve estar funcinand bem a mesm temp, uma tarefa nada fácil e simples O CERTIFICADO PMP Origem: O que é a Certificaçã Prject Management Prfessinal (PMP )? É um rigrs Prgrama de Certificaçã Prfissinal desenvlvid e mantid pel PMI - Prject Management Institute, cm base em um exame, visand avanç da prfissã de Gerenciament de Prjets e recnheciment das cnquistas individuais nesta área. A Certificaçã Prject Management Prfessinal (PMP ) d PMI é a credencial prfissinal mais recnhecida e respeitada em terms mundiais n que tange a Gerenciament de Prjets. Em 1999, PMI trnu-se a primeira rganizaçã n mund a ter seu Prgrama de Certificaçã recnhecid pela Internatinal Organizatin fr Standardizatin (ISO) Quais s benefícis de se bter a Certificaçã Prject Management Prfessinal (PMP )? BENEFÍCIOS PARA A ORGANIZAÇÃO: - Certificaçã cm recnheciment internacinal, pr sua cnsistência em relaçã a cnheciment na área de gerenciament de prjets; - Desenvlviment efetiv d prfissinal; - Cnfirmaçã d cnheciment de um prfissinal; - Aument na prdutividade.

238 Disciplina: Engenharia de Sftware Matéria: Gerência de Prjets de Sftware Página: 238 BENEFÍCIOS INDIVIDUAIS: - Aumenta valr d indivídu na rganizaçã; - Aumenta cresciment d trabalh e de prtunidades; - Acelera prgress prfissinal; - Recnheciment d grau de qualificaçã atestad internacinalmente; - Qualidade e efetividade d gerenciament ds prjets; - Ampliaçã da empregabilidade d prfissinal; - Aument médi ds saláris ds gerentes de prjet. Quem pde bter a Certificaçã Prject Management Prfessinal (PMP )? Para bter a Certificaçã PMP, prfissinal deve satisfazer a determinads requisits de educaçã e experiência, cncrdar e aderir a Códig de Cnduta Prfissinal (Cde f Prfessinal Cnduct) e passar n Exame de Certificaçã PMP. Para cmprvaçã da experiência, existem duas categrias: Categria I (prfissinais cm 3º grau cmplet): hras e 36 meses de experiência ns últims 6 ans; Categria II (prfissinais cm 2º grau cmplet): hras e 60 meses de experiência ns últims 8 ans. O PMI-ES prcurará manter este rteir sempre atualizad, mas em cas de cnflit entre as infrmações aqui cntidas e as cnstantes d site d PMI ( prevalecem as infrmações d site. Quant custa para fazer exame de Certificaçã Prject Management Prfessinal (PMP )? US$ 405,00 para filiads d PMI ; US$ 555,00 para nã filiads. 8.9 DICAS DE LEITURA SOMMERVILLE, Ian. Engenharia de sftware Pearsn Educatin. Capítul 5 Gerenciament de Prjets. Capítul 25 Gerenciament de Pessal. Capítul 26 Estimativa de cust de sftware; PRESSMAN, Rger. Engenharia de sftware McGraw Hill. Capítul 21 Cnceits de Gestã de Prjets. Capítul 23 Estimativa de Prjets de Sftware. Capítul 24 Crngramaçã de Prjet de Sftware. Capítul 25 Gestã de Risc; PAULA FILHO, Wilsn de Pádua. Engenharia de sftware fundaments, métds e padrões LTC. Capítul 12 Gestã de Prjets. Capítul 23 Artefats de Gestã de Prjets; VALERIANO. Gerência em prjets pesquisa, desenvlviment e engenharia Capítul 7 Planejament: Aspects Gerais; Gerenciament de Prjets. Link: Artig: COCOMO II Um mdel para estimativa de custs em Gerência de Prjets. Link: Site d PMI n Espírit Sant: Site ficial da PMI: Site sbre Gerenciament de Prjets: Códig de Ética e de Cnduta Prfissinal d PMI. Link: R.pdf; Mapa de Prcesss PMBOK 3ª. Ediçã. Link:

239 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: GARANTIA E CONTROLE DE QUALIDADE A engenharia de sftware nã se relacina à criaçã de dcuments. Refere-se à criaçã de qualidade. [Rger Pressman, 2006] 9.1 INTRODUÇÃO À QUALIDADE DE SOFTWARE Origem: Wikipédia, a enciclpédia livre. A Qualidade de Sftware é uma área de cnheciment da Engenharia de Sftware que bjetiva garantir a qualidade d sftware através da definiçã e nrmatizaçã de prcesss de desenvlviment. Apesar ds mdels aplicads na garantia da qualidade de sftware atuarem principalmente n prcess, principal bjetiv é garantir um prdut final que satisfaça às expectativas d cliente, dentr daquil que fi acrdad inicialmente. Segund a nrma ISO 9000 (versã 2000), a qualidade é grau em que um cnjunt de características inerentes a um prdut, prcess u sistema cumpre s requisits inicialmente estipulads para estes. N desenvlviment de sftware, a qualidade d prdut está diretamente relacinada à qualidade d prcess de desenvlviment, desta frma, é cmum que a busca pr um sftware de mair qualidade passe necessariamente pr uma melhria n prcess de desenvlviment. Rdney Brks, diretr d Labratóri de Inteligência Artificial e Ciência da Cmputaçã d MIT, define qualidade cm a cnfrmidade as requisits. Essa definiçã exige determinar dis pnts: I) que se entende pr cnfrmidade; e II) cm sã especificads - e pr quem - s requisits PRINCIPAIS TÓPICOS Para um melhr entendiment e estud, SWEBOK divide a Qualidade de Sftware em três tópics, cada tópic é subdividid em atividades, da seguinte frma: Fundaments de Qualidade de Sftware Cultura e Ética de Engenharia de Sftware Valres e Custs de Qualidade Mdels e Características de Qualidade Melhria da Qualidade Gerência d Prcess de Qualidade de Sftware Garantia de Qualidade de Sftware Verificaçã e Validaçã Revisões e Auditrias Cnsiderações Práticas Requisits de Qualidade para Aplicações Caracterizaçã de Defeits Técnicas de Gerência de Qualidade de Sftware Medidas de Qualidade de Sftware Ainda segund SWEBOK, a Qualidade de Sftware é um tema tã imprtante que é encntrad, de frma ubíqua, em tdas as utras áreas de cnheciment envlvidas em um prjet. Além diss, ele deixa clar que essa área, cm nele definida, trata d aspects estátics, u seja, daqueles que nã exigem a execuçã d sftware para avaliá-l, em cntrapsiçã á área de cnheciment Teste de sftware. Prém, é nrmal que se encntrem autres e empresas que afirmam serem s testes de sftware uma etapa da Qualidade de Sftware.

240 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: REQUISITOS DE QUALIDADE Requisits de Qualidade é um tópic pr si dentr d assunt Qualidade. Dentr da ótica desta última, espera-se que s requisits sejam definids de maneira a caracterizar cmpletamente prdut a ser cnstruíd. Nesse aspect - e em relaçã à definiçã de Brks - é evidente que as znas de smbra dentr de uma especificaçã abrem margem a td tip de prblemas de avaliaçã de prduts. Smmerville distingue requisits funcinais e nã funcinais. O mdel internacinal mais recente Square, estabelecid pela nrma ISO 25000, adta uma classificaçã um puc diferente e utiliza uma descriçã hierárquica. Dentr dessa descriçã, "funcinalidade" é uma das seis divisões iniciais em que se classificam s requisits de um prdut de sftware. Idealmente, a especificaçã de requisits deve permitir que prcess de fabricaçã d sftware seja cntrlad. Iss significa que idealmente a qualidade de prduts intermediáris deve pder ser mensurada e que s dads btids devem trazer infrmaçã que pssa levar a cntrle de desvis, lcalizaçã de defeits e utras crrências negativas. Para permitir a avaliaçã de prduts finais e de prduts intermediáris, a especificaçã de requisits deve, idealmente, especificar qualitativa e quantitativamente s bjetivs a serem atingids. Esse bjetiv é bastante desafiadr. As experiências iniciais indicam que cada empresa deve cnstruir sua base de dads própria, a partir da qual é pssível refinar as especificações de nvs prduts. Esse caracter lcalizad ds dads se explica pel fat de que nã há especificações universais de qualidade de sftware. Os requisits variam cas a cas, nã apenas em funçã ds clientes mas também ds critéris utilizads pela própria empresa fabricante O PROCESSO DE SOFTWARE Nas últimas décadas fram prpstas dezenas de metdlgias e prcesss adaptads a diferentes cenáris e prduts. Embra se pssa justificar essa multiplicidade pr utra lei de Brks - a ausência de "balas de prata", é um fat que a situaçã se mstra cnfusa. Há dezenas de trabalhs prpsts para cass particulares. Exempls das diversas iniciativas para tratar assunt sã metdlgias cm XP e Scrum; mdel CMM, seguid de tda uma série de adaptações (cm SW-CMM, peple-cmm, etc.), mais tarde substituíd pel mdel CMMI; e dezenas de artigs e teses de mestrad e dutrad, abrdand tópics particulares em um u mais de tais métds, u prpnd ainda nvas adaptações a cass particulares. A situaçã deixa evidente que há um vácu a ser preenchid - atacar a raiz d prblema e identificar uma estrutura suficientemente geral, capaz de explicar prblema de qualidade e ser adaptada a tds s cenáris diferentes. Se tal bjetiv é pssível resta a ser prvad - assunt para nvs artigs e teses GARANTIA DE QUALIDADE DE SOFTWARE A Garantia da Qualidade de Sftware (GQS) é a área-chave de prcess d CMM cuj bjetiv é frnecer as váris níveis de gerência a adequada visibilidade ds prjets, ds prcesss de desenvlviment e ds prduts gerads. A GQS atua cm "guardiã", frnecend um retrat d us d Prcess e nã é respnsável pr executar testes de sftware u inspeçã em artefats. Obtend a visibilidade desejada, a gerência pde atuar de frma pntual n sentid de atingir s quatr grandes bjetivs de um prjet de desenvlviment de sftware, quais sejam, desenvlver sftware de alta qualidade, ter alta prdutividade da equipe de desenvlviment, cumprir crngrama estabelecid junt a cliente e nã necessitar de recurss adicinais nã prevists. Para cnseguir esses bjetivs a área-chave de prcess GQS estimula a atuaçã das equipes respnsáveis pel desenvlviment de sftware em diversas frentes bjetivand internalizar cmprtaments e ações, pdend-se destacar: O planejament d prjet e acmpanhament de resultads;

241 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 241 O us ds métds e ferramentas padrnizadas na rganizaçã; A adçã de Revisões Técnicas Frmais; O estabeleciment e a mnitraçã de estratégias de testes; A revisã ds artefats prduzids pel prcess de desenvlviment; A busca de cnfrmidade cm s padrões de desenvlviment de sftware; A implantaçã de medições assciadas a prjet, prcess e prdut; A utilizaçã de mecanisms adequads de armazenament e recuperaçã de dads relativs a prjets, prcesss e prduts; e A busca de uma melhria cntínua n prcess de desenvlviment de sftware. Para facilitar trabalh ds desenvlvedres e evitar geraçã de metdlgias diversas, Serpr desenvlveu Prcess Serpr de Desenvlviment de Sluções (PSDS). O PSDS fi cnstruíd pr pessas das unidades da empresa que prcuraram aprveitar as melhres práticas existentes e cnsagradas. O "CMM - Capability Maturity Mdel fr Sftware /SEI" é uma estrutura-"framewrk", que descreve s principais elements de um prcess de desenvlviment de sftware efetiv. O CMM descreve s estágis de maturidade através ds quais Organizações de sftware evluem seu cicl de desenvlviment de sftware através de sua avaliaçã cntínua, identificaçã e ações crretivas dentr de uma estratégia de melhria ds prcesss. Este caminh de melhria é definid pr cinc níveis de maturidade: inicial, repetitiv, definid, gerenciad e timizad. O Mdel CMM (CMM- Capability Maturity Mdel) frnece às rganizações uma direçã sbre cm ganhar cntrle de seu prcess de desenvlviment de sftware e cm evluir para uma cultura de excelência na gestã de sftware. O bjetiv principal nas transações destes níveis de maturidade é a realizaçã de um prcess cntrlad e mensurad cm a fundaçã para melhria cntínua. Cada nível de maturidade pssui um cnjunt de práticas de sftware e gestã específicas, denminad áreas-chave d prcess. Estas devem ser implantadas para a rganizaçã atingir nível de maturidade em qualidade de sftware. 9.2 DEFINIÇÕES E CONCEITOS Origem: Apstila sbre Engenharia de Sftware, site: Apstiland. PROF. VITÓRIO BRUNO MAZZOLA. Capítul 2 Qualidade de Sftware 1. INTRODUÇÃO Cm fi mencinad n capítul anterir, papel da Engenharia de Sftware é, principalmente, frnecer métds e ferramentas para desenvlviment d sftware de qualidade e a baix cust. O fatr qualidade é um ds aspects imprtantes que deve ser levad em cnta quand d desenvlviment d sftware. Para ist, é necessári que se tenha uma definiçã precisa d que é um sftware de qualidade u, pel mens, quais sã as prpriedades que devem caracterizar um sftware desenvlvid segund s princípis da Engenharia de Sftware. Um utr aspect imprtante é aquele relacinad à avaliaçã e a aprimrament d prcess de desenvlviment de sftware de uma rganizaçã. Nesta linha, fi desenvlvid pel SEI (Sftware Engineering Institute) um mdel que permite definir parâmetrs para a análise desta questã nas crprações, mdel CMM (Capability and Maturity Mdel), cujas linhas gerais serã descritas na seçã DEFINIÇÃO DE SOFTWARE DE QUALIDADE Primeiramente, é imprtante discutir cnceit de sftware de qualidade. Segund a Assciaçã Francesa de Nrmalizaçã, AFNOR, a qualidade é definida cm "a capacidade de um prdut u serviç de satisfazer às necessidades ds seus usuáris".

242 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 242 Esta definiçã, de certa frma, é cerente cm as metas da Engenharia de Sftware, particularmente quand algumas definições sã apresentadas. É cas das definições de Verificaçã e Validaçã intrduzidas pr Behm, que asscia a estas definições as seguintes questões: Verificaçã: "Será que prdut fi cnstruíd crretamente?" Validaçã: "Será que este é prdut que cliente slicitu?" O prblema que surge quand se reflete em terms de qualidade é a dificuldade em se quantificar este fatr Fatres de Qualidade Externs e Interns Algumas das prpriedades que pderíams apntar de imediat sã a crreçã, a facilidade de us, desempenh, a legibilidade, etc... Na verdade, analisand estas prpriedades, é pssível rganizálas em dis grups imprtantes de fatres, que vams denminar fatres externs e interns. Os fatres de qualidade externs, sã aqueles que pdem ser detectads principalmente pel cliente u eventuais usuáris. A partir da bservaçã destes fatres, cliente pde cncluir sbre a qualidade d sftware, d seu pnt de vista. Enquadram-se nesta classe fatres tais cm: desempenh, a facilidade de us, a crreçã, a cnfiabilidade, a extensibilidade, etc... Já s fatres de qualidade interns sã aqueles que estã mais relacinads à visã de um prgramadr, particularmente aquele que vai assumir as tarefas de manutençã d sftware. Nesta classe, encntram-se fatres cm: mdularidade, legibilidade, prtabilidade, etc... Nã é difícil verificar que, nrmalmente, s fatres mais cnsiderads quand d desenvlviment d sftware sã s externs. Ist prque, uma vez que bjetiv d desenvlviment d sftware é satisfazer a cliente, sã estes fatres que vã assumir um papel imprtante na avaliaçã d prdut (da parte d cliente, é clar!!!). N entant, também nã é difícil cncluir que sã s fatres interns que vã garantir alcance ds fatres externs Fatres de Qualidade Crreçã É a capacidade ds prduts de sftware de realizarem suas tarefas de frma precisa, cnfrme definid ns requisits e na especificaçã. É um fatr de suma imprtância em qualquer categria de sftware. Nenhum utr fatr pderá cmpensar a ausência de crreçã. Nã é interessante prduzir um sftware extremamente desenvlvid d pnt de vista da interface hmem-máquina, pr exempl, se as suas funções sã executadas de frma incrreta. É precis dizer, prém, que a crreçã é um fatr mais facilmente afirmad d que alcançad. O alcance de um nível satisfatóri de crreçã vai depender, principalmente, da frmalizaçã ds requisits d sftware e d us de métds de desenvlviment que explrem esta frmalizaçã Rbustez A rbustez é a capacidade d sistema funcinar mesm em cndições anrmais. É um fatr diferente da crreçã. Um sistema pde ser crret sem ser rbust, u seja, seu funcinament vai crrer smente em determinadas cndições. O aspect mais imprtante relacinad à rbustez é a btençã de um nível de funcinament d sistema que suprte mesm situações que nã fram previstas na especificaçã ds requisits. Na pir das hipóteses, é imprtante garantir que sftware nã vai prvcar cnseqüências catastróficas em situações anrmais. Resultads esperads sã que, em tais situações, sftware apresente cmprtaments tais cm: a sinalizaçã da situaçã anrmal, a terminaçã "rdenada", a cntinuidade d funcinament "crret" mesm de maneira degradada, etc... Na literatura, estas características pdem ser assciadas também a cnceit de cnfiabilidade Extensibilidade É a facilidade cm a qual se pde intrduzir mdificações ns prduts de sftware. Td sftware é cnsiderad, em princípi, "flexível" e, prtant, passível de mdificações. N entant, este fatr nem sempre é muit bem entendid, principalmente quand se trata de pequens prgramas. Pr utr lad, para sftwares de grande prte, este fatr atinge uma imprtância cnsiderável, e pde ser atingid a partir de dis critéris imprtantes:

243 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 243 a simplicidade de prjet, u seja, quant mais simples e clara a arquitetura d sftware, mais facilmente as mdificações pderã ser realizadas; a descentralizaçã, que implica na mair autnmia ds diferentes cmpnentes de sftware, de md que a mdificaçã u a retirada de um cmpnente nã implique numa reaçã em cadeia que altere td cmprtament d sistema, pdend inclusive intrduzir errs antes inexistentes Reusabilidade É a capacidade ds prduts de sftware serem reutilizads, ttalmente u em parte, para nvas aplicações. A necessidade vem da cnstataçã de que muits cmpnentes de sftware bedecem a um padrã cmum, que permite entã que estas similaridades pssam ser explradas para a btençã de sluções para utras classes de prblemas. Este fatr permite, principalmente, atingir uma grande ecnmia e um nível de qualidade satisfatóris na prduçã de nvs sftwares, dad que mens prgrama precisa ser escrit, que significa mens esfrç e menr risc de crrência de errs. Ist significa de fat que a reusabilidade pde influir em utrs fatres de qualidade imprtantes, tais cm a crreçã e a rbustez Cmpatibilidade A cmpatibilidade crrespnde à facilidade cm a qual prduts de sftware pdem ser cmbinads cm utrs. Este é um fatr relativamente imprtante, dad que um prdut de sftware é cnstruíd (e adquirid) para trabalhar cnvivend cm utrs sftwares. A impssibilidade de interaçã cm utrs prduts pde ser, sem dúvida, uma característica que resultará na nã esclha d sftware u n abandn de sua utilizaçã. Os cntraexempls de cmpatibilidade, infelizmente, sã maires que s exempls, mas pdems citar, nesta classe, principalmente, a definiçã de frmats de arquivs padrnizads (ASCII, PstScript,...), a padrnizaçã de estruturas de dads, a padrnizaçã de interfaces hmem-máquina (sistema d Macintsh, ambiente Windws,...), etc Eficiência A eficiência está relacinada cm a utilizaçã racinal ds recurss de hardware e de sistema peracinal da platafrma nde sftware será instalad. Recurss tais cm memória, prcessadr e c-prcessadr, memória cache, recurss gráfics, biblitecas (pr exempl, primitivas de sistema peracinal) devem ser explrads de frma adequada em espaç e temp Prtabilidade A prtabilidade cnsiste na capacidade de um sftware em ser instalad para diverss ambientes de sftware e hardware. Esta nem sempre é uma característica facilmente atingida, devid principalmente às diversidades existentes nas diferentes platafrmas em terms de prcessadr, cmpsiçã ds periférics, sistema peracinal, etc... Alguns sftwares, pr utr lad, sã cnstruíds em diversas versões, cada uma delas rientada para execuçã num ambiente particular. Exempls dist sã alguns prgramas da Micrsft, cm pr exempl pacte Micrsft Office, que existe para platafrmas Macintsh e micrcmputadres cmpatíveis IBM Facilidade de us Este fatr é certamente um ds mais frtemente detectads pels usuáris d sftware. Atualmente, cm grande desenvlviment ds ambientes gráfics cm Windws, X-Windws e Sistema Macintsh, a btençã de sftwares de fácil utilizaçã trnu-se mais freqüente. A adçã de prcediments de auxíli em linha (help n line) é, sem dúvida, uma grande cntribuiçã neste sentid. Dada a definiçã de sftware feita n iníci d curs, prém, nã se pde deixar de registrar a imprtância de uma dcumentaçã adequada (manual de usuári) capaz de rientar usuári em sua navegaçã pel sftware cnsiderad. 3. A METROLOGIA DA QUALIDADE DO SOFTWARE Apresentads alguns fatres de qualidade de sftware, a dificuldade que se apresenta é cm medir a qualidade d sftware. A cntrári de utras disciplinas de engenharia, nde s prduts gerads

244 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 244 apresentam características físicas cm pes, a altura, tensã de entrada, tlerância a errs, etc..., a medida da qualidade d sftware é alg relativamente nv e alguns ds critéris utilizads sã questináveis. A pssibilidade de estabelecer uma medida da qualidade é um aspect imprtante para a garantia de um prdut de sftware cm algumas das características definidas anterirmente. O Metrlgia d Sftware crrespnde a cnjunt de terias e práticas relacinadas cm as medidas, a qual permite estimar desempenh e cust d sftware, a cmparaçã de prjets e a fixaçã ds critéris de qualidade a atingir. As medidas de um sftware pdem ser as mais variadas, a esclha da medida devend bedecer a determinads critéris: a pertinência da medida (interpretabilidade); cust da medida (percentual reduzid d cust d sftware); utilidade (pssibilidade de cmparaçã de medidas). As medidas de um sftware pdem ser rganizadas segund duas grandes categrias: 3.1. Medidas dinâmicas Sã as medidas btidas mediante a execuçã d sftware, cm, pr exempl, s testes, as medidas de desempenh em velcidade e cupaçã de memória, s traçs, etc... Estas medidas pdem assumir um interesse relativamente grande pis elas permitem quantificar fatres que pdem implicar em retrn ecnômic u que representem infrmações sbre a crreçã d prgrama; pr utr lad, estas medidas só pdem ser btidas num mment relativamente tardi d cicl de desenvlviment de um sftware, u seja, a partir da etapa de testes Medidas estáticas Sã aquelas btidas a partir d dcument fnte d sftware, sem a necessidade de execuçã d sftware. Dentre as medidas estáticas, pdems destacar: As medidas de cmplexidade textual, a qual é baseada na cmputaçã d númer de peradres e d númer de perands cntids n text d sftware; A cmplexidade estrutural, a qual se baseia na análise ds grafs de cntrle assciadas a cada cmpnente d sftware; As medidas baseadas n text, cm tamanh d prgrama, a taxa de linhas de cmentáris, etc QUESTÕES IMPORTANTES À QUALIDADE DE SOFTWARE Uma vez que alguns parâmetrs relacinads à qualidade fram detectads na seçã 2.2, cabe aqui discutir alguns princípis que devem fazer parte das precupações de uma equipe de desenvlviment de sftware O princípi d us: sftware deverá ser utilizad pr utrs Este princípi implica num cuidad em trnar sftware acessível nã apenas para usuári imediat, mas também para futurs prgramadres que irã trabalhar n códig fnte, seja para eliminaçã de errs, seja para intrduçã u aprimrament de funções. Cm base nestes princípis, prgramadr u a equipe de prgramaçã deverá prver a necessária flexibilidade e rbustez a prgrama desde iníci d desenvlviment e nã inserir estes aspects à medida que s prblemas vã surgind. Um utr pnt imprtante é que muitas vezes um prgramadr julga que determinadas sluções encntradas a nível de um prgrama sã tã específicas que mais ninguém, incluind própri autr, irá utilizar tal sluçã nvamente. As diversas experiências mstram que ist pdem ser um grave err de avaliaçã, pis cnduz, na mairia ds cass, à geraçã de códig incmpreensível, representand um grande bstácul à reutilizaçã. Algumas prvidências n desenvlviment de um sftware suprtam respeit a este princípi: racicinar, desde iníci d desenvlviment, em terms de um sftware públic; ist vai prprcinar uma ecnmia relativamente grande n que diz respeit a temp necessári para a depuraçã u mdificaçã de partes d códig;

245 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 245 dcumentar suficientemente prgrama, que vai permitir uma ecnmia em hras de explicaçã a utras pessas de cm funcina prgrama u cm ele deve ser utilizad; prjetar sftware para que ele seja utilizável pr iniciantes; rtular tdas as saídas, salvar u dcumentar tdas as entradas, que pde facilitar trabalh de interpretaçã de resultads btids durante a execuçã d sftware O princípi d abus: sftware será utilizad de maneira indevida Este princípi diz respeit às manipulações incrretas que s usuáris imprimem a prgrama, seja pr descnheciment d md crret de utilizaçã, seja pr simples curisidade. Exempls destas manipulações sã a manipulaçã de arquivs de entrada de um prgrama nas mais diversas cndições (arquivs vazis, arquivs bináris, arquivs muit grandes, etc...) u incrreções sintáticas. Muitas vezes, entradas sintaticamente crretas pdem prvcar errs de execuçã (valres fra de faixa, errs de verflw, divisã pr zer, etc...). Um utr prblema é a tentativa, pr parte de usuáris, de utilizaçã de um dad sftware para uma utra finalidade que nã aquela para a qual sftware fi desenvlvid. Para levar em cnta este princípi, s cuidads que prgramadr deve ter sã s seguintes: garantir que sftware fereça alguma saída satisfatória para qualquer tip de entrada; evitar que prgrama termine de frma anrmal; chamar a atençã para entradas alteradas u saídas incrretas O princípi da evluçã: sftware será mdificad Este é utr aspect de imprtância n desenvlviment de sftware, qual está frtemente ligad cm aspect da facilidade de manutençã (u extensibilidade). É fat recnhecid que s sftwares deverã sfrer mdificações, estas pelas razões mais diversas; seja devid à detecçã de um err residual d desenvlviment; seja pr nvs requisits surgids após a instalaçã d sftware. Ist trna evidente a necessidade de desenvlver prjet e códig de md a facilitar as mdificações necessárias. A existência de um códig bem estruturad e dcumentad é pel mens 50% d trabalh reslvid. Dentr deste princípi, s cuidads a serem tmads deverã ser: desenvlviment de prgramas cm bm nível de legibilidade; a estruturaçã em cmpnentes de sftware facilmente mdificáveis; agrupar alterações visíveis a usuári e eventuais crreções em versões numeradas; manter a dcumentaçã atualizada O princípi da migraçã: sftware será instalad em utras máquinas Este últim princípi leva em cnta fat de que a vida de muits sftwares deve ultrapassar a vida da própria máquina em que ele está executand. A velcidade cm a qual as arquiteturas de cmputadr têm evluíd ns últims ans acentua a imprtância deste princípi. Um prblema relacinad a este princípi é que às vezes s prgramas sã desenvlvids explrand algumas particularidades das arquiteturas das máquinas para as quais eles estã send cncebids. Ist cria uma frte dependência d hardware, que dificulta a futura migraçã para utras arquiteturas. Ist significa, na verdade, que para um prgrama apresentar um nível satisfatóri de prtabilidade, prgramadr deve evitar amarrar-se a detalhes de hardware da máquina a invés de "aprveitá-ls". Assim, pdems sintetizar as ações a serem preparadas cm relaçã a este princípi: pensar s prgramas cm mei para slucinar prblemas e nã para instruir determinad prcessadr; utilizar as cnstruções padrnizadas das linguagens de prgramaçã u sistemas peracinais;

246 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 246 islar e cmentar tds s aspects d prgrama que envlvam a dependência d hardware. 5. O MODELO CMM A causa mais cmum d insucess ds prjets de desenvlviment de sftware é a má utilizaçã u a cmpleta indiferença as métds e ferramentas rientads à cncepçã. É pssível que, em empresas de desenvlviment de sftware nde us de metdlgias cnsistentes nã seja prática adtada, s prjets pssam ter bns resultads. Mas, em geral, estes bns resultads sã muit mais uma cnseqüência de esfrçs individuais d que prpriamente causadas pela existência de uma plítica e de uma infra-estrutura adequada à prduçã de sftware. O mdel CMM Capability Maturity Mdel fi definid pel SEI Sftware Engineering Institute cm bjetiv de estabelecer cnceits relacinads as níveis de maturidade das empresas de desenvlviment de sftware, cm respeit a grau de evluçã que estas se encntram ns seus prcesss de desenvlviment. O mdel estabelece também que prvidências as empresas pdem tmar para aumentarem, gradualmente seu grau de maturidade, melhrand, pr cnseqüência, sua prdutividade e a qualidade d prdut de sftware Cnceits básics d CMM Um Prcess de Desenvlviment de Sftware crrespnde a cnjunt de atividades, métds, práticas e transfrmações que uma equipe utiliza para desenvlver e manter sftware e seus prduts assciads (plans de prjet, dcuments de prjet, códig, cass de teste e manuais de usuári). Uma empresa é cnsiderada num mair grau de maturidade quant mais evluíd fr seu prcess de desenvlviment de sftware. A Capabilidade de um prcess de sftware está relacinada as resultads que pdem ser btids pela sua utilizaçã num u em váris prjets. Esta definiçã permite estabelecer uma estimaçã de resultads em futurs prjets. O Desempenh de um prcess de sftware representa s resultads que sã crrentemente btids pela sua utilizaçã. A diferença básica entre estes dis cnceits está n fat de que, enquant primeir, está relacinad as resultads esperads, segund, relacina-se as resultads que fram efetivamente btids. A Maturidade de um prcess de sftware estabelece s meis pels quais ele é definid, gerenciad, medid, cntrlad e efetiv, implicand num ptencial de evluçã da capabilidade. Numa empresa cm alt grau de maturidade, prcess de desenvlviment de sftware é bem entendid pr td staff técnic, graças à existência de dcumentaçã e plíticas de treinament, e que este é cntinuamente mnitrad e aperfeiçad pr seus usuáris. À medida que uma rganizaçã cresce em terms de maturidade, ela institucinaliza seu prcess de desenvlviment de sftware através de plíticas, nrmas e estruturas rganizacinais, as quais geram uma infra-estrutura e uma cultura de suprte as métds e prcediments de desenvlviment Níveis de maturidade n prcess de desenvlviment de sftware O mdel CMM define cinc níveis de maturidade n que diz respeit a prcess de desenvlviment de sftware adtad a nível das empresas, estabelecend uma escala rdinal que cnduz as empresas a lng de seu aperfeiçament. Um nível de maturidade é um patamar de evluçã de um prcess de desenvlviment de sftware, crrespndend a um degrau na evluçã cntínua de cada rganizaçã. A cada nível crrespnde um cnjunt de bjetivs que, uma vez atingids, estabilizam um cmpnente fundamental d prcess de desenvlviment de sftware, tend cm cnseqüência direta aument da capabilidade da empresa. A figura 2.1 apresenta s cinc níveis de maturidade prpsts n mdel CMM, na qual se pde bservar também estabeleciment de um cnjunt de ações que permitirã a uma empresa subir de um degrau para utr nesta escala.

247 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: Nível Inicial N nível inicial, desenvlviment de sftware é realizad de frma ttalmente ad hc, sem uma definiçã de prcesss. N cas de prblemas que venham a crrer durante a realizaçã de um prjet, a rganizaçã tem uma tendência a abandnar ttalmente s prcediments planejads e passa a um prcess de cdificaçã e testes, nde prdut btid pde apresentar um nível de qualidade suspeit. A capabilidade de uma empresa caracterizada cm nível 1 é ttalmente imprevisível, uma vez que prcess de desenvlviment de sftware é instável, sujeit a mudanças radicais freqüentes, nã apenas de um prjet a utr, mas também durante a realizaçã de um mesm prjet. Neste nível, estimaçã de custs, prazs e qualidade d prdut é alg ttalmente fra d cntext e da plítica de desenvlviment (que plítica?). Embra nã se pssa assegurar fracass de um prjet desenvlvid pr uma empresa situada neste nível, é pssível dizer que sucess é, geralmente, resultad de esfrçs individuais, variand cm as habilidades naturais, cnheciment e as mtivações ds prfissinais envlvids n prjet Nível Repetível Neste nível, plíticas de desenvlviment de sftware e tarefas de suprte a estas plíticas sã estabelecidas, planejament de nvs prjets send basead na experiência btida cm prjets anterires. Para que uma empresa pssa atingir este nível, é imprescindível institucinalizar gerenciament efetiv ds seus prjets de sftware, de md que sucess de prjets anterires pssam ser repetids ns prjets em curs. Neste nível, s requisits d sftware e trabalh a ser feit para satisfazê-ls sã planejads e supervisinads a lng da realizaçã d prjet. Sã definids padrões de prjet, e a instituiçã deve garantir a sua efetiva implementaçã. A capabilidade de uma empresa situada neste nível pde ser caracterizada cm disciplinada, em razã ds esfrçs de gerenciament e acmpanhament d prjet de sftware Nível Definid N nível definid, prcess de desenvlviment de sftware é cnslidad tant d pnt de vista d gerenciament quant das tarefas de engenharia a realizar; ist é feit através de dcumentaçã, padrnizaçã e integraçã n cntext da rganizaçã, que adta esta versã para prduzir e manter sftware.

248 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 248 Os prcesss definids nas rganizações situadas neste nível sã utilizads cm referência para s gerentes de prjet e s membrs d staff técnic, send basead em práticas prpstas pela Engenharia de Sftware. Prgramas de treinament sã prmvids a nível da rganizaçã, cm frma de difundir e padrnizar as práticas adtadas n prcess definid. As características particulares de cada prjet pdem influir n aprimrament de um prcess de desenvlviment, send que para cada prjet em desenvlviment, este pde ser instanciad. Um prcess de desenvlviment bem definid deve cnter padrões, prcediments para desenvlviment das atividades envlvidas, mecanisms de validaçã e critéris de avaliaçã. A capabilidade de uma empresa n nível 3 é caracterizada pela padrnizaçã e cnsistência, uma vez que as plíticas de gerenciament e as práticas da Engenharia de Sftware sã aplicadas de frma efetiva e repetida Nível Gerenciad N nível gerenciad, é realizada a cleta de medidas d prcess e d prdut btid, que vai permitir um cntrle sbre a prdutividade (d prcess) e a qualidade (d prdut). É definida uma base de dads para cletar e analisar s dads dispníveis ds prjets de sftware. Medidas cnsistentes e bem definidas sã, entã, uma característica das rganizações situadas neste nível, as quais estabelecem uma referência para a avaliaçã ds prcesss de desenvlviment e ds prduts. Os prcesss de desenvlviment exercem um alt cntrle sbre s prduts btids; as variações de desempenh d prcess pdem ser separadas das variações casinais (ruíds), principalmente n cntext de linhas de prduçã definidas. Os riscs relacinads a aprendizad de nvas tecnlgias u sbre um nv dmíni de aplicaçã sã cnhecids e gerenciads cuidadsamente. A capabilidade de uma rganizaçã situada este nível é caracterizada pela previsibilidade, uma vez que s prcesss sã medids e peram em limites cnhecids Nível Otimizad N nível timizad, a rganizaçã prmve cntínus aperfeiçaments n prcess de desenvlviment, utilizand para ist uma realimentaçã quantitativa d prcess e aplicand nvas idéias e tecnlgias. Os aperfeiçaments sã definids a partir da identificaçã ds pnts fracs e imperfeições d prcess crrente e d estabeleciment das alterações necessárias para evitar a crrência de falhas. Análises de cust/benefíci sã efetuadas sbre prcess de desenvlviment cm base em dads extraíds de experiências passadas. Quand s prblemas relacinads à adçã de um dad prcess de desenvlviment nã pdem ser ttalmente eliminads, s prjets sã cuidadsamente acmpanhads para evitar a crrência de prblemas inerentes d prcess Definiçã peracinal d mdel CMM O mdel CMM, além de definir s níveis de maturidade acima descrits, detalha, cada um deles, cm respeit as bjetivs essenciais de cada um e das tarefas chave a serem implementadas para que estes bjetivs sejam atingids. Para ist, fi realizad, à exceçã d nível 1, um detalhament ns diferentes níveis, estabelecend uma estrutura que permitisse caracterizar a maturidade e a capabilidade d prcess de desenvlviment de sftware. A figura 2.2 ilustra s cmpnentes relacinads a este detalhament.

249 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 249 Cm se pde ntar na figura, cada nível de maturidade é cmpst pr diversas Áreas Chave, as quais identificam um cnjunt de atividades que, quand realizadas cnjuntamente, permitem atingir s bjetivs essenciais d nível cnsiderad, aumentand a capabilidade d prcess de desenvlviment de sftware. A Tabela 2.1 apresenta as áreas chave assciadas a cada um ds níveis d CMM (à exceçã d nível 1, cm já fi explicad). Os Fatres Cmuns indicam grau de implementaçã u institucinalizaçã de uma dada Área Chave. N mdel, s Fatres Cmuns fram definids em númer de cinc, cm mstra a Tabela 2.2. As Tarefas Chave crrespndem às atividades que, uma vez realizadas de md cnjunt, cntribuirã para alcance ds bjetivs da área chave. As tarefas chave descrevem a infra-estrutura e as atividades que deverã ser implementadas para a efetiva implementaçã u institucinalizaçã da área chave. As tarefas chave crrespndem a uma sentença simples, seguida pr uma descriçã detalhada a qual pde incluir exempls. A figura 2.3 apresenta um exempl de estrutura de uma tarefa chave para a Área Chave de Planejament d Prjet de Sftware.

250 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 250

251 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: Utilizaçã d mdel CMM O bjetiv fundamental d estabeleciment deste mdel é frnecer parâmetrs para: de um lad, que as instituições que pretendam cntratar frnecedres de sftware pssam avaliar as capacidades destes frnecedres; pr utr lad, para que as empresas de desenvlviment de sftware pssam identificar quais s prcediments a serem implementads u institucinalizads n âmbit da rganizaçã de md a aumentar a capabilidade d seu prcess de sftware. Embra s dis bjetivs sejam diferentes, é definid n mdel um prcediment similar para a realizaçã ds dis tips de análise. As etapas deste prcediment, descritas a seguir, deverã ser realizadas num esquema seqüencial: seleçã de uma equipe, cujs elements serã treinads segund s cnceits básics d mdel CMM, send que estes já deverã ter cnheciments de engenharia de sftware e gerenciament de prjets; selecinar prfissinais representantes da rganizaçã, para s quais será aplicad um questinári de maturidade; analisar as respstas btidas d questinári de maturidade, prcurand identificar as áreas chave; realizar uma visita (da equipe) à rganizaçã para a realizaçã de entrevistas e revisões de dcumentaçã relacinadas a prcess de desenvlviment; as entrevistas e revisões deverã ser cnduzidas pelas áreas chave d CMM e pela análise realizada sbre questinári de maturidade; a fim da visita, a equipe elabra um relatóri enumerand s pnts frtes e s pnts fracs da rganizaçã em terms de prcess de desenvlviment de sftware; finalmente, a equipe prepara um perfil de áreas chave, que indica as áreas nde a rganizaçã atingiu/nã atingiu s bjetivs de cada área. 9.3 NORMAS E MODELOS DE QUALIDADE DE PROCESSO DE SOFTWARE Origem: BERTOLLO, Gleidsn. Dissertaçã de Mestrad. Definiçã de prcesss em um ambiente de desenvlviment de sftware. UFES Qualidade de Prcesss de Sftware Organizações bem sucedidas melhram cntinuamente seus prcesss. Cm a definiçã de um prcess padrã rganizacinal, a melhria sistemática ds prcesss é mais efetiva e eficiente se guiada pr nrmas e mdels de qualidade de prcess. A finalidade da mairia desses padrões é ajudar as rganizações de sftware a cnseguir a excelência seguind prcesss e atividades adtads pr rganizações cm alt grau de maturidade. Cntud, nã é fácil selecinar s padrões aprpriads. Existem muitas pções cm uma grande sbrepsiçã entre elas. Muitas vezes, é vantagem para uma rganizaçã de sftware usar u implementar mais de um padrã a mesm temp. Nessa situaçã, é melhr implementá-ls simultaneamente. Tal abrdagem permite as engenheirs de prcess maximizar s pnts frtes de um padrã e diminuir suas fraquezas (MUTAFELIJA, STROMBERG, 2003). A seguir, é apresentad um breve resum das principais nrmas e mdels de qualidade, a saber: ISO 9000, ISO/IEC 12207, ISO/IEC 15504, CMMI e MPS.BR. Além desses mdels e nrmas, mdel d Prcess Unificad da Ratinal (Ratinal Unified Prcess RUP) é também descrit, dada a sua ampla disseminaçã e aceitaçã ISO 9000 Em 2000, uma revisã da família de nrmas ISO 9000 Sistemas de gestã da qualidade fi publicada, substituind a versã anterir, cuja versã em prtuguês da ABNT datava de 1994.

252 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 252 Algumas nrmas da família ISO 9000 fram alteradas, utras canceladas e nvas criadas, ficand a ISO 9000 resumida a quatr nrmas (ISO, 2000b): ISO 9000 Fundaments e Vcabulári (ISO, 2000b); ISO 9001 Requisits para sistemas de gestã da qualidade (ISO, 2000a); ISO 9004 Diretrizes para Melhria de Desempenh (ISO, 2000c). ISO Diretrizes sbre auditria de sistemas de gestã da qualidade e ambiental. A principal alteraçã crreu na abrdagem adtada: mudu-se de uma perspectiva prescritiva baseada em prcediments, para práticas de gestã da qualidade baseadas em uma abrdagem de engenharia de sistemas, rientada a prcesss, buscand a satisfaçã d cliente e a melhria cntínua (MUTAFELIJA, STROMBERG, 2003). A nrma ISO 9001:2000 é a única certificadra, u seja, as rganizações pdem bter um certificad de sistema de gestã da qualidade se implementarem seus requisits. Seu bjetiv é estabelecer requisits genérics para sistema de gestã da qualidade, send aplicáveis a tdas rganizações, sem cnsiderar tip, tamanh u prdut frnecid. O padrã é basead em princípis de gestã da qualidade. Esses princípis nã estã explicitamente na parte nrmativa da nrma, mas sã rastreáveis em seus principais requisits. Os princípis sã (ISO, 2000a): fc n cliente, liderança, envlviment das pessas, abrdagem de prcess, abrdagem sistêmica para a gestã, melhria cntínua, abrdagem factual para tmada de decisã e benefícis mútus na relaçã cm s frnecedres. Organizações desenvlvem prduts e prestam serviçs através de uma sistemática definida. A cmplexidade desses prduts e serviçs pde requerer prcesss interdisciplinares que transfrmam requisits d cliente, entradas e restrições em um prdut, u mais genericamente, em uma sluçã. Esses prcesss inter-relacinads frmam um sistema, definid cm uma cmbinaçã de elements (humans, sftware e hardware) e prcesss (facilidades, equipaments, material e prcediments) que sã relacinads para satisfazer necessidades através de um cicl de vida sustentável d prdut (IEEE, 1998). A mudança de fc na nva versã da nrma teve bjetiv de encrajar a adçã da abrdagem de prcess para a gerência de uma rganizaçã. É natural que diferentes prcesss pssam interagir e s mesms devem ser gerenciads cletivamente para atingir s bjetivs rganizacinais. Para funcinarem de frma eficaz, as rganizações têm que identificar e gerenciar prcesss interrelacinads ISO/IEC A nrma NBR ISO/IEC Tecnlgia da Infrmaçã Prcesss de Cicl de Vida de Sftware (ISO/IEC, 1995) estabelece uma estrutura cmum para s prcesss de cicl de vida de sftware, cm terminlgia bem definida, que pde ser referenciada pela indústria de sftware. A estrutura cntém prcesss, atividades e tarefas que devem ser aplicads na aquisiçã, frneciment, desenvlviment, peraçã e manutençã de prduts de sftware. Esse cnjunt de prcesss, atividades e tarefas fi prjetad para ser adaptad, de acrd cm as características específicas, a uma rganizaçã, prjet u aplicaçã, que pde envlver detalhament, a adiçã e a supressã de elements de acrd cm bjetiv de utilizaçã. Seu mdel de referência de prcess frnece indicações de prcesss, descrits em terms de seus prpósits e resultads esperads, em cnjunt cm uma arquitetura que descreve as relações entre esses prcesss. Define, ainda, atividades e tarefas requeridas para implementar em alt nível tais prcesss, bjetivand atingir a capacidade desejada para cmpradres, frnecedres, desenvlvedres, mantenedres e peradres de sistemas que cntêm sftware. Na ISO/IEC sã cnsideradas três categrias de prcesss: Fundamentais, de Api e Organizacinais. Os prcesss fundamentais cnstituem um cnjunt de cinc prcesss que atendem às partes fundamentais (pessa u rganizaçã) durante cicl de vida d sftware. Os prcesss fundamentais sã: Prcess de Aquisiçã, Prcess de Frneciment, Prcess de Desenvlviment, Prcess de Operaçã e Prcess de Manutençã. Os prcesss de api auxiliam um utr prcess cm parte integrante, cm um prpósit distint, cntribuind para

253 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 253 sucess e qualidade d prjet de sftware. Um prcess de api é empregad pr utr prcess, quand necessári. Sã eles: Prcess de Dcumentaçã, Prcess de Gerência de Cnfiguraçã, Prcess de Garantia da Qualidade, Prcess de Verificaçã, Prcess de Validaçã, Prcess de Revisã Cnjunta, Prcess de Auditria e Prcess de Resluçã de Prblemas. Os prcesss rganizacinais sã empregads pr uma rganizaçã para estabelecer e implementar uma estrutura subjacente de frma a melhrar cntinuamente s seus prcesss. Sã empregads tipicamente fra d dmíni de prjets e cntrats específics; entretant, ensinaments desses prjets e cntrats cntribuem para a melhria da rganizaçã. Sã eles: Prcess de Gerência, Prcess de Infraestrutura, Prcess de Melhria e Prcess de Treinament. A nrma descreve a arquitetura ds prcesss de cicl de vida de sftware, mas nã representa uma abrdagem de implementaçã particular, nem prescreve um mdel de cicl de vida, metdlgia u técnica específica. O mdel de referência tem bjetiv de ser adaptad para uma rganizaçã, cnsiderand suas necessidades de negóci e dmínis de aplicaçã. A ISO/IEC fi riginalmente publicada em 1995 cm uma nrma internacinal. Em 1998, fi publicada a sua versã brasileira que sustenta mesm nme que a internacinal, acrescida das iniciais NBR. Em 2002 e 2004, fram feitas atualizações, chamadas de emendas 1 e 2 respectivamente, quand fram inseridas algumas melhrias. Essas melhrias criaram nvs u expandiram escp de alguns prcesss, inseriram para cada prcess seu prpósit e resultads esperads e para s nvs prcesss definiram suas atividades e tarefas. Essas mdificações têm bjetiv de representar a evluçã da área de prcesss de sftware, as necessidades vivenciadas pels usuáris da nrma e sua harmnizaçã cm a série ISO/IEC Avaliaçã de Prcesss de Sftware ISO/IEC A nrma ISO/IEC fi publicada pela primeira vez em 1998 cm a designaçã de Relatóri Técnic (ISO/IEC TR 15504) (ISO/IEC, 1998). Essa designaçã é atribuída quand assunt está ainda em desenvlviment técnic u quand existe a pssibilidade de se alcançar um entendiment para uma Nrma Internacinal. Em 2003, a ISO/IEC (ISO/IEC, 2003) fi publicada cm nrma, send rganizada em cinc partes sb títul genéric Tecnlgias de Infrmaçã Avaliaçã de Prcesss. As partes que a cmpõem sã (ISO/IEC, 2003): Parte 1: Cnceits e Vcabulári (Infrmativa) estabelece uma intrduçã geral sbre s cnceits de avaliaçã de prcesss e um glssári para s terms relacinads; Parte 2: Execuçã de uma avaliaçã (Nrmativ) define s requisits mínims para execuçã de uma avaliaçã que garanta cnsistência e repetiçã ds prcesss; Parte 3: Guia para execuçã de uma avaliaçã (Infrmativ) estabelece uma interpretaçã ds requisits para execuçã de uma avaliaçã; Parte 4: Guia para utilizaçã em prcesss de melhria e na determinaçã da capacidade de prcesss (Infrmativ) identifica a avaliaçã de prcesss cm uma atividade a ser executada cm parte de uma iniciativa de melhria de prcesss u cm parte de uma abrdagem de determinaçã de capacidade. Parte 5: Um exempl de um mdel de avaliaçã de prcesss (Infrmativ) cntém um exempl de um Mdel de Avaliaçã de Prcess basead n Mdel de Referência de Prcess definid na ISO/IEC 12207, emendas 1 e 2. A avaliaçã de prcesss é baseada num mdel bi-dimensinal, que cntém uma Dimensã de Prcess e uma Dimensã de Capacidade. A Dimensã de Prcess é cnstituída pr prcesss de cicl de vida definids n Mdel de Referência de Prcesss, qual define um cnjunt de prcesss caracterizads pr uma descriçã ds bjetivs e ds resultads. Um exempl de mdel de referência é derivad diretamente da nrma ISO/IEC emendas 1 e 2. Os prcesss encntram-se agrupads em nve categrias: Aquisiçã, Frneciment, Engenharia, Operaçã, Api, Gerência, Melhria de Prcess, Recurs e Infra-estrutura, e Reus. A nrma permite, ainda, que s mdels de referência de prcesss pssam ser desenvlvids fra d cntext da nrmalizaçã ISO, desde que preencham um cnjunt de requisits de cnfrmidade pré-estabelecids. O patrcinadr deve determinar qual mdel de referência de prcess melhr

254 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 254 atende requisit especificad u bjetiv de negóci definid, seguind guia ISO/IEC para seleçã. A Dimensã de Capacidade cnsiste numa platafrma de mediçã cmpsta pr seis níveis de capacidade e pels atributs de prcess assciads a cada nível. O resultad da avaliaçã cnsiste na determinaçã d perfil de cada um ds prcesss através da classificaçã ds respectivs atributs. A avaliaçã pde incluir, ainda, nível de capacidade atingid pr cada prcess (determinad a partir ds atributs). Os níveis de capacidade, rdenads de frma crescente de 0 (zer) a 5 (cinc), sã: Incmplet, Executad, Gerenciad, Estabelecid, Previsível e Otimizad. Os atributs de prcess sã: Nível 1 Execuçã de Prcess; Nível 2 Gerência da Execuçã e Gerência de Prduts de Trabalh; Nível 3 Definiçã de Prcess e Implementaçã de Prcess; Nível 4 Mediçã de Prcess e Cntrle de Prcess; Nível 5 Invaçã de Prcess e Otimizaçã de Prcess CMMI Em 1995, Sftware Engineering Institute (SEI) criu um mdel de maturidade e capacidade para rganizações de sftware, SW-CMM. O mdel cntém elements essenciais para um prcess efetiv em diversas disciplinas e descreve um caminh para as rganizações evluírem seus prcesss de um nível imatur para um nível disciplinad. Assim cm fi elabrad um mdel para sftware, diversas utras disciplinas criaram s seus mdels de maturidade cbrind utras áreas de interesse, tais cm SA-CMM (Mdel de Maturidade e Capacidade para Aquisiçã de Sftware) e SE-CMM (Mdel de Maturidade e Capacidade para Engenharia de Sistemas). Embra esses mdels tenham sid bastante úteis para muitas rganizações, us de múltipls mdels trnu-se prblemátic. Pr nã serem desenvlvids de frma integrada, diferenças na arquitetura, cnteúd e abrdagem aumentaram s custs de treinament, avaliações e atividades de melhria. Pr estas razões, SEI elabru CMMI (CMM Integratin) (CHRISSIS et al., 2003) cm bjetiv de apiar a melhria de prcesss e prduts, diminuind a redundância e eliminand a incnsistência que surge a se utilizar diverss mdels independentes. Esse bjetiv é atingid através da integraçã ds diverss CMMs numa estrutura única, tds cm a mesma terminlgia, prcesss de avaliaçã e estrutura. O prjet também se precupu em trnar CMM cmpatível cm a nrma ISO/IEC 15504, de md que avaliações em um mdel sejam recnhecidas cm equivalentes as d utr (CHRISSIS et al., 2003). O CMMI ferece duas abrdagens diferentes para a melhria de prcesss, send cnhecidas pr mdel em estágis e mdel cntínu. A representaçã pr estágis prescreve a rdem para implementaçã de cada área de prcess de acrd cm níveis de maturidade, que definem um caminh de melhria para uma rganizaçã d nível Inicial para nível Otimizad. Atingind um nível de maturidade, garante-se uma base adequada para buscar próxim estági. A representaçã cntínua ferece uma abrdagem flexível para melhria de prcesss. Uma rganizaçã pde esclher melhrar a qualidade de um prcess específic u trabalhar em diversas áreas de frma alinhada as bjetivs de negóci. Os níveis de capacidade sã usads para medir uma área, ind de um prcess nã executad para um prcess timizad. Existem algumas limitações de esclha, devid à dependência entre as áreas de prcesss. As duas representações cntêm s mesms cmpnentes, usand s mesms cnceits. A diferença entre as representações está na abrdagem para melhria de prcesss. Se uma rganizaçã planeja atingir uma maturidade rganizacinal, deve selecinar a representaçã pr estágis. Se uma rganizaçã tem interesse na capacidade de um prcess específic, deve selecinar a representaçã cntínua. O CMMI é estruturad em terms de áreas de prcess (Prcess Area PA), que cnsistem em práticas relacinadas que cletivamente satisfazem um cnjunt de bjetivs. Um bjetiv genéric descreve a institucinalizaçã requerida para atingir um nível de capacidade (representaçã cntínua) u de maturidade (representaçã pr estági). Cada bjetiv genéric é assciad a um

255 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 255 cnjunt de práticas genéricas que descrevem atividades requeridas para a institucinalizaçã de prcesss em uma determinada área de prcess. Cada área de prcess cntém, ainda, bjetivs específics e práticas específicas, que descrevem atividades essenciais n atendiment as bjetivs específics. Os cmpnentes d mdel CMMI pdem, ainda, ser agrupads em três categrias: requerid, esperad e infrmativ. A Figura 2.2 apresenta esses cmpnentes MPS.BR O MPS.BR (Melhria de Prcess d Sftware Brasileir) (SOFTEX, 2005) é um mdel para avaliaçã e melhria d prcess de sftware. A base técnica é cmpsta pelas nrmas NBR ISO/IEC e suas emendas 1 e 2, e a ISO/IEC 15504, além de cbrir td cnteúd d mdel CMMI. O MPS.BR baseia-se ns cnceits de maturidade e capacidade de prcess para a avaliaçã e melhria da qualidade e prdutividade de prduts de sftware e serviçs crrelats. Dentr desse cntext, MPS.BR pssui três cmpnentes: Mdel de Referência (MR-MPS), que cntém s requisits a serem atendids pelas rganizações, bem cm s níveis de maturidade e capacidade, e s prcesss; Mdel de Avaliaçã (MA-MPS), que cntém prcess de avaliaçã, s requisits para s avaliadres e s requisits para averiguaçã da cnfrmidade a MR-MPS; Mdel de Negóci (MN-MPS), que cntém as regras para implantaçã d MPS.BR pelas empresas de cnsultria, de sftware e avaliaçã. O MPS.BR é descrit através de dcuments em frmat de guias: Guia Geral: cntém a descriçã geral d MPS.BR e detalha Mdel de Referência (MR- MPS), seus cmpnentes e as definições cmuns necessárias para seu entendiment e aplicaçã. Guia de Aquisiçã: cntém recmendações para a cnduçã de cmpras de sftware e serviçs crrelats. Fi descrit cm frma de apiar as instituições que queiram adquirir prduts de sftware e serviçs crrelats apiand-se n MR-MPS. Guia de Avaliaçã: cntém a descriçã d prcess de avaliaçã, s requisits para avaliadr, s requisits para a avaliaçã, métd e s frmuláris para apiar a avaliaçã.

256 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 256 O Mdel de Referência MR-MPS define níveis de maturidade cm uma cmbinaçã entre prcesss e capacidade de prcesss. Os níveis de maturidade estabelecem patamares de evluçã de prcess, caracterizand estágis de melhria de implementaçã de prcesss na rganizaçã. O MR-MPS define sete níveis de maturidade: A (Em Otimizaçã), B (Gerenciad Quantitativamente), C (Definid), D (Largamente Definid), E (Parcialmente Definid), F (Gerenciad) e G (Parcialmente Gerenciad). A escala de maturidade se inicia n nível G e prgride até nível A. Para cada um desses sete níveis de maturidade fi atribuíd um perfil de prcesss e de capacidade de prcesss que indica nde a rganizaçã tem que clcar esfrç para melhria, de frma a atender s bjetivs de negóci. A capacidade d prcess é um cnjunt de atributs de prcess descrit em terms de resultads. A capacidade estabelece grau de refinament e institucinalizaçã cm que prcess é executad na rganizaçã. À medida que evlui ns níveis, um mair ganh de capacidade para desempenhar prcess é atingid pela rganizaçã. A capacidade d prcess pssui cinc atributs de prcess, que sã detalhads, pr sua vez, em terms ds resultads para alcance cmplet d atribut. Os atributs de prcess d MPS.BR sã: AP 1.1: O prcess é executad; AP 2.1: O prcess é gerenciad; AP 2.2: Os prduts de trabalh d prcess sã gerenciads; AP 3.1: O prcess é definid e AP 3.2: O prcess está implementad. O prgress e a btençã de um nível de maturidade crrem quand sã atendids tds s resultads e s prpósits ds prcesss e ds atributs de prcess relacinads àquele nível e as anterires. A Tabela 2.1 apresenta s prcesss de cada nível de maturidade e a capacidade exigida.

257 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: REVISÕES Origem: Engenharia de Sftware, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. Para se cntrlar a qualidade em um prjet de sftware, uma abrdagem bastante usada cnsiste em se realizar revisões. Nas revisões, prcesss, dcuments e utrs artefats sã revisads pr um grup de pessas, cm bjetiv de verificar se s mesms estã em cnfrmidade cm s padrões rganizacinais estabelecids e se prpósit de cada um deles está send atingid, incluind atendiment a requisits d cliente e ds usuáris. Assim, bjetiv de uma revisã é detectar errs e incnsistências em artefats e prcesss, sejam eles relacinads à frma, sejam em relaçã a cnteúd, e apntá-ls as respnsáveis pela sua elabraçã. O prcess de revisã cmeça cm planejament da revisã, quand uma equipe de revisã é frmada, tend à frente um líder. A equipe de revisã deve incluir s membrs da equipe que pssam efetivamente ser úteis para atingir bjetiv da revisã. Muitas vezes, a pessa respnsável pela elabraçã d artefat a ser revisad integra a equipe de revisã. Dand iníci a prcess de revisã prpriamente dit, nrmalmente, autr d artefat apresenta mesm e descreve a perspectiva utilizada para a sua cnstruçã. Além diss, prpósit da revisã deve ser previamente infrmad e material a ser revisad deve ser entregue cm antecedência para que cada membr da equipe de revisã pssa avaliá-l.

258 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 258 Uma vez que tds estejam preparads, uma reuniã é cnvcada pel líder. Essa reuniã deverá ser relativamente breve (duas hras, n máxim), uma vez que tds já estã preparads para a mesma. Durante a reuniã, líder rientará prcess de revisã, passand pr tds s aspects relevantes a serem revists. Tdas as cnsiderações ds demais membrs da equipe de revisã devem ser discutidas e as decisões registradas, dand rigem a uma ata de reuniã de revisã, cntend uma lista de defeits encntrads. Revisões de Qualidade Origem: Engenharia de Sftware, Ian Smmerville, 2007 As revisões sã métds de validaçã de qualidade de um prcess u prdut amplamente usads. Envlvem um grup de pessas que examina parte u td de um prcess de sftware, sistema u sua dcumentaçã assciada para descbrir prblemas ptenciais. As cnclusões da revisã sã frmalmente registradas e passadas para autr u quem mais fr respnsável pr crrigir s prblemas detectads. Os sftwares u dcuments pdem ser assinads em uma revisã, que significa que prgress para próxim estági de desenvlviment fi aprvad pela gerência. Existem diferentes tips de revisã, cm bjetivs diferentes: Inspeções para remçã de defeits (prdut); Revisões para avaliaçã de prgress (prdut e prcess); Revisões de qualidade (prdut e padrões). Funções de revisã: Funçã de qualidade é parte d prcess geral de gerenciament de qualidade. Funçã de gerenciament de prjet frnecem infrmações para s gerentes de prjet. Funçã de treinament e cmunicaçã cnheciment d prdut é passad entre s membrs da equipe de desenvlviment. O principal bjetiv é a descberta de defeits e incnsistências de sistema, e apntá-ls para prjetista u autr d dcument. Quaisquer dcuments prduzids n prcess pdem ser revisads, nã se restringind apenas a códig-fnte. As equipes de revisã devem ser relativamente pequenas, apesar de s membrs de tal equipe pderem cnvidar utrs membrs a integrar temprariamente a equipe durante a realizaçã de uma revisã específica. As revisões devem ser bem curtas, n máxim duas hras. A reuniã de revisã englba basicamente percrrer dcument, havend um mderadr e um membr que realiza registr da revisã. O mderadr será respnsável pr garantir que as mudanças necessárias indicadas durante a reuniã sejam realizadas. Dependend da quantidade de alteraçã prpsta uma revisã de acmpanhament pde ser rganizada. Sbre a revisã realizada: Os registrs devem ser sempre mantids para revisões de qualidade, de maneira frmal; Os cmentáris feits durante a revisã devem ser classificads: Nenhuma açã. Nenhuma mudança n sftware u na dcumentaçã é necessária; Se referir a repar. O prjetista u prgramadr deve crrigir um defeit identificad;

259 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 259 Recnsiderar prjet glbal. O prblema identificad na revisã tem impact sbre utras partes d prjet. Algum julgament geral deve ser feit sbre a maneira mais adequada em terms de cust para reslver prblema; Os errs de requisits e de especificaçã devem ser cmunicads a cliente. 9.5 DOCUMENTAÇÃO Origem: Engenharia de Sftware, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. A dcumentaçã prduzida em um prjet de sftware é de suma imprtância para se gerenciar a qualidade, tant d prdut send prduzid, quant d prcess usad para seu desenvlviment. N desenvlviment de sftware, sã prduzids diverss dcuments, dentre eles, dcuments descrevend prcesss (plan de prjet, plan de qualidade etc.), registrand requisits e mdels d sistema (dcuments de especificaçã de requisits, análise e prjet) e apiand us d sistema gerad (manual d usuári, ajuda n-line, tutriais etc). Uma dcumentaçã de qualidade prpicia uma mair rganizaçã durante desenvlviment de um sistema, facilitand mdificações e futuras manutenções n mesm. Além diss, reduz impact da perda de membrs da equipe, reduz temp de desenvlviment de fases psterires, reduz temp de manutençã e cntribui para reduçã de errs, aumentand assim, a qualidade d prcess e d prdut gerad. Dessa frma, a criaçã da dcumentaçã é tã imprtante quant a criaçã d sftware em si [4]. Há, prtant, a necessidade de se definir um prcess para cntrlar a dcumentaçã de uma rganizaçã, dit prcess de dcumentaçã, incluind atividades de planejament, análise, aprvaçã u reprvaçã, identificaçã de alterações, situaçã da revisã atual, dispnibilidade das versões pertinentes de dcuments aplicáveis, dentre utras. Algumas dessas atividades estã relacinadas cm cntrle e a garantia da qualidade de sftware, utras cm a gerência da cnfiguraçã d sftware, cnfrme discutid a seguir. É imprtante ntar que planejament da dcumentaçã tem uma estreita relaçã cm prcess de sftware definid para prjet. Ou seja, s dcuments a serem gerenciads sã aqueles prevists cm saídas das atividades d prcess. Assim, tend sid definid prcess d prjet, planejament da sua dcumentaçã cnsiste apenas em selecinar quais artefats, dentre s muits prduzids a lng d prcess, serã efetivamente submetids à gerência de cnfiguraçã de sftware e a cntrle e garantia da qualidade. Padrões de Dcumentaçã Origem: Engenharia de Sftware, Ian Smmerville, 2007 Os padrões de dcumentaçã em um prjet de sftware sã particularmente imprtantes, pis s dcuments sã a manifestaçã tangível d sftware. Tips de padrões de dcumentaçã: Padrões de prcess de dcumentaçã - Relacinad a md cm s dcuments devem ser desenvlvids, validads e mantids; Padrões de dcuments - Relacinad a cnteúd, à estrutura e à aparência de dcuments; Padrões de intercâmbi de dcuments - Relacinad à cmpatibilidade de dcuments eletrônics. Os padrões de prcess de dcumentaçã definem prcess para prduzir dcuments. O que envlve estabelecer: prcediments para desenvlviment de dcuments, ferramentas a serem

260 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 260 utilizadas, prcediments de verificaçã e refinament para garantia de qualidade. Tais prcesss devem ser suficientemente flexíveis para lidar cm tds s tips de dcuments. É uma ba prática utilizar mesm estil para tds s dcuments gerads durante prcess de desenvlviment de sftware. A figura a seguir é um mdel de prcess de dcumentaçã. Alguns exempls de padrões de dcuments que pdem ser desenvlvids: Padrões de identificaçã de dcuments - Cm s dcuments sã unicamente identificads. Padrões de estrutura de dcuments - Estrutura padrã para dcuments de prjet. Padrões de apresentaçã de dcuments - Definem fntes e estils, us de lgtips, etc. Padrões de atualizaçã de dcuments - Definem cm as mudanças nas versões anterires sã refletidas em um dcument. Padrões de Intercâmbi de dcuments Padrões para intercâmbi permitem que dcuments eletrônics sejam trcads, enviads pel crrei, etc. Dcuments sã prduzids usand sistemas e cmputadres diferentes. Mesm quand ferramentas padrnizadas sã usadas, s padrões sã necessáris para definir cnvenções para seu us, pr exempl, us de flhas de estil e macrs. Necessidade de arquivament. O temp de vida ds sistemas de prcessament de text pde ser muit menr que temp de vida d sftware que está send dcumentad. Um padrã de arquivament pde ser definid para assegurar que dcument pssa ser acessad n futur. 9.6 GERÊNCIA DE CONFIGURAÇÃO Origem: Engenharia de Sftware, Ntas de Aula, prf. Ricard Falb, UFES, Departament de Infrmática. Durante prcess de desenvlviment de sftware, váris artefats sã prduzids e alterads cnstantemente, evluind até que seus prpósits fundamentais sejam atendids. Ferramentas de sftware, tais cm cmpiladres e editres de text, e prcesss também pdem ser substituíds

261 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 261 pr versões mais recentes u mesm pr utras, n cas de ferramentas. Prém, cas essas mudanças nã sejam devidamente dcumentadas e cmunicadas, pderã acarretar diverss prblemas, tais cm: dis u mais desenvlvedres pdem estar alterand um mesm artefat a mesm temp; nã se saber qual a versã mais atual de um artefat; nã se refletir alterações ns artefats impactads pr um artefat em alteraçã. Esses prblemas pdem gerar váris transtrns cm incmpatibilidade entre s grups de desenvlviment, incnsistências, retrabalh, atras na entrega e insatisfaçã d cliente. Assim, para que esses transtrns sejam evitads, é de suma imprtância acmpanhament e cntrle de artefats, prcesss e ferramentas, através de um prcess de gerência de cnfiguraçã de sftware, durante td cicl de vida d sftware [5]. A Gerência de Cnfiguraçã de Sftware (GCS) visa estabelecer e manter a integridade ds itens de sftware a lng de td cicl de vida d sftware, garantind a cmpleteza, a cnsistência e a crreçã de tais itens, e cntrland armazenament, a manipulaçã e a distribuiçã ds mesms. Para tal, tem de identificar e dcumentar s prduts de trabalh que pdem ser mdificads, estabelecer as relações entre eles e s mecanisms para administrar suas diferentes versões, cntrlar mdificações e permitir auditria e a elabraçã de relatóris sbre estad de cnfiguraçã. Pels bjetivs da GCS, pde-se ntar que ela está diretamente relacinada cm as atividades de garantia da qualidade de sftware. As atividades da GCS pdem ser resumidas em: Planejament da GCS: Um plan deve ser elabrad descrevend as atividades da gerência de cnfiguraçã, prcediments e respnsáveis pela execuçã dessas atividades. Identificaçã da Cnfiguraçã: refere-se à identificaçã ds itens de sftware e suas versões a serem cntrladas, estabelecend linhas básicas. Cntrle de Versã: cmbina prcediments e ferramentas para administrar diferentes versões ds itens de cnfiguraçã criads durante prcess de sftware. Cntrle de Mdificaçã: cmbina prcediments humans e ferramentas autmatizadas para cntrlar as alterações feitas em itens de sftware. Para tal, seguinte prcess é nrmalmente realizad: slicitaçã de mudança, aprvaçã u rejeiçã da slicitaçã, registr de retirada para alteraçã (check-ut), análise, avaliaçã e realizaçã das alterações, revisã e registr da realizaçã das alterações (check-in). Auditria de Cnfiguraçã: visa avaliar um item de cnfiguraçã quant a características nã cnsideradas nas revisões, tal cm se s itens relacinads as slicitads fram devidamente atualizads. Relat da situaçã da cnfiguraçã: refere-se à preparaçã de relatóris que mstrem a situaçã e históric ds itens de sftware cntrlads. Tais relatóris pdem incluir, dentre utrs, númer de alterações ns itens, as últimas versões ds mesms e identificadres de liberaçã. Gerenciament de Cnfiguraçã Origem: Engenharia de Sftware, Ian Smmerville, 2007 Nvas versões de sistemas de sftware sã criadas quand eles: Mudam para máquinas/os diferentes; Oferecem funcinalidade diferente; Sã cnfigurads para requisits de usuáris particulares. O gerenciament de cnfiguraçã está relacinad a desenvlviment e us de padrões e prcediment para gerenciament de sistemas de sftware em desenvlviment. O CM pde ser vist cm parte de um prcess mais geral de gerenciament de qualidade.

262 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 262 Cnsiderand que requisits de sistemas sempre mudam e as mudanças devem cmpr uma nva versã d sistema, é precis ter uma rastreabilidade de qual versã cntém quais mudanças, a fim de evitar prblemas. É cnsiderad que: Mudança de sistema é uma atividade de equipe; O CM (Cnfiguratin Management) tem pr bjetiv cntrlar s custs e esfrç envlvids na realizaçã das mudanças em um sistema. Quand liberads para CM, s sistemas de sftware sã chamads, algumas vezes, de baselines, vist que sã um pnt de partida para desenvlviment psterir. Há muitas razões pr que s sistemas existem em diferentes cnfigurações. Cnfigurações pdem ser prduzidas para diferentes cmputadres, para diferentes sistemas peracinais, incrprand funções especificadas de clientes, etc. Os gerentes de cnfiguraçã sã respnsáveis pr manter a rastreabilidade das diferenças entre versões de sftware, para assegurar que as nvas versões sejam derivadas de maneira cntrlada e liberar nvas versões para clientes certs n mment cert. Padrões de CM O CM deve ser sempre basead em um cnjunt de padrões que sã aplicads dentr de um rganizaçã. Tais padrões devem definir cm s itens sã identificads, cm as mudanças sã cntrladas e cm as nvas versões sã gerenciadas. Eles pdem ser baseads em padrões de CM externs (pr exempl, padrã IEEE para CM). Alguns padrões existentes sã baseads em um mdel de prcess cascata nvs padrões de CM sã necessáris para desenvlviment evlucinári. Para prver um desenvlviment incremental, algumas rganizações desenvlveram uma abrdagem mdificada para gerenciament de cnfiguraçã que suprta desenvlviment atual e teste de sistema. Ela é baseada ns seguintes cmpnentes: Um hrári (digams 14:00 hras) para entrega de cmpnentes d sistema é acrdad; Uma nva versã de um sistema é cnstruíd a partir de cmpnentes pela cmpilaçã e ligaçã desses cmpnentes; Essa nva versã é entregue para teste usand testes predefinids; Os defeits que sã descberts durante teste sã dcumentads e enviads para s desenvlvedres d sistema. E serã crrigids para a versã seguinte.

263 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 263 Cnstruçã frequente d Sistema É mais fácil encntrar prblemas que surgem das interações de cmpnentes n iníci d prcess. Iss encraja teste unitári s desenvlvedres estã sb pressã para nã quebrar a cnstruçã. Um prcess de gerenciament rigrs de mudanças é necessári para manter a rastreabilidade ds prblemas que fram descberts e reparads. Planejament de gerenciament de cnfigurações Tds s prduts d prcess de sftware pdem ser gerenciads: Especificações, Prjets, Prgramas, Dads de teste, Manuais de usuári. Milhares de dcuments separads pdem ser gerads para um sistema grande e cmplex de sftware. Trnand necessári estabeleciment de um plan de trabalh. O PLANO DE CM deve: Definir s tips de dcuments a serem gerenciads e um esquema de identificaçã de dcuments; Definir quem tem a respnsabilidade pels prcediments e pela criaçã de baselines de CM; Definir plíticas para cntrle de mudanças e gerenciament de versões; Definir s registrs de CM que devem ser mantids; Descrever as ferramentas que devem ser usadas para prcess de CM e quaisquer limitações de seu us; Definir prcess de us da ferramentas; Definir a base de dads de CM usada para registrar infrmações de cnfiguraçã; Pde incluir infrmações, tais cm CM de sftware extern, a auditria de prcesss, etc. Identificaçã de Item de Cnfiguraçã Prjets grandes prduzem tipicamente milhares de dcuments que devem ser unicamente identificads. Alguns desses dcuments devem ser mantids pel temp de vida d sftware. E assim é precis manter a rastreabilidade das infrmações necessárias, u seja, é precis ter um esquema de identificaçã cnsistente. Nem tds s arquivs prduzids devem ser clcads sbre cntrle de cnfiguraçã. Se frem dcuments tempráris pdem ser tratads de frma mais simplificada. O esquema de identificaçã de dcuments deve ser definid de tal md que dcuments relacinads tenham nmes relacinads. Um esquema de hierarquia cm múltipls nmes é prvavelmente a abrdagem mais flexível. Exempl: PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE

264 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 264 Banc de Dads de Cnfiguraçã Um banc de dads de cnfiguraçã nã inclui apenas infrmações sbre itens de cnfiguraçã. Pde também registrar infrmações sbre usuáris de cmpnentes, clientes de sistemas, platafrmas de execuçã, mudanças prpstas, etc. Tdas as infrmações de CM devem ser mantidas em uma base de dads de cnfiguraçã. Iss deve permitir cnsultas sbre cnfigurações a serem respndidas: Quem tem uma versã particular de sistema? Qual platafrma é necessária para uma versã particular? Quais versões sã afetadas pela mudança d cmpnente X? Quants defeits fram reprtads na versã T? A base de dads de CM deve ser preferivelmente ligada a sftware que está send usad para gerenciament. Tal base pde ser parte de um ambiente integrad para apiar desenvlviment de sftware (A base de dads de CM e s dcuments gerenciads sã tds mantids n mesm sistema). Ferramentas CASE pdem ser integradas de tal md que há um relacinament próxim entre ferramentas CASE e ferramentas de CM. Mais cmumente, n entant, a base de dads de CM é mantida separadamente, vist que iss é mais barat e mais flexível. Gerenciament de Mudanças Sistemas de sftware estã sujeits às slicitações cntínuas de mudanças: De usuáris; De desenvlvedres; De frças de mercad. O gerenciament de mudanças está relacinad à manutençã da rastreabilidade dessas mudanças e à garantia de que elas sejam implementadas da maneira mais adequada em terms de cust. Prcediments de gerenciament de mudança dizem respeit à análise de cust e benefíci das mudanças prpstas, à aprvaçã das mudanças viáveis e à rastreabilidade de quais cmpnentes d sistema fram alterads. O prcess de gerenciament de mudanças (cm prpst na figura abaix) deve surtir efeit quand sftware / dcumentaçã sã clcads em baseline pela equipe de gerenciament de cnfigurações.

265 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 265 O primeir estági n prcess de gerenciament de cnfigurações é cmpletar um frmulári de slicitaçã de mudança (cm prpst na figura abaix). A definiçã de um frmulári de slicitaçã de mudança é parte d prcess de planejament de CM. Esse frmulári registra a mudança prpsta, requisitante da mudança, a razã pela qual a mudança fi sugerida e a urgência da mudança (a partir d requisitante da mudança). Também registra a avaliaçã da mudança, a análise d impact, cust da mudança e as recmendações (pessal de manutençã de sistema). O mair prblema n gerenciament de mudanças é acmpanhament d status da mudança. N entant, ferramentas de acmpanhament de mudanças acmpanham status de cada slicitaçã de mudança e asseguram, autmaticamente, que as slicitações de mudança sejam enviadas para as pessas certas n temp cert. Sã integrads a sistemas de , permitind a distribuiçã eletrônica da slicitaçã de mudança.

266 Disciplina: Engenharia de Sftware Matéria: Garantia e Cntrle de Qualidade Página: 266 As mudanças devem ser revisadas pr um grup extern, que decide se elas sã u nã adequadas em terms de cust, a partir de um pnt de vista estratégic u rganizacinal a invés de um pnt de vista técnic. O grup deve ser independente d respnsável de prjet pel sistema. Esse grup é, algumas vezes, chamad de Cmitê de Cntrle de mudanças (CCB) e pde cnter representantes d cliente e d pessal frnecedr. Prcedência histórica É um registr das mudanças realizadas em um dcument u um cmpnente de códig. Deve registrar, em linhas gerais, a mudança feita, a lógica da mudança, quem fez a mudança e quand fi implementada. Pde ser incluída cm um cmentári n códig. Se um estil de cabeçalh padrã é usad para a prcedência histórica, as ferramentas pdem prcessar iss autmaticamente. Gerenciament de versões e release É precis: Definir um esquema para identificaçã e manutençã da rastreabilidade das versões de sistema. Planejar quand uma nva versã de sistema será prduzida. Assegurar que prcediments e ferramentas de gerenciament das versões sejam adequadamente aplicads. Planejar e distribuir releases d nv sistema. Versões / Variantes / Releases Versã - É uma instância de um sistema que é funcinalmente distinta, de alguma maneira, de utras instâncias de um sistema. A alteraçã pde envlver funções, desempenhs aprimrads, errs crrigids, mudanças de cnfiguraçã de hardware/sftware; Variante - É uma instância de um sistema que é funcinalmente idêntica, mas nã funcinalmente distinta de utras instâncias de um sistema. Sã versões cm variações pequenas; Release - É uma versã de um sistema distribuída para s usuáris fra da equipe de desenvlviment.