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

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

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

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

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

và giảm thời gian

ác kin hi?m quí trong CNPM

nh Ð?c

Phát triển phần mềm là công việc tập thể

Các thách thức

Các nhóm đông hơn

Sự chuyên môn hóa

Chung ta da lam viéc ra sao ?

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

Quá trình build-and-release không đáng tin cậy

s V1

“s V1 V1

Chữa trị triệu chứng không g

Symptoms

end-user needs changing

requiremenfs modules dont fit hard to maintain late discovery poor quality poor performance colliding

overwhelming complexity

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ể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 soát của các thay đổi

V1

“s

ES

“s

ES Thiếu các công cụ tự động hóa

Các kinh nghi?m qui trong CNPM Duong Anh B?c

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/soát

5 Phat trién theo vong lap

Quan tri cac y/c

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

Roof Causes insufficient requirements ambiguous

communications

brittle architectures

overwhelming complexity

undetected inconsistencies

insufficient automation

Besf Pracfices

| develop iteratively manage requirements

use component architectures

model the software

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

Phát triển theo you lig

Migin soat efe thay doi trons nS tone

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

Các kinh nghiệm tạo ra

\€?Ì 9|!

Nhiều dự án thành công hơn

Develop lIteratively

lG `

Manage Oy rans Retr Ceo OT an Visually Model

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

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

Một thiết kế ban đầu có thể không hoà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

thiết ce ; sai là không thể bù đắp

Qui trình thác nước truyền thống

Requirements Analysis

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

qui trình thác nước có wi ay

Requirements Analysis

œ 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

ac kin hi?m qui trong CNPM

?c

0ui trình lặp đẩy nhanh việc giảm rủi ro

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

2 Cac cai đặt bộ phận có thể triển khai riêng

Ap dụng các kinh nghiệm trong chu kỳ sống PM

Configuration & Change Mgmt

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

Iterations

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

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

Các mâu thuẫn khơn test

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

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

ác kinh nghi?m quí trong CNPM

nh Ð?c

Đị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

nghi?m quí trong CNPM

?c

Thỏa thuận về những gì mà HT phải làm

Cac yéu cau T II

Adapted from Al Davis Cac Ae Cau

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

| OA&Test |

Cac kinh nghi?m qui trong CNPM

Duong Anh B?c

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 soá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

nh Ð?c

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

Các thay đổi không ks chứa các y/c, thuộc tính và đồ

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

Develop lteratively

manage Use model

B\peribectl| peas

Control Changes

ac kin hi?m qui trong CNPM

?c

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

ác kinh nghi?m quí trong CNPM

?c

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) Khả năng tái sử dụng (Reuse)

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

Các kinh nghi?m qui trong CNPM Duong Anh B?c

Customer Product License

en SH

Các kinh nghi?m qui trong CNPM

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

Đá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

—Cac Component dễ tạo ra

các kiến trúc đàn hồi

Tái sử dụng các com và

er Thương mại trở

nên dê dàng —Tính đơn thể cho phép phân

Kinh nghiệm 4: Mô hình hóa trực quan phần mềm

Kinh nghiệm 4: Mô hình hóa trực quan phần mềm

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 taéng khau naéng

quaun lyu hoa phouc taip cuua phaan meam

ac kin hi?m qui trong CNPM

nh Ð?c

làm sưu liệu

các artifact của một hệ thống phần mềm

‘ni >

MODELING LANGUAGE

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

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

Thay đồi ba0n thiết kế ?

ác kinh nghi?m quí trong CNPM

nh Ð?c

Mô hình hóa trực quan và phát triển theo vòng lặp

Yêu câu ban đâu

implementation & testing PIN:

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

Cauc nguyean nhaan coat looLogi giaú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

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

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

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

mô hình hóa băng UML

“S

“s

EE a4 V1 V21 Các mâu thuẫn chưa

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

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

PT theo vòng lặp cho phép test liên tục

Iteration 1 i:

Execute Evaluate

Execute Evaluate

Plan

Design Implement

Execute Evaluate

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

lteration 1 lteration 2 lteration 3 Iteration 4

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

Tai sao? Thé nao?

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

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

in test độ tin cậy, chức năng và

hiệu năng

“s

ES

ES V1

ES

` Thiếu ccụ tự động

nghi?m quí trong CNPM

?c

Kinh nghiệm 6: Kiểm soát thay đổi trong PM

Kinh nghiệm 6: Kiểm soát thay đổi trong PM

hiểu developer hiểu team

hiểu vị trí

hiều vòng lập niéu release

EE

EE EES

ES

ES a4 a4 niéu platform

TT kiếm soát tường minh, đây đủ

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

Các kinh nghi?m qui trong CNPM Duong Anh B?c

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 toà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 soát các thay đổi

Nắm bắt thay đổi xuất hiện nào xuất hiện trong release

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 soá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 soá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õ

Va Cac phan tứ được boa vé trudc các thay đổi

Dùng kiến trúc component

Mô hình hóa trực

quan

Các kinh nghi?m qui trong CNPM

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

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

thay đổi

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

Thay đổi không thể

kiểm soát

œ Thiếu ccụ tự động

Các kinh nghi?m qui trong CNPM Duong Anh B?c

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

decisions early on )» - CðZiØØWient :

Develop lteratively

Developer

Use Model ị

Manage Component Visually Mˆ22))/

Requirements architectures Quality