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: oce: phone: fax: school: comp284@turing.une.edu.au 107 Booth Block (02) 6773 2513 (02) 6773 3312 (02) 6773 2298 http://mcs.une.edu.au/~comp284/

unit www:

lecturer www: http://mcs.une.edu.au/~despi/ Tutor: Serge Bgeholz e-mail: oce: phone: fax: comp284@turing.une.edu.au B262 Booth Block (02) 6773 3692 (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

Aims & Prerequisites

This unit introduces students to the software engineering issues. SE is an engineering discipline whose goal is the cost-eective development of software systems. SE aims to nd answers to the many problems that software development projects are likely to meet when constructing 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, 2001 3. Daniel H. Steinberg, Daniel W. PAlmer - Extreme Software Engineering. A hands-On Approach. Pearson Prentice Hall, 2004 4. James F. Peters, Witold Pedrycz - Software Engineeering. An Engineering Approach. John Wiley & sons, 2000 5. Hans van Vliet - Software Engineering. Priciples and Practice. John Wiley & sons, 2001 6. Martin Fowles - UML Distilled. Addison Wesley, 3rd ed, 2004 7. Bell S., Wood-Harper T. - Rapid Information Systems Development. 2nd ed., McGraw Hill, 1998 8. Bennett S., McRobb S., Farmer R. -Object-Oriented System Analysis and Design Using UML. McGraw Hill, 1999 9. Reiss S. P. - A Practical Introduction to Software design with C++. John Wiley & Sons, 1999 10. Sikora Z. M. - Java-Practical Guide for Programmers. Morgan Kaufmann, 2003 11. Spivey J. M. - The Z Notation: A Reference manual. 2nd ed., Oxford press, 1998 12. Wieringa R. J. -Design Methods for Reactive Systems. Morgan Kaufmann, 2003

How this Unit will be Run

The very rst thing you should do if you are taking this unit is mail a message to comp284@turing.une.edu.au from your turing account. If the computer account where you wish to receive electronic announcements is dierent from your turing account, you should create a le called .forward into your turing account and populate it with your prefered address(es).

The next thing you should do is check out either the ~comp284 directory or the comp284 web page. This is where (if you are external & dont attend lectures) everything that happens in this unit will take place. Ill describe the comp284 directory here, the web page is structured in an analagous fashion. In the comp284 directory there will be subdirectories called: 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. After the 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 are of general interest. Bulletin Board. This is where you can exchange oppinions with your mates (concerning the subject). Unit Links. This is where you can nd 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 the unit, 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 worth together 50 % from the nal mark. The exam is worth 50% from the nal mark. Deadlines will be extended on medical grounds. Otherwise late submissions will attract a penalty of 10% per day late and will not be marked at all (0 marks) if more than seven days late. 3

