# Agile Stage-Gate Approach for Design, Integration, and Testing of a 1U CubeSat
## 2 Materials and Methods
### Integration and Testing Flow and Procedure  
NASA's Launch Services Program features payloads with different launch providers. Each launch is named an ELaNa mission (Educational Launch of Nanosatellites) and is assigned a number. Since launch vehicle capabilities commonly exceed customer requirements, there is often space to fit a secondary payload. NASA's CubeSat Launch Initiative provides rides to CubeSats as a secondary payload to schools and non-profit organizations. These secondary payloads can either be released from the launch vehicle or deployed from the ISS. The ISS provides options for deploying nanosatellites. Usually, satellites are launched from below the station to avoid contact and potential risks. AztechSat-1 was sent as a secondary payload for a resupply mission to the International Space Station aboard a SpaceX Dragon capsule atop a Falcon 9 rocket.  
For a CubeSat as a secondary payload, the main purpose is to verify that the nanosatellite will not break apart or produce debris, which may damage the primary payload. After successfully completing the first two stages of the project (conceptualization and design), the team decided in a weekly sprint meeting to implement a system tool for satellite projects. After an iterative, recursive, and Agile process involving experts and members from the different teams, a testing and integration flow diagram was chosen as the best system tool [24].  
Figure 8 gives a general picture of the AztechSat-1 verification and validation diagram. In this diagram, it is possible to visualize the flow of the testing and integration process.  
At the beginning, both self-developed modules (payload) and COTS modules were tested at the university to guarantee their functionality. Secondly, integration was carried out at UPAEP, which was well documented. Thirdly, the integrated nanosatellite was sent to NASA's Ames Research Center where environmental tests were conducted in the following order: functional test, sine test, functional test, random test, functional test, post-sine test, functional test, centrifugal test, functional test, and thermal vacuum power management test. Lastly, one final functional test was conducted, and the satellite was sent to the launcher site.  
The integration and testing procedure started with the testing of each module separately using a FlatSat unit. Each board was mounted independently. After verification of successful performance, different modules were combined to probe communications until the full system was verified. The AztechSat-1 was then assembled, integrated, and tested based on a modified version of the 2-Model Philosophy by building a FlatSat/engineering model and a flight model [25]. The team also used a typical standard CubeSat build approach, which involved building a FlatSat, an engineering unit, and a flight model. The AztechSat-1 builds were registered as shown in Table 2. The differences between approaches involved building a FlatSat unit, an engineering unit, and two flight models to reduce failure.  
The AztechSat-1 project followed the building, testing, and repairing philosophy for critical components [26]. The procedure for integrating the AztechSat-1 nanosatellite aimed at guaranteeing the connections of the interfaces between the different components to ensure the correct operation of the subsystems at the general system level.