SYSTEMS ENGINEERING APPROACH IN MANAGEMENT SYSTEMS

1. SYSTEMS ENGINEERING APPROACH AND LIFE (CYCLE) PROCESSES STANDARDS

Systems engineering; By dealing with systems formed by bringing together the products of many engineering disciplines, it differs from other engineering disciplines or represents their integrated form. Systems engineering, attention; It is a branch of engineering in which the parts are collected into the design and applications of the whole. It handles all kinds of variables related to the need or the project with a holistic approach, taking into account its social and technical aspects. Systems engineering; It is the product of a joint study that is interdisciplinary, aimed at meeting the needs of those in need (buyers), taking into account the concepts of the system life cycle, holistically and thus maximizing its effectiveness.

Systems engineering; It covers all sub-processes, activities and/or tasks implemented in the process that starts with analyzing the requests submitted by the need authority (buyer, customer and/or user) and continues until the system completes its usable life.

Systems engineering; Nowadays, especially in defense sector projects and high-level management system standards (for example, ISO27001: Information Security Management System, ISO15288: System Life Cycle Processes, ISO12207: Software Life Cycle Processes, AQAP-160: Throughout the Life Cycle for Software). Unified NATO Quality Requirements, AQAP-2110: NATO Quality Assurance Requirements for Design, Development and Production, etc.). Today, standards defined as system (or product, service, project, software) life cycle processes have been created in accordance with the systems engineering discipline.

• The first Systems Engineering approach in the world was introduced in 1940 (BellLabs, MIT, RAND Corp.).
• The USA widely used Systems Engineering methods in the development of many systems during World War II.
• The first Systems Engineering courses started to be given at MIT in 1950.
• Today, Systems Engineering practices have become standard in many developed countries, especially in the USA and Europe.

Systems Engineering is an engineering discipline that emerged as a result of years of experience by the Defense, Aerospace Industries in the USA; It is widely applied in this country as well as in many developed countries and plays a critical role in the success of the projects. Systems Engineering is widely used in the Defense Industry as well as in Transportation and Energy projects.

Systems Engineering, which was chosen as the profession of the year in the USA in 2009, plays a key role especially in large system integration projects. System Engineering, which is required to be implemented as an indispensable part of Defense Industry projects in our country, is rapidly spreading to the Transportation and Energy sectors.

2. SYSTEM ENGINEERING APPROACH IN THE SYSTEM (PRODUCT, PROJECT, SOFTWARE) LIFE PROCESS

A design and integration process called the Systems Engineering V-Model is widely used for the development of complex systems (see Fig.1). According to this model, the design process begins with analyzing the requests presented by the need authority (buyer, customer and/or user). These requests are initial requirements determined by the user or the authority in need in accordance with the operational concept envisaged for the system. Although these requirements contain clear and descriptive information in terms of the buyer’s own usage environment, the requirements must be transformed and classified into meaningful technical requirements for the designer in order to be used as design input.

All requests presented by the requirement authority, from the designer’s point of view, physical, functional, performance, interface, logistics, environment, safety/security, etc. They are grouped into classes and converted into system requirements expressed from the designer’s perspective. The resulting system requirements continue to evolve and lead to subcomponent requirements and/or configuration item requirements.

Let’s think of the phases defined by many people in the literature as the architectural and conceptual design phase and the detailed design phase as “definition” and “design”. Because understanding and “defining” the needs of the buyer (buyer) very well before moving on to design means preventing faulty design and subsequent faulty production.

Now, both the “System Engineering VModel” and the “Configuration Management Model in the System (Product/Service/Project) Life Process” that I recommend, which are applied in the system (product, software, project, etc.) life process, are used in the life process phases. Let’s explain it together. I would like to point out that I will not go into the details of configuration management here.

2.1 Identification Phase

In order to turn user (buyer, customer) requests into system requirements that can provide input into the design, the architectural design phase of the system is started. During the architectural design phase, three separate architectures are developed. These are called “functional, physical and operational” architecture. The functional architecture of the system defines what the system is supposed to do, the functions of the system, and the data that flows between them. The physical architecture of the system involves determining the physical resources that will perform the functions of the system. Operational architecture, on the other hand, is created by the synthesis of the allocation process that defines which functions will be performed with which physical resources. During the architectural design process, interfaces are also defined by taking into account the physical and functional architectures of the system. This architecture provides input into system and subsystem designs and provides the basis for controlling interfaces as the design progresses.

Then, in the process that starts with the offer and/or tender stage other than the sales order for a ready-made product (system, etc.), the conceptual / functional configuration of the product is defined, taking into account customer requirements. When the conceptual/functional definition is completed and it is decided to move on to the design of the product, the configuration information is updated and the configuration is brought to the “Basic” state. The condition for changing the configuration status to “Basic” during the definition phase; The sales contract, relevant plan documents (configuration management plan, project management plan, security requirements plan, etc.) and relevant requirement documents are completed. In addition, it is a suitable method for the Configuration Management Board, which includes the buyer (customer), to approve the phase transition. If the existence of components that may be required during the installation of the product in the customer environment (field) is known, a discovery is made to identify these components. Thus, by adding the components to be used in the installation into the Conceptual / Functional Definition Configuration, the design of the product is initiated to fully suit the customer requirements.

2.2 Design Phase

Following the architectural design process, the subsystems and functions of the system are shaped by assigning the requirements of the components that make up the system. The process of creating a basic structure level (Design Base) in design is defined as “a creative process based on validation of options and repetitive actions.” According to this approach, the designer creates a basic structure of his own system based on the task requirements, performs repetitive actions by analyzing all the parameters of the system, and checks that the basic structure he has determined meets the performance requirements (with verification and validation tests). Thus, the structuring (configuration) and design basic configuration of the system and the subcomponents (elements) that make up the system are created.