The assignments must be submitted using the electronic submit facility. All programming 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 worth together 50 % from the nal mark. The exam is worth 50% from the nal mark. Deadlines will be extended on medical grounds. Late assignments will attract a penalty of 10% per day late and will not be marked (youll get 0 marks) if more than seven days late, unless you have requested and been granted an extension prior to the due date. The last one (Assignment 7) can be submitted anytime before the last day of school (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 to the 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 nal examination, you will receive a failed incomplete (NI) grade for the Unit.

PLAGIARISM
Students are warned to read the statement in the Facultys Undergraduate and Postgraduate Handbooks for 2003 regarding the Universitys Policy on Plagiarism. Full details of the 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, it is presumed that you have read the web site and have agreed with the conditions so you dont have to submit the form .

Tentative unit plan 2005

Week 1 26 July - 31 July Introduction Socio-technical systems Critical systems Software processes Project management Software requirements Requirements engineering processes System models Critical systems specications Formal specications Architectural design Distributed system architectures Application architectures Object-oriented design Real-time software design User interface design Rapid software development Software reuse

Week 2

01 - 07 August

Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Midsemester Break Week 9 Week 10 Week 11 Week 12 Week 13

08 - 14 August 15 - 21 August 22 - 28 August 29 August - 04 September 05 - 11 September 12 - 16 September 17 September 03 October 04 - 09 October 10 - 16 October 17 - 23 October 24 - 30 october 31 October - 04 Nov

Component-based software engineering Critical systems development Software evolution Verication and validation Software testing Critical systems validation Managing people Software cost estimation Quality management Process improvement Conguration management

Assignment due dates

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

Contents
1 Introduction 2 Socio-technical Systems 3 Critical Systems 4 Software Processes 5 Project management 6 Software Requirements 7 Requirements Engineering Processes 8 System models 9 Critical Systems Specication 8 11 14 18 23 26 30 32 36 40 44 48 52 56 60 64 68 72

10 Formal Specication 11 Architectural Design 12 Distributed Systems Architectures 13 Application architectures 14 Object-oriented Design 15 Real-time Software Design 16 User interface design 17 Rapid software development 18 Software Reuse

19 Component-based software engineering 20 Critical Systems Development 21 Software evolution 22 Verication and Validation 23 Software Testing 24 Critical Systems Validation 25 Managing people 26 Software cost estimation 27 Quality Management 28 Process Improvement 29 Conguration Management

76 79 83 87 90 94 98 102 104 108 112

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 concern to 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 Code contains eight Principles related to the behaviour of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, 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 client and employer consistent with the public interest. 8

3. PRODUCT. Software engineers shall ensure that their products and related modications meet the highest professional standards possible. 4. JUDGMENT. Software engineers shall maintain integrity and independence in their professional judgment. 5. MANAGEMENT. Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. 6. PROFESSION. Software engineers shall advance the integrity and reputation of the profession consistent 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 their profession 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 aspects of software production. Software products consist of developed programs and associated documentation. Essential product attributes are maintainability, dependability, eciency and usability. The software process consists of activities that are involved in developing software products. Basic activities are software specication, development, validation and evolution. Methods are organised ways of producing software. They include suggestions for the process to be followed, the notations to be used, rules governing the system descriptions which are produced and design guidelines.

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 dierent customers. Customised products designed to meet the specic 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 a computer-based system. To introduce the concept of emergent system properties such as reliability and security. To explain system engineering and system procurement processes. To explain why the organisational context of a system aects 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 and people.

11

A system is a purposeful collection of inter-related components working together towards some common objective. A system may include software, mechanical, electrical and electronic hardware and may be operated by people. System components are dependent on other system component. The properties and behaviour of system components are inextricably intermingled. System categories Technical computer-based systems. Systems that include hardware and software but where the operators and operational processes are not normally considered to be part of the system. The system is not self-aware. Socio-technical systems. Systems that include technical systems but also operational processes and people who use and interact with the technical system. Socio-technical systems are governed by organisational policies and rules.

2.4

Key points
Socio-technical systems include computer hardware, software and people and are designed to meet some business goal. Emergent properties are properties that are characteristic of the system as a whole and not its component parts. The systems engineering process includes specication, design, development, integration and testing. System integration is particularly critical. Human and organisational factors have a signicant eect on the operation of sociotechnical systems. There are complex interactions between the processes of system procurement, development and operation. A legacy system is an old system that continues to provide essential services. Legacy systems include business processes, application software, support software and system hardware.

2.5

Quiz

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

2. What are emergent properties? 12

3. What are three inuences 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 aect 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 severe human or economic consequence. To explain four dimensions of dependability - availability, reliability, safety and security. To explain that, to achieve dependability, you need to avoid mistakes, detect and remove 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 environment. 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: Customer accounting system in a bank.

3.4

Dependability

The dependability of a system equates to its trustworthiness. A dependable system is a system 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 specied time in a given environment for a given purpose. Availability: The probability that a system, at a point in time, will be operational and able 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, physical damage or threats to life. The dependability in a system reects the users trust in that system. The availability of a system is the probability that it will be available to deliver services when requested. The reliability of a system is the probability that system services will be delivered as specied. Reliability and availability are generally seen as necessary but not sucient conditions for safety and security. Reliability is related to the probability of an error occurring in operational use. A system with known faults may be reliable. Safety is a system attribute that reects the systems ability to operate without threatening people or the environment. Security is a system attribute that reects the systems ability to protect itself from external attack. Dependability improvement requires a socio-technical approach to design where you consider the humans as well as the hardware and software. 15

3.7

Quiz
Safety-critical systems Mission-critical systems Business critical systems

1. What are the principal types of critical system?

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 insulin pump? The system shall be available to deliver insulin when required. The system shall perform reliably and deliver the correct amount of insulin to counteract 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 available but 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 time is very short, then recovery from a system failure can be very rapid so the system availability is only minimally aected. 16

7. What is the denition of the safety property? Safety is a system property that reects its ability to operate, normally or abnormally, without danger of causing human injury or death and without damage to the systems environment. 8. What damage can result if a system is insecure? Denial of service Corruption of programs or data Disclosure of condential 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 an unsafe 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 development, testing and evolution. To explain the Rational Unied Process model. To introduce CASE technology to support software process activities.

4.2

Topics covered
Software process models Process iteration Process activities The Rational Unied Process Computer-aided software engineering

4.3

The software process

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

18

 Specication Design Validation Evolution A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

4.4

Generic software process models

1. The waterfall model. Separate and distinct phases of specication and development. 2. Evolutionary development. Specication 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-like process is used but the specication is a formal specication that is rened through several stages to an implementable design.

4.5

Key points
Software processes are the activities involved in producing and evolving a software system. Software process models are abstract representations of these processes. General activities are specication, design and implementation, validation and evolution. Generic process models describe the organisation of software processes. Examples include the waterfall model, evolutionary development and component-based software engineering. Iterative process models describe the software process as a cycle of activities. Requirements engineering is the process of developing a software specication. Design and implementation processes transform the specication to an executable program. Validation involves checking that the system meets to its specication and user needs. Evolution is concerned with modifying the system after it is in use. The Rational Unied Process is a generic process model that separates activities from phases. CASE technology supports software process activities. 19

4.6

Quiz
Software specication Software design and implementation Software validation Software evolution

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

2. List the 3 fundamental software process frameworks that are used to create specic software processes? The waterfall model Evolutionary development Component-based software engineering 3. Why are iterations usually limited when the waterfall model is used?

4. Briey describe two types of evolutionary development? Exploratory development where the objective of the process is to work with customers to explore their requirements and deliver a nal-system. Throw-away prototyping where the objective is to develop a better understanding of the customers requirements and deliver a better requirements specication. 5. What are the development stages in CBSE? Component analysis Requirements modication 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 Boehms 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 specication 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-ow 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 and evolution?

21

12. What are the 4 phases of the Rational Unied 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 characteristics. 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 software projects. Software project management is concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software.

23

The failure of many large projects in the 60s and 70s was the rst indication of the diculties 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 application of management techniques derived from other engineering disciplines. Project management is needed because software development is always subject to textcolormagentabudget and textcolormagentaschedule constraints that are set by the organisation developing the software.

5.4

Risk management

A risk is a probability that some adverse circumstance will occur. Risk management is concerned with identifying risks and drawing up plans to minimise their eect on a project. Categories of risk: Project risks aect schedule or resources. Product risks aect the quality or performance of the software being developed. Business risks aect 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 signicant activities are planning, estimating and scheduling. Planning and estimating are iterative processes which continue throughout the course of a project. A project milestone is a predictable state where a formal report of progress is presented to management. Project scheduling involves preparing various graphical representations showing project activities, their durations and stang. Risk management is concerned with identifying risks which may aect the project and planning to ensure that these risks do not develop into major threats.

24

5.6

Quiz

1. What are important dierences between software project management and other types of project management? The product (software) is intangible. There are no standard software processes Large software projects are often one-o 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 dierence between a milestone and a deliverable?

5. What is involved in project scheduling?

6. Explain how bar charts and activity networks give dierent 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 specication The software requirements document

6.3

Requirements engineering

Requirements engineering is the process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed. The requirements are the descriptions of the system services and constraints that are generated during the requirements engineering process.

26

6.4

The requirements document

The requirements document is the ocial statement of what is required of the system developers. Should include both a denition and a specication of requirements. It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it. Users of a requirements document range from the senior managers 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. Specic requirements 4. Appendices 5. Index This is a generic structure that must be instantiated for specic systems.

6.5

Key points
Requirements set out what the system should do and dene constraints on its operation and implementation. Functional requirements set out services the system should provide. Non-functional requirements constrain the system being developed or the development process. User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams. System requirements are intended to communicate the functions that the system should provide. A software requirements document is an agreed statement of the system requirements. The IEEE standard is a useful starting point for dening more detailed specic requirements 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 of what services the system should provide and the constraints under which it operates. System requirements are more detailed descriptions of the system services and constraint, 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 requirements document? 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 specication, Existing systems constrain the design and these constraints are requirements, The use of a specic architecture may be a requirement for business or regulatory reasons. 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 denition of form elds mean that writers are less likely to forget to include information Some automated processing is possible. 10. What are 3 types of interface that may have to be dened 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 Specic 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 requirements engineering 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 system requirements document. They are processes used to discover, analyse, and validate system requirements. 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 feasibility study decides whether or not the proposed system is worthwhile. It is a short focused study 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 integrated with 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 Classication 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 elicitation and analysis, requirements specication and requirements management. Requirements elicitation and analysis is iterative involving domain understanding, requirements collection, classication, structuring, prioritisation and validation. Systems have multiple stakeholders with dierent requirements. Social and organisation factors inuence system requirements. Requirements validation is concerned with checks for validity, consistency, completeness, realism and veriability. 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 Requirements Engineering (RE) process To describe behavioural modelling, data modelling and object modelling To introduce some of the notations used in the Unied 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 understood by people who are not technical experts. More detailed system requirements may be expressed in a more technical way. One widely used technique is to document the system specication as a set of system models, that is a graphical representation that describe the problem 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 dierent information about the system. Context models show how the system being modelled is positioned in an environment with other systems and processes. Architectural models, process models and data-ow models may be used as context models. Data-ow diagrams may be used to model the data processing carried out by a system. The system is modelled as a set of data transformations with functions acting on the data. State machine models are used to model a systems behaviour in response to internal or external events. Semantic data models describe the logical structure of the data which is imported to and exported by the system. They show system entities, their attributes and the relationships in which they participate. They may be supplemented with data dictionaries that provide a more detailed description of the data. Object models describe the logical system entities and their classication and aggregation. They combine a data model with a processing model. One can develop: inheritance models, aggregation models and behavioural models. CASE workbenches support the development of system models by providing model editing, checking, repporting and documentation tools. Sequence models show the interactions between actors and the system objects that they use. Structured methods provide a framework for developing system models.

33

8.5

Quiz
An external perspective A behavioural perspective A structural perspective.

1. What perspectives may be used for system modelling?

2. What types of system model may be developed? Data ow models Composition models Architectural models Classication 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 denition in the UML? The name of the object class The attributes of that class The operations or methods associated with that class 7. What dierent 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 particular area They tend to produce too much documentation The models produced are detailed and often hard to understand

35

Chapter 9 Critical Systems Specication

9.1 Objectives
To explain how dependability requirements may be identied by analysing the risks faced 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 specication.

9.2

Topics covered
Risk-driven specication Safety specication Security specication Software reliability specication

9.3

Introduction

We introduced requirements processes and techniques for the development of system specications in previous chapters. In this chapter we will discuss the same issues but concerning critical (dependable) systems. Denition: Dependable Systems Specication deals with processes and techniques for developing a specication 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 specication should be risk-driven. This approach has been widely used in safety and security-critical systems. The aim of the specication process should be to understand the risks (safety, security, etc.) faced by the system and to dene requirements that reduce these risks. Risk identication. Identify potential risks that may arise. Risk analysis and classication. Assess the seriousness of each risk. Risk decomposition. Decompose risks to discover their potential root causes. Risk reduction assessment. Dene how each risk must be taken into eliminated or reduced 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 given cost and schedule constraints. Acceptable. Consequences of hazard are acceptable and no extra costs should be incurred 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 classifying risks according to their seriousness. Security requirements should identify assets and dene how these should be protected. Reliability requirements may be dened quantitatively. Reliability metrics include POFOD, ROCOF, MTTF and availability. Non-functional reliability specications can lead to functional system requirements to reduce failures or deal with their occurrence. 37

9.6

Quiz
Exclusion requirements that dene undesirable situations to be avoided Functional requirements that protect against system failure Non-functional requirements that dene levels of availability and reliability

1. Describe the three types of dependability requirement?

2. What is risk-based specication?

3. What activities are part of the process of risk analysis? Risk identication, Risk analysis and classication 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. identication 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 reliability metric?

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 of service requests The time between system failures The elapsed repair or restart time. 10. What are the steps involved in establishing a reliability specication? Identify the types of system failure that may occur and the consequences of failure Partition failures into appropriate classes For each failure class, dene the reliability requirements using an appropriate metric

39

Chapter 10 Formal Specication

10.1 Objectives

To explain why formal specication techniques help discover problems in system requirements. To describe the use of algebraic techniques for interface specication. To describe the use of model-based techniques for behavioural specication.

10.2

Topics covered

Formal specication in the software process Sub-system interface specication Behavioural specication

10.3

Introduction

Formal specications are techniques for the unambiguous specication of software. Formal specication is part of a more general collection of techniques that are known as formal methods. These are all based on mathematical representation and analysis of software. Formal methods include: Formal specication Specication analysis and proof Transformational development Program verication A formal software specication is a specication expressed in a language whose vocabulary, syntax, andi semantics are formally dened. The specication language must be

40

based on mathematical concepts. Ussully, it is used discrete mathematics, and the concepts come from set theory, logic and algebra. Formal specication involves investing more eort in the early phases of software development. This reduces requirements errors as it forces a detailed analysis of the requirements. Incompleteness and inconsistencies can be discovered and resolved. Hence, savings as made as the amount of rework due to requirements problems is reduced.

10.4

Specication techniques

Thre are two approaches to formal specication that have been used to write detailed specications for non-trivial software systems: 1. Algebraic approach. The system is specied in terms of its operations and their relationships. 2. Model-based approach. The system is specied in terms of a state model that is constructed using mathematical constructs such as sets and sequences. Operations are dened by modications to the systems state. Sequential Concurrent Algebraic Larch Lotos
(Guttag et.al. 1985,1993)

OBJ
(Futatsugi et.al. 1985)

(Bolognesi et. al. 1987)

Model-based

Z (Spivey, 1992) VDM (Jones, 1980) B (Wordsworth, 1996)

CSP (Hoare, 1985) Petri Nets (Peterson, 1981)

10.5

Key points

Formal system specication complements informal specication techniques. Formal specications are precise and unambiguous. They remove areas of doubt in a specication. Formal specication forces an analysis of the system requirements at an early stage. Correcting errors at this stage is cheaper than modifying a delivered system. Formal specication techniques are most applicable in the development of critical systems and standards. Algebraic techniques are suited to interface specication where the interface is dened as a set of object classes. Model-based techniques model the system using sets and functions. This simplies some types of behavioural specication. Operations are dened in a model-based spec. by dening pre and post conditions on the system state. 41

10.6

Quiz

1. Suggest 4 reasons why formal specication is not widely used? Other software engineering techniques have been eective. 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 prole of software development costs change when formal specication is used? Costs are front-loaded with higher initial specication costs but lower testing and validation costs. 3. What are the two fundamental approaches to formal specication that are used? Algebraic specication Model-based specication. 4. What should be included in an algebraic specication 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 specication?

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 rst 3 invariants in the INSULIN PUMP STATE schema predicate? The variable r 2 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 species that the system can only operate if the hardware is operating properly and an insulin reservoir is 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, decomposition and control. To discuss reference architectures are used to communicate and compare architectures.

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. The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural design. The output of this design process is a description of the software architecture. Architectural design is an early stage of the system design process. It represents the link between specication and design processes. 44

Often carried out in parallel with some specication activities. It involves identifying major system components and their communications. Architectural design is a creative process so the process diers depending on the type of system being developed. However, a number of common decisions span all design processes.

11.4

Architectural models

The output of the architectural design is an architectural design document. Dierent architectural models may be produced during the design process. Each model presents dierent 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 denes sub-system interfaces. Relationships model such as a data-ow 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, the distribution and the architectural styles to be used. Dierent architectural models such as a structural model, a control model and a decomposition model may be developed. System organisational models include repository models, client-server models and abstract 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-specic architectures and 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 inuenced by the choice of system architecture? 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. Briey 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 interrupt 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 dierent approaches to the development of client-server systems. To explain the dierences between client-server and distributed object architectures. To describe object request brokers and the principles underlying the CORBA standards. To introduce peer-to-peer and service-oriented architectures as new models of distributed 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 on more than one processor. Virtually all large computer-based systems are now distributed systems. Information processing is distributed over several computers rather than conned to 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 personal computer or workstation. 2. Embedded systems. They run on a single processor or on an integrated group of processors. 3. Distributed systems. The system software runs on a loosely integrated group of cooperating 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 dierently 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 programs operating 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 and servers. Distributed object systems require middleware to handle object communications and to add and remove system objects. The CORBA standards are a set of middleware standards that support distributed object architectures. Peer to peer architectures are decentralised architectures where there is no distinction between clients and servers. Service-oriented systems are created by linking software services provided by dierent service 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. Briey descibe the thin-client and fat client models. Thin-client: All application processing and data management is carried out by the server. The client runs the presentation software. Fat client: The server is responsible for data management with all other functionality the 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 and server? Decentralised systems where computations may be carried out by any node on the network, 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 exible and scaleable Dynamic system reconguration 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 Notication services Transaction services 11. What are peer-to-peer systems?

12. What is a web service?

13. List 3 crucial dierences between a web service architecture and a distributed object architecture. Services can be oered 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 execution. 14. What standards have been dened 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 - batch processing 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 much in common, their application systems also tend to have a common architecture that reects the application requirements. A generic architecture is congured and adapted to create a system that meets specic requirements. E-commerce systems are Internet-based resource management systems that accept electronic orders for goods or services. They are usually organised using a multi-tier architecture with application layers associated with each tier. 52

Event processing systems respond to events in the systems environment. Their key characteristic is that event timing is unpredictable so the architecture has to be organised to handle this. Many common systems such as word processors, games, etc. are event processing systems. Application types Data processing applications. Data driven applications that process data in batches without explicit user intervention during the processing. Transaction processing applications. Data-centred applications that process user requests and update information in a system database. Event processing systems. Applications where system actions depend on interpreting events from the systems environment. Language processing systems. Applications where the users intentions are specied 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 applications. Important classes of application are data processing systems, transaction processing systems, event processing systems and language processing system. Data processing systems operate in batch mode and have an input-process-output structure. Transaction processing systems allow information in a database to be remotely accessed and modied 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 is modied. Language processing systems translate texts from one language to another and may interpret the specied 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 dierent 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 ow 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 modication 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-ow 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 objects that 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 Design is part of Object-Oriented Development: 1. Object-oriented analysis. OOA is concerned with developing an object model of the application domain. The identied objects reect entities and operations that are associated with the problem to be solved. 2. Object-oriented design. OOD is concerned with developing an object-oriented system model to implement requirements.

56

3. Object-oriented programming. OOP is concerned with realising an OOD using an OO programming language such as Java or C++. Objects are abstractions of real-world or system entities and manage themselves. Objects are independent and encapsulate state and representation information. System functionality is expressed in terms of object services. Shared data areas are eliminated. Objects communicate by message passing. Objects may be distributed and may execute sequentially or in parallel. Objects are entities in a software system which represent instances of real-world and system 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) which request services when some computation is required. Object classes are templates for objects. They may be used to create objects. They may inherit attributes and services from other object classes. Several dierent notations for describing object-oriented designs were proposed in the 1980s and 1990s . The Unified Modeling Language is an integration of these notations. It describes notations for a number of dierent models that may be produced during OO analysis 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 private state and operations. Objects should have constructor and inspection operations. They provide services to other objects. Objects may be implemented sequentially or concurrently. The Unied Modeling Language provides dierent notations for dening dierent object models. A range of dierent models may be produced during an object-oriented design process. These include static and dynamic system models. Object interfaces should be dened precisely using e.g. a programming language like Java. Object-oriented design potentially simplies 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. Briey describe two types of concurrent object implementation. Servers: The object is a parallel process with methods corresponding to the object operations. Methods execute in response to external requests Active objects: The state of the object is changed by internal operations within the object itself. The process executing these operations runs continuously. 4. List the 5 key stages in an object-oriented design process? Understand and dene 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 the system being designed. The model of use is a dynamic model that describes how the system being designed interacts with its environment. 6. In the architectural model of the weather station system, what are the three layers in the 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. Briey 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. Briey 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 usually implemented 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 acquisition systems

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 behaviour is subject to timing constraints. Real-time systems are systems which monitor and control their environment. Time is critical: RTS must respond within specied times. Inevitably associated with hardware devices Sensors: Collect data from the system environment.

