INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA DO PAR PR-REITORIA DE EXTENSO DIRETORIA DE EDUCAO ABERTA E A DISTNCIA

TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS

GERENCIAMENTO DE DESENVOLVIMENTO DE SOFTWARE

PROF. MILTON ROBERTO GOMES CARDOSO

2011

SUMRIO
PLANO DE ENSINO APRESENTAO UNIDADE 1 CONCEITOS BSICOS 1. 2. 2.1 2.2 2.3 2.3.1 2.3.2 3. 3.1 3.2 4. INTRODUO CONCEITOS BSICOS DE GERENCIAMENTO DE PROJETOS QUAL A DIFERENA ENTRE PROJETOS E PROGRAMAS? O QUE UM PROJETO E QUAL O PESSOAL ENVOLVIDO NO PROJETO? QUAIS AS CARACTERTICAS DOS PROJETOS? Benefcios do Gerenciamento de Projetos Causas de fracassos em Projetos O CICLO DE VIDA DOS PROJETOS CARACTERSTICAS DO CICLO DE VIDA FASES DO CICLO DE VIDA AS NORMAS E OS ORGOS NORMATIVOS

UNIDADE 2 REAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS 1 2 2.1 2.1.1 2.1.2 2.2 2.2.1 2.2.2 2.3 2.3.1 2.3.2 2.4 2.4.1 2.4.2 2.5 2.5.1 2.5.2 2.6 2.6.1 2.6.2 2.7 2.7.1 2.7.2 2.8 PMBOK ATRAVS DE MAPAS MENTAIS (MINDMAPS) REAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS GERENCIAMENTO DA INTEGRAO Definio e Midmap do Gerenciamento da Integrao Plano Global do Projeto GERENCIAMENTO DE ESCOPO Definio e Midmap do Gerenciamento de Escopo Plano de Gerenciamento de Escopo GERENCIAMENTO DE TEMPO Definio e Midmap do Gerenciamento de Tempo Plano de Gerenciamento do Cronograma GERENCIAMENTO DE CUSTOS Definio e Midmap do Gerenciamento de Custos Plano de Gerenciamento de Custos GERENCIAMENTO DA QUALIDADE Definio e Midmap do Gerenciamento da Qualidade Plano de Gerenciamento da Qualidade GERENCIAMENTO DE RECURSOS HUMANOS Definio e Midmap do Gerenciamento de Recursos Humanos Plano de Gerenciamento de Pessoal GERENCIAMENTO DAS COMUNICAES Definio e Midmap do Gerenciamento das Comunicaes Plano de Gerenciamento das Comunicaes GERENCIAMENTO DE RISCOS

2.8.1 2.8.2 2.9 2.9.1 2.9.2

Definio e Midmap do Gerenciamento de Riscos Plano de Gerenciamento de Riscos GERENCIAMENTO DAS AQUISIES Definio e Midmap do Gerenciamento das Aquisies Plano de Gerenciamento das Aquisies

PARA SABER MAIS REFLEXES SOBRE A APRENDIZAGEM RESUMO DA UNIDADE SUGESTES DE LEITURA

UNIDADE 3 QUALIDADE DE SOFTWARE 1. 1.1 1.2 1.2.1 1.2.2 1.2.3 1.3 1.3.1 1.3.2 1.3.3 2. 2.1 2.2 2.2.1 3. 3.1 3.2 3.3 4. 4.1 5. 5.1 5.2 6. 7 7.1 O QUE QUALIDADE? DEFINIO DE DEFEITO E FALHA SWEBOK Fundamentos de Qualidade Processos de Gerenciamento de Qualidade de software: Consideraes prticas de Qualidade MTRICAS Viso geral (apndice A - qualidade de software) Mtricas Orientadas a Tamanho ou Funo Estatsticas prticas CONTRIBUIES HUMANAS A QUALIDADE NVEIS DE MATURIDADE DAS EMPRESAS PRTICAS DE EMPRESAS MADURAS Aplicao das prticas construo de Softwares NORMAS ISO/IEC ISO/IEC 15504 ISO/IEC 12207 ISO/IEC 25000 MODELO SW-CMM E CMMI SW-CMM ORIGEM E NVEIS MODELO BRASILEIRO MPS.BR ESTRUTURA DO MPS.BR NVEIS DO MPS.BR METODOLOGIAS GEIS ASPECTOS DA QUALIDADE E DA GARANTIA DA QUALIDADE DE SOFTWARE FATORES DA GARANTIA DA QUALIDADE DE SOFTWARE

PARA SABER MAIS REFLEXES SOBRE A APRENDIZAGEM RESUMO DA UNIDADE SUGESTES DE LEITURA

UNIDADE 4 TCNICAS E MODELOS DE PROJETO DE SOFTWARE 1 1.1 1.2 1.3 1.4 1.5 2. 2.1 2.2 2.3 2.4 2.5 ASPECTOS FUNDAMENTAIS DO PROJETO DE SOFTWARE ABSTRAO REFINAMENTO MODULARIDADE ARQUITETURA E HIERARQUIA DE CONTROLE DE SOFTWARE ESTRUTURA DE DADOS MODELOS DE PROJETOS DE SOFTWARE MODELO EM CASCATA MODELO EM V MODELO DE PROTOTIPAO MODELO DE DESENVOLVIMENTO POR FASES MODELO EM ESPIRAL

PARA SABER MAIS REFLEXES SOBRE A APRENDIZAGEM RESUMO DA UNIDADE SUGESTES DE LEITURA

CONSIDERAES FINAIS DA DISCIPLINA GUIA DIDTICO

UNIDADE 3 QUALIDADE DE SOFTWARE

OBJETIVOS DA UNIDADE Apresentar a importncia dos conceitos de qualidade para servir de base a aplicao e na anlise das caractersticas de um software dito de boa qualidade. Esclarecer o aluno que qualidade no algo sugestivo ou relativo, mas possui aspectos tcnicos de TI, padres internacionais a serem seguidos e respeitados. Apresentar as normas internacionais atravs de breves comentrios para no se tornar enfadonho o descobrimento da sua utilizao prtica. Estimular a percepo do aluno quanto ao modelo brasileiro de qualidade de software.

