US-SIT-302 Software Engineering

Unit 2

S.Y. B.Sc IT : Semester 3

Syllabus
⚫ 2.1 System Models: Models and its types, Context Models,
Behavioural Models, Data Models, Object Models, Structured
Methods.
⚫ 2.2 Requirements Engineering Processes: Feasibility study,
Requirements elicitation and analysis, Requirements Validations,
Requirements Management..
⚫ 2.3 Architectural Design: Architectural Design Decisions, System
Organisation, Modular Decomposition Styles, Control Styles,
Reference Architectures.
⚫ 2.4 User Interface Design: Need of UI design, Design issues, The
UI design Process, User analysis, User Interface Prototyping,
Interface Evaluation.
⚫ 2.5 Project Management : Software Project Management,
Management activities, Project Planning, Project Scheduling, Risk
Management
⚫ 2.6. Quality Management: Process and Product Quality, Quality
assurance and Standards, Quality Planning, Quality Control,
Software Measurement and Metrics.
2
System Models

3
System models:
⚫ Models are : Abstract descriptions of systems whose
requirements are being analysed .
⚫ Models and its types :
1. Context models
2. Behavioural models
3. Data models
4. Object models
5. Structured Methods

4
System modelling
⚫ System modelling helps the analyst to understand the
functionality of the system and models are used to
communicate with customers
⚫ Different models present the system from different
perspectives
⚫ External perspective showing the system’s context or
environment
⚫ Behavioural perspective showing the behaviour of the
system
⚫ Structural perspective showing the system or data
architecture

5
Model types
⚫ Data processing model showing how the data is processed
at different stages
⚫ Composition model showing how entities are composed of
other entities
⚫ Architectural model showing principal sub-systems
⚫ Classification model showing how entities have common
characteristics
⚫ Stimulus/response model showing the system’s reaction to
events

6
1. Context models
⚫ Context models are used to illustrate the boundaries of a
system
⚫ Social and organisational concerns may affect the decision
on where to position system boundaries
⚫ Architectural models show the a system and its
relationship with other systems

7
The context of an ATM system

8
 Process models
⚫ Process models show the overall process and the processes
that are supported by the system
⚫ Data flow models may be used to show the processes and
the flow of information from one process to another

9
2. Behavioural models
⚫ Behavioural models are used to describe the overall
behaviour of a system
⚫ Two types of behavioural model are shown here
⚫ Data processing models that show how data is processed as
it moves through the system
⚫ State machine models that show the systems response to
events
⚫ Both of these models are required for a description of the
system’s behaviour

10
3. Data-processing models
⚫ Data flow diagrams are used to model the system’s data
processing
⚫ These show the processing steps as data flows through a
system
⚫ Intrinsic part of many analysis methods
⚫ Simple and intuitive notation that customers can
understand
⚫ Show end-to-end processing of data

11
Order processing DFD

12
Data flow diagrams
⚫ DFDs model the system from a functional perspective
⚫ Tracking and documenting how the data associated with a
process is helpful to develop an overall understanding of
the system
⚫ Data flow diagrams may also be used in showing the data
exchange between a system and other systems in its
environment

13
CASE toolset DFD

14
State machine models
⚫ These model the behaviour of the system in response to
external and internal events
⚫ They show the system’s responses to stimuli so are often
used for modelling real-time systems
⚫ State machine models show system states as nodes and
events as arcs between these nodes. When an event occurs,
the system moves from one state to another
⚫ Statecharts are an integral part of the UML

15
Semantic data models
⚫ Semantic data models describe the logical structure of data
processed by the system.
⚫ An entity-relation-attribute model sets out
⚫ the entities in the system,
⚫ the relationships between these entities
⚫ and the entity attributes
⚫ Widely used in database design. Can readily be
implemented using relational databases.
⚫ No specific notation provided in the UML but objects and
associations can be used (VERY SIMILAR to CLASS
HIERARCHY DIAGRAMs)

16
4. Object models
⚫ Object models describe the system in terms of object classes
and their associations.
⚫ An object class is an abstraction over a set of objects with
common attributes and the services (operations) provided by
each object.
⚫ Various object models may be produced
⚫ Simple object models
⚫ Inheritance models
⚫ Aggregation models
⚫ Interaction models.

17
Object Model: Class Diagram
Class name

attributes

operations

18
Class
(Relationship)
Diagram

19
5. Structured methods
⚫ Structured methods incorporate system modelling as an
inherent part of the method
⚫ Methods define a set of models, a process for deriving
these models and rules and guidelines that should apply to
the models
⚫ CASE tools support system modelling as part of a
structured method

