Antonio Marcos Neves Esteca. Apoio à maturidade pessoal visando a melhoria dos projetos de software

Tamanho: px
Começar a partir da página:

Download "Antonio Marcos Neves Esteca. Apoio à maturidade pessoal visando a melhoria dos projetos de software"

Transcrição

1 Antonio Marcos Neves Esteca Apoio à maturidade pessoal visando a melhoria dos projetos de software São José do Rio Preto 2013

2 Antonio Marcos Neves Esteca Apoio à maturidade pessoal visando a melhoria dos projetos de software Dissertação apresentada como parte dos requisitos para obtenção do título de Mestre em Ciência da Computação, junto ao Programa de Pós-Graduação em Ciência da Computação, Área de Concentração - Sistemas de Computação, do Instituto de Biociências, Letras e Ciências Exatas da Universidade Estadual Paulista Júlio de Mesquita Filho, Campus de São José do Rio Preto. Orientadora: Profª. Drª. Rogéria Cristiane Gratão de Souza São José do Rio Preto 2013

3 Esteca, Antonio Marcos Neves Apoio a maturidade pessoal visando a melhoria dos projetos de software / Antonio Marcos Neves Esteca. - São José do Rio Preto: [s.n.], f. : il. ; 30 cm. Orientador: Rogéria Cristiane Gratão de Souza Dissertação (mestrado) - Universidade Estadual Paulista, Instituto de Biociências, Letras e Ciências Exatas 1. Computação. 2. Engenharia de software. 3. Software de aplicação. I. Souza, Rogéria Cristiane Gratão. II. Universidade Estadual Paulista, Instituto de Biociências, Letras e Ciências Exatas. III. Título. CDU Ficha catalográfica elaborada pela Biblioteca do IBILCE Campus de São José do Rio Preto - UNESP

4 Aos meus pais, avós e namorada. i

5 ii AGRADECIMENTOS Agradeço primeiramente a Deus, por sempre ter iluminado os caminhos por onde trilhei, dando força e coragem para seguir em frente da maneira correta. Agradeço aos meus pais, João e Angela, que sempre apoiaram meus estudos como a forma de alcançar horizontes cada vez melhores. Agradeço também a todos os familiares que ajudaram e incentivaram minha formação, principalmente a meus avós, Antônio e Tereza, e irmãs, Ariane e Fernanda, pelo apoio que deram, mesmo sem saber que o estavam dando, desde meus primeiros anos de estudo. Gostaria de expressar também profunda gratidão à minha namorada, Talita, que desde o primeiro ano de graduação esteve ao meu lado, fazendo com que eu enxergasse as situações com olhar mais tranqüilo e confiante, sempre com muita compreensão e carinho nos momentos em que estive ausente para dedicar-me exclusivamente aos estudos. À professora Rogéria, agradeço imensamente por ter me orientado desde o primeiro semestre da graduação, oferecendo condições para meu amadurecimento não somente intelectual, mas também pessoal, tendo me ensinado, dentre outras lições, que enfrentar desafios é a única maneira de crescermos e aprimorarmos nossas capacidades. Ao Grupo de Estudos e Pesquisas em Engenharia de Software (GEPES), em especial à Professora Adriana e ao Wanderson, agradeço por todo o suporte oferecido durante a realização deste projeto. De maneira especial, agradeço a todos meus colegas, principalmente ao Victor, Júlio César e Junior que, compartilhando momentos de dificuldade, mostraram que o importante não é vencer todos os dias, mas batalhar sempre por nossos objetivos. Por fim, agradeço à Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) por ter apoiado financeiramente a realização deste projeto através da concessão de bolsa de mestrado por meio do processo número 2010/

6 iii Procure ser uma pessoa de valor, em vez de procurar ser uma pessoa de sucesso. O sucesso é consequência. Albert Einstein

7 iv RESUMO Estudos revelam que os resultados dos projetos de software ainda estão muito aquém do esperado. Devido a isso, organizações produtoras de software bem sucedidas têm adotado uma abordagem mais completa em relação aos processos de desenvolvimento. Nos últimos anos, além de gerenciarem seus projetos, tais organizações estão investindo em um processo para capacitação individual e monitoramento rigoroso dos recursos humanos, denominado Personal Software Process PSP. Tal processo tem levado à maior disciplina e controle sobre todas as fases do desenvolvimento e, consequentemente, ao aumento da taxa de sucesso dos projetos. Neste contexto, este trabalho apresenta a integração das técnicas propostas no modelo PSP a um sistema web previamente desenvolvido, denominado Sistema de Apoio à Gerência de Projetos - SAGP. A avaliação dos resultados foi realizada por meio de uma análise comparativa da nova versão do SAGP em relação a outras ferramentas disponíveis no mercado. Além disso, o sistema foi avaliado por desenvolvedores de software, que constituem o seu públicoalvo. Os resultados obtidos permitem concluir que a integração realizada levou à obtenção de um sistema de qualidade capaz de facilitar o emprego do PSP e de gerar indicadores que auxiliam os gerentes de projetos em suas atividades. Palavras-chave: Maturidade de recursos humanos. Personal Software Process. Melhoria dos projetos de software.

8 v ABSTRACT Studies show that the results of software projects are still much less than expected. Due to this, successful software-producing organizations have adopted a more complete approach towards development processes. Nowadays, besides managing their projects, such organizations are investing in a process of individual qualification and strict monitoring of team members called Personal Software Process - PSP. This process has led to maintenance of greater discipline and control throughout all development phases and, consequently, to the increase in the rate of successful projects. In this context, this work presents the integration of the techniques proposed in the PSP model with a previously developed web-based system, which is called System to Aid Project Management - SAPM. The evaluation of the results was carried out through comparative analysis of the new version of SAGP in relation to other tools commercially available. Furthermore, the system was evaluated by software developers, who are their target audience. The results indicate that the proposed integration led to obtaining of a system of quality able to facilitate the use of the PSP and generate indicators that aid project managers in their activities. Keywords: Maturity of human resources. Personal Software Process. Improvement of software projects.

9 vi LISTA DE ILUSTRAÇÕES Figura 1.1 Processo metodológico Figura Arquitetura de software do SAGP (ESTECA, 2010) Figura Página inicial do SAGP Figura Portfólio de projetos Figura Página principal do SAGP Figura Página para vincular membros ao projeto Figura Fluxo do processo PSP (Adaptado de HUMPHREY, 1997) Figura Níveis do PSP (Adaptado de HUMPHREY, 1997) Figura Diagrama de casos de uso - Requisitos gerais Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama de casos de uso - Requisitos referentes ao PSP Figura Diagrama arquitetural do SAGP estendido a partir de ESTECA (2010) Figura Menu principal do SAGP com destaque para os itens relacionados ao PSP. 55 Figura Página inicial da Área exclusiva - Nível Figura Página para cadastro de programas Figura Página para gerenciamento de programas Figura Página para seleção de programas Figura Página para definição de atividades Figura 3.15 Diagrama de estados representando o funcionamento do Time Recording Log Figura 3.16 Telas associadas aos estados do Time Recording Log Figura 3.17 Defect Recording Log Figura 3.18 Diagrama de atividades referente ao envio de programas para teste Figura 3.19 Página de envio de programa para teste Figura 3.20 Página para recebimento de programa para teste Figura 3.21 Sumário do Plano de Projeto - PSP Figura Página inicial da Área exclusiva - Nível Figura Página de cadastro de propostas no Process Improvement Proposal Figura Página de cadastro de padrão de codificação Figura Página para registro e consulta do tamanho de programas Figura Página para definição de proxy Figura Página para registro de categorias funcionais Figura Página para registro de tamanho de proxies Figura Tabela de tamanho relativo gerada pelo sistema Figura Página para registro de tamanho de proxies Figura Resultado da avaliação do proxy Figura Página de registro de dados para estimativa de tamanho de programas... 71

10 Figura Size Estimating Template Figura Página de gerenciamento de atividades com campo para estimativa de tempo de cada atividade Figura Página para registro do tamanho real dos programas Figura Página para registro testes planejados/executados Figura 3.37 Página para estimativa do tempo de duração das atividades de um 75 programa Figura 3.38 Página para ordenação de programas Figura 3.39 Página para ordenação de atividades Figura 3.40 Schedule Planning Template Figura 3.41 Task Planning Template Figura 3.42 Página para cadastro do checklist de revisão de código Figura 3.43 Página para emprego do checklist de revisão de código Figura 3.44 Indicadores gerais de qualidade Figura 3.45 Evolução dos indicadores de qualidade Figura 3.46 Página para cadastro do modelo de especificação operacional Figura 3.47 Página para cadastro do modelo de especificação funcional Figura 3.48 Página para cadastro do modelo de especificação de estados Figura 3.49 Página para cadastro do modelo de especificação lógica Figura 3.50 Menu principal do SAGP com destaque para os itens relacionados aos indicadores do PSP Figura 3.51 Página para geração de indicadores por equipe Figura 3.52 Página para geração de rankings sobre os indicadores do PSP Figura 3.53 Página para seleção de atividades para geração de indicadores de tempo.. 89 Figura 3.54 Página para exibição dos indicadores de tempo Figura 4.1 Perfil dos participantes quanto ao tempo de experiência Gráfico 4.1 Avaliação da Compreensão dos elementos e práticas do PSP antes e depois da apresentação do SAGP Gráfico 4.2 Avaliação da Importância dos elementos e práticas do PSP antes e depois da apresentação do SAGP Gráfico 4.3 Avaliação do Grau de dificuldade dos elementos e práticas do PSP antes da apresentação da ferramenta Gráfico 4.4 Avaliação da Facilidade de uso dos elementos e práticas do PSP após a apresentação da ferramenta Gráfico 4.5 Avaliação da concordância quanto às assertivas antes e depois da apresentação da ferramenta Gráfico 4.6 Avaliação da Aderência ao PSP Gráfico 4.7 Avaliação da contribuição decorrente da integração do PSP ao ambiente de gerenciamento de projetos Gráfico 4.8 Avaliação dos aspectos de qualidade do sistema vii

11 viii LISTA DE TABELAS Tabela 2.1 Sumário do Plano de Projeto - PSP Tabela 2.2 Sumário do Plano de Projeto - PSP Tabela Tabela de tamanho relativo Tabela 2.4 Size Estimating Template Tabela 2.5 Critérios de seleção dos métodos para cálculo das estimativas pelo PROBE Tabela 2.6 Sumário do Plano de Projeto PSP Tabela 2.7 Sumário do Plano de Projeto PSP Tabela 2.8 Sumário do Plano de Projeto PSP Tabela 3.1 Descrição resumida dos casos de uso Requisitos gerais Tabela 3.2 Descrição resumida dos casos de uso Requisitos referentes ao PSP Tabela 3.3 Descrição resumida dos casos de uso Requisitos referentes ao PSP Tabela 3.4 Descrição resumida dos casos de uso Requisitos referentes ao PSP 1 (continua) Tabela 3.4 Descrição resumida dos casos de uso Requisitos referentes ao PSP 1 (conclusão) Tabela 3.5 Descrição resumida dos casos de uso Requisitos referentes ao PSP Tabela 3.6 Descrição resumida dos casos de uso Requisitos referentes ao PSP Tabela 3.7 Descrição resumida dos casos de uso Requisitos referentes ao PSP Tabela 4.1 Análise comparativa das ferramentas de apoio ao PSP Tabela A.1 - Cenário correspondente ao caso de uso "Registrar interesse em empregar o PSP na gestão de projetos" Tabela A.2 - Cenário correspondente ao caso de uso "Registrar nível do PSP a ser empregado em cada projeto" Tabela A.3 - Cenário alternativo correspondente ao caso de uso "Registrar nível do PSP a ser empregado em cada projeto" Tabela A.4 - Cenário correspondente ao caso de uso "Apresentar instruções do PSP" Tabela A.5 - Cenário correspondente ao caso de uso "Apresentar sumário de plano de projeto" Tabela A.6 - Cenário correspondente ao caso de uso "Registrar conclusão de projeto" Tabela A.7 - Cenário correspondente ao caso de uso "Gerar relatório" Tabela A.8 - Cenário correspondente ao caso de uso "Exibir indicadores de membros da equipe " Tabela A.9 - Cenário correspondente ao caso de uso "Cadastrar programas a serem construídos" Tabela A.10- Cenário correspondente ao caso de uso "Apresentar atividades a serem realizadas no projeto" Tabela A.11 - Cenário correspondente ao caso de uso "Cadastrar atividades pessoais" Tabela A.12 - Cenário correspondente ao caso de uso "Registrar estimativa de tempo das atividades"

12 Tabela A.13 - Cenário correspondente ao caso de uso "Disponibilizar o Time Recording Log" Tabela A.14 - Cenário correspondente ao caso de uso "Apresentar o Time Recording Log" Tabela A.15 - Cenário correspondente ao caso de uso "Disponibilizar o Defect Recording Log" Tabela A.16 - Cenário correspondente ao caso de uso "Enviar um programa para teste" 122 Tabela A.17 - Cenário correspondente ao caso de uso "Apresentar um programa para teste" Tabela A.18 - Cenário correspondente ao caso de uso "Registrar dados sobre os testes no programa" Tabela A.19 - Cenário correspondente ao caso de uso "Cadastrar padrão de codificação" Tabela A.20 - Cenário correspondente ao caso de uso "Registrar dados obtidos com as medições de software" Tabela A.21 - Cenário correspondente ao caso de uso "Cadastrar dados no Process Improvement Proposal" Tabela A.22 - Cenário correspondente ao caso de uso Cadastrar proxy" Tabela A.23 - Cenário correspondente ao caso de uso Cadastrar categorias funcionais de proxies Tabela A.24 - Cenário correspondente ao caso de uso Registrar tamanho dos proxies em programas já construídos Tabela A.25 - Cenário correspondente ao caso de uso Apresentar tabelas de tamanho relativo Tabela A.26 - Cenário correspondente ao caso de uso Apresentar avaliação do proxy definido Tabela A.27 - Cenário correspondente ao caso de uso Registrar dados no Size Estimating Template Tabela A.28 - Cenário correspondente ao caso de uso Apresentar estimativas pessoais Tabela A.29 - Cenário correspondente ao caso de uso Registrar tempo estimado para cada atividade seguindo instruções do PSP Tabela A.30 - Cenário correspondente ao caso de uso Cadastrar dados no Test Report Template Tabela A.31 - Cenário correspondente ao caso de uso Registrar tempo estimado para cada atividade seguindo as restrições do PSP Tabela A.32 - Cenário correspondente ao caso de uso Disponibilizar o Task Planning Template Tabela A.33 - Cenário correspondente ao caso de uso Apresentar o Schedule Planning Template Tabela A.34 - Cenário correspondente ao caso de uso Registrar conclusão de atividade Tabela A.35 - Cenário correspondente ao caso de uso Apresentar o CPI Tabela A.36 - Cenário correspondente ao caso de uso Cadastrar o checklist de revisão de código Tabela A.37 - Cenário correspondente ao caso de uso Registrar verificações no checklist de revisão de código Tabela A.38 - Cenário correspondente ao caso de uso Registrar verificações no checklist de revisão de projeto ix

13 Tabela A.39 - Cenário correspondente ao caso de uso Apresentar indicadores de qualidade Tabela A.40 - Cenário correspondente ao caso de uso Disponibilizar modelos de especificação de projeto Tabela A.41 - Cenário correspondente ao caso de uso Registrar verificações no checklist de revisão de projeto detalhado x

14 xi LISTA DE ABREVIATURAS AF/R: Appraisal to Failure Ratio CMM: Capability Maturity Model COQ: Cost of Quality CPI: Cost Performance Index DRL: Defect-Removal Leverage EV: Earned Value GEPES: Grupo de Estudos e Pesquisas em Engenharia de Software HTML: Hypertext Markup Language KLOC: 1000 Lines Of Code LOC: Lines Of Code LPI: Lower Prediction Interval MPS.BR: Melhoria de Processo do Software Brasileiro PDF: Portable Document Format PHP: acrônimo recursivo para PHP: Hypertext Preprocessor PIP: Process Improvement Proposal PMBoK: Project Management Body of Knowledge PQI: Process Quality Index PROBE: Proxy-Based Estimating PSP: Personal Software Process PV: Planned Value SAGP: Sistema de Apoio à Gerência de Projetos SEI: Software Engineering Institute TSP: Team Software Process UFPE: Universidade Federal de Pernambuco UML: Unified Modeling Language UNICAMP: Universidade Estadual de Campinas UPI: Upper Prediction Interval

15 xii SUMÁRIO Capítulo 1 - Introdução Considerações iniciais Motivação Objetivo Justificativa Metodologia Organização da dissertação Capítulo 2 Melhoria dos Projetos de Software Considerações iniciais Sistema de Apoio à Gerência de Projetos Personal Software Process Visão geral do PSP Estrutura do PSP Trabalhos relacionados Considerações finais Capítulo 3 Ferramenta de Apoio ao PSP Considerações iniciais Requisitos identificados Requisitos gerais Requisitos referentes ao PSP Requisitos referentes ao PSP Requisitos referentes ao PSP Requisitos referentes ao PSP Requisitos referentes ao PSP Requisitos referentes ao PSP Extensão da arquitetura de software do SAGP Funcionamento do componente de apoio ao PSP Integração do PSP ao SAGP Nível Nível Nível Nível Nível Nível Indicadores oriundos do emprego individual do PSP Considerações finais

16 Capítulo 4 Avaliação dos Resultados Considerações iniciais Análise comparativa de ferramentas de apoio ao PSP Visão dos usuários Considerações finais Capítulo 5 Considerações Finais Considerações iniciais Contribuições Trabalhos futuros Conclusões Referências bibliográficas Apêndice A Cenários de especificação dos casos de uso xiii

17 1 CAPÍTULO 1 Introdução 1.1 Considerações iniciais A atual concorrência entre organizações tem tornado cada vez mais necessária a obtenção de informações de maneira rápida e segura, para que decisões adequadas possam ser tomadas em tempo hábil, de modo a aumentar o potencial competitivo das empresas. Com isso, os processos organizacionais tornam-se dependentes de sistemas de informação, o que eleva a demanda por software de qualidade (SILVA, 2006). Segundo Pressman (2009), qualidade de software consiste na conformidade com requisitos funcionais e não-funcionais explicitamente declarados, normas de desenvolvimento documentadas e características implícitas esperadas em todo o software desenvolvido profissionalmente. A qualidade de software pode ser analisada sob duas diferentes perspectivas: a qualidade do produto de software e a qualidade do processo de desenvolvimento e manutenção de software (SOMMERVILLE, 2011). A qualidade do produto de software resulta das atividades realizadas durante seu desenvolvimento, sendo mensurada pela verificação do atendimento ou não dos requisitos identificados, o que é feito por meio de técnicas e atividades operacionais (SILVA, 2006). A qualidade do processo de desenvolvimento e manutenção de software tem assumido um papel tão importante quanto a qualidade dos produtos entregues aos clientes, uma vez que um processo de qualidade auxilia na obtenção de um produto de qualidade, além de permitir a repetição de bons resultados (ROCHA; MALDONADO; WEBER, 2001). Diante da relevância da qualidade do processo, surgiram modelos de maturidade, como o CMM (Capability Maturity Model) (Software Engineering Institute - SEI, 1993) e o MPS.BR

