curso-6931-aula-00-v1

Aula 00

Tecnologia da Informao p/ TRT-MG (parte II) - AnalistaProfessor: Diego Carvalho

00000000000 - DEMO

Tpicos de TI para Analista do TRT/3 Regio (MG) Curso de Teoria e Exerccios

Prof. Diego Carvalho Aula 00

Prof. Diego Carvalho www.estrategiaconcursos.com.br Pg. 1 de 103

AULA 00

SUMRIO PGINA

Apresentao 01 1. Ciclo de Vida de Software 12 2. Processos de Desenvolvimento de Software 15 3. Modelo em Cascata 18 4. Modelos Iterativos e Incrementais 36 5. Modelos Evolucionrios 41 6. Scrum 46 7. Extreme Programming (XP) 67 8. Kanban 86 9. TDD (Test Driven Development) 86 10. BDD (Behavior Driven Development) 86

Fui bem? Fui mal? Mais ou menos? 87 Lista de Exerccios Comentados 88 Gabarito 103

APRESENTAO

Ol, pessoal. Sejam bem-vindos! Acaba de sair a autorizao para o Concurso do Tribunal Regional do Trabalho 3 Regio (MG) Cargo: Analista Judicirio rea: Tecnologia da Informao. Pessoal, deixa eu contar uma parada: finalmente saiu o esperado concurso do TRT/MG! No importa se cadastro-reserva, no ltimo concurso h seis anos chamaram um bocado de gente! Animem, pessoal!

TOP 4 DVIDAS DOS ALUNOS

1. Essa a Aula Demonstrativa (est disponvel para todos na internet) o restante do contedo estar disponvel na Aula 01 (apenas para aqueles que adquirirem o curso).

2. Esse curso no possui vdeo-aulas! Estamos trabalhando para disponibiliz-las em cursos futuros a partir do segundo semestre, logo isso no ocorrer ainda neste curso.

3. Esse curso contempla somente aquilo que est em seu cronograma. Ele no contempla todo edital de tecnologia da informao, nem outras disciplinas, nem discursivas, estudos de caso, etc.

4. Existem questes de Mltipla Escolha (A, B, C, D, E) e existem questes de Certo/Errado (C, E). Quando

no h itens para escolha na questo, porque a questo da Modalidade Certo/Errado.

00000000000

00000000000 - DEMO




O PROFESSOR.

Uma breve apresentao: meu nome Diego Carvalho, bacharel em Cincia da Computao pela Universidade de Braslia, ps-graduado em Gesto de Tecnologia da Informao na Administrao Pblica e Analista de Finanas e Controle da Secretaria do Tesouro Nacional. J passei por esses perrengues de concurseiro e sei de duas coisas: a estrada difcil, mas o prmio compensa! E muito!

www.facebook.com/professordiegocarvalho

O nosso curso est cada vez mais completo e mais maduro. meu 38 curso aqui no site, passando por rgos como: ANCINE, TRT/2, CEF, ISS/SP, TCE-RS, ANATEL, TRT/1, ANTAQ, ISS/BA, DATAPREV, TJ/BA, TCE/SP, TCM/GO, CNMP, MPOG, TRT/15, TCU, CD fora os Cursos Regulares. Observem que foram cursos de menor envergadura at cursos de enorme envergadura! Galera, l no site, ns professores temos algumas mtricas para medir se o nosso desempenho nos cursos est bacana! Os alunos podem avaliar com notas e, inclusive, escrever anonimamente o que acharam do professor e do curso. Apresento abaixo o resultado de alguns cursos ministrados recentemente. Portanto, confiem em mim... vocs vo aprender muito com esse curso!

00000000000

00000000000 - DEMO




00000000000

00000000000 - DEMO




Esse curso protegido por direitos autorais (Copyright), nos termos da Lei 9.610/98.

00000000000

00000000000 - DEMO




O CONCURSO

Concurso do Tribunal Regional do Trabalho 3 Regio ( - 2015 Analista Judicirio Apoio Especializado: Tecnologia da Informao

INFORMAES GERAIS

REMUNERAO VAGAS

(PROVAVELMENTE) R$8.863,84 CADASTRO RESERVA

EDITAL/AUTORIZAO: http://www.concursosfcc.com.br/concursos/trt3r114/boletim_final_trt3r114.pdf

00000000000

00000000000 - DEMO




O CURSO...

O curso que eu proponho abranger todo o contedo acima, entretanto impossvel e invivel esgotar cada ponto do edital em uma aula online de TI (diferente de Direito). Logo, vou direcion-los pelo contedo da melhor maneira possvel. Fiquem tranquilos! Eu sei como complicado ler muita coisa e vocs tm outras disciplinas para estudar. Logo, vou ser simples e objetivo! Tranquilo? ;) Alm disso, o cronograma ser seguido com a maior fidelidade possvel, mas ele no esttico e poder haver alteraes no decorrer do curso. Eventualmente, posso tirar o contedo de uma aula e colocar em outra de forma que o estudo de vocs fique mais lgico, coeso e fcil de acompanhar; eventualmente, podemos mudar a ordem das aulas. Ademais, vamos usar questes de diversas bancas. Enfim, confiem em mim: o curso vai ajudar bastante! Qualquer dvida, qualquer dvida mesmo... por mais simples que seja, s me chamar! Caso haja alguma reclamao, problema, sugesto, comentrios, erros de digitao, etc, podem enviar para o nosso frum que eu tento responder da maneira mais tempestiva possvel. Ainda duvidam que PDF no d certo com Concursos de TI? Veja abaixo:

6 Lugar ISS/Salvador https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678 1 Lugar TRT/RJ https://www.facebook.com/video.php?v=790616534367672

