ÔN TẬP MÔN KỶ NGHỆ PHẦN MỀM

Chương 1. Tổng quan về phần mềm và kỹ nghệ phần mềm

A.Question:

1.

Thế nào là phần mềm? Phần mềm tốt nghĩa là gì?

2.

Bản  chất  và tầm quan trọng của phần mềm? Phân loại phần mềm?

3.

Thế nào là kỹ nghệ phần mềm? Các hoạt động phổ biến của kỹ nghệ phần mềm?Một số mô hình để phát triển phần mềm?

4.

Tiến trình phát triển phần mềm là gì? Cho biết hoạt động chính của mọi tiến trình?

B.Reply:

1.Thế nào là phần mềm? Phần mềm tốt nghĩa là gì?

1.

Phần mềm (software):

là một tập hợp các câu lệnh được viết bằng một hoặc nhiều ngôn ngữ lập trình, nhằm tự động thực hiện một số các chức năng giải quyết một bài toán nào đó.

+ Phần mềm bao gồm:

                        Chương trình máy tính

                        Dữ liệu: Cơ sở dữ liệu, hệ quản  trị cơ sở dữ liệu(access, foxpro,SQL server…)

                        Tài liệu: Hướng dẫn, kỹ thuật.

+ Phần mềm có thể được sản xuất cho một khách hàng riêng biệt hoặc khách hàng chung

Sản phẩm phần mềm có thể là:

Sản phẩm đại trà

(Genetic): phục vụ cho nhiều đối tượng khách hàng.

Sản phẩm đặt hàng

(Custom): phục vụ cho một nhóm người dùng

2.Phần mềm tốt:

Thứ 1 : Không gây ra lỗi, đứng hệ thống, tắt ngẽn trong quá trình sử dụng.

Thứ 2 :

Hệ thống phải có giao diện thân thiện với người sử dụng, phải phù hợp với khả năng và kiến thức của người dung hệ thống,hỗ trợ được những người dùng có trinh độ khác nhau(dễ đọc, dễ sử dụng và nhớ lâu).

Thứ 3 : Dễ thao tác với các chức năng. Các thao tác càng đơn giản càng tốt

Thứ 4 : Đáp ứng được phần lớn công việc như tự động hóa về quản lý và tự động hóa tính toán số liệu, linh họat trong sử dụng.

Thứ 5: Linh hoạt trong quản trị. Cho phép mở rộng nhu cầu, cập nhật nâng cấp và bổ sung tính năng mới.

Thứ 6: Phần mềm có thể bảo trì được , có tuổi thọ dài,phải được xây dụng và lập tư liệu,sao cho co thể dễ dàng sửa đổi bổ sung mà không quá tốn kém

Thứ 7: Phần mềm có tính hiệu quả ,hệ thống phải không lãng phí nguồn lực như bộ nhớ,bộ xử lý.

Thứ 8 : Cho phép tố ưu Cơ sở dữ liệu. Hằng năm cho phép cắt dữ liệu ra nhưng khi cần vẫn có thể tra lại được

2. Bản chất và tầm quan trọng của phần mềm

A.Bản chất của phần mềm

v

Không mòn cũ nhưng thoái hóa theo thời gian

Môi trường sử dụng thay đổi

Nhu cầu thay đổi

Lỗi phát sinh do nâng cấp

v

Thay đổi thường xuyên

Là mô hình của thế giới thực

Nhu cầu thay đổi

Môi trường nghiệp vụ thay đổi

Để thích ứng với thay đổi của môi trường

Thiết bị phần cứng

v

Không được lắp ráp từ mẫu có sẵn

v

Phức tạp, khó hiểu, vô hình

v

Cần phát triển theo nhóm

Quy mô phần mềm lớn và yêu cầu nhiều kỹ năng khác nhau

Thời gian

Tuy nhiên năng suất nhóm không tỷ lệ với số thành viên

Khó kiểm soát và đồng bộ

Trao đổi thông tin là vấn đề lớn

Khó tăng tốc bằng cách thêm người

B.Tầm quan trọng của phần mềm:

v

Phần mềm là linh hồn của các hệ thống máy tính

q

Có thể thực hiện các nhiệm vụ khác nhau bằng cách dùng các phần mềm khác nhau

q

Quyết định năng lực của máy tính

v

Có vai trò nền tảng của mọi hoạt động tổ chức, xã hội

v

Phần mềm tạo nên sự khác biệt giữa các tổ chức

q

Phong cách

q

Năng suất lao động

q

3.Thế nào là kỹ nghệ phần mềm?Một số mô hình phát triển phát triển phần mềm

A.Thế nào là kỹ nghệ phần mềm

Phần mềm (software): là một tập hợp các câu lệnh được viết bằng một hoặc nhiều ngôn ngữ lập trình, nhằm tự động thực hiện một số các chức năng giải quyết một bài toán nào đó.

Công nghệ (engineering): là cách sử dụng các công cụ, các kỹ thuật trong cách giải quyết một vấn đề nào đó.

Công nghệ phần mềm (software engineering): là việc áp dụng các công cụ, các kỹ thuật một cách hệ thống trong việc phát triển các ứng dụng dựa trên máy tính. Đó chính là việc áp dụng các quan điểm,  các tiến trình có kỷ luật và lượng hoá được, có bài bản và hệ thống để phát triển, vận hành và bảo trì phần mềm.

Theo quan điểm của nhiều nhà nghiên cứu, có thể nhìn công nghệ phần mềm là một mô hình được phân theo ba tầng mà tất cả các tầng này đều nhằm tới mục tiêu chất lượng, chi phí, thời hạn phát triển phần mềm.

v

Ba mặt cơ bản của kỹ nghệ phần mềm:

v

Quy trình (process): Định nghĩa một bộ khung các tiêu chuẩn để xây dựng phần mềm

q

Xác định trình tự các công việc

q

Xác định các tài liệu, sản phẩm cần bàn giao và cách thức thực hiện

q

Định ra các mốc thời gian và sản phẩm đưa ra

v

Phương pháp (methods): Chỉ ra cách thực hiện các công việc cụ thể

v

Mỗi công đoạn có phương pháp riêng:

q

Phân tích

q

Thiết kế

q

Lập trình

q

Kiểm thử

…

v

Công cụ (Tools): cung cấp, hỗ trợ tự động hay bán tự động đối với phương pháp. Các công cụ này gọi chung là CASE (Computer Aided Software Engineering). Ví dụ:

q

Quản lý dự án: Microsoft Project

q

Hỗ trợ phân tích, thiết kế: Ration Rose, Enterprise Architect

q

Hỗ trợ lập trình: IDE của các ngôn ngữ lập trình

B.Một số mô hình phát triển phần mềm

+  ,Mô hình tuyến tính (The linear sequential model)

Đôi lúc còn được gọi là mô hình kinh điển (classic model) hay mô hình thác nước (waterfall model). Mô hình này xem quá trình xây dựng một sản phẩm phần mềm bao gồm nhiều giai đoạn tách biệt, sau khi hoàn tất một giai đoạn thì chuyển đến giai đoạn sau.

Có hai hoạt động phổ biến được thực hiện trong mỗi giai đoạn là: kiểm tra - phê chuẩn và quản lý cấu hình. Tổng kết mỗi giai đoạn là sự kiểm tra, phê chuẩn  và quản lý cấu hình đây chính là mục tiêu của sản phẩm. Việc kiểm tra đưa ra khuôn mẫu đúng đắn tương ứng giữa sản phẩm phần mềm và các đặc tính của nó. Sự phê chuẩn đưa ra chuẩn mực về sự phù hợp hay chất lượng của sản phẩm phần mềm đối với mục đích của quá trình hoạt động. 

Tuy vậy, thường thì các dự án có hàng ngàn trang tài liệu mà không ai ngoại trừ tác giả đọc đến nó. Thông tin ứng dụng chỉ nằm trong đầu mọi người và việc trao đổi thông tin là một trở ngại lớn để có được thành công của hệ thống. Kết luận là văn bản không phải là một phương tiện tốt để mô tả các yêu cầu phức tạp của ứng dụng. Thêm vào đó, mô hình bộc lộ một số nhược điểm quan trọng như:

·

Mối qua hệ giữa các giai đoạn không được thể hiện

·

Hệ thống phải được kết thúc ở từng giai đoạn do vậy rất khó thực hiện được đầy đủ những yêu cầu của khách hàn

+ Mô hình mẫu (Prototyping model)

Thông thường, khách hàng sẽ đưa ra mục tiêu của họ một cách chung chung mà họ không biết hoặc không đưa ra một cách cụ thể những cái vào, cái ra và các tiến trình xử lý chúng. Thêm vào đó, chúng ta cũng không thể không quan tâm đến thuật toán sử dụng, tính tương thích của sản phẩm phần mềm với môi trường của nó như: phần cứng, hệ điều hành...Trong trường hợp này, mô hình mẫu có thể là sự lựa chọn tốt hơn cho người lập trình.

Những điểm chính của mô hình mẫu được tóm tắt theo sơ đồ sau:

Mô hình mẫu là một cách để phá vỡ sự khắt khe, cứng nhắc trong chu trình tuần tự của dự án. Tuy vậy, trong mô hình mẫu, sử dụng sai làm hỏng phân tích và thiết kế, không bao giờ hoàn thiện được mẫu thành các ứng dụng thực sự là các vấn đề cần quan tâm. Thêm vào đó là hệ thống có thể không bao giờ được chuẩn hóa, chi tiết của việc xử lý, việc kiểm tra tính hợp lệ của dữ liệu và các đòi hỏi kiểm toán có thể bị bỏ quên trong việc đưa mẫu vào sản xuất.

Trong tương lai, tạo mẫu thích hợp với đánh giá thiết kế, cải tiến cách dùng phần cứng và phần mềm mới. Tạo mẫu thường đi đôi với các ngôn ngữ lập trình bậc cao và ngày càng có nhiều công cụ đặt mẫu sẽ được tích hợp với CASE

Mô

hình xoắn ốc (The spiral model)

Mô hình này được Boehm đưa ra nên đôi lúc còn được gọi là mô hình  Boehm's (The Boehm's spiral model). Nó có thể xem là sự kết hợp giữa mô hình thác nước và mô hình mẫu và đồng thời thêm một thành phần mới - phân tích rủi ro. Bao gồm bốn hoạt động chính:

·

Planning: Xác định mục tiêu, tương tác và ràng buộc.

·

Risk analysis: Phân tích các lựa chọn và các chỉ định/giải quyết rủi ro.

·

Engineering : Phát triển sản phẩm

·

Customer evaluation: Đánh giá kết quả xây dựng.

Mô hình được tóm tắt nhu sau:

Trong vòng đầu tiên của xoáy ốc, mục đích, lựa chọn, các ràng buộc được định nghĩa và các nguy cơ được xác định và phân tích. Nếu phân tích các lỗi chỉ ra rằng có một vài yêu cầu không chắc chắn, tạo mẫu có thể dược tiến hành để giúp đỡ nhà phát triển và khách hàng. Mô phỏng và các mô hình khác có thể được sử dụng để xác định vấn đề và làm mịn các yêu cầu.

Khách hàng đánh giá công việc và đưa ra các gợi ý. Trên cơ sở ý kiến đó, phần tiếp theo của lập kế hoạch và phân tích lỗi xuất hiện.

Mô hình xoáy ốc hiện nay là mô hình hướng tiếp cận hiện thực nhất để phát triển các hệ thống lớn. Nó sử dụng mô hình mẫu như là cơ chế loại trừ lỗi, cho phép nhà phát triển áp dụng mô hình mẫu tại mỗi chu trình phát triển. Nó kế thừa cách tiếp cận hệ thống từng bước từ chu kỳ sống cổ điển nhưng kết hợp với quá trình lặp lại phù hợp với thực tế.

Giống như các quy trình khác, mô hình xoáy ốc không phải là công cụ vạn năng. Đối với những hệ thống lớn, khó có thể điều khiển sự tiến hóa của phần mềm. Nó đòi hỏi phải có kỹ năng đánh giá lỗi. Cuối cùng là cần phải có thêm thời gian để kiểm nghiệm phương pháp mới này.

Mô hình đài phun nước

Đây là mô hình của cách tiếp cận hướng đối tượng, hệ thống được xem như là một hệ thống các thực thể tác động qua lại để đạt được một mục đích nào đó. Mô hình này tương ứng với mô hình thác nước trong cách tiếp cận hướng thủ tục ở trên. Ở đây, ta thấy trong có những phần lặp và giao nhau giữa các bước phân tích, thiết kế và cài đặt.

Các điểm chính của mô hình được tóm tắt như sau:

Mô hình phát triển dựa trên thành phần

