Bài giảng Introduction to Software Engineering - Week 2: Software Processes - Nguyễn Thị Minh Tuyền
Week 2:
Software Processes
Nguyễn Thị Minh Tuyền
Topics covered
1. Software process models
2. Process activities
3. Coping with change
4. Process improvement
2
Definitions
£ What is a process?
£ Four activities that are fundamental to software
engineering?
£ What is process model?
3
The software process
£ A structured set of activities required to develop a
software system.
£ 4 fundamental activities:
p Specification – defining what the system should do;
p Design and implementation – defining the organization of the
system and i
p Validation – checking that it does what the customer wants;
p Evolution – changing the system in response to changing
customer needs.
£ A software process model
p Is an abstrac
p Presents a description of a process from some particular
perspective.
4
Software process descriptions
£ When we describe and discuss processes, we
usually talk about
p the activities in these processes such as specifying a
data model, designing a user interface, etc. and
p the ordering of these activities.
£ Process descriptions may also include:
p Products, which are the outcomes of a process activity;
p Roles, which reflect the responsibilities of the people
involved in the process;
p Pre- and post-conditions, which are statements that
are true before and after a process activity has been
enacted or a product produced.
5
Plan-driven and agile processes
£ Plan-driven processes are processes where all of
the process activities are planned in advance and
progress is measured against this plan.
£ In agile processes, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
£ In practice, most practical processes include
elements of both plan-driven and agile
approaches.
£ There are no right or wrong software processes.
6
Topics covered
1. Software process models
2. Process activities
3. Coping with change
4. Process improvement
7
Software process models
£ The waterfall model
p Plan-driven model. Separate and distinct phases of
specification and development.
£ Incremental development
p Specificatiovalidation are
interleaved. May be plan-driven or agile.
£ Reuse-oriented software engineering
p The system is assembled from existing components.
May be plan-driven or agile.
£ In practice, most large systems are developed
using a process that incorporates elements from
all of these models.
8
The waterfall model
Requirements
definition
System and
software design
Implementation
and unit testing
Integration and
system testing
Operation and
maintenance
9
Waterfall model phases
£ The main drawback of the waterfall model is the
difficulty of accommodating change after the
process is underway.
£ In principle, a phase has to be complete before
moving onto the next phase.
10
Waterfall model problems
£ Inflexible partitioning of the project into distinct stages
makes it difficult to respond to changing customer
requirements.
p Only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.
p Few businments.
£ Mostly used for large systems engineering projects
where a system is developed at several sites.
p The plan-driven nature of the waterfall model helps coordinate
the work.
11
£ An important variant of the waterfall model is
formal system development
p Use a mathematical model to specify a system.
p Use mathematical transformations that preserve its
consistency, into executable code.
p Mathematical transformations are correct: a program
generated in this way is consistent with its specification.
£ Formal development processes (B method for
example) are suited to the development of
systems that have stringent safety, reliability, or
security requirements.
12
Incremental development
Concurrent
activities
Initial
Specification
Development
Validation
version
Intermediate
versions
Outline
description
Final
version
13
Incremental development benefits
£ The cost of accommodating changing customer
requirements is reduced.
p The amount of analysis and documentation that has to be redone
is much less than is required with the waterfall model.
£ 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 ifurther 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
available
Software
discovery
application
system
Requirements
Requirements
specification
Adapt
components
Software
Integrate
system
evaluation
Components
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
Tải về để xem bản đầy đủ
55 trang
15360
Free
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Introduction to Software Engineering - Week 2: Software Processes - Nguyễn Thị Minh Tuyền", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- bai_giang_introduction_to_software_engineering_week_2_softwa.pdf
