TI Gerência de Desenvolvimento de Software - UNIDADE 3

8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3

1/32

INSTITUTO FEDERAL DE EDUCAO, CINCIA E TECNOLOGIA DO PARPR-REITORIA DE EXTENSO

DIRETORIA DE EDUCAO ABERTA E A DISTNCIA

TECNOLOGIA EM ANLISE E

DESENVOLVIMENTO DE SISTEMAS

GERENCIAMENTO DEDESENVOLVIMENTO DE SOFTWARE

PROF. MILTON ROBERTO GOMES CARDOSO

2011


2/32

SUMRIO

PLANO DE ENSINOAPRESENTAO

UNIDADE 1 CONCEITOS BSICOS

1. INTRODUO2. CONCEITOS BSICOS DE GERENCIAMENTO DE PROJETOS2.1 QUAL A DIFERENA ENTRE PROJETOS E PROGRAMAS?2.2 O QUE UM PROJETO E QUAL O PESSOAL ENVOLVIDO NO PROJETO?2.3 QUAIS AS CARACTERTICAS DOS PROJETOS?2.3.1 Benefcios do Gerenciamento de Projetos2.3.2 Causas de fracassos em Projetos

3. O CICLO DE VIDA DOS PROJETOS3.1 CARACTERSTICAS DO CICLO DE VIDA3.2 FASES DO CICLO DE VIDA4. AS NORMAS E OS ORGOS NORMATIVOS

UNIDADE 2 REAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS

1 PMBOK ATRAVS DE MAPAS MENTAIS (MINDMAPS)2 REAS DE CONHECIMENTO EM GERENCIAMENTO DE PROJETOS2.1 GERENCIAMENTO DA INTEGRAO

2.1.1 Definio e Midmap do Gerenciamento da Integrao2.1.2 Plano Global do Projeto2.2 GERENCIAMENTO DE ESCOPO2.2.1 Definio e Midmap do Gerenciamento de Escopo2.2.2 Plano de Gerenciamento de Escopo2.3 GERENCIAMENTO DE TEMPO2.3.1 Definio e Midmap do Gerenciamento de Tempo2.3.2 Plano de Gerenciamento do Cronograma2.4 GERENCIAMENTO DE CUSTOS

2.4.1 Definio e Midmap do Gerenciamento de Custos2.4.2 Plano de Gerenciamento de Custos2.5 GERENCIAMENTO DA QUALIDADE2.5.1 Definio e Midmap do Gerenciamento da Qualidade2.5.2 Plano de Gerenciamento da Qualidade2.6 GERENCIAMENTO DE RECURSOS HUMANOS2.6.1 Definio e Midmap do Gerenciamento de Recursos Humanos2.6.2 Plano de Gerenciamento de Pessoal2.7 GERENCIAMENTO DAS COMUNICAES2.7.1 Definio e Midmap do Gerenciamento das Comunicaes

2.7.2 Plano de Gerenciamento das Comunicaes2.8 GERENCIAMENTO DE RISCOS


3/32

2.8.1 Definio e Midmap do Gerenciamento de Riscos2.8.2 Plano de Gerenciamento de Riscos2.9 GERENCIAMENTO DAS AQUISIES2.9.1 Definio e Midmap do Gerenciamento das Aquisies2.9.2 Plano de Gerenciamento das Aquisies

PARA SABER MAISREFLEXES SOBRE A APRENDIZAGEMRESUMO DA UNIDADESUGESTES DE LEITURA

UNIDADE 3 QUALIDADE DE SOFTWARE

1. O QUE QUALIDADE?1.1 DEFINIO DE DEFEITO E FALHA1.2 SWEBOK1.2.1 Fundamentos de Qualidade1.2.2 Processos de Gerenciamento de Qualidade de software:1.2.3 Consideraes prticas de Qualidade1.3 MTRICAS1.3.1 Viso geral (apndice A - qualidade de software)1.3.2 Mtricas Orientadas a Tamanho ou Funo1.3.3 Estatsticas prticas2. CONTRIBUIES HUMANAS A QUALIDADE

2.1 NVEIS DE MATURIDADE DAS EMPRESAS2.2 PRTICAS DE EMPRESAS MADURAS2.2.1 Aplicao das prticas construo de Softwares3. NORMAS ISO/IEC3.1 ISO/IEC 155043.2 ISO/IEC 122073.3 ISO/IEC 250004. MODELO SW-CMM E CMMI4.1 SW-CMM ORIGEM E NVEIS

5. MODELO BRASILEIRO MPS.BR5.1 ESTRUTURA DO MPS.BR5.2 NVEIS DO MPS.BR6. METODOLOGIAS GEIS7 ASPECTOS DA QUALIDADE E DA GARANTIA DA QUALIDADE DE

SOFTWARE7.1 FATORES DA GARANTIA DA QUALIDADE DE SOFTWAREPARA SABER MAISREFLEXES SOBRE A APRENDIZAGEMRESUMO DA UNIDADE

SUGESTES DE LEITURA


