Lessons Learned from AIV in ESA’s Fly Your Satellite! Educational CubeSat Programme

‘Fly Your Satellite!’ (FYS) is a recurring hands-on programme conducted by the ESA (European Space Agency) Academy Unit of ESA’s Education Office. Fly Your Satellite! was established to support university student teams in the development of their own CubeSats by enabling a transfer of knowledge and experience from ESA specialists to students. Selected teams are guided through project reviews and supervised through design consolidation and verification activities, conducted according to ESA professional practice and to standards tailored to fit the scope of university CubeSat projects. This paper focuses on key lessons learned and issues identified during the ongoing verification activities of the CubeSats in the second cycle of FYS (FYS2), and on how that experience is used to the benefit of participants of future cycles, including the teams in the third cycle (FYS3), who are now in the late stages of their Critical Design Review. Special attention is given to the lessons learned during the manufacturing, assembly, integration and testing phases as experience shows that first-time developers tend to underestimate the number of issues which arise when the design is translated from documentation and models into physical hardware. The lessons learned are categorised into the topics of Development, AIV, Project Management, and Product Assurance. In the Development category, the lessons learns suggest attention should be focused on emphasizing the importance of development models and FlatSats for early testing, proactive development of aspects which don’t appear to be immediately critical or appear to be on the project’s critical path (such as software and test GSE), and anticipating the need for compatibility with a range of possible orbit scenarios. The Assembly, Integration, and Verification category contains a large variety of lessons learned from the preparation for AIV activities, anomalies encountered, and reflection on what was done well in the programme. These lessons cover topics such as dimensional requirement non-conformances, electromagnetic interferences, and recommendations for system level testing preparation. Lessons learned for the Project Management category mostly arise from the understandable lack of (space) project management experience of the student teams, and the discussion focuses on possible mitigation approaches that can be implemented. Specific topics covered include delayed project schedules, management of student resources, risk management, and experiences with legal and regulatory requirements. The lessons learned on Product Assurance stem primarily from the difficulties in applying standard methodologies to educational small spacecraft projects. Problems with configuration control, clean room practices, and anomaly investigation methods are discussed, with recommendations for how student teams could solve such issues, primarily through the creation of additional documentation to track modifications and processes implemented

Pitfalls and guide lines in the transition to object oriented software design methodologies

A research report submitted to the Faculty of Engineering, University of the Witwatersrand, Johannesburg, in partial fulfilment of the requirements for the degree of Master of Science in Engineering.Due to the dynamic nature of the software engineering industry there is a constant move towards new strategies for solving design problems. More specifically there is a move towards Object Oriented (OO) methodologies, presumably because of the various advantages offered in terms of maintainability, and reuse of code produced this way. As with various other aspects of the software industry there are however also problems encountered in this transition and lessons to be learned from the experience of companies who have already performed this change. This research report investigates possible guidelines for companies who are currently contemplating a change to the OO software design methodologies, by covering a collection of issues one should know about prior to this change. It also summarises the problems faced in the transition so far, the reasons for these problems and suggests possible solutions. Lastly it also investigates new trends in the OO arena. The emphasis is on South African companies and projects. The results obtained are compared with results obtained overseas to find out what the differences and similarities are. Areas of concern are also identified, where theoreticians' views have been ignored, and both South African and overeeas companies have not implemented any of the suggestions made.Andrew Chakane 201

Enhancing the Process of Testing Object -Oriented Systems.

Testing is a crucial step in the overall system development process. Using testing techniques that support features of the underlying software paradigm more effectively tests program than do testing techniques that support features of other paradigms. Systems developed with the object-oriented paradigm require techniques that support object-oriented features such as inheritance, data abstraction, encapsulation, and dynamic binding. Many techniques that are used to test systems developed with the structured paradigm are not sufficient for the testing of object-oriented systems. The goal of this research is to develop methods that will improve the process of testing object-oriented systems. Specifically, emphasis is given to improving the level of testing of methods because the level of method testing is generally considered inadequate. Algorithms are included that identify the set of methods, both interobject and intraobject, that should be tested for a given system. These algorithms are implemented as a part of an automated testing system that derives a framework for the testing of methods. This system includes the automatic generation of test drivers to facilitate the testing. It captures the results of tests for the purposes of reuse for future system maintenance. This framework provides the software engineer who is testing a system a mechanism to determine the level of method coverage that has been achieved in the testing process

Modelo de calidad para el software orientado a objetos

El software ha obtenido en la actualidad una gran importancia en todos los ámbitos de la vida cotidiana. Es indudable que la calidad del software juega un papel fundamental en todo desarrollo informático, aunque en ocasiones no se le presta la suficiente atención, quizás debido a los relativamente escasos trabajos relacionados con este tema desarrollados hasta la fecha. En el presente trabajo, se plantea la necesidad de un modelo de calidad completo. Para cubrir esta necesidad se presenta un nuevo modelo de calidad, obtenido tras un estudio pormenorizado de los modelos de calidad existentes, centrado en el paradigma orientado a objetos. Este modelo de calidad muestra cómo la calidad del software se descompone en una serie de factores y éstos, a su vez, se descomponen en un conjunto de criterios medibles utilizando medidas. El modelo incluye un amplio conjunto de medidas, diseñadas especialmente para su aplicación dentro del paradigma orientado a objetos. Para completar el modelo, se ha diseñado un sencillo método de aplicación de este modelo de calidad para que pueda ser utilizado de una forma simple por los desarrolladores de sistemas informáticos orientados a objetos. El modelo de calidad definido se ha validado realizando un juego de experimentos. Estos experimentos han consistido en la aplicación del modelo sobre una serie de desarrollos orientados a objetos. Los resultados obtenidos han demostrado su utilidad práctica para determinar tanto la calidad global de los sistemas, como para identificar aquellas partes del sistema susceptibles de ser mejoradas. Con este trabajo, se llena un importante hueco existente en esta área, pues, en primer lugar, no existen modelos de calidad completos para la orientación a objetos. En segundo lugar, aunque hay medidas para la orientación a objetos, no se han asociado a los atributos que determinan la calidad del software, por lo que su utilidad, tal cual fueron definidas, resulta bastante cuestionable. Para finalizar, nunca se ha asociado un modelo de calidad con una método de aplicación, por lo que su utilidad quedaba considerablemente mermada, quedando a expensas de la habilidad y experiencia del Ingeniero del Software que lo utilizara