Software Engineering

Spring 2011; CMSC 435; Section 0101

Welcome to TerpSoft!

By registering for this class, you have automatically become part of a pseudo-company called TerpSoft. This company develops software according to the Software Engineering principles taught in this course. Your customer is the course instructor assisted by the class TA. Your job is to complete the software engineering tasks required by the customer. Because you are part of TerpSoft, YOU need to take initiative to get the project started, make progress, and complete it on time. Schedule meetings with the course instructor and TA so that you get a clear description of the requirements for each project phase.

Before you start, PLEASE READ

• IMPORTANT: As part of this project, you will be expected to use buggy 3rd-party software. This is done deliberately to simulate real-life scenarios. Students are expected to work around the bugs and submit their projects on time.

• Late deliverables will be accepted with a 20% penalty per day. Start your projects early - last-minute computer malfunctions will not be accepted as reason for delaying an assignment's due date.
• All teams will present their project in class.
• The university computer labs should provide all necessary support for the project. Other resources normally available to you (e.g., home computers) can be employed, however you do this is "at your own risk." No alterations to conditions of the assignment will be made to accommodate peculiarities of your other computing resources.

List of Projects, Teams, and Members' Roles

Project Title (each project is assigned to a team)
	Web GUITAR	Sikuli GUITAR	iPhone GUITAR	SWT GUITAR	Android GUITAR	muJava
Project Manager	Valentine Kravets	Peter Enns	Alex Kavalsky	Gabe Gorelick-Feldman	Abeyu Mengistu	Wendy Mock
Other possible roles: {Version control, Hudson, Doc., Testing, Coding, OS, Code Doc, Test Doc.}		Mike Dehn	Alexander Dutil	Eric Stevens	Barry Smith	Abhishek Gupta
	Luis Sanchez	Mihai Mazilu	Temidayo Adebanjo Obayomi	Chris Hurley	Piotr Romam	Robert Henderson
	Philip Anderson	Glenn Hogie		George Sequeira	Yonah Meiselman	Mark Geraty
	Allen Chung	Eric Azebu		Mike Meyers	Tapan Patel	Denis Karamyshev
	Todd Watson	Brad Klein	John Fabrizio	Brian Lager	Gary Sullivan	Philip Mastandrea
	Leyla Norooz	Andrew Ferguson	Brendan Fruin	Aaron Blair	Daniel Wu	Andrew Kukwa
	Brian Ramnarain	Sean Maxwell	Jason Tseng	Kathryn Mackey	Sheldon Neuberger

Project Phases

Phase 1; due date: Feb. 3, 2011.

Goal: Downloading and running all the applications on a simple input.

Procedure: In this phase, you need to demonstrate that you are able to run all six GUITAR applications. The source code for all these applications resides in a Subversion repository that can be viewed at http://guitar.svn.sourceforge.net/viewvc/guitar/. Please refer to https://sourceforge.net/projects/guitar/develop for additional help with Subversion. Some of these applications (lets call them foo for fun) reside in the folder foo.tool/ in the repository. Checkout this folder and read its README.txt file. You will find more information about the modules that foo uses for building and execution. You will also find instructions on how to build and run foo.

Deliverables: There are no deliverables for this phase. Points will be awarded for demos.

Grading session: During the grading session, one team member will be selected at random to do the demo; you will have access to a new machine (Windows or Linux) that is connected to the Internet. You will have to download, build, and execute all six applications and run them on all the inputs. You will also need to install Ant, Subversion, Java, C++, and any other tools needed to run the applications. Each application is worth 15 points.

Points: 90

Phase 2; due date: Feb. 10.

Goal: To understand the problem domain and solicit initial requirements.

Procedure: Talk to the domain experts, read the literature, and interview the customer to understand what the customer wants.

Deliverables: A document that (1) briefly (in one page) describes the problem domain as you understand it, (2) capabilities of the current system, and (3) a list of requirements from the customer and how these requirements will impact the system.

Additional reading(s): 

1. For all teams: http://guitar.sourceforge.net

2. For the Sikuli GUITAR team: please read the two papers listed at the bottom of page: http://www.sikuli.org/docx/ and download Sikuli to become familiar with the tool.

