Slide 2

Prévia do material em texto

Profa. MSc. Priscila Facciolli
UNIDADE II
Engenharia de Software I
 Conjunto de atividades coerentes e consistentes para especificar, projetar, implementar e 
testar um software. 
 É uma representação abstrata de como será realizada a construção do software.
Processo de desenvolvimento de software
 Para definir as atividades a serem conduzidas no projeto.
 Para uniformizar o entendimento dos envolvidos em relação ao desenvolvimento 
de sistemas.
 Para manter a consistência entre os sistemas desenvolvidos em uma mesma empresa.
 Para viabilizar os pontos de controle para a gerência.
Para que um processo?
Processo de desenvolvimento de software
Fonte: Adaptado do: livro-texto.
Percepção das necessidades do cliente ou do usuário final 
(requisitos do software)
Desenvolvimento
Concepção (análise do software - modelagem)
Elaboração (definição da arquitetura do software)
Construção
Desenho inicial
Implementação
Desenho 
detalhado
Codificação
Teste de unidade
Testes de integração
Transição (entregas parciais e testes de homologação 
pelo cliente usuário final)
Operação (utilização do software pelo cliente-usuário)
Manutenção (melhorias do software e acertos de defeitos)
Retirada (troca ou cancelamento do produto de software)
 Sugere práticas e métodos para que o próprio indivíduo possa identificar e corrigir os seus 
pontos fracos.
 É uma sugestão para organizar e disciplinar o indivíduo, e não para limitar a sua capacidade 
de criação.
 Possui 7 etapas sequenciais e progressivas, cada uma com um conjunto de roteiros e 
formulários disponíveis em www.sei.cmu.edu.
Processo Pessoal de Software (PSP)
Processo Pessoal de Software (PSP)
Fonte: livro-texto.
Objetivos do PSP:
 Melhorar o planejamento;
 Melhoria das estimativas de prazos;
 Estabelecer processos de revisão de projeto e código;
 Gerenciar a qualidade;
 Executar a fase de projeto de maneira mais formal;
 Identificar pontos de melhoria da qualidade.
Processo Pessoal de Software (PSP)
O TSP é baseado no PSP e estabelece um framework para:
 Planejar e gerenciar um projeto em equipe;
 Definir processos – Incremental;
 Distribuir papéis – Disciplina;
 Construir um trabalho em equipe;
 Estabelecer medidas de qualidade;
 Ter equipes eficazes.
Processo para a Equipe de Software (TSP)
Equipes eficazes possuem:
 Objetivo definido, realista e tangível;
 Recursos são suficientes para o trabalho;
 Membros qualificados;
 Time motivado e empenhado em cumprir os objetivos;
 Membros cooperam e apoiam uns aos outros;
 Membros são disciplinados em seu trabalho.
Processo para a Equipe de Software (TSP)
 Estabelecer objetivos e papéis;
 Definir um processo comum de trabalho;
 Envolver todos na produção do plano e 
negociar o plano com a gerência;
 Comunicar constante e livremente;
 Treinar previamente em PSP.
Processo para a Equipe de Software (TSP)
Fonte: Adaptado do livro-texto.
Gerência 
da 
qualidade
Equipes 
autogerenciáveis
Arcabouço 
(framework) 
de mediação 
integrada
Coaching
(tutorial)
Personal
Software 
Process
(PSP)
Fatores 
princípios 
do TSP
Um processo de desenvolvimento define um conjunto de atividades para organizar e 
padronizar a construção de um software. A fase responsável por definir as características 
técnicas da arquitetura do software é a: 
a) Fase de construção.
b) Fase de concepção.
c) Fase de manutenção.
d) Fase de elaboração.
e) Fase de transição.
Interatividade
Um processo de desenvolvimento define um conjunto de atividades para organizar e 
padronizar a construção de um software. A fase responsável por definir as características 
técnicas da arquitetura do software é a: 
a) Fase de construção.
b) Fase de concepção.
c) Fase de manutenção.
d) Fase de elaboração.
e) Fase de transição.
Resposta
 Definem um conjunto distinto de atividades, ações, tarefas, marcos e produtos de trabalho 
que são necessários para fazer a engenharia de software com alta qualidade. 
 Esses modelos fornecem um roteiro útil para o trabalho de engenharia de software.
Modelos de ciclo de vida de software
Principais modelos de ciclo de vida:
 Modelo Codifica-Remenda;
 Modelo Sequencial Linear (cascata);
 Modelo Incremental;
 Modelo RAD;
 Modelo Prototipação;
 Modelo Espiral;
 Modelo Unificado;
 Modelo PRAXIS;
 Modelo Sala Limpa.
