apostila engenharia de software

141
 PROFª. TÂNIA BARBOSA SALLES GAVA ENGENHARIA DE SOFTWARE SERRA 2009

Upload: elciojonas

Post on 21-Jul-2015

762 views

Category:

Documents


14 download

TRANSCRIPT

PROF. TNIA BARBOSA SALLES GAVAENGENHARIA DE SOFTWARESERRA20092Tecnologia em Anlise e Desenvolvimento de SistemasGoverno FederalMinistro de EducaoFernando HaddadIfes Instituto Federal do Esprito SantoReitorDnio Rebello ArantesPr-Reitora de EnsinoCristiane Tenan Schlittler dos SantosCoordenadora do CEAD Centro de Educao a DistnciaYvina Pavan BaldoCoordenadoras da UAB Universidade Aberta do Brasil Yvina Pavan BaldoMaria das Graas ZamborliniCurso de Tecnologia em Anlise e Desenvolvimento de SistemasCoordenao de CursoIsaura NobreDesigner InstrucionalDanielli Veiga Carneiro/ Jos Mrio Costa JniorProfessor Especialista/AutorTnia Barbosa Salles GavaCatalogao da fonte: Rogria Gomes Belchior - CRB 12/417F279eGava, Tnia Barbosa Salles Engenharia de sofware. / Tnia Barbosa Salles Gava. Vitria: Ifes, 2009.140 p. : il.1. Engenharia de software. I. Instituto Federal do Esprito Santo. II. Ttulo. CDD 005.1DIREITOS RESERVADOSIfes Instituto Federal do Esprito SantoAv. Vitria Jucutuquara Vitria ES - CEP - (27) 3331.2139Crditos de autoria da editoraoCapa: Juliana Cristina da SilvaProjeto grfco: Juliana Cristina da Silva / Nelson TorresIconografa: Nelson TorresEditorao eletrnica: Duo TranslationsReviso de texto: Ilioni Augusta da CostaMaria Madalena Covre da SilvaCOPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao escrita dos autores e do detentor dos direitos autorais.3Engenharia de SoftwareOl, Aluno(a)! um prazer t-lo conosco. O Ifes(Instituto Federal do Esprito Santo) oferece a voc, em parceria com as Prefeituras e com o Governo Federal, o Curso Tecnologia em Anlise e Desenvolvimento de Sistemas, na modalidade a distncia.Apesar de este curso ser ofertado a distncia, esperamos que haja proximidade entre ns, pois, hoje, graas aos recursos da tecnologia da informao (e-mails, chat, videoconferncia, etc.) podemos manter uma comunicao efetiva.importantequevocconheatodaaequipeenvolvidanestecurso:co-ordenadores, professores especialistas, tutores a distncia e tutores presen-ciaisporque,quandoprecisardealgumtipodeajuda,saberaquem recorrer.Na EaD Educao a Distncia, voc o grande responsvel pelo sucesso da aprendizagem. Por isso, necessrio que se organize para os estudos e para a realizao de todas as atividades, nos prazos estabelecidos, confor-me orientao dos Professores Especialistas e Tutores.FiqueatentosorientaesdeestudoqueseencontramnoManualdo Aluno!AEaD, pela sua caracterstica de amplitude e pelo uso de tecnologias mo-dernas,representauma nova forma de aprender, respeitando , sempre, o seu tempo.Desejamos-lhe sucesso!Equipe do Ifes4Tecnologia em Anlise e Desenvolvimento de SistemasFala do ProfessorConceitos importantes. Fique atento!Atividades que devem ser elaboradas por voc, aps a leitura dos textos.Indicao de leituras complemtares, referentes ao contedo estudado.Destaquedealgoimportante,referenteao contedo apresentado. Ateno!Refexo/questionamentosobrealgoimpor-tante referente ao contedo apresentado.Espao reservado para as anotaes que voc julgar necessrias.ICONOGRAFIAVeja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos.5Engenharia de SoftwareENGENHARIA DE SOFTWARECap. 1 - INTRODUO ENGENHARIA DE SOFTWARE91.1. Viso Geral91.1.1. O que software?101.1.2. O que engenharia de software?121.1.3. Qual a diferena entre engenharia de software, engenharia de sistemas e engenharia de conhecimento?121.1.4. Qual a diferena entre engenharia de software e cincia da computao?131.2. Histrico da Engenharia de Software131.3. Qualidade de Software14Cap. 2 - CARACTERSTICAS DO SOFTWARE192.1. O Software como Produto192.1.1. Caractersticas de um Software212.1.2. Mitos do Software23Cap. 3 - PROCESSOS DE SOFTWARE293.1. Uma viso genrica de processo293.2. Processo de Software x Engenharia deSoftware303.3. O que um Processo de Software323.4. Definio de Processos35Cap. 4 - MODELOS DE CICLO DE VIDA394.1. O Ciclo de Vida de um Software394.2. Categorias de Modelos de Ciclo de Vida414.3. Modelo Linear Sequencial434.4. Modelo Incremental454.5. Modelo Espiral454.6. Modelo de Prototipagem46Cap. 5 - ATIVIDADES DE DESENVOLVIMENTO515.1. Especificao e Anlise de Requisitos515.2. Projeto de Sistema536Tecnologia em Anlise e Desenvolvimento de Sistemas5.3. Implementao e Testes555.4. Entrega e Manuteno575.5. Exemplo da Loja Vitria585.5.1. Documento de Especificao de Requi-sitos59Cap. 6 - GERENCIAMENTO DE PROJETO DE SOFTWARE716.1. Introduo716.2. Escopo de Software716.3. Estimativa de Custo de Software726.3.1. Estimativa LOC (Estimativa de Linha de Cdigo)726.3.2. Anlise de Ponto de Funo776.4. Elaborao de Cronograma80Cap. 7 - MTRICAS DE SOFTWARE897.1. Mtricas de Software897.2. Mtricas de Processo927.3. Mtricas de Projeto937.4. Mtricas de Produto94Cap. 8 - ANLISE E GERENCIAMENTO DE RISCO998.1. Introduo998.2. Identificao de risco1008.3. Estimativa de risco1028.4. Exposio de risco1028.5. Mitigao de risco1038.7. Monitoramento de riscos105Cap. 9 - GARANTIA DE QUALIDADE DE SOFTWARE1099.1. Introduo1099.2. Revises Tcnicas Formais1099.3. Confiabilidade do Software1109.4. Garantia Estatstica de Qualidade deSoftware1119.5. Normas e Modelos de Qualidade de Processo de Software1149.5.1 As Normas de Qualidade ISO 90001147Engenharia de SoftwareREFERNCIAS BIBLIOGRFICAS119ANEXO A121ANEXO B1298Tecnologia em Anlise e Desenvolvimento de SistemasAPRESENTAOOl!MeunomeTniaBarbosaSallesGava,responsvelpeladisciplinade EngenhariadeSofware.SouprofessoraatualmentedoInstitutoFederal do Esprito Santo, Centro Universitrio Vila Velha (UVV), mas j lecionei em outras instituies de ensino superior como Centro Universitrio So Camilo,UniversidadeFederaldoEspritoSantoeFaculdadeSalesiana deVitria.Tambmatuocomoprofessoraemcursosdeps-graduao latu-sensu do IFES, UVV, e cursos a distncia, fornecidos pelo programa ProInfo, em parceria com o MEC-UFES-UFRGS.SougraduadaemMatemticaAplicadaeComputacional(1995) eCinciadaComputao(1996),MestreemInformtica(1998) eDoutoraemEngenhariaEltrica-Automao,todoscursadosna UFES. Nesta disciplina sero discutidos assuntos relacionados disciplina de en-genharia de sofware. Muitos dos conceitos que sero discutidos j foram vistos com diferentes nveis de profundidade nas disciplinas de Anlise de Sistema e Projeto de Sistemas, e outros assuntos sero novos para voc.O objetivo deste material auxili-lo no estudo da disciplina de engenha-ria de sofware, por meio de dicas e sugestes que destacam os pontos mais importantes a serem estudados. O objetivo do material dar um enfoque mais prtico disciplina, citando exemplos sempre que possvel, e dando sugestes de leituras complementares.Em geral, para ser bem sucedido neste curso, importante que voc faa as atividades sugeridas e estude os exerccios resolvidos, alm dos estudos regulares, evitando, dessa forma, o acmulo de contedo. A participao no ambiente e, consequentemente, a interao com os colegas e tutores extremamenteimportanteparaosucessonadisciplinaenocursocomo um todo. Procure realizar com afnco todas as atividades sugeridas. Desejo sinceramente que este material venha lhe agregar valores e que lhe ajude a construir conhecimento sobre os assuntos estudados.Prof Tnia Barbosa Salles Gava9Engenharia de SoftwarePrezado aluno,Neste primeiro captulo abordarei como temas principais uma introduo engenharia de sofware, um breve histrico dessa disciplina e falarei um poucosobrequalidadedesofware.Tambmseroapresentadosostrs tipos bsicos de atividades envolvidas na engenharia de sofware: ativida-des de desenvolvimento, atividades de gerncia de projeto e atividades de garantia da qualidade. Para cada um destes trs tipos de atividades serdedicado um captulo. A saber, captulos 5, 6 e 7 respectivamente. Bons estudos!1.1. Viso GeralOtermoEngenhariamuitocomumdeserutilizadoemdiferentes contextos. No entanto, se eu lhe pedisse para defnir o que engenharia, voc saberia me responder? AEngenharia,segundooDicionrioHouaissdalnguaportu-guesa, possui muitas defnies:Aplicao de mtodos cientcos ou empricos utilizao1. dos recursos da natureza em benefcio do ser humano;Formao, cincia e ofcio de engenheiro; 2. Oconjuntodeatividadesefunesdeumengenheiro,3. que vo da concepo e do planejamento at a responsa-bilidade pela construo e pelo controle dos equipamen-tos de uma instalao tcnica ou industrial, etc.Alm disso, vrias so as especialidades ou ramos da engenharia. Algu-mas das mais comuns so a engenharia eltrica, a mecnica, a qumica, acivil,aaeronutica,aambiental,adealimentoseaindaoutrasmais curiosas, como engenharia txtil, de plsticos, de pesca, petroqumica, robtica e de entretenimento. INTRODUO ENGENHARIA DE SOFTWARE10Tecnologia em Anlise e Desenvolvimento de Sistemas Mas e a Engenharia de Sofware, o que seria? Certamente, se voc um iniciante na rea, possui esta e muitas outras dvidas, tais como: o que um sofware, como ele produzido, se engenharia de sistemas e enge-nharia de sofware so a mesma coisa e qual a diferena de engenharia de sofware e cincia da computao (SOMMERVILLE, 2003). A seguir, tentarei esclarecer essas dvidas.1.1.1. O que software?Quando voc pensa em sofware, o que vem a sua mente? Se voc res-pondeu que sofware um programa de computador voc pensa como a maioria das pessoas. No entanto, sofware no apenas um programa, mas tambm toda a documentao associada e os dados de confgurao necessrios para fazer com que esse programa opere de forma correta. Umsistemadesofwaregeralmenteconsisteemumasrieprogramas separados tais como:os arquivos de congurao que so utilizados para congu- rar esses programas;a documentao do sistema, que descreve a estrutura des- se sistema;eadocumentaodousurio,queexplicacomoutilizar o sistema.No caso de produtos de sofware, h ainda sites web onde os usurios podem fazer download de informaes referentes a esse produto.H dois tipos de produtos de sofware:Os1.Produtos Genricos, que so sistemas do tipo stand-alone, produzidosporumaorganizaodedesenvolvimentodesof-tware e vendidos no mercado. Muitas vezes, esse tipo de sof-twarechamadodepacotedesoftware.Podemosdarcomo exemplo os processadores de texto, planilhas eletrnicas, paco-tes de desenho, ferramentas de gerenciamento de projetos, etc.Otermostand-alonesignicaindependente,isolado,autnomo. Esse adjetivo descreve um dispositivo que no necessita do suporte de outro dispositivo ou sistema, por exemplo, um computador que no est conectado a uma rede. Captulo 111Engenharia de SoftwareProdutos sob encomenda ou personalizados 2., que so sistemas encomendados por um cliente em particular e desenvolvidos especialmenteparaesseclienteporumaempresadedesen-volvimento de software. Uma diferena entre esse tipo de sof-tware e os produtos genricos que, nos produtos genricos, a especicao do software denida pela prpria organizao que o desenvolve, ao contrrio dos produtos sob encomenda, em que a especicao do software controlada pela prpria organizao que est comprando o software.Alm disso, Pressman (2006) nos apresenta sete tipos de categorias im-portantes de sofware de computadores. So elas:SoftwaredeSistemas: 1.coleodeprogramasescritospara servir a outros programas, como, por exemplo, os compilado-res, editores e utilitrios para gesto de sistemas;Softwarede Aplicao: 2.programaisoladoqueresolveuma necessidade especca do negcio, tal como o processamento de transaes no ponto de venda ou o controle do processo de fabricao em tempo real;Software Cientco e de Engenharia: 3. antigamente caracte-rizado por algoritmos que processavam nmeros, atualmente vodaastronomiavulcanologia,daanliseautomotivade tensesdinmicaorbitaldonibusespacialedabiologia molecular manufatura automatizada;Software Embutido: 4. reside dentro de um produto ou sistema e usado para implementar e controlar caractersticas e funes para o usurio nal e para o prprio sistema. Como exemplo, pode-mos citar os softwares desenvolvidos para aparelhos celulares;Softwareparalinhasdeprodutos: 5.projetadoparafornecer uma capacidade especca a ser usada por muitos clientes dife-rentes. Geralmente este tipo de software foca um mercado limi-tado e especial, tal como os produtos de controle de estoque; AplicaesWeb:6.cobremumaamplavariedadedeaplica-es, que podem ou no estar integradas a banco de dados de empresas e s aplicaes do negcio. Aplicaes de comrcio eletrnico so um exemplo de aplicaes web.Software para Inteligncia Articial: 7. faz uso de algoritmos nonumricospararesolverproblemascomplexosqueno podem ser resolvidos pela computao ou anlise direta. Apli-Introduo Engenharia de Software12Tecnologia em Anlise e Desenvolvimento de Sistemascaes nessa rea incluem robtica, sistemas especialistas, re-conhecimento de padres de imagem e voz, jogos, etc.1.1.2. O que engenharia de software?A engenharia de sofware uma disciplina da engenharia que se preo-cupa com todos os aspectos da produo de sofware, desde os estgios iniciais de especifcao do sistema at a sua manuteno, aps esse sis-tema entrar em funcionamento. Em relao engenharia de software muito importante desta-car que essa disciplina no se dedica simplesmente aos processos tcnicosdedesenvolvimentodesoftware,mastambmaativi-dades como o gerenciamento de projetos de software e o desen-volvimento de ferramentas, mtodos e teorias que dem apoio produo de software. 1.1.3. Qual a diferena entre engenharia de software, engenharia de sistemas e engenharia de conhecimento?A engenharia de sistemas uma disciplina mais antiga que a engenharia de sofware. A engenharia de sistemas engloba todos os aspectos do de-senvolvimento e da evoluo de sistemas complexos, em que o sofware desempenha papel principal. Ou seja, a engenharia de sistemas preocu-pa-se no s com o desenvolvimento de hardware, do projeto de polticas e processos, da implantao de sistemas, mas tambm da engenharia de sofware. Os engenheiros de sistema esto envolvidos na especifcao do sistema, na defnio de sua arquitetura geral e tambm na integra-o das diferentes partes necessrias para se criar um sistema completo, e menos envolvidos com o hardware e o sofware.J os engenheiros de sofware tm a responsabilidade direta de construir e manter um siste-ma de sofware. Em relao engenharia de conhecimento, trata-se de uma rea que tem a ver com os sistemas baseados em conhecimento e suas aplicaes, em que se faz investigao fundamental de modelos de representao de conhecimento e formas de raciocnio, estabelecimento demtodosdecomparao,tantodopontodevistaformalcomodo experimental, desenvolvimento de sistemas baseados em conhecimento e estudo das relaes entre sistemas e o processo ensino/aprendizagem.Captulo 113Engenharia de Software1.1.4. Qual a diferena entre engenharia de software e cincia da computao?A cincia da computao se preocupa com as teorias e mtodos bsicos referentes aos computadores e a sistemas de sofware, enquanto a enge-nharia de sofware se preocupa com os problemas prticos da produo de sofware. Da mesma forma que a fsica pr-requisito para os enge-nheiros eltricos, fundamental que os engenheiros de sofware tenham algum conhecimento sobre a cincia da computao.AtividadesAps ler o tpico 1.1 responda:1.Diferencieosconceitosdesoftware,cinciadacomputao, engenharia de sistemas e engenharia de software.2. Fale um pouco sobre como um software produzido.3.Quaissoosdoistiposdeprodutosdesoftware?Falesobre cada um desses tipos.4.Citeastrscategoriasdesoftwarequevocconsideramais importantes para nossa sociedade e justique suas escolhas.1.2. Histrico da Engenharia de SoftwareO desenvolvimento dede sofware uma atividade de crescente impor-tncia no dias de hoje. Os sistemas de sofware esto praticamente em todos os lugares, e a utilizao dos computadores nas mais diversas re-as do conhecimento tem gerado uma demanda cada vez mais crescente por solues computadorizadas.Para os iniciantes, muitas vezes o desenvolvimento de sofware confun-didocomprogramao.Issoaconteceporquegeralmentecomeamos nesta rea resolvendo pequenos problemas que vo aumentando grada-tivamente de complexidade, requerendo cada vez mais conhecimentos e habilidades. No entanto, chega-se a um ponto em que, devido comple-xidade e tamanho dos problemas a serem resolvidos, essa abordagem cen-trada na programao no mais indicada. Na verdade, essa abordagem aplicvel apenas para resolver pequenos problemas, tais como calcular mdias, ordenar conjuntos de dados,etc. De fato, medida que os pro-blemas vo se tornando mais complexos, uma abordagem de engenharia Introduo Engenharia de Software14Tecnologia em Anlise e Desenvolvimento de Sistemas necessria. E foi exatamente essa a motivao para o desenvolvimento da disciplina de engenharia de sofware, ou seja, a engenharia de sofware foi desenvolvida em resposta a problemas de construo de sistemas de grande porte e personalizados, destinados a aplicaes industriais, gover-namentais e para o setor de defesa (SOMMERVILLE, 2003).Paracompreendermosmelhoraimportnciadaengenhariadesofware na produo de sofware, vamos utilizar uma analogia feita por (FALBO, 2005), em que o autor compara a engenharia de sofware com a engenharia civil. Por exemplo, para se construir uma casinha de cachorro, difcilmente algum ir elaborar um projeto de engenharia civil, com plantas baixa, hi-drulica e eltrica. Para resolver o problema, basta um bom pedreiro. Pode ser que esse pedreiro no faa a melhor casinha de cachorro possvel, mas certamente o produto resultante atender aos requisitos pr-estabelecidos. No entanto, voc se arriscaria a investir todo o seu dinheiro, por exemplo, na construo de um edifcio comercial sem ter feito um projeto? Para se construir um edifcio fundamental realizar um estudo profundo, incluin-do anlises de solo, clculos estruturais etc., seguido de um planejamento da execuo da obra e desenvolvimento de modelos at a realizao da obra, que deve ocorrer em etapas, tais como fundao, alvenaria, acabamento, en-tre outras. Alm disso, importante realizar um acompanhamento da obra para se verifcar prazos, custos e a qualidade do que se est construindo.importantetambmdestacarqueaengenhariadesofware,almde serdesenvolvidaemrespostaaproblemasdeconstruodesistemas mais complexos, tambm visa melhoria da qualidade dos produtos de sofware e ao aumento de produtividade no processo de desenvolvimen-todesofware.Almdisso,aengenhariadesofwaretambmtratade aspectos relacionados ao estabelecimento de processos, mtodos, tcni-cas, ferramentas e ambientes de suporte produo de sofware.1.3. Qualidade de SoftwareNa seo anterior vimos que um dos objetivos da engenharia de sofwa-re melhorar a qualidade dos produtos de sofware desenvolvidos. Mas voc saberia responder o que seria qualidade de sofware?FALBO (2005) nos apresenta o conceito de qualidade como um conceito de muitas facetas. Ou seja, para um usurio, um produto de sofware de boa quali-dade deve satisfazer suas necessidades, sendo fcil de usar, efciente e confvel. Para um desenvolvedor, um produto de boa qualidade deve ser fcil de manter. Captulo 115Engenharia de SoftwareJ para um cliente, o produto de sofware deve agregar valor a seu negcio. Ob-serve que quer seja em uma perspectiva externa, interna ou sobre a qualidade de uso, o conceito de qualidade est sempre associado ao produto de sofware. Um outro aspecto muito importante a ser observado que a qualidade deve ser incorporada ao produto ao longo de todo o seu desenvolvimento.Ou seja, aqualidadedosprodutosdesofwaredependefortementedaqualidadedos processos usados para desenvolv-lo e mant-los. E essa a grande preocupa-o da engenharia de sofware, produzir sofware de qualidade!Seguindoumatendnciadeoutrossetores,aqualidadedoprocessode sofware tem sido apontada como parte fundamental para a obteno da qualidade do produto. Como veremos com mais detalhes nos captulos frente, abordagens de qualidade de processo, tal como a srie de padres ISO 9000, sugerem que, melhorando a qualidade do processo de sofware, possvel melhorar a qualidade dos produtos resultantes. Ou seja, a idia por trs disso que, uma vez que se tenham processos bem estabelecidos, que incorporem mecanismos sistemticos para acompanhar o desenvolvimen-to e avaliar a qualidade, em geral isso conduzir a produtos de qualidade (iremos tratar com mais detalhes de processos de sofware no captulo 3).Vale destacar que um processo de sofware em uma abordagem de en-genharia de sofware envolve diferentes atividades que podem ser clas-sifcadas quanto ao seu propsito como(FALBO, 2005):AtividadesdeDesenvolvimento(ouTcnicasoudeCons- ttruo): so as atividades diretamente relacionadas ao proces-so de desenvolvimento do sofware, ou seja, que contribuem diretamente para o desenvolvimento do produto de sofware a ser entregue ao cliente. So exemplos de atividades de desen-volvimento:especifcaoeanlisederequisitos,projetode sistema, implementao e testes, entrega e manuteno. Essas atividades sero discutidas no captulo 5;Atividades de Gerncia de Projeto: tso aquelas relacionadas ao planejamento e acompanhamento gerencial do projeto, tais comorealizaodeestimativas,elaboraodecronogramas, anlise dos riscos do projeto, etc. Falaremos de gerenciamento de projeto no captulo 6;AtividadesdeGarantiadaQualidade: t soasrelacionadas com a garantia da qualidade do produto em desenvolvimen-toedoprocessodesofwareutilizado,taiscomorevisese inspeesdeprodutos(intermediriosoufnais)dodesen-volvimento. Assuntos relacionados garantia de qualidade de sofware sero discutidos no captulo 8.Introduo Engenharia de Software16Tecnologia em Anlise e Desenvolvimento de SistemasFigura 1-1: Atividades do Processo de SoftwareFonte: [1] Falbo, 2005.Aespinhadorsaldodesenvolvimentoformadapelasatividadesde desenvolvimento, e geralmente essas atividades so realizadas segundo uma ordem estabelecida no planejamento. J as atividades de gerncia e de controle da qualidade so muitas vezes con-sideradas atividades de apoio, pois no esto ligadas diretamente construo do produto fnal. Essas atividades so normalmente realizadas ao longo de todo o ciclo de vida do sofware, sempre que necessrio ou em pontos pr-estabelecidos durante o planejamento, ditos marcos ou pontos de controle. AtividadesAps ler os itens 1.2 e 1.3 responda:Por que importante que um software tenha qualidade? 1. Quaissoasatividadesquegeralmenteestoenvolvidasno2. processo de software?(1) ALBO, R.A., Notas de Aula: Engenharia de Sofware. Dispo-nvel em http://www.inf.ufes.br/~falbo, 2005.(2)PRESSMAN,R.S.,EngenhariadeSofware.SoPaulo:Mc-Graw-Hill, 6 Edio, 2006.(3) SOMMERVILE, I. Engenharia de Sofware. So Paulo: Pear-son Addison Wesley, 6 edio, 2003.Captulo 117Engenharia de Software

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Introduo Engenharia de Software18Tecnologia em Anlise e Desenvolvimento de SistemasCaptulo 119Engenharia de SoftwarePrezado aluno,Agora que voc j tem uma viso geral da engenharia de software, neste captulo estudaremos o software como um produto, alm de discutirmos sobre o processo de desenvolvimento de um software. Bom estudo!2.1. O Software como ProdutoO sofware de computador o produto que os profssionais, ou seja, os engenheiros de sofware, constroem e depois mantm ao longo do tem-po para que pessoas de todo o mundo o usem, direta ou indiretamente. Comodissemosanteriormente,osofwareabrangeprogramasquepo-demexecutaremdiferentescomputadores,comdiferentestecnologias. Mas por que o sofware um produto to importante? A resposta sim-ples.Eleumprodutofundamentalemnossasociedadeporqueafeta praticamente todos os aspectos de nossas vidas e tornou-se difundido na indstria, no comrcio, na nossa cultura e em nossas atividades dirias. Tempos atrs quem poderia prever que o sofware estaria embutido em sistemas de toda espcie, tais como de transporte, mdico, de telecomuni-caes, militar, industrial, de entretenimento, etc? Vrios intelectuais tm procurado mostrar a importncia do sofware para a sociedade:Osborn,t em1979,caracterizouacriaodosofwarecomo uma nova revoluo industrial;Tofer,t em1980,chamouoadventodamicroeletrnicade terceira onda de mudana da histria da humanidade;Naisbitt,t em1982,previuatransformaodasociedadein-dustrial em uma sociedade da informao; Feigenbaum e McCorduck,t em 1983, sugeriram que o poder do sculo XXI estaria na informao e no conhecimento;Porfm, t Stoll,em1989,ponderouqueoqueelechamoude comunidadeeletrnica,criadaporredesesofwares,seriaa chave para a troca de conhecimento em todo o mundo.CARACTERSTICAS DO SOFTWARE20Tecnologia em Anlise e Desenvolvimento de SistemasUmoutroaspectoimportantedoprodutodesoftwareque,inde-pendentemente de seu tamanho, complexidade ou domnio de apli-cao,eleevoluiucomotempo,comopodemosobservar nasfases ou eras descritas a seguir: Antigamente(atmeadosdosanos60). t Sistemasbatch, pouca distribuio, software sob medida para computado-res especficos. O software visto apenas como um coadju-vante da indstria de hardware. O hardware era muito mais caro do que o software;Segunda era (at o meio dos anos 70). tSistemas multiusurio, temporeal,bancosdedados,osofwarecomeaaservisto como um produto;Terceira era (at o fnal dos anos 80 t ). Sistemas distribudos, sistemas inteligentes, hardware barato;Quarta era (do fnal dos anos 80 at os dias de hoje). tOs sis-temas passam a ter interfaces muito amigveis com o usurio; surgemasredesdecomputadores;ossistemasorientadosa objetos; os sistemas especialistas, as redes neurais e os algorit-mos genticos; a programao paralela; a Internet, o Cybers-pace e a information superhighway.O Cyberspace, tambm conhecido como ciberespao, um espao de comunicao que descarta a necessidade do homem fsico para constituiracomunicaocomofontederelacionamento,dando nfase ao ato da imaginao, necessria para a criao de uma ima-gem annima, que ter comunho com os demais.Apesar de a internet ser o principal ambiente do ciberespao, devi-do a sua popularizao e sua natureza de hipertexto, o ciberespao tambmpodeocorrernarelaodohomemcomoutrastecnolo-gias: celular, pagers, comunicao entre rdio-amadores e por ser-vios do tipo tele-amigos, por exemplo. (JUNGBLUT, 2004; GUI-MARES JR., 1999).TambmconhecidocomoCyberespao,termomuitocomumna fco cientfca, possui variaes para vrias outras denominaes referente Internet, Cyberpoeta, Cyberpunk e outros mais.J information superhighway foi um termo popular usado na dca-da de 90 para fazer referncia aos sistemas de comunicao digital. Fonte: WikipdiaCaptulo 221Engenharia de SoftwareExistem muitas questes que demonstram a preocupao da indstria comosofwareecomamaneiracomoeledesenvolvido.Otempo necessrioparasedesenvolverumsofware,osaltoscustosdedesen-volvimento de um sofware, a difculdade de corrigir todos os erros de um sofware ao entreg-lo ao cliente, a manuteno de um sofware que requertempoeesforoeadifculdadeemavaliartodooprocessode desenvolvimento do sofware so algumas dessas questes.AtividadesPesquisenaInternet,ouemoutrasfontesdepesquisaquevoc achar interessante, sobre os seguintes conceitos:Sistemas batch. 1. Sistemas monousurio e multiusurio. 2. Sistemas distribudos e programao paralela. 3. Sistemasinteligentes,sistemasespecialistas,redesneuraise4. algoritmos genricos.2.1.1. Caractersticas de um SoftwareNa nossa sociedade, existe uma infnidade de produtos que so produ-zidos todos os dias, com as mais diferentes fnalidades. Os produtos vo desdeumpofrancs,umaroupaoucalado,umbrinquedo,atum carro ou navio. Mas o que torna um sofware um produto to diferen-ciado? Observe suas caractersticas, descritas a seguir, e tente chegar a uma concluso:O sofware no fabricado no sentido clssico da palavra. O sof- 1. tware desenvolvido: se voc pensar na fabricao de um hardwa-re qualquer como, por exemplo, uma impressora, ou no desen-volvimento de um sofware qualquer como um editor de texto, verque,apesardeexistiremalgumassemelhanasentreestas duas produes, elas so duas atividades fundamentalmente di-ferentes. Caso haja um bom projeto, ambas as atividades geraro produtos de qualidade. No entanto, a fabricao de um hardware pode gerar problemas de qualidade que poderiam ser corrigidos facilmente em um sofware, ou at mesmo nem existirem nesse caso. Alm disso, ambas as atividades envolvem pessoas (embora a relao entre as pessoas envolvidas e o trabalho realizado seja Caractersticas do Software22Tecnologia em Anlise e Desenvolvimento de Sistemasdiferente)erequeremaconstruodeumproduto(embora com abordagens diferentes). Alm disso, uma diferena impor-tante entre a fabricao de um sofware e a de um hardware est relacionada ao custo desses dois tipos de produto. Os projetos de sofware no podem ser geridos como se fossem projetos de fa-bricaosimplesmente,pelofatodoscustosdosofwareserem concentrados na engenharia de sofware. Isso faz com que o cus-tododesenvolvimentodesofwaresejamuitomaiordoqueo custo da fabricao de um hardware.O sofware no se desgasta:2.voc j teve que trocar sua impres-sora, comprar um mouse novo, trocar seu modem por um mais moderno ou trocar alguma pea quebrada ou deteriorada de seu computador? Se voc possui um computador pessoal, certamen-te sim. Mas e o sofware? Precisamos troc-lo de vez em quan-doporqueelequebrou?Emboranotenhamosessarelao de desgaste ou de quebra, o sofware tem uma outra caracters-tica muito particular, o sofware torna-se obsoleto. Basta lembrar quantas vezes voc teve que atualizar seu sistema operacional ou um pacote de ferramentas como o Microsof Ofce ou o Open Ofce. Alm disso, quando um hardware se desgasta, ele tem que ser substitudo por um outro, ou ser feita uma troca de peas. J comosofwareissonoacontece.Nohpeassobressalentes para um sofware. Isso signifca que toda falha de sofware gera-da por um erro de projeto. Isso faz com que a manuteno de um sofware seja consideravelmente muito mais complexa do que a manuteno de um hardware qualquer.A maioria dos sofwares ainda continua a ser desenvolvida sob en- 3. comenda, e no como um produto genrico: se voc fosse comprar uma simples garrafa trmica, iria a uma loja e pediria ao vendedor que encomendasse uma garrafa cuja cor, estampa, altura e largura voc pu-desse escolher como mais lhe agradasse ou simplesmente entraria numa lojaelevariaumadasqueestivessemdisponveis?Emgeral,quando compramos um produto qualquer, no isso que acontece. Ou seja, os produtossofabricadosemlargaescalaedeformapadronizada.Na fabricao de um hardware, por exemplo, existem diversos componen-tes reutilizveis que foram criados para que os engenheiros se concen-trassem nos elementos realmente inovadores de um novo projeto. Em relao ao desenvolvimento de sofware, embora possa haver reusabili-dade, de forma geral, o sofware desenvolvido de forma customizada e no montado a partir de partes. Nos anos 60 preconizava-se que as bi-bliotecas de sofware permitiriam reuso intenso de cdigo. Atualmente, embora a reusabilidade seja totalmente desejvel, as perspectivas para que isso acontea so muito mais discretas.Captulo 223Engenharia de Software2.1.2. Mitos do SoftwareUm mito uma crena, uma construo mental de algo idealizado; no entanto,semcomprovaoprtica.Existemmuitosmitosquandose trata de sofware, mitos tanto da gerncia responsvel pelo sofware, dos clientes que o compram ou encomendam, quanto dos profssionais que odesenvolvem.Sendovocuminicianteounonadisciplinadeen-genhariadesofware,importantetercinciadessesmitos,queesto descritos em Pressman (2006):Mitos da GernciaOsgerentescomresponsabilidadesobreumsofwaregeralmentetrabalham sobpressoparaobedeceraoramentos,cumprircronogramasemelhorar aqualidadedessesofware.Afmdediminuirapresso,pelomenos temporariamente, eles se agarram aos seguintes mitos:Mito: J temos um livro que est cheio de padres e procedimentos para elaborar o sofware. Isso no fornece ao meu pessoal tudo o que o elesprecisamsaber.Realidade:Olivrodepadrespodeatexistir,masserqueeleusado? Os profssionais de sofware sabem de sua existncia? Ele refete as prticas modernasdaengenhariadesofware?Elecompleto?adaptvel?Est voltado para melhorar o prazo de entrega, mantendo o foco na qualidade? Em muitos casos, a resposta a essas perguntas negativa.Mito:Senosatrasarmosnocronograma,podemosadicionarmais programadores e fcar em dia.Realidade:Essetipodepensamentoumgrandeerro,poisoprocessode desenvolvimentodesofwarenoumprocessomecanizadocomoodeum hardware, por exemplo. Como citado por Brooks (1975), Adicionar pessoas a um projeto de sofware atrasado atrasa-o mais ainda. No podemos esquecer que sempre que novas pessoas so adicionadas a um projeto, a equipe j constituda precisa gastar tempo orientando os novatos, o que reduz a quantidade de tempo investida no desenvolvimento produtivo. Isso NO quer dizer que pessoas no podem ser adicionadas a um projeto. Absolutamente, mas desde que isso seja feito de maneira planejada e bem coordenada.Mito: Se eu decidir terceirizar um projeto de software, vou poder relaxar e deixar que a empresa contratada o elabore.Realidade: Se uma organizao no sabe como gerir e controlar projetos de sofwareinternamente,certamenteterproblemasnaterceirizaodeseus projetos.Caractersticas do Software24Tecnologia em Anlise e Desenvolvimento de SistemasMitos do ClienteUmclientepodeserumapessoaouempresaqueencomendouumsofware, geralmente sob contrato. Frequentemente, os clientes acreditam em certos mitos porfaltadeinformaesmaisprecisassobreodesenvolvimentodosofware porpartedosgerentesouprofssionaisdesofware.Issopodelevarafalsas expectativas e insatisfao do cliente. Mito: Estabelecer um objetivo geral para um projeto de sofware sufciente para iniciar o seu desenvolvimento podemos fornecer os detalhes posteriormente.Realidade: uma das principais causas do fracasso de um projeto de sofware terumadefnioinicialmalfeita.Numprojetodesofware,fazeruma descrio formal e detalhada do domnio da informao, das funcionalidades, do comportamento, do desempenho das interfaces, das restries do projeto e dos critrios de validao algo essencial. E isso s possvel por meio de intensa comunicao entre os envolvidos no projeto (stakeholders).OBS:comumencontrarotermostakeholderquandosefaz referncia aos envolvidos em um projeto de software. Stakeholder ou, emPortugus,parteinteressadaouinterveniente,refere-seatodos osenvolvidosnumprocesso,porexemplo,clientes,colaboradores, investidores, fornecedores, comunidade, etc.Mito: Os requisitos de um projeto mudam continuamente, mas as mudanas podemserfacilmenteadaptadasporqueoprocessodedesenvolvimentode sofware fexvel.Realidade: Outro erro muito comum. Na verdade, os requisitos de sofware mudam,masoimpactodessasmudanaspodevariarmuito,dependendo de quando elas acontecem. Por exemplo, quando uma mudana solicitada antecipadamente, quando o projeto ou mesmo a codifcao do sofware ainda no tenha comeado, o impacto do custo relativamente baixo. Por outro lado, medida que o tempo passa, o impacto do custo aumenta consideravelmente isso acontece porque os recursos j foram comprometidos, a estrutura do projetofoiestabelecidaeasmudanaspodemcausarconsequnciasque exijam recursos adicionais e grandes modifcaes no projeto. OBS:Umrequisitodefnidocomoumacondioouumacapacidade comaqualosistemadeveestardeacordo.Fonte:http://www.wthreex.com/rup/process/workfow/requirem/co_req.htm Captulo 225Engenharia de SoftwareMitos do ProfssionalOsmitosentreosprofssionaisdesofwarequeseroapresentadosaseguir existem desde os primrdios da programao, persistindo at hoje.Mito: Quando escrevemos um programa e o fazemos funcionar, nosso trabalho est completo.Realidade:Dadosdaindstriaindicamqueentre60%e80%detodoo esforo despendido em sofware vai acontecer depois de o sofware ter sido entregue ao cliente pela primeira vez, pois quando o cliente usa o sofware queelepercebesuasfalhas,equaisdesuasnecessidadesquenoforam atendidas por esse programa. Mito: At que eu esteja com o programa rodando no tenho como avaliar a sua qualidade.Realidade: Um dos mecanismos mais efcazes de garantia de qualidade de um sofware pode ser aplicado logo no incio de um projeto a reviso tcnica formal. Revises de sofware so um fltro de qualidade que se descobriu ser mais efcaz do que testes para encontrar alguns tipos de erros de sofware.Mito: O nico produto de trabalho que pode ser entregue para um projeto de sofware bem-sucedido o programa executvel.Realidade:Umprogramaexecutvelapenasumdoselementos produzidos em um projeto de software. A documentao fornece a base paraumaengenhariabem-sucedidaefuncionacomoumaorientao para o suporte ao software. Mito: A engenharia de software vai nos fazer criar documentao volumosa e desnecessria que far atrasar o projeto.Realidade: A engenharia de sofware tem a ver com a criao de qualidade, e no somente com a criao de documentos. Uma melhor qualidade leva reduo de trabalho e retrabalho. Reduzir (re)trabalho resulta em tempos de entrega mais rpidos.UmaRevisoTcnicaFormalumaatividadedegarantiada qualidade de sofware realizada por engenheiros de sofware. Seus objetivos so:Descobrir erros de funcionalidade, lgica ou implemen- 1. tao para qualquer representao do sofware;Verifcarseosofwaresobrevisosatisfazseus2. requisitos;Garantirqueosofwaretenhasidorepresentadode3. acordo com padres pr-defnidos;Conseguirqueosofwaresejadesenvolvidodemodo4. uniforme;Tornar os projetos mais administrveis. 5. Fonte: Pressman, 2006.Caractersticas do Software26Tecnologia em Anlise e Desenvolvimento de Sistemas importante que voc tenha em mente que todo projeto de sofwa-reseiniciabaseadoemalgumanecessidadedenegcio.Semum problema para se resolver no h projeto de sofware! Essa necessi-dade pode ser criar um novo produto, servio ou sistema, adaptar um sistema legado a alguma necessidade em particular, corrigir um defeitodeumaaplicaoexistenteouestenderasfuncionalidades dessa aplicao, entre outras. Ao iniciar um projeto de sofware, a necessidade do negcio muitas vezes expressa informalmente. Mas com o passar do tempo voc vai ver que a engenharia de sofware vai fornecer toda uma estrutura para que seja desenvolvido um sof-tware de qualidade que atenda a essa necessidade de negcio.SistemaLegadootermoutilizadoemrefernciaaossistemas computacionais de uma organizao que, apesar de serem bastan-te antigos, fornecem servios essenciais.Fonte: Wikipdia.AtividadesDescreva as caractersticas de um sofware que o tornam dife- 1. rente dos demais produtos que voc conhece.Falesobrepelomenosummitodagerncia,doclienteedo2. profssional. Baseadonoquevocleuataqui,faledaimportnciada3. engenhariadesofwareparaaconstruodesofwarecom qualidade.(1) FALBO, R.A., Notas de Aula: Engenharia de Sofware. Dispo-nvel em http://www.inf.ufes.br/~falbo, 2005.(2) RAPCHAN, F., Notas de Aula: Engenharia de Sofware.(3)PRESSMAN,R.S.,EngenhariadeSofware.SoPaulo:Mc-Graw-Hill, 6 Edio, 2006.Captulo 227Engenharia de Software

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Caractersticas do Software28Tecnologia em Anlise e Desenvolvimento de SistemasCaptulo 229Engenharia de SoftwareMtodos e Estratgias de EstudoPrezado aluno,Neste captulo apresentarei a diferena entre engenharia de sofwa-re e processo de desenvolvimento de sofware, dando detalhes sobre o processo de desenvolvimento de um sofware, apresentando ativi-dades principais e atividades de apoio ao processo de sofware. Bom estudo!3.1. Uma viso genrica de processoO Dicionrio Houaiss da lngua portuguesa nos d vrias defnies in-teressantes do que seja um processo. Eis algumas delas:Ao continuada, realizao contnua e prolongada de algu- 1. ma atividade; seguimento, curso, decurso;Seqnciacontnuadefatosouoperaesqueapresentam2. certa unidade ou que se reproduzem com certa regularidade; andamento, desenvolvimento, marcha;Mododefazeralgumacoisa;mtodo,maneira,3. procedimento.Masnumalinguagemtcnica,oqueseriaumprocessodedesenvol-vimentodesofware?SegundoPressman(2006),umprocessodede-senvolvimento de sofware um arcabouo para as tarefas necessrias para a construo de um sofware de qualidade. Numa linguagem bem simples, o processo de sofware um roteiro que voc cria e segue com o objetivo de desenvolver um produto de qualidade. Mas ser que enge-nharia de sofware e processo de sofware so a mesma coisa? Embora a diferena seja sutil, ela existe. Ou seja, um processo de sofware defne umaabordagemqueadotadaquandoosofwareelaborado.Masa engenharia de sofware tambm inclui tecnologias que constituem um processo, tais como mtodos tcnicos e ferramentas automatizadas. PROCESSOS DE SOFTWARE30Tecnologia em Anlise e Desenvolvimento de Sistemas3.2. Processo de Software x Engenharia de SoftwareAtaquitemosfaladoumpoucosobreengenhariadesofware.Mas chegou a hora de defnirmos o termo. Embora muitos autores tenham defniespessoaisdotermo,vamosutilizaradefniopropostapor Fritz Bauer (apud Pressman, 2006), que diz que:Engenharia de Sofware a criao e a utilizao de slidos princ-pios de engenharia a fm de obter sofwares econmicos que sejam confveis e que trabalhem efcientemente em mquinas reais. Essa defnio foi dada em 1969 na primeira conferncia sobre o assun-to e est longe de ser uma defnio completa e satisfatria. H muitos aspectos no contemplados nessa defnio, tais como os aspectos tc-nicosdaqualidadedosofware,anecessidadedesatisfaodociente ou a importncia de um processo e de medidas e unidades. Mas o IEEE (InstituteofElectricalandElectronicEngineers)em1993nosdeuuma defnio mais apurada do termo que diz que:Engenharia de Sofware (1) aplicao de uma abordagem siste-mtica, disciplinada e quantifcvel para o desenvolvimento, ope-rao e manuteno do sofware; isto , a aplicao da engenharia ao sofware. (2) o estudo de abordagens como as de (1). O IEEE - Institute of Electrical and Electronic Engineers colabora no incremento da prosperidade mundial, promovendo a engenharia de criao, desenvolvimento, integrao, compartilhamento e o conheci-mento aplicado no que se refere cincia e tecnologias da eletricidade e da informao, em benefcio da humanidade e da profsso. O IEEE foi criado em 1884, nos E.U.A. e uma sociedade tcnico-profssional internacional, dedicada ao avano da teoria e prtica da engenharia nos campos da eletricidade, eletrnica e computao. Congrega mais de 312.000 associados, entre engenheiros, cientistas, pesquisadores e outros profssionais, em cerca de 150 pases.Se voc deseja conhecer um pouco mais sobre o IEEE, consulte o site http://www.ieee.org. Captulo 331Engenharia de SoftwareA Engenharia de Sofware pode ser considerada uma tecnologia em ca-madas (Pressman, 2006). Essas camadas compreendem o foco na qua-lidade,oprocesso,osmtodoseasferramentas.Novamentevemosa relao entre processo de sofware e engenharia de sofware. Nesta def-nio podemos ver que o processo parte de um todo chamado engenha-ria de sofware. A Figura 2.1 apresenta essas camadas. Figura 3-1: Camadas da engenharia de software (Adaptado de Pressman, 2006).1) Foco na Qualidade: qualquer abordagem de engenharia, inclusive a engenharia de sofware, deve ter um compromisso com a qualidade. O foco na qualidade deve ser a base da engenharia de sofware.2) Processo: essa camada deve ser o alicerce da engenharia de sofware. O processo, como j foi dito, deve ser um arcabouo estabelecido para a efetiva utilizao da tecnologia de engenharia de sofware. Alm disso, essa camada que mantm as outras unidas e permite o desenvolvimen-to racional e adequado de sofwares.3)Mtodos:osmtodosfornecematcnicaparasedesenvolversof-twaredequalidade.Constituemumconjuntodetarefasqueincluem comunicao, anlise de requisitos, modelagem de projeto, construo de programas, testes e manuteno.4)Ferramentas:asferramentasfornecemapoioautomatizadoparao processo de sofware e os mtodos. Alm desses processos, uma parte signifcativa do trabalho da engenharia de sofware pode ser agrupada nas seguintes fases genricas: 1) Defnio: seu foco est no que ser desenvolvido. Compreende trs tarefas principais:Engenharia do sistema;tPlano de projeto do sofware ( t sofware project planning); Anlise dos requisitos do sistema.tProcessos de Software32Tecnologia em Anlise e Desenvolvimento de Sistemas2) Desenvolvimento: seu foco est em como o sofware ser desenvol-vido. Ou seja, como os dados sero estruturados e como as funes se-ro implementadas? Como as interfaces sero caracterizadas? Como o projetosertraduzidoemumalinguagemdeprogramao?Comoos testes sero feitos? Etc. Compreende trs tarefas principais:Projeto do sofware;tGerao de cdigo;tTestes.t3) Manuteno: a fase da correo de erros. H quatro tipos princi-pais de manuteno: Corretiva;tAdaptativa;tEvolutiva;tPreventiva (reengenharia). t3.3. O que um Processo de SoftwareNs vimos at aqui vrias defnies de engenharia de sofware, e que nenhuma deles consegue descrever com preciso o que seja essa disci-plina.Almdisso,vimostambmqueoprocessodedesenvolvimento de sofware pode ser considerado como uma das camadas da engenha-ria de sofware, se a consideramos uma tecnologia em camadas. Nesta seo, defniremos o que um processo de sofware, apresentando seus principais elementos.Segundo Falbo (2005), Um processo de sofware pode ser visto como o conjunto de atividades, mtodos, prticas e transformaes que guiam pessoas na produo de sofware. Um processo efcaz deve, claramente, considerarasrelaesentreasatividades,osartefatosproduzidosno desenvolvimento, as ferramentas e os procedimentos necessrios e a ha-bilidade, o treinamento e a motivao do pessoal envolvido.Alm disso, os processos de sofware so, geralmente, decompostos em diversas fases, etapas ou atividades (Falbo, 2005). So elas:Captulo 333Engenharia de Software1)Planejamento:oobjetivodestaatividadefornecerumaestrutura que possibilite ao gerente fazer estimativas razoveis de recursos, custos e prazos. Uma vez estabelecido o escopo de sofware, com os requisitos esboados,umapropostadedesenvolvimentodeveserelaborada,isto ,umplanodeprojetodeveserelaboradoconfgurandooprocessoa ser utilizado no desenvolvimento de sofware. medida que o projeto progride, o planejamento deve ser detalhado e atualizado regularmente. Pelo menos ao fnal de cada uma das fases do desenvolvimento (anlise eespecifcaoderequisitos,projeto,implementaoetestes),opla-nejamentocomoumtododeveserrevistoeoplanejamentodaetapa seguinte deve ser detalhado. O planejamento e o acompanhamento do progresso fazem parte do processo de gerncia de projeto.2) Anlise e Especifcao de Requisitos: Nesta atividade, o processo de levantamento de requisitos intensifcado. O escopo deve ser refna-do e os requisitos melhor defnidos. Para entender a natureza do sofwa-reaserconstrudo,oengenheirodesofwaretemquecompreendero domnio do problema, bem como a funcionalidade e o comportamento esperados. Uma vez capturados os requisitos do sistema a ser desenvol-vido, estes devem ser modelados, avaliados e documentados. Uma parte vital dessa atividade a construo de um modelo descrevendo o que o sofware tem que fazer (e no como faz-lo). 3)Projeto:Estaatividaderesponsvelporincorporarrequisitostec-nolgicosaosrequisitosessenciaisdosistema,modeladosnaativida-de anterior e, portanto, requer que a plataforma de implementao seja conhecida.Estaatividadeenvolvebasicamenteduasgrandesetapas: projeto da arquitetura do sistema e projeto detalhado. O objetivo da etapa de projeto da arquitetura do sistema defnir a arquitetura geral do sofware, tendo por base o modelo construdo na fase de anlise de requisitos. Essa arquitetura deve descrever a estrutura de nvel mais alto da aplicao e identifcar seus principais componentes. J o objetivo da etapa de projeto detalhado detalhar o projeto do sofware para cada componente identifcado na etapa anterior. Os componentes de sofwa-redevemsersucessivamenterefnadosemnveismaioresdedetalha-mento, at que possam ser codifcados e testados.4)Implementao:Nestaatividadeoprojetodevesertraduzidopara umaformapassveldeexecuopelamquina.Aatividadedeimple-mentao realiza essa tarefa, isto , cada unidade de sofware do projeto detalhado implementada. 5)Testes:estaatividadeincluidiversosnveisdetestes,asaber,teste deunidade,testedeintegraoetestedesistema.Inicialmente,cada unidade de sofware implementada deve ser testada e os resultados do-cumentados.Aseguir,osdiversoscomponentesdevemserintegrados Processos de Software34Tecnologia em Anlise e Desenvolvimento de Sistemassucessivamente at se obter o sistema. Finalmente, o sistema como um todo deve ser testado.6)EntregaeImplantao:umaveztestado,osofwaredevesercoloca-do em produo. Para que isso acontea, contudo, necessrio treinar os usurios,confguraroambientedeproduoe,muitasvezes,converter bases de dados. O propsito desta atividade estabelecer que o sofware satisfaa os requisitos dos usurios. Isso feito instalando o sofware no ambiente do usurio e conduzindo testes de aceitao. Quando o sofware tiver demonstrado prover as capacidades requeridas, ele pode ser aceito e a operao (prxima etapa) iniciada.7)Operao:nestaatividadeosofwareutilizadopelosusuriosno ambiente de produo.8) Manuteno: Sem dvida, o sofware sofrer mudanas aps ter sido en-tregueparaousurio.Alteraesocorreropordiversosmotivos:porque erros foram encontrados, porque o sofware precisa ser adaptado para aco-modarmudanasemseuambienteexternoouporqueoclientenecessita de funcionalidade adicional ou aumento de desempenho. Muitas vezes, de-pendendo do tipo e do porte da manuteno necessria, essa atividade pode requerer a defnio de um novo processo, em que cada uma das fases prece-dentes re-aplicada no contexto de um sofware existente, ao invs de iniciar um processo de criao de um novo sofware.Asatividadesdescritasacimasoasatividadesprincipaisdeum processo de software. No entanto, existe uma srie de outras ativi-dades de apoio que se encontram no entorno das atividades prin-cipais, mas que nem por isso deixam de ser de grande importncia (Pressman, 2006). So elas:1) Acompanhamento e controle do projeto de sofware: permi-te equipe de sofware avaliar o progresso com base no plano de projeto e tomar a ao necessria para manter o cronograma;2) Gesto de risco: avalia os riscos que podem afetar o resultado do projeto ou a qualidade do produto;3) Garantia da qualidade: defne e conduz as atividades necess-rias para garantir a qualidade do sofware;4) Revises Tcnicas Formais: avaliam os produtos de trabalho da engenharia de sofware, num esforo para descobrir e remover erros antes que eles sejam propagados para a prxima ao ou atividade;5)Medio:defneerenemedidasdeprocesso,projetoepro-duto que ajudam a equipe a entregar um sofware que satisfaa s necessidadesdousurio;podeserrealizadadeformaconjugada com todas as outras atividades principais;Captulo 335Engenharia de Software6)Gestodeconfguraodesofware:gerenciaosefeitosdas modifcaes ao longo de todo o processo de sofware;7)Gestodereusabilidade:defnecritriosparaareutilizao dosprodutosdetrabalho(inclusivecomponentesdesofware)e estabelecemecanismosparaobtercomponentesreusveis.(Um produtodetrabalhoproduzidoaofnaldeumaatividadedo processo de sofware);8)Preparaoeproduodoprodutodetrabalho:abrangeas atividades necessrias para criar produtos de trabalho como mo-delos, documentos, registros, formulrios e listas.Finalizando,umprocessodesofwareoconjuntototaldeatividades deengenhariadesofwarenecessriasparatransformarrequisitosdo usurio em sofware (Managing the Process, Humphrey, 1989), ou seja, um conjunto de atividades realizadas por pessoas cujo objetivo o de-senvolvimento ou a evoluo de um sofware e sua documentao.Figura 3-2: Processo de Desenvolvimento de Software3.4. Definio de ProcessosUm processo de sofware no pode ser defnido de uma maneira univer-sal. Para ser efcaz e conduzir construo de produtos de boa qualida-de, cada processo de sofware deve ser adequado s especifcidades do projeto em questo, tais como as caractersticas da aplicao (domnio do problema, tamanho, complexidade etc), a tecnologia a ser adotada na sua construo (paradigma de desenvolvimento, linguagem de progra-mao, mecanismo de persistncia, etc), a organizao em que o produ-to ser desenvolvido e a equipe de desenvolvimento, etc. Muitos aspectos devem ser considerados na defnio de um processo de sofware. Como descrito no item 3.3., um processo de sofware pos-sui atividades principais, tais como: anlise e especifcao de requisitos, projeto, implementao e testes, que so a base sobre a qual o processo de desenvolvimento deve ser construdo. Entretanto, a defnio de um processoenvolveoutrosfatorestaiscomoaescolhadeummodelode Processos de Software36Tecnologia em Anlise e Desenvolvimento de Sistemasciclodevida(oumodelodeprocesso),queveremosnocaptulo4,o detalhamento(decomposio)desuasmacro-atividades,aescolhade mtodos, tcnicas e roteiros (procedimentos) para a sua realizao e a defnio de recursos e artefatos necessrios e produzidos.Atividades1) Faa um paralelo entre os conceitos de engenharia de sofware e de processo de sofware.2) A engenharia de software pode ser considerada uma tecno-logia em camadas. Diante dessa afirmao, descreva cada uma dessas camadas.2) Identifique as atividades principais e as atividades de apoio deumprocessodesoftware.Faleumpoucosobrecadauma dessas atividades.(1) FALBO, R.A., Notas de Aula: Engenharia de Sofware. Dispo-nvel em http://www.inf.ufes.br/~falbo, 2005.(2)PRESSMAN,R.S.,EngenhariadeSofware.SoPaulo:Mc-Graw-Hill, 6 Edio, 2006.Captulo 337Engenharia de Software

