1 / 26

Análise e Projeto de Sistemas I

Análise e Projeto de Sistemas I. Prof. MSc. Larissa Luz Gomes lariluz@yahoo.com.br Aula 5. Desenvolvimento Tradicional. O termo desenvolvimento tradicional , é utilizado para identificar as metodologias que de alguma forma adotam o Desenvolvimento em Cascata .

rollo
Download Presentation

Análise e Projeto de Sistemas I

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Análise e Projeto de Sistemas I Prof. MSc. Larissa Luz Gomes lariluz@yahoo.com.br Aula 5

  2. Desenvolvimento Tradicional • O termo desenvolvimento tradicional, é utilizado para identificar as metodologias que de alguma forma adotam o Desenvolvimento em Cascata. • No desenvolvimento em cascata, o software é construído seguindo uma seqüência de fases, sendo que cada fase, com exceção da primeira, depende da conclusão da fase anterior para ser iniciada.

  3. Desenvolvimento em Cascata

  4. Desenvolvimento em Cascata • O desenvolvimento em cascata, vem sendo amplamente nos processos de desenvolvimento de software. Por esse motivo, é chamado de Desenvolvimento Tradicional. • Alguns processos de desenvolvimento de software que não são em cascata, como o RUP (Rational Unified Process), são adotados em grande parte dos projetos, de uma forma semelhante ao modelo em cascata.

  5. Desenvolvimento RUP • No desenvolvimento RUP o processo é empregado de forma iterativa e incremental, mas ainda existe uma forte linearidade no desenvolvimento, caracterizada por cascatas menores dentro de cada iteração. • O termo desenvolvimento tradicional também engloba estes casos [TELES, 2004].

  6. Desenvolvimento RUP

  7. Desenvolvimento Ágil • Desenvolvimento Ágil de software (Agile software development) ou Método Ágil é um conjunto de metodologias de desenvolvimento de software. • O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.

  8. Desenvolvimento Ágil • Existem inúmeros métodos de desenvolvimento de software rápido. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de 1 semana a até 4 semanas. • Cada iteração é como um projeto de software em miniatura e inclui todas as tarefas necessárias para implantar os mini-incrementos de cada iteração, passando pelas seguintes etapas: Planejamento, Análise de Requisitos, Projeto, Codificação, Teste e Documentação.

  9. Desenvolvimento Ágil • Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projeto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração. • Desenvolvimento Ágil enfatiza a comunicação face-a-face, por isso produzem pouca documentação em relação a outros métodos, sendo este um de seus pontos negativos.

  10. Desenvolvimento Ágil • Eliminam grande parte do excesso de modelos e de documentação e o tempo gasto nestas tarefas; • Enfatizam um desenvolvimento de aplicação simples e iterativo, normalmente usado com a orientação a objeto; • Exemplos: Extreme Programming (1996), DSDM (Método de Desenvolvimento de Sistemas Dinâmicos) (1995) e o Scrum (1986).

  11. Tempo Clássico Iterativo XP Escopo Diferentes Métodos(Cascata, RUP, XP)

  12. Extreme Programming (XP) • Usa codificação simples e teste contínuo executado por dois desenvolvedores; • Interações estreitas com os usuários finais para construir o sistema rapidamente, conversas face-a-face; • Planejamento superficial executam as fases de análise, projeto e implementação iterativamente. A funcionalidade do sistema cresce ao longo do tempo.

  13. Extreme Programming (XP) • Planejamento superficial executam as fases de análise, projeto e implementação iterativamente. A funcionalidade do sistema cresce ao longo do tempo.

  14. Extreme Programming (XP) • As práticas de teste e codificação são o ponto-chave da XP; • XP conta pesadamente com refactoring (que é um modo disciplinado de reestruturar código para mantê-los simples); • A metodologia trabalha bem com projetos que têm agendas muito curtas ou prazos críticos.

  15. Extreme Programming (XP) • Um projeto XP começa com: • Histórias de usuários que descrevem o que o sistema deve fazer; • Depois os programadores codificam módulos e testes pequenos e simples para atender as necessidades do sistema em questão; • Usuários devem estar sempre disponíveis para esclarecer questões e tópicos à medida que surgirem; • Os padrões são importantes para minimizar a confusão por isso as equipes usam um conjunto de nomes, descrições e práticas de codificação comuns.

  16. Extreme Programming (XP) • Os projetos XP entregam resultados mais cedo que os outros e raramente têm problemas para reunir os requisitos do sistema • O XP trabalha muito com orientação a objeto e são indicados para agendas muito curtas ou prazos críticos. • Contudo, o XP requer muita disciplina, senão o projeto perde seu foco; • Recomendada para pequenos grupos de desenvolvimento, não mais que doze desenvolvedores trabalhando em dupla; • Não é recomendada para grandes aplicações.

  17. Extreme Programming (XP) • Sobre o processo proposto pelo XP • Ele se inicia com o cliente escolhendo as funcionalidades que serão implementadas. Estas funcionalidades são chamadas de estórias do usuário (user stories). A escolha leva em conta a estimativa de custo/tempo feita pelos programadores; • O desenvolvimento é fortemente guiado a testes (TDD: Test-Driven Development). Os programadores escrevem testes unitários, que são classes que automatizam seqüências de testes sobre outras classes. São escritos antes do código estar completo; • Normalmente no par de programadores procura-se unir um com muita experiência em TDD e outro com pouca ou nenhuma experiência nesta técnica.

  18. Extreme Programming (XP) • Sobre as estórias dos usuários • Uma estória do usuário é uma unidade funcional • Ela deve ser entendida pelos clientes e usuários, deve ser testável, deve ter valor para o cliente e deve ser pequena o bastante para que os programadores possam construir dúzias delas em um ciclo de iteração; • Ela é formada por uma ou duassentenças que descrevem algo com valor para o cliente: • o sistema deve verificar se o CPF do cliente é um número válido

  19. Extreme Programming (XP) • Sobre as estórias dos usuários • Os programadores deverão ser capazes de estimar o custo/tempo para implementar a estória. Caso isto não seja possível, a estória deve ser subdividida em estórias menores, para que possam ser então estimadas;

  20. Extreme Programming (XP) • Reportando o progresso de um projeto XP • O progresso de cada iteração é medido e reportado por uma pessoa chamada tracker; • A cada programador, o tracker faz duas perguntas básicas: • Quantos dias ideais você já trabalhou nesta tarefa? • Mais quantos dias ideais você precisa para completar a tarefa? • Se o tracker descobre que um programador não vai conseguir terminar sua tarefa, ele tenta redistribui o encargo para outro programador que esteja com alguma folga. Caso isto não seja possível, o cliente deve ser informado;

  21. Extreme Programming (XP) • Reportando o progresso de um projeto XP • As iterações no XP terminam na data estimada. As estórias implementadas, são apresentadas aos clientes, que decidirá se está adequada, a qual, neste caso, será considerada completa. As estórias incompletas serão consideradas para a próxima iteração.

  22. Abordagem Tradicional x XP • Tenta prever todos os problemas e criar defesas contra eles. • Análise de Requisitos; • Arquiteturas pensadas para aceitar aquilo que vai ser preciso no futuro; • Os erros só são um problema senão aparecer uma mensagem que explique; • O projeto nunca depende de um elemento particular da equipe, todos são substituíveis.

  23. Abordagem Tradicional x XP • A abordagem XP pretende ser mais flexível; • Não se baseia em prever e proteger-se contra todas as eventualidades; • Procura garantir que o sistema é facilmente alterável para se conformizar com a nova realidade.

  24. Exercício • Descreva as fases principais do ciclo de vida de desenvolvimento de sistemas (SDLC). • Compare e contraste as metodologias centradas em processo, as centradas em dados e as orientadas a objeto. • Descreva os principais elementos e questões do desenvolvimento em cascata. • Quais são os principais fatores na seleção de uma metodologia. • Em que se concentram as metodologias do desenvolvimento Ágil?

  25. Dúvidas e Perguntas

  26. Próxima Aula Gerência de Projeto

More Related