Ccmtptpm 01 cackinhnghiemptpm

Công cụ và môi trường phát triển phần mềm

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

Công cụ môi trường phát triển phần mềm
1

Mục đích

w 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
w 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
w 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

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 kích thước, độ phức tạp,
vào 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
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

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

5

Các triệu chứng của các vấn đề trong phát triển PM

w Hiểu không đúng những gì người dùng cần
w Không thể thích ứng với các thay đổi về yêu cầu của hệ thống
w Các Module không khớp với nhau
w Phần mềm khó bảo trì và nâng cấp, mở rộng
w Phát hiện trễ các lỗ hổng của dự án
w Chất lượng phần mềm kém
w Hiệu năng của phần mềm thấp
w 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
w Quá trình build-and-release không đáng tin cậy

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

7

Các nguyên nhân chính

w Sự quản lý yêu cầu người dùng không đầy đủ
w Trao đổi thông tin mơ hồ và không đầy đủ
w Kiến trúc không vững chắc
w Độ phức tạp vượt quá tầm kiểm soát
w 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
w Kiểm chứng không đầy đủ
w Sự lượng giá chủ quan về tình trạng của dự án
w Sự chậm trễ trong việc giảm rủi ro do mô hình thác nước
w Sự lan truyền không thể kiểm soát của các thay đổi
w Thiếu các công cụ tự động hóa

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

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 manage requirements
modules don’t fit communications use component
hard to maintain brittle architectures architectures

late discovery overwhelming complexity model the software
undetected inconsistencies visually
poor quality
poor testing verify quality
poor performance
subjective assessment control changes
colliding developers
build-and-release 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ị kiến trúc Mô hình hóa Kiểm định
các yêu cầu trực quan chất lượng
Component

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

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

Phá triể lặ

Tester
Quả trị
Quản trị Sử dụng Kiểm định
Kiể đị
Mô hình hóa
hì hó
cầ
các yêu cầu kiế trú
kiến trúc trự
trực quan chấ lượ
chất lượng
Component
Release
Engineer
Kiểm soát các thay đổI trong hệ thống
Kiể soá cá đổ hệ thố

12
Developer

Kinh nghiệm 1: Phát triển phần mềm 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êu cầu chất lượng
Component


13

Kinh nghiệm 1: Phát triển phần mềm theo vòng lặp(tt)

w 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
w 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

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

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

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

w Các vòng lặp đầu dành cho các vấn đề nhiều rủi ro
w 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
w Mỗi vòng lặp bao gồm cả việc tích hợp và kiểm chứng

17

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

R

I

S

K Iterative Waterfall

Iteration Iteration Iteration Iteration Iteration Iteration Iteration
T I M E

18

Các đặc tính của qui trình lặp

w Các rủi ro chính được giải quyết trước khi có các phát triển lớn
w Các vòng lặp đầu tiên cho phép nhận feedback
w Việc kiểm chứng và tích hợp diễn ra liên tục
w Các cột mốc cục bộ sẽ định ra các tiêu điểm ngắn hạn
w Sự tiến triển được đo bằng bản cài đặt
w Các cài đặt bộ phận có thể triển khai riêng

19

Áp dụng các kinh nghiệm trong chu kỳ sống của PM

20

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 đốI Nhận và khuyến khích các
với hệ thống feedback từ người dùng
þ Trao đổi thông tin mơ hồ Các hiểu lầm nghiêm trọng
được làm rõ sớm
¨ Kiến trúc kém bền vững
Tập trung phát triển các khái
þ Độ phức tạp quá cao niệm chứa nhiều rủi ro trước
þ Đánh giá chủ quan
Đánh giá khách quan thông
þ Các mâu thuẫn không được qua test
phát hiện
Mâu thuẫn đc phát hiện sớm
þ Kiểm chứng kém
þ Qui trình thác nước Bắt đầu test sớm
¨ Các thay đổi không kiểm soát Các rủi ro được xác định và
giải quyết sớm
¨ Thiếu công cụ tự động
21

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


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


22

Kinh nghiệm 2: Quản lý yêu cầu đối với hệ thống(tt)

w 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
w Lượng giá các thay đổi và xác định ảnh
hưởng của chúng
w Theo dấu và tao 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

23

Định nghĩa: Yêu cầu đối với HT và sự quản lý chúng

w 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ó
w 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

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

25

Yêu cầu ảnh hưởng đến nhiều thành phần khác

26

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

w 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ả
w Đạt được thỏa thuận với customer/user về các yêu cầu đối với
hệ thống
w Mô hình hóa sự tương tác giữa user và system
w Thiết lập một đường ranh giới (baseline) và qui trình kiểm soát
thay đổi (change control process)
w 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
w Sử dụng một qui trình lặp

27

Các vấn đề giải quyết nhờ quản lý yêu cầu đối với HT

