} Aula Anterior
} O que será abordado na aula de hoje? } Próxima aula
} Bibliografia
} Necessidades do usuário ou negócio não atendidas } Requisitos Instáveis
} Módulos que não se integram } Dificuldades de Manutenção } Descoberta tardia de erros
} Qualidade ou experiência do usuário pobres } Performance de carga sofrível
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos ◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML)
◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
} Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que consiste em várias iterações. Uma iteração incorpora um conjunto quase sequencial de atividades em modelagem de negócios, requisitos,
análise e projeto, implementação, teste e implantação, em várias proporções, dependendo do local em que ela está localizada no ciclo de
} Vantagens
◦ Os riscos são reduzidos mais cedo, pois os elementos são
integrados progressivamente.
◦ As táticas e os requisitos variáveis são acomodados.
◦ A melhoria e o refinamento do produto são facilitados, resultando
em um produto mais robusto.
◦ As organizações podem aprender a partir dessa abordagem e
melhorar seus processos.
◦ A capacidade de reutilização aumenta.
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos ◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML)
◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
“uma condição ou uma capacidade com a qual o sistema deverá estar em conformidade”
} O gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis em um sistema.
} O gerenciamento de requisitos é definido formalmente como uma abordagem sistemática a identificar, organizar e documentar os requisitos do sistema, além de firmar e
atualizar acordos entre o cliente e a equipe do projeto
sobre os requisitos variáveis do sistema.
} As chaves para o gerenciamento eficaz de requisitos incluem manter uma sentença clara dos requisitos, junto com os atributos aplicáveis e a rastreabilidade para outros requisitos e outros artefatos do projeto.
} A coleta de requisitos pode parecer uma tarefa bem precisa.
Na realidade, porém, os projetos enfrentam dificuldades pelos seguintes motivos:
◦ Nem sempre os requisitos são óbvios e podem vir de várias fontes. ◦ Existem diversos tipos de requisitos em diferentes níveis de detalhe. ◦ O número de requisitos pode se tornar impossível de gerenciar se eles
não forem controlados.
◦ Os requisitos têm propriedades exclusivas ou valores de propriedade. Por exemplo, eles não são necessariamente igualmente importantes ou igualmente fáceis de se atender.
◦ Há várias partes interessadas, o que significa que os requisitos precisam ser gerenciados por grupos de pessoas de diferentes funções (gerentes, desenvolvedores, etc.).
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos
◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML)
◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
} Os componentes são grupos de código coesos, na forma de código fonte ou executável, com interfaces bem
definidas e comportamentos que fornecem forte encapsulamento do conteúdo e são, portanto, substituíveis.
} As arquiteturas baseadas em componentes tendem a
reduzir o tamanho efetivo e a complexidade da solução e, portanto, são mais robustas e flexíveis.
} Um componente de software pode ser definido como um
pedaço não-trivial de software, um módulo, um pacote ou um subsistema, sendo que todos desempenham uma função clara, possuem uma
fronteira clara e podem ser integrados em uma arquitetura bem definida. É a realização física de uma abstração do design.
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos ◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML) ◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
} A modelagem visual é o uso de notações de design
gráficas e textuais, semanticamente ricas, para capturar
designs de software.
} Uma notação, como a UML, permite que o nível de
abstração seja aumentado, enquanto mantém sintaxe
e semântica rígidas.
} Dessa maneira, a comunicação na equipe de design melhora, à medida que o design é formado e revisado, permitindo ao leitor raciocinar sobre ele e fornecendo uma base não ambígua para a implementação.
} Para:
◦ Capturar a estrutura e o comportamento.
◦ Exibir como os elementos do sistema se integram.
◦ Manter projeto e implementação consistentes.
◦ Esconder ou exibir detalhes como for apropriado.
◦ Proporcionar uma comunicação não ambígua.
UML provê uma linguagem comum para todos os técnicos envolvidos
no projeto.
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos ◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML)
◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
} A qualidade não é uma dimensão única, mas várias. Para usar a definição e aplicá-la ao desenvolvimento de software, ela precisa ser refinada.
“caraterística de ter demonstrado a realização da criação de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados, e que é criado em um processo acordado”
} A localização e a solução dos problemas de software ficam de 100 a 1000 vezes mais caros, se realizados
após a implementação. A verificação e o
gerenciamento da qualidade durante o ciclo de vida do projeto é essencial para atingir os objetivos corretos no momento certo.
} Obter qualidade não é simplesmente “atender a requisitos” ou produzir um produto que atende às necessidades e expectativas dos usuários. Pelo contrário, a qualidade também inclui a identificação das medidas e dos critérios para demonstrar a obtenção da qualidade e a implementação de um processo para garantir que o produto por ele criado tenha atingido o grau desejado de qualidade e possa ser repetido e gerenciado.
} Melhores Práticas ◦ Desenvolvimento Iterativo ◦ Gerenciamento de Requisitos ◦ Uso da Arquitetura de Componentes ◦ Modelagem Visual (UML)
◦ Contínua Verificação da qualidade ◦ Gerenciamento de Mudança
} Um desafio importante quando se está desenvolvendo sistemas intensivos de software é lidar com vários
desenvolvedores, organizados em diferentes equipes,
possivelmente em diferentes locais, trabalhando juntos em vários iterações, releases, produtos e plataformas. } Na ausência de controle disciplinado, o processo de
desenvolvimento rapidamente se transforma em caos.
Gerenciamento de Mudança consiste de um recurso
utilizado para superar esse desafio.
} Coordenação de Atividades e de Artefatos
} Coordenação de Iterações e de Releases
} Adaptar Processos.
} Balancear Prioridades dos Interessados. } Colaboração entre Times.
} Demonstrar Valor da Iteratividade. } Elevar o Nível de Abstração. } Foco Contínuo na Qualidade.
} Ciclo de vida eficiente.
} Incrementar a agilidade do projeto.
} Planos e estimativas realísticas.
} Alinhar aplicativos às necessidades do negócio e dos usuários.
} Reduzir desenvolvimento customizado.
} Incrementar a produtividade do Time.
} Melhorar o acoplamento entre necessidades do negócio e desenvolvimento e operação dos aplicativos.
} Redução de risco prematura.
} Concordância entre interessados.
} Produtividade
} Alta qualidade.
} Incremento do progresso e da qualidade prematuramente.
} Funções:
◦ Orienta a ordem das atividades de uma equipe.
◦ Especifica quando e quais artefatos devem ser produzidos.
◦ Direciona as tarefas individuais dos desenvolvedores e a equipe
como um todo.
◦ Oferece critérios para monitorar e medir os produtos e
atividades do projeto.
} O Rational Unified Process (também chamado de processo RUP) é um processo de engenharia de software. Ele oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de software de alta qualidade que atenda às necessidades dos usuários dentro de um
} Um processo define quem (papel) está fazendo o quê
(produto de trabalho), como (tarefa) e quando (fluxo) de
modo a alcançar determinado objetivo.
} Work Product é uma abstração geral que representa algum resultado de um processo.
} Pode ser um dos seguintes elementos: ◦ Artifact (Artefato);
◦ Deliverable (Entrega); ◦ Outcome (Resultado).
} Observações:
◦ O RUP desencoraja o uso de artefatos em papel, priorizando o uso de mídia.
◦ Cada artefato deve ter apenas um responsável (na versão 2003, na 7 não
existe essa restrição)
} Podem ser organizados em cinco conjuntos de informação: ◦ Conjunto de gerenciamento.
} Artefatos são produtos de trabalho tangíveis e bem definidos consumidos, produzidos ou modificados por tarefas. Artefatos podem ser compostos por
outros artefatos. São exemplos de artefatos:
◦ Um modelo, como o Modelo de Casos de Uso ou o Modelo de
Design.
◦ Um elemento do modelo, ou seja, um elemento existente em um
modelo, como uma classe ou um subsistema.
◦ O RUP não incentiva a criação de documentos impressos, tendo
em vista que o importante é possuir modelos em ferramentas e gerar relatórios quando necessário.
◦ Um artefato pode ser modificado por vários papéis.
} Uma Entrega é um produto de trabalho que provê uma descrição e definição para o empacotamento de outros produto de trabalho.
} Uma Entrega é utilizada para pré-definir um conteúdo típico ou recomendado da forma que um produto de trabalho deve ser empacotado para a entrega.
} Um resultado descreve produtos de trabalho intangíveis como um resultado ou um estado como um servidor instalado ou uma rede otimizada.
} Resultados não possuem templates associados ou exemplos e não é possível a sua reusabilidade.
} O conceito mais central no Processo é o conceito de papel. O papel define o comportamento e as
responsabilidades de um indivíduo ou de um conjunto de indivíduos que trabalham juntos como
uma equipe, no contexto de uma organização de engenharia de software.
} Um papel é uma definição abstrata de um conjunto de
atividades executadas e dos respectivos artefatos.
} Normalmente os papéis são desempenhados por uma pessoa
ou um grupo de pessoas que trabalham juntas em equipe.
} Um membro da equipe do projeto geralmente desempenha
} Os papéis possuem tarefas que definem o trabalho que
executam.
} Uma tarefa é uma unidade de trabalho que um indivíduo,
desempenhando o papel descrito, pode ser chamado a realizar.
} A tarefa tem uma finalidade clara, normalmente expressa em
termos da criação ou atualização de alguns artefatos como um modelo, uma classe, um plano. Toda tarefa é atribuída a um papel específico.
} Em geral, a granularidade de uma tarefa é de duração de
algumas horas a alguns dias e, em geral envolve um papel e afeta um ou alguns artefatos.
} As tarefas são divididas em passos. Os passos podem pertencer a três categorias principais:
◦ Passos de reflexão: nos quais o indivíduo que executa o papel
compreende a natureza da tarefa, reúne e examina os artefatos de entrada e formula a saída.
◦ Passos de execução: nos quais o indivíduo que executa o papel
cria ou atualiza alguns artefatos.
◦ Passos de revisão: nos quais o indivíduo que executa o papel
} Riscos no RUP:
◦ Riscos de Integração
◦ Riscos Arquitetônicos.
} Categorias de Mudanças no RUP:
◦ Mudança de Requisitos.
◦ Mudanças Táticas.
◦ Lançar um produto mais cedo com menos funcionalidade.
◦ Mudanças Tecnológicas.
} Livro Texto:
