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

Avaliação do RUP como processo para desenvolvimento de

software

Autor: João Henrique Marangon

Valmir Tavares

Orientador: Prof. Msc. Candido Salgado

Projeto de conclusão de curso

Bacharel em Sistemas de Informação

Novembro de 2009

• Motivação

• Problemas

• Surgimento da Necessidade da Pesquisa

• Objetivos

• Processos

• Processo Unificado

ROTEIRO

• RUP (Rational Unified Process)

• GQM (Goal Question Metric)

• Sistema Avaliado

• Avaliação do processoo Coleta dos Dadoso Resultado

• Conclusão

ROTEIRO

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.

MOTIVAÇÃO

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;

PROBLEMAS

• Falta de confiança por parte do cliente;

• Falta de qualidade nos artefatos entregues;

• Descontrole do projeto quanto ao escopo;

• Descontentamento do cliente.

PROBLEMAS

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.

SURGIMENTO DA NECESSIDADE DA

PESQUISA

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

OBJETIVOS

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).

PROCESSOS

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.

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

PROCESSO UNIFICADO

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.

RUP

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

RUP

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.

GQM (Goal Question Metric)

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?

GQM

As vantagens do GQM são:

• Apóia a definição top-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.

GQM

Breve histórico do sistema avaliado

Desenvolvimento do Sistema de Folha de Pagamento utilizando o RUP.

SISTEMA AVALIADO

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

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

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

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

AVALIAÇÃO DO PROCESSO

Resultado

AVALIAÇÃO DO PROCESSO

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

CONCLUSÃO

CONCLUSÃOCom 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.

Perguntas e comentários

“Não se pode gerenciar aquilo que não pode ser medido” – Tom DeMarco