SOFTWARE ENGINEERING

1
SOFTWARE ENGINEERING
2
Software

• Collection of programs, procedures, rules and
  associated documentation and data.
• Software engineers are concerned with developing
  software products.

3
Two types of software products
Generic products These are sold on open market
to any customer who is able to buy
them. Bespoke(or customised) products developed
specifically for a particular customer.
4
Software Engineering

• It is an engineering discipline which is
  concerned with all aspects of software production
  from the early stages of system specification
  through to maintaining the system after it has
  gone into use.

5
Engineering discipline

• Engineers makes things work by applying theory,
  methods and tools wherever they are appropriate
  and try to discover solutions when there are no
  applicable theories.

6
All aspects of software production

• Software engineering is not just concerned with
  the technical process of software development but
  also with activities such as software project
  management .

7
Computer Engineering

• Computer Engineering (also called Electronic and
  Computer Engineering , or Computer Systems
  Engineering) is a discipline that combines both
  Electronic Engineering and Computer Science.
  Computer engineers usually have training in
  electronic engineering, software design and
  hardware-software integration instead of only
  software engineering or electronic engineering.

8

• Computer engineers are involved in many aspects
  of computing, from the design of individual
  microprocessors, personal computers, and
  supercomputers, to circuit design. This field of
  engineering not only focuses on how computer
  systems themselves work, but also how they
  integrate into the larger picture.

9
Computer science and SE

• CS is concerned with theory and fundamentals SE
  is concerned with practicalities of developing
  and delivering useful software

10

• Some knowledge of CS is essential for software
  engineers as physics is needed for Electrical
  Engineers.

11
System Engineering

• System engineering is concerned with all aspects
  of computer based systems development including
  hardware, software and process engg. SE is a part
  of this.
• Systems engineering is an older discipline than
  SE.

12
Software process

• A set of activities whose goal is the development
  or evolution of software.
• Activities such as software specification,
  software development, software validation and
  software evolution.

13
Software process model

• A simplified representation of a software
  process, presented from a specific perspective.
• Some examples of the types of software process
  model which may be produced are
• Workflow model, dataflow/activity model
  and role/action model

14

• The general models of software development are
• Waterfall model
• Evolutionary model.
• Formal transformation etc.

15
Costs of SE

• 60 of costs are development costs, 40 are
  testing costs.
• For custom software evolution costs often exceed
  development costs.
• Costs of a software on a PC are often greater
  than the hardware cost.

16
CASE

• Software systems which are intended to provide
  automated support for software process activities.

17
Attributes of good software

• Software should deliver the required
  functionality and performance to the user and
  should be maintainable, dependable, portable and
  usable.

18
Challenges facing SE

• Coping with legacy systems
• Coping with increasing diversity
• Coping with demands for reduced delivery time.

19
Professional and ethical responsibility

• Confidentiality
• Competence
• Intellectual property right
• Computer misuse.

20
Phases in software development

• Software Development Lifecycle

21

• The main steps are
• Problem Definition
• Feasibility Study
• Analysis
• System Design
• Detailed Design
• Implementation
• Maintenance
• A separate planning step for large applications
  may be introduced after feasibility

22
Problem Definition

• To answer What is the Problem?
• Where and by whom is the problem felt?
• Meet users and Management and obtain their
  agreement that there is a problem
• If problem exists, and it needs to be solved
• Then it becomes a project

23

• Prepare a brief statement of problem
• This avoids misunderstandings
• This is to get concurrence from user/management
• Preparation is usually short 1 or 2 pages
• Estimate cost and schedule for the next
  feasibility step
• Estimate roughly overall project cost to give
  users a sense of project scope.

24

• Proper understanding and characterization of
  problem is essential
• It is to discover cause of the problem
• It is for planning directed investigation
• Otherwise, success is unlikely

25

• Possible reasons for initial characterization of
  problems
• Existing system has poor response time, i.e., it
  is slow
• Unable to handle workload
• Problem of cost existing system uneconomical
• Problem of accuracy and reliability
• Requisite information is not produced by system
• Problem of security

26
Problem Definition document

• Project Title
• Problem Statement Concise statement of problem,
  possibly in a few lines
• Project Objectives state objective of the
  project defined for the problem
