Project Deliverables

EE 547: Applied and Cloud Computing for Electrical Engineers

Deliverables Overview

Deliverable	Weight	Due Date
Draft Proposal	3%	31 Oct 2025, 23:59
Revised Proposal	8%	09 Nov 2025, 23:59
Status Report	6%	30 Nov 2025, 23:59
Technical Demo	20%	11 Dec 2025, 14:00–17:00
Final Report	25%	15 Dec 2025, 12:00
Video	3%	15 Dec 2025, 12:00
Source Code	35%	15 Dec 2025, 12:00
Total	100%

GitHub Repository Access

All project code must be maintained in a private GitHub repository. Grant read access to the GitHub user github-share-uscece no later than 31 October 2025 (draft proposal deadline) and maintain this access through 17 December 2025. The instructor will clone your repository directly for evaluation—you do not submit code archives. Your repository should show regular commits from all three team members throughout the project period demonstrating ongoing development and collaboration.

Draft Proposal

See sample template.

Due: Thursday, 31 October 2025 at 23:59 Weight: 3%

The draft proposal establishes your project direction and allows the instructor to provide early feedback before significant implementation effort. This is an initial document that outlines your concept and approach. Expect your proposal to evolve as you begin implementation and gain deeper understanding of your system’s requirements.

Content Requirements

Problem and Application: Describe the problem your application addresses and what functionality it will provide. What will users be able to accomplish with your system? Why is this problem worth solving?
System Architecture: Provide a high-level overview of your system components and how they interact. What are the major services or modules? How will they communicate? Include a preliminary architecture diagram showing component relationships.
Technical Approach: Outline the key technologies you plan to use. What AWS services will you leverage? What databases or storage systems are appropriate for your data? How will you handle asynchronous processing? What ML techniques will you incorporate and how do they serve your application?
Data Sources: Identify what data your application will use. Are you consuming external APIs? Will users generate data through interaction? How will data flow through your system?

Evaluation Criteria

The draft proposal is evaluated on clarity of concept, feasibility of the proposed architecture, and evidence that you understand the scope of work required. You should demonstrate a viable direction forward, but detailed implementation plans are not expected at this stage.

Revised Proposal

Due: Saturday, 09 November 2025 at 23:59 Weight: 8%

The revised proposal incorporates instructor feedback from your proposal meeting and reflects any adjustments based on early implementation work. By this point, you should have started building components and have a clearer understanding of your architecture and technical challenges.

Content Requirements

Refined Architecture: Update your system architecture based on feedback and early implementation insights. Provide a detailed architecture diagram showing all major components, data flows, and communication patterns. Explain any changes from your draft proposal and why they were necessary.
Technology Stack: Specify your complete technology stack including programming languages, frameworks, AWS services, databases, and third-party APIs. Justify key technology choices with reference to your application requirements.
Implementation Plan: Describe your approach to building each major component. How will you implement your REST API? What authentication strategy will you use? How will asynchronous processing be coordinated? Where will the ML component fit in your architecture?
Progress Summary: Document what you have accomplished since the draft proposal. This might include setting up infrastructure, implementing initial services, or validating technical approaches through prototypes.
Timeline and Milestones: Provide a realistic timeline for completing your implementation. What milestones will you reach by the status report deadline? What remains for the final weeks before the demo?

Evaluation Criteria

The revised proposal is evaluated on architectural soundness, appropriateness of technology choices, quality of early progress, and realistic scope. Strong proposals demonstrate thoughtful iteration based on feedback and early technical validation.

Status Report

Due: Sunday, 30 November 2025 at 23:59 Weight: 6%

The status report documents your implementation progress and current system state. This checkpoint demonstrates that you have made substantial progress toward a working deployed system.

Content Requirements

Implementation Status: Describe what you have built and deployed. Which components are operational? What functionality is working? Be specific about what exists beyond prototype or local development.
Deployment Progress: Document your AWS deployment status. What services are provisioned and configured? Can your system be accessed remotely? What deployment challenges have you encountered and how did you address them?
Technical Challenges: Discuss obstacles you faced during implementation and how you resolved them. This might include integration issues, performance problems, deployment complications, or unexpected technical limitations. Explain your problem-solving process.
Remaining Work: Identify what remains to complete before the demo. What components still need implementation? What integration work is outstanding? What testing or debugging is required?
Risk Assessment: Note any risks to completing your planned functionality. Are there technical blockers? Do you need to adjust scope? What is your contingency plan if certain features prove too difficult to complete in time?

Evaluation Criteria

The status report is evaluated on demonstrated progress toward a working system, quality of deployment, and realistic assessment of remaining work. By this deadline, you should have significant portions of your system deployed and operational on AWS.

Technical Demo

Due: Thursday, 11 December 2025, 14:00–17:00
Weight: 20%

See Reference deck.

The technical demo is a scheduled session where you demonstrate your working system and discuss your implementation with the instructor. This is a technical evaluation focused on understanding your architecture, design decisions, and how well your system integrates course concepts.

Format

Scheduling: Teams will reserve 12-15 minute time slots during the demo period. Schedule your slot in advance—specific scheduling details will be provided separately.
Attendance: All team members must be present for your scheduled demo. Exceptions require prior instructor approval. If your team is late to your scheduled slot, you may be rescheduled based on availability.
Demonstration: You must show your working system through either a live demonstration or a pre-recorded demo that you can pause for questions. Live demos are encouraged but pre-recording is acceptable if you want to ensure reliability.
Reference Materials: A template slide deck will be provided for you to complete and submit the evening before your demo. This deck serves as a reference for the instructor during your session and includes standard elements like architecture diagrams, system components, and deployment details.

Demonstration Content

Working System: Show your deployed application in operation. Demonstrate key functionality including user interaction, asynchronous processing, data persistence, and ML integration. Walk through typical user workflows.
Architecture and Integration: Explain how your components work together. How do services communicate? How is data managed across components? Where does asynchronous processing occur? How does authentication work?
Technical Decisions: Be prepared to discuss your implementation choices. Why did you structure your architecture this way? What trade-offs did you make? How did you handle challenges that arose during development?
AWS Deployment: Describe your deployment architecture. What AWS services are you using and why? How are components hosted? How did you configure networking and security?

Evaluation Criteria

Technical demos are evaluated on system functionality, architectural design, integration quality, and depth of technical understanding. You should demonstrate both that your system works and that you understand why it works. Be prepared for technical questions about any aspect of your implementation.

Attendance and engagement during other teams’ demos is encouraged but not required.

Final Report

Due: Monday, 15 December 2025 at 12:00 (no late submissions accepted) Weight: 25%

The final report is a comprehensive technical document that describes your complete system. It should provide sufficient detail that someone familiar with cloud computing could understand your architecture, implementation decisions, and results.

Format

There is no required page length—focus on clarity and completeness. LaTeX is not required; submit a single PDF file. Include diagrams and figures to illustrate your architecture and system behavior. Minimize grammatical errors as they impede clear communication. Cite any external sources appropriately—do not copy text without attribution.

Content Requirements

Project Overview: Describe your application and its purpose. What problem does it solve? Who is the target audience? What functionality does your system provide? Set the context for understanding the rest of your report.
Architecture and Implementation: Document your system architecture and technical implementation.

System Architecture: Provide detailed architecture diagrams showing all components, data flows, and communication patterns. Explain the role of each component and how they integrate.
Technologies and Frameworks: List all technologies used including programming languages, frameworks, AWS services, databases, and third-party services. Justify major technology choices.
AWS Deployment: Describe how your system is deployed to AWS. What services are you using? What instance types or compute resources? How are databases managed (RDS, self-hosted, DynamoDB)? Document your deployment architecture with sufficient detail for replication.
REST API Design: Document your API endpoints, authentication mechanisms, and data formats. Include API documentation in an appendix if extensive.
Database Schema: Describe your data model and database schema. How does your schema relate to application functionality? What design decisions did you make regarding data storage?
Authentication and User Roles: Explain how authentication works and what user roles exist in your system. How is user-specific content managed?
External Dependencies: List all external dependencies including packages (package.json, requirements.txt), external APIs, and third-party services.

User Experience: Provide a narrative describing how users interact with your system. Walk through typical user workflows from initial access through key functionality. This should help readers understand what using your application feels like.
Implementation Results: Document what you successfully implemented and what remains incomplete.

Completed Features: Describe all working functionality in your deployed system. What can users actually do?
Incomplete or In-Progress Features: Identify any planned features that were not completed or are partially implemented. Explain their current status and what would be needed to finish them.

Technical Challenges and Solutions: Discuss significant technical obstacles you encountered during development. How did you diagnose and resolve issues? What problems remain unresolved? What would you do differently with more time or different constraints?
Critical Reflection: Address the following questions that demonstrate learning and growth:

What did you fundamentally misunderstand before starting this project? Identify assumptions or understandings that proved incorrect once you began implementation. What did you learn that changed your perspective on cloud architectures or system design?
What technical decisions were most critical to your success or challenges? Reflect on key decision points and their consequences.
How did your understanding of integration and deployment evolve? What did you learn about making independent components work together in a deployed system?

Milestones, Timeline, and Contributions: Document your development timeline and how work was distributed among team members. What were your major milestones? How did each team member contribute to the final system?

Evaluation

The final report is evaluated across three dimensions:

Report Quality (25% of report grade): Relevant background and context, clear organization, quality of writing, effective diagrams and figures, proper citations, and professional presentation.

Project Quality (40% of report grade): Clear objectives and milestones, appropriate scope and significance, thoughtful reflection on learning, and honest assessment of what worked and what didn’t.

Technical Quality (35% of report grade): Sound architecture and implementation decisions, clear description of technical results including successes and failures, documentation of ongoing challenges, and evidence of understanding trade-offs.

Video

Due: Monday, 15 December 2025 at 12:00 (no late submissions accepted) Weight: 3%

The video is a brief summary of your project aimed at a broader technical audience than your report. This is your opportunity to demonstrate your application and explain its purpose to viewers who want to understand what you built without reading a detailed technical report.

Format Requirements

Duration: 3-4 minutes maximum. Strictly enforce the 4-minute limit.

File Format: Any video format supported by YouTube (mp4, mov, avi, etc.).

Participants: Not all team members must appear or speak, though all should contribute to content development.

Distribution: Videos may be distributed or posted for class or academic purposes. If you are comfortable with this, include names in the video. If you prefer to avoid having your face associated with the video publicly, produce your video accordingly. Names may be omitted if you prefer.

Content Requirements

Project Summary: Explain what your application does and what problem it solves. Who would use this system and why?
System Overview: Describe your major system components and how they interact. Provide enough technical detail that a viewer understands your architecture without overwhelming them with implementation specifics.
Demonstration: Show your application in action. Walk through key functionality and user workflows. Demonstrate what makes your system interesting or useful.
Technical Highlights: Highlight interesting technical aspects of your implementation. What challenges did you solve? What integration or deployment aspects are noteworthy?

The video should be engaging and informative for a technical audience that understands cloud computing but hasn’t read your report. Focus on demonstrating your product and explaining how its components work together rather than exhaustive technical detail.

Evaluation Criteria

Videos are evaluated on clarity of explanation, quality of demonstration, and effectiveness of communication. Strong videos make viewers understand and appreciate your work within four minutes.

Source Code

Due: Monday, 15 December 2025 at 12:00 (no late submissions accepted) Weight: 35%

Your source code is the implementation artifact of your project and the most heavily weighted deliverable. Code should be well-organized, documented, and reflect the system described in your report and demonstrated during your technical demo.

Repository Access

Your code is evaluated through your GitHub repository. Ensure you have granted read access to github-share-uscece by the draft proposal deadline and maintain access through 17 December 2025. The instructor will clone your repository for evaluation.

Documentation Requirements

README Files: Include comprehensive README files that describe:

Major files and directories in your repository
Repository structure and organization
Setup and deployment instructions for your application
Environment configuration requirements
External dependencies and how to install them
Database setup and schema initialization
Instructions for running your application locally and deploying to AWS
Any special technical requirements or prerequisites

Your README should enable someone familiar with cloud development to understand, set up, and deploy your system.

Code Comments: Include comments for non-obvious code sections, complex algorithms, or architectural decisions. Your code should be readable and maintainable.

Code Organization

Organize your code with clear separation of concerns:

Backend services and API implementations
Frontend application code
Database schemas and migration scripts
Deployment scripts or infrastructure-as-code
Configuration files for different environments
Tests (if implemented)

Your repository structure should reflect your system architecture logically.

Evaluation Criteria

Source code is evaluated on correctness, organization, documentation quality, and how well the implementation matches your described architecture.

Implementation Quality: Does your code correctly implement your system as described? Are components properly integrated? Does your application handle errors appropriately?

Organization and Clarity: Is your code well-structured? Can someone navigate your repository and understand its organization? Are naming conventions consistent and meaningful?

Documentation: Can someone else deploy and run your system based on your documentation? Have you documented deployment procedures and configuration requirements?

Consistency with Report: Does your implementation match what you described in your report? Are architectural diagrams accurate representations of your code?

The source code represents the culmination of your project work and should demonstrate both technical competence and thoughtful system design.