1 O QUE QUALIDADE?
A idia geral sobre qualidade quase intuitiva, mas no uma verdade. No devemos aceitar apenas o conceito contido no dicionrio de nossa lngua. Pelo contrrio, assim como organismos internacionais possuem inmeras equipes de pesquisa, ns tambm devemos nos esforar por adquirir conhecimento desta rea, cuja aplicao no desenvolvimento de softwares est relacionada ao uso de recomendaes, de mtricas e de estatsticas. A complexidade de um novo sistema de informaes medida pelo tamanho do, pelas especificaes, pelas solues apresentadas, pelo nmero de mdulos e suas interaes. A mudana tecnolgica vivenciada atualmente teve um efeito dramtico na produo de software. Com um avano dos recursos de hardware criaram-se diversas oportunidades de desenvolvimento de sistemas de informao com grau de complexidade cada vez maior, comprovando assim a unidade existente entre mquina (hardware) e aplicativos (software). Um aspecto importante nesse desenvolvimento de sistemas que os problemas so os mesmos de trinta anos atrs: - Cronogramas que no so observados; - Mdulos que no funcionam corretamente e no interagem entre si; - Abandono da pesquisa e de projeto de software por falta de recursos financeiros e qualificao dos programadores e desenvolvedores; - Aplicativos de difcil interao com o usurio e de difcil manuteno; - Aplicativos que interrompem o seu funcionamento por mudanas ou atualizaes de sistemas operacionais; Se no bastassem os exemplos citados acima, temos ainda a incluso de novos aspectos: - A demanda por aplicativos voltados ao ambiente da internet; - A demanda por aplicativos voltados a novos equipamentos individuais; - A popularidade de equipamentos voltados para o entretenimento, conectividade e mobilidade.

Este um cenrio desafiador para todos os desenvolvedores de software e sistemas de informao e automao. O que era futuro j chegou! Aps uma introduo a pergunta permanece: O que Qualidade? No dicionrio da lngua portuguesa Houasis, o termo se refere ao atributo que determina a essncia ou a natureza de algo ou de algum. E segue: caracterstica comum ou inerente a grupos de seres vivos ou a grupos de objetos. O conceito que mais se adqua a qualidade de software o segundo, por apresentar um aplicativo (o objeto) com caractersticas que podem ser agrupadas e, portanto podem ser medidas, parametrizadas e padronizadas. E uma vez que um software tem suas caractersticas padronizadas, os seus mdulos tambm podem servir de base para o desenvolvimento de outro software. exatamente o que presenciamos hoje em dia com a filosofia das licenas para softwares livres que nos d liberdade para: - Executar o programa, para qualquer propsito; - Estudar como o programa funciona e adapt-lo para as suas necessidades; - Acessar ao cdigo-fonte; - Redistribuir cpias do novo software informando o nome do software em que est baseado; - Aperfeioar o programa, e liberar os seus aperfeioamentos, de modo que toda a comunidade se beneficie deles.

1.1

DEFINIO DE DEFEITO E FALHA

Mesmo com todas as recomendaes e padres de qualidade internacionais os programas so passveis de defeitos, falhas (ou bugs). Ento qual a importncia de se fazer a diferenciao entre essas trs possibilidades de ocorrncias em um programa? Faamos o estudo. O defeito uma imperfeio ou incorreo no cdigo do programa que no permite o seu funcionamento parcial ou completo, enquanto que falhas so ocorrncias geradas por fatores externos as linhas de comando de um programa, como por exemplo, a corrupo na base de dados ou falta de espao na memria RAM. Portanto, podemos perceber que ao medirmos a qualidade de um programa devemos ter em mente se o mau funcionamento de um programa deu-se por um defeito em seu cdigo fonte ou por uma falha provocada por fatores externos a sua concepo. Na Figura 21 observamos graficamente o contexto em que os defeitos e as falhas se encontram em relao ao programa.

FIGURA 21 DEFEITO E FALHA DE UM PROGRAMA

PROGRAMAS FATORES EXTERNOS FALHAS DEFEITOS

1.2

SWEBOK

Nas ltimas dcadas, tornou-se claro o desdobramento da computao em uma longa lista de subreas de estudos, obrigando os profissionais a se especializarem para desenvolverem suas atividades com excelncia. Uma dessas subreas a Engenharia de Software cujas fronteiras que delimitam sua atuao esto definidas em estudos realizados pela IEEE chamados de Corpo de Conhecimento de Engenharia de Software (SWEBOK Software Engineering Body Oh Knowledge). O diagrama na Figura 22 apresenta a diviso do Swebok em reas do conhecimento, enquanto que a Figura 23 mostra a subdiviso da rea voltada Qualidade de Software. FIGURA 22 REAS DE CONHECIMENTO DO SWEBOK REQUISITOS DE ENGENHARIA GERNCIA DE ENGENHARIA PROJETO DE ENGENHARIA MTODOS E FERRAMENTAS DE ENGENHARIA SWEBOK CONSTRUO PROCESSO DE ENGENHARIA TESTES QUALIDADE DE SOFTWARE MANUTENO DISCIPLINAS RELACIONADAS GERNCIA DE CONFIGURAO A Qualidade de Software est relacionada a todas as outras reas de conhecimento, trabalhando em conjunto com as demais, pois requer a aplicao de conhecimentos delas. Como o PMBOK, o SWEBOK tem subdivises de suas reas maiores. A subrea que interessa a nossa disciplina da Qualidade de Software, dividida em

dois nveis, formando uma estrutura hierrquica para catalogar os assuntos referentes aos seus fundamentos, processos de gerncia e consideraes prticas (generalidades). Veja a Figura 23: FIGURA 23 DIVISO DA REA DE QUALIDADE DE SOFTWARE Qualidade de Software

Fundamentos da Qualidade de Software Cultura e tica de Engenharia de Software Valor e custo da Qualidade de Software Modelos e caractersticas de Qualidade Melhoria De Qualidade

Processos de Gerncia da Qualidade de Software Garantia da Qualidade de Software Verificaes e Validaes Revises E Auditoria

Consideraes Prticas Requisitos de Qualidade de Software Caracterizao de Defeitos Tcnicas de Gerenciamento de Qualidade de Software Medio de Qualidade de Software

