Metodologia Tradicional X Ágil

Prévia do material em texto

<p>Página inicial</p><p>METODOLOGIA PARA</p><p>DESENVOLVIMENTO</p><p>DE SOFTWARE</p><p>Professor :</p><p>Me. Jackson Luis Schirigatti</p><p>Objetivos de aprendizagem</p><p>• Apresentar e compreender os conceitos de metodologia de desenvolvimento de software.</p><p>• Apresentar e compreender as atividades de especificação de software.</p><p>• Apresentar e compreender as atividades de projeto e implementação do software.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>Plano de estudo</p><p>A seguir, apresentam-se os tópicos que você estudará nesta unidade:</p><p>• Conceitos de Metodologias de Desenvolvimento de Software.</p><p>• Fase de Especificação de Software.</p><p>• Fase de Projeto e Implementação do Software.</p><p>Introdução</p><p>Para compreender os benefícios entre as metodologias tradicionais e ágeis, como utilizá-las ou até mesmo como combiná-las, é</p><p>necessário um entendimento do conceito sobre as metodologias de desenvolvimento de software. Neste estudo, vamos</p><p>apresentar e compreender o conceito de metodologia de desenvolvimento de software e as principais fases da metodologia</p><p>tradicional de desenvolvimento. O estudo das metodologias de desenvolvimento de software no campo da engenharia de software</p><p>é imprescindível para que as organizações atinjam uma melhor eficiência e qualidade dos seus sistemas de informações e,</p><p>consequentemente, dos resultados dos seus processos funcionais. Veremos que essas metodologias cadenciam os processos do</p><p>ciclo de vida de desenvolvimento, regendo os recursos, regras e padrões, direcionando os requisitos necessários para a</p><p>implementação e descomplicando, assim, a tarefa de produzir o software. Estamos em uma época em que desenvolver sistemas</p><p>não é mais sinônimo de complexidade e alto custo, pois as metodologias ágeis e suas combinações com as boas práticas de</p><p>gerenciamento de projetos, se bem utilizadas e compreendidas, promovem, em qualquer tipo de ambiente, uma elevação de</p><p>produtividade no desenvolvimento. Cada vez mais novas metodologias e suas combinações estão sendo estudas e melhoradas,</p><p>trazendo reais benefícios e melhorias às fábricas de software e às equipes de projetos de desenvolvimento de software.</p><p>Avançar</p><p>DOWNLOAD PDF</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/unidade-1</p><p>https://drive.google.com/file/d/1GnBbWAfGjOdxUVSoS86-YTtPtoQ_XKtP/view?usp=sharing</p><p>Página inicial</p><p>Conceitos de Metodologias de</p><p>Desenvolvimento De Software</p><p>Para Koscianski e Soares (2007, p. 190), “uma metodologia de desenvolvimento de software é um conjunto de atividades que</p><p>auxiliam na produção de software. O resultado dessas atividades é um produto que reflete a forma com que o processo foi</p><p>conduzido”. Contudo, um conjunto de atividade é denominado de processo. Sendo assim, uma metodologia de desenvolvimento de</p><p>software se utiliza de processos de produção de software. Engholm Jr. (2010, p. 42) comenta que processo é um conjunto</p><p>sequencial e peculiar de ações que objetivam atingir uma meta. É usado para criar, inventar, projetar, transformar, produzir,</p><p>controlar, manter e usar produtos ou sistemas.</p><p>Os processos estão vinculados às atividades e procedimentos dos funcionários ou colaboradores de uma empresa. Estes processos</p><p>são compostos de rotinas de trabalho, chamadas instruções de trabalho. Um sistema de folha de pagamento, planejamento de</p><p>controle e produção, estocagem, emissão de pedidos e demais funções, estão vinculadas aos processos organizacionais. Os</p><p>processos são compostos de ‘entrada’ de informações ou de matérias-primas; de ‘processamento’ de cálculos ou transformação</p><p>das informações ou das matérias-primas; ‘saída’ de informações, resultados ou de produtos acabados; de ‘recursos’ de pessoal ou</p><p>financeiro; e de ‘regras e padrões’ como políticas, instruções de trabalho, normas, regulamentações, etc., como mostra a Figura 1.</p><p>Figura 1 - Representação de um processo.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>Fonte: autor.</p><p>Podemos citar algumas características sobre o processo, enumeradas por Engholm Jr. (2010, p. 43):</p><p>é disparado/iniciado por evento externo; engloba todas as atividades necessárias para prover os resultados</p><p>apropriados em resposta ao evento que o iniciou; tem indicadores de desempenho para os quais os</p><p>objetivos mensuráveis podem ser estabelecidos, e o desempenho, avaliado, [...] etc.</p><p>Além disso, são compostos por atividades, e essas decompostas por rotinas ou procedimentos funcionais, chegando ao maior</p><p>detalhe possível da atividade, ou seja, como fazer o procedimento. As atividades também são regidas por normas, especificações</p><p>ou padrões determinados, que são executados por recursos tecnológicos ou humanos.</p><p>Sommerville (2011, p. 18-19) comenta que esse processo de produção de software pode acontecer de diferentes formas, seja para</p><p>novos softwares desenvolvidos a partir do zero ou para implementações, mas devem incluir quatro atividades, etapas ou fases</p><p>fundamentais para a engenharia de software: (1) especificação de software (definições das funcionalidades e funcionamento); (2)</p><p>projeto e implementação do software (produção, codificação); (3) validação do software (validação para garantir as demandas do</p><p>cliente) e (4) evolução do software.</p><p>Os processos de produção do software, também chamado de fases tradicionais de desenvolvimento do software, podem ser</p><p>definidos como (Figura 2):</p><p>Figura 2 – Fases tradicionais de desenvolvimento do ciclo de vida do software.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Fonte: Brookshear (2013, p. 267).</p><p>a. Análise e requisitos (especificação de software);</p><p>b. Projeto;</p><p>c. Implementação (projeto e implementação do software); e</p><p>d. Testes (validação do software e evolução).</p><p>Segundo Royce (1970 apud KOSCIANSKI e SOARES, 2007, p. 190), as metodologias tradicionais são também chamadas de</p><p>pesadas ou orientadas a documentação. Essas metodologias surgiram em um contexto de desenvolvimento de software muito</p><p>diferente do atual, baseado apenas em mainframes e terminais burros. Ainda segundo Koscianski e Soares (2007, p. 190), a</p><p>primeira metodologia publicada de desenvolvimento de software é a chamada de metodologia em cascata ou modelo clássico, que</p><p>estabelece uma sequência de etapas e a qual veremos mais adiante neste estudo dos princípios das metodologias de</p><p>desenvolvimento de software.</p><p>Fases Tradicionais de Desenvolvimento de Software</p><p>Como vimos no item anterior, o desenvolvimento do ciclo de vida do software (Fig. 2 e Fig.3) é composto de quatro fases (1) análise</p><p>e definição de requisitos ou especificações de software, etapa para o entendimento dos serviços requisitados do sistema; (2)</p><p>projeto e implementação, em que é realizada a conversão da especificação em um sistema executável, desde a modelagem</p><p>(projeto) até a codificação do software (implementação); (3) validação do software através de testes, com a intenção de apresentar</p><p>um software funcional e adequado às especificações do cliente; e podemos adicionar a fase (4) evolução do software, que se refere</p><p>às manutenções para a sobrevivência do software.</p><p>Figura 3 – Fases tradicionais de desenvolvimento de software.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Fonte: o autor.</p><p>Uma questão importante a ser refletida neste estudo seria: “por que utilizar uma metodologia de</p><p>desenvolvimento de software?”, além de: “é possível desenvolver um sistema sem metodologia?”. A primeira</p><p>questão é levantada por Sommerville (2011, p.2-3), que</p><p>da abordagem iterativa.</p><p>a) É uma abordagem que potencialmente combina os três modelos de processos genéricos: cascata, incremental e de reutilização.</p><p>b) Na fase de elaboração (comunicação e modelagem), a base da arquitetura não é um protótipo, pois não é descartável. Em alguns</p><p>casos, a elaboração gera uma base de arquitetura executável.</p><p>c) Um modelo de projeto é criado e documentado com modelos de arquitetura, modelos de componentes, modelos de objetos e</p><p>modelos de sequência.</p><p>d) Para definição dos requisitos, o protótipo é eficiente para o projeto de desenvolvimento de software; após a fase de</p><p>especificação, deve ser descartado.</p><p>3. Segundo Pressman (2016, p.47), o modelo espiral é um modelo de processo de software evolucionário que une a natureza</p><p>iterativa da prototipação e os aspectos sistemáticos e controlados do modelo cascata. De acordo com a afirmativa mencionada,</p><p>marque a alternativa incorreta.</p><p>a) O ciclo de vida de modelo espiral é atualmente uma abordagem mais realista para o desenvolvimento de softwares e sistema de</p><p>grande escala.</p><p>b) É uma abordagem “evolucionária”, capacitando a equipe de projeto e o cliente a entenderem e a reagirem aos riscos em cada</p><p>etapa evolutiva da espiral.</p><p>c) Está mais relacionada à identificação dos requisitos do software, pois é de sua característica ajudar na elicitação e validação de</p><p>requisitos de sistema. Outros autores denominam também este modelo de espiral rápida, e de cunho operacional.</p><p>d) Cada volta da espiral é dividida em quatro setores: definição de objetivos (alternativas e restrições), avaliação e redução de</p><p>riscos (identificação e resolução de riscos – AR – análise de riscos), desenvolvimento e avaliação e planejamento (planejar</p><p>próximas fases do ciclo).</p><p>Resolução das atividades</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/atividades</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/resumo</p><p>Página inicial</p><p>RESUMO</p><p>Neste estudo compreendemos os diversos paradigmas clássicos de desenvolvimento de software, como o modelo Cascata,</p><p>Sequencial ou Clássico, modelo Incremental ou Iteração, modelo Prototipação, modelo Espiral ou Boehm e o modelo RUP. No</p><p>método Cascata, vimos que é considerada uma sequência de atividades inerentes ao processo de desenvolvimento de software,</p><p>como comunicação, planejamento, modelagem, construção e entrega, sendo que se deve finalizar cada fase antes de passar para a</p><p>próxima. Na realidade esse modelo não condiz mais com a realidade dos desenvolvimentos de software, pois na atualidade as</p><p>mudanças ocorrem de maneira quase interminável. No modelo Incremental, no qual as entregas são incrementais em iterações,</p><p>cada iteração é constituída das etapas do modelo sequencial. Este modelo clássico é utilizado como precursor do paradigma de</p><p>desenvolvimento ágil XP, que também realiza entregas incrementais das versões ao cliente. Outro modelo clássico que aparece em</p><p>várias metodologias tradicionais e ágeis é a prototipação. É um modelo usado quando os requisitos estão obscuros e auxilia os</p><p>envolvidos a compreender melhor o que está sendo construído. Um dos problemas da prototipação é o cliente não diferenciar o</p><p>protótipo de um software final. Neste caso, a equipe pode ceder o tempo de entrega. Outro modelo clássico é o Espiral ou modelo</p><p>Boehm, que vem preencher uma lacuna nas metodologias anteriores, pois aborda a análise de riscos. Esse modelo é constituído de</p><p>4 etapas: planejamento (objetivos), análise de riscos (identificação e resolução de riscos), engenharia (desenvolvimento do</p><p>produto, codificação) e a avaliação do cliente (avaliação dos resultados). Além disso, ele preza pela verificação de riscos e validação</p><p>dos requisitos, e é possível realizar o retorno às fases anteriores, devido ao seu formato espiral. O paradigma Espiral não admite</p><p>construção paralela para integração posterior, mas é um dos modelos mais realistas para a produção de software em grande escala.</p><p>Por último, compreendemos em nosso estudo o modelo RUP (Processo Unificado Racional), que é um processo de</p><p>desenvolvimento de software híbrido e aproveita os melhores recursos e características dos modelos tradicionais de processo de</p><p>software, como prototipação e incremental. Vimos que esse modelo trabalha com as perspectivas estáticas, dinâmicas e prática. A</p><p>perspectiva estática trabalha com as atividades, papéis, artefatos trabalhados e os procedimentos que devem ser executados. Na</p><p>perspectiva prática a metodologia trabalha com as boas práticas de engenharia de software. A perspectiva dinâmica do RUP está</p><p>relacionada às fases de concepção, elaboração, construção e transição do projeto de desenvolvimento de software.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/resumo</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/eu-indico</p><p>Página inicial</p><p>Material Complementar</p><p>Leitura</p><p>Engenharia de Software</p><p>Autor: Ian Sommerville</p><p>Editora: Pearson</p><p>Sinopse : no intuito de atender às necessidades de alunos e professores</p><p>dos cursos de ciência da computação, engenharia de computação e</p><p>sistema de informação, esta nona edição de Engenharia de Software teve</p><p>seu conteúdo reestruturado e atualizado. A obra conta com capítulos que</p><p>focalizam o desenvolvimento ágil de software e os sistemas embarcados,</p><p>além de trazer novas abordagens sobre engenharia dirigida a modelos,</p><p>desenvolvimento open source, modelo Swiss Cheese de Reason,</p><p>arquiteturas de sistemas confiáveis, reúso de COTS e planejamento ágil.</p><p>Comentário: umas das referências mais importantes na área de</p><p>engenharia de software, e bem explorado em nosso estudo de</p><p>metodologias de desenvolvimento de software, Sommerville explica as</p><p>diversas metodológicas clássicas e ágeis, bem como uma tendência na</p><p>utilização de métodos híbridos e atualização para o desenvolvimento de</p><p>software na atualidade.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/eu-indico</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/refer%C3%AAncias</p><p>Página inicial</p><p>REFERÊNCIAS</p><p>AUDY, J.; PRIKLANDNICKI, R. Desenvolvimento distribuído de software : desenvolvimento de software com equipes distribuídas.</p><p>Rio de Janeiro: Elsevier, 2008.</p><p>BROOKSHEAR, J. G. Ciência da computação : uma visão abrangente. 11. ed. Porto Alegre: Bookman, 2013.</p><p>ENGHOLM, H. Análise e design orientados a objetos . São Paulo: Novatec Editora, 2013.</p><p>HIRAMA, K. Engenharia de software : qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2012.</p><p>HORSTMANN, C. Conceitos de computação Java . 5. ed. São Paulo: Bookman Editora, 2009.</p><p>KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software : aprenda as metodologias e técnicas mais modernas para o</p><p>desenvolvimento de software. São Paulo: Novatec Editora, 2007.</p><p>MARTINS, J. C. C. Gerenciamento de desenvolvimento de software com PMI, RUP e UML . 5. ed. Rio de Janeiro: Brasport, 2010.</p><p>NEVES, M. CBAP Master : aprenda análise de negócios e conquiste a certificação CCBA/CBAP. Rio de Janeiro: Brasport, 2014.</p><p>PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software : uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.</p><p>SCHACH, S. R. Engenharia de software : os paradigmas clássico & orientado a objetos. 7. ed. Porto Alegre. AMGH, 2010.</p><p>SCHIRIGATTI, J. L. Introdução a gestão de projetos de banco de dados : Unidade I. Maringá. Pós-graduação em Banco</p><p>de Dados.</p><p>Maringá: Unicesumar, 2017.</p><p>SOMMERVILLE, I. Engenharia de Software . São Paulo: Pearson Prentice Hall, 2011.</p><p>REFERÊNCIAS ON-LINE</p><p>¹ Em: < https://www.google.com/url?</p><p>sa=D&q=https://scholar.google.com/scholar_url%3Furl%3Dhttp://sites.google.com/site/20121engsoft/&ust=161091366000000</p><p>0&usg=AOvVaw0ks4b3Cr6BzySUhRWy3ZZT&hl=pt-BR >. Acesso em: 01 out. 2017.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/refer�ncias</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://www.google.com/url?sa=D&q=https://scholar.google.com/scholar_url%3Furl%3Dhttp://sites.google.com/site/20121engsoft/&ust=1610913660000000&usg=AOvVaw0ks4b3Cr6BzySUhRWy3ZZT&hl=pt-BR</p><p>https://www.google.com/url?sa=D&q=https://scholar.google.com/scholar_url%3Furl%3Dhttp://sites.google.com/site/20121engsoft/&ust=1610913660000000&usg=AOvVaw0ks4b3Cr6BzySUhRWy3ZZT&hl=pt-BR</p><p>https://www.google.com/url?sa=D&q=https://scholar.google.com/scholar_url%3Furl%3Dhttp://sites.google.com/site/20121engsoft/&ust=1610913660000000&usg=AOvVaw0ks4b3Cr6BzySUhRWy3ZZT&hl=pt-BR</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/aprofundando</p><p>Página inicial</p><p>APROFUNDANDO</p><p>Além de compreendermos as metodologias clássicas de desenvolvimento de software em nosso estudo, é importante nos</p><p>aprofundarmos sobre as metodologias clássicas de gerenciamento de projetos de desenvolvimento de software. Uma das</p><p>referências clássicas de grande difusão internacional é o guia de boas práticas de gerenciamento de projetos, denominado PMBOK</p><p>(Project Management Bodies of knowledge), do PMI (Project Management Institute) – Instituto de gerenciamento de projeto.</p><p>Segundo Martins (2010), o PMI especificou um conjunto de procedimentos que visam padronizar a teoria associada à gerência de</p><p>projetos registrada no documento chamado PMBOK; trata-se de uma bibliografia de referências, cujo propósito é identificar e</p><p>descrever conceitos e práticas de gerenciamento.</p><p>Atualmente as organizações estão preocupadas com as execuções de suas atividades rotineiras e com os seus projetos de</p><p>sistemas, negócios, infraestrutura, linhas de produção e softwares. Ou seja, o PMBOK é utilizado para qualquer tipo de projeto, e</p><p>para o desenvolvimento de software.</p><p>O Quadro 1 apresenta as fases de gerenciamento de projetos, suas divisões dentro de cada fase e artefatos utilizados</p><p>(documentações).</p><p>Quadro 1 - Ciclo de vida do projeto, suas divisões e artefatos utilizados</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>Fonte: o autor.</p><p>Os processos de gerenciamento (iniciação, execução, monitoramento e controle e encerramento) são organizados e agrupados em</p><p>9 áreas do conhecimento, segundo o PMI:</p><p>1. Integração do gerenciamento do projeto.</p><p>2. Gerenciamento de escopo do projeto.</p><p>3. Gerenciamento do tempo de projeto.</p><p>4. Gerenciamento dos custos de projeto.</p><p>5. Gerenciamento da qualidade do projeto.</p><p>6. Gerenciamento dos recursos humanos do projeto.</p><p>7. Gerenciamento das comunicações do projeto.</p><p>8. Gerenciamento dos riscos do projeto.</p><p>9. Gerenciamento das aquisições do projeto.</p><p>Na Figura 1 é possível visualizar o gráfico do ciclo de vida do projeto com as fases (1) Conceitual; (2) planejamento/preparação/</p><p>organização; (3) execução e (4) encerramento. O gráfico também mostra, no ciclo de vida do projeto, o alto risco nas fases iniciais</p><p>do projeto e do planejamento e alta utilização de recursos na etapa de execução.</p><p>Figura 1 – Ciclo de vida do projeto</p><p>Fonte: o autor.</p><p>REFERÊNCIAS</p><p>MARTINS, J. C. C. Gerenciamento de Projetos de desenvolvimento de Software com PMI, RUP e UML. Rio de Janeiro: Brasport.</p><p>2010.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>PARABÉNS!</p><p>Você aprofundou ainda mais seus estudos!</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/editorial</p><p>Página inicial</p><p>EDITORIAL</p><p>DIREÇÃO UNICESUMAR</p><p>Reitor Wilson de Matos Silva</p><p>Vice-Reitor Wilson de Matos Silva Filho</p><p>Pró-Reitor de Administração Wilson de Matos Silva Filho</p><p>Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva</p><p>Presidente da Mantenedora Cláudio Ferdinandi</p><p>C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância;</p><p>SCHIRIGATTI , Jackson Luis.</p><p>Metodologia Tradicional x Ágil. Jackson Luis Schirigatti.</p><p>Maringá-Pr.: UniCesumar, 2017.</p><p>33 p.</p><p>“Pós-graduação Universo - EaD”.</p><p>1. Metodologia. 2. Software 3. EaD. I. Título.</p><p>CDD - 22 ed. 006</p><p>CIP - NBR 12899 - AACR/2</p><p>Pró Reitoria de Ensino EAD Unicesumar</p><p>Diretoria de Design Educacional</p><p>Equipe Produção de Materiais</p><p>Fotos : Shutterstock</p><p>NEAD - Núcleo de Educação a Distância</p><p>Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900</p><p>Maringá - Paraná | unicesumar.edu.br | 0800 600 6360</p><p>Retornar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/editorial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>Página inicial</p><p>METODOLOGIAS</p><p>ÁGEIS</p><p>Professor :</p><p>Me. Jackson Luis Schirigatti</p><p>Objetivos de aprendizagem</p><p>• Apresentar a história de surgimento do manifesto ágil, bem como os seus princípios e valores.</p><p>• Compreender o que á metodologia ágil e caracterizá-la.</p><p>• Apresentar e compreender o processo de desenvolvimento de Programação Extrema (XP).</p><p>• Apresentar e compreender a metodologia de gerenciamento de projetos de software Scrum.</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>Plano de estudo</p><p>A seguir, apresentam-se os tópicos que você estudará nesta unidade:</p><p>• Histórico de Surgimento do Manifesto Ágil.</p><p>• O que é a Metodologia Ágil?</p><p>• Programação Extrema (XP).</p><p>• Scrum (Gerenciamento Ágil De Projetos De Software).</p><p>Introdução</p><p>Neste estudo, vamos compreender os conceitos das metodologias de desenvolvimento de software ágeis. Começaremos essa</p><p>compreensão na primeira aula, com a história do surgimento do manifesto ágil, seus fundamentos e seus princípios declarados</p><p>para uma necessidade de entregas rápidas a um menor custo de software. Entenderemos o que é uma metodologia ágil e suas</p><p>principais características. Para compreender melhor como funcionam estes princípios, estudaremos alguns tipos de metodologias</p><p>de desenvolvimento ágil, como a metodologia XP – Extreme Programming (programação extrema), na qual se aplica uma</p><p>metodologia em desenvolvimento de software com poucos artefatos, reduzindo consideravelmente a fase de projeto, com</p><p>entregas rápidas das versões implementadas (estórias implementadas e testadas), e essas aprovadas pelo cliente. Veremos</p><p>também a metodologia Scrum, utilizada para o gerenciamento ágil de projetos, sendo possível a sua combinação com outras</p><p>metodologias de desenvolvimento ágil de software, como a XP. Serão abordadas as principais características da metodologia</p><p>Scrum e a importância sobre a combinação da metodologia de desenvolvimento de software XP com a metodologia de</p><p>gerenciamento de projeto de software Scrum, uma combinação que pode gerar um resultado poderoso em projetos de software.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/unidade-3</p><p>Página inicial</p><p>História De Surgimento do Manifesto</p><p>Ágil</p><p>A Engenharia de software, nascida na segunda metade do sec. XX através das teorias e dos métodos de produção (Fordismo e</p><p>Taylorismo) (PRIKLANDNICKI; MILLANI, 2014, p. 16), e as metodologias de desenvolvimento de software tiveram inspiração em</p><p>processos de manufatura para a consolidação de seus métodos de trabalho.</p><p>Na década de 1980 e inicio de 1990, havia uma visão generalizada de que a melhor maneira para conseguir</p><p>o melhor software era por meio de um planejamento cuidadoso do projeto, qualidade da segurança</p><p>formalizada, do uso de métodos de análise e projeto apoiado por ferramentas CASE (Computer-aided-</p><p>software engineering) e do processo de desenvolvimento de software rigoroso e controlado</p><p>(SOMMERVILLE, 2011, p. 39).</p><p>Essa percepção era aplicada para o desenvolvimento de sistemas corporativos de grande porte, como do governo, sistemas</p><p>aeroespaciais e de grandes empresas, através de uma abordagem pesada e de desenvolvimento dirigida a planos, com grandes</p><p>equipes, dispersas geograficamente e de longos períodos de desenvolvimento. Hoje, as empresas trabalham em ambientes de</p><p>mudanças rápidas, globais, interativas, inovadoras e de valorização aos funcionários e colaboradores, ou seja, operam através de</p><p>um pensamento ágil . Em meados dos anos 90, novos processos de desenvolvimento de software estavam surgindo, chamados de</p><p>processos leves, em respostas às tradicionais metodologias, lentas e burocráticas. Para Priklandnicki, Willi e Millani (2014, p.16),</p><p>diversos profissionais reportam que o pensamento ágil já era adotado no desenvolvimento de software no Brasil, bem antes da</p><p>formalização do Manifesto Ágil. Por volta de 1999, Klaus Wuestefeld e Vinícius Teles, profissionais de desenvolvimento de</p><p>software, precursores no país, estavam em busca de uma abordagem alternativa que propiciasse aumento de chances de sucesso</p><p>no desenvolvimento de software (PRIKLANDNICKI et al., 2014, p. 16). O movimento no Brasil teve inicio em 2000 por professores</p><p>e profissionais que tiveram contato com o movimento internacional. Segundo Cruz (2015, p.12), o manifesto para o</p><p>desenvolvimento ágil de software, ou simplesmente o manifesto ágil, foi criado de forma colaborativa pelos 17 profissionais</p><p>representantes de métodos de desenvolvimento que estavam presentes no encontro de 2001 em Utah, oeste dos Estados Unidos.</p><p>Pham e Pham (2014, p. 39) apresentam os fundamentos do manifesto ágil declarados, que justificam a sua criação:</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo.</p><p>Ao longo desse trabalho começamos a valorizar:</p><p>• Indivíduos e interações em vez de processos e ferramentas.</p><p>• Software funcional em vez de documentação excessiva.</p><p>• Colaboração com os clientes em vez de negociação de contrato.</p><p>• Respostas à mudança em vez de seguimento de um plano. [...]</p><p>Valores do Manifesto Ágil</p><p>Veremos quais são os valores apresentados na declaração do manifesto ágil com relação aos fundamentos ou princípios: (a)</p><p>indivíduos e interações, (b) envolvimento do cliente (funcionamento e colaboração com o cliente), (c) entrega incremental, (d)</p><p>aceitação das mudanças e (e) manter a simplicidade.</p><p>a. Indivíduos e interações (mais que processos e ferramentas): as habilidades da equipe de desenvolvimento devem ser</p><p>reconhecidas e exploradas. Membros da equipe devem desenvolver suas próprias maneiras de trabalhar, sem processos</p><p>prescritivos (SOMMERVILLE, 2011, p. 40). Ferramentas e processos são importantes, mas a comunicação e a valorização das</p><p>pessoas é extremamente importante.</p><p>b. Colaboração com o cliente (mais que negociação de contratos): para o manifesto ágil, o escopo não pode ser uma questão</p><p>contratual, deve ser mais do que uma negociação contratual, pois o escopo fica definido através de cláusulas do contrato,</p><p>protegendo contratante e contratado, o que leva o insucesso dos projetos. Para Priklandnicki et al. (2014, p.6), esse é um ponto</p><p>fraco do manifesto e dos métodos ágeis, constantemente criticados à sua fragilidade e pessoalidade. Contudo, Sommerville (2011,</p><p>p. 40) comenta que é necessário que os clientes estejam intimamente envolvidos no processo de desenvolvimento. Seu papel é</p><p>fornecer e priorizar novos requisitos do sistema e avaliar suas iterações.</p><p>c. Entrega Incremental: o software é desenvolvido em incrementos com o cliente, especificando os requisitos para serem incluídos</p><p>em cada um (SOMMERVILLE, 2011, p. 40). Larman (2002, p.57) comenta que esse princípio é satisfazer o cliente por meio da</p><p>entrega pronta e contínua de software de valor.</p><p>d. Aceitação das mudanças: deve-se ter em mente que os requisitos do sistema vão mudar. Por isso, projete o sistema de maneira a</p><p>acomodar essas mudanças (SOMMERVILLE, 2011, p. 40). Larman (2002, p.57) comenta que se deve acolher modificação de</p><p>requisitos, mesmo no final do desenvolvimento. Processos ágeis valorizam a modificação para vantagem competitiva do cliente.</p><p>e. Manter a simplicidade: o foco é a simplicidade, tanto do software a ser desenvolvido quanto do processo de desenvolvimento.</p><p>Sempre que possível, deve-se trabalhar ativamente para eliminar a complexidade do sistema (SOMMERVILLE, 2011, p. 40).</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>O que é a Metodologia Ágil?</p><p>A metodologia ágil de software é a realização de atividades de levantamento de requisitos, planejamento, projeto, implementação</p><p>e testes, de fabricação rápida, através de uma série de incrementos de funcionalidades, interações de curtos espaços de tempo e</p><p>de entregas aprovadas pelo cliente. Para Sommerville (2011, p.39) os processos de desenvolvimento rápido de software são</p><p>concebidos para produzir, rapidamente, softwares úteis.</p><p>O software não é desenvolvido como uma única unidade, mas como uma série de incrementos – cada incremento inclui uma nova</p><p>funcionalidade do sistema. Para Lobo (2008, p.42) os métodos ágeis de desenvolvimento de software utilizam uma sistematização</p><p>mais rápida e objetiva para se obter um software. O ponto de equilíbrio entre não utilizar metodologias sistematizadas e utilizar</p><p>metodologias pesadas é o desenvolvimento do método ágil, pois, ainda segundo Lobo (2008, p.42), a maioria desses métodos</p><p>possui uma característica em comum: iterações em curtos períodos de tempo.</p><p>As iterações nos métodos ágeis normalmente são períodos pequenos (uma semana, por exemplo), permitindo assim a diminuição</p><p>dos riscos do projeto. Como visto sobre os princípios no item anterior, Pressman (2016, p. 84) comenta que uma filosofia ágil para</p><p>a engenharia de software enfatiza quatro elementos-chave: a importância das equipes que se auto-organizam, que têm controle</p><p>sobre o trabalho por elas realizado, a comunicação e a colaboração entre os membros da equipe e entre os desenvolvedores e seus</p><p>clientes. Outras características importantes dos processos do desenvolvimento ágil podem ser destacadas, tais como o</p><p>versionamento, para o controle de versões devido às muitas alterações realizadas durante o desenvolvimento; a priorização dos</p><p>projetos, em que funcionalidades urgentes são priorizadas; e a aplicação de documentação leve, deixando o processo dinâmico. No</p><p>item 2.1 é apresentado um quadro-resumo dessas características e o porquê delas.</p><p>Características do Processo de Desenvolvimento Ágil</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>O processo ágil de desenvolvimento de software se caracteriza pela velocidade de fabricação de um software útil, reduzindo a</p><p>burocracia através de poucos artefatos (documentos) e através de iterações de execução de atividades</p><p>inicia assim que alguns</p><p>requisitos estiverem disponíveis e, após, começam as atividades de design e codificação, trabalhando com pequenas partes de cada</p><p>vez, sendo essas testadas, aprovadas e entregues ao cliente. Contudo, Pressman (2016, p. 78) comenta que Scrum é uma</p><p>metodologia de desenvolvimento de software ágil concebido por Jeff Sutherland e sua equipe de desenvolvimento no inicio dos</p><p>anos 1990. A abordagem Scrum é um método ágil geral, mas seu foco está no gerenciamento do desenvolvimento iterativo, em vez</p><p>de em abordagens técnicas específicas da engenharia de software ágil. Pode ser usado com abordagens ágeis e com a XP, para</p><p>fornecer um framework (estrutura conceitual) de gerenciamento de projetos (SOMMERVILLE, 2011, p. 50). A Figura 6 mostra o</p><p>fluxo do processo Scrum.</p><p>Figura 6 – Processo Scrum.</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>Fonte: Pressman (2016, p. 78).</p><p>No Scrum existem três fases. A primeira é uma fase de planejamento geral, em que se estabelecem os objetivos gerais do projeto e</p><p>da arquitetura do software. Em seguida, ocorre uma série de ciclos de sprint , e cada ciclo desenvolve um incremento do sistema</p><p>(SOMMERVILLE, 2011, p. 50). Finalmente, a fase de encerramento do projeto, com finalizações das documentações e lições</p><p>aprendidas, equivalente à etapa de encerramento de projeto do PMI (Project Management Institute). Para Pressman (2016, p.79),</p><p>os sprints , consistem em unidades de trabalho solicitadas para atingir um requisito estabelecido no registro de trabalho ( backlog ) e</p><p>que precisa ser ajustado dentro de um prazo já fechado (janela de tempo, tipicamente 30 dias), como na Figura 5. Os ciclos sprint</p><p>são a novidade do método Scrum. Para Sommerville (2011, p.50), o sprint é uma unidade de planejamento na qual o trabalho a ser</p><p>feito é avaliado, os recursos para o desenvolvimento são selecionados e o software é implementado. No final de um sprint , a</p><p>funcionalidade completa é entregue.</p><p>A Figura 7 mostra o processo Scrum esquematizado adaptado de Sommerville (2011, p. 50), em que o processo inicial é backlog do</p><p>produto, que é a lista de trabalho a ser feito no projeto o backlog do sprint (funcionalidades atribuídas ao sprint). Na sequência são</p><p>aplicadas as fases de (1) avaliação, que revisa todas as funcionalidades atribuídas, identificando as prioridades e riscos; (2) seleção,</p><p>na qual são selecionados os recursos e funcionalidades pela equipe e cliente; e (3) após aprovações (acordos), a equipe inicia o</p><p>desenvolvimento do software e com reuniões diárias de 15 minutos, que são geradas para analisar o progresso do</p><p>desenvolvimento, dificuldades, tarefas realizadas e repriorização do trabalho:</p><p>Figura 6 – O processo Scrum iniciando com o Backlog, após o ciclo sprint e encerramento.</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>Fonte: Adaptado de Sommerville (2011, p. 50).</p><p>Segundo Martins (2007, p. 269),</p><p>Scrum é um processo bastante leve para gerenciar e controlar projetos de desenvolvimento de software e</p><p>para a criação de produtos. Scrum é uma metodologia ágil que segue as filosofias interativa e incremental.</p><p>Ela se concentra no que é realmente importante: gerenciar o projeto e criar um produto que acrescente</p><p>valor para o negócio. O valor decorre da funcionalidade propriamente dita, do prazo em que ela é</p><p>necessária, do custo e da qualidade</p><p>Características do Scrum</p><p>Orth e Priklandnicki (2009, p.152) comentam que o Scrum adota uma abordagem empírica, aceitando que o problema pode não</p><p>ser totalmente entendido ou definido na análise e que provavelmente os requisitos mudarão com o passar do tempo, focando na</p><p>maximização da habilidade da equipe de responder de forma ágil aos desafios. Algumas características da metodologia Scrum são</p><p>elencadas no Quadro 3, adaptada de Sabbagh (2014) e Martins (2007). Na coluna da direita, os questionamentos do porquê das</p><p>características são respondidas.</p><p>Quadro 3 – Características do Scrum.</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>Fonte: Adaptado de Sabbagh (2014) e Martins (2007).</p><p>Scrum com XP</p><p>Para Pires (2016, p. 21) o processo Scrum é um método ágil similar ao XP, “como equipes pequenas,</p><p>requisitos pouco estáveis e iterações curtas para promover visibilidade para o desenvolvimento. No entanto</p><p>as dimensões em Scrum diferem de XP” (SOARES, 2016, p. 5), porém com foco maior em gerência. O</p><p>Processo de gestão descrito pelo Scrum é bastante simples, bem como suas práticas, artefatos e regras.</p><p>Segundo Massari (2016, p. 241), “o Extreme Programming (XP) é uma metodologia ágil de desenvolvimento</p><p>de software que, quando utilizada com o Scrum, pode gerar um resultado poderosíssimo em projetos de</p><p>software”. As aderências da metodologia de desenvolvimento de software XP com a metodologia de</p><p>gerenciamento de projetos de software Scrum geram assim um modelo híbrido ágil. Como o Scrum é um</p><p>Framework, ele funciona muito bem na combinação ou complemento por diferentes métodos e práticas</p><p>consagrados pelo mercado. Uma aderência forte desta combinação é que as práticas de Scrum são</p><p>utilizadas para gerenciar várias equipes que usam XP.</p><p>Portanto, como sugestão para melhorar a eficiência e eficácia nos projetos de desenvolvimento de</p><p>software, é a combinação das metodologias. Dependendo da abordagem do projeto, cultura organizacional,</p><p>tamanho da equipe, requisitos do produto e do projeto, etc., é possível a aplicação das vantagens de cada</p><p>uma das metodologias.</p><p>Fonte: Pires (2016, p. 21); Soares (2016, p. 5) e Massari (2016, p. 241).</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/unidade-3</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/atividades</p><p>Página inicial</p><p>ATIVIDADES</p><p>1. “Na década de 1980 e inicio de 1990, havia uma visão generalizada de que a melhor maneira para conseguir o melhor software</p><p>era por meio de um planejamento cuidadoso do projeto, qualidade da segurança formalizada, do uso de métodos de análise e</p><p>projeto apoiado por ferramentas CASE (Computer-aided-software engineering) e do processo de desenvolvimento de software</p><p>rigoroso e controlado.” (SOMMERVILLE, 2011, p. 39). De acordo com recorte do texto apresentado pelo estudo sobre a</p><p>utilização da metodologia clássica na década de 80, marque a alternativa correta:</p><p>a) Já não se produz softwares com a metodologia clássica, todos são produzidos através de métodos ágeis tanto de gerenciamento</p><p>e de desenvolvimento.</p><p>b) A produção atual de software continua como da década de 80, mas algumas produções de software com métodos ágeis.</p><p>c) A produção atual de software é equilibrada, com grande tendência do uso de metodologias ágeis, mas ainda muitas organizações</p><p>utilizam a metodologia tradicional ou combinações de metodologias ágeis e tradicionais, devido ao desenvolvimento de sistemas</p><p>críticos e de alto risco.</p><p>d) A produção de software atualmente é totalmente através de métodos combinados, pois os métodos da década de 80 são</p><p>arcaicos.</p><p>2. Pressman (2016, p. 78) comenta que Scrum é uma metodologia de desenvolvimento de software ágil concebido por Jeff</p><p>Sutherland e sua equipe de desenvolvimento no inicio dos anos 1990. A abordagem Scrum é um método ágil geral, mas seu foco</p><p>está no gerenciamento do desenvolvimento iterativo, em vez de em abordagens técnicas específicas da engenharia de software</p><p>ágil. Pode ser usado com abordagens ágeis e com a XP, para fornecer um framework (estrutura conceitual) de gerenciamento de</p><p>projetos (SOMMERVILLE, 2011, p. 50). De acordo com o comentário de Sommerville, marque a alternativa que não corresponde</p><p>a característica da abordagem Scrum:</p><p>a) É um framework e não um método, ou seja, fornece uma estrutura de trabalho, mas não é uma sequência de trabalho.</p><p>b) Trabalha com característica</p><p>para prototipação, ou seja, o trabalho é voltado para um produto demonstrável com frequência.</p><p>c) Opera para contextos caóticos. O Scrum opera com objetivos não definidos e instáveis.</p><p>d) É iterativo e incremental, ou seja, o produto é desenvolvido em ciclos ou iterações sucessivas. Em cada um desses ciclos é gerado</p><p>um incremento no produto, que se soma e modifica o que já está pronto do produto até o momento (sprints).</p><p>3. Segundo Luna (2011, p.179), o cartão de usuários deve ser escrito com a linguagem de negócio, de forma clara e precisa, para</p><p>que seja compreendido por todos. Essa atividade de planejamento inicia-se em ouvir – uma atividade de levantamento de</p><p>requisitos que capacita os membros técnicos da equipe a entender o ambiente de negócios do software e permite obter uma</p><p>percepção sobre os resultados solicitados e a funcionalidade. Depois de recebidos e desenvolvidos, a equipe de desenvolvimento</p><p>divide-os em tarefas (cartões de tarefas). Estima-se o esforço e os recursos necessários para a realização da tarefa. Esta tarefa</p><p>envolve a discussão e o envolvimento do cliente, atribuindo valor de negócio e priorizando-as. Com relação as atividades</p><p>comentadas por Luna, marque qual é o método de desenvolvimento ou de gerenciamento de software a que se refere:</p><p>a) Scrum.</p><p>b) Scrum + XP.</p><p>c) XP.</p><p>d) Uma metodologia clássica.</p><p>Resolução das atividades</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/atividades</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/resumo</p><p>Página inicial</p><p>RESUMO</p><p>Neste estudo apresentamos a história do manifesto ágil, surgida em uma época de tendências de pensamento ágil , de</p><p>necessidades de mudanças rápidas, globais, interativas, inovadoras e de valorização aos funcionários e colaboradores. O manifesto</p><p>ágil configurou fundamentos e princípios, como o reconhecimento das habilidades da equipe de desenvolvimento, a comunicação e</p><p>a valorização das pessoas, mais do que ferramentas e processos; a questão do escopo do projeto não se torna mais uma questão</p><p>contratual, configura-se a pessoalidade, no lugar do formal; as entregas das funcionalidades para o cliente são de modo</p><p>incremental, criando uma satisfação para o cliente; há uma geração de vantagem competitiva através do conceito de mudança ao</p><p>longo das atividades de desenvolvimento. Também foram compreendidos e apresentados os conceitos e as características das</p><p>metodologias ágeis, destacando suas atividades de levantamento de requisitos, planejamento, projeto, implementação e testes. As</p><p>características apresentadas que merecem destaque: uma metodologia leve, redução do risco do projeto, iterações curtas,</p><p>implementações de versões do software, visão por prioridades de atividades e funcionalidades e também gera uma documentação</p><p>leve e eficiente. No estudo, foram compreendidas duas metodologias principais, a XP da extrema programação, como a</p><p>metodologia de desenvolvimento de software mais utilizada, e a metodologia Scrum, utilizada para o gerenciamento de</p><p>desenvolvimento de software. Com relação ao XP destacam-se as etapas rápidas, o alto grau de comunicação, a orientação ao</p><p>objeto e o fato de ser composto de quatro atividades: planejamento, projeto, codificação e testes. Além disso, é um processo de</p><p>desenvolvimento de software voltado para projetos cujos requisitos são vagos e mudam com frequência. Com relação ao Scrum,</p><p>de abordagem iterativa, usada para um gerenciamento e controle rápido de projetos de ideologia leve, agrega valor ao negócio,</p><p>aumenta a qualidade, a comunicação entre a equipe devido ao sprint (avaliar, selecionar, desenvolver e revisar) e também pode e</p><p>deve ser utilizado com uma metodologia de desenvolvimento de software com a própria XP</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/resumo</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/eu-indico</p><p>Página inicial</p><p>Material Complementar</p><p>Leitura</p><p>Agile Scrum Master no Gerenciamento Avançado de Projetos</p><p>Autor: Vitor L. Massari</p><p>Editora: Brasport</p><p>Sinopse : muitos livros comentam sobre o framework Scrum e a filosofia</p><p>Agile, mas poucos entram mais a fundo em questões sobre como</p><p>implementá-los em ambientes que já possuem outra metodologia – ou</p><p>mesmo nenhuma metodologia –, quais os cuidados que devemos ter</p><p>nessa implementação, que resistências enfrentaremos, que técnicas de</p><p>motivação e engajamento podemos usar, como fazer uma transição de</p><p>papéis como gerente de projetos, líder técnico e analista de negócios para</p><p>os papéis do Scrum, como a área de PMO se encaixa dentro de uma</p><p>organização Scrum/Agile, como combinar modelos de tal forma a criar um</p><p>modelo híbrido e como criar uma gestão de serviços de TI ágil.</p><p>Todos esses assuntos são abordados neste livro para ajudar você, que já</p><p>está iniciado nos fundamentos do Scrum/Agile, em sua jornada para</p><p>explorar o melhor deste framework e consequentemente atingir ótimos</p><p>resultados em seus projetos</p><p>Na Web</p><p>Apresentação: um estudo adicional e para leitura é a dissertação de</p><p>mestrado da autora Priscila Bastos Fagundes da UFSC, que desenvolve</p><p>um framework para comparação e análise de métodos ágeis. Também</p><p>discutido no “aprofundando” em nosso estudo dos métodos XP, Scrum,</p><p>FDD e DSDM.</p><p>Acesse</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/eu-indico</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://www.google.com/url?q=https%3A%2F%2Frepositorio.ufsc.br%2Fbitstream%2Fhandle%2F123456789%2F101860%2F220977.%2520pdf%3Fsequence%3D1%26isAllowed%3Dy&sa=D&sntz=1&usg=AFQjCNHROt09xd1OpJDp8Tx5A_-3jZtqcQ</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/refer%C3%AAncias</p><p>Página inicial</p><p>REFERÊNCIAS</p><p>CRUZ, F. Scrum e agile em projetos : Guia Completo. Rio de Janeiro: Brasport, 2015.</p><p>FEATHERS, M. C. Trabalho eficaz com código legado . Porto Alegre: Bookman Editora, 2013.</p><p>HIRAMA, K. Engenharia de software : qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2012.</p><p>LERMAN, C. Utilizando UML e padrões : uma introdução a análise e ao projeto orientados a objetos e ao desenvolvimento</p><p>interativo. 3. ed. São Paulo: Bookman Editora, 2002.</p><p>LOBO, E. J. R. Curso de engenharia de software . São Paulo: Digerati Books, 2008.</p><p>MARITNS, J. C. C. Técnicas para gerenciamento de projetos de software . Rio de Janeiro: Brasport, 2007.</p><p>MASSARI, V. Agile Scrum Master no gerenciamento avançado de projetos . Rio de Janeiro: Brasport, 2016.</p><p>PIRES, W. S. Gerenciamento de projetos utilizando métodos ágeis : teoria e prática. 1. ed. Belo Horizonte: Clube de Autores, 2016.</p><p>PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software : uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.</p><p>PHAM, A.; PHAM, P-V. Scrum em ação : gerenciamento e desenvolvimento ágil de projetos de software. São Paulo: Novatec, 2011.</p><p>ORTH, A. I. ; PRIKLANDNICKI, R. Planejamento e gerência de projetos . Porto Alegre: EDIPUCRS, 2009.</p><p>PRIKLANDNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software . Porto Alegre: Bookman, 2014.</p><p>SABBAGH, R. SCRUM : gestão ágil para projetos de sucesso. São Paulo. Editora Casa do Código. 2014.</p><p>SOARES, M. dos S.; Metodologias ágeis extreme programming e scrum para desenvolvimento de software. Revista Eletrônica de</p><p>Sistemas de Informação . v.15. n.3. set./dez. 2016.</p><p>SOMMERVILLE, I. Engenharia de Software . 9. ed. São Paulo: Pearson, 2011.</p><p>TELES, V. M. Extreme programming :</p><p>aprenda como encantar seus usuários desenvolvendo software com agilidade e qualidade. 2.</p><p>ed. Novatec, 2017.</p><p>REFERÊNCIAS ON-LINE</p><p>¹ Em:< https://repositorio.ufsc.br/bitstream/handle/123456789/101860/220977.pdf?sequence=1&isAllowed=y >. Acesso em: 30</p><p>ago. 2017.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/refer�ncias</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://www.google.com/url?q=https%3A%2F%2Frepositorio.ufsc.br%2Fbitstream%2Fhandle%2F123456789%2F101860%2F220977.pdf%3Fsequence%3D1%26isAllowed%3Dy&sa=D&sntz=1&usg=AFQjCNFHePsIIkbWMhI5infJIn0FMdD54w</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/aprofundando</p><p>Página inicial</p><p>APROFUNDANDO</p><p>Para compreendermos um pouco mais sobre as metodologias ágeis de desenvolvimento de software, um questionamento que</p><p>muitos desenvolvedores, líderes de equipe de projetos e engenheiros de software fazem é: Qual é a metodologia que iremos</p><p>utilizar para este projeto? Fagundes (2005, p. 16) apresenta no Quadro 1 os resultados dos critérios nos métodos FDD, Scrum, XP,</p><p>Cristal Family e DSDM. Os métodos comparados que atendem aos critérios do manifesto ágil foram XP, o Scrum e o Crystal,</p><p>enquanto o DSDM e o FDD atenderam parcialmente.</p><p>Quadro 1 – Comparação entre os métodos ágeis.</p><p>Fonte: Cohn (2002 apud FAGUNDES, 2005, p.18).</p><p>Segundo (HIGHSMITH 2000a), o método FDD (Feature Driven Development), “desenvolvimento desenvolvido a características”,</p><p>“é focado em pequenas iterações que geralmente duram 2 semanas, onde ao final ocorre a entrega de uma parte do sistema</p><p>funcionando (apud FAGUNDES, 2005, p. 39). Massari (2014, p. 20) comenta que “o método FDD é um método ágil que consistem</p><p>em desenhar um protótipo do produto, montar uma lista de funcionalidades desse produto e planejar e desenvolver por</p><p>funcionalidades. [...] Ele promove o “faseamento” do projeto por funcionalidades”. A Figura 1 ilustra o método FDD:</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>Figura 1 – Método de desenvolvimento orientado a funcionalidades</p><p>Fonte: Massari (2014, p.20).</p><p>Com relação ao Método de desenvolvimento dinâmico de sistemas (DSDM – Dynamic Systems Development Method), Pressman</p><p>(2016, p. 79) comenta que o método é uma abordagem de desenvolvimento de software ágil que oferece uma metodologia para</p><p>construir e manter sistemas que satisfaçam restrições de prazo apertado por meio de uso de prototipagem incremental em um</p><p>ambiente de projeto controlado. Para Massari (2014, p. 22), o método DSDM considera o ciclo de vida de um projeto com quatro</p><p>fases: estudo de viabilidade, iteração do modelo funcional, iteração de design e construção e implementação.</p><p>Com relação ao método Crystal, segundo Massari (2014, p. 19):</p><p>É uma família de metodologias designadas para projetos dirigidos por pequenas equipes desenvolvendo</p><p>projetos de baixa criticidade ou até mesmo grandes equipes desenvolvendo projetos de alta criticidade. Os</p><p>principais princípios são: entrega frequente, melhorias reflexivas (checar por caminhos de melhorias e</p><p>implementá-los), comunicação osmótica (equipes próximas para compartilhamento), segurança pessoal e</p><p>foco.</p><p>Luna (2014, p. 104-105) mostra no Quadro 2 os pontos-chave, principais características e limitações entre os métodos XP,</p><p>SCRUM, DSDM, FDD e Crystal.</p><p>Quadro 2 – Comparação entre os métodos ágeis</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>Fonte: adaptado de Luna (2014, p. 104-105).</p><p>Concluímos deste estudo que é importante ter o conhecimento das principais características e limitações das metodologias ágeis</p><p>de desenvolvimento de software, para que, assim, seja possível selecionar qual a metodologia mais adequada para o projeto.</p><p>REFERÊNCIAS</p><p>FAGUNDES, P. B. Framework para comparação e análise de métodos ágeis. Dissertação. UFSC. 2005. Disponível em: <</p><p>https://repositorio.ufsc.br/bitstream/handle/123456789/101860/220977.pdf?sequence=1&isAllowed=y >. Acesso em: 30 ago.</p><p>2017.</p><p>LUNA, A. Implantando Governança Ágil – MAnGve: uma visão crítica, uma abordagem prática. Rio de Janeiro: Brasport, 2011.</p><p>MASSARI, V. Gerenciamento ágil de projetos: uma visão preparatória para a certificação ágil. Rio de Janeiro: Brasport, 2014.</p><p>PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH. 2016.</p><p>PARABÉNS!</p><p>Você aprofundou ainda mais seus estudos!</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://www.google.com/url?q=https%3A%2F%2Frepositorio.ufsc.br%2Fbitstream%2Fhandle%2F123456789%2F101860%2F220977.pdf%3Fsequence%3D1%26isAllowed%3Dy&sa=D&sntz=1&usg=AFQjCNFHePsIIkbWMhI5infJIn0FMdD54w</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial/editorial</p><p>Página inicial</p><p>EDITORIAL</p><p>DIREÇÃO UNICESUMAR</p><p>Reitor Wilson de Matos Silva</p><p>Vice-Reitor Wilson de Matos Silva Filho</p><p>Pró-Reitor de Administração Wilson de Matos Silva Filho</p><p>Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva</p><p>Presidente da Mantenedora Cláudio Ferdinandi</p><p>C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância;</p><p>SCHIRIGATTI , Jackson Luis.</p><p>Metodologia Tradicional x Ágil. Jackson Luis Schirigatti.</p><p>Maringá-Pr.: UniCesumar, 2017.</p><p>31 p.</p><p>“Pós-graduação Universo - EaD”.</p><p>1. Metodologia. 2. Software 3. EaD. I. Título.</p><p>CDD - 22 ed. 006</p><p>CIP - NBR 12899 - AACR/2</p><p>Pró Reitoria de Ensino EAD Unicesumar</p><p>Diretoria de Design Educacional</p><p>Equipe Produção de Materiais</p><p>Fotos : Shutterstock</p><p>NEAD - Núcleo de Educação a Distância</p><p>Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900</p><p>Maringá - Paraná | unicesumar.edu.br | 0800 600 6360</p><p>Retornar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p�gina-inicial/editorial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa3/p%C3%A1gina-inicial</p><p>Página inicial</p><p>COMPARATIVO ENTRE</p><p>METODOLOGIA</p><p>TRADICIONAL E ÁGIL</p><p>Professor :</p><p>Me. Jackson Luis Schirigatti</p><p>Objetivos de aprendizagem</p><p>• Apresentar uma visão geral entre as metodologias tradicionais e ágeis com relação a sua utilização em projetos de</p><p>desenvolvimento de software.</p><p>• Apresentar, comparar e compreender as possíveis metodologias aplicadas aos projetos quanto à orientação por processo ou</p><p>pessoas, a quantidade de artefatos e a orientação ao planejamento ou a mudanças.</p><p>• Apresentar, comparar e compreender as possíveis metodologias aplicadas aos projetos quanto aos requisitos, habilidades da</p><p>equipe, tamanho da equipe e produto gerado, a impessoalidade, a filosofia e ao gerenciamento.</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>Plano de estudo</p><p>A seguir, apresentam-se os tópicos que você estudará nesta unidade:</p><p>• Visão Geral entre as Metodologias.</p><p>• Comparativo entre as Metodologias I.</p><p>• Comparativo entre as Metodologias II.</p><p>Introdução</p><p>Neste estudo, vamos realizar, através de uma abordagem comparativa, uma análise de quando utilizar as metodologias de</p><p>desenvolvimento de software tradicional e a ágil nas diversas abordagens de projetos. Na primeira aula, através de uma visão</p><p>geral, serão apresentados alguns comentários e comparações sobre as metodologias tradicionais e ágeis de diversos autores, para</p><p>que possamos recordar e sintetizar as características</p><p>dessas metodologias. Nas aulas posteriores, em dois momentos, serão</p><p>comparadas e compreendidas as diversas características e aplicações das metodologias tradicionais e ágeis, com relação aos</p><p>paradigmas e projetos de desenvolvimento de softwares. As características abordadas das metodologias neste estudo estão</p><p>relacionadas à orientação por processo ou pessoas, à quantidade de artefatos gerados durante as fases do projeto, à orientação ao</p><p>planejamento ou a mudanças, aos requisitos, às habilidades da equipe, tamanho da equipe e produto gerado, à impessoalidade, à</p><p>filosofia e ao gerenciamento do projeto. Veremos, portanto, comparações através de comentários e sugestões, realizando</p><p>conexões e possíveis combinações das metodologias. A finalidade do estudo não é enfatizar alguma metodologia ou prática</p><p>específica, pois a imparcialidade é fundamental para que o leitor tire suas próprias conclusões. Devemos compreender que é</p><p>possível trabalhar com todas as metodologias, mas uma boa prática que deve ser seguida é entender as suas vantagens e</p><p>desvantagens, combinando de maneira consciente e relacionando à cultura organizacional, aos negócios e às necessidades</p><p>específicas.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/unidade-4</p><p>Página inicial</p><p>Visão Geral entre as Metodologias</p><p>Neste estudo, entenderemos um pouco melhor sobre as características das metodologias tradicionais e ágeis, através de</p><p>comentários e estudos de vários autores até chegar a um comparativo mais sólido na questão da utilização de tais abordagens no</p><p>ambiente de desenvolvimento de software. Hoje são muitas as metodologias de desenvolvimento e de gerenciamento de software,</p><p>tanto as tradicionais como as ágeis, tais quais podem ser combinadas para uma melhor eficiência de produção, redução de riscos,</p><p>maior qualidade e menor custo. Para Soares (2004, p. 1, on-line)³ , as metodologias ágeis têm sido apontadas como uma alternativa</p><p>às abordagens tradicionais para o desenvolvimento de software. As metodologias tradicionais, conhecidas como pesadas ou</p><p>orientadas a planejamentos, devem ser aplicadas apenas em situações em que os requisitos futuros são previsíveis.</p><p>Segundo Eder et al. (2015, p. 1), o desafio atual é verificar os benefícios e restrições dessa abordagem e os estudos comparativos</p><p>com um meio mais confiável para a verificação (tanto para o desenvolvimento, como para o gerenciamento ágil e tradicional de</p><p>projetos de software). Luna (2011, p. 103), apresenta no Quadro 1, as comparações entre os pressupostos do desenvolvimento</p><p>dirigido por planejamento e da abordagem ágil.</p><p>Quadro 1 – Comparação entre os pressupostos do desenvolvimento dirigido por planejamento e da abordagem ágil.</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>Fonte: Magalhães et al. (2005 apud LUNA, 2011, p.103-104).</p><p>Segundo Soares (2004, p. 5, on-line)³ , as metodologias ágeis diferenciam-se das tradicionais com relação ao enfoque e valores. A</p><p>ideia das metodologias ágeis é o enfoque nas pessoas e não em processos ou algoritmos. Além disso, existe a preocupação de</p><p>gastar menos tempo com documentação do que com implementação, mas isso não quer dizer que as metodologias tradicionais não</p><p>estejam preocupadas com as pessoas – o próprio PMI inseriu em seus processos de gerenciamento de projetos, na sua 5ª edição do</p><p>PMBOK, um novo processo chamado de Stakeholders, enfatizando a importância de todos os envolvidos no projeto. Em termos de</p><p>gerenciamento de projetos de desenvolvimento de software, os frameworks PMBOK do PMI (Instituto de Gerenciamento de</p><p>Projetos) e o PRINCE2, são exemplos de abordagem tradicional. Em contrapartida, a Scrum (foco no gerenciamento) e o Extreme</p><p>Programming – XP (foco no desenvolvimento) são exemplos de abordagens ágeis. Para Soares (2004, p. 5, on-line)3 , uma</p><p>característica das metodologias ágeis é que elas são adaptativas em vez de preditivas. Priklandnicki et al. (2014, p. xxi) comentam</p><p>que os métodos ágeis têm desempenhado um papel fundamental para o desenvolvimento de software moderno ao priorizar o</p><p>valor que o projeto agrega e as interações entre as pessoas, em vez do cumprimento dos prazos, custos ou atendimento ao escopo</p><p>inicialmente definido. No Quadro 2 a seguir, Priklandnicki et al. (2014, p. xxii) apresentam um comparativo entre o método</p><p>tradicional e ágil. Na primeira coluna, elencam os pressupostos fundamentais de uma metodologia de desenvolvimento de</p><p>software</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>Quadro 2 – Comparativo entre Metodologia Tradicional e Ágil.</p><p>Fonte: Priklandnicki et al. (2014, p.xxii).</p><p>Soares (2004, p. 5, on-line)³comenta que, para uma metodologia ser considerada ágil:</p><p>A metodologia deve aceitar a mudança ao invés de tentar prever o futuro. O problema não é a mudança em</p><p>si, mesmo porque ela ocorrerá de qualquer forma. O problema é como receber, avaliar e responder as</p><p>mudanças. Como exemplo, as aplicações baseadas em Web são melhores modeladas usando metodologias</p><p>ágeis, uma vez que o ambiente Web é muito dinâmico.</p><p>As metodologias pesadas devem ser aplicadas apenas em situações em que os requisitos do software são</p><p>estáveis e requisitos futuros são previsíveis. Estas situações são difíceis de serem atingidas, uma vez que os</p><p>requisitos para o desenvolvimento de um software são mutáveis.</p><p>Por outro lado, Priklandnicki et al. (2014, p. xxi) comentam que a agilidade questiona modelos consolidados por meio de uma</p><p>revisão de valores da indústria de TI. Aos poucos empresários e gestores estão cedendo à tradição industrial em prol de novos</p><p>paradigmas de trabalho. Podemos entender que existe uma tendência à utilização das metodologias ágeis, entretanto, é</p><p>importante ficar claro que se deve conhecer o tipo de projeto, o ambiente de trabalho, o tipo do negócio envolvido, os</p><p>stakeholders, o conhecimento sobre a metodologia ágil e a questão da cultura organizacional e seu nível de maturidade nesta</p><p>questão. Cada metodologia possui suas vantagens e desvantagens e podem ser adaptadas e combinadas. Empresas sólidas</p><p>utilizam as práticas de gerenciamento de projetos e de desenvolvimento próprias a partir das boas práticas consagradas do</p><p>mercado.</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>O PRINCE2TM, ou Project In a Controlled Environment, é um método não proprietário para gerenciamento</p><p>de projetos. É adaptável a qualquer tipo ou tamanho de projeto e cobre seu gerenciamento, controle e</p><p>organização. Um Projeto PRINCETM possui as seguintes características: (1) controle e organização do</p><p>inicio ao fim; (2) regular revisão de progressos baseada nos planos e no business case; (3) pontos de decisão</p><p>flexível; (4) envolvimento da gerencia e das partes interessadas em momentos-chave durante toda a</p><p>execução do projeto e (5) um bom canal de comunicação entre o time do projeto e o restante da</p><p>organização. Hoje o PRINCE2TM vem sendo adotado como um padrão para todos os projetos</p><p>governamentais no Reino Unido e amplamente utilizado pela iniciativa privada não só naquele pais, mas</p><p>também em outros lugares da Europa, África, Oceania e Estados Unidos. É considerado o método de</p><p>gerenciamento de projetos mais utilizados no mundo.</p><p>Fonte: Angelo (2008).</p><p>Comparativo entre as Metodologias I</p><p>É possível identificar as metodologias tradicionais e ágeis aplicadas aos diversos projetos de desenvolvimento de software. No</p><p>Quadro 3, adaptado de diversos autores e a partir deste estudo, podemos realizar um comparativo entre a metodologia tradicional</p><p>e ágil (segunda e quarta coluna), exemplos de metodologias</p><p>(item 2), suas características principais, como a orientação a processo</p><p>ou pessoas (item 1), quantidade de artefatos no projeto (item 3), bem como a aplicação nos diversos tipos projetos de</p><p>desenvolvimento de software.</p><p>Quadro 3a – Comparativo entre as metodologias de desenvolvimento e gerenciamento de software com relação às características</p><p>dos projetos.</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>Fonte: Autor.</p><p>a. Orientação a processos e a pessoas (item 1, Quadro 3a):</p><p>Empresas que possuem abordagem para processos e a níveis de maturidade alta podem trabalhar com maior eficiência nos</p><p>projetos. Empresas pequenas que não possuem processos definidos, se utilizarem as metodologias com abordagens a processos,</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>podem ter efeitos desastrosos na qualidade e entrega do produto final. Uma abordagem orientada a processos reduz considerável</p><p>a comunicação nos projetos e portfólios, deve-se, entretanto, criar um escritório de projetos (PMO – Project Management Office)</p><p>para interagir as equipes, pessoal e suas expectativas na estrutura organizacional por processos. O poder de comunicação na</p><p>abordagem ágil traz benefícios da proximidade da equipe de desenvolvimento, com relação às influências de decisão e execução</p><p>que são geradas reciprocamente durante o projeto. Devido a essa alta comunicação, mudanças rápidas entre clientes e equipe são</p><p>solicitadas e devem estar preparados para este nível de aceitação. Portanto, não quer dizer que as metodologias orientadas a</p><p>processos não sejam ideais para a produção de software, mas que certos questionamentos devem ser feitos: que resultados o</p><p>cliente espera do seu software? Que riscos o projeto está ou pode ser submetido? A área de desenvolvimento (equipe do projeto)</p><p>está preparada para trabalhar com tal metodologia? Que habilidades e conhecimentos a equipe e o gestor de projeto possuem</p><p>sobre o projeto e a metodologia? Como é a estrutura organizacional da empresa? É uma fábrica de software ou uma indústria?</p><p>b. Quantidade de artefatos (item 2, Quadro 3a):</p><p>Como visto no Quadro 3, Soares (2004, p. 1, on-line)³ comenta que “os processos orientados a documentação para o</p><p>desenvolvimento de software são de certa forma, fatores limitadores aos desenvolvedores e muitas organizações não possuem</p><p>recursos e inclinação para processos pesados de produção de software”. A sugestão é não deixar de realizar o registro das</p><p>informações e dosar a quantidade necessária de artefatos que documentarão o projeto.</p><p>Outra questão que deve ser considerada é a interpretação pelo Manifesto ágil com relação à quantidade de documentação na</p><p>metodologia ágil. Cruz (2013, p. 112) comenta sobre essas interpretações erradas do Scrum ou do Manifesto Ágil, que dizem que</p><p>não há necessidade de realizar tal documentação em metodologias ágeis e que documentação é perda de tempo. Cruz (2013, p. 12)</p><p>afirma o contrário: o Manifesto Ágil quer dizer que</p><p>deve haver mais produto funcionando do que documentação excessiva. Em outras palavras, uma</p><p>documentação necessária deve ser realizada, e a sugestão mais importante é que recomendada é registrar e</p><p>confirmar todas as regras de negócios sem exceção, independente de ser Scrum ou método tradicional.</p><p>c. Exemplos de metodologias ágeis e tradicionais (item 3, Quadro 3a):</p><p>Relembrando as definições de algumas metodologias ágeis, segundo Soares (2004, p. 3, on-line)³ , a Extreme Programming (XP) é</p><p>uma metodologia ágil para equipes pequenas e médias que desenvolvem software baseado em requisitos vagos e que se</p><p>modificam rapidamente, de feedback constante, abordagem incremental e alta comunicação encorajadora. O Scrum, por outro</p><p>lado, segundo Priklandnicki et al. (2014, p. 22), é um framework ágil que auxilia no gerenciamento de projetos complexos e no</p><p>desenvolvimento de produtos. É conhecido como framework que prescreve um conjunto de práticas leves e objetivas, muito</p><p>utilizadas na área de desenvolvimento de software.</p><p>Com relação às metodologias tradicionais, o PMBOK do PMI é um conjunto de boas práticas de gerenciamento de projetos</p><p>consolidadas em livros chamados guias de gerenciamento de projetos. Enfatiza o detalhamento do escopo, tempo e custo dentro</p><p>de processos específicos. É utilizado para qualquer tipo de projeto em que é possível dosar o detalhamento da documentação de</p><p>acordo com o tamanho e complexidade do projeto. O PRINCE2 é um método de gerenciamento de projetos não proprietário</p><p>genérico. É um framework completo para o projeto e isola o gerenciamento com o esforço do projeto (PRINCE2, 2017, on-line)2 .</p><p>Referente às metodologias tradicionais de desenvolvimento de software, a Cascata é um modelo que não atende às reais</p><p>demandas de produção de software, pois suas etapas de levantamento de necessidades, análise, projeto, implementação e</p><p>manutenção não mais condizem com uma cadeia de intermináveis mudanças. Até mesmo o PMBOK, cujo gerenciamento é</p><p>tradicional (concepção, planejamento, execução e encerramento), aborda, através das boas práticas de gerenciamento de projetos,</p><p>um processo de gerenciamento de mudanças, que trata as mudanças de escopo, tempo e custo durante o projeto.</p><p>d. Orientada a planejamentos ou a mudanças (item 4 e 5, Quadro 3a):</p><p>Segundo Soares (2004, p. 4, on-line)³ , o planejamento consiste em decidir o que é preciso ser feito e o que pode ser adiado no</p><p>projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros. Ainda sobre a aposta</p><p>do XP, especificamente, Soares (2004, p. 3, on-line)³ comenta que é melhor fazer algo simples hoje e pagar um pouco mais amanhã</p><p>para fazer modificações necessárias do que implementar algo complicado hoje, que talvez não venha a ser usado, sempre</p><p>considerando que requisitos são mutáveis. Na metodologia tradicional, a etapa de planejamento é o levantamento de requisitos e</p><p>análise de viabilidade do projeto, verificando todas as funcionalidades necessárias para o desenvolvimento e implementação final</p><p>do software. Está baseado em um planejamento de possíveis fatores de riscos e das probabilidades que os riscos ocorrem. Essa</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>etapa demanda um custo presente alto e custo futuro baixo, pois tenta prever exaustivamente os requisitos de funcionalidades</p><p>atuais e futuras. Em termos de segurança contratual, a abordagem tradicional preserva uma negociação entre as partes através de</p><p>formalizações. Na metodologia ágil, por outro lado, a impessoalidade pode trazer problemas contratuais nas entregas e nos</p><p>objetivos do projeto.</p><p>A importância do PMO como apoio ao gerenciamento de projetos: um escritório de gerenciamento de</p><p>projetos (EGP ou PMO) é uma estrutura organizacional que padroniza os processos de governança</p><p>relacionados a projetos e facilita o compartilhamento de recursos, metodologias, ferramentas e técnicas. As</p><p>responsabilidades de PMO podem variar, desde o fornecimento de funções de apoio ao gerenciamento de</p><p>projetos até a responsabilidades real pelo gerenciamento direto de um ou mais projetos. Há vários tipos de</p><p>estruturas de PMO nas organizações e elas variam em função do seu grau de controle e influência nos</p><p>projetos da organização, tais como (1) de suporte (papel consultivo nos projetos, fornecendo modelos,</p><p>melhores práticas, treinamento, acesso às informações e lições aprendidas com outros projetos); (2) de</p><p>controle (fornecem suporte e exigem a conformidade através de adoção de estruturas, metodologias de</p><p>gerenciamento de projetos, usando modelos, formulários e ferramentas específicas) e (3) apoio diretivo, em</p><p>que assumem o controle dos projetos através do gerenciamento direto.</p><p>Fonte: PMBOK (2013, p. 10).</p><p>Comparativo entre as Metodologias II</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>Nesta aula, vamos apresentar outras características da metodologia tradicional e ágil, elencadas no Quadro 3b, como as</p><p>habilidades da equipe de projeto, a quantidade de integrantes da equipe, a impessoalidade ou pessoalidade por parte do cliente e</p><p>equipe do projeto, as filosofias de projeto e as características do gerenciamento e controle do projeto.</p><p>Quadro 3b – comparativo entre as metodologias de desenvolvimento e gerenciamento de software com relação às características</p><p>dos projetos.</p><p>Fonte: o autor.</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>a. Habilidades e tamanho da equipe de projeto (item 1 e 2, Quadro 3b)</p><p>Nos modelos tradicionais, as equipes de projeto precisam ter habilidades e conhecimentos variados sobre as documentações de</p><p>projeto e de modelagem do software, como entendimento do PMI, UML e outras especificações referentes ao negócio do projeto,</p><p>além de habilidades de liderança, julgamento (analítica) e de percepção (decisão). Nos modelos ágeis, os times devem ser auto-</p><p>organizáveis. Segundo o Manifesto Ágil, “as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis”.</p><p>Segundo Bernardo (2015, on-line)¹ , esta auto-organização é uma forma de levar equipes a um padrão de alta performance, mas</p><p>não significa que a equipe é independente o suficiente para se organizar em torno de um problema a ser resolvido, tendo</p><p>autonomia para decidir a melhor forma de fazê-lo e solucioná-lo. Ainda segundo Bernardo (2015, on-line)1, corporações que</p><p>decidem assumir a responsabilidade de se tornarem auto-organizáveis enfrentam grandes desafios no decorrer do caminho, mas</p><p>as recompensas para as que conseguem são gigantescas. Alguns benefícios são citados, como:</p><p>1. Comunicação mais rápida e aprimorada.</p><p>2. Mais confiança entre cliente e equipe.</p><p>3. Diminuição de conflitos.</p><p>4. Aumento de motivação.</p><p>5. Decisões coerentes e mais bem informadas.</p><p>6. Trabalho em conjunto aprimorado.</p><p>7. Maior confiança para decisões.</p><p>8. Equipes mais adaptativas. (BERNANDO, 2015, on-line)¹ .</p><p>Cohn (2011, p. 53) comenta que “os desenvolvedores de metodologias ágeis como o Scrum, devem aprender novas habilidades</p><p>técnicas, como os programadores e testadores terão que programar e testar sistemas sem depender tanto de documentação,</p><p>aprender novas maneiras de automatizar os testes”. Habilidades, conhecimentos e pensamentos devem ser aprendidos, mas a</p><p>metodologia deve ser guiada por uma documentação mais enxuta e suficiente. Conforme Highsmith (2002 apud DALFOVO;</p><p>TAMBORLIN, 2017, p. 216), as habilidades, personalidades e peculiaridades dos indivíduos são críticas para o sucesso dos</p><p>projetos. Os indivíduos serão muitas vezes desorganizados e difíceis de entender, ao mesmo tempo em que são inovadores,</p><p>apaixonados, criativos e exuberantes. Segundo Dalfovo e Tamborlin (2017, p. 216), o trabalho em equipe e as habilidades</p><p>individuais são características inseparáveis em projetos de desenvolvimento de software, pois sem eles não há como aplicar a</p><p>agilidade. No entanto, cabe ressaltar que os processos têm o propósito de guiar e apoiar o desenvolvimento de software e as</p><p>ferramentas para a melhoria da eficiência.</p><p>Para Soares (2004, p. 6, on-line)³ , outro grande desafio é utilizar as metodologias ágeis em grandes empresas, uma vez que essas</p><p>metodologias são baseadas em equipes pequenas. Neste caso, pelo menos, é necessário resolver os problemas de comunicação</p><p>internos na equipe devido à separação geográfica.</p><p>b. Colaboração com o Cliente e a equipe de projeto (item 3, Quadro 3b)</p><p>Para Dalfovo e Tamborlin (2017, p. 218), a colaboração com o cliente, mais do que negociar contratos, é um valor ágil que mostra a</p><p>necessidade que ambos possuem na busca pela qualidade do produto e do software. A relação entre a organização e o cliente deve</p><p>existir sob o companheirismo, tomada de decisão conjunta e rapidez na comunicação. Para Cohn (2000, p. 375), um pensamento</p><p>incorreto é o de que o Scrum não é uma boa opção para uma equipe distribuída geograficamente. Felizmente, esse argumento é</p><p>falso. O Scrum pode ajudar equipes geograficamente distribuídas a ter um desempenho em níveis próximos aos de equipes</p><p>colonizadas ou colonizadas em colaboração, em que cada equipe possui habilidades suficientes para a entrega do produto, sendo</p><p>essas distantes em cidades diferentes. Cohn (2011, p. 375) apresenta as vantagens que o Scrum potencializa: “Maior visibilidade</p><p>pela exibição de um progresso demonstrável no fim de cada sprint; possibilidade de ajuste de prioridades após cada sprint;</p><p>comunicação mais frequente; ênfase na qualidade e automação de testes [...]”.</p><p>c. Gerenciamento e controle na etapa do projeto (item 5, Quadro 3b)</p><p>Na metodologia tradicional de gerenciamento e desenvolvimento de projetos de software, se tem uma ênfase de controle e de</p><p>planejamento nas atividades de planejamento e execução do projeto. Essa ênfase depende da cultura organizacional e da estrutura</p><p>de atividades da organização. Uma empresa pode ter uma ênfase alta ou baixa no controle da execução e no planejamento de suas</p><p>atividades dos projetos, como mostra a matriz de ênfase de atividades de planejamento e controle na Figura 1. Isso ocorre porque</p><p>os projetos são constituídos de atividades da empresa e recebem também essa ênfase nas estruturas funcionais e mistas que</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>utilizam mesmos processos. Frezatti (2009) apresenta essa matriz para o planejamento e controle das atividades organizacionais,</p><p>que vale para os projetos que estão com aderências nestas atividades funcionais da estrutura organizacional.</p><p>Figura 1 – Matriz de ênfases em atividades de planejamento e controle.</p><p>Fonte: Adaptado de Frezatti (2009, p. 19).</p><p>No quadrante 1, a predominância de foco nas atividades no planejamento é mais valorizada, e as pessoas estão alertas para a sua</p><p>relevância e impacto. Contudo, o controle das atividades para assegurar que possam atingir os objetivos desejados não se verifica</p><p>com o mesmo entusiasmo (FREZATTI, 2009, p. 19). Nessa abordagem, temos como exemplos as organizações que não efetuam</p><p>controles, utilizam pouco ou nenhum indicador para atingir os objetivos de projetos e processos, e o feeling como realimentação</p><p>dos processos. Sem medição e controle, não tem como realizar gestão.</p><p>No quadrante 2, pelo tipo de definição de controle, essa abordagem nem ao menos contempla a perspectiva de planejamento, já</p><p>que na visão adequada só existe controle quando o planejamento o procede (FREZATTI, 2009, p. 19). Nessa abordagem, temos</p><p>como exemplo organizações imediatistas, sem perspectivas de planejamento e pouca proatividade e gestão organizacional.</p><p>O quadrante 3 apresenta significativo foco no planejamento e controle. É a abordagem mais desejada para as metodologias</p><p>tradicionais.</p><p>O quadrante 4 apresenta um reduzido foco tanto no planejamento como no controle. Esse tipo de organização já tem seu rumo</p><p>traçado. Salvo aquelas muito pequenas, que vivem dos impulsos dos seus fundadores e visionários, as demais já se encontram na</p><p>rota da extinção (FREZATTI, 2009, p. 21).</p><p>Em relação à metodologia ágil do gerenciamento, Cohn (2011, p. 305) comenta que o planejamento é um aspecto fundamental</p><p>para o Scrum. As equipes Scrum se comprometem a sempre trabalhar nos requisitos de valor mais alto. Para fazer isso, a equipe e o</p><p>dono do produto devem ter uma estimativa de quanto custará desenvolver um requisito, senão será apenas uma priorização por</p><p>desejo do requisito. Na metodologia XP, a atividade de planejamento é constituída de uma atividade de levantamento de requisitos</p><p>para um melhor entendimento do ambiente de negócios de software, conduzindo a um conjunto de estórias, relatos de usuários</p><p>que descreve os resultados, características e funcionalidades para a construção do software. Cada estória</p><p>explica que é devido à natureza complexa do</p><p>software, pois é necessária uma maior compreensão de como atender às necessidade dos usuários, das</p><p>mudanças legais dos negócios e das mudanças procedimentais nos processos organizacionais. Deve-se,</p><p>portanto, atendê-las através das funcionalidades dos sistemas. Existem vários tipos de negócios:</p><p>financeiros, científicos, agronegócios, industriais, contábeis, de engenharia, de produção, armazenamentos,</p><p>logísticos, etc.; logo, existem vários tipos de sistemas, dos mais simples aos mais complexos, interligados,</p><p>conectados, de alto armazenamento e de sistemas críticos, atendendo aos respectivos negócios. As</p><p>metodologias ajudam a produzir melhor os sistemas, verificar o que realmente o cliente deseja, projetar e</p><p>codificar as funcionalidades, testar e manutenir para a sobrevivência do seu ciclo de vida. É possível</p><p>desenvolver sem uma metodologia?</p><p>Fonte: o autor.</p><p>Fase de Especificações do Software</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Nesta aula vamos estudar a fase de especificação do software, que é o momento do entendimento dos serviços ou produto</p><p>requisitados pelo cliente. Nesse caso, o resultado gerado é uma consultoria ou produto (software ou sistemas). Devemos aqui</p><p>realizar os seguintes questionamentos: “é viável ao negócio tal serviço ou produto?”, “há orçamento disponível para desenvolver o</p><p>produto ou serviço?”, “como deseja tal serviço?”, “quais são os requisitos do serviço ou produto?”, “os requisitos desejados são</p><p>realmente os definidos?”. Alguns autores apresentam essa fase, também como etapa de viabilidade e análise de sistemas. No</p><p>estudo de viabilidade, é necessário identificar as deficiências atuais, estabelecer objetivos no novo sistema; gerar cenários</p><p>aceitáveis; preparar encargos de projeto. Nas atividades de análise de sistemas, é preciso desenvolver o modelo ambiental,</p><p>desenvolver o modelo comportamental; estabelecer os limites homem-máquina, executar a análise custo-benefício etc.</p><p>(REZENDE, 2005, p. 42).</p><p>Especificações de Software</p><p>Para Brookshear (2013, p. 267), o ciclo de vida do software inicia com a análise de requisitos, cujos objetivos são especificar quais</p><p>serviços o sistema proposto fornecerá, identificar quaisquer condições (restrições de tempo, segurança e assim por diante) desses</p><p>serviços e definir como o mundo externo vai interagir com o sistema. Para Sommerville (2011, p.24), “esta fase também chamada</p><p>de especificação de software ou engenharia de requisitos é o processo de compreensão e definição dos serviços requisitados do</p><p>sistema e identificação de restrições relativas à operação e ao desenvolvimento do sistema”. A Fig.3 mostra as atividades do</p><p>processo de engenharia de requisItos, tendo como resultado final uma documentação de requisitos. As atividades são de: (1)</p><p>estudo de viabilidade; (2) elicitação e análise de requisitos; (3) especificação de requisitos e (4) validação de requisitos.</p><p>Figura 4 – Os requisitos de engenharia de processos.</p><p>Fonte: adaptado de Sommerville (2011, p. 24).</p><p>a. Estudo de viabilidade:</p><p>O estudo de viabilidade (primeira atividade do processo de engenharia de requisitos, Figura 4) é uma atividade para verificar se o</p><p>sistema proposto é viável a partir do ponto de vista de negócio e orçamentário. Se aplicado um conceito de gestão de projetos,</p><p>essa etapa é analisada na fase de abertura e planejamento do projeto, na qual são realizados o levantamento das necessidades e o</p><p>planejamento do escopo, do tempo e do custo do projeto, baseados no orçamento proposto e selecionados pelo portfólio de</p><p>projetos. Alguns autores também chamam essa etapa de fluxo de trabalho de levantamento de necessidades, na qual são</p><p>identificadas as necessidades do cliente, verificação do prazo, confiabilidade e custo. Para Sommerville (2011, p.25), “um estudo de</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>viabilidade deve ser relativamente barato e rápido. O resultado deve informar à decisão de avançar ou não, com uma análise mais</p><p>detalhada”. O produto gerado dessa atividade é um relatório de viabilidade.</p><p>b. Elicitação e análise de requisitos:</p><p>A segunda atividade do processo de engenharia de requisitos é a elicitação e análise de requisitos . Trata-se, na verdade, da</p><p>descoberta dos requisitos, levantamento de requisitos, ou até da busca ou coleta de informações, por meio de observação,</p><p>documentações, discussões etc.</p><p>Para IIBA (2011, p.57),</p><p>A elicitação é uma tarefa-chave de análise de negócios. É essencial que os requisitos sejam completos,</p><p>claros, corretos e consistentes, porque eles servem como pilares da solução para as necessidades dos</p><p>negócios [...]. A atividade de elicitação dos requisitos não é uma atividade isolada, os requisitos são definidos</p><p>durantes as atividades de análise, especificação e validação de requisitos. Algumas técnicas para a elicitação</p><p>dos requisitos podem ser usadas como brainstorming, entrevista, observação, análise de interfaces,</p><p>prototipagem, workshop de requisitos, pesquisa e questionário.</p><p>Para Camargo (2014, p. 58)</p><p>Requisitos são condições que devem ser obedecidas por um sistema, produto ou componente, um padrão,</p><p>uma especificação, ou outros documentos formais. Os “requisitos de um projeto” incluem as necessidades,</p><p>os desejos e as expectativas do patrocinador, cliente e outras partes.</p><p>Os Requisitos são os desejos dos clientes com relação ao projeto que irá gerar um produto ou serviço. Os requisitos do produto ou</p><p>serviço gerados pelo projeto são as regras de negócios (normas, condições), são funcionalidades de um sistema ou processo</p><p>(requisitos funcionais e não funcionais) desejáveis.</p><p>c. Especificação dos requisitos:</p><p>Para Sommerville (2011, p.25), “as especificações dos requisitos é a atividade de traduzir as informações obtidas, durante a</p><p>atividade de análise em um documento que defina um conjunto de requisitos”. Existem dois tipos de requisitos: (1) requisitos do</p><p>usuário (funcionalidades desejadas, abstrato) e (2) requisitos do sistema (funcionalidades atendidas). Ainda de acordo com</p><p>Sommerville (2011, p. 65), “Os requisitos de usuário para um sistema, descrevem os requisitos funcionais e não funcionais de modo</p><p>que sejam compreensíveis para os usuários do sistema que não tenham conhecimentos técnicos detalhados”.</p><p>Com relação aos requisitos funcionais e não funcionais, é preciso saber que: os requisitos funcionais são aqueles que definem o</p><p>comportamento do sistema, por meio do Caso de Uso [diagrama da UML para modelar sistemas] que documentam as entradas, os</p><p>processos e as saídas geradas. Exemplo: um cadastro de clientes cujo acesso é realizado pelo CPF do cliente, a descrição do</p><p>produto deve conter as especificações técnicas regidas por determinada norma técnica. Já os requisitos não funcionais são</p><p>compostos por características não necessariamente comportamentais, como a usabilidade, confiabilidade, desempenho e suporte.</p><p>Sobre a UML:</p><p>O Unified Modeling Language (UML) tem um amplo aspecto de utilização, e sua principal função é a</p><p>modelagem de regras de negócios e especificações de sistemas, compreendendo tanto os aspectos</p><p>estruturais do software como os dinâmicos. Para prover essa ampla gama de aplicação, a linguagem foi</p><p>definida de modo que possa ser estendida e seja genérica o suficiente para lidar com diferentes tipos de</p><p>sistemas, evitando especializações e complexidade excessiva. O UML é usado para modelar os mais</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>variados tipos de software, fornecendo diferentes tipos de visões do sistema. A UML também pode ser</p><p>aplicada em todas as fases do projeto de desenvolvimento de um sistema , desde o levantamento de</p><p>requisitos até os testes finais, passando pela especificação técnica e implementação.</p><p>Fonte: Martins (2010, p. 167).</p><p>d. Validação de requisitos:</p><p>é priorizada pelo cliente</p><p>(valor de negócio) e a equipe atribui um custo. Após 3 semanas, a funcionalidade priorizada é desenvolvida, mas não há um</p><p>planejamento de viabilidade, detalhamento do escopo, comunicação e planejamento dos riscos, como acontece no gerenciamento</p><p>de projetos do PMBOK/ PMI. A sugestão é utilizar a combinação do Scrum com o XP para uma melhor eficiência na produção e</p><p>gerenciamento do desenvolvimento do software.</p><p>d. Filosofia por etapas ou incremental (item 4, Quadro 3b)</p><p>As entregas do produto para o cliente está relacionada à definição na proposta inicial do projeto. Na metodologia tradicional, se</p><p>analisarmos bem, temos o modelo incremental ou iteração, que combina fluxos de processo linear (modelo cascata) com</p><p>sequências lineares de forma escalonada à medida que o tempo avança. Cada sequência produz incrementos entregáveis de</p><p>software. Segundo Sommerville (2011, p.33, apud SCHIRIGATII, 2017), as vantagens desse modelo seriam que os clientes podem</p><p>usar os incrementos iniciais como protótipos e ganhar experiência, formando os requisitos para os próximos incrementos. Outra</p><p>vantagem é que a probabilidade dos clientes encontrarem falhas de software nas partes mais importantes é menor, pois os</p><p>incrementos priorizados recebem uma maior quantidade de testes (SOMMEVILLE, 2011, p.22, apud SCHIRIGATTI, 2017).</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>Com relação à metodologia ágil XP, a construção do software ocorre também em formas incrementais, gera versões, e ele é</p><p>continuamente modificado . O cliente realiza os testes de aceitação e aprova a versão. Em seguida, uma nova versão é</p><p>implementada. Vejam que a satisfação do cliente é maior quando as versões são entregues por etapas, de forma que ele possa</p><p>realizar os testes e aprovas as versões. Como já comentado, o cliente deve colaborar (item b) com os testes de aceitação e verificar</p><p>as funcionalidades. Muitas organizações de médio e grande porte não participam de várias etapas do desenvolvimento do</p><p>software, pois alegam que não é o core business da organização e terceirizam totalmente a implementação do software. Nesses</p><p>casos, utilizam os processos tradicionais de desenvolvimento, pois relatam que participam apenas dos requisitos desejáveis e que</p><p>atendem às suas necessidades. Essa é uma questão de maturidade, entendimento e colaboração aos processos de</p><p>desenvolvimento de software ágil, que devem ser compartilhados e combinados nas suas diversas formas de produção conjunta de</p><p>software.</p><p>De acordo com o que foi estudado sobre as comparações entre as metodologias tradicionais e ágeis de</p><p>desenvolvimento e gerenciamento de software, é possível identificar qual seria a melhor metodologia ou</p><p>combinação de metodologia para determinada situação de projeto? Existe um consenso? A engenharia de</p><p>software pode nos ajudar nesse questionamento? Para isso, realize a leitura do artigo científico</p><p>Comparação entre metodologias Ágeis e Tradicionais para o Desenvolvimento de Software, de Michel dos</p><p>Santos Soares. Disponível em: < http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68</p><p>>.</p><p>(O autor).</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/unidade-4</p><p>https://getfireshot.com</p><p>http://www.google.com/url?q=http%3A%2F%2Fwww.dcc.ufla.br%2Finfocomp%2Findex.php%2FINFOCOMP%2Farticle%2Fview%2F68&sa=D&sntz=1&usg=AFQjCNFggfrNXbAxYyzDoV7OVCQKs8OqLw</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/atividades</p><p>Página inicial</p><p>ATIVIDADES</p><p>1. Para Soares (2004, p.1, on-line)3 , as metodologias ágeis têm sido apontadas como uma alternativa às abordagens tradicionais</p><p>para o desenvolvimento de software. As metodologias tradicionais, conhecidas como pesadas ou orientadas a planejamentos,</p><p>devem ser aplicadas apenas em situações em que os requisitos futuros são previsíveis. Portanto, de acordo com o comentário</p><p>feito por Soares sobre a aplicação das metodologias tradicionais, podemos ainda afirmar que a alternativa verdadeira sobre a</p><p>aplicação das metodologias ágeis seria:</p><p>a) Os times devem ser organizados pelo líder de projeto ou patrocinador do projeto, pois, segundo o manifesto ágil, “as melhores</p><p>arquiteturas, requisitos e desingns emergem de equipes organizadas e lideradas por um gestor de projeto”.</p><p>b) Os times devem ser auto-organizáveis, pois, segundo o manifesto ágil, “as melhores arquiteturas, requisitos e designs emergem</p><p>de equipes auto-organizáveis”.</p><p>c) Quando a equipe do projeto é pequena ela pode ser organizada e definida pelo gestor do projeto. Quando a equipe for formada</p><p>por um grande número de envolvidos e áreas funcionais, ela pode ser auto-organizável e auto-gerenciável.</p><p>d) A equipe de projeto deve ser definida somente pelo patrocinador do projeto e elas são organizadas e respondem ao líder do</p><p>projeto.</p><p>2. “Segundo Soares (2004, p. 4, on-line)3, o planejamento consiste em decidir o que é preciso ser feito e o que pode ser adiado no</p><p>projeto. A XP baseia-se em requisitos atuais para desenvolvimento de software, não em requisitos futuros. Ainda sobre a aposta</p><p>do XP, especificamente, Soares (2004, p. 3, on-line)3 comenta que é melhor fazer algo simples hoje e pagar um pouco mais amanhã</p><p>para fazer modificações necessárias do que implementar algo complicado hoje, que talvez não venha a ser usado, sempre</p><p>considerando que requisitos são mutáveis.” De acordo com esse trecho de nosso estudo sobre o planejamento realizado em</p><p>projetos de desenvolvimento de software, marque a alternativa correta o planejamento referente a metodologia ágil:</p><p>a) É preditiva.</p><p>b) É adaptativa.</p><p>c) É preditiva e adaptativa.</p><p>d) Necessidade de uma grande quantidade de artefatos para realizar as estimativas do escopo, tempo, custo e riscos.</p><p>3. A filosofia incremental e interativa é uma característica principal da metodologia ágil, conforme o texto de nosso estudo: “Com</p><p>relação à metodologia ágil XP, a construção do software ocorre também em formas incrementais, gera versões, e ele é</p><p>continuamente modificado. O cliente realiza os testes de aceitação e aprova a versão. Em seguida, uma nova versão é</p><p>implementada.” De acordo com a afirmativa acima, marque a alternativa correta:</p><p>a) Na metodologia clássica não há entregas incrementais e iterações nas etapas de desenvolvimento de software.</p><p>b) Na metodologia ágil, como os projetos utilizam uma abordagem por processos, utilizam atividades e tarefas das áreas</p><p>funcionais.</p><p>c) Na metodologia clássica, especificamente no modelo incremental ou iteração, utiliza-se de processos lineares escalonados e</p><p>geração de entregáveis.</p><p>d) Na metodologia clássica, utilizam-se sequenciamento iterativo por funcionalidade priorizadas do produto. Entregas</p><p>incrementais através de versões ou protótipos, através de modificações contínuas.</p><p>Resolução das atividades</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/atividades</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/resumo</p><p>Página inicial</p><p>RESUMO</p><p>Neste estudo vimos que a metodologia ágil diferencia da tradicional com relação ao enfoque e valores. Uma metodologia ágil tem</p><p>um enfoque mais relacionado às pessoas, e a tradicional, mais relacionado aos processos. Isso não quer dizer que as metodologias</p><p>tradicionais não se preocupem com as pessoas, mas estão mais relacionadas mais aos processos e ferramentas. Atualmente</p><p>algumas abordagens tradicionais de gerenciamento de projetos, como o PMI, estão preocupadas com a ênfase pessoas , que até</p><p>inseriram em seus processos de gerenciamento um novo processo chamado stakeholders . As metodologias tradicionais possuem</p><p>uma abordagem preditiva em vez de adaptativa, característica dos modelos ágeis.</p><p>A ideia da preditiva é prever, através de planos,</p><p>os possíveis riscos, mudanças de curso no escopo, custos e tempo do projeto. No paradigma ágil, já se tem um enfoque que as</p><p>mudanças ocorrerão de qualquer maneira, e o desenvolvimento pode sofre a qualquer momento estas mudanças. As metodologias</p><p>ágeis apostam que é melhor fazer algo simples e sem previsões hoje, e pagar um pouco mais e fazer as devidas modificações</p><p>amanhã, do que realizar um planejamento que consuma muito tempo para prever o quer será feito. Na questão de geração de</p><p>artefatos em projetos que utilizam o paradigma clássico, é possível gerar uma quantidade grande de documentações necessárias</p><p>para previsão e direcionamento do projeto, mas não é obrigatória, pois tudo depende da segurança do líder de projeto e do</p><p>conhecimento com relação aos projetos similares. No paradigma ágil, as entregas são incrementais com pouca ou quase nenhuma</p><p>documentação. Na metodologia ágil, aposta-se nas entregas versionadas das funcionalidades priorizadas e aprovadas pelo cliente.</p><p>Outra característica que merece ser revista aqui é da impessoalidade em projetos de paradigmas ágeis, muito questionada por</p><p>diversos autores. Na metodologia ágil a colaboração do cliente é essencial. Na metodologia clássica também, mas requer</p><p>maturidade na relação entre organização e o cliente sem haver contratos assinados, pois a falta de documentos legais pode causar</p><p>algumas dores de cabeça com relação ao escopo, tempo, custo e os entregáveis do projeto. Essas questões, que como vimos no</p><p>estudo, dependem da visão de cada gestor, da cultura e histórico de mudanças da organizacional, da complexidade e criticidade do</p><p>projeto, do conhecimento da equipe e do cliente, da estrutura organizacional e de diversos outros fatores.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/resumo</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/eu-indico</p><p>Página inicial</p><p>Material Complementar</p><p>Leitura</p><p>Scrum e PMBOK unidos no Gerenciamento de Projetos</p><p>Autor: Fabio Cruz</p><p>Editora: Brasport</p><p>Sinopse : esta publicação agrega muito valor à área de gerenciamento de</p><p>projetos ao trazer uma nova visão de integração entre o Guia PMBOK e o</p><p>Scrum. O grande mérito é permitir uma visão prática de dois referenciais</p><p>metodológicos até considerados antagônicos, mas que no decorrer da</p><p>leitura percebemos que são complementares e podem trazer ótimos</p><p>resultados com o uso combinado. Vale destacar que o conteúdo deste</p><p>livro não é apenas uma visão teórica, mas o resultado de vivências</p><p>profissionais e lições aprendidas em projetos reais com a aplicação em</p><p>boas práticas. Com essa abordagem, você obterá ganhos como: permitir</p><p>que os gerentes de projeto executem suas tarefas em ambiente Scrum;</p><p>prever entregas com o gerente de projetos e manter o foco no valor com</p><p>o Time Scrum; e Rodar Scrum de verdade com foco na execução e com o</p><p>apoio do Guia PMBOK nas demais fases; descrever as dez áreas de</p><p>conhecimento e os 47 processos do Guia PMBOK, juntamente com todas</p><p>as regras, cerimônias, papéis e responsabilidades do Scrum.</p><p>Comentário: este livro é uma leitura apropriada para reforçar os nossos</p><p>estudos sobre a combinação das metodologias clássica e ágil (assunto</p><p>abordado também no “aprofundando” deste estudo). Nessa abordagem, o</p><p>autor trata das boas práticas de gerenciamento de projetos reunidas no</p><p>guia PMBOK e do Framework ágil de trabalho Scrum. A sugestão para</p><p>toda combinação de metodologias é comparar as vantagens e</p><p>desvantagens de cada método ou prática e verificar as aderências de</p><p>ambas as metodologias ao projeto de desenvolvimento de software que</p><p>se deseja aplicar, verificando a cultura e estrutura organizacional,</p><p>tamanho e complexidade do projeto, conhecimento da equipe com</p><p>relação às metodologias e as necessidades e riscos do projeto.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/eu-indico</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/refer%C3%AAncias</p><p>Página inicial</p><p>REFERÊNCIAS</p><p>COHN, M. Desenvolvimento de software com scrum : aplicando métodos ágeis com sucesso. Porto Alegre: Bookman, 2011.</p><p>CRUZ, F. Scrum e guia PMBOK unidos no gerenciamento de projetos . Rio de Janeiro: Brasport, 2013.</p><p>DALFOLVO, O.; TAMBORLIN, N. Business intelligence : estudos e casos no uso da gestão de tecnologia da informação como</p><p>inteligência nos negócios. Blumenau: Edição Clube de Autores. 2017.</p><p>EDER, S.; CONFORTO, E. C.; AMARAL, D. C.; SILVA, S. L. da. Diferenciando as abordagens tradicional e ágil de gerenciamento de</p><p>projetos. Production , São Carlos, v. 25, n. 3, p. 482-497, 2015.</p><p>FREZATTI, F. Orçamento empresarial : planejamento e controle gerencial. 5. ed. São Paulo. Atlas, 2009.</p><p>LUNA, A. Implantando governança ágil – MAnGve. Rio de Janeiro: Brasport, 2011.</p><p>PMI. Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK) . 5. ed. Project Management Institute Inc.,</p><p>Newtown Square, Pennsylvania-USA, 2013.</p><p>PRIKLANDNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software . Porto Alegre: Bookman, 2014.</p><p>SCHIRIGATTI, J. L. Modelos tradicionais de desenvolvimento de software : Unidade II – Metodologia x Ágil. Unicesumar. Maringá,</p><p>2017.</p><p>REFERÊNCIAS ON-LINE</p><p>¹ Em: < https://www.culturaagil.com.br/auto-organizacao-em-projetos-ageis/ >. Acesso em 26 ago. de 2017.</p><p>² Em: < https://www.prince2.com/usa >. Acesso em 25 ago. 2017.</p><p>³ Em: < http://www.dcc.ufla.br/infocomp/index.php/INFOCOMP/article/view/68 >. Acesso em 24 ago. 2017.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/refer�ncias</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://www.google.com/url?q=https%3A%2F%2Fwww.culturaagil.com.br%2Fauto-organizacao-em-projetos-ageis%2F&sa=D&sntz=1&usg=AFQjCNGrmvvpsmjYODJ-g3eiXLcdjL0Wng</p><p>https://www.google.com/url?q=https%3A%2F%2Fwww.prince2.com%2Fusa&sa=D&sntz=1&usg=AFQjCNFDh3dccBktlEbx4DspzZ2KJMv4YQ</p><p>http://www.google.com/url?q=http%3A%2F%2Fwww.dcc.ufla.br%2Finfocomp%2Findex.php%2FINFOCOMP%2Farticle%2Fview%2F68&sa=D&sntz=1&usg=AFQjCNFggfrNXbAxYyzDoV7OVCQKs8OqLw</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/aprofundando</p><p>Página inicial</p><p>APROFUNDANDO</p><p>Neste Aprofundando, ampliaremos nosso conhecimento sobre as combinações de metodologias clássicas e ágeis, por meio da</p><p>comparação de compatibilidades das boas práticas de gerenciamento de projetos de software do PMBOK e PRINCE2 com a</p><p>metodologia de gerenciamento ágil Scrum.</p><p>Para Vargas (2016, p. 49), frente às especificidades da área de tecnologia, a gestão de projetos foi desafiada a ampliar e a adaptar</p><p>suas práticas para melhoria da produtividade e da qualidade. Vargas (2016), em seu estudo “Gerenciamento ágil de projetos em</p><p>desenvolvimento de software: um estudo comparativo sobre a aplicabilidade do Scrum em conjunto com PMBOK e/ou PRINCE2”,</p><p>comenta que o guia PMBOK não descreve como fazer projetos, e sim descreve o que deve ser feito por meio de processos que</p><p>abrangem diversas áreas de conhecimento. [...] O autor ressalta a importância de compreender o PMBOK e PRINCE2 como um</p><p>método, e não uma metodologia. O método está ligado ao modo de proceder para atingir o objetivo, e a metodologia está ligada ao</p><p>estudo do método, como ciência.</p><p>A perspectiva de análise considera que o PMBOK propõe-se como um manual de boas práticas a ser executado com uma</p><p>metodologia de gestão, sendo a última responsável, ou não, pelo engessamento</p><p>dos processos (VARGAS, 2016, p. 5). A Tabela 1,</p><p>adaptada de Vargas (2016), mostra as principais comparações do PMBOK x PRINCE 2 x SCRUM:</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>Tabela 1- Comparações do PMBOK x PRINCE 2 x SCRUM</p><p>Fonte: adaptado de Vargas (2016, p. 48) e Angelo (2008).</p><p>REFERÊNCIAS</p><p>VARGAS, L. M. Gerenciamento ágil de projetos em desenvolvimento de software: um estudo comparativo sobre a aplicabilidade do</p><p>Scrum em conjunto com PMBOK e/ou PRINCE2. Revista de Gestão e Projetos (GeP). v. 7, n. 3, set./dez. 2016.</p><p>ANGELO, A. S. Entendendo o PRINCE2. Revista Mundo PM - Project Management. Pr. 2008. Disponível em: <</p><p>http://www.mundopm.com.br/noticia.jsp?id=264 >. Acesso em: 9 out. 2017.</p><p>PARABÉNS!</p><p>Você aprofundou ainda mais seus estudos!</p><p>Avançar</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>http://www.google.com/url?q=http%3A%2F%2Fwww.mundopm.com.br%2Fnoticia.jsp%3Fid%3D264&sa=D&sntz=1&usg=AFQjCNEIUOMiEh9M_abvEO2XU_fOC9HQAg</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/editorial</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>Página inicial</p><p>EDITORIAL</p><p>DIREÇÃO UNICESUMAR</p><p>Reitor Wilson de Matos Silva</p><p>Vice-Reitor Wilson de Matos Silva Filho</p><p>Pró-Reitor de Administração Wilson de Matos Silva Filho</p><p>Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva</p><p>Presidente da Mantenedora Cláudio Ferdinandi</p><p>C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância;</p><p>SCHIRIGATTI, Jackson Luis.</p><p>Metodologia Tradicional x Ágil. Jackson Luis Schirigatti.</p><p>Maringá-Pr.: UniCesumar, 2017.</p><p>30 p.</p><p>“Pós-graduação Universo - EaD”.</p><p>1. Metodologia. 2. Software 3. EaD. I. Título.</p><p>CDD - 22 ed. 006</p><p>CIP - NBR 12899 - AACR/2</p><p>Pró Reitoria de Ensino EAD Unicesumar</p><p>Diretoria de Design Educacional</p><p>Equipe Produção de Materiais</p><p>Fotos : Shutterstock</p><p>NEAD - Núcleo de Educação a Distância</p><p>Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900</p><p>Maringá - Paraná | unicesumar.edu.br | 0800 600 6360</p><p>Retornar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/editorial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial</p><p>A atividade de validação de requisitos, segundo Vazquez e Simões (2016, p. 212), é um trabalho de garantia na engenharia de</p><p>requisitos que busca assegurar que todos os requisitos especificados estejam alinhados com os requisitos do negócio, ou seja,</p><p>procurar que todas as necessidades de negócio das partes interessadas no escopo do projeto estejam satisfeitas. Para Sommerville</p><p>(2011, p. 25), essa atividade verifica quanto a realismo, consistência e completude. Durante este processo, os erros no documento</p><p>de requisitos são inevitavelmente descobertos e, em seguida, o documento deve ser modificado para a correção desses problemas.</p><p>Fase de Projeto e Implementação de</p><p>Desenvolvimento de Software</p><p>Após a etapa de elicitação e análise de requisitos, por exemplo, através de um diagrama de caso de uso (UML – Linguagem de</p><p>Modelagem unificada) e validações, a fase de projeto de desenvolvimento de software é a ligação entre a codificação e seus</p><p>requisitos, visando estabelecer uma arquitetura de software.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Segundo Horstmann (2008, p. 446) “a fase de projeto, você desenvolve um plano sobre como vai implementar o sistema. Você</p><p>descobre as estruturas que apoiam o problema a ser resolvido”. A fase de projeto pode ser constituída e duas atividades principais:</p><p>(1) projeto de arquitetura e (2) projeto detalhado. Na atividade de projeto de arquitetura são desenvolvidos os diagramas de</p><p>implementação.</p><p>Pressman e Maxim (2016, p. 225-226), afirmam que o projeto de software está no núcleo técnico da</p><p>engenharia de software e é aplicado seja qual for o modelo de processo de software utilizado. Iniciando</p><p>assim que os requisitos de software tiverem sido analisados e modelados, o projeto de software é a última</p><p>ação de engenharia de software na atividade de modelagem e prepara o cenário para a construção (geração</p><p>de código e testes).</p><p>A Figura 5 mostra o esquema de transformação do modelo de requisitos em modelo de projeto.</p><p>Figura 5 – Transformando o modelo de requisitos no modelo de projeto.</p><p>Fonte: Pressman e Maxim (2016, p. 226).</p><p>Sommerville (2011, p. 25) explica que um projeto de software é uma descrição da estrutura do software a ser implementado, dos</p><p>modelos e estruturas de dados usados pelo sistema, das interfaces entre os componentes do sistema e, às vezes, dos algoritmos</p><p>usados. Pressman e Maxim (2016, p. 226) comentam que “o modelo de requisitos, manifestado por elementos baseados em</p><p>cenários, baseados em classes, orientado a fluxos e comportamentais, alimenta a tarefa de projeto”. Assim, a tarefa de projeto é</p><p>composta das atividades de projeto de dados/classes, projeto de arquitetura, projeto de interfaces e projeto de componentes,</p><p>como mostra a Figura 5.</p><p>Na Figura 6, Sommerville (2011, p. 26) trata estas atividades do processo de projeto como: projeto de arquitetura, projeto de</p><p>interface, projeto de componente e projeto de banco de dados, em que:</p><p>• As entradas do processo de projeto são: informação de plataforma, especificação de requisitos e descrição de dados (que são as</p><p>saídas do processo de requisitos).</p><p>• As saídas do processo de projeto são: arquitetura de sistema, especificação de banco de dados, especificação de interface e</p><p>especificação de componentes.</p><p>• As atividades do processo do projeto são: projeto de arquitetura, projeto de interface e projeto de componente, todas</p><p>convergindo para o projeto de banco de dados.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Figura 6 – Processo de Projeto.</p><p>Fonte: Sommerville (2011, p. 26).</p><p>As atividades de projetos mostrada na figura 6 também são chamadas de modelo de projeto. Segundo Pressman e Maxim (2016, p.</p><p>243), o modelo de projeto usa vários dos diagramas UML utilizados no modelo de análise; são fornecidos detalhes mais específicos</p><p>à implementação e enfatizados a estrutura e o estilo da arquitetura, os componentes que residem nessa arquitetura, bem como as</p><p>interfaces entre os componentes.</p><p>O Projeto de Arquitetura</p><p>Para Pressman e Maxim (2016, p. 226), o projeto de arquitetura define as relações entre os principais elementos estruturais de</p><p>software, os estilos arquiteturais e os padrões de projeto. Para Sommerville (2011, p. 25), por outro lado, o projeto de arquitetura,</p><p>no qual é possível identificar a estrutura geral do sistema, define os componentes principais (algumas vezes, chamados</p><p>subsistemas ou módulos), seus relacionamentos e como eles são distribuídos. Para Hirama (2012, p. 80), a arquitetura de software</p><p>é a estrutura ou as estruturas do sistema que abrange os elementos de software, as suas propriedades (atributos) visíveis</p><p>externamente e seus relacionamentos. A arquitetura é resultado de um conjunto de decisões técnicas e de negócio. Ainda segundo</p><p>Hirama (2012, p. 79):</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>A atividade de projeto tem por objetivo estabelecer uma arquitetura do software que seja realizável. Nesta</p><p>atividade, algumas decisões de projeto são tomadas para atender aos requisitos não funcionais tais como</p><p>desempenho, confiabilidade e manutenibilidade. Diferentemente da análise, no projeto a questão a ser</p><p>respondida é: “Como o software será desenvolvido?” A resposta é a arquitetura do software representado</p><p>por um modelo de arquitetura, que podem ser do tipo modelo baseado em repositório, modelo-cliente</p><p>servidor, modelo em cascata ou suas combinações. Uma vez definido um modelo de arquitetura do sistema,</p><p>a próxima atividade é decomposição do sistema em módulos.</p><p>Para Schach (2010, p. 233) “a arquitetura de um produto de software pode ser descrita como orientada a objetos, pipes e filtros</p><p>(componentes UNIX) ou cliente/servidor (como um fornecedor central que fornece armazenamento de arquivos e recursos</p><p>computacionais para uma rede de computadores)”. Martins (2010, p. 22) comenta que “o projetista do software precisa especificar</p><p>a estrutura do sistema, definindo e refinando os componentes que compõem a arquitetura”. A arquitetura de um sistema define</p><p>como as partes do sistema serão projetadas e agrupadas fisicamente. Ainda segundo Martins (2010, p. 139), a arquitetura pode ser</p><p>de três tipos: centrada nos dados, n-camadas ou orientada a objetos (outras podem ser hibridas). A Figura 7 apresenta um exemplo</p><p>de diagrama de arquitetura em camadas, representando a comunicação entre os componentes através de interfaces padronizadas.</p><p>Cada pacote é independente e pode ser organizado internamente em n-camadas.</p><p>Figura 7 – Arquitetura em Camadas utilizado no projeto de arquitetura.</p><p>Fonte: Martins (2010, p. 142).</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Pacote:</p><p>no UML, os elementos de um diagrama podem ser agrupados em pacotes, seguindo um critério qualquer de</p><p>agrupamento. Por exemplo, os casos de uso podem ser agrupados em pacotes segundo critérios funcionais</p><p>de negócio, os componentes de sistema também podem ser agrupados em pacotes e cada pacote poderia</p><p>ser entregue a uma equipe ou programador diferente.</p><p>Fonte: Martins (2010, p. 163).</p><p>Diagrama de pacotes:</p><p>frequentemente são usados para ilustrar a arquitetura lógica de um sistema – as camadas, subsistemas,</p><p>pacotes (no significado do Java), etc. Uma camada pode ser modelada com um pacote UML; um diagrama de</p><p>pacote fornece um modo de agrupar elementos. Um pacote UML, pode agrupar qualquer coisa: classes,</p><p>outros pacotes, casos de uso etc.</p><p>Fonte: Larman (2007, p. 223).</p><p>O Projeto de Interface</p><p>Sommerville (2011, p. 25) comenta que no projeto de interface são definidas as interfaces entre os componentes do sistema.</p><p>Pressman e Maxim (2016, p. 226) explicam que o projeto de interfaces se comunica com sistemas que operam em conjunto e com</p><p>as pessoas que o utilizam. Uma interface implica em fluxo de informações (por</p><p>exemplo, dados e/ou controle) e em um tipo de</p><p>comportamento específico. Modelos comportamentais e de cenários de uso têm usado neste modelo. Diagramas de sequência da</p><p>UML são utilizados neste modelo. A Figura 8 mostra o ciclo de desenvolvimento de uma aplicação web, na qual a atividade (2),</p><p>Especificações, gera uma representação gráfica da estrutura para a atividade (3), Design do site, e este gera um modelo de dados,</p><p>projeto gráfico (interfaces) e arquitetura do software (visto no item 3.1) para a sua implementação (codificação). O projeto de</p><p>interface está contemplado no processo de design do site (3).</p><p>Figura 8 – Ciclo de desenvolvimento de uma aplicação web.</p><p>Fonte: Miletto e Bertagnolli (2014, p. 20)</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Miletto e Bertagnolli (2014, p. 20) comentam sobre a qualidade das interfaces: é fundamental para garantir uma interação que</p><p>traga a sensação de confiança e satisfação ao usuário. Confiança no sentido de que a interface seja segura e eficaz (cumpre a</p><p>missão) e satisfação no sentido de que a interface seja agradável de usar e eficiente (cumpra a sua missão em menos tempo e com</p><p>menos custo e esforço).</p><p>Os três importantes elementos de projeto de interfaces (ou projeto de usabilidade) são: (1) a interface do usuário (UI, user</p><p>interface), que incorpora elementos estéticos ou ergonômicos, como layout, cor, imagem, navegação, etc., (2) interfaces externas</p><p>para os outros sistemas, dispositivos, redes ou outros produtores ou consumidores de informação e (3) interfaces internas entre</p><p>vários componentes do projeto (PRESSMAN e MAXIM, 2016, p. 245).</p><p>Para o desenvolvimento de uma interface com uma usabilidade eficaz e eficiente, são utilizados vários</p><p>diagramas em um projeto de interface. Um exemplo de representação de interface é através de operações</p><p>públicas visíveis externamente de uma classe, como mostra a Figura 9. Pressman e Maxim (2016, p. 246)</p><p>comentam que a Interface, chamada teclado, é apresentada como estereótipo <>. A interface é definida</p><p>sem nenhum atributo e conjunto de operações necessárias para obter o comportamento de um teclado.</p><p>Figura 9 – Representação da Interface Painel de Controle.</p><p>Fonte: adaptado de Pressman e Maxim (2016, p. 246).</p><p>O Projeto de Componentes</p><p>Segundo a UML, e mencionado por Martins (2010, p. 22), o componente é “uma parte modular, [é a parte física], possível de ser</p><p>implantada e substituível de um sistema que encapsula, implementa e exibe um conjunto de interfaces [realização de interfaces]”,</p><p>em outras palavras, componentes são blocos que compõem a arquitetura do software e se comunicam entre si com outros</p><p>sistemas e entidades. Exemplos de componentes: executáveis, bibliotecas, tabelas, documentos etc. Os tipos de componentes</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>seriam: base de dados, ficheiro ou fonte de dados, documentos, biblioteca estática ou dinâmica e componente executável em um</p><p>nó. Para Pressman e Maxim (2016, p. 247), o projeto de componente para software descreve completamente os detalhes internos</p><p>de cada componente de software. Para tanto, o projeto no nível de componente define estruturas de dados para todos os objetos</p><p>de dados locais e detalhes algorítmicos. Os possíveis diagramas da UML que poderiam atender o projeto de componentes no</p><p>modelo de projeto seriam: diagramas de componentes, classes de projeto, diagramas de atividade e diagramas de sequência. A</p><p>Figura 10 mostra um exemplo de diagrama de componentes utilizado no projeto de componentes, além da organização e as</p><p>dependências entre componentes, destacando a implementação estática do sistema. Este diagrama está relacionado com as</p><p>classes e interfaces (MARTINS, 2010, p. 138).</p><p>Figura 10 – Diagrama de componentes usado no projeto de componentes.</p><p>Fonte: Martins (2010, p. 163).</p><p>O Projeto de Banco de Dados</p><p>Sommerville (2011, p.26), relata que o projeto de Banco de Dados projeta as estruturas de dados do sistema e como eles devem</p><p>ser representados em um banco de dados.</p><p>Um projeto de banco de dados envolve (1) análise de requisitos, atividade contemplada na fase de especificação do software; (2)</p><p>projeto lógico, composto por diagramas de modelo de dados conceitual que mostra os dados e seus relacionamentos, através do</p><p>diagrama DER (diagrama entidade relacionamento), Figura 11, ou UML (diagramas de classe);</p><p>Figura 11 – Exemplo de modelo conceitual.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Fonte: Heuser (2009, p. 26).</p><p>e (3) um modelo lógico de nível de abstração visto pelo usuário do SGBD (Sistemas Gerenciador de Banco de Dados) como mostra</p><p>a Figura 12. Para Heuser (2009, p. 27), “o modelo lógico descreve a estrutura do Banco de Dados, [... onde os] detalhes de</p><p>armazenamento interno de informações, que não tem influência sobre a programação de aplicações do SGBD, mas podem afetar o</p><p>desempenho das aplicações”. Este exemplo é representado no diagrama das Figuras 12 e 13, na forma entendível para a geração de</p><p>tabelas e campos para o banco de dados, mais próxima ao entendimento do SGBD. Na Figura 13, Mannino (2008, p. 157) mostra o</p><p>diagrama de classe que contém classes (grupos de objetos), associações (relacionamentos binários) entre classes e características</p><p>dos objetos (atributos e operações). O digrama de classe apoia a modelagem orientada aos objetos, fornecendo uma alternativa às</p><p>notações de DER.</p><p>Fig. 12 – Modelo Lógico de Banco de Dados.</p><p>Fonte: Heuser (2009, p. 27).</p><p>Figura 13 – Diagrama de Classe Simples.</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>Fonte: Mannino (2008, p. 153).</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/unidade-1</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/atividades</p><p>Página inicial</p><p>ATIVIDADES</p><p>1. Para Schirigatti (2017), os processos estão vinculados às atividades e procedimentos dos funcionários ou colaboradores de uma</p><p>empresa. Esses processos são compostos de rotinas de trabalho, chamadas instruções de trabalho. Um sistema de folha de</p><p>pagamento, planejamento de controle e produção, estocagem, emissão de pedidos e demais funções, estão vinculadas aos</p><p>processos organizacionais. De acordo com este trecho do estudo sobre processos, marque a alternativa correta.</p><p>a) Os processos de gerenciamento e desenvolvimento de software do projeto geralmente possuem aderência às atividades das</p><p>áreas funcionais de uma organização.</p><p>b) Os processos de produção do software clássicos podem ser definidos como: análise e requisitos, desenvolvimento do software e</p><p>entrega.</p><p>c) Geralmente os processos de gerenciamento e desenvolvimento de software não possuem relação com as os processos das áreas</p><p>funcionais de uma organização.</p><p>d) Os processos de produção do software são definidos pelas etapas análise de projeto, desenvolvimento e testes.</p><p>2. Sommerville (2011, p. 24) comenta que a fase de especificação de software ou engenharia de requisitos “é o processo de</p><p>compreensão e definição dos serviços requisitados do sistema e identificação de restrições relativas à operação e ao</p><p>desenvolvimento do sistema”. De acordo com o comentário de Sommerville, quais são atividades da fase de especificação de</p><p>software?</p><p>a) Estudo do projeto; elicitação e análise de projeto; especificação de requisitos e validação de requisitos.</p><p>b) Estudo de viabilidade; elicitação e análise de requisitos; especificação de requisitos e validação dos testes do software.</p><p>c) Estudo de viabilidade; elicitação e análise de requisitos; especificação de requisitos e validação de requisitos.</p><p>d) Estudo de requisitos; análise das funcionalidades e validação e testes das funcionalidades.</p><p>3. Pressman e Maxim (2016, p. 225-226) afirmam que o projeto de software</p><p>está no núcleo técnico da engenharia de software e é</p><p>aplicado seja qual for o modelo de processo de software utilizado. Sendo assim, se os requisitos de software tiverem sido</p><p>analisados e modelados, o projeto de software é a última ação de engenharia de software na atividade de modelagem e prepara o</p><p>cenário para a construção (geração de código e testes). De acordo com os comentários de Pressman e Maxim, esse modelo de</p><p>processo de software pode ser:</p><p>a) Modelo de programação de software.</p><p>b) Linguagem de modelagem unificada.</p><p>c) Modelagem de requisitos unificada.</p><p>d) Linguagem de modelagem de especificação de software.</p><p>Resolução das atividades</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/atividades</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/resumo</p><p>Página inicial</p><p>RESUMO</p><p>Neste estudo sobre a metodologia de desenvolvimento de software, compreendemos o seu conceito principal. Vale a pena aqui</p><p>relembrar: “é um conjunto de atividades que auxiliam na produção de software. O resultado dessas atividades é um produto que</p><p>reflete a forma com que o processo foi conduzido”. Vimos que esse conjunto de atividades é chamado de processo de</p><p>desenvolvimento de software. Portanto, os processos de software são diversos em suas abordagens e são constituídos de fases</p><p>tradicionais, como a especificação de software, projeto, implementação e testes e também a evolução do software (manutenção).</p><p>Na fase de análise de requisitos ou especificação do software, é realizado o levantamento das necessidades do cliente para com o</p><p>software. É constituída das atividades (etapas) de: (1) estudo de viabilidade; (2) elicitação e análise de requisitos; (3) especificação</p><p>de requisitos e (4) validação de requisitos. A etapa de estudo de viabilidade é uma atividade para verificar se o sistema proposto é</p><p>viável a partir do ponto de vista de negócio e orçamentário. A etapa de elicitação de requisitos consiste da busca ou coleta de</p><p>informações, por meio de observação, documentações, discussões, etc. A etapa de especificação de requisitos consiste da</p><p>atividade de traduzir as informações obtidas durante a atividade de análise em um documento que defina um conjunto de</p><p>requisitos, como a documentação UML para um paradigma orientado a objeto. A última etapa da especificação de software é a</p><p>atividade de validação de requisitos, que assegura que todos os requisitos especificados estejam alinhados com os requisitos do</p><p>negócio. Outra importante fase do processo de software é a de projeto e implementação do software, em que se desenvolve um</p><p>plano sobre como vai ser implementado o sistema e estruturas que apoiam a resolução do problema. Essa fase é constituída das</p><p>etapas de projeto de arquitetura, projeto de interface, projeto de componente e projeto de banco de dados. Alguns autores</p><p>representam essas etapas como projeto de arquitetura e projeto detalhado. A etapa de projeto de arquitetura define as relações</p><p>entre os principais elementos estruturais de software, os estilos arquiteturais e padrões de projeto. Na etapa de projeto de</p><p>interface são definidas as interfaces entre os componentes do sistema. A etapa de projeto de componentes descreve</p><p>completamente os detalhes internos de cada componente de software, ou seja, define estruturas de dados para todos os objetos</p><p>de dados locais e detalhes algorítmicos. Por último, a etapa de banco de dados, que projeta as estruturas de dados do sistema e</p><p>como eles devem ser representados em um banco de dados. Divididas em análise de requisitos (especificação do software), projeto</p><p>lógico (diagramas de modelos de dados) e modelo lógico, que descreve a estrutura do Banco de Dados na visão dos SGBDs.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/resumo</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/eu-indico</p><p>Página inicial</p><p>Material Complementar</p><p>Leitura</p><p>Engenharia de Software: uma abordagem profissional</p><p>Autores: Roger S. Pressman e Bruce R. Maxim</p><p>Editora: Bookman</p><p>Sinopse : Com mais de três décadas de liderança de mercado, Engenharia</p><p>de Software chega à sua 8ª edição como o mais abrangente guia sobre</p><p>essa importante área. Totalmente revisada e reestruturada, esta nova</p><p>edição foi amplamente atualizada para incluir os novos tópicos da</p><p>“engenharia do século 21”. Capítulos inéditos abordam a segurança de</p><p>software e os desafios específicos ao desenvolvimento para aplicativos</p><p>móveis. Conteúdos novos também foram incluídos em capítulos</p><p>existentes, e caixas de texto informativas e conteúdos auxiliares foram</p><p>expandidos, deixando este guia ainda mais prático para uso em sala de</p><p>aula e em estudos autodidatas.</p><p>Comentário: Não há como deixar de falar e indicar uma das referências</p><p>sobre engenharia de software, Pressman, autor renomado</p><p>internacionalmente, para que seja consultado sobre as metodologias de</p><p>desenvolvimento de software. Pressman e Maxim detalham em seu livro,</p><p>de quase 1000 páginas e 39 capítulos, os modelos tradicionais e ágeis no</p><p>ciclo de desenvolvimento de software, além de diversos tópicos de</p><p>engenharia de software.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/eu-indico</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/refer%C3%AAncias</p><p>Página inicial</p><p>REFERÊNCIAS</p><p>AGUIAR, L. J. Programação em C++ : algoritmos, estruturas de dados e objetos. 2. ed. Porto Alegre: AMGH, 2011.</p><p>BROOKSHEAR, J. G. Ciência da computação : uma visão abrangente. 11. ed. Porto Alegre: Bookman, 2013.</p><p>CAMARGO, M. R. Gerenciamento de Projetos . Fundamentos e Prática Integrada. Rio de Janeiro: Elsevier. 2014.</p><p>ENGHOLM JUNIOR, H. Engenharia de software na prática . São Paulo: Novatec, 2010.</p><p>HIRAMA, K. Engenharia de software : qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2012.</p><p>HEUSER, A. Projeto de banco de dados . 6. ed. Porto Alegre: Bookman, 2009.</p><p>HORSTMANN, C. Conceitos de computação com o essencial de C++ . 3. ed. São Paulo: Bookman, 2008.</p><p>IIBA. Um guia para o corpo de conhecimento de análise de negócios (guia BABOK). versão 2.0. International Institute of Business</p><p>Analysis, 2011.</p><p>KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de Software : aprenda metodologias e técnicas mais modernas para o</p><p>desenvolvimento de software. 2. ed. São Paulo: Novatec Editora, 2007.</p><p>LARMAN, C. Utilizando UML e padrões : uma introdução à análise e ao projeto orientados a objetos e ao desenvolvimento</p><p>iterativo. 3. ed. São Paulo: Bookman, 2002.</p><p>MACHADO, R. P.; FRANCO, M. H. I.; BERTAGNOLLI, S. de C. Desenvolvimento de software III : programação de sistemas web</p><p>orientada a objetos. Bookman, 2015.</p><p>MILETTO, E. M.; BERTAGNOLLI, S. de C. Desenvolvimento de software II : introdução ao desenvolvimento web com HTML, CSS,</p><p>Java Script e PHP. Porto Alegre: Bookman, 2014.</p><p>MANNINO, M. V. Projeto, desenvolvimento de aplicações & administração de banco de dados . 3. ed. Bookman, 2008.</p><p>MARTINS, J. C. C. Gerenciamento de projetos de desenvolvimento de software com PMI, RUP e UML . Rio de Janeiro: Brasport,</p><p>2010.</p><p>PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software : Uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.</p><p>RAMOS, R. A. Treinamento prático em UML . São Paulo: Digerati Books, 2006.</p><p>REZENDE, D. A. Engenharia de software e sistemas de informação . Rio de Janeiro: Brasport, 2005.</p><p>SCHACH, S. R. Engenharia de software: os paradigmas</p><p>clássicos orientados a objetos . 7. ed. Porto Alegre: AMGH, 2010.</p><p>SOMMERVILLE, I. Engenharia de software . São Paulo: Pearson Prentice Hall, 2011.</p><p>VAZQUEZ, C. E. SIMÕES, G. S. Engenharia de requisitos : software orientado ao negócio. Rio de Janeiro: Brasport, 2016.</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/refer�ncias</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/aprofundando</p><p>Página inicial</p><p>APROFUNDANDO</p><p>Paradigma Orientado a Objeto e Clássico</p><p>Quando falamos de metodologias de gerenciamento e desenvolvimento de software, também devemos nos aprofundar em</p><p>paradigmas de desenvolvimento (modelagem e programação). Existem os paradigmas estruturados e orientados a objetos. Um dos</p><p>paradigmas atuais são os de orientação a objeto.</p><p>Para Enghom Júnior (2010, p. 116) o paradigma orientado a objeto propiciou o aparecimento de uma série de soluções:</p><p>programação OO, modelagem e design OO, bando de dados OO, interfaces OO e metodologias orientadas a objetos de</p><p>desenvolvimento de software etc. Ainda, segundo o autor (2010, p.117), o foco do paradigma orientado a objeto não está nos</p><p>procedimentos do universo, e sim nos objetos que existem nele, representando uma nova forma de descrever nossa visão</p><p>(modelagem) da realidade nos sistemas desenvolvidos.</p><p>Para Schach (2010, p. 21-22), o paradigma orientado a objeto reduz o nível de complexidade de um produto de software e,</p><p>portanto, simplifica tanto o desenvolvimento quanto a manutenção. O paradigma orientado a objeto permite reutilização; pelo</p><p>fato que de os objetos serem entidades independentes. Schach (2010, p. 22), mostra na Figura 1 e 2 uma comparação entre os</p><p>modelos de ciclo de vida do paradigma tradicional e do paradigma de orientação a objetos.</p><p>Figura 1 – Comparação entre os modelos de ciclo de vida do paradigma clássico e do paradigma orientado a objeto</p><p>Fonte: Schach (2010, p. 22).</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>Figura 2 – Diferenças entre os modelos de ciclo de vida do paradigma clássico e do paradigma orientado a objeto</p><p>Fonte: Schach (2010, p. 22).</p><p>No caso da modelagem de sistemas (fluxo de trabalho do projeto de orientação a objetos), a UML (Unified Modeling Language) é</p><p>uma linguagem unificada que auxilia na modelagem de sistemas de informação desenvolvidos no paradigma orientado a objeto</p><p>(OO) (RAMOS, 2006, p. 10). [Esta] análise orientada a objetos consiste na geração de modelos conceituais gráficos e descritivos de</p><p>um problema a ser resolvido, por meio de programação orientada a objetos. Esses modelos que representam uma realidade irão</p><p>auxiliar o programador na tarefa de implementação [...] (MACHADO, FRANCO, BERTAGNOLLI, 2015, p. 2). Em termos de</p><p>codificação (codificar as classes em uma linguagem de programação orientada a objetos), “C++ é uma linguagem multiparadigma,</p><p>suporta ambos os tipos de paradigmas [procedimental e orientada a objeto]. A grande vantagem é que é possível proporcionar a</p><p>solução que resolva melhor cada problema com o paradigma mais adequado [...]” (AGUIAR, 2011, p. 25). Segundo Engholm (2010,</p><p>p. 117), a programação orientada a objetos não apresenta a solução para todos os problemas relacionados à modelagem da</p><p>realidade, resolução de problemas e implementação de soluções/sistemas que atendam às nossas expectativas.</p><p>REFERÊNCIAS</p><p>AGUIAR, L. J. Programação em C++. Algoritmos estruturados de dados e objetos. 2a Ed. Porto Alegre. AMGH. 2011.</p><p>ENGHOLM JÚNIOR, H. Engenharia de Software na prática. São Paulo: Novatec Editora. 2010.</p><p>MACHADO, R. P.; FRANCO, M. H. I.; BERTAGNOLLI, S. DE C. Desenvolvimento de Software III: programação de sistemas Web</p><p>Orientada a Objetos. Bookman. 2015.</p><p>RAMOS, R. A. Treinamento Prático em UML. São Paulo: Digerati Books. 2006.</p><p>SCHACH, S. R. Engenharia de Software: os paradigmas clássicos e orientado a objeto. 7a Ed. Porto Alegre. AMGH. 2010.</p><p>PARABÉNS!</p><p>Você aprofundou ainda mais seus estudos!</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/aprofundando</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial/editorial</p><p>Página inicial</p><p>EDITORIAL</p><p>DIREÇÃO UNICESUMAR</p><p>Reitor Wilson de Matos Silva</p><p>Vice-Reitor Wilson de Matos Silva Filho</p><p>Pró-Reitor de Administração Wilson de Matos Silva Filho</p><p>Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva</p><p>Presidente da Mantenedora Cláudio Ferdinandi</p><p>C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância;</p><p>SCHIRIGATTI , Jackson Luis.</p><p>Metodologia Tradicional x Ágil. Jackson Luis Schirigatti.</p><p>Maringá-Pr.: UniCesumar, 2017.</p><p>34 p.</p><p>“Pós-graduação Universo - EaD”.</p><p>1. Metodologia. 2. Software 3. EaD. I. Título.</p><p>ISBN 978-85-459-1630-7</p><p>CDD - 22 ed. 006</p><p>CIP - NBR 12899 - AACR/2</p><p>Pró Reitoria de Ensino EAD Unicesumar</p><p>Diretoria de Design Educacional</p><p>Equipe Produção de Materiais</p><p>Fotos : Shutterstock</p><p>NEAD - Núcleo de Educação a Distância</p><p>Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900</p><p>Maringá - Paraná | unicesumar.edu.br | 0800 600 6360</p><p>Retornar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p�gina-inicial/editorial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa1/p%C3%A1gina-inicial</p><p>Página inicial</p><p>MODELOS</p><p>TRADICIONAIS DE</p><p>DESENVOLVIMENTO</p><p>DE SOFTWARE</p><p>Professor :</p><p>Me. Jackson Luis Schirigatti</p><p>Objetivos de aprendizagem</p><p>• Apresentar e compreender o Modelo Cascata ou Sequencial, bem como suas características, vantagens e desvantagens.</p><p>• Apresentar e compreender o Modelo Incremental ou Iteração, bem como suas características, vantagens e desvantagens.</p><p>• Apresentar e compreender o Modelo Prototipação, bem como suas características, vantagens e desvantagens.</p><p>• Apresentar e compreender o Modelo Espiral, bem com suas características, vantagens e desvantagens.</p><p>• Apresentar e compreender o Modelo RUP, bem como suas características, vantagens e desvantagens.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>Plano de estudo</p><p>A seguir, apresentam-se os tópicos que você estudará nesta unidade:</p><p>• O Modelo Cascata ou Clássico.</p><p>• O Modelo Incremental ou Iteração.</p><p>• O Modelo Prototipação.</p><p>• O Modelo Espiral de Boehm.</p><p>• O Modelo RUP - Processo Unificado Racional.</p><p>Introdução</p><p>Os processos de software são dirigidos a planos (tradicionais) ou processos ágeis. Neste estudo, vamos compreender quais são os</p><p>principais modelos do processo tradicional (clássicos) de desenvolvimento de software. Os modelos apresentados neste estudo</p><p>acomodam as atividades metodológicas fundamentais de análise de requisitos, projeto, implementação e testes, mas com ênfases</p><p>diferentes das atividades. Serão apresentados os paradigmas de desenvolvimento de software, como o modelo cascata ou</p><p>sequencial (aborda a forma linear de desenvolvimento), o modelo incremental (aborda a combinação da forma linear e paralela de</p><p>desenvolvimento), o modelo de prototipação (abordagem de conceitos e descoberta de possíveis problemas antecipados), o</p><p>modelo espiral (abordagem que combina a prevenção e tolerância a mudanças) e o modelo RUP (Rational Unifield Process), que</p><p>trabalha com uma perspectiva dinâmica, estática e prática. Veremos que todos os modelos que serão apresentados neste estudo</p><p>podem ser combinados de acordo com: o tipo de projeto (simples ou complexo), o levantamento e análise dos requisitos do</p><p>software, o tamanho da equipe de projeto, a maneira de realizar os entregáveis do projeto, a redução dos riscos envolvidos,</p><p>modelagem do sistema, feedbacks do cliente, etc. Um método que, por exemplo, combina os paradigmas de fluxos de processo</p><p>linear (modelo cascata), incremental e de reutilização é o método RUP. Nesse caso, as características dos três métodos combinados</p><p>atenderão às melhores vantagens do modelo cascata, incremental e de reutilização. Contudo, a melhor abordagem é aquela que se</p><p>adéqua às necessidades do cliente (atende os requisitos funcionais e não funcionais) e a uma produção eficiente do software de</p><p>alta qualidade com menor custo e tempo.</p><p>Avançar</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/unidade-2</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial</p><p>https://getfireshot.com</p><p>Página inicial</p><p>O Modelo Cascata ou Clássico</p><p>O modelo cascata foi exposto pela primeira vez em 1970, e consiste de atividades iterativas (que passam por várias versões), mas</p><p>não incrementais, ou seja, constituído parte por parte (SCHACH, 2010, p. 42). Segundo Sommerville (2011, p. 19), o modelo</p><p>cascata considera as atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução (sequencial e</p><p>sistemática) e representa cada uma das fases distintas, como: especificação de requisitos, projeto de software, implementação,</p><p>testes e assim por diante. Algumas vezes chamado de ciclo de vida clássico, Pressman mostra na Figura 1 o modelo cascata. Para</p><p>Pressman (2016, p. 42), o modelo cascata é o modelo mais antigo de engenharia de software, e a sua eficácia é questionável; tais</p><p>problemas são relatados como: (1) os projetos reais não seguem o fluxo sequencial proposto pelo modelo; (2) o modelo cascata</p><p>exige que o cliente estabeleça todas as necessidades no início do projeto; (3) versões não são disponibilizadas durante o projeto.</p><p>Figura 1 – Modelo Cascata.</p><p>Fonte: Pressman (2016, p. 42).</p><p>Características do Paradigma Cascata</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial</p><p>Um ponto crítico referente ao modelo cascata é que nenhuma fase é terminada até que a documentação para essa fase tenha sido</p><p>completada e os produtos desta fase tenham sido aprovados pelo grupo de SQA (Garantia da Qualidade de Software). Isso</p><p>acarreta modificações (SCHACH, 2010, p. 51), ou seja, como mostra a Figura 2, se houver alterações, o processo continuará</p><p>somente se as modificações dos documentos forem realizadas e conferidas pelo SQA. No paradigma cascata, não é formada uma</p><p>etapa de testes, pois apresenta um ciclo de vida de uma metodologia de desenvolvimento de software. Neste modelo, todas as</p><p>etapas realizam os testes e o retorno dos devidos ajustes, como um ciclo de manutenção, contínuos ao longo do processo de</p><p>desenvolvimento de software; contudo, este modelo apresenta uma fase evolucionária de manutenção pós-entrega do software,</p><p>fornecendo um feedback de manutenção.</p><p>De acordo com Pressman (2016, p. 43), hoje os trabalhos com software têm um ritmo muito acelerado e estão sujeitos a uma</p><p>cadeia de mudanças intermináveis (em características, funções e conteúdo de informações). O modelo cascata é frequentemente</p><p>inadequado para esse trabalho.</p><p>Figura 2 – O modelo de ciclo de vida completo cascata.</p><p>Fonte: Schach (2010, p. 51).</p><p>As vantagens e desvantagens do Modelo Cascata:</p><p>Sobre as vantagens do desenvolvimento em cascata, Lessa e Lessa Junior (2009, p. 2, on-line)1 comentam</p><p>que “ele permite controle departamental e gerencial. Um planejamento pode ser atribuído com prazo final</p><p>para cada estágio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento,</p><p>teoricamente e ser entregue no prazo [...]”. Sobre a desvantagem, Lessa e Lessa Junior (2009, p. 2, on-line)1</p><p>comentam que ele não permite muita flexibilidade ou revisão. Uma vez que uma aplicação está em estágio</p><p>de teste, é muito difícil retornar e mudar alguma coisa que não foi bem pesada no estágio conceitual.</p><p>Fonte: Lessa e Lessa Junior (2009, p. 2, on-line)1 .</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>O Modelo Incremental ou Iteração</p><p>O modelo Incremental, segundo Schach (2010, p. 41), utiliza um modelo de vida iterativo e incremental. A Figura 3 mostra o</p><p>desenvolvimento de um produto de software e quatro incrementos chamados incrementos A, incremento B, incremento C e</p><p>incremento D. O eixo horizontal é o eixo do tempo, e o vertical refere-se a homem-hora.</p><p>Figura 3 – Construção de um produto de software em quatro incrementos.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: Schach (2010, p. 43).</p><p>Para Pressman (2016, p. 44), o modelo incremental combina os fluxos de processo linear (modelo cascata) e paralelo dos</p><p>elementos. A Figura 4 mostra que o modelo incremental aplica sequências lineares de forma escalonada, à medida que o tempo vai</p><p>avançando. Cada sequência linear produz incrementos entregáveis de software. No eixo vertical trata das funcionalidades e</p><p>recursos do software, e no eixo horizontal trata do cronograma do projeto. Cada incremento é composto do modelo cascata</p><p>(comunicação, planejamento, modelagem, construção e disponibilização). Segundo Sommerville (2011, p. 31), em um processo de</p><p>entrega incremental os clientes identificam os serviços a serem fornecidos pelo sistema. Identificando os menos e mais</p><p>importantes, uma série de incrementos de entregas são definidos, com cada incremento proporcionando um conjunto de</p><p>funcionalidades do sistema.</p><p>Figura 4 – O modelo incremental.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: Pressman (2016, p. 44).</p><p>Características do Modelo Iterativo</p><p>Na abordagem iterativa as especificações do projeto são elaboradas em cada iteração do incremento (1..n), ou seja, as definições</p><p>dos requisitos funcionais e não funcionais do sistema (fluxo de levantamento de necessidades da engenharia de requisitos) são</p><p>levantadas a cada inicio de iteração (etapa de comunicação e planejamento) do incremento 1,2.. até o último incremento. O uso</p><p>deste modelo deve ser evitado para sistemas críticos e que envolvem equipes de trabalhos em locais diferentes, pois é</p><p>característica do paradigma incremental a iteração entre os envolvidos da equipe de desenvolvimento de software.</p><p>Vantagens e desvantagens do Paradigma Incremental</p><p>Sommerville (2011, p. 32) apresenta algumas vantagens e desvantagens do paradigma incremental. Abaixo é apresentado um</p><p>quadro resumo adaptado, Quadro1:</p><p>Quadro 1 – Vantagens e desvantagens do modelo Incremental.</p><p>Fonte: adaptado de Sommerville (2011, p. 32).</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>O Modelo Prototipação</p><p>Para Sommerville (2011, p. 30) um protótipo é uma versão inicial de um sistema de software, usado para demonstrar conceitos,</p><p>experimentar opções de projeto e descobrir sobre o problema e suas possíveis soluções. O desenvolvimento rápido e iterativo do</p><p>protótipo é essencial para que os custos sejam controlados. O modelo de prototipação é ideal para quando o cliente apenas define</p><p>alguns objetivos, sem detalhar os requisitos funcionais ou quando o desenvolvedor sente-se inseguro quanto a eficiência de algum</p><p>algoritmo. Pressman (2016, p. 45) comenta que “o paradigma da prototipação, independente da forma como é aplicado [em</p><p>qualquer processo de software], quando os requisitos estão obscuros, [...]</p><p>auxilia os envolvidos a compreender melhor o que está</p><p>sendo construído”. A Figura 5, conforme comenta Pressman (2016, p. 45), mostra o ciclo de desenvolvimento de software no</p><p>modelo prototipação, que inicia com a comunicação.</p><p>Figura 5 - O paradigma prototipação.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: Pressman (2016, p. 45).</p><p>Características do Modelo de Prototipação</p><p>A modelagem de protótipo está mais relacionada à identificação dos requisitos do software, pois é de sua característica ajudar na</p><p>elicitação e validação de requisitos de sistema. Outros autores denominam também este modelo de prototipagem rápida e de</p><p>cunho operacional. Schach (2010, p. 320) comenta, por exemplo, que se o produto desejado deve lidar com funcionalidades</p><p>financeiras, então o protótipo rápido é constituído de um produto que executa na tela a captura de dados e imprime relatórios, mas</p><p>não realiza nenhuma atualização de arquivos ou tratamento de erros. Sommerville (2011, p. 30) comenta que um protótipo</p><p>também pode obter novas ideias para os requisitos e encontrar pontos fortes e fracos do software, bem como revelar erros e</p><p>omissões dos requisitos propostos.</p><p>Vantagens e desvantagens do Paradigma de Prototipação</p><p>Sommerville (2011, p. 31) comenta que um dos problemas do modelo de prototipação é o que o protótipo pode não ser</p><p>necessariamente usado da mesma forma como o sistema final. O testador do protótipo pode não ser um usuário típico do sistema</p><p>ou tempo de treinamento é insuficiente. O Quadro 2 mostra as vantagens e desvantagens do modelo de prototipação relatadas</p><p>por vários autores.</p><p>Quadro 2 – Vantagens e desvantagens do modelo Incremental.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: adaptado de Pressman (2016, p. 46); Sommerville (2011, p. 32); Schach (2010, p. 62) e Audy e Priklandnicki (2008, p. 17).</p><p>O WSEBOK ( Software Engineering Body of Knowledge ) é um guia de conhecimento sobre a engenharia de</p><p>software que foi constituído por diversos pesquisadores, criado pelo patrocínio da IEEE ( Institute of Eletrical</p><p>and Eletronics Engineers ) e serve de referência a assuntos pertinentes à engenharia de software. Como para</p><p>o gerenciamento de projetos se tem o guia PMBOK ( Project Management Body Knowledge – boas práticas de</p><p>gerenciamento de projetos), para a engenharia de software se tem o WSEBOK. Esse guia é constituído por</p><p>10 áreas de conhecimento: requisitos de software, design de software, construção de software, testes de</p><p>software, manutenção de software, gerenciamento de configuração de software, gerenciamento de</p><p>engenharia de software, processo de engenharia de software, ferramentas e métodos de engenharia de</p><p>software, qualidade de software e disciplinas relacionadas com engenharia de software.</p><p>Fonte: o autor.</p><p>Para saber mais, acesse o link disponível em: < http://www.computer.org/portal/web/swebok/htmlformat >.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>http://www.google.com/url?q=http%3A%2F%2Fwww.computer.org%2Fportal%2Fweb%2Fswebok%2Fhtmlformat&sa=D&sntz=1&usg=AFQjCNEKw3MoLugCKJpGPEoQwPSAB6Holg</p><p>O Modelo Espiral de Boehm</p><p>Segundo Pressman (2016, p. 47), o modelo espiral é um modelo de processo de software evolucionário que une a natureza</p><p>iterativa da prototipação e os aspectos sistemáticos e controlados do modelo cascata. Sommerville (2011, p. 32) comenta que o</p><p>modelo espiral é um framework dirigido a riscos, foi proposto por Boehm (1988), em que o processo de software é representado</p><p>por uma espiral e não como uma sequência de atividades com alguns retornos de uma para outra. De acordo com Audy e</p><p>Priklandnicki (2008, p. 15), o modelo espiral é chamado também de ciclo de vida Espiral ou paradigma de Boehm, e contém um</p><p>novo elemento em seu processo, a análise de risco.</p><p>O modelo Espiral possui quatro importantes atividades relatadas por Audy e Priklandnicki (2008, p. 15):</p><p>Planejamento: determinação de objetivos.</p><p>Análise de riscos: análise de alternativas e identificação/resolução de riscos.</p><p>Engenharia: desenvolvimento do produto.</p><p>Avaliação do Cliente: avaliação dos resultados de engenharia.</p><p>A Figura 6 mostra o modelo Espiral de processo de software de Boehm, em que cada volta da espiral é dividida em quatro setores:</p><p>definição de objetivos (alternativas e restrições), avaliação e redução de riscos (identificação e resolução de riscos – AR – análise</p><p>de riscos), desenvolvimento e avaliação e planejamento (planejar próximas fases do ciclo).</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Sommerville (2011, p.33) comenta que na etapa de definição dos objetivos são definidas as restrições ao processo e ao produto,</p><p>que são idênticas. Além disso, um plano de gerenciamento detalhado é elaborado e os riscos do projeto são identificados. Nessa</p><p>etapa podem ser planejadas estratégias alternativas em função desses riscos. Para Horstmann (2009, p. 482), essas fases iniciais</p><p>focam na construção de protótipos. As lições aprendidas a partir do desenvolvimento de um protótipo podem ser aplicadas à</p><p>próxima iteração da espiral.</p><p>Na fase de avaliação e redução de riscos , Sommerville (2011, p. 33) comenta que para cada um dos riscos identificados do projeto</p><p>é feita uma análise detalhada. Medidas para redução do risco são tomadas, conforme mostra a Figura 6, na análise de riscos (AR).</p><p>Após a avaliação dos riscos é realizada a etapa de desenvolvimento e planejamento, na qual se opta pela prototipação descartável,</p><p>se os riscos forem presentes, ou utilização do modelo cascata, se o principal risco for a integração de subsistemas. Após, o projeto é</p><p>revisado e decisões são realizadas para a continuidade do modelo (SOMMERVILLE, 2011, p. 33). Portanto, no modelo espiral, a</p><p>cada volta na espiral são realizadas análises de risco, prototipagens e avaliações pelo cliente, até chegar a um protótipo</p><p>operacional, testes de aceitação e implantação.</p><p>Figura 6 – Modelo de Ciclo de Vida Espiral.</p><p>Fonte: Audy e Priklandnicki (2008, p. 18).</p><p>Características do Modelo Espiral</p><p>O Ciclo de vida de modelo espiral é atualmente uma abordagem mais realista para o desenvolvimento de softwares e sistema de</p><p>grande escala. É uma abordagem evolucionária, capacitando a equipe de projeto e o cliente a entenderem e a reagirem aos riscos</p><p>em cada etapa evolutiva da espiral (AUDY; PRINKLANDNICKI, 2008, p. 17).</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Vantagens e desvantagens do Paradigma Espiral</p><p>Para Soares e Koscianski (2008, p. 191), o modelo Espiral admite um retorno às fases anteriores, mas não suporta a ideia de</p><p>execução paralela de fases. Isso é necessário em um projeto em que se aplique concorrente, ou diferentes componentes do</p><p>produto sejam construídos de forma independente. O Quadro 3 apresenta as vantagens e desvantagens do paradigma espiral.</p><p>Quadro 3 – Vantagens e desvantagens do modelo Espiral.</p><p>Fonte: adaptado de Pressman (201, p. 46); Sommerville (2011, p. 33); Schach (2010, p. 64) e Audy e Priklandnicki (2008, p. 17).</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>O Modelo RUP – Processo Unificado</p><p>Racional</p><p>É um processo proprietário da IBM, que fornece técnicas para o desenvolvimento de software com o objetivo de aumentar o</p><p>desempenho e produtividade. O RUP usa orientações a objetivos e UML para ilustrar as ações (NEVES, 2014, p. 51).</p><p>O modelo RUP ( Rational Unifield Process – Processo Unificado Racional) é um exemplo de modelo de processo moderno (modelo</p><p>híbrido de desenvolvimento de software), derivado de trabalhos sobre a UML e o Unifield Software Development Process associado</p><p>(RUNBAUGH et al., 1999; ARLOW e NEUSTADT, 2005, apud SOMMERVILLE, 2011, p. 34). Pressman (2016, p. 56-57) chama esse</p><p>processo de Processo Unificado (PU), “é uma tentativa de aproveitar os melhores recursos e características dos modelos</p><p>tradicionais de processo de software, mas caracterizado-os de modo a implementar muitos dos melhores princípios do</p><p>desenvolvimento do desenvolvimento ágil de software”. Portanto, esse paradigma é o principio das metodologias híbridas de</p><p>desenvolvimento de software (tradicionais e ágeis).</p><p>Para Martins (2010, p. 170),</p><p>O modelo RUP, é uma simplificação da realidade que descreve o sistema a partir de certo ponto de vista, e</p><p>trabalha com os modelos da UML: (1) modelo de análise, (2) modelo de banco de dados, (3) modelo de caso</p><p>de uso, (4) modelo de implantação, (5) modelo de implementação, (6) modelo de negócio, (7) modelo de</p><p>design e (8) modelo de teste.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Para Brookshear (2013, p. 271), o RUP é essencialmente um paradigma de desenvolvimento de software que redefine os passos na</p><p>fase de desenvolvimento do ciclo de vida de software e fornece recomendações para realizar esses passos. Para Sommerville</p><p>(2011, p. 34), “o RUP reconhece que os modelos de processo convencionais apresentam uma visão única do processo”. É descrito</p><p>em três perspectivas, características do modelo RUP: (1) dinâmica, que mostra as fases do modelo ao longo do tempo; (2) estática,</p><p>que mostra as atividades realizadas no processo (workflow); e (3) prática, que sugere boas práticas a serem usadas durante o</p><p>processo (SOMMERVILLE, 2011, p. 34).</p><p>Pressman (2016, p. 57) mostra na Figura 7 que o modelo RUP inclui as atividades de concepção (comunicação com os clientes e</p><p>planejamento); a fase de elaboração inclui as atividades de comunicação e de modelagem do processo genérico. Também inclui a</p><p>fase de construção , na qual desenvolve e adquire componentes de software. A fase de transição abrange os últimos estágios da</p><p>atividade de construção e as primeiras de entrega. Por último, a fase de produção , relativa às atividades de monitoramento e</p><p>suporte do software.</p><p>Figura 7 – Processo Unificado, chamado também de RUP (o processo refinado pela IBM).</p><p>Fonte: Pressman (2016, p. 57).</p><p>Características do Modelo RUP (perspectivas)</p><p>O modelo RUP se baseia em 4Ps: Pessoas, Projeto, Produto e Processo. O RUP se sustenta em quatro pilares: gestão de requisitos,</p><p>arquitetura componentizada, avaliação da qualidade do software e gestão de mudanças do software (NEVES, 2014, p. 51). As</p><p>características principais do modelo RUP incluem, conforme já comentado por Sommerville (2011, p. 34), as perspectivas</p><p>estáticas, dinâmicas e prática, ou seja, são as atividades dos modelos genéricos, as boas práticas da especificação e do projeto e o</p><p>apoio da prototipação e entrega incremental. A Figura 8, segundo Hirama (2012, p. 40), mostra o processo unificado, as fases do</p><p>processo (concepção, elaboração, construção e transição) e os fluxos principais de trabalho (requisitos, análise e projeto,</p><p>implementação e testes), também visualizadas no Quadro 3 (workflow e sua descrição).</p><p>a. Perspectiva Estática: Martins (2010, p. 170) comenta sobre a estrutura estática , na qual os processos do RUP definem papéis,</p><p>atividades, artefatos trabalhados e os procedimentos que devem ser executados. Os processos definem “quem” está executando “o</p><p>que” e “quando”. Sommerville (2011, p. 35) mostra no Quadro 4 os workflows estáticos no RUP, a modelagem de negócios,</p><p>requisitos, análise e projeto, implementação, teste, implantação, gerenciamento de configuração e mudanças e meio ambiente.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Quadro 4 – Workflows estáticos no Rational Unified Process.</p><p>Fonte: Sommerville (2011, p. 35).</p><p>b. Perspectiva Prática: sobre a perspectiva prática do RUP, são sugeridas as boas práticas de engenharia de software</p><p>recomendadas para o desenvolvimento de software: “i. desenvolver software iterativamente, ii. gerenciar os requisitos, iii. usar</p><p>arquiteturas baseadas em componentes, iv. modelagem do software virtualmente, v. verificar a qualidade do software e vi.</p><p>controlar as mudanças do software” SOMMERVILLE (2011, p. 35).</p><p>c. Perspectiva dinâmica: para Hirama (2012, p. 42), a perspectiva está relacionada com a ordem em que às atividades devem ser</p><p>realizadas (fases). As perspectivas estáticas e dinâmicas se confundem, são vistas de forma única.</p><p>Figura 8 – Processo Unificado (Workflow e as fases do processo).</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: Hirama (2012, p. 40).</p><p>Vantagens e Desvantagens do Modelo RUP</p><p>Como vimos o RUP é uma abordagem de desenvolvimento iterativo que fornece um software de forma incremental, ou seja, possui</p><p>uma perspectiva dinâmica. O Quadro 5 a seguir apresenta as vantagens e desvantagens do Modelo RUP.</p><p>Quadro 5 – Vantagens e desvantagens do modelo RUP.</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>Fonte: adaptado de Pressman (2011, p. 46); Sommerville (2011, p. 35); e Engholm (2013).</p><p>Método de reutilização (uma das características do RUP):</p><p>Segundo Sommerville (2011, p. 23), “Na maioria dos projetos de software, há algum reúso de software. Isso</p><p>acontece muitas vezes informalmente, quando as pessoas envolvidas no projeto sabem de projetos ou</p><p>códigos, semelhantes ao que é exigido. Elas o buscam, fazem as modificações necessárias e incorporam aos</p><p>seus sistemas”.</p><p>Atualmente os processos de desenvolvimento de software aplicam a reutilização de componentes. É o caso</p><p>do método RUP que reaproveita o código já desenvolvido para o aumento da produtividade e otimização</p><p>dos recursos. Um modelo de processo geral de desenvolvimento baseado no reúso possui os estágios (1)</p><p>análise de componentes (busca de componentes para implementar uma especificação de requisitos); (2)</p><p>modificação de requisitos (modificação utilizando o componente encontrado); (3) projeto de sistema de</p><p>reúso e (4) desenvolvimento e integração (SOMERVILLE, 2011, p. 23).</p><p>Fonte: Sommerville (2011, p. 23).</p><p>Avançar</p><p>UNICESUMAR | UNIVERSO EAD</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p�gina-inicial/unidade-2</p><p>https://getfireshot.com</p><p>https://sites.google.com/fabrico.com.br/mtxa2/p%C3%A1gina-inicial/atividades</p><p>Página inicial</p><p>ATIVIDADES</p><p>1. Segundo Sommerville (2011, p. 19), o modelo cascata considera as atividades fundamentais do processo de especificação,</p><p>desenvolvimento, validação e evolução, (sequencial e sistemática) e representa cada uma das fases distintas, como: especificação</p><p>de requisitos, projeto de software, implementação, testes e assim por diante. De acordo com o trecho do nosso estudo sobre o</p><p>modelo cascata, marque a alternativa correta que contempla um ponto crítico:</p><p>a) As fases podem ser terminadas, independentemente da documentação ter sido completada e os produtos desta fase terem sido</p><p>aprovados pelo grupo de SQA.</p><p>b) Nenhuma fase é terminada até que a documentação para essa fase tenha sido completada e os produtos desta fase tenham sido</p><p>aprovados pelo grupo de SQA (Garantia da Qualidade de Software).</p><p>c) Atualmente os trabalhos com software tem um ritmo muito acelerado e estão sujeitos a uma cadeia de mudanças intermináveis,</p><p>sendo este cenário adequado à metodologia cascata.</p><p>d) O modelo cascata permite um controle departamental e gerencial. Um planejamento pode ser atribuído com prazo final para</p><p>cada estágio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento, teoricamente, e ser entregue no</p><p>prazo.</p><p>2. Na abordagem iterativa as especificações do projeto são elaboradas em cada iteração do incremento, ou seja, as definições dos</p><p>requisitos funcionais e não funcionais são levantadas a cada inicio de iteração (etapa de comunicação e planejamento). De acordo</p><p>com esta afirmativa descrita, marque a alternativa correta que apresenta as vantagens</p>dos processos (VARGAS, 2016, p. 5). A Tabela 1, 
adaptada de Vargas (2016), mostra as principais comparações do PMBOK x PRINCE 2 x SCRUM: 
https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando
https://getfireshot.com
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial
Tabela 1- Comparações do PMBOK x PRINCE 2 x SCRUM 
Fonte: adaptado de Vargas (2016, p. 48) e Angelo (2008). 
REFERÊNCIAS 
VARGAS, L. M. Gerenciamento ágil de projetos em desenvolvimento de software: um estudo comparativo sobre a aplicabilidade do 
Scrum em conjunto com PMBOK e/ou PRINCE2. Revista de Gestão e Projetos (GeP). v. 7, n. 3, set./dez. 2016. 
ANGELO, A. S. Entendendo o PRINCE2. Revista Mundo PM - Project Management. Pr. 2008. Disponível em: < 
http://www.mundopm.com.br/noticia.jsp?id=264 >. Acesso em: 9 out. 2017. 
PARABÉNS! 
Você aprofundou ainda mais seus estudos! 
Avançar 
https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando
https://getfireshot.com
http://www.google.com/url?q=http%3A%2F%2Fwww.mundopm.com.br%2Fnoticia.jsp%3Fid%3D264&sa=D&sntz=1&usg=AFQjCNEIUOMiEh9M_abvEO2XU_fOC9HQAg
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial/editorial
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/aprofundando
https://getfireshot.com
Página inicial 
EDITORIAL 
DIREÇÃO UNICESUMAR 
Reitor Wilson de Matos Silva 
Vice-Reitor Wilson de Matos Silva Filho 
Pró-Reitor de Administração Wilson de Matos Silva Filho 
Pró-Reitor Executivo de EAD William Victor Kendrick de Matos Silva 
Presidente da Mantenedora Cláudio Ferdinandi 
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ . Núcleo de Educação a Distância; 
SCHIRIGATTI, Jackson Luis. 
Metodologia Tradicional x Ágil. Jackson Luis Schirigatti. 
Maringá-Pr.: UniCesumar, 2017. 
30 p. 
“Pós-graduação Universo - EaD”. 
1. Metodologia. 2. Software 3. EaD. I. Título. 
CDD - 22 ed. 006 
CIP - NBR 12899 - AACR/2 
Pró Reitoria de Ensino EAD Unicesumar 
Diretoria de Design Educacional 
Equipe Produção de Materiais 
Fotos : Shutterstock 
NEAD - Núcleo de Educação a Distância 
Av. Guedner, 1610, Bloco 4 - Jardim Aclimação - Cep 87050-900 
Maringá - Paraná | unicesumar.edu.br | 0800 600 6360 
Retornar 
UNICESUMAR | UNIVERSO EAD 
https://sites.google.com/fabrico.com.br/mtxa4/p�gina-inicial/editorial
https://getfireshot.com
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial
https://sites.google.com/fabrico.com.br/mtxa4/p%C3%A1gina-inicial