Xuất phát từ quan điểm: "Buy do not build", tư tưởng của phát triển dựa trên thành phần là lắp ráp hệ thống từ những thành phần đã có. Do vậy, kiến trúc phần mềm của hệ thống dựa vào kiến trúc phần mềm của các thành phần phần mềm tiêu chuẩn nên hệ thống đạt chất lượng cao hơn.

Phương pháp phát triển dựa trên thành phần gần tương tự như phương pháp phát triển hướng đối tượng. Hoạt động công nghệ bắt đầu với sự chỉ ra các lớp tham dự để phát triển hệ thống. Nếu các lớp này được tìm thấy trong thư viện và sự thích nghi là tốt, chúng sẽ được lấy ra và phát triển hệ thống. Ngược lại, chúng sẽ được phát triển để sử dụng và bổ sung vào thư viện sử dụng lại.

Thành phần phần mềm được sử dụng lại có độ chính xác cao và có thể nói là không chứa lỗi. Mặc dầu không thường xuyên được chứng minh về mặt hình thức nhưng với việc sử dụng lại, lỗi được tìm thấy và loại trừ; chất lượng của thành phần được cải thiện như là một kết quả.

Khi những thành phần sử dụng lại được ứng dụng thông qua tiến trình phần mềm, chúng ta ít tốn thời gian để tạo ra kế hoạch, mô hình, tài liệu, mã và dữ liệu mà chúng là cần thiết để tạo ra hệ thống. Thêm vào, chức năng cùng mức được phân phối cho người sử dụng với  đầu vào ít công sức hơn, do vậy, hiệu suất phần mềm được cải thiện.

Những điểm chính của mô hình được tóm tắt như sau:

5.

Tiến trình phát triển phần mềm là gì? Cho biết các hoạt động chính của mọi tiến trình

v

Các hoạt động phổ biến của mọi tiến trình:

q

Xác định yêu cầu

q

Phát triển

q

Thẩm định

q

Tiến hóa phần mềm: Thay đổi nhằm đáp ứng yêu cầu thay đổi (môi trường, nghiệp vụ)

q

Vận hành và bảo trì

v

Xác định yêu cầu: Hệ thống làm gì? Những ràng buộc mà hệ thống cần tuân thủ?

q

Phân tích hế thống:

Ø

Vai trò của phần mềm trong hệ thống

Ø

Phác họa và chọn phương án khả thi

q

Phân tích yêu cầu

Ø

Các yêu cầu cụ thể (chức năng, ràng buộc)

Đặc tả yêu cầu

v

Phát triển: Tạo ra phần mềm như thế nào?

q

Thiết kế: Dịch các yêu cầu ra bản thiết kế như nó tồn tại trong thực tế (Dữ liệu, giao diên, xử lý,…)

q

Mã hóa: Chuyển thiết kế thành chương trình (bằng 1 ngôn ngữ cụ thể)

q

Kiểm thử: sữa lỗi, hoàn thiện chương trình

v

Vận hành, bảo trì: hoàn thiện hệ thống sau khi đưa vào hoạt động?

q

Sửa lỗi: để vận hành thông suốt

q

Thích nghi với môi trường đã thay đổi để hoạt động hiệu quả

q

Nâng cao: hoàn thiện chức năng, phát triển dự phòng

q

Thêm mới: thêm các chức năng mới

CHƯƠNG II. PHÂN TÍCH VÀ ĐẶC TẢ YÊU CẦU

Question

1.Thế nào là yêu cầu?

2.Phân biệt được yêu cầu chức năng và yêu cầu phi chức năng?Cho ví dụ?

3. Một số kỹ thuật để thu thập dữ liệu

4.Các phương pháp đặc tả yêu cầu?

5.Những khó khăn của việc phân tích và xác định yêu cầu?

5.Có thể thực hiện thực hiện việc thu thập, phân tích và đặc tả yêu cầu của một bài toán cụ thể?

Reply:

1.Thế nào là yêu cầu?

v

L

à mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào.

Theo  mức độ chi tiết có thể chia ra các loại tài liệu yêu cầu:

            + Xác định yêu cầu: đây là một khẳng định, bằng ngôn ngữ tự nhiên hơn là các sơ đồ, về các dịch vụ hệ thống cần cung cấp và các ràng buộc mà hệ thống phải tuân theo. Tài liệu này cung cấp cho các thành phần: người quản lý của bên khách hàng, người dùng cuối của hệ thống, kỹ sư của khách hàng, người quản lý ký kết hợp đồng, các kiến trúc sư hệ thống.

            + Đặc tả yêu cầu: là tài liệu được cấu trúc mô tả hệ thống các dịch vụ chi tiết hơn. Đôi khi tài liệu này được gọi là đặc tả chức năng. Đây có thể coi là hợp đồng ký kết giữa người mua và kẻ bán phần mềm. Tài liệu này cung cấp cho các thành phần: người dùng cuối của hệ thống, kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm.

            + Đặc tả phần mềm: là mô tả trừu tượng hơn của phần mềm làm cơ sở cho thiết kế và triển khai. Tài liệu này cung cấp cho các thành phần: kỹ sư của khách hàng, các kiến trúc sư hệ thống, người phát triển phần mềm.

2.Phân biệt được yêu cầu chức năng và yêu cầu phi chức năng?Cho ví dụ?

**Yêu cầu chức năng

v

Mô tả chức năng hay dịch vụ của hệ thống cần cung cấp.

v

Chẳng hạn:

q

(Hệ thống thư viện) Độc giả có thể tìm kiếm đầu sách thông qua tên tác giả hoặc tiêu đề của đầu sách hoặc tên nhà xuất bản,…(Hiện)

q

(Forum) Hệ thống phải lưu lại thời gian đăng nhập của các thành viên (Ẩn)

v

Phụ thuộc

q

Mong muốn của khách hàng

q

Loại phần mềm được xây dựng

q

Loại hệ thống mà phần mềm trợ giúp

v

Mức độ các yêu cầu:

q

Trừu tượng: Hệ thống làm gì?

q

Chi tiết: nhiệm vụ cụ thể hế thống cần thực hiện

v

Trên nguyên tắc, yêu cầu phải:

q

Đầy đủ

q

Gắn bó: không mâu thuẫn lẫn nhau

v

Trên thực tế:

q

Khó có được yêu cầu đầy đủ và gắn bó

q

Cần bổ sung và hoàn thiện trong quá trình phát triển

**Yêu cầu phi chức năng

v

Định nghĩa các tính chất và ràng buộc của hệ thống

q

Yêu cầu về tiến trình phát triển

Ø

Phương pháp thiết kế

Ø

Ngôn ngữ lập trình được sử dụng

Ø

Công cụ sử dụng

q

Thời gian trả lời

q

Độ tin cậy

q

Yêu cầu về lưu trữ dữ liệu

v

Yêu cầu phi chức năng có thể quan trọng hơn yêu cầu chức năng

v

Phân loại:

q

Yêu cầu về sản phẩm

Ø

Tốc độ thực thi, độ tin cậy,…

q

Yêu cầu về tổ chức

Ø

Yêu cầu về chuẩn

Ø

Tiến trình phát triển

q

Yêu cầu bên ngoài

Ø

Yêu cầu về đạo đức

Ø

Yêu cầu về tương tác

v

Ví dụ:

q

Yêu cầu về sản phẩm:

Ø

Thời gian hiển thị thông tin sản phẩm sau khi nhập mã là bé hơn 3 giây

q

Yêu cầu về tổ chức

Ø

Tiến trình phát triển phải đáp ứng chuẩn DO178

q

Yêu cầu bên ngoài

Ø

Không để lộ thông tin khách hàng.

3.Một số kỹ thuật để thu thập dữ liệu

1.

Phỏng vấn

Phỏng vấn là việc tập hợp một số lượng ít người - thường với một hoặc hai người - cho một thời gian cố định với một mục đích cụ thể. Trong quá trình phỏng vấn, các câu hỏi có thể được thay đổi. Bạn có thể đánh giá được cảm nhận của họ, động cơ và thói quen đối với các phòng ban, quá trình quản lý, ứng dụng hoặc các thực thể khác đáng chú ý. Kiểu phỏng vấn được xác định bởi kiểu thông tin yêu cầu. Phỏng vấn nên được dẫn dắt sao cho cả hai bên tham gia đều cảm thấy thoả mãn với kết quả. Được chuẩn bị kỹ đồng nghĩa là hiểu rõ người đang được phỏng vấn, do đó bạn không làm họ bối rối và bạn có thể có vài câu hỏi ban đầu được chuẩn bị cho dù không phải là tất cả.

2.

Họp nhóm

Họp nhóm là việc tập hợp ba hoặc nhiều hơn một số người cho một thời hạn nhất định để thảo luận một số chủ đề. Họp nhóm có thể vừa bổ sung và thay thế  phỏng vấn. Nó bổ sung phỏng vấn bằng cách cho phép nhóm kiểm tra lại các kết quả phỏng vấn cá nhân. Nó có thể thay thế cho phỏng vấn bằng cách cung cấp một diễn đàn cho các người sử dụng cùng tìm ra các đòi hỏi và các giải pháp cho ứng dụng.

Họp nhóm cũng có thể làm lãng phí thời gian. Nói chung, họp nhóm càng lớn thì càng ít ý kiến nhất trí và thời gian quyết định càng kéo dài. Do vậy, nên có một kế hoạch ban đầu cho họp nhóm. Lịch trình nên được cung cấp trước cho các thành viên. Số lượng các chủ đề nên giữ ở mức độ 1 đến 5 và không mời những người không thích hợp để tránh lãng phí thời gian. Họp nhóm nên có một thời gian cố định và có điểm thống nhất cụ thể với các quyết định cần thiết, không nên kéo dài hơn 2 giờ để có thể đảm bảo được sự chú ý của thành viên. Họp nhóm phù hợp với việc đòi hỏi các tổng quát, tìm kiếm đồng lòng, và tiếp nhận cả thông tin chi tiết và thông tin tóm tắt.

Vậy, ưu điểm của phương pháp họp nhóm:

Ø

Có thể tạo ra quyết định,

Ø

Nhận được cả thông tin tổng hợp và chi tiết,

Ø

Phương pháp tốt cho các yêu cầu bên ngoài,

Ø

Tập hợp được nhiều người dùng liên quan,...

Nhược điểm của phương pháp họp nhóm:

Ø

Nếu số đại biểu nhiều sẽ tốn thời gian cho việc ra quyết định,

Ø

Tốn thời gian,

Ø

Các ngắt quảng làm phân tán sự chú ý,

Ø

Mời không đúng thành viên dẫn tới chậm có kết quả,

Ø

Dễ chuyển sang các chủ đề không liên quan như là chính trị, thể thao,...

3.

Quan sát

Quan sát là hoạt động có thể tiến hành thủ công hoặc tự động như sau:

+ Theo cách thủ công, người quan sát ngồi tại một chỗ và ghi chép các hoạt động, các bước xử lý công việc. Ghi chép hoặc băng ghi hình được dùng để phân tích cho các sự kiện, các mô tả động từ chính, hoặc các hoạt động chỉ rõ lý do, công việc hoặc các thông tin về công việc.

+Theo cách tự động, máy tính sẽ lưu giữ các chương trình thường trú, lưu lại vết của các chương trình được sử dụng, email và các hoạt động khác được xử lý bởi máy. Các file nhật ký của máy sẽ được phân tích để mô tả công việc.

Quan sát có các nhược điểm:

Ø

Thời gian của quan sát có thể không biểu diễn cho các công việc diễn ra thông thường,

Ø

Ý nghĩ là đang bị quan sát có thể làm thay đổi thói quen thường ngày của người bị quan sát,

Ø

Tốn thời gian.

Tuy nhiên, quan sát có các ưu điểm:

Ø

Kỹ sư phần mềm có thể nhận được sự hiểu biết tốt về môi trường công tác hiện tại và quá trình xử lý thông qua quan sát.

Ø

Kỹ sư phần mềm có thể tập trung vào vấn đề, mà không bị ảnh hưởng bởi người khác.

Ø

Các ngăn cách giữa kỹ sư phần mềm và các người được phỏng vấn sẽ được vượt qua bởi quan sát.

Để quan sát có hiệu quả, nên xác định cái gì sẽ được quan sát và xác định thời gian cần thiết cho việc quan sát. Đồng thời, hãy xin sự chấp thuận của cả người quản lý và cá nhân trước khi tiến hành quan sát.

4.

Ấn định công việc tạm thời

Với một công việc tạm thời, ta có được nhận thức đầy đủ hơn về các nhiệm vụ, đồng thời nó cung cấp cho ta kinh nghiệm thực tế. Đầu tiên, ta học các thuật ngữ và ngữ cảnh sử dụng nó. Thời gian tiến hành thường từ 2 tuần đến 1 tháng đủ dài để bạn có thể quen thuộc với phần lớn các công việc thông thường và các tình huống ngoại lệ nhưng không được quá dài để trở thành chuyên gia thực sự đối với công việc.

