an lise e projeto de sistemas i
Download
Skip this Video
Download Presentation
Análise e Projeto de Sistemas I

Loading in 2 Seconds...

play fullscreen
1 / 26

An lise e Projeto de Sistemas I - PowerPoint PPT Presentation


  • 108 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'An lise e Projeto de Sistemas I' - rollo


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
an lise e projeto de sistemas i

Análise e Projeto de Sistemas I

Prof. MSc. Larissa Luz Gomes

[email protected]

Aula 5

desenvolvimento tradicional
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.
desenvolvimento em cascata1
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.
desenvolvimento rup
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].
desenvolvimento gil
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.
desenvolvimento gil1
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.
desenvolvimento gil2
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.
desenvolvimento gil3
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).
extreme programming xp
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.
extreme programming xp1
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.
extreme programming xp2
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.
extreme programming xp3
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.
extreme programming xp4
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.
extreme programming xp5
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.
extreme programming xp6
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
extreme programming xp7
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;
extreme programming xp8
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;
extreme programming xp9
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.
abordagem tradicional x xp
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.
abordagem tradicional x xp1
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.
exerc cio
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?
pr xima aula
Próxima Aula

Gerência de Projeto

ad