APS - Engenharia de Software

Prévia do material em texto

Centro Universitário das Faculdades Metropolitanas Unidas 
Engenharia de Software 
 
 
 
 
Relatório Técnico 
 
 
 
 
Ailson Rodrigues da Silva RA: 6296339 
Gustavo Toshio Almeida Ueyama RA: 6795647 
Prince Neto RA: 6639050 
 
 
 
 
 
 
 
São Paulo 
Novembro 2020 
 
 
Introdução: 
 
 
 
Nesse relatório técnico irei apresentar diferentes tipos de modelos tradicionais, sendo eles 
Cascata, Espiral e RUP abordando como funcionam suas características, vantagens e 
desvantagens, comparativo entre o Cascata e o Espiral relacionando ao RUP. E sobre o 
AGILE, o manifesto ágil e modelos ágeis de desenvolvimento e também quais modelos de 
desenvolvimento são utilizados nas grandes empresas. 
 
 
Modelo Queda d’Água (Cascata / Waterfall) 
Dispensa apresentações. É o mais conhecido e mais simples/intuitivo. Todas atividades do projeto 
executas em série, ou seja, cada etapa só inicia após a conclusão da anterior. 
 
Modelo de desenvolvimento Waterfall (cascata) 
 
Engenharia de Sistemas (planejamento): Adquirir uma visão geral do sistema a ser 
desenvolvido, incluindo hardware, software, equipamentos, pessoas envolvidas etc.). É 
uma fase de planejamento, mas chamei esta etapa de “Engenharia de Sistemas” pois é 
mencionado assim por muitos autores. 
Análise de Requisitos: Definição dos requisitos de software (detalhamento das 
funcionalidades que ele vai possuir). Define O QUE será desenvolvido, sem definir 
exatamente como. Este trabalho é de suma importância para as demais etapas (por 
motivos óbvios: antes de desenvolver código/programação é necessário saber em 
detalhes o que desenvolver). Se você não entendeu, pense que podemos definir que o 
cliente deverá fazer um cadastro com Nome, CPF e Telefone, mas não vamos definir aqui 
se será um formulário usando a tecnologia X ou Y nem se isso será salvo em um Banco 
Oracle, MySQL etc. São regras de negócio / necessidades do mundo real onde devemos 
tentar abstrair a parte tecnológica e mapear os detalhes de cada necessidade. 
Projeto: Definição de como os requisitos da etapa anterior serão construídos. Aqui 
definimos quais tecnologia usaremos (Java, ASP.Net, Oracle, MySQL), quais frameworks 
(Spring, Struts etc.), qual arquitetura (MVC etc.) e demais questões técnicas antes de 
começar o desenvolvimento. Obviamente alguns projetos já nascem com algumas destas 
questões mapeadas (o cliente pode pedir Java por exemplo, porque já tem outros projetos 
nesta linha). Mesmo assim esta etapa deve formalizar todas estas questões. 
Codificação: É o desenvolvimento / programação. Nas etapas anteriores ocorreram 
somente atividades de planejamento ou especificação. Aqui o software é construído de 
fato. Esta atividade engloba destes o desenho das telas (design e criação do HTML) até a 
programação na linguagem nos moldes definidos na etapa de Projeto. 
Testes e Integração: Onde o programa obtido será submetido a uma bateria de testes 
para verificar e corrigir. Esta etapa envolve alguma codificação em função dos eventuais 
bugs descobertos que serão corrigidos aqui. 
Operação e Manutenção: Onde o software está em produção sendo utilizado pelos 
usuários. Em função do surgimento de novas necessidades ou atualizações tecnológicas 
poderá ser necessário dar manutenção, o que envolve a realização de Codificação nesta 
etapa. 
Atenção para o fato de cada empresa pode definir o seu processo de desenvolvimento de 
software. Portanto este modelo Modelo Queda d’Água (Cascata / Waterfall) pode sofrer 
variações e ainda ser chamado de Modelo Queda d’Água, pois a 
principal característica deste modelo é a execução sequencial das atividades. 
Modelo de Prototipação 
É um conceito diferente. Cria um protótipo que simula o software final funcionando com 
base nos requisitos básicos do sistema. Busca contornar algumas das limitações 
existentes no modelo Queda d’Água (como por exemplo descobrir durante a Codificação 
que um requisito mapeado anteriormente na fase de Análise de Requisitos é inviável de 
construir). O cliente poderá contemplar o protótipo e solicitar mudanças de escopo antes 
de desenvolver todo o software. Para isto, é necessário executar um “miniprojeto” antes 
do projeto, selecionado requisitos essenciais e executando as etapas de Análise de 
Requisitos, Projeto, Codificação e Testes para eles. Estas etapas podem ser executas de 
forma superficial durante o protótipo, pois o foco é simular o software de forma básica. É 
normal o protótipo ser insuficiente, pois seus esforços são concentrados na interface do 
usuário. 
 