Công việc tạm thời cho ta cơ sở hình thức hoá các câu hỏi về các chức năng nào của phương pháp hiện thời của công việc sẽ được lưu giữ lại và cái nào sẽ bị loại trừ hoặc thay đổi. Nó cũng là cách thức để trả lời các câu hỏi không thể thực hiện được

Bất lợi của công việc tạm thời là tốn thời gian và sự lựa chọn về thời gian có thể làm tối thiểu hoá vấn đề. Thêm vào đó, người kỹ sư phần mềm có thể có thiên kiến về quá trình xử lý công việc, nội dung làm ảnh hưởng tới công việc thiết kế sau này.

5.

Điều tra qua câu hỏi

Điều tra qua câu hỏi là xây dựng các câu hỏi để phỏng vấn trên giấy hoặc máy tính. Các câu hỏi được dùng để nhận các thông tin từ số lượng lớn người sử dụng và thường ở dạng khả năng lựa chọn, người trả lời chỉ việc đánh dấu. Các mục câu hỏi, như là phỏng vấn, có thể là câu hỏi mở hoặc câu hỏi đóng nhưng không chỉ rõ tên, dẫn đến các câu trả lời trung thực hơn nhiều phỏng vấn.

Ưu điểm của phương pháp điều tra:

Ø

Các trả lời không cần biết tên nên quan điểm và cảm nhận thu được là trung thực,

Ø

Có thể tiến hành với nhiều người,

Ø

Thích hợp với các câu hỏi đóng và hữu hạn,

Ø

Phù hợp với công ty đa văn hoá và có thể tuỳ biến với quy ước địa phương,…

Hạn chế của phương pháp điều tra:

Ø

Khó thực hiện lại được,

Ø

Các câu hỏi không có trả lời có nghĩa là không thu được thông tin,

Ø

Các câu hỏi có thể khó hiểu,

Ø

Thực hiện và đánh giá có thể chậm,

Ø

Không thể thêm các thông tin khi đã tiến hành công việc,

Ø

Thông tin thu được hạn chế trong một phạm vi hẹp,

Ø

Chỉ dùng nó như một phương pháp bổ sung,...

6.

Xem xét tài liệu

Khái niệm tài liệu ám chỉ tới các cẩm nang, quy định, các thao tác chuẩn mà tổ chức cung cấp như là hướng dẫn cho các nhà quản lý và nhân viên.

Các tài liệu thực sự hữu ích cho các kỹ sư phần mềm để học về các lĩnh vực mà họ chưa từng có kinh nghiệm. Nó có thể hữu ích cho việc xác định các câu hỏi về quá trình thao tác và sản xuất. Tài liệu đưa ra các thông tin khách quan.

Tuy nhiên, các tài liệu không phải luôn nằm trong công ty, nó có thể là các ấn phẩm kỹ thuật, các báo cáo nghiên cứu,... nên khó cho việc tìm kiếm. Nó còn gây thành kiến và không không cung cấp để có thể nhận biết được quan điểm, động cơ,...

7.

Xem xét phần mềm

Khi các ứng dụng cũ phải được thay thế các phần mềm mới, việc nghiên cứu các phần mềm đã tồn tại cung cấp cho chúng ta các thông tin về quá trình xử lý công việc hiện thời và các mở rộng có ràng buộc bởi thiết kế phần mềm.

Khuyết điểm chính của việc nhận thông tin từ quan sát phần mềm là tài liệu có thể không chính xác hoặc kịp thời. Thêm vào đó, thời gian có thể bị lãng phí nếu ứng dụng đang bị xoá bỏ.

4.Các phương pháp đặc tả yêu cầu?

3.3.1. Đặc tả yêu cầu

Khi đã xác định rõ bài toán thì bước tiếp theo là tìm hiểu xem hệ thống dự kiến sẽ yêu cầu làm cái gì. Điều quan trọng ở đây là phải xây dựng được danh sách các yêu cầu của người sử dụng. Dựa trên những yêu cầu của người sử dụng, người phát triển đưa ra các đặc tả cho hệ thống.

Người xây dựng hệ thống phải trả lời được các yêu cầu sau đây:

·

Đầu ra của hệ thống là cái gì

·

Hệ thống sẽ phải làm cái gì để có kết quả mong muốn, nghĩa là phải xử lý những cái gì

·

Những tài nguyên mà hệ thống yêu cầu là gì

Hiểu rõ nguồn gốc, các dạng thông tin cần cung cấp cho hệ thống hoạt động. Hệ thống sẽ phải giải quyết những vấn đề gì, những kết quả cần phải có là gì. Xác định được mối quan hệ giữa cái vào và cái ra cho quá trình hoạt động của hệ thống. Các đặc tả chi tiết phục vụ cho việc  xây dựng và trắc nghiệm về hệ thống để kiểm tra xem những nhiệm vụ đã đặt ra có hoàn tất được hay không.

Ở đây, chúng ta cần chú ý là trong một số trường hợp, sẽ nảy sinh những yêu cầu mới mà có thể là ta phải xây dựng lại hệ thống, tất nhiên điều này sẽ làm chậm tiến trình xây dựng và làm tăng giá thành do một vài lý do để không thể hoàn chỉnh các đặc tả đối với các hệ thống như:

·

Các hệ thống phần mềm lớn luôn đòi hỏi cải tiến từ hiện trạng. Mặc dù các khó khăn của hệ thống hiện tại có thể xác định được nhưng các ảnh hưởng và hiệu ứng của hệ thống mới khó có thể dự đoán trước được.

·

Hệ thống lớn thường có nhiều cộng đồng sử dụng khác nhau. Họ có các yêu cầu và ưu tiên khác nhau. Các yêu cầu hệ thống cuối cùng không tránh khỏi các thỏa hiệp.

·

Người trả tiền cho hệ thống và người sử dụng thường khác nhau. Các yêu cầu đưa ra do ràng buộc của các tổ chức và tài chính có thể tranh chấp với yêu cầu của người sử dụng.

Do các đặc tả yêu cầu thêm các thông tin vào định nghĩa yêu cầu nên các đặc tả thường được biểu diễn cùng với các mô hình hệ thống được phát triển trong quá trình phân tích yêu cầu. Nó cần bao gồm mọi thông tin cần thiết về yêu cầu chức năng và ràng buộc của hệ thống. Phân tích yêu cầu được tiếp tục xác định và đặc tả khi các yêu cầu mới nảy sinh. Đây là tài liệu thường xuyên thay đổi và nên được kiểm soát chặt chẽ.

Ngôn ngữ tự nhiên không hoàn toàn thuận tiện cho các thiết kế viên hoặc các hợp đồng giữa các khách hàng và cán bộ phát triển hệ thống vì có một số lý do như sau:

·

Nhầm lẫn do cách hiểu các khái niệm khác nhau giữa hai bên.

·

Đặc tả yêu cầu ngôn ngữ tự nhiên quá mềm dẻo. Một vấn đề có thể được mô tả bằng quá nhiều cách khác nhau.

·

Các yêu cầu không được phân hoạch tốt, khó tìm các mối quan hệ,...

Do vậy người ta thường dùng các thay thế khác để đặc tả các yêu cầu như:

·

Ngôn ngữ tự nhiên có cấu trúc,

·

Ngôn ngữ mô tả thiết kế, giống ngôn ngữ lập trình nhưng có mức trừu tượng cao hơn,

·

Ngôn ngữ đặc tả yêu cầu,

·

Ghi chép graphic,

·

Đặc tả toán học,...

Có thể chia đặc tả yêu cầu ra làm hai loại: đặc tả phi hình thức (ngôn ngữ tự nhiên) và  đặc tả hình thức (dựa trên kiến trúc toán học).

1.

Đặc tả phi hình thức

Đặc tả phi hình thức là đặc tả sử dụng ngôn ngữ tự nhiên. Tuy nó không được chặt chẽ bằng đặc tả hình thức nhưng được nhiều người biết và có thể dùng để trao đổi với nhau để làm chính xác hóa các điểm chưa rõ, chưa thống nhất giữa các bên phát triển hệ thống.

2.

Đặc tả hình thức

Đặc tả hình thức là đặc tả mà ở đó các từ ngữ, cú pháp, ngữ nghĩa được định nghĩa hình thức dựa vào toán học. Đặc tả hình thức có thể coi là một phần của hoạt động đặc tả phần mềm. Các đặc tả yêu cầu được phân tích chi tiết. Các mô tả trừu tượng của các chức năng chương trình có thể được tạo ra để làm rõ yêu cầu.

Đặc tả phần mềm hình thức là một đặc tả được trình bày trên một ngôn ngữ bao gồm: từ vựng, cú pháp và ngữ nghĩa được định nghĩa. Định nghĩa ngữ nghĩa đảm bảo ngôn ngữ đặc tả không phải là ngôn ngữ tự nhiên mà dựa trên toán học. Các chức năng nhận các đầu vào trả lại các kết quả. Các chức năng có thể định ra các điều kiện tiền tố và hậu tố. Điều kiện tiền tố là điều kiện cần thỏa mãn để có dữ liệu vào, điều kiện hậu tố là điều kiện cần thỏa mãn sau khi có kết quả.

Có hai hướng tiếp cận đặc tả hình thức để phát triển các hệ thống tương đối phức tạp.

+ Tiếp cận đại số, hệ thống được mô tả dưới dạng các toán tử và các quan hệ.

+ Tiếp cận mô hình, mô hình hệ thống được câú trúc sử dụng các thực thể toán học như là các tập hợp và các thứ tự.

Sử dụng đặc tả hình thức, ta có các thuận lợi:

·

Cho phép chúng ta thấy và hiểu được bản chất bên trong của các yêu cầu, đây là cách tốt nhất để làm giảm các lỗi, các thiếu sót có thể xảy ra và giúp cho công việc thiết kế được thuận lợi.

·

Do chúng ta sử dụng toán học cho việc đặc tả nên có thể dựa vào các công cụ toán học khi phân tích và điều này làm tăng thêm tính chắc chắn và tính đầy đủ của hệ thống.

·

Đặc tả hình thức, bản thân nó cho chúng ta một cách thức cho việc kiểm tra hệ thống sau này.

Tuy vậy, đặc tả hình thức cũng bộc lộ một vài khó khăn:

·

Quản lý phần mềm có tính bảo thủ cố hữu của nó, không sẵn sàng chấp nhận các kỹ thuật mới.

·

Chi phí cho việc đặc tả hình thức thường cao hơn so với các đặc tả khác (tuy phần cài đặt sẽ thấp hơn), nên khó để chứng minh rằng chi phí tương đối cao cho đặc tả sẽ làm giảm tổng chi phí dự án.

·

Phần lớn, những người đặc tả hệ thống không được đào tạo một cách chính quy về việc sử dụng đặc tả hình thức cho việc đặc tả hệ thống mà dựa trên thói quen của họ.

·

Thông thường, nhiều thành phần của hệ thống là khó cho việc đặc tả bằng ngôn ngữ hình thức. Thêm vào đó là khách hàng không thể hiểu được nó.

·

Khách hàng không thích các đặc tả toán học.

3.3.2.

Nguyên lý đặc tả

Nguyên lý 1: Phân tách chức năng với cài đặt: đặc tả là mô tả điều mong muốn chứ không phải cách thức thực hiện (cài đặt). Kết quả thu được theo dạng cái gì chứ không phải là thế nào.

Nguyên lý 2: Cần tới ngôn ngữ đặc tả hệ thống hướng tiến trình: cần thiết đặc biệt trong trường hợp môi trường là động và sự thay đổi của nó ảnh hưởng tới hành vi của thực thể nào đó tương tác với môi trường nào đó.

Nguyên lý 3: Đặc tả phải bao gồm hệ thống có phần mềm là một thành phần:  vì hệ thống bao gồm các thành phần tương tác với nhau, chỉ bên trong hoàn cảnh của toàn bộ hệ thống và tương tác giữa các thành phần của nó thì hành vi của một thành phần mới có thể xác định.

Nguyên lý 4: Đặc tả phải bao gồm cả môi trường mà hệ thống vận hành.

Nguyên lý 5: Đặc tả hệ thống phải là một mô hình nhận thức: không phải là mô hình thiết kế hay cài đặt. Nó phải mô tả một hệ thống như cộng đồng người sử dụng cảm nhận thấy. (Các sự vật mà nó thao tác phải tương ứng với các sự vật của lĩnh vực đó; các tác nhân phải mô hình cho các cá nhân, tổ chức, trang thiết bị; các hành động họ thực hiện thì mô hình cho những hoạt động thực tế xuất hiện trong lĩnh vực;...)

