BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM

ĐẠI HỌC ĐÀ NẴNG
ĐẠI HỌC BÁCH KHOA
KHOA CÔNG NGHỆ THÔNG TIN

BÁO CÁO THỰC HÀNH
CÔNG NGHỆ PHẦN MỀM
GVHD : LÊ THỊ MỸ HẠNH
SVTH : NGUYỄN TRƯỜNG LƯU 09T4
PHAN QUỐC HẬU 09T4
TRẦN ĐỨC TRÌNH 09T4
NHÓM : 10A
Đà Nẵng, tháng 11 năm 2012
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
1
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
BÀI TẬP 1
Đề bài: Công ty IT quyết định sản xuất một máy tính mới để cung cấp một môi trường
mô phỏng cho các hệ thống thời gian thực. Công ty cần các công nghệ và hệ điều hành mới
để để sản xuất máy tính. Phần mềm hệ thống cung cấp giao diện giữa hệ điều hành và phần
cứng cần phải được phát triển. Công ty quyết định sử dụng ngôn ngữ lập trình Java
đ
ể viết
phần mềm hệ thống. Tuy nhiên, Java có một số hạn chế trong lập trình hệ thống. Nhóm phát
triển xác định một số tính năng mở rộng cần được tích hợp thêm vào chương tr

ình d
ịch Java
để lập trình hệ thống. Đặc tả yêu cầu có thể thay đổi trong quá trình phát triển dự án. Các
thành viên phát triển phần mềm cho máy tính mới cần chương tr
ình d
ịch Java để biên dịch
phần mềm. Hầu hết các yêu cầu của phần mềm đều cần các mở rộng của chương tr
ình d
ịch
Java để chạy trên hệ điều hành mới.
Hãy xác
đ
ịnh mô hình phát triển phần mềm phù hợp để phát triển máy tính mới. Yêu
cầu các sinh viên chia nhóm và thảo luận.
Mô hình lựa chọn: Mô hình xoắn ốc
I. Giới thiệu mô hình xoắn ốc:
Mô hình xoắn ốc, ban đầu do Boehm đề xuất, là mô hình tiến trình phần mềm tiến hoá
vốn cặp đôi bản chất lặp của làm bản mẫu với các khía cạnh hệ thống và có kiểm soát của mô
hình trình tự tuyến tính. Nó cung cấp tiềm năng cho việc phát triển nhanh các phiên
bản tăng dần của phần mềm. Dùng mô hình xoắn ốc này, phần mềm được phát triển thành
từng chuỗi các lần đưa ra tăng dần. Trong những lần lặp đầu, việc đưa ra tăng dần có thể là
mô hình trên giấy hay bản mẫu. Trong các lần lặp sau, các phiên bản đầy đủ tăng dần của hệ
thống được k
ĩ ngh
ệ hoá sẽ được tạo ra.
Mô hình xoắn ốc được chia thành một số khuôn khổ hoạt động, c
ũng c
òn đư
ợc gọi
là vùng nhiệm vụ. Về cơ bản, có từ ba tới sáu vùng:

1. Trao đổi với khách hàng - nhiệm vụ đòi hỏi thiết lập việc trao đổi có hiệu quả giữa
người phát triển và khách hàng.
2. Lập kế hoạch - nhiệm vụ đ
òi h
ỏi định ngh
ĩa các t
ài nguyên, h
ạn thời gian và các
thông tin liên quan tới dự án.
3. Phân tích rủi ro - nhiệm vụ đ
òi h
ỏi định giá cả những rủi ro k
ĩ t
huật và quản lí
4. K
ĩ ngh
ệ - nhiệm vụ đ
òi h
ỏi xây dựng một hay nhiều biểu diễn cho ứng dụng
5. Xây dựng và đưa ra - nhiêm vụ đ
òi h
ỏi xây dựng, kiểm thử, thiết đặt và cung cấp
sự hỗ trợ cho người dùng (như tài liệu và huấn luyện)
6. Đánh giá của khánh hàng - nhiệm vụ đ
òi h
ỏi thu được phản hồi của khách hàng
dựa trên đánh giá về biểu diễn phần mềm được tạo ra trong giai đoạn k
ĩ ngh
ệ và được
SVTH : TR

ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
2
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
cài đặt trong giai đoạn cài đặt.
Mỗi một trong các vùng đều được đặt vào một tập các nhiệm vụ, được gọi là tập nhiệm
vụ, vốn được thích ứng với các đặc trưng của dự án được tiến hành. Với các dự án
nhỏ, số các nhiệm vụ công việc và tính hình thức của chúng là thấp. Với các dự án
lớn, nhiều căng thẳng hơn, thì mỗi vùng nhiệm vụ lại chứa nhiều nhiệm vụ công việc vốn
được xác định để đạt tới mức độ hình thức cao hơn. Trong mọi trường hợp, hoạt động hỗ trợ
(như quản lí cấu hình phần mềm và đảm bảo chất lượng phần mềm) sẽ được áp dụng.
Khi tiến trình tiến hoá này bắt đầu, tổ k
ĩ ngh
ệ phần mềm đi v
ò
ng xoắn ốc theo chiều
ngược kim đồng hồ, bắt đầu từ trung tâm. Mạch đầu tiên quanh xoắn ốc có thể làm phát sinh
việc phát triển đặc tả sản phẩm; các bước tiếp theo quanh xoắn ốc có thể được dùng để phát
triển bản mẫu và thế rồi các phiên bản phức tạp dần thêm. Mỗi bước qua vùng lập kế hoạch
lại làm nảy sinh việc điều chỉnh kế hoạch dự án. Chi phí và lịch biểu được điều chỉnh dựa
trên phản hồi được suy từ đánh giá của khách hàng. Bên cạnh đó, người quản lí dự án điều
chỉnh số việc lặp đ
ã l
ập kế hoạch cần để hoàn chỉnh phần mềm.
Không giống như mô h

