- Qual a importância do Software no cenário Mundial?

- Automatização da informação e as economias de TODAS as nações são dependentes

de softwares

- O Software contribui/contribuiu para a evolução de algumas áreas?

- Telecomunicações; Geoprocessamento; Engenharia Genética.

- Para quem desenvolvemos software?

- Para clientes que querem se atualizar para o mercado.

- O que é e como podemos definir SOFTWARE?

- São instruções que quando executadas fornecem as características e desempenho

desejados; Estruturas de dados que permitem aos programas manipular adequadamente a
informação; Documentos que descrevem a operação e o uso dos programas. Etc.

- As atividades genéricas de um Processo de Software são:

- Especificação: o que o sistema deve fazer e suas restrições de desenvolvimento;

- Desenvolvimento: produção do sistema de software;
- Validação: verificação de que o software é o que o cliente deseja;
- Evolução: mudança do software em resposta às demandas de mudança.

- Atributos de um bom software:

- O software deve fornecer a funcionalidade e o desempenho requeridos para o usuário

e deve ser manutenível, confiável e aceitável.

- Processo de Software: um conjunto de etapas que devem ser seguidas para o

desenvolvimento de um produto.

- Processo de software genérico:

- Comunicação: entre cliente e analistas (levantamento de requisitos);

- Planejamento: plano de trabalho de ES (técnicas utilizadas, riscos, recursos,
cronogramas);
- Modelagem: representação dos requisitos em modelos que traduzem as necessidades
dos clientes;
- Construção: geração de código (manual e/ou automática) e testes (revelar erros);
- Implantação: software entregue ao cliente para avaliação.

- Fases de um Processo de Desenvolvimento de Softwares (Linhas Gerais):

- Análise de requisitos e Especificação do problema;

- Projeto de Software;
- Implementação;
- Verificação e Validação;
- Manutenção.

- Modelos Incrementais de Processo: basicamente são escolhidos para atuar em contextos

onde o documento de requisitos está bem definido e as funcionalidades podem ser
adicionadas e, posteriormente, trabalhadas.
 - Modelo Incremental: projeto com poucas pessoas; avaliação do núcleo, e; depois os
detalhes.
- Modelo RAD: ciclo curto; utiliza uma abordagem baseada em componentes; atividades
genéricas.

- Modelos Evolucionários de Processo: são modelos ITERATIVOS, permitindo que os

engenheiros de software criem verões cada meus mais completas do software.

- Modelo Prototipagem: projeto com definição de objetivos gerias; não possui detalhes;
alto grau de incertezas; melhor comunicação com o cliente.
- Modelo Espiral: combina a natureza iterativa (Prototipagem) com aspectos controlados
e sistemáticos (Cascata)

- Modelos Especializados de Processos: são aplicados quando uma abordagem de Engenharia

de Software é claramente definida.

- Processo Unificado (PU): guiado por casos de uso, centrado na arquitetura, iterativo e
incremental -> relacionado aos sistemas de grande porte e complexos.

- Desenvolvimento Ágil: enfoca os talentos e habilidades dos indivíduos moldando o processo

e pessoas e equipes especificas. O processo se molda às necessidades das pessoas e das
equipes.

- Indivíduos e interações em vez de processos e ferramentas;

- Softwares funcionando em vez de documentação abrangente;
- Colaboração do cliente em vez de negociação de contratos;
- Respostas a modificações em vez de seguir um plano;

- Como criar um processo que possa gerenciar a imprevisibilidade?

- Está na adaptabilidade do processo (as modificações rápidas do projeto e das

condições técnicas). Um processo ágil deve ser adaptável. (O feedback do cliente deve ocorrer
durante a etapa de desenvolvimento)

- Modelos de Processos Ágeis:

- Extreme Programming (XP): usa a abordagem OO como seu paradigma de

desenvolvimento predileto;
- Planejamento: tenta definir a necessidade do cliente
- Projeto: segue rigorosamente o princípio da simplicidade. A história deve ser implementada
como está escrita.
- Codificação: após a definição das histórias, o XP recomenda que não se avance para a
programação e sim para elaboração de testes unitários para cada história.
- Teste: criação dos testes unitários antes da codificação é um elemento chave da abordagem XP;

- Scrum: Pequenas equipes para maximizar a comunicação e gerenciamento das

atividades; Desenvolvimento dividido em partições claras, baixo acoplamento, ou em pacotes.