Nguyên lý 6: Đặc tả phải vận hành: phải đầy đủ và hình thức để có thể được dùng trong việc xác định liệu một cài đặt được đề nghị có thỏa mãn đặc tả trong những trường hợp kiểm thử tùy ý hay không.

Nguyên lý 7: Đặc tả hệ thống phải dung sai về tính không đầy đủ và tính nâng cao. Đặc tả không thể hoàn toàn đầy đủ do môi trường phức tạp

+ Đặc tả là mô hình - sự trừu tượng hóa - của tình huống thực nên không đầy đủ.

+ Đặc tả sẽ tồn tại ở nhiều mức chi tiết

+ Các công cụ phân tích được sử dụng để giúp cho đặc tả và kiểm thử đặc tả phải có khả năng xử lý với tính không đầy đủ.

Nguyên lý 8: Đặc tả phải được cục bộ hóa và được ghép lỏng lẻo: Đặc tả làm cơ sở cho thiết kế và cài đặt, không phải tĩnh mà là một sự vật động, đang trải qua thay đổi đáng kể nên nội dung và cấu trúc phải phù hợp. Sự thay đổi khi cần sửa đổi là tối thiểu, chỉ một phần nhỏ các thành phần có thể thâm vào hay loại bớt một cách dễ dàng.

5.Những khó khăn của việc phân tích và xác định yêu cầu?

v

Khó khăn

q

Khách hàng thương mơ hồ về yêu cầu, không biết rõ mình muốn gì

q

Họ thể hiện yêu cầu bằng thuật ngữ riêng

q

Khách hàng đa dạng, có thể có yêu cầu mâu thuẫn

q

Yêu cầu thương mang tính đặc thù, khó hiểu, khó có chuẩn chung

q

Những yếu tố tổ chức, chính sách có thể ảnh hưởng đến yêu cầu

**Những khó khăn của việc phân tích yêu cầu?

Như vậy, phân tích yêu cầu là quá trình suy luận các yêu cầu hệ thống thông qua quan sát hệ thống hiện tại, thảo luận với các người sử dụng, phân tích công việc. Việc này có thể liên quan với việc tạo một hay nhiều mô hình khác nhau. Nó giúp các phân tích viên hiểu biết hệ thống. Các mẫu hệ thống cũng có thể được phát triển để mô tả các yêu cầu. Ta có quy trình để có các chức năng của hệ thống:

Trong quá trình phân tích cần lưu ý đến tính khả thi của dự án.

+ Khả thi về kinh tế: chi phí phát triển phải cân xứng với lợi ích mà hệ thống đem lại, gồm có:

Ø

Chi phí:

·

Mua sắm: thiết bị, vật tư (phần cứng), tư vấn, cài đặt thiết bị, quản lý và phục vụ,...

·

Chi phí cho khởi công: phần mềm phục vụ cho hệ thống, hệ thống liên lạc (truyền dữ liệu), nhân sự ban đầu: đào tạo - huấn luyện, cải tổ tổ chức cho phù hợp,...

·

Chi phí liên quan: chi phí nhân công phục vụ thu nhập dữ liệu, sửa đổi, cập nhật hệ thống, chuẩn bị tài liệu,...

·

Chi phí liên tục là tốn kém nhất, gồm: bảo trì, thuê bao, khấu hao phần cứng, chi phí phục vụ cho vận hành,...

Ø

Lợi nhuận do sử dụng hệ thống

·

Nhiệm vụ xử lý thông tin: giảm chi phí do xử lý tự động, tăng độ chính xác và kết quả tốt hơn, thời gian trả lời rút ngắn,...

·

Có được từ hệ thống: thu thập và lưu trữ dữ liệu tự động, đầy đủ, dữ liệu được chuẩn hóa, bảo đảm an toàn và an ninh dữ liệu, tương thích và chuyển đổi giữa các bộ phận, truy cập và tìm kiếm nhanh, kết nối và trao đổi diện rộng,...

+ Khả thi về kỹ thuật: đây là vấn đề cần lưu ý vì các mục tiêu, chức năng và hiệu suất của hệ thống theo một cách nào đó là còn "mơ hồ" do vậy xét:

Ø

Rủi ro xây dựng: các phần tử hệ thống (chức năng, hiệu suất) khi thiết kế và phân tích có tương đương hay không?

Ø

Có sẵn tài nguyên: có sẵn con người và tài nguyên cần thiết để phát triển hệ thống?

Ø

Công nghệ: các công nghệ liên quan cho việc phát triển hệ thống đã có sẵn hay chưa?

+ Khả thi về hợp pháp: có sự xâm phạm, vi phạm hay khó khăn nào gây ra khi xây dựng hệ thống hay không.

+ Các phương án: đánh giá về phương án tiếp cận đến việc xây dựng hệ thống.

Những khó khăn của việc xác định yêu cầu?

Xác định yêu cầu:

là mô tả trừu tượng các dịch vụ mà hệ thống được mong đợi phải cung cấp và các ràng buộc mà hệ thống phải tuân thủ khi vận hành. Nó chỉ có các đặc tả phẩm hạnh bên ngoài của hệ thống mà không liên quan đến các đặc tính thiết kế. Nó phải được viết sao cho người ta có thể hiểu được mà không cần một kiến thức chuyên môn đặc biệt nào.

Về nguyên tắc các yêu cầu của một hệ thống phải là vừa đầy đủ, vừa tráng kiện. Đầy đủ có nghĩa là mọi yêu cầu đều phải được đặc tả. Tráng kiện có nghĩa là các yêu cầu không gây ra mâu thuẫn. Thực tế đối với các hệ lớn và phức tạp thì thực là không thể đạt được tính đầy đủ và tính tráng kiện cho phiên bản đầu của tư liệu yêu cầu phần mềm. Vấn đề là khi duyệt lại hoặc trong các pha sau này của vòng đời phần mềm, người ta phát hiện ra các sự không thỏa mãn đó thì tư liệu yêu cầu phải được chỉnh lý lại.

Về bản chất, chúng ta phải hiểu và xác định rõ những yêu cầu của khách hàng. Tuy nhiên, thường bài toán được khách hàng phát biểu bằng ngôn ngữ tự nhiên cộng thêm với việc dùng các bảng các biểu đồ cho các người dùng dễ hiểu (xem là người dùng không biết các khái niệm chuyên môn công nghệ thông tin). Không may là ngôn ngữ được dùng này lại thường là không chính xác và mơ hồ,  đôi khi có sự lầm lẫn giữa các biểu thị khái niệm và các biểu thị chi tiết làm cho việc mô tả chứa các thông tin hổ lốn được biểu diễn ở nhiều mức chi tiết khác nhau.

Ở đây, chúng ta cần chú ý rằng người đặt hàng có thể vì không hiểu biết gì về tin học nên họ không thể phát biểu chính xác và đầy đủ các yêu cầu của họ, đôi lúc thì những cái mà người sử dụng yêu cầu và những cái mà họ cần là không giống nhau. Thêm vào đó, chúng ta lại không hiểu biết đầy đủ về đối tượng, địa bàn cho nên không thể thu thập đầy đủ và chính xác các thông tin của đối tượng và đây chính là một trong những mâu thuẩn giữa khách hàng và chúng ta. Vì vậy, trong thực tế, đối với các hệ thống lớn và phức tạp, rất khó có thể đạt được tính đầy đủ và thống nhất của tài liệu yêu cầu.

Các yêu cầu được tìm hiểu còn chứa các mâu thuẩn:

·

Thiếu rõ ràng: Rất khó sử dụng ngôn ngữ tự nhiên mô tả chính xác không nhầm lẫn mà không làm khó khăn cho người đọc.

·

Nhầm lẫn yêu cầu: Các yêu cầu chức năng, các ràng buộc, mục đích của hệ thống và các thông tin thiết kế không được phân biệt rõ ràng.

·

Trộn lẫn yêu cầu: Một số các yêu cầu khác nhau có thể được thể hiện như là một yêu cầu đơn.

Giải quyết mâu thuẩn này, chúng ta phải: trên cơ sở nghiên cứu kỹ lĩnh vực ứng dụng và thảo luận với người sử dụng để định nghĩa chính xác các yêu cầu của bài toán. Xác định rõ và đầy đủ bài toán là yếu tố quan trọng góp phần đảm bảo thành công của dự án. Nhiệm vụ của giai đoạn này là xây dựng được các hồ sơ mô tả chi tiết về các yêu cầu, nhiệm vụ, chức năng của hệ thống dự kiến

CHƯƠNG III> THIẾT KẾ PHẦN MỀM

1.Hiểu biết chung về thiết kế phần mềm

Xây dựng ứng dụng phần mềm là một dây chuyền các chuyển đổi, mà ở đó phân tích nhằm xác định ứng dụng sẽ thực hiện cái gì (what) còn thiết kế nhằm để trả lời câu hỏi phần mềm cụ thể sẽ như thế nào (how)? Tức là xác định cách thức thực hiện những gì đã được đặt ra ở phần phân tích.

Trong ba giai đoạn: thiết kế, cài đặt và bảo trì thì thiết kế là giai đoạn quan trọng nhất, chịu trách nhiệm đến 80% đối với sự thành công của một sản phẩm. Cài đặt là việc thực thi những gì đã thiết kế. Nếu trong quá trình cài đặt có xuất hiện vấn đề thì phải quay lại sửa bản thiết kế. Quá trình thiết kế tốt là cơ sở để quản lý và giảm chi phí cho công việc bảo trì phần mềm sau này.

•

Khái niệm: Là chuyển đặc tả yêu cầu

è

mô tả thiết kế

•

Là hoạt động đặc biệt:

–

Là một quá trình sáng tạo: đòi hỏi kinh nghiệm và nhanh nhạy

–

Cần phải được thực hành và học bằng kinh nghiệm, bằng khảo sát thực tế. Sách vở là chưa đủ.

è

Đủ chi tiết để người lập trình biết phải làm gì để  chuyển thành chương trình thực hiện được

2.Các hoạt động cần thiết để thiết kế phần mềm

Như trên đã nói, phân tích nhằm xác định ứng dụng sẽ thực hiện cái gì còn thiết kế nhằm để trả lời câu hỏi phần mềm cụ thể sẽ như thế nào? Trong thực tế, không có sự tách biệt giữa hai giai đoạn này mà là hai hoạt động được tiến hành song song và chúng bổ sung lẫn nhau. Các hoạt động phải thực hiện trong quá trình này gồm: định danh, suy diễn, tổng hợp lại, xem xét lại và tạo tài tiệu.

            Định danh: chính là tìm kiếm những gì quan trọng có liên quan, như việc tìm các thực thể, các đối tượng, các mối quan hệ, các chức năng, các tiến trình và các ràng buộc của hệ thống.

Thiết kế là việc tham chiếu các yêu cầu logic sẽ làm việc như thế nào trong môi trường tính toán đích. Điều này có nghĩa là chúng ta định danh cấu trúc thiết kế hệ thống, nó là phương hướng thiết kế nền tảng. Các phương hướng có thể bao gồm:

·

Xử lý theo lô, trực tuyến hoặc thời gian thực.

·

Các hàm chức năng nào được kết nối với nhau và ứng dụng sẽ làm việc trong môi trường sản phẩm như thế nào.

·

Các giao diện người sử dụng chung như điều khiển menu, cửa sổ – biểu tượng – menu – con trỏ, điều khiển lệnh,...

·

Kiểu thao tác, người sử dụng là chuyên gia, tập sự hay bình thường.

Suy diễn: Xác định các chi tiết của những gì đã được định danh. Về mặt thể hiện, một yêu cầu có thể được cung cấp bản kê khai thống nhất của khách hàng cho báo cáo đặc biệt.

Trong quá trình xem xét, ta sẽ tìm câu trả lời cho các câu hỏi như:

Thông tin nào có thể đảm bảo chắc chắn về người sử dụng? Nó có đang tồn tại?

Điều gì đặc biệt đối với người sử dụng?

Kiểu của các Query người sử dụng đang hỏi?

Các dạng câu hỏi nào người sử dụng muốn hỏi mà họ không thể trả lời?

Kiểu dữ liệu phân tích nào người sử dụng cần?

Các form (như màn hình hiển thị hay giấy) được đưa ra?

Các người sử dụng đặt câu hỏi ở đâu (vật lý)?

Dữ liệu đang ở đâu (tập trung/ phân tán/ nữa tập trung)? Và nó có thể ở đâu?

Mỗi yêu cầu từ quá trình phân tích được khai triển thành chi tiết lớn hơn trong thiết kế và được tham chiếu tới phần cứng, phần mềm thuộc cấu trúc thiết kế hệ thống.

