Bài giảng Introduction to Software Engineering - Week 2: Software Processes - Nguyễn Thị Minh Tuyền

£ It is easier to get customer feedback on the development
 work that has been done.
 p Customers can comment on demonstrations of the software and
 see how much has been implemented.
£ More rapid delivery and deployment of useful software to
 the customer is possible.
 p Customers are able to use and gain value from the software earlier
 than is possible with a waterfall process.
 14
 Incremental development problems
£ The process is not visible.
 p Managers need regular deliverables to measure
 progress. If systems are developed quickly, it is not
 cost-effective to produce documents that reflect
 every version of the system.
£ System structure tends to degrade as new
 increments are added.
 p Unless time and money is spent on refactoring to
 improve the software, regular change tends to
 corrupt its structure. Incorporating further software
 changes becomes increasingly difficult and costly.
 15
 Integration and configuration
£ Based on systematic reuse where systems are integrated
 from existing components or COTS (Commercial-off-the-
 shelf) systems.
£ Reused elements may be configured to adapt their
 behaviour and functionality to a user’s requirements
£ Reuse is now the standard approach for building many
 types of business system
 16
 Types of reusable software
£ Stand-alone application systems (sometimes
 called COTS) that are configured for use in a
 particular environment.
£ Collections of objects that are developed as a
 package to be integrated with a component
 framework such as .NET or J2EE.
£ Web services that are developed according to
 service standards and which are available for
 remote invocation.
 17
 Reuse-oriented software 
 engineering
 Application system Configure
 Software available application 
 discovery system
Requirements Requirements
 specification refinement Adapt 
 components
 Software Integrate
 evaluation Components system
 available Develop new
 components
 18
 Advantages and drawbacks
£ Advantages
 p Reduced costs and risks as less software is
 developed from scratch
 p Faster delivery and deployment of system
£ Drawbacks
 p requirements compromises are inevitable
 ¡ this may lead to a system that does not meet the real needs
 of users.
 p Loss of control over evolution of reused system
 elements
 19
 Topics covered
1. Software process models
2. Process activities
3. Coping with change
4. Process improvement
 20
 Process activities
£ Real software processes are interleaved sequences of
 technical, collaborative and managerial activities with the
 overall goal of specifying, designing, implementing and
 testing a software system.
£ The four basic process activities of specification,
 development, validation and evolution are organized
 differently in different development processes.
£ For example:
 p In the waterfall model, they are organized in sequence,
 p In incremental development, they are interleaved.
 21
 Software specification
£ The process of establishing what services are required
 and the constraints on the system’s operation and
 development.
£ Requirements engineering process
 p Feasibility study: Is it technically and financially feasible to
 build the system?
 p Requirements elicitation and analysis: What do the system
 stakeholders require or expect from the system?
 p Requirements specification: Defining the requirements in
 detail
 p Requirements validation: Checking the validity of the
 requirements
 22
The requirements engineering process
 Requirements
 Feasibility
 elicitation and
 study
 analysis
 Requirements
 specification
 Feasibility Requirements
 report validation
 System
 models
 User and system
 requirements
 Requirements
 document
 23
 Software design and implementation
£ The process of converting the system specification into an
 executable system.
£ Software design
 p Design a software structure that realises the specification;
£ Implementation
 p Translate this structure into an executable program;
£ The activities of design and implementation are closely
 related and may be inter-leaved.
 24
A general model of the design process 
 Design inputs
 Platform Requirements Data
 information specification description
 Design activities
 Architectural Interface Component
 design design design
 Database design
 Design outputs
 System Database Interface Component
 architecture specification specification specification
 25
 Design activities
£ Architectural design, where you identify
 p the overall structure of the system,
 p the principal components, their relationships and how they are
 distributed.
£ Interface design
 p define the interfaces between system components.
£ Component selection and design
 p where you search for reusable components. If unavailable, you
 design how it will operate.
£ Database design
 p design the system data structures and how these are to be
 represented in a database.
 26
 System implementation
£ The software is implemented either by developing a
 program or programs or by configuring an application
 system.
£ Design and implementation are interleaved activities for
 most types of software system.
£ Programming is an individual activity with no standard
 process.
£ Debugging is the activity of finding program faults and
 correcting these faults.
 27
 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.
£ Testing is the most commonly used V & V activity.
 28
 Stages of testing
Component Acceptance
 System testing
 testing testing
 29
 Testing stages
£ Development or component testing
 p Individual components are tested independently;
 p Components may be functions or objects or
 coherent groupings of these entities.
£ System testing
 p Testing of the system as a whole. Testing of
 emergent properties is particularly important.
£ Acceptance testing
 p Testing with customer data to check that the system
 meets the customer's needs.
 30
 Testing phases in a plan-driven 
 software process
Requirements System System Detailed
 specification specification design design
 System Sub-system Module and
 Acceptance
 integration integration unit code
 test plan
 test plan test plan and test
 Acceptance System Sub-system
 Service
 test integration test integration test
 31
 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 this is increasingly irrelevant
 as fewer and fewer systems are completely new.
 32
 System evolution 
Define system Assess existing Propose system Modify
 requirements systems changes systems
 Existing New
 systems system
 33
 Topics covered
1. Software process models
2. Process activities
3. Coping with change
4. Process improvement
 34
 Coping with change
£ Change is inevitable in all large software
 projects.
 p Business changes lead to new and changed
 system requirements
 p New technologies open up new possibilities for
 improving implementations
 p Changing platforms require application changes