18 2 (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2003), que guiam e possibilitam a certificação das organizações em relação ao processo de desenvolvimento (NOGUEIRA, 2006). 1.2 Motivação Para o desenvolvimento de software de qualidade, é necessário incorporar um conjunto de boas práticas ao processo de desenvolvimento, dentre as quais está a gerência dos projetos, que consiste na aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do projeto, a fim de atender aos requisitos, bem como satisfazer às necessidades e expectativas dos interessados (stakeholders) no projeto (PMI, 2008; PRESSMAN, 2009; SOMMERVILLE, 2011). Apesar das técnicas de gerenciamento estarem em constante aperfeiçoamento, os resultados obtidos nos projetos de desenvolvimento de software ainda estão muito aquém do esperado, conforme revela o estudo CHAOS (STANDISH GROUP, 2011), segundo o qual 42% dos projetos concluídos apresentam alterações em relação às estimativas iniciais, 21% são abortados e apenas 37% são concluídos com sucesso. De acordo com o Standish Group, um projeto é bem sucedido se é concluído dentro do prazo e orçamento previstos e atende às funções inicialmente solicitadas, bem como às eventualmente incorporadas aos requisitos no decorrer do projeto (EVELEENS; VERHOEF, 2010). Dentre as razões apontadas pelo estudo CHAOS para o baixo índice de sucesso dos projetos de software destacam-se a falta de comprometimento dos recursos humanos envolvidos e a definição de metas irreais baseadas em expectativas acima da realidade (JIRACHIEFPATTANA, 2012), o que pode ser atribuído à falta de indicadores sólidos sobre os membros de equipe. Com o intuito de obterem melhores resultados em seus projetos, organizações produtoras de software bem sucedidas têm adotado uma abordagem mais completa em relação aos processos de desenvolvimento (SILVA, 2006). Nos últimos anos, além de gerenciarem seus projetos, tais organizações estão investindo em um robusto processo para capacitação individual e monitoramento rigoroso dos membros da equipe denominado Personal Software Process - PSP, o qual tem levado à manutenção de maior disciplina e controle em todas as fases do desenvolvimento e, conseqüentemente, ao significativo aumento da taxa de sucesso dos projetos (HUMPHREY, 2005).

19 3 1.3 Objetivo Este trabalho teve o objetivo de incorporar um componente de apoio ao emprego do PSP a um sistema web de apoio à gerência de projetos previamente desenvolvido pelo Grupo de Estudos e Pesquisas em Engenharia de Software GEPES. Tal sistema, denominado Sistema de Apoio à Gerência de Projetos - SAGP (ESTECA, 2010; SOUZA et al., 2011), tem como intuito principal apoiar a execução de atividades gerenciais segundo as práticas propostas por um dos mais conceituados guias para o gerenciamento de projetos, o Project Management Body of Knowledge (PMBoK) (PMI, 2008). Para tanto, o SAGP fornece um ambiente onde os gerentes de projeto de qualquer segmento de atuação podem cadastrar seus projetos e vincular membros de equipe a eles. Deste modo, tanto o gerente de projetos como os demais membros de equipe podem acessar cada projeto para usar as funções disponíveis, que apoiam a efetivação de um gerenciamento adequado (SOUZA et al., 2011). Neste contexto, as novas funções incorporadas ao SAGP automatizam a aplicação dos mecanismos propostos pelo PSP, permitindo que todos os usuários do SAGP possam empregá-lo durante a execução das atividades dos projetos de software aos quais estão vinculados, fazendo com que a melhoria pessoal proporcionada pelo PSP contribua para o sucesso dos projetos realizados. Finalmente, cabe ressaltar que, em razão da abrangência e complexidade do PSP, também foi objetivo deste trabalho oferecer elementos para apoiar os usuários do SAGP no entendimento do PSP, motivando o uso efetivo de seus mecanismos durante a execução dos projetos. 1.4 Justificativa A integração de funções relacionadas ao PSP a um ambiente de apoio à gerência de projetos pode acarretar uma série de benefícios, tanto em âmbito pessoal como em âmbito organizacional. Em âmbito pessoal, um dos principais benefícios é a automatização de todos os complexos cálculos propostos pelo PSP, que normalmente representam uma barreira ao emprego do processo (ABBAS; AFZAL; AHMED, 2012). Além disso, a integração ao ambiente de gerenciamento de projetos é um importante diferencial da proposta, uma vez que permite ao sistema apontar automaticamente o papel de cada membro de equipe nos projetos, bem como as atividades e períodos em que estão alocados, o que facilita sobremaneira a

20 4 definição e o gerenciamento do trabalho pessoal a ser desenvolvido pelos membros de equipe. Outro benefício importante do componente proposto é a disponibilização de elementos de apoio ao aprendizado do PSP, o que é algo especialmente importante no Brasil e em países onde são raros os cursos para ensino do assunto. Como resultado de todos esses benefícios, constata-se que o componente proposto pode levar à melhoria da maturidade dos recursos humanos, uma vez que facilita a adoção do PSP (HUMPHREY, 2005). Em âmbito organizacional, um dos principais benefícios é o aumento da taxa de sucesso dos projetos, uma vez que o PSP leva a um maior comprometimento dos membros de equipe (HUMPHREY, 2005). Além disso, há um aumento da produtividade dos recursos humanos, bem como uma melhoria na qualidade dos produtos de software resultantes (WOHLIN, 1998). Outro benefício relevante é a disponibilização de mais informações de apoio às tomadas de decisão dos gerentes de projetos, as quais podem ser geradas a partir do processamento dos dados coletados sobre cada membro de equipe que emprega o PSP individualmente. Tais informações podem ser úteis para direcionar decisões cujo impacto pode afetar qualquer uma das nove áreas de conhecimento em gerenciamento de projetos, a saber: Integração, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicação, Riscos e Aquisições (PMI, 2008). Além de apoiar as tomadas de decisão, tais informações podem servir ainda como base para a aplicação de políticas para bonificação de recursos humanos, uma vez que representam um meio para a avaliação dos recursos quanto a diversos aspectos (HUMPHREY, 2005; JOHNSON et al., 2003). Outro ponto que torna ainda mais relevante a proposta é a falta de sistemas de apoio ao PSP mais completos. Além disso, durante o levantamento bibliográfico realizado neste trabalho, não foram encontrados sistemas que integrem a aplicação do PSP ao contexto de gerenciamento de projetos. Diante do exposto, é possível constatar que os benefícios observados podem contribuir fortemente para a melhoria do panorama atual dos projetos de software. Deste modo, considera-se relevante incorporar ao SAGP o componente de apoio ao emprego do PSP. 1.5 Metodologia A metodologia adotada para a realização deste trabalho dividiu-se em cinco principais etapas: 1. Revisão bibliográfica: seleção e estudo de artigos relacionados ao tema e publicados em periódicos e congressos científicos, os quais foram coletados em base de dados como o

21 5 portal de periódicos da CAPES, a SciELO, a ACM Digital Library, bem como nos anais de congressos. Além disso, foram considerados livros, teses e dissertações relacionados ao tema. A partir da revisão bibliográfica realizada, foram identificados os requisitos a serem incorporados ao SAGP de modo a fornecer um apoio adequado para o emprego do PSP pelos membros das equipes de projetos, bem como informações importantes que possam auxiliar os gerentes de projetos em suas tomadas de decisões; 3. Extensão da arquitetura de software do SAGP: a partir dos requisitos definidos, foram identificados os módulos a serem incorporados na versão atual da arquitetura de software do SAGP, de modo a contemplar as novas funções; 4. Implementação e integração de novas funções ao SAGP: os módulos arquiteturais identificados foram implementados e integrados ao ambiente do SAGP utilizando os seguintes recursos computacionais gratuitos: linguagens PHP (acrônimo recursivo para "PHP: Hypertext Preprocessor"), JavaScript e HTML (HyperText Markup Language); gerenciador de banco de dados MySQL; servidor web Apache; 5. Avaliação da proposta: a avaliação da contribuição deste trabalho foi realizada em duas etapas. Inicialmente, foi executada uma análise comparativa entre o sistema proposto e algumas ferramentas de apoio ao PSP disponíveis no mercado. Posteriormente, o sistema foi avaliado também por um grupo de 22 usuários com diferentes níveis de experiência em desenvolvimento de software, o que permitiu identificar a abrangência do sistema desenvolvido e o quanto ele auxilia no aprendizado de conceitos relacionados ao PSP. O fluxo entre tais etapas e os artefatos gerados por elas estão ilustrados na Figura 1.1. Figura Processo metodológico

22 6 1.6 Organização da dissertação O restante dessa dissertação está organizado da seguinte forma: Capítulo 2 - Melhoria dos Projetos de Software: neste capítulo é apresentado o SAGP, fornecendo uma visão geral de sua arquitetura, bem como um estudo detalhado sobre o tema central deste trabalho, o PSP, abordando desde conceitos básicos até os detalhes envolvidos em sua estruturação; Capítulo 3 Ferramenta de Apoio ao PSP: neste capítulo são apresentados os requisitos funcionais definidos para o sistema em desenvolvimento, bem como a extensão da arquitetura de software original do SAGP; Capítulo 4 Avaliação dos Resultados: neste capítulo é apresentada a avaliação da contribuição deste trabalho, descrevendo uma análise comparativa de sistemas de apoio ao PSP, bem como um estudo sobre a visão dos usuários do sistema desenvolvido; Capítulo 5 Considerações Finais: neste capítulo são discutidas as principais contribuições deste trabalho e são propostos alguns trabalhos futuros.

23 7 CAPÍTULO 2 Melhoria dos Projetos de Software 2.1 Considerações iniciais O objetivo deste capítulo é apresentar a arquitetura original do SAGP e uma visão geral sobre seu funcionamento, bem como a estrutura do PSP, de maneira a permitir a compreensão do contexto no qual este trabalho está inserido. Além disso, também são apresentados trabalhos relacionados à melhoria da maturidade pessoal no contexto de desenvolvimento de software, fornecendo uma visão geral sobre o estado da arte. Na seção 2.2, é apresentada uma breve descrição sobre o funcionamento do SAGP, destacando sua arquitetura. Na seção 2.3 é apresentada uma visão geral sobre o PSP, bem como sua estrutura básica, descrevendo cada um dos seus níveis. Na seção 2.4 são apresentados trabalhos relacionados à melhoria da maturidade pessoal. Por fim, na seção 2.5, são apresentadas as considerações finais deste capítulo. 2.2 Sistema de Apoio à Gerência de Projetos O SAGP foi construído com o intuito de apoiar a execução das boas práticas de gerência de projetos descritas no guia PMBoK. Com isso, a arquitetura de software estabelecida, ilustrada na Figura 2.1, visou contemplar os requisitos necessários para apoiar as atividades gerenciais propostas no guia PMBoK.

24 8 Figura Arquitetura de software do SAGP Fonte: ESTECA (2010). Conforme apresentado na Figura 2.1, a arquitetura do SAGP é constituída por dois componentes, a saber: Controle de acesso: constituído por módulos que se comunicam para fornecer as funções relacionadas ao controle de acesso ao SAGP, o que envolve o cadastro de novos usuários, a autenticação no sistema, o cadastro de novos projetos e o controle do nível de acesso de cada usuário aos projetos cadastrados; Gestão de projetos: constituído por módulos que se comunicam para fornecer as funções relacionadas ao gerenciamento de projetos propriamente dito, o que envolve o apoio ao emprego das práticas referentes às nove áreas de conhecimento propostas no guia PMBoK. A descrição detalhada dos módulos desses componentes está disponível em ESTECA (2010). Com o intuito de exemplificar o funcionamento do SAGP, proporcionado pela implementação dos respectivos módulos, cabe observar que para uma instituição ter acesso ao SAGP é necessário que um de seus membros seja cadastrado pelo administrador do sistema. Em seguida, este membro pode acessar o sistema autenticando-se pela página ilustrada na Figura 2.2. Após a autenticação, esse usuário pode cadastrar um projeto ou acessar um projeto

25 9 cadastrado ao qual tenha acesso, selecionando-o no portfólio de projetos, ilustrado na Figura 2.3. Ao acessar um projeto, é exibida a página principal do sistema, apresentada na Figura 2.4, a qual dá acesso ao menu principal, que categoriza as funções oferecidas pelo SAGP de acordo com as nove áreas de conhecimento definidas no guia PMBoK. Figura Página inicial do SAGP Figura Portfólio de projetos

26 10 Figura Página principal do SAGP Observa-se que o usuário criador de um projeto pode permitir que tal projeto seja acessado por outros usuários. Para tanto, por meio da página ilustrada na Figura 2.5, o criador do projeto pode vincular outros membros já cadastrados, bem como cadastrar novos membros. Ao vincular um usuário a um projeto, é possível atribuir a ele um dos três níveis de acesso: Nível 3: permite acesso a todos os recursos e informações cadastradas no sistema. Esse é o nível de acesso dos criadores dos projetos, que, por padrão, são definidos como gerentes do projeto. Usuários com esse nível de acesso podem cadastrar novos usuários, bem como vincular usuários aos projetos. Observa-se que um usuário de nível 3 em um projeto pode não ter acesso a algum outro projeto, uma vez que o nível de acesso varia por projeto; Nível 2: permite todos os privilégios dos usuários de nível 3, exceto a possibilidade de consultar informações financeiras dos projetos; Nível 1: permite acesso apenas a informações referentes às atividades do projeto.

27 11 Figura Página para vincular membros a um projeto Além das funções referentes às áreas de conhecimento em gerenciamento de projetos, o SAGP permite a geração de relatórios em formato PDF, o que facilita a análise, acompanhamento e distribuição das informações. 2.3 Personal Software Process O objetivo desta seção é apresentar detalhadamente o PSP. Para tanto, na seção 2.3.1, é apresentada uma visão geral do processo, descrevendo suas principais metas e elementos, bem como os benefícios oriundos de sua aplicação. Na seção 2.3.2, é apresentada a estrutura do PSP, descrevendo os mecanismos propostos em cada um de seus níveis Visão geral do PSP A criação do PSP foi iniciada em 1989 por Watts Humphrey no SEI (HUMPHREY, 1989). A estrutura do PSP foi baseada no CMM, do qual foram selecionadas e adaptadas para

28 12 o nível individual 12 das 18 áreas chave de processo, não sendo abordadas apenas as que não são aplicáveis em nível individual (REINEHR, 2001). De modo geral, o PSP pode ser definido como um processo de auto-melhoria projetado para ajudar o desenvolvedor de software a controlar, administrar e melhorar o modo como trabalha (HUMPHREY, 2005). Em termos específicos, as metas do PSP são (BALBINO, 2004; OVER, AKIYAMA, 2009): fornecer subsídios para estimativas bastante precisas do tempo de esforço individual necessário para o desenvolvimento de software; direcionar o trabalho da equipe de desenvolvimento de acordo com um processo bem definido; definir e refinar o processo de desenvolvimento; auxiliar na identificação e solução das deficiências do processo de desenvolvimento; utilizar revisões eficientemente para melhorar a qualidade do software; promover a diminuição de erros durante o desenvolvimento através da análise de dados coletados. Para atingir todas estas metas, o PSP é um processo bem definido que se divide em três fases (POMEROY-HUFF et al., 2009): Planejamento: nesta fase é produzido um plano para direcionar o desenvolvimento do trabalho; Desenvolvimento: nesta fase, com base no plano desenvolvido, é realizado o trabalho propriamente dito, o qual engloba os passos de definição de requisitos, projeto do software, revisão e correção de defeitos do projeto, codificação do software, revisão e correção de defeitos do código, compilação e correção de defeitos, teste do software e correção de defeitos; Autópsia: nesta fase são estabelecidos comparativos entre os dados planejados e os reais. Além disso, são registradas propostas para melhoria do processo. Durante todas as fases do PSP devem ser empregados quatro elementos básicos (POMEROY-HUFF et al., 2009): Scripts: são descrições em alto-nível que guiam os usuários na execução de um processo. Os scripts documentam o objetivo do processo, critérios de entrada,

29 13 diretrizes gerais, passos a serem executados, medições e critérios de qualidade do processo e suas condições de saída; Formulários: constituem uma forma consistente de coletar dados necessários para execução dos processos. Existem ainda formulários especializados, denominados checklists, que guiam os usuários na execução de algumas revisões propostas pelo PSP; Medições: quantificam o processo e o produto e habilitam os usuários a desenvolverem perfis de dados com base em projetos anteriores, os quais podem ser usados para planejamentos e melhorias de processo. Além disso, as medições possibilitam monitorar a produtividade pessoal; Padrões: oferecem definições precisas e consistentes que guiam o trabalho e a coleta e uso dos dados, tornando possível aplicar medições uniformemente em vários projetos para obtenção de dados que reflitam corretamente a realidade. O fluxo destes elementos ao longo das fases do PSP é ilustrado na Figura 2.1. Figura Fluxo do processo PSP Fonte: Adaptado de HUMPHREY (1997). Estudos empíricos revelam que, através de sua estrutura robusta e bem definida, o PSP oferece diversos benefícios pessoais e/ou organizacionais, a saber (FERGUSON et al., 1997;

30 14 HUMPHREY 2005; JOHNSON et al., 2003; RAMINGWONG; RAMINGWONG, 2012; WOHLIN, 1998): aumento da produtividade; diminuição da taxa de produção de defeitos; melhoria da qualidade dos produtos de software; estimativas de custo e cronograma cada vez mais próximas da realidade; diminuição do tempo de realização de testes nos produtos de software e consequente redução do tempo total de desenvolvimento; aperfeiçoamento do processo de desenvolvimento de software; atendimento, pelo menos parcial, de 12 das 18 áreas chave de processo do CMM; aumento da chance de sucesso nos projetos como um todo devido ao cumprimento adequado das metas estabelecidas em nível individual. Diante de todos estes benefícios, o interesse pela implantação do PSP tem aumentado significativamente nos últimos anos (RAMINGWONG; RAMINGWONG, 2012; SHEN; YONG-JI; LI, 2009). Atualmente, a maneira mais comum de se obter os conhecimentos necessários para o emprego do PSP é através de cursos com duração entre 100 e 150 horas ao longo dos quais são executados exercícios e produzidos relatórios que permitem fixar conceitos importantes e exercitá-los na prática. Além disso, em algumas universidades, como a Universidade Estadual de Campinas - UNICAMP e a Universidade Federal de Pernambuco - UFPE, o PSP vem sendo abordado em disciplinas de cursos de graduação e pós-graduação da área de Ciência da Computação. Apesar dos cursos habilitarem os desenvolvedores de software a empregarem o PSP, sua incorporação dentro das organizações deve ser feita de maneira gradativa, uma vez que, primeiramente, é necessário implantar mecanismos que apoiem o autoconhecimento dos membros de equipe de desenvolvimento para que, posteriormente, com base nesse conhecimento adquirido, possam ser implantados adequadamente os mecanismos que proporcionarão os benefícios práticos do PSP Estrutura do PSP O PSP é estruturado em 7 níveis, conforme ilustrado na Figura 2.7, sendo que a cada nível são incorporados novos elementos de apoio a auto-melhoria contínua dos

31 15 desenvolvedores de software. A seguir são apresentados cada um destes níveis, exceto o último, correspondente ao Team Software Process (TSP), que não é o objeto de interesse deste trabalho, uma vez que representa uma expansão do PSP para ser utilizada por equipes, não por indivíduos. Figura Níveis do PSP Fonte: Adaptado de HUMPHREY (2005). Nível 0 Os níveis 0 e 0.1, também denominados PSP 0 e 0.1, pertencem ao grupo de processos que constituem a base do PSP, introduzindo medições e relatórios padronizados. Os objetivos do nível 0 do PSP são (HUMPHREY, 2005): usar o processo atual como um processo introdutório; incorporar medidas básicas no processo de desenvolvimento de software; requerer mudanças mínimas nas práticas pessoais.

32 16 No PSP 0, os desenvolvedores de software são estimulados a incluir pequenas modificações em seu processo de desenvolvimento. A primeira delas consiste em categorizar as atividades de acordo com a sequência de passos das fases pré-definidas no PSP, ou seja, planejamento, desenvolvimento e autópsia. Para cada uma destas fases, como todos os níveis do PSP, o PSP 0 fornece um script para guiar os desenvolvedores ao longo do processo. A fase de planejamento do PSP 0 é bastante simples, resumindo-se à estimativa de tempo (em minutos) que o desenvolvedor espera levar para a construção total do produto de software. Já na fase de desenvolvimento do PSP são introduzidos dois formulários: o Time Recording Log e o Defect Recording Log (HUMPHREY, 2005; REINEHR, 2001; SILVA JÚNIOR, 2000). O Time Recording Log tem a função de registrar o tempo gasto pelos desenvolvedores em cada uma das atividades. Para tanto, o desenvolvedor deve registrar o momento em que iniciou a execução de uma atividade e, para cada interrupção que ocorrer, deve registrar sua duração e motivo. Por fim, o desenvolvedor deve registrar o momento em que parou de executar a atividade, mesmo que ela ainda não tenha sido concluída. Este formulário pode ser considerado um dos principais mecanismos de apoio ao autoconhecimento dos desenvolvedores de software, pois, por meio dele, é possível conhecer onde é gasto o tempo e como isso muda à medida que o processo evolui. O Defect Recording Log tem a função de registrar dados sobre os defeitos encontrados e o tempo para consertar cada um deles. Para tanto, sempre que um defeito é encontrado, o desenvolvedor deve registrar os seguintes dados: data em que o defeito foi encontrado; identificador exclusivo do defeito, que normalmente é um número; o tipo do defeito, que pode ser selecionado a partir um conjunto padrão de dez defeitos sugerido pelo PSP; o passo da fase de desenvolvimento em que defeito foi injetado; o passo da fase de desenvolvimento ou autópsia em que defeito foi removido; tempo gasto para correção do defeito. Além destes dados, caso um defeito Y seja gerado durante a correção de um defeito X, deve-se registrar que Y refere-se à correção de X. A partir dos dados constantes neste formulário, os desenvolvedores passam a ter parâmetros para o estabelecimento de metas de diminuição da produção de defeitos. Na fase de autópsia, os dados coletados através do Time Recording Log e do Defect Recording Log são descritos no Sumário do Plano de Projeto do PSP 0, exemplificado na Tabela 2.1, o qual é exclusivo para cada programa desenvolvido.