60

Actuators: Change (in some way) the systems environment. Given a stimulus, the system must produce a response within a specied time. We distinguish: 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 the system 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 produced according to the specied timing requirements. A hardware RTS is a system whose operation is incorrect if results are not produced according to the timing specication. Hard-real time systems may have to programmed in assembly language to ensure that deadlines are met. Languages such as C allow ecient programs to be written but do not have constructs to support concurrency or shared resource management. Java supports lightweight concurrency (threads and synchronized methods) and can be used for some soft real-time systems. Java 2.0 is not suitable for hard RT programming but real-time versions of Java are now available.

15.4

Key points

Real-time system correctness depends not just on what the system does but also on how 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 processes. 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 consumer model.

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. Briey 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 cause a 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. Briey 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 buer for each type of sensor. A processor for that data. A display process. 9. Why is a sensor data buer required in data acquistion systems?

10. Why is the sensor data buer 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 dierent 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 interaction between machines and the human beings who use them (users). UI can take on many forms, 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 of its anticipated users. System users often judge a system by its interface rather than its functionality. 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 information. If you present more than this, they are more liable to make mistakes. People make mistakes. When people make mistakes and systems go wrong, inappropriate alarms and messages can increase stress and hence the likelihood of more mistakes. People are dierent. People have a wide range of physical capabilities. Designers should not just design for their own capabilities. People have dierent 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 ll-in, command languages and natural language. Graphical displays should be used to present trends and approximate values. Digital displays when precision is required. Colour should be used sparingly and consistently. The user interface design process involves user analysis, system prototyping and prototype evaluation. The aim of user analysis is to sensitise designers to the ways in which users actually work. UI prototyping should be a staged process with early paper prototypes used as a basis for automated prototypes of the interface. The goals of UI evaluation are to obtain feedback on how to improve the interface design 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 inuence 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 dierent 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? Conrmation of destructive actions. The provision of an undo facility. Checkpointing. 5. What are the 5 primary styles of interaction? Direct manipulation, Menu selection, Form ll-in, Command language, Natural language. 6. What are the advantages of using analogue rather than digital presentation of information? 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 nal 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 delivery of 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 new opportunities and competition. This requires software and rapid development and delivery is not often the most critical requirement for software systems. Businesses may be willing to 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, consistent set of system requirements. Therefore a waterfall model of development is impractical and an approach to development based on iterative specication and delivery is the only way to deliver software quickly. 68

