Transcript Best Practices of Software Engineering

Giáo trình Phân tích và thiết kế hướng đối tượng bằng UML
Các kinh nghiệm quí của Công
nghệ phần mềm
Các kinh nghiệm quí của CNPM
1
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 6 kinh nghiệm tốt của Rational trong quá trình phát
triển phần mềm
 Xem xét cách sử 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
Các kinh nghiệm quí của CNPM
2
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í của CNPM
3
Phát triển phần mềm là công việc tập thể
Các thách thức
Performance
Engineer
• Các nhóm đông hơn
• Sự chuyên môn hóa
Analyst
• Phân tán
Project
Manager
• Công nghệ thay đổi quá nhanh
Developer
Tester
Các kinh nghiệm quí của CNPM
4
Release
Engineer
Chúng ta đã làm việc ra sao?
• Nhiều thành công
• Quá nhiều thất bại
Analyst
Performance
Engineer
Project
Manager
Developer
Tester
Các kinh nghiệm quí của CNPM
5
Release
Engineer
Các triệu chứng của các vấn đề trong phát triển PM
 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êu cầu của
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, tại sao phải thay đổi
 Quá trình build-and-release không đáng tin cậy
Các kinh nghiệm quí của CNPM
6
Chữa trị triệu chứng không giải quyết hết vấn đề
Root Causes
Symptoms
insufficient requirements
end-user needs
ambiguous communications
changing
requirements
brittle architectures
modules don’t fit
overwhelming
complexity
hard to maintain
undetected inconsistencies
late discovery
poor testing
poor quality
poor performance
subjective
assessment
colliding
developers
waterfall
development
build-and-release
uncontrolled change
Diagnose
Các kinh nghiệm quí của CNPM
7
insufficient automation
Các nguyên nhân chính










Sự quản lý yêu cầu 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ữa yêu cầu,
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ự chậm trễ 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
Thiếu các công cụ tự động hóa
Các kinh nghiệm quí của CNPM
8
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 kinh nghiệm tốt
Các yêu cầu 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
Qui trình phát triển thác nước
Sự thay đổi không kiểm soát
Thiếu sự tự động hóa
Các kinh nghiệm quí của CNPM
 Phát triển theo vòng lặp
 Quản trị các yêu cầu
 Sử dụng kiến trúc
component
 Mô hình hóa trực quan
 Kiểm định chất lượng
 Kiểm soát các thay đổi
9
Giải quyết các nguyên nhân giúp giảm các triệu chứng
Symptoms
Root Causes
Best Practices
end-user needs
insufficient requirements
develop iteratively
changing requirements
ambiguous
communications
manage requirements
modules don’t fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
brittle architectures
overwhelming complexity
undetected inconsistencies
poor testing
subjective assessment
waterfall development
uncontrolled change
insufficient automation
Các kinh nghiệm quí của CNPM
10
use component
architectures
model the software
visually
verify quality
control changes
Các kinh nghiệm quí của CNPM
Phát triển theo vòng lặp
Quản trị
các y/c
Sử dụng
kiến trúc
Component
Mô hình hóa
trực quan
Kiểm soát các thay đổi trong hệ thống
Các kinh nghiệm quí của CNPM
11
Kiểm định
chất lượng
Các kinh nghiệm tạo ra các nhóm làm việc hiệu năng cao
Kết quả
Performance
Engineer
• Nhiều dự án thành công hơn
Analyst
Project
Manager
Developer
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Tester
Model
Visually
Verify
Quality
Release
Engineer
Control Changes
Các kinh nghiệm quí của CNPM
12
Kinh nghiệm 1: Phát triển phần mềm theo vòng lặp
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Các kinh nghiệm quí của CNPM
13
Verify
Quality
Kinh nghiệm 1: Phát triển phần mềm theo vòng lặp(tt)
 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 chi ra để cài đặt một thiết kế sai
