FATEC - Faculdade de Tecnologia de São Paulo

Transcrição

1 FATEC - Faculdade de Tecnlgia de Sã Paul Departament de Tecnlgia da Infrmaçã TELMA CAROLINA MENDES ESTUDO DA GARANTIA DE QUALIDADE DE SOFTWARE UTILIZANDO A METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS CRIADA POR UMA INSTITUIÇÃO FINANCEIRA Sã Paul, Dezembr de 2011

2 TELMA CAROLINA MENDES ESTUDO DA GARANTIA DE QUALIDADE DE SOFTWARE UTILIZANDO A METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS CRIADA POR UMA INSTITUIÇÃO FINANCEIRA Mngrafia submetida cm exigência parcial para a btençã d Grau de Tecnólg em Prcessmant de Dads Orientadr: Carls Hide Arima Sã Paul, Dezembr de

3 RESUMO MENDES, Telma Carlina. Estud da garantia de qualidade de sftware utilizand a metdlgia de desenvlviment de sistemas criada pr uma Instituiçã Financeira. Sã Paul, Trabalh de Cnclusã de Curs (Prcessament de Dads) FATEC-SP. Em busca de sftwares de qualidade empresas vem fazend us de metdlgias n prcess de desenvlviment de sftware cm um mei de garantir a qualidade de sftware. Afim de garantir a prduçã de sistemas cm qualidade é que uma determinada instituiçã financeira adtu uma metdlgia única para tdas as empresas d grup. A metdlgia adtada nasceu dentr da própria empresa, e fi elabrada de tal maneira a atender as necessidades e as expectativas da instituiçã de bter sistemas cnfiáveis, eficientes e que nã apresentassem um vlume grande de prblemas em prduçã. O bjetiv deste trabalh é identificar, quais as características de garantia de qualidade de sftware que pdem ser encntradas dentr da Metdlgia de Desenvlviment de Sistemas criada pela Instituiçã Financeira. Dentr desta pesquisa fi feit estud sbre que é a qualidade, cm fi elabrada a metdlgia que é utilizada pela Instituiçã Financeira e d que ela é cmpsta. A partir destes estuds fi realizada uma análise para verificar se a metdlgia pssuia itens suficientes para garantir um sftware de qualidade e, quais fram as características de garantia de qualidade de sftware encntradas, u nã, em cada uma destas fases. Palavras-chave: qualidade; metdlgia; sftware. 3

4 ABSTRACT MENDES, Telma Carlina. Estud da garantia de qualidade de sftware utilizand a metdlgia de desenvlviment de sistemas criada pr uma Instituiçã Financeira. Sã Paul, Trabalh de Cnclusã de Curs (Prcessament de Dads) FATEC-SP. Lking fr sftware quality cmpanies are making use f methdlgies in the prcess f sftware develpment as a means f ensuring sftware quality. In rder t ensure the prductin f quality systems is that a particular financial institutin has adpted a unique methdlgy t all grup f the cmpany. The methdlgy adpted was brn within the cmpany, and is designed in such a way that meets the needs and expectatins f the institutin t btain reliable systems, efficient and des nt present a large amunt f prblems in prductin. The bjective f this study is identifying which features f quality assurance f sftware that can be fund within the Systems Develpment Methdlgy created by the Financial Institutin. Within this research was the study dne n what is quality, as the methdlgy that was develped is used by the financial institutin and that it is cmpsed. Frm these studies, an analysis was perfrmed t verify that the methdlgy has enugh items t ensure the quality sftware, and what were the characteristics f sftware quality assurance fund r nt in each f these stages. Key terms: quality; methdlgy; sftware. 4

5 LISTA DE FIGURAS Figura 1 - Template d Rteir de Teste Funcinal Figura 2 - Imagem da janela d sistema de flux de aprvaçã

6 LISTA DE TABELAS Tabela 1 - Quantidade de empresas certificadas pela ISO ns últims dez ans Tabela 2 - Matriz de Qualidade

7 SUMÁRIO 1. INTRODUÇÃO Breve históric d us das metdlgias para desenvlviment de sistemas Identificaçã e justificativa d prblema Objetivs Objetiv geral Objetivs específics Metdlgia QUALIDADE Cnceits de qualidade As diferentes percepções de qualidade Qualidade d prcess O que é qualidade de sftware Cm é medida a qualidade de um sftware METODOLOGIA A Metdlgia de Desenvlviment de Sistemas utilizada pela instituiçã financeira cm garantia de qualidade de seus sistemas Expectativas na implantaçã desta Metdlgia de Desenvlviment de Sistemas Fases da MDS Metdlgia de Desenvlviment de Sistemas Escp e Estimativa Análise Desenh Físic Cnstruçã Teste Implantaçã Gestã de Mudanças d Prjet Checklist da Metdlgia de Desenvlviment de Sistemas O preenchiment ds itens d checklist ESTUDO E IDENTIFICAÇÃO DOS PROCESSOS DE GARANTIA DA QUALIDADE NA METODOLOGIA DE DESENVOLVIMENTO DO SISTEMA CRIADO POR UMA INSTITUIÇÃO FINANCEIRA Matriz de Qualidade Estud das fases da Metdlgia de Desenvlviment de Sistemas criada pr uma determinada Instituiçã Financeira Escp e Estimativa Análise Desenh Físic Teste Implantaçã Gestã de Mudanças CONCLUSÃO REFERÊNCIAS

8 1. INTRODUÇÃO 1.1. Breve históric d us das metdlgias para desenvlviment de sistemas Segund PFLEEGER (2004), um métd é um prcediment frmal, que utiliza técnicas e pde também usar ferramentas para prduzir algum resultad. A utilizaçã de uma ferramenta em um métd pde trazer resultads mais preciss, melhrand a qualidade d prdut resultante. YOURDON (1991) define metdlgia cm uma série recmendada de passs e prcediments que devem ser seguids para bter-se desenvlviment de um sistema de infrmaçã. E, ainda segund a definiçã de AVISON e FITZGERALD (1997), é cnjunt frmad pr prcediments, técnicas, ferramentas e dcumentaçã que auxiliará s respnsáveis pel desenvlviment de sistemas em seus esfrçs na implementaçã de um nv sistema de infrmaçã. Uma metdlgia cnsistirá de fases, cada uma cnsistind de subfases, que rientarã estes respnsáveis na esclha das técnicas que deverã ser mais aprpriadas a cada estági d prjet e também auxiliá-ls a planejar, gerenciar, cntrlar e avaliar prjet d sistema de infrmaçã. As metdlgias fram criadas a partir da necessidade de se bter um prdut final cm um mínim de qualidade. A Metdlgia Kaizen trata justamente de frnecer técnicas para que um prdut passe a ter qualidade cm cust reduzid. O prcess utilizad pr essa metdlgia envlve desde um funcinári de nível hierárquic baix até a gerência, nde fc principal da metdlgia é cmprmetiment de tds para se atingir bjetiv sugerid. Segund criadr da metdlgia, Masaaki Imai: Os executivs cidentais tendem a acreditar que melhrias substanciais custam muit dinheir. Parecem pensar que devem ter estad da arte da tecnlgia e s equipaments mais avançads para melhrar., quand na realidade um prdut de qualidade nã está relacinad a uma matériaprima de altíssima qualidade u a uma mã de bra especializada, que é 8