Metodologias e prticas de desenvolvimento de software. Scrum. Extreme Programming (XP). Prticas geis. Kanban. Test Driven Development. Behavior Driven Development. Engenharia de Software: Engenharia de Requisitos. Tcnicas de levantamento de requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos. Verificao e validao de requisitos. Requisitos funcionais e no funcionais. Mtricas de Software. Ponto de funo. Mtricas geis. Anlise e projeto orientado a objetos. Processo Unificado. Testes. Processos de testes. Tipos e estratgias. Planejamento e acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade. Tolerncia a falhas. Interoperabilidade. Usabilidade. Integrao Contnua. Anlise automatizada e Reviso de cdigo. Linguagens de programao. Java. HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS. Tecnologias Java. Java EE 6 e 7 (web profile e full profile). Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST. SOAP. Padres de Projetos. Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio ao desenvolvimento de software: Maven. Gerenciadores de verso distribudos (Git e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da Informao. Conceituao e papel da Informao nas organizaes. Implantao da gesto informacional: custos e benefcios. Informao e confiabilidade: a validade dos dados.

00000000000

00000000000 - DEMO




2 Lugar ISS/Salvador https://www.youtube.com/watch?v=vmU1n1J-aqQ Veja outros depoimentos: http://www.estrategiaconcursos.com.br/blog/depoimentos

00000000000

00000000000 - DEMO




CRONOGRAM

Aula Data Tpicos do Edital 00 12/05 - Aula Demonstrativa

01 14/05 - Metodologias e prticas de desenvolvimento de software. Scrum. Extreme Programming (XP). Prticas geis. Kanban. Test Driven Development. Behavior Driven Development.

02 17/05 - Engenharia de Software: Engenharia de Requisitos. Tcnicas de levantamento de requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos. Verificao e validao de requisitos. Requisitos funcionais e no funcionais.

03 24/05 - Mtricas de Software. Ponto de funo. Mtricas geis.

04 31/05 - Anlise e projeto orientado a objetos.

05 07/06 - Processo Unificado.

06 14/06 - Testes. Processos de testes. Tipos e estratgias. Planejamento e acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade. Tolerncia a falhas. Interoperabilidade. Usabilidade. Integrao Contnua. Anlise automatizada e Reviso de cdigo.

07 21/06 - Linguagens de programao. Java.

08 28/06 - HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS. Tecnologias Java. Java EE 6 e 7 (web profile e full profile).

09 05/07 - Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST. SOAP.

10 12/07 - Padres de Projetos.

11 19/07 - Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio ao desenvolvimento de software: Maven. Gerenciadores de verso distribudos (Git e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da Informao. Conceituao e papel da Informao nas organizaes. Implantao da gesto informacional: custos e benefcios. Informao e confiabilidade: a validade dos dados.

00000000000

00000000000 - DEMO




AS AULAS E AS DICAS

1 Pargrafos pequenos: observem que os pargrafos tm, no mximo, cinco linhas. Isso serve para que a leitura no fique cansativa e para que vocs no desanimem no meio do material! Para tal, eu tento dividir as disciplinas de maneira que as aulas fiquem objetivas e pequenas (em termos de teoria), mas extensa (em termos de exerccios).

2 Viso Geral: no se atenham a detalhes antes de entender o bsico. Por que? Ora, no h nada mais irritante do que ir para uma prova que vai cair, por exemplo, RUP, saber vrios detalhes, mas no saber as fases e disciplinas. Portanto, caso estejam iniciando os estudos sobre uma matria, foquem em saber o bsico para depois se especializarem.

3 Destaques em vermelho: quase todos os pargrafos possuem alguma palavra ou frase destacada em negrito e em vermelho. Isso ocorre por suas razes: primeiro, para enfatizar alguma informao importante; segundo, para facilitar a leitura vertical, i.e., aps uma primeira leitura, a segunda pode ser passando apenas pelos pontos em destaque.

4 Faam muitos exerccios: ler vrias bibliografias muito trabalhoso e, geralmente, no vale o custo-benefcio. Acredito que o que funciona mesmo entender o bsico, depois fazer muitos exerccios e, eventualmente, caso encontrarem algo que no souberem, pesquisem-no separadamente. Alm disso, YRFrYDLSHJDQGRDVPDQKDVGDEDQFD

5 Linguagem natural: essa uma aula para ser lida, o que por si s j pode ser cansativo. Tentarei colocar a linguagem mais coloquial possvel, simulando uma conversa. Portanto, caso virem frases ou palavras em itlico, ou uma palavra estrangeira ou a simulao de uma conversa com vocs. Pode dar um exemplo, professor? Acabei de dar! :-)

6 Faam resumos: essa dica somente serve caso vocs tenham disponibilidade. Caso haja pouco tempo para estudar ou pouco tempo at a prova, no compensa! Se no, faam resumos organizados, pois eles economizaro um bom tempo de estudo em suas prximas provas e sempre que descobrirem novas informaes, insiram-nas no resumo.

7 Diversas figuras: essas aulas estaro em constante evoluo, sempre procura de explicar as matrias de maneira mais compreensvel e com novas informaes/questes. Para tal, na minha opinio, fundamental a utilizao de figuras, grficos, painis, etc. Em minha experincia, bem mais fcil memorizar a partir de imagens.

8 Revisem antes da prova: no adianta querer estudar coisas novas at o ltimo minuto antes da prova e no revisar o que estudou h um ms. Vocs iro esquecer e iro se irritar na hora da prova por no lembrarem de conceitos simples. Tirem uma semana para revisar seus resumos, decorarem algumas coisas e, certamente, iro mais confiantes para a prova.

9 Fazer Exerccios: muitos exerccios o meio pelo qual vocs se situaro. Como assim, professor? na hora de fazer os exerccios que vocs descobriro se esto bem ou mal e avaliaro se precisam estudar mais ou menos. Para tal, h um quadrinho ao final de cada bloco de exerccios para vocs anotarem a quantidade de questes respondidas corretamente ou incorretamente.

10 Simulado Final: ora, fazer um bloco de questes depois de estudar a teoria tranquilo. No entanto, lembrem-se que a memria de vocs no infinita e vocs tm um milho de outras coisas para estudar e decorar. Portanto, se possvel, ao fim do curso faremos um simulado com questes escolhidas que foram comentadas dentro das aulas.

Bem, pessoal! isso... sejam bem vindos! Espero que vocs curtam e tenham uma leitura leve e despojada da aula, mas com muito foco, ateno e dedicao. Qualquer dvida, podem entrar em contato comigo ficarei feliz em ajud-los. Bons estudos, estou torcendo por vocs! Fiquem agora com algumas mensagens de incentivo para anim-los ;-)

00000000000

00000000000 - DEMO




R$8.863,84 R$8.863,84 R$8.863,84 R$8.863,84

R$8.863,84

00000000000

00000000000 - DEMO




1. CICLO DE VIDA DE SOFTWARE

O Ciclo de Vida de Software se refere s fases pelas quais um sistema de software atravessa desde sua concepo at sua retirada de produo. Galera, no confundam Ciclo de Vida de Software com Ciclo de Vida de Desenvolvimento de Software (inclusive, muitas bancas erram nesse ponto), entretanto fiquem relaxados, porque essa diferena geralmente no cobrada. Fazendo um paralelo com o PMBOK, o Ciclo de Vida do Projeto seria o Ciclo de Vida do Desenvolvimento de Software e o Ciclo de Vida do Produto seria o Ciclo de Vida do Software. O PMBOK diz que cada projeto deve especificar seu prprio ciclo de vida, mas sugere fases genricas: Incio do Projeto, Organizao e Preparao, Execuo do Trabalho e Encerramento do Projeto.

Metodologias e prticas de desenvolvimento de software. Scrum. Extreme Programming (XP). Prticas geis. Kanban. Test Driven Development. Behavior Driven Development. Engenharia de Software: Engenharia de Requisitos. Tcnicas de levantamento de requisitos. Casos de uso. Histrias de usurios. Gerncia de requisitos. Verificao e validao de requisitos. Requisitos funcionais e no funcionais. Mtricas de Software. Ponto de funo. Mtricas geis. Anlise e projeto orientado a objetos. Processo Unificado. Testes. Processos de testes. Tipos e estratgias. Planejamento e acompanhamento. Mtricas de testes. Qualidade de Software. Conformidade. Tolerncia a falhas. Interoperabilidade. Usabilidade. Integrao Contnua. Anlise automatizada e Reviso de cdigo. Linguagens de programao. Java. HTML. Linguagens dinmicas (Python, Ruby e Groovy). Javascript. CSS. Tecnologias Java. Java EE 6 e 7 (web profile e full profile). Arquitetura de Software: Arquiteturas em camadas. SOA. Web services. REST. SOAP. Padres de Projetos. Portais corporativos. Gesto eletrnica de documentos. Ferramentas de apoio ao desenvolvimento de software: Maven. Gerenciadores de verso distribudos (Git e Mercurial). Eclipse. Netbeans. Jenkins. Gesto da Informao. Conceituao e papel da Informao nas organizaes. Implantao da gesto informacional: custos e benefcios. Informao e confiabilidade: a validade dos dados.

00000000000

00000000000 - DEMO




Da mesma forma que o Ciclo de Vida do Projeto est contido em um Ciclo de Vida do Produto, o Ciclo de Vida de Desenvolvimento de Software est contido em um Ciclo de Vida do Software. Fazendo um paralelo, podemos ver cada fase do ciclo de vida do software como um projeto! Em outras palavras, podemos tratar a Definio, Desenvolvimento, Operao e Retirada como um projeto. O Ciclo de Vida apenas a ordem global das atividades desempenhadas no s no desenvolvimento de software, mas tambm em sua evoluo, manuteno e retirada. Infelizmente no h um consenso entre os autores a respeito dos estgios, mas comum as seguintes fases: Definio ou Concepo, Desenvolvimento ou Construo, Operao ou Utilizao e Retirada ou Aposentadoria.

Na Definio, busca-se entender o problema a ser resolvido pelo software. No Desenvolvimento, busca-se construir o software de acordo com uma srie de requisitos. Na Operao, ocorre a entrega, distribuio, instalao, configurao,

00000000000

00000000000 - DEMO




utilizao e manuteno do software. Por fim, na Retirada, aposenta-se o software de vez! isso... simples, no?! ;)

00000000000

00000000000 - DEMO




2. PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

De acordo com Sommerville, o termo Ciclo de Vida de Desenvolvimento de Software foi criado originalmente para se referir ao Modelo em Cascata, sendo atualmente bastante utilizado como um sinnimo de Processo ou Metodologia de Desenvolvimento Software. E o que seria isso? Um conjunto de atividades, cuja meta o desenvolvimento ou a evoluo de um software. Sendo mais detalhista, o processo de desenvolvimento de software refere-se s atividades, relacionamentos, artefatos, ferramentas, papis, etc necessrios para construir, entregar e manter um produto de software. J o ciclo de vida de desenvolvimento de software apresenta uma representao mais alto nvel do processo de software executado. Galera, vocs no precisam se preocupar com isso! Nunca vi essa diferena ser cobrada em prova. Alis, comum que as bancas as tratem como sinnimos. Pessoal, coloquei na imagem abaixo os principais grupos de modelos de desenvolvimento de software. Essa classificao no um consenso entre os autores e nem so mutuamente exclusivas, podendo haver combinao entre elas.

