SOFTWARE ENGINEERING(COMP284, COMP284A and COMP584)

IOAN DESPI

January 17, 2005

Welcome to Software Engineering

Welcome to comp284, comp284A, comp584! Here you are some vital statistics:Lecturer: Ioan Despi

e-mail: comp284@turing.une.edu.au

office: 107 Booth Block

phone: (02) 6773 2513

fax: (02) 6773 3312

school: (02) 6773 2298

unit www: http://mcs.une.edu.au/~comp284/

lecturer www: http://mcs.une.edu.au/~despi/

Tutor: Serge Bgeholz

e-mail: comp284@turing.une.edu.au

office: B262 Booth Block

phone: (02) 6773 3692

fax: (02) 6773 3312

Consultation times:

09:00am - 11:00am Tuesday

09:00am - 10:00pm Wednesday

09:00am - 11:00pm Friday

Administrative Details

Unit Title: Software Engineering

Unit Code: comp284

Semester: 2, 2005

1

Aims & Prerequisites

This unit introduces students to the software engineering issues. SE is an engineeringdiscipline whose goal is the cost-effective development of software systems. SE aims to findanswers to the many problems that software development projects are likely to meet whenconstructing large software systems.

There will be lecture notes appearing on the web & the Internet as the unit proceeds.So you should pay close attention to the comp284 web pages on turing.

Textbooks:

1. Ian Sommerville - Software Engineering. Addison Wesley, 7th edition, 2004

Recommended Readings

2. Eric J. Braude - Software Engineering. An Object-Oriented Perspective. John Wiley &sons, 20013. Daniel H. Steinberg, Daniel W. PAlmer - Extreme Software Engineering. A hands-OnApproach. Pearson Prentice Hall, 20044. James F. Peters, Witold Pedrycz - Software Engineeering. An Engineering Approach.John Wiley & sons, 20005. Hans van Vliet - Software Engineering. Priciples and Practice. John Wiley & sons,20016. Martin Fowles - UML Distilled. Addison Wesley, 3rd ed, 20047. Bell S., Wood-Harper T. - Rapid Information Systems Development. 2nd ed., McGrawHill, 19988. Bennett S., McRobb S., Farmer R. -Object-Oriented System Analysis and Design UsingUML. McGraw Hill, 19999. Reiss S. P. - A Practical Introduction to Software design with C++. John Wiley & Sons,199910. Sikora Z. M. - Java-Practical Guide for Programmers. Morgan Kaufmann, 200311. Spivey J. M. - The Z Notation: A Reference manual. 2nd ed., Oxford press, 199812. Wieringa R. J. -Design Methods for Reactive Systems. Morgan Kaufmann, 2003

How this Unit will be Run

The very first thing you should do if you are taking this unit is mail a message tocomp284@turing.une.edu.au from your turing account. If the computer account whereyou wish to receive electronic announcements is different from your turing account, youshould create a file called .forward into your turing account and populate it with yourprefered address(es).

2

The next thing you should do is check out either the ~comp284 directory or the comp284web page. This is where (if you are external & don’t attend lectures) everything thathappens in this unit will take place. I’ll describe the comp284 directory here, the web pageis structured in an analagous fashion. In the comp284 directory there will be subdirectoriescalled:

Lectures-v6. This is where the lecture notes from the 6th edition are stored.

Lectures-v7. This is where the lecture notes (7th edition of the textbook) will appear.

Tutorials. This is where brief descriptions of what went on in tutorials will appear. Afterthe tutorials have taken place I will also place solutions here.

Assignments. This is where assignments will appear.

Solutions. This is where solutions to the assignments, and projects, will appear.

Papers-of-Interest. This is where I will put postscript versions of papers that I feel areof general interest.

Bulletin Board. This is where you can exchange oppinions with your mates (concerningthe subject).

Unit Links. This is where you can find links to suplimentary/alternative materials.

Most important announcements will be made via the mailing list that I will set up.

Assignments, Projects & Assessment

To pass the unit itself, a student

must submit all 6 (7) assignments AND

must obtain at least 50% (that is, 30 (35) marks) in the programming part of theunit, AND

must obtain at least 50% in the exam part of the unit.

1. Students enrolled in comp284 have six assignments.

There will be 6 programming assignments, marked from 1 to 10, and worthtogether 50 % from the final mark.

The exam is worth 50% from the final mark.

Deadlines will be extended on medical grounds.

Otherwise late submissions will attract a penalty of 10% per day late and willnot be marked at all (0 marks) if more than seven days late.

3

The assignments must be submitted using the electronic submit facility. Allprogramming assignments must be compilable on turing.

2. Students enrolled in comp284A and comp584 have seven assignments.

There will be 7 programming assignments, marked from 1 to 10, and worthtogether 50 % from the final mark.

The exam is worth 50% from the final mark.

Deadlines will be extended on medical grounds.

Late assignments will attract a penalty of 10% per day late and will not bemarked (you’ll get 0 marks) if more than seven days late, unless you have re-quested and been granted an extension prior to the due date.

The last one (Assignment 7) can be submitted anytime before the last day ofschool (November 4, 2005).

Notes

In any situation you have to submit the assignment.

To request an extension, you will need to email comp284@mcs.une.edu.au, prior tothe due date, and provide the following:

• your name,

• the assignment for which you seek an extension,

• the grounds for granting an extension, and

• the date you anticipate being able to submit your assignment.

If you do not submit all of the assignments or do not sit the final examination, youwill receive a failed incomplete (NI) grade for the Unit.

PLAGIARISM

Students are warned to read the statement in the Faculty’s Undergraduate and Postgrad-uate Handbooks for 2003 regarding the University’s Policy on Plagiarism. Full details ofthe Policy on Plagiarism are available in the UNE Handbook and at the following site:http://www.une.edu.au/offsect/policies.htm

In addition, you must complete the Plagiarism Declaration Form for all assignments,practical reports, etc. submitted in this unit. For electronic submission of assignments, itis presumed that you have read the web site and have agreed with the conditions so youdon’t have to submit the form .

4

Tentative unit plan – 2005

Week 1 26 July - 31 July IntroductionSocio-technical systemsCritical systems

Week 2 01 - 07 August Software processesProject managementSoftware requirements

Week 3 08 - 14 August Requirements engineering processesSystem models

Week 4 15 - 21 August Critical systems specificationsFormal specifications

Week 5 22 - 28 August Architectural designDistributed system architectures

Week 6 29 August - 04 September Application architecturesObject-oriented design

Week 7 05 - 11 September Real-time software designUser interface design

Week 8 12 - 16 September Rapid software developmentSoftware reuse

Midsemester 17 September -Break 03 OctoberWeek 9 04 - 09 October Component-based software engineering

Critical systems developmentWeek 10 10 - 16 October Software evolution

Verification and validationWeek 11 17 - 23 October Software testing

Critical systems validationWeek 12 24 - 30 october Managing people

Software cost estimationWeek 13 31 October - 04 Nov Quality management

Process improvementConfiguration management

Assignment due datesAssignment 1 comp284, comp284A, comp584 due on August, 10thAssignment 2 comp284, comp284A, comp584 due on August, 24thAssignment 3 comp284, comp284A, comp584 due on September, 7thAssignment 4 comp284, comp284A, comp584 due on October, 5thAssignment 5 comp284, comp284A ,comp584 due on October, 19thAssignment 6 comp284, comp284A, comp584 due on November, 2ndAssignment 7 comp284A, comp584 not after November, 4th

5

Contents

1 Introduction 8

2 Socio-technical Systems 11

3 Critical Systems 14

4 Software Processes 18

5 Project management 23

6 Software Requirements 26

7 Requirements Engineering Processes 30

8 System models 32

9 Critical Systems Specification 36

10 Formal Specification 40

11 Architectural Design 44

12 Distributed Systems Architectures 48

13 Application architectures 52

14 Object-oriented Design 56

15 Real-time Software Design 60

16 User interface design 64

17 Rapid software development 68

18 Software Reuse 72

6

19 Component-based software engineering 76

20 Critical Systems Development 79

21 Software evolution 83

22 Verification and Validation 87

23 Software Testing 90

24 Critical Systems Validation 94

25 Managing people 98

26 Software cost estimation 102

27 Quality Management 104

28 Process Improvement 108

29 Configuration Management 112

7

Chapter 1

Introduction

1.1 Objectives

To introduce software engineering and to explain its importance.

To set out the answers to key questions about software engineering.

To introduce ethical and professional issues and to explain why they are of concernto software engineers.

1.2 Topics covered

FAQs about software engineering

Professional and ethical responsibility

1.3 ACM/IEEE Code of Ethics

The professional societies in the US have cooperated to produce a code of ethical practice.Members of these organisations sign up to the code of practice when they join. The Codecontains eight Principles related to the behaviour of and decisions made by professionalsoftware engineers, including practitioners, educators, managers, supervisors and policymakers, as well as trainees and students of the profession.

1. PUBLIC.

Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER.

Software engineers shall act in a manner that is in the best interests of their clientand employer consistent with the public interest.

8

3. PRODUCT.

Software engineers shall ensure that their products and related modifications meetthe highest professional standards possible.

4. JUDGMENT.

Software engineers shall maintain integrity and independence in their professionaljudgment.

5. MANAGEMENT.

Software engineering managers and leaders shall subscribe to and promote an ethicalapproach to the management of software development and maintenance.

6. PROFESSION.

Software engineers shall advance the integrity and reputation of the profession con-sistent with the public interest.

7. COLLEAGUES.

Software engineers shall be fair to and supportive of their colleagues.

8. SELF.

Software engineers shall participate in lifelong learning regarding the practice of theirprofession and shall promote an ethical approach to the practice of the profession.

1.4 Key points

Software engineering is an engineering discipline that is concerned with all aspectsof software production.

Software products consist of developed programs and associated documentation. Es-sential product attributes are maintainability, dependability, efficiency and usability.

The software process consists of activities that are involved in developing softwareproducts. Basic activities are software specification, development, validation andevolution.

Methods are organised ways of producing software. They include suggestions forthe process to be followed, the notations to be used, rules governing the systemdescriptions which are produced and design guidelines.

9

1.5 Quiz

1. What was the software crisis?

2. What are the two fundamental types of software product?

Generic products that are designed to meet the needs of many different customers.

Customised products designed to meet the specific needs of a single customer.

3. What is software engineering?

4. What are the fundamental activities in software processes?

5. What are the 3 general paradigms of software development?

6. What are the principal components of a software engineering method?

7. What does the acronym CASE stand for?

8. Why is maintainability an important attribute of software?

9. What are three key challenges facing software engineering

10. What is a software engineering code of ethics?

10

Chapter 2

Socio-technical Systems

2.1 Objectives

To explain what a socio-technical system is and the distinction between this and acomputer-based system.

To introduce the concept of emergent system properties such as reliability and secu-rity.

To explain system engineering and system procurement processes.

To explain why the organisational context of a system affects its design and use.

To discuss legacy systems and why these are critical to many businesses.

2.2 Topics covered

Emergent system properties.

Systems engineering.

Organizations, people and computer systems .

Legacy systems.

2.3 System engineering

System engineering is the activity of specifying, designing, implementing, validating,deploying, and maintaining systems as a whole. These include hardware, software andpeople.

11

A system is a purposeful collection of inter-related components working together to-wards some common objective. A system may include software, mechanical, electrical andelectronic hardware and may be operated by people.

System components are dependent on other system component. The properties andbehaviour of system components are inextricably intermingled.

System categories

• Technical computer-based systems. Systems that include hardware and software butwhere the operators and operational processes are not normally considered to be part ofthe system. The system is not self-aware.• Socio-technical systems. Systems that include technical systems but also operationalprocesses and people who use and interact with the technical system. Socio-technicalsystems are governed by organisational policies and rules.

2.4 Key points

Socio-technical systems include computer hardware, software and people and aredesigned to meet some business goal.

Emergent properties are properties that are characteristic of the system as a wholeand not its component parts.

The systems engineering process includes specification, design, development, integra-tion and testing. System integration is particularly critical.

Human and organisational factors have a significant effect on the operation of socio-technical systems.

There are complex interactions between the processes of system procurement, devel-opment and operation.

A legacy system is an old system that continues to provide essential services.

Legacy systems include business processes, application software, support softwareand system hardware.

2.5 Quiz

1. What is the difference between a technical and a socio-technical system?

2. What are emergent properties?

12

3. What are three influences on the reliability of a system?

Hardware reliability

Software reliability

Operator reliability

4. What are the 8 fundamental systems engineering activities?

5. What is a wicked problem?

6. What is involved in systems integration?

7. What human and organisational factors affect the design of a system?

Process changes

Job changes

Organisational changes

8. What is involved in a system procurement process?

9. What are legacy systems?

10. What are the components of a legacy system?

13

Chapter 3

Critical Systems

3.1 Objectives

To explain what is meant by a critical system where system failure can have severehuman or economic consequence.

To explain four dimensions of dependability - availability, reliability, safety and se-curity.

To explain that, to achieve dependability, you need to avoid mistakes, detect andremove errors and limit damage caused by failure.

3.2 Topics covered

A simple safety-critical system

System dependability

Availability and reliability

Safety

Security

3.3 Critical Systems

Safety-critical systems. Failure results in loss of life, injury or damage to the envi-ronment. Example: Chemical plant protection system.

Mission-critical systems. Failure results in failure of some goal-directed activity.Example: Spacecraft navigation system.

14

Business-critical systems. Failure results in high economic losses. Example: Cus-tomer accounting system in a bank.

3.4 Dependability

The dependability of a system equates to its trustworthiness. A dependable system is asystem that is trusted by its users. Principal dimensions of dependability are: Availability;Reliability; Safety; Security.

3.5 Availability and reliability

