Project Development Process

Our group handles new projects and enhancement requests to existing projects in the same manner. Enhancement requests are just mini-projects that tie in with the bigger picture, so it is important when dealing with those requests that they are evaluated with the good of the entire application in mind.

Step 1: New Project or Enhancement Request

Projects are submitted via OIT’s Help Ticket System (help.ncsu.edu). Important information is gathered from the client regarding the scope and requirements for the project, as well as primary contacts and stakeholders. This data helps with the next step:

Step 2: High Level Project Design

After requirements have been gathered from the client, the design team meets and does some high-level design. Possible data sources are examined, and technologies are evaluated to determine if they meet the goals of the project. These meetings run hand-in-hand with Step 3:

Step 3: Client Review

After the design team evaluates a project and its requirements, meetings are held with the client to get into more detail about the project and what additional requirements there are. The design team and the client work together to set goals for the project, which will later be used to determine the success of the project. After client reviews, the design team meets again, then goes back to the client, and so on until a solid plan with attainable goals is determined.

Step 4: Prototyping

During the process of doing Project Design and Client Review, prototyping is sometimes used for the client to help the planning process along. Prototypes should be used for nothing more than to get an idea about how a project may act and should not be used as production code.

Step 5: Implementation Meeting

Once a solid plan is in place and the client and design team is happy with the project, an implementation meeting is set that does low-level project design, including defining data models and code layout. A schedule with milestones is laid out at this stage.

Step 6: Release Deliverables

Each release will have certain deliverables that are associated with it. These deliverables are deteremined by the design team in coordination with the client. This step is crucial in keeping with the project timeline, as too many or too few deliverables mean that deadlines are not kept.

Step 7: Coding

This is where the magic happens

Step 8: Code Review

One of the most important and beneficial processes an application development team can go through is code reviews. Code reviews not only help developers find bugs within the software, but they ensure the overall style and design decisions stay consistent. Code reviews are done whenever a feature is added to the code base, before a commit is done.

Step 9: Commit

GitHub is currently used for version control. Commits are made whenever features are added to the codebase. Once a commit is made, the process is repeated by coding, code review, and commit. This is done until all deliverables of the release are met.

Step 10: Release Evaluation and Push Out

Once all goals for a release are met, an evaluation of the release and its goals are done by the design team. The success of our application is judged on the goals set forth earlier in the process by the client and the design team. Once the team is satisfied with the results, the revision is tagged in GitHub and the codebase is exported to wherever the application will run from. After a release is made, the process returns to Step 6 and continues until the final release is ready.

Step 11: Gold Master

When all releases have been successfully finished, the entire project is looked at and evaulated based on the goals set forth earlier in the project. The final revision is tagged as release-1.0.0 and exported to wherever the application will run from. At this point, we consider the project to be in maintenance mode.

Step 12: Maintenance Cycle

All our completed applications stay in the maintenance cycle until the group freezes the application or end-of-lifes it. The decisions to do this are the responsibility of the group in coordination with managmenet and the client. During maintenance mode, the client evaluates the product and submits bug reports. Applications are continually reviewed for security problems and addressed according to our policies and procedures. When any of these requests come into our system, they are evaluated based on the Bug Fixing Cycle.

Project Status Definitions

Each type of project goes this development process and are prioritized by our group.

During the lifecycle of an application, we use certain terms to describe the status the application is. It is important for us to continually evaluate the usefulness of an application, so the status of each application is updated at each prioritization meeting.

Proposed

This means that a project has been proposed, but has not been reviewed or accepted by our group. Projects can be proposed by submitting a request via the OIT Help system help.ncsu.edu.

Accepted

Our team has reviewed the proposal and has accepted that this is a project that we are going to work on. The schedule for when the work is done depends on our Priority Guidelines.

Declined

Our team has reviewed the proposal and decided it is not within our purview to take on the project.

Once a project is finished, it is classified as Active and will, over time move through the stages below:

  • Active – we are still adding features and actively coding on the product.

  • Maintenance – we are making bug fixes and security patches but no new features.

  • Depreciated – we no longer patch/update it but have not announced it is going away in sysnews.

  • Retired – we have turned off access to the depreciated system but it still exists on servers and in github (in some cases the github repo still exists for reference purposes)

  • Archived – we have copied the source code to a CD and removed all traces from the github repo.