PSI - Aula 01

Aula 01 - PSI - Revisão
Visão Geral da Engenharia de Software, Requisitos de Software

Prof. Lucas H. C. de Lima
Agenda
● Comunicados
● Revisão
○ Unidade 1 - Visão Geral da Engenharia de Software
○ Unidade II - Requisitos de Software (até requisitos de interface)
● Descrição exercício de Revisão
Projeto de Sistemas (PSI) 2

Comunicados
● Já estou com acesso ao Moodle da disciplina
○ Conteúdo da disciplina será postado lá
● Atividade de Revisão disponível

○ Entrega até 06/10, 23:55
● Dúvidas?
○ lucaslima@cefetmg.br

Unidade I - Visão Geral da Eng. de Software
Revisão
Introdução a Engenharia de Software
Motivação

O que é Software?
● Programa de Computador + Documentação
● Classificação fundamental
○ Produtos Genéricos (ex. MS Office)
○ Produtos Encomendados (ex. Software Vendinha do Zé)
● Cada vez mais presente no dia a dia

Desafios
● Confiabilidade
Desenvolver sistemas bons,
● Preço e desempenho confiáveis e que tenham preços
acessíveis
● Sistemas Críticos

Engenharia de Software
A Engenharia de Software é uma disciplina

de engenharia relacionada a todos os
aspectos de produção de software
Ian Sommerville
● Foco no desenvolvimento de software de alta qualidade dentro

de custos adequados
○ Atender as necessidades dos clientes

Visão Geral da Engenharia de Software em Camadas
● Pode ser organizada em camadas com foco em qualidade

Atributos de um bom
software:
- Facilidade de
Manutenção
- Confiança
- Eficiência
- Usabilidade...

Atividades (e seus
resultados) para o
desenvolvimento de
software: O que fazer?
Atividades Principais:
- Especificação
- Modelagem
- Implementação
- Verificação
- Evolução

Técnicas para
desenvolvimento de
software: Como
fazer?
Métodos Incluem:
- Modelos
- Notações
- Regras

Fornecem apoio
automatizado para o
processo e para os
métodos
Exemplo:
- Ferramentas de
modelagem de
processo

Processos de Desenvolvimento de Software
O que é um processo de software?
● Conjunto de atividades que leva ao desenvolvimento do produto software
● Um processo define
○ Quem faz, o que faz e quando fazer
○ Nem sempre diz como fazer
● Não existe um processo ideal

○ Organizações desenvolvem seus próprios processos

Atividades de Desenvolvimento
● 5 atividades são comuns no processo de desenvolvimento de

software:
○ Engenharia de Requisitos
○ Modelagem de Software
○ Implementação
○ Verificação e Validação
○ Evolução


software:
Atividades Preliminares
○ Implementação
○ Evolução


software: Processo que engloba
○ Engenharia de Requisitos todas as atividades
que contribuem para
○ Modelagem de Software a produção de um
○ Implementação documento de
requisitos
○ Evolução


software:
○ Engenharia de Requisitos 1. define a estrutura
modular do software,
○ Modelagem de Software e 2. detalha cada
○ Implementação módulo definido do
projeto preliminar
○ Evolução


software:
Transcreve as
○ Modelagem de Software decisões de projeto
○ Implementação arquitetural e
detalhado para uma
○ Verificação e Validação linguagem de
○ Evolução programação


software:
○ Implementação Tem por objetivo
garantir que o sistema
○ Verificação e Validação satisfaça os requisitos
○ Evolução


software:
○ Implementação
○ Verificação e Validação Acompanhar evolução
e manutenção do
○ Evolução Software

O que é o modelo do processo de software?
● Descrição simplificada do processo
● Definem
○ As atividades para o desenvolvimento do software
○ Especificam os produtos de cada atividade
○ Indicam os papéis das pessoas envolvidas

Exemplos de Modelos de Processo
● Modelos de Processos mais gerais

○ Modelo Cascata
○ Desenvolvimento Incremental
● Modelos que lidam com mudanças

○ Prototipagem
○ Entrega Incremental
○ Modelo Espiral

Ciclo de Vida de Software: Modelo Cascata
● Atividades sequenciais
● Uma fase deve ser terminada para a outra começar
○ Raramente ocorre na prática

Vantagens do Modelo Cascata
● Documentação rígida (idealmente

completa) em cada atividade
● Reflete abordagens adotadas em outras engenharias
● Aderência a outros modelos de processo

