SELF STUDY

SOFTWARE ENGINEERING

Submitted by:
Manisha S K
Section B
USN: 4NM16IS050
Q.1) Explain system engineering for air traffic control system
example.

Systems engineering is the activity of specifying, designing, implementing, validating,

deploying and maintaining socio-technical systems. Systems engineers are not just
concerned
with software but also with hardware and the system's interactions with users
and its environment.

1. Limited scope for rework during system development : Once some system
engineering
decisions, such as the siting of base stations in a mobile phone system,
have been made, they are very expensive to change. Reworking the system design
to solve these problems is rarely possible. One reason software has become so
important in systems is that it allows changes to be made during system development,
in response to new requirements.

2. Interdisciplinary involvement: Many engineering disciplines may be involved

in system engineering. There is a lot of scope for misunderstanding because
different engineers use different terminology and conventions.

Systems engineering is an interdisciplinary activity involving teams drawn from

various backgrounds. System engineering teams are needed because of the wide
knowledge
required to consider all the implications of system design decisions. As an
illustration of this, Figure 2.3 shows some of the disciplines that may be involved
in the system engineering team for an air traffic control (ATC) system that uses
radars and other sensors to determine aircraft position.
For many systems, there are almost infinite possibilities for trade-offs between
different types of sub-systems. Different disciplines negotiate to decide how
functionality
should be provided. Often there is no correct' decision on how a system
should be decomposed. Rather, you may have several possible alternatives, but you
may not be able to choose the best technical solution. Say one alternative in an air
traffic control system is to build new radars rather than refit existing installations.
If the civil engineers involved in this process do not have much other work, they
may favour this alternative because it allows them to keep their jobs. They may
then rationalise this choice with technical arguments.

Q. 2) Explain the system procurement process.

The development process interacts with system procurement process and with the
process of using and operating the system.
This is illustrated in Figure 2.9.

The procurement process is normally embedded within the organisation that will
buy and use the system (the client organisation). The process of system procurement
is concerned with making decisions about the best way for an organisation to
acquire a system and deciding on the best suppliers of that system.
Large complex systems usually consist of a mixture of off-the-shelf and specially
built components. One reason why more and more software is included in systems
is that it allows more use of existing hardware components, with the software acting
as a 'glue' to make these hardware components work together effectively. The
need to develop this 'glue ware' is one reason why the savings from using off-the shelf
components are sometimes not as great as anticipated.

Figure 3 shows the procurement process for both existing systems and systems
that have to be specially designed. Some important points about the process
shown in this diagram are:
1. Off-the-shelf components do not usually match requirements exactly, unless the
requirements have been written with these components in mind. Therefore, choosing
a system means that you have to find the closest match between the system
requirements and the facilities offered by off-the-shelf systems. You may
then have to modify the requirements and this can have knock-on effects on
other sub-systems.
2. When a system is to be built specially, the specification of requirements acts
as the basis of a contract for the system procurement. It is therefore a legal, as
well as a technical, document.
3. After a contractor to build a system has been selected, there is a contract negotiation
period where you may have to negotiate further changes to the requirements
and discuss issues such as the cost of changes to the system.

fig.3 The system procurement process

Q. 3) Explain rational unified process

The Rational Unified Process (RUP) is an example of a modern process model that
has been derived from work on the UML and the associated Unified Software
Development Process.
The RUP recognises that conventional process models present a single view of
the process. In contrast, the RUP is normally described from three perspectives:
I. A dynamic perspective that shows the phases of the model over time.
2. A static perspective that shows the process activities that are enacted.
3. A practice perspective that suggests good practices to be used during the process.
Fig.4 Phases in Rational Unified Process

1. Inception: The goal of the inception phase is to establish a business case for the
system. You should identify all external entities (people and systems) that will
interact with the system and define these interactions. You then use this
information
to assess the contribution that the system makes to the business. If this
contribution is minor, then the project may be cancelled after this phase.

2. Elaboration : The goals of the elaboration phase are to develop an understanding