33 17 Tabela 2.1 Sumário do Plano de Projeto - PSP 0 Desenvolvedor José da Silva Data 10/01/2009 Projeto Fórmulas de estatística Programa 2 Linguagem C Tempo em fase (minutos) Planejado Real To Date To Date % Planejamento 5 8 5,7 Projeto ,1 Codificação ,5 Compilação ,8 Teste ,1 Autópsia ,8 Total Defeitos injetados Planejado Real To Date To Date % Planejamento Projeto ,2 Codificação ,8 Compilação Teste Total Defeitos removidos Planejado Real To Date To Date % Planejamento Projeto Codificação ,5 Compilação ,5 Teste Total Pós-desenvolvimento 0 0 O formulário apresentado na Tabela 2.1 permite obter, de maneira clara e eficiente, as seguintes informações: diferença entre o tempo estimado e o tempo realmente utilizado para desenvolver o produto de software, que é dado pelo somatório do tempo gasto em cada atividade do projeto; tempo gasto em cada um dos passos das fases do PSP, que é dado pelo somatório do tempo gasto pelas atividades executadas em cada passo; número de defeitos injetados e removidos em cada passo das fases do PSP, uma vez que isto é registrado no Defect Recording Log;

34 18 atributo To Date que registra os valores acumulados em todos os programas construídos usando o PSP. Por exemplo: o atributo Real refere-se ao tempo gasto num dado programa na fase de planejamento, enquanto que o atributo To Date refere-se ao tempo gasto em todos os programas durante a fase de planejamento; atributo To Date % que mostra a distribuição percentual dos dados do atributo To Date entre as fases do PSP, revelando aquelas em que a construção de seus programas mais consome tempo ou gera defeitos, o que permite aos desenvolvedores elaborar futuras estimativas com maior precisão. Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 0 são: quatro scripts: um para guiar os desenvolvedores na utilização do PSP 0 e os outros três para guiá-los em cada fase do PSP; três formulários: Sumário do Plano de Projeto, Time Recording Log e Defect Recording Log; medições de tempo e defeitos produzidos; padrão de tipo de defeitos. Nível 0.1 O PSP 0.1 tem como foco de atuação a fase de autópsia do PSP, de modo que não são incorporadas mudanças às fases de planejamento e desenvolvimento. Além de manter os objetivos do PSP 0, o PSP 0.1 tem como objetivos específicos (SILVA JÚNIOR, 2000): estimular a criação de um padrão de codificação; estimular e auxiliar o processo de medição do tamanho dos programas produzidos; estimular a melhoria do processo empregado para o desenvolvimento de software. O estímulo ao processo de medição tem como intuito criar um histórico com o tamanho dos programas construídos, que servirá de base para estimar o tamanho de programas durante a elaboração de planejamentos de projetos futuros. O processo de medição proposto pelo PSP 0.1 expressa o tamanho dos programas por meio do número de linhas de código (LOCs, do inglês lines of code) e opera sistematicamente para alcançar resultados consistentes e repetíveis. Neste processo, o primeiro passo a ser executado é a adoção de um padrão de codificação que deve ser seguido em todos os

35 19 programas que forem construídos em uma mesma linguagem, para que todas as medições em LOCs sejam proporcionais à quantidade de trabalho realizado. Como o padrão de codificação é dependente da linguagem que está sendo utilizada, existem padrões propostos para Java (ALBUQUERQUE; MEIRA, 1997), C++ (HUMPHREY, 1995), PHP (MARTINS; OLIVEIRA, 2009) e outras linguagens. Após adotar um padrão de codificação, o próximo passo do PSP 0.1 é a contagem e classificação das linhas produzidas entre as seguintes categorias (HUMPHREY, 2005): base (B): refere-se às linhas que já estavam codificadas no início da construção do programa; adicionadas (A): refere-se às linhas que foram criadas durante a construção do programa; modificadas (M): refere-se às linhas do código base que foram alteradas; deletadas (D): refere-se às linhas do código base que foram excluídas e não utilizadas no programa construído; reutilizadas (R): refere-se às linhas de código que foram copiadas e utilizadas sem nenhuma alteração. Se houver qualquer alteração, todas as linhas utilizadas devem ser contadas como código base (B) e as alteradas devem ser contadas como modificadas (M); adicionadas e modificadas (A&M): esta categoria pode ser empregada quando o tempo de criação ou alteração de uma linha de código é aproximadamente o mesmo. Salienta-se que toda linha A&M deve ser classificada também como A ou M para que seja possível calcular corretamente o tamanho total do programa; novas reutilizáveis (NR): refere-se às linhas criadas com intenção de reutilização futura ou às linhas do código base que foram modificadas para torná-lo reutilizável. Salienta-se que toda linha NR deve ser classificada também como A ou M para que seja possível calcular corretamente o tamanho total do programa. Deste modo, tem-se a classificação adequada das linhas do código-fonte, bem como o total (T) de linhas do programa construído, que deve ser calculado da seguinte forma: T = B + A + R D (2.1) Embora este processo de contagem de tamanho pareça desnecessariamente complexo, ele permite a obtenção de informações que serão necessárias para a realização de cálculos

36 20 estatísticos essenciais para a elaboração de estimativas de tamanho de software, que, por sua vez, serão utilizadas em níveis posteriores do PSP para a criação de planos bastante precisos. Para reduzir a complexidade do processo de contagem de tamanho, é recomendável a utilização de programas específicos para este fim. Já para o registro das linhas deletadas e modificadas, uma abordagem que pode ser empregada consiste em marcar tais linhas com um comentário especial reconhecido e contabilizado por um contador específico. Com os dados obtidos a partir da medição do tamanho dos programas, podem-se realizar cálculos para a determinação de parâmetros capazes de indicar a qualidade do programa e a produtividade do desenvolvedor. Como indicativo de qualidade do programa, pode-se utilizar o número de defeitos para cada 1000 LOCs ou 1 KLOC produzido. Já a produtividade do desenvolvedor pode ser indicada de diferentes maneiras, por exemplo: se for considerada a produtividade para criar linhas de código, calcula-se o número de linhas adicionadas (A) dividido pelo tempo de codificação (em horas); se for considerada a produtividade para adicionar ou modificar linhas de código, calcula-se o A&M dividido pelo tempo de codificação (em horas). Além do processo de medição do tamanho dos programas, o PSP 0.1 propõe o uso de um formulário denominado Process Improvement Proposal (PIP) para o registro de sugestões de melhoria do processo de software utilizado, onde os principais dados a serem registrados são: descrição do problema/situação atual; proposta de solução/mudança; comentários adicionais. O formulário PIP pode ser utilizado em qualquer fase do PSP. Na fase de autópsia, todas as medições devem ser registradas no Sumário do Plano de Projeto do PSP 0.1, exemplificado na Tabela 2.2, o qual acrescenta as seguintes informações em relação ao PSP 0: quantidade de LOCs pertencentes a cada categoria; quantidade total de LOCs criadas ou modificadas em programas construídos; quantidade total de LOCs dos programas construídos; quantidade total de LOCs reutilizadas nos programas construídos; quantidade total de LOCs reutilizáveis criadas nos programas construídos.

37 21 Tabela 2.2 Sumário do Plano de Projeto - PSP 0.1 Desenvolvedor José da Silva Data 14/01/2009 Projeto Fórmulas de estatística Programa 4 Linguagem C Tamanho do programa (LOC) Planejado Real To Date Base (B) 20 Adicionadas (A) 50 Modificadas (M) 10 Deletadas (D) 5 Reutilizadas (R) 8 28 A&M Total (T) Novas reutilizáveis (NR) campos do Sumário do Plano de Projeto do PSP 0 Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 0.1 são: quatro scripts: um para guiar os desenvolvedores na utilização do PSP 0.1 e os outros três para guiá-los em cada fase do PSP; dois formulários: Sumário do Plano de Projeto, Process Improvement Proposal (PIP); medição do tamanho dos programas construídos; padrão de codificação. Nível 1 Os níveis 1 e 1.1 do PSP, denominados PSP 1 e 1.1, têm como foco de atuação as fases de planejamento e desenvolvimento do PSP e pertencem ao grupo de processos de planejamento. Além de manter os objetivos do PSP 0.1, o PSP 1 tem como objetivos específicos (HUMPHREY, 2005): estabelecer um método ordenado e repetível para estimar o tamanho e tempo total de desenvolvimento de um software; estimular o registro de uma maior quantidade de informações sobre os testes realizados em programas.

38 22 O método de estimativa de tamanho de software estabelecido no PSP 1 é denominado Proxy-Based Estimating (PROBE) e pode ser considerado o elemento central do PSP, tendo sido criado especialmente para ser utilizado durante sua fase de planejamento. O PROBE foi baseado em princípios e técnicas conhecidos, como lógica Fuzzy, método do componente padrão, análise por pontos de função e técnicas estatísticas (REINEHR, 2001). O nome do método deve-se ao fato de que todo seu funcionamento baseia-se em um proxy, que nada mais é que uma unidade capaz de representar o esforço demandado para o desenvolvimento de um programa. No contexto de desenvolvimento de software, exemplos de proxies são classes, tabelas de banco de dados, janelas de interface, etc. Observa-se que para cada linguagem de programação empregada deve ser definido um proxy apropriado. Antes de se aplicar o método PROBE, é necessário criar uma tabela de tamanho relativo, que busca definir o número médio de LOCs de proxies para cinco categorias de tamanho relativo: muito pequena, pequena, média, grande e muito grande. Para tanto, é necessário que inicialmente sejam estabelecidas as categorias funcionais do proxy definido, pois o tamanho relativo de um proxy varia de acordo com a sua função. No caso em que se emprega classe como proxy, exemplos de suas possíveis funções são execução de cálculos, realização de operações de entrada/saída, etc. Em geral, não são necessárias mais que seis categorias para descrever todas as possíveis funções que um proxy pode exercer (HUMPHREY, 2005). Após a definição das categorias funcionais, deve-se registrar dados históricos sobre o tamanho e tempo de desenvolvimento do proxy para cada tipo de função que ele pode exercer. Tais dados devem então ser submetidos a uma análise da correlação matemática, a qual deve ser maior que 0,7 para comprovar que o proxy definido realmente é capaz de indicar o esforço demandado para o desenvolvimento dos programas, uma vez que há proporcionalidade entre o tamanho e o tempo de desenvolvimento. Caso o valor da correlação seja superior a 0,7, deve-se ainda calcular a significância dos dados para constatar se a quantidade de dados históricos é suficiente ou se devem ser registrados mais dados. Se o valor da correlação for inferior a 0,7 e a significância for adequada, é necessário alterar o proxy ou remover dados históricos considerados outliers. Após a coleta de dados históricos e comprovação da adequação do proxy, finalmente deve-se realizar cálculos que apontem o tamanho médio do proxy para cada categoria funcional. Na Tabela 2.3 é apresentado um exemplo de tabela de tamanho relativo usando classe como proxy para programas desenvolvidos em C++. O detalhamento de todos os cálculos pode ser encontrado em HUMPHREY (2005).

39 23 Tabela Tabela de tamanho relativo Tamanho de classe em LOCs - Linguagem C++ Categoria Muito pequena Pequena Média Grande Muito grande Cálculo 2,34 5,13 11,25 24,66 54,04 Dados 2,60 4,79 8,84 16,31 30,09 Entrada/Saída 9,01 12,06 16,15 21,62 28,93 Lógica 7,55 10,98 15,98 23,25 33,83 Configuração 3,88 5,04 6,56 8,53 11,09 Texto 3,75 8,00 17,07 36,41 77,66 Fonte: Extraído de HUMPHREY (2005). Com a tabela de tamanho relativo já estabelecida, o PROBE pode ser aplicado empregando-se os seguintes passos (HUMPHREY, 2005): Passo 1. elaboração de um projeto conceitual do programa a ser construído, cujas partes devem ser definidas em termos do proxy; Passo 2. estimativa inicial do tamanho do programa a ser desenvolvido, a qual é feita analisando-se a função e o tamanho relativo esperado para cada parte do projeto conceitual; Passo 3. categorização das LOCs que comporão as partes do programa. Para apoiar a execução deste trabalho, o PSP 1 oferece um formulário denominado Size Estimating Template, ilustrado na Tabela 2.4. Neste formulário, devem ser estimadas as partes base, as partes adicionadas e as partes reutilizadas do programa a ser construído. As partes base são aquelas sobre as quais será iniciada a construção do programa. As partes adicionadas referemse ao código que deverá ser criado e que deve ser estimado em termos de proxies. Já as partes reutilizadas são aquelas que serão inteiramente extraídas da biblioteca de reuso, sem alterações. Observa-se que, ao término da construção do programa, deve-se registrar no mesmo formulário os dados reais sobre as partes do programa.

40 24 Tabela 2.4 Size Estimating Template Fonte: Adaptado de HUMPHREY (2005). Após o preenchimento das estimativas no Size Estimating Template, devem ser calculados os valores de duas variáveis: A = BA + PA (2.2) onde A é o número total de linhas a serem criadas, BA é o número de linhas que serão adicionadas às partes base e PA é o tamanho total das partes adicionadas E = A + M (2.3) onde E é o tamanho estimado do proxy e M é o número de linhas que serão modificadas nas partes base.

41 25 Passos 4 e 5. estimativa definitiva do tamanho do programa (Passo 4) e estimativa definitiva do tempo total de desenvolvimento do programa (Passo 5). Para tanto, vários cálculos devem ser realizados para atribuir valores a um conjunto de variáveis, que são reunidas numa planilha fornecida pelo PSP 1 para apresentação clara das informações. Durante o quarto e quinto passos do PROBE, a primeira decisão a ser tomada é sobre qual método será utilizado para a realização dos cálculos para estimativa de tamanho e tempo de desenvolvimento dos programas. São quatro métodos: A, B, C ou D, sendo que a adequação de um ou outro método relaciona-se à quantidade de dados históricos que se tem disponível. Na Tabela 2.5 são apresentados os critérios de seleção de cada método. Tabela 2.5 Critérios de seleção dos métodos para cálculo das estimativas pelo PROBE Método A B C D Critérios de seleção Para estimativas de tamanho, este método só poderá ser usado caso existam três ou mais pontos de dados sobre o tamanho estimado do proxy (E) e o número real de LOCs adicionadas e modificadas nos programas construídos. Já para estimativas de tempo, este método só poderá ser usado caso existam três ou mais pontos de dados sobre o tamanho estimado do proxy (E) e o tempo real de desenvolvimento. Além disso, para ambas estimativas a correlação matemática entre os dados deve ser maior que 0.7. Deverá ser usado caso o método A não seja adequado. Para estimativas de tamanho, este método poderá ser usado caso existam três ou mais pontos de dados sobre o tamanho planejado de LOCs adicionadas e modificadas e os correspondentes tamanhos reais. Já para estimativas de tempo, este método poderá ser usado caso existam três ou mais pontos de dados sobre o tamanho planejado de LOCs adicionadas e modificadas e o correspondente tempo real de desenvolvimento. Além disso, para ambas estimativas, a correlação matemática entre os dados deve ser maior que 0.7. Note que, neste método, não é necessário ter dados sobre a variável E em outros programas, mas apenas estimativas do número de LOCs adicionadas e modificadas, as quais podem ter sido estimadas pelo julgamento do desenvolvedor. Deverá ser usado caso o método B não seja adequado. Para estimativas de tamanho, este método poderá ser usado caso exista pelo menos um ponto de dados sobre o tamanho planejado de LOCs adicionadas e modificadas e o correspondente tamanho real. Para estimativas de tempo, este método poderá ser usado caso exista pelo menos um ponto de dados sobre o tamanho planejado de LOCs adicionadas e modificadas e o correspondente tempo real de desenvolvimento. Neste método não se calcula a correlação matemática entre os dados de tamanho e tempo. Deverá ser usado se não houver nenhum dado histórico. Este método consiste em apenas julgar o tamanho esperado de LOCs adicionadas e modificadas ou o tempo de desenvolvimento. Após a escolha do método a ser utilizado, deve-se calcular os parâmetros de regressão linear β 0(size) e β 1(size) para a estimativa de tamanho e β 0(time) e β 1(time) para estimativa do tempo.

42 26 Em termos gerais, β 0 indica a variação percentual média do tamanho/tempo real em relação ao estimado, enquanto β 1 indica uma relação entre o valor de E e o número de LOCs/tempo real (em minutos). No entanto, o cálculo destes parâmetros não consiste em simplesmente calcular médias aritméticas e varia de acordo com o método utilizado (A, B, C ou D). Os valores encontrados pelos cálculos realizados podem indicar a necessidade de mudar de um método para outro. Detalhes sobre o cálculo dos parâmetros β 0 e β 1 podem ser encontrados em HUMPHREY (2005). Ainda no quarto passo, após a definição de β 0(size), β 1(size), β 0(time) e β 1(time) deve-se estabelecer os valores para as seguintes variáveis: P = β 0(size) + β 1(size) *E (2.4) onde P é a estimativa final do tamanho do programa a ser desenvolvido em LOCs adicionadas e modificadas T = P + B - D - M + R (2.5) onde T é o tamanho total estimado do programa a ser desenvolvido Tempo total estimado = β 0(time) + β 1(time) *E (2.6) Com o tempo total de desenvolvimento já estabelecido, a definição do tempo de cada fase pode ser feita pelo julgamento do desenvolvedor. Passo 6. cálculo do intervalo de previsão, que estabelece um valor mínimo e máximo dentro do qual as variáveis tamanho e tempo totais têm determinada probabilidade de cair. O PSP sugere o emprego de um intervalo de previsão de 70%, o qual estabelece um intervalo de valores dentro do qual há 70% de chance de os valores de tamanho e tempo reais caírem. Para definir os intervalos de previsão de 70%, deve-se executar as seguintes etapas: a) calcula-se a variância entre os dados projetados e os dados reais para tamanho e tempo aplicando-se a seguinte fórmula: (2.7) onde n é o tamanho do conjunto de dados histórico, y i é o dado real (o tamanho real do programa ou o tempo real de desenvolvimento), x i é o dado estimado, devendo-se utilizar β 0(size) e β 1(size) quando calculando o intervalo de previsão para o tamanho e β 0(time) e β 1(time) quando calculando o intervalo de previsão para o tempo; b) calcula-se o desvio padrão: Desvio padrão = σ = (2.8)

43 27 c) utiliza-se uma tabela t - distribution (HUMPHREY, 2005) para encontrar o valor de t (p, d), com p = 70% e d = n - 2 graus de liberdade, o qual indica o número de variáveis livres que serão utilizados para o cálculo estatístico; d) calcula-se a variação do intervalo de previsão: Variação = t (p, d) σ n + (x k x avg ) 2 n i=1(x i x avg ) 2 onde x avg é a média das n estimativas e x k é o valor da estimativa do tamanho do proxy (E) para o programa atual. (2.9) Após encontrar o valor da variação do intervalo de previsão, finalmente são calculados o menor (LPI, do inglês Lower Prediction Interval) e o maior (UPI, do inglês Upper Prediction Interval) valores do intervalo de previsão, dados por: LPI = β 0 + β 1 x k - Variação (2.10) UPI = β 0 + β 1 x k +Variação (2.11) Salienta-se que se deve utilizar β 0(size) e β 1(size) quando calculando o intervalo de previsão para o tamanho e β 0(time) e β 1(time) quando calculando o intervalo de previsão para o tempo. Observa-se que para auxiliar o emprego do método PROBE, o PSP 1 fornece instruções através do PROBE Estimating Script. Após a execução do método PROBE, tem-se a estimativa de tamanho total do programa a ser desenvolvido, bem como o tempo total de desenvolvimento esperado. Embora seja bastante minucioso, o método PROBE permite obter estimativas cada vez mais próximas da realidade, uma vez que elas se baseiam em dados históricos pessoais. Além disso, desde que sejam feitas as devidas adaptações, é possível utilizar este método para estimar tamanho e tempo de diversos tipos de tarefas, e não apenas de tarefas de programação. Além do método PROBE, o PSP 1 propõe o emprego de um formulário denominado Test Report Template para o registro de informações mais detalhadas sobre os testes realizados nos programas, tais como: número do teste, objetivo, descrição, condições de teste, resultados esperados e resultados reais.

