CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

1
CTIS 359 PRINCIPLES OF SOFTWARE ENGINEERING

• WEEK 2
• LECTURE 1
• SOFTWARE PROCESSES

2
OBJECTIVES

• To understand the concept of software processes
  and software process models,
• To describe three generic process models and when
  they may be used,
• To describe activities involved in requirements
  engineering, software development, testing and
  evolution,
• To introduce CASE technology to support software
  process activities.

3
SOFTWARE PROCESS

• A software process is a set of activities that
  leads to the production of a software product.
• These activities may involve
• Development of software from scratch,
• Modifying existing systems,
• Configuring and integrating COTS software.

4
SOFTWARE PROCESS ACTIVITIES

• Although there are many software processes, some
  fundamental activities are common to all software
  processes
• Software Specification The functionality of the
  software and constraints on its operation must be
  defined,
• Software Design and Implementation The software
  to meet the specification must be produced,
• Software Validation The software must be
  validated to ensure that it does what the
  customer wants,
• Software Evolution The software must evolve to
  meet changing customer needs.

5
SOFTWARE PROCESS MODELS

• A software process model,also referred as life
  cycle model, is an abstract representation of a
  software process. They represent the framework of
  the process but not the details of specific
  activities.
• There are three fundamental software process
  models
• The waterfall model The fundamental process
  activities are represented as separate process
  phases.
• Evolutionary development The fundamental
  process activities are represented as interleaved
  process phases.
• Component-based software engineering The
  fundamental process activities involve
  integrating the components into a software system
  rather than developing them from scratch.

6
THE WATERFALL MODEL

• The first published model of the software
  development process was derived from more general
  system engineering process.
• Because of the cascade from one phase to another,
  this model is known as the waterfall.

7
THE WATERFALL MODEL
8
THE WATERFALL MODEL

• Requirements and definition The systems
  services and constraints are analyzed and defined
  as system specification.
• System and software design Partitions the
  requirements into either hardware or software
  systems.
• Implementation and unit testing Software design
  is implemeted and each software unit is tested.
• Integration and system testing Software units
  are integrated and tested as a complete system.
  Then the software system is delivered to the
  customer.
• Operation and maintenace Operation of software
  system starts. Errors are corrected,
  implementation is improved, and enhancements are
  made. Usually this is the longest phase.

9
ADVANTAGES OF THE WATERFALL MODEL

• The single requirements phase encourages
  specification of what the system is to do before
  deciding how the system will do it.
• The single design phase encourages planning of
  the system structure before implementation.
• The reviews at the end of each phase permits
  acquirer and user involvement.

10
DISADVANTAGES OF THE WATERFALL MODEL

• Inflexible partitioning of the project into
  distinct stages makes it difficult to respond to
  changing customer requirements.
• Therefore, this model is only appropriate when
  the requirements are well-understood and changes
  will be fairly limited during the design process.
  
• Few business systems have stable requirements.
• The waterfall model is mostly used for large
  systems engineering projects where a system is
  developed at several sites.
• It is difficult to assess the true state of
  progress in the first phases.
• A large integration and test effort must occur
  near the end of the project.

11
EVOLUTIONARY DEVELOPMENT

• Based on the idea of developing an initial
  implementation, exposing this to user comment and
  refining it through many versions until an
  adequate system has been developed.
• Specification, development, and validation
  activities are interleaved rather than separate.

12
EVOLUTIONARY DEVELOPMENT
13
ADVANTAGES OF EVOLUTIONARY DEVELOPMENT

• The model can be used when the requirements
  cannot and will not be specified.
• The user can experiment with the system to
  improve requirements.
• Greater user/acquirer involvement is required
  than the waterfall model.
• Immediate needs of the customer can be implemeted
  and delivered.

14
DISADVANTAGES OF EVOLUTIONARY DEVELOPMENT

• The process is not visible. Strong management is
  required to the measure the progress.
• It is often poorly structured and documented.

15
Comparison
Waterfall
Evolutionary
16
COMPONENT BASED SOFTWARE ENGINEERING

• Based on systematic reuse where systems are
  integrated from existing components or COTS
  (Commercial-off-the-shelf) systems.
• Process stages are
• Component analysis
• Requirements modification
• System design with reuse
• Development and integration
• This approach is becoming increasingly used as
  component standards have emerged.

17
COMPONENT BASED SOFTWARE ENGINEERING
18
ADVANTAGES OF COMPONENT BASED SOFTWARE ENGINEERING

• Reduced amount of software to be developed thus
  reduced cost and risk.
• Faster software delivery.

19
DISADVANTAGES OF COMPONENT BASED SOFTWARE
ENGINEERING