00000000000

00000000000 - DEMO




A tabela abaixo apresenta um comparativo entre os principais modelos de processos de desenvolvimento de software, com as principais caractersticas a serem observadas antes de escolher o ciclo de vida adequado. Pessoal, isso uma orientao genrica, no exato para todos os conceitos, mas ajuda bastante a entend-los. Vejamos a tabela:

MODELO FOCO REQUISITOS 1 VERSO P/ CLIENTE GERENCIAMENTO

CASCATA Documentos e artefatos

Bem conhecidos e estticos Fim do ciclo 1

INCREMENTAL Incrementos operacionais

Mais abstratos; tratados em mdulos

Prottipos operacionais 3

EVOLUTIVO Evoluo dos requisitos

Pouco conhecidos Prottipos operacionais 4

RAD Rapidez de desenvolvimento

Escopo restrito; mais abstratos; tratado em mdulos

Prottipos operacionais 5

PROTOTIPAGEM Dvidas nos requisitos

Mais abstratos Prottipos no operacionais

5

ESPIRAL Anlise de Risco

Mais abstratos; evoludos com o tempo

Prottipos operacionais ou no operacionais

5

RUP Frameworks e boas prticas

Mais abstratos; evoludos com o tempo

Prottipos operacionais ou no operacionais

5

A ltima coluna, referente ao gerenciamento, revela em uma escala de 1 a 5 a dificuldade de gerenciamento de cada processo (sendo 1 mais simples e 5 mais complexo). O que diferencia um processo de software de outro a ordem em que as fases vo ocorrer, o tempo e a nfase dados a cada fase, as atividades presentes em cada um, e os produtos entregues como resultado. Pessoal, a qualidade de um produto de software depende fortemente da qualidade do processo de software utilizado em seu desenvolvimento. Logo, essencial ter um processo de software adequado para se obter produtos de software de qualidade. Seguir um processo de software mal escolhido ou definido pode ocasionar prejuzos no andamento do projeto.

00000000000

00000000000 - DEMO




(CESPE TCE/TO Analista de Sistemas - Quanto maior e mais complexo o projeto de software, mais simples deve ser o modelo de processo a ser adotado.

Comentrios: Galera, no existe essa relao! Em geral, quanto mais complexo o projeto mais complexo o modelo. No entanto, isso tambm no uma regra.

Gabarito: E

(CESPE TCE/TO Analista de Sistemas - O modelo de ciclo de vida

do software serve para delimitar o alvo do software. Nessa viso, no so consideradas as atividades necessrias e o relacionamento entre elas.

Comentrios: Pelo contrrio, o alvo do software serve para delimitar o modelo de ciclo de vida a ser escolhido. Ademais, so consideradas as atividades necessrias e o relacionamento entre elas.

Gabarito: E

(CESPE TCE/TO Analista de Sistemas - A escolha do modelo do

ciclo de vida no depende de caractersticas especficas do projeto, pois o melhor modelo sempre o mais usado pela equipe do projeto.

Comentrios: No faz o menor sentido! A escolha depende das caractersticas do projeto.

Gabarito: E

ACERTEI ERREI

00000000000

00000000000 - DEMO




3. MODELO EM CASCATA

Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de uma fase com a outra. Os estgios do modelo demonstram as principais atividades de desenvolvimento. Observem a imagem mais abaixo! No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos:

00000000000

00000000000 - DEMO




De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja satisfeito com os resultados alcanados. Vocs conseguem perceber como essas restries engessam o desenvolvimento?

Por Sommerville

Por Yourdon

Por Pressman (4 Ed.)


Por Royce

Definio de Requisitos

Requisitos de Sistema

Modelagem e Engenharia do

Sistema/Informao

Comunicao Elicitao de Requisitos

Projeto de Sistema e Software

Requisitos de Software

Anlise de Requisitos de Software

Planejamento Projeto

Implementao e Teste de Unidade

Anlise Projeto Modelagem Construo

Integrao e Teste de Sistema

Projeto Gerao de Cdigo Construo Integrao

Operao e Manuteno

Codificao Teste e Manuteno Implantao Teste de Depurao

Teste Instalao

Operao Manuteno de Software

Percebam que h diferenas gritantes entre os autores! Inclusive, h divergncias at entre autor e ele mesmo, dependendo da verso do livro (Exemplo: Pressman mudou as fases na ltima edio de seu livro). Professor, voc j viu isso cair em prova? Sim, j vi! E o que aconteceu? Bem, polmica, recursos, etc! No h o que fazer... minha classificao preferida a do Yourdon. Na prtica, esses estgios no so completamente sequenciais, i.e., eles se sobrepem e trocam informaes entre si. Na teoria, so fases sequenciais com o resultado de cada fase consistindo em um ou mais documentos aprovados ou no, dependendo dos problemas. Por exemplo: durante o projeto, so identificados problemas com requisitos. De modo geral, grande parte dos modelos possuem as seguintes fases:

Planejamento: faz-se o esboo do escopo e dos requisitos, alm de estimativas razoveis sobre recursos, custos e prazos.

00000000000

00000000000 - DEMO




Anlise e Especificao de Requisitos: durante essa fase, refina-se os requisitos e o escopo e desenha-se o problema em questo.

Projeto: durante essa fase, incorpora-se requisitos tecnolgicos aos requisitos

essenciais do sistema e projeta-se a arquitetura do sistema.

Implementao: durante essa fase, codifica-se o software como um conjunto de programas executveis pela mquina.

Teste: o programa testado como um sistema completo para garantir que

os requisitos de software foram atendidos.

Implantao, Operao e Manuteno: o sistema de software liberado para o cliente, treina-se usurios, gerencia servios e realiza manutenes.

Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde as primeiras fases do processo de desenvolvimento.

Percebam que os riscos deveriam ser descobertos logo no incio do processo de desenvolvimento, porm eles so descobertos somente aps o incio dos testes e integrao. Vocs podem notar que, nesse instante (parte vermelha), o progresso do projeto avana e retrai diversas vezes, porque o sistema est sendo corrigido devido a requisitos modificados. Vejam, tambm, que o projeto no terminou em seu deadline original. Como a reduo dos riscos atrasou, todo andamento do projeto tambm atrasou. Dessa

00000000000

00000000000 - DEMO




forma, no se cumpriu nem o prazo do projeto e, provavelmente, nem o oramento e talvez seu escopo tendo em vista que, quanto mais ao fim do projeto um erro identificado, mais caras se tornam as modificaes. Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um custo de correo altssimo, visto que provavelmente ter que se refazer tudo novamente. Ora, se eu peo a construo de um carro e voc constri uma moto, o custo para corrigir esse erro ser altssimo. Portanto no confundam essas duas coisas: o erro ocorreu no incio e foi identificado no incio, ter baixo custo de correo; se o erro ocorreu no incio e foi identificado no final, ter alto custo de correo. O custo de correo de um erro est mais focado no momento em que um erro identificado do que no momento em que ele ocorre. Bacana?

Outra maneira de visualizar o atraso por meio de um grfico Risco x Tempo, comparando o modelo em cascata com o Modelo Iterativo e Incremental. Observem que o Modelo Iterativo e Incremental j comea a reduzir os riscos desde o incio

00000000000

00000000000 - DEMO




do processo, em contraste com o Modelo em Cascata que acumula os riscos at a fase de testes, integrao e implantao do sistema. Galera, a grande vantagem do Modelo em Cascata que o desenvolvimento dividido em fases distintas, padronizadas, etc (antigamente, os softwares eram construdos artesanalmente). possvel colocar pessoas com perfis especficos para cada fase, i.e., quem tem facilidade de se comunicar vai ser analista de requisitos, programadores vo fazer a codificao, etc. A grande desvantagem que - em projetos complexos demora-se muito para chegar at a fase de testes, sendo que o cliente no v nada rodando at a implantao. Ento, pode acontecer de, nas fases finais, os requisitos da organizao no serem mais os mesmos daqueles do incio e o software no ter mais utilidade para organizao. Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese? Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer preferencialmente quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs entenderam?

Vantagens Desvantagens

simples de entender e fcil de aplicar, facilitando o planejamento.

Diviso inflexvel do projeto em estgios distintos.

Fixa pontos especficos para a entrega de artefatos.

Dificuldade em incorporar mudanas de requisitos.

Funciona bem para equipes tecnicamente fracas. Clientes s visualizam resultados prximos ao final do projeto.

fcil de gerenciar, devido a sua rigidez. Atrasa a reduo de riscos.

Realiza documentao extensa por cada fase ou estgio.

Apenas a fase final produz um artefato de software entregvel.

Possibilita boa aderncia a outros modelos de processo.

Cliente deve saber todos os requisitos no incio do projeto.

Funciona bem com projetos pequenos e com requisitos bem conhecidos.

No fornece feedback entre as fases.

Pressupe que os requisitos ficaro estveis ao longo do tempo.

No funciona bem com projetos complexos e orientados a objetos, apesar de compatvel.

00000000000

00000000000 - DEMO




(CESGRANRIO 2010 PETROBRS Analista de Sistemas Processos de Negcio) No Ciclo de Vida Clssico, tambm chamado de Modelo Sequencial Linear ou Modelo Cascata, apresentada uma abordagem sistemtica composta pelas seguintes atividades:

a) Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e

Manuteno.

b) Modelagem e Engenharia do Sistema/Informao, Anlise de Requisitos de Software, Projeto, Gerao de Cdigo, Teste e Manuteno.

c) Modelagem e Engenharia do Sistema/Informao, Projeto, Gerao de

