Olá sejam bem-vindos ao canal engenheria de software com ênfase uml Eu sou professor Janes gedes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livos publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou dar continuidade ao tema processos prescritivos Então vamos iniciar esse conteúdo Ok então eu vou começar falando sobre o modelo em espiral H antes de mais nada é importante falar que muito do material aqui representado foi eh inspirado nos
livros do summerville e do vs slavic então Eh eu vou falar sobre modelo em espiral que apesar de ele ser eh dividido em vários ciclos ele ainda é considerado um modelo prescritivo Na verdade o modelo em espiral ele é um modelo fortemente focado em analisar e mitigar a ocorrência de riscos e ele utiliza H outros processos de desenvolvimento de acordo com a os requisitos identificados então ele identif ele escolhe um processo de desenvolvimento mais adequado para cada situação bom então ele é é composto de diversos ciclos no primeiro ciclo se faz um estudo de viabilidade
para tentar verificar se vale a pena realmente desenvolver o software o segundo ciclo corresponderia à engenharia de requisitos o terceiro ciclo corresponderia ao projeto o quarto ciclo eh trabalharia com projeto mais detalhado codificação e testes e assim vai então em todos eles tem uma forte análise de riscos e tenta-se verificar alternativas para impedir que o risco ocorra ou caso ele ocorra que o impacto dessa ocorrência seja menor Então logo no primeiro ciclo se faz uma análise de risco se produz um prot tipo Inicial se tem uma ideia da operação e se for viável eh for
considerado viável desenvolver o software se faz um plano de requisitos e um plano de ciclo de vida já se estabelece Qual é o processo mais adequado processo de desenvolvimento mais adequado para o problema em questão aí se passa paraa fase seguinte onde eh são feitas a feita uma nova análise de riscos se passa para um segundo protótipo um pouco mais detalhado se produzem simulações se faz o levantamento e análise de requisitos eh se estabelece como esses requisitos serão validados se cria um plano de desenvolvimento ã se passa por um novo ciclo se faz uma nova
análise de requisitos eh se faz novos protótipos se produzem modelos que vão ser utilizados pelo na prod do projeto H também se cria um projeto de verificação e validação do produto se cria um plano de testes e um plano de integração eh em cada um desses ciclos também se determina eh alternativas para as possíveis restrições que ocorram eh sobre esse produto eh depois é feito uma nova análise de risco se faz um novo projeto um novo protótipo um protótipo mais operacional se faz uma análise de mercado para ver eh possíveis produtos concorrentes se trabalha num
projeto detalhado se passa para codificação e se fazem testes de unidade teste de integração teste de aceitação e se passa para implantação do software eventualmente pode se planejar uma próxima fase ou uma e uma nova evolução do software Eh ok então como já foi falado eh e cada laço na espiral ela representa uma fase do processo de software o o laço mais interno estabelece a viabilidade de desenvolver o software o lá seguinte vai corresponder à engenharia de requisitos Ah o lado seguinte ao projeto e assim sucessivamente vai ver projeto detalhado vai em seguida vai passar
paraa implementação bom ah o modelo espiral ele possui quatro etapas para cada um dos seus ciclos A primeira é a definição de objetivos onde se estabelece os objetivos específicos para fase do projeto para Aquela fase do projeto se for ã engenharia de requisitos projeto etc se identificam as possíveis restrições para aquele processo e o para o produto que está sendo eh desenvolvido se prepara um plano de gerenciamento detalhado de maneira a gerenciar o desenvolvimento do do software gerenciar os riscos eh se identificam os riscos do projeto e possíveis estratégias alternativas para eh contornar esses riscos
depois é feito uma avaliação e redução desses riscos então para cada risco identificado é feita uma análise detalhada e a partir daí se toma evidências para reduzir esses riscos são criados planos de contingência eh de maneira a mitigar o impacto que esse risco possa causar depois é feito o desenvolvimento e validação eh se escolhe como foi falado um modelo de desenvolvimento para aquele sistema de acordo com eh o tipo de software que está sendo desenvolvido de acordo com os requisitos não funcionais daquele software Então se escolhe qual o processo de desenvolvimento é mais adequado para
aquele software particular então como eu falei o modelo espiral não é o único não é um não é um modelo de processo de desenvolvimento eh único Ele trabalha com outros processos dentro dos seus ciclos Ah então considera-se os tipos de riscos mais com maior probabilidade de ocorrência e se foca mais neles depois na fase seguinte na etapa seguinte é feito o planejamento o projeto ele é revisto e se decide se deve se continuar para o próximo laço ou se o software deve ser concluído ou eventualmente abandonado vantagens do modelo espiral ele identifica muitos riscos Logo
no início logo nas primeiras interações então isso permite que os riscos sejam contornados e e mitigados ou eventualmente se se criem planos de contingência H Logo no início então nessas as primeiras interações são mais baratas eh o tempo e os recursos Ainda são amplos para eh fazer o contorno desses riscos ah na medida que os custos vão aumentando os riscos costumam diminuir E se o projeto não puder ser concluído por razões técnicas ou limitações de orçamento ou limitações de prazo etc então normalmente isso vai ser descoberto H cedo então isso são vantagens ainda possui fase
bem definidas e isso permite um acompanhamento do desenvolvimento bastante objetivo e ele modelo espiral ele é adequado a projetos que são complexos que possuem um alto risco de falha por exemplo por justamente porque por ele ser complexo por por os requisitos serem não se conseguir medir totalmente a a complexidade dos requisitos e os requisitos são pouco conhecidos e o esforço para eh levantar esses requisitos analisar esses requisitos é muito grande desvantagens eh não existe uma indicação Clara para a equipe eh sobre a quantidade de trabalho esperada para cada ciclo então o tempo de desenvolvimento principalmente
nas primeiras fases pode ser difícil de prever ã Exige uma gerência bastante eficaz a gerência a gerência desse tipo de processo costuma ser complexa então o gerente tem que ser experiente tem que ser bastante eficiente porque o movimento com complexo entre as várias fases ao longo das várias interações da espiral é bastante difícil exige muita eficiência por parte do gerente exige bastante experiência ã e esse esse tipo de modelo ele não é recomendado para projetos de eh porte pequeno ou médio e que os requisitos sejam bem conhecidos e nós temos uma variação do modelo em
cascata com redução de risco que utiliza o conceito eh de espiral Então como o modelo espiral Ele trabalha muito com a redução de riscos Então se aplica esse modelo espiral a ao modelo em Cascata Então ele pode ser qualquer variação do modelo em Cascata Então se aplica um modelo ã fortemente focado em riscos principalmente antes das fases de levantamento e ou análise de requisitos mas na verdade eu posso aplicar uma fase de redução de riscos em antes de qualquer fase do modelo em Cascata ã então o objetivo de aplicar o conceito do ã do modelo
em espiral junto com o modelo em Cascata é tentar ã diminuir a possibilidade que os requisitos sejam mal definidos então tenta-se Eh com essa aplicação da da União do modelo espiral com modelo em Cascata que os requisitos sejam bem definidos ah nas fases iniciais Então antes do início do processo em Cascata se acrescenta uma fase de redução uma fase de redução de riscos e se aplica diversas técnicas para tornar os requisitos mais estáveis e como eu falei eu posso criar eu posso eu posso inserir uma fase Extra de redução de riscos antes de qualquer fase
do projeto aliás antes de qualquer fase do processo antes da análise antes do projeto antes da codificação antes dos Testes Se isso for considerado necessário eh algumas técnicas utilizadas Essa não é uma lista exaustiva podem ser utilizadas outras técnicas são desenvolver protótipos de interface com com um usuário para que os requisitos sejam melhor compreendidos e a arquitetura correta seja adotada ah criar storyboards com usuário apresentando imagens para descrever cenários e situações de uso do sistema conduzir tantas entrevistas quanto necessários com os usuários e clientes filmar os usuários para compreender como o trabalho funciona realmente e
aplicar diversas outras técnicas para identificação de requisitos como tempestade cerebral grupo focal etc um outro ã modelo de de ã processo de desenvolvimento é o desenvolvimento evolucionário ou incremental em que se é feita uma descrição do esboço do software e se executam várias atividades concorrentes onde se é feita especificação desenvolvimento e validação do produto e se produzem várias versões uma versão Inicial diversas versões intermediárias até atingir a versão final eh Então esse processo ele desenvolve uma implementação Inicial expõe o resultado ao usuário e de acordo com o parecer do usuário se faz aprimoramentos produzindo diversas
versões até que o software seja considerado adequado eh Então em vez de ter atividades de especificação desenvolvimento e validação separadas todo esse trabalho é realizado de forma concorrente com retorno rápido do do cliente das partes interessadas o problema do desenvolvimento evolucionário é que muitas vezes ele pode eh se tornar o desenvolvimento clássico de desenvolver e testar bom então Existem algumas variações existe o desenvolvimento evolucionário exploratório e existe o desenvolvimento ário com protótipos descartáveis então no desenvolvimento evolucionário exploratório h o objetivo é trabalhar fortemente com cliente eh a fim de forma que os os requisitos sejam
bem definidos e que se entregue eh logo um sistema eh final concluído ã então o desenvolvimento ele se inicia com várias entrevistas com várias eh interações com as partes interessadas eh não desculpe e o desenvolvimento ele se inicia com as pes do sistema que são compreendidas ã e depois o sistema ele vai evoluindo com acréscimo de novas características na medida que elas são propostas pelo cliente Ahã já o desenvolvimento evolucionário com protótipos descartáveis o nome já diz são gerados muitos protótipos então o objetivo é com compreender os requisitos do cliente na verdade a técnica de
prototipação é muito utilizada para compreender os requisitos do cliente não somente no desenvolvimento evolucionário mas em outras em outros processos e a partir desses protótipos se desenvolve uma melhor compreensão dos requisitos então O protótipo ele se concentra em auxiliar a na compreensão dos requisitos na medida em que são feitos experimentos com patos requisitos que estejam mal compreendidas Então se apresenta os protótipos pros stakeholders paraas partes interessadas e se faz as modificações necessárias a partir dos pareceres que eles fornecerem Ahã eventualmente o desenvolvimento evolucionário ele pode ser mais eficaz que o modelo em cascata no momento
que ele atende as necessidades de forma mais imediata dos clientes gera menos documentação a especificação ela pode ser desenvolvida gradativamente já é um precursor dos ã modelos ágeis ou modelos interativos incrementais E no momento que os usuários eles desenvolvem uma compreensão melhor do dos problemas então isso vai se refletir no software em termos que novos requisitos vão ser identificados requisitos anteriores H vão sofrendo modificações bom mas desvantagens esse processo ele possui várias desvantagens e as três principais são as mais graves então sobre a perspectiva de Engenharia e de gerenciamento os três problemas são o progresso
ele não é visível ah os gerentes eles para saberem se o processo tá realmente evoluindo a contento eles precisam de alguma maneira medir o o progresso do software e isso é muito difícil de fazer adotando esse processo de desenvolvimento um outro problema eh como os sistemas eles costumam ser desenvolvidos rapidamente então a não é produzido muita documentação basicamente são produzidos só protótipos então Eh muitas versões do sistema acabam ficando somente no código ou somente em protótipos e não tem documentação de apoio para ela isso pode levar ao desgaste rápido do software em termos de muitas
modificações sem atualização da documentação sem refatoração correta Ah E isso também é uma está relacionado com com o terceiro problema que o software é muitas vezes mal estruturado e ele tá ele muitas vezes ele já é entregue com desgaste ou seja ele a estrutura do software ele sofreu foi corrompida pelas constantes alterações então isso faz com que fazer modificações no s software se torne cada vez mais complexo mais difícil e mais caro então esse tipo de de processo de desenvolvimento evolucionário é pouco melhor que o processo de desenvolvimento ã desenvolver e corrigir tá então para
sistemas pequenos e talvez de médio embora isso já seja bem mais arriscado essa abordagem ela pode ser em algum situações uma alternativa talvez em situações em que o prazo seja muito curto mas ela é uma alternativa muito arriscada no momento em que o software ele já pode ser entregue com muito desgaste muito ele pode ter sido ter sofrido muitas alterações e essas alterações esse código não foi refatorado de forma adequada não possui documentação para apoiar evoluções então para sistemas de grande porte e que o tempo de desenvolvimento é muito longo essa abordagem é totalmente inviável
Ah nós temos uma evolução dessa abordagem que é a prototipação evolucionária em que ela se trabalha com protótipos mais sérios protótipos que são levar são desenvolvidos com eh maior seriedade Então ela trabalha com uma fase de concepção da Concepção Inicial Depois ela faz ela passa por uma fase de projeto implementação do protótipo Inicial E aí se testa O protótipo não é aceitável então ele é refinado e ele fica nesse ciclo até ele ser considerado aceitável se o protótipo é aceitável então o software é finalizado e o produto é liberado bom ã essa técnica de prototipação
evolucionária ela se baseia na na técnica de prototipação corner Stone que são protótipos desenvolvidos com mais seriedade com bastante planejamento e com mais cuidado então O protótipo ele vai ser parte do sistema final ele vai evoluindo até que o software ele possa ser entregue Ahã ele preconiza que a equipe trabalha com cliente e outras partes interessadas os aspectos que são mais visíveis do software basicamente em termos de interface e vão ser produzidos então vários protótipos até que o produto seja aceitável vantagens quando o cliente ele tiver dificuldades em comunicar os seus requisitos O que é
bastante frequente esse modelo esse esse processo de desenvolvimento pode ser útil ã também situações em que nem equipe nem o cliente conhecem bem os requisitos então a prototipação evolucionária pode ser vantajosa nessas situações porém ã tem várias desvantagens ela é é difícil de prever o tempo de desenvolvimento eh como já foi falado o gerente Tem dificuldades em saber o se o processo está seguindo a contento ou não ah Além disso o projeto ele é difícil de gerir porque ã é difícil identificar quando a quando C da fase foi realmente concluída E como eu falei esse
tipo de processo ele pode acabar se tornando o modelo codificar e consertar Ah é preciso garantir que o processo ele realmente ele Identifique as necessidades do sistema e devem ser os requisitos eles devem sofrer uma análise e produzir um projeto realista antes de realmente se iniciar a codificação e é isso nós terminamos a primeira a segunda fase do do tema de processos prescritivos eu espero que essa aula tenha sido eh adequada tenha sido útil para vocês eu agradeço a atenção e nós nos vemos na próxima aula
