[02] APS Processo de Desenvolvimento de Software

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Análise e Projeto de Sistemas
Aula 2
Processo de Desenvolvimento de Software
Prof. Jorge Viana Doria Junior, M.Sc.
jjunior@unicarioca.edu.br 
Engenharia de Software
*
Engenharia de Software
O conteúdo desta aula foi parcialmente 
baseado nos slides disponíveis para o livro:
Engenharia de Software – Conceitos e Práticas
Raul Sidnei Wazlawick, Elsevier, 1a edição, 2013
*
Engenharia de Software
Conteúdo da Aula
Processo de Desenvolvimento de Software Clássicos
Cascata
Prototipação
Iterativo e Incremental
Espiral
RUP
Metodologias Ágeis
*
Engenharia de Software
O que é um Processo?
Processo é um conjunto de atividades que são executadas de forma sequencial para atingir algum objetivo
Atividades Interdependentes
Com responsáveis
Com entradas e saídas definidas
*
Engenharia de Software
Papéis e Atividades no Desenvolvimento de Software
Usuários
Problema
Entendimento do problema
Verificação &Validação
Projeto da Solução
Testes
Time de Desenvolvimento
Programadores
Testadores
Designers
Gerente de Projetos
Analistas de Sistemas
Arquitetos de Software
Implantação
Levantamento de Requisitos
Análise de Requisitos
Projeto
Implementação
Testes
Implantação
Desenvolvimento do Sistema
*
Copyright 2002, 2003 Eduardo Bezerra
*
Modelo de Ciclo de Vida em Cascata
Método sistemático e sequencial
O resultado de uma fase se constitui na entrada da outra
Também conhecido como Modelo Clássico
Engenharia de Software
*
Engenharia de Software
Problemas Modelo de Ciclo de Vida em Cascata
Rigidez do processo
Projetos reais raramente seguem um fluxo seqüencial
Assume que é possível declarar detalhadamente todos os requisitos antes do início das demais fases do desenvolvimento.
propagação de erros pelas as fases do processo.
Uma versão de produção do sistema não estará pronta até que o ciclo do projeto de desenvolvimento chegue ao final. 
*
Engenharia de Software
Cascata com Prototipação
Tem como objetivo assegurar que os requisitos do sistema foram bem entendidos. 
Técnica frequentemente aplicada quando:
há dificuldades no entendimento dos requisitos do sistema
há requisitos que precisam ser mais bem entendidos
O próprio usuário não tem compreensão completa do problema
*
Engenharia de Software
Prototipação
*
Engenharia de Software
Tipos de Protótipos
Evolutivo
Protótipo desenvolvido via programação para ser usado de base para o produto final. Terá a cara do produto final.
Descartável
Protótipo desenvolvido rapidamente via programação e com baixa qualidade de código. Só serve para validar os requisitos de usuários e depois deve ser jogado fora.
Baixa Fidelidade 
Protótipo desenvolvido em papel ou em ferramentas gráficas, mas sem se preocupar com a cara final do sistema
Engenharia de Software
Engenharia de Software
*
Engenharia de Software
Cascata com Prototipação
*
Engenharia de Software
Modelo em V (Cascata com fases de Testes)
Apesar de adicionar uma fase de teste para cada fase do cascata, ainda possui a característica de entregar software apenas no final de todo o processo
Engenharia de Software
Engenharia de Software
*
Engenharia de Software
Novo Modelo de Ciclo de Vida
Vamos assumir nossa incompetência em planejamento a longo prazo e vamos dividir o planejamento em pequenos pedaços chamados de iteração!
 Ciclo de Vida Incrementa e Iterativo
*
Engenharia de Software
Vários Mini-Cascatas
Cada cascata é uma iteração...
Iteração 1
Iteração 2
Iteração 3
*
Engenharia de Software
Modelo Iterativo e Incremental
Dividir para conquistar
O desenvolvimento ocorre em várias iterações, cada uma delas resultando em extensão de funcionamento e/ou maior conhecimento do sistema
As funcionalidades mais críticas devem ser tratadas nas primeiras iterações
*
Engenharia de Software
Modelo Iterativo e Incremental
Incremental
Iterativo
*
Engenharia de Software
Modelo Iterativo e Incremental
Vantagens
Antecipa possíveis problemas no desenvolvimento de software através de versões preliminares 
Entrega acelerado dos serviços ao cliente
Engajamento do usuário do sistema com o processo de desenvolvimento
Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto. 
*
Engenharia de Software
Modelo Iterativo e Incremental
Desvantagens
Passa a ter uma camada a mais de gerenciamento, que é o controle e a ordem de cada iteração
Problemas Contratuais pois o software desenvolvido pode caminhar para um produto muito diferente do que foi contratado
*
Engenharia de Software
Processo em Espiral – preocupação explícita com os riscos do projeto de desenvolvimento
*
Engenharia de Software
Processo em Espiral
O processo é representado por uma espiral ao invés de ser representado como uma sequencia de atividades
Cada volta da espiral (loop) representa uma única fase de desenvolvimento de software
Capacita o desenvolvedor e o cliente a entender e a reagir aos riscos em cada etapa evolutiva
Engloba as melhores características do ciclo de vida Clássico como o da Prototipação adicionando um novo elemento: a Análise de Riscos
*
Engenharia de Software
Questões que determinam a escolha de um processo
Quão bem os analistas e o cliente podem conhecer os requisitos do sistema?
Quão bem é compreendida a arquitetura do sistema?
Qual o grau de confiabilidade necessário em relação ao cronograma?
Quanto planejamento é efetivamente necessário?
Qual o grau de risco que este projeto apresenta?
Será necessário entregar partes do sistema funcionando antes de terminar o projeto todo?
Será desenvolvido um único sistema ou uma família de sistemas semelhantes?
Qual o tamanho do projeto?
*
Engenharia de Software
Questões de Concursos
Dentro da Engenharia de Software, encontramos uma gama de conceitos. Embasado nisso, analise as assertivas e assinale a alternativa que aponta a(s) correta(s) sobre Processos de Software. 
 I. Podemos definir um processo de software como um conjunto de atividades relacionadas que levam à produção de um produto de software. 