• Preliminary Ideas possible solutions, if any,
  occurring to user and/or analyst could be stated
  here.

27

• Project Scope give overall cost estimate as
  approximate figure
• Feasibility Study indicate time and cost for the
  next step
• Note
• Do not confuse between problems and solutions
  e.g., develop computerized payroll cannot be a
  problem
• No commitment is implied to preliminary ideas it
  may change according to the situation

28
Feasibility Study

• To get better understanding of problems and
  reasons, by studying existing system, if
  available
• Are there feasible solutions?
• Is the problem worth solving?
• Consider different alternatives
• Essentially covers other steps of methodology
  (analysis, design, etc.) in a capsule form
• Estimate costs and benefits for each alternative

29

• Make a formal report and present it to management
  and users review here confirms the following
• Will alternatives be acceptable
• Are we solving the right problem
• Does any solution promise a significant return
• Users/management select an alternative
• Many projects die here

30
Types of Feasibility

• Economical will returns justify the investment
  in the project ?
• Technical is technology available to implement
  the alternative ?
• Operational will it be operationally feasible
  as per rules, regulations, laws, organizational
  culture, etc. ?

31
Costs

• One-time (initial) costs include equipment,
  training, software development, consultation,
  site preparation
• Recurring costs include salaries, supplies,
  maintenance, rentals, depreciation
• Fixed and variable costs vary with volume of
  workload

32
Benefits

• Benefits could be tangible (i.e. quantifiable) or
  intangible
• Saving (tangible benefits) could include
• Saving in salaries
• Saving in material or inventory costs
• More production
• Reduction in operational costs, etc.

33

• Intangible benefits may include
• Improved customer service
• Improved resource utilization
• Better control over activities (such as
  production, inventory, finances, etc.)
• Reduction in errors
• Ability to handle more workload

34
Estimating Costs

• How to estimate costs so early in the project?
• Decompose the system and estimate costs of
  components this is easier and more accurate than
  directly estimating cost for the whole system
• Use historical data whenever available
• Use organization's standards for computing
  overhead costs (managerial/secretarial support,
  space, electricity, etc.)
• Personnel (for development and operations) costs
  are function of time, hence estimate time first

35
Financial Analysis

• Consider time-value of money while investment is
  today, benefits are in future!
• Compute present value P for future benefit F by
• P F/ (1I)n
• where I is prevailing interest rate and n is
  year of benefit
• Take into account life of system most systems
  have life of 5-7 years

36

• Cost is investment in the project, benefits
  represent return
• Compute payback period in which we recover
  initial investment through accumulated benefits
• Payback period is expected to be less than system
  life !
• Are there better investment alternatives?

37
FEASIBILITY STUDY
1.0 Introduction A brief statement of the
problem, the environment in which the system is
to be implemented, and constraints that affect
the project 2.0 Management Summary and
Recommendations Important findings and
recommendations 3.0 Alternatives A presentation
of alternative system specifications criteria
that were used in selecting the final approach
38
4.0 System Description An abbreviated version
of information contained in the
System-Specification or reference to the
specifications 5.0 Cost-Benefit Analysis 6.0
Evaluation of Technical Risk 7.0 Legal
Ramifications (if any) 8.0 Other Project-Specific
Topics
39
Requirements Analysis

• Objective determine what the system must do to
  solve the problem (without describing how)
• This is usually done by Analyst (also called
  Requirements Analyst)
• He produce Software Requirements Specifications
  (SRS) document
• Incorrect, incomplete, inconsistent, ambiguous
  SRS often cause for project failures and disputes

40

• A very challenging task
• Users may not know exactly what is needed
• Users change their mind over time
• They may have conflicting demands
• They cant differentiate between what is possible
  and cost-effective against what is impractical
  (wish-list)
• Analyst has no or limited domain knowledge
• Often client is different from the users

41
SRS

• SRS is the basis for subsequent design and
  implementation
• First and most important baseline
• Defines contract with users
• Basis for validation and acceptance
• Cost increases rapidly after this step defects
  if not captured here, becomes 2 to 25 times more
  costly to remove later

42

• It identifies all functional (inputs, outputs,
  processing) and performance requirements, and
  also other important constraints (legal, social,
  operational)
• Should be adequately detailed so that
• Users can visualize what they will get
• Design and implementation can be carried out

43

