Olá sejam bem-vindos ao canal engenharia de software com ênfase o ML Eu sou professor Jenis Guedes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto eu já ministrei diversas palestras e cursos técnicos S modelagem de software utilizando a linguagem uml na aula de hoje eu vou iniciar com o tema sobre processos prescritivos então vamos iniciar a nossa aula bom eh grande parte do conteúdo apresentado nessa aula foi retirado do livro de engenharia de software do Raul vs slavik as figuras todas também foram retiradas
a partir desse material bom vamos iniciar Então primeiramente vamos fazer algumas conceituações básicas com relação a projeto de software segundo o vats slavic um projeto de software é algo que ocorre em um tempo determinado e consiste na execução concreta de um conjunto de atividades que visam a criação de um produto específico Já segundo suvel que é um outro autor da área de engenharia de software ele define projeto de software como sendo a descrição da estrutura do software a ser implementado dos modelos e estruturas de dados usados pelo sistema das interfaces entre os componentes do sistema
e às vezes dos algoritmos usados já o Roger presman um terceiro autor da área de engenharia de software ele define projeto de software como o intuito do projeto de software é aplicar um conjunto de princípios conceitos e práticas que leva o desenvolvimento de um sistema ou produto de alta qualidade o objetivo do projeto é criar um modelo de software que irá implementar corretamente todos os requisitos do cliente e trazer satisfação àqueles que o usarem bom ainda definindo alguns conceitos básicos vamos estabelecer agora os conceitos relacionados a processo de software então de acordo com vs slavic
um processo de software é o conjunto de regras que define Como projeto deve ser executado já de acordo com o Ian summerville um processo de software é um conjunto de atividades relacionadas que levam à produção de um produto de software e de acordo com o Roger presman ã um processo de software é a abordagem adaptável que possibilita as pessoas realizar o trabalho de selecionar e escolher o conjunto apropriado de ações e tarefas a intenção é a de sempre entregar software dentro prazo e com qualidade suficiente para satisfazer aqueles que patrocinaram sua criação e aqueles que
irão utilizá-lo Finalmente nós vamos falar sobre modelo de processo em Essência o modelo de processo é é abstração de um processo de software eh uma estrutura geral uma definição Geral de um processo de software que vai ser instanciado pelas equipes que forem utilizar pelas empresas que forem utilizar esse processo mas de acordo com vlab um modelo de processo é um conjunto de regras mais abstratas que especificam a forma geral de processos Já segundo su é uma representação simplificada de um processo de software cada modelo representa uma perspectiva particular de um processo e portanto fornece informações
parciais sobre ele já o presman define modelo de processo como o conjunto de atividades metodológicas e de apoio ações e tarefas a realizar cada modelo de processo pode ser descrito por um fluxo de processo diferente bom então nós fizemos algumas definições básicas necessárias para o teúdo que vai ser apresentado hoje bom eh vou falar rapidamente a respeito dos modelos de processos essencialmente há três tipos de modelos de processos os processos prescritivos os processos iterativos incrementais e os processos ágeis ou métodos ágeis na verdade ã o Roger presman ele divide os processos prescritivos em várias subdivisões
mas não vou manter a definição geral e então processos prescritivos eles são definidos como um conjunto de Fases e atividades onde eles descrevem de maneira bem definida como as atividades do processo devem ser realizadas eles estabelecem fornecem instruções específicas e detalhadas sobre o o conjunto de Passos a serem executados para atingir um determinado objetivo ou resultado ah na verdade essa definição ela é mais ou menos válida para os outros tipos de processos A diferença é que nos processos descritivos nos processos prescritivos essas as etapas as atividades e as instruções elas são mais rígidas são mais
detalhadas e exigem pelo menos no formato clássico que cada etapa seja totalmente concluída para se passar paraa etapa seguinte ah na verdade existem várias diversas variações dos processos prescritivos que eles que vão desde eh um processo bem rígido até alguns processos um pouco mais flexíveis como como a gente vai ver ao longo das aulas mas essencialmente processos prescritivos eles têm um conjunto de atividades e um conjunto de instruções e um conjunto de Passos bem definidos e enquanto que nos outros modelos processos essa rigidez não é normalmente tão eh forte bom e nós temos os processos
iterativos e incrementais os processos iterativos e incrementais eles se caracterizam por possuírem vários subciclo enquanto que nos processos prescritivos há somente um ciclo e cada etapa tem que ser totalmente concluída para se passar paraa seguinte e o software normalmente só vai ser entregue ao final de todo ciclo nos processos interativos existem vários subciclo de requisitos é enfocado em cada em cada um desses subciclo ah e o resultado desses subciclo é acrescentar novas funcionalidades ao software que agreguem valor ao cliente que possa ser utilizado por ele e ou a a melhoria de artefatos e funcionalidades ou
funcionalidades que já existiam anteriormente já os processos ágeis eles também são iterativos e incrementais Mas eles são mais flexíveis são mais pragmáticos e eles enfatizam H menos as definições das atividades embora elas ex mas se concentram mais nos fatores humanos do desenvolvimento eles incentivam uma maior interação com as partes interessadas no desenvolvimento Ok então vamos começar a falar sobre processos prescritivos primeiramente vamos falar sobre o antim modelo de processo que é o chamado codificar e consertar que é basicamente a forma como se desenvolvia tradicionalmente software e que na realidade muitas empresas muitos profissionais ainda utilizam
que basicamente é um processo em que não há um processo definido basicamente o desenvolvedor ele utiliza a própria experiência para desenvolver o software ele parte de um um entendimento preliminar das necessidades do cliente e ele passa diretamente a implementar o código ã sem fazer uma engenharia de quisito sem fazer um projeto ele implementa o código testa normalmente ele mesmo corrige o código ã apresenta para o cliente se a versão não for considerada satisfatória ele volta a implementar e corrigir o código e ele fica nesse ciclo até que o cliente considere que a versão ã existente
é ã razoavelmente ã satisfatória para uso Então esse é o processo clássico bom esse processo ele apresenta alguns problemas tá primeiramente ele se baseia num entendimento normalmente mais geral sobre os requisitos sem aprofundar sem detalhar muito esses requisitos ele vai ter uma entrevista Geral com o cliente eventualmente envolvendo alguma parte interessada mais importante e vai partir direto paraa codificação bom eh Isso é um problema grave eu sou um defensor da engenharia de requisitos eu considero que a engenharia de requisitos é a fase mais importante do desenvolvimento de software uma vez que ela estabelece claramente o
que precisa ser feito ela compreende o problema não é possível desenvolver uma solução correta sem saber o que precisa realmente ser feito qual é o problema a ser resolvido então eh partir eh para o desenvolvimento tendo apenas um entendimento preliminar ou inicial do que precisa ser feito é uma receita pro fracasso do projeto então eh Há um risco muito grande de que muita coisa não seja compreendida corretamente e também que muitas das necessidades que o cliente teria não sejam eh definidas um outro problema é que iniciar o a codificação sem ter feito uma engenharia de
requisitos sem ter feito o projeto indo direta diretamente pro código eh agrega vários problemas nessa abordagem o o desenvolvedor ele vai apresentar o software por cliente o cliente vai apresentar a possível defeitos possíveis falhas de interpretação Elas serão corrigidas reimplementado o código será apresentado por cliente vai sofrer modificações novamente várias vezes bom Como já foi falado em vídeos anteriores o código ele não se desgasta da maneira tradicional mas ele sofre desgaste à medida que ele vai sofrendo muitas alterações muitas manutenções então u utilizar essa abordagem pode fazer com que o software seja entregue já com
desgaste ou seja o código está muito remendado está muito foi alterado muitas vezes ele vai ser muito difícil de manter no futuro por exemplo mas de qualquer forma esse era o processo desenvolvimento tradicional que muita gente ainda utiliza tem muitos profissionais que se dizem ágeis mas na verdade não são ágeis o que eles utilizam é o método codificar e consertar bom Ah um dos primeiros processos a a serem propostos foi o modelo em Cascata o modelo em Cascata ele foi proposto na década de 70 Ah e ele era composto de várias eh fases bem rígidas
que produziam bastante documentação E era necessário concluir uma fase completamente para se passar para a fase seguinte mas foi um dos primeiros processos de desenvolvimento propostos e se tornou razoavelmente popular na época bom ã Então ele era composto por uma fase ou mais de uma fase de elicitação de requisitos ou levantamento de requisitos uma fase de análise de requisitos uma fase de projeto uma fase de codificação teste e operação ou implantação Ah aqui eh nesse exemplo tirado fatsl que tem em duas fases de levantamento de requisitos Mas vocês vão ver na bibliografia que muitos autores
ã ah representam somente uma fase certo mas aqui nós temos levantamento de requisitos do sistema e levantamento de requisitos de software que basicamente são requisitos mais Gerais e requisitos H um pouco mais detalhados eh depois nós temos a fase de análise onde os requisitos seriam eh analisados como o nome já diz à procura de ambiguidades e outras anomalias como os requisitos não estarem eh completos não serem fáceis de compreender possuírem conflitos esse tipo de coisa então eh essas três fases aqui seria equivalente à fase de engenharia de requisitos atual depois se passaria paraa fase de
projeto onde se pensaria na solução do do do software depois paraa fase de codificação depois para fase de testes e depois o software seria colocado em operação a certo então alguns defeitos do modelo em Cascata em muitas situações algumas atividades poderiam ser realizadas em Paralelos ã mas um dos principais defeitos é que todos os requisitos precisam ser declarados detalhadamente no no início da modelagem e nem sempre isso isso é possível muitas vezes alguns requisitos vão surgindo ao longo do processo de desenvolvimento e não é tão simples conseguir levantar todos os requisitos logo na primeira fase
porque na verdade eh levantar requisitos iniciar requisitos descobrir requisitos é uma tarefa muito difícil porque muitas vezes os clientes e as e as outras partes interessadas elas não têm uma ideia muito concreta do que eles querem elas têm um conjunto de requisit itos de ideias de necessidades vagas Nebulosas mal definidas que precisam ser ã transcritas em algo bem definido algo concreto isso não é uma tarefa fácil na verdade Muitas vezes os clientes stakeholders eles nem conseguiram conceber todas as possibilidades que o software poderia trazer para a empresa ah muitas vezes o desenvolvedor o engenheiro de
software ele precisa eh fazer uma espécie de consultoria sugerindo muitas modificações na forma como a como as informações são produzidas eh transformadas geridas e utilizadas na tomada de decisão da empresa então muitas das funcionalidades que o software poderia ter na verdade devem ser H sugeridas pelo próprio engenheiro de requisitos Ahã bom então o fato de ter que declarar todos os requisitos detalhadamente no início da modelagem pode acarretar que alguns requisitos sejam mal especificados e essa esse erro de especificação só seja descoberto quando o sistema for implantado e isso vai trazer um alto custo porque uma
coisa é identificar um erro de especificação no início do projeto outra descobrir que o requisito foi mal especificado mal definido no final após o processo ter sido após o o software ter sido totalmente codificado então o custo para se adaptar a essa a essa mudança é muito alto ã e também um outro problema é que o software só é implantado no momento em que todo o ciclo tiver completo Então os problemas que esse software possa ter só vão ser realmente ertos quando for implantado no cliente mas de qualquer forma esse esse foi ah o primeiro
modelo um dos primeiros modelos de desenvolvimento propostos Ah logo em seguida quase imediatamente eh houve algumas evoluções do modelo em Cascata por exemplo eh se sugeriu então um modelo em Cascata dupla que permitia que H se retornasse a uma fase anterior quando algum erro fosse descoberto então Eh na fase de análise por exemplo no momento que um erro fosse descoberta uma anomalia nos requisitos fosse descoberta poderia se voltar paraa fase anterior também durante o projeto se Eros fossem descobertos se poderia se poderia voltar paraa fase de análise por exemplo e assim sucessivamente então diminuía um
pouco ã que um erro uma falha de interpretação fosse ser descoberto somente quando o software tivesse sido completamente implementado mas ainda assim não resolvia o problema não resolvia totalmente o problema porque o software realmente o software final só é entregue quando ele tiver sido desenvolvido completamente então às vezes se percebia que houve um erro de interpretação quando o cliente passava a utilizar o software O problema é que eh nós não falamos a mesma língua na minha opinião nós falamos dialetos semelhantes Eu costumo dizer que eh as terminologias os termos utilizados variam muito de área para
área de região para região às vezes de faix etária para faixa etária então um termo pode ter um significado em uma área e ter outro termo completamente pode ter um significado bem diferente em outra isso pode causar erros graves de interpretação isso para o desenvolvimento de software pode causar problemas graves porque pode chegar no final do desenvolvimento e se descobrir que se compreendeu errado um requisito porque a terminologia tinha significados diferentes do da área para o qual o software se destinava Então embora o modelo em Cascata dupla tenha sido uma solução tenha melhorado um pouco
a descoberta de erros ele ainda não resolveu o problema ah Aqui nós temos um exemplo de modelo em Cascata na prática porque muitas vezes não basta voltar simplesmente paraa fase anterior às vezes é necessário voltar várias fases atrás quando alguma falha algum erro foi descoberto Então a partir do projeto do programa eu posso ter que pode posso ter que voltar pro levantamento de requisitos software e a partir do teste eu posso ter que voltar pro projeto tá se for encontrados erros de projeto na fase de testes ou durante a fase de projeto eu encontre erros
de especificação de requisitos por exemplo Ahã o o rice um Provavelmente o autor que eh desenvolveu que criou modin Cascata Ele mesmo fez Algumas propostas para melhorar a estabilidade do moden em Cascata ele sugeria por exemplo que se inserisse uma fase de design entre levantamentos requisitos e A análise dos requisitos para que eh requisitos eh referentes às limitações físicas do sistema pudessem ser adicionados ele também eh sugeria produzir documentação de qualidade porque ele percebeu que muitas vezes a documentação produzida durante o levantamento análise projeto era fraca então ela não ajudava realmente na fase de codificação
então ele preconizava que a documentação tinha que ser tinha que ter uma alta qualidade e ele já propunha que se fossem aplicadas inspeções naquele naqueles documentos gerados ele também propunha que o software entregue eh fosse a segunda versão produzida eh que a primeira versão fosse uma experiência que era uma boa sugestão Mas demandava bastante tempo e ele propunha também que fosse aplicados testes sistemáticos que fossem realizados por especialistas que eh fossem independente dos desenvolvedores que não estivessem envolvidos no desenvolvimento do software mas que fossem especializados ã em testar aquele o o software eles fosse especializ
tivessem fosse especializados em planejar controlar e monitorar os testes e ele também o ry também ioniza o envolvimento forte do cliente e das partes interessadas durante o desenvolvimento do software uma uma proposta que é bastante dotada pelos métodos ágeis bom depois houve uma evolução para o modelo en Cascata entrelaçado também chamado modelo sashimi porque a figura lembrava um prato japonês então no modelo modelo cascato entrelaçado Ah não era necessário terminar totalmente uma fase para já se iniciar outra então muitas vezes o algumas fases podiam ser executadas em Paralelos então nós tínhamos uma fase de concepção
do software que definia a viabilidade de desenvolver o software e começava o levantamento dos requisitos mas antes dela ser concluída já se passava para fase de análise e especificação de requisitos da mesma forma a fase de análise antes de ser concluída já produzia um projeto de arquitetura que foi uma evolução grande uma evolução importante em relação aos modelos em Cascata anteriores e uma vez que a saída da análise de requisitos deve ser um projeto de arquitetura que vai ser aperfeiçoado durante o projeto detalhado eh Na verdade o projeto da arquitetura costuma ser uma fase intermediária
entre análise e projeto e ela define a estrutura o esqueleto do software se baseia fortemente nos requisitos não funcionais eh identificados durante a durante a concepção e análise requisitos e a arquitetura em particular é algo que não é flexível a mudanças ela tem que ser escorrida com muita seriedade porque modificar a arquitetura causa altos custos do projeto Às vezes o projeto precisa ser totalmente abandonado e como começar de novo se forse mexer na arquitetura depois eh antes da do da arquitetura ser totalmente definida já se passava para projeto detalhado ã antes do projeto detalhado ser
totalmente concluído Já se passava para codificação e depuração e antes do código testid totalmente totalmente desenvolvido já se realizavam testes testes de sistema então isso permitia ã uma menor quantidade de documentação e uma maior interação entre as subquente uma fase para iniciar a outra as duas equipes poderiam as duas eh então algumas vantagens do modelo sashimi era que uma fase só estará completa depois que forem consideradas questões referentes à fase seguinte então isso permitia que fossem eh gerados ganhos de conhecimento e a documentação diminuía Já que as equipes conversavam mais as equipes envolvidas em fases
diferentes elas trabalhavam juntas então não era necessário tanta documentação porém alguns problemas Embora tenha sido uma evolução Ah o entrelaçamento o modelo encascado entrelaçado não era totalmente suficiente ã já que o término e o início das fases também não estava explícito Então se tornava mais difícil estabelecer Marcos Marcos ess estabelecem os finais de uma fase e que artefatos que produtos devem ser entregues em cada fase além disso a realização de atividades paralelas poderia levar a Fas de comunicação a aceitação de hipóteses erradas e a ineficiência do no trabalho mas foi uma evolução bastante importante depois
se passou ao modelo em v o modelo em V ele trabalhava fortemente com verificação e validação Então ele era chamado modelin V porque ele tinha esse formato em V então ele definia uma fase de requisitos uma fase de projeto arquitetural uma fase de projeto detalhado uma fase de implementação após isso se passava paraa fase de teste de unidade que verificava o projeto detalhado uma fase de teste de integração que verific a fase de projeto arquitetural e uma fase de teste sistema em que se verificava se o software realmente atendia aos requisitos do sistema então ele
trabalhava fortemente com verificação e também um pouco de validação do do software desenvolvido então a principal vantagem como falado possui esse processo ele possui uma forte ênfase em verifica e validação Porém tem algumas desvantagens eh nesse modelo os requisitos só vão ser realmente verificados e validados quando o software tiver sido finalizado ã as mudanças dos requisitos ainda continuam tendo um alto custo já que os eh os requisitos só são verificados no final e ele exige muita documentação e documentação de qualidade senão não é possível aplicar testes eh realmente precisos realmente corretos a partir da depois
houve a uma nova evolução que foi o modelo emw onde os testes eram preparados eh já durante as fases em que os documentos eram produzidos então durante a fase de requisitos eram preparados testes de sistema durante a fase de projeto arquitetural eram preparados testes de integração durante a fase de projeto detalhado eram preparados os testes de unidade depois passava para codificação e possíveis alterações Ah E aí se executavam testes testes de unidade eram feitas depurações então poderia se voltar paraa fase de codificação realizar mudanças depois se executava um teste de integração que poderiam gerar depurações
e poderia se voltar paraa fase de codificação e mudança e depois eram executados testes sistemas onde nova ente se produziam depurações se fosse necessário e se poderia voltar paraa fase de codificação e mudança então dos métodos prescritivos o modelo inw é na minha opinião um dos que tem mais qualidades então eh ele tem várias vantagens os testes são planejados durante a construção eh eventualmente a execução dos Testes se for encontrados erros obviamente vai implicar em reconstrução ele tem a vantagem de trabalhar com conceitos testáveis só conceitos testáveis são aceitos então eles partem do do princípio
que se os requisitos eles não podem ser testados então eles têm problemas se eu não consigo imaginar um teste para um requisito então eu não consegui definir esse requisito corretamente então o requisito não é aceitável e isso vale também para a arquitetura e o projeto então o modelo emw foi uma forte evolução uma evolução poderosa do modelo em Cascata eh então o modelo inw ele envolvia especialistas em testes desde o início do projeto Então isso permitia que mais erros pudessem ser detectados logo no início eh já que já se imaginava os testes para aqueles requisitos
logo no começo e também diminuía a complexidade dos projetos porque ao imaginar a forma de testar se percebia que algo estava complexo demais se trabalhava para simplificar Então esse era o modelo que tinha muitas vantagens depois houve o modelo cascata com subprojetos que já trabalhava com H ciclos Paralelos é quase um antecessor dos processos interativos e incrementais Então nesse trata construir projetos havia uma fase de concepção do do software onde se determinava a viabilidade do software se levantava os requisitos havia uma fase de análise requisitos notem que era possível voltar paraa concepção do software e
havia uma fase de projeto arquitetônico onde se definia a arquitetura que como eu falei é uma fase muito importante que tem que ser feita com muita seriedade porque ela é de alto risco ã a partir da arquitetura definida se passava para ã vários subprojetos então havia os requisitos eles eram divididos em várias o software integrado se passava paraa operação então cascata com subprojetos também é uma grande evolução do modelo em Cascata clássico vantagens Então esse tipo de abordagem permite que subprojetos ã mais rápidos e fácil de gerenciar sejam realizados Ah explora muito mais as potencialidades
de modularidade do projeto e o progresso costuma ser h mais claro você consegue perceber o o o progresso do software de forma mais clara Ah é possível Ah fazer várias entre entregas de eh funcionalidades do software na medida em que elas ficarem prontas desvantagens ah às vezes não é possível eh fazer esse paralelismo porque podem haver interdependências entre os subsistemas Então se um subsistema depende de algum módulo de outro subsistema isso pode atrasar ou mesmo impedir que seja feito esse desenvolvimento paralelo o projeto arquitetônico ele precisa ser muito bem feito mas isso é válido para
qualquer processo de software tá no caso do cascata com subprojetos isso era Tornado bem explícito o projeto arquitetônico precisava ser feito de maneira muito com muita seriedade para que que ah os diversas as os diversas funcionalidades que fossem feitas ah desenvolvidas em paralelo pudessem ser Integradas na arquitetura do software Tá mas um projeto arquitetônico bem feito é uma necessidade basicamente qualquer processo de software ah Exige uma grande capacidade de gerência para que não haja inconsistências entre subsistemas tem que ser um gerente experiente E no momento de integrar todos os subsistemas isso podia causar alguns problemas
eh se não tivesse se as interdependências entre esses entre esses subsistemas não tivessem sido gerenciados de forma adequadas isso podia causar problemas Ah e é isso nós terminamos essa primeira aula sobre processos prescritivos logo nós iremos tratar da segunda parte Y
