ICO 001 - Introdução À Computação - Desenvolvimento de Sistemas PDF

Introdução à Computação
Visão Geral de Desenvolvimento de

sistemas e Engenharia de Requisitos
CURSO SUPERIOR DE TECNOLO GIA EM

ANÁLISE E DESENVOLVIMEN TO DE
SISTEMAS
(ADS)
Prof. MSc. Fábio Xavier
IFBA Eunápolis ADS

OBJETIVOS DO MÓDULO
 Dar uma visao geral da atividade de Desenvolvimento de

Sistemas
 Explicar a importância da Engenharia de Requisitos
 Abordar conceitos da TI relacionados à Engenharia de
Requisitos
 Mostrar prática e ferramentas de requisitos
IFBA Eunápolis - ADS 2

Conteúdo do Módulo
1 Desenvolvimento Sistemas
2 Engenharia de Software
3 Engenharia de Requisitos
4 Requisitos de sistemas
5 Estudo de Caso
6 Ferramentas

Conteúdo do Curso
1 Desenvolvimento Sistemas

Conceitos
 Análise de Sistemas
 Engenharia de Software
 Ciclo de Vida de um Software
 Metodologias de Desenvolvimento
 Processo de Software
 Problemas no Desenvolvimento de Software
 Modelagem
 Introdução à UML
5
Análise x Engenharia
 Evolução acompanha a evolução do Hardware

 Engenharia de software tornou mais robusto o
conhecimento de Análise inicialmente existente
 Engenheiros são profissionais preparados em
matemática, ciências e tecnologia para construir
produtos que são importantes para a segurança e
bem-estar da sociedade.
 A meta da engenharia de software é a produção de
software livre de falhas entregue no tempo e no
orçamento, que satisfaça as necessidades dos
usuários
6
Engenharia de Software
7
Ciclo de Vida
 Modelos são representações formais dos sistemas em

um nível de abstração;
 Nos modelos de análise, o nível de abstração é mais
alto e detalhes do modelo são omitidos;
 Os modelos de projeto possuem menor nível de
abstração e, portanto, contém detalhes suficientes
para permitir sua implementação em uma linguagem
de programação.
8
Ciclo de Vida
 Análise
 Projeto
 Implementação
 Testes
 Manutenção
9
Metodologias de Desenvolvimento
 Estruturada
 Cascata
 Em paralelo
 Rápidas (RAD)
 Cíclicas
 Protótipos
 Ágeis
 XP
10
Processo
 É o “caminho” que deve ser seguido para o efetivo

desenvolvimento do software;
 O processo descreve a estrutura para o
desenvolvimento do SW, descrevendo os artefatos a
serem produzidos e os passos que devem ser
seguidos para produzi-los;
 Em alto nível, o processo descreve o ciclo de vida do
desenvolvimento e as iterações que ocorrem dentro
dele.
11
Problemas no Desenvolvimento de SW
Sintomas Causas Melhores Práticas
• Necessidades não • Requisitos • Gerenciamento

atendidas Insuficientes Interativo
• Requisitos • Comunicação • Gerenciamento de
Expirados Inadequada Requisitos
• Módulos sem • Arquitetura Frágil • Gerenciamento da
integração • Complexidade Qualidade
• Difícil Manutenção absurda • Arquitetura
• Descoberta tardia de • Testes pobres adequada e
falhas • Avaliação Subjetiva componentizada
• Baixa Qualidade • Adoção de “Cascata” • Modelagem Visual
• Baixa Performance inadequadamente adequada (UML)
• Falta de • Mudanças não
entendimento entre controladas
desenvolvedores
12
Modelagem
 Décadas de 50/60
 Sistemas mais simples, modelagem mais simples
 Desenvolvimento com pouco planejamento
 Fluxogramas e Diagramas de Módulos
 Década de 70
 Maior acesso aos computadores
 Avanço computacional
 Programação estruturada, projeto estruturado
 Década de 80
 Barateamento das máquinas
 Maior interface homem-máquina
 Análise Estruturada Moderna
13
Modelagem
 Década de 90
 OO: Novo paradigma de modelagem
 Suprir necessidades de algumas dificuldades da Análise

Estruturada
 A partir do final da década de 90
 Maturidade da Orientação a Objetos
 Padrões de projeto, frameworks, componentes e qualidade

ganham espaço
 Surge a UML – Unified Modeling Language
14
Orientação a Objetos
 Abstração
 Encapsulamento
 Polimorfismo
 Generalização (Herança)
 Composição
15
UML
 Foram aproveitadas as melhores características das

notações OO existentes.
 Os 3 amigos: Booch, Rumbaugh e Jacobson
 A empresa Rational
 Aprovada em 1997 pela OMG – Object Management
Group, consórcio internacional de empresas que
define e ratifica padrões da OO (HP, Digital, IBM,
Oracle, Microsoft, Unisys entre outras)
 Grande aceitação de desenvolvedores de todo o
mundo
16
Visões de um Sistema
 Perspectivas de um sistema de software
Visão de
Visão de Projeto
Implementação
Visão de
Casos de Uso
Visão de Processo Visão de Implantação
17
Diagramas da UML
Objetos
Classes
Estruturais
Pacotes
Componentes
Implementação
Diagramas Implantação.
Casos de Uso
Sequência
Atividades
Comportamentais Temporização
Interação
Colaboração
Transições de
Estados
Visão Geral da
Interação. 18
1 – Introdução
DÚVIDAS SOBRE ESTA PARTE 1 ?

Conteúdo do Curso
2 Engenharia de Software
UNIFACS - Pós-Graduação em BD com ênfase em Alta Disponibilidade – Engenharia de Requisitos 20

2 – Conceitos
2.1 – Elementos da Engenharia de Software

2 – Conceitos
2.2 – Fatores da Qualidade de Software
Fatores da Qualidade de Software

Fonte: Adaptado de Pressman, Roger S. - 1995 - p. 726
Todos os itens acima citados podem fazer parte da lista de requisitos a