9 realmente essencial sã s esfrçs de melhria cntínua, executads pr tds, send que seu fc central é a busca pela eliminaçã ds desperdícis. Ns primórdis d desenvlviment de sistemas nã eram utilizadas as metdlgias, mdel usad dentr das empresas era "cdifica-crrige", nde desenvlvedr recebia a tarefa de desenvlver um prgrama. Ele, sem dcumentar nada, partia para a cdificaçã; se prgrama apresentasse errs, era entã realizada uma crreçã e enviad nvamente para cliente. Cm passar ds ans, ntu-se a dificuldade para realizar a manutençã ns prgramas desenvlvids dessa maneira, uma vez que apenas prgramadr que desenvlveu cnseguia realizar essa tarefa. Além diss, era necessári também uma análise mais elabrada d prblema, pis a cmunicaçã entre desenvlvedr x cliente era praticamente inexistente n entã mdel "cdifica-crrige". Na década de 1960, surge a primeira metdlgia para desenvlviment de sistemas cm mdel Waterfall, u mdel cascata, que sugere um mdel de desenvlviment sequencial e cmpst pr cinc fases: Cmunicaçã: iniciaçã d prjet e levantament de requisits; Planejament: estimativas, crngramas e mnitrament; Mdelagem: análise e prjet; Cnstruçã: cdificaçã e teste; E, pr fim, a Implantaçã: entrega e manutençã. Já na década de 70, Steven Myers e Cnstantine prpuseram s cnceits d prjet estruturad. Buscu-se entã aplicar s cnceits de prjet estruturad à análise de sistemas cm bjetiv de desenvlver um métd de especificaçã de requisits adequad a prjet estruturad. GANE e SARSON (1979) apresentaram uma metdlgia de desenvlviment de sistemas chamada STRADIS - Structured Analysis, Design and Implementatin f Infrmatin Systems - que incrpru a análise, prjet e implementaçã estruturada 9

10 de sistemas de infrmaçã. É uma metdlgia baseada na decmpsiçã funcinal e n us d diagrama de flux de dads, cmpsta pelas seguintes fases: Fase 1: Estud inicial; Fase 2: Estud detalhad; Fase 3: Definiçã e prjet de sluções alternativas; Fase 4: Prjet Físic. Gane e Sarsn acrescentam que para cmpletar desenvlviment d sistema utras atividades sã necessárias cm, pr exempl, desenhar um planejament incluind plans de teste e aceitabilidade d sistema. E Yurdn (1989), também dentr da metdlgia estruturada, prpôs a Metdlgia Estruturada Mderna, que pssui cm base a decmpsiçã funcinal e prjet tp-dwn, através ds quais um prblema é sucessivamente decmpst em unidades gerenciáveis. Atualmente, a metdlgia mais utilizada é a rientada a bjets. O term Prgramaçã Orientada a Objets fi criad pr Alan Kay, autr da linguagem de prgramaçã Smalltalk. Mas, mesm antes da criaçã d Smalltalk, algumas das ideias da POO já eram aplicadas, send que a primeira linguagem a realmente utilizar esses cnceits fi a linguagem Simula 67, criada pr Ole Jhan Dahl e Kristen Nygaard em De acrd cm DAVID (2007), este paradigma de prgramaçã já é bastante antig, mas só agra vem send realmente aceit nas grandes empresas de desenvlviment de Sftware. Alguns exempls de linguagens mdernas utilizadas pr grandes empresas em td mund que adtaram esses cnceits: Java, C#, C++, Object Pascal (Delphi), Ruby, Pythn etc Identificaçã e justificativa d prblema A utilizaçã de sftware de qualidade garante a segurança das transações, ds negócis, das pessas envlvidas e mantém alta dispnibilidade ds serviçs. Prduts e serviçs sã cnsiderads aceitáveis se apresentarem desempenh dentr de certs limites. Prém, quand um sftware passa a apresentar grandes falhas, a 10

11 empresa respnsável pel sftware passa a sfrer cm despesas de retrabalh para crrigir s errs detectads e, dependend da gravidade d err, as hras gastas pel desenvlvedr para crrigir a falha serã muit maires d que temp que pderia ter sid dedicad à prevençã desta. Assim cm PFLEEGER (2004) afirma que us de uma metdlgia é uma maneira de bter um sftware de qualidade, em determinada Instituiçã Financeira fi implantada uma Metdlgia de Desenvlviment de Sistemas visand mair qualidade em seus sistemas. A instituiçã adtu uma metdlgia interna para desenvlviment de nvs sistemas e para prjets de melhria ns já existentes. A medida fi tmada prque a empresa pssui uma grande precupaçã cm falhas sistêmicas, que acarretam em diverss prblemas, tais cm: perda financeira, cmprmetiment de dads sigilss e multas pr nã estar de acrd cm as nrmas estabelecidas pel Banc Central. A partir da implantaçã de uma metdlgia cmpletamente vltada às necessidades da Instituiçã Financeira é que surgiu interesse neste estud sbre cm a Metdlgia de Desenvlviment de Sistemas pde garantir a qualidade de um sftware. Para bter essa respsta fi desenvlvid este trabalh de pesquisa sbre s pnts, dentr d prcess prpst de desenvlviment dentr da metdlgia descrita, em que se pde identificar a garantia de qualidade de sftware Objetivs Objetiv geral Estudar s itens relacinads cm a garantia da qualidade de sftware que cmpõem a Metdlgia de Desenvlviment de Sistemas criada pr uma Instituiçã Financeira Objetivs específics Realizar um estud sbre que é qualidade de acrd cm definições de autres que abrdam assunt, e que é e cm é a qualidade de um prdut de sftware. 11

12 Realizar um estud sbre us de metdlgia cm maneira de bter garantia de qualidade de sftware, cm fi elabrada a Metdlgia de Desenvlviment de Sistemas adtada pela Instituiçã Financeira, e se a maneira cm essa Metdlgia de Desenvlviment de Sistemas fi implantada é suficiente para assegurar um sftware de qualidade. A esclha da metdlgia desta empresa fi feita baseada nas mudanças de estrutura que estã acntecend dentr da Instituiçã Financeira, nde cada vez mais a qualidade ns sftwares tem sid cbrada de tds nã só pela precupaçã de um retrabalh, mas principalmente pels impacts financeirs que a crpraçã sfre em funçã de errs sistêmics Metdlgia A cnstataçã d prblema prpst para estud fi feita a partir de métd indutiv, em que, segund DIEHL (2006), é um métd prpst pr Bacn, Hbbes, Lcke e Hume que cnsidera que cnheciment é fundamentad na experiência, realizand a bservaçã de cass na realidade cncreta. Para desenvlviment d trabalh fi utilizada a pesquisa bibligráfica, buscand autres dentr das áreas de Qualidade e de Engenharia de Sftware, para que fssem pssíveis as fundamentações teóricas d tema abrdad. Além da pesquisa pr meis bibligráfics fi utilizada também a pesquisa de dcuments ficiais, cletand dads secundáris, que segund DIEHL (2006), sã dads existentes na frma de arquivs, bancs de dads e relatóris, nde fi pssível ser feita a cleta de dads sbre a metdlgia desenvlvida e implantada na Instituiçã Financeira. Fi necessária também uma pesquisa na internet para buscar cnheciment a partir de piniões e experiências de utrs prfissinais da área de tecnlgia. Para alguns pnts sbre a utilizaçã da Metdlgia de Desenvlviment de Sistemas implantada na Instituiçã Financeira fi utilizada também a bservaçã, nde fi pssível a percepçã de alguns fats sbre cenári antes e pós-implantaçã da metdlgia. 12

13 Feit trabalh de levantament de dads, fi realizada a rganizaçã de tds s dads para que fsse entã pssível a interpretaçã destes para a expsiçã d tema abrdad, através de texts. 13