Reliability: The probability of failure-free system operation over a specified time in agiven environment for a given purpose.Availability: The probability that a system, at a point in time, will be operational andable to deliver the requested services.Both of these attributes can be expressed quantitatively

3.6 Key points

A critical system is a system where failure can lead to high economic loss, physicaldamage or threats to life.

The dependability in a system reflects the user’s trust in that system.

The availability of a system is the probability that it will be available to deliverservices when requested.

The reliability of a system is the probability that system services will be delivered asspecified.

Reliability and availability are generally seen as necessary but not sufficient conditionsfor safety and security.

Reliability is related to the probability of an error occurring in operational use. Asystem with known faults may be reliable.

Safety is a system attribute that reflects the systems ability to operate withoutthreatening people or the environment.

Security is a system attribute that reflects the systems ability to protect itself fromexternal attack.

Dependability improvement requires a socio-technical approach to design where youconsider the humans as well as the hardware and software.

15

3.7 Quiz

1. What are the principal types of critical system?

Safety-critical systems

Mission-critical systems

Business critical systems

2. Why is dependability particularly important for critical systems?

Systems that are unreliable, unsafe or insecure may be rejected by their users.

System failure costs may be very big.

Untrustworthy systems may cause information loss.

3. What are the two most important high-level dependability requirements for the insulinpump?

The system shall be available to deliver insulin when required.

The system shall perform reliably and deliver the correct amount of insulin to coun-teract the current level of blood sugar.

4. What are the principal dependability dimensions?

Availability

Reliability

Safety

Security

5. What is the distinction between reliability and availability?

Reliability is concerned with the correct delivery of system services.

Availability is concerned with the systems operational state. A system can be availablebut unreliable.

6. Explain how an unreliable system can be a high-availability system

If the reliability problems can be solved with a system restart and the restart timeis very short, then recovery from a system failure can be very rapid so the systemavailability is only minimally affected.

16

7. What is the definition of the safety property?

Safety is a system property that reflects its ability to operate, normally or abnormally,without danger of causing human injury or death and without damage to the system’senvironment.

8. What damage can result if a system is insecure?

Denial of service

Corruption of programs or data

Disclosure of confidential information

9. Explain why an insecure system cannot be shown to be dependable.

Availability can be compromised through denial of service attacks

Reliability can be compromised if data is corrupted

Safety can be compromised if the system itself is corrupted and so can behave in anunsafe way.

10. List 5 approaches to development that might be used in critical systems development

Use of formal methods

Separate implementation and testing teams

Redundant code and self-checking in programs

Redundant hardware units

Measurement of test coverage

17

Chapter 4

Software Processes

4.1 Objectives

To introduce software process models.

To describe three generic process models and when they may be used.

To describe outline process models for requirements engineering, software develop-ment, testing and evolution.

To explain the Rational Unified Process model.

To introduce CASE technology to support software process activities.

4.2 Topics covered

Software process models

Process iteration

Process activities

The Rational Unified Process

Computer-aided software engineering

4.3 The software process

A software process is a coherent set of activities for specifying, designing, implementingand testing software systems. It is a structured set of activities required to develop asoftware system. Fundamental activities:

18

• Specification•Design•Validation•EvolutionA software process model is an abstract representation of a process. It presents adescription of a process from some particular perspective.

4.4 Generic software process models

1. The waterfall model. Separate and distinct phases of specification and development.2. Evolutionary development. Specification and development are interleaved.3. Reuse-based development. The system is assembled from existing components.

There are many variants of these models e.g. formal development where a waterfall-likeprocess is used but the specification is a formal specification that is refined through severalstages to an implementable design.

4.5 Key points

Software processes are the activities involved in producing and evolving a softwaresystem.

Software process models are abstract representations of these processes.

General activities are specification, design and implementation, validation and evo-lution.

Generic process models describe the organisation of software processes. Examplesinclude the waterfall model, evolutionary development and component-based softwareengineering.

Iterative process models describe the software process as a cycle of activities.

Requirements engineering is the process of developing a software specification.

Design and implementation processes transform the specification to an executableprogram.

Validation involves checking that the system meets to its specification and user needs.

Evolution is concerned with modifying the system after it is in use.

The Rational Unified Process is a generic process model that separates activities fromphases.

CASE technology supports software process activities.

19

4.6 Quiz

1. What are the fundamental activities that are common to all software processes?

Software specification

Software design and implementation

Software validation

Software evolution

2. List the 3 fundamental software process frameworks that are used to create specificsoftware processes?

The waterfall model

Evolutionary development

Component-based software engineering

3. Why are iterations usually limited when the waterfall model is used?

4. Briefly describe two types of evolutionary development?

Exploratory development where the objective of the process is to work with customersto explore their requirements and deliver a final-system.

Throw-away prototyping where the objective is to develop a better understanding ofthe customers requirements and deliver a better requirements specification.

5. What are the development stages in CBSE?

Component analysis

Requirements modification

System design with reuse

Development and integration

6. What are the advantages of using incremental development and delivery?

Early delivery of critical functionality to the customer

Early increments serve as prototypes to explore requirements

20

Lower risk of overall project failure

More extensive testing of critical customer functionality

7. What are the 4 sectors in each loop in Boehm’s spiral model?

Objective setting

Risk assessment and reduction

Development and validation

Planning

8. What are the principal requirements engineering activities?

Feasibility study

Requirements elicitation and analysis

Requirements specification

Requirements validation

9. What models might be developed when applying a structured method?

An object model

A sequence model

A state transition model

A structural model

A data-flow model

10. What are the three important stages in the testing process?

Component (or unit) testing

System or integration testing

Acceptance testing

11. Why is it increasingly irrelevant to distinguish between software development andevolution?

21

12. What are the 4 phases of the Rational Unified Process?

Inception

Elaboration

Construction

Transition

13. What are the six fundamental best practices in the RUP?

Develop software iteratively

Manage requirements

Use component-based architectures

Visually model software

Verify software quality

Control changes to software

14. Give 5 examples of activities that can be automated using CASE

Graphical system modelling

Maintaining a data dictionary

Generating user interfaces

Program debugging

Translating programs from one language to another

15. What is the distinction between a CASE tool and a CASE workbench?

22

Chapter 5

Project management

5.1 Objectives

To explain the main tasks undertaken by project managers.

To introduce software project management and to describe its distinctive character-istics.

To discuss project planning and the planning process.

To show how graphical schedule representations are used by project management.

To discuss the notion of risks and the risk management process.

5.2 Topics covered

Management activities

Project planning

Project scheduling

Risk management

5.3 Introduction

Project management is the activity of organising, planning and scheduling softwareprojects.Software project management is concerned with activities involved in ensuring thatsoftware is delivered on time and on schedule and in accordance with the requirements ofthe organisations developing and procuring the software.

23

The failure of many large projects in the 60s and 70s was the first indication of thedifficulties of software management.• Software was delivered late• Software was unreliable• Software costed several times the original estimates• Software often exhibited poor performance

The main reason was not the incompetence of managers or programmers, but the ap-plication of management techniques derived from other engineering disciplines. Projectmanagement is needed because software development is always subject to textcolorma-gentabudget and textcolormagentaschedule constraints that are set by the organisationdeveloping the software.

5.4 Risk management

A risk is a probability that some adverse circumstance will occur. Risk management isconcerned with identifying risks and drawing up plans to minimise their effect on a project.Categories of risk:

•Project risks affect schedule or resources.•Product risks affect the quality or performance of the software being developed.•Business risks affect the organisation developing or procuring the software.

5.5 Key points

Good project management is essential for project success.

The intangible nature of software causes problems for management.

Managers have diverse roles but their most significant activities are planning, esti-mating and scheduling.

Planning and estimating are iterative processes which continue throughout the courseof a project.

A project milestone is a predictable state where a formal report of progress is pre-sented to management.

Project scheduling involves preparing various graphical representations showing projectactivities, their durations and staffing.

Risk management is concerned with identifying risks which may affect the projectand planning to ensure that these risks do not develop into major threats.

24

5.6 Quiz

1. What are important differences between software project management and other typesof project management?

The product (software) is intangible.

There are no standard software processes

Large software projects are often one-off projects.

2. List 5 common project management activities.

3. What is included in a quality plan and a validation plan?

Quality plan: The quality procedures and standards that should be used in a project

Validation plan: The approach, resources and schedule used for system validation.

4. What is the difference between a milestone and a deliverable?

5. What is involved in project scheduling?

6. Explain how bar charts and activity networks give different views of a project schedule.

7. What are three related categories of risk?

Project risks,

Product risks

Business risks

8. Suggest 4 risks that may threaten the success of a software project?

9. Give 2 examples of technology risks that may arise in a software project.

The system database cannot process as many transactions as expected;

Reused software components are defective.

10. What is involved in risk monitoring?

25

Chapter 6

Software Requirements

6.1 Objectives

To introduce the concepts of user and system requirements.

To describe functional and non-functional requirements.

To explain how software requirements may be organised in a requirements document.

6.2 Topics covered

Functional and non-functional requirements

User requirements

System requirements

Interface specification

The software requirements document

6.3 Requirements engineering

Requirements engineering is the process of establishing the services that the customerrequires from a system and the constraints under which it operates and is developed.

The requirements are the descriptions of the system services and constraints thatare generated during the requirements engineering process.

26

6.4 The requirements document

The requirements document is the official statement of what is required of the systemdevelopers. Should include both a definition and a specification of requirements. It isNOT a design document. As far as possible, it should set of WHAT the system should dorather than HOW it should do it. Users of a requirements document range from the seniormanagers to the responsibles for developing the software.

6.4.1 IEEE requirements standard

There are there a lot of standards for requirements document.

The most widely known standard is IEEE/ANSI 830-1988.

1. Introduction

2. General description

3. Specific requirements

4. Appendices

5. Index

This is a generic structure that must be instantiated for specific systems.

6.5 Key points

Requirements set out what the system should do and define constraints on its oper-ation and implementation.

Functional requirements set out services the system should provide.

Non-functional requirements constrain the system being developed or the develop-ment process.

User requirements are high-level statements of what the system should do. Userrequirements should be written using natural language, tables and diagrams.

System requirements are intended to communicate the functions that the systemshould provide.

A software requirements document is an agreed statement of the system requirements.

The IEEE standard is a useful starting point for defining more detailed specificrequirements standards.

27

6.6 Quiz

1. What are system requirements?

2. What are user requirements and system requirements?

User requirements are statements in a language that is understandable to a user ofwhat services the system should provide and the constraints under which it operates.

System requirements are more detailed descriptions of the system services and con-straint, written for developers of the system.

3. What is the distinction between functional and non-functional requirements?

4. List 3 types of non-functional requirement?

Product requirements,

Organisational requirements,

External requirements.

5. What is a domain requirement? Give an example.

6. What problems can arise when requirements are written in natural language?

Lack of clarity,

Requirements confusion,

Requirements amalgamation.

7. What is the distinction between the terms shall and should in a user requirementsdocument?

Shall normally indicates a mandatory requirement

Should indicates a desirable but not essential requirement.

8. Why is it impossible to completely separate system requirements and design?

28

The system architecture may have to be designed to structure the requirements speci-fication,

Existing systems constrain the design and these constraints are requirements,

The use of a specific architecture may be a requirement for business or regulatoryreasons.

9. What are the main advantages of using a standard format to specify requirements?

All requirements have the same format so are easier to read,

The definition of form fields mean that writers are less likely to forget to includeinformation

Some automated processing is possible.

10. What are 3 types of interface that may have to be defined in a requirements document?

Procedural interfaces,

Data structures,

Representations of data

11. What is the software requirements document?

12. List the requirements document sections suggested by the IEEE standard.

Introduction

General description

Specific requirements

Appendices

Index

29

Chapter 7

Requirements Engineering Processes

7.1 Objectives

To describe the principal requirements engineering activities

To introduce techniques for requirements elicitation and analysis

To describe requirements validation and the role of requirements reviews

To discuss the role of requirements management in support of other requirementsengineering processes

7.2 Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation

Requirements management

7.3 Requirements Engineering Processes

The goal of the reqirements engineering processes is to create and maintain a systemrequirements document. They are processes used to discover, analyse, and validate systemrequirements. The processes used for RE vary widely depending on the application domain,the people involved, and the organisation developing the requirements.

For all new systems, RE process should start with a feasability study. A feasibilitystudy decides whether or not the proposed system is worthwhile. It is a short focusedstudy that checks: if the system contributes to organisational objectives, if the system can

30

be engineered using current technology and within budget, if the system can be integratedwith other systems that are used.

However, there are a number of generic activities common to all processes:

1. Requirements elicitation

2. Requirements analysis

3. Requirements validation

4. Requirements management

Classification

From a evolution perspective, requirements are divided in:

1. Enduring requirements.

Stable requirements derived from the core activity of the customer organisation.

Example: a hospital will always have doctors, nurses, etc.

May be derived from domain models.

2. Volatile requirements.

Requirements which change during development or when the system is in use.

Example: in a hospital, requirements derived from health-care policy.

7.4 Key points

The requirements engineering process includes a feasibility study, requirements elic-itation and analysis, requirements specification and requirements management.

Requirements elicitation and analysis is iterative involving domain understanding,requirements collection, classification, structuring, prioritisation and validation.

Systems have multiple stakeholders with different requirements.

Social and organisation factors influence system requirements.

Requirements validation is concerned with checks for validity, consistency, complete-ness, realism and verifiability.

Business changes inevitably lead to changing requirements.

Requirements management includes planning and change management.

31

Chapter 8

System models

8.1 Objectives

To explain why the context of a system should be modelled as part of the Require-ments Engineering (RE) process

To describe behavioural modelling, data modelling and object modelling

