Đặc tả và chất lượng phần mềm môn Đảm bảo chất lượng phần mềm | Học viện Công Nghệ Bưu Chính Viễn Thông

lOMoAR cPSD| 58457166
CHƯƠNG 1: ĐẶC TẢ PHẦN MỀM I)
Đặc điểm của phần mềm •
Phần mềm là chương trình (mã máy + dữ liệu) được cài đặt vào phần cứng (hoặc lớp nền)
để thực thi các chức năng đã định nghĩa cho người sử dụng. PM có tài liệu hướng dẫn cách tạo ra
chương trình (cho developers) & cách sử dụng (cho users), nó được mô tả từ nhiều khía cạnh
khác nhau. PM được thể hiện thành các phiên bản (release) mặc dù users chỉ sử dụng 1 phiên bản
tại một thời điểm, nhưng developers phải kiểm soát được tất cả các phiên bản (tài liệu, chương
trình) của PM trong suốt chu kỳ sống của nó. • Đặc điểm:
Không có tính chất vật lý (“vô hình”): Người ta chỉ biết PM qua các tác động của nó lên phần
cứng (hiển thị chử, phát âm, rung…); copy được, để chạy trên nhiều máy. Phần mềm không bị
hao mòn như phần cứng chỉ bị “lạc hậu”, hoặc “lỗi”. Ngoài ra, nó dể thay đổi (sửa, nâng cấp)
hơn phần cứng đó là ưu thế và cũng là sứ mệnh cho phần mềm.
-Sự khác biệt giữa phần mềm và sản phẩm công nghiệp
Sản phẩm công nghiệp là một sản phẩm vật lý, bao gồm các giai đoạn sản xuất như thiết kế kỹ
thuật, chế tạo, lắp ráp và kiểm tra, sản phẩm thường là một đồ vật hoặc thiết bị được sản xuất để
phục vụ mục đích công nghiệp, thương mại hoặc sử dụng trong quá trình sản xuất. II)
Đặc tả cho phần mềm
Specification : (Một đặc tả) là một phát biểu khẳng định một hành vi (chức năng) hoặc tính chất
(chất lượng) của PM. Chẳng hạn như, hành vi: phần mềm có ghi logfile, chất lượng: phần mềm có bảo mật.
Requirement specification : là đặc tả đòi hỏi phải được thỏa mãn trên PM (“what”): là yêu cầu
thường được nêu ra từ người sử dụng
Design specification : là đặc tả hướng dẫn cho cách làm PM (“how”): là các loại tài liệu mô tả
csdl và các xử lý (tiếp cận cấu trúc ) hoặc mô tả các lớp (tiếp cận hướng đối tượng) của PM 2 khía cạnh:
1) Đặc tả về chức năng
Function (chức năng) PM là công cụ, nó phải có chức năng xử lý.
Đặc tả phần mềm về chức nắng: Là tập tài liệu có kiểm soát dùng để mô tả cho các chức năng và
xử lý của PM. Vd: URD,SyRD, SwRD, … trong tiếp cận cấu trúc.
Nếu xem PM là một hệ thống con trong môi trường mà nó được sử dụng, thì các chức năng xử lý
của PM được yêu cầu từ môi trường này. Có 2 cách tiếp cận hệ thống phổ biến để xác định các
chức năng của PM (là 1 hệ thống con):
Hướng cấu trúc: phân rã các chức năng của hệ thống lớn thành các chức năng của các hệ thống
con, đến mức có thể làm được (lược đồ DFD). lOMoAR cPSD| 58457166
Hướng đối tượng: nhìn từ ngoài (usecases) và nhìn vào bên trong hệ thống (classes): nó có nhiều
lớp,1 lớp – là 1 hệ thống con- có trách nhiệm cộng tác với các lớp khác để thực thi 1 chức năng
(use-case) của hệ thống.
2) Đặc tả về chất lượng được mong đợi ( phi chức năng) Là tập tài liệu mô tả các đặc tính chất lượng của PM.
Non-function (phi chức năng) ví dụ: độ tin cậy, bảo mật, linh hoạt,… của PM, được gọi chung là
các đặc điểm làm hài lòng người sử dụng (đặc tính chất lượng, quality attributes).
a) Khái niệm về chất lượng phần mềm
Để có chất lượng, PM phải làm thỏa mãn được những gì (user và developers) muốn đ/v PM. Hai khía cạnh:
Users muốn có PM tốt hơn trong việc sử dụng nó như một công cụ làm việc
VD: người sử dụng muốn PM có hiệu quả (efficiency), dể bảo trì
(maintainability),…, là những đặc điểm mà PM bộc lộ ra ngoài, user có thể nhận biết được.
Developers muốn có thiết kế tốt hơn cho PM để dể hiểu, dể làm, dể bảo trì,… vd: Nhất quán,
không dư thừa dữ liệu, bảo mật,…, đây là những đặc tính bên trong của PM, users không biết.
Tất nhiên, PM phải làm thỏa mãn yêu cầu của users
Vd: Để PM có hiệu quả như mong đợi của Users, thì nó cần phải sử dụng CPU, RAM, đường
truyền mạng,.. một cách hiệu quả.
b) Yêu cầu, mong muốn và ràng buộc
Yêu cầu là những điều kiện hoặc năng lực được mong đợi từ user (a) hoặc đòi hỏi trên sản phẩm
(b): yêu cầu là điều kiện cho công việc tạo mới (có thay đổi).
Ràng buộc (constraint) cũng là điều kiện, nhưng để duy trì (vận hành)
Đặc tả yêu cầu (=requirement specification) là yêu cầu được mô tả & truyền đạt một cách tường
minh đến người nhận. Vd: yêu cầu tương tác trên form, ghi trong tài liệu.
Mong muốn( Needs): bao gồm cả yêu cầu tường minh lẫn yêu cầu cần thiết nhưng không được
nêu ra. Vd: có hiệu quả cao
Design (=design specification) là đặc tả sản phẩm để hướng dẫn hành động tạo ra sản phẩm. vd:
giải thuật (để lập trình), cấu trúc dữ liệu (để cài đặt csdl), testcases (để kiểm thử) Mối quan hệ: lOMoAR cPSD| 58457166
c) Vai trò các tác nhân trong việc tạo ra phần mềm
Mô tả phần mềm để có chất lượng
Thông thường, users cố gắng diễn đạt yêu cầu chất lượng của họ thành đặc tính trên PM để devs
làm đúng yêu cầu cho họ. Tuy nhiên, Users không biết được những đặc tính nào của PM cần
phải có, vì họ không biết cách thiết kế (bên trong) của PM, các mong muốn như “dể sử dụng”,
“thân thiện”,… lại không giống nhau giữa các Users của một PM. Do đó, định nghĩa rõ ràng cho
mỗi đặc tính chất lượng được yêu cầu trên PM là rất cần thiết, để: Dev thỏa mãn được, hoặc gợi
ý thêm về các đặc tính cần thiết khác, User hiểu rõ giá trị sử dụng của các đặc tính này, để hiệu chỉnh yêu cầu
d) Mô hình chất lượng McCall, ISO25010 Vai trò của các mô hình chất lượng:
Chuẩn hoá yêu cầu chất lượng cho PM thành các yếu tố chất lượng có định nghĩa để tránh trùng
lặp, mâu thuẩn, hiểu lầm.
Ánh xạ mỗi yếu tố chất lượng này thành các đặc tính khả thi bên trong PM để cài đặt.
Bằng các mô hình này, người phát triển có thể “tự đo được” chất lượng của PM do mình tạo ra.
SQuaRE = Sw Quality Requirement & Evaluation Mô hình Mc.Cal(1977) lOMoAR cPSD| 58457166
Phần mềm khi làm ra trong phòng lab chuyển giao cho nơi sử dụng thì một số đặc điểm chất
lượng đã được thõa mãn ở phòng lab , do không được tương thích với môi trường vận hành
một số đặc điểm không bộc lộ ra được, ko thõa mãn được chất lượng.
Trong quá trình sử dụng phần mềm( vận hành): phát sinh thêm yêu cầu chất lượng.
Cập nhật: sử dụng 1 thời gian lạc hậu thì cần cập nhật nâng cấp
Các yếu tố chất lượng (Quality factors) được đưa ra từ 3 khía cạnh: chuyển giao, vận hành và cập
nhật: có tác động lớn đến việc sử dụng PM Các yếu tố chất lượng được định nghĩa cho Dev & users
Các yếu tố chất lượng “phiên dịch” thành tiêu chuẩn chất lượng để Dev hiện thực được trên PM.
Phương diện Chuyển giao: có 3 yêu cầu: khả năng linh hoạt( phần mềm chạy được trên nhiều
máy, trên nhiều hệ điều hành,..); khả năng sử dụng lại (sử dụng lại phương tiện, công cụ mà user
đã có, tốt và sử dụng hiệu quả để làm phần mềm mới); khả năng tương tác( nối kết phần mềm
của mình với phần mềm khác để làm hệ thống lớn hơn, phục vụ đắt lực cho người user)
Phương diện Vận hành: tính đúng đắn, độ tin cậy, khả năng sử dụng cao, toàn vẹn( toàn vẹn dữ
liệu và toàn vẹn code); tính hiệu quả
Phương diện Cập nhật, cải tiên: khả năng bảo trì; tính linh hoạt( thay đổi thông số phù hợp với
môi trường vận hành); khả năng kiểm tra Mô hình ISO 25010
Chất lượng của PM có từ việc sử dụng nó trong một ngữ cảnh cụ thể (quality in use): từ tập hợp
các đặc tính chất lượng mà người user mong đợi, sau đó nhìn từ môi trường sử dụng chọn ra đặc
tính chất lượng cần thiết
Người lập trình viên sẽ sử dụng các đặc tính user chọn để họ cân nhắc và cài đặt những đặc tính
phần mềm phải có để thõa mãn.
Chu kì sống của phần mềm theo ISO 25010
Yêu cầu chất lượng trong sử dụng: chất lượng user mong muốn có khi sử dụng phần mềm.
Trong môi trường, trong bối cảnh cụ thể, user chọn ra đặc tính chất lượng cần phải có. lOMoAR cPSD| 58457166
Từ yêu cầu chất lượng trong sử dụng xác định và định nghĩa các yêu cầu chất lượng phần mềm
bên ngoài( external quality requirements).: là những đặc tính chất lượng mà người user có thể
traỉ nghiệm được, cảm nhận được từ môi trường sử dụng, nắm bắt được ý nghĩa của các đặc tính
chất lượng ( chức năng về giao diện)
Từ Yêu cầu chất lượng phần mềm bên ngoài xác định và định nghĩa các yêu cầu chất lượng
phần mềm bên trong: những yếu tố chất lượng yêu cầu trên từng thuộc tính của phần mềm mà nó
phải được cài đặt ( chi tiết của phần mềm) Ví dụ csdl phải cài đặt theo chuẩn 3.
Từ yêu cầu tạo ra sản phẩm.
Để có sản phẩm phần mềm thõa mãn những yếu tố chất lượng trên thuộc tính thì phải đối chiếu
với yêu cầu của bảng thiết kế.
Đánh giá chất lượng phần mềm bên trong được sử dụng để dự đoán chất lượng phần mềm bên ngoài.
Đánh giá chất lượng phần mềm bên ngoài có thể được sử dụng để dự đoán chất lượng trong sử
dụng. Cài đặt phần mềm vào môi trường vận hành, đối chiếu xem đúng với yêu cầu chất lượng
mà người user mong đợi chưa.
Nếu những điều người user mong đợi chưa thể hiện hết thành requirments, người user sẽ bổ
sung. Nhìn vào chất lượng sản phẩm trong môi trường thực, thì người user tiếp tục đưa ra Needs.
Giá trị của các mô hình chất lượng:
Các tiêu chí chất lượng được định nghĩa sẵn là sự gợi ý cho các yêu cầu chất lượng: Yêu cầu chất
lượng là tập tiêu chí được chọn
Ước lượng được mức độ quan trọng của mỗi tiêu chí trong môi trường ứng dụng thực tế:
Để ước lượng mức độ thực hiện
Với bộ tiêu chí được chọn làm yêu cầu, cả users lẫn devs đều có thể tự đánh giá chất lượng của
PM: Kiểm thử trên các đặc tính chất lượng được chọn
CHƯƠNG 2: MÔ HÌNH LÀM PHẦN MỀM
1/ SW Process (Tiến trình PM)
Là một chuổi hành động cần làm (kế hoạch) để làm ra và cập nhật cải tiến cho PM, đến khi nó bị
bỏ đi. Mỗi phần mềm chỉ có 1 tiến trình làm phần mềm.
2/ SW Process model( Mô hình làm phần mềm)
Là một khuông mẫu để thiết lập tiến trình làm phần mềm; nó quy định các công đoạn (bước) và
thứ tự thực hiện các công đoạn này ví dụ: waterfall có các công đoạn khảo sát, phân tích, thiết lOMoAR cPSD| 58457166
kế, hiện thực, kiểm thử và bảo trì. Công đoạn trước hổ trợ cho một vài công đoạn sau một cách
có kiểm soát (biết đúng/sai) và có mục đích (biết dùng để làm gì).
Quá trình phát triển PM thực chất là quá trình nhận thức yêu cầu từ thực tế đối với PM trong suốt
chu kỳ sống của nó, để thực hiện các thay đổi lên PM làm thỏa mãn các yêu cầu này.
Sự thay đổi của PM thể hiện thành phiên bản mới tốt hơn phiên bản củ và thay đổi có kiểm soát.
Mỗi một thay đổi được đưa ra thì : Nó phải phù hợp với mong muốn (thỏa mãn chưa); Nó có
đáng làm hay không ? (lợi ích/thiệt hại); Nó được làm như thế nào ? (khó hay dể)
Sự xem xét để thực hiện các thay đổi này đưa đến nhu cầu tìm kiếm thông tin (kiến thức, kinh
nghiệm) và công nghệ (phương tiện), để chọn cách làm tốt nhất, phối hợp các công đoạn trong
tiến trình PM một cách hiệu quả
Một mô hình phát triển PM cần thể hiện 4 nội dung: 1.
SW specification: đặc tả phần mềm -
Đặc tả cho vấn đề: từ mong muốn đặc tả thành yêu cầu, mô tả rõ ràng phần mềm cần làm gì -
Đặc tả cho phần mềm (giải pháp, trong thực tế) 2.
SW design & implementation : Thiết kế và hiện thực phần mềm -
Thiết kế phần mềm từ đặc tả phần mềm -
Từ bảng thiết kế hiện thực thành 1 phiên bản PM 3.
SW verification & validation: cơ chế, cách để đánh giá chất lượng
Củng cố cho cách làm PM và phiên bản PM hiện tại để nó thỏa mãn cho yêu cầu (và mong muốn).
Verification: đánh giá trên từng công đoạn làm: công đoạn sau có làm đúng theo yêu cầu của
công đoạn trước hay không
Validation: phần mềm tạo ra có đúng, phù hợp với mong muốn người dùng không. 4. SW evolution (maintenance) -
Cách cập nhật phiên bản PM hiện tại để nó thỏa mãn cho yêu cầu mới: làm sao để phần
mềm không bị lạc hậu( cập nhật, nâng cấp, cải tiến), ngăn ngừa những nguy cơ làm hư hỏng hệ
thống, làm sao để kiểm soát được các thay đổi để cho phần mềm trở nên tốt hơn.
Mỗi mô hình sẽ có các đặc trưng khác nhau:
Mô hình tác nước ( tuyến tính): Gồm các giai đoạn: lOMoAR cPSD| 58457166
Mô hình thác đổ (còn gọi là SDLC chuẩn) dựa trên phương pháp luận giải quyết vấn đề
có từng bước dẫn dắt quá trình suy nghĩ cách giải quyết vấn đề: -
Khảo sát : nhận thức bối cảnh phát sinh yêu cầu có PM -
Phân tích: định nghĩa yêu cầu (định nghĩa các chức năng cần thiết của PM từ yêu cầu hợp lý của user) -
Thiết kế: cân nhắc chọn lựa cho giải pháp “tốt nhất” (từ kiến thức chuyên môn trong lĩnh
vực CNPM) để thực hiện các chức năng của PM (thành các xử lý của nó). -
Hiện thực (lập trình): áp dụng giải pháp thiết kế -
Kiểm thử: đánh giá mức độ phù hợp của giải pháp (là PM&cách dùng nó) so với yêu cầu làm PM. -
Bảo trì: cách sửa PM cho phù hợp yêu cầu mới Đặc điểm tuyến tính:
Mỗi công đoạn sẽ tạo ra một ẩn phẩm: Có các tài liệu (vd: tài liệu phân tích, thiết kế)
hướng dẫn thực hiện công đoạn tiếp theo để giải quyết yêu cầu ban đầu (từ user). Mọi công đoạn
cùng cộng tác nhau giải quyết yêu cầu. Công đoạn trước phải hoàn tất để làm công đoạn sau.
Người users chỉ đưa ra yêu cầu để có PM sử dụng: Users không tham gia vào việc làm ra
sản phẩm PM. Nếu yêu cầu sai, mọi công đoạn phải được xét lại. lOMoAR cPSD| 58457166
Mô hình này chỉ phù hợp với loại yêu cầu “chắc chắn đúng, đủ và không thay đổi”. Mô
hình này cần nhiều công sức để làm lại cho các yêu cầu ban đầu bị thay đổi.
Mô hình làm mẫu thử:
Đặc điểm: lặp nhiều lần
Ngược với mô hình thác đổ, người user (chuyên gia) điều khiển quá trình phát triển mẫu
để dần dần tạo thành một phiên bản mẫu hoàn chỉnh (PM): Có cộng tác giữa user và dev.
Trực quan, dể nhận xét và bàn luận trên mẫu: User tiếp cận sớm với mẫu (sẽ là sản phẩm
PM), Dev hiểu rõ yêu cầu từ user.
Mọi thay đổi đều thể hiện trên mẫu, không có tài liệu. Bị phụ thuộc vào user, User quyết
định mọi chi tiết của mẫu (Dev không cần phân tích để đưa ra chức năng & đặc tính chất lượng).
Nhưng nhiều users có thể sinh mâu thuẩn. Khó bảo hành, bảo trì, cải tiến được( nếu thay đổi dev). Mô hình xoắn ốc Đặc điểm tiến hóa
Thừa kế các mô hình trước: -
Mô hình thác nước: có các công đoạn để tạo mẫu (có tài liệu ấn phẩm của công đoạn). lOMoAR cPSD| 58457166 -
Mô hình mẫu thử: cho phép user tham gia đánh giá & cải tiến mẫu sau mỗi chu kỳ.
Khác các mô hình trước: -
Làm từ bản chất ⃕ chi tiết (bất biến ⃕ tùy biến). -
Reciew: dành cho tát cả những người có liên quan (User + Dev + Experts +…) - Các
công đoạn trong chu kỳ: thay đổi được. -
Cho phép cập nhật ấn phẩm, thay vì tạo mới. -
Cho phép tiếp tục phát triển trong khi PM đang được sử dụng Mô hình hợp nhất (UP/RUP)
Đặc điểm tiến hóa linh hoạt
Có các chu kỳ để cải tiến mẫu (giống như xoắn ốc). -
Mỗi chu kỳ có thể dùng mô hình thác nước,mẫu thử,.. -
Phải sử dụng tiếp cận hướng đối tượng.
Mỗi chu kỳ phát sinh công việc cho chu kỳ kế tiếp. -
Mỗi công đoạn trong một chu kỳ có thể nhận yêu cầu từ bất kỳ công đoạn nào trước đó.
vd: kết quả “test” ở chu kỳ trước → sửa “requirements” và bổ sung “design” để thực hiện ở chu kỳ sau. -
“Công đoạn” là “luồng công việc” cập nhật 1 ấn phẩm.
Có 9 luồng công việc làm song song. -
6 luồng công việc phát triển mẫu (engineering) -
3 luồng hổ trợ phát triển mẫu (configuration & change management, project management, environment)
CHƯƠNG 3: ỨNG XỬ VỚI YÊU CẦU
1) Quản lý yêu cầu (CMMI-L2_RM) Khám phá yêu cầu mới và kiểm soát chúng
a) Hiểu đúng yêu cầu
Hiểu nguyên nhân phát sinh yêu cầu (vấn đề, mong muốn): là nền tảng cốt lõi cho việc hiểu đúng yêu cầu
Kiểm chứng yêu cầu, vd: làm mẫu thử. lOMoAR cPSD| 58457166
Quá trình đặt yêu cầu và kiểm chứng yêu cầu
Mẫu thử trong môi trường sống sẽ bị ảnh hưởng bởi nhiều khía cạnh khác nhau: Tình huống
dùng (usercases), Ràng buộc/Phụ thuộc, Rủi ro trong môi trường, Hiệu quả, Lợi/Hại
Tình huống dùng( usercase): tình huống mà người sử dụng cần dùng đến phần mềm, phần mềm
hỗ trợ user giải quyết tình huống tác động từ phần mềm lên môi trường
Ràng buộc/ phụ thuộc: xuất phát từ môi trường làm việc của người user phần mềm muốn chạy
được phải lệ thuộc vào những thứ xung quanh môi trường: hệ điều hành,
Rủi ro: phần mềm chạy gây ra những rủi ro gì, những rủi ro môi trường gây ra
Hiệu quả: hiệu quả xử lý nhanh hay chậm, tốn tài nguyên hay không,…
Lợi/Hại: sử dụng phần mềm có tiết kiệm được chi phí hay không, lợi ích khi sử dụng phần mềm
Phần mềm chưa thõa mãn được hết mong muốn xem xét (mẫu) Yêu cầu Từ đó developer
mới sửa mẫu và tạo ra phiên bản mẫu thử mới. Phiên bản mới thõa mãn thêm những mong đợi
xuất phát từ môi trường so với phiên bản cũ.
b) Cam kết cho yêu cầu: tiến trình cam kết và thõa thuận
Cái gì cam kết từ đầu thì phải làm để thõa thuận cam kết
Trước khi sử dụng nguồn lực của mình cho việc thực hiện yêu cầu thì phải xác định tính khả thi của nó. lOMoAR cPSD| 58457166
1. Nơi phát sinh yêu cầu: Nhận biết yêu cầu từ khách hàng, users hoặc stakeholders 2. Xem
xét khả năng đáp ứng từ dự án, theo nhiều khía cạnh: mục tiêu, nguồn lực. phương án và rủi ro 3.
Xem xét khả năng thực hiện có thêm trợ giúp từ bên ngoài 4.
Cam kết thực hiện yêu cầu khả thi bằng kế hoạch cơ sở (base line project plan, BPP) 5.
Thực hiện theo kế hoạch để làm thỏa mãn cho các cam kết
Các khía cạnh xem xét tính khả thi: 1.
Kinh tế: PM sẽ giúp ích được gì cho users / tổ chức : lợi ích được tích lũy theo thời gian
từ lúc bắt đầu sử dụng phần mềm đến một thời điểm cụ thể 2.
Vận hành: PM có thể tích hợp được với các thành phần khác (hệ điều hành, máy tính, quy
trình) để tạo thành hệ thống vận hành tốt trong môi trường hiện tại không ? 3.
Kỹ thuật: PM có hiện thực được không, với các hổ trợ hiện có (vd: công nghệ, năng lực,
phương pháp,..) trong giới hạn cho phép về chi phí và thời gian ? 4.
Kế hoạch: Có kế hoạch khả thi để giải quyết mọi yêu cầu từ nhiều phương diện : kỹ thuật,
vận hành, thời gian, chi phí,…? 5.
Chính trị-xã hội: Có gây hại (hiệu ứng lề) gì không ?
Chất lượng của yêu cầu:
Tiêu chí thể hiện nội dung yêu cầu:
Mạch lạc: mọi thứ phải có căn cứ, liên kết lại với nhau
Nhất quán: mọi yêu cầu, công đoạn không được mâu thuẫn
Kết quả được mô tả chính xác: một tình huống được đưa ra phải có kết quả mô tả chính xác
Hậu quả được mô tả rõ lOMoAR cPSD| 58457166
Tiêu chí truyền đạt yêu cầu: SMART S: cụ thể rõ ràng M: đo lường được A: khả thi
R: có lý do T: có thời hạn
c) Theo dõi việc thực hiện( tracking & oversight)
Giúp năng ngừa và loại bỏ sự không nhất quán giữa yêu cầu và hành động thực hiện để đảm bảo
đúng cam kết thực hiện yêu cầu. Tracking: Theo dõi kết quả trong quá khứ
Oversight: dự báo hậu quả để lại trong tương lai
d) Kiểm soát các thay đổi
Nhận biết sự thay đổi trên yêu cầu ban đầu từ các tác nhân nêu ra yêu cầu, cân nhắc về các thay
đổi và kiểm soát các hành động đáp ứng cho thay đổi.
Các nguồn phát sinh làm thay đổi yêu cầu: -
Đề nghị thay đổi từ nơi đặt ra yêu cầu: marketing/customers/management cảm thấy các
tính năng hoặc giao diện không phù hợp, thay đổi yêu cầu để phù hợp hơn. Môi trường vận hành
bị thay đổi ( ví dụ sự mở rộng của tổ chức) dẫn đến yêu cầu thay đổi, phần mềm phải cải tiến,
nâng cấp để phù hợp với môi trường mới. lOMoAR cPSD| 58457166 -
Đề nghị từ nơi thực hiện yêu cầu (Project Enviroment): có cách làm tốt hơn, công nghệ bị
lạc hậu có công nghệ tốt hơn đề nghị thay đổi cách làm để phần mềm trở nên tốt hơn.
(Đọc sơ qua)
Yêu cầu đối với sản phẩm xuất hiện xuyên suốt từ khi dự án bắt đầu đến khi sự án sắp kết thúc Giai đoạn tiền dự án: •
Tiền dự án (pre-project) Là một tập hợp có hệ thống các việc cần làm để khẳng định các
yêu cầu sẽ được cam kết thực hiện (sẽ ghi trong bản hợp đồng) giữa các bên tham gia vào quá
trình tạo ra sản phẩm phần mềm. • Mục tiêu: –
Lập tôn chỉ (charter) và hợp đồng (contract) để khẳng định vai trò và trách nhiệm của các
bên tham gia dự án, và các tiêu chí để đánh giá, nghiệm thu cho hợp đồng dự án. –
Khẳng định kế hoạch hợp tác thực hiện (Baseline Project Plan, BPP). Project Charter (tôn chỉ):
Project charter là tập tài liệu xác định một cách hết sức cơ bản về trách nhiệm và quyền hạn của
dự án và các bên có liên quan. lOMoAR cPSD| 58457166
Nó được các key-persons ( Í stakeholders) cùng nhau tạo ra để làm tiên đề cho các hành động phối
hợp thực hiện dự án, ie: mọi vấn đề & giải pháp cụ thể đều bắt nguồn từ charter này.
Project charter diễn tả mối quan hệ giữa vấn đề, mục tiêu, giải pháp, lợi ích và kinh phí thực hiện của dự án. Charter Index 1.
Những vấn đề, hậu quả và cơ hội khắc phục của tổ chức thụ hưởng. 2.
Mục tiêu của dự án (→ giải quyết vấn đề nào). 3.
Yêu cầu đối với sản phẩm/dịch vụ của dự án. 4.
Phương pháp giải quyết yêu cầu 5.
Giả định và phụ thuộc của phương pháp 6.
Các chuyển giao, và mốc chuyển giao 7.
Lợi ích từ các chuyển giao 8.
Nguồn lực & nơi cấp nguồn lực cho dự án 9.
Vai trò và trách nhiệm của stakeholders đối với dự án (trong đó có nhiệm vụ và quyền
hạn của trưởng dự án) Lập hợp đồng 1.
Lập bản hồ sơ dự thầu (proposal ) hoặc phương án sơ bộ gửi đến khách hàng để hai
bên cùng xem xét nội dung yêu cầu & giải pháp trước khi ký hợp đồng.
– Đây là giai đoạn khảo sát để nhận biết yêu cầu từ hiện trạng thực tế. 2.
Lập bản hợp đồng dự án (contract ) sau khi proposal/phương án sơ bộ đã hoàn chỉnh. 3.
Lập bản hợp đồng phụ (sub-contract) với các đối tác bên ngoài để thực hiện một phần
việc được outsource từ dự án (nếu có).
2) Phát triển yêu cầu (CMMI_L3_RD)
Biến yêu cầu thành đặc tả PM
a) Thấu hiểu yêu cầu đối với phần mềm
Khám phá những mong muốn về phần mềm theo quan điểm hệ thống trong suốt chu kỳ sống của nó.
Yêu cầu đối với phần mềm nhìn từ quan điểm hệ thống: lOMoAR cPSD| 58457166
Môi trường sống của phần mềm:
1.Môi trường nghiệp vụ (business) –
Các vấn đề gì cần giải quyết trong tổ chức (phần mềm có những lợi ích gì). –
Các quy tắc quản lý phải tuân thủ (phần mềm phải tuân thủ ràng buộc gì).
Vì sao yêu cầu phần mềm phải được xem xét và chọn lọc từ môi trường nghiệp vụ?
Môi trường nghiệp vụ là miền vấn đề (problem domain) có nhiều vấn đề “bất biến” (không đổi
& tồn tại lâu dài) làm phát sinh nhu cầu sử dụng PM để giải quyết các vấn đề này.
Môi trường nghiệp vụ yêu cầu phần mềm cung cấp các chức năng và tính năng liên quan đến
nghiệp vụ của tổ chức. Phần mềm được phát triển để giải quyết những vấn đề hoặc nhu cầu kinh
doanh cụ thể của tổ chức, giúp đảm bảo rằng phần mềm sẽ cung cấp giá trị và lợi ích cho tổ
chức, như cải thiện hiệu suất, tối ưu hóa quy trình làm việc hoặc tạo ra sản phẩm và dịch vụ mới.
Phần mềm tạo ra phải tuân thủ quy tắc quản lý liên quan đến lĩnh vực của tổ chức.
2.Môi trường vận hành (operation)
Là môi trường sử dụng phần mềm: bao gồm các yếu tố và điều kiện cần thiết để phần mềm hoạt
động một cách ổn định và hiệu quả. –
Máy tính và các thiết bị hổ trợ cho phần mềm: hệ điều hành, cấu hình phần cứng, cấu
hình mạng,..phải tương thích với phần mềm –
Người sử dụng (trực tiếp và gián tiếp) –
Các ràng buộc trong giao tiếp, vd: quy trình xử lý
Vì sao việc lấy ý kiến từ môi trường vận hành rất quan trọng ?
Môi trường vận hành của PM là miền vấn đề (problem domain) có nhiều vấn đề “bất biến”
(không đổi & tồn tại lâu dài) làm phát sinh nhu cầu sử dụng PM để giải quyết các vấn đề này.
Việc lấy ý kiến từ môi trường vận hành, ta có thể nhận biết mức độ tương thích của các thiết bị
với phần mềm, giúp ta hiểu rõ hơn trải nghiệm và nhu cầu của người sử dụng. Ngoài ra việc lấy
ý kiến từ môi trường vận hành giúp phần mềm đảm bảo các ràng buộc trong giao tiếp.
3.Môi trường phát triển (development)
Môi trường sử dụng để viết, thử nghiệm và triển khai phần mềm
Công cụ: Phần mềm hổ trợ lập trình, trình biên dịch, công cụ quản lý mã nguồn, ….
Người: kiến thức chuyên môn, kênh thông tin Phương pháp, kỹ thuật, công nghệ hiện có lOMoAR cPSD| 58457166
Quan hệ giữa phần mềm và môi trường: •
Môi trường nghiệp vụ hoặc vận hành của PM là miền vấn đề (problem domain) có nhiều
vấn đề “bất biến” (không đổi & tồn tại lâu dài) làm phát sinh nhu cầu sử dụng PM để giải quyết các vấn đề này.
– Nguồn gốc của yêu cầu đ/v phần mềm là từ những vấn đề bất biến trên, không phải từ users •
Người phát triển làm ra PM bằng cách dùng các hổ trợ cần thiết (công nghệ, phương
pháp, cộng đồng,…) từ môi trường phát triển PM.
Thông tin cộng tác giữa các chuyên gia (devs + users = COMMUNITY) có thể cung cấp giải
pháp tốt nhất cho việc phát triển PM (IEEEstd1233)
Quá trình phát triển yêu cầu hệ thống giao tiếp với ba tác nhân: Customer, Enviroment, Teachnical Community
Customer: đưa ra Raw Requirement: khách hàng đưa ra yêu cầu ban đầu, nhu cầu và mong đợi,
những ý tưởng và đề xuất cho phần mềm.
Environment: đưa ra Constraint/ Influence: xác định các yếu tố, yêu cầu ràng buộc từ môi trường
ảnh hưởng đến hệ thống ( ảnh hưởng chính trị, thị trường, tiêu chuẩn, và chính sách kỹ thuật, văn hóa, tổ chức)
Từ bộ sưu tập yêu cầu phát triển hệ thống biểu diễn kỹ thuật được chuẩn bị cho Technical
Community để làm rõ xác nhận yêu cầu lOMoAR cPSD| 58457166
Technical Community cung cấp phản hồi Technical Feedback có thể gây ra sự thay đổi bổ sung
hoặc xóa bỏ trong bộ sưu tập yêu cầu. Phản hồi từ cộng đồng kĩ thuật có thể cung cấp cho khách
hàng những tính năng mới nhất, các công nghệ mới từ đó phản triển hơn bộ sưu tập phát triển yêu cầu hệ thống.
Từ bộ sưu tập yêu cầu biểu diễn cho khách hàng ( role, prototype, user story,..)
Khách hàng gửi feedback: khách hàng phản hồi về sự cập nhật thông tin về mục tiêu vấn đề, về
các yêu cầu mới để phát triển bộ sư tập yêu cầu hoàn chỉnh.
b) Chi tiết hóa yêu cầu thành đặc tả cho PM:
“Requirements allocation and flow-down”: phiên dịch yêu cầu đ/v PM (nhìn từ quan điểm sử
dụng) thành đặc tả sản phẩm, thiết kế, lập trình, kiểm thử,.. (quan điểm xây dựng, tạo sản phẩm)
Là sự cụ thể hóa yêu cầu thành đặc tả chi tiết ở các mức (mức ý niệm, mức thiết kế, mức lập trình,..), vd: •
FR: Ngữ cảnh ® DFD-0 ® DFD-1 … •
NFR: External quality factors ® internal quality attibutes.
Theo CMMI, có 3 mức chi tiết: 1.
User requirements: đặc tả yêu cầu của users 2.
Product (system) requirements : đặc tả yêu cầu đối với hệ thống lớn (nhìn từ bên ngoài system) 3.
Product-component requirements: đặc tả từng môđun của hệ thống (nhìn vào bên trong system)
Chi tiết hóa yêu cầu làm PM: 1.
Tìm hiểu nhu cầu về PM từ môi trường nghiệp vụ (“User” requirements) thông qua các stakeholders
– Cân nhắc từ các mục tiêu kinh tế ($) 2.
Xem xét User requirements theo quan điểm hệ thống (nghiệp vụ, vận hành, phát triển)
để diễn tả thành yêu cầu đ/v hệ thống (System requirements) 3. Từ System requirements,
đặc tả yêu cầu (bên ngoài) cho phần mềm (SW Product requirements)
– Yêu cầu chức năng và phi chức năng lOMoAR cPSD| 58457166 4.
Từ Product requirements, tạo ra bản thiết kế có nhiều thành phần; mỗi thành phần
giải quyết cho 1 yêu cầu được phân rã từ Product requirements (SW Components requirements) 5.
Đặc tả trong thiết kế là yêu cầu cho các công đoạn tiếp theo (lập trình, kiểm thử, cài đặt, …)
Chi tiết hóa yêu cầu theo CMMI:
c) Phân tích và kiểm chứng các đặc tả
Mô phỏng môi trường vận hành, phân tích các tình huống cần sử dụng phần mềm (bằng prototype hoặc user story);
Chỉ ra sự phù hợp của bản thiết kế PM với các môi trường nghiệp vụ, vận hành, phát triển của nó. •
Là hành động chứng minh rằng các đặc tả đ/v PM phản ánh đúng “mong đợi”. lOMoAR cPSD| 58457166
– Mong đợi từ những tác nhân (stakehoders). Hành động này phân tích mối quan hệ giữa phần
mềm với các môi trường (nghiệp vụ, phát triển, vận hành) trong suốt chu kỳ sống của nó kể cả
các môđun trong hệ thống/PM, để khẳng định rằng các đặc tả là cần thiết, đúng và đầy đủ. • Phương pháp: –
Validation: CMR sản phẩm sẽ thỏa mãn mong đợi – Verification: CMR hành động làm sản phẩm là đúng. • Kỹ thuật: –
Peer review, inspection, user story, prototype,..
( Đọc sơ qua) Dự án •
Thiết kế: Thiết kế phần mềm là một hệ thống các công việc chỉ ra giải pháp của PM cho
các vấn đề đã biết, và đặc tả chi tiết cho PM để xây dựng, kiểm thử và triển khai ứng dụng một phiên bản PM: –
Đặc tả các chức năng và kết cấu của PM (các usecase, class, layers, package/subsystem,…) –
Đặc tả chi tiết để lập trình (mô đun, dữ liệu, giải thuật, giao tiếp, công nghệ / chuẩn,…) –
Đặc tả chi tiết kiểm thử: test cases, test plans –
Đặc tả cách vận hành của PM (mô hình vận hành, các vai trò của users, flatforms, giao
tiếp với các hệ thống khác,… ) •
Tất cả các hành động đưa ra đặc tả đều phải được chứng minh là đúng (thỏa mãn cả FR lẫn NFR)
Yêu cầu và giải pháp làm phần mềm
1 Yêu cầu dùng để xây dựng các giải pháp từ tổng quát đến chi tiết, mà kết quả sau cùng là PM;
do đó, cần phát hiện những yêu cầu “chắc chắn đúng” cho PM càng sớm càng tốt để làm cơ sở
phát triển các yêu cầu khác (vd: mh xoắn ốc). 1.
Yêu cầu đúng là yêu cầu dẫn xuất từ bản chất của vấn đề, không hoặc ít bị thay đổi (invariances). 2.
Tạo điều kiện cho users tiếp cận sớm với PM (user involvement) để họ tư vấn/gợi ý/đánh giá:
Nhận định về vấn đề bị sai, hoặc còn thiếu
Đánh giá tầm quan trọng của vấn đề không đúng
Giải pháp của phần mềm chưa tốt … 2.
Xem xét toàn diện các khía cạnh phát triển, chuyển giao, vận hành, tiến hóa của PM (mô
hình McCALL, ISO 9126) để đưa ra đặc tả, bằng cách phối hợp nhiều chuyên gia (ie, community).
Peer review / forum / workflow lOMoAR cPSD| 58457166
Ý kiến từ người sử dụng được ưu tiên, vì nó thường diễn tả trực tiếp yêu cầu từ tổ chức có sử
dụng PM (nghiệp vụ, môi trường vận hành, hiệu quả dùng tài nguyên,..), tuy nhiên người sử
dụng không giải quyết được vấn đề sử dụng lâu dài của PM (công nghệ, an toàn, cải tiến,... ).
Các website stackOverflow.com, expertExchange.com, codeProject.com, hoặc gitHub.com đều
cung cấp các nghiên cứu chuyên sâu cho giải pháp. 3.
PM sẽ thực hiện các chức năng theo yêu cầu nhưng vì chưa có sẵn nên khó hình dung
cách xử lý; vì vậy, cần mô tả hành vi của chúng một cách trực quan. Vẽ ra các lược đồ
(DFD/ERD,UMLs), làm phim minh họa (user story)
Dùng CASE tools để thiết kế (Rational Rose/ Power Designer/Oracle Designer,..) Làm mẫu thử
bỏ đi (throw-away prototype) Agile: Minh hoạ bằng chính source code đang làm. 4.
Tài liệu phát triển PM phải được mô tả một cách có hệ thống; sự “phiên dịch” yêu cầu
ban đầu thành đặc tả chi tiết cho giải pháp (sản phẩm) phải rõ ràng, trong suốt (~traceability).
Mọi vấn đề/giải pháp trong từng mức đều nhất quán (consistency).
Mỗi yêu cầu được cụ thể hóa thành giải pháp chi tiết trong mức thấp hơn (impact).
Mỗi chi tiết phải giải quyết vấn đề nào đó ở mức cao hơn (derive).
Liệu mọi yêu cầu ở mức cao đều đã có giải pháp ở mức chi tiết hơn ? (coverage). 5.
Yêu cầu chức năng và phi chức năng cần được phát triển đồng thời.
Các yêu cầu chức năng được phân rã / chi tiết hoá đến mức lập trình được bằng DFD, UML Class diagram,..
Các yêu cầu phi chức năng được quy chuẩn thành các yếu tố chất lượng (external quality
factors) và diễn tả thành các đặc trưng phải có của PM (internal attributes) bằng các mô hình
chất lượng, như ISO 25010.
Xem xét đồng thời yêu cầu chức năng & phi chức năng của PM để quyết định cách cài đặt các
chức năng này (chọn giải thuật phù hợp).
CHƯƠNG 5:VERIFICATION & VALIDATION 1) Cách làm PM đúng
Là tạo ra sản phẩm làm hài lòng người sử dụng: yêu cầu là nền tảng cơ sở để làm ra sản phẩm
đúng đáp ứng mong đợi
Sản phẩm không đúng là: Không thoả mãn hết mọi yêu cầu đầu vào, Có mâu thuẩn với yêu cầu, Không dùng được,…
2) Định nghĩa Verification & Validation
Verification: đánh giá một hệ thống hoặc một thành phần trong hệ thống trên từng công đoạn
làm để quyết định khi nào sản phẩm phát triển thõa mãn yêu cầu đặt ra cho từng công đoạn.
Verification không kiểm tra đầu vào sai; lỗi (yêu cầu sai) sẽ phát tán đến sản phẩm => cần có validation.
Validation: đánh giá phần mềm tạo ra có đúng, phù hợp với mong muốn người dùng không.
Validation không thể kiểm thử hết mọi tình huống xử lý của sản phẩm => cần có verification.