• Requirements are compromised.
• Control over system evolution is lost as new
  versions of the resuable components are nor under
  direct control.

20
PROCESS ITERATION

• Software process is not a one time event rather
  it is iterative.
• Requirements (new business, need to integrate
  with other systems)
• Design and implementation (new technologies
  become available)
• Iteration can be applied to any of the generic
  process models.
• Incremental delivery Software specification,
  design, and implementation are broken down into
  series of implements that are each developed in
  turn.
• Spiral development The development of the
  software spirals outwards from an initial outline
  through to the final developed software.

21
INCREMENTAL DELIVERY

• Rather than deliver the system as a single
  delivery, the development and delivery is broken
  down into increments with each increment
  delivering part of the required functionality.
• User requirements are prioritised and the highest
  priority requirements are included in early
  increments.
• Once the development of an increment is started,
  the requirements are frozen though requirements
  for later increments can continue to evolve.
• In between aproach between waterfall model and
  evolutionary development.

22
INCREMENTAL DELIVERY
23
INCREMENTAL DELIVERY
A model between waterfall and evolutionary
24
ADVANTAGES OF INCREMENTAL DELIVERY

• Customer value can be delivered with each
  increment so system functionality is available
  earlier.
• Early increments act as a prototype to help
  elicit requirements for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to
  receive the most testing.

25
DISADVANTAGES OF INCREMENTAL DELIVERY

• Increments should be small (no more than 20,000
  lines of code).
• Each increment should deliver some functionality.
  (It may be hard to map requirements to
  increments).
• A variant of the incremental approach extereme
  programming is based on development and delivery
  of very small increments of functionality.

26
SPIRAL DEVELOPMENT

• Process is represented as a spiral.
• Each loop in the spiral represents a phase in the
  process.
• No fixed phases such as specification or design -
  loops in the spiral are chosen depending on what
  is required.
• Risks are explicitly assessed and resolved
  throughout the process.

27
SPIRAL DEVELOPMENT
28
SPIRAL DEVELOPMENT

• Objective setting
• Specific objectives for the phase are identified.
• Risk assessment and reduction
• Risks are assessed and activities put in place to
  reduce the key risks.
• Development and validation
• A development model for the system is chosen
  which can be any of the generic models.
• Planning
• The project is reviewed and the next phase of the
  spiral is planned.

29
ADVANTAGES OF SPIRAL DEVELOPMENT

• It can accommodate different software models.
• Risk-driven approach might avoid potential
  difficulties.
• It focuses early attention on options.
• It focuses on eliminating errors early.
• It provides a framework for hardware-software
  system development.

30
DISADVANTAGES OF SPIRAL DEVELOPMENT

• Do not match to contract software.
• Assumes software will be developed internally.
• Contract software might not provide flexibility
  of step by step commitments.

31
SOFTWARE PROCESS MODEL SELECTION

• The software process models are not mutually
  exclusive and are often used together.
• The person whose job is to choose a model and the
  processes to be used to perform the tasks within
  the model is referred as process architect.
• After evaluating the strengths and weaknesses of
  each model, the process architect must select the
  best model appropriate for the project.

32
SOFTWARE PROCESS MODEL SELECTION

• Research and Reading Assignment
• In 1991, Alexander, L., and Davis, A. (1991).
  published Criteria for Selection of a Software
  Process Model, Proc. 15th IEEE International
  Conference Computer Software and Applications
  (COMPSAC91). IEEE CS Press, Los Alamitos, CA,
  pp. 521-528.

33
SOFTWARE PROCESS MODEL SELECTION

• The following lists some of the criteria that
  should be considered during evaluation of the
  models
• The tolerance of the model to the risks that are
  likely to be encountered,
• The extent to which the development organization
  has access to end users,
• How well defined the known requirements are,
• Importance of early functionality,
• The complexity of the problem and likely
  candidates for solutions,
• The anticipated frequency and magnitude of
  requirement changes,
• Organizations managerial capability.

34
PROCESS ACTIVITIES

• Software specification
• Software design and implementation
• Software validation
• Software evolution

35
SOFTWARE SPECIFICATION (REQUIREMENTS ENGINEERING)

• The process of establishing what services are
  required and the constraints on the systems
  operation and development.
• Requirements engineering process
• Feasibility study
• Requirements elicitation and analysis
• Requirements specification
• Requirements validation

36
SOFTWARE SPECIFICATION
37
FEASIBILITY STUDY

• An estimate of whether the identified user needs
  may be satisfied with current software and
  hardware technologies.
• If the system will be cost-effective from a
  business point of view?
