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ác ứng dụng mở rộng về

càng phụ thuộc hơn vào kích thước, độ phức tạp,
CNPM và phân bố

Thương trường đòi hỏi nâng Không đủ nhân lực có trình

cao năng suất, chất lượng và độ
giảm thời gian
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
• Các nhóm đông hơn Engineer
• Sự chuyên môn hóa Analyst
• Phân tán
Project
• Công nghệ thay đổi quá nhanh Manager
Developer

Tester Release
Engineer

Các kinh nghiệm quí của CNPM 4

Chúng ta đã làm việc ra sao?

• Nhiều thành công

• Quá nhiều thất bại
Performance
Engineer
Analyst

Project
Manager

Developer

Tester Release
Engineer

Các kinh nghiệm quí của CNPM 5

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
brittle architectures
requirements
overwhelming
modules don’t fit
complexity
hard to maintain
undetected inconsistencies
late discovery
poor testing
poor quality
subjective
poor performance assessment
colliding waterfall
developers development
build-and-release uncontrolled change
Diagnose insufficient automation

Các kinh nghiệm quí của CNPM 7

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 đủ  Phát triển theo vòng lặp
 Trao đổi thông tin mơ hồ  Quản trị các yêu cầu
 Kiến trúc kém bền vững  Sử dụng kiến trúc
 Độ phức tạp quá cao component
 Các lượng giá chủ quan  Mô hình hóa trực quan
 Các mẫu thuẫn chưa thấy  Kiểm định chất lượng
 Kiểm chứng nghèo nàn  Kiểm soát các thay đổi
 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 9

Giải quyết các nguyên nhân giúp giảm các triệu chứng
Symptoms
end-user needs
changing requirements
modules don’t fit
hard to maintain
late discovery
poor quality
poor performance
colliding developers
build-and-release
Các kinh nghiệm quí của CNPM
Root Causes Best Practices
insufficient requirements develop iteratively
ambiguous communications manage requirements
brittle architectures use component
architectures
overwhelming complexity
model the software visually
undetected inconsistencies
verify quality
poor testing
control changes
subjective assessment
waterfall development
uncontrolled change
insufficient automation
10
Các kinh nghiệm quí của CNPM

Phát triển theo vòng lặp

Sử dụng
Quản trị Mô hình hóa Kiểm định
kiến trúc trực quan
các y/c chất lượng
Component

Kiểm soát các thay đổi trong hệ thống

Các kinh nghiệm quí của CNPM 11

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

Tester
Use
Manage Component Model Verify
Requirements Architectures Visually 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

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes

Các kinh nghiệm quí của CNPM 13

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

Requirements
R Analysis
I
Design
S
K 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 Iteration 3

R R R
D D D
C C C
T 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

K Iterative Waterfall

Iteration Iteration Iteration Iteration Iteration Iteration Iteration

T I M E

Các kinh nghiệm quí của CNPM 18

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 Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
Các kinh nghiệm quí của CNPM 20
Qui trình lặp giải quyết các vấn đề
Nguyên nhân cốt lõi
 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
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
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

Use
Model Verify
Manage Component Visually Quality
Requirements Architectures

Control Changes

Các kinh nghiệm quí của CNPM 22

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 Hệ thống

Các Customer cần xây dựng
User

Xác minh Surrogate

Các yêu cầu Goal

Adapted from Al Davis Các yêu cầu

Các kinh nghiệm quí của CNPM 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
 hình, sẽ được kết nối tự động
Thiếu ccụ tự động
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à đồ
với sưu liệu

Các kinh nghiệm quí của CNPM 28

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

Develop Iteratively

Manage Use Model Verify

Requirements Visually Quality
Component
Architectures

Control Changes

Các kinh nghiệm quí của CNPM 29

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 Licensing

User Interface User Interface

User Interface
Mechanisms

Customer Product License

Key:
- Purchased Oracle Vantive
- Built
- New

Các kinh nghiệm quí của CNPM 33

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
 tảng tự nhiên cho quản lý
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
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

Use
Manage Component Verify
Requirements Model Quality
Architectures Visually

Control Changes

Các kinh nghiệm quí của CNPM 35

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ể
State
State
Diagrams
Class
Diagrams
Diagrams State
use-case State
Diagrams
Diagrams Object
Diagrams
Activity Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Sequence
Diagrams State
Diagrams
Diagrams Models Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Component
Collaboration
Diagrams Deployment Diagrams
Diagrams Diagrams Diagrams

Các kinh nghiệm quí của CNPM 38

Mô hình hóa trực quan dùng các lược đồ UML

Use-Case Diagram Class Diagram State Diagram add file

DocumentList
FileMgr Doc ument

add( )
name : int
fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int
Writing
add file [ numberOffile==MAX ] /
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileLis t( ) Openning

use-case 1 add( )
fList create( )
fillDocument( )
dele te( )
1 close file

Actor A Actor B
close file
Closing
Reading

rep
use-case 2
<<entity>>
File
Repository