○ Pode ser combinado a outros modelos

Desvantagens do Modelo Cascata
● Projetos reais raramente seguem

um fluxo sequencial
○ Difícil se adequar a mudanças inevitáveis
de requisitos
● Em geral, é difícil para o cliente estabelecer todos os requisitos à priori
● Uma versão executável somente ficará pronta na fase final do projeto

Unidade II - Requisitos de Software
Revisão
Introdução a Requisitos de Software
O que são requisitos?
● Requisitos
○ Descrições dos serviços fornecidos pelo sistema e das restrições
sobre estes serviços
● Engenharia de Requisitos
○ Processo de descobrir, analisar, documentar e verificar requisitos
Requisitos definem o que o sistema faz, nem

sempre dizem como ele faz (projeto)

Desafios
● Não é fácil padronizar os requisitos usando
linguagem natural
● Falta de clareza
● Diversos requisitos expressos juntos
● Diretrizes Gerais
○ Adotar um formato padrão e usá-lo em
todas as definições
○ Usar a linguagem de forma simples e
consistentes
Desafios
● A imprecisão na especificação de requisitos é motivo de vários
problemas: ambiguidades em requisitos
○ O desenvolvedor tende a interpretar o requisito da maneira
mais fácil de implementar
● “O sistema deve oferecer telas apropriadas…”

○ O que são telas apropriadas?

Requisitos Funcionais
● Descrevem explicitamente as funcionalidades e serviços do
sistema
○ Documenta também o que o sistema não deve fazer
● Atributos dos Requisitos Funcionais:

○ Completude: todos os serviços devem estar definidos
○ Consistência: os requisitos não devem ter definições
contraditórias

Exemplos de Requisitos Funcionais
● O usuário pode pesquisar todo ou um sub-conjunto do banco de

dados
● O sistema deve oferecer telas apropriadas para o usuário ler
documentos armazenados
● Cada pedido deve ser associado a um identificador único (PID), o
qual o usuário pode copiar para a área de armazenamento
permanente da conta

Requisitos Não Funcionais
● Definem propriedades e restrições do sistema
○ Exemplos: segurança, desempenho, espaço em disco
● Podem ser do sistema todo ou de partes do sistema
● Requisitos não-funcionais podem ser mais críticos que requisitos
funcionais: ‘se não satisfaz, o sistema é inútil’
● Desafios:
○ Requisitos não funcionais podem conflitar com outros requisitos
(funcionais ou não)

Requisitos Não Funcionais
Classificação de RNF

Exemplos de Requisitos Não Funcionais
● Requisitos do Produto
○ A interface do usuário deve ser implementada como simples HTML
● Requisitos Organizacionais
○ Todos os documentos entregues devem seguir o padrão de relatórios
XYZ-00
● Requisitos Externos
○ Informações pessoais dos usuários não podem ser vistas pelos operadores
do sistema
Métricas de Requisitos Não Funcionais
● Velocidade
○ Tempo de resposta, tempo de atualização de tela
● Facilidade de Uso
○ Tempo gasto em treinamento, número de quadros de ajuda
● Confiabilidade
○ Tempo médio para falhar, taxa de ocorrência de falhas, disponibilidade
● Robustez
○ Tempo de reinício após uma falha, porcentagem de eventos que causam falhas
Identificação de Requisitos Funcionais e Não Funcionais
Engenharia de Requisitos
● O Documento de Requisitos é lido por várias pessoas

interessadas no sistema (stakeholders)
● Inclui quatro fases principais:

○ Estudo de viabilidade
○ Elicitação de requisitos
○ Especificação de requisitos
○ Validação dos requisitos

Identificação de Requisitos Funcionais e Não Funcionais
Engenharia de Requisitos
● O Documento de Requisitos é lido por várias pessoas

interessadas no sistema (stakeholders)
O objetivo é descobrir
- O domínio de aplicação
● Inclui quatro fases principais: - Serviços que devem ser fornecidos pelo
sistema
○ Estudo de viabilidade - Restrições associadas ao domínio ou aos
serviços
○ Elicitação de requisitos
○ Especificação de requisitos Várias técnicas podem ser utilizadas para
levantamento de requisitos
○ Validação dos requisitos - Entrevistas
- Cenários
- Casos de Uso