ser definida.

2 – Conceitos
2.3– Estratégia de aquisição de Software
Desenvolvimento de sistemas personalizados

OU
Aquisição de sistemas prontos
OU
Terceirização no desenvolvimento de sistemas
INDEPENDENTE DA ESTRATÉGIA ADOTADA,

OS REQUISITOS DEVEM ESTAR BEM
DEFINIDOS.

2 – Conceitos
2.4 – Fases do Desenvolvimento de Sis
 Fases que devem estar presentes no desenvolvimento de

sistemas, independente da metodologia:
1. O Estudo Preliminar que fornece uma visão global e genérica do
projeto, sistema ou software concebido, com a primeira definição dos
requisitos e objetivos.
2. A Análise do Sistema Atual, que permita levantar informações para
verificar as vantagens e desvantagens na organização das informações.
3. O Projeto Lógico que mostra o que o sistema ou software fará.
4. O Projeto Físico que permite o planejamento do ambiente em que o
sistema irá operar.
5. O Projeto de implantação que prevê o treinamento e capacitação do
cliente e determina detalhes da entrega do produto.
Reflita: O que envolve o BD?

2 – Conceitos
2.5 – Atividades da Criação de Sis
 Atividades são comuns na maioria dos processos de SW existentes:

1. Análise de sistemas, que concentra esforços em todos os elementos do
sistema, não apenas no software, identificando as necessidades dos
usuários, a análise econômica, a viabilidade técnica e a existência de
restrições de prazos e custos;
2. Análise de requisitos, que avalia necessidades dos usuários quanto ao
sistema que está sendo desenvolvido ajudando a levantar elementos que
são problemáticos, a refinar os dados de entrada e saída e a aprimorar os
modelos;
3. Projeto, uma fase onde são construídos modelos e representações do
sistema que será desenvolvido;
4. Codificação, que é a etapa em que o software é efetivamente construído.
5. Teste, que representa uma etapa crucial para a garantia da qualidade do
sistema que está sendo desenvolvido;
6. Manutenção, que envolve todas as modificações feitas no software depois
de pronto.
Reflita: O que envolve o BD?

2 – Conceitos
2.6 – Metodologias de Desenvolvimento de Sis
(Metodologia Estruturada – Em Cascata)
Planejamento
Análise
Projeto
Implementação
Testes

2 – Conceitos
(Metodologia Estruturada – Em Cascata)
 A metodologia em cascata faz com que analista e usuários prossigam no

desenvolvimento do sistema seguindo em seqüência de uma fase para
outra.
 É interessante observar que os resultados importantes de cada fase são
registrados e apresentados ao responsável pelo projeto para a aprovação ou
não à medida que o processo de desenvolvimento passa de uma fase para
outra.
 Se o projeto for aprovado e a fase que gerou a documentação é considerada
finalizada, e uma nova fase de desenvolvimento é iniciada. Um dos
problemas do desenvolvimento em cascata é o de voltar para uma fase
anterior, sendo um procedimento extremamente complicado.
 Vantagem:
 Identifica os requisitos do sistema antes da programação ser iniciada e permite que as
alterações destes requisitos sejam reduzidas à medida que o projeto prossegue.
 Desvantagem:
 O projeto deve ser completamente especificado no papel antes da programação ser iniciada,
e também exige um longo tempo entre a fase de análise do sistema e a sua entrega, levando
muitas vezes meses ou anos.

2 – Conceitos
(Metodologia Estruturada – Em Paralelo)
Planejamento
Análise Análise Análise
Projeto Projeto Projeto
Implementação Implementação Implementação
Testes

2 – Conceitos
(Metodologia Estruturada – Em Paralelo)
 Tem como principal objetivo o tratamento dos longos

atrasos que existem entre as fases de análise e a entrega
do sistema. O desenvolvimento em cascata divide a fase
de projeto em subprojetos distintos que são conduzidos
em paralelo.
 Depois de concluídos todos os subprojetos, são feitas
integrações das partes que estão separadas.
 Vantagem:
 Reduz o tempo necessário para a entrega do sistema.
 Desvantagem:
 Na maioria das vezes os subprojetos não são totalmente
independentes.

2 – Conceitos
(Modelo Espiral de Barry Boehm, 1988 )

2 – Conceitos
(Metodologia RAD – Em Fases)
 O desenvolvimento em fases tem como característica a divisão do sistema

em várias versões que são desenvolvidas seqüencialmente. Na análise é
identificada a equipe de desenvolvimento, os usuários e os conceitos do
sistema e o responsável pelo projeto fica encarregado de toda a
categorização dos requisitos, sendo que os requisitos mais importantes do
sistema são agrupados na sua primeira versão.
 Depois de agrupados todos os requisitos, é feita a implementação dos
mesmos gerando a primeira versão do sistema. Depois de gerada a
primeira versão, são iniciados os trabalhos para o desenvolvimento da
segunda versão, sendo combinadas novas idéias e questões que foram
surgindo com as experiências adquiridas na primeira versão dos sistemas.
 Trabalhar em fases/versões é uma característica abordada também pelos
conhecidos Processos Iterativo, Espiral ou Incremental que possuem a
mesma idéia e pequenas adaptações.
 Vantagem:
 Coloca rapidamente uma versão útil do sistema em poder dos usuários.
 Desvantagem:
 O usuário começa a trabalhar com um sistema incompleto.

2 – Conceitos
(Metodologia RAD – Protótipos)
 No protótipo as fases de análise, projeto e implementação são executadas

simultaneamente e em ciclos até que o sistema esteja completamente
concluído.
 A análise e o projeto do sistema são executados iniciando-se rapidamente a
construção de um protótipo do sistema. Esse protótipo fornece ao usuário
uma quantidade mínima de recursos, sendo normalmente a primeira parte
que o usuário irá trabalhar, e nele são abordadas questões de revisão das
tarefas realizadas até o momento, que fornecerá subsídios para a versão
definitiva.
 Esse ciclo será continuo e só é encerrado quando o sistema está
