Bài giảng Quản lý dự án phần mềm - Chương 3: Ứng xử với yêu cầu đối với phần mềm - Nguyễn Anh Hào

Nguyễn Anh Hào Khoa CNTT2 Học viện CNBCVT – Cs Tp.HCM S W Q u a lit y A ss u ra n ce S W Q u a lit y A ss u ra n ce 03. Ứng xử với yêu cầu đ/v PM  1 Yêu cầu là gi ? Yêu cầu (requirements) là đặc tả cho những gì cần phải được thoả mãn bằng cách làm. đặc tả hành vi xử lý của phần mềm (functions) đặc tả các đặc tính của phần mềm (characteristics) đặc tả các ràng buộc đ/v cách thức phát triễn phần mềm (constraints). Yêu cầu không tường minh (needs) là những mong muốn được cho là cần thiết, nhưng không được đặc tả. Cả yêu cầu lẫn mong muốn đều góp phần quyết định chất lượng của phần mềm. 2 Software_Requirements, 3rd edition, 2013.pdf: Page 6 Ứng xử với yêu cầu Yêu cầu đv PM : 1. Yêu cầu phải được hiểu đúng để làm đúng Không chỉ dựa vào mô tả của người sử dụng 2. Yêu cầu phải đầy đủ & nhất quán Vì PM là hệ thống. 3. Yêu cầu phải đưa đến hành động khả thi 4. Yêu cầu có thể thay đổi để có PM tốt hơn Cách làm cần hổ trợ cho các thay đổi yêu cầu Sự truyền đạt yêu cầu có 5 đặc điểm: S.M.A.R.T. 3 Yêu cầu đ/v PM có từ đâu ? 1. Môi trường ứng dụng PM (hệ thống lớn) Các vấn đề nghiệp vụ cần giải quyết trong hệ thống Yêu cầu của user và giải pháp nghiệp vụ của vấn đề 2. Môi trường vận hành PM (nguồn lực: con người | phương pháp | công cụ) Máy tính và các thiết bị dùng cho PM Người sử dụng (trực tiếp và gián tiếp) của phần mềm Flat-form của phần mềm: hệ điều hành, mạng, 3. Môi trường phát triễn PM Các công cụ làm ra phần mềm: pm để lập trình, Năng lực chuyên môn của người làm phần mềm Phương pháp, kỹ thuật (công nghệ) được chọn để làm phần mềm 4 Các ứng xử cơ bản đ/v yêu cầu 1. Nhận biết và kiễm soát yêu cầu (CMMI-level 2-RM)  Phát hiện nhu cầu sử dụng PM và các yêu cầu từ người sử dụng, trong đó có sự thay đổi yêu cầu  Nghiên cứu khả thi: Xác định ích lợi của phần mềm sẽ xây dựng (nên làm không) và phương án làm 2. Khám phá yêu cầu (CMMI-level 3-RD)  Phát triễn yêu cầu cho việc xây dựng phần mềm 3. Truyền đạt yêu cầu (Comunicating)  Mô hình hoá, tài liệu đặc tả, làm mẫu thử (demo) 4. Kiễm chứng yêu cầu (validation)  Chứng minh rằng các đặc tả yêu cầu phản ánh đúng mong đợi đ/v PM (Review) 5 1.Nhận biết & kiễm soát yêu cầu  PM không chỉ phục vụ cho người sử dụng; nó phục vụ cho hệ thống lớn hơn vd: website bán hàng phục vụ cho công việc kinh doanh và kế toán của công ty. Người sử dụng chỉ làm một phần công việc của hệ thống. Yêu cầu đ/v PM = yêu cầu của hệ thống lớn  Yêu cầu từ hệ thống được nêu ra từ người sử dụng (hoặc stake-holders), và phải được xem xét một cách có hệ thống vì: Để tránh chủ quan. Để khẳng định tính đúng đắn của yêu cầu. Bảo đảm tính nhất quán của hệ thống. 6 Yêu cầu đ/v PM từ quan điểm hệ thống 7 D es ig n d o m ai n P ro b le m d o m ai n Giải pháp Phần mềm Vấn đề Yêu cầu về chất lượng Kết cấu của hệ thống Các hổ trợ (công nghệ) Yêu cầu từ user 1 2 3 4 5 6 7 8 9 Đặc tính của PM 10 C1 FR1 NFR C2 FR2 (External Quality Factors) (Internal Attributes) Hệ thống đặc tả yêu cầu cho PM dot arrow = “is the origin of”, arrow = “are stored in ” 8 Software_Requirements, 3rd edition, 2013.pdf: Page 8 A pp lic at io n O p er at io n Im p le m en ta ti o n CMMI-L2: Quản lý yêu cầu Quản lý yêu cầu (Requirements Management, RM): là những hành động tìm hiểu yêu cầu đ/v PM từ khách hàng (users), cam kết làm thỏa mãn yêu cầu, kiễm soát các thay đổi đ/v yêu cầu đã biết, và gắn yêu cầu với công việc (kế hoạch thực hiện) làm thỏa mãn yêu cầu.  Ie, thiết lập yêu cầu từ quan điểm sử dụng PM CMMI DEV-V1.3 (2010).pdf Page 341 & 325 9 CMMI-L2: Quản lý yêu cầu (RM) 1. Hiểu đúng yêu cầu từ khách hàng  Tiêu chí diễn đạt nội dung : S.M.A.R.T  Có tương tác để kiễm chứng (vd: làm mẫu thử) 2. Khẳng định trách nhiệm thực hiện yêu cầu  Bằng tiến trình cam kết 3. Gắn yêu cầu vào kế hoạch thực hiện, để theo dõi việc thực hiện (tracking & oversight)  Ngăn 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 4. Kiễm soát các thay đổi của yêu cầu  Nhận biết sự thay đổi trên yêu cầu (vd: version), và sự thay đổi tương ứng bên trong phần mềm  Cân nhắc chi phí thực hiện & lợi ích từ sự thay đổi 10 Tiến trình cam kết Yêu cầu Khả năng Kế hoạch thực hiện(BPP) Mục tiêu Nguồn lực Phương án & rủi ro Y/c Khả thi Nơi phát sinh yêu cầu   Kết quả thực hiện Người thực hiện Trợ giúp   1. Nhận biết yêu cầu từ khách hàng, users hoặc stack-holders 2. Xem xét khả năng thực hiện yêu cầu từ phía dự án 3. Xem xét khả năng thực hiện yêu cầu 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 11 Nghiên cứu khả thi Mục đích: xác định vai trò & ý nghĩa của PM trong môi trường vận hành (ie, hệ thống lớn), và khả năng thực hiện yêu cầu từ dự án. Nội dung: trả lời các câu hỏi 1. PM sẽ giúp được gì cho users / tổ chức ? 2. PM có hiện thực được không, với các hổ trợ hiện có (vd: công nghệ) trong giới hạn cho phép về chi phí và thời gian ? 3. PM có vận hành được chung với các PM khác trong môi trường hiện tại không ? 4. Có phương án khả thi được xem xét từ nhiều phương diện : kỹ thuật, kế hoạch, chi phí,? 12 Quản lý các thay đổi yêu cầu13 Software_Requirements, 3rd edition, 2013.pdf: Page 18 Dự án: Quản lý yêu cầu  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 (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 của tiền dự án: 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 (Project Plan, hoặc BPP). 14 Project Charter15 1. 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 mà các bên có liên quan phải tuân thủ. 2. Nó được các key-person (  stackholders) 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 được dẫn xuất từ charter này.  Quá trình thực hiện dự án là chuổi các hành động phát hiện, hiệu chỉnh các yêu cầu và tìm giải pháp Project Charter-Nội dung16 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 n 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 thực hiện yêu cầu của dự án 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 stake-holders đố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 dự án 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ó). 17 a) Lập hồ sơ dự thầu 1. Mọi yêu cầu đều phải có phương án khả thi & các phương án được xem xét từ 2 phía (tiến trình cam kết). 2. Mọi yêu cầu được nêu rõ và lập tài liệu (cho từng phiên bản, để có thể thay đổi). 3. Thiết lập quan hệ giữa khách hàng & dự án để hợp tác thực hiện, gồm 1. Thiết lập các kênh thông tin liên lạc; 2. Cách thức nêu yêu cầu & thay đổi yêu cầu; 3. Cách thức chuyển giao và tiêu chí đánh giá; 4. Cách kiểm thử và thông báo lỗi; 5. Cách kết thúc từng giai đoạn (nghiệm thu). 18 b) Lập hợp đồng 1. Hợp đồng có yêu cầu rõ ràng, đầy đủ, không thừa và hoàn toàn khả thi Mọi sự hiểu biết về nội dung dự án (yêu cầu chức năng, vấn đề tài chính, mong muốn của tác nhân, giải pháp của yêu cầu,) đều được thể hiện trong bản hợp đồng hoặc phụ lục hợp đồng. 2. Mọi sự thay đổi, thêm hoặc bớt trên nội dung hợp đồng đã ký, đều phải được thảo luận và đồng ý giữa các bên. Thay đổi nội dung hợp đồng (cập nhật, nâng cấp sản phẩm) cũng cần có cách thức và điều khoản 19 c) Lập hợp đồng phụ  Phạm vi trách nhiệm của các hợp đồng phụ nhỏ hơn so với hợp đồng chính, nhưng nó lại góp phần tạo ra chất lượng cho hợp đồng chính, do đó: 1. Cần nhận biết sớm và đầy đủ các nguy cơ trễ hạn từ hợp đồng phụ làm trễ hạn hợp đồng chính. 2. Bảo đảm mức chất lượng hợp lý trên các phần việc outsource để làm thoả mãn yêu cầu của hợp đồng chính. 3. Bảo đảm đủ tài liệu để bảo trì các sản phẩm được chuyển giao từ hợp đồng phụ 20 Kế hoạch hợp tác 1. Thể hiện đầy đủ và đúng thực tế về nội dung thực hiện hợp đồng. 2. Tường trình chi tiết về thời gian, nguồn lực và rủi ro của các công việc đang thực hiện. 3. Có đáp ứng cho các thay đổi của hợp đồng. 4. Cảnh báo các khó khăn trong quá trình thực hiện: thiếu hụt nguồn nhân lực chuyên môn, các phương tiện, các milestones, các rủi ro, vv 21 2.Khám phá yêu cầu CMMI –L3: Phát triễn yêu cầu (Requirement Development, RD) Phát triễn yêu cầu : là những hành động khám phá yêu cầu từ hệ thống, phát triễn các yêu cầu ban đầu thành yêu cầu chi tiết cho từng công đoạn làm phần mềm và kiễm chứng sự phù hợp của yêu cầu trong thực tế.  Ie, chi tiết hoá yêu cầu theo quan điểm tạo sản phẩm CMMI DEV-V1.3 (2010).pdf Page 341 & 325 22 CMMI-L3: Phát triễn yêu cầu (RD) 1. Thấu hiểu yêu cầu đ/v phần mềm Khám phá (tìm hiểu căn kẽ) yêu cầu từ mong muốn về phần mềm (users) và những thứ có liên quan đến phần mềm, theo quan điểm hệ thống. 2. Chi tiết hóa yêu cầu thành đặc tả cho việc phát triễn sản phẩm phần mềm Phiên dịch yêu cầu đ/v PM (nhìn từ quan điểm sử dụng) thành đặc tả thiết kế, lập trình, kiễm thử,.. (quan điểm xây dựng, tạo sản phẩm) 3. 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; Chỉ ra sự phù hợp của bản thiết kế với các môi trường nghiệp vụ, vận hành, phát triễn PM. 23 Chi tiết hóa yêu cầu  Là sự cụ thể hóa yêu cầu đ/v sản phẩm phần mềm thành đặc tả chi tiết trong các mức phát triễn phần mềm (mức thiết kế, mức lập trình)  Yêu cầu đối với PM được thể hiện thành các đặc tả cho PM ngày càng rõ dần (cụ thể hơn) trong quá trình hiện thực ý tưởng thành sản phẩm PM (mô hình làm PM).  Theo CMMI v1.3, có 3 mức chi tiết: 1. User requirement: yêu cầu từ môi trường vận hành của phần mềm 2. Product requirement (hoặc system requirements): yêu cầu để sản phẩm PM sẽ dùng được tốt trong môi trường vận hành (external view) 3. Product-component requirement: yêu cầu cho từng môđun bên trong PM (đặc tả của thiết kế, internal view) 24 Chi tiết hóa yêu cầu từ ISO-9126 SW spec. External quality requirement Internal quality requirement User quality needs Req.Elicitation User’s view Dev ‘s view (ISO 9126-1) Req.Development Product requirements Component requirements User’s requirements Trace (vết) Đặc tả (yêu cầu) Yêu cầu ở các mức có liên kết nhau (trace) 25 Dò vết của các yêu cầu  Vết (trace): chỉ ra nguồn gốc (ie, đặc tả đã biết) phát sinh ra các đặc tả mới.  vd: giải thuật (là đặc tả mới) được đưa ra để thực hiện một chức năng được yêu cầu (là đặc tả đã biết)  Nó liên kết các đặc tả giữa các mức phát triễn (phân tích, thiết kế, lập trình,..)  Việc dò vết yêu cầu giữa các mức là để bảo đảm tính liên kết nhất quán & mạch lạc (dễ hiểu) giữa các bộ tài liệu đặc tả cho quá trình phát triễn và cập nhật phần mềm  Dò vết từ hồ sơ phân tích → hồ sơ thiết kế → mã nguồn & cấu trúc dữ liệu  Tracing dùng cho phát triễn lẫn kiễm thử phần mềm 26 Các khía cạnh để dò vết  Toàn diện (coverage): các đặc tả được đưa ra ở các mức chi tiết (ie, giải pháp ) có đáp ứng được trọn vẹn mọi đặc tả ở mức bên trên (ie, yêu cầu ) không ?  Ý nghĩa: phát hiện sự thiếu sót (không đủ) của đặc tả mới  Tác động (impact): Nếu thay đổi (phát sinh, sửa, hủy) một đặc tả ở mức bên trên, thì những đặc tả nào ở mức chi tiết sẽ bị ảnh hưởng (cần phải thay đổi theo) ?  Ý nghĩa: chỉ ra phạm vi bị tác động bởi sự thay đổi yêu cầu  Dẫn xuất (derivation): một đặc tả ở mức chi tiết được sinh ra từ đặc tả nào ở mức trên (ie, phải có lý do để tồn tại), và tại sao nó lại nằm ở mức này ?  Ý nghĩa: phân hoạch các đặc tả vào từng mức phát triễn cho phù hợp với nội dung thực hiện của từng mức. 27 Dò vết trong xây dựng đặc tả Im pact analysis D er iv at io n an al ys is User’s requirements Product requirements Component requirements Coverage Impact: Những đặc tả chi tiết nào sẽ bị ảnh hưởng bởi sự thay đổi của 1 đặc tả ở mức cao hơn ? Derivation: Những đặc tả chi tiết nào là cần thiết, và nó cần nằm ở mức nào ? Coverage: Đặc tả chi tiết đã đầy đủ chưa ? Requirements Engineering, 2nd Edition - 2005.pdf 28 Dò vết trong kiễm thử đặc tả (V-model) User’s requirements Product requirements Component requirements Acceptance Test cases System Test cases Component Test cases C o verage Impact analysis Derivation analysis Coverage: Các test-cases đã được định nghĩa đủ chưa ? 29 Kiễm chứng yêu cầu  Là hành động chứng minh rằng các đặc tả yêu cầu đ/v PM phản ánh đúng “mong đợi” từ môi trường mà nó sẽ được phát triễn & vận hành.  Mong đợi: được phát biểu từ những tác nhân  Các 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 trong suốt chu kỳ sống của nó, để khẳng định rằng các đặc tả là cần thiết, và đầy đủ.  Phương pháp:  Revew, Làm mẫu thử  Định nghĩa các tiêu chí nghiệm thu  Kiễm thử yêu cầu (để phát hiện sai)  Giả lập các yêu cầu (để phát hiện thiếu) 30 Dự án: Khảo sát & phân tích Khảo sát hiện trạng là một hệ thống các công việc đưa ra nhận định về bối cảnh phát sinh vấn đề, yêu cầu và giải pháp để giải quyết vấn đề mà PM sẽ hổ trợ thực hiện.  Xem xét: nhu cầu sử dụng PM từ môi trường nghiệp vụ, khả năng triễn khai áp dụng PM từ môi trường vận hành, cách thức xây dựng PM trong môi trường phát triễn từ khía cạnh học thuật, mô hình phát triễn, công nghệ và chuẩn để đưa ra nhận định về vấn đề và giải pháp.  Theo dõi sự thay đổi trong các môi trường này; vì chúng có thể làm thay đổi yêu cầu ban đầu (UP/RUP: giám sát môi trường & quản lý cấu hình) 31 Dự án: Thiết kế phần mềm 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 cho các vấn đề đã biết, đó là các đặc tả chi tiết để 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, flat-forms, giao tiếp với các hệ thống khác, ) 32 Yêu cầu & giải pháp trong dự án (1)33  Yêu cầu dùng để xây dựng các giải pháp, mà sau cùng là PM → phát hiện yêu cầu đúng và đầy đủ cho PM càng sớm càng tốt. 1. Yêu cầu đúng là yêu cầu từ bản chất của vấn đề, không hoặc ít thay đổi (invariances). 2. Tạo điều kiện cho users tiếp cận sớm với PM (user involvement) để nhận được tư vấn thiết thực. Yêu cầu & giải pháp trong dự án (2)34  Xem xét toàn diện các khía cạnh phát triễn, vận hành, tiến hóa của PM để đưa ra yêu cầu bằng cách phối hợp nhiều chuyên gia.  Tổ chức cuộc họp / forum / workflow  Ý kiến từ người sử dụng được ưu tiên, vì nó thường diễn tả yêu cầu từ tổ chức (nghiệp vụ, môi trường vận hành, hiệu quả dùng tài nguyên,..), tuy nhiên họ chỉ giải quyết vấn đề trước mắt, 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,... ) Yêu cầu & giải pháp trong dự án (3)35  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ý → cần mô tả hành vi của chúng một cách trực quan để các tác nhân (users, devs, managers) dể tiếp thu.  Bằng các lược đồ (DFD,UMLs)  Bằng CASE tools: Rational Rose/ Power Designer/Oracle Designer,..) làm mẫu thử bỏ đi (throw-away prototype)  Agile: Bằng chính source code đang làm Yêu cầu & giải pháp trong dự án (4)36  Lỗi rất khó phát hiện → việc kiểm thử PM cần được thực hiện sớm, để tránh gây hậu quả (làm lại, rework) sau này. 1. Các công đoạn ban đầu (phân tích, thiết kế, lập trình) đều cần kiểm thử 2. Xác định các test cases trước khi đặc tả nội dung xử lý một chức năng. 3. Đặc tả tổng quát cần phải kiểm thử (và sửa cho đúng) trước đặc tả chi tiết (top down approach) 4. Tự động hóa việc kiểm thử là rất cần thiết. Yêu cầu & giải pháp trong dự án (5)37  Tài liệu phát triễn PM phải được mô tả một cách có hệ thống; sự truyền đạt yêu cầu thành giải pháp là 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 những 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) Yêu cầu & giải pháp trong dự án (6)38  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 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 tính sẽ được cài đặt vào PM bằng mô hình McCall, ISO9126, hoặc ISO 25010,..  Xem xét đồng thời yêu cầu chức năng & tính năng của PM để quyết định cách thức cài đặt các chức năng này (vd: chọn giải thuật phù hợp). Xem xét bản thiết kế: ý nghĩa 1. Để phát hiện lỗi phân tích, lỗi thiết kế cũng như các nội dung mà trong đó sự hoàn thiện, thay đổi hoặc sửa chữa phải làm thỏa mãn cho đặc tả ban đầu, và phải được chấp thuận. 2. Để phát hiện rủi ro ảnh hưởng đến dự án. 3. Để tìm sự lệch chuẩn chất lượng  Sửa chữa những sai lệch này dự kiến sẽ góp phần cải thiện giao tiếp & phối hợp thực hiện nhờ tính nhất quán & phổ biến của chẩn. 4. Để phê duyệt bản phân tích, thiết kế sản phẩm, cho phép nhóm dự án tiếp tục thực hiện giai đoạn tiếp theo. 39 Các phương pháp xem xét bản thiết kế 1. Peer review : để hoàn thiện bản thiết kế 2. Formal design review : để phê duyệt thiết kế, 3. Expert opinion: để được tư vấn thêm. 40