ình ti
ến trình cổ điển vốn kết thúc khi phần mềm được chuyển
giao, mô hình xoắn ốc có thể được thích ứng để áp dụng trong toàn bộ cuộc đời của phần
mềm máy tính. Một cái nhìn khác có thể được xem xét bằng việc kiểm tra trục điểm vào dự
án, như được vẽ trong hình trên. Mỗi hình hộp được đặt theo trục có thể được dùng để biểu
diễn cho điểm bắt đầu cho các kiểu dự án khác nhau. "Dự án phát triển khái niệm" bắt đầu
tại cốt lõi của xoắn ốc và sẽ tiếp tục (nhiều lần lặp xuất hiện theo con đường xoắn ốc mà vốn
gắn với vùng tô đậm trung tâm) cho tới khi việc phát triển khái niệm là đầy đủ. Nếu khái
niệm này được phát triển thành một sản phẩm thực tại, thì tiến trình tiến qua hình hộp tiếp
(điểm vào dự án phát triển sản phẩm mới) và một "dự án phát triển mới" được khởi đầu.
Sản phẩm mới sẽ tiến hoá qua một số lần lặp quanh xoắn ốc, đi theo con đường vốn gắn
vùng có tô mầu sáng hơn vùng l
õi. V
ề bản chất, xoắn ốc, khi được đặc trưng theo cách này,
vẫn còn làm việc cho tới khi phần mềm được cho nghỉ. Có những lúc tiến trình này
“ngủ”, nhưng bất kì khi nào một thay đổi được khởi đầu, thì tiến trình này lại bắt đầu tại
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
3
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
điểm vào thích hợp (tức là nâng cao sản phẩm).
Mô hình xoắn ốc là cách tiếp cận thực tế cho việc phát triển cho các hệ thống và phần
mềm qui mô lớn. Bởi vì phần mềm tiến hoá khi tiến trình tiến hoá, nên người phát triển và
khách hàng hiểu rõ h

ơn và ph
ản ứng với rủi ro tại từng mức tiến hoá. Mô hình xoắn ốc dùng
cách làm bản mẫu như một cơ chế làm giảm bớt rủi ro, nhưng điều quan trọng hơn, làm cho
người phát triển có khả năng áp dụng được cách tiếp cận làm bản mẫu tại mọi giai đoạn
trong tiến hoá của sản phẩm. Nó duy trì cách tiếp cận từng bước một cách có hệ thống
do cách tiếp cận vòng
đ
ời cổ điển gợi ý, nh
ưng t
ổ hợp cách tiếp cận này vào một khuôn
khổ lặp lại, vốn phản ánh được sát thực hơn thế giới thực. Mô hình xoắn ốc đ
òi h
ỏi việc xem
xét trực tiếp các rủi ro k
ĩ thu
ật tại mọi giai đoạn của dự án, và nếu được áp dụng đúng thì nó
có thể làm giảm rủi ro trước khi chúng trở thành vấn đề thực sự.
Nhưng giống như các mô h
ình khác, mô hình xo
ắn ốc không phải là một liều
thuốc bách bệnh. Có thể khó thuyết phục những khách hàng (đặc biệt trong tình huống có
hợp đồng) rằng cách tiếp cận tiến hoá là kiểm soát được. Nó đ
òi h
ỏi tri thức chuyên gia đánh
giá rủi ro chính xác và dựa trên tri thức chuyên gia này mà đạt được thành công. Nếu một rủi
ro chính không được phát hiện và quản lí thì không nghi ngờ gì nữa vấn đề sẽ xuất hiện. Cuối
cùng, chính bản thân mô hình này c
ũng còn chưa đư
ợc sử dụng rộng rãi nh
ư mô hình

trình tự tuyến tính hoặc làm bản mẫu. Cần phải có thêm một số năm nữa trước khi tính
hiệu quả của mô hình quan trọng này có thể được xác định với sự chắc chắn hoàn toàn.
Ưu điểm:
 Mô hình xoắn ốc là một trong những mô hình linh hoạt nhất của vòng
đ
ời phát triển
phần mềm. Các giai đoạn phát triển phần mềm có thể được xác định bởi người quản
lý dự án, theo sự phức tạp của dự án.
 Dự án được giám sát một cách dễ dàng và hiệu quả. Mỗi giai đoạn là những vòng lặp
được chia ra một cách rõ ràng.
 Mô hình xoắn ốc hướng đến sự phân tích rủi ro trong từng giai đoạn phát triển
phần mềm.
 Sự thay đổi của phần mềm có thể được kiểm soát và giải quyết trong từng giai đoạn.
 Phù hợp với các dự án có nhiều thay đổi, môi trường làm việc không ổn định.
Nhược điểm:
 Chi phí áp dụng mô hình xoắn ốc thường rất cao.
 Mô hình xoắn ốc phức tạp và khó áp dụng.
 Đ
òi h
ỏi năng lực lãnh
đ
ạo của người quản lý dự án và năng lực của nhóm dự án cao.
 Sự thay đổi từ phía khách hang nên những bản mẫu thường không được sử dụng
trong sản phẩm thật.
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY

ỄN TR
ƯỜNG LƯU
4
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
 Việc dự trù kinh phí khó khăn.
 Tài liệu đặc tả phức tạp, do phải chỉnh sửa qua từng giai đoạn khác nhau.
 Không phù hợp các dự án có rủi ro thấp.
II. Phân tích bài toán:
Bài toán đặt ra, công ty IT quyết định xây dựng một máy tính mới với công nghệ và hệ
điều hành mới. Phần mềm hệ thống được phát triển bằng ngông ngữ Java. Tuy nhiên, Java có
nhiều hạn chế về lập trình hệ thống, nhóm phát triển cần tích hợp một số tính năng mở rộng
cho chương tr
ình d
ịch Java. Các đặc tả yêu cầu có thể thay đổi trong quá trình phát triển dự
án. Hầu hết các yêu cầu của phần mềm đều cần các mở rộng của chương tr
ình d
ịch Java để
chạy trên hệ điều hành mới.
Qua những yêu cầu trên của bài toán, xây dựng một hệ điều hành và áp dụng công nghệ
mới vào hệ thống máy tính mới, đây là một dự án với quy mô lớn. Trước tiên, hệ thống cần
tích hợp bổ sung một số tính năng cho chương tr
ình d
ịch của Java, sau đó mới có thể xây
dựng được các phần mềm hệ thống và phần mềm ứng dụng khác. Các tính năng tích hợp này
chưa được xác định rõ ràng mà dễ thay đổi bổ sung trong quá trình phát triển dư án. Như
vậy, việc lựa chọn mô hình xoắn ốc để phát triển dự án này là phù hợp.
Thứ nhất, dự án của bài toán đặt ra có quy mô lớn và tính rủi ro cao, những yêu cầu của
phần mềm hệ thống chưa được xác định rõ ngay từ khi phát triển dự án, mà được thay đổi
trong quá trình phát triển dự án. Không giống như mô h
ình t

ăng trư
ởng, các thay đổi có
nguy cơ dẫn đến sự sụp đỗ toàn bộ hệ thống do kiến trúc hệ thống không rõ ràng mà
đư
ợc
thay đổi qua từng giai đoạn, mô hình xoắn ốc tập trung trước tiên vào việc nghiên cứu tính
rủi ro của từng giai đoạn phát triển. Với mỗi giai đoạn phát triển, nhiệm vụ đầu tiên của
nhóm dự án, phải xác định tính rủi ro của tính năng được tích hợp vào chương tr
ình d
ịch
Java như thế nào ? Liệu có dẫn đến hậu quả lớn đến toàn bộ hệ thống ? Từ những phân tích
rủi ro ban đầu cùng với đánh giá việc tích hợp từ những giai đoạn trước, người quản lý dự
án và nhóm phát triển dự án sẽ điều chỉnh và quyết định thích hợp.
Thứ hai, dự án sẽ được phát triển qua từng giai đoạn, với mỗi giai đoạn, nhóm dự án sẽ
tích hợp dần dần các tính năng vào chương tr
ình d
ịch Java, để thõa mãn các yêu cầu của
nhóm phát triển phần mềm ứng dụng và hệ thống. Nhóm dự án có thể sử dụng bản mẫu để
xác định rõ h
ơn các yêu c
ầu của tính năng cần thêm vào. Như vậy hệ thống sẽ được hoàn
thiện qua từng giai đoạn, cùng với phân tích rủi ro, hệ thống đảm bảo được tính kiến trúc.
Thứ ba, việc quản lý dự án sẽ dễ dàng và hiệu quả hơn, do sự phân chia rõ ràng của từng
giai đoạn phát triển hệ thống. Người quản lý sẽ nắm rõ từng giai đoạn, cũng như những thay
đổi đặc tả xuất hiện trong giai đoạn đó. Nếu thay đổi được xuất hiện, người quản lý và nhóm
dự án sẽ giải quyết được vấn đề dựa trên kiến trúc của hệ thống ở những giai đoạn trước đó.
Qua việc đánh giá rủi ro cùng với sự quản lý dễ dàng, người quản lý biết rõ cần phải quay trở
SVTH : TR
ẦN ĐỨC TR
ÌNH

– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
5
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
lại giai đoạn nào một cách chính xác nếu việc tích hợp sự thay đổi là không thể ở giai đoạn
hiện tại.
Từ những yếu tố trên, việc lựa chọn mô hình xoắn ốc là đúng đắn, đảm bảo vẫn kiến trúc
của hệ thống khi tích hợp thêm các tính năng vào.
BÀI TẬP 2
NGHIÊN CỨU KHẢ THI – FEASIBILITY STUDY
Khi nào chúng ta cần dừng một dự án “không tốt” ? Sau một cuộc khảo sát về 8000 dự án
IT, Standish Group báo cáo rằng khoảng 30% tổng số dự án đ
ã b
ị hủy bỏ ("Charting the Seas
of Information Technology," Dennis, MA: The Standish Group, 1994). Capers Jones báo cáo
rằng trung bình dự án được hủy bỏ ở Mỹ sau một năm so với kế hoạch và chi phí vượt
khoảng 200% so với dự kiến tại thời điểm dự án buộc phải dừng lại (Assessment and Control
of Software Risks, Englewood Cliffs, N.J.: Yourdon Press, 1994). Jones ước tính số tiền bỏ ra
cho các dự án bị hủy lên đến 15% tổng số tiền U.S bỏ ra để phát triển phần mềm, con số này
lên đến 14 triệu $ mỗi năm, điều này quả thật hết sức lãng phí.
Mặc dù những thống kê trên đ
ã ch
ỉ ra một cách chân thực, nhưng việc hủy bỏ một dự án
quả thật là điều khó khăn, tuy nhiên nếu việc dừng dự án xảy ra quá trễ sẽ dẫn đến những
lãng phí hơn nữa. Do đó, đểm giảm tối thiểu số tiền cần cho các công việc cần thiết, ngay từ
những bước đầu của vòng
đ

ời phát triển phần mềm (Software Development Life Cycle:
SDLC) cần phải xác định dự án được tiếp tục hay buộc phải dừng lại.
“Press Cancel to Exit or OK to Continue”
Làm thế nào để hủy bỏ một dự án phần mềm sớm ? Chúng ta cần tiến hành các nghiên
cứu khả thi sớm trong dự án để xác định quy mô dự án là hoàn toàn khả thi. Trước tiên,
nhóm dự án chuẩn bị các tài liệu liên quan đến việc nghiên cứu khả thi. Các kết quả của
nghiên cứu khả thi là một đánh giá tính khả thi, mà tại đó các nhóm dự án, khách hàng và
quản lý dự án quyết định tiếp tục hoặc dừng dự án lại. Việc xem xét tính khả thi thường
được quyết định thông qua một buổi họp hoặc đôi khi chỉ dự vào sự quyết định của một cá
nhân dựa trên những tài liệu nghiên cứu khả thi. Các thông tin cần thiết hỗ trợ cho xem xét
tính khả thi có thể được đưa ra sau khi dự án hoàn thành khoảng 10-20%.
Nghiên cứu khả thi là một hoạt động thời gian-thử nhiệm (time-tested practice), nhưng
nó không được sử dụng nhiều. Một cuộc khảo sát của KPMG cho thấy rằng 84% các công ty
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
6
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
có dự án runaway (vượt ra khỏi kiểm soát) đ
ãđư
ợc đề xuất sử dụng nghiên cứu khả thi như
là một phương tiện ngăn ngừa các vấn đề trong tương lai ("Runaway Projects—Cause and
Effect," Software World, vol. 26, no. 3, 1995). Cuộc khảo sát này cho thấy rằng các công ty đ
ã
không thực hiện phân tích khả thi trong các dự án runaway của họ.

Một lý do mà nghiên cứu khả thi không được sử dụng thường xuyên là do sự hiểu sai về
thuật ngữ “nghiên cứu khả thi”. Thuật ngữ “nghiên cứu khả thi” gợi lên câu hỏi về tính khả
thi kỹ thuật, và đối với những người thuộc nhóm dự án là những chuyên gia về ngôn ngữ lập
trình nào
đó trên m
ột hệ thống máy tính chủ đạo, thì những câu hỏi về tính khả thi kỹ thuật
không thể xuất hiện trong đầu của họ. “Nếu như chúng tôi biết về tính khả thi về mặt kỹ
thuật của dự án thì tại sao chúng tôi cần phải tiến hành nghiên cứu khả thi ?”.
Đối với một vài dự án, tính khả thi kỹ thuật là một mối quan tâm đáng kể: liệu có khả thi
khi xây dựng một Star War để phòng chống tên lữa ? Có khả thi về mặt kỹ thuật khi xây dựng
một ngôn ngữ tự nhiên tiếng Anh để phiên dịch tiếng Pháp ? Đối với nhiều dự án, tính khả
thi kỹ thuật không phải là mối quan tâm chính, mà cần phải xem xét đến các vấn đề phi kỹ
thuật: tổng chi phí cần để hoàn thành dự án, thời gian của dự án, khả năng chi trả của công
ty, phần mềm sẽ được sử dụng như thế nào sau khi hoàn thành …
Trong giai đoạn nghiên cứu khả thi, chúng ta tập trung vào bốn l
ĩnh v
ực quan tâm chính:
1. Khả thi về kinh tế: chi phí phát triển cần phải cân xứng với lợi ích mà hệ thống được
xây dựng đem lại. Tính khả thi về kinh tế thể hiện trên các nội dung sau:
- Khả năng tài chính của tổ chức cho phép thực hiện dự án.
- Lợi ích mà dự án phát triển hệ thống mang lại đủ bù đắp chi phí phải bỏ ra xây
dựng nó.
- Tổ chức chấp nhận được những chi phí thường xuyên khi hệ thống hoạt động
Một thuật ngữ hay dùng để chỉ tài liệu nghiên cứu khả thi về kinh tế là luận chứng
kinh tế. Luận chứng kinh tế nói chung được coi như nền tảng cho hầu hết các hệ
thống (các ngoại lệ là hệ thống quốc phòng, hệ thống luật, các hệ thống phục vụ cho
các nghiên cứu đặc biệt). Luận chứng kinh tế bao gồm:
- các mối quan tâm, nhất là phân tích chi phí/lợi ích
- chiến lược phát triển dài hạn của công ty
- sự ảnh hưởng tới các sản phẩm lợi nhuận khác

- chi phí cho tài nguyên cần cho việc xây dựng và phát triển thị trường tiềm năng
2. Khả thi về kỹ thuật: khảo cứu về chức năng, hiệu suất và ràng buộc có thể ảnh hưởng
tới khả năng đạt tới một hệ thống chấp nhận được. Nói cách khác, khả thi kỹ thuật là
xem xét khả năng kỹ thuật hiện tại có đủ đảm bảo thực hiện giải pháp công nghệ dự
định áp dụng hay không.
Khả thi kỹ thuật thường là l
ĩnh v
ực khó thâm nhập nhất tại giai đoạn phân tích.
Điều thực chất là tiến trình phân tích và xác
đ
ịnh nhu cầu cần được tiến hành song
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
7
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
song với việc xác nhận tính khả thi kỹ thuật. Các xem xét thường được gắn với tính
khả thi kỹ thuật bao gồm:
- Rủi ro xây dựng: liệu các phần tử hệ thống có thể được thiết kế sao cho đạt được
chức năng và hiệu suất cần thiết thỏa mãn những ràng buộc trong khi phân tích
không?
- Có sẵn tài nguyên: có sẵn các nhân viên cho việc xây dựng phần tử hệ thống đang
xét không? Các tài nguyên cần thiết khác (phần cứng và phần mềm) có sẵn cho
việc xây dựng hệ thống không ?
- Công nghệ: công nghệ liên quan đ

ãđ
ạt tới trạng thái sẵn sàng hỗ trợ cho hệ thống
chưa?
3. Khả thi về pháp lý: nghiên cứu và đưa ra phán quyết về có hay không sự xâm phạm, vi
phạm pháp luật hay khó khăn pháp lý từ việc xây dựng và vận hành hệ thống. Tính
khả thi pháp lý bao gồm một phạm vi rộng các mối quan tâm kể cả hợp đồng, ngh
ĩa
vụ pháp lý, sự vi phạm và vô số các bẫy pháp lý khác mà thường là các nhân viên kỹ
thuật không biết tới. Trong nước, vấn đề khả thi về pháp lý vẫn chưa được coi trọng
một cách đúng mức mặc dù đ
ã có m
ột số luật liên quan đến CNTT và bảo hộ bản
quyền.
4. Khả thi về hoạt động: đánh giá tính khả thi của việc vận hành hệ thống. Trong mỗi
phương án người ta cần xem xét hệ thống có thể vận hành trôi chảy hay không trong
khuôn khổ tổ chức và điều kiện quản lý mà tổ chức đó (người dùng, khách hàng) có.
Mức độ các phương án được xem xét tới trong nghiên cứu khả thi thường bị giới hạn
bởi các ràng buộc về chi phí và thời gian.
Trong quá trình nghiên cứu khả thi
Trong quá trình nghiên cứu khả thi, nhóm dự án phải tạo ra các tài liệu sau đây:
- Thõa thuận rõ ràng với những quyết định quan trọng của nhà sản xuất hoặc nhà
điều hành với khách hàng
- Tầm nhìn của dự án
- Chiến lược kinh doanh phần mềm
- Động lực ban đầu và mục tiêu đặt ra
- Động lực hiện tại và dự toán kế hoạch
- Danh sách các rủi ro và kế hoạch giải quyết từng rủi ro
- Chi tiết giao diện người dùng mẫu thử, nếu hệ thống yêu cầu một giao diện cụ thể
- Yêu cầu về kỹ thuật
- Kế hoạch đảm bảo chất lượng phần mềm

- Chi tiết kế hoạch phát triển phần mềm
Các tài liệu chỉ ra một hoặc một số mối nguy hiểm đối với dự án. Yêu cầu không rõ ràng,
thiếu nguồn tài trợ, lập kế hoạch không phù hợp là những nguyên nhân chính dẫn đến sự
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
8
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
thất bại của dự án được chỉ ra bởi khảo sát của Standish Group.
Nếu nhóm dự án không chuẩn bị đầy đủ các tài liệu này cho nghiên cứu khả thi, thì không
nên tổ chức cuộc họp đánh giá vì bạn không có đủ thông tin để xác định tính khả thi của dự
án.
Thời gian cần thiết để hoàn thành các tài liệu nghiên cứu khả thi phụ thuộc chủ yếu vào
bao nhiêu công việc là cần thiết để xác định các yêu cầu của phần mềm. Nếu người dùng biết
chính xác họ cần những gì ở phần mềm, giai đoạn này có thể chỉ tốn 10% tổng thời gian của
lịch trình phát triển phần mềm. Trong nhiều trường hợp điển hình khác, quá trình này có thể
mất từ 10-20%. Một số trường hợp khác, khách hàng thậm chí không biết cái học muốn là gì,
như vậy nhóm dự án phải giúp người dùng tìm ra những gì họ muốn, và như vậy thời gian bỏ
ra có thể lên đến 25% hoặc nhiều hơn.
Việc xem xét tính khả thi nên tập trung vào các câu hỏi sau:
- Khái niệm sản phẩm là khả thi ?
- Liệu có sản xuất được một sản phẩm như tầm nhìn ban đầu ?
- Ước tính chi phí hiện tại và chi phí mục tiêu để hoàn thành sản phẩm ?
- Chi phí ban đầu, chi phí mục tiêu đặt ra và chi phí hiện tại chênh lệch như thế nào?
- Chiến lược kinh doanh của phần mềm là hợp lí khi kinh phí hiện tại và dự toán kế

hoạch được xem xét ?
- Khi các nguy cơ chính đối với dự án được xác định và họ có thể khắc phục ?
- Yêu cầu đặc điểm kỹ thuật đầy đủ và ổn định, đủ để hỗ trợ công tác phát triển còn
lại ?
- Người sử dụng và các nhà phát triển có thể đồng ý về một mẫu thử nghiệm giao
diện người dùng chi tiết ? Nếu không, các yêu cầu có thực sự ổn định?
- Kế hoạch phát triển phần mềm hoàn chỉnh và đầy đủ để hỗ trợ công việc phát
triển hơn nữa?
Công việc này được thực hiện trong thời gian 10-20% đầu tiên của dự án nên đủ để trả
lời những câu hỏi này. Từ đó, khách hàng hoặc quản lý dự án có đầy đủ thông tin để quyết
định có tiếp tục phần còn lại của dự án.
Các lợi ích chính của nghiên cứu khả thi
Quyết định hủy dự án vào một giai đoạn nghiên cứu khả thi và một giai đoạn chính phát
triển giúp các công ty phần mềm ít nhất ba lợi ích.
Thứ nhất, một số người xem bất kỳ dự án bị hủy bỏ như một sự thất bại, nhưng một dự
án bị hủy bỏ tại thời điểm hoàn thành 10-20% nên được coi là một sự thành công. Hủy bỏ
một dự án sau khi nó hoàn thành 10-20% thay vì 80-90% (hoặc như Jones chỉ ra, 200%),
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
9
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
việc hủy bỏ sớm sẽ giúp công ty tiết kiệm rất nhiều chi phí và dành thời gian khảo sát các dự
án tiềm năng khác.
Thứ hai, nghiên cứu khả thi giúp cho người quản lý dự án đưa ra các yêu cầu tài trợ chính

xác hơn mức trung bình. Đầu tiên quản lý dự án yêu cầu tài trợ cho hoạt động nghiên cứu
khả thi, tức là 10-20% đầu tiên của dự án được hoàn thành. Sau khi các tài liệu nghiên cứu
khả thi được xem xét và những người tài trợ cho dự án đưa ra quyết định “go”, người quản
lý dự án yêu cầu kinh phí tài trợ cho các phần còn lại của sản phẩm. Tại thời điểm này, vẫn
có thể xảy ra những sự thay đổi về chi phí dự án, nhưng công việc thăm d
ò s
ẽ giảm khả năng
biến đổi này.
Cuối cùng, sự yêu cầu người quản lý dự án hoàn thành 10-20% của một dự án trước khi
yêu cầu tài trợ cho phần còn lại của dự án, điều này buộc nhóm dự án phải làm việc một cách
nghiêm túc và tập trung vào những công việc ban đầu đảm bảo sự thành công của dự án.
Những hoạt động này thường được làm qua loa hoặc bỏ qua, và những hậu quả tai hại sẽ trở
nên rõ ràng vào các giai
đo
ạn cuối của dự án. Nếu đội dự án được yêu cầu hoàn thành các
công việc ban đầu quan trọng trước khi tiếp tục dự án, thì rủi ro tổng thể có thể được giảm
một cách đáng kể.
BÀI TẬP 3
Đề bài:
Câu 3.1 Hãy đặc tả bởi điều kiện trước và sau các hàm:
a. Sắp xếp một danh sách các số nguyên.
b. Đảo ngược các phần tử của một danh sách
c.Đếm số phần tử có giá trị e trong một danh sách các số nguyên
Câu 3.2 Hãy đặc tả các kiểu trừu tượng:
a. Đặc tả kiểu trừu tượng cây nhị phân
b. Đặc tả kiểu trừu tượng tập hợp
Câu 3.3 Hãy sử dụng ngôn ngữ Z đặc tả một số hệ thống quản lý:
a. Quản lý thông tin đo
àn viên đơn gi
ản có một số tính năng như: thêm, xóa, chỉnh

sửa một đoàn viên, t
ìm ki
ếm (theo nhiều tiêu chí khác nhau)…
b. Quản lý th
ư vi
ện đơn giản gồm một số tính năng như quản lý thêm, sửa, xóa độc
giả; thêm, sửa, xóa sách; quản lý việc thuê mượn sách,.
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
10
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
Bài giải:
Câu 3.1 Hãy đặc tả bởi điều kiện trước và sau các hàm:
a.Sắp xếp một danh sách các số nguyên
Funtion_sort ( a : danh sách kiểu số nguyên
size : số phần tử của danh sách
)
Post_condition:
∀i,1<=i<=size,a[i] <= a[i+1].
b. Đảo ngược các phần tử của một danh sách
Funtion_ reverse ( a : danh sách kiểu K
size : số phần tử của danh sách a
result : b: danh sách kiểu K
)

Pre_condition:
∀i,1<=i<=size, a[i] K
Post_condition:
∀i,1<=i<=size,b[i]=a[size+1-i].
c. Đếm số phần tử có giá trị e trong một danh sách các số nguyên
Funtion_Count ( a : danh sách số nguyên
size : số phần tử của danh sách a
e : giá trị để so sánh
result: dem : là một số nguyên
)
Pre_condition:
dem = 0
Post_condition:
∀i,1<=i<=size,a[i]=e=>dem=dem+1
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
11
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
Câu 3.2 Hãy đặc tả các kiểu trừu tượng:
a.Đặc tả kiểu trừu tượng cây nhị phân
Sort BinTree(T)
Import : T, Boolean
Operation
init : →Bintree(T)

isEmpty : Bintree(T) →Boolean
create : T x BinTree(T) x BinTree(T) →BinTree(T)
root : BinTree(T) →T
left : BinTree(T) →BinTree(T)
right : BinTree(T) →BinTree(T)
isLeaf : BinTree(T) →Boolean
insertNode: BinTree(T) x T → BinTree(T)
searchNode: BinTree(T) x T → Boolean
deleteNode: BinTree(T) x T → BinTree(T)
deleteTree: BinTree(T) → BinTree(T)
Axioms
isEmpty (init) = true
isEmpty(deleteTree(L)) = false
isEmpty (create(O,L,R)) = false
root (create(O,L,R))) = O
left (create(O,L,R))) = L
right (create(O,L,R))) = R
isLeaf(O) = if ( isEmpty(left(O)) ∧ isEmpty(right(O)) ) true
else false
isEmpty(insertNode(init,O)) = false
searchNode(insertNode(L,O)) = true
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
12

BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
searchNode(deleteNode(L,O)) = false
With: O: T; L,R: BinTree(T)
b. Đặc tả kiểu trừu tượng tập hợp
Sort Set(T)
Import: T, Integer , Boolean
Operations
init : →Set(T)
isEmpty : Set(T) →Boolean
insert : Set(T) x T →Set(T)
delete : Set(T) x T →Set(T)
in : Set(T) x T →Boolean
union : Set(T) x Set(T) →Set(T)
intersection : Set(T) x Set(T) →Set(T)
count : Set(T) →Integer
Axioms
isEmpty (init) = true
count(init) = 0
isEmpty (insert(init,e)) = false
isEmpty (delete(insert(init,e),e)) = true
in(insert(S,e),e) = true
count (insert(S,e) ) = if in(S,e) count(S)
else count(S)+1
in(delete(S,e),e) = false
count(delete(S,e)) = if in(S,e) count(S)-1
else count(S)
in(union(S1,S2),e) = in(S1,e) ∨in(S2,e)
In(intersection(S1,S2),e) = in(S1,e) ∧in(S2,e)
With:
S,S1,S2: Set(T); e: T

SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
13
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
Câu 3.3
a.Quản lý thông tin đo
àn viên đơn gi
ản có một số tính năng như: thêm, xóa, chỉnh sửa một
đoàn viên, t
ìm ki
ếm (theo nhiều tiêu chí khác nhau)…
+ Sử dụng kiểu cơ bản
⟦UnionMember, AgeOfUnion⟧
+ Đặc tả trạng thái hệ thống (mỗi người đoàn viên chỉ có 1 tuổi đoàn duy nhất)
UnionBook
Ubook : UnionMember ⇸ AgeOfUnion
+ Khởi tạo hệ thống
InitUbook
UnionBook
Ubook = {}
+ Thêm 1 đoàn viên vào hệ thống
Add
ΔUnionBook
Name? : UnionMember