Ở đây, các vấn đề liên quan đến cần giải quyết như:

·

Cơ sở dữ liệu thiết kế có thể được thiết kế để cung cấp như thế nào, về mặt thể hiện là thời gian đáp ứng tốt nhất với hiệu quả cao nhất?

·

Các chương trình có thể được đóng gói như thế nào để đáp ứng các ràng buộc tiến trình?

·

Các hoạt động xem xét khác được quyết định bao gồm các công việc thông thường chung cho các tiến trình sử dụng thông thường. Về mặt thể hiện, tiến trình hiển thị sẽ được thực hiện như thế nào? Các lập trình viên sẽ viết giao diện hiển thị riêng hay sẽ có các module chung cho các thao tác hiển thị? Phần thân và các chi tiết của hệ thống các chương trình tiện ích được tất cả các lập trình viên sử dụng.

·

Hoạt động xem xét chính cuối cùng là kiểm tra các ràng buộc của ứng dụng. Chúng ta chắc chắn rằng mỗi ràng buộc đều được bảo toàn trong thiết kế và quá trình đó nằm trong các giới hạn quy định.

Tổng hợp lại: xây dựng một khung nhìn thống nhất của ứng dụng, điều hoà các phần không thích hợp và biểu diễn các yêu cầu trên form đồ thị. Sự biểu diễn có thể là thủ công hoặc tự động, sử dụng các công cụ tính toán cơ sở.

Trong thiết kế, tổng hợp lại phải xây dựng một thiết kế vật lý của ứng dụng, điều chỉnh các phần không phù hợp và biểu diễn các yêu cầu chi tiết hơn. Chúng ta có thể thêm các hàm chức năng vào ứng dụng trong môi trường đặc biệt.

Xem xét lại: là việc thực hiện điều khiển chất lượng. Tại cuối mỗi giai đoạn, phân tích lại tính khả thi, thời biểu và bố trí nhân sự. Xem xét lại chúng khi cần thiết dựa vào sự hoàn thiện hơn, các khái niệm hiện tại của hệ thống mới.

Như thế, xem xét lại chính là thực hiện điều chỉnh chất lượng. Tại cuối giai đoạn này dẫn hướng thiết kế xuyên suốt, so sánh thiết kế với các yêu cầu logic, sự hoàn thiện logic và sự đúng đắn. Phân tích lại thời biểu và bố trí nhân sự để tiến hành cài đặt, kiểm duyệt, thay đổi, đào tạo và sự chuyển công tác, xem xét lại chúng cho phù hợp yêu cầu.

Tạo tài liệu: tạo các chương trình hữu ích đặc biệt và một tài liệu thiết kế toàn thể. Tài liệu thiết kế mô tả cơ sở dữ liệu, cấu trúc của ứng dụng, các ràng buộc, cũng như các đồ thị và văn bản thiết kế. Các module của chương trình bao gồm các chi tiết của tiến trình, tất cả các giao diện thiết kế và các thông tin đặc biệt để phát triển ứng dụng.

Tuy nhiên, các hoạt động trên trong phân tích và thiết kế có những khác biệt cơ bản, chúng được chỉ ra ở bảng sau:

Để ý rằng, chúng ta bàn luận về phân tích và thiết kế như là việc tham chiếu đơn giản của “cái gì” và “như thế nào”, nhưng nó không phải là tham chiếu 1-1. Ở đây, chúng ta cần tới sự thoả hiệp các yêu cầu phân tích trong thiết kế. Thoả hiệp các yêu cầu nghĩa là chúng có thể phải được cấu trúc lại, thao tác, phân nhỏ hay thay đổi để phù hợp với giới hạn của môi trường. Việc liên kết giữa phân tích và thiết kế chương trình lỏng hay chặt phụ thuộc vào phương pháp luận và môi trường cài đặt. Về mặt thể hiện, dữ liệu sẽ khác nhau nếu chúng ta sử dụng các chuẩn dữ liệu khác nhau. Mức độ chi tiết các yêu cầu sẽ khác nhau nếu ta sử dụng ngôn ngữ cài đặt khác nhau.

3.Nội dung thiết kế

Thiết kế phần mềm là hoạt động được xác lập dựa trên hai mặt: quản lý và kỹ thuật, chúng đan xen với nhau. Mối quan hệ giữa hai khía cạnh kỹ thuật và quản lý được thể hiện qua sơ đồ:

·

 Trong quan điểm quản lý: thiết kế phần mềm được tiến hành 2 bước:

+ Thiết kế sơ bộ: quan tâm đến việc dịch các yêu cầu thành các kiến trúc dữ liệu và phần mềm.

+ Thiết kế chi tiết: tập trung vào việc làm mịn biểu diễn kiến trúc để dẫn đến cấu trúc dữ liệu chi tiết và biểu diễn thuật toán cho phần mềm.

·

 Đối với khía cạnh kỹ thuật, xuất hiện một số hoạt động thiết kế như:

            + Thiết kế  dữ liệu:Xây dựng mô hình biểu diễn thông tin

Các mức thiết kế

–

Thiết kế cấu trúc logic:

–

Mô hình dữ liệu quan hệ

–

Mô hình dữ liệu đối tượng

Thiết kế cấu trúc vật lý

            + Thiết kế kiến trúc: Phân rã hệ thống thành các modul con và xác định giao diện tương tác giữa các modul

–

Sử dụng biểu đồ cấu trúc, mô tả:

–

Cái nhìn tổng thể về hệ thống

–

Mối quan hệ giữa các modul

–

Giao diện giữa các modul

–

Không cần chỉ ra:

–

Thứ tự thực hiện

–

Số lần thực hiện

Chi tiết thiết k

            + Thiết kế thủ tục: Xác định các bước cần xử lý

•

Mô tả các bước hoạt động của modul

•

Phương pháp

–

Mã giả (Pseudo code)

–

Sơ đồ luồng (Flow chart)

–

Biểu đồ hoạt động

…

            + Thiết kế đối tượng

            +Thiết kế giao diện

Trong tiến trình thiết kế, mô hình để biểu diễn công việc thiết kế là đồ thị. Các đỉnh của đồ thị dùng để biểu diễn các thực thể (các tiến trình, các chức năng, các kiểu...) và các cạnh là các mối liên hệ giữa chúng. Quá trình thiết kế thường được mô tả bằng nhiều mức khác nhau của cách tiếp cận trừu tượng hóa, nhằm tách các bộ phận cấu thành của bài toán nhằm nâng cao độ chắc chắn, độ tin cậy của hệ thống.

Tiến trình thiết kế được chỉ ra ở sơ đồ sau:

4.Đánh giá chất lượng của một thiết kế

Như đã đề cập ở trên, rất khó để có thể xác định được thế nào là thiết kế tốt, nó phụ thuộc vào ứng dụng và vào yêu cầu dự án. Một thiết kế tốt phải là một thiết kế mà nó cho phép sản sinh ra mã hữu hiệu; nó có thể là một thiết kế tối thiểu mà theo đó là việc thực hiện là càng chặt càng tốt; hoặc nó là thiết kế bảo dưỡng được tốt nhất hay chỉ là tiêu chuẩn tốt cho người dùng. Một thiết kế bảo dưỡng tốt có thể thích nghi với việc cải biên các chức năng và việc thêm các chức năng mới. Do đó, thiết kế như thế phải là dễ hiểu và việc sửa đổi chỉ có hiệu ứng cục bộ. Các thành phần của thiết kế là kết dính theo nghĩa là tất cả các phần trong thành phần đó phải có một quan hệ logic chặt chẽ. Các thành phần ấy phải là được nối ghép lỏng lẻo. Sự nối ghép là một độ đo của tính độc lập của các thành phần. Nối ghép càng lỏng lẻo thì càng dễ thích nghi.

Thực tế, đã có một vài công việc được tiến hành để thiết lập độ đo chất lượng thiết kế dùng để xem một thiết kế có là tốt hay không.

4.4.1. Sự kết dính

Sự kết dính của một thành phần là độ đo về tính khớp lại với nhau. Một thành phần hẳn thực hiện một chức năng logic hoặc thực hiện một thực thể logic. Tất cả các phần của thành phần đó đều tham gia vào việc thực hiện đó. Nếu một thành phần không trực tiếp tham gia vào việc chức năng logic đó thì mức độ kết dính của nó là thấp.

Theo một số chuyên gia thì có bảy mức kết dính theo thứ tự tăng dần sau đây:

a)

Kết dính gom góp: Các phần của thành phần không liên quan với nhau, song lại bị bó vào một thành phần.

b)

Hội hợp logic: Các thành phần cùng thực hiện các chức năng tương tự chẳng hạn như vào, xử lý lỗi,... là được đặt vào cùng một thành phần.

c)

Kết dính theo thời điểm: Tất cả các thành phần cùng hoạt hoá một lúc, chẳng hạn như khởi sự và kết thúc, là được bó lại với nhau.

d)

Kết dính thủ tục: Các phần tử trong thành phần được ghép lại trong một dãy điều khiển.

e)

Kết dính truyền thông: Tất cả các phần tử của thành phần cùng thao tác trên một dữ liệu vào và đưa cùng một dữ liệu ra.

f)

Kết dính tuần tự: Trong một thành phần, ra của phần tử này là vào của phần tử khác.

g)

Kết dính chức năng: Mỗi phần của thành phần đều là cần thiết để thi hành cùng một chức năng nào đó.

4.4.2. Sự ghép nối

Ghép nối liên quan đến kết dính. Nó chỉ ra độ ghép nối giữa các đơn vị của chương trình. Hệ thống có ghép nối cao sẽ có độ ghép nối mạnh giữa các đơn vị, các đơn vị phụ thuộc lẫn nhau. Hệ thống nối ghép lỏng lẻo làm cho các đơn vị là độc lập hoặc là tương đối độc lập với nhau.

Các module là được ghép nối chặt chẽ nếu chúng dùng các biến chung và nếu chúng trao đổi các thông tin điều khiển (ghép nối chung nhau và ghép nối điều khiển). Ghép nối lỏng lẻo đạt được khi đảm bảo rằng các thông tin biểu diễn là được giữ trong thành phần này và giao diện dữ liệu của nó với các đơn vị khác lại thông qua danh sách tham số của nó.

Tiêu chuẩn của các ghép nối trong chương trình được đánh giá như sau:

- Một phép nối chuẩn là một phép gọi tới một module khác bằng tên.

           - Một phép nối điều khiển xấu là một phép chuyển tới bất kỳ một điểm vào thứ cấp nào được xác định trong một module khác.

- Một phép nối dữ liệu xấu là một sự liên hệ tới dữ liệu xác định trong một module khác nhưng không phải bởi một phép truyền tường minh qua một phép nối chuẩn.

- Một ghép cặp (couple) tính toán là một mục dữ liệu dùng chung được module nhận dùng làm cơ sở tính toán hay lập chỉ mục, nhưng không phải để lập quyết định.

4.4.3. Sự hiểu được

            Sự hiểu được liên quan tới một số các đặc trưng thành phần sau đây:

a)

Tính kết dính: Có thể hiểu được thành phần đó mà không cần tham khảo đến một thành phần nào khác hay không?

b)

Đặt tên: Phải chăng là mọi tên được dùng trong thành phần đó đều có nghĩa? Tên có nghĩa là những tên phản ánh của thực thể trong thế giới thực được mô hình bởi thành phần đó.

c)

Soạn tư liệu: Thành phần có được soạn thảo tư liệu sao cho ánh xạ giữa các thực thể của thế giới thực và thành phần đó là rõ ràng?

d)

Độ phức tạp: độ phức tạp của các thuật toán được dùng để thực hiện thành phần đó là như thế nào? Từ phức tạp ở đây được dùng theo nghĩa không hình thức. Độ phức tạp cao ám chỉ nhiều quan hệ giữa các thành phần khác nhau của thành phần thiết kế đó và một cấu trúc logic phức tạp mà nó dính líu đến độ sâu lồng nhau của phát biểu. Các thành phần phức tạp là khó hiểu, vì thế người thiết kế nên làm cho thiết kế thành phần càng đơn giản càng tốt.

Đa số công việc về đo chất lượng thiết kế được tập trung vào cố gắng đo độ phức tạp của thành phần và từ đó thu được một vài độ đo về sự dễ hiểu của thành phần. Độ phức tạp phản ánh độ dễ hiểu, nhưng cũng có một số các nhân tố khác ảnh hưởng đến độ dễ hiểu, chẳng hạn như tổ chức dữ liệu và kiểu cách mô tả thiết kế. Các số đo độ phức tạp có thể chỉ cung cấp một chỉ số cho độ dễ hiểu của một thành phần.

