CSC 492 Software Development Process

Back to Table of Contents


  1. Project File
    1. Project Problem Statement
    2. Project Progress Reports
    3. Final Project Reports
    4. Project Code
    5. Research Projects

In general, these problem-solving activities can be divided into the following categories:

  • Understanding the Problem Statement, and, necessarily, technologies that are useful in solving the problem,
  • Planning the Problem Solution in light of the leverage provided by these technologies and knowledge, experience and skills of the team,
  • Implementing the Problem Solution, including verification and validation of the solution,
  • Delivering the Problem Solution, including appropriate documentation.

In CSC 492, we use a formal software development process to expose you to typical software development process language and to give you an opportunity to build a software product in a professional environment. This process also enables monitoring by faculty and project sponsors by providing work elements and checkpoints that are evaluated and graded.

The objectives of using this process to develop new applications are to:

  • Provide a disciplined, logical, and business-oriented approach to project development that meets pertinent elements of ISO 9000,
  • Guide the creation of a detailed and auditable Project File,
  • Enhance teaming skills of project participants,
  • Enable project participants to refine their writing, presentation, and other communication skills.

Simply described, in CSC 492, each team must:

  1. Choose and follow a software development methodology,
  2. Plan and log activities appropriate to the chosen methodology,
  3. Provide written and oral progress reports,
  4. Deliver a final product.

Project File

Updates are made to the Project File throughout the semester. Each team has the responsibility to provide these updates in the form of project-related documentation as described below. Student teams use the online Senior Design Center (SDC) document submission system to submit drafts and final versions of each document as required. The final forms of each document are graded by instructors.

The contents of a Project File are as follows (details about each item are provided below):

Project Problem Statement

On the first day of class, you will be given a Project List that includes a problem statement for each project. Software projects in the SDC cover a wide range of application venues. Some involve a GUI, a database, and business logic as specified by the sponsor (i.e., a model-view-controller design pattern). Others ask for development of real-time or control software. Occasionally, projects are research or experimental in nature and require frequent prototyping and re-prototyping. Industrial projects come into the SDC after a meeting between the NCSU CSC industry partner (ePartners Program) and the SDC Director. When a project has been identified, it is assigned to a student team and a Project File is initiated. All projects start with a meeting between the team, sponsors, faculty mentor, and team coordinator.

You will be assigned to a team, and the team assigned to a project, based on the instructors’ best optimization of the overall requirements of the set of projects, your individual interests and qualifications (as specified in your project bid sheet) and, to some extent, random chance.

As soon as your team and project are assigned, it is important to choose a Team Leader and begin immediate discussions to clarify team-level understanding of the project and technologies involved. You can learn about your teammates, what strengths they may have and how your talents can best fit in. There may be something new to learn, e.g., the project might involve perl and you have not had experience in perl. For practical reasons there may be a delay of a week or so before a first meeting can be arranged with your sponsor. Some sponsors are out-of-town, faculty mentor’s schedule may delay a first meeting, etc., so it is important to use this time wisely. For example, schedule a team meeting with Ms. Heil — absent sponsors or faculty mentor. Get together with your team and debate and discuss various interpretations of the project or related alternative technologies. Ask someone on the faculty for advice about the projet. In general — start learning!

Project Progress Reports

The SDC staff will monitor the progress of your team’s project by reviewing Oral Progress Reports and Written Progress Reports. These reviews are used to ensure that the sponsor, owner, developer, and other people involved with the project are in agreement with the direction and progress of a project. The Progress Reports have the following purposes:

  • Evaluate the capabilities and limitations of the project against the current and future needs of the sponsor.
  • Ensure that the work products and plans for the project are in agreement with the requirements of the project.
  • Advise participants of the status and direction of the project.

Prior to Progress Reports, the team should review the work products for technical content. During this time, team members must affirm the following:

  • The work products are complete and fulfill the work commitments.
  • The work products, at the present stage of development, correctly address the functional, technical, financial, and security aspects of the business activity served by the project.
  • The plans are realistic and achievable, the planned work products and services will satisfy the objectives of the next project activity, and the persons involved understand and commit to the plans.
  • Deviations, such as the elimination of activities, merging of activities, and so forth, are documented and agreed to.
  • The project is meeting the schedule and quality objectives.

The Team Leader is responsible for establishing and monitoring review activities. The Team Leader must consider the findings and advice of all participants during the review process, must resolve differences of opinion (through negotiation, persuasion, and escalation as needed), and give explicit direction to the project.

The course calendar lists all progress reports, both written and oral. For details about Written Progress Reports 1-2 and Oral Progress Reports 1-3, see below.

Final Project Reports

The written final project report is expected to provide a description of the software system that was created and source code for project software developed during the semester. In CSC 492, this final report must be written in a “waterfall” format (see discussion below). By “waterfall” format we mean a document that clearly identifies the project problem statement, project requirements, design, testing, and delivery of the final product. It is important to note that, although the final report is expected to be in a waterfall format, the development methodology your team follows throughout the semester need not be strictly “waterfall.” A choice of a Plan-Driven or Agile methodology can be made, per team, after consultation with sponsors and the faculty mentor assigned to your project.

Waterfall Model. The Waterfall Model is a linear process with distinct phases that, once completed, are theoretically not revisited during the development life cycle (see Figure 1). During the Problem Statement & Feasibility Study phase, you will gain a better understanding of the problem. During the Requirements Definition phase, you will detail all requirements of the system. In the design phase, you will plan your system. Program code is written, implemented, and tested (Implementation & Testing) after planning (Design) is complete. After the code is fully tested, the final system is installed and delivered (Project Installation & Delivery).

waterfall model diagram

Figure 1. The Waterfall Software Development Model.

In addition to the written Final Project Report, your team will be expected to deliver a Final Oral Report to your sponsor, as listed on the course calendar. For details about the Final Written and Oral Reports, see below.

Project Code

As a part of the final project deliverable, it is the team’s responsibility to provide a machine-readable source tree, supporting files, test data and appropriate build instructions (more details will be provided at a later date).

Research Projects

If the major component of a team’s senior design experience involves research, the team will be expected to produce a final report that discusses the following:

  • Introduction (Who is involved? What are you doing? Why is it important?)
    • Sponsor Background
    • Problem Statement
    • Major Contributions of the work/Impact on the field
  • Background (where does this project fit into the scheme of things? What have others done?)
    • Related work (survey of the field)
    • Work done on this project by others
  • Methodology (so others can reproduce your results)
    • Process Flow /Design documents
    • Resources needed
    • Experimental set up (hardware/software)
    • Data Produced
    • If software is to be developed, include Requirements, Design, Implementation, Testing, User Guide, Developer Guide as/ where appropriate
  • Results and Discussion (What did you find?)
    • Show data produced
    • Describe/ explain the significance of the data
    • Explain any concrete results obtained
  • Conclusion
  • Sum up sections 1-4
  • Future Work
  • What will you do next?
  • How can others use the results of this paper?


Refer to: Dr. Laurie Williams, A (Partial) Introduction to Plan-Driven and Agile Software Engineering Practices & Methods, NCSU CSC326 Course Pack, 2004-2006 located in your team lab space.