To introduce some of the notations used in the Unified Modeling Language (UML)

To show how CASE workbenches support system modelling

8.2 Topics covered

Context models

Behavioural models

Data models

Object models

CASE workbenches

8.3 Introduction

User requirements must be written in natural language because they have to be understoodby people who are not technical experts. More detailed system requirements may beexpressed in a more technical way. One widely used technique is to document the systemspecification as a set of system models, that is a graphical representation that describe theproblem to be solved, and the system that is to be developed.

32

8.4 Key points

A model is an abstract view of a system which ignores some system details.

Complentary system models can be developed which present different informationabout the system.

Context models show how the system being modelled is positioned in an environ-ment with other systems and processes.

Architectural models, process models and data-flow models may be used as contextmodels.

Data-flow diagrams may be used to model the data processing carried out by asystem.

• The system is modelled as a set of data transformations with functions actingon the data.

State machine models are used to model a system’s behaviour in response tointernal or external events.

Semantic data models describe the logical structure of the data which is importedto and exported by the system.

• They show system entities, their attributes and the relationships in which theyparticipate.

• They may be supplemented with data dictionaries that provide a more de-tailed description of the data.

Object models describe the logical system entities and their classification and ag-gregation.

• They combine a data model with a processing model.

• One can develop: inheritance models, aggregation models and behavioural mod-els.

CASE workbenches support the development of system models by providing modelediting, checking, repporting and documentation tools.

Sequence models show the interactions between actors and the system objects thatthey use.

Structured methods provide a framework for developing system models.

33

8.5 Quiz

1. What perspectives may be used for system modelling?

An external perspective

A behavioural perspective

A structural perspective.

2. What types of system model may be developed?

Data flow models

Composition models

Architectural models

Classification models

Stimulus/response models

3. What is described in a context model?

4. What is described in a state machine model?

5. What is a semantic data model?

6. What are the components of an object class definition in the UML?

The name of the object class

The attributes of that class

The operations or methods associated with that class

7. What different object models may be developed?

Inheritance models

Object aggregation models

Object behaviour models

34

8. What is shown in an UML sequence model?

9. What is a structured method?

10. List 4 weaknesses of structured methods?

They do not support non-functional requirements modelling

They rarely include guidelines to help users decide if they can be used in a particulararea

They tend to produce too much documentation

The models produced are detailed and often hard to understand

35

Chapter 9

Critical Systems Specification

9.1 Objectives

To explain how dependability requirements may be identified by analysing the risksfaced by critical systems.

To explain how safety requirements are derived from an analysis of hazards and risks.

To explain the derivation of security requirements.

To describe metrics used for reliability specification.

9.2 Topics covered

Risk-driven specification

Safety specification

Security specification

Software reliability specification

9.3 Introduction

We introduced requirements processes and techniques for the development of system speci-fications in previous chapters. In this chapter we will discuss the same issues but concerningcritical (dependable) systems.Definition: Dependable Systems Specification deals with processes and techniques fordeveloping a specification for system availability, reliability, safety and security.Dependability = reliability + availability + safety + security

Reliability = continuity of service

36

Availability = readiness for usage

Safety = no catastrophic consequences

Security = prevention of unauthorized access

9.4 Risk-based analysis

Critical systems specification should be risk-driven. This approach has been widely usedin safety and security-critical systems. The aim of the specification process should be tounderstand the risks (safety, security, etc.) faced by the system and to define requirementsthat reduce these risks.

Risk identification. Identify potential risks that may arise.

Risk analysis and classification. Assess the seriousness of each risk.

Risk decomposition. Decompose risks to discover their potential root causes.

Risk reduction assessment. Define how each risk must be taken into eliminated orreduced when the system is designed.

Levels of risk are:

Intolerable. Must never arise or result in an accident.

As low as reasonably practical (ALARP). Must minimise possibility of hazard givencost and schedule constraints.

Acceptable. Consequences of hazard are acceptable and no extra costs should beincurred to reduce hazard probability.

9.5 Key points

Risk analysis is the basis for identifying system reliability requirements.

Risk analysis is concerned with assessing the chances of a risk arising and classifyingrisks according to their seriousness.

Security requirements should identify assets and define how these should be protected.

Reliability requirements may be defined quantitatively.

Reliability metrics include POFOD, ROCOF, MTTF and availability.

Non-functional reliability specifications can lead to functional system requirementsto reduce failures or deal with their occurrence.

37

9.6 Quiz

1. Describe the three types of dependability requirement?

Exclusion requirements that define undesirable situations to be avoided

Functional requirements that protect against system failure

Non-functional requirements that define levels of availability and reliability

2. What is risk-based specification?

3. What activities are part of the process of risk analysis?

Risk identification,

Risk analysis and classification

Risk decomposition

Risk reduction assessment.

4. What are the risk classes that are normally used in critical systems?

Intolerable

As low as reasonably practical (ALARP)

Acceptable

5. What are the three possible strategies that can be used for risk reduction?

Risk avoidance,

Risk detection and removal

Damage limitation.

6. What are safety integrity requirements?

7. List 4 types of security requirement.

identification requirements,

authentication requirements,

38

authorisation requirements,

immunity requirements,

integrity requirements,

intrusion detection requirements,

non-repudiation requirements,

privacy requirements,

security auditing requirements,

system maintenance,

security requirements

8. Under what circumstances would Mean Time to Failure be an appropriate reliabilitymetric?

9. What measurements may be made when assessing the reliability of a system?

The number of system failures that occur in a given period or for a given number ofservice requests

The time between system failures

The elapsed repair or restart time.

10. What are the steps involved in establishing a reliability specification?

Identify the types of system failure that may occur and the consequences of failure

Partition failures into appropriate classes

For each failure class, define the reliability requirements using an appropriate metric

39

Chapter 10

Formal Specification

10.1 Objectives

To explain why formal specification techniques help discover problems in systemrequirements.

To describe the use of algebraic techniques for interface specification.

To describe the use of model-based techniques for behavioural specification.

10.2 Topics covered

Formal specification in the software process

Sub-system interface specification

Behavioural specification

10.3 Introduction

Formal specifications are techniques for the unambiguous specification of software. For-mal specification is part of a more general collection of techniques that are known as formalmethods. These are all based on mathematical representation and analysis of software.Formal methods include:

Formal specification

Specification analysis and proof

Transformational development

Program verification

A formal software specification is a specification expressed in a language whose vo-cabulary, syntax, andi semantics are formally defined. The specification language must be

40

based on mathematical concepts. Ussully, it is used discrete mathematics, and the conceptscome from set theory, logic and algebra.

Formal specification involves investing more effort in the early phases of software de-velopment. This reduces requirements errors as it forces a detailed analysis of the require-ments. Incompleteness and inconsistencies can be discovered and resolved. Hence, savingsas made as the amount of rework due to requirements problems is reduced.

10.4 Specification techniques

Thre are two approaches to formal specification that have been used to write detailedspecifications for non-trivial software systems:1. Algebraic approach. The system is specified in terms of its operations and theirrelationships.2. Model-based approach. The system is specified in terms of a state model that isconstructed using mathematical constructs such as sets and sequences. Operations aredefined by modifications to the system’s state.

Sequential ConcurrentAlgebraic Larch Lotos

(Guttag et.al. 1985,1993)

OBJ (Bolognesi et. al. 1987)

(Futatsugi et.al. 1985)

Model-based Z (Spivey, 1992) CSP (Hoare, 1985)VDM (Jones, 1980) Petri NetsB (Wordsworth, 1996) (Peterson, 1981)

10.5 Key points

Formal system specification complements informal specification techniques.

Formal specifications are precise and unambiguous. They remove areas of doubt ina specification.

Formal specification forces an analysis of the system requirements at an early stage.Correcting errors at this stage is cheaper than modifying a delivered system.

Formal specification techniques are most applicable in the development of criticalsystems and standards.

Algebraic techniques are suited to interface specification where the interface is definedas a set of object classes.

Model-based techniques model the system using sets and functions. This simplifiessome types of behavioural specification.

Operations are defined in a model-based spec. by defining pre and post conditionson the system state.

41

10.6 Quiz

1. Suggest 4 reasons why formal specification is not widely used?

Other software engineering techniques have been effective.

Time to market is now often more important than software quality.

The scope of formal methods is limited.

Formal methods do not scale to large-system development.

2. How does the profile of software development costs change when formal specification isused?

Costs are front-loaded with higher initial specification costs but lower testing andvalidation costs.

3. What are the two fundamental approaches to formal specification that are used?

Algebraic specification

Model-based specification.

4. What should be included in an algebraic specification of an object?

An introduction.

A description part

A signature part

An axioms part

5. What does Tail (Cons (L, v)) = if L = Create then Create else Cons (Tail (L), v)mean?

6. What are the types of operation on an abstract data type?

Constructor operations that create or modify instances

Inspection operations that evaluate attributes.

7. What is model-based specification?

42

8. What are the components of a Z schema?

A schema name

A schema signature

A schema predicate

9. In the insulin pump state description (Figure 10.10), explain the first 3 invariants inthe INSULIN PUMP STATE schema predicate?

The variable r2 is always equal to the current insulin reading

The dose delivered must be less than or equal to the available insulin

The amount of insulin available is always less than or equal to the reservoir capacity

10. Write a predicate that might be added to INSULIN PUMP STATE that specifies thatthe system can only operate if the hardware is operating properly and an insulin reservoiris properly inserted

HardwareTest? = OK

InsulinReservoir = present

43

Chapter 11

Architectural Design

11.1 Objectives

To introduce architectural design and to discuss its importance.

To explain the architectural design decisions that have to be made.

To introduce three complementary architectural styles covering organisation, decom-position and control.

To discuss reference architectures are used to communicate and compare architec-tures.

11.2 Topics covered

Architectural design decisions

System organisation

Decomposition styles

Control styles

Reference architectures

11.3 Introduction

Architectural Design aims to establish the overall structure of a software system. Thedesign process for identifying the sub-systems making up a system and the framework forsub-system control and communication is architectural design. The output of this designprocess is a description of the software architecture. Architectural design is an early stage ofthe system design process. It represents the link between specification and design processes.

44

Often carried out in parallel with some specification activities. It involves identifying majorsystem components and their communications. Architectural design is a creative processso the process differs depending on the type of system being developed. However, a numberof common decisions span all design processes.

11.4 Architectural models

The output of the architectural design is an architectural design document. Differentarchitectural models may be produced during the design process. Each model presentsdifferent perspectives on the architecture:

Static structural model that shows the major system components.

Dynamic process model that shows the process structure of the system.

Interface model that defines sub-system interfaces.

Relationships model such as a data-flow model.

Distribution model that shows how sub-systems are distributed across computers.

11.5 Key points

The software architecture is the fundamental framework for structuring the system.

Architectural design decisions include decisions on the application architecture, thedistribution and the architectural styles to be used.

Different architectural models such as a structural model, a control model and adecomposition model may be developed.

System organisational models include repository models, client-server models andabstract machine models.

Modular decomposition models include object models and pipelining models.

Control models include centralised control and event-driven models.

Reference architectures may be used to communicate domain-specific architecturesand to assess and compare architectural designs.

45

11.6 Quiz

1. What are the advantage of explicitly designing and documenting a software architecture?

It improves stakeholder communications

It encourages a detailed analysis of the system

It helps with large-scale reuse.

2. What non-functional requirements may be influenced by the choice of system architec-ture?

Performance

Security

Safety

Availability

Maintainability

3. List 4 fundamental questions that should be addressed in architectural design?

Is there a generic application architecture that can be used?

How will the system be distributed?

What architectural style or styles are appropriate?

How should the system be structured?

What control strategy should be used?

4. What architectural models may be developed?

A static structural model

A dynamic process model

An interface model

Relationship models

A distribution model

5. What is the fundamental characteristic of a repository model?

46

6. How is the system organised in a client-server model?

7. What are the two principle styles used for modular decomposition?

Object-oriented decomposition

Function-oriented pipelining

8. Briefly describe function-oriented pipelining?

9. What are the two main types of event-driven control models?

Broadcast models where an event is broadcast to all sub-systems

Interrupt-driven models where external events are detected and processed by an in-terrupt handler.

10. What is a reference architecture?

47

Chapter 12

Distributed Systems Architectures

12.1 Objectives

To explain the advantages and disadvantages of distributed systems architectures.

To describe different approaches to the development of client-server systems.

To explain the differences between client-server and distributed object architectures.

To describe object request brokers and the principles underlying the CORBA stan-dards.

To introduce peer-to-peer and service-oriented architectures as new models of dis-tributed computing.

12.2 Topics covered

Multiprocessor architectures

Client-server architectures

Distributed object architectures

Inter-organisational computing

12.3 Introduction

Distributed Systems Architecture is architectural design for software that executes onmore than one processor. Virtually all large computer-based systems are now distributedsystems. Information processing is distributed over several computers rather than confinedto a single machine. Distributed software engineering is now very important.

48

System types

1. Personal systems.They are not distributed and are designed to run on a personalcomputer or workstation.

2. Embedded systems. They run on a single processor or on an integrated group ofprocessors.

3. Distributed systems. The system software runs on a loosely integrated group ofcooperating processors linked by a network.

Distributed systems archiectures

1. Client-server architectures. Distributed services which are called on by clients.Servers that provide services are treated differently from clients that use services.

2. Distributed object architectures. No distinction between clients and servers.Any object on the system may provide and use services from other objects.

12.4 Key points

Distributed systems support resource sharing, openness, concurrency, scalability,fault tolerance and transparency.

Client-server architectures involve services being delivered by servers to programsoperating on clients.

User interface software always runs on the client and data management on the server.Application functionality may be on the client or the server.

In a distributed object architecture, there is no distinction between clients andservers.