Sự thừa kế trong một thiết kế hướng đối tượng phản ánh độ dễ hiểu. Nếu sự thừa kế được dùng để gắn các chi tiết thiết kế thì thiết kế sẽ dễ hiểu hơn. Mặc khác nếu sử dụng sự thừa kế đòi hỏi người đọc thiết kế phải phải nhìn nhiều lớp đối tượng khác nhau trong tôn ti thừa kế thì độ dễ hiểu của thiết kế là được rút gọn.

4.4.4.

Sự thích nghi được

Nếu một thiết kế là nhằm được bảo trì thì nó phải là sẳn sàng thích nghi được. Dĩ nhiên điều đó suy ra rằng các thành phần của chúng nên được ghép nối lỏng lẻo. Tuy nhiên sự thích nghi được lại có nghĩa là thiết kế đó phải được soạn thảo tư liệu tốt, tư liệu thành phần phải là dễ hiểu và kiên định với sự thực hiện, và nghĩa là sự thực hiện phải được viết ra trong cách dễ đọc.

Một thiết kế dễ thích nghi hẳn là có mức nhìn thấy được cao. Nó có một quan hệ rõ ràng giữa các mức khác nhau của thiết kế. Người đọc thiết kế có thể tìm được các biểu diễn liên quan sao cho lược đồ cấu trúc biểu diễn sự vận chuyển của biểu đồ dòng dữ liệu.

Cần phải dễ dàng kết hợp chặt chẽ các biến đổi về thiết kế  trong toàn bộ tư liệu thiết kế.

Nếu không như vậy thì các thay đổi thiết kế có thể sẽ không được đưa vào trong các mô tả liên quan. Tư liệu thiết kế đó có thể trở nên không kiên định. Các biến đổi tiếp sau là khó thực hiện (thành phần thiết kế này là ít thích nghi được) vì rằng sự cải biên đó không thể dựa vào tính kiên định của của tư liệu thiết kế.

Để có độ thích nghi tối ưu thì mỗi thành phần phải là tự chứa. Một thành phần có thể là ghép nối lỏng lẻo theo nghĩa chỉ là hợp tác với các thành phần khác thông qua việc chuyển các thông báo. Điều này không giống như là tự chứa vì rằng thành phần đó có thể dựa trên các thành phần khác chẳng hạn như các chức năng hệ thống hoặc các chức năng xử lý sai. Sự thích nghi với một thành phần có thể dính líu với sự thay đổi các phần của thành phần đó mà nó dựa trên các chức năng ngoại nên đặc tả của các chức năng ngoại này cũng xét đến sự cải biên đó.

Muốn tự chứa một cách hoàn toàn thì một thành phần không nên dùng các thành phần khác được xác định ngoại lai. Tuy nhiên, điều đó lại mâu thuẫn với kinh nghiệm nói rằng các thành phần hiện có nên là dùng lại được. Vậy là cần có một cân bằng giữa tính ưu việt của sự dùng lại các thành phần và sự mất mát tính thích nghi được của thành phần.

4.4.5. Một số yêu cầu thiết kế

+ Linh hoạt đối với những yêu cầu thay đổi không định trước.

+ Dễ thử nghiệm.

+ Tính sáng sủa, dễ đọc

+ Kích thước module nhỏ

+ Tính độc lập module (tính mở/đóng giứa các module), sử dụng yếu tố "hộp đen"

+ Phải quan hệ chặt chẽ giữa thiết kế và yêu cầu.

+ Mỗi module hoàn toàn độc lập, nó thực hiện một chức năng duy nhất và thực hiện trọn vẹn chức năng đó.

+ Mọi thứ trong module ràng buộc với nhau qua việc xử lý nối tiếp nhau trên cùng một dòng dữ liệu.

+ Mọi thứ trong module được điều khiển bởi cùng một dữ liệu vào, hay cùng một phức hợp thiết bị, hay cùng thực hiện từng phần của cùng một kết xuất.

+ Module có thể hiểu được hoàn toàn dựa vào những tham biến truyền cho nó và nhận từ nó.

+ Khi thiết kế cố gắng giảm thiểu cấu trúc bằng việc tản ra nhiều và cố gắng co cụm khi chiều sâu tăng thêm.

+ Giữ phạm vi hiệu quả của một module bên trong phạm vi kiểm soát của module đó.

- Phạm vi hiệu quả của module m được định nghĩa là tất cả các module khác bị ảnh hưởng bởi một quyết định thực hiện trong module m.

- Phạm vi kiểm soát của module m là tất cả các module và mọi module thuộc cấp và thuộc cấp cuối cùng đối với module m.

+ Ước lượng giao diện module để giảm độ phức tạp, dư thừa và tăng tính nhất quán.

+ Xác định các module có chức năng dự kiến được.

+ Cố gắng giữ các module một đầu vào và một đầu ra, tránh các "mối nối bệnh hoạn".

CHƯƠNG V>KIỂM TRA  CHẤT LƯỢNG PHẦN MỀM

1.Kiểm thử là gi?

IEEE

: Kiểm thử là vận hành hệ thống hay thành phần dưới những điều kiện xác định, quan sát hoặc ghi nhận kết quả và đưa ra đánh giá về hệ thống hoặc thành phần đó

Myers

: Kiểm thử là tiến trình thực thi chương trình với mục đích tìm thấy lỗi

¡

Kiểm thử # gỡ rối (debug)

§

Kiểm thử:

▪

nhằm để phát hiện lỗi

§

Gỡ rối:

▪

Xác định bản chất lỗi và định vị lỗi trong chương trình

▪

Tiến hành sửa lỗi

¡

Một error: là một sự nhầm lẫn hay một sự hiểu sai trong quá trình phát triển phần mềm của người phát triển

¡

Một lỗi (fault, defect): xuất hiện trong phần mềm như là kết quả của một sai xót

¡

Một hỏng hóc (failure): là kết quả của một lỗi xuất hiện làm cho chương trình không hoạt động được hay hoạt động nhưng không cho kết quả như mong đợi

2. Đặc điểm của việc kiểm tra phần mềm? Sự khác nhau của kiểm tra hộp trắng và hộp đen.

. Đặc điểm của kiểm thử

6.3.2.1.

Các hạn chế của kiểm thử

·

Do kiểm thử là chạy thử chương trình với tập dữ liệu giả nên không thể khẳng định tính đúng của chương trình do bản chất quy nạp không hoàn toàn của nó.

·

Trong nhiều trường hợp, việc kiểm thử thường được thực hiện từ những giai đoạn đầu của quá trình cài đặt sản phẩm.

·

Các chương trình nên được kiểm chứng theo hai kỹ thuật: kiểm thử và chứng minh. Và nếu có thể nên khẳng định tính đúng của chương trình thông qua văn bản chương trình

Như vây, một chương trình tuyệt đối đúng phải được thực hiện thông qua: tính đúng đắn của thuật toán và tính tương đương của chương trình với thuật toán (được thể hiện ở chứng minh thông qua văn bản chương trình).

Việc kiểm thử chương trình chỉ là nhìn sự kiện đưa ra kết luận do vậy không thể khẳng định một chương trình tuyệt đối đúng bằng kiểm thử. Tuy vậy, bộ dữ liệu kiểm thử phải phủ kín mọi trường hợp cần đánh giá.

Thêm vào đó, trong quá trình kiểm thử, ta thưòng mắc phải các đặc trưng của nguyên lý chủ quan như sau:

·

Bộ dữ liệu Test không thay đổi trong quá trình xây dựng phần mềm

·

Chỉ Test các trường hợp chính thống, hợp lệ, không quan tâm đến các cận và các sự cố

·

Cài đặt chức năng nào thì chỉ Test riêng chức năng đó, không chỉ Test tổng hợp chức năng vừa cài đặt với các chức năng đã cài đặt trước đó.

·

Người Test đồng thời là người xây dựng phần mềm tức vừa đá bóng, vừa thổi còi.

6.3.2.2.

Các loại hình kiểm thử

·

Kiểm thử lược đồ hệ thống: chỉ quan tâm đến các bản chọn (menu) đánh giá tính hợp lý, khả năng chọn một mục, khả năng di chuyển qua mục khác, tính đủ, tính khoa học của các chức năng.

·

Kiểm thử cận dưới

·

Kiểm thử cận trên: cho hệ thống thực hiện đến mức tối hạn.

·

Kiểm thử qua sự cố: tạo ra các sự cố để kiểm thử phần mềm.

6.3.2.3.

Nguyên tắc kiểm thử

·

Nguyên tắc khách quan: người kiểm thử không phải là tác giả của phần mềm đang kiểm thử

·

Nguyên tắc ngẫu nhiên: dữ liệu và chức năng được chọn, tuy có chủ đích nhưng không phải xuất hiện theo thứ tự nhất định.

·

Nguyên tắc "người sử dụng kém": hệ thống được một người sử dụng có trình độ thấp (ở mức chấp nhận được) dùng thử. (Người này có thể gây các sự cố có thể không lường trước được của hệ thống )

·

Nguyên tắc "kẻ phá hoại": hệ thống rơi vào tay có trình độ nghiệp vụ cao, chủ ý phá hoại. "Trình độ" ở đây thuộc lĩnh vực công nghệ thông tin hoặc lĩnh vực phần mềm đang hướng tới.

6.3.2.4.

Kỹ thuật kiểm thử

·

Kỹ thuật đối xứng: dựa vào tính đối xứng của các thao tác hoặc tập dữ liệu để xậy dựng bộ dữ liệu Test.

·

Kỹ thuật đám đông

·

Kỹ thuật kiểm thử trên dữ liệu thật: cho hệ thống vận hành với các tập dữ liệu thật đã thu được từ trước để so sánh và đánh giá kết quả

·

Kỹ thuật kiểm thử trên thị trường thật: cho hệ thống vận hành trên thị trường thật (không chính thức) để so sánh với các hệ thống chính được dùng và đánh giá kết quả.

·

Kỹ thuật đối sánh: cho thực hiện với một vài sản phẩm khác với cùng các chức năng giống nhau và trên cùng các tập dữ liệu rồi lập bảng so sánh các chức năng.

6.3.2.5.

Quá trình kiểm thử

Trừ hệ thống nhỏ, nói chung không nên kiểm thử nguyên cả khối; quá trình kiểm thử có thể chia 5 giai đoạn:

1.

Thử đơn vị

2.

Thử module

3.

Thử hệ con

4.

Thử hệ thống

5.

Thử nghiệm thu: còn gọi thử anpha.

Khi hệ thống được đem bán còn phép thử beta: phân phối hệ thống cho một số người dùng đồng ý dùng thử và báo cáo lại các vấn đề cho người phát triển hệ thống

**Sự khác nhau của kiểm tra hộp trắng và hộp đen.

6.2.2.1. Kiểm tra Black-box

Kiểm tra hộp đen, black-box, coi xử lý kết quả như là minh chứng bởi dữ liệu. Khái niệm kiểm tra là black-box không quan tâm logic. Khuynh hướng này hiệu quả đối với các modul chức năng đơn và các hệ thống cấp cao. Ba phương pháp chính là:

·

Phân hoạch cân bằng:

Mục đích của phương pháp này là tối thiểu các trường hợp kiểm tra cho trước, các mục dữ liệu vào được chia thành các nhóm dữ liệu có vai trò cân bằng nhau, mỗi nhóm đại diện cho một tập dữ liệu. Nguyên tắc là bằng cách kiểm tra triệt để một mục của mỗi tập hợp, chúng ta có thể chấp nhận tất cả các mục tương đương khác của tập hợp đó cũng sẽ được kiểm tra một cách kỹ càng.

·

Phân tích cực biên:

Phân tích giá trị cực biên là một dạng nghiêm ngặt của phân hoạch cân bằng có sử dụng các giá trị biên hơn là bất cứ giá trị nào trong tập cân bằng. Ví dụ: miền giá trị của tháng là 1 – 12 và ngoài là 0 và 13. Thì 4 kiểm tra ứng với bốn trường hợp sẽ được kiểm tra phân tích cực biên thường xuyên được dùng tại các mức modul để xác định các mục dữ liệu đặc trưng cho testing.

·

Đoán lỗi:

Dựa trên cơ sở trực giác và kinh nghiệm, các chuyên gia có thể dễ dàng kiểm tra các điều kiện lỗi bằng cách đoán cái nào dễ xảy ra nhất. Ví dụ, chia 0, nếu modul có phép chia, nên dùng phép chia 0. Vì dựa trên trực giác, nên phép thử này khó tìm hết các lỗi.