During the design phase, detailed design is carried out, verified and validated using the definition (conceptual / functional) documents of the product. The condition for bringing the configuration status to the “Basic” state during the design phase is the validation of the design prototype, that is, the completion of the tests in the test environment.

In order to start mass production for a system (product, etc.) whose design has been converted to “Basic” status, the most preferred practice is to carry out a trial production under mass production conditions and then start production with the mass production authorization obtained.

2.3 Production, Installation/Deployment and Maintenance Phases

At the end of the production phase, as a result of the acceptance tests to be carried out with the customer, the relevant products (configurations) are approved to be shipped to the customer, in other words, the relevant configuration item is released for release.

During the installation (and deployment) phase, the relevant system(s) (product, software) are installed and/or deployed in the field (at the locations specified by the customer in the agreement) in accordance with the defined documents. At this stage, temporary field acceptance test and/or field acceptance test can also be applied upon the customer’s request.

In the maintenance phase that begins after the system (product, software) is installed and delivered to the customer (buyer); Changes that occur in the product configuration are tracked with the method described in the “Control and Implementation of Configuration Changes” article.

By adopting the system engineering approach, consistent and effective operation is ensured in the design phase of the systems as well as in the production, installation (and deployment) and maintenance phases. Shape. Documents related to configuration management and transition conditions at these stages are shown in Figure 3.

2.4 V-Model

The V-Model has been criticized by agile method advocates and some others as an inadequate model for software development for various reasons. Some of the criticisms include:

• The V-Model reflects a project management view of software development and meets the needs of project managers, accountants, and lawyers rather than software developers or users.
• Although easily understood by beginners, a more comprehensive and detailed effort is required on how to adapt and extend the V-Model in practice.
• It is not flexible. It encourages a rigid and linear view in software development. There is no ability to respond to change.
• It provides a slight variation on the waterfall model and is therefore subject to the same criticisms as this model. It places greater emphasis on testing and especially the importance of early testing planning.
• It encourages inefficient and ineffective testing methodologies.
• It lacks consistency and precision. There is widespread confusion about what exactly the V-Model is.

Supporters of the V-Model argue that the model evolves over time and promotes flexibility and agility throughout the development process. They also say that it is a highly disciplined approach as well as meticulous design, development and documentation to produce stable software products.

2.5 Configuration Management Model in System (Product/Service/Project) Lifecycle

Dividing the system (or product, service, project) life process into phases is a well-known concept. When we combine and apply this concept with the concept of configuration management, which is not a new thing for large-scale and standards-compliant organizations, a much more consistent and reliable application model emerges. The configuration management model during the system (or Product, Service, Project) life cycle is shown conceptually in Figure 2.

The main purpose of configuration management is to ensure that products (services); To ensure that it is created accurately and completely to fully meet customer requirements at all stages of the life process. Therefore, it is very important to determine the stages of the life process, to establish the transition rules between these stages, and to define the activities to be carried out and the outputs to be created in each stage. Summary information about these issues; Shape. It is shown schematically in Table 3, and the relevant document definitions are explained in Table 1. Shape. The transition conditions and documents specified in Table 3 and Table 1 are given as examples by choosing the most important ones. Shape. The document abbreviations given in Figure 3 are defined to show as many documents as possible on the same figure. These abbreviations may be similar and/or different in different organizations.

I won’t go into the details of configuration management here. But in summary, configuration management: configuration element (system, product, subsystem, subproduct, etc.);

✓To define and document its functional and physical properties,
✓ Controlling changes in features and recording changes,
✓ Recording and reporting progress,
✓ To check compliance with the specified requirements,

We can say that it is a process consisting of methods, resources and tools applied for

Shape. Configuration Management and Documents in 3 Product (Service/Project/System) Lifecycle Phases

Shape. The meanings of the document abbreviations (document definitions) specified for the relevant stages in 3 are shown in Table 1. The documents mentioned here are not all documents, they are given as examples.

Table. Documents in 1 Product (Service/Project/System) Life Cycle Phases

2.6 Control and Implementation of Configuration Changes

Configuration change requests that occur at any stage or location of the system (product, software) life process are sent to the departments that will implement the change and the Configuration Management Board with a document in which the changes are explained in detail (“Product Configuration Change Document”, etc.). The buyer (customer) or interested parties are informed about the changes. Discussing and approving Product Configuration Changes; It is held at the “Configuration Management Board” meetings attended by representatives from relevant units. When requested by the customer, the customer’s representative also attends this meeting. With the approval of those attending the meeting, the effective date and change class of the change are determined. Change classes; The changes are determined by taking into account their importance and effects (shape, conformity, function changes, etc.). The change proposal rejected by the Configuration Management Board is not processed. Whatever phase in the life process the system (product, software) configuration change concerns, life process activities in the relevant phase are carried out and after the relevant changes are applied, the configuration is made Basic and the life process continues. In order to ensure traceability and control of changes in the system (product, software) and documents; document set, document set change information, product configuration change authority, configuration item, configuration item status, configuration number, implementation date, change class, product configuration change authority number, Configuration Management Board decision date, etc. information needs to be tracked. It would be appropriate to use a “Configuration Management System” software to monitor this information easily and accurately. I should reiterate that I am not going into the details of configuration management here.

3. STANDARDS RELATED TO LIFE (CYCLE) PROCESSES

Some of the standards related to system (product) life (transfer) processes, which are prominent in our country’s defense industry projects today, are shown in Table 2 for informational purposes.