Distributed object systems require middleware to handle object communications andto add and remove system objects.

The CORBA standards are a set of middleware standards that support distributedobject architectures.

Peer to peer architectures are decentralised architectures where there is no distinctionbetween clients and servers.

Service-oriented systems are created by linking software services provided by differentservice suppliers.

49

12.5 Quiz

1. List 5 advantages of using a distributed approach to software development.

Resource sharing,

Openness,

Concurrency,

Scalability,

Fault tolerance

2. What are the two generic types of distributed systems architecture that are widely used?

Client-server architectures

Distributed object architectures

3. Briefly descibe the thin-client and fat client models.

Thin-client: All application processing and data management is carried out by theserver. The client runs the presentation software.

Fat client: The server is responsible for data management with all other functionalitythe responsibility of the client.

4. What is the biggest disadvantage of the thin-client model?

5. What is mobile code and how does it help share the processing load between client andserver?

Decentralised systems where computations may be carried out by any node on thenetwork, with no distinction between clients and servers.

6. When would you recommend the use of a 3-tier client-server architecture?

In large-scale applications with hundreds of clients

In applications where the the data and the application are volatile

In applications where data from multiple sources are used.

7. List 3 advantages of using a distributed object architecture.

50

Decisions on where services are provided may be delayed

New resources can easily be added to the system

The system is flexible and scaleable

Dynamic system reconfiguration is possible.

8. What is CORBA?

9. How are object request brokers normally implemented?

10. List 3 types of generic CORBA services?

Naming and trading services

Notification services

Transaction services

11. What are peer-to-peer systems?

12. What is a web service?

13. List 3 crucial differences between a web service architecture and a distributed objectarchitecture.

Services can be offered by any provider inside or outside of the organisation.

The service provider makes service information public.

Applications can delay the binding of services until they are deployed or until execu-tion.

14. What standards have been defined to enable communications between web services?

SOAP – simple object access protocol

WSDL – Web Services Description Language

UDDI – Universal Description, Discovery, Integration.

51

Chapter 13

Application architectures

13.1 Objectives

To explain the organisation of two fundamental models of business systems - batchprocessing and transaction processing systems

To describe the abstract architecture of resource management systems

To explain how generic editors are event processing systems

To describe the structure of language processing systems

13.2 Topics covered

Data processing systems

Transaction processing systems

Event processing systems

Language processing systems

13.3 Introduction

Application systems are designed to meet an organisational need. As businesses have muchin common, their application systems also tend to have a common architecture that reflectsthe application requirements. A generic architecture is configured and adapted to create asystem that meets specific requirements.

E-commerce systems are Internet-based resource management systems that acceptelectronic orders for goods or services. They are usually organised using a multi-tier archi-tecture with application layers associated with each tier.

52

Event processing systems respond to events in the system’s environment. Their keycharacteristic is that event timing is unpredictable so the architecture has to be organisedto handle this. Many common systems such as word processors, games, etc. are eventprocessing systems.

Application types

Data processing applications. Data driven applications that process data inbatches without explicit user intervention during the processing.

Transaction processing applications. Data-centred applications that processuser requests and update information in a system database.

Event processing systems. Applications where system actions depend on inter-preting events from the system’s environment.

Language processing systems. Applications where the users intentions are speci-fied in a formal language that is processed and interpreted by the system.

13.4 Key points

Generic models of application architectures help us understand and compare appli-cations.

Important classes of application are data processing systems, transaction processingsystems, event processing systems and language processing system.

Data processing systems operate in batch mode and have an input-process-outputstructure.

Transaction processing systems allow information in a database to be remotely ac-cessed and modified by multiple users.

Event processing systems include editors and real-time systems.

In an editor, user interface events are detected and an in-store data structure ismodified.

Language processing systems translate texts from one language to another and mayinterpret the specified instructions.

53

13.5 Quiz

1. How can generic application architectures be used?

As a starting point for architectural design

As a design checklist

As a way of organising development work

As a means of assessing components for reuse

As a vocabulary for talking about different types of application

2. List 4 broad types of application architecture?

Data processing applications

Transaction processing applications

Event processing applications

Language-processing systems

3. What are the principal components of a batch processing system?

An input component

A processing component

An output component

4.Why are data flow diagrams useful for describing data processing systems?

5. What is a transaction?

6. What are the architectural layers in an information and resource management system?

User interface layer

User communications layer

Information retrieval and modification

Transaction management/database

54

7. What is an event-processing system?

8. What are 3 distinguishing characteristics of editing systems?

They are mostly single-user systems.

They have to provide rapid feedback on simple user actions

Editing sessions are long transactions

9. What are the components of a translator in a language processing system?

A lexical analyser

A symbol table

A syntax analyser

A semantic analyser

A code generator

10. What architectural models or styles may be used to implement a translator?

A data-flow or function-oriented pipelining model

A repository model

55

Chapter 14

Object-oriented Design

14.1 Objectives

To explain how a software design may be represented as a set of interacting objectsthat manage their own state and operations.

To describe the activities in the object-oriented design process.

To introduce various models that describe an object-oriented design.

To show how the UML may be used to represent these models.

14.2 Topics covered

Objects and object classes

An object-oriented design process

Design evolution

14.3 Introduction

OO Design is designing systems using self-contained objects and object classes.OO Designis part of Object-Oriented Development:

1. Object-oriented analysis. OOA is concerned with developing an object model of theapplication domain. The identified objects reflect entities and operations that areassociated with the problem to be solved.

2. Object-oriented design. OOD is concerned with developing an object-oriented sys-tem model to implement requirements.

56

3. Object-oriented programming. OOP is concerned with realising an OOD using anOO programming language such as Java or C++.

Objects are abstractions of real-world or system entities and manage themselves. Objectsare independent and encapsulate state and representation information. System function-ality is expressed in terms of object services. Shared data areas are eliminated. Objectscommunicate by message passing. Objects may be distributed and may execute sequen-tially or in parallel.

Objects are entities in a software system which represent instances of real-world andsystem entities. An object has:

a state = the set of object attributes

a behaviour = the operations associated with the object

The operations associated with the object provide services to other objects (clients) whichrequest services when some computation is required.

Object classes are templates for objects. They may be used to create objects. Theymay inherit attributes and services from other object classes.

Several different notations for describing object-oriented designs were proposed in the1980s and 1990s . The Unified Modeling Language is an integration of these notations.It describes notations for a number of different models that may be produced during OOanalysis and design. It is now a de facto standard for OO modelling.

14.4 Key points

OOD is an approach to design so that design components have their own privatestate and operations.

Objects should have constructor and inspection operations. They provide services toother objects.

Objects may be implemented sequentially or concurrently.

The Unified Modeling Language provides different notations for defining differentobject models.

A range of different models may be produced during an object-oriented design pro-cess. These include static and dynamic system models.

Object interfaces should be defined precisely using e.g. a programming language likeJava.

Object-oriented design potentially simplifies system evolution.

57

14.5 Quiz

1. What are the stages in an object-oriented development process?

Object-oriented analysis

Object-oriented design

Object-oriented programming.

2. What is the distinction between an object and an object class?

3. Briefly describe two types of concurrent object implementation.

Servers: The object is a parallel process with methods corresponding to the objectoperations. Methods execute in response to external requests

Active objects: The state of the object is changed by internal operations within theobject itself. The process executing these operations runs continuously.

4. List the 5 key stages in an object-oriented design process?

Understand and define the context and use of the system.

Design the system architecture

Identify the principal objects in the system

Develop design models

Specify object interfaces

5. What do you understand by the system context and model of use?

The system context is a static model of the other systems in the environment of thesystem being designed.

The model of use is a dynamic model that describes how the system being designedinteracts with its environment.

6. In the architectural model of the weather station system, what are the three layers inthe software?

The interface layer

The data collection layer

58

The instruments layer

7. List 4 approaches that may be used to identify object classes?

Grammatical analysis identifying nouns and verbs.

Identify tangible things in the application domain.

Use an approach based on the behaviour of the system.

Use scenario-based analysis.

8. Briefly describe three design models that are part of the UML.

Subsystem models that show logical groupings of objects.

Sequence models that show the sequence of object interactions.

State machine models that show state changes in response to events.

9. What is the purpose of interface design in an OO design process?

10. Briefly explain why an OO approach facilitates design evolution?

59

Chapter 15

Real-time Software Design

15.1 Objectives

To explain the concept of a real-time system and why these systems are usuallyimplemented as concurrent processes

To describe a design process for real-time systems

To explain the role of a real-time executive

To introduce generic architectures for monitoring and control and data acquisitionsystems

15.2 Topics covered

System design

Real-time operating systems

Monitoring and control systems

Data acquisition systems

15.3 Introduction

Real-time software design means designing embedded software systems whose behaviouris subject to timing constraints. Real-time systems are systems which monitor andcontrol their environment. Time is critical: RTS must respond within specified times.Inevitably associated with hardware devices

Sensors: Collect data from the system environment.

60

Actuators: Change (in some way) the system’s environment.

Given a stimulus, the system must produce a response within a specified time. Wedistinguish:

1. Periodic stimuli. Stimuli which occur at predictable time intervals.

2. Aperiodic stimuli. Stimuli which occur at unpredictable times.

A real-time system -RTS- is a software system where the correct functioning of thesystem depends on

the results produced by the system, and

the time at which these results are produced.

A software RTS is a system whose operation is degraded if results are not producedaccording to the specified timing requirements. A hardware RTS is a system whoseoperation is incorrect if results are not produced according to the timing specification.Hard-real time systems may have to programmed in assembly language to ensure thatdeadlines are met. Languages such as C allow efficient programs to be written but do nothave constructs to support concurrency or shared resource management. Java supportslightweight concurrency (threads and synchronized methods) and can be used for somesoft real-time systems. Java 2.0 is not suitable for hard RT programming but real-timeversions of Java are now available.

15.4 Key points

Real-time system correctness depends not just on what the system does but also onhow fast it reacts.

A general RT system model involves associating processes with sensors and actuators.

Real-time systems architectures are usually designed as a number of concurrent pro-cesses.

Real-time operating systems are responsible for process and resource management.

Monitoring and control systems poll sensors and send control signal to actuators.

Data acquisition systems are usually organised according to a producer consumermodel.

61

15.5 Quiz

1. What are the two types of stimuli that must be handled in a real-time system?

Periodic stimuli that occur at predictable time intervals.

Aperiodic stimuli that occur irregularly.

2. Briefly explain what you understand by a sensor and an actuator?

A sensor gathers information from a systems environment.

An actuator is a device that changes the environment in some way.

3. Why are state machine models used in real-time software design?

Because most real-time systems are event-driven systems where external events causea transition from one system state to another.

4. List the components of a real-time operating system?

A real-time clock

An interrupt handler

A scheduler

A resource manager

A despatcher

5. What are the actions required in a RTOS to start a process?

Choose process for execution.

Allocate memory and processor.

Start execution on an available processor.

6. Briefly describe the functions of monitoring and control systems?

7. In the notation used, what does a label of 560Hz associated with a process mean?

8. What are the components of the generic architecture of data acquisition systems?

62

Sensor process to handle sensor inputs.

A sensor data buffer for each type of sensor.

A processor for that data.

A display process.

9. Why is a sensor data buffer required in data acquistion systems?

10. Why is the sensor data buffer implemented as a separate thread?

63

Chapter 16

User interface design

16.1 Objectives

To suggest some general design principles for UI design

To explain different interaction styles

To introduce styles of information presentation

To explain when to use graphical and textual information presentation

To explain the principal activities in the user interface design process

To describe the user support which should be built-in to user interfaces

To introduce usability attributes and system approaches to system evaluation

16.2 Topics covered

Design issues

The user interface design process

User analysis

User interface prototyping

Interface evaluation

16.3 Introduction

User Interface refers to the methods and devices that are used to accommodate interac-tion between machines and the human beings who use them (users). UI can take on manyforms, but always accomplish two fundamental tasks:

communicating information from the machine to the user, and

communicating information from the user to the machine.

64

User interfaces should be designed to match the skills, experience and expectations ofits anticipated users. System users often judge a system by its interface rather than itsfunctionality. A poorly designed interface can cause a user to make catastrophic errors.Poor user interface design is the reason why so many software systems are never used.

Human factors in interface design

Limited short-term memory. People can instantaneously remember about 7 items of in-formation. If you present more than this, they are more liable to make mistakes.People make mistakes. When people make mistakes and systems go wrong, inappropriatealarms and messages can increase stress and hence the likelihood of more mistakes.People are different. People have a wide range of physical capabilities. Designers shouldnot just design for their own capabilities.People have different interaction preferences. Some like pictures, some like text.

16.4 Key points

User interface design principles should help guide the design of user interfaces.

Interaction styles include direct manipulation, menu systems form fill-in, commandlanguages and natural language.

Graphical displays should be used to present trends and approximate values. Digitaldisplays when precision is required.

Colour should be used sparingly and consistently.

The user interface design process involves user analysis, system prototyping andprototype evaluation.

The aim of user analysis is to sensitise designers to the ways in which users actuallywork.

UI prototyping should be a staged process with early paper prototypes used as abasis for automated prototypes of the interface.

The goals of UI evaluation are to obtain feedback on how to improve the interfacedesign and to assess if the interface meets its usability requirements.

16.5 Quiz

1. Why is careful user interface design important?

65

2. What are important human issues that should influence UI design?

Limited short-term memory.

The natural tendency of people to make mistakes especially when under stress.

The diverse range of physical capabilities.

People have different interaction preferences.

3. List 6 important principles of user interface design.

User familiarity,

Consistency,

Minimal surprise,

Recoverability,

User guidance,

User diversity

4. What three approaches can be incorporated in a system to support recoverability?

Confirmation of destructive actions.

