Criou página com ' ===='''Responsável:''' Gabriel Villela ==== ===='''Última Atualização:''' 02/12/2025 ==== ===='''Status:''' Em desenvolvimento ==== ===* [[|Guia para Implementação - BIRD]]=== ==1. Visão Geral== ==2. Fundamentos Teóricos== ==3. Principais Responsabilidades== ==4. Integração com o Time== ==Referências e Leitura Recomendada== <br>' |
Sem resumo de edição |
||
| (21 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
| Linha 1: | Linha 1: | ||
===='''Responsável:''' Gabriel de Freitas Villela ==== | |||
====''' | ===='''Última Atualização:''' 02/12/2025 ==== | ||
====''' | ===='''Status:''' Em progresso==== | ||
=== | ===* [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf| Melhores práticas de Implementação - BIRD]]=== | ||
===* [[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== | ||
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== | ==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. | |||
<br> | |||
*'''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. | |||
<br> | |||
*'''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== | ==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 [[Media:Roteiro_Melhores_Praticas_Implementacao.pdf|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== | ==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. | |||
<br> | |||
*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. | |||
<br> | |||
*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. | |||
<br> | |||
*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== | ==Referências e Leitura Recomendada== | ||
*'''SWEBOK v4:''' Capítulo 3 (Software Construction). | |||
<br> | |||
*'''Clean Code:''' A Handbook of Agile Software Craftsmanship - Robert C. Martin. Base para os princípios SOLID e Nomenclatura) | |||
<br> | |||
*'''The Pragmatic Programmer''' – Andrew Hunt & David Thomas. (Base para os princípios DRY e ETC) | |||
<br> | |||
*'''Refactoring''' – Martin Fowler. (Técnicas para melhorar código legado sem alterar comportamento) | |||
<br> | |||
*'''PEP 8 – Style Guide for Python Code.''' Disponível em: https://peps.python.org/pep-0008/ | |||
<br> | <br> | ||
*'''Google Java Style Guide.''' Disponível em: https://google.github.io/styleguide/javaguide.html | |||
<br> | |||
*'''C# Coding Conventions (Microsoft).''' Disponível em: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions | |||
<br> | |||
*'''OWASP Top 10''' – Padrão global de conscientização sobre segurança de aplicações web. | |||
<br> | |||
*'''Documentação Interna:''' | |||
<br> | |||
#[[Engenharia de Requisitos]] - Leonardo | |||
#[[Projeto de Software]] - Luis Henrique | |||
#[[Modelagem de Software]] - Davi | |||
#[[Padrões de Trabalho]] - Carlos Ernani (Junin) | |||
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)
- PEP 8 – Style Guide for Python Code. Disponível em: https://peps.python.org/pep-0008/
- Google Java Style Guide. Disponível em: https://google.github.io/styleguide/javaguide.html
- C# Coding Conventions (Microsoft). Disponível em: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
- OWASP Top 10 – Padrão global de conscientização sobre segurança de aplicações web.
- Documentação Interna:
- Engenharia de Requisitos - Leonardo
- Projeto de Software - Luis Henrique
- Modelagem de Software - Davi
- Padrões de Trabalho - Carlos Ernani (Junin)