EMCS – 981 Myo Thi Ha

Name : Myo Thi Ha

Roll Number : EMCS – 981
Assignment : COMP 612 - Assignment 3

1.  (a) Describe the phases of the system engineering process.

     (b) The emergent properties of a system are properties that are characteristics of
the system as a whole rather than of its component parts. Do you agree that the
success or failure of a system is often dependent on these emergent properties?
Why?
     (c) Explain why legacy systems can cause difficulties for companies that wish
to reorganize their business processes.

Answer:

1 (a) The phases of the system engineering process are:

- Requirements Definition
- System Design
- Sub-system Development
- System Integration
- System Installation
- System Evolution
- System Decommissioning

1
 EMCS – 981 Myo Thi Ha

Requirement Definition

System Requirement definitions specify what the system should do (its

functions) and its essential and desirable system properties. Creating system
requirement definition involves consultations with system customers and
end-users.
This requirements definition phase usually concentrates on deriving three
types of requirement:

- Abstract functional requirements:

System functions are defined in an abstract way.

- System properties :
Non-functional requirements for the system in general are defined.

- Characteristics that the system must not exhibit

Unacceptable system behavior is specify.

An Important part of the requirements definition phase is to establish a set of

overall objectives that the system should meet.

System Design
System design is concerned with how the system functionality is to be
provided by the components of the system.

The activities involved in this process are :

- Partition Requirement: Analyze the requirements and organize them into related
groups.
- Identify sub-systems: Identify sub-systems that can individually or collectively
meet the requirements.
- Assign requirements to sub-systems : Causes particular problems when COTS
are integrated. Assign the requirements to each
identified sub-system.
- Specify sub-system functionality: Relationship between the sub-systems should
be identified at this stage which can collectively meet the
system requirements

- Define sub-system interfaces: Once defining the sub-system interface have been
2
 EMCS – 981 Myo Thi Ha

agreed, parallel development of the sub-system

becomes possible.

Sub-system Development
The sub-system is identified during system design are implemented.

- Typically parallel projects developing the hardware, software and

communications
- It may involve some COTS (Commercial Off-the-Shelf) systems
procurement
- Lack of communication across implementation teams
- Bureaucratic and slow mechanism for proposing system changes means
that the development schedule may be extended because of the need for
rework.

System Integration
During the system integration process, you take the independently developed
sub-systems and put them together to make up a complete system.
- The process of putting hardware, software and people together to make a
system.
- Should be tackled incrementally so that sub-systems are integrated one at a
time.
- Interface problems between sub-systems are usually found at this stage.
- May be problems with uncoordinated deliveries of system components.

System Installation
It is the activity of installing the system in the environment in which it is intended
to operate. Some of the problems that can arise during installations are:
- Environmental assumptions may be incorrect.
- May be human resistance to the introduction of a new system.
- System may have to coexist with alternative systems for some time.
- May be physical installation problems (e.g. cabling problems).
- Operator training has to be identified.

System Evolution

3
 EMCS – 981 Myo Thi Ha

Large, complex system has a very long lifetime. During their life, they are
changed to correct errors in the original system requirements and to implement
new requirements that have emerged.

System evolution, like software evolution is inherently costly for several

reasons:
- Proposed changes have to be analyzed very carefully from a business and
a technical perspective. Changes have to contribute to the goals of the
system and should not simply be technically motivated.
- Because sub-systems are never completely independent, changes to one
subsystem may adversely affect the performance or behavior of other
subsystems. Consequent changes to these sub-systems may therefore be
needed.
- The reasons for original design decisions are often unrecorded. Those
responsible for the system evolution have to work out why particular design
decisions were made.
- As systems age, their structure typically becomes corrupted by change so
the costs of making further changes increases.

Existing systems which must be maintained are sometimes called legacy

systems.

System Decommissioning
System decommissioning means taking the system out of service after the
end of its useful operational lifetime. For hardware systems this may involve
disassembling and recycling materials or dealing with toxic substances. Software
has no physical decommissioning problems, but some software may be
incorporated in a system to assist with the decommissioning process. For example,
software may be used to monitor the state of hardware components. When the
system is decommissioned, components that are not worn can therefore be
identified and reused in other systems.

If the data in the system that is being decommissioned is still valuable to

your organization, you may have to convert it for use by some other system. This
can often involve significant costs as the data structures may be implicitly defined
in the software itself. You have to analyze the software to discover how the data is
structured and then write a program to reorganize the data into the required
structures for the new system.

1(b) Emergent Properties

4
 EMCS – 981 Myo Thi Ha

Emergent system properties are properties of the system as a whole rather

than properties that can be derived from the properties of components of a system.
Emergent properties are a consequence of the relationships between system
components. They can therefore only be assessed and measured once the
components have been integrated into a system.

There are Two Types of emergent property

- Functional emergent properties
These appear when all the parts of a system work together to achieve some
objective. For example, a bicycle has the functional property of being a
transportation device once it has been assembled from its components.

- Non-functional emergent properties

Examples are reliability, performance, safety, and security. These relate to the
behaviour of the system in its operational environment. They are often critical for
computer-based systems as failure to achieve some minimal defined level in these
properties may make the system unusable.

Examples of Emergent properties are

- Volume
The volume (total space occupied) varies depending on how the component
assemblies are arranged and connected.