• Covers what and how at business level e.g.,
• What calculate take-home pay
• How procedure (allowances, deductions, taxes
  etc.)

44
Analysis Process

• Here interviewing of the clients and users are
  essential to understand their needs from the
  system
• Existing documents and current mode of operations
  can be studied

45

• If it is a long process it needs to be organized
  systematically
• Interviewing, correlating, identifying gaps, and
  iterating again for more details
• Focus on what gets done or needs to be done

46

• Interview users or get details through
  questionnaires
• Examine existing system study existing forms,
  outputs, records kept (files, ledgers,
  computerized systems)

47
Interviews

• Identify users, their roles and plan interviews
  in proper order to collect details progressively
  and systematically
• Conducting interviews is an art !
• Need good communication skills, domain knowledge,
  patience,

48
Organizing Findings

• Massive amount of information is collected from
  interviews, study of existing systems
• Need to be organized, recorded, classified and
  conceptualized (at multiple level of details)

49

• Data-flow diagrams (for processing),
  entity-relationship models (for data domain) and
  object models commonly used
• SRS format is great help in organizing
  requirements in details

50
Structured Analysis

• Focuses on functions/processes and data flowing
  between them
• Uses top-down decomposition approach
• Initially see the application as a single process
  and identify inputs, outputs, users and data
  sources
• Decompose the process into sub processes, show
  data flows for them
• Function Decomposition and Data Flow Diagrams
  (FDD, DFD) very useful

51
Structured Methodology

• Study existing system What is done and how
• Prepare physical current DFD
• Convert this DFD to logical DFD
• Remove physical implementation-specific details
• Define boundary for automation (scope)
• Prepare DFD for proposed system - requires
  innovation, experience, vision
• Incorporate new needs
• Improve work flows (BPR business process
  re-engg)
• Introduce efficiency/effectiveness

52
Requirement Specification Format

• (Based on IEEE Recommendation)
• 1. Introduction
• 1.1 PURPOSE clearly state purpose of this
  document
• 1.2 SCOPE by whom and how it will be used
• 1.3 Definitions Acronyms, Abbreviations as
  applicable
• 1.4 REFRENCES to other documents
• 1.5 Overview of Developers Responsibilities In
  terms of development, installation, training,
  maintenance, etc.

53
Requirement Specification Format

• 2. GENERAL DESCRIPTION
• 2.1 PRODUCT PERSPECTIVE relationship with other
  products and principle interfaces
• 2.2 PRODUCT FUNCTIONS OVERVIEW general overview
  of tasks including data flow diagrams
• 2.3 USER CHARACTERISTICS who they are and what
  training they may need
• 2.4 GENERAL CONSTRAINTS about schedule,
  resources, cost, etc.

54

• 3.1 FUNCTIONAL REQUIREMENT
• 3.1.1 INTRODUCTION
• 3.1.2 INPUTS
• 3.1.3 PROCESSING
• 3.1.4 OUTPUTS
• 3.2.. (repeat similarly for each function)

55

• 4. External Interface Requirements
• 4.1 User Interfaces a preliminary user manual
  giving commands, screen formats, outputs,
  errors messages, etc.
• 4.2 Hardware Interfaces with existing as well as
  new or special purpose hardware
• 4.3 Software Interfaces with other software
  packages, operating systems, etc.
• 5. Performance Requirements
• Capacity requirements (no of users, no of
  files), response time, through-put (in measurable
  terms)

56

• 6. Design Constraints
• 6.1 Standards Compliance software development
  standards as well as organizational standards
  (e.g., for reports, auditing)
• 6.2 Hardware Limitations available machines,
  operating systems, storage capacities, etc.
• 7 Other Requirements
• Possible future extensions
• Note
• All sections are not required for all projects.

57
System Design

• Objective To formulate alternatives about how
  the problem should be solved
• Input is SRS from previous step
• Consider several technical alternatives based on
  type of technology, automation boundaries, type
  of solutions (batch/on-line), including make or
  buy
• Propose a range of alternatives low-cost,
  medium cost and comprehensive high cost solutions

58
Alternatives

• For each alternative, prepare high-level system
  design (in terms of architecture, DB design, )
  prepare implementation schedule, carry out
  cost-benefit analysis