Cdigo, Teste e Manuteno.

d) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo e Manuteno e Anlise de Requisitos de Software.

e) Levantamento de Requisitos de Software, Projeto, Gerao de Cdigo, Teste

Progressivo e Manuteno. Comentrios:

Por Sommerville

Por Yourdon



Por Royce




Sistema/Informao










Operao e Manuteno


Teste Instalao

00000000000

00000000000 - DEMO





A Letra B est correta de acordo com o Pressman 4 Edio, mas est errada de acordo com o Pressman 6 Edio. Ademais, na questo ele sequer disse que era de acordo com o Pressman. Portanto, percebam que um assunto polmico e que as bancas deveriam ignorar, mas eventualmente elas cobram mesmo assim.

Gabarito: B

(CESPE INMETRO Analista de Sistemas) Em uma empresa que tenha

adotado um processo de desenvolvimento de software em cascata, falhas no levantamento de requisitos tm maior possibilidade de gerar grandes prejuzos do que naquelas que tenham adotado desenvolvimento evolucionrio.

Comentrios:

Vantagens Desvantagens simples de entender e fcil de aplicar, facilitando o planejamento.













No funciona bem com projetos complexos e orientados a objetos.

O Modelo em Cascata, de fato, no reage bem a mudanas. J Modelo evolucionrio mais adaptvel a mudanas por se utilizar de iteraes.

Gabarito: C

00000000000

00000000000 - DEMO




(CESPE 2011 MEC Analista de Sistemas) O modelo Waterfall tem a vantagem de facilitar a realizao de mudanas sem a necessidade de retrabalho em fases j completadas.

Comentrios:















Pelo contrrio, h dificuldade de lidar com requisitos volteis, tendo em vista que dependendo do erro, necessrio refaz-lo desde seu incio.

Gabarito: E

(CESPE 2008 TST Analista de Sistemas) No modelo de desenvolvimento

sequencial linear, a fase de codificao a que gera erros de maior custo de correo.

Comentrios: Entenderam essa parte direitinho? Um erro na fase de requisitos, por exemplo, que no foi corrigido e foi descoberto no final do processo de desenvolvimento, ter um custo de correo altssimo, visto que provavelmente ter que se refazer tudo novamente. Ora, se eu peo a construo de um carro e voc constri uma moto, o custo para corrigir esse erro ser altssimo.

00000000000

00000000000 - DEMO




Portanto no confundam essas duas coisas! Percebam o que eu disse: quanto mais tarde se descobre um erro, mais caro se torna sua correo. Dizendo isso de outra forma: erros nas fases iniciais possuem custo de correo altssimo. Uma coisa o momento em que o erro ocorre (quanto mais cedo, mais caro); outra coisa o momento em que um erro identificado (quanto mais tarde, mais caro). Bacana? Percebam que erros nas fases iniciais possuem custos de correo mais altos. Logo, o maior custo est na fase de codificao? No, est na fase de requisitos que a fase inicial!

Gabarito: E

(CESPE INMETRO Analista de Sistemas) Em um processo de

desenvolvimento em cascata, os testes de software so realizados todos em um mesmo estgio, que acontece aps a finalizao das fases de implementao.

Comentrios:

Por Sommerville

Por Yourdon



Por Royce




Sistema/Informao










Operao e Manuteno


Teste Instalao


Todos em um mesmo estgio, no. A grande maioria dos testes ocorrem, de fato, aps a finalizao das fases de implementao. No entanto, podem ocorrer testes unitrios durante a prpria implementao, como mostra o quadro acima.

Gabarito: E

00000000000

00000000000 - DEMO




(FCC - 2012 - - - Analista Judicirio - Anlise de Sistemas - E) Dos diferentes modelos para o ciclo de vida de desenvolvimento de um software correto afirmar que o modelo em cascata o mais recente e complexo.

Comentrios: Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de uma fase com a outra. Os estgios do modelo demonstram as principais atividades de desenvolvimento. Observem a imagem mais abaixo! Mais recente? No, muito antigo! Complexo? No, possui um encadeamento simples de fases.

Gabarito: E

10. (CESPE 2008 SERPRO Analista de Sistemas) O modelo em cascata consiste

de fases e atividades que devem ser realizadas em sequncia, de forma que uma atividade requisito da outra.

Comentrios: No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos: (...) Vimos isso exaustivamente: no modelo em cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior.

Gabarito: C

