Bài giảng Các kinh nghiệm quí của công nghệ phần mềm

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

? Hiểu không đúng những gì 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 trong nhóm không biết được ai đã thay đổi

cái gì, khi nào, ở đâu, tai sao phải thay đổi

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

 

pdf 57 trang kimcuc 9080
Bạn đang xem 20 trang mẫu của tài liệu "Bài giảng Các kinh nghiệm quí của công nghệ phần mềm", để tải tài liệu gốc về máy hãy click vào nút Download ở trên

Tóm tắt nội dung tài liệu: Bài giảng Các kinh nghiệm quí của công nghệ phần mềm

Bài giảng Các kinh nghiệm quí của công nghệ phần mềm
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 1
Các kinh nghiệm quí của 
Công nghệ phần mềm
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 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ủả cácù vấná đềà trong phátù triểnå phầnà mềmà
? Trình bàỳ 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àỳ đểå giảIû
quyếtá cácù vấná đềà trong phátù triểnå phầnà mềmà
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 3
Phân tích tình hình của CNPM
Kinh tế thế giớI ngày
càng phụ thuộc hơn
vào CNPM
Các ứng dụng mơ rộng
về kích thước, độ phức
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
Không đủ nhân lực có
trình độ
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 4
Phát triển phần mềm là công việc tập thể
Project
Manager
Performance
Engineer
Release
Engineer
Analyst
Developer
Tester
Các thách thức
• Các nhóm đông hơn
• Sự chuyên môn hóa
• Phân tán
• Công nghệ thay đổi
quá nhanh
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 5
Chúng ta đã làm việc ra sao ?
Project
Manager
Performance
Engineer
Release
Engineer
Analyst
Tester
• Nhiều thà h công
• Quá nhiều thất bại
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 6
Các triệu chứng của các vấn đề trong PTPM
? Hiểuå khôngâ đúngù nhữngõ gì 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ảỏ trì vàø nângâ cấpá , mởû rộngä
? Phátù hiệnä trễã cácù lỗã hổngå củả dựï ánù
? Chấtá lượngï phầnà mềmà kémù
? Hiệuä năngê củả phầnà mềmà thấpá
? Cácù thànhø viênâ trong nhómù khôngâ biếtá đượcï ai đãõ thay đổiå
cáiù gì, khi nàò , ởû đâuâ , tai sao phảiû thay đổiå
? Quáù trình build-and-release khôngâ đángù tin cậyä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 7
Symptoms
end-user needs
changing
requirements
modules dont fit
hard to maintain
late discovery
poor quality
poor performance
colliding
developers
build-and-release
Root Causes
insufficient requirements
ambiguous communications
brittle architectures
overwhelming
complexity
undetected inconsistencies
poor testing
subjective
assessment
waterfall
development
uncontrolled change
insufficient automationDiagnose
Chữa trị triệu chứng không giải quyết vấn đề
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 8
Các nguyên nhân chính của các v/đ trong PTPM
? Sựï quảnû lýù 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å soátù
? Cóù nhữngõ mâuâ thuẫnã khôngâ phátù hiệnä đượcï giữã 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ủả 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ủả cácù thay đổiå
? Thiếuá cácù côngâ cụï tựï độngä hóá
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 9
? 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èò nànø
? Q/tr phátù triểnå thácù nướcù
? Sựï thay đổiå khôngâ k/soátù
? Thiếuá sựï tựï độngä hóá
? Phátù triểnå theo vòngø lặpë
? Quảnû trị cácù y/c
? Sửû dụngï KT component
? Môâ hình hóá trựcï quan
? Kiểmå định chấtá lượngï
? Kiểmå soátù cácù thay đổiå
Nguyên nhân cốt lõiâ â á õ Các kinh nghiệm tốtù ä á
Các kinh nghiệm giúp giải quyết các vấn đề
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 10
Symptoms
end-user needs
changing
requirements
modules dont fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Root Causes
insufficient requirements
ambiguous
communications
brittle architectures
overwhelming complexity
undetected
inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
insufficient automation
Best Practices
develop iteratively
manage requirements
use component
architectures
model the software
visually
verify quality
control changes
G/q các nguyên nhân giúp giảm các triệu chứng
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 11
Phátù triểnå theo vòngø lặpë
Kiểmå soátù cácù thay đổiå trong hệä thốngá
Sửû dụngï
kiếná trúcù
Component
Quảnû trị
Cácù y/c
Môâ hình hóá
trựcï quan
Kiểmå định
chấtá lượngï
Các kinh nghiệm quí của CNPM
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 12
Các kinh nghiệm tạo ra các nhóm lv hiệu năng cao
Project
Manager
Performance
Engineer
Release
Engineer
Analyst
Developer
Tester
Kết quả
• Nhiều dự án thành
công hơn
Control Changes
Develop Iteratively
Use
Component
Architectures
Manage
Requirements
Model
Visually
Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 13
Kinh nghiệm 1: PTPM theo vòng lặp
Develop Iteratively
Control Changes
Use
Component
Architectures
Manage
Requirements
Model
Visually
Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 14
Thời gian và tiền bạc chi ra để cài đặt một 
thiết kế
sai là không thể bù đắ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ủỷ bỏû dựï ánù
$$$
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 15
T I M E
Qui trình thác nước truyền thống
Subsystem
Testing
System Testing
Code & Unit
Testing
Design
Requirements
Analysis
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 16
R
I
S
K
T I M E
Qui trình thác nước có nhiều rủi ro
Subsystem
Testing
System Testing
Code & Unit
Testing
Design
Requirements
Analysis
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 17
Ứ/d QT thác nước theo vòng lặp
? Cácù vòngø lặpë đầuà dànhø cho cácù v/đ nhiềuà rủiû ro
? Mỗiã vòngø lặpë 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ù
T
C
D
R
T I M E
Iteration 1 Iteration 2 Iteration 3 
T
C
D
R
T
C
D
R
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 18
Qui trình lặp đẩy nhanh việc giảm rủi ro
WaterfallIterative
R
I
S
K
T I M E
Iteration Iteration Iteration Iteration Iteration Iteration Iteration
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 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ë
? Cácù càiø đặtë bộä phậnä cóù thểå triểnå khai riêngâ
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 20
Áp dụng các kinh nghiệm trong chu kỳ sống PM
Project Management
Environment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary
Iteration(s)
Iter.
#1
Phases
Process Workflows
Iterations
Supporting Workflows
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Deployment
Configuration & Change Mgmt
Requirements
Elaboration TransitionInception Construction
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 21
Nhậnä vàø khuyếná khích cácù
feedback từø ngườiø dùngø
Cácù hiểuå lầmà nghiêmâ trọngï
đượcï làmø rõõ sớmù
Tậpä trung phátù triểnå cácù kháiù
niệmä chứá nhiềuà rủiû ro trướcù
Đánhù giáù kháchù quan thôngâ qua
test
Mâuâ thuẫnã đc phátù hiệnä sớmù
Bắté đầuà test sớmù
Cácù rủiû ro đượcï xácù định vàø giảiû
quyếtá sớmù
Qui trình lặp giải quyết các vấn đề
Nguyên nhân cốt lõi Cách giải quyết 
? Khôngâ đủû cácù yêuâ cầuà
đ/v hệä thốngá
? Trao đổiå TT mơ hồà
? Kiếná trúcù kémù bềnà vữngõ
? Độä phứcù tạpï quáù cao
? Đánhù giáù chủû quan
? Cácù mâuâ thuẫnã khôngâ
đượcï phátù hiệnä
? Kiểmå chứngù kémù
? QT thácù nướcù
? Cácù thay đổiå khôngâ ks
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 22
Kinh nghiệm 2: Quản lý yêu cầu đ/v hệ thống
Control Changes
Develop Iteratively
Use 
Component
Architectures
Manage 
Requirements
Model
Visually
Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 23
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 PTPM
Kinh nghiệm 2: Quản lý yêu cầu đ/v hệ thống
? Suy dẫnã , tổå chứcù , vàø tạọ sưu liệuä
vềà cácù yêuâ cầuà chứcù năngê vàø
cácù ràngø buộcä
? Lượngï giáù cácù thay đổiå vàø xácù
định ảnhû hưởngû củả chúngù
? Theo dấuá vàø tao sưu liệuä vềà cácù
thỏả hiệpä & cácù quyếtá định
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 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 đ/v hệ thống, và
?Thiết lập và duy trì sự thỏa thuận giữa
customer/user và project team liên quan đến các
thay đổi về yêu cầu đ/v hệ thống
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 25
Thỏa thuận về những gì mà HT phải làm
Đích
Surrogate
Goal
Xác minh
Các yêu cầu
Cộng đồng
Các Customer
User
Các yêu cầu
Hệ thống
cần xây dựng
Adapted from Al Davis
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 26
Y/c ảnh hưởng đến nhiều thành phần khác
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 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ủả
ngườiø dùngø mộtä cáchù cóù hiệuä quảû
? Đạtï đượcï thỏả thuậnä vớiù customer/user vềà cácù yêuâ
cầuà đốiá vớiù hệä thốngá
? Môâ hình hóá sựï tương tácù giữã user vàø system
? Thiếtá lậpä mộtä đườngø ranh giớiù (baseline) vàø qui
trình kiểmå soátù thay đổiå (change control process)
? Duy trì khảû năngê theo vếtá tiếná vàø lùiø cácù yêuâ cầuà
đ/v hệä thốngá
? Sửû dụngï mộtä qui trình lặpë
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 28
Các vấn đề giải quyết nhờ quản lý y/c đ/v HT
Nguyên nhân cốt lõiâ â á õ Cách giải quyếtù û á
Xây dựng trong quản lý Y/C
một tiếp cận kỷ luật
Trao đổi thông tin dựa trên
các y/c đã xác định
Đặt độ ưu tiên, lọc và theo dõi
các yêu cầu
Đánh giá khách quan các
chức năng và hiệu năng
Các mâu thuẫn đễ phát hiện
RM tool cung cấp một kho
chứa các y/c, thuộc tính và đồ
hình, sẽ được kết nối tự động
với sưu liệu
? Thiếuá cácù y/c đ/v HT
? Trao đổiå TT mơ hồà
? Kiếná trúcù kémù bềnà vữngõ
? Độä phứcù tạpï quáù cao
? Đánhù giáù chủû quan
? Cácù mâuâ thuẫnã khôngâ
đượcï phátù hiệnä
? Kiểmå chứngù kémù
? QT thácù nướcù
? Cácù thay đổiå khôngâ ks
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 29
Use
Component
Architectures
Kinh nghiệm 3: Dùng kiến trúc Component-Based
Control Changes
Develop Iteratively
Manage
Requirements
Model
Visually
Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 30
Kiến trúc phần mềm xác định:
? Kiếná trúcù phầnà mềmà chứá đựngï cácù quyếtá định
quan trọngï vềà tổå chứcù củả 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
này thành các subsystem lớn hơn
?Kiểu kiến trúc định hướng cho tổ chức này, cho các
phần tử cấu trúc và interface của chúng, các công
tác, và sự tổng hợp giữa chúng
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 31
Các ảnh hưởng của kiến trúc
? Kiếná trúcù phầnà mềmà liênâ quan đếná cấuá trúcù , hànhø
vi vàø ngữõ cảnhû (context):
?Cách dùng (Usage)
?Chức năng (Functionality)
?Hiệu năng (Performance)
?Tính co dãn (Resilience)
?Khả năng tái sử dụng (Reuse)
?Tính dễ hiểu (Comprehensibility)
?Các ràng buộc về kinh tế và kỹ thuật và các dung
hòa
?Tính thẩm mỹ (Aesthetics)
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 32
Resilient, Component-Based Architectures
? Cácù kiếná trúcù tốtá thỏả mãnõ cácù y/c đ/v chúngù , làø
tính đà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
?Phân chia công việc rõ ràng trong đội ngũ PTPM
?Gói gọn các phụ thuộc phần cứng & hệ thống
? Mộtä kiếná trúcù component-based cho phépù
?Tái sử dụng hoặc tùy chỉnh các component sẵn có
?Chọn 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 quí trong CNPM
Duong Anh Ð?c 33
Ví dụ: Component-Based Architecture
Key:
- Purchased
- Built
- New
User Interface 
Mechanisms
Oracle Vantive
Customer Product
Lead Tracking
User Interface
License
Licensing 
User Interface
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 34
Kiến trúc Component giải quyết các vấn đề
Cácù Component dễã tạọ ra
cácù kiếná trúcù đànø hồià
Táiù sửû dụngï cácù com. vàø
framework Thương mạiï trởû
nênâ dễã dàngø
Tính đơn thểå cho phépù phânâ
táchù cácù điềuà lo lắngé
Component cung cấpá nềnà
tảngû tựï nhiênâ cho quảnû lýù
cấuá hình
Cácù ccụï môâ hình hóá trựcï
quan hỗã trợï thiếtá kếá tựï độngä
component-based
Các nguyên nhân cốt lõiù â â á õ Cách giải quyếtù û á
? Thiếuá y/c đ/v 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ù
? Qui trình thácù nướcù
? Cácù thay đổiå khôngâ
thểå kiểmå soátù
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 35
Kinh nghiệm 4: Mô hình hóa trực quan phần mềm
Control Changes
Develop Iteratively
Use
Component
Architectures
Manage
Requirements
Verify
QualityModel 
Visually
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 36
Mô hình hóa trực quan tăng khả năng
quản lý độ phức tạp của phần mềm
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ủả cácù thànhø phầnà
kiếná trúcù
? 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àỳ chi tiếtá theo nhu cầuà côngâ
việcä
? Duy trì tinhd nhấtá quánù giữã thiếtá kếá vàø càiø đặtë
? Tăngê cườngø trao đổiå thôngâ tin rõõ ràngø
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 37
UML là gì ?
? Unified Modeling Language (UML) làø ngônâ ngữõ
• đặc tả
• trực quan hóa
• xây dựng
• làm sưu liệu
cácù artifact củả mộtä hệä thốngá phầnà mềmà
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 38
Các lược đồ là các khung nhìn của mô hình
Một mô hình là một mô
tả đầy đủ của hệ thống
từ một phối cảnh cụ thể
Deployment
Diagrams
Deployment
Diagrams
use-case
Diagrams
use-case
Diagrams
Scenario
Diagrams
Scenario
DiagramsScenario
Diagrams
Scenario
DiagramsSequence
Diagrams
Sequence
Diagrams
State
Diagrams
State
DiagramsState
Diagrams
State
DiagramsState
Diagrams
State
Diagrams
Component
Diagrams
Component
DiagramsComponent
Diagrams
Component
DiagramsComponent
Diagrams
Co ponent
Diagrams
Models
State
Diagrams
State
DiagramsState
Diagrams
State
DiagramsObject
Diagrams
Object
Diagrams
Scenario
Diagrams
Scenario
DiagramsScenario
Diagrams
Scenario
DiagramsCollaboration
Diagrams
Collaboration
Diagrams
Activity
Diagrams
Activity
Diagrams
State
Diagrams
State
DiagramsState
Diagrams
State
DiagramsClass
Diagrams
Clas
Diagrams
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 39
Mô hình hóa trực quan dừng các lược đồ UML
Actor A
use-case 1
use-case 2
Actor B
user : ÀÚ
mainWnd : MainWnd
fileMgr : FileMgr
repository : Repository
document : Document
gFile : GrpFile
9 : s o r t B y N a m e ( )
L
1: D o c view request ( )
2 : fetchDoc ( )
5 : readDoc ( )
7 : r e a d F i l e ( )
3: c r e a t e ( )
6 : f i l l D o c u m e n t( )
4: c r e a t e ( )
8 : f i l l F i l e( )
GrpFile
read( )
open( )
create( )
fillFile( )
rep
Repository
name : char * = 0
readDoc( )
readFile( )
(from Persistence)
FileMgr
fetchDoc( )
sortByName( )
DocumentList
add( )
delete( )
Document
name : int
docid : int
numField : int
get( )
open( )
close( )
read( )
sortFileList( )
create( )
fillDocument( )
fList
1
FileList
add( )
delete( )
File
read( )
read() fill the 
code..
UI
MFC
RogueWave
global
DocumentApp
Persistence Window 9 5
óÀÌ . E X E
W i n d o w s
N T
Á. E X E
W i n d o w s
N T
W i n d o w s 9 5
S o l a r i s
A Ø A Ø . EXE
A l p h a
U N I X
IBM
M a i n f r a m e
ÀÌÀÌ
W i n d o w s 9 5
Ã
e â ÈÀ ÀÀ Á Ã á
- Àì 95 : óÀÌ
- Àì N T : ÀÀ
- À Ó: À ÀÌ ,
-IBM ÀÁÀÓ: ÀÌ ,
Document
FileManager
GraphicFile
File
Repository DocumentList
FileList
user
mainWnd fileMgr: 
FileMgr
repositorydocument : 
Document
gFile
1: D o c view request ( )
2 : fetchDoc ( )
3: c r e a t e ( )
4: c r e a t e ( )
5 : readDoc ( )
6 : f i l l D o c u m e n t( )
7 : r e a d F i l e ( )
8 : f i l l F i l e( )
9 : s o r t B y N a m e ( )
A Ù â
A Ø U Ù ÃÙ.
ÈÀÀÚÂ ÀÂ
A Ø Á
A Õ ÁÀ ÃÙ.
Èé àÀéÀ
Ãé ÀÌ
A Ù A Ø Ã E Ø e ù
A Ù U Ø .
Customer
name
addr
withdraw ()
fetch ()send()
receive ()
>
Forward Engineering (Code Generation)
and
Reverse Engineering
Executable System
User Interface
Definition
Domain
Expert
Openning
Writing
Reading Closing
add file [ numberOffile==MAX ] / 
flag OFF
add file
close file
close file
use-case 3
Source Code edit, compile, debug, link
Use-Case Diagram Class Diagram
Collaboration Diagram
Sequence Diagram
Component
Diagram
State Diagram
Package
Diagram
Deployment
DiagramClass
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 40
Thay đổi bản thiết kế ?
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
risk targeting
deployment
Đánh giá requirements
analysis & design
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 41
Cái gì thay đổi? Những thay đổi này được phép 
không?
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
risk targeting
deployment
Đánh giá requirements
analysis & design
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 42
Giải quyết vấn đề nhờ mô hình hóa trực quan 
Cácù use-case vàø scenario
đặcë tảû hànhø vi rõõ ràngø
Cácù môâ hình nắmé bắté tườngø
minh cácù thiếtá kếá
Cácù kiếná trúcù khôngâ đơn thểå
hay cứngù nhắcé bị phơi bàỳ
Cácù chi tiếtá khôngâ cầnà thiếtá
đượcï che dấuá khi cầnà
Cácù thiếtá kếá tườngø minh chỉ ra
cácù mâuâ thuẫnã dễã dàngø
Chấtá lượngï củả ứngù dụngï đi kèmø
vớiù bảnû thiếtá kếá tốtá
Cácù ccụï trựcï quan hỗã trợï cho
môâ hình hóá bằngè UML
Các nguyên nhân cốt lõiLời giải
? Thiếuá y/c đ/v HT
? Truyềnà tin 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ù
? Qui trình thácù nướcù
? Thay đổiå khôngâ thểå KS
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 43
Kinh nghiệm 5: Kiểm định chất lượng phần mềm
Control Changes
Develop Iteratively
Use
Component
Architectures
Manage
Requirements
Model
Visually Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 44
Chi phí tìm kiếm và sửa chữa các vấn đề của 
phần mềm sẽ tăng hàng 100, hàng 1000 lần 
sau khi PT
Development Deployment
Cost
Kinh nghiệm 5: Kiểm định chất lượng phần mềm
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 45
PT theo vòng lặp cho phép test liên tục
T I M E
Test Test Test
T
C
D
R
Iteration 1 Iteration 2 Iteration 3 
T
C
D
R
T
C
D
R
Test 
Life 
Cycle Evaluate
Plan
Design
Implement
Execute
Evaluate
Plan
Design
Implement
Execute
Evaluate
Plan
Design
Implement
Execute
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 46
Test trong một môi trường PT theo vòng lặp
R
eq
ui
re
m
en
ts
R
eq
ui
re
m
en
ts
Test Suite 1
Iteration 2 Iteration 3 Iteration 4
Test Suite 2 Test Suite 3 Test Suite 4
Iteration 1
A
ut
om
at
ed
A
ut
om
at
ed
Te
st
s
Te
st
s
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 47
Tự động hóa giảm thời gian và công sức test
One Manual Test Cycle
13,000 Tests 2 Weeks 6 People
13,000 Test
6 giờ
1 người
13,000 Test
6 giờ
1 người
Một chu trình test thủ ông
13,000 lần Test 2 Tuần 6 Người
Test
tự động
Ch?y ngày càng nhi?u test hon
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 48
Các khía cạnh của chất lượng phần mềm
Chức năng
Độ tin cậy
Hiệu năng ứng
dụng
Hiệu năng của
hệ thống
Ư/d của tôi có làm những gì
được yêu cầu?
Ư/d của tôi có làm mất bộ
nhớ?
Ư/d của tôi có hồi đáp hợp
lệ?
Ư/d của tôi có hoạt động
dưới công suất thiết kế?
Tạo cácTest case cho mỗi
scenario đã cài đặt
Các công cụ phân tích và
các thiết bị coding
Kiểm tra hiệu năng của mỗi
use-case/scenario đã cài đặt
Kiểm tra hiệu năng của tất
cả use-case ở mức độ tin
cậy và trường hợp xấu nhất
Kiểu Tại sao? Thế nào?
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 49
Các vấn đề được giải quyết nhờ kiểm định CL
Testing đánhù giáù kháchù quan
vềà trạngï tháiù dựï ánù
Đánhù giáù kháchù quan triệtä
tiêuâ cácù mâuâ thuầnà sớmù
Testing vàø kiểmå định tậpä
trung vàò vùngø high risk
Tìm thấyá thiếuá sótù sớmù vàø chi
phí sửả chữã thấpá
Cácù ccụï test tựï độngä giúpù
test độä tin cậyä , chứcù năngê vàø
hiệuä năngê
Nguyên nhân cốt lõi Cách giải quyết
? Thiếuá y/c đ/v HT
? Truyềnà tin 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
đượcï xácù định
? Test kémù
? Qui trình thácù nướcù
? Thay đổiå khôngâ thểå KS
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 50
Kinh nghiệm 6: Kiểm soát thay đổi trong PM
Control Changes
Develop Iteratively
Use
Component
Architectures
Manage
Requirements
Model
Visually
Verify
Quality
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 51
Thiếu sự kiểm soát tường minh, đầy đủ
Phát triển song song dễ biến thành hỗn độn
Kinh nghiệm 6: Kiểm soát thay đổi trong PM
? Nhiềuà developer
? Nhiềuà team
? Nhiềuà vị trí
? Nhiềuà vòngø lậpä
? Nhiềuà release
? Nhiềuà project
? Nhiềuà platform
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 52
Ba khía cạnh chính của CM System
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 53
Các khái niệm của Configuration & Change M.
? Phânâ rãõ kiếná trúcù thànhø cácù subsystem vàø gánù 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 soát tất cả 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àò xuấtá hiệnä trong release
nàò
? Đưa ra mộtä đườngø ranh giớiù hạnï chỗã hoànø tấtá củả mỗiã
vòngø lặpë
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 54
Change Control hỗ trợ tất cả Best Practices khác
? Phátù triểnå theo
qui trình lặpë
? Quảnû lýù Y/c
? Dùngø kiếná trúcù
component
? Môâ hình hóá trựcï
quan
? Kiểmå định chấtá
lượngï
? Dựï ánù chỉ tiếná triểnå khi cácù thay
đổiå đượcï kiểmå soátù
? Đểå loạiï bỏû sựï dãnõ phạmï vị, đánhù
giáù ảnhû hưởngû củả mọiï thay đổiå dựï
kiếná trướcù khi chấpá nhậnä
? Cácù Component phảiû đángù tin cậyä ,
i.e., tìm thấyá phiênâ bảnû đúngù đắné
củả tấtá cảû cácù phầnà hợpï thànhø
? Đểå bảỏ đảmû sựï hộiä tụï, phảiû tăngê
dầnà kiểmå soátù cácù model khi cácù
thiếtá kếá ổnå định
? Test chỉ cóù ýù nghĩa nếuá cácù version
cácù phầnà tửû đang test đượcï biếtá rõõ
vàø cácù phầnà tửû đượcï bỏả vệä trướcù
cácù thay đổiå
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 55
Các vần đề được giải quyết nhờ Control Change
Requirements change workflow đượcï
xácù định vàø lặpë lạiï đi lặpë lạiï
Cácù Change request làmø cho thôngâ
tin trao đổiå rõõ ràngø
Vùngø làmø việcä biệtä lậpä giảmû cácù trởû
ngạiï do làmø việcä song song
Thốngá kêâ vềà mứcù độä thay đổiå làø độä
đo tốtá cho cácù đánhù giáù kháchù quan
vềà trạngï tháiù củả dựï ánù
Vùngø làmø việcä chứá tấtá cảû cácù
artifact dễã tạọ sựï nhấtá quánù
Kiểmå soátù đượcï sựï lan truyềnà cácù
thay đổiå
Cácù thay đổiå đượcï duy trì trong mộtä
hệä thốngá mạnhï mẽõ, cóù khảû năngê tùỳ
chỉnh
Nguyên nhân cốt lõiâ â á õ Cách giải quyếtù û á
? Thiếuá y/c đ/v HT
? Truyềnà tin mơ hồà
? Kiếná trúcù kémù bềnà
? Quáù phứcù tạpï
? Đánhù giáù chủû quan
? Mâuâ thuẫnã chưa đượcï
xácù định
? Test kémù
? Qui trình thácù nướcù
? Thay đổiå khôngâ thểå
kiểmå soátù
? Thiếuá ccụï tựï độngä
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 56
Các kinh nghiệm hỗ trợ lẫn nhau
Control
Changes
Develop 
Iteratively
Use
Component
Architectures
Model
Visually
Verify
Quality
Ensures users involved
as requirements evolve
Validates architectural
decisions early on
Addresses complexity of
design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Manage
Requirements
Các kinh nghi?m quí trong CNPM
Duong Anh Ð?c 57
Tổng kết
?Kếtá quảû làø phầnà mềmà trởû nênâ
?Đúng thời hạn
?Bảo đảm ngân sách
?Thỏa mãn nhu cầu user
Project
Manager
Performance
Engineer
Release
Engineer
Analyst
Developer
Tester
Control 
Changes
Develop Iteratively
Use 
Component
Architectures
Manage 
Requirements
Model 
Visually Verify
Quality

File đính kèm:

  • pdfbai_giang_cac_kinh_nghiem_qui_cua_cong_nghe_phan_mem.pdf