RESUMO DA MATÉRIA - ENGENHARIA DE SOFTWARE II - UNIP EAD

Prévia do material em texto

Professora Priscila Facciolli 
Unidade I – Videoaula I 
 
Conceitos sobre Qualidade de Software: Segundo a norma NBR ISO (2000a), qualidade de 
software é definida como um conjunto de características que devem ser alcançadas em um 
determinado grau para que o produto atenda às necessidades de seus usuários. 
 
Para Crosby (1990) existem cinco princípios básicos da qualidade que, se seguidos, 
produzirão melhores resultados: Fazer certo na primeira vez, Processo preventivo, Atenção às 
necessidades dos usuários, Responsabilidade de todos e Melhoria contínua. 
 
Benefícios da Qualidade de Software: Aumento da produtividade;  Redução de defeitos no 
produto;  Aumento da confiabilidade do produto;  Menos retrabalho;  Menos horas 
extras de trabalho;  Maior satisfação dos clientes. 
 
Obstáculos da Qualidade: fatores que são opostos às boas práticas e que acabam por criar 
dificuldades à implementação do processo de qualidade em uma empresa 
 
- Cultura da organização, Custo e prazo mal definidos, Envolvidos não identificados. 
 
Visões da Qualidade: As visões no desenvolvimento de um software envolvem os gerentes, os 
desenvolvedores, os clientes e os usuários. 
 
 
Garantia da Qualidade: A garantia da qualidade avalia se as características do produto estão 
de acordo com os padrões estabelecidos e se as atividades estão ocorrendo conforme o 
planejado. 
 
Controle de Qualidade: São atividades de qualidade realizadas após o produto de software 
estar pronto. Seu objetivo é permitir o aceite do produto, atestando que a aplicação está de 
acordo com as especificações. 
 
No controle da qualidade, avalia-se se as ações de qualidade planejadas estão sendo 
executadas de acordo com o processo estabelecido. Essa atividade chama-se Auditoria. 
 
- Tipos de auditoria: 
• Auditorias de produto: foco em verificar a conformidade de produtos com os padrões 
estabelecidos; 
• Auditorias de processo: se as ações planejadas estão sendo executadas; 
• Auditorias de sistemas de qualidade: avaliam a eficácia da implementação desse 
sistema e determinam o grau em que os objetivos estão sendo atingidos. 
 
 
 
Unidade I – Videoaula II 
 
A NBR ISO 9000 – Normas de Gestão da Qualidade e Garantia da Qualidade – nos trás a gestão 
e garantia da qualidade, serve como arcabouço-padrão para definir como as demais normas 
específicas devem ser utilizadas. Pode ser considerada a “mãe” das normas que regem 
qualidade empresarial. 
 
O ISO 9000 permite que a empresa passe por uma mudança que será voltada para a gestão 
com qualidade total. A qualidade total significa ter excelência organizacional e satisfação dos 
clientes, colaboradores, fornecedores e sociedade. Uma produção com qualidade demanda 
corte de gastos, o que gera um preço final menor. Além disso, há o cuidado com o meio 
ambiente e a preocupação com a satisfação de funcionários. 
 
ISO 9001 – Sistemas da Qualidade – Qualidade em Projeto, Desenvolvimento, Produção, 
Instalação e Assistência Técnica; 
 
ISO 9000-1 – Normas de Gestão da Qualidade e Garantia da Qualidade – Parte 1: estabelece os 
princípios gerenciais que permeiam toda a série de normas 
 
ISO 9000-3 – Normas de Gestão da Qualidade e Garantia da Qualidade – Parte 3: esta norma 
define diretrizes para facilitar a aplicação da norma ISO 9001 a organizações que desenvolvem, 
fornecem e mantêm software. 
 
As normas básicas para garantia da qualidade são as contratuais – ISO 9001, ISO 9002 e ISO 
9003. 
 
Unidade I – Videoaula III 
Gestão da Qualidade do Produto de Software 
 
 
 
