Plano de Projeto de Software ControlArt - Rascunho

Pessoal, boa noite.

Segue abaixo rascunho do Plano de Projeto de Software ControlArt (Sistema para Controle de Acervo de Arte).

RUP: Boas Práticas para o Desenvolvimento de Software

Pessoal, boa noite!

   O termo boas práticas (derivado do inglês, best practices) denomina o melhor conjunto de técnicas para realizar uma determinada tarefa. O Rational Unified Process (RUP) engloba muitas das boas práticas do desenvolvimento de software moderno, tornando-se adequado para uma grande quantidade de projetos e organizações que desejam obter valores precisamente quantificados e, ao mesmo tempo, padrões comprovados de sucesso. 

   Hoje falaremos um pouco sobre algumas dessas práticas incorporadas pelo RUP:

• Desenvolvimento de software iterativo: Os sofisticados produtos de software da atualidade não são compatíveis com o modelo tradicional de desenvolvimento sequencial. Dependendo da abordagem utilizada, a necessidade de refinamentos sucessivos (com o intuito de aprimorar a lógica de negócio), mudanças nos requisitos e no calendário, que podem gerar diversas versões finais (releases) de um produto de software, requerem uma abordagem iterativa de desenvolvimento. O RUP descreve como utilizar esse modelo e como gerir os riscos provenientes desse novo enfoque;
  
• Gerenciamento de requisitos: O RUP possui ferramentas que permitem criar, organizar e documentar requisitos e restrições de um produto de software. O objetivo desse intento é garantir coerência e precisão durante a etapa de desenvolvimento (e suas diversas fases) e de entrega do produto (verificar se o produto entregue era realmente o esperado);
  
• Utilização de uma arquitetura baseada em componentes: O RUP apresenta um modelo que procura construir uma arquitetura robusta e ao mesmo tempo flexível, com o foco na reutilização de componentes complexos (ou criação de novos). O intuito dessa abordagem é acomodar mudanças e torná-las facilmente entendíveis, afim de viabilizar a reutilização de software;
  
• Modelagem visual do software: O Processo Unificado Rational também descreve como modelar software visualmente para melhorar a estrutura e o comportamento da arquitetura e dos componentes de um produto de software. A UML (Unified Modeling Language), por exemplo, é muito utilizada para esses propósitos;
  
• Análise da qualidade do software: Garantir a qualidade do software é uma preocupação de que está presente em todas as fases do processo de construção. O RUP assegura, em todas as suas atividades, que exista o controle da garantia da qualidade do software. Esse papel não é executado por uma ferramenta à parte;
  
• Controle das mudanças do software: Uma modificação em um produto de software só é aceitável se as suas consequências forem previamente conhecidas. Um sistema que atua em um ambiente inconstante, deve estar preparado para suportar mudanças. O Processo Unificado Rational descreve como controlar, rastrear e monitorar com êxito tais mudanças, assegurando que possa existir um ambiente iterativo real.

Isso é tudo pessoal.

Um forte abraço a todos. 

Até a próxima!

Fonte:

[1] IBM Rational Unified Process | Último acesso em 14/01/2014.

Reengenharia de sistemas com RUP

Boa tarde pessoal,

 

Vou falar hoje sobre uma experiência que terminou como TCC de estudantes da Universidade Federal de Florianópolis, é a utilização do RUP aplicado a reengenharia de sistema.

 

O trabalho trada da experiência no uso da metodologia de desenvolvimento RUP em um processo de reengenharia de sistemas. O RUP foi escolhido devido a suas característica altamente adaptativa. e que se mostrou útil ao caso de uso proposto pelo trabalho.

A reengenharia foi aplicada ao sistema da Associação de Professores da UFSC desenvolvido em Microsoft Access e com pouca documentação.

Pressman como um dos prisma da reengenharia a criação de um produto com funcionalidades adicionais e melhoras no sistema e na forma de manutenção dele, sendo utilizado para a migração de sistemas legados com pouca documentação ou migração de sistemas locais para sistemas baseados na internet.

Muitos pensam no RUP para utilização em projetos novos onde existem bem definidas todas as fases do projeto porém como é mostrado no trabalho muitos artefatos podem ser utilizados no processo de reengenharia.

 O documento utiliza a ideia do Business Process Reengineering que é você fazer a avaliação crítica  de todo negócio existente e tentar encontrar meios novos para sua reconstrução.

Também explica que projetos de reengenharia tem grandes chances de fracasso, entre 50% a 70% segundo Jacobson, e o documento abordar segundo Pressman os principais motivos desse fracasso.

Para utilização do RUP nesse cenário ou em qualquer outro é preciso manter os princípios do RUP.

 

• Suavização antecipada de riscos/mudanças;

• desenvolvimento iterativo;

• avaliação progressiva;

• organização em pequenos times;

• verificação contínua de qualidade;

• gerenciamento de escopo;

