Skip to content

Systems Development Life Cycle

Dubman25 edited this page Nov 11, 2014 · 3 revisions

Systems Development Life Cycle

System investigation

Community Feedback

We should provide a method or two for the community to provide feedback. This feedback should be rolled into system investigation activities like product development, feature prioritization and event schedules.

New Feature Selection

Potential new features should be presented for discussion as Enhancement Issues. The prioritization of work should reflect immediate short team goals and long term concerns. Once discussion is complete, the feature can be assigned for analysis.

  • New Feature Workflow
    • Open Issue discussing feature tagged as enhancement. This thread should be used to clarify the drivers and requirements behind the feature, the WHY.
    • Next we should prioritize the feature among the current backlog of items and make sure it fits into the delivery schedule, the WHEN.
    • Once the requirements are understood, the discussion should center around the description of the solution details, the WHAT.
    • After we know what we want to build, we should then select a technology or set of technologies to implement the feature, the HOW.
    • Lastly we should discuss the design and patterns to be used in the implementation, the WHERE.

System analysis

Milestones will be created that will contain documentation for what is envisioned as desired functionality that can reasonably be completed by the date of the milestone.

Design

The goals laid out by the milestone should be broken down into issues. High level design ideas should be communicated to the group for review.

Environments

Project contributors may work directly out of the master branch for smaller changes needed for the upcoming milestone. Larger changes or changes made by a user who is not a designated contributor should be made in a branch off of master. Once the changes in the branch off master are complete with the latest master changes merged in the developer should create a pull request. At least one contributor who is not the developer making the changes should review the pull request before accepting it into the master branch.

Testing

Training and transition

Operations and maintenance

Evaluation