Software processes (CÔNG NGHỆ PHẦN mềm SLIDE)

 Trong các quy trình agile, lập kế hoạch gia tăng và dễ dàng thay đổi quy trình để phản ánh các yêu cầu thay đổi của khách hàng..  Do đó, mô hình này chỉ phù hợp khi các yêu cầu được

Chapter 2 – Software Processes

Chapter 2 Software Processes 1

tượng của một tiến trình Nó trình bày một mô tả của

Mô tả quy trình phần mềm

thường nói về các hoạt động trong các quy trình này

như chỉ định mô hình dữ liệu, thiết kế giao diện người

dùng, v.v và thứ tự các hoạt động này

• Sản phẩm, là kết quả của một quy trình hoạt động ;

• Vai trò, phản ánh trách nhiệm của những người liên quan đến quá trình;

• điều kiện trước và sau, đó là những tuyên bố đúng trước và sau khi một hoạt động quy trình đã được ban hành hoặc một sản

phẩm được sản xuất.

Quy trình Plan-driven và agile

hoạt động của quy trình được lên kế hoạch trước và tiến độ được đo lường theo kế hoạch này.

 Trong các quy trình agile, lập kế hoạch gia tăng và

dễ dàng thay đổi quy trình để phản ánh các yêu cầu thay đổi của khách hàng.

 Trong thực tế, hầu hết các quy trình thực tế bao gồm các yếu tố của cả hai phương pháp Plan-driven và agile.

 Không có quy trình phần mềm đúng hay sai.

Chapter 2 Software Processes 5

Mô hình quy trình phần mềm

 Integration and configuration

 Hệ thống được lắp ráp từ các thành phần cấu hình hiện có Có thể được lập kế hoạch theo định hướng hoặc nhanh nhẹn

bằng cách sử dụng một quá trình kết hợp các yếu tố từ

tất cả các mô hình này

Chapter 2 Software Processes 7

The waterfall model

thay đổi (dễ tính) sau khi quá trình đang được tiến hành

Về nguyên tắc, một giai đoạn phải được hoàn thành

trước khi chuyển sang giai đoạn tiếp theo

Chapter 2 Software Processes 9

Vấn đề của mô hình Waterfall

riêng biệt làm cho việc xử lý các yêu cầu của khách

hàng thay đổi trở nên khó khăn

 Do đó, mô hình này chỉ phù hợp khi các yêu cầu được hiểu rõ

và các thay đổi sẽ bị hạn chế trong quá trình thiết kế.

 Rất ít hệ thống kinh doanh có yêu cầu ổn định.

án kỹ thuật hệ thống lớn, nơi một hệ thống được phát triển tại một số địa điểm

 Trong những trường hợp đó, bản chất định hướng của mô hình thác nước giúp điều phối công việc.

Incremental development

Chapter 2 Software Processes 11

Lợi ích của Incremental development

 Số lượng phân tích và tài liệu phải được làm lại ít hơn nhiều so với yêu cầu với mô hình waterfall.

triển đã được thực hiện dễ dàng hơn

 Khách hàng có thể bình luận về các giai đoạn của phần mềm và xem có bao nhiêu phần đã được triển khai.

ích cho khách hàng

 Khách hàng có thể sử dụng và đạt được giá trị từ phần mềm

sớm hơn là có thể với quy trình waterfall.

Vấn đề của Incremental development

 Người quản lý cần phân phôi thường xuyên để đo lường tiến

độ Nếu các hệ thống được phát triển một cách nhanh chóng,

nó không tiết kiệm chi phí để sản xuất các tài liệu phản ánh mọi phiên bản của hệ thống.

được thêm vào

 Trừ khi thời gian và tiền bạc được chi cho việc tái cấu trúc để cải thiện phần mềm, thay đổi thường xuyên có xu hướng làm hỏng cấu trúc của nó Kết hợp thêm các thay đổi phần mềm ngày

càng trở nên khó khăn và tốn kém.

Chapter 2 Software Processes 13

Integration and configuration

được tích hợp từ các thành phần hiện có hoặc các hệ thống ứng dụng (đôi khi được gọi là các hệ thống COTS -Commercial-off-the-shelf))

để điều chỉnh hành vi và chức năng của chúng theo yêu cầu của người dùng

nhiều loại hệ thống kinh doanh

 Tái sử dụng được đề cập sâu hơn trong Chapter 15.

Các loại phần mềm tái sử dụng

COTS) được cấu hình để sử dụng trong một môi trường

cụ thể

gói được tích hợp với một khung thành phần như NET hoặc J2EE

dịch vụ và có sẵn để gọi từ xa

Chapter 2 Software Processes 15

Kỹ thuật phần mềm theo định hướng tái sử dụng

Ưu điểm và nhược điểm

đầu

thống có thể không đáp ứng nhu cầu thực sự của người dùng

được tái sử dụng

Process activities

(Quy trình hoạt động)

Chapter 2 Software Processes 19

Quy trình hoạt động

hoạt động kỹ thuật, cộng tác và quản lý với mục tiêu

tổng thể về việc xác định, thiết kế, thực hiện và thử

nghiệm một hệ thống phần mềm

xác nhận và tiến hóa(specification, development,

validation và evolution) được tổ chức khác nhau trong

các quy trình phát triển khác nhau

theo thứ tự, trong khi incremental development chúng

Quá trình yêu cầu kỹ thuật

Chapter 2 Software Processes 21

Đặc điểm phần mềm

những hạn chế về hoạt động và phát triển của hệ thống

 Yêu cầu gợi ý và phân tích

• Các bên liên quan hệ thống yêu cầu hoặc mong đợi gì từ hệ thống?

 Yêu cầu kỹ thuật

• Xác định các yêu cầu chi tiết

 Xác nhận yêu cầu

• Kiểm tra tính hợp lệ của các yêu cầu

Thiết kế và triển khai phần mềm

thống thực thi

 Thiết kế cấu trúc phần mềm nhận ra đặc điểm kỹ thuật;

 Dịch cấu trúc này thành một chương trình thực thi;

chẽ và có thể liên quan đến nhau

Chapter 2 Software Processes 23

Một mô hình chung của quá trình thiết kế

Design activities

của hệ thống, các thành phần chính (hệ thống con hoặc module), mối quan hệ của chúng và cách chúng được

phân phối

thống và cách chúng được biểu diễn trong cơ sở dữ liệu

các thành phần hệ thống

thành phần có thể tái sử dụng Nếu không có, bạn thiết

kế cách nó sẽ hoạt động

Chapter 2 Software Processes 25

Hoàn thiện hệ thống

chương trình hoặc các chương trình hoặc bằng cách

Xác thực phần mềm(Software validation)

được dự định để cho thấy rằng một hệ thống phù hợp với đặc điểm kỹ thuật của nó và đáp ứng các yêu cầu của khách hàng hệ thống

kiểm tra hệ thống

các trường hợp thử nghiệm được lấy từ đặc tả của dữ liệu thực được xử lý bởi hệ thống

Chapter 2 Software Processes 27

Các giai đoạn testing

Giai đoạn Testing

 Các Component riêng lẻ được kiểm tra độc lập;

 Các Component có thể là các hàm hoặc các đối tượng hoặc các nhóm kết hợp của các thực thể này.

 Kiểm tra toàn bộ hệ thống Testing các đặc tính đặc biệt quan trọng.

 Thử nghiệm với dữ liệu khách hàng để kiểm tra xem hệ thống

có đáp ứng được nhu cầu của khách hàng hay không.

Chapter 2 Software Processes 29

Thử nghiệm giai đoạn trong một plan-driven

software (V-model)

phát triển phần mềm

kinh doanh, phần mềm hỗ trợ doanh nghiệp cũng phải phát triển và thay đổi

cấp(bảo trì) điều này ngày càng không thích hợp vì ngày càng có ít hệ thống hoàn toàn mới

Chapter 2 Software Processes 31

phát triển hệ thống

Coping with change

(Đối phó với thay đổi)

Chapter 2 Software Processes 33

Coping with change

 Thay đổi nền tảng yêu cầu thay đổi ứng dụng

làm lại (ví dụ như yêu cầu phân tích lại) cũng như chi phí triển khai chức năng mới

Giảm chi phí làm lại

gồm các hoạt động có thể lường trước những thay đổi

có thể xảy ra trước khi yêu cầu làm lại đáng kể

 Ví dụ, một hệ thống nguyên mẫu có thể được phát triển để hiển thị một số tính năng chính của hệ thống cho khách hàng.

để thay đổi có thể được cung cấp với chi phí tương đối thấp

 Điều này thường liên quan đến một số hình thức của

incremental development Các thay đổi được đề xuất có thể

được thực hiện theo các bước tăng chưa được phát triển Nếu điều này là không thể, thì chỉ có một lần tăng (một phần nhỏ của

hệ thống) có thể bị thay đổi để kết hợp thay đổi.