là không thể bù đắp
Các kinh nghiệm quí của CNPM
14
Qui trình thác nước truyền thống
Requirements
Analysis
Design
Code & Unit
Testing
Subsystem
Testing
System Testing
T I M E
Các kinh nghiệm quí của CNPM
15
Qui trình thác nước có nhiều rủi ro
R
I
S
K
Requirements
Analysis
Design
Code & Unit
Testing
Subsystem
Testing
System Testing
T I M E
Các kinh nghiệm quí của CNPM
16
Ứng dụng qui trình thác nước theo vòng lặp
Iteration 1
Iteration 2
R
Iteration 3
R
D
R
D
D
C
C
T
C
T
T
T I M E
 Các vòng lặp đầu dành cho các vấn đề 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 vòng lặp bao gồm cả việc tích hợp và kiểm chứng
Các kinh nghiệm quí của CNPM
17
Qui trình lặp đẩy nhanh việc giảm rủi ro
R
I
S
Iterative
K
Iteration
Iteration
Iteration
Waterfall
Iteration
Iteration
T I M E
Các kinh nghiệm quí của CNPM
18
Iteration
Iteration
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í của CNPM
19
Áp dụng các kinh nghiệm trong chu kỳ sống của 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
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter.
Iter.
#n+1 #n+2
Iterations
Các kinh nghiệm quí của CNPM
20
Iter.
#m
Iter.
#m+1
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
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
 Không đủ các yêu cầu đốI
với hệ thống
 Trao đổi thông tin 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
 Qui trình thác nước
 Các thay đổi không kiểm soát
 Thiếu công cụ tự động
Các kinh nghiệm quí của CNPM
Tập trung phát triển các khái
niệm chứa 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
21
Kinh nghiệm 2: Quản lý yêu cầu đối với hệ thống
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Các kinh nghiệm quí của CNPM
22
Verify
Quality
Kinh nghiệm 2: Quản lý yêu cầu đối với hệ thống(tt)
 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à các ràng buộc
 Lượng giá các thay đổi và xác định ảnh
hưởng của chúng
 Theo dấu và tạo sưu 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 phát triển phần mềm
Các kinh nghiệm quí của CNPM
23
Định nghĩa: Yêu cầu đối với 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êu cầu 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
đối với 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 đối với
hệ thống
Các kinh nghiệm quí của CNPM
24
Thỏa thuận về những gì mà hệ thống phải làm
Đích
Cộng đồng
Các Customer
User
Hệ thống
cần xây dựng
Xác minh
Các yêu cầu
Adapted from Al Davis
Các kinh nghiệm quí của CNPM
Surrogate
Goal
Các yêu cầu
25
Yêu cầu ảnh hưởng đến nhiều thành phần khác
Các kinh nghiệm quí của CNPM
26
Làm thế nào để bắt được lỗi về yêu cầu 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) 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 đốI với hệ
thống
 Sử dụng một qui trình lặp
Các kinh nghiệm quí của CNPM
27
Các vấn đề giải quyết nhờ quản lý yêu cầu đối với HT
Nguyên nhân cốt lõi










Cách giải quyết
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í của CNPM
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
28
Kinh nghiệm 3: Dùng kiến trúc Component-Based
Develop Iteratively
Manage
Requirements
Model
Visually
Use
Component
Architectures
Control Changes
Các kinh nghiệm quí của CNPM
29
Verify
Quality
Kiến trúc phần mềm xác định:
 Kiến trúc phần mềm 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 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í của CNPM
30
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í của CNPM
31
Resilient, Component-Based Architectures
 Các kiến trúc tốt thỏa mãn các yêu cầu đối với 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ũ phát triển phần
mềm
 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í của CNPM
32
Ví dụ: Component-Based Architecture
Lead Tracking
User Interface
Licensing
User Interface
User Interface
Mechanisms
Customer
Key:
- Purchased
- Built
- New
Các kinh nghiệm quí của CNPM
Product
Oracle
Vantive
33
License
Kiến trúc Component giải quyết các vấn đề
Các nguyên nhân cốt lõi










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í của CNPM
Cách giải quyết
Các Component dễ tạo 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óa trực
quan hỗ trợ thiết kế tự động
component-based
34
Kinh nghiệm 4: Mô hình hóa trực quan phần mềm
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Các kinh nghiệm quí của CNPM
35
Verify
Quality
Kinh nghiệm 4: Mô hình hóa trực quan phần mềm(tt)