Modelos de ciclo de vida de software
O modelo de ciclo de vida processo é escolhido com base:
 Na natureza do projeto e da aplicação (tipo de software);
 Nos métodos e ferramentas a serem utilizados; 
 Nos controles e nos produtos intermediários e finais a serem entregues.
Modelos de ciclo de vida de software
Ciclo de vida do software – mais comum
Modelos de ciclo de vida de software
Fonte: Adaptado do: livro-texto.
Levantamento das 
necessidades
Desenvolvimento
Projeto
Análise das 
alternativas
Manutenção
Implementação
Levantamento das necessidades: 
 Entendimento e levantamento das necessidades da área do negócio.
Análise: 
 Identificação e avaliação das alternativas sistêmicas que atendam aos requisitos.
Projeto: 
 Definem as características técnicas relacionadas à construção como a arquitetura 
e o banco de dados.
Modelos de ciclo de vida de software
Desenvolvimento:
 Inclui a codificação e os testes do novo sistema.
Implantação: 
 Consiste em transferir a aplicação do ambiente de desenvolvimento para o ambiente 
de produção.
Manutenção: 
 Atividades relacionadas a correções e/ou inclusão de novas 
funcionalidades após o sistema estar em produção.
Modelos de ciclo de vida de software
 É o modelo de ciclo de vida mais caótico.
 Parte de uma especificação simples ou uma reunião para iniciar a codificação, fazendo 
correções à medida que surgem os defeitos.
 Não há a separação de papéis e todos fazem todas as atividades.
 Ainda é utilizado nos dias atuais.
Modelo Codifica-Remenda
Modelo Cascata (waterfall)
Fonte: Adaptado do: livro-texto..
Engenharia de 
Sistemas
Análise
Design
Codificação
Testes
Manutenção
Engenharia de Sistemas: 
 Envolve a coleta das necessidades dos usuários.
Definem-se:
 Os requisitos de negócio;
 A avaliação do sistema atual em uso, se existir; 
 Elementos de software e hardware necessários. 
Modelo Cascata (waterfall)
Análise:
 Concentra-se no detalhamento do “o quê” deve ser feito. 
Design (projeto):
 Define o “como” a aplicação será construída;
 Envolve a definição da arquitetura de software, do banco de dados e das características 
visuais. 
Modelo Cascata (waterfall)
Codificação:
 Tradução dos requisitos para uma linguagem de programação.
Testes:
 Verifica se a aplicação está de acordo com a sua especificação.
Manutenção:
 Envolve as alterações no sistema relacionadas aos erros, às evoluções de negócio 
ou às evoluções técnicas.
Modelo Cascata (waterfall)
Principais dificuldades:
 Os projetos nem sempre são sequenciais e as mudanças sempre trazem problemas;
 O produto somente é visível no final de todo o ciclo.
Quando utilizar:
 Projetos com requisitos bem definidos;
 Projetos pequenos com duração de, até, 2 meses.
Modelo Cascata (waterfall)
O Modelo Cascata ainda é muito utilizado nos dias atuais e representa a estrutura base para os 
demais modelos. Qual das opções a seguir é uma característica deste modelo?
a) É um processo interativo.
b) É indicado para projetos longos.
c) O produto é visto somente ao final.
d) É indicado para os projetos com requisitos mal definidos.
e) Nenhuma das alternativas.
Interatividade
O Modelo Cascata ainda é muito utilizado nos dias atuais e representa a estrutura base para os 
demais modelos. Qual das opções a seguir é uma característica deste modelo?
a) É um processo interativo.
b) É indicado para projetos longos.
c) O produto é visto somente ao final.
d) É indicado para os projetos com requisitos mal definidos.
e) Nenhuma das alternativas.
Resposta Divide o desenvolvimento de software em incrementos (que são partes do sistema) que 
“independem” uns dos outros.
 Cada sequência linear produz uma parte do software. O processo se repete até que o 
produto esteja completo.
 O incremento inicial é chamado de núcleo do produto. Isto quer dizer que os requisitos 
básicos devem ser satisfeitos logo no início do projeto.
Modelo Incremental
Modelo Incremental
Fonte: Adaptado do: livro-texto.
Incremento 1
Incremento 2
Incremento n
Entrega do n 
incremento
Entrega do 2º 
incremento
Entrega do 1º 
incremento
Núcleo do produto
Comunicação
Comunicação
Comunicação
Planejamento
Planejamento
Planejamento
Modelagem
Modelagem
Modelagem
Construção
Construção
Construção
Implantação
Implantação
Implantação
 Para sistemas que podem ser divididos em módulos.
 Para sistemas com muitas alterações de requisitos.
 Quando o usuário necessita utilizar uma parte do produto antes do final de um projeto.
 Quando há um prazo de entrega que não pode ser modificado.
