Course Syllabus
Below is a syllabus template that includes WSU's required syllabus elements. Please complete all items highlighted in yellow.
Title of Course [Software Maintenance]
Prefix and Number [CPT_S 481]
Semester and Year [tbd]
Number of Credit Hours [3]
Prerequisites [CPT_S 321 and 322 with a C or better; Admitted to major or minor in EECS or Data Analytics.]
Course Details
Day and Time: [tbd]
Meeting Location: [tbd]
Instructor Contact Information
Instructor Name: [tbd]
Instructor Contact Information: [office location, phone, email] [tbd]
Instructor Office Hours: [click here for best practices] [tbd]
TA Name: [tbd]
TA Contact Information: [office location, phone, email]: [tbd]
TA Office Hours: [click here for best practices] [tbd]
Course Description
[Software maintenance, refactoring, reengineering, reverse engineering.]
Course Materials
Books: [
[0] Tom Mens, Alexander Serebrenik, and Anthony Cleve. 2014. Evolving Software Systems. Springer Publishing Company, Incorporated.
[1] P. Grubb and A.A. Takang, Software Maintenance: Concepts and Practice, 2nd ed., World Scientific Publishing, 2003.[1]
[2] IEEE Std. 14764-2021 - ISO/IEC/IEEE International Standard - Software engineering - Software life cycle processes - Maintenance, IEEE, 2021..[2]
[1] Available on Amazon; ISBN-13: 978-9812384263.
[2] Available on the IEEE Xplore Digital Library; access provided by WSU Libraries. Direct link here.
]
Other Materials: [[3] Keith Brian Gallagher and James R. Lyle. 1991. Using Program Slicing in Software Maintenance. IEEE Transactions on Software Engineering, Vol. 17, Issue 8 (August 1991), 751–761.
[4] H.M. Sneed, “Offering Software Maintenance as an Offshore Service,” Proc. IEEE International Conference on Software Maintenance (ICSM), IEEE, 2008, pp. 1–5.]
Fees: [none]
|
Course Learning Outcomes (students will be able to:) |
Activities Supporting the Learning Outcomes | Assessment of the Learning Outcomes |
|---|---|---|
| Work with a project team to add/modify features of existing software systems. |
Software maintenance activities (weeks 3-10) |
Project, mid-term 1 |
|
Apply the corrective, perfective, adaptive and preventive types of software changes and maintenance types. |
Software maintenance categories (weeks 1 and 2) |
Mid-term 1 |
| Apply regression testing techniques and verify that a change has not introduced new bugs. |
Regression testing (week 9) |
Mid-term 2, project |
| Determine the initial and estimated impact sets of a change. |
Change impact analysis (weeks 4 and 5) |
Mid-term 1 |
| Apply techniques and tools to facilitate the understanding of an existing software system. |
Program comprehension and reverse engineering (weeks 3, 6, and 7) |
Mid-term 2, project |
|
Apply appropriate refactoring techniques to improve the quality of the software. |
Quality measurement and improvement (weeks 6, 7, 8, and 13) |
Final exam, project |
| Determine actions that need to be accomplished to perform software migration. |
Software migration (week 14) |
Final exam |
| Dates | Lesson Topic | Assignment | Assessment |
|---|---|---|---|
|
Week 1 |
Fundamentals of software maintenance and evolution. Maintenance categories. |
- Ch. 1, 3, and 4 [1] - Ch. 3 and 6.2 [2] |
|
| Week 2 [dates] |
Software maintenance process. |
- Ch 5 [1] - Ch 5 [2] |
|
| Week 3 [dates] |
Program comprehension. |
- Ch 6 [1] |
Project deliverable 1- part 1 |
| Week 4 [dates] |
Change impact analysis. |
- Ch. 13.3 [1] |
|
| Week 5 [dates] |
Program slicing. |
- Ch. 14 [1] - [3] |
Project deliverable 1- part 2 |
| Week 6 [dates] |
Reengineering. |
- Ch.7 [1] |
Mid-term 1 |
| Week 7 [dates] |
Refactoring. |
|
|
| Week 8 [dates] |
Testing. |
- Ch. 9 [1] |
Project deliverable 1- part 3 |
| Week 9 [dates] |
Specifying, reviewing, and controlling software maintainability. |
|
|
| Week 10 [dates] |
Spring vacation |
|
|
| Week 11 [dates] |
Management issues during software maintenance (e.g., organizational objectives, outsourcing). |
- [4] |
|
| Week 12 [dates] |
Maintenance cost estimation. |
|
Mid-term 2 |
| Week 13 [dates] |
Software maintenance measurement. |
- Ch. 12 [1] - Ch 6.5 [2] |
|
| Week 14 [dates] |
Migration. |
- Ch. 13.6 [1] - Ch. 5.5 [2]
|
|
| Week 15 [dates] |
Retirement. |
- Ch. 5.6 [2] |
Project deliverable 2 |
Expectations for Student Effort
[Describe how much time students should expect to invest in the course each week. Graduate courses should state: "For each hour of lecture equivalent, students should expect to have a minimum of two hours of work outside of class." Note that Global campus courses will automatically include credit hour equivalents in the syllabus.]
Assignments/Project:
The assignments for this course consist of a group project in which students will work together to maintain an existing software system. Students will work with a real world open source system. We will be forming teams of 3 to 5 members - 5 being highly recommended.
For the first deliverable, students will be asked to handle a set of change requests consisting of bug fixing and addition of new features. The deliverable is split into 3 parts where students work on a single request in each part before moving to the next one. In addition to the code implementing the change requests, students will deliver a report describing the steps, techniques, and tool that were used to implement the change request. Of critical importance here are the comprehension activities prior to the change requests, pre/post-factoring activities, bug localization, change impact analysis, unit testing and regression testing activities. Assessment criteria include the clarity of the report, the choice of techniques and justification of design decisions. For the second deliverable students will evaluate the quality of the open source system using measures that are specific to software maintenance. Those metrics may include changeability, testability, and stability. The choice and justification of the selected metrics will be part of the assessment criteria. Students will apply appropriate modernization techniques such as refactoring to improve the quality of the existing system. The choice of modernization techniques, the justification of the undertaken activities, and the history of the version control tool used by the students will be given high importance. In addition to the improved code, students will provide a report reflecting of the quality of the system before and after the modernization techniques.
All team members are expected to contribute equally to all project deliverables and to all components of each project deliverable. As part of all deliverables, the team will list the tasks assigned to each team member, the tasks completion percentages, and the tasks completion dates. The instructor will use the history of the version control system (e.g., submitted artifacts such as code and documentation, time stamps, commit messages) to verify the task completion percentages and the individual contribution of each team member. In addition, each team member will fill a confidential peer evaluation questionnaire evaluating her/his own performance and the performance of the rest of the team. The peer evaluation will be used as guidance and will help the instructor to understand the team dynamics and the contribution of the individual team members but it will not be used directly as part of the students’ grades. The task assignment, the version control history, and the peer evaluation questionnaire will be used to adjust the project grade for individual team members. The team will receive the same group grade (g) for a given deliverable. The group grade will then be adjusted by an individual weight (wi) between 0.00 and 1.00, which corresponds to the percentage of the work completed by each individual that was assigned to her/him. If the performance of an individual team member is considered unsatisfactory, i.e., she/he completes less than 80% of the work that was assigned to her/him, then to avoid penalizing the team for poor performance of individual team member, the grade of the team will be adjusted positively by discarding the tasks assigned to the team member that performed poorly.
In a team with 4 members for example, an equal task distribution will imply that each team member will complete a set of tasks that account about 25% of the work. Suppose that team members 1, 2, and 3 complete 100%, 95% and 90% of their tasks, respectively. Their individual weights will then be equal to 1, 0.95, and 0.9, respectively. Suppose also that team member 4 only completed 30% of the tasks that were assigned to her/him; his individual weight will then be 0.3. As team member 4 performed poorly, the group grade for team members 1, 2, and 3 will be adjusted by discarding the task of team member 4, i.e., by discarding 25% of the project.
Each team member must submit a peer evaluation report for all team members (including yourself) for every deliverable. The evaluation report must contain:
- the names and WSU IDs of all team members,
- the tasks assigned to each team member,
- the percentage of completion of each high level task and dates of completion of the tasks if applicable
- overall task completion percentage for all team members
- short description providing details on the performance, motivation, commitment, etc. of all team members.
The group grade will be assigned by evaluating the following components:
|
Deliverables |
Components |
Percentage of the final grade |
|
Deliverable 1 |
|
25% |
|
|
Delivered software code |
10% |
|
|
Software documentation |
10% |
|
|
Report |
5% |
|
Deliverable 2 |
|
25% |
|
|
Delivered software code |
10% |
|
|
Software documentation |
10% |
|
|
Report |
5% |
Choice of Project
The group project consists of maintaining an existing open source project. You can choose either from an existing open source project (option 1) or from the EECS provided projects (option 2).
Option 1: Existing open source project: There are plenty of open source projects that you can chose from. Here is where you can start searching:
The project you select must be a real project (e.g., not a student assignment), must be active (at least one commit in the past one week), must have a bug tracking system, must have at least 3 members, and must have some documentation. The project’s main programming language will preferably be Java.
Once you have selected the project clone it and create your own repository (shared with the rest of the team and the instructor). You will be working on this cloned repository.
Option 2: Existing EECS projects: We will provide a set of repositories that contain projects from past senior design teams and club projects that are open source. Those projects will be documented and will have clearly identified opportunities to contribute to them.
Deliverable 1
Every team member must select three existing open change requests that they will handle. Preferably there will be a diversity among the types of change requests. For example, one would be a bug fix, another will be adding a new feature, etc. There will also be a diversity regarding the severity of the change requests. You are free to submit change requests yourself and address those.
What to submit:
- Code implementing the change requests. Every change request must be packed as a separate patch.
- Tests for the implemented change requests.
- The existing documentation will be updated/added to account for the implemented change requests.
- The report will describe the steps, techniques, and tool that were used to implement the change requests. Of critical importance here are the comprehension activities prior to the change requests, pre/post-factoring activities, bug localization, change impact analysis, unit testing and regression testing activities, code review. Assessment criteria include the clarity of the report, the choice of techniques and justification of design decisions. The report will also describe the changes to the documentation. Moreover, the submitted patches must be linked to relevant activities. For example, commits in the version control history, tasks in the project management tools, etc.
- Peer evaluation. Each team member must submit a peer evaluation report through "Peer evaluation for Project Deliverable 1" assignment.
- Schedule a demo with the instructor.
Deliverable 2
The second deliverable consists of evaluating the quality of the open source project using measures that are specific to software maintenance. Those metrics may include changeability, testability, and stability. The choice and justification of the selected metrics will be part of the assessment criteria. Students will apply appropriate modernization techniques such as refactoring to improve the quality of the existing system. The choice of modernization techniques, the justification of the undertaken activities, and the history of the version control tool used by the students will be given high importance.
What to submit:
- Code implementing the improvements.
- Tests for the improved parts of the code.
- The existing documentation will be updated/added to account for the implemented improvements.
- The report must reflect on the quality of the system before and after the improvement. The report will also provide a rationale behind the metrics used to measure the quality of the project, the implemented improvements, the modernization techniques used, etc. The report will also describe the changes to the documentation. Moreover, the report will highlight the links among the improvements and the relevant activities such as the commit ids, the tasks, etc.
- Peer evaluation. Each team member must submit a peer evaluation report through assignment "Peer evaluation for Project Deliverable 2".
- Schedule a demo with the instructor.
Grading [add more lines if necessary]
| Type of Assignment (tests, papers, etc) | Points | Percent of Overall Grade |
|---|---|---|
|
Mid-term 1 |
15 |
15% |
|
Mid-term 2 |
15 |
15% |
|
Final exam |
20 |
20% |
|
Project deliverable 1 |
25 |
25% |
|
Project deliverable 2 |
25 |
25% |
| Grade | Percent | Grade | Percent |
|---|---|---|---|
| A |
[insert]>= 95% |
C | [insert]>=73% and <77% |
| A- | [insert]>=90% and <95% | C- | [insert]>=70% and <73% |
| B+ | [insert]>=87% and <90% | D+ | [insert]>=65% and <70% |
| B | [insert]>=83% and <87% | D | [insert]>=60% and <65% |
| B- | [insert]>=80% and <83% | F | [insert]< 60% |
| C+ | [insert]>=77% and <80% |
[Provide information about how grades will be rounded (eg, if 89% earns a B+ and 90% earns an A-, what grade is given to a student with an 89.5?]
Attendance and Make-Up Policy
[Provide details on how attendance affects final course grades. Indicate whether and how missed exams, laboratory sessions, etc. can be made up. Sample attendance statement: “Students should make all reasonable efforts to attend all class meetings. However, in the event a student is unable to attend a class, it is the responsibility of the student to inform the instructor as soon as possible, explain the reason for the absence (and provide documentation, if appropriate), and make up class work missed within a reasonable amount of time, if allowed. Missing class meetings may result in reducing the overall grade in the class.” ]
Course rules:
You must take exam during the assigned test period. Failure to do so will result in a score of zero. However, in extraordinary circumstances and at the discretion of the instructor, a make‐up exam may be offered. An advanced notice must be given to the instructor beforehand.
Unless posted otherwise, assignment documents shall be submitted electronically.
Late penalty is a flat 10% deduction per day. Late assignments may be turned up to one week after the original due date, and an advanced notice must be given to the instructor beforehand for the late submission. No homework will be accepted after its due day without advanced notice or special permission from the instructor.
Uncompleted peer evaluations will be returned for revisions. 10% will be deducted each day calculated from the original due day until the evaluation is completed or a total of 70% is deducted.
Reasonable Accommodation:
Reasonable accommodations are available for students with a documented disability. If you have a disability and need accommodations to fully participate in this class, please either visit or call the Access Center (Washington Building 217; 509-335-3417) to schedule an appointment with an Access Advisor. All accommodations MUST be approved through the Access Center.
Academic Integrity Statement
You are responsible for reading WSU's Academic Integrity Policy, which is based on Washington State law. If you cheat in your work in this class you will:
I encourage you to work with classmates on assignments. However, each student must turn in original work. No copying will be accepted. Students who violate WSU's Standards of Conduct for Students will receive an F as a final grade in this course, will not have the option to withdraw from the course and will be reported to the Office Student Conduct. Cheating is defined in the Standards for Student Conduct WAC 504-26-010 (3). It is strongly suggested that you read and understand these definitions. (Read more: http://apps.leg.wa.gov/wac/default.aspx?cite=504-26-010)
-Be reported to the Center for Community Standards
-Have the right to appeal my decision
-Not be able to drop the course of withdraw from the course until the appeals process is finished
If you have any questions about what you can and cannot do in this course, ask me.
If you want to ask for a change in my decision about academic integrity, use the form at the Center for Community Standards website. You must submit this request within 21 calendar days of the decision.