__________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Processos de Software38Tecnologia em Anlise e Desenvolvimento de SistemasCaptulo 339Engenharia de SoftwarePrezado aluno,Neste captulo apresentaremos o que o ciclo de vida de um sof-tware, bem como as categorias mais comuns de modelos de ciclo devida:ModeloLinearSeqencial,ModeloIncremental,Mo-delo Espiral e Modelo de Prototipagem. Neste captulo tambm sero apresentados as principais atividades e documentos tpicos relacionados ao ciclo de vida de um software.Bom estudo! 4.1. O Ciclo de Vida de um SoftwareO ciclo de vida de um sofware consiste em uma sequncia de diferentes ativi-dades que so executadas durante o desenvolvimento desse sofware. Durante o desenvolvimento dessas atividades, diversos artefatos so produzidos. Um artefato um produto de trabalho, que pode ser um modelo, documento ou cdigo-fonte produzido por uma atividade, entre outros. Geralmente, as ati-vidades e os artefatos esto diretamente relacionados. Alm disso, o ciclo de desenvolvimento de um sofware marcado pelo que chamados de marcos, que so eventos que podem ser usados para defnir o status de um projeto. Por exemplo, o evento de completar o manual do usurio pode ser um marco. Os marcos so essenciais para fns de gerenciamento porque o trmino de um marco permite ao gerente identifcar o progresso do desenvolvimento do sofware. Gustafson (2003) apresenta uma lista com os Tipos de Atividades do Ciclo de Vida e Documentos Tpicos, listados a seguir:Atividade ObjetivoViabilidadeDetermina se o desenvolvimento proposto vivel.Anlise de mercadoDetermina se existe mercado potencial para esse produto.RequisitosDeterminam quais as funcionalidades o sofware deve ter.Elucidao de Requisitos Obtm dos requisitos do usurio.MODELOS DE CICLO DE VIDA40Tecnologia em Anlise e Desenvolvimento de SistemasAnlise de DomnioDetermina quais tarefas e estruturas so comuns ao problema.Planejamento do Projeto Determina como desenvolver o sofware.Anlise de Custos Determina a estimativa dos custos.CronogramaConstri o cronograma para o desenvolvimento.Garantia da Qualidade de SofwareDetermina atividades que iro ajudar a garantir a qualidade do produto.ProjetoDetermina como o sofware dever prover as funcionalidades.Projeto Arquitetural Projeta a estrutura do sistema.Projeto de InterfaceEspecifca as interfaces entre as partes do sistema.Projeto Detalhado Projeta os algoritmos para cada parte.Implementao Construo do sofware.TesteExecuo do sofware com dados para ajudar a garantir que o sofware funcione corretamente.Teste de UnidadeTeste do desenvolvedor original que focaliza o esforo de verifcao na menor unidade de projeto do sofware.Teste de Integrao Teste durante a integrao do sofware.Teste do SistemaTeste do sofware em um ambiente semelhante ao ambiente operacional.Teste AlphaTeste pelo cliente no ambiente do desenvolvedor.Teste BetaTeste pelo cliente em seu ambiente operacional.Teste de Aceitao Teste para satisfazer o cliente.Teste de RegressoTeste de armazenamento da verso anterior para garantir que a nova verso possui todas as capacidades anteriores.EntregaProv o cliente com uma soluo de sofware efciente.InstalaoTorna o sofware disponvel no ambiente operacional do cliente.Treinamento Capacita o usurio a operar o sofware.Help DeskResponde a questes (dvidas) dos usurios.ManutenoAtualizao e evoluo do sofware para garantir usabilidade constante.Tabela 4.1 - Atividades do ciclo de Vida do softwareAtividade ObjetivoCaptulo 441Engenharia de SoftwareAtividade ObjetivoContrato de TrabalhoDescrio preliminar das funcionalidades desejadas, geralmente produzidas pelo usurio.Especifcao dos Requisitos de SofwareDescreve o que o sofware fnal ir fazer.Modelo de ObjetosApresenta as classes e os objetos principais.Diagramas de Casos de UsoMostram a sequncia de possveis comportamentos do ponto de vista do usurio.Cronograma do ProjetoDescreve a ordem das tarefas e as estimativas de tempo e esforo necessrios.Plano de Teste do SofwareDescreve como o sofware ser testado para garantir o comportamento apropriado.Testes de AceitaoTestes elaborados pelo cliente para determinar a aceitabilidade do sistema.Projeto de Sofware Descreve a estrutura do sofware.Projeto ArquiteturalEstrutura de alto nvel com as interconexes.Projeto DetalhadoProjeto de baixo nvel dos mdulos ou objetos.Plano de Garantia da qualidade do sofware (SQA)Descreve as atividades que sero desenvolvidas para garantir a qualidade.Manual do Usurio Descreve como usar o sofware pronto.Cdigo Fonte O cdigo fonte do produto atual.Relatrio de TesteDescreve como os testes foram feitos e como o sistema se comportou.Relatrio de FalhasDescreve as insatisfaes do cliente com os comportamentos especfcos do sistema, geralmente suas falhas ou erros.Tabela 4.2 Documentos Tpicos4.2. Categorias de Modelos de Ciclo de Vida Um modelo de ciclo de vida ou modelo de processo, segundo Falbo (2005), pode ser visto como uma representao abstrata de um esqueleto de pro-cesso,incluindotipicamentealgumasatividadesprincipais,aordemde precedncia entre elas e, opcionalmente, artefatos requeridos e produzidos. De maneira geral, um modelo de processo descreve uma filosofia de orga-Modelos de Ciclo de Vida42Tecnologia em Anlise e Desenvolvimento de Sistemasnizaodeatividades,estruturandoasatividadesdoprocessoemfasese definindo como essas fases esto relacionadas. Entretanto, ele no descreve um curso de aes preciso, recursos, procedimentos e restries. Ou seja, ele um importante ponto de partida para definir como o projeto deve ser conduzido, mas a sua adoo no o suficiente para guiar e controlar um projeto de software na prtica. Ou seja, a escolha de um modelo de ciclo de vida (ou modelo de processo) apenas o ponto de partida para a definio de um processo de desenvolvimento de software. ComovistonadefiniodeFalbo(2005),ummodelodeciclodevida, geralmente, organiza as macro-atividades bsicas do processo (atividades principais),estabelecendoprecednciaedependnciaentreasmesmas. Noentanto,paraadefiniocompletadoprocesso,cadaatividadedes-crita no modelo de ciclo de vida deve ser decomposta e para suas subati-vidades, devem ser associados mtodos, tcnicas, ferramentas e critrios de qualidade, entre outros, formando uma base slida para o desenvolvi-mento de um software. Alm disso, outras atividades tipicamente geren-ciais devem ser definidas, entre elas atividade de gerncia de projetos e de controle e garantia da qualidade. Osseguintesfatoresinfluenciamadefiniodeumprocessoe,porcon-seguinte, a escolha do modelo de processo a ser usado como base: tipo de software (por exemplo, sistema de informao, sistema de tempo real etc.), paradigma de desenvolvimento (paradigma estruturado, orientado a obje-tos,etc.),domniodaaplicao,tamanhoecomplexidadedosistema,es-tabilidade dos requisitos, caractersticas da equipe, entre outros. A seguir, veremos com mais detalhes o que um modelo de ciclo de vida, e alguns exemplos principais desses modelos.Os modelos de ciclo de vida descritos a seguir so os modelos de ciclo de vida de sofware mais comuns (Gustafson, 2003):Modelo Linear Sequencial; 1. Modelo Incremental; 2. Modelo Espiral; 3. Modelo de Prototipagem. 4. Captulo 443Engenharia de SoftwareQuandoseestudaumassuntoemparticular,geralmenteexistem,nali-teraturaespecializada,vriosautoresqueescrevemsobreesseassunto. Almdisso,essesdiferentesautoresmuitasvezesapresentamdiferentes nomenclaturas e categorizaes para falar de um mesmo assunto. Em re-lao a modelos de ciclo de vida, existem outras formas, alm dessas, de categoriz-loseorganiz-los,quepodemserdestacadas.EmPressman (2006), por exemplo, todos os modelos de ciclo de vida so defnidos como prescritivos, pelo fato de prescreverem um conjunto de elementos de pro-cesso. Esses modelos prescritivos so, ento, divididos em:1. Modelo em Cascata;2. Modelos Incrementais: que compreendem o Modelo Incremental e o Modelo RAD (Rapid Application Development);3. Modelos Evolucionrios: que compreendem a Prototipagem, O Modelo Espiral e O Modelo de Desenvolvimento Concorrente.J Falbo (2005) categoriza os modelos de ciclo de vida como:1. Modelos Sequenciais: que contemplam o Modelo em Cascata e o Modelo V;2. Modelos Incrementais: que contemplam o Modelo Incremental e o Modelo RAD;3. Modelos Evolutivos ou Evolucionrios: que contempla o Modelo Espiral;4. Prototipao.4.3. Modelo Linear SequencialTambm chamado de Modelo em Cascata, esse modelo tem seu diagrama parecido com uma srie de cascatas, da seu nome. Inicialmente descrito por Royce em 1970, foi a primeira realizao de uma sequncia padro de tarefas. Existem muitas verses desse modelo. Na verso apresentada na Figura 4.1, note que as atividades de planejamento de projeto esto includasnafasederequisitos.Almdisso,asfasesdeentregaema-nuteno foram deixadas de fora. J a Figura 4.2 apresenta uma verso diferente da anterior. Compare as duas e tire suas concluses sobre qual seria a melhor, na sua opinio.Modelos de Ciclo de Vida44Tecnologia em Anlise e Desenvolvimento de SistemasFigura 4.1 - da pgina 13 da coleo schaum Figura 4-1: Modelo em Cascata Verso 1Fonte: Gustafson, 2003Figura 4-2: Modelo em Cascata Verso 2Fonte: Falbo, 2005Captulo 445Engenharia de Software4.4. Modelo IncrementalHmuitassituaesemqueosrequisitosiniciaisdosofwaresora-zoavelmente bem defnidos, mas o tamanho do sistema a ser desenvol-vido impossibilita a adoo de um modelo sequencial, principalmente quandohanecessidadedesefornecerrapidamenteaosusuriosum conjunto limitado de funcionalidades e depois refnar e expandir essas funcionalidadesemnovasversesdosofware.Nessescasos,ousode um modelo incremental o mais adequado.O Modelo Incremental foi proposto inicialmente por D. L. Parnas. O Obje-tivo era projetar e entregar ao cliente um conjunto mnimo do sistema que continuasse a ser um sistema usvel. O processo, ento, continuaria a inte-ragir ao longo de todo o ciclo de vida com incrementos adicionais mnimos. Ou seja, no desenvolvimento incremental, o sistema dividido em subsiste-mas ou mdulos, tomando por base a funcionalidade. Os incrementos (ou verses) so defnidos, comeando com um pequeno subsistema funcional que, a cada ciclo, acrescido de novas funcionalidades. Alm de acrescentar novas funcionalidades, nos novos ciclos, as funcionalidades providas ante-riormentepodemsermodifcadasparamelhorsatisfazersnecessidades dosclientes/usurios.Valeressaltarqueadefniodasverses,comsua segmentao e atribuio de requisitos, realizada antes do desenvolvimen-to da primeira verso. As vantagens deste modelo incluem fornecer logo ao cliente um sistema e novas verses de trabalho.4.5. Modelo EspiralComo todo sistema complexo, o sofware tambm evolui com o tempo. Seus requisitos, de negcio ou do prprio produto, muitas vezes so difceis de se-rem defnidos ou mudam frequentemente durante o desenvolvimento. Dessa forma, importante que os profssionais de sofware possam contar com mo-delos de ciclo de vida que tenham sido explicitamente projetados para lidar com incertezas e contnuas mudanas. Por serem iterativos, os modelos in-crementais podem ser aplicados a esses casos, permitindo o desenvolvimento de verses cada vez mais completas do sofware. Vale ressaltar que a grande maioria dos modelos evolutivos toma como pressuposto que os requisitos es-tejam muito bem defnidos. Faz parte desta categoria o Modelo Espiral.O Modelo Espiral, tambm chamado Modelo Espiral de Boehm, foi introdu-zido por B. Boehm, de quem recebeu o nome. A imagem do modelo de uma espiral que comea no meio e continuamente revisa as tarefas bsicas dousurio:Especifcaoderequisitos,Anlise,Projeto,Implementao, Testes e Entrega e Implantao.Modelos de Ciclo de Vida46Tecnologia em Anlise e Desenvolvimento de SistemasA palavra iterativo quer dizer um processo que se repete diversas vezes para se chegar a um resultado e a cada vez gera um resulta-do parcial que ser usado na vez seguinte. Fonte: wikipdia.Figura 4-3: Modelo EspiralFonte: Falbo, 20054.6. Modelo de Prototipagems vezes, os clientes podem at ter em mente um conjunto de objetivos gerais para um sistema de sofware. No entanto, eles no so capazes deidentifcarclaramenteosrequisitosdeentrada,processamentoe sadadessesistema.TambmchamadodePrototipao,estemodelo pode ser til para ajudar a levantar e validar requisitos, mas tambm pode acontecer de os clientes/usurios s terem uma dimenso real do queestsendodesenvolvidosecolocadosdiantedosistema.Nesses casos, o uso da prototipao fundamental. Ou seja, a prototipao umatcnicacujoobjetivoajudartantoosprofssionaisdesofware quanto os clientes a entenderem o que est sendo desenvolvido, quan-do os requisitos no esto claros. Apesar de a prototipao poder ser usada como um modelo de processo independente, ela mais comu-mente usada como uma tcnica que pode ser aplicada no contexto de qualquer modelo de processo.Captulo 447Engenharia de SoftwareNa prototipao, os objetivos gerais do sofware so defnidos, identif-cam-se as necessidade do cliente e as reas que necessitam de mais def-nies so delineadas.Aps isso, uma iterao planejada e modelada na forma de um projeto rpido. Esse projeto rpido concentra-se apenas na representao dos aspectos do sistema de sofware que so visveis ao cliente/usurio. Esse projeto leva ao desenvolvimento de um prottipo. Esseprottipoimplantadoedepoisavaliadopelocliente/usurio.O feedback dado pelo cliente/usurio usado para refnar os requisitos do sistema.Aiteraoocorremedidaqueoprottipoajustadopara satisfazerasnecessidadesdocliente,eaomesmotempopermiteaos desenvolvedores entender melhor o que precisa ser feito. Em administrao, feedback o procedimento que consiste no pro-vimento de informao a uma pessoa sobre o desempenho, conduta ou eventualidade executada por ela e objetiva reprimir, reorientar e/ou estimular uma ou mais aes determinadas, executadas ante-riormente. No nosso contexto, o feedback so as informaes que o cliente/usurio fornece aos profssionais de sofware sobre o sistema de sofware em questo, sob diferentes aspectos, quer seja de utiliza-o, atendimento das suas necessidades, facilidade de uso, etc. Atividades1) Quais so as diferenas entre um modelo de ciclo de vida do software e um modelo processo?2) Pesquise sobre outras verses do modelo em cascata e des-creva em forma de diagrama de atividades as verses que voc encontrar.3) Descreva com suas prprias palavras o modelo de prototipagem.Exerccios Resolvidos1. Como um modelo de ciclo de vida de fases contempla o geren-ciamento de sofware?2. Qual a caracterstica de um marco?Modelos de Ciclo de Vida48Tecnologia em Anlise e Desenvolvimento de Sistemas3.Paracadaumdosseguintesdocumentos,indiquea(s)fase(s) do ciclo de vida do sofware em que so desenvolvidos. Use como base o modelo cascata.- Manual fnal do usurio- Projeto arquitetural- Plano de SQA- Especifcao de Mdulos- Cdigo Fonte- Seqncia de Trabalho- Plano de Teste- Manual de Usurio Preliminar- Projeto detalhado- Estimativa de custo- Plano de Projeto- Relatrio de Teste- Documentaes4. Ordene as seguintes tarefas em termos do modelo cascata: - Teste de aceitao- Planejamento do projeto- Teste de unidade- Reviso de requisitos- Estimativa de custo- Projeto em alto nvel- Anlise de mercado- Projeto em baixo nvel- Teste de sistema- Reviso do projeto- Implementao- Especifcao de RequisitosRespostas dos Exerccios1. O ciclo de vida de fases melhora a visibilidade do projeto. O projeto pode ser gerenciado usando-se as fases como marcos. Fases mais de-talhadas permitem um monitoramento mais prximo do progresso.2. Um marco deve estar sempre relacionado com o progresso de de-senvolvimento do sofware. Por exemplo, ele pode ser usado para de-fnir o status de um projeto e, para fns de gerenciamento, permite ao gerente identifcar o progresso do desenvolvimento do sofware.Captulo 449Engenharia de Software3. - Manual fnal do usurio fase de implementao - Projeto arquitetural fase de projeto- Plano de SQA fase de planejamento de projeto- Especifcao de Mdulos - fase de projeto- Cdigo Fonte - fase de implementao- Sequncia de Trabalho fase de viabilidade- Plano de Teste fase de teste- Manual de Usurio Preliminar fase de requisitos- Projeto detalhado - fase de projeto- Estimativa de custo - fase de planejamento de projeto- Plano de Projeto - fase de planejamento de projeto- Relatrio de Teste fase de teste- Documentaes - fase de implementao4. Ordem das tarefas:1. Anlise de mercado2. Planejamento do projeto, estimativa de custo, especifcao de requisitos (podem ser feitos concomitantemente)3. Reviso dos requisitos4. Projeto em alto nvel5. Projeto em baixo nvel6. Reviso do projeto7. Implementao 8. Teste de unidade9. Teste de sistema10. Teste de aceitao (1) FALBO, R.A., Notas de Aula: Engenharia de Software. Dis-ponvel em http://www.inf.ufes.br/~falbo, 2005.(2) GUSTAFSON, DAVID A. Teoria a problemas de engenharia de software. Porto alegre: Bookman, 2003. (Coleo Schaum).PRESSMAN, R.S., Engenharia de Sofware. So Paulo: McGraw-Hill, 6 Edio, 2006.Modelos de Ciclo de Vida50Tecnologia em Anlise e Desenvolvimento de Sistemas __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________Captulo 451Engenharia de SoftwarePrezado aluno,Como visto na seo 1.3, em um processo de sofware, em uma abor-dagem de engenharia de sofware, podemos considerar trs tipos de atividades principais: de desenvolvimento, de gerncia de projetos e de garantia da qualidade. No entanto, a espinha dorsal do desenvol-vimentodeumsofwareformadapelasatividadeschamadasde atividades de desenvolvimento, tcnicas ou atividades de cons-truo.Asatividadesdegernciaedecontroledaqualidadeso muitas vezes consideradas atividades de apoio. Neste captulo apre-sentareiasatividadesdedesenvolvimento,quesoasatividades que contribuem diretamente para o desenvolvimento do produto de sofware a ser entregue ao cliente. As atividades de desenvolvimen-to compreendem basicamente as seguintes atividades: especifcao e anlise de requisitos, projeto de sistema, implementao e testes, entrega e manuteno.Bom estudo!5.1. Especificao e Anlise de RequisitosEmrelaosatividadesdedesenvolvimentodesofware,aprimeira coisaaserfeitacapturarosrequisitosquedevemsertratadospelo sistema que ser desenvolvido. Ter um entendimento completo dos re-quisitosdosofwarequeserdesenvolvidoumdosfatoresmaisim-portantes que determinaro o sucesso ou no do esforo de desenvolvi-mento desse sofware. Tambmchamadadeengenhariaderequisitos,estafasedodesen-volvimento de um sofware um processo de descoberta, refnamento, modelagem e especifcao. A engenharia de requisitos o processo de identifcar todos os envolvidos, descobrir seus objetivos e necessidades e document-los apropriadamente. Nesta fase, o escopo do sofware, que foi defnido no planejamento do proje-to, refnado em detalhes. Tambm so especifcadas as funes e o desem-ATIVIDADES DE DESENVOLVIMENTO52Tecnologia em Anlise e Desenvolvimento de Sistemaspenho do sofware, bem como as interfaces com outros sistemas e restries que o sofware deve atender. Tambm so construdos os modelos de dados que defnem o controle e o comportamento operacional do sofware. Final-mente, so defnidos os critrios para a avaliao da qualidade do produto de sofware nas atividades subsequentes (FALBO, 2005). Falbo(2005)apresentaaengenhariaderequisitoscomoumprocesso composto das seguintes atividades:LevantamentodeRequisitos:nestaatividadeidenticam-seos usurios, clientes e especialistas de domnio, que trabalham juntos com os engenheiros de requisitos para descobrir, articular e entender a organizao como um todo, o domnio da aplicao, os processos de negcio, as necessidades que o software deve atender e os pro-blemas e decincias dos sistemas atuais. Tambm so levantados os diferentes pontos de vista dos envolvidos no processo, as opor-tunidades de melhoria e restries existentes, os problemas a serem resolvidos e o desempenho requerido do sistema como um todo. Anlise de Requisitos:tem como objetivo denir um conjunto de requisitos consistentes e sem ambiguidades, que sero usados como baseparaodesenvolvimentodosoftware.Nestaatividadesero construdos diversos tipos de modelos. Nesta fase tambm pode in-cluir a negociao para se resolver conitos detectados.Documentao de Requisitos:atividade de representar os resulta-dos da engenharia de requisitos em um documento (ou conjunto de documentos) contendo os requisitos do software.VericaoeValidaodeRequisitos:avericaoderequisi-tos avalia se o documento de especicao de requisitos est sendo construdocorretamenteeseestdeacordocompadresprevia-mentedenidos,nocontendorequisitosambguos,incompletos, incoerentesouimpossveisdeseremtestados. Avalidaodere-quisitos avalia se o documento de especicao de requisitos est correto, ou seja, se os requisitos e modelos documentados atendem s reais necessidades e requisitos dos clientes/usurios.Gerncia de Requisitos:esta atividade preocupa-se em gerenciar asmudanasqueporventuraocorramnosrequisitosjacordados, mantendoumatrilhadessasmudanas,gerenciandoosrelaciona-mentos entre os requisitos e as dependncias entre o documento de requisitosedemaisartefatosproduzidosnoprocessodesoftware, de forma a garantir que mudanas nos requisitos ocorram de manei-ra controlada e documentada.Captulo 553Engenharia de SoftwareFinalizando, um requisito de sofware pode ser funcional ou no funcio-nal. Requisitos funcionais, como o prprio nome diz, descrevem as fun-es que o sistema deve fornecer e como o sistema deve se comportar em determinadas situaes. J os requisitos no funcionais descrevem restri-es sobre as funes oferecidas, tais como as restries de tempo, de uso de recursos, etc. Alguns requisitos no funcionais dizem respeito ao sis-tema como um todo e no a uma funcionalidade especfca. Os requisitos no funcionais podem ser classifcados de diferentes maneiras: requisitos dedesempenho,requisitosdeportabilidade,requisitoslegais,requisitos de conformidade etc. (FALBO, 2005).5.2. Projeto de SistemaA fase de projeto inicia-se assim que os requisitos do sofware tiverem sido especifcados e modelados. Esta atividade corresponde primeira das trs atividades do domnio computacional projeto, implementa-o e testes requeridas para se construir um sistema de sofware.Aatividadedeprojetoenvolveamodelagemdecomoosistemaser implementado, incorporando os requisitos no funcionais aos modelos construdosnafasedeanlise.Oobjetivodoprojetodeumsistema incorporar a tecnologia aos requisitos essenciais dos usurios, projetan-do o que ser construdo na fase de implementao. Assim, necessrio conhecer as tecnologias disponveis e as facilidades do ambiente de sof-tware no qual o sistema ser implementado. O projeto de sofware um processo iterativo. O projeto inicialmente representado em um alto nvel de abstrao. medida que as iteraes ocorrem,osrefnamentosconduzemarepresentaescomnveisme-nores de abstrao.Atividades de Desenvolvimento54Tecnologia em Anlise e Desenvolvimento de SistemasUma viso geral da atividade de projeto apresentada na Figura 5.1. Figura 5-1: Viso Geral da Atividade de projetoFonte: Falbo, 2005A Tabela 5.1 nos apresenta primeiramente o qu um projeto de sistema deve ser e contemplar, bem como nos apresenta os produtos de trabalho (artefatos) produzidos nessa fase (FALBO, 2005).Tabela 5.1Um projeto de sistema deve:Contemplar todos os requisitos explcitos contidos no modelo de anlise e todos os requisitos implcitos desejados pelos clientes/usurios. Ser um guia legvel e compreensvel para aqueles que iro codifcar, testar e fazer a manuteno do sofware.Fornecer um quadro completo do sofware, tratando aspectos funcionais, com-portamentais e de dados, segundo uma perspectiva de implementao. Diagramas de Casos de UsoUm projeto de sistema deve produzir:Projeto da Arquitetura do sofware: visa defnir os grandes componentes estruturais do sofware e seus relacionamentos.Projeto de Dados: tem como objetivo projetar a estrutura de armazenamento de dados necessria para implementar o sofware.ProjetodeInterface:visadescrevercomoosofwaredevesecomunicar internamente (interfaces internas), com outros sistemas (interfaces externas) e com seus usurios (interface com o usurio).Projeto Procedimental Detalhado: tem como objetivo refinar e deta-lhar a descrio procedimental dos componentes estruturais da arqui-tetura do software.Captulo 555Engenharia de Software5.3. Implementao e TestesAps projetar um sistema, necessrio escrever os programas que im-plementem esse projeto e test-los. Em relao implementao, sabe-mos que mesmo que um projeto esteja bem elaborado, esta tarefa no necessariamente fcil. A seguir listamos alguns aspectos que tornam esta tarefa to complexa:Muitas vezes, os projetistas no conhecem a plataforma de im- tplementao em detalhes e, portanto, no so capazes de chegar a um projeto algortmico passvel de implementao direta; Questesrelacionadaslegibilidade,alterabilidadeereutili- tzao devem ser levadas em conta;Geralmente os programadores trabalham em equipe, necessi- ttando integrar, testar e alterar cdigo produzido por outros, o que cria uma necessidade da criao de padres organizacio-nais que devem ser seguidos por todos os programadores;Deve-se sempre ter o cuidado de manter a correspondncia entretoscomponentesdoprojetoeocdigo.Lembrarsemprequeo projeto o guia para a implementao, ainda que os programa-dores possam e devam ter certa fexibilidade de implementao;Para uma implementao bem-sucedida, as unidades de sof- ttware devem ser codifcadas e critrios de verifcao das mes-mas devem ser defnidos.EmrelaoaTestes,muitoimportanteque,apsaimplementa-o, o produto de sofware produzido seja testado, a fm de que se descubra o nmero mximo de defeitospossvel antes da entrega do produto de sofware ao cliente. O processo de teste envolve quatro atividades principais (Falbo, 2005), descritas a seguir:Planejamento de Testes: tdiz respeito defnio das atividades de teste, das estimativas dos recursos necessrios para realiz-las, dos objetivos, estratgias e tcnicas de teste a serem adotadas e dos crit-rios para determinar quando uma atividade de teste est completa;Atividades de Desenvolvimento56Tecnologia em Anlise e Desenvolvimento de SistemasProjeto de Casos de Testes: t a atividade chave para um teste bem-sucedido, ou seja, para se descobrir a maior quantidade de defeitos comomenoresforopossvel.Oscasosdetestedevemsercuida-dosamente projetados e avaliados para se tentar obter um conjunto de casos de teste que seja representativo e envolva as vrias possibi-lidades de exerccio das funes do sofware (cobertura dos testes). Existeumagrandequantidadedetcnicasdetesteparaapoiaros testadores a projetar casos de teste, oferecendo uma abordagem sis-temtica para o teste de sofware;Execuo dos testes: tconsiste na execuo dos casos de teste e regis-tro de seus resultados;Avaliao dos resultados t : detectadas falhas, os defeitos devero ser procurados. No detectadas falhas, deve-se fazer uma avaliao fnal da qualidade dos casos de teste e defnir pelo encerramento ou no de uma atividade de teste.ExistemdiferentesCategoriasdeTcnicasdeTeste.Usaremosaca-tegorizaoqueseparaasTcnicasdeTestesemFuncionalouTeste Caixa-Preta, Estrutural ou Teste Caixa-Branca e as baseadas em m-quinas de estado (Falbo, 2005).Ost testes funcionais ou caixa-preta so conduzidos na interface do sofware, ou seja, o conhecimento sobre uma determinada implementaonousado.Essetipodetesteutilizaases-pecifcaes(derequisitos,anliseeprojeto)paradefniros objetivosdotestee,portanto,paraguiaroprojetodecasos de teste. Os testes caixa-preta ou funcionais, como o prprio nome diz, so empregados para demonstrar que as funes do sofwareestooperacionais,queaentradaadequadamente aceita e a sada corretamente produzida e que a integridade dainformaoexternamantida.Testescaixapretaexami-nam algum aspecto fundamental do sistema, pouco se preo-cupando com a estrutura lgica interna do sofware. Ost testes estruturais ou caixa-branca so baseados em um exa-me rigoroso do detalhe procedimental. Esse tipo de teste es-tabelece os objetivos do teste com base em uma determinada implementao, verifcando detalhes do cdigo, ao contrrio do teste caixa-preta. Caminhos lgicos internos so testados, defnindo casos de testes que exercitem conjuntos especfcos de condies ou laos.Captulo 557Engenharia de SoftwareOst testes baseados em mquinas de estado so projetados utili-zando o conhecimento subjacente estrutura de uma mqui-na de estados para determinar os objetivos do teste. Em relao a Tcnicas de Teste de Software, muito importante ressaltar que as diferentes tcnicas devem ser utilizadas de forma complementar,jqueelastmpropsitosdistintos,detectando categorias de erros distintas.Alm das Tcnicas de Testes, existe o que chamamos deEstratgias de Teste. A estratgia de teste a srie planejada de realizao dos testes, e compreende basicamente trs grandes fases. A sab