14 2. QUALIDADE A precupaçã cm a qualidade de bens e serviçs nã é recente, e de acrd cm LONGO (1996), a evluçã da qualidade pde ser dividida em três grandes mments: a era da inspeçã, da qualidade estatística e da gestã da qualidade. A precupaçã ds cnsumidres de inspecinar s bens e serviçs que recebiam deu rigem à chamada era da inspeçã, que se vltava para prdut acabad, nã prduzind assim qualidade, apenas encntrand prduts defeituss na razã direta da intensidade da inspeçã. De acrd cm LONGO (1996), a era d cntrle estatístic surgiu cm apareciment da prduçã em massa, traduzind-se na intrduçã de técnicas de amstragem e de utrs prcediments de base estatística, bem cm, em terms rganizacinais, n apareciment d setr de cntrle da qualidade. Sistemas de qualidade fram pensads, esquematizads, melhrads e implantads desde a década de 30 ns Estads Unids e, um puc mais tarde, na década de 40, n Japã e em váris utrs países d mund. E entã, a partir da década de 50, surgiu a precupaçã cm a gestã da qualidade, que truxe uma nva filsfia gerencial cm base n desenvlviment e na aplicaçã de cnceits, métds e técnicas adequads a uma nva realidade. A gestã da qualidade ttal, cm ficu cnhecida essa nva filsfia gerencial, marcu deslcament da análise d prdut u serviç para a cncepçã de um sistema de qualidade. A qualidade deixu de ser um aspect d prdut e respnsabilidade apenas de um departament específic e passu a ser um prblema da empresa, abrangend, cm tal, tds s aspects de sua peraçã. A qualidade se trna cada vez mais necessária para garantir que um prdut seja cmpetitiv, e em tdas as áreas há uma prcura pr ela: na educaçã, ns prduts que cnsumims e até mesm ns serviçs prestads. Este capítul apresenta, a partir de diferentes cnceits de qualidade, que essa expressã significa, que ela representa para cnsumidr final e cm trnar pssível que um prdut u serviç seja cnsiderad de qualidade. 14

15 2.1. Cnceits de qualidade Sã inúmers s autres que abrdam tema qualidade, e nem tds pssuem mesm cnceit pra esse term. Entre alguns ds nmes mais imprtantes que tratam sbre esse assunt estã Juran, Deming e Crsby. Segund JURAN (1974), dentre tdas as definições para term duas sã as mais imprtantes para gerenciament da qualidade: As características de um prdut, pis, para s clientes, quant melhres frem as características de um prdut, mais alta será a qualidade dele. A ausência de defeit, pis, para cliente, quant mens defeits um prdut pssuir, mair será a qualidade dele. A partir diss, JURAN (1974) sugere a reflexã ds gerentes para dis pnts: primeir é que prduts cm melhres características pdem afetar as vendas, pis nrmalmente custam mais car; e segund é que prduts defeituss pdem afetar s custs, uma vez que haverá um retrabalh. DEMING (1986) sugere que, para bter a qualidade ttal, 14 pnts devem ser seguids. Esses 14 pnts desenvlvids pr ele pdem ser aplicads das pequenas às grandes empresas, independentemente de seu setr: serviçs u manufatura. Seus 14 pnts sugerem que as transfrmações devem atingir tdas as áreas da empresa, desde s recurss humans até a prduçã, atingind tds s prcesss rganizacinais da empresa. Sã eles: Criar na rganizaçã uma cnstância de prpósits n sentid da melhria ds prduts e serviçs, de frma que se trne cmpetitiva, mantenha-se n negóci e gere trabalh; Adtar uma nva filsfia. Vivems numa nva era ecnômica. A administraçã cidental deve despertar para desafi, cnscientizar-se de suas respnsabilidades e assumir a liderança em direçã à transfrmaçã; 15

16 Acabar cm a dependência de inspeçã para a btençã da qualidade. Eliminar a necessidade de inspeçã em massa, pririzand a internalizaçã da qualidade d prdut; Acabar cm a prática de negócis cmpensadres baseads apenas n preç. Em vez diss, minimizar cust ttal. Insistir na ideia de um únic frnecedr para cada item, desenvlvend relacinaments duradurs, baseads em qualidade e em cnfiança; Aperfeiçar cnstante e cntinuamente td prcess de planejament, prduçã e serviçs, cm bjetiv de aumentar a qualidade e a prdutividade e, cnsequentemente, reduzir s custs; Frnecer treinament n lcal de trabalh; Adtar e estabelecer liderança. O bjetiv da liderança é ajudar as pessas a realizar um trabalh melhr. Assim cm a liderança ds trabalhadres, a liderança empresarial necessita de uma cmpleta refrmulaçã; Eliminar med, para que tds pssam trabalhar pela empresa; Quebrar as barreiras entre departaments. Os clabradres ds setres de pesquisa, prjets, vendas, cmpras u prduçã devem trabalhar em equipe, trnand-se capazes de antecipar prblemas que pssam surgir desde a prduçã até a utilizaçã ds prduts u serviçs; Eliminar slgans, exrtações e metas dirigidas as empregads pedind pr defeit zer e nvs níveis de prduçã. Iss pde gerar uma cmpetitividade negativa entre s funcináris, atrapalhand na prdutividade, uma vez que eles pdem passar a nã mais trabalhar cm uma equipe, apenas visand ser melhres que s demais; Eliminar a gestã pr bjetivs cm base em indicadres de quantidades. Esse pnt é cntrvers, a mens que seja interpretad cm entendiment das variações naturais; 16

17 Remver barreiras que despjem as pessas de rgulh n trabalh. A atençã ds supervisres deve vltar-se para a qualidade e nã para númers. Remver as barreiras que usurpam ds clabradres das áreas administrativas e de planejament just direit de rgulhar-se d prdut de seu trabalh. Iss significa a abliçã das avaliações de desempenh u de mérit e da administraçã pr bjetivs u pr númers; Estabelecer um prgrama rigrs de educaçã e aperfeiçament para td pessal; Clcar tds da empresa para trabalharem de md a realizar a transfrmaçã. A transfrmaçã é tarefa de tds. Crsby é fundadr da teria Zer Defeit. Essa abrdagem se baseia na teria de que a qualidade é assegurada através de um melhrament cntínu ns prcesss de fabricaçã, que leva a uma realizaçã crreta na primeira tentativa. CROSBY (1985) elabru 14 pnts que cnstituem as etapas de implementaçã de sua abrdagem. Sã eles: Dedicaçã da alta gerência e cmprmetiment através da elabraçã de um dcument cm a plítica e s bjetivs da empresa; Cnstituiçã de equipes para melhrias crdenadas pels gerentes; Mediçã ds resultads; Avaliaçã ds custs da qualidade; Cmunicaçã ds resultads as supervisres e peráris; Reuniã para identificaçã ds prblemas; Estabeleciment de um cmitê infrmal para a divulgaçã d prgrama; Treinament da gerência e supervisã; Instauraçã d dia Zer Defeit, em que s resultads anuais sã divulgads e efetua-se recnheciment a tds s participantes d prgrama; 17

18 Estabeleciment ds bjetivs a serem seguids; Cnsulta as peráris sbre a rigem ds prblemas; Recmpensar aqueles que atingiram s seus bjetivs; Frmar s cnselhs da qualidade; Etapa final: faça tud de nv. Qualidade é um assunt cada vez mais discutid dentr das crprações e a precupaçã em prestar serviçs u apresentar prduts de qualidade é desafi para quem pretende ganhar mercad. Cada vez mais mercad de prduts e serviçs prcura ferecer qualidade as seus clientes, mas que é qualidade? Segund a nrma ISO 9001:2008, qualidade é grau n qual um cnjunt de características inerentes satisfaz a requisits. E, nas últimas décadas, muitas empresas, de váris setres, vêm buscand essa qualidade em seus prduts e serviçs. A Tabela 1 mstra a quantidade de empresas que tiraram a certificaçã ISO 9001:2000 e a ISO 9001:2008 ns últims dez ans: Tabela 1 - Quantidade de empresas certificadas pela ISO ns últims dez ans Segund CARPINETTI (2010), a ISO identificu que as empresas que prcuram a certificaçã 9001:2008 sã u as que precisam dela u as que sabem que, a exibir tal certificaçã na embalagem de seus prduts, ganham a cnfiança d cliente pr mstrar a ele que artig adquirid é de qualidade. 18