The provision of an undo facility.

Checkpointing.

5. What are the 5 primary styles of interaction?

Direct manipulation,

Menu selection,

Form fill-in,

Command language,

Natural language.

6. What are the advantages of using analogue rather than digital presentation of informa-tion?

It is easier to get an at a glance impression of the value.

66

The value relative to its maximum and minimum values may be presented.

7. Suggest 5 factors that are important when designing the wording of system messages.

Context,

User experience,

User skill level,

Style of presentation,

Culture.

8. What are the sub-processes in the UI design process?

Analyse and understand user activities,

Produce paper-based design prototype,

Evaluate design with end-users

Produce dynamic design prototype, (and evaluate design)

Implement final user interface.

9. Suggest three approaches that may be used for UI prototyping.

Script-based,

Visual programming,

Internet-based prototyping

10. List 4 techniques of user interface evaluation.

Questionnaire-based evaluation,

observation of users at work,

video snapshots,

software instrumentation.

67

Chapter 17

Rapid software development

17.1 Objectives

To explain how an iterative, incremental development process leads to faster deliveryof more useful software

To discuss the essence of agile development methods

To explain the principles and practices of extreme programming

To explain the roles of prototyping in the software process

17.2 Topics covered

Agile methods

Extreme programming

Rapid application development

Software prototyping

17.3 Introduction

Because of rapidly changing business environments, businesses have to respond to newopportunities and competition. This requires software and rapid development and deliveryis not often the most critical requirement for software systems. Businesses may be willingto accept lower quality software if rapid delivery of essential functionality is possible.

Because of the changing environment, it is often impossible to arrive at a stable, consis-tent set of system requirements. Therefore a waterfall model of development is impracticaland an approach to development based on iterative specification and delivery is the onlyway to deliver software quickly.

68

Characteristics of RAD processes

The processes of specification, design and implementation are concurrent. There is nodetailed specification and design documentation is minimised. The system is developed ina series of increments. End users evaluate each increment and make proposals for laterincrements. System user interfaces are usually developed using an interactive developmentsystem.

Prototyping

Stakeholders find it very difficult to express their real requirements. It’s hard to predicthow a system will affect working practices, how it will interact with other systems, whatuser operations should be automated. Requirements analysis plus systematic reviews ofthe requirements help to reduce the uncertainty. There is no real substitute for trying outa requirement before agreeing to it. This is possible if a system prototype is available. Aprototype is an initial version of a software system. It is used to demonstrate concepts,to try out design options, to find out more about the problem and its solution.

System prototyping is rapid software development to validate requirements. Prototyp-ing is the rapid development of a system. The principal use of system prototypes is tohelp customers and developers understand the requirements for the system. This systemis thrown away when the system specification has been agreed.

17.4 Key points

An iterative approach to software development leads to faster delivery of software.

Agile methods are iterative development methods that aim to reduce developmentoverhead and so produce software faster.

Extreme programming includes practices such as systematic testing, continuous im-provement and customer involvement.

The approach to testing in XP is a particular strength where executable tests aredeveloped before the code is written.

Rapid application development environments include database programming lan-guages, form generation tools and links to office applications.

A throw-away prototype is used to explore requirements and design options.

When implementing a throw-away prototype, start with the requirements you leastunderstand; in incremental development, start with the best-understood require-ments.

69

17.5 Quiz

1. What are the advantages of using an incremental approach to software development?

Accelerated delivery of customer services,

User engagement with the system.

2. What is the key difference between incremental development and prototyping?

Prototyping is intended to help understand the requirements so starts with require-ments that are not well-understood.

3. List 5 important principles of agile methods.

Customer involvement,

Incremental delivery,

People not process,

Embrace change,

Maintain simplicity.

4. What are three important characterictics of extreme programming?

Requirements expressed as scenarios,

Pair programming,

Test-first development.

5. What is test-first development?

6. Briefly describe the advantage of pair programming.

It supports the idea of common ownership and responsibility for the code.

It serves as an informal code review process.

It helps support refactoring.

7. What tools are normally included in a RAD environment?

A database programming language,

70

an interface generator,

links to office applications,

a report generator.

8. What is visual programming?

9. Suggest three ways that a software prototype may be used?

To help with the elicitation and validation of requirements,

To explore software design solutions and support user interface design,

To run back-to-back tests with the implemented system.

10. What were the key benefits of prototyping found in Gordon and Biemans study?

Improved system usability, a closer match to users needs,

Improved system quality, improved maintainability,

Reduced development effort.

71

Chapter 18

Software Reuse

18.1 Objectives

To explain the benefits of software reuse and some reuse problems

To discuss several different ways to implement software reuse

To explain how reusable concepts can be represented as patterns or embedded inprogram generators

To discuss COTS reuse

To describe the development of software product lines

18.2 Topics covered

The reuse landscape

Design patterns

Generator based reuse

Application frameworks

Application system reuse

18.3 Introduction

Design with Reuse means building software from reusable components. In most engi-neering disciplines, systems are designed by composing existing components that have

72

been used in other systems. Software engineering has been more focused on original devel-opment but it is now recognised that to achieve better software, more quickly and at lowercost, we need to adopt a design process that is based on systematic software reuse.

Although reuse is often simply thought of as the reuse of system components, thereare many different approaches to reuse that may be used. Reuse is possible at a range oflevels from simple functions to complete application systems. The reuse landscape coversthe range of possible reuse techniques:

Application system reuse. The whole of an application system may be reused eitherby incorporating it without change into other systems (COTS reuse) or by develop-ing application families. Widely practised as software systems are implemented asapplication families. COTS reuse is becoming increasingly common.

Component reuse. Components of an application from sub-systems to single objectsmay be reused. Now seen as the key to effective and widespread reuse throughcomponent-based software engineering. However, it is still relatively immature.

Object and Function reuse. Software components that implement a single well-defined function may be reused. Common in some application domains (e.g. engi-neering) where domain-specific libraries of reusable functions have been established.

18.4 Key points

Advantages of reuse are lower costs, faster software development and lower risks.

Design patterns are high-level abstractions that document successful design solu-tions.

Program generators are also concerned with software reuse - the reusable conceptsare embedded in a generator system.

Application frameworks are collections of concrete and abstract objects that aredesigned for reuse through specialisation.

COTS product reuse is concerned with the reuse of large, off-the-shelf systems.

Problems with COTS reuse include lack of control over functionality, performance,and evolution and problems with inter-operation.

ERP systems are created by configuring a generic system with information about acustomer’s business.

Software product lines are related applications developed around a common core ofshared functionality.

73

18.5 Quiz

1. List the main benefits of software reuse.

Increased dependability, reduced process risk,

Effective use of specialists, standards compliance,

Accelerated development.

2. List the main problems with software reuse.

Increased maintenance costs,

Lack of tool support,

Not-invented-here syndrome,

Creating and maintaining a component library,

Finding, understanding and adapting components.

3. What key factors should be considered when planning reuse?

The development schedule for the software,

The expected software lifetime,

The background, skills and experience of the development team,

The criticality of the software and its non-functional requirements,

The application domain,

The system delivery platform.

4. What is a design pattern and why are patterns important for reuse?

5. What do Gamma et al. suggest are the four essential elements of a design pattern?

A meaningful name

A description of the problem and when the pattern can be applied

A solution description

A statement of the consequences of applying the pattern.

74

6. What is generator-based reuse?

7. What major software problem is addressed by aspect-oriented software development?

8. What are three possible classes of application framework?

System infrastructure frameworks,

Middleware integration frameworks,

Enterprise application frameworks.

9. What design choices have to be made when reusing COTS products?

Which COTS products offer the most appropriate functionality,

How will data be exchanged between different products,

What features of a product will actually be used.

10. List 4 types of specialisation of software product lines.

Platform specialisation,

Environment specialisation,

Functional specialisation,

Process specialisation.

75

Chapter 19

Component-based softwareengineering

19.1 Objectives

To explain that CBSE is concerned with developing standardised components andcomposing these into applications.

To describe components and component models.

To show the principal activities in the CBSE process.

To discuss approaches to component composition and problems that may arise.

19.2 Topics covered

Components and component models

The CBSE process

Component composition

19.3 Introduction

Component-based software engineering (CBSE) is an approach to software developmentthat relies on reuse. It emerged from the failure of object-oriented development to supporteffective reuse. Single object classes are too detailed and specific.

Components are more abstract than object classes and can be considered to be stand-alone service providers. When a system needs some service, it calls a component to providethat service, without caring about where the component is executed and the programminglanguage used. A component is an independent executable entity that can be made up of

76

one or more executable objects. Components are independent so do not interfere witheach other. Source code is not available so that the component is not compiled with othersystem components. The component interface is published and all interactions are throughthe published interface. The internal state of a component is never exposed (componentimplementations are hidden). Component platforms are shared and reduce developmentcosts.

CBSE essentials

Independent components specified by their interfaces.

Component standards to facilitate component integration.

Middleware that provides support for component inter-operability.

A development process that is geared to reuse.

19.4 Key points

CBSE is a reuse-based approach to defining and implementing loosely coupled com-ponents into systems.

A component is a software unit whose functionality and dependencies are completelydefined by its interfaces.

A component model defines a set of standards that component providers and com-posers should follow.

During the CBSE process, the processes of requirements engineering and systemdesign are interleaved.

Component composition is the process of wiring components together to create asystem.

When composing reusable components, you normally have to write adaptors to rec-oncile different component interfaces.

When choosing compositions, you have to consider required functionality, non-functionalrequirements and system evolution.

19.5 Quiz

1. What are the essential elements of component-based software engineering?

Independent components completely specified by their interfaces.

77

Component standards that facilitate integration,

Middleware for component integration,

A development process geared to component assembly and composition.

2. What is Councill and Heinemans definition of a component?

3. What are the two principal component interfaces?

A provides interface that defines the services provided by the component.

A requires interface that specifies what services must be provided by other com-ponents in the system for correct operation. .

4. What is a component model?

5. Give 6 examples of horizontal services that might be implemented in component modelmiddleware support.

6. Give examples of changes you might make to a component to make it more reusable.

7. What are the stages of the CBSE process?

8. What is component composition? What are three different types of composition?

The process of assembling components to create a system.

Sequential composition, hierarchical composition, additive composition

9. What is the OCL and how is it used?

10. What decisions about design trade-offs may have to be made when composing compo-nents?

What composition is most effective to deliver the functional requirements?

What composition will allow adaptations for future requirements change?

What will be the emergent properties of the composed system?

78

Chapter 20

Critical Systems Development

20.1 Objectives

To explain how fault tolerance and fault avoidance contribute to the development ofdependable systems

To describe characteristics of dependable software processes

To introduce programming techniques for fault avoidance

To describe fault tolerance mechanisms and their use of diversity and redundancy.

20.2 Topics covered

Dependable processes

Dependable programming

Fault tolerance

Fault tolerant architectures

20.3 Introduction

Dependable software development (Critical Systems Development) means program-ming techniques for building dependable software systems. In general, software customersexpect all software to be dependable. However, for non-critical applications, they maybe willing to accept some system failures. Some applications, however, have very highdependability requirements and special programming techniques must be used to achievethis.

There are three complementary approaches to develop dependable software:

79

1. Fault avoidance. The software is developed in such a way that human error isavoided and thus system faults are minimised. The development process is organ-ised so that faults in the software are detected and repaired before delivery to thecustomer.

2. Fault tolerance. The software is designed so that faults in the delivered softwaredo not result in system failure.

3. Fault detection. Verification and validation techniques are used to discover andremove faults in a system before it is deployed.

To ensure a minimal number of software faults, it is important to have

a well-defined software development process, one that does not depend entirely onindividual skills; rather it can be enacted by different people;

a repeatable software development process, and

a lot of verification and validation activities.

20.4 Key points

Dependability in a system can be achieved through fault avoidance, fault detectionand fault tolerance.

The use of redundancy and diversity is essential to the development of dependablesystems.

The use of a well-defined repeatable process is important if faults in a system are tobe minimised.

Some programming constructs are inherently error-prone - their use should be avoidedwherever possible.

Exceptions are used to support error management in dependable systems.

The four aspects of program fault tolerance are failure detection, damage assessment,fault recovery and fault repair.

N-version programming and recovery blocks are alternative approaches to fault-tolerant architectures.

80

20.5 Quiz

1. Briefly describe three complementary strategies for fault management in critical systems.

2. List 4 techniques that should be used if you aim to develop fault-free software.

3. What is model checking?

4. List 5 programming constructs that are potentially error-prone.

5. What is an exception?

An error or an unexpected event that occurs during the execution of a program.

6. List four aspects of fault tolerance.

Fault detection,

Damage assessment,

Fault recovery,

Fault repair

7. Briefly describe two types of fault detection.

Pre-emptive fault detection – detections a fault before a state change is com-mitted.

Retrospective fault detection – detects a fault by analysing the state after ithas been changed.

8. List 3 fault detection and damage assessment techniques that may be used.

The use of coding checks and checksums in data communications and check digits innumeric data.

The use of redundant links in data structures.

The use of watchdog timers in concurrent systems.

81

9. What is the difference between forward and backward error recovery?

10. Briefly describe the two fundamental approaches used to achieve software fault toler-ance.

N-version programming: Multiple versions of the same software are simultaneouslyexecuted and a voting system used to select the output.

Recovery blocks: Different versions of the software are executed in sequence untilan output satisfies a pre-defined acceptance test.

82

Chapter 21

Software evolution

21.1 Objectives

To explain why change is inevitable if software systems are to remain useful

To discuss software maintenance and maintenance cost factors

To describe the processes involved in software evolution

To discuss an approach to assessing evolution strategies for legacy systems

21.2 Topics covered

Program evolution dynamics

Software maintenance