• Prepare for technical and management review
• Costs rise sharply hereafter
• Costs can be quantified better at this stage
• Technical review uncovers errors, checks
  consistency, completeness, alternatives,
• Phase ends with a clear choice

59
Design goals

• Processing component main alternatives
• Hierarchical modular structure in functional
  approach
• Object-oriented model and implementation
• Different design methodologies for functional and
  OO
• Data component
• Normalized data base design using ER model
• De-normalization for performance
• Physical design indexes

60
System Architecture

• Decompose a complex system
• Partitions (vertical)
• Layers (horizontal)
• Define subsystems/modules as building blocks
• Modules make calls on each other
• Pass data, obtain results
• Maximize module independence and minimize module
  interdependence
• Cohesion and coupling characteristics
• Essential for maintenance
• Decompose until manageable units for coding and
  testing obtained

61
Structure Chart

• Used in functional methodology to depict modules
  and their calling relationships
• Hierarchical structure module at level i calls
  modules at level i1 control flow not shown
• Modules at higher levels generally do
  coordination and control modules at lower levels
  do i/o and computations
• Structure chart may show important data passing
  between modules, and also show main iterations
  and decision-making without much details
• Techniques are available to go from DFD to
  structure charts

62
Structure Chart Notation

• Modules on level 2 can be decomposed further

63
(No Transcript)
64
OO Approach

• Large systems decomposed into packages
• Design consists of classes
• Have structure (properties)
• Have behavior (methods/operations)
• Inheritance major feature in OO for re-use
• Class diagrams show static structure of the
  system
• Interaction diagrams are used to capture dynamic
  behavior of classes and objects

65
Design Document Format

• 1. Introduction
• 2. Problem Specification include here the
  data-flow diagrams, entry-relationship diagrams
• 3. Software structure give the high-level
  software structure chart identifying major
  modules and major data elements in their
  interfaces
• 4. Data Definitions for major data structure,
  files and database
• 5. Module Specifications indicate inputs,
  outputs, purpose and subordinate modules for each
  software module
• 6. Requirements Tracing indicate which modules
  meet which requirements

66
Detailed Design

• Specific implementation alternative already
  selected in previous step giving
• Overall software structure
• Modules to be coded
• Database/file design
• In this step, each component is defined further
  for implementation

67

• Deliverables include
• Program specifications (e.g. psuedo-code)
• File design (organization, access method)
• Hardware specifications (as applicable)
• Test plans
• Implementation schedule
• Ends in technical review

68
Implementation

• Programs are coded, debugged and documented
• Initial creation of data files and their
  verification
• Individual modules as well as whole system
  istested
• Operating procedures are designed
• User does the acceptance of the system
• System is installed and switch-over is affected

69
Operations Maintenance

• Systems must continue to serve user needs
  correctly and continuously
• Maintenance activities consist of
• Removing errors
• Extending present functions
• Adding new functions
• Porting to new platforms

70
Data Dictionary

• It is a repository (i.e., catalog) of information
  about a system (which gets collected during
  various phases)
• Definition of data
• Structure of data
• Usage of data (in processing)

71
Software process models

• A software process model is an abstract
  representation of a software process.
• Each process model represents a process from a
  particular perspective so only provides partial
  information about that process.

72

• Process models are sometimes called process
  paradigms.

73
Waterfall model

• Simplest process model
• Phases are organised in a linear order
• Proposed by Royce
• Also called classic life cycle.

74

• This model takes the fundamental process
  activities of specification, development,
  validation an evolution and represents them as
  separate process phases such as requirements
  specification, software design, implementation,
  testing and so on.

75
(No Transcript)
76
Requirements analysis and definition
77

• The system services, constraints and goals are
  established in consultation with the system user.
  They are then defined in detail and serve as the
  system specifiation.

78
System and software design

• The systems design process partitions the
  requirements to either hardware or software
  systems. It establishes an overall system
  architecture. Software design involves
  identifying and describing the fundamental
  software system abstractions and their
  relationships.

79
Implementation and unit testing

• During this stage the software design is realised
  as a set orf programs. Unit testing involves
  verifying that each unit meets its specification.

80
Integration and system testing

• The individual program units are integrated and
  tested as a complete system to ensure that the
  software requirements are met. After testing, the
  software system is delivered.

81
Operation and maintenance

