RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)

Slides:



Advertisements
Apresentações semelhantes
Projeto Qualified Curriculum
Advertisements

RUP – Rational Unified Process
Engenharia de Software
Engenharia de Software
Engenharia de Software
Participantes do Processo de Desenvolvimento de Software
Processos de Software Introdução
Rational Unified Process(RUP)
Gestão de Projetos Áreas de conhecimentos Integração
Valéria Maria Lauande Março/2010
Engenharia de Software Professor Sandro de Paiva Carvalho.
RUP - Rational Unified Process
Metodologia de Desenvolvimento de Software
RUP Rational Unified Process (Processo Unificado de Desenvolvimento da Rational) 1.
Gestão de projetos de Software GTI-16
Gabriel Silva Bornia Prof. Dr. Roberto Tom Price Orientador
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Metodologia Versão 2 FSRS.
Análise e Gerenciamento de Requisitos com Casos de Uso
Análise e Gerenciamento de Requisitos com Casos de Uso Módulo 0 Sobre o Curso.
Engenharia de Software
Classes e objetos Modelagem
Alunos: Artulanez Souza Iony Melo
RUP Prof.ª Elaine B. Figueiredo.
Rational Unified Process
RUPinho Qualidade de Software
Aula 1 Minicurso: Astah Ministrantes: André Martins; Camila Brondani;
Planejamento e Gerenciamento de Projetos
Visão Geral PRO.NET.
Visão Geral do RUP.
Fundamentos de Engenharia de SW
Análise de Sistemas de Software Prof. Rodrigo Ribeiro.
Processos de Desenvolvimento de Software – Parte 2
Arquitetura do Software
Engenharia de Software
Gerência de Configuração - GC
Modelagem de Negócio no RUP
PAS Características: Elaborado com o propósito de ser utilizado em práticas acadêmicas de desenvolvimento de software. Foi desenvolvido de forma iterativa.
Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014
PSBD II Projeto de Sistemas de Banco de Dados II
O Processo de desenvolvimento de software
Especificação em Projeto de Sistemas
Abr-17 Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto Fluxo de análise e projeto.
Análise e Projeto Orientados a Objetos
Bruno Silva Desenvolvido a partir de
RUP - Cap. 5 – Processo Iterativo e Incremental
Introdução ao Processo Unificado de Desenvolvimento de Software Tiago Lima Massoni UFPE
Engenharia de Software
Capturando Requisitos com Use Cases Disciplina: Estudo do RUP Autor: Tiago Lima Massoni Orientacao: Augusto Sampaio Paulo Borba.
RUP - Cap. 4 – Processo Centrado na Arquitetura
Processo de Desenvolvimento de Software – PDS C Construção - PAS
RUP - Cap. 3 – Processo Dirigido por Caso de Uso
Trabalho de Engenharia de Software II
Gestão de projetos de Software GTI-16
Engenharia de Software
Engenharia de Software
Capítulo 2: Os 4 Ps (Pessoas, Projeto, Produto, Processo)
© Nabor C. Mendonça Processo / Metodologia de Desenvolvimento de Software.
Análise e Projeto de Sistemas Unified Modeling Language Renata Araujo Ricardo Storino Núcleo de Computação Eletrônica Curso de Programação de Computadores.
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
Aula 02 de Eng. de Requisitos
APSI II Análise e Projeto de Sistemas de Banco de Dados II.
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
Engenharia de Software com o RUP - Workflow de Requisitos
Dimitri de Almeida Malheiros Barbosa
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto.
O Processo Unificado (PU). 2 O que é o Processo Unificado (PU)? É um modelo de processo de software baseado no modelo incremental, visando a construção.
Transcrição da apresentação:

RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo) Disciplina: ESOF2 Prof. Adriana M. Martins

Visão Geral Pessoas Projeto Produto Processo Ferramenta Template participam Resultado Automação

Visão Geral Um processo de Desenvolvimento de Software é realizado por várias pessoas. Quem são elas? - Arquitetos, desenvolvedores, testadores, equipe de suporte, usuários, clientes e fornecedores.

