Engenharia de Software 2

Prévia do material em texto

UNIP – Alphaville
Engenharia de Software
Apresentação
 Engenharia de Software - Tópicos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
2
Módulo 01: Introdução
Introdução: Definição / Crise do Software / Modelos, Processo e Produto / Coesão e Acoplamento;
Engenharia de Requisitos: Conceitos / Importância / Processo / Ergonomia Cognitiva;
 
Módulo 02: Design
JAD: Joint Application Design: Conceito / Princípios e Práticas;
RUP: Processo Unificado: Definições / Processo / Atividades / Iterativo e Incremental;
Métricas de Software: 
APF – Análise de Ponto de Função: Conceitos e Aplicação;
UCP - Pontos por Caso de Uso: Conceitos e Aplicação;
 
Módulo 03: Desenvolvimento
Testes de Software: Caixas Branca e Preta / Unitário / Integração / Aceitação e Regressão;
Componentização: Engenharia de Software Baseada em Componentes – Reusabilidade;
Reengenharia de Software: Manutenção e Evolução;
 Engenharia de Software - Tópicos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
3
Módulo 04: Gestão 
• Gestão de Projetos de Software: PMBOK: Conceitos / Demandas Concorrentes / Processo e Gerências;
• XP: Introdução / Motivação / Manifesto Ágil / Valores e Práticas;
• Gestão de Riscos: Definições / Processo / Framework;
Módulo 05: Governança I
• ISO/IEC 12.207: Conceitos / ISO/IEC 12.207 / Contexto Brasileiro
• Normas e Modelos de Qualidade – SPICE: ISO 15.504 – Modelo SPICE – Objetivos e Processo;
• ISO 9000: Definições / Finalidade e Processo;
Módulo 06: Governança II
• CMMI: Definições / Processo / Níveis Capacidade e Maturidade / Agrupamentos;
• Qualidade do Produto de Software: ISO 9126 / ISO 14.598 e Evolução para SQuaRE;
Módulo 07: Futuro
• Interface Homem Computador - IHC: Definições / Importância / Aplicação / Indicadores / ERGOLIST;
• A evolução das interfaces face à IA generativa: quais os caminhos e impactos na UX/UI.
• Estrada Adiante: Contexto e objetivos futuros.
Módulo 02: Design de Software 
JAD, RUP e Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
4
Curso: Ciência da Computação
Módulo: Engenharia de Software – Design
Tópicos abordados:
JAD (Joint Application Design)
RUP (Rational Unified Process)
XP (Extreme Programming)
Métricas de Software (Análise de Ponto de Função e Pontos por Caso de Uso)
Módulo 02: JAD (Joint Application Design)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
5
JAD (Joint Application Design)
2.1 O que é JAD?
O Joint Application Design (JAD) é uma metodologia de desenvolvimento colaborativo, onde clientes e equipe técnica trabalham juntos em sessões estruturadas para definir requisitos e funcionalidades.
📌 Definição segundo Sommerville (2020):"O JAD é um processo colaborativo que envolve usuários e desenvolvedores no levantamento e refinamento de requisitos, reduzindo mal-entendidos e acelerando o desenvolvimento.“
📌 Definição segundo Pressman (2021):"Uma abordagem de engenharia de requisitos em que um facilitador conduz sessões de grupo com stakeholders para coletar requisitos de forma mais eficiente e interativa."
Módulo 02: JAD (Joint Application Design)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
6
1.2 Benefícios do JAD
✅ Redução de erros na definição de requisitos.
✅ Engajamento do usuário final no desenvolvimento.
✅ Aceleração do processo de levantamento de requisitos.
✅ Melhor alinhamento entre áreas técnicas e de negócios.
1.3 Exemplo Prático de JAD
Imagine que uma empresa deseja criar um sistema de Gestão de Benefícios Corporativos.
Facilitador reúne RH, TI e funcionários em um workshop.
Discussão sobre necessidades: RH quer relatórios detalhados, funcionários querem interface simples.
Protótipo inicial criado durante a sessão.
Refinamento do escopo e validação imediata pelos usuários.
✅ Resultado: Requisitos mais precisos, reduzindo refações futuras.
Módulo 02: JAD (Joint Application Design)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
7
O JAD foi amplamente utilizado nos anos 80 e 90, quando o desenvolvimento de software ainda dependia muito de processos estruturados e documentados. Com o surgimento de metodologias ágeis, como Scrum e Kanban, o uso de JAD diminuiu, mas a abordagem ainda é aplicada em contextos específicos, principalmente quando há necessidade de intensa colaboração com stakeholders.
Contextos onde JAD ainda é útil:
✅ Projetos de grande porte e governamentais, onde requisitos precisam ser amplamente discutidos antes do desenvolvimento.
✅ Empresas que seguem modelos híbridos, combinando práticas ágeis com elementos tradicionais.
✅ Levantamento de requisitos para softwares empresariais complexos, como ERPs ou sistemas bancários.
📌 Exemplo Atual:
Algumas organizações ainda utilizam workshops JAD para levantar requisitos em projetos de transformação digital, onde diferentes departamentos precisam alinhar necessidades antes da implementação de um novo sistema.
18/02/2025
Instituto de Ciência e Tecnologia - ICET
8
Limitações do JAD
Apesar dos benefícios, o JAD tem limitações, especialmente quando comparado a métodos mais dinâmicos como Scrum.
❌ Principais desafios:
Alto custo e tempo para realização das sessões – Reunir todos os stakeholders pode ser caro e demorado.
Risco de burocracia excessiva – Se não for bem gerenciado, pode se tornar um processo rígido e lento.
Dependência de um facilitador experiente – O sucesso do JAD depende muito de um moderador qualificado.
Dificuldade de adaptação em projetos ágeis – O modelo de documentação detalhada pode conflitar com abordagens iterativas como XP e Scrum.
Resistência de participantes – Nem todos os stakeholders estão dispostos ou preparados para participar ativamente. Os projetos são conduzidos pela mesma equipe que conduz o negócio.
📌 Exemplo:
Uma grande seguradora implementando um novo sistema de sinistros pode gastar semanas organizando e conduzindo sessões JAD para levantar requisitos, enquanto um time ágil poderia coletar feedback de forma iterativa e contínua.
Módulo 02: JAD (Joint Application Design)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
9
Principais Artefatos Produzidos em JAD
Durante as sessões JAD, vários artefatos são gerados para documentar e estruturar as decisões tomadas.
📌 1. Documento de Requisitos de Negócio (BRD - Business Requirements Document)
📌 2. Modelos de Processos (BPM - Business Process Models)
📌 3. Prototipação e Wireframes. 
📌 4. Documento de Casos de Uso (Use Case Document)
📌 5. Matriz de Priorização de Requisitos
Módulo 02: JAD (Joint Application Design)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
10
Conclusão:
📌 O JAD ainda é utilizado, mas de forma mais seletiva, especialmente em projetos corporativos e governamentais.
📌 Suas limitações o tornam menos popular em ambientes ágeis, onde feedback contínuo e flexibilidade são preferidos.
📌 Os artefatos do JAD são úteis para garantir que todos os requisitos sejam bem documentados e compreendidos.
🔎 Pergunta para reflexão:
Você acredita que o JAD poderia ser adaptado para equipes ágeis? Como ele poderia ser modificado para se encaixar em um modelo como Scrum? 🚀
Módulo 02: JAD (Joint Application Design)
Módulo 02: RUP (Rational Unified Process)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
11
O que é RUP? É um processo iterativo e incremental de desenvolvimento de software criado pela IBM Rational.
📌 Definição segundo Sommerville (2020):"O RUP é uma abordagem orientada a modelos que organiza o desenvolvimento em fases iterativas, garantindo maior previsibilidade e controle.“
📌 Definição segundo Pressman (2021):"O RUP segue uma estrutura organizada em disciplinas bem definidas, ajudando na modelagem e desenvolvimento incremental de sistemas complexos.
As Quatro Fases do RUP
Iniciação: Definição do escopo e viabilidade do projeto
E laboração: Modelagem da arquitetura e mitigação de riscos.
Construção: Desenvolvimento iterativo do software.
Transição: Implantação e refinamento do sistema.
18/02/2025
Instituto de Ciência e Tecnologia - ICET
12
O que é XP?O Extreme Programming (XP) é uma metodologia ágil voltada para o desenvolvimento rápido, adaptável e com alta qualidade de software, baseada em ciclos curtos de desenvolvimento e feedback contínuo.
📌 Definição segundo Sommerville (2020):"XP é uma metodologia ágil de desenvolvimento de software que enfatiza a comunicação, simplicidade, feedback e coragem para promover um processo altamente iterativo e adaptável.“
📌 Definição segundo Pressman (2021):"Extreme Programming é uma abordagem disciplinada ao desenvolvimento de software que valoriza iterações curtas, testes frequentes e colaboração intensa entre clientes e desenvolvedores."
Módulo 02: XP (Extreme Programming)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
13
Princípios do XP
O XP se baseia em valores fundamentais, que orientam suas práticas:
✅ Comunicação – Equipes trabalham juntas e compartilham conhecimento continuamente.
✅ Simplicidade – O código deve ser direto e fácil de entender.
✅ Feedback – Testes contínuos garantem que o software atenda às expectativas.
✅ Coragem – Mudanças são bem-vindas e ajustes no código são incentivados.
✅ Respeito – O trabalho da equipe deve ser valorizado, garantindo um ambiente saudável.
Módulo 02: XP (Extreme Programming)
18/02/2025
Instituto de Ciência e Tecnologia - ICET
14
Módulo 02: JAD x RUP x XP
	Critério	XP (Extreme Programming)	RUP (Rational Unified Process)	JAD (Joint Application Design)
	Foco Principal	Desenvolvimento rápido e adaptável	Desenvolvimento estruturado e iterativo	Coleta de requisitos colaborativa
	Abordagem	Código sempre testado e melhorado	Modelo incremental com fases definidas	Sessões de workshops com stakeholders
	Mudanças de Escopo	Altamente adaptável	Moderadamente flexível	Rígido após definição inicial
	Interação com Usuário	Contínua	Periódica (durante fases do projeto)	No início do projeto
	Entrega de Software	Entregas frequentes (semanas)	Ciclos iterativos mais longos	Definição detalhada antes do desenvolvimento
	Flexibilidade	Alta	Média	Baixa
	Entrega de Valor	Contínua	Iterativa	Apenas no final
	Documentação	Mínima	Moderada	Extensa
	Exemplo de Uso	Startups	Projetos corporativos	Sistemas críticos (ex: Aeroespacial)
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
15
O que são métricas de software?
As métricas são usadas para estimar esforço, custo e complexidade do software.
📌 Definição segundo Sommerville (2020):
"Métricas de software fornecem dados objetivos para avaliar e gerenciar a qualidade do software.“
📌 Definição segundo Pressman (2021):
"A medição é essencial para previsibilidade e melhoria contínua no desenvolvimento de software.“
Exemplos de Métricas de Software
As métricas de software permitem avaliar aspectos como qualidade, produtividade, desempenho e complexidade do código. Elas são amplamente utilizadas para estimar esforço, custo e detectar problemas no desenvolvimento de software.
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
16
📌 Classificação das métricas:
✅ Métricas de Tamanho – Medem a quantidade de código e funcionalidade.
✅ Métricas de Complexidade – Avaliam a dificuldade de manutenção do código.
✅ Métricas de Qualidade – Medem a confiabilidade e manutenibilidade do software.
✅ Métricas de Produtividade – Avaliam o desempenho da equipe.
📌 1. Métricas de Tamanho
Métricas que quantificam o tamanho do software com base em código ou funcionalidades.
📌 Exemplo 1: Linhas de Código (LOC - Lines of Code)
Mede o total de linhas de código no sistema.
Simples, mas não leva em conta a complexidade.
Exemplo: Um software com 50.000 LOC pode ser mais complexo que outro com 100.000 LOC se o código for mal estruturado.
📌 Exemplo 2: Pontos de função
Mede funcionalidades entregues ao usuário, independentemente da linguagem de programação.
Considera entradas, saídas, consultas e bases de dados.
Exemplo: Um sistema bancário pode ter 500 pontos de função, enquanto um sistema de controle de estoque pode ter 200 pontos de função.
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
17
📌 2. Métricas de Complexidade
Métricas usadas para avaliar a dificuldade de manutenção e evolução do código.
📌 Exemplo 3: Complexidade Ciclomática (McCabe’s Cyclomatic Complexity - CC)
Mede o número de caminhos independentes em um código.
Se um código tem muitos caminhos diferentes, ele pode ser difícil de testar e manter.
Fórmula: CC=E−N+2PCC = E - N + 2PCC=E−N+2P Onde:
EEE = Número de arestas do grafo de controle de fluxo
NNN = Número de nós no grafo
PPP = Número de componentes conectados
Exemplo: Se um código tem CC > 10, pode indicar complexidade excessiva e necessidade de refatoração.
📌 Exemplo 4: Índice de Halstead
Mede a complexidade do software com base no número de operadores e operandos.
Quanto maior o índice, maior a dificuldade de leitura e manutenção do código.
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
18
📌 3. Métricas de Qualidade
Métricas que ajudam a garantir que o software é confiável e manutenível.
📌 Exemplo 5: Densidade de Defeitos
Mede a quantidade de defeitos por mil linhas de código (KLOC - Thousand Lines of Code).
Exemplo: Se um software tem 2 defeitos a cada 1.000 LOC, ele pode estar bem testado. Se houver 10 defeitos por 1.000 LOC, pode indicar necessidade de melhorias na qualidade do código.
📌 Exemplo 6: Taxa de Retrabalho
Mede a porcentagem de código que precisou ser refeito.
Exemplo: Se 30% das funcionalidades entregues precisaram ser refeitas, isso pode indicar falhas no levantamento de requisitos ou na arquitetura do sistema.
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
19
📌 4. Métricas de Produtividade
Métricas que avaliam o desempenho da equipe de desenvolvimento.
📌 Exemplo 7: Velocidade de Desenvolvimento (Story Points por Sprint)
Mede quantos Story Points (tamanho das tarefas) uma equipe conclui por sprint.
Exemplo: Uma equipe XP que entrega 40 Story Points por sprint pode medir sua produtividade para otimizar entregas futuras.
📌 Exemplo 8: Tempo Médio de Resolução de Bugs
Mede quanto tempo leva para um defeito ser detectado e corrigido.
Exemplo: Se um bug crítico demora 5 dias para ser resolvido, pode indicar problemas no processo de testes e integração contínua.
EXERCÍCIO: Qual é a dificuldade de obtenção das métricas aqui avaliadas? Quais são mais fáceis de obter e quais são as mais difíceis?
Módulo 2: Métricas de Software
18/02/2025
Instituto de Ciência e Tecnologia - ICET
20
📌 Conclusão
Métricas de software ajudam a garantir qualidade, previsibilidade e eficiência no desenvolvimento.
Devem ser utilizadas combinadas, pois métricas isoladas podem ser enganosas.
Em metodologias ágeis como XP, métricas como Story Points, Velocidade e Tempo Médio de Correção de Bugs são mais relevantes do que métricas tradicionais como LOC.
📌 EXERCÍCIO: Qual métrica você considera mais importante para avaliar a qualidade de um software e por quê? 🚀
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
21
Definição de Artefato no Contexto da Engenharia de Software
No contexto da Engenharia de Software, um artefato é qualquer produto tangível gerado durante o processo de desenvolvimento de software. Ele pode ser usado para documentação, planejamento, modelagem, implementação, teste ou manutenção do software.
📌 Definição segundo Sommerville (2020):
"Artefatos de software incluem documentos, modelos, código-fonte e qualquer outro elemento criado durante o desenvolvimento para apoiar a construção e evolução do sistema.“
📌 Definição segundo Pressman (2021):
"Artefatos são elementos do processo de desenvolvimento que servem como referência para a equipe técnica e stakeholders, garantindo rastreabilidade e organização do projeto."
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
22
📌 Classificação dos Artefatos
Os artefatos podem ser documentais, técnicos ou executáveis,dependendo de sua função no desenvolvimento.
✔️ Artefatos Documentais – Servem para registrar requisitos, decisões e processos.
Exemplo: Documento de Requisitos, Diagramas UML, BPMN, User Stories.
✔️ Artefatos Técnicos – Representam elementos de modelagem e design do sistema.
Exemplo: Wireframes, Protótipos, Modelos de Dados.
✔️ Artefatos Executáveis – Produzem resultados diretos no funcionamento do software.
Exemplo: Código-fonte, Scripts de Teste, Compiláveis.
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
23
	Artefato	XP (Extreme Programming)	RUP (Rational Unified Process)	JAD (Joint Application Design)
	Requisitos	User Stories	Casos de Uso detalhados	Documento de Requisitos de Negócio (BRD)
	Planejamento	Plano de Iteração	Planejamento por fases	Workshops com stakeholders
	Modelagem	Metáfora do Sistema	Diagramas UML	BPMN e fluxos de processos
	Medição do progresso	Gráficos de Velocidade e Burndown	Relatórios de status	Marcos de entrega definidos no início
	Qualidade	Test-Driven Development (TDD)	Testes ao final de cada fase	Definição de critérios de aceitação
📌 Comparação: Artefatos no XP vs. RUP vs. JAD
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
24
📌 Comparação: Artefatos no XP vs. RUP vs. JAD
XP: Base da metodologia Ágil, os artefatos XP são “consumíveis”, não tem valor intrínseco após a construção do código. Não há a preocupação com a atualização ou o tracking desses artefatos, já que o principal é o código de boa qualidade (comentado, dentro do framework escolhido, usando as bibliotecas homologadas, validado por pares e, em grande parte, automaticamente testado).
RUP: Baseados na Análise Orientada a Objetos, os artefatos são construídos em linguagem UML (Unified Modelling Language) e a codificação somente é iniciada após todas as fases serem cumpridas a cada iteração. 
JAD: Baseado na Análise Estruturada, os artefatos são construídos com base em Diagramas de Fluxo de Dados, Diagramas de entidades relacionais, Fluxogramas e Pseudo-código.	
📌 Conclusão
📌 XP usa artefatos leves e iterativos para garantir flexibilidade.
📌 RUP utiliza modelos formais e documentação estruturada.
📌 JAD enfatiza alinhamento inicial com stakeholders antes do desenvolvimento.
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
25
📌 Principais artefatos no XP:
Cartões de User Stories
Plano de Iteração (Iteration Plan)
Metáfora do Sistema
Gráficos de Velocidade e Burndown
Testes Automatizados (TDD e ATDD)
Pair Programming Notes (Anotações da Programação em Par)
https://www.hiperbytes.com.br/metodologia-xp-extreme-programming-comparativos-entre-as-metodologias/
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
26
📌 Principais artefatos no RUP (UML):
Diagramas de atividade
Diagramas de classes
Diagramas de comunicação
Diagramas de componentes
Diagramas de estrutura composta
Diagramas de implantação
diagrama de fluxo de informação
Diagramas de visão geral da interação
diagrama de objetos
Diagramas de pacotes
Diagramas de perfil
Diagramas de sequência
Diagramas de máquina de estados
Diagramas de tempo (timing diagram)
Diagramas de casos de uso
GRÁFICO DAS BALEIAS
http://www.dsc.ufcg.edu.br/~pet/jornal/abril2012/materias/recapitulando.html
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
27
📌 Principais artefatos no JAD
Fluxogramas
DFD (Diagramas de fluxo de dados)
ERD (Diagramas de entidades relacionais)
Diagramas de Casos de Uso
Wireframes, pseudo-código
Apesar do conjunto inicial limitado de tipos de artefatos, o principal desafio do JAD é o estabelecimento de uma agenda de reuniões entre participantes das áreas operacionais da empresa em diversos níveis.
https://en.wikipedia.org/wiki/Joint_application_design
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
28
User Story
Título: Visualizar Tempo Estimado de Chegada do Motorista
Descrição: Como passageiro, quero visualizar o tempo estimado de chegada do motorista para planejar minha saída.
Critérios de Aceitação:
O tempo estimado de chegada deve ser exibido na interface do passageiro assim que a corrida for aceita pelo motorista.
O tempo estimado deve ser atualizado em tempo real com base na localização do motorista.
Caso ocorra alguma alteração significativa na rota do motorista, o passageiro deve ser notificado.
Se houver problemas de conectividade, deve ser exibida uma mensagem informando a impossibilidade de atualização do tempo estimado.
Prioridade: Alta
Notas Técnicas:
O cálculo do tempo estimado deve utilizar APIs de geolocalização e trânsito em tempo real.
A interface do usuário deve ser intuitiva e responsiva para diferentes dispositivos.
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
29
Diagrama UML - Caso de Uso "Solicitar Corrida"
Atores:
Passageiro
Motorista
Fluxo Principal:
O Passageiro acessa o aplicativo.
O Passageiro insere o destino e solicita uma corrida.
O sistema busca motoristas disponíveis.
O sistema atribui um motorista ao passageiro.
O Motorista recebe a solicitação e aceita a corrida.
O sistema exibe o tempo estimado de chegada do motorista ao passageiro.
O Motorista dirige até o local de embarque.
O Passageiro embarca no veículo.
O Motorista inicia a corrida.
O Motorista finaliza a corrida no destino.
O sistema calcula o valor da corrida e processa o pagamento.
O Passageiro e o Motorista avaliam a experiência.
Fluxos Alternativos:
Se nenhum motorista estiver disponível, o passageiro recebe uma notificação informando a indisponibilidade.
O passageiro pode cancelar a corrida antes do motorista chegar.
O motorista pode recusar a corrida, e o sistema busca outro motorista.
Módulo 2 - Artefatos
18/02/2025
Instituto de Ciência e Tecnologia - ICET
30
Documento de Requisitos de Negócio (BRD)
1. Introdução O presente documento especifica os requisitos de negócio para o desenvolvimento de um aplicativo de transporte que permita a conexão entre passageiros e motoristas.
2. Objetivo do Sistema Fornecer uma plataforma que permita aos passageiros solicitarem corridas e acompanharem a chegada do motorista, garantindo uma experiência segura e eficiente.
3. Requisitos Funcionais
O passageiro deve poder criar uma conta e fazer login.
O passageiro deve poder solicitar uma corrida informando o destino.
O sistema deve exibir motoristas disponíveis próximos ao passageiro.
O motorista deve receber notificações sobre novas solicitações de corrida.
O sistema deve exibir o tempo estimado de chegada do motorista ao passageiro.
O pagamento deve ser processado automaticamente via cartão de crédito/débito ou carteira digital.
Passageiros e motoristas devem poder avaliar a corrida.
4. Requisitos Não Funcionais
O sistema deve ser capaz de processar 10.000 requisições simultâneas.
A interface deve ser responsiva e compatível com dispositivos móveis.
Os dados dos usuários devem ser armazenados e protegidos conforme as normas de segurança da informação.
.
5. Restrições
Apenas motoristas cadastrados e verificados poderão oferecer corridas.
O sistema deve obedecer às regulamentações locais de transporte urbano.
O pagamento deve ser processado apenas por métodos eletrônicos.
6. Premissas e Dependências
O funcionamento do sistema depende da conectividade com serviços de geolocalização e mapas.
O processamento de pagamentos dependerá de integração com provedores financeiros terceirizados.
7. Riscos
Risco de indisponibilidade do serviço devido a alta demanda.
Possível rejeição de motoristas a determinadas corridas, impactando a experiência do passageiro.
Questões regulatórias que possam afetar a operação da plataforma.
8. Conclusão O desenvolvimento do aplicativo de transporte deve priorizar a experiência do usuário, garantindo eficiência no atendimento e segurança na operação. O acompanhamento em tempo real da chegada do motorista é uma funcionalidade essencial para aprimorar o planejamento dos passageiros e a qualidade do serviço.
image2.png
image3.pngimage4.png
image5.png
image1.png