In the last presentation,

we looked at the nature of systems. In this presentation, we're going to look

briefly at the life
cycle of a system before, of course, we focus on the main interest in
the course, systems engineering. As of almost anything else,
a system has a life. At some point, it doesn't exist,
it's brought into being, it's used, and then it's dispersed
off once we can no longer use it for the purpose for which it's created. Throughout
the life of the system, therefore, there are a number
of phases and activities, each of which builds on the results
of the preceding phase of activity. Now, the sum of all these phases and
activities is called the system lifecycle, which can be described in a model
that has four very broad phases. It starts with the conceptualization
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. It's then 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 last level 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 they're 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, business
requirements, stakeholder requirements, and system requirements. We also see
shortly that the customer
could 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 utilisation phase. The system is operated during the
utilisation 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 has become expensive but 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 can no longer can do what the
organization requires of it, or it does, but it's 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 lifecycle at the retirement phase will
most likely also mark the start of another lifecycle 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 organization. They're managed by enterprise management,
who set the direction for the organization and
pass the tasks to business management, who are responsible for the activities
that are conducted by the operations element of the organization run while 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 a 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 logistics support. The operators who do the business in
the organization are supported 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 are many others in
the organization who also have a stake in a 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 organisation. 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 then also call the developer. The supplier or the developer may be
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 development
in order to support the system. But it's increasingly
common these days for the supply of the 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
contractor varies with each sort of project, but for each project,
the relationships defined by the terms and conditions of a contract
between the two parties. In many cases, the contractor themselves
are not able to perform all the work and devolves the packages of work into
a number of subcontracts delivered by subcontractors. The terms and conditions
relating to this
work are then in a relevant subcontract. Responsibility for the various phases of
the system lifecycle is spread across the enterprise or the organization within
which the eventual system will operate. The initial pre acquisition
phase is clearly responsible for enterprise management, who conduct
the early business planning and establish the business case for the projects that
require to support the organization. Their work's not over, though they must
stay engaged 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 expend organizational resources
on acquiring the system. The project manager will be
principally responsible for the acquisition and may be engaged for
the other lifecycle phases as well. Working for the project manager
is systems engineering. Now, system engineering is
an important discipline, responsible to the project manager 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 provided essential input
to the system engineering and the project management processes, but
now they're principally responsible. 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.