Avaliação do RUP como processo para desenvolvimento de software

1. Avaliação do RUP comoprocessoparadesenvolvimento de software Autor: João Henrique Marangon Valmir Tavares Orientador: Prof. Msc. Candido Salgado Projeto de conclusão de curso BacharelemSistemas de Informação Novembro de 2009

2. ROTEIRO • Motivação • Problemas • Surgimento da Necessidade da Pesquisa • Objetivos • Processos • ProcessoUnificado

3. ROTEIRO • RUP (Rational Unified Process) • GQM (Goal Question Metric) • SistemaAvaliado • Avaliação do processo • Coleta dos Dados • Resultado • Conclusão

4. MOTIVAÇÃO De acordo com Wilson de Pádua Paula Filho (2001, p.11), processo é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações usado para atingir uma meta. A idéia do tema sugerido iniciou-se quando foi analisado que em um projeto de desenvolvimento de sistemas de informação, não eram aplicados processos adequados e satisfatórios para o seu aperfeiçoamento, o que causava a impossibilidade organizacional do sistema de informação.

5. PROBLEMAS Todos os problemas enfrentados antes da instauração dos processos: • Atraso no desenvolvimento do projeto; • Má distribuição de tarefas entre disciplinas; • Má distribuição de tarefas entre os recursos (equipe); • Falta de controle de entrega de artefatos;

6. PROBLEMAS • Falta de confiança por parte do cliente; • Falta de qualidade nos artefatos entregues; • Descontrole do projeto quanto ao escopo; • Descontentamento do cliente.

7. SURGIMENTO DA NECESSIDADE DA PESQUISA A necessidade do caráter organizacional do desenvolvimento de Sistemas de Informação através de processos adequados, promovendo o bom funcionamento da equipe de Projeto, construindo assim relações satisfatórias entre cliente e empresa.

8. OBJETIVOS O objetivo da pesquisa é demonstrar através de um estudo de caso, a implantação bem sucedida de processos para desenvolvimento de software.

9. PROCESSOS Em engenharia de software, processo é um conjunto de passos parcialmente ordenados, cujo objetivo é atingir uma meta: entregar um produto de software de maneira eficiente, previsível e que atinja as necessidades de negócio. Um processo somente e definido quando este possui documentações que detalham o que é feito (produto), quando (passos), por quem (agentes), o que é utilizado (insumos) e o que é produzido (resultados).

10. PROCESSO UNIFICADO Como exemplo de processos podemos citar o Processo Unificado, que descende de métodos como o PSP (Personal Software Process) e o TSP (Team Software Process). O Processo Unificado apresenta as seguintes características centrais: • É dirigido por casos de uso; • É centrado na arquitetura; • É iterativo e incremental.

11. PROCESSO UNIFICADO Seu ciclo de vida e dividido nas seguintes fases: • Concepção • Elaboração • Construção • Transição Suas atividades são dividias nos seguintes fluxos de trabalho: • Requisito – Visa obter um conjunto de requisitos de um produto • Análise – Detalha, estrutura e valida os requisitos • Design – Formula um modelo estrutural do produto • Implementação – Realiza o design em termos de componentes de código • Teste – Verifica os resultados da implementação

12. RUP O RUP (Rational Unified Process) é um processo de engenharia de software (Kruchten). Segundo Kruchten, o RUP captura muitas das melhores práticas para o desenvolvimento de software.

13. RUP O RUP apresenta duas dimensões, ou dois eixos:

14. GQM (Goal Question Metric) A idéia básica do GQM é derivar métricas de software a partir de perguntas e objetivos. O processo de definição de um programa de métricas deve ser baseado nas necessidades de informação de cada nível organizacional. Isso pode ser obtido a partir do levantamento de informações junto às áreas interessadas.

15. GQM Cada uma das siglas do GQM tem um propósito, conforme descrito a seguir: • Goal - Quais são as metas/objetivos? • Question - Quais as questões que deseja responder? • Metric - Quais métricas poderão ajudar?

16. GQM As vantagens do GQM são: • Apóia a definiçãotop-down do processo de medição e a análise bottom-up dos dados resultantes; • Ajuda na identificação de métricas úteis e relevantes; • Apóia a análise e interpretação dos dados coletados; • Permite uma avaliação da validade das conclusões tiradas; • Diminui a resistência das pessoas contra processos de medição.

17. SISTEMA AVALIADO Breve histórico do sistema avaliado Desenvolvimento do Sistema de Folha de Pagamento utilizando o RUP.

18. AVALIAÇÃO DO PROCESSO A ferramenta utilizada para avaliação da qualidade do processo de desenvolvimento de software é o GQM. Planejamento: • Analisar o processo para o desenvolvimento do software • Com o propósito de verificar a qualidade do produto com a utilização do processo

19. AVALIAÇÃO DO PROCESSO • com respeito a utilização do processo para o desenvolvimento do software • Sob o ponto de vista da análise do ponto de vista do projeto e equipe de projeto • No contexto do desenvolvimento de um sistema de pagamento

20. AVALIAÇÃO DO PROCESSO As questões foram separadas por disciplinas dentro da equipe de projeto. • Avaliação do processo geral – Analista de qualidade • Avaliação do processo para a disciplina de Gerência de projetos • Avaliação do processo para a disciplina de requisitos • Avaliação do processo para a disciplina de gerenciamento de configuração e mudança • Avaliação do processo para a disciplina de implementação

21. AVALIAÇÃO DO PROCESSO Coleta de Dados Envio de formulários para cada integrante da equipe avaliada com as seguintes alternativas: • Muito satisfatório • Satisfatório • Pouco satisfatório • Insatisfatório

22. AVALIAÇÃO DO PROCESSO Resultado

23. CONCLUSÃO A utilização de um Processo, quando bem definido e gerenciado, traz benefícios para o produto final do software. De acordo com a pesquisa realizada, a principal vantagem em se utilizar processo no desenvolvimento de um sistema é a organização

24. CONCLUSÃO Com esses conceitos em mente, foi realizada a avaliação para verificar se dentro do projeto citado no decorrer desta pesquisa o processo definido pela empresa estava sendo utilizado corretamente. Concluiu-se que este, no momento da coleta de dados, estava sendo seguido de forma coerente ao que foi proposto pelo órgão verificador de qualidade da empresa.

25. Perguntas e comentários“Não se podegerenciaraquiloquenãopode ser medido” – Tom DeMarco