Introdução
Software
 Programa de computador e documentação associada
 Produtos de software podem ser desenvolvidos para um cliente particular ou podem ser
desenvolvidos para um mercado geral
 Novos softwares podem ser criados desenvolvendo-se novos programas ou reusando softwares
existentes
Processo
 Uma série conectada de ações, com a intenção de satisfazer um objetivo
 Define quem está fazendo o quê, quando e como para atingir certo objetivo.
Processo de Software: Um conjunto estruturado de atividades para desenvolver um sistema de
software, que deve envolver obrigatoriamente, pelo menos as seguintes atividades:




Especificação
Projeto e implementação
Validação
Evolução
Disciplina de engenharia preocupada com todos os aspectos sobre a produção de software, incluindo:
 Processos: Racionalizam o desenvolvimento de Software
 Métodos: Conhecimentotécnico; “Como” fazer
 Ferramentas: Suporte automatizado para processos e métodos
Objetivos:




Obter software de qualidade
Com produtividade no seu desenvolvimento, operação e manutenção
Dentro de custos, prazos e níveis de qualidade controlados
Com o melhor custo-benefício entre Qualidade e Produtividade
Eng. de Software x Eng. De Sistemas
 Engenharia de Sistemas é algo maior: preocupa-se com todos os aspectos de sistemas baseados
em computador
 Software
 Hardware
 Processos
 Pessoas e outros sistemas, etc.
 Engenharia de Software é apenas parte deste processo
Questão
(TRE/BA – CESPE 2010)
[61] A engenharia de software está relacionada com todos os aspectos da produção de software, desde os
estágios iniciais de especificação do sistema até sua manutenção, depois que este entrar em operação. A
engenharia de sistemas diz respeito aos aspectos do desenvolvimento e da evolução de sistemas
complexos, nos quais o software desempenha um papel importante.
Gab. C
(IBGE – CONSULPLAN 2009)
[12] Segundo Pressman (1995), Engenharia de Software é o estabelecimento e uso de sólidos princípios
de engenharia para que se possa obter economicamente um software que seja confiável e que funcione
eficientemente em máquinas reais, abrangendo um conjunto de três elementos fundamentais (métodos,
ferramentas e procedimentos).
Assinale a alternativa INCORRETA:
A) Métodos de Engenharia de Software proporcionam os detalhes de “como fazer” para construir o
software.
B) As ferramentas proporcionam apoio automatizado ou semi-automatizado aos métodos.
C) Procedimentos constituem o elo de ligação dos métodos e das ferramentas e possibilitam o
desenvolvimento racional e oportuno de software.
D) Métodos envolvem um amplo conjunto de tarefas que incluem: planejamento e estimativa de projeto,
análise de requisitos de software e sistemas, projeto de estrutura de dados, arquitetura de programa e
algoritmo de processamento, codificação, teste e manutenção.
E) Ferramentas são roteiros para o desenvolvimento de software
Gab. E
Modelos de Ciclo de Vida
Cascata (Clássico / sequencial linear):




Recomendado para situações onde há requisitos estáveis e bem compreendidos.
É inflexível, sistemático e sequencial
É facilmente aplicável em equipes inexperientes
Atrasa a resolução dos riscos (falha tardia do projeto)
Pressman
Sommerville
Prototipagem:
 Evolucionária:
 Evolui o sistema a partir de uma especificação inicial resumida.
 Começa com os requisitos mais fáceis e bem compreendidos.
 Novas funcionalidades são adicionadas à medida que o cliente às propõe.
 Falta visibilidade do progresso (sempre evoluindo, nunca está terminado).
 Aplicável em sistemas pequenos ou médios.
 Descartável:
 Pequenas versões são disponibilizadas ao clientes para avaliação.
 Objetivo: clarificar e entender os requisitos do sistema.
 Começa com os requisitos mais difíceis e menos compreendidos.
 Descarta-se o protótipo e a implementação continua.
 Útil para sistemas grandes e complexos, quando o cliente não sabe o que quer.
 Podem ser aplicados no contexto de qualquer modelo de processo.
Métodos Formais:
- Modelo baseado em técnicas matemáticas para especificar, desenvolver e verificar software.
- O software é especificado usando técnicas formais(matemáticas), e após a “prova” da especificação é
transformado em código.
- Tem sido aplicados apenas a desenvolvimento de sistemas críticos (questões de segurança).
 Iterativos:
- Motivação: requisitos de sistema sempre evoluem durante o projeto.
- Duas abordagens:
 Incremental
 Desenvolver a entrega em incrementos, com cada um entregando parte da funcionalidade
requerida.
 Requisitos são definidos antes do desenvolvimento do incremento, sendo os mais críticos
priorizados.
 Os incrementos são avaliados e os desvios identificados, sendo possível replanejar as
próximas iterações de acordo.
 Espiral
 Cada volta na espiral representa uma fase no processo
 Nãoháfasesfixas
 Inicia de dentro para fora
 Acrescenta aspectos gerenciais ao desenvolvimento de software
 Planejamento
 Análise de riscos
OBS: O modelo espiral do ciclo de vida de software é iterativo e incremental, uma vez que a mesma
sequência de atividades relacionadas à produção de software é realizada a cada ciclo da espiral.
Falso, pois não há garantia de que a sequência de atividades será realizada em cada fase(ciclo), podendo
ocorrer até supressões de atividades.
^
PROCESSOS ÁGEIS
Valores:




Indivíduos e interações em vez de processos e ferramentas.
Software funcional em vez de documentação extensiva.
Colaboração com o cliente em vez de negociação de contrato.
Resposta à mudança em vez de seguimento de um plano.
Doze princípios do manifesto ágil:
 Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software
de valor.
 Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adéquam
a mudanças, para que o cliente possa tirar vantagens competitivas.
 Entregar software funcionando com freqüência, na escala de semanas até meses, com preferência
aos períodos mais curtos.
 Pessoas relacionadas ao negócio e os desenvolvedores devem trabalhar em conjunto e
diariamente, durante todo o curso do projeto.
 Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte
necessário, e confiar que farão seu trabalho.
 O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de
desenvolvimento, é através de uma conversa cara a cara.
 Software funcional é a medida primária de progresso.
 Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e
usuários, devem ser capazes de manter indefinidamente, passos constantes.
 Contínua atenção à excelência técnica e bom design, aumenta a agilidade.
 Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
 As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
 Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam
seu comportamento de acordo.
Vantagens:
 Entrega acelerada dos serviços ao cliente.
 Engajamento do usuário com o sistema (envolvimento).
Problemas na implantação:
 Problemas
 Problemas
 Problemas
 Problemas
Desvantagens:
de
de
de
de
gerenciamento (mudanças rápidas, documentação, tecnologias não conhecidas).
contrato (preço fixo?).
validação (TDD).
manutenção
 Envolvimento com o cliente (cadê ele?). Indisponibilidade do cliente para atuar continuamente no
projeto em conjunto com a equipe de desenvolvimento.
 Membros da equipe podem não interagir bem com outros membros da equipe.
 Priorização de mudanças pode ser bem difícil, principalmente onde existem muitos Stakeholders.
 Manter a simplicidade requer trabalho extra.
Extreme Programming(XP):
Características:
 Os programadores trabalham em pares.
 Testes são desenvolvidos antes da escrita do código
 Pequeno espaço de tempo entre as releases do sistema que apóia assim o desenvolvimento
incremental.
 Envolvimento do cliente apoiado pelo engajamento em tempo integral deste na equipe de