Characteristics of RAD processes The processes of specication, design and implementation are concurrent. There is no detailed specication and design documentation is minimised. The system is developed in a series of increments. End users evaluate each increment and make proposals for later increments. System user interfaces are usually developed using an interactive development system. Prototyping Stakeholders nd it very dicult to express their real requirements. Its hard to predict how a system will aect working practices, how it will interact with other systems, what user operations should be automated. Requirements analysis plus systematic reviews of the requirements help to reduce the uncertainty. There is no real substitute for trying out a requirement before agreeing to it. This is possible if a system prototype is available. A prototype is an initial version of a software system. It is used to demonstrate concepts, to try out design options, to nd out more about the problem and its solution. System prototyping is rapid software development to validate requirements. Prototyping is the rapid development of a system. The principal use of system prototypes is to help customers and developers understand the requirements for the system. This system is thrown away when the system specication 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 development overhead and so produce software faster. Extreme programming includes practices such as systematic testing, continuous improvement and customer involvement. The approach to testing in XP is a particular strength where executable tests are developed before the code is written. Rapid application development environments include database programming languages, form generation tools and links to oce applications. A throw-away prototype is used to explore requirements and design options. When implementing a throw-away prototype, start with the requirements you least understand; in incremental development, start with the best-understood requirements.

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 dierence between incremental development and prototyping? Prototyping is intended to help understand the requirements so starts with requirements 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-rst development. 5. What is test-rst development?

