Santos.paula (discussão | contribs)
Sem resumo de edição
Santos.paula (discussão | contribs)
Sem resumo de edição
 
Linha 5: Linha 5:
===='''Status:''' Em progresso====
===='''Status:''' Em progresso====


===* [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf|Guia para Implementação - BIRD]]===
===* [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf| Melhores práticas de Implementação - BIRD]]===


===* [[Media:Resumo_Guia_de_Implementacao.pdf|Guia para Implementação - BIRD]]===
===* [[Media:Resumo_Guia_de_Implementacao.pdf| Resumo Guia para Implementação - BIRD]]===


==1. Visão Geral==
==1. Visão Geral==

Edição atual tal como às 17h26min de 22 de janeiro de 2026

Responsável: Gabriel de Freitas Villela

Última Atualização: 02/12/2025

Status: Em progresso

1. Visão Geral

A área de Implementação (Software Construction) é o motor da Fábrica de Software. É responsável por materializar as definições abstratas (requisitos e arquitetura) em um produto funcional, tangível e executável.

Diferente de uma abordagem artesanal, na nossa Fábrica o foco não é apenas "escrever código", mas sim estabelecer uma Engenharia de Construção. O objetivo é garantir que o software seja construído sobre alicerces sólidos de padronização, permitindo que qualquer desenvolvedor da equipe possa atuar em qualquer módulo com a mesma eficiência e qualidade (intercambiabilidade). O responsável atua como um Líder Técnico (Tech Lead), provendo ferramentas, roteiros e orientação para o time.

2. Fundamentos Teóricos

A prática de implementação nesta organização é fundamentada nas seguintes Áreas de Conhecimento (KAs) do SWEBOK v4 e práticas de indústria:

  • Software Construction (Cap. 3): Foco na codificação, verificação unitária, integração e depuração.


  • Engenharia de Qualidade (Clean Code): Aplicação rigorosa de princípios como SOLID, DRY (Don't Repeat Yourself) e KISS (Keep It Simple, Stupid) para garantir manutenibilidade.


  • Automação de Processos: Uso de Ferramentas de Análise Estática (Linters, Formatters, Type Checkers) para garantir a consistência do código independentemente da linguagem (Python, C#, Java).

3. Principais Responsabilidades

A atuação vai além da digitação do código, focando na governança técnica da construção:

  • 3.1. Governança e Padronização

Definir e aplicar as "Regras da Casa". Isso inclui a imposição do idioma Inglês para o código, a definição de convenções de nomenclatura (Snake case vs Camel case) e a configuração do ambiente de desenvolvimento (hooks de pre-commit).

Ação: Manutenção do Guia para Implementação - BIRD e configuração dos pipelines de validação automática.

  • 3.2. Construção e Orientação (Tech Lead)

Atuar como facilitador técnico. O responsável pela implementação cria os esqueletos (scaffolding) das aplicações e resolve os problemas técnicos mais complexos, pavimentando o caminho para que os demais membros codifiquem as regras de negócio.

Ação: Codificação do core do sistema, Code Reviews (revisão de pares) e mentoria técnica para o time.

  • 3.3. Preparação para Operação

Garantir que o código não apenas funcione na máquina do desenvolvedor, mas seja operável em produção.

Ação: Implementação de logs estruturados, tratamento adequado de exceções e não-exposição de credenciais (Segurança/Environment Variables).

4. Integração com o Time

Abaixo detalha-se como a área de Implementação interage com as outras áreas da Software House:

4.1. Com Projeto e Modelagem (Luis Henrique e Davi)

  • Entrada: Diagramas UML e Definição Arquitetural.


  • Ação: A implementação deve ser o espelho fiel da modelagem. Responsável pela implementação valida se a arquitetura proposta pelos responsáveis do Projeto e Modelagem de Software é viável tecnicamente dentro do prazo. Se o diagrama é a planta, a implementação é a construção do prédio.

4.2. Com Q&A e Garantia de Entrega (Giovana e João Gabriel)

  • Saída: Código "buildável" e testável.


  • Ação: A Implementação entrega para o Q&A um código que já passou por testes unitários básicos e análise estática. O código deve ser limpo o suficiente para que o Q&A foque em bugs de negócio, não em erros de sintaxe.

4.3. Com Segurança (Lucas)

  • Parceria Contínua: Security by Design.


  • Ação: Implementar as blindagens solicitadas pelo responsável pela Segurança do Software durante a escrita do código (ex: sanitização de inputs), em vez de deixar para corrigir vulnerabilidades apenas no final.

Referências e Leitura Recomendada

  • SWEBOK v4: Capítulo 3 (Software Construction).


  • Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin. Base para os princípios SOLID e Nomenclatura)


  • The Pragmatic Programmer – Andrew Hunt & David Thomas. (Base para os princípios DRY e ETC)


  • Refactoring – Martin Fowler. (Técnicas para melhorar código legado sem alterar comportamento)





  • OWASP Top 10 – Padrão global de conscientização sobre segurança de aplicações web.


  • Documentação Interna:


  1. Engenharia de Requisitos - Leonardo
  2. Projeto de Software - Luis Henrique
  3. Modelagem de Software - Davi
  4. Padrões de Trabalho - Carlos Ernani (Junin)