Nắm bắt cấu trúc và hành vi của 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ày chi tiết theo nhu cầu công việc
Duy trì tinh nhất quán giữa thiết kế và cài đặt
Tăng cường trao đổi thông tin rõ ràng
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
Các kinh nghiệm quí của CNPM
36
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ủa một hệ thống phần mềm
Các kinh nghiệm quí của CNPM
37
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ể
Activity
Diagrams
Scenario
Scenario
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Các kinh nghiệm quí của CNPM
State
State
Diagrams
Class
Diagrams
Diagrams
use-case
Diagrams
Models
Deployment
Diagrams
38
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
State
Diagrams
Diagrams
Component
Component
Diagrams
Component
Diagrams
Diagrams
Mô hình hóa trực quan dùng các lược đồ UML
Use-Case Diagram
Class Diagram
State Diagram
add file
Writing
add file [ numberOffile==MAX ] /
flag OFF
Openning
use-case 1
clos e file
Actor A
Actor B
clos e file
Reading
use-case 2
Domain
Expert
Closing
<<entity>>
Customer
name
addr
receive()
withdraw()
fetch()
send()
use-case 3
Deployment
Diagram
UI
Class
MFC
DocumentApp
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼¹ö ¹× µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼¹ö, Åë½Å ¼¹ö
RogueWave
Repository
DocumentList
Windows95
Window95
Persistence
9: sortByName ( )
Windows95
global
¹®¼°ü¸®
Ŭ¶óÀ̾ðÆ®.EXE
FileManager
User Interface
Definition
¹®¼°ü¸® ¾ÖÇø´
mainWnd : MainWnd
1: Doc view request ( )
L
2: fetchDoc( )
gFile : GrpFile
4: create ( )
8: fillFile ( )
user : »ç¿ëÀÚ
fileMgr : FileMgr
Package
Diagram
Windows
NT
Document
Solaris
¹®¼°ü¸® ¿£Áø.EXE
Alpha
UNIX
ÀÀ¿ë¼¹ö.EXE
Windows
NT
GraphicFile
File
3: create ( )
IBM
Mainframe
FileList
6: fillDocument ( )
µ¥ÀÌŸº£À̽º¼¹ö
7: readFile ( )
5: readDoc ( )
document : Document
repository : Repository
Collaboration Diagram
mainWnd
fileMgr :
FileMgr
user
ƯÁ¤¹®¼¿¡ ´ëÇÑ º¸±â¸¦
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.
document :
Document
gFile
Component
Diagram
Forward Engineering (Code Generation)
and
Reverse Engineering
repository
1: Doc view request ( )
Source Code edit, compile, debug, link
2: fetchDoc( )
3: create ( )
4: create ( )
5: readDoc ( )
ÈÀÏ°ü¸®ÀÚ´Â Àоî¿Â
¹®¼ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼
°´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù.
6: fillDocument ( )
7: readFile ( )
8: fillFile ( )
È¸é °´Ã¼´Â ÀоîµéÀÎ
°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î
Á¤·ÄÀ» ½ÃÄÑ È¸é¿¡
º¸¿©ÁØ´Ù.
9: sortByName ( )
Sequence Diagram
Executable System
Các kinh nghiệm quí của CNPM
39
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
requirements
analysis & design
Đánh giá
implementation & testing
deployment
Thay đổi bản thiết kế ?
Các kinh nghiệm quí của CNPM
40
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
requirements
analysis & design
Đánh giá
implementation & testing
deployment
Cái gì thay đổi? Những thay đổi này được phép không?
Các kinh nghiệm quí của CNPM
41
Giải quyết vấn đề nhờ mô hình hóa trực quan
Các nguyên nhân cốt lõi