6. Briey 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 oce 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 benets of prototyping found in Gordon and Biemans study? Improved system usability, a closer match to users needs, Improved system quality, improved maintainability, Reduced development eort.

71

Chapter 18 Software Reuse

18.1 Objectives

To explain the benets of software reuse and some reuse problems To discuss several dierent ways to implement software reuse To explain how reusable concepts can be represented as patterns or embedded in program 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 engineering disciplines, systems are designed by composing existing components that have

72

been used in other systems. Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, 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, there are many dierent approaches to reuse that may be used. Reuse is possible at a range of levels from simple functions to complete application systems. The reuse landscape covers the range of possible reuse techniques: Application system reuse. The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families. Widely practised as software systems are implemented as application families. COTS reuse is becoming increasingly common. Component reuse. Components of an application from sub-systems to single objects may be reused. Now seen as the key to eective and widespread reuse through component-based software engineering. However, it is still relatively immature. Object and Function reuse. Software components that implement a single welldened function may be reused. Common in some application domains (e.g. engineering) where domain-specic 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 solutions. Program generators are also concerned with software reuse - the reusable concepts are embedded in a generator system. Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialisation. COTS product reuse is concerned with the reuse of large, o-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 conguring a generic system with information about a customers business. Software product lines are related applications developed around a common core of shared functionality.

73

18.5

Quiz

1. List the main benets of software reuse. Increased dependability, reduced process risk, Eective 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 oer the most appropriate functionality, How will data be exchanged between dierent 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 software engineering

19.1 Objectives

To explain that CBSE is concerned with developing standardised components and composing 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 development that relies on reuse. It emerged from the failure of object-oriented development to support eective reuse. Single object classes are too detailed and specic. Components are more abstract than object classes and can be considered to be standalone service providers. When a system needs some service, it calls a component to provide that service, without caring about where the component is executed and the programming language 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 with each other. Source code is not available so that the component is not compiled with other system components. The component interface is published and all interactions are through the published interface. The internal state of a component is never exposed (component implementations are hidden). Component platforms are shared and reduce development costs. CBSE essentials Independent components specied 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 dening and implementing loosely coupled components into systems. A component is a software unit whose functionality and dependencies are completely dened by its interfaces. A component model denes a set of standards that component providers and composers should follow. During the CBSE process, the processes of requirements engineering and system design are interleaved. Component composition is the process of wiring components together to create a system. When composing reusable components, you normally have to write adaptors to reconcile dierent component interfaces. When choosing compositions, you have to consider required functionality, non-functional requirements and system evolution.