completamente concluído. Depois que o protótipo é instalado, ocorrem
refinamentos até que ele seja reconhecido realmente como um sistema.
 Vantagem:
 Fornece rapidamente um sistema onde os usuários poderão interagir.
 Desvantagem
 A construção rápida de um protótipo do sistema desafia todas as tentativas de condução de
uma análise criteriosa.

2 – Conceitos
(Metodologia Ágil – XP)
 O desenvolvimento XP faz parte do quadro de

desenvolvimentos ágeis possuindo como característica
básica a codificação simples, sendo que toda essa
codificação é sempre testada por dois desenvolvedores.
 Além da codificação simples, as interações com os
usuários são mais curtas com o intuito de construir
rapidamente um sistema.
 O XP requer um maior grau de disciplina na sua
aplicação a fim de evitar que o projeto perca totalmente o
seu foco e torne-se um caos total. A equipe de
desenvolvimento em XP deve ser reduzida, não sendo
recomendada a sua aplicação em sistemas de grande
porte.

2 – Conceitos
(observações)
 As metodologias RAD e Ágeis são as que se encontram mais

comumente em uso na atualidade. Processos bem estruturados
baseados em conceitos cíclicos e incrementais, dominam o
mercado. O maior exemplo é o processo denominado Rational
Unified Process - RUP, que é adaptado atualmente em muitas
empresas.
 Isto não significa o fim das metodologias estruturadas, mas mostra
a tendência atual do mercado de informática.
 Em tecnologia da informação, mais especificamente na área de
engenharia de software, há um termo constantemente repetido que
diz que não há "bala de prata", solução definitiva e única.
 Para escolher a metodologia adequada, é importante ter em mente
que não há solução completamente adequada. A análise que deve
ser feita pelos envolvidos no projeto, depende da avaliação de
vantagens e desvantagens de cada uma das técnicas, de acordo com
as expectativas da organização que deseja implantar o sistema.

2 – Conceitos
(Quadro Comparativo)
Figura 2 - Comparação das metodologias

Fonte: Adaptado de Soares, Michel S. - Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. p.8-13

2 – Conceitos
2.8 – Modelos de Aquisição de Serviços de TI
 Qual a melhor solução tecnológica e ser adotada?

 Verificar a estrutura organizacional da empresa e da
área de TI. Esta estrutura é responsável por
desenvolver soluções, vender produtos, gerir
prestadores de serviços entre outras
responsabilidades.
 Proporcionar inteligência empresarial é condição
indiscutível dos sistemas pretendidos por uma
organização.
 Entender que a área de TI deve possuir uma
estrutura capaz de avaliar e definir os objetivos e a
forma de atuação dos prestadores de serviços se a
terceirização de atividades ocorrer.

2 – Conceitos

 Evitarreservar o conhecimento nas mãos de
poucos.
 Atentar para os perfis dos recursos humanos
disponíveis.
 Buscar a redução de custos e aumento da
competitividade, ao se evitar muitas vezes, dar
atenção a uma área que não é atividade fim.

2 – Conceitos

 Impedir o vazamento de informações estratégicas
para a concorrência com competência e sigilo do
prestador de serviço.
 Perceber que a Terceirização em TI pode
englobar diversas subáreas relacionadas ao
processamento de dados, como por exemplo,
serviços de hospedagem de soluções ou aluguel
de infra-estrutura e energia, com equipamentos
do contratante.

2 – Conceitos
2.8 – Modelos de Aquisição de Sistemas/Serviços de TI
 Opções para aquisição de sistemas/serviços:

 Desenvolvimento de sistemas/serviços personalizados
 Conheço os requisitos?
 Custo é Acessível (custo/benefício)?
 Necessito de solução específica (ou estarei reinventando a roda)?
 Pessoal é qualificado para
desenvolvimento/implantação/manutenção (usuários e técnicos)?
 Tenho Tempo disponível (pessoal e prazo)?

2 – Conceitos

 Aquisição de sistemas/serviços prontos (COTS)
 Atende minha necessidade (conheço o produto)?
 Empresa é confiável (conheço histórico/outros produtos)?
 Possuo pessoal qualificado para a implantação/manutenção?
 Garantia, Escopo e Prazos estão bem definidos contrato?
 Segurança é adequada?

2 – Conceitos

 Terceirização no desenvolvimento de sistemas /
prestação de serviços
 Plataforma tecnológica que possuo é adequada (BD/Redes/SOs)?
 Empresa é confiável (conheço histórico/outros produtos)?
 Empresa possui pessoal qualificado para a
implantação/manutenção?
 Garantia, Escopo e Prazos estão bem definidos em contrato
 Segurança é adequada?

2 – Conceitos
2.9 – Controles na Área de TI
Para minimizar erros, desastres, interrupções de serviço,

cibercrimes e violações de segurança, políticas e procedimentos
especiais devem ser incorporados ao projeto e à implementação
dos sistemas de informação. A combinação de medidas manuais
e automáticas para salvaguardar os SIs e assegurar que
funcionem segundo padrões administrativos é denominada
controle. Os controles consistem portanto, em todos os métodos,
políticas e procedimentos organizacionais que garantem a
segurança dos ativos das organizações, a precisão e
confiabilidade de seus registros contábeis e a adesão operacional
aos padrões administrativos.
(O'BRIEN, 2001, p. 467)

2 – Conceitos
2.9 – Controles na Área de TI (cont.)
 O controle dos sistemas deve ser capaz de atender aos seguintes itens:
 Proteção de Bens;
 Conferência da exatidão e da fidelidade dos dados contábeis;
 Promoção da eficiência operacional;
 Estímulo à obediência das diretrizes administrativas estabelecidas.
 O controle é freqüentemente classificado como contábil ou administrativo. Os

parâmetros do controle interno contábil atendem:
 Fidelidade das informações em relação aos dados (Confiabilidade)
 Segurança Física
 Segurança Lógica
 Confidencialidade
 Obediência à legislação em vigor
 O controle administrativo trata de assuntos referentes mais a gestão e estratégia das

organizações, conforme descrito a seguir:
 Eficiência
 Eficácia
 Obediência às diretrizes da alta administração

2 – CONCEITOS
2.9 – Resumindo Viabilidades Técnicas de Sis
 É neste estudo de a viabilidade que é feita toda a avaliação técnica do projeto, destacando até
em que ponto o sistema deverá ser elaborado, desenvolvido e instalado com total sucesso.
 Um dos riscos que pode comprometer totalmente a conclusão do sistema é a familiaridade de

usuários e analistas com o novo sistema que está sendo desenvolvido.
 A viabilidade tecnológica analisa se poderão existir problemas com a nova tecnologia que está
sendo implantada na construção do sistema, o que pode conseqüentemente causar atrasos e
riscos.
 É importante avaliar também o porte do projeto levando em conta o tamanho da equipe de

desenvolvimento, o tempo que será necessário para a sua conclusão, o número de recursos
distintos. Quanto maior o projeto, maior é a possibilidade de riscos, pois existe um grau de
complexidade maior e com isso alguns dos requisitos do sistema podem ser mal compreendidos
ou ignorados.
 A existência de uma integração entre os sistemas já existentes e o sistema novo que está sendo
desenvolvido pode ser outra dificuldade encontrada devido à existência de possíveis
incompatibilidades.
 Os profissionais de TI da empresa são os responsáveis por verificar se o sistema é viável ou não

no ponto de vista técnico.

2 – CONCEITOS
2.9 – Resistência de Usuários aos SIs
• Aversão às mudanças, hábitos

Resistência naturais.
Natural • Expectativas diferentes da Possíveis causas e
conseqüência real dos novos SIs.
comportamentos de
• Disputa de poder e relações de
resistência na
Fatores influência. contribuição para a
Políticos • Mudanças nos cargos e salários. construção de um
novo sistema, e
conseqüentemente,
• A perda da importância do colaborador no
contexto da organização que se dá através da na participação
Status disseminação do conhecimento entre vários ou
novos colaboradores. como fonte de
informação na
coleta de fatos e
• Medo de ser demitido. requisitos.
Insegurança

2 – CONCEITOS
2.10 – Motivação para equipes de desenvolvimento
Hierarquia de Necessidades de Maslow.

Adaptação encontrada em http://www.brandme.com.br/publico-alvo/

2 – CONCEITOS
• A mudança tecnológica de caráter revolucionário exerce coerção sobre as organizações –

ela exige inovação. Não se trata de apenas aperfeiçoar os processos, mas de repensar a
própria organização. Drucker (1971) alerta que nada poderia ser menos produtivo do que
tornar mais eficiente aquilo que não deveria estar sendo feito. As perguntas devem ser
sobre quais as tarefas que devem ser executadas e por que devem sê-lo.
• Para sobreviver e prosperar em um ambiente turbulento, torna-se crítico gerenciar o
conhecimento de fora para dentro, e não apenas de dentro para fora. É preciso ampliar a
colaboração, o compartilhamento, o aprendizado, para além das fronteiras da organização.
A value chain (cadeia de valor) em que a organização está inserida está mudando muito
rapidamente, e uma das mais poderosas forças que movem (e provocam) as mudanças é a
tecnologia da informação e suas aplicações.
• Uma nova organização deve ser fundada em um ambiente onde as organizações e as
pessoas estão conectadas em rede (internetworking), onde a colaboração deverá suplantar
a rivalidade e a competição predatória, como chave para um desenvolvimento sustentável
dos negócios e da sociedade. Convênios para ações cooperativas, descritas por Cunha
(1999) para bibliotecas, poderão se tornar usuais entre organizações públicas.
Motivações e fatores críticos de sucesso para o planejamento Motivações e fatores críticos de sucesso para o planejamento de sistemas interorganizacionais na
sociedade da informação de sistemas interorganizacionais na sociedade da informação
Henrique Flávio Rodrigues da Silveira

2 – CONCEITOS
• Hammer (1997) afirma que a essência do gerenciamento de um negócio é o gerenciamento

de seus processos. Seria factível admitir, então, que não caberá mais às organizações
gerenciar apenas seus próprios processos, mas participar ativamente da gestão dos
processos da cadeia produtiva em que estão envolvidas, o que estaria de acordo com
Chiavenato (1998), que destaca a crescente importância da administração sem fronteiras.
• As motivações identificadas na revisão de literatura (compartilhamento de informações;
aumento de produtividade; redução de custos; determinação superior, legal ou normativa e
incremento do relacionamento com os clientes/usuários) atendem às inquietações dos
gestores quanto à racionalização do uso de recursos e ao aumento de produtividade.
• Quanto aos fatores críticos de sucesso identificados na revisão de literatura (custo,
segurança, habilidade de cooperação, efeitos internos, apoio superior), pode-se afirmar que
há suficiente desenvolvimento tecnológico para minimizar as questões relativas à
segurança, confidencialidade e integridade das informações, a custos compatíveis com os
benefícios esperados.
Motivações e fatores críticos de sucesso para o planejamento Motivações e fatores críticos de sucesso para o planejamento de sistemas interorganizacionais na
sociedade da informação de sistemas interorganizacionais na sociedade da informação
Henrique Flávio Rodrigues da Silveira

2 – CONCEITOS
DÚVIDAS SOBRE A PARTE 2 ?

3 Engenharia de Requisitos

3 – Engenharia de Requisitos
Objetivos do Capítulo
Definir Conceitos da Engenharia de Requisitos
Estudar Técnicas de Elicitação


Indo além do balanço requisitado !!!
http://www.devmedia.com.br/artigo-engenharia-de-software-introducao-a-engenharia-de-requisitos/8034

Requisitos do Negócio
Quem decide pela aquisição de um sistema tem

requisitos que geram valor para a organização.
Os colaboradores responsáveis pela tomada de

decisões possuem requisições relacionadas às suas
práticas de negócio ou novas práticas que desejam
adotar para minimizar custos e maximizar ganhos.
Há sensíveis diferenças entre estes requisitos e os

requisitos dos usuários mas deve-se entender que
os requisitos de negócio estão em um nível mais
alto/estratégico e menos técnico.

Requisitos do Sistema
Sentenças que expressam as

necessidades dos clientes e que
condicionam a qualidade do software.
Sentenças que indicam o que o sistema

deve fazer mas não como deve ser feito.
Condição ou capacidade que deve ser

atingida pelo sistema para satisfazer
uma solicitação.

Negócio x Sistema
Exemplo:
Caixa Eletrônico
Sistema Negócio
• Solicitar que cliente insira o cartão • Prover acesso seguro em locais e horários
• Ler dado criptografado da tarja magnética convenientes aos clientes
• Solicitar senha • Confirmar identidade dos clientes
• Verificar senha digitada • Permitir ao cliente executar transações
• Aceitar envelopes com depósitos bancárias de maneira rápida e confiável
• Processar pagamentos • Permitir registro que evidencie transações
bancárias
• Entregar dinheiro
• Imprimir extratos
• Proceder transferência entre contas

Pontos de Atenção
Requisitos de
Requisitos de Negócio
Sistemas só são
e Requisitos de
importantes quando
Sistema não são a
atingem os Requisitos
mesma coisa
do Negócio
Sistemas são
insatisfatórios quando
atingem os Requisitos
do Negócio

Requisitos do Requisitos do
Negócio Sistema
Visão do Linguagem Já existe no Visão do Linguagem Criado por

Conceitual Concreto
Negócio do Usuário negócio Produto Operacional alguém

Não Requisitos
Funcionais
Funcionais Inversos
Expressam
restrições que o
Diretamente Estabelecem
software deve
ligados à condições que
atender ou
funcionalidade do nunca podem
qualidades
software. ocorrer.
específicas que o
software deve ter.

Detalhamento dos Requisitos
O projeto de um produto não é uma decomposição de

Requisitos de Negócio.

Detalhamento dos Requisitos
O correto é detalhar cada tipo de Requisito (Negócio /

Sistema) de acordo com a necessidade.

Afinal, o que são Requisitos ?
Requisitos de Negócio são sentenças que compõem uma visão caixa-preta de um

sistema que são detectáveis pelo mundo exterior. Fazendo uma Analogia, uma TV
é uma caixa-preta.
Como ela é vista exteriormente pelos espectadores?
Como um equipamento que transmite divertimento através de uma programação.
E na visão do E na visão do Engenheiro

Engenheiro Eletrônico ? de Telecomunicações ?
E na visão do E na visão da rede

Anunciante ? de Televisão ?
E na visão do fabricante
do aparelho ?
Fases da Análise de Requisitos
Validação/
Verificação
• Buscar por falta de
coerência, concisão ou
clareza nos requisitos
elicitados e reescrevê-los
Elicitação se encontrado. Modelagem/
• Tarefa de comunicar com Registro
clientes e usuários para • Documentar requisitos
verificar seus na forma de linguagem
requerimentos. natural , de nodelos
gráficos (DFD, MER,
casos de uso, Etc) ou de
especificação de
processos (fluxos).
Análise de
Requisitos

Análise de Requisitos x Engenharia de Requisitos

Como Trabalhar com Requisitos
Requisitos devem ser

compreendidos de
forma coesa;
Mudanças de
requisitos devem ser
Sistemas Expectativas dos
clientes devem ser
gerenciadas. gerenciadas com
(Rational,2000) eficácia;
Requisitos realmente
devem refletir as
necessidades dos
clientes;

O Profissional de Requisitos
Capacidade de compreender conceitos abstratos, reorganizá-los em

divisões lógicas e sintetizar soluções destas divisões
Capacidade de absorver fatos provenientes confusas
Capacidade de absorver ambientes dos usuários/organização
Capacidade de se comunicar bem nas formas escrita e verbal
Capacidade de associar elementos de hardware e software às necessidades

do cliente
Capacidade de focar na necessidade global sem antecipar detalhes,

descobrindo funções de cima para baixo.

Necessidade X Solução
A História dos Burrinhos (1/4)




Elicitação de Requisitos
Forma x Conteúdo
Requisitos tendem a ser hierárquicos. Vamos rever o caso

do caixa eletrônico ?
Sistema Negócio
• Solicitar que cliente insira o cartão • Prover acesso seguro em locais e horários
• Ler dado criptografado da tarja magnética convenientes aos clientes
• Solicitar senha • Confirmar identidade dos clientes
• Verificar senha digitada • Permitir ao cliente executar transações
• Aceitar envelopes com depósitos bancárias de maneira rápida e confiável
• Processar pagamentos • Permitir registro que evidencie transações
bancárias
• Entregar dinheiro
• Imprimir extratos
• Proceder transferência entre contas

Fontes de Informação
Fontes de
Informação
Indivíduos Sistemas Textos
Usuários Desenvolvedores Documentos Livros Artigos

Registro Textual – Pontos de Atenção
Requisitos devem
ser na linguagem Requisitos devem
que o usuário ser claros
entenda
Os analistas de Requisitos entendem
Programadores também os acham
realmente esta linguagem para
claros ?
modelar adequadamente ?
Usuários não sabem o que querem
Usuários também não acham perda de

tempo conversar com pessoal de TI ?

Exemplos de Palavras que indicam Requisitos Inverificáveis
Amigável
• Número máximo de passos
• Lista de funcionalidades presentes em outras aplicações
• Menus ou prompts para auxiliar usuários
Portável
• Dimensões
• Requisitos mínimos de hardware
• Sistemas operacionais em que deve funcionar
Pequeno
• Dimensões aceitáveis (em número de Bytes)
• Volume de Dados
Flexível
• Variáveis que podem acomodar uma gama de mudanças de valores
• Funções que implementam uma de várias possibilidades

Técnicas / Métodos
3.1 •Entrevista
3.2 •Questionário
•Observação e Análise
3.3
Social (Etnografia)
3.4 •Leitura de Documentos
3.5 •Análise de Cenários
3.6 •Prototipagem

Técnicas - 3.1 - Entrevista
 Gerencie a Entrevista. 3.1

 Planeje. Direcione. Organize. Controle.
 Vantagem
 Ótima técnica para conhecer sobre o presente.
 Desvantagem
 Não tão boa para identificar metas e pontos críticos.
 Pergunte tudo contanto que focado.
 O que? Por que? Quem? Como? Onde? Quando?
 Comunique-se de acordo com ambiente.
 Entrevistado. Público. Cultura. Diversidades.
 Documente.
 Não perca nenhum detalhe. Padronize. Formate.

Técnicas - 3.1 - Entrevista
 Seleção de Entrevistado 3.1

 Quem melhor pode citar o trabalho e problemas atuais?
 O entrevistado foi nomeado para a função? É o mais recomendável?
 Escolha das perguntas
 Depende de quando e para quem.
 Não deixe de perguntar sobre questões críticas / de stress.
 Nem tudo pode ser feito por observação/questionário/etc.
 Ex.: Volumes de Dados
 Improvisos serão necessários
 Registre mesmo questões imprevistas.
 Grupos podem ser entrevistados

 Balancear participação dos participantes durante o processo.
 Acessórios
 Gravadores podem ser usados se autorizadas.

Técnicas - 3.2 - Questionário
3.2
 Gerencie o Questionário
 Vantagem
 Bom para obter respostas diretas
 Desvantagem
 Falta de motivação pode gerar resultados inadequados
 Pergunte o necessário
 Parametrize. Verifique necessidade de Anonimato.
 Avalie detalhadamente após respondidos

 Resultados podem utilizar análises estatísticas

Técnicas - 3.2 - Questionário
3.2
 Objetividade pode ser problema
 Há risco de não entender bem através de questões fechadas
 Questões abertas devem ser limitadas

 Para obtenção de boas e direcionadas análises
 Testes devem existir

 Pequenos grupos podem servir de pré-avaliação.
 Os que respondem podem não entender as perguntas
 Os que perguntam podem não entender as respostas
 Mistura de Técnicas
 Usar mais técnicas pode ser adequado

Técnicas - 3.3 - Observação
 Gerencie a Observação 3.3

 Muitas pessoas não conseguem descrever o que fazem.

 Quando se pergunta, pode se obter respostas lógicas mas erradas.
 Não é o caso de mentir deliberadamente. O normal é que se

interessem o máximo pela qualidade das respostas.
 Observações são muitas vezes mais rápidas e exatas para se
obter aprendizado.
 Compare os manuais de eletrônicos/Livros de Receitas com
observações.
 Os processos reais de trabalho geralmente diferem daqueles
processos formais descritos.

 Etnografia é uma técnica usada em outras áreas 3.3

 Um etnógrafo passa algum tempo observando pessoas no trabalho e
constrói uma imagem de como o trabalho é realizado.
 Organize regularmente seções de relato, onde o etnógrafo fala para
pessoas externas ao processo.
 Relações de Confiança
 Gaste algum tempo conhecendo as pessoas e estabeleça um bom
relacionamento mútuo.
 Escutando Etnógrafos
 Nem sempre o responsável pela observação é o que descreve os
requisitos
 Tome nota de forma detalhada de todas as práticas de trabalho.
Analise-as e chegue a uma conclusão a partir delas
 Combine etnografia com outras técnicas de elicitação.
 Acessórios 3.3
 Câmeras podem ser usadas se autorizadas.
 Facilitam a revisão em conjunto com indivíduos observados.
 Situações Críticas nem sempre são observáveis

 Cuidados da equipe são aumentados durante observação
 Necessárias coincidências para captar exatamente momentos

críticos.
 Etnografia é uma técnica usada em outras áreas
 Nas Ciências Sociais se mostrou útil no entendimento dos processos
reais realizados nos trabalhos.
 Útil para se buscar formas não padronizadas de trabalho.

Técnicas - 3.4 – Leitura de Documentos
 Gerencie o procedimento de Leitura. 3.4

 Vantagem
 Detalhes podem ser aprendidos.
 Às vezes as dicas ou observações não nos ensinam a operar um
eletro-eletônico.
 Desvantagem
 Demanda tempo e disponibilidade da Fonte.
 Legado
 Excelente para informação “antiga”.
 Variedade de Fontes
 Formulários, Livros, Memorandos, Portarias, Leis, Documentação de
sistemas existentes.

Técnicas - 3.4 – Leitura de Documentos
 Cuidados com a Relevância 3.4
 Quais documentos e/ou informações são realmente

pertinentes?
 Confiabilidade
 Como foram criados estes documentos? Ainda são utilizados?
 Origem do Documentos
 Quem utiliza? De que forma? Com que freqüência?
 Segurança
 Trate adequadamente material sigiloso
 Adaptações
 O que pode ser eliminado? O que pode ser modificado

Técnicas - 3.5 – Análise de Cenários
 Cenários são estórias que explicam como um sistema poderá ser 3.5
usado.
 Imaginemos que (esta é a idéia) ...
 Cenários são exemplos de sessões de interação que descrevem como o usuário
interage com o sistema.
 A descoberta de cenários expõe interações possíveis do sistema e revela as
facilidades que o sistema pode precisar.
 Registre adequadamente
 Necessário saber o estado do sistema antes de começar o cenário
 O fluxo normal de eventos do cenário exceções ao fluxo normal de eventos
 Informações sobre atividades concorrentes
 Descrição do estado do sistema ao final do cenário
 Cenários na UML
 Cenários são partes inerentes de alguns métodos de desenvolvimento orientados
a objeto.
 O termo “caso de uso” ou use-case (um caso específico do uso do sistema) é
usado para se referir a um cenário.

Técnicas - 3.6 – Prototipagem
 O que é um Protótipo ? 3.6

 Versão simplificada de um sistema final, que dá idéia de funcionamento real.
 Design
 Ajuda Usabilidade
 Comunicação
 Testa Tempos de Resposta .
 Utilidade como Requisitos
 Usuários poderão experimentar o “sistema” e mostrar os pontes fortes e
fracos
 Força um estudo detalhado dos requisitos, revelando problemas
 Agilidade
 Desenvolvimento rápido dos protótipos é essencial para que eles fiquem
disponíveis logo para o processo de elicitação.
 Documentação
 Como pode ser usado para teste do sistema pode ajudar a documentação.

Técnicas / Métodos
Há muitas outras técnicas existentes:

Brainstorm, Reuso e Requisitos, Modelagem de Processos,
Análise de Risco, Análise de Custo-Benefício e etc...
O mais importante é conhecê-las detalhadamente e aplicá-las
para cada situação indicada.

Infra-estrutura
Espaço para Películas em

Mesas e Cadeiras Iluminação
equipes Vidraças
Computadores e DVD
Câmeras Microfones
monitores player/recorder
Software de Ambiente
Scanner Projetor
captura de tela acústico
Cabeamento / Monitores para Quadro Espaço de

Rede sem fio Reunião Branco/Avisos Armazenamento

Adaptação à Cultura Organizacional
Cliente do Cliente do
Mundo Mundo
Oriental Ocidental
Comunicação Comunicação
Implícita Direta
Autoritário Democrático
Herárquico Igualitário
Coletivismo Individualismo

DÚVIDAS SOBRE O CAPÍTULO 3 ?

4 Requisitos de Sistemas
UNIFACS - Pós-Graduação em BD com ênfase em Alta Disponibilidade – Engenharia de Requisitos 91

4 – Requisitos em Sistemas
Controle x Requisitos
A idéia aqui é esclarecer que os requisitos são muito

mais abrangentes que as funcionalidades definidas
pelos usuários.
O analista deve atentar para questões de infra-estrutura

de banco, de redes de comunicação, de servidores, de
qualificação de pessoal técnico e usuários.
Serão abordados como exemplo aspectos de

levantamento a respeito de um Banco de Dados.

4 – Requisitos em Sistemas
Controle x Requisitos
Avaliando Técnicas de Controle e Procedimentos que

podem ser usados em atividades de fiscalização de
bancos de dados nas organizações, podemos elucidar
quais aspectos merecem atenção na Engenharia de
Requisitos.
A Idéia deste capítulo não é somente trabalhar com requisitos nos SIs que
estão sendo desenvolvidos.
A Intenção é ajudar a planejar, elicitar e suportar requisitos específicos

relacionados ao funcionamento da área de Banco de Dados, promovendo
eficiência e eficácia do desempenho.

4 – Requisitos em Banco de Dados
4.1 - Controles da administração de dados
Coordenação da manutenção dos dados (definição,

criação, exclusão e propriedade dos dados);
• Quem é o responsável?
Estabelecimento de políticas de acesso,

confidencialidade e integridade de dados;
• Quem terá que ter acesso?
Manutenção da documentação;
• Quem e Como se fará a documentação?

4.1 - Controles da administração de dados
Coordenação entre administração de dados, usuários e

programação;
• Como está prevista esta integração?
Desenvolvimento e manutenção de padrões.

• Como, De que Maneira e Por quem ?
Observância de padrões e métodos para o desenvolvimento de

aplicações que utilizam BDs
• Qual?
Registro das atividades de administração de dados armazenados

em históricos
• Em que formato e Por quem ?

4.2 - Controles da administração do SGBD
Projeto e manutenção da estrutura da base de

dados;
• Estrutura é suficiente? Até quando? Necessário Crescimento?
Quando?
Revisão e avaliação da confiabilidade do SGBD

• Há Erros relatados? Solicitações dos sistemas estão sendo bem
atendidas?
Avaliação do pessoal que tenha acesso ao SGBD

• Há autorização? É revista periodicamente?
4.2 - Controles da administração do SGBD
Treinamento dos DBAs

• Qualificação é adequada?
Segurança dos dados.

• Acessa quem realmente pode (Usuários e Administração do BD)?
Registro das atividades dos DBAs

• LOGs adequados?
Plano de treinamento em linguagens de acesso aos BDs aos

Analistas desenvolvedores
• Analistas de Sistemas/Desenvolvedores estão qualificados?

4.3 - Controles de Acesso ao BD
O uso das facilidades do gerenciador de banco de dados é limitado ao pessoal com

atribuições compatíveis com esse acesso?
Existem mecanismos para restringir o acesso a arquivos de dados e ao dicionário de dados

(senhas, tabelas e perfis de segurança), impedindo o acesso a pessoas não autorizadas?
O acesso ao software e às tabelas de segurança do SGBD e aos perfis de segurança do

dicionário de dados é limitado?

4.3 - Controles de Acesso ao BD
Foram estabelecidos procedimentos de autorização de acesso ao banco de dados, que são

cumpridos?
São produzidos registros históricos de acesso e atualização, bem como trilhas de auditoria
que possibilitem investigar o acesso e atualização a elementos da base de dados?
O gerenciador de banco de dados controla o acesso simultâneo aos elementos de dados e

possui mecanismos para prevenir processamento incorreto nessas situações?

4.4 – Controle de Acesso ao Dicionário
Há consistência entre as estruturas de dados do

banco de dados e do dicionário de dados.
O dicionário de dados contém os elementos

necessários, tais como:
• data de criação e última atualização;
• descrição de cada elemento de dados;
• chaves utilizadas;
• estrutura de cada elemento de dados (qual registro lógico
contém o elemento);
• programas e sistemas que utilizam cada elemento de dados e
de que forma.
4.4 – Controle de Acesso ao Dicionário
Há procedimentos estabelecidos para produção

de cópias de segurança (backup) e recuperação
do dicionário de dados.
São mantidas trilhas de auditoria que permitam

supervisionar mudanças nos dicionários de
dados.
A alteração e a criação de novos nomes de

arquivos e descrição de dados são controladas e
seguem padrões e políticas predefinidos.
4.5 - Disponibilidade e recuperação
Existência de políticas e procedimentos que garantam a disponibilidade do banco

de dados e sua pronta recuperação após a ocorrência de falhas operacionais ou
desastres.
Há regras estabelecidas para o tratamento da Continuidade do Serviço.
Procedimentos de backup de hardware e software asseguram a disponibilidade

da base de dados para as aplicações consideradas prioritárias, em caso de redução
da capacidade de operação.

4.5 - Disponibilidade e recuperação
Existem nós ou caminhos alternativos de acesso para bancos de dados acessados

via rede.
Foram estabelecidos procedimentos para recuperação lógica e física do ambiente

de banco de dados, e são obedecidos.
Os procedimentos de recuperação são periodicamente testados e atualizados.

4.6 - Integridade do banco de dados
Existem procedimentos para avaliar o desempenho do banco de dados.
O gerenciador de banco de dados apresenta elementos de controle sobre

a organização, o acesso e o compartilhamento de dados.
Existem mecanismos de controle sobre a integridade dos dados, das

rotinas e do dicionário de dados do sistema gerenciador de banco de
dados.

4.6 - Integridade do banco de dados
O sistema gerenciador de banco de dados mantém um controle das

mudanças realizadas na base.
O gerenciador de banco de dados estabelece controles sobre atividades de

pesquisa, atualização de aplicativos, funções de SGBD e dicionário de
dados.

UML e Requisitos de BDs
Material Complementar: UML

DÚVIDAS SOBRE A PARTE 4 ?

5 Estudo de Caso

5 – Estudo de Caso
Documentação a
ser apresentada
em Sala

5 – Estudo de Caso
DÚVIDAS SOBRE O CAPÍTULO 5 ?

6 Ferramentas

6 – Ferramentas
Ferramentas Serão Demonstradas em Sala de Aula.

6 – Ferramentas
DÚVIDAS SOBRE A PARTE 6?

Engenharia de Requisitos
CONTATO
fabiosxavier@yahoo.com.br

Introdução à Computação
Prof. MSc. Fábio Xavier

ICO 001 - Introdução À Computação - Desenvolvimento de Sistemas PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

ICO 001 - Introdução À Computação - Desenvolvimento de Sistemas PDF

Caricato da

Copyright:

Formati disponibili

Introdução à Computação

Visão Geral de Desenvolvimento de

CURSO SUPERIOR DE TECNOLO GIA EM

Prof. MSc. Fábio Xavier

IFBA Eunápolis ADS

 Dar uma visao geral da atividade de Desenvolvimento de

IFBA Eunápolis - ADS 2

IFBA Eunápolis - ADS 3

IFBA Eunápolis - ADS 4

 Evolução acompanha a evolução do Hardware

 Modelos são representações formais dos sistemas em

 É o “caminho” que deve ser seguido para o efetivo

Sintomas Causas Melhores Práticas

• Necessidades não • Requisitos • Gerenciamento

 Suprir necessidades de algumas dificuldades da Análise

 Padrões de projeto, frameworks, componentes e qualidade

 Foram aproveitadas as melhores características das

 Perspectivas de um sistema de software

Visão de Processo Visão de Implantação

DÚVIDAS SOBRE ESTA PARTE 1 ?

IFBA Eunápolis - ADS 19

UNIFACS - Pós-Graduação em BD com ênfase em Alta Disponibilidade – Engenharia de Requisitos 20

IFBA Eunápolis - ADS 21

Fatores da Qualidade de Software

Todos os itens acima citados podem fazer parte da lista de requisitos a

IFBA Eunápolis - ADS 22

Desenvolvimento de sistemas personalizados

INDEPENDENTE DA ESTRATÉGIA ADOTADA,

IFBA Eunápolis - ADS 23

 Fases que devem estar presentes no desenvolvimento de

Reflita: O que envolve o BD?

IFBA Eunápolis - ADS 24

 Atividades são comuns na maioria dos processos de SW existentes:

IFBA Eunápolis - ADS 25

IFBA Eunápolis - ADS 26

 A metodologia em cascata faz com que analista e usuários prossigam no

IFBA Eunápolis - ADS 27

Análise Análise Análise

Projeto Projeto Projeto

Implementação Implementação Implementação

IFBA Eunápolis - ADS 28

 Tem como principal objetivo o tratamento dos longos

IFBA Eunápolis - ADS 29

IFBA Eunápolis - ADS 30

 O desenvolvimento em fases tem como característica a divisão do sistema

IFBA Eunápolis - ADS 31

 No protótipo as fases de análise, projeto e implementação são executadas

IFBA Eunápolis - ADS 32

 O desenvolvimento XP faz parte do quadro de

IFBA Eunápolis - ADS 33

 As metodologias RAD e Ágeis são as que se encontram mais

IFBA Eunápolis - ADS 34

Figura 2 - Comparação das metodologias

IFBA Eunápolis - ADS 35

 Qual a melhor solução tecnológica e ser adotada?

IFBA Eunápolis - ADS 36

 Qual a melhor solução tecnológica e ser adotada?

IFBA Eunápolis - ADS 37

 Qual a melhor solução tecnológica e ser adotada?

IFBA Eunápolis - ADS 38

 Opções para aquisição de sistemas/serviços:

IFBA Eunápolis - ADS 39

 Opções para aquisição de sistemas/serviços: