## 1 Introduction
### How Does It Look from the Process Side? So we learned the technical challenges of the software source code development. The other major side of the problem lies in the way software development is planned and carried out--this involves addressing the software development lifecycle (SDLC) and general project management model. The common project and thus software development lifecycle for the space projects is still the \"waterfall\" one. The \"waterfall model\" is a linear-sequential life cycle model and was the first process model to be introduced and shown in Figure 2. It is very simple to understand and use. It is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. Typical major stages of the waterfall model are:  
* \"Requirements analysis and specification phase\": the phase when a project team gathers together and elicits and writes down all applicable project requirements. This phase usually ends when all project team members and a customer or a client agree that all requirements are final and fully defined. After this phase, it is assumed that requirements never change and are ready for design and implementation;
* \"Design phase\": the phase where the engineering team designs parts of the project having the requirements compiled in a previous stage. Normally, such a phase delivers two documents: a software design document (SDD) and a hardware design document (HDD). If some of the requirements cannot be fulfilled by the design, the design phase is considered as \"non-feasible\" and the project returns to the previous phase: \"requirements\";
* \"Implementation (and unit-testing) phase\": the main phase where the development team associated with the project gets the software/hardware done. If something from the design cannot be implemented in unit-tested, the phase is considered as unfinished and the project shall return to the previous phase for either design or requirements elaboration;
* \"Integration and system testing phase\": the phase where all parts of the project are put together for the system-level testing. This is where the majority of problems appear because of either design and/or implementation errors or non-foreseen conflicts. Normally, this phase is the most heavy one and, in fact, is the most eye-opening for all project members due to integration \"surprises\";
* \"Operation and maintenance phase\": the phase where the developed software and/or overall system delivers its designed value to the customer. This phase normally consists of adding further new functions to the software, fixing found during the operation bugs, and adopting the developed software to the changing product environment. The waterfall model is a heritage of 1950s engineering and is bounded to standards like MIL-STD-499 [26], MIL-STD-1521 [27], and IEEE-15288 [28]. It is rather clear from NASA's \"CubeSat 101 Handbook\" [13] that the recommended approach to the development of a CubeSat software is purely sequential and thus is of a \"waterfall\" life-cycle too. It is mainly driven by two common facts: industry practice and heritage and the fact of having and actually constructing the hardware in a CubeSat project. These are the factors that lead the entire project to be within the \"waterfall\" development life-cycle. What does it consist of? The problem that is created by the waterfall development process is not only in its method of structuring the pipeline of the tasks but also in the the way the source code design, development, testing, and structuring are carried out. After conducting an analysis of the existing CubeSat projects available on GitHub, it became clear that the structure of the source code is weak and often primitive. Even regarding the projects where the code  
Figure 2: Typical outline of the waterfall development model. structure is executed in a modular manner, it is still made as a monolithic, tightly bounded, data/code coupled piece of software.