19.5

Quiz

1. What are the essential elements of component-based software engineering? Independent components completely specied 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 denition of a component?

3. What are the two principal component interfaces? A provides interface that denes the services provided by the component. A requires interface that species what services must be provided by other components 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 model middleware 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 dierent 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-os may have to be made when composing components? What composition is most eective 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 of dependable 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 programming techniques for building dependable software systems. In general, software customers expect all software to be dependable. However, for non-critical applications, they may be willing to accept some system failures. Some applications, however, have very high dependability requirements and special programming techniques must be used to achieve this. There are three complementary approaches to develop dependable software: 79

1. Fault avoidance. The software is developed in such a way that human error is avoided and thus system faults are minimised. The development process is organised so that faults in the software are detected and repaired before delivery to the customer. 2. Fault tolerance. The software is designed so that faults in the delivered software do not result in system failure. 3. Fault detection. Verication and validation techniques are used to discover and remove faults in a system before it is deployed. To ensure a minimal number of software faults, it is important to have a well-dened software development process, one that does not depend entirely on individual skills; rather it can be enacted by dierent people; a repeatable software development process, and a lot of verication and validation activities.

20.4

Key points

Dependability in a system can be achieved through fault avoidance, fault detection and fault tolerance. The use of redundancy and diversity is essential to the development of dependable systems. The use of a well-dened repeatable process is important if faults in a system are to be minimised. Some programming constructs are inherently error-prone - their use should be avoided wherever 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 faulttolerant architectures.

80

20.5

Quiz

1. Briey 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. Briey describe two types of fault detection. Pre-emptive fault detection detections a fault before a state change is committed. Retrospective fault detection detects a fault by analysing the state after it has 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 in numeric data. The use of redundant links in data structures. The use of watchdog timers in concurrent systems. 81

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

10. Briey describe the two fundamental approaches used to achieve software fault tolerance. N-version programming: Multiple versions of the same software are simultaneously executed and a voting system used to select the output. Recovery blocks: Dierent versions of the software are executed in sequence until an output satises a pre-dened 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; the business environment changes; errors must be repaired; new computers and equipment is added 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 existing software systems. Organisations have huge investments in their software systems - they are critical business assets. To maintain the value of these assets to the business, they must be changed and updated. The majority of the software budget in large companies is devoted to evolving existing software rather than developing new software. 83

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

21.4

Lehmans laws

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

21.5

Key points

Software development and evolution should be a single iterative process. Lehmans Laws describe a number of insights into system evolution. Three types of maintenance are bug xing, modifying software for a new environment and 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 software to make it easier to change. The business value of a legacy system and its quality should determine the evolution strategy that is used. 84

1. Why is software evolution important?

2. What are Lehmans 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 large software systems. 3. What are the three dierent types of software maintenance? Maintenance to repair software faults, Maintenance to adapt the software to a dierent environment, Maintenance to add to or modify the systems functionality. 4. What is the distribution of eort across these dierent maintenance types? Fault repair 17%, Software adaptation 18% Enhanced functionality 65%. 5. What factors should be assessed to understand the relationship between a system and its 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, Conguration management, Test data, Personnel skills

86

Chapter 22 Verication and Validation

22.1 Objectives

To introduce software verication and validation and to discuss the distinction between them To describe the program inspection process and its role in verication and validation To explain static analysis as a verication technique To describe the Cleanroom software development process

22.2

Topics covered

Verication 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 specication. 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 users needs. The V & V process is a whole life-cycle process: V&V must be applied at each stage in the software process. Has two 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. Verication and validation should establish condence that the software is t for purpose. This does NOT mean completely free of defects. Rather, it must be good enough for its intended use and the type of use will determine the degree of condence 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 to discover problems (static verication). May be supplement by tool-based document and code analysis. 2. Software testing. Concerned with exercising and observing product behaviour (dynamic verication). The system is executed with test data and its operational behaviour is observed. Types of testing 1. Defect testing. Tests designed to discover system defects. A successful defect test is one which reveals the presence of defects in a system. 2. Statistical testing. Tests designed to reect the frequence of user inputs. Used for reliability estimation. 3. Validation testing. Intended to show that the software meets its requirements. A successful test is one that shows that a requirements has been properly implemented.

22.4

Key points

Verication and validation are not the same thing. Verication shows conformance with specication; Validation shows that the program meets the customers needs. Test plans should be drawn up to guide the testing process. Static verication techniques involve examination and analysis of the program for error detection. Program inspections are very eective in discovering errors. Program code in inspections is systematically checked by a small team to locate software faults. Static analysis tools can discover program anomalies which may be an indication of faults in the code. The Cleanroom development process depends on incremental development, static varication and statistical testing. 88

22.5

Quiz

1. What is the distinction between validation and verication? Validation: Are we building the right product? Verication: 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 specication and verication? 9. Why do formal specication and verication not guarantee reliability? The specication may not reect 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 responsibility of the component developer (except sometimes for critical systems). Tests are derived from the developers experience. 2. Integration (System) testing. Testing of groups of components integrated to create a system or sub-system. The responsibility of an independent testing team. Tests are based on a system specication. 90

Testing process goals Validation testing. To demonstrate to the developer and the system customer that the software meets its requirements; A successful test shows that the system operates as intended. Defect testing. To discover faults or defects in the software where its behaviour is incorrect or not in conformance with its specication; A successful test is a test that makes 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 successful defect test is a test which causes a program to behave in an anomalous way. Tests show the presence not the absence of defects. This contrasts with validation testing which is intended to prove that a system meets its specication. 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 no remaining faults. Component developers are responsible for component testing; system testing is the responsibility of a separate team. Integration testing is testing increments of the system; release testing involves testing a 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 components. Equivalence partitioning is a way of discovering test cases - all cases in a partition should 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 of software 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. Briey describe the two distinct phases of system testing. Integration testing where the components and subsystems making up the system are integrated and tested. The integration team have access to the source code of the system. 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 buers to overow, 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 identied 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 models can 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 security 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 specication? 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 verication and validation costs for critical systems involves additional validation processes and analysis than for non-critical systems: The costs and consequences of failure are high so it is cheaper to nd and remove faults than to pay for system failure; You may have to make a formal case to customers or to a regulator that the system meets its dependability requirements. This dependability case may require specic V & 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 prole - a simulated input set which matches the actual usage of the system. Reliability growth modelling is concerned with modelling how the reliability of a software system improves as it is tested and faults are removed. Safety arguments or proofs are a way of demonstrating that a hazardous condition can never occur.