Como podemos observar a rea que estamos estudando (Qualidade de Software) abrangente e mundialmente difundida como uma rea de pesquisas que esto alm das letras, ou seja, configura um campo de ao interdisciplinar cujo alcance vo alm das regrinhas formais, so prticas, claras, srias, que envolvem muitas especialidades que no somente a Tecnologia da Informao e a Engenharia de Software. Observe novamente a figura e veja os exemplos: Cultura e tica de Engenharia de Software, reviso e auditoria, tcnicas de gerenciamento da Qualidade de Software, entre outras. Vejamos as trs divises que esto atreladas dentro do SWEBOK. a Qualidade de Software

1.2.1 Fundamentos da Qualidade: Os aspectos ticos do trabalho com software tem se tornado mais relevante devido nossa crescente dependncia da automao de nossas rotinas atravs dos avanos tecnolgicos. Toda uma nova classe de profissionais e de problemas surgiu com os crimes que tem os computadores e a internet como suas ferramentas. Estudos da tica e de uma legislao especfica para tratar adequadamente esses crimes esto sendo desenvolvidos para cada caso. Novas disciplinas em cursos de graduao e psgraduao foram includas para a efetiva discusso: Informtica e Sociedade e Percia Forense aplicada Informtica, respectivamente. 1.2.2 Processos de Gerenciamento de Qualidade de software: Esses processos abrangem todos os aspectos da construo do software. Citamos por exemplo: sistemas para controle de verso e linguagens de programao, metodologias para reviso do software, tcnicas de administrao de pessoas, etc. Dentro desse grupo de processos encontramos a garantia de qualidade, cujo propsito assegurar que o planejamento feito no incio do projeto seja cumprido e que o programa criado far exatamente o que se espera dele, sem falhas e com um menor ndice riscos de defeitos. Por esse motivo as verificaes, as validaes e as auditorias so os processos que complementam o processo de garantia da qualidade. 1.2.3 Consideraes prticas de Qualidade Esse tpico contm as recomendaes gerais sobre as execues das atividades relacionadas qualidade. Os quatro subtpicos ligados as consideraes de qualidade (vistos na Figura 23) compreendem requisitos de oramento, usurios envolvidos, segurana de funcionamento do software, possveis falhas e defeitos, deteco de noconformidade com requisitos, teste do software, metodologias formais de mediadas para os gerentes de qualidade, entre outras. 1.3 MTRICAS

A qualidade pode ser mensurada em dois momentos: ao longo do processo de engenharia de software e aps a entrega ao cliente e aos usurios. Antes da entrega servem como base para decises referentes a projetos e testes, estando includas nessa categoria as mtricas de complexidade do programa, tamanho do

programa e manutenibilidade efetiva. J as mtricas ps-entrega do ao gerente e ao corpo tcnico uma indicao da efetividade do processo de desenvolvimento do programa ou do sistema. A utilizao de mtricas de qualidade um componente-chave da garantia estatstica da qualidade. Traduzindo o enunciado, quando acrescentamos informaes adicionais obre os tipos de defeitos descobertos e suas causa, ofereceremos mecanismos e aes de planejamento de correo dos elementos que esto introduzindo esses defeitos (rotinas inadequadas, lgica mal aplicada, etc). Como se deve fazer a medida da qualidade de um software? Esta pergunta pertinente, visto que no fcil concebermos a idia de que iremos medir algo subjetivo ou abstrato. Em outras palavras, quando pudermos medir aquilo que afirmamos e transformarmos o fenmeno ou projeto em nmeros, saberemos algo mais a respeito e que est alm do que se pressupe sem comprovaes. Podemos sim avaliar quantitativamente a qualidade de sistemas de informaes ou de um simples aplicativo, estabelecendo, por exemplo, o quesito de tempo mximo que um programa poder demorar em fornecer certa resposta e partindo para a escolha de um algoritmo de melhor desempenho, da maneira como acessaremos registros e arquivos em um banco de dados, os requisitos mnimos de hardware e etc. Outra questo para respondermos : Qual a importncia do uso de mtricas no processo de desenvolvimento de um sistema? O uso de mtricas responde a aspectos como a influncia de uma rotina no resultado e no tempo de resposta do sistema. D evidncias de que uma estrutura de dados pode ser melhor do que outra em determinado mdulo do programa por economizar o nmero de variveis, ou seja, a escolha por implementar uma matriz Aluno com dez elementos em lugar de dez variveis com nomes diferentes. Portanto, um rpido estudo sobre mtricas pode nos capacitar a analisar aspectos qualitativos de um software (que antes pareciam subjetivos e passivos de opinies divergentes) atravs de estatsticas e verificaes formais baseados em nmeros e funes matemticas conclusivas. 1.3.1 Viso geral As mtricas podem ser utilizadas para medir a produtividade de programadores, horas de trabalho e a evoluo do cronograma do sistema. Para que isso acontea consideram-se fatores de comportamento de um programa baseados: Na configurao de Hardware: Modelo do processador, clock, nmero de ncleos, quantidade de memria Cashe e RAM disponveis e velocidade de perifricos;

 Na configurao de Software: Sistema Operacional, verso do programa, outros programas que esto sendo executados em paralelo e ao de antivrus. No nmero de usurios que faro os testes de usabilidade; Na lgica da programao: nmero de rotinas, escolha do tipo de estrutura de dados, tipo de linguagem (orientada a objetos ou procedural), os tipos de variveis e de seus atributos e os tipos de dados. As mtricas no so meros resultados de quantificao, mas um estudo sobre a definio do escalonamento de caractersticas qualitativas de um software. As caractersticas qualitativas esto associadas noo de intensidade ou de gosto, porm possvel atribuirmos um valor (de 1 a 10) em lugar de um conceito (pouco, muito, bom, razovel, excelente, baixo ou alto). Tomemos como exemplo um novo jogo de computador. Um dos maiores fatores a ser medido, tanto qualitativamente, quanto quantitativamente o fato de quo atrativo ao usurio e qual o nvel de dificuldade de suas etapas, respectivamente. Na Tabela 12 temos um exemplo de mapeamento qualitativo-quantitativo do desempenho de editor de texto. TABELA 12 Mapeamento qualitativo-quantitativo de desempenho