- Reliability
This depends on the reliability of system components and the relationships
between the components but unexpected interactions can cause new types of
failure and affect the reliability of the system.

- Security
The ability to resist attack means security. It is a complex property that cannot be
easily measured.

- Repairability
This property reflects how easy it is to fix a problem with the system once it has
been discovered. It depends on being able to diagnose the problem, access
components that are faulty and modify or replace these components.

- Usability
5
 EMCS – 981 Myo Thi Ha

This property reflects how easy it is to use the system which is not simply
dependent on the system hardware and software but also depends on the system
operators and the environment where it is used.

To illustrate the complexity of emergent properties, consider the property of

system reliability. Reliability is a complex concept that must always be considered
at the system level rather than at the individual component level. The components
in a system are interdependent, so failures in one component can be propagated
through the system and affect the operation of other components. It is often
difficult to anticipate how the consequences of component failures propagate
through the system. Consequently, you cannot make good estimates of overall
system reliability from data about the reliability of system components.

There are three related influences on the overall reliability of a system:

Hardware reliability: What is the probability of a hardware component failing and

how long does it take to repair that component?

Software reliability: How likely is it that a software component will produce an

incorrect output? Software failure is usually distinct from hardware failure in that
software does not wear out. Failures are usually transient so the system carries on
working after an incorrect result has been produced.

Operator reliability. How likely is it that the operator of a system will make an
error?

All of these are closely linked. Hardware failure can generate spurious
signals that are outside the range of inputs expected by software. The software can
then behave unpredictably. Operator error is most likely in conditions of stress,
such as when system failures are occurring. These operator errors may further
stress the hard ware, causing more failures, and so on. Thus, the initial, recoverable
failure can rapidly develop into a serious problem requiring a complete system
shutdown.

Like reliability, other emergent properties such as performance or usability

are hard to assess but can be measured after the system is operational. Properties
such as safety and security, however, pose different problems. Here, you are not
simply concerned with an attribute that is related to the overall behavior of the
system but are concerned with behavior that the system should not exhibit. A

6
 EMCS – 981 Myo Thi Ha

secure system is one that does not allow unauthorized access to its data but it is
clearly impossible to predict all possible modes of access and explicitly forbid
them. Therefore, it may only be possible to assess these properties by default. That
is, you only know that a system is insecure when someone breaks into it.

With the above facts, I agree that the success or failure of a system is often
dependent on these emergent properties because they include properties such as
performance, reliability, usability, safety and security.

1 (c)
To develop a complex system, large computer based systems usually have a
long lifetime, need more time and effort required. (Eg: Military system - 20years
lifetime system). It is sometimes too expensive and too risky to discard such
business critical systems after a few years of use. Their development continues
throughout their life with changes to accommodate new requirements, new
operating platforms, and so forth.
Legacy systems are socio-technical computer-based systems that have been
developed in the past, often using older or obsolete technology. These systems
include not only hardware and software but also legacy processes and procedures
old ways of doing things that are difficult to change because they rely on legacy
software. Changes to one part of the system inevitably involve changes to other
components.
Legacy systems are often business-critical systems. They are maintained
because it is too risky to replace them. For example, for most banks the customer
accounting system was one of their earliest systems. Organizational policies and
procedures may rely on this system. If the bank were to scrap and replace the
customer accounting software (which may run on expensive mainframe hardware)
then there would be a serious business risk if the replacement system didn't work
properly. Furthermore, existing procedures would have to change, and this may
upset the people in the organization and cause difficulties with the bank's auditors.

System Hardware : In many cases, legacy system have been written for main
frame hardware that is no longer available, that is expensive to maintain and that
may not be compatible with current organizational IT purchasing policies.
Support Software : The Legacy system may rely on a range of support software
from the operating system and utilities provided by the hardware manufacturer
through to the compilers used for system development.

7
 EMCS – 981 Myo Thi Ha

Application Software : The application system that provides the business

services is usually composed of a number of separate programs that have been
developed at different times. Sometimes the term legacy system means this
application software system rather than the entire system.

Application data : These the data that are processed by the application system.
This data may be inconsistent and may be duplicated in several files.

Business processes : These are processes that are used in the business to achieve
some business objective. Business processes may be designed around a legacy
system and constrained by the functionality that it provides.

Business policies and rules : These are definitions of how the business should be
carried out and constraints on the business. Use of the legacy application system
may be embedded in these policies and rules.

With the above facts, legacy systems can cause difficulties for companies
that wish to reorganize their business processes because legacy systems often run
on obsolete and usually slow hardware, and sometimes spare parts for such
computers become increasingly difficult to obtain. These systems are often hard to
maintain, improve, and expand because there is a general lack of understanding of
the system (as the staff who were experts on it have retired or forgotten what they
knew about it, and staff who entered the field after it became "legacy" never
learned about it in the first place), which can be worsened by lack or loss of
documentation. Integration with newer systems may also be difficult because new
software may use completely different technologies. The kind of bridge hardware
and software that becomes widely available for different technologies that are
widely popular at the same time does usually not get developed for differing
technologies in different times, because of the lack of a large demand for it and the
lack of associated reward of a large market economies of scale, though some of
this "glue" does get developed by nice vendors and enthusiasts of particular legacy
technologies often called "retrocomputing" communities.