UNIDADE II

Engenharia de Software I

Profa. MSc. Priscila Facciolli

 Processo de desenvolvimento de software

 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.

 Para que um processo?

 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.

Processo de desenvolvimento de software

Percepção das necessidades do cliente ou do usuário final

(requisitos do software)
Concepção (análise do software - modelagem)
Elaboração (definição da arquitetura do software)
Desenho inicial
Desenho
detalhado
Desenvolvimento Construção Implementação 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)
Fonte: Adaptado do: livro-texto.
 Processo Pessoal de Software (PSP)

 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)

Fonte: livro-texto.
 Processo Pessoal de Software (PSP)

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 para a Equipe de Software (TSP)

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;

Equipes
 Definir um processo comum de trabalho; autogerenciáveis

 Envolver todos na produção do plano e Gerência

Coaching
negociar o plano com a gerência; da
(tutorial)
qualidade
 Comunicar constante e livremente; Fatores
princípios
 Treinar previamente em PSP. do TSP

Arcabouço Personal
(framework) Software
de mediação Process
integrada (PSP)

Fonte: Adaptado do livro-texto.

 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

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.
 Modelos de ciclo de vida de software

 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

Levantamento das
necessidades

Análise das
Manutenção
alternativas

Implementação Projeto

Desenvolvimento

Fonte: Adaptado do: livro-texto.

 Modelos de ciclo de vida de software

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.
 Modelo Codifica-Remenda

 É 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 Cascata (waterfall)

Engenharia de
Sistemas
Análise

Design

Codificação

Testes

Manutenção

Fonte: Adaptado do: livro-texto..

 Modelo Cascata (waterfall)

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.
 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

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.
 Modelo Incremental

 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

Incremento n
Comunicação

Planejamento

Incremento 2 Modelagem

Construção
Comunicação
Implantação
Planejamento

Incremento 1 Modelagem Entrega do n

incremento
Comunicação Construção

Planejamento Implantação Entrega do 2º

incremento
Modelagem

Construção
Entrega do 1º
Implantação incremento
Núcleo do produto
Fonte: Adaptado do: livro-texto.
 Modelo Incremental – Quando utilizar?

 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

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 RAD (Rapid Application Development)

 É 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)
Equipe nº 3
Equipe nº 2 Modelagem
Equipe nº 1 do negócio
Modelagem do
Modelagem negócio Modelagem
do negócio dos dados
Modelagem Modelagem
dos dados do processo
Modelagem
dos dados Geração de
Modelagem do
processo aplicação
Modelagem
Teste e
do processo Geração de modificação
aplicação
Geração de
Teste e
aplicação modificação

Teste e
60 a 90 dias modificação

Fonte: Adaptado do: livro-texto.

 Modelo RAD – Quando utilizar?

 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

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 de Prototipação

 É 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

Obter os
requisitos

Elaborar o projeto
rápido
Refinamento do protótipo

Construir o
Avaliar o protótipo protótipo

Fonte: Adaptado do: livro-texto.

 Modelo de Prototipação – Quanto utilizar?

 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

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.
 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

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.
 Modelo Espiral

 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

Definir os objetivos Analisar os

(planejamento) riscos

Avaliar e planejar
a próxima fase
Desenvolvimento
da engenharia

Fonte: Adaptado do livro-texto.

 Modelo Espiral – Quando utilizar?

 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

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.
 Processo unificado

 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

Concepção Elaboração Construção Transição

Requisitos

Análise

Análise

Implementação

Testes

Iter. Iter. Iter. Iter.

nº 1 nº 2 nº 1 nº 2

Fonte: Adaptado de livro-texto.

 Processo unificado

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.
 RUP (Processo Unificado Racional)

 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)
Modelo de negócio, lista de requisitos, casos de
uso, modelo de domínio, protótipo preliminar

Requisitos Modelo de Modelo de classes, diagrama de atividades,

use case diagrama de estados e casos de testes

Modelo de Deployment, diagrama de componentes,

Análise diagramas de sequência e modelagem visual
análise
Design Modelo
design
Modelo de
Implementação implementação
Modelo de
Testes teste

Fonte: Adaptado do: livro-texto.

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.
 Processo Praxis

 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).

 Processo Clean Room (Sala Limpa)

 É 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 – Quando utilizar?

 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

Vantagens:
 Alta qualidade;
 Baixo número de erros.

Problema:
 Processo muito complexo;
 Requer conhecimento matemático;
 Produtividade é menor.
 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

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.
ATÉ A PRÓXIMA!