20
Method weaknesses
⚫ They do not model non-functional system requirements
⚫ They do not usually include information about whether a
method is appropriate for a given problem
⚫ The may produce too much documentation
⚫ The system models are sometimes too detailed and
difficult for users to understand

21
Requirements Engineering
Processes

22
Topics covered
⚫ Feasibility studies
⚫ Requirements elicitation and analysis
⚫ Requirements validation
⚫ Requirements management

23
Requirements engineering processes

⚫ The processes used for RE vary widely depending on the

application domain, the people involved and the
organisation developing the requirements.
⚫ However, there are a number of generic activities common
to all processes
⚫ Requirements elicitation;
⚫ Requirements analysis;
⚫ Requirements validation;
⚫ Requirements management.

24
The requirements engineering process

25
Requirements engineering

26
Feasibility studies
⚫ A feasibility study decides whether or not the proposed
system is worthwhile.
⚫ A short focused study that checks
⚫ If the system contributes to organisational objectives;
⚫ If the system can be engineered using current technology
and within budget;
⚫ If the system can be integrated with other systems that are
used.

27
Feasibility study implementation
⚫ Based on information assessment (what is required),
information collection and report writing.
⚫ Questions for people in the organisation
⚫ What if the system wasn’t implemented?
⚫ What are current process problems?
⚫ How will the proposed system help?
⚫ What will be the integration problems?
⚫ Is new technology needed? What skills?
⚫ What facilities must be supported by the proposed system?

28
Elicitation and analysis
⚫ Sometimes called requirements elicitation or requirements
discovery.
⚫ Involves technical staff working with customers to find out
about the application domain, the services that the system
should provide and the system’s operational constraints.
⚫ May involve end-users, managers, engineers involved in
maintenance, domain experts, trade unions, etc. These are
called stakeholders.

29
Requirements validation
⚫ Concerned with demonstrating that the requirements
define the system that the customer really wants.
⚫ Requirements error costs are high so validation is very
important
⚫ Fixing a requirements error after delivery may cost up to
100 times the cost of fixing an implementation error.

30
Requirements checking
⚫ Validity. Does the system provide the functions which best
support the customer’s needs?
⚫ Consistency. Are there any requirements conflicts?
⚫ Completeness. Are all functions required by the customer
included?
⚫ Realism. Can the requirements be implemented given available
budget and technology
⚫ Verifiability. Can the requirements be checked?

31
Requirements validation
techniques
⚫ Requirements reviews
⚫ Systematic manual analysis of the requirements.
⚫ Prototyping
⚫ Using an executable model of the system to check
requirements. Covered in Chapter 17.
⚫ Test-case generation
⚫ Developing tests for requirements to check testability.

32
Requirements management
⚫ Requirements management is the process of managing
changing requirements during the requirements engineering
process and system development.
⚫ Requirements are inevitably incomplete and inconsistent
⚫ New requirements emerge during the process as business needs change
and a better understanding of the system is developed;
⚫ Different viewpoints have different requirements and these are often
contradictory.

33
Requirements change
⚫ The priority of requirements from different viewpoints
changes during the development process.
⚫ System customers may specify requirements from a
business perspective that conflict with end-user
requirements.
⚫ The business and technical environment of the system
changes during its development.

34
Key points
⚫ The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification and requirements management.
⚫ Requirements elicitation and analysis is iterative involving
domain understanding, requirements collection,
classification, structuring, prioritisation and validation.
⚫ Systems have multiple stakeholders with different
requirements.

35
Key points
⚫ Social and organisation factors influence system
requirements.
⚫ Requirements validation is concerned with checks for
validity, consistency, completeness, realism and
verifiability.
⚫ Business changes inevitably lead to changing
requirements.
⚫ Requirements management includes planning and change
management.

36
Architectural Design

37
 Software architecture
• 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.

38
 Architectural design
• An early stage of the system design process
• Represents the link between specification and
design processes
• Often carried out in parallel with some
specification activities
• It involves identifying major system
components and their communications

39
 Advantages of explicit architecture

• Stakeholder communication
– Architecture may be used as a focus of discussion
by system stakeholders.
• System analysis
– Means that analysis of whether the system can
meet its non-functional requirements is possible.
• Large-scale reuse
– The architecture may be reusable across a range
of systems.

40
 Architectural design decisions
• Is there a generic application architecture that can
be used?
• How will the system be distributed?
• What architectural styles are appropriate?
• What approach will be used to structure the system?
• How will the system be decomposed into modules?
• What control strategy should be used?
• How will the architectural design be evaluated?
• How should the architecture be documented?