Usabilidade Muito difcil Difcil Indiferente Fcil Super fcil Nota atribuda 1 2 3 4 5

A escala numrica variou atribuindo notas de 1 a 5 para expressar a opinio dos usurios em manipular os comandos, menus e ferramentas de um determinado editor. Estatisticamente, como a opinio de um nico usurio no confivel para concluir um processo avaliativo, necessrio verificar um grupo de usurios que usem diariamente o mesmo editor de texto. Aps a coleta das notas procede-se ento o clculo da mdia e registra-se como a nota do grupo, cuja credibilidade maior. Outro aspecto dentro da mesma pesquisa e com o mesmo grupo pesquisado a possibilidade de expressarmos ndices de proporcionalidade baseados no nmero de indivduos que atriburam a nota 5 em relao ao nmero total de indivduo que participaram da pesquisa. Esse ndice pode ser usado para realizarmos uma comparao entre dois diferentes editores de texto, dando a concluir qual o editor que oferece uma interface mais amigvel ao usurio.

No devemos esquecer de que os demais parmetros de configurao de hardware e de software devem ser exatamente os mesmos, ou seja, uma mesma mquina e um mesmo sistema operacional. Uma maneira adequada de facilitarmos a compreenso dos resultados a confeco de grficos do tipo histograma e pizza, entre vrios. um recurso visual que torna a quantizao de um aspecto qualitativo do software mais direta e clara, evidenciando atravs de imagens que o crebro humano imediatamente reconhece, analisa e conclui os dados contidos em uma tabela. Se formos representarmos atravs de um histograma a Tabela 12 veramos a correspondente imagem dos seus dados na Figura 24. Para cada possvel impresso relatada pelo usurio teramos um nvel em cada coluna do histograma. FIGURA 24 GRFICO DO MAPEAMENTO DE DESEMPENHO.

Por outro lado se quisssemos expressar a comparao entre dois editores de texto diferentes poderamos visualizar atravs de outro histograma (Figura 25) ou dois grficos de pizza (Figura 26) com origem nos resultados da Tabela 13. TABELA 13 Dados comparativos entre dois editores de texto
Usabilidade Muito difcil Difcil Indiferente Fcil Nmero de usurios Editor 1 10 20 10 30 Editor 2 15 30 10 25

Super fcil TOTAL

30 100

20 100

Os dados na tabela 13 so apenas dados numricos com representatividade, mas sem entendimento imediato (tambm so fictcios, apenas servem para ilustrarmos). Agora preste ateno na Figura 25, os dados foram transformados em informaes de fcil discernimento atravs de barras coloridas que distinguem os resultados obtidos dos dois editores e com o auxlio da legenda podemos identificar quantas pessoas expressaram suas opinies dentro do intervalo de conceitos e notas atribudas. FIGURA 25 GRFICO DE BARRAS: COMPARATIVO DOS EDITORES.

Pelo grfico constatamos que h maior dificuldade dos usurios em utilizarem as ferramentas do segundo editor de texto, pois suas curvas acusam que mais da metade (55 pontos) foram atribudos a dificuldade enquanto que o primeiro editor pode ser considerado mais amigvel por ter menos de um tero (30 pontos) de usurios com dificuldades, tornando-o mais funcional e amigvel. Deixamos claro que esta concluso est levando em considerao o aspecto da dificuldade como expresso da caracterstica maior do editor: a usabilidade. Mesmo que fossemos declarar a usabilidade atravs do aspecto da facilidade de uso, chegaramos a mesma concluso: o editor1 apresenta melhores respostas.

FIGURA 26 GRFICO DE PIZZA: COMPARATIVO DE EDITORES.

Com os grficos da Figura 26 teremos a mesma concluso extrada do grfico de barras da Figura 25. Observando que em um nico histograma foi suficiente para chegarmos a uma idia conclusiva, os grficos de pizza por editor neste caso, disponibilizaram os dados de uma forma diferente. Salientamos que no caso de uma possvel escolha entre os dois editores, outros fatores devem ser analisados: custo de licena, compatibilidade com SO, espao em memria, suporte e atualizaes peridicas. Portanto, durante as anlises de dados, algumas vezes o simples uso de grficos mais til ao gerente de uma equipe de desenvolvedores do que clculos de varincia e projees. Para que tenhamos a viso geral da relevncia do uso de mtricas na prtica do Gerenciamento de Desenvolvimento de Software, observemos o papel das mtricas quando possumos dados histricos do funcionamento de um software cujo projeto deve ser modificado (Figura 27). As informaes coletadas por meio de mtricas aplicadas em modelos anteriores e de controles de projetos de software em andamento (fase de testes e documentao) daro subsdios para aes corretivas e preventivas no novo projeto de software, conduzindo um gerente de desenvolvimento de software a ter previses mais acertadas.

FIGURA 27 USO DE MTRICAS E DE DADOS HISTRICOS Projeto Terminado Projeto em Andamento Projeto Futuro

Mtricas

Controles

Previses

Dados histricos

1.3.2 Mtricas Orientadas a Tamanho ou Funo As mtricas de software orientadas ao tamanho so medidas diretas baseadas nos registros dos seguintes aspectos: Nmero de linhas de cdigo: (medidas em mil linhas de cdigo - KLOC); Nmero de pessoas/ms envolvidas no esforo da codificao das linhas de comandos; Nmero de pginas de documentao gerada por software; Nmero de erros existentes aps a entrega do sistema ao cliente dentro de um perodo de um ano de operao, excluindo-se o perodo de testes; As observaes desses aspectos geram dados tabelados, exemplificados para efeitos de compreenso na Tabela 14, conforme abaixo. TABELA 14 Mtricas orientadas ao Tamanho
Software Finanas Operacional Logstica Mdica Estoque Esforo 3 4 7 15 3 KLOC 12,1 28 19,5 25,5 10 Pginas Documentadas 430 1024 925 1459 400 erros 4 7 3 8 2

