Modelos e etapas do processo de software.pdf

Prof. Ivan Fontainha
ivan.alvarenga@pitagoras.com.br
Engenharia de Software

2
Bibliografia
MAITINO NETO, Roque. Engenharia de Software.
Londrina: Editora e Distribuidora Educacional S.A., 2016.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São
Paulo: Pearson, 2007
PADUA FILHO, Wilson de Paula. Engenharia de
software: fundamentos, métodos e padrões. 3. ed. Rio
de Janeiro: LTC – Livros Técnicos e Científicos, 2009
PRESSMAN, Roger S. Engenharia de software : uma
abordagem Profissional. 7ª. ed 2011.

▪ Unidade 1: Fundamentos da Engenharia de Software:
▪ O que veremos nesta aula:
▪ Seção 1.3 – Modelos e etapas do processo de software:
características, requisitos, projeto de sistema, desenvolvimento,
integração, instalação e manutenção
3

4
▪ É importante observar que a abordagem dos requisitos e
a elaboração do projeto constituem, normalmente, as
duas primeiras etapas dos modelos de software
tradicionais.
▪ Estas etapas são tidas como as mais críticas no
processo.
▪ Conforme Pressman (2011), não importa o quão bem
codificado seja, mas um programa mal analisado e mal
projetado desapontará o usuário e trará aborrecimentos
ao desenvolvedor.

5
Requisitos
▪ O dilema com o qual se depara um analista pode ser
mais bem entendido, repetindo-se a declaração de um
cliente anônimo:
▪ “Sei que você acredita que entendeu o que acha que
eu disse, mas não estou certo que percebeu que
aquilo que ouviu não é o que eu pretendia dizer...”

6
Requisitos (figura clássica)

7
Requisitos
▪ Os requisitos podem ser divididos em duas categorias
básicas :

8
Requisitos

9
Requisitos
Requisitos Funcionais:
Os requisitos funcionais
descrevem o que o
sistema deve fazer, isto
é, as funções
necessárias para
atender os objetivos do
sistema.
 Exemplos:
◦ Cadastrar Clientes;
◦ Fazer Análise de
Crédito;
◦ Fazer uma Transação
com Banco de Dados;
◦ Cadastrar um
Registro de
Atendimento;
◦ Imprimir Relatório.

10
Requisitos
Requisitos não Funcionais:
Os requisitos não funcionais
dizem respeito as
características do software,
exemplos: performance,
portabilidade, segurança,
usabilidade e etc. Estas
características descrevem
também a qualidade do
serviço.
 Exemplos:
◦ O sistema deve usar
gráficos comparativos do
aproveitamento do aluno
com a média da turma;
◦ O sistema deve usar
cores na construção dos
gráficos;
◦ As cores utilizadas
devem ser vermelho e
preto;
◦ O tempo de resposta na
elaboração do relatório
não pode ser superior a
15 segundos.

11
Regras de Negócio
▪ Regras do Negócio são declarações sobre a forma da
empresa fazer negócio.
▪ Elas refletem políticas do negócio.
▪ Organizações têm políticas para satisfazer os objetivos
do negócio, satisfazer clientes, fazer bom uso dos
recursos, e obedecer às leis ou convenções gerais do
negócio.

12
Regras de Negócio
▪ As regras de negocio representam o comportamento da
organização dentro do sistema.
▪ É a regra de negócio que especifica as
particularidades das funcionalidades a serem
desenvolvidas.
▪ As regras de negocio ajudam a entender o
funcionamento da empresa e obviamente o
funcionamento do sistema.

13
Regras de Negócio
▪ As regras de negocio tem relação com o comportamento
da organização e desejável que este comportamento
seja refletido no sistema.
EXEMPLO:
▪ Ao se cadastrar no nossa loja física todo cliente tem que
apresentar um CPF valido;
▪ No desenvolvimento do sistema durante o cadastro
do cliente obrigatoriamente ele tem que possuir um
CPF valido.