41
 Architectural models
• Used to document an architectural design.
• Static structural model that shows the major system
components.
• Dynamic process model that shows the process structure of
the system.
• Interface model that defines sub-system interfaces.
• Relationships model such as a data-flow model that shows
sub-system relationships.
• Distribution model that shows how sub-systems are
distributed across computers.

42
 System organization ( SLE )
• Reflects the basic strategy that is used to
structure a system.
• Three organisational styles are widely used:
– A shared data repository style;
– A shared services and servers style;
– An abstract machine or layered style.

43
 The repository model
• Sub-systems must exchange data. This may be
done in two ways:
– Shared data is held in a central database or
repository and may be accessed by all
sub-systems;
– Each sub-system maintains its own database and
passes data explicitly to other sub-systems.
• When large amounts of data are to be shared,
the repository model of sharing is most
commonly used.
44
 Modular Decomposition..
• Modular decomposition means dividing each subsystem
in modules and identifying interconnections between
modules
• Models described previously can be applied here as well
(a subsystem is, in fact, a system, and the distinction
between a subsystem and a module is relative)
• Styles that may be used for decomposition:
– Object-oriented decomposition: a subsystem consists of several
communicating objects
– Function-oriented pipelining: functional modules are identified,
together with data transfer paths

45 / 26
 Modular Decomposition.
• Partial object model of an invoicing system

46 / 26
 Control Styles
• Control models emphasize control flow
among subsystems
• Two general approaches:
– Centralized control: a single subsystem (central
controller) has the control responsibility of the
entire system; it may defer control to other
subsystems but the control must be returned to
the central controller
• Call-return model (top-down subroutine model)
• Manager model (applies to concurrent systems, in
which several processes run in parallel)
47 / 26
 Control Styles….
• Two general approaches (continued):
– Event-based control: each subsystem has control
responsibilities; they respond to events generated
by the environment and/or other subsystems
• Broadcast models: an event is dispatched to all
subsystems
• Interrupt-driven models: make use of interrupt
handlers; typical to RTS

48 / 26
 Control Styles...
• The call-return control model

49 / 26
 Control Styles..
• Example of a centralized control model: an RTS

50 / 26
 Control Styles.
• Control model with selective broadcasting

51 / 26
 Reference Architecture ( SLE )
• A domain-specific architecture is characteristic to a
particular application domain; it proposes a common
architectural structure that can be used across
applications within that particular domain
• In architectural design various design models can be
applied in combination

52 / 26
 Reference Architectures ( SLE )
• Main categories:
– Generic models: models extracted from real
systems that provide a common architectural
framework for new applications within the
domain (e.g., compiler design)
– Reference models: more abstract models that
communicate commonly used domain and
design concepts; derived from studying the
application domain (e.g., the Open Systems
Interconnection [OSI] reference model)

53 / 26
 Reference Architectures
• Example of reference architecture: the OSI model

54
User interface design

55
 Topics covered
• Need of UI design
• Design issues
• The user interface design process
• User analysis
• User interface
• Prototyping
• Interface evaluation

56
 The user interface
• 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.

57
 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 different
– People have a wide range of physical capabilities. Designers should not
just design for their own capabilities.
• People have different interaction preferences
– Some like pictures, some like text.

58
 Design principles
• User familiarity
– The interface should be based on user-oriented
terms and concepts rather than computer concepts. For example, an
office system should use concepts such as letters, documents, folders
etc. rather than directories, file identifiers, etc.
• Consistency
– The system should display an appropriate level
of consistency. Commands and menus should have the same format,
command punctuation should be similar, etc.
• Minimal surprise
– If a command operates in a known way, the user should be able to
predict the operation of comparable commands

59
 Design principles
• Recoverability
– The system should provide some resilience to
user errors and allow the user to recover from errors. This might
include an undo facility, confirmation of destructive actions, 'soft'
deletes, etc.
• User guidance
– Some user guidance such as help systems, on-line manuals, etc. should
be supplied
• User diversity
– Interaction facilities for different types of user should be supported.
For example, some users have seeing difficulties and so larger text
should be available

60
 Design issues in UIs
• Two problems must be addressed in interactive systems
design
– How should information from the user be provided to the computer
system?
– How should information from the computer system be presented to
the user?
• User interaction and information presentation may be
integrated through a coherent framework such as a user
interface metaphor.

61
 The UI design process
• UI design is an iterative process involving close
liaisons between users and designers.
• The 3 core activities in this process are:
– User analysis. Understand what the users will do
with the system;
– System prototyping. Develop a series of
prototypes for experiment;
– Interface evaluation. Experiment with these
prototypes with users.

