tìm hiểu môn công nghệ phần mềm

• Câu hỏi 2: Hãy chọn một mô hình phát triển phần mềm thích hợp nhất cho việc phát triển hệ thống sau, nêu ra những tiến trình cơ bản của mô hình này: một hệ thống quản lý tài sản của mộ

Tìm hiểu môn Công nghệ phần mềm

Mr Hoàng & Mr Thành

Group 06T1 CVA University

• Câu hỏi 1: Hãy giải thích làm thế nào để cả hai

mô hình: mô hình tuyến tính (waterfall) và mô hình mẫu (prototyping) có thể kết hợp trong mô hình xoắn ốc

• Câu hỏi 2: Hãy chọn một mô hình phát triển phần mềm thích hợp nhất cho việc phát triển hệ thống sau, nêu ra những tiến trình cơ bản của mô hình này: một hệ thống quản lý tài sản của một doanh nghiệp

Các giai đoạn trong quy trình

phát triển một phần mềm

• Giai đoạn định nghĩa: Phân tích hệ thống (system

engineering), hoạch định đề tài (software project management), phân tích yêu cầu (requirement analysis)

• Giai đoạn phát triển: Thiết kế phần mềm (software

design), sinh mã (code generation), kiểm tra phần mềm (software testing)

• Giai đoạn bảo trì: Sửa lỗi (correction), thay đổi

môi trường thực thi (adaptation), tăng cường (enhancement)

Để sản xuất cùng một sản phẩm phần mềm người ta có thể dùng các mô hình khác nhau.

Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng.

Tìm hiểu về 3 mô hình

• Mô hình tuyến tính (Waterfall Model)

• Mô hình mẫu (Prototype Model)

• Mô hình xoắn ốc (Spiral Model)

• Sự kết hợp giữa hai mô hình: mô hình tuyến tính

và mô hình mẫu trong mô hình xoắn ốc

Mô hình tuyến tính (Waterfall)

Requiments and

Specifications

System Analysis and Design

Test

Coding and Unit Test

Deployment and Maintainance

Người sử dụng hệ thống và nhà phát triển

hệ thống bàn bạc, trao đổi với nhau để xác định hệ thống sẽ làm gì, đưa ra các yêu chức năng và phi chức năng cần phải được đáp ứng Kết quả là bản đặc tả hệ

thống và yêu cầu chi tiết.

Phân tích và mô hình hóa các chức năng

mà phần mềm cần thực hiện Làm thế nào

để hệ thống phần mềm đáp ứng những đòi hỏi mà khách hàng đưa ra trong bản đặc tả chi tiết? Là cầu nối giữa đặc tả và code.

Trong giai đoạn này các đơn vị chương trình hay tập hợp các chương trình được kiểm thử lần lượt sao cho thoả mãn các đặc tả và các yêu cầu tương ứng Thực hiện theo cấu trúc được chỉ ra trong giai đoạn Requiments and Specifications

Kiểm thử mã (code) đã được hiện thực Kiểm thử tích hợp cho nhóm các thành phần Kiểm thử toàn hệ thống (system test).

Khâu kiểm thử cuối cùng: Nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.

Cài đặt, cấu hình và huấn luyện khách hàng.

Sửa chữa những lỗi của phần mềm (nếu có).

Phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng, đặc điểm của hệ thống.

Đánh giá mô hình:

Có lặp sau mỗi bước

Số lượng lặp có giới hạn Linh hoạt nhưng khó quản lý Thực tế cho thấy đến những giai đoạn sau mới có khả năng nhận ra sai sót trong những giai đoạn trước và phải quay lại để sửa chữa.

Mô hình tuyến tính (Waterfall)

Requiments and

Specifications

System Analysis and Design

Test

Coding and Unit Test

Deployment and Maintainance

Ưu điểm:

Đơn giản, dễ hiểu Các giai đoạn được đĩnh nghĩa với đầu vào và đầu ra rõ ràng.

Việc kiểm định gắn liền với từng đoạn Sản phẩm hình thành thông qua chuỗi các hoạt động xây dựng theo trình tự rõ ràng.

Mô hình mẫu (Prototyping)

Xây dựng Prototype