II. A definição das funcionalidades do software e as restrições a seu funcionamento devem ser definidas na produção de um software. Essa atividade está incluída no processo de software. 
*
Engenharia de Software
Questões de Concursos
III. A validação de software também é uma atividade presente no processo de software. 
IV. Os processos de software são complexos e, como todos os processos intelectuais e criativos, dependem de pessoas para tomar decisões e fazer julgamentos. Não existe um processo ideal, a maioria das organizações desenvolve seus próprios processos de desenvolvimento de software. 	a) Apenas I. 
	b) Apenas I e III. 
	c) Apenas I e IV. 
	d) Apenas II, III e IV. 
	e) I, II, III e IV. 
*
Engenharia de Software
Conteúdo da Aula
Processo de Desenvolvimento de Software Clássicos
Cascata
Prototipação
Iterativo e Incremental
Espiral
RUP
Metodologias Ágeis
*
Engenharia de Software
O Processo Unificado - RUP
Ele usa uma abordagem de orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML para ilustrar os processos em ação.
Primeiro modelo de processo inteiramente adaptado ao uso com a UML (Unified Modeling Language).
Inicialmente desenvolvido e comercializado pela Rational, e desde 2003 pertence a IBM.
Usando o seu nome original RUP
*
Engenharia de Software
Dimensões necessárias para Desenvolver Sistemas
Processo
Linguagem de Modelagem
Ferramentas
RUP / Processo Unificado
UML
Ferramentas CASE
*
Engenharia de Software
Organização do RUP
RUP é organizado:
Por tempo
Fases e Iterações
Por Conteúdo
Disciplinas 
*
Engenharia
de Software
Organização do RUP por Tempo - Fases
Concepção: Definir o escopo do projeto e alcançar a cooperação entre todos os stakeholders.
Elaboração: Especificar os requisitos prioritários e estabelecer a arquitetura.
Construção: Finalizar a implementação do Produto.
Transição: Garantir que o produto esteja disponível para seus usuários finais.
*
Engenharia de Software
Organização do RUP por Conteúdo - Disciplinas
*
Engenharia de Software
Disciplinas X Fases
Cada Iteração corresponde a um ciclo completo em todas as Disciplinas do processo.
Cada Fase (Concepção, Elaboração, Construção e Transição) é composta de uma ou mais Iterações. 
O peso de cada Disciplina em uma Fase é variável.
Cada iteração gera um Release (interno ou externo) que é uma versão estável e executável do sistema bem como quaisquer outros elementos necessários para sua utilização (a integração não fica concentrada no final ).
*
Engenharia de Software
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 1
Foco nas disciplinas de Análise de Negócios e Requisitos
Engenharia de Software
*
Engenharia de Software
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 2
O Foco é em validar a Arquitetura e o que possuir mais riscos
Engenharia de Software
*
Engenharia de Software
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 3
O Foco é em validar a Arquitetura e o que possuir mais riscos
Engenharia de Software
*
Engenharia de Software
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 4, 5, 6.... n
O Foco é na construção do software e nos testes
Engenharia de Software
*
Engenharia de Software
Gráfico das Fases x Disciplinas
Engenharia de Software
Iteração 4, 5, 6.... n
O Foco é na implantação do sistema em produção
Engenharia de Software
*
Engenharia de Software
Conteúdo da Aula
Processo de Desenvolvimento de Software Clássicos
Cascata
Prototipação
Iterativo e Incremental
Espiral
RUP
Metodologias Ágeis
*
Engenharia de Software
Scrum
Scrum é um processo ágil para gestão de projetos de software.
Em Scrum, o negócio define suas prioridades e a equipe se auto-organiza para determinar a melhor forma para entregar funcionalidades.
Scrum é embasado no empirismo e utiliza uma abordagem iterativa e incremental para entregar valor com frequência e, assim, reduzir s riscos de projeto.
Engenharia de Software
Engenharia de Software
*
Engenharia de Software
Mas o que é o Scrum?
Planejamento por Iteração
Aprendizado a partir do que está sendo entregue
Interações inter e intra equipes rápidas e constantes
*
Engenharia de Software
Framework Scrum
3 Papéis
3 Artefatos
4 Cerimônias
*
Engenharia de Software
Scrum
*
Engenharia de Software
Papéis no Scrum: Scrum Master
O Scrum master não é um gerente no sentido dos modelos prescritivos. O Scrum master não é um líder, já que as equipes são auto-organizadas, mas um facilitador (pessoa que conhece bem o modelo) e resolvedor de conflitos
*
Engenharia de Software
Papéis no Scrum: Product Owner
O Product Owner (PO), ou seja, a pessoa responsável pelo projeto em si. O product owner tem, entre outras atribuições, a de indicar quais são os requisitos mais importantes a serem tratados em cada sprint. O product owner é o responsável pelo ROI (Return Of Investment), e também por conhecer e avaliar as necessidades do cliente.
*
Engenharia de Software
Papéis no Scrum: Time
O Time Scrum é a equipe de desenvolvimento. Essa equipe não é necessariamente dividida em papeis como analista, designer e programador, mas todos interagem para desenvolver o produto em conjunto. Usualmente são recomendadas equipes de 6 a 10 pessoas.
*
Engenharia de Software
Scrum
*
Engenharia de Software
Planejamento da Sprint
O Sprint é o ciclo de desenvolvimento de poucas semanas de duração sobre o qual se estrutura o Scrum.
Normalmente tem duração de 2 a 4 semanas.
No início de cada Sprint é feito uma reunião de planejamento da Sprint, no qual a equipe prioriza os elementos do Backlog de produto a serem implementados, e transfere estes elementos do Backlog de produto para o Backlog da Sprint, ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia.
A equipe se compromete a desenvolver as funcionalidades, e o Product Owner (PO) se compromete a não trazer novas funcionalidades durante o mesmo Sprint. Se novas funcionalidades forem descobertas, serão abordadas em Sprints posteriores.
*
Engenharia de Software
Backlog de Produto
As funcionalidades ou característica a serem implementadas ou produzidas em cada projeto (requisitos, casos de uso ou histórias de usuário) são mantidas em uma lista chamada de Backlog de Produto. 
Cada funcionalidade é classificada genericamente como um item de backlog
Topo do Backlog
Itens de menor granularidade
*
*
*/34
Cartões de Histórias dos Usuários
Como um <tipo_de_usuário>, eu gostaria de <funcionalidade> para <benefício>
Requisitos dos Usuários são definidos em Histórias
Engenharia de Software
*
Engenharia de Software
Sprint
O sprint é o ciclo de desenvolvimento de poucas semanas de duração sobre o qual se estrutura o Scrum.
No início de cada sprint é feito uma reunião de planejamento da sprint, no qual a equipe prioriza os elementos do backlog de produto a serem implementados, e transfere estes elementos do backlog de produto para o backlog da sprint, ou seja, a lista de funcionalidades a serem implementadas no ciclo que se inicia.
A equipe se compromete a desenvolver as funcionalidades, e o product owner (PO) se compromete a não trazer novas funcionalidades durante o mesmo sprint. Se novas funcionalidades forem descobertas, serão abordadas em sprints posteriores.
*
Engenharia de Software
Reunião Diária
O modelo sugere que a equipe realize uma reunião diária, onde o objetivo é que cada membro da equipe fale sobre o que fez no dia anterior, o que vai fazer no dia que se segue e, se for o caso, o que o impede de prosseguir.
Essas reuniões devem ser rápidas. Por isso, se sugere que sejam feitas com as pessoas em pé e em frente a um quadro de anotações. Além disso, recomenda-se que sejam feitas logo após o almoço, quando os participantes estarão mais imersos nas questões do trabalho (longe dos problemas pessoais), além de ser uma boa maneira de dissipar o cansaço que atinge os desenvolvedores no início da tarde.
*
Engenharia de Software
Finalização da Sprint
Ao final de cada sprint a equipe deve fazer um reunião de revisão da sprint para verificar o que foi feito e, a partir daí, partir para uma nova sprint. Na reunião de revisão da sprint ocorre a demonstração e avaliação do produto do sprint.
Outra reunião que pode ser feita ao final de uma sprint é a reunião de retrospectiva da sprint, cujo objetivo é avaliar a equipe e os processos (impedimentos, problemas, dificuldades, ideias novas etc.).
*
*
*
*
Nível de fracasso é muito alto
Em suma, só descobre que aquele software não atende muito tarde
*
*
*
*
*
*
*
Os ciclos são muito curtos e as entregas são mais frequentes.
Ciclos muito longo de entregas geram produtos que as vezes não tem mais tanto valor para o cliente.
*