Exercício de Revisão: Entrega até 06/10, 23:55
● À medida que o software invade praticamente todos os setores do nosso dia a dia, riscos ao público (devido a programas
com imperfeições) passam a ser uma preocupação cada vez maior. Crie um cenário o mais catastrófico possível, porém
realista, cuja falha de um programa de computador poderia causar um grande dano (em termos econômico ou humano).
● Na questão anterior você criou um cenário em que falhas em um programa de computador podem causar grandes danos
econômicos ou humanos. Nesta questão, discuta as vantagens de empresas adotarem Processos de Desenvolvimento de
Software e especificarem um modelo de processo. Explique a importância da comunicação em processos de
desenvolvimento. Finalmente, discuta os motivos que levam o Modelo Cascata a não ser muito utilizado em cenários
práticos de projetos de sistemas.
● Suponha que você tenha que criar um sistema para acompanhamento de evento esportivo, conforme cenário descrito a
seguir. Cite pelo menos 3 requisitos funcionais e 3 requisitos não funcionais. Lembre-se que requisitos podem ser
ambíguos se não descritos de forma clara e que descrever diversos requisitos juntos não é uma boa prática.

Próximas Aulas...
● Laboratório (01/10)
○ Apresentação dos grupos sobre o tema do Projeto Integrado (PI)
■ Apresentação curta, em poucas palavras, para descrever qual é o seu projeto, qual
a solução vocês oferecem (6-7 minutos)
● Laboratório (08/10)
○ Prática Processos de Software (Trello)
○ Ajustes Primeira Etapa
● Teoria (13/10)
○ Requisitos de Interface
○ Modelagem de Processos de Negócio

Referências
● Ian Sommerville. Engenharia de Software, 9ª Edição. Pearson
Education, 2011.
● Roger Pressman. Engenharia de Software: Uma Abordagem
Profissional, 7a Edição. McGraw-Hill, 2011.
● Material de aula Prof. Eduardo Figueiredo (DCC/UFMG)

PSI - Aula 01

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PSI - Aula 01

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 01 - PSI - Revisão

Visão Geral da Engenharia de Software, Requisitos de Software

● Descrição exercício de Revisão

Projeto de Sistemas (PSI) 2

● Atividade de Revisão disponível

Projeto de Sistemas (PSI) 3

Projeto de Sistemas (PSI) 5

● Programa de Computador + Documentação

● Cada vez mais presente no dia a dia

Projeto de Sistemas (PSI) 6

Projeto de Sistemas (PSI) 7

A Engenharia de Software é uma disciplina

● Foco no desenvolvimento de software de alta qualidade dentro

Projeto de Sistemas (PSI) 8

● Pode ser organizada em camadas com foco em qualidade

Projeto de Sistemas (PSI) 9

● Pode ser organizada em camadas com foco em qualidade

Projeto de Sistemas (PSI) 10

● Pode ser organizada em camadas com foco em qualidade

Projeto de Sistemas (PSI) 11

● Pode ser organizada em camadas com foco em qualidade

Projeto de Sistemas (PSI) 12

● Pode ser organizada em camadas com foco em qualidade

Projeto de Sistemas (PSI) 13

● Não existe um processo ideal

Projeto de Sistemas (PSI) 14

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 15

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 16

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 17

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 18

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 19

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 20

● 5 atividades são comuns no processo de desenvolvimento de

Projeto de Sistemas (PSI) 21

● Descrição simplificada do processo

Projeto de Sistemas (PSI) 22

● Modelos de Processos mais gerais

● Modelos que lidam com mudanças

Projeto de Sistemas (PSI) 23

Projeto de Sistemas (PSI) 24

● Documentação rígida (idealmente

● Reflete abordagens adotadas em outras engenharias

● Aderência a outros modelos de processo

Projeto de Sistemas (PSI) 25

● Projetos reais raramente seguem

● Em geral, é difícil para o cliente estabelecer todos os requisitos à priori

● Uma versão executável somente ficará pronta na fase final do projeto

Projeto de Sistemas (PSI) 26

Requisitos definem o que o sistema faz, nem

Projeto de Sistemas (PSI) 28

● “O sistema deve oferecer telas apropriadas…”

Projeto de Sistemas (PSI) 30

● Atributos dos Requisitos Funcionais:

Projeto de Sistemas (PSI) 31

● O usuário pode pesquisar todo ou um sub-conjunto do banco de

Projeto de Sistemas (PSI) 32

Projeto de Sistemas (PSI) 33

Projeto de Sistemas (PSI) 34