• produção apenas dos artefatos necessários.

Também mesmo em um projeto de reengenharia deve-se criar os documentos de Visão, Planejamento do Projeto, Avaliação de Riscos entre os outros artefatos mínimos para projetos e definir os artefatos do sistema legado. 

O levantamento de requisitos tem uma fase para identificação dos requisitos dos sistema legado e sua adaptação para os requisitos atuais.

Durante a analise em que é feito a expansão dos casos de usos e eventos do sistemas caso o sistema legado tenha interface definida a expansão do caso de uso pode utilizar os casos de uso reais. Wazlawick aborda a falta de necessidade para projetos de reengenharia já que a versão de caso de uso essencial é para explorar sistemas desconhecido em que se precisa ter um aprendizado para a construção de telas. Em projetos de reengenharia é indicado manter a interface compatível com a antiga.

Quando se está no projeto os principais artefatos são os diagramas de interação baseado nos diagramas de classe sendo construindo da mesma forma que um processos de projeto baseado em engenharia normal.

Após o projeto é feita a implantação, durante a implantação encontra-se mais dificuldades comparados a um projeto novo. Para Kruchten, sistemas feitos de reengenharias trazem problemas como a conversão de dados, continuidade de operação e re-treinamento do pessoal bem como a confiança do usuário no novo sistema.

 

Kruchten alinha o fluxo de trabalho de reengenharia com as fases do RUP e os documentos necessários a mais para cada fase.

 

concepção - documento dos artefatos a serem reconstruídos e iniciação do processo de engenharia reversa para os artefatos de requisitos e análise.

elaboração – A elaboração aproveita os artefatos antigos e todos devem ser revisados e incorporados.

construção - A fase de construção do RUP segue como a de um projeto de software de engenharia normal. Os artefatos legados são implementados e atualizados.

transição - A fase de transição encontram-se os elementos mais delicados. Necessários atenção para a migração de dados, a desativação do sistema que está sendo substituído.

No estudo de caso do trabalho os autores descrevem as atividades de todas as fases do RUP que permitiu a reengenharia minimizando as chances de falhas ou erros durantes o projeto.

A baixo vou reproduzir a conclusão que os autores tiveram sobre o estudo realizado.

Conclusão

Um processo de reengenharia pode ser visto sob dois diferentes prismas, a reengenharia de negócios e a reengenharia de sistemas. A primeira, também chamada de BPR, é muito mais abrangente, envolve toda uma organização e acaba, em última instancia, levando também à segunda.

A reengenharia de sistemas, foco deste trabalho, pode ser vista como uma atividade composta, basicamente, dos seguintes passos: conhecer o software existente e as razões que levam à necessidade de uma reengenharia; fazer a engenharia reversa do sistema existente a fim de se obter conhecimento e documentação o bastante sobre ele para se realizar a construção de um novo sistema; e, realizar a construção do novo sistema partindo-se da documentação gerada com a engenharia reversa e dos requisitos que levaram ao processo de reengenharia.

Neste trabalho verificou-se o poder de adaptação do Rational Unified Process quando este pôde ser perfeitamente utilizado em um processo de reengenharia. Num primeiro momento, usou-se a fase de concepção do RUP para se estudar o sistema existente e levantar os requisitos que motivaram a realização da reengenharia.

Em seguida, foi possível se utilizar, com algumas pequenas adaptação, os fluxos de levantamento de requisitos, análise e projeto de RUP para se estudar e documentar o sistema existente a fim de preparar a base para a construção do novo sistema. Dentre as adaptação feitas pode-se citar:

• identificação de requisitos a partir da análise do sistema já existente; • identificação de conceitos a partir da estrutura de dados ou banco de dados do sistema legado;

• identificação dos casos de uso e consultas a partir da estrutura e dos processos dos sistema;

• expansão dos casos de uso diretamente para casos de uso reais utilizando-se como modelo de interface gráfica a interface do próprio sistema existente;

• elaboração dos contratos usando-se como base, além dos casos de uso, as funções do sistema legado.

A construção do sistema a partir dos artefatos gerados com o auxílio de uma engenharia reversa acaba sendo praticamente igual à construção de um sistema qualquer. Um dos grandes desafios de uma reengenharia surge no final, na implantação do sistema, quando deve-se tomar cuidado com a estratégia utilizada afim de se evitar problemas com os usuários finais.

O processo de reengenharia do sistema da APUFSC não foi completado principalmente por dois motivos: o pouco tempo de desenvolvimento deste trabalho e a falta de mão- de-obra para o desenvolvimento. Porém, mesmo não se tendo feito o processo todo, foi possível avaliar bem o uso do RUP em um projeto dessa natureza e algumas adaptações interessantes foram propostas.

 

 

https://projetos.inf.ufsc.br/arquivos_projetos/projeto_218/TCC-PauloCesarAllebrandt.pdf

 

 

As baleias do RUP