Evolution processes

Legacy system evolution

21.3 Introduction

Software change is inevitable: new requirements emerge when the software is used; thebusiness environment changes; errors must be repaired; new computers and equipment isadded to the system; the performance or reliability of the system may have to be improved.A key problem for organisations is implementing and managing change to their existingsoftware systems.

Organisations have huge investments in their software systems - they are critical busi-ness assets. To maintain the value of these assets to the business, they must be changed andupdated. The majority of the software budget in large companies is devoted to evolvingexisting software rather than developing new software.

83

Program evolution dynamics is the study of the processes of system change. Aftermajor empirical studies, Lehman and Belady proposed that there were a number of lawswhich applied to all systems as they evolved. There are sensible observations rather thanlaws. They are applicable to large systems developed by large organisations. Perhaps lessapplicable in other cases.

21.4 Lehman’s laws

1. Continuing change. A program necessarily must change or become progressively lessuseful.2. Increasing complexity. As an evolving program changes, its structure tends tobecome more complex.3. Large program evolution. Program evolution is a self-regulating process.4. Organisational stability. Over a program’s lifetime, its rate of development isconstant and independent of the resources devoted to the system development.5. Conservation and familiarity. Over a program’s lifetime, the icremental change ineach release is approximately constant.6. Continuing growth. The functionality offered by systems has to continually increaseto maintain user satisfaction.7. Declining quality. The quality of systems will appear to be declining unless theyare adapted to changes in their operational environment.8. Feedback system. Evolution processes incorporate multi-agent, multi-loop feedbacksystems and you have to treat them as feedback systems to achieve significant productimprovement.

21.5 Key points

Software development and evolution should be a single iterative process.

Lehman’s Laws describe a number of insights into system evolution.

Three types of maintenance are bug fixing, modifying software for a new environmentand implementing new requirements.

For custom systems, maintenance costs usually exceed development costs.

The process of evolution is driven by requests for changes from system stakeholders.

Software re-engineering is concerned with re-structuring and re-documenting softwareto make it easier to change.

The business value of a legacy system and its quality should determine the evolutionstrategy that is used.

84

1. Why is software evolution important?

2. What are Lehman’s Laws and how were they derived?

A set of laws concerning system change.

They were derived from studies of the growth and evolution of a number of largesoftware systems.

3. What are the three different types of software maintenance?

Maintenance to repair software faults,

Maintenance to adapt the software to a different environment,

Maintenance to add to or modify the systems functionality.

4. What is the distribution of effort across these different maintenance types?

Fault repair 17%,

Software adaptation 18%

Enhanced functionality 65%.

5. What factors should be assessed to understand the relationship between a system andits environment?

The number and complexity of system interfaces,

The number of inherently volatile system requirements,

The business processes in which the system is used.

6. What process metrics can be used to assess maintainability?

Number of requests for corrective maintenance,

Average time required for impact analysis,

Average time taken to implement a change request,

Number of outstanding change requests.

7. What are the stages in the system evolution process and what triggers that process?The process is triggered by change requests. Process stages are:

85

Impact analysis

Release planning

Change implementation

System release

8. What are the principal systems re-engineering activities?

Source code translation,

Reverse engineering,

Program structure improvement,

Program modularisation,

Data re-engineering

9. What are the strategic options for legacy system evolution?

Scrap the system completely,

Leave the system unchanged and continue maintenance,

Re-engineer the system to improve maintainability,

Replace all or part of the system with a new system.

10. List four important factors used to assess applications for evolution.Any four from:

Understandability, Documentation, Data, Performance,

Programming language, Configuration management,

Test data, Personnel skills

86

Chapter 22

Verification and Validation

22.1 Objectives

To introduce software verification and validation and to discuss the distinction be-tween them

To describe the program inspection process and its role in verification and validation

To explain static analysis as a verification technique

To describe the Cleanroom software development process

22.2 Topics covered

Verification and validation planning

Software inspections

Automated static analysis

Cleanroom software development

22.3 Introduction

Verification: Are we building the product right?The software should conform to its specification.

Validation: Are we building the right product?The software should do what the user really requires.

V& V = Assuring that a software system meets a user’s needs. The V & V process is awhole life-cycle process: V&V must be applied at each stage in the software process. Hastwo principal objectives:

87

1. The discovery of defects in a system.

2. The assessment of whether or not the system is usable in an operational situation.

Verification and validation should establish confidence that the software is fit for purpose.This does NOT mean completely free of defects. Rather, it must be good enough for itsintended use and the type of use will determine the degree of confidence that is needed.Within the V&V process, two techniques of system checking and analysis may be used:

1. Software inspections. Concerned with analysis of the static system representation todiscover problems (static verification). May be supplement by tool-based documentand code analysis.

2. Software testing. Concerned with exercising and observing product behaviour (dy-namic verification). The system is executed with test data and its operational be-haviour is observed.

Types of testing

1. Defect testing. Tests designed to discover system defects. A successful defect testis one which reveals the presence of defects in a system.

2. Statistical testing. Tests designed to reflect the frequence of user inputs. Usedfor reliability estimation.

3. Validation testing. Intended to show that the software meets its requirements. Asuccessful test is one that shows that a requirements has been properly implemented.

22.4 Key points

Verification and validation are not the same thing. Verification shows conformancewith specification; Validation shows that the program meets the customer’s needs.

Test plans should be drawn up to guide the testing process.

Static verification techniques involve examination and analysis of the program forerror detection.

Program inspections are very effective in discovering errors.

Program code in inspections is systematically checked by a small team to locatesoftware faults.

Static analysis tools can discover program anomalies which may be an indication offaults in the code.

The Cleanroom development process depends on incremental development, staticvarification and statistical testing.

88

22.5 Quiz

1. What is the distinction between validation and verification?

Validation: Are we building the right product?

Verification: Are we building the product right?

2. What are the two complementary approaches used for checking and analysis?

Software inspections or peer reviews,

Software testing.

3. What are the principal sections included in a test plan?

The testing process, Requirements traceability, Tested items,

Testing schedule, Test recording procedures,

Hardware and software requirements, Constraints.

4. What are the advantages of inspections over testing?

Inspections can discover many errors. In testing, one error may mask another.

Incomplete versions of a system can be inspected.

Inspections can consider broader quality attributes as well as program defects.

5. What are the stages in the software inspection process?

6. List the classes of faults that should be considered in an inspection checklist.

Data faults, Control faults, Input/output faults,

Interface faults, Storage management faults, Exception management faults.

7. What is automated static analysis?

8. What are the main argument for the use of formal specification and verification?

9. Why do formal specification and verification not guarantee reliability?

The specification may not reflect the real requirements of users,

The proof may contain errors,

The proof may assume a usage pattern which is incorrect.

10. What are the 5 key strategies used in cleanroom development?

89

Chapter 23

Software Testing

23.1 Objectives

To discuss the distinctions between validation testing and defect testing.

To describe the principles of system and component testing.

To describe strategies for generating system test cases.

To understand the essential characteristics of tool used for test automation.

23.2 Topics covered

System testing

Component testing

Test case design

Test automation

23.3 Introduction

Defect testing means testing programs to establish the presence of system defects.

1. Component testing. Testing of individual program components. Usually the respon-sibility of the component developer (except sometimes for critical systems). Testsare derived from the developer’s experience.

2. Integration (System) testing. Testing of groups of components integrated to create asystem or sub-system. The responsibility of an independent testing team. Tests arebased on a system specification.

90

Testing process goals

Validation testing. To demonstrate to the developer and the system customer thatthe software meets its requirements; A successful test shows that the system operatesas intended.

Defect testing. To discover faults or defects in the software where its behaviour isincorrect or not in conformance with its specification; A successful test is a test thatmakes the system perform incorrectly and so exposes a defect in the system.

Defect testing

The goal of defect testing is to discover defects in programs before its delivery. A successfuldefect test is a test which causes a program to behave in an anomalous way. Tests showthe presence not the absence of defects. This contrasts with validation testing which isintended to prove that a system meets its specification.

Common approaches for defect testing

1. Black-box testing

2. Equivalence partitioning

3. Structural testing

4. Path testing

23.4 Key points

Testing can show the presence of faults in a system; it cannot prove there are noremaining faults.

Component developers are responsible for component testing; system testing is theresponsibility of a separate team.

Integration testing is testing increments of the system; release testing involves testinga system to be released to a customer.

Use experience and guidelines to design test cases in defect testing.

Interface testing is designed to discover defects in the interfaces of composite com-ponents.

Equivalence partitioning is a way of discovering test cases - all cases in a partitionshould behave in the same way.

Structural analysis relies on analysing a program and deriving tests from this analysis.

Test automation reduces testing costs by supporting the test process with a range ofsoftware tools.

91

23.5 Quiz

1. What are the two complementary goals of the testing process?

To demonstrate that the software meets its requirements

To discover faults or defects in the software.

2. What is a successful defect test?

3. Briefly describe the two distinct phases of system testing.

Integration testing where the components and subsystems making up the systemare integrated and tested. The integration team have access to the source code of thesystem.

Release testing where the version of the system to be released to users is tested.The release testing team treat the system as a black-box while testing.

4. What guidelines does Whittaker suggest for defect testing?

Chose inputs that force all error messages to be generated,

Design inputs that might cause buffers to overflow,

Repeat the same input numerous times,

Force invalid outputs to be generated

Force computation results to be too large or too small.

5.What is the function of stress testing?

To test the failure behaviour of the system,

To stress the system and bring defects to light that might not normally be discovered.

6. What tests should be included in object class testing?

Tests for all operations in isolation,

Tests that set and access all object attributes,

Tests that force the object into all possible states.

7. What are the three important classes of interface errors?

92

Interface misuse,

Interface misunderstanding,

Timing errors.

8. What three approaches may be used when designing test cases?

Requirements-based testing where test cases are designed from the requirements.

Partition testing where input and output partitions are identified and tested.

Structural testing where knowledge of the programs structure is used to design tests.

9. What is an equivalence partition? Give an example.

10. What is path testing?

93

Chapter 24

Critical Systems Validation

24.1 Objectives

To explain how system reliability can be measured and how reliability growth modelscan be used for reliability prediction

To describe safety arguments and how these are used

To discuss the problems of safety assurance

To introduce safety cases and how these are used in safety validation

24.2 Topics covered

Reliability validation

Safety assurance

Security assessment

Safety and dependability cases

24.3 Introduction

Critical Systems Validation = validating the availability, reliability, safety and secu-rity of critical systems.

1. Availability validation.

Is the system operational and able to deliver the requested service any time?

94

2. Reliability validation.

Does the measured reliability of the system meet its specification?

Is the reliability of the system good enough to satisfy users?

3. Safety validation.

Does the system always operate in such a way that accidents do not occur or that accident

consequences are minimised?

4. Security validation.

Is the system and its data secure against external attack?

The verification and validation costs for critical systems involves additional validationprocesses and analysis than for non-critical systems:

The costs and consequences of failure are high so it is cheaper to find and removefaults than to pay for system failure;

You may have to make a formal case to customers or to a regulator that the systemmeets its dependability requirements. This dependability case may require specificV & V activities to be carried out.

24.4 Validation techniques

1. Static techniques.

2. Dynamic techniques.

3. Process validation.

24.5 Key points

Reliability measurement relies on exercising the system using an operational profile- a simulated input set which matches the actual usage of the system.

Reliability growth modelling is concerned with modelling how the reliability of asoftware system improves as it is tested and faults are removed.

Safety arguments or proofs are a way of demonstrating that a hazardous conditioncan never occur.

95

24.6 Quiz

1. What are the four stages of reliability validation?

Establish and operational profile

Design test data sets matching that profile

Test the system and count system failures

After observing a statistically significant number of failures, compute the reliability

2. What is an operational profile?

3. What is a reliability growth model?

A model of how the system reliability changes over time during the testing process.

4. What types of review does Parnas suggest for safety-critical systems?

Review for correct intended function,

Review for maintainable, understandable structure,

Review to verify behaviour

Review of code consistence and algorithm/data structure design

Review of system test cases.

5. Why is it easier to create formal safety arguments than proofs of program correctness?

6. What safety assurance activities might be included in a critical systems developmentprocess?

Creation of a hazard logging and monitoring system,

Appointment of a project safety engineer,

Extensive use of safety reviews,

Creation of a safety certification system

Use of detailed configuration management.

96

7. What are assertions and how are they used?

8. Why is the security of a system difficult to assess?

9. What are four complementary approaches to security checking?

Experience-based validation,

Tool-based validation,

Tiger teams,

Formal verification.

10. What is a safety case?

97

Chapter 25

Managing people

25.1 Objectives

To explain some of the issues involved in selecting and retaining staff.

To describe factors that influence individual motivation.

To discuss key issues of team working including composition, cohesiveness and com-munications.

To introduce the people capability maturity model (P-CMM) - a framework for en-hancing the capabilities of people in an organisation.

25.2 Topics covered

Selecting staff

Motivating people

Managing groups

The people capability maturity model

25.3 Introduction

People are an organisation’s most important assets. The tasks of a manager are essen-tially people oriented. Unless there is some understanding of people, management will beunsuccessful. Poor people management is an important contributor to project failure.

98

25.4 People management factors

Consistency. Team members should all be treated in a comparable way withoutfavourites or discrimination.

Respect. Different team members have different skills and these differences shouldbe respected.

Inclusion. Involve all team members and make sure that peoples views are considered.

Honesty. You should always be honest about what is going well and what is goingbadly in a project.

25.5 Staff selection factors

Application domain experience

Platform experience

Programming language experience

Educational background

Communication ability

Adaptability

Attitude

Personality

25.6 Key points

Staff selection factors include education, domain experience, adaptability and per-sonality.

People are motivated by interaction, recognition and personal development.