Lời giải
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ày
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ủa ứ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óa bằng UML
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í của CNPM
42
Kinh nghiệm 5: Kiểm định chất lượng phần mềm
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Các kinh nghiệm quí của CNPM
43
Verify
Quality
Kinh nghiệm 5: Kiểm định chất lượng phần mềm (tt)
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 trăm, hàng ngàn lần sau khi phát triển
Cost
Development
Các kinh nghiệm quí của CNPM
Deployment
44
Phát triển theo vòng lặp cho phép test liên tục
Iteration 1
Iteration 2
R
R
D
R
D
D
C
C
T
T I M E
Test
Life
Cycle
C
T
Test
Test
Plan
Design
Implement
Execute
Evaluate
Các kinh nghiệm quí của CNPM
Iteration 3
Plan
Design
Implement
Execute
Evaluate
45
T
Test
Plan
Design
Implement
Execute
Evaluate
Automated Tests
Requirements
Test trong một môi trường phát triển theo vòng lặp
Iteration 1
Iteration 2
Test Suite 1
Test Suite 2
Các kinh nghiệm quí của CNPM
Iteration 3
Test Suite 3
46
Iteration 4
Test Suite 4
Tự động hóa giảm thời gian và công sức test
Một
One
chu
Manual
trình test
Testthủ
Cycle
công
13,000
13,000
lầnTests
Test
2 Weeks
2 Tuần
6 People
6 Người
Test
tự động
13,000 Test
6 giờ
1 người
Các kinh nghiệm quí của CNPM
Chạy ngày càng nhiều test hơn
47
Các khía cạnh của chất lượng phần mềm
Kiểu
Tại sao?
Thế nào?
Chức năng
Ứng dụng của tôi có làm những
gì được yêu cầu?
Tạo cácTest case cho mỗi
scenario đã cài đặt
Độ tin cậy
Ứng dụng của tôi có làm mất bộ
nhớ?
Các công cụ phân tích và các
thiết bị coding
Hiệu năng ứng Ứng dụng của tôi có hồi đáp
dụng
hợp lệ?
Kiểm tra hiệu năng của mỗi
use-case/scenario đã cài đặt
Hiệu năng của
hệ thống
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
Các kinh nghiệm quí của CNPM
Ứng dụng của tôi có hoạt động
dưới công suất thiết kế?
48
Các vấn đề được giải quyết nhờ kiểm định chất lượng
Nguyên nhân cốt lõ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
đượ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í của CNPM
Cách giải quyết
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ào vùng high risk
Tìm thấy thiếu sót sớm và chi
phí sửa chữa thấp
Các ccụ test tự động giúp
test độ tin cậy, chức năng và
hiệu năng
49
Kinh nghiệm 6: Kiểm soát thay đổi trong phần mềm
Develop Iteratively
Manage
Requirements
Use
Component
Architectures
Model
Visually
Control Changes
Các kinh nghiệm quí của CNPM
50
Verify
Quality
Kinh nghiệm 6: Kiểm soát thay đổi trong phần mềm (tt)







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
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
Các kinh nghiệm quí của CNPM
51
Ba khía cạnh chính của CM System
Các kinh nghiệm quí của CNPM
52
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ào xuất hiện trong release nào
Đưa ra một đường ranh giới giới hạn chỗ hoàn tất của mỗi
vòng lặp
Các kinh nghiệm quí của CNPM
53
Kiểm soát thay đổi hỗ trợ tất cả Best Practices khác
 Phát triển theo qui
trình lặp
 Quản lý yêu cầu
 Dùng kiến trúc
component
 Mô hình hóa trực
quan
 Kiểm định chất
lượng
Các kinh nghiệm quí của CNPM
 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 vi, đánh giá
ảnh hưởng của 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ủa tất cả
các phần hợp thành
 Để bảo đả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ảo vệ trước các
thay đổi
54
Các vần đề được giải quyết nhờ kiểm soát thay đổi
Nguyên nhân cốt lõ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
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í của CNPM
Cách giải quyết
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ủa dự án
Vùng làm việc chứa tất cả các
artifact dễ tạo 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ùy
chỉnh
55
Các kinh nghiệm hỗ trợ lẫn nhau
Develop
Iteratively
Ensures users involved
as requirements evolve
Manage
Requirements
Validates architectural
decisions early on
Use
Component
Architectures
Addresses complexity of
design/implementation incrementally
Measures quality early and often
Evolves baselines incrementally
Các kinh nghiệm quí của CNPM
56
Model
Visually
Verify
Quality
Control
Changes
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
Performance
Engineer
Analyst
Project
Manager
Develop Iteratively
Developer
Manage
Requirements
Use
Component
Architectures
Model
Visually
Verify
Quality
Tester
Control Changes
Release
Engineer
Các kinh nghiệm quí của CNPM
57