19 2.2. As diferentes percepções de qualidade Qualidade pssui definições de inúmers autres, mas para cada indivídu ela terá um significad diferente, pr se tratar de alg que varia de acrd cm as necessidades de cada um. É nesse pnt que entra a questã das diferentes percepções de qualidade. É pssível entender melhr essa questã das diferentes percepções cm seguinte exempl de Weinberg(1994) em que ele descreve um prblema cm um editr de texts que prejudicu sua sbrinha, pis editr perdeu text após um determinad númer de palavras digitadas: [...] Minha sbrinha me pediu para discutir assunt cm a empresa fabricante d sftware em minha próxima visita. Lcalizei entã gerente de prjet para editr de texts e ele recnheceu a existência d err. É um err rar ele argumentu. Eu nã diria iss cntestei. Encntrei 25 crrências n livr de minha sbrinha. Mas iss só pderia crrer num prjet d tamanh de um livr. Entre mais de cem mil clientes, estimams que mens de dez prduziram um prjet deste tamanh em um únic arquiv. Mas minha sbrinha ntu. Era seu primeir livr, e ela ficu arruinada. Naturalmente eu sint pr ela, mas nã faria sentid tentarms crrigir um err para dez clientes. Pr que nã? Vcês anunciam que editr manipula prjets d tamanh de um livr. Tentams fazê-l, mas as alterações nã funcinaram. Eventualmente farems as crreções, mas, pr ra, sã grandes as chances de intrduzirms um err pir, que afetaria centenas de milhares de clientes. Acredit que fizems a cisa certa. A uvir gerente de prjet, cnfess que fiquei dividid. Cm cnsultr da empresa, eu tinha que cncrdar, mas, cm ti de uma autra, clquei-me radicalmente cntra essa linha de racicíni. Se alguém me perguntasse: Esse editr é um prdut de qualidade?, eu ficaria cm a língua presa. [ ] O cas acima mstra bem cm um prdut pde ser de qualidade para muits e para utrs, nã, uma vez que ele para de atender as requisits d cliente. GARVIN (1984) define qualidade em seu artig escrit para a Universidade de Harvard cm cinc diferentes percepções: Transcendente: em que qualidade é sinônim de "excelência inata". Parte-se da premissa de que há alg de intempral e duradur nas bras de qualidade. Está muit próxim as prduts artesanais, rejeitand a prduçã em massa. O mais frequente é alegar que a qualidade nã pde ser cnceituada, nem medida, e nem ser recnhecida exclusivamente pela 19

20 experiência. Essa visã gera uma enrme dificuldade, pis nã ferece rientaçã prática alguma. Essa definiçã se sustenta na ideia de que um gerente u qualquer pessa cnhece a qualidade quand se defrnta cm exempls dela, u seja, a qualidade só é recnhecida quand é vista. Baseada n prdut: essa visã é cmpletamente diferente da visã transcendente. A visã baseada n prdut sustenta que a qualidade é precisa e mensurável. Prém, sustenta que "diferenças de qualidade refletem diferenças nas quantidades de algum ingrediente u atribut de um prdut". Pr exempl, um srvete de alta qualidade pssui um alt cnteúd de grdura. Send assim, frma-se uma dimensã vertical à qualidade, pis prdut pde ser classificad pela quantidade d atribut desejad que ele pssui. Dentr desta visã, devem ser destacads dis fatres imprtantes. O primeir é que, cm a qualidade reflete a quantidade de atributs cntids e cm estes envlvem custs, prduts de melhr qualidade serã brigatriamente mais cars. O segund pnt é que a qualidade é vista cm característica inerente a prdut e nã cm alg atribuíd a ele. Essa abrdagem também apresenta limitações, uma vez que nem sempre existe uma crrespndência entre s atributs d prdut e a qualidade. Baseada n usuári: esta visã fundamenta-se n princípi de que um prdut cm qualidade é aquele que melhr atende as desejs u às necessidades d cnsumidr. Iss quer dizer que um prdut pssui mair qualidade à medida que está atendend às necessidades d públic-alv. Um prblema desta abrdagem é que ela iguala qualidade à satisfaçã máxima. Ambas estã intimamente relacinadas, prém nã sã de frma alguma idênticas. Um exempl prátic diss pde ser uma lista de livrs mais vendids: esses livrs sã bviamente s preferids pels leitres, prém pdem nã se traduzir n mais alt nível de literatura. Baseada na prduçã: Enquant a visã baseada n usuári apia-se na preferência d cnsumidr, a visã baseada na prduçã, pr sua vez, busca lad da ferta, interessand-se basicamente pela engenharia e prduçã d 20

21 bem. Tds s cnceits ligads a essa visã se resumem em uma frase: "qualidade é a cnfrmidade cm as especificações". Seu enfque é basicamente intern. Admite interesse d cnsumidr pr qualidade, mas sustenta que um prdut que nã está dentr das cnfrmidades nã lhe atende às necessidades. Talvez seja essa a sua grande deficiência, abandnar el que cnsumidr bserva entre qualidade e característica d prdut, além da cnfrmidade. É cercada de várias técnicas mdernas, mas sempre cm intuit de reduçã de custs. Baseada n valr: As definições de qualidade baseadas n valr refletem um avanç das visões anterires, já que se fundamentam em custs e preçs. Cnsumidres cada vez mais avaliam a qualidade de um prdut pel seu valr. Pr exempl, um restaurante que tem em seu cardápi um prat a R$ 200,00 pr pessa, independentemente da excelência da sua cnfecçã, pde nã ser um prdut de qualidade, pis, pel preç, acaba atraind pucs cmpradres. Essa visã envlve dis cnceits distints - excelência e valr -, mas sem limites definids, e pde muitas vezes se perder na subjetividade. Várias percepções de qualidade pdem ser insatisfatórias quand aplicadas individualmente em um prcess, segund GARVIN (1984) As empresas precisam utilizar diferentes perspectivas para atingir um alt nível de qualidade. Pr exempl, nã é prque um prdut fi fabricad cm qualidade atingind bjetiv de reduçã de custs da empresa que ele será bem recebid pels cnsumidres atendend tdas as suas necessidades Qualidade d prcess De acrd cm JURAN (1992), prcess é uma série sistemática de ações dirigidas à realizaçã de uma meta. Um prcess pde auxiliar n planejament de qualidade cm, pr exempl, s prcesss de pesquisa de mercad, desenvlviment d prdut, desenvlviment d prcess e de cntrles d prcess. Existem inúmeras atividades dentr de um prcess que pdem afetar a qualidade d prdut final, cas uma u mais delas nã sejam bem realizadas. 21

