Olá sejam bem-vindos ao canal engenharia de software com ênfase a IML Eu sou professor julianes getes e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicado sobre o assunto 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 de processos de desenvolvimento de software dessa vez abord os processos iterativos E incrementais então vamos dar início a nossa aula então ah os processos iterativos e incrementais eles se se caracterizam por serem compostos de
por diversos ciclos de desenvolvimento diferente dos processos prescritivos tradicionais em que havia um único ciclo de desenvolvimento e que cada etapa precisava ser totalmente concluída para se passar para a etapa seguinte e nos quais o o produto o software só era entregue quando todo o ciclo fosse desenvolvido nessa abordagem existem diversos ciclos de desenvolvimento por isso ela é chamada de iterativa por possui várias iterações e em cada ciclo algum valor alguma característica alguma funcionalidade algum artefato é acrescentado ao produto em em desenvolvimento então a cada ciclo é adicionado algum recurso ao software por isso ele
essa abordagem é chamada de incremental eh então como eu falei a os processos iterativos incrementais eles são desenvolvidos em vários Passos similares ou vários ciclos similares por isso eles são chamados de iterativos e em cada ciclo o sistema ganha novas funcionalidades por isso ele é chamado de incremental eventualmente ele não ganha novas funcionalidades mas as funcionalidades elas são melhoradas são refaturar ou novos artefatos são produzidos como esp aplicações requisitos modelos de software H casos de teste esse tipo de coisa Ah essa abordagem incentiva mais a participação das partes interessadas uma parte interessada é qualquer pessoa
que tenha interesse no desenvolvimento do software e isso diminui a possibilidade de erros nos requisitos como interpretações erradas eh ambiguidades conflitos e outras anomalias que que pode ocorrer nos requisitos de software Ah então nessa abordagem o o processo de desenvolvimento ele é dividido em vários ciclos e a cada ciclo se considera um conjunto de requisitos esses requisitos eles são agrupados por ordem de priorização considerando a importância para o cliente e o risco que eles carregam em termos de complexidade que pode ser subestimada em termos de requisitos que podem sofrer mudanças bom Ah então a cada
ciclo um novo conjunto de requisitos ele é considerado e ao final de cada um desses pequenos ciclos é produzido um novo incremento para o sistema contendo extensões refinamentos novas novas funcionalidades ou novos Artefatos em relação ao sistema anterior essa abordagem ela somente é viável se realmente for possível dividir os requisitos em diversos grupos e alocar cada um desses grupos H um determinado ciclo de desenvolvimento eventualmente isso pode não ser possível em situações em que os requisitos eles possuem muitas interdependências entre si por exemplo bom os requisitos eles são alocados como já foi falado em função
da sua prioridade com relação à importância para o cliente e em função do risco que está agregado a eles em termos de complexidade ou instabilidade em termos que eles podem sofrer muitas mudanças Por exemplo agora nós vamos falar um pouquinho sobre processo Unificado ou unified process que é um dos melhores exemplos de processo iterativo e incremental esse processo ele foi criado em conjunto com o ML ele possui quatro fases a fase de concepção elaboração construção e transição cada uma dessas fases possui diversos ciclos o exceção da fase de concepção que ela pode ser concluída em
um ciclo só mas na impede que ela seja dividida em mais de um ciclo ah a fase de concepção ela é responsável por identificar os requisitos de negócio e por determinar a viabilidade do desenvolvimento do software se realmente vale a pena desenvolver o software considerando as restrições orçamentárias de cronograma de expertise da equipe de recurso de hardware e de software etc já a fase de elaboração é provavelmente a fase mais importante do processo Unificado onde os requisitos eh mais arriscados e mais importantes são desenvolvidos e onde grande parte da complexidade do software é resolvida a
fase de construção embora muitas vezes tenha mais ciclos e se desenvolva mais código ela requisitos de dificuldade Média a fácil então ela é mais uma fácil uma fase de trabalho do que uma fase difícil já a fase de transição é uma fase em que o software ele é basicamente implantado no cliente ela ainda vai ter alguma análise projeto e alguma implementação mas em menor grau É nessa fase que o software costuma ser realmente o software finalizado costuma realmente ser implantado no cliente são feitos Treinamentos e conversões de dados bom em cada fase são executadas diversas
disciplinas as disciplinas mais comuns são modelagem de negócio requisitos análise e projeto implementação teste implantação gerenciamento e configura mudança gerenciamento de projeto e ambiente em cada uma dessas fases essas disciplinas são executadas em maior ou menor grau em alguns casos elas não ser não chegam a ser executadas bom então pode-se perceber que na fase de concepção há uma ênfase muito forte nas disciplinas de modelagem de negócio e de requisitos já começa a haver alguma análise projeto começa a ter um pouquinho de entação quase nada algum teste não há nenhuma implantação Ah há um pouco de
gerenciamento de configuração e mudança onde começa a surgir as primeiras versões do software mas bem Inicial há o gerenciamento do projeto que ele é constante durante todo o processo Unificado o gerenciamento de projeto ele tenta garantir que os ciclos sejam alocados corretamente que o processo Siga os pasos siga o Mantenha o orçamento que o software desenvolvido eh tenha qualidade eh a feito é feito um gerenciamento de riscos esse tipo de coisa e o ambiente são feitas as configurações necessárias para que a equipe consiga eh ter um bom trabalho de desenvolvimento bom durante a concepção Como
já foi falado eh é feito um estudo de viabilidade se vale a pena desenvolver o software dentro da das restrições H impostas àquele projeto então basicamente A modelagem de negócio ela tenta entender as características da organização a que o software se destina H tenta compreender o processo eh que o software irá auxiliar e tenta identificar a os requisitos de negócio que basicamente justificam o desenvolvimento do software em termos de lucro vantagens que o software trará trá hum trará para empresa ou ã prejuízos que serão evitados eventualmente a empresa é obrigada a desenvolver um software caso
contrário será multada por exemplo então basicamente a fase de concepção ela estabelece a viabilidade e as justificativas para desenvolver o software a fase requisitos ela corresponde principalmente a elicitação de requisitos que aqui é muito forte na concepção uma vez que os requisitos eles têm que ser descobertos de maneira abrangente nessa fase para tentarse determinar a complexidade o escopo do software e a complexidade de maneira geral dos requisitos é feit uma uma análise e projeto já começa a ha ver uma análise e projeto os requisitos considerados mais arriscados são detalhados com mais profundidade Ah para auxiliar
na definição da viabilidade alguma pequena implementação pode ser feita alguns poucos testes e algum e um pouco de gerenciamento de configuração e mudança em termos de versões que começam a ser desenvolvidas por exemplo bom Como foi falado na elaboração se enfocam os requisitos considerados mais arriscados e mais importantes pro cliente então podee perceber que ainda há bastante modelagem de negócio embora ela vá diminuindo ainda há muito levantamento de requisitos embora eles também diminuam um pouco ao longo dos ciclos há muita análise e projeto de software há muito há muito engenharia de requisitos e muito projeto
uma vez que esses são os requisitos mais importantes eles têm que ser muito bem analisados e muito bem projetados há muita implementação Não tanto quanto na fase de construção mas essa implementação mais importante e mais arriscada aqui nós estamos desenvolvendo os requisitos mais importantes e mais complexos já há alguma implantação uma vez que esse é um processo incremental já algumas funcionalidades são implantadas no cliente ele já pode começar a trabalhar com o software uma vez que os requisitos mais importantes estão sendo desenvolvidos já começa a a haver H também alguns testes o gerenciamento de configuração
e mudança ele aumenta o gerenciamento de projeto é constante em todas as fases e o ambiente também na fase de construção Como já foi falado se identificam os requisitos ã de nível médio e fácil ã se implementa os requisitos de nível médio e fácil então A modelagem de negócio já é bem menor uma vez que os requisitos Eles já foram quase todos definidos ah a elicitação de requisitos diminui bastante embora sigue existindo A análise de projeto ela diminui um pouco também mas ela ainda é importante a implementação é muito alta nessa fase mas como eu
já falei é mais uma fase de trabalho do que uma fase eh difícil porque os requisitos Eles já não TM normalmente uma grande complexidade os testes aumentam e a implantação se torna bem maior muito Muitas mais funcionalidades são implantadas no cliente Ah o gerenciamento de configuração e mudança aumenta uma vez que várias versões estão estão sendo desenvolvidas gerenciamento de projeto e ambiente é constante na transição quase não há mais modelagem de negócio quase não há mais elicitação de requisitos análise de projeto também está quase finalizada há ainda alguma implementação referente principalmente a algumas pequenas adaptações
que foram eh identificadas pelo cliente os testes também diminuem bastante mas a implementação a implantação é bastante grande ah essa implementação envolve também as conversões há ainda bastante gerenciamento de configuração e mudança bastante gerenciamento de projeto e o ambiente é constante bom então falar um pouquinho mais sobre processo Unificado ele é iterativo incremental ele é fortemente focado em riscos ele é dirigido por caso de uso e ele é fortemente centrado na arquitetura Ah então como foi falado ele dirigido por caso de uso Isso significa que os casos de uso eles devem definir todas as funcionalidades
do software Como já foi demonstrado em outros vídeos os casos de uso identificam requisitos funcionais do software eh os casos de uso identificam os requisitos e quem pode utilizá-los os atores eh os casos de uso eles auxiliam na definição e validação da arquitetura do do sistema que é extremamente importante a arquitetura ela é a estrutura do software o esqueleto do software e ela é pouco passível à mudança Então ela tem que ser feita com muita seriedade ah mudanças na arquitetura pode afetar muito o projeto então deve-se evitar mudanças por isso que a decisão da arquitetura
é muito importante os casos de uso também auxiliam no planejamento da as diversas iterações e na criação dos casos de teste E além disso eles servem de base para documentação do software eh o processo Unificado ele é centrado na arquitetura como eu falei a arquitetura é algo extremamente importante para um projeto de software então ah o processo Unificado ele enfatiza o desenvolvimento de uma arquitetura sólida uma arquitetura bem consolidada e que atenda aos requisitos não funcionais Ah e a medida que os casos de uso eles vão sendo identificados e detalhados e implementados eles vão sendo
integrados incrementalmente ao longo dos ciclos na arquitetura Ah esse em geral esses casos de uso eles são inseridos dentro de componentes módulos ou pacotes que estão distribuídos né essa arquitetura eh então a cada iteração se incorpora a arquitetura os as funcionalidades que foram eh identificadas com a análise e implementadas ao longo dos ciclos ah os casos de uso eles são priorizados de tal maneira que os mais críticos arriscados ou complexos sejam enfocados nos primeiros ciclos então aqui se aplicam técnicas de priorização como a Moscou por exemplo que identificam os requisitos que precisam ser eh desenvolvidos
ou seja os requisitos que são essenciais sem eles o software não é útil para o cliente Ah então com isso eu tenho o mínimo produto viável uma vez que eu sei quais são os requisitos essenciais eu sei que são esses requisitos precisam ser des envolvidos primeiro e precisam ser implementados Obrigatoriamente senão o software não será útil também eh em seguida se identificam os requisitos desejáveis que são requisitos que agregam valor mas que não são realmente obrigatórios podem ser em último caso deixados por uma segunda versão caso o cronograma não permita os em seguida se identificam
os requisitos opcionais que poderiam ser eh desenvolvidos mas que agregariam pouco valor ao software Então realmente seriam os primeiros a serem deixados eh para novas versões e os requisitos que estão fora do escopo requisitos que não deverão ser implementados porque eles estão fora do objetivo do software e é útil identificar esse requis para não dar falsas expectativas ao cliente já deixar claro Logo no início esses requisitos eles não são não fazem parte do escopo do software Isso faz parte de um projeto separado então técnicas de priorização como a Moscou que identificam esse tipo de de
esse que classificam que priorizam os requisitos elas são bastante úteis e devem ser aplicados nesses processos interativos incrementais hã bom o desenvolvimento Como já foi já foi falado é baseado em ciclos iterativos e como já foi falado a cada iteração se incorpora a arquitetura as funcionalidades ah relativas aos casos de uso abordados no ciclo em questão cada ciclo acrescenta algo ao projeto como por exemplo eh a adição de conhecimento sobre os requisitos e a arquitetura criação de modelos como modelos de projeto modelos de classe modelos de interação Ah e desenvolvimento ou melhoria de código eh
do código que está sendo desenvolvido ah em cada interação todas as disciplinas relativas àquela fase devem ser executadas no no grau exigido por Aquela fase Então como já foi falado na quando nós explicamos a figura anterior no na fase de concepção eh o modelo de negócio os requisitos de negócio eles são uma disciplina que eh possui um grau de importância muito grande enquanto que a disciplina de implantação praticamente não é eh útil para essa fase Então essas disciplinas elas variam de importância Ah para cada uma das fases do processo Unificado a a integração contínua ela
reduz os riscos facilita os testes e melhora o aprendizado da equipe a respeito do software eh isso é bastante percebido no início quando é preciso tomar decisões bastante críticas e ainda pouco conhecimento sobre a complexidade dos requisitos bom o processo Unificado ele é focado em riscos Isso significa que Como já foi falado são enfocados são implementados os casos de uso mais críticos os considerados mais arriscados mais complexos mais instáveis no início e se tenta desenvolver os eh casos de uso mais arriscados quando o custo para resolver a ocorrência de riscos ainda e baixo e o
tempo para se adaptar a a situações eh não não ideais como complexidade maior do que havia sido pensado ainda ainda está no início então é necessário se adaptar a situações eh não ideais e nós temos tempo ainda para isso por isso os requisitos mais arriscados são enfocados nos primeiros ciclos falar um pouquinho sobre cada fase a fase vamos começar pela fase de concepção eh ela costuma ser rápida normalmente tem um ciclo só ela como já foi falado determina a viabilidade de desenvolver o software identific os principais riscos o escopo básico ã do software de tal
forma que possa se determinar se é válido desenvolver o projeto ou não os requisitos Eles são analisados de forma abrangente mas não em profundidade a profundidade será avaliada será desenvolvida se o software for considerado viável nas fases seguintes de elaboração principalmente Então as principais atividades da F de concepção são a produção de um seminário curto de requisitos os atores e casos de uso devem ser identificados pelo menos a maioria deles os atores Como já foi visto em outros vídeos relacionados ao ml representam grupos de usuários que podem utilizar determinadas funcionalidades do sistema e os casos
de uso representa as funcionalidades propriamente ditas ah a maioria dos casos de uso ela é escrita em um formato resumido mais identificando requisitos de usuário e os H casos de usos percebidos como mais complexos mais arriscados eles são escritos com maior nível de detalhe Então são desenvolvidos aqui requisitos desse sistema ah os requisitos mais importantes e mais riscados eles devem ser identificados e se produz uma lista de riscos quais a as possibilidades da ocorrência de um determinado risco e já pode se pensar em alguma forma de tentar resolvê-los e evitá-los Ah ainda são produzidos protótipos
protótipos são muito úteis para ajudar a compreender o problema e a facilitar a comunicação com os clientes para evitar ambiguidade e soluções de conflitos Então os protótipos eles são produzidos para para ajudar na compreensão dos requisitos funcionais e para demonstrar conceitos técnicos e são feitas eh investigações para determinar se realmente alguns requisitos em especial eh possuem viabilidade técnica para serem desenvolvidos Ah ainda são feitas algumas recomendações sobre possíveis componentes que podem ser reutilizados ou comprados e quais devem ser construídos eh reuso de software é uma característica muito útil que permite apressar o desenvolvimento de de
um sistema e diminuir a possibilidade de riscos Desde que seja possível reutilizar o código em termos de que pouca adaptação Deva ser feita eventualmente pode-se comprar componentes já prontos que Existem muitos disponíveis no mercado Ah ainda se produz uma proposta de nível alto de uma possível arquitetura para os requisitos não funcionais do sistema requisitos não funcionais identificam características gerais do sistema como ã nível necessário de escalabilidade de confiabilidade de proteção de segurança de desempenho de usabilidade esse tipo de coisa uma outra atividade é elaborar um plano para a primeira interação e se gerar uma lista
das possíveis ferramentas que poderão ser utilizadas para o desenvolvimento do software em termos de ferramentas Case em termos de ferramentas para ã desenvolvimento de interface Human computador H sistema gerenciador de banco de dados mais adequado linguagem de programação mais adequada esse tipo de coisa depois nós temos a fase de elaboração que como eu já disse é provavelmente a fase mais importante do processo onde são trabalhados os requisitos mais arriscados mais importantes para o cliente Ah é onde começam realmente a haver iterações normalmente a fase de concepção só tem um ciclo então nessas iterações do da
fase de elaboração a maioria dos requisitos é realmente descoberta e estabilizada ah problemas encontrados com eles são solucionados a arquitetura central e de risco alto é programada e testada os principais riscos são identificados mitigados Ou seja a possibilidade dees ocorrer é diminuía ou totalmente eliminados Se isso for possível também se criam ah planos de contingência para caso algum risco realmente ocorra esse tipo de coisa Ah é importante lembrar que nesse processo risco inclui também valor de negócio então Eh na fase de elaboração podem ser implementados funcionalidades que na verdade não são tão complexas mas que
agregam valor para o cliente a elaboração ela possui em geral duas ou mais interações e cada uma delas ocupa cerca de duas a seis semanas ah na elaboração são analisados o domínio do problema de forma bem mais profunda e a arquitetura é consolidada é estabelecida em definitivo Como já foi falado a priorização dos casos de uso mais complexos e permite eliminar Ou pelo menos diminuir o impacto da ocorrência de riscos Então se existem casos de uso funcionalidades arriscadas elas devem ser enfocadas primeiro e o processo Unificado ele tenta diminuir o impacto de mudanças ele Valha
com a perspectiva que elas ocorrerão mas tenta diminuir o seu impacto no projeto caso elas realmente ocorram na fase de construção ã são trabalhados os requisitos que Ainda faltam ela possui mais ciclos em geral que a elaboração Mas ela é mais uma fase de trabalho do que uma fase difícil complexa eh se completa o projeto sistema eh como já foi falado os requisitos aqui enfocados são de nível médio a fácil eh tenta garantir que o software atenda as necessidades dos usuários e que ele se encaixe corretamente no contexto da organização completa o desenvolvimento e os
testes doos componentes desenvolve versões úteis do sistema e ao final da fase de construção um produto completo e utilizável deve estar desenvolvido testado e pronto para uso pelo usuário final ah como já foi falado nessa fase são trabalhados os casos de uso de complexidade média e baixa que não vão impactar normalmente na arquitetura Ah o esforço de análise e projeto é bem menor nesta fase embora ocorra e a maior parte do trabalho se refere à implementação e teste dos componentes da arquitetura que se refere a esses casos de uso finalmente na fase de transição o
software é implantado no seu ambiente final são realizados testes de aceitação com as partes interessadas os usuários são treinados pode haver algumas conversões algumas desculpe algumas adaptações podem ainda ser necessárias e provavelmente devem ser feitas algumas de dados de sistemas anteriores sistemas legados e agora então nós terminamos o o vídeo a aula sobre processo de desenvolvimento iterativos e incrementais eu espero que esse vídeo tenha sido útil para vocês eu agradeço a atenção de todos e se esse se essa aula foi considerada útil eu peço que vocês curtam compartilhem esse conteúdo com quem possa ter interesse
e se ainda não estiverem inscritos eu gostaria de solicitar que você se inscrevam no canal novamente obrigado pela atenção nós nos vemos nos próximos vídeos