95

24.6

Quiz

1. What are the four stages of reliability validation? Establish and operational prole Design test data sets matching that prole Test the system and count system failures After observing a statistically signicant number of failures, compute the reliability 2. What is an operational prole?

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 development process? Creation of a hazard logging and monitoring system, Appointment of a project safety engineer, Extensive use of safety reviews, Creation of a safety certication system Use of detailed conguration management. 96

7. What are assertions and how are they used?

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

9. What are four complementary approaches to security checking? Experience-based validation, Tool-based validation, Tiger teams, Formal verication. 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 sta. To describe factors that inuence individual motivation. To discuss key issues of team working including composition, cohesiveness and communications. To introduce the people capability maturity model (P-CMM) - a framework for enhancing the capabilities of people in an organisation.

25.2

Topics covered

Selecting sta Motivating people Managing groups The people capability maturity model

25.3

Introduction

People are an organisations most important assets. The tasks of a manager are essentially people oriented. Unless there is some understanding of people, management will be unsuccessful. 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 without favourites or discrimination. Respect. Dierent team members have dierent skills and these dierences should be 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 going badly in a project.

25.5

Sta selection factors

Application domain experience Platform experience Programming language experience Educational background Communication ability Adaptability Attitude Personality

25.6

Key points

Sta selection factors include education, domain experience, adaptability and personality. People are motivated by interaction, recognition and personal development. Software development groups should be small and cohesive. Leaders should be competent 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 development team?

3. What are the dierent levels in the human needs hierarchy? Physiological needs, Safety needs, Social needs, Esteem needs, Self-realisation needs. 4. How can self-realisation needs be satised?

5. What are the three classes of people identied by Bass and Dunteman? Task-oriented people, Self-oriented people, Interaction-oriented people. 6. What are the four most important factors that inuence group working? Group composition, Group cohesiveness, Group communications, 100

Group organisation. 7. What is egoless programming?

8. What are the key factors that inuence the eectiveness of group communications? Group size, Group structure, Group composition, The physical work environment. 9. What environmental factors inuence 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 of their work force. To ensure that software development capability is an attribute of an organisation rather 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 dierent 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 stang

26.3

Introduction

Predicting the resources required for a software development process. The fundamental estimation questions are How much eort 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 Eort 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, sta 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 charged to the customer. Broader organisational, economic, political and business considerations inuence 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 prot.

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 diculties, 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 its development costs. Factors aecting productivity include individual aptitude, domain experience, the development 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 the limitations 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 quality is achieved in a software product. It involves dening appropriate quality standards and procedures and ensuring that these are followed. Should aim to develop a quality culture where quality is seen as everyones responsibility. Quality, simplistically, means that a product should meet its specication. This is problematical for software systems. There is a tension between 104

customer quality requirements (eciency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.). Quality management is particularly important for large, complex systems. The quality documentation is a record of progress and supports continuity of development as the development team changes. For smaller systems, quality management needs less documentation and 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 particular project and modify these as required. 3. Quality control. Ensure that procedures and standards are followed by the software development team.

27.5

Key points

Software quality management is concerned with ensuring that software meets its required standards. Quality assurance procedures should be documented in an organisational quality manual. 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 the software product. Product quality metrics should be used to identify potentially problematical components. 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. Briey describe the two types of standard that may be dened during the quality management process. Product standards that are applied to the software that is being developed. Process standards that dene the processes to be followed during software development. 3. Briey 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 identication 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 of components and derive some aggregate system measure. To identify anomalous components. 8. What is the dierence 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 dierent 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 inuence 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 improvement model

28.2

Topics covered

Process and product quality Process classication 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 reects the increasing attention paid by industry to quality. However, other process attributes can be the focus of improvement. Process quality and product quality are closely related and process improvement benets arise because the quality of the product depends on its development process.

28.4

Key points

Process improvement involves process analysis, standardisation, measurement and change. Processes can be classied as informal, managed, methodical and improving. This classication can be used to identify process tool support. The process improvement cycle involves process measurement, process analysis and process change. Process measurement should be used to answer specic process questions, based on organisational 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, communications, deliverables and other processes. The CMMI process maturity model integrates software and systems engineering process improvement. Process improvement in the CMMI model is based on reaching a set of goals related to 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 aect software product quality? Development technology, People quality, Cost, time and schedule, Process quality. 4. Briey describe 4 classes of software process. Informal processes with no dened 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. Briey describe the GQM paradigm. A set of goals which dene what the organisation is trying to achieve is dened. Associated questions that identify areas of uncertainty in achieving the goals are established. 110

The measurements needed to answer the questions are dened. 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 identied levels in the CMMI staged model? Initial, Managed, Dened, Quantitatively managed, Optimizing.

111

Chapter 29 Conguration Management

29.1 Objectives

To explain the importance of software conguration management (CM) To describe key CM activities namely CM planning, change management, version management and system building To discuss the use of CASE tools to support conguration management processes

29.2

Topics covered

Conguration management planning Change management Version and release management System building CASE tools for conguration management

29.3

Introduction

Conguration Management means textcolorredManaging the products of system change. CM is the development and application of standards and procedures for managing an evolving system product. New versions of software systems are created as they change: For dierent machines/OS Oering dierent functionality Tailored for particular user requirements 112

Conguration management is concerned with managing evolving software systems. System change is a team activity. CM aims to control the costs and eort involved in making changes to a system. Involves the development and application of procedures and standards to manage an evolving software product. May be seen as part of a more general quality management process.

29.4

Terminology

1. Version. An instance of a system which is functionally distinct in some way from other system instances. 2. Variant. An instance of a system which is functionally identical but non-functionally distinct from other instances of a system. 3. Release. An instance of a system which is distributed to users outside of the development team.

29.5

System releases

Systems are now normally released on CD-ROM or as downloadable installation les from the web. Not just a set of executable programs. May also include: 1. Conguration les dening how the release is congured for a particular installation. 2. Data les 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