44 Como em todos os níveis do PSP, o PSP 1 estabelece o Sumário do Plano de Projeto do PSP 1, exemplificado na Tabela 2.6, o qual acrescenta ao PSP 0.1 as seguintes informações: produtividade real, planejada e geral (To Date) em LOCs/hora, indicando quantas linhas são adicionadas ou modificadas por hora; dados sobre o tamanho planejado e real do programa, categorizados de acordo com os tipos de LOC; dados sobre o tempo total planejado e real necessário para o desenvolvimento do programa; dados sobre o tempo planejado e real necessário para cada fase de construção do programa. Tabela 2.6 Sumário do Plano de Projeto PSP 1 Desenvolvedor José da Silva Data 10/03/2009 Projeto Fórmulas de estatística Programa 10 Linguagem C Planejado Real To Date LOCs/hora 27,2 30,9 23,4 Tamanho do programa (LOC) Base (B) Adicionadas (A) Modificadas (M) Deletadas (D) Reutilizadas (R) Planejado Real To Date (medido) (medido) (A&M - M) (T - B + D -R) 5 18 (estimado) (contado) 0 0 (estimado) (contado) (estimado) (contado) A&M (projetado, dado por P) (A + M) Total (T) (P + B - M - D + R) (medido) Novas reutilizáveis (NR) Tamanho estimado do proxy (E) campos do PSP 0.1, incluindo planejamento de tempo das fases

45 29 Além desses dados, caso seja de interesse, os valores de LPI e UPI podem também ser apresentados no sumário. Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 1 são: cinco scripts: um para guiar os desenvolvedores na utilização do PSP 1, três para guiá-los em cada fase do PSP e um com instruções de apoio ao emprego do método PROBE; três formulários: Sumário do Plano de Projeto, Test Report Template, Size Estimating Template. Nível 1.1 O PSP 1.1 tem como foco de atuação as fases de planejamento e desenvolvimento do PSP, de modo que não são incorporadas mudanças à fase de autópsia. Além de manter os objetivos do PSP 1, o PSP 1.1 tem como objetivos específicos (HUMPHREY, 2005): elaborar o planejamento de tarefas de um projeto; criar cronogramas; monitorar o progresso real em relação ao progresso planejado para o projeto. Para elaborar o planejamento de tarefas, o desenvolvedor deve, primeiramente, distribuir entre as fases do PSP o tempo total estimado pelo PROBE para o desenvolvimento de cada um dos programas do projeto. Esta distribuição deve basear-se no atributo To Date % (relacionado ao tempo) do Sumário do Plano de Projeto. Caso exista mais de uma atividade em uma ou mais fases, o desenvolvedor deve julgar o tempo necessário para cada atividade de modo que a soma seja igual ao tempo total da fase. Após a definição da duração das atividades, esta informação deve ser lançada no Task Planning Template, que registra as seguintes informações: nome da atividade; fase a qual pertence; duração planejada (em horas); total de horas acumuladas até cada atividade, o qual é dado pela soma da duração das atividades anteriores;

46 30 valor planejado (PV, do inglês planned value) para cada atividade, o qual deve ser dado pelo percentual do tempo total planejado que se espera gastar com a atividade; PV acumulado até cada atividade, o qual é dado pela soma do PV das atividades anteriores; semana planejada, que é estimada com apoio do Schedule Planning Template e corresponde à semana em que se planeja concluir uma atividade; horas realmente gastas com cada atividade; semana em que cada atividade foi realmente concluída; valor agregado (EV, do inglês earned value) pela atividade, o qual é atribuído apenas quando a atividade é totalmente concluída e corresponde ao PV; EV acumulado até cada atividade, o qual é dado pela soma do EV das atividades anteriores. Conforme citado, o Schedule Planning Template tem como função auxiliar na definição das semanas em que cada atividade de determinado projeto será concluída. Para tanto, este formulário registra a disponibilidade do desenvolvedor para um determinado projeto em cada semana (até que se complete a quantidade de horas total estimada para o projeto) por meio dos seguintes atributos: data de início da semana; identificador numérico da semana; horas disponíveis na semana; horas disponíveis acumuladas até determinada semana; horas realmente gastas em cada semana; horas realmente acumuladas até determinada semana; PV de cada semana, o qual corresponde ao somatório dos PVs das atividades que deverão ser concluídas em cada semana; PV acumulado até determinada semana; EV de cada semana, o qual corresponde ao somatório dos EVs das atividades concluídas em cada semana; EV acumulado até determinada semana.

47 Salienta-se que o EV é atribuído a uma atividade somente quando ela é completamente concluída, de modo que não se atribui 50% do PV como sendo o EV de uma atividade 50% concluída. A partir do Task Planning Template e do Schedule Planning Template, o desenvolvedor consegue elaborar o planejamento de suas atividades em termos das semanas de execução do projeto. Além disso, é possível monitorar e comparar o progresso real em relação ao planejado, o que é feito comparando-se o EV acumulado com o PV acumulado. Se o EV acumulado for maior ou igual ao PV acumulado, o progresso do projeto está dentro do esperado ou além do esperado. Caso contrário, o progresso está aquém do esperado. O PSP 1.1 fornece também um indicador capaz de sinalizar a capacidade do planejamento do tempo, o qual é denominado Cost Performance Index (CPI), que consiste na razão entre o tempo de desenvolvimento total planejado acumulado até a data e o tempo de desenvolvimento total real acumulado até a data (POMEROY-HUFF et al., 2009). O ideal é que o CPI seja próximo a 1, refletindo que o tempo planejado está próximo ao tempo realmente gasto. Como em todos os níveis do PSP, o PSP 1.1 estabelece o Sumário do Plano de Projeto do PSP 1.1, exemplificado na Tabela 2.7, o qual acrescenta ao PSP 1 as seguintes informações: tempo planejado e real para o desenvolvimento do programa; tempo planejado e real acumulado até a data, desde que se iniciou o emprego do PSP; CPI e percentual de LOCs reutilizadas (R) e novas reutilizadas (NR). Tabela 2.7 Sumário do Plano de Projeto PSP 1.1 Desenvolvedor José da Silva Data 29/03/2009 Projeto Fórmulas de estatística Programa 11 Linguagem C Planejado Real To Date LOCs/hora 26,7 25,3 23,6 Tempo planejado ,8 Tempo real 709,2 6052,2 CPI 0,80 % de LOCs R 1,3 1,4 0,50 % de LOCs NR 4,4 5,3 5,7 + campos do PSP 1 31

48 32 Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 1.1 são: quatro scripts: um para guiar os desenvolvedores na utilização do PSP 1 e três para guiá-los em cada fase do PSP; três formulários: Sumário do Plano de Projeto, Task Planning Template, Schedule Planning Template. Nível 2 Os níveis 2 e 2.1, denominados PSP 2 e 2.1, têm como foco o gerenciamento da qualidade pessoal. Além de manter os objetivos do PSP 1.1, o PSP 2 tem como objetivos específicos (HUMPHREY, 2005): introduzir revisões de projeto e código; introduzir métodos para avaliar e melhorar a qualidade do processo de software e das revisões; estimar o número de defeitos em cada fase. O objetivo das revisões é encontrar e corrigir defeitos o mais cedo possível, pois, conforme apontam estudos empíricos (HUMPHREY, 2005; PRESSMAN, 2009), é muito mais rápido e barato encontrar e corrigir defeitos em fases iniciais do desenvolvimento de software. Para apoiar a execução das revisões, o PSP 2 fornece um script para orientar a revisão de projeto e outro para a revisão de código, os quais devem ser aplicados em conjunto com checklists de revisão de projeto e código, respectivamente. Enquanto o PSP 2 fornece checklist para revisão de projeto, o checklist de revisão de código é um formulário específico para cada linguagem, onde os desenvolvedores registrarão cada um dos itens verificados nas revisões, de modo a evitarem esquecimentos. Este checklist deve ser criado e atualizado com base no conjunto de tipos de defeitos padrão e no Defect Recording Log, com o intuito de evitar que tais defeitos estejam presentes no código. Observa-se que as revisões de projeto devem ser realizadas após a criação do projeto e antes da codificação, enquanto as revisões de código devem ser realizadas ao término da codificação e antes da compilação. Além de introduzir as revisões de projeto e código, o PSP 2 introduz diversos métodos para avaliar a qualidade do processo de software e das revisões e, com isso, melhorá-las. Tais

49 métodos consistem na obtenção de indicadores calculados com base nos dados registrados durante o desenvolvimento. Os principais indicadores gerados para análise são: 33 rendimento da remoção de defeitos - quantifica a eficiência da remoção de defeitos em cada fase do PSP. Há duas formas de mensurá-lo: - rendimento de uma fase = número de defeitos corrigidos na fase (2.12) número de defeitos presentes no início da fase + número de defeitos produzidos na fase - rendimento do processo = número de defeitos corrigidos antes da compilação (2.13) número de defeitos presentes antes da compilação + número de defeitos presentes durante a compilação Salienta-se que os rendimentos das fases de revisão de projeto e código podem ser calculados como forma de sinalizar a qualidade das revisões. densidade de defeitos - é dado pelo número de defeitos encontrados por volume de projeto ou pelo número de defeitos encontrados por KLOC. taxa de defeitos - é dado por: número de defeitos encontrados em uma fase (2.14) tempo gasto em horas na fase defect-removal leverage (DRL) - mede o poder de remoção de defeitos de uma fase em relação a uma outra fase e é dado por: número de defeitos removidos em uma fase X (2.15) número de defeitos removidos em uma fase Y Este indicador é especialmente útil quando envolve fases de revisão e teste, pois demonstra qual delas tem um poder maior para remover defeitos.

50 34 taxa de revisão - esse é um indicador usado principalmente para revisão de LOCs, não sendo muito comum para revisão de projeto. É dado por: número de LOCs revisadas (2.16) tempo de revisão de código em horas cost-of-quality (COQ) - é uma forma de quantificar o tamanho do problema de qualidade (HUMPHREY, 2005). As medidas de COQ do PSP são as seguintes: a) Failure COQ - mede o percentual de tempo que a compilação e os testes demandam em relação ao tempo total de desenvolvimento e é dado por: 100* (tempo de compilação + tempo de testes) (2.17) tempo total de desenvolvimento b) Appraisal COQ - mede o percentual de tempo que as revisões de código e de projeto demandam em relação ao tempo total de desenvolvimento e é dado por: 100* (tempo de revisão de projeto + tempo de revisão de código) (2.18) tempo total de desenvolvimento c) COQ total - mede percentual de tempo que as medidas de qualidade demandam em relação ao tempo total de desenvolvimento e é dado por: Failure COQ + Appraisal COQ (2.19) d) Appraisal como % do COQ total - é dado por: 100* (Appraisal COQ) (2.20) COQ total e) Appraisal to Failure Ratio (AF/R) - calcula a razão entre Appraisal COQ e Failure COQ, sendo muito útil para monitorar o melhoramento da qualidade do processo pessoal, pois valores maiores de AF/R demonstram que uma quantidade de tempo adequada está sendo empregada em revisões. No entanto, deve haver um equilíbrio no gasto de tempo com revisões, de modo que um bom valor para o AF/R é próximo a 2.0 (HUMPHREY, 2005). process quality index (PQI) - é um índice que quantifica a qualidade do processo de software e é calculado como o produto dos seguintes valores (HUMPHREY, 2005): a = tempo de projeto (2.21) tempo de codificação

51 35 b = 2 * tempo de revisão do projeto (2.22) tempo de projeto c = 2 * tempo de revisão do código (2.23) tempo de codificação d = 20 (2.24) (10 + defeitos de compilação/kloc) e = 10 (2.25) (10 + defeitos de teste de unidade/kloc) Logo, PQI = a*b*c*d*e. Quanto mais próximo de 1 for o PQI, melhor é a qualidade do processo de desenvolvimento. Por fim, o PSP 2 estimula os desenvolvedores a estimarem o número de defeitos que serão produzidos em cada fase. Para tanto, primeiramente deve ser estimado o tamanho do programa a ser desenvolvido. Em seguida, com base no número de defeitos por KLOC (obtido pelos dados históricos), estima-se o número total de defeitos que o programa terá. Para distribuir estes defeitos entre as fases, utiliza-se os dados de To Date %. Como em todos os níveis do PSP, o PSP 2 estabelece o Sumário do Plano de Projeto do PSP 2, exemplificado na Tabela 2.8, o qual acrescenta ao PSP 1.1 as seguintes informações: defeitos encontrados na fase de teste por KLOC (planejado, real e até a data), sendo que quanto menor for este valor, melhor é a qualidade do processo, uma vez que os defeitos devem ser encontrados preferencialmente antes da fase de teste; defeitos encontrados por KLOC (planejado, real e até a data), sendo que quanto menor for este valor, melhor é a qualidade do produto; rendimento do processo; UPI e LPI para as estimativas de tamanho e tempo, os quais já eram calculados no PSP 1; dados sobre a eficiência na remoção de defeitos.

52 36 Tabela 2.8 Sumário do Plano de Projeto PSP 2 Desenvolvedor José da Silva Data 15/04/2009 Projeto Fórmulas de estatística Programa 12 Linguagem C Planejado Real To Date LOCs/hora 24,6 26,6 23,8 Tempo planejado ,8 Tempo real 448,5 6500,7 CPI 0,81 % de LOCs R 2,4 3,1 0,6 % de LOCs NR 5,4 7,2 5,8 Defeitos de teste/kloc 13,5 5 12,8 Defeitos/KLOC 81,1 90,5 81,8 Rendimento 0,5 0,8 0,5 Indicadores sobre remoção de defeitos Planejado Real To Date Defeitos/hora- Revisão de projeto - 5,6 5,6 Defeitos/hora- Revisão de código Defeitos/hora- Compilação 12,1 6,6 11,7 Defeitos/hora - Teste 2,3 1,1 2,2 DRL (revisão de código/teste de unidade) - 5 0,3 DRL (compilação/teste de unidade) 3,4 3 3,5 + campos do PSP 1, incluindo o planejamento de defeitos por fase Observa-se que alguns campos do Sumário do Plano de Projeto estão preenchidos com "-", pois não há dados que fundamentem seu planejamento até o momento de criação do sumário para o programa 12. Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 2 são: seis scripts: um para guiar no emprego do PSP 2, três para guiar as fases do PSP, um para guiar as revisões de projeto e outro para as revisões de código; três formulários: Sumário do Plano de Projeto, checklist para revisões de projeto e checklist para revisões de código.

53 37 Nível 2.1 O PSP 2.1 tem como foco de atuação a fase de projeto do PSP. Além de manter os objetivos do PSP 2, o PSP 2.1 tem como objetivos específicos (HUMPHREY, 2005): reduzir o número de defeitos nos projetos; prover critérios para determinar se um projeto está completo; prover uma estrutura consistente para documentar e verificar os projetos. Para atingir tais objetivos, o PSP 2.1 fornece modelos para especificação dos projetos, a saber: a) modelo de especificação operacional - consiste em um formulário simplificado para descrever o comportamento operacional do programa. Este modelo registra, de maneira estruturada, informações similares às do diagrama de casos de uso da Unified Modeling Language (UML); b) modelo de especificação funcional - consiste em um formulário para descrever as interfaces e lógicas dos métodos de cada classe. Este modelo registra, de maneira estruturada, informações similares às do diagrama de classes da UML; c) modelo de especificação de estados - consiste em um formulário para descrever o estados de um sistema ou parte dele. Este modelo registra, de maneira estruturada, informações similares às do diagrama de estados da UML; d) modelo de especificação lógica - consiste em um formulário para descrever a lógica dos programas por meio de pseudocódigo. Observa-se que os modelos de especificação devem ser tratados como um complemento aos modelos gráficos que representam o comportamento ou estrutura dos sistemas. Portanto, é importante manter a consistência entre as representações empregadas. Além destes modelos de especificação de projeto, o PSP 2.1 fornece também versões mais detalhadas para o script e o checklist de revisão de projeto. Por fim, como todos os demais níveis, o PSP 2.1 estabelece o Sumário do Plano de Projeto do PSP 2.1, o qual não será apresentado, pois inclui apenas 3 informações obtidas em níveis anteriores, sendo elas: Appraisal como % do COQ total, Failure COQ, A/FR. Em resumo, a partir do conteúdo apresentado pode-se concluir que os principais elementos do PSP 2.1 são:

54 38 cinco scripts: um para guiar os desenvolvedores na utilização do PSP 2.1, três para guiá-los em cada fase do PSP e um para guiar as revisões de projeto. seis formulários: Sumário do Plano de Projeto, checklist para revisões de projeto; quatro modelos de especificação de projeto. 2.4 Trabalhos relacionados Nos últimos anos, estudos vêm apontando que as habilidades pessoais de cada membro de equipe são cruciais para o sucesso dos projetos de software (BADDOO; HALL, 2003; JIRACHIEFPATTANA, 2012). Diante disso, trabalhos vêm propondo mecanismos para a melhoria da maturidade dos recursos humanos envolvidos nos projetos. Em geral, tais mecanismos devem ser empregados pelos próprios indivíduos durante suas rotinas de trabalho, de modo a estimular o autoconhecimento e posterior melhoria da produtividade e qualidade do trabalho desenvolvido. Uma das vertentes das pesquisas realizadas visa propor ferramentas de apoio à melhoria de aspectos específicos, relacionados ao aumento da produtividade dos recursos humanos ou à melhoria da qualidade dos produtos de software desenvolvidos. Quanto ao aumento da produtividade dos recursos humanos, a maioria dos trabalhos oferece ferramentas de suporte ao registro do tempo gasto pelos membros de equipe para desenvolver suas atividades pessoais (EPIFORGE SOFTWARE, 2012; RESPONSIVE SOFTWARE, 2012). Em relação à melhoria da qualidade dos produtos de software, alguns trabalhos propõem sistemas computacionais de apoio às revisões de projeto e código (BRYKCZYNSKI; MEESON; WHEELER, 1994; KLEINE, 2011), enquanto outros propõem recursos para documentação de defeitos encontrados (BUGZILLA, 2012; EDGEWALL, 2012; MANTIS, 2012). Apesar do grande potencial dessas propostas, muitas vezes não se consegue extrair todos os seus benefícios, uma vez que são empregadas de maneira isolada, sem a integração com outros mecanismos que poderiam apoiar a obtenção de informações mais amplas e relevantes. Diante dessa situação, é muito comum que dados registrados não sejam devidamente aproveitados. Além das pesquisas com objetivos mais específicos, vários trabalhos visam a melhoria de todo o processo pessoal de desenvolvimento de software. Neste contexto, diversos trabalhos vêm propondo sistemas computacionais de apoio ao emprego do PSP (JOHNSON et al., 2005; NAZIR; YUSOF, 2005; SHIN; CHOI; BAIK, 2007; SISON et al., 2005; TUMA

55 39 SOLUTIONS, 2012; YUAN et al., 2005). No entanto, a maioria das propostas não oferece apoio a todos os níveis do PSP ou, quando oferecem, não apoiam a aplicação de elementos importantes, como a medição do tempo de correção de defeitos e a geração de indicadores do processo. Além disso, durante toda a revisão bibliográfica não foram encontradas ferramentas computacionais que apoiem o emprego do PSP no contexto de gerenciamento de projetos, o que impede que os gerentes de projetos possam obter informações importantes sobre os membros de equipe a partir dos dados coletados individualmente. Outro problema decorrente disso é a necessidade de os membros de equipe cadastrarem em um sistema externo os dados sobre suas atividades pessoais, que muitas vezes já estão disponíveis no ambiente de apoio ao gerenciamento de projetos. Diante desse cenário, atesta-se a originalidade e a importância deste trabalho como uma forma de apoiar a melhoria da maturidade pessoal e fornecer informações importantes para as tomadas de decisão dos gerentes de projetos. 2.5 Considerações finais Neste capítulo foi apresentada a arquitetura originalmente estabelecida para o desenvolvimento do SAGP que foi expandido neste trabalho para incorporar técnicas de apoio à capacitação individual. Foi também apresentado um estudo sobre o PSP, o qual abordou as suas características gerais, bem como uma descrição de cada um de seus níveis. Além disso, foi apresentado um panorama geral sobre os trabalhos relacionados à melhoria da maturidade pessoal no contexto de desenvolvimento de software. Com isso, foi possível observar a complexidade do PSP, a partir do qual se tem o estabelecimento de passos bem fundamentados capazes de direcionar o aperfeiçoamento individual dos profissionais. Por fim, cabe salientar que o estudo de trabalhos relacionados permitiu constatar a originalidade e a contribuição deste trabalho.

