Continue navegando
Prévia do material em texto
Livro Eletrônico Aula 00 Engenharia de Software p/ TRF 2ª Região (Analista Judiciário - Informática - Desenvolvimento) Professor: Diego Carvalho 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 1 de 83 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 2 de 83 AULA 00 SUMÁRIO PÁGINA Apresentação 01 - Metodologias Ágeis 12 - Test-Driven Development (TDD) 30 - Feature Driven Development (FDD) 39 - Dynamic Systems Development Method (DSDM) 47 - Desenvolvimento Adaptativo de Software (DAS) 60 - Modelagem Ágil 56 - Refatoração 60 Lista de Exercícios Comentados 68 Gabarito 82 Olá, sejam bem-vindos! Galera, acaba de sair o edital do concurso do TRF.02 – Rio de Janeiro e Espírito Santo! A prova será somente em março, um ótimo tempo de preparação. Mesmo em tempos de crise, não podemos deixar passar nenhuma chance, além de ser uma ótima oportunidade para se manter estudando. Vamos ficar ligados para não perder o foco e porque a concorrência não dorme! Estou aqui para ajudá-los. Vamos lá... DAS, DSDM, FDD e Modelagem Ágil. Test-driven development (TDD). Refatoração. Metodologias Ágeis de Desenvolvimento de Sistemas: Scrum, XP. Conhecimento em RUP. Processo Unificado Ágil. Engenharia de Requisitos: técnicas de levantamento de requisitos; Casos de uso; Gerência de requisitos; Verificação e validação de requisitos; Requisitos funcionais e não funcionais. Testes: tipos e estratégias de testes. Orientação a Objetos: abstração de dados, definição de classes, métodos e atributos, herança, polimorfismo, encapsulamento, reutilização de componentes. Tratamento de exceções e controle de erros. Engenharia de Software: Análise e Projeto orientado a objetos com UML 2.5: notações, diagramas, metodologia para utilização e ferramentas (Parte I). Orientação a Objetos: abstração de dados, definição de classes, métodos e atributos, herança, polimorfismo, encapsulamento, reutilização de componentes. Tratamento de exceções e controle de erros. Engenharia de Software: Análise e Projeto orientado a objetos com UML 2.5: notações, diagramas, metodologia para utilização e ferramentas (Parte II). Web Services: conceitos básicos, REST, SOAP, UDDI e WSDL. Mensuração de sistemas em Pontos de Função segundo o Manual de Práticas de Contagem (CPM versão 4.3 do IFPUG). 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 3 de 83 O PROFESSOR 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 4 de 83 A AVALIAÇÃO DOS PROFESSORES... 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 5 de 83 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 6 de 83 O CONCURSO. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 7 de 83 O CURSO... 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 8 de 83 CONHEÇA O 6º LUGAR – ISS/SALVADOR https://www.youtube.com/watch?v=b1w4H3l6mC4#t=1678 CONHEÇA O 1º LUGAR – TRT/RJ https://www.facebook.com/video.php?v=790616534367672 CONHEÇA O 2º LUGAR – ISS/SALVADOR https://www.youtube.com/watch?v=vmU1n1J-aqQ CONHEÇA O 1º LUGAR – DATAPREV http://www.estrategiaconcursos.com.br/blog/entrevista-andre-furtado-aprovado-em-1o-lugar-no- concurso-dataprev-para-o-cargo-de-analistaarea-de-tecnologia-da-informacao 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 9 de 83 CRONOGRAM Aula Data Tópicos do Edital 00 26/11 Aula Demonstrativa: DAS, DSDM, FDD e Modelagem Ágil. Test-driven development (TDD). Refatoração. 01 30/11 Metodologias Ágeis de Desenvolvimento de Sistemas: Scrum, XP. 02 16/12 Conhecimento em RUP. Processo Unificado Ágil. 03 29/12 Engenharia de Requisitos: técnicas de levantamento de requisitos; Casos de uso; Gerência de requisitos; Verificação e validação de requisitos; Requisitos funcionais e não funcionais. 04 13/01 Testes: tipos e estratégias de testes. 05 20/01 Orientação a Objetos: abstração de dados, definição de classes, métodos e atributos, herança, polimorfismo, encapsulamento, reutilização de componentes. Tratamento de exceções e controle de erros. Engenharia de Software: Análise e Projeto orientado a objetos com UML 2.5: notações, diagramas, metodologia para utilização e ferramentas (Parte I). 06 07/02 Orientação a Objetos: abstração de dados, definição de classes, métodos e atributos, herança, polimorfismo, encapsulamento, reutilização de componentes. Tratamento de exceções e controle de erros. Engenharia de Software: Análise e Projeto orientado a objetos com UML 2.5: notações, diagramas, metodologia para utilização e ferramentas (Parte II). 07 14/02 Web Services: conceitos básicos, REST, SOAP, UDDI e WSDL. 08 20/02 Mensuração de sistemas em Pontos de Função segundo o Manual de Práticas de Contagem (CPM versão 4.3 do IFPUG). 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 10 de 83 AS AULAS E AS DICAS 1 – Parágrafos pequenos: observem que os parágrafos têm, no máximo, cinco linhas. Isso serve para que a leitura não fique cansativa e para que vocês não 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 exercícios). 2 – Visão Geral: não se atenham a detalhes antes de entender o básico. Por que? Ora, não há nada mais irritante do que ir para uma prova que vai cair, por exemplo, RUP, saber vários detalhes, mas não saber as fases e disciplinas. Portanto, caso estejam iniciando os estudos sobre uma matéria, foquem em saber o básico para depois se especializarem. 3 – Destaques em vermelho: quase todos os parágrafos possuem alguma palavra ou frase destacada em negrito e em vermelho. Isso ocorre por suas razões: primeiro, para enfatizar alguma informação importante; segundo, para facilitar a leitura vertical, i.e., após uma primeira leitura, a segunda pode ser passando apenas pelos pontos em destaque. 4 – Façam muitos exercícios: ler várias bibliografias é muito trabalhosoe, geralmente, não vale o custo- benefício. Acredito que o que funciona mesmo é entender o básico, depois fazer muitos exercícios e, eventualmente, caso encontrarem algo que não souberem, pesquisem-no separadamente. Além disso, você vai pegando as “manhas” da banca. 5 – Linguagem natural: essa é uma aula para ser lida, o que por si só já pode ser cansativo. Tentarei colocar a linguagem mais coloquial possível, simulando uma conversa. Portanto, caso virem frases ou palavras em itálico, ou é uma palavra estrangeira ou é a simulação de uma conversa com vocês. Pode dar um exemplo, professor? Acabei de dar! :-) 6 – Façam resumos: essa dica somente serve caso vocês tenham disponibilidade. Caso haja pouco tempo para estudar ou pouco tempo até a prova, não compensa! Se não, façam resumos organizados, pois eles economizarão um bom tempo de estudo em suas próximas provas e sempre que descobrirem novas informações, insiram-nas no resumo. 7 – Diversas figuras: essas aulas estarão em constante evolução, sempre à procura de explicar as matérias de maneira mais compreensível e com novas informações/questões. Para tal, na minha opinião, é fundamental a utilização de figuras, gráficos, painéis, etc. Em minha experiência, é bem mais fácil memorizar a partir de imagens. 8 – Revisem antes da prova: não adianta querer estudar coisas novas até o último minuto antes da prova e não revisar o que estudou há um mês. Vocês irão esquecer e irão se irritar na hora da prova por não lembrarem de conceitos simples. Tirem uma semana para revisar seus resumos, decorarem algumas coisas e, certamente, irão mais confiantes para a prova. 9 – Fazer Exercícios: muitos exercícios é o meio pelo qual vocês se situarão. Como assim, professor? É na hora de fazer os exercícios que vocês descobrirão se estão bem ou mal e avaliarão se precisam estudar mais ou menos. Para tal, há um quadrinho ao final de cada bloco de exercícios para vocês anotarem a quantidade de questões respondidas corretamente ou incorretamente. 10 – Simulado Final: ora, fazer um bloco de questões depois de estudar a teoria é tranquilo. No entanto, lembrem-se que a memória de vocês não é infinita e vocês têm um milhão de outras coisas para estudar e decorar. Portanto, se possível, ao fim do curso faremos um simulado com questões escolhidas que foram comentadas dentro das aulas. Bem, pessoal! É isso... sejam bem-vindos! Espero que vocês curtam e tenham uma leitura leve e despojada da aula, mas com muito foco, atenção e dedicação. Qualquer dúvida, podem entrar em contato comigo – ficarei feliz em ajudá-los. Bons estudos, estou torcendo por vocês! Fiquem agora com algumas mensagens incentivo para animá-los ;-) 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 11 de 83 R$ 10.119,93 R$ 10.119,93 R$ 10.119,93 R$ 10.119,93 R$ 10.119,93 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 12 de 83 METODOLOGIAS ÁGEIS Em meados de 2001, dezessete especialistas proeminentes da área de desenvolvimento de software se reuniram em um resort em Utah para discutir sobre suas pesquisas e métodos de desenvolvimento de software. Entre eles, estava Martin Fowler (foto ao lado). Após diversos debates, eles redigiram o famoso documento intitulado de Manifesto Ágil para Desenvolvimento de Software, que trazia um conjunto de definições a respeito sobre essa abordagem. Por que valorizar mais indivíduos e suas interações do que processos e ferramentas? Porque, em última instância, quem gera produtos e serviços são os indivíduos, que possuem características únicas, como talento e habilidade. A programação de computadores é uma atividade humana e, assim, depende de questões humanas para seu sucesso. Highsmith afirma que são críticas para o sucesso dos projetos: as habilidades, as personalidades e as peculiaridades dos indivíduos. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 13 de 83 Eles são, muitas vezes, desorganizados e difíceis de entender, mas também são inovadores, criativos e apaixonados. Vale dizer que quanto melhor a equipe interage, mais fácil será a resolução dos problemas no desenvolvimento. O feedback contribui bastante para melhorar essa interação. As habilidades individuais e o trabalho em equipe são inseparáveis em projetos de desenvolvimento de software. E quanto às ferramentas e aos processos? Ora, ambos são importantes para guiar e apoiar o desenvolvimento, mas é a capacidade e o conhecimento dos indivíduos que ajudam a tomar decisões críticas no projeto. Desde quando seguir processos e usar ferramentas, apenas, é suficiente para criar bons softwares? Pois é, sempre são necessárias as habilidades do indivíduo! Por que valorizar mais software em funcionamento do que documentação abrangente? Porque clientes se interessam por resultados que entreguem valor ao negócio e, não, por documentos abrangentes. O software em funcionamento é o único indicador do que, de fato, a equipe construiu. Claro, não se exclui a necessidade de documentação, que é bastante útil para o desenvolvimento, mas deve-se produzir somente a documentação necessária e suficiente para a realização do trabalho. Vou repetir, porque esse assunto cai em prova! No ágil, documentação é descartável? Não! Ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a transferência de conhecimento, preservar informações históricas, satisfazer necessidades contratuais ou legais, etc. A documentação é importante, sim; mas valoriza-se mais o software em funcionamento. Por que valorizar mais colaboração com o cliente do que negociação de contratos? Porque é importante envolvimento contínuo do cliente. Aliás, desenvolvedores e clientes devem estar sempre lado a lado, visto que possuem interesses em comum, i.e., produzir um software que traga valor aos clientes. Galera, ambos são fundamentais, o projeto não sai sem a colaboração com o cliente. Ambos devem tomar decisões em conjunto – colaborativamente –, sem disputas contratuais. Por que valorizar mais a resposta a mudanças do que seguir um planejamento específico? 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 14 de 83 Porque, em geral, é necessário obter respostas rápidas a mudanças e seguir um desenvolvimento contínuo do software. Todo projeto deve balancear o planejamento com a mudança, dependendo do nível de incerteza inerente a ele. Projetos são inerentemente incertos, logo manter-se preso a um planejamento ultrapassado pode ser nocivo ao andamento do projeto. Estamos no século 21! Uma empresa líder de mercado pode acabar de uma hora para outra – a única certeza é a instabilidade! Logo, a equipe deve estar preparada para mudanças no escopo, tempo, custo, tecnologia, arquitetura, entre outros. Iterações curtas de desenvolvimento permitem que mudanças possam ser rapidamente inseridas no projeto, de forma que atendam às novas necessidades. Por fim, o manifesto enfatiza que os itens à direita têm seu valor, entretanto os itens à esquerda são mais valorizados! A charge abaixo brinca com os mitos sobre desenvolvimento ágil. Muitos acreditam que é um desenvolvimento caótico, sem ordem, mambembe, improvisado,sem planejamento e sem documentação, mas com foco em rapidez. Isso é um enorme equívoco! Primeiro, agilidade é diferente de velocidade. A agilidade é a capacidade de responder adequadamente a mudanças (de software, tecnologia, equipes). Quem realiza um desenvolvimento, de fato, veloz ou rápido é o RAD (Desenvolvimento Rápido de Aplicações). Portanto, a agilidade está relacionada a flexibilidade e capacidade de resposta. Para entender essa diferença, eu gosto de utilizar dois exemplos! O Usain Bolt é tricampeão olímpico, mundial, etc... ou seja, ele é geralmente o mais rápido, mas ele tem um problema: sua largada! Ele reage mais lento que seus adversários 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 15 de 83 quando ouve o disparo de início da corrida (mudança), logo podemos dizer que ele é o mais rápido, mas é menos ágil, i.e., ele demora mais a responder a mudanças. Isso ocorre também quando você tem em disputa um carro muito potente e pesado e um carro menos potente e mais leve. É provável que o carro mais leve, mesmo sendo menos potente, tenha uma arrancada melhor, ou seja, ele é mais ágil. Apesar de ser mais lento no decorrer da corrida, ele será mais ágil. Claro, pessoal, que esses são exemplos genéricos – apenas para entender a ideia. Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software. Entretanto, para obtê-la, é essencial que seja projetado para que a equipe possa adaptar e alinhar (racionalizar) tarefas; possa conduzir o planejamento compreendendo a fluidez de uma abordagem do desenvolvimento ágil; possa eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos. Além disso, deve enfatizar a estratégia de entrega incremental, conseguindo entregar ao cliente, o mais rapidamente possível, o software operacional para o tipo de produto e ambiente operacional. Essa são as diretivas para que um processo de software possa ser, também, ágil. Vocês podem notar que segue todos os princípios que nós já vimos em aula. Métodos ágeis são mais dinâmicos, adaptativos, interativos e colaborativos, eles se adaptam às necessidades de um projeto e às suas mudanças no decorrer do desenvolvimento; os tradicionais são mais preditivos/prescritivos, processuais, formais, documentais e contratuais, eles valorizam mais o planejamento de todos os aspectos do processo de desenvolvimento de software como um todo. Entre os princípios do desenvolvimento ágil de software, nós temos: simplicidade; rápida adaptação a mudanças; quaisquer mudanças no projeto são bem-vindas; softwares ou partes de softwares são entregues frequentemente; cooperação constante entre a área de negócio e a área técnica; excelência técnica, entre outros. Galera, já entraram no site do Manifesto Ágil? Entrem aí: www.agilemanifesto.org. NÓS SEGUIMOS ESSES PRINCÍPIOS... Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. As Metodologias Tradicionais preconizavam planos detalhados do projeto; o Ágil busca se adaptar às necessidades dos clientes e entregar valor continuamente. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 16 de 83 Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são preditivas – já vimos que esse cenário é ilusório. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo. As Metodologias Tradicionais realizam, em geral, uma única entrega – ao final do projeto, Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. As Metodologias Tradicionais não valorizavam essa colaboração intensa entre clientes e desenvolvedores, como faz o Ágil. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho. As Metodologias Tradicionais se apoiavam fortemente em processos e ferramentas, em detrimento das pessoas que, de fato, construíam o software. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face. As Metodologias Tradicionais utilizam documentos, diagramas, relatórios, telefonemas para promover a comunicação no projeto. Software funcionando é a medida primária de progresso. As Metodologias Tradicionais propunham a entrega de artefatos (Ex: Documentação) que, em geral, não agregavam valor algum aos clientes, como também uma forma de medir o progresso do projeto. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente. As Metodologias Tradicionais, muitas vezes, patrocinavam horas-extras de forma a fazer a equipe produzir mais em menos tempo. Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias Tradicionais acreditavam que, para se obter máxima velocidade e flexibilidade no desenvolvimento de software, poder-se-ia sacrificar a qualidade deste software. Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As Metodologias Tradicionais, algumas vezes, recorriam a implementações desnecessariamente complexas, a planejamentos exageradamente detalhados, entre outros1. 1 Esse princípio parece não fazer sentido, mas é simples! Deve-se maximizar a quantidade de trabalho não realizado, ou seja, se determinado trabalho não é essencial, não deve ser feito - e isso tem que ser maximizado. A negação dessa frase seria: minimizar a quantidade de trabalho realizado. Ou seja, fazer o mínimo que resolve determinado problema. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 17 de 83 As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As Metodologias Tradicionais geralmente precisam de um gerente de projetos responsável por organizar o trabalho da equipe como um todo, sendo também responsável pela tomada de decisões. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo. As Metodologias Tradicionais muitas vezes são engessadas, i.e., não revisitam frequentemente seu comportamento. Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho e complexidade? Segundo Sommerville: “Todos os métodos têm limites, e os métodos ágeis são somente adequados para alguns tipos de desenvolvimento de sistema. Na minha opinião, eles são mais adequados para o desenvolvimento de sistemas de pequenas e médias empresas e produtos para computadores pessoais”. Eu discordo dessa afirmação! Acredito que ela já foi válida tempos atrás, mas hoje não é mais! Projetos Ágeis já são suficientemente maduros para serem aplicados a projetos complexos e de grande porte. Pessoal, essa é só a minha opinião! Não é possível saber ainda a posição das bancas caso isso seja questionado em provas de concurso. Bacana? Vamos lá... Professor, você pode citar algumas metodologias e frameworks de desenvolvimento de software? Claro, vejam uma lista abaixo: Agora vamos ver algumas diferenças básicas entremetodologias de desenvolvimento software tradicionais e metodologias ágeis: 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 18 de 83 CRITÉRIO TRADICIONAL ÁGIL PLANEJAMENTO Comumente realizado em detalhe para todo o projeto em sua fase inicial. Planejamento de alto nível no início do projeto e os detalhes são realizados durante o projeto. Não é necessário possuir um planejamento detalhado de todo o projeto. A restrição se dá apenas em possuir os detalhes do trabalho para a próxima iteração. RISCOS Pode exigir um grande esforço e equipe para atuar com os riscos de todo o projeto. Prioriza os riscos gerais do projeto, mas foca principalmente nos riscos das próximas iterações, atuando assim em um escopo bem reduzido. A própria equipe atua com os riscos e pode obter apoio externo. EQUIPE Possui profissionais com papéis bem definidos, quantificada e mobilizada conforme o planejamento do projeto. A equipe executa o projeto guiado pelo Gerente de Projetos conforme o plano estabelecido. Equipe multidisciplinar, multifuncional e auto-organizada. Ela decide como fazer e atua de forma colaborativa. TEMPO DE ENTREGA É realizado conforme o plano estabelecido e pode durar semanas, meses ou até mesmo anos. Fixo e é conforme a definição de duração das iterações que comumente varia entre 1 e 4 semanas. ACEITAÇÃO DE MUDANÇAS Gerenciamento formal de mudanças, pois exige alteração do planejamento já realizado e geralmente precisa passar por Mudanças são bem-vindas. Evita- se mudar o escopo da iteração em andamento, mas o escopo das futuras iterações podem ser 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 19 de 83 aprovações formais de um ou mais níveis hierárquicos. replanejado conforme a necessidade do cliente. PREVISIBILIDADE Depende do intervalo de monitoramento e controle do projeto. Quanto mais curto, maior a chance de prever as ocorrências futuras. Quanto maior o intervalo, menor a chance de prever as ocorrências futuras. Tende a ter uma grande previsibilidade futura devido à constante análise e feedback através das oportunidades de inspeção e adaptação providas pelo método. RESULTADOS AO LONGO DO TEMPO Tende a demorar a dar resultados a curto prazo, pois as entregas são geralmente realizadas ao final do projeto. Melhores resultados são apresentados em projetos de maior duração. Gera resultados a curto, médio e longo prazo, pois atua com entregas antecipadas e de valor agregado e contínuo ao cliente. APRESENTAÇÃO DE INFORMAÇÕES DO PROJETO Geralmente de uma apresentação formal previamente agendada com os stakeholders em intervalos de tempo. As informações podem ser detalhadas ou não conforme a necessidade do público envolvido. Geralmente informal e utiliza radiadores de informação no ambiente de trabalho durante todo o projeto, de modo que as informações do projeto fiquem visíveis e transparentes a toda equipe e envolvidos. PRAZO DE ENTREGA Conforme estabelecido no planejamento do projeto. No caso de mudanças aprovadas, varia conforme os impactos das solicitações e podem ser traumáticas aos envolvidos quanto às suas expectativas. Conforme o tamanho da iteração e o planejamento das releases para as entregas significativas. DOCUMENTAÇÃO Detalhada desde o início do projeto. Abrangente no início e detalhada somente o necessário durante o 0 00000000000 - DEMO 0 Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 20 de 83 projeto conforme os objetivos das iterações e releases. ATUAÇÃO DO CLIENTE Nas fases iniciais e nas principais validações do produto. Durante todo o projeto, o cliente faz parte da equipe. DISCUSSÃO E MELHORIAS Geralmente em prazos longos através da realização de reuniões após uma grande etapa ou grande entrega do projeto. Em prazos curtos, sempre ao final das iterações. COMANDANTE Gerente de Projetos. Equipe do Projeto. PAPÉIS Claros e definidos. Conforme a confiança na equipe e ambiente colaborativo. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 21 de 83 PROCESSO Guiado conforme o planejamento do projeto e nos processos estabelecidos no plano. Empírico e guiado ao produto e às pessoas. Orientado à geração de valor e conforme priorização dos riscos. RESULTADO Melhor resultado em projetos com escopo muito bem definido e orientado a planejamento. Melhor resultado em projetos cujo escopo é dinâmico e construído durante a execução do projeto. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 22 de 83 (CESPE – 2012 – TCE/E – Auditor de Controle Externo – Tecnologia da Informação) Em virtude de as metodologias ágeis gerarem excessiva documentação, a gestão do conhecimento depende diretamente dos programadores envolvidos no projeto. Comentários: Por que valorizar mais software em funcionamento do que documentação abrangente? Vou repetir, porque esse assunto cai em prova! No ágil, documentação é descartável? Não! Ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a transferência de conhecimento, preservar informações históricas, satisfazer necessidades contratuais ou legais, etc. A documentação é importante, sim; mas valoriza-se mais o software em funcionamento. Conforme vimos em aula, o Manifesto Ágil valoriza: Software em Funcionamento mais do que Documentação Abrangente, portanto não é correto dizer que metodologias ágeis geram excessiva documentação. Gabarito: E (CESPE – 2011 – EBC – Analista de Sistemas) O que os métodos ágeis buscam é como evitar as mudanças desde o início do projeto e não a melhor maneira de tratar essas mudanças. Comentários: NÓS SEGUIMOS ESSES PRINCÍPIOS... 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 23 de 83 Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são preditivas – já vimos que esse cenário é ilusório. Conforme vimos em aula, Metodologias Ágeis são extremamente afeitas a mudanças de requisitos, adaptando-se a novos contextos e respondendo a cada modificação. Gabarito: E (CESPE – 2010 – BASA – Técnico Científico – Arquitetura de Tecnologia) Desenvolvimento ágil de software (Agile Software Development) ou método ágil é aplicado, principalmente, a grandes corporações, uma vez que permite produzir grandes sistemas de forma ágil. Comentários: Professor, metodologias ágeis são recomendadas para projetos de qualquer tamanho e complexidade? Segundo Sommerville: “Todos os métodostêm limites, e os métodos ágeis são somente adequados para alguns tipos de desenvolvimento de sistema. Na minha opinião, eles são mais adequados para o desenvolvimento de sistemas de pequenas e médias empresas e produtos para computadores pessoais”. A questão afirma que ela é aplicada principalmente a grandes corporações. De fato, isso está errado! Ela ainda é aplicada principalmente a aplicações pequenas e médias, mas permite – sim – produzir grandes sistemas de forma ágil. Gabarito: E (CESPE – 2010 – TCU – Auditor Federal de Controle Externo – Tecnologia da Informação) A agilidade não pode ser aplicada a todo e qualquer processo de software. Comentários: Pressman afirma que a agilidade pode ser aplicada a qualquer processo de software. Entretanto, para obtê-la, é essencial que seja projetado para que a equipe possa adaptar e alinhar (racionalizar) tarefas; possa conduzir o planejamento 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 24 de 83 compreendendo a fluidez de uma abordagem do desenvolvimento ágil; possa eliminar tudo, exceto os artefatos essenciais, conservando-os enxutos. Conforme vimos em aula, a agilidade pode – sim – ser aplicada a qualquer processo de software. Gabarito: E (CESPE – – UNIPAMPA – Analista de Sistemas) XP, Scrum e Cristal são exemplos de modelos ágeis de desenvolvimento de sistemas. Comentários: Conforme vimos em aula, está perfeito! Gabarito: C (CESPE - 2011 - EBC - Analista - Engenharia de Software) Considerando o conceito de metodologia ágil em apreço, é correto afirmar que as seguintes metodologias são ágeis: XP (Extreme Programming), Scrum, Crystal, FDD (Feature Driven Development), DSDM (Dynamic Systems Development Method) e Open Source Software Development. Comentários: 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 25 de 83 Conforme vimos em aula, está perfeito! Gabarito: C (CESPE - 2013 - CNJ - Técnico Judiciário - Programação de Sistemas) O desenvolvimento ágil de sistemas consiste em uma linguagem de modelagem que permite aos desenvolvedores visualizarem os produtos de seu trabalho em gráficos padronizados. Comentários: Não, desenvolvimento ágil de sistemas não é uma linguagem de modelagem. Quem pode me dizer um exemplo de linguagem de modelagem? UML! Gabarito: E (CESPE - 2011 - EBC - Analista - Engenharia de Software) É conveniente que o contrato, entre cliente e fornecedor, para o desenvolvimento de um sistema computacional, contenha a lista de requisitos para o software. Contudo, os métodos ágeis de desenvolvimento preconizam que o referido contrato estabeleça o preço, a ser pago pelo cliente, com base no tempo necessário para o desenvolvimento do sistema e não com base no conjunto de requisitos. Comentários: Segundo Martin Fowler, pode-se fixar um orçamento para o software antes de desenvolvê-lo. A abordagem ágil comum é fixar tempo e preço, deixando o escopo 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 26 de 83 variar (os requisitos são variáveis) de forma controlada. É o famoso: “Tempo fixo, escopo variável”. Gabarito: C (CESPE - 2015 – MPOG/ATI - Analista de Sistemas) Metodologias de desenvolvimento ágil enfocam atividades de projeto e implementação, desconsiderando as atividades de elicitação de requisitos e a produção de documentação. Comentários: Por que valorizar mais software em funcionamento do que documentação abrangente? Porque clientes se interessam por resultados que entreguem valor ao negócio e, não, por documentos abrangentes. O software em funcionamento é o único indicador do que, de fato, a equipe construiu. Claro, não se exclui a necessidade de documentação, que é bastante útil para o desenvolvimento, mas deve-se produzir somente a documentação necessária e suficiente para a realização do trabalho. Vou repetir, porque esse assunto cai em prova! No ágil, documentação é descartável? Não! Ela é útil para ajudar a comunicação e colaboração na equipe, melhorar a transferência de conhecimento, preservar informações históricas, satisfazer necessidades contratuais ou legais, etc. A documentação é importante, sim; mas valori -se mais o software em funcionamento. Conforme vimos em aula, é absurdo pensar que se desconsidera atividades de elicitação de requisitos – não há o que se discutir nesse ponto. Além disso, o Manifesto Ágil afirma que, mesmo havendo valor na documentação extensa de software, valoriza-se mais o software em funcionamento. Em outras palavras, é errado afirmar que se desconsidera a produção de documentação, tendo em vista que há uma codificação não formal. Gabarito: E 10. (CESPE - 2016 – TRE/PI - Analista de Sistemas) No que se refere a métodos ágeis de desenvolvimento de sistemas, assinale a opção correta. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 27 de 83 a) A aplicação de método ágil para desenvolvimento de grandes sistemas pode enfrentar dificuldades que o tornem inviável. b) O documento de requisitos, apesar de abordar um conjunto pequeno de funcionalidades, deve especificar toda a necessidade do usuário. c) O sistema é construído em pequenos blocos, que irão compor uma versão a ser entregue aos usuários. d) A documentação de projeto deve ser feita pelo próprio desenvolvedor, seguindo padrões simplificados. e) Para atingir os objetivos de agilidade exigidos, os desenvolvedores devem seguir processos simplificados para a construção do software. Comentários: a) Correto. Aqui temos a teoria e a prática: no início, tanto a teoria quanto a prática não recomendavam que as metodologias ágeis fossem aplicadas a sistemas grandes. No entanto, atualmente, isso já não é mais uma limitação. Hoje em dia, as metodologias ágeis adquiriram maturidade suficiente para desenvolver sistemas grandes e complexos. Porém, isso ainda está na teoria, por isso as questões ainda cobram. b) Errado. Em metodologias ágeis, há uma documentação abrangente no início e detalhada somente o necessário durante o projeto conforme os objetivos das iterações e releases. No entanto, não existe um "Documento de Requisitos" - isso é coisa de metodologias tradicionais. Além disso, nenhum documento nunca conseguirá especificar todas as necessidades dos usuários. c) Correto. Não vislumbro qualquer erro nesse item. Ora, metodologias ágeis são iterativas e incrementais, dividindo o sistema em pequenas partes e sempre entregando versões que agreguem valor aos usuários. Se você errou esse item, fique tranquilo - o vacilo foi da banca! d) Errado. Documentação de Projeto? Isso é coisa de metodologias tradicionais. E, pensa comigo, o Product Backlog (do Scrum) é feito pelo desenvolvedor? Não, as histórias de usuário são escritas pelo Product Owner (Cliente). 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 28 de 83 e) Errado. Não existe esse negócio de "objetivos de agilidade exigidos". Isso soa como se existissem métricas de agilidadeque tivessem que ser atingidas. Gabarito: A 11. (CESPE - 2016 – TCE/PR - Analista de Sistemas) Os métodos ágeis para o desenvolvimento de software representam uma evolução da engenharia de software tradicional, uma vez que são aplicáveis a todos os tipos de projetos, produtos, pessoas e situações. Comentários: É um erro comum achar que metodologias ágeis servem para todas as ocasiões. Gabarito: E 12. (CESPE - 2016 – TCE/PR - Analista de Sistemas) Para que um projeto fundamentado em métodos ágeis de desenvolvimento tenha sucesso, a situação ou o problema a ser resolvido deve-se manter inalterado enquanto durar o projeto. Comentários: Estamos no século 21! Uma empresa líder de mercado pode acabar de uma hora para outra – a única certeza é a instabilidade! Logo, a equipe deve estar preparada para mudanças no escopo, tempo, custo, tecnologia, arquitetura, entre outros. Iterações curtas de desenvolvimento permitem que mudanças possam ser rapidamente inseridas no projeto, de forma que atendam às novas necessidades. Pelo contrário, métodos ágeis aceitam bem mudanças. Gabarito: E 13. (CESPE - 2016 – TCE/PR - Analista de Sistemas – Um dos princípios de agilidade da Agile Alliance dispõe que a entrega completa de um software garante a satisfação do cliente. Comentários: 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 29 de 83 NÓS SEGUIMOS ESSES PRINCÍPIOS... Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado. As Metodologias Tradicionais preconizavam planos detalhados do projeto; o Ágil busca se adaptar às necessidades dos clientes e entregar valor continuamente. Percebam que não existe entrega completa, mas contínua – logo, errado! Gabarito: E ACERTEI ERREI 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 30 de 83 TEST-DRIVEN DEVELOPMENT (TDD) O Test-Driven Development (TDD2) é um método ágil de desenvolvimento de software que se baseia na repetição de um ciclo de desenvolvimento curto, focado em testes unitários, em que os casos de teste que verificam uma nova funcionalidade são escritos antes mesmo da própria funcionalidade. Escreve-se o teste, encontre uma falha e refatore-o, ciclicamente – conhecido como Red, Green e Refactor. Vamos lá! Para cada parte da aplicação, adiciona-se um teste escrito antes mesmo do desenvolvimento do código em si. Por que? Porque eles podem ajudar a reduzir riscos de possíveis problemas no código. Executamos o teste e ele... falha! Ele deve necessariamente falhar! Por que? Ora, porque ele é o primeiro teste e você nem criou a funcionalidade ainda, logo ele não irá funcionar! Então nós adicionamos uma nova funcionalidade ao sistema apenas para que ele passe no teste e execute novamente (agora ele deve passar no teste). Então adicionamos um novo teste e rodamos o teste anterior e esse novo teste. Se algum deles falhar, modifica-se o código da funcionalidade e rodam-se todos os testes novamente, e assim por diante – a imagem abaixo mostra como funciona. Galera, vocês percebem que o feedback sobre a nova funcionalidade é bem rápido? Ademais, cria-se um código mais limpo, visto que o código para passar nos testes deve ser bastante simples. Há mais segurança na correção de eventuais bugs; 2 Eventualmente chamado de Test-Driven Programming (TDP). 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 31 de 83 aumenta-se a produtividade, visto que se perde menos tempo com depuradores; e o código se torna mais flexível, menos acoplado e mais coeso. Em geral, utilizam-se Testes Unitários, Testes de Integração ou Testes de Aceitação – sendo os primeiros os mais comuns. Algumas ferramentas que podem ser utilizadas para implementar o processo de desenvolvimento orientado a testes: JUnit, TesteNG, PHPUnit, SimpleTest, NUnit, Jasmine, CUnit, PyUnit, etc. Enfim, pessoal, essa abordagem permite diminuir eventuais riscos. IMPORTANTE O Test Driven Development (TDD) não é uma abordagem para realizar testes, é uma abordagem para desenvolver softwares. Entenderam? Se alguma questão disser que trata- se de uma técnica para realização de testes de software, está errado! É um processo para desenvolvimento de software! Ok? 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 32 de 83 Professor, isso já caiu em prova discursiva? Sim, a prova pedia para dizer as vantagens do emprego do TDD em relação a outras metodologias ágeis. Poderíamos responder essa pergunta afirmando que o software desenvolvido, em geral, apresenta maior qualidade, na medida em que é implementado direcionado às expectativas do cliente; Há a possibilidade de se testar todo o código desenvolvido, o que oferece maior confiabilidade ao sistema; por fim, em geral, o código é mais modularizado, flexível e extensível, visto que a metodologia requer que os desenvolvedores imaginem o software como pequenas unidades que podem ser reescritas, desenvolvidas e testadas de forma independente e integradas em momento posterior. A prova também perguntava como os princípios da Metodologia XP apoiados pelo TDD. Poderíamos afirmar que O Extreme Programming (XP) apresenta diversas práticas que podem ser relacionadas com o TDD; a mais óbvia é o “Teste Primeiro”, ratificando a característica básica recomendada veementemente pelo desenvolvimento orientado a testes. O TDD pode apoiar esse princípio por fornecer detalhes para a realização dos testes de unidade e de funcionalidade, que são importantes e necessários. Ademais, o desenvolvimento orientado a testes apresenta relação intrínseca com a Refatoração, tendo em vista que confere ao programador maior segurança para identificar e remover o código duplicado, e permite, assim, a melhoria contínua do programa. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 33 de 83 (CESPE – – INMETRO – Analista Executivo em Metrologia e Qualidade – Desenvolvimento de Sistemas) A rotina diária dos desenvolvedores, ao empregar processos baseados no TDD (Test-Driven Development), é concentrada na elaboração de testes de homologação. Comentários: A rotina dos desenvolvedores é concentrada, na verdade, na elaboração de testes unitários e, não, de homologação. Lembrem-se: constrói o teste, constrói a funcionalidade e refatora a funcionalidade. Gabarito: E (CESPE – 2013 – INPI – Analista de Planejamento – Desenvolvimento e Manutenção de Sistemas) Usando-se o TDD, as funcionalidades devem estar completas e da forma como serão apresentadas aos seus usuários para que possam ser testadas e consideradas corretas. Comentários: Pelo contrário, primeiro são feitos os testes e depois desenvolvem-se as funcionalidades. Gabarito: E (CESPE – 2013 – ANCINE – Analista de Sistemas) No desenvolvimentode software conforme as diretivas do TDD (Test-Driven Development), deve-se elaborar primeiramente os testes e, em seguida, escrever o código necessário para passar pelos testes. Comentários: Perfeito! Primeiro, criam-se os testes, depois cria-se o software ou componente. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 34 de 83 Gabarito: C (CESPE – – INMETRO – Analista de Sistemas) Considerando uma organização na qual a abordagem de Test Driven Development (TDD) esteja implementada, assinale a opção correta. a) Nessa organização, ocorre a execução de iterações com ciclo longo, isto é, com duração de alguns meses. b) No início de cada iteração, a primeira atividade realizada pela equipe de desenvolvimento é produzir o código que será validado através de testes. c) O refactoring é uma das primeiras atividades realizada no início de cada iteração. d) Entre as atividades finais de cada iteração, o desenvolvedor escreve casos de teste automatizados, cuja execução verifica se houve a melhoria desejada ou se uma nova funcionalidade foi implementada. e) Há coerência e inter-relação com os princípios promovidos pela prática da extreme programming (XP). Comentários: (a) Não, são ciclos curtos; (b) Não, são produzidos primeiramente os testes e, depois, os códigos; (c) Não, a refatoração é uma das últimas atividades realizadas em uma iteração; (d) Escrever casos de testes é uma das atividades iniciais; (e) Perfeito, TDD é uma das práticas recomendadas pelo XP. Gabarito: E (CESPE – 2013 – MPOG – Analista de Sistemas) Ao realizar o TDD (test-driven development), o programador é conduzido a pensar em decisões de design antes de pensar em código de implementação, o que cria um maior acoplamento, uma vez que seu objetivo é pensar na lógica e nas responsabilidades de cada classe. Comentários: 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 35 de 83 Em Engenharia de Software, há dois conceitos importantíssimos: coesão e acoplamento. Quando eu estudava, eu decorava uma frase pequena para entender: "Coesão é a divisão de responsabilidades e Acoplamento é a dependência entre componentes". Há outra que dizia assim: "Uma boa arquitetura de software deve ter componentes de projeto com baixo acoplamento e alta coesão". O Acoplamento trata do nível de dependência entre módulos ou componentes de um software. Por que é bom ter baixo acoplamento? Porque se os módulos pouco dependem um do outro, modificações de um não afetam os outros, além de não prejudicar o reúso. Se esse princípio não for observado durante a construção da arquitetura de um sistema de software, pode haver problemas sérios de manutenção futura! Voltando à questão! Se o programador pensa em decisões de design antes de pensar em código de implementação, isso diminui o acoplamento - os componentes ficam menos dependentes tornando a arquitetura bem mais flexível. Gabarito: E (CESPE – 2013 – MPU – Analista de Sistemas) Na metodologia TDD, ou desenvolvimento orientado a testes, cada nova funcionalidade inicia com a criação de um teste, cujo planejamento permite a identificação dos itens e funcionalidades que deverão ser testados, quem são os responsáveis e quais os riscos envolvidos. Comentários: Perfeito, essa metodologia permite um aprendizado maior sobre o problema a ser resolvido, permitindo (não é obrigatório) a identificação de itens, funcionalidades, responsáveis e riscos. barito: C (CESPE – 2013 – STF – Analista de Sistemas) No TDD, o primeiro passo do desenvolvedor é criar o teste, denominado teste falho, que retornará um erro, para, posteriormente, desenvolver o código e aprimorar a codificação do sistema. Comentários: 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 36 de 83 Perfeito, é exatamente isso! Gabarito: C (CESPE – 2013 – TRT/17 – Analista de Sistemas) TDD consiste em uma técnica de desenvolvimento de software com abordagem embasada em perspectiva evolutiva de seu desenvolvimento. Essa abordagem envolve a produção de versões iniciais de um sistema a partir das quais é possível realizar verificações de suas qualidades antes que ele seja construído. Comentários: Galera! O CESPE afirma que esta questão está errada e, para uma questão estar errada, é preciso que haja algum erro nela. Óbvio, não?! Pois é, o problema é que eu não acho que haja nenhum erro no item. TDD é uma técnica? Sim! De desenvolvimento de software? Sim! Com abordagem embasada em perspectiva evolutiva? Sim, criam-se testes que vão encontrando erros e melhorando um código. Essa abordagem envolve a produção de versões iniciais de um sistema? Sim. A partir das quais é possível realizar verificações de suas qualidades antes que ele seja construído? Sim, a partir dos testes e do entendimento do software, é possível verificar a qualidade do sistema a ser construído. Enfim, discordo do gabarito! Gabarito: E (CESPE – 2013 – AL/RN – Analista de Sistemas) Um típico ciclo de vida de um projeto em TDD consiste em: I. Executar os testes novamente e garantir que estes continuem tendo sucesso. II. Executar os testes para ver se todos estes testes obtiveram êxito. III. Escrever a aplicação a ser testada. IV. Refatorar (refactoring). V. Executar todos os possíveis testes e ver a aplicação falhar. VI. Criar o teste. A ordem correta e cronológica que deve ser seguida para o ciclo de vida do TDD está expressa em: a) IV − III − II − V − I − VI. b) V − VI − II − I − III − IV. c) VI − V − III − II − IV − I. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 37 de 83 d) III − IV − V − VI − I − II. e) III − IV − VI − V − I − II. Comentários: Pessoal, acredito que essa questão não possui resposta! Percebam que a opção que melhor se encaixa é a Letra C (VI − V − III − II − IV – I), no entanto o item V afirma: Executar todos os possíveis testes e ver a aplicação falhar. Acredito que o correto seria dizer: Executar os possíveis testes e ver se algum deles falha. Gabarito: C 10. (FGV – 2013 – AL/MT – Analista de Sistemas) Com relação ao desenvolvimento orientado (dirigido) a testes (do Inglês Test Driven Development – TDD), analise as afirmativas a seguir. I. TDD é uma técnica de desenvolvimento de software iterativa e incremental. II. TDD implica escrever o código de teste antes do código de produção, um teste de cada vez, tendo certeza de que o teste falha antes de escrever o código que irá fazê-lo passar. III. TDD é uma técnica específica do processo XP (Extreme Programming), portanto, só pode ser utilizada em modelos de processos ágeis de desenvolvimento de software. Assinale: a) Se somente as afirmativas I e II estiverem corretas. b) Se somente as afirmativas I e III estiverem corretas. c) Se somente as afirmativas II e III estiverem corretas. d) Se somente a afirmativa III estiver correta. e) Se somente a afirmativa I estiver correta. Comentários: (I) Perfeito, é iterativo e incremental (lembrando que, em sua imensa maioria, metodologias ágeis são iterativas/incrementais); (II) Perfeito, escrevem-se os testes antes, fá-lo falhar e só depois escreve-se o código da aplicação;(III) Não, ele é uma metodologia independente. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 38 de 83 Gabarito: A 11. (FCC – 2015 – TRT/MG – Analista de Sistemas) Um analista de TI está participando do desenvolvimento de um software orientado a objetos utilizando a plataforma Java. Na abordagem de desenvolvimento adotada, o código é desenvolvido de forma incremental, em conjunto com o teste para esse incremento, de forma que só se passa para o próximo incremento quando o atual passar no teste. Como o código é desenvolvido em incrementos muito pequenos e são executados testes a cada vez que uma funcionalidade é adicionada ou que o programa é refatorado, foi necessário definir um ambiente de testes automatizados utilizando um framework popular que suporta o teste de programas Java. A abordagem de desenvolvimento adotada e o framework de suporte à criação de testes automatizados são, respectivamente, a) Behavior-Driven Development e JTest. b) Extreme Programming e Selenium. c) Test-Driven Development e Jenkins. d) Data-Driven Development and Test e JUnit. e) Test-Driven Development e JUnit. Comentários: A questão trata do TDD e JUnit. Gabarito: E ACERTEI ERREI 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 39 de 83 FEATURE DRIVEN DEVELOPMENT (FDD) Vamos falar agora sobre o Feature Driven Development (ou Desenvolvimento orientado a Funcionalidades/Características). Essa é uma das seis implementações de metodologias ágeis originais preconizadas pelo Manifesto Ágil – a ela se juntam eXtreme Programming (XP), Adaptative Software Development (ASD), Dynamic Systems Development Method (DSDM), Scrum e Crystal Clear. O FDD foi criado em 1997 por Peter Coad e Jeff de Lucca como um grande projeto de um United Overseas Bank – um banco local de Singapura. Ela oferece um conjunto coeso de princípios e práticas tanto para a Gestão de Projetos quanto para a Engenharia de Software, e se harmoniza bem com abordagens mais especialistas, como Scrum. Ela se fundamenta em técnicas de gerenciamento de projetos e de modelagem orientada a objetos, equilibrando vantagens das metodologias rígidas (contemplando – por exemplo – planejamento e modelagem) e das metodologias ágeis (ciclos curtos, orientação ao cliente, ênfase em programação, etc). Eu diria que ele é um meio-termo entre XP e RUP. Professor, mas o que seria um Feature? Trata-se de uma funcionalidade ou característica valorizada pelo cliente, que pode ser implementada em duas semanas ou menos. Alguns dizem ser similar a um requisito funcional que gera valor ao cliente. À medida que há participação ativa do cliente no projeto, os resultados têm bastante e rápida visibilidade. O método oferece algumas características importantes: Fornece uma estrutura adequada para equipes maiores; Enfatiza a produção de software de qualidade; Fornece informação de estado e progresso de forma simples; Agradam clientes, gerentes e desenvolvedores; Entrega resultados frequentes, tangíveis e funcionais; Planejamento detalhado e guiado para medição; Rastreabilidade e relatórios com precisão; Ele recomenda também a adoção de um conjunto de melhores práticas para que o método atinja seus objetivos principais, são eles: modelagem de objetos de domínio; 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 40 de 83 desenvolvimento por feature; posse individual do código; equipes de features; inspeções; builds regulares; gerenciamento de configuração; relatório e visibilidade de resultados. Possui duas grandes fases: Concepção & Planejamento (ou Modelagem) – com três processos; e Construção (ou Implementação) – com dois processos. Concepção & Planejamento: é uma parte crítica do processo, pois é nessa fase que são listadas as características (Features) que serão desenvolvidas, e em um primeiro momento é nessa fase que são definidas todas as características e fases do sistema e projetos, respectivamente. Seus processos são: Desenvolver um Modelo Abrangente: abrangendo todo o projeto, realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são realizados estudos mais detalhados para cada área a ser modelada. Assim, pequenos grupos são formados por membros do domínio do negócio e por desenvolvedores, que comporão seus próprios modelos. Os pequenos grupos apresentam seus modelos para serem revisados por parceiros e para discussão. Um dos modelos propostos é selecionado por consenso, tornando-se, assim, o modelo para aquela área do domínio do negócio. Realiza-se, então, uma combinação do modelo da área do domínio dentro de um modelo abrangente. Construir uma Lista de Funcionalidades: abrangendo todo o projeto, identificam-se todas as funcionalidades que satisfaçam os requisitos. Uma equipe é formada para decompor funcionalmente o domínio em áreas de negócio, atividades de negócio dentro delas e passos dentro de cada atividade de negócio, formando uma lista categorizada de funcionalidades. Planejar por Funcionalidade: abrangendo todo o projeto, busca-se produzir o plano de desenvolvimento. O gerente de projeto, o gerente de desenvolvimento e os programadores-líderes planejam a ordem de implementação, baseado nas dependências entre elas, na carga de trabalho da equipe e na complexidade das funcionalidades a serem implementadas. As principais atividades neste processo não são uma sequência estrita. Como muitas atividades de planejamento, elas são consideradas em conjunto, com refinamentos feitos a partir de uma ou mais atividades e então considerando 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 41 de 83 os outros novamente. Após isso, a posse das classes estará completada (além das classes principais que já foram consideradas para posse). Construção: a implementação inicia agrupando features relacionadas e agrupando dentro de uma pacote de trabalho, que deve ser completada dentro de uma iteração. Um pacote de trabalho completo representa uma parte do sistema que já pode ser utilizada pelo cliente. Detalhar por Funcionalidade: abrangendo cada funcionalidade, busca-se produzir o pacote de projeto para ela. Certo número de funcionalidades são agendadas para desenvolvimento ao atribuí-las a um programador-líder. Ele seleciona as funcionalidades para desenvolvimento a partir de sua caixa de entrada de funcionalidades atribuídas. Ele pode escolher diversas funcionalidades que utilizem as mesmas classes (e portanto, desenvolvedores). Operacionalmente, com frequência acontece o caso de conjuntos de funcionalidades serem agendados para desenvolvimento de uma vez pelo programador-líder. Tal conjunto é chamado de Pacote de Trabalho do Programador-Líder (PTPL). O programador-líder forma uma equipe de funcionalidades, identificando os proprietários das classes que provavelmente serão envolvidos no desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz diagrama de sequência para as funcionalidades atribuídas. O programador- líder, então, refina o modelo de objetos e realiza-se uma inspeção no projeto. Construir por Funcionalidade: abrangendo cada funcionalidade,busca-se produzir uma função com valor para o cliente. Começando com o pacote de projeto, os proprietários de classes implementam os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código passa por testes e inspeções. Após isso, é promovido à versão atual (build). 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 42 de 83 O FDD pode facilitar imensuravelmente o fardo de reportar o status do projeto. Ele permite que o rastreio do progresso do desenvolvimento possa ser feito através de marcos definidos por funcionalidade, o que facilita a visualização do projeto como um todo. Os marcos começam a ser monitorados pelo gerente do projeto a partir da fase de construção. São eles: Walkthroughs do projeto; Projeto; Inspeção do projeto; Código; Inspeção de código; Progressão para construção. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 43 de 83 (FCC - 2010 – TRF/4 - Analista de Sistemas) A Feature Driven Development (FDD) é uma metodologia ágil de desenvolvimento de software, sobre a qual é correto afirmar: a) Não pode ser combinada a outras técnicas para a produção de sistemas. b) Possui cinco processos: Desenvolver um Modelo Abrangente, Construir a Lista de Funcionalidades, Planejar por Funcionalidade, Detalhar por Funcionalidade e Implementar por Funcionalidade. c) Divide os papéis em dois grupos: papéis chave e papéis de apoio. Dentro de cada categoria, os papéis são atribuídos a um único participante que assume a responsabilidade pelo papel. d) Mantém seu foco apenas na fase de modelagem. e) Mantém seu foco apenas na fase de implementação. Comentários: (a) Como não? O próprio modelo é a combinação de ferramentas de diferentes metodologias – elas interagem bem com outros modelos; (b) Perfeito, esses são de fato os cinco processos; (c) Na verdade, há diversos cargos e responsabilidades entre as categorias principais (ou chave), de apoio e adicionais; (d) Não, o foco é tanto na Modelagem quanto na Implementação; (e) Não, o foco é tanto na Modelagem quanto na Implementação. Gabarito: B (FCC - 2014 – TRF/3 - Analista de Sistemas) Os modelos ágeis de desenvolvimento de software têm menos ênfase nas definições de atividades e mais ênfase na pragmática e nos fatores humanos do desenvolvimento. Um destes modelos enfatiza o uso de orientação a objetos e possui apenas duas grandes fases: 1 − 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 44 de 83 Concepção e Planejamento e 2 − Construção. A fase de Concepção e Planejamento possui três disciplinas (chamadas de processos): Desenvolver Modelo Abrangente, Construir Lista de Funcionalidades e Planejar por funcionalidade. Já a fase de Construção incorpora duas disciplinas (processos): Detalhar por Funcionalidade e Construir por Funcionalidade. O texto acima apresenta a metodologia ágil conhecida como: a) XP. b) SCRUM. c) Crystal Clear. d) ASD. e) FDD. Comentários: Trata-se evidentemente do FDD. Gabarito: E (FCC - 2013 – TRT/9 - Analista de Sistemas) Os modelos de processos tradicionais surgiram em um cenário muito diferente do atual, baseado em mainframes e terminais remotos. Já os modelos de processos ágeis são adequados para situações atuais nas quais a mudança de requisitos é frequente. Dentre os modelos de processos ágeis mais comuns temos: Extreme Programming (XP), Scrum e Feature Driven Development (FDD). Algumas das práticas e características desses modelos de processo são descritas a seguir: I. Programação em pares, ou seja, a implementação do código é feita em dupla. II. Desenvolvimento dividido em ciclos iterativos de até 30 dias chamados de sprints. III. Faz uso do teste de unidades como sua tática de testes primária. IV. A atividade de levantamento de requisitos conduz à criação de um conjunto de histórias de usuários. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 45 de 83 V. O ciclo de vida é baseado em três fases: pre-game phase, game-phase, post- game phase. VI. Tem como único artefato de projeto os cartões CRC. VII. Realiza reuniões diárias de acompanhamento de aproximadamente 15 minutos. VIII. Define seis marcos durante o projeto e a implementação de uma funcionalidade: walkthroughs do projeto, projeto, inspeção do projeto, codificação, inspeção de código e progressão para construção. IX. Os requisitos são descritos em um documento chamado backlog e são ordenados por prioridade. A relação correta entre o modelo de processo ágil e a prática/característica é: SCRUM FDD II, V e VII II, IV e VIII VII e IX I, III, IV e VI II, V, VII e IX VIII II, VII e VIII III, IV, VI e IX I e V II, VII e VIII I, III, IV e V VI e IX I, III, IV e VI II, VIII, VII e IX V Comentários: (I) XP; (II) Scrum; (III) XP; (IV) XP; (V) Scrum; (VI) XP; (VII) Scrum; (VIII) FDD; (IX) Scrum. Vamos comentar apenas a que nos interessa: FDD define seis marcos durante o projeto e implementação de uma funcionalidade: walkthroughs (travessia) do projeto, projeto, inspeção do projeto, codificação, inspeção de código e progressão para construção. Gabarito: B (FCC - 2011 – TRT/23- Técnico Judiciário) FDD (Feature Driven Development) é uma metodologia muito objetiva, possuindo apenas duas fases: a) Concepção & Planejamento e Construção. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 46 de 83 b) Decomposição Funcional e Construção. c) Análise dos Requisitos e Desenvolvimento. d) Planejamento Incremental e Desenvolvimento por Funcionalidade. e) Planejamento por Funcionalidade e Construção por Funcionalidade. Comentários: Trata-se da Concepção & Planejamento e Construção. Gabarito: A (FCC - 2010 - TRE- - Técnico Judiciário - Programação de Sistemas) São algumas das metodologias de desenvolvimento de software consideradas ágeis (Agile Software Process Models): a) RUP, XP e DSDM. b) Waterfall, RUP e FDD. c) XP, FDD e RUP. d) Scrum, XP e FDD. e) Scrum, Waterfall e DSDM. Comentários: Fácil, não?! Scrum, XP e FDD. Gabarito: D ACERTEI ERREI 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 47 de 83 DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM) O Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) é uma abordagem de desenvolvimento de software ágil que oferece uma metodologia para construir e manter sistemas que atendem restrições de prazo apertado através do uso da prototipagem incremental em um ambiente controlado. A filosofia DSDM baseia-se em uma versão modificada do Princípio de Pareto. Como assim? 80% de uma aplicação pode ser entregue em 20% do tempo para entregar a aplicação completa (100%). O DSDM é um processo de software iterativo em que cadaiteração segue a regra dos 80%. Ou seja, somente o trabalho suficiente é requisitado para cada incremento, para facilitar o movimento para o próximo incremento. Funcionalidades atendem aos prazos fixos; e, não, o contrário. Os detalhes remanescentes podem ser completados depois, quando outros requisitos de negócio forem conhecidos ou alterações tiverem sido solicitadas e acomodadas. O Consórcio DSDM é um grupo mundial de empresas-membro que coletivamente assume o papel de mantenedor do método. Esse consórcio definiu um modelo de processos ágeis, chamado Ciclo de Vida DSDM. Esse ciclo de vida define três ciclos iterativos diferentes, precedidos por duas atividades de ciclo de vida adicionais: Estudo da Viabilidade Estabelece os requisitos básicos de negócio e restrições associados à aplicação a ser construída e depois avalia se a aplicação é ou não um candidato viável para o processo de Método de Desenvolvimento de Sistemas Dinâmicos (DSDM). Estudo do Negócio Estabelece os requisitos funcionais e de informação que permitirão à aplicação agregar valor de negócio; define também a arquitetura básica da aplicação e identifica os requisitos de facilidade de manutenção para a aplicação. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 48 de 83 Iteração de Modelos Funcionais Produz um conjunto de protótipos incrementais que demonstram funcionalidade para o cliente.3 Durante esse ciclo iterativo, o objetivo é juntar requisitos adicionais ao se obter feedback dos usuários, conforme testam o protótipo. Iteração de Projeto e Desenvolvimento Revisita protótipos desenvolvidos durante a iteração de modelos funcionais para assegurar-se de que cada um tenha passado por um processo de engenharia para capacitá-los a oferecer, aos usuários finais, valor de negócio em termos operacionais. Em alguns casos, a Iteração de Modelos Funcionais e a Iteração de Projeto e Desenvolvimento ocorrem ao mesmo tempo. Implementação Aloca a última versão do incremento de software (um protótipo “operacionalizado”) no ambiente operacional. Deve-se notar que: (1) o incremento pode estar 100% completo ou (2) alterações podem vir a ser solicitadas conforme o incremento seja alocado. Em qualquer dos casos, o trabalho de desenvolvimento do DSDM contínua, retornando-se à atividade de iteração do modelo funcional. O DSDM pode ser combinado com o XP para fornecer uma abordagem combinatória que define um modelo de processos consistente (o ciclo de vida do DSDM) com as práticas básicas (XP) necessárias para construir incrementos de software. Além disso, os conceitos de colaboração e de equipes auto-organizadas do ASD podem ser adaptados a um modelo de processos combinado. 3 Todos os protótipos DSDM são feitos com a intenção de que evoluam para a aplicação final entregue ao cliente. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 49 de 83 (CONSULPLAN - – TRE/MG – Analista de Sistemas) As metodologias ágeis de desenvolvimento surgiram em meados de 1990, como reação aos chamados métodos pesados de desenvolvimento, que eram caracterizados por muita formalidade nas documentações e regulamentações. Muitos eram gerenciados pelo tradicional modelo em cascata. Em 2001, de fato, após uma reunião no estado de Utah, surgiu, definitivamente, e foi propagado o paradigma de desenvolvimento de softwares ágeis. Muitos foram os motivos que levaram a essa concepção, por exemplo: gestão orientada a pessoas, adaptabilidade de processos, design e construção de software usando uma metodologia adaptativa, entre outros. Uma dessas metodologias ágeis é “centrada em estabelecer os recursos e o tempo fixo para o desenvolvimento de um projeto, ajustando suas funcionalidades de maneira a atender os prazos estipulados”. A respeito dessa metodologia, assinale a alternativa correta. a) SCRUM. b) Extreme Programming (XP). c) Adaptive Software Development (ASD). d) Dynamic Systems Development Methodology (DSDM). Comentários: Como assim? 80% de uma aplicação pode ser entregue em 20% do tempo para entregar a aplicação completa (100%). O DSDM é um processo de software iterativo em que cada iteração segue a regra dos 80%. Ou seja, somente o trabalho suficiente é requisitado para cada incremento, para facilitar o movimento para o próximo incremento. Funcionalidades atendem aos prazos fixos; e, não, o contrário. Conforme vimos em aula, trata-se do DSDM! Gabarito: D ACERTEI ERREI 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 50 de 83 DESENVOLVIMENTO ADAPTATIVO DE SOFTWARE (DAS) O Adaptative Software Development (ASD) é uma técnica para a construção de softwares e de sistemas complexos. Seus fundamentos filosóficos se concentram na colaboração humana e na auto-organização da equipe. Eu vou repetir essa parte porque, muitas vezes, isso é capaz de matar uma questão: seu foco é na colaboração humana e na auto-organização da equipe! Trata-se de uma abordagem de desenvolvimento ágil e adaptável baseada em colaboração é tanto uma fonte de ordem nas interações humanas complexas como uma disciplina e engenharia. Seu criador, Jim Highsmith, define o ciclo de vida dessa metodologia de desenvolvimento de softwares e sistemas incorporando três fases: Especulação, Colaboração e Aprendizado. 0 00000000000 - DEMO Analista Judiciário – Especialidade Informática/TRF.02 Curso de Engenharia de Software Prof. Diego Carvalho – Aula 00 Prof. Diego Carvalho www.estrategiaconcursos.com.br Pág. 51 de 83 Na fase de Especulação, ocorre o planejamento do ciclo adaptativo, a declaração da missão, as restrições de projeto (datas de entrega, descrições de usuários, etc), os requisitos básicos e o plano de lançamento em um período fixo de tempo (time- boxed). Na fase de Colaboração, ocorre a reunião dos requisitos, que são levantados por técnicas como JAD e mini-especificações. Pessoas motivadas usam a colaboração de uma forma que multiplica seu talento e criatividade além de seus números absolutos. Esta abordagem é um tema recorrente em todos os métodos ágeis, mas a colaboração não é fácil. Ela engloba comunicação e trabalho em equipe, mas também enfatiza o individualismo, porque a criatividade individual executa um papel importante no pensamento colaborativo. É, acima de tudo, uma questão de confiança. Pessoas trabalhando juntas precisam confiar um no outro para (1) criticar sem animosidade, (2) ajudar sem ressentimento, (3) trabalhar tão duro quanto ou mais do que já trabalham, (4) ter um conjunto de habilidades para contribuir para o trabalho na mão, e (5) comunicar problemas ou preocupações em um caminho que conduz à ação efetiva. Rapaziada, à medida que os membros de uma equipe começam a desenvolver os componentes que fazem parte de um ciclo adaptativo, a ênfase está tanto no aprendizado quanto no progresso em direção a um ciclo completo. As Equipes de Desenvolvimento Adaptativo de Software aprendem de três modos: Foco nos Grupos; Revisões Técnicas Formais; e Pós-Conclusão. Foco nos Grupos: o cliente/usuário fornecem feedback sobre os incrementos de software que são entregues, indicando se o produto está ou não satisfazendo às necessidades do negócio; Revisões Técnicas Formais: os membros
Materiais relacionados
159 pág.
49 pág.
Perguntas relacionadas
