week2

# Integrate Engineering Design

DAEN 640 Capstone Senior Design

---

# Updates

.box-inv-1.medium.sp-after-veryshort[**BH**: reach out for data access]
.box-inv-1.medium.sp-after-veryshort[**COE**: data/modelling/prototyping]
.box-inv-1.medium.sp-after-veryshort[**ML**: simulation models/data generation]
.box-inv-1.medium.sp-after-veryshort[**Next week**: PM, revised goals, Questions]
.box-inv-1.medium.sp-after-veryshort[Check **Canvas**]

---

# Plan for today

.box-2.medium.sp-after-veryshort[Engineering Design Process]
.box-4.medium.sp-after-veryshort[Integrated Engineering Design Process]
.box-5.medium.sp-after-veryshort[System Architecture, Data Pipeline]
.box-6.medium.sp-after-veryshort[*The Toaster Project*]
.box-7.medium.sp-after-veryshort[Challenges, Solutions]

---

# Learning Goals

.box-inv-1.medium.sp-after-veryshort[Map the V-Model]
.box-inv-1.medium.sp-after-veryshort[Identify Configuration Items]
.box-inv-1.medium.sp-after-veryshort[Understand Traceability]
.box-inv-1.medium.sp-after-veryshort[Connect Tests to Artifacts]
.box-inv-1.medium.sp-after-veryshort[Evaluate Change Impact]

---

.pequeno[
* **Map the V-Model** See how requirements, design, and implementation connect to testing and validation.
* **Identify Configuration Items** Recognize key items (requirements, schemas, code, pipelines, infrastructure) and how they are versioned.
* **Understand Traceability** Follow how requirements link to system components, data pipelines, and tests.
* **Connect Tests to Artifacts** Identify what is tested or validated for each major configuration item.
* **Evaluate Change Impact** Understand how changes ripple across design, implementation, and testing.
]

---

# Engineering Design Process

---

.center[
<figure class="figure">
<img src="images/Engineering_Design_Process3.png" alt="Engineering Design Process" title="Engineering Design Process" width="40%">
</figure>
]
.small[A step-by-step approach engineers use to identify problems, brainstorm solutions, build and test prototypes, and improve designs to create effective, practical solutions.]

---

# Engineering Design Process

.box-inv-2.medium.sp-after-veryshort[Similarities to the scientific method]

* .small[Begin with existing knowledge, gradually become more specific]

.box-inv-2.medium.sp-after-veryshort[Key difference?]

* .small[The scientific process emphasizes explanation, prediction, and discovery.]
* .small[The engineering process focuses on application of systematic thinking to leverage technology in service of human needs!]

---

.center[
<figure class="figure">
<img src="images/TraditionalPencils.jpg" alt="Traditional Pencils" title="Traditional Pencils" width="50%">
</figure>
]
.center[https://www.youtube.com/watch?v=qqs3fxfmWr4]

---

.box-3.large[Life Lessons from a Pencil]

.box-inv-3.sp-after-veryshort[*What matters is what’s inside*]
.box-inv-3.sp-after-veryshort[*Keep yourself sharp*]
.box-inv-3.sp-after-veryshort[*Mistakes are part of the process*]
.box-inv-3.sp-after-veryshort[*Pressure creates output*]
.box-inv-3.sp-after-veryshort[*Collaboration matters*]
.box-inv-3.sp-after-veryshort[*Durability comes from design*]

---

&nbsp;

.box-2.medium.sp-after-short[Imagine a pencil journey as a metaphor]

.box-inv-2.normal.sp-after-veryshort[Raw Materials → Shaping → Testing → Final Pencil]

---

.box-2.large[Engineering Design Process]

1. Define the problem (*Why make a pencil?*)
2. Research & brainstorm (*What materials & designs?*)
3. Develop concepts (*Sketch ideas, pick the best*)
4. Build & prototype (*Make a sample pencil*)
5. Test & evaluate (*Does it write? Break?*)
6. Redesign/refine (*Improve core, casing, process*)

---

.box-2.large[Engineering Design Process]

.pull-left-3.center[
.box-inv-2[Material Selection and Functionality]]

---

.box-2.large[Engineering Design Process]

.pull-left-3[
.box-inv-2[Material Selection and Functionality]
.pequeno[
Multiple cycles of design thinking.
Define the problem, explore materials and methods, prototype, test, and refine.
]]

.pull-middle-3[
.box-inv-2[Mapping Process to Design Stages]
.pequeno[
Engineering design is not linear.
Feedback from testing and production continually informs improvements.
]]

.pull-right-3[
.box-inv-2[Balancing Constraints]
.pequeno[
Deliberate choice that balances functional requirements, "manufacturability", cost, and sustainability.
How engineers translate design goals into real-world material and process decisions.
]]

---

---

# Integrated Engineering Design Process

---

&nbsp;

.box-4.medium.sp-after-veryshort[Integrated Engineering Design Process]

.box-inv-4.small.sp-after-short[(multiple disciplines and feedback loops)]

.box-inv-4.normal.sp-after-veryshort[Materials + Mechanical + Environmental + Economics]

---

.box-inv-4.normal.sp-after-short[Integrating engineering design means: Combining different subjects, ideas, and people with the Engineering Design Process to solve problems together]

.box-inv-4.small.sp-after-short[Instead of working in separate steps, this approach encourages teamwork and big-picture thinking to create complete solutions]

.box-inv-4.normal.sp-after-short[It helps us build skills in STEM, critical thinking, and practical problem-solving, from the first idea all the way through testing and improving designs]

.box-inv-4.small.sp-after-short[You see this approach in schools and in big projects (like designing buildings :)]

---

# System Architecture, Data Pipeline

---

.box-5.large.sp-after-short[System Architecture (V-Model Aligned)]

.box-inv-5.normal.sp-after-short[**Objective:** Provide a modular, testable architecture that supports traceability from requirements through validation]

.box-inv-5.normal.sp-after-short[High-Level Architecture]

.small[
* Presentation Layer: Dashboards, APIs, reporting interfaces
* Application / Processing Layer: Business logic, analytics services, orchestration
* Data Layer: Raw, curated, and analytics-ready data stores
* Infrastructure Layer: Compute, storage, networking, security controls]

---

.box-5.large.sp-after-short[V-Model Mapping]

.box-inv-5.sp-after-veryshort[Decomposition & Design *(Left Side)*]
.center[
System Requirements → System Architecture 
Subsystem Design → Component Design]

.box-inv-5.sp-after-veryshort[Integration & Verification *(Right Side)*]
.center[
Component Testing → Subsystem Integration 
System Verification → User Acceptance Validation]

---

.box-5.large.sp-after-short[Configuration Items]

.box-inv-5.normal.sp-after-short[Architecture design documents]

.box-inv-5.normal.sp-after-short[Interface control documents]

.box-inv-5.normal.sp-after-short[Infrastructure-as-Code templates]

.box-inv-5.normal.sp-after-short[Versioned service definitions and APIs]

---

.box-5.large.sp-after-short[End-to-End Data Pipeline]

.small[
* **Data Ingestion**
  * Batch and streaming sources
  * Schema validation and data quality checks
* **Data Processing**
  * Transformation, aggregation
  * Business rule enforcement
* **Data Storage**
  * Raw (immutable), curated, and analytics layers
* **Data Consumption**
  * BI tools, ML models, downstream services
]

---

.box-5.large.sp-after-short[V-Model Alignment]

**Design** → Pipeline workflows, storage schemas

**Implementation** → ETL/ELT jobs, orchestration logic

**Verification & Validation** 
.small[Data quality tests, Pipeline integration tests, End-user data validation]
]

---

.box-5.large.sp-after-veryshort[Key Configuration Items]

.center[
Data schemas and metadata definitions 
Pipeline code (ETL/ELT, orchestration) 
Data quality rules and test cases 
Versioned datasets and lineage artifacts]

.box-5.large.sp-after-veryshort[Outcome]

.center[
Full traceability from data requirements to validated outputs 
Controlled change management and audit readiness]

---

---

# Project Alignment Questions

.small[
1. *V-Model Mapping:* How does your project diagram map requirements → design → implementation (left side) to testing → integration → validation (right side)?

1. *Configuration Items:* What are the key configuration items (e.g., requirements, schemas, code, pipelines, infrastructure), and how are they identified and versioned?

1. *Traceability:* How does the diagram show traceability between requirements, system components, data pipelines, and verification activities?

1. *Verification & Validation:* For each major CI, what test or validation activity is defined and where is it represented on the right side of the V-Model?

1. *Change Impact:* How does the diagram communicate the impact of changes to requirements or data definitions across design, implementation, and testing?
]

---

# Mini Project Packet

&nbsp;

.box-inv-5.normal.sp-after[
Please be sure to include these answers in your submission
]

---

# *The Toaster Project*

---

&nbsp;

---

.center[
<figure class="figure">
<img src="images/Deconstruction.png" alt="Deconstruction" title="Deconstruction" width="70%">
</figure>
]

---

.center[
<figure class="figure">
<img src="images/Construction2.jpg" alt="Construction" title="Construction" width="70%">
</figure>
]

---

.center[
<figure class="figure">
<img src="images/Construction3.jpg" alt="Construction" title="Construction" width="70%">
</figure>
]

---

# Challenges, Solutions

---

### Q1. Feasibility & Hidden Complexity  
What assumptions are we making about the simplicity, availability of resources, and manufacturability of our design, and how will we validate or challenge them early?

*Expose hidden complexity and prevent unrealistic scope definition.*

---

### Q2. Materials, Supply Chains, and Constraints  
What critical materials, tools, and external resources does our project depend on, and what are the risks if they are unavailable or delayed?

*Early supply-chain awareness and contingency planning.*

---

### Q3. Cost and Schedule Realism  
How will we estimate cost and schedule realistically, and where do we expect uncertainty, rework, or iteration to occur?

*Encourage defensible planning with buffers and explicit risk acknowledgment.*

---

### Q4. Performance Definition & Validation  
What does “success” mean for our system, and how will we verify and validate performance throughout the project rather than only at the end?

*Link requirements to measurable, testable outcomes.*

---

### Q5. Process Choices & Tradeoffs  
How will we evaluate alternative technical approaches, and what criteria will justify simplifying, changing, or abandoning a design when constraints arise?

*Promote pragmatic, evidence-based engineering decisions.*

---

### Q6. Documentation & Learning from Failure  
How will we document decisions, failures, and lessons learned in real time, and how will this knowledge be used to improve subsequent design choices?

*Reinforce engineering as an iterative, learning-driven process.*