Análise de Sistemas: Conceitos e Modelagem com UML

Objetivo da Disciplina

• Apresentar os conceitos básicos de análise e
modelagem de sistemas e a importância
destas práticas para os projetos de software.
Análise e Projeto de Sistemas • Apresentar parâmetros de comparação que
possibilitem a identificação da técnica
adequada para cada projeto.
• Capacitar o aluno a elaborar projetos
Aula expositiva 01 detalhados de sistemas através de técnicas
de análise praticadas no mercado, em
especial a Análise Orientada por Objetos
Professor José Luiz Bastos com a utilização do padrão UML (Unified
Modeling Language) e seus diagramas de
representação.
© 2008 José Luiz G. Bastos Jr. © 2008 José Luiz G. Bastos Jr.

Ementa da Disciplina Ementa da Disciplina
1. FUNDAMENTOS DA ANÁLISE DE SISTEMAS 3. ANÁLISE ORIENTADA A OBJETOS E PADRÃO
1.1 Análise de sistemas e ciclo de vida dos sistemas. UML
1.2 Modelagem de sistemas. 3.1 Conceitos básicos da orientação a objetos.
1.3 Evolução da análise de sistemas. 3.2 Os três pilares da orientação a objetos.
3.3 Linguagem de modelagem unificada – UML.
2. ENGENHARIA DE REQUISITOS 3.4 Modelos da UML.
2.1 Técnicas envolvidas
2.2 Dificuldades 4. MODELAGEM DE SISTEMAS ATRAVÉS DA UML
2.3 Especificação e documentação 4.1 Diagrama de Casos de Uso.
4.2 Diagrama de Classes.
4.3 Diagrama de Seqüência de Casos de Uso.


Ementa da Disciplina Análise de Sistemas - Motivação
5. MODELAGEM DE SISTEMAS ATRAVÉS DA UML • Por que analisar? Por que não começar logo pela
5.1 Diagrama de Colaboração. implementacão?
5.2 Diagrama de Estados. • Análise de sistemas:
– A análise de sistemas é um processo de análise detalhada
5.3 Diagrama de Atividades.
das necessidades de informação de uma organização, das
características e dos componentes dos sistemas de
informação atualmente utilizados (se existirem) e dos
requisitos dos sistemas de informação sendo propostos.
– Trata da análise detalhada dos componentes e requisitos
de um sistema.
• Objetivos da Análise de Sistemas:
– Padronizar, minimizar a redundância, evitar a ambigüidade e
reduzir a manutenção corretiva das
especificações do sistema.


1

Análise de Sistemas - Visão Geral Análise de Sistemas - Visão Geral

• Sistema? Sistemas de Informações
– Um grupo de itens que interagem entre si ou que
sejam interdependentes, formando um todo unificado,
orientado para atender objetivos específicos. • Um sistema de informações é um conjunto
– Um conjunto organizado de doutrinas, idéias ou de elementos inter-relacionados, processos,
princípios, habitualmente previstos para explicar a dados e tecnologia, cuja finalidade é
organização ou o funcionamento de um conjunto
alimentar os centros de decisões com as
sistemático.
– Exemplos:
informações necessárias à escolha de
• Sistema gravitacional diretrizes de ação que permitam atingir os
• Sistema digestivo objetivos da organização.
• Sistema rodoviário
• Sistema bancário



• Dados: Componentes de um Sistema de
Informações:
– São seqüências ordenadas de símbolos dos quais se
pode extrair informações. Porém, não contêm nenhum
significado quando analisados isoladamente.
• Hardware;
• Software;
• Informações: • Pessoas;
• Dados;
– São dados tratados, analisados ou processados, • Procedimentos.
capazes de transmitir algum conhecimento ao
receptor.


Classificação quanto à forma de processamento: Classificação quanto à forma de processamento:

• Sistemas em Tempo Real
• Sistemas Batch – Controla um ambiente pelo recebimento de dados, seu
– O usuário normalmente não interage com o computador por processamento e apresentação dos resultados com rapidez
terminal e as informações são processadas em lotes, de suficiente para afetar o ambiente naquele momento.
forma seqüencial.
• Sistemas Baseados em Conhecimento
– Esses sistemas estão associados ao campo da inteligência
• Sistemas On-Line artificial. Contêm grande quantidade de conhecimentos
– O usuário interage com o computador por terminal, os dados variados para utilização em determinadas tarefas.
de entrada são fornecidos diretamente do local onde eles
foram criados e os resultados do processamento são • Sistemas Especialistas
dirigidos diretamente para onde sejam necessários. – São sistemas baseados em conhecimento. Têm embutidos
o conhecimento e a capacidade que os tornam capazes de
funcionar como um especialista.


2


Classificação quanto ao nível organizacional:
Sistemas de Processamento de Transações

Nível operacional;
Apoia operações rotineiras da empresa;
Registra transações;
Origem dos dados: operações internas;
Grau de agregação dos dados: dados analíticos, reais
e precisos;
Volumes manipulados: grandes;
Saídas: relatórios analíticos, alguns sintéticos;
Freqüência: periódica;
Exemplos: faturamento, estoque, contabilidade etc.



Sistemas de Apoio à Decisão
Sistemas de Planejamento e Controle Operacional
Nível tático (média gerência);
Nível tático (supervisão);
Apoia processos decisórios;
Apoia o planejamento e controle operacional;
Trabalha com análise matemática e estatística dos
Coleta informações sobre o realizado e compara com
dados;
o previsto;
Origem dos dados: operações internas e fontes
Origem dos dados: operações internas;
externas;
Grau de agregação dos dados: médio;
Grau de agregação dos dados: alto;
Volumes manipulados: médios;
Volumes manipulados: pequenos;
Saídas: relatórios consolidados;
Saídas: gráficos e tabelas;
Freqüência: periódica;
Freqüência: a pedido (ad hoc);
Exemplos: custos, planejamento e controle de
Exemplos: análise de investimentos, análise estatística,
produção, planejamento e controle de projetos.
simulação de cenários.


Sistemas de Planejamento Estratégico Princípios Gerais dos Sistemas:

Nível estratégico (alta administração); • Quanto mais especializado é um sistema,
Apoia análise de fatores críticos de sucesso da menos capaz ele é de se adaptar a
empresa: desempenho, mercado e concorrência; circunstâncias diferentes;
Trabalha com projeções a longo prazo e tendências • Quanto maior for um sistema, maior o
do mercado;
número de seus recursos que serão
Origem dos dados: operações internas e fontes
destinados à manutenção diária;
externas;
Grau de agregação dos dados: alto; • Os sistemas sempre fazem parte de
Volumes manipulados: pequenos; sistemas maiores e sempre podem ser
Saídas: gráficos e tabelas sofisticados; divididos em sistemas menores;
Freqüência: a pedido (ad hoc); • Os sistemas CRESCEM.
Exemplo: sistemas de informações executivas.

3

Análise de Sistemas - Mais definições Problemas
• “A análise de sistemas é frustrante, repleta de relacionamentos
entre pessoas, indefinida e difícil. Resumindo, é fascinante.
• Depende da clareza do usuário:
Depois que você é fisgado, os velhos e fáceis prazeres da – É ele o responsável por mostrar ao analista, de
construção de sistemas nunca mais serão suficientes para maneira clara, quais requisitos o sistema deve
satisfazê-lo.” (DeMarco, 1989) atender.
• “Análise de sistemas é a atividade que tem como finalidade
realizar estudos de processos a fim de encontrar o melhor e • Depende do entendimento do analista:
mais racional caminho para que a informação possa ser
processada.” (Wikipedia) – É ele o responsável por identificar e analisar os
requisitos esperados pelo usuário.
• Análise de sistemas consiste em identificar, detalhar e – Deve documentar de forma clara o seu trabalho, para
documentar os processos de negócio para sua automatização que os consumidores do mesmo saibam identificar os
junto aos usuários. Essa análise deve produzir como resultado
requisitos esperados pelos usuários.
uma especificação completa de tudo que o sistema de
informação deve realizar.


Solução

• Técnicas para identificação e detalhamento
de requisitos

• Técnicas para modelagem de sistemas


Usuários Usuários

• Principais participantes do processo:
– O sistema está sendo desenvolvido PARA ELES. Cada projeto possui um elenco diferente de pessoas
– O sistema automatizará os processos de negócio envolvidas. Um analista de sistemas precisa ter aptidões
executados POR ELES. interpessoais (além do conhecimento da tecnologia), ou
– Comprometimento dos usuários é fundamental para o seja, deve falar com outras pessoas usando uma
sucesso do projeto “linguagem” diferente.


4

Usuários Usuários

Classificação por Tipo de Função
O analista de sistemas deve fazer reuniões regulares
com os usuários (também chamados de clientes ou
Operacionais
proprietários). O ideal seria ter um usuário dedicado
integralmente ao projeto. Alguns defendem que o usuário Têm visão local, isto é, não conhecem o processo de
deveria fazer o projeto. forma global;

Responsáveis por executar as funções do sistema;

Têm uma visão física do sistema, ou seja, imaginam o
funcionamento do sistema considerando a tecnologia de
implementação.


Usuários Usuários

Supervisores
Executivos
Podem ou não ter uma visão local;
Não têm experiência operacional;
Geralmente conhecem as operações, pois muitos já
Têm iniciativa sobre o projeto;
foram usuários operacionais. Além disso, têm que
supervisionar os usuários operacionais;
Possuem uma visão global;
Orientados por considerações orçamentárias (ex.:reduzir
Têm preocupações estratégicas;
o quadro de funcionários ou aproveitá-los melhor);
Capazes de lidar com modelos abstratos.
Normalmente, agem como intermediários em relação aos
níveis mais elevados.


Usuários Usuários

Classificação por Nível de Experiência
Novato arrogante
Amador
Participou de alguns projetos;
Nunca trabalhou com um computador;
Possui ou trabalha com computadores;
Tem dificuldade para entender os modelos produzidos
pelos analistas; Por conhecer algumas ferramentas, gosta de opinar
sobre as tecnologias a serem usadas para implementar
Receia ser substituído pelo sistema ou ter sua o sistema (normalmente, tem certeza que opina certo,
importância minimizada. mas opina errado!).


5

Usuários Usuários
Classificação quanto ao conhecimento de
tecnologia:
Experiente – Baixo:
• Não compreende a linguagem técnica
Conhece a análise de sistemas; – Médio
• Tem algum conhecimento tecnológico
Tem experiência de outros projetos;
• Pode perder o foco e se preocupar com a solução
tecnológica
Discute sobre as ferramentas de modelagem sendo
utilizadas. – Alto
• Tem um bom conhecimento tecnológico
• Pode perder o foco e se preocupar muito com
solução tecnológica


Equipe do Projeto Equipe do Projeto

Gerente de Projeto Auditores, Controle de Qualidade e
Padronizadores
As principais funções de um gerente de projeto são:
Podem ser internos ou externos. Responsáveis por
Gerenciar e alocar recursos de toda a equipe técnica; garantir que o sistema será desenvolvido de acordo com
os vários padrões internos e externos da organização,
Prestar constas junto à administração superior;
especialmente aqueles voltados à segurança e ao
Encaminhar problemas identificados no decorrer do controle de qualidade do produto final.
projeto;

Gerentes de níveis mais altos se concentram nos aspectos
mais abstratos do sistema.


Equipe do Projeto
Equipe do Projeto

Alguns problemas dos Auditores que devem ser Analistas de sistemas
considerados:

Normalmente não se envolvem no projeto até que ele tenha sido • Analisam, detalham e documentam os
concluído. Nesse ponto, modificar o sistema é muito mais difícil; processos de negócios que serão
Às vezes não estão habituados com a notação utilizada;
automatizados
• Ajudam os usuários a encontrarem as
Geralmente, estão mais interessados na forma do que na
substância. soluções mais apropriadas
• Atuam como mediadores entre os diversos
Verificam conformidades com padrões:
Padrões governamentais
participantes do processo
Padrões internos da empresa
Padrões do processo de desenvolvimento


6


Um analista de sistemas deve ter: O analista desempenha as seguintes funções:

Mediador: como os usuários dificilmente chegam a um consenso, o
Habilidade de relacionamento social; analista deve usar a arte da diplomacia e da negociação. O sistema
deve ser feito da forma como os usuários solicitaram;
Conhecimento da tecnologia; Líder de projeto: Como o analista entrou antes no projeto,
freqüentemente também é o projetista e normalmente é uma pessoa
Conhecimento dos processos de negócio mais experiente, existe uma tendência natural de que ele assuma o
papel de gerente de projeto.

Mente lógica e organizada (visualizar o
sistema sob diferentes perspectivas), ou seja,
raciocínio lógico e abstrato


Projetistas de Sistemas
Arqueólogo e escriba: deve trazer à luz os detalhes e
documentar as atividades cujos detalhes passam de geração em • Arquitetos do sistema
geração de usuários;
• Recebem o resultado do trabalho dos analistas de sistemas
Inovador: não se limitar apenas a implementar as funções
atuais do sistema mas ajudar a encontrar produtos e mercados • Usam os requisitos levantados para desenhar a arquitetura do
novos; sistema que servirá de base para o trabalho dos
programadores
• Interação constante com os analistas
• Podem verificar a inviabilidade de alguns requisitos



Projetistas de Sistemas
Programador
• O analista de sistemas deve fornecer informações
suficientemente detalhadas para que o projetista elabore um • Responsável por codificar e testar (usando uma
projeto tecnologicamente bom. linguagem de programação) os módulos dos sistemas
modelados pelos projetistas.
• O projetista deve fornecer informações suficientes para que o
analista possa dizer se os requisitos dos usuários podem ser • Em um cenário ideal, o programador não deveria ter
completamente atendidos ou devem ser modificados. contato com o analista, já que se baseia apenas no
trabalho feito pelo projetista.

• Há programadores que são responsáveis apenas por
dar manutenção em um sistema.


7


Programador

Segundo Zvegintzov (1987) - (autor do artigo Software
Maintenance News):

Até o presente momento, o principal profissional da computação era alguém que podia
aprender o suficiente sobre as necessidades das empresas para expressá-las na
linguagem dos computadores. No futuro, quando nossa sociedade tornar-se
irreversivelmente computadorizada, o principal profissional será alguém que possa
aprender o suficiente sobre sistemas computadorizados para expressá-los em linguagem
humana. Sem essa pessoa, teremos perdido o controle de nossa sociedade. Esse alguém
é o engenheiro às avessas. Os mantenedores de software são os engenheiros às avessas
da sociedade.


Equipe do Projeto Ciclo de vida de um projeto

• Mais integrantes? Definição:

– Testadores • “Um ciclo de vida de projeto bem definido
– Analistas de usabilidade oferece mecanismos para planejar e
– Engenheiros de processo
acompanhar atividades de forma mais
– Gestores de configuração
precisa, possibilitando a detecção de
– E por aí vai...
problemas de forma rápida (YOURDON,
1990)”.


Etapas do ciclo de vida clássico Questões

1) Quais são os problemas do ciclo de
desenvolvimento de sistemas apresentado
na figura acima? De que forma esses
problemas podem ser solucionados ou pelo
menos minimizados?
2) Esse ciclo de vida pode ser considerado
realístico para projetos de software? Por
quê?
3) De que forma a fase de análise interfere e
sofre interferência das outras etapas?


8

Etapas do ciclo de vida de Fases
desenvolvimento de software
Concepção Fase na qual necessidades dos usuários e conceitos da
aplicação são analisados o suficiente para justificar a
especificação de um produto de software, resultando em uma
proposta de especificação.

Elaboração Fase na qual a especificação do produto é detalhada o
suficiente para modelar conceitualmente o domínio do
problema, validar os requisitos em termos deste modelo
conceitual e permitir um planejamento acurado da fase de
construção.

Construção Fase na qual é desenvolvida (desenhada, implementada e
testada) uma liberação completamente operacional do
produto, que atende aos requisitos especificados.

Transição Fase na qual o produto é colocado à disposição de uma
comunidade de usuários para testes finais, treinamento e uso
inicial.


Fluxos Modelos de ciclo de vida
Requisitos Visa obter um conjunto de requisitos de um produto,
Modelo Codifica-Remenda:
acordado entre cliente e fornecedor.

Análise Visa detalhar, estruturar e validar os requisitos, em termos
de um modelo conceitual do problema, de forma que estes
possam ser usados como base para o planejamento e
acompanhamento detalhados da construção do produto.

Desenho Visa formular um modelo estrutural do produto, que sirva de
base para a implementação, definindo os componentes a
desenvolver e a reutilizar, assim como as interfaces entre
eles.
Implementação Visa detalhar e implementar o desenho através de
componentes de código e de documentação associada.

Testes Visa verificar os resultados da implementação, através do
planejamento, desenho e realização de baterias de testes.


Modelos de ciclo de vida Modelos de ciclo de vida

Modelo Codifica-Remenda: Modelo em cascata:
• As fases são executadas em estrita
sequencia
• Provavelmente o mais usado
• Pouco realiza, não permite erros
• Não exige sofisticação técnica ou gerencial
• Pontos de controle bem definidos facilitam
• Alto risco gestão
• Impossível de gerir • Teoricamente é confiável e utilizável em
• Não permite assumir compromissos projetos de qualquer escala
confiáveis • Rígido e burocrático
• Baixa visibilidade para o usuário, que só
recebe o resultado no final do projeto


9


Modelo em cascata com realimentação: Modelo em espiral:
• E possível voltar à fase anterior
• Mais fexível



Modelo em espiral: Modelo de entrega evolutiva:
• Software é desenvolvido em uma série de
iterações • Combinação entre o modelo de Espiral e
• Cada nova iteração é um novo ciclo na Cascata
espiral
• Construção é feita de forma incremental
• Utilizado em processos ágeis, como o XP


Projeto – Empresas de pequeno porte Projeto – Empresas de grande porte

• Normalmente é iniciado após um acordo • Existe um processo formal de engenharia de
verbal entre os usuários e a equipe do software
projeto • Existem meios para verificar se o processo
• O desenvolvimento é feito logo após esse está sendo seguido
acordo verbal, geralmente sem a existência • Todos conhecem o processo
de análise. • O gerente é o responsável por organizar o
• Geralmente não existe um processo de projeto de acordo com o processo
desenvolvimento formal. Se existe,
geralmente não é seguido ou verificado.


10

Modelos Modelos

• A criação de um modelo corresponde à • É a partir das especificações dos clientes e
utilização de uma linguagem que possa ser usuários que os modelos serão construídos e
empregada por analistas e compreendida por a partir dos modelos que o produto será
usuários, para representar um sistema. desenvolvido, portanto, o envolvimento do
• Os modelos são os principais produtos da cliente é de fundamental importância nesta
análise e são fundamentais para se obter um etapa. Os modelos podem ser utilizados
produto de software de qualidade, dentro de também para a validação inicial do produto, o
prazos e custos preestabelecidos. que os torna ainda mais importantes.


Modelos

Observação Importante:

• Um analista de sistemas, além de saber Análise e Projeto de Sistemas
construir modelos, deve se aprofundar no
que está sendo modelado, seja um sistema
de matrícula, vendas, controle de estoque,
bancário, etc. Durante a modelagem, o Aula expositiva 02
analista muitas vezes se torna um
especialista na área.
Professor José Luiz Bastos


Fatores de insucesso em projetos de
Premissas
software
Por que os projetos de software são cancelados antes de serem concluídos?
Para desenvolver sistemas úteis, de alta qualidade e
que realmente satisfaçam as necessidades dos Fator de insucesso % dos projetos
usuários, é necessário considerar os seguintes Requisitos incompletos 13,1
aspectos: Falta de envolvimento dos usuários 12,4
Falta de recursos 10,6
Produtividade; Expectativas não-realistas 9,9
Falta de suporte executivo 9,3
Confiabilidade;
Alterações nos requisitos e especificações 8,7
Manutenibilidade. Falta de planejamento 8,1
O software não é mais necessário 7,5
Falta de gerenciamento de TI 6,2
Outros 14,2

11

Engenharia dos Requisitos Engenharia dos Requisitos

• Motivação • Princípios
• Os problemas têm que ser enunciados antes de serem • Boas especificações de requisitos são indispensáveis.
resolvidos. • Não representam custos supérfluos, mas investimentos
necessários.
• Nada é mais caro do que resolver os problemas errados.
• A participação dos usuários na engenharia de requisitos é
• A boa engenharia de requisitos reduz a instabilidade de fundamental para que suas necessidades sejam corretamente
sistemas de informação: atendidas pelo produto.
• Ajuda a obter os requisitos corretos em um estágio anterior • Uma boa especificação de requisitos custa tempo e
ao desenvolvimento. dinheiro;
• O custo de correção de defeitos cresce muito ao longo do • A ausência de uma boa especificação de requisitos custa
tempo. muito mais tempo e dinheiro.


Fase de Elaboração Levantamento dos Requisitos
• Fase na qual a especificação do produto é detalhada
o suficiente para modelar conceitualmente o domínio • Levantamento das funções, interfaces e
do problema, validar os requisitos em termos deste requisitos não-funcionais desejados para o
modelo conceitual e permitir um planejamento produto.
acurado da fase de construção.
• Requisitos levantados apenas em nível
necessário para o estabelecimento de um
• É dividida em duas iterações: entendimento inicial entre usuários, clientes e
desenvolvedores.
• Levantamento dos Requisitos: captura dos requisitos • Levantamento de requisitos focalizando os
junto aos usuários.
usuários.
• Análise dos Requisitos: detalhamento e validação dos
requisitos levantados junto aos usuários. • Método típico:
* oficinas de levantamento de requisitos.

Análise dos Requisitos Análise dos Requisitos

• Detalhamento e análise dos requisitos. • Foco na visão que os desenvolvedores têm
dos requisitos do produto, ainda dentro do
• Modelagem conceitual dos elementos espaço de problema e não do espaço de
relevantes do domínio do problema e uso solução.
desse modelo para validação dos requisitos e
planejamento detalhado da fase de
Construção. • Métodos típicos:
* oficinas de detalhamento de requisitos;
* entrevistas.


12

Técnicas para Levantamento e Análise de Técnicas para Levantamento e Análise de
Requisitos Requisitos
• Freqüentemente, falhas de comunicação e de
entendimento entre a equipe de • Metodologia mais utilizada pelas empresas:
desenvolvimento e clientes envolvidos • Entrevista individual entre o analista de sistemas e os
usuários.
resultam em erros de especificação cuja
• Vantagens:
posterior correção em sistemas já • Praticidade e fácil aplicação.
construídos compromete prazos e custos • Desvantagens:
previstos. • Lentidão do processo;
• Comprometimento:
• Da qualidade dos requisitos resultantes;

$$$ • Da convergência de interesses entre os usuários;
• Consenso na priorização dos requisitos.


Técnicas para Levantamento e análise de
Requisitos
Metodologia JAD

• Técnicas de dinâmica de grupo: • Benefícios:
• Eficazes na agilização do processo; • Redução da necessidade de manutenção nos aplicativos
• Redução nas falhas de comunicação; desenvolvidos com o seu auxílio;
• Metodologia JAD*: • Redução de custos;
• Maior satisfação dos usuários, pois as aplicações atendiam ao
• Uma abordagem usando um líder NEUTRO para
que eles realmente desejavam;
orientar usuários através de um processo interativo
e flexível, obtendo-se CONSENSO sobre um • Maior entrosamento entre a área de Sistemas de Informações
assunto pré-determinado. e os Departamentos Usuários;
• Menor necessidade de modificações durante o processo de
desenvolvimento;
• Nivelamento das expectativas de ambas as partes entre outros.
*Joint Application Design
• Metodologia desenvolvida nos anos 70 pela IBM – Canadá;
• Objetivo inicial: levantamento de requisitos e desenho de
interfaces de sistema;

Metodologia JAD Metodologia JAD

• Com o passar do tempo, JAD passou a ser
utilizado: • Componentes básicos de um JAD:
• Em todas as fases do cliclo de desenvolvimento de software • Patrocinador do projeto:
e não apenas durante o levantamento de requisitos (Joint
Application Development);
• Possui poder de decisão e fornece os recursos
necessários para o projeto.
• Planejamento de projetos em geral;
• Planejamento estratégico;
• Líder da sessão:
• Tomada de decisões, de qualquer natureza, que necessita • Responsável por conduzir a sessão de forma
de um consenso entre várias pessoas das diversas áreas de NEUTRA.
uma organização (Workshops). • Documentador:
• Responsável por redigir as decisões tomadas em
ata;


13

Metodologia JAD Metodologia JAD

• Componentes básicos de um JAD: • Por que usar JAD?
• Usuários finais: • Redução do tempo de desenvolvimento do software;
• Conhecedores do negócio da aplicação; • Aumento da qualidade do software;
• Aumento da produtividade;
• Definem as necessidades do sistema em nível
• Redução do custo;
apropriado de detalhes;
• Maior motivação e comprometimento da equipe;
• Desenvolvedores:
• Redução de alteração de requisitos;
• Tomam conhecimentos das necessidades dos • Visão global do sistema pelos envolvidos;
usuários finais e da aplicação durante a sessão de
JAD;
• Respondem questões técnicas;


Metodologia JAD Oficina de Requisitos

• Sucesso de um JAD depende:
• Liderança da sessão de forma eficiente; • Definição do Local:
• Participação de usuários finais, executivos e ☺ Afastado do local de trabalho, onde os
desenvolvedores;
participantes não possam ser interrompidos;
• Alcance da sinergia do grupo durante a sessão.
☺ Sem interferências externas (celular, bip, etc...);
☺ Baixo nível de ruído;
☺ Mesas arrumadas em “U” (se possível);
☺ Serviço de café.


Principais Problemas no Principais Problemas no
Desenvolvimento de Sistemas Desenvolvimento de Sistemas

Demanda reprimida
Problemas de Produtividade
O backlog dos sistemas pode ser dividido em três
Os dois aspectos mais importantes desse problema categorias:
são:
• Visível:
A demanda reprimida (backlog) por novos sistemas;
Sistemas solicitados oficialmente pelos usuários e que
O tempo necessário para construir um novo sistema. foram aceitos e tiveram suas verbas aprovadas pela
gerência. Ainda não foram iniciados por falta de
recursos humanos (analistas, programadores etc.).


14


• Invisível: Tempo de desenvolvimento

Sistemas que os usuários sabem que precisam, mas não Existe a preocupação com a perda de oportunidades de
se dão ao trabalho de solicitar oficialmente, porque ainda negócios, devido à incapacidade de desenvolver os
estão aguardando outros projetos. sistemas de apoio necessários no tempo necessário.
Muitos projetos nem são terminados. Dentre os principais
• Desconhecido: motivos para estouro de tempo em projetos, podemos
citar:
Sistemas que os usuários ainda não sabem que precisam
mas que emergirão logo que sejam concluídos outros Problemas técnicos;
sistemas dos backlogs visível e invisível.



O tempo necessário para criar um sistema pode ser
Problemas gerenciais; reduzido através de algumas técnicas:

Inexperiência da equipe; Contratação de mais programadores e analistas de
sistemas;
Falta de tempo para análise e projeto;
Contratação de programadores e analista de sistemas
Escasso envolvimento por parte da gerência ou mais talentosos, oferecendo-lhes melhores condições de
usuários. trabalho;



Razões para os analistas terem ciência dos
Deixar que usuários desenvolvam seus próprios problemas de produtividade:
sistemas;
A produtividade e qualidade do trabalho dos
Melhores linguagens de programação; programadores está diretamente ligada ao serviço feito
pelo analista;
Ferramentas automatizadas de desenvolvimento.
Algumas das técnicas de aumento de produtividade
têm importância direta para os analistas;


15


Problemas de Confiabilidade

A produtividade da análise é um problema politicamente Os erros em sistemas podem passar desapercebidos (ex.:
sensível; uma impressão de relatório não formatada corretamente)
ou causar graves acidentes (problema em sistema de
Usuários e gerente têm ansiedade pelo início da tráfego aéreo).
programação;
Os erros em software são difíceis de serem extintos
Usuários não entendem a importância da especificação. porque:

É difícil descobrir como solucionar o erro;



A figura 1 mostra o número de erros encontrados em
Deve-se encontrar todos os pontos de correção;
função do tempo decorrido (YOURDON, 1990).
Alta probabilidade de introduzir novos erros (efeitos
colaterais);

Nem sempre são reportados pelos usuários;

Dificuldade de reproduzir o erro.

Figura 1 – Erros descobertos em função do tempo


Manutenibilidade
Sobre a curva na figura 1 é importante notar:
A correção de erros é apenas um dos aspectos da
Inicialmente o nº de erros encontrados é pequeno (usuários sem
segurança para apontar erros), como indica T1;
manutenção de sistemas. A manutenção também está
vinculada a fatores como:
À medida que os usuários se familiarizam com sistema os erros são
percebidos e reportados (entre T1 e T2); Modificações no hardware;

Após um tempo (após T2) o nº de erros encontrados começa a Novos dispositivos;
diminuir (sistema começa a tornar-se mais estável);
Necessidade de melhorar o desempenho;
O número de erros volta a crescer devido a correções ou modificações
que introduzem novos erros (após T3); Garantir maior confiabilidade;

A curva nunca atinge zero. Alterações dos requisitos.

16


A manutenção de um sistema deve ser sempre Outros Problemas – Portabilidade
acompanhada de modificações na especificação do
sistema. Entretanto, isso nem sempre ocorre devido a Consiste em escrever sistemas que podem ser
fatores como: transferidos para outras plataformas;

Analista alocado para outro projeto; Apesar de não ser um problema da alçada do analista,
ele deve especificar que há essa necessidade;
Urgência na implantação das modificações;
A portabilidade geralmente provoca ineficiência já que
Inexistência de uma política que valorize a recursos disponíveis de determinada plataforma não são
manutenção da especificação. aproveitados.



Principais causas dos Problemas
Outros Problemas – Segurança

À medida que os sistemas de informações crescem em Ausência de Planejamento de Sistemas;
número e importância, o risco de violações aumenta.
Ausência de Administração de Dados;
A segurança de sistemas de informações consiste
basicamente em: Não utilização de Métodos e Técnicas Formais
de Desenvolvimento;
Impedir o acesso de pessoas não autorizadas;
Não utilização de Técnicas e Ferramentas;
Conceder acesso a certas funcionalidades apenas a
algumas pessoas. Adoção de Metodologias não ambientadas à
realidade da empresa;


Principais causas dos Problemas(cont.) Nota Especial Sobre Qualidade

Falta de definição precisa dos objetivos e A qualidade de um sistema pode ser mensurada
requisitos do sistema; considerando a eficácia e a eficiência obtidas:

Dificuldade de comunicação e/ou falta de Eficácia = Resultados Obtidos / Resultados Pretendidos
entrosamento entre as pessoas envolvidas no
processo, causada por problemas de linguagem Eficiência = Resultados Obtidos / Recurso Consumido
ou rivalidade entre usuários;

Falta de precisão e clareza na especificação dos
sistemas.


17

Principais Problemas no Identificação, análise e gerência de
Desenvolvimento de Sistemas requisitos

Problemas que denotam falta de qualidade em 1 Técnicas de Entrevistas e de Coleta de Dados
sistemas:
Por que e para que fazemos entrevistas ?
Não contribuem para os objetivos da empresa;
Para coletar informações armazenadas em cérebros sobre o
comportamento de um sistema atual ou um novo sistema;
Não atendem às necessidades dos usuários;
Para verificar como compreendemos o comportamento de
Não são confiáveis; um sistema;

Para elaborar um estudo de viabilidade de desenvolvimento
São ineficientes; de um sistema.

Têm manutenção constante, difícil e onerosa.


Identificação, análise e gerência de Identificação, análise e gerência de
requisitos requisitos

2 Tipos de Entrevistas 3 Problemas ao Entrevistar Usuários

Entrevista em forma de reunião pessoal; Entrevistar a pessoa errada no momento errado;

Entrevista em forma de questionários abertos e fechados; Fazer perguntas erradas e obter respostas erradas;

Gravação de descrição de expectativas do usuário em relação Criar ressentimentos recíprocos.
ao sistema.


4 Diretrizes para a realização de entrevistas

Desenvolva um plano geral de entrevista; 5 Possíveis Formas de Resistência na Entrevista
Certifique-se de que você tem autorização para falar com os
Você está tomando muito o meu tempo;
usuários;
Você está ameaçando o meu emprego;
Planejar a entrevista para fazer uso eficiente do tempo;

Utilize ferramentas automatizadas que sejam adequadas, mas não Você não conhece nossa empresa e ainda quer nos dizer como deve
abuse; ser feito o novo sistema?

Tente descobrir em que informações o usuário está mais
interessado;


18


6 Outros Problemas a Enfrentar
5 Possíveis Formas de Resistência na Entrevista(cont.)
Uma discussão que focalize mais os problemas de
Você está tentando mudar o modo como as coisas são feitas implementação do que os problemas de requisitos;
aqui;
Confusão entre sintomas e problemas;
Nós, usuários, não queremos este sistema;
O usuário pode ser incapaz de explicar o que ele quer que o
Por que você está desperdiçando nosso tempo com esta sistema faça ou pode mudar de opinião;
entrevista?
Desentendimento entre usuários de mesmo nível, subordinados e
chefes.