14
Como Diferenciar
▪ Requisitos Funcionais?
▪ São ações que o meus sistema tem que
apresentar;
▪ Requisitos não Funcionais ?
▪ São características do meu sistema.
▪ Regras de Negocio?
▪ Normalmente tem haver com o problema em si e
não ao sistema.

16
Exercícios
▪ Grupos de até 5 alunos
▪ Cada grupo deve definir um sistema a ser desenvolvido
▪ Cada sistema deve ter:
▪ 10 requisitos funcionais
▪ 5 requisitos não funcionais
▪ 5 regras de negócio
▪ Apresentação em XX minutos – iremos discutir
requisitos de alguns grupos.
▪ Inserir as requisitos e regras de negócio no formulário:
https://forms.gle/Xs589YH92ajN91ue6

17
Requisitos de Software
▪ A área de requisitos de software preocupa-se com o
levantamento, análise, especificação e validação das
propriedades que devem ser apresentadas para resolver
tarefas relacionadas ao software em desenvolvimento.
▪ Requisitos são a expressão mais detalhada sobre aquilo
de que o usuário ou cliente precisa em termos de um
produto de software.
▪ Além das funcionalidades, eles relacionam-se também
aos objetivos, restrições e padrões do sistema.

18
▪ Os requisitos de software expressam as necessidades e
restrições colocadas num produto de software que
contribuem para a solução de algum problema do
mundo real.
▪ São subetapas da fase de requisitos:
▪ Levantamento de requisitos,
▪ Análise dos requisitos,
▪ Especificação dos requisitos de software.

19
▪ Levantamento de requisitos:
▪ Devemos determinar o que o cliente precisa, em
vez do que o cliente quer.
▪ É comum que os clientes não sabem o que
realmente precisam ou tenham dificuldade de
expressar.
▪ É importante conhecer o campo de aplicação, isto
é, a área geral em que o software será aplicado.
▪ Deve-se conhecer as regras (ou modelos) de
negócio do cliente, pois trata-se da descrição dos
processos que compões o negócio da
organização.

20
▪ Técnicas de levantamento de requisitos:
▪ O levantamento de requisitos é atividade
essencialmente humana.
▪ Requer habilidade em trabalhar com especialistas
humanos e com o conhecimento tácito, que é trivial
para quem conhece a informação, mas não é trivial
para quem procura obtê-la.
▪ Algumas técnicas que facilitam este trabalho:
▪ Entrevista,
▪ Aplicação de questionário.

21
▪ Entrevista:
▪ A entrevista deve ser planejada antes da sua
aplicação.
▪ Objetivos devem ser fixados.
▪ Local e roteiro definidos.
▪ Entrevistados devem ser criteriosamente
escolhidos.
▪ A interação entre entrevistado e entrevistador
deve buscar revelar conceitos, objetos e a
organização do domínio do problema, além de
buscar soluções ou projeções de soluções que
comporão o domínio da solução.

22
▪ Aplicação de questionário:
▪ Geralmente é aplicado em formulário distribuído
para os futuros usuários do sistema.
▪ Seu elaborador deve utilizar questões diretas e
objetivas, dispostas preferencialmente na
mesma ordem para todos os participantes e que
consigam extrair deles respostas sobre o
procedimento atual adotado.

23
▪ Outras técnicas de levantamento de requisitos:
▪ Análise de documentos,
▪ Observações pessoais,
▪ Reuniões estruturadas.

24
Análise de Requisitos
▪ É a fase que vem logo após a fase de levantamento de
requisitos ser concluída.
▪ Os requisitos são analisados e classificados e, como
resultado, serão divididos principalmente em requisitos
funcionais e não funcionais.
▪ Os requisitos são divididos em funcionais e não
funcionais.

25
Especificação de Requisitos de Software
▪ Refere-se a produção de um documento contendo os
requisitos levantados e analisados, que podem ser
sistematicamente revistos, avaliados e aprovados.
▪ Estabelece um contrato entre cliente e desenvolvedor.
▪ Escrito em linguagem natural, forma base realista para
estimativas de custos, riscos e cronograma.