desenvolvimento sendo responsável pela definição de teste de aceitação do sistema.
 Dentro da tríplice restrição ele está focado no escopo. (?)
Princípios:
 Feedback rápido
 Presumirsimplicidade
 Mudançasincrementais
 Abraçarmudanças
 Trabalho de altaqualidade.
Valores:
 Comunicação.
 Simplicidade.
 Feedback.
 Coragem.
 Respeito.
Práticas:
 Utilização de metáforas: as funcionalidades do software são descritas em histórias, da forma mais
simples possível.
 Jogo de planejamento.
 Planejamento incremental: de acordo com a prioridade dos requisitos a serem implementados.
 Pequenas versões: entregas constantes de pequenos pedaços de software funcionando.
 Projeto Simples: o código na forma mais simples que atenda todos os testes.
 Testes de aceitação/Cliente on-site: cliente com conhecimento sobre o negócio deve estar
disponível em tempo integral, participando ativamente.
 Ritmo sustentável (trabalho motivado e hora extra quando trouxer vantagens).
 Posse coletiva (o código não tem dono): qualquer programador pode alterar o código.
 Programação em pares: validação mútua do trabalho realizado, 2 programadores em 1
computador.
 Desenvolvimento orientado a testes. (TDD, Test-first): testes unitários escritos antes da
funcionalidade ser implementada.
 Refatoração: melhorar o código sem alterar o comportamento externo.
 Integração contínua: os módulos são integrados imediatamente após sua conclusão.
 Padrões de codificação: estilo e formato consistentes.
 Reuniões em pé: rápidas e diárias para discutir o essencial.
Ferramentas:
 Template de Cartão de História: ator, meta, motivo.
 Plainning poker: dividir (a história) em tarefas e estimar esforços e recursos necessários.
 Priorização de histórias para implementação pelos clientes.
 TDD (Desenvolvimento dirigido por testes)
 Define interfaces e comportamentos para a funcionalidade (entrada, testes, saídas).
 Desenvolvimento incremental de teste a partir de cenários.
 Envolvimento do usuário no desenvolvimento e validação de testes.
 O uso de ferramentas de teste automatizadas: teste escrito como um componente executável
antes do código. Deve possibilitar a entrada e verificar se a saída atende.
SCRUM:
 É um processo iterativo e incremental para o desenvolvimento de produtos e gerenciamento de
projetos.
 Está mais para framework do que para uma metodologia.
 Ele não te dirá o que fazer, apenas te dará transparência para enfrentar os desafios do dia a dia,
a decisão é sua.
 Método ágil para gerenciamento de projetos baseado em times pequenos (5 a 9 pes.) e
auto-organizados.
 Apresenta forte-visibilidade e rápida adaptação a mudanças (Melhoria contínua).
Pilares:
 Transparência: os aspectos do processo que afetam o resultado devem ser visíveis para aqueles
que gerenciam os resultados.
 Inspeção: detecção de variâncias inaceitáveis no processo devem ser inspecionadas e detectadas.
 Adaptação: aspectos do processo que saírem dos trilhos devem ser ajustados.
PAPÉIS:
 Product Owner (PO):
o Faz o Macro Management
o Tem total decisão sobre o produto
o Responsável por garantir o ROI.
o Responsável por garantir as necessidades do cliente.
o Proxy de comunicação em ambientes com mais de um cliente.
o Precisa ter disponibilidade e não estar dentro do time.
 Scrum Master (SM):
o Responsável por remover os impedimentos do time.
o Garante o uso do Scrum.
o Protege o time de interferências externas.
o Não deve ser PO nem fazer parte do time.
 Time:
o Multidisciplinar.
o Auto-organizado.
o Dedicação Integral.
o Metascompartilhadas.
o É quem faz o micro-management.
FLUXO:
Product Backlog:

O Product Owner define a visão do produto.

Para tanto ele recolhe informações junto ao cliente, usuários finais, time, gerentes, stk, etc.

A visão define o que o PO espera que seja entregue como produto final do projeto e sabe-se
que ele foi finalizado quando a visão foi atendida.

Definição de Pronto.

Escopoaberto.

O PO cria uma lista inicial de necessidades (ProductBacklog) com o auxílio do Scrum Master.

O ProductBacklog contém os requisitos para o produto que a equipe está desenvolvendo.

O PO é o responsável pelo ProductBacklog: conteúdo, disponibilidade e priorização.

O ProductBacklog é um documento dinâmico. Nunca está completo.

Não existe um padrão para documentação técnica, pode ser UC, Use Stories.

Um item do backlog deverá sempre caber em uma sprint.

Quanto mais no topo do ProductBacklog,
automaticamente mais detalhada ela estará.

Quanto mais no fundo, menos prioritária será a necessidade e automaticamente menos
detalhada ela estará.

Cartão de Memória

Plainning Poker
mais
prioritária
será
a necessidade
e
Sprint Planning Meet:
 Planejamento da Iteração (tempo: 5% da Sprint)- A reunião ocorre dentro do Time Box da Sprint.
 Definição do Sprint Backlog
 Primeira metade: define-se o que vai ser realizado no Sprint.
 Segunda metade: como construir as funcionalidades do produto durante a Sprint (definição do
Pronto e Implementado). CaiuemProva !!
Sprint Backlog:
 Lista de tarefas a serem executadas durante a sprint.
 Deverá estar “definida” no final da Sprint Plannning Meeting.
 Iniciará com 70% das atividades definidas. O restante virá diariamente durante a Sprint.
 Conterá os itens de backlog selecionados, suas respectivas tarefas e as metas da Sprint.
 Relacionadas a atividades micro (até 8 h).
EX:
Sprint Burndown:
 É um gráfico do time, não do PO nem do SM.
 Tem como objetivo ajudar o time no micro-management.
 O gráfico só evolui quando o item está efetivamente pronto.
 Auxilia na mediação da velocidade da equipe por sprint.
Sprint:
 Ocorre em um período de 30 dias aproximadamente
 O tempo de duração inclui o planejamento e a revisão.
 O SM facilita o trabalho do time removendo os impedimentos encontrados e garantindo a boa
aplicação do Scrum.
 O time pode consultar especialistas ou o PO.
Daily Meeting/Scrums (Reunião Diária):
 Duração de 15 minutos (O que fiz? O que fazer ? Qual impedimento ?)
 Visibilidade da situação atual dentro do planejamento.
 SM comofacilitador.
 Micro- Management. Reunião para o time.
 Inclusão/exclusão de tarefas para cumprir a meta da Sprint.
 Inserção de impedimentos (relacionados às tarefas já previstas)
Sprint Review (Reunião de Revisão da Sprint)
 Realizada ao final do Sprint (4h p/ sprints de 1 mês)
 Identifica o que foi feito, problemas encontrados e soluções.
 O time demonstra o que foi feito e responde a questionamentos.
 O PO discute o ProductBacklog atual.
 Todos discutem melhorias que poderão ser implementadas (melhoria do produto).
Retrospectiva:
 Foco na inspeção-adaptação (duração: 3h).
 O time é encorajado a revisar o processo de trabalho (melhoria do processo).
 Finalidade: inspecionar o último sprint (aspectos: pessoas, relacionamentos, processos e
ferramentas).
 Identificação de melhorias para as próximas sprints.
Stories, Temas e Epics:
 Epics são grandes user stories, que ainda estão em formato bruto.
 Temas são pacotes de user stories (decompostos ou não) relacionadas por algum grande objetivo