56 40 CAPÍTULO 3 Ferramenta de Apoio ao PSP 3.1 Considerações iniciais O objetivo deste capítulo é apresentar os requisitos funcionais identificados a partir dos estudos realizados, os quais foram contemplados pelo componente incorporado ao SAGP de modo a apoiar o emprego do PSP pelos membros das equipes de projetos, bem como fornecer informações importantes que possam auxiliar os gerentes de projetos em suas tomadas de decisões. Além disso, este capítulo apresenta a arquitetura de software do SAGP estendida para incorporar os requisitos identificados. Por fim, é apresentado o funcionamento do componente construído. Na seção 3.2 são apresentados os requisitos funcionais identificados para o componente de apoio ao PSP. Na seção 3.3 é apresentada a arquitetura de software do SAGP estendida. Na seção 3.4 é apresentado o funcionamento do componente construído. Por fim, na seção 3.5, são apresentadas as considerações finais deste capítulo. 3.2 Requisitos identificados A partir do estudo realizado em torno do PSP, foram identificados os requisitos funcionais a serem contemplados pelo componente de apoio ao PSP, os quais estão descritos nas próximas subseções. Observa-se que a apresentação dos requisitos está organizada em sete categorias: uma geral e outras seis referentes a cada nível do PSP. A categoria geral reúne os requisitos relacionados a todos os níveis, enquanto as outras seis reúnem os requisitos necessários para atender especificamente a cada nível do PSP considerando o ambiente de gerenciamento de projetos.

57 41 Os requisitos foram representados por meio do diagrama de casos de uso sendo que, para cada caso de uso, uma breve descrição é apresentada. Observa-se que os cenários para especificação detalhada dos casos de uso são descritos no Apêndice A segundo o modelo de especificação operacional proposto pelo nível 2.1 do PSP, no qual são declaradas as seguintes informações: dados gerais: nome do autor, data de autoria e linguagem; número do cenário; objetivo do cenário; ator de cada passo; número de cada passo; ação de cada passo; comentários, onde são registrados resultados, condições de exceção ou outras informações úteis. Em relação à especificação dos requisitos, observa-se que: cenários alternativos oriundos de ações de validação mal sucedidas não foram apresentados por se tratarem apenas da emissão de mensagens de erro, embora tenham sido implementados; todos os dados cadastrados podem também ser consultados, alterados e excluídos. Entretanto, apenas os cenários de cadastro são apresentados, uma vez que as consultas, alterações e exclusões ocorrem de maneira similar ao cadastro, apesar das particularidades referentes às validações específicas de cada operação. Para a elaboração do diagrama de casos de uso e do modelo de especificação operacional foram definidos 4 possíveis atores: Usuário de nível 1 - usuários que tem acesso de nível 1 a um projeto do SAGP; Usuário de nível 2 - usuários que tem acesso de nível 2 a um projeto do SAGP; Usuário de nível 3 - usuários que tem acesso de nível 3 a um projeto do SAGP; Gerente de projeto - usuário de nível 3 que cadastrou o projeto.

58 Requisitos gerais O diagrama de casos de uso ilustrado na Figura 3.1 representa o conjunto de operações que o sistema deve permitir que os usuários executem. Na Tabela 3.1 é apresentada uma descrição resumida de cada caso de uso. Figura Diagrama de casos de uso - Requisitos gerais Requisitos referentes ao PSP 0 O diagrama de casos de uso ilustrado na Figura 3.2 representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 0. Na Tabela 3.2 é apresentada uma descrição resumida de cada caso de uso.

59 43 Tabela 3.1 Descrição resumida dos casos de uso Requisitos gerais ID Caso de uso Descrição resumida 1 Registrar interesse em empregar o PSP na gestão de projetos Este caso de uso permite que, no momento de cadastro de um projeto, o gerente de projetos registre se deseja ou não empregar informações 2 Registrar nível do PSP a ser empregado em cada projeto oriundas do PSP durante a gestão Este caso de uso permite que, no primeiro acesso a um projeto, o usuário registre se deseja empregar o PSP no projeto e qual será o nível empregado. Com isso, são habilitadas as ferramentas de apoio à aplicação do nível selecionado 3 Apresentar instruções do PSP Este caso de uso permite que qualquer usuário que empregue o PSP possa consultar instruções sobre o seu uso 4 Apresentar sumário de plano de projeto Este caso de uso permite consultar o sumário do plano de projeto referente a cada programa construído em um projeto, o qual é gerado automaticamente a partir da reunião e organização dos dados coletados ao longo do PSP 5 Registrar conclusão de projeto Este caso de uso permite que os usuários do PSP registrem a conclusão do projeto quando completarem suas atividades 6 Gerar relatório Este caso de uso permite gerar relatórios em PDF sobre todas as informações oriundas do emprego do PSP 7 Exibir indicadores de membros da equipe Este caso de uso permite que usuários de nível 2 acessem uma página para apresentação de indicadores de membros de equipe oriundos do uso pessoal do PSP, os quais podem ser relacionados à qualidade ou tempo de execução de atividades. Podem ser visualizados indicadores individuais ou de um conjunto de membros

60 Figura Diagrama de casos de uso - Requisitos referentes ao PSP 0 44

61 45 Tabela 3.2 Descrição resumida dos casos de uso Requisitos referentes ao PSP 0 ID Caso de uso Descrição resumida 8 Cadastrar programas a serem construídos Este caso de uso permite que os usuários do PSP cadastrem os programas a serem construídos, registrando o nome do programa, a linguagem de programação usada e a atividade do projeto à qual o programa se refere. Observa-se que os programas cadastrados referem-se àqueles que cada membro deverá desenvolver para cumprir as atividades do projeto às quais está alocado 9 Apresentar atividades a serem realizadas no projeto Este caso de uso permite que, no momento de cadastro de um programa, sejam apresentados os dados sobre as atividades do projeto às quais o usuário está alocado, facilitando a identificação dos programas que ele deverá desenvolver para cumprir seu papel no projeto 10 Cadastrar atividades pessoais Este caso de uso permite cadastrar as atividades envolvidas na construção de cada programa 11 Registrar estimativa de tempo das atividades Este caso de uso permite registrar o tempo total estimado para o desenvolvimento das atividades envolvidas na construção de cada programa 12 Disponibilizar o Time Recording Log Este caso de uso permite a coleta de dados de tempo das atividades pessoais por meio de um mecanismo que registra o início das atividades, as interrupções realizadas e o término da contagem do tempo 13 Apresentar o Time Recording Log Este caso de uso permite que os usuários do PSP consultem os dados coletados pelo Time Recording Log para cada programa cadastrado 14 Disponibilizar o Defect Recording Log Este caso de uso permite registrar dados sobre os defeitos encontrados nos programas por meio de um formulário 15 Enviar um programa para teste Este caso de uso permite que os usuários que empregam o PSP no projeto acessem uma página para seleção de programas que desejam enviar para teste, sendo necessário definir o arquivo referente a cada programa. Feito isso, o sistema faz upload do arquivo e o disponibiliza para os membros da equipe do projeto responsáveis por atividades de teste 16 Apresentar um programa para teste Este caso de uso permite que qualquer usuário com o papel de testador no projeto possa acessar uma página com os programas que estão aguardando o início de testes. Ao selecionar um dos programas, o usuário torna-se o responsável pelos seus testes e o programa não é mais apresentado a outros testadores 17 Registrar dados sobre testes realizados Este caso de uso permite registrar defeitos encontrados em programas recebidos para testes. Os dados sobre os defeitos são registrados entre as estatísticas do autor do programa

62 Requisitos referentes ao PSP 0.1 O diagrama de casos de uso ilustrado na Figura 3.3 representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 0.1. Na Tabela 3.3 é apresentada uma descrição resumida de cada caso de uso. Figura Diagrama de casos de uso - Requisitos referentes ao PSP 0.1 Tabela 3.3 Descrição resumida dos casos de uso Requisitos referentes ao PSP 0.1 ID Caso de uso Descrição resumida 18 Cadastrar padrão de codificação Este caso de uso permite que os usuários do PSP cadastrem o padrão de codificação que pretendem seguir para cada linguagem de programação 19 Registrar dados obtidos com as medições de software 20 Cadastrar dados no Process Improvement Proposal Este caso de uso permite cadastrar os dados obtidos com as medições de cada programa construído Este caso de uso permite cadastrar propostas de melhoria no processo de acordo com o formulário PIP Requisitos referentes ao PSP 1 O diagrama de casos de uso, ilustrado na Figura 3.4, representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 1. Na Tabela 3.4 é apresentada uma descrição resumida de cada caso de uso.

63 47 Figura Diagrama de casos de uso - Requisitos referentes ao PSP 1 Tabela 3.4 Descrição resumida dos casos de uso Requisitos referentes ao PSP 1 (continua) ID Caso de uso Descrição resumida 21 Cadastrar proxy Este caso de uso permite cadastrar o proxy a ser empregado para cada linguagem de programação utilizada 22 Cadastrar categorias funcionais de proxies Este caso de uso permite cadastrar as categorias funcionais de cada proxy cadastrado 23 Registrar tamanho dos proxies em programas já construídos Este caso de uso permite registrar o tamanho dos proxies em programas já construídos, de modo a criar uma base histórica 24 Apresentar tabelas de tamanho relativo Este caso de uso permite gerar automaticamente a tabela de tamanho relativo, realizando os cálculos a partir dos dados históricos cadastrados 25 Apresentar avaliação do proxy definido Este caso de uso permite executar automaticamente a avaliação do proxy, realizando os cálculos de correlação e significância a partir dos dados históricos cadastrados 26 Registrar dados no Size Estimating Template Este caso de uso permite registrar dados sobre as estimativas das partes que comporão os programas a serem construídos, de acordo com o Size Estimating Template

64 Tabela 3.4 Descrição resumida dos casos de uso Requisitos referentes ao PSP 1 48 (conclusão) ID Caso de uso Descrição resumida 27 Apresentar estimativas pessoais O sistema permite a geração automática das estimativas de tempo e tamanho dos programas a serem construídos, realizando os cálculos a partir dos dados registrados no Size Estimating Template 28 Registrar tempo estimado para cada atividade seguindo restrições do PSP 1 O sistema permite o registro de tempo estimado para cada atividade pessoal, de acordo com o proposto no PSP 1 29 Cadastrar dados no Test Report Template O sistema permite o cadastro de dados sobre os testes realizados, de acordo com o Test Report Template Requisitos referentes ao PSP 1.1 O diagrama de casos de uso, ilustrado na Figura 3.5, representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 1.1. Na Tabela 3.5 é apresentada uma descrição resumida de cada caso de uso. Figura Diagrama de casos de uso - Requisitos referentes ao PSP 1.1

65 49 Tabela 3.5 Descrição resumida dos casos de uso Requisitos referentes ao PSP 1.1 ID Caso de uso Descrição resumida 30 Registrar tempo estimado para cada atividade seguindo restrições do PSP 1.1 Este caso de uso permite registrar o tempo estimado para cada atividade pessoal, de acordo com o proposto no PSP Disponibilizar o Task Planning Template Este caso de uso permite empregar o Task Planning Template. Para tanto, o usuário deve apenas definir a ordem de execução das atividades pessoais, sendo o restante do template gerado automaticamente 32 Apresentar o Schedule Planning Template Este caso de uso permite gerar automaticamente o Schedule Planning Template a partir dos dados do Task Planning Template e dos períodos de alocação dos usuários a cada atividade do projeto 33 Registrar conclusão de atividade Este caso de uso permite registrar a conclusão das atividades pessoais, de modo a viabilizar a atualização automática do valor de VP no Schedule e no Task Planning Template 34 Apresentar o CPI Este caso de uso permite executar automaticamente o cálculo do valor do CPI a partir dos dados cadastrados Requisitos referentes ao PSP 2 O diagrama de casos de uso ilustrado na Figura 3.6 representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 2. Na Tabela 3.6 é apresentada uma descrição resumida de cada caso de uso. Figura Diagrama de casos de uso - Requisitos referentes ao PSP 2

66 50 Tabela 3.6 Descrição resumida dos casos de uso Requisitos referentes ao PSP 2 ID Caso de uso Descrição resumida 35 Cadastrar o checklist de revisão de código Este caso de uso permite cadastrar o checklist de revisão de código que deve ser empregado para cada linguagem de programação 36 Registrar verificações no checklist de revisão de código 37 Registrar verificações no checklist de revisão de projeto Este caso de uso permite registrar as verificações já realizadas no código de cada programa cadastrado, de modo a facilitar o acompanhamento das revisões Este caso de uso permite registrar as verificações já realizadas no projeto de cada programa cadastrado, de modo a facilitar o acompanhamento das revisões. Observa-se que o checklist de revisão de projeto segue o padrão proposto pelo PSP 38 Apresentar indicadores de qualidade Este caso de uso permite executar automaticamente os cálculos para geração dos indicadores de qualidade propostos pelo PSP, os quais são exibidos numérica e graficamente na forma de um painel Requisitos referentes ao PSP 2.1 O diagrama de casos de uso ilustrado na Figura 3.7 representa o conjunto de operações que o sistema deve permitir que os usuários executem, tendo como base o PSP 2.1. Na Tabela 3.7 é apresentada uma descrição resumida de cada caso de uso. Figura Diagrama de casos de uso - Requisitos referentes ao PSP 2.1 Tabela 3.7 Descrição resumida dos casos de uso Requisitos referentes ao PSP 2.1 ID Caso de uso Descrição resumida 39 Disponibilizar modelos de especificação de projeto Este caso de uso permite cadastrar os quatro modelos de especificação de projeto para cada programa cadastrado, sendo eles: modelo de especificação operacional, modelo de especificação funcional, modelo de especificação 40 Registrar verificações no checklist de revisão de projeto detalhado de estados e modelo de especificação lógica Este caso de uso permite registrar as verificações já realizadas no projeto de cada programa cadastrado, de modo a facilitar o acompanhamento das revisões. Observa-se que no PSP 2.1 são incluídos dois itens em relação ao checklist de revisão de projeto do PSP 2

67 Extensão da arquitetura de software do SAGP Para incorporar as novas funções de apoio ao emprego do PSP, a arquitetura original do SAGP foi estendida, recebendo um novo componente, denominado Gestão pessoal. Na Figura 3.8, é ilustrada a arquitetura do SAGP estendida, mostrando os componentes originais e os módulos alterados, bem como o novo componente criado. No componente Controle de acesso, foram alterados os módulos Gerenciador de projetos e Controlador de conteúdo. O Gerenciador de projetos, antes responsável apenas pelo registro de dados gerais sobre os projetos cadastrados, passa agora a registrar também se o gerente de projetos optou por empregar o PSP em cada projeto. Já o Controlador de conteúdo, antes responsável apenas pelo registro e controle dos níveis de acesso dos usuários aos projetos, passa agora a registrar também o nível do PSP empregado pelos usuários em cada projeto. A seguir, os módulos do componente Gestão pessoal são descritos detalhadamente: 1. Gerenciador de atividades pessoais: Este módulo recebe dados do "Gerenciador de stakeholders" sobre as atividades às quais cada membro da equipe está alocado e as apresenta aos membros que estiverem empregando o PSP no projeto para possibilitar a definição e cadastro das atividades pessoais, cuja conclusão pode ser posteriormente registrada pelos usuários. Além disso, este módulo recebe dados do "Gerenciador de programas" para vincular cada atividade pessoal aos programas que serão construídos por meio delas; 2. Gerenciador de programas: Este módulo permite que cada desenvolvedor cadastre dados gerais sobre os programas que desenvolverá e recebe dados do "Gerenciador de atividades pessoais" para vincular os programas às atividades envolvidas em seu desenvolvimento. Além disso, este módulo registra dados nos formulários do PSP sobre os defeitos encontrados e testes realizados e recebe dados do "Gerenciador de stakeholders" para identificar quais recursos humanos poderão executar as atividades de teste. A partir disso, o "Gerenciador de programas" apresenta esses programas a estes recursos, que podem registrar, nos formulários do PSP, os dados sobre os defeitos encontrados, os quais são lançados entre os registros do autor do programa. Por fim, este módulo permite cadastrar dados sobre as medições do tamanho dos programas, bem como o checklist de revisão de código;

68 Figura Diagrama arquitetural do SAGP estendido a partir de ESTECA (2010) Gerenciador de estimativas: Este módulo recebe dados do "Gerenciador de atividades pessoais" e do "Gerenciador de programas" para gerar estimativas de tempo, tamanho e número de defeitos dos programas de acordo com o nível do PSP empregado pelo usuário em cada projeto. Além disso, para viabilizar o emprego do método PROBE e do cálculo dos intervalos de previsão de tamanho e tempo, este módulo permite que os usuários cadastrem o proxy que utilizarão, bem como suas categorias funcionais e o tamanho mensurado nos programas já construídos. A partir disso, todos os cálculos do PROBE e dos intervalos de previsão são efetuados automaticamente. Por fim, o "Gerenciador de estimativas" fornece aos usuários o Task

69 53 Planning Template e o Schedule Planning Template para auxiliar na gestão pessoal do tempo; 4. Gerador de relatórios pessoais: Este módulo recebe dados do "Gerenciador de atividades pessoais", do "Gerenciador de programas", do "Gerenciador de estimativas" e do "Gerador de painel", reunindo todas as informações necessárias para gerar os sumários de plano de projeto e outros relatórios sobre cada programa construído, de acordo com o nível do PSP empregado nos projetos; 5. Gerador de painel: Este módulo recebe dados do "Gerenciador de atividades pessoais", do "Gerenciador de programas" e do "Gerenciador de estimativas" para gerar todos os indicadores propostos pelo PSP de acordo com seus seis níveis. Após gerar tais indicadores, eles são disponibilizados em um painel de acesso restrito a membros autorizados, podendo ser visualizados de maneira ordenada por parâmetros escolhidos pelos usuários; 6. Gerenciador de padrões: Este módulo permite que os usuários registrem e atualizem os padrões de codificação e de tipos de defeitos; 7. Apresentador de instruções: Este módulo mantém o registro das instruções fornecidas pelo PSP e as apresenta aos usuários do sistema para auxiliá-los no preenchimento de formulários e no emprego de indicadores fornecidos pelo PSP; 8. Registrador de especificações de projeto: Este módulo recebe dados do "Gerenciador de programas" sobre cada programa a ser desenvolvido pelos recursos humanos e disponibiliza os formulários de especificação de projeto propostos pelo PSP, os quais podem ser registrados, alterados e consultados pelos autores dos programas; 9. Registrador de sugestões de melhoria: Este módulo permite que os usuários registrem sugestões de melhoria ao processo pessoal adotado para o desenvolvimento de software, as quais podem ser consultadas apenas por seus autores. 3.4 Funcionamento do componente de apoio ao PSP Nesta seção é descrito o funcionamento do componente de apoio ao PSP implementado. Na subseção são apresentadas as funções que viabilizaram a integração do componente ao ambiente do SAGP. Nas subseções a são apresentadas as