Thảo luận với khách hàng

Đánh giá Của khách hàng

Yêu cầu sơ lược (Outline requirements)

Làm mẫu (Prototype)

Waterfall

Mô hình mẫu (Prototyping)

• Prototype như là một cơ chế để nhận diện chính xác yêu cầu của khách hàng Thu thập yêu cầu với

sự có mặt của đại diện của cả phía phát triển lẫn khách hàng nhằm định ra mục tiêu tổng thể của hệ thống phần mềm

• Ý tưởng: xây dựng các prototype để hiểu rõ hơn những điểm phức tạp

Mô hình mẫu (Prototyping)

• Thực hiện thiết kế nhanh, tập trung chuyển tải những khía cạnh thông qua prototype để khách hàng có thể hình dung, đánh giá giúp hoàn chỉnh yêu cầu cho toàn hệ thống phần mềm, không đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển thực

sự sau đó

• Tiếp theo sau giai đoạn làm prototype này có thể

là một chu trình theo mô hình waterfall hay cũng

có thể là mô hình khác

Mô hình mẫu (Prototyping)

• Ưu điểm.

 Người sử dụng sớm hình dung ra chức năng

và đặc điểm của hệ thống

 Cho phép đánh giá rủi ro và kiểm tra giải pháp.

 Có ích trong tất cả các pha của vòng đời PM.

Mô hình mẫu (Prototyping)

• Nhược điểm.

 Khách hàng hối thúc nhà phát triển hoàn thành sản

phẩm một khi thấy được các prototype đầu tiên.

 Prototype thường được làm nhanh, thậm chí vội vàng,

theo kiểu “hiện thực - sửa” và có thể thiếu sự phân tích đánh giá một cách cẩn thận tất cả khía cạnh liên quan đến hệ thống cuối cùng.

 Không được xây dựng trên cùng môi trường và công cụ

phát triển của giai đoạn xây dựng phần mềm thực sự sau này.

 Không đặt ra mục tiêu tái sử dụng cho giai đoạn phát

triển thực sự sau đó.

Mô hình xoắn ốc

Mô hình xoắn ốc (tiếp)

• Mô hình này được xây dựng bởi Barry Boehm

• Đặt trọng tâm phân tích rủi ro và xem xét kế hoạch để giải quyết chúng, thông qua nhiều chu kỳ con nối tiếp được lặp liên tiếp dựa trên bản chất của mô hình lặp

Mô hình xoắn ốc (tiếp)

• Được thực hiện theo một chuỗi lặp kiểu xoắn ốc, mỗi lần lặp là một lần cải thiện sản phẩm cho thích nghi với bản chất của đề án, thực chất là một meta

- model

• Có phướng pháp đánh giá rủi ro.

• Có thể áp dụng Prototype.

Mô hình xoắn ốc (tiếp)

 Phân tích đánh giá rủi ro được đẩy lên như một phần thiết yếu trong mỗi vòng xoắn để tăng mức độ tin cậy của dự án.

 Kết hợp những tính chất tốt nhất của mô hình waterfall và

mô hình tiến hóa.

 Cho phép thay đổi tùy theo điều kiện thực tế dự án tại mỗi vòng xoắn.

 Đây chính là mô hình tổng quát nhất, tất cả các mô hình khác đều có thể xem là một hiện thực của mô hình tổng quát này, hay cũng có thể xem nó là mô hình tổng hợp các mô hình khác Đặc biệt, nó được ứng dụng không chỉ trong phát triển phần mềm mà còn trong phát triển phần cứng.

Mô hình xoắn ốc (tiếp)

• Một số nhược điểm:

 Khó đánh giá chính xác nhất là khi gặp rủi ro,

khó kiểm soát Phức tạp và không phù hợp cho

dự án nhỏ với ít rủi ro

 Mô hình này còn mới chưa được kiểm nghiệm

nhiều trong thực tiễn

 Cần có kỹ năng tốt về phân tích rủi ro.

Sự kết hợp mô hình tuyến tính và

mô hình mẫu vào mô hình xoắn ốc

• Như ta đã biết mô hình xoắn ốc phát triển trên tính