Modelo de desenvolvimento em Protótipo 
 
Mode de Desenvolvimento Iterativo 
Cada incremento vai adicionando ao sistema novas capacidades funcionais, até a 
obtenção do sistema final. Busca contornar algumas das limitações existentes no modelo 
Queda d’Água e combinar as vantagens do modelo Prototipação. É como executar vários 
“miniprojetos” onde cada um adiciona novas funcionalidades no software final até que ele 
esteja completo. A metodologia mais conhecida no momento que segue deste modelo é 
a SCRUM. 
 
Modelo de Desenvolvimento Iterativo 
 
Modelo Espiral 
Principais características são a análise de risco e prototipagem. É interativo, mas os 
primeiros ciclos são de planejamento, depois de especificação de requisitos, depois de 
especificação/projeto de software, e nos ciclos finais são de desenvolvimento. Problemas 
em um clico remetem a repetir o anterior. As interações iniciais do projeto são as mais 
baratas, permitindo que as tarefas de maior risco sejam levadas com o mínimo de custos. 
Este modelo é complexo de executar e requer experiência. 
 
 
 
 
 
 
 
A história do surgimento do Manifesto Ágil 
Em meados dos anos 2000, um grupo de pessoas influentes da comunidade do Extreme 
Programming se reuniu para discutir diversos pontos que envolvem o processo de 
desenvolvimento de software com XP (Extreme Programming).Nessa reunião, foram 
levantadas questões como os efeitos da burocratização do processo e o excesso de 
formalização com documentações presentes no Extreme Programming. Naturalmente, 
então, inseriu-se no debate os benefícios de novos métodos que eram contrários a essa 
formalização exagerada, os chamados métodos leves (Lightweight Methods). O resultado 
foi que os presentes perceberam que havia um espaço comum entre os dois métodos, que 
deveria ser observado mais de perto. Assim, um dos integrantes do grupo Robert Cecil 
Martin, conhecido como Tio Bob resolveu convidar os interessados para uma segunda 
reunião e, assim, se aproximar desse espaço comum. Ocorrida no estado americano de 
Utah, nos dias 11 a 13 de fevereiro de 2001, essa segunda reunião se tornou um marco 
para os profissionais da área de gestão de projetos, e contou com a presença de 17 
pessoas muito influentes nesse setor. No decorrer do debate, foi verificado um consenso 
sobre os fatores importantes no desenvolvimento de software e, assim, todos decidiram 
que valia a pena registrar tais questões em um documento. Aqui, aliás, vale lembrar que 
essa não era a intenção inicial dos presentes, mas se tornou inevitável quando eles 
perceberam que estavam lidando com algo grande, e que deveria ser tratado como tal. 
Assim, ali mesmo, eles elaboraram um documento que se tornou um divisor de águas para 
o setor: O Manifesto para o Desenvolvimento Ágil de Software, mais conhecido como 
Manifesto Ágil ou Agile. Esse documento, que reúne um conjunto de valores e princípios, 
teve como principal objetivo nortear as ações das equipes ágeis, mantendo-as focadas no 
que realmente agrega valor tanto para o projeto quanto para o cliente. Baseado em 12 
princípios, ele se tornou uma espécie de guia que orienta as ações, as escolhas de métodos 
e ferramentas dos times ágeis de projetos, maximizando os resultados. Foi uma verdadeira 
revolução! Para ter uma real dimensão do impacto e do peso do Manifesto, basta pensar 
que além de RobertCecil Martin, nomes como Jeff Sutherland e Ken Schwaber fundadores 
do Scrum estavam entre os dezessete signatários. Também estavam presentes nessa 
reunião: Jim Highsmith, Kent Beck, Arie van Bennekum, Alistair Cockburn, Mike Beedle, 
Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Robert C. Martin, 
Steve Mellor, Ward Cunningham, Brian Marick, Ken Schwaber, Jeff Sutherland e Dave 
Thomas. 
 