22 PFLEEGER (2004) cnsidera que a qualidade d prcess de desenvlviment e manutençã é tã imprtante quant a qualidade d prdut justamente pr essa interferência que prcess pde causar n resultad final. Para que seja pssível avaliar um prcess para identificar seu estad atual e em que pnts pdem ser melhrads, existem inúmeras abrdagens de avaliaçã de prcess, entres elas PRESSMAN (2006) cita: SCAMPI (Standard CMMI Assessment Methd fr Prcess Imprvement), que frnece um mdel de prcess de avaliaçã cm cinc passs: a iniciaçã; diagnóstic; estabeleciment; a açã e aprendizad. Esse métd utiliza CMMI cm base para avaliaçã; CBA IPI (CMM-Based Appraisal fr Internal Prcess Imprvement), que frnece uma técnica de diagnóstic para avaliar a maturidade relativa de uma rganizaçã de sftware usand CMM cm base para avaliaçã; Nrma SPICE (ISSO/IEC 15504), que define um cnjunt de requisits para a avaliaçã de prcess de sftware. Essa nrma tem pr bjetiv assistir às rganizações n desenvlviment de uma avaliaçã bjetiva da eficácia de qualquer prcess definid de sftware; ISO 9001:2000 para sftware, uma nrma genérica que se aplica a qualquer rganizaçã que deseje aperfeiçar a qualidade glbal ds prduts, sistemas u serviçs que ela frnece, send assim a nrma é aplicável também a rganizações e empresas de sftware. Essa nrma trabalha dentr de um cicl de planejar, fazer, verificar e agir, que é aplicad as elements de gestã de qualidade de um prjet de sftware. Aplicand esse cicl a cntext de sftware, tem-se que planejar é nde sã estabelecids s bjetivs d prcess, suas atividades e as tarefas necessárias para a btençã de sftwares de ótima qualidade, resultand na satisfaçã d cliente. O fazer é a implementaçã d prcess. Verificar mnitra e mede prcess para garantir que s requisits estabelecids tenham sid atingids. Pr fim, agir inicia as atividades de melhrament cntínu d prcess. Tdas essas abrdagens estã sempre sfrend atualizações para que seja pssível acmpanhar as mudanças e as nvas necessidades d mercad. 22

23 2.4. O que é qualidade de sftware Qualidade de sftware é uma das áreas de cnheciment da engenharia de sftware cuj bjetiv é garantir a qualidade d sftware através da definiçã de prcesss de desenvlviment. Apesar ds mdels aplicads na garantia da qualidade de sftware atuar principalmente n prcess, bjetiv mais imprtante é garantir um prdut final que satisfaça às expectativas d cliente, dentr daquil que fi acrdad inicialmente. Segund SWEBOK (2004), essa área é cnjunt de atividades relacinadas cm garantia de qualidade de sftware, entre elas as atividades de verificaçã e validaçã, nde as particularidades de um mdel de qualidade de sftware variam para utr mdel, pis cada um tem um númer diferente de níveis hierárquics e um númer ttal de diferentes características. PRESSMAN (2006) define qualidade cm a cnfrmidade cm s requisits funcinais e de desempenh previamente declarads, as nrmas de desenvlviment dcumentadas e as características implícitas que sã esperadas de td sftware que é desenvlvid prfissinalmente. PRESSMAN (2006) acredita que a partir dessa definiçã é pssível enfatizar três pnts imprtantes: É a partir ds requisits de sftware que se pde medir a qualidade dele, uma vez que a falta de cnfrmidade cm s requisits é falta de qualidade; A definiçã de nrmas auxilia n md cm sftware é submetid à engenharia, uma vez que as nrmas se cnstituem de um cnjunt de critéris de desenvlviment. Se esses critéris nã sã seguids, existe uma grande pssibilidade de se bter a falta de qualidade; Os requisits implícits, na mair parte ds cass, nã sã mencinads, cm, pr exempl, bm desempenh u a fácil manutençã d sistema, prém sã requisits esperads. Prtant, se sftware satisfaz s requisits explícits, mas nã satisfaz s implícits, a qualidade d sftware pde ser cnsiderada suspeita. 23

24 Uma vez que sã satisfeits tant s requisits explícits cm s implícits as chances de se bter um sftware de qualidade sã maires Cm é medida a qualidade de um sftware Para avaliar a qualidade de um sftware u prdut é utilizada cm api a mediçã. A mediçã da qualidade de um sftware pde ser realizada a partir de métricas de qualidade, essas métricas indicam quant um sftware se adapta às exigências implícitas e explícitas d cliente. As métricas pdem ser as medidas de: tamanh d prdut de sftware; númer de pessas necessári para implementar um cas de us; númer de defeits encntrads pr fase de desenvlviment; esfrç para a realizaçã de uma tarefa; temp para a realizaçã de uma tarefa; cust para a realizaçã de uma tarefa; grau de satisfaçã d cliente. Segund PRESSMAN (2006), ainda que as métricas de prdut para sftware nã sejam sempre abslutas, elas trnam pssível avaliar de md sistemátic a qualidade cm base em um cnjunt de regras claramente definidas. JURAN (1992) diz que um sftware de qualidade é aquele que nã apenas satisfaz as exigências, mas também é implementad a temp e de acrd cm rçament. Quand um sftware pssui muits errs u falhas, perde parte d valr para usuári, prém, um sftware isent de errs nã é, necessariamente, um sftware de qualidade, pis ele pde se apresentar cm um prgrama isent de errs que, prém, nã satisfaz as necessidades d usuári. A ausência de funções necessárias para usuári nã pde ser cmpensada pr funções auxiliares genéricas nã slicitadas, cm uma calculadra, um blc de ntas, um layut diferenciad u qualquer utr aplicativ d gêner. E, segund PRESSMAN (2006), as necessidades d cliente sã expressas ns requisits explícits descrits a analista, e também ns implícits, tais cm: ser flexível, fácil de perar, barat, cnstruíd n praz, além de ter que ser mais prátic, mais rápid, prtátil, realizar integraçã cm utrs sftwares, ter fácil manusei, ser mais segur e mais barat em relaçã a prcess anterir, fsse ele manual u já infrmatizad. Em PFLEEGER (2004), cnta-se que n iníci da década de 1990 a cmunidade da engenharia de sftware buscava cnslidar tdas as inúmeras 24

25 visões de qualidade em um mdel que pudesse ser utilizad cm padrã mundial para medir a qualidade de sftware. Cm resultad diss surgiu a ISO itens: A ISO 9126 (2003) define que sã características de qualidade s seguintes Funcinalidade: É a capacidade d prdut de sftware de prver funções que atendam às necessidades explícitas e implícitas quand sftware estiver send utilizad sb cndições especificadas; Cnfiabilidade: É a capacidade d prdut de sftware de manter um nível de desempenh especificad, quand usad em cndições especificadas; Usabilidade: É a capacidade d prdut de sftware de ser cmpreendid, aprendid, perad e atraente a usuári, quand usad sb cndições especificadas; Eficiência: É a capacidade d prdut de sftware de apresentar desempenh aprpriad, relativ à quantidade de recurss usads, sb cndições especificadas; Manutenibilidade: É a capacidade d prdut de sftware de ser mdificad. As mdificações pdem incluir crreções, melhrias u adaptações d sftware devid a mudanças n ambiente e ns seus requisits u especificações funcinais; Prtabilidade: Capacidade d prdut de sftware de ser transferid de um ambiente para utr. Send assim, quand um prdut de sftware atende à tdas as especificações acima pde ser cnsiderad um prdut de qualidade. 25

26 3. METODOLOGIA Segund MACENAS (2005), para se prduzir um sftware de qualidade é necessári pensar também em um prcess eficiente para que iss crra. E para entender, de maneira simples, que é metdlgia, é necessári pensar em prcediments rganizads que cnduzem a um prdut final de frma padrnizada. Existem atualmente n mercad inúmeras metdlgias, nde cada uma representa visões e experiências de seus criadres e, para que seja pssível a adçã de uma, algumas vezes é necessári adequar a metdlgia à realidade da empresa. De acrd cm MACENAS (2005), a adçã de uma metdlgia nã implica necessariamente na btençã de um prdut de qualidade, prém nã se pde pensar em qualidade sem api de uma metdlgia. Ou seja, ainda que a adçã de uma metdlgia nã garanta que resultad final de um prcess será de qualidade, é ela quem auxilia cm um prcess de desenvlviment padrnizad e rganizad a fim de alcançar bjetiv de bter um prdut final de qualidade A Metdlgia de Desenvlviment de Sistemas utilizada pela instituiçã financeira cm garantia de qualidade de seus sistemas Visand nã só a padrnizaçã de prcesss cm também a busca pr um melhr prcess de desenvlviment, resultand assim em um prdut final de qualidade, fi adtada a Metdlgia de Desenvlviment de Sistemas pr uma determinada Instituiçã Financeira. De acrd cm GMQS (2009), essa Metdlgia de Desenvlviment de Sistemas criada pr uma instituiçã financeira fi elabrada pr 22 representantes de tdas as diretrias de desenvlviment de sistemas, em que bjetiv era de integrar em uma única metdlgia tds s prcesss de desenvlviment existentes após a integraçã de duas instituições financeiras e tdas as empresas d grup resultante. Além diss, cm a adçã dela espera-se também: Definir as fases de um desenvlviment de um sistema, de md a trná-l repetível; 26

