Trabalho Regina-converted

Prévia do material em texto

QUALIDADE E TESTE DE SOFTWARE 
 
 
Testes e qualidade de software, fatores, objetivos e características. 
 
O teste do software é uma das fases do processo de Engenharia de Software que visa atingir 
um nível de qualidade de produto superior. O objetivo, por paradoxal que pareça, é mesmo o 
de encontrar defeitos no produto, para que estes possam ser corrigidos pela equipe de 
analistas/programadores, antes da entrega final. A maioria das pessoas pensam que o teste de 
software serve para demonstrar o correto funcionamento de um programa, quando na 
verdade ele é utilizado como um processo da engenharia de software para encontrar defeitos. 
 
O conceito de teste de software pode ser compreendido através de uma visão intuitiva ou 
mesmo de uma maneira formal. Existem atualmente várias definições para esse conceito. De 
uma forma simples, testar um software significa verificar através de uma execução controlada 
se o seu comportamento corre de acordo com o especificado. O objetivo principal desta tarefa 
é encontrar o número máximo de erros dispondo do mínimo de esforço, ou seja, mostrar aos 
que desenvolvem se os resultados estão ou não de acordo com os padrões estabelecidos. 
 
Nas indústrias qualidade é algo percorrido há tempos, diversas metodologias surgiram, sempre 
com o objetivo de melhorar a qualidade ao mesmo tempo em que reduz custo, pois o custo do 
defeito pode ser desastroso, não só para as finanças, mas também para o nome da empresa, 
há diversos exemplos de defeitos que poderia ser citado aqui, mas um dos mais conhecidos e 
desastrosos é o incidente que ocorreu na década de 80, mais especificamente entre junho de 
85 a janeiro de 87, o Therac-25, dispositivo computadorizado para tratamento por radiação 
para câncer, teve diversos equipamentos ministrando doses elevadas a pacientes, pelo menos 
6 pacientes tiveram doses elevadas e alguns foram mortos outros incapacitados. O FDA (Food 
and Drug Administration) investigou o caso e descobriu um programa mal documentado, sem 
especificação e nem plano de testes, Frank Houston da FDA escreveu em 85 "Uma quantidade 
significativa de software para sistemas críticos para a vida vêm de pequenas empresas, 
especialmente na indústria de equipamentos médicos; empresas que enquadram no perfil 
daquelas que resistem aos princípios tanto da segurança de sistemas quanto da engenharia de 
software ou os desconhecem", notem a importância da qualidade do software? 
 
Já se imaginou sendo você o paciente em tratamento em um equipamento com software que 
não foi testado adequadamente e os testes serão realizados quando você estiver sendo 
atendido? 
 
 
 
Segundo Bastos et. al. Há três dimensões de qualidade que precisam ser consideradas: 
 
Confiança: O sistema é resistente a falhas durante a execução, isto é, não entra em loop, não 
interrompe a execução por falta de recursos, etc. 
 
Funcionalidade: O sistema se comporta conforme o esperado e definido em seus requisitos. 
 
Performance: O sistema tem um tempo de resposta adequado e aceitável, mesmo quando 
submetido a um volume de processamento próximo de situações reais ou de pico? 
 
E para atender as três dimensões, o desenvolvedor e o analista, tem uma nova tarefa, 
desenvolver com foco em qualidade, além das dimensões, a equipe de análise e 
desenvolvimento pode fazer uso do tão conhecido ciclo PDCA: Planejar, Executar, Verificar, 
Agir. 
 
Testes de software 
 
Teste de Software é um processo que faz parte do #desenvolvimento de software, e tem como 
principal objetivo revelar falhas/bugs para que sejam corrigidas até que o produto final atinja a 
qualidade desejada / acordada. 
Profissionais que trabalham com testes (denominados analistas de testes, técnicos de testes, 
homologador, ou simplesmente testes) estão habituados a realizar uma bateria de testes de 
diferentes naturezas e propósitos, envolvendo não apenas os testes funcionais da aplicação, 
mas diversas outras atividades como: 
 
• avaliação da especificação de requisitos, 
• avaliação de projeto técnico, 
• verificações em outros documentos, 
• testes de performance e capacidade, 
• avaliação de interface, 
• dentre outros. 
 
Para ter uma ideia a respeito da diversidade e abrangência de atividades que fazem parte do 
processo de testes, é apresentada a seguir uma tabela com alguns tipos de testes comuns. 
 