11. (FCC - - SEFAZ- - Agente Fiscal de Rendas - Tecnologia da Informao

- Prova 3 - O processo de engenharia de software denominado ciclo de vida clssico refere-se ao modelo incremental.

Comentrios:

00000000000

00000000000 - DEMO




Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de uma fase com a outra. Os estgios do modelo demonstram as principais atividades de desenvolvimento. Observem a imagem mais abaixo! No, modelo clssico se refere a modelo em cascata, sequencial, linear, tradicional, waterfall, rgido ou monoltico.

Gabarito: E

12. (CESPE AL/ES Analista de Sistemas - O modelo de desenvolvimento

em cascata descreve ciclos sequenciais, incrementais e iterativos, possuindo, entre outras, as fases de requisitos e implementao.

Comentrios: No! Ele no descreve ciclos, muito menos ciclos iterativos. Na verdade, essa a definio de Modelo Iterativo e Incremental.

Gabarito: E

13. (CESPE 2004 STJ Analista de Sistemas) O modelo de desenvolvimento

seqencial linear, tambm chamado modelo clssico ou modelo em cascata, caracteriza-se por no acomodar adequadamente as incertezas que existem no incio de um projeto de software, em especial as geradas pela dificuldade do cliente de explicitar todos os requerimentos que o programa deve contemplar.

Comentrios: Professor, o que voc quer dizer com atrasar a reduo de riscos? Bem, essa uma desvantagem recorrente em provas. Como uma fase s se inicia aps o trmino da fase anterior, s possvel em geral verificar se houve erros nas ltimas fases como pode ser visto na imagem abaixo. Em outros modelos, os riscos so reduzidos desde as primeiras fases do processo de desenvolvimento. Perfeito, lembrem-se que ele acumula riscos e no lida bem com requisitos volteis.

Gabarito: C

00000000000

00000000000 - DEMO




14. (CESPE IPEA Analista de Sistema) No modelo em cascata de processo de desenvolvimento, os clientes devem definir os requisitos apenas durante a fase de projeto; e os projetistas definem as estratgias de projeto apenas durante a fase de implementao. As fases do ciclo de vida envolvem definio de requisitos, projeto, implementao, teste, integrao, operao e manuteno. Em cada fase do ciclo de vida, podem ser produzidos diversos artefatos.

Comentrios: Essa questo no faz sentido! Os clientes definem os requisitos durante a fase de Definio de Requisitos. J os projetistas definem as estratgias de projeto apenas durante a fase Projeto.

Gabarito: E

15. (CESPE 2008 TCE/TO Analista de Sistema No ciclo de vida em cascata,

possvel realizar alternadamente e simultaneamente as atividades de desenvolvimento de software.

Comentrios: No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos: (...) No, sequencial e linear. No pode ser alternado e simultneo!

Gabarito: E

16. (CESPE 2004 TJ/PA Analista de Sistema A abordagem sistemtica

estritamente linear para o desenvolvimento de software denominada modelo em cascata ou modelo sequencial linear.

Comentrios: Citado inicialmente em 1970 por W. Royce, tambm designado Cascata ou Clssico ou Sequencial ou Linear ou Tradicional ou Waterfall ou Rgido ou Monoltico (todos esses nomes j caram em prova!). Esse nome devido ao encadeamento simples de

00000000000

00000000000 - DEMO




uma fase com a outra. Os estgios do modelo demonstram as principais atividades de desenvolvimento. Observem a imagem mais abaixo! Perfeito! Modelo em Cascata, Linear, Sequencial, Waterfall, etc.

Gabarito: C

17. (CESPE 2006 TSE Analista de Sistema O modelo em cascata organiza

o desenvolvimento em fases. Esse modelo encoraja a definio dos requisitos antes do restante do desenvolvimento do sistema. Aps a especificao e a anlise dos requisitos, tm-se o projeto, a implementao e o teste.

Comentrios:

Por

Sommerville Por

Yourdon Por Pressman

(4 Ed.) Por Pressman

(6 Ed.) Por Royce




Sistema/Informao










Operao e Manuteno


ste Instalao


Perfeito! De fato, segue essa ordem!

Gabarito: C

18. (CESPE INMTRO Analista de Sistema) No desenvolvimento de

software, o modelo em cascata estruturado de tal maneira que as fases que compem o desenvolvimento so interligadas. Nessa situao, o final de uma fase implica o incio de outra.

Comentrios:

00000000000

00000000000 - DEMO




No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos: (...) Perfeito, conforme a definio.

Gabarito: C

19. (CESPE 2010 BASA Analista de Sistema) No modelo em cascata, o projeto

segue uma srie de passos ordenados. Ao final de cada projeto, a equipe de projeto finaliza uma reviso. O desenvolvimento continua e, ao final, o cliente avalia a soluo proposta.

Comentrios: De acordo com Vasconcelos (2006), no Modelo em Cascata, o projeto segue uma srie passos ordenados, ao final de cada fase, a equipe de projeto finaliza uma reviso. Alm disso, o desenvolvimento no continua at que o cliente esteja satisfeito com os resultados alcanados. Vocs conseguem perceber como essas restries engessam o desenvolvimento? Ao final de cada projeto? No! Ao final de cada fase.

Gabarito: E

(CESPE TRE/MT Analista de Sistema - O modelo em cascata apropriado para software em que os requisitos ainda no foram bem compreendidos, pois focado na criao de incrementos.

Comentrios: Professor, ento o Modelo em Cascata no deve ser usado em nenhuma hiptese? Calma l, ele pode ser usado! No entanto, sua utilizao deve ocorrer preferencialmente quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanas radicais durante o desenvolvimento do sistema. Vocs entenderam?

00000000000

00000000000 - DEMO




Pelo contrrio, totalmente errado!

Gabarito: E

21. (CESPE 2009 UNIPAMPA Analista de Sistema O modelo em cascata

sugere uma abordagem sistemtica e sequencial para o desenvolvimento de software. Sua natureza linear leva a estados de bloqueio nos quais, para que nova etapa seja iniciada, necessrio que a documentao associada fase anterior tenha sido aprovada.

Comentrios: No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases! Vejamos: (...) Perfeito! No basta terminar uma fase, necessrio que a sua documentao tenha sido aprovada.

Gabarito: C

(CESPE 2004 ABIN Analista de Sistema) O modelo de desenvolvimento seqencial linear, tambm denominado modelo em cascata, incompatvel com o emprego de tcnica de anlise orientada a objetos no desenvolvimento de um sistema de informao.

Comentrios:









00000000000

00000000000 - DEMO









No funciona bem com projetos complexos e orientados a objetos, apesar de compatvel.

Ele compatvel, mas no recomendado! Por que, no? Imagina um projeto super complexo que utiliza uma anlise orientada a objetos (que um modelo mais sofisticado que a anlise estruturada). Lembre-se que, no Modelo em Cascata, voc no pode errar, porque se voc errar, os riscos de o projeto falhar so enormes! Por essa razo, ele no recomendvel, apesar de compatvel!

Gabarito: E

(CESPE 2004 TRE/AL Analista de Sistema) O modelo cascata ou ciclo de vida clssico necessita de uma abordagem sistemtica, que envolve, em primeiro lugar, o projeto e, em seguida, a anlise, a codificao, os testes e a manuteno.

Comentrios:

Por Sommerville

Por Yourdon



Por Royce




Sistema/Informao










Operao e Manuteno


Teste Instalao


Primeiro Projeto e depois Anlise? No, Anlise vem antes do Projeto!

Gabarito: E

00000000000

00000000000 - DEMO




24. (CESPE MPE/AM Analista de Sistema) O modelo de desenvolvimento

seqencial linear tem como caracterstica principal a produo de uma verso bsica, mas funcional, do software desde as primeiras fases.

Comentrios:

Vantagens Desvantagens

simples de entender e fcil de aplicar, facilitando o planejamento.














Pelo contrrio, somente nas fases finais que se tem uma verso! Essa definio est mais com cara de modelo de desenvolvimento em prototipagem.

Gabarito: E

(VUNESP - 2012 - SPTrans - Analista de Informtica) Uma das abordagens do processo de desenvolvimento da engenharia de software prev a diviso em etapas, em que o fim de uma a entrada para a prxima. Esse processo conhecido como modelo: a) Transformao. b) Incremental. c) Evolutivo. d) Espiral. e) Cascata.

Comentrios:

00000000000

00000000000 - DEMO




No Modelo em Cascata, uma fase s se inicia aps o trmino e aprovao da fase anterior, isto , h uma sequncia de desenvolvimento do projeto. Por exemplo, a Fase 4 s iniciada aps o trmino e aprovao da Fase 3. A Fase 5 s iniciada aps o trmino e aprovao da Fase 4. Mas que fases so essas? Bem, agora que complica, porque cada autor resolve criar suas fases!

Gabarito: E

ACERTEI ERREI

00000000000

00000000000 - DEMO




4. MODELOS ITERATIVOS E INCREMENTAIS

Como foi dito anteriormente, o Modelo em Cascata acumulava riscos e vrios projetos comearam a fracassar ao utiliz-lo no mundo inteiro. Ento surgiu o Modelo Iterativo como uma tentativa de resolver esse problema de acmulo de riscos. Vejamos a diferena fundamental entre o Modelo em Cascata e o Modelo Iterativo:

No Modelo em Cascata, caso haja cem requisitos, analisa-se os cem requisitos, projeta-se os cem requisitos, codifica-se os cem requisitos, testa-se os cem requisitos, e assim, por diante, sequencialmente. No Modelo Incremental, caso haja cem requisitos no projeto, divide-se os

cem requisitos em vinte miniprojetos de cinco requisitos e utiliza-se o modelo em cascata para cada miniprojeto.

Galera, pensem s: possvel combinar a abordagem incremental com uma abordagem iterativa para desenvolver os miniprojetos em paralelo e entregar partes diferentes do projeto. A imagem abaixo apresenta os miniprojetos de cinco requisitos sendo feitos iterativamente e paralelamente em um modelo iterativo e incremental.

00000000000

00000000000 - DEMO




Assim, os resultados so mais rpidos, h maior interao com o usurio e h um feedback mais intenso possvel reagir mais facilmente a mudanas. Essa abordagem permite gerenciamento e mitigao de riscos. Professor, mas eu fiquei com uma dvida: qual a diferena entre Modelo Iterativo e Modelo Incremental? Ou eles so exatamente a mesma coisa? Bem, galera... eu nunca vi nenhuma prova cobrar essa diferena entre modelo iterativo e modelo incremental! Na verdade, quando se fala em modelo iterativo, presume-se que incremental e quando se fala em modelo incremental, presume-se que iterativo. Eles frequentemente andam lado a lado, mas h pequenas diferenas. Professor, mas e se cair em prova? Ora, caso caia em prova, a diferena que, no modelo iterativo, h vrias equipes desenvolvendo uma parte do software a serem integradas no fim e, no modelo incremental, lana-se a verso 1.0, adicionam-se funcionalidades, lana uma verso 2.0, adicionam-se mais funcionalidades e assim por diante.

Modelo Incremental: observem que a imagem mostra um artista com uma ideia completa sobre o quadro, mas ele desenvolve cada parte separadamente at integrar as partes em uma imagem completa. como se fosse um quebra-cabeas em que cada parte entregue funcionando e depois integrada. Produz builds, i.e., partes do software.

IMPORTANTE

Galera, j vi essas palavras serem trocadas dezenas de vezes. No entanto, muitas vezes a prpria banca erra e, s vezes, no volta atrs! Infelizmente isso acontece =(

Iterativo: reiterado ou repetitivo. Interativo: participao ou ao mtua.

00000000000

00000000000 - DEMO




Modelo Iterativo: observem que a imagem mostra um artista com um esboo do quadro, sendo que ele desenvolve vrias verses do quadro at chegar ao resultado final. como se fosse uma viso abstrata da imagem, que em seguida vai sendo melhorada at chegar a uma viso mais concreta. Produz releases, i.e., verses constantemente melhoradas da imagem. Uma das vantagens do modelo iterativo e incremental que o cliente pode receber e avaliar as entregas do produto mais cedo, j no incio do desenvolvimento do software. Alm disso, h maior tolerncia a mudanas com consequncia direta de reduo do risco de falha do projeto, i.e., ele acomoda melhor mudanas. Ele aumenta o reso e a qualidade.

00000000000

00000000000 - DEMO




(CESPE 2011 MEC Anlise de Sistemas) No modelo de prototipao, o processo de desenvolvimento de software modelado como uma sequncia linear de fases, enfatizando um ciclo de desenvolvimento de breve durao.

Comentrios: Na verdade, no linear iterativo.

Gabarito: E

27. (CESPE - 2011 TJ/ES - Analista Judicirio - Anlise de Sistemas - Especficos) O

modelo de processo incremental de desenvolvimento de software iterativo, assim como o processo de prototipagem. Contudo, no processo incremental, diferentemente do que ocorre no de prototipagem, o objetivo consiste em apresentar um produto operacional a cada incremento.

Comentrios: De fato, no modelo iterativo e incremental, apresenta-se sempre um produto a cada incremento. J na prototipao, no. Idealmente, ele serve apenas para identificar requisitos.

Gabarito: C

(CESPE - TJ/DF - Analista Judicirio - Anlise de Sistemas) No modelo de desenvolvimento incremental, embora haja defasagem entre os perodos de desenvolvimento de cada incremento, os incrementos so desenvolvidos em paralelo.

Comentrios: Questo perfeita. Os incrementos so codificados no exatamente em paralelo h uma pequena defasagem.

Gabarito: C

00000000000

00000000000 - DEMO




(CESPE - UNIPAMPA - Anlise de Sistemas) No modelo de desenvolvimento incremental, a cada iterao so realizadas vrias tarefas. Na fase de anlise, pode ser feito o refinamento de requisitos e o refinamento do modelo conceitual.

Comentrios: Perfeito, a fase seguinte fase de requisitos e busca refin-los.

Gabarito: C

ACERTEI ERREI

00000000000

00000000000 - DEMO




5. MODELOS EVOLUCIONRIOS

Antes de comearmos, eu acho oportuno explicar porque alguns autores consideram o Modelo Evolucionrio como um tipo de Modelo Iterativo. Um dos nossos guias, Pressman diz: Os modelos evolucionrios so iterativos, apresentando caractersticas que possibilitam desenvolver verses cada vez mais completas do software. Vamos ver isso melhor? Ok, o tema agora Modelos Evolucionrios! Esse modelo baseia-se na ideia de desenvolvimento de uma implementao inicial, expondo o resultado aos comentrios do usurio e refinando esse resultado por meio de vrias verses at que seja desenvolvido um sistema adequado ou descartando-o. Existem dois tipos fundamentais de desenvolvimento evolucionrio:

Desenvolvimento Exploratrio (ou Evolutivo): comea com as partes do sistema compreendidas e evolui por meio da adio de novas caractersticas propostas pelo cliente at entregar o sistema final.

Prototipao Throwaway: tambm conhecida como descartvel, tem o intuito de compreender os requisitos do cliente e, a partir disso, desenvolver melhor definio de requisitos para o sistema.

Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por que? Porque a especificao pode ser desenvolvida de forma incremental. medida que os usurios compreendem melhor seu problema, isso pode ser refletido no sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no Senado Federal):

O processo no visvel: se os sistemas so desenvolvidos rapidamente, no vivel economicamente produzir documentos para cada verso do sistema.

Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem a corromper a estrutura do software e tornar mudanas difceis e caras.

O Pressman recomenda o Desenvolvimento Evolucionrio para sistemas de pequeno e mdio porte (at 500 mil linhas de cdigo). J para sistemas maiores e mais complexos, esses problemas supracitados tornam-se mais graves. difcil

00000000000

00000000000 - DEMO




estabelecer uma arquitetura estvel, tornando difcil integrar as contribuies das equipes. Vamos resumir? um modelo que apresenta uma verso inicial aos usurios, com os requisitos mais bem compreendidos, para refinamento do resultado verso a verso. Pode ser Evolucionrio (quando evolui at o sistema final) ou Throwaway (quando descartado). Ademais, recomendado para sistemas de pequeno e mdio porte.

Um esboo simples do processo de desenvolvimento evolucionrio apresentado na imagem acima. As atividades de especificao, desenvolvimento e validao so intercaladas, em vez de separadas, com feedback rpido que permeia as atividades. H dois modelos principais de desenvolvimento evolucionrio: Prototipagem e Espiral.

00000000000

00000000000 - DEMO




(FGV 2008 Senado Federal Analista de Sistemas) No modelo evolucionrio, a mudana constante tende a corromper a estrutura do software.

Comentrios: Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por que? Porque a especificao pode ser desenvolvida de forma incremental. medida que os usurios compreendem melhor seu problema, isso pode ser refletido no sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no Senado Federal):


Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem

a corromper a estrutura do software e tornar mudanas difceis e caras. Logo, percebemos que exatamente isso que acontece!

Gabarito: C

31. (CESPE DETRAN/DF Analista de Sistemas) O modelo de processo de

desenvolvimento de software evolucionrio parte do desenvolvimento de uma implementao inicial cujos resultados so apresentados aos clientes e refinados por meio de vrias verses at que se alcance o sistema adequado. A prototipao, como processo, tem por objetivo compreender as especificaes do software para se chegar aos requisitos para o sistema.

Comentrios: Como ? Compreender as especificaes para chegar aos requisitos? No, isso no faz sentido! compreender os requisitos para chegar especificao.

Gabarito: E

00000000000

00000000000 - DEMO




(CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria no gera problemas de manuteno de sistema porque o desenvolvimento rpido e no sofre grandes mudanas.

Comentrios: Em geral, a abordagem evolucionria mais eficaz que abordagem em cascata. Por que? Porque a especificao pode ser desenvolvida de forma incremental. medida que os usurios compreendem melhor seu problema, isso pode ser refletido no sistema de software. Essa abordagem possui dois problemas (inclusive, j caram no Senado Federal):


Os sistemas so frequentemente mal estruturados: mudanas contnuas tendem

a corromper a estrutura do software e tornar mudanas difceis e caras. Gera problemas, sim! Muitas mudanas tendem a corromper a estrutura do software e isso as torna difceis e caras.

Gabarito: E

(CESPE TJ/DF Analista de Sistemas) A prototipao evolucionria permite que a verso inicial do prottipo seja desenvolvida e refinada em estgios sequenciados, at que se chegue verso final do sistema.

Comentrios: Ok, o tema agora Modelos Evolucionrios! Esse modelo baseia-se na ideia de desenvolvimento de uma implementao inicial, expondo o resultado aos comentrios do usurio e refinando esse resultado por meio de vrias verses at que seja desenvolvido um sistema adequado ou descartando-o. Existem dois tipos fundamentais de desenvolvimento evolucionrio:

Desenvolvimento Exploratrio (ou Evolutivo comea com as partes do sistema compreendidas e evolui por meio da adio de novas caractersticas propostas pelo cliente at entregar o sistema final.

Perfeito, essa a prototipao evolucionria ou exploratria.

00000000000

00000000000 - DEMO




Gabarito: C

ACERTEI ERREI

00000000000

00000000000 - DEMO




6. SCRUM

Algum de vocs sabe de onde vem esse nome? No? Ento eu vou contar! Esse nome vem do Rugby e utilizado como uma metfora para refletir o alto grau de cooperao necessria para obter sucesso. Imagino que poucos de vocs entendam as regras desse esporte, portanto vou explicar de forma bastante objetiva o porqu dessa metfora ser utilizada. Nesse esporte, um time pontua quando a bola cruza a linha de gol e toca o cho sendo carregada ou por meio de um passe. Caso o jogador seja derrubado, ele deve soltar a bola, e a jogada se reinicia! Deve haver intensa troca de passes entre os jogadores, de modo a deix-los menos vulnerveis a serem derrubados por outros jogadores.

Bem... cada jogada se inicia quando um Scrum realizado, isto , forma-se uma parede de fora entre os jogadores, como mostra a imagem acima. Observem que os jogadores se renem de forma bastante prxima, unindo suas foras e habilidades para trabalhar em conjunto e harmonicamente a fim de conseguir recuperar a bola.

00000000000

00000000000 - DEMO




Percebam, portanto, que o time inteiro deve trabalhar para que a equipe possa pontuar. Diferentemente do Futebol Americano, no h um quarterback ou uma estrela do time todos tm sua funo e so igualmente importantes! Pois , a histria fica ainda mais interessante: vamos ver uma das recomendaes de ataque do rugby. 3HQVHm continuamente em seu alinhamento em relao ao jogador que carrega a bola e aos jogadores ao seu redor. Trabalhe duro para estar disponvel quando QHFHVViULRObservem como isso importante em metodologias geis: trabalhar duro para ajudar a equipe a obter xito nunca existe: $FKRTXHQmRKiQDGDDTXLSDUDHXID]HUDJRUD! Acho que agora ficou mais fcil entender de onde vem esse nome vamos teoria? Antes de comear, uma observao: o Guia Oficial do Scrum um documento to pequeno (so apenas 18 pginas) que eu recomendo fortemente que vocs leiam-no por inteiro, pois ser muito til! Tem verso em portugus, gratuito, ento no custa nada l-lo. Bem... agora sim vamos ao trabalho! Scrum um framework (isto , possui uma estrutura processual) leve, simples de entender e extremamente difcil de dominar, para desenvolver e manter produtos complexos e adaptativos, enquanto entrega produtiva e criativamente produtos com o mais alto valor possvel. Complicado ou no? Galera, percebam que ele no um processo ou uma tcnica para construir produtos. Ele um framework em que pode ser empregado vrios processos e tcnicas. Pode ser definido como um conjunto de papis, eventos, artefatos e regras associadas a uma equipe. Ele fundamentado em teorias empricas de controle de processo e emprega uma abordagem iterativa e incremental (maximizando as oportunidades de feedback) para aperfeioar a previso e controle de riscos. O empirismo afirma que o conhecimento vem da experincia e da tomada de decises com base naquilo que verdadeiro e conhecido. Para tal, ele emprega uma abordagem iterativa e incremental para aperfeioar e otimizar a previsibilidade e controle de riscos, fundamentando-se para tal em trs pilares fundamentais: transparncia, inspeo (verificao) e adaptao.

Transparncia: aspectos significativos (e padronizados) devem estar visveis aos responsveis pelos resultados. Por exemplo: uma linguagem comum a todos os participantes.

00000000000

00000000000 - DEMO




Inspeo: os usurios devem frequentemente inspecionar os artefatos e o progresso, para detectar indesejveis variaes (no pode ser frequente a ponto de atrapalhar a execuo das tarefas).

Adaptao: o processo ou material sendo produzido deve ser adaptado

sempre que um inspetor verificar desvios que tornem o resultado inaceitvel e, para tanto, ele tem quatros oportunidades (as reunies).

O Scrum define o conceito de Time Scrum que um time auto-organizvel (escolhe qual a melhor forma para realizar seu trabalho) e multifuncional (possui todas as competncias e no depende de outros de fora da equipe). o responsvel por entregar produtos de forma iterativa e incremental, maximizando as oportunidades de realimentao. As entregas ou verses incrementais de produto (conhecido como SURQWR) garantem que uma verso potencialmente funcional do produto do trabalho esteja sempre disponvel. Agora o mais importante: o Time Scrum composto por: Product Owner, um Scrum Master e uma Equipe de Desenvolvimento galera, no confundam Equipe de Desenvolvimento com Time Scrum. Product Owner: o responsvel por maximizar o valor do produto e do trabalho da equipe de desenvolvimento, sendo o nico que pode gerenciar o Product Backlog. Ele pode at delegar as atividades de gerenciamento, mas ainda ser considerado o responsvel pelos resultados. A Equipe de Desenvolvimento s responde a ele! Equipe de Desenvolvimento A Equipe de Desenvolvimento no reconhece ttulos para seus integrantes, todos so considerados desenvolvedores (no importa o que faam). A Equipe deve ter entre 3 e 9 integrantes, de modo que no seja pequena demais que haja restries de habilidades nem grande demais que seja complicado de gerenciar. Scrum Master o facilitador que garante que o Scrum seja entendido e aplicado. Ademais, ele deve comunicar claramente a viso, objetivo e itens do Product Backlog; ensinar a equipe a criar itens claros e concisos; treinar a equipe de desenvolvimento em autogerenciamento e interdisciplinaridade; remover impedimentos; entre outros. Certa vez, uma aluna me falou o seguinte: 3URIHVVRUQDPLQKDRSLQLmRRFRQWUROHe gerenciamento do projeto no descentralizado nesses trs papis. O Product

00000000000

00000000000 - DEMO




Owner que responde pelo sistema, logo o gerenciamento e controle no descentralizado centralizado no PO!. Eu resolvi, ento, fazer uma historinha para que ela pudesse entender melhor. mais ou menos assim... Imaginem que Joo deseja construir uma casa. Para tal, ele contrata uma renomada empresa de engenharia. A empresa ir fornecer todo seu know-how por meio de uma Equipe de Construo de Casas, que ser composta por uma Equipe de Pedreiros, um Mestre de Obras e... por voc! Sim, voc far parte da Equipe de Construo de Casas como principal parte interessada. Vamos dar um nome para voc? Voc ocupar o cargo de Dono da Casa. Ora, ento, a Equipe de Construo de Casas ser composta por uma Equipe de Pedreiros, um Mestre de Obras e o Dono da Casa. E qual a funo de cada um? Bem, a Equipe de Pedreiros composta por 3 a 9 pedreiros multidisciplinares i.e., todos dominam todas as atividades de um pedreiro. Eles so os responsveis por colocar a mo na massa, levantar parede, fazer o concreto, alinhar o piso, etc. J o Mestre de Obras o grande facilitador! Como assim, professor? Ele vai retirar os impedimentos que aparecem no decorrer do nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele ir buscar uma maneira de reduzir os impactos dessa ausncia. Os pedreiros esto desmotivados, distrados, descuidados? Ele ir arrumar uma maneira de solucionar isso. Um pedreiro saiu na porrada com outro? Ele ir intermediar o conflito. Alm disso, ele o cara que vai trazer a demanda do Dono da Casa, entender o que ele quer e passar de maneira simples, clara e objetiva para a Equipe de Pedreiros. E, por fim, ele tambm ir treinar a equipe para que ela seja auto gerencivel e interdisciplinar. E voc? Qual a sua funo? Voc o Dono da Casa voc que gerencia o que ser feito e o que no ser feito. Voc o responsvel pelo que ser entregue. A Equipe de Pedreiros responde a voc! O Mestre de Obras responde a voc! Voc o cara que tem que tentar fazer essa casa ficar o melhor possvel (Mximo Valor Agregado). Voc o cara que vai priorizar o que deve ser feito primeiro. Voc o cara que coloca ou tira atividades da lista atividade a serem realizadas. Voc o nico cara que pode simplesmente cancelar determinada atividade. Pessoal, h pequenas diferenas, mas a metfora evidente.

00000000000

00000000000 - DEMO




A Equipe de Construo de Casas o Scrum Team; a Equipe de Pedreiros o Development Team; o Mestre de Obras o Scrum Master; e o Dono da Casa o Product Owner. Bacana? Cada um desses tem atividades bem definidas. E o controle sobre essas atividades descentralizado, ou seja, o Dono da Casa no interfere na parte tcnica dos pedreiros, que no interferem no trabalho do Mestre de Obras. Pensem em uma repartio pblica que contm uma Coordenao dividida em 4 gerncias. Ora, o controle e a gesto so descentralizados, feitos por cada gerncia mesmo que todas elas tenham que responder ao coordenador. Bem, acredito que dessa forma consegui convenc-la e faz-la entender melhor o papel de cada um desses caras. Certinho? Ficou mais claro agora? Mudando de assunto, os Eventos Scrum so eventos time-boxed (isto , com durao mxima predefinida) usados para criar uma rotina e minimizar a necessidade de reunies no definidas pelo Scrum. Lembrem-se de que a Sprint tem um ms ou menos e iniciada imediatamente aps a concluso da sprint anterior. As Sprints so compostas por uma Reunio de Planejamento da Sprint, por Reunies Dirias, pelo Trabalho de Desenvolvimento, por uma Reviso da Sprint e pela Retrospectiva da Sprint. Uma sprint se inicia imediatamente aps a concluso da sprint anterior e tem duraes coerentes em todo o esforo de desenvolvimento. Durante a sprint proibido realizar mudanas que afetem o seu objetivo. Alm disso, proibido mudar a composio da equipe ou diminuir as metas de qualidade, apesar disso o escopo pode ser sempre clarificado e renegociado. Uma sprint pode ser cancelada antes de seu time-box terminar e isso somente pode ser feito pelo Product Owner (sob influncia de stakeholders, equipe de desenvolvimento, entre outros). Isso pode ocorrer caso o seu objetivo se torne obsoleto, mas ocorrem tambm devido curta durao e a cancelamentos, porm so raros os casos. O trabalho a ser realizado na Sprint planejado na Reunio de Planejamento da Sprint (Proporcional a 8 horas). Essa reunio consiste em duas perguntas que devem ser adequadamente respondidas:

1. O que ser entregue como resultado do incremento da prxima Sprint? 2. Como o trabalho necessrio para entregar o incremento ser realizado?

00000000000

00000000000 - DEMO




Na primeira parte, a Equipe de Desenvolvimento tenta prever as funcionalidades e sero desenvolvidas durante a Sprint. Na segunda parte, a Equipe de

Desenvolvimento decide como ir construir essas funcionalidades durante a Sprint HGHVHQYROYHR6SULQW%DFNORJ3RUWDQWRDSULPHLUDSDUWHWUDGDGR2TXHID]HU"HDVHJXQGDWUDWDGR&RPRID]HU"

O Product Owner pode estar presente durante a segunda parte da reunio para clarificar itens do Backlog do Produto. A Reunio Diria (Proporcional a 15 minutos) um evento que busca criar um plano para as prximas 24 horas e inspecionar o trabalho desde a ltima Reunio Diria. Ela ocorre sempre no mesmo horrio e no mesmo local e cada integrante deve responder as seguintes perguntas:

1. O que foi completado desde a ltima reunio? 2. O que ser feito at a prxima reunio? 3. Quais os obstculos que esto no caminho?

As Reunies Dirias melhoram a comunicao entre os integrantes, eliminam a necessidade de outras reunies, identificam e removem impedimentos, destacam e promovem rpidas tomadas de deciso, e melhoram o nvel de conhecimento da

00000000000

00000000000 - DEMO




Equipe. A Reviso da Sprint (Proporcional a 4 horas) executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto, se necessrio. Esta uma reunio informal e a apresentao do incremento destina-se a motivar e obter comentrios e promover a colaborao. Nesta reunio, discute-se entre outras coisas: o que foi bem e o que no foi; problemas ocorridos e como foram resolvidos; Product Backlog; projees de datas. O resultado o Product Backlog revisado e ajustado. A Retrospectiva da Sprint (Proporcional a 3 horas) uma chance para o Scrum Team inspecionar a si prprio e criar um plano de melhorias para a prxima sprint. Ela inspeciona como foi a ltima sprint em relao s pessoas, s relaes, aos processos e s ferramentas. Pode identificar e ordenar os itens que se tornaram potenciais de melhorias e cria um plano para implementar melhorias no trabalho.

O Documento de Viso definido pelo Product Owner e representa como os clientes, usurios finais, gerentes, stakeholders, executivos, entre outros, visualizam o resultado final do produto que ser criado. Prticas como Burndown/Burnup tm sido utilizadas para prever o progresso, sem substituir a importncia do empirismo, como mostra a imagem. O Product Backlog uma lista ordenada (por valor, risco, prioridade etc) de tudo que deve ser necessrio no produto, e uma origem nica dos requisitos para qualquer mudana a ser feita no produto. Ele nunca (EU DISSE: NUNCA!) estar

00000000000

00000000000 - DEMO




completo e existir enquanto o produto tambm existir. O ciclo de vida da SCRUM baseado em trs fases principais, divididas em sub-fases: 1) Pr-Planejamento (Pre-game Phase): define o sistema sendo desenvolvido. Cria-