- Modelagem Ágil: necessidade de Engenheiros de Softwares em construir sistemas

grandes e críticos.
- Práticas de Engenharia de Software:

- Práticas de Comunicação (levantamento de requisitos): o cliente tem um problema que

pode ser adequado a uma solução baseada em computador.
- Escute: prepare-se antes de se comunicar; alguém deve facilitar a atividade; comunicação face-
a-face é melhor; faça anotações e documente as decisões; busque colaboração; modularize sua discussão; se algo
não está claro, desenhe uma figura.

- Práticas de Planejamento: inclui um conjunto de práticas gerenciais e técnicas que

permite à equipe de software atingir seus objetivos.
- Entenda o escopo do projeto; envolva o cliente na atividade de planejamento; reconheça que o
planejamento é iterativo; estime com base no que é sabido; considere os riscos à medida que você define o plano;
seja realista;

- Práticas de Modelagem: criamos modelos para obter um melhor entendimento da

entidade real a ser construída. Para um software são criados modelos de análise (requisitos) e
de projeto (arquitetura, interface e componentes).
- Princípios de Modelagem de Análise: O domínio de informação de um problema precisa ser
representado e entendido; As funções a serem desenvolvidas pelo software devem ser definidas; O comportamento
do software (eventos externos) precisa ser representado; Os modelos que mostram informação, função e
comportamento devem ser particionados de um modo que revele detalhes em forma de camadas (ou hierarquias).
A tarefa de análise deve ir da informação essencial até os detalhes de implementação;
- Princípios de Modelagem de Projeto: O projeto deve estar relacionado ao modelo de análise;
Sempre considere a arquitetura do sistema a ser construído; O projeto dos dados é tão importante quanto o projeto
de funções de processamento; As interfaces (tanto externas quanto internas) precisam ser projetadas com cuidado
(componentes); O projeto de interface com o usuário deve estar sintonizado com as necessidades do usuário final.
No entanto, em cada caso, deve enfatizar a facilidade de uso; O projeto em nível de componente deve ser
funcionalmente independente; Os componentes devem ser fracamente acoplados uns aos outros e ao ambiente
externo;

- Práticas de Construção: compreende um conjunto de tarefas de codificação e teste que

levam o software operacional que está pronto e que pode ser entregue ao cliente/usuário final.
- Princípios de Teste: consiste na descoberta de problemas em um sistema.
- Princípios e Conceitos de Codificação: estilo de programação, linguagens de programação e
métodos de programação rigorosamente definidos.

- Engenharia de Requisitos: o processo de estabelecer os serviços que o cliente requer a partir

de um sistema e as restrições sob as quais ele opera e é desenvolvido. Os próprios requisitos
são as descrições dos serviços de sistema e das restrições que são geradas durante o processo
de engenharia de requisitos.

- Requisitos funcionais: são declarações de serviços que o sistema deve fornecer, como o
sistema deve reagir a entradas especificas e como o sistema deve se comportar em
determinadas situações.

- Requisitos não funcionais: são restrições sobre serviços ou funções oferecidas pelo sistema
tais como restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc.

- Requisitos de domínio: são requisitos que vêm do domínio de aplicação do sistema e que
refletem as características desse domínio.

- Requisitos e Projetos: requisitos deve definir o que o sistema deve faze e o projeto deve
descrever como ele faz isto.

- Requisitos de usuário são declarações de alto nível sobre o que o sistema deve fazer. Esses
requisitos devem ser escritos usando linguagem natural, tabelas e diagramas.
- Requisitos de sistema se destinam a comunicar quais as funções que o sistema deve fornecer.

- Um documento de requisitos de software é uma declaração acordada dos requisitos de

sistema.

- O padrão IEEE é um ponto de partida útil para definição de padrões de requisitos mais
detalhados e específicos.

- Atividades Genéricas para Processo de Engenharia de Requisitos:

- Elicitação de requisitos;
- Análise de requisitos;
- Validação de requisitos;
- Gerenciamento de requisitos.

- Estudo de viabilidade: decide de vale a pena ou não gastar tempo e esforço com sistema
proposto.

- A elicitação e a análise de requisitos constituem um processo iterativo, envolvendo

entendimento de domínio, coleta, classificação, estruturação, priorização e validação de
requisitos;

- Casos de uso: constituem uma técnica baseada em cenários UML que identificam os agentes
em uma interação, que descrevem a interação em si; um conjunto de casos de uso deve
descrever todas as possíveis interações com o sistema.

