Olá sejam bem-vindos ao canal engenharia de software com ênfase ml Eu sou professor ganes Gets e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando linguagem uml na aula de hoje eu pretendo dar continuidade ao tema de processos prescritivos então vamos iniciar a nossa aula então esta é a terceira e última aula sobre processos prescritivos então nós vamos ver mais alguns processos classificados com os prescritivos já alguns processos um pouco mais
eh evoluídos um pouco mais avançados em relação ao modelo Cascata tradicional Então nós vamos começar com o processo entregas em estágios novamente muito do conteúdo desta aula foi tirado foi inspirado no livro de engenheiria de software do professor Raul vlavi e também do Ian Samille principalmente esses dois foram as minhas as minhas principais fontes de consulta bom então vamos falar um pouquinho sobre o modelo de entregas em estágios Então esse modelo ele procura entregar ah várias funcionalidades ir entregando várias funcionalidades aos clientes a a partir de cada ao final de cada iteração embora ele seja
considerado um processo prescritivo esse modelo já pode ser considerado também um precursor dos modelos iterativos e incrementais e também dos modelos ágeis ah basicamente ele consiste numa fase de concepção inicial para entender os requisitos e determinar a viabilidade de desenvolver o software uma fase para análise de requisitos onde os requisitos serão melhor detalhados uma fase de projeto arquitetural como eu já disse em aulas anteriores o projeto arquitetural é muito importante e ele normalmente é uma saída da fase de análise de hum da fase de análise requisitos ele deve ser uma saída da fase de análise
requisitos uma vez que a análise requisitos ela identifica os requisitos não funcionais que influenciam fortemente no projeto arquitetural eh depois se parte para vários ciclos iterativos eh Aqui nós temos uma anotação a iteração inicia com um essa barra é uma anotação umr e significando que isto é o resultado de um cálculo então depois do projeto projeto arquitetural bem definido se parte para o projeto detalhado o projeto detalhado ele vai sendo aperfeiçoado ao longo das interações depois de o projeto detalhado de parte dos requisitos se passa para codificação e depuração depois para o teste depois para
entrega da funcionalidade desenvolvida ou melhorada naquele ciclo de interação E aí se volta se verifica não é o final do ciclo projeto não tá acabado Então se inicia uma segunda iteração né aqui vai Aqui tem uma Fórmula I = I + 1 quer dizer que eu estou calculando a se a a nova o novo valor da iteração o novo número da iteração por assim dizer então se o projeto não estiver acabado se volta ao projeto detalhado se codifica teste entrega mais uns mais um conjunto de requisitos e se procede assim até o final do do
processo então vocês podem perceber que esse modelo se assemelha bastante com os processos interativos incrementais atuais Mas ainda é considerado um processo prescritivo eh uma evolução do modelo em Cascata bom então vantagens do processo de entregas em estágios então a cada ciclo a equipe planeja e sabe o que vai entregar eh o cliente ele vai ter um acompanhamento melhor da evolução do sistema os gerentes também já que vão haver várias entregas sucessivas Ah já permite que o cliente vá utilizando o sistema uma vez que eh esse processo ele fornece funcionalidades que podem ser utilizadas antes
do projeto ter sido concluído e se os estágios forem bem planejados então o o cliente ele vai receber funcionalidades importantes ã logo nos primeiros ciclos ah e também de uma forma mais cedo do que em outros processos semelhantes então ele eh provê entregas mais cedo e de forma contínua e isso pode diminuir a pressão sobre o cronograma desvantagens eh C não forem bem planejadas nos níveis técnicos de gerencial esse processo não vai funcionar adequadamente então no nível técnico eu preciso identificar quais dependências técnicas entre os diversos módulos as diversas funcionalidades precisam ser verificadas ã Então
eu preciso saber se um módulo se uma funcionalidade tem dependência sobre outro módulo se precisa de outro módulo nesse caso esse outro módulo precisa ser desenvolvido primeiro já a nível gerencial eu preciso garantir que os módulos as funcionalidades Ah eles sejam úteis para o cliente que eles agreguem valor ao sistema Então para que essa técnica possa realmente funcionar eh é necessário que os requisitos sejam bem compreendidos E o planejamento seja efetivo na verdade a compreensão dos requisitos uma compreensão bem bem correta dos requisitos eh normalmente é uma é uma necessidade para praticamente qualquer processo Ok
mas nesse em particular eles precisam ser bem compreendidos e bem planejados bom e nós temos um outro modelo que é o modelo orientado a cronograma ou processo orientado a cronograma ele é um pouco semelhante ao processo anterior também há uma fase de concepção Inicial uma fase de requisitos e uma fase de projeto arquitetural E aí se iniciam vários ciclos mas eh eles são H organizados em torno dos requisitos mais importantes Então se faz uma priorização de requisitos se especificam Quais são os requisitos essenciais Quais são os requisitos desejáveis Quais são os requisitos opcionais pode-se aplicar
uma técnica de priorização como a Moscou por exemplo e a partir do momento que os requisitos mais importantes são a agrupados Esses são eh desenvolvidos primeiro então é criado um ciclo para os requisitos considerados mais essenciais se projeta codifica testa e entrega esses requisitos E aí se faz um teste não se ainda há requisitos para desenvolver mas sim se ainda há tempo para desenvolver Então se ainda há tempo se toma mais um grupo de requisitos mais importantes que ainda não foram ã desenvolvidos e se iniciam um nov ciclo então Eh nesse tipo de modelo eu
tenho garantia ou eu tenho uma uma garantia maior de que eu vou conseguir desenvolver os requisitos essenciais para o cliente eu posso não conseguir desenvolver os requisitos todos mas os essenciais para que o software já possa ser útil para o cliente serão desenvolvidos os outros requisitos pode ser deixados com uma segunda versão por exemplo eh então h no caso desse nesse nesse modelo ele sabe que os ciclos deverão ser terminados numa data específica existe um prazo final para entrega Então eu só vou poder entregar as funcionalidades que eu consegui desenvolver até esse prazo Por isso
as funcionalidades mais importantes precisam ser priorizadas então ah eu vou ter um produto viável para o cliente então a cada iteração se desenvolve os requisitos mais importantes os requisitos que foram priorizados como essenciais desejáveis e assim vai e se encerra o projeto quando o tempo acabar ou então quando todos os requisitos tiverem sido atendidos vantagens no momento em que eu tenho programa rígido essa é uma estratégia boa porque garante que algum produto algumas funcionalidades eh essenciais estarão disponíveis terão entregues para o cliente ah desvantagens se nem todas as funcionalidades forem entregues então a equipe vai
ter perdido algum tempo analisando analisando os requisitos H nas etapas iniciais mas considerando a a pressão do cronograma isso ah é é é um tempo perdido mas é um tempo perdido válido E além disso os requisitos poderão ser novamente trabalhados numa segunda versão bom nós temos também um outro processo que é a entrega evolucionária entrega evolucionária ela é uma combinação entre a prototipação evolucionária que foi estudada no vídeo anterior sobre a segunda parte sobre processos prescritivos e a entrega em estágios na verdade a entrega em estágios eh apesar de ser uma um um precursor dos
processos interativos e incrementais ela é uma evolução do da prototipação evolucionária eh então na entrega evolucionária a equipe ela desenvolve uma versão do produto apresenta o cliente e cria novas versões baseadas nas nos pareceres que os STE que que os clientes apresentarem para para o protótipo para a versão apresentada então a entrega evolucionária quando ela tenta acomodar a todas todas as as modificações sugeridas ou a maioria delas Então ela se aproxima mais da prototipação evolucionária já quando as entregas elas permanecem sendo planejadas de acordo com o que foi visto e essas modificações sugeridas vão sendo
acomodadas de acordo com as entregas Então esse processo é mais semelhante com a entrega em estágios ã Então esse processo ele tenta possibilitar a flexibilidade da prototipação evolucionária e manter o planejamento da entrega em estágios há um outro modelo que é o orientado A Fer como o nome diz ele utiliza muito ferramentas de prototipação e geração de código tem uma dependência muito forte em relação a essas ferramentas Então ela esse modelo ele Teoricamente permite uma produção rápida de de software a partir de especificações de alto nível essa é uma abordagem bastante rápida de movimento de
prototipação Mas ela é limitada pelas funcionalidades que são oferecidas pelas ferramentas eh Além disso os requisitos só são atendidos se as ferramentas realmente o permitirem ah dependendo das Ferramentas e da complexidade dos requisitos pode-se conseguir implementar grande parte dos requisitos considerando se a complexidade não for muito grande eh e essa abordagem ela pode ser combinada com outros processos por exemplo com modelo o modelo espiral que trabalha bastante com produção de próticos por exemplo e nós temos o desenvolvimento formal de sistemas que el é um pouco complexo possui algumas similaridades com o modelo em Cascata mas
ele se baseia na transformação matemática formal da especificação de software em programas executáveis eh as principais diferenças entre esse processo e o modelo em Cascata é que a especificação de requisitos ela é redefinida em uma especificação formal matemática detalhada eh e as atividades de projeto implementação e teste elas são substituídas por um processo de desenvolvimento transformacional Então são aplicados uma série de trans ações matemáticas na especificação formal até chegar ao software propriamente dito ah essa abordagem ela embora ela ela é muito formal ela exige que os profissionais que a utilizem tenham um conhecimento avançado de
matemática para que eles possam realmente desenvolver essas transformações Então por esse motivo Ele não costuma ser muito utilizado há poucos profissionais que podem eh ser utilizar esse tipo de processo e nós temos o desenvolvimento orientado a reuso Que Tem se tornado bastante Popular hoje em dia uma vez que já existe muito código desenvolvido que pode ser reaproveitado e existe muito código livre na internet que pode ser reutilizado eh existem bibliotecas existem componentes que podem ser utilizado e existem tem muito software que pode ser também comprado existem muitas empresas que criam componentes pacotes bibliotecas módulos que
podem ser comprados e utilizados no desenvolvimento de novos softwares Então para que esse tipo de processo possa ser útil é necessário haver uma ampla base de componentes de software reutilizáveis e é preciso existir uma infraestrutura de integração eh então como eu falei H muito disso pode ser baixado gratuitamente ou não via internet existe até o o a sigla cots que significa commercial of the shelf que significa literalmente comercial da da prateleira software de prateleira que são software genéricos que oferecem muitas funcionalidades que podem ser utilizadas ah inclusive algumas podem e devem ser habilitadas ou desabilitadas
dependendo de como o software vai ser eh reutilizado então Aqui nós temos uma figura representando o desenvolvimento orientado a reuso baseada no summerville então há uma etapa de especificação de requisitos uma etapa de análise de componentes dos componentes que estão que estão disponíveis componentes que sejam necessárias e uma etapa de alterações nos requisitos Esse é talvez o principal defeito desse desse processo Porque ah Muitas vezes os requisitos eles não são satisfeitos completamente porque muitas vezes os componentes disponíveis não atendem esses requisitos de forma completa então às vezes é necessário fazer alguma alteração nos requisitos aí
depois faz o projeto de sistema com reuso se houver necessidade na medida em que eh não existir um componente adequado ele pode ter que ser desenvolvido E aí depois os componentes eles são integrados e o software é validado e depois implantado no cliente Ah aqui nós temos as etapas do desenvolvimento orientado a reuso etapas ou estágios A primeira é a análise de componentes então baseado nos requisitos se busca por componentes para reutilizar e implementar a o software eh muitas vezes não existe uma combinação exata e então os componentes reutilizados eles vão fornecer parte da funcionalidade
requerida ou não vão atender totalmente a funcionalidade então tem a segunda etapa que é a modificação dos requisitos os requisitos eles são analisados então ã e comparados com as informações com as funcionalidades fornecidas pelos componentes Então os requisitos eles são modificados para refletir o que os componentes disponíveis podem oferecer e se não for possível modificar esses requisitos então H A análise de componentes poderá ser refeita em busca de novos componentes ou de soluções alternativas que podem eh redundar na no desenvolvimento de componentes novos depois se passa para o projeto de sistema com reuso então a
infraestrutura do sistema é projetada basicamente é a a arquitetura do sistema ou então uma arquitetura reutilizada eh levando-se em conta os componentes que vão ser reutilizados a a infraestrutura ela é organizada Para litar com esses componentes e eventualmente o novo software poderá ter de ser projetado se os componentes reutilizáveis não estiverem eh disponíveis não forem considerados adequados Eh aí se passa pro estágio de desenvolvimento integração então software que não puder ser comprado não puder ser baixado da internet não pudesse reaproveitado da base de componentes disponível precisará ser desenvolvido e os componentes serão integrados para criar
o novo sistema Ah bom o reuso ele é muito útil ele deve ser eh aplicado sempre que possível mas o processo de desenvolvimento orientado a reuso ele muitas vezes ele pode não ser tão útil se ele for totalmente orientado a reuso como é proposto aqui mas vamos lá Quais são as vantagens H esse processo ele reduz muito a quantidade de software que deverá ser realmente desenvolvido os custos e os riscos são menores já que muita coisa está sendo reaproveitada e o software é concluído muito rapidamente porém ah muitas vezes as funcionalidades disponíveis dos componentes não
atendem os requisitos do cliente totalmente então esses requisitos sofrer adequações ã e isso pode resultar em um sistema que não atenda realmente as necessidades do cliente Além disso é preciso ter cuidado com comportamentos emergentes quando se vai unir vários componentes quando vai se unir e vários eh vai se integrar vários componentes principalmente que alguns deles podem ser de fabricantes diferentes por exemplo ah existem componentes cots que oferecem muitas funcionalidades uma grande quantidade de funcionalidades então é necessário desabilitar as funcionalidades que não forem ser utilizadas porque às vezes acontece uma coisa engraçada que é o comportamento
emergente quando se integram vários componentes diferentes e eles não foram configurados com corretamente Às vezes o software apresenta H funcionalidades inesperadas ou comportamentos inesperados ele pode oferecer funcionalidades desnecessárias ou até a entar erros e comportamentos estranhos em determinados momentos do desenvolvimento do sistema Então os componentes reutilizados eles T que ser bem configurados para evitar esse tipo de coisa e nós temos também as linhas de produto de software que são uma forma de evolução do reuso de software linhas de produtos de software eles são compostas por um conjunto de sistemas de software que compartilham características comuns
são chamadas famílias de softwares eh Então essas linhas de produtos de software eh também chamadas de rps ou SPL em inglês software product Lines elas são gerenciadas de forma a satisfazer as necessidades específicas de um determinado segmento do mercado e elas são desenvolvidas a partir de um núcleo comum que pode ser eh reaproveitado de maneira sistemática e Então as sprs ou as linhas de produtos de software elas como eu falei elas são uma evolução das estratégias de reuso mas o reuso que é obtido com as sprs é uma consiste em uma abordagem estratégica para a
indústria de software então o reuso ele passa a ser incorporado sistematicamente aos processos de desenvolvimento Porém quando não utilizar linhas de produtos de software a as as spls elas não são úteis quando existe um produto único então o custo para desenvolver uma SPL com produto só com produto único não compensa ã também situações em que os produtos eles não possuem um relacionamento não é possível reaproveitar ativos comuns entre eles Ah uma SP ela precisa envolver vários produtos relacionados dentro de uma mesma área se isso não for possível não vale a pena investir SPR e também
se o número de produtos for pequeno o investimento não compensa Ah quando utilizar É preciso que haja no mínimo três produtos relacionados preferencialmente mais Então a partir de um determinada de uma determinada quantidade de produtos então é possível fazer o gerenciamento de versões e otimizar o produto o processo produtivo uma vez que se reaproveitam muitos ativos Ahã a partir do momento em que um existe um número de produtos então um número satisfatório então o custo de desenvolver uma linha de produto de software é menor que o custo de desenvolvimento Normal ah a implantação de uma
SP ela exige algumas mudanças na forma de desenvolver software mudanças na gerência do processo na forma de desenvolvimento na organização estrutural e do pessoal envolvido na abord na própria abordagem de negócio da empresa e na concepção arquitetônica dos produtos a arquitetura ela é muito importante nas SPS mas na verdade a arquitetura é importante para a maioria dos projetos eh existem três atividades essenciais na no processo de desenvolvimento de linhas de produtos de software que é o desenvolvimento de um núcleo de ativos esse núcleo de ativos é um núcleo que pode ser reaproveitado reutilizado o a
atividade de desenvolver de desenvolvimento de produtos propriamente dito e a atividade de gerência das eh SPS no desenvolvimento do núcleo de ativos então como eu falei o núcleo de ativos eh é o conjunto de componentes é o conjunto de software que pode ser reutilizado ah pode ser necessário identificar os pontos de variação ou seja ã o que pode variar de um elemento para outro eh a forma como o elemento vai ser reutilizado eh em uma spele em um produto ou outro e precisa haver instruções ou diretrizes que instruam que forneçam dicas sobre como reusar esses
ativos porque em algumas situações eles vão ser vão ser reutilizados de uma forma ou de outra eh então na fase de na atividade de desenvolvimento de produto ele recebe como entrada a descrição de um produto de um produto novo Óbvio Ah o escopo da linha de produto de software que vai garantir a viabilidade de incluir um novo produto nessa linha ou não o núcleo de ativos que poderão ser reutilizados e que vão ser vão servir de base para construção do produto o plano de produção que vai detalhar como o núcleo de ativos poderá ser utilizado
para produzir o produto Ah e as saídas são o produto propriamente dito o parecer para o processo produtivo que vai eh Tentar aproveitar as lições aprendidas eh no durante o desenvolvimento e com isso tentar melhorar o processo eh possíveis novos ativos que poderão ser reaproveitados eh em outros no desenvolvimento de um de um novo produto ah e possíveis novas restrições aplicadas a esse produto e aí nós temos a atividade gerência que ela tem como função identificar a estratégia de negócio e as possíveis oportunidades que podem ser obtidas com o desenvolvimento de uma SPR e adição
de Novos Produtos então a gerência técnica existe isso é a gerência organizacional e a gerência técnica ela é a gerência propriamente dita que acompanha as atividades de desenvolvimento tentando Verificar se os padrões adotados eles estão sendo seguidos de forma correta se as atividades estão sendo executadas a contento E se o processo pode ser melhorado então nós terminamos essa aula sobre processo de desenvolvimento prescritivos eu espero que ela tenha sido útil eu agradeço a atenção de todos e nós os vemos em uma outra aula obrigado pela atenção
