Software Engineering Midterm Defense Guidelines

Introduction
The Software Engineering 2 course continues the Software Engineering 1 course. The students enrolled
are grouped and tasked to develop usable software for their respective clients adhering to the needs of
their client’s businesses. The software must meet the objectives of the software engineering approach,
which is to develop quality software within the budget and schedule. The students may use frameworks
to speed up development and any tools as they see fit for the implementation. Using online templates,
content management tools, drag-and-drop web development tools, software reuse, and any subscription-
based or ready-made software is NOT ALLOWED.

Purpose
The purpose of the Software Engineering Midterm Presentation is to check if the students were able to
implement both functional and non-functional requirements, including creative requirements using
different software engineering techniques. The software developed must pass the software quality
attributes defined in ISO/IEC 25010:2011 Software Quality Model and focus only on functional suitability,
usability, reliability, and maintainability.

Scope:
The midterm defense will only cover 60% of the module to be presented, including the system’s primary
purpose. For example, for an e-commerce app, the system shall allow ordering products until tracking and
receiving them. If the system incurs a minimum of three major defects, the group immediately fails the
defense and receives the lowest score.

Schedule of Defense
The defense is scheduled on March 23 to March 25, 2023, from 8 AM to 5 PM.

Panel Composition
There should be at least 3-panel members, 2 of whom should be CCS faculty members and at least one
industry expert.

System Requisite
▪ Publish your source code to the GIT repository (add your instructor for verification)
▪ Deploy web app to production environment (published online, localhost is not accepted)
▪ For mobile apps, the app must be generated ahead of time and be able to share with the panel
members. The database user must be online. (Local database is not allowed)
▪ Be ready with all the links where to access your system and the accounts to use. Before starting
the system demonstration, these must be shared with panel members.

Documentation Requirement (Hardcopy at least 3)

▪ Chapter 1 – Project Overview
▪ Chapter 2 – The Company
▪ Chapter 3 – Project Plan and Schedule
▪ Chapter 4 – Project Costing
▪ Chapter 5 – Requirements Engineering
▪ Chapter 6 – System Interface
▪ Chapter 7 – Testing and Results
 o Test Cases
o Test Results Summary
o Testing Plan

Presentation Flow

Intro & Deliberation &

Q&A Results
Presentation Assessment

Final Ratings
▪ Passed with no revision
▪ Passed with minor revision
▪ Conditional Passed with major revision

Presentation Outline
Part 1 – PowerPoint Presentation
1. Short Company Introduction
2. Project Overview
3. List of Features
4. Users and Roles
Part 2 – System Demonstration

Grading System

• Midterm Defense – 30%

• Final Defense – 70%

Prepared by:

Mr. Jaydee C. Ballaho/Engr. Marjorie A. Rojas

Software Engineering Instructor

Noted:

Ms. Lucy Felix-Sadiwa, MSCS

Computer Science Department Head
 SOFTWARE ENGINEERING 2 MIDTERM DEFENSE RUBRIC

Criteria 1 2 3 4 5
Delivered with confidence,
Organized and somehow Precise, organized and
Confused and Organized but failed to managed, and captured
connected with the combined with the
Delivery and unstructured; Cannot connect with the audience; audience interest;
audience; Answered audience. Answer
Knowledge (10%) answer questions/ Some questions were Thoroughly answered
questions but with little questions with enough
Incorrect answers unable to answer questions with elaboration
supporting details supporting details
and supporting details
Less than 50 % complete 60 – 70 % complete and
71 – 80 % complete and 81 – 90 % complete and
Project Status (20%) Less than 30 % complete and partially meet the partially meet the
meet the requirements meet the requirements
requirements requirements
The main module is The main module is
All units/modules are not The main module is not All units and modules are
Functionality (20%) working, but some modules working, but some module
working working working as intended
failed to integrate is not working
With menus and Good design and process- Easy to learn, understand,
Usability (20%) Poor design Good design
navigations but confusing oriented use, and navigate

The plan was unable to The system works well

The system failed to work The system works well The system operates under
Reliability (10%) work under some best-case even under worst-case
as intended under best-case scenarios some worst-case scenarios
scenarios scenarios

Static settings and the Dynamic environments but The system has a built-in
The system is not The system can be easily
Maintainability (10%) system cannot undo user system maintainability is content management
operational deployed in live production
actions limited system
Below are the technical Average technical Exceeded technical
Meet technical needs for
Complexity (10%) CRUD System Only requirements for course requirements for course requirements for course
course level
level level level