You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
177 lines
4.9 KiB
177 lines
4.9 KiB
# Complexity Assessment — Evaluation Frameworks
|
|
|
|
> **Agent role**: Reference this file for
|
|
complexity evaluation frameworks when assessing project complexity.
|
|
|
|
## 📊 Complexity Assessment Framework
|
|
|
|
### **Technical Complexity Factors**
|
|
|
|
#### **Code Changes**
|
|
|
|
- **Simple**: Text, styling, configuration updates
|
|
|
|
- **Medium**: New components, refactoring existing code
|
|
|
|
- **Complex**: Architecture changes, new patterns, integrations
|
|
|
|
- **Unknown**: New technologies, APIs, or approaches
|
|
|
|
#### **Platform Impact**
|
|
|
|
- **Single platform**: Web-only or mobile-only changes
|
|
|
|
- **Two platforms**: Web + mobile or web + desktop
|
|
|
|
- **Three platforms**: Web + mobile + desktop
|
|
|
|
- **Cross-platform consistency**: Ensuring behavior matches across all platforms
|
|
|
|
#### **Testing Requirements**
|
|
|
|
- **Basic**: Unit tests for new functionality
|
|
|
|
- **Comprehensive**: Integration tests, cross-platform testing
|
|
|
|
- **User acceptance**: User testing, feedback integration
|
|
|
|
- **Performance**: Load testing, optimization validation
|
|
|
|
### **Dependency Complexity**
|
|
|
|
#### **Internal Dependencies**
|
|
|
|
- **Low**: Self-contained changes, no other components affected
|
|
|
|
- **Medium**: Changes affect related components or services
|
|
|
|
- **High**: Changes affect core architecture or multiple systems
|
|
|
|
- **Critical**: Changes affect data models or core business logic
|
|
|
|
#### **External Dependencies**
|
|
|
|
- **None**: No external services or APIs involved
|
|
|
|
- **Low**: Simple API calls or service integrations
|
|
|
|
- **Medium**: Complex integrations with external systems
|
|
|
|
- **High**: Third-party platform dependencies or complex APIs
|
|
|
|
#### **Infrastructure Dependencies**
|
|
|
|
- **None**: No infrastructure changes required
|
|
|
|
- **Low**: Configuration updates or environment changes
|
|
|
|
- **Medium**: New services or infrastructure components
|
|
|
|
- **High**: Platform migrations or major infrastructure changes
|
|
|
|
## 🔍 Complexity Evaluation Process
|
|
|
|
### **Step 1: Technical Assessment**
|
|
|
|
1. **Identify scope of changes** - what files/components are affected
|
|
|
|
2. **Assess platform impact** - which platforms need updates
|
|
|
|
3. **Evaluate testing needs** - what testing is required
|
|
|
|
4. **Consider performance impact** - will this affect performance
|
|
|
|
### **Step 2: Dependency Mapping**
|
|
|
|
1. **Map internal dependencies** - what other components are affected
|
|
|
|
2. **Identify external dependencies** - what external services are involved
|
|
|
|
3. **Assess infrastructure needs** - what infrastructure changes are required
|
|
|
|
4. **Evaluate risk factors** - what could go wrong
|
|
|
|
### **Step 3: Complexity Classification**
|
|
|
|
1. **Assign complexity levels** to each factor
|
|
|
|
2. **Identify highest complexity** areas that need attention
|
|
|
|
3. **Plan mitigation strategies** for high-complexity areas
|
|
|
|
4. **Set realistic expectations** based on complexity assessment
|
|
|
|
## 📋 Complexity Assessment Checklist
|
|
|
|
- [ ] Technical scope identified and mapped
|
|
|
|
- [ ] Platform impact assessed across all targets
|
|
|
|
- [ ] Testing requirements defined and planned
|
|
|
|
- [ ] Internal dependencies mapped and evaluated
|
|
|
|
- [ ] External dependencies identified and assessed
|
|
|
|
- [ ] Infrastructure requirements evaluated
|
|
|
|
- [ ] Risk factors identified and mitigation planned
|
|
|
|
- [ ] Complexity levels assigned to all factors
|
|
|
|
- [ ] Realistic expectations set based on assessment
|
|
|
|
## 🎯 Complexity Reduction Strategies
|
|
|
|
### **Scope Reduction**
|
|
|
|
- Break large features into smaller, manageable pieces
|
|
|
|
- Focus on core functionality first, add polish later
|
|
|
|
- Consider phased rollout to reduce initial complexity
|
|
|
|
### **Dependency Management**
|
|
|
|
- Minimize external dependencies when possible
|
|
|
|
- Use abstraction layers to isolate complex integrations
|
|
|
|
- Plan for dependency failures and fallbacks
|
|
|
|
### **Testing Strategy**
|
|
|
|
- Start with basic testing and expand coverage
|
|
|
|
- Use automated testing to reduce manual testing complexity
|
|
|
|
- Plan for iterative testing and feedback cycles
|
|
|
|
## **See also**
|
|
|
|
- `.cursor/rules/development/realistic_time_estimation.mdc` for the core principles
|
|
|
|
- `.cursor/rules/development/planning_examples.mdc` for planning examples
|
|
|
|
## Model Implementation Checklist
|
|
|
|
### Before Complexity Assessment
|
|
|
|
- [ ] **Problem Scope**: Clearly define the problem to be assessed
|
|
- [ ] **Stakeholder Identification**: Identify all parties affected by complexity
|
|
- [ ] **Context Analysis**: Understand technical and business context
|
|
- [ ] **Assessment Criteria**: Define what factors determine complexity
|
|
|
|
### During Complexity Assessment
|
|
|
|
- [ ] **Technical Mapping**: Map technical scope and platform impact
|
|
- [ ] **Dependency Analysis**: Identify internal and external dependencies
|
|
- [ ] **Risk Evaluation**: Assess infrastructure needs and risk factors
|
|
- [ ] **Complexity Classification**: Assign complexity levels to all factors
|
|
|
|
### After Complexity Assessment
|
|
|
|
- [ ] **Mitigation Planning**: Plan strategies for high-complexity areas
|
|
- [ ] **Expectation Setting**: Set realistic expectations based on assessment
|
|
- [ ] **Documentation**: Document assessment process and findings
|
|
- [ ] **Stakeholder Communication**: Share results and recommendations
|
|
|