- Validação de Requisitos: tem por objetivo mostrar que os requisitos definem o sistema que o
cliente realmente deseja.

- Gerenciamento de Requisitos: é o processo de gerenciamento de mudanças de requisitos

durante o processo de engenharia de requisitos e o desenvolvimento de sistema.

- Modelagem de Análise, principais objetivos:

- Explicar por que o contexto de um sistema deve ser modelado como parte do processo
de Engenharia de Requisitos;
- Descrever a modelagem de comportamento de dados e de objetos;
- Apresentar algumas das notações usadas na UML (Linguagem unificada de
Modelagem)
- Mostrar como workbenches CASE apoiam a modelagem de sistema.

- A modelagem de sistema auxilia o analista a entender a funcionalidade do sistema e os

modelos são usados para se comunicar com os clientes.

- Tipos de Modelos:
- Modelo de fluxo de dados que mostra como os dados são processados em estágios
diferentes.
- Modelo de composição que mostra como as entidades são compostas de outras
entidades.
- Modelo de arquitetura que mostra os subsistemas principais.
- Modelo de classificação que mostra como as entidades têm características comuns.
- Modelo estímulo-resposta que mostra a reação do sistema aos eventos
- Modelo de contexto: são usados para ilustrar o contexto operacional de um sistema – eles
mostram o que se encontra nos limites do sistema.

- Modelos de Processos: mostram o processo geral e os processos que são apoiados pelo
sistema.

- Modelos de Comportamento: são usados para descrever o comportamento geral de um

sistema.

- Modelos de Dados: são usados para descrever a estrutura lógica dos dados processados pelo
sistema.

- Modelos de Objetos: descreve o sistema em termos de classes de objeto e suas associações.

Uma classe de objeto é uma abstração de um conjunto de objetos com atributos comuns e os
serviços fornecidos por cada objeto.

- Workbenches CASE: é um conjunto de ferramentas coerentes projetado para apoiar as

atividades relacionadas de processo de software, tais como análise, projeto ou teste.

- Arquitetura não é o software operacional, mas uma representação que permite ao

engenheiro de software analisar a efetividade do projeto em satisfazer seus requisitos
declarados; considerar alternativas arquiteturais em um estágio em que fazer modificações
de projeto é relativamente fácil; reduzir os riscos associados à construção do software.

- Projeto de Dados: são estruturas criadas para realizar o armazenamento de dados definidos
na etapa de projeto de análise (Mineração de dados).

- Estilos e Padrões Arquiteturais: podem ser definidos como gabaritos para a construção de
um software. Retrata a estrutura interna do software
- Um conjunto de componentes que realizam a função do requisito do sistema;
- Um conjunto de conectores entre componentes;
- Restrições que definem como os componentes podem ser integrados para formar o
sistema;
- Modelos semânticos que possibilitam ao projetista entender as propriedades gerais de
um sistema pela análise das propriedades conhecidas de duas partes construtivas.

- Arquitetura centrada nos dados: possui uma base de dados centralizada.

- Arquitetura de fluxo de dados: utilizada quando dados de uma entrada devem ser
transformados por meio de uma série de componentes;

- Arquitetura de Chamada e Retorno: permite ao arquiteto de programa definir uma estrutura

fácil de modificar.

- Arquitetura Orientada a Objetos: componentes encapsulam os dados e as operações que

devem ser aplicadas para manipular os dados.

- Arquitetura em Camadas: um certo número de camadas é criado para organizar o software.

- Padrões Arquiteturais são responsáveis por tratar algumas características comportamentais

do sistema:
- Concorrência: capacidade do sistema em tratar múltiplas tarefas;
 - Persistência: são os dados que “sobrevivem” após a execução do programa;
- Distribuição: retrata a comunicação do software em um ambiente distribuído.

- Projeto Arquitetural: à medida que um projeto arquitetural começa, o software a ser

desenvolvido deve ser colocado no contexto. O projeto deve definir quem irá interagir com o
sistema.

- Avaliação de Alternativas de Projeto Arquitetural: para auxiliar os Engenheiros de Software

na definição de uma arquitetura de software temos a ADL (Descrição de Linguagem
Arquitetural), que fornece uma sintaxe e semântica para descrever uma arquitetura de
software.
- Uma ADL fornece ao projetista a habilidade de decompor componentes arquiteturais,
compor componentes individuais em blocos arquiteturais menores e identificar mecanismos de
conexão entre componentes.

