Baixe o app para aproveitar ainda mais
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).
Compartilhar