



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
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
1 / 6
This page cannot be seen from the preview
Don't miss anything!
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