Software development groups should be small and cohesive. Leaders should be com-petent and should have administrative and technical support.

99

25.7 Quiz

1. What are the four critical factors in people management?

Consistency,

Respect,

Inclusion,

Honesty

2. What factors might be considered when selecting people for a software developmentteam?

3. What are the different levels in the human needs hierarchy?

Physiological needs,

Safety needs,

Social needs,

Esteem needs,

Self-realisation needs.

4. How can self-realisation needs be satisfied?

5. What are the three classes of people identified by Bass and Dunteman?

Task-oriented people,

Self-oriented people,

Interaction-oriented people.

6. What are the four most important factors that influence group working?

Group composition,

Group cohesiveness,

Group communications,

100

Group organisation.

7. What is egoless programming?

8. What are the key factors that influence the effectiveness of group communications?

Group size,

Group structure,

Group composition,

The physical work environment.

9. What environmental factors influence human behaviour?

Room size, furniture, equipment, temperature,

Humidity, brightness and quality of light, noise and t

he degree of privacy that is available.

10. What are the strategic objectives of the people capability maturity model?

The improve the capability of software organisations by increasing the capability oftheir work force.

To ensure that software development capability is an attribute of an organisationrather than of a few individuals.

101

Chapter 26

Software cost estimation

26.1 Objectives

To introduce the fundamentals of software costing and pricing

To describe three metrics for software productivity assessment

To explain why different techniques should be used for software estimation

To describe the COCOMO 2 algorithmic cost estimation model

26.2 Topics covered

Software productivity

Estimation techniques

Algorithmic cost modelling

Project duration and staffing

26.3 Introduction

Predicting the resources required for a software development process. The fundamentalestimation questions are

How much effort is required to complete an activity?

How much calendar time is needed to complete an activity?

What is the total cost of an activity?

Project estimation and scheduling are interleaved management activities.

102

26.4 Software cost components

Parameters involved in computing the total cost of a software development project:

Software cost components

Hardware costs

Travel and training costs

Effort costs (the dominant factor in most projects):

• salaries of engineers involved in the project.

• social and insurance costs

• costs of building, heating, lighting,

• costs of networking and communications,

• costs of shared facilities (e.g library, staff restaurant, etc.)

Estimates are made to discover the cost, to the developer, of producing a software system.There is not a simple relationship between the development cost and the price chargedto the customer. Broader organisational, economic, political and business considerationsinfluence the price charged.

26.4.1 Software pricing factors

Market opportunity. You may quote a low price because you wish to move in a new

segment of the market and to use later the experience gained in this project.

Cost estimate uncertainty. Unsure of the cost estimate, you may increase its price over

and above the normal profit.

Contractual terms. If you retain the ownership of the source code you can reuse it.

Requirements volatility. Lower the price to win a contract. Then charge higher prices

for changes to the requirements.

Financial health. If you are in difficulties, lower the price to gain the contract.

26.5 Key points

There is not a simple relationship between the price charged for a system and itsdevelopment costs.

Factors affecting productivity include individual aptitude, domain experience, thedevelopment project, the project size, tool support and the working environment.

Software may be priced to gain a contract and the functionality adjusted to the price.

103

Chapter 27

Quality Management

27.1 Objectives

To introduce the quality management process and key quality management activities.

To explain the role of standards in quality management.

To explain the concept of a software metric, predictor metrics and control metrics.

To explain how measurement may be used in assessing software quality and thelimitations of software measurement.

27.2 Topics covered

Process and product quality

Quality assurance and standards

Quality planning

Quality control

27.3 Introduction

Quality management = Managing the quality of the software process and products.Software quality managementis concerned with ensuring that the required level of qual-

ity is achieved in a software product. It involves defining appropriate quality standardsand procedures and ensuring that these are followed. Should aim to develop a ’qualityculture’ where quality is seen as everyone’s responsibility.

Quality, simplistically, means that a product should meet its specification. This isproblematical for software systems. There is a tension between

104

customer quality requirements (efficiency, reliability, etc.) and

developer quality requirements (maintainability, reusability, etc.).

Quality management is particularly important for large, complex systems. The qualitydocumentation is a record of progress and supports continuity of development as the devel-opment team changes. For smaller systems, quality management needs less documentationand should focus on establishing a quality culture.

27.4 Quality management activities

1. Quality assurance. Establish organisational procedures and standards for quality.

2. Quality planning. Select applicable procedures and standards for a particularproject and modify these as required.

3. Quality control. Ensure that procedures and standards are followed by the soft-ware development team.

27.5 Key points

Software quality management is concerned with ensuring that software meets itsrequired standards.

Quality assurance procedures should be documented in an organisational qualitymanual.

Software standards are an encapsulation of best practice.

Reviews are the most widely used approach for assessing software quality.

Software measurement gathers information about both the software process and thesoftware product.

Product quality metrics should be used to identify potentially problematical compo-nents.

There are no standardised and universally applicable software metrics.

27.6 Quiz

1. What are the three main quality management activities?

Quality assurance – establishing standards

105

Quality planning – selecting appropriate standards

Quality control – checking conformance to standards.

2. Briefly describe the two types of standard that may be defined during the qualitymanagement process.

Product standards that are applied to the software that is being developed.

Process standards that define the processes to be followed during software develop-ment.

3. Briefly explain why software standards are important.

They are based on knowledge of the best practices for that company.

They provide a framework for implementing the quality assurance process.

They assist in continuity where work is transferred from one person to another.

4. What is ISO 9000?

5. Give four examples of document standards that may be used.

Document identification standards,

Document structure standards,

Document presentation standards,

Document update standards.

6. What sections does Humphrey suggest should be included in a quality plan?

Product introduction,

Product plans,

Process descriptions,

Quality goals,

Risks and risk management.

7. Describe two ways in which software product measurements may be used.

106

To make general predictions about a system – ie you may measure characteristics ofcomponents and derive some aggregate system measure.

To identify anomalous components.

8. What is the difference between predictor and control metrics?

9. What are the key stages in the product measurement process?

Chose measurements to be made,

Select components to be assessed,

Measure component characteristics,

Identify anomalous measurements,

Analyse anomalous components.

10. Suggest 4 different object-oriented metrics that may be used.

Depth of inheritance tree,

Method fan-in/fan-out,

Weighted methods per class,

Number of overriding operations.

107

Chapter 28

Process Improvement

28.1 Objectives

To explain the principles of software process improvement

To explain how software process factors influence software quality and productivity

To explain how to develop simple models of software processes

To explain the notion of process capability and the CMMI process improvementmodel

28.2 Topics covered

Process and product quality

Process classification

Process measurement

Process analysis and modelling

Process change

The CMMI process improvement framework

28.3 Introduction

Process improvement = Understanding, Modelling and Improving the Software Process.Process Improvement means

understanding existing processes and

108

introducing process changes

to achieve organisational objectives which are usually focused on

• quality improvement,

• cost reduction and

• schedule acceleration.

Most process improvement work so far has focused on defect reduction. This reflects theincreasing attention paid by industry to quality. However, other process attributes canbe the focus of improvement.

Process quality and product quality are closely related and process improvement ben-efits arise because the quality of the product depends on its development process.

28.4 Key points

Process improvement involves process analysis, standardisation, measurement andchange.

Processes can be classified as informal, managed, methodical and improving. Thisclassification can be used to identify process tool support.

The process improvement cycle involves process measurement, process analysis andprocess change.

Process measurement should be used to answer specific process questions, based onorganisational improvement goals.

The three types of process metrics used in the measurement process are time metrics,resource utilisation metrics and event metrics.

Process models include descriptions of tasks, activities, roles, exceptions, communi-cations, deliverables and other processes.

The CMMI process maturity model integrates software and systems engineering pro-cess improvement.

Process improvement in the CMMI model is based on reaching a set of goals relatedto good software engineering practice.

109

28.5 Quiz

1.What are the stages of process improvement?

Process measurement,

Process analysis,

Process change.

2. List the process characteristics that you may try to improve.

3. What are the main factors that affect software product quality?

Development technology,

People quality,

Cost, time and schedule,

Process quality.

4. Briefly describe 4 classes of software process.

Informal processes with no defined process model.

Managed processes where a process model drives the process.

Methodical processes where some development method is followed.

Improving processes where processes have inherent improvement goals.

5. What are the three types of process metric that may be collected?

The time taken for a process to complete.

The resources required for a particular process.

The number of occurrences of a particular event.

6. Briefly describe the GQM paradigm.

A set of goals which define what the organisation is trying to achieve is defined.

Associated questions that identify areas of uncertainty in achieving the goals are es-tablished.

110

The measurements needed to answer the questions are defined.

7. What are process models?

8. What are the essential stages in the process change process?

Identify improvements,

Prioritise improvements

Introduce process change,

Train engineers,

Tune process changes

9. What are the process area categories used in the CMMI model?

Process management,

Project management,

Engineering,

Support.

10. What are the identified levels in the CMMI staged model?

Initial,

Managed,

Defined,

Quantitatively managed,

Optimizing.

111

Chapter 29

Configuration Management

29.1 Objectives

To explain the importance of software configuration management (CM)

To describe key CM activities namely CM planning, change management, versionmanagement and system building

To discuss the use of CASE tools to support configuration management processes

29.2 Topics covered

Configuration management planning

Change management

Version and release management

System building

CASE tools for configuration management

29.3 Introduction

Configuration Management means textcolorredManaging the products of system change.CM is the development and application of standards and procedures for managingan evolving system product. New versions of software systems are created as they change:

For different machines/OS

Offering different functionality

Tailored for particular user requirements

112

Configuration management is concerned with managing evolving software systems. Systemchange is a team activity. CM aims to control the costs and effort involved in makingchanges to a system. Involves the development and application of procedures and standardsto manage an evolving software product. May be seen as part of a more general qualitymanagement process.

29.4 Terminology

1. Version. An instance of a system which is functionally distinct in some way fromother system instances.

2. Variant. An instance of a system which is functionally identical but non-functionallydistinct from other instances of a system.

3. Release. An instance of a system which is distributed to users outside of the devel-opment team.

29.5 System releases

Systems are now normally released on CD-ROM or as downloadable installation files fromthe web. Not just a set of executable programs. May also include:

1. Configuration files defining how the release is configured for a particular installation.

2. Data files needed for system operation.

3. An installation program or shell script to install the system on target hardware.

4. Electronic and paper documentation.

5. Packaging and associated publicity.

29.6 Key points

Configuration management is the management of system change to software products.

A formal document naming scheme should be established and documents should bemanaged in a database.

The configuration data base should record information about changes and changerequests.

A consistent scheme of version identification should be established using versionnumbers, attributes or change sets.

113

29.7 Quiz

1. What is meant by configuration management?

A controlled system where changes to the system have to be agreed and recorded before they are implemented.

The development and use of standards and procedures for managing an evolving software system.

2. What is a baseline?

3. What should be included in a configuration management plan?

The configuration items to be managed,

The people responsible for management,

The configuration management policies,

The CM tools to be used,

The schema of the configuration database.

4. Why is it necessary to define a configuration item identification scheme?

Because there may be thousands of source code modules, test scripts, design documents, etc. in a large project.

You have to be able to uniquely identify and loc ate any specific item and so a uniquenaming scheme is required.

5. What information may be included in a configuration database?

Information about configuration items such as data of creation, creator, etc.

Information about users of components, system customers, execution platforms, andproposed changes to the system.

6. What are the objectives of change management procedures?

To analyse the costs and benefits of proposed changes, approving changes that ar eworthwhile, and tracking which components of the system have been changed.

7. What is the role of a change control board?

114

To assess the impact of proposed changes from a strategic and organisational perspective rather than a technical perspective.

They should decide if changes are worthwhile and should prioritise changes to beimplemented.

8. What is the difference between a system version and a system release?

A system version is an instance of a system that differs, in some ways, from oth erinstances.

A system release is a version that is released to customers.

9. What are the advantages of attribute-based version identification?

They reflect the many attributes that may be used to identify versions.

When selecting components, you do not need to specify the version number (an error-prone process if there are many components) but simply list the required component attributes.

10. What may be included in a system release?

The executable code of a system,

Configuration files,

Data files,

An installation program

Electronic and paper documentation, packaging and publicity.

11. What are the key issues in system building?

Have all components been included?

Are the right versions of components included?

Are all required data files available?

Are the data files properly referenced,

Is the appropriate version of the compiler and other tools available?

12. What are the two types of CM workbench?

Open workbenches that include CM tools from different suppliers.

115

Integrated workbenches that provide integrated facilities for version management ,system building and change tracking.

13. What facilities might be provided in system building CASE tools?

A dependency specification language and interpreter,

Tool selection and instantiation support,

Distributed compilation,

Derived object management.

116

Amalgamated Revision Questions

Question 1. What are the four important attributes which all software products should

have?

Question 2. How are described system architectures?

Question 3. Which are the fundamental activities common to all software processes?

Question 4. Enumerate the principal stages of the waterfall model.

Question 5. Which is the main distinction between the spiral model and other software

process models?

Question 6. Enumerate the principal stages of the testing process.

Question 7. Enumerate the principal stages of the debugging process.

Question 8. Give a short definition for CASE.

Question 9. Enumerate at least four management activities.

Question 10. Enumerate the stages of the risk management process.

Question 11. What is a software requirement and what is requirement engineering?

Question 12. Enumerate the stages of the requirement engineering process.

Question 13. What is a system model?

Question 14. How is represented an object class in UML? Give an example of a class

hierarchy.

Question 15. What is a Wizard of Oz prototype?

Question 16. Draw and explain the structure of a Z schema.

Question 17. In the first phase of the architectural design activity, a system is decomposed

into a set of interacting sub-systems. Enumerate some specific models of the structure thatmay be developed.