27 Frmalizar envlviment das demais áreas n prcess de desenvlviment u manutençã de sistemas. Cm exempl, cita-se envlviment da equipe de administraçã de dads, equipe de arquitetura de TI, equipe de gestã de mudança, equipe de gestã de liberaçã, etc.; Orientar desenvlvedr n cumpriment de nrmas crprativas e/u de cntrle para mitigaçã de risc peracinal de tecnlgia; Institucinalizar s prcesss de desenvlviment u manutençã de sistemas, pssibilitand a repetiçã de práticas de sucess n cicl de desenvlviment u manutençã de sistemas; Padrnizar a dcumentaçã a ser elabrada pel desenvlvedr, facilitand a manutençã ds sistemas; Maximizar a ba cmunicaçã cm s clientes através da frmalizaçã da slicitaçã deles, declaraçã de escp e requisits, e aceite pel cliente durante prcess de desenvlviment u manutençã de sistemas; Declarar s papéis e respnsabilidades n prcess de desenvlviment u manutençã de sistemas. Ainda que dentr na dcumentaçã elabrada da Metdlgia nã há referência à nenhuma utra metdlgia cm base para desenvlviment desta, é pssível encntrar algumas semelhanças cm a metdlgia RUP - Ratinal Unified Prcess. A Metdlgia de Desenvlviment de Sistemas desenvlvida pela Instituiçã Financeira analisada pde ser cmparada à Metdlgia de Desenvlviment RUP Ratinal Unified Prcess. Alguns pnts em cmum entre essas metdlgias sã: Assim cm é descrit em IBM (1998), a metdlgia Ratinal Unified Prcess frnece uma abrdagem disciplinada para atribuir tarefas e respnsabilidades dentr de uma rganizaçã de desenvlviment garantind a prduçã de alta qualidade. O desenvlviment da metdlgia adtada pela Instituiçã Financeira fi elabrada sb a mesma abrdagem de bter um sftware 27

28 que atenda as necessidades de seus usuáris finais, dentr de um crngrama e rçament previsíveis; Em IBM (1998) é descrit que a equipe de desenvlviment para Ratinal Unified Prcess trabalha em estreita clabraçã cm clientes, parceirs, prduts da Ratinal, grups, bem cm a rganizaçã Ratinal d cnsultr, para garantir que prcess é cntinuamente atualizad e melhrad para refletir as experiências recentes e em desenvlviment e as melhres práticas cmprvadas. O mesm crre cm a Metdlgia de Desenvlviment adtada pela Instituiçã Financeira, que de acrd cm ARQUITETURA (2009) pssui a equipe CMPS Cmitê de Melhria d Prcess de Sftware respnsável pela revisã e aprimrament cnstante da metdlgia, através de reuniões periódicas cm s mesms representantes das diretrias que participaram da criaçã da metdlgia. Essas reuniões acntecem cm uma frequência mínima de uma vez a mês; Segund IBM (1998), Ratinal Unified Prcess aumenta a prdutividade da equipe, frnecend a cada membr da equipe, cm fácil acess a uma base de cnheciment cm as diretrizes, mdels e mentres de ferramentas para tdas as atividades de desenvlviment crític. Pr ter tds s membrs da equipe acessand a base de cnheciment, nã imprta se vcê trabalha cm s requisits, prjet de teste design, gestã u gerenciament de cnfiguraçã, pdems garantir que tds s membrs da equipe partilham uma língua cmum, prcess e sua visã de cm desenvlver sftware. A metdlgia adtada pela Instituiçã Financeira também pssui seu repsitóri de arquivs, nde é pssível que tds s envlvids n prjet tenham acess as dcuments e utrs artefats prduzids. O repsitóri de arquivs utilizads é MTFS Micrsft Team Fundatin System; Segund IBM (1998) Ratinal Unified Prcess cria e mantém mdels a invés de fcar na prduçã de grande quantidade de dcuments em papel, prcess unificad enfatiza desenvlviment e manutençã de mdels, representações semanticamente ricas d sistema de sftware em desenvlviment, assim cm descrit nas fases da Metdlgia de Desenvlviment de Sistemas em e Para a criaçã ds mdels da Metdlgia utilizada pela Instituiçã financeira é utilizada a ferramenta Pwer Designer; 28

29 Em IBM (1998) é descrit que Ratinal Unified Prcess captura muitas das melhres práticas em desenvlviment de sftware mdern, de frma que é aprpriad para uma ampla gama de prjets e rganizações. Da mesma frma fi elabrada a Metdlgia de Desenvlviment de Sistemas utilizada pela Instituiçã, de acrd cm ARQUITETURA (2009) a prpsta de metdlgia que cnsideru as necessidades identificadas e cnsideru s mdels existentes e a experiência ds desenvlvedres da Instituiçã Financeira n prcess. Dentr da instituiçã financeira há uma equipe de qualidade que avalia a dcumentaçã gerada em cada fase dessa metdlgia a fim de garantir que prdut gerad atende à Metdlgia de Desenvlviment de Sistemas através de Checklists, que sã listagens que cnferem se itens brigatóris na dcumentaçã fram devidamente preenchids durante as fases da metdlgia Expectativas na implantaçã desta Metdlgia de Desenvlviment de Sistemas A elabrar e implantar essa metdlgia na instituiçã financeira havia uma expectativa de intrduzir cm sucess s sistemas, atendend à Resluçã d Banc Central de Nº BANCO CENTRAL (1998), que determina que as instituições financeiras e demais instituições regularizadas pr ele devem implantar e implementar cntrles interns, a fim de garantir que s sistemas e as atividades da instituiçã cumpram nrmas crprativas u de cntrle para diminuir riscs peracinais. Os cntrles interns devem ser revisads e atualizads peridicamente, de md a sempre incrprar nvs riscs u riscs antes nã identificads. Cm a implantaçã desta Metdlgia de Desenvlviment de Sistemas, a Instituiçã Financeira espera que s prjets de TI atendam às expectativas ds demandadres cm previsibilidade de escp u de crreçã, cust e praz. Send assim, uma vez que essas expectativas sã atendidas, btém-se um sistema de qualidade. As três primeiras áreas-fc durante desenvlviment dessa metdlgia fram: 29

30 Requisits: Nesta área, bjetiv era bter uma mair clareza ds requisits, garantind requisits explícits cmprmetids entre TI e negócis; Desenh da Arquitetura Técnica e Funcinal: Nesta área, buscu-se um melhr us de recurss de desenvlviment e prcessament, garantind funcinalidades claras entre s sistemas e n us da tecnlgia; Mdelagem de Dads: Durante a mdelagem ds dads, bjetiv era garantir que mdels de dads lógics e físics fssem desenhads de maneira explícita, juntamente cm s desenvlvedres e alinhads cm a prduçã a fim de se bter a cnsistência e integridade de infrmações e dads. A Instituiçã Financeira estudada tinha pr bjetiv também que essa nva metdlgia seguisse md de trabalh da empresa, send cnstituída entã de um prcess únic que fsse adequad a tamanh d prjet, simples, mas cm alta utilizaçã e, pr fim, cntrlad nde fsse essencial. Antes da implantaçã da metdlgia fi realizada uma pesquisa de aceitaçã ds analistas e diretres, identificand a receptividade u rejeiçã em relaçã a artefats e disciplinas envlvidas nas bas práticas da metdlgia, de md a permitir esclareciment de dúvidas, crreçã de alguns aspects u preparar melhr pnts de rejeiçã. As fases que cmpõem a versã final da Metdlgia de Desenvlviment de Sistemas sã: Escp e Estimativa; Análise; Desenh Físic; Cnstruçã; Teste; Implantaçã; Gestã de Mudanças d Prjet. 30