70 funções referentes a cada nível do PSP. Por fim, na subseção são apresentados os indicadores gerados aos gerentes de projeto por meio do emprego individual do PSP Integração do PSP ao SAGP O primeiro passo para empregar o PSP como apoio às atividades de gerenciamento de projetos deve ser dado no momento da criação dos projetos, quando é necessário declarar o interesse em utilizá-lo. Feito isso, ao acessar o projeto no SAGP, os usuários de nível 2 e 3, bem como os gerentes de projetos, poderão visualizar os indicadores gerados por meio das informações oriundas do uso do PSP pelos membros da equipe. Já o emprego pessoal do PSP pode ser feito por qualquer usuário interessado e em qualquer projeto. Para tanto, no primeiro acesso aos projetos, o usuário deve declarar se tem ou não interesse em utilizar o PSP. Além disso, se tiver interesse em empregá-lo, o usuário deve selecionar o nível do PSP desejado, sendo possível utilizar apenas níveis já empregados em projetos anteriores ou um nível acima do mais alto já empregado, como forma de comprovar maturidade para uso do nível selecionado. Observa-se que um nível só é considerado como já empregado em um projeto após o usuário declarar a sua conclusão. Ao optar por empregar o PSP, no menu principal do SAGP é exibido um item adicional, conforme ilustrado na Figura 3.9, por meio do qual o usuário poderá acessar sua Área exclusiva, onde somente ele terá acesso para fazer uso das ferramentas de apoio ao PSP disponíveis. É importante destacar que na Área exclusiva os usuários definirão os programas que deverão desenvolver e as atividades pessoais envolvidas na construção desses programas. Por sua vez, os programas serão definidos com base nas atividades do projeto às quais os usuários estão alocados.

71 55 Figura Menu principal do SAGP com destaque para os itens relacionados ao PSP Nível 0 Quando o usuário acessa sua Área exclusiva, é exibida a página inicial do sistema, ilustrada na Figura 3.10, a qual apresenta apenas alguns dados gerais sobre sua experiência no PSP. Ainda na Figura 3.10, é possível visualizar também as opções que o menu principal oferece ao usuário. Como se pode notar, a terminologia usada no sistema é completamente alinhada ao PSP, o que torna mais fácil o emprego por usuários que já conhecem o processo e, por outro lado, facilita o aprendizado dos conceitos por usuários iniciantes.

72 56 Figura Página inicial da Área exclusiva - Nível 0 Seguindo as diretrizes propostas pelo PSP, o emprego de todas as funções de apoio disponibilizadas no SAGP é baseado nos programas que o usuário cadastra. O cadastro de programas é feito por meio da página ilustrada na Figura Os únicos dados solicitados são o título do programa, a atividade do projeto ao qual se relaciona e a linguagem em que será desenvolvido, a qual pode ser selecionada caso já tenha sido utilizada anteriormente, agilizando o preenchimento do cadastro. Outra facilidade que o sistema fornece é a apresentação das atividades do projeto às quais o usuário está alocado, o que o direciona na definição dos programas que deverá construir. Ao passar o cursor do mouse sobre o nome de uma atividade, informações sobre ela são exibidas, conforme é ilustrado na Figura 3.11.

73 57 Figura Página para cadastro de programas Os programas registrados podem ser consultados, alterados e excluídos por meio de uma única página, ilustrada na Figura 3.12, que possibilita também registrar a conclusão dos programas. Esta forma de execução das operações evita a necessidade de troca de páginas, o que facilita o trabalho dos usuários do sistema. Figura Página para gerenciamento de programas Após cadastrar um ou mais programas, o usuário deve definir as atividades envolvidas na construção de cada um. Para tanto, primeiramente deve ser selecionado o programa para o

74 58 qual é desejado definir as atividades, o que é feito pela página ilustrada na Figura Ao selecionar o programa, é exibida a página de definição de atividades, ilustrada na Figura 3.14, a partir da qual o usuário pode também importar atividades, tornando o cadastro mais rápido. Figura Página para seleção de programas Figura Página para definição de atividades

75 59 As operações de consulta, alteração, exclusão e registro de conclusão das atividades são feitas por uma página de gerenciamento de atividades semelhante à de gerenciamento de programas, já apresentada na Figura Para registrar os dados sobre o tempo de execução das atividades, o usuário deve selecionar o programa sobre o qual irá atuar e, em seguida, a atividade que iniciará a execução. Feito isso, o sistema abrirá, em uma janela de pop-up, o Time Recording Log, cuja operação é especificada no diagrama de estados da Figura Observa-se que as figuras 3.16a, 3.16b e 3.16c representam as telas associadas aos estados que as referenciam entre parênteses. Figura 3.15 Diagrama de estados representando o funcionamento do Time Recording Log Figura 3.16 Telas associadas aos estados do Time Recording Log

76 60 Para empregar o Defect Recording Log, o usuário deve inicialmente selecionar o programa para o qual deseja registrar os defeitos. Feito isso, o sistema exibirá a página ilustrada na Figura 3.17, que apresenta os dados sobre os defeitos já registrados e permite registrar dados de novos defeitos com o auxílio de um cronômetro controlado pelos botões "Play/Pause" e "Limpar", bem como por teclas de atalho. Ao encontrar um defeito e iniciar sua correção, o usuário deve iniciar a marcação de tempo pelo cronômetro. Assim que concluir a correção, o usuário deve interromper o cronômetro e registrar os dados solicitados, podendo, logo após o preenchimento, iniciar novamente o cronômetro para registrar o tempo de correção de outro defeito. Figura 3.17 Defect Recording Log O Defect Recording Log oferecido pelo sistema permite que o usuário interrompa a correção de um defeito A para corrigir um defeito B e depois retorne à correção do defeito A. Para tanto, antes de submeter o formulário com os registros de cada rodada, basta que o usuário digite um mesmo número natural maior que zero no campo Identificador nas rodadas referentes a um mesmo defeito. Deste modo, o sistema registra as várias rodadas de mesmo identificador como um único defeito, cujo tempo de correção é dado pela soma do tempo das rodadas. No exemplo da Figura 3.17, as rodadas 2 e 4 serão registradas como um

77 61 único defeito com tempo de correção de 15 minutos, enquanto as demais serão registradas cada uma como um defeito. Os autores de programas que empregam o PSP também podem enviar seus programas para que outros membros de equipe do projeto realizem testes. Na Figura 3.18, é apresentado um diagrama de atividades que especifica a sequência de interações relacionadas ao envio de programas para testes. Neste diagrama, interagem o autor de um programa que emprega o PSP, o sistema, e um testador, que pode ser qualquer membro da equipe do projeto responsável pela realização de testes. Observa-se que nas Figuras 3.19 e 3.20 são representadas as telas associadas às interações que as referenciam entre parênteses no diagrama de atividades. Cabe destacar que mesmo os testadores que não empregam o PSP usam o Defect Recording Log para declarar os defeitos encontrados nos programas, uma vez que a página para recebimento de programas para teste é acessível pelo menu principal do SAGP na área de conhecimento de Qualidade, não dependendo, portanto, de acesso à Área exclusiva do PSP. Os dados sobre os defeitos encontrados pelos testadores são registrados entre os dados dos autores desses programas, de modo a viabilizar a geração de indicadores de qualidade. Figura 3.18 Diagrama de atividades referente ao envio de programas para teste

78 62 Figura 3.19 Página de envio de programa para teste Figura 3.20 Página para recebimento de programa para teste Sempre que solicitado pelos usuários, todas as informações registradas sobre os programas são reunidas e organizadas para a geração do Sumário do Plano de Projeto do PSP 0, ilustrado na Figura 3.21, o que permite ao usuário fazer uma análise geral dos dados obtidos. Além da geração do Sumário do Plano de Projeto, nos seis níveis do PSP é possível exportar todos os dados sobre os programas para relatórios em formato PDF, o que facilita a análise, acompanhamento e distribuição das informações.

79 63 Figura 3.21 Sumário do Plano de Projeto - PSP 0 Por fim, o sistema disponibiliza também os scripts do PSP 0 e mensagens de ajuda oferecidas pelos links Saiba mais, de modo a guiar os usuários ao longo do PSP 0 e a auxiliá-los no preenchimento de formulários Nível 0.1 Ao acessar a Área exclusiva empregando o nível 0.1 do PSP, as primeiras mudanças podem ser notadas já no menu principal e na página inicial, conforme ilustrado na Figura Em relação ao menu, são incluídos os itens referentes ao nível 0.1 do PSP. Quanto à página inicial, são disponibilizados os indicadores de produtividade e densidade de defeitos para cada linguagem empregada pelo usuário. A produtividade é dada em número de linhas de código por hora e seu cálculo é feito usando os dados de tamanho que o usuário passa a registrar no nível 0.1. Já a densidade de defeitos é dada em número de defeitos produzido por KLOC e seu cálculo baseia-se nos registros do Defect Recording Log.

80 64 Figura Página inicial da Área exclusiva - Nível 0.1 O primeiro item disponibilizado no menu é o cadastro de propostas no Process Improvement Proposal, feito por meio da página ilustrada na Figura As consultas às propostas cadastradas podem ser feitas por palavras ou parte de palavras constantes nos campos "Processos relacionados", "Descrição do problema" e "Descrição da proposta".

81 65 Figura Página de cadastro de propostas no Process Improvement Proposal No nível 0.1 é disponibilizado também o cadastro de padrões de codificação, que deve ser feito por meio da página ilustrada na Figura 3.24, que solicita o nome da linguagem para a qual o padrão será cadastrado e fornece o campo para o upload do arquivo contendo o padrão definido. Além disso, para auxiliar o entendimento dos usuários, essa página fornece exemplos reais de padrões de codificação propostos para as linguagens C, Java e PHP. Outra função disponibilizada nesse nível é o registro e consulta do tamanho de programas, que devem ser feitos pela página ilustrada na Figura 3.25 após a seleção do programa desejado. Observa-se que a obtenção e classificação dos dados de tamanho de programas podem ser facilitadas com o uso de ferramentas de comparação de código gratuitamente encontradas na internet para download ou acesso online.

82 66 Figura Página de cadastro de padrão de codificação Figura Página para registro e consulta do tamanho de programas

83 67 Ainda no nível 0.1, o usuário pode consultar a densidade de defeitos por programa, sendo possível visualizar o número de defeitos produzido por KLOC em cada fase de desenvolvimento de cada programa. A página exibida ao usuário contempla os mesmos dados relativos à densidade de defeitos apresentados na página inicial da área exclusiva (vide Figura 3.22). Por fim, o usuário pode ainda consultar os scripts fornecidos pelo nível 0.1 do PSP, bem como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na Figura 3.21, o qual acrescenta apenas as informações sobre o tamanho dos programas em relação ao sumário do PSP Nível 1 O suporte oferecido ao nível 1 do PSP contribui para otimizar a efetivação de tarefas a serem executadas pelos usuários, uma vez que automatiza uma quantidade significativa de cálculos complexos e organiza um grande volume de dados de maneira transparente ao usuário, que, com isso, pode concentrar-se em questões relacionadas ao desenvolvimento de programas, fornecendo dados facilmente obtidos. Conforme proposto pelo PSP, o primeiro passo para empregar o nível 1 consiste em definir um proxy para cada linguagem de programação utilizada, o que pode ser feito pela página ilustrada na Figura As operações de consulta, alteração e exclusão dos proxies são feitas por uma página de gerenciamento de proxies semelhante à de gerenciamento de programas, já apresentada na Figura Figura Página para definição de proxy Após a definição do proxy, devem ser estabelecidas suas categorias funcionais, o que é feito pela página ilustrada na Figura 3.27, que permite também excluir categorias estabelecidas.

84 68 Figura Página para registro de categorias funcionais O próximo passo consiste em registrar dados históricos de tamanho de proxy por meio da página ilustrada na Figura Esses dados devem ser mensurados em programas já construídos para a criação de uma base histórica que permita gerar a tabela de tamanho relativo, ilustrada na Figura Além de os dados históricos serem úteis para a geração da tabela de tamanho relativo, eles serão usados também como base para a avaliação do proxy, que permite verificar se o proxy definido representa adequadamente o esforço demandado para o desenvolvimento dos programas. Essa avaliação é feita em duas etapas: desconsiderar/excluir dados considerados outliers, que, portanto, não deverão constar na avaliação. Essa etapa deve ser executada pela página ilustrada na Figura 3.30; analisar os resultados da avaliação, que considera a correlação e significância dos dados de tamanho e tempo de desenvolvimento dos programas. A página com a exibição dos resultados da avaliação está ilustrada na Figura Como se pode observar, além das considerações sobre a correlação e significância, é apresentado um gráfico ao usuário, o qual auxilia na determinação dos pontos com comportamentos diferenciados dos demais, podendo indicar que se tratam de outliers e, portanto, devem ser desconsiderados para que a avaliação apresente resultados corretos.

85 69 Figura Página para registro de tamanho de proxies Figura Tabela de tamanho relativo gerada pelo sistema

86 70 Figura Página para registro de tamanho de proxies Figura Resultado da avaliação do proxy

87 71 A partir dos dados de proxies, podem ser feitas as estimativas de tamanho e tempo dos programas usando o método PROBE. Para tanto, inicialmente deve ser feito o preenchimento do formulário de estimativa de tamanho, ilustrado na Figura Após a submissão deste formulário, o usuário é redirecionado para a página ilustrada na Figura 3.33, o Size Estimating Template, que executa automaticamente o método PROBE, desde a escolha dos métodos para estimativa de tamanho e tempo até a execução de cada um dos métodos. Além disso, é calculado também o intervalo de previsão de 70% para as estimativas realizadas e, ao término de todos os cálculos, uma planilha resumindo os resultados obtidos é apresentada ao usuário. Observa-se que quando o método D é o adequado para a estimativa de tamanho e/ou tempo, o sistema solicita o preenchimento dos parâmetros de regressão β 0(size) e β 1(size) e/ou β 0(time) e β 1(time). Figura Página de registro de dados para estimativa de tamanho de programas

88 72 Figura Size Estimating Template Com base nas estimativas geradas para um programa, o usuário deve planejar o tempo de duração de cada atividade relacionada, o que é feito pela página exibida na Figura Conforme proposto pelo PSP, o tempo de duração total das atividades não deve ultrapassar o tempo de desenvolvimento estimado pelo método PROBE acrescido do intervalo de previsão.

89 73 Figura Página de gerenciamento de atividades com campo para estimativa de tempo de cada atividade Ao concluir o desenvolvimento de um programa, o usuário deve acessar a página ilustrada na Figura 3.35 para registrar o seu tamanho real. Esses dados são utilizados para alimentar a base de dados históricos sobre o tamanho dos proxies, o que leva a atualização da avaliação do proxies e da tabela de tamanho relativo. Ainda no nível 1, o usuário pode também empregar o Test Report Template. O registro de testes planejados/executados é realizado na página ilustrada na Figura As operações de consulta, alteração e exclusão podem ser realizadas por uma página de gerenciamento de testes semelhante à de gerenciamento de programas, já apresentada na Figura Por fim, o usuário pode consultar os scripts fornecidos pelo nível 1 do PSP, bem como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na Figura 3.21, o qual acrescenta apenas as informações sobre o tamanho e tempo planejados para os programas em relação ao sumário do PSP 0.1.

90 74 Figura Página para registro do tamanho real dos programas Figura Página para registro testes planejados/executados

91 Nível 1.1 O suporte oferecido ao nível 1.1 do PSP permite que os usuários do sistema elaborem rapidamente seus planos pessoais de trabalho. O primeiro passo para o planejamento pessoal consiste em estimar a duração das atividades, o que é feito pela página ilustrada na Figura Como é possível verificar, para direcionar a definição do tempo o sistema aponta a duração das fases às quais as atividades pertencem. Para tanto, baseando-se no valor do campo To Date % do Sumário do Plano de Projeto, é feita a distribuição do tempo total estimado pelo método PROBE para construção do programa. Embora o sistema aponte a duração das fases, não é obrigatório que o somatório da duração das atividades de uma fase tenha o valor apontado. Figura 3.37 Página para estimativa do tempo de duração das atividades de um programa Após a estimativa do tempo de duração das atividades, deve-se definir a ordem de construção dos programas, o que é feito pela página ilustrada na Figura Em seguida, por meio da página ilustrada na Figura 3.39, deve-se ordenar as atividades envolvidas na construção de cada programa. Observa-se que, após a ordenação, novos programas ou atividades que forem cadastrados são lançados ao final da ordenação pré-estabelecida, embora os usuários possam reordená-los.

92 76 Figura 3.38 Página para ordenação de programas Figura 3.39 Página para ordenação de atividades A última etapa do planejamento pessoal é executada automaticamente. Nessa etapa, o sistema reúne três informações: tempo de duração estimado para as atividades pessoais;

93 77 ordem de execução das atividades pessoais; tempo de alocação às atividades do projeto, que equivale à disponibilidade dos usuários. Com base nessas informações, é gerado o Schedule Planning Template e o Task Planning Template, ilustrados nas figuras 3.40 e 3.41, respectivamente. É importante destacar que, além de gerar a tabela do Task Planning Template, o sistema gera também o diagrama de Gantt correspondente, o que auxilia os usuários na gestão pessoal do tempo. Outro ponto importante a ser considerado é que os indicadores EV e PV são gerenciados automaticamente pelo sistema, com base no registro de conclusão das atividades pessoais. Além disso, o sistema confronta o tempo de disponibilidade dos usuários com o tempo estimado para realizar as atividades, o que permite apontar potenciais atrasos que deverão ocorrer no projeto. Esse apontamento é feito na tabela do Task Planning Template, no diagrama de Gantt - não são apresentadas as barras correspondentes às atividades para as quais se estima insuficiência de tempo, bem como na matriz apresentada ao final da página do Task Planning Template. Por meio do apontamento dos potenciais atrasos, os usuários do PSP podem constatar a necessidade de serem alocados por um tempo maior às atividades do projeto. Figura 3.40 Schedule Planning Template

94 78 Figura 3.41 Task Planning Template a

95 79 Por fim, o usuário pode consultar os scripts fornecidos pelo nível 1.1 do PSP, bem como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na Figura 3.21, o qual acrescenta apenas alguns indicadores em relação ao sumário do PSP Nível 2 O suporte oferecido ao nível 2 do PSP permite que os usuários do sistema empreguem facilmente os checklists de revisão de código e projeto e gerem rapidamente os indicadores de qualidade propostos. Na Figura 3.42, é ilustrada a página para cadastro do checklist de revisão de código, cujos tópicos podem também ser consultados, alterados e excluídos. Observa-se que para cada linguagem de programação deve ser cadastrado um checklist de revisão de código. Quanto ao checklist de revisão de projeto, seus tópicos não precisam ser cadastrados, uma vez que são propostos pelo PSP e são independentes da linguagem de programação adotada. Figura 3.42 Página para cadastro do checklist de revisão de código Para empregar os checklists de revisão de código ou de projeto, primeiramente o usuário deve selecionar o programa que deseja revisar e, em seguida, selecionar os campos já verificados, conforme ilustrado na Figura Deste modo, o usuário consegue controlar as verificações já realizadas.

96 80 Figura 3.43 Página para emprego do checklist de revisão de código Além de apoiar as revisões, o sistema gera automaticamente todos os indicadores propostos pelo PSP 2, os quais são exibidos na forma de um painel para cada linguagem de programação empregada. Junto a cada indicador, é disponibilizado um link Saiba Mais com informações explicativas. Na Figura 3.44, é ilustrada a primeira parte do painel gerado pelo sistema, a qual apresenta os indicadores considerando a média de todos os dados históricos registrados pelo usuário ao longo do emprego do PSP. Já na Figura 3.45, é ilustrada a segunda parte do painel, a qual apresenta a evolução dos indicadores ao longo dos projetos executados com o emprego do PSP. É importante destacar que a visão evolutiva dos indicadores pode contribuir sobremaneira para a constatação do impacto de mudanças no processo.

97 Figura 3.44 Indicadores gerais de qualidade 81

98 Figura 3.45 Evolução dos indicadores de qualidade 82

99 83 Por fim, o usuário pode consultar os scripts fornecidos pelo nível 2 do PSP, bem como acessar o Sumário do Plano de Projeto deste nível, de maneira semelhante ao ilustrado na Figura 3.21, o qual acrescenta apenas alguns indicadores e o planejamento de defeitos por fase, calculado automaticamente com base no tamanho estimado para o programa, na produção de defeitos por KLOC e no valor do To Date % Nível 2.1 O suporte oferecido ao nível 2.1 do PSP permite que os usuários do sistema empreguem facilmente os modelos de especificação de projeto e o checklist de revisão de projeto detalhado. Para empregar os modelos de especificação de projeto, o usuário deve primeiramente selecionar o programa que deseja especificar. Nas figuras 3.46, 3.47, 3.48 e 3.49 são ilustradas, respectivamente, as páginas para cadastro dos modelos de especificação operacional, funcional, de estados e lógica. Tais modelos podem também ser consultados, alterados e excluídos. Figura 3.46 Página para cadastro do modelo de especificação operacional