Modelo McCall: Jim McCall desenvolveu um modelo de qualidade para o Departamento de 
Defesa Americano em que a qualidade é definida por um conjunto de características internas e 
externas de um software, tornando-se o primeiro modelo de qualidade a ser amplamente 
divulgado e utilizado. São três visões: Revisão, Operação e Transição, com 11 processos. 
 
SO/NBR 9126 – Característica de Qualidade do Produto de Software 
 
Fornece um modelo geral que define seis categorias de características de qualidade do 
produto de software divididas em subcaracterísticas. São elas a funcionalidade, 
confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. 
Estas características podem ser avaliadas por métricas quantitativas, que permitem dizer se o 
software satisfaz as necessidades e padrões estabelecidos pelo desenvolvedor e usuário. 
 
- Tipos de métricas: métricas internas, métricas externas e qualidade de uso. 
 
https://blog.delogic.com.br/importancia-da-gestao-da-qualidade/
https://blog.delogic.com.br/importancia-da-gestao-da-qualidade/
ISO/NBR 12207 – Ciclo de Vida do Software 
 
A norma define um conjunto de processos que padroniza as atividades e orienta o 
desenvolvimento, a manutenção e a aquisição para as empresas de desenvolvimento de 
software. Sua implantação em uma empresa de software vida padronizar e aferir qualidade em 
quaisquer ciclos de vida de softwares utilizados. É dividida em processos fundamentais, 
processos de apoio, processos organizacionais e processos adaptativos. 
 
- Processos fundamentais: Execução do desenvolvimento, da operação e da manutenção do 
software durante o seu ciclo de vida. 
 
- Processos de apoio: Definem as tarefas que auxiliam outros processos, principalmente as 
relacionadas à qualidade do software. 
 
- Processos organizacionais: Definem as tarefas que permitem a manutenção ou a melhoria 
contínua dos processos. 
 
- Processos de adaptação: Proporciona a flexibilidade necessária a todo processo e permite 
que a norma seja adaptável a qualquer empresa de desenvolvimento. 
 
Unidade I – Videoaula IV 
 
ISO/IEC 14598 – Avaliação do Produto de Software 
 
Seu objetivo é padronizar a avaliação da qualidade do produto de software. É um 
complemento da norma ISO/IEC 9126 e deve ser utilizada em conjunto com esta. 
 
Definição do Processo de Avaliação: Descreve o processo de avaliação do produto de software 
sob três perspectivas: desenvolvedor, adquirente e avaliador. Cada perspectiva possui quatro 
fases distintas no processo de avaliação: análise, especificação, projeto e execução. 
 
 
ISO/IEC 25000 – SQuaRe (Software Product Quality Requirements and Evaluation) 
 
É a nova versão das normas ISO/IEC 9126 e ISO/IEC 14598. Especifica e avalia a qualidade do 
produto de software . Unifica o processo de medição da qualidade do software. Atualiza as 
informações de requisitos de qualidade. 
 
 
 
 
 
Unidade II – Videoaula II 
 
Qualidade para o processo de software 
Auxilia as empresas a construírem uma estrutura adequada e robusta para a produção do 
software e orienta a respeito de como podem evoluir e atingir graus de maturidade cada vez 
mais elevados. 
 
 
ISO/IEC 15504 – SPICE – melhoria do processo de software: É o resultado da combinação do 
CMM, da norma ISO/IEC 12207, da qual trouxe os processos de ciclo de vida, da ISO 9001, da 
ISO 9000-3, dentre outros. 6 níveis de maturidade que permitem a avaliação do grau de 
qualidade em que as organizações se encontram. Dividido em duas partes: processo de 
desenvolvimento e processo de capacidade 
 - Está dividido em duas partes: processo de desenvolvimento e processo de 
capacidade. 
 
Maturidade: graus de conhecimento e de execução das melhores práticas de Engenharia de 
Software que levam as empresas a produzirem software com qualidade. 
 
Interatividade: Qual é a proposta da ISO/IEC 15504 para as organizações que desejam essa 
certificação? 
- Melhoria do processo de software e determinação da capacidade. 
 
Unidade II – Videoaula III 
CMMI – áreas de processos 
 
 
 
Área de Gerenciamento de Processos: Áreas relacionadas às ações organizacionais que 
permitem a definição, a implantação, o monitoramento, a avaliação e a medição dos 
processos. 
 
Áreas de gerenciamento de projetos: Descrevem e definem as boas práticas para o 
planejamento, a execução, o controle e o encerramento dos projetos de software. 
 
Áreas de engenharia: Envolvem as áreas de processo voltadas para a construçãoe a 
manutenção do software. 
Áreas de suporte: Relacionam as áreas de processo que servem de apoio ao desenvolvimento 
e à manutenção do software. 
 
Unidade II – Videoaula IV 
Melhoria de processos do software brasileiro (MPS.BR) 
 
Objetivo: incentivar as pequenas e as médias empresas brasileiras de produção de software; 
Implantar um modelo de qualidade de melhoria de processo com custos mais acessíveis à 
realidade brasileira; 
 
- Auxilia as organizações a compreenderem todos os componentes envolvidos no 
desenvolvimento e na aquisição do software, bem como a executarem projetos de forma mais 
eficiente. 
 
- O modelo está dividido em 4 componentes, 7 níveis de maturidade e 19 processos 
distribuídos nos níveis definidos. 
 
Níveis de maturidade (São 07 ao total) 
 
 
Unidade III – Videoaula I 
Verificação e Validação de Software 
 
Garante que o produto seja construído corretamente, para que os esforços de correção de 
problemas causem o menor impacto possível. 
 
Verificação: Consiste nas ações realizadas ao final de cada fase. O Objetivo é atestar que o 
produto está sendo desenvolvido corretamente. 
 
Validação: Consiste nas ações realizadas ao final ou no decorrer do processo de 
desenvolvimento. O objetivo de avaliar se o produto está de acordo com as especificações de 
requisitos iniciais fornecidas pelo cliente e garantir que o produto tenha sido desenvolvido 
corretamente. 
 
Revisões técnicas: Avaliação crítica de todos os artefatos produzidos durante o 
desenvolvimento de um software, em pontos predefinidos do ciclo de vida. Seu objetivo é 
encontrar e corrigir erros inseridos durante o processo. 
 
Revisão Técnica Formal (RTF): Deve ser estruturada. Conduzida em uma reunião e será tão 
bem-sucedida quanto for planejada e controlada. Deve ser realizada sobre artefatos para 
permitir melhor avaliação e aumentar as probabilidades de sucesso. 
Passeio (walkthrough) 
São revisões técnicas informais, também chamados de revisão por pares, mas podem ter até 
três participantes: autor, revisor e moderador. 
 
O revisor pode ser um técnico, um cliente ou uma pessoa externa ao projeto que domine o 
assunto em revisão. 
 
O moderador não deve ser do mesmo nível hierárquico do autor e do revisor. 
 
Revisões progressivas por pares 
 
Constituem características da walkthrough e da RTF. 
 
Artefato é dividido em partes e distribuído aos revisores; 
 
 O artefato deve ser separado e distribuído aos revisores; 
 
Na revisão, cada revisor faz a leitura do artefato. 
 
Unidade III – Videoaula II 
Técnica de Inspeção 
 
Técnica formal, em que os envolvidos examinam os artefatos produzidos contra uma 
especificação inicial com o objetivo de encontrar incoerência e erros; 
 
Realizada a qualquer momento dentro do ciclo de vida de um produto de software; 
 
Envolve pessoas com domínio do assunto que está sendo inspecionado e possui um checklist 
dos pontos que devem ser verificados no artefato. 
 
Processo de inspeção é composto de seis etapas: 
 
 
 
- Planejamento: Previsão da inspeção dos artefatos no cronograma do processo de 
desenvolvimento de software, sem o qual a formalidade prevista não será atendida. 
- Apresentação: Etapa opcional diretamente ligada ao tamanho e à complexidade do artefato 
a ser inspecionado. No caso de ocorrer, há uma explicação sobre seus pontos principais. 
- Preparação: Leitura prévia de toda a documentação dentro do tempo planejado. 
- Inspeção: Apresentação do artefato por partes, para que os inspetores façam os 
questionamentos e apontamentos de correção, que são registrados pelo escritor. O processo 
se repete até que todo o artefato seja inspecionado. Ao final, a equipe faz as considerações de 
melhoria e decide se o artefato será aceito, aceito com ressalvas ou se necessita de nova 
inspeção. 
- Correção: As correções e melhorias são realizadas com registro das respectivas soluções. 
-Revisão: Situação final da inspeção. O coordenador de inspeções recebe o documento final da 
inspeção 
 
 
 
Técnica Sala limpa (Cleanroom) 
 
Baseada em especificações formais matemáticas e destinada ao desenvolvimento de software 
de alta confiabilidade como os utilizados no controle de usinas nucleares, na navegação de 
aviões, trens, metrôs e navios, dentre outros. O foco da sala limpa é a realização de ações 
preventivas, e não a correção de erros. 
 
Unidade III – Videoaula III 
Teste de Software 
- Segundo Myers (2004), testar um software é um processo de executar um programa ou 
sistema com a intenção de encontrar defeitos. 
- Para Dijkstra (1970), os testes podem mostrar a presença de falhas em um software, mas 
nunca a sua ausência. 
 
Conceituação de Defeito, Erro e Falha 
 
 
Principais tipos de defeitos 
 
 
Técnica de teste Modelo V 
Foi desenvolvido a partir do Cascata. 
Inclui o processo de testes desde o início do ciclo de desenvolvimento do software. 
Foco: Permitir a identificação de defeitos o mais corretamente possível, por meio de atividades 
de verificação e validação e da criação de casos de testes e roteiro de testes. 
 
 
 
 
 
 
 
Modelo V 
 
 
Roteiro de teste: O roteiro de testes que descreve em detalhes o passo a passo para a 
realização dos testes, especificando o que deve ser feito e qual o resultado esperado. 
 
Testes de unidade ou testes unitários: são testes realizados pelo desenvolvedor e garante que 
cada módulo seja testado por vez. 
 
Testes de integração: Realizados após o teste unitário para garantir que os elementos que 
compõem a aplicação funcionem de forma integrada com sucesso. 
 
Teste de Sistemas: Verificam se o software desenvolvido está de acordo com a especificação 
inicial do sistema. 
 
Teste de Aceitação: Realizados pelos usuários finais e analistas de testes. Garantem que todos 
os requisitos solicitados foram incluídos e funcionam corretamente no produto entregue. 
 
Teste de Regressão: Quando há manutenção do sistema, toda a aplicação deve ser testada 
para garantir que nenhuma rotina que tenha sido afetada pela mudança contenha erros. 
 
Teste de Funcionais (Caixa-preta): Envolvem o correto funcionamento do software, sua 
integração com outros sistemas, suas interfaces e a garantia de que qualquer alteração feita 
não afete a aplicação. Preocupa-se com os requisitos funcionais sem a necessidade de 
debugar o código fonte 
 
Teste Estrutural (Caixa-branca): Avalia a qualidade do código fonte produzido pelos 
desenvolvedores, garantindo que toda linha de código escrita seja executada pelo menos uma 
vez e não contenha erros. 
 
Unidade III – Videoaula IV 
 
Casos de Testes: Situação que o sistema apresenta para a qual, dada uma informação de 
entrada, será gerada uma saída esperada pelo usuário. 
 
Roteiro de Testes: Descrição detalhada do passo a passo para a execução do sistema, a fim de 
verificar cada caso de teste identificado na fase anterior. 
 
Testes Funcionais em Interfaces: Esses casos de testes são importantes para garantir que a 
interface faça as verificações necessárias para tornar o software mais robusto e confiável com 
os dados de entrada. 
 
Testes em processos ágeis: Colaborar com a solução dos defeitos e não apenas apontá-los, por 
meio da identificação das causas desses defeitos, para que não voltem a acontecer. 
 
Como funciona uma equipe ágil com relação aos testes? 
 - Todos devem possuir habilidade para testar e todos trabalham em conjunto, com 
interação constante durante todo o ciclo de desenvolvimento do software. 
 
Unidade IV – Videoaula I 
Manutenção de software 
 
O software precisa sofrer alterações e evoluções para continuar a ser utilizado de maneira 
adequada pelos usuários. 
 
A Norma ISO/IEC 14764 (2006) unifica a terminologia para manutenção de software: 
 Manutenção: modificação de um produto, corrigir defeitos, melhorar o desempenho, 
adaptar o produto a um ambiente de mudança, incluir novas funcionalidades ou recursos não 
previstos anteriormente; 
 Evolução: Gerar uma nova versão do produto com rotinas relevantes; 
 Alteração: mudançasrealizadas no código do software (defeitos ou novas rotinas); 
 Melhoramento: Melhorar o desempenho, a segurança ou adaptá-lo a novos ambientes; 
 Linha de base: uma versão aprovada formalmente pelo cliente; 
 Pedido de mudança: Solicitação de uma mudança; após a correção, pode ser classificado 
como uma correção ou uma melhoria; 
 Plano de manutenção: Descreve as práticas específicas, os recursos e as atividades 
relevantes para a manutenção; 
 Processo de manutenção: Tarefas para a realização da manutenção. 
 
---- TIPOS DE MANUTENÇÕES 
 
- Manutenibilidade indica quão fácil é fazer uma alteração, uma correção ou uma melhoria em 
um determinado software. 
 
Papéis e responsabilidades na manutenção 
 
 
Manutenção de sistemas legados 
 
Software legado é uma aplicação desenvolvida no passado e que ainda está em uso numa 
organização. 
 
A manutenção de softwares antigos é mais complicada porque não temos referências, 
normalmente não há mais quem participou do desenvolvimento, quase não há documentação 
e a tecnologia é ultrapassada. 
 
Engenharia reversa: Seu proposito é a redução do custo para a empresa. Substitui sistemas 
legados, em razão das dificuldades que as organizações têm para manter esses sistemas 
legados funcionando adequadamente. 
 
Técnicas de manutenção 
 
Manutenção estruturada: é executada em software que tem uma estrutura documentada e 
seguindo os padrões de Engenharia de Software. Nesse tipo de manutenção, a análise e a 
correção de defeito são mais rápidas e menos custosas, tornando os resultados melhores e 
com maior qualidade. 
 
Manutenção não estruturada: a análise de um pedido de manutenção é feita por uma 
verificação direta no código fonte. Não há outra documentação disponível. Trata-se de uma 
atividade demorada, delicada e não é possível verificar os requisitos não funcionais da 
aplicação. É executada por pessoal com pouca experiência e com pouco conhecimento do 
software. 
 
Custos em manutenção 
 
Os seguintes fatores são relevantes e afetam diretamente os custos de manutenção de um 
produto de software durante o processo de manutenção: Estabilidade da equipe, 
Responsabilidade contratual e Habilidade da equipe. 
 
Qual é o tipo de técnica de manutenção que adequa alterações das leis governamentais 
impostas às empresas? Manutenção adaptativa. 
 
Unidade IV – Videoaula II 
Processo de manutenção 
 
As atividades que compõem o processo de desenvolvimento são: Definição do processo de 
manutenção, Análise das mudanças, Aceitação/revisão da mudança, Migração, Retirada de 
produção 
 
Migração (de dados): PROPÓSITO: A migração exige a elaboração de um plano de 
transferência para a garantia da integridade das informações de um SI para o outro. 
 
Retirada de produção: Análise técnica ou econômica para determinar se o software deve 
permanecer em produção ou ser descontinuado. A decisão deve ser conjunta, entre a equipe 
de desenvolvimento e os usuários, para garantir o investimento necessário para a manutenção 
do software existente ou para a aquisição ou o desenvolvimento de um novo produto. 
 
Impactos da Manutenção 
 
Desenvolvimento Orientado a Objetos: Baseia-se em objetos do mundo real que interagem 
entre si e são acionados por pessoas do mundo real chamadas de atores. É composto de 
classes que são a representação de um objeto de negócio do mundo real com seus próprios 
(atributos) e seus próprios comportamentos (métodos) que executam as ações necessárias 
para o negócio. 
 
Unidade IV – Videoaula III 
 
Desenvolvimento ágil: O desenvolvimento ágil é um processo de desenvolvimento de 
software. Suas características estão relacionadas à rapidez, à integração cliente-equipe e à alta 
qualidade durante o ciclo de construção, podendo utilizar uma estrutura orientada a objetos 
ou baseada em componentes. 
 
Gestão da Configuração: Estabelecer as condições para a organização dos artefatos de 
software, controlar suas versões e suas alterações, manter a integridade de tudo o que foi 
produzido durante o ciclo de vida de um projeto de software e garantir seu armazenamento 
adequado. 
 
Conceitos de gestão da configuração 
 
Manutenção: mudanças e/ou alterações que são realizadas no software após sua conclusão e 
entrada em produção. 
Configuração: atividades de gerenciamento de todo o fluxo dos artefatos produzidos em um 
software, desde seu início até sua descontinuidade. 
Controle de versões: Envolve o uso de uma ferramenta que controla o armazenamento dos 
artefatos e gerencia todas as alterações que esse artefato possa sofrer durante seu ciclo de 
vida. 
Itens de configuração: artefatos criados como parte do processo de desenvolvimento de um 
software. É a menor unidade produzida em um projeto passível de controle. 
Baseline: Trata-se de um ponto de controle no desenvolvimento de software, caracterizado 
pela entrega de um item de configuração para aprovação formal, por meio de uma RTF, por 
exemplo. 
 
Unidade IV – Videoaula IV 
Operações importantes no controle de versão: 
 
Check-out: ação para retirar o artefato do repositório e copiar para o seu ambiente para poder 
fazer alterações. 
Check-in: ação de devolver o artefato retirado para alteração para o repositório central com as 
modificações realizadas. 
Diff: ação que compara a versão que está no repositório com a versão que você está 
alterando, ou compara duas versões que estão no repositório. 
Tag ou label: são rótulos atribuídos a um artefato para identificar o projeto e as versões aos 
quais ele pertence. 
Branch: são usados branches quando é preciso trabalhar em duas versões distintas de um 
projeto ao mesmo tempo. 
Build: uma versão do software produzida para ser utilizada em testes, aceitação ou em 
produção. Pode ser manual ou automaticamente gerada por uma ferramenta específica. 
 
Check-out: ação para retirar o artefato do repositório e copiar para o seu ambiente para poder 
fazer alterações.  Check-in: ação de devolver o artefato retirado para alteração para o 
repositório central com as modificações realizadas.  Diff: ação que compara a versão que 
está no repositório com a versão que você está alterando, ou compara duas versões que estão 
no repositório.  Tag ou label: são rótulos atribuídos a um artefato para identificar o projeto e 
as versões aos quais ele pertence.  Branch: são usados branches quando é preciso trabalhar 
em duas versões distintas de um projeto ao mesmo tempo.  Build: uma versão do software 
produzida para ser utilizada em testes, aceitação ou em produção. Pode ser manual ou 
automaticamente gerada por uma ferramenta específica. 
 
Padrões de Gestão de Configuração: CMMI ISO/IEC 12207 ISO/IEC 9000-3 ISO/IEC 15504. 
Possuem processos para implementação da Gestão de Configuração 
 
Application Lifecycle Management (ALM) – Gerência do ciclo de vida das aplicações 
 
ALM é a gestão integrada entre as necessidades de atender ao negócio e aos processos de 
Engenharia de Software, por meio da criação de procedimentos e do suporte de ferramentas 
que fazem a automação dos processos.