7 Formas Complementares de Coleta de Dados Requisitos Funcionais: Descrevem a funcionalidade
ou os serviços que se espera que o sistema forneça.
Demonstrações feitas pelos fornecedores; Descrevem a função de sistema detalhadamente, suas
entradas e saídas, excessões, etc. Exemplos:
Visitas a outras empresas com sistemas semelhantes;
“O sistema deve permitir que cada professor realize o
Coleta de dados em manuais, formulários, relatórios, listagens de lançamento de notas das turmas nas quais lecionou”;
programas, etc.;
“O sistema deve permitir que um aluno realize a sua
Pesquisa externa em instituições como IEEE e ACM. matrícula nas disciplinas oferecidas em um semestre”;

“O sistema deve permitir que o aluno consulte todo o seu
histórico de disciplinas cursadas”.



Requisitos Não Funcionais:
Requisitos Não Funcionais: São aqueles que não
dizem respeito diretamente às funções específicas
Requisitos não
fornecidas pelo sistema. Eles podem estar relacionados funcionais

a propriedades de sistemas emergentes, como
confiabilidade, tempo de resposta e espaço em disco. Requisitos do Requisitos Requisitos
produto organizacionais externos
Alternativamente, podem definir restrições para o
sistema, como por exemplo, a capacidade dos
Facilidade Confiabili Portabili Interopera
dispositivos de E/S e as representações de dados de uso
Eficiência
dade dade bilidade
Legais Éticos

utilizados nas interfaces de sistema.
Desempe Privacida Seguran
Espaço
nho de ça

Implemen
Entrega Padrões
tação


19

Requisitos de Usuário:
Requisitos de Sistema:
São os requisitos que descrevem os requisitos funcionais e não
funcionais de modo compreensível pelos usuários do sistema que São descrições mais detalhadas dos requisitos de
não têm conhecimentos técnicos detalhados. Como redigí-los ? usuários. Estes requisitos podem ser descritos utilizando-
se:
Utilize um formato-padrão e certifique-se de que todas as
definições de requisitos estejam conforme este formato; (1) Linguagem natural estruturada – depende de formulários padrão;
Utilize a linguagem de modo consistente. Em particular, faça uma (2) Linguagem de descrição de projeto – usando linguagens de
distinção entre os requisitos obrigatórios e os que são desejáveis; programação como exemplo para descrever os requisitos;
Evite, tanto quanto possível, o uso de jargões de informática. (3) Notações gráficas – usando diagramas em geral (casos de uso,
Contudo, inevitavelmente, ocorerrá que termos técnicos detalhados, atividades, seqüência, etc);
utilizados no domínio da aplicação do sistema, sejam incluidos nos
requisitos do usuário. (4) Especificações matemáticas – como uma máquina de estados
finitos (de acordo com a transição de estados).

Observações Sobre os Requisitos:

Volatilidade dos requisitos: atualmente, a Documento de Requisitos:
volatilidade é mais uma regra que uma exceção. Os
requisitos mudam rapidamente atualmente, novos O documento de requisitos – às vezes chamado ER -
requisitos podem ser adicionados e outros removidos Especificação de Requisitos de software – é a
durante o processo. declaração oficial do que é exigido dos desenvolvedores
de sistema. Ele deve incluir os requisitos de usuário para
É importante ressaltar que, com a complexidade um sistema e uma especificação detalhada dos
dos sistemas atuais, é impossível pensar em todos os requisitos de sistema (SOMMERVILE, 2003).
detalhes do sistema a princípio.


Usuários do Documento de Requisitos:
Requisitos de um Documento de Requisitos:
Especificam os requisitos e os lêem para verificar
Clientes do Sistema se eles atendem a suas necessidades. Especificam
as mudanças nos requisitos. Segundo Heninger (1980), um documento de requisitos de software deveria
satisfazer a seis princípios:
Utilizam o documento de requisitos para planejar
Gerentes um pedido de proposta para o sistema e para
planejar o processo de desenvolvimento.
Deveria especificar somente o comportamento externo do sistema;

Deveria especificar as restrições à implementação;
Engenheiros de Sistema Utilizam os requisitos para compreender que
sistema deve ser desenvolvido.
Deveria ser fácil de ser modificado;
Engenheiros de teste de Deveria servir como uma ferramenta de referência para os responsáveis pela
Utilizam os requisitos para desenvolver testes de
Sistema validação para o sistema. manutenção do sistema;
Deveria registrar a estratégia sobre o ciclo de vida do sistema;
Engenheiros de Utilizam os requisitos para ajudar a compreender Deveria caracterizar respostas aceitáveis para eventos indesejáveis.
manutenção de Sistema o sistema e as relações entre suas partes.


20

Análise de Sistemas: Conceitos e Modelagem com UML

Análise de Sistemas: Conceitos e Modelagem com UML

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Análise de Sistemas: Conceitos e Modelagem com UML

Semelhante a Análise de Sistemas: Conceitos e Modelagem com UML (20)

Análise de Sistemas: Conceitos e Modelagem com UML