Aps- Engenhria de software 1

Prévia do material em texto

Centro Universitário Das Faculdades Metropolitanas Unidas
Anderson Lopes Cazita
RA:3931175
Gabriel Santos Leite de Sousa
RA:3841220
Gabriel Vitor Viana De Brito 
RA:3877253
Jonatas dos Santos Eugenio 
RA:5889868
Luiz Flavio Mizozoe de Amorim
RA: 5828145
Engenharia de Software
Modelos de Software
São Paulo, 2020
Anderson Lopes Cazita
Gabriel Santos Leite de Sousa
Gabriel Vitor Viana De Brito 
Jonatas dos Santos Eugenio 
Luiz Flavio Mizozoe de Amorim
Engenharia de Software 1
Modelos de Softwares
 Avaliação Prática Supervisionada-APS, trabalho
apresentado para disciplina de Engenharia de Software 1
para o Curso de Análise e Desenvolvimento de Sistemas
da faculdade, Centro Universitário das Faculdades Metropolitanas
Unidas, sob orientação do professor Celso Eduardo Guimarães 
São Paulo,2020
Introdução 
Este trabalho tem como objetivo conceituar os principais modelos de Software, traçar um comparativo entre eles, conceituar o modelo AGILE e elaborar um comparativo entre o AGILE e Comparativo, iremos falar sobre os ciclos iterativos e incremental. 
Índice
1. Modelo Cascata 
2. Modelo Espiral 
3. RUP
4. Manifesto Agile
4.1. O que é o manifesto Agile?
4.2. Como surgiu o manifesto Agile?
4.3. Os valores do Ágil?
4.4. Os princípios do manifesto Agile 
 
1. Modelo Cascata 
O modelo cascata é utilizado principalmente quando os requisitos de um determinado problema são bem compreendidos. Uma forma de utilizar o modelo cascata é quando precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Por exemplo quando temos um sistema já pronto precisamos fazer uma adaptação porque alguma lei governamental foi alterada ou criada.
Podemos utilizar o modelo cascata quando um software necessita de uma nova funcionalidade e os requisitos estão bem definidos e são estáveis. 
O modelo cascata também é chamado de ciclo de vida clássico ou tradicional.
Este modelo sugere uma abordagem sequencial e sistemática para o desenvolvimento de software. Dessa forma, começamos com levantamento de requisitos ou necessidades junto ao cliente, depois vamos para fase de planejamento onde definimos estimativa, cronograma e acompanhamento, após isso partimos para modelagem onde fazemos a análise e projeto, seguindo da construção onde codificamos e testamos, passamos para implantação ou emprego efetuamos a entrega, suporte e feedback do software concluído. 
Basicamente na etapa de levantamento de requisitos ou necessidades estabelecemos junto aos clientes os requisitos do produto desejado pelo cliente que consiste dos serviços que devem ser fornecidos, limitações e objetivos do software. Esta etapa também consiste da documentação e o estudo da viabilidade do projeto para determinarmos o processo de inicio de desenvolvimento do projeto do sistema. Na etapa de planejamento temos a definição de estimativas, cronograma e acompanhamento baseando se nos requisitos e na determinação das tarefas que, por sua vez, são determinadas pelos requisitos. A etapa de modelagem é uma prévia da próxima etapa de construção, nesta etapa define-se as estruturas de dados, arquitetura do software, interfaces, etc. A etapa de construção abrange a implementação, onde os programas são efetivamente criados e também os testes é onde testam as lógicas internas de software e as funcionalidades externas. As funcionalidades internas normalmente são realizadas com uso de testes unitários e fases externas podem ser realizadas por testadores e pelo próprio cliente. Por fim, a etapa de emprego ou implantação abrange a entrega efetiva do software no cliente que é onde instalamos o software no servidor ou na máquina do cliente junto com outros utilitários como banco de dados ou outros itens dependendo do software sendo construído. O suporte é onde tiramos dúvidas dos clientes e a manutenção consiste na correção de erros não eram nem foram previamente detectados.
O modelo Cascata possui algumas variações como o “modelo V”. Este modelo pode ser visto na 2 figura acima. 
Este modelo descreve a relação entre as ações da garantia da qualidade (representado no lado direito da figura) e as ações associadas à comunicação, modelagem e atividades de construção. O modelo é seguido de cima para baixo a partir do lado esquerdo, ou seja, possuirmos um software executável efetivamente subimos no modelo. Não existe diferença entre o modelo V e o modelo tradicional. O modelo V apenas enfatiza uma forma de visualizar como a verificação e as ações de validação são aplicadas ao trabalho de engenharia como são realizadas do lado esquerdo.
O modelo Cascata é o paradigma mais antigo da engenharia de software. Porém, mesmo sendo bastante antigo e ainda utilizado na indústria esse processo recebe muitas criticas que gerou questionamentos sobre a sua eficácia até mesmo pelos seus maiores defensores.
Os principais problemas encontrados no modelo cascata são:
· Os projetos de software reais construídos e evoluídos na indústria de software raramente seguem o fluxo sequencial que o modelo prega. Apesar de que esse modelo em forma sequencial possa conter interações, onde poderíamos passar diversas vezes pelas mesmas atividades, ele faz indiretamente. Como o resultado tem-se que mudanças podem provocar bastante confusão na medida em que a equipe de projeto prossegue.
· É muito raro e difícil para o cliente saber e estabelecer explicitamente todas as suas necessidades. O modelo cascata é muito fortemente baseado nisso e tem dificuldade para adequar a incerteza natural que existam no início do projeto.
· O cliente precisa ter muita paciência, o que raramente acontece, o que raramente acontece. Uma versão operacional (pronta para ser executada no cliente) não estará disponível até estarmos próximo ao final do projeto se tivermos um erro grave nas etapas iniciais, como uma especificação mal compreendida e mal especificada, podemos ter um resultado desastroso.
Outro grande problema que temos com os projetos que usam modelos cascata é o bloqueio que existe em alguns membros da equipe que precisam esperar os outros completarem as suas tarefas para que eles possam dar sequencia ao trabalho. O tempo gasto nessa espera pode exceder o tempo gasto em trabalho produtivo que levaria à conclusão do projeto. Estudos mostram um estado de bloqueio tende a prevalecer no inicio e no final do processo sequencial linear. Um exemplo clássico disso é a brincadeira das moedas. Imagine temos 5 moedas de 10 centavos na mão esquerda e faremos uma rodinha com 5 pessoas sendo que existe uma cadeira ao lado de cada pessoa para que possamos colocar as moedas já lançadas. Cada pessoa deve pegar uma moeda da sua mão esquerda com sua mão direita e atirar a moeda pra cima e deixar a moeda cair na mesma mão direita, após isso colocamos a moeda na cadeira ao lado. Após lançarmos todas as moedas e colocarmos na cadeira ao lado o próximo colega deve pegar essas cinco moedas deixadas pelo colega anterior. Agora vamos recomeçar a brincadeira e o colega deve lançar as moedas, sem precisar esperar que as cinco moedas estejam disponíveis. Calcule o tempo gasto nas duas brincadeiras. Veremos que há uma boa diferença quando não precisamos esperar até que cada um realize toda a atividade para que possamos começar o trabalho. Temos um grande ganho de produtividade.
Atualmente também temos um ritmo bastante acelerado no desenvolvimento de software e estamos cada vez mais sujeitos a uma cadeia de mudanças que são intermináveis que surgem desde necessidades do negócio, necessidades dos clientes até exigências impostas por leis governamentais. O modelo Cascata é inapropriado para este trabalho. Como dito anteriormente o modelo cascata é útil apenas em situações onde os requisitos são fixos e o trabalho deve ser todo finalizado de forma linear.
Vantagens
· Torna o processo de desenvolvimento estruturado. Tem uma ordem sequencial de fases. Cada fase cai em cascata na próxima e cada fase deve estar terminada antesdo início da seguinte;
· Todas as atividades identificadas nas fases do modelo são fundamentais e estão na ordem certa.
· Esta abordagem é atualmente a norma e provavelmente permanecerá como tal nos próximos tempos.
 Desvantagens
· Não fornece feedback entre as fases e não permite atualização ou redefinição das fases anteriores 
· Não suporta modificações nos requisitos 
· Não prevê a manutenção 
· Não permite a reutilização 
· É excessivamente sincronizado
· Se ocorrer um atraso todo processo é afetado 
· Faz aparecer o software muito tarde
 
