In the last presentation, we looked at the

nature of systems.
In this presentation, we are going to look
at the life cycle of a system.
Before of course, we focus on the
main interest in the course, Systems
Engineering.
As with almost anything else a system has
a life.
At some point it doesn't exist.
It's brought into being.
Used and then disposed of.
Once, we can no longer use it for the
purpose for which it's created.
Throughout the life of a system therefore,
there are a number of phases and
activities.
Each of which builds on the results of the
preceding phase or activity.
The sum of all these activities is called
a system life cycle.
Which could described in a model, as four
very broad phases.
It starts with the conceptual of the
business needs for the system.
In the pre-acquisition phase.
The system is then fine tuned and
formalized and is realized in the
acquisition phase.
Its been used and evolved in the
utilization phase.
And is finally disposed of in the
retirement phase.
Let's look at each of those phases in a
little bit more detail.
The life cycle begins with the
Pre-acquisition Phase.
With an idea for the system being
generated as a result of business
planning.
The early needs of the business are
confirmed and is supported by a business
case.
Which justifies expenditure of
organizational resources
on the acquisition of the system.
In some instances, the Pre-acquisition
Phase may determine that it
might not be feasible or cost-effective to
proceed to acquisition.
For example, due to technology limitations
or funding shortfalls.
In that sense, then, the pre-acquisition
phase
is where the organization spends research
and
development funds To ensure that only
feasible,
cost-effective projects are taken forward
to acquisition.
Once the business needs for the system can
be
justified, they provide the input to the
acquisition phase.
Which is focused on bringing the system
into being and into service in the
organization.
This would normally involve defining the
system in terms of three major artifacts.
Which we'll describe shortly: business
requirements, stakeholder requirements,
and system requirements.
We'll also see shortly that the customer
can then go on to develop the system.
But most commonly, a contractor is engaged
to develop
the system, and then deliver it back to
the customer.
Who introduces it into service, in the
utilization phase.
The systems operator during the
utilization phase, during which
time it's also supported by the
organization that owns it.
During utilization, the system may also
undergo a number of
modifications, and upgrades of different
sorts, to rectify performance shortfalls.
Perhaps to meet a changing operational
requirement or perhaps
because the external environment has
changed in some way.
Or perhaps even that the ongoing support
of the system is
become expensive and needs to be modified
to ease its maintenance.
Now the system remains in service during
the utilization phase.
Perhaps being modified over time, until
the
business has no further need for the
system.
Or it no longer can do what the
organization requires of it,
or it does but is not cost-effective to
keep it in service.
The system life cycle, therefore concludes
with the retirement phase.
If the business need for the capability
still
exists, the conclusion of this life cycle
at the
retirement phase Will most likely also
mark the
start of another life cycle for the
replacement system.
And the process begins again.
Throughout the system life cycle there are
a number of parties involved.
First of course, is the customer
organisation.
They're managed by enterprise management
who
set the direction for the organisation.
And pass the tasks to business management.
Who are responsible for the activities
that are
conducted by the operations element of the
organization.
Run by the operators, and sometimes called
the users.
The systems used within the organization
are acquired by an acquisition element.
Also called the acquirer or in some
standards the tasking activity.
They belong to the organisation and they
work under
the auspices of a project manager who runs
the project.
Project managers are also supported by a
number of other related disciplines.
One of course, the reason why we're here
is system engineering.
But there's also requirements engineering
and other specialty engineering
disciplines.
Quality assurance and integrated logistic
support.
The operators who do the business in the
organization
are support in their operation by the
support element.
Which supports, sustains and maintains the
system throughout its life.
In addition to operational, acquisition,
and support staff.
There many others in the organization who
also have
a stake in the successful implementation
of the project.
These people we call stakeholders.
And they include representatives from
management, financial, operations,
supply, maintenance, and facilities areas
of the organization.
The system, is as I said before, most
likely obtained
from a supplier, also called in some
standards, the performing activity.
Who may deliver the system off-the-shelf,
or may develop
it, in which case, they did also called
the developer.
The supplier, or the developer, maybe an
internal
part of the customer, or the acquirer
organization.
If the development of the system is to be
undertaken in house.
The acquisition element of the
organization, the acquirer,
will engage with the development
organization, the developer.
In order to support the system.
But it's increasingly common these days
for the supply
or development to be undertaken outside,
by a contractor.
Which is therefore the entity responsible
for supplying and most likely
for designing and developing the system to
meet the customer requirements.
And so most commonly these days, we have
customers and contractors.
The relationship between the customer and
the
contractor varies with each sort of
project.
But, before each project, the
relationships are defined by the
terms and conditions of the contract
between the two parties.
In many cases, the contractors themselves
are not able to perform all of the work.
And devolves the packages of work into
a number of subcontracts, delivered by
subcontractors.
The terms and conditions relaying to this
work are then in the relevant subcontract.
Responsibility for the various phase of
the system life
cycle is spread across the enterprise or
the organization.
Within which the eventual system will
operate.
The initial pre-acquisition phase is
clearly the responsible of enterprise
management.
Who conduct the early business planning
and establish the business
case for the projects that required to
support the organization.
The works not over though, they must then
engage
with the system development process
throughout acquisition, utilization and
retirement.
The system is ultimately the
responsibility of
business management, more than anyone else
involved.
It is after all, their business.
A project is then established with a
project charter
providing authority from business
management to a project manager.
To expand organizational resources on
acquiring this system.
The project manager will be principally
responsible for the acquisition and
may be engaged for the other life cycle
phases as well.
Working for the project manager is systems
engineering.
Now, system engineering is an important
discipline, responsible to the
project managers to perform the technical
management for the project.
Throughout acquisition and utilization, as
well as retirement.
Now, of course once the acquisition is
complete the system
is introduced into service and is operated
by the users.
And supported by the support element.
These people have been involved early in
the acquisition phase.
They have provided essential input to the
system engineering
and the project management processes, but
now their principle responsibility.
They, like all parties involved, are
involved in all phases of the life cycle.
But the roles and responsibilities for
each
party shifts in emphasis between those
phases.
>> [BLANK_AUDIO]