Customer
(from Persis tenc e) GrpFile
read( )

name
name : char * = 0
read( )
readDoc( )

addr
open( )
readFile( )
create( )

receive()
fillFile( )

use-case 3 withdraw()
Domain fetch()
Expert UI
send()
Deployment
MFC Class Diagram
DocumentApp
ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨
- À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼ ­¹ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼ ­¹ö ¹× µ¥ÀÌŸ ¼­¹ ö, Åë½Å ¼­¹ ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ ö, Åë½Å ¼­¹ ö

RogueWave
Repository DocumentList Window95 Windows95
9: sortByName ( )
Persistence Windows95

global
¹®¼­°ü¸®

FileManager Ŭ¶óÀ̾ðÆ®.EXE

User Interface
¹®¼­°ü¸® ¾ÖÇø´

mainWnd : MainWnd

Package
Windows
NT

1: Doc view request ( )

Definition
L

Document Solaris

2: fetchDoc( )
¹®¼­°ü¸® ¿£Áø.EXE
4: create ( )
gFile : GrpFile

Diagram
Alpha
8: fillFile ( ) UNIX
ÀÀ¿ë¼­¹ ö.EXE

Windows
NT

user : »ç¿ëÀÚ GraphicFile IBM

fileMgr : FileMgr
Mainframe

3: create ( )
File FileList
6: fillDocument ( )

µ¥ÀÌŸº£À̽º¼ ­¹ö

7: readFile ( )

5: readDoc ( )

document : Document
repository : Repository

Component Forward Engineering (Code Generation)

Collaboration Diagram Diagram and
Reverse Engineering
mainWnd fileMgr : document : gFile repository
user FileMgr Document

Source Code edit, compile, debug, link

ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ 1: Doc view request ( )
»ç¿ëÀÚ°¡ ¿äûÇÑ´Ù.

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

Đánh giá requirements

analysis & design

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

Đánh giá requirements

analysis & design

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
 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
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
42
Kinh nghiệm 5: Kiểm định chất lượng phần mềm

Develop Iteratively

Use
Manage Model
Component Visually Verify
Requirements Architectures Quality

Control Changes

Các kinh nghiệm quí của CNPM 43

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 Deployment

Các kinh nghiệm quí của CNPM 44

Phát triển theo vòng lặp cho phép test liên tục

Iteration 1 Iteration 2 Iteration 3

R R R
D D D
C C C
T T T

Test Test Test

T I M E

Plan Plan Plan

Design Design Design
Test Implement Implement Implement
Life Execute Execute Execute
Cycle Evaluate Evaluate Evaluate

Các kinh nghiệm quí của CNPM 45

Test trong một môi trường phát triển theo vòng lặp

Iteration 1 Iteration 2 Iteration 3 Iteration 4

Requirements
Automated Tests

Test Suite 1 Test Suite 2 Test Suite 3 Test Suite 4

Các kinh nghiệm quí của CNPM 46

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ờ Chạy ngày càng nhiều test hơn
1 người

Các kinh nghiệm quí của CNPM 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 Tạo cácTest case cho mỗi
gì được yêu cầu? scenario đã cài đặt

Độ tin cậy Ứng dụng của tôi có làm mất bộ Các công cụ phân tích và các
nhớ? thiết bị coding

Hiệu năng ứng Ứng dụng của tôi có hồi đáp Kiểm tra hiệu năng của mỗi
dụng hợp lệ? use-case/scenario đã cài đặt

Kiểm tra hiệu năng của tất cả

Hiệu năng của Ứng dụng của tôi có hoạt động use-case ở mức độ tin cậy và
hệ thống dưới công suất thiết kế? trường hợp xấu nhất

Các kinh nghiệm quí của CNPM 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

Use
Manage Model Verify
Component Visually
Requirements Architectures Quality

Control Changes

Các kinh nghiệm quí của CNPM 50

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  Dự án chỉ tiến triển khi các thay đổi
trình lặp được kiểm soát
 Quản lý yêu cầu  Để 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
 Dùng kiến trúc  Các Component phải đáng tin cậy, i.e.,
component 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
 Mô hình hóa trực dần kiểm soát các model khi các
quan thiết kế ổn định
 Test chỉ có ý nghĩa nếu các version
 Kiểm định chất các phần tử đang test được biết rõ và
lượng các phần tử được bảo vệ trước các
thay đổi
Các kinh nghiệm quí của CNPM 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

Ensures users involved Manage

as requirements evolve Requirements

Validates architectural Use

Component
decisions early on
Architectures

Develop Addresses complexity of Model

Iteratively Visually
design/implementation incrementally

Measures quality early and often Verify

Quality

Evolves baselines incrementally Control

Changes

Các kinh nghiệm quí của CNPM 56

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
Performance
 Thỏa mãn nhu cầu user Engineer
Analyst

Project
Develop Iteratively
Manager
Developer
Use Model
Manage Component Visually Verify
Requirements Architectures Quality
Tester
Control Changes

Release
Engineer
Các kinh nghiệm quí của CNPM 57