PDS - Leitura Complementar do Conteúdo Online

Prévia do material em texto

1 
 
LEITURA SUGERIDA NO FINAL DA AULA 1 DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
SOFTWARE 
 
Software1 [sóftuer],2 logiciário ou suporte lógico é uma sequência de instruções a serem seguidas e/ou 
executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento. 
"Software" também é o nome dado ao comportamento exibido por essa sequência de instruções quando 
executada em um computador ou máquina semelhante além de um produto desenvolvido pela engenharia 
de software, e inclui não só o programa de computador propriamente dito, mas também manuais e 
especificações. Para fins contábeis e financeiros, o software é considerado um bem de capital.3 
Este produto passa por várias etapas como: análise econômica, análise de 
requisitos, especificação, codificação, teste, documentação, Treinamento, manutenção e implantação nos 
ambientes.4 
 
Software como programa de computador 
 
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.5 
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. 
 
A construção de um programa de computador 
 
Um programa é um conjunto de instruções para o processador (linguagem de máquina). Entretanto, pode-se 
utilizar linguagens de programação, que traduza comandos em instruções para o processador. 
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.6 
Alguns programas feitos para usos específicos, como por exemplo software embarcado ou software embutido, 
ainda são feitos em linguagem de máquina para aumentar a velocidade ou diminuir o espaço consumido. Em todo 
caso, a melhoria dos processadores dedicados também vem diminuindo essa prática, sendo a C uma linguagem 
típica para esse tipo de projeto. Essa prática, porém, vem caindo em desuso, principalmente devido à grande 
complexidade dos processadores atuais, dos sistemas operacionais e dos problemas tratados. Muito raramente, 
realmente apenas em casos excepcionais, é utilizado o código de máquina, a representação numérica utilizada 
diretamente pelo processador.7 
O programa é, inicialmente, "carregado" na memória principal.8 Após carregar o programa, o computador 
encontra o Entry Point ou ponto inicial de entrada do programa que carregou e lê as instruções 
sucessivamente byte por byte. As instruções do programa são passadas para o sistema ou processador onde são 
traduzidas da linguagens de programação para a linguagem de máquina, sendo em seguida executadas ou 
diretamente para o hardware, que recebe as instruções na forma de linguagem de máquina. 
 
Tipos de programas de computador 
 
Qualquer computador moderno tem uma variedade de programas que fazem diversas tarefas. 
Eles podem ser classificados em duas grandes categorias:9 
1. Software de sistema que incluiu o firmware (O BIOS dos computadores pessoais, por exemplo), drivers 
de dispositivos, o sistema operacional e tipicamente uma interface gráfica que, em conjunto, permitem 
ao usuário interagir com o computador e seusperiféricos. 
2 
 
2. Software aplicativo, que permite ao usuário fazer uma ou mais tarefas específicas. Aplicativos podem 
ter uma abrangência de uso de larga escala, muitas vezes em âmbito mundial; nestes casos, os 
programas tendem a ser mais robustos e mais padronizados. Programas escritos para um pequeno 
mercado têm um nível de padronização menor. 
Ainda é possível usar a categoria Software embutido ou software embarcado, indicando software destinado a 
funcionar dentro de uma máquina que não é um computador de uso geral e normalmente com um destino muito 
específico. 
 Software aplicativo: é aquele que permite aos usuários executar uma ou mais tarefas específicas, em 
qualquer campo de atividade que pode ser automatizado especialmente no campo dos negócios. Inclui, 
entre outros: 
 Aplicações de controle e sistemas de automação industrial. 
 aplicações de informática para o escritório. 
 Software educacional. 
 Software de negócios. 
 Banco de dados. 
 Telecomunicações. 
 vídeo games. 
 Software médico. 
 Software de calculo numérico e simbólico. 
Atualmente, temos um novo tipo de software. O software como serviço, que é um tipo de software armazenado 
num computador que se acessa pela internet, não sendo necessário instalá-lo no computador do usuário. 
Geralmente esse tipo de software é gratuito e tem as mesmas funcionalidades das versões armazenadas 
localmente. 
Outra classificação possível em 3 tipos é: 
 Software de sistema: Seu objetivo é separar usuário e programador de detalhes do computador específico 
que está sendo usado. O software do sistema lhe dá ao usuário interfaces de alto nível e ferramentas que 
permitem a manutenção do sistema. Inclui, entre outros: 
 Sistemas operacionais 
 Drivers 
 ferramentas de diagnóstico 
 ferramentas de correção e otimização 
 Servidores 
 Software de programação: O conjunto de ferramentas que permitem ao programador desenvolver programas 
de computador usando diferentes alternativas e linguagens de programação, de forma prática. Inclui, entre 
outros: 
 Editores de texto 
 Compiladores 
 Intérpretes 
 linkers 
 Depuradores 
 Ambientes de Desenvolvimento Integrado : Agrupamento das ferramentas anteriores, geralmente em um 
ambiente visual, de modo que o programador não precisa digitar vários comandos para a compilação, 
interpretação, depuração, etc. Geralmente equipados com uma interface de usuário gráfica avançada. 
 
Licenças 
 
A maioria do software é publicado sob uma licença de software. Essa licença define e até restringe qual a forma 
que se pode utilizar o software definido números de licenças, modificações entre outros. Exemplos de licenças: 
 GNU General Public License 
 Licença BSD 
 Licença Apache 
 Licença comercial 
 Licença de software 
 Licença de software livre 
 Software livre 
 Freeware 
 Shareware 
 Demo 
 Trial 
 
 
3 
 
LEITURA SUGERIDA NO FINAL DA AULA 2 DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
ANÁLISE DE REQUERIMENTO DE SOFTWARE 
Na engenharia de sistemas e engenharia de software, análise de requisitos engloba todas as tarefas que lidam 
com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte 
importante do processo de desenvolvimento de softwares, na qual o engenheiro de requisitos e oanalista de 
negócio, juntamente comengenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou 
requisitos de um cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de 
sistemas estarão preparados para projetar a solução. 
A análise de requisitos é a primeira fase de desenvolvimento de software dividido em Requisito 
funcional e Requisito não-funcional. É nesta fase que o analista faz as primeiras reuniões com os clientes e/ou 
usuários do software para conhecer as funcionalidades do sistema que será desenvolvido. É nesta fase também 
que ocorre a maior parte dos erros, pois a falta de experiência dos clientes ou usuários faz com que eles nem 
sempre tenham claro em sua mente quais funcionalidades o software terá. 
As entrevistas estruturadas são um método utilizado para esta fase e que poderão ter um papel importante na 
ajuda à compreensão de todas as funcionalidades pretendidas pelo cliente. 
Outras denominações 
A análise de requisitos é também conhecida por outros nomes: 
 Engenharia de requisitos 
 Levantamento de requisitos 
 Captura de requisitos 
 Análise de sistema 
 Especificação de requisitos 
 Análise de requerimentos 
Principais Atividades 
Conceitualmente, a análise de requisitos inclui três tipos de atividades: 
 Elicitação dos requisitos: é a tarefa de comunicar-se com os usuários e clientes para determinar quais são os 
requisitos de sistema. 
 Análise de requisitos: determina se o estado do requisitos é obscuro, incompleto, ambíguo, ou contraditório 
e resolve estes problemas. 
 Registros dos requisitos: os requisitos podem ser documentados de várias formas, tais como documentos de 
linguagem natural, casos de uso, ou processo de especificação. 
Processo 
Análise de requisitos pode ser um processo longo e árduo. Novos sistemas mudam o ambiente e a relação entre 
as pessoas, então é importante identificar todos os envolvidos, levando em conta todas as suas necessidades e 
assegurando que eles compreenderam as implicações dos novos sistemas. Os analistas podem empregar várias 
técnicas para elicitar os requisitos dos clientes. Historicamente, isto envolve coisas tais como 
organizar entrevistas ou grupos focais (workshops) e a criação de lista de requisitos. Técnicas mais modernas 
incluem prototipação, e casos de uso, onde o analista irá aplicar uma combinação de métodos para estabelecer 
os requisitos exatos de seus stakeholders, tal que um sistema que atenda as necessidades do negócio seja 
produzido. 
Principais técnicas 
Entrevistas com stakeholder 
Entrevistas com stakeholder é um método comumente usado na análise de requisitos. Algumas decisões são 
usualmente necessárias, o custo inicial é um fator na decisão de quem será entrevistado. Estas entrevistas 
devem revelar requisitos ainda não precisamente delineados de acordo com o escopo do projeto, e requisitos 
que possam ser contraditórios. 
4 
 
 
Workshops de requisitos 
Em alguns casos pode ser útil reunir os stakeholders em workshop de requisitos. Estes workshops são mais 
propriamente denominados como seção de Desenvolvimento de Requisitos Conjunta, onde os requisitos são 
identificados conjuntamente e definidos pelos stakeholders. 
Pode ser útil realizar tais workshops fora em ambientes controlados, tais que os stakeholders não sejam 
distraídos. Um facilitador que pode ser usado para manter o processo focado e beneficiar esta sessão seria o fato 
de haver um redator dedicado a documentar a discussão. Facilitadores devem fazer uso de um projetor e 
diagramas de software ou devem usar um suporte tão simples como papel e marcadores. Uma regra para os 
facilitadores deve assegurar que o peso associado ao requisitos propostos não deve ser demasiadamente 
dependente das personalidades daqueles envolvidos no processo!. 
Lista de requisitos no estilo de contrato 
Uma forma tradicional de documentar requisitos é a utilização de lista de requisitos no estilo de contrato. Em 
sistemas complexos tais listas de requisitos podem chegar a centenas de páginas. 
Objetivos Mensuráveis 
As melhores práticas consideram as listas de requisitos compostas como meras dicas e respostas, até que o real 
propósito do negócio seja descoberto. Então os stakeholders e desenvolvedores poderão planejar testes para 
medir em qual nível cada objetivo será atingido. Estes objetivos mudam mais lentamente do que a longa lista de 
especificação de requisitos não mensuráveis. Uma vez que este pequeno grupo de objetivos críticos e 
mensuráveis for estabelecido, prototipação rápida e fases de desenvolvimento interativas e rápidas convergirão 
para atendimento dos fundamentais objetivos dos stakeholder antes que tenha decorrido metade do projeto. 
Protótipos 
Em meados dos anos 80, prototipação surgiu como a solução para o problema da análise de requisitos. 
Prototipação é uma simulação das telas de uma aplicação a qual permite ao usuário visualizar a aplicação que 
ainda não foi produzida. Protótipos ajudam o usuário a ter uma idéia de como o sistema irá parecer, e facilita a 
tomada de decisões no projeto sem esperar que o sistema seja construído. Melhorias na comunicação entre o 
usuário e desenvolvedores são freqüentemente vistas com a implantação da prototipação. A visualização 
antecipada das telas leva a poucas mudanças posteriores e, por conseguinte reduz o custo total 
consideravelmente. 
Contudo, no decorrer da década seguinte, embora provasse ser uma técnica útil, ela não resolvia estes 
problemas dos requisitos: 
 Uma vez que o protótipo fica pronto, o gerente gasta um grande tempo para entender que o projeto final 
não irá ser produzido no mesmo tempo. 
 Projetistas freqüentemente sentem-se compelidos a usar o atalho de utilizar o protótipo no sistema real, 
porque eles têm medo do 'grande tempo' para iniciar de novo. 
 Projetistas e usuários finais podem focar-se demais no projeto da interface e pouco na produção de um 
sistema que atenda as necessidades do processo de negócio. 
Protótipos podem ser exibidos em diagramas (denominados como wireframes) ou utilizando aplicações que 
sintetizem as funcionalidades. Wireframes são exibidos em documentos com várias apresentações gráficas, e 
freqüentemente removem-se as cores do projeto gráfico (isto é, usa-se uma paleta de tons de cinza) em casos 
onde existe uma expectativa a respeito do projeto gráfico do software final. Isto ajuda a prevenir a confusão a 
respeito da experiência final a respeito da aparência da aplicação. 
Casos de Uso 
 Artigo Principal: Caso de uso 
Um 'Caso de Uso' é uma técnica para capturar os requisitos em potencial de um novo sistema ou manutenção de 
software. Cada caso de uso provê um ou mais cenários que indicam como o sistema deve interagir com o usuário 
final ou outro sistema para atingir um objetivo de negócio específico. Casos de uso tipicamente evitam o jargão 
técnico, preferindo ao invés disto a linguagem do usuário final ou de um expert no domínio. Os casos de uso são 
freqüentemente de co-autoria dos desenvolvedores de software e usuários. 
Casos de usos são ferramentas enganosamente simples para descrever o comportamento de um software. Um 
caso de uso deve conter uma descrição textual de todos os passos que o usuário futuramente poderá vir a 
utilizar no software através de sua interface. Casos de uso não descrevem nenhum comportamento interno do 
5 
 
software, nem fazem explanações de como o software será implementado. Eles simplesmente mostram os passos 
que o usuário deve seguir para usar o software no seu trabalho. Todas as formas com que o usuário irá interagir 
com o software deverão ser descritas por este meio. 
Problemas 
Problemas com Stakeholder 
Alguns dos problemas que podem inibir a obtenção dos requisitos: 
 Usuários não sabem o que eles querem. 
 Usuários que nãoquerem concluir a escrita do conjunto de requisitos. 
 Comunicação com o usuário é lenta 
 Os usuários freqüentemente não participam nas revisões ou são incapazes de fazer isto. 
 Os usuários são tecnicamente poucos sofisticados. 
 Os usuários não entendem o processo de desenvolvimento. 
Isto deve levar a situações onde os requisitos do usuário continuam mudando mesmo quando o desenvolvimento 
do sistema ou produto já se iniciou. 
Problemas de Engenheiros/Desenvolvedores 
Possíveis problemas causados por engenheiros e desenvolvedores durante a análise dos requisitos são: 
 Pessoal técnico e usuários finais têm vocabulários diferentes. Conseqüentemente, eles podem acreditar que 
estão em perfeito acordo até que o produto final seja entregue. 
 Engenheiros e desenvolvedores tentam ajustar os requisitos para um sistema existente ou modelo, em vez 
de desenvolver um sistema específico que atenda as necessidades do cliente. 
 A análise é freqüentemente conduzida por engenheiros ou programadores, ao invés de pessoal com 
habilidade e conhecimento do domínio para compreender as necessidades dos clientes. 
Tentativas de solução 
Uma tentativa para solucionar os problemas de comunicação vem sendo o emprego de especialistas em negócios 
ou analistas de sistema. 
As técnicas introduzidas em 1990 como Prototipação, UML, Casos de Uso, e Desenvolvimento ágil de 
software foram também introduzidas como soluções para os problemas apresentados. 
Também surgiu no mercado uma nova classe de ferramentas de simulação de aplicação ou definição de 
aplicação. Estas ferramentas foram projetadas como uma ponte para transpor a lacuna de comunicação 
existente entre o usuário e a equipe de TI – e também permitir que aplicações tenham 'testes de mercado' antes 
que qualquer código seja produzido. O melhor que estas ferramentas tem a oferecer é: 
 Quadro eletrônico para marcar o fluxo das aplicações e testar alternativas. 
 habilidade de capturar a lógica do negócio e informações necessárias. 
 interatividade 
 capacidade de adicionar requisitos contextuais e outros comentários. 
 habilidade para uso remoto e distribuído para permitir o uso e interação como as simulações. 
 
LEITURA SUGERIDA NO FINAL DA AULA 3 DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
UML 
Na área de Engenharia de Software, a Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling 
Language) é uma linguagem de modelagem que permite representar um sistema de forma padronizada. 
A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer 
primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a 
comunicação entre os objetos. 
Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas 
padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma 
notação independente de processos, embora o
desenvolvido utilizando a UML. 
É importante distinguir entre um modelo UML e um
uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. 
O XMI (XMLMetadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas.
Os objetivos da UML são: especificação, documentação, estruturação para sub
lógica do desenvolvimento completo de um sistema de informação.
História 
A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso 
na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de
e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML 
pretende ser a linguagem de modelagem padrão
A UML ainda não é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do
Management Group (OMG). O OMG pediu informação acerca de metodologia
criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança 
de ajudar a criar o padrão. 
Os esforços para a criação da UML tiveram início em outubro de 1994, quando
a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi 
lançado, em outubro de 1995, o esboço da versão 0.8 do
conhecido). Nesta mesma época, Jacobson
para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML.
Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio 
internacional de empresas que define e ratifica padrões na área de Orientação a Objetos.
Visão geral da UML 
UML 2.2, conforme a OMG, possui 14 tipos de diagramas, divididos em duas grandes categorias: Estruturais e 
Comportamentais. Sete tipos de diagramas representam informações estruturais, e os outros sete representam 
tipos gerais de comportamento, incluindo quatro em uma sub
interação. Estes diagramas podem ser visualizados de forma hierárquica, como apresentado no padrão 
de diagrama de classes abaixo: 
Adaptação da Figura A.5 da UML Superstructure Specification 2.4.1, feita com o InkScape sobre figura similar do verbete 
UML, em Inglês. 
 
 
, embora o RUP (Rational Unified Process) tenha sido especificamente 
É importante distinguir entre um modelo UML e um diagrama1 (ou conjunto de diagramas) de UML. O último é 
uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. 
Metadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas.
documentação, estruturação para sub-visualização e maior visualização 
lógica do desenvolvimento completo de um sistema de informação. 
A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso 
de sistemas grandes e complexos. Sucedeu aos conceitos de Booch
os numa única linguagem de modelagem comum e largamente utilizada. A UML 
padrão para modelar sistemas concorrentes e distribuídos.
o é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do
(OMG). O OMG pediu informação acerca de metodologias orientadas a objetos que pudessem 
criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança 
Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh
. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi 
lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (como era 
Jacobson se associou à Rational e o escopo do projeto da UML foi expandido 
para incorporar o método OOSE. Nasceu então, em junho de 1996, a versão 0.9 da UML. 
Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio 
internacional de empresas que define e ratifica padrões na área de Orientação a Objetos. 
, possui 14 tipos de diagramas, divididos em duas grandes categorias: Estruturais e 
Comportamentais. Sete tipos de diagramas representam informações estruturais, e os outros sete representam 
incluindo quatro em uma sub-categoria que representam diferentes aspectos de 
interação. Estes diagramas podem ser visualizados de forma hierárquica, como apresentado no padrão 
Adaptação da Figura A.5 da UML Superstructure Specification 2.4.1, feita com o InkScape sobre figura similar do verbete 
6 
(Rational Unified Process) tenha sido especificamente 
(ou conjunto de diagramas) de UML. O último é 
uma representação gráfica da informação do primeiro, mas o primeiro pode existir independentemente. 
Metadata Interchange) na sua versão corrente disponibiliza troca de modelos mas não de diagramas. 
visualização e maior visualização 
A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso 
Booch, OMT (Rumbaugh)os numa única linguagem de modelagem comum e largamente utilizada. A UML 
para modelar sistemas concorrentes e distribuídos. 
o é um padrão da indústria, mas esse objetivo está a tomar forma sob os auspícios do Object 
s orientadas a objetos que pudessem 
criar uma linguagem rigorosa de modelagem de software. Muitos líderes da indústria responderam na esperança 
Rumbaugh se juntou 
. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi 
Processo Unificado (como era 
se associou à Rational e o escopo do projeto da UML foi expandido 
Finalmente em 1997, a UML foi aprovada como padrão pelo OMG (Object Management Group), um consórcio 
, possui 14 tipos de diagramas, divididos em duas grandes categorias: Estruturais e 
Comportamentais. Sete tipos de diagramas representam informações estruturais, e os outros sete representam 
categoria que representam diferentes aspectos de 
interação. Estes diagramas podem ser visualizados de forma hierárquica, como apresentado no padrão 
 
Adaptação da Figura A.5 da UML Superstructure Specification 2.4.1, feita com o InkScape sobre figura similar do verbete 
7 
 
 
 
Elementos 
 De estrutura: 
 Colaboração 
 De comportamento: 
 Casos de uso 
 Interação 
 Máquina de estados 
 De agrupamento: 
 Pacote 
 Modelo 
 Associação (bidirecional) 
 Subsistema 
 Framework 
 De anotação: 
 Notas 
 
 
Análise estruturada 
Origem: Wikipédia, a enciclopédia livre. 
A análise estruturada é uma atividade de construção de modelos que utiliza c# uma notação que é própria ao 
método de análise de sistemas para a finalidade de retratar o fluxo e o conteúdo das informações utilizadas pelo 
sistema, dividir o sistema em partições funcionais e comportamentais e descrever a essência daquilo que será 
construído. 
Modelo ambiental 
O modelo ambiental descreve o ambiente no qual o sistema se insere, ou seja, descreve o contexto do sistema, 
que deve ter 3 componentes: 
Componentes do modelo ambiental:: 
 Definição de objetivos → Finalidade de sistema; 
 Lista de eventos → Os acontecimentos que ocorrem no exterior e que interagem com o sistema; 
 Diagrama de contexto → Representa o sistema como um único processo e as suas interacções com o meio 
ambiente. 
Modelo comportamental 
O modelo comportamental descreve as ações que o sistema deve realizar para responder da melhor forma aos 
eventos definidos no modelo ambiental. 
Técnicas utilizadas: 
 Diagrama de fluxos de dados (DFD); 
 Dicionário de dados (DD); 
 Diagrama de entidades e associações (ou relacionamentos) (Diagrama entidade relacionamento [DER] 
ou Modelo de entidades e relacionamentos [MER]); 
Diagramas da UML 2.0 
 
Diagramas estruturais 
 Diagrama de classes 
 Diagrama de objetos 
 Diagrama de componentes 
 Diagrama de instalação ou de implantação 
 Diagrama de pacotes 
 Diagrama de estrutura composta 
 Diagrama de perfil 
Diagramas comportamentais 
 Diagrama de caso de uso 
 Diagrama de transição de estados ou de estados 
 Diagrama de atividade 
 Diagramas de interação 
 Diagrama de sequência 
 Diagrama de interatividade ou de interação 
 Diagrama de colaboração ou comunicação 
 Diagrama de tempo ou temporal 
8 
 
 Especificação de processos (EP) - (DESENHO); 
 Diagrama de transição de estados (DTE). 
Diagramas 
 Diagrama de contexto 
 Diagrama de fluxos de dados 
 Diagrama entidade relacionamento 
 Lista de eventos 
 Tabela de decisão 
 Árvore de decisão 
 Diagrama de transição de estados 
 
LEITURA SUGERIDA NO FINAL DA AULA 4 DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
Arquitetura de software 
A arquitetura de software de um sistema consiste na definição dos componentes de software, suas propriedades 
externas, e seus relacionamentos com outros softwares. O termo também se refere à documentação da 
arquitetura de software do sistema. A documentação da arquitetura do software facilita: a comunicação entre 
os stakeholders, registra as decisões iniciais acerca do projeto de alto-nível, e permite o reúso do projeto dos 
componentes e padrões entre projetos. 
Introdução 
O campo da ciência da computação tem lidado com problemas associados, como a complexidade da informação, 
desde sua criação.1 Os primeiros problemas de complexidade foram resolvidos pelos desenvolvedores através da 
escolha da estrutura de dados, do desenvolvimento de algoritmos e pela aplicação de conceitos de separação de 
escopos. Embora o termo arquitetura de software seja relativamente novo na indústria, os princípios 
fundamentais deste campo vêm sendo aplicados esporadicamente pela engenharia de software desde o início dos 
anos 80. As primeiras tentativas de capturar e explicar a arquitetura de software do sistema foram imprecisas e 
desorganizadas – freqüentemente caracterizadas por um conjunto de diagramas.2 Durante o decorrer da década 
de 90 houve um esforço concentrado para definir e codificar os aspectos fundamentais desta disciplina. 
Inicialmente um conjunto de padrões de projeto, estilo, melhores práticas, descrição de linguagens, e lógica 
formal foram desenvolvidas durante este período. 
A disciplina de arquitetura de software é centrada na ideia da redução da complexidade através da abstração e 
separação de interesses. O glossário do site oficial SOFTWARE ENGINEERING INSTITUTE (Instituto de Engenharia 
de Software) 3 descreve que arquitetura de software é a estrutura ou estruturas de um sistema, com todos os 
elementos de software vendo e tendo suas propriedades vistas por todos os outros elementos e relacionamentos. 
Sendo a arquitetura de sistema uma disciplina em maturação, sem regras claras, a ação do arquiteto de software 
é ainda uma composição de arte e ciência. Os aspectos de arte da arquitetura de software são devidos ao fato 
que os sistemas de software comerciais suportam alguns aspectos de um negócio ou missão. Assim como o 
direcionamento de negócio chave para o suporte os sistemas são descritos nos cenários como requisitos não-
funcionais de sistema, também conhecidos como atributos de qualidade, que determinam como um sistema irá 
se comportar.4 Cada sistema é único devido à natureza do negócio que ele suporta, tal que o nível dos atributos 
de qualidade exigidos de um sistema 
como compatibilidade, extensibilidade, confiabilidade, manutenabilidade,disponibilidade, segurança, usabilidad
e, dentre outros – irão variar para cada aplicação sendo desenvolvida.4 
Para trazer a perspectiva do usuário para dentro da arquitetura de software, pode-se dizer que essa disciplina 
dá a direção dos passos que serão tomados e as tarefas envolvidas em cada área de especialidade e interesse do 
usuário, por exemplo, osstakeholdersde sistemas de software, os desenvolvedores de software, o grupo de 
suporte ao software do sistema operacional, os testadores e os usuários de negócio final. Neste sentido, a 
arquitetura de software se torna a ligação das múltiplas perspectivas que um sistema traz nele embutido. O fato 
de que estas várias perspectivas diferentes possam ser postas juntas em uma arquitetura de software padrão 
justifica e valida a necessidade de criação da arquitetura de software antes do desenvolvimento do software 
para que o projeto alcance a maturidade. 
9 
 
História 
A origem da arquitetura de software como um conceito foi primeiramente identificado no trabalho de pesquisa 
de Edsger Dijkstra em 1968 e David Parnas no início de 1970. Estes cientistas enfatizaram a importância das 
estruturas de um sistema de software e acriticidade da identificação da sua estrutura.5 O estudo deste campo 
aumentou de popularidade desde o inicio de 1990 com os trabalhos de pesquisa concentrando-se nos padrões de 
estilo de arquitetura de software, linguagens de descriçãode arquitetura de software, documentação de 
arquitetura de software, e métodos formais.6 Muitas instituições de pesquisa tais como a Carnegie Mellon 
University e a University of California, Irvine estavam realizando muitas pesquisas no campo da arquitetura de 
software. Mary Shaw e David Garlan da Carnegie Mellon escreveram um livro intitulado Software Architecture: 
Perspectives on an Emerging Discipline em 1996, o qual trazia a tona conceitos da arquitetura de software, tais 
como componentes, conexões, estilos, etc. Os esforços do UCI's (Institute for Software Research) na pesquisa da 
arquitetura de software foram inicialmente direcionados para os estilos de arquitetura, descrições de linguagens 
de arquitetura, e arquiteturas dinâmicas. 
ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software-Intensive Systems[1] foi a 
primeira norma padrão na área de arquitetura de software, e foi recentemente adotada pelo ISO como ISO/IEC 
DIS 25961. 
Descrevendo arquiteturas 
Linguagem de descrição de arquitetura 
As Linguagens de descrição de arquitetura (LDAs) são usadas para descrever a arquitetura de software. Várias 
LDAs distintas foram desenvolvidas por diferentes organizações, incluindo Wright (desenvolvido por Carnegie 
Mellon), Acme (desenvolvido por Carnegie Mellon), xADL (desenvolvido por UCI), Darwin (desenvolvido 
por Imperial College London), DAOP-ADL (desenvolvido pela University of Málaga). Elementos comuns de uma 
LDA são componente, conexão e configuração. 
Visões 
A arquitetura de software é normalmente organizada em visões7 , as quais são análogas aos diferentes tipos 
de plantas utilizadas no estabelecimento da arquitetura. Na Ontologia estabelecida pela ANSI/IEEE 1471-
2000, visões são instâncias de pontos de vista, onde cada ponto de vista existe para descrever a arquitetura na 
perspectiva de um conjunto de stakeholders e seus consortes. 
Algumas possíveis visões são: 
 Visão funcional/lógica 
 Visão de código. 
 Visão de desenvolvimento/estrutural 
 Visão de concorrência/processo/thread 
 Visão física/evolutiva 
 Visão de ação do usuário/retorno 
Várias linguagens para descrição da arquitetura de software foram inventadas, mas nenhum consenso foi ainda 
alcançado em relação a qual conjunto de símbolos ou sistema de representação deve ser adotado. Alguns 
acreditam que a UML irá estabelecer um padrão para representação de arquitetura de software. Outros 
acreditam que os desenvolvimentos efetivos de software devem contar com a compreensão única das restrições 
de cada problema, e notações tão universais são condenadas a um final infeliz porque cada uma provê 
uma notação diferenciada que necessariamente torna a notação inútil ou perigosa para alguns conjuntos de 
tarefas. Eles apontam a proliferação de linguagens de programação e a sucessão de tentativas falhas para impor 
uma simples 'linguagem universal' na programação, como uma prova da tendência do software para a diversidade 
e não para os padrões. 
Padrões de arquitetura 
 DODAF [2] 
 MODAF [3] 
 TOGAF [4] 
 Zachman framework [5] 
 Federal Enterprise Architecture [6] 
10 
 
Exemplos de arquitetura de software 
Há muitas formas comuns de projetar módulos de software de computador e suas comunicações, entre elas: 
 Cliente-Servidor 
 Computação distribuída 
 P2P 
 Quadro Negro 
 Criação implícita 
 Pipes e filtros 
 Plugin 
 Aplicação monolítica 
 Modelo em três camadas 
 Analise de sistema estruturada (baseada em módulos, mas usualmente monolíticas em dentro dos módulos) 
 Arquitetura orientada a serviço 
 Arquitetura orientada a busca 
 MVC 
 
LEITURA SUGERIDA NO FINAL DA AULA 5 DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 
 
Teste de software 
O teste do software é a investigação do software a fim de fornecer informações sobre sua qualidade em relação 
ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. 
O teste é um processo realizado pelo testador de software, que permeia outros processos da engenharia de 
software, e que envolve ações que vão do levantamento de requisitos até a execução do teste propriamente 
dito. 
Visão geral 
Não se pode garantir que todo software funcione corretamente, sem a presença de erros,1 visto que os mesmos 
muitas vezes possuem um grande número de estados com fórmulas, atividades e algoritmos complexos. O 
tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais 
a complexidade. Idealmente, toda permutação possível do software deveria ser testada. Entretanto, isso se 
torna impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades. A qualidade 
do teste acaba se relacionando à qualidade dos profissionais envolvidos em filtrar as permutações relevantes.2 
Falhas podem ser originadas por diversos motivos. Por exemplo, a especificação pode estar errada ou 
incompleta, ou pode conter requisitos impossíveis de serem implementados, devido a limitações de hardware ou 
software. A implementação também pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, 
uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema. 
O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da 
aplicação pode e, normalmente, varia significativamente de sistema para sistema. 
Os atributos qualitativos previstos na norma ISO 9126 são: 
 Funcionalidade 
 Confiabilidade 
 Usabilidade 
 Eficiência 
 Manutenibilidade 
 Portabilidade 
De forma geral, mensurar o bom funcionamento de um software envolve compará-lo com elementos como 
especificações, outros softwares da mesma linha, versões anteriores do mesmo produto, inferências pessoais, 
expectativas do cliente, normas relevantes, leis aplicáveis, entre outros. Enquanto a especificação do software 
diz respeito ao processo de verificação do software, a expectativa do cliente diz respeito ao processo de 
validação do software. Por meio da verificação será analisado se o produto foi feito cor
acordo com os requisitos especificados. Por meio da validação será analisado se foi feito o produto correto, se 
ele está de acordo com as necessidades e expectativas do cliente.
Um desenvolvimento de software organizado tem como premissa uma
como base conceitos que visem a construção de um produto de software de forma eficaz. Dentro desta 
metodologia estão definidos os passos necessários para chegar ao produto final esperado.
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera
produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de 
desenvolvimento. Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem 
ter uma metodologia de trabalho bem sol
processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento 
de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja
período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se 
obtenha um produto final com um certo nível de qualidade é imprescindível a melhoria dos processos de 
engenharia de software. 
Uma maneira viável para se assegurar a melhoria de tais
entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e 
ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como 
eficientes, como por exemplo os SW-CMM
Outro fator com grande influência sobre a qualidade do software a ser produzido
queserão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma 
disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de 
maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de 
recursos humanos e financeiros. 
De acordo com um estudo conduzido pelo
59,5 bilhões de dólares à economia dos Estados Unidos
melhorias na infraestrutura do teste de software.
Princípios 
Para Myers (2004), há princípios vitais para o test
de forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente 
analisada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as 
condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a 
implementação e para a verificação. A entidade de teste 
erros, enquanto a entidade de programação possui uma visão construtiva, em busca da implementação de uma 
especificação. 
Myers também aborda o esforço para se construir casos de teste. Deve
qualidade do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o
regressão, que permite quantificar a evolução da qualidade de software, mantendo e executando novamente 
testes realizados anteriormente. 
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência 
de erros num certo trecho de código é proporci
Basicamente, erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais 
propensos a ter erros que outros. 
Técnicas 
Existem muitas maneiras de se testar um software. 
utilizadas em sistemas desenvolvidos sobre
sistemas orientados a objeto. Apesar de os
objetivo principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas 
algumas das técnicas mais conhecidas. 
Caixa-branca Ver artigo principal: 
Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa
interno do componente de software. Essa técnica trabalha diretamente sobre o
validação do software. Por meio da verificação será analisado se o produto foi feito corretamente, se ele está de 
acordo com os requisitos especificados. Por meio da validação será analisado se foi feito o produto correto, se 
ele está de acordo com as necessidades e expectativas do cliente. 
organizado tem como premissa uma metodologia de trabalho. Esta deve ter 
a construção de um produto de software de forma eficaz. Dentro desta 
metodologia estão definidos os passos necessários para chegar ao produto final esperado. 
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera
produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de 
desenvolvimento. Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem 
ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no 
processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento 
de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja
período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar.
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se 
com um certo nível de qualidade é imprescindível a melhoria dos processos de 
Uma maneira viável para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por 
entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e 
ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como 
CMM, SE-CMM, ISO/IEC 15504 e o mais conhecido CMMI.
Outro fator com grande influência sobre a qualidade do software a ser produzido é o que diz respeito aos testes 
que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma 
disciplina dedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de 
ente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de 
De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 
Estados Unidos. Mais de um terço do custo poderia ser evitado com 
do teste de software.3 
Para Myers (2004), há princípios vitais para o teste de software. O caso de teste deve definir a saída esperada, 
de forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente 
ada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as 
condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a 
implementação e para a verificação. A entidade de teste possui uma visão destrutiva do sistema, em busca de 
erros, enquanto a entidade de programação possui uma visão construtiva, em busca da implementação de uma 
Myers também aborda o esforço para se construir casos de teste. Deve-se evitar testes descartáveis, pois a 
qualidade do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o
a evolução da qualidade de software, mantendo e executando novamente 
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência 
de erros num certo trecho de código é proporcional à quantidade de erros já encontrada anteriormente. 
Basicamente, erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais 
Existem muitas maneiras de se testar um software. Mesmo assim, existem as técnicas que sempre foram muito 
utilizadas em sistemas desenvolvidos sobre linguagens estruturadas que ainda hoje têm grande v
. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o 
objetivo principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas 
 teste de caixa-branca 
Também chamada de teste estrutural ou orientado à lógica, a técnica de caixa-branca avalia o comportamento 
. Essa técnica trabalha diretamente sobre o código fonte
11 
retamente, se ele está de 
acordo com os requisitos especificados. Por meio da validação será analisado se foi feito o produto correto, se 
de trabalho. Esta deve ter 
a construção de um produto de software de forma eficaz. Dentro desta 
Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um 
produto final que melhor agrade tanto aos clientes quanto ao próprio fornecedor, ou seja, a empresa de 
desenvolvimento. Observando este aspecto, não faz sentido iniciar a construção de um produto de software sem 
idificada e que seja do conhecimento de todos os envolvidos no 
processo. Porém, além de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento 
de software sofrem cada vez mais pressão por parte dos clientes para que o produto seja entregue num curto 
período de tempo. Este fato pode fazer com que uma sólida metodologia de trabalho acabe por se desequilibrar. 
Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se 
com um certo nível de qualidade é imprescindível a melhoria dos processos de 
e modelos sugeridos por 
entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situações e 
ambientes específicos ou para soluções genéricas, existem alguns que são mais utilizados e tidos como 
. 
é o que diz respeito aos testes 
que serão executados sobre tal produto. Todas as metodologias de desenvolvimento de software têm uma 
disciplinadedicada aos testes. Atualmente esta é uma tarefa indispensável, porém muitas vezes efetuada de 
ente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de 
resultam num custo anual de 
. Mais de um terço do custo poderia ser evitado com 
deve definir a saída esperada, 
de forma a reduzir a interpretação do critério de sucesso. A saída da execução do teste deve ser exaustivamente 
ada. Os casos de teste devem verificar não somente as condições inválidas de execução, como também as 
condições válidas. Outro conceito apresentado é utilizar pessoas e organizações diferentes para a 
possui uma visão destrutiva do sistema, em busca de 
erros, enquanto a entidade de programação possui uma visão construtiva, em busca da implementação de uma 
s descartáveis, pois a 
qualidade do teste piora gradualmente com as iterações de desenvolvimento. Em contrapartida, há o teste de 
a evolução da qualidade de software, mantendo e executando novamente 
O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existência 
onal à quantidade de erros já encontrada anteriormente. 
Basicamente, erros aparecem em grupos. Trechos específicos de código de um software qualquer estão mais 
Mesmo assim, existem as técnicas que sempre foram muito 
que ainda hoje têm grande valia para os 
serem completamente diferentes, o 
objetivo principal destas técnicas continua a ser o mesmo, encontrar falhas no software. Abaixo estão descritas 
branca avalia o comportamento 
código fonte do componente de 
software para avaliar aspectos tais como: teste de condição,
caminhos lógicos, códigos nunca executados.
Os aspectos avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a 
construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados 
anteriormente. O testador tem acesso ao código fonte da aplicaçã
ligação de bibliotecas e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando 
casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as 
variações relevantes originadas por estruturas de condições são testadas.
Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre
classes de teste para testar classes ou métodos desenvolvidos em
testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de 
codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente
diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor 
desempenho de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis 
com essa técnica de teste aplicada sobre
cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na 
realidade de produção que a soma dos aparentes pequenos tempos de execução e consum
programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de caixa
branca é recomendada para as fases de teste de 
fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produ
Caixa-preta Ver artigo principal: Teste de caixa
Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a
técnica de caixa-preta avalia o comportamento externo do
comportamento interno do mesmo.4 Dados de entrada são fornecidos, o teste é executado e o resultado obtido é 
comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são 
considerados, os casos de teste são todos derivados da especificação.
Quanto mais entradas são fornecidas, mais rico
seriam testadas, mas na ampla maioria dos casos isso é impossível.
estar ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as 
mesmas aceitas para o teste.6 Uma abordagem mais realista para 
subconjunto de entradas que maximize a riqueza do teste. Pode
que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para 
averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um
testar todos os casos possíveis pode gerar pelo menos dezenas 
Entretanto, a partir da especificação do sistema, pode
a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteir
ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.
Essa técnica é aplicável a todas as fases de teste 
de aceitação. A aplicação de critérios de teste leva o testador a produzir um conjunto de casos de teste (ou 
situações de teste). A aplicação do critério de Particionamento de Equivalência (ou
equivalência) permite avaliar se a quantidade de casos de teste produzida é coerente. O Particionamento de 
Equivalência se baseia em testar subconjuntos dos dados e não todos os dados possíveis 
às vezes impossível -, pode-se assumir que as classes de equivalência serão tratadas da mesma maneira, pois um 
único elemento da classe se comporta como um representante dess
identificadas pode-se usar a Análise de Valor Limite, o testador construirá casos de teste que atuem nos limites 
superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita 
cobertura de teste possível. Outro critério é o Grafo Causa
transformar entradas de dados em causas e saídas de dados em efeitos. Esse grafo é posteriormente convertido 
para tabela de decisão e este para casos de teste. Por fim, tem
técnica em que os analistas de teste, por meio da experiência e intuição, supõem tipos prováveis de erro.
Uma abordagem no desenvolvimento do teste de caixa
as funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é 
insuficiente para identificar certos riscos num projeto de software.
Caixa-cinza 
A técnica de teste de caixa-cinza é uma mescla do uso das técnicas de caixa
envolve ter acesso a estruturas de dados
que são executados como na técnica da caixa
considerado caixa-cinza pois a entrada e a saída estão claramente fora da caixa
ra avaliar aspectos tais como: teste de condição, teste de fluxo de dados, teste de ciclos, teste de 
caminhos lógicos, códigos nunca executados. 
avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a 
construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados 
anteriormente. O testador tem acesso ao código fonte da aplicação e pode construir códigos para efetuar a 
e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando 
ste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as 
variações relevantes originadas por estruturas de condições são testadas. 
Um exemplo bem prático desta técnica de teste é o uso da ferramenta livre JUnit para desenvolvimento de 
classes de teste para testar classes ou métodos desenvolvidos em Java. Também se enquadram nessa técnica 
testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de 
codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente
diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor 
desempenho de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis 
com essa técnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, 
cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na 
realidade de produção que a soma dos aparentes pequenos tempos de execução e consumode memória de cada 
programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de caixa
teste de unidade e teste de integração, cuja responsabilidade principal 
fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produ
Teste de caixa-preta 
Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a
preta avalia o comportamento externo do componente de software, sem se considerar o 
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é 
o previamente conhecido. Como detalhes de implementação não são 
são todos derivados da especificação. 
Quanto mais entradas são fornecidas, mais rico será o teste. Numa situação ideal todas as entradas possíveis 
seriam testadas, mas na ampla maioria dos casos isso é impossível.5 Outro problema é que a especificação pode 
ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as 
Uma abordagem mais realista para o teste de caixa-preta é escolher um 
subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possíveis 
que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para 
r a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro
testar todos os casos possíveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. 
Entretanto, a partir da especificação do sistema, pode-se encontrar um subconjunto de inteiros que maximizem 
a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteir
ímpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro. 
Essa técnica é aplicável a todas as fases de teste – teste unitário, teste de integração, teste de sistema
. A aplicação de critérios de teste leva o testador a produzir um conjunto de casos de teste (ou 
situações de teste). A aplicação do critério de Particionamento de Equivalência (ou
) permite avaliar se a quantidade de casos de teste produzida é coerente. O Particionamento de 
r subconjuntos dos dados e não todos os dados possíveis - o que seria exaustivo e 
se assumir que as classes de equivalência serão tratadas da mesma maneira, pois um 
único elemento da classe se comporta como um representante dessa classe. A partir das classes de equivalência 
se usar a Análise de Valor Limite, o testador construirá casos de teste que atuem nos limites 
superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita 
cobertura de teste possível. Outro critério é o Grafo Causa-Efeito, que consiste em utilizar a ideia de grafos para 
transformar entradas de dados em causas e saídas de dados em efeitos. Esse grafo é posteriormente convertido 
e este para casos de teste. Por fim, tem-se o critério de Error-Guessing, que é uma 
técnica em que os analistas de teste, por meio da experiência e intuição, supõem tipos prováveis de erro.
Uma abordagem no desenvolvimento do teste de caixa-preta é o teste baseado na especificação, de forma que 
as funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é 
insuficiente para identificar certos riscos num projeto de software.7 
cinza é uma mescla do uso das técnicas de caixa-preta e de caixa
estruturas de dados e algoritmos do componente a fim de desenvolver os casos de teste, 
s como na técnica da caixa-preta. Manipular entradas de dados e formatar a saída não é 
cinza pois a entrada e a saída estão claramente fora da caixa-preta. A caixa
12 
, teste de ciclos, teste de 
avaliados nesta técnica de teste dependerão da complexidade e da tecnologia que determinarem a 
construção do componente de software, cabendo portanto avaliação de mais aspectos que os citados 
o e pode construir códigos para efetuar a 
e componentes. Este tipo de teste é desenvolvido analisando o código fonte e elaborando 
ste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as 
para desenvolvimento de 
. Também se enquadram nessa técnica 
testes manuais ou testes efetuados com apoio de ferramentas para verificação de aderência a boas práticas de 
codificação reconhecidas pelo mercado de software. A aderência a padrões e boas práticas visa principalmente a 
diminuição da possibilidade de erros de codificação e a busca de utilização de comandos que gerem o melhor 
desempenho de execução possível. Apesar de muitos desenvolvedores alegarem que não há ganhos perceptíveis 
unidades de software, devemos lembrar que, no ambiente produtivo, 
cada programa pode vir a ser executado milhares ou milhões de vezes em intervalos de tempo pequenos. É na 
o de memória de cada 
programa poderá levar o software a deixar de atender aos objetivos esperados. A técnica de teste de caixa-
, cuja responsabilidade principal 
fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o código fonte produzido. 
Também chamada de teste funcional, teste comportamental, orientado a dado ou orientado a entrada e saída, a 
, sem se considerar o 
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é 
o previamente conhecido. Como detalhes de implementação não são 
será o teste. Numa situação ideal todas as entradas possíveis 
Outro problema é que a especificação pode 
ambígua em relação ao sistema produzido, e como resultado as entradas especificadas podem não ser as 
preta é escolher um 
se agrupar subconjuntos de entradas possíveis 
que são processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para 
inteiro como entrada, 
de milhares de casos de testes distintos. 
se encontrar um subconjunto de inteiros que maximizem 
a qualidade do teste. Depende do propósito do sistema, mas casos possíveis incluem inteiros pares, inteiros 
teste de sistema e teste 
. A aplicação de critérios de teste leva o testador a produzir um conjunto de casos de teste (ou 
situações de teste). A aplicação do critério de Particionamento de Equivalência (ou uso de classes de 
) permite avaliar se a quantidade de casos de teste produzida é coerente. O Particionamento de 
o que seria exaustivo e 
se assumir que as classes de equivalência serão tratadas da mesma maneira, pois um 
a classe. A partir das classes de equivalência 
se usar a Análise de Valor Limite, o testador construirá casos de teste que atuem nos limites 
superiores e inferiores destas classes, de forma que um número mínimo de casos de teste permita a maior 
Efeito, que consiste em utilizar a ideia de grafos para 
transformar entradas de dados em causas e saídas de dados em efeitos. Esse grafo é posteriormente convertido 
Guessing, que é uma 
técnica em que os analistas de teste, por meio da experiência e intuição, supõem tipos prováveis de erro. 
baseado na especificação, de forma que 
as funcionalidades são testadas de acordo com os requisitos. Apesar de necessário, esse tipo de teste é 
preta e de caixa-branca. Isso 
do componente a fim de desenvolver os casos de teste, 
preta. Manipular entradas de dados e formatar a saída não é 
preta. A caixa-cinza pode incluir 
também o uso de engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, 
além de mensagens de erro. 
Regressão Ver artigo principal: teste de regressão
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo 
ciclo de teste durante o processo de des
ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. 
Inclui-se nesse contexto a observação de fases e técnicas de teste de acordo 
provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidadedos 
testes, é recomendada a utilização de ferramentas de
ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.
Técnicas não funcionais 
São técnicas utilizadas para verificar a operação 
de entrada. Outras técnicas de teste existem para testar aspectos não
exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológic
técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas 
operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente 
ou sistema que não se relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, 
manutenibilidade e portabilidade)8 . 
Uma delas é o uso conjunto de teste de desempenho
processar grandes quantidades de dados
determina a escalabilidade do software. O
usuário é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com 
conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes 
componentes.9 Já o teste de confiabilidade
dos dados armazenados e processados. O 
retornar a um estado estável de execução após estar em um estado de 
Fases ou Níveis 
Abstração do teste 
Descendente 
 
Sistema 
Ascendente
Integração 
Unidade 
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada 
no cliente, por um grupo de profissionais 
teste ser usada para compensar atrasos do 
começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto.
Em contrapartida, algumas práticas emergentes como a
modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade são escritos primeiro 
(TDD), por engenheiros de software. Antes da implementação da unidade em questão, o te
código é escrito, passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos 
junto com o resto do código fonte do software, e geralmente também integra o processo de construção do 
software. 
Teste de unidade Ver artigo principal:
Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de 
software desenvolvidas (pequenas partes ou unidades do sistema).
as subrotinas, métodos, classes ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas 
de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.
Teste de integração Ver artigo principal:
para determinar por exemplo os limites superiores e inferiores das classes, 
teste de regressão 
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo 
ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova versão do software 
ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. 
se nesse contexto a observação de fases e técnicas de teste de acordo com o impacto de alterações 
provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos 
testes, é recomendada a utilização de ferramentas de automação de teste, de forma que, sobre a nova versão 
ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.
São técnicas utilizadas para verificar a operação correta do sistema em relação a casos inválidos ou inesperados 
de entrada. Outras técnicas de teste existem para testar aspectos não-funcionais do software, como por 
exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológic
técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas 
operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente 
e relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, 
teste de desempenho e teste de carga, que verifica se o software consegue 
processar grandes quantidades de dados, e nas especificações de tempo de processamento exigidas, o que 
do software. Oteste de usabilidade é necessário para verificar se a
é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com 
conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes 
teste de confiabilidade é usado para verificar se o software é seguro em assegurar o sigilo 
 teste de recuperação é usado para verificar a robustez do software em 
retornar a um estado estável de execução após estar em um estado de falha. 
 
Ascendente 
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada 
no cliente, por um grupo de profissionais diferente da implementação. Essa prática pode resultar na fase de 
teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prática é 
começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto.
Em contrapartida, algumas práticas emergentes como a programação extrema e o desenvolvimento ágil
tado ao teste. Nesse processo, os testes de unidade são escritos primeiro 
), por engenheiros de software. Antes da implementação da unidade em questão, o te
código é escrito, passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos 
junto com o resto do código fonte do software, e geralmente também integra o processo de construção do 
Ver artigo principal: teste de unidade 
Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de 
nas partes ou unidades do sistema).10 O universo alvo desse tipo de teste são 
, métodos, classes ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas 
uma pequena parte do sistema funcionando independentemente do todo.
Ver artigo principal: teste de integração 
13 
para determinar por exemplo os limites superiores e inferiores das classes, 
Essa é uma técnica de teste aplicável a uma nova versão de software ou à necessidade de se executar um novo 
envolvimento. Consiste em se aplicar, a cada nova versão do software 
ou a cada ciclo, todos os testes que já foram aplicados nas versões ou ciclos de teste anteriores do sistema. 
com o impacto de alterações 
provocado pela nova versão ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos 
, de forma que, sobre a nova versão 
ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade. 
correta do sistema em relação a casos inválidos ou inesperados 
funcionais do software, como por 
exemplo, a adequação a restrições de negócio, adequação a normas, ou restrições tecnológicas. Em contraste às 
técnicas funcionais mencionadas acima, que verificam a produção pelo sistema de respostas adequadas de suas 
operações, de acordo com uma especificação, as técnicas não funcionais verificam atributos de um componente 
e relacionam com a funcionalidade (por exemplo, confiabilidade, eficiência, usabilidade, 
, que verifica se o software consegue 
, e nas especificações de tempo de processamento exigidas, o que 
é necessário para verificar se a interface de 
é fácil de se aprender e utilizar. Entre verificações cabíveis estão a relação da interface com 
conhecimento do usuário, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes 
é usado para verificar se o software é seguro em assegurar o sigilo 
é usado para verificar a robustez do software em 
Uma prática comum é testar o software após uma funcionalidade ser desenvolvida, e antes dela ser implantada 
. Essa prática pode resultar na fase deprojeto, comprometendo o tempo devotado ao teste. Outra prática é 
começar o teste no mesmo momento que o projeto, num processo contínuo até o fim do projeto. 
desenvolvimento ágil focam o 
tado ao teste. Nesse processo, os testes de unidade são escritos primeiro 
), por engenheiros de software. Antes da implementação da unidade em questão, o teste falha. Então o 
código é escrito, passando incrementalmente em porções maiores dos casos de teste. Os testes são mantidos 
junto com o resto do código fonte do software, e geralmente também integra o processo de construção do 
Também conhecida como teste unitário ou teste de módulo, é a fase em que se testam as menores unidades de 
O universo alvo desse tipo de teste são 
, métodos, classes ou mesmo pequenos trechos de código. Assim, o objetivo é o de encontrar falhas 
uma pequena parte do sistema funcionando independentemente do todo. 
Na fase de teste de integração, o objetivo é encontrar falhas provenientes da integração interna dos 
componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por 
exemplo, um componente A pode estar aguardando o retorno de um valor X ao
componente B; porém, B pode retornar um valor Y, gerando uma falha. O teste de integração conduz ao 
descobrimento de possíveis falhas associadas à
o tratamento de interfaces com outros sistemas (integração entre sistemas). Essas interfaces são testadas na 
fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas 
mesmo antes de o sistema estar plenamente construído.
 
Teste de sistema Ver artigo principal:
Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as 
funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições 
similares – de ambiente, interfaces sistêmicas e massas de dados 
dia de manipulação do sistema. De acordo com a política de uma organização, podem ser utilizadas condições 
reais de ambiente, interfaces sistêmicas e massas de dados.
Teste de aceitação Ver artigo principal:
Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que 
simulam operações de rotina do sistema de modo a verificar se seu comportamento está de acordo com o 
solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e 
para permitir ao cliente determinar se aceita ou não o sistema. Validação de um 
usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes 
funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho.
Teste de operação Ver artigo princ
Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará 
em ambiente produtivo. Vale ressaltar que essa fase é aplicável somente a sistemas de informação próprios de 
uma organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste 
devem ser feitas simulações para garantir que a entrada em produção
testes de instalação, simulações com cópia de segurança
entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o 
suporte ao negócio. 
Testes alfa e beta Ver artigo principal:
Em casos especiais de processos de desenvolvimento de sof
de bancos de dados e outros softwares distribuídos em escala nacional e internacional 
também especiais antes do produto ser disponibilizado a todos os usuários.
O período entre o término do desenvolvimento e a entre
nesse período, como testes alfa. PRESSMAN
desenvolvedor, com este "olhando sobre o ombro" do usuário e registrando erros e problemas de uso.
Completada a fase alfa de testes, são lançadas a grupos restritos de usuários, versões de teste 
denominadas versões beta. Ele também é um teste de aceitação voltado para softwares cuja distribuição 
atingirá grande número de usuários de uma ou várias empresas compr
é conduzido em uma ou mais instalações do cliente, pelo usuário final do software. Diferente do teste alfa, o 
desenvolvedor geralmente não está presente. Consequentemente, o teste beta é uma aplicação do software nu
ambiente que não pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou 
imaginários) que são encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. 
Com o resultado dos problemas relatados d
modificações e depois se preparam para liberar o produto de software para toda a base de clientes.
A comunidade do teste de software usa o termo teste gama de forma sarcástica referindo
são mal testados e são entregues aos usuários finais para que estes encontrem os defeitos já em fase de 
produção. 
Candidato a lançamento 
Ultimamente, e principalmente na comunidade de
lançamento (release candidate) para indicar uma versão que é ca
quantidade de erros encontrados. Tais versões são um passo além do teste beta, sendo divulgadas para toda a 
comunidade. 
integração, o objetivo é encontrar falhas provenientes da integração interna dos 
componentes de um sistema. Geralmente os tipos de falhas encontradas são de transmissão de dados. Por 
exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um método do 
componente B; porém, B pode retornar um valor Y, gerando uma falha. O teste de integração conduz ao 
descobrimento de possíveis falhas associadas à interface do sistema.Não faz parte do escopo dessa fase de teste 
sistemas (integração entre sistemas). Essas interfaces são testadas na 
fase de teste de sistema, apesar de, a critério do gerente de projeto, estas interfaces podem ser testadas 
mesmo antes de o sistema estar plenamente construído. 
Ver artigo principal: teste de sistema 
Na fase de teste de sistema, o objetivo é executar o sistema sob ponto de vista de seu usuário final, varrendo as 
funcionalidades em busca de falhas em relação aos objetivos originais. Os testes são executados em condições 
de ambiente, interfaces sistêmicas e massas de dados – àquelas que um usuário utilizará no seu dia
acordo com a política de uma organização, podem ser utilizadas condições 
reais de ambiente, interfaces sistêmicas e massas de dados. 
Ver artigo principal: teste de aceitação 
Geralmente, os testes de aceitação são realizados por um grupo restrito de usuários finais do sistema, que 
ma de modo a verificar se seu comportamento está de acordo com o 
solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou não seus critérios de aceitação e 
para permitir ao cliente determinar se aceita ou não o sistema. Validação de um software pelo comprador, pelo 
usuário ou por terceira parte, com o uso de dados ou cenários especificados ou reais. Pode incluir testes 
funcionais, de configuração, de recuperação de falhas, de segurança e de desempenho. 
Ver artigo principal: teste de operação 
Nessa fase o teste é conduzido pelos administradores do ambiente final em que o sistema ou software entrará 
ressaltar que essa fase é aplicável somente a sistemas de informação próprios de 
uma organização, cujo acesso pode ser feito interna ou externamente a essa organização. Nessa fase de teste 
devem ser feitas simulações para garantir que a entrada em produção do sistema será bem sucedida. Envolve 
cópia de segurança dos bancos de dados, etc.. Em alguns casos um sistema 
entrará em produção para substituir outro e é necessário garantir que o novo sistema continuará garantindo o 
Ver artigo principal: versão alfa Ver artigo principal: versão beta 
Em casos especiais de processos de desenvolvimento de software – sistemas operacionais, sistemas 
e outros softwares distribuídos em escala nacional e internacional – os testes requerem fases 
também especiais