Os quatro valores do Manifesto Ágil 
Um ponto que merece destaque sobre o Manifesto para o Desenvolvimento Ágil de 
software é que ele se firmou sobre quatro valores, e doze princípios. O objetivo desses 
fundamentos era mostrar para os profissionais do setor quais eram os fatores valorizados 
https://www.projectbuilder.com.br/blog/e-possivel-desenvolver-novos-produtos-com-metodos-ageis/
por essas pessoas presentes na reunião, ajudando outros profissionais a fazer o mesmo. 
Assim, definiram como mais importante a se valorizar: Indivíduos e a interação entre eles, 
mais que processos e ferramentas; 
- Software em funcionamento, mais que documentação abrangente; 
- Colaboração com o cliente, mais que negociação de contratos; 
- Responder a mudanças, mais que Na prática, esses valores informam que os 
profissionais devem saber da importância dos itens à direita, mas que os itens à esquerda 
possuem maior peso para o processo. Ou seja, eles creditam mais valor ao produto e ao 
processo. 
Os doze princípios do Manifesto Ágil 
Além dos quatro valores instituídos, firmou-se ainda um conjunto de abordagens de 
desenvolvimento de softwares que pode ser apresentado por meio de 12 princípios. A saber: 
PRINCÍPIO 1: valor 
“A maior prioridade está em satisfazer o cliente por meio da entrega adiantada e contínua 
de software de valor. “O principal objetivo das equipes ágeis não é entregar um produto 
final, segundo determinados requisitos, mas entregar valor para o cliente. Ou seja, entregar 
uma solução que traga os melhores resultados. Na prática, isso implica na priorização da 
felicidade do cliente, de sua satisfação. E essa nova forma de ver representou uma quebra 
de paradigma para o setor, pois passou a ser mais importante desenvolver um crescimento 
orgânico do software. Trocando em miúdos, o desenvolvimento passou a ser incremental, 
a partir das necessidades observadas do dia a dia, não mais apenas do briefing inicial. Esse 
princípio lembra a máxima do marketing: entender para atender. O próximo princípio trará 
mais detalhes sobre sua prática. 
PRINCÍPIO 2: flexibilidade 
Processos ágeis se adéquam a mudanças, para que o cliente possa tirar vantagens 
competitivas, aceitando alterações de requisitos mesmo no fim do desenvolvimento. 
Perceba como os princípios estão interligados. Quando o primeiro princípio abre espaço 
para a satisfação do cliente, ele já abarca o segundo, que é ter um projeto flexível e passível 
de alterações. Em um mercado cada vez mais competitivo e complexo, é preciso 
desenvolver projetos de maneira flexível, para que possam sofrer alterações de acordo com 
o contexto em que a empresa está inserida e com suas necessidades, que podem mudar 
durante o desenvolvimento. Isso é, para satisfazer plenamente ao cliente, é necessário que 
o gestor do projeto tenha em mente que, se for necessário, ele terá que fazer alterações, 
inclusões, exclusões etc. Mas essa flexibilidade somente será aplicável se o projeto tiver 
uma frequência de entrega, como veremos a seguir. 
PRINCÍPIO 3: frequência 
“Entregar o software em funcionamento com frequência, seja na escala de semanas ou 
meses, dando preferência a períodos mais curtos. “Novamente, há o entrecruzamento, para 
que o projeto seja flexível e tenha como prioridade a satisfação do cliente — na prática, ele 
deverá ser entregue por partes. Cada etapa estará sujeita a validação e, por consequência, 
o produto final terá maior valor para o cliente. Lembra quando falamos de um processo de 
desenvolvimento incremental? É isso! A cada sprint concluída, o time do projeto deve 
entregar uma funcionalidade ao cliente, com total capacidade para ser utilizada desde o 
primeiro momento. Isso ajuda desde a percepção de valor até a testes e integrações com 
outros componentes do projeto. 
Princípio 4: união 
“Tanto pessoas relacionadas a negócios como desenvolvedores devem trabalhar em 
conjunto, diariamente, durante todo o curso do projeto”. O envolvimento da gestão da 
empresa é fundamental para que os projetos sejam desenvolvidos de acordo com as 
expectativas do cliente. Essa colaboração é o que permite personalizar a solução e validá-
la a cada sprint concluída. Não é à toa que um dos papéis mais importante de um time ágil 
é do Product Owner, profissional responsável por ser um representante do cliente durante 
todo o processo de desenvolvimento. 
Princípio 5: motivação 
“Para construir projetos ao redor de indivíduos motivados, é preciso dar a eles o ambiente 
e o suporte necessários, confiando que farão seu trabalho”. É fundamental que a equipe do 
projeto esteja motivada a desempenhar seu papel e tenha um ambiente adequado para 
desenvolver suas atividades, com suporte tanto na orientação das atividades quanto na 
adequação das metodologias ágeis. a figura do Scrum Master nesse princípio, certo? Ainda, 
é importante que os gestores do projeto tenham em mente que as ações para que esse 
princípio seja posto em prática são de duas frentes, igualmente importantes: manter a 
equipe motivada e subsidiar a equipe com o suporte necessário. 
Princípio 6: comunicação 
“O método mais eficiente de transmitir informações tanto externas como internas para um 
time de desenvolvimento é por meio de uma conversa cara a cara. “Se você voltar às 
demandas que iniciaram o surgimento do manifesto, perceberá que a burocratização era 
um desses pontos. Entretanto, é preciso ter em mente que o manifesto não quis excluir 
todas as formas de comunicação, mas sim otimizá-las. Isso é, identificou-se que era preciso 
cortar o exagero de documentação que engessava e atrasava o processo. Enfim, reuniões 
de planejamento de Sprint são fundamentais, sim, e fazem parte dos princípios do 
manifesto. Afinal, o registro de atividades não é tão eficaz quanto uma reunião da equipe 
do projeto para alinhar objetivos, trocar conhecimentos e planejar as próximas ações. 
Princípio 7: funcionalidade 
“Um software funcional é a medida primária de progresso “A evolução de um projeto 
desenvolvido a partir de métodos ágeis entrega de um software onal e não pela conclusão 
de atividades. Agora, resgate os primeiros princípios apresentados neste artigo: viu como 
a funcionalidade é o resultado para a união dos três primeiros, valor, flexibilidade e 
frequência? Assim, no ato do fazer no caso desenvolver softwares os princípios se imbricam. 
E isso ocorre porque o manifesto é fruto da observação do ato de fazer e da escolha das 
suas melhores maneiras. 
Princípio 8: sustentabilidade 
“Processos ágeis promovem um ambiente sustentável, com patrocinadores, 
desenvolvedores e usuários sendo capazes de manter passos constantes. “Deve-se 
construir o ambiente ideal para o desenvolvimento de projetos, com planejamento por 
iterações e envolvimento de todos os afetados pelo trabalho. Esse processo deve ser 
contínuo, e todos devem estar disponíveis para acompanhá-lo e dar o devido suporte. O 
mais importante nesse tópico é se atentar para construir algo com os recursos atuais, sem 
esgotá-los e multiplicando-os para usos futuros. 
Princípio 9: revisão 
“A contínua atenção à excelência técnica e ao bom design aumenta a agilidade. “A revisão 
constante dos requisitos técnicos como também do design permite a entrega de uma 
solução realmente alinhada aos objetivos de negócio do cliente, dispensando grandes 
mudanças no momento da entrega final. 
Princípio 10: simplicidade 
“Simplicidade é a arte de maximizar a quantidade de trabalho que não precisou ser feito”. 
Menos é mais! Como os métodoságeis dispensam boa parte de registros e outros 
documentos que comprometem o tempo da equipe, o trabalho se torna mais simples de ser 
executado. Sendo, portanto, concluído em menos tempo. Assim se garante o time do 
Market do cliente. 
https://www.projectbuilder.com.br/blog-pb/entry/conhecimentos/quais-sao-os-principais-tipos-de-metodos-ageis
Princípio 11: organização 
“As melhores arquiteturas, os requisitos e os designs emergem de times auto organizáveis. 
“Times ágeis são compostos por profissionais com a capacidade de se organizarem por si 
mesmos. Ou seja, de dividirem as tarefas e responsabilidades entre eles, sem que um 
gerente de projetos tenha que interferir. 
Princípio 12: autoavaliação 
“Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e 
otimizam seu comportamento de acordo. “Na prática, esse princípio consiste na revisão do 
trabalho realizada que, ao final de cada sprint, permite que a própria equipe avalie sua 
performance e descubra formas mais interessantes de trabalhar e agilizar todo o processo. 
A continuidade do Manifesto Ágil 
Por fim, o manifesto representou um grito de liberdade de práticas que atravancam o 
processo. No momento, era sabido que, embora dificilmente a essência (valores e 
princípios) mudasse, era necessário ter uma organização que prezasse por seu contínuo 
aperfeiçoamento e que o representasse. assim com esse propósito, no final do mesmo ano 
(2001), surgiu a Agile Alliance. A organização sem fins lucrativos se tornou responsável por 
compartilhar esse conhecimento e promover debates sobre os diversos métodos ágeis 
existentes no mundo. A discussão, bem como a própria organização, é fundamental, pois o 
Agile é como um guarda-chuva, que abarca vários métodos que se assentam sobre seus 
princípios e valores. Assim, essa contínua discussão ajuda a criar um norte para que os 
desenvolvedores de softwares saibam escolher os melhores métodos ou ferramentas. E 
você, já desenvolve essas práticas na sua empresa? Como vem percebendo os resultados? 
Se gostou desse artigo, aproveite para compartilhá-lo em suas redes sociais!