Sumário
- Resumo
- Abstract
- 1. Introdução
- 2. Contexto e Justificativa
- 3. Metodologia
- 4. Requisitos do Sistema
- 5. Regras de Negócio
- 6. Arquitetura do Sistema
- 7. Diagrama de Fluxo de Dados (DFD)
- 8. Diagrama de Contexto de Menu
- 9. Diagramas de Interface
- 10. Protótipos de Tela
- 11. Banco de Dados e Dicionário de Dados
- 12. Módulos Implementados
- 13. Materiais Recebidos e Inventário
- 14. Plano de Contingência
- 15. Planejamento do Backlog — Gantt e Burndown
- 16. Análise do Backlog Priorizado
- 17. Implementação de QR Code
- 18. Portal de Documentação Auditável
- 19. Próximos Passos
- 20. Pendências e Notas de Divergência
- 21. Conclusão
- 22. Referências (ABNT NBR 6023)
Resumo
Resumo
Este artigo apresenta o desenvolvimento do Sistema de Gestão do Laboratório de Hardware, um projeto integrador elaborado pela turma de 2º Técnico em Informática do Instituto Federal Fluminense — Campus Bom Jesus do Itabapoana. O sistema visa informatizar e modernizar o controle de equipamentos, empréstimos e agendamentos do laboratório, substituindo processos manuais por uma plataforma web baseada em PHP 8.2, MySQL 8.0 e Bootstrap 5. São descritas a modelagem conceitual (diagramas DFD, DER, casos de uso), a arquitetura do sistema, as regras de negócio, os módulos implementados e o planejamento do backlog com gráficos de Gantt e Burndown. Adicionalmente, são detalhadas implementações recentes: módulo de empréstimos com CRUD completo, geração e leitura de QR Code para identificação de componentes, segurança com rate limiting e CSP, e o portal de documentação auditável do projeto. Os resultados parciais demonstram a viabilidade da solução para a gestão eficiente dos recursos do laboratório.
Palavras-chave: Sistema de Gestão. Laboratório de Hardware. PHP. MySQL. QR Code. Segurança. Projeto Integrador. Instituto Federal.
Abstract
Abstract
This paper presents the development of the Hardware Laboratory Management System, an integrative project created by the 2nd year Information Technology class at the Federal Fluminense Institute — Bom Jesus do Itabapoana Campus. The system aims to computerize and modernize the control of equipment, loans, and scheduling of the laboratory, replacing manual processes with a web platform based on PHP 8.2, MySQL 8.0, and Bootstrap 5. The conceptual modeling (DFD, ERD, and use case diagrams), system architecture, business rules, implemented modules, and backlog planning with Gantt and Burndown charts are described. Recent implementations are also detailed: the complete loan module with full CRUD, QR Code generation and reading for component identification, security features including rate limiting and CSP headers, and the project's auditable documentation portal. Partial results demonstrate the feasibility of the solution for efficient management of laboratory resources.
Keywords: Management System. Hardware Laboratory. PHP. MySQL. QR Code. Security. Integrative Project. Federal Fluminense Institute.
1. Introdução
O presente artigo apresenta o desenvolvimento do Sistema de Gestão do Laboratório de Hardware, um projeto integrador desenvolvido pela turma de 2º TI do Instituto Federal Fluminense — Campus Bom Jesus do Itabapoana. O sistema tem como objetivo principal informatizar e modernizar o controle de equipamentos, empréstimos e agendamentos do laboratório de hardware da instituição.
O projeto abrange desde a modelagem conceitual (diagramas DFD, DER, casos de uso, dicionário de dados)
até a implementação funcional com PHP 8.2, MySQL 8.0 e Bootstrap 5, incluindo integração com Docker
para ambiente de desenvolvimento padronizado. O código-fonte está hospedado no repositório
github.com/debianlima/laboratorio_hardware_2025.
1.1 Objetivos
Objetivo Geral: Desenvolver um sistema web para gestão do laboratório de hardware do IFF Bom Jesus do Itabapoana, informatizando os processos de controle de equipamentos, empréstimos e agendamentos.
Objetivos Específicos:
- Modelar os requisitos funcionais e não funcionais do sistema por meio de diagramas DFD, DER e casos de uso;
- Implementar módulo de autenticação com controle de acesso por perfil (administrador e padrão);
- Desenvolver CRUD completo de itens/equipamentos com código patrimonial único;
- Implementar fluxo de empréstimos e devoluções com validação de regras de negócio;
- Criar módulo de agendamentos com verificação de conflitos de horário;
- Gerar relatórios gerenciais e dashboard para acompanhamento do laboratório;
- Documentar todo o processo conforme normas ABNT para trabalhos acadêmicos.
2. Contexto e Justificativa
O laboratório de hardware do IFF Bom Jesus do Itabapoana enfrentava desafios operacionais significativos: controle manual de empréstimos de kits, agendamentos em planilhas, dificuldade de rastreamento de itens e ausência de relatórios gerenciais. A partir de análises utilizando matriz GUT (Gravidade, Urgência, Tendência), foram priorizados os requisitos que mais impactavam a rotina do laboratório.
Os Diagramas de Causa e Consequência (DCC-1 e DCC-2) elaborados durante a fase de análise evidenciaram que a falta de um sistema integrado resultava em perda de equipamentos, conflitos de agendamento e dificuldade na prestação de contas. O sistema proposto visa resolver esses problemas por meio de uma plataforma web com controle de acesso, CRUD de itens, empréstimos, agendamentos e relatórios.
3. Metodologia
O desenvolvimento do sistema seguiu uma abordagem baseada em metodologias ágeis, com ciclos iterativos de planejamento, implementação e revisão. As etapas metodológicas foram organizadas conforme descrito a seguir.
3.1 Levantamento de Requisitos
Os requisitos foram levantados por meio de entrevistas com o técnico do laboratório e professores da disciplina, análise de documentos institucionais e observação direta dos processos manuais existentes. A matriz GUT (Gravidade, Urgência, Tendência) foi aplicada para priorização dos requisitos.
3.2 Modelagem do Sistema
A modelagem conceitual incluiu a elaboração de Diagramas de Fluxo de Dados (DFD) níveis 0 e 1, Diagrama Entidade-Relacionamento (DER), diagramas de caso de uso e diagramas de contexto de menu. O dicionário de dados foi construído para documentar todas as tabelas, campos e relacionamentos do banco de dados MySQL.
3.3 Tecnologias Utilizadas
| Componente | Tecnologia | Finalidade |
|---|---|---|
| Linguagem | PHP 8.2 | Lógica do servidor e controllers |
| Banco de Dados | MySQL 8.0 | Persistência de dados |
| Frontend | Bootstrap 5 + CSS3 | Interface responsiva |
| Infraestrutura | Docker + Docker Compose | Ambiente padronizado |
| Controle de Versão | Git + GitHub | Versionamento do código |
3.4 Atividades Realizadas
As atividades foram organizadas em sprints semanais, abrangendo desde a análise inicial até a implementação dos módulos. Cada sprint produziu entregas incrementais validadas pelo orientador e pelo técnico do laboratório. O detalhamento de cada módulo implementado encontra-se nas seções 6 a 15 deste artigo.
4. Requisitos do Sistema
4.1 Requisitos Funcionais
O sistema contempla 30 requisitos funcionais (RF-01 a RF-30), dos quais os principais incluem:
- RF-01 a RF-05: Cadastro, edição, exclusão e listagem de usuários
- RF-06 a RF-10: Cadastro, edição, exclusão e listagem de itens/equipamentos
- RF-11 a RF-15: Controle de empréstimos e devoluções
- RF-16 a RF-20: Agendamento de laboratórios
- RF-21 a RF-25: Geração de relatórios e auditoria
- RF-26 a RF-30: Fórum de dúvidas, suporte e notificações
4.2 Requisitos Não Funcionais
- RNF-01: Segurança — autenticação com senha hasheada (bcrypt)
- RNF-02: Desempenho — resposta em até 3 segundos nas operações CRUD
- RNF-03: Acessibilidade — navegação responsiva e compatível com leitores de tela
- RNF-04: Escalabilidade — arquitetura modular preparada para novos módulos
- RNF-05: Documentação — código comentado e README atualizado
5. Regras de Negócio
As regras de negócio definem as restrições e comportamentos do sistema:
| ID | Regra | Descrição | Módulo | Status |
|---|---|---|---|---|
| RN-01 | Autenticação obrigatória | Todas as páginas, exceto login, exigem sessão ativa | Autenticação | Implementado |
| RN-02 | Controle de acesso por perfil | Apenas usuários com perfil "administrador" (coluna tipo) podem gerenciar usuários e acessar relatórios. O campo tipo é armazenado na sessão durante o login e utilizado para controle de acesso. | Autenticação | Implementado |
| RN-03 | Unicidade do patrimônio | O código de patrimônio deve ser único no sistema | Itens | Implementado |
| RN-04 | Disponibilidade de itens | Apenas itens com status "disponível" podem ser emprestados | Empréstimos | Implementado |
| RN-05 | Devolução obrigatória | Um item emprestado deve ser devolvido antes de novo empréstimo ao mesmo usuário | Empréstimos | Implementado |
| RN-06 | Conflito de agendamento | Dois agendamentos não podem sobrepor horário no mesmo laboratório | Agendamentos | Prevista |
| RN-07 | Aprovação de agendamento | Agendamentos requerem aprovação do administrador antes de confirmação | Agendamentos | Prevista |
| RN-08 | Limite de empréstimos | Cada usuário pode ter no máximo 3 empréstimos ativos simultaneamente | Empréstimos | Implementado |
| RN-09 | Atualização de status | Ao registrar devolução, o status do item volta automaticamente para "disponível" | Empréstimos | Implementado |
| RN-10 | Log de auditoria | Toda operação de criação, edição ou exclusão é registrada com data, hora e usuário | Auditoria | Prevista |
| RN-11 | Exclusão protegida | Itens com empréstimos ativos não podem ser excluídos | Itens | Implementado |
| RN-12 | Senha segura | Senhas devem ter mínimo de 4 caracteres e serem armazenadas com bcrypt | Autenticação | Implementado |
| RN-13 | QR Code único por item | Cada item possui um QR Code único baseado no seu ID, apontando para URL absoluta do servidor | QR Code | Implementado |
| RN-14 | Visualização pública via QR | A página de detalhes do item (ver.php) não requer autenticação para leitura via QR Code | QR Code | Implementado |
| RN-15 | Rate limit no login | Máximo de 5 tentativas de login por IP antes de bloqueio de 15 minutos, com log de tentativas | Segurança | Implementado |
Tabela 5.1 — Regras de negócio com status de implementação. Regras RN-01 a RN-12 mantidas da versão original; RN-13 a RN-15 adicionadas na versão 3.0. Regras marcadas como "Prevista" ainda não foram implementadas e estão vinculadas a itens do backlog pendentes. A regra RN‑10, referente ao log de auditoria, está em fase de pendência, aguardando a implementação do módulo BL‑11.
6. Arquitetura do Sistema
O sistema adota uma arquitetura monolítica modular baseada no padrão MVC simplificado, com as seguintes camadas:
| Camada | Tecnologia | Descrição |
|---|---|---|
| Apresentação | HTML5 + Bootstrap 5 + CSS3 | Interface responsiva com navegação intuitiva |
| Lógica | PHP 8.2 | Controllers em PHP com sessão e flash messages |
| Dados | MySQL 8.0 + mysqli | Banco relacional com transações e chaves estrangeiras |
| Infraestrutura | Docker + Docker Compose | Ambiente padronizado com Apache e PHP 8.2 |
6.1 Diagrama de Camadas
6.2 Ambiente de Desenvolvimento
O projeto utiliza Docker com dois containers: lab_hardware_app (PHP 8.2 + Apache)
e lab_hardware_db (MySQL 8.0). A configuração é centralizada no arquivo
docker-compose.yml com variáveis de ambiente via .env.
A documentação da pasta docs/ é servida diretamente pelo Apache via volume mount
(./docs:/var/www/html/docs), estando acessível em http://localhost:8080/docs/.
7. Diagrama de Fluxo de Dados (DFD)
7.1 DFD Nível 0 — Diagrama de Contexto
O DFD de contexto mostra o sistema como um processo único e suas interações com entidades externas.
7.2 DFD Nível 1 — Processos Principais
O DFD Nível 1 decompõe o sistema em quatro processos principais:
8. Diagrama de Contexto de Menu
A estrutura de navegação do sistema organiza-se hierarquicamente conforme o diagrama abaixo:
9. Diagramas de Interface
9.1 Mapa de Navegação
O sistema possui as seguintes telas interligadas:
| # | Tela | Arquivo | Tipo | Acesso | Destinos |
|---|---|---|---|---|---|
| T-01 | Login | login/index.html | Protótipo | Público | → T-02 |
| T-02 | Painel Principal | src/index.php | Produção | Autenticado | → T-03, T-06, T-09 |
| T-03 | Listar Itens | src/itens/listar.php | Produção | Autenticado | → T-04, T-05 |
| T-04 | Cadastrar Item | src/itens/cadastrar.php | Produção | Admin | → T-03 |
| T-05 | Editar Item | src/itens/editar.php | Produção | Admin | → T-03 |
| T-06 | Listar Usuários | fontes_recebidas/prototipos/users_list.php | Protótipo | Admin | → T-07, T-08 |
| T-07 | Cadastrar Usuário | fontes_recebidas/prototipos/users_create.php | Protótipo | Admin | → T-06 |
| T-08 | Editar Usuário | fontes_recebidas/prototipos/users_edit.php | Protótipo | Admin | → T-06 |
| T-09 | Relatórios | fontes_recebidas/prototipos/relatorios_list.php | Protótipo | Admin | → T-10 |
| T-10 | Dashboard | fontes_recebidas/prototipos/dashboard.php | Protótipo | Autenticado | → T-02 |
Tabela 9.1 — Mapa de navegação com classificação de ambiente. Telas marcadas como "Protótipo" referem-se a arquivos de referência em fontes_recebidas/prototipos/ ou login/, não fazendo parte do runtime web atual.
9.2 Diagrama de Transição de Telas
10. Protótipos de Tela
10.1 Tela de Login
10.2 Painel Principal (Dashboard)
Nota de atualização (LIM-313): O dashboard em produção (src/index.php) agora exibe ícones SVG ilustrativos para cada módulo (painel-itens.svg, painel-emprestimos.svg, painel-agendamentos.svg) e o card de Agendamentos é exibido com estilo card-disabled (borda tracejada, opacidade reduzida) indicando "Em breve". Os arquivos SVG estão em assets/img/.
Painel do Laboratório
10.3 Listagem de Itens
Itens do Laboratório
+ Cadastrar Item| Código | Nome | Tipo | Status | Localização | Ações |
|---|---|---|---|---|---|
PAT-001 | Kit Arduino Uno | Kit Arduino | Disponível | Prateleira A1 | Editar Excluir |
PAT-002 | Multímetro Digital | Instrumento | Emprestado | Bancada 3 | Editar Excluir |
PAT-003 | ESP32 DevKit | Placa Desenv. | Disponível | Prateleira B2 | Editar Excluir |
PAT-004 | Osciloscópio | Instrumento | Manutenção | Assistência | Editar Excluir |
10.4 Formulário de Cadastro de Item
Cadastrar Item
11. Banco de Dados e Dicionário de Dados
11.1 Visão Geral
O banco de dados lab_hardware utiliza MySQL 8.0 com charset UTF-8mb4.
O schema está definido em docker/mysql/init.sql.
11.2 Diagrama Entidade-Relacionamento (DER)
11.3 Dicionário de Dados Completo
Tabela: usuarios
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| username | VARCHAR(50) | NO | — | Nome de usuário (único) |
| senha | VARCHAR(255) | NO | — | Senha hasheada (bcrypt) |
| tipo | ENUM('administrador','padrao') | NO | 'padrao' | Nível de acesso — coluna renomeada de role para tipo via migration (2026-05-21) |
| criado_em | TIMESTAMP | YES | CURRENT | Data de criação |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: laboratorios
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| codigo | VARCHAR(20) | NO | — | Código do laboratório (único) |
| lugar | VARCHAR(100) | NO | — | Localização física |
| nome | VARCHAR(100) | NO | — | Nome do laboratório |
| tipo | ENUM('redes','hardware','robotica','informatica_normal') | NO | 'informatica_normal' | Categoria |
| tecnico_responsavel | VARCHAR(100) | YES | NULL | Técnico responsável |
| informacao_adicional | TEXT | YES | NULL | Observações |
| criado_em | TIMESTAMP | YES | CURRENT | Data de criação |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: equipamentos
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| nome | VARCHAR(100) | NO | — | Nome do equipamento |
| descricao | TEXT | YES | NULL | Descrição detalhada |
| quantidade | INT | NO | 1 | Quantidade total |
| disponivel | INT | NO | 1 | Quantidade disponível |
| criado_em | TIMESTAMP | YES | CURRENT | Data de criação |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: itens
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| codigo_patrimonio | VARCHAR(50) | NO | — | Código patrimonial (único) |
| nome | VARCHAR(100) | NO | — | Nome do item |
| tipo_id | INT | YES | NULL | FK → tipos_itens.id |
| status | ENUM('disponivel','emprestado','manutencao') | NO | 'disponivel' | Status atual |
| descricao | TEXT | YES | NULL | Descrição do item |
| localizacao | VARCHAR(100) | YES | NULL | Localização física |
| criado_em | TIMESTAMP | YES | CURRENT | Data de cadastro |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: tipos_itens
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| nome | VARCHAR(100) | NO | — | Nome do tipo (único) |
| descricao | TEXT | YES | NULL | Descrição do tipo |
| criado_em | TIMESTAMP | YES | CURRENT | Data de criação |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: emprestimos
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| usuario_id | INT | NO | — | FK → usuarios.id (CASCADE) |
| equipamento_id | INT | NO | — | FK → equipamentos.id (CASCADE) |
| data_emprestimo | TIMESTAMP | YES | CURRENT | Data do empréstimo |
| data_devolucao | TIMESTAMP | YES | NULL | Data da devolução |
| status | ENUM('pendente','devolvido','atrasado') | NO | 'pendente' | Status do empréstimo |
| observacao | TEXT | YES | NULL | Observações |
| criado_em | TIMESTAMP | YES | CURRENT | Data de registro |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: agendamentos
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| usuario_id | INT | NO | — | FK → usuarios.id (CASCADE) |
| laboratorio_id | INT | NO | — | FK → laboratorios.id (CASCADE) |
| data_inicio | DATETIME | NO | — | Início do agendamento |
| data_fim | DATETIME | NO | — | Fim do agendamento |
| finalidade | VARCHAR(255) | YES | NULL | Finalidade do uso |
| status | ENUM('pendente','aprovado','cancelado','concluido') | NO | 'pendente' | Status do agendamento |
| criado_em | TIMESTAMP | YES | CURRENT | Data de criação |
| atualizado_em | TIMESTAMP | YES | CURRENT | Última atualização |
Tabela: login_attempts
| Campo | Tipo | Null | Default | Descrição |
|---|---|---|---|---|
| id | INT AUTO_INCREMENT | NO | — | Chave primária |
| ip_address | VARCHAR(45) | NO | — | Endereço IP da tentativa |
| username | VARCHAR(50) | NO | — | Nome de usuário tentado |
| attempted_at | TIMESTAMP | NO | CURRENT_TIMESTAMP | Data/hora da tentativa |
| success | TINYINT(1) | NO | 0 | 1 = sucesso, 0 = falha |
Tabela auxiliar criada automaticamente pelo rate limiter. Fonte: docker/mysql/migrations/01_add_login_attempts.sql. Índices em ip_address+attempted_at, username e success.
12. Módulos Implementados
12.1 Módulo de Autenticação
Sistema de login com sessão PHP, senha hasheada em bcrypt e controle de tipo de usuário
(administrador / padrão).
Inclui página de login responsiva com validação client-side e server-side.
A coluna tipo (renomeada de role via migration) controla o nível de acesso.
Utilitários de sessão em src/utils/session.php gerenciam timeout de inatividade (30 min)
e regeneração de ID de sessão para prevenção de fixation.
12.2 Módulo de Itens (CRUD Completo)
Gerencia o inventário com cadastro, listagem com filtros, edição e exclusão. Cada item possui código de patrimônio único, tipo, status e localização física.
12.3 Módulo de Empréstimos e Devoluções
Módulo implementado com CRUD completo. Inclui listagem de empréstimos ativos,
cadastro de novos empréstimos com validação de disponibilidade, edição de registros,
e página dedicada para visualização de empréstimos atrasados.
Arquivos: src/emprestimos/listar.php, cadastrar.php,
editar.php, atrasados.php.
12.4 Módulo de Agendamentos
Tabelas criadas no banco. Implementação do CRUD em desenvolvimento.
12.5 Módulo de Relatórios (Módulo 4)
Estrutura base de relatórios implementada (interface Bootstrap); funcionalidades avançadas — gráficos dinâmicos, exportação de dados e dashboard completo — pendentes de desenvolvimento.
12.6 Módulo de Fórum (Módulo 5)
Planejado com integração via Flarum (tema personalizado e suporte a pt-BR). Implementação pendente de desenvolvimento — ver item BL-10 do backlog.
12.7 Segurança e Correções
Correções de segurança aplicadas com base em auditoria defensiva (LIM-77, LIM-200, LIM-274):
- XSS em Flash Messages (LIM-201): Substituição de
strip_tags()porhtmlspecialchars()emsrc/config/flash.php, eliminando vetor de injeção de JavaScript via atributos de tags HTML permitidas. - Syntax Error em Login (LIM-201): Correção de chave não fechada em
src/login.phpque impedia o funcionamento correto do módulo de autenticação. - Feedback de CSRF (LIM-201): Adicionada mensagem de retorno para falha de validação CSRF no login, melhorando a experiência do usuário e a segurança.
- Rate Limiting (LIM-274): Implementado limite de 5 tentativas de login por IP com bloqueio de 15 minutos. O log de tentativas é armazenado em
src/admin/login_log.phpe acessível apenas por administradores. Estudo disponível emdocs/estudos/LIM-274-rate-limit-estudo.md. - CSP Headers (LIM-248): Implementado Content Security Policy via
src/config/security_headers.php, restringindo fontes de script, estilo e conexão. Estudo disponível emdocs/estudos/LIM-248-csp-header.md. - CSRF Tokens: Proteção contra Cross-Site Request Forgery implementada em todos os formulários via
src/config/csrf.php, com tokens armazenados em sessão. - Senhas hasheadas: Autenticação utiliza bcrypt para armazenamento seguro de senhas.
- Sessão segura: Controle de sessão PHP com regeneração de ID e timeout de inatividade via
src/utils/session.php. - Security headers automáticos: O arquivo
src/config/security_headers.phpé incluído viarequire_onceno cabeçalho de autenticação e na página de logout, garantindo que todas as páginas protegidas recebam os headers CSP, X-Frame-Options e Referrer-Policy. - Erros ocultos em produção:
display_errors = Offnodocker/php/php.inipara evitar vazamento de informações do servidor.
Estudos técnicos disponíveis em docs/estudos/LIM-201-correcao-xss-flash.md, docs/estudos/LIM-248-csp-header.md e docs/estudos/LIM-202-testes-manuais.md.
13. Materiais Recebidos e Inventário
| Material | Tipo | Origem | Status |
|---|---|---|---|
| documentacao-do-projeto.pdf | PDF (~20MB) | Documentação oficial | Referenciado |
| lab_system.rar | RAR (~21MB) | Protótipo alunos | Extraído |
| LAB HAD.docx | DOCX (~2MB) | Documento laboratório | Referenciado |
| Relatório lab system.pdf | PDF (~19MB) | Relatório sistema | Referenciado |
| Requisitos .docx | DOCX (~312KB) | Requisitos do sistema | Referenciado |
| Modulo_4_relatorios/ | PHP + Imagens | Grupo 4 | Copiado |
| Modulo_5_forum/ | Flarum (PHP) | Grupo 5 | Referenciado |
14. Plano de Contingência
O plano de contingência identifica riscos potenciais e define ações preventivas e corretivas:
| ID | Risco | Prob. | Impacto | Ação Preventiva | Ação Corretiva |
|---|---|---|---|---|---|
| RC-01 | Perda de dados do banco | Média | Alto | Backup diário automatizado via Docker volume | Restaurar último backup; reexecutar init.sql |
| RC-02 | Indisponibilidade do servidor | Média | Alto | Monitoramento de saúde do container | Reiniciar container; verificar logs |
| RC-03 | Acesso não autorizado | Média | Alto | Senhas bcrypt; controle de sessão; HTTPS | Invalidar sessões; reset de senhas; auditoria |
| RC-04 | Conflito de agendamento | Baixa | Médio | Validação de sobreposição no backend | Cancelar agendamento conflitante; notificar |
| RC-05 | Perda de equipamento | Média | Alto | Controle patrimonial; registro de empréstimo | Registro de ocorrência; substituição |
| RC-06 | Queda de energia | Baixa | Médio | UPS no servidor; InnoDB com transações | Verificar integridade do banco após retorno |
| RC-07 | Erro de deploy em produção | Baixa | Alto | Testes em staging antes de produção | Rollback para versão anterior estável |
docker compose down;
(2) Verificar integridade dos volumes;
(3) Restaurar backup mais recente;
(4) Recriar containers com docker compose up -d;
(5) Validar acesso e dados.
15. Planejamento do Backlog — Gantt e Burndown
15.1 Gráfico de Gantt
Cronograma estimado do projeto (Maio 2026 – Abril 2027):
15.2 Gráfico Burndown
Projeção de trabalho restante ao longo das sprints (estimativa em story points):
15.3 Backlog Detalhado
| ID | Item do Backlog | Sprint | Story Points | Status | Prioridade |
|---|---|---|---|---|---|
| BL-01 | Análise de requisitos e documentação | S1 | 13 | Concluído | Alta |
| BL-02 | Modelagem DFD, DER e dicionário de dados | S1 | 8 | Concluído | Alta |
| BL-03 | Protótipos de tela (Figma/HTML) | S2 | 8 | Concluído | Alta |
| BL-04 | Infraestrutura Docker + MySQL | S2 | 8 | Concluído | Alta |
| BL-05 | Módulo de autenticação (login/logout) | S3 | 13 | Concluído | Alta |
| BL-06 | CRUD completo de itens | S3-S4 | 13 | Concluído | Alta |
| BL-07 | Módulo de empréstimos e devoluções | S5-S6 | 21 | Concluído | Alta |
| BL-08 | Módulo de agendamentos | S7-S8 | 13 | Pendente | Média |
| BL-09 | Módulo de relatórios | S9-S10 | 8 | Pendente | Média |
| BL-10 | Integração com fórum Flarum | S10-S11 | 8 | Pendente | Baixa |
| BL-11 | Módulo de auditoria e logs | S11 | 5 | Pendente | Média |
| BL-12 | Testes automatizados | S12 | 8 | Pendente | Alta |
| BL-13 | Deploy em produção | S13 | 5 | Pendente | Alta |
16. Análise do Backlog Priorizado
16.1 Contexto da Priorização
O backlog do projeto foi priorizado utilizando a Matriz de Impacto vs Esforço,
metodologia clássica de gestão de produtos que classifica tarefas em quatro quadrantes:
Quick Wins (alto impacto, baixo esforço), Major Projects (alto impacto, alto esforço),
Fill-ins (baixo impacto, baixo esforço) e Time Sinks (baixo impacto, alto esforço).
O documento BACKLOG_PRIORITIZACAO.md contém a priorização completa com 10 tarefas
distribuídas entre esses quadrantes.
16.2 Distribuição das Tarefas
A distribuição quantitativa revela um backlog equilibrado, com predominância de tarefas de alto impacto (5 de 8 tarefas implementáveis, excluindo-se os 2 Time Sinks recomendados para reavaliação). O gráfico abaixo ilustra a proporção de cada categoria:
A Matriz de Impacto vs Esforço abaixo posiciona cada tarefa nos quadrantes correspondentes:
16.3 Análise Crítica por Categoria
Quick Wins (Alto Impacto, Baixo Esforço) — 3 tarefas
As Quick Wins representam 37,5% das tarefas e concentram correções de alto
valor com esforço mínimo. A correção de Root Path em AGENTS.md previne execução
em contexto incorreto; a limpeza de issues duplicadas (LIM-47, LIM-48, LIM-49 identificadas
na auditoria LIM-71) reduz ruído no board; a atualização de keyword residual no abstract
melhora a qualidade acadêmica do documento. A execução imediata destas tarefas na Sprint 1
é altamente recomendada.
Major Projects (Alto Impacto, Alto Esforço) — 2 tarefas
Os Major Projects concentram as funcionalidades críticas do sistema. O Módulo de
Empréstimos, classificado como de maior prioridade, foi implementado e está operacional
(commit 85f5e31). As melhorias de segurança, incluindo correções XSS em
flash messages (LIM-201), validação CSRF e uso de bcrypt, já foram parcialmente aplicadas.
O planejamento em fases (básico → avançado) para Sprints 2-3 é adequado.
Fill-ins (Baixo Impacto, Baixo Esforço) — 3 tarefas
As tarefas de preenchimento são apropriadas para intervalos entre sprints. A documentação de APIs internas é a mais relevante por contribuir para a manutenibilidade do sistema. A otimização de performance e atualização de dependências são tarefas de manutenção preventiva que podem ser distribuídas ao longo do projeto.
Time Sinks (Baixo Impacto, Alto Esforço) — 2 tarefas
A classificação como Time Sink está correta. A refatoração total do CSS/Layout não se justifica neste momento, pois o layout existente é funcional. A implementação de funcionalidades não-solicitadas representa risco de escopo creep e deve ser evitada. Recomenda-se criar labels específicas no board para identificar visualmente estas tarefas.
16.4 Recomendações Finais
- Manter a priorização atual, executando Quick Wins na Sprint 1
- Antecipar testes automatizados (BL-12, previsto para Sprint 12) para sprints iniciais
- Criar label "time-sink" no board para evitar priorização acidental
- Revisar a priorização a cada sprint planning conforme recomendação do backlog
- Adicionar validação automatizada de consistência como extensão da correção de Root Path
17. Implementação de QR Code
O módulo de QR Code foi implementado como parte da issue LIM-79 para permitir a identificação física de cada componente do laboratório através de etiquetas com código QR. Ao escanear a etiqueta com a câmera do celular, o usuário é direcionado para a página de detalhes do item sem necessidade de autenticação.
17.1 Fluxo Completo
| Etapa | Ação | Arquivo | Descrição |
|---|---|---|---|
| 1 | Cadastro | src/itens/cadastrar.php | Administrador cadastra novo item no sistema |
| 2 | Geração QR | src/itens/qrcode.php | Sistema gera QR Code com URL /itens/ver.php?id=X |
| 3 | Impressão | src/itens/qrcode.php | Etiqueta é pré-visualizada e impressa com CSS @media print |
| 4 | Fixação | — | Etiqueta é fixada fisicamente no componente |
| 5 | Leitura | Câmera do celular | Usuário escaneia QR Code com app de câmera nativa |
| 6 | Redirecionamento | src/itens/ver.php | Navegador abre página de detalhes do item |
| 7 | Visualização | src/itens/ver.php | Usuário consulta nome, patrimônio, tipo, status e localização |
17.2 Arquivos Envolvidos
| Arquivo | Tipo | Função |
|---|---|---|
src/itens/ver.php | Novo | Página de detalhes do item (mobile-first, acessível via QR) |
src/itens/qrcode.php | Novo | Geração de QR Code, pré-visualização e impressão de etiqueta |
src/itens/listar.php | Modificado | Coluna QR adicionada na tabela + nome do item linkado para ver.php |
src/itens/cadastrar.php | Modificado | Mensagem de sucesso inclui link "Gerar QR Code" |
src/itens/editar.php | Modificado | Botão "QR Code" adicionado ao lado de Salvar |
17.3 Tecnologias e Regras de Negócio
O QR Code utiliza a biblioteca qrcodejs via CDN, sem dependência Composer.
A URL codificada segue o formato http://{$_SERVER['HTTP_HOST']}/itens/ver.php?id={item_id},
garantindo funcionamento em rede local. A impressão é otimizada via CSS @media print para
etiquetas físicas. A página ver.php não requer autenticação, permitindo leitura
rápida por qualquer pessoa com smartphone. A documentação completa do fluxo está disponível em
docs/fluxo-qrcode.html.
18. Portal de Documentação Auditável
Como parte do esforço contínuo de documentação, foi implementado um portal de documentação
navegável e auditável na pasta docs/, acessível via navegador e servido pelo
Apache/Docker. O portal permite rastrear a evolução do projeto com série histórica, vinculação
a issues, commits e agentes responsáveis.
18.1 Estrutura do Portal
A estrutura organizacional do portal segue o padrão abaixo:
docs/
├── index.html (Portal principal)
├── artigo.html (Artigo acadêmico — este documento)
├── fluxo-qrcode.html (Documentação do QR Code)
├── assets/
│ ├── css/main.css (CSS unificado do portal)
│ ├── img/ (Imagens do projeto)
│ └── screenshots/ (Prints de tela)
├── auditoria/ (Histórico de auditoria)
│ └── index.html
├── banco/ (Documentação do banco de dados)
│ └── index.html
├── estudos/ (Estudos técnicos)
│ └── index.html
└── telas/ (Catálogo de telas)
└── index.html
18.2 Série Histórica e Rastreabilidade
Cada página do portal segue um padrão de auditoria com: identificação da issue relacionada,
data, agente responsável, tipo de documento e status. Revisões preservam o conteúdo original
e exibem a versão corrigida em bloco próprio, mantendo rastreabilidade completa das alterações.
O CSS unificado em docs/assets/css/main.css garante aparência profissional com
layout responsivo, cards de resumo, badges de status e tabelas de revisão.
18.3 Manutenção e Padrão ABNT
O arquivo docs/artigo.html é mantido como a versão oficial e canônica do artigo
acadêmico (conforme REVISAO_DOCUMENTAL.md), substituindo as cópias legadas em
src/doc/artigo.html e src/doc/artigo1.html. A documentação segue as
normas ABNT NBR 6023 (referências) e NBR 14724 (apresentação de trabalhos acadêmicos) sempre
que aplicável.
19. Próximos Passos
- Módulo de Agendamentos — Calendário interativo com validação de conflitos
- Módulo de Relatórios — Dashboard com gráficos e exportação de dados
- Módulo de Auditoria — Log de todas as operações do sistema
- Fórum de Dúvidas — Integração com Flarum (planejado, pendente de implementação)
- Testes Automatizados — Cobertura de testes unitários e funcionais
- Deploy em Produção — Configuração de ambiente de produção com HTTPS e backup automatizado
20. Pendências e Notas de Divergência
BACKLOG_MOBILE_FIRST.md mencionado no planejamento original não está
presente na raiz do repositório. O arquivo CHECKLIST_AUDITORIA.md foi criado e
está disponível na raiz do workspace (verificado em Maio 2026); recomenda-se confirmar se
encontra-se versionado no branch final antes da entrega. O arquivo
BACKLOG_PRIORITIZACAO.md está presente na raiz e contém a priorização oficial
do backlog utilizando a Matriz de Impacto vs Esforço (ver seção 16). O arquivo
docs/planejamento/BACKLOG_ORGANIZADO_LIM-143.md também está disponível com
a organização diária do backlog. Recomenda-se a criação do BACKLOG_MOBILE_FIRST.md
para alinhamento completo com o planejamento original.
src/doc/artigo.html (v2.0) e src/doc/artigo1.html (v2.1) são
cópias legadas não oficiais do artigo, mantidas apenas para referência histórica.
A versão oficial e vigente é docs/artigo.html (v3.0 — este documento).
Conteúdo divergente entre as versões deve ser resolvido pela atualização de
docs/artigo.html. A partir da revisão LIM-344, estes legados foram verificados e registrados como
consistentes com o artigo oficial; sua remoção é opcional e recomendada para
limpeza futura do repositório.
| Item | Descrição | Prioridade | Status |
|---|---|---|---|
| BACKLOG_MOBILE_FIRST.md | Arquivo de referência para backlog com foco mobile-first | Média | Ausente |
| BACKLOG_PRIORITIZACAO.md | Priorização do backlog com Matriz Impacto vs Esforço (raiz) | Média | Presente |
| BACKLOG_ORGANIZADO_LIM-143.md | Organização diária do backlog (docs/planejamento/) | Média | Presente |
| CHECKLIST_AUDITORIA.md | Checklist de auditoria técnica do projeto | Média | Presente |
| CRUD Empréstimos | Implementação completa do fluxo de empréstimos e devoluções | Alta | Concluído |
| CRUD Agendamentos | Módulo de agendamentos com calendário e validação de conflitos | Alta | Pendente |
| Relatórios Avançados | Dashboard com gráficos dinâmicos e exportação de dados | Média | Pendente |
| Testes Automatizados | Cobertura de testes unitários e funcionais nos módulos | Alta | Pendente |
| Deploy em Produção | Configuração de HTTPS, backup e ambiente de produção | Alta | Pendente |
21. Conclusão
O desenvolvimento do Sistema de Gestão do Laboratório de Hardware demonstrou que a informatização dos processos de controle de equipamentos, empréstimos e agendamentos é viável e necessária para a realidade do IFF Bom Jesus do Itabapoana. A partir da análise de requisitos, modelagem conceitual e implementação dos módulos iniciais (autenticação e CRUD de itens), foi possível validar a arquitetura proposta e estabelecer uma base sólida para a continuidade do projeto.
Os resultados parciais indicam que a utilização de tecnologias acessíveis e de código aberto (PHP, MySQL, Bootstrap, Docker) permite criar uma solução robusta, escalável e de baixo custo de manutenção. O planejamento com metodologia ágil, evidenciado pelos gráficos de Gantt e Burndown, proporciona visibilidade clara do progresso e das etapas restantes.
Desde a versão anterior deste artigo, avanços significativos foram alcançados: o módulo de empréstimos foi implementado com CRUD completo e validações de negócio (RN-04, RN-05, RN-08, RN-09); o sistema de QR Code foi incorporado para identificação física de componentes, permitindo que qualquer pessoa com um smartphone obtenha detalhes do item instantaneamente; e a segurança do sistema foi substancialmente reforçada com rate limiting, CSP headers e tokens CSRF. Adicionalmente, o portal de documentação auditável foi estabelecido como fonte oficial de consulta e rastreabilidade do projeto.
Na presente revisão (LIM-344), foi realizada uma verificação final de consistência
entre a versão oficial do artigo (docs/artigo.html) e seus legados
(src/doc/artigo.html v2.0 e src/doc/artigo1.html v2.1),
além da correção de caracteres e referências documentais. A série histórica e a
rastreabilidade do projeto foram preservadas, garantindo a integridade acadêmica
do documento.
Como trabalhos futuros, destacam-se a implementação dos módulos de agendamentos, relatórios, auditoria e fórum, além da realização de testes automatizados e do deploy em ambiente de produção. O sistema tem potencial para ser replicado em outros laboratórios da instituição, contribuindo para a modernização da gestão acadêmica.
22. Referências (ABNT NBR 6023)
O estudo de priorização pode ser consultado em LIM-134‑estudo.
INSTITUTO FEDERAL FLUMINENSE. Documentação do projeto: sistema de gestão do laboratório de hardware. Bom Jesus do Itabapoana: IFF, 2025. 89 p.
INSTITUTO FEDERAL FLUMINENSE. Requisitos do sistema: laboratório de hardware. Bom Jesus do Itabapoana: IFF, 2025. Documento técnico.
GRUPO 5 E 1. Relatório do sistema Lab System. Bom Jesus do Itabapoana: IFF, 2025. PDF.
GRUPO 4. Relatório técnico — Módulo 4: relatórios. Bom Jesus do Itabapoana: IFF, 2025.
GRUPO 5. Relatório final — Módulo 5: fórum de dúvidas. Bom Jesus do Itabapoana: IFF, 2025.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 6023: informação e documentação: referências: elaboração. Rio de Janeiro, 2018.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 14724: informação e documentação: trabalhos acadêmicos: apresentação. Rio de Janeiro, 2011.
PHP: HYPERTEXT PREPROCESSOR. PHP: Hypertext Preprocessor. Versão 8.2. Disponível em: <https://www.php.net>. Acesso em: 19 maio 2026.
ORACLE. MySQL 8.0 Reference Manual. Disponível em: <https://dev.mysql.com/doc/>. Acesso em: 19 maio 2026.
BOOTSTRAP. Bootstrap 5.3 Documentation. Disponível em: <https://getbootstrap.com/docs/5.3/>. Acesso em: 19 maio 2026.
DOCKER INC. Docker Documentation. Disponível em: <https://docs.docker.com>. Acesso em: 19 maio 2026.
DEBIANLIMA. laboratorio_hardware_2025. Repositório GitHub. Disponível em: <https://github.com/debianlima/laboratorio_hardware_2025>. Acesso em: 21 maio 2026.
DAVIDSHIM. qrcodejs. Biblioteca JavaScript para geração de QR Code. Disponível em: <https://github.com/davidshimjs/qrcodejs>. Acesso em: 21 maio 2026.
OWASP FOUNDATION. Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. Disponível em: <https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html>. Acesso em: 21 maio 2026.
OWASP FOUNDATION. Content Security Policy Cheat Sheet. Disponível em: <https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html>. Acesso em: 21 maio 2026.
MOZILLA DEVELOPER NETWORK. Content Security Policy (CSP). MDN Web Docs. Disponível em: <https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP>. Acesso em: 21 maio 2026.
MOZILLA DEVELOPER NETWORK. Rate Limiting HTTP. MDN Web Docs. Disponível em: <https://developer.mozilla.org/en-US/docs/Glossary/Rate_limit>. Acesso em: 21 maio 2026.