Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Capstone Project Evaluation and Grading Guidelines, Lab Reports of Capstone Design

Detailed evaluation and grading guidelines for a capstone project in software engineering. It outlines the various components of the project, the evaluation criteria for each component, and the submission dates. The project consists of inception, elaboration, construction and deployment, and report, demonstration, and viva phases. The document emphasizes the importance of use cases, domain modeling, risk management, design principles, data modeling, ui/ux design, and deployment considerations. It also highlights the role of jira, github, and ci/cd pipelines in the project.

Typology: Lab Reports

2023/2024

Uploaded on 03/15/2024

vikram-belgaonkar
vikram-belgaonkar 🇮🇳

1 document

1 / 6

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Evaluation component Credit Submission Date Submission
EC1 – Inception 10% 15 August (Tue) Canvas/JIRA
EC2 – Elaboration 20% 29 August (Tue) 2 Sept (Sat) Canvas/JIRA
EC3 A – Construction & Deployment 25% 12 Sept(Tue) 16 Sept (Sat) Canvas/JIRA
EC3 B – Construction & Deployment 25% 26 Sept (Tue) 30 Sept (Sat) Canvas/JIRA
EC4 – Report, Demonstration & Viva 20% 30 Sept (Sat) 7 Oct (Sat) Canvas/JIRA
Capstone Grading 100% 14 Oct (Sat)
Evaluation
Date*
19 August
(Sat)
pf3
pf4
pf5

Partial preview of the text

Download Capstone Project Evaluation and Grading Guidelines and more Lab Reports Capstone Design in PDF only on Docsity!

Evaluation component Credit Submission Date Submission EC1 – Inception 10% 15 August (Tue) Canvas/JIRA EC2 – Elaboration 20% 29 August (Tue) 2 Sept (Sat) Canvas/JIRA EC3 A – Construction & Deployment (^) 25% 12 Sept(Tue) 16 Sept (Sat) Canvas/JIRA EC3 B – Construction & Deployment 25% 26 Sept (Tue) 30 Sept (Sat) Canvas/JIRA EC4 – Report, Demonstration & Viva (^) 20% 30 Sept (Sat) 7 Oct (Sat) Canvas/JIRA Capstone Grading 100% 14 Oct (Sat) Evaluation Date* 19 August (Sat)

Faculty Group Interacti on

2 12 Participation in Interactions / Evaluations 2 JIRA Activities 3 EC3 B – Construction & Deployment 25% 20 Participation in Interactions / Evaluations 1 JIRA Activities 4 EC-4- Report, Live Demonstration and Viva 20% 10 5 5 o Deployment plan o Prototype II (Executable) o Prototype III (Executable) o Capstone final report o Minimal Viable Product (MVP) o Viva (Individual)

Evaluation Guidelines Use cases are written in fully descsriptive manner Important use cases are provided, not trivial one like login, registration Use case model provided with primary, secondary actors Don’t only consider use case model, dsecriptive use cases are must RUPS are taken into consideration Thoughts are given for mitigation of these requirements Domain objects and relationship within is well identified and shown with proper notation Enough care taken at managing the complexity level Potential risks/challenges are noted down Thoughts towards resolution are also provided Refinement to the previous version of use cases For important use cases, sequence diagrams are provided More detailed attributes are identified Refinement to the previous version of domain objects Main components / services are identified Interaction between the components are defined If feasible, process workflow is shown with flowchart / activity diagram Technology / tool required for supporting the architecture are identified Classes / Components are described in detail Relationship between classes / components conveyed If appropriate, packaging of components defined Design principles / patterns are leveraged while designing the system Some thoughts on UI/UX design are also given Thoughts are given for deployment of components as well Important entities are identified ERDs are shown with proper notation Various options are explored and decision for tool taken Thought given to actual implementation of data model in physical databases Atleast one important (and might be riskier) use case is working Backend / fronend can be mimicked based on where risk is more Refinement to proposed architecture Firm decision on tool / framework / programming languare for implementation Refinement to proposed design API design considered Focus on modularity and coupling , reducing complexity Data model is more refined with more detailing of entities and attributes Thought given to communication between backend and databases Translation of data model into physical implementation using tool / language Thoughts given to the deployment - local / clustered / cloud based Risks in those aspects are identified