TI Gerência de Desenvolvimento de Software - UNIDADE 3
-
Upload
anderson-marques-neto -
Category
Documents
-
view
222 -
download
0
Transcript of 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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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;
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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;
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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!
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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:
2. Nome2 assinatura:
3. Nome3 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:
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
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.
-
8/6/2019 TI Gerncia de Desenvolvimento de Software - UNIDADE 3
32/32