• The longest phase
• The system is installed and put into practical
  use. Maintenance involves correcting errors which
  were not discovered in earlier stages of the life
  cycle, improving the implementation of the system
  units and enhancing the services as new
  requirements are discovered.

82

• Here we have to clearly identify the end of a
  phase and the beginning of the next. Ensure that
  the output of a phase (work products) is
  consistent with the input (output from the
  previous phase) . The result of each phase is one
  or more documents which are approved. The
  following phase should not start until the
  previous phase has finished.

83

• Eg. For coding phase code is the output.

84
Limitations

• It assumes that the requirements of a system can
  be frozen before the design begins.
• This is possible where we have manual systems.
• But for new systems it is difficult.

85

• Freezing the requirements usually requires
  choosing the hardware.
• The entire software is delivered at the end.
• It is a document driven process that requires
  formal documents at the end of each phase.

86
Evolutionary Development

• This approach interleaves the activities of
  specification, development and validation. An
  initial system is rapidly developed from abstract
  specifications. This is then refined with
  customer input to produce a system which
  satisfies the customers needs.

87

• Evolutionary development is based on the idea of
  developing an initial implementation, exposing
  this to the user comment and refining this
  through many versions until an adequate system
  has been developed. Rather than have separate
  specification, development and validation
  activities, these are carried out concurrently
  with rapid feedback across these activities.

88
(No Transcript)
89
Two types of evolutionary development

• Exploratory development where the objective of
  the process is to work with the customer to
  explore their requirements and deliver a final
  system. The development starts with the parts of
  the system which are understood. The system
  evolves by adding new features as they are
  proposed by the customer.

90

• Throw-away prototyping where the objective of the
  evolutionary development process is to understand
  the customers requirements and hence develop a
  better requirements definition for the system.
  The prototype concentrates on experimenting with
  those parts of the customer requirements that are
  poorly understood.

91

• An evolutionary approach is often more effective
  than the waterfall model approach in producing
  systems which meet the immediate needs of the
  customer.

92
Advantage

• Specification can be developed incrementally
• As users develop a better understanding of the
  problem this can be reflected in the software
  system.

93
Disadvantage

• The process is not visible
• Managers need regular deliverables to measure
  progress. If systems are developed quickly, it is
  not cost-effective to produce documents which
  reflect every version of the system.

94

• Systems are often poorly structured
• Continual changes tends to corrupt the software
  structure.

95

• Special tools and techniques may be required.
• Tools may be incompatible with other tools.
• Few people have the skills which are needed to
  use them.

96
Formal systems development

• This approach to software development has
  something in common with the waterfall model but
  where the development process is based on formal
  mathematical transformation of a system
  specification to an executable program.

97
Formal systems Development
98
Formal transformation
99
Difference from waterfall model

• The software requirements specification is
  refined into a detailed formal specification
  which is expressed in a mathematical notation.

100

• The development process of design, implementation
  and unit testing are replaced by a
  transformational development process where the
  formal specification is refined, through a series
  of transformations, into a program.

101

• In the transformation process, the formal
  mathematical representation of the system is
  systematically converted into a more detailed
  but still mathematically correct system
  representation. Each step adds detail
• until the formal specification is converted into
  an equivalent program.

102

• Transformations are sufficiently close that the
  effort of verifying the transformation is not
  excessive. It can therefore be guaranteed,
  assuming there are no verification errors that
  the program is a true implementation of the
  specification.

103
Reuse oriented development

• In majority of software projects there is some
  reuse. This usually happens informally.
• Developers know the design or code that is
  similar to the one required.
• They will do the necessary modification and
  incorporate them into their system.
• Reuse essential for evolutionary approach

104

• This informal reuse takes place irrespective of
  the generic process which is used.
• An approach to software development (Component
  based software engineering) which relies on reuse
  has emerged and is widely used.

105
(No Transcript)
106

• This reuse oriented approach relies on a large
  base of reusable software components which can be
  accessed and some integrating framework for these
  components. These systems may be COTS which may
  be used to provide specific functionality.

107
Intermediate stages

• Component analysis
• Given the requirements specification, a search is
  made for components to implement the
  specification. Usually there is not an exact
  match and the components which may be used
  provide only some of the functionality required.

108

