Home

Online Learning

Degrees

FAQ

Schedule of Courses

Contact Us

Texts

Software

Other Resources

Catalog Description

Course Objectives

Prerequisites

Class Location

Grading

Assignments

Additional Information

Schedule of Assignments and Events

Contact Information

Texts

Refactoring: Improving the Design of Existing Code (1st ed.) , by Martin Fowler et al., Addison Wesley ISBN 9780201485677 (1999) (Required) Download the errata.

Test-Driven Development: By Example (1st ed.), by Kent Beck, Addison Wesley ISBN 978-0321146533 (2002) (Required)

Software

• A Distributed Version Control System (DVCS) and Protocol:
• You may choose your own (but it must be the same as your team mates' choice).
• Or, if you don't want to investigate and choose, you and your team mates can select bitbucket, with the GIT protocol. If you make this choice, do make good use of the tutorials at the website!
• An automated testing framework for unit tests:
• If you are programming in Java, JUnit is a good choice.
• If you are programming in C++, Google Test is a good choice.
• If you are programming in C#/.NET, NUnit is a good choice.
• If you are programming in a .NET language (C# or C++), and you are using a recent version of Microsoft's Visual Studio (VS) IDE, the built-in VS unit test tool is a good choice.

Other Resources

One reference for Test-Driven Development (TSS) is the Wikipedia.

Another reference for Test-Driven Development (TSS) is c2.com.

Course Description

Software maintenance and the improvement of the design of existing code. Incremental development, adding new features with support from refactoring. Design quality evaluation and design quality improvement. Test-first development. Version control.

This Online Learning course begins on January 12, 2015.

Back to Top

Course Objectives

Breadth and Depth in Defining, Analyzing, and Solving Complex Problems:

• After successfully completing this course, you should be able to demonstrate a basic capability to apply refactoring techniques to solve complex problems.

Communicate Technical Aspects of the Solution for Complex Software Engineering Problems to a Technical Audience:

• After successfully completing this course, you should be able to demonstrate a basic ability to communicate regarding the application of refactoring techniques to a technical audience.

Back to Top

Prerequisite(s)

SSE 550 Object-Oriented Design I

Back to Top

Class Location

• The Online Learning asynchronous "meetings" take place in Cyberspace; i.e., on the Internet.

Back to Top

Grading

Item	Percent of Term Grade
Direct Activity Report 1	5
Direct Activity Report 2	5
Direct Activity Report 3	5
Project 1	25
Project 2	25
Project 3	35

Credit will be given only for original work.

The Mercer University Student Handbook, including its provisions for academic honesty (including plagiarism), applies to all Mercer students.

Project reports are to be submitted complete, not as incremental partial submissions.

All course work is categorized as either Direct or Non-Direct (but not both). More information about the Direct and Non-Direct categories is contained in the Direct and Non-Direct and Report Logs. Please read these pages very carefully.

Instruction Time

Federal and regional accreditation requirements stipulate that a 3-credit hour course must include 150 minutes of direct instruction time per week. For this course, that direct instruction time includes"

• Collaborative discussions with other students regarding the content of readings assigned for the course.
• Collaborative discussions with other students regarding the content that goes beyond readings assigned for the course, but is not part of work on the projects assigned on the syllabus.
• Collaborative development of generic technology that may be useful for your project(s), but is not, in its generic form, part of your project.

In addition to the 150 minutes of direct instruction time each week, students are expected to spend a minimum of 300 additional minutes per week completing reading and writing assignments:

• Doing the assigned reading.
• Working on the projects assigned on the syllabus.

More information about the Direct and Non-Direct categories is contained in the Direct and Non-Direct and Report Logs. Please read these pages very carefully.

Use the Report Logs to help you to manage your time and keep on schedule. You should schedule your work evenly throughout the term. If you fall behind schedule for your Direct Activities, and you "catch up" by your last Direct Activity Report, your previous Direct Activity Report grades can be raised to reflect your success in meeting this requirement, provided that your previous Direct Activity Reports were submitted in a timely manner. Direct Activity Reports not submitted in a timely manner will receive a grade of 0 (zero) unless the professor has approved an extension in advance.

The Non-Direct Activity reports do not receive a separate grade, but are used to help in evaluating your project reports.

More information about project grading is contained in the General Project Rubric .

If you have a question about any of this, please ask.

Back to Top

Assignments

• Purpose of projects:
• Use the projects to develop your capabilities, and
• Use the projects to demonstrate your capabilities.
• Deliverables for all projects:

  All course work is categorized as either Direct or Non-Direct (but not both). Read Direct and Non-Direct and Report Logs before continuing. Please read these pages very carefully.

  • All Direct Activity Reports include a Direct Activity Log, and may include additional supporting material at your discretion.

  • All Project Reports include a Non-Direct Activity Log, in addition to your work on the project.

  • Projects shall be delivered either via the course FTP site.
  • Project reports should each be a single, standalone .pdf document, with the Bookmark feature used to support easy document navigation. Note that both MS Word and LibreOffice (which is free open-source software) support bookmarks, and will carry the bookmarks over into the pdf document when they convert your .docx, .odf, or whatever file type to PDF.
  • Project reports should focus on the development and/or maintenance that you actually do. Reports should not focus on summarizing or explaining the text or other materials.
  • Inclusion of screenshots demonstrating your work, and code you actually wrote for the project, are appropriate. Long code listings can be placed in appendices if doing so does not interfere with you presenting your work on that code in the body of the text.
  • Your report should be organized in such a way as to make the topics that you want credit for covering easy to find, and demonstrate your capabilities clearly and convincingly. Everything you want considered for credit, including code and tests (including test results), should be included in the report.
  • Each project can be a single, integrated project that tries to actually do something, or a collection of exercises that demonstrate your capabilities but don't accomplish anything else, or any combination of these two alternatives that you find convenient
  • You may include other material outside of the report (on the FTP site), if you wish, but this material may or _may not_ be considered in evaluating your work.
  • For each capability that you demonstrate within a report or major section of that report, you may present only the final result of your work; you need not demonstrate every step in the development of that result.
• Some suggestions for doing a project are contained in the One Way to Do a Project page.
• Test-Driven Development (TDD() and and Distributed Version Control Systems (DVCS) are to be used for all projects in this course.
• Project 1(Team and Solo - please read on) TDD-Version Control
• Form your team.
• Teams may have 2, 3, or 4 members. Each team member is to report to me, privately, via email, their estimate of the percentage of them team's work done by each team member at the end of the term. Estimates are to be independent.
• You may form your own teams. Announce your team's composition via the course listserv.
• Each team member will use the same version control system, so choose it carefully!
• Each team member will use the same programming language. (Teams programming in .NET languages may mix C++ and C#, both based on .NET, if they wish.)
• In parallel:
• Each individual should get their own version control software (the same version control software as their team mates) working for them. That is, they should start developing software using that system.
• Each individual should study the TDD references listed at Other Resources.
• After getting version control working and studying TDD, each individual should develop one or more example apps using version control and TDD. Many IDE's support TDD tools (e.g, JUnit for Java). Each individual can choose the TDD unit test tool they prefer. Choose carefully! Some, such as CppUnit, are reportedly not well supported now. For C++, Google Test may be a better alternative.
• For Java and C#, this project may cover topics of the student's (individual) choice.
• The team portions of this project are the selection of team members, programming language, and DVCS. Each individual will develop his/her own example apps, and write and submit her/his own Project 1 report.
• Project 2 (Team):
• Find some code in your selected language (Java, C#, or C++) that you can refactor for this project. (Hint: the source code for Junit, Nunit, or CppUnit would not be an appropriate choice. Otherwise, open source software may be a good source of code to refactor.)
• Develop and demonstrate your capabilities in the topics covered in Chapters 3 through 12 of Fowler.
• Use an automated tool such as Junit or another to implement your test-first testing as part of refactoring.
  
• Project 3 (Team):
• Step 1. Read the Wikipedia article on software maintenance https://secure.wikimedia.org/wikipedia/en/wiki/Software_maintenance . Complete this step before moving on.
• Read something else about software maintenance. Briefly report on what you read in your project report.
• Phase 1: Software Acquisition (Team or Solo):
• Make sure that you complete this phase early. If you reach April 1 without having the software and maintenance requirements on hand (not promised for the future), you should consider the situation urgent, and make sure that you complete this phase NLT April 2.

There are two options for you to acquire the software that you will maintain:

1. Team Approach: Each team member shall provide another team member with software to maintain, and some information about the required maintenance (maintenance requirements). This software shall be new to the person who receives it, and no two team members shall maintain the same software. Person A provides some software and maintenance requirements to person B (A -> B); Person B provides some software and maintenance requirements to person A (B -> A). If you have a three person team, then A -> B, B -> C, and C -> A. Four person teams work similarly, so that no person maintains their own software.
2. Solo Approach: You find software to be maintained (software that you did not write!) from any legitimate source, and create the maintenance requirements yourself or obtain them from someone else.

Phase 1 has no deliverable, but the code and maintenance requirements you obtain are included in your Phase 2 report.

• Phase 2: Software Maintenance (Solo):
• You perform the maintenance.
• This project is not about refactoring, is it more about maintenance in general, and maintenance will get primary credit in grading this project. Use refactoring only as appropriate. If it is not appropriate, don't use it.
• TDD and DVCS are required, and must be demonstrated.
• Manage scope. Too little scope does not demonstrate enough capability. Too much scope prevents you from finishing on time, and you must finish on time. It is okay to not be able to complete all of the maintenance requirements as long as the requirements you do complete demonstrate sufficient maintenance capability.
• Deliverable:
Each student delivers their own report of the maintenance they performed. Report contents include:
• An identification of the code to be maintained, including how you obtained it, and from whom.
• A specification of the maintenance requirements, including how you obtained them, and from whom.
• A narrative presentation of the maintenance performed, including TDD results and some evidence of continuing and pervasive use of DVCS.
• A statement of results.
• A conclusion.
• An appendix containing the software to be maintained, as it was prior to your maintenance.
• An appendix containing the software to be maintained, as it is after your maintenance.
• TBD

Back to Top

Additional Information

• Asynchronous Learning Nets (ALNs)
• • Self Study: You study the texts and any other course study material on your own(team).
  • Collaborative Projects: After your self-study, you collaborate (via the Internet [email]) with your partner(s) to produce a team product. Your collaborative work is substantial, asynchronous, and rapid.
  • This course is an online learning course. Please read this Online Learning web page regarding online learning in this course and this program.

Back to Top

• What Do I Do?

• Subscribe to the course email listserv. Your professor can tell you how to do this.
• Study the assigned material.
• Write and read email messages about ideas, problems and solutions to do with the assigned study material.
• Do the assigned work, deliver the assigned deliverables.
• Write and read email messages (to/from the listserv) about ideas, problems, projects, and solutions to do with the assigned homework.
• Review the deliverables produced by other people.

Changes to this Syllabus:

There will be changes to this syllabus, so check back frequently, and don't forget to hit "Reload" or "Refresh".

Schedule of Assignments and Events (tentative)

Start Date	End Date	Activity/Event
January 12, 2015	May 1, 2015	Course in Progress
	NLT January 15, 2015	Identify your selected language for this course in an email message to the _course_ listserv.
January 12, 2015	February 9, 2015	Work on Project 1
	February 9, 2015	Direct Activity Report 1 due.
	February 9, 2015	Project 1 due.
	March 16, 2015	Project 2 due.
	April 6, 2015	Direct Activity Report 2 due.
	May 1, 2015	Direct Activity Report 3 due.
	May 1, 2015	Project 3 due.
	May 1, 2015	Course ends. Firm date.

Notes:

tbd

Back to Top

---

Contact Information

• My Name: Dr. Paul E. MacNeil
• My E-mail: macneil_pe@mercer.edu .
• My Office Phone: 478 301-2185
• US Mail:
 
• Dr. Paul E. MacNeil
• School of Engineering
• Mercer University
• 1501 Mercer University Drive
• Macon, GA 31207

Back to Top

Important Additional Information:

“Students requiring accommodations or modifications for a disability should inform the instructor at the close of the first class meeting or as soon as possible. The instructor will refer you to the ACCESS and Accommodation Office to document your disability, determine eligibility for accommodations under the ADAAA/Section 504 and to request a Faculty Accommodation Form. Disability accommodations or status will not be indicated on academic transcripts. In order to receive accommodations in a class, students with sensory, learning, psychological, physical or medical disabilities must provide their instructor with a Faculty Accommodation Form to sign. Students must return the signed form to the ACCESS Coordinator. A new form must be requested each semester. Students with a history of a disability perceived as having a disability or with a current disability who does not wish to use academic accommodations are also strongly encouraged to register with the ACCESS and Accommodation Office and request a Faculty Accommodation Form each semester. For further information, please contact Carole Burrowbridge, Director and ADA/504 Coordinator, at 301-2778 or visit the ACCESS and Accommodation Office website at http://www.mercer.edu/disabilityservices.

---

Accreditation: Mercer University is accredited by SACSCOC.