ưu việt của vòng đời và bản mẫu tức là phát triển dựa trên hai mô hình “mô hình tuyến tính và mô hình mẫu” bổ sung những yếu tố còn thiếu và thêm vào các yếu tố mới, phân tích rủi ro Vì vậy

để có thể kết hợp hai mô hình này trong mô hình xoắn ốc thì phải

Sự kết hợp mô hình tuyến tính và

mô hình mẫu vào mô hình xoắn ốc

• Phải khắc phục được những nhược điểm của hai mô

hình này để chúng có thể kết hợp được với nhau.

• Phải được xây dựng trên cùng một môi trường phát

triển của giai đoạn xây dựng phần mềm sau này.

• Đặt ra mục tiêu tái sử dụng cho giai đoạn phát triển

thực sự sau nó.

• Trên thực tế các giai đoạn phát triển phần mềm

không phải tách rời nhau mà là gối lên nhau và thông tin được cung cấp lẫn nhau vì vậy phải đảm bảo tính kế thừa của từng giai đoạn.

Sự kết hợp mô hình tuyến tính và

mô hình mẫu vào mô hình xoắn ốc

• Phải phát triển một cách tuần tự giữa hai mô hình.

• Tránh việc phát triển một cách nhanh chóng thậm trí là vội vàng

• Đáp ứng được các chức năng trong mô hình xoắn

ốc có thể thích hợp cho mỗi vòng

Xây dựng hệ thống phần mềm Quản lý tài sản của một doanh nghiệp

• Mô hình phát triển được lựa chọn: Mô hình xoắn ốc

• Phân tích nhanh yêu cầu:

• Xây dựng một phần mềm quản lý tài sản trong một doanh nghiệp Tài

sản bao gồm: thiết bị - máy móc phục sản xuất trực tiếp, thiết bị văn phòng, phương tiện đi lại…

• Phần mềm cho phép hiển thị, cập nhật, tìm kiếm, báo cáo, tổng hợp

thông tin về tài sản hiện có, đã thanh lý(tên, số lượng, chức năng, ngày nhập, ngày thanh lý…

• Phần mềm phải được sử dụng những công nghệ mới nhất.

• Những người sử dụng trong tương lai không biết hết những công nghệ

mới.

Vấn đề đặt ra:

• Đó là một sản phẩm mới

• Không thể dựa trên sản phẩm đã có.

• Nguồn và kiểu dữ liệu mới.

• Sử dụng các công nghệ mới, chưa được huấn luyện

thành thục

• Yêu cầu của khách hàng cần phải đơn giản hóa.

Tiếp cận:

• Tiếp cận theo phương pháp lặp với 5 vòng

• Vòng 1: Nghiên cứu tính khả thi

• Vòng 3: Chức năng hiển thị (Interface)

• Vòng 4: Chức năng cập nhật (Add, Edit, Delete)

• Vòng 5: Chức năng Tìm kiếm, Báo cáo, Tổng hợp.

Vòng 1:

• Nghiên cứu tính khả thi.

• Tập trung vào công nghệ → Không làm mẫu.

• Tìm các công nghệ thay thế khi có sự cố.

• Sự hiểu biết về quy trình làm việc trong công ty chưa đầy đủ → Cần tổ

chức các buổi trao đổi.

• Thời gian: 1 tháng làm việc.

• Nhân lực: 5 người.

Secondary Database Server (Backup Server)

GUI (Software Interface-

Browser)

• Vấn đề an ninh  Liện hệ với các chuyên gia nhằm xác định biện pháp

và tinh lược các yêu cầu.

• Thời gian: 1 tháng làm việc.

• Nhân lực: 5 người.

Primary Database Server

Secondary Database Server (Backup Server)

GUI (Software Interface-

Browser)

Vòng 5:

• Sử dụng lại và thay đổi kiến trúc đã tồn tại

• Thực hiện chức năng Tìm kiếm, Báo cáo, Tổng hợp.

• Chậm tiến độ ?  Thoả thuận với khách hàng.

• Hiệu suất ?  Sự tương thích giữa các cấu trúc, môi trường cài đặt…

• Thời gian: 1 tháng làm việc.

• Nhân lực: 5 người.