31 Essas fases sã grups de atividades rganizadas em rdem crnlógica de execuçã. Cada fase é cmpsta de atividades que devem ser executadas. Cada dcument gerad durante a execuçã das atividades de uma fase da metdlgia passa pela aprvaçã de determinadas áreas respnsáveis para que dessa frma tenha uma garantia de que prpst n prjet u mudança está de acrd cm as necessidades d cliente. 3.3 Fases da MDS Metdlgia de Desenvlviment de Sistemas Segund a GMQS (2009), as fases de desenvlviment da metdlgia criada sã grups de atividades rganizadas em rdem crnlógica de execuçã. Cada uma dessas fases é cmpsta pr atividades que sã desenvlvidas a partir de um material de api que é dispnibilizad dentr da intranet da empresa. Também de acrd cm a GMQS (2009), além ds prduts que devem ser resultads de cada fase, há também dentr de cada fase um checklist para que seja analisad se s prduts gerads naquela fase sã u nã satisfatóris. Abaix sã descritas cada uma das fases e as atividades que cada uma prduz: Escp e Estimativa A GMQS (2009) descreve que bjetiv desta fase é analisar a demanda de md rápid e cm prfundidade suficiente para gerar uma estimativa d esfrç d prjet. É aberta pel analista uma slicitaçã de serviç para a área afetada e entã sã gerads dis prduts: O DEP Demanda, Estimativa e Planejament e DAP Direcinament da Arquitetura a Prjet DEP Demanda, Estimativa e Planejament O DEP é dcument de Demanda, Estimativa e Planejament. Segund a GMQS (2009), ele é principal dcument d prjet, uma vez que cntém as infrmações de estimativas, desde a ideia até planejament da entrega, detalhament da demanda, a sluçã prpsta pela área de TI e planejament das entregas d prjet. 31

32 As infrmações cntidas n dcument de Demanda, Estimativa e Planejament dã uma visã macr das necessidades d slicitante, permitind avaliar a viabilidade d prjet e estudar uma sluçã de TI a ser implementada DAP Direcinament da Arquitetura a Prjet O DAP é dcument de Direcinament da Arquitetura a Prjet, que de acrd cm GMQS (2009) é elabrad quand analista respnsável pel prjet slicita à equipe de Arquitetura de TI uma análise da arquitetura funcinal, arquitetura técnica e direcinament para prjet. A equipe de arquitetura é quem determina se há u nã a necessidade de envlviment n prjet seguind determinads critéris cm: Prjets de nvas funcinalidades em um dmíni funcinal; Prjets de nvas interfaces entre sistemas; Prjets de aquisiçã, alteraçã de tecnlgias u pactes em sistemas nvs u legads; Prjets de identificaçã, cnstruçã u reutilizaçã de códigs crprativs. Cas seja necessári envlviment da equipe de Arquitetura, é ela que será respnsável pela elabraçã d dcument de Direcinament da Arquitetura a Prjet, send que esse dcument é emitid apenas depis de um ttal entendiment d dcument da Demanda, Estimativa e Planejament Análise De acrd cm a GMQS (2009), essa fase define s requisits em detalhes, determinand que será desenvlvid. A análise é feita após a aprvaçã da estimativa e d DEP e DAP pel slicitante da demanda. Essa fase gera até quatr prduts: DRS, PROT, RTF e MLD DRS Diagrama de Requisits de Sistema O DRS é artefat de Requisits de Sistema, que tem pr bjetiv representar graficamente e em detalhes as funcinalidades d sistema. 32

33 Esse dcument é cnstituíd pr um Diagrama de Funcinalidades d Sistema e a especificaçã textual de cada funcinalidade, nde Diagrama deve representar escp da sluçã de TI, identificand cnjunt de tdas as funcinalidades d sistema de frma gráfica através d us de Diagrama de Cass de Us. A especificaçã textual descreve textualmente cada uma dessas funcinalidades desenhadas n diagrama PROT Prtótip O Prtótip de Interface permite que a partir de imagens ds layuts, arquivs e gráfics, s envlvids n prjet entendam e pssam sugerir mudanças para que sistema satisfaça tant visualmente cm em relaçã às funcinalidades. Além das imagens de tela da sluçã prpsta para atender às funcinalidades esperadas para sistema na análise, é válida também a elabraçã de um prtótip executável das telas desenvlvidas RTF Rteir de Teste Funcinal O Rteir de Teste Funcinal tem pr bjetiv testar s requisits funcinais e nã funcinais, e é necessári detalhar exatamente que será testad para as funcinalidades d sistema. Este artefat é cmpst pr: Rteir Geral: É dcument em que analista de TI deve descrever s cenáris de testes que serã cntemplads. O Slicitante Aprvadr da área de Negócis vai validar este rteir e, cas necessári, pde cmplementar cm utrs cenáris de teste relevantes; Rteir de Segurança: É de respnsabilidade d Gestr d Prjet, deve cnter um rteir que atenda as exigências da Área de Segurança e implementa um cntrle SOX necessári; Rteir BI: É preenchid pel analista de TI, e é necessári apenas para prjets que cntemplem sistemas da área de BI Business Inteligence; Rteir Campanhas: É preenchid pel analista de TI, e é necessári apenas para prjets que cntemplem sistemas da área de Campanhas; 33

34 Lg de Errs: É um dcument de cntrle de us pcinal, vltad smente a registrar s errs detectads durante execuçã ds cicls de testes. A GMQS (2009) define que Rteir de Teste Funcinal deve ser elabrad pel Analista de Sistemas cm a clabraçã d Gestr d Prjet durante a Fase de Análise, lembrand que este será utilizad tant para testar a aplicaçã cm fc em funcinalidades, cm também n mment de hmlgaçã pel usuári/slicitante. Durante a elabraçã d Rteir de Teste Funcinal deve se atentar muit à linguagem utilizada, pis nã deve pssuir uma linguagem muit técnica u cnteúd muit irrelevante que pssa dificultar seu entendiment. Esse dcument deve descrever cndições de teste, dads de entrada e resultads esperads e as cndições u cenáris de teste para cada funcinalidade, visand assegurar seu crret funcinament, e deve atingir um nível de representaçã suficiente para que artefat deixe clar bjetiv ds testes e de que frma eles serã cnduzids. Para cada cenári descrit n rteir devem ser definids também s dads de entrada a serem utilizads e s respectivs resultads a serem btids em cada um deles MLD Mdel Lógic de Dads O Mdel Lógic de Dads representa graficamente e dcumenta s dads tratads em um sistema de infrmaçã. Ele é feit antes d iníci da fase de Desenh Físic da Metdlgia de Desenvlviment de Sistemas, que é quand serã analisadas as frmas de armazenament e acess. Segund a GMQS (2009), para desenvlviment d Mdel Lógic de Dads, a ferramenta hmlgada é Pwer Designer, e dcument é elabrad utilizand cnceits de Mdelagem Entidade Relacinament, cm chave primária, nrmalizaçã, entre utrs. A partir d Mdel Lógic de Dads pde-se bter Mdel Físic de Dads para diverss Sistemas Gerenciadres de Banc de Dads. 34