Chapter 2 Software Processes 35

Đối phó với các yêu cầu thay đổi

phiên bản của hệ thống hoặc một phần của hệ thống

được phát triển nhanh chóng để kiểm tra các yêu cầu của khách hàng và tính khả thi của các quyết định thiết

kế Cách tiếp cận này hỗ trợ dự đoán thay đổi

thống được gửi đến khách hàng để nhận xét và thử

nghiệm Điều này hỗ trợ cả thay đổi tránh và thay đổi

dung sai

Tạo mẫu phần mềm

được sử dụng để minh họa các khái niệm và thử các tùy chọn thiết kế

 Quy trình kỹ thuật yêu cầu để giúp yêu cầu gợi ý và xác nhận;

 Trong các quy trình thiết kế để khám phá các tùy chọn và phát triển một thiết kế giao diện người dùng;

 Trong quá trình thử nghiệm để chạy thử nghiệm back-to-back.

Chapter 2 Software Processes 37

Lợi ích của việc tạo mẫu

dùng

Quá trình phát triển mẫu thử nghiệm

Chapter 2 Software Processes 39

Prototype development

nhanh

 Prototype nên tập trung vào các khu vực của sản phẩm không được hiểu rõ;

 Lỗi kiểm tra và phục hồi có thể không được bao gồm trong

nguyên mẫu;

 Tập trung vào các yêu cầu chức năng hơn là phi chức năng như

độ tin cậy và bảo mật

Throw-away prototypes

they are not a good basis for a production system:

 It may be impossible to tune the system to meet non-functional requirements;

 Prototypes are normally undocumented;

 The prototype structure is usually degraded through rapid

Incremental delivery

development and delivery is broken down into

increments with each increment delivering part of the

required functionality

requirements are included in early increments

requirements are frozen though requirements for later increments can continue to evolve

Incremental development and delivery

 Develop the system in increments and evaluate each increment before proceeding to the development of the next increment;

 Normal approach used in agile methods;

 Evaluation done by user/customer proxy.

 Deploy an increment for use by end-users;

 More realistic evaluation about practical use of software;

 Difficult to implement for replacement systems as increments have less functionality than the system being replaced.

Chapter 2 Software Processes 43

Incremental delivery

Incremental delivery advantages

system functionality is available earlier

requirements for later increments

most testing

Chapter 2 Software Processes 45

Incremental delivery problems

used by different parts of the system

 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

specification is developed in conjunction with the

software

 However, this conflicts with the procurement model of many

organizations, where the complete system specification is part of the system development contract

Process improvement

Chapter 2 Software Processes 47

Process improvement

process improvement as a way of enhancing the quality

of their software, reducing costs or accelerating their

development processes

processes and changing these processes to increase

product quality and/or reduce costs and development

time

Approaches to improvement

improving process and project management and

introducing good software engineering practice

 The level of process maturity reflects the extent to which good technical and management practice has been adopted in

organizational software development processes

development and the reduction of overheads in the

The process improvement cycle

Process improvement activities

 You measure one or more attributes of the software process or product These measurements forms a baseline that helps you decide if process improvements have been effective

 The current process is assessed, and process weaknesses and bottlenecks are identified Process models (sometimes called process maps) that describe the process may be developed

 Process changes are proposed to address some of the identified process weaknesses These are introduced and the cycle

resumes to collect data about the effectiveness of the changes.

Chapter 2 Software Processes 51

Process measurement

should be collected

 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.

assess process improvements

 But this does not mean that measurements should drive the

improvements The improvement driver should be the

organizational objectives.

Process metrics

completed

 E.g Calendar time or effort to complete an activity or process.

 E.g Total effort in person-days.

 E.g Number of defects discovered.

Chapter 2 Software Processes 53

Capability maturity levels

The SEI capability maturity model

 Process improvement strategies defined and used

Chapter 2 Software Processes 55

Key points

producing a software system Software process models are abstract representations of these processes

Key points

with transforming a requirements specification into an

executable software system

system conforms to its specification and that it meets the real needs of the users of the system

existing software systems to meet new requirements

The software must evolve to remain useful

and incremental delivery to cope with change

Chapter 2 Software Processes 57

Key points

and delivery so that changes may be made without

disrupting the system as a whole

agile approaches, geared to reducing process

overheads, and maturity-based approaches based on better process management and the use of good

software engineering practice

levels that essentially correspond to the use of good