Olá seja bem-vindo à nossa segunda aula de engenharia de software nessa aula de hoje nós vamos ver os conceitos e algumas coisas sobre os modelos de desenvolvimento de software foi a gente vai ver um pouco de do histórico e desde dos primeiros modelos que foram ados vamos ver os problemas e por que eles não são tão usados assim e vamos ver quando utilizar o modelo de desenvolvimento de software vamos ver vários tipos e eles foram criados de acordo com o decorrer do do tempo e com as necessidades e os conhecimentos que foram sendo adquiridos Lembrando
que se você precisar pause o vídeo e Anote tudo que você tiver dúvidas tá bom lá no último slide a gente vai falar para você Onde na apostila que você vai a teoria sobre essa aula aqui vamos ver alguns conceitos definições que foram dadas por pesquisadores que trabalharam na época Essa não é a mais antiga é a definição de p é de 1987 a engenharia de software pode ser vista como uma abordagem de desenvolvimento de software elaborada com disciplina e métodos bem definidos é a construção por múltiplas pessoas de um software com múltiplas versões bom
nessa definição que par dá pr gente ele mostra que para construir um software você tem que passar por métodos e passo a Passos bem definidos passos a Passos esses que você pode medir quando você terminou você pode entender quando que você terminou um passo e vai começar o próximo e que você possa ainda trabalhar com várias pessoas desenvolvimento de software é você saber trabalhar em equipe para que você consiga tirar o máximo de proveito e qualidade antes que a gente comece se aprofundar em alguns conceitos eu t trouxe aqui para vocês um pouco de eh
algumas imagens de alguns Profissionais que são eh que trabalham na engenharia de software que talvez a gente oua falar quando vai ler algum livro mas a gente não sabe nem a cara deles né então vamos ver ah tem tantos brasileiros Como por exemplo o professor Carlos Lucena que é lá da PUC do Rio de Janeiro Professor Silvio Meira que é da UFPE de de Recife Professor Paulo Mairo que é professor aposentado lá da USP de São Carlos e e outros professores que são muitos bastante conhecidos como professor por exemplo Roger presman é o Ian sumerville
são eles tem livros de engenharia de software que são bastante utilizados né Qualquer são os principais livros de engenharia de software a Bárbara kitchen a Laurence wiler e o Fred Brooks também tem livros de engenharia de software Professor Daniel Berry Professor Donald Cohan eles são da Universidade lá de waterlow no Canadá são Pioneiros também são muito conhecidos aqui no Brasil eles foram orientadores de vários pesquisadores aqui no Brasil então só paraa gente dar uma um um uma imagem geral dos pesquisadores das pessoas que trabalham com engenheria de software que fizeram o progresso da engenheria de
software no Brasil e no mundo mais um conceito de engenharia de software agora o Bauer de 1960 Então esse é um dos conceitos mais antigos mais ou menos eh Quando foi criado o termo engenharia de software então ele define o seguinte Ger de software é a criação e a utilização de sólidos princípios de engenharia a fim de obter software de maneira Econômica que seja confiável e que trabalhe em máquinas reais bom essa é a ideia de você conseguir e garantir que um software foi produzido através de um processo que te Garanta e qualidade durante todo
o processo que eu consiga monitorar eh o processo e que no final eu tenho um software que pode ser realmente utilizado em máquinas reais e que não vai causar nenhum dano pra sociedade ou para quem tá operando essa máquina existe até um quadrinho que talvez defina várias coisas sobre engenharia de software não sei se vocês já ouviram falar é o Gilbert do Scott Adams esse aqui tá em português mas tem se você colocar na internet e procurar sobre o Gilbert você vai encontrar várias charges e situações engraçadas com engenharia de software tá bom pause o
vídeo Leia e vê se você entenda o que tá sendo dito aqui nessa charge outra charge bastante interessante conta um pouco Talvez o maior problema de projetos de software essa charge aqui que mostra é de maneira engraçada Ela já foi traduzida em várias línguas né Nós temos essa aqui em português que mostra um processo de desenvolvimento de software um processo de você entender o cliente se você der um pause quando você tiver prestando atenção em cada quadro você vai ver que nem o cliente conseguiu explicar o que ele queria e nem o engenheiro de software
conseguiu entender o que o cliente queria o cliente queria uma coisa muito básica e o o projetista o desenvolvedor de software pensou em algo bem diferente né foi quase um telefone sem fio então preste atenção nessa chave se você não viu ainda eh veja agora agora a gente vai começar a falar mesmo sobre os modelos de processo de software ah existem vários modelos que a gente vai trabalhar nó Nós escolhemos só os principais o modelo Cascata eh o modelo espiral eh o modelo eh o hup ou up que é o processo Unificado e depois a
gente vai ver o método ágil de desenvolvimento de software e a gente vai focar no scrum Tá bom então Eh eu vou mostrar para vocês vários modelos e qual que er a ideia dos modelos né Qual que é a ideia é a mesma coisa eles pegaram da engenharia de construção de um produto por exemplo de construção de um carro como é que acontecia a construção do de um carro quase uma linha de montagem e tentaram passar para isso passar isso pro eh desenvolvimento de software as Prime a primeiro a gente vai ver bastante interessante Talvez
o mais conhecido é o modelo Cascata o modelo tradicional que foi o primeiro modelo que tentou colocar uma ordem numa atividade que como aqui fala né uma atividade inerentemente caótica bom então Prest atenção e percebam a evolução dos processos de desenvolvimento de software vocês vão perceber durante essa aula e a próxima que eu vou falar bastante de modelo e de processo Mas vamos colocar aqui as defin de modelo e processo para que a gente não confunda tá bom modelo é um desenvolvimento de software uma representação abstrata simplificada e e como o processo de desenvolvimento de
software deve ser organizado e executado A ideia é o seguinte então a gente vai ter um modelo que a gente vai seguir esse modelo para que a gente consiga fazer o nosso processo então tem lá o modelo Cascata que a gente vai ver daqui a pouco se eu quiser seguir Aquele modelo eu vou criar um processo para minha empresa por exemplo de como construir software baseado no modelo Cascata já um processo de desenvolvimento de software é a instanciação daquele modelo Ou seja você segui o modelo e vai criar agora atividades métodos práticas e transformações realizadas
para desenvolver implantar e manter um software isso você vai fazer eh pra sua empresa por exemplo então eu posso seguir um modelo e ter vários processos diferentes mas que seguem o mesmo modelo cada empresa vai ter o seu processo de desenvolvimento de software cada fábrica de software vai ter o seu processo que pode até seguir o mesmo modelo e de outras empresas mas é diferente porque ele é específico para construir um tipo de software o primeiro modelo ou processo se é que pode se dizer que isso é um modelo ou um processo é a forma
de codificar e consertar Ou seja você faz de maneira empírica eu falei um pouquinho sobre essa forma de desenvolver software e talvez seja a forma mais utilizada principalmente empresas iniciais ou então programadores que estão iniciando conjunto de de desenvolvedores iniciantes eles fazem desse jeito codificar e comca nesse desenhozinho mais ou menos mostra como funciona faz uma especificação do sistema ou seja colhe o que que vai ser construído e vai codificando e consertando e gera um produto que espera-se que ele funcione Tá bom então a gente já viu os problemas quem assistiu a aula um e
lembra lá ah Um dos problemas é que você não consegue muito evoluir E com o tempo um fal de manutenção você também não consegue adicionar novas funcionalidades a ele por exemplo né então só para vocês verem o gráfico de como funciona faz o entendimento preliminar implementa corrige se tem uma versão satisfatória já entrega o produto pro cliente se não tem uma versão satisfatória volta a implementar e corrigir então é bem simples e na verdade não é muito um processo a gente tá colocando aqui como processo como tendo o início de tudo tá bom isso pode
até funcionar para alguns casos muito simples tal tal vez funcione para algum exercício mas com o tempo se eu quero dar manutenção novamente eu quero mostrar que isso teve qualidade eh eu preciso de um processo um pouco mais organizado do que esse Agora sim o primeiro modelo que foi criado é o modelo Cascata também chamado de ciclo de vida clássico eh ou modelo Waterfall se for em inglês esse modelo ele tenta separar todas as etapas do desenvolvimento de software percebam que esse modelo ele é sequencial e linear ou seja uma atividade só começa quando a
atividade anterior a ela terminou ele não pode fazer duas atividades ao mesmo tempo tá bom é a mesma ideia lá da linha de montagem de um carro por exemplo só posso colocar a porta no carro se o chassi estiver pronto por exemplo E por aí vai vamos perceber os nomes que tem aqui tá bom o modelo cascato Como disse é um modelo é uma representação abstrata a gente já viu o que que é modelo né né ele tem várias etapas pode de seis até 12 etapas dependendo o que o que me interessa nesse caso Aqui
nós temos sete etapas ele tem lá levantamento de requisitos do sistema a gente vai ter uma aula sobre isso né sobre como fazer eh levantamento de requisitos levantamento de requisitos tanto de sistema de software agora segunda etapa análise desses requisitos e todas essas três primeiras etapas são referentes ao o que que o o software vai fazer tá bom A partir dessa etapa de análise começa agora programa projeto do programa codificação teste e operação já é como e o software vai fazer aquilo que o cliente quer então eu tenho três etapas iniciais nesse caso aqui desse
modelo que me ajuda a entender o que o software vai fazer bom essas três iniciais a gente chama de eh engenharia de requisitos a gente vai ter aulas sobre isso lá no módulo dois e é bem importante lembra se você olhar aquela charge que eu mostrei H uns slides atrás ela mostra que o maior problema é a falta de entendimento entre o cliente e o desenvolvedor ou seja ninguém entende o que é para ser construído nem o cliente Sabe dizer o que ele quer e nem o desenvolvedor sabe perguntar de forma que seja eficaz a
construção desse software aqui então a gente vê um resumo de tudo que eu falei sobre o modelo Cascata é o modelo mais antigo e mais amplamente utilizado na engia de software ainda hoje ele é utilizado Apesar dele ter problemas que a gente vai comentar daqui a pouco ele é foi feito Pens pensado meio que no ciclo de vida eh da engenharia de software convencional da engenharia convencional dei o exemplo lá da linha de montagem né então como constrói um produto físico né Não como um software requer uma abordagem sistemática sequencial o desenvolvimento de software a
gente viu que o resultado de uma fase se constitui na entrada de outra então eu só posso começar por exemplo lá o planejamento se eu ter terminei a comunicação A modelagem Eu terminei o planejamento e a gente vai ver que isso não é muito real no desenvolvimento de software e pode ser que cause alguns problemas a gente vai falar sobre isso daqui a pouco alguns problemas do modelo Cascata a gente pode perceber Nessa versão simplificada que a gente vê aqui dele né Vejam Só por exemplo eu faço os requisitos a partir dos requisitos que que
é fazer os requisitos é você entender o que o sistema vai fazer então você ter reuniões com o seu cliente ou então através de prototipação ou através de leituras de documentos né Tem várias maneiras a gente vai estudar isso melhor eh em uma próxima aula depois de você entender o que o cliente fez faz o planejamento eh o desenvolvimento que seria a codificação em si pode testar o software eh e depois entrega pro cliente ou leva para manutenção isso é feito só depois então você imagina um software grande o tanto de tempo que demora para
você entregar isso pro cliente porque você tem passar primeiro por essas todas as etapas para só depois o cliente vem então você tem um encontro com o cliente lá nos requisitos e depois só lá no final e talvez isso depende do tamanho do software demore ah 2 3 meses ou então até mais né dependendo do tamanho Então isso é um dos problemas outro problema se der um eh se você descobriu um problema lá na fase de teste você tem que voltar até a fase de requisitos para saber onde tá esse problema e corrigir novamente na
sequência Esse é uma das características do modelo ser sequencial e linear ele também não é interativo ou seja ele não entrega pedaços do software que já poderia ser entregue pro cliente eh aos poucos e depois vai complementando outros pedaços outras partes do software a gente vai ver que outros modelos mais novos conseguem fazer isso esse modelo ainda não pensava com isso embora a gente tenha apontado alguns problemas do modelo Cascata ele é muito melhor né ele tem algumas fragilidades mas ele é muito melhor do que você utilizar aquele primeiro modelo do Code and Fix do
codifica e concerta né então é muito melhor você utilizar o Cascata que ele tem pelo menos etapas bem definidas para alguns tipos algumas características de software quando você tem os requisitos bastante conhecidos quando você faz a fase inicial então ele é melhor ele é muito bom de ser utilizado tá bom e o cliente ele tem que tá ciente que eu tô desenvolvendo o meu software utilizando esse modelo porque ele vai saber o que eu tô trabalhando para entregar um software com qualidade vai demorar um tempo mas eu tô gastando esse tempo dele para implementar um
software com melhor qualidade então pensando algumas coisas boas que o modelo Cascata trouxe pra gente né foi a imposição de disciplina planejamento e gerenciamento aquela disciplina que não tinha antes que não tem se você codifica do meio daquele jeito é tradicional de você consertar fazer de novo consertar fazer de novo então ele coloca uma disciplina um planejamento que você tem que ter a implementação do produto deve ser postergada até que os objetivos tenham sido completamente entendidos né como ele é sequencial eu só vou conseguir fazer lá a etapa de codificação de desenvolvimento em si quando
eu terminar as etapas iniciais que são as etapas de entendimento melhor do que que tá sendo do que que vai ser construído e do planejamento do que vai ser construído e permite uma uma uma gerência de baseline como eu sei que só vou terminar uma etapa só vou começar uma etapa quando aquela etapa terminar então eu consigo saber exatamente eh uma linha de base para eu até medir a velocidade por exemplo se eu tenho vários projetos eu consigo mais ou menos ter uma noção de quanto tempo que que dura Aquela fase dos requisitos ou quanto
tempo que dura Aquela fase de codificação de teste porque eu já tô participando num processo de desenvolvimento de software que ele tem bem definido quando passa de uma fase para outra então tem algumas características né a gente vai ter a nossa avaliação a nossa avaliação vai perguntar algumas coisas sobre isso tá bom anotem parem dá um pause no seu slide para ver se você tem alguma dúvida sobre o modelo Cascata se você colocar na internet lá modelo Cascata você vai ver vários tipos de modelo com com mais quantidade com menos quantidade existem versões diferentes do
modelo Cascata tem o Cascata em V Cascata em w tá bom de se você quiser se aprofundar mais sobre o modelo Cascata se você foi fazer algum concurso na área dá uma olhada mais sobre isso e os dois livros de engenharia de software que eu recomendo tem na biblioteca da univasf você como aluno eh de um curso da univas você tem acesso à biblioteca você pode pegar o o engenheiria de software do Samille que é o primeiro aqueles slides no começo que eu mostrei para vocês tem lá a foto dele e do Roger presman são
dois livros bastante conhecidos na engenharia de software que fala um pouco dos tipos diferentes do modelo Cascata o próximo modelo que a gente vai ver né que foi uma evolução do modelo Cascata Ele tentou pegar aqueles problemas os as fragilidades do Cascata e colocar aqui em um outro modelo e o modelo espiral ele foi criado por um pesquisador americano chamado Barry Bean tá na década de 80 e a ideia é o seguinte você lembra que o problema Um dos problemas do Cascata que ele é sequencial e para alguns tipos de software que são desenvolvidos esse
modelo sequencial é ruim modelo sequencial significa que eu só vou entregar o software pro meu cliente só no final quando o software estiver bem Pronto com modelo espiral por exemplo eu consigo entregar o software aos poucos eu consigo ser iterativo e incremental Ou seja eu passo pelas várias etapas no desenvolvimento de software várias vezes e eu vou incrementando o meu software eu dou sempre um exemplo de biblioteca eu tô fazendo um software para uma biblioteca então eu eu penso quando eu vou fazer um software biblioteca o que que eu posso entregar eh primeiro pro meu
cliente pro pra biblioteca para que eu consiga com outro tempo ficar codificando outras coisas ficar planejando eh outras coisas do software então por exemplo eu posso fazer um cadastro de livros deixar o cadastro de livros pronto o cadastro de cliente pronto e já mandar pra biblioteca Então a primeira fase que eu vou fazer que eu vou entregar pro cliente é um pedaço do software que já pode ser utilizado El já pode ir cadastrando por exemplo os livros eh os ou os clientes né Então vai de acordo com o meu planejamento no modelo espiral Se você
dar uma olhada aqui ó nesse caso ele tem cinco cinco etapas comunicação que seria essa parte da comunicação seria a parte dos requisitos de você ter o contato com o cliente Então veja também que era uma fragilidade do modelo Cascata a comunicação agora eu vou várias vezes né Então você começa a linha onde tá escrito início e você vai na primeira volta da espiral você passa por comunicação planejamento que seria como que eu vou construir Depois que eu me comuniquei com o cliente entendi o que que éa para ser feito como que eu vou construindo
então uma parte importante que nesse planejamento tem lá o que a gente chama de análise de riscos é o primeiro processo de desenvolvimento o primeiro modelo de desenvolvimento de software que tem essa etapa de análise de riscos análise de riscos do tipo desde de de desenvolvedores que podem sair do do do meu projeto desde eh do custo pode aumentar por algum motivo então desde o tempo que eu posso demorar também para construir então para cada requisito que o cliente pede eu analiso os riscos daquele requisito de ser implementado no tempo correto no valor correto que
foi pedido depois eu passo pela modelagem que seria construir um projeto de como será eh o software a construção em si a entrega pro cliente de novo Eh no finalzinho da primeira espiral que eu tô lendo entrega pro cliente veja o feedback com feedback faça uma nova comunicação e construa a outra interação do software então ele vai fazendo isso até que no final as últimas voltas da espirais o software vai est estar pronto então eu entrego o software aos pouquinhos para o meu cliente ele vai ter o software completo ele vai conseguir ver a evolução
do software eu sempre vou estar em contato com El com ele então para alguns tipos de software esse modelo espiral é o melhor um resumo sobre o que o modelo do espiral faz ele acopla a natureza interativa da prototipação a gente vai falar mais sobre partipação eh nas próximas aulas mas é é a ideia que você uma das maneiras de você entender melhor os requisitos do cliente você pode fazer uma entrevista com o cliente para saber qual é o software Como será o software que você vai construir mas você também pode fazer um protótipo daquele
software e fica mais fácil de você entender e se você lembrar volte aos slides atrás se você der uma olhada no modelo espiral a primeira voltinha a primeira espiral lá do início pode ser um protótipo não precisa ser o software em si Então você faz um protótipo e passa por todas as etapas de construção sendo as primeiras etapas um protótipo eh os o espiral é dividido em uma série de atividades de trabalho ou regiões e tarefas é meio parecido também com Cascata só que a diferença é que ele revisita eh essas e atividades de trabalho
eh existem tipicamente três a seis regiões de tarefa dependendo do modelo que você vai ver você pode colocar mais ou menos e a parte interessante que combina também aquela baseline que tem lá modelo Cascata também ou seja você sabe quando termina uma etapa e começa a próxima então Outro ponto importante do modelo espiral é que ele adiciona um novo elemento que é o análise de riscos eu falei um pouquinho sobre análise de riscos mas na verdade é eh o engenheiro de software pensar no risco daquele requisito que o cliente quer de ser implementado ou não
de conseguir implementar ele riscos de tempo riscos financeiro Será que eu vou conseguir implementar aquilo então é um dos únicos modelos de desenvolvimento de software que tem uma etapa que você pensa nos Riscos eh de ser implementado ou não aquele requisito eh segue a abordagem de passos sistemáticos do ciclo de vida clássico ou seja tem uma uma abordagem passo a passo que você vai construir sempre Começando na etapa da comunicação no nosso caso que seria o a obtenção dos requisitos o que será construído depois modelo eh ou então projeto do software e aí por aí
vai eh uma usa prototipação em todas as etapas da evolução do produto então toda vez que tem aquela parte lá de comunicação eh eu vou construir um protótipo para eu conseguir me comunicar com o cliente com o que tá sendo desenvolvido antes de eu construir então facilita a comunicação por isso que a prototipação é tão importante e a nossa disciplina No final a gente vai trabalhar com prototipação eh e vai ter o projeto final é sobre isso alguns coment sobre o ciclo de vida do modelo espiral eh a gente viu lá que é uma abordagem
que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa evolutiva como toda etapa eu passo novamente por aquela análise de riscos o análise de riscos é feita através do desenvolvedor em si e também do do cliente eh pode ser difícil convencer os clientes que uma abordagem evolutiva controlável né a gente vi uma espiral e pode ser que não tenha fio enfim quando é que termina eh o desenvolvimento do meu software Será que nunca vai terminar aquela espiral é infinita exige considerável experiência na determinação de riscos e depende dessa experiência
para ter sucesso bom apesar de ter essa análise de riscos que é interessante como é que realmente Eu determino se aquele requisito é um risco ou não então vamos supor que eu quero implementar um software e esse software dependa de um hardware muito novo então da Inteligência Artificial que talvez eu não saiba ainda como é que funciona né como é que eu sei que isso é um risco ou não é um risco então para para eu saber disso eu preciso ter uma base de conhecimento muito boa tem que ter alguma experiência em desenvolvimentos de software
que já ten utilizado essa tecnologia e só assim eu vou conseguir saber se é risco ou não bom então é é um modelo Interessante foi o segundo modelo talvez eh história né Talvez seja mais importante historicamente do que realmente seja utilizado ele é muito aproveitado em outros modelos mas ele mostra uma evolução e uma vontade de construir software com qualidade o próximo modelo ele já foi pensado de maneira diferente e é para ser mais robusto ainda esse próximo modelo chamado de processo Unificado e muita muitas vezes na internet se você procurar sobre ele você vai
encontrar em vez de Up você encontrar a sigla rup rup porque ele é ele foi feito ele foi feito so encomenda a IBM encomendou os principais Engenheiros de software da época que estavam trabalhando com vários tipos de eh desenvolvimento de técnicas para desenvolvimento de software em várias etapas do desenvolvimento software e encomendou e criou um produto chamado Rational esse R é de Rational eh criou um produto chamado eh Rational unified process ou seja rop mas pra gente aqui nos livros que você vai encontrar é o processo Unificado o que importa pra gente é saber que
ele foi feito eh para ser bastante robusto ah Empresas Grandes vão utilizar o processo Unificado ele tem uma documentação bastante grande e para cada etapa de desenvolvimento de software ele mostra a evolução eu consigo acompanhar eh e aos poucos e ele pega um pouco das características boas dos outros modelos que a gente viu Eh uma coisa interessante é que ao mesmo tempo Quando surge o processo Unificado também surgiu a uml uml é linguagem de modem unificada que é por exemplo como que eu escrevo como é que eu faço um modelo de software na fase de
requisitos como é que eu faço o modelo de software na fase de projeto Então vão ter diagramas a ml vai me ajudar a descrever diagramas para que eu consiga fazer um projeto disso assim como na engenharia civil quando eu faço uma planta de uma casa é um arquiteto então um engenheiro que faz a planta na casa na engenharia de software eu uo modelos e diagramas da uml para eu conseguir descrever como é que vai ser o meu software e por último eh para entender aqui sua concepção é baseada nas práticas de maior retorno do investimento
do mercado Tá bom então ele foi pensado exatamente para ser utilizado no mercado para ser fácil de ser utilizado para ser uma uma documentação bastante vasta que permita que qualquer eh empresa que deseja utilizá-lo possa consultar essa documentação e tinha um um monte de ferramenta pela IBM que a IBM proporciona para isso esse modelo ele mostra pra gente eh como é que funciona Eh toda o desenvolvimento de software através do processo Unificado se vocês derem uma olhada aqui no modelo eh vai começar iniciação ele tem lá as fases iniciação elaboração construção e transição e essa
figura aqui mostra a quantidade de esforço em cada disciplina então por exemplo na iniciação eu começo por aqui na iniciação Eu tenho um esforço maior na modelagem de negócio um esforço maior na nos requisitos na análise no projeto a implementação em teste na fase de iniciação muito pouco então eu termino uma versão do software entrego o software pro cliente vou resolver a outra iteração faço de novo iniciação vai começando a aumentar o algumas e diminuir outras disciplinas na elaboração vou ter um gasto de modelarem de negócio bastante en requisitos análise de projeto implementação já começou
alguma coisa já faço o teste e Gero cada um desses aqui aqui embaixo equivale a uma e a uma uma versão do software Tá bom então a gente tem várias versões do software quando eu chego lá no final a construção pode ver que os requisitos ó vão ser poucos já vou utilizar muito pouco da modelagem de requisitos então dos requisitos análise de projeto pouco implementação ainda tem alguma coisa mas já vai terminando eh testes tem bastante no finalzinho quando já vou entregar pro cliente implantação que começa a ser maior agora porque a implantação é você
entregar o o software pro cliente já na versão final praticamente né gerência de configuração e mudança sempre constante nessa fase de construção até uma hora que eu vou diminuir todos os disciplinas eh das fases iniciais e começa a ter mais esforço nessa fase finais chegamos ao final da segunda aula e agora você vai poder pesquisar mais saber um pouco mais sobre o que foi falado eh na nossa apostila então leia lá a nossa apostila agora eu peço que vocês Leiam a unidade dois da apostila chamada de processo de software lá tem bastante coisa do que
eu passei aqui e um pouquinho de coisa mais tá bom então eu quero que vocês Leiam da página 12 até a página 23 A suas dúvidas dessa aula que nós teremos nossas aulas síncronas nossas aulas ao vivo nessas aulas você poderá tirar dúvidas direto com o professor