Age? : AgeOfUnion
Name?
∉ dom(
Ubook)
Ubook′ = Ubook ⋃ {Name?
↦
Age?}
- Trường hợp Add thành công
AddReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
14
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessAdd
Reply! : AddReply
Reply! = OK
- Trường hợp Add lỗi
BadAdd
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Reply! : AddReply
Name? ∈dom(Ubook)
Reply! = ERROR

- Khiđó:ResultAdd==(Add∧SuccessAdd)∨BadAdd
+ Xóa 1 đoàn viên ra khỏi hệ thống
Remove
Δ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Name? ∈dom(Ubook)
Ubook′ = Ubook ⧹ {Name?
↦
Age?}
- Trường hợp xóa thành công
RemoveReply == OK|ERROR
SuccessRemove
Reply! : RemoveReply
Reply! = OK
- Trường hợp xóa lỗi
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
15
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
BadRemove
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion

Reply! : RemoveReply
Name?
∉
dom(Ubook)
Reply! = ERROR
 khiđó:ResultRemove==(Remove∧SuccessRemove) ∨BadRemove
 Mở rộng: Xóa các đoàn viên ứng với 1 tập tên
RemoveNames
Δ UnionMember
Name? :ℙ UnionMember
Ubook′ = Name?
⩤
Ubook
+ Chỉnh sửa tuổi đoàn
Update
Δ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Name? ∈dom(Ubook)
Ubook′ = Ubook ⊕ {Name?
↦
Age?}
- Trường hợp chỉnh sửa thành công
UpdateReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY

ỄN TR
ƯỜNG LƯU
16
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessUpdate
Reply! : UpdateReply
Reply! = OK
- Trường hợp chỉnh sửa lỗi
BadUpdate
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Reply! : UpdateReply
Name?
∉
dom(Ubook)
Reply! = ERROR
 Khiđó:ResultUpdate==(Update∧SuccessUpdate)∨BadUpdate
+ Tìm kiếm
- Tìm tuổi đoàn của 1 người
LookupAge
Ξ UnionBook
Name? : UnionMember
Age! : AgeOfUnion
Name? ∈dom(Ubook)
Age! = Ubook(Name?)
. Trường hợp tìm thành công
LookupAgeReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR

ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
17
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessLookupAge
Reply! : LookupAgeReply
Reply! = OK
. Trường hợp tìm lỗi
BadLookupAge
Ξ UnionBook
Name? : UnionMember
Age? : AgeOfUnion
Reply! : LookupAgeReply
Name?
∉
dom(Ubook)
Reply! = ERROR
 Khi đó: ResultLookupAge == (LookupAge ∧SuccessLookupAge)∨BadLookupAge
- Tìm những đoàn viên có cùng tuổi đoàn
LookupNames
Ξ UnionBook
Age? : AgeOfUnion
Name! :
ℙ
UnionMember
Name! : {p : UnionMember | p ∈dom(Ubook) ∧Ubook(p) = Age?}