Ciclo de Testes 
 
O ciclo de vida consiste em uma série de etapas dependentes, consideradas como o esqueleto 
do Processo de Teste, que visam estruturar as atividades definindo como os testes serão 
conduzidos no projeto. 
Essas etapas podem variar de acordo com a metodologia utilizada 
A execução de cada etapa do ciclo de vida tem um tempo estimado de duração. Assim, é 
recomendável seguir essa estimativa para que seja possível executar todas as fases do 
processo, minimizando riscos e consequentemente garantindo mais qualidade ao software. 
 
Classes de Testes 
 
Quando falamos em testes de software devemos sempre lembrar que estes são divididos em 
diversos tipos, de acordo com seu objetivo particular. Para clarear os conceitos, conheça aqui, 
os 13 principais tipos de testes de software e o que cada um aborda. 
 
Teste de Configuração 
Testa se o software funciona no hardware a ser instalado. 
 
Teste de Instalação 
Testa se o software instala como planejado, em diferentes hardwares e sob diferentes 
condições, como pouco espaço de memória, interrupções de rede, interrupções na instalação 
etc. 
 
Teste de Integridade 
Testa a resistência do software a falhas (robustez). 
 
Teste de Segurança 
Testa se o sistema e os dados são acessados de maneira segura, apenas pelo autor das ações. 
 
Teste Funcional 
 Testa os requisitos funcionais, as funções e os casos de uso. “A aplicação faz o que deveria 
fazer?” 
 
Teste de Unidade 
Testa um componente isolado ou classe do sistema. 
 
Teste de Integração 
Testa se um ou mais componentes combinados funcionam de maneira satisfatória. Há quem 
diga que o teste de integração é composto por vários testes de unidade. 
 
Teste de Volume 
Testa o comportamento do sistema operando com o volume “normal” de dados e transações 
envolvendo o banco de dados durante um longo período de tempo. 
 
Teste de Performance 
O teste de performance se divide em 3 tipos: 
 
- Teste de carga: 
Testa o software sob as condições normais de uso. Ex.: tempo de resposta, número de 
transações por minuto, usuários simultâneos etc. 
 
- Teste de stress: 
Testa o software sob condições extremas de uso. Grande volume de transações e usuários 
simultâneos. Picos excessivos de carga em curtos períodos de tempo. 
 
- Teste de estabilidade: 
Testa se o sistema se mantém funcionando de maneira satisfatória após um período de uso. 
 
Teste de Usabilidade 
Teste focado na experiência do usuário, consistência da interface, layout, acesso às 
funcionalidades etc. 
 
Testes de Caixa Branca e Caixa Preta 
Basicamente, teste de caixa branca envolve o código e o de caixa-preta, não. 
 
 
Teste de Regressão 
Reteste de um sistema ou componente para verificar se alguma modificação recente causou 
algum efeito indesejado, além de, certificar se o sistema ainda atende os requisitos. 
 
Teste de Manutenção 
Testa se a mudança de ambiente não interferiu no funcionamento do sistema. 
 
Conceito de qualidade de processo e produto de software 
A aplicação QUALIDADE, foi idealizada seguindo fielmente o modelo CMMI com o 
planejamento do estudo da aderência e a implementação do modelo MPS.BR. 
Esta aplicação por idealização e concepção será disponibilizada para utilização gratuita através 
do site www.maturidade-academica.com.br/Qualidade para as empresas e instituição de 
ensino que tenham interesse em estudos e melhoria da qualidade dos processos de software. 
É uma aplicação web e para ser utilizada todos deverão estar cadastrados. A identificação da 
organização no momentodo cadastro pode ser fantasia, em caso da organização não querer 
ser identificada. 
 
Estará à disposição para esclarecimento de eventuais dúvidas o e-mail duvidas@maturidade- 
academica.com.br ou para o e-mail contato@maturidade-academica.com.br, onde os 
pesquisadores/autores da ferramenta, esporádica e voluntariamente poderão orientá-los em 
alguma questão ou direcionar para a busca da melhor orientação. 
 
Este é um trabalho voluntário e acadêmico, resultado de pesquisa e desenvolvimento, e 
poderá ser utilizado como base estatística de pesquisa em qualidade de software, onde será 
utilizado para o entendimento estatístico de fragilidades nos processos de forma geral e 
consequentemente propor pesquisa o desenvolvimento de mecanismos e processos a ser 
oferecido as organizações para auxiliar na conquistar das melhores classificações nos Modelos 
de Qualidade de Processos de Software. 
 
Considerações: 
O Uso desta aplicação não irá eliminar a necessidade da organização em contratar um 
especialista ou uma consultoria em modelos de qualidade, mas poderá minimizar o tempo 
desta contratação, pois o uso responsável irá proporcionar ao usuário um panorama do 
processo pré-auto-avaliado com relação aos modelos CMMI e MPSBR. 
Para ser um usuário da aplicação não é necessário ter conhecimento profundo dos modelos, 
porem quanto maior a familiaridade maior a facilidade em organizar os processos. O termo 
pré-auto-avaliação está se referindo a uma avaliação interna da organização com relação aos 
seus processos de software, não com relação aos processos oficiais de avaliação do CMMI ou 
MSPSBR. 
 
Uma Linha de Produto de Software (LPS) consiste em uma estratégia de realizar o reuso de 
forma sistemática para a construção de sistemas com menos esforço desde que estes 
pertençam a uma mesma família, ou seja, que tenham em comum pertencer a um mesmo 
domínio de mercado. A definição de linha de produto mais aceita na indústria diz o seguinte: 
“Uma linha de produto de software é um conjunto de sistemas que usam software 
intensivamente, compartilhando um conjunto de características comuns e gerenciadas, que 
satisfazem as necessidades de um segmento particular de mercado ou missão, e que são 
desenvolvidos a partir de um conjunto comum de ativos principais e de uma forma 
preestabelecida”. 
 
A ideia básica é o trabalho sobre um grupo de sistemas compartilhando um conjunto comum 
de domínio e gerenciado por features, desenvolvidos a partir de um aglomerado comum de 
artefatos base e de forma previamente planejada. Os artefatos que são reutilizáveis abrangem 
todos os tipos tais como documento de requisitos, projeto de arquitetura, componentes de 
software, planos de testes e etc. Para facilitar a customização em massa, a plataforma deve 
 
fornecer os meios para satisfazer as necessidades dos diferentes stakeholders. Para este 
propósito, o conceito de variabilidade foi criado (explorar as características que variam em 
relação aos diversos produtos). Como consequência de aplicar este conceito, os artefatos que 
podem ser diferentes nas aplicações da linha de produtos são modelados usando variabilidade. 
Uma das características principais da LPS é o reuso, sendo muito presente devido ao 
reaproveitamento de produtos ou partes de produtos em criação de novos produtos. O 
processo de desenvolvimento de software, por uma linha de produto de software, ocorre em 
duas etapas: 
 
Engenharia de Domínio: processo responsável por estabelecer a plataforma de reutilização 
definindo o que é comum e o que é variável da linha de produtos. A plataforma consiste em 
todos os tipos de artefatos de software (requisitos, design, testes, etc.) também chamados de 
ativos base; 
 
Engenharia de Aplicação: processo responsável por derivar aplicações concretas a partir da 
plataforma estabelecida na engenharia de domínio. Ela explora a variabilidade da linha de 
produtos e assegura sua correta instanciação de acordo com as necessidades específicas das 
aplicações finais. 
 
Inicialmente é preciso compreender o plano de negócio da empresa, informações sobre os 
produtos contidos nos ativos bases e dos novos produtos que serão construídos, e os novos 
requisitos. Depois é feita uma análise sobre os potenciais artefatos para reuso sistematizado 
pela engenharia de domínio. Na fase de engenharia de domínio, é feita uma análise dos 
potenciais artefatos para reuso nos ativos bases de acordo com as etapas de processo de 
desenvolvimento, por exemplo: análise de domínio nos artefatos de requisitos, arquitetura de 
domínio nos projetos arquiteturais, implementação de domínio nos ativos de implementação e 
testes de domínio nos documentos de testes reutilizáveis. 
 
Como pode ser observado na figura, o fluxo de informações entre as etapas é feito de forma 
sequencial. Além disso, é necessário fazer rastreabilidade do produto ou produtos que serão 
reusados para encontrar os artefatos correspondentes para serem reutilizados. Após verificar 
os potenciais artefatos para reuso, começa a etapa de engenharia de aplicação. Nesta etapa, é 
construído um novo produto a partir de reuso de artefatos. Nesta etapa é feita análise de 
produto com os requisitos recuperados, projeto arquitetural do produto, implementação e 
testes. 
 
Vale salientar que um novo produto pode ser construído a partir do reuso de artefatos de um 
ou vários produtos. Por fim, é feito um feedback da evolução de produtos no processo de 
desenvolvimento. Este feedback é feito analisando o novo produto e verificando se houve 
evolução de software. Caso isto aconteça, este novo produto pode ser incorporado aos ativos 
bases para o projeto de novos produtos. 
 
Definição de Processo 
A utilização de um processo de software tem sido apontada como um fator primordial para o 
sucesso de empresas de desenvolvimento de software. 
 
Para poder melhor compreender o assunto é necessário definir o que é um processo de 
software. 
 
Um processo de software pode ser entendido como um conjunto estruturado de atividades 
exigidas para desenvolver um sistema de software. Assim Sommerville traz a seguinte 
definição: 
 
"[O processo é] um conjunto de atividades e resultados associados que produzem um produto 
de software". 
 
Jalote conclui que um processo de software é: 
 
"é um conjunto de atividades, ligadas por padrões de relacionamento entre ela, pelas quais se 
as atividades operarem corretamente e de acordo com os padrões requeridos, o resultado 
desejado é produzido. O resultado desejado é um software de alta qualidade e baixo custo. 
Obviamente, um processo que não aumenta a produção (não suporta projetos de software 
grandes) ou não pode produzir software com boa qualidade não é um processo adequado." 
 
A partir destas definições podemos considerar que de forma geral um processo de software 
padrão pode ser visto como um conjunto de atividades, métodos, ferramentas e práticas que 
são utilizadas para construir um produto de software. Na definição de um processo de 
software devem ser consideradas as seguintes informações: atividades a serem realizadas, 
recursos necessários, artefatos requeridos e produzidos, procedimentos adotados e o modelo 
de ciclo de vida utilizado. 
 
Sucintamente podemos definir o processo de software como um conjunto de atividades 
uniformizadas a serem aplicadas sistematicamente que se encontram agrupadas em fases, 
cada uma das quais com os seus intervenientes com responsabilidades, que possui diversas 
entradas e produz diversas saídas. Isto é, define quem faz o quê, quando e como para atingir 
um certo objetivo. 
 
Humphrey define as seguintes razões para a definição de um processo padrão: 
 
• Redução dos problemas relacionados a treinamento, revisões e suporte à ferramentas; 
• As experiências adquiridas nos projetos são incorporadas ao processo padrão e 
contribuem para melhorias em todos os processos definidos; 
• Economiade tempo e esforço na definição de novos processos adequados a projetos. 
 
Para Schwartz as principais fases de um processo de software são: 
 
Especificação de Requisitos: tradução da necessidade ou requisito operacional para uma 
descrição da funcionalidade a ser executada. 
Projeto de Sistema: tradução destes requisitos em uma descrição de todos os componentes 
necessários para codificar o sistema. 
Programação (Codificação): produção do código que controla o sistema e realiza a 
computação e lógica envolvida. 
Verificação e Integração (Verificação): verificação da satisfação dos requisitos iniciais pelo 
produto produzido. 
 
Ao contrário do que possa parecer não existe uma sequência obrigatória de fases, sendo que 
diversos autores apontam a natureza não simultânea das fases como uma realidade na 
aplicação de processos de software, e também defendem que o processo de software é muito 
mais interativo e cíclico do que a ideia de fases simples pode sugerir. 
 
Dimensões 
O processo de desenvolvimento de software definido pela ISO 15504 é divido em três 
categorias principais de processos: 
 
 
Processos Primários 
Processo de Aquisição: 
O objetivo é obter um produto ou serviço que satisfaça o cliente, passando por quatro fases: 
preparação, seleção do fornecedor, monitoração do fornecedor e aceitação. 
 
Processo de Fornecimento: 
É o processo de fornecer ao cliente um software que satisfaça suas necessidades, incluindo a 
preparação do contrato, entrega do produto e a instalação. 
 
Processo de levantamento de Requisitos: 
Tem como objetivo capturar e processar todos os requisitos do cliente. É utilizado durante 
todas as fases de desenvolvimento para o processo de revisão do plano de desenvolvimento e 
comunicação com o cliente para possíveis alterações de requisitos. 
 
Processo de Operação: 
Tem como função fazer o produto de software operar no ambiente para o qual foi 
desenvolvido e oferecer suporte ao usuário. 
 
Categoria de Engenharia de Software: 
Vai da parte de construção do software, que é composta da análise de requisitos, construção, 
integração e testes à manutenção do software que tem o objetivo de alterar modificações, 
migrações e desativação do software, de acordo com os desejos do cliente. 
 
 
 
 
Processos Organizacionais 
Processos de Gestão: 
- Alinhamento aos objetivos estratégicos da organização; 
- Estabelecimento de práticas de gestão em geral, e especialmente gestão de projeto; 
- Gestão da qualidade; 
- Gestão de riscos; 
- Medição; 
 
Processos de Melhoria de Processos: 
- Definição de processos; 
- Avaliação de processos: Avaliar como os processos estão contribuindo para a organização 
alcançar seus objetivos; 
- Melhoria de processos: Comprometimento, priorização, gestão das ações de melhoria; 
 
Processos de Recursos e Infraestrutura: 
- Gestão de RH; 
- Treinamento; 
- Gestão do conhecimento; 
- Infraestrutura: Recursos materiais, ambiente de trabalho, ferramentas; 
 
Processos de Reuso: 
- Gestão de Ativos (Componentes/módulos/informações) suscetíveis de reuso; 
- Gestão do programa de Reuso: Estratégia, definição de domínios, procedimentos, melhoria; 
- Engenharia de Domínio: A partir da definição de um ou mais domínios, de aplicação, 
Desenvolvimento e manutenção de modelos, arquiteturas e 
componentes/módulos/informações relativos ao domínio; 
 
Processos de Apoio 
Garantia de Qualidade: 
- Os produtos e atividades de um processo ou projeto devem estar de acordo com os 
requisitos especificados, planos e regras. 
 
Verificação: 
- Cada produto ou serviço resultado de um processo obedecem às especificações de entrada 
do processo. 
 
Validação: 
- Os requisitos para o uso desejado de cada produto ou serviço resultado de um processo deve 
ser atendido. 
 
Revisão Conjunta: 
- O cliente pode ter visibilidade completa do andamento do desenvolvimento quando 
comparada ao estabelecido no contrato. 
 
Auditoria: 
- Os produtos identificados devem estar em conformidade com as atividades com planos, 
requisitos e com o contrato. 
- Documentação: 
- Documentos que registrem informações produzidas por um outro processo ou atividade 
devem ser mantidos. 
 
Gestão de Configuração: 
- Integridade de todos os produtos de algum processo ou do projeto. 
 
 Solução de Problemas: 
- Todos os problemas encontrados devem ser analisados, resolvidos e que tendências sejam 
observadas visando o planejamento de ações preventivas. 
 
Avaliação de Produto: 
- Garantir a devida avaliação do produto de acordo com as diretrizes estabelecidas do 
contrato. 
 
Gestão de Mudança: 
- Garantir que todos os pedidos de mudança serão gerenciados, acompanhados e controlados. 
 
 
Usuário 
 
Um usuário (pt-BR) ou utilizador (pt) é um agente, tanto um agente humano (usuário final) 
como um agente de software, que usa um computador ou serviço de rede. Os usuários de 
sistemas computacionais e produtos de software geralmente não possuem o conhecimento 
técnico necessário para entender completamente como eles funcionam. Os usuários 
avançados usam recursos avançados dos programas, embora não tenham, necessariamente, 
habilidades de programação de computadores e administração de sistemas. 
Um usuário, muitas vezes tem uma conta de usuário e é identificado por um nome de usuário. 
Outros termos para nome de usuário incluem o nome de login, nome de 
tela (screenname), apelido (nick) ou identificador, que é derivado do termo do Serviço Rádio 
do Cidadão. 
 
Alguns produtos de software fornecem serviços para outros sistemas e não possuem usuários 
finais diretos. 
Os usuários também são amplamente caracterizados como a classe de pessoas que usam 
um sistema sem conhecimento técnico completo necessário para compreender totalmente o 
sistema. Em contextos relacionados a hackers, tais usuários também estão divididos 
em lusers e usuários avançados. 
Em projetos em que o ator do sistema é um outro sistema ou um agente de software, é muito 
possível que não haja usuário final para o sistema. Neste caso, os usuários finais para o sistema 
seriam usuários finais indiretos. 
 
Desenvolvimento 
 
Um processo de desenvolvimento de software pode ser visto como um conjunto de atividades 
organizadas, usadas para definir, desenvolver, testar e manter um software. A seguir, alguns 
objetivos do processo de desenvolvimento: 
 
• Definição das atividades a serem executadas; 
• Quando determinada atividade deve ser executada; 
• Pessoa ou grupo a executar tais atividades; 
• Padronização no processo de desenvolvimento. 
 
 
Desenvolvimento de 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. 
 
Levantamento de Requisitos 
Esta atividade tem como objetivo, compreender o problema, dando aos desenvolvedores e 
usuários, a mesma visão do que deve ser construído para resolução do problema. 
Desenvolvedores e clientes, em conjunto, buscam levantar e priorizar as necessidades dos 
futuros usuários do software (necessidades essas denominadas como requisitos). 
 
O Levantamento de Requisitos é a etapa mais importante, no que diz respeito ao retorno de 
investimentos no projeto. Vários projetos são abandonados pelo baixo levantamento de 
requisitos, ou seja, membros da equipe não disponibilizaram tempo suficiente para essa fase 
do projeto, em compreender as necessidades dos clientes em relação ao sistema a ser 
desenvolvido. 
 
E como um sistema de informações geralmente é utilizado para automatizar processos de 
negócio em uma organização, esses processos da organização devem ser bem compreendidos 
para que o restante das atividades do processo de desenvolvimento flua de acordo comas 
reais necessidades do cliente. 
 
Análise de Requisitos 
Esta etapa, também chamada de especificação de requisitos, é onde os desenvolvedores 
fazem um estudo detalhado dos dados levantados na atividade anterior. De onde são 
construídos modelos a fim de representar o sistema de software a ser desenvolvido. 
 
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. 
 
O que acontece com frequência, é quando as equipes de desenvolvimento partem para a 
solução do problema do software, sem antes ter definido completamente o problema em 
questão. Nesta fase deve-se então realizar a validação e verificação dos modelos construídos, 
antes de partir para solução do problema. 
 
• Validação: tem por objetivo, assegurar que o sistema de software está atendendo as 
reais necessidades do cliente; 
• Verificação: verifica se os modelos construídos na análise estão em conformidade com 
os requisitos do cliente. 
 
Projeto 
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. 
 
No projeto é gerada uma descrição computacional, mencionando o que o software deve fazer, 
e deve ser coerente com a descrição realizada na fase de análise de requisitos. 
 
O projeto possui duas atividades básicas: projeto da arquitetura (ou projeto de alto nível), e 
projeto detalhado (ou projeto de baixo nível). 
 
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. 
 
Já no projeto detalhado, são modeladas as relações de cada módulo com o objetivo de realizar 
as funcionalidades do módulo. Além de desenvolver o projeto de interface com o usuário e o 
projeto de banco de dados. 
 
Implementação 
Nessa etapa, o sistema é codificado a partir da descrição computacional da fase de projeto em 
uma outra linguagem, onde se torna possível a compilação e geração do código-executável 
para o desenvolvimento software. 
 
Em um processo de desenvolvimento orientado a objetos, a implementação se dá, definindo 
as classes de objetos do sistema em questão, fazendo uso de linguagens de programação 
como, por exemplo: Delphi (Object Pascal), C++, Java, etc. Pode-se também utilizar na 
implementação ferramentas de software e bibliotecas de classes preexistentes para agilizar a 
atividade, como também o uso de ferramentas CASE, que dinamizam o processo de 
desenvolvimento, nas várias atividades, onde inclui-se geração de código-fonte, 
documentação, etc. 
 
Testes 
Diversas atividades de testes são executadas a fim de se validar o produto de software, 
testando cada funcionalidade de cada módulo, buscando, levando em consideração a 
especificação feita na fase de projeto. Onde o principal resultado é o relatório de testes, que 
contém as informações relevantes sobre erros encontrados no sistema, e seu comportamento 
em vários aspectos. Ao final dessa atividade, os diversos módulos do sistema são integrados, 
resultando no produto de software. 
 
Implantação 
Por fim a implantação compreende a instalação do software no ambiente do usuário. O que 
inclui os manuais do sistema, importação dos dados para o novo sistema e treinamento dos 
usuários para o uso correto e adequado do sistema. Em alguns casos quando da existência de 
um software anterior, também é realizada a migração de dados anteriores desse software. 
 
Comercialização 
 
Os contratos são instrumentos jurídicos que existem há mais de um século. Seu conceito e sua 
função social estão intimamente ligados à definição econômica que lhe é dada: instrumento 
que operacionaliza a circulação de riquezas e acomodação de diversos interesses. É 
importante destacar que o contrato não é só o documento escrito que formaliza obrigações, 
mas é, sobretudo, um acordo de vontades dirigida a determinado fim. O Direito, portanto, 
atenta-se constantemente às mudanças sociais e econômicas que demandam, cada dia mais, 
um novo desafio aos instrumentos contratuais. 
 
Nessa lógica, atravessa-se momento de ampla evolução tecnológica, iniciada pela revolução 
digital, na qual a tecnologia se apresenta progressivamente presente em nossas relações 
sociais e nas atividades econômicas. O quadro contemporâneo é de constante transformação, 
de modo que requer do ordenamento jurídico atual uma rápida adaptação para atender suas 
necessidades. 
 
Atualmente, há previsto em nossa legislação diferentes espécies de contratos, que se agrupam 
em categorias distintas consoante às suas particularidades. É importante destacar que as 
espécies variam de acordo com o negócio jurídico a ser realizado, e apesar 
do Código Civil prever diversas categorias, a legislação e normatização jurídicas estão em 
processo de adaptação e recepção acerca das questões de tecnologia, exigindo maior 
preocupação daqueles que atuam nesse mercado. 
 
Como exemplo, a transferência de tecnologia, ou Contrato de Fornecimento de Tecnologia, 
tem como principal objeto a técnica e conhecimento exclusivo utilizado para produção e/ou 
 
comercialização de bens. A transferência desse conhecimento não implica no direito de 
titularidade do bem, ou seja, o detentor da tecnologia continua sendo o mesmo. Para cada 
tipo haverá um contrato de licenciamento ou de cessão, a depender do propósito da 
transferência. Qualquer que seja a modalidade, deverá haver registro no Instituto Nacional da 
Propriedade Industrial (INPI). 
 
Para a transferência de propriedade de bens tecnológicos, a modalidade utilizada é a cessão, 
na qual o detentor da tecnologia transfere a titularidade do direito de propriedade intelectual, 
ou seja, não terá mais a tecnologia e nem os direitos que dela decorre m, como por exemplo, 
de licenciamento de uso, ou de outra qualquer transferência. Entretanto, dentre as formas de 
negociação de tecnologia, a comercialização de software destaca -se no mercado tecnológico e 
também no ordenamento jurídico. 
 
Os softwares são programas que comandam o funcionamento de um computador. Há algumas 
décadas os programas somente eram comercializados por fabricantes de hardwares 
(equipamentos) e vinham pré-instalados, ou seja, o consumidor o adquiria na compra de um 
equipamento. Ocorre que, com a evolução da tecnologia, os softwares passaram a ser 
comercializados em separado, diretamente por seus desenvolvedores, surgindo, dessa forma, 
um novo modelo de contratação. O mercado de software tem operado, sobretudo, através do 
Contrato de Licença de Uso, conforme definiu a lei 9.609, de 19 de fevereiro de 1998. Esse 
modelo consiste em uma modalidade de negócio jurídico através do qual alguém, denominado 
licenciante, concede ao licenciado o direito de exploração econômica e/ou utilização do 
programa de computador. 
 
No licenciamento ocorre a transferência do direito de uso, fruição, e gozo daquela tecnologia, 
por isso, tendo em vista a natureza e a função dos softwares, essa é a modalidade mais 
comum para quem comercializa tais tecnologias. Nessa modalidade, o detentor da tecnologia 
do software, desenvolvedor ou licenciante, estabelece junto ao licenciado uma forma de uso, 
bem como pode ou não determinar o tempo e algumas formas de utilização.É natural perceber que, para aqueles interessados em negociar a tecnologia de software a fim 
de obter interessados na utilização de seu programa, o contrato de licenciamento de uso 
permite exatamente o ajuste de (i) quantidade de usuários do licenciado, (ii) valor por unidade 
ou por conexão, (iii) inclusão ou não de manutenção evolutiva, (iii) atualizações do sistema e 
formas de cobrança, (iv) sistema de manutenção, e todas as matérias afetas ao uso do 
software, que fazem do contrato não apenas uma formalidade para concretizar o uso e os 
direitos do licenciado ou do licenciador, mas que abrangem todas as questões, inclusive 
técnicas, que devem vigorar a tempo e a modo na duração do contrato. 
 
Desse modo, o contrato de licenciamento de software vai além de uma simples burocratização 
para licenciado e licenciante, mas um instrumento que permite delimitar os limites, regras, 
valores, formas de uso, e, inclusive, pode abrir espaço para novas negociações, como no caso 
de manutenção evolutiva, por exemplo. Apesar disso, é comum que alguns contratos deixem à 
parte termo de confidencialidade quando se trata de questões sigilosas e tecnologia da 
informação, mas como um apenso ao contrato principal com todas as informações 
necessárias. Portanto, a utilização do instrumento contratual proporciona segurança ao 
desenvolvedor de software, evitando, dessa forma, 
 
vulnerabilidade de dados, utilização indevida e a própria comercialização ilegal da tecnologia. 
 
Fatores de Qualidade 
 
Ao final do projeto de desenvolvimento, além de conter o mínimo possível de erros, o 
software deve apresentar características como: agilidade de funcionamento, facilidade de 
manuseio, atender as expectativas do cliente e agregar valor à empresa. 
Durante os testes, diversos padrões do software devem ser analisados. Esse processo 
permitirá que a ferramenta tenha um diferencial positivo em relação a outras que produzem o 
mesmo serviço no mercado, mas não funcionam da maneira adequada. 
Vale destacar que a qualidade do software está sempre sendo aprimorada, haja vista que as 
tecnologias evoluem de acordo com o tempo. 
É necessário o entendimento de que é um trabalho contínuo, constante e que exige alto 
investimento. Mesmo após o software ter se transformado em produto final, novos testes e 
aprimoramentos devem ser realizados, geralmente pela criação de novas versões ou até novos 
softwares para atender a demanda. 
Mas, na realidade, o que influência na qualidade final do software desenvolvido? O que faz 
com que a ferramenta funcione da maneira que foi projetada ou não tenha o sucesso que foi 
pretendido? O que deve ser utilizado para aperfeiçoar o seu desenvolvimento? 
Alguns pontos são imprescindíveis para que o software funcione da forma correta. Os fatores 
que influenciam na qualidade do software e contribuem para o sucesso do produto final são: 
 
 
Etapa de desenvolvimento 
A etapa de desenvolvimento é um dos fatores que mais contribui para o desempenho final do 
software. É necessário focar não somente na parte prática e técnica, mas também em tudo 
que colaborou para que a ferramenta chegasse naquele momento de ação. 
Tudo que foi planejado no início dessa etapa deve ser levado em consideração, como: público-
alvo de destino do software, a realização das pesquisas, análise dos dados obtidos, e por fim, 
mas não menos importante, a avaliação do mercado em que se está introduzido. É de 
imensurável importância ter consciência da demanda que existe em busca do produto. 
 
Equipe de profissionais 
É claro que ter acesso a uma tecnologia de ponta, assim como ter um projeto impecável do 
produto que se planeja desenvolver é importante. 
No entanto, não adianta muita coisa ter a melhor tecnologia e o produto mais bem produzido 
se o seu projeto não tiver a melhor equipe de profissionais para executar a aplicação. 
Um dos fatores mais importantes que influenciam na qualidade do software é a captação de 
recursos humanos. Deve-se sempre trabalhar com os melhores funcionários dentro da 
possibilidade e treiná-los para que estejam sempre em constante evolução. 
 
Uma equipe de sucesso nem sempre é formada de início, mas é preciso que haja um 
supervisor capacitado para identificar as falhas e acertos do grupo de profissionais que 
trabalham no projeto. 
É importante saber identificar os colaboradores certos, mas, também, capacitá-los para que 
estejam sempre aptos a acrescentar novidades. 
 
Influenciadores gerais 
Os influenciadores gerais podem estar relacionados a diversos fatores, como a assistência 
técnica, escolha das ferramentas e recursos disponibilizados para o desenvolvimento do 
software. 
Possuir um software de qualidade comprovada exige muito trabalho, estrutura, tecnologia e 
uma equipe adequada. É inevitável que esses e outros fatores estejam sempre em harmonia 
para que o projeto tenha sucesso ao fim do desenvolvimento do produto. 
 
Softwares com interação humana 
Vale lembrar que os softwares com interação humana, ou seja, aplicativos que não servem 
exclusivamente para cálculos matemáticos, geralmente passam por aprimoramentos após o 
seu lançamento. 
Esse fato se dá não necessariamente por conta de falhas no sistema, mas, sim por causa da 
percepção que os usuários têm do aplicativo. 
Inclusive, há uma máxima conhecida, adaptada do princípio da incerteza da física das 
subpartículas que diz: “o usuário só sabe o que ele precisa a partir do momento em que ele 
obteve o que pediu”.