As mtricas orientadas ao tamanho podem provocar controvrsias e no so padronizadas internacionalmente por no serem aceitas como a melhor ou a nica maneira de medio do desenvolvimento de um programa. A maior parte da controvrsia gira em torno do uso das linhas de cdigo como a medida-chave. Os opositores a essas mtricas por tamanho afirmam que o nmero de linhas de comandos depende da sintaxe, da semntica e do tipo de linguagem de programao adotada por uma equipe de desenvolvedores (linguagem orientada a objeto ou linguagem procedural). Por outro lado, as mtricas orientadas Funo so medidas indiretas coletadas e registradas sobre a funcionalidade ou utilidade do programa. Ao invs de contar o nmero de linhas e erros de um programa, nessa mtrica sugerido o mtodo de pontos-por-funo (function-point). Para sermos mais prticos na abordagem do mtodo de pontos-por-funo sugerimos seguir a lista de pontuao e perguntas assinaladas na Tabela 15 abaixo: TABELA 15 Pontos-por-Funo
S/ influncia Significativo Moderado Mdio

Conceitos E Pontos
Perguntas O sistema requer backup e recuperao confiveis? Exigncia de comunicao de dados? H sub-rotinas de processamento distribudo? O desempenho crtico? H compatibilidade novo software e o S.O. existente? O programa requer entrada de dados on-line? A entrada on-line requer muitas telas? As consultas so complexas? Os arquivos so atualizados on-line? O cdigo do sistema reusvel? O sistema usado em qualquer mquina/ambiente? O sistema amigvel aos usurios? O sistema de fcil manuteno dos cdigos?

Como podemos notar, as mtricas de pontos-por-funo, so aplicaes dos conceitos vistos no item anterior (1.3.1. Viso geral), onde realizamos um mapeamento qualitativo e quantitativo de requisitos e de desempenho, com a finalidade de adiantarmos as prioridades de respostas e o comportamento que

Essencial

Incidental

dever ter o novo sistema, observando a caractersticas de um menor nmero de erros aps a entrega. 1.3.5 Estatsticas prticas Alguns resultados em estatsticas so ao mesmo tempo bsicos e teis para a anlise global das medidas que foram efetuadas sobre as qualidades dos softwares, entre elas citamos: mdia e a varincia. No caso das mdias a representao do resultado mais provvel e esperado da execuo. Num exemplo de medies de tempo de resposta para consultas, via rede, de um banco de dados, referenciados em segundos, o clculo seguir a somatria de todos os tempos de amostragem (TP1 a TPn), dividido pelo nmero de medidas efetuadas (n). M = (TP1+TP2+...+TPn) n A varincia uma indicao dos intervalos de valores prximos a mdia. Se o valor da varincia for pequeno, ento as medies esto pouco espalhadas em trono da mdia. Por outro lado, se o valor da varincia for igual a zero, conclumos que todos os valores medidos foram iguais. 2. CONTRIBUIES HUMANAS A QUALIDADE

A maneira como as pessoas trabalham no desenvolvimento de software, individualmente e em equipe, tem um impacto decisivo sobre os resultados obtidos. Uma parte importante desse trabalho no rotineiro, e saber administrar as novidades vital. A organizao do trabalho da equipe de desenvolvedores em grande parte resolvida pelo uso de metodologias como CMMI. Contudo, um mtodo de trabalho no estar completo se no houver compreenso do mtodo organizacional e envolvimento de cada elemento do grupo, reconhecendo o seu papel individual e coletivo que est exercendo. A equipe tcnica dividida em grupos para desenvolver diferentes mdulos precisa de comunicao. Portanto, garantir que todos os indivduos de todos os grupos tenham em mente o desenvolvimento de seu mdulo em consonncia com o desenvolvimento dos demais mdulos primordial, pois precisar do apoio de indivduos de outros grupos e para isso precisar se comunicar eficientemente. Outro aspecto a criatividade individual destituda da individualidade egocntrica. Parece uma crtica, mas uma observao a ser feita diante de uma equipe de pessoas inteligentes, experientes e autodidatas. Trabalhar em equipe, muitas vezes, determina a perda de padres de desenvolvimento pessoais.

2.1

NVEIS DE MATURIDADE DAS EMPRESAS

Os nveis de maturidade de uma empresa so classificados de acordo com nveis de gerncia dessa organizao. Nos modelos CMM/CMMI so citados os seguintes nveis: inicial, gerenciado, definido, gerenciado quantitativamente e otimizado. Mas esses nveis no so o padro mundial, eles compartilham com outras classificaes. Galgar nveis de maturidade significa que uma empresa e todos os seus departamentos aprenderam a ter maior preciso: Ao traar os seus objetivos; Ao estimar situaes variadas de custos, tempo e outras; Ao elaborar e gerenciar planos e projetos; Ao interagir com o seu cliente e com seus usurios; Ao utilizar mtricas de qualidade; Ao treinar seus desenvolvedores; 2.2 PRTICAS DE EMPRESAS MADURAS

Uma das metodologias de trabalho muito difundida e conhecida o Sistema Kaisen que foi introduzida nas empresas japonesas do grupo Toyota, inicialmente concebida para ambientes de produo fabril. Com o sucesso de tal metodologia, o sucesso encorajou desdobramentos em outros campos como o da TI. No Sistema Kaisen aparecem noes de disciplina, asseio e organizao em todos os espaos individuais e coletivos de uma empresa. No espao individual,por exemplo: ferramentas, objetos, canetas, equipamentos devem estar posicionados em lugares apropriados e em bom estado. Tambm conhecido como os 5S (referentes s iniciais das palavras japonesas: Seiri, Seiton, Seisoh, Seikrtsu e Shitsuke), essa metodologia se fundamenta na prtica de cinco reas: 1S: tudo o que no necessrio deve ser jogado fora; 2S: organizao do espao e do mtodo de trabalho;

 3S: limpeza geral, ou melhor, alm da limpeza do ambiente, preocupa-se com a limpeza e disponibilidade das ferramentas de trabalho; 4S: asseio ou padronizao, ou seja, tudo em seu devido lugar, cabe a mxima: usou, limpou!; 5S: disciplina e submisso s recomendaes e prticas de trabalho. Cabe o restante da mxima: usou, limpou! Guardou no mesmo lugar.