Một nhược điểm của phân hoạch cân bằng và phân tích cực biên là tổ hợp của các miền hợp không được xác định. Để bổ sung, người ta dùng sơ đồ nguyên nhân – kết quả (Cause – Effect Graphing). Sơ đồ nguyên nhân – kết quả chỉ ra các đầu ra và thông tin di chuyển như là hệ quả và các đầu vào gây ra hệ quả trên. Các ký hiệu graphic xác định tương tác, lựa chọn, logic và các điều kiện tương đương. Một vòng đại diện một dãy các thao tác không có điểm quyết định hoặc điều khiển. Mỗi dòng biểu diễn một lớp cân bằng của dữ liệu và các điều kiện sử dụng nó. Mỗi lần graph được thực hiện thì ít nhất một giá trị có nghĩa và một không có nghĩa cho mỗi tập được thử.

6.2.2.2. White-box testing

Có ba loại kiểm tra hộp trắng là kiểm tra logic -logic test, chứng minh toán học -mathematical proof và Cleanroom testing.

1. Logic test

Logic test có thể được chi tiết đến mức lệnh. Trong khi thực hiện của mọi lệnh là mục đích đáng khen ngợi, nó có thể không kiểm tra tất cả các điều kiện thuộc chương trình. Ví dụ, ít nhất 2 kiểm tra cho một kiểm tra 2 điều kiện (1 đúng và 1 sai). Cố gắng kiểm tra tất cả các điều kiện lẽ dĩ nhiên là không thể thực hiện được về thực tiễn. Ví dụ trong 1 module có 10 thao tác qua 4 vòng lặp thì có 5,5 triệu trường hợp kiểm tra. Do đó phải có phương pháp lựa chọn.

Logic kiểm tra nhìn vào mỗi quyết định trong module và sản sinh các dữ liệu để tạo tất cả các kết quả ra có thể. Có một vấn đề với logic test tại mức này là chúng không test tình trạng của module đối với đặc tả. Nếu kiểm tra được phát triển dựa trên đặc tả, mà đặc tả được dịch khác nhau bởi người lập trình thì kiểm tra sẽ không đúng. Giải pháp là đòi hỏi đặc tả chương trình đủ chi tiết và logic. Điều này có thể phù hợp với ngôn ngữ thế hệ 1 và 2.

Các kiểm tra nhiều điều kiện tạo mỗi kết quả ra của tiêu chuẩn đa quyết định và nhiều điểm vào module. Các kiểm tra đòi hỏi việc phân tích xác định được bên quyết định đa tiêu chuẩn. Nếu các biên được xác định không chính xác, thì kiểm tra không hiệu quả. Khi được thiết kế phù hợp, test logic đa điều kiện có thể tối thiểu hoá các trường hợp kiểm tra để kiểm tra nhiều nhất các điều kiện. Sự sử dụng kỹ thuật này đòi hỏi luyện tập và kỹ năng.

3.Tiển trình kiểm thử?

5.

  Độ tin cậy của phần mềm?  Vì sao phải đảm bảo chất lượng phần mềm.

**Độ tin cậy của phần mềm? 

Độ tin cậy của một hệ phần mềm là độ đo về mức độ tốt của các dịch vụ mà hệ cung cấp cho máy tính. Cần chú ý là người dùng không xét rằng các dịch vụ là quạn trọng như nhau: chẳng hạn một hệ điều khiển máy bay có thể rất, rất hiếm khi thất bại, nhưng nếu chúng có thất bại gây ra tai nạn máy bay thì các người bị nạn và thân nhân người bị nạn không thể xem hệ đó là đáng tin.

Độ tin cậy là một đặc trưng động của hệ thống, nó là một hàm của số các thất bại phần mềm. Một thất bại phần mềm là một sự kiện thi hành mà khi đó phần mềm hành xử không như người ta mong đợi. Chú ý rằng một thất bại phần mềm khác nột hư hỏng phần mềm. Hư hỏng phần mềm là một đặc trưng tĩnh, và nó sẽ gây ra thất bại phần mềm khi mà mã lỗi được thi hành với một tập hợp đặc biệt các thông tin vào. Các hư hỏng không phải luôn luôn xuất đầu lộ diện, vì vậy đọ tin cậy phụ thuộc vào việc sử dụng hệ thống như thế nào. Không thể đưa ra một phát biểu đơn giản và khái quát về độ tin cậy phần mềm.

Các hư hỏng phần mềm không phải là các khuyết tật của chương trình. Một hành xử bất ngờ có thể xảy ra khi mà phần mềm phù hợp với các yêu cầu của nó, nhưng mà chính các yếu tố đó lại không đầy đủ. Các sai sót trong các tư liệu phần mềm cũng có thể dẫn đến các hành vi bất ngờ mặc dầu rằng phần mềm không có khiếm khuyết.

Có công trình nghiên cứu đã chỉ ra rằng có thể rút bỏ 60% các khiếm khuyết mà chỉ có thể cải tạo được 3% độ tin cậy. Cũng có người đã chú ý rằng nhiều khiếm khuyết trong sản phẩm chỉ là kết quả của hàng trăm hoặc hàng nghìn tháng sử dụng.

**Vì sao phải đảm bảo chất lượng phần mềm

Kiểm tra chất lượng phần mềm là một hoạt động khó khăn để chấp nhận về mặt ý thức vì chúng ta đang cân nhắc công việc của chúng ta hoặc của đồng nghiệp để tìm lỗi. Sau quá trình làm việc trong nhóm và trở thành thành viên, chúng ta ngại tìm ra lỗi và không phát hiện được ra chúng thông qua kiểm tra. Khi một người nào đó tiến hành kiểm tra lại không phải là thành viên của dự án, ví dụ một chuyên gia kiểm tra, họ được nhìn nhận như là một kẻ thù.

Thêm vào đó, kiểm tra chất lượng phần mềm lại là một hoạt động khó được chấp nhận đối với việc quản lý vì nó tốn kém, mất thời gian và hiếm khi phát hiện được lỗi. Kết quả là phần lớn các ứng dụng không được kiểm tra đầy đủ và được phát hành với lỗi tiềm ẩn.

Tuy vậy, chất lượng phần mềm cao là một mục tiêu quan trọng của nhóm phát triển phần mềm. Do vậy, cần và phải  đảm bảo các tiêu chuẩn của phần mềm như đã đề cập ở chương 2. Đảm bảo chất lượng phần mềm là một hoạt động có hệ thống và kế hoạch. Nó bao gồm nhiều nhiệm vụ liên kết với các hoạt động chính sau:

+ Áp dụng các phương pháp kỹ thuật,

+ Tiến hành các cuộc xét duyệt kỹ thuật chính thức,

+ Kiểm thử phần mềm,

+ Buộc tôn trọng các chuẩn,

+ Kiểm soat thay đổi,

+ Đo chất lượng,

+ Báo cáo, lưu giữ kết quả.

Theo chuẩn ANSI/IEEE, kế hoạch đảm bảo chất lượng phần mềm như sau:

1*Mục đích của kế hoạch

2*Tham khảo

3*Quản lý

+Tổ chức

+Nhiệm vụ

+Trách nhiệm

4*Tài liệu

+Mục đích

+Tài liệu công nghệ phần mềm cần thiết

+Các tài liệu khác

5*Chuẩn, thực hành và quy ước

+Mục đích

+Quy ước

6*Xét duyệt và kiểm toán

+Mục đích

+Các yêu cầu xét duyệt

 .Xét duyệt yêu cầu phần mềm

 .Xét duyệt thiết kế

 .Kiểm chứng phần mềm và xét duyệt hợp lệ

 .Kiểm toán chức năng

 .Kiểm toán vật lý

 .Kiểm toán trong tiến trình

 .Xét duyệt quản lý

7*Quản lý cấu hình phần mềm

8*Báo cáo vấn đề và cách sửa chữa

9*Công cụ, kỹ thuật và phương pháp luận

10-*Kiểm soát mã

11*Kiểm soát phương tiện

12*Kiểm soát người cung cấp

13*Thu thập bảo trì và ghi nhớ báo cáo

            Việc đảm bảo chất lượng phần mềm là một hoạt động bản chất cho bất kỳ nhóm phát triển phần mềm nào sản xuất ra phần mềm cho người sử dụng.

6.Lý do của kiểm thử?

¡

Hợp thức hóa, thẩm định (validation)

§

Chỉ ra rằng sản phẩm đáp ứng yêu cầu của người sử dụng

¡

Xác minh(verification)

§

Chỉ ra rằng sản phẩm thỏa mãn đặc tả yêu cầu

¡

Phân biệt validation và verification

§

Verification: Chúng ta đang xây dựng một sản phẩm đúng?

§

Validation: Chúng ta đang xây dựng đúng sản phẩm?

§

Thứ tự thực hiện: verification

è

validation

7.Khó khăn của kiểm thử:

¡

Về mặt con người:

§

Thiếu đào tạo bài bản

§

Ít chú trọng vai trò kiểm thử

¡

Về mặt kỹ thuật

§

Không tồn tại một thuật toán tổng quát có thể chứng minh sự đúng đắn hoàn toàn của bất kì một chương trình nào

CHƯƠNG VI> BẢO TRÌ VÀ QUẢN LÝ THAY ĐỔI PHẦN MỀM

Question:

1.Bảo trì phần mềm là gi?

Bảo trì là giai đoạn cuối cùng của một chu trình phát triển phần mềm. Các chương trình máy tính luôn thay đổi- phải mở rộng, sửa lỗi, tối ưu hoá,...và theo thống kê thì bảo trì chiếm đến 70% toàn bộ công sức bỏ ra cho một dự án phần mềm. Do vậy, bảo trì là một hoạt động phức tạp nhưng nó lại là vô cùng cần thiết trong chu trình sống của sản phẩm phần mềm để đảm bảo cho phần mềm phù hợp với người sử dụng.

            Do nhu cầu phát triển của các hệ thống thông tin, rất hiếm hay không muốn nói là không thể có một hệ thống thông tin không có sự thay đổi trong suốt chu trình sống của nó. Để duy trì tính đúng đắn, trật tự trong giai đoạn bảo trì thì quản lý sự thay đổi phần mềm là một hoạt động cần thiết song song.

2.Các hoạt động nào trong bảo trì phần mềm là chính yếu?

Bảo trì phần mềm là phức tạp và chúng ta có thể chia hoạt động bảo trì ra làm bốn hoạt động như sau:

1.

Bảo trì hiệu chỉnh

Công việc bảo trì đầu tiên cần phải thực hiện là do việc kiểm tra chương trình không thể tránh được mội lỗi ẩn chứa bên trong một hệ phần mềm lớn. Trong khi sử dụng bất kỹ một chương trình lớn nào, các lỗi sẽ được báo về lại cho người phát triển.

Bảo trì hiệu chỉnh chính là quá trình phân tích và hiệu chỉnh một hay nhiều lỗi của chương trình.

2.

Bảo trì tiếp hợp

Hoạt động thứ hai diễn ra bởi sự thay đổi thường xuyên môi trường. Những thế hệ phần cứng mới dường như được công bố theo chu trình 24 tháng một lần. Những hệ điều hành mới hay phiên bản mới của các hệ cũ đều đặn xuất hiện; thiết bị ngoại vi và các thành phần hệ thống khác liên tục được nâng cấp và thay đổi. Thời gian hữu dụng của một phần mềm ứng dụng mặt khác lại dễ dàng vượt qua thời hạn mười năm, lâu hơn môi trường hệ thống đã phát triển nó đầu tiên.

Bảo trì tiếp hợp là hoạt động sửa đổi phần mềm để thích ứng được với những thay đổi của môi trường.

3.

Bảo trì hoàn thiện

Hoạt động thứ ba diễn ra khi một phần mềm đã được hoàn tất thành công. Hoạt động này chiếm hầu hết các công sức tiêu tốn cho việc bảo trì phần mềm. Lúc sử dụng, các yêu cầu về những khả năng mới, các thay đổi những chức năng đã có, và các mở rộng tổng quát được người dùng gửi đến.

Để thỏa mãn những yêu cầu phát triển của người sử dụng, ta tiến hành bảo trì hoàn thiện.

4.

Bảo trì phòng ngừa

Bảo trì phòng ngừa là hoạt động bảo trì diễn ra khi phần mềm được thay đổi để cải thiện tính năng bảo trì hay độ tin cậy trong tương lai hoặc để cung cấp một nền tảng tốt hơn cho những mở rộng sau này.

Bảo trì phòng ngừa, hoạt động này vẫn còn nhiều xa lạ trong thế giới phần mềm hiện nay.

Các thuật ngữ dùng để mô tả ba hoạt động bảo trì đầu tiên là do Swanson đề xướng. Thuật ngữ thứ tư thường được dùng trong việc bảo trì phần cứng hay các hệ thống vật lý khác. Tuy nhiên cần chú ý rằng những điểm tương tự giữa bảo trì phần mềm và bảo trì phần cứng có thể gây nhầm lẫn. Phần mềm khác với phần cứng, không thể tận dụng được, vì vậy hoạt động bảo trì phần cứng chủ yếu - thay thế các bộ phận bị hỏng hóc hay gãy vỡ - không được kể đến.

