Buscar

Processos de Negocio e Software - Video Aula1

Prévia do material em texto

PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 1
Conceito da Engenharia 
de Software em Processos de Negócios
Livros Indicados
Como escolher
o melhor modelo 
de desenvolvimento 
de Software
Conhecer alguns 
Ciclos de vida de 
Software e 
o processo
Por que surgiu Engenharia de Software?
OBJETIVOS DESTA AULA
1950 a 60 (Primeira Era) 
1970 (Segunda Era)
1980 (Terceira Era)
1990 (Quarta Era)
HISTÓRICO DE SOFTWARE
INSTRUÇÕES (programas de computador) 
executados em computador 
geram informações através das 
funcionalidades
ESTRUTURAS DE DADOS que 
possibilitam que os programas 
manipulem adequadamente
a informação
DOCUMENTOS que 
descrevem a construção, 
operação e o uso dos 
programas
COMPOSIÇÃO DO SOFTWARE
Minha 
informação
Projetos e
Manuais
Executar uma função
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 2 
Características e a crise de software
Após configurado ocorre a estabilização do 
Software;
A cada modificação eleva-se os índices de 
falhas;
Ao longo do tempo a curva de falhas continua 
aumentando.
CARACTERÍSTICAS DE SOFTWARE
CARACTERÍSTICAS 
DE SOFTWARE
Dimensão espacial
O Software se deteriora
Gerentes de projetos 
sem experiências
Resistência a mudanças
CAUSAS DA CRISE DO SOFTWARE
Falta de treinamento 
contínuo
Aumento expressivo da 
demanda por Software
CAUSAS DA CRISE DO SOFTWARE
Estimativa de prazo e de custos
Produtividade das pessoas
Dificuldade em manter o Software
Qualidade de Software
CONSEQUÊNCIAS DA CRISE
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 3 
A Engenharia de Software
Em 1968, Fritz Bauer diz: “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.” (Roger 
Pressman “Engenharia de Software”)
A Engenharia de Software 
surgiu com foco em qualidade 
no processo de Software.
ENGENHARIA DE SOFTWARE
1) Aplicação de uma abordagem sistemática, 
disciplinada e quantificável ao 
desenvolvimento, operação e manutenção de 
software, ou seja, a aplicação da Engenharia 
ao Software
2) O estudo de abordagens do
tipo declarado em (1)
[IEEE]
ENGENHARIA DE SOFTWARE
Foco na Qualidade
Processo
Métodos
Ferramentas
Base fundamental
A Qualidade Total e 
outras iniciativas 
equivalentes com 
objetivo de resultar 
em mudanças 
culturais permitindo 
o avanço na 
implementação da 
maturidade na 
Engenharia de 
Software
Estrutura
Framework que permite 
atividades conscientes e 
formais, através das 
pessoas e de objetivos 
previstos em resultados 
estabelecidos para cada 
área do processo
Instrumentos
Mecanismos que integram 
metodologia, processo e tarefas 
automatizados, também 
chamado de CASE (Computer 
Aided Software Engineering)
“Como fazer”
Conjunto de Tarefas com técnicas 
particulares para cada fase do 
desenvolvimento de Software
Ao iniciar uma fase são necessários produtos da 
fase anterior;
Para realizar atividades previstas na fase, são 
necessários Metodologias 
e Recursos (humanos, hardware, software, etc);
Resultando novos produtos de 
acordo com o previsto na fase.
ELEMENTOS DO CICLO DE VIDA
FASE Produtoresultante
Produtos da
Fase anterior
Método de 
desenvolvimento
Recursos 
Necessário
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 4
Modelos de Processos (Parte 1)
Natureza da aplicação a ser desenvolvida;
Metodologia e Ferramentas a serem utilizadas;
Produto ou serviço final a ser entregue;
Complexidade da aplicação;
Disponibilidade dos envolvidos no projeto;
Quantidade de interação 
com usuários.
COMO ESCOLHER O MODELO
Chamado de Clássico ou Cascata;
Foi o primeiro modelo adotado no 
desenvolvimento de software;
O modelo mais usado na engenharia 
de software;
As fases são estabelecidas 
pelas Funções realizadas na 
engenharia convencional;
Abordagem sistemática.
MODELO SEQUENCIAL 
OU CLÁSSICO
PROJETO CODIFICAÇÃO TESTE
Engenharia de 
Sistemas/Informação ANÁLISE
Análise
Projeto
Codificação
Teste
Manutenção
Modelo original
proposto por 
Royce com feedback
Engenharia 
de sistemas
Engenharia de Sistemas
–Coletar os requisitos do sistema, quantidade 
restrita de projeto e análise de alto nível;
–Priorizar o essencial do software;
– Identificar interfaces com outros sistemas, 
banco de dados, entre outros.
MODELO SEQUENCIAL 
OU CLÁSSICO
Análise de Requisitos
–Coletar os requisitos com detalhamento;
–Priorizar o escopo de um único sistema;
–Compreender o domínio da informação, as 
regras de negócios 
e funcionalidades;
–Documentar e validar
requisitos.
MODELO SEQUENCIAL 
OU CLÁSSICO
Projeto
– Transferir o conhecimento dos requisitos 
em estrutura e arquitetura de software
Compor projeto em:
–estrutura de dados;
– arquitetura de software;
–procedimentos detalhados;
– caracterização da interface.
MODELO SEQUENCIAL 
OU CLÁSSICO
Codificação
–Transferir o conhecimento do projeto em 
programas de computador;
– Estruturar logicamente os comandos para 
atender os procedimentos especificados;
–Construção do projeto.
MODELO SEQUENCIAL 
OU CLÁSSICO
Teste
–Verificar se o software está fornecendo todas 
informações previstas nos requisitos;
– Encontrar falhas de construção;
–Garantir que todas instruções
sejam testadas.
MODELO SEQUENCIAL 
OU CLÁSSICO
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 5
Modelos de Processos (Parte 2)
Apropriado quanto o cliente não tem 
os requisitos de entradas e saídas devidamente 
definidos;
É usado como um mecanismo para identificar 
Requisitos de Software;
Criação de um modelo bem próximo 
do que o Software irá possuir;
O cliente participa ativamente
da construção e validação
do Protótipo.
MODELO PROTOTIPAÇÃO
Baseado no modelo sequencial, porém com 
características de maior velocidade;
O desenvolvimento é rápido por utilizar uma 
construção baseada em componentes;
Utilizado somente quando o escopo 
do Software é específico e restrito;
Uso de Ferramentas de 
desenvolvimento.
MODELO 4ª GERAÇÃO
Requisitos
Implementação
Projetos
Testes
MODELO 4ª GERAÇÃO
1. Requisitos são detalhados, 
com o cliente;
2. O projeto curto e consistente;
3. A geração de código são automáticas;
4. Execução de testes e 
documentação 
de uso do Software.
MODELO 4ª GERAÇÃO
Potencialmente usado para desenvolvimento 
rápido e incremental;
Liberação de versões incrementais para 
implantação;
Novas versões são complementares e-ou 
melhoradas;
MODELO ESPIRAL
1. Determinação dos objetivos;
2. Análise e tratamento dos Riscos;
3. Desenvolvimento e validação do Software;
4. Avaliação com o cliente.
MODELO ESPIRAL
Utiliza o processo iterativo;
Organização baseada no conteúdo;
–Disciplinas, papéis, artefatos, atividades;
–Processo de configuração, processo Evolutivo;
Elementos chave do RUP: Funções, Tarefas e 
Produtos de Trabalho (artefato);
Uma iteração pode incluir 
múltiplas disciplinas;
Granularidade: tarefas de 
poucas horas a poucos dias.
MODELO RUP
PROFESSORA 
POLYANNA P. GOMESFABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 6
Engenharia de Requisitos
Determinar o escopo 
do sistema;
Meio para interação 
com os usuários;
Tipos de requisitos;
Como levantar requisitos.
OBJETIVOS DESTA AULA
“Condição necessária 
para a obtenção de 
certo objetivo.”
Requisitos funcionais 
e não-funcionais.
Alternativas para melhorar 
e agilizar uma tarefa.
Alternativas para solucionar 
um problema.
DEFINIÇÕES DE REQUISITOS
Qualidade está relacionada com os Requisitos 
designados para o Software.
Não conformidades aos requisitos considera-se 
falta de qualidade.
Qualidade deve ser definida, medida, monitorada, 
gerenciada e melhorada.
Prioridade na comunicação 
e descrição do requisito.
Visão profissional da qualidade
RequisitosRequisitos Engenharia de Software
Requisitos Atendidos
Usuário Software
REQUISITOS NO PROCESSO
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 7
Análise de Requisitos
Atividade a ser executada após a definição 
do Escopo do sistema.
Desempenhada por um Analista de Sistemas, com 
apoio do Analista de Negócios 
e participação dos Usuários finais.
Gerenciar requisitos a serem 
desenvolvidos e em 
desenvolvimento.
Analisar impacto das mudanças 
de requisitos.
ANÁLISE DE REQUISITOS
Demanda em software está a cada dia mais 
específica.
Requisitos são necessidades pontuais.
Sempre deve promover a solução de 
problemas.
RECONHECIMENTO DO PROBLEMA
Não importa um bom design e uma boa 
programação, caso os requisitos não refletirem 
o que usuário necessita.
A meta é o reconhecimento dos elementos 
básicos do problema, conforme percebido pelo 
cliente.
RECONHECIMENTO DO PROBLEMA
Administrador 
do projeto
Clientes Analistas Desenvolvedores
Plano de projeto 
de Software Especificação de 
requisitos de Software
Construção do Software
REQUISITOS MAL DEFINIDOS
“O novo sistema automatizado 
traz maior velocidade aos nossos 
negócios. Vamos perder Clientes 
mais rapidamente.”
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 8
Avaliação do Problema
Avaliar o problema na situação real, ambiente 
do usuário.
Reconhecer e definir as funcionalidades 
do novo sistema.
Identificar as entradas e saídas do sistema 
(dados e informações).
AVALIAÇÃO DO PROBLEMA 
E SÍNTESE DA SOLUÇÃO
Entender o comportamento 
do sistema.
Estabelecer características 
de Interface.
Determinar as restrições do 
projeto.
AVALIAÇÃO DO PROBLEMA 
E SÍNTESE DA SOLUÇÃO
Descrição do fluxo e estrutura da informação.
Refinamento detalhado de todas funções.
Estabelecimento das características das 
interfaces.
ESPECIFICAÇÃO DE REQUISITOS
Foco em “o que” o sistema deverá contemplar, 
não em “como”.
Detalhamento das restrições.
Especificação dos critérios de validação.
Validação dos requisitos com o cliente.
ESPECIFICAÇÃO DE REQUISITOS
Para refletir
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 9
Levantamento de Requisitos
Compreende conceitos abstratos.
Capacidade de sintetizar “soluções”.
Visualizar fatos em fontes conflitantes ou 
confusas.
Entender o ambiente do usuário.
Boa comunicação verbal e 
escrita.
HABILIDADES DE UM ANALISTA
–Conhecer o problema 
e alternativas para solução.
– Exemplo de como NÃO
deve acontecer...
LEVANTAMENTO DE REQUISITOS
Eu vou subir e ver o que eles 
querem e o resto de vocês 
comecem a codificar.
Elaborar uma lista de desejos dos usuários.
Priorizar os requisitos coletados.
Conhecer detalhadamente as regras de 
negócios.
Escolher os envolvidos de acordo com escopo 
do projeto.
Sintetizar o problema.
Revisar e validar requisitos.
LEVANTAMENTO DE DADOS
Certificar-se de que está executando o 
levantamento com a pessoa certa (é oficial?).
Conhecer restrições que impedem soluções 
do problema (performance, escalabilidade, 
portabilidade, etc).
INICIANDO LEVANTAMENTO 
Vamos refletir um pouco sobre o 
assunto...
Todas informações novas são 
estimulantes, certo?
Mas nem sempre conseguimos 
aprender tudo somente nas 
reuniões...
Facilitaded Application Specification
Techniques.
Conhecida como JAD (Joint Application
Development).
Reunião em local neutro.
Participação dos Analistas 
de sistemas e do Cliente.
REUNIÃO – FAST
Deve ser elaborada um agenda dos pontos mais 
importantes.
Um moderador é designado para controlar 
a reunião.
Um mecanismo é definido (planilha, flip-chart, 
ou cartazes).
Relacionar as possíveis 
soluções para o problema.
REUNIÃO – FAST
Preparação do workshop. 
Conduzir a sessão.
Encontros no qual o analista expõe uma 
tecnologia ou cenário.
Os participantes devem conhecer e dar 
sugestões.
Consolidar resultados.
WORKSHOP
Definir o objetivo do encontro.
Gerar o maior número de ideias para o assunto.
Não permitir críticas ou debates.
Reunir e combinar as ideias.
Todos devem expressar seu voto.
Priorizar cada ideia por 
categoria.
BRAINSTORMING
Exemplo para Brainstorming
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML
PROCESSOS DE NEGÓCIO E SOFTWARE
Vídeo Aula 10
Complemento
Glossário
– Sinônimos
– Siglas
–Termos técnicos
Análise de risco
–De Projeto
– Técnico
REQUISITO – COMPLEMENTO
Protótipos e provas
– Janelas
–Relatórios
–Gráficos
– Formulários
REQUISITO – COMPLEMENTO
O que o sistema deve fazer (“o que”).
– Evidentes – o que é mostrado para o usuário 
em forma de diálogo com o sistema.
–Ocultos – o que é executado pelo sistema 
porém não é mostrado na interface com o 
usuário.
Restrições para que o requisito 
não seja atendido
REQUISITO – FUNCIONAL
Restrições colocadas sobre como o sistema 
deve realizar seus requisitos funcionais.
–Obrigatórios – devem ser obtidos de qualquer 
maneira.
–Desejados – podem ser obtidos caso não cause 
defeito no procedimento.
Restrições a nível do sistema –
ou seja, Suplementares.
REQUISITO – NÃO-FUNCIONAL
Segurança – restrições de acesso, por perfil de 
usuário à determinadas funções ou 
informações.
Performance – nível de aceitação para resposta 
a uma determinada interface.
REQUISITO – NÃO-FUNCIONAL
Compatibilidade – tipo de modem, impressora, 
moeda do país, são configuráveis.
Implementação – linguagem de programação, 
reutilização de biblioteca disponíveis (legado).
REQUISITO – NÃO-FUNCIONAL
Através de Fluxo de informação ou de 
funcionalidade.
Através de Caso de uso.
Representar as interfaces com o usuários.
REQUISITOS – REPRESENTAÇÃO 
Descrição funcional;
Descrição comportamental;
Critério de Validação;
Referências.
REQUISITOS – REPRESENTAÇÃO 
Engenharia de requisitos
http://www.inf.ufes.br/~falbo/files/Notas_Aula_
Engenharia_Requisitos.pdf
Conceitos: Especificação de requisitos
http://www.macoratti.net/07/
12/net_fer.htm
Saiba mais...
http://elearning.bizagi.com/my/
http://tiinteligente.blogspot.com.br/2012/12/c
obit-estrutura-dos-processos.html
LINK COMPLEMENTAR
PROFESSORA 
POLYANNA P. GOMES FABRIS
Especialista em
Engenharia de Software com UML

Continue navegando