Grading session: Your document will be given to the customer. During the grading session, your team will meet with the course instructor and the customer. We will all examine the clarity and adequacy of the document. (Remember that requirement elicitation is an iterative process. Feel free to show the document to the customer BEFORE the grading session, get feedback, and revise the document accordingly. If the customer is happy with the document BEFORE the grading session, everyone will be happy AFTER the grading session.)

Points: 200

Phase 3; due date: Feb. 22.

Goal: To setup the software and hardware infrastructure needed for project.
Procedure: You need to install Hudson on your hardware that can be viewed over the Internet. Configure Hudson so that it gets the latest GUITAR code, builds it so that all 6 tools (used in Phase 1) can be executed. Run the 4 JFC apps on the default aut. Instrument the aut first so that you can get a code coverage report. Automate the entire process so that it builds nightly.
Deliverables: The fully automated Hudson process viewable from the Internet.
Additional reading(s):  http://hudson-ci.org/

Grading session: During the grading session, you will demo the Hudson process, show the build process, and show logs of several days of successful execution.

Points: 400

Phase 4; due date: Mar. 1.

Goal: To prepare an "implementation plan", "evaluation plan", and "risk management plan" for the project.
Procedure: The project will use an incremental process to implement the customer's requirements. Divide the customer's requirements into 4 parts. You will deliver the implementation of Part 1 first, followed by Part 2, and so on. Come up with a schedule to deliver these parts (use the delivery dates from phases 5--8 below). Remember that the customer's original requirements may have changed (or may change in the future). Describe how the customer will evaluate each part in an evaluation plan. 

Come up with a risk management plan. Remember that:

Risk management is the identification, assessment, and prioritization of risks (defined in ISO 31000 as the effect of uncertainty on objectives, whether positive or negative) followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events[1] or to maximize the realization of opportunities. Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit risk, accidents, natural causes and disasters as well as deliberate attacks from an adversary.

Discuss how you will manage these risks:

The strategies to manage risk include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk.

By Feb. 22, get your instructor's approval on all these plans. Finally, discuss, with the customer, these documents, schedule of activities, and get his/her approval.

Deliverables: A document outlining the implementation plan with concrete deliverables for each of the 4 parts; the evaluation plan; and the risk management plan.
Additional reading(s): 

Grading session: Your document will be given to the customer. During the grading session, your team will meet with the course instructor and the customer. We will all examine the clarity and adequacy of the document. (Feel free to show the document to the customer BEFORE the grading session, get feedback, and revise the document accordingly. If the customer is happy with the document BEFORE the grading session, everyone will be happy AFTER the grading session.)

Points: 600

Phases 5--8; due dates: Mar. 15; Mar. 30; Apr. 15; Apr. 30.

Goal: To take delivery of each part described in the Phase 4 document.
Procedure: Implement the requirements, develop test cases, and documents.
Deliverables: The code, test cases, documentation for each part. The documentation should be on a wiki in the GUITAR sourceforge space. The test cases should be executed by Hudson every night on the code.
Additional reading(s): 

Grading session: During the grading session, you will demo each part with the customer and instructor. The implementation plan of Phase 4 will be used as a contract.

Points: 300 for each part.

Phase 9; due date: May 5.

Goal: Final deliverables, documents, and presentation.
Procedure: Each team will present (25 mins.)  its complete project in class, either on May 5 or 10. This will be a professional presentation where the team will walk the customer through all the features listed in the original contract. All these features will be listed in the wiki, which will be used as a guide for this presentation. You can use additional slides if needed. The team will talk about how a developer might extend the product and show the relevant wiki pages. The team will show the Hudson/Jenkins server (the one we have installed for this purpose), the test cases, failure reports, code coverage, etc. The code should be pulled from the GUITAR sourceforge site. 
Deliverables: Software code, wiki, Jenkins jobs and reports.

Grading session: Points will be assigned during the presentation.

Points: 400 for presentation quality, 400 for product, and 400 for completeness and robustness of Jenkins jobs, and 400 for wiki. Total 1600 points.

Back to Top

Copyright: Dept. of Computer Science, University of Maryland.
For problems or questions regarding this web, contact Atif M. Memon.
Last updated: April 21, 2011.