4/32

UNIDADE 4 TCNICAS E MODELOS DE PROJETO DE SOFTWARE

1 ASPECTOS FUNDAMENTAIS DO PROJETO DE SOFTWARE1.1 ABSTRAO1.2 REFINAMENTO

1.3 MODULARIDADE1.4 ARQUITETURA E HIERARQUIA DE CONTROLE DE SOFTWARE1.5 ESTRUTURA DE DADOS2. MODELOS DE PROJETOS DE SOFTWARE2.1 MODELO EM CASCATA2.2 MODELO EM V2.3 MODELO DE PROTOTIPAO2.4 MODELO DE DESENVOLVIMENTO POR FASES2.5 MODELO EM ESPIRAL

PARA SABER MAISREFLEXES SOBRE A APRENDIZAGEMRESUMO DA UNIDADESUGESTES DE LEITURA

CONSIDERAES FINAIS DA DISCIPLINA

GUIA DIDTICO


5/32

UNIDADE 3

QUALIDADE DE SOFTWARE

OBJETIVOS DA UNIDADE

Apresentar a importncia dos conceitos de qualidade para servir de base a aplicaoe na anlise das caractersticas de um software dito de boa qualidade.

Esclarecer o aluno que qualidade no algo sugestivo ou relativo, mas possuiaspectos tcnicos de TI, padres internacionais a serem seguidos e respeitados.

Apresentar as normas internacionais atravs de breves comentrios para no setornar enfadonho o descobrimento da sua utilizao prtica.

Estimular a percepo do aluno quanto ao modelo brasileiro de qualidade de

software.


6/32

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 conhecimentodesta rea, cuja aplicao no desenvolvimento de softwares est relacionada ao usode recomendaes, de mtricas e de estatsticas.

A complexidade de um novo sistema de informaes medida pelo tamanhodo, pelas especificaes, pelas solues apresentadas, pelo nmero de mdulos esuas interaes.

A mudana tecnolgica vivenciada atualmente teve um efeito dramtico na

produo de software. Com um avano dos recursos de hardware criaram-sediversas oportunidades de desenvolvimento de sistemas de informao com grau decomplexidade cada vez maior, comprovando assim a unidade existente entremquina (hardware) e aplicativos (software).

Um aspecto importante nesse desenvolvimento de sistemas que osproblemas 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 equalificao dos programadores e desenvolvedores;

- Aplicativos de difcil interao com o usurio e de difcil manuteno;

- Aplicativos que interrompem o seu funcionamento por mudanas ou atualizaesde sistemas operacionais;

Se no bastassem os exemplos citados acima, temos ainda a incluso denovos 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 emobilidade.


7/32

Este um cenrio desafiador para todos os desenvolvedores de software esistemas 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, porapresentar 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 seusmdulos tambm podem servir de base para o desenvolvimento de outro software. exatamente o que presenciamos hoje em dia com a filosofia das licenas parasoftwares 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 estbaseado;

- Aperfeioar o programa, e liberar os seus aperfeioamentos, de modo que toda acomunidade se beneficie deles.

1.1 DEFINIO DE DEFEITO E FALHA

Mesmo com todas as recomendaes e padres de qualidade internacionaisos programas so passveis de defeitos, falhas (ou bugs). Ento qual aimportncia de se fazer a diferenciao entre essas trs possibilidades deocorrncias 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 soocorrncias 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 memriaRAM.

Portanto, podemos perceber que ao medirmos a qualidade de um programadevemos ter em mente se o mau funcionamento de um programa deu-se por umdefeito em seu cdigo fonte ou por uma falha provocada por fatores externos a suaconcepo.

Na Figura 21 observamos graficamente o contexto em que os defeitos e asfalhas se encontram em relao ao programa.


8/32

FIGURA 21 DEFEITO E FALHA DE UM PROGRAMA

1.2 SWEBOK

Nas ltimas dcadas, tornou-se claro o desdobramento da computao emuma longa lista de subreas de estudos, obrigando os profissionais a seespecializarem para desenvolverem suas atividades com excelncia.

Uma dessas subreas a Engenharia de Software cujas fronteiras quedelimitam sua atuao esto definidas em estudos realizados pela IEEE chamadosde Corpo de Conhecimento de Engenharia de Software (SWEBOK SoftwareEngineering Body Oh Knowledge).

O diagrama na Figura 22 apresenta a diviso do Swebok em reas doconhecimento, enquanto que a Figura 23 mostra a subdiviso da rea voltada Qualidade de Software.

FIGURA 22 REAS DE CONHECIMENTO DO SWEBOK

A Qualidade de Software est relacionada a todas as outras reas deconhecimento, trabalhando em conjunto com as demais, pois requer a aplicao deconhecimentos delas.

Como o PMBOK, o SWEBOK tem subdivises de suas reas maiores. Asubrea que interessa a nossa disciplina da Qualidade de Software, dividida em

PROGRAMAS

DEFEITOS FALHASFATORESEXTERNOS

SWEBOK

REQUISITOS DE ENGENHARIA

GERNCIA DE ENGENHARIA

PROJETO DE ENGENHARIA

QUALIDADE DE SOFTWARE

MANUTENO

DISCIPLINAS RELACIONADAS

GERNCIA DE CONFIGURAO

MTODOS E FERRAMENTAS DE ENGENHARIA

CONSTRUO

PROCESSO DE ENGENHARIA

TESTES


9/32

dois nveis, formando uma estrutura hierrquica para catalogar os assuntosreferentes aos seus fundamentos, processos de gerncia e consideraes prticas(generalidades). Veja a Figura 23:

FIGURA 23 DIVISO DA REA DE QUALIDADE DE SOFTWARE

Como podemos observar a rea que estamos estudando (Qualidade de

Software) abrangente e mundialmente difundida como uma rea de pesquisas queesto alm das letras, ou seja, configura um campo de ao interdisciplinar cujoalcance vo alm das regrinhas formais, so prticas, claras, srias, que envolvemmuitas especialidades que no somente a Tecnologia da Informao e a Engenhariade Software. Observe novamente a figura e veja os exemplos: Cultura e tica deEngenharia de Software, reviso e auditoria, tcnicas de gerenciamento daQualidade de Software, entre outras.

Vejamos as trs divises que esto atreladas a Qualidade de Softwaredentro do SWEBOK.

Qualidadede

Software

Processos de Gernciada Qualidade de

Software

Fundamentos daQualidade de

Software

Consideraes

Prticas

Garantia daQualidade de

Software

Cultura e tica deEngenharia de

Software

Requisitos deQualidade de

Software

Verificaese

Validaes

Valor e custo daQualidade de

Software

Caracterizaode

Defeitos

RevisesE

Auditoria

Modelos ecaractersticasde Qualidade

Tcnicas deGerenciamento de

Qualidade de Software

MelhoriaDe

Qualidade

Medio deQualidade de

Software


10/32

1.2.1 Fundamentos da Qualidade:

Os aspectos ticos do trabalho com software tem se tornado mais relevantedevido 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 deuma legislao especfica para tratar adequadamente esses crimes esto sendodesenvolvidos para cada caso. Novas disciplinas em cursos de graduao e ps-graduao foram includas para a efetiva discusso: Informtica e Sociedade ePercia 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 deprogramao, metodologias para reviso do software, tcnicas de administrao depessoas, etc.

Dentro desse grupo de processos encontramos a garantia de qualidade, cujopropsito assegurar que o planejamento feito no incio do projeto seja cumprido eque o programa criado far exatamente o que se espera dele, sem falhas e com ummenor ndice riscos de defeitos.

Por esse motivo as verificaes, as validaes e as auditorias so osprocessos que complementam o processo de garantia da qualidade.

1.2.3 Consideraes prticas de Qualidade

Esse tpico contm as recomendaes gerais sobre as execues dasatividades relacionadas qualidade.

Os quatro subtpicos ligados as consideraes de qualidade (vistos naFigura 23) compreendem requisitos de oramento, usurios envolvidos, seguranade funcionamento do software, possveis falhas e defeitos, deteco de no-conformidade com requisitos, teste do software, metodologias formais de mediadaspara os gerentes de qualidade, entre outras.

1.3 MTRICAS

A qualidade pode ser mensurada em dois momentos: ao longo do processode 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, estandoincludas nessa categoria as mtricas de complexidade do programa, tamanho do


11/32

programa e manutenibilidade efetiva. J as mtricas ps-entrega do ao gerente eao corpo tcnico uma indicao da efetividade do processo de desenvolvimento doprograma ou do sistema.

A utilizao de mtricas de qualidade um componente-chave da garantia

estatstica da qualidade. Traduzindo o enunciado, quando acrescentamosinformaes adicionais obre os tipos de defeitos descobertos e suas causa,ofereceremos mecanismos e aes de planejamento de correo dos elementos queesto 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 queiremos medir algo subjetivo ou abstrato. Em outras palavras, quando pudermosmedir 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 detempo mximo que um programa poder demorar em fornecer certa resposta epartindo para a escolha de um algoritmo de melhor desempenho, da maneira comoacessaremos registros e arquivos em um banco de dados, os requisitos mnimos dehardware e etc.

Outra questo para respondermos : Qual a importncia do uso de mtricasno processo de desenvolvimento de um sistema?

O uso de mtricas responde a aspectos como a influncia de uma rotina noresultado e no tempo de resposta do sistema. D evidncias de que uma estruturade dados pode ser melhor do que outra em determinado mdulo do programa poreconomizar o nmero de variveis, ou seja, a escolha por implementar uma matrizAluno com dez elementos em lugar de dez variveis com nomes diferentes.

Portanto, um rpido estudo sobre mtricas pode nos capacitar a analisaraspectos qualitativos de um software (que antes pareciam subjetivos e passivos deopinies divergentes) atravs de estatsticas e verificaes formais baseados emnmeros e funes matemticas conclusivas.

1.3.1 Viso geral

As mtricas podem ser utilizadas para medir a produtividade deprogramadores, horas de trabalho e a evoluo do cronograma do sistema. Paraque isso acontea consideram-se fatores de comportamento de um programabaseados:

Na configurao de Hardware:

Modelo do processador, clock, nmero de ncleos, quantidade de memriaCashe e RAM disponveis e velocidade de perifricos;


12/32

Na configurao de Software:

Sistema Operacional, verso do programa, outros programas que estosendo 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 dedados, tipo de linguagem (orientada a objetos ou procedural), os tipos de variveis ede seus atributos e os tipos de dados.

As mtricas no so meros resultados de quantificao, mas um estudosobre 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 dequo atrativo ao usurio e qual o nvel de dificuldade de suas etapas,respectivamente.

Na Tabela 12 temos um exemplo de mapeamento qualitativo-quantitativo dodesempenho de editor de texto.

TABELA 12 Mapeamento qualitativo-quantitativo de desempenho

Usabilidade Nota atribuda

Muito difcil 1

Difcil 2

Indiferente 3

Fcil 4

Super fcil 5

A escala numrica variou atribuindo notas de 1 a 5 para expressar a opiniodos usurios em manipular os comandos, menus e ferramentas de um determinadoeditor. Estatisticamente, como a opinio de um nico usurio no confivel paraconcluir um processo avaliativo, necessrio verificar um grupo de usurios queusem diariamente o mesmo editor de texto. Aps a coleta das notas procede-seento 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 grupopesquisado a possibilidade de expressarmos ndices de proporcionalidadebaseados no nmero de indivduos que atriburam a nota 5 em relao ao nmerototal de indivduo que participaram da pesquisa. Esse ndice pode ser usado para

realizarmos uma comparao entre dois diferentes editores de texto, dando aconcluir qual o editor que oferece uma interface mais amigvel ao usurio.


13/32

No devemos esquecer de que os demais parmetros de configurao dehardware e de software devem ser exatamente os mesmos, ou seja, uma mesmamquina 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 visualque 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 veramosa correspondente imagem dos seus dados na Figura 24. Para cada possvelimpresso 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 editoresde 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 Nmero de usurios

Editor 1 Editor 2

Muito difcil 10 15

Difcil 20 30

Indiferente 10 10

Fcil 30 25


14/32

Super fcil 30 20

TOTAL 100 100

Os dados na tabela 13 so apenas dados numricos com

representatividade, mas sem entendimento imediato (tambm so fictcios, apenasservem para ilustrarmos).

Agora preste ateno na Figura 25, os dados foram transformados eminformaes de fcil discernimento atravs de barras coloridas que distinguem osresultados obtidos dos dois editores e com o auxlio da legenda podemos identificarquantas pessoas expressaram suas opinies dentro do intervalo de conceitos enotas atribudas.

FIGURA 25 GRFICO DE BARRAS: COMPARATIVO DOS EDITORES.

Pelo grfico constatamos que h maior dificuldade dos usurios emutilizarem as ferramentas do segundo editor de texto, pois suas curvas acusam que

mais da metade (55 pontos) foram atribudos a dificuldade enquanto que o primeiroeditor 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 oaspecto da dificuldade como expresso da caracterstica maior do editor: ausabilidade. Mesmo que fossemos declarar a usabilidade atravs do aspecto dafacilidade de uso, chegaramos a mesma concluso: o editor1 apresenta melhoresrespostas.


15/32

FIGURA 26 GRFICO DE PIZZA: COMPARATIVO DE EDITORES.

Com os grficos da Figura 26 teremos a mesma concluso extrada dogrfico de barras da Figura 25. Observando que em um nico histograma foisuficiente para chegarmos a uma idia conclusiva, os grficos de pizza por editorneste 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 degrficos mais til ao gerente de uma equipe de desenvolvedores do que clculosde varincia e projees.

Para que tenhamos a viso geral da relevncia do uso de mtricas naprtica do Gerenciamento de Desenvolvimento de Software, observemos o papeldas mtricas quando possumos dados histricos do funcionamento de um softwarecujo projeto deve ser modificado (Figura 27).

As informaes coletadas por meio de mtricas aplicadas em modelosanteriores e de controles de projetos de software em andamento (fase de testes edocumentao) daro subsdios para aes corretivas e preventivas no novo projetode software, conduzindo um gerente de desenvolvimento de software a ter previsesmais acertadas.


16/32

FIGURA 27 USO DE MTRICAS E DE DADOS HISTRICOS

1.3.2 Mtricas Orientadas a Tamanho ou Funo

As mtricas de software orientadas ao tamanho so medidas diretasbaseadas 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 decomandos;

Nmero de pginas de documentao gerada por software;

Nmero de erros existentes aps a entrega do sistema ao cliente dentro deum perodo de um ano de operao, excluindo-se o perodo de testes;

As observaes desses aspectos geram dados tabelados, exemplificadospara efeitos de compreenso na Tabela 14, conforme abaixo.

TABELA 14 Mtricas orientadas ao Tamanho

Software Esforo KLOC Pginas

Documentadas

erros

Finanas 3 12,1 430 4

Operacional 4 28 1024 7

Logstica 7 19,5 925 3

Mdica 15 25,5 1459 8

Estoque 3 10 400 2

ProjetoTerminado

Projeto emAndamento

ProjetoFuturo

Dadoshistricos

Mtricas PrevisesControles


17/32

As mtricas orientadas ao tamanho podem provocar controvrsias e no sopadronizadas internacionalmente por no serem aceitas como a melhor ou a nicamaneira de medio do desenvolvimento de um programa. A maior parte dacontrovrsia gira em torno do uso das linhas de cdigo como a medida-chave.

Os opositores a essas mtricas por tamanho afirmam que o nmero delinhas de comandos depende da sintaxe, da semntica e do tipo de linguagem deprogramao adotada por uma equipe de desenvolvedores (linguagem orientada aobjeto ou linguagem procedural).

Por outro lado, as mtricas orientadas Funo so medidas indiretascoletadas e registradas sobre a funcionalidade ou utilidade do programa. Ao invsde contar o nmero de linhas e erros de um programa, nessa mtrica sugerido omtodo depontos-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

Conceitos

E

PontosS/influncia

Incidental

Moderado

Mdio

Significativo

Essencial

Perguntas 0 1 2 3 4 5

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 dosconceitos vistos no item anterior (1.3.1. Viso geral), onde realizamos ummapeamento qualitativo e quantitativo de requisitos e de desempenho, com a

finalidade de adiantarmos as prioridades de respostas e o comportamento que


18/32

dever ter o novo sistema, observando a caractersticas de um menor nmero deerros aps a entrega.

1.3.5 Estatsticas prticas

Alguns resultados em estatsticas so ao mesmo tempo bsicos e teis paraa anlise global das medidas que foram efetuadas sobre as qualidades dossoftwares, entre elas citamos: mdia e a varincia.

No caso das mdias a representao do resultado mais provvel eesperado da execuo. Num exemplo de medies de tempo de resposta paraconsultas, via rede, de um banco de dados, referenciados em segundos, o clculoseguir a somatria de todos os tempos de amostragem (TP1 a TPn), dividido pelonmero de medidas efetuadas (n).

M = (TP1+TP2+...+TPn)n

A varincia uma indicao dos intervalos de valores prximos a mdia. Seo valor da varincia for pequeno, ento as medies esto pouco espalhadas emtrono da mdia. Por outro lado, se o valor da varincia for igual a zero, conclumosque 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 asnovidades vital.

A organizao do trabalho da equipe de desenvolvedores em grande parteresolvida pelo uso de metodologias como CMMI. Contudo, um mtodo de trabalhono estar completo se no houver compreenso do mtodo organizacional eenvolvimento de cada elemento do grupo, reconhecendo o seu papel individual ecoletivo que est exercendo.

A equipe tcnica dividida em grupos para desenvolver diferentes mdulosprecisa de comunicao. Portanto, garantir que todos os indivduos de todos osgrupos tenham em mente o desenvolvimento de seu mdulo em consonncia com odesenvolvimento dos demais mdulos primordial, pois precisar do apoio deindivduos de outros grupos e para isso precisar se comunicar eficientemente.

Outro aspecto a criatividade individual destituda da individualidadeegocntrica. Parece uma crtica, mas uma observao a ser feita diante de umaequipe de pessoas inteligentes, experientes e autodidatas. Trabalhar em equipe,muitas vezes, determina a perda de padres de desenvolvimento pessoais.


19/32

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 nveisno so o padro mundial, eles compartilham com outras classificaes.

Galgar nveis de maturidade significa que uma empresa e todos os seusdepartamentos 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 SistemaKaisen que foi introduzida nas empresas japonesas do grupo Toyota, inicialmenteconcebida para ambientes de produo fabril. Com o sucesso de tal metodologia, osucesso encorajou desdobramentos em outros campos como o da TI.

No Sistema Kaisen aparecem noes de disciplina, asseio e organizao emtodos os espaos individuais e coletivos de uma empresa. No espao individual,porexemplo: ferramentas, objetos, canetas, equipamentos devem estar posicionadosem lugares apropriados e em bom estado. Tambm conhecido como os 5S(referentes s iniciais das palavras japonesas: Seiri, Seiton, Seisoh, Seikrtsu eShitsuke), 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;


20/32

3S: limpeza geral, ou melhor, alm da limpeza do ambiente, preocupa-se coma 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 orestante 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 comoum software, cujas caractersticas so subjetivas e abstratas?

A resposta esclarecedora est na m interpretao e na m aplicao dametodologia. A filosofia Kaisen (5S) pode servir como um mtodo de trabalho aosdesenvolvedores tambm. Portanto, vejamos como fazer a ligao dos conceitosdos 5S construo de softwares:

1S: tudo o que no necessrio deve ser jogado fora as rotinasnecessrias devem ser implementadas, evitando-se por outro lado todas as linhas

de comando que sejam inteis ao usurio. Deve-se simplificar o software tendocomo consequncia a facilitao as atividades do usurio do software;

2S: organizao do espao e do mtodo de trabalho o cdigo-fonte e osdiagramas e documentos do sistema devem ser identificados de forma clara elgica.

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 semostraram 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 dosdocumentos e dos testes, vocabulrio devem seguir um padro na equipe tcnica ouna empresa;

5S: disciplina e submisso s recomendaes e prticas de trabalho. Cabe o

restante da mxima: usou, limpou! Guardou no mesmo lugar. est diretamentemais relacionado ao bem estar e qualidade de vida dos indivduos pertencentes


21/32

equipe tcnica do que ao software em si, porm reflete de igual forma nodesenvolvimento do sistema, pois teremos um ambiente de trabalho mais salutar ecom pessoas bem dispostas e comprometidas com a viso do todo.

3. NORMAS ISO/IEC

A simples meno do vocbulo norma nos remete o pensamento aosprocessos de engessamento da criatividade e sufocamento das individualidades.

Mero engano! As normas so partes integrantes das frmulas de sucessoem todas as atividades humanas. O que seria do trnsito se no existissem asnormas (ou padres) de direo dos veculos automotores, chamadas de leis detrnsito? 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 emnossa profisso de analistas e desenvolvedores de software.

No faz parte do escopo deste fascculo e nem de nossa disciplina o estudoaprofundado de cada norma, mas estaremos apresentando o que maisinteressante e aplicvel ao Gerenciamento de Desenvolvimento de Software.

3.1 ISO/IEC 15504

Esta norma apresenta uma estrutura para realizao de avaliaes deprocessos em organizaes e est dividida como mostra a Tabela 16.

Para que a ISO/IEC 15504 tenha efeito sobre a qualidade de software, eladeve ser complementada com a ISO/IEC 12207.

TABELA 16 Divises da ISO/IEC 15504

Parte Publicao Descrio

1 2004 Conceitos e vocabulrio

2 2003 Estrutura de avaliaes3 2004 Recomendaes de realizao de avaliaes

4 2004 Recomendaes de melhoria de processos

5 2006 Exemplo de aplicao

Sua aplicao geral sobre situaes como:

Melhorias internas nas empresas;

Avaliaes das atividades de empresas terceirizadas ou de fornecedores de

produtos.


22/32

3.2 ISO/IEC 12207

Ao definir esquemas de qualidade em uma empresa, referncias como oCMMI so importantes, uma vez que permitem traar um objetivo a ser alcanado.

Mas a definio de uma estrutura de processos para se alcanar o objetivotem 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 apartir do qual cada empresa tem autonomia para definir a sua prpria estrutura e oencadeamento de seus processos.

Os processos dessa norma esto exemplificados na Tabela 17 edetalhadamente descritos no texto da ISO/IEC 12207. Como vemos so

classificados em trs categorias:

Primrio: processos bsicos de produtos de software, tais como: processo dedesenvolvimento, 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 De apoio Organizacionais

Aquisio Documentao Gerenciamento

Fornecimento Gerncia de configurao Infraestrutura

Desenvolvimento Garantia da qualidade Treinamentos

Operao e manuteno Verificao/validao Melhoramentos

Revises e auditorias

3.3 ISO/IEC 25000

Para completar o estudo das normas, alm das normas ISO/IEC 15504 eISO/IEC 12207, temos que estudar especificamente uma norma responsvel pelacaracterizao 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


23/32

Software). Ela est dividida em cinco componentes, conforme a disposiovisualizada na Figura 28:

FIGURA 28 COMPONENTES DA NORMA SQuaRE.

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 softwareconhecidos por SW-CMM e CMMI.

Surge logo a pergunta: o que significa SW-CMM? A sigla entre tantas outrasque estudamos em nosso curso e em especial em nossa disciplina, significa aCapacidade de Maturidade de Modelos para Software.

Por ser um modelo especfico rea de software, no esto includas asoutras reas de uma organizao, como RH e Finanas. Mesmo assim, um fatorde relevncia na busca pela melhoria da eficcia e da competitividade, focalizandonos processos de automao em um curto prazo.

4.1 SW-CMM ORIGEM E NVEIS

O objetivo principal do SW-CMMI que as empresas aprendam comodesenvolver melhor os seus softwares implementando melhorias em seus

processos. Essas melhorias, ao contrrio do que muitos estudiosos pensam, estobaseadas em cinco pequenos passos e no em grandes revolues organizacionais.

So cinco nveis diferentes, cada passo corresponde a um nvel dematuridade de processos e so classificados como:

Nvel 1: Inicial.

A empresa que for classificada neste nvel tem dificuldades de planejamentoe enfrentam problemas de erros em cronogramas, sempre contando comimprevistos. Por isso, a falta de credibilidade em planejamento leva a umdesenvolvimento confuso de software.