26
Especificação de Requisitos de Software
▪ Uma boa especificação de requisitos de software pode
propiciar diversos benefícios aos clientes e demais
envolvidos no projeto:
1. Estabelecer a base para a concordância entre
clientes e fornecedores, naquilo que o software
deve produzir;
2. Reduzir o esforço para o desenvolvimento.
(revisão minimiza possibilidade de erros)
3. Fornecer base para estimativa de custos e
agendas.
4. Fornecer uma linha de base para validação e
verificação.

27
Validação dos Requisitos
▪ É a última fase do processo.
▪ Deve incidir sobre o documento de especificação.
▪ Podemos usar algumas perguntas para esta validação:
▪ O que fizemos é o que deveria ser feito?
▪ O produzido, corresponde aos requisitos?

28
▪ É a última fase do processo.
▪ A validação serve para assegurar que o engenheiro
compreendeu os requisitos e se estes são
compreensíveis, consistentes e completos.
▪ A participação do cliente é fundamental
▪ A revisão é feita por profissionais designados para
assegurar que não há no documento falta de clareza,
sentido dúbio e desvio dos padrões.

29
▪ Uma maneira eficaz de validar os requisitos é pela
prototipação.
▪ Prototipação é a criação de uma versão
simplificada de determinadas funções do sistema,
▪ É indicada para capturar a real compreensão do
engenheiro em relação aos requisitos levantados.
▪ O comportamento de uma interface de usuário é
melhor compreendida através de um protótipo

30
Projeto de Software
▪ É o primeiro passo da fase de desenvolvimento de
qualquer produto ou sistema de engenharia.
▪ Meta é produzir modelo ou representação do produto a
ser construído.
▪ O projetista deve lançar mão de sua experiência,
intuição e metodologias consagradas.
▪ Modelos ou representações podem ser analisados
quanto a sua qualidade e são base para as etapas de
codificação, teste, validação e manutenção.

31
Projeto de Software
▪ Projeto é o processo pelo qual os requisitos são
traduzidos numa representação do software.
▪ A avaliação da qualidade de um projeto implica que ele
deve:
▪ exibir uma organização hierárquica do software,
▪ ser modular,
▪ haver distinção entre dados e procedimentos.

32
Projeto de Software
▪ O nível de detalhamento deve ser suficiente para
permitir sua realização física e, de acordo com o modelo
de processo tradicional.
▪ O projeto se inicia depois de levantados, analisados e
especificados os requisitos.
▪ Os aspectos fundamentais de um projeto são:
▪ Abstração,
▪ Abstração de dados,
▪ Modularidade,
▪ Procedimento de Software.

33
Projeto de Software
Os aspectos fundamentais de um projeto:
▪ Abstração:
▪ Abstrair é concentrar-se em certos aspectos
relevantes ao ambiente do problema.
▪ Cada passo da Engenharia de Software diminui o
nível de abstração em direção à solução do
problema.
▪ O nível mais baixo de abstração é o código-fonte.
▪ Uma solução modular leva a vários níveis de
abstração.

34
Projeto de Software
▪ Abstração de dados:
▪ É a coleção de dados que descreve um objeto.
▪ Devemos abstrair os dados e uni-los em um
objetivo comum
▪ Exemplo:
▪ o contra cheque é referenciado pelo conjunto de
dados do funcionário.
▪ Ele contém o nome do funcionário, salário, valor
do imposto de renda e contribuição sindical.

35
Projeto de Software
▪ Modularidade:
▪ É divisão do software em componentes chamados
módulos.
▪ Permite a administração intelectual do software, já
que um grande software monolítico (composto por
apenas um módulo) é praticamente
incompreensível.
▪ O desafio é dimensionar a quantidade de módulos
a serem construídos.

36
Projeto de Software
▪ Procedimento de Software:
▪ Focaliza os detalhes de processamento de cada
módulo da hierarquia.
▪ O procedimento oferece especificação precisa do
processamento do módulo.
▪ Descreve o que deve ser feito por cada módulo, e
o que deve ser produzido.

Modelos e etapas do processo de software.pdf

Mais conteúdo relacionado

Mais procurados

Semelhante a Modelos e etapas do processo de software.pdf

Último

Modelos e etapas do processo de software.pdf