Bom dia, hoje vamos dar uma olhada no que alguns conhecem como baleias do RUP. O RUP divide suas iterações em fases e disciplinas. Elas devido duas características e tempo em cada disciplina formam gráficos que lembram desenhos de baleias.

A ideia do tópico hoje é interpretar esse gráfico tão conhecidos por aqueles que já fizeram algum estudo sobre o processo.

O ciclo do projeto no RUP é dividido em fases: Iniciação, Elaboração, Construção, Transição. As disciplinas são as divisões das atividades do RUP, no total são nove disciplinas que por sua característica iterativa e incremental acontecem em todas as fases de desenvolvimento.

Só que dependendo da maturidade do projeto, ou do tempo decorrido de execução dele algumas atividades tem maior importância que outras. Quando dividido esse tempo decorrido de execução em fases bem distintas percebemos isso com mais clareza.

Olhando o gráfico fica claro que as disciplinas de Modelagem, Requisito, ocorrem com maior intensidade no início de um projeto. Em seguida a disciplina de análise e projeto ganha maior foco enquanto até acontecer a transição para a parte de implementação. A disciplina de teste acontece quando a parte de implementação já está em seu fim seguido da fase de implantação.

As disciplinas de Gerencia de configuração e mudança, gerenciamento de projeto e ambiente acontecem quase de forma constante durante todo o projeto sendo que são atividades de suporte a execução do projeto por isso não atingem picos em que demando maior esforço que o próprio projeto.

Conseguimos ver a característica incremental do RUP nesse gráfico também. Nenhuma das disciplinas deixa de ser executada durante alguma fase. Isso porque o RUP é um processo que consegue atender a imprevisibilidade do desenvolvimento de um projeto de software. Por isso mesmo que não seja comum os requisitos podem sofrer mudanças em fases mais avançadas do projeto.

Espero que com isso o gráfico consiga ser visto com maior clareza e não assuste aqueles que buscam conhecer o RUP.

Abraços.

Atualização PMBOK 5° Edição

Olá pessoal! Falaremos agora sobre algo que acabou de sair do forno. Em 2013 houve a atualização do PMBOK 4° edição para a 5° edição.

Resumo das principais mudanças: - Adição de 1 nova área de conhecimento;
                                                     - 7 novos processos; e
                                                     - Remoção de 2 processos.

A nova área adicionada ao PMBOK 5° edição foi a "Gerenciamento das Partes Interessadas do Projeto"

Abaixo segue tabela com as áreas de conhecimento e processos atualizados:

;
                                                   

                                      Em próximos posts desceremos um pouco mais o nível de conhecimento e elucidaremos a fundo algumas dessas mudanças.

Relacionando RUP e PMBOK - Parte 2

Uma característica do PMBOK é que ele deve ser aplicado ao processo de negócio existente. Dessa maneira, uma empresa pode utilizar o RUP como seu processo de desenvolvimento de software e aplicar o PMBOK. Dessa forma, em cada uma das fases do RUP seriam utilizadas as melhores práticas do PMBOK.

Uma maneira de se fazer isso é através de mapeamentos:

1. Mapeia-se as papéis, processos e saídas do PMI para os papéis, atividades e artefatos do RUP. Recomenda-se que se agrupe pelos papéis do RUP.
2. Para cada atividade de um papel, mapeia-se para um grupo de processos do PMBOK. Esse processo é repetido para cada grupo de papéis até todas as atividades estarem mapeadas para um processo.
3. Compara-se então as diferenças das demais características (saídas, técnicas, ferramentas) e ajustam-se as atividades que não estão de acordo com o PMBOK.

É importante notar que esse mapeamento vai mudar de acordo com a configuração do RUP escolhida, já que a quantidade de papéis e atividades vai mudar de acordo com o tamanho do projeto e da equipe.

E essa é uma das formas de utilizar RUP e PMBOK em conjunto. Abraços!

Relacionando RUP e PMBOK - Parte 1

O RUP e o PMBOK são dois frameworks que podem ser utilizados de maneira conjunta. Vejamos uma breve comparação entre eles para entendermos melhor:

• O PMBOK descreve as melhores práticas utilizadas na indústria. O RUP ajuda uma equipe de desenvolvimento de software implementar as melhores práticas.
• O PMBOK descreve um ciclo de vida para um projeto genérico. O RUP descreve um projeto de software genérico dentro de um ciclo de vida de um projeto.
• O PMBOK descreve como gerenciar projetos de qualquer tamanho. O RUP pode ser utilizado para criar um software de qualquer tamanho.

Pode-se dizer que o PMBOK descreve as melhores práticas de gerenciamento de projetos enquanto o RUP ajuda a colocar em prática essas recomendações. Então isso significa que o RUP é um 'produto derivado' do PMBOK? Não exatamente.

Mais sobre essa relação num futuro post. Abraços!

Fonte: 

http://www.ibm.com/developerworks/rational/library/4763.html