Trong thực tế của hoạt động bảo trì, các nhiệm vụ được làm như một phần của bảo trì tiếp hợp và bảo trì hoàn thiện cũng giống như các nhiệm vụ cần làm trong giai đoạn phát triển của một chu trình phần mềm. Để tiếp hợp hay hoàn thiện, chúng ta đều phải xác định yêu cầu, thiết kế lại, tạo mã và kiểm tra phần mềm có được. Thông thường các nhiệm vụ đó đã được gọi là bảo trì rồi.

3. Một số hình thức bảo trì phần mềm?

7.4.1. Bảo trì mã chương trình xa lạ

Các chương trình được gọi là mã chương trình xa lạ nếu:

·

Không một thành viên này trong phòng kỹ thuật tiếp tục phát triển chương trình đó nữa,

·

Không tiếp tục áp dụng lý thuyết phát triển, và vì vậy tồn tại vấn đề thiết kế nghéo nàn và ít tài liệu (theo tiêu chuẩn ngày nay), và

·

Cấu trúc khối chưa được thiết kế theo tiêu chuẩn, và các khái niệm về thiết kế có cấu trúc chưa được áp dụng.

Yourdon đưa ra một số đề nghị hữu dụng cho người quản trị hệ thống phải bảo trì các chương trình xa lạ như sau:

·

Nghiên cứu chương trình trước khi bạn bị đặt vào "chế độ khẩn cấp". Cố gắng thu nhận được càng nhiều thông tin cơ sở càng tốt...

·

Cố gắng làm quen với toàn bộ các luồng điều khiển của chương trình; trước hết bỏ qua các chi tiết về mã chương trình. Sẽ rất có ích khi vẽ cho riêng bạn sơ đồ cấu trúc và sơ đồ luồng hoạt động mức cao, nếu chưa có bản nào tồn tại.

·

Đánh giá tình hình hợp lý của tài liệu hiện có; bổ sung thêm các lời chú thích của bản thân bạn vào chương trình nguồn nếu bạn thấy cần thiết.

·

Sử dụng tốt các danh sách chỉ dẫn tham khảo, các bảng ký hiệu, và các trợ giúp khác thông thường được chương trình dịch và/hoặc assembler cung cấp.

·

Thực hiện sửa đổi chương trình với sự chú ý lớn nhất. Lưu ý tới kiểu và dạng của chương trình tại tất cả các chỗ có thể. Đánh dấu trên chương trình những lệnh bạn đã sửa.

·

Đừng loại bỏ chương trình trừ khi bạn chắc chắn nó không được sử dụng nữa.

·

Đừng cố sử dụng chung các biến tạm thời và vùng nhớ làm việc mà đã có sẵn trong chương trình. Thêm các biến của riêng bạn để tránh các rắc rối.

·

Giữ các bản ghi chép chi tiết (vê hoạt động bảo trì và các kết quả).

·

Tránh sự nóng vội vô lý ném chương trình cũ đi và viết lại nó.

·

Thực hiện các kiểm tra lỗi.

7.4.2.

Công nghệ phản hồi và công nghệ tái sử dụng

Công nghệ phản hồi -Reverse engineering- đối với phần mềm là đơn giản. Trong nhiều trường hợp, chương trình được tổ chức ngược không phải thuộc nhà cạnh tranh mà thuộc bản thân công ty. Bí mật cần khám phá là do không còn giữ được các đặc tả. Do đó tổ chức ngược đối với phần mềm là quá trình phân tích chương trình trong cố gắng biểu diễn lại các chương trình ở mức độ trừu tượng cao hơn mã nguồn. Tổ chức lại là quá trình khám phá thiết kế. Các công cụ của công nghệ phản hồi lấy ra dữ liệu, kiến trúc, các thông tin thiết kế thủ tục từ chương trình đã tồn tại.

Công nghệ tái sử dụng, Re-engineering,không đơn thuần phát hiện các thông tin thiết kế mà còn dùng các thông tin này để biến đổi hoặc tổ chức lại hệ thống đã tồn tại với mục đích cải thiện chất lượng. Trong nhiều trường hợp, phần mềm ứng dụng lại các chức năng của hệ thống tồn tại. Nhưng trong cùng thời điểm, nhà phát triển phần mềm cũng phải thêm các chức năng mới và/hoặc cải thiện các xử lý.

7.4.3. Bảo trì phòng ngừa

Bảo trì phòng ngừa các phần mềm máy tính là một vấn đề khá mới và còn đang được tranh cãi. Thay vì đợi cho đến khi nhận được yêu cầu bảo trì, các tổ chức phát triển hay bảo trì chọn một chương trình mà:

·

Sẽ được sử dụng trong một số năm định trước;

·

Hiện đang được sử dụng tốt,và

·

Dễ bị thay đổi hoặc nâng cấp trong tương lai gần.

Thoạt đầu ý kiến đề nghị phát triển lại một chương trình lớn khi một phiên bản đang làm việc đã tồn tại ta thấy dường như quá phung phí. Nhưng chúng ta hãy xem xét các điểm sau:

·

Chi phí để bảo trì một dòng mã lệnh có thể lớn hơn 20 tới 40 lần chi phí cho phát triển ban đầu dòng lệnh đó.

·

Thiết kế lại cấu trúc của phần mềm, với sự sử dụng các khái niệm thiết kế hiện tại có thể làm cho việc bảo hành tương lai dễ dàng hơn.

·

Bởi vì khuôn mẫu phần mềm đã tồn tại, năng suất phát triển chương trình chắc sẽ cao hơn mức trung bình nhiều.

·

Người sử dụng bây giờ đã làm quen với phần mềm. Vì vậy, các đòi hỏi mới và hướng thay đổi có thể tìm ra dễ dàng hơn nhiều.

·

Các công cụ CASE dành cho reverse engineering và re-engineering sẽ thực hiện tự động một số phần của công việc.

·

Một cấu hình phần mềm sẽ tồn tại trên sự hoàn thành của bảo trì phòng ngừa.

Khi một tổ chức phát triển phần mềm bán phần mềm như là một sản phẩm, bảo trì phòng ngừa được xem như "phiên bản mới" của chương trình. Nhiều hãng phát triển phần mềm lớn có thể có từ 500 tới 2000 sản phẩm chương trình trong phạm vi trách nhiệm của nó. Các chương trình như vậy có thể được xếp theo thứ tự ưu tiên và xem xét lại như các ứng cử cho bảo trì phòng ngừa.

7.4.4. Chiến lược phần mềm thành phần

Như đặc tính cổ điển của bảo hành phần cứng là tháo bỏ phần hỏng và thay thế bằng phụ tùng mới. Một khái niệm được gọi là nguyên mẫu phần mềm có thể dẫn tới việc phát triển các phụ tùng cho các chương trình.

Nguyên mẫu phần mềm là một quá trình mô hình hóa yêu cầu ngươi dùng trong một hay nhiều mức chi tiết, bao gồm cả các mô hình làm việc. Các tài nguyên của dự án được xếp đặt làm sao để sản xuất các phiên bản phần mềm được mô tả theo yêu cầu phải nhỏ đi. Phiên bản nguyên mẫu làm cho người dùng, người thiết kế và quản trị... có thể xem lại được phần mềm. Quá trình đó sẽ tiếp tục khi được đề nghị, với phiên bản đang chạy chuẩn bị sẵn sàng phát hành sau vài lần làm lại.

Nếu các mức nguyên mẫu khác nhau được phát triển, nó có thể có một bộ các phụ tùng phần mềm có thể được sử dụng khi nhận được yêu cầu bảo trì hiệu chỉnh. Ví dụ một module phân tích có thể được thiết kế và thực hiện theo hai cách khác nhau nhưng có cùng giao diện bên ngoài. Một phiên bản của module có được sử dụng trong phần mềm làm việc. Nếu module đó hỏng, một phụ tùng có thể được lắp thay ngay.

Mặc dù chiến lược phụ tùng thay thế cho phần mềm có vẻ khác thường một chút, nhưng không có bằng chứng gì nó tỏ ra tốn kém, khi chúng ta tính đến chi phí cho tất cả chu kỳ sống của phần mềm.

CHƯƠNG VII>QUẢN LÝ DỰ ÁN PHẦN MỀM

Question

1.

Khái niệm dự án và quản lý dự án

2.Trách nhiệm của người quản lý dự án

3.Các hoạt động quản lý dự án

Reply:

1.Khái niệm dự án và quản lý dự án

•

Dự án là một tập các công việc được thực hiện bởi một tập thể nhằm:

–

Đạt được một kết quả dự kiến

–

Trong thời gian dự kiến

–

Với một kinh phí dự kiến

•

Tập thể:

–

Có chuyên môn khác nhau

–

Công việc khác nhau

–

Thời gian tham gia khác nhau

–

Cùng phối hợp

•

Thời gian:

–

Thời gian bắt đầu

–

Thời gian kết thúc

–

Mốc thời gian (Thời điểm trung gian)

•

Kinh phí

–

Vốn đầu tư cho dự án

–

Có thể cấp thành nhiều giai đoạn

2.Trách nhiệm của người quản lý dự án

**Nhiệm vụ của người QLDA

•

Quản lý thời gian:

–

Lập lịch

–

Kiểm tra/đối chiếu các tiến trình với lịch biểu

–

Điều chỉnh lịch khi cần thiết

•

Quản lý tài nguyên:

–

Xác định, phân bổ và điều phối tài nguyên

•

Quản lý sản phẩm:

–

Thêm bớt chức năng phù hợp với yêu cầu của khách hàng

•

Quản lý rủi ro

–

Xác định, phân tích rủi ro và đề xuất giải pháp khắc phục

•

Tổ chức cách làm việc

**Trách nhiệm của người QLDA

•

Với tổ chức cấp trên, người tài trợ

–

Sử dụng vốn hiệu quả, báo cáo kịp thời

•

Với dự án và khách hàng

–

Giao đúng hạn, đảm bảo chất lượng

•

Với các thành viên đội dự án

–

Việc làm phù hợp

–

Thu nhập thỏa đáng

–

Tiến bộ

è

Áp lực lên nhà quản lý là rất lớn

3.Các hoạt động quản lý dự án

•

Xác định dự án phần mềm cần thực hiện

Xác định là dự án là bước đầu tiên của QLDA

. Nó được thể hiện thông qua bản đề xuất dự án

Để đề án được thông qua phải thỏa mãn:

•

Đáp ứng các yêu cầu của người đưa ra: yêu cầu chức năng, ràng buộc. Vì vậy cần đưa ra một số phương án và lựa chọn phương án thích hợp

•

Sau khi có phương án cần lập luận tính khả thi trên các mặt: kinh tế, thời gian, kỹ thuật, pháp lý,…

Nội dung bảnđềxuấtdựán:

•

Mục tiêu của dự án (đáp ứng yêu cầu gì)

•

Vấn đề và cơ hội (sự cấp thiết)

•

Giải pháp đề xuất (giải pháp công nghệ)

•

Các tiêu chuẩn và chọn lựa dự án

•

Phân tích lợi nhuận và chi phí  (khả thi kinh tế)

•

Các yêu cầu về nghiệp vụ (sự công tác)

•

Phạm vi dự án và trách nhiệm

•

Những cản trở và khó khăn chính

•

Phân tích các rủi ro

•

Tổng quan lịch trình thực hiện

•

Lập kế hoạch thực hiện dự án

Kế hoạch là bản dự kiến công việc (cái gì), người làm (ai), thời gian làm (khi nào, bao lâu), phương tiện dùng (cái gì, bao nhiêu), sản phẩm ra (cái gì), tiêu chí cần có (chất lượng)

•

Là công việc lặp lại suốt quá trình dự án

•

Có nhiều kế hoạch cần lập để quản lý dự án

•

Là công cụ chính để quản lý

Các loại  kế hoạch của dự án

•

Kế hoạch chất lượng

•

Mô tả thủ tục và các chuẩn chất lượng áp dụng

•

Kế hoạch thẩm định

•

Mô tả cách thức, nguồn lực và lịch trình thẩm định

•

Kế hoạch quản lý cấu hình

•

Mô tả cấu hình, thủ tục và tiến trình quản lý cấu hình

•

Kế hoạch bảo trì

•

Chỉ ra yêu cầu, chi phí và nguồn lực cần cho bảo trì

•

Kế hoạch phát triển đội ngũ

•

Mô tả số lượng, kĩ năng, kinh nghiệm của từng thành viên dự án cần

•

Tổ chức, quản lý, giám sát quá trình thực hiện dự án

•

Đóng dự án