Question 18. Give a taxonomy for control models.

117

Question 19. Depict the OSI reference model architecture.

Question 20. Shortly describe a client-server architecture.

Question 21. Enumerate the layers of the logical structure of an application.

Question 22. Describe two-tier client-server architectures.

Question 23. Describe the three-tier client-server architecture.

Question 24. What is a distributed object architecture?

Question 25. Enumerate the two principal standards for middleware.

Question 26. What is an object?

Question 27. The behaviour of a real-time system is determined by stimuli that are

received by the system. Enumerate and describe classes of stimuli.

Question 28. Define and describe a real-time executive.

Question 29. What is a real-time system?

Question 30. What is design with reuse and what are its advantages?

Question 31. Describe component-based development.

Question 32. Describe at least three principal characteristics of a GUI.

Question 33. What are the most important dimensions of system dependability?

Question 34. Define a critical system and enumerate classes of critical systems.

Question 35. Describe at least one type of damage that can be caused through an external

attack.

Question 36. Define hardware reliability.

Question 37. Define MeanTimeToFailure (MTTF).

Question 38. Enumerate at least three types of failure.

Question 39. What are the levels of risk?

Question 40. How can be achieved dependability in a program?

Question 41. What programming constructs and techniques should not be used when

developing dependable systems?

Question 42. Enumerate the four aspects of program fault tolerance.

Question 43. What is defensive programming?

118

Question 44. What is the difference between verification and validation?

Question 45. What is the difference between testing (verification and validation) and

debugging?

Question 46. Describe the structure of a software test plan.

Question 47. What is Cleanroom Software Development?

Question 48. Describe black box testing.

Question 49. What is the difference between top-down and bottom-up testing?

Question 50. How should you test object classes?

Question 51. What is a tiger team?

Question 52. Enumerate the types of human memory.

Question 53. Classify professionals into three types.

Question 54. Enumerate at least four factors governing staff selection.

Question 55. Enumerate the factors affecting software engineering productivity.

Question 56. By dividing the effort required on a project by the development schedule

gives me a useful indication of the number of people required by the project team. Commentthis sentence.

Question 57. Enumerate three principal activities of software quality management.

Question 58. What is a software metric?

Question 59. Classify and give examples of software metrics.

Question 60. Process improvement means understanding existing processes and changing

these processes to improve product quality and/or reduce costs and development time.Enumerate the key stages in the process improvement process.

Question 61. Enumerate the four factors that can affect software product quality.

Question 62. The fundamental difficulty in process measurement is knowing what to

measure. The GQM paradigm (Basili and Rombach) relies on identification of what?

Question 63. The SEI (Software Engineering Institute) model classifies software processes

into five different levels. Enumerate these levels.

Question 64. Enumerate three types of process metrics.

Question 65. What is a legacy system?

Question 66. Enumerate the four strategic options during the legacy system assessment.

119

Question 67. Enumerate the three strategies for software change.

Question 68. Enumerate three of Lehman’s laws.

Question 69. Enumerate two types of software maintenance.

Question 70. What does architectural evolution involve?

Question 71. Re-engineering a software system has two keys advantages over more radical

approaches to system evolution. Enumerate these advantages.

Question 72. Enumerate the activities in the re-engineering process.

Question 73. What is source code translation?

Question 74. What is configuration management?

Question 75. A system release is not just the executable code of the system. Enumerate

what may include a system release.

Question 76. What is system building?

Question 77. What is the difference between software engineering and computer

science? Explain.

Question 78. Can the physical environment affect the functioning of a software

system adversely? Explain.

Question 79. What development process should be used for a system that controls a

car’s brakes? Explain.

Question 80. What are the steps after brainstorming for viewpoint-oriented require-

ments elicitation? Explain.

Question 81. What is the advantage of using UML compared to natural language and

actual code? Explain.

Question 82. How can the abstract machine model be applied for the design of an

operating system? Explain.

Question 83. Draw an UML class diagram for a part of a document preparation sys-

tem described as follows (the bold words are bold for a reason!). Document any furtherassumptions.A document consists of a number of pages, each of which has identical dimensions(width and height). A page contains a number of elements, each of which has a posi-tion (from the top and the left), dimension (width and height), and a style (font name,font size, bold, italic, underlined). Elements are either columns, headings, or para-graphs. Columns have a text alignment (left, right, center, fill) and contain headings andparagraphs. Headings and paragraphs have their actual content.

Question 84. Indicate whether the following statements are true or false(T/F):

120

1. Encapsulation in C++ usually involves making a class’ data members private.

2. A has-a relationship corresponds to inheritance and a is-a relationship correspondsto composition.

3. A derived class inherits its base class’ data members even if they are private.

4. A derived class has direct access to its base class’ private data members.

5. A base class’ protected members can be accessed directly by its derived classes.

6. In an UML class diagram a diamond shape represents inheritance.

Question 85. Give brief definitions of the following terms. Limit yourself to bf 1 sentence

for each answer.

1. abstraction

2. information hiding

3. Abstract Data Type (ADT)

4. polymorphism

5. abstract class

Question 86. Draw an UML class diagram for a menu of a restaurant (the bold words

are bold for a reason!). Document any further assumptions.A menu at a restaurant has 40 different items, which fall into two main categories: pastaand wine. The available types of pasta are lasagna, spaghetti and linguini, and theavailable types of wine are red and white.

Question 87. Multiplication of positive integers can be viewed as the recursive applica-

tion of integer addition.

1. Give a precise recursive definition of the multiplication operation without using anyprogramming language notation.

2. Write a C++ function int multiply (int m, int n) that performs multiplication byrecursive application of addition.

Question 88. Exponentiation of a positive integer by a positive integer has a recursive

structure.

1. Give a precise recursive definition of the exponentiation operation without using anyprogramming language notation.

121

2. Write a C++ function int exp (int m, int n) that implements the recursive exponen-tiation.

Question 89. (parametric polymorphism). A swap function takes references totwo objects

and swaps them. Write a templated swap function that can be used to swap objects ofarbitrary type.

Question 90. Choose the correct answer for the following questions, knowing that only

ONE is true.

1. The waterfall model:

(a) encapsulates risk

(b) modularizes risk

(c) linearizes risk

(d) does not deal with risk

2. Which of the following is NOT a participant in a code inspection:

(a) moderator

(b) recorder

(c) reader

(d) none of the above

3. A design that uses information hiding should hide design decisions that:

(a) have many clients

(b) are likely to be inherited

(c) are likely to change

(d) none of the above

4. The most costly phase in software lifecycle is:

(a) verification

(b) maintenance

(c) design

(d) none of the above

5. An object oriented design tends to focus on:

(a) verbs

(b) nouns

122

(c) subroutines

(d) none of the above

6. An abstract data type consists of a set of values and

(a) a set of operations on those values

(b) a set of concrete types

(c) a set of classes

(d) none of the above

Question 91. List at least FOUR characteristics of a project that would argue for using

the software engineering approach.

Question 92. What are the THREE most important characteristics of a requirements

specification. Explain why each of them is so important.

Question 93. Briefly describe at least FOUR good things about the waterfall process

model.

Question 94. Describe THREE ways in which the spiral process model is superior to the

waterfall model.

Question 95. Briefly describe THREE benefits of using standards.

Question 96. Describe the difference between requirements elicitation and requirements

analysis.

Question 97. What are the main techniques used during elicitation and analysis?

Question 98. What is the purpose of the specification phase? Describe the main deliver-

ables of this phase.

Question 99. Write a Z schema that formalizes the following informal specification :

A student can drop one of the courses for which he is registered

Question 100. Given the schema Counter, where ctr is declared to be a natural number

less or equal to a predefined constant max

Counterctr : N

0 ≤ ctr ≤ max

write down a schema

1. InitCounter – an operation to initialise the counter

123

2. Increment – an operation to increment the counter

3. Decrement – an operation to decrement the counter

4. Display – an operation to display the value of the counter

Question 101. Let T be the set of integers from 1 to 10 inclusive.

1. Give a formal definition (in the declarative predicate style) of the relation R : T ↔ T ,where x is related to y exactly when y is greater then the square of x but less thanthe square of x + 1.

2. Write down R as a set of ordered pairs.

Question 102. Decide if the following predicates are true or false (need to give a reason).

1. ∀ x : Z • x − x = 0

2. ∃ x : Z • x ∗ x = −16

3. ∃ n : N • ∀m : N • m > n ⇒ ∃ k : N • m = 2 ∗ k

4. ∀ S ,T : PN • S ⊆ T ∨ T ⊆ S

5. PPP∅ = {∅, {∅}, {∅, {∅}}, {{∅}}}

Question 103. Given Schema1 and Schema2, define Schema3 and Schema4 to be the

conjunction, respectively disjunction of Schema1 and schema2.

Schema1x : X ; y : Y

A(x , y)

Schema2z : Z ; x : X

B(z , x )

Question 104. The notation X 7→ Y stands for

1. a total function

2. a relation

124

3. a partial function

4. none of the above

Question 105. You have been hired by a client to design and build a program. As you

sit down with the client to learn what his needs are, you get the feeling he is not sure ofexactly what the software should look like. What software model would you choose forthis project? Explain why.

Question 106. Finding software defects early lowers the cost of development. Explain

how the waterfall model attempts to find defects early.

Question 107. How are software defects found early in the Extreme Programming (XP)

approach?

Question 108. A key component of the XP (eXtreme Programming) philosophy is that

programmers should design test cases before writing code. Suppose that you are working inan XP team that is developing code for user authentication, i.e. it asks for a username andpassword, and it checks against a database. What test cases would you use? Be specific.

Question 109. Why does it not make sense (necessarily) to cut project costs by using a

new programming methodology that reduces development time?

Question 110. Inspections and walkthroughs tie up the valuable time of several team

members. So, how can inspections and walkthroughs be justified?

Question 111. What key problem does the rapid prototyping model address? How does

it address it, as opposed to the waterfall model?

Question 112. What key problem does the spiral model address? How does it address

it, as opposed to the waterfall model?

Question 113. What are the benefits of Object-Oriented Programming?

Question 114. Enumerate some pros and cons for COTS (Commercial Off The Shelf).

Question 115. The IT department in our university intends to procure an integrated

student management system holding all details of registered students, including personalinformation, courses taken and examination marks achieved. The alternative approachesto be adopted are:

1. Buy a similar system from another university and modify it to local requirements.

2. Buy a database management system and develop an in-house system based on thisDBMS.

3. Join a consortium of other universities, establish a common set of requirements andcontract a software house to develop a single system for all of the universities in theconsortium.

125

Identify two possible risks (Risk1, Risk2) in each of these strategies and suggest techniquesfor risk resolution (Resolution 1, Resolution 2) which would help in deciding which approachto adopt.

Question 116. If N is a constant, give formal specifications via pre- and post-conditions

for the program behaviours described below

1. A program sorts an non-empty array A[1..N ] of integers into increasing order.

Note. You may use predicate PERM (A,B), true iff array B is a permutation of arrayA.

2. Given three arrays A[1..N ], B [1..N ], C [1..N ] of integers, set each element of A equalto the larger of the two corresponding elements of B and C .

Note. You may use predicate UNCHG(A) if array A does not change.

3. A function that finds the minimum values in an array of integers A[1..N ].

Question 117. Enumerate at least five prototyping benefits.

Question 118. What are software engineering methods?

Question 119. What are the attributes of good software?

Question 120. What are the key challenges facing software engineering?

Question 121. Define and give some (at least three) examples of emergent properties.

Question 122. What is software design and implementation?

Question 123. What is a design method? Enumerate some possible models.

Question 124. What are software management distinctions?

Question 125. Enumerate and describe three types of project plans.

Question 126. Write down the project plan structure.

Question 127. What is risk analysis?

Question 128. What is risk planning?

Question 129. What is risk monitoring?

Question 130. What are feasibility studies?

Question 131. What are scenarios?

Question 132. What are use cases?

Question 133. Give a classification of volatile requirements.

126

Question 134. What is traceabality and how can you classify it?

Question 135. What is a process model?

Question 136. What are behavioural models?

Question 137. Define multiple inheritance.

Question 138. What is object aggregation model?

Question 139. What is the difference between architectural design and software archi-

tecture?

Question 140. Briefly describe the activities in the architectural design process.

Question 141. What is middleware?

Question 142. Briefly describe the main CORBA services.

Question 143. Briefly describe the implementations of concurrent objects.

Question 144. What is reuse-based software engineering and what software units can be

reused?

Question 145. Enumerate reuse problems.

Question 146. What is an application framework? Classify frameworks.

Question 147. Briefly describe a product line and its types of specialisation.

Question 148. What is a design pattern and what are its elements?

Question 149. Enumerate and describe three user interfacce (UI) design principles.

Question 150. Briefly describe the types of document produced to support users with a

software system.

Question 151. What is dependability?

Question 152. What is security?

Question 153. What is a dependable systems specification?

Question 154. What is system reliability engineering?

Question 155. What’s the meaning of ROCOF = 0.0001?

Question 156. What’s the meaning of MTTF = 1000?

Question 157. An availability of 0.995 means what?

Question 158. What’s the meaning of POFOD = 0.0001?

127

Question 159. What is structured programming?

Question 160. What is fault tolerance?

Question 161. Briefly describe the types of testing.

Question 162. Is it possible to apply software inspections to requirements?

Question 163. What is the difference between test data and test cases?

Question 164. Briefly describe the approaches to cluster testing.

Question 165. What are safety proofs?

Question 166. Compare Parkinson’s law with Pricing to win.

Question 167. Briefly describe Fan-in/Fan-out.

Question 168. What is spaghetti logic?

Question 169. What is the fundamental theoretical result used for automatic program

restructuring?

128