• Requirements modification
• During this stage, the requirements are analysed
  using information about the components which have
  been discovered. They are then modified to
  reflect the available components. Where
  modification are impossible, the component
  analysis activity may be re-entered to search for
  alternatives.

109

• System design with reuse
• During this phase, the framework of the system is
  designed or an existing framework is reused. The
  designers take into account the components which
  are reused and organize the framework to cater
  for this. Some new software may have to be
  designed if reusable components are not
  available.

110

• Development and integration
• Software which cannot be bought in is developed
  and the components and COTS system are integrated
  to create the system. System integration, in this
  model, may be a part of the development process
  rather than a separate activity.

111
Advantages

• Reduces amount of software to be developed.
• Reduces costs and risks.
• Faster delivery

112
Disadvantages

• System may not meet the real needs of the user.

113
Hybrid model

• In the case of a large system different
  approaches have to be used in different parts.
  Also it is a need to support process iteration
  where parts of the process are repeated as system
  requirements evolve.

114
Hybrid models with process iteration

• Incremental development
• Here software specification, design and
  implementation is broken into a series of
  increments which are developed in turn.
• Spiral development
• Here the development of the system spirals
  outwards from an initial outline through to the
  final developed system.

115
Spiral development

• Proposed by Boehm
• Widely known
• Process is represented as spiral.
• Innermost loop system feasibility, then
  requirements definition, then design and so on
• Each loop is split into 4 sectors.

116
(No Transcript)
117
Objective setting

• Specific objectives for that phase of the project
  are defined.
• Constraints on the process and the product are
  identified and a detailed management plan is
  drawn. Project risks are identified.
• Alternative strategies depending on these risks
  may be planned.

118
Risk assessment and reduction

• For each of the identified risks, a detailed
  analysis is carried out.
• Steps are taken to reduce the risk.

119
Development and validation

• After risk evaluation, a development model for
  the system is chosen.
• eg.
• Dominancy of user interface risks - evolutionary
  development model
• Safety risks formal transformations
• Sub-system integration waterfall model

120
Planning

• The project is reviewed and a decision is made
  whether to continue with a further loop of the
  spiral. If it is decided to continue, plans are
  drawn for the next phase.

121
Benefit

• Consideration of risks
• While using new languages
• Schedule
• Cost overrun

122
Increment development

• Suggested by Mills
• A means of reducing rework in the development
  process
• Give costumers some opportunity to delay
  decisions on their detailed decisions until they
  have some experience with the system.
• Recent development is called as extreme
  programming developed by Beck.

123
System incomplete
124

• In an incremental development process, customers
  identify, in outline the services to be provided
  by the system. They identify which of the
  services are important and which are least
  important. A number of delivery increments are
  then defined, with each increment providing a
  subset of system functionality. The allocation of
  services to increments depends on the service
  priority. The highest priority services are
  delivered first.

125

• Once system increments have been identified , the
  requirement for the services to be delivered in
  the first increment is defined in detail and that
  increment is developed using the most appropriate
  development process. During that development,
  further requirement analysis for the later
  increments can take place but requirement changes
  for the current increment are not accepted.

126

• Once an increment is completed and delivered,
  customers can put it into service. This means
  they take early delivery of the part of the
  system functionality. They can experiment with
  the system which helps them clarify their
  requirements for the later increments and for the
  later versions of the current increment.

127

• As new increments are completed, they are
  integrated with existing increments so that the
  system functionality improves with each delivered
  increment. The common services may be implemented
  early in the processes or may be implemented
  incrementally as functionality is required by an
  increment.

128

• No need to use the same process for the
  development of each increment.
• Where the services in an increment have a well
  defined specification, a waterfall model may be
  used for that increment.
• If specification unclear use evolutionary
  development.

129

• An example of this incremental approach is
  observed in the development of word processing
  applications where the following services are
  provided on subsequent builds
• 1.      Basic file management, editing and
  document production functions
• 2.      Advanced editing and document production
  functions
• 3.      Spell and grammar checking
• 4.      Advance page layout

130
Advantages

• Customers do not have to wait until the entire
  system is delivered.
• Customers can use the early increments in the
  form of prototype and gain experience
• There is a lower risk of overall project failure.

131

• As the highest priority services are delivered
  first and later increments are integrated with
  them, it is inevitable that the most important
  system services receive the most testing.