2.2.1 Aplicao das prticas construo de Softwares A filosofia de trabalho dos 5S nos parece intimamente ligadas a tarefas do dia-a-dia e de trabalhos sobre objetos concretos; ento, como aplic-la a algo como um software, cujas caractersticas so subjetivas e abstratas? A resposta esclarecedora est na m interpretao e na m aplicao da metodologia. A filosofia Kaisen (5S) pode servir como um mtodo de trabalho aos desenvolvedores tambm. Portanto, vejamos como fazer a ligao dos conceitos dos 5S construo de softwares: 1S: tudo o que no necessrio deve ser jogado fora as rotinas necessrias devem ser implementadas, evitando-se por outro lado todas as linhas de comando que sejam inteis ao usurio. Deve-se simplificar o software tendo como consequncia a facilitao as atividades do usurio do software; 2S: organizao do espao e do mtodo de trabalho o cdigo-fonte e os diagramas e documentos do sistema devem ser identificados de forma clara e lgica. 3S: limpeza geral, ou melhor, alm da limpeza do ambiente, preocupa-se com a limpeza e disponibilidade das ferramentas de trabalho arquivos e documentos, alm de rotinas/linhas de comando no software que estejam desatualizados ou se mostraram sem utilizao devem ser descartado; 4S: asseio ou padronizao, ou seja, tudo em seu devido lugar, cabe a mxima: usou, limpou! formatos de linhas de comentrios, nomenclaturas dos documentos e dos testes, vocabulrio devem seguir um padro na equipe tcnica ou na empresa; 5S: disciplina e submisso s recomendaes e prticas de trabalho. Cabe o restante da mxima: usou, limpou! Guardou no mesmo lugar. est diretamente mais relacionado ao bem estar e qualidade de vida dos indivduos pertencentes

equipe tcnica do que ao software em si, porm reflete de igual forma no desenvolvimento do sistema, pois teremos um ambiente de trabalho mais salutar e com pessoas bem dispostas e comprometidas com a viso do todo. 3. NORMAS ISO/IEC

A simples meno do vocbulo norma nos remete o pensamento aos processos de engessamento da criatividade e sufocamento das individualidades. Mero engano! As normas so partes integrantes das frmulas de sucesso em todas as atividades humanas. O que seria do trnsito se no existissem as normas (ou padres) de direo dos veculos automotores, chamadas de leis de trnsito? O caos total! Similar a importncia das normas de trnsito de um pas, as Normas ISO/IEC so os referenciais de qualidade necessrios a conduo dos trabalhos em nossa profisso de analistas e desenvolvedores de software. No faz parte do escopo deste fascculo e nem de nossa disciplina o estudo aprofundado de cada norma, mas estaremos apresentando o que mais interessante e aplicvel ao Gerenciamento de Desenvolvimento de Software. 3.1 ISO/IEC 15504

Esta norma apresenta uma estrutura para realizao de avaliaes de processos em organizaes e est dividida como mostra a Tabela 16. Para que a ISO/IEC 15504 tenha efeito sobre a qualidade de software, ela deve ser complementada com a ISO/IEC 12207. TABELA 16 Divises da ISO/IEC 15504
Parte 1 2 3 4 5 Publicao 2004 2003 2004 2004 2006 Descrio Conceitos e vocabulrio Estrutura de avaliaes Recomendaes de realizao de avaliaes Recomendaes de melhoria de processos Exemplo de aplicao

Sua aplicao geral sobre situaes como: Melhorias internas nas empresas; Avaliaes das atividades de empresas terceirizadas ou de fornecedores de produtos.

3.2

ISO/IEC 12207

Ao definir esquemas de qualidade em uma empresa, referncias como o CMMI so importantes, uma vez que permitem traar um objetivo a ser alcanado. Mas a definio de uma estrutura de processos para se alcanar o objetivo tem que contar com um linguajar comum em meio ao crescente nmero mtodos, tcnicas, modelos e normas que tratam de qualidade e da garantia de qualidade. Podemos afirmar que a ISO/IEC 12207 um metamodelo de ciclo de vida, ou seja, um modelo que ensina a modelar um novo ciclo de vida de processo e a partir do qual cada empresa tem autonomia para definir a sua prpria estrutura e o encadeamento de seus processos. Os processos dessa norma esto exemplificados na Tabela 17 e detalhadamente descritos no texto da ISO/IEC 12207. Como vemos so classificados em trs categorias: Primrio: processos bsicos de produtos de software, tais como: processo de desenvolvimento, processo de operao e manuteno; De apoio: processos iniciados aps a concluso dos primrios, tais como: processo de revises, de auditorias e de solues de problemas; Organizacionais: processos relacionados ao gerenciamento e treinamentos. TABELA 17 Categorias dos processos da ISO/IEC 12207
Primrios Aquisio Fornecimento Desenvolvimento Operao e manuteno De apoio Documentao Garantia da qualidade Verificao/validao Revises e auditorias Organizacionais Gerenciamento Treinamentos Melhoramentos

Gerncia de configurao Infraestrutura

3.3

ISO/IEC 25000

Para completar o estudo das normas, alm das normas ISO/IEC 15504 e ISO/IEC 12207, temos que estudar especificamente uma norma responsvel pela caracterizao e medio de qualidade de produto de software: ISO/IEC 25000. Essa norma chamada de SQuaRE que significa: Software product Quality Requirements and Evaluation (Requisitos de Qualidade e Avaliao de Produtos de

Software). Ela est dividida em cinco componentes, conforme a disposio visualizada na Figura 28: FIGURA 28 COMPONENTES DA NORMA SQuaRE. Modelo de Qualidade Requisio De Qualidade 2503n 2501n Gerenciamento de Qualidade 2501n Medies 2501n Avaliao 2504n

4.

MODELO SW-CMM E CMMI

O Instituto de Engenharia de software (SEI - Software Engineering Institute) criou a partir de sua fundao os padres de melhoria de processos de software conhecidos por SW-CMM e CMMI. Surge logo a pergunta: o que significa SW-CMM? A sigla entre tantas outras que estudamos em nosso curso e em especial em nossa disciplina, significa a Capacidade de Maturidade de Modelos para Software. Por ser um modelo especfico rea de software, no esto includas as outras reas de uma organizao, como RH e Finanas. Mesmo assim, um fator de relevncia na busca pela melhoria da eficcia e da competitividade, focalizando nos processos de automao em um curto prazo. 4.1 SW-CMM ORIGEM E NVEIS

