SEGURANCA DA INFORMACAO 2

Prévia do material em texto

Curso Online: 
Segurança da Informação 
 
 
 
1 
 
 
Fundamentos da qualidade de software..............................................................2 
Processos de desenvolvimento de software........................................................4 
Métricas da qualidade de software......................................................................7 
Normas ISO 12207 / ISO 15504........................................................................10 
Reengenharia....................................................................................................13 
Engenharia de software cliente/Servidor...........................................................15 
O desenvolvimento do plano de projeto de Software........................................17 
Processos de gerência de qualidade de software.............................................19 
Referências bibliográficas..................................................................................22 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
FUNDAMENTOS DA QUALIDADE DE SOFTWARE 
 
 
O termo Qualidade possui diferentes definições na literatura. O glossário 
do IEEE define qualidade como ―Grau de conformidade de um sistema, 
componente ou processo com os respectivos requisitos‖, ou, alternativamente, 
como ―Grau de conformidade de um sistema, componente ou processo com as 
necessidades e expectativas de clientes ou usuários‖. 
A norma NBR ISO 9000:2005 define qualidade como sendo o grau no qual um 
conjunto de características inerentes satisfaz aos requisitos. Ou seja, pode-se 
afirmar que se algum produto ou serviço atende aos requisitos especificados, 
este mesmo produto ou serviço possui a qualidade desejada. 
Outra visão diferente é no contexto de desenvolvimento de software: qualidade 
pode ser entendida como um conjunto de características a serem satisfeitas em 
um determinado grau, de modo que o produto de software atenda às 
necessidades explícitas e implícitas de seus usuários. 
Fundamentos de qualidade de software: 
 
 Cultura e ética de engenharia de software 
 Valores e custos de qualidade 
 Modelos e características de qualidade 
 Melhoria da qualidade de software 
 Segurança de Software (Software Safety) 
 
Garvin apresenta cinco formas de entender qualidade: 
 
A definição transcedental: onde qualidade é uma "excelência inata, absoluta e 
que todos podem reconhecer", sendo semelhante ao conceito de "Qualidade 
sem um nome" proposta por Christopher Alexander. 
A definição baseada em produto: onde qualidade é algo que pode ser medido 
em um objeto. 
A definição baseada no usuário: onde qualidade é algo ligado ao atendimento 
das necessidades do usuário. 
https://pt.wikipedia.org/wiki/Qualidade
https://pt.wikipedia.org/wiki/Instituto_de_Engenheiros_Eletricistas_e_Eletr%C3%B4nicos
https://pt.wikipedia.org/wiki/ISO_9000
https://pt.wikipedia.org/wiki/Software
https://pt.wikipedia.org/wiki/Christopher_Alexander
 
 
 
3 
 
A definição baseada na fabricação: onde qualidade está ligado a produção 
correta de acordo com os requisitos 
A definição baseada em valor: onde "um produto de qualidade é aquele que 
fornece desempenho a um preço aceitável ou conformidade a um custo 
aceitável". 
 
 
Fundamentos de Qualidade de Software é o primeiro dos 4 tópicos de 
Qualidade de Software do SWEBOK. Nele são tratados à discussão e a 
definição dos aspectos da Qualidade de Software, seus conceitos, 
características, valores e sua aplicação no software sendo desenvolvido ou em 
manutenção. 
 
 
Modelos e Características de Qualidade de Software 
Modelos de Processo de Software 
CMMI 
MPS.BR 
Padrões Internacionais de Processo de Software 
ISO 12207 
Padrões Internacionais de Qualidade de Software 
ISO 9126 
ISO 15504 
ISO/IEC 25010 (SQuaRe) 
Padrões de certificação de Qualidade de Software 
SCAMPI para o CMMI 
Fórum de credenciamento e controle -FCC para o MPS.br 
 
 
https://pt.wikipedia.org/wiki/CMMI
https://pt.wikipedia.org/w/index.php?title=MPS.BR&action=edit&redlink=1
https://pt.wikipedia.org/wiki/ISO_12207
https://pt.wikipedia.org/wiki/ISO_9126
https://pt.wikipedia.org/wiki/ISO_15504
https://pt.wikipedia.org/wiki/ISO/IEC_25010
https://pt.wikipedia.org/wiki/CMMI
 
 
 
4 
 
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE 
 
 
Um processo de desenvolvimento de software é um conjunto de atividades, 
parcialmente ordenadas, com a finalidade de obter um produto de software. É 
estudado dentro da área de Engenharia de Software, sendo considerado um 
dos principais mecanismos para se obter software de qualidade e cumprir 
corretamente os contratos de desenvolvimento, sendo uma das respostas 
técnicas adequadas para resolver a crise do software. 
A arquitetura de um sistema de software remete a uma representação abstrata 
daquele sistema. Arquitetura é concernente à garantia de que o sistema de 
software irá ao encontro de requisitos do produto, como também assegurar que 
futuros requisitos possam ser atendidos. A etapa da arquitetura também 
direciona as interfaces entre os sistemas de software e outros produtos de 
software, como também com o hardware básico ou com o sistema operacional. 
 
 Modelo em cascata (Waterfall development) 
 Prototipação (Prototyping) 
 Desenvolvimento incremental (Incremental development) 
 Desenvolvimento iterativo e incremental (Iterative and incremental 
development) 
 Modelo em espiral (Spiral development) 
 Desenvolvimento Rápido de Aplicação (Rapid application development - 
RAD) 
 Desenvolvimento ágil de software (Agile development) 
 Programar e Arrumar (Code and fix) 
 Metodologias leves (Lightweight methodologies) 
 
 
O Modelo em Cascata (do inglês: Waterfall Model) é um modelo de 
desenvolvimento de software sequencial no qual o processo é visto como um 
fluir constante para frente (como uma cascata) através das fases de análise de 
requisitos, projeto, implementação, testes (validação), integração, 
e manutenção de software. A origem do termo cascata é frequentemente citado 
como sendo um artigo publicado em 1970 por W. W. Royce; ironicamente, 
Royce defendia um abordagem iterativa para o desenvolvimento de software e 
https://pt.wikipedia.org/wiki/Engenharia_de_Software
https://pt.wikipedia.org/wiki/Qualidade_de_software
https://pt.wikipedia.org/wiki/Crise_do_software
https://pt.wikipedia.org/wiki/Interface
https://pt.wikipedia.org/wiki/Sistema_de_software
https://pt.wikipedia.org/wiki/Hardware
https://pt.wikipedia.org/wiki/Sistema_operacional
https://pt.wikipedia.org/wiki/Modelo_em_cascata
https://pt.wikipedia.org/wiki/Prototipa%C3%A7%C3%A3o
https://pt.wikipedia.org/w/index.php?title=Desenvolvimento_incremental&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Desenvolvimento_iterativo_e_incremental&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Modelo_em_espiral
https://pt.wikipedia.org/wiki/Rapid_Application_Development
https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software
https://pt.wikipedia.org/w/index.php?title=C%C3%B3digo_Cowboy&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Modelo_de_desenvolvimento_de_software
https://pt.wikipedia.org/wiki/Modelo_de_desenvolvimento_de_software
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_requisitos
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_requisitos
https://pt.wikipedia.org/wiki/Projeto_de_software
https://pt.wikipedia.org/wiki/Implanta%C3%A7%C3%A3o_de_software
https://pt.wikipedia.org/wiki/Teste_de_software
https://pt.wikipedia.org/wiki/Integra%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Manuten%C3%A7%C3%A3o_de_software
https://pt.wikipedia.org/wiki/1970https://en.wikipedia.org/wiki/Winston_W._Royce
https://pt.wikipedia.org/w/index.php?title=Desenvolvimento_iterativo&action=edit&redlink=1
 
 
 
5 
 
nem mesmo usou o termo cascata. Royce originalmente descreve o que é hoje 
conhecido como o modelo em cascata como um exemplo de um método que 
ele argumentava ser um risco e um convite para falhas. 
O modelo em cascata apresenta uma grande vantagem quando o escopo do 
trabalho é claramente definido, como licitações e serviços específicos para 
órgãos públicos, neste cenário o modelo em cascata leva vantagem. Entretanto 
percebe-se a fragilidade do modelo nos dias de hoje em virtude da pouca ou 
quase nenhuma flexibilidade do modelo, daí então surgem os modelos lineares 
e iterativos. 
No modelo em cascata original de Royce, as seguintes fases são seguidas em 
perfeita ordem: 
 
 Requerimento 
 Projeto 
 Implementação 
 Integração 
 Teste e depuração (verificação) 
 Manutenção de software 
 
O Protótipo é um produto de trabalho da fase de testes e/ou planejamento de 
um projeto. 
Pode se referir a um automóvel (como um carro conceptual), avião, nave 
espacial, navio ou qualquer outra embarcação, veículo de transporte, moveis 
ou produto da engenharia, como, por exemplo, um porto ou uma usina 
hidrelétrica, uma turbina, uma bomba hidráulica, etc. 
Geralmente estes produtos são testados antes em modelos físicos, em 
laboratórios especializados de aerodinâmica ou de hidrodinâmica. A grande 
diferença desse elemento para uma maquete, é que a maquete seria em 
miniatura e o protótipo é em tamanho real. 
Na Engenharia de Software, protótipo é um sistema/modelo (um website ou 
outro software) sem funcionalidades inteligentes (acesso a banco de dados, por 
exemplo), podendo conter apenas funcionalidades gráficas. Utilizado para fins 
de ilustração e melhor entendimento, geralmente em reuniões entre a equipe 
de Análise de Sistemas e o contratante. 
 
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_requerimento_de_software
https://pt.wikipedia.org/wiki/Projeto_de_software
https://pt.wikipedia.org/wiki/Implanta%C3%A7%C3%A3o_de_software
https://pt.wikipedia.org/wiki/Teste_de_integra%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Teste_de_software
https://pt.wikipedia.org/wiki/Depura%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Manuten%C3%A7%C3%A3o_de_software
https://pt.wikipedia.org/wiki/Produto_(ind%C3%BAstria)
https://pt.wikipedia.org/wiki/Trabalho_(economia)
https://pt.wikipedia.org/wiki/Projeto
https://pt.wikipedia.org/wiki/Autom%C3%B3vel
https://pt.wikipedia.org/wiki/Carro_conceptual
https://pt.wikipedia.org/wiki/Avi%C3%A3o
https://pt.wikipedia.org/wiki/Nave_espacial
https://pt.wikipedia.org/wiki/Nave_espacial
https://pt.wikipedia.org/wiki/Navio
https://pt.wikipedia.org/wiki/Embarca%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Ve%C3%ADculo
https://pt.wikipedia.org/wiki/Engenharia
https://pt.wikipedia.org/wiki/Porto
https://pt.wikipedia.org/wiki/Usina_hidrel%C3%A9trica
https://pt.wikipedia.org/wiki/Usina_hidrel%C3%A9trica
https://pt.wikipedia.org/wiki/Turbina
https://pt.wikipedia.org/wiki/Bomba_hidr%C3%A1ulica
https://pt.wikipedia.org/wiki/Modelos_f%C3%ADsicos
https://pt.wikipedia.org/wiki/Aerodin%C3%A2mica
https://pt.wikipedia.org/wiki/Hidrodin%C3%A2mica
https://pt.wikipedia.org/wiki/Maquete
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Banco_de_dados
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_sistemas
 
 
 
6 
 
Existem inúmeros frameworks de processos para desenvolvimento de software. 
A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do 
software em curtos períodos, chamados de iteração, os quais gastam 
tipicamente menos de uma semana a até quatro. 
Cada iteração é como um projeto de software em miniatura de seu próprio, e 
inclui todas as tarefas necessárias para implantar o mini-incremento da nova 
funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e 
documentação. Enquanto em um processo convencional, cada iteração não 
está necessariamente focada em adicionar um novo conjunto significativo de 
funcionalidades, um projeto de software ágil busca a capacidade de implantar 
uma nova versão do software ao fim de cada iteração, etapa a qual a equipe 
responsável reavalia as prioridades do projeto. 
Métodos ágeis enfatizam comunicações em tempo real, preferencialmente cara 
a cara, a documentos escritos. A maioria dos componentes de um grupo ágil 
deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias 
para terminar o software: no mínimo, os programadores e 
seus clientes (clientes são as pessoas que definem o produto, eles podem ser 
os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem 
também se encontrar os testadores, projetistas de iteração, redatores 
técnicos e gerentes. 
Métodos ágeis também enfatizam o software funcional como uma medida 
primária de progresso. Combinado com a comunicação cara-a-cara, métodos 
ágeis produzem pouca documentação em relação a outros métodos, sendo 
este um dos pontos que podem ser considerados negativos, mas reduzindo o 
tempo de produção de documentação mais útil. 
A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de 
metodologias de desenvolvimento de Software: os membros da equipe fazem o 
que eles sentem que é correto. Como os desenvolvedores que utilizam 
métodos ágeis freqüentemente reavaliam os planos, enfatizam a comunicação 
face a face e fazem o uso relativamente esparso de documentos, 
ocasionalmente levam as pessoas a confundirem isto com codificação cowboy. 
Equipes ágeis, contudo, seguem o processo definido (e freqüentemente de 
forma disciplinada e rigorosa). 
Como em todas as metodologias, o conhecimento e a experiência dos usuários 
definem o grau de sucesso e/ou fracasso de cada atividade. Os controles mais 
rígidos e sistematizados aplicados em um processo implicam altos níveis de 
responsabilidade para os usuários. A degradação de procedimentos bem-
intencionados e organizados pode levar as atividades a serem caracterizadas 
como codificação cowboy. 
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_requisitos
https://pt.wikipedia.org/wiki/Teste_de_software
https://pt.wikipedia.org/wiki/Sala
https://pt.wikipedia.org/wiki/Gerente
https://pt.wikipedia.org/wiki/Analista_de_neg%C3%B3cio
https://pt.wikipedia.org/wiki/Cliente_(com%C3%A9rcio)
https://pt.wikipedia.org/w/index.php?title=Redactores_t%C3%A9cnicos&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Redactores_t%C3%A9cnicos&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Codifica%C3%A7%C3%A3o_cowboy&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Modelo_Balb%C3%BArdia&action=edit&redlink=1
 
 
 
7 
 
MÉTRICAS DA QUALIDADE DE SOFTWARE 
 
 
 
 
Imagem: Medições de previsão e de controle — SOMMERVILLE, 2011 
 
 
É um conjunto de métodos, ferramentas e procedimentos com o objetivo 
de construir software com qualidade. 
A combinação desses 3 elementos fundamentais possibilita ao gerente o 
controle do processo de desenvolvimento do software desde as fases iniciais 
de concepção do projeto até sua manutenção, e oferece ao profissional uma 
base para a construção de softwares de alta qualidade, para além dos 
processos técnicos. (Pressman, 2002) 
―A qualidade de software não é diretamente comparável à qualidade da 
manufatura. A ideia de tolerâncias não é aplicável aos sistemas 
digitais.‖ Sommerville(2011) 
 
 
 
 
8 
 
As métricas podem mensurar fatores diversos, dependendo de sua intenção. 
Desde detectar tendências até medir quantitativamente a eficácia dos 
processos, sua premissa é ser simples, de fácil coleta e manipulação de 
informações, de forma a garantir sua competitividade ao longo do tempo e, 
portanto, seu monitoramento. 
No contexto do desenvolvimento de softwares, é necessário que as metas 
sejam construídas a partir dedados estatísticos históricos, para que sejam 
projetadas o mais próximas da realidade possível, de modo a permitir a 
existência de processos verdadeiramente mais eficientes e eficazes. Tão 
importante quanto coletar e manipular os dados corretos, é papel do gerente 
sempre avaliar a necessidade de auditar seus processos periodicamente, 
evitando desperdício de tempo e esforço em algo sem propósito específico 
definido. 
A medição é algo comum no mundo da engenharia. A engenharia de 
software está longe de desenvolver uma medição padrão amplamente aceita e 
com resultados sem fatores subjetivos. Há discordâncias sobre o que medir e 
como avaliar o resultado obtido das medições. 
Métricas de softwares possibilitam realizar uma das atividades mais 
fundamentais do processo de gerenciamento de projetos: o planejamento. A 
partir desse, pode-se identificar a quantidade de esforço, de custo e 
das atividades que serão necessárias para a realização do projeto. 
As métricas de software, do ponto de vista de medição, podem ser divididas em 
duas categorias: medidas diretas e indiretas. Podemos considerar como 
medidas diretas do processo de engenharia de software o custo e o esforço 
aplicados ao desenvolvimento e manutenção do software e do produto, a 
quantidade de linhas de código produzidas e o total de defeitos registrados 
durante um determinado período de tempo. Porém, a qualidade e 
a funcionalidade do software, ou a sua capacidade de manutenção, são mais 
difíceis de serem avaliadas e só podem ser medidas de forma indireta. 
Também podemos dividir as métricas de software, sob o ponto de vista 
de aplicação, em duas categorias: métricas de produtividade e de qualidade. 
As métricas de produtividade concentram-se na saída do processo de 
engenharia de software. As métricas de qualidade indicam o quanto o software 
atende aos requisitos definidos pelo usuário. 
A medida de software mais familiar é a contagem de linhas de código. Esta 
métrica pode parecer simples, mas existe discordância sobre o que constitui 
uma linha de código. A medida de linhas de código não deveria contar linhas 
de comentário e linhas em branco, pois não afeta a sua funcionalidade. Está 
https://pt.wikipedia.org/wiki/Medi%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Engenharia
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Padr%C3%A3o
https://pt.wikipedia.org/wiki/Gerenciamento_de_projetos
https://pt.wikipedia.org/wiki/Custo
https://pt.wikipedia.org/wiki/Atividade
https://pt.wikipedia.org/wiki/Projeto
https://pt.wikipedia.org/w/index.php?title=Linhas_de_c%C3%B3digo&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Qualidade
https://pt.wikipedia.org/wiki/Funcionalidade
https://pt.wikipedia.org/wiki/Software
https://pt.wikipedia.org/wiki/Manuten%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Aplica%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Produtividade
https://pt.wikipedia.org/wiki/Requisitos
https://pt.wikipedia.org/wiki/Usu%C3%A1rio
 
 
 
9 
 
fortemente ligado à linguagem de programação utilizada, impossibilitando a 
utilização de dados históricos para projetos que não utilizam a mesma 
linguagem. Um conjunto de métricas de qualidade e produtividade pode ser 
desenvolvido com esta técnica. 
Exemplos de métricas: 
 Número de defeitos introduzidos por programador / hora. 
 Número de patches disponibilizados. 
 Número de mudanças no documento de requisitos 
 Número de linhas de código. 
Análise de pontos de função (APF) : mede o tamanho funcional do software, 
subsídios para o cálculo da produtividade do processo de desenvolvimento 
com base na funcionalidade ou utilidade dos programas. Esta avaliação é 
realizada sob o ponto de vista do usuário que avalia o tamanho e a 
complexidade de um software. Nesta contagem são consideradas os seguintes 
itens da aplicação(software):Arquivos Lógicos Internos, Arquivos de Interface 
Externa, Entradas Externas, Consultas Externas e Saídas Externas. Cada item 
deste define um peso que no final determina a quantidade de pontos de função 
da aplicação, para o desenvolvimento de um novo sistema ou os pontos 
necessários para se realizar uma manutenção em um sistema já existente. Os 
pontos calculados servem para se chegar as horas totais do projeto. 
 
 
Objetivos da Medição de Software e utilidade das métricas 
 
Entender: ajudam a entender o comportamento e o funcionamento de produtos 
de software. 
 
Avaliar: utilizadas para determinar padrões, metas e critérios de aceitação. 
 
Controlar: utilizadas para controlar processos, produtos e serviços de 
software. 
 
Prever: utilizadas para prever valores de atributos. 
https://pt.wikipedia.org/wiki/Defeito_de_software
https://pt.wikipedia.org/wiki/Patch_(computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/An%C3%A1lise_de_pontos_de_fun%C3%A7%C3%A3o
 
 
 
10 
 
NORMAS ISO 12207 / ISO 15504 
 
A ISO/IEC 12207 é a norma ISO/IEC que define processo de Engenharia de 
Software, atividades e tarefas que são associados com os processos do ciclo 
de vida do software desde sua concepção até a retirada/descontinuação do 
software. 
A norma internacional ISO/IEC 12207 tem como objetivo principal estabelecer 
uma estrutura comum para os processos de ciclo de vida e de desenvolvimento 
de softwares visando ajudar as organizações a compreenderem todos 
os componentes presentes na aquisição, desenvolvimento e fornecimento de 
software e, assim, conseguirem firmar contratos e executarem projetos de 
forma mais eficaz. Para isso é necessário que compradores, fornecedores, 
desenvolvedores, mantenedores, operadores, gerentes e técnicos envolvidos 
no desenvolvimento de software usem uma linguagem/framework comum. 
A descrição por atividade é a abordagem mais conhecida e intuitiva. Nela são 
descritas as atividades com as inter-relações e o algoritmo de execução de 
cada atividade. As atividades devem atingir o propósito do processo. Para isso 
deve adotar as premissas: 
 Que procedimentos e métodos serão usados para a execução das 
atividades; 
 Que ferramentas e equipamentos suportarão a realização das 
atividades, de forma a simplificar e automatizar o trabalho; 
 Qual o perfil adequado de quem irá executar as atividades e qual 
o treinamento requerido nos procedimentos, métodos, ferramentas para 
que se possam realizar as atividades de forma adequada; 
 Quais as métricas de processo que poderão ser empregadas para que a 
execução do processo possa ter a qualidade avaliada. 
A norma ISO/IEC 12207 estabelece uma arquitetura de alto nível do ciclo de 
vida de software que é construída a partir de um conjunto de processos e seus 
inter-relacionamentos. Os processos são descritos tanto em nível de 
propósito/saídas como em termos de atividades. 
Os processos da ISO/IEC 12207 são modulares, ou seja, são fortemente 
coesos e fracamente acoplados. Isto significa que todas as partes de um 
processo são fortemente relacionadas, mas a quantidade de interfaces entre os 
processos é mínima. 
As regras listadas a seguir são fundamentais para identificação, escopo e 
estruturação dos processos. 
https://pt.wikipedia.org/wiki/Organiza%C3%A7%C3%A3o_Internacional_para_Padroniza%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Comiss%C3%A3o_Eletrot%C3%A9cnica_Internacional
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Softwares
https://pt.wikipedia.org/wiki/Organiza%C3%A7%C3%B5es
https://pt.wikipedia.org/wiki/Componente_de_software
https://pt.wikipedia.org/wiki/Contrato
https://pt.wikipedia.org/wiki/Arquitetura_de_software
https://pt.wikipedia.org/wiki/Acoplamento_(programa%C3%A7%C3%A3o_de_computadores)
 
 
 
11 
 
Um processo deve ser modular, isto é, convém que um processo execute uma 
e somente uma função dentro do ciclo de vida e é conveniente que as 
interfaces entre dois processosquaisquer sejam mínimas; 
Cada processo é invocado na arquitetura; 
Se um processo A é invocado por um processo B e somente por ele, 
então A pertence a B; 
Se uma função é invocada por mais de um processo, então esta função torna-
se um processo; 
Deve ser possível verificar qualquer função dentro do modelo de ciclo de vida; 
Convém que cada processo tenha uma estrutura interna suficientemente 
definida para que possa ser executável. 
Algumas atividades importantes para o desenvolvimento de software serão 
descritas a seguir. São elas: 
 Elicitação de requisitos; 
 Análise dos requisitos do software; 
 Projeto da arquitetura do software; 
 Projeto detalhado do software; 
 Implementação; 
 Codificação e testes do software; 
 Integração do software; 
 Teste de qualificação do software; 
 Instalação do software; 
 Testagem e aprovação do software. 
 
Com os requisitos elaborados e validados, pode-se estabelecer uma 
arquitetura de alto nível para o sistema. A arquitetura deve identificar itens de 
hardware, software e operações manuais. Após a arquitetura ser estabelecida, 
é necessário avaliá-la, considerando os critérios listados a seguir: 
Rastreabilidade para os requisitos do sistema; 
Consistência com os requisitos do sistema; 
Adequação dos métodos e padrões de projeto utilizados; 
Viabilidade dos itens de software atenderem seus requisitos alocados; 
Viabilidade da operação e da manutenção. 
 
 
 
12 
 
ISO / IEC 15504, também conhecida como Spice, é um modelo que possui 
como foco a melhoria dos processos de desenvolvimento de software e a 
determinação da capacidade de processos de uma organização. Além dos 
processos, a SPICE define também os seis níveis de capacitação de cada 
processo (Executado, gerenciado, estabelecido, previsível e otimizado) 
A norma ISO/IEC 15504 propõe uma estrutura para realização de avaliações 
de processos em organizações. A mesma pode ser aplicada em empresas que 
buscam uma melhoria e performance interna ou terceiros que utilizam a 
prestação de serviços e fornecimento de produtos. 
Se o objetivo for a melhoria de processos, a organização pode realizar a 
avaliação gerando um perfil dos processos que será usado para a elaboração 
de um plano de melhorias. A análise dos resultados identifica os pontos fortes, 
os pontos fracos e os riscos inerentes aos processos. No segundo caso, a 
empresa tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu 
perfil de capacidade. 
A dimensão do processo define os processos divididos em cinco categorias: 
 Fornecedor do cliente 
 Engenharia 
 Suporte 
 Gestão 
 Organização 
 
Cada atributo do processo é avaliado em uma escala de classificação de 
quatro pontos (NPLF): 
Não atingido (0 - 15%) 
Parcialmente atingido (> 15% - 50%) 
Em grande parte alcançado (> 50% - 85%) 
Totalmente alcançado (> 85% - 100%). 
 
A classificação é baseada em evidências coletadas contra os indicadores da 
prática, que demonstram o cumprimento do atributo do processo. 
 
 
https://pt.wikipedia.org/wiki/Software
 
 
 
13 
 
REENGENHARIA 
 
 
Os fundamentos científicos para a engenharia de software envolvem o uso 
de modelos abstratos e precisos que permitem ao engenheiro especificar, 
projetar, implementar e manter sistemas de software, avaliando e garantindo 
suas qualidades. A área que estuda e avalia os processos de engenharia de 
software, propondo a evolução dos processos, ferramentas e métodos de 
suporte a engenharia de software é a Engenharia de Software Experimental. 
Os princípios da Engenharia de Software constituem a base dos métodos, 
tecnologias, metodologias e ferramentas adotadas na prática e que norteiam a 
prática de desenvolvimento de soluções de software. Os princípios se aplicam 
ao processo e ao produto de software se tornando em prática de 
desenvolvimento de software através da adoção de métodos e técnicas. 
Geralmente, métodos e técnicas constituem uma metodologia, as quais, são 
apoiadas pela utilização de ferramentas. 
Os princípios-chave são: 
 
 Rigor e Formalidade; 
 Separação de Interesses; 
 Modularidade; 
 Alta Coesão; 
 Baixo Acoplamento. 
 Abstração; 
 Antecipação a Mudanças; 
 Generalidade; 
 Incrementação; 
 Requisitos de Software; 
 Goob. 
 
A reengenharia para Stair e Reynolds (2002, p. 39) é vista como 
―redesenho de processos, envolve a readequação dos processos 
empresariais, estruturas organizacionais, sistemas de informação e valores da 
organização objetivando uma guinada nos resultados dos negócios da 
organização‖. 
 
https://pt.wikipedia.org/wiki/Ci%C3%AAncia
https://pt.wikipedia.org/wiki/Modelo_(matem%C3%A1tica)
https://pt.wikipedia.org/w/index.php?title=Engenharia_de_Software_Experimental&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Metodologia_(engenharia_de_software)&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Estrutura
https://pt.wikipedia.org/wiki/Sistemas_de_informa%C3%A7%C3%A3o
 
 
 
14 
 
Na avaliação de um re-projeto de um sistema legado procedimental, apoiar a 
melhoraria da qualidade dos processos de software e do planejamento de 
questões administrativas em projetos de TI e, garantir a qualidade do processo 
de reengenharia de software orientado a objetos[/lead] 
A opção pela reconstrução de um software legado também tem problemas 
associados. O fato de que software tem regras de negócios embutidas, que 
podem não estar documentadas e a possibilidade das pessoas que as 
dominam não estarem mais na empresa, faz com que a sua completa 
reconstrução não seja tão confiável. Além disso, outro problema dessa opção é 
o custo do re-desenvolvimento global do software, geralmente muito alto, 
consumindo tempo e recursos que, na maioria das vezes, as empresas não 
dispõem. 
A engenharia reversa e/ou reengenharia são as formas que muitas 
organizações estão buscando para manter/refazer seus softwares, livrando-se 
das manutenções difíceis e da degeneração de suas estruturas. Por esse 
motivo, é importante que o resultado desse processo seja confiável. 
As tecnologias e técnicas de criação de sistemas estão em constante evolução, 
os sistemas legados inflexíveis devem acompanhar esse avanço, ou podem 
tornar-se obsoletos ou até extintos no mercado. Sendo assim, é necessário a 
compreensão de algumas formas de acompanhar essa evolução, podendo 
fazer uso das técnicas de engenharia reversa ou reengenharia. Em razão da 
semelhança entre as técnicas de engenharia reversa e reengenharia pode 
surgir a dúvida entre qual melhor se adequa ao problema proposto, e a escolha 
da técnica errada poderá ocasionar custos extras e desnecessários. O objetivo 
desta pesquisa é esclarecer os conceitos sobre as técnicas de engenharia 
reversa e reengenharia através de uma revisão sistemática da literatura, 
definindo suas diferenças no que diz respeito a recriação de sistemas ou 
documentação de sistemas legados. 
A reengenharia de software não é aplicável quando um sistema de software 
legado possui alta qualidade técnica e baixo valor de negócio. Em sistemas 
como esse, deve ser aplicada a evolução de software. Com tais características 
é dispensada a necessidade de esforço de mudança. 
A análise é essencial para priorizar sistemas candidatos à reengenharia e qual 
será a estratégia de desenvolvimento. A maior justificativa de reengenharia é o 
alto risco de falhas, problemas de desempenho, confiabilidade, etc. 
 
 
 
 
 
15 
 
ENGENHARIA DE SOFTWARE CLIENTE/SERVIDOR 
 
 
O modelo cliente-servidor (em inglês client/server model), em computação, é 
uma estrutura de aplicação distribuída que distribui as tarefas e cargas de 
trabalho entre os fornecedores de um recurso ou serviço, designados 
como servidores, e os requerentes dos serviços, designados como clientes. 
Geralmente os clientes e servidores comunicam através de uma rede de 
computadores em computadores distintos, mas tanto o clientequanto o 
servidor podem residir no mesmo computador. 
 
 
 
 
Imagem: Wikipédia, a enciclopédia livre. 
 
 
 
Após vários modelos estudados de cliente-servidor caracterizou-se chamar 
tecnicamente de arquitetura multicamada, inspirado nas camadas no Modelo 
OSI, o processo de dividir a arquitetura de cliente-servidor em várias camadas 
lógicas facilitando o processo de programação distribuída, existe desde o 
modelo mais simples de duas camadas, e o mais utilizado atualmente que é 
o modelo de três camadas que é paralelo ao modelo de arquitetura de 
software denominado MVC (Model-view-controller). 
https://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Computa%C3%A7%C3%A3o_distribu%C3%ADda#Aplica%C3%A7%C3%B5es
https://pt.wikipedia.org/wiki/Servidor
https://pt.wikipedia.org/wiki/Cliente_(computa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Rede_de_computadores
https://pt.wikipedia.org/wiki/Arquitetura_multicamada
https://pt.wikipedia.org/wiki/Modelo_OSI
https://pt.wikipedia.org/wiki/Modelo_OSI
https://pt.wikipedia.org/w/index.php?title=Programa%C3%A7%C3%A3o_distribu%C3%ADda&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Thin_client
https://pt.wikipedia.org/wiki/Modelo_em_tr%C3%AAs_camadas
https://pt.wikipedia.org/wiki/Arquitetura_de_software
https://pt.wikipedia.org/wiki/Arquitetura_de_software
https://pt.wikipedia.org/wiki/MVC
 
 
 
16 
 
Características do Cliente: 
Inicia pedidos para servidores; 
Espera por respostas; 
Recebe respostas; 
Conecta-se a um pequeno número de servidores de uma só vez ; 
Normalmente interage diretamente com os servidores através de seu software 
aplicação especifico, que lhe possibilita a comunicação com o servidor; 
Utiliza recursos da rede . 
 
Características do Servidor: 
Sempre espera por um pedido de um cliente; 
Atende os pedidos e, em seguida, responde aos clientes com os dados 
solicitados; 
Podem se conectar com outros servidores para atender uma solicitação 
específica do cliente; jamais podem se comunicar. 
Fornece recursos de rede. 
Normalmente interage diretamente com os usuários finais através de qualquer 
interface com o usuário; 
Estrutura o sistema. 
 
Os protocolos do nível de transporte fornecem serviços que garantem uma 
transferência confiável de dados e aplicativos entre computadores (ou outros 
equipamentos) remotos. Os programas na camada de aplicação usam 
os protocolos de transporte para contactar outras aplicações. Para isso, a 
aplicação interage com o software do protocolo antes de ser feito o contacto. A 
aplicação que aguarda a conexão informa ao software do protocolo local que 
está pronta a aceitar mensagem. A aplicação que estabelece a conexão usa os 
protocolos de transporte e rede para contactar o sistema que aguarda. As 
mensagens entre as duas aplicações são trocadas através da conexão 
resultante. 
 
https://pt.wikipedia.org/wiki/Protocolo_de_transporte
https://pt.wikipedia.org/wiki/Protocolo
https://pt.wikipedia.org/wiki/Conex%C3%A3o
 
 
 
17 
 
O DESENVOLVIMENTO DO PLANO DE PROJETO DE SOFTWARE 
 
 
Na computação, o desenvolvimento de software é o ato de elaborar e 
implementar um sistema computacional, isto é, transformar a necessidade de 
um utilizador ou de um mercado em um produto de software. Também é 
entendido como a aplicação dos processos da engenharia de 
software combinados com a pesquisa das necessidades do produto para 
desenvolver software. 
Existem diversos processos de desenvolvimento de software, no entanto há 
algumas atividades básicas comuns à grande parte dos processos existentes, 
nesse artigo será descrito algumas dessas atividades, como: 
 Levantamento de requisitos; 
 Análise de Requisitos; 
 Projeto; 
 Implementação; 
 Testes; 
 Implantação. 
 
O interesse nessa atividade é criar uma estratégia de solução, sem se 
preocupar como essa estratégia será realizada, ou seja, utilizar as 
necessidades dos clientes, depois de compreendido o problema, para 
resolução do problema solicitado. Assim é necessário definir o que o sistema 
deve fazer, antes de definir como o sistema irá fazer. 
Nesta fase é que deve ser considerado, como o sistema funcionará 
internamente, para que os requisitos do cliente possam ser atendidos. Alguns 
aspectos devem ser considerados nessa fase de projeto do sistema, como: 
arquitetura do sistema, linguagem de programação utilizada, Sistema 
Gerenciador de Banco de Dados (SGBD) utilizado, padrão de interface gráfica, 
entre outros. 
Em um processo de desenvolvimento orientado a objetos, o projeto da 
arquitetura normalmente é realizado por um arquiteto de software. O projeto da 
arquitetura visa distribuir as classes de objetos relacionados do sistema em 
subsistemas e seus componentes, distribuindo também esses componentes 
pelos recursos de hardware disponíveis. 
https://pt.wikipedia.org/wiki/Ci%C3%AAncia_da_computa%C3%A7%C3%A3o
https://pt.wikipedia.org/wiki/Sistema_computacional
https://pt.wikipedia.org/wiki/Software
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://www.devmedia.com.br/guias/
https://www.devmedia.com.br/os-4-pilares-da-programacao-orientada-a-objetos/9264
https://www.devmedia.com.br/arquitetura-de-software-desenvolvimento-orientado-para-arquitetura/8033
https://www.devmedia.com.br/arquitetura-de-software-desenvolvimento-orientado-para-arquitetura/8033
 
 
 
18 
 
Um software normalmente é composto por diversas funções, bibliotecas e 
módulos que gera um programa executável ao final do processo de 
desenvolvimento e este, quando executado, recebe algum tipo de ―entrada‖ de 
dados (input), processa as informações segundo uma série de algoritmos ou 
sequências de instruções lógicas e libera uma saída (output) como resultado 
deste processamento. Um software bem desenvolvido é normalmente criado 
pela área engenharia de software e inclui não apenas o programa de 
computador em si, mas também manuais, especificações e configurações. 
Um programa de computador é composto por uma sequência de instruções, 
que é interpretada e executada por um processador ou por uma máquina 
virtual. Em um programa correto e funcional, essa sequência segue padrões 
específicos que resultam em um comportamento desejado. 
O termo "software" foi criado na década de 1940, e é um trocadilho com o 
termo hardware. "Hardware", em inglês, significa "ferramenta 
física". Software seria tudo o que faz o computador funcionar excetuando-se a 
parte física dele. 
Um programa pode ser executado por qualquer dispositivo capaz de interpretar 
e executar as instruções de que é formado. 
Quando um software está representado como instruções que podem ser 
executadas diretamente por um processador, dizemos que está escrito 
em linguagem de máquina. A execução de um software também pode ser 
intermediada por um programa interpretador, responsável por interpretar e 
executar cada uma de suas instruções. Uma categoria especial e o notável de 
interpretadores são as máquinas virtuais, como a máquina virtual Java (JVM), 
que simulam um computador inteiro, real ou imaginado. 
O dispositivo mais conhecido que dispõe de um processador é o computador. 
Atualmente, com o barateamento dos microprocessadores, existem outras 
máquinas programáveis, como telefone celular, máquinas de automação 
industrial, calculadora etc. 
Normalmente, programas de computador são escritos em linguagens de 
programação, pois estas foram projetadas para aproximar-se das linguagens 
usadas por seres humanos. Raramente a linguagem de máquina é usada para 
desenvolver um programa. Atualmente existe uma quantidade muito grande de 
linguagens de programação, dentre elas as mais populares no momento 
são Java, Visual Basic, C, C++, PHP, dentre outras. 
 
 
https://pt.wikipedia.org/wiki/Programa_de_computador
https://pt.wikipedia.org/wiki/Algoritmo
https://pt.wikipedia.org/wiki/Processadorhttps://pt.wikipedia.org/wiki/M%C3%A1quina_virtual
https://pt.wikipedia.org/wiki/M%C3%A1quina_virtual
https://pt.wikipedia.org/wiki/Hardware
https://pt.wikipedia.org/wiki/L%C3%ADngua_inglesa
https://pt.wikipedia.org/wiki/Processador
https://pt.wikipedia.org/wiki/C%C3%B3digo_de_m%C3%A1quina
https://pt.wikipedia.org/wiki/M%C3%A1quina_virtual
https://pt.wikipedia.org/wiki/M%C3%A1quina_virtual_Java
https://pt.wikipedia.org/wiki/Computador
https://pt.wikipedia.org/wiki/Microprocessador
https://pt.wikipedia.org/wiki/Telefone_celular
https://pt.wikipedia.org/wiki/Automa%C3%A7%C3%A3o_industrial
https://pt.wikipedia.org/wiki/Automa%C3%A7%C3%A3o_industrial
https://pt.wikipedia.org/wiki/Calculadora
https://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/Visual_Basic
https://pt.wikipedia.org/wiki/C_(linguagem_de_programa%C3%A7%C3%A3o)
https://pt.wikipedia.org/wiki/C%2B%2B
https://pt.wikipedia.org/wiki/PHP
 
 
 
19 
 
PROCESSOS DE GERÊNCIA DE QUALIDADE DE SOFTWARE 
 
 
O rumo que a Qualidade de Software tomou na história se iniciou a partir da 
reunião da OTAN em 1968 onde o termo ―Engenharia de Software‖ foi utilizado 
pela primeira vez por F. L. Bauer. 
Naquela reunião foi a primeira vez que o termo ―Crise do Software‖ foi utilizado 
para dizer sobre os maus tempos que a indústria de software 
E a crise foi atribuída à complexidade de desenvolver sistemas cada vez 
maiores, bem como à falta de gerenciamento no processo de desenvolvimento 
de software. 
A partir daí ―engenheiros de software‖ passaram a imitar a engenharia 
convencional para resolver problemas de qualidade e falhas em sistemas de 
informação. O modelo inicial adotado pela engenharia de software foi orientado 
fortemente à melhoria do produto final de software. 
No início da década de 1990, o próprio mercado substituía o Controle pela 
Garantia da Qualidade com um foco centrado no processo e que utilizava 
auditorias durante todo o ciclo de vida de desenvolvimento. 
A partir daí, foram surgindo normas aplicadas para a área tais como a ISO 
9000-3, ISO 15504, ISO 12207, padrões IEEE 1074, IEEE 1298 e 
Modelos SW-CMM, CMMI e MPS.BR para Qualidade de Software. 
Uma forte motivação para o foco em qualidade é que o custo relativo de corrigir 
erros aumenta drasticamente com a evolução do Ciclo de Vida do Software. 
Segundo Boehm, citado por Pressman, há corrigir um erro ou defeito na fase 
de manutenção do software custa 100 vezes mais que corrigi-lo na fase de 
requisitos. 
Pressman indica os seguintes custos relacionados a qualidade de software, 
podendo eles ocorrerem tanto na prevenção quanto no tratamento dos 
problemas: 
Custos de Prevenção 
 Planejamento da qualidade 
 Revisões técnicas formais 
 Testes 
 Treinamento 
https://pt.wikipedia.org/wiki/Engenharia_de_software
https://pt.wikipedia.org/wiki/Crise_do_software
https://pt.wikipedia.org/wiki/ISO/IEC_15504
https://pt.wikipedia.org/wiki/ISO_12207
https://pt.wikipedia.org/wiki/Instituto_de_Engenheiros_Eletricistas_e_Eletr%C3%B4nicos
https://pt.wikipedia.org/wiki/Instituto_de_Engenheiros_Eletricistas_e_Eletr%C3%B4nicos
https://pt.wikipedia.org/wiki/Capability_Maturity_Model
https://pt.wikipedia.org/wiki/CMMI
https://pt.wikipedia.org/w/index.php?title=Ciclo_de_Vida_do_Software&action=edit&redlink=1
 
 
 
20 
 
Custos de Falha Interna 
 Retrabalho 
 Reparo 
 Modo de análise de falha 
Custo de Falha Externa 
 Resolução das reclamações 
 Devolução e substituição 
 Suporte 
 Atendimento à garantia 
 
A Série ISO/IEC 25000, denominada Software product Quality Requirements 
and Evaluation (SQuaRE), é a mais moderna norma de qualidade de software, 
sendo organizada da seguinte forma: 
 
2500n: Divisão da gestão da qualidade 
2501n: Divisão de modelo de qualidade 
2502n: Divisão de medição de qualidade 
2503n: Divisão de requisitos de qualidade 
2504n: Divisão de avaliação de qualidade 
 
Ela define 3 perspectivas de qualidade (ou modelos): 
 Qualidade Externa, uma visão de caixa preta do software 
 Qualidade Interna, uma visão de caixa branca do software 
 Qualidade em Uso, uma visão operacional do software 
 
Existem quatro subcategorias de Gerência de Qualidade de Software: 
Planejamento da Qualidade de Software 
Garantia da Qualidade de Software 
Controle da Qualidade de Software 
Melhoria da Qualidade de Software. 
 
 
 
21 
 
Para auxiliar a garantir a qualidade de software existem várias ferramentas, 
que podem atuar em análises estáticas ou dinâmicas do software. 
Entre a grande variedade de ferramentas existentes, é possível caracterizar 
alguma categorias de análise estática: 
 Ferramentas de apoio a revisões e inspeções 
 Ferramentas de apoio a análise de riscos de segurança 
 Ferramentas de rastreamento de problemas 
 Ferramentas de análise de dados capturados em ambientes de 
Engenharia de Software. 
 
No Brasil existe o Programa Brasileiro da Qualidade e Produtividade em 
Software, PBQP-Software, cuja principal contribuição é o programa de Melhoria 
do Processo de Software Brasileiro, MPS.Br, apoiado pelo Softex. Além disso 
a ABNT nacionaliza as normas internacionais. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
https://pt.wikipedia.org/w/index.php?title=Programa_Brasileiro_da_Qualidade_e_Produtividade_em_Software&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Programa_Brasileiro_da_Qualidade_e_Produtividade_em_Software&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=PBQP-Software&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=MPS/Br&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=MPS/Br&action=edit&redlink=1
https://pt.wikipedia.org/w/index.php?title=Mps.br&action=edit&redlink=1
https://pt.wikipedia.org/wiki/Softex
https://pt.wikipedia.org/wiki/ABNT
 
 
 
22 
 
Referências Bibliográficas 
 
Wikipédia, a enciclopédia livre.Qualidade de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Qualidade_de_software 
 
Wikipédia, a enciclopédia livre.Processo de desenvolvimento de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Processo_de_desenvolvimento_de_software 
 
Wikipédia, a enciclopédia livre.Modelo em cascata. 
Disponível em: 
https://pt.wikipedia.org/wiki/Modelo_em_cascata 
 
Wikipédia, a enciclopédia livre.Protótipo. 
Disponível em: 
https://pt.wikipedia.org/wiki/Prot%C3%B3tipo 
 
Wikipédia, a enciclopédia livre.Desenvolvimento ágil de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Desenvolvimento_%C3%A1gil_de_software 
 
Felipe Corniani de Genaro.Como usar métricas para garantir a qualidade de 
software. 
Disponível em: 
https://medium.com/launchpad-labs/como-usar-m%C3%A9tricas-para-garantir-
a-qualidade-de-software-a2a0a77b0a40 
 
 
 
23 
 
 
Wikipédia, a enciclopédia livre.Métrica de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/M%C3%A9trica_de_software 
 
Wikipédia, a enciclopédia livre.ISO/IEC 12207. 
Disponível em: 
https://pt.wikipedia.org/wiki/ISO/IEC_12207 
 
Wikipédia, a enciclopédia livre. ISO/IEC 15504. 
Disponível em: 
https://pt.wikipedia.org/wiki/ISO/IEC_15504 
 
Wikipédia, a enciclopédia livre.Reengenharia. 
Disponível em: 
https://pt.wikipedia.org/wiki/Reengenharia 
 
Wikipédia, a enciclopédia livre.Engenharia de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Engenharia_de_software 
 
DEVMEDIA.Reengenharia de Software Orientado a Objetos - Engenharia de 
Software 33. 
Disponível em: 
https://www.devmedia.com.br/reengenharia-de-software-orientado-a-objetos-
engenharia-de-software-33/19304 
 
 
 
 
24 
 
Pedro Luis Saraiva Barbosa, Adriano Lima Cândido.DIFERENÇAS ENTRE 
ENGENHARIA REVERSA E REENGENHARIA NOS SISTEMAS DE 
INFORMAÇÃO. 
Disponível em: 
https://interfaces.leaosampaio.edu.br/index.php/revista-
interfaces/article/view/263 
 
Nycolas Batista Medeiros. QUANDO APLICAR A REENGENHARIA DE 
SOFTWARE. 
Disponível em: 
https://www.webartigos.com/artigos/quando-aplicar-a-reengenharia-de-software/90537 
 
Wikipédia, a enciclopédia livre.Modelo cliente–servidor. 
Disponível em: 
https://pt.wikipedia.org/wiki/Modelo_cliente%E2%80%93servidor 
 
Wikipédia, a enciclopédia livre.Desenvolvimento de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Desenvolvimento_de_software 
 
DEVMEDIA. Atividades básicas ao processo de desenvolvimento de Software. 
Disponível em: 
https://www.devmedia.com.br/atividades-basicas-ao-processo-de-
desenvolvimento-de-software/5413 
 
Wikipédia, a enciclopédia livre.Software. 
Disponível em: 
 
 
 
25 
 
https://pt.wikipedia.org/wiki/Software 
 
Wikipédia, a enciclopédia livre.Qualidade de software. 
Disponível em: 
https://pt.wikipedia.org/wiki/Qualidade_de_software