Giáo trình Nhập môn công nghệ phần mềm - Trường Đại học Hàng Hải
TRƢỜNG ĐẠI HỌC HÀNG HẢI VIỆT NAM
KHOA CÔNG NGHỆ THÔNG TIN
BỘ MÔN HỆ THỐNG THÔNG TIN
-----***-----
BÀI GIẢNG
NHẬP MÔN CÔNG NGHỆ PHẦN MỀM
TÊN HỌC PHẦN
MÃ HỌC PHẦN
: CÔNG NGHỆ PHẦN MỀM
: 17404
TRÌNH ĐỘ ĐÀO TẠO
: ĐẠI HỌC CHÍNH QUY
DÙNG CHO SV NGÀNH : CÔNG NGHỆ THÔNG TIN
HẢI PHÒNG - 2011
2
MỤC LỤC
Trang
Nội dung
Chƣơng 1: Giới thiệu
1.1. Khái niệm phần mềm
1.2. Các đặc điểm của phần mềm
1.3. Các ứng dụng của phần mềm
1.4. Giới thiệu về Công nghệ phần mềm (Software engineering)
Chƣơng 2: Các mô hình phát triển phần mềm
2.1. Mô hình thác nước (Waterfall model)
2.2. Mô hình nguyên mẫu (Prototyping model)
2.3. Mô hình phát triển nhanh (RAD model)
2.4. Mô hình tăng trưởng (Incremental model)
2.5. Mô hình xoắn ốc (Spiral model)
2.6. Các mô hình hiện đại (Fourth generation techniques)
Chƣơng 3: Khảo sát và phân tích yêu cầu
3.1. Thu thập yêu cầu (Requirements elicitation)
3.2. Phân tích yêu cầu (Requirements analysis)
3.3. Đặc tả yêu cầu (Requirements specification)
3.4. Xét duyệt yêu cầu (Requirements validation)
Chƣơng 4: Mô hình hóa hệ thống
4.1. Mô hình hóa dữ liệu (Data modeling)
4.2. Mô hình hóa chức năng (Functional modeling)
4.3. Mô hình hóa luồng thông tin (Information flow modeling)
Chƣơng 5: Thiết kế hệ thống
5.1. Quá trình thiết kế (Design process)
5.2. Các nguyên tắc thiết kế (Design principles)
Chƣơng 6: Kiểm thử phần mềm
6.1. Mục đích (Testing objectives)
6.2. Nguyên tắc kiểm thử (Testing principles)
6.3. Kiểm thử theo đường cơ bản (Basic path)
6.4. Kiểm thử theo phân vùng tương đương (Equivalence partitioning)
6.5. Kiểm thử theo giá trị biên (Boundary value analysis)
6.6. Các mức độ kiểm thử (Testing strategy)
3
Tên học phần: Nhập môn Công nghệ phần mềm
Bộ môn phụ trách giảng dạy: Hệ thống Thông tin
Mã học phần: 17404
Loại học phần: 1
Khoa phụ trách: CNTT.
Tổng số TC: 2
Tổng số tiết Lý thuyết
30 30
Thực hành/Xemina
Tự học
Bài tập lớn
Đồ án môn học
không
0
0
không
Học phần học trƣớc: Không yêu cầu.
Học phần tiên quyết: Không yêu cầu.
Học phần song song: Không yêu cầu.
Mục tiêu của học phần:
Cung cấp cho sinh viên những kiến thức cơ bản về công nghệ phần mềm.
Nội dung chủ yếu:
Giới thiệu về công nghệ phần mềm; Các mô hình phát triển phần mềm; Lượng giá dự án phần mềm;
Khảo sát và phân tích yêu cầu; Mô hình hóa hệ thống; Thiết kế hệ thống; Kiểm thử phần mềm.
Nội dung chi tiết:
TÊN CHƢƠNG MỤC
PHÂN PHỐI SỐ TIẾT
TS LT TH BT KT
Chƣơng 1: Giới thiệu
2
2
1.1. Khái niệm phần mềm
1.2. Các đặc điểm của phần mềm
1.3. Các ứng dụng của phần mềm
1.4. Giới thiệu về Công nghệ phần mềm (Software engineering)
Chƣơng 2: Các mô hình phát triển phần mềm
2.1. Mô hình thác nước (Waterfall model)
2.2. Mô hình nguyên mẫu (Prototyping model)
2.3. Mô hình phát triển nhanh (RAD model)
2.4. Mô hình tăng trưởng (Incremental model)
2.5. Mô hình xoắn ốc (Spiral model)
6
6
2.6. Các mô hình hiện đại (Fourth generation techniques)
Chƣơng 3: Khảo sát và phân tích yêu cầu
3.1. Thu thập yêu cầu (Requirements elicitation)
3.2. Phân tích yêu cầu (Requirements analysis)
3.3. Đặc tả yêu cầu (Requirements specification)
3.4. Xét duyệt yêu cầu (Requirements validation)
Chƣơng 4: Mô hình hóa hệ thống
4.1. Mô hình hóa dữ liệu (Data modeling)
4.2. Mô hình hóa chức năng (Functional modeling)
4.3. Mô hình hóa luồng thông tin (Information flow modeling)
Chƣơng 5: Thiết kế hệ thống
4
4
4
4
6
4
4
6
5.1. Quá trình thiết kế (Design process)
5.2. Các nguyên tắc thiết kế (Design principles)
5.3. Các khái niệm trong thiết kế phần mềm (Design concepts)
Chƣơng 6: Kiểm thử phần mềm
6.1. Mục đích (Testing objectives)
6.2. Nguyên tắc kiểm thử (Testing principles)
6.3. Kiểm thử theo đường cơ bản (Basic path)
6.4. Kiểm thử theo phân vùng tương đương (Equivalence
partitioning)
4
TÊN CHƢƠNG MỤC
PHÂN PHỐI SỐ TIẾT
TS LT TH BT KT
6.5. Kiểm thử theo giá trị biên (Boundary value analysis)
6.6. Các mức độ kiểm thử (Testing strategy)
Nhiệm vụ của sinh viên:
Tham dự các buổi học lý thuyết và thực hành, làm các bài tập được giao, làm các bài thi giữa kỳ và
bài thi kết thúc học phần theo đúng quy định.
Tài liệu học tập:
1. Roger S. Pressman, Software Engineering- A practitioner's Approach, 6th edition, McGraw-
Hill.
2. Sommerville, Software Engineering, 7th edition, Pearson education.
3. Nguyễn Xuân Huy, Giáo trình công nghệ phần mềm, NXB Trường ĐHBK Hà Nội, 1996.
Hình thức và tiêu chuẩn đánh giá sinh viên:
- Hình thức thi: tự luận hoặc trắc nghiệm.
- Tiêu chuẩn đánh giá sinh viên: căn cứ vào sự tham gia học tập của sinh viên trong các buổi
học lý thuyết và thực hành, kết quả làm các bài tập được giao, kết quả của các bài thi giữa học
phần và bài thi kết thúc học phần.
Thang điểm: Thang điểm chữ A, B, C, D, F.
Điểm đánh giá học phần: Z = 0,2X + 0,8Y.
Bài giảng này là tài liệu chính thức và thống nhất của Bộ môn Hệ thống Thông tin, Khoa Công
nghệ Thông tin và được dùng để giảng dạy cho sinh viên.
Ngày phê duyệt:
Trƣởng Bộ môn
/
/
5
Chương 1: Giới thiệu
1.1. Khái niệm phần mềm
“Phần mềm là một tập hợp bao gồm:
Các lệnh (chương trình máy tính) khi thực hịên thì đưa ra hoạt động và kết quả
mong muốn.
Các cấu trúc dữ liệu làm cho chương trình thao tác thông tin thích hợp.
Các tài liệu mô tả thao tác và cách dùng chương trình.”
1.2. Các đặc điểm của phần mềm
Phần mềm là phần tử của hệ thống logic chưa không phải hệ thống vật lý. Do vậy, phần mềm
có một số đặc trưng khác biệt đáng kể đối với đặc trưng của phần cứng.
Đặc trưng 1: Phần mềm được phát triển hay được kỹ nghệ hoá, nó không được chế tạo theo nghĩa
cổ điển.
Mặc dầu có một số điểm tương đồng giữa phát triển phần mềm và chế tạo phần cứng, hai hoạt
động này về cơ bản là khác nhau. Trong cả hai hoạt động này, chất lượng cao được đạt tới thông
qua thiết kế tốt, nhưng giai đoạn chế tạo phần cứng có thể đưa vào vấn đề mà chất lượng không tồn
tại (hay dễ được sửa đổi) cho phần mềm. Cả hai hoạt động này đều phụ thuộc vào con người, nhưng
mối quan hệ giữa người được áp dụng và công việc được thực hiện hoàn toàn khác. Cả hai hoạt
động này đòi hỏi việc xây dựng "sản phẩm", nhưng cách tiếp cận là hoàn toàn khác. Phần mềm
được chế tạo ra là hoàn toàn mới, không có tiền lệ trước và nó cũng chỉ được tạo ra 1 lần duy nhất.
Đặc trưng 2: Phần mềm không “hỏng đi”.
Phần mềm không cảm ứng với khiếm khuyết môi trường vốn gây cho phần cứng mòn cũ đi.
Phần mềm nếu cứ với các bộ dữ liệu đầu vào hợp lý thì nó luôn cho kết quả có ý nghĩa giống nhau,
không thay đổi theo thời gian, điều kiện khí hậu, …
Chết yểu
Tỷ lệ
hỏng
Tỷ lệ
hỏng
Giữ tỷ lệ cho đến khi
lạc hậu
M n cũ
Thời gian
Thời gian
Đường cong hỏng hóc của phần cứng
Đường cong hỏng hóc của phần mềm (lý tưởng)
6
Thực tế, phần mềm sẽ trải qua sự thay đổi (bảo trì). Khi thay đổi được thực hiện, có thể một số
khiếm khuyết sẽ được thêm vào, gây ra trong đường cong tỷ lệ hỏng có dấu hiệu như hình vẽ dưới
đây. Trước khi đường cong đó có thể trở về tỷ lệ hỏng hóc ổn định ban đầu, thì một yêu cầu khác lại
được đưa vào, lại gây ra đường cong phát sinh đỉnh nhọn một lần nữa. Dần dần, mức tỷ lệ hỏng tối
thiểu tăng lên - phần mềm bị thoái hoá do sự thay đổi.
Nhận xét: Phần cứng hỏng có “vật tư thay thế”, nhưng không có phần mềm thay thế cho phần
mềm. Mọi hỏng hóc của phần mềm đều chỉ ra lỗi trong thiết kế hay trong tiến trình chuyển thiết kế
thành mã hoá lệnh máy thực hiện được. Do đó, việc bảo trì phần mềm bao gồm việc phụ thêm đáng
kể so với bảo trì phần cứng.
Đặc trưng 3: Phần lớn phần mềm được xây dựng theo đơn đặt hàng, chứ ít khi được lắp ráp từ các
thành phần có sẵn.
Cách thiết kế và xây dựng phần cứng điều khiển cho một sản phẩm dựa trên bộ vi xử lý: vẽ sơ
Thay đổi
Tỷ lệ hỏng
Đường cong thực tế
Đường cong lý tưởng
Thời gian
H nh 1: Đường cong hỏng h c thực tế của phần mềm
đồ mạch số => thực hiện phân tích để đảm bảo chức năng đúng => phân loại các danh mục thành
phần => gắn cho mỗi mạch tích hợp (thường gọi là IC hay chip) một số hiệu một chức năng đã định
trước và hợp lệ; một giao diện đã xác định rõ; một tập các hướng dẫn tích hợp chuẩn hoá.
Đối với phần mềm: Khi xây dựng ta không có danh mục các thành phần. Phần mềm được đặt
hàng với đơn vị hoàn chỉnh, không phải là những thành phần có thể lắp ráp lại thành chương trình
mới.
1.3. Các ứng dụng của phần mềm
Sản phẩm phần mềm là gì?
Sản phẩm phần mềm là một hoặc một nhóm các chương trình được xây dựng để giải quyết
một vấn đề nào đó. Ví dụ: chương trình quản lý hoạt động của máy móc và các chương trình ứng
dụng.
Nhóm các sản phẩm hiện có.
Hiện nay người ta phân chia thành 7 nhóm phần mềm chính.
Nhóm 1: Phần mềm hệ thống.
7
Là một tập hợp các chương trình được viết để phục vụ cho các chương trình khác. Chương
trình này xử lý các thông tin phức tạp nhưng xác định cấp thấp, tạo môi trường hoạt động (trình
biên dịch, trình soạn thảo, quản lý tệp tin, …).
Các chương trình này đặc trưng bởi tương tác chủ yếu với phần cứng máy tính, phục vụ nhiều
người dùng, có cấu trúc dữ liệu phức tạp và nhiều giao diện ngoài.
Nhóm 2: Phần mềm thời gian thực.
Là phần mềm điều phối hoặc phân tích hay kiểm soát các sự kiện thế giới thực ngay khi
chúng xuất hiện.
Phần mềm thời gian thực bao gồm các yếu tố:
Một thành phần thu thập dữ liệu để thu và định dạng thông tin từ bên ngoài.
Một thành phần phân tích để biến đổi thông tin theo yêu cầu của ứng dụng.
Một thành phần kiểm soát hoặc đưa ra các đáp ứng cho môi trường ngoài.
Một thành phần điều phối để điều hoà các thành phần khác sao cho có thể duy trì việc đáp
ứng thời gian thực.
Hệ thống thời gian thực phải đáp ứng được những ràng buộc thời gian chặt chẽ.
Nhóm 3: Phần mềm nghiệp vụ.
Ngày nay, xử lý thông tin nghiệp vụ là lĩnh vự ứng dụng phần mềm lớn nhất. Phần mềm loại
này phục vụ cho các hệ thống rời rạc: hệ thông tin quản lý. Các ứng dụng phần mềm nghiệp vụ còn
bao gồm cả tính toán tương tác (như xử lý các giao tác cho các điểm bán hàng) ngoài ứng dụng xử
lý dữ liệu.
Nhóm 4: Phần mềm khoa học công nghệ.
Phần mềm này được đặc trưng bởi các thuật toán. Phần mềm tạo ra một ứng dụng mới, thiết
kế có máy tính trợ giúp (computer aided of design - CAD), có chú ý đến các đặc trưng thời gian
thực và phần mềm hệ thống.
Nhóm 5: Phần mềm nhúng.
Nằm trong bộ nhớ chỉ đọc và được dùng để điều khiển các sản phẩm và hệ thống cho người
dùng và thị trường công nghiệp. Có thể thực hiện các chức năng đơn giản nhưng mang tính chuyên
biệt (huyền bí), ví dụ: điều khiển chức năng cho lò vi sóng; hay có thể đưa ra các khả năng điều
khiển và vận hành (chức năng số hoá ở ô-tô, kiểm soát xăng, biểu thị bảng đồng hồ, các hệ thống
phanh…).
Nhóm 6: Phần mềm máy tính cá nhân.
Loại phần mềm này bùng nổ trong hơn thập kỷ vừa qua (như xử lý văn bản, trang tính, đồ
hoạ, quản trị cơ sở dữ liệu). Hiện nay được tiếp tục phát triển biểu thị giao diện người máy, tạo ra
sự thân thiện, dễ sử dụng cho người dùng.
Nhóm 7: Phần mềm trí tuệ nhân tạo.
8
Dùng các thuật toán phi số để giải quyết các vấn đề phức tạp mà tính toán hay phân tích trực
tiếp đều không thể quản lý nổi. Phần mềm này hoạt động mạnh ở hệ chuyên gia (hệ cơ sở tri thức);
trong lĩnh vực nhận dạng và xử lý hình ảnh và âm thanh; chứng minh các định lý và chơi trò chơi.
Hiện nay phát triển mạnh mạng nơ-ron nhân tạo: mô phỏng cấu trúc việc xử lý trong bộ não của con
người.
1.4. Giới thiệu về Công nghệ phần mềm (Software engineering)
Công nghệ phần mềm là một lĩnh vực nghiên cứu của tin học nhằm đưa ra các nguyên lý, phương
pháp, công cụ, phương tiện giúp cho việc thiết kế và cài đặt một sản phẩm phần mềm đạt được các
yêu cầu sau một cách tốt nhất:
Phải có tính đúng đắn và khoa học.
Dễ tiếp cận và cải tiến.
Phổ dụng.
Độc lập với các thiết bị.
Bài tập:
1. Trình bày vai trò của phần mềm
2. Trình bày các đặc điểm của phần mềm
3. Các ứng dụng của phần mềm
9
Chương 2: Các mô hình phát triển phần mềm
2.1. Mô hình thác nước (Waterfall model)
Đôi khi còn được gọi là mô hình tuần tự tuyến tính hay mô hình thác nước, mô hình này gợi ý
một cách tiếp cận tuần tự, có hệ thống tới việc phát triển phần mềm vốn bắt đầu từ mức hệ thống và
tiến dần qua phân tích, thiết kế, mã hoá, kiểm thử và hỗ trợ. Dưới đây minh hoạ mô hình thác nước
cho kĩ nghệ phần mềm. Được mô hình hoá theo chu kì kĩ nghệ qui ước, mô hình thác nước bao gồm
các hoạt động sau:
Kỹ nghệ hệ
thống
Phân tích và
định rõ yêu cầu
Thiết kế hệ
thống và phần
Mã hoá
Kiểm thử đơn vị
và tích hợp hệ
Vận hành và
bảo trì
Hình 2: Mô hình thác nƣớc
Kĩ nghệ và mô hình hoá hệ thống / thông tin. Bởi vì phần mềm bao giờ cũng là một phần
của một hệ thống (hay nghiệp vụ) lớn hơn nên công việc bắt đầu từ việc thiết lập yêu cầu cho mọi
phần tử hệ thống và rồi cấp phát một tập con các yêu cầu đó cho phần mềm. Quan điểm hệ thống
này là điều bản chất khi phần mềm phải tương tác với các thành phần khác như phần cứng, con
người và CSDL. Kĩ nghệ và phân tích hệ thống bao gồm việc thu thập yêu cầu ở mức hệ thống với
một lượng nhỏ thiết kế và phân tích mức đỉnh. Kĩ nghệ thông tin bao gồm việc thu thập yêu cầu tại
mức nghiệp vụ chiến lược và tại mức lĩnh vực nghiệp vụ.
Phân tích yêu cầu phần mềm. Tiến trình thu thập yêu cầu được tăng cường và hội tụ đặc biệt
vào phần mềm. Để hiểu được bản chất của các chương trình phải xây dựng, kĩ sư phần mềm ("nhà
phân tích") phải hiểu về lĩnh vực thông tin (được mô tả trong phần sau) đối với phần mềm cũng như
chức năng cần có, hành vi, hiệu năng và giao diện. Các yêu cầu cho cả hệ thống và phần mềm cần
phải được lập tư liệu và xét duyệt cùng với khách hàng.
10
Thiết kế. Thiết kế phần mềm thực tế là một tiến trình nhiều bước tập trung vào bốn thuộc tính
phân biệt của chương trình: cấu trúc dữ liệu, kiến trúc phần mềm, biểu diễn giao diện và chi tiết thủ
tục (thuật toán). Tiến trình thiết kế dịch các yêu cầu thành một biểu diễn của phần mềm có thể được
định giá về chất lượng trước khi giai đoạn mã hoá bắt đầu. Giống như các yêu cầu, việc thiết kế
phải được lập tư liệu và trở thành một phần của cấu hình phần mềm.
Sinh mã. Thiết kế phải được dịch thành dạng máy đọc được. Bước mã hoá thực hiện nhiệm vụ
này. Nếu thiết kế được thực hiện theo một cách chi tiết thì việc sinh mã có thể được thực hiện một
cách máy móc.
Kiểm thử. Một khi mã đã được sinh ra thì việc kiểm thử chương trình bắt đầu. Tiến trình kiểm
thử hội tụ vào nội bộ logic của phần mềm, đảm bảo rằng tất cả các câu lệnh đều được kiểm thử, và
vào bên ngoài chức năng; tức là tiến hành các kiểm thử để làm lộ ra các lỗi và đảm bảo những cái
vào đã định sẽ tạo ra kết quả thống nhất với kết quả muốn có.
Vận hành và bảo trì. Phần mềm chắc chắn sẽ phải trải qua những thay đổi sau khi nó được bàn
giao cho khách hàng (một ngoại lệ có thể là những phần mềm nhúng). Thay đổi sẽ xuất hiện bởi vì
gặp phải lỗi, bởi vì phần mềm phải thích ứng với những thay đổi trong môi trường bên ngoài (chẳng
hạn như sự thay đổi do hệ điều hành mới hay thiết bị ngoại vi mới), hay bởi vì khách hàng yêu cầu
nâng cao chức năng hay hiệu năng. Việc bảo trì phần mềm phải áp dụng lại các bước vòng đời nói
trên cho chương trình hiện tại chứ không phải chương trình mới.
Mô hình tuần tự tuyến tính là mô hình cũ nhất và được sử dụng rộng rãi nhất cho kĩ nghệ phần
mềm. Tuy nhiên, những chỉ trích về mô hình này đã làm cho những người ủng hộ nó tích cực phải
đặt vấn đề về tính hiệu quả của nó. Một số các vấn đề thỉnh thoảng gặp phải khi dùng mô hình tuần
tự tuyến tính này là:
Các dự án thực hiếm khi tuân theo dòng chảy tuần tự mà mô hình đề nghị. Mặc dầu mô
hình tuyến tính có thể cho phép lặp, nhưng điều đó chỉ làm gián tiếp. Kết quả là những thay đổi có
thể gây ra lẫn lộn khi tổ dự án tiến hành.
Khách hàng thường khó phát biểu mọi yêu cầu một cách tường minh. Mô hình tuần tự
tuyến tính đòi hỏi điều này và thường khó thích hợp với sự bất trắc tự nhiên tồn tại vào lúc đầu của
nhiều dự án.
Khách hàng phải kiên nhẫn. Bản làm việc được của chương trình chỉ có được vào lúc cuối
của thời gian dự án. Một sai lầm ngớ ngẩn, nếu đến khi có chương trình làm việc mới phát hiện ra,
có thể sẽ là một thảm hoạ.
Trong một phân tích thú vị về các dự án hiện tại, Brada thấy rằng bản chất tuyến tính của vòng
đời cổ điển dẫn tới "các trạng thái nghẽn" mà trong đó một số thành viên tổ dự án phải đợi cho các
thành viên khác của tổ hoàn thành các nhiệm vụ phụ thuộc. Trong thực tế, thời gian mất cho việc
chờ đợi có thể vượt quá thời gian dành cho công việc sản xuất. Trạng thái nghẽn có khuynh hướng
phổ biến vào lúc đầu và cuối của tiến trình tuần tự tuyến tính.
11
Từng vấn đề trên đều là thực. Tuy nhiên, mô hình vòng đời cổ điển có một vị trí quan trọng và
xác định trong công việc về kĩ nghệ phần mềm. Nó đưa ra một tiêu bản trong đó có thể bố trí các
phương pháp cho phân tích, thiết kế, mã hoá, kiểm thử và bảo trì. Bên cạnh đó, vòng đời cổ điển
vẫn còn là một mô hình thủ tục được dùng rộng rãi cho kĩ nghệ phần mềm. Trong khi nó quả thực
còn điểm yếu, nó vẫn tốt hơn đáng kể nếu so với cách tiếp cận ngẫu nhiên tới việc phát triển phần
mềm.
2.2. Mô hình nguyên mẫu (Prototyping model)
Thông thường khách hàng đã xác định một tập các mục tiêu tổng quát cho phần mềm, nhưng
còn chưa định danh các yêu cầu cái vào chi tiết, hay xử lí cái ra. Trong các trường hợp khác, người
phát triển có thể không chắc về tính hiệu quả của thuật toán, việc thích nghi hệ điều hành hay dạng
giao diện người máy cần có. Trong những trường hợp này và nhiều trường hợp khác mô hình làm
bản mẫu có thể đưa ra cách tiếp cận tốt nhất.
Tập hợp yêu cầu và
làm mịn => xác định
mục tiêu tổng thể,
khảo sát thêm để
định rõ yêu cầu
Sản phẩm
Thiết kế nhanh
Làm mịn
bản mẫu
Xây dựng bản
Đánh giá của
khách hàng về
bản mẫu
Mô hình làm bản mẫu (hình dưới) bắt đầu với việc thu thập yêu cầu. Người phát triển và
khách hàng gặp nhau và xác định các mục tiêu tổng thể cho phần mềm, xác định các yêu cầu nào đã
biết, và miền nào bắt buộc phải xác định thêm. Rồi đến việc "thiết kế nhanh". Thiết kế nhanh tập
trung vào việc biểu diễn các khía cạnh của phần mềm thấy được đối với người dùng (như cách đưa
vào và định dạng đưa ra). Thiết kế nhanh dẫn tới việc xây dựng một bản mẫu. Bản mẫu được khách
hàng / người dùng đánh giá và được dùng để làm mịn các yêu cầu đối với phần mềm cần phát triển.
Tiến trình lặp đi lặp lại xảy ra để cho bản mẫu được "vi chỉnh" thoả mãn nhu cầu của khách hàng
trong khi đồng thời lại làm cho người phát triển hiểu được kĩ hơn cần phải thực hiện nhu cầu nào.
Một cách lí tưởng, bản mẫu phục vụ như một cơ chế để xác định các yêu cầu phần mềm. Nếu
một bản mẫu làm việc được xây dựng thì người phát triển có thể dùng được các đoạn chương trình
12
đã có hay áp dụng các công cụ (như bộ sinh báo cáo, bộ quản lí cửa sổ, v.v..) để nhanh chóng sinh
ra chương trình làm việc.
Nhưng chúng ta nghĩ về bản mẫu thế nào khi nó được dùng cho mục đích được nêu trên? Brook
đã nêu ra câu trả lời:
Trong hầu hết các dự án, hệ thống đầu tiên hiếm khi sử dụng được. Nó có thể là quá chậm, quá
lớn, cồng kềnh trong sử dụng hay tất cả những nhược điểm này. Không có cách nào khác là bắt đầu
lại, đau đớn nhưng tinh khôn hơn, và xây dựng một phiên bản được thiết kế lại trong đó những vấn
đề này đã được giải quyết... Khi một khái niệm hệ thống mới hay một kĩ nghệ mới được dùng,
người ta phải xây dựng một hệ thống để rồi vứt đi, cho dù việc lập kế hoạch được thực hiện chu đáo
nhất thì nó cũng không thể bao quát hết để chạy đúng được ngay lần đầu. Do đó câu hỏi quản lí
không phải là liệu chúng ta có nên xây dựng một hệ thống thử nghiệm và rồi vứt nó đi hay không.
Bạn sẽ làm như vậy. Câu hỏi duy nhất là liệu nên lập kế hoạch trước để xây dựng một cái vứt đi hay
để hứa hẹn bàn giao cái vứt đi đó cho khách hàng...
Bản mẫu có thể phục vụ như "hệ đầu tiên" - cái mà Brook lưu ý chúng ta nên vứt đi. Nhưng
điều này có thể là một cách nhìn lí tưởng hoá. Giống như mô hình tuyến tính tuần tự (thác nước),
việc làm bản mẫu tựa như một mô hình cho kĩ nghệ phần mềm có thể trở thành có vấn đề bởi những
lí do sau:
1. Khách hàng thấy được cái dường như là phiên bản làm việc của phần mềm mà không biết rằng
bản mẫu được gắn lại "bằng kẹo cao su và dây gói hàng", không biết rằng trong khi xô đẩy để
cho nó làm việc thì chẳng ai xem xét tới chất lượng phần mềm tổng thể hay tính bảo trì thời gian
dài. Khi được thông báo rằng sản phẩm phải được xây dựng lại để cho có thể đạt tới mức độ
chất lượng cao, thì khách hàng kêu trời và đòi hỏi rằng "phải ít sửa chữa" để làm bản mẫu thành
sản phẩm làm việc. Rất thường là việc quản lí phát triển phần mềm bị buông lỏng.
2. Người phát triển thường hay thoả hiệp cài đặt để có được bản mẫu làm việc nhanh chóng. Hệ
điều hành hay ngôn ngữ lập trình không thích hợp có thể được dùng đơn giản bởi vì nó có sẵn
và đã biết; một thuật toán không hiệu quả có thể được cài đặt đơn giản để chứng tỏ khả năng.
Sau một thời gian, người phát triển mới có thể trở nên quen thuộc với những chọn lựa này và
quên mất mọi lí do tại sao chúng lại không thích hợp. Việc chọn lựa không được theo lí tưởng
bây giờ lại trở thành một phần tích hợp của hệ thống.
Mặc dầu vấn đề có thể xuất hiện, việc làm bản mẫu có thể là một mô hình hiệu quả cho kĩ nghệ
phần mềm. Chìa khoá là định nghĩa ra các qui tắc của trò chơi từ ngay lúc bắt đầu; tức là khách
hàng và người phát triển phải cùng đồng ý rằng bản mẫu được xây dựng để phục vụ làm cơ chế xác
định yêu cầu. Thế rồi nó phải bị bỏ đi (ít nhất cũng một phần) và phần mềm thực tại được đưa vào
kĩ nghệ với con mắt hướng về chất lượng và tính bảo trì được.
13
2.3. Mô hình phát triển nhanh (RAD model)
Mô hình phát triển nhanh (RAD – Rapid Application Development) chính là mô hình tăng
dần với chu kỳ phát triển cực ngắn. Để đạtđược mục tiêu này, RAD dựa trên phương pháp phát
triển trên cơ sở thành phần hoá hệ thống cùng với việc tái sử dụng các thành phần thích hợp. RAD
thích hợp cho những hệ thống quản lý thông tin.
RAD - dựa vào phương pháp luận,điều chỉnh các giai đoạn SDLC đểtạo ra một sốphần của hệthống
phát triển nhanh và vào các thao tác thủ công của người sử dụng.
Phần lớn RAD - dựa vào phương pháp luận mà người phân tích sử dụng các kỹ thuậtđặc biệt và
công cụ máy tínhđể tăng tốc các giaiđoạn phân tích, thiết kế, và thực hiện, như công cụ CASE
(computer-aided software engineering).
2.4. Mô hình tăng trưởng (Incremental model)
Thay vì chuyển giao một lần, quá trình phát triển và chuyển giao được chia làm nhiều lần, mỗi
chuyển giao đáp ứng một phần chức năng.
Yêu cầu người dùng được phân loại ưu tiên, mức cao sẽ thuộc phần chuyển giao sớm
Khi phát triển một bản tăng, yêu cầu tương ứng là cố định, tuy nhiên, yêu cầu cho bản tăng
sau vẫn phát triển.
2.5. Mô hình xoắn ốc (Spiral model)
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. Hình sau mô tả cho mô hình xoắn ốc có chứa 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ĩ thuậ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)
14
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 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 sự á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) - được nêu trong phần sau - 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.
Đánh giá của khách hàng
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,
15
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 đ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.
2.6. Các mô hình hiện đại (Fourth generation techniques)
Thuật ngữ kĩ thuật thế hệ thứ tư (4GT) bao gồm một phạm vi rộng các công cụ phần mềm có
một điểm chung: mỗi công cụ đều cho phép người kĩ sư phần mềm xác định đặc trưng nào đó của
phần mềm ở mức cao. Rồi công cụ đó tự động sinh ra mã chương trình gốc dựa trên đặc tả của
người phát triển. Người ta gần như không còn bàn cãi về việc phần mềm có thể được xác định đối
với một máy càng ở mức cao thì chương trình có thể được xây dựng càng nhanh hơn. Mô hình 4GT
cho kĩ nghệ phần mềm tập trung vào khả năng xác định phần mềm bằng việc dùng các khuôn mẫu
ngôn ngữ đặc biệt hay kí pháp đồ hoạ vốn mô tả cho vấn đề cần được giải quyết dưới dạng khách
hàng có thể hiểu được.
16
Tìm hiểu yêu cầu
Phân tích
Công cụ tự động
hoặc hỗ trợ
Thiết kế
C i đặt
Kiểm thử
Sản phẩm
Hình 3: Mô hình kỹ nghệ thứ 4 - 4GT
Hiện tại, một môi trường phát triển phần mềm hỗ trợ cho mô hình 4GT bao gồm một số hay tất
cả các công cụ sau:
Ngôn ngữ phi thủ tục để hỏi đáp cơ sở dữ liệu.
Bộ sinh báo cáo.
Bộ thao tác dữ liệu.
Bộ tương tác và xác định màn hình.
Bộ sinh chương trình.
Khả năng đồ hoạ mức cao.
Khả năng làm trang tính và việc sinh tự động HTML.
Các ngôn ngữ tương tự được dùng cho việc tạo ra trang Web thông qua việc dùng các
công cụ phần mềm tiên tiến.
Ban đầu nhiều trong những công cụ đã được nhắc tới đó đã có sẵn chỉ cho những lĩnh vực ứng
dụng rất đặc thù, nhưng ngày nay môi trường 4GT đã được mở rộng để đề cập tới hầy hết các loại
ứng dụng phần mềm.
Giống như các mô hình khác, 4GT bắt đầu từ bước thu thập yêu cầu. Một cách lý tưởng, khách
hàng sẽ mô tả các yêu cầu và các yêu cầu đó sẽ được dịch trực tiếp thành một bản mẫu vận hành
được. Nhưng điều này không thực hiện được. Khách hàng có thể không chắc chắn mình cần gì, có
thể có sự mơ hồ trong việc xác định các sự kiện đã biết, có thể không có khả năng hay không sẵn
lòng xác định thông tin theo cách thức mà công cụ 4GT có thể giải quyết được. Bởi lí do này, đối
thoại khách hàng/ người phát triển được mô tả cho các mô hình tiến trình khác vẫn còn là phần bản
chất của cách tiếp cận 4GT.
Với những ứng dụng nhỏ, có thể chuyển trực tiếp từ bước thu thập yêu cầu sang cài đặt bằng
cách dùng ngôn ngữ sinh thế hệ thứ tư phi thủ tục (4GL) hay một mô hình bao gồm một mạng các
biểu tượng đồ hoạ. Tuy nhiên với nỗ lực lớn hơn, cần phải phát triển một chiến lược thiết kế cho hệ
17
thống, ngay cả nếu có dùng 4GL. Việc dùng 4GT thiếu thiết kế (với các dự án lớn) sẽ gây ra cùng
những khó khăn (chất lượng kém, khó bảo trì, người dùng khó chấp nhận) mà chúng ta đã gặp phải
khi phát triển phần mềm bằng cách dùng các cách tiếp cận qui ước.
Việc cài đặt dùng 4GL làm cho người phát triển phần mềm biểu diễn được các kết quả mong
muốn theo cách là phát sinh tự động chương trình tính ra chúng. Hiển nhiên, một cấu trúc dữ liệu
với những thông tin có liên quan cần phải có sẵn và sẵn sàng cho 4GL truy nhập vào.
Để biến đổi một cài đặt 4GT thành một sản phẩm, người phát triển phải tiến hành việc kiểm thử
toàn diện, xây dựng các tài liệu có ý nghĩa và thực hiện mọi hoạt động tích hợp giải pháp khác vốn
cần tới trong các mô hình kĩ nghệ phần mềm khác. Bên cạnh đó, phần mềm được phát triển theo
4GT phải được xây dựng theo cách làm cho việc bảo trì có thể được tiến hành một cách chóng
vánh.
Giống như mọi mô hình kĩ nghệ phần mềm, mô hình 4GT có ưu điểm và nhược điểm. Những
người ủng hộ cho là làm giảm đáng kể thời gian phát triển phần mềm và làm tăng rất nhiều hiệu
suất của người xây dựng phần mềm. Những người phản đối cho là các công cụ 4GT hiện tại không
phải tất cả đều dễ dùng hơn các ngôn ngữ lập trình, rằng chương trình gốc do các công cụ này tạo ra
là "không hiệu quả," và rằng tính bảo trì cho các hệ thống phần mềm lớn được phát triển bằng cách
dùng 4GT vẫn còn là vấn đề mở.
Có đôi điều lợi ích trong các luận điểm của cả hai phía và có thể tóm tắt trạng thái hiện tại của
cách tiếp cận 4GT như sau:
1. Việc dùng 4GT là cách tiếp cận có thể tồn tại được cho nhiều lĩnh vực ứng dụng khác nhau.
Gắn với các công cụ kĩ nghệ phần mềm có máy tính hỗ trợ và bộ sinh mã, 4GT cung cấp
một giải pháp tin cậy được cho nhiều vấn đề phần mềm.
2. Dữ liệu được thu thập từ các công ty có dùng 4GT chỉ ra rằng thời gian cần cho việc tạo ra
phần mềm được giảm đáng kể đối với các ứng dụng vừa và nhỏ và rằng khối lượng thiết kế
và phân tích cho các ứng dụng nhỏ cũng được rút bớt.
3. Tuy nhiên, việc dùng 4GT cho các nỗ lực phát triển phần mềm lớn đòi hỏi nhiều phân tích,
thiết kế và kiểm thử (các hoạt động kĩ nghệ phần mềm) để đạt tới việc tiết kiệm thời gian
vốn nảy sinh từ việc xoá bỏ mã hoá.
Tóm lại, các kĩ thuật thế hệ thứ tư đã trở thành một phần quan trọng của kĩ nghệ phần mềm. Khi đi
đôi với cách tiếp cận dựa trên cấu phần (sẽ được trình bày ở mục tiếp theo), mô hình 4GT có thể trở
thành cách tiếp cận thống trị cho việc phát triển phần mềm\
Bài tập:
1. Trình bày mô hình thác nước
2. Phân biệt mô hình bản mẫu với mô hình thác nước
3. Phân biệt mô hình tăng trưởng với mô hình thác nước
18
Chương 3: Khảo sát và phân tích yêu cầu
3.1. Thu thập yêu cầu (Requirements elicitation)
Mỗi giai đoạn phát triển hệ thống đồi hỏi sự trao đổi giữa nhà phát triển và người dùng để
nhận được thông tin có ích. Mỗi giai đoạn cần tìm kiếm một dải rộng các câu hỏi về ứng dụng. Ví
dụ: Khi phân tích tính khả thi, các câu hỏi tương đối rộng và tổng quát:
Đâu là phạm vi của vấn đề?
Cách tốt nhất để tự động hoá là gì?
Công ty có cố gắng để phát triển ứng dụng này hay không?
Công ty có thể hỗ trợ việc phát triển ứng dụng không?
Khi phân tích yêu cầu chúng ta tìm hiểu các thông tin có liên quan đến ứng dụng là gì. Ví dụ:
Các dữ liệu cần thiết là gì?
Các xử lý nào được tiến hành và các thông tin chi tiết liên quan?
Khi thiết kế chúng ta phát triển thêm: Làm thế nào thông tin có liên quan tới ứng dụng:
Làm thế nào chuyển ứng dụng vào môi trường đã chọn?
Làm thế nào thiết kế dữ liệu logic được chuyển vào thiết kế dữ liệu vật lý?
Các module chương trình được phối hợp với nhau như thế nào?
Các thông tin đó không xuất phát từ đâu khác ngoài chính từ yêu cầu của người dùng. Nhiệm
vụ của nhà phát triển là phải nắm bắt được các thông tin trên. Có nhiều cách để thu thập dữ liệu:
Phỏng vấn - họp nhóm - quan sát - giới thiệu trước chương trình sau đó xin ý kiến - ấn định công
việc tạm thời - làm việc chung - xem xét tài liệu nội bộ, tài liệu ngoài… Mỗi phương pháp có ưu,
nhược điểm riêng (chúng ta sẽ thảo luận sau). Nhà phát triển phần mềm phải biết vận dụng linh hoạt
các phương pháp trên để thu được thông tin một cách hiệu quả nhất.
Các tính chất của dữ liệu.
Các dữ liệu được phân biệt theo một vài khía cạnh:
Định hướng thời gian.
Cấu trúc.
Nhập nhằng.
Ngữ nghĩa.
Độ lớn.
Mỗi yếu tố trên đều quan trọng trong việc xác định các đặc tả của ứng dụng bởi vì chúng
hướng dẫn cho công nghệ phần mềm biết số lượng và kiểu thông tin nên được chọn. Cũng vậy, các
kiểu dữ liệu khác nhau có liên quan tới các loại ứng dụng khác nhau và đòi hỏi các kỹ thuật khai
thác thông tin khác nhau. Không chú ý tới các đặc tính của dữ liệu sẽ dẫn tới lỗi phân tích thiết kế.
19
Bên cạnh việc thu thập thông tin, chúng ta cũng cần sử dụng các kỹ thuật định lượng thông tin
và biên dịch và ứng dụng đề ra.
Tính chất 1: Hướng thời gian.
Tính hướng thời gian của dữ liệu đề cập tới quá khứ, hiện tại hoặc các đòi hỏi tương lai của
ứng dụng đề ra.
Các dữ liệu quá khứ, ví dụ, có thể mô tả công việc đã được biến đôit thế nào qua thời gian,
các quy định ảnh hưởng thế nào tới nhiệm vụ, vị trí của nó trong tổ chức và nhiệm vụ. Các thông tin
quá khứ là chính xác, đầy đủ và xác đáng.
Các thông tin hiện tại là các thông tin và cái gì đang xảy ra. Ví dụ thông tin ứng dụng hiện tại
liên quan tới quá trình hoạt động của công ty, số lượng các lệnh được thực hiện trong ngày hoặc số
lượng các hang hoá được sản xuất, các chính sách, sản phẩm, đòi hỏi nghiệp vụ, yêu cầu pháp quy
hiện tại hoặc các rang buộc khác cũng rất cần thiết cho việc phát triển ứng dụng. Các thông tin hiện
tại nên được chuyển thành các tư liệu cho phù hợp với đội ngũ phát triển để tăng sự hiểu biết của họ
về ứng dụng và phạm vi của bài toán
Các đòi hỏi trong tương lai liên quan đến các sự thay đổi sẽ diễn ra, chúng không chính xác
và rất khó kiểm tra. Các dự đoán kinh tế, khuynh hướng tiếp thị, kinh doanh là các ví dụ.
Tính chất 2: Tính có cấu trúc.
Thông tin chúng ta thu thập được là những thông tin được tổ chức theo một cấu trúc (khuôn
mẫu) nhất định; có như vậy mới thể hiện một ý nghĩa phản ánh một đối tượng nào đó, điều này là
hiển nhiên. Tuy nhiên, trong quá trình thu thập dữ liệu, chúng ta có khi không hiểu được cấu trúc
của thông tin phản ánh, mà rất có thể hiểu theo hướng khác (điều này đã được đề cập ở phần các lỗi
có thể mắc phải trong quá trình phát triển hệ thống - Chương 2).
Cấu trúc của thông tin định hướng về phần mở rộng theo đó thông tin có thể được phân loại
theo một cách nào đó. Cấu trúc có thể tham chiếu tới các hàm, môi trường hoặc dạng dữ liệu hạy
hình thức xử lý. Các thông tin thay đổi từ phi cấu trúc cho tới cấu trúc mà phần cấu trúc được xác
định bởi công nghệ phần mềm (SE).
Một ví dụ thực tế khi phân tích chức năng của nghiệp vụ. Các chức năng của nghiệp vụ nếu
theo người quản lý hệ thống thì không thể kể ra hết vì đó là các công việc của từng bộ phận, của
từng nhân viên. Do vậy ta chỉ nắm được những cái tổng quan (có tính trừu tượng cao - không rõ
ràng, cụ thể). Còn các chức năng nghiệp vụ của từng bộ phận, từng nhân viên thì rất nhỏ lẻ. Và
đứng giữa một danh sách các chức năng như vậy thì khó có thể thấy được tính cấu trúc của nó. Các
nhà phân tích lại phải "ngồi lại" với nhau và tổ chức lại các chức năng nghiệp vụ đó. Có như vậy thì
khi xây dựng chương trình, ta tránh phải làm đi làm lại các chức năng giống nhau giữa các bộ phận
trong thực tế. Mà ta chỉ cần nêu ra một liên kết (link) từ bộ phận (module) này đến bộ phận khác.
Tính "không chuẩn" của dữ liệu thể hiện rõ nhất ở thông tin trong một tờ "hoá đơn". Hoá đơn
thanh toán thể hiện rất nhiều thông tin, như: Số HD, Tên HĐ, Tên khách hàng, Địa chỉ khách hàng,
20
… và sau đó là một bảng liệt kê chi tiết tên các mặt hàng, đơn giá, số lượng, thành tiền ... nhưng
trong thực tế, không một bảng dữ liệu có khuôn dạng giống như một hoá đơn nào có mặt trong kho
dữ liệu của hệ thống. Điều này là do liên kết dữ liệu từ các bảng khác mà thành, tránh lưu trữ trùng
lặp quá nhiêu thông tin. Do vậy, các nhà thiết kế dữ liệu đã tổ chức lại cấu trúc của dữ liệu cần lưu
trữ.
Tính chất 3: Đầy đủ.
Hơn lúc nào hết, khi tìm hiểu về một đối tượng hay lĩnh vực nào đó, ta luôn cần thông tin
phản ánh về nó một cách đầy đủ và chính xác nhất có thể có. Về mặt lý thuyết thì không bao giờ ta
có được toàn bộ thông tin về đối tượng hay lĩnh vực mà ta xử lý. Trong thực tế cũng như vậy, thông
tin mà ta có chỉ là tạm đủ để ta có thể xử lý mà thôi.
Các thông tin có thể xếp theo cấp độ tính đầy đủ mà cao nhất là mọi thông tin cần thiết sẽ
được biểu diễn. Mỗi kiểu ứng dụng đòi hỏi một mức độ đầy đủ khác nhau. Các hệ thống xử lý giao
dịch luôn tiếp cận các thông tin đầy đủ và chính xác (ví dụ hệ thống bán vé máy bay). Tuy nhiên
các hệ thống xây dựng theo kiến trúc hệ chuyên gia hay trí tuệ nhân tạo (AI) là minh hoạ tốt nhất
việc xử lý thông tin không đầy đủ.
Tính chất 4: Nhập nhằng.
Tính nhập nhằng là một thuộc tính của dữ liệu không trong sáng về nghĩa hoặc có nhiều nghĩa
một cách hữu ý (có chủ định). Tính chất này liên quan đến mức độ ngữ nghĩa. Ví dụ, nhìn thấy một
cửa hiệu có thể đề biển “Giặt là hấp”, thì một cậu bé có thể hỏi bố một câu hỏi như sau: “Tại sao
giặt lại là hấp?”, vào hoàn cảnh này, ông bố sẽ phải mất rất nhiều công sức để giải thích cho con
hiểu. Như vậy có hiện tượng “ông nói gà, bà hoá cuốc”. Để giải quyết vấn đề này cần căn cứ vào
ngữ cảnh.
Tính chất 5: Ngữ nghĩa.
Mọi người trong một tổ chức đều có một tập hợp các định nghĩa được chia sẻ cho biết các
thuật ngữ, chính sách hoặc các hành động được biểu hiện như thế nào.
Ngữ nghĩa rất quan trọng với việc phát triển ứng dụng và với chính bản thân ứng dụng đó.
Nếu mọi người dùng chung một thuật ngữ mà có cách hiểu khác nhau thì sẽ dẫn đến không thể trao
đổi thông tin được. Đối với ứng dụng thì dữ liệu sẽ không bao giờ xử lý được cho đến khi người sử
dụng hiểu được ngữ nghĩa của dữ liệu này. Các ứng dụng sẽ có ý nghĩa xác định với mục dữ liệu
được định tính thông qua việc đào tạo và sử dụng lâu dài. Khi các cán bộ chủ chốt chuyển công tác,
thì khả năng chuyển hoá ngữ nghĩa dễ mất. Việc đánh mất ngữ nghĩa của một công ty có thể gây tổn
thất rất lớn cho công ty đó.
Tính chất 6: Độ lớn (volume).
Volume là số lượng các sự kiện nghiệp vụ hệ thống phải tiến hành trong một chu kỳ nào đó.
Volume của tạo mới hay thay đổi khách hàng được tiến hành theo tháng hoặc năm, trong đó volume
của giao dịch được tiến hành theo ngày giờ hoặc là theo peak volume (peak volume là số các giao
Tải về để xem bản đầy đủ
65 trang
04/05/2022
5900
Bạn đang xem 20 trang mẫu của tài liệu "Giáo trình Nhập môn công nghệ phần mềm - Trường Đại học Hàng Hải", để tải tài liệu gốc về máy hãy click vào nút Download ở trên
File đính kèm:
- giao_trinh_nhap_mon_cong_nghe_phan_mem_truong_dai_hoc_hang_h.pdf