Requisio

De

Qualidade

2503n

Modelo de Qualidade

2501n

Avaliao

2504n

Gerenciamento de Qualidade

2501n

Medies

2501n


24/32

Os responsveis e a equipe de desenvolvimento dos programas ou sistemasda empresa passam dos requisitos para a codificao sem se importarem comoutros 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, comprazos e custos, considerando o que aprendeu com outros processos anteriores.Assim, quando j se tem experincia suficiente em desenvolver aplicaes emplataforma WEB, passar a fazer uso de seu Know-how em projetos futuros.

Mesmo dando indcios de disciplina, essas empresas ainda no so capazesde adotar novas ferramentas e novos mtodos, devido se manter na perspectiva defazer o que sabe e o que deu certo.

Nvel 3: Definido.

Um nvel acima do que o anterior significa que essas organizaesestabelecem uma adaptao mudana de seus processos. Repetem os sucessosde projetos anteriores e evoluem com novas iniciativas de melhorias.

Os processos de documentao, por exemplo, so bem realizados e apiamos gerentes e equipes de desenvolvedores em suas novas decises e objetivos,evitando as no-conformidades e impactos indesejveis na qualidade de seussoftwares.

Nvel 4: Gerenciado.

A administrao dos processos evolui para a parametrizao da base dadosdos projetos anteriores atravs de mtricas. A produtividade e a qualidade sogerenciveis e os processos sofrem contnuas melhorias. A vigilncia de aspectosquantitativos 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 atitudescorretivas.

A equipe, alm do gerente, tem uma postura pr-ativa e de autonomia paraimplementar melhorias em seus processos. O que demonstra um crescimento daviso e o comprometimento de avaliar a produtividade do trabalho.

Os defeitos so identificados, resolvidos e estudados por todos para que noocorram novamente nos novos projetos de software.

5. MODELO BRASILEIRO MPS.BR


25/32