100 84 Figura 3.47 Página para cadastro do modelo de especificação funcional Figura 3.48 Página para cadastro do modelo de especificação de estados Figura 3.49 Página para cadastro do modelo de especificação lógica

101 85 Em relação ao checklist de revisão de projeto, a única mudança ocorrida foi a inclusão de dois tópicos a serem verificados: Análise de estados e Uso de prova matemática para verificação da lógica. Por fim, o usuário pode consultar os scripts fornecidos pelo nível 2.1 do PSP, bem como acessar o Sumário do Plano de Projeto deste nível de maneira semelhante ao ilustrado na Figura Indicadores oriundos do emprego individual do PSP A partir do emprego individual do PSP, o sistema permite a geração de informações que podem auxiliar nas atividades de gerenciamento de projetos. Tais informações são disponibilizadas aos gerentes de projeto e aos usuários de nível 2. Na Figura 3.50, é ilustrada a página inicial do SAGP, com destaque para os links do menu principal que dão acesso aos indicadores oriundos do PSP. Como se pode verificar, podem ser gerados indicadores relacionados a equipes, à formação de rankings e à gestão de tempo. Em relação aos indicadores sobre equipes, o sistema permite gerar os indicadores de um determinado conjunto de recursos humanos, de modo a verificar quais recursos levam à composição de uma equipe com o perfil mais próximo ao de interesse. Para tanto, os usuários devem, primeiramente, acessar a página ilustrada na Figura Por meio dessa página, os usuários podem selecionar os recursos humanos sobre os quais desejam visualizar indicadores. Essa seleção pode ser precedida por uma busca capaz de considerar a disponibilidade dos recursos em determinado período de interesse, o que é especialmente útil quando se deseja formar uma equipe de trabalho, já que é necessário que ele esteja disponível quando necessário.

102 86 Figura 3.50 Menu principal do SAGP com destaque para os itens relacionados aos indicadores do PSP

103 87 Figura 3.51 Página para geração de indicadores por equipe Após a seleção dos recursos humanos, deve-se selecionar a linguagem de programação para a qual se deseja visualizar os indicadores. Feito isso, o sistema pode gerar dois tipos de painel: se for selecionado apenas um recurso humano, é gerado um painel constituído pelos indicadores gerais e evolutivos deste recurso, com as mesmas informações e estrutura ilustradas nas figuras 3.44 e 3.45, incluindo apenas a apresentação do percentual de tempo que o recurso humano gasta com interrupções; se for selecionado mais de um recurso humano, é gerado um painel constituído apenas pela média de cada indicador geral dos recursos, com as mesmas informações e estrutura ilustradas na Figura 3.44, incluindo apenas a apresentação do percentual de tempo médio que os recursos humanos gastam com interrupções. Observa-se que, caso um ou mais recursos não tenham dados para a geração de um indicador, o sistema aponta o nome desses recursos logo abaixo do gráfico correspondente ao indicador. Em relação à geração de ranking, o sistema permite classificar os recursos humanos considerando cada um dos indicadores de qualidade do PSP, o que pode ser útil para a

104 88 aplicação de políticas de bonificação. Para tanto, o usuário deve acessar a página ilustrada na Figura Por meio dessa página, o usuário pode selecionar se deseja gerar o ranking considerando os dados de todos os projetos ou apenas do projeto atual, bem como o indicador e a linguagem de programação a ser considerada. Além disso, também é possível realizar uma busca considerando a disponibilidade dos recursos humanos antes de gerar o ranking. Figura 3.52 Página para geração de rankings sobre os indicadores do PSP O sistema permite também que os usuários visualizem indicadores de tempo referentes a cada atividade do projeto. O funcionamento dessa função baseia-se no fato de que cada programa que um usuário do PSP constrói está relacionado a uma atividade do projeto à qual ele está alocado. O primeiro passo para geração das informações é a seleção ou busca da atividade de interesse, o que pode ser feito por meio da página ilustrada na Figura Como pode ser visto, já nessa página é exibido o progresso registrado para as atividades do projeto e

105 89 o progresso estimado automaticamente pelo sistema com base no progresso das atividades pessoais. Quando um ou mais usuários alocados a uma atividade não empregam o PSP, o progresso não pode ser estimado e, então, é exibido apenas #. Figura 3.53 Página para seleção de atividades para geração de indicadores de tempo Após a seleção de uma das atividades, é exibida a página ilustrada na Figura 3.54, que apresenta as seguintes informações sobre cada recurso humano vinculado à atividade: nível no PSP: nível do recurso humano no PSP. Quanto maior o nível, maior a qualidade das estimativas pessoais; tempo de alocação à atividade: tempo de alocação do recurso humano à atividade; tempo estimado pelo usuário: tempo estimado pelo recurso humano para desenvolver sua parte da atividade; diferença: diferença percentual do tempo de alocação à atividade estimada pelo gerente e pelo próprio recurso humano. Valores positivos indicam que o recurso está alocado por mais tempo do que considera necessário. Valores negativos indicam o oposto; desvio médio: diferença percentual média entre o tempo planejado pelo usuário e o tempo realmente gasto por ele para executar uma atividade. Valores positivos indicam que o recurso, em média, estima que precisará de mais tempo do que realmente utiliza para executar uma atividade. Valores negativos indicam o oposto; tempo real consumido: tempo já utilizado para a execução da atividade; % concluído: percentual da atividade já concluído pelo recurso humano, o qual é calculado de acordo com a técnica da análise de valor agregado.

106 90 Figura 3.54 Página para exibição dos indicadores de tempo Após a listagem do último recurso humano na tabela, é apresentado o percentual concluído da atividade, que é calculado automaticamente pelo sistema por meio de uma média ponderada. No cálculo, considera-se como elementos os percentuais concluídos pelos recursos humanos, enquanto os pesos são os tempos de alocação à atividade. Observa-se que o tempo de alocação à atividade foi considerado como peso, pois é proporcional à carga de trabalho que se espera de cada recurso. Por meio das informações fornecidas pela página ilustrada na Figura 3.54, os responsáveis pelo projeto podem decidir atualizar o progresso da atividade, o que pode ser feito pelo link Atualizar progresso. Além disso, baseando-se em todas as informações apresentadas na tabela, pode-se decidir aumentar ou diminuir o tempo de alocação dos recursos humanos, o que pode ser feito pela própria página.

107 Considerações finais Neste capítulo, foi apresentada toda a construção do componente de apoio ao PSP, abordando desde a identificação de requisitos, até a apresentação do funcionamento do componente implementado. Com isso, foi possível observar que o sistema proposto contempla uma ampla quantidade de funções, que permitem o emprego rápido e adequado de todos os elementos do PSP, além de gerar informações capazes apoiar o gerenciamento de projetos. Outro aspecto importante do componente construído é a disponibilização de textos de ajuda, especialmente úteis para usuários com pouco conhecimento sobre o PSP.

108 92 CAPÍTULO 4 Avaliação dos Resultados 4.1 Considerações iniciais O objetivo deste capítulo é apresentar a avaliação das novas funções de apoio ao PSP incorporadas ao SAGP por meio do componente Gestão pessoal. Na seção 4.2 é apresentada uma análise comparativa entre o sistema proposto e algumas ferramentas de apoio ao PSP disponíveis no mercado. Na seção 4.3 é apresentada uma avaliação do sistema por um grupo de 22 usuários com diferentes níveis de experiência em desenvolvimento de software, permitindo identificar sua abrangência, bem como o apoio fornecido ao aprendizado de conceitos relacionados ao PSP. Por fim, na seção 4.4 são apresentadas as considerações finais deste capítulo. 4.2 Análise comparativa de ferramentas de apoio ao PSP A análise comparativa considerou o SAGP e outras seis ferramentas de apoio ao PSP disponíveis no mercado. A seleção dessas ferramentas buscou contemplar as mais citadas em artigos consultados durante o estudo de trabalhos relacionados. Além disso, foram selecionadas apenas aquelas sobre as quais foram encontradas informações suficientes para a realização da análise. Seguindo esses critérios, foram selecionadas as seguintes ferramentas: Process Dashboard: ferramenta open-source, cujo projeto é financiado pela Tuma Solutions (TUMA SOLUTIONS, 2012); Jasmine: ferramenta desenvolvida pela Escola de Engenharia da Information and Communications University, na Coréia do Sul (SHIN; CHOI; BAIK et al. 2007);

109 93 Hackystat: ferramenta open-source, desenvolvida para apoiar a coleta e análise de dados necessários a diversas metodologias de desenvolvimento de software, não sendo exclusiva para o PSP (JOHNSON et al., 2005); PSP Assistant (PSPA): ferramenta desenvolvida pela Faculdade de Estudos de Computação na De La Salle University, nas Filipinas (SISON et al., 2005); PSP.NET: ferramenta desenvolvida pela Faculdade de Ciência da Computação e Tecnologia da Informação na University of Malaya, na Malásia (NASIR; YUSOF, 2005); Plug-in Eclipse: ferramenta open-source que pode ser instalada no ambiente de programação Eclipse para apoiar a coleta e análise de dados de interesse ao emprego do PSP (YUAN et al., 2005). Após a seleção das ferramentas, foram definidos os quesitos a serem analisados, os quais buscaram avaliar o apoio ao emprego dos elementos e práticas de cada nível do PSP. Tais quesitos foram avaliados por meio de uma análise observacional realizada por um membro da equipe do GEPES não envolvido no desenvolvimento do componente de apoio ao PSP integrado ao SAGP, o que garantiu uma avaliação imparcial dos sistemas. Para a atribuição de uma qualificação, foi considerada uma escala de 0 a 100%, variando de 25 em 25%, conforme a cobertura das ferramentas aos itens considerados. Na Tabela 4.1, é apresentado o resultado da avaliação. Como se pode verificar, em geral o SAGP apresenta cobertura igual ou melhor que as demais ferramentas avaliadas. Um dos pontos de destaque identificados é que a maioria das ferramentas oferece pouco ou nenhum apoio ao PSP 1, que pode ser considerado um dos níveis mais importantes, uma vez que permite a obtenção de estimativas de tamanho e tempo de desenvolvimento de software muito precisas. Além disso, apenas a ferramenta PSP.NET aborda o nível 2.1, que também é de grande importância por apoiar a qualidade dos projetos de software. Em relação aos pontos em que o SAGP não obteve 100%, as principais deficiências observadas foram: 1. Registro do padrão de tipos de defeitos: o SAGP considera apenas os tipos de defeitos propostos pelo PSP, não permitindo o cadastro de outros itens; 2. Medição e classificação das linhas de código: o SAGP não mede e classifica automaticamente as LOCs dos programas construídos, tornando necessário o uso de outras ferramentas; 3. Registro das revisões de código e projeto: o SAGP considera apenas os itens propostos pelo PSP no checklist de revisão de projeto, não permitindo o cadastro

110 94 de adicionais. Em complemento aos resultados apresentados na Tabela 4.1, a análise realizada permitiu constatar que nenhuma das ferramentas é integrada a um ambiente de gerenciamento de projetos. Além disso, com exceção da PSPA e da PSP.NET, nenhuma das ferramentas exige autenticação dos usuários para o acesso, o que pode comprometer a privacidade dos usuários (ABBAS; AFZAL; AHMED, 2012). Tabela 4.1 Análise comparativa das ferramentas de apoio ao PSP Process Jasmine Hackystat PSPA PSP.NET Plug-in SAGP Dashboard Eclipse PSP 0 Registro de tempo e defeitos 100% 100% 100% 100% 100% 100% 100% Registro do padrão de tipos de defeitos Registro de padrão de codificação Medição e classificação das linhas de código Registro de propostas de melhoria do processo Geração automática das estimativas Registro de relatórios de teste Elaboração do Schedule Planning Template Elaboração do Task Planning Template Distribuição automática do tempo entre as fases do PSP Registro das revisões de código e projeto Geração dos indicadores de qualidade Estimativa de defeitos em cada fase Apoio à especificação de projeto 0% 75% 0% 0% 75% 0% 50% PSP 0.1 0% 0% 0% 0% 0% 0% 100% 100% 100% 100% 75% 75% 75% 50% 0% 0% 0% 100% 0% 0% 100% PSP 1 100% 25% 25% 25% 25% 0% 100% 0% 25% 0% 100% 50% 0% 100% PSP % 75% 0% 75% 75% 0% 100% 25% 75% 0% 75% 75% 0% 100% 0% 100% 0% 0% 100% 100% 100% PSP 2 75% 75% 25% 75% 25% 25% 75% 100% 75% 50% 50% 50% 50% 100% 75% 75% 0% 0% 75% 75% 100% PSP 2.1 0% 0% 0% 0% 100% 0% 100%

111 Visão dos usuários Esta etapa teve como objetivo analisar a visão dos usuários quanto à contribuição deste trabalho. Para tanto, em outubro de 2012 foi realizado no campus da Universidade Estadual Paulista (UNESP) de São José do Rio Preto um curso de 16 horas, que se dividiu em duas etapas. Na primeira etapa, que teve duração de 8 horas, foi ministrado um curso teórico, no qual foram abordados todos os elementos e práticas do PSP, de modo a garantir um conhecimento básico sobre o processo a todos os participantes do curso. Na segunda etapa, também com duração de 8 horas, foi apresentado o sistema de apoio ao emprego do PSP, abordando tanto a Área exclusiva que garante o acesso às funções de apoio ao PSP disponíveis, como as funções relacionadas aos indicadores para gerenciamento de projetos. O curso contou com 22 participantes, entre profissionais e alunos de graduação e pósgraduação da área de computação, sendo que nenhuma delas tinha conhecimento prévio sobre o PSP. Na Figura 4.1, é apresentado o perfil dos participantes quanto ao tempo de experiência em desenvolvimento de software, revelando a abrangência da amostra selecionada. Figura 4.1 Perfil dos participantes quanto ao tempo de experiência Ao término de cada uma das duas etapas do curso ministrado, foi aplicado um questionário online aos participantes. Observa-se que os participantes não foram identificados nos questionários, garantindo uma avaliação imparcial. Além disso, ao iniciar o segundo questionário, não era possível alterar as respostas do primeiro. No primeiro questionário, cada prática do PSP foi avaliada com base nos seguintes quesitos:

112 96 Compreensão: refere-se ao grau de entendimento de um elemento ou prática do PSP, quantificado em uma escala de 1 (pior entendimento) a 5 (melhor entendimento); Importância: refere-se ao grau de importância que o participante atribui a um elemento ou prática do PSP, quantificado em uma escala de 1 (menor importância) a 5 (maior importância); Dificuldade: refere-se ao grau de dificuldade que o usuário sentiu para empregar um elemento ou prática do PSP contando apenas com o apoio dos recursos que tem disponível, quantificado em uma escala de 1 (menor dificuldade) a 5 (maior dificuldade). Além desses quesitos, os participantes fizeram uma avaliação geral do PSP, julgando quatro assertivas quanto ao grau de concordância, quantificado numa escala de 1 (discordo plenamente) a 5 (concordo plenamente). As assertivas foram: O PSP me ajudaria no desenvolvimento de sistemas; Um desenvolvedor que não conhece o PSP pode aprender as práticas em pouco tempo; A simplicidade do PSP estimula seu uso; Pretendo usar o PSP em meu cotidiano. Por fim, foi deixado um campo aberto para o recebimento de comentários. Já o segundo questionário foi dividido em três partes, sendo a primeira para avaliar o apoio do SAGP às práticas do PSP; a segunda para averiguar o quanto os gerentes e membros de equipe dos projetos podem ser auxiliados pela integração das práticas do PSP ao ambiente de gerenciamento de projetos; e a terceira para avaliar aspectos gerais de qualidade da ferramenta. Assim, na primeira parte do questionário, foram reavaliadas a Compreensão e a Importância dos elementos ou práticas do PSP, bem como a concordância com as assertivas, de modo a constatar as diferenças da visão dos usuários antes e depois da apresentação do sistema desenvolvido. Além disso, foram avaliados também: Facilidade de uso: refere-se ao grau de facilidade que o usuário sentiu para empregar um elemento ou prática do PSP contando com o apoio do SAGP, quantificado em uma escala de 1 (menor facilidade) a 5 (maior facilidade); Aderência ao PSP: refere-se ao grau de proximidade entre elemento ou prática proposto pelo PSP e a abordagem oferecida pela ferramenta, considerando também a

113 completeza do apoio oferecido. Esse quesito também foi avaliado em uma escala de 1 (sem aderência) a 5 (totalmente aderente). 97 Na segunda parte do questionário, foram avaliados, em uma escala de 1 (pior avaliação) a 5 (melhor avaliação), os seguintes quesitos: Contribuição para o uso individual do PSP: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda cada recurso humano no emprego do PSP durante os projetos; Importância para o recrutamento de recursos humanos: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projeto a formarem suas equipes; Importância para o gerenciamento da equipe do projeto: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a monitorarem o desempenho dos recursos humanos e aplicarem políticas de incentivo; Importância para as estimativas de tempo: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a planejarem o tempo demandado para o desenvolvimento dos projetos; Importância para o controle do tempo: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a controlarem o andamento das atividades dos projetos; Importância para o planejamento da qualidade dos projetos: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos a planejarem a qualidade dos projetos; Importância para o controle da qualidade dos projetos: refere-se ao quanto a integração ao ambiente de gerenciamento de projetos ajuda os gerentes de projetos no controle da qualidade dos projetos; Importância dos indicadores gerados: refere-se ao grau de importância dos indicadores gerados pela ferramenta para os gerentes de projetos. Na terceira parte foram avaliados, em uma escala de 1 (menor) a 5 (maior), os seguintes aspectos de qualidade: Qualidade da interface: refere-se ao grau de atratividade da interface;

114 98 Organização das informações: refere-se à organização das informações na ferramenta e nos relatórios gerados; Frequência de falhas: refere-se à frequência de falhas ocorridas durante o uso da ferramenta. Salienta-se que, quanto maior a avaliação recebida, maior a frequência de falhas; Desempenho: refere-se à rapidez da ferramenta para a execução das solicitações; Portabilidade: refere-se à capacidade de uso da ferramenta em vários ambientes computacionais (sistemas operacionais e navegadores); Operacionalidade: refere-se à quantidade de recursos de ajuda oferecidos pela ferramenta, tais como textos de apoio, manuais e contato para suporte. Por fim, foi deixado um campo aberto para registro dos pontos fortes e outro para registro dos pontos fracos do sistema. No Gráfico 4.1, são apresentados os resultados obtidos com a avaliação do quesito Compreensão, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que houve uma melhoria significativa no entendimento dos elementos e práticas do PSP após a apresentação do SAGP. Isso permite afirmar que o sistema desenvolvido é capaz de contribuir para o aprendizado do processo, o que era um dos objetivos iniciais deste trabalho. No Gráfico 4.2, são apresentados os resultados obtidos com a avaliação do quesito Importância, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que houve um aumento da importância dos elementos e práticas do PSP após a apresentação do SAGP, o que permite afirmar que o sistema desenvolvido foi capaz de elucidar a contribuição do PSP, fato que pode contribuir sobremaneira para a implantação do referido processo em uma organização.

115 99 Gráfico 4.1 Avaliação da Compreensão dos elementos e práticas do PSP antes e depois da apresentação do SAGP Gráfico 4.2 Avaliação da Importância dos elementos e práticas do PSP antes e depois da apresentação do SAGP

116 100 No Gráfico 4.3, são apresentados os resultados obtidos com a avaliação do quesito Grau de dificuldade, abordado no primeiro questionário. Já o Gráfico 4.4 refere-se à Facilidade de uso, abordada no segundo questionário. Ao confrontar os dois gráficos, é possível notar que muitos elementos e práticas inicialmente considerados como sendo de difícil uso, passaram a ser avaliados como de fácil utilização, o que atesta o apoio fornecido para o emprego do PSP. Gráfico 4.3 Avaliação do Grau de dificuldade dos elementos e práticas do PSP antes da apresentação da ferramenta