de negócio. (= package de um caso de uso)
 Uma release pode ter 1 ou mais temas.
 No planning poker passou de 40 é um Epic.
Sprints x Release:
 Sprint: entrega um incremento do produto.
 Release: entrega de um “produto” que entrará em produção.
P.S: Uma release pode conter várias sprints.
Mudanças Durante a Sprint:
 As mudanças ocorrem desde que não atrapalhem a meta das Sprint.
 Time-box é fixo. Mudanças não impactam o timer da sprint.
Feature Driven Development (FDD):
Características:
 Focada na entrega regular de funcionalidades valiosas para o cliente.
 Que possam ser entregues em até 2 semanas.
 Equipes podem variar de 10 a 250 programadores.
 Nãonecessita de tantadocumentação
Papéis: Existem papéis chave e papéis de apoio, abaixo seguem os papéis chave:
 Project Manager
 Líderadministrativo do projeto
 Planeja orçamento, elabora relatórios e protege a equipe de distrações externas.
 Chief Architect
 Responsável pelo projeto geral do sistema
 Tem a palavra técnica final sobre o software e sua arquitetura
 Development Manager
 Lidera as atividades diárias de desenvolvimento
 Lidera a equipe de desenvolvimento através de desafios técnicos
 Chief Programmers
 Desenvolvedoresexperientes
 Lideram pequenas equipes de desenvolvedores individuais
 Class Owners
 São os desenvolvedores individuais
 Projetam, codificam, testam e documentam as funcionalidades
 Domain Experts
 Usuários, clientes, patrocinadores...
 A base de conhecimento para os desenvolvedores
Processos:
 Desenvolver um modelo abrangente (geral)
 Construirumalista de funcionalidades
 Planejarporfuncionalidade
 Projetar (detalhar) porfuncionalidade
 Implementarporfuncionalidade
Benefícios:
 Qualidade de software
 Maiorprodutividade
 Maiorprevisibilidade
 Maior controle sobre custos e prazos
Ferramentas CASE
- São ferramentas que auxiliam o engenheiro de swnas atividades associadas ao desenvolvimento de sw.
- Utilizada por Gerentes de projeto e engenheiros de sw.
- Reduzem o esforço necessário para produzir artefatos e alcançar metas
- Aumentam a qualidade do sw.
-Ferramentas CASE são usadas em conjunto com o modelo de processo adotado. Se for escolhida uma
ferramenta completa, pode passar por quase todos os passos do desenvolvimento de SW.
- São usadas como complemento às boas práticas de Engenharia de Software. Ferramentas CASE não
substituem uma metodologia de desenvolvimento de software sólida.
Categorização:
Terminologia I:
 Horizontais: são utilizados durante todo o processo de des. de soft.
 Verticais: são específicas para uma disciplina de soft.
 Por funções: processos de negócio, análise de risco...
Terminologia II:
 Front-end ou Upper CASE: apoiam etapas iniciais da criação dos sistemas; planejamento, análise
e projeto de aplicação.
 Back-end ou Lower CASE: dão apoio à parte física, código, testes e manutenção.
 I-CASE ou Integrated CASE: cobrem todo o ciclo de vida do início ao fim.
RUP
Características:
 Iterativo e Incremental: O ciclo de vida do produto é dividido em iterações, cada uma entregando
incrementos/releases (partes acabadas) do software.
 Guiado por casos de uso: Os casos de uso conectam todas as fases e visões, sendo utilizados por
todos os stakeholders.
 Centrado na arquitetura: Evolui a partir das necessidades do produto.
 Orientado a objetos: Componentes são construídos através de Objetos e estes colaboram entre si
para realizar os casos de uso.
 Planejado por riscos: Os riscos são analisados continuamente e os de maior criticidade são
tratados prioritariamente.
- O RUP tem duas dimensões:
 A primeira dimensão representa o aspecto dinâmico do processo (Eixo horizontal)
 Expresso em termos de fases, marcos e iterações
 A segunda dimensão representa o aspecto estático do processo (Eixo vertical)
 Expresso em termos de componentes, disciplinas, atividades, artefatos, papéis
Perspectivas:
 Dinâmica: são as fases do modelo.
o Concepção: estabelecer um business case para o sistema (escopo).
o Elaboração: domínio do problema, identificar os riscos do projeto, elaborar um plano de
projeto.
o Construção: projeto, programação e teste de sistema.
o Transição: implantação. Fase onerosa e problemática.
 Estática: são as disciplnas, fluxos ou workflows.
PRINCIPAIS (realizadas no projeto)






Modelagem de negócios
Requisitos
Análise e projeto
Implementação
Teste
Implantação
AUXILIARES (acompanham o projeto)
 Gerenciamento de configuração e mudança
 Gerenciamento de Projeto
 Ambiente
Disciplinas (MRAITIGGA)
 São um conjunto de atividades (fluxo de trabalho) relacionadas a uma “área de interesse” do
projeto
 Ajudam a compreender o projeto a partir de uma perspectiva em cascata
OBS: teste unitário está incluso na disciplina de implementação.
Obs: Cada passagem pela sequência de disciplinas do projeto se chama iteração, não passando
obrigatoriamente por todas.
Critérios de Avaliação dos Marcos:
 Objetivos do ciclo de vida:




Casos de uso definem claramente o escopo?
Foi possível fazer um protótipo da arquitetura?
Todos os riscos críticos foram encontrados? Forammitigados?
Há condições de realizar o projeto?
 Arquitetura do ciclo de vida: Baseline
 A arquitetura é estável e robusta, comportando requisitos atuais e futuros?
 Riscoscríticosforamresolvidos?
 Cronograma, orçamento e níveis de qualidade estão bem definidos?
 Devemosfechar o contrato?
 Capacidade operacionalinicial:
 O produto está estável para ser implantado?
 O resultado está coerente com o planejado?
 Os envolvidos estão prontos para a Transição?
 Release do produto:
 As despesas reais com recursos são aceitáveis se comparadas às planejadas?
 O usuárioestásatisfeito?
- Papéis executam Atividades que geram Artefatos.
Práticas: boas práticas durante o processo.
 Desenvolver o software iterativamente.
 As táticas e os requisitos variáveis são acomodados
 Os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente.
 A melhoria e o refinamento do produto são facilitados, tornando-o mais robusto.
 As organizações podem aprender a partir dessa abordagem e melhorar seus processos.
 Identificar partes comuns quando estão parcialmente projetadas ou implementadas é mais
fácil que identificar todas as semelhanças no começo.
 Gerenciar Requisitos (documentação e mudanças).
 Requisitossãoalterados.
 Entenda as necessidades das partes interessadas.
 Defina o sistema e seu escopo.
 Garanta que os requisitos sejam facilmente atualizáveis.
 Casos de uso guiam o desenvolvimento
 Arquiteturabaseadaemcomponentes.
 Grupos coesos de código fonte ou executável com interfaces e comportamentos bem
