| name | metodologia-asis-analysis |
| description | Universal current-state assessment producing 10-section analysis for ANY MetodologIA service type. Use when the user asks to "analyze the codebase", "assess current architecture", "run AS-IS analysis", "technical audit", "evaluate tech debt", "code quality assessment", "assess current state", "service assessment", "QA maturity", "PMO assessment", "RPA readiness", "data maturity", "cloud readiness", "design maturity", "talent gap analysis", or mentions "Phase 1", "current state", "legacy system review", "technical health check".
|
| argument-hint | <codebase-path-or-project-name> |
| author | Javier Montano · Comunidad MetodologIA |
| allowed-tools | ["Read","Write","Edit","Glob","Grep","Bash"] |
AS-IS Analysis — Universal Current-State Assessment
Generates a 10-section current-state assessment for ANY MetodologIA service type (SDA, QA, Management, RPA, Data-AI, Cloud, SAS, UX-Design). For software codebases (SDA), produces: executive dashboard, technology inventory, code structure, C4 architecture, code quality metrics, technical debt inventory, NFR heatmap, security posture, operational model, and risk register with prioritized recommendations. For other service types, sections S1-S8 adapt to domain-specific dimensions while S0 (Executive Dashboard), S9 (Risk Register), and S10 (Recommendations) remain universal.
Principio Rector
No se puede trazar un camino hacia el futuro sin comprender con honestidad brutal dónde se está parado hoy.
- Diagnóstico basado en evidencia, no en opinión. Cada hallazgo debe estar respaldado por métricas extraídas del código, configuración o historial operativo. La intuición guía la exploración; la evidencia sustenta la conclusión.
- El presente contiene las semillas del futuro. Las decisiones arquitectónicas heredadas no son errores — son contexto. Comprender por qué se tomaron revela restricciones que cualquier transformación debe respetar o explícitamente romper.
- La deuda técnica es deuda de conocimiento. Cada atajo no documentado, cada patrón inconsistente, cada test ausente representa conocimiento que el equipo decidió no capturar. El análisis AS-IS restaura ese conocimiento antes de que se pierda.
Inputs
$1 — Path to codebase root (default: current working directory)$2 — Analysis depth: full (default), executive (sections 0,5,9,10 only)
Parse from $ARGUMENTS.
Parameters:
{MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
- piloto-auto: Auto para extracción de métricas y análisis de código, HITL para hallazgos de seguridad y decisiones de escalamiento.
- desatendido: Cero interrupciones. Análisis completo automatizado. Supuestos documentados.
- supervisado: Autónomo con reportes al completar cada sección del framework.
- paso-a-paso: Confirma antes de cada sección del análisis.
{FORMATO}: markdown (default) | html | dual{VARIANTE}: ejecutiva (~40% — sections S0, S5, S9, S10 only) | técnica (full, default){TIPO_SERVICIO}: SDA (default) | QA | Management | RPA | Data-AI | Cloud | SAS | UX-Design
- When omitted or when a codebase path is provided, defaults to SDA (backward compatible)
- Determines which variant of sections S1-S8 to generate
Service Type Detection
Before starting analysis, detect the service type from context:
- If
{TIPO_SERVICIO} explicitly provided → use it
- If codebase path provided → default to SDA
- If conversation mentions QA/testing/ISTQB → QA
- If conversation mentions PMO/methodology/delivery → Management
- If conversation mentions automation/bots/RPA/UiPath → RPA
- If conversation mentions data/AI/ML/analytics/dashboards → Data-AI
- If conversation mentions cloud/migration/DevOps/SRE → Cloud
- If conversation mentions staffing/talent/augmentation → SAS
- If conversation mentions design/UX/UI/usability → UX-Design
Confirm: "Tipo de servicio detectado: {X}. ¿Confirma o desea ajustar?"
Dynamic Context Injection
SDA Context Injection (when {TIPO_SERVICIO}=SDA)
Auto-detect codebase characteristics before starting analysis:
find . -name "*.ts" -o -name "*.py" -o -name "*.java" -o -name "*.go" -o -name "*.rs" | head -30
ls -la package.json pom.xml build.gradle Cargo.toml go.mod setup.py pyproject.toml Makefile 2>/dev/null
find . -name "Dockerfile" -o -name "*.yaml" -path "*/k8s/*" -o -name "docker-compose*" | head -10
find . -name "*.yaml" -path "*/swagger/*" -o -name "openapi*" -o -name "*.proto" | head -10
Use detected languages, build tools, and infrastructure to scope each section.
Input Requirements
Mandatory (varies by service type):
| Service Type | Mandatory Inputs |
|---|
| SDA | Complete codebase with commit history, build configuration, deployment configuration |
| QA | Test suite documentation, QA processes, tool landscape inventory, defect metrics |
| Management | PMO artifacts, methodology documentation, team assessments, delivery metrics |
| RPA | Process documentation (BPMN), bot inventory, automation logs, process metrics |
| Data-AI | Data catalog, pipeline documentation, model registry, data quality reports |
| Cloud | Infrastructure inventory, cloud accounts, monitoring dashboards, cost reports |
| SAS | Team composition, skills matrix, project history, utilization reports |
| UX-Design | Design system, research repository, usability reports, accessibility audits |
Recommended (all types):
- Previous assessments or modernization reports
- Stakeholder interviews or survey results
- Operational metrics (last 12-24 months)
- Industry benchmarks for comparison
Assumptions & Limits
Assumptions:
- Codebase is buildable (dependencies resolvable)
- System has operational history (incident/performance data available)
- Documentation in English or Spanish
- No production secrets embedded in source
Cannot do:
- Runtime profiling under production load (requires live monitoring)
- Live load testing or performance tuning
- Team interviews or org structure analysis (requires human interaction)
- Legal compliance review (requires legal expertise)
Workarounds When Inputs Missing
| Missing Input | Impact | Workaround |
|---|
| No deployment config | Cannot assess infrastructure | Infer from Dockerfiles, K8s manifests, CI/CD scripts; flag as assumption |
| No API specs | Cannot fully document integrations | Reverse-engineer from code (HTTP clients, REST annotations, gRPC stubs) |
| No security audit | Cannot benchmark against standards | Lightweight SAST scan (SQL injection, hardcoded secrets, weak crypto patterns) |
| No performance data | Cannot assess NFR baseline | Code-level heuristics (complexity suggests bottlenecks) + recommend profiling |
| <1 year history | Cannot assess trends | Current snapshot only; flag as point-in-time analysis |
| Monorepo unclear | Cannot map boundaries | Infer from package naming, deployment units, team ownership patterns |
Edge Cases
- Monorepo: Decompose per deployment unit. Analyze coupling between units.
- No CI/CD: Infer from Dockerfiles, cloud configs, README scripts. Flag inference risk.
- No test suite: Flag coverage as CRITICAL (0%). Extrapolate quality risk via complexity. Recommend test buildout.
- Multiple languages: Metrics per language separately. +1 risk per language for integration burden.
- Microservices vs Monolith: Check for multiple deployable units. Analyze per-service if microservices.
- Legacy no docs: Reverse-engineer from code structure + configuration. Flag confidence level.
- System >500K LOC: Phased analysis (Tier 1: core domains, Tier 2: supporting). Deliver executive summary + prioritized deep-dives.
- Vendor lock-in detected: Flag proprietary dependencies with migration cost estimates and open-source alternatives.
- Outdated framework (EOL): Escalate to CRITICAL risk. Document security exposure and upgrade path complexity.
Trade-off Matrix
| Decision | Enables | Constrains | When to Use |
|---|
| Full 10-section analysis | Maximum depth, complete audit trail | 5-7 days, high token cost | High-stakes modernization, regulated environments |
| Executive variant (S0+S5+S9+S10) | Fast insights, decision-ready | Misses detailed architecture/quality data | Time-constrained, executive audience |
| Security-focused (S7 deep) | Compliance-ready, vulnerability inventory | Narrower scope | Pre-audit, compliance-driven engagements |
| Quality-focused (S4+S5 deep) | Actionable tech debt remediation plan | Less architecture context | Tech debt reduction initiatives |
10-Section Framework
S0: Executive Dashboard
System snapshot: LOC, modules, integrations, team size, years in production, tech stack summary, development status, maintenance cost estimate. Health score (1-10) with color-coded indicators.
S1: Technology Inventory
Per layer: Backend, Frontend, Data, Infrastructure, Development. Dependency tree table with EOL status. Flag deprecated dependencies. Version currency score per component.
S2: Code Organization
Module decomposition, coupling analysis (afferent/efferent), layering assessment, cyclomatic complexity distribution, anti-patterns (god classes, circular dependencies, duplication). Package cohesion metrics.
S3: Architecture (C4 Model)
Level 1 (Context): system as black box with external actors. Level 2 (Containers): major services, databases, data flows. Pattern catalog with quality assessment. Architecture fitness functions where applicable.
S4: Code Quality Metrics
Complexity distribution (p50, p95), duplication %, test coverage by layer, dependency depth, code smells by type. Dashboard with severity-coded cards. Trend analysis if git history available.
S5: Technical Debt Inventory
Per item: description, category (7 types: design, code, test, build, documentation, infrastructure, dependency), severity, technical impact, business impact, remediation pathway, prioritization score (impact x cost-to-fix).
Conditional logic:
- IF debt >30% of codebase OR average CC >15: flag CRITICAL, recommend refactoring before features
- IF test coverage <20%: CRITICAL quality risk
- IF dependency depth >5: recommend modularization
- IF >10 circular dependencies: architectural refactor required
S6: NFR Heatmap
7x5 matrix: performance, security, maintainability, scalability, reliability, usability, interoperability. Scored 1-10 with evidence. Gap analysis against targets. Priority ranking by business impact.
S7: Security Assessment
Authentication, authorization, encryption, data protection, known CVEs (SBOM analysis), compliance gaps. Severity-rated findings with remediation recommendations. OWASP Top 10 mapping where applicable.
S8: Operational Model
Deployment model, monitoring/observability, incident response (MTTR), release management, capacity management. Operational readiness scorecard. DevOps maturity assessment (DORA metrics if available).
S9: Risk Register
Top-10 risks: probability x impact matrix. Per risk: category, score, current mitigations, recommended improvements, owner, status. Risk velocity indicator (growing/stable/shrinking).
S10: Recommendations
Top 5-10 findings with root cause + business impact. Quick wins (under 5 eng-days). Strategic roadmap (immediate/short/medium/long-term). Refactor vs rewrite vs replace decision tree per major component.
Service-Type Variant Sections (S1-S8)
When {TIPO_SERVICIO} ≠ SDA, sections S0, S9, and S10 remain universal. Sections S1-S8 adapt to the service type:
QA Variant ({TIPO_SERVICIO}=QA)
- S1: QA Tool Landscape — Testing tools inventory (automation frameworks, CI/CD integration, test management), license status, adoption maturity
- S2: Test Coverage Assessment — Coverage by type (unit, integration, E2E, performance, security), by layer, by risk level. Gap analysis
- S3: Testing Maturity Model (TMMi) — Assessment against TMMi levels 1-5. Current level with evidence. Improvement roadmap
- S4: Process Quality — Defect detection rate, escape rate, test execution efficiency, automation ratio. Trend analysis
- S5: Quality Debt Inventory — Untested critical paths, flaky tests, outdated test data, manual-only processes. Severity scoring
- S6: QA NFR Heatmap — Performance testing capability, security testing, accessibility testing, reliability testing. Scored 1-10
- S7: Compliance & Standards — ISTQB alignment, industry regulatory testing requirements, audit readiness
- S8: QA Operations Model — Team structure, shift-left maturity, CI/CD quality gates, release qualification process
Management Variant ({TIPO_SERVICIO}=Management)
- S1: PMO Maturity Assessment — PMO maturity level (ad-hoc, defined, managed, optimized). Evidence-based assessment
- S2: Methodology Fitness — Current methodology (Agile, SAFe, Waterfall, Hybrid) fit to organizational context. Disciplined Agile assessment
- S3: Governance Model — Decision rights, escalation paths, ceremony effectiveness, reporting cadence. Governance health score
- S4: Team Capability — Certifications inventory (PMP, CSM, SAFe, etc.), experience distribution, skill gaps. Capability maturity
- S5: Process Debt — Manual processes that should be automated, ceremonias inefectivas, documentation gaps, governance overhead
- S6: Management NFR Heatmap — Predictability, transparency, stakeholder satisfaction, velocity stability, quality. Scored 1-10
- S7: Change Readiness — Organizational change capacity, resistance patterns, adoption barriers, training needs
- S8: Delivery Operations — Delivery cadence, deployment frequency, lead time, WIP management. DORA-lite for management
RPA Variant ({TIPO_SERVICIO}=RPA)
- S1: Process Landscape — BPMN process inventory, volume, frequency, complexity classification, manual effort per process
- S2: Automation Readiness — Rule-based score per process (structured data, stable rules, high volume, repetitive). Automation candidate ranking
- S3: Bot Inventory & Health — Existing bots, platform (UiPath/AA/Power Automate/Blue Prism), success rate, exception rate, maintenance status
- S4: Process Quality — Error rates, rework rates, processing time, compliance violations per process
- S5: Automation Debt — Bots with high exception rates, unmaintained automations, undocumented processes, technical debt in bot code
- S6: RPA NFR Heatmap — Scalability (concurrent bots), reliability (uptime), security (credential management), auditability. Scored 1-10
- S7: Security & Compliance — Bot credential management, audit trails, data handling, regulatory compliance (SOX, GDPR)
- S8: Bot Operations — Orchestration model (attended/unattended), monitoring, incident response, change management for bots
Data-AI Variant ({TIPO_SERVICIO}=Data-AI)
- S1: Data Maturity (DCAM/DMM) — Data management maturity assessment. Current level with evidence across 6 dimensions
- S2: Data Architecture — Data platform inventory, lakehouse/warehouse, ETL/ELT pipelines, streaming. Architecture patterns
- S3: AI Readiness (AI SCALE) — Assessment using MetodologIA AI SCALE methodology. Current stage (Selection/Co-creation/Adoption/Launch/Expansion)
- S4: Data Quality Baseline — Completeness, accuracy, consistency, timeliness, validity. Quality scores per critical dataset
- S5: Data/AI Debt — Undocumented pipelines, untested models, stale datasets, missing lineage, shadow IT data sources
- S6: Data NFR Heatmap — Latency, freshness, availability, security, governance, interoperability. Scored 1-10
- S7: Data Privacy & Governance — GDPR/CCPA compliance, data classification, access controls, retention policies, consent management
- S8: DataOps/MLOps Model — Pipeline orchestration, model deployment, A/B testing, monitoring, feature store maturity
Cloud Variant ({TIPO_SERVICIO}=Cloud)
- S1: Cloud Readiness — Current infrastructure inventory, cloud adoption stage, migration assessment (7R per workload)
- S2: Migration Assessment — Workload classification, dependency mapping, migration complexity scoring, risk analysis
- S3: DevOps Maturity (DORA) — Deployment frequency, lead time, change failure rate, MTTR. DORA level assessment
- S4: Infrastructure Quality — IaC coverage, configuration drift, resource tagging, cost optimization. Quality score
- S5: Cloud Debt — Over-provisioned resources, untagged assets, legacy configurations, manual processes, security gaps
- S6: Cloud NFR Heatmap — Scalability, availability, disaster recovery, security, compliance, cost efficiency. Scored 1-10
- S7: Cloud Security — Shared responsibility model adherence, IAM hygiene, encryption, network segmentation, compliance
- S8: FinOps & Operations — Cost visibility, optimization opportunities, reserved/spot usage, showback/chargeback, operational runbooks
SAS Variant ({TIPO_SERVICIO}=SAS)
- S1: Talent Gap Analysis — Current team capabilities vs required capabilities. Gap identification per role/skill
- S2: Skills Inventory — Technical and soft skills matrix. Certification status. Proficiency levels
- S3: Team Topology — Team structure, communication patterns, collaboration effectiveness. Conway's Law alignment
- S4: Capability Maturity — Team velocity, quality output, self-organization level, continuous improvement practices
- S5: Knowledge Debt — Single points of failure (key-person dependency), undocumented tribal knowledge, skill concentration risks
- S6: SAS NFR Heatmap — Retention, productivity, satisfaction, growth, adaptability, cultural fit. Scored 1-10
- S7: Compliance — Labor regulations, contractor vs employee classification, IP protection, NDA coverage
- S8: Staffing Operations — Recruiting pipeline, onboarding effectiveness, utilization rates, bench management
UX-Design Variant ({TIPO_SERVICIO}=UX-Design)
- S1: Design Maturity — Design maturity level (ad-hoc, repeatable, managed, optimized, innovative). Evidence-based
- S2: Design System Inventory — Components, tokens, documentation coverage, adoption rate, governance model
- S3: UX Research Capability — Research methods used, frequency, integration with product decisions, research repository
- S4: Usability Baseline — Heuristic evaluation results, usability test scores, task success rates, error rates
- S5: Design Debt — Inconsistent patterns, accessibility violations, undocumented design decisions, outdated components
- S6: UX NFR Heatmap — Accessibility (WCAG), performance perception, consistency, learnability, satisfaction. Scored 1-10
- S7: Accessibility Compliance — WCAG 2.1/2.2 level assessment (A/AA/AAA), assistive technology compatibility, legal requirements
- S8: Design Operations — Design review process, handoff quality, tools ecosystem, design-dev collaboration maturity
Cross-Section Traceability
Every recommendation in S10 must reference evidence from S0-S9:
- S2 Code Structure to S5 Debt (coupling = architectural debt)
- S4 Quality to S5 Debt (low coverage = quality debt)
- S5 Debt to S9 Risks (high debt with uncertain remediation = risk)
- S6 NFR Gaps to S5 Debt (NFR miss = technical work required)
- S7 Security to S9 Risks (CVEs = security risk)
- S8 Ops Gaps to S9 Risks (manual deployment = operational risk)
- S9 Risks to S10 Roadmap (top risks = immediate roadmap items)
Escalation to Human Architect
- Codebase doesn't match business description
- Multiple competing architectural patterns (MVC + microservices mixed)
- Undocumented integration logic requiring team interviews
- Code contradicts comments (conflicting evidence)
- Regulatory compliance ambiguity (PCI, HIPAA, GDPR)
- Rare/uncommon tech stack beyond standard tooling
Execution Workflow
- Input Validation (30 min): Verify completeness, collect manifests, flag gaps
- Automated Extraction (2-4 hours): Parse metrics (LOC, complexity, duplication), generate dependency tree, scan vulnerabilities
- Architectural Analysis (4-6 hours): Map C4 L1/L2, identify patterns, assess coupling
- Synthesis (4-6 hours): Consolidate into 10 sections, prioritize by business impact, cross-reference validation
Typical engagement: 5-7 days for systems under 500K LOC.
Output Artifact
Primary: 03_Analisis_AS-IS_{TIPO_SERVICIO}_{project}.md (o .html si {FORMATO}=html|dual) — Full 10-section current-state assessment with domain-specific analysis, debt inventory, risk register, and prioritized recommendations. When {TIPO_SERVICIO}=SDA, for backward compatibility also accept 03_Analisis_AS-IS_{project}.md.
Secondary: 02_Brief_Tecnico_{project}.md — Executive summary (S0 + key findings).
Diagramas incluidos:
- C4 Context diagram: system boundaries and external actors
- C4 Container diagram: internal components and relationships
- Mindmap: technology stack overview
- Quadrant chart: NFR heatmap positioning
Validation Gate
Output Format Protocol
| Format | Default | Description |
|---|
markdown | ✅ | Rich Markdown + Mermaid diagrams. Token-efficient. |
html | On demand | Branded HTML (Design System). Visual impact. |
dual | On demand | Both formats. |
Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.
Diagrams (Mermaid)
- C4 Context diagram: system boundaries and external actors
- C4 Container diagram: internal components and their relationships
- Mindmap: technology stack overview
Casos Borde
| Caso | Estrategia de Manejo |
|---|
| Monorepo con multiples deployment units | Descomponer por deployment unit. Analizar coupling entre units. Metricas por servicio separado. |
| No CI/CD configurado | Inferir de Dockerfiles, cloud configs, README scripts. Flag inference risk explicitamente. |
| No test suite existente | Flag coverage como CRITICAL (0%). Extrapolar quality risk via complexity. Recomendar test buildout prioritario. |
| Multiples lenguajes en codebase | Metricas por lenguaje separadas. +1 risk por lenguaje adicional por carga de integracion. |
| Sistema >500K LOC | Analisis faseado: Tier 1 core domains, Tier 2 supporting. Executive summary + deep-dives priorizados. |
| Framework EOL detectado | Escalar a CRITICAL risk. Documentar security exposure y upgrade path complexity. |
| Vendor lock-in con dependencias propietarias | Flag dependencias propietarias con migration cost estimates y alternativas open-source. |
Decisiones y Trade-offs
| Decision | Alternativa Descartada | Justificacion |
|---|
| 10 secciones como framework universal | Framework de 5 secciones, assessment libre | 10 secciones cubren el espectro completo (exec, tech, arch, quality, debt, NFR, security, ops, risk, recommendations). Sections S0, S9, S10 son universales cross-service-type. |
| Service-type variants para S1-S8 | Framework unico para todos los tipos de servicio | SDA, QA, Management, RPA, Data-AI, Cloud, SAS, UX-Design tienen dimensiones de evaluacion fundamentalmente diferentes. Adaptar S1-S8 maximiza relevancia. |
| Evidence-based diagnostico con tags | Opinion-based assessment | Tags [CODIGO], [CONFIG], [DOC], [INFERENCIA], [SUPUESTO] garantizan trazabilidad. Cada hallazgo tiene backing verificable. |
| Cross-section traceability (S10 to S0-S9) | Recomendaciones desconectadas de hallazgos | Toda recomendacion S10 referencia evidencia de secciones previas. Elimina recomendaciones sin fundamento. |
Knowledge Graph
graph TD
subgraph Core["Conceptos Core"]
EXEC["S0: Executive Dashboard"]
TECH["S1-S8: Domain Sections"]
DEBT["S5: Technical Debt"]
RISK["S9: Risk Register"]
RECS["S10: Recommendations"]
end
subgraph Inputs["Entradas"]
CODE["Codebase / Artifacts"]
CONFIG["Build & Deploy Config"]
HISTORY["Operational History"]
TIPO["Service Type"]
end
subgraph Outputs["Salidas"]
ASIS["AS-IS Analysis Report"]
BRIEF["Technical Brief"]
C4["C4 Diagrams"]
NFR["NFR Heatmap"]
end
subgraph Related["Skills Relacionados"]
TOBE["architecture-tobe"]
SCENARIOS["scenario-evaluation"]
COST["cost-estimation"]
SECURITY["security-assessment"]
end
CODE --> TECH
CONFIG --> TECH
HISTORY --> RISK
TIPO --> TECH
EXEC --> ASIS
TECH --> DEBT
DEBT --> RISK
RISK --> RECS
RECS --> ASIS
ASIS --> BRIEF
TECH --> C4
TECH --> NFR
ASIS -.-> TOBE
RISK -.-> SCENARIOS
DEBT -.-> COST
TECH -.-> SECURITY
Output Templates
Formato Markdown (default):
# Analisis AS-IS: {project} ({TIPO_SERVICIO})
## S0: Executive Dashboard
| Indicador | Valor |
| LOC | ... |
| Health Score | .../10 |
## S1-S8: [Domain-Specific Sections]
## S5: Technical Debt Inventory
| Item | Category | Severity | Impact | Remediation | Priority Score |
...
## S9: Risk Register
| Risk | Probability | Impact | Score | Mitigations | Owner |
...
## S10: Recommendations
### Quick Wins (<5 eng-days)
### Strategic Roadmap
Formato HTML (bajo demanda):
HTML branded con Design System MetodologIA:
- Executive Dashboard con color-coded health indicators
- C4 Diagrams interactivos (Mermaid rendered)
- NFR Heatmap como quadrant chart visual
- Collapsible sections para S1-S8
- Risk Register con severity color coding
- Responsive layout para presentacion en pantalla
- Filename:
03_Analisis_AS-IS_{TIPO_SERVICIO}_{project}_{WIP}.html
- Estructura: HTML self-contained branded (Design System MetodologIA v5). Light-First Technical page con health score dashboard, secciones S0-S10 colapsables, y risk register con color coding por severidad. WCAG AA, responsive, print-ready.
Formato DOCX (bajo demanda):
- Filename:
{fase}_{entregable}_{cliente}_{WIP}.docx
- Via python-docx con Design System MetodologIA v5. Cover page, TOC auto, headers/footers branded, tablas zebra. Para circulacion formal y auditoria.
Formato XLSX (bajo demanda):
- Filename:
{fase}_{entregable}_{cliente}_{WIP}.xlsx
- Via openpyxl con Design System MetodologIA v5. Headers branded (fondo navy, texto blanco, Poppins), formato condicional con colores semaforo, auto-filtros, valores sin formulas. Para inventario de deuda tecnica, registro de riesgos y heatmap NFR por servicio.
Formato PPTX (bajo demanda):
- Filename:
{fase}_{entregable}_{cliente}_{WIP}.pptx
- Via python-pptx con MetodologIA Design System v5. Slide master con gradiente navy, titulos Poppins, cuerpo Montserrat, acentos gold. Max 20 slides (ejecutiva) / 30 slides (tecnica). Speaker notes con referencias de evidencia. Para comites directivos y presentaciones C-level.
Evaluacion
| Dimension | Peso | Criterio |
|---|
| Trigger Accuracy | 10% | Activacion correcta ante keywords de AS-IS, current state, tech debt, code quality, architecture assessment, y variantes por service type. |
| Completeness | 25% | 10 secciones completas con service-type adaptation. Cross-section traceability S10 a S0-S9 verificable. |
| Clarity | 20% | Health score 1-10 interpretable. Debt items con severity scoring cuantitativo. NFR heatmap con evidencia. |
| Robustness | 20% | 8 service types soportados. Edge cases (monorepo, no CI/CD, >500K LOC, multi-language, EOL frameworks) manejados. |
| Efficiency | 10% | Variante ejecutiva reduce a S0+S5+S9+S10 (~40%). Context injection automatica detecta lenguaje y build system. |
| Value Density | 15% | S10 produce quick wins (<5 dias) y strategic roadmap. Debt scored por impact x cost-to-fix. Risk register con velocity indicator. |
Umbral minimo: 7/10. Debajo de este umbral, revisar evidence backing de findings y cross-section traceability.
Autor: Javier Montano · Comunidad MetodologIA | Ultima actualizacion: 15 de marzo de 2026
