CSSE 497: Senior Project 1

CSSE 497: Senior Project 1
Rose-Hulman Institute of Technology
Computer Science and Software Engineering Department
Fall 2013

Introduction

Software projects are challenging efforts and as CSSE students prepare to enter the workforce, experience is needed. In the Junior Sequence of courses (CSSE 371/372/374/375) students gained experience with key aspects of software engineering as they completed a year-long junior project. Topics covered included:

Software requirements analysis & specification
Software project planning & management
Software architecture & design
Software construction & evolution
Forming and managing project teams
Software risk planning and management
Software configuration management
Software validation & verification

Senior projects follow a similar approach, but the students play a much more directive role in their projects by working with the clients to define the projects (typically 1400-1600 hours of effort for 4 team members). Rather than meeting in class, there are weekly meetings with the faculty advisors and the clients. The focus for the students is largely on the full development of a software system for a real-world client where the students define, plan, develop and deliver a usable product. CSSE 497 is the first of the three terms for this year-long project. Students are graded each term for their performance and participation on the teams, as well as using input from the clients.

Course Description

Group software engineering project requiring completion of a software system for an approved client. Tasks include project planning, risk analysis, use of standards, prototyping, configuration management, quality assurance, project reviews and reports, team management and organization, copyright, liability, and handling project failure.

Learning Outcomes

Upon successfully completing this series of senior project courses, a student should be able to.

Demonstrate effective Communication Skills
- Reading: read technical documents and offer constructive criticism of their content and style
- Writing: write several different types of technical documents
- Oral presentation: prepare and deliver technical material at the appropriate level of detail
Demonstrate effective Management Skills
- Leadership: lead a small software team (if team leader) or ability to support the leadership of the team (if not)
- Time management: estimate and monitor personal time across multiple tasks
- Meeting facilitation: lead and participate in small groups in constructive meetings
- Estimating: estimate effort required to complete technical tasks
- Risk: assess project risks and plan mitigation strategies
- Planning: prepare a feasible plan for the accomplishment of several technical tasks
- Monitoring: track the progress of several tasks according to a plan
Apply Technical Skills on a real-world problem.
- Analysis: analyze technical requirements and proposals for feasibility and to model the consequences of proposed solutions
- Design: construct appropriate abstractions of problems and solutions
- Coding: produce and inspect implementations of software according to project standards
- Testing: prepare test plans and to participate in both unit-level and system-level testing activities
Demonstrate key areas of Professionalism
- Ethics: identify and prevent unethical professional behavior
- Intellectual property issues: make appropriate professional judgments regarding choice of methods for protecting intellectual property
- Social issues: evaluate and avoid possible negative social aspects of a software product
- Relationships with clients: interact with clients in a professional manner
- Teamwork: working collaboratively with the team to deliver the project and accomplish other project goals.

Prerequisites

CSSE 371. (Software development and/or maintenance experience, and an ability write and communicate effectively will make this course more meaningful.)

Textbooks

Readings may also be assigned from relevant papers (e.g., case studies).

Course Evaluation and Feedback

Please feel free to provide feedback about the course at any time. If you feel uncomfortable talking with me directly, there is an anonymous feedback box under the Moodle account for this course where you can provide feedback throughout the term; I check it regularly and will try respond to feedback in a reasonable time. There will also be two anonymous plus-delta evaluations of the course where you can offer suggestions on how to improve the course and its delivery.

Grading

Grading for senior project needs to be somewhat flexible. It is difficult to assign percentages to individual deliverables as some teams may be given some of the deliverables by the client. As such I will focus on the following items. I will attempt to give you regular feedback on your performance and will be happy to grade deliverables as them become available.

Quality and completeness of project deliverables, as judged by the contents of the repositories to which you give me access, documents you make available to me and the client feedback (70%)
Effort you put into the project, as judged by the Engineering Journal and Peer evaluations (30%)

Expectations

Students will be expected to attend and participate in senior project related meetings. We will use the CSSE497 course website as well as your Rose email addresses to disseminate relevant information.

Assignments

Project assignments are somewhat different than our usual classes. Please provide access to your software project material/artifacts in your configuration managed repository to the instructor. Some assignments may be requested separately (e.g., a response to a case study). Unless otherwise instructed, please post these on Moodle in the associated drop boxes. While this course is demanding, it is also rewarding for those that want strong understanding of software engineering as a discipline.

Late Submissions

Please note that project assignments and deliverables will be due at the specified time on the specified day, in the format agreed upon with advisor. Late assignments and project deliverables will not be accepted (receiving a zero for grade).

Academic Integrity

CSSE Honesty Policy (see http://www.rose-hulman.edu/Class/cs/HTML/about/honesty.html) governs class and performance. Joint study is allowed (even encouraged) on some items as expressed by the instructor; however, each student must produce his or her solutions individually. Students must not collaborate on tests or homework that is passed in unless directed by the instructor.

Attendance Policy

Attendance of meetings is mandatory (unless with a legitimate excused absence). If you cannot make it to meeting, you are still responsible for all information covered in the meeting. Students who have more than 2 unexcused absences will receive a final course grade reduced by up to on full grade level; a student whose total absences (excused and unexcused) exceed 8 will fail this course.

Writing

Written communication is important in CSSE 497, as it is in the software profession in general. Remember that a software document has several unique and important characteristics:

Technical documents are often the result of group authorship, thus it requires planning and final tweaking.
Specificity and organization are more important than flow; hence technical documents are often ordered around lists and tables rather than paragraphs.
Documents are often the reader's only source of information on the particular subject or product; hence they must be thorough and complete.
Documents are often used to answer specific questions; hence, they should facilitate finding specific pieces of information (navigation).
Documentation must bridge from general specifications to particulars of implementation and operation, hence it must make abstract concepts concrete and make concrete facts fit generalized concepts.
Documentation can be presented in many forms: online via HTML, MS help files, just plain text, and on paper as reference manuals, tutorial, quick reference guides, etc. It is important to choose the correct medium and even more important to write to fit the medium.

You can always drop by your project advisor's office if you have any questions regarding your documents. I would be happy to look at it and suggest improvements. You should also be aware of the service provided by the Learning Center.

Professionalism

As would be expected in the workplace, you are asked to behave in a professional manner. This includes your appearance, such as your apparel, your hygiene, as well as potentially offensive computer desktops. We furthermore ask that you turn off your cell phones during meetings, let people finish their turn talking and do not be disruptive in other ways.

Mentoring Junior Project Teams

The Senior Project team may be assigned a Junior Project team to mentor and provide some review of their material. While this will not be a large part of your senior project effort, it is an important way to refine your understanding about software projects, techniques you have learned in the Software Engineering program, and interaction with project teams. Please take this seriously as the juniors depend on your advice and your participation will be part of your meetings grade.

Schedule of Course Deliverable

If you were to use the Waterfall model, the schedule below would work. The actual schedule will depend on your project plan.

Week	Deliverables
0	Assign team roles Schedule weekly meeting times with client and advisor
1	Introduction to Senior Projects presentations during 7th period on Wednesday Set up Engineering journal and Configuration management system First client meeting Agree, sign NDA and IPA forms, if necessary. Metrics Document Project Plan
2	Initial Problem Statement
3	Revised Problems Statement
4	Requirements Presentation, Wednesday during 7th, 8th, and 9th hours Preliminary Requirements Document
9	Demo Working Prototype
10	Initial Architecture Document Working prototype shown to client

Deliverables

The following are brief descriptions of the fall deliverables along with some relevant instructions and recommendations. These deliverables are a starting bid. If your team feels that any part does not apply to your project, please make your case.

Engineering Journal. Each team sets up an electronic log, documenting what each individual did, how long it took, decisions your team made, and how those were made. The idea is to keep adding to this daily and weekly. The instructor will be periodically looking at these (typically weekly). The log may take any form suitable to the team. In the past, teams set up blogs or used Google Docs.
Configuration Management.
- Similar to CSSE 376
- Use GIT / GITHUB unless some requirement drives something else
- Course instructor must have access rights
Problem Statement.
- Should have a problem statement agreed to by your client by midterm.
- Should be updated with changes at end of term.
- Normal format is for the problem statement to be about 2-3 pages, to include a short list of key features, quality attributes, and other pertinent info the client agrees to, like how the system relates to or replaces some existing system. The Function Form Economy Time model used in 333 would be a good template.
Project Plan.
- Similar to what you had in CSSE 372
- Description of your processes (e.g., pick a lifecycle, explain how you will use it, and why you expect it to be a good choice)
- Some initial estimates of tasks, and requisite resources
- Schedule: Who's doing what (coding, testing, etc.)
- Risks
  - Updated and added to (includes all risks)
  - ID and
  - Type (risk/opportunity)
  - Impact and Probability
  - Mitigation strategy with revisit date (for all risks)
  - Resources responsible
Metrics.
- Identify Product, Communication and Process metrics
- Track Product, Communication and Process Metrics
Overall completeness.
- Includes structure for subsequent quarters (we will provide our expectations ahead of time, toward this end)
- Uses good documentation standards
Requirements/Features Document. While your customer will probably dictate this, requirements will normally include detailed use cases and a supplementary specification, based on input from your client and from other sources. Occasionally, other pieces also are important. (E.g., if you talk to other systems, perhaps charts of those interactions.) If your customer deviates from this substantially, a meeting needs to be arranged for the Advisor, team, and client to agree upon the requisite requirements definition and management approach.
Requirements Presentation.
- What the project is about?
- The problem statement and requirements you have gathered and
- analyzed
- The process you've decided to use, and why that's right for this project
- Known project risks, and possible plans to deal with those
- Feature Listing and an exemplar of functional specification technique (use case, scenarios, etc)
- Current status
- Anything else of interest to other teams.
- Week 4: Wednesday 6th, 7th and 8th hours.
- 10 -15 Minutes per team.
Initial Architecture Document.
- This is a trial at a high-level architecture. It might be changed as you try to detail it bottom-up during development, as you investigate components, subsystems, and other low-level aspects of the design work. It should include at least:
  - An explanation of how why this design will solve the problem described in your problem statement
  - A high-level static view of the structures you expect to use, like the class diagrams you did in CSSE 374
  - A high-level dynamic view showing how the system will operate as software - like what major components communicate during the main operations.
  - A high-level "allocation" view showing how the running system will sit on hardware and what these boxes will exchange to make the whole system work
Prototype. You should select key aspects of your system to prototype. This should be based on reducing risk, showing that you can do some difficult part of the technical work. For example:
- A usability prototype, which tests whether humans can operate the system as desired.
- A functionality or reliability test for some part of the design.
Junior Project Mentorship. The Senior Project team will be expected to provide mentorship for a Junior Project team as part of their Senior Project responsibilities. This is to reinforce many of the concepts and techniques taught in your CSSE program. Basic expectations for this aspect of the senior project are:
- Establishing a dialogue with the assigned junior project team and being available for questions or advice as they proceed through their junior project deliverables.
- Reviewing at least one assignment (to be established by junior project instructor) and provide feedback to the junior project team.

Weekly Meetings

Each week, the project team will meet with both your client and project advisor. For each weekly meeting with the team's advisor, a meeting agenda must be sent in advance of the meeting.

Overall strategy

We recommend that each team develop a Vision document which is internal for the team's use. It describes conceptually what you plan to accomplish over the whole year.