Resumo EE1 ESS

Prévia do material em texto

Introdução 
 
 A Engenharia de Software se dedica às teorias, 
métodos e ferramentas para desenvolvimento 
de software profissional -> sistemas não-triviais 
com base em um conjunto de requisitos; 
 Dedica-se ao desenvolvimento de software com 
custos adequados, respeitando o cronograma 
acordado, satisfazendo as necessidades dos 
clientes, minimizando o custo de manutenção; 
 Engenharia de Software é uma disciplina 
gerencial e tecnológica que lida com a produção 
e manutenção sistemática de produtos de 
software desenvolvidos dentro de estimativas de 
custo e tempo; 
 Se refere a sw desenvolvidos por grupos, usa 
princípios de engenharia e inclui tanto aspectos 
técnicos quanto não técnicos; 
 Software -> Programas de computador e 
artefatos associados, podem ser genéricos 
(produzido para uma grande variedade de 
clientes) ou personalizados, desenvolvidos para 
apenas um cliente, de acordo com suas 
especificações; 
 Engenharia de sistemas -> mais ampla, tem 
ênfase em aspectos de hardware e infra-
estrutura, engloba a engenharia de software; 
 Processo -> Um conjunto estruturado de 
atividades, práticas, artefatos e ferramentas 
necessários para o desenvolvimento de um 
sistema de software. Envolve especificação, 
desenvolvimento, validação e evolução. Ex: 
OpenUP, XP, Processo unificado; 
 Elementos de um processo: modelos de 
sistema (modelos gráficos e as notações a 
serem empregadas), recomendações de boas 
práticas de projeto, atividades que devem ser 
seguidas em determinada ordem, e, às 
vezes, ferramentas. Um processo adere a um ou 
mais modelos de processo; 
 Custos de ES: 60% desenvolvimento, 40% 
testes. Variam dependendo do tipo de sistema e 
de seus requisitos, e a distribuição de custo 
depende do modelo de desenvolvimento usado; 
 CASE -> Sistemas de software que fornecem 
apoio automatizado para as atividades de 
desenvolvimento de software. Podem ser Upper-
CASE (apoiam as atividades iniciais de 
processo de requisitos e de projeto) ou Lower-
CASE (apoiam as atividades finais, 
programação, debugging e teste); 
 Atributos de um bom software: facilidade de 
manutenção, confiabilidade, eficiência e 
usabilidade; 
 Desafios chave da ES: Heterogeneidade, 
Entrega, Confiança, Escalabilidade; 
 Responsabilidade profissional: 
Confidencialidade, Competência, Direito sobre 
propriedade intelectual; 
 Ética: discordância das políticas da gerência, 
liberação de um sistema de segurança crítico 
sem finalizar o teste do sistema, 
desenvolvimento de sistemas nucleares ou de 
armamentos militares. 
 
 
Processos de Software 
 
 
 Processo -> Um conjunto estruturado de atividades, procedimentos, 
artefatos e ferramentas necessários para o desenvolvimento de um 
sistema de software. Exemplo de atividades: Especificação, Projeto, 
Validação, Evolução; 
 Exemplos de processos: Processo Unificado (RUP), OpenUP, 
Programação Extrema (XP), SCRUM; 
 Pontos de consenso: Iteratividade, participação 
de usuários, flexibilidade de configuração, 
comunicação entre membros da equipe; 
 Pontos de divergência: nível de detalhamento 
das atividades, critério de conclusão das 
atividades, rigor na atribuição das tarefas, 
artefatos gerados, nível de automação, nível de 
impessoalidade; 
 Alguns autores consideram que processos 
incluem uma metodologia, enquanto outros 
afirmam que uma metodologia é a 
especialização de um processo com um 
conjunto de métodos; 
 Método -> Descrição sistemática de como deve-
se realizar uma determinada atividade ou tarefa, 
normalmente feita através de padrões e guias; 
 Modelo de processo -> Apresenta a descrição de 
um processo de uma perspectiva particular, 
normalmente focando em apenas algumas 
atividades. É usado para entendimento e 
comunicação do processo, e como base para 
análise, execução, gerência e melhoria do 
processo. A descrição deve ser formal e 
completa para permitir automação, e deve ser 
apresentada em diferentes níveis de abstração; 
 Modelos genéricos -> Representação abstrata e 
simplificada do processo de desenvolvimento de 
software, incluindo algumas atividades e sua 
organização de alto nível; 
 Modelo cascata -> Primeiro a ser utilizado, 
derivado de modelos existentes em outras 
engenharias. Uma fase tem que estar completa 
antes de passar para a próxima, as fases são 
executadas de forma sistemática e sequencial, 
envolvendo sempre atividades de validação. Na 
prática, existe uma interação entre as etapas e 
cada uma delas pode levar a modificações nas 
anteriores; 
 
o Problemas: particionamento inflexível do 
projeto, dificulta a resposta aos requisitos de 
mudança do cliente, documentos 
completamente elaborados são necessários 
para fazer as transições entre estágios, e o 
modelo é apropriado somente quando os 
requisitos são compreendidos e as mudanças 
são raras. 
 Modelo de desenvolvimento evolucionário -> 
Implementação inicial, exposição do resultado 
ao usuário e refinamento desse resultado em 
versões. Especificação, desenvolvimento e 
validação são intercalados. Existem dois tipos 
de modelos evolucionários: 
 
o Exploratório -> explora requisitos e entrega 
um sistema final; 
o Prototipação throwaway -> objetivo é 
compreender os requisitos do cliente. 
 Desenvolvimento exploratório -> 
