Các kinh nghiệm quý của công nghệ phần mềm

Các kinh nghiệm quý của công nghệ phần mềm

Trang 2

Mục đích:

Khám phá các triệu chứng và các nguyên nhân cốt lõi của các vấn để trong phát triển phân mềm

Trình bày Rationals 6 kinh nghiệm tốt cho quá trình phát triển phần mềm

Xem xét cách dùng các kinh nghiệm này để giải quyết các vấn đề trong phát triển phần mềm

Trang 3

Phân tích tình hình của CNPM

ee

Kinh té thé gidl ngay Các ứng dụng mơ rộng

càng phụ thuộc hơn về kích thước, độ phức

vào CNPM tạp, và phân bố

Thương trường địi hỏi nâng

cao năng suất & chất lượng

và giảm thời gian

Trang 6

Các triệu chứng của các vấn dé trong PTPM

Hiểu khơng đúng những øì người dùng cần

Khơng thể thích ứng với các thay đổi về y/c đ/v hệ thống

Các Module khơng khớp với nhau

Phần mềm khĩ bảo trì và nâng cấp, mở rộng Phát hiện trễ các lỗ hổng của dự án

Chất lượng phần mềm kém

Hiệu năng của phần mềm thấp

Các thành viên J0) nhĩm khơng biết được ai đã thay đổi cái øì, khi nào, ở đâu, tai sao phải thay đổi

Trang 8

Các nguyên nhân chính của các v/đ trong PTPM

Sự quản ly y/c người dùng khơng đầy đủ Trao đổi thơng tin mơ hồ và khơng đầy đủ Kiến trúc khơng vững chắc Độ phức tạp vượt quá tầm kiểm sốt RRR RR Cĩ những mâu thuẫn khơng phát hiện được giữa yíc, thiết kế, và cài đặt

Kiểm chứng khơng đây đủ

Sự lượng giá chủ quan về tình trạng của dự án

Sự trễ nải trong việc giảm rủi ro do mơ hình thác nước

Sự lan truyền khơng thể kiểm sốt của các thay đổi

V1 “s ES “s

ES Thiếu các cơng cụ tự động hĩa

Trang 9

Các kinh nghiệm giúp giải quyết các vấn đề

Nguyên nhân cốt lỗi

Các y/c khơng đây đủ Trao đổi thơng tin mơ hồ

Kiến trúc kém bền vững

Độ phức tạp quá cao Các lượng giá chủ quan

Các mâu thuẫn chưa thấy Kiểm chứng nghèo nàn Q/tr phát triển thác nước Sự thay đổi khơng k/sốt Thiếu sự tự động hĩa “s “s “s “s “s ES BS V21 “s ES Cac kinh nghi?m qui trong CNPM Duong Anh B?c Các kinh nghiệm tốt

5 Phat trién theo vong lap

Trang 11

Các kinh nghiệm quí của ÊNPM

Phát triển theo you lig Su clung kiến trúc Component Momiiiapaoa Mein dine DHHODdI Gidtauone Ouan te Các v/e

Migin soat efe thay doi trons nS tone

Trang 14

Kinh nghiệm 1: PTPM theo vịng lặp

Một thiết kế ban đầu cĩ thể khơng hồn chỉnh so với các yêu cầu chính

œ Việc phát hiện trễ các thiếu sĩt trong bản thiết kế sẽ làm tăng giá thành, tốn thời gian và thậm chí

làm hủy bỏ dự án

Thời gian và tiền bạc chỉ ra để cài đặt một

Trang 17

Ứ/d 0T thác nước theo vịng lặn Iteration 1 Iteration 2 Iteration 3 R R R m—my mo D ~ Ee ~~ ~~ TIME

œ Các vịng lap dau danh cho cac v/d nhiéu rủi ro 2 MOi vong lap sinh ra một phiên bản với một sự bổ

sung cho hệ thống

œ Mỗi VL bao gồm cả việc tích hợp và kiểm chứng

Trang 19

Các đặc tính của qui trình lặp œ Các rủi ro chính được giải quyết trước khi cĩ các phát triển lớn œ Các vịng lặp đầu tiên cho phép nhận feedback œ Việc kiểm chứng và tích hợp diễn ra liên tục œ Các cột mốc cục bộ sẽ định ra các tiêu điểm ngăn hạn

Sự tiến triển được đo bằng bản cài đặt

Trang 20

Ap dụng các kinh nghiệm trong chu kỳ sống PM Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows

Configuration & Change Mgmt

Project Management Environment Preliminary] Iter.| : Iter J Iter | Iter | Iter ———— Iter | Iter

Iteration(s)" #1 es iC ee: eo a 0) hoe

Iterations

Trang 21

Qui trình lặp giải quyết các vấn để

Nguyên nhân cốt lõi Cách giaơi quyết

4 Khơng dú các eT cầu <— Nhận Vi khuyến khích các

đ/v hệ thống feedback từ người dùng

Trao đổi TTmơhồ:_ “———C4C hiểu lầm nghiêm trọng

> ' được làm rõ sớm

Kiến trúc kém bền vững TS 7

Tập trung phát triển các khái

niềm chứa nhiều rủi ro trước

“| Danh gia khach quan thong qua

Trang 23

Kinh nghiệm 2: Quản lý yêu cầu đ/v hệ thống

Suy dẫn, tổ chức, và tạo sưu liệu vé cdc yéu cau chtic năng và

các ràng buộc

œ Lượng giá các thay đổi và xác

định ảnh hưởng của chúng

zs Theo dau va tao suu liệu về các thỏa hiệp & các quyết định

Yêu câu đối với hệ thống luơn động

Phải lường trước khả năng chúng bị thay đổi trong quá trình PTPAI

Trang 24

Định nghĩa: Y/c đ/v HT và sự quản lý chúng

œ Một yêu câu là một điều kiện hoặc khả năng mà hệ thống phải tuân theo/cĩ

œ Quản lý y/c là một tiếp cận cĩ hệ thống để

Suy dẫn, tổ chức, và tạo sưu liệu về các yêu cầu

chức năng d/V ie thống, và

Thiết lập và duy trì sự thỏa thuận giữa

Customer/user và NO SOI ST lio quan đến các

thay đổi về yêu câu d/v hé thống

Trang 25

Thỏa thuận về những gì mà HT phải làm Hệ thống can xay dung Rey Cac Customer User

Xac minh Surrogate

Cac yéu cau T II

Adapted from Al Davis Cac Ae Cau

Trang 27

Làm thế nào để bắt được lỗi về y/c sớm ?

œ Phân tích vấn để và suy dẫn ra các nhu cầu của người dùng một cách cĩ hiệu quả

Đạt được thỏa thuận với customer/user về các yêu cầu đối với hệ thống

œ‹ Mơ hình hĩa sự tương tác giữa user và system œ Thiết lập một đường ranh giới (baseline) va qui

trình kiểm sốt thay đổi (change control prOC€S$) Duy trì khả năng theo vết tiến và lùi các yêu cau đ/v hệ thống

Sử dụng một qui trình lặp ác kinh nghi?m quí trong CNPM

Trang 28

Các vấn đề giải quyết nhờ quản ly y/c dv HT

NETO a Co Cach giai quyét

Thiéu cac y/c d/v HT <—— Xay dung trong quản lý Y/C

Trao đổi TTmơhơ_ <4 một tiếp cận kỷ luật

Kiến trúc kém bên vững Trao đổi thơng tin dựa trên

các yíc đã xác định

J ae ert độ ưu tiên, lọc và theo dõi

Đánh gia chu quan _- yêu cầu

Các ĨC thuân khơng Đánh giá khách quan các

được phát hiện mu năng và hiệu năng

Kiểm chứng kém Các mâu thuẫn đễ phát hiện QT thac nước RM tool cung cấp một kho

Trang 29

Kinh nghiệm 3: Dùng kiến trúc Component-Based

Develop lteratively

manage Use model

MS MRO one mesually

B\peribectl| peas

Control Changes

Trang 30

Kiến trúc phần mềm xác định: œ Kiến trúc ĐỀU HƯU, chứa đựng các quyết định quan trọng về tổ chức của hệ thống phần mềm Sự lựa chọn các phần tử cầu trúc và interface của chúng để cẫu thành một hệ thống Hành vi được mơ tả như sự cộng tác giữa các phần tử này Sự tổng hợp của các phẩn tử cấu trúc và hành vi

nay thanh cac subsystem lớn hơn

«Kiểu kiến trúc định hướng cho tổ chức này, cho các

phan tử cấu trúc va interface cua chung, các cơng

tác, và sự tổng hợp giữa chúng

Trang 31

Các ảnh hưởng của kiến trúc

2s Kiến trúc phần mềm liên quan đến cấu trúc, hành

vị và ngữ cảnh (context):

#{Cach dung (Usage)

#{htic nang (Functionality }

#tHiéu nang (Performance)

inh co dan (Resilience)

Trang 32

Resilient, Component-Based Architectures

a Các kiến trúc tốt thỏa mãn các y/c d/v chúng, là

tính dàn hồi, và component-based œ Một kiến trúc đàn hồi cho phép

Tăng cường khả năng dễ bảo trì và dễ mở rộng Khả năng tái sử dụng với lợi ích kinh tế cao

œ#hân chia cơng việc rõ ràng trong đội ngũ PTPM

2§G6i gon cdc phụ thuộc phần cứng & hệ thống

œ Một kiến trac component-based cho phép

Tái sử dụng hoặc tùy chỉnh các component sẵn cĩ €hon lựa giữa hàng ngàn component thương mại

trên thị trường

Tiến hĩa khơng ngừng phần mềm đang tồn tại

Trang 34

Kiến trúc Êomponent giải quyết các vấn dé

Các nguyên nhân cốt lõi Cách giải quyết “s “s ES ES BS “s ` Thiếu y/c đ/ hệ thống Trao đổi TT mơ hồ Kiến trúc kém bền Quá phức tạp Đánh giá chủ quan Các mâu thuẫn chưa xác định Test kém Cui trình thác nước

Các thay đổi khơng

Trang 36

Kinh nghiệm 4: Mơ hình hĩa trực quan phần mềm œ Nắm bắt cấu trúc và hành vi của các thành phần kiến trúc es Thể hiện cách mà các phần tử hệ thống khớp với nhau œ Che dấu hoặc phơi bày chỉ tiết theo nhu cầu cơng VIỆC

2s Duy tri tinhd nhat quán giữa thiết kế và cài đặt

Tăng cường trao đổi thơng tin rõ ràng

Moa hinh houa troic quan tắng khau nắng

quaun lyu hoa phouc taip cuua phaan meam

Trang 40

Mơ hình hĩa trực quan và phát triển theo vịng lặp Yêu ” ban đâu [—” risk aan — 4 Danh gia requirements | analysis desigøn — & testing deployment

Thay đồi ba0n thiết kế ?

Trang 41

Mơ hình hĩa trực quan và phát triển theo vịng lặp

Yêu câu ban đâu

_ — risk targeting |

Danh gia §200)01)21112111-

| analysis & design

Trang 42

Giải quyết vấn để nhờ mơ hình hĩa trực quan

Cauc nguyean nhaan coat looLogi giẳl

NTR TS ~.— Cac use-Case va scenario

Y đặc tả hành vi rõ ràng

Truyen tin - L8 |_ Các mơ hình nắm bắt tường

Kiến trúc kém bên minh các thiết kế

Quá phức tạp | Các kiến trúc khơng đơn thể

Đánh giá chu quan hay Cứng nhắc 1) eae bay

Các chỉ tiết khơng cần thiết

xác định < được che dẫu khi cần

Testkém < = Cac uC Ry mỉnh chỉ ra

Cui trình thác nước ` ae - m

: at lượng của ứng dụng đi kèm

D0221 7" .x TY

Thiếu ccụ tựđộng <1 các ccụ trực quan hỗ trợ cho

Trang 44

Kinh nghiệm 5: Kiểm định chất lượng phần mềm

Trang 46

Test trong một mơi trường PT theo vịng lặp

lteration 1 lteration 2 lteration 3 Iteration 4

“oo KOO OC eS Ni Cài "`

Trang 47

Tự động hĩa giảm thời gian và cơng sức test

Một chu trình test thủ cơng

Trang 48

Tai sao? Thé nao?

Ư/d của tơi cĩ làm những gì | Tao cdcTest case cho mỗi

Trang 49

Các vấn đề được giải quyết nhờ kiểm định ŒL

Nguyên nhân cốt lõi Cauch giaũi oT

Thiéu y/c d/v HT —Testing danh gia khach quan

NRTA TS vé trang thai du an

Kién trac kém bén -Đánh giá khách quan triệt Quá phức tạp tiêu các mâu thuần sớm

Bins gl ou 4 Jos Testing và kiểm định tập Các mâu thuân chưa trung vao ving high risk

được xác định

Testkém < Bee i thấy thiếu sĩt sớm và chỉ " -_= phí sửa chữa thấp

Cui trình thác nước

Thay đổi khơng thể K Các ccụ test tự động giúp

Trang 51

Kinh nghiệm 6: Kiểm sốt thay đổi trong PM hiểu developer hiểu team hiểu vị trí hiều vịng lập niéu release niéu project EE EE EES ES ES a4 a4 niéu platform

TT kiếm sốt tường minh, đây đủ

Phát triển song song dễ biến TT, hơn độn

Trang 53

Các khái niệm của Configuration & Change M

< Phân rã kiến trúc thành các subsystem va gan trách nhiệm

thực hiện các subsystem cho mơi nhĩm

< Thiết lập vùng làm việc an tồn cho mỗi developer

Cho phép cơ lập với các thay đổi tạo bởi vùng làm việc khác

#Kiém soat tat ca software artifact - models, code, docs,

Thiết lập một vùng làm việc tích hợp

Thiết lập một cơ chế khả thi kiểm sốt các thay đổi

Trang 54

Change Control hé tro tat ca Best Practices khac

œ Pháttriểntheo Dự án chỉ tiến triển khi các thay

qui trình lặp đổi được kiểm sốt

2 Quan ly Y/c œ Để loại bỏ sự dãn phạm vị, đánh giá ảnh hưởng của mọi TEN đổi dự kiến trước khi chấp nhận

Cac Component phai dang tin cay, ¡.e., tìm DI) phién ban dung dan của tất cả các phần hợp thành

Để bảo đảm sự hội tụ, phải eae

dan kiểm sốt các model khi các thiết kế ổn định

Kiểm định chất Test chỉ cĩ a nghĩa nếu các version

lượng các phần tử eras test được biết rõ

Trang 55

Các vần đề được giải quyết nhờ ontrol Change

Nguyên nhân cốt lỗi bách giải quyết

Thiếu yíc đív HT <—R£9Mjromenl:chanus warklow dược

Truyền tin mơ hồ Các Change request làm cho thơng Kiến trác kém bên tin trao đối rõ ràng

, 4s Vung lam viéc biét lap giam cac tro

Qua phic tap > nT Tins lam viéc Serr

Đánh giá chủ quan <1 Thống kê về mức độ thay đổi là độ da tốt cho các đánh giá NT: quan

MET thuan chưa đ về trạng thái của dự ân

xác định Vùng làm việc chứa tất cả các

Test kém artifact dé tao su nhat quan

thay đổi

Cui trình thác nước mn sốt được sự lan truyền các

Thay đổi khơng thể

kiểm sốt

œ Thiếu ccụ tự động

Trang 56

Các kinh nghiệm hỗ trợ lẫn nhau

Develop Rede Lah,

Cac kinh nghi?m qui trong CNPM Duong Anh B?c

Ensures users involved Manage

as requirements evolve : > Ree CƠ Do

Validates architectural Use

Trang 57

Tổng kết > ^ “} A œ Kết quả là phần mềm trở nên Đúng thời hạn eine, iP h os ID Vu, fm ngan [ Performance ao Ge Ba Sac rn " Engineer Foie MMC MRL U Cpe >» 4 rN | Project Manager Develop lteratively Developer Use Model ị