se o Product Backlog, que contm todos os requisitos atuais e informaes sobre o planejamento do projeto. Cria-se tambm uma arquitetura de alto nvel.

2) Desenvolvimento (Game Phase): o sistema desenvolvido em sprints, por meio

de uma abordagem iterativa. A cada sprint, novas funcionalidades so adicionadas de modo tradicional, i.e., anlise, projeto, implementao, etc.

3) Ps-Planejamento (Post-game Phase): aps a fase de desenvolvimento so feitas

reunies para analisar o progresso do projeto e demonstrar o software atual para os clientes. Aqui so feitas as etapas de integrao, testes finais e documentao.

00000000000

00000000000 - DEMO




34. (FCC - 2011 - INFRAERO - Analista de Sistemas - Arquitetura de Software - A)

Um dos principais conceitos do Scrum para atacar a complexidade do desenvolvimento e gerenciamento de software a implantao de um controle descentralizado, capaz de lidar mais eficientemente com contextos pouco previsveis. Para tanto, o gerenciamento distribudo por meio de trs agentes independentes que so: Product Owner, Scrum Team e Scrum Master.

Comentrios: Guia Scrum diz que o Scrum Team dividido em Product Owner, Scrum Master e Development Team. No entanto, a FCC deu a resposta como correto. Por que? No fao ideia!