O objetivo principal do SW-CMMI que as empresas aprendam como desenvolver melhor os seus softwares implementando melhorias em seus processos. Essas melhorias, ao contrrio do que muitos estudiosos pensam, esto baseadas em cinco pequenos passos e no em grandes revolues organizacionais. So cinco nveis diferentes, cada passo corresponde a um nvel de maturidade de processos e so classificados como: Nvel 1: Inicial. A empresa que for classificada neste nvel tem dificuldades de planejamento e enfrentam problemas de erros em cronogramas, sempre contando com imprevistos. Por isso, a falta de credibilidade em planejamento leva a um desenvolvimento confuso de software.

Os responsveis e a equipe de desenvolvimento dos programas ou sistemas da empresa passam dos requisitos para a codificao sem se importarem com outros aspectos: manutenibilidade, usabilidade, documentao e etc. Nvel 2: Repetitivo. No nvel Repetitivo, tambm chamado de Gerenciado, as empresas tm maior probabilidade em cumprir compromissos com os requisitos de sistema, com prazos e custos, considerando o que aprendeu com outros processos anteriores. Assim, quando j se tem experincia suficiente em desenvolver aplicaes em plataforma WEB, passar a fazer uso de seu Know-how em projetos futuros. Mesmo dando indcios de disciplina, essas empresas ainda no so capazes de adotar novas ferramentas e novos mtodos, devido se manter na perspectiva de fazer o que sabe e o que deu certo. Nvel 3: Definido. Um nvel acima do que o anterior significa que essas organizaes estabelecem uma adaptao mudana de seus processos. Repetem os sucessos de projetos anteriores e evoluem com novas iniciativas de melhorias. Os processos de documentao, por exemplo, so bem realizados e apiam os gerentes e equipes de desenvolvedores em suas novas decises e objetivos, evitando as no-conformidades e impactos indesejveis na qualidade de seus softwares. Nvel 4: Gerenciado. A administrao dos processos evolui para a parametrizao da base dados dos projetos anteriores atravs de mtricas. A produtividade e a qualidade so gerenciveis e os processos sofrem contnuas melhorias. A vigilncia de aspectos quantitativos e qualitativos dos processos recorrente e motivadora. Nvel 5: Otimizado. Os gerentes identificam pontos falhos nos processos e so pr-ativos, percebendo as conseqncias e tomando medidas preventivas em lugar de atitudes corretivas. A equipe, alm do gerente, tem uma postura pr-ativa e de autonomia para implementar melhorias em seus processos. O que demonstra um crescimento da viso e o comprometimento de avaliar a produtividade do trabalho. Os defeitos so identificados, resolvidos e estudados por todos para que no ocorram novamente nos novos projetos de software. 5. MODELO BRASILEIRO MPS.BR

Os pesquisadores brasileiros tm dado suas contribuies para melhoria dos processos de desenvolvimento de software. O MPS.BR (Melhoria de Processos do Software Brasileiro) prova dessa atitude pioneira e corajosa. um modelo recente (iniciou em 2003) e em estado de constante evoluo. O alvo dessas melhorias empresa de desenvolvimento de software que necessitam evoluir sua produo de sistemas com qualidade e possui poucos recursos diante de tal desafio em um contexto especfico: o brasileiro. Os diferenciais desse mtodo so: Sete nveis de maturidade, possibilitando uma implantao mais gradual e adequada ao porte da empresa; Compatibilidade com SW-CMMI e com a norma ISO/IEC 15504; Voltado para o mercado de micros, pequenas e mdias empresas desenvolvedoras de sistemas; Custo acessvel; Avaliao bienal das empresas; Forte interao entre Universidades e empresas. A descrio deste modelo tem trs guias para sustentar os diferencias citados acima: Guia Geral: Contendo a descrio do MPS.BR e o detalhamento do modelo de referncia (MR-MPS), seus componentes e as definies comuns necessrias para estudos e prticas. Guia Aquisio: Possui recomendaes para a conduo de compras e de servios correlatos ao desenvolvimento de software. Guia de Avaliao: Contm os requisitos para o avaliador, o mtodo e os formulrios para guiar a avaliao.

5.1

ESTRUTURA DO MPS.BR

A estrutura deste modelo est baseada nas normas NBR ISO/IEC 12207, ISO/IEC 15504 e o SW-CMMI. Pode ser visualizada atravs da Figura 29 como o resultado dos esforos governamental, Universidades e a SOFTEX. FIGURA 29: ESTRUTURA DO MPS.BR CMMI ISO/IEC 15504 ISO/IEC 12207

Realidade das empresas brasileiras

MPS.BR

MR-MPS

MA-MPS

MN-MPS

Guia Geral

Guia de Avaliao

Guia de Aquisio

5.2

NVEIS DO MPS.BR

Como mencionado no item 5, so sete nveis que compem o MPS.BR. para cada nvel foi definido dois perfis comuns: um perfil de processos e um perfil de capacitao de processos. Tais informaes de perfis colaboram no sentido de direcionar esforos de melhorias para atender os objetivos de negcio da empresa. A classificao dos sete nveis feita seguindo uma ordem alfabtica, onde os processos ligados ao nvel G so considerados os mais bsicos. E no outro extremo da classificao, os processos do nvel A so os mais avanados. A Tabela 18 resume correspondncia entre os processos e os nveis segundo essa classificao do MPS.BR. Vejamos:

TABELA 18 Classificaes dos processos segundo os nveis do MPS.br

Tipo

Nvel Em otimizao Gerenciado quantitativamente Definido

Processos Inovao na empresa Anlise de causas/solues. Desempenho do processo organizacional. Gerncia Quantitativa Anlise de decises e resolues Gerncia de Riscos Desenvolvimento de requisitos Soluo tcnica Integrao de produto

A B C

Largamente definido

Instalao de produto Liberao de produto Verificao Validao Treinamento Melhoria do processo organizacional Definio do processo organizacional Adaptao do processo para Gerncia de Projetos. Medio Gerncia de Configurao Aquisio Garantia da Qualidade Gerncia de Requisitos Gerncia de Projeto

Parcialmente definido