Conguration management is the management of system change to software products. A formal document naming scheme should be established and documents should be managed in a database. The conguration data base should record information about changes and change requests. A consistent scheme of version identication should be established using version numbers, attributes or change sets. 113

29.7

Quiz

1. What is meant by conguration management? A controlled system where changes to the system have to be agreed and recorded b efore they are implemented. The development and use of standards and procedures for managing an evolving sof tware system. 2. What is a baseline?

3. What should be included in a conguration management plan? The conguration items to be managed, The people responsible for management, The conguration management policies, The CM tools to be used, The schema of the conguration database. 4. Why is it necessary to dene a conguration item identication scheme? Because there may be thousands of source code modules, test scripts, design docu ments, etc. in a large project. You have to be able to uniquely identify and loc ate any specic item and so a unique naming scheme is required. 5. What information may be included in a conguration database? Information about conguration items such as data of creation, creator, etc. Information about users of components, system customers, execution platforms, and proposed changes to the system. 6. What are the objectives of change management procedures? To analyse the costs and benets of proposed changes, approving changes that ar e worthwhile, 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 per spective rather than a technical perspective. They should decide if changes are worthwhile and should prioritise changes to be implemented. 8. What is the dierence between a system version and a system release? A system version is an instance of a system that diers, in some ways, from oth er instances. A system release is a version that is released to customers. 9. What are the advantages of attribute-based version identication? They reect the many attributes that may be used to identify versions. When selecting components, you do not need to specify the version number (an err or-prone process if there are many components) but simply list the required comp onent attributes. 10. What may be included in a system release? The executable code of a system, Conguration les, Data les, 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 les available? Are the data les 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 dierent 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 specication 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 denition 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 rst phase of the architectural design activity, a system is decomposed into a set of interacting sub-systems. Enumerate some specic models of the structure that may 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. Dene 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. Dene 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. Dene hardware reliability. Question 37. Dene 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 dierence between verication and validation? Question 45. What is the dierence between testing (verication 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 dierence 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 sta selection. Question 55. Enumerate the factors aecting software engineering productivity. Question 56. By dividing the eort required on a project by the development schedule gives me a useful indication of the number of people required by the project team. Comment this 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 aect software product quality. Question 62. The fundamental diculty in process measurement is knowing what to measure. The GQM paradigm (Basili and Rombach) relies on identication of what? Question 63. The SEI (Software Engineering Institute) model classies software processes into ve dierent 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 Lehmans 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 conguration 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 dierence between software engineering and computer science? Explain. Question 78. Can the physical environment aect the functioning of a software system adversely? Explain. Question 79. What development process should be used for a system that controls a cars brakes? Explain. Question 80. What are the steps after brainstorming for viewpoint-oriented requirements 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 system described as follows (the bold words are bold for a reason!). Document any further assumptions. 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 position (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 paragraphs. Columns have a text alignment (left, right, center, ll) and contain headings and paragraphs. 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 corresponds to 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 denitions 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 dierent items, which fall into two main categories: pasta and wine. The available types of pasta are lasagna, spaghetti and linguini, and the available types of wine are red and white. Question 87. Multiplication of positive integers can be viewed as the recursive application of integer addition. 1. Give a precise recursive denition of the multiplication operation without using any programming language notation. 2. Write a C++ function int multiply (int m, int n) that performs multiplication by recursive application of addition. Question 88. Exponentiation of a positive integer by a positive integer has a recursive structure. 1. Give a precise recursive denition of the exponentiation operation without using any programming language notation. 121

2. Write a C++ function int exp (int m, int n) that implements the recursive exponentiation. 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 of arbitrary 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) verication (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 specication. Explain why each of them is so important. Question 93. Briey 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. Briey describe THREE benets of using standards. Question 96. Describe the dierence 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 specication phase? Describe the main deliverables of this phase. Question 99. Write a Z schema that formalizes the following informal specication : 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 predened constant max Counter ctr : 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 denition (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 than the 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, dene Schema3 and Schema4 to be the conjunction, respectively disjunction of Schema1 and schema2. Schema1 x : X; y : Y A(x , y)

Schema2 z : Z; x : X B(z , x ) Question 104. The notation X 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 of exactly what the software should look like. What software model would you choose for this project? Explain why. Question 106. Finding software defects early lowers the cost of development. Explain how the waterfall model attempts to nd 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 in an XP team that is developing code for user authentication, i.e. it asks for a username and password, and it checks against a database. What test cases would you use? Be specic. 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 justied? 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 benets of Object-Oriented Programming? Question 114. Enumerate some pros and cons for COTS (Commercial O 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 personal information, courses taken and examination marks achieved. The alternative approaches to 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 this DBMS. 3. Join a consortium of other universities, establish a common set of requirements and contract a software house to develop a single system for all of the universities in the consortium. 125

Identify two possible risks (Risk1, Risk2) in each of these strategies and suggest techniques for risk resolution (Resolution 1, Resolution 2) which would help in deciding which approach to adopt. Question 116. If N is a constant, give formal specications 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 i array B is a permutation of array A. 2. Given three arrays A[1..N ], B [1..N ], C [1..N ] of integers, set each element of A equal to 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 nds the minimum values in an array of integers A[1..N ]. Question 117. Enumerate at least ve prototyping benets. 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. Dene 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 classication 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. Dene multiple inheritance. Question 138. What is object aggregation model? Question 139. What is the dierence between architectural design and software architecture? Question 140. Briey describe the activities in the architectural design process. Question 141. What is middleware? Question 142. Briey describe the main CORBA services. Question 143. Briey 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. Briey 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. Briey 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 specication? Question 154. What is system reliability engineering? Question 155. Whats the meaning of ROCOF = 0.0001? Question 156. Whats the meaning of MTTF = 1000? Question 157. An availability of 0.995 means what? Question 158. Whats the meaning of POFOD = 0.0001? 127

Question 159. What is structured programming? Question 160. What is fault tolerance? Question 161. Briey describe the types of testing. Question 162. Is it possible to apply software inspections to requirements? Question 163. What is the dierence between test data and test cases? Question 164. Briey describe the approaches to cluster testing. Question 165. What are safety proofs? Question 166. Compare Parkinsons law with Pricing to win. Question 167. Briey 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