2. Modelo Espiral 
O objetivo do modelo espiral é prover um metamodelo que pode acomodar diversos processos específicos. Isto significa que podemos encaixar nele principais características dos modelos vistos anteriormente, adaptando-os as necessidades especificas de desenvolvedores ou às particularidades do software a ser desenvolvido. Este modelo prevê a prototipação, desenvolvimento evolutivo e cíclico, e as principais atividades do modelo cascata.
Sua principal inovação é guiar o processo de desenvolvimento gerado a partir deste metamodelo com base em análise de riscos e planejamento que é realizado durante toda evolução do desenvolvimento. Riscos são circunstancias adversas que podem surgir durante o desenvolvimento de software impedindo o processo ou diminuindo a qualidade do produto. São exemplos de riscos: pessoas que abandonaram a equipe de desenvolvimento, ferramentas que não podem ser utilizadas, falha em equipamentos usados no desenvolvimento ou que serão importantíssimas no desenvolvimento de software devido a imaturidade da área e à falta de conhecimento, técnicas e ferramentas adequadas.
O modelo espiral descreve um fluxo de atividades cíclico e evolutivo constituído de quatro estágios 
· No estágio 1- devem ser determinados objetivos, soluções alternativas e restrições.
· No estágio 2- devem ser analisados os riscos das decisões do estágio anterior. Durante este estágio podem ser construído protótipos ou realizar-se simulações do software.
· No estágio 3-consiste nas atividades da fase de desenvolvimento, incluindo design, especificação, codificação e verificação. A principal característica é que a cada especificação que vai surgindo a cada ciclo - especificação de requisitos, do software, da arquitetura, da interface de usuário e dos algoritmos e dados - deve ser feita a verificação apropriadamente. 
· O estágio 4- compreende a revisão das etapas anteriores e o planejamento da próxima fase. Neste planejamento, dependendo dos resultados obtidos nos estágios anteriores - decisões, análise de riscos e verificação, pode-se optar por seguir o desenvolvimento num modelo Cascata (linear), evolutivo ou Transformação. Por exemplo, se já no primeiro ciclo, os requisitos forem completamente especificados e validados pode-se optar por seguir o modelo Cascata. Caso contrário, pode-se optar pela construção de novos protótipos, incrementando-o, avaliando novos riscos e replanejando o processo.
Vantagens 
· Desenvolvimento repetida ou contínua ajuda na gestão de riscos. Os desenvolvedores ou programadores descrever as características com alta prioridade em primeiro lugar e, então, desenvolver um protótipo baseado sobre estes. Mudanças Este protótipo é testado e desejada são feitas no novo sistema. Esta abordagem contínua e constante minimiza os riscos ou as falhas associadas com a alteração no sistema.
· Adaptabilidade no projeto do modelo em espiral em engenharia de software acomoda qualquer número de mudanças, que podem acontecer, durante qualquer fase do projeto.
· Desde que o edifício protótipo é feito em pequenos fragmentos ou bits, a estimativa de custo torna-se mais fácil e o cliente pode ganhar o controle sobre a administração do novo sistema.
· Como o modelo continua em direção a fase final, a experiência do cliente no novo sistema cresce, permitindo bom desenvolvimento das necessidades do cliente reunião produto.
Desvantagens 
· Modelo espiral precisa de habilidade extensa na avaliação de incertezas ou riscos associados ao projeto e sua redução.
· Avaliar os riscos envolvidos no projeto podem disparar o custo e pode ser maior que o custo para a construção do sistema.
· Há uma exigência para mais explicações das etapas envolvidas no projeto, tais como avanço, blueprint, postos de controle e procedimento padrão.
 
