UC00601 - Analisar e planear sistemas de informação

UC00601 - Analisar e planear sistemas de informação

Let's go!

Sumário

• Apresentação
• Balanço de competências
• Resumo sobre unidade.

• Introdução aos Sistemas de Informação (SI)
• Discussão

Continue

Continue

Objetivos da Sessão

• Compreender o conceito de Sistema de Informação (SI).
• Identificar tipos e exemplos práticos de SI.
• Reconhecer os componentes de um SI.
• Relacionar SI com o processo de tomada de decisão.

Continue

O que é um Sistema de Informação

Continue

Sistema

Informação

Um sistema é um conjunto de elementos inter-relacionados que trabalham para atingir um objetivo comum. Características:

• Entradas
• Processamento
• Saídas
• Feedback

Exemplo Sistema de rega: sensores de humidade → controlador → válvulas de água → solo com humidade estável.

Informação = dados organizados, contextualizados e compreensíveis. Valor da informação depende:

• Contexto
• Relevância
• Atualidade
• Fiabilidade

Continue

O que é um Sistema de Informação?

Um Sistema de Informação é um sistema que recolhe, guarda, processa e distribui informação para:Apoiar:

• operações
• gestão
• decisão
• estratégia

Inclui:

• Pessoas
• Processos
• Tecnologia
• Dados

Continue

Funções de um Sistema de Informação

• Recolher dados

• Processar (filtrar, calcular, validar)

• Armazenar

• Distribuir informação

• Apoiar decisões

• Controlar operações

• Automatizar tarefas

Continue

Exemplo: Sistema de gestão de inventário de um armazém.

Continue

Componentes de um Sistema de Informação

• Pessoas – Utilizadores e técnicos que operam o sistema.
• Processos – Conjunto de regras e procedimentos.
• Dados – Informação bruta que será tratada.
• Tecnologia – Hardware e software que suportam o sistema.

Continue

Tipos de Sistemas de Informação

ERP

MRP

CRM

MRP (Material Requirements Planning) é um sistema de planeamento das necessidades de materiais, usado principalmente em empresas de produção e manufatura.

ERP (Enterprise Resource Planning) – sistema de gestão integrada que reúne num único software as principais funções e processos de uma empresa — como finanças, compras, vendas, produção, recursos humanos, logística, e contabilidade. Exemplos ERPs: SAP, Oracle, PHC, Primavera.

CRM – (Customer Relationship Management) é um sistema de gestão de relacionamento com clientes. O seu principal objetivo é organizar, automatizar e melhorar todas as interações que a empresa tem com clientes e potenciais clientes.

Continue

Qual a importância dos SI nas Organizações?

Continue

• Aumentam a eficiência e reduzem erros humanos.
• Facilitam o controlo e a tomada de decisão.
• Permitem integração de dados entre departamentos.
• Apoiam a inovação e competitividade.

Continue

Desvantagens.

• Dependência tecnológica
• Falhas técnicas
• Custos altos de implementação
• Segurança de dados
• Obsolescência
• Resistência dos utilizadore

Continue

Tendências atuais dos SI

• Inteligência Artificial
• Big Data
• Cloud Computing
• IoT
• Automação Robótica (RPA)
• Blockchain

Continue

Caso Prático

Dado um pequeno ginásio, identifique os SI que o podem ajudar.

• objetivos
• processos
• dados recolhidos
• utilizadores
• melhorias esperadas

Continue

Objetivos

• Aumentar a retenção de clientes
• Melhorar o atendimento e personalização dos treinos
• Automatizar tarefas administrativas
• Controlar pagamentos e acessos
• Monitorizar desempenho dos utilizadores

Continue

Processos

• Registo e inscrição de novos membros
• Gestão de mensalidades e pagamentos
• Controlo de acesso (entrada/saída)
• Marcação de aulas e personal trainers
• Gestão de equipamentos e manutenção
• Acompanhamento físico (pesagens, treinos, avaliações)
• Comunicação com clientes (notificações, avisos, promoções)

Continue

Dados Recolhidos

• Dados pessoais dos clientes (nome, idade, contacto)
• Registo biométrico ou cartão de acesso
• Registo de pagamentos e estado das mensalidades
• Histórico de treinos
• Resultados de avaliações físicas (peso, massa gorda, IMC…)
• Disponibilidade de salas, professores e equipamentos
• Estatísticas de utilização do ginásio

Continue

Utilizadores dos Sistemas

• Funcionários de receção
• Instrutores / Personal Trainers
• Clientes / Membros
• Gestor do ginásio
• Equipa de manutenção
• Sistema automático de controlo de acessos

Continue

Melhorias Esperadas com a Implementação de SI

• Redução de erros administrativos
• Check-in automático → menos filas na receção
• Maior controlo das mensalidades e redução de incumprimentos
• Treinos mais personalizados com base nos dados recolhidos
• Melhor planeamento de aulas e lotações
• Acompanhamento mais profissional e motivacional
• Melhor tomada de decisão através de dashboards (ex: horas de maior afluência)
• Comunicação mais eficaz com os clientes
• Aumento da satisfação e fidelização dos membros

Continue

Processo de Decisão e Recolha de Dados

Como os Sistemas de Informação suportam a tomada de decisão e como a recolha de dados influencia a qualidade dessas decisões.

Continue

Objetivos da Sessão

• Explicar as fases do processo de decisão
• Identificar os tipos de decisões numa organização
• Compreender a importância dos dados na decisão
• Reconhecer fontes de dados internas e externas

• Construir mapas de dados e necessidades informacionais

Continue

O Que É Uma Decisão?

Uma escolha consciente entre duas ou mais alternativas, feita para resolver um problema ou alcançar um objetivo.

Elementos de uma boa decisão

• Objetivo – O que quero alcançar?
• Opções – Que alternativas existem?
• Informação – Que dados tenho disponíveis para analisar?
• Consequências – O que pode acontecer com cada escolha?
• Critérios – O que é mais importante? (custo, tempo, qualidade…)

Numa empresa: Escolher um fornecedor com base no preço, qualidade e prazos de entrega. No dia a dia: Decidir se vais trabalhar de carro ou transporte público. Que decisões importantes temos numa oficina automóvel?

Continue

Por Que a Decisão É Importante?

• Tempo e eficiência
• Custos e lucro
• Satisfação do cliente
• Qualidade do serviço
• Cumprimento de prazos
• Reputação do negócio

Quando apoiadas por dados → melhores decisões, menos erros.

Continue

Continue

Continue

Tipos de Decisões

1. Decisões Programadas

2. Decisões Não Programadas

• Rotineiras
• Repetitivas
• Com regras claras

Exemplo?

• Complexas
• Envolvem análise e criatividade

Exemplo?

Continue

Níveis da Decisão

Nível Estratégico (Gestão de topo)

Nível Operacional (Dia-a-dia)

Nível Tático (Gestão intermédia)

• Decisões simples e repetidas

• Organização dos recursos
• Controlo das operações

• Planos a longo prazo
• Objetivos da organização
• Grandes investimentos

Continue

Fases do Processo de Decisão

• Inteligência — Identificar problema
• Modelação — Procurar soluções
• Escolha — Selecionar a melhor
• Implementação — Executar
• Avaliação — O resultado foi positivo?

Cliente reclama atraso → identificar causa → testar opções → mudar fluxo → medir impacto.

Continue

A Importância dos Dados

Sem dados → decisões subjetivas Com dados → decisões objetivas, rápidas e fundamentadas

DADOS PERMITEM:

• Reduzir incerteza
• Reconhecer padrões
• Criar previsões
• Medir desempenho
• Melhorar processos

Gestão de Stocks.

Continue

Tipos de Dados

1. Dados Quantitativos

2. Dados Qualitativos

• Numéricos
• Medidos

• Descritivos
• Observações

Continue

Estrutura dos Dados

• Dados brutos → sem tratamento
• Informação → dados processados
• Conhecimento → interpretação dos dados
• Sabedoria → ação baseada em conhecimento

Continue

Fontes Internas de Dados

As Fontes Internas de Dados são todos os dados que a organização já produz ou armazena no decorrer das suas operações diárias. Em qualquer organização, estas fontes são fundamentais para melhorar processos, apoiar decisões e otimizar o negócio.

• Dados Financeiros
• Dados de Cliente (CRM interno)
• Dados de Recursos Humanos
• Dados de Inventário / Armazém
• Dados de Sistemas Internos / Equipamentos
• Dados Operacionais (Produzidos pelas atividades diárias)

Continue

Dados Financeiros

Exemplos nas organizações:

• Faturas emitidas a clientes
• Custos de artigos e componentes
• Margem por tipo de serviço
• Pagamentos em atraso
• Fluxo de caixa mensal

Como são usados:

• Análise de rentabilidade
• Planeamento financeiro
• Ajuste de preços dos serviços

Continue

Dados de Inventário / Armazém

Informação sobre stocks e artigos. Exemplos:

• Quantidade de peças em armazém
• Entradas e saídas
• Tempo médio de reposição
• Peças mais usadas por tipo de serviço
• Fornecedores e prazos de entrega

Como são usados:

• Evitar ruturas de stock
• Identificar peças com baixa rotação
• Automatizar encomendas

Continue

Dados Operacionais (Produzidos pelas atividades diárias)

Incluem toda a informação gerada durante os serviços prestados. Exemplos:

• ?

Como são usados:

• ?

Continue

Exemplos reais na oficina: • Ordens de trabalho • Diagnósticos realizados • Checklists de manutenção • Registos de peças utilizadas • Tempos de execução por tarefa • Histórico de avarias por veículo Como são usados: • Previsão de necessidades de stock • Comparação entre tempo estimado vs. tempo real • Identificação de serviços que demoram mais que o esperado

Continue

Fontes Externas de Dados

As Fontes Externas de Dados são todas as informações obtidas fora da organização, mas que influenciam decisões, planeamento e operações do negócio.

• Fabricantes e Fornecedores de Peças
• Bases de Dados Técnicas e Manuais Oficiais
• Legislação e Normas
• Dados de Clientes em Plataformas Online
• Dados de Mercado e Tendências da Indústria
• Parceiros e Redes de Oficinas

Continue

Fabricantes e Fornecedores de Artigos

Os fabricantes são uma das principais fontes de dados externas.

Exemplos reais:

• Catálogos digitais de peças (Bosch, Monroe, Gates…)
• Tabelas de compatibilidades para cada modelo
• Prazos de entrega
• Listas de preços atualizadas
• Boletins técnicos de instalação

Utilidade:

• Encomendas mais rápidas e precisas
• Garantia de compatibilidade
• Planeamento de armazém com base em tempos de entrega

Continue

O Papel do Sistema de Informação na Recolha de Dados

Os Sistemas de Informação (SI) têm um papel central na forma como a organização capta, organiza e valida dados. Manualmente, a recolha de dados torna-se lenta, sujeita a erros e difícil de utilizar para tomar decisões.

Continue

Automatizam a Recolha de Dados Um SI evita que os dados sejam recolhidos manualmente, reduzindo erros e aumentando a velocidade.Exemplo: Atualização automática do stock quando uma peça é usada

Garantem Consistência e Padronização Os dados seguem sempre o mesmo formato, facilitando análises futuras. Exemplo: Campos obrigatórios: marca, modelo, matrícula

Continue

Recolhem Dados em Tempo Real Permitem decisões imediatas baseadas no estado atual da organização.Exemplo: Atualização imediata do estado da viatura (em diagnóstico, em reparação, concluído)

Reduzem a Recolha Duplicada e Erros HumanosO mesmo dado não é introduzido duas vezes. Exemplo: O cliente é registado uma vez e reutilizado em todas as ordens

Continue

Modelos de Decisão 1. Modelo Racional Baseado em dados e análise. 2. Modelo Intuitivo Experiência e instinto. 3. Modelo ComportamentalInfluenciado por emoções e limitações.

Continue

Exemplo Comparativo 1. Mecânico experiente (intuitivo): "A válvula EGR deve estar entupida." 2. SI / Dados (racional): Erro OBD P0401Pressão anormalHistórico similar no mesmo modelo

Continue

Erros Comuns na Decisão

• Dados incompletos
• Dados incorretos
• Dados desatualizados
• Viés de confirmação
• Subjetividade
• Falta de análise
• Pressão do tempo

Continue

Decidir Baseado Apenas na Intuição Depender apenas do “feeling” sem dados confiáveis.Exemplo na oficina: “Penso que vendemos muitas baterias… deve ser melhor encomendar mais.” → Mas os dados mostram que a procura é sazonal e está a baixar.

Continue

Depender Demasiado de Métricas Isoladas Tomar decisões olhando apenas para um indicador e não para o conjunto.Exemplo: Reduzir o preço da mão-de-obra porque a concorrência é mais barata. → mas sem analisar custos, produtividade e margem real.

Continue

Ferramentas de Apoio à Decisão As ferramentas de apoio à decisão ajudam gestores e equipas a analisar dados

1 . Dashboards e Sistemas de Reporting (BI)

Exemplos na Oficina Automóvel: – Tempo médio de reparação por tipo de serviço – Número de carros em fila / agendamentos do dia – Consumo de peças e stock crítico – Receita diária/semanal

2 - Sistemas de Gestão (ERP / CRM)

– ERP: gestão de stock, compras, faturação – CRM: histórico do cliente, recomendações de serviços, lembretes de revisões Exemplo real: lembrar automaticamente um cliente de trocar a correia de distribuição.

Continue

Mini Caso de Estudo A oficina recebe 40 carros por semana, mas apenas 28 são entregues no prazo. Como um SI pode ajudar?

• Identificação do Problema/Análise do Processo Atual.
• Levantamento dos Dados Necessários.
• Principais Fontes de Dados, internas e externas.
• Ferramentas de Apoio à Decisão Recomendadas.
• Benefícios Esperados.

Proposta?

Continue

Mini Caso de Estudo A oficina recebe 40 carros por semana, mas apenas 28 são entregues no prazo. Como um SI pode ajudar?

O problema:

• Atrasos constantes na entrega dos veículos.

• Repetição de erros no processo (peças em falta, diagnósticos incompletos).

• Queixas por falta de comunicação e prazos incorretos.

Continue

ANÁLISE DE SOFTWARE E RECOLHA DE REQUISITOS

É o momento em que entendemos o problema, os utilizadores, o contexto e definimos o que o sistema deve fazer — antes de programar.

Continue

Objetivos da Sessão

• Compreender o papel da Análise de Software
• Identificar e recolher requisitos essenciais
• Avaliar processos de negócio antes do desenvolvimento
• Elaborar documentação clara e útil

• Entender a importância da comunicação entre stakeholders

Continue

Porque existe? Porque é tão importante?

1. Evita Erros e Retrabalho (o maior custo dos projetos)

• 60% dos problemas em projetos de software vêm de requisitos mal definidos.
• Corrigir erros na fase de desenvolvimento custa até 10x mais do que os identificar na análise.
• Sistemas sem análise tornam-se caros, lentos de implementar e difíceis de manter.

2. Assegura que o Software Resolve o Problema Certo

• A análise garante que entendemos exatamente o processo atual, o que funciona mal e o que precisa de mudar.
• Sem ela, o sistema pode ficar “bonito, mas inútil”.

Continue

Porque existe? Porque é tão importante?

3. Melhora a Comunicação entre Equipas

• Traduz necessidades de negócio → linguagem clara para programadores.
• Evita mal-entendidos entre utilizadores, gestão e equipa técnica.

4. Reduz Custos e Aumenta o Retorno do Investimento (ROI) Planeamento correto evita funcionalidades desnecessárias. Garante que o software apoia diretamente os objetivos da organização.

➡️ Porque é que acham que tantos projetos falham por causa de uma má análise?

Continue

Antes de desenvolver, é preciso…

1. Compreender o Problema Real

• O utilizador descreve o que sente, mas nem sempre descreve o que precisa.
• Antes de pensar em software, é obrigatório perceber:
• Que dor queremos resolver?
• Quem sofre o problema?
• Quando acontece?
• Com que impacto no negócio?

“Se o cliente diz ‘o sistema é lento’, isso é um problema ou um sintoma?”

Continue

Antes de desenvolver, é preciso…

2. Mapear o Processo Atual (AS-IS)

• Identificar como as tarefas são feitas hoje — mesmo que mal feitas.
• Descobrir:
• Responsáveis
• Passos e decisões
• Exceções
• Ferramentas usadas
• Visualizar o processo ajuda a revelar falhas e redundâncias.

Exemplo: oficina automóvel → desde a chegada do cliente até à entrega da viatura: onde existem esperas? quem valida? quem regista?

Continue

Antes de desenvolver, é preciso…

3. Definir Objetivos Claros Não começar por “precisamos de um software novo”. Começar por:

• Queremos reduzir o tempo do processo em 30%
• Queremos evitar erros manuais
• Queremos maior transparência para os clientes
• Queremos registos que cumpram auditorias

Objetivos mal definidos produzem software inútil.

Continue

Antes de desenvolver, é preciso…

4. Recolher Requisitos de Forma Estruturada A análise exige perguntas e investigação:

• O que o sistema vai fazer (funcionais)?
• Como o sistema deve comportar-se (não funcionais)?
• Restrições, integrações, volumes, segurança, acessos…

Ferramentas úteis: entrevistas, workshops, questionários, observação, análise documental.

Continue

Antes de desenvolver, é preciso…

5. Entender os Utilizadores e o Contexto Mais importante que a tecnologia é quem a usa. É necessário identificar:

• Perfis de utilizadores (rececionista, mecânico, gestor…)
• Capacidades tecnológicas
• Tarefas mais críticas
• Frustrações atuais
• Prioridades individuais vs. empresariais

Pergunta crítica: “Quem vai usar isto todos os dias?”

Continue

Antes de desenvolver, é preciso…

6. Validar as Necessidades Antes de Começar Antes do programador tocar no teclado, validar:

• Estamos todos a falar do mesmo?
• As necessidades estão completas?
• Há algo contraditório?
• O que é prioridade?
• O que pode ficar para uma fase 2?

Sem validação → retrabalho → custos → atrasos → frustração.

Continue

O que são Requisitos?

Requisitos são declarações verificáveis sobre o que o sistema deve fazer (funcionais) ou como deve comportar-se (não funcionais).São um contrato: quem pede (negócio) e quem faz (equipa técnica) devem entender e aceitar o mesmo.

Continue

Por que são críticos?

• Evitam mal-entendidos entre utilizador e equipa técnica.
• Permitem estimar corretamente esforço, custos e prazos.
• Servem de base para testes (criterios de aceitação).
• Minimizar retrabalho e desperdício.

Tipos de requisitos

• Funcionais (O QUE): ações, processos e funcionalidades (ex.: “Sistema deve gerar orçamento”).
• Não funcionais (COMO): desempenho, segurança, usabilidade, disponibilidade (ex.: “Resposta < 3s”).
• Requisitos de domínio: regras ou restrições específicas do setor (ex.: normas ambientais).
• Requisitos de interface: integrações com outros sistemas (ex.: faturação automática para o software X).

Continue

Exemplos requisitos funcionais

• Criar ordens de reparação
• Registar entrada de viaturas
• Associar mecânico a um serviço
• Enviar SMS ao cliente quando a viatura está pronta
• Integrar com o software de faturação

Exemplos de requisitos não funcionais.

• Disponibilidade do sistema de 99,5%
• Página inicial carrega em < 2 segundos
• Backups automáticos diários
• A interface deve ser compatível com telemóveis

Continue

Como escrever um requisito bom (boas práticas)

Use regras e modelos para requisitos testáveis e claros:

• INVEST (User Stories): Independente, Negociável, Valiosa, Estimável, Pequena, Testável.
• SMART (para objetivos / NFs): Específico, Mensurável, Atingível, Relevante, Temporal.
• Formato recomendado (requisito funcional): “O sistema deve [verbo + objeto] [condição opcional]”.

Ex.: “O sistema deve gerar o orçamento detalhado (peças + mão de obra) ao guardar a ordem de serviço.”

Continue

Perguntas ESSENCIAIS para fazer aos stakeholders

Sobre o problema / contexto

• Qual é o problema que queremos resolver?
• Com que frequência ocorre? Qual o impacto?

Sobre a funcionalidade

• O que exatamente espera que o sistema faça? Pode dar um exemplo real?
• Que dados entram e que resultados espera receber?

Sobre exceções e regras

• O que acontece se faltar uma peça? E se o cliente recusar o orçamento?
• Existem tempos máximos aceitáveis (SLA)?

Continue

Perguntas ESSENCIAIS para fazer aos stakeholders

Sobre prioridades

• Qual é mais importante: tempo de resposta, segurança ou custo?
• Se tivermos de escolher, o que deve ficar para uma fase posterior?

Sobre utilizadores

• Quem usa isto hoje? Quem usará amanhã? Que proficiência têm com tecnologia?
• Quem valida/assina o resultado (quem aprova o orçamento)?

Sobre testes e aceitação

• Como vamos saber que isto funciona? Que prova aceitaria?
• Quais os critérios mínimos para considerar a funcionalidade aceite?

Continue

Critérios de aceitação (exemplos concretos)

Transforma um requisito numa check list testável: Requisito: “Gerar orçamento ao guardar ordem” Critérios:

• Inclui peças e mão de obra com preço unitário e subtotal.
• Calcula IVA automaticamente.
• Permite editar antes de enviar.
• Guarda versão com timestamp e autor.
• Envia notificação ao cliente (email/SMS) se solicitado.

Continue

Exemplos práticos (Oficina Automóvel)

Funcionais:

• RF-01: “O sistema deve criar uma ordem de serviço ao registar a entrada da viatura, com matrícula, cliente, km e observações.”
• RF-02: “O sistema deve sugerir peças compatíveis com base no modelo e ano da viatura.”

Não funcionais:

• RNF-01: “O tempo de resposta para carregar a ficha de viatura deve ser ≤ 2s.”
• RNF-02: “Os dados sensíveis do cliente devem estar encriptados em repouso (AES-256).”

Continue

Exemplos práticos (Oficina Automóvel)

Critérios de aceitação (RF-01):

• Ficha criada com todos os campos obrigatórios preenchidos;
• Ordem aparece imediatamente no dashboard do mecânico;
• ID da ordem gerado automaticamente;
• Histórico da ordem acessível pelo cliente.

Continue

Técnicas de Análise

• Fluxogramas
• Casos de Uso (UML)
• User Stories (métodos ágeis)

• Mockups e protótipos

Continue

Fluxogramas e Modelação

Um fluxograma é uma representação visual de um processo, mostrando passos, decisões, entradas e saídas de forma clara e sequencial.

Serve para:

• Compreender processos complexos
• Identificar falhas, redundâncias e desperdícios
• Comunicar de forma simples com qualquer utilizador
• Apoiar a análise e recolha de requisitos
• Criar bases para automatização de tarefas

Continue

Elementos Principais de um Fluxograma

• Início/Fim → indica onde o processo começa e termina
• Processo/Tarefa → ação executada
• Decisão → ponto onde há uma escolha (Sim/Não)
• Entrada/Saída → informação que entra ou sai
• Conectores → continuidade do fluxo
• Documentos/Registos → formulários, relatórios, ordens de trabalho

Continue

Fluxo recepção.

Continue

Casos de Uso

Um Caso de Uso descreve como um utilizador interage com o sistema para atingir um objetivo.

Inclui:

• Ator
• Objetivo
• Fluxo principal
• Fluxos alternativos
• Exceções

Qual o ator mais crítico numa oficina? Justifica.

Continue

Caso de Uso: Criar Orçamento de Reparação

Ator: MecânicoObjetivo: Orçamentar reparação de viatura Fluxo Principal:

1. Seleciona viatura
2. Regista problemas
3. Sistema sugere peças
4. Sistema calcula valores
5. Mecânico confirma
6. Orçamento é enviado ao cliente

Fluxo Alternativo: Peça não existe em stock → pedido sugerido automaticamente.

Continue

User Stories

As User Stories são descrições curtas e simples que representam uma necessidade real de um utilizador dentro do sistema. São usadas em métodos ágeis (Scrum, Kanban) para comunicar funcionalidades de forma clara, sem linguagem técnica complexa.

Formato:“Como [utilizador], quero [ação], para [benefício].”

Exemplos:

• Como mecânico, quero registar o tempo de trabalho, para garantir orçamentos corretos.
• Como cliente, quero receber notificações SMS, para acompanhar o estado da reparação.
• Como rececionista, quero gerar uma fatura automaticamente, para reduzir erros de digitação.

Continue

Mockups ou Prototipagem

Prototipar é criar uma versão simplificada, rápida e interativa do sistema antes de o desenvolver totalmente. Serve para testar ideias, validar requisitos e evitar erros caros.

Tipos de Protótipos : Protótipo de Baixa Fidelidade

• Rascunhos em papel Esboços simples (wireframes)
• Focado na navegação e estrutura
• Rápido de criar e fácil de alterar

Exemplo: Um desenho simples da interface da “Receção de Viaturas”.

Protótipo de Média Fidelidade Mais próximo do visual real Criado em ferramentas como Figma, Balsamiq, Miro Permite testar fluxos e interações básicas Exemplo: Ecrã clicável para registar uma nova intervenção na oficina.

Continue

Mockups ou Prototipagem

Exemplo aplicado à Oficina Automóvel Imaginem que a oficina quer um módulo para: “Registar veículos e abrir ordens de reparação.” Protótipo típico:

• Ecrã inicial → lista de viaturas
• Botão “Nova Receção”
• Formulário com matrícula, cliente, quilometragem
• Botão “Criar OR”
• Fluxo para anexar fotografias da viatura

O cliente pode testar e dizer: “Falta a opção de indicar o estado dos pneus.” “O campo dos danos devia aceitar fotos.” 👉 Estas correções são baratas, antes do código existir.

Quando usar protótipos?

• No início do projeto
• Quando há muitas incertezas
• Quando o cliente “não sabe o que quer”
• Para validar requisitos com utilizadores reais
• Para explicar o sistema à equipa de desenvolvimento

Continue

Mini Caso Prático — Sistema de Gestão de Ginásio Um ginásio local pretende modernizar o seu processo de gestão. Atualmente, os registos são feitos em Excel e papel. Querem um sistema de informação que permita:

• Gerir inscrições e mensalidades
• Controlar presenças
• Gerir aulas e horários
• Registar treinos personalizados
• Comunicar com os clientes

Tarefas

• 5 requisitos funcionais (RF)
• 3 requisitos não funcionais (RNF)
• 1 caso de uso
• 1 user story
• 1 fluxograma simples

Continue

Introdução à UML e Visual Paradigm

A importância da modelação no desenvolvimento de software Nesta sessão vamos:

• Introduzir a linguagem UML Perceber porque é essencial antes de programar
• Criar os primeiros diagramas

Continue

Objetivos da Sessão

• Entender a importância da modelação
• Explicar o que é a UML e para que serve
• Identificar os principais tipos de diagramas
• Ler e criar modelos simples

Continue

Porque Modelamos?

Modelamos para… ➡ Entender • ➡ Comunicar • ➡ Reduzir erros • ➡ Planear • ➡ Criar melhor software

Continue

1. Para Entender o Problema Antes de Criar a Solução

• Evita desenvolver algo errado ou incompleto.
• Ajuda a clarificar o que o cliente realmente quer — e não apenas o que “parece que quer”.
• Reduz ambiguidades e interpretações diferentes entre equipa, cliente e utilizadores.

2. Para Comunicar Melhor

• A modelação torna ideias visíveis.
• Diagramas permitem que programadores, analistas, gestores e clientes falem a mesma linguagem.
• Promove alinhamento entre todos, reduzindo falhas de comunicação.

3. Para Reduzir Riscos, Retrabalho e Custos

• Identifica problemas logo no início — quando ainda são baratos de resolver.
• Permite prever comportamentos, dependências e falhas antes de escrever qualquer linha de código.
• Diminui retrabalho, atrasos e frustração do cliente.

Continue

4. Para Organizar o Pensamento e Estruturar o Sistema

• Obriga o analista a pensar de forma lógica e sequencial.
• Torna o sistema mais simples de compreender, dividir, estimar e planear.
• Cria uma visão global e detalhada do que será construído.

5. Para Aumentar a Qualidade do Software

• Modelos melhoram a consistência entre requisitos, casos de uso e implementação.
• Facilita testes: a equipa sabe exatamente o que deve acontecer em cada cenário.
• Ajuda a garantir que o software cumpre o propósito e funciona bem.

6. Para Criar Documentação Útil e Duradoura

• Diagramas tornam-se documentação para:
• novas funcionalidades
• onboarding de novos programadores
• auditorias
• manutenção ao longo dos anos

Continue

O que é a UML?

(Unified Modeling Language) é uma linguagem padrão usada para modelar, visualizar e documentar sistemas de software, independentemente da tecnologia, linguagem de programação ou tipo de aplicação.

Continue

O que não é a UML?

❌ Não é uma linguagem de programação ❌ Não é uma metodologia de desenvolvimento ✔ É apenas uma forma de representar modelos que podem ser usados em Scrum, Waterfall, Kanban, XP, etc.

Continue

Para que Serve?

• Representa processos, regras, funcionalidades, arquiteturas e interações.
• Cria uma visão comum entre analistas, programadores, gestores, clientes e testers.
• Ajuda a passar do “problema” para uma solução organizada e estruturada

Porque foi criada?

• Antes da UML, cada empresa usava os seus próprios diagramas → muita confusão.
• A UML tornou a modelação unificada, compreensível e standard.
• Permite que qualquer pessoa da área entenda o modelo criado por outra equipa.

Continue

Os 3 Grandes Tipos de Diagramas da UML

Categoria O que representam Exemplos

Estruturais Como o sistema é composto Classes, Objetos, Pacotes

Comportamentais Como o sistema se comporta Casos de uso, Atividades, Sequência

Interação Como partes do sistema interagem Sequência, Comunicação

Continue

Benefícios de Usar UML

• Reduz erros e ambiguidades
• Melhora a comunicação entre equipas
• Acelera o desenvolvimento
• Serve como documentação de longo prazo
• Facilita testes e validação de requisitos

Continue

Exemplos onde sao usados

Nos bancos

• Modelos de risco para decidir aprovações de crédito.
• Fluxogramas de atendimento ao cliente.
• Modelos de dados para contas, cartões e movimentos.

Em aplicações do dia-a-dia Uber / Bolt:

• Modelo de procura vs. oferta para calcular “surge pricing”.

Netflix / YouTube:

• Modelos de recomendação baseados no comportamento do utilizador.
• Diagramas de fluxo interno de processamento de vídeo.

E-commerce (Amazon, Worten, etc.):

• Modelos de carrinho → pagamento → entrega.
• Fluxograma de devoluções e trocas.

Continue

Exemplos onde sao usados

Na saúde

• Processos de triagem num hospital.
• Modelos de dados do doente: histórico, exames, prescrições.
• Protocolos clínicos representados como fluxogramas.

Na vida pessoal

• Planeamento mensal de despesas (modelo financeiro pessoal).
• Organização de tarefas (Kanban, listas, prioridades).
• Preparação de refeições (diagramas simples: compra → preparo → conservação).

Sempre que precisas de organizar, explicar, simplificar ou prever algo → estás a modelar.

Continue

Tipos de Diagramas

Como representamos visualmente um sistema?

A UML oferece vários tipos de diagramas, cada um com um propósito específico. Todos servem para compreender melhor o sistema antes de o construir.

Continue

Tipos de Diagramas

Diagramas Estruturais (estáticos)

Representam a estrutura, os componentes e as relações do sistema.Mostram como “as coisas estão organizadas”.

Continue

Diagramas Estruturais

Mostram a estrutura do sistema: elementos, entidades, objetos e relações.

Diagrama de Classes Representa os “blocos” principais do sistema. Exemplos: Biblioteca Digital Classe: Livro

• título: “O Alquimista”
• ISBN: 978-972-23-1234-5
• ano: 1988

Continue

Diagramas Estruturais

Classe: Autor

• nome: Paulo Coelho
• nacionalidade: Espanhola

Classe: Utilizador

• nome: Sofia Mendes
• ID: 5502
• tipo: Estudante

Relações:

• Autor —< escreve >— Livro
• Utilizador —< requisita >— Livro

Diagrama de Classes.

Continue

Diagramas Comportamentais (o “comportamento” do sistema)

Descrevem como o sistema funciona ao longo do tempo e como os utilizadores interagem.

Mostra funcionalidades vistas pelos utilizadores.

Ele mostra:

• Quem usa o sistema (os atores).
• O que o sistema permite fazer (os casos de uso).
• Como cada ator interage com essas funcionalidades.

É uma visão macro — não mostra detalhes técnicos, mas sim o que o sistema faz do ponto de vista do utilizador.

Continue

Elementos principais

Atores São pessoas, sistemas externos ou dispositivos que interagem com o sistema. Exemplos:

• Utilizador (cliente)
• Administrador
• Sistema de Faturação (outro sistema)

Continue

Elementos principais

Casos de Uso São ações ou funcionalidades que o ator realiza no sistema. Exemplos:

• Criar Ticket
• Consultar Estado
• Atribuir Técnico
• Gerar Relatório

Continue

Elementos principais

Exemplo Sistema: Gestão de Tickets Atores:

• Cliente
• Técnico
• Administrador

Casos:

• Criar ticket
• Consultar ticket
• Fechar ticket
• Atribuir técnico

Continue

Actividades

Mostra fluxos de trabalho.

Exemplo (Processo de Check-in num Hotel):

• Cliente chega
• Rececionista confirma reserva
• (Decisão) Reserva encontrada?
• Não → Criar nova reserva
• Sim → Continuar
• Solicitar documento
• Emitir chave do quarto
• Finalizar check-in

Continue

Sequência

Mostra ordem das mensagens

Exemplo (Sistema de Bilhética de Metro): Objetos: Passageiro → Torniquete → Sistema Central → Cartão

1. Passageiro aproxima cartão
2. Torniquete lê chip
3. Torniquete envia pedido ao Sistema Central
4. Sistema Central verifica saldo
5. Se saldo OK → aprovar
6. Torniquete abre
7. Sistema Central regista viagem

Continue

Estados

Mostra o “ciclo de vida” de algo.

Exemplo (Estado de uma Encomenda Online):

1. Criada
2. Confirmada
3. Em preparação
4. Enviada
5. Em transporte
6. Entregue
7. Arquivada

(Com transições claras entre estados.)

Continue

Visual Paradigm

O que é o Visual Paradigm?

• Ferramenta líder de modelação UML, BPMN, ERD, SysML, ArchiMate…
• Usada por +300 000 empresas e universidades
• Versões: Community (grátis), Standard, Enterprise, Modeler
• Funciona em Windows, macOS e Linux

Continue

Visual Paradigm - Interface

• Project Browser (esquerda)
• Diagramas abertos (centro)
• Barra superior rápida

Continue

Visual Paradigm - New project

Passo a passo:

• Project → New

• Escolher Tipo UML
• Dar nome (ex: “Sistema Biblioteca”)
• Clicar “Create Blank Project”

Continue

Visual Paradigm - Tipos de diagramas mais usados

• Use Case Diagram
• Class Diagram
• Sequence Diagram
• Activity Diagram
• State Machine Diagram
• BPMN Business Process Diagram
• Entity Relationship Diagram (ERD)

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Contexto do Caso Um centro desportivo dispõe de vários campos de padel que podem ser reservados pelos clientes. Os clientes podem consultar horários, fazer reservas e pagar. Os funcionários podem gerir campos, ver reservas e registar pagamentos presenciais. O sistema deve permitir operações simples, rápidas e acessíveis via web.

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Requisitos Funcionais

• O sistema deve permitir que o cliente consulte horários disponíveis dos campos.
• O sistema deve permitir ao cliente efetuar uma reserva indicando data, hora e número de jogadores.
• O sistema deve enviar uma confirmação de reserva por e-mail.
• Os funcionários devem poder registar manualmente reservas presenciais.
• O sistema deve permitir ao cliente cancelar reservas até 2h antes do horário marcado.

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Requisitos Funcionais

• O sistema deve permitir que o cliente consulte horários disponíveis dos campos.
• O sistema deve permitir ao cliente efetuar uma reserva indicando data, hora e número de jogadores.
• O sistema deve enviar uma confirmação de reserva por e-mail.
• Os funcionários devem poder registar manualmente reservas presenciais.
• O sistema deve permitir ao cliente cancelar reservas até 2h antes do horário marcado.

Continue

DIAGRAMAS DE CASOS DE USO

Continue

Objetivos da Sessão

• Compreender o que são Casos de Uso
• Identificar Atores e Interações
• Desenhar Diagramas de Casos de Uso
• Relacionar casos de uso (include, extend, generalização)

Continue

O que é um Caso de Uso?

Um caso de uso descreve como um utilizador (ator) interage com o sistema para atingir um objetivo.

O foco é sempre no que o utilizador quer fazer, não no funcionamento interno.

Continue

Não representa um..

• Não é um diagrama de fluxo
• Não mostra como o sistema funciona internamente
• Não mostra código nem base de dados
• Não representa layout de ecrãs

✔ É apenas sobre interações entre utilizadores e sistema.

Continue

A solução

• Descrevem a interação entre um ator e o sistema
• Foco no “O quê” e “Porquê”, não no “Como”
• Linguagem simples (quase natural)
• Servem de contrato entre cliente e equipa técnica

Continue

Erros mais comuns (e como evitar)

• Escrever tudo num único caso de uso gigante
• Misturar interface (botões, telas) dentro do caso de uso
• Esquecer fluxos alternativos e de exceção
• Usar Include/Extend sem critério

Continue

Onde são usados?Em que altura do processo?

• Levantamento de requisitos
• Comunicação com stakeholders
• Base para testes funcionais
• Base para prototipagem
• Definição do âmbito do projeto
• No desenvolvimento da documentação

Continue

Template oficial de Caso de Uso

• Nome do Caso de Uso
• Atores
• Objetivo
• Pré-condições
• Pós-condições (sucesso + falha)
• Casos de uso
• As ações/objetivos do ator.
• Relacionamentos
• Include, extend, generalização
• Fluxo Principal (passos numerados)
• Fluxos Alternativos (A1, A2…)
• Fluxos de Exceção (E1, E2…)

Continue

Atores: Exemplos. Quem são?

Pessoa ou sistema externo que interage com o nosso sistema

Exemplos no Padel:

• Cliente (ator principal em quase tudo)
• Funcionário
• Sistema de Pagamentos (ator secundário)
• Serviço de Email

• Cliente
• Administrador
• Funcionário
• Sistema Externo (ex: API de Pagamentos)
• Cron job / sistema de envio automático

Dica: Atores são sempre “fora” do sistema.

Continue

Como identificar atores?

Perguntas úteis:

✔ Quem usa o sistema?✔ Quem beneficia da funcionalidade?✔ Quem fornece informação ao sistema?✔ Quem recebe informação do sistema?

Continue

Pré-condições vs Pós-condições

Pré-condição = o que tem de estar verdadeiro ANTES Ex: “Cliente autenticado”, “Campo existe” Pós-condição de sucesso = o que fica verdadeiro DEPOIS Ex: “Reserva criada”, “Email enviado” Pós-condição de falha = o que fica verdadeiro se correr mal Ex: “Nenhum dado alterado”, “Mensagem de erro exibida”

Continue

Fluxo Principal = Caminho Feliz

Passos numerados 1, 2, 3…Ação do ator → Resposta do sistema (alternar) Verbo no presente, linguagem ativa Ex:

1. O cliente seleciona o horário
2. O sistema apresenta formulário de reserva

Continue

Fluxos Alternativos e de Exceção

A1 – Horário já não disponível E1 – Erro de ligação à base de dados Sempre referenciar em que passo “sai” do fluxo principa

Continue

Relação «include»

Quando um comportamento é usado por vários casos de usoEx: “Autenticar Utilizador” é incluído em quase todos → Evita repetição

Continue

Relação «extend»

Comportamento opcional ou condicional Ex: “Aplicar Desconto Promoção” estende “Efetuar Reserva” apenas se o cliente tiver código

Continue

Quando usar Include vs Extend?

Include → Obrigatório e reutilizável Extend → Opcional ou condicional

Continue

Notação visual básica - diagrama

Bonequinhos → Atores Ovais → Casos de uso Sistema → Caixa retangular Linhas → Associações

Continue

Exemplo Ginásio

Casos de Uso

Efetuar Check-in na Entrada Marcar Aula de Grupo Renovar Mensalidade Registar Novo Sócio (presencial) Comprar Produto na Loja (proteína, toalha, água…) Cancelar Inscrição no Ginásio Receber Lembrete de Aula (automático)

Continue

Exemplo Ginásio

Efetuar Check-in na Entrada Ator principal: Sócio Objetivo: Registar a entrada no ginásio Fluxo principal:

• Sócio aproxima o cartão ou QR code
• Sistema valida cartão ativo
• Sistema regista hora de entrada
• Torniquete/porta abre

Pós-condição: Entrada registada e sócio dentro do ginásio

Continue

Exemplo Ginásio

Marcar Aula de Grupo Ator principal: Sócio Objetivo: Reservar lugar numa aula (Crossfit, Zumba, Yoga…) Fluxo principal:

• Sócio faz login na app/site
• Escolhe dia e hora
• Seleciona aula disponível
• Sistema verifica lotação
• Reserva efetuada

Pós-condição: Sócio tem lugar reservado + recebe lembrete 1h antes

Continue

Exemplo Ginásio

Renovar Mensalidade Ator principal: Sócio Objetivo: Pagar o mês seguinte Fluxo principal:

• Sócio recebe notificação 5 dias antes do vencimento
• Acede à área de pagamentos
• Escolhe método (MB Way, cartão, débito direto)
• Efetua pagamento
• Sistema renova plano automaticamente

Pós-condição: Plano ativo por mais 30 dias

Continue

Exemplo Ginásio

Registar Novo Sócio (presencial) Ator principal: Rececionista Objetivo: Criar ficha de novo membro Fluxo principal:

• Rececionista preenche dados pessoais + foto
• Escolhe plano (Basic, Premium, Familiar…)
• Sócio assina contrato digital
• Sistema gera cartão/QR code

Pós-condição: Novo sócio fica ativo no sistema

Continue

Exemplo Ginásio

Comprar Produto na Loja (proteína, toalha, garrafa…) Ator principal: Sócio Objetivo: Comprar artigo na receção Fluxo principal:

• Sócio pede artigo
• Rececionista regista venda no POS
• Sócio paga (numerário, MB Way ou débito na mensalidade)
• Sistema atualiza stock

Pós-condição: Produto entregue e stock atualizado

Continue

Exemplo Ginásio

Cancelar Inscrição no Ginásio Ator principal: Sócio Objetivo: Dar baixa definitiva Fluxo principal:

• Sócio pede cancelamento com 30 dias de antecedência
• Preenche formulário de saída
• Sistema bloqueia renovação automática

Pós-condição: Plano termina no final do mês pago

Continue

Exemplo Ginásio

Receber Lembrete de Aula (automático) Ator principal: Sistema Objetivo: Enviar notificação 1 hora antes da aula marcada (Este é desencadeado pelo sistema – ator temporal)

Continue

Continue

Casos de Uso – Site de E-commerce

Pesquisar Produtos – Cliente Adicionar ao Carrinho – Cliente Finalizar Compra – Cliente Efetuar Pagamento – Cliente (include obrigatório) Criar Conta – Visitante → Cliente Fazer Login – Cliente Aplicar Cupão de Desconto – Cliente (extend opcional) Escolher Morada de Entrega – Cliente (include) Rastrear Encomenda – Cliente Pedir Devolução/Reembolso – Cliente (após entrega)

Continue

Continue

Thank you!

youremail@genially.com yourwebsite.com

Start

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Calcula quando e quanto comprar ou produzir. Baseia-se em três dados principais: 1. Plano de produção (o que e quando se vai produzir) 2. Listas de materiais (BOM – Bill of Materials) 3. Stocks atuais e encomendas em curso Ajuda a otimizar o inventário, reduzir custos e melhorar prazos de entrega.

Did you know that...

The window allows you to add broader content. You can enrich your genially by incorporating PDFs, videos, text… The content of the window will appear when clicking on the interactive element.

Um Sistema de Informação (SI) é um conjunto organizado de pessoas, processos, dados e tecnologias que trabalham em conjunto para recolher, processar, armazenar e distribuir informação.

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Calcula quando e quanto comprar ou produzir. Baseia-se em três dados principais: 1. Plano de produção (o que e quando se vai produzir) 2. Listas de materiais (BOM – Bill of Materials) 3. Stocks atuais e encomendas em curso Ajuda a otimizar o inventário, reduzir custos e melhorar prazos de entrega.