I am finally starting the app based of the existing Quality Management System (QMS). This post will log what feels unnatural or needs to change as I tried to implement the QMS with in my game.
Note: This post is not complete, it will be updated as I work through this project. However, since I am starting the walkthrough of the QMS, this is the right chronological position for this post.
Each section will document the findings observations that I make while trying to use it. If something is titled “QMS” it means that it applies to the whole QMS. If something has a document mnemonic in is specific to that document and it will be fixed as I find it. Anything that I am choosing to fix later, I am tagging it with “TODO”
Let’s get started…
Project Charter
QMS: It feels I need a Memo to explain that I am pushing through trying to find holes in the project and the QMS
QMS TODO: I need a Doc numbering workflow. I am simple using the “SHP” mnemonic in front of the original QMS document. It will work for now, but adjusting it in the future may be a little cumbersome.
PC-901: Between the Scope, Executive Summary and Quality Objectives, the Objectives section seems like a duplicate information. Remove it.
PC-901: Move the Assumptions section from the SDD to here.
PC-901: Move the Target Customer from the SDD to here.
Requirements & Acceptance Test
Req-901: Need to add a Product and Version to the title.
Req-901: Change the “Requirements” to “Customer Requirements”
Req-901: Add a “System, Performance, Legal, or Regulatory” etc. requirements. section. Make sure we cover all of the other requirements needed to define system performance, etc.
QMS: Update the copyright notice on the templates. Copyright ® 2015 Greg Schallert
Software Design Document
SDD-901: Move Assumptions to the Project Charter
SDD-901: Make sure we have an “Other Design Requirements” section. This will allow the developers to document any additional requirements that are needed for the design but have not been stated by the customer.
QMS TODO: Since we added a requirements section to the SDD, we need to find a place to add the verification for them. This might be in the SDD, Project Map, Unit Tests, or Iteration Plan. I could also add a traceability matrix, but I’m going to wait to decide on this one until I get closer to completing the process so I can determine where this feels natural.
QMS TODO: Now that I am using git, I should create a git repository. – I expect I can do this with my cloud storage and not cause too much disruption.
SDP-902: The SDD seems a little out of place here. I was able to complete a fair amount of the background, but I think I really need the Project Map to be completed first. I am going to complete the Project Map, then come back
SDD-901: Add the Project Map (now called Project Plan) as a reference.
SDD-901: Add LibGDX as a dependency and adjust the the verification accordingly.
SDD-901: Move the Product details to the Project Charter
The Software Development Procedure. There needs to be some initial thought into the design to generate the Project Map, but the Project Map should be completed prior to the SDD being complete. We will make sure the SDP is clear that the first iteration may be something like an iteration 0 were much of the investigation and initial design allows for a Project Map to be put together. One additional item of note is that each time an iteration is completed, the Project Map, Requirements, and SDD may need to be adjusted. This is expected in an iterative development. Our goal is to take our best guess at what the next logical steps are and move forward quickly while continually asking the question “are we on the right track.”
(Additional comments after completing a draft)
SDD-901 TODO: The Design section towards the end needs instructions that say “Modify as Needed.” Some projects would be more logical if they followed a different format. Think MVC -vs- Procedural.
SDD-901 TODO: Consider changing this to a more free-form document with a git repository of the design and a readme then creating a more detailed Verification plan instead.
Project Map Plan
PM: Change the name from Project Map (PM) to Project Plan (PP). It will make more sense to a larger audience. From this point on in the post I will be calling it a Project Plan.
PP: Remove the Assumptions section as it is covered in the Project Charter
PP: Add sections to describe the Verification and Validation efforts
QMS TODO: Currently most of the changeable items in the templates as well as the instructions are highlighted yellow an in italics. A review of all of the documentation should make this easier to use. For example, in many cases editing an italics text creates an extra step of formatting the text back to normal. Current thoughts are all instructions that should be deleted are in italics and highlighted. Text that could stay in the document and simply be highlighted.
PP: Adjusted the timeline. Streamline the columns so that the Plan is always forward looking (see next comment).
PP TODO: Review the timeline based on first and second projects. The first plan has time for the QMS built into it. The second should be a more normal timeframe. Once this is understood, a default “Timeline” section should offer better guidance for future products than it does today.
QMS TODO: Need to add a Iteration Plan so that the Project Plan, etc. does not change. – Consider simply doing Iteration Plans on GitLab. This way there is no duplication of effort. I like the idea of GitLab maintaining a timeline (maybe just monitoring the backlog) so no additional documents are required.
Hazards and Risk Procedure
HA TODO: Audit the HA to determine what other QMS procedures should have a HA.
HA TODO: Add Definitions.
HA TODO: Revisit towards the end or the Dev Cycle
Hazards and Risk Template
QMS TODO: Create a standard Excel Chart “Document Template”
HAT TODO: Add instructions and a Summary page.
HAT TODO: Revisit towards the end or the Dev Cycle
Design and Development Procedure
DDP: This has been outlined. It is being written as each step of the process is being executed.
General
All Docs: Confirm Dates, Versions, Copyright and TOC are correct after all of the required edits.
QMS: Audit the DPP, and the SDP after Shapes! has been released.
Summary of Actions
Create the Project Charter
Agree on the Product Requirements
Dev does initial Design Brainstorming and comes up with the Acceptance Tests
Acceptance Tests are reviewed by the team.
(repeats until Req and Acpt Tests are approved)
Dev Team creates a GitLab project and determines approximate schedule.
– GitLab wiki is created.
Project Plan is drafted and reviewed (repeats until approved)
Dev ends any pilot projects
SDD is drafted by the Dev Team (not approved yet).
HA is drafted. Adjustments to the Req and SDD are made.
HA and SDD are approved.
V&V is adjusted based on the HA and SDD.