Pessoas São Cruciais (P1) Elas estão envolvidas em todo ciclo de desenvolvimento do software. O processo de desenvolvimento afeta pessoas: Viabilidade do Projeto: modelo iterativo é apoio; Gerenciamento de Riscos: riscos não calculados preocupam; Estrutura da Equipe: equipes menores tem maior rendimento; Cronograma do Projeto: deve ser realístico e de acordo com a capacidade de produção da equipe.

Pessoas São Cruciais (P1) a) O processo de desenvolvimento afeta pessoas: Entendimento do Projeto: pessoas gostam de saber o que farão, e onde se deseja chegar; Senso de Comprometimento: é preciso um feedback à equipe no fim de cada iteração, pois isso os incentivará e direcionará seu trabalho. Mostrar resultados gera senso de comprometimento.

Pessoas São Cruciais (P1) b) Os papéis irão mudar: O processo precisa de guia. O sistema a ser construído será cada vez mais complexo e deverá ter vida longa, por isso é preciso entender bem o negócio: Trabalho Cooperativo : várias pessoas de diferentes áreas; A equipe mudará com o tempo (os papéis também); As pessoas são cruciais, é necessário ter na equipe pessoas certas, que fazem acontecer PROJETO DE SUCESSO!

Pessoas São Cruciais (P1) c) Tornando “recursos” em “Trabalhadores”: Pessoas exercem diferentes papéis num projeto. Recursos  Pessoas; Trabalhador  posição na qual o recurso pode ser alocado (analista, arquiteto, gerente, testador.. etc); Responsabilidade do trabalhador: executar um conjunto de atividades. É preciso ter informações efetivas sobre o que será realizado por ele e sua relação com os demais trabalhadores. Um trabalhador poderá assumir diferentes posições no projeto.

Projetos fazem o Produto (P2) O desenvolvimento de um projeto sempre resultará num produto (resultado de várias iterações). A condução do projeto segue padrões organizacionais e afetam: Seqüência de Mudanças: cada ciclo resulta num release (versão) e a seqüência de ciclos mudará o produto continuamente até a versão final. Série de Iterações: cada iteração implementa uma série de casos de uso e mitiga riscos.

Produto é mais que Código (P3) No UP o produto é o software desenvolvido (sistema). O produto não é somente o código entregue (executável) mas o sistema como um todo. Definição de SISTEMA: “É o conjunto de todos os artefatos que são tomados para serem representados numa máquina ou de forma legível para máquina, trabalhadores ou usuários.”

Produto é mais que Código (P3) Definição de ARTEFATOS: “Qualquer tipo de informação criada, produzida ou usada pelos trabalhadores no desenvolvimento do sistema. (Ex: Diagramas UML, descrições textuais...)” Há dois tipos de artefatos: Artefatos de Engenharia: documentação, diagramas, código (foco do UP). Artefatos de Gerenciamento: planejamento, execução, controle do projeto.

Produto é mais que Código (P3) O sistema é um conjunto de modelos. O artefato mais importante no UP é o MODELO. Cada trabalhador precisa de uma perspectiva única do modelo. Analistas SISTEMA Arquiteto Gerente do Projeto Usuários Testadores Desenvolvedores

Produto é mais que Código (P3) O modelo é a abstração do sistema (uma visão) com características específicas para cada trabalhador dentro do processo. Definir o modelo do sistema é uma das decisões mais importantes no processo.

Produto é mais que Código (P3) O conjunto de modelos do UP dá informações claras sob o sistema e todos os trabalhadores envolvidos, sendo eles: Modelo de Caso de Uso Modelo de Análise Modelo de Design Modelo de Desenvolvimento Modelo de Implementação Modelo de Testes “Cada modelo é uma abstração semântica fechada do sistema”, sendo assim, o modelo não precisa de outra informação adicional para interpretá-lo.

Produto é mais que Código (P3) Os modelos no UP se relacionam mutuamente. Cada relacionamento no UML é chamado de “traço de dependência”. As dependências entre modelos adicionam informações não semânticas para ajudar a entender os modelos e suas relações. M. Caso Uso M. Análise M. Design ....

