178
edits
Changes
no edit summary
“Space does not give you a second chance!” <br>
::-Manvi Dhawan, Project Manager at the time of Pratham launch
Achieving the reliability and the robustness of a satellite is a significant challenge. This is where having a robust set of quality assurance practices comes into play. Quality Assurance (QA) quite simply put - are a set of practices followed to maintain the quality of a system.
<br>
Unlike the other subsystems of a student satellite, the task of enforcing quality assurance practices across all aspects of a system should not be supervised by a single subsystem or a group of people. Although organisations and space agencies across the globe have dedicated teams of people that deal solely with quality assurance practices for their respective missions, when it comes to a student team, however, such a setup would not be recommended. The reasons for which are enumerated below:
<br>
This [[ Concept Phase |concept phase]] deals with coming up with the concept for the system. The design begins with understanding the need behind the design, understanding the set objectives and coming up with our expectations of the final product or prototype. The team would have to list down the requirements of the system and various subsystems. When doing so, an example of QA being followed in the requirement writing process would be to have all of the system’s requirements documented comprehensively. ID’s should be systematically assigned to these requirements so as to be able to trace the origin of a particular requirement, as well the entity on which it is being placed. The subsystems tasked with ensuring a given requirement is met also need to be explicitly defined in the requirement list in addition to having a precise definition of the requirement itself.
<br>
The possible methodologies to track and/or achieve the requirements should be also identified and documented. In case a [[ Concept Phase #Non-Conformance of Requirement |non-conformance]] meeting needs to occur, the reason why the requirement was not met needs to be documented exhaustively, as well as the final decisions and the outcome of the meet. In such a scenario, having systematic requirement IDs would help in tracking all of the inter-dependent requirements that are affected.
==Development Phase==
The [[ Development Phase |development phase]] deals with coming up with detailed concepts for realising the system.
When coming up with the design of a subsystem, QA plays an extremely important role. The phase involves making multiple decisions based on trade-offs.
<br>
Over the course of years, the reason for any such decision can get lost. This is where documentation in the form of regular updates, minutes of review meetings and [[ Concept Phase |design review documents]] come into play.
<br>
An exhaustive list of all the interfaces of the system, along with the details regarding the exact nature of the interface need to be noted systematically and categorised with IDs in the [[ Development Phase #Integration Plan |Interface Control Document]] (ICD) which would be reviewed by the concerned members. All of these practices in addition to maintaining the quality of the system, also help in passing down the knowledge gained by the team to future members ensuring that time is not wasted re-learning what was already known to the team members at one point.
<br>
Another effective method of relaying such information is through concise Skill Development Modules, which compile all the resources to learn a particular skill in one place, and can be completed within a fixed period of time, after which proficiency can be tested through a test at the end of the module.
* A centralized repository consisting of all of the codes, and templates of documents/files to be created for the entire team.
* PCBs to be thoroughly checked and documented before and after fabrication by the Electrical and Communication subsystem
----
If you are done reading this page, you can go back to [[Starting a Student Satellite Project]].