Multidisciplinary Systems Engineering pp 149-174 | Cite as
Systems Engineering Tasks and Products
Abstract
Developing of a cohesive technical plan, requires engineering efforts to follow established guidance at each tier of the architecture, and is critical to achieve successful system engineering processes. A technical plan should establish the guidance and/or work instructions for the technical artifacts, so that a standards-based approach can be maintained across both small and large development, taking into account time, schedule and personnel turn-over. When guidance is established, it allows for management and tracking of activities at each development level ensuring system design and implementation meets development objectives. As the program progresses, refinement of technical guidance may occur. If so, it is critical that changes in guidance flows down efficiently to the entire engineering staff and that the new direction is followed. Although many optimizations can be found during development, it is important for Systems Engineering to watch closely for and to avoid unnecessary shortcuts during all technical engineering efforts, as each shortcut can lead to increased development and cost risks.
Keywords
Multidisciplinary systems engineer Systems engineer Technical planning Technical assessment Milestones Technical performance measures (TPM) Technical coordination Change control Change management Documentation Database Mission analysis Stakeholders Objectives Technical requirements Requirements Formal requirements Informal requirements Acronym System tier Application services tier Persistent services tier Data access tier Data access objects API Data management Data labelling Orchestration Communications tier Derived requirements Statement of objectives Attribute Object text COTS FOSS Subsystem External interface Internal interface XML Business-to-business Trade studies CONOPS Life cycle cost Total cost of ownership Likelihood of occurrenceReferences
- 64.Offutt, J. and J. Hayes. 1996. A Semantic Model of Program Faults. International Symposium on Software Testing and Analysis. CiteSeerX: 10.1.1.134.9338.Google Scholar
- 96.Ramesh, B. and Jarke, M. 2001. Toward Reference Models for Requirements Traceability. IEEE Transactions on Software Engineering 27(1):58-93.CrossRefGoogle Scholar
- 97.Robertson, J. and Robertson, S. 2007. Mastering the Requirements Process. Addison-Wesley, Boston, MA, ISBN-13: 978-0321815743.Google Scholar
- 98.Tyree, J. and Akerman, A. 2005. Architecture Decisions: Demystifying Architecture. IEEE Software, 22(2):19-27.CrossRefGoogle Scholar
- 99.Lamsweerde, A. 2001. Goal-Oriented Requirements Engineering. In Proceedings of the Fifth IEEE International Symposium on Requirements Engineering, Toronto, CAN.Google Scholar
- 100.Lamsweerde, A. 2009. Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley & Sons, Hoboken, NJ.Google Scholar
- 101.Broy, M. and Stølen, K. 2001. Specification and Development of Interactive Systems: Focus on Streams, Interfaces and Refinement. Springer Publishing, New York, NY.CrossRefGoogle Scholar
- 102.Erdobmus, H., and Torchiano, M. 2005. On the Effectiveness of Test-first Approach to Programming. Proceedings of the IEEE Transactions on Software Engineering, 31(1), NRC 47445.Google Scholar
- 103.Madeyski, L. 2010. Test-Driven Development - An Empirical Evaluation of Agile Practice. Springer Publishing, New York, NY, ISBN 978-3-642-04287-4.CrossRefGoogle Scholar
- 104.Hamilton, M. and Hackler, W. 2000. A Rapid Development Approach for Rapid Prototyping Based on a System that Supports its own Life Cycle. Proceedings, 10th International Workshop on Rapid System Prototyping.Google Scholar
- 105.Jaakola, H. and Thalheim, B. 2011. Architecture-Driven Modeling Methodologies. In Proceedings of the 2011 Conference on Information Modelling and Knowledge Bases XXII, Anneli Heimbürger et al. (eds), IOS Press.Google Scholar