Modelo Incremental – Quando utilizar?
Vantagens:
 Entregas parciais facilitam a validação do cliente;
 Feedback constante aumenta a qualidade;
 Cada incremento é uma parte de software utilizável.
Desvantagens:
 Cliente pode não aceitar a divisão em módulos.
Modelo Incremental
 É incremental e contém um ciclo de desenvolvimento curto (em média de 60 a 90 dias).
 Construção baseada em componentes.
 Pode ser dividido entre as várias equipes RAD e, ao final, integrada para formar o todo.
Modelo RAD (Rapid Application Development)
Modelo RAD (Rapid Application Development)
Fonte: Adaptado do: livro-texto.
Equipe nº 1
Equipe nº 2
Equipe nº 3
60 a 90 dias
Modelagem 
do negócio
Modelagem 
dos dados
Modelagem 
do processo
Geração de 
aplicação
Teste e 
modificação
Modelagem do 
negócio
Modelagem 
dos dados
Modelagem do 
processo
Geração de 
aplicação
Teste e 
modificação
Modelagem 
do negócio
Modelagem 
dos dados
Modelagem 
do processo
Geração de 
aplicação
Teste e 
modificação
 As restrições de tempo devem ser (em média de 60-90 dias).
 Se a aplicação de software pode ser modularizada e cada função principal possa ser 
completada em menos de 3 meses.
 Cada função principal pode ser tratada por uma equipe distinta e, depois, integrada para 
formar um todo.
Modelo RAD – Quando utilizar?
Vantagens:
 Ciclo curto de desenvolvimento;
 Usa a prototipação interativa e viva;
 Aumento do reúso do código.
Desvantagens:
 Não indicado para projetos grandes e complexos;
 Não aplicado a projetos com alto risco técnico.
Modelo RAD
 É um modelo evolucionário.
 Pode ser usado por qualquer dos demais modelos.
 Utilizado para identificar e validar os requisitos.
 Permite visualizar como o sistema ficará quando estiver pronto.
Modelo de Prototipação
Modelo de Prototipação
Fonte: Adaptado do: livro-texto.
Obter os 
requisitos
Refinamento do protótipo
Avaliar o protótipo
Construir o 
protótipo
Elaborar o projeto 
rápido
 Quando os requisitos estão mal definidos ou difíceis de serem compreendidos.
 Um meio de redução de risco, ao permitir que o usuário visualize como vai ficar antes de 
estar pronto.
 Pode ser usado em qualquer tipo de sistema na fase de captura dos requisitos. Depois, pode 
continuar com outros modelos ao decorrer de desenvolvimento.
Modelo de Prototipação – Quanto utilizar?
Vantagens:
 Reduz o número de mudanças;
 Aumenta a qualidade;
 Pode reduzir o tempo de desenvolvimento.
Desvantagens:
 O cliente acha que o produto está pronto;
 O projetista pode incorporar as soluções inadequadas.
Modelo de Prototipação
Os modelos de ciclo de vida de desenvolvimento de software Incremental e RAD são 
semelhantes em sua estrutura. Assinale a alternativa que indica uma dessas semelhanças:
a) Usam a prototipação.
b) Divide o software em partes menores.
c) Utiliza os componentes.
d) Não melhora a qualidade.
e) São testados só ao final de todo o projeto.
Interatividade
Os modelos de ciclo de vida de desenvolvimento de software Incremental e RAD são 
semelhantes em sua estrutura. Assinale a alternativa que indica uma dessas semelhanças:
a) Usam a prototipação.
b) Divide o software em partes menores.
c) Utiliza os componentes.
d) Não melhora a qualidade.
e) São testados só ao final de todo o projeto.
Resposta
 Engloba a natureza interativa do Modelo de Prototipação com os aspectos do Modelo 
Cascata e de análise de riscos.
 Cada loop representa uma fase do processo de software.
 Onde cada loop pode estar relacionado à viabilidade do sistema.
 O próximo loop, à definição de requisitos.
 O próximo, ao projeto e assim por diante.
 A cada ciclo são produzidas versões cada vez mais completas 
do software.
Modelo Espiral
Modelo Espiral
Fonte: Adaptado do livro-texto.
Definir os objetivos 
(planejamento)
Avaliar e planejar 
a próxima fase
Analisar os 
riscos
Desenvolvimento 
da engenharia
 Para softwares de grande porte.
 Para softwares que possuem riscos no seu desenvolvimento.
 Com o uso de prototipação, tem-se melhor conhecimento de requisitos do sistema.
Modelo Espiral – Quando utilizar?
Vantagens:
 É uma alternativa ao ciclo cascata;
 Primeiro modelo a incluir a análise de riscos;
 Permite uma maior interação com o cliente.
Desvantagens:
 Difícil convencer o cliente que uma abordagem “evolutiva” é melhor;
 Exige experiência na avaliação de riscos e no uso do modelo.
Modelo Espiral 
 Baseado em casos de uso.
 Centrado em arquitetura.
 Modela o software utilizando a UML.
 Desenvolve o software interativamente.
 Gerencia os requisitos.
 Verificação contínua da qualidade.
Processo unificado
Processo unificado
Fonte: Adaptado de livro-texto.
Requisitos
Análise
Análise
Testes
Implementação
Concepção Elaboração Construção Transição
Iter. Iter.
nº 1 nº 2 
Iter. Iter.
nº 1 nº 2 
Vantagens:
 Tolerância às mudanças de requisitos;
 Elementos de um software são integrados progressivamente;
 Incorpora, formalmente, a gerência de projeto ao ciclo.
Desvantagens:
 Cliente não aceita o processo interativo;
 Complexidade de suas fases e seus fluxos;
 Indispensáveis que os profissionais sejam capacitados no processo.
Processo unificado
 Processo configurável.
 Adapta-se a softwares de pequeno, médio ou de grande porte.
 Baseado em documentação de requisitos.
 Utiliza UML.
 Trabalha com a orientação aos objetos.
RUP (Processo Unificado Racional)
RUP (Processo Unificado Racional)
Apresenta 4 fases:
Concepção ou iniciação, elaboração, construção e 
transição. Disciplinas:
 São 10 atividades que variam de intensidade conforme 
a fase. Dão origem aos artefatos do projeto.
Fonte: Adaptado do: livro-texto.
Requisitos
Análise
Design
Implementação
Testes
Modelo de 
use case
Modelo de 
análise
Modelo 
design
Modelo de 
implementação
Modelo de 
teste
Modelo de negócio, lista de requisitos, casos de 
uso, modelo de domínio, protótipo preliminar
Modelo de classes, diagrama de atividades, 
diagrama de estados e casos de testes
Deployment, diagrama de componentes, 
diagramas de sequência e modelagem visual
 Tem como objetivo dar suporte ao treinamento em engenharia de software e à implantação 
de processos em organizações.
 É baseado na experiência do prof. Wilson de Pádua Paula Filho.
 Baseia-se em: CMMI, UML, UP e nos padrões do Institute Eletric Eletronic Engineering
(IEEE) para a engenharia de software.
Processo Praxis
 Fornece suporte para projetos realizados individualmente ou por pequenas equipes, com 
duração de seis meses a um ano.
 Abrange requisitos, análise, desenho, testes e implementação, quanto métodos gerenciais, 
como gestão de requisitos, gestão de projetos, garantia da qualidade e gestão 
de configuração.
 Propõe um ciclo de vida composto por fases.
 Gera artefatos (documentos e modelos). 
ProcessoPraxis
 É uma aplicação prática de matemática e estatística para produzir software de 
alta qualidade.
 Aplica fortemente a prevenção de erros.
 Utiliza os métodos de especificação precisos, chamadas de especificações formais.
 A especificação formal é complexa e trabalhosa.
Processo Clean Room (Sala Limpa)
 Normalmente, utilizada na produção de softwares que trazem risco à perda de 
vidas humanas.
 Exemplos: controle de trens, metrôs, aviões e usinas nucleares.
Processo Clean Room – Quando utilizar?
Vantagens:
 Alta qualidade;
 Baixo número de erros.
Problema:
 Processo muito complexo;
 Requer conhecimento matemático;
 Produtividade é menor.
Processo Clean Room
Em relação às afirmativas a seguir sobre o processo unificado, qual a alternativa correta:
a) Não utiliza técnicas para a garantia da qualidade.
b) É um processo simples que não requer treinamento.
c) É um processo rápido e de fácil aceitação pelo cliente.
d) É baseado em casos de uso e centrado em arquitetura.
e) Não requer o gerenciamento do projeto.
Interatividade
Em relação às afirmativas a seguir sobre o processo unificado, qual a alternativa correta:
a) Não utiliza técnicas para a garantia da qualidade.
b) É um processo simples que não requer treinamento.
c) É um processo rápido e de fácil aceitação pelo cliente.
d) É baseado em casos de uso e centrado em arquitetura.
e) Não requer o gerenciamento do projeto.
Resposta
ATÉ A PRÓXIMA!