consistentes, que representem um Processos direcionam Projetos (P4) Processo no UP é a chave do desenvolvimento de sistemas. É definido como um template (molde). É a definição de um conjunto de atividades, e não de sua execução!! Definição de PROCESSO: “Processo é o conjunto de atividades necessárias para transformar requisitos de usuários em artefatos consistentes, que representem um produto de software.“

Processos direcionam Projetos (P4) Relação entre Processos e Fluxos: “As atividades relacionadas constituem os fluxos (workflows).” Como organizar o fluxo? a) Identificar os diferentes trabalhadores necessários no processo; b) Identificar os artefatos que serão criados por cada trabalhador no processo. RESULTA Descrição de como o processo flui através de trabalhadores e artefatos produzidos por eles.

Processos direcionam Projetos (P4) Exemplo de Fluxo de Atividades (modelagem de um Caso de Uso no UP): Cria a Interface do usuário Projetor da interface Encontrar atores e Casos de Uso Analista de Sistemas Especificador de caso de uso Arquiteto Detalha os Casos de Uso Priorizar os Estrutura o modelo de Caso de Uso

Processos direcionam Projetos (P4) Especializando um Processo: O RUP é genérico, precisa ser instanciado; Processos irão variar porque haverão diferentes contextos, tipos de sistemas e regras de negócios. O processo precisa se adaptar ao mundo real e ser configurado de forma a atender as necessidades específicas de uma organização.

Processos direcionam Projetos (P4) Fatores a considerar para especializar o Processo: Fatores Organizacionais: estrutura, gerenciamento, cultura e experiência no desenvolvimento de software; Fatores de Domínio: domínio da aplicação, suporte ao negócio, usuários e concorrência; Fatores de Ciclo de Vida: expectativa do ciclo de vida do software, desenvolvimento, tecnologia e futuras versões; Fatores Técnicos: linguagem de programação, ferramentas de desenvolvimento, banco de dados, modelo, arquitetura, comunicação e distribuição.

Processos direcionam Projetos (P4) Benefícios do uso de um Processo: Clareza de papéis a serem executados no projeto (trabalhadores, artefatos); Entendimento das atividades dos colegas mesmo em localizações geográficas diferentes (outsourcing); Clareza de papéis dos desenvolvedores para os gerentes/supervisores; Transferência de gerente/trabalhadores entre projetos; Treinamento padronizado; Estimativa de custos e prazos facilitada; Aperfeiçoamento da equipe como um time.

Ferramentas integram o Processo As ferramentas são parte integrante do processo; São úteis para automatizar tarefas repetitivas, manter dados estruturados e consistentes, gerenciar grande volume de informações e ser um guia formal durante o processo de desenvolvimento; Aumento de qualidade da informação e produtividade da equipe. Situação: imagine a atualização de modelos e fluxos de processo sendo gerenciados de forma manual, para cada iteração e incremento??? Isto é vantajoso?

Ferramentas integram o Processo As ferramentas são utilizadas para automatizar e formalizar o processo tanto quando possível. Um processo automatizado proverá meios eficientes para que a equipe trabalhe de forma coerente e proverá meios para validação de das consistências entre os artefatos. Características das Ferramentas: Facilidade de uso (reuso e diferentes alternativas de utilização); Eficiente (compensar o tempo de aprendizado).

Ferramentas integram o Processo As ferramentas deve atuar bem sob demanda (acesso simultâneo); As ferramentas devem suportar todos o ciclo de vida do desenvolvimento de software. Considerações sobre a UML A UML suporta modelagem visual ; A UML define regras sintáticas – elementos da linguagem de construção; A UML define regras semânticas - garante integridade entre versões dos modelos.

Ferramentas integram o Processo Exemplo de Ferramentas: - Gerência de Projetos, UML, desenvolvimento, testes, qualidade. Site On-line do RUP: http://www.wthreex. com/rup/ Site para baixar versão em Português do RUP: http://files.filefront.com/3952633

Visão Geral As necessidades dos usuários relativas aos requisitos não podem ser implementadas todas de uma vez, elas serão refinadas em sucessivas iterações.