of the problem domain, establish an architectural framework for the system,
develop the project plan and identify key project risks. On completion of
this phase. you should have a requirements model for the system (UML use
cases are specified), an architectural description and a development plan for
the software.

3. Construction The construction phase is essentially concerned with system

design, programming and testing. Parts of the system are developed in parallel
and integrated during this phase. On completion of this phase, you should
have a working software system and associated documentation that is ready for
delivery to users.

4. Transition The final phase of the RUP is concerned with moving the system
from the development community to the user community and making it work
in a real environment. This is something that is ignored in most software process
models but is, in fact, an expensive and sometimes problematic activity.
On completion of this phase, you should have a documented software system
that is working correctly in its operational environment.

Q. 4) Explain non-functional requirement in detail with a

diagram.
Non-functional requirements, as the name suggests, are requirements that are not
directly concerned with the specific functions delivered by the system. They may
relate to emergent system properties such as reliability, response time and store
occupancy.
Alternatively, they may defll1e constraints on the system such as the capabilities
Of I/O devices and the data representations used in system interfaces.
The types of non-functional requirements are:
1. Product requirements : These requirements specify product behaviour.
Examples include performance requirements on how fast the system must execute
and how much memory it requires; reliability requirements that set out the
acceptable failure rate; portability requirements; and usability requirements.

2. Organisational requirements : These requirements are derived from policies and

procedures in the customer s and developer s organisation. Examples include
progress standards that must be used; implementation requirements such as the
programming language or design method used; and delivery requirements that
specify when the product and :Its documentation are to be delivered.
3. External requirements : These broad heading covers all requirements that are
derived
from factors external to the system and its development process. These may
include interoperability requirements that define how the system interacts with
systems in other organisations: legislative requirements that must be followed
to ensure that the system operates within the law; and ethical requirements. Ethical
requirements are requirements placed on a system to ensure that it will be acceptable
to its users and the general public.
Non-functional requirements such as safety and security requirements are particularly
important for critical systems.
Figure 5 is a classification of non-functional
requirements. You can see from this diagram that the non-functional requirements
may come from required characteristics of the software (product requirements), the
organization developing the software (organizational requirements) or from external
sources.
Fig.5 Types of non-functional requirement

Q. 5) Explain ethnography with a diagram.

Ethnography is an observational technique that can be used to understand social

and organisational requirements. An analyst immerses him or herself in the working
environment where the system will be used. He: or she observes the day-to-day
work and notes made of the actual tasks in which participants are involved. The
value of ethnography is that it helps analysts discover implicit system requirements
that reflect the actual rather than the formal processes in which people are involved.

Ethnography is particularly effective at discovering two types of requirements:

I. Requirements that are derived from the way in which people actually work rather
than the way in which process definitions say they ought to work. For example,
air traffic controllers may switch off an aircraft conflict alert system that
detects aircraft with intersecting flight paths even though normal control procedures
specify that it should be used. Their control strategy is designed to ensure
that these aircraft are moved apart before problems occur and they find that
the conflict alert alarm distracts them from their work.

2. Requirements that are derived from cooperation and awareness of other people's
activities. For example, air traffic controllers may use an awareness of other
controllers' work to predict the number of aircraft that will be entering their control
sector. They then modify their control strategies depending on that predicted
workload. Therefore, an automated ATC system should allow controllers in a sector
to have some visibility of the work in adjacent sectors.

Fig 6: Ethnography and prototyping for requirement analysis

Ethnography may be combined with prototyping (Figure 6). The ethnography

informs the development of the prototype so that fewer prototype refinement cycles
are required. Furthermore, the prototyping focuses the ethnography by identifying
problems and questions that can then be discussed with the ethnographer. He or she
should then look for the answers to these questions during the next phase of the
system study.
Ethnographic studies can reveal critical process details that are often missed by
other requirements elicitation techniques. However, because of its focus on the end
user,
this approach is not appropriate for discovering organisational or domain
requirements. Ethnographic studies cannot always identify new features that should
be added to a system. Ethnography is not, therefore, a complete approach to
elicitation
on its own, and it should be used to complement other approaches, such as
use-case analysis.