þ Thiếu các y/c đ/v HT Xây dựng trong quản lý Y/C
một tiếp cận kỷ luật
þ Trao đổi TT mơ hồ
¨ 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
þ Độ phức tạp quá cao
Đặt độ ưu tiên, lọc và theo dõi
þ Đánh giá chủ quan các yêu cầu
þ Các mâu thuẫn không Đánh giá khách quan các
được phát hiện chức năng và hiệu năng
þ Kiểm chứng kém Các mâu thuẫn đễ phát hiện
¨ QT thác 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à đồ
þ Thiếu ccụ tự động 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


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


29

Kiến trúc phần mềm xác định:

w 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

30

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

w 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)

31

Resilient, Component-Based Architectures

w 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
w 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
w 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

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

33

Kiến trúc Component giải quyết các vấn đề

Các nguyên nhân cốt lõi Cách giải quyết
¨ Thiếu y/c đ/v hệ thống Các Component dễ tạo ra các
¨ Trao đổi TT mơ hồ kiến trúc đàn hồi
þ Kiến trúc kém bền Tái sử dụng các com. và
framework Thương mại trở
þ Quá phức tạp nên dễ dàng
¨ Đánh giá chủ quan
Tính đơn thể cho phép phân
¨ Các mâu thuẫn chưa tách các điều lo lắng
xác định
¨ Test kém Component cung cấp nền
¨ Qui trình thác nước tảng tự nhiên cho quản lý
cấu hình
þ Các thay đổi không thể
kiểm soát Các ccụ mô hình hóa trực
quan hỗ trợ thiết kế tự động
þ Thiếu ccụ tự động component-based
34

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


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


35

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

w Nắm bắt cấu trúc và hành vi của các thành phần kiến trúc
w Thể hiện cách mà các phần tử hệ thống khớp với nhau
w Che dấu hoặc phơi bày chi tiết theo nhu cầu công việc
w Duy trì tính nhất quán giữa thiết kế và cài đặt
w 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

36

UML là gì?

w 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

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

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

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

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 Document

add( ) name : int
fetchDoc( ) delete( )
docid : int
sortByName( ) numField : int
add file [ numberOffile==MAX ] / Writing
get( ) flag OFF
open( ) read() fill the
close( ) code..
FileList read( )
sortFileList( ) Openning
use-case 1 fList create( )
fillDocument( )
add( )
delete( )
1 close file
Actor A Actor B
close file
Closing
Reading

rep
use-case 2 File

<<entity>>
Repository

(from Persistence)

name : char * = 0
read( )
GrpFile
Customer
readDoc( ) read( ) name
readFile( ) open( )
create( )
fillFile( )
addr
receive()
use-case 3 withdraw()
Domain fetch()
Expert UI
send()
Deployment
MFC Class Diagram
DocumentApp
ºÐ»ê È¯°æÀÇ ÇÏµå¿þ¾ î¹× ³× Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½ Ã½ºÅÛ ¿¬°á ¸ ðµ¨
- À©µµ¿ì 95 : Å¬¶óÀÌ¾ ðÆ®
- À©µµ¿ì NT: ÀÀ¿ë¼-¹ ö
- À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼-¹ö ¹ × µ¥ÀÌÅ¸ ¼-¹ö, Åë½Å ¼-¹ö
- IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌÅ¸ ¼-¹ ö, Åë½ Å ¼-¹ö

RogueWave
Repository DocumentList Wi ndow95
Wi ndows95
9: sortByN ame ( )
Persistence Wi ndows95

global
¹®¼-°ü¸®

FileManager Å¬¶óÀÌ¾ðÆ®.EXE
¹®¼-°ü¸® ¾ÖÇ Ã¸´

User Interface mainWnd : MainWnd Wi ndows
NT

Package
1: Doc view request ( )
L

Document
Definition
Solaris

2: fetchDoc( )
¹®¼-°ü¸® ¿£Áø.EXE
4: create ( )
gFile : GrpFile Alpha
8: fillFile ( ) UNIX

Diagram
ÀÀ¿ë¼-¹ö.EXE

Wi ndows
NT

user : »ç¿ëÀÚ GraphicFile IBM
Mainframe
fileMgr : FileMgr File
3: create ( )
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

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

2: fetchDoc( )

3: create ( )

4: create ( )
Source Code edit, compile, debug, link
5: readDoc ( )

È-ÀÏ°ü¸®ÀÚ´Â ÀÐ¾î¿Â 6: fillDocument ( )
¹®¼-ÀÇ Á¤º¸¸¦ ÇØ´ç ¹® ¼-
°´Ã¼¿¡ ¼ ³Á¤À» ¿äÃ»Ç Ñ´Ù.

7: readFile ( )

8: fillFile ( )

È-¸é °´Ã¼ ´Â ÀÐ ¾îµéÀÎ 9: sortByN ame ( )
°´Ã¼µé¿¡ ´ëÇØ ÀÌ¸§º°·Î
Á¤·ÄÀ» ½ ÃÄÑ È- ¸é¿¡
º¸¿©ÁØ´ Ù.

