Curso Online:

MS Project
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

1
 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.

2
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

3
 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

4
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.

5
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.

6
 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)

7
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 de dados 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á

8
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.

9
 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.

10
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 processos quaisquer 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.

11
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.

12
 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‖.

13
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.

14
 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 cliente quanto 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).

15
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.

16
 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.

17
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.

18
 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

19
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.

20
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.

21
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

22
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

23
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:

24
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

25