Gerenciado

Parcialmente gerenciado

6.

METODOLOGIAS GEIS

Diversas metodologias foram criadas para sistematizar o estudo do desenvolvimento de softwares. Essas metodologias foram divididas em dois grandes grupos: as tradicionais e as geis. As metodologias tradicionais enfatizam a documentao de cada fase do projeto de desenvolvimento do sistema, enquanto que as metodologias geis prometem implementar um novo paradigma: melhorias na produo do software com qualidade.

O resultado esperado de qualquer tipo de metodologia a produo e a garantia de qualidade de um sistema. Para isso, elas tm em comum as seguintes atividades: Especificao: definio das funcionalidades e demais caractersticas do software; Projeto e implantao: proposio do modelo em forma de diagrama que sero codificados em uma linguagem de programao; Validao: atividades de testes e reviso do software de acordo com requisitos; Evoluo: atividades de manuteno do programa para novas demandas do cliente; Entre as mais difundidas metodologias geis podemos citar duas: a Extreme Programming (XP) e a Scrum. A XP voltada para equipes pequenas e mdias e que desenvolvem softwares baseados em requisitos vagos, assim como determina atividades constantes de feedback e encorajamento de comunicao entre as pessoas. A idia central a simplicidade (cdigos enxutos) e a rapidez na entrega do software. A Scrum tem por objetivo o fornecimento de processos voltados ao desenvolvimento de software orientado a objetos. O foco central encontrar uma forma de trabalho dos membros para flexibilizar a produo de software em ambientes dinmicos, que tm como caracterstica mudanas constantes de necessidades. Para que no acumulem problemas e sejam gerados erros nos cdigos dos programas, as reunies da equipe so curtas (15 minutos) e dirias e tm ciclos interativos, chamados de sprints com durao de trinta dias. As duas metodologias tm em comum o curto espao de tempo para promover as solues que aparecem com frequncia e dar respostas a requisitos instveis. 7 ASPECTOS DA QUALIDADE E DA GARANTIA DA QUALIDADE DE SOFTWARE

Estudamos at este momento os aspectos de qualidade no desenvolvimento de um software e parece que o termo garantia est relacionado a uma etapa posterior gerao do software. Se assim pensamos, estamos longe da verdade!

Dentro da Engenharia de Software a Garantia de Qualidade de Software (SQA Software Quality Assurance) abrange mtodos ao longo de todos os processos de anlise, de codificao, de testes, de revises tcnicas, de estratgias, de controle da documentao e de mecanismos de medio e divulgao. 7.1 FATORES DA GARANTIA DA QUALIDADE DE SOFTWARE

Uma grande ameaa qualidade de software vem de fontes benignas: as mudanas. So nessas fontes que as introdues e a propagao de erros so percebidas. O desafio escrever cdigos que podem ser mudados futuramente sem causarem transtornos para os demais mdulos do sistema. A anotao e manuteno de registros de mediadas e aes de qualidade de software oferecem a coleta e a disseminao de informaes para garantir uma melhor produo. Para a SQA esses registros so feitos periodicamente atravs de relatrios tcnicos de reviso. Um exemplo de relatrio depende de informaes, tais como podemos ver na figura abaixo: FIGURA 30 RELATRIO TCNICO DE REVISO
Relatrio Tcnico de Reviso Identificao da reviso: Projeto: Projeto 1 Data: dd/mm/aaaa Identificao do produto: Material revisado: Mdulo 1 Desenvolvedor: Milton Descrio: insero de varivel de controle de lao. Material revisado: 1. 2. Linhas de cdigos do mdulo 1. Documentao do software, pg. 32. nmero da reviso: AA-xxx local e horrio:

Equipe de reviso: 1. Nome1 2. Nome2 3. Nome3 Avaliao do projeto: ( ) Aceito como est ( ) No aceito Material suplementar anexo: ( ) lista de questes ( ) Outras observaes: ( ) Materiais produzidos e anotados ( ) Com pequenas modificaes ( ) Com revises significativas assinatura: assinatura: assinatura:

Com esses relatrios realizada a anlise estatstica das ocorrncias de informaes e categorias de erros, de rastreamento dos defeitos e de providncias para correo. A utilizao de uma simples planilha eletrnica permite o gerenciamento de quantos erros ocorreram por processos ou por projetos, qual a periodicidade e quais as causas por categorias, etc. possvel o Gerenciamento de Desenvolvimento de Software atravs da aplicao das metodologias estudadas de Qualidade de Software com vistas Garantia da Qualidade de Software. Esse elo muito forte.

RESUMO DA UNIDADE
Aps entendermos as reas de gerenciamento de projetos e obtermos base slida, passamos ao estudo da Qualidade de Software. Foram expostos os fundamentos e os processos da metodologia SWEBOK e suas implicaes prticas, assim como a utilizao das mtricas como fator contribuinte a qualidade de software. As contribuies humanas em conjunto com o nvel de maturidade das empresas formam um importante aspecto do sucesso de um software, sendo verificado no item 2 dessa unidade. Outro fator que tem papel fundamental na atividade de gerenciamento o conhecimento das normas nacionais e internacionais. Suas estruturas, suas divises, seus modelos e sua filosofia so expostos com a finalidade de estabelecer apoio s decises gerenciais. Dentre os modelos estudados chamamos a ateno do MPS.BR, como referncia a padres adotados dentro do contexto de micro, pequenas e mdias empresas brasileiras.

PARA SABER MAIS

Faa pesquisa sobre Garantia de Qualidade de Software na biblioteca de seu plo em livros de Engenharia de Software. Entre eles: Pfleeger, Shari Lawrence. Engenharia de Software: teoria e prtica. 2 edio. So Paulo: Prentice Hall, 2004.

REFLEXES SOBRE A APRENDIZAGEM

Dentro do contexto do Gerenciamento de Desenvolvimento de Software, qual o impacto em uma organizao quando forem utilizadas as metodologias de Garantia de Qualidade de Software? Qual o objetivo e a necessidade de se utilizar mtricas para se fazer classificao de empresas?

SUGESTES DE LEITURA
1. Pressman, Roger S. Engenharia de Software. 3 edio. So Paulo: Pearson Makron Books, 2008.