Last updated: April 21, 2008

Development Plan

Background

CS 481 is a course that gives you the opportunity to practice what you learned in CS 383, CS 384 and possibly your technical electives as you develop a large software application for a real world customer.  The major difference between CS 481 and other courses you've taken in Computer Science is that in the course MUST work in a group.  Virtually all significant (i.e. large) software development requires a concentrated team effort.  In addition your project is rarely a completely independent development with no dependencies on existing systems or previously developed code.  This class is an introduction to the trials and tribulations of working with your peers in a production environment.

In commercial (industrial) software development there are two primary methods of software development – serial and incremental.  Serial (often called Waterfall) progresses sequentially through a series of life cycle stages such as specification, design, coding, testing, and installation.  Each stage is completed before going on to the next stage and little iteration takes place between activities in different stages.  At times the serial approach seems like an exercise in document preparation rather than a concerted effort addressed at producing a product.  Serial development works best when the project is relatively small and isolated from other systems, can be well defined in advance, and few changes are likely to occur once definition is completed.

There’s an inherent risk in serial development.  In serial development, if the initial specification and design are incorrect then there is little that the developer(s) can do at the end of the project to match the customer’s expectation.  Incremental development addresses this risk by breaking a large project up into a series of smaller projects that build incrementally on each other.  Incremental developments have multiple cycles through the specification, design, testing, and installation (release) activities before the project is completed.  If an early release of a partial capability product determines that some misunderstanding exists regarding what the product is supposed to do, then there is still time to make adjustments to get back on track.  Documentation will be developed incrementally as well.  Incremental development helps reduce project risk.

Team Projects

The team projects may be new systems or expansions / enhancements of existing products.  All project will be conducted with real customers from government, industry, or University of Idaho faculty.  This serves three purposes:

Teams are assembled and projects identified in the first class session, the project kick-off meeting.  Your course instructor will make the team and project assignments. There will be no conventional lectures after the first week of classes.

Meetings

After the project kick-off meeting, your team will meet with your instructor once a week at a mutually agreeable time.  Your team needs to be meeting at other times as well to plan and perform a variety of project activities.  If your team is not meeting at least twice a week in addition to your instructor meeting, you will most probably fall behind.  You will meet with your customer many times during the semester but on a strictly scheduled basis.  Some of these will be face-to-face and some may be via teleconferencing.

Instructor’s Role

It is not your instructor’s job to mange your software project for you.  Your instructor’s  job is to create an appropriate, but realistic atmosphere in which you learn to work as a group in order to build quality software.  Your instructor will provide development process and project management guidance where and when appropriate.

Evaluation

Evaluation of worker performance is a difficult and often subjective task for project managers.  Grading in a team project course presents similar challenges.  Final grades will be determined using all of the following sources of information:  level of accomplishment against project requirements, quality of team deliverables,  teamwork,  individual and team dedication and initiative, technical competency, meeting commitments (schedule), peer evaluations, customer evaluation, and instructor evaluation.

Development Processes

The following is a summary of the software development process to be used by CS 481 design teams.

The Incremental Development Life Cycle Model

Teams are required to use an Incremental Development method.  It is based on a phased delivery approach complemented by application of Boehm’s Spiral project management strategy.  This method might also be classified as an Iterative or Evolutionary Life Cycle model with an emphasis on rapid delivery of functionality to the customer. This model is considered to be appropriate since the project requirements are initially loosely specified.  Further, a user interface, possibly graphical, may need to be generated and prototyping offers the best means of ensuring that the Customer's expectations will be met. The Incremental Development Life Cycle is based on four major phases consisting of a Planning and Analysis Phase, a Specification and Implementation Phase, a Testing and Review Phase, and an Evaluation Phase. These phases are subdivided into key activities each of which generates a "product" of some type. These products are often used by subsequent activities / phases. Even though dependencies exist, these activities, and even the phases, should be examined for potential concurrency.

Each cycle will require re-visiting each of the key activities. Details of the four phases and their associated activities are as follows:

The use of the above model, with the associated activities, provides the teams with a defined process that enables them to rapidly clarify customer requirements. Once this is accomplished a fully operational product will be constructed which can be shown to match the requirements. Configuration Management and controlled builds are maintained by employing CVS and make files throughout the development process.

Milestones

Key events, or milestones, during the course of product development are discussed briefly below. These events include the Initial Customer Meeting (principally a question and answer period), Solution / Approach Prototype (presentation of the proposed solution approach supported by operational or non- operational prototypes).  Incremental Release 1 Demonstration (the first delivery of a subset of operation features), Incremental Release 2 Demonstration, Incremental Release 3 Demonstration (delivery of a functionally complete product ), Beta Release, Semester End Project Presentation and Final Release of the total software product containing defect fixes for problems discovered during Beta Testing.

Initial Customer Meeting

This will be a meeting held jointly between the project team and the customer to discuss the scope of the project.  Based on this meeting the team is expected to have sufficient understanding of the customer’s needs and requirements that the team can develop a proposed solution approach as well as present the customer with a documented set of requirements for review, modification, and approval.

Solution / Approach / Concept Proposal

This is the first major event for the team requiring significant teamwork and preparation. The intent of this meeting is to provide an opportunity for clarification of the task in a face-to-face meeting with the customer. During week two of the development process the teams will meet with the customer in a meeting that lasts approximately one hour.  While the team receive and elaborates on a written statement of the requirements during week one of the development process, this meeting offers the opportunity to clarify requirements, limitations, and constraints.  This is accomplished by presenting an initial solution concept proposal that focuses on what the system does and the way the user will interact with it.  The benefit is to gain direct and immediate feedback from the customer ensuring that the team is working in the right direction.   One of the major objectives is to demonstrate to the customer that the team understands the customer’s need and has proposed an acceptable approach to its resolution.

Incremental Releases and Demonstrations

During subsequent weeks the team again has an opportunity to meet face-to-face with the customer.  By now a functional release should have been developed and will be demonstrated. This release will contain a subset of the features selected to provide a foundation for the continued evolution of the product.  The release must contain functionality that is meaningful to the customer and for which meaningful feedback can be given relative to the project’s objectives.

Early solicitation of feedback from an "interim release" increases the likelihood of a successful delivery of the complete product at semester’s end. The intent of the initial release is to try to resolve all requirements issues, such that the remaining implementation work can be performed in a straight forward manner.

The customer will also take advantage of this opportunity to review the product documentation. This gives the customer confidence that a defined development process is in place and is being followed.

It is essential that the teams come away from each Release Demonstration with a firm, clear understanding of the Customer's wants and needs.  A fully functional version is developed for the Beta Release.  Regression testing is used throughout to show that the release is sound.  All known defects must be resolved by the final release.

The Testing Process

A solid testing activity greatly contributes to customer confidence in the delivered product, not just the final product, but the incremental releases as well. This activity should include the development of test plans, application of a variety of test design strategies, an automated, regression test harness, an ever expanding test set, and a defect tracking methodology.

Test Development and Regression Testing

As the development process proceeds, functionality is added to the software as new requirements are identified and clarified. Tests should then be developed to ensure that each new piece of functionality correctly implements the corresponding requirement(s). In this way, the test set is developed in parallel with the code and grows as the code grows. A test-harness should be developed to enable the teams to run the entire test set against each new build and automatically compare the results with previous builds to ensure that no new defects were created when functionality is added and when defects are corrected.  Completion of all the testing identified in the test plan is expected prior to each release.

Defect Tracking

Throughout the development process a Defect Log is maintained by the team. Defects are deviations of the system’s actual behavior from its desired behavior.  When you develop software systems defects are introduced.  So we expect to have defects and our testing process should find them.  However, to ensure that we will be able to fix defects we need to document them.  When tracking defects following information is recorded and maintained:

Defect metrics will be tabulated on a regular basis. The total number of defects found and the total number of defects fixed will be graphed on a weekly basis. The defects fixed should eventually reach closure with the defects found. This is an important factor in inspiring customer confidence in the product: that it can be used with a low probability of failure.

Beta Testing

During the last few weeks prior to delivery, beta tests are conducted by the customer.  In parallel with the customer’s efforts the project team continues to develop and execute new tests. During week 10 (approximately) the teams develop a plan for Beta testing and notifies the customers when the Beta release is expected to occur.  The product is released for Beta Testing during week 12 and by week 14 all Beta testers should have responded with information on what has been done and what has been found.  New defects discovered during this activity must be quickly resolved so that the product may be finalized for delivery.

Because Beta Testing is a multi-step activity (planning, executing, analyzing feedback, and making changes) a significant amount of time will be required.  It is imperative that the duration of this activity be recognized and accounted for in the planning phase (scheduling activity).

Another important factor in inspiring customer confidence is the thoroughness with which the team tests the product prior to commencement of the beta testing activity. Beta testing should be conducted well in advance of the final delivery.

The plan for Beta Testing is developed with the intent of exposing the software to a wide variety of environments. Beta testers are selected specifically to ensure that the software will be compiled and run on a variety of different machines and with a variety of compilers / interpreters (as appropriate). When preparing the Beta product, the experience level of the testers should be assumed to be rudimentary, though testers with a wide range of experience levels should be solicited as testers.

Again, because beta testing is a multi-phase activity (planning, executing, analyzing feedback, and making changes) a significant amount of time will be required. It is imperative that the duration of this activity be recognized and accounted for in the planning phase (scheduling activity).

Regression testing, defect tracking, and a solid alpha / beta test plan all contribute to a product's successful completion. If any of these elements are omitted, customer confidence in the delivered product will be greatly reduced and the likelihood of defects discovered by users, after delivery, will increase.

Because of the complexity and duration of the total testing process, it is important to allocate sufficient resources to this activity; therefore, planning for, monitoring and controlling this activity is a critical project management task.

Final Project Presentation & Product Delivery

During week 16 the final meeting with the customer is held.  The team will make a formal presentation of the project followed by a demonstration of the product which concentrates on showing that any problems or issues discovered during the project have been adequately addressed.

The formal presentation will normally include information on the customer’s need / objective, highlights of the requirements, overview of the product design, review of risk items and their resolution, review of defect status and resolution, summary of effort expended and schedule accomplishment, defect find / fix graph, and recommendations for further product development.

Two hours will generally be allocated.  The focus of the demonstration will be on changes made during the latter weeks of development since the customer will have also had the opportunity to be involved in the beta testing completed earlier.  He or she will be aware of the product's near-final capabilities.  The final product demonstration keys on showing that the defects discovered during beta testing have been resolved. The product documentation is reviewed, and the product is accepted / rejected by the customer.

Project Management

Team Values & Project Vision

To have a successful design experience it is important for team members to have a dialog and reach consensus on team values – important attitude and behavioral norms that each team member is expected to meet.  A project vision is a statement about what you want to accomplish during the semester, or in other words, what does success look like.  One of your first team activities will be to establish a set of team values and a project vision to guide you through the semester.

Documented Process

A well defined process is important to assure that a product under construction is built with an acceptable level of quality.  Without process controls the product quality is dependent upon random incidents and behaviors – which are unlikely to lead to acceptable quality.  By controlling software processes, we can control the quality of the software being constructed.  Controlling a process requires process definition and process measurement.  This is especially important when working in a group.  The process for the most significant processes are documented on the course web site. 

Scheduling

The best way to control a software project is to identify the work you must do, schedule it, assign it, and then make sure that progress adheres to the schedule.  The schedule can be modified as necessary when encountering bad estimates and unforeseen problems.  Project schedules should contain a timeline with a list of objectives, milestones, and deliverables.  The project milestone schedule list the major events during the semester.  The project task list identifies individual-level activities that must be accomplished in order to successfully complete a milestone.

Project Measurement (Metrics)

You will be expected to capture numerical information individually and for the project that helps to indicate the status of your project.  This will include such things as number of defects found, number of open defects, hours worked, number of test cases, number of test cases executing successfully, amount of code developed, etc.

Project Leader

In industrial software development each project will have a designated leader – a manager or engineer vested with the responsibility and authority to make the project successful.  In our class, however, we will use a rotating leader so that each of you has an opportunity to lead the project for part of the semester.  The project leader has four important duties: (1) scheduling the meetings and events during his/her term, (2) recording progress and problems encountered. (3) making decisions when consensus cannot be reached, and (4) serving as liaison to the customer.  In this latter capacity it is important for the customer to have precisely one contact point to the team and to know who that contract is as well as how to reach him/her.  If more than one contact is involved, the potential of conflicting information, goals, and direction increases.

Project Meetings

Perhaps the best technique for maintaining your project schedule is to have weekly project meetings.  Giving a weekly verbal status report to your instructor will be required.  These meetings will be scheduled at mutually agreeable times and will be attend by all team members and the instructor.  Distribute an agenda listing topics to be discussed prior to each meeting. The customer will not attend. 

Several customer meetings will be held during the semester.  These need to be scheduled in advance.   Formal meetings will include a presentation of the initial project approach, demonstration of incremental releases of the product (most likely three), and a meeting and demonstration to support final product delivery.  You will use a checklist to verify readiness.  Prior to each meeting prepare an agenda and distribute it to your customer.  Some of the teams may have meetings with their customer using video or telephone conferencing facilities.

Project teams are encourage to schedule frequent meetings where they discuss and collaborate on project work.

Customer Presentations and Demonstrations

At several points during the semester associated with interim releases and the final release, you will be required to make a formal presentation to your customer.  You will also be asked to demonstrate your product’s current version.  The product version demonstrated must be a fully tested and functioning system that delivers useful capabilities to the customer.

Configuration Management & Change Control 

Multiple programmers working on the same set of documents and code can have problems unless the access to the files is controlled.  The CVS version control or revision control system safeguards your code, data, and documents so that nobody stomps on anybody else’s changes, and allows you to roll back your files to any previous versions. 

Large code systems should have multiple files which constitute multiple independent compilation units, some of which may have parameters controlling how they are built.  Controlling when and how these compilable units get made is a function of a configuration management tool.  Unix scripts and the “make” facility are primitive configuration management tools which allow you to build only the portion of code that needs to be built at any given time.  When used in conjunction with CVS these tools form a configuration management system.  Other tools may be used if more appropriate for a specific development environment.

Note that only “frozen” versions of code must be used for releases and customer demos.  A freeze should take place several days before the demo and no changes are to be made just prior to the demo.

Formal Test Plans

Testing a large, complicated code system well is exponentially harder than testing a piece of code that can be constructed by a single person.  This increased complexity can be managed by adopting a formal test plan, developing and managing test suites, using automated means of executing and evaluating tests, and applying techniques for defect recording and tracking.

Defect Recording and Tracking

Unfortunately, we don’t have any sophisticated tools for defect reporting and tracking.  Using a text file within CVS is a possibility, as is logging everything into a simple data base or spreadsheet.  Regardless of how it’s done, every defect needs to be recorded and either resolved or identified for future work.  Defects should not persist from demo to demo – they should be fixed or discussed.

Documentation of discovered defects (functional failures) should begin when a unit of code is made public.  Public status is indicated when an individual developer makes the unit available for other to use or releases the code for inclusion in a system build.  Problems discovered during the initial coding of a unit do not have to be formally documented, although it’s a good idea to keep records to ensure that problems you discover are corrected before the code is made public.

Coding Style

When working in a group it is important to be able to read and understand each others code.  The quickest way to facilitate code comprehension is to define, adopt and use coding standards or guidelines.  The actual format of the code is less important than the fact that everyone involved knows and uses the standard.  Decide on a coding style that you can all live with and then use it.  Check to see if your customer has an existing coding standard that he/she expect you to follow.  At a minimum, your code should be ANSI compliant with indentation to show nesting, meaningful variable names, function headers comments, function prototypes, functional block comments, etc.  File and function header comment blocks should always include the 5 W’s:  Who, What, When, Where, and Why.

Documentation Style

It is also important to have consistent documentation.  All parts of your documentation should be written in the same style and format.  Every document in the set should have a cover page and table of contents.  The cover page should identify the document title, authors, version, and publication date.  Although you will be producing many independent documents they should look like a cohesive set.   Product definitions and usage documents should be written in a style and language appropriate for the knowledge and skill levels of the customer and product users.

Project Web Site

Each team is to establish a web site for their project.  Technical documents, meeting agendas and minutes, code, product releases, team member contact information, etc. are to be posted to the web site.