902 lines
42 KiB
Markdown
902 lines
42 KiB
Markdown
|
---
|
||
|
|
title: 3. ALM - Application Lifecycle Management
|
||
|
|
sidebar_label: 3. ALM
|
||
|
|
sidebar_position: 3
|
||
|
|
---
|
||
|
|
|
||
|
|
# 3. Application Lifecycle Management (ALM)
|
||
|
|
|
||
|
|
## 3.1. Conceitos Fundamentais de ALM
|
||
|
|
|
||
|
|
### 3.1.1. Definição e Importância
|
||
|
|
|
||
|
|
O Application Lifecycle Management (ALM) é uma abordagem integrada para gerenciar todos os aspectos do ciclo de vida de uma aplicação, desde a concepção inicial até a implantação e manutenção. Na Pragmatismo, o ALM é especialmente importante devido à natureza crítica dos projetos de IA e General Bots, que exigem rastreabilidade, segurança e conformidade com padrões regulatórios.
|
||
|
|
|
||
|
|
O ALM da Pragmatismo foi projetado para atender às necessidades específicas de conformidade com ISO 27001, HIPAA e LGPD, garantindo que todas as fases do desenvolvimento de software atendam aos requisitos de segurança da informação, proteção de dados pessoais e melhores práticas da indústria.
|
||
|
|
|
||
|
|
### 3.1.2. Componentes Principais do ALM
|
||
|
|
|
||
|
|
- **Gestão de Requisitos**: Documentação, rastreamento e priorização de requisitos
|
||
|
|
- **Gestão de Desenvolvimento**: Controle de código-fonte, integração contínua e entrega contínua
|
||
|
|
- **Gestão de Testes**: Testes automatizados, testes de segurança e testes de conformidade
|
||
|
|
- **Gestão de Implantação**: Implantação em ambientes controlados com registro de auditoria
|
||
|
|
- **Gestão de Operações**: Monitoramento, manutenção e resposta a incidentes
|
||
|
|
|
||
|
|
### 3.1.3. Benefícios do ALM para Projetos de IA e General Bots
|
||
|
|
|
||
|
|
- Rastreabilidade completa de requisitos até código e testes
|
||
|
|
- Auditabilidade para fins regulatórios (ISO 27001, HIPAA, LGPD)
|
||
|
|
- Redução de riscos de segurança e privacidade
|
||
|
|
- Melhoria contínua do processo de desenvolvimento
|
||
|
|
- Aceleração do time-to-market mantendo a qualidade e a conformidade
|
||
|
|
|
||
|
|
## 3.2. Estruturação do Ambiente ALM
|
||
|
|
|
||
|
|
### 3.2.1. Organização de Áreas e Iterações
|
||
|
|
|
||
|
|
1. Use áreas para agrupar (se necessário) requisitos e outras entidades por versão, grupo, ou qualquer outro agrupamento necessário. Geralmente apenas uma área é suficiente para um projeto isolado ou inicial. Ver artigo sobre como [personalizar áreas](https://docs.microsoft.com/en-us/vsts/work/customize/set-area-paths).
|
||
|
|
|
||
|
|
2. User iterações para definir o cronograma do projeto. Ver [artigo](https://docs.microsoft.com/en-us/vsts/work/customize/set-iteration-paths-sprints)
|
||
|
|
|
||
|
|
3. O modelo CMMI deve ser o modelo usado para confecionar projetos, mesmo em métodos ágeis.
|
||
|
|
|
||
|
|
4. Para editar o cronograma do projeto visite ``` https:///_admin/_work
|
||
|
|
|
||
|
|
5. Para realizar anotações diversas em tarefas, requisitos, questões e outras entidades, utilize o campo Discussion, de modo que o histórico seja automaticamente registrado com data/hora de quem registrou e o texto da anotação.
|
||
|
|
|
||
|
|
6. Apenas inclua as pessoas na linha de conversação, durante a edição de questões, tarefas ou requisitos até que estas precisem realmente ter algum item de ação atribuída a elas.
|
||
|
|
|
||
|
|
7. Escreva o texto do item corporativo de modo dissertativo.
|
||
|
|
|
||
|
|
### 3.2.2. Estruturação para Compliance
|
||
|
|
|
||
|
|
1. **Áreas de Compliance**: Criar áreas específicas para requisitos relacionados a ISO 27001, HIPAA e LGPD, facilitando a rastreabilidade e auditoria.
|
||
|
|
|
||
|
|
2. **Iterações de Compliance**: Definir iterações dedicadas à revisão de conformidade antes de cada release major.
|
||
|
|
|
||
|
|
3. **Tags de Compliance**: Utilizar tags padronizadas (ISO27001, HIPAA, LGPD) para marcar requisitos e tarefas relacionadas à conformidade.
|
||
|
|
|
||
|
|
4. **Artefatos de Compliance**: Manter uma biblioteca de artefatos de compliance que podem ser reutilizados em diferentes projetos.
|
||
|
|
|
||
|
|
### 3.2.3. Integrações com Ferramentas de Segurança
|
||
|
|
|
||
|
|
1. **SAST (Static Application Security Testing)**: Integração com ferramentas de análise estática de código
|
||
|
|
|
||
|
|
2. **DAST (Dynamic Application Security Testing)**: Integração com ferramentas de análise dinâmica
|
||
|
|
|
||
|
|
3. **SCA (Software Composition Analysis)**: Verificação de dependências e bibliotecas
|
||
|
|
|
||
|
|
4. **Gestão de Vulnerabilidades**: Integração com sistemas de registro e acompanhamento de vulnerabilidades
|
||
|
|
|
||
|
|
### 3.2.4. Configuração de Pipelines de CI/CD Seguros
|
||
|
|
|
||
|
|
1. **Verificações de Segurança**: Configurar gates de segurança nos pipelines de CI/CD
|
||
|
|
|
||
|
|
2. **Testes Automatizados de Compliance**: Incluir testes automatizados de conformidade nos pipelines
|
||
|
|
|
||
|
|
3. **Aprovações e Controles de Acesso**: Configurar aprovações baseadas em papéis para implantações em ambientes sensíveis
|
||
|
|
|
||
|
|
4. **Logging e Auditoria**: Configurar logging detalhado de todas as ações nos pipelines
|
||
|
|
|
||
|
|
## 3.3. Papéis e Responsabilidades
|
||
|
|
|
||
|
|
### 3.3.1. Papéis Comuns a Todos os Projetos
|
||
|
|
|
||
|
|
#### 3.3.1.1. Capacitação
|
||
|
|
|
||
|
|
##### 3.3.1.1.1 Gerenciamento do Ciclo de Vida da Aplicação
|
||
|
|
|
||
|
|
(Duração: 30 min. Público: Analistas de Sistemas e Gerentes de Projetos)
|
||
|
|
[Artigo](https://docs.microsoft.com/pt-br/vsts/security/get-started-stakeholder)
|
||
|
|
|
||
|
|
E mais:
|
||
|
|
|
||
|
|
Itens de Trabalho(Work Items)
|
||
|
|
|
||
|
|
Visão geral de todos os tipos de itens de trabalho como requisitos, questões, defeitos, riscos, revisões, requisições de mudança.
|
||
|
|
|
||
|
|
Fluxo de Questões
|
||
|
|
|
||
|
|
Como trafegar informações pelo fluxo de questões e usar o campo Discussion mantendo o Description como o campo mais atualizado.
|
||
|
|
|
||
|
|
Wiki Como visualizar a Wiki do projeto e contribuir com informações e Atas.
|
||
|
|
|
||
|
|
##### 3.3.1.1.2 Criando um Perfil de Navegador por cliente.
|
||
|
|
|
||
|
|
1. No canto superior do navegador, clique no nome de seu usuário(a);
|
||
|
|
2. Em seguida, Gerenciar Pessoas;
|
||
|
|
3. Clique em Adicionar;
|
||
|
|
4. Digite o nome do Perfil e clique em Salvar;
|
||
|
|
5. Pronto.
|
||
|
|
|
||
|
|
##### 3.3.1.1.3 Capacitação em Compliance
|
||
|
|
|
||
|
|
1. **Treinamento ISO 27001**: Conceitos básicos de segurança da informação e requisitos da ISO 27001
|
||
|
|
|
||
|
|
2. **Treinamento HIPAA/LGPD**: Proteção de dados pessoais e dados de saúde
|
||
|
|
|
||
|
|
3. **Treinamento em Desenvolvimento Seguro**: Práticas de codificação segura e prevenção de vulnerabilidades
|
||
|
|
|
||
|
|
4. **Treinamento em Resposta a Incidentes**: Procedimentos para identificação e resposta a incidentes de segurança
|
||
|
|
|
||
|
|
### 3.3.2. Cliente
|
||
|
|
|
||
|
|
Porquê principal da companhia, foco das atenções e zelo, tem registradas todas as suas ideias de modo contínuo recebendo a melhor arquitetura disruptiva e sustentável. No contexto de projetos de IA e General Bots, o cliente deve:
|
||
|
|
|
||
|
|
1. **Fornecer Requisitos Claros**: Especificar claramente os requisitos funcionais e de segurança/privacidade
|
||
|
|
|
||
|
|
2. **Participar das Revisões**: Participar ativamente das revisões de requisitos e demonstrações
|
||
|
|
|
||
|
|
3. **Validar Compliance**: Validar que os requisitos de compliance específicos do seu setor foram atendidos
|
||
|
|
|
||
|
|
4. **Reportar Incidentes**: Reportar prontamente quaisquer incidentes de segurança ou privacidade
|
||
|
|
|
||
|
|
### 3.3.3. Arquiteta de Solução
|
||
|
|
|
||
|
|
Quem define o modo que código, artefatos e dados serão elaborados através de novas ideias disruptivas mas factíveis, técnicas e padrões de indústria consagrados. Para projetos de IA e General Bots, a arquiteta de solução também deve:
|
||
|
|
|
||
|
|
1. **Arquitetura de Segurança**: Definir controles de segurança e privacidade por design
|
||
|
|
|
||
|
|
2. **Arquitetura de Compliance**: Garantir que a arquitetura atenda aos requisitos regulatórios
|
||
|
|
|
||
|
|
3. **Avaliação de Risco**: Realizar avaliações de risco durante o design da solução
|
||
|
|
|
||
|
|
4. **Revisão de Arquitetura**: Conduzir revisões regulares da arquitetura para identificar possíveis vulnerabilidades
|
||
|
|
|
||
|
|
### 3.3.4. Gerente de Projetos
|
||
|
|
|
||
|
|
Quem mantém o projeto no custo, prazo, escopo e qualidade utilizando as melhores práticas de comunicação juntamente das melhores ferramentas de gestão do ciclo de vida da aplicação dentro do meio disruptivo. Para projetos de IA e General Bots, o gerente de projetos também deve:
|
||
|
|
|
||
|
|
1. **Gestão de Riscos de Compliance**: Identificar e mitigar riscos relacionados à compliance
|
||
|
|
|
||
|
|
2. **Coordenação de Auditorias**: Coordenar auditorias internas e externas de segurança e compliance
|
||
|
|
|
||
|
|
3. **Gestão de Documentação de Compliance**: Garantir que toda a documentação necessária está sendo produzida e mantida
|
||
|
|
|
||
|
|
4. **Comunicação de Riscos**: Comunicar riscos de segurança e compliance aos stakeholders
|
||
|
|
|
||
|
|
#### 3.3.4.1. Aplicação de crédito em nuvem
|
||
|
|
|
||
|
|
1. Necessário verificar validade e crédito em USD do Voucher para verificar se atende o projeto;
|
||
|
|
|
||
|
|
2. Aplicar o voucher numa contra criada especificamente para o projeto ou no cliente consultando o EscritorioDeProjetos@Pragmatismo para tal, [Referência](https://www.microsoftazurepass.com/Home/HowTo).
|
||
|
|
|
||
|
|
3. Caso a conta especifica seja usada, ela será a administradora da nuvem. Convidar os envolvidos assim que a conta for criada e colocar operations@Pragmatismo como Administradora e as demais pessoas que terão este tipo de acesso.
|
||
|
|
|
||
|
|
#### 3.3.4.2. Reunião do Escritório de Projetos
|
||
|
|
|
||
|
|
1. Verificar se existem questões, requisitos, riscos, requisições de mudança e outras pendências antes da reunião.
|
||
|
|
|
||
|
|
2. Preparar a lista de itens pendentes para discussão com base em questões pendentes.
|
||
|
|
|
||
|
|
3. Além dos itens de controle da aplicação, apresentar cronograma & escopo juntamente da satisfação geral do cliente.
|
||
|
|
|
||
|
|
4. Incluir na pauta itens específicos sobre compliance e segurança.
|
||
|
|
|
||
|
|
### 3.3.5. Analista Desenvolvedor(a)
|
||
|
|
|
||
|
|
Quem identifica requisitos e os codifica em código-fontes e ativos associados de acordo com as melhores práticas da indústria. Para projetos de IA e General Bots, o(a) analista desenvolvedor(a) também deve:
|
||
|
|
|
||
|
|
1. **Desenvolvimento Seguro**: Aplicar práticas de desenvolvimento seguro em todo o código
|
||
|
|
|
||
|
|
2. **Tratamento Seguro de Dados**: Implementar mecanismos seguros para processamento e armazenamento de dados
|
||
|
|
|
||
|
|
3. **Testes de Segurança**: Realizar testes unitários que incluam casos de teste de segurança
|
||
|
|
|
||
|
|
4. **Revisão de Código**: Participar de revisões de código com foco em segurança e compliance
|
||
|
|
|
||
|
|
### 3.3.6. Analista de Qualidade
|
||
|
|
|
||
|
|
Quem certifica que os requisitos especificados estão de acordo com a experiência final de utilização ou operação do projeto. Para projetos de IA e General Bots, o analista de qualidade também deve:
|
||
|
|
|
||
|
|
1. **Testes de Segurança**: Realizar testes específicos de segurança e privacidade
|
||
|
|
|
||
|
|
2. **Verificação de Compliance**: Verificar se os requisitos de compliance foram atendidos
|
||
|
|
|
||
|
|
3. **Testes de Penetração**: Coordenar ou realizar testes de penetração
|
||
|
|
|
||
|
|
4. **Análise de Vulnerabilidades**: Realizar varreduras de vulnerabilidade regularmente
|
||
|
|
|
||
|
|
#### 3.3.6.1. Métodos
|
||
|
|
|
||
|
|
##### BDD com Gherkin
|
||
|
|
|
||
|
|
[Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin)
|
||
|
|
|
||
|
|
Para projetos de IA e General Bots, recomenda-se a adaptação do BDD para incluir critérios específicos de segurança e compliance:
|
||
|
|
|
||
|
|
```gherkin
|
||
|
|
Funcionalidade: Processamento seguro de dados pessoais
|
||
|
|
Como um usuário do sistema
|
||
|
|
Eu quero que meus dados pessoais sejam processados de forma segura
|
||
|
|
Para que minha privacidade seja protegida
|
||
|
|
|
||
|
|
Cenário: Armazenamento de dados sensíveis
|
||
|
|
Dado que eu forneço dados sensíveis ao sistema
|
||
|
|
Quando os dados são armazenados
|
||
|
|
Então os dados devem ser criptografados
|
||
|
|
E o acesso aos dados deve ser registrado em log de auditoria
|
||
|
|
E os dados devem ter uma política de retenção definida
|
||
|
|
```
|
||
|
|
|
||
|
|
### 3.3.7. Oficial de Segurança da Informação
|
||
|
|
|
||
|
|
Papel específico para projetos de IA e General Bots com requisitos rigorosos de segurança e compliance:
|
||
|
|
|
||
|
|
1. **Avaliação de Segurança**: Realizar avaliações regulares de segurança do projeto
|
||
|
|
|
||
|
|
2. **Definição de Políticas**: Definir políticas de segurança específicas para o projeto
|
||
|
|
|
||
|
|
3. **Resposta a Incidentes**: Coordenar a resposta a incidentes de segurança
|
||
|
|
|
||
|
|
4. **Conformidade Regulatória**: Garantir que o projeto esteja em conformidade com regulamentações aplicáveis
|
||
|
|
|
||
|
|
### 3.3.8. Especialista em Compliance
|
||
|
|
|
||
|
|
Papel específico para projetos com requisitos rigorosos de compliance:
|
||
|
|
|
||
|
|
1. **Interpretação Regulatória**: Interpretar requisitos regulatórios e traduzi-los em requisitos técnicos
|
||
|
|
|
||
|
|
2. **Documentação de Compliance**: Preparar e manter documentação de compliance
|
||
|
|
|
||
|
|
3. **Auditorias**: Conduzir auditorias internas de compliance
|
||
|
|
|
||
|
|
4. **Remediação**: Coordenar esforços de remediação para problemas de compliance identificados
|
||
|
|
|
||
|
|
## 3.4. Configuração e Uso do ALM
|
||
|
|
|
||
|
|
### 3.4.1. Configuração Inicial do Projeto
|
||
|
|
|
||
|
|
1. **Criação do Projeto**: Criar o projeto no ALM utilizando o modelo CMMI
|
||
|
|
|
||
|
|
2. **Configuração de Áreas**: Configurar áreas para organizar o trabalho, incluindo áreas específicas para compliance
|
||
|
|
|
||
|
|
3. **Configuração de Iterações**: Configurar iterações alinhadas ao cronograma do projeto
|
||
|
|
|
||
|
|
4. **Configuração de Políticas**: Configurar políticas de branch, build e release
|
||
|
|
|
||
|
|
5. **Configuração de Dashboards**: Configurar dashboards para visualização do status do projeto e métricas de compliance
|
||
|
|
|
||
|
|
### 3.4.2. Gestão de Requisitos
|
||
|
|
|
||
|
|
1. **Cadastro de Requisitos**: Cadastrar requisitos funcionais, não funcionais e de compliance
|
||
|
|
|
||
|
|
2. **Rastreabilidade**: Estabelecer links de rastreabilidade entre requisitos, testes e código
|
||
|
|
|
||
|
|
3. **Priorização**: Priorizar requisitos considerando impacto em segurança e compliance
|
||
|
|
|
||
|
|
4. **Aprovação**: Estabelecer processo de aprovação formal para requisitos
|
||
|
|
|
||
|
|
### 3.4.3. Gestão de Código-Fonte
|
||
|
|
|
||
|
|
1. **Organização de Repositórios**: Organizar repositórios de forma a facilitar a gestão de segurança e compliance
|
||
|
|
|
||
|
|
2. **Controle de Versão**: Utilizar práticas robustas de controle de versão
|
||
|
|
|
||
|
|
3. **Branches e Pull Requests**: Utilizar branches e pull requests para revisão de código
|
||
|
|
|
||
|
|
4. **Políticas de Branch**: Configurar políticas de branch que exijam revisão de código
|
||
|
|
|
||
|
|
### 3.4.4. Gestão de Build e Release
|
||
|
|
|
||
|
|
1. **Pipelines de CI/CD**: Configurar pipelines de integração contínua e entrega contínua
|
||
|
|
|
||
|
|
2. **Gates de Qualidade**: Implementar gates de qualidade nos pipelines
|
||
|
|
|
||
|
|
3. **Aprovações**: Configurar aprovações necessárias para releases em ambientes de produção
|
||
|
|
|
||
|
|
4. **Logs de Auditoria**: Configurar logs de auditoria detalhados para todas as atividades de build e release
|
||
|
|
|
||
|
|
### 3.4.5. Gestão de Testes
|
||
|
|
|
||
|
|
1. **Planejamento de Testes**: Planejar testes de forma abrangente, incluindo testes de segurança e compliance
|
||
|
|
|
||
|
|
2. **Execução de Testes**: Executar testes de forma automatizada sempre que possível
|
||
|
|
|
||
|
|
3. **Relatórios de Teste**: Gerar relatórios detalhados dos resultados dos testes
|
||
|
|
|
||
|
|
4. **Cobertura de Testes**: Monitorar e melhorar continuamente a cobertura de testes
|
||
|
|
|
||
|
|
### 3.4.6. Gestão de Incidentes e Defeitos
|
||
|
|
|
||
|
|
1. **Registro de Incidentes**: Registrar todos os incidentes, incluindo incidentes de segurança
|
||
|
|
|
||
|
|
2. **Classificação de Incidentes**: Classificar incidentes por gravidade e impacto
|
||
|
|
|
||
|
|
3. **Resolução de Incidentes**: Resolver incidentes de acordo com SLAs definidos
|
||
|
|
|
||
|
|
4. **Análise de Causa Raiz**: Realizar análise de causa raiz para incidentes significativos
|
||
|
|
|
||
|
|
### 3.4.7. Gestão de Documentação
|
||
|
|
|
||
|
|
1. **Documentação Técnica**: Manter documentação técnica atualizada
|
||
|
|
|
||
|
|
2. **Documentação de Compliance**: Manter documentação específica de compliance
|
||
|
|
|
||
|
|
3. **Documentação de Segurança**: Manter documentação de segurança atualizada
|
||
|
|
|
||
|
|
4. **Documentação de Operações**: Manter documentação de operações atualizada
|
||
|
|
|
||
|
|
## 3.5. Específico para Projetos de IA e General Bots
|
||
|
|
|
||
|
|
### 3.5.1. Requisitos Específicos
|
||
|
|
|
||
|
|
1. **Rastreabilidade de Dados de Treinamento**: Manter rastreabilidade completa dos dados utilizados para treinamento de modelos de IA
|
||
|
|
|
||
|
|
2. **Documentação de Algoritmos**: Documentar detalhadamente os algoritmos utilizados
|
||
|
|
|
||
|
|
3. **Registro de Experimentos**: Manter registro detalhado dos experimentos realizados
|
||
|
|
|
||
|
|
4. **Versionamento de Modelos**: Implementar versionamento robusto de modelos de IA
|
||
|
|
|
||
|
|
### 3.5.2. Testes Específicos
|
||
|
|
|
||
|
|
1. **Testes de Viés**: Realizar testes para identificar e mitigar viés nos modelos de IA
|
||
|
|
|
||
|
|
2. **Testes de Robustez**: Testar a robustez dos modelos contra entradas adversariais
|
||
|
|
|
||
|
|
3. **Testes de Explicabilidade**: Verificar a explicabilidade dos resultados dos modelos
|
||
|
|
|
||
|
|
4. **Testes de Conformidade Ética**: Verificar conformidade com princípios éticos de IA
|
||
|
|
|
||
|
|
### 3.5.3. Monitoramento Específico
|
||
|
|
|
||
|
|
1. **Monitoramento de Drift**: Monitorar drift em modelos de IA em produção
|
||
|
|
|
||
|
|
2. **Monitoramento de Performance**: Monitorar continuamente a performance dos modelos
|
||
|
|
|
||
|
|
3. **Monitoramento de Uso**: Monitorar padrões de uso dos modelos
|
||
|
|
|
||
|
|
4. **Alertas de Anomalias**: Configurar alertas para comportamentos anômalos
|
||
|
|
|
||
|
|
## 3.6. Compliance e Regulamentações
|
||
|
|
|
||
|
|
### 3.6.1. ISO 27001
|
||
|
|
|
||
|
|
1. **Mapeamento de Requisitos**: Mapear requisitos da ISO 27001 para requisitos do sistema
|
||
|
|
|
||
|
|
2. **Controles Técnicos**: Implementar controles técnicos requeridos pela ISO 27001
|
||
|
|
|
||
|
|
3. **Documentação**: Manter documentação requerida pela ISO 27001
|
||
|
|
|
||
|
|
4. **Auditorias**: Preparar para auditorias de certificação e recertificação
|
||
|
|
|
||
|
|
### 3.6.2. HIPAA
|
||
|
|
|
||
|
|
1. **PHI (Protected Health Information)**: Implementar proteções específicas para PHI
|
||
|
|
|
||
|
|
2. **BAAs (Business Associate Agreements)**: Gerenciar BAAs com fornecedores
|
||
|
|
|
||
|
|
3. **Notificação de Violações**: Implementar procedimentos para notificação de violações
|
||
|
|
|
||
|
|
4. **Treinamento**: Realizar treinamento específico sobre HIPAA
|
||
|
|
|
||
|
|
### 3.6.3. LGPD
|
||
|
|
|
||
|
|
1. **Bases Legais**: Documentar bases legais para processamento de dados
|
||
|
|
|
||
|
|
2. **Direitos dos Titulares**: Implementar mecanismos para atender direitos dos titulares
|
||
|
|
|
||
|
|
3. **Relatório de Impacto**: Realizar relatórios de impacto à proteção de dados pessoais
|
||
|
|
|
||
|
|
4. **DPO (Data Protection Officer)**: Designar e suportar o DPO
|
||
|
|
|
||
|
|
### 3.6.4. Outras Regulamentações
|
||
|
|
|
||
|
|
1. **GDPR**: Para projetos com impacto na União Europeia
|
||
|
|
|
||
|
|
2. **CCPA/CPRA**: Para projetos com impacto na Califórnia
|
||
|
|
|
||
|
|
3. **Regulamentações Setoriais**: Para projetos em setores específicos (financeiro, saúde, etc.)
|
||
|
|
|
||
|
|
4. **Regulamentações Locais**: Para projetos com impacto em jurisdições específicas
|
||
|
|
|
||
|
|
## 3.7. Métricas e KPIs
|
||
|
|
|
||
|
|
### 3.7.1. Métricas de Qualidade
|
||
|
|
|
||
|
|
1. **Densidade de Defeitos**: Número de defeitos por linhas de código
|
||
|
|
|
||
|
|
2. **Cobertura de Testes**: Percentual do código coberto por testes
|
||
|
|
|
||
|
|
3. **Taxa de Retrabalho**: Percentual de código que precisa ser reescrito
|
||
|
|
|
||
|
|
4. **Tempo Médio de Resolução de Defeitos**: Tempo médio para resolver defeitos
|
||
|
|
|
||
|
|
### 3.7.2. Métricas de Segurança
|
||
|
|
|
||
|
|
1. **Vulnerabilidades Encontradas**: Número de vulnerabilidades encontradas em varreduras
|
||
|
|
|
||
|
|
2. **Tempo de Remediação de Vulnerabilidades**: Tempo médio para remediar vulnerabilidades
|
||
|
|
|
||
|
|
3. **Cobertura de Testes de Segurança**: Percentual de requisitos de segurança testados
|
||
|
|
|
||
|
|
4. **Incidentes de Segurança**: Número e gravidade de incidentes de segurança
|
||
|
|
|
||
|
|
### 3.7.3. Métricas de Compliance
|
||
|
|
|
||
|
|
1. **Conformidade com Requisitos**: Percentual de requisitos de compliance atendidos
|
||
|
|
|
||
|
|
2. **Achados de Auditoria**: Número e gravidade de achados em auditorias
|
||
|
|
|
||
|
|
3. **Tempo de Remediação**: Tempo médio para remediar achados de auditoria
|
||
|
|
|
||
|
|
4. **Cobertura de Treinamento**: Percentual da equipe treinada em requisitos de compliance
|
||
|
|
|
||
|
|
### 3.7.4. Métricas Específicas para IA e General Bots
|
||
|
|
|
||
|
|
1. **Acurácia do Modelo**: Medida da acurácia dos modelos de IA
|
||
|
|
|
||
|
|
2. **Taxa de Falsos Positivos/Negativos**: Taxa de falsos positivos e negativos
|
||
|
|
|
||
|
|
3. **Latência**: Tempo de resposta dos modelos em produção
|
||
|
|
|
||
|
|
4. **Uso de Recursos**: Uso de recursos computacionais pelos modelos
|
||
|
|
|
||
|
|
## 3.8. Melhores Práticas
|
||
|
|
|
||
|
|
### 3.8.1. Melhores Práticas Gerais
|
||
|
|
|
||
|
|
1. **Revisões Regulares**: Realizar revisões regulares de código, arquitetura e documentação
|
||
|
|
|
||
|
|
2. **Automação**: Automatizar o máximo possível do processo de desenvolvimento e testes
|
||
|
|
|
||
|
|
3. **Documentação**: Manter documentação atualizada e acessível
|
||
|
|
|
||
|
|
4. **Treinamento**: Investir em treinamento contínuo da equipe
|
||
|
|
|
||
|
|
### 3.8.2. Melhores Práticas de Segurança
|
||
|
|
|
||
|
|
1. **Security by Design**: Incorporar segurança desde o início do projeto
|
||
|
|
|
||
|
|
2. **Least Privilege**: Aplicar o princípio do privilégio mínimo
|
||
|
|
|
||
|
|
3. **Defense in Depth**: Implementar múltiplas camadas de defesa
|
||
|
|
|
||
|
|
4. **Regular Assessments**: Realizar avaliações regulares de segurança
|
||
|
|
|
||
|
|
### 3.8.3. Melhores Práticas de Compliance
|
||
|
|
|
||
|
|
1. **Privacy by Design**: Incorporar privacidade desde o início do projeto
|
||
|
|
|
||
|
|
2. **Data Minimization**: Coletar e armazenar apenas os dados necessários
|
||
|
|
|
||
|
|
3. **Regular Audits**: Realizar auditorias regulares de compliance
|
||
|
|
|
||
|
|
4. **Documentation**: Manter documentação detalhada de compliance
|
||
|
|
|
||
|
|
### 3.8.4. Melhores Práticas para IA e General Bots
|
||
|
|
|
||
|
|
1. **Ethical AI**: Seguir princípios éticos no desenvolvimento de IA
|
||
|
|
|
||
|
|
2. **Explainable AI**: Desenvolver modelos explicáveis sempre que possível
|
||
|
|
|
||
|
|
3. **Human Oversight**: Manter supervisão humana sobre decisões críticas
|
||
|
|
|
||
|
|
4. **Continuous Monitoring**: Monitorar continuamente o comportamento dos modelos
|
||
|
|
|
||
|
|
## 3.9. Tratamento de Defeitos
|
||
|
|
|
||
|
|
### 3.9.1 Desenvolvimento
|
||
|
|
|
||
|
|
1. Uma notificação do ALM é recebida;
|
||
|
|
2. O exame do item de trabalho é realizado destinado a definir o Defeito como sendo um item de trabalho interno, através da classificação como Ativo, ao cálculo do esforço em horas para a resolução;
|
||
|
|
3. Verifique se o relato do erro contém informações suficientes para a análise, do contrário, solicite tais informações de volta e finalize este ciclo;
|
||
|
|
4. Determinar se o defeito é originado da plataforma ou da aplicação;
|
||
|
|
5. Através do texto contido no Log, encontre a possível localização do problema no código-fonte.
|
||
|
|
|
||
|
|
Notas
|
||
|
|
* Os defeitos devem conter o Log emitido pela aplicação, caso a aplicação não esteja disponibilizando informações suficientemente, é necessário que uma alteração seja realizada para a melhoria do Log;
|
||
|
|
* Informações visuais como cor, podem ser adicionadas ao Log de modo a facilitar a leitura de modo complementar.
|
||
|
|
* Capturas de telas devem ser acompanhadas dos Log textuais relativas ao mesmo momento da captura
|
||
|
|
* Caso documentos sejam enviados, uma cópia contendo referências ao ALM deve ser criada e remetida de volta.
|
||
|
|
|
||
|
|
### 3.9.2. Classificação de Defeitos
|
||
|
|
|
||
|
|
1. **Crítico**: Impacto significativo na segurança, privacidade ou funcionalidade core
|
||
|
|
2. **Alto**: Impacto na funcionalidade principal, mas sem comprometer segurança ou privacidade
|
||
|
|
3. **Médio**: Impacto em funcionalidades secundárias
|
||
|
|
4. **Baixo**: Impacto cosmético ou de usabilidade menor
|
||
|
|
|
||
|
|
### 3.9.3. SLAs para Resolução de Defeitos
|
||
|
|
|
||
|
|
| Classificação | Tempo de Resposta | Tempo de Resolução |
|
||
|
|
|---------------|-------------------|-------------------|
|
||
|
|
| Crítico | 2 horas | 24 horas |
|
||
|
|
| Alto | 4 horas | 48 horas |
|
||
|
|
| Médio | 8 horas | 5 dias úteis |
|
||
|
|
| Baixo | 16 horas | 10 dias úteis |
|
||
|
|
|
||
|
|
### 3.9.4. Processo de Escalonamento
|
||
|
|
|
||
|
|
1. **Nível 1**: Analista Desenvolvedor(a) responsável
|
||
|
|
2. **Nível 2**: Arquiteta de Solução
|
||
|
|
3. **Nível 3**: Gerente de Projetos
|
||
|
|
4. **Nível 4**: Diretoria
|
||
|
|
|
||
|
|
## 3.10. Ferramentas e Integração
|
||
|
|
|
||
|
|
1. **Azure DevOps**: Gerenciamento de ciclo de vida
|
||
|
|
2. **GitHub**: Repositório de código e automaçãos
|
||
|
|
3. **Jira**: Gestão de tarefas e defeitos (opcional)
|
||
|
|
4. **Confluence**: Documentação colaborativa (opcional)
|
||
|
|
5. **Forgejo**: ALM open-source
|
||
|
|
|
||
|
|
## 3.11. Templates e Artefatos
|
||
|
|
|
||
|
|
### 3.11.1. Templates de Documentação
|
||
|
|
|
||
|
|
1. **Documento de Requisitos**: Template padronizado para documentação de requisitos
|
||
|
|
2. **Plano de Testes**: Template para planos de teste, incluindo testes de segurança e compliance
|
||
|
|
3. **Relatório de Segurança**: Template para relatórios de segurança
|
||
|
|
4. **Relatório de Compliance**: Template para relatórios de compliance
|
||
|
|
|
||
|
|
### 3.11.2. Checklists
|
||
|
|
|
||
|
|
1. **Checklist de Segurança**: Para revisão de segurança
|
||
|
|
2. **Checklist de Compliance**: Para revisão de compliance
|
||
|
|
3. **Checklist de Qualidade**: Para revisão de qualidade
|
||
|
|
4. **Checklist de Prontidão para Produção**: Para revisão antes da implantação
|
||
|
|
|
||
|
|
### 3.11.3. Scripts e Automações
|
||
|
|
|
||
|
|
1. **Scripts de Análise**: Scripts para análise automatizada de código
|
||
|
|
2. **Scripts de Deploy**: Scripts para implantação automatizada
|
||
|
|
3. **Scripts de Teste**: Scripts para testes automatizados
|
||
|
|
4. **Scripts de Monitoramento**: Scripts para monitoramento automatizado
|
||
|
|
|
||
|
|
# Links
|
||
|
|
|
||
|
|
| Title | Address |
|
||
|
|
|------------------------------|--------------------------------------------------------------------------------------------|
|
||
|
|
| Scaled Agile Framework & TFS | https://msdn.microsoft.com/pt-br/library/dn798712.aspx?f=255&MSPPError=-2147217396 |
|
||
|
|
| ISO 27001 Overview | https://www.iso.org/isoiec-27001-information-security.html |
|
||
|
|
| LGPD Guide | https://www.gov.br/cidadania/pt-br/acesso-a-informacao/lgpd |
|
||
|
|
| HIPAA Guidelines | https://www.hhs.gov/hipaa/for-professionals/index.html |
|
||
|
|
| Azure DevOps Documentation | https://docs.microsoft.com/en-us/azure/devops/?view=azure-devops |
|
||
|
|
| Microsoft Security Guide | https://docs.microsoft.com/en-us/security/ |
|
||
|
|
| OWASP Top 10 | https://owasp.org/www-project-top-ten/ |
|
||
|
|
| ML Ops Guide | https://ml-ops.org/ |
|
||
|
|
|
||
|
|
## 3.13. Gestão de Dados no ALM
|
||
|
|
|
||
|
|
### 3.13.1. Classificação de Dados
|
||
|
|
|
||
|
|
A classificação de dados é essencial para projetos de IA e General Bots, especialmente para garantir a conformidade com regulamentações como LGPD e HIPAA. O ALM da Pragmatismo implementa as seguintes categorias de classificação:
|
||
|
|
|
||
|
|
1. **Dados Públicos**: Informações que podem ser livremente divulgadas sem restrições
|
||
|
|
2. **Dados Internos**: Informações para uso interno da organização
|
||
|
|
3. **Dados Confidenciais**: Informações sensíveis que requerem proteção adicional
|
||
|
|
4. **Dados Restritos**: Informações altamente sensíveis com proteções rigorosas
|
||
|
|
|
||
|
|
Cada categoria possui controles específicos de acesso, armazenamento, processamento e transferência que devem ser implementados e documentados no ALM.
|
||
|
|
|
||
|
|
### 3.13.2. Ciclo de Vida dos Dados
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa um ciclo de vida completo para dados utilizados em projetos de IA e General Bots:
|
||
|
|
|
||
|
|
1. **Coleta**: Documentação da origem, base legal e consentimento
|
||
|
|
2. **Processamento**: Aplicação de controles de segurança apropriados
|
||
|
|
3. **Armazenamento**: Implementação de criptografia e controles de acesso
|
||
|
|
4. **Transferência**: Proteção durante a transferência interna ou externa
|
||
|
|
5. **Arquivamento**: Processo seguro para dados que precisam ser retidos
|
||
|
|
6. **Eliminação**: Processo seguro para apagar dados que não são mais necessários
|
||
|
|
|
||
|
|
### 3.13.3. Registros de Processamento de Dados
|
||
|
|
|
||
|
|
Para conformidade com a LGPD e outras regulamentações, o ALM mantém registros detalhados de todas as atividades de processamento de dados:
|
||
|
|
|
||
|
|
1. **Finalidade do processamento**: Documentação clara da finalidade
|
||
|
|
2. **Categorias de dados**: Tipos de dados processados
|
||
|
|
3. **Categorias de titulares**: Indivíduos cujos dados são processados
|
||
|
|
4. **Categorias de destinatários**: Entidades com quem os dados são compartilhados
|
||
|
|
5. **Transferências internacionais**: Detalhes de transferências para outros países
|
||
|
|
6. **Prazos de retenção**: Período pelo qual os dados serão mantidos
|
||
|
|
7. **Medidas de segurança**: Descrição das medidas técnicas e organizacionais
|
||
|
|
|
||
|
|
## 3.14. Segurança no ALM
|
||
|
|
|
||
|
|
### 3.14.1. Princípios de Segurança
|
||
|
|
|
||
|
|
O ALM da Pragmatismo é fundamentado nos seguintes princípios de segurança:
|
||
|
|
|
||
|
|
1. **Security by Design**: Segurança incorporada desde o início do projeto
|
||
|
|
2. **Defense in Depth**: Múltiplas camadas de controles de segurança
|
||
|
|
3. **Least Privilege**: Acesso mínimo necessário para realizar a função
|
||
|
|
4. **Segregation of Duties**: Separação de responsabilidades críticas
|
||
|
|
5. **Secure Default Configuration**: Configurações padrão seguras
|
||
|
|
6. **Fail Secure**: Em caso de falha, o sistema deve falhar de forma segura
|
||
|
|
7. **Continuous Improvement**: Aprimoramento contínuo da postura de segurança
|
||
|
|
|
||
|
|
### 3.14.2. Controles de Segurança no ALM
|
||
|
|
|
||
|
|
Os seguintes controles de segurança são implementados no ALM da Pragmatismo:
|
||
|
|
|
||
|
|
1. **Autenticação**: MFA (Multi-Factor Authentication) para acesso ao ALM
|
||
|
|
2. **Autorização**: Controle de acesso baseado em papéis (RBAC)
|
||
|
|
3. **Criptografia**: Criptografia em trânsito e em repouso
|
||
|
|
4. **Logging e Monitoramento**: Registro e análise de atividades
|
||
|
|
5. **Gestão de Vulnerabilidades**: Processo para identificação e remediação
|
||
|
|
6. **Segurança de Código**: Análise estática e dinâmica de código
|
||
|
|
7. **Segurança de Infraestrutura**: Hardening e configuração segura
|
||
|
|
|
||
|
|
### 3.14.3. DevSecOps
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa práticas de DevSecOps para integrar segurança ao longo do ciclo de desenvolvimento:
|
||
|
|
|
||
|
|
1. **Treinamento**: Capacitação regular da equipe em práticas seguras
|
||
|
|
2. **Automação**: Automação de verificações de segurança nos pipelines
|
||
|
|
3. **Feedback Rápido**: Feedback imediato sobre problemas de segurança
|
||
|
|
4. **Remediação Contínua**: Processo ágil para correção de vulnerabilidades
|
||
|
|
5. **Colaboração**: Colaboração entre equipes de desenvolvimento e segurança
|
||
|
|
6. **Medição**: Métricas para avaliar a postura de segurança
|
||
|
|
7. **Melhoria Contínua**: Processo de aprimoramento contínuo
|
||
|
|
|
||
|
|
## 3.15. Gestão de Projetos de IA no ALM
|
||
|
|
|
||
|
|
### 3.15.1. Características Específicas de Projetos de IA
|
||
|
|
|
||
|
|
Projetos de IA e General Bots apresentam características específicas que devem ser consideradas no ALM:
|
||
|
|
|
||
|
|
1. **Experimentação Iterativa**: Processo mais experimental que desenvolvimento tradicional
|
||
|
|
2. **Gestão de Dados**: Volumes maiores e mais complexos de dados
|
||
|
|
3. **Reprodutibilidade**: Necessidade de reproduzir experimentos e resultados
|
||
|
|
4. **Explicabilidade**: Requisito de explicar decisões e previsões
|
||
|
|
5. **Monitoramento de Modelos**: Necessidade de monitorar drift e desempenho
|
||
|
|
6. **Requisitos Éticos**: Considerações éticas específicas para IA
|
||
|
|
7. **Regulamentações Específicas**: Requisitos regulatórios para sistemas de IA
|
||
|
|
|
||
|
|
### 3.15.2. Adaptação do ALM para Projetos de IA
|
||
|
|
|
||
|
|
O ALM da Pragmatismo é adaptado para atender às necessidades específicas de projetos de IA:
|
||
|
|
|
||
|
|
1. **MLOps**: Integração de práticas de MLOps ao ALM
|
||
|
|
2. **Versionamento de Dados**: Controle de versão para conjuntos de dados
|
||
|
|
3. **Registro de Experimentos**: Documentação detalhada de experimentos
|
||
|
|
4. **Avaliação de Modelos**: Critérios e métricas para avaliação
|
||
|
|
5. **Integração de Modelos**: Processo para integração de modelos ao produto
|
||
|
|
6. **Monitoramento de Modelos**: Ferramentas para monitoramento em produção
|
||
|
|
7. **Governança de IA**: Estrutura para governança de sistemas de IA
|
||
|
|
|
||
|
|
### 3.15.3. Artefatos Específicos para Projetos de IA
|
||
|
|
|
||
|
|
Além dos artefatos tradicionais, o ALM para projetos de IA inclui:
|
||
|
|
|
||
|
|
1. **Catálogo de Dados**: Documentação detalhada dos conjuntos de dados
|
||
|
|
2. **Cartões de Modelo**: Documentação das características e limitações dos modelos
|
||
|
|
3. **Relatórios de Experimentos**: Documentação detalhada de experimentos
|
||
|
|
4. **Avaliações de Viés**: Análises de viés nos modelos
|
||
|
|
5. **Avaliações de Explicabilidade**: Análises da explicabilidade dos modelos
|
||
|
|
6. **Relatórios de Monitoramento**: Documentação do desempenho em produção
|
||
|
|
7. **Avaliações Éticas**: Análises das implicações éticas
|
||
|
|
|
||
|
|
## 3.16. Gestão de Riscos no ALM
|
||
|
|
|
||
|
|
### 3.16.1. Processo de Gestão de Riscos
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa um processo estruturado de gestão de riscos:
|
||
|
|
|
||
|
|
1. **Identificação**: Identificação sistemática de riscos
|
||
|
|
2. **Análise**: Avaliação da probabilidade e impacto
|
||
|
|
3. **Avaliação**: Priorização com base em critérios definidos
|
||
|
|
4. **Tratamento**: Desenvolvimento e implementação de planos de mitigação
|
||
|
|
5. **Monitoramento**: Acompanhamento contínuo da eficácia das medidas
|
||
|
|
6. **Comunicação**: Comunicação regular sobre riscos aos stakeholders
|
||
|
|
7. **Melhoria**: Aprimoramento contínuo do processo
|
||
|
|
|
||
|
|
### 3.16.2. Categorias de Riscos para Projetos de IA e General Bots
|
||
|
|
|
||
|
|
O ALM considera as seguintes categorias de riscos específicas para projetos de IA:
|
||
|
|
|
||
|
|
1. **Riscos Técnicos**: Relacionados à tecnologia e sua implementação
|
||
|
|
2. **Riscos de Dados**: Relacionados à qualidade, disponibilidade e segurança dos dados
|
||
|
|
3. **Riscos Éticos**: Relacionados às implicações éticas do sistema
|
||
|
|
4. **Riscos Regulatórios**: Relacionados à conformidade com regulamentações
|
||
|
|
5. **Riscos de Mercado**: Relacionados à aceitação do mercado
|
||
|
|
6. **Riscos Operacionais**: Relacionados à operação do sistema
|
||
|
|
7. **Riscos Reputacionais**: Relacionados à reputação da organização
|
||
|
|
|
||
|
|
### 3.16.3. Matriz de Riscos
|
||
|
|
|
||
|
|
O ALM utiliza uma matriz de riscos para categorizar e priorizar riscos:
|
||
|
|
|
||
|
|
| Probabilidade/Impacto | Baixo | Médio | Alto | Crítico |
|
||
|
|
|-----------------------|-------|-------|------|---------|
|
||
|
|
| Muito Alta | Médio | Alto | Crítico | Crítico |
|
||
|
|
| Alta | Médio | Médio | Alto | Crítico |
|
||
|
|
| Média | Baixo | Médio | Alto | Alto |
|
||
|
|
| Baixa | Baixo | Baixo | Médio | Alto |
|
||
|
|
| Muito Baixa | Baixo | Baixo | Baixo | Médio |
|
||
|
|
|
||
|
|
## 3.17. Auditoria e Compliance no ALM
|
||
|
|
|
||
|
|
### 3.17.1. Processo de Auditoria
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa um processo estruturado de auditoria:
|
||
|
|
|
||
|
|
1. **Planejamento**: Definição do escopo, objetivos e critérios
|
||
|
|
2. **Preparação**: Coleta de informações e documentação
|
||
|
|
3. **Execução**: Realização da auditoria com base no planejamento
|
||
|
|
4. **Relatório**: Documentação dos resultados e achados
|
||
|
|
5. **Acompanhamento**: Monitoramento da implementação das correções
|
||
|
|
6. **Fechamento**: Encerramento formal da auditoria
|
||
|
|
7. **Aprendizado**: Incorporação de lições aprendidas
|
||
|
|
|
||
|
|
### 3.17.2. Trilhas de Auditoria
|
||
|
|
|
||
|
|
O ALM mantém trilhas de auditoria para as seguintes atividades:
|
||
|
|
|
||
|
|
1. **Acesso ao Sistema**: Registro de todas as tentativas de acesso
|
||
|
|
2. **Alterações de Configuração**: Registro de alterações em configurações
|
||
|
|
3. **Alterações de Código**: Registro de alterações em código-fonte
|
||
|
|
4. **Implantações**: Registro de todas as implantações
|
||
|
|
5. **Processamento de Dados**: Registro de operações de processamento de dados
|
||
|
|
6. **Incidentes de Segurança**: Registro de incidentes e resposta
|
||
|
|
7. **Atividades Administrativas**: Registro de atividades administrativas
|
||
|
|
|
||
|
|
### 3.17.3. Relatórios de Compliance
|
||
|
|
|
||
|
|
O ALM gera os seguintes relatórios de compliance:
|
||
|
|
|
||
|
|
1. **Relatório de Análise de Lacunas**: Identificação de lacunas de conformidade
|
||
|
|
1. **Plano de Ação de Remediação**: Plano para resolver lacunas identificadas
|
||
|
|
1. **Relatório de Progresso**: Acompanhamento da implementação de correções
|
||
|
|
1. **Relatório de Incidentes**: Detalhes sobre incidentes e resposta
|
||
|
|
|
||
|
|
## 3.18. Treinamento e Capacitação
|
||
|
|
|
||
|
|
### 3.18.1. Programa de Treinamento ALM
|
||
|
|
|
||
|
|
O programa de treinamento ALM da Pragmatismo inclui:
|
||
|
|
|
||
|
|
1. **Onboarding**: Treinamento inicial para novos membros da equipe
|
||
|
|
2. **Treinamento Técnico**: Capacitação em ferramentas e tecnologias
|
||
|
|
3. **Treinamento de Segurança**: Capacitação em práticas de segurança
|
||
|
|
4. **Treinamento de Compliance**: Capacitação em requisitos regulatórios
|
||
|
|
5. **Treinamento Específico de IA**: Capacitação em desenvolvimento de IA
|
||
|
|
6. **Treinamento Ético**: Capacitação em questões éticas de IA
|
||
|
|
7. **Treinamento de Liderança**: Capacitação para gerentes e líderes
|
||
|
|
|
||
|
|
### 3.18.2. Materiais de Treinamento
|
||
|
|
|
||
|
|
Os seguintes materiais de treinamento são disponibilizados:
|
||
|
|
|
||
|
|
1. **Documentação**: Documentação detalhada de processos e ferramentas
|
||
|
|
2. **Vídeos**: Tutoriais em vídeo para conceitos importantes
|
||
|
|
3. **Workshops**: Materiais para workshops interativos
|
||
|
|
4. **Guides**: Guias passo-a-passo para tarefas comuns
|
||
|
|
5. **FAQs**: Respostas para perguntas frequentes
|
||
|
|
6. **Case Studies**: Estudos de caso para aprendizado baseado em problemas
|
||
|
|
7. **Simulações**: Simulações para prática em ambiente seguro
|
||
|
|
|
||
|
|
### 3.18.3. Certificações Recomendadas
|
||
|
|
|
||
|
|
As seguintes certificações são recomendadas para a equipe:
|
||
|
|
|
||
|
|
1. **Segurança**: Certificações em segurança da informação (CISSP, Security+)
|
||
|
|
1. **Compliance**: Certificações em compliance (CISA, CRISC)
|
||
|
|
1. **IA e ML**: Certificações em IA e Machine Learning
|
||
|
|
1. **Cloud**: Certificações em plataformas de nuvem (Azure, AWS)
|
||
|
|
1. **Ágil/Scrum**: Certificações em metodologias ágeis
|
||
|
|
1. **Específicas da Indústria**: Certificações relacionadas à indústria do cliente
|
||
|
|
|
||
|
|
## 3.19. Continuidade de Negócios
|
||
|
|
|
||
|
|
### 3.19.1. Backup e Recuperação
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa as seguintes práticas de backup e recuperação:
|
||
|
|
|
||
|
|
1. **Backup Regular**: Backup automatizado em intervalos definidos
|
||
|
|
2. **Verificação de Integridade**: Verificação regular da integridade dos backups
|
||
|
|
3. **Testes de Restauração**: Testes periódicos de restauração
|
||
|
|
4. **Armazenamento Seguro**: Armazenamento seguro de backups
|
||
|
|
5. **Retenção Adequada**: Política de retenção alinhada a requisitos regulatórios
|
||
|
|
6. **Documentação**: Documentação detalhada dos procedimentos
|
||
|
|
7. **Treinamento**: Capacitação da equipe em procedimentos de recuperação
|
||
|
|
|
||
|
|
### 3.19.2. Plano de Continuidade de Negócios
|
||
|
|
|
||
|
|
O ALM integra-se ao plano de continuidade de negócios através de:
|
||
|
|
|
||
|
|
1. **Análise de Impacto**: Identificação de sistemas e processos críticos
|
||
|
|
2. **Estratégias de Recuperação**: Definição de estratégias para diferentes cenários
|
||
|
|
3. **Planos de Resposta**: Procedimentos detalhados para diversos cenários
|
||
|
|
4. **Equipes de Resposta**: Definição clara de papéis e responsabilidades
|
||
|
|
5. **Comunicação**: Procedimentos de comunicação durante incidentes
|
||
|
|
6. **Testes Regulares**: Exercícios e simulações para validar planos
|
||
|
|
7. **Melhoria Contínua**: Aprimoramento contínuo com base em lições aprendidas
|
||
|
|
|
||
|
|
### 3.19.3. Gestão de Incidentes
|
||
|
|
|
||
|
|
O ALM implementa um processo estruturado de gestão de incidentes:
|
||
|
|
|
||
|
|
1. **Detecção**: Mecanismos para detecção rápida de incidentes
|
||
|
|
2. **Classificação**: Classificação de incidentes por gravidade e impacto
|
||
|
|
3. **Resposta**: Procedimentos para resposta a incidentes
|
||
|
|
4. **Contenção**: Medidas para limitar o impacto do incidente
|
||
|
|
5. **Erradicação**: Eliminação da causa raiz do incidente
|
||
|
|
6. **Recuperação**: Restauração de operações normais
|
||
|
|
7. **Aprendizado**: Incorporação de lições aprendidas
|
||
|
|
|
||
|
|
### 3.20.5. Configuração de Ambiente para Projetos de IA
|
||
|
|
|
||
|
|
1. **Ambiente Python**: Configuração de ambiente Python com ferramentas específicas
|
||
|
|
2. **Frameworks de IA**: Instalação de frameworks como TensorFlow, PyTorch
|
||
|
|
3. **Ferramentas de MLOps**: Instalação de ferramentas como MLflow, DVC
|
||
|
|
4. **Jupyter Notebooks**: Configuração para desenvolvimento exploratório
|
||
|
|
5. **Ferramentas de Visualização**: Instalação de bibliotecas de visualização
|
||
|
|
6. **Ferramentas de Processamento de Dados**: Instalação de bibliotecas de processamento
|
||
|
|
7. **Conexões com Serviços de Nuvem**: Configuração de conexões com serviços de nuvem
|
||
|
|
|
||
|
|
### 3.20.6. Configurações Recomendadas
|
||
|
|
|
||
|
|
#### Visual Studio Code Keybindings Sugeridos
|
||
|
|
|
||
|
|
```json
|
||
|
|
[
|
||
|
|
{ "key": "ctrl+shift+s", "command": "workbench.action.files.saveAll" },
|
||
|
|
{ "key": "ctrl+w", "command": "workbench.action.closeActiveEditor", "when": "!editorIsOpen" },
|
||
|
|
{ "key": "ctrl+shift+w", "command": "workbench.action.files.saveAll" }
|
||
|
|
]
|
||
|
|
```
|
||
|
|
|
||
|
|
#### Extensões Recomendadas para Visual Studio Code
|
||
|
|
|
||
|
|
1. **Python**: Suporte para desenvolvimento Python
|
||
|
|
2. **Jupyter**: Suporte para Jupyter Notebooks
|
||
|
|
6. **ESLint**: Análise estática para JavaScript
|
||
|
|
7. **Prettier**: Formatação de código
|
||
|
|
|
||
|
|
## 3.21. Processo de Entrega e Implantação
|
||
|
|
|
||
|
|
### 3.21.1. Entrega Contínua
|
||
|
|
|
||
|
|
O ALM da Pragmatismo implementa práticas de entrega contínua:
|
||
|
|
|
||
|
|
1. **Automação**: Automação completa do processo de build e deploy
|
||
|
|
2. **Testes Automatizados**: Execução automática de testes
|
||
|
|
3. **Ambientes**: Múltiplos ambientes (desenvolvimento, teste, produção)
|
||
|
|
4. **Promoção Controlada**: Promoção controlada entre ambientes
|
||
|
|
5. **Reversão Rápida**: Capacidade de reverter rapidamente mudanças
|
||
|
|
6. **Monitoramento**: Monitoramento contínuo de implantações
|
||
|
|
7. **Feedback Rápido**: Mecanismos para feedback rápido
|
||
|
|
|
||
|
|
### 3.21.2. Gates de Qualidade
|
||
|
|
|
||
|
|
Os seguintes gates de qualidade são implementados nos pipelines:
|
||
|
|
|
||
|
|
1. **Análise de Código**: Verificação de qualidade e segurança do código
|
||
|
|
2. **Testes Unitários**: Execução de testes unitários
|
||
|
|
3. **Testes de Integração**: Execução de testes de integração
|
||
|
|
4. **Testes de Segurança**: Execução de testes de segurança
|
||
|
|
5. **Testes de Performance**: Execução de testes de performance
|
||
|
|
6. **Testes de Compliance**: Verificação de compliance
|
||
|
|
7. **Aprovações**: Aprovações baseadas em papéis
|
||
|
|
|
||
|
|
### 3.21.3. Implantação Segura
|
||
|
|
|
||
|
|
O ALM implementa as seguintes práticas para implantação segura:
|
||
|
|
|
||
|
|
1. **Blue/Green Deployment**: Minimização de downtime e risco
|
||
|
|
2. **Canary Releases**: Implantação gradual para detecção precoce de problemas
|
||
|
|
3. **Feature Flags**: Controle granular de funcionalidades
|
||
|
|
4. **Rollback Automatizado**: Capacidade de reverter automaticamente em caso de falha
|
||
|
|
5. **Monitoramento Em Tempo Real**: Monitoramento durante a implantação
|
||
|
|
6. **Checklists de Implantação**: Verificações antes e após implantação
|
||
|
|
7. **Post-Mortem**: Análise detalhada após cada implantação significativa
|
||
|
|
|
||
|
|
### 3.21.4. Entrega do Código-Fonte
|
||
|
|
|
||
|
|
1. O código-fonte deve ser desenvolvido internamente no Projeto Base no processo de personalização;
|
||
|
|
|
||
|
|
2. A partir do momento em que a personalização via mecanismo declarativo atingiu o processo máximo, um desvio (branch) pode ser aberto para confecção do código sob medida da ou do cliente;
|
||
|
|
|
||
|
|
3. O código-fonte entregue deve conter apenas o código relativo à lista de requisitos do projeto, desativando as partes comuns (removendo o código) do Projeto Base não descritas na especificação original do projeto primordialmente para diminuir superfície de ataque.
|
||
|
|
|
||
|
|
4. **Sanitização de Código**: Remoção de credenciais, comentários sensíveis e informações internas
|
||
|
|
|
||
|
|
5. **Documentação**: Documentação completa do código e sua utilização
|
||
|
|
|
||
|
|
6. **Licenciamento**: Inclusão de informações de licenciamento adequadas
|
||
|
|
|
||
|
|
7. **Verificação Final**: Verificação final de segurança e qualidade
|