. Trường hợp tìm thành công
LookupNamesReply == OK|ERROR
SuccessLookupNames
Reply! : LookupNamesReply
Reply! : OK
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
18
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
. Trường hợp tìm lỗi
BadLookupNames
Ξ UnionBook
Age? : AgeOfUnion
Reply! :LookupNamesReply
Age?
∉
ran(Ubook)
Reply! = ERROR
b. Quản lý th
ư vi
ện đơn giản gồm một số tính năng như quản lý thêm, sửa, xóa độc giả;
thêm, sửa, xóa sách; quản lý việc thuê mượn sách.
 Quản lí độc giả
+ Sử dụng kiểu cơ bản

⟦ Readers, IdReaders ⟧
+ Đặc tả trạng thái hệ thống
ReadersList
RList : Readers ⇸ IdReaders
+ Khởi tạo hệ thống
InitList1
ReadersList
RList = {}
+ Thêm độc giả
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
19
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
AddReader
ΔReadersList
Name? : Readers
Id1? : IdReaders
Name?
∉
dom(RList)
RList′ = RList ⋃ {Name?
↦
Id1?}
+ Xóa độc giả

RemoveReader
ΔReadersList
Name? : Readers
Id1? : IdReaders
Name? ∈dom(RList)
RList′ = RList ⧹ {Name?
↦
Id1?}
+ Sửa mã
đ
ộc giả
UpdateReader
ΔReadersList
Name? : Readers
Id1? : IdReaders
Name? ∈dom(RList)
RList′ = RList ⊕ {Name?
↦
Id1? }
 Quản lí sách
+ Sử dụng kiểu cơ bản
⟦Books, IdBooks⟧
+ Đặc tả hệ thống trạng thái
BooksList
BList : Books ⇸ IdBooks
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU

– NGUY
ỄN TR
ƯỜNG LƯU
20
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
+Khởi tạo hệ thống
InitList2
BooksList
BList = {}
+ Thêm một cuốn sách
AddBook
ΔBooksList
Title? : Books
Id2? : IdBooks
Title?
∉
dom(BList)
BList′ = BList ⋃ {Title?
↦
Id2?}
+Xóa một cuốn sách
RemoveBook
ΔBooksList
Title? : Books
Id2? : IdBooks
Title? ∈dom(BList)
BList′ = BList ⧹ {Title?
↦
Id2?}
+ Sửa Id một quyển sách

UpdateBooks
ΔBookList
Title? : Books
Id2? : IdBooks
Title? ∈dom(BList)
BList′ = BList ⊕ {Title?
↦
Id2?}
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
21
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
 Quản lí việc thuê mượn sách
Count
Dem : N
0<= Dem <= 5
+ Khởi tạo biến
InitCount
Dem : N
Dem = 0
+ Sử dụng kiểu cơ bản
⟦IdReaders , IdBooks⟧ ⟦ IdReaders , Count ⟧
+ Mô tả trạng thái hệ thống
Library

Lib : IdReaders ↦ IdBooks
Number
Nb : IdReaders ⇸ Count
+ Khởi tạo hệ thống
InitLibrary
Library
Lib = {}
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
22
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
InitNumber
Number
Nb = {}
+ Mượn sách
- Mượn sách lần đầu
Borrow1
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? = 0
Dem?

′ =
Dem? + 1
Lib′ = Lib ⋃ {Id1?
↦
Id2?}
Nb′ = Nb ⋃ {Id1? ↦ Dem?}
- Mượn sách lần sau
Borrow2
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? < 5
Lib′ = Lib ⋃ {Id1?
↦
Id2?}
Dem?
′ =
Dem? + 1
Nb′ = Nb ⊕ {Id1?
↦
Dem?}
- Trường hợp mượn thành công
BorrowReply == OK|ERROR
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU

– NGUY
ỄN TR
ƯỜNG LƯU
23
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
SuccessBorrow
Repy! : BorrowReply
Reply! = OK
- Trường hợp mượn lỗi
BadBorrow
ΞLibrary
ΞNumber
Dem? : Count
Reply! : BorrowReply
Dem? = 5
Reply! = ERROR
 Khi đó :
ResultBorrow == ((Borrow1 ∨Borrow2)∧SuccessBorrow)∨BadBorrow
+ Trả sách
Pay1
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? > 1
Dem?
′ =
Dem? – 1
Lib′ = Lib ⧹ { Id1?

↦
Id2?}
Nb′ = Nb ⊕ {Id1?
↦
Dem?}
SVTH : TR
ẦN ĐỨC TR
ÌNH
– PHAN QU
ỐC HẬU
– NGUY
ỄN TR
ƯỜNG LƯU
24
BÁO CÁO THỰC HÀNH CÔNG NGHỆ PHẦN MỀM GV: LÊ THỊ MỸ HẠNH
Pay2
ΔLibrary
ΔNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Dem? = 1
Dem?
′ =
Dem? – 1
Lib′ = Lib ⧹ { Id1?
↦
Id2?}
Nb′ = Nb ⧹ {Id1?
↦

Dem?}
+ Trường hợp trả thành công
PayReply == OK| ERROR
SuccessPay
Reply! : PayReply
Reply! = OK
+ Trường hợp trả lỗi
BadPay
ΞLibrary
ΞNumber
Id1? : IdReaders
Id2? : IdBooks
Dem? : Count
Reply! : PayReply
Id1?
∉
dom(Lib)
⋃
Id2?
∉ ran(
Lib) ⋃ Dem? = 0
Reply! = ERROR
 Khi đó : ResultPay == ((Pay1 ∨Pay2)∧SuccessPay)∨BadPay