3.RUP
O RUP, de propriedade da IBM, é um framework de processo da engenharia de software que fornece práticas testadas na indústria de software e gerência de projetos. Por ser um framework de processo, pode ser customizado conforme as necessidades organizacionais e do projeto, dessa forma, pode-se trabalhar um RUP mais “leve e ágil” ou “mais pesado”.
O RUP permite que a equipe do projeto escolha as atividades e os artefatos para serem produzidos, reduzindo assim, o excesso de documentação para torná-lo mais ágil. Outra característica interessante dele é a aplicação do modelo de ciclo de vida iterativo e incremental. Na metodologia iterativa, em cada iteração, parte do software é desenvolvida, sendo os artefatos da nova iteração superior à iteração anterior. O desenvolvimento iterativo e incremental permite aos desenvolvedores o aprendizado em relação ao software, possibilitando assim, a localização de futuros problemas em fases iniciais.
O RUP é descrito a partir de três perspectivas. Na perspectiva dinâmica, o RUP identifica o ciclo de desenvolvimento do projeto em quatro fases sequenciais sendo, cada fase, finalizada por um marco principal. As fases do RUP são iniciação, elaboração, construção e transição. A Figura 1 apresenta as fases do RUP.
A iniciação, também conhecida como concepção, é a fase em que se estabelece o escopo do projeto de software, levantando-se uma visão geral do produto final. A iniciação tem como objetivo estabelecer o escopo, detalhar os casos de uso crítico do software, estimar o custo, os riscos e preparar o ambiente para o projeto. Se o projeto for de pouca importância ou inviável, ele pode ser cancelado após essa fase.
Na elaboração, identificam-se os casos de uso principais e elaboram-se o sistema em iterações. A elaboração tem como objetivo garantir que a arquitetura, os requisitos e os planos estejam estáveis, que os riscos identificados sejam reduzidos, permitindo a criação de protótipos e estabelecer um ambiente de suporte.
A construção é a etapa do desenvolvimento do software. Nela, produzem-se o código fonte do produto na linguagem de programação escolhida pela equipe do projeto. Os objetivos principais da construção compreendem reduzir os custos da implementação, obter a qualidade, concluir a análise, o design, a implementação e os testes das funcionalidades necessárias, desenvolver o produto de software, bem como, verificar se as funcionalidades foram finalizadas e se os usuários estão prontos para receber o sistema em ambiente de produção.
A transição é a fase final do RUP. Nela, ocorre a validação e a entrega definitiva do software para o cliente. Essa etapa normalmente inclui a entrega do sistema, teste beta para validação das funcionalidades, conversão de bancos de dados operacionais, treinamento com os usuários, ajustes no sistema e a avaliação do produto.
A perspectiva estática do RUP enfoca as atividades que acontecem no processo de desenvolvimento. Elas são denominadas workflows na descrição do framework. O RUP oferece seis workflows de processos principais e três workflows de apoio principais. Os workflows estão representados na Figura 2.
Vantagens 
· Processo robusto e bem definido com a geração de artefatos importantes;
· Os maiores riscos são atacados primeiro, diminuindo as chances de fracasso do projeto.
Desvantagens 
· Complexo e trabalhoso para projetos de pequeno porte;
· Exige experiência da equipe.
4.Modelo Agile 
4.1. O que é o manifesto Agile?
Para entender a Agile, primeiramente é importante ressaltar que ela se trata de uma filosofia que serve como base para as metodologias como XP, Kanban e Scrum. 
O manifesto Ágil declara 4 valores e 12 princípios pradesenvolvimento ágil de softwares.
4.2. Como surgiu o manifesto Agile?
Sua história começou na primavera do ano 2000 em Oregon, quando um grupo de líderes da comunidade do Extreme Programming se juntou para debater as relações entre o XP e os Lightweinght Methods (Métodos Leves) que eram os métodos de desenvolvimento de software em ascensão na época do burocrático modelo cascata dos métodos clássicos apesar de concluírem que o método XP era melhor enquanto método específico, concordaram que havia um gap entre o XP e os lightweinght Methods.
Robert Cecil Martin, conhecido como Tio Bob, que esteve presente na reunião de Oregon, decidiu organizar uma nova reunião com pessoas com um interesse em comum: os métodos leves neste evento, os 17 participantes iniciaram a propagação do paradigma de desenvolvimento ágil de softwares.
Os consensos sobre aspectos importantes em desenvolvimento de software foram documentados, e serviram como ferramenta de expressividade dos novos métodos de desenvolvimento de software e desencadearia o manifesto ágil então, após avaliar diversas possibilidades, definiram “Agile” como a palavra que nomearia esta nova abordagem.
O manifesto Ágil passou a ser um grito de guerra, não apenas para aquelas 17 pessoas, mas também para a indústria de software.
4.3. Os valores do Ágil?
A 4 valores fundamentais no manifesto agile e eles são: Mais interações entre indivíduos do que processo e ferramentas Mais software em funcionamento do que documentação abrangente Colaboração com o cliente acima da negociação de contrato Adaptabilidade é mais importante do que seguir um plano.
4.4. Os princípios do manifesto Agile 
O manifesto agile possui 12 princípios que são: Priorizar a satisfação do cliente por meio de entregas contínuas de valor; Ser receptivo à mudanças de requisitos em qualquer etapa do processo Fazer entregas frequentes, com o menor intervalo de tempo possível Trabalho em conjunto dos desenvolvedores de software e pessoas de negócios em todo o projeto Oferecer  o ambiente e suporte necessários á pessoas, além de confiar nelas para  executar as tarefas Manter uma comunicação pessoal, e que transmita as informações necessárias à equipe de desenvolvimento, é o método mais eficiente A medida primária de progresso é o software funcionando As pessoas envolvidas no processo devem ser capazes de manter um ritmo constante indefinidamente. Pois processos ágeis promovem um desenvolvimento sustentável Manter uma atenção constante à excelência técnica e de design aumenta a agilidade Cortar o máximo de esforços que não agregam valor ao produto, a simplicidade é essencial Times auto organizáveis desenvolvem as melhores arquiteturas e designs Regularmente, a equipe reflete sobre como aumentar sua eficiência e eficácia para aprimorar seu comportamento.