Bài giảng Nhập môn Công nghệ phần mềm: Chương 2 - Nguyễn Thị Minh Tuyền

Nguyễn Thị Minh Tuyền Nhập môn CNPM Nội dung Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP... Nguyễn Thị Minh Tuyền Nhập môn CNPM Quy t

Trang 1

Nguyễn Thị Minh Tuyền

Quy trình phần mềm

Trang 2

Nguyễn Thị Minh Tuyền Nhập môn CNPM

Nội dung

Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP

Trang 3

Nội dung

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

Các hoạt động của quy trình Thích nghi với sự thay đổi Quy trình RUP

Trang 4

Quy trình phần mềm

v  Quy trình phần mềm (software process) là một tập

có cấu trúc các hoạt động cần thiết để phát triển

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

v  Có nhiều quy trình phần mềm khác nhau Tuy

nhiên, tất cả đều bao gồm những hoạt động:

dùng;

v Mô hình quy trình phần mềm (software process

model) là biểu diễn trừu tượng của một quy trình

Nó biểu diễn mô tả của quy trình từ một góc nhìn nào đó

4

Trang 5

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

v Khi mô tả về quy trình, ta thường nói về

mô hình dữ liệu, thiết kế giao diện người dùng, … ;

v Các mô tả quy trình có thể gồm:

§   Sản phẩm, kết quả đầu ra của một hoạt động;

§   Vai trò, phản ánh trách nhiệm của những người tham gia vào quy trình;

§   Điều kiện trước và điều kiện sau (Pre- and post-conditions), là

những điều kiện phải đảm bảo trước và sau khi một hoạt động

được thực hiện hay một sản phẩm được tạo ra.

Trang 6

Quy trình hoạch định sẵn và quy

trình linh hoạt

v Các quy trình hoạch định sẵn (plan-driven

process) là các quy trình mà trong đó tất cả

các hoạt động được lên kế hoạch trước và tiến

độ thực hiện được đánh giá dựa vào kế hoạch này

v Trong các quy trình linh hoạt (agile process),

kế hoạch được phát triển dần dần và dễ dàng thay đổi quy trình để đáp ứng sự thay đổi yêu cầu của khách hàng

v Hầu hết các quy trình thực tế đều gồm những phần tử của cả hai phương pháp này

v Không có quy trình phần mềm đúng hay sai!

6

Trang 7

Các mô hình quy trình phần mềm

v Mô hình thác nước (waterfall model)

§   Mô hình hoạch định sẵn Các pha đặc tả và phát triển phân biệt và tách rời nhau

v Mô hình phát triển dần dần (incremental

Trang 8

Mô hình thác nước

Requirements

definition

System and software design

Implementation and unit testing

Integration and system testing

Operation and maintenance

8

Trang 9

Các pha trong mô hình thác nước

v Mô hình thác nước có các pha sau:

§   Phân tích và định nghĩa yêu cầu

§   Thiết kế hệ thống và phần mềm

§   Cài đặt và kiểm thử đơn vị (unit testing)

§   Kiểm thử tích hợp và kiểm thử toàn hệ thống

§   Vận hành và bảo trì

v Nhược điểm:

quy trình đã vào guồng Về nguyên tắc, pha này phải

hoàn thành trước khi bắt đầu pha tiếp theo

Trang 10

Các vấn đề của mô hình thác nước

thành những giai đoạn tách biệt gây khó khăn trong việc đáp ứng sự thay đổi yêu cầu người dùng

và sự thay đổi khá hạn chế trong suốt quá trình phát triển;

thống lớn trong đó hệ thống được phát

triển tại nhiều địa điểm khác nhau

nước giúp cho việc phối hợp trong công việc dễ dàng

hơn

10

Trang 11

v Một biến thể của mô hình thác nước là phát

triển hệ thống theo kiểu hình thức

§   Sử dụng mô hình toán học để đặc tả hệ thống

§   Sử dụng các chuyển đổi toán học để chuyển các đặc tả thành chương trình chạy được sao cho vẫn đảm bảo được tính nhất quán

§   Do sử dụng chuyển đổi toán học => đây là một lý do thuyết

phục để đảm bảo rằng một chương trình được phát sinh theo cách này nhất quán với đặc tả đưa ra

v Những quy trình phát triển hình thức (sử dụng B-method chẳng hạn) phù hợp với việc phát

triển hệ thống có độ tin cậy cao, độ an toàn cao

và tính bảo mật cao

§   Ví dụ: đường metro 14 ở Paris, hệ thống tàu tự động ở sân bay

Trang 12

Phát triển dần dần

Concurrent activities

Validation versionFinalDevelopment Intermediateversions

Specification versionInitial

Outline

description

12

Trang 13

Lợi ích của phát triển dần dần

v  Giảm được chi phí khi đáp ứng sự thay đổi yêu cầu khách hàng

§   Lượng phân tích và tài liệu phải làm lại được giảm đi nhiều

so với mô hình thác nước

v  Dễ dàng trong việc lấy phản hồi từ khách

hàng

§  Khách hàng có thể đưa ra ý kiến dựa trên demo phần mềm

và thấy được phần mềm đã được cài đặt đến đâu rồi

v  Phân phối và triển khai phần mềm đến

khách hàng nhanh hơn

§  Khách hàng có thể sử dụng phần mềm sớm hơn so với quy trình thác nước

Trang 14

thiện hệ thống, nếu không sự thay đổi thường xuyên sẽ phá vỡ cấu trúc của hệ thống Đáp ứng những thay đổi phần mềm sẽ trở nên khó khăn và tốn kém hơn

14

Trang 15

CNPM theo hướng tái sử dụng

v  Dựa vào việc tái sử dụng một cách có hệ

thống

hoặc từ các hệ thống COTS (Commercial-off-the-shelf)

v  Các giai đoạn của quy trình

v  Hiện nay, việc tái sử dụng là phương pháp

chuẩn cho việc xây dựng nhiều loại hệ thống thương mại

Trang 16

CNPM theo hướng tái sử dụng

Requirements

specification

Component analysis

Development and integration

System design with reuse

Requirements modification

System validation

16

Trang 17

Các loại component

phát triển theo các chuẩn dịch vụ và có sẵn để triệu gọi từ xa

như một gói (package) tích hợp trong

các framework như NET hay J2EE

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

Trang 18

Nội dung

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

Các hoạt động của quy trình

Thích nghi với sự thay đổi Quy trình RUP

Trang 19

Các hoạt động của quy trình

v 4 hoạt động quy trình cơ bản - đặc tả, phát

triển, thẩm định và cải tiến - được tổ chức khác nhau trong các quy trình phát triển khác nhau

đan xen nhau

Trang 20

Đặc tả phần mềm

được yêu cầu và các ràng buộc đối với hoạt

động của hệ thống và việc phát triển hệ thống

engineering process)

§   Nghiên cứu khả thi (Feasibility study): Ước lượng xem những yêu cầu của người dùng có khả thi về mặt kỹ thuật và tài chính

để xây dựng nên hệ thống hay không

§   Thu thập và phân tích yêu cầu (Requirements elicitation and

analysis): Các stackholder hệ thống yêu cầu và mong muốn gì

Trang 21

Quy trình công nghệ yêu cầu

Feasibility study

Requirements elicitation and analysis

Requirements specification

Requirements validation

Feasibility report

System models

User and system requirements

Requirements document

Trang 22

Thiết kế và cài đặt phần mềm

hệ thống thực thi được

thường liên quan đến nhau hoặc có thể

đan xen nhau

22

Trang 23

Một mô hình chung của quy trình

Requirements specification

Architectural design

Component specification

Trang 24

Các hoạt động thiết kế

v Thiết kế kiến trúc (Architectural design)

chính, mối quan hệ giữa các component và chúng được phân tán thế nào

v Thiết kế giao diện (Interface design)

v Thiết kế component (Component design)

nó hoạt động thế nào

v Thiết kế CSDL (Database design)

được biểu diễn trong CSDL

24

Trang 25

Thẩm định phần mềm

(validation) (V & V) nhằm mục đích chỉ ra

rằng

§  Một hệ thống tuân theo đặc tả của nó;

§   Thỏa mãn yêu cầu của khách hàng hệ thống

kiểm thử hệ thống (system testing)

thống sử dụng các test case được viết ra dựa vào đặc tả

dụng nhất

Trang 26

Các giai đoạn kiểm thử phần mềm

System testing

Component testing

Acceptance testing

26

Trang 27

Các giai đoạn kiểm thử phần mềm

component testing)

hoặc nhóm đồng nhất các thực thể

rằng hệ thống đáp ứng được yêu cầu của khách hàng

Trang 28

Các pha kiểm thử trong quy trình

hoạch định sẵn

Requirements

specification specificationSystem

Acceptance test integration testSystem integration testSub-system

System design Detaileddesign

Service

Module and unit code and test

Acceptance test plan

System integration test plan

Sub-system integration test plan

28

Trang 29

Cải tiến phần mềm

thay đổi

doanh thay đổi, phần mềm hỗ trợ kinh doanh cũng phải cải tiến và thay đổi

cải tiến phần mềm ngày càng mờ nhạt

đi Ngày càng ít phần mềm được phát triển hoàn toàn mới

Trang 30

Cải tiến phần mềm

Assess existing systems

Define system requirements

Propose system changes

Modify systems

New system

Existing systems

30

Trang 31

Tổng kết

trúc các hoạt động cần thiết để phát

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

diễn trừu tượng của một quy trình

tổ chức của các quy trình phần mềm

tiến hóa, mô hình phát triển theo hướng tái sử dụng

Trang 32

thống

v  Cải tiến phần mềm xảy ra khi bạn thay đổi

hệ thống phần mềm có sẵn để đáp ứng các yêu cầu mới

32

Trang 33

Nội dung

Mô hình quy trình phần mềm Các hoạt động của quy trình

Thích nghi với sự thay đổi

Quy trình RUP

Trang 34

Thích nghi với sự thay đổi

những dự án phần mềm lớn

cầu hoặc phát sinh những yêu cầu mới

làm lại và chi phí cài đặt tính năng mới

34

Trang 35

Giảm thiểu chi phí làm lại

v Tránh thay đổi (change avoidance)

§   Quy trình phần mềm gồm các hoạt động mà nó có thể dự đoán trước những thay đổi có thể xảy ra khi việc làm lại được yêu cầu

§   Ví dụ: hệ thống nguyên mẫu (prototype system) có thể dùng

để cho khách hàng xem những tính năng chính của hệ thống

v Chấp nhận thay đổi (change tolerance)

§   Quy trình được thiết kế sao cho thay đổi được thực hiện với chi phí khá thấp

§   Thường sử dụng mô hình phát triển dần dần

Trang 36

Nguyên bản phần mềm

v Một nguyên bản (prototype) là phiên bản đầu tiên của một hệ thống được dùng để demo

những khái niệm và thử các tùy chọn thiết kế

v Một nguyên bản có thể được sử dụng trong các trường hợp sau:

trình thu thập yêu cầu và thẩm định yêu cầu;

triển thiết kế giao diện người dùng;

back-to-back

36

Trang 37

Lợi ích của nguyên bản

người dùng

Trang 38

Quy trình phát triển nguyên bản

Establish prototype objectives

Define prototype functionality

Develop prototype

Evaluate prototype

Prototyping plan

Outline definition

Executable prototype

Evaluation report

38

Trang 39

chưa được hiểu rõ ràng;

các yêu cầu phi chức năng

Trang 40

được các yêu cầu phi chức năng;

thay đổi nhanh;

tiêu chuẩn chất lượng về mặt tổ chức

40

Trang 41

Chuyển giao dần dần(incremental

delivery)

v  Thay vì phân phối hệ thống một lần, việc

phát triển và phân phối được chia ra thành từng phần nhỏ (increment) Mỗi phần giao cho khách hàng chứa một phần tính năng được yêu cầu

v  Những yêu cầu người dùng được ưu tiên và những yêu cầu có độ ưu tiên cao nhất sẽ

được đặt trong các phần đầu tiên

v  Trong quá trình phát triển, việc phân tích yêu cầu cho phần tiếp theo có thể được

tiến hành nhưng thay đổi yêu cầu cho phần hiện tại không được chấp nhận

Trang 42

Phát triển dần dần và chuyển giao

dần dần

trước khi tiến hành phát triển phần tiếp theo;

Trang 43

Chuyển giao dần dần

Design system architecture

Define outline

System incomplete?

Final system

Develop system increment

Trang 44

Ưu điểm của chuyển giao dần dần

v Khách hàng sớm được bàn giao sản phẩm (từng phần)

v Các phần đầu được xem như một nguyên bản

để hỗ trợ cho việc làm lộ rõ những yêu cầu cho phần sau

v Nguy cơ thất bại toàn hệ thống là thấp

v Duy trì được ưu điểm của phát triển từng phần,

do đó dễ thích nghi với sự thay đổi của hệ

thống

v Những dịch vụ hệ thống có độ ưu tiên cao nhất

sẽ được kiểm thử nhiều nhất

trọng của hệ thống

44

Trang 45

Mô hình xoắn ốc Boehm

đường xoắn ốc hơn là một chuỗi tuần tự các hoạt động với các bước quay lui

diễn một pha của quy trình

hay thiết kế, các vòng lặp trong đường xoắn ốc được chọn theo nhu cầu

giải quyết trong suốt quy trình

Trang 46

Quy trình phần mềm của mô hình

xoắn ốc Boehm

Risk analysis Risk

analysis Risk

analysis

Risk analysis Proto-

Simulations, models, benchmarks

S/W requirements Requirement

validation Design V&V

Product design Detailed

design Code Unit test Integration test Acceptance

test

next-level product

Evaluate alternatives, identify, resolve risks

Determine objectives, alternatives and constraints

Plan next phase

Integration and test plan

Development plan

Requirements plan Life-cycle plan REVIEW

46

Trang 47

Các phân khu (sector) của mô hình

xoắn ốc

v Thiết lập mục tiêu

v Đánh giá và giảm thiểu rủi ro

hành để giảm thiểu các rủi ro chính

v Phát triển và thẩm định

đây có thể là một trong các mô hình tổng quát

v Lập kế hoạch

xoắn ốc được lên kế hoạch

Trang 48

Sử dụng mô hình xoắn ốc

v  Ưu điểm:

mỗi mức tiến hóa

thống

v Nhược điểm:

này có thể điều khiển được

thành công Nếu một nguy cơ lớn không được tìm ra và quản lý

48

Trang 49

Nội dung

Mô hình quy trình phần mềm Các hoạt động của quy trình Thích nghi với sự thay đổi

Quy trình RUP

Trang 50

Quy trình RUP

v The Rational Unified Process

v Đây là một quy trình tổng quát bắt nguồn từ

UML và Unified Software Development

Process

v Kết hợp các khía cạnh của ba mô hình quy

trình tổng quát

v Thường mô tả ba khía cạnh

theo thời gian;

của quy trình;

những thực tiễn tốt

50

Trang 51

Các pha của RUP

Phase iteration

Transition

Trang 52

Các pha của RUP

Trang 53

Vòng lặp trong RUP

tăng dần

pha

Trang 54

Các workflow tĩnh trong RUP

Requirements Actors who interact with the system are

identified and use cases are developed to model the system requirements

Implementation The components in the system are

implemented and structured into implementation sub-systems Automatic code generation from design models helps accelerate this process

54

Trang 55

Các workflow trong RUP

Testing Testing is an iterative process that is carried out in

conjunction with implementation System testing follows the completion of the implementation

Deployment A product release is created, distributed to users

and installed in their workplace

Environment This workflow is concerned with making appropriate

software tools available to the software development team

Trang 56

Nguyễn Thị Minh Tuyền 56 Nhập môn CNPM

Nguồn: http://www.ibm.com

Trang 57

Ưu điểm của RUP

của khách hàng và phân phối những phần có độ

ưu tiên cao nhất trước

khách hàng và theo dõi sự thay đổi của những yêu cầu này

Trang 58

Ưu điểm của RUP

những hệ thống quản lý thay đổi và các công cụ quản lý cấu hình

58

Trang 59

Tổng kết

v Quy trình nên có các hoạt động để đối phó với

sự thay đổi Có thể có pha nguyên bản để hạn chế những thay đổi không cần thiết trên yêu

cầu và thiết kế

v Quy trình có thể được cấu trúc hóa cho phát

triển và phân phối dần dần sao cho nhưng thay đổi có thể được thực hiện mà không phá vỡ

Trang 60

Câu hỏi?

Tiêu đề	Quy trình phần mềm
Tác giả	Nguyễn Thị Minh Tuyền
Trường học	Trường Đại Học Công Nghệ Thông Tin
Chuyên ngành	Nhập môn Công nghệ phần mềm
Thể loại	Bài giảng

Định dạng
Số trang	61
Dung lượng	1,53 MB