62
The design process

63
 User analysis
• If you don’t understand what the users want
to do with a system, you have no realistic
prospect of designing an effective interface.
• User analyses have to be described in terms
that users and other designers can
understand.
• Scenarios where you describe typical episodes
of use, are one way of describing these
analyses.

64
 User interface prototyping
• The aim of prototyping is to allow users to
gain direct experience with the interface.
• Without such direct experience, it is
impossible to judge the usability of an
interface.
• Prototyping may be a two-stage process:
– Early in the process, paper prototypes may be
used;
– The design is then refined and increasingly
sophisticated automated prototypes are then
developed.
65
 Paper prototyping
• Work through scenarios using sketches of the
interface.
• Use a storyboard to present a series of
interactions with the system.
• Paper prototyping is an effective way of
getting user reactions to a design proposal.

66
 Prototyping techniques
• Script-driven prototyping
– Develop a set of scripts and screens using a tool
such as Macromedia Director. When the user
interacts with these, the screen changes to the
next display.
• Visual programming
– Use a language designed for rapid development
such as Visual Basic. See Chapter 17.
• Internet-based prototyping
– Use a web browser and associated scripts.

67
 User interface evaluation
• Some evaluation of a user interface design
should be carried out to assess its suitability.
• Full scale evaluation is very expensive and
impractical for most systems.
• Ideally, an interface should be evaluated
against a usability specification. However, it is
rare for such specifications to be produced.

68
Usability attributes

69
 Simple evaluation techniques
• Questionnaires for user feedback.
• Video recording of system use and subsequent
tape evaluation.
• Instrumentation of code to collect information
about facility use and user errors.
• The provision of code in the software to
collect on-line user feedback.

70
 Key points
• 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.

71
Project management

72
 Topics covered
• Software Project Management
• Management activities
• Project planning
• Project scheduling
• Risk management

73
 Software project management
• 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.
• Project management is needed because
software development is always subject to
budget and schedule constraints that are set
by the organisation developing the software.

74
Software management distinctions
• The product is intangible.
• The product is uniquely flexible.
• Software engineering is not recognized as an
engineering discipline with the same status as
mechanical, electrical engineering, etc.
• The software development process is not
standardised.
• Many software projects are 'one-off' projects.

75
 Project staffing
• May not be possible to appoint the ideal people to work on a
project
– Project budget may not allow for the use of highly-paid
staff;
– Staff with the appropriate experience may not be
available;
– An organisation may wish to develop employee skills on a
software project.
• Managers have to work within these constraints especially
when there are shortages of trained staff.

76
 Project planning
• Probably the most time-consuming project
management activity.
• Continuous activity from initial concept through
to system delivery. Plans must be regularly
revised as new information becomes available.
• Various different types of plan may be developed
to support the main software project plan that is
concerned with schedule and budget.

77
From here : Types of project plan

78
 Project planning process
Establish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop

79
 The project plan
• The project plan sets out:
– The resources available to the project;
– The work breakdown;
– A schedule for the work.

80
 Project plan structure
• Introduction.
• Project organisation.
• Risk analysis.
• Hardware and software resource
requirements.
• Work breakdown.
• Project schedule.
• Monitoring and reporting mechanisms.

81
 Project scheduling
• Split project into tasks and estimate time and
resources required to complete each task.
• Organize tasks concurrently to make optimal
use of workforce.
• Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete.
• Dependent on project managers intuition and
experience.

82
The project scheduling process

83
 Scheduling problems
• Estimating the difficulty of problems and
hence the cost of developing a solution is
hard.
• Productivity is not proportional to the number
of people working on a task.
• Adding people to a late project makes it later
because of communication overheads.
• The unexpected always happens. Always allow
contingency in planning.

84
 Risk management
• Risk management is concerned with
identifying risks and drawing up plans to
minimise their effect on a project.
• A risk is a probability that some adverse
circumstance will occur
– Project risks affect schedule or resources;
– Product risks affect the quality or performance of
the software being developed;
– Business risks affect the organisation developing
or procuring the software.

85
Software risks

86
 The risk management process
• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess the likelihood and consequences of these
risks;
• Risk planning
– Draw up plans to avoid or minimise the effects of
the risk;
• Risk monitoring
– Monitor the risks throughout the project;

87
The risk management process

88
 Risk identification
• Technology risks.
• People risks.
• Organisational risks.
• Requirements risks.
• Estimation risks.

89
Risks and risk types

90
 Risk analysis
• Assess probability and seriousness of each
risk.
• Probability may be very low, low, moderate,
high or very high.
• Risk effects might be catastrophic, serious,
tolerable or insignificant.