117 101 Gráfico 4.4 Avaliação da Facilidade de uso dos elementos e práticas do PSP após a apresentação da ferramenta No Gráfico 4.5, são apresentados os resultados obtidos com a avaliação do grau de concordância quanto às quatro assertivas, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que houve um forte aumento da concordância quanto as assertivas, o que permite afirmar que os participantes sentiram-se mais interessados em empregar o PSP após a apresentação do sistema desenvolvido. Gráfico 4.5 Avaliação da concordância quanto às assertivas antes e depois da apresentação da ferramenta

118 102 No Gráfico 4.6, são apresentados os resultados obtidos com a avaliação do quesito Aderência ao PSP, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que a avaliação recebida foi muito boa, uma vez que a maioria dos quesitos recebeu avaliação média superior a 4,5. Gráfico 4.6 Avaliação da Aderência ao PSP No Gráfico 4.7, são apresentados os resultados obtidos com a avaliação da contribuição decorrente da integração do PSP ao ambiente de gerenciamento de projetos, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que a avaliação recebida foi muito boa, uma vez que todos os quesitos receberam avaliação média próxima a 4,5.

119 Gráfico 4.7 Avaliação da contribuição decorrente da integração do PSP ao ambiente de gerenciamento de projetos 103 No Gráfico 4.8, são apresentados os resultados obtidos com a avaliação dos aspectos de qualidade do sistema desenvolvido, considerando a média das notas atribuídas pelos participantes. Observando-se o gráfico, é possível constatar que, de maneira geral, a avaliação recebida foi muito boa. No entanto, a portabilidade, a organização das informações e a qualidade da interface podem ser melhoradas em projetos futuros. Cabe observar que, atualmente, o sistema opera apenas no navegador Mozilla Firefox, o que explica a avaliação mais baixa do quesito portabilidade. Quanto à frequência de falhas, embora a avaliação média recebida tenha sido boa (por ser baixa), todas as falhas foram corrigidas à medida que foram encontradas. Gráfico 4.8 Avaliação dos aspectos de qualidade do sistema

PERSONAL SOFTWARE PROCESS: UMA VISÃO GERAL SOBRE O PROCESSO E O SEU IMPACTO NA INDÚSTRIA DE SOFTWARE

PERSONAL SOFTWARE PROCESS: UMA VISÃO GERAL SOBRE O PROCESSO E O SEU IMPACTO NA INDÚSTRIA DE SOFTWARE PERSONAL SOFTWARE PROCESS: UMA VISÃO GERAL SOBRE O PROCESSO E O SEU IMPACTO NA INDÚSTRIA DE SOFTWARE PERSONAL SOFTWARE PROCESS: AN OVERVIEW OF THE PROCESS AND ITS IMPACT ON SOFTWARE INDUSTRY Antonio Marcos

Leia mais

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process

Capítulo 6: PSP. Capítulo 6: PSP Personal Software Process Capítulo 6: PSP Personal Software Process Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6: PSP

Leia mais

GESTÃO DE RECURSOS HUMANOS EM PROJETOS DE SOFTWARE: PROPOSTA INTEGRADA AO PROCESSO PESSOAL

GESTÃO DE RECURSOS HUMANOS EM PROJETOS DE SOFTWARE: PROPOSTA INTEGRADA AO PROCESSO PESSOAL GESTÃO DE RECURSOS HUMANOS EM PROJETOS DE SOFTWARE: PROPOSTA INTEGRADA AO PROCESSO PESSOAL ESTECA, Antonio Marcos Neves Universidade Estadual Paulista Júlio de Mesquita Filho (UNESP) am.esteca@sjrp.unesp.br

Leia mais

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK

Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK 180 - Encontro Anual de Tecnologia da Informação Sistema de Gerenciamento de Riscos em Projetos de TI Baseado no PMBOK Thiago Roberto Sarturi1, Evandro Preuss2 1 Pós-Graduação em Gestão de TI Universidade

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br

Engenharia de Software. Gerenciamento de Requisitos. Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Software Gerenciamento de Requisitos Prof. Rodolfo Miranda de Barros rodolfo@uel.br Engenharia de Requisitos (ER) Engenharia de O termo Engenharia implica em dizer que um processo sistemático

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

Padrões de Qualidade de Software e Métricas de Software

Padrões de Qualidade de Software e Métricas de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Requisitos para ferramentas de registro de defeitos de software

Requisitos para ferramentas de registro de defeitos de software Requisitos para ferramentas de registro de defeitos de software Alessandro Liebmam Departamento de Ciência da Computação Instituto de Ciências Exatas Universidade Federal de Minas Gerais (UFMG) CEP: 31270-010

Leia mais

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider

Ferramenta: Spider-CL. Manual do Usuário. Versão da Ferramenta: 1.1. www.ufpa.br/spider Ferramenta: Spider-CL Manual do Usuário Versão da Ferramenta: 1.1 www.ufpa.br/spider Histórico de Revisões Data Versão Descrição Autor 14/07/2009 1.0 15/07/2009 1.1 16/07/2009 1.2 20/05/2010 1.3 Preenchimento

Leia mais

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

Leia mais

Gerenciamento de Qualidade

Gerenciamento de Qualidade UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Qualidade Engenharia de Software 2o. Semestre de

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática

Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Programa de Pós-Graduação em Informática Disciplina: INF5008 Prof.: (monalessa@inf.ufes.br) Conteúdo 3. Gerência de

Leia mais

PSP Personal Software Process. MO409 Engenharia de Software I Bruno Abreu - RA 030020 Henrique Souza - RA 008876

PSP Personal Software Process. MO409 Engenharia de Software I Bruno Abreu - RA 030020 Henrique Souza - RA 008876 PSP Personal Software Process MO409 Engenharia de Software I Bruno Abreu - RA 030020 Henrique Souza - RA 008876 Setembro/2004 Introdução O PSP Origem 1989 Watts Humphrey Foco e objetivos Motivações Introdução

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Requisitos Cap. 06 e 07 Sommerville 8 ed. REQUISITOS DE SOFTWARE» Requisitos são descrições de serviços fornecidos pelo sistema e suas restrições operacionais. REQUISITOS DE USUÁRIOS: São

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis MBA em Gestão de Projetos Gerenciamento de Projetos Prática essencial para gerar negócios sustentáveis Prof: Ângelo Braga, PMP, MBA angelo.braga@fgv.br eu@angelobraga.com.br 2/154 Contatos Prof. Ângelo

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

FERRAMENTA CASE PARA GERENCIAMENTO DE PROJETOS E MÉTRICAS DE SOFTWARE

FERRAMENTA CASE PARA GERENCIAMENTO DE PROJETOS E MÉTRICAS DE SOFTWARE FERRAMENTA CASE PARA GERENCIAMENTO DE PROJETOS E MÉTRICAS DE SOFTWARE 1 UNIVERSIDADE DO VALE DO ITAJAÍ Centro de Ciências Tecnológicas da Terra e do Mar Rua Uruguai, 458 Centro Itajaí(SC) CEP: 88.302-202

Leia mais

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R ENCARTE R Estimativa de de Software Estimativa de de Software: Contratação de Serviços de Fábrica de Software Página 1 de 10 SUMÁRIO 1 REFERÊNCIAS... 3 1 INTRODUÇÃO... 3 3.1 ESTIMATIVA PRELIMINAR... 4

Leia mais

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos.

definido por um documento de padronização. A Fig. 1 representa a organização dos Grupos de Processos juntamente com os documentos exigidos. A GESTÃO DE PROJETOS EXISTENTE NA NORMA DO-178B Matheus da Silva Souza, matheusdasilvasouza@gmail.com Prof. Dr. Luiz Alberto Vieira Dias, vdias@ita.br Instituto Tecnológico de Aeronáutica Praça Marechal

Leia mais

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

O Gerenciamento de Projetos na abordagem do

O Gerenciamento de Projetos na abordagem do Seminário de Desenvolvimento de Gestores de Programas e Projetos Fórum QPC O Gerenciamento de Projetos na abordagem do PMI - Project Management Institute Marco Antônio Kappel Ribeiro Presidente do PMI-RS

Leia mais

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI)

F U N D A Ç Ã O E D U C A C I O N A L S Ã O J O S É. MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) 1 MODELOS DE MATURIDADE CMMI Capability Maturity Model Integration (CMMI) Teresinha Moreira de Magalhães 1 Lúcia Helena de Magalhães 2 Fernando Machado da Rocha 3 Resumo Este trabalho visa apresentar uma

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

Marcelo Novaes Coutinho. Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle. Dissertação de Mestrado

Marcelo Novaes Coutinho. Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle. Dissertação de Mestrado Marcelo Novaes Coutinho Um Processo de Gerência de Estratégia de Rastreabilidade: Um Caso em Ambiente Oracle Dissertação de Mestrado Dissertação apresentada como requisito parcial para obtenção do grau

Leia mais

Como concluir um projeto com sucesso?

Como concluir um projeto com sucesso? Como concluir um projeto com sucesso? Luiz Eduardo Cunha, Eng. Professor da FAAP e do IMT 1 Luiz Eduardo Cunha Graduado em Engenharia de Produção EPUSP Pós-Graduado em Gestão do Conhecimento e Inteligência

Leia mais

Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e

Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e JEANE MENDES DA SILVA SANTOS Um Framework para definição de processos de testes de software que atenda ao nível 3 do TMM-e Plano de Trabalho de Conclusão de Curso apresentado à Universidade Federal de

Leia mais

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow

Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Controle de métricas no processo de desenvolvimento de software através de uma ferramenta de workflow Gustavo Zanini Kantorski, Marcelo Lopes Kroth Centro de Processamento de Dados Universidade Federal

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS

SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS SISTEMA DE GESTÃO DE PROJETOS DE SOFTWARE - SGPS Lilian R. M. Paiva, Luciene C. Oliveira, Mariana D. Justino, Mateus S. Silva, Mylene L. Rodrigues Engenharia de Computação - Universidade de Uberaba (UNIUBE)

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Métricas de Software. Sistemas de Informação

Métricas de Software. Sistemas de Informação Métricas de Software Sistemas de Informação Objetivos Entender porque medição é importante para avaliação e garantia da qualidade de software Entender as abordagens principais de métricas e como elas são

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software

Ciência da Computação ENGENHARIA DE SOFTWARE. Análise dos Requisitos de Software Ciência da Computação ENGENHARIA DE SOFTWARE Análise dos Requisitos de Software Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução Tipos de requisitos Atividades Princípios da

Leia mais

Introdução à Qualidade de Software

Introdução à Qualidade de Software FACULDADE DOS GUARARAPES Introdução à Qualidade de Software www.romulocesar.com.br Prof. Rômulo César (romulodandrade@gmail.com) 1/41 Objetivo do Curso Apresentar os conceitos básicos sobre Qualidade de

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

04/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI. Prof.: Fernando Hadad Zaidan. Unidade 1.

04/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI. Prof.: Fernando Hadad Zaidan. Unidade 1. Faculdade INED Curso Superior de Tecnologia: Redes de Computadores Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan 1 Unidade 1.1 2 Introdução ao Gerenciamento de Projetos 3 1 Leitura

Leia mais

4. PMBOK - Project Management Body Of Knowledge

4. PMBOK - Project Management Body Of Knowledge 58 4. PMBOK - Project Management Body Of Knowledge No Brasil, as metodologias mais difundidas são, além do QL, o método Zopp, o Marco Lógico do Banco Interamericano de Desenvolvimento (BID) e o Mapp da

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

GERÊNCIA DE INTEGRAÇÃO DO PROJETO GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA

GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA SOBRE A CONSULTORIA Como realizar inúmeros projetos potenciais com recursos limitados? Nós lhe mostraremos a solução para este e outros

Leia mais

O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software

O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software O uso de métodos e normas na garantia de qualidade do processo de especificação de requisitos de software Maria Angela Coser (UTFPR/CEFETES) macoser@cefetes.br Helio Gomes de Carvalho (UTFPR) helio@utfpr.edu.br

Leia mais

Requisitos de Ferramentas de Gerenciamento de Configuração

Requisitos de Ferramentas de Gerenciamento de Configuração Requisitos de Ferramentas de Gerenciamento de Configuração Viviane Nogueira Pinto de Oliveira 1 1Departamento de Ciência da Computação Universidade Federal de Minas Gerais Av. Antônio Carlos, 6627 CEP

Leia mais

GESTÃO DA QUALIDADE DE SOFTWARE

GESTÃO DA QUALIDADE DE SOFTWARE GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida falmeida@ispgaya.pt Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP)

Leia mais

A Experiência de Melhoria do Processo do Instituto Atlântico Baseado no SW-CMM nível 2

A Experiência de Melhoria do Processo do Instituto Atlântico Baseado no SW-CMM nível 2 A Experiência de Melhoria do Processo do Instituto Atlântico Baseado no SW-CMM nível 2 Carlos Giovano Pires, Fabiana Marinho, Gabriela Telles, Arnaldo Belchior * Instituto Atlântico, Rua Chico Lemos, 946,

Leia mais

ATIVIDADES PRÁTICAS SUPERVISIONADAS

ATIVIDADES PRÁTICAS SUPERVISIONADAS ATIVIDADES PRÁTICAS SUPERVISIONADAS CST em Análise e Desenvolvimento de Sistemas 5ª. Série Programação e Design para Web A atividade prática supervisionada (ATPS) é um procedimento metodológico de ensino-aprendizagem

Leia mais

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia.

Na medida em que se cria um produto, o sistema de software, que será usado e mantido, nos aproximamos da engenharia. 1 Introdução aos Sistemas de Informação 2002 Aula 4 - Desenvolvimento de software e seus paradigmas Paradigmas de Desenvolvimento de Software Pode-se considerar 3 tipos de paradigmas que norteiam a atividade

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental

Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Proposta de um método para auditoria de projetos de desenvolvimento de software iterativo e incremental Francisco Xavier Freire Neto 1 ; Aristides Novelli Filho 2 Centro Estadual de Educação Tecnológica

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software

Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Ambiente de workflow para controle de métricas no processo de desenvolvimento de software Gustavo Zanini Kantorski, Marcelo Lopes Kroth Universidade Federal de Santa Maria (UFSM) 97100-000 Santa Maria

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

GERENCIAMENTO DE PROJETOS PROJECT MANAGEMENT INSTITUTE

GERENCIAMENTO DE PROJETOS PROJECT MANAGEMENT INSTITUTE GERENCIAMENTO DE PROJETOS PROJECT MANAGEMENT INSTITUTE O PMI e a Certificação PMP Visão Geral sobre o Modelo PMI APRESENTAÇÃO DO PMI O PMI - Project Management Institute é uma instituição sem fins lucrativos,

Leia mais

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum

Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Scrum-Half: Uma Ferramenta Web de Apoio ao Scrum Diego R. Marins 1,2, José A. Rodrigues Nt. 1, Geraldo B. Xexéo 2, Jano M. de Sousa 1 1 Programa de Engenharia de Sistemas e Computação - COPPE/UFRJ 2 Departamento

Leia mais

Gerenciamento de Integração do Projeto Planejamento e Execução do Projeto

Gerenciamento de Integração do Projeto Planejamento e Execução do Projeto Gerenciamento de Integração do Projeto Planejamento e Execução do Projeto 4. Gerenciamento de integração do projeto PMBOK 2000 PMBOK 2004 4.1 Desenvolver o termo de abertura do projeto 4.2 Desenvolver

Leia mais

Definição do Framework

Definição do Framework Definição do Framework 1. Introdução 1.1. Finalidade Este documento tem por finalidade apresentar o mapeamento dos processos de Definição de Processo Organizacional e Avaliação e Melhoria do Processo dos

Leia mais

Mapeamento GRH. 1. Introdução

Mapeamento GRH. 1. Introdução Mapeamento GRH 1. Introdução 1.1. Finalidade Este documento tem duas finalidades principais: a) Averiguar semelhanças e diferenças entre modelos, normas e guias de boas práticas para gestão de recursos

Leia mais

Gerenciamento de Projetos Modulo IV Integração

Gerenciamento de Projetos Modulo IV Integração Gerenciamento de Projetos Modulo IV Integração Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

[6.46] RiskFree: Uma Ferramenta para Gerência de Risco em Projetos de Software em conformidade com o nível 3 do modelo CMMI

[6.46] RiskFree: Uma Ferramenta para Gerência de Risco em Projetos de Software em conformidade com o nível 3 do modelo CMMI [6.46] RiskFree: Uma Ferramenta para Gerência de Risco em Projetos de Software em conformidade com o nível 3 do modelo CMMI Flávio Franco Knob, Filipi Pereira da Silveira, Afonso Inácio Orth, Rafael Prikladnicki

Leia mais

Aula Nº 06 Determinação do Orçamento

Aula Nº 06 Determinação do Orçamento Aula Nº 06 Determinação do Orçamento Objetivos da Aula: Os objetivos desta aula são, basicamente, apresentar os processos aplicados que possibilitem identificar os recursos necessários para se conduzir

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Certificação ISO 9001:2000 a Experiência da SoftExport

Certificação ISO 9001:2000 a Experiência da SoftExport Certificação ISO 9001:2000 a Experiência da SoftExport Raimundo Sales Neto e Azevedo 1, 2, Ana Cristina M.Matos 2, Marum Simão Filho 1, Flávio Lenz César 1, Arnaldo Dias Belchior 2 sales.mia@unifor.br,

Leia mais

- Project Management Institute. Disciplina de Engenharia de Software. PMP- Project Management Professional PMBOK

- Project Management Institute. Disciplina de Engenharia de Software. PMP- Project Management Professional PMBOK Disciplina de Engenharia de Software Material elaborado por Windson Viana de Carvalho e Rute Nogueira Pinto em 19/07/2004 Material alterado por Rossana Andrade em 22/04/2009 - Project Management Institute

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos GERÊNCIA DE INTEGRAÇÃO GERÊNCIA DO ESCOPO GERÊNCIA DO TEMPO GERÊNCIA DE CUSTO GERÊNCIA DA QUALIDADE Desenvolvimento do Plano

Leia mais

ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA

ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA ESTRUTURAÇÃO DOS PROCESSOS DE COMUNICAÇÃO EM PROJETOS, PROGRAMAS E PORTFÓLIOS CONSULTORIA SOBRE A CONSULTORIA Assegure melhores resultados em seus projetos com uma estrutura de comunicação simples, efetiva,

Leia mais

Normas para Apresentação de Monografias

Normas para Apresentação de Monografias UNIVERSIDADE FEDERAL DE CAMPINA GRANDE DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO COORDENAÇÃO DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Normas para Apresentação de Monografias Campina Grande, dezembro 2010

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes.

Com relação às áreas de conhecimento de projetos conforme o. PMBoK, julgue os itens subseqüentes. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 29 3.1 GERENCIAMENTO DO ESCOPO O Gerenciamento do Escopo do Projeto engloba os processos necessários para assegurar que o projeto inclua todas

Leia mais

PMBOK 4ª Edição I. Introdução

PMBOK 4ª Edição I. Introdução PMBOK 4ª Edição I Introdução 1 PMBOK 4ª Edição Um Guia do Conhecimento em Gerenciamento de Projetos Seção I A estrutura do gerenciamento de projetos 2 O que é o PMBOK? ( Project Management Body of Knowledge

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Carlos Alberto Rovedder, Gustavo Zanini Kantorski Curso de Sistemas de Informação Universidade Luterana do Brasil (ULBRA) Campus

Leia mais

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste

Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste Melhoria da Qualidade de Produto e de Processo de Software a partir da Análise de Indicadores de Teste ERIKA DE FREITAS NITA CI&T SYSTEMS S/A www.cit.com.br Resumo Atualmente, a maioria das empresas de

Leia mais

Relatório de Consultoria PD.33.10.83A.0080A/RT-05-AA. Levantamento da Gestão de TIC

Relatório de Consultoria PD.33.10.83A.0080A/RT-05-AA. Levantamento da Gestão de TIC Relatório de Consultoria PD.33.10.83A.0080A/RT-05-AA Levantamento da Gestão de TIC Cotação: 23424/09 Cliente: PRODABEL Contato: Carlos Bizzoto E-mail: cbizz@pbh.gov.br Endereço: Avenida Presidente Carlos

Leia mais

Essencial ao Desenvolvimento de Software

Essencial ao Desenvolvimento de Software Documento de Requisitos Essencial ao Desenvolvimento de Software De que se trata o artigo? Apresenta o documento de requisitos de software, destacando-o como um dos principais documentos pertinentes ao

Leia mais