• If it can be developed with the constraints?
• If the above are true, go ahead with more
  detailed analysis.

38
REQUIREMENTS ELICITATION AND ANALYSIS

• Extract and refine the system requirements
  through observation of existing systems,
  discusussions with potential users, etc.

39
REQUIREMENTS SPECIFICATION

• Translate the information gathered during the
  analysis activity into a requirements document.
• 2 types of documents
• User Requirements Abstract statements of the
  system requirements for the customer and end-user
  of the system.
• System Requirements Detailed descrition of the
  functionality to be provided.

40
REQUIREMENTS VALIDATION

• Checks the requirements for realism, consistency,
  and completeness.
• Requirements document is modified accordingly.

41
SOFTWARE DESIGN AND IMPLEMENTATION

• The process of converting the system
  specification into an executable system.
• Software design
• Design a software structure that realises the
  specification,
• Implementation
• Translate this structure into an executable
  program
• The activities of design and implementation are
  closely related and may be inter-leaved.

42
SOFTWARE DESIGN AND IMPLEMENTATION
43
ARCHITECTURAL DESIGN

• The sub-systems of the overall system and their
  relationships are identified and documented.

44
ABSTRACT SPECIFICATION

• For each sub-system, an abstract specification of
  its services and constraints is specified.

45
INTERFACE DESIGN

• For each sub-system, its interface with other
  sub-systems is designed and documented.

46
COMPONENT DESIGN

• Sub-system services are allocated to components
  and their interfaces are also designed.

47
DATA STRUCTURE DESIGN

• Data structures used in the system implementation
  are designed.

48
ALGORITHM DESIGN

• The algorithms used to provide services are
  designed.

49
SOFTWARE VALIDATION

• Verification and validation (V V) is intended
  to show that a system conforms to its
  specification and meets the requirements of the
  system customer.
• Involves checking and review processes and system
  testing.
• System testing involves executing the system with
  test cases that are derived from the
  specification of the real data to be processed by
  the system.

50
SOFTWARE TESTING
51
SOFTWARE TESTING STAGES

• Component or unit testing
• Individual components are tested independently.
• Components may be functions or objects or
  coherent groupings of these entities.
• System testing
• Testing of the system as a whole. Testing of
  emergent properties is particularly important.
• Acceptance testing
• Testing with customer data to check that the
  system meets the customers needs.

52
SOFTWARE TESTING PHASES
53
COMPONENT (UNIT) TESTING

• Individual components are tested to make sure
  they operate correctly. Components may be simple
  entitie such as functions or objects classes.

54
SYSTEM TESTING

• The components are integrated.
• This process is concerned with finding interface
  errors between the components.
• This process is also concerned that the system
  meets its functional and non-functional
  requirements.

55
ACCEPTANCE TESTING

• Final stage of testing before system is accepted
  for operational use.
• Real data is used for testing. As a result, it
  may reveal where the testing with simulated test
  data did not find.
• Acceptance testing is sometimes called alpha
  testing.

56
SOFTWARE EVOLUTION

• Software is inherently flexible and can change.
• As requirements change through changing business
  circumstances, the software that supports the
  business must also evolve and change.
• Although there has been a demarcation between
  development and evolution (maintenance) this is
  increasingly irrelevant as fewer and fewer
  systems are completely new.

57
SOFTWARE EVOLUTION
58
COMPUTER-AIDED SOFTWARE ENGINEERING (CASE)

• Computer-aided software engineering (CASE) is
  software to support software development and
  evolution processes.
• Activity automation
• Graphical editors for system model development,
• Graphical UI builder for user interface
  construction,
• Debuggers to support program fault finding.

59
CASE TECHNOLOGY

• Case technology has led to significant
  improvements in the software process. However,
  these are not the order of magnitude improvements
  that were once predicted
• Software engineering requires creative thought -
  this is not readily automated
• Software engineering is a team activity and, for
  large projects, much time is spent in team
  interactions. CASE technology does not really
  support these

60
CASE CLASSIFICATION

• Classification helps us understand the different
  types of CASE tools and their support for process
  activities.
• Functional perspective
• Tools are classified according to their specific
  function
• Process perspective
• Tools are classified according to process
  activities that are supported
• Integration perspective
• Tools are classified according to their
  organisation into integrated units

61
CASE FUNCTIONAL TOOL CLASSIFICATION
62
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 specification, 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.

63
KEY POINTS

• Requirements engineering is the process of
  developing a software specification.
• Design and implementation processes transform the
  specification to an executable program.
• Validation involves checking that the system
  meets to its specification and user needs.
• Evolution is concerned with modifying the system
  after it is in use.
• CASE technology supports software process
  activities.