Advanced
Effect of the Application of the CBD Output Management Technique for the Development of Operation Software for a Space Observation System
Effect of the Application of the CBD Output Management Technique for the Development of Operation Software for a Space Observation System
Journal of Astronomy and Space Sciences. 2014. Sep, 31(3): 265-276
Copyright © 2014, The Korean Space Science Society
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.
  • Received : June 06, 2014
  • Accepted : September 09, 2014
  • Published : September 15, 2014
Download
PDF
e-PUB
PubReader
PPT
Export by style
Share
Article
Author
Metrics
Cited by
TagCloud
About the Authors
Yoon Kyung Seo
Department of Computer Engineering, Chungnam National University, Daejeon 305-764, Korea
Dong Young Rew
Korea Aerospace Research Institute, Daejeon 305-333, Korea
Georg Kirchner
Space Research Institute of the Austrian Academy of Sciences, A-8042 Graz, Austria
Jakyoung Nah
Korea Astronomy and Space Science Institute, Daejeon 305-348, Korea
Bi-Ho Jang
Korea Astronomy and Space Science Institute, Daejeon 305-348, Korea
Jiwoong Heo
Selab Inc., Seoul 135-010, Korea
Cheong Youn
Department of Computer Engineering, Chungnam National University, Daejeon 305-764, Korea
cyoun@cnu.ac.kr
Abstract
The application of software engineering is not common in the development of astronomical observation system. While there were component-wise developments in the past, large-scale comprehensive system developments are more common in these days. In this study, current methodologies of development are reviewed to select a proper one for the development of astronomical observation system and the result of the application is presented. As the subject of this study, a project of operation software development for an astronomical observation system which runs on the ground is selected. And the output management technique based on Component Based Development which is one of the relatively recent methodologies has been applied. Since the nature of the system requires lots of arithmetic algorithms and it has great impact on the overall performance of the entire system, a prototype model is developed to verify major functions and performance. Consequently, it was possible to verify the compliance with the product requirements through the requirement tracing table and also it was possible to keep to the schedule. Besides, it was suggested that a few improvements could be possible based on the experience of the application of conventional output management technique. This study is the first application of the software development methodology in the domestic astronomical observation system area. The process and results of this study would contribute to the investigation for a more appropriate methodology in the area of similar system development.
Keywords
1. INTRODUCTION
Recently, the introduction of a software engineering has been attempted in the development of software in the areas of national defense, astronomy, and aviation. Advanced Defense Component Development Methodology (ADCDM) (Chung et al. 2006) and Magic and Robust Methodology Integrated-III 4.0 (Ham et al. 2004) can be used for these attempts. The ADCDM is Component Based Development (CBD) methodology developed by Agency for Defense Development (ADD) and the MRMI-III is developed by Electronics and Telecommunications Research Institute (ETRI). It is not common to apply the software engineering in the development of astronomical observation system field. While the aspect of development was small scale, it has been changed to the complex and large scale in recent years. Also, the cost of software development ranges from several tenths billion won to a few billion won and a package type software development is required in terms of the project period and the man-power demands. Due to series of similar system developments rather than a one-time development, the reusability of software are demanded to reduce the development period and the cost. These are the main reason why we consider the application of software engineering.
In this study, current methodologies of development are reviewed to determine the best one for the development of astronomical observation system through preliminary studies and the application results of this methodology is presented. Also, the current methodologies are reviewed to identify the improvements to be made to contribute to the application of a new methodology. For this study, the output management technique developed based on the CBD methodology which is one of the recent development methodologies was applied to the software development of the Satellite Laser Ranging (SLR) system (Jo et al. 2011, Park et al. 2012) which is an astronomical observation equipment of Korea Astronomy and Space Science Institute (KASI). At the stage of this task placement, the list of products are determined and according to this list, all the process of requirement analysis, design, implementation, test, and operation are interfaced. Since the nature of software to be developed requires lots of arithmetic algorithms and has great impact on the performance of the entire system, a prototype model (Youn 2009) is developed for the verification of major functions and performance. Also, the effect of this approach on the results of development is investigated through the requirement tracing table to verify the compliance of the requirements of the products according to the plan.
In consequence, the product requirements were satisfied and it was also possible to meet the schedule of software development. Most of all, the systematic development phase and the verification of the products according to the milestone enabled the reliable development. However, the difference in the progresses of interfaced sub-systems resulted in a delay in part of the software tests. This should be corrected in the subsequent application of current development methodology.
This study is the first application of the software development methodology in the domestic astronomical observation system area. The process and results of this study would contribute to the investigation for a more appropriate methodology in the area of similar system development. In Section 2 of this paper, preliminary studies on the comparison of current methodologies and the standards are described. In Section 3, the derivation of products and the prototype models are described focused on the implementation system. In Section 4, the applied techniques are evaluated and the issues are analyzed and in Section 5, the results are summarized and further study is proposed.
2. METHODOLOGY REVIEW
- 2. 1 Comparison of Current Studies and Review on the Standards
The software development methodologies or the processes are largely classified as frameworks of Objectoriented methodology, Component Based Development (CBD) methodology, and Product Line Engineering (Jo et al. 2007). Table 1 compares major features of fairly new methodologies of object-oriented methodology, CBD methodology, and Agile methodology (Rizwan Jameel Qureshi 2012) in order to determine the methodology for this study excluding conventional methodologies. The study results on the Agile methodology which has attracted attention of people recently, are summarized in Chung et al. (2014). The foreign or domestic standards have also been reviewed during the preparation stage for the successful development of the software. In Table 2 , the texts are divided into the categories of software project management plan, CBD standard products, software test based on the standards of preliminary study. In order to determine the software development life-cycle (Chae & Yoon 2007), literatures were reviewed and derived the conclusions ahead of the main development.
Comparative analysis of the features of representative software development methodology after 1990s.
PPT Slide
Lager Image
Comparative analysis of the features of representative software development methodology after 1990s.
Referenced specifications.
PPT Slide
Lager Image
Referenced specifications.
- 2.2 Selection of Methodology
According to the reviews of Section 2.1, the CBD methodology is selected for this study based on the following reasons. First, the total period of software development is 15 months which is never short. Thus, a systematic task management is enabled through the products applying the CBD methodology because of the long development time span in view of project management. Second, the reusability of software are taken into account since subsequent developments of same or similar systems have been planned. In other words, the development of a reusable component module has been attempted. The life cycle is determined as combined type of a waterfall and a prototyping model as shown in Fig. 1 . The repetitive and progressive processes which are the characteristics of an object-oriented development project are not adopted since the specific requirements considering these were prepared already and it is not easy to change the requirements due to complicated interfaces. Also, there are logics of arithmetic algorithm and which have an impact on the major functions and the performance elements, a prototype model is developed for the verification of these in order to reduce risks in advance. Development products based on the CBD methodology are decided according to the selected methodology. The development products are prepared from the standpoint of process and product. While the products are prepared to manage and control the processes during the development stage in order to ensure the quality of final products according to the process view, the products are prepared for the takeover and management of the products specifying the quality and component of the final products (TTA 2003b) according to the product view. The products are determined based on the product lists shown in “Standard Product Management Guides based on CBD SW Developments” (NIA 2011). This management guide is established as a standard, TTA (2013). Table 3 shows a comparison table between standard products suggested in the standard (TTA 2013) and applied products. Most of the products suggested in the guide are incorporated and part of products are renamed or excluded. The products are reviewed in milestone review meetings which is held for progress managements according to the level of each stage.
PPT Slide
Lager Image
The applied software life cycle for this development: the combined type of waterfall and prototyping model. Also, the relation with the milestone is shown.
Comparison with the standard (TTA 2013) for CBD Software outputs.
PPT Slide
Lager Image
Comparison with the standard (TTA 2013) for CBD Software outputs.
3. IMPLEMENTATION SYSTEM
The meaning of the application of a methodology in developing software is to set up consistent interfaces over the process of requirement analysis, design, implementation, test, operation, and maintenance (Jin et al. 2004). Thus, the methodology of this study is explained focusing on the activities for the derivation of products according to the life cycle flow of the implemented system. The application of prototype model is also explained in this flow.
- 3.1 Requirement Analysis and Design According to UML Implementation
According to Kundu et al. (2013), the conventional UML tool in a model-driven software environment generates structural codes automatically from UML class diagrams. That is, the modeling language is used to confirm the requirements and to analyze and design them to generate the codes automatically. The modeling tool used in the requirement analysis and the design process is Enterprise Architect (2014) 7.5 or 8.0 which is a product of SPARX SYSTEMS of United States. This tool is based on UML (Unified Modeling Language) 2.0 (OMG 2006) of Object Management Group (OMG 2014). The layer policy related to the software structure is decided as 3+1 layer based on the Rational Software policy of IBM (IBM 2009). UI (User Interface), Control, Integration, and Common layer comprise the policy. In this policy, the references among the component elements are handled when a request is made through a terminal or external system interfaces. Especially, the Control layer is where the components are located and has business logic such as data processing, etc., as shown in Fig. 2 (KASI 2012a). The key to a development of components is the derivation of components (Song et al. 2004), that is, “What is suitable for a component?” The derivation of components in this research corresponds to the encapsulation and modularization of internals based on the interfaces between the peripheral equipment. The interface should be maintained for subsequent systems and for the replacement of some equipment, thus, it is determined as a component considering reusability. The component has main functions of data transceiver among equipments and control, and it is derived as a class rather than a package since the processing logic is not so complicated. The stereotypes of “<>” or “<>” has been applied in order to identify and name the component during the preparation of UML. The sample illustration of a component in UML is shown in Fig. 3 where the interface to a meteorological equipment is derived as a component and shown in a type of class diagram (KASI 2012b).
PPT Slide
Lager Image
The control layer diagram of the OCS. This control layer is a part of the architecture where the system-dependent components are placed, and has the business logic such as data computation. The components of this layer are expressed as a class type because the processing logic is not complicated.
PPT Slide
Lager Image
The example of the component expressed with UML. The interface with the meteorological equipment is drawn as a component, and is expressed as a class diagram type.
- 3.2 Definition of System Interface and Design
For the normal operation of entire system, various subsystems and operation equipment should be accompanied in addition to AOS (ARGO-M Operation System) (Seo et al. 2009, 2010) which includes operation software. AOS plays a main role for most of communications among these systems. Therefore, an interface design manual called ICD (Interface Control Document) is essential for the system design. In the course of design stage, discussions, design and implementation were performed for communication method, operation logic, in addition to the identification of communication interfaces between other sub-system and the operation equipment. Although the concept of basic communication adopts Ethernet communication, there are cases of using an exclusive controller for the communication due to the nature of hardware. Fig. 4 shows the data flow to analyze the interfaces between other sub-systems and the operation equipment (Seo et al. 2010). The oval shape indicates the other sub-systems except AOS and the rectangular shape represents operation computers and operation equipments comprising AOS. The ICD is prepared largely dividing external interfaces and internal interfaces based on the data flow of communication described above. The external interfaces represent interfaces between AOS and other sub-systems and the internal interfaces indicates the interfaces among low level components or configuration items in AOS. Fig. 5 (KASI 2011a) shows a sample of AOS internal interface described in the ICD which is a capture of the interfaces between OCS (Operation Control System) and one of the operation equipment of radar system. The communication information from OCS to radar is shown in this figure. The number of interfaces identified during the design process is shown in Table 4 .
PPT Slide
Lager Image
Data flow diagram for the interface analysis of other subsystems and operation equipment (adopted from Seo et al. (2010)). ICS: interface con¬trol system, OCS: observation control system, DAS: data analysis system.
PPT Slide
Lager Image
The sample image of the interface control document.
Quantity of the identified communication interface (IF). AOS: ARGO-M operation system, OPS: optics subsystem, OES: opto-electronics subsystem, LAS: laser subsystem, TMS: tracking mount subsystem, ICS: interface con¬trol system, OCS: observation control system, DAS: data analysis system, WMS: weather monitoring system, Timing: Timing system.
PPT Slide
Lager Image
Quantity of the identified communication interface (IF). AOS: ARGO-M operation system, OPS: optics subsystem, OES: opto-electronics subsystem, LAS: laser subsystem, TMS: tracking mount subsystem, ICS: interface con¬trol system, OCS: observation control system, DAS: data analysis system, WMS: weather monitoring system, Timing: Timing system.
- 3.3 Analysis of Main Algorithm and Development of Prototype Model to Reduce the Risks in Performance
The greatest risk factor of performance elements and the core functions are implemented through a prototype model and verified. The prototype model is chosen to verify the on-line primary algorithms. The primary algorithms are divided into those which require the on-line operation of the system for observations and off-line system to analyze the raw data obtained through observations. The analyzed algorithms are shown in flowchart (Seo et al. 20011a) and the verification is performed in the review phase of the detailed design. First of all, as a target of prototype model considering functional verification, an on-line processing algorithm which processes the raw data obtained from the observation of ground targets. For the performance verification, the target of laser repetition rate, the processing capability within 2 kHz is chosen. Also, a user interface terminal is implemented to verify the performance of on-line data display during the implementation of the prototype model. Fig. 6 (Seo et al. 2011b) shows the system block diagram to develop the prototype. The results of Fig. 7 were obtained according to this diagram. The left graph of Fig. 7 shows the plot of a measurement program provided by the manufacturer of Event Timer A032-ET (Bespal’ko 2006) which is a measurement test equipment for the verification and validation. The right graph shows the plot of raw data obtained from the observation using the prototype model. According the results of analysis, both graph show 128 ns to show an agreement. Thus, it was possible to verify the weighted function and the performance through the development of the prototype model.
PPT Slide
Lager Image
The system configuration diagram for validation of the weighted function and performance through the prototyping model development prior to completing the critical design (adopted from Seo et al. (2011b))
PPT Slide
Lager Image
The test result by the configuration of Fig. 6 and the prototype model development: (left) A verified display and measured values through the client software provided by the equipment vendor (right) A result graph of the measured raw data through the prototyping model. As a result, we verified the weighted function and performance through the prototyping model development by showing the result value of 128 ns in both of the pictures.
- 3.4 Implementation
The process of implementation comprises coding and documentation for all the elements defined during the design process. Also, the required developer tests during coding process was performed internally. Microsoft Windows 7 64bit is selected as the operating system of the target developing system and the implementation tool is Visual C++ 2008. The system-wise user interface displays are shown in Fig. 8 . These were implemented according to the user interface design documents prepared during design stage.
PPT Slide
Lager Image
The main UI that completed the implementation: (a) ICS main UI, (b) DAS UI, (c) OCS main UI, (d) OCS status monitoring.
- 3.5 Tests
Official software tests consists of 3 phases as described in Table 5 . However, the source level tests which are performed by the developer during the developing phase are excluded from this classification. Pre-installation tests were performed by the developer after the implementation. For this test, test stubs and drivers were constructed to enable self-tests since the interfaces with other sub-systems were not set up completely. Postinstallation tests were performed after the completion of whole system integration through site installation. The test stubs and the drivers used for pre-installation tests are replaced with the actual sub-systems and operation equipments. Also, most of the test cases of pre-installation tests were repeated for re-confirmation and some tests are added for the post-installation tests. In Table 6 , the number of test cases performed (KASI 2012c, 2012d, 2012e, 2012f, 2012g, 2012h, 2013a, 2013b, 2013c, 2013d, 2013e, 2013f) are classified according to the test and the phase for each host computer. Test cases are classified as module tests and system tests in accordance with the nature of the test. The system integration test which is the third phase test in Table 5 should be performed by preparing the integration test scenario which is consistent with the actual system operation scenario. However, this integration test will be performed during the warranty maintenance phase rather than during software development phase considering the characteristics of entire system development.
The content of the planned software test.
PPT Slide
Lager Image
The content of the planned software test.
The number of the identified test case.
PPT Slide
Lager Image
The number of the identified test case.
4. RESULTS AND DISCUSSION
- 4.1 Analysis of the Results Through Requirement Tracing Table
The requirement tracing table was prepared during the planning phase for the analysis of the results of this research to find out the effect on the software development results compared to the original development plan. In order to verify the consistency and the integrity among the products, the requirement tracing table traces the software requirements starting from the proposal of the project before the initialization of the project until the complete development of the requirements or the exclusion of the requirement out of the scope due to a change (Kim & Rhew 2007). Fig. 9 (KASI 2011c) shows the sample image of OCS requirement tracing table which is one of the development configuration items. The requirement tracing table consists of functional requirements and non-functional requirements with the same trace field. Forward tracing is performed for the requirements among products and the result of acceptance is filled out in the last field according to a qualitative decision. The numbers of satisfaction in the last field of the host-system dependent requirement tracing table (KASI 2011b, 2011c, 2011d) were compared with those of the corresponding requirement, in Table 7 . In other words, the table shows the result of agreement or disagreement compared to the original requirements. Consequently, the original requirements are met completely and the results are satisfactory.
PPT Slide
Lager Image
The sample image of the tailored requirement traceability table.
The result of the requirement satisfaction.
PPT Slide
Lager Image
The result of the requirement satisfaction.
- 4.2 Improvements for the Application of Output Management Technique Based on CBD Methodology
All the applied outputs suggested in Table 3 were derived according to the outputs of CBD methodology and are satisfactory in large. However, the outputs related to the post-installation are not satisfactory since the delay in the development of other hardware sub-systems resulted in the completion of post-installation tests behind schedule. While in the pre-installation tests, test stubs and drivers were constructed to enable self-tests without the interfaces with other sub-systems, it is essential to make interfaces with other sub-systems during post-installation tests, the tests are affected directly by the completion status of the entire system. Hence, the derivation of test cases, conduction of tests, and result report, all were not satisfactory. Therefore, it turned out to be necessary to find a new approach to take into account of the hardware development together with software development interfacing each other.
5. CONCLUSIONS
The purpose of this research is to review current methodologies of development to select the best one for the development of astronomical observation equipment and to present the results of application of the methodology. As a result of the application, the requirements were met and the outputs are satisfactory compared to the original planning. Above all, this research would be an example of systematic software development and it was possible to check the progress versus plan. However, there was a delay in the post-installation test due to the troubles in the interfaces with other sub-systems to cause the results of integration test to be dissatisfactory. Therefore, this issue is necessary to be corrected later even with the application of output management technique according to the conventional methodology. The components derived in this research comprise interfaces with surrounding equipments and those will be reused for the subsequent system development. This study would be the example of the first application of the software development methodology in the domestic astronomical observation system area. Thus, there have been difficulties due to the lack of understanding of the methodology. It is considered that these difficulties could be overcome gradually according to the application of other methodologies. For further research, a different methodology could be applied to the development of similar system and the effect and the characteristics could be compared and quantitative quality analysis would be possible according to ISO/IEC 9126. The process and results of this study would contribute to the investigation for a more appropriate methodology in the area of similar system development in the future.
Acknowledgements
This work has been supported by the Korea Astronomy and Space Science Institute (KASI) through the SLR system development program for space geodesy funded by the Ministry of Science, ICT & Future Planning (MSIP) – Republic of Korea.
References
Allen P , Kim KJ 2001 Fundamental elements of CBD process Journal of KIISE 19 40 - 50
Bespal’ko V , Boole E , Vedin V The Model A032-ET of Riga Event Timers 15th International Workshop on Laser Ranging Canberra, Australia 15-20 Oct 2006
Chae J , Yoon H Comparison and Evaluation of Software Product Line Methodology for developing Embedded Software 34th KIISE Conference Pusan 26-27 Oct 2007
Chung SW , Luor T , Lu HP 2014 Assessment of institutions, scholars, and contributions on agile software development (2001-2012) J. Syst. Software http://dx.doi.org/10.1016/j.jss.2014.03.006 93 84 - 101
Chung YD , Lim JS , Yoon H 2006 Present and future of advanced defense development methodology Journal of KIISE 24 75 - 80
Enterprise Architect [Internet] http://www.sparxsystems.com/
Ham DH , Kim JS , Cho JH , Ha SJ 2004 MaRMI-III: A Methodology for Component-Based Development ETRI Journal http://dx.doi.org/10.4218/etrij.04.0103.0041 26 167 - 180
2009 Es¬sentials of Visual Modeling with UML 2.0 Module 2: Principles of Visual Modeling, IBM Software Group Technical Document
1998 IEEE Standard for Software Project Management Plans IEEE standard association
2004 IEEE Standard for Software Verification and Validation IEEE standard association
2004 Information Technology-Software packages-Quality requirements and testing IEEE standard association
2000 Information technology-Software product quality -Part 1: Quality model International Organization for Standardization
Jin KY , Shin HC , Pan AH Consistency support method among products of analysis and design step 2004 the 31th KIISE Spring Conference Seoul 22-23 Oct 2004
Jo HK , Ko IY , Lee J , Park S An Artifact-sharing Method across Multiple Component-based Military Software Development Processes 2007 the 34th KIISE Fall Conference Pusan 26-27 Oct 2007
Jo JH , Park IK , Lim HC , Seo YK , Yim HS , et al. 2011 The design concept of the first mobile satellite laser ranging system (ARGO-M) in Korea JASS et al. http://dx.doi.org/10.5140/JASS.2011.28.1.093 28 93 - 102
2011 ARGO-M operation and control system development project: Interface Control Document Korea Astronomy and Space Science Institute
2011 ARGO-M operation and control system development project: Requirement traceability description (ICS) Korea Astronomy and Space Science Institute
2011 ARGO-M operation and control system development project: Requirement traceability description (OCS) Korea Astronomy and Space Science Institute
2011 ARGO-M operation and control system development project: Requirement traceability description (DAS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : Final design document (OCS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project: Final design document (OCS) - Component design document Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : Unit test plan and result report for preinstallation test (ICS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : System test plan and result report for preinstallation test (ICS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : Unit test plan and result report for preinstallation test (OCS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : System test plan and result report for preinstallation test (OCS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : Unit test plan and result report for preinstallation test (DAS) Korea Astronomy and Space Science Institute
2012 ARGO-M operation and control system development project : System test plan and result report for preinstallation test (DAS) Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: Unit test plan and result report for postinstallation test (ICS) Korea Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: System test plan and result report for postinstallation test (ICS), Korea Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: Unit test plan and result report for postinstallation test (OCS) Korea Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: System test plan and result report for postinstallation test (OCS) Korea Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: Unit test plan and result report for postinstallation test (DAS) Korea Astronomy and Space Science Institute
2013 ARGO-M operation and control system development project: System test plan and result report for postinstallation test (DAS) Korea Astronomy and Space Science Institute
Kim JY , Rhew SY 2007 An empirical study on tracking table for consistency and completeness validation in the outputs Journal of KIISE: Software and Applications http://koix.ksci.re.kr/KISTI1.1003/JNL.JAKO200727543156668 34 419 - 430
Kundu D , Samanta D , Mall R 2013 Automatic code generation from unified modeling language sequence diagrams IET Software http://dx.doi.org/10.1049/iet-sen.2011.0080 7 12 - 28
2011 Guidelines for CBD Software Deliverables Development
2006 Unified Modeling Language: Infrastructure, version 2.0
OMG (Object Management Group) [Internet] http://www.omg.org/
Park E , Yu SY , Lim HC , Bang SC , Seo YK , et al. 2012 Status and progress of ARGO-M system development PKAS et al. http://dx.doi.org/10.5303/PKAS.2012.27.3.049 27 49 - 59
Rizwan Jameel Qureshi M 2012 Agile software development methodology for medium and large projects IET Software http://dx.doi.org/10.1049/iet-sen.2011.0110 6 358 - 363
Seo YK , Rew DY , Lim HC , Park IK , Yim HS , et al. 2009 A study on the deriving requirements of ARGO operation system JASS et al. http://dx.doi.org/10.5140/JASS.2009.26.4.643 26 643 - 650
Seo YK , Lim HC , Rew DY , Jo JH , Park JU , et al. 2010 Study on the preliminary design of ARGO-M operation system JASS et al. http://dx.doi.org/10.5140/JASS.2010.27.4.393 27 393 - 400
Seo YK , Rew DY , Lim HC , Kirchner G , Park JU , et al. 2011 A study on tracking method and normal point formation algorithm of new mobile SLR system in Korea Journal of the Korean Society for Aeronautical and Space Sciences et al. http://dx.doi.org/10.5139/JKSAS.2011.39.4.370 39 370 - 377
Seo YK , Lim HC , Park ES , Park JU , Bang SC , et al. Software design and development status of ARGO-M operation system 2011 the 17th International Workshop on Laser Ranging Bad Koetzing, Germany 16-20 May 2011b et al.
Song YJ , Kim GJ , Byun JW , Seo YJ , Choi HY , et al. 2004 Software Engineering Based on Object Oriented Modeling and CBD Ehan Goyang et al. 507 -
2001 Standard for Software Unit Testing , Telecommunications Technology Association
2002 Standard for Software Test Documentation, Telecommunications Technology Association
2003 Standard for Software Project Management Plans, Telecommunications Technology Association
2003 Standard for software development artifacts specification, Telecommunications Technology Association
2006 Guidelines for Object-Oriented Software Testing Telecommunications Technology Association
2013 Guidelines for CBD Software Deliverables Development Telecommunications Technology Association
Youn C 2009 Software Engineering through Paradigm Shift Sangnung Paju 82 - 86