Rational Unified Process - RUP e Work Breakdown Structure - WBS

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

*
*
Rational Unified Process – RUP
 O RUP é um processo de desenvolvimento de software que utiliza a Unified Modeling Language - UML – como notação de uma série de modelos que compõem os principais resultados das atividades de uma metodologia.
 O RUP utiliza pequenos ciclos do projeto (mini-projetos), que correspondem a uma iteração e resultam em um incremento no software.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Rational Unified Process – RUP
Embora o RUP sugira um processo, ele pode ser considerado como:
 uma abordagem de desenvolvimento de software que é iterativa, centrada na arquitetura e dirigida por casos de uso, ou seja, levantamento de requisitos baseados na visão do usuário;
 um processo de engenharia de software bem definido e bem estruturado. Ele claramente define quem é o responsável pelo que, como as coisas são feitas e quando fazê-las;
 um produto processo que fornece um framework de processo customizável para a engenharia de software. Essas customizações podem ser feitas para suportar pequenas equipes e abordagens disciplinadas ou menos formal para o desenvolvimento. 
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Rational Unified Process – RUP
Desenvolvimento iterativo controlado é superior à abordagem tradicional em cascata por várias razões:
 Gerenciar a mudança de requisitos;
 Integração contínua;
 Redução dos riscos;
 Possibilidade de mudanças táticas;
 Facilita o reuso;
 Resulta numa arquitetura mais robusta;
 Aprendizado;
 Refinamento do processo.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Rational Unified Process – RUP
Todos os componentes do processo, da captura dos requisitos aos testes, são dirigidos por casos de uso.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Rational Unified Process – RUP
Os Casos de Uso definidos para um sistema são a base de todo o processo de desenvolvimento. Eles orientam o desenvolvimento:
 Na análise de requisitos os casos de uso são usados para capturar os Requisitos;
 No design devem ser identificadas as classes a partir dos casos de uso;
 Na implementação os casos de uso são implementados;
 Nos testes os casos de uso devem ser verificados. Os casos de uso tornam-se casos de teste.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Rational Unified Process – RUP
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
RUP – Estruturação do processo
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
RUP - Fases do ciclo de vida do software
O processo tem quatro fases:
 Início (Inception): definição do escopo do projeto
 Elaboração (Elaboration): planejamento do projeto, especificação das características e design da arquitetura
 Construção (Construction): construção do produto
 Transição (Transition): colocar em ação (deployment) para a comunidade de usuários
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
RUP – Iterações do ciclo de vida do software
Uma iteração é um ciclo completo de desenvolvimento finalizando com uma versão (release) de um produto executável que é um pedaço incrementado no produto final em desenvolvimento.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
RUP – Desenvolvimento iterativo
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Praxis
 É desenhado para suportar projetos realizados individualmente ou por pequenas equipes, com duração de seis meses a um ano;
 Abrange tanto métodos técnicos (requisitos, análise, desenho, testes e implementação, etc) quanto métodos gerenciais (gestão de requisitos, gestão de projetos, garantia da qualidade, gestão de configurações, etc);
 Propõe um ciclo de vida composto por fases que produzem um conjunto precisamente definido de artefatos (documentos e modelos);
 Sua linguagem de modelagem é a UML;
 Reflete muitos elementos do Processo Unificado;
 Assim como o RUP, é um processo concreto, ou seja, contém um conjunto de padrões e gabaritos para serem aplicados.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho – EAT)
 O WBS é um chek-list que identifica todas as partes do projeto e as tarefas associadas.
 É peça central no planejamento de qualquer projeto.
 Contém dois tipos de elementos:
 Pacote Trabalho – Corresponde a uma atividade que será atribuída a uma pessoa ou equipe.
 Tarefa Resumo – Corresponde a um agrupamento de pacotes de trabalho. Quando uma equipe recebe um pacote de trabalho, ela poderá listar o conjunto de atividades que precisam ser executadas e distribuir estas atividades entre os membros da equipe. O pacote de trabalho representa, então, o menor nível de gerenciamento para o gerente do projeto.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho – EAT)
Existem WBS padrão para determinados tipos de projetos, que podem servir como ponto de partida para a criação do WBS específico para o projeto, Exemplo: Engenharia Civil, Aeronáutica, Desenvolvimento de Software, etc.
O WBS para desenvolvimento de software pode ser baseado em diferentes linguagens de modelagem (Análise Essencial, UML, etc) e diferentes metodologias de desenvolvimento (Rational Unified Process - RUP, Praxis, etc).
O critério de finalização de uma tarefa pode ser definido através das respostas às seguintes requisitos:
 O que significa terminar esta tarefa? Como saber se tudo foi feito corretamente?
 Descobrir critérios de aceitação do cliente para reproduzí-los “em casa”.
 Checar a verificação do trabalho através de uma lista de verificação ou teste sistemático.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Projeto de
Desenvolvimento
de Software
Implementação
Camada de 
Regras de Negócio
Camada de 
Persistência
Camada de 
Dados
Camada de 
Interface com o 
Usuário (GUI)
Manual do
Usuário
Especificação
Modelo de 
Caso de Uso
Modelo de 
Análise
Modelo de
Designe
Modelo de 
Implantação
Modelo de
Implementação
Requisitos do
Negócio
Modelo de 
Negócio
Testes
Modelo de
Testes
Testes de 
Integração
Implantação
Banco de
Dados
Aplicações
De Software
Aplicações de
Usuários
Treinamento
Exemplo de WBS para desenvolvimento de software baseado em RUP
*
*
Os processos essenciais a qualquer projeto estão representados no diagrama de rede (ou diagrama de precedência) abaixo:
Planejamento 
do Escopo 
do Produto
Definição 
do WBS
Definição das
Atividades
Seqüência das
Atividades
Planejamento 
dos Recursos
Estimativas e
Durações
Estimativa
dos Custos
Planejamento 
dos Riscos
Programação
Orçamento
dos Riscos
Planejamento 
Global
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Além dos processos da figura anterior, alguns projetos requerem também os processos auxiliares abaixo:
Planejamento 
da Qualidade
Planejamento 
da 
Comunicação
Identificação
dos Riscos
Análise
Qualitativa
Análise
Quantitativa
Planos de 
Resposta ao
Risco
Planejamento 
Organizacional
Contratação 
de Pessoal
Planejamento 
de Aquisições
Preparação da
Documentação
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Planejamento do Escopo do Projeto
A entrada para este processo é a descrição do produto que será produzido, ou do serviço a ser executado pelo projeto.
O escopo do produto não deve ser confundido com o escopo do projeto. O escopo do projeto define o conjunto de trabalhos que serão executados para construir e entregar o produto.
Como o escopo do projeto descreve as principais atividades a serem executadas, é a base para a elaboração do cronograma e do orçamento.
Algumas vezes é necessário especificar o que o produto não vai produzir, principalmente quando existe algo que as pessoas possam presumir como sendo parte implícita do produto.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Processos podem ser definidos para:
 Desenvolvimento de software
 Manutenção de software
 Aquisição de software
 Contratação de software
Para cada um desses processos, pode-se definir sub processos.
*
*
O fogo está sob controle
Reação (e não agindo pró-ativamente)
Não há tempo para melhoria
Os “ bombeiros” se queimam
As cinzas podem voltar
a se incendiar mais tarde
Sua única forma de controle - prevenção de incêndio
Embora existam várias ferramentas para ajudar as organizações a desenvolver software com qualidade, a maioria das organizações gasta suas energias “apagando incêndios”
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
Referências Bibliográficas
Albuquerque, Antonio Roberto; Schiavo, Luciano. Uma visão de abordagem de desenvolvimento de software do Rational Unified Process. Disponível em <http://www.simpep.feb.unesp.br/Artigos%20Apresentados.htm>. Acesso em 01/02/2005.
Hazan, Claudia. Implantação de um processo de medições de software. Disponível em http://www.bfpug.com.br/Artigos/Palestra%20_Medicoes%20Claudia%20Hazan.pdf . Acesso em 03/02/2005.
Leite, Jair C. Processo de Desenvolvimento de Software. Disponível em <www.dimap.ufrn.br/~jair/ES/slides/Processo.pdf>. Acesso em 01/02/2005.
Martins, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2004.
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.
Ribeiro, Carlos Augusto. Apostila de Engenharia de Requisitos.
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Qualidade – Parte VIII.
Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.
<http://www.ibm.com/br/products/software/rational/des.phtml>. Acesso em 03/02/2005.
<http://www.esicenter.unisinos.br/index.php?pg=frm_rumocmmi25.php>. Acesso em 03/02/2005.
<www.dimap.ufrn.br/~jair/ES/slides/rup.pdf> . Acesso em 01/03/2005.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
*
*
· Conceitos da Modelagem Estruturada
· Conceitos da Modelagem Essencial
· O Paradigma Orientado a Objetos
o Objetos e classes
o Relacionamentos entre objetos
o Abstração
o Polimorfismo, Herança e Encapsulamento
Tópico 3 - Paradigmas do Desenvolvimento de Software
*
*
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Considerações sobre a Modelagem
A modelagem é um técnica de engenharia aprovada e bem-aceita;
Um modelo é uma simplificação da realidade;
Construímos modelos para compreender melhor o sistema que estamos desenvolvendo;
Construímos modelos de sistemas complexos porque não é possível compreendê-los em sua totalidade;
Um modelo é expresso através de uma linguagem (linguagem de modelagem).