- Mapear Fluxo de Dados para um Arquitetura de Software: o fluxo de informação representa

o caminho que é percorrido para a execução de uma funcionalidade, os caminhos podem estar
dispostos em “linhas retas” ou “sinuosas”

- Arquitetura de Sistemas Distribuídos:

- Arquitetura cliente-servidor: serviços distribuídos que são solicitados pelos clientes. Os
servidores que fornecem serviços são tratados de maneira diferente dos clientes que usam esses
serviços.
- Arquitetura de objetos distribuídos: não há distinção entre clientes e servidores.
Qualquer objeto no sistema pode fornecer e usar serviços de outros objetos.

- Middleware: software que gerencia e apoia os componentes diferentes de um sistema

distribuído. Geralmente adquirido no mercado.

- Arquitetura em Camadas:
- Camada de apresentação: está relacionada à apresentação dos resultados de um
processamento para os usuários do sistema, e à coleta de entradas do usuário.
- Camada de processamento de aplicação: está relacionada ao fornecimento de
funcionalidade específica da aplicação, por exemplo, em um sistema de banco, funções
bancárias, tais como abrir a conta, fechar conta, etc.
- Camada de gerenciamento de dados: está relacionada ao gerenciamento do banco de
dados do sistema (NÃO DIGA!!)

- Organização das Camadas:

- Modelo de cliente-magro: todo o processamento de aplicação e o gerenciamento de
dados é realizado no servidor. O cliente é responsável, simplesmente, por executar o software
de apresentação. – Usado quando sistemas legados são migrados para arquiteturas cliente-
servidor.
- Modelo de cliente-gordo: o servidor é responsável somente pelo gerenciamento de
dados. O software do cliente implementa a lógica da aplicação e as interações com o usuário do
sistema. – Usado quando mais processamento é delegado ao cliente quando o processamento
da aplicação é localmente executado.

- Arquitetura em Objetos Distribuídos: Cada entidade distribuível é um objeto que fornece

serviços para outros objetos e recebe serviços de outros objetos. É uma arquitetura de sistema
aberta que permite que novos recursos sejam adicionados quando necessários.
- Arquitetura Orientada a Serviços: baseada em Web Services, que é uma abordagem
padronizada para tornar um componente reusável disponível e acessível através da rede.

- Teste de software é um conjunto de atividades que pode ser planejada antecipadamente e

conduzidas sistematicamente.
- Teste de baixo nível: verifica se um pequeno segmento de código foi implementado.
- Teste de alto nível: verifica a validação das funções com base nos requisitos de sistema.

- Verificação: se refere a um conjunto de atividades que garante que o software implementa

corretamente uma função especifica.

- Validação: se refere a um conjunto de atividades que garante que o software produzido está
em conformidade com a especificação do cliente.

- Teste de unidade: verifica o esforço em menos unidade de projeto de software (artefato ou

componente).

- Teste de Integração é uma técnica sistemática para a construção da arquitetura do software,

enquanto conduz testes para a avaliação da comunicação do sistema.

- O Teste de Validação começa no final do teste de integração. Testes de unidades e de

integração já detectaram erros de interface e o software já está pronto em um pacote.
- O objetivo do teste de validação é verificar se o software está em conformidade com a
especificação dos requisitos do sistema.

- Teste do sistema: representa um conjunto de testes que visa exercitar, por completo, o
sistema. Teste de recuperação, segurança, estresse e desempenho.

- Teste caixa-branca: é uma técnica que visa realizar um conjunto de testes baseados em um
exame rigoroso do detalhe procedimental.

- Teste caixa-preta: trata, basicamente, dos requisitos funcionais do software. Os testes são
conduzidos na interface do software.

- Teste de caminho Básico: é uma técnica de teste caixa-branca que permite ao projetista gerar
casos de teste para avaliar a complexidade lógica do projeto.

- Métodos de Teste Orientado a Objetos: similares aos sistemas convencionais, porém

taticamente diferentes. O teste pode começar pela revisão dos modelos de projeto e à medida
que as classes são integradas, testes devem ser aplicados para avaliar o “novo” software.

- Teste baseado em Erro: projeto de teste cujo o objetivo é a descoberta de erros plausíveis.

- Teste com Base em Cenários: concentra-se no que o usuário faz e não naquilo que o sistema
faz.