Gabarito: C

(FCC - 2010 - TRE-RS - Analista Judicirio - Analista de Sistemas Suporte - E Os princpios Scrum so usados para guiar as atividades de desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouo: requisitos, anlise, projeto, evoluo e entrega. Em cada atividade de arcabouo, as tarefas de trabalho ocorrem dentro de um padro de processo chamado sprint.

Comentrios: Perfeito, isso mesmo! Trata-se de uma Sprint.

Gabarito: C

(FCC - 2010 - TRF - 4 REGIO - Analista Judicirio - Tecnologia da Informao- E) Na fase de desenvolvimento do Scrum, o software desenvolvido em processos iterativos denominados Sprint.

Comentrios: Perfeito, isso mesmo! Trata-se tambm de uma Sprint.

00000000000

00000000000 - DEMO




Gabarito: C

37. (FCC - 2010 - TRE-RS - Tcnico Judicirio - Programao de Sistemas - E) Em

reunio, toda conversao restringida s respostas dos elementos s perguntas colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver at a prxima reunio?". As Scrum meetings ocorrem diariamente.

Comentrios: Perfeito! Essa uma das trs perguntas feitas pelo Scrum Master e a Scrum Meeting citada a Daily Scrum Meeting ou Reunio Diria.

Gabarito: C

(FCC - 2011 - INFRAERO - Analista de Sistemas - Gesto de TI - A) Em relao s regras do Scrum, incorreto afirmar que o Sprint deve ser realizado num perodo mximo de 40 dias e ter uma equipe de trabalho no superior a 10 pessoas.

Comentrios: De fato, est incorreto! O perodo mximo de 30 dias e a equipe de trabalho varia de 3 a 9 pessoas.

Gabarito: C

(FCC - 2

curso-6931-aula-00-v1

Documents

Transcript of curso-6931-aula-00-v1