Produção de Software de Qualidade: Princípios e Metodologias

15082023 2213 Engenharia de Software 7 CAPITULO 1 COMO PRODUZIR UM SOFTWARE DE QUALIDADE ELEVADA Igor Fernandes Menezes INICIAR eee fs Introducao Neste capitulo vocé vai estudar os principios da Engenharia de Software os modelos de processo de desenvolvimento adotados nas fabricas principais métodos ageis de desenvolvimento e metodologia para levantamento de requisitos Vamos estudar httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 153 15082023 2213 Engenharia de Software como é feita a producdo de artefatos de levantamento de requisitos para o desenvolvimento de softwares compreendendo como trabalha uma equipe de desenvolvimento de sistemas Para nossos estudos vamos considerar que vocé deseja atuar como analista e desenvolvedor de sistemas e recebe uma oportunidade de desenvolvimento de um novo software ou de um aplicativo Assim a primeira questao que aparece é como vocé ira fazer o levantamento das informac6es para desenvolver este software Existem metodologias que vocé pode utilizar para facilitar suas atividades como o levantamento de requisitos Vamos comecar a estudar nesta area de grandes oportunidades Bons estudos s e 11 Introducao a Engenharia de Software Para comecar o estudo sobre Engenharia de Software precisamos entender a diferenca entre ciéncia e engenharia Vocé sabe qual é Vamos la Os dois estado relacionados mas existe uma grande diferenca nos conceitos e no objetivo dos profissionais de cada uma destas areas Na ciéncia se busca estudar os detalhes de um determinado escopo observando suas caracteristicas seu funcionamento e aplicando experimentos para aproximar esta pesquisa do mundo pratico Por exemplo um cientista tem que encontrar os melhores materiais para o asfalto que é usado em pontes superiores a 500 metros de extensao como foco de pesquisa httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 253 15082023 2213 Engenharia de Software Por outro lado a engenharia busca responder demandas especificas de trabalho utilizando recursos adequados desenvolvidos por cientistas como solucao para problemas praticos Isso se resume no que a pesquisadora Shari Pfleeger 2004 p 2 afirma como engenheiros de software utilizamos nosso conhecimento sobre computadores e computacao para ajudar a resolver problemas Vamos entender entao como o profissional de software se desenvolve para atender a essas demandas 111 Desenvolvimento do profissional de software Com a necessidade do desenvolvimento de softwares complexos e com grande processamento de informacgdes se tornou necessario aprimorar as técnicas e metodologias aplicadas no processo de producdo Esse aprimoramento é feito pelos cientistas da computacao que trabalham para melhorar ou criar novos procedimentos auditando e certificando sua eficiéncia e eficacia Eles realizam estudos minuciosos que resultam em um framework com as melhores praticas relacionadas ao desenvolvimento de sistemas e com ele os profissionais e engenheiros de software buscam atender suas necessidades O profissional de software deve ser capaz de entender e aplicar as tecnologias emergentes no mercado para producdao de sistemas que respondam as demandas dos clientes e de seus negocios httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 353 15082023 2213 Engenharia de Software VOCE QUER VER Steve Jobs tinha uma percepcdo agucada do que as pessoas desejavam em um produto tecnoldgico Era comum ele adiar o langamento de um produto porque nao estava satisfeito com o design No filme Steve Jobs SORKIN 2015 o roteiro mostra como essa percepcdo motivava sua equipe a sempre pensar além da parte técnica das maquinas Para comecar o desenvolvimento de um sistema é necessario criar metodologias para entender o que o cliente precisa e transformalas em funcionalidades dentro de um produto de software Para isso é necessario aprender técnicas de levantamento definicao e modelagem de requisitos e de banco de dados para passar para a linha de producao utilizando linguagens de desenvolvimento de telas Front End e de aplicagdo de logicas sistémicas Back End e se necessario comunicando e desenvolvendo uma bases de dados Em seguida 6 o momento da aplicagdo de testes funcionais para verificar se a aplicagdo desenvolvida esta conforme as exigéncias do cliente podendo assim ser disponibilizada para utilizagao Observe que sao envolvidos diversos profissionais para o desenvolvimento de sistemas com responsabilidades diferentes dentro de um projeto Ao entender o que cada um faz e as habilidades especificas necessarias vocé pode se aprofundar em suas areas de interesse alinhadas com seu perfil httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 453 15082023 2213 Engenharia de Software O analista de sistema faz a mediacdo da comunicacéo entre o clienteusuario com a equipe de producgao Para que essa comunicagao seja feita de forma eficiente ele deve utilizar tecnicas e metodologias definidas pela Engenharia de Software de forma que as necessidades sejam transformadas em solucgdes de sistemas Em uma equipe de producdo de sistema é necessario também ter um profissional responsavel pela administragao e gerenciamento do banco de dados um gestor de projetos programadores de sistemas designers de interface e analistas de testes 112 Etica na Engenharia de Software Quando alocados em um projeto em andamento é comum que os profissionais iniciantes fagam criticas a diagramas artefatos e principalmente codigos produzidos por uma outra pessoa Claro que buscamos sempre a perfeicao mas com o passar do tempo entendemos que deve haver um equilibrio no desenvolvimento e essa critica pode nos ajudar a melhorar nossos proprios processos Ao analisar um codigo produzido vocé deve pensar em fatores que podem ter influenciado nesta producao Qual tempo destinado para a producdo Teve mudancas continuas de escopo Equipe e local adequado para o desenvolvimento Teve comprometimento da equipe Foram aplicadas métricas e metodologias da Engenharia de Software Muitos sdo os fatores que podem impactar diretamente na qualidade da producao de um software 12 Modelos de desenvolvimento de httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 553 15082023 2213 Engenharia de Software Vamos entender um pouco sobre os modelos utilizado em fabricas de software para o desenvolvimento de sistemas de informacdo Uma fabrica define o modelo a ser aplicado para o desenvolvimento de um software de acordo com as caracteristicas delineadas e com o perfil dos profissionais que possui a dimensao da equipe e tipos de produtos de desenvolve E importante entender os mais variados modelos de producdo para que seja facil sua adaptacdo ao incorporar ou migrar de empresa ou equipe de trabalho Vamos entender isso melhor nos topicos a seguir 121 Processo Unificado de software No desenvolvimento de sistemas é necessario ter uma melhor organizacdo nas fases de desenvolvimento do produto proporcionando uma continua melhoria nos processos de desenvolvimento A criagao do Processo Unificado veio com o objetivo de proporcionar uma melhor divisdo entre as etapas de criacao do software O engenheiro Roger Pressman 2016 p 56 define o PU Processo Unificado como uma tentativa de aproveitar os melhores recursos e caracteristicas dos modelos tradicionais de processo de software VOCE O CONHECE httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 653 15082023 2213 Engenharia de Software Roger S Pressman é dos mais famosos escritores e engenheiro de software uma autoridade reconhecida em todo o mundo em relacgado a melhoria de processos de desenvolvimento de software Trabalhou como engenheiro de software professor e escritor por décadas e apos receber o titulo de PhD em Engenharia dedicouse a vida académica Assim o Processo Unificado representado na figura a seguir comeca com a fase de concepcao passando para as fases de elaboragao e construcao e fechando a interagao com a fase de transigao httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 753 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 853 15082023 2213 Engenharia de Software Figura 1 O Processo Unificado é definido por quatro fases e cada uma tem disciplinas vinculadas Fonte PRESSMAN 2016 p 57 A figura a seguir detalha as fases de um ciclo de vida de um software iniciando com a necessidade do cliente na construcao de um sistema para melhorar ou sistematizar um determinado procedimento Percepcao da Necessidade do Cliente Elaboracéo Desenho detalhado Ciclo de Vida Desenvolvimento do Produto Construgéo Liberacéo Codificacgao Testes de Unidade Teste de Aceitacao Figura 2 Detalhamento das etapas de um ciclo de vida de um software desde a identificagao da necessidade até a retirada do produto Fonte Elaborada pelo autor 2018 Observe na figura que o produto é desenvolvido e disponibilizado para operacdo com base na necessidade sendo utilizado por um determinado tempo até que seja necessario um aprimoramento ou substituicdo por outro retirandoo de operacdo httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 953 15082023 2213 Engenharia de Software Entao vamos detalhar um pouco mais a etapa de desenvolvimento do produto passando por todas as fases Concepcao Fase de identificacao por parte do cliente da necessidade de desenvolvimento de uma funcionalidade ou produto de software a fim de resolver um determinado problema de processo ou sistematizagao Com essa demanda o analista de sistemas faz um brainstorming com o cliente e sua equipe a fim de buscar o maximo de informacgdes possiveis para compor o artefato de levantamento de requisitos Em resumo é a fase de comunicacado com o cliente e planejamento do que sera desenvolvido PRESSMAN 2016 Elaboragao Nesta fase 0 analista de sistema deve montar o artefato de requisitos de software ou seja desenvolver requisitos funcionais nado funcionais e regras de negocios acrescidos se necessario de outras informacdes e diagramas da engenharia de software Este o momento de definigdo dos requisitos mais importantes do software definindoos em prioridades e negociando com o cliente A negociacdo é sem duvida O ponto nevralgico de toda e qualquer gestdo empresarial O precioso tempo que se investe em uma reunido ou 0 aval definitivo em um processo decisério determinam o sucesso ou 0 fracasso de uma organizacao WANDERLEY 1998 p 1 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1053 15082023 2213 Engenharia de Software Sem duvida este um momento de grande importancia no processo de desenvolvimento de software Cabe ao analista desenvolver um bom planejamento elaboracao de requisitos de software para acertar com o cliente valores e prazos para conclusao e entrega dos requisitos E aconselhavel neste momento que o analista esteja munido de estratégias de negociacdo e acompanhado por um gerente de projetos Para Pressman 2016 p 57 a fase de elaboracao inclui as atividades de comunicacao e de modelagem do modelo de processo genérico Existem técnicas de métricas de software que podem ser utilizadas neste momento do processo de desenvolvimento do sistema Com a métrica de software é possivel mensurar o tamanho do sistema quantidade de recursos complexidade custo valor e prazo de desenvolvimento Construcao Esta é a fase de construcdo das telas da parte logica do armazenamento em banco de dados e uso de todos os recursos necessarios para o funcionamento do requisito aplicando suas regras de negocio Para Pressman 2016 p 57 a fase de construgdo do PU é idéntica a atividade de construcdo definida para o processo genérico de software Usando modelo arquitetural como entrada a fase de construgao desenvolve ou adquire componentes de software que vao tornar cada caso de uso operacional para os usuarios finais Geralmente nas fabricas de software o analista de sistemas repassa as responsabilidades de execucgao e o documento feito na fase anterior Especificagao de Requisitos de Software para o Gerente de Projetos Cabe ao Gerente de Projetos httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1153 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1253 repassar as tarefas para sua equipe e monitorar principalmente custos e prazos acordados com o cliente Transição Nesta fase o produto é colocado à disposição dos usuários para o teste de aceitação Após o deferimento da funcionalidade é feita a transição das funcionalidades do servidor de homologação para o servidor de produção A fase de transição do PU abrange os últimos estágios da atividade genérica de construção e primeira parte da atividade genérica de implantação PRESSMAN 2016 p 57 VOCÊ SABIA As empresas de desenvolvimento de sistemas utilizam diferentes processos Por isso é importante conhecer os processos utilizados pelas principais empresas do setor em sua região ou estado Faça um levantamento dessas empresas e de quais os principais produtos ou serviços que elas oferecem para entender como o mercado está atuando Se for necessário e caso tenha sido acordado na fase de elaboração cabe neste momento a aplicação de um treinamento para os usuários do sistema O treinamento é um ponto importante a ser negociado com o cliente para evitar conflitos de 15082023 2213 Engenharia de Software relacionamento com ele Normalmente o contrato de prestagcao de servio das fabricas de software define que o treinamento seja repassado para dois ou trés usuarios sendo eles responsaveis pela disseminacdo do conhecimento para todos da empresa 122 Ciclo de vida do processo de desenvolvimento de software Cada empresa define o modelo de ciclo de vida do desenvolvimento de software a ser utilizado de acordo com as caracteristicas discutidas anteriormente Entretanto é importante estudar as caracteristicas de cada tipo para entendimento do processo de desenvolvimento de software aplicado para cada organizacao A garantia do processo deve assegurar que o ciclo de vida do software utilizado e as praticas de engenharia de software estejam conforme o contrato e de acordo com o planejamento feito e mesmo no caso de subcontratagao deve haver uma supervisao para que os requisitos sejam conhecidos por todos os envolvidos e atendidos plenamente BOENTE MORE COSENZA 2009 p 6 Com uma visdo empreendedora além de estudar o propdsito de cada tipo de processo de desenvolvimento de software é possivel fazer uma gestdo de conflitos e interesses na relagao com o cliente para garantir sua satisfacao com o produto que ele esta recebendo Segundo Boente e Moré 2009 p 1 ter um cliente satisfeito 6 objeto de desejo de qualquer organizacdo independentemente se o cliente é interno ou externo independentemente se estamos falando de organizac6es publicas ou privadas httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1353 15082023 2213 Engenharia de Software Mais adiante vamos entender melhor os conceitos de cada ciclo de desenvolvimento de software para fazer uma comparacao entre eles e estimular visdes e estratégias empreendedoras Algumas empresas recentes no mercado e mesmo programadores que estao comecando a aprender a codificar e criar sistemas tem o habito de ndo adotar um modelo de desenvolvimento de sistemas Isso dificulta o desenvolvimento de uma analise dos requisitos de software correndo o risco de nao seguir as praticas definidas e consolidadas pela engenharia Assim por nao pular essa fase o programador comeca a desenvolver sem nenhum planejamento sendo necessario em varios momentos voltar em funcionalidades ja criadas para readaptacdo de algum procedimento Nisso ele perde produtividade pois toda vez que é necessario voltar em uma funcionalidade ja criada o programador deve ler e interpretar todo o raciocinio logico dela A conformidade com os requisitos é o que vai atestar a qualidade do produto KOSCIANSKI 2007 VOCE SABIA A maioria das empresas e profissionais que trabalha com desenvolvimento de sistemas nao adota um modelo de ciclo de desenvolvimento de sistemas de qualidade ou bem estruturado gerando retrabalho e entregas de produtos incoerentes com o que foi solicitado httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1453 15082023 2213 Engenharia de Software Esse formato em codificaremenda sem planejamento acarreta um alto risco para o projeto nado proporciona qualidade de software conforme definigdo da engenharia e gera dificuldades para uma futura manutengdo ou aprimoramento Também pode gerar insatisfacao do cliente e a retirada e substituicao do aplicativo o que reduz o tempo de vida de utilizacao Um software ou sistema de informacdo tem qualidade quando esta adequado a empresa ao cliente eou usuario e atende a padrdes de qualidade predefinidos REZENDE 1999 apud BOENTE MORE COSENZA 2009 p 2 Como o formato codificaremenda nao possui um documento de especificagao de requisitos pela engenharia de software se torna dificil mensurar a qualidade do produto ou do processo de desenvolvimento Vamos ver a seguir alguns dos modelos de desenvolvimento mais utilizados 123 Cascata O modelo em cascata foi o primeiro criado pela Engenharia de Software em 1970 pelo cientista computacional Winston Royce Este ciclo é caracterizado pela divisdo em varias fases bem definidas permitindo uma auditoria ou pontos de controles para avaliacao de cada fase garantindo os requisitos necessarios para a proxima fase E importante ter modelos para essa avaliacgao pois isso garante a qualidade dos produtos de software BOENTE MORE COSENZA 2009 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1553 15082023 2213 Engenharia de Software VOCE O CONHECE Winston W Royce 19291995 foi o cientista computacional que desenvolveu o modelo de ciclo de vida em cascata Ele era PhD em Engenharia Aeronautica e também foi diretor na Lockheed Software Technology Center em Austin Estados Unidos durante os anos 1980 Sobre os pontos de controle para que tudo o que foi definido no projeto de software seja realizado é possivel criar um grupo de SQA Software Quality Assurance que vai ter a tarefa de ajudar a equipe de software a desenvolver um produto final de alta qualidade com base em um conjunto de atividades BOENTE OLIVEIRA ALVES 2009 Para Sommerville 2011 p 33 o ciclo de cascata considera as atividades fundamentais do processo de especificagao desenvolvimento validagao e evolucao e representa cada uma delas como fases distintas como especificagao de requisitos projeto de software implementagao teste e assim por diante Na figura a seguir podemos visualizar as etapas do ciclo de vida cascata httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1653 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1753 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1853 15082023 2213 Engenharia de Software Figura 3 Representagao do Ciclo de Vida Cascata e sua estrutura de fases definida Fonte RODRIGUES 2005 p 16 Na figura acima vemos que o ciclo de vida em cascata define suas etapas para a construcdo de software As etapas de requisitos e analise sdo de definicdo das necessidades do cliente e das funcionalidades passando assim para a terceira e quarta etapa na qual se inicia o desenho do funcionamento das telas e sua codificacdo Em principio o resultado de cada fase consiste de um ou mais documentos aprovados assinados A fase seguinte nado deve comecar antes que a fase anterior tenha terminado SOMMERVILLE 2011 p 21 Atualmente ha gestores de TI com esse tipo de visdo em que repassam as responsabilidades do desenvolvimento do software para o cliente gerando um documento de aprovacdo apos a conclusdo de cada fase Esse procedimento garante minimizar esforco de retrabalho ndo permitindo apds a aprovacdo voltar as fases anteriores Entretanto isso pode provocar insatisfacdo do cliente ja que no momento de assinatura do documento de aprovagao o cliente ainda nao tem a abstracao necessaria sobre um determinado assunto que gerou 0 conflito entre as partes Pressman 2016 define o modelo cascata em cinco etapas Comunicacao Planejamento Modelagem Construgao e Implantacao conforme vemos na figura a seguir iniciac3o do projeto Peres ts pry es codificacSo Peer erect fils fs cesT ES Hr Le re pita ats ites marlutenao Poets La monitoracao feedback httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 1953 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2053 Podemos obter outras informações importantes da análise desse procedimento Por exemplo a entrega de algo funcional para o cliente só se dá após a passagem de todas as fases acarretando uma baixa visibilidade para ele O diferencial da abordagem da figura acima que representa o Ciclo de Vida Cascata e sua estrutura de fases definida conforme a visão de Pressman 2016 em relação à figura anterior que mostra sua estrutura de fases definida é a utilização clara de etapas de gestão e planejamento do projeto aplicando métricas de estimativas cronogramas e pontos de controle conforme estipulado na fase de planejamento 124 Cascata com realimentação Percebendo a insatisfação por parte do cliente ao não permitir voltar às fases anteriores no modelo cascata com realimentação é permitido voltar para alguma correção Neste modelo a grande polêmica é conseguir mensurar o nível de retrabalho em fases anteriores podendo até inviabilizar o projeto Neste modelo é permitido voltar a apenas uma fase anterior ou seja não é permitido voltar duas fases Isso geraria uma grande possibilidade de retrabalho de forma podendo até inviabilizar o projeto caindo no formato codificaremenda Veja na figura a seguir a sequência de estrutura cascata com realimentação e a indicação dos retornos Figura 4 Representação moderna do Ciclo de Vida Cascata e sua estrutura de fases definida conforme visão de Pressman Fonte PRESSMAN 2016 p 42 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2153 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2253 15082023 2213 Engenharia de Software Figura 5 Representacao do ciclo de vida cascata com realimentagao e sua estrutura com indicdeaode retorno nas fases anteriores Fonte RODRIGUES 2005 p 17 Resumindo este modelo tem como caracteristicas e pontos de controle bem definidos e baixa visibilidade para o cliente e entrega do produto como um todo finalizagao de todas as etapas e retrabalho em fases A seguir vamos conhecer mais um modelo de desenvolvimento 125 Espiral Nos modelos anteriores o grande desafio era garantir a integridade dos requisitos de sistemas durante as fases de desenvolvimento ja que o cliente tem acesso ao produto somente no final do processo de desenvolvimento de software O ciclo de vida espiral tem como caracteristica basica o formato de divisdes de um determinado sistema em modulos funcionais Dessa forma o cliente tem a possibilidade de utilizar os modulos partes ja liberados e com isso a fabrica de software tem maior facilidade de fidelizagao do cliente Na figura a seguir vemos o modelo espiral e sua dinamica de iteracao httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2353 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2453 Este modelo é dividido em cinco fases sendo Figura 6 Representação do ciclo de vida espiral iniciando na fase de comunicação e finalizando na implantação Fonte PRESSMAN 2016 p 48 15082023 2213 Engenharia de Software comunicagao primeiro contato com o cliente e entendimento das necessidades e planejamento abstracao das necessidades momento de aplicagao do brainstorming e ativagao de uma nova unidade de gerenciamento ou modulo e modelagem consolidacao e especificagao dos requisitos e construgao construcao das telas codificaao e testes e e implantagao transicao dos artefatos funcionais do servidor de homologacao para o de producao Ao visualizar o processo de software em uma espiral Sommerville 2011 p 46 destaca que nao se trata de uma sequéncia de atividades com alguns retornos de uma para outra pois cada volta na espiral representa uma fase do processo de software Assim é possivel observar que 0 modelo espiral possui iteragdes ou seja metas parciais entregues para o cliente e cada volta no espiral representa um novo ciclo Uma das qualidades deste modelo é a gestdo de riscos ja que um grande problema é dividido em partes menores tornando o gerenciamento mais eficaz Essa é a principal diferenca entre este modelo e os outros modelos de processo de software SOMMERVILLE 2011 p 47 Este modelo possui a possibilidade de abstracoes de novos requisitos tanto para o analista quanto para o cliente permitindo que o cliente passe uma informacdo mais refinada para os proximos modulos iteragdes httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2553 15082023 2213 Engenharia de Software 126 Prototipagem evolutiva A prototipagem evolutiva 6 o modelo em que se desenvolvem versées provisdrias protdtipos para a aprovacdo dos requisitos Em sistemas baseados em tecnologias para internet a criacao das telas se torna simples com grandes possibilidades do prototipo das telas serem as mesmas telas da versdo que entrara em producdo Com a criagdo dos prototipos de tela mesmo que ainda nao funcionando o cliente tem a oportunidade de abstrair melhor os requisitos do software permitindo a mudanga dos requisitos antes da codificagdo das telas ja que a codificacdo exige um esforco relativamente maior que a simples criacdo dos protdtipos Com a estratégia de protdtipos se evita o retrabalho e se garante excelente visibilidade sobre as funcionalidades para os clientes Para Rodrigues 2005 p 18 os protdtipos cobrem cada vez mais requisitos até atingir o produto desejado Isso permite também uma gestdo de risco mensuravel ja que o software é dividido por iteracdes e proporciona maior qualidade além de facilitar o levantamento das regras de negocios A figura a seguir representa o modelo de prototipagem evolutiva httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2653 15082023 2213 Engenharia de Software Planejamento d Requisitos Analise EM ito rterte Novaliteracao Desenho ale da eRe tats Implementacao iteracao Projetoterminado Figura 7 Representacao do ciclo de vida prototipagem evolutiva e sua definigao estrutural em um formato espiral Fonte RODRIGUES 2005 p 18 A grande adaptacdo deste modelo é a inclusdo da fase de desenho na qual é realizada a prototipagem do sistema e suas funcionalidades Para Sommerville 2011 p 44 um prototipo é uma versdo inicial de um sistema de software usado para demonstrar httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTENGSOF19unidade1ebookindexhtml 2753 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2853 conceitos experimentar opções de projeto e descobrir mais sobre o problema e suas possíveis soluções Diversos recursos são úteis para uma consolidação dos requisitos principalmente o protótipo e diagramas de casos de uso com ênfase no primeiro O cliente consegue visualizar mais facilmente o que será o produto final quando tem contato com algo menos abstrato Dessa maneira ele já consegue inclusive dar sugestões e verificar se os requisitos serão atendidos 127 Entrega evolutiva A prototipagem evolutiva é o modelo que combina os modelos cascata e prototipagem evolutiva Este ciclo tem como características etapa de abstração do problema que enfatiza aspectos visuais do sistema entrega evolutiva permite melhor gerência dos projetos gerenciamento de riscos e permite uma melhor visão do sistema por parte do cliente Para Rodrigues 2005 p 19 entrega evolutiva enfatiza as funcionalidades centrais do sistema que são improváveis de serem alteradas pelo feedback do cliente O objetivo deste ciclo é separar as etapas de análise de sistemas requisitos análise e desenho arquitetônico das etapas relacionadas à produção em iterações funcionais desenho detalhado implementação testes e avaliação da iteração Na figura a seguir vemos uma representação do ciclo de vida de entrega evolutiva 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 2953 Este modelo também contempla a utilização de protótipo em dois formatos Figura 8 Representação do ciclo de vida entrega evolutiva separando a fase de análise de sistemas e gestão de projetos Fonte RODRIGUES 2005 p 19 15082023 2213 Engenharia de Software a desenho arquitet6nico apresentando um prototipo geral e posicionamento dos objetos e funcionamento da interface e b desenho detalhado no qual é definido por meio de protdtipo o formato e operacdo da funcionalidade que sera desenvolvida na iteracdo O modelo entrega evolutiva tem como papel principal evitar o desperdicio de mao de obra no desenvolvimento de software principalmente dos arquitetos de software Neste modelo o arquiteto de software faz a analise de requisitos e desenho arquitet6nico do projeto como um todo Apos finalizar a analise do software o projeto é repassado para um gerente de projeto que deve cuidar da construgdo do sistema seguindo as etapas de desenho detalhado implementagdao testes e avaliacao da iteracao 128 RUP O RUP Rational Unified Process ou Processo Unificado da Rational um processo proprietario da empresa IBM International Business Machines que fornece técnicas e artefatos a serem seguidos pelos colaboradores de uma equipe de desenvolvimento de software com o objetivo de melhorar os processos e aumentar a produtividade httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3053 15082023 2213 Engenharia de Software Iteracdes scinit Constr Constr Constr Jj Trans Trans Disciplinas i Modelagem do Negocio a a Analise e Projeto a pp Implementacao I ee i Testes eta Implantaao I Geréncia de Config I aa e Mudancas Geréncia do ProjetO 7 le eee el Ambiente ee ee eee 0 Fases Figura 9 Representacao do ciclo de vida RUP disciplinas x fases Fonte IBM BRASIL 2008 p 3 O processo RUP promove uma aproximagao disciplinada para atribuir tarefas e responsabilidades em uma organizagao de desenvolvimento com a meta de garantir que a producao do software tenha alta qualidade e esteja de acordo com as httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTENGSOF19unidade1ebookindexhtml 3153 15082023 2213 Engenharia de Software necessidades do usuario final Isso com um orcamento bem estabelecido e previsivel RATIONAL 1998 traducao nossa As caracteristicas sdo ciclo de iteragdes fases prazo e esforco entre as etapas bem definidas disciplinas e artefatos bem delineados qualidade de desenvolvimento de software baixo risco de desenvolvimento e possibilidade de desenvolvimento incremental Uma vantagem do RUP destacada por Rodrigues 2005 p 20 é que as fases podem ser divididas em iteragoes que entregam parte da funcionalidade antecipadamente para o cliente Isso reduz o risco pois o cliente pode visualizar se o que fol desenvolvido é 0 que ele deseja Na representacao da figura abaixo vemos a mensuracao dos pontos de controle marcos do processo de desenvolvimento de software do RUP Iniciacgao Elaboracao Construao Transiao Marco dos Marco da Marco da Marco de objetivos do arquitetura do capacidade lanamento ciclo de vida ciclo de vida operacional do produto inicial 8 Tempo Figura 10 Marcagao dos pontos de controle do ciclo de vida do RUP Fonte BOENTE OLIVEIRA ALVES 2009 p 12 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3253 15082023 2213 Engenharia de Software A grande vantagem do desenvolvimento do software utilizando a metodologia RUP é a possibilidade de o gerente de projeto saber o nivel de mado de obra que cada profissional da sua equipe vai ter e quando vai precisar desta mado de obra Isso é possivel acompanhar no grafico da figura Representacdo do ciclo de vida RUP disciplinas x fases vista anteriormente Este grafico 6 popularizado no mercado como o grafico das baleias pela semelhanga visual quanto maior é a barriga da baleia em uma determinada fase maior o esforo do profissional com base nas disciplinas VOCE QUER LER A Rational Software é uma familia de software da IBM para desenvolvimento suporte geréncia construgdo e desenvolvimento de projetos de desenvolvimento de software Vocé pode ler mais sobre ela no endereco httpswww01ibmcom httpswwwibmcomdeveloperworksbrrational cmmcuid00254170293015283098742cmmcsid5020000066114401528309874236cmmcsid526 4000037609411528309874240software httpswwwibmcomdeveloperworksbirational cmmcuid00254170293015283098742cmmcsid5020000066114401528309874236cmmcsid526400003 7609411528309874240brrational httpswwwibmcomdeveloperworksbrrational cmmcuid00254170293015283098742cmmcsid5020000066114401528309874236cmmcsid526 4000037609411528309874240 A figura a seguir ilustra a proporcao dos riscos nas fases do processo de desenvolvimento comparando o RUP em relacao ao modelo de cascata httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3353 15082023 2213 Engenharia de Software Cascata Concepao Interativo RUP Elaboracao Risco Construgao Transicao Tempo Figura 11 Comparacao do risco nos ciclos de vida do RUP e cascata avaliando 0 risco em uma linha do tempo Fonte RODRIGUES 2005 p 22 Como metodologia de desenvolvimento de software o RUP gera qualidade produtividade no desenvolvimento operagao e manutencao de software controle sobre o desenvolvimento dentro de custos prazos e niveis de qualidade desejados sem deixar de levar em conta a estimativa de prazos e custo com maior precisao BOENTE OLIVEIRA ALVES 2009 p 12 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3453 15082023 2213 Engenharia de Software Os modelos de ciclo de desenvolvimento de software que vimos aqui sao normalmente aplicados dentro de um fabrica de software tradicional com equipes médias ou grandes Existe também no mercado as empresas de pequeno porte ou que possui uma parte de sua equipe trabalhando outsourcing ou seja nas instalagoes do cliente E uma estratégia das fabricas de software optar pelo outsourcing quando ha clientes com requisitos vagos ou em constantes mudancas Para casos assim é recomendada a utilizacdo de metodologias ageis como as que veremos a seguir o e e 13 Metodos ageis de desenvolvimento de software Diversas metodologias foram criadas pela Engenharia de Software para sistematizar e padronizar o desenvolvimento do software As metodologias tradicionais que vimos no topico anterior sdo incorporadas nas fabricas de software e os métodos ageis para aplicagdo outsourcing sendo necessarias a consideragdo de um novo paradigma de desenvolvimento As metodologias ageis prometem melhorias na producdo de software e em sua qualidade Para se escolher 0 uso de uma metodologia agil é preciso avaliar sua viabilidade junto as necessidades do sistema a ser desenvolvido Alguns conceitos ndo se aplicam mais na época atual mas em contrapartida podemos incorporar varios outros para ajudar no desenvolvimento de aplicagoes para o cliente Alguns questionamentos sobre essas metodologias sao aplicaveis como listamos abaixo httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3553 15082023 2213 Engenharia de Software e Quala melhor metodologia ser seguida e Posso criar minha propria metodologia de trabalho conforme o ambiente da organizacao e As metodologias ageis funcionam em fabricas de softwares O outsourcing designa a agao que existe por parte de uma organizacgao em obter mao deobra terceirizada de fora da empresa A fabrica reconhece a necessidade de se desenvolver o software nas instalagdes do cliente ou seja outsourcing quando os requisitos do software sao extremamente vagos ou de grande complexidade para especificagao 131 Extreme Programming XP A Programagdo eXtrema eXtreme Programming ou simplesmente XP é uma metodologia aplicavel em pequenas e médias equipes Normalmente a XP é adotada em um ambiente de requisitos vagos de dificil definigdo e constante mudancgas Neste ambiente a utilizagdo de metodologias ageis ganha forca permitindo ajustes ao longo do desenvolvimento e possibilitando pequenas versoes que serao imediatamente incorporadas e disponibilizadas para os usuarios Os requisitos neste tipo de programacdo sdo expressos como cenarios que recebem o nome de historias do usuario que sdo implementados diretamente como uma série de tarefas uma linha de producdo SOMMERVILLE 2011 p 58 Os programadores podem trabalhar em pares e desenvolver testes para cada tarefa antes da escrita do httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3653 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3753 código Os testes são implementados logo que um novo recurso é integrado à versão final disponível para os usuários Sommerville 2011 p 59 destaca como valores e princípios da XP equipe de desenvolvimento e cliente devem estabelecer uma boa comunicação desenvolvimento por iteração focando a simplicidade tendo requisitos tão vagos é fundamental uma cultura de feedbacks constantes em relação ao desenvolvimento e satisfação do cliente desenvolvimentos incrementais baseados nas necessidades do diaadia receptividade a mudanças sabendo que é sinônimo da prestação de serviço A metodologia XP se baseia em conceitos que devem ser observados em sua adoção pela equipe de desenvolvimento Na lista a seguir de acordo com Teles 2004 vemos alguns deles Planejamento desenvolvimento feito por semana chamado de iterações No início da semana reunião de planejamento são identificadas as prioridades das funcionalidades junto ao cliente Neste momento também são feitas as estimativas pelos desenvolvedores do tempo gasto para cada tarefa O cliente tem a liberdade de alterar a ordem de prioridade das tarefas a qualquer momento Ao final da tarefa o cliente recebe a funcionalidade 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3853 para aplicar o teste de aceitação e validação se está conforme o requisito levantado Pequenas versões sempre que é feito um conjunto de funcionalidades é liberada uma nova versão do sistema A tendência da metodologia ágil é a liberação de versões de forma mais rápida assim que um conjunto mínimo de tarefas foram integradas Metáfora entender a realidade do cliente e utilizar os termos de comunicação do negócio é importante para a sintonia entre as partes evitando que a equipe técnica utilize conceitos e palavras da área Projeto simples o XP deve ser simples O projeto deve ser elaborado para durar apenas uma semana Deve fazer justamente o que foi solicitado Nos sprints seguintes as funcionalidades serão melhoradas e novos recursos serão incluídos Time coeso a equipe de desenvolvimento e o cliente devem ter uma comunicação frequente Testes de aceitação teste feito pelo cliente avaliando se está conforme solicitação Ritmo sustentável o ritmo de trabalho normal em um projeto bem planejado costuma ser de 40 horassemana 8 horasdia evitando horas extras Se o projeto necessitar de horas extras por mais de duas semanas é porque tem um problema mais grave que precisa ser corrigido Reuniões em pé reuniões literalmente em pé rápidas e com duração de no máximo 10 minutos Posse coletiva o código pode ser alterado por qualquer outro desenvolvedor mesmo não sendo o criador 15082023 2213 Engenharia de Software e Programagao em pares dois desenvolvedores trabalham em um unico computador e Padroes de codificagao 0 padrdo de codificacdo deve ser unico na equipe e Desenvolvimento orientado a testes 0 primeiro passo é a elaboracdo do teste unitario Depois é criado 0 codigo compativel para que o teste funcione abordagem contraria do que diz a Engenharia de Software tradicional e Refatoracdo processo de melhoria continua do codigo da funcionalidade e Integracdo continua sempre que uma funcionalidade é criada ou alterada uma nova versdo é imediatamente incorporada e disponibilizada para o usuario e Cliente no desenvolvimento onsite cliente precisa estar presente e disponivel em tempo integral para que os desenvolvedores possam solucionar suas duvidas evitando assim problemas no entendimento e desempenho na producao e Padrées de codigo padrdes existem e sdo seguidos pelos desenvolvedores facilitando a manutencdo do codigo por qualquer membro da equipe e Ambiente de trabalho aberto sala ampla ao inves de cubiculos e Apenas regras time tem regras a serem seguidas mas elas podem ser alteradas A metodologia XP é uma das mais importantes dentro do mundo agil e por isso é importante conhecéla Mas ha outras entéo vamos estudar novas abordagens ageis a seguir httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 3953 15082023 2213 Engenharia de Software 132 Scrum A metodologia Scrum foi criada para a gestdo de projetos ageis e empresas de fabricagdo de automoveis e produtos de consumo O método Scrum pode ser aplicado em equipes pequenas e médias que tém tarefas dinamicas com mudancas frequentes Sommerville 2011 p 64 define o método Scrum como uma abordagem de iteragdes com um periodo limitado de 30 dias Nesse espaco de tempo sdo feitas reunides diarias breves de pé que levantam trés questdes especiais respondidas pelos membros da equipe O Scrum é utilizado principalmente no gerenciamento de projetos de software mas pode ser utilizada em qualquer segmento de negocio Normalmente é utilizado juntamente com outras metodologias ageis no mercado dentre elas a Extreme Programming VOCE QUER LER O quadro de MoSCoW é uma importante técnica para priorizacdo de tarefas criado por Dai Clegg que classifica a ordem das tarefas em tem que fazer deve fazer poderia fazer e interessante fazer Leia mais no artigo A Técnica de Priorizagao MoSCoW OLIVEIRA 2014 httpsissuucomronieltondocsartigoprince2moscow2014mpbr httpsissuucomronieltondocsartigoprince2moscow2014mpbr httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4053 15082023 2213 Engenharia de Software No topico a seguir vamos estudar a engenharia de requisitos necessaria para essas metodologias ageis e para a Engenharia de Software tradicional e e e 14 Engenharia de requisitos Os requisitos no contexto da Engenharia de Software representam o levantamento e abstragoes de informacoes que contribuem com o processo de desenvolvimento de software e sua manutencao Para Pressman 2016 p 167 analise de requisitos resulta na especificagdo das caracteristicas operacionais do software A engenharia de requisitos 6 composta por seis fases distintas sendo requisitos analise projeto implementacdo teste e manutencdao httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4153 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4253 De acordo com Magela 2006 p 13 podemos entender a pirâmide da seguinte forma O usuário pode imaginar os números ao lado da figura como valores monetários ou tempo em minutos de um requisito omitido ou com erro Ou seja omitir ou especificar erroneamente um requisito custa 20 vezes mais se sua descoberta ou correção for realizada na fase implementação e 200 vezes mais se for descoberta na manutenção Podemos compreender melhor a engenharia de requisitos a partir de três importantes conceitos requisitos funcionais não funcionais e regras de negócios Vamos entender melhor cada um deles no próximo tópico Figura 12 Pirâmide de propagação de erro Relação do tempo versus momento de identificação de um bug Fonte MAGELA 2006 p 13 15082023 2213 Engenharia de Software I httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4353 141 Requisitos funcionais Os requisitos funcionais descrevem as funcionalidades telas que o sistema de informação deve ter Esses requisitos são declarações de serviços que o sistema deve fornecer de como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em determinadas situações SOMMERVILLE 2011 p 73 que também podem explicitar o que o sistema não deve fazer Para entender melhor isso vamos ver dois exemplos de requisitos funcionais em um sistema bancário Exemplo Requisitos Funcional 1 O Sistema XB deve permitir que o atendente faça o cadastramento dos dados do cliente Exemplo Requisitos Funcional 2 O Sistema XB deve permitir que o gerente faça a abertura de conta para um novo cliente Para que o requisito tenha conformidade e evite problemas de interpretação do texto algumas regras devem ser respeitadas para a construção da frase Veja no requisito de exemplo as marcações do sistema ator e funcionalidade 15082023 2213 Engenharia de Software o Sistema XB deve permitir que o gerente faca a abertura de conta para um novo cliente Sendo que 1 identificacdo do sistema no qual deve ser construida a funcionalidade ator que provoca estimulos a funcionalidade Um ator pode ser do tipo pessoa gerente vendedor consultor e outros sistema legado outro sistema que envia ou recebe informac6des do sistema XB ou um periférico leitora de cédigos de barras leitora biométrica e outros periféricos de entrada e saida 3 requisito funcional de software 142 Requisitos nado funcionais Os requisitos nado funcionais sdo as qualidades ou caracteristicas gerais de um software no que diz respeito a sua facilidade de alteracdes changeability usabilidade desempenho reusabilidade facilidade de instalacao portabilidade concorréncia seguranca necessidade de treinamento complexidade de processamento e eficiéncia online Para Sommerville 2011 p 73 os requisitos nao funcionais sao restricdes aos servicos ou funcgoes oferecidas pelo sistema Incluem restricdes de timing restrigoes no processo de desenvolvimento e restrigdes impostas pelas normas httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4453 15082023 2213 Engenharia de Software VOCE QUER LER O levantamento de requisitos certamente é um dos principais entendimentos que o analista de sistemas deve ter para iniciar a produgao de um projeto Para se aprofundar nesse assunto recomendamos a leitura do capitulo quatro do livro Engenharia de Software de an Sommerville 2011 Agora vamos ver dois exemplos de requisitos nao funcionais de um sistema de vendas Exemplo Requisito Nao Funcional 1 O Sistema XB deve permitir 0 acesso via nternet Explorer verses 7 e 8 Exemplo Requisito Nao Funcional 2 O Sistema XB deve funcionar em horario de atendimento da empresa das 8h as 18h Observe que para o requisito ndo funcional também é informado qual o sistema que deve respeitar a caracteristica escrita neste requisito httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4553 15082023 2213 Engenharia de Software é e 143 Regras de negocio As regras de negocio sdo todas das regras especificas de uma empresa ou ramo de atividade que podem ou nao ser incorporadas em um sistema de informagao Para Larman 2007 p 85 regras de negocio também chamadas de regras de dominio descrevem tipicamente requisitos ou politicas que transcendem um projeto de software elas sdo necessarias no dominio ou no negocio e muitas aplicagdes podem precisar respeitalas Vamos entender melhor com dois exemplos de requisitos nao funcionais de um sistema bancario exemplo 1 e um sistema académico exemplo 2 Exemplo Regra de Negocio 1 Para ativagdo da conta o cliente deve depositar um valor minimo de RS 5000 cinquenta reais Exemplo Regra de Negocio 2 Para o aluno ser aprovado em uma disciplina deve ter uma nota igual ou superior a 60 pontos CASO httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4653 15082023 2213 Engenharia de Software Vamos acompanhar uma descricao de necessidade de construgao de um sistema para gestao escolar Neste texto foram destacados os possiveis requisitos funcionais nado funcionais e regras de negocio de forma melhorar o entendimento dos conceitos e aplicaado na pratica requisitos funcionais nado funcionais regras de negdcio Vocé foi alocado para desenvolver um sistema de gestao escolar Atualmente a escola Patat inhas faz todo seu controle académico em planilhas e deseja melhorar este processo A escola possui trés cursos técnicos com aproximadamente 12 turmas ativas que funciona no periodo matutino e noturno O sistema deve ser utilizado principalmente pelos funcionarios da secretaria que funciona das 13h as 22h equipados com Computadores modemios e com acesso a intemmet E importante que o sistema controle as notas dos alunos professores e suas respectivas disciplinas dentro do curso O aluno deve ser capaz de acessar via portal suas notas nas disciplinas e para ser aprovado deve ter uma nota igual ou superior a seis Ao realizar uma analise dos ciclos de vida observamos que os ciclos Entrega Evolutiva Prototipagem Evolutiva e o RUP apresentam vantagens quando comparados aos de Cascata e Espiral Cada ciclo de desenvolvimento tem pontos de estudo que valem se estudados mais a fundo divisao clara de etapas e pontos de controles no modelo de cascata melhor gerenciamento de conflitos com clientes na questao de retrabalho no ciclo de cascata com realimentagao divisdo de médulos que proporciona melhor negociacdo com o cliente e qualidade no desenvolvimento de software httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4753 15082023 2213 Engenharia de Software criagdo de protdtipos evolutivos para melhor abstragdo do sistema por parte do cliente refinamento do processo de desenvolvimento de software tratado pelo ciclo de entrega evolutivo de forma a proporcionar um melhor gerenciamento de mao de obra ecom o RUP proporcionando um planejamento e gestao dos processos Com esses estudos recomendamos algumas acoes basicas que devem existir em uma fabrica de software por exemplo a dividir a fabricagao do produto de software em etapas b nos intervalos de fases criar uma auditoria da fase que acaba de terminar antes de passar para proxima etapa c trabalhar com prototipos na fase de andlise de requisitos d entrega de unidades funcionais de software para o cliente ao longo do desenvolvimento do software como um todo e procurar utilizar métricas de software f elaborar um documento padrdo de analise e outras fases de forma que atenda a realidade da fabrica g escolher o ciclo de desenvolvimento conforme qualificacao dos profissionais que trabalham na fabrica entre outras recomendac6es citadas neste trabalho httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4853 15082023 2213 Engenharia de Software Assim podemos concluir que dentre os modelos de ciclos de vida de desenvolvimento de sistemas que estudamos o RUP proporciona maior quantidade de beneficios mas para que este processo tenha sucesso é necessario uma equipe e gerentes qualificados tecnicamente para trabalhar com a ferramenta Mas a realidade é que faltam profissionais disponiveis no mercado Caso tenha uma equipe heterogénea mas com um analista de sistemas com bastante experiéncia e conhecimentos 0 modelo de Entrega Evolutiva pode ser aplicado com eficiéncia Para os demais casos 0 modelo de Prototipagem Evolutiva atende bem as necessidades Sint Chegamos ao final deste capitulo Aprendemos sobre os modelos de ciclos de vida de software que possibilitam um melhor gerenciamento de conflitos com os clientes aumento na produtividade e qualidade final do software e equilibrio empresarial para as fabricas de software e metodologias ageis Vimos que essas metodologias sdo utilizadas com mais frequéncia em projetos em constantes mudangas eou requisitos vagos e também conhecemos conceitos relacionados a engenharia de requisitos Neste capitulo vocé teve a oportunidade de e entender o que é Engenharia de Software e a sua importancia compreender que para desenvolver softwares distintos podem ser necessarias técnicas diferentes de engenharia httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 4953 15082023 2213 Engenharia de Software e conhecer algumas quest6es éticas e profissionais para engenheiros de software compreender os conceitos e saber aplicar os modelos genéricos de processos de software e conhecer as atividades fundamentais do processo de engenharia de requisitos desenvolvimento testes e evolucao de software e entender por que os processos devem ser organizados de maneira a lidar com as mudangas nos requisitos e projeto de software compreender como o RUP integra boas praticas de Engenharia de Software na criacdo de processos de software adaptaveis compreender os métodos ageis de desenvolvimento de software e conhecer o manifesto agil e saber diferenciar desenvolvimento agil de desenvolvimento voltado a planos e conhecer as praticas de XP compreender a abordagem Scrum e tomar ciéncia de quest6es de escalonamento de métodos ageis compreender os conceitos de requisitos de usuario e de sistema e entender por que os requisitos de usuario e de sistema devem ser escritos de formas diferentes e saber a diferencga entre requisitos funcionais e nao funcionais compreender o documento de requisitos de software httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 5053 15082023 2213 Engenharia de Software Clique para baixar o contetido deste tema BOENTE A MORE J Um modelo Fuzzy para avaliacdo da satisfacdo dos Gerentes de Projetos de Software de uma fundacao publica estadual XXIX Encontro Nacional de Engenharia de Produgao 2009 BOENTE A MORE J COSENZA H Avaliacdo Fuzzy da qualidade de produtos de software numa fundagao publica estadual VII Simposio de Exceléncia em Gestao e Tecnologia 2009 BOENTE A OLIVEIRA F ALVES J C RUP como metodologia de desenvolvimento de software para obtengao da qualidade de software XXIX Encontro Nacional de Engenharia de Produgao 2009 IBM BRASIL Rational Unified Process Best Practices for Software Development Teams Portal Rational Software 1998 Disponivel em httpswwwibmcomdeveloperworksrationallibrarycontent03July1000125112 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 5153 15082023 2213 Engenharia de Software 51bestpracticesTP026Bpdf httpswwwibmcomdeveloperworksrationallibrarycontent03July1000125112 51bestpracticesTP026Bpdf Acesso em 662018 KOSCIANSKI A Qualidade de software aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software 2 ed Sao Paulo Novatec 2007 LARMAN C Utilizando UML e padr6es uma introducdo a analise e ao projeto orientado a objetos e ao desenvolvimento iterativo Tradugao Rosana Vaccare Braga 3 ed Porto Alegre Bookman 2007 MAGELA R Engenharia de Software aplicada fundamentos Rio de Janeiro Alta Books 2006 OLIVEIRA R R A Técnica de Priorizagdéo MoSCoW Management Plaza International 2014 Disponivel em httpsissuucomronieltondocsartigoprince2moscow2014mpbr httpsissuucomronieltondocsartigoprince2moscow2014mpbr Acesso em 06062018 PFLEEGER S L Engenharia de Software Teoria e Pratica 2 ed Sdo0 Paulo Pearson Addison Wesley 2004 PRESSMAN R Engenharia de Software 8 ed Porto Alegre AMGH 2016 Disponivel em https brasilblackboardcomwebappsblackboardcontentlistContentjsp courseid1986891contentid41222111modereset https httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTIENGSOF19unidade1ebookindexhtml 5253 15082023 2213 Engenharia de Software brasilblackboardcomwebappsblackboardcontentlistContentjsp courseid1986891contentid4122211 1modereset Acesso em 24052018 RATIONAL Software Corporation Sobre o Rational Unified Process Sao Paulo 2002 Disponivel em ftppublicdheibmcomsoftwarepdfbrRUPDSpdf ftppublicdheibmcomsoftwarepdfbrRUPDSpdf Acesso em 18052018 RODRIGUES C A Engenharia de Software Apostila da disciplina de Engenharia de Software Curso de Especializacdo em Engenharia de Software Centro Universitario UNA 2005 SOMMERVILLE I Engenharia de Software 9 ed Sao Paulo Pearson Addison Wesley 2011 SORKIN A Steve Jobs Diregao Danny Boyle Produgao Danny Boyle Guymon Casady Christian Colson Mark Gordon Scott Rudin Estados Unidos 2015 TELES V M Extreme Programming aprenda como encantar seus usuarios desenvolvendo software com agilidade e alta qualidade Sao Paulo Novatec 2004 WANDERLEY J A Negociagao total encontrando solugdes vencendo resisténcias obtendo resultados Sao Paulo Gente 1998 httpscodelyfmucontents3amazonawscomMoodleEADConteudoCTENGSOF19unidade1ebookindexhtml 5353