91
Risk analysis (i)

92
Risk analysis (ii)

93
 Risk planning
• Consider each risk and develop a strategy to
manage that risk.
• Avoidance strategies
– The probability that the risk will arise is reduced;
• Minimisation strategies
– The impact of the risk on the project or product
will be reduced;
• Contingency plans
– If the risk arises, contingency plans are plans to
deal with that risk;

94
Risk management strategies (i)

95
Risk management strategies (ii)

96
 Risk monitoring
• Assess each identified risks regularly to decide
whether or not it is becoming less or more
probable.
• Also assess whether the effects of the risk
have changed.
• Each key risk should be discussed at
management progress meetings.

97
Risk indicators

98
Quality Management

99
 Topics Covered

• Process and Product quality

• Quality Assurance and Standards
• Quality Planning
• Quality Control
• Software Measurement and Metrics

100
 What is quality?
• Quality, simplistically, means that a product should meet
its specification.
• This is problematical for software systems
– There is a tension between customer quality
requirements (efficiency, reliability, etc.) and developer
quality requirements (maintainability, reusability, etc.);
– Some quality requirements are difficult to specify in an
unambiguous way;
– Software specifications are usually incomplete and
often inconsistent.

101
 Quality management activities
• Quality assurance
– Establish organisational procedures and standards for
quality.
• Quality planning
– Select applicable procedures and standards for a particular
project and modify these as required.
• Quality control
– Ensure that procedures and standards are followed by the
software development team.
• Quality management should be separate from project
management to ensure independence.

102
Quality management and software development

103
 Process and product quality
• The quality of a developed product is
influenced by the quality of the production
process.
• This is important in software development as
some product quality attributes are hard to
assess.
• However, there is a very complex and poorly
understood relationship between software
processes and product quality.

104
 Process-based quality
• There is a straightforward link between process and product
in manufactured goods.
• More complex for software because:
– The application of individual skills and experience is particularly
imporant in software development;
– External factors such as the novelty of an application or the need for
an accelerated development schedule may impair product quality.
• Care must be taken not to impose inappropriate process
standards - these could reduce rather than improve the
product quality.

105
 Practical process quality
• Define process standards such as how reviews
should be conducted, configuration
management, etc.
• Monitor the development process to ensure
that standards are being followed.
• Report on the process to project management
and software procurer.
• Don’t use inappropriate practices simply
because standards have been established.

106
 Quality assurance and standards
• Standards are the key to effective quality
management.
• They may be international, national,
organizational or project standards.
• Product standards define characteristics that
all components should exhibit e.g. a common
programming style.
• Process standards define how the software
process should be enacted.

107
Product and process standards

108
 Quality planning
• A quality plan sets out the desired product
qualities and how these are assessed ande
define the most significant quality attributes
• It should define the quality assessment
process
• It should set out which organisational
standards should be applied and, if necessary,
define new standards

109
 Quality plan structure
• Product introduction
• Product plans
• Process descriptions
• Quality goals
• Risks and risk management
• Quality plans should be short, succinct
documents
– If they are too long, no-one will read them

110
Software quality attributes

111
 Quality control
• Checking the software development process
to ensure that procedures and standards are
being followed
• Two approaches to quality control
– Quality reviews
– Automated software assessment and software
measurement

112
 Quality reviews
• The principal method of validating the quality of a
process or of a product
• Group examined part or all of a process or system
and its documentation to find potential problems
• There are different types of review with different
objectives
– Inspections for defect removal (product)
– Reviews for progress assessment(product and
process)
– Quality reviews (product and standards)

113
Types of review

114
The review process

115
 Software measurement and metrics

• Software measurement is concerned with

deriving a numeric value for an attribute of a
software product or process
• This allows for objective comparisons
between techniques and processes
• Although some companies have introduced
measurment programmes, the systematic use
of measurement is still uncommon
• There are few standards in this area

116
 Software metric
• Any type of measurement which relates to a
software system, process or related
documentation
– Lines of code in a program, the Fog index, number of
person-days required to develop a component
• Allow the software and the software process to
be quantified
• Measures of the software process or product
• May be used to predict product attributes or to
control the software process

117
Predictor and control metrics

118
 Product metrics
• A quality metric should be a predictor of
product quality
• Classes of product metric
– Dynamic metrics which are collected by
measurements made of a program in execution
– Static metrics which are collected by measurements
made of the system representations
– Dynamic metrics help assess efficiency and reliability;
static metrics help assess complexity,
understandability and maintainability

119
Product measurement process

120
Software product metrics

121