£ Change leads to rework so the costs of
 change include both rework as well as the
 costs of implementing new functionality
 35
 Reducing the costs of rework
£ Change anticipation (Change avoidance)
 p The software process includes activities that can
 anticipate possible changes before significant rework
 is required.
 p Example: a prototype system may be developed to
 show some key features of the system to customers.
£ Change tolerance
 p The process is designed so that changes can be
 accommodated at relatively low cost.
 p This involves some form of incremental development.
 36
 Coping with changing requirements
£ System prototyping
 p a version of the system or part of the system is
 developed quickly to check the customer’s requirements
 and the feasibility of design decisions.
 p This approach supports change anticipation.
£ Incremental delivery
 p system increments are delivered to the customer for
 comment and experimentation.
 p This supports both change avoidance and change
 tolerance.
 37
 Software prototyping
£ A prototype is an initial version of a system used to
 demonstrate concepts and try out design options.
£ A prototype can be used in:
 p The requirements engineering process to help with
 requirements elicitation and validation;
 p In design processes to explore options and develop a UI
 design;
 p In the testing process to run back-to-back tests.
 38
 Benefits of prototyping
£ Improved system usability.
£ A closer match to users’ real needs.
£ Improved design quality.
£ Improved maintainability.
£ Reduced development effort.
 39
The process of prototype development
 Establish Define
 prototype prototype Develop Evaluate
 objectives functionality prototype prototype
 Prototyping Outline Executable Evaluation
 plan definition prototype report
 40
 Prototype development
£ May be based on rapid prototyping languages or
 tools
£ May involve leaving out functionality
 p Prototype should focus on areas of the product that are
 not well-understood;
 p Error checking and recovery may not be included in the
 prototype;
 p Focus on functional rather than non-functional
 requirements such as reliability and security
 41
 Throwaway prototypes
£ Prototypes should be discarded after development
 as they are not a good basis for a production
 system:
 p It may be impossible to tune the system to meet non-
 functional requirements;
 p Prototypes are normally undocumented;
 p The prototype structure is usually degraded through
 rapid change;
 p The prototype probably will not meet normal
 organisational quality standards.
 42
 Incremental 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.
 43
 Incremental development and delivery
£ Incremental development
 p Develop the system in increments and evaluate each
 increment before proceeding to the development of the
 next increment;
 p Normal approach used in agile methods;
 p Evaluation done by user/customer proxy.
£ Incremental delivery
 p Deploy an increment for use by end-users;
 p More realistic evaluation about practical use of software;
 p Difficult to implement for replacement systems as
 increments have less functionality than the system being
 replaced.
 44
 Incremental delivery 
Define outline Assign requirements Design system Develop system
 requirements to increments architecture increment
 System
 incomplete?
 Validate Integrate Validate Deploy
 increment increment system increment
 System
 complete?
 Final
 system
 45
 Incremental delivery benefits
£ 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.
 46
 Incremental delivery problems
£ Most systems require a set of basic facilities that are
 used by different parts of the system.
 p As requirements are not defined in detail until an increment is to
 be implemented, it can be hard to identify common facilities that
 are needed by all increments.
£ The essence of iterative processes is that the
 specification is developed in conjunction with the
 software.
 p However, this conflicts with the procurement model of many
 organizations, where the complete system specification is part
 of the system development contract.
 47
 Topics covered
1. Software process models
2. Process activities
3. Coping with change
4. Process improvement
 48
 Process improvement
£ Many software companies have turned to software
 process improvement as a way of enhancing the
 quality of their software, reducing costs or
 accelerating their development processes.
£ Process improvement means understanding
 existing processes and changing these processes
 to increase product quality and/or reduce costs
 and development time.
 49
 Approaches to improvement
£ The process maturity approach, which focuses on
 improving process and project management and
 introducing good software engineering practice.
 p The level of process maturity reflects the extent to which good
 technical and management practice has been adopted in
 organizational software development processes.
£ The agile approach, which focuses on iterative
 development and the reduction of overheads in the
 software process.
 p The primary characteristics of agile methods are rapid delivery of
 functionality and responsiveness to changing customer
 requirements.
 50
The process improvement cycle
 Measure
Change Analyze
 51
 Process measurement
£ Wherever possible, quantitative process data should be
 collected
 p However, where organisations do not have clearly defined process
 standards this is very difficult as you don’t know what to measure. A
 process may have to be defined before any measurement is
 possible.
£ Process measurements should be used to assess process
 improvements
 p But this does not mean that measurements should drive the
 improvements. The improvement driver should be the
 organizational objectives.
 52
 Process metrics
£ Time taken for process activities to be completed
 p E.g. Calendar time or effort to complete an activity or process.
£ Resources required for processes or activities
 p E.g. Total effort in person-days.
£ Number of occurrences of a particular event
 p E.g. Number of defects discovered.
 53
 Capability maturity levels
 Level 5
 Optimizing
 Level 4
 Quantitatively
 managed
 Level 3
 Defined
 Level 2
 Managed
Level 1
 Initial
 54
 The SEI capability maturity model
£ Initial
 p Essentially uncontrolled
£ Repeatable
 p Product management procedures defined and used
£ Defined
 p Process management procedures and strategies defined
 and used
£ Managed
 p Quality management strategies defined and used
£ Optimising
 p Process improvement strategies defined and used
 55