Os pesquisadores brasileiros tm dado suas contribuies para melhoria dosprocessos de desenvolvimento de software. O MPS.BR (Melhoria de Processos doSoftware 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 quenecessitam evoluir sua produo de sistemas com qualidade e possui poucosrecursos diante de tal desafio em um contexto especfico: o brasileiro. Osdiferenciais desse mtodo so:

Sete nveis de maturidade, possibilitando uma implantao mais gradual eadequada ao porte da empresa;

Compatibilidade com SW-CMMI e com a norma ISO/IEC 15504;

Voltado para o mercado de micros, pequenas e mdias empresasdesenvolvedoras de sistemas;

Custo acessvel;

Avaliao bienal das empresas;

Forte interao entre Universidades e empresas.

A descrio deste modelo tem trs guias para sustentar os diferenciascitados acima:

Guia Geral: Contendo a descrio do MPS.BR e o detalhamento do modelode referncia (MR-MPS), seus componentes e as definies comuns necessriaspara estudos e prticas.

Guia Aquisio: Possui recomendaes para a conduo de compras e deservios correlatos ao desenvolvimento de software.

Guia de Avaliao: Contm os requisitos para o avaliador, o mtodo e osformulrios para guiar a avaliao.


26/32

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

5.2 NVEIS DO MPS.BR

Como mencionado no item 5, so sete nveis que compem o MPS.BR. paracada nvel foi definido dois perfis comuns: um perfil de processos e um perfil decapacitao de processos. Tais informaes de perfis colaboram no sentido dedirecionar esforos de melhorias para atender os objetivos de negcio da empresa.

A classificao dos sete nveis feita seguindo uma ordem alfabtica, ondeos processos ligados ao nvel G so considerados os mais bsicos. E no outroextremo da classificao, os processos do nvel A so os mais avanados.

A Tabela 18 resume correspondncia entre os processos e os nveissegundo essa classificao do MPS.BR. Vejamos:

MR-MPS MA-MPS MN-MPS

MPS.BR

CMMI ISO/IEC 15504 ISO/IEC 12207

Realidade das empresas brasileiras

Guia Geral

Guia de Aquisio

Guia de Avaliao


27/32

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

Tipo Nvel Processos

A Em otimizao Inovao na empresaAnlise de causas/solues.

BGerenciado

quantitativamente

Desempenho do processo organizacional.

Gerncia Quantitativa

C DefinidoAnlise de decises e resolues

Gerncia de Riscos

DLargamente

definido

Desenvolvimento de requisitos

Soluo tcnica

Integrao de produto

Instalao de produto

Liberao de produto

Verificao

Validao

EParcialmente

definido

Treinamento

Melhoria do processo organizacional

Definio do processo organizacional

Adaptao do processo para Gerncia de Projetos.

F Gerenciado

Medio

Gerncia de Configurao

Aquisio

Garantia da Qualidade

GParcialmentegerenciado

Gerncia de Requisitos

Gerncia de Projeto

6. METODOLOGIAS GEIS

Diversas metodologias foram criadas para sistematizar o estudo dodesenvolvimento de softwares. Essas metodologias foram divididas em dois grandesgrupos: as tradicionais e as geis.

As metodologias tradicionais enfatizam a documentao de cada fase doprojeto de desenvolvimento do sistema, enquanto que as metodologias geis

prometem implementar um novo paradigma: melhorias na produo do software comqualidade.


28/32

O resultado esperado de qualquer tipo de metodologia a produo e agarantia de qualidade de um sistema. Para isso, elas tm em comum as seguintesatividades:

Especificao: definio das funcionalidades e demais caractersticas dosoftware;

Projeto e implantao: proposio do modelo em forma de diagrama quesero codificados em uma linguagem de programao;

Validao: atividades de testes e reviso do software de acordo comrequisitos;

Evoluo: atividades de manuteno do programa para novas demandas docliente;

Entre as mais difundidas metodologias geis podemos citar duas: a ExtremeProgramming (XP) e a Scrum.

A XP voltada para equipes pequenas e mdias e que desenvolvemsoftwares baseados em requisitos vagos, assim como determina atividadesconstantes de feedbacke encorajamento de comunicao entre as pessoas. A idiacentral a simplicidade (cdigos enxutos) e a rapidez na entrega do software.

A Scrum tem por objetivo o fornecimento de processos voltados aodesenvolvimento de software orientado a objetos. O foco central encontrar umaforma de trabalho dos membros para flexibilizar a produo de software emambientes dinmicos, que tm como caracterstica mudanas constantes denecessidades.

Para que no acumulem problemas e sejam gerados erros nos cdigos dosprogramas, as reunies da equipe so curtas (15 minutos) e dirias e tm ciclosinterativos, chamados de sprints com durao de trinta dias.

As duas metodologias tm em comum o curto espao de tempo parapromover as solues que aparecem com frequncia e dar respostas a requisitosinstveis.

7 ASPECTOS DA QUALIDADE E DA GARANTIA DA QUALIDADE DESOFTWARE

Estudamos at este momento os aspectos de qualidade no desenvolvimentode um software e parece que o termo garantia est relacionado a uma etapa

posterior gerao do software. Se assim pensamos, estamos longe da verdade!


29/32

Dentro da Engenharia de Software a Garantia de Qualidade de Software(SQA Software Quality Assurance) abrange mtodos ao longo de todos osprocessos 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: asmudanas. So nessas fontes que as introdues e a propagao de erros sopercebidas. O desafio escrever cdigos que podem ser mudados futuramente semcausarem transtornos para os demais mdulos do sistema.

A anotao e manuteno de registros de mediadas e aes de qualidadede software oferecem a coleta e a disseminao de informaes para garantir uma

melhor produo. Para a SQA esses registros so feitos periodicamente atravs derelatrios tcnicos de reviso.

Um exemplo de relatrio depende de informaes, tais como podemos verna figura abaixo:

FIGURA 30 RELATRIO TCNICO DE REVISO

Relatrio Tcnico de Reviso

Identificao da reviso:

Projeto: Projeto 1 nmero da reviso: AA-xxx

Data: dd/mm/aaaa local e horrio:

Identificao do produto:

Material revisado: Mdulo 1

Desenvolvedor: Milton

Descrio: insero de varivel de controle de lao.

Material revisado:

1. Linhas de cdigos do mdulo 1.

2. Documentao do software, pg. 32.

Equipe de reviso:

1. Nome1 assinatura:



Avaliao do projeto:

( ) Aceito como est ( ) Com pequenas modificaes

( ) No aceito ( ) Com revises significativas

Material suplementar anexo:

( ) lista de questes ( ) Materiais produzidos e anotados

( ) Outras observaes:


30/32

Com esses relatrios realizada a anlise estatstica das ocorrncias deinformaes e categorias de erros, de rastreamento dos defeitos e de providnciaspara correo.

A utilizao de uma simples planilha eletrnica permite o gerenciamento de

quantos erros ocorreram por processos ou por projetos, qual a periodicidade e quaisas causas por categorias, etc.

possvel o Gerenciamento de Desenvolvimento de Software atravs daaplicao das metodologias estudadas de Qualidade de Software com vistas Garantia da Qualidade de Software. Esse elo muito forte.


31/32

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 fatorcontribuinte a qualidade de software.

As contribuies humanas em conjunto com o nvel de maturidade dasempresas formam um importante aspecto do sucesso de um software, sendoverificado no item 2 dessa unidade.

Outro fator que tem papel fundamental na atividade de gerenciamento oconhecimento das normas nacionais e internacionais. Suas estruturas, suas

divises, seus modelos e sua filosofia so expostos com a finalidade de estabelecerapoio s decises gerenciais.

Dentre os modelos estudados chamamos a ateno do MPS.BR, comoreferncia a padres adotados dentro do contexto de micro, pequenas e mdiasempresas brasileiras.


32/32

TI Gerência de Desenvolvimento de Software - UNIDADE 3

Documents

Transcript of TI Gerência de Desenvolvimento de Software - UNIDADE 3