35 3.3.3 Desenh Físic De acrd cm GMQS (2009), nesta fase é definida a estrutura d aplicativ, a dinâmica de execuçã ds cmpnentes e a lógica algrítmica detalhada de cada cmpnente. Para a elabraçã deste Desenh físic pdem ser gerads cm principais prduts: MFD, DFIS, MAL, RTI DFIS Desenh Físic O dcument d Desenh Físic é cmpst pr um cnjunt de diagramas e suas especificações. Os desenhs físics sã realizads de acrd cm a arquitetura d prjet, pdend envlver tant sluções de alta quant de baixa platafrma. O diagrama é a representaçã visual da sluçã, pdend utilizar padrã UML u estruturad, e a especificaçã é a descriçã textual detalhada ds elements d própri diagrama. Essa dcumentaçã serve de api para implementaçã d códig, prtant, tant a diagramaçã quant a especificaçã deverã ser elabradas de maneira esclarecedra e detalhar que deverá ser cnstruíd. Para se certificar da qualidade d dcument, é acnselhad cm uma ba prática que um membr da equipe d prjet revise s dcuments físics elabrads pr utr membr. É mais cmum que utra pessa identifique falhas u incnsistências cm mais facilidade que aquele que elabru desenh físic da aplicaçã RTI Rteir de Teste Integrad O Rteir de Teste Integrad tem cm bjetiv planejar s testes de integraçã de md a garantir que tds s cmpnentes d sistema, quand clcads junts em funcinament, executem suas funções crretamente, cnsiderand suas interfaces cm usuáris u utrs sistemas. O Teste Integrad visa identificar e crrigir pssíveis prblemas na integraçã. Este dcument deve ser elabrad cm a lista das cndições u situações que devem ser testadas para validar a integraçã entre s elements que fazem parte d sistema, pdend haver uma rdem em que devem ser executadas. O planejament ds Testes Integrads deve ser feit na medida em que sistema vai send cnstruíd, cnsiderand 35

36 requisits, us de determinads recurss e desempenh da aplicaçã, suas interfaces cm usuári e utrs sistemas. E tdas as funcinalidades, testadas u nã, devem ser retestadas, cnsiderand a integraçã cm utrs móduls u cmpnentes, cm utrs recurss e usuáris. Os itens cntids n RTI devem validar as integrações entre prgramas, rtinas e sistemas. Geralmente s tips de falhas encntradas ns testes de integraçã sã de envi e recebiment de dads MFD Mdel Físic de Dads O Mdel Físic de Dads representa a estrutura física das tabelas d sistema e s relacinaments entre elas, cnsiderand s requisits de desempenh e eficiência. Ele é cnstruíd também na ferramenta PwerDesigner, a partir d Mdel Lógic de Dads. Quand crre uma alteraçã n Mdel Lógic, cm desnrmalizaçã de tabelas, definiçã de índices e views, e criaçã de stred prcedures, ela deve refletir n Mdel Físic de Dads MAL Mapa de Acess Lógic O MAL - Mapa de Acess Lógic é registr ds acesss cm suas vlumetrias, que irã atender as necessidades de infrmações e, u atualizações, de Bases de Dads para as funcinalidades de um prjet. É através da análise ds acesss, que administradr d banc de dads pderá definir a criaçã de índices secundáris, particinament de bases e recmendar ajustes nas funções para garantia de perfrmance Cnstruçã Segund a GMQS (2009), nesta fase é cnstruída a sluçã cnfrme definida n desenh físic, testand-a de md unitári e integrad. Para que seja realizada a cnstruçã, é necessári que a demanda tenha sid aprvada pela Fábrica e que códig esteja testad (teste unitári e integrad). As principais atividades desta fase sã a cnstruçã da base de dads, recebiment da 36

37 dcumentaçã, elabraçã e execuçã d RTU, implementaçã d códig fnte, preparaçã d ambiente de integraçã e a execuçã ds testes integrads Cnstruir a Base de Dads A finalidade desta atividade é cmplementar a especificaçã da Estrutura de Dads e implementar resultad n Banc de Dads. Este cmplement da especificaçã cntempla acréscim de atributs físics na especificaçã das tabelas que cntribuam cm a timizaçã d banc de dads, sem, cntud, alterar a estruturaçã de dads Receber tda a dcumentaçã O respnsável pel prjet recebe tda a dcumentaçã para validar s dcuments necessáris a envi d prjet à fábrica de sftware u desenvlviment intern Elabraçã e execuçã d RTU Os testes unitáris fazem parte d cicl de desenvlviment de sistemas, especificamente da cdificaçã da aplicaçã, e cncentram-se na verificaçã da menr unidade d sistema. A finalidade d Rteir de Testes Unitáris é planejar e definir as cndições de testes unitáris a serem executadas para a validaçã ds sistemas que serã cnstruíds u alterads. Embra s testes de unidade cnsumam temp d desenvlvedr, sua adçã n cicl de desenvlviment pde trazer benefícis cm encntrar defeits nas fases iniciais da cnstruçã d sistema, cnsiderand que crrigi-ls é mais fácil e barat. Garantir que td códig de um sistema passe pr testes unitáris antes de ser liberad reduz a prbabilidade da crrência de errs em ambiente de prduçã. Depis de cada pequena mudança, s testes unitáris pdem ser reexecutads para cnfirmar se esta mudança prvcu surgiment de um defeit. 37

38 Implementar Códig Fnte O Códig Fnte deve ser implementad pela Fábrica u i nternamente, de acrd cm as especificações feitas. Os padrões de desenvlviment variam de acrd cm a linguagem que será utilizada para implementar a sluçã Preparaçã d ambiente de integraçã. Nesta atividade deve ser definida a infraestrutura de hardware, sftware e as cnfigurações de ambiente nde crrerá a hmlgaçã d sistema. Cada cnfiguraçã de ambiente de teste especifica uma cnfiguraçã adequada e cntrlada, necessária para a cnduçã ds testes e avaliaçã ds resultads. Prver um ambiente cntrlad significa garantir que s resultads d esfrç de teste sejam exats, válids e cm uma grande prbabilidade de serem reprduzids em utras execuções, u seja, é imprtante para uma eficiente análise e resluçã de falhas Executar Rteir de Testes Integrads Sã realizads s testes integrads definids n rteir a fim de validar se as unidades executam crretamente quand clcadas juntas. Os Testes de Integraçã devem ser executads várias vezes até que td sistema tenha sid integrad cm sucess. A final desta atividade, s sistemas u móduls cnstruíds e alterads devem estar cmpletamente validads, nã apresentand errs e incnfrmidades quant a sua integraçã. Garantir que td códig de um sistema passe pr testes integrads reduz a prbabilidade da crrência de errs de cmunicaçã entre diferentes partes (móduls u cmpnentes) em ambiente de prduçã. Os defeits identificads devem ser crrigids, sem a necessidade de relat frmal de errs encntrads, dand flexibilidade e rapidez a prcess de cnstruçã Teste A GMQS (2009) descreve essa fase cm testar funcinalmente a sluçã desenvlvida validand se s requisits slicitads fram adequadamente 38

39 implementads de md a garantir a qualidade em ambiente de prduçã. Nesta fase se btém d demandadr, que é respnsável pela hmlgaçã, faz a aprvaçã, u nã, da implantaçã d Sistema. Serã geradas as evidências de teste e TRHI Term de Respnsabilidade de Hmlgaçã e Implantaçã. Para a realizaçã ds testes é precis garantir que ambiente de hmlgaçã dispõe da estrutura de hardware e sftware necessária descrita n desenh físic. Feit iss, é entã executad Rteir de Teste Funcinal, a fim de validar se s sistemas cnstruíds pssuem algum err, adquirind cnfiança e reduzind riscs na implantaçã d sistema. A executar s testes, dentr d própri rteir deve ser preenchida a cluna de execuçã de testes cm "sim k" u "nã k". O preenchiment destas infrmações pderá ser anexad cm evidência de testes. Figura 1 - Template d Rteir de Teste Funcinal. 39