Bài 2. quy trình phát triểnphần mềm

BÀI 2. QUY TRÌNH PHÁT TRIỂNPHẦN MỀM Nội dung: 2.1. Quy trình phát triển phần mềm 2.2. Thực trạng của quá trình phát triển phần mềm 2.3. Quá trình nghiên cứu đặc tả phần mềm * * 2.1. QUY TRÌNH PHÁT TRIỂNPHẦN MỀM Giới thiệu: Nội dung: 2.1.1. Các thành phần của phần mềm 2.1.2. Nhân lực của một dự án 2.1.3. Mô hình phát triển phần mềm * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các tài liệu của quá trình phát triển PM: Yêu cầu của khách hàng Đặc tả sản phẩm * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các tài liệu của quá trình phát triển PM: Yêu cầu của khách hàng Đặc tả sản phẩm Kế hoạch làm việc Biểu đồ Gantt * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các tài liệu của quá trình phát triển PM: Yêu cầu của khách hàng Đặc tả sản phẩm Kế hoạch làm việc Tài liệu thiết kế phần mềm phần mềm nhỏ cũng được design Phụ thuộc vào nhiều yếu tố Một số tài liệu: * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các tài liệu của quá trình phát triển PM: Yêu cầu của khách hàng Đặc tả sản phẩm Kế hoạch làm việc Tài liệu thiết kế phần mềm Một số tài liệu: Architecture Data flow diagram State transition diagram commented code * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các tài liệu của quá trình phát triển PM: Yêu cầu của khách hàng Đặc tả sản phẩm Kế hoạch làm việc Tài liệu thiết kế phần mềm Tài liệu kiểm thử Test plan Test case list Bug report Test tool * * 2.1.1. THÀNH PHẦN CỦA PHẦN MỀM Các thành phần tạo nên một sản phẩm phần mềm: Help files User's manual Samples and examples Labels and stickers Product support info Icons and art Error messages Ads and marketing material Setup and installation Readme file * * 2.1.2. NHÂN LỰC CỦA DỰ ÁN Tuy thuộc vào công ty, dự án thành phần này còn thay đổi Cơ bản, gồm các thành phần: Project managers, program managers, hoặc producers Architects or system engineers Programmers, developers, or coders Testers hoặc Quality Assurance Technical writers, user assistance, user education, manual writers, or illustrators Configuration management or builder * * 2.1.3. MÔ HÌNH PHÁT TRIỂN PHẦN MỀM Không có một mô hình nào là tốt nhất, tùy thuộc vào phần mềm để lựa chọn mô hình phù hợp Các mô hình phát triển phần mềm: Big – bang Code – and – fix Waterfall Spiral * * BIG - BANG Tuân theo học thuyết tạo ra vũ trụ từ vụ nổ Big – bang. Tất cả nỗ lực dành cho việc viết code * * BIG - BANG Tuân theo học thuyết tạo ra vũ trụ từ vụ nổ Big – bang. Tất cả nỗ lực dành cho việc viết code Áp dụng khi: Spec không tốt Hạn hoàn thành phần mềm đã đến gần Khách hàng là những người dễ thuyết phục * * BIG - BANG Tuân theo học thuyết tạo ra vũ trụ từ vụ nổ Big – bang. Tất cả nỗ lực dành cho việc viết code Áp dụng khi: Ưu: rất đơn giản Nhược: Khách hàng không được biết gì về sản phẩm cho đến khi nó hoàn thành Sau khi code xong mới diễn ra quá trình testing * * CODE – AND – FIX Ý tưởng: * * CODE – AND – FIX Ý tưởng: Áp dụng: Với các dự án nhỏ Khi sản phẩm được tung ra thị trường trong một thời gian ngắn Ưu: - Nhanh, tốn ít chi phí Nhược: Chưa kịp test xong version cũ đã lại update version mới Một số đặc trưng bị bỏ qua => rủi ro * * WATERFALL Ý tưởng: Xác định rõ mục tiêu của dự án Các bước tiến hành độc lập, không có sự chồng chéo Không được phép back up (giai đoạn trước hoàn thành mới được phép tiến hành tiếp giai đoạn sau) * * WATERFALL Ý tưởng: Áp dụng: Mô hình áp dụng tốt với những dự án well-understood product Với một đội project team làm việc rất chặt chẽ và kỷ luật * * WATERFALL Ưu điểm: Đây là một mô hình tương đối tổng quát Mọi thứ được xác định cận thận và chặt chẽ Khi bàn giao cho các tester , phần mềm đã khá hoàn chỉnh, và sẽ không thay đổi gì cho đến khi kiểm thử xong => thuận lợi cho các tester lập kế hoạch, và thực hiện test. * * WATERFALL Nhược điểm: Trong thời đại ngày nay, mọi thứ đều thay đổi rất nhanh => Nếu quá cận trọng, đôi khi phần mềm sẽ không theo kịp sự thay đổi Khi bàn giao cho các tester , phần mềm đã khá hoàn chỉnh => nếu có một lỗi xuất hiện từ rất sớm, nhưng đến giai đoạn cuối này mới phát hiện => chi phí để fix lỗi là rất lớn * * WATERFALL Chú ý: Trong thực tế: các dạng biến thể của waterfall được áp dụng (một số quy tắc được nới lỏng) Không có sự chồng chéo các giai đoạn Có thể back up được * * SPIRAL Ý tưởng: Ra đời năm 1986 bởi Barry Boehm Không xác định mọi thứ một cách chi tiết từ khi bắt đầu Các giai đoạn lặp đi lặp lại cho đến khi thu được sản phẩm cuối cùng * * SPIRAL Mỗi lần lặp của Spiral gồm 6 bước: Determine objectives, alternatives, and constraints. dentify and resolve risks. Evaluate alternatives. Develop and test the current level. Plan the next level. Decide on the approach for the next level. * * SPIRAL Ưu điểm: Mô hình dễ hiểu và dễ thực hiện Có rất nhiều dự án đã thành công với mô hình này Nhược điểm: Spiral không được phân tích kỹ lưỡng ngay từ đầu nên đôi khi hệ thống được xây dựng chưa triệt để Đôi khi khó kiểm soát kế hoạch làm việc * * TỔNG KẾT Bây giờ bạn phải hiểu sản phẩm phần mềm tạo ra như thế nào, cái gì bên trong chúng và quy trình được sử dụng để liên kết chúng với nhau. Ngoài 4 mô hình mô tả ở đây, còn nhiều mô hình khác nữa và biến thể của chúng. Mỗi công ty, mỗi dự án và mỗi đội sẽ chọn mô hình phù hợp với họ. Công việc của tester là kiểm tra phần mềm để nó làm việc tốt nhất trong mô hình phát triển của nó. * * 2.2. THỰC TRẠNG CỦA QUÁ TRÌNH SOFTWARE TESTING Nội dung: 2.2.1. Phương châm của việc kiểm thử phần mềm 2.2.2. Định nghĩa và thuật ngữ của quá trình kiểm thử phần mềm 2.2.3. Mô hình chữ V * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm (ST): (“rules of the road” hay “facts of life”) Tester đảm bảo 1 chương trình là hoàn hảo là điều không thể thực hiện được. Vì: Số lượng các dữ liệu có thể là input là rất lớn Số lượng các dữ liệu có thể là output cũng vô cùng lớn Số lượng các “lối đi” (path) trong phần mềm là rất lớn Đặc tả phần mềm có tính chất chủ quan. Bạn có thể nói rằng lỗi là những khuyết điểm dưới con mắt của độc giả. Ví dụ: một phần mềm đơn giản Microsoft Windows Calculator * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Testing là 1 bài kiểm tra phụ thuộc vào sự rủi ro Nếu không kiểm tra hết các trường hợp => sẽ đến lúc khách hàng phát hiện ra những lỗi bị bỏ quên => chi phí để khắc phục là rất lớn Do vấn đề về thời gian, kinh phí và tính khả thi => không thể test được hết các trường hợp => rủi ro Lựa chọn những trường hợp test ít rủi ro nhất => đâu là vấn đề quan trọng? * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Testing là 1 bài kiểm tra phụ thuộc vào sự rủi ro Nếu cố kiểm tra mọi thứ => chi phí quá lớn Nếu cắt giảm công việc kiểm thử => bỏ quên nhiều lỗi Vậy, phải lựa chọn được các trường hợp kiểm thử tối ưu => đảm bảo không phải kiểm thử quá nhiều hay quá ít => optimal amount of testing * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Testing không thể tìm thấy những lỗi không tồn tại? Các hình thức của lỗi: đang tồn tại (live bug) đã được sửa (dead bug) hoặc còn đang tiềm ẩn (nest) Nếu bạn đã cố gắng kiểm tra nhưng không tìm thấy lỗi => không có nghĩa là phần mềm không có lỗi => kết luận: lỗi chưa được phát hiện * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Một số lỗi được phát hiện, tự đó tester suy luận ra một số lỗi khác: Lập trình viên cũng có lúc làm việc tốt, cũng có lúc không được minh mẫn Lập trình viên cũng mắc lỗi theo thói quen Tester phát hiện ra 1 số lỗi, tưởng rằng chúng không có quan hệ với nhau => nhưng chúng lại đều xuất phát từ cùng 1 lỗi rất nguy hiểm * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: The Pesticide Paradox: Thuật ngữ này dùng để mô tả việc tìm lỗi phần mềm giống như việc dùng thuốc trừ sâu (Pesticide) diệt côn trùng * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Không phải tất cả các lỗi mà bạn phát hiện sẽ được sửa không có nghĩa rằng: bạn đã làm sai, hay bạn sẽ giao cho khách hàng 1 sản phẩm kém chất lượng => lựa chọn sửa những lỗi chứa nhiều rủi ro nhất Một số lý do khiến lỗi không được fix: Không đủ thời gian Không hẳn là lỗi Có quá nhiều rủi ro khi sửa lỗi Không đáng để phải sửa * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Không phải tất cả các lỗi mà bạn phát hiện sẽ được sửa Những người đưa ra quyết định lỗi nào được fix: Tester project manager Coder Ví dụ: Lỗi của Intel Pentium năm 1994 * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Một “vấn đề” tồn tại nhưng không ai phát hiện, hoặc không được chú ý tới: Có được gọi là lỗi không? Duyệt theo 5 quy tắc phát hiện lỗi Latent bug * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Xây dựng spec là công việc không bao giờ kết thúc Mọi thứ luôn thay đổi mau lẹ => Spec cũng phải biến đổi linh hoạt Ví dụ: Các feature thay đổi liên tục, không trong kế hoạch => bạn đã test xong, và sẵn sàng báo cáo lỗi, những feature lại thay đổi hoàn toàn Cần có kỹ thuật kiểm thử linh hoạt * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: Tester không phải là thành viên được coder chờ đợi trong một dự án Nhiệm vụ của 1 tester là gì? Tester phê bình công việc của đồng nghiệp, công khai những vấn đề tìm thấy, cố gắng chiến thắng trong các cuộc tranh luận Tester cần giữ thái độ hòa bình với đồng nghiệp: Phát hiện lỗi thật sớm Giữ thái độ hăng hái nhiệt tình Đừng chỉ báo cáo những thông tin xấu * * 2.2.1. PHƯƠNG CHÂM CỦA VIỆCKIỂM THỬ Chân lý của quá trình kiểm thử phần mềm: ST là một công việc đòi hỏi tính kỷ luật cao Tester trở thành lực lượng lòng cốt, những thành viên sống còn trong nhiệm vụ xây dựng các phần mềm có chất lượng cao Tester trở thành một nghề nghiệp được nhiều người lựa chọn và cần phải được đào tạo Tester làm việc có kỷ luật và thúc đẩy sự tiến bộ. * * 2.2.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ CỦA ST Phân biệt các thuật ngữ: Precision (tập chung) và accuracy (chính xác) Verification (sự kiểm tra) và Validation (sự xác nhận) Quality (chất lượng) và reliability (sự tin cậy) Testing (Kiểm thử) và quality assurance (đảm bảo chất lượng) (QA) * * 2.2.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ CỦA ST Precision (tập chung) và accuracy (chính xác): Hình trên mô tả sự khác nhau giữa 2 thuật ngữ Ví dụ: Kiểm tra yêu cầu về tính precision và accuracy trên phần mềm Calculator * * 2.2.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ CỦA ST Verification (sự kiểm tra) và Validation (sự xác nhận): Vào 4/1990, Kính thiên văn không gian Hubble được đưa vào quỹ đạo quanh trái đất Verification: kiểm tra bản đặc tả đã chính xác chưa Validation: Cần thực hiện việc xác nhận lại sản phẩm cuối cùng so với bản đặc tả * * 2.2.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ CỦA ST Quality (chất lượng) và reliability (sự tin cậy): Dường như 2 khái niệm này là tương tự nhau: 1 sản phẩm Reliability là 1 sản phẩm Quality Nhưng, Reliability chỉ là 1 khía cạnh của Quality Sản phẩm Quality: Sự thoải mái của các feature Dịch vụ hậu mãi Có thể chạy trên các PC cấu hình thấp Giá cả của sản phẩm Sản phẩm Quality và Reliability thì phải thực hiện verification và validation trong suốt quá trình phát triển sản phẩm * * 2.2.2. CÁC ĐỊNH NGHĨA VÀ THUẬT NGỮ CỦA ST Testing (Kiểm thử) và quality assurance (đảm bảo chất lượng) (QA): Mục đích của testing là tìm ra lỗi, tìm thấy chúng sớm nhất có thể, và đảm bảo rằng chúng đã được sửa. Trách nhiệm chính của người QA là tạo và bắt phần mềm phải tuân theo các chuẩn để cải tiến quy trình phát triển phần mềm và ngăn chặn các lỗi xuất hiện bất cứ lúc nào 2 khái niệm này có sự chồng chéo Chúng có mỗi quan hệ mật thiết với nhau * * URS 2.2.3. MÔ HÌNH CHỮ V 2.3. QUÁ TRÌNH NGHIÊN CỨU ĐẶC TẢ PHẦN MỀM 2.3.1. Kiểm tra đặc tả ở mức cao 2.3.2. Kiểm tra đặc tả ở mức thấp * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Bước đầu là xem xét spec ở mức cao => nghiên cứu chi tiết từng vấn đề => để hiểu rõ hơn về phần mềm và chức năng của nó => yêu cầu sửa những điểm chưa hợp lý => phục vụ cho quá trình kiểm thử * * Nếu bạn là một khách hàng: Tester xác định đối tượng sử dụng sản phẩm là ai? Tester không nhất thiết phải là chuyên gia trong lĩnh vực của phần mềm Nhưng nếu tester có hiểu biết về lĩnh vực đó => thuận lợi cho quá trình test Bạn buộc phải hiểu rõ được bản đặc tả Lưu ý tới khả năng bảo mật của phần mềm (dù khách hàng có thể tuyệt đối tin tưởng) * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Nghiên cứu về những Standard và Guideline Thời kỳ đầu của Microsoft Windows và Apple Macintosh: => xây dựng lên các standard và guideline Standard là chuẩn đã được thông qua => bắt buộc phải tuân theo Guideline là những hướng dẫn, không bắt buộc, nhưng cũng nên tuân theo * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Nghiên cứu về những Standard và Guideline Khi xây dựng một phần mềm, một số Standard và Guideline sẽ được lựa chọn: Các thuật ngữ và các quy ước của các tổ chức (Corporate Terminology and Conventions) Nhu cầu của ngành công nghiệp (Industry Requirements) Chuẩn về chính quyền (Government Standards) Giao diện đồ họa người dùng (Graphical User Interface – GUI) Tiêu chuẩn về sự bảo mật (Security Standards) * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Nghiên cứu về những Standard và Guideline Lựa chọn các standard và guideline là công việc của các người quản lý hoặc người viết bản đặc tả Tester phải hiểu về các standard và guideline này, và xác minh lại xem nó được áp dụng trên phần mềm như thế nào (coi chúng như 1 phần của bản đặc tả) * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Kiểm tra những phần mềm tương tự Cách thức tốt nhất để tìm hiểu cái mà phần mềm của bạn cần đạt đến là nghiên cứu những phần mềm tương tự Một số điểm cần xem xét trên các phần mềm cạnh tranh: Tỷ lệ (scale): feature, code Sự phức tạp (complexity) Khả năng kiểm thử (testability): thời gian, chuyên môn, tài nguyên Chất lượng / tính tin cậy (quality / reliability) Bảo mật (security) * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Kiểm tra những phần mềm tương tự Những kinh nghiệm trên các phần mềm tương tự => rất có ích cho quá trình kiểm tra bản đặc tả Đánh giá độ bảo mật của các phần mềm tương tự => so sánh => đựa ra mức độ bảo mật phù hợp * * 2.3.1. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC CAO Danh mục những thuộc tính của bản đặc tả Những thuật ngữ của bản đặc tả * * 2.3.2. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC THẤP Danh mục những thuộc tính của bản đặc tả: Hoàn thiện (complete): Chính xác (accurate): Rõ ràng, chính xác, không mập mờ và trong sáng (Precise, Unambiguous, and Clear): Nhất quán (consistent): Mối quan hệ (relevant): Khả thi (Feasible): Mã nguồn mở (code - free): Khả năng kiểm thử (testable): * * 2.3.2. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC THẤP Những thuật ngữ của bản đặc tả Luôn luôn, mọi thứ, tất cả, không một ai, không bao giờ (Always, every, all, none, never) Tất nhiên, bởi vậy, chắc hẳn rồi, hiển nhiên, rõ ràng (Certainly, Therefore, Clearly, Obviously, Evidently) Vân vân, và cứ tiếp tục ở phía trước, và cứ tiếp tục như vậy, ví dụ (Etc., And So Forth, And So On, Such As) * * 2.3.2. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC THẤP Những thuật ngữ của bản đặc tả Tốt, nhanh, rẻ, hiệu quả, nhỏ gọn, ổn định (Good, Fast, Cheap, Efficient, Small, Stable) Danh hiệu, quy trình, loại bỏ, bỏ qua, loại trừ (Handled, Processed, Rejected, Skipped, Eliminated) Nếu … thì … nhưng không có trường hợp còn lại (If…Then…but missing Else) * * 2.3.2. KIỂM TRA BẢN ĐẶC TẢ Ở MỨC THẤP TỔNG KẾT Đây là cuốn sách giới thiệu những người muốn nhanh chóng có thể kiểm thử được một bản đặc tả. Những nội dung được mô tả ở phần này sẽ là cánh tay đắc lực trợ giúp tìm ra những khuyết điểm trong những bản đặc tả mà bạn phải kiểm thử. Dạng của bản đặc tả có thể rất rộng. Bạn nên áp dụng những kỹ thuật trong chương này, kiểm tra một sơ đồ mức cao, phân tích những cú pháp câu. Bạn sẽ tìm thấy lỗi. Bạn muốn tìm hiểu nhiều kỹ thuật mở rộng: www.mfagan.com. * * BÀI 2. CÂU HỎI Tên một số nhiệm vụ sẽ được thực thi trước khi lập trình viên viết các dòng code đầu tiên với từng mô hình? Bạn sẽ gặp phải những khó khăn nào nếu bạn muốn xây dựng một bản đặc tả chính thức và chốt lại bản đặc tả đó (formal, locked-down specification)? * * BÀI 2. CÂU HỎI Đâu là feature tốt nhất của mô hình big – bang? Khi sử dụng mô hình code – and – fix, phần mềm như thế nào là đủ để giao tới tay khách hàng? Tại sao mô hình waterfall khó sử dụng? Tại sao các tester thích mô hình spiral hơn các mô hình khác? * * BÀI 2. CÂU HỎI Bắt đầu với Windows Calculator. Hãy gõ vào 5,000 – 5 = (dấu phẩy là rất quan trọng). Và nhìn kết quả. Đây có phải là lỗi không? Tại sao có và tại sao không? Có thể tồn tại một sản phẩm có quality nhưng lại không có reliability? Hãy lấy ví dụ? Hãy giải thích một tester nên lo ngại điều gì với dòng đặc tả như sau: Phần mềm sẽ cho phép trên 100 triệu kết nối đồng thời, mặc dù bình thường sẽ không có nhiều hơn 1 triệu kết nối. * *