Sequence Diagram

Executable System

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ế?

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?

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
þ Thiếu y/c đ/v HT Các use-case và scenario
đặc tả hành vi rõ ràng
þ Truyền tin mơ hồ
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ể hay
¨ Đánh giá chủ quan cứng nhắc bị phơi bày
þ Các mâu thuẫn chưa Các chi tiết không cần thiết
xác định được che dấu khi cần
þ Test kém Các thiết kế tường minh chỉ ra
các mâu thuẫn dễ dàng
¨ Qui trình thác nước
Chất lượng của ứng dụng đi
¨ Thay đổi không thể KS
kèm với bản thiết kế tốt
þ Thiếu ccụ tự động
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


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


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

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

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

46

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

Một chu trình test thủ công
One Manual Test Cycle
13,000 lầnTests
13,000 Test 2 Weeks
2 Tuần 6 People
6 Người

Test
tự động
13,000 Test
13,000 Test
6 giờ
6 giờ
Chạy ngày càng nhiều test hơn
1 người
1 người

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

48

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

¨ Thiếu y/c đ/v HT Testing đánh giá khách quan
¨ Truyền tin mơ hồ về trạng thái dự án
¨ Kiến trúc 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
þ Đánh giá chủ quan Testing và kiểm định tập
þ Các mâu thuẫn chưa trung vào vùng high risk
được xác định
þ Test kém Tìm thấy thiếu sót sớm và chi
phí sửa chữa thấp
¨ Qui trình thác nước
¨ Thay đổi không thể KS Các ccụ test tự động giúp
þ Thiếu ccụ tự động 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


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


50

Kinh nghiệm 6: Kiểm soát thay đổi trong phần mềm (tt)

w Nhiều developer
w Nhiều team
w Nhiều vị trí
w Nhiều vòng lập
w Nhiều release
w Nhiều project
w 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

51

Ba khía cạnh chính của CM System

52

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

w 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
w 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, …
w Thiết lập một vùng làm việc tích hợp
w Thiết lập một cơ chế khả thi kiểm soát các thay đổi
w Nắm bắt thay đổi xuất hiện nào xuất hiện trong release nào
w Đưa ra một đường ranh giới hạn chỗ hoàn tất của mỗi vòng
lặp

53

Kiểm soát thay đổi hỗ trợ tất cả Best Practices khác

w 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
w Quản lý yêu cầu è Để loại bỏ sự dãn phạm vị, đánh giá
ảnh hưởng của mọi thay đổi dự kiến
trước khi chấp nhận
w 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
w Mô hình hóa trực è Để bảo đảm sự hội tụ, phải tăng
quan dần kiểm soát các model khi các
thiết kế ổn định
w Kiểm định chất è Test chỉ có ý nghĩa nếu các version
lượng các phần tử đang test được biết rõ và
các phần tử được bỏa vệ trước các
thay đổi
54

Các vần đề được giải quyết nhờ kiểm soát thay đổi
þ Thiếu y/c đ/v HT Requirements change workflow
được xác định và lặp lại đi lặp lại
þ 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
Vùng làm việc biệt lập giảm các trở
þ Quá phức tạp ngại do làm việc song song
þ Đánh giá chủ quan Thống kê về mức độ thay đổi là độ
đo tốt cho các đánh giá khách quan
þ Mâu thuẫn chưa được 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ễ tạo sự nhất quán
¨ Qui trình thác nước Kiểm soát được sự lan truyền các
thay đổi
þ Thay đổi không thể
Các thay đổi được duy trì trong một
kiểm soát hệ thống mạnh mẽ, có khả năng tùy
chỉnh
þ Thiếu ccụ tự động
55

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

Ensures users involved Quản trị
as requirements evolve các yêu cầu

Sử dụng
Validates architectural
kiến trúc
decisions early on Component

Phát triển theo Mô hình hóa
Addresses complexity of
vòng lặp trực quan
design/implementation incrementally

Measures quality early and often Kiểm định
chất lượng

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

56

Tổng kết

w 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
Phá triể lặ
Phát triển theo vòng lặp Manager
Developer
Quả trị
Quản trị Sử dụng Kiểm định
Kiể đị
Mô hình hóa
hì hó
cầ
các yêu cầu kiế trú
kiến trúc trự
trực quan chấ lượ
chất lượng
Component Tester

Kiểm soát các thay đổI trong hệ thống
Kiể soá cá đổ hệ thố
Release
Engineer
57

Ccmtptpm 01 cackinhnghiemptpm

Recomendados

Recomendados

Más contenido relacionado

Similar a Ccmtptpm 01 cackinhnghiemptpm

Similar a Ccmtptpm 01 cackinhnghiemptpm (20)

Más de Nguyen Tran

Más de Nguyen Tran (20)

Ccmtptpm 01 cackinhnghiemptpm