definidos.(substituíveis)
 Permitereusoemgrandeescala
 Visões Arquiteturais(4+1):
 De casos de uso (externa)
 Queabrangemcomportamentossignificativos
 Visão obrigatória do documento de arq. de soft.
 Lógica (interna)
 Classes de projetos mais importantes e sua organização
 Visãoobrigatória
 De processos
 Descreve as tarefas envolvidas e suas interações
 Só precisa ser utilizada quando em alto grau de paralelismo
 Visãoopcional
 De implementação
 Detalhes(físicos) dos pacotes e módulos da visão lógica
 Visãoopcional
 De implantação
 Descrição dos vários nós físicos do sistema e suas tarefas.
 Visãoopcional
 Modelar Visualmente(UML).
 Notação gráfica e visual para capturar o projeto de software
 Capturarrequisitos com precisão
 Melhorcomunicação, diminuindo a ambiguidade
 Verificar a qualidade do software.
 Foco nos processos e como eles são executados (garantia)
 Foco no produto, em encontrar defeitos específicos (controle)
 Controlar as mudanças (SGM).
 Apenasmudançasaprovadassãoimplementadas
 Coordenação de atividades e artefatos
 Coordenação de iterações e releases
 Controle de mudanças no software
OBS: No RUP a qualidade representa “a característica de
ter demonstrado a realização da criação de um produto que
atende ou excede os requisitos acordados, conforme
avaliado por medidas e critérios acordados, e que é criado
em um processo acordado”
FASES do RUP
INICIAÇÃO(Concepção):
 Compensa/é possível realizar o projeto?
 Meta principal: atingir o consenso sobre os objetivos do ciclo de vida do projeto.
 Escopo
 Custos
 Tempo (cronograma)
 Riscos
 Identificarcasos de usocríticos
 Propor pelo menos uma opção de arquitetura para cenários básicos.
Ênfases:
Modelagem de Negócios:
 Entender a estrutura e a dinâmica da organização-alvo
 Analista de Processo de Negócios:
 Identificaosprocessosnaorganização
 Descreveosprocessos
 Definir o que pode e deve ser melhorado
 Artefatos:
 Modelo de Domínio: captura os tipos mais importantes de objetos de negócio.
 Modelos de negócio subsidiam os requisitos de sistema
 Entidades de negócio identificam classes de entidade
Requisitos:
 Estabelecer o que o sistema deve fazer
 Definir o escopo do sistema
 Analista de Requisitos
 Levantarrequisitos do sistema
 Estruturar modelo de Casos de Uso
 Especificador de Requisitos
 Detalhar especificação de Casos de Uso
 Artefatos:
 Visão
o Documento da visão em alto nível do produto a ser desenvolvido.
o Contém as necessidades e características mais importantes.
 Glossário
o Modelo de Casos de Uso: serve como contrato entre cliente e desenvolvedores.
ELABORAÇÃO:
Fornecer uma base estável para o esforço de Construção
Arquitetura é desenvolvida a partir dos requisitos que tem maior impacto na arquitetura.
Tratar todos os riscos significativos do ponto de vista da arquitetura do projeto.
Selecionar componentes(reuso) e criar planos de iterações detalhados para a fase de construção.
Artefatos:
 Protótipos: reduzir o risco e elicitar requisitos significativos
 Doc. de Arquit. de Soft.: visão geral, usando diversas visões para descrever diferentes
aspectos do sistema.
 Modelo de projeto: descreve a realização dos casos de uso críticos.
 Modelo de dados: descreve a representação física e lógica dos dados persistentes no
sistema.
Ênfases:





Análise e Design/projeto:
 Transformar os requisitos em projeto a ser criado
 Desenvolver uma arquitetura refinada (estabilizada)
 Adaptar o projeto às restrições de tecnologia
 Arquiteto de Software
 Projetararquitetura, visãoampla.
 Designer(projetista)
 Analisar e projetar casos de uso
 Projetarsubsistemas
 Projetista de Banco de Dados
 Projetar base de dados
 Implementa as funcionalidadescríticas
OBS: Segundo o manual RUP, as atividades de Análise são opcionais. Apesar de na prática não ser
muito interessante pular essas atividades.
CONSTRUÇÃO:
Esclarecerosrequisitosrestantes
Concluir o desenvolvimento com base na arquitetura estável
Gerenciamento de recursos e controle de operações para maior produtividade e qualidade.
Otimizarrecursos e evitarretrabalho
Definir se o software está pronto para ser implantado
Artefatos:
 Sistema: pronto para iniciar os testes Beta.
 Plano de Implantação: versão inicial desenvolvida, analisada e com baseline.
 Conjunto de testes: testes implementados e executados para validar a estabilidade dos
releases.
 Modelo de projetocompleto
OBS: testes Alfa são executados na fase de construção, já os testes Beta são realizados na fase de
transição.






Ênfases:
Implementação:
 Definir o código em subsistemas e camadas
 Implementar classes e objetos em termos de componentes
 Realizar testes unitários
 Integra os componentes individuais ao sistema executável.
 Implementador (II e III)
 Integrador (IV)
 Implementa o que foi definido na disciplina de Análise e Design
Teste:
 Localizar e documentar defeitos na qualidade do software
 Validar as funções do software conforme projetadas
 Verificar se os requisitos foram implementados de forma adequada
 Analista de teste: elaborar plano de testes.
 Projetista de teste: projetar testes (a partir dos casos de uso).
 Testador: implementar e executar testes.
Plano de testes:
 Define metas e objetivos dos testes no escopo da iteração (ou projeto)
 Explicita a abordagem adotada, os recursos necessários e os produtos liberados.
Caso de teste:
 Descrição do objetivo e do escopo do teste
 É desenvolvido caso de teste para cada cenário do caso de uso, prevendo caminhos para o fluxo
básico, alternativo e de exceção.
 Define:
o Entradas de teste
o Condições de execução
o Resultadosesperados
OBS: testes unitários são executados na disciplina de implementação, e não na disciplina de teste.
TRANSIÇÃO:
 Disponibilizar o software aos usuários finais
 Testar os releases e ajustar pequenos defeitos com base no feedback do usuário
 Feedback prioriza apenas ajustes finos, todos os problemas estruturais já devem ter sido
trabalhados anteriormente.
 Teste Beta para validar o novo sistema
 Treinamento de usuários e equipe de manutenção
 Artefatos:
 Notas de Release
 Artefatos de instalação
 Material de treinamento
Ênfase:
Implantação:
 Coordenar e gerenciar os testes Beta e de aceitação
 Desenvolver artefatos de instalação e materiais de treinamento
 Liberar para fabricação
 Tipos de Instalação:
 Personalizada/customizada
 Compacta (cd, dvd)
 Internet
 Gerente de implantação
 Desenvolverplano de implantação
 Escrevernotas de releases
 Desenvolvedor do curso
 Desenvolvermateriais de treinamento
 Implementador
 Desenvolverartefatos de instalação
Disciplinas Auxiliares
Gerenciamento de configuração e mudança:
Controla as mudanças feitas nos artefatos de um projeto e mantém a integridade entre eles
Identificar e controlar itens de configuração
Restringir as mudanças nesses itens e auditá-las
Trilha de auditoria indicando a razão, por quem e quando um artefato foi alterado
Gerente de Configuração
 Configurar ambiente de CM
 Estabelecer políticas de CM
 Garantir a integridade dos artefatos
 Gerente de Mudanças
 Estabelecer processo de controle de mudanças
 Confirmar ou recusar solicitações de mudança
 Artefatos:
 Repositório do projeto
 Solicitações de mudanças
Gerenciamento de Projeto:





Gerenciar pessoas, equipes, fases e iterações.
Planejar o cronograma do projeto
Gerenciar a qualidade e realizar revisões
Gerenciar os riscos
Artefatos:
 Plano de desenvolvimento de software
 Planos de iteração
 Lista de riscos
Ambiente:





Oferecer o ambiente de que dará suporte à equipe de desenvolvimento.
Configurar/ajustar o processo para o projeto
Selecionar e adquirir as ferramentas que serão utilizadas
Desenvolver/adaptar guias de atividades
Engenheiro de processo
 Configurar o processo
 Iniciar caso de desenvolvimento
 Especialista em ferramentas
 Selecionar, adquirir e configurar ferramentas
 Artefato:Caso de desenvolvimento
 Descreve o processo escolhido para ser seguido no projeto
 É o documento que configura o próprio processo de desenvolvimento





Requisitos de Software
Requisitos: definem o que o sistema deve fazer e sob quais limitações ele é requisitado a operar.
- O sucesso das etapas posteriores depende da qualidade dos requisitos gerados.
Tipos de Requisitos:
No desenvolvimento
 Funcionais: definem as funcionalidades do sistema, é o que ele deve fazer. Depende dos usuários
e do contexto de utilização.
 Não
Funcionais:
são
qualidades,
atributos,
restrições,
características
do
sistema.Possuemrelação com as funcionalidades do sistema.
 Do produto: eficiência, confiabilidade, usabilidade, portabilidade.
 Organizacionais: obedecem a políticas, padrões, processos.
 Externos: legislação, interoperabilidade, privacidade
 De domínio: refletem características do domínio, são transformados posteriormente em
funcionais ou não funcionais.
 São expressos na linguagem do domínio da aplicação.
 Conhecimentotácito
Na evolução e manutenção






OBS:
Permanentes: relativamente estáveis, pois são derivados da atividade principal da organização.
Voláteis:
Mutáveis: são modificados por conta do ambiente do sistema.
Emergentes: surgem durante o desenvolvimento à medida que o cliente compreende o sistema.
Consequentes: resultam da introdução do sistema no ambiente do usuário.
Compatibilidade: que dependem de outro processo, mudam conforme o outro muda.
Requisitos não funcionais devem ser verificáveis(mensuráveis) de forma objetivamente testada.
Elicitação e Análise de Requisitos:
 Entendimento do domínio da aplicação
 Descoberta/levantamento dos requisitos
OBS: JAD- Técnica de elicitação de requisitos.(IBM) - ler sobre
Técnicas de Elicitação:
Entrevistas
Questionários
Leituras de documentos
Observações e análises sociais (etnografia):
 Fatores organizacionais importantes podem ser observados
 Analisar como as pessoastrabalham
 Requisitos são derivados da cooperação e compreensão das atividades.
 Workshops de requisitos
 Stakeholders são reunidos por um período intensivo
 Reunir informações para atributos de requisitos aplicáveis
 Resumir a sessão e elaborar conclusões
 Prototipagem
 Cenários (casos de uso)
 Utilizados para mostrar quais funcionalidades o sistema oferece e que usuários se
comunicam com ele.
 Atores são sempre entidades externas ao ambiente do sistema.
 Tipos:
. Concreto: iniciado por um ator, constitui um fluxo completo de eventos.
. Abstrato: nunca são instanciados diretamente, são includes, extends ou
generalizações de um caso de uso concreto. São escritosemItálico.




Relacionamentos:
 Include: após um caso de uso “base” a inclusão de outro caso de uso é obrigatória.
 Extend: modela partes opcionais da execução de um caso de uso.
 Generalização: relaciona um caso de uso especializado a um mais geral.
 Modelo de Caso de Uso: comunica o comportamento do sistema ao usuário final.
Análise de Requisitos:
 Agrupar requisitos relacionados e organizá-los em conjuntos coerentes
 Checagem de consistência, ambigüidade, omissão e relacionamentos entre requisitos.
 Priorizar requisitos e negociar conflitos
 É papel do analista de requisitos balancear todas as demandas
 Requer grande capacidade de integração social
Especificação de Requisitos:
 A abordagem utilizada depende da necessidade específica de cada projeto
 Podeabordar:
 Documento escrito
 Modelo gráfico
 Modelo matemático formal
 Coleção de cenários de uso
 Especificação do Sistema:
 É o produto final produzido pelo engenheiro de requisitos
 Descreve a função do sistema e suas restrições
 Descreve informações que entram e saem do sistema
Validação de Requisitos:
Objetivos: Assegurar que...
 Os requisitos definem o sistema que o usuário realmente deseja
 Requisitos são consistentes e de alta qualidade
 Documento de requisitos provê uma base adequada para Projeto e Implementação
 Aprovar o Documento de Requisitos
Técnicas:
 Revisões(inspeções)
 Prototipagem
 Geração de Casos de teste
Gerenciamento de Requisitos:
 A preocupação é manter os requisitos e controlar suas evoluções.
 Gerencia as mudanças nos requisitos. Requisitos sempre mudam!
 Rastreabilidade: relacionam os requisitos e avaliam seus impactos
 De fonte: liga o requisito a quem propôs, e sua necessidade original.
 De Requisitos: liga os requisitos que dependem entre si.
 De projeto: ligação entre o requisito e o projeto do software.
 É impossível rastrear requisitos sem uma ferramenta CASE adequada.
Análise e Projeto OO
Análise OO:
 Gerar um primeiro modelo do sistema a partir dos casos de uso (Modelo de Análise/Domínio)
 Entender o problema a ser tratado antes de partir para a solução. Estruturando por classes e
objetos.
 Escrita na linguagem dos desenvolvedores.
 Encontrar os objetos que vão compor o software, suas funções, dados e relacionamentos.
 Não depende de tecnologia
 Segundo o RUP, é atividade opcional.
Modelo de Análise/Domínio:
 Modelo de objetos que descreve a realização dos casos de uso, é uma abstração do Modelo de
Design.
 Contém as classes e qualquer artefato associado.
 O modelo evolui durante as iterações do projeto, incrementando detalhes às classes.
 Desenhar diagramas de classes conceituais
 Identificar persistência
 Classes de Fronteira: fazem a interação Ator x Sistema. Apresentam dados aosusuários.
 Classes de Controle: controlam a lógica de execução correspondente a cada caso de uso.
 Classes de Entidade: representam a informação que é manipulada pelo caso de uso.
Armazenam informações persistentes. Contém as regras de negócio.
 Identificar responsabilidades: qual operação é fornecida por cada classe.
 Identificar atributos: sem identificar o tipo.
 Identificar relacionamentos: associações, dependências.
Projeto OO:
 Criamos o Modelo de Projeto, no qual definimos como o software atenderá os requisitos
analisados.
 Dependente da tecnologia a ser utilizada na implementação.
 Unificar os modelos de caso de uso em um modelo único, mais detalhado.
 Projetar detalhadamente a estrutura e o comportamento interno de cada subsistema (módulo).
 Projetar a arquitetura, em camadas.
Tipos de Herança:
Simples: novas classes são criadas a partir de uma classe existente.
Múltipla: uma classe pode herdar de várias outras classes.
 Deve ser evitada. Pois pode causar vários problemas:
 Difícil de entender
 Codificaçãoconfusa
 Ambiguidade e duplicação de atributos
 Algumas linguagens(Java e Smalltalk) não suportam herança múltipla
Tipos de generalização:
 Incompleta: outros subtipos(objetos) podem ser
adicionados no futuro
 Completa: todas as subclasses já foram especificadas.
 Disjunta(disjoint): não pode ocorrer herança múltipla
 Sobreposta(Overlapping): pode ocorrer herança
múltipla
Classe Abstrata:




Representa um conceito abstrato e é utilizada para organizar uma hierarquia de generalização
Não é projetada para gerar instâncias. O nome estará sempre em Itálico
A “superclasse” será herdada por outras, e estas é que gerarão instâncias concretas.
Caso exista um método abstrato, a classe precisará ser abstrata, mas o contrário não pode se
afirmado. Se a classe é abstrata, não obrigatoriamente eu preciso ter um método abstrato.
Interface:
 Define um conjunto de comportamentos(operações) oferecidos para uma classe ou componente.
 Pode ser interpretada como um contrato de comportamento entre um objeto cliente e o fornecedor
de serviços.
 É dito que classes realizam interfaces.
Arquitetura do Sistema: é a estrutura dos componentes significativos do sistema que interagem por
meio de interfaces.
Composição:



OBS:
Componentes de software
Propriedades visíveis externamente
Relacionamento entre componentes
Uma boa arquitetura deve ter componentes projetados com baixo acoplamento e alta coesão.
Acoplamento:
 Grau de dependência de um módulo em relação aos demais.
 Acoplamento forte significa que uma classe precisa conhecer detalhes internos das outras.
 Quanto menos acoplamento melhor. Menor complexidade.
Coesão: é o grau de entendimento das responsabilidades de um determinado módulo/classe.
Queremos classes:
 Com menor complexidade possível
 Com responsabilidades claramente definidas
 Que não executam um grande volume de trabalho
Arquitetura em Camadas:
 Cada camada provê um conjunto de funcionalidades em determinado nível de abstração
 Camadas de mais alta abstração dependem das de mais baixa abstração
Vantagens:
 Separação de responsabilidades
 Decomposição de complexidade
 Maiorreuso e extensibilidade
Desvantagens:
 Pode penalizar o desempenho do sistema
 Aumento do esforço e complexidade de desenvolvimento
Padrões:
Arquitetura em 3 camadas(clássica):
 Camada de apresentação: entrada e saída de dados
 Camada da lógica do negócio: processa comandos, faz avaliações e implementa regras de
negócio.
 Camada de acesso a dados: contém o código responsável por armazenar e recuperar dados de
uma base de dados.
 Normalmente há uma interface(sub-camada) dentro dessa camada, o DAO (Data Acess Objetct),
que abstrai o mecanismo de persistência, facilitando a integração de múltiplas fontes de dados.
Model-View-Controller (MVC):
View (Visão):
 É a camada de interface com o usuário.
 Entrada e saída de dados, apresenta os resultados.
 Pode requerer dados diretamente da camada Modelo
Controle:
 Atualiza o modelo
 Seleciona a visão
 Controla e mapeia as ações do usuário
Modelo:
 Modela os dados e o comportamento por trás das regras de negócio
 Armazena, manipula e gera os dados
Observações:




Nem toda comunicação passa pelo controlador
A visão despacha atualizações para o controlador
O controlador atualiza o modelo
A visão é atualizada diretamente pelo Modelo
Arquitetura MVC na WEB(Model 2)
Prova: A camada Controller geralmente possui um componente controlador padrão criado para atender
a todas as requisições do cliente.
Arquitetura WEB:





Browser utilizadocomocliente universal
Camadas de 3 a N
Em projetos simples podemos ter as camadas WEB e Aplicação no mesmo local.
Quanto mais camadas, maior a flexibilidade.
A lógica de negócio fica no servidor de aplicação.
N Camadas
Testes e Qualidade de Software
Tipos de Manutenção:




Corretiva: posterior ao encontro dos erros na verificação/validação.
Adaptativa: para adaptar-se a mudanças externas.
Melhoria (Perfectiva): para atender a requisições posteriores.
Preventiva (reengenharia): abordagem pró-ativa, foco na melhoria contínua.
Falta: Causa de uma falha, é o defeito / causa raiz.
Erro: instabilidade causada ao tentar processar determinada informação, estado intermediário.
Falha: incapacidade do software de realizar a função requisitada, fato observável.
Prevenção de Faltas:
 Especificaçãorigorosa
 Proteção de hardware
 Ambientes e linguagensapropriados
Tolerância a Falhas:
 Replicação/Redundância
 Isolamento do componentefaltoso
 Hot swapping
Verificação:
 Garantir que o software implementa as funções especificadas. Corretaconstrução do produto.
 Verificações estáticas (inspeções)
 Verificações dinâmicas (testes). Foco mais interno.
Inspeção de Software:









Análise estática dos artefatos do sistema
Checa a conformidade com as funções especificadas
Não checa requisitos não funcionais (desempenho, usabilidade)
Podem ser aplicadas a qualquer artefato do sistema
Podem ser aplicadas antes da implementação, pois não precisam da execução do sistema.
Erros são apenas detectados e nunca corrigidos durante a inspeção
Podem ser manuais e com auxílio de ferramentas CASE
Padrões organizacionais devem ser bem definidos
As equipes devem ser bem informadas e ter acesso a especificações precisas
OBS: Walkthroughs são inspeções informais, rápidas que podem ocorrer a qualquer momento no
desenvolvimento, exigindo uma menor formalidade.
Validação:
 Garantir que o software atende às reais necessidades do cliente. Construção do produtocerto.
 Homologação
 Testes de aceitação (Beta). Foco mais externo, no cliente.
Testes:





O objetivo é encontrar erros. Ocorre sucesso quando encontra um erro não conhecido.
Não garante que está livre de erros, apenas mostra os erros presentes.
Devem ser planejados muito antes da execução, com base nos casos de uso.
Aplica-se o princípio de Pareto, pois testes exaustivos são impossíveis.
Preferencialmente conduzidos por terceiros.
Abordagens:
Caixa preta(funcional): foca nas entradas e saídas especificadas. Técnicas:
 Grafos:
 Toda aplicação é constituída por objetos
 Todos eles são identificados e representados em um grafo.
 Os relacionamentos definidos são utilizados para descobrir comportamentos inesperados.
 Particionamento de equivalências:
 As entradas utilizadas são organizadas em “classes de dados”, válidas e inválidas.
 Casos de teste são gerados através dessas classes.
 Análise de valoreslimítrofes:
 Os testes devem ser gerados com valores limítrofes, pois é sabido que a maioria dos erros
ocorre nos limites do domínio.
 Utilizada em conjunto com o partic. de equiv.
 MatrizOrtogonal:???
Caixa Branca(estrutural): foca nas estruturas internas dos procedimentos do sistema.
 Testes são gerados a partir de uma análise dos caminhos lógicos possíveis de serem executados.
 Objetivos:
 Garantir que todos os caminhos sejam executados pelo menos uma vez.
 Realizar as decisões lógicas para valores falsos e verdadeiros
 Executar laços dentro dos valores limites
 Avaliar as estruturas de dados internas
 Técnicas:
 Testes de caminhos
 Testes de estruturas de controle (if, while...)
 Complexidade ciclomática: nos dá uma idéia do limite superior de caminhos necessários.
Caixa cinza(mista): são testes que utilizam algum conhecimento sobre a estrutura interna.
Estágios(estratégias):
Teste de Unidade(unitáro):
 Os componentes individuais são testados para assegurar sua operação individualmente.
 Componentes precisam possuir a estrutura interna bem conhecida
 Ferramenta mais utilizada: JUnit (Java) Pesquisar depois de ver Java
Teste de Integração:
 Sistemas devem ser integrados gradualmente(boa prática)
 Top-down: desenvolve o esqueleto do sistema e o preenche com os componentes
 Bottom-up: integra os componentes de infraestrutura e depois adiciona componentes
funcionais.
Exemplos:
 Teste de Regressão:
 Execução de baterias de testes já executadas antes, toda vez que um módulo é adicionado
ao sistema.
 Garantir que os módulos anteriores não “quebraram” com a inserção do novo.
 Teste de Fumaça(smoketest):
 Aplicado após cada montagem do produto(build) para verificar funcionalidades básicas.
 Normalmente é o primeiro teste realizado depois de integrar os componentes.
Testes de Aceitação(validação):
 São realizados após os testes de integração
 Finalidade de demonstrar a conformidade com os requisitos de software
 Ambiente deve ser o mais próximo possível do ambiente real.
Teste Alfa:
 Testes conduzidos pelo cliente, nas instalações do desenvolvedor(ambiente controlado)
 Desenvolvedor toma nota dos erros e problemas que ocorrem
Teste Beta:
 Conduzido pelo usuário final, ocorre no ambiente real/de produção.
 O usuário anota os problemas e reporta ao desenvolvedor
Teste de Sistema:
. Conduzidos em um ambiente completo e integrado, por várias pessoas.
. Considera hardware, pessoas, processos, informações e outros sistemas.
Exemplos:
 Teste


 Teste





Qual
de Recuperação:
Força o software a falhar de várias formas e verifica a adequada recuperação.
Recuperação pode ser automática ou manual.
de Segurança:
Tentativas de penetrar no sistema, até penetrar.
O papel do desenvolvedor é assegurar que isto custe mais caro que os ganhos com a
invasão bem sucedida.
Teste de Carga(estresse):
 Visam confrontar programas com situações anormais, de caráter destrutivo, para saber até
onde ele aguenta.
 Pode estressar memória, disco, processamento etc.
Teste de Desempenho:
 Visa garantir que o sistema atenda os níveis de desempenho e tempo acordados.
 Pode ocorrer durante todos os estágios de testes.
Teste de Usabilidade:
 Avalia a facilidade de uso pelo usuário.
a diferença de teste beta x teste de sistema ?
OBS: Verificação e validação podem utilizar as mesmas técnicas, o que muda é apenas o foco, se para
checar problemas com especificações ou se é para checar o atendimento ao propósito do cliente.
Debugging
- É o processo que resulta na remoção de um erro encontrado.
- Envolve formular hipóteses sobre o comportamento do sistema e testar essa hipótese para achar os
erros.
Tipos:
 Força Bruta:espalha no sistema escritas de identificação, mapeando a execução do sistema
 Backtracking: rastreia-se manualmente a partir de onde o erro ocorreu até sua fonte.
 Eliminação de causa: elabora-se uma hipótese de causa, e os dados do erro são utilizados para
provar a hipótese.
Questões
- A metodologia de prototipagem evolutiva é uma abordagem que visualiza o desenvolvimento de
concepções do sistema conforme o andamento do projeto, por meio de protótipos visuais.
- No modelo de desenvolvimento prototipagem, um protótipo é desenvolvido para ajudar no
entendimento dos requisitos do sistema. (descartável)
- O modelo de desenvolvimento em espiral permite repensar o planejamento diversas vezes durante o
desenrolar do projeto.
- O modelo iterativo e o modelo em espiral possuem características semelhantes: ambos permitem que as
atividades do processo sejam planejadas e avaliadas ao longo do ciclo de vida.
- Uma vantagem do ciclo de desenvolvimento iterativo em relação ao ciclo clássico está na receptividade
às mudanças inerentes ao desenvolvimento de software.
- O Scrum é utilizado, como função primária, para o gerenciamento de projetos de desenvolvimento de
software, mas também tem sido usado como extreme programming e outras metodologias de
desenvolvimento. Teoricamente, o Scrum pode ser aplicado em qualquer contexto no qual um grupo de
pessoas necessite trabalhar juntas para atingir um objetivo comum.
- Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não
podem ser resolvidos com sucesso utilizando-se uma abordagem tradicional de controle. O Scrum adota
uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido,
focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.
- A metodologia Scrum é facilitada por um scrum master, que atua como um mediador entre a equipe e
qualquer influência desestabilizadora, além de assegurar que a equipe esteja utilizando corretamente as
práticas de Scrum, motivando e mantendo o foco na meta da sprint.
- Na engenharia de software, um processo iterativo denominado sprint, que segue o ciclo PDCA para
entregar, num período de 30 dias aproximadamente, um incremento do software pronto, caracteriza a
metodologia ágil Scrum.
- O RUP foi projetado em conjunto com a UML e os processos de negócios são modelados usando casos de
uso que, posteriormente, serão desenvolvidos para modelar os requisitos de sistema.
- O processo unificado de software é centrado na arquitetura e orientado por casos de uso, o que sugere
um fluxo de processo iterativo e incremental.
- As atividades fundamentais relacionadas ao processo de construção de um software incluem a
especificação, o desenvolvimento, a validação e a evolução do software.
- Ao contrário do modelo em cascata, no qual as fases coincidem com as atividades do processo, o RUP
compreende as fases de concepção, elaboração, construção e transição.
- O Processo Unificado é iterativo e incremental. Ao final de cada iteração, a qual é um miniprojeto, os
modelos que representam o sistema encontram-se em um determinado estado, denominado baseline. As
atividades de cada fase de um ciclo de vida podem ser distribuídas entre várias iterações.
- No Processo Unificado, atividades são organizadas em fluxos de atividades. Algumas atividades
produzem artefatos, que podem ser de engenharia ou gerenciais. Entre os artefatos criados, há modelos
que visam especificar o sistema a partir de certos pontos de vista e níveis de abstração.
- Uma das principais características do RUP é o uso da iteração, que, por meio de refinamentos
sucessivos, melhora o entendimento do problema.
- No modelo RUP, a primeira linha de base da arquitetura de um software é produzida ao final da fase de
elaboração.
- Na fase de construção, muitos componentes do sistema são implementados, testados e integrados.
Essas atividades, que partem de uma arquitetura definida, validada e implementada em fases anteriores
do ciclo de desenvolvimento, produzem um sistema operacional pronto para ser instalado em um
ambiente em que serão feitos testes beta.
- A manipulação dos riscos está relacionada, na fase de elaboração, a questões técnicas, envolvendo a
arquitetura escolhida.
- A fase de elaboração tem os seguintes objetivos: detalhar casos de uso e requisitos do software; refinar
a arquitetura proposta e demonstrar que essa arquitetura suporta os requisitos do sistema; testar e
avaliar protótipos visando demonstrar que os principais riscos foram avaliados; e construir protótipos
executáveis para a avaliação da arquitetura proposta.
- No RUP, o planejamento de projeto ocorre em dois níveis: planos de fase, que descrevem todo o
projeto; e planos de iteração, que descrevem os passos iterativos.
- Elaboração, no contexto do RUP, é uma fase que visa criar a baseline para a arquitetura do sistema a ser
desenvolvido e, no contexto de engenharia de requisitos, a elaboração consiste em atividade cujo
objetivo é o desenvolvimento de um modelo técnico refinado das funções, características e restrições do
sistema.
- A área de atividade de requisitos de software apresenta maior interface com a engenharia de sistemas
quando comparada à área de análise e projeto de software.
- Requisitos descrevem um acordo ou contrato entre duas partes, especificando, entre outros aspectos, o
que o sistema de software deve fazer para ser aprovado em um teste de aceitação.
- Requisitos funcionais declaram as funções que o sistema deve fornecer, seu comportamento, e ainda, o
que o sistema não deve fazer.
- A etnografia é uma técnica utilizada para a descoberta de requisitos de sistemas de software na qual,
por meio de observações, procura-se compreender os requisitos sociais e organizacionais do ambiente
onde o sistema será usado.
- A descrição dos cenários de uso com informações acerca da utilização do sistema sob diversos pontos de
vista e formas de operação deve fazer parte do levantamento dos requisitos.
- A construção de um modelo de casos de uso é um meio para capturar requisitos funcionais com foco no
valor dos requisitos para os usuários. Um caso de uso especifica uma seqüência de ações que o sistema
pode realizar e que produzem resultados observáveis e de valor para os atores.
- Em um modelo de casos de uso, pode haver diferentes tipos de usuários representados por atores. Além
de tipos de usuários, atores podem representar outros sistemas ou hardwares que interagem com o
sistema a ser desenvolvido. Atores se comunicam com o sistema via casos de uso.
- Revisão de requisitos, prototipação e geração de casos de teste são exemplos de técnicas de validação
de requisitos.
- Uma das formas de resolução de ambigüidades de requisitos consiste em realizar a prototipação de
partes do sistema, antes de se adotar uma solução.
- A rastreabilidade de requisitos é essencial para que o controle de mudanças possa avaliar o impacto de
uma solicitação de Mudança.
- A gerência de requisitos tem como objetivo principal controlar a evolução dos requisitos, seja por
constatação de novas necessidades, seja por constatação de deficiências nos requisitos registrados até o
momento.
- O gerenciamento de requisitos deve compreender e controlar mudanças nos requisitos de sistema, além
de avaliar os seus impactos. Para atingir esse propósito, podem ser mantidas informações de
rastreabilidade a serem usadas para avaliar quais outros requisitos seriam afetados por uma mudança,
bem como o impacto da mudança de requisitos no projeto e na implementação do sistema.
- Um modelo de análise pode realizar casos de uso. A realização de um caso de uso descreve interações
entre objetos. Na UML, essas realizações podem ser documentadas via diagramas de colaboração (v 2.0
=comunicação).
- O conceito de herança possibilita a especialização de comportamentos pré-existentes em classes
ancestrais.
- Uma das desvantagens da herança é a criação de dependência entre as classes envolvidas.
- De acordo com a ideia do encapsulamento, é desejável, do ponto de vista de um objeto, que seus
atributos internos estejam protegidos contra modificações diretas e que o acesso seja realizado por meio
de métodos específicos (setters e getters).
- Polimorfismo está relacionado à vinculação dinâmica de mensagens e sobrescrita de métodos, sendo
que o método correto a ser chamado só será definido em tempo de execução e dependerá do tipo da
instância do objeto referenciado pela mensagem.
- Em um modelo de análise, as classes de fronteira modelam interações entre o sistema e os atores. Cada
classe de fronteira deve estar relacionada a um ou mais atores. Pode-se também ter classes de entidade,
as quais tipicamente modelam dados persistentes.
- Se uma classe criada por meio de herança tiver uma única classe- pai, o processo chama-se herança
simples. Se tiver mais de uma classe- pai, o processo chama-se herança múltipla. Uma classe derivada
pode acrescentar variáveis e métodos, possibilitando que certas operações sejam fornecidas apenas aos
objetos da classe derivada.
- Ao longo do desenvolvimento, artefatos produzidos podem ser revisados, objetivando garantir que os
mesmos apresentem, pelo menos, a qualidade mínima especificada. Não apenas o código, mas também
outros artefatos podem ser revisados. Os defeitos encontrados pelas revisões referem-se à faltas (fault),
enquanto os defeitos encontrados por testes são falhas do software, pois testes avaliam a qualidade
comparando o comportamento esperado com o observado.
- A validação assegura que o produto, como fornecido, irá atender o seu uso pretendido, ou seja, que se
está construindo o produto certo. E a verificação confirma que os produtos de trabalho refletem de forma
apropriada os requisitos que foram especificados, ou seja, que se está construindo o produto
corretamente.
- A diferença entre verificação e validação reside no fato de que a primeira se refere ao conjunto de
atividades que garante que o software realiza corretamente uma função específica, enquanto a segunda
refere-se a um conjunto diferente de atividades que garante que o software que foi construído é
rastreável às exigências do cliente.
- O processo de validação tem por objetivo estabelecer com os clientes confiança quanto ao
funcionamento adequado de um software. Enquanto inspeções de software ou revisões por pares são
consideradas validação estática, o teste consiste em uma técnica dinâmica de validação de software. Os
termos estático ou dinâmico são relativos à necessidade ou não do software ser executado.
- Teste funcional é uma técnica para se projetar casos de teste na qual o programa ou sistema é
considerado uma caixa-preta e, para testá-lo, são fornecidas entradas e avaliadas as saídas geradas.
- Entre os tipos de testes de caixa preta, encontram-se o teste baseado em grafos; o particionamento de
equivalência; a análise de valor-limite; e o teste de matriz ortogonal.
- O aumento na medida de complexidade ciclomática de um programa introduz mudanças significativas
no refinamento de uma abordagem do tipo caixa-branca.
- À medida que avança o nível de integração dos módulos de um software, mais viável se torna a adoção
do método de caixa-preta para desenho do teste de software.
- Para aderência à abordagem de software caixa-branca, podem ser empregados testes de fluxo de
controle e de dados, que não são apoiadores diretos em testes de caixa-preta.
- O teste estrutural é uma estratégia que se baseia na análise da especificação de um programa para
ajudar na seleção de casos de teste.
- A atividade de teste unitário de software é, conforme os modelos de ciclo de vida de software vigentes,
realizada de forma mais eficaz no escopo de implementação e da construção de software - nas quais a
codificação de uma unidade executável de software é feita -, quando comparada à situação em que o
teste unitário é realizado simultaneamente ao teste de integração.
- Os testes de integração verificam se os componentes do sistema funcionam em conjunto, se os
componentes são chamados corretamente e se os componentes transferem dados corretos via suas
interfaces. Nesses testes, os componentes são testados interligados; podem ser necessários drivers e
stubs para simular componentes ainda não implementados; e, em sistemas de software orientados a
objeto, os stubs podem ser classes.
- Há um tipo de teste que vislumbra a “destruição do programa” por meio de sua submissão a
quantidades, frequências ou volumes anormais que é o teste de estresse.
- Ao se inspecionar o conteúdo de um plano de testes, devem-se encontrar, entre outras, as seguintes
descrições: escopo de testes, abordagens de teste, recursos para realização dos testes e cronograma das
atividades de teste a serem realizadas.
Referência Bibliográfica:

Aulas do curso Engenharia de Software do Prof. Fernando Pedrosa 01 a 05

Módulo 01:
http://www.provasdeti.com.br/index.php/por-disciplina/engenharia-de-software/
esw01-para-concursos.html

Módulo 02:
http://www.provasdeti.com.br/index.php/por-disciplina/engenharia-de-software/
esw02-para-concursos.html

Módulo 03:
http://www.provasdeti.com.br/index.php/por-disciplina/engenharia-de-software/
esw03-para-concursos.html

Módulo 04:
http://www.provasdeti.com.br/index.php/por-disciplina/engenharia-de-software/
esw04-para-concursos.html

Módulo 05:
http://www.provasdeti.com.br/index.php/por-disciplina/engenharia-de-software/
esw05-para-concursos.html