 |
SWEN 749: Software Evolution and Reengineering
|
Course Description
Developers spend most of their time maintaining and updating existing software systems rather than designing new ones. Generally, evolving a software system, to ensure its continued integration and usefulness, is complex, human-intensive, costly, and an error-prone process. Therefore, practitioners are continually designing creative techniques and tools to improve developer’s experience with software maintenance and evolution. These techniques rely using data mining and intelligent and machine learning algorithms to tackle maintainability problems such us, regression testing, bug localization, API migration, and software refactoring. This course explores the foundations of software maintenance by introducing several challenges linked to software evolution along with support tools to approach them. Also, the course covers various concepts related of software analysis and testing, along with practical tools, widely used in the open source community.
Term
Spring 2185
Course Structure
This class is practice-driven. The first portion of the course will introduce basic concepts and approaches to software maintenance and testing. There will also be an introduction to statistics for software engineering data. The next portion will focus on student review and presentation of tools and techniques presented in journal and conference papers. The final portion is the preparation and in-class presentation of a group project that illustrates solving a real-world maintenance problem, extracted from open-source softwqre systems.Student paper presentations
Every student will select or be assigned one paper to present and 3 papers to review, the papers are related to a topic covered in class. The purpose of this assignment is to allow students to gain a detailed understanding of a specific problem and how it is being approached. The student should highlight the motivation of the work, the novel contributions of the work, any surprising findings and possible applications of the work. The student should also place the work relative to other papers that cite the work, the author’s follow on work and papers that are being presented in our course in the same week.
Student paper discussants
For each paper that is being presented, There will be 4 reviewers. The role of the reviewer is to take an adversarial position and point out the weaknesses or controversial points of the work.
Paper critiques
Every week that we have student paper presentations, each student is expected to send a critique of one of the papers that are being presented. The critique should include a brief summary of the paper, at least three strengths of the paper and at least three weaknesses of the paper. For the other paper, each student is required to submit a summary of the paper. The critiques and paper summaries are due right before the session in which the papers are to be presented.
Course project - research paper
A large portion of the course deliverables is a group project. You are expected to work on the course project in groups of 1-2-3-4 students. Each group is expected to design or enhance an existing concept or tool by the end of the semester. The topic is to be negotiated with the instructor. Examples include a comparatyive study between existing tools or approaches, a survey paper of a software evolution related topic (typically involves surveying 30 – 60 papers), or building a tool to support software evolution and/or testing.
The first deliverable of the course project is a project proposal. The project proposal should be 3 pages in length (plus references). The project proposal should be submitted by the end of week 4. A project progress presentation will be held in week 7. The final project will be presented in weeks 14-15 and the final project report (10 pages in length) should be submitted by the end of week 16. The final submission is expected to be of publishable quality. All project-related documents (i.e., project proposal and project report) should use the IEEE conference publication format. The final submission should contain all the documents, data, tools used along with a proper presentation of the project methodology and outcomes.
Resources:
There will be resources posted periodically on myCourses. Below is a list of textbooks that may help. These books and others may be available on Books 24x7.- Seacord, Robert C., Daniel Plakosh, and Grace A. Lewis. Modernizing legacy systems: software technologies, engineering processes, and business practices. Addison-Wesley Professional, 2003.
- Martin, Robert C. Agile software development: principles, patterns, and practices. Prentice Hall, 2002.
- Refactoring: Improving the Design from Existing Code, Addison-Wesley ISBN 0201485672, 2000.
- Reengineering Software Legacy Systems, Miller, Butterworth Publishers, ISBN 1555581951, 1998.
- Myers, Glenford J., Corey Sandler, and Tom Badgett. The art of software testing. John Wiley & Sons, 2011.
- Software Evolution and Feedback: Theory and Practice, Nazim H. Madhavji, M.M. Lehmann, J. Ramil, Dewayne Perry, John Wiley & Sons, ISBN 0470871806, 2005.
- AntiPatterns: Refactoring Software Architectures, and Projects in
Crisis, Brown, Malveau, Mowbray & McCormick, Wiley, ISBN
0471197130, 1998.
Grading and Deliverables:
Class Participation (5%)
Students are expected to read all papers covered in a week, come to class prepared to discuss their thoughts and take part of the classroom discussions.
Paper presentation (15%)
Every student will be assigned one paper on a course-related topic. In this assignment, the student is to gain a detailed understanding of the paper, and present it to the class. You should not simply repeat the paper content, rather you should focus on the main findings of the paper. You should highlight the motivation of the work, the novel contributions of the work, any surprising findings and possible applications of the work. You should also place the work relative to other papers that cite the work, the authors follow on work and papers that are being presented in our course in the same week.
Paper review (15%)
Two students will randomly be chosen to be discussants. They will have to take the adversarial role and take the lead in critiquing the paper. Everyone will be chosen for this once at least. You will be graded on the intellectual strengths of the critique.
Midterm Exam (10%)
There will be only one comprehensive exam throughout the semester.
Individual Assignments (25%)
This set of assignments be given throughout the term to reinforce class material and will help students better understand the theoretical part of the course. Every student is required to work individually on the class assignments. No group submission allowed.
Group Project (30%)
There will be a final project for the course that develops a research project related to software maintenance (e.g., improve an existing tool, literature review, empirical study between several tools, develop a new metric model, etc.). The project will allow group work, but working in a group is optional (i.e., you may choose to work alone). The students must construct their final report by combining 4 submissions throughout the semester:
- Phase I Project Proposal 33% --Report.
- Phase II Literature Review and Open Research Questions 33% --Report.
- Phase III Validation 33% -- Combined with previous phases to create the final report.
Students are also required to schedule a meeting with the instructor to discuss the project progress in week 9. They are also required to present their findings (summary of their research paper) in a presentation by the end of the semester.
The final deliverables of the project should include: final project paper, source code (if any), data (if any). The final paper should be close to the quality of a publishable workshop paper, and has potential to be developed to a complete research paper. All written papers must use the ACM SIG Proceedings Template. The instructor reserve the right to ask students to fix papers that do not conform to the template. .
Grading Scheme
The ranges for this courseare:| Letter Grade | Numeric Grade | GPA Points |
| A | 93-100 | 4.000 |
| A- | 90-92 | 3.667 |
| B+ | 87-89 | 3.333 |
| B | 83-86 | 3.000 |
| B- | 80-82 | 2.667 |
| C+ | 77-79 | 2.333 |
| C | 73-76 | 2.000 |
| C- | 70-72 | 1.667 |
| D | 60-69 | 1.000 |
| F | Below 60 | 0.000 |
For more information consult the Provost's website: http://www.rit.edu/provost/grading
Grading Policy
I will post grades in the Gradebook section of myCourses. Once a grade is posted for an activity or project you have 72 hours to resolve any grading question. After that it becomes final. Please email your questions to me, even if we have spoken face-to-face.
Students will be evaluated individually using midterms and the final exam. Teams will be given a single grade for units and project deliverables submitted. Individual team members may have their grades for the units and team project adjusted up or down based on their contribution to the project. This adjustment will be based on peer evaluations from your teammates.
If you have a personal event, an RIT activity, or a job-related activity that keeps you from class, please check with the instructor to see if it qualifies as an excused absence. Make up exams will only be granted for very good reasons (job interviews known in advance, documented sickness, family emergencies, etc.).