Desenvolvimento da primeira versão do sistema 
o mais rápido possível, seguido de modificações 
sucessivas até que o sistema seja considerado 
adequado. Após o desenvolvimento de cada 
uma das versões, ele é mostrado aos usuários 
para comentários. Adequado para o 
desenvolvimento de sistemas onde é difícil ou 
impossível se fazer uma especificação 
detalhada, como sistemas especialistas que 
tentam emular capacidades humanas; 
 Prototipação descartável -> Primeira fase é 
simular ao desenvolvimento exploratório. No 
entanto, o objetivo é estabelecer os requisitos, 
então o software deve ser reimplementado na 
fase seguinte. Útil para sistemas grandes e 
complicados ou quando não existe um sistema 
anterior ou manual que ajude a especificar os 
requisitos. Os objetivos do protótipo devem estar 
bem claros antes do início da codificação, e uma 
decisão importante é escolher o que será e o 
que não será parte do protótipo; 
 Processos Iterativos -> A abordagem iterativa 
pode ser aplicada a qualquer um dos modelos 
genéricos de processo. Possui duas abordagens 
relacionadas: desenvolvimento incremental e 
desenvolvimento espiral. Em sua essência, a 
especificação é desenvolvida em conjunto com 
o software; 
 Desenvolvimento incremental -> O sistema é 
entregue ao cliente em incrementos, onde cada 
um deles fornece parte da funcionalidade 
requirida. Os requisitos são priorizados, com os 
de prioridade mais alta incluídos nos 
incrementos iniciais. Uma vez que o 
desenvolvimento de um incremento é iniciado, 
os requisitos são congelados, embora os de 
incrementos posteriores possam continuar 
evoluindo. 
 
o Vantagens: a funcionalidade de sistema é 
disponibilizada mais cedo, os incrementos 
iniciais agem como protótipos, riscos 
menores de falha geral do projeto, e os 
serviços de mais alta prioridade tendem a 
receber mais testes; 
o Desvantagens: incrementos pequenos 
exigem mapeamento entre requisitos, e 
existe uma dificuldade de identificar os 
recursos comuns exigidos por todos os 
incrementos. 
 Desenvolvimento espiral -> Acrescenta aspectos 
gerenciais ao processo de desenvolvimento de 
software. O processo é representado como uma 
espiral, onde cada loop representa uma fase do 
processo. Como não existem fases definidas, os 
loops são escolhidos dependendo do que é 
requisitado. Os riscos são explicitamente 
avaliados e resolvidos ao longo do processo. 
 
o Quadrantes: definição de objetivos, avaliação 
e reduçãode riscos, desenvolvimento e 
validação, planejamento. 
 ES baseada em componentes -> Baseada em 
reuso sistemático onde sistemas são integrados 
a partir de componentes existentes ou de 
sistemas COTS (Commercial-of-the-shelf). Cada 
vez mais usada à medida que padrões de 
componentes têm surgido. 
 
o Estágios: Especificação dos requisitos, 
análise de componentes, modificação de 
requisitos, projeto de sistema com reuso, 
desenvolvimento e integração, validação. 
 Transformação Formal -> Um especificação 
formal (definição matemática, não ambígua) é 
desenvolvida e posteriormente transformada em 
um programa através de regras que preservam 
a corretude da especificação. Motivação: 
possibilidade de gerar programas que são 
corretos por construção. Este modelo tem sido 
aplicado ao desenvolvimento de sistemas 
críticos. 
 
 
Gerenciamento de Projetos 
 
 
 Definição -> Aplicação de atividades de 
gerenciamento (planejamento, coordenação, 
medição, controle e relatório) para assegurar 
que o desenvolvimento de software é 
sistemático, disciplinado e quantificado; 
 Projeto -> um empreendimento temporário para 
criar um produto ou serviço único. Principais 
características: prazo limitado, recursos 
limitados e definidos a priori, data estipulada 
para conclusão e resultado diferente do que é 
produzido na rotina da organização; 
 
o Dimensões -> Custo, Tempo, Qualidade e 
Escopo. 
 Gerenciamento de projetos -> Está relacionado 
às atividades envolvidas em assegurar que o 
software será entregue dentro do prazo e de 
acordo com os requisitos. É necessário porque o 
desenvolvimento está sempre sujeito a 
restrições de orçamento e cronograma; 
 Particularidades -> O produto é intangível e 
flexível, a ES não tem a maturidade das outras 
engenharias, o processo de desenvolvimento 
não é padronizado e muitos projetos são únicos; 
 Atividades -> Elaboração de proposta, 
planejamento e desenvolvimento do cronograma 
de projeto, estimativa de custo do projeto, 
monitoração e revisões de projeto e elaboração 
de relatórios e apresentações; 
 Planejamento de projeto -> Atividade de 
gerenciamento que mais toma tempo, vai do 
conceito inicial até a entrega do sistema. Os 
planos são regularmente revisados, e vários 
tipos de planos podem ser desenvolvidos para 
apoiar o plano principal (particularmente focados 
no cronograma e no orçamento do projeto); 
 Plano de projeto -> Documento que define o 
trabalho que (e como #Dudu) deve ser feito, 
através de uma estimativa de tempo e recursos 
exigidos, e um contexto para gerenciamento de 
controle e revisão, para cada marco. Serve de 
benchmark para comparar com projetos 
anteriores, quando documentado 
apropriadamente. O plano de projeto melhora 
erros em estimativas e sua precisão; 
 
o Tipos: 
o 
 Plano de qualidade -> descreve os 
procedimentos e os padrões de qualidade 
usados no projeto; 
 Plano de validação -> descreve a 
abordagem, os recursos e o cronograma 
usados para a validação do sistema; 
 Plano de gerenciamento de configuração -
> descreve os procedimentos e as 
estruturas de gerenciamento de 
configuração a serem usados; 
 Plano de manutenção -> prevê os 
requisitos de manutenção do sistema, os 
custos de manutenção e o esforço 
necessário; 
 Plano de desenvolvimento de pessoal -> 
descreve como as habilidades e a 
experiência dos membros da equipe do 
projeto serão desenvolvidas; 
o Estrutura: Introdução, Organização do 
projeto, Recursos do projeto, Análise de 
riscos, Estrutura analítica, Cronograma do 
projeto, Mecanismos de monitoramento e 
elaboração de relatórios, Custo do projeto; 
 Processo de planejamento de projeto: 
 
 
 
 Organização das atividades -> As atividades devem ser organizadas 
para produzir saídas tangíveis. Marcos são o ponto final de uma 
atividade de processo. Produtos a serem entregues como resultados do 
projeto, usualmente entregues ao final de uma fase, são disponíveis para 
os clientes; 
 Tarefa -> Normalmente atribuída a uma pessoa, permite uma estimativa 
de tempo/esforço precisa. Pode-se associar a uma ou mais 
especialidades necessárias para sua realização, e podem gerar um 
resultado desejável (marco) ou parte dele; 
 Recursos -> Pessoas (com especialidades), Software (quantidade e 
versões), Hardware (quantidade e modelos); 
 Custo -> Recursos humanos, instalações, reuniões, material, etc; 
 Desenvolvimento do cronograma -> Dividir o projeto em tarefas e estimar 
tempo e recursos necessários para completar cada tarefa. Organizar 
tarefas simultâneas para fazer uso otimizado da força de trabalho. 
Minimizar dependências entre tarefas para evitar atrasos. Atividades 
PERT/CPM; 
 
o Problemas -> É difícil estimar dificuldades e problemas, a 
produtividade não é proporcional ao número de pessoas que 
trabalham em uma tarefa, a inclusão de pessoas em um projeto 
atrasado o atrasa ainda mais, o inesperado sempre ocorre (margem 
mínima de 10%); 
 Diagramas de barras e redes de atividades -> 
Notações gráficas usadas para ilustrar o 
cronograma de projeto. Mostram a quebra do 
projeto em tarefas. As redes de atividades 
mostram as dependências entre tarefas e o 
caminho crítico. Os diagramas de barras 
mostram o cronograma em comparação com o 
calendário; 
 Redes de atividades -> O gerente deve dar 
especial atenção às tarefas contidas no caminho 
crítico (leva mais tempo para ser concluído). É 
crucial ter folgas neste caminho; 
 Gerenciamento de riscos -> Está relacionado à 
identificação de riscos e à elaboração de planos 
para minimizar esses efeitos em um projeto. 
 
o Risco -> Envolve a probabilidade de que 
alguma circunstância adversa ocorra. Pode 
ser de três tipos: 
o 
 Riscos de projeto -> Afetam o cronograma 
ou os recursos; 
 Riscos de produto -> Afetam a qualidade 
ou o desempenho do software que está 
sendo desenvolvido; 
 Riscos de negócio -> Afetam a 
organização que desenvolve ou adquire o 
software. 
 Principais áreas de riscos -> pessoal, 
cronograma e custo, funcionalidade do sistema, 
nível de instabilidade dos requisitos, qualidade 
de componentes externos, etc; 
 Identificação de riscos -> Classificação de riscos 
em termos de suas possíveis fontes (tecnologia, 
pessoal, organizacionais, ferramentas, 
requisitos, estimativas); 
 Análise de riscos -> Avaliar a probabilidade e a 
seriedade de cada risco. Probabilidade pode ser 
baixa, média ou alta. Efeitos podem ser 
catastróficos, sérios, toleráveis ou 
insignificantes; 
 Planejamento de riscos -> Considerar cada risco 
e desenvolver uma estratégia para gerenciar 
este risco. Esta estratégia pode ser de 
prevenção, minimização ou de contigência; 
 Monitoração de riscos -> Avaliar regularmente 
cada um dos riscos identificados para 
determinar a probabilidade atual dele ocorrer e 
se os efeitos mudaram. Cada risco-chave deve 
ser discutido nas reuniões de gerenciamento de 
progresso; 
 Qualidades de um gerente -> Liderança, 
comunicação, capacidade de resolver 
problemas, negociação, influência na 
organização, mentor, especialista técnico e em 
processo. 
 
 
OpenUP 
 
 
 Definição -> Processo Unificado leve que aplica 
abordagens iterativa e incremental em um ciclo 
de vida estruturado. Adota filosofia ágil e possui 
foco na natureza colaborativa do 
desenvolvimento de software. É um processo 
mínimo, completo e extensível; 
 Características -> Mínimo (utiliza apenas 
conteúdo fundamental), completo (possui as 
disciplinas essenciais para o ciclo de vida de 
desenvolvimento de software), extensível (pode 
ser adaptado para projetos específicos), 
desenvolvimento iterativo e incremental, guiado 
por casos de uso e centrado na arquitetura dosistema; 
 Princípios -> Colaboração para alinhar 
interesses e compartilhar entendimento, 
equilibrar prioridades concorrentes para 
maximizar valor para o stakeholder, foco na 
arquitetura para minimizar riscos e organizar o 
desenvolvimento, e evoluir para continuamente 
obter feedback e melhoria; 
 Elementos básicos -> Produto de trabalho (o que 
é produzido), Tarefa (como executar o trabalho), 
Papel (quem faz o trabalho) e Processo (une 
tarefas, produtos e papéis, adicionando 
estrutura e sequenciamento; 
 
 
 Micro-incrementos -> O esforço pessoal é organizado em micro-
incrementos, unidades curtas de trabalho para alcançar os objetivos de 
uma iteração. Estes provêem feedback que direciona as decisões em 
cada iteração, produzindo código testado, bem como artefatos validados; 
 Lista de itens de trabalho -> Lista com todo o trabalho agendado para o 
projeto. Cada item pode conter referências para informação relevante 
para a execução do mesmo. É um ponto focal para a equipe; 
 Iterações -> Intervalos de tempo definidos e planejados, como foco na 
entrega de valor incremental aos stakeholders de manteira previsível. O 
plano de iteração define o que deve ser entregue na iteração e o 
resultado é uma versão estável e executável. O plano de iteração é 
criado com seleção dos itens de trabalho de maior prioridade; 
 Plano de Iteração -> Tem como objetivo fornecer à equipe um lugar 
central para informações a respeito dos objetivos da iteração. É um 
plano detalhado, com s atribuições das tarefas, e também ajuda a equipe 
a monitorar o progresso da iteração e avaliá-la, através de critérios de 
sucesso previamente definidos; 
 Ciclo de vida do projeto -> estruturado em quatro fases: 
 
o Concepção -> define o escopo do projeto; 
o Elaboração -> detalha os requisitos e a arquitetura; 
o Construção -> desenvolve o sistema; 
o Transição implanta o sistema. 
 Plano de projeto -> Reúne informação 
necessária para gerenciar o projeto num nível 
estratégico, identificando iterações e seus 
objetivos. Descreve como o projeto está 
organizado, identifica práticas a serem seguidas, 
define os parâmetros de rastreamento do projeto 
e especifica os objetivos das iterações (alto 
nível) e seus marcos. 
 
 
Gerenciamento de Configuração 
 
 
 Definição -> O gerenciamento de configuração exerce controle sobre os 
artefatos produzidos pelo desenvolvimento de software. É o processo de 
identificar, organizar e controlar modificações ao software sendo 
construído. A ideia é maximizar a produtividade minimizando os 
enganos; 
 O gerenciamento de configuração envolve o desenvolvimento e a 
aplicação de procedimentos e padrões para gerenciar um produto de 
software em evolução. 
 O controle de mudanças pode ser visto como parte de um processo mais 
geral de gerenciamento do projeto; 
 Artefatos que estão sob gerenciamento de configuração são chamados 
de itens de configuração; 
 Novas versões de sistemas são criadas quando eles mudam para OS 
diferentes, oferecem novas funcionalidades ou são configurados para 
requisitos de usuários particulares; 
 Principais atividades do gerenciamento de 
configuração -> Controle de versões e releases, 
gerenciamento e registro de mudanças, 
organização e geração de builds do sistema; 
 Controle de versões e releases -> Elaborar um 
esquema de identificação para versões de 
sistema, planejar quando uma nova versão será 
produzida, assegurar que procedimentos e 
ferramentas de gerenciamento das versões 
sejam aplicados adequadamente, e planejar e 
distribuir releases da nova versão do sistema; 
 Versão -> é uma instância de um sistema que é 
funcionalmente distinta de outras instância deste 
mesmo sistema; 
 Variante -> é uma versão de um sistema que 
tem apenas pequenas diferenças com relação a 
outras instâncias, normalmente devido a 
diferenças no hardware/software alvo; 
 Release -> é uma instância de um sistema 
distribuída para os usuários fora da equipe de 
desenvolvimento; 
 Identificação de versões -> Os procedimentos 
devem definir uma maneira não ambígua de 
identificar versões. Duas técnicas básicas: 
numeração de versões e identificação baseada 
em atributos: 
 
o Numeração -> É um esquema simples de 
numeração que usa uma derivação linear. A 
estrutura é uma árvore ou rede, e não uma 
sequência; 
o Identificação baseada em atributos -> Os 
atributos podem ser associados a uma 
versão. É mais flexível que um esquema 
explícito de atribuição de nomes. Na prática, 
a versão também necessita de um nome que 
facilite a referência. 
 Branching -> Consiste em usar diferentes ramos 
de desenvolvimento para aumentar o 
paralelismo. Cada ramo é chamada de branch, e 
o código não é compartilhado entre as branches. 
 
o Razões para criação de um branch -> 
implementar uma funcionalidade pontual ou 
uma solicitação de mudança, ou paralelizar o 
desenvolvimento dos componentes do 
sistema. 
 Merging -> Combinação de um desses ramos 
com o ramo principal. As diferenças entre os 
branches combinados precisam ser resolvidas; 
 Baseline -> Uma especificação ou produto que 
foi formalmente revisado e aceito, serve como 
base para passos posteriores do 
desenvolvimento. Representa a configuração do 
sw em um ponto no tempo, e só pode ser 
modificado através de procedimentos formais. 
São considerados marcos no processo de 
desenvolvimento; 
 
o Reproducibilidade -> a habilidade de 
reproduzir uma versão anterior do sistema; 
o Rastreabilidade -> Estabelece uma relação 
predecessor-sucessor entre artefatos do 
projeto; 
o Geração de relatórios -> A comparação dos 
conteúdos de dois baselines ajuda na 
depuração e criação de documentação; 
o Controle de mudanças -> referencial para 
comparações, discussões e negociações. 
 Funcionalidades de um sistema de controle de 
versões -> Manutenção de um repositório de 
itens de configuração, criação e manutenção de 
múltiplas versões, criação e merging de 
branches, capacidade de realizar consultas 
sobre versões dos sistemas, com base em seus 
atributos; 
 Gerenciamento e registro de mudanças -> Está 
relacionado à rastreabilidade das mudanças de 
um sistema de software, de modo que reparos 
realmente corrijam falhas, novas falhas possam 
ser identificadas rapidamente e que seja fácil 
descobrir quais mudanças foram implementadas 
e quando; 
 Acompanhamento de mudanças -> Ferramentas 
de gerenciamento fornecem meios para se 
acompanhar a situação de cada solicitação de 
mudança. São integrados a sistemas de e-mail, 
permitindo a distribuição eletrônica da 
solicitação de mudança; 
 Comitê de controle de mudanças (CCB) -> 
Mudanças podem ser revisadas por um grupo 
que decide se elas são ou não adequadas, o 
CCB, que pode conter representantes do cliente 
e do pessoal fornecedor; 
 Análise de impacto -> Mudanças de grande 
impacto devem ser comunicadas aos 
stakeholders envolvidos. Elas podem ser 
rejeitadas se o CCB perceber que o custo será 
maior que o benefício. As mudanças devem ser 
priorizadas e, por questões de eficiência, podem 
ser agrupadas por tema, subsistema ou área de 
negócio; 
 Procedência histórica -> É um registro das 
mudanças realizadas em um documento ou um 
componente de código. Deve registrar a 
mudança feita, a lógica, quem a fez e quando foi 
implementada. Pode ser incluída como um 
comentário no código; 
 Construção de sistemas -> É o processo de 
compilação e ligação de componentes de 
software em um sistema executável (pode incluir 
a execução de testes). Geralmente é apoiado 
por ferramentas automatizadas. 
 
 
Requisitos 
 
 
 Engenharia de requisitos -> Estabelece os 
serviços que o cliente requer de um sistema e 
as restriçõessob as quais tal sistema operará e 
será desenvolvido; 
 Requisitos -> tais serviços e restrições. Pode ser 
uma descrição abstrata de alto nível de um 
serviço, uma restrição de sistema ou até uma 
especificação matemática. Define o problema 
cujo desenvolvimento do sistema deve resolver. 
Um sistema deve ser construído de modo a 
satisfazer todos os seus requisitos; 
 
o Requisitos funcionais -> Serviços que o 
sistema deve fornecer, como o sistema deve 
reagir a entradas específicas, como ele deve 
se comportar em determinadas situações; 
o Requisitos não-funcionais -
> Restrições sobre serviços ou funções 
oferecidos pelo sistema, tais como restrições 
de tempo, padrões, linguagem de 
programação, etc: 
o 
 Requisito de produto; 
 Requisito organizacional; 
 Requisito externo; 
 Imprecisão de requisitos -> Requisitos ambíguos 
podem ser interpretados de maneiras diferentes 
pelos desenvolvedores e usuários. Requisitos 
devem ser completos e consistentes: 
 
o Completude -> Eles devem incluir descrições 
de todos os recursos requeridos; 
o Consistência -> Não deve haver conflitos ou 
contradições nas descrições dos recursos de 
sistema; 
 Metas -> RNF podem ser difíceis de definir 
precisamente. Uma meta é uma intenção geral 
do usuário. Um RNF verificável é uma 
declaração usando alguma medida que pode ser 
objetivamente testada. RNF são esperados 
serem mensuráveis. Assim, deve-se associar 
uma forma de medida a cada RNF elicitado; 
 Requisitos de usuário -> Requisitos funcionais e 
não-funcionais descritos de modo a serem 
compreensíveis por usuários que não tem 
conhecimento técnico detalhado. São 
declarações de alto nível escritas em linguagem 
natural, definidos usando tabelas, diagramas, 
etc; 
 Requisitos de sistema -> Documento estruturado 
estabelecendo descrições detalhadas das 
funções, serviços e restrições operacionais do 
sistema; 
 Requisitos e projeto -> Requisitos devem definir 
o que o sistema deve fazer (problema) e o 
projeto deve descrever como ele faz isto 
(solução). Na prática, são inseparáveis; 
 Problemas com linguagem natural -> Falta de 
clareza, confusão de requisitos, fusão de 
requisitos e dificuldade de estruturar a 
especificação; 
 Especificação em linguagem estruturada -> 
Existe um template pré-definido para requisitos, 
que são escritos de maneira padronizada. A 
terminologia usada na descrição pode ser 
limitada. Pró: a maior parte da expressividade 
da linguagem natural é mantida. Contra: O grau 
de uniformidade é imposto na especificação; 
 Outras formas: baseada em formulário, tabular, 
etc; 
 Documento de requisitos -> É a declaração 
oficial do que é requisitado pelos 
desenvolvedores do sistema. Deve incluir uma 
definição dos requisitos de usuário e uma 
especificação dos requisitos de sistema. NÃO é 
um documento de projeto; 
 Processo de engenharia de requisitos -> Os 
requisitos e as formas de obtê-los e documentá-
los variam drasticamente. Existem, porém, 
várias atividades genéricas comuns a todos os 
processos: elicitação de requisitos, análise de 
requisitos, validação de requisitos e 
gerenciamento de requisitos; 
 Elicitação e análise -> Envolve pessoal técnico 
trabalhando com os clientes para descobrir 
sobre o domínio da aplicação, os serviços que o 
sistema deve fornecer e sobre as restrições 
operacionais. Envolve os stakeholders; 
 
o Elicitação -> Interação com os stakeholders 
para coletar seus requisitos. Os requisitos de 
domínio também são descobertos nesse 
estágio. Técnicas de elicitação: 
o 
 Entrevistas; 
 Questionários; 
 Brainstorming; 
 Casos de uso; 
o Análise e Negociação -> Agrupa requisitos 
relacionados e organiza-os em conjuntos 
coerentes, bem como prioriza requisitos e 
soluciona conflitos de requisitos; 
o Documentação -> Os requisitos são 
documentados e colocados na próxima volta 
da espiral; 
 Identificação de requisitos -> Processo de reunir 
informações sobre os sistemas propostos e 
existentes. As fontes de informação incluem 
documentação, stakeholders e especificações 
de sistemas similares. Protótipos também 
podem ser usados; 
 Problemas da análise -> Stakeholders não 
sabem o que querem, expressam requisitos em 
seus próprios termos, podem ter requisitos 
conflitantes, fatores organizacionais e políticos 
podem influenciar e podem ocorrer mudanças 
de requisitos durante o processo de análise; 
 Atribuição de Prioridade -> É essencial 
determinar a prioridade dos requisitos junto ao 
cliente. Requisitos de maior prioridade são 
considerados em primeiro lugar. Três classes 
distintas: essenciais, importantes e desejáveis; 
 Validação de requisitos -> Dedica-se a mostrar 
que os requisitos definem o sistema que o 
cliente realmente deseja, evitando custos de 
erros de requisitos. Técnicas: 
 
o Revisões de requisitos -> análise manual 
sistemática dos requisitos, potencialmente 
acompanhada por stakeholders; 
o Prototipação -> uso de um modelo executável 
do sistema para verificar requisitos; 
o Geração de casos de teste -> 
desenvolvimento de testes para requisitos a 
fim de verificar a testabilidade, testes de 
aceitação; 
 Verificação de requisitos -> 
 
o Verificação de validade -> O sistema fornece 
as funções que melhor apoiam as 
necessidades do cliente? 
o Verificação de consistência -> Existe algum 
tipo de conflito de requisitos? 
o Verificação de completude -> Todas as 
funções requisitadas pelo cliente foram 
incluídas? 
o Verificação de exequibilidade -> Os requisitos 
podem ser implementados com o orçamento 
e a tecnologia disponíveis? 
o Facilidade de verificação -> Os requisitos 
podem ser verificados? 
 Gerenciamento de requisitos -> É um processo 
para compreender e controlar as mudanças de 
requisitos. Deve ser aplicado a todas as 
mudanças propostas aos requisitos. O impacto 
da mudança deve ser avaliado para todo o 
sistema. Estágios principais: 
 
o Análise de problema -> discutir problemas e 
mudanças de requisitos; 
o Análise de mudança e estimativa de custo -> 
avaliar os efeitos da mudança sobre os 
outros requisitos; 
o Implementação de mudança -> modificar 
vários artefatos para refletir as mudanças; 
 Rastreabilidade -> Tem a ver com 
relacionamentos entre os requisitos, suas fontes 
e o projeto do sistema. É necessário manter 
essa informação registrada nos locais 
apropriados: 
 
o Rastreabilidade da fonte -> Ligam requisitos 
aos stakeholders que os propuseram ou aos 
elementos externos que o criaram; 
o Rastreabilidade de requisitos -> É a ligação 
dos requisitos dependentes; 
o Rastreabilidade de projeto -> Ligações entre 
os requisitos e os módulos de projeto; 
 Caso de Uso -> Sequência de ações, executada 
pelo sistema, que gera um resultado de valor 
observável e para um ator particular. A 
descrição de um caso de uso define o que o 
sistema faz quando o caso de uso é realizado. A 
funcionalidade do sistema é definida por um 
conjunto de casos de uso, cada um 
representando um fluxo de eventos específico; 
 
o Ator -> Alguém ou alguma coisa (fora do 
sistema) que interage com o sistema; 
 Reuso em Use Cases -> Comportamento 
comum a mais de dois casos de uso, pode-se 
modelar como use case para ser reusado. Três 
possibilidades: inclusão, extensão, 
generalização/especialização; 
 Inclusão -> Vários use cases possuem texto de 
fluxo de eventos comum. Equivalente ao 
#include da linguagem C. Notação: <<include>>, 
com a seta na direção do caso de uso que é 
necessário; 
 Extensão -> Um caso de uso pode ser estendido 
por outro. A extensão ocorre em pontos 
específicos, os chamados pontos de extensão. 
Há também extensão de texto (sob condições 
particulares). Pode ser usada para simplificar 
fluxoscomplexos, representar componentes 
opcionais ou lidar com exceções. Notação: 
<<extend>>; 
 Especialização -> Um caso de uso pode 
especializar outro, permitindo modelar 
comportamento de estruturas de aplicação em 
comum. Notação: seta com ponta vazia na 
direção da "superclasse"; 
 Fluxo de eventos -> Parte mais importante de 
um caso de uso, define a sequência de ações 
entre o ator e o sistema, geralmente escrito em 
linguagem natural, mas também pode ser 
expresso formalmente. Na descrição surgem 
caminhos alternativos, casos e efeitos 
diferentes. Eventualmente, todos os caminhos 
possíveis são descritos; 
 Sub-fluxos de eventos -> Podem ser principais 
ou alternativos/opcionais. Esta abordagem visa 
o reuso de fluxos de eventos; 
 Diagrama de atividades -> Descreve aspectos 
dinâmicos de um sistema através de fluxo de 
tarefas. É uma alternativa para modelar fluxos 
de eventos de casos de uso; 
 Diagrama de Casos de Uso -> Casos de uso são 
organizados dentro de um diagrama que 
caracteriza limites da funcionalidade do sistema. 
Atores são relacionados por 
generalização/especialização. 
 
 
 
Testes de Software 
 
 Motivação -> Ocorrência de falhas humanas no processo de 
desenvolvimento de software é considerável, e os custos associados a 
estas falhas justificam um processo de testes cuidadoso e bem 
planejado; 
 Falha -> Incapacidade do software de realizar a função requisitada 
(aspecto externo). Ex: terminação anormal, restrição temporal violada; 
 Falta -> Causa de uma falha. Ex: código incorreto ou faltando; 
 Erro -> Estado intermediário. Provém de uma falta e pode resultar em 
falha, se propagado até a saída; 
 Confiabilidade -> É uma estimativa probabilística, mede a frequência 
com que um software irá executar sem falha em um dado ambiente e por 
um determinado período de tempo. Assim, entradas para testes devem 
se aproximar do ambiente do usuário final; 
 Dados de teste -> Entradas selecionadas para testar o software; 
 Casos de teste -> Dados de teste, bem como saídas esperadas de 
acordo com a especificação (veredicto), cenários específicos de 
execução; 
 Eficácia de testes -> A atividade de teste é o processo de executar um 
programa com a intenção de descobrir um erro. Um bom caso de teste é 
aquele que apresenta uma elevada probabilidade de revelar um erro 
ainda não descoberto. Um teste bem sucedido é aquele que revela um 
erro ainda não descoberto; 
 Padronização de testes -> 
 
o Sistemático -> Testes aleatórios não são 
suficientes. Testes devem cobrir todos os 
fluxos possíveis do software e representar 
situações de uso reais; 
o Documentado -> Que testes foram feitos, 
quais foram os resultados, etc.; 
o Repetível -> Se encontrou ou não erro em 
determinada situação, deve-se poder repetí-
lo; 
 Abordagem funcional -> São os testes de "caixa 
preta", gerados a partir de uma análise dos 
relacionamentos entre os dados de entrada e 
saída, com base nos requisitos levantados com 
os usuários. Geralmente é aplicado durante as 
últimas etapas do processo de teste. Procura 
encontrar erros associados a não satisfação da 
especificação, erros na GUI, erros de acesso ao 
banco de dados e problemas de integração; 
 Abordagem estrutural -> São os testes de "caixa 
branca", gerados a partir de uma análise dos 
caminhos lógicos possíveis de serem 
executados. É utilizado conhecimento do 
funcionamento interno do software. Seu objetivo 
é garantir que todos os caminhos independentes 
dentro de um módulo tenham sido exercitados 
pelo menos uma vez, para valores falsos e 
verdadeiros. Também pretende executar laços 
dentro dos valores limites e avaliar as estruturas 
de dados internas; 
 Estágios de teste -> 
 
o Teste de unidade -> Componentes individuais 
são testados para assegurar que os mesmos 
operam de forma correta; 
o Teste de aspectos OO -> Características 
típicas de orientação a objetos são testadas 
(testes de construtores, de hierarquia de 
tipos, etc.); 
o Teste de integração -> A interface entre as 
unidades integradas é testada; 
o Teste de sistema -> Envolve a integração de 
dois ou mais componentes para criar um 
sistema ou subsistema. Pode envolver um 
teste de incremento para ser entregue ao 
cliente. Os elementos de software integrados 
com o ambiente operacional são testados 
como um todo; 
o Teste de aceitação -> Realizado pelo usuário, 
tem como finalidade demonstrar a 
conformidade com os requisitos de software. 
Pode ser alfa (feito pelo usuário geralmente 
nas instalações do desenvolvedor, que 
observa e registra erros ou problemas) ou 
beta (feito pelo usuário em suas próprias 
instalações, sem a supervisão do 
desenvolvedor); 
 Tipos de teste -> São definidos em relação aos 
diversos tipos de requisitos descritos no 
documento de requisitos: 
 
o Teste funcional -> A funcionalidade geral do 
sistema em termos de regras de negócio é 
testada; 
o Teste de recuperação de falhas -> O software 
é forçado a falhar de diversas maneiras para 
que seja verificado o seu comportamento, 
bem como a adequação dos procedimentos 
de recuperação; 
o Teste de segurança -> Verifica se todos os 
mecanismos de proteção de acesso estão 
funcionando satisfatoriamente; 
o Teste de integridade de dados -> Verifica a 
corretude dos métodos de acesso à base de 
dados e a garantia das informações 
armazenadas; 
o Teste de performance -> Verifica o tempo de 
resposta e processamento; 
o Teste de volume -> Foca em transações do 
BD, verifica se o sistema suporta altos 
volumes de dados em uma única transação, 
bem como o número de terminais, modems e 
bytes de memória que é possível gerenciar; 
o Teste de estresse -> Verifica a funcionalidade 
do sistema em situações limite; 
o Teste de configuração ou portabilidade -> 
Verifica o funcionamento adequado do 
sistema em diferentes configurações de 
hardware/software; 
o Teste de instalação e desinstalação -> 
Verifica a correta instalação e desinstalação 
do sistema para diferentes plataformas de 
HW/SW e opções de instalação; 
o Teste da GUI -> Aparência e comportamento 
da GUI, navegação, consistência, aderência 
a padrões, tempo de aprendizagem e 
funcionalidade; 
o Teste de documentação -> Verifica se a 
documentação corresponde à informação 
correta e apropriada; 
o Teste de ciclo de negócios -> Garante que o 
sistema funciona adequadamente durante um 
ciclo de atividades relativas ao negócio; 
o Teste de regressão -> Re-execução de testes 
feitos após uma manutenção corretiva ou 
evolutiva; 
 Diretrizes de teste -> São recomendações para 
auxiliar a equipe de teste a escolher os testes 
que revelarão defeitos no sistema. 
 
 
Testes de Unidade 
 
 
 Teste de unidade -> Investiga a qualidade de 
componentes individuais, com o objetivo de 
testar comportamento e estrutura interna; 
 
o Estratégia -> Criação de um driver de teste, 
programa que executa o módulo a ser 
testado usando os dados do caso de teste e 
verifica o veredicto; 
 Teste de caixa preta -> Casos de teste são gerados usando somente a 
especificação da unidade a ser testada. Deve-se analisar a relação entre 
a pré e a pós-condição, tentando cobrir todas as combinações lógicas 
entre estas partes; 
 
o Vantagens -> o procedimento de teste não é influenciado pela 
implementação, os resultados podem ser avaliados por pessoas 
sem conhecimento da linguagem de programação e é robusto em 
relação a mudanças na implementação; 
 Seleção de dados de teste -> Existem várias 
técnicas: particionamento, fronteiras, pares 
ortogonais, etc; 
 
o Particionamento -> Determina partições e 
seleciona representantes; 
o Fronteiras -> Estatísticas indicam que há uma 
maior suscetibilidadea erros nas fronteiras 
das partições. Muito indicada para investigar 
bom funcionamento de arrays, vetores, 
algoritmos de busca/ordenação, etc.; 
 Teste de caixa branca -> Casos de teste são 
gerados a partir da lógica de implementação da 
unidade a ser testada. Não se pode avaliar o 
grau de cobertura de uma funcionalidade pelo 
teste de caixa preta. A ideia é gerar dados de 
teste que permitam exercitar algum critério em 
relação ao código; 
 Grafo de fluxo de controle -> Nó = bloco de 
comandos sequenciais, Aresta = transferência 
de controle; 
 
 
 Critérios de cobertura -> Cobertura de instruções, de decisões ou de 
condições: 
 
o Cobertura de instruções -> Cada instrução deve ser executada pelo 
menos uma vez; 
o Cobertura de decisões -> Cada expressão lógica em 
estruturas de controle é avaliada pelo menos 
uma vez para verdadeiro e falso. Geralmente 
satisfaz cobertura de instruções, desde que 
toda instrução esteja no mesmo caminho 
da cobertura de decisão; 
o Cobertura de condições -> Cada condição em uma decisão é 
exercitada pelo menos uma vez para os possíveis resultados. 
 
 
Testes de Integração, Sistema e Aceitação 
 
 
 Teste de integração -> Unidades ou aplicações que foram testadas em 
separado são testadas de forma integrada. A interface entre elas é 
testada. O teste de integração deve ser feito de forma incremental, e 
executado por um testador de integração. A integração dos módulos 
pode ser feita através das abordagens Top-down ou Bottom-up; 
 Stubs -> São pseudo-implementações de 
determinadas especificações (casos básicos, 
triviais ou esperados); 
 Drivers -> São operações que automatizam 
testes de acordo com casos de teste; 
 Abordagem Top-down -> Os módulos são 
integrados de cima pra baixo, utilizando driver e 
stubs. O driver é utilizado como módulo de 
controle principal, e os módulos reais são 
substituídos por stubs. À medida que os testes 
vão sendo realizados, os stubs são substituídos 
pelos módulos reais, um de cada vez; 
 
o Vantagens -> Permite verificação antecipada 
de comportamento de alto nível, apenas um 
único driver é necessário, módulos podem 
ser adicionados, um por vez, em cada passo, 
se desejado, e suporta as abordagens 
breadth first e depth first; 
o Desvantagens -> Retarda verificação de 
componentes de baixo nível, stubs são 
necessários para suprir elementos ainda 
inexistentes; 
 Abordagem Bottom-up -> A integração é feita a 
partir do nível mais básico da hierarquia. Os 
stubs nem sempre são necessários. Os módulos 
do nível inferior são combinados e, para cada 
combinação, é criado um driver que coordena a 
entrada e a saída dos casos de teste. Após o 
teste, o driver é substituído pela combinação de 
módulos correspondentes, que passam a 
interagir com os módulos de nível superior; 
 
o Vantagens -> Permite verificação antecipada 
de comportamento de baixo nível, stubs nem 
sempre são necessários; 
o Desvantagens -> Retarda verificação de 
comportamento de alto nível, drivers são 
necessários para elementos ainda não 
implementados e como sub-árvores são 
combinadas, um grande número de 
elementos deve ser integrado de uma só vez; 
 Testes baseados em chamadas -> Os testes 
top-down e bottom-up são puramente 
funcionais. Usando abordagem estrutural, 
podemos identificar dependências entre 
unidades através de duas técnicas: por pares e 
por vizinhança, obtendo melhorias ao reduzir 
stubs e drivers; 
 Teste de sistema -> Investiga o funcionamento 
da aplicação como um todo. A integração dos 
componentes de sw com o ambiente 
operacional é realizada e testada. Geralmente 
emprega teste funcional, idealmente executado 
por um membro de um grupo independente de 
testes. Pode utilizar o diagrama de casos de uso 
como fonte de funcionalidades e pode ser 
guiado pelos fluxos dos casos de uso; 
 Teste de aceitação -> Testes funcionais, 
realizados pelo usuário, objetivando demonstrar 
a conformidade com os requisitos do software. 
Envolve treinamento, documentação e 
empacotamento. Podem ser de duas categorias: 
 
o Alfa -> Feitos por usuários, geralmente nas 
instalações do desenvolvedor. Observam e 
registram problemas; 
o Beta -> Feitos por usuários, geralmente em 
suas próprias instalações, sem supervisão do 
desenvolvedor. Problemas detectados são 
relatados ao desenvolvedor.