1/  Kiến trúc phầnmềm

Saukhiđãcócáckháiniêmcơbảnnhấtvềphầnmềm,tiếpsauđâychúngtasẽđisâu vàotìmhiểucấutrúcchitiếtcáccấutrúcchitiếtcácthànhphầnbêntrongphầnmềm.Phần mềm bao gồm 3 thành phần:

a)Thành  phần giao tiếp(giaodiện)

-Chophéptiếpnhậncácyêucầuvềviệcmuốnthựchiệnvàcungcấpcácdữliệunguồn liên  quan  đến  công  việc  đó  hoặc  từ  các  thiết  bị  thu  thập  dữ  liệu .

-Chophéptrìnhbàycáckếtquảcủaviệcthựchiệncácyêucầuchongườidùnghoặcđiềukhiểnhọatđộngcácthiếtbịđiềukhiển

   -Mộtcáchtổngquátthànhphầngiaotiếplàhệthốngcáchàmchuyênvềviệcnhập/xuất dữliệu(hàmnhập/xuất)cùngvớihìnhthứctrìnhbàyvàtổchứclưutrữdữliệutươngứng, mụctiêuchínhcủacáchàmnàylàđưadữliệutừthếgiớibênngoàiphầnmềmvàobêntrong hoặc ngượclại.

b)Thành phần dữ liệu

  -Chophéplưutrữlại(hàmghi)cáckếtquảđãxửlý(việcmượnsáchđãđược  kiểmtra hợplệ,bảnglươngthángđãđượctính)trênbộnhớphụvớitổchứclưutrữđượcxácđịnh trước (tập tin có cấu trúc, tập tin nhị phân, cơ sởdữ liệu).

  -Chophéptruyxuấtlại(hàmđọc)cácdữliệuđãlưutrữphụcvụchocáchàmxửlý tương ứng.

-Mộtcáchtổngquátthànhphầndữliệulàhệthốngcáchàmchuyênvềđọcghidữliệu (hàmđọc/ghi)cùngvớimôhìnhtổchứcdữliệutươngứng.Mụctiêuchínhcủacáchàmnày là chuyển đổi dữ liệu giữa bộ nhớ chính và bộ nhớ phụ.

c)  Thành phần xử lý

-Kiểmtratínhhợplệcủacácdữliệunguồnđượccungcấptừngườidùngtheocácquy trìnhràngbuộctrongthếgiớithực

 -Tiếnhànhxửlýchorakếtquảmongđợitheoquyđịnhtínhtoáncósẵntrongthếgiới thựchoặctheo thuật giảitự đề xuất

 -Việc  xử  lýdựa  trêndữliệu  nguồn  từ  người  sử  dụng  cung  cấp  hoặcdữliệulưutrữđãcósẵnhoặccảhai tùyvàoxửlýcụthể.Tươngtự,việcxử lýchorakếtquảcóthểdùngđểxuấtchongườidùngxemquathànhphầngiaodiệnhaycùngcóthểlưutrữlại  quathànhphầndữlịêuhoặc cả hai

-Mộtcáchtổngquát,thànhphầnxửlýlàhệthốngcáchàmchuyênvềxửlýtínhtoán, biếnđổidữliệu.Cáchàmnàysẽdùngdữliệunguồntừcáchàmtrongthànhphầngiaodiện

2/ Tiêu chí đánh giá phần mềm

  A.  Tínhđúng đắn

Tínhđúngđắncủaphầnmềmđượcthểhiệnởchổsảnphẩmđó   thựchiệnđầyđủvà chínhxáccácyêucầucủangườidùng.Tínhđúngđắnởđâycầnphảihiểutheonghĩarộnglà chương  trình  cần  phải  thực  hiện  được  trong  cả  những  trường  hợp  mà  dữ  liệu  đầu  vào  là không hợp lệ.

B.  Tính tiếnhóa

           Chophépngườidùngcóthểkhaibáocácthayđổivềquiđịnhvớiphầnmềmtùytheo cácthayđổitrongthếgiớithựcliênquan

Sản phẩmcó thể mở rộng, tăng cường về mặt chức năng mộtcách dễ dàng.

 C.  Tínhhiệuquả

 Tính hiệu quả của một sản phẩmphầnmềmđược xác định qua các tiêu chuẩn sau:

-       Hiệu quả kinh tế hoặc ý nghĩa, giá trị thu được do áp dụng sản phẩmđó.

-       Tốcđộxửlýcủaphầnmềm(v)tínhbằngtỉlệgiữakhốilượngđốitượngcầnphải xử lý (m) và tổng thời gian (t) cần thiết để xử lý các đối tượngđó.

-       Sử dụng tối ưu tài nguyên của máy tính (CPU, bộnhớ…)

D.  Tính tiệndụng

Sản phẩmphải tính đếnnhững yếu tố tâmlý sau đây của người dùng:

-       Dễ học, có giao diệntrực quan tự nhiên.

-       Dễ thao tác,…

E.  Tính tương thích

Traođổidữliệuvớicácphầnmềmkháccóliênquan(Excel,Word…)

-       Giao tiếp nội bộ,Giao tiếp bên ngoài

F.  Tính tái sử dụng

Sảnphẩmphầnmềmcóthểápdụngchonhiềulĩnhvựctheonhiềuchếđộlàmviệc khác nhau.

        -Các phần mềmcùng lớp

-Các phần mềmkhác lớp

3/Quy trình sản xuất phần mềm

Trong quy trình phần mềm gồm 4 hoạt động cơ bản. Những hoạt động này bao gồm:

- Đặc tả: các chức năng của hệ thống và những ràng buộc khi vận hành hệ thống cần phải được xác định một cách đầy đủ và chi tiết.

- Thiết kế và cài đặt: phần mềm được xây dựng phải thoả mãn đặc tả của nó.

- Đánh giá & kiểm thử: phần mềm phải được đánh giá và thẩm định để đảm bảo rằng nó đã thoả mãn tất cả các yêu cầu.

- Cải tiến & bảo trì: phần mềm cần phải cải tiến và điều chỉnh để phù hợp với những thay đổi về yêu cầu hệ thống.

=>Với mỗi mô hình khác nhau thì các hoạt động này cũng được tổ chức theo các cách khác nhau.

4/ Các hoạt động trong quy sản xuất trình phần mềm

a/ Đặc tả phần mềm:là quy trình tìm hiểu và định nghĩa những dịch vụ nào được yêu cầu và các ràng buộc trong quá trình vận hành và xây dựng hệ thống.

- Nghiên cứu khả thi: Nghiên cứu khả thi giúp xác định những yêu cầu của người sử dụng có thoả mãn những công nghệ hiện tại hay không. Về góc độ kinh doanh, nghiên cứu khả thi nhằm xác định hệ thống đưa ra có mang lại lợi nhuận không. Việc nghiên cứu khả thi nên được thực hiện một cách nhanh chóng và không quá tốn kém. Kết quả của việc nghiên cứu khả thi sẽ xác định có nên tiếp tục xây dựng hệ thống nữa hay không.

- Phân tích và rút ra các yêu cầu: đây là quy trình đưa ra các yêu cầu hệ thống thông qua một số phương pháp như: quan sát hệ thống hiện tại, phỏng vấn và thảo luận với người sử dụng, phân tích nhiệm vụ, phân tích tài liệu hoặc hệ thống cũ … Trong pha này, chúng ta có thể phải xây dựng một hoặc nhiều mô hình hệ thống và các mẫu thử.

- Đặc tả yêu cầu: Pha này sẽ tư liệu hoá những thông tin thu thập được. Có hai loại yêu cầu cần được xác định:

* Yêu cầu của người sử dụng: là những yêu cầu bằng ngôn ngữ tự nhiên bổ sung thêm cho các biểu đồ của các dịch vụ mà hệ thống cung cấp và các ràng buộc vận hành của nó. Kiểu yêu cầu này được viết bởi người sử dụng.

* Yêu cầu hệ thống: là những tài liệu có cấu trúc mô tả chi tiết về các chức năng, dịch vụ và các ràng buộc vận hành của hệ thống. Yêu cầu hệ thống sẽ định nghĩa những gì cần phải xây dựng, cho nên nó có thể trở thành bản hợp đồng giữa khách hàng và nhà thầu.

- Đánh giá yêu cầu: pha này sẽ kiểm tra lại các yêu cầu xem chúng có đúng thực tế hay không, có thống nhất không, có đầy đủ không. Nếu phát hiện ra lỗi thì ta phải chỉnh sửa các lỗi này.

b/Thiết kế và cái đặt

+Thiết kế phần mềm là quá trình thiết kế cấu trúc phần mềm dựa trên những tài liệu đặc tả. Hoạt động thiết kế bao gồm những công việc chính sau:

- Thiết kế kiến trúc: Các hệ thống con cấu thành lên hệ thống cần xây dựng và mối quan hệ giữa chúng được xác định và tư liệu hoá.

- Đặc tả trừu tượng: với mỗi hệ thống con, phải có một bản đặc tả về các dịch vụ của nó và những ràng buộc khi nó vận hành.

- Thiết kế giao diện: với mỗi hệ thống con, các giao diện của nó với những hệ thống con khác phải được thiết kế và tư liệu hoá.

- Thiết kế thành phần: các dịch vụ cung cấp cho các thành phần khác và các giao diện tương tác với chúng phải được thiết kế.

- Thiết kế cấu trúc dữ liệu: cấu trúc dữ liệu được sử dụng để cài đặt hệ thống phải được thiết kế một cách chi tiết và cụ thể.

- Thiết kế thuật toán: Các thuật toán được sử dụng để cung cấp các dịch vụ phải được thiết kế chi tiết và chính xác.

+Cài đặt là quy trình chuyển đổi từ tài liệu đặc tả hệ thống thành một hệ thống thực, có thể vận hành được và phải loại bỏ các lỗi của chương trình.

c/kiểm thử và đánh giá

Đánh giá phần mềm hay còn gọi là kiểm tra và đánh giá được sử dụng để chỉ ra rằng hệ thống đã thực hiện theo đúng các đặc tả và thoả mãn mọi yêu cầu của khách hàng.Đánh giá phần mềm bao gồm các công đoạn: kiểm tra, xem xét lại, và kiểm thử hệ thống. Kiểm thử hệ thống tức là cho hệ thống thực hiện trên những trường hợp có dữ liệu thật được lấy từ tài liệu đặc tả hệ thống. Quy trình kiểm thử gồm các pha sau:

- Kiểm thử thành phần (đơn vị): các thành phần được kiểm thử một cách độc lập, thành phần có thể là một chức năng hoặc một đối tượng hoặc một nhóm các thực thể gắn kết với nhau.

- Kiểm thử hệ thống: kiểm thử toàn bộ hệ thống.

- Kiểm thử chấp thuận: kiểm thử trên dữ liệu của khách hàng để kiểm tra hệ thống có đáp ứng tất cả các yêu cầu của khách hàng hay không.

Khi chuyển giao hệ thống cho khách hàng thì quy trình kiểm thử beta sẽ được thực hiện. Khách hàng sẽ thông báo các lỗi cho đội dự án. Những lỗi này sẽ được chỉnh sửa và tiếp tục kiểm thử beta hoặc chuyển giao thực sự cho khách hàng.

d/bảo trì và cải tiến

Khi các yêu cầu hệ thống thay đổi theo sự thay đổi của các yêu cầu nghiệp vụ thì phần mềm phải cải tiến và thay đổi để hỗ trợ khách hàng. Thông thường chi phí để bảo trì và cải tiến thường đắt hơn nhiều so với chi phí xây dựng phần mềm.

5/ Các mô hình phát triển phầm mềm

a/mô hình thác nước

Các pha của mô hình thác nước bao gồm:

- Phân tích và xác định các yêu cầu

- Thiết kế hệ thống và phần mềm

- Cài đặt và kiểm thử đơn vị

- Tích hợp và kiểm thử hệ thống

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

Trong mô hình thác nước, năm pha trên phải được thực hiện một cách tuần tự; kết thúc pha trước, rồi mới được thực hiện pha tiếp theo. Do đó, nhược điểm chính của mô hình thác nước là rất khó khăn trong việc thay đổi các pha đã được thực hiện. Giả sử, pha phân tích và xác định yêu cầu đã hoàn tất và chuyển sang pha kế tiếp, nhưng lúc này lại có sự thay đổi yêu cầu của người sử dụng; thì chỉ còn cách là phải thực hiện lại từ đầu.

Cho nên, mô hình này chỉ thích hợp khi các yêu cầu đã được tìm hiểu rõ ràng và những thay đổi sẽ được giới hạn một cách rõ ràng trong suốt quá trình thiết kế. Tuy nhiên, trong thực tế có rất ít những hệ thống nghiệp vụ có các yêu cầu ổn định.

b/mô hình tiến triển (tiến hóa)

Mô hình xây dựng tiến triển dựa trên ý tưởng xây dựng một mẫu thử ban đầu và đưa cho người sử dụng xem xét; sau đó, tinh chỉnh mẫu thử qua nhiều phiên bản cho đến khi thoả mãn yêu cầu của người sử dụng thì dừng lại.

Có hai phương pháp để thực hiện mô hình này:

- Phát triển thăm dò: mục đích của nó là để làm việc với khách hàng và để đưa ra hệ thống cuối cùng từ những đặc tả sơ bộ ban đầu. Phương pháp này thường bắt đầu thực hiện với những yêu cầu được tìm hiểu rõ ràng và sau đó, bổ sung những đặc điểm mới được đề xuất bởi khách hàng. Cuối cùng, khi các yêu cầu của người sử dụng được thoả mãn thì cũng là lúc chúng ta đã xây dựng xong hệ thống.

- Loại bỏ mẫu thử: mục đích là để tìm hiểu các yêu cầu của hệ thống. Phương pháp này thường bắt đầu với những yêu cầu không rõ ràng và ít thông tin. Các mẫu thử sẽ được xây dựng và chuyển giao tới cho người sử dụng. Từ đó, ta có thể phân loại những yêu cầu nào là thực sự cần thiết và lúc này mẫu thử không còn cần thiết nữa. Như vậy, mẫu thử chỉ có tác dụng để làm sáng tỏ yêu cầu của người sử dụng.

tuy nhiên, nhược điểm của mô hình xây dựng tiến triển là: thiếu tầm nhìn của cả quy trình; các hệ thống thường hướng cấu trúc nghèo nàn; yêu cầu các kỹ năng đặc biệt (Ví dụ: các ngôn ngữ để tạo ra mẫu thử nhanh chóng).

Mô hình xây dựng tiến triển chỉ nên áp dụng với những hệ thống có tương tác ở mức độ nhỏ hoặc vừa; trên một phần của những hệ thống lớn; hoặc những hệ thống có thời gian chu kỳ tồn tại ngắn.

c/mô hình mẫu

Mô hình mẫu (prototype) được minh hoạ trong  Trong đó, qui trình được bắt đầu bằng việc 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 sau này, đồng thời ghi nhận tất cả những yêu cầu có thể biết được và sơ luợc những nhóm yêu cầu nào cần phải được làm rõ.
Sau đó, 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. Việc này không những giúp tinh chỉnh yêu cầu, mà đồng thời giúp cho đội ngũ phát triển thông hiểu hơn những gì cần được phát triển. 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.

d/lặp và tăng dần

        Hai mô hình lặp và tăng dần đều có điểm giống nhau là đều dựa trên tinh thần của mô hình tiến hóa, và có thêm đặc điểm nhắm đến việc cung cấp một phần hệ thống để khách hàng có thể đưa vào sử dụng trong môi trường hoạt động sản xuất thực sự mà không cần chờ cho đến khi toàn bộ hệ thống được hoàn thành (trong mô hình mẫu hay tiến hóa, các phiên bản mẫu hay trung gian đều không nhắm đến đưa vào vận hành thực sự cho khách hàng, trừ phiên bản cuối cùng). Để khách hàng có thể sử dụng, mỗi phiên bản đều phải được thực hiện như một qui trình đầy đủ các công việc từ phân tích yêu cầu với khả năng bổ sung hay thay đổi, thiết kế, hiện thực cho đến kiểm nghiệm và có thể xem như một qui trình (chu trình) con. Các chu trình con có thể sử dụng các mô hình khác nhau (thông thường là waterfall).

Mục tiêu của phiên bản đầu tiên là phát triển phần lõi và nhóm các chức năng quan trọng. Sau mỗi phiên bản được đưa vào sử dụng, các kết quả đánh giá sẽ được phản hồi và lập kế hoạch cho chu trình con của phiên bản tiếp theo để thực hiện:
• Những thay đổi cho phiên bản trước đó nhằm đáp ứng nhu cầu khách hàng tốt hơn
• Có thể thêm những chức năng hoặc đặc điểm bổ sung
• Sự khác nhau giữa hai mô hình tăng dần và lặp có thể được hiểu đơn giản:
• Mô hình tăng dần (Incremental): thêm chức năng vào sản phẩm
• Mô hình lặp (Iterative): thay đổi sản phẩm

e/mô hình xoắn ốc

-mô hình này đặ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.
Trong mô hình này, việc phân tích và giải quyết những vấn đề có rủi ro cao tập trung vào thiết kế từng khía cạnh cụ thể chứ không dựa vào việc xử lý các vấn đề một cách chung chung.
-chu kỳ xoay vòng, trong đó mỗi chu kỳ bao gồm 4 giai đoạn con như sau:
1. Xác định mục tiêu chất lượng cho sản phẩm được thực hiện, đồng thời xác định sự lựa chọn mua, tái sử dụng hay tự thiết kế và hiện thực các thành phần của hệ thống.
2. Phân tích sự lựa chọn và các rủi ro có thể xảy ra. Việc này được thực hiện bởi nhiều hoạt động khác nhau thông qua làm mẫu hay mô phỏng.
3. Phát triển và kiểm định sản phẩm ở mức tiếp theo dựa trên kết quả định hướng được chỉ ra trong giai đoạn con số 2 (phân tích rủi ro)
4. Kiểm duyệt tất cả các kết quả của các giai đoạn con xảy ra trước đó và lập kế hoạch cho chu kỳ lặp tiếp theo.

6/so sánh các mô hình:

a/Mô hình Waterfall
Ưu điểm:
Các giai đoạn được định nghĩa, với đầu vào và đầu ra rõ ràng. Mô hình này cơ bản dựa trên tài liệu nhất là trong các giai đoạn đầu, đầu vào và đầu ra đều là tài liệu.
Sản phẩm phần mềm được hình thành thông qua chuỗi các hoạt động xây dựng phần mềm theo trình tự rõ ràng.
Nhược điểm:
Đòi hỏi tất cả yêu cầu phần mềm phải được xác định rõ ràng ngay từ đầu dự án. Nhưng đa số dự án thực tế cho thấy yêu cầu phần mềm thường ẩn chứa không nhiều thì ít những điểm không chắc chắn.
Một thực tế là các dự án hiếm khi được thực hiện đầy đủ các bước trong suốt chu kỳ dự án. Đặc biệt là giai đoạn kiểm thử khi gần đến ngày giao hàng chẳng hạn, nếu có trục trặc xảy ra do yêu cầu phần mềm không rõ ràng hay thiết kế có lỗi, xu hướng là mã nguồn được sửa đổi trực tiếp mà không qua các bước bổ sung theo đúng mô hình, nên dẫn đến bản đặc tả phần mềm cũng như một số sản phẩm trung gian khác như bản thiết kế, cho dù có được cập nhật sau này cũng có thể không phản ánh đầy đủ những gì đã được sửa đổi trong mã nguồn.
Người sử dụng không có cơ hội tham gia trong suốt thời gian của các giai đoạn trung gian từ thiết kế cho đến kiểm thử. Đặc biệt với những dự án lớn, người sử dụng chỉ có thể nhận ra rằng hệ thống phần mềm không phù hợp cho nhu cầu của họ vào thời điểm cuối dự án.
Nói chung, mô hình này thường ẩn chứa nhiều rủi ro mà chỉ có thể phát hiện ở giai đoạn cuối cùng  và chi phí để sửa chữa có thể rất cao.
Ứng dụng:
Yêu cầu được định nghĩa rất rõ ràng, chi tiết và hầu như không thay đổi, thường xuất phát từ sản phẩm đã đạt mức ổn định.
Yêu cầu mới bổ sung (nếu có) cũng sớm được xác định rõ ràng, đầy đủ từ đầu dự án.
Đội ngũ thực hiện quen thuộc và hiểu rõ tất cả yêu cầu của dự án, và có nhiều kinh nghiệm với các công nghệ được dùng để phát triển sản phẩm.
Dự án được xác định hầu như không có rủi ro.
b/Mô hình tiến hóa
Ưu điểm:
Chú trọng việc tái sử dụng mẫu. Một phần của hệ thống có thể được phát triển ngay trong các giai đoạn phân tích phát triển yêu cầu và thiết kế.Cho phép thay đổi yêu cầu và khuyến khích người sử dụng tham gia trong suốt chu kỳ của dự án.

Nhược điểm:
Làm chậm quá trình phát triển yêu cầu và có thể ảnh hưởng sự chú ý đến các công việc trung gian như kiểm tra mã nguồn, thực hiện kiểm thử cấp thấp...
Dễ dẫn đến kết cấu của hệ thống kém.
Thường thì với mô hình này, tính chặt chẽ, minh bạch của qui trình kém.
Ứng dụng:
Hệ thống tương tác nhỏ và vừa; phần GUI của những hệ thống lớn; những hệ thống cần chu kỳ phát triển ngắn.
Đội ngũ phát triển không quen thuộc với lĩnh vực của dự án.

c/Mô hình lặp và tăng dần
Ưu điểm:
Giảm rủi ro sớm trong chu kỳ phát triển phần mềm. Những yêu cầu quan trọng thường được phát triển và chuyển đến người sử dụng sớm.
Phản hồi của nguời sử dụng về những vấn đề phát sinh trong phiên bản trước được dùng để cải tiến và ngăn ngừa những vấn đề tương tự xảy ra trong những phiên bản tiếp theo.
Nhược điểm:
Tổng chi phí lập kế hoạch phát triển cho toàn hệ thống có thể cao hơn. Lưu ý, ở đây chỉ đề cập chi phí lập kế hoạch ban đầu, không bao gồm tất cả chi phí phát sinh. Trong thực tế, nếu ứng dụng hợp lý, toàn bộ chi phí và thời gian cho đến khi sản phẩm được nghiệm thu có thể thấp hơn so với mô hình khác.
Các yêu cầu về kế hoạch và hoạt động trong qui trình cụ thể sẽ phức tạp hơn.
-Mô hình lặp:
Đội ngũ phát triển quen thuộc với lĩnh vực dự án nhưng không có nhiều kinh nghiệm, nhất là về công nghệ được dùng phát triển dự án.
Có nhiều rủi ro về mặt kỹ thuật
-Mô hình tăng dần:
Rủi ro được phân tích và xác định ngay từ đầu.
Giao tiếp giữa các module cũng được xác định rõ ràng từ đầu.
Đội ngũ phát triển quen thuộc với lĩnh vực của dự án và có nhiều kinh nghiệm.
Hệ thống lớn được phát triển trong thời gian dài, khách hàng cần triển khai sớm một số phần của hệ thống.
d/Mô hình xoắn
Ưu điểm:
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 “spiral” để 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à 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 “spiral”.
Đâ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.

Nhược điểm:
Phức tạp và không phù hợp cho dự án nhỏ với ít rủi ro.
Cần có kỹ năng tốt về phân tích rủi ro.
Ứng dụng:
Dự án lớn có nhiều rủi ro hay sự thành công của dự án không có được sự đảm bảo nhất định; những dự án đòi hỏi nhiều tính toán, xử lý như hệ thống hỗ trợ
quyết định.
Đội ngũ thực hiện dự án có khả năng phân tích rủi ro.
Trên đây là một số so sánh giữa các mô hình, thực sự việc lựa chọn cụ thể mô hình nào không phải dễ dàng và trên thực tế người ta thường dùng mô hình lai, kết hợp một số mô hình với nhau sao cho phù hợp với dự án.
Việc cải tiến các mô hình phát triển phần mềm luôn là đề tài nghiên cứu hấp dẫn, với sự tham gia tích cực không những từ các nhà sản xuất phần mềm mà còn từ các viện đại học khắp thế giới. Riêng với các nhà phát triển phần mềm, họ luôn cố gắng cải tiến liên tục qui trình phát triển của mình nhằm không ngừng đổi mới, nâng cao năng suất và chất lượng sản phẩm. Tuy nhiên, một điều dễ thấy là việc lựa chọn, tùy biến mô hình phù hợp cho các dự án đã khó, nhưng việc vận hành nó vào trong quá trình phát triển sản phẩm càng khó hơn.

7/ Phân loại phần mền

a.Theo phương thức hoạt động

1.          Phần mềm hệ thống dùng để vận hành máy tính và các phần cứng máy tính, ví dụ như các hệ điều hành máy tính Windows XP, Linux, Unix, các thư viện động của hệ điều hành, các trình điều khiển (driver), phần sụn (firmware) và BIOS. Đây là các loại phần mềm mà hệ điều hành liên lạc với chúng để điều khiển và quản lý các thiết bị phần cứng.

2.          Phần mềm ứng dụng để người sử dụng có thể hoàn thành một hay nhiều công việc nào đó, ví dụ như các phần mềm văn phòng (Microsoft Office,FoxPro), phần mềm doanh nghiệp, phần mềm quản lý nguồn nhân lực , phần mềm giáo dục, cơ sở dữ liệu, phần mềm trò chơi, chương trình tiện ích, hay các phần mềm ác tính.

3.          Các phần mềm chuyển dịch mã bao gồm trình biên dịch và trình thông dịch: các loại chương trình này sẽ đọc các câu lệnh từ mã nguồn được viết bởi các lập trình viên theo một ngôn ngữ lập trình và dịch nó sang dạng ngôn ngữ máy mà máy tính có thể hiểu đưọc, hay dịch nó sang một dạng khác như là tập tin đối tượng (object file) và các tập tin thư viện (library file) mà các phần mềm khác (như hệ điều hành chẳng hạn) có thể hiểu để vận hành máy tính thực thi các lệnh.

b.Theo khả năng ứng dụng

1.          Những phần mềm không phụ thuộc, nó có thể được bán cho bất kỳ khách hàng nào trên thị trường tự do. Ví dụ: phần mềm về cơ sở dữ liệu như Oracle, đồ họa như Photoshop, Corel Draw, soạn thảo và xử lý văn bản, bảng tính,... Ưu điểm: Thông thường đây là những phần mềm có khả năng ứng dụng rộng rãi cho nhiều nhóm người sử dụng. Khuyết điểm: Thiếu tính uyển chuyển, tùy biến.

2.          Những phần mềm được viết theo đơn đặt hàng hay hợp đồng của một khách hàng cụ thể nào đó (một công ty, bệnh viện, trường học,...). Ví dụ: phần mềm điều khiển, phần mềm hỗ trợ bán hàng,... Ưu điểm: Có tính uyển chuyển, tùy biến cao để đáp ứng được nhu cầu của một nhóm người sử dụng nào đó. Khuyết điểm: Thông thường đây là những phần mềm ứng dụng chuyên ngành hẹp.

8/ Các phương pháp tìm hiểu và thu thập yêu cầu

-phương pháp phỏng vấn( pv có cấu trúc & pv phi cấu trúc)

-phương pháp dùng phiếu hỏi

-phương pháp lấy mẫu

-phương pháp xem xét tài liệu

-phương pháp quan sát

-phương pháp họp nhóm

-phương pháp xem xét các phần mềm có cùng tính năng

9/ Các mô hình kiến trúc phần mềm

a-Kho dùng chung

Nếu số lượng dữ liệu dùng chung rất lớn thì mô hình kho dữ liệu dùng chung thường được sử dụng phổ biến nhất. Ưu điểm của mô hình này là:

- Đây là phương pháp hiệu quả để chia sẻ số lượng lớn dữ liệu.

- Các hệ thống con không cần quan tâm tới những hoạt động liên quan đến dữ liệu như: sao lưu, bảo mật,… vì đã có bộ quản lý trung tâm thực hiện nhiệm vụ này.

Tuy nhiên, việc sử dụng kho dữ liệu dùng chung cũng có một số nhược điểm sau:

- Tất cả các hệ thống con phải chấp nhận mô hình kho dữ liệu.

- Việc cải tiến dữ liệu rất phức tạp và tốn kém

- Khó phân tán một cách hiệu quả

- Không có giới hạn cho các chính sách quản lý cụ thể.

b- Mô hình client-sever

Mô hình kiến trúc client-server là một mô hình hệ thống trong đó hệ thống bao gồm một tập hợp các server cung cấp dịch vụ và các client truy nhập và sử dụng các dịch vụ đó. Các thành phần chính của mô hình này bao gồm:

- Tập hợp các server sẽ cung cấp những dịch vụ cụ thể như: in ấn, quản lý dữ liệu…

- Tập hợp các client truy nhập đến server để yêu cầu cung cấp dịch vụ.

- Hệ thống mạng cho phép client truy cập tới dịch vụ mà server cung cấp.

Client phải biết tên của server và các dịch vụ mà server cung cấp. Nhưng server thì không cần xác định rõ client và hiện tại có bao nhiêu client. Client tạo ra một yêu cầu tới server và chờ server trả lời.

*Ưu điểm của mô hình client - server là:

- Phân tán dữ liệu rõ ràng

- Sử dụng các hệ thống được kết nối mạng một cách hiệu quả và chi phí dành cho phần cứng có thể rẻ hơn.

- Dễ dàng bổ sung hoặc nâng cấp server

*Nhược điểm của mô hình client - server là:

- Không phải là mô hình dữ liệu dùng chung nên các hệ thống con có thể sử dụng các tổ chức dữ liệu khác nhau. Do đó, việc trao đổi dữ liệu có thể không hiệu quả.

- Quản lý mỗi server không thống nhất, dư thừa.

- Không đăng ký tên và dịch vụ tập trung. Điều này làm cho việc tìm kiếm server hoặc các dịch vụ rất khó khăn.

c- Mô hình phân lớp

Mô hình phân lớp tổ chức hệ thống thành nhiều lớp và mỗi lớp cung cấp một tập các dịch vụ. Mỗi lớp có thể được coi như một máy trừu tượng (abstract machine) mà ngôn ngữ của máy được định nghĩa bởi các dịch vụ mà lớp đó cung cấp. Do đó, mô hình này thường được sử dụng để mô hình hoá giao diện (interface) của hệ thống con.Mô hình phân lớp hỗ trợ phát triển các hệ thống con theo kiểu tăng vòng ở nhiều lớp khác nhau. Khi giao diện của một lớp thay đổi thì chỉ những lớp liền kề nó mới bị ảnh hưởng.

10/Quy trình thiết kế giao diên người dùng

a-Phân tích người sử dụng

Phân tích người sử dụng phải được mô tả theo những thuật ngữ để người sử dụng và những người thiết kế khác có thể hiểu được.

Các ngữ cảnh mà ta mô tả thao tác ở trong đó là một trong những cách mô tả phân tích người dùng. Ta có thể lấy được rất nhiều yêu cầu của người sử dụng từ đó.

Các kỹ thuật phân tích:

- Phân tích nhiệm vụ: mô hình hoá các bước cần thực hiện để hoàn thành một nhiệm vụ.

- Phân tích nhiệm vụ phân cấp.

- Phỏng vấn và trắc nghiệm: hỏi người sử dụng về những gì mà họ làm. Khi phỏng vấn, chúng ta nên dựa trên những câu hỏi có kết thúc mở. Sau đó, người sử dụng cung cấp những thông tin mà họ nghĩ rằng nó là cần thiết; nhưng không phải tất cả các thông tin đó là có thể được sử dụng. Ngoài ra, chúng ta có thể thực hiện phỏng vấn với cả nhóm người sử dụng, điều đó cho phép người sử dụng thảo luận với nhau về những gì họ làm.

- Mô tả: quan sát người sử dụng làm việc và hỏi họ về những cách mà không được biết tới. Nên nhớ rằng có nhiều nhiệm vụ của người sử dụng thuộc về trực giác và rất khó để mô tả và giải thích chúng. Dựa trên kỹ thuật này ta có thể hiểu thêm về các ảnh hưởng xã hội và tổ chức tác động tới công việc đó.

b-lập mẫu thử giao diên người dùng

Mẫu thử cho phép người sử dụng có được những kinh nghiệm trực tiếp với giao diện. Nếu không có những kinh nghiệm trực tiếp như vậy thì không thể đánh giá được khả năng có thể sử dụng được của giao diện.

Lập mẫu thử là một quy trình gồm 2 trạng thái:

- Lập các mẫu thử trên giấy.

- Tinh chỉnh mẫu thử và xây dựng chúng

Các kỹ thuật lập mẫu thử:

- Mẫu thử hướng nguyên mẫu: sử dụng công cụ như Macromedia Director để xây dựng một tập hợp các nguyên mẫu và màn hình. Khi người sử dụng tương tác với chúng thì màn hình sẽ thay đổi để hiển thị trạng thái kế tiếp.

- Lập trình trực quan: sử dụng các ngôn ngữ được thiết kế cho việc phát triển nhanh như Visual Basic.

- Mẫu thử dựa Internet: sử dụng web browser và script.

c- đánh giá giao diên người sử dụng

Ta nên đánh giá bản thiết kế giao diện người dùng để xác định khả năng phù hợp của nó. Tuy nhiên, việc đánh giá trên phạm vi rộng tốn nhiều chi phí và không thể thực hiện được đối với hầu hết các hệ thống.

*Các kỹ thuật đánh giá đơn giản:

- Trắc nghiệm lại các phản hồi của người sử dụng

- Ghi lại quá trình sử dụng mẫu thử của hệ thống và đánh giá nó.

- Lựa chọn những thông tin về việc sử dụng dễ dàng và các lỗi của người sử dụng.

- Cung cấp mã lệnh trong phần mềm để thu thập những phản hồi của người sử dụng một cách trực tuyến.

11/ Kiểm thư phần mềm

Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau.

1-Các chiến lược kiểm thử

A-kiểm thử đơn vị

Một đơn vị là một thành phần phần mềm nhỏ nhất mà ta có thể kiểm thử được. Ví dụ, các hàm (Function), thủ tục (Procedure), lớp (Class) hay phương thức (Method) đều có thể được xem là Unit.

Vì Unit được chọn để kiểm tra thường có kích thước nhỏ và chức năng hoạt động đơn giản, chúng ta không khó khăn gì trong việc tổ chức kiểm thử, ghi nhận và phân tích kết quả kiểm thử. Nếu phát hiện lỗi, việc xác định nguyên nhân và khắc phục cũng tương đối dễ dàng vì chỉ khoanh vùng trong một đơn thể Unit đang kiểm tra. Một nguyên lý đúc kết từ thực tiễn: thời gian tốn cho Unit Test sẽ được đền bù bằng việc tiết kiệm rất nhiều thời gian và chi phí cho việc kiểm thử và sửa lỗi ở các mức kiểm thử sau đó.

Unit Test thường do lập trình viên thực hiện. Công đoạn này cần được thực hiện càng sớm càng tốt trong giai đoạn viết code và xuyên suốt chu kỳ phát triển phần mềm. Thông thường, Unit Test đòi hỏi kiểm thử viên có kiến thức về thiết kế và code của chương trình. Mục đích của Unit Test là bảo đảm thông tin được xử lý và xuất (khỏi Unit) là chính xác, trong mối tương quan với dữ liệu nhập và chức năng của Unit. Điều này thường đòi hỏi tất cả các nhánh bên trong Unit đều phải được kiểm tra để phát hiện nhánh phát sinh lỗi. Một nhánh thường là một chuỗi các lệnh được thực thi trong một Unit

B-kiểm thử tích hợp- Intergration Test

Integration test kết hợp các thành phần của một ứng dụng và kiểm thử như một ứng dụng đã hoàn thành. Trong khi Unit Test kiểm tra các thành phần và Unit riêng lẻ thì Intgration Test kết hợp chúng lại với nhau và kiểm tra sự giao tiếp giữa chúng.

Hai mục tiêu chính của Integration Test:

·        Phát hiện lỗi giao tiếp xảy ra giữa các Unit.

·        Tích hợp các Unit đơn lẻ thành các hệ thống nhỏ (Subsystem) và cuối cùng là nguyên hệ thống hoàn chỉnh (System) chuẩn bị cho kiểm thử ở mức hệ thống (System Test).

Có 4 loại kiểm thử trong Integration Test:

-          Kiểm thử cấu trúc (Structure Test)

-          Kiểm thử chức năng (Functional Test)

-          Kiểm thử hiệu năng (Performance Test)

-          Kiểm thử khả năng chịu tải (Stress Test)

C-kiểm thử hệ thống- system test

-Mục đích System Test là kiểm thử thiết kế và toàn bộ hệ thống (sau khi tích hợp) có thỏa mãn yêu cầu đặt ra hay không.

-System Test bắt đầu khi tất cả các bộ phận của phần mềm đã được tích hợp thành công. Thông thường loại kiểm thử này tốn rất nhiều công sức và thời gian. Trong nhiều trường hợp, việc kiểm thử đòi hỏi một số thiết bị phụ trợ, phần mềm hoặc phần cứng đặc thù, đặc biệt là các ứng dụng thời gian thực, hệ thống phân bố, hoặc hệ thống nhúng. Ở mức độ hệ thống, người kiểm thử cũng tìm kiếm các lỗi, nhưng trọng tâm là đánh giá về hoạt động, thao tác, sự tin cậy và các yêu cầu khác liên quan đến chất lượng của toàn hệ thống.

-System Test kiểm thử cả các hành vi chức năng của phần mềm lẫn các yêu cầu về chất lượng như độ tin cậy, tính tiện lợi khi sử dụng, hiệu năng và bảo mật. Mức kiểm thử này đặc biệt thích hợp cho việc phát hiện lỗi giao tiếp với phần mềm hoặc phần cứng bên ngoài, chẳng hạn các lỗi "tắc nghẽn" (deadlock) hoặc chiếm dụng bộ nhớ. Sau giai đoạn System Test, phần mềm thường đã sẵn sàng cho khách hàng hoặc người dùng cuối cùng kiểm thử chấp nhận sản phẩm (Acceptance Test)

D-Kiểm thử chấp nhận- Acceptance Test

-Acceptance Test, được khách hàng thực hiện (hoặc ủy quyền cho một nhóm thứ ba thực hiện). Mục đích của Acceptance Test là để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm (và trả tiền thanh toán hợp đồng).

-Acceptance Test có ý nghĩa hết sức quan trọng, mặc dù trong hầu hết mọi trường hợp, các phép kiểm thử của System Test và Acceptance Test gần như tương tự, nhưng bản chất và cách thức thực hiện lại rất khác biệt.

-Đối với những sản phẩm dành bán rộng rãi trên thị trường cho nhiều người sử dụng, thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha – Alpha Test và kiểm thử Beta – Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa.

=>Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng.

E-kiểm thử hồi quy- Regression Testing

kiểm thử hồi quy là “sự kiểm tra lại có lựa chọn của một hệ thống hay thành phần để xác minh là những sự thay đổi không gây ra những hậu quả không mong muốn…”.

-Trên thực tế, quan niệm này là chỉ ra rằng phần mềm mà đã qua được các kiểm tra trước đó vẫn có thể được kiểm tra lại, đó là sự lặp lại các kiểm tra để chỉ ra rằng cách hoạt động của phần mềm không bị thay đổi, ngoại trừ tới mức như yêu cầu. Hiển nhiên là sự thỏa hiệp phải được thực hiện giữa sự đảm bảo được đưa ra bởi kiểm thử hồi quy mỗi lần thực hiện một sự thay đổi và những tài nguyên được yêu cầu thực hiện điều đó.

12/kiểm thử hộp đen , trắng , xám

A-Kiểm thử hộp đen – Black box testing

-Kiểm thử hộp đen xem chương trình như là một “hộp đen”. Mục đích của bạn là hoàn toàn không quan tâm về cách cư xử và cấu trúc bên trong của chương trình. Thay vào đó, tập trung vào tìm các trường hợp mà chương trình không thực hiện theo các đặc tả của nó

-Kiểm thử dựa trên đặc tả tập trung vào kiểm tra tính thiết thực của phần mềm theo những yêu cầu thích hợp. Do đó, kiểm thử viên nhập dữ liệu vào, và chỉ thấy dữ liệu ra từ đối tượng kiểm thử. Mức kiểm thử này thường yêu cầu các ca kiểm thử triệt để được cung cấp cho kiểm thử viên mà khi đó có thể xác minh là đối với dữ liệu đầu vào đã cho, giá trị đầu ra (hay cách thức hoạt động) có giống với giá trị mong muốn đã được xác định trong ca kiểm thử đó hay không. Kiểm thử dựa trên đặc tả là cần thiết, nhưng không đủ để để ngăn chặn những rủi ro chắc chắn.

Ưu, nhược điểm

Kiểm thử hộp đen không có mối liên quan nào tới mã lệnh, và kiểm thử viên chỉ rất đơn giản tâm niệm là: một mã lệnh phải có lỗi. Sử dụng nguyên tắc “ Hãy đòi hỏi và bạn sẽ được nhận”, những kiểm thử viên hộp đen tìm ra lỗi mà những lập trình viên đã không tìm ra. Nhưng, mặt khác, người ta cũng nói kiểm thử hộp đen “giống như là đi trong bóng tối mà không có đèn vậy”, bởi vì kiểm thử viên không biết các phần mềm được kiểm tra thực sự được xây dựng như thế nào. Đó là lý do mà có nhiều trường hợp mà một kiểm thử viên hộp đen viết rất nhiều ca kiểm thử để kiểm tra một thứ gì đó mà đáng lẽ có thể chỉ cần kiểm tra bằng 1 ca kiểm thử duy nhất, và/hoặc một số phần của chương trình không được kiểm tra chút nào.

Do vậy, kiểm thử hộp đen có ưu điểm của “một sự đánh giá khách quan”, mặt khác nó lại có nhược điểm của “thăm dò mù”.

B- Kiểm thử hộp trắng – White box testing

-Là một chiến lược kiểm thử khác, trái ngược hoàn toàn với kiểm thử hộp đen, kiểm thử hộp trắng hay kiểm thử hướng logic cho phép bạn khảo sát cấu trúc bên trong của chương trình. Chiến lược này xuất phát từ dữ liệu kiểm thử bằng sự kiểm thử tính logic của chương trình. Kiểm thử viên sẽ truy cập vào cấu trúc dữ liệu và giải thuật bên trong chương trình (và cả mã lệnh thực hiện chúng).

-Phương pháp kiểm thử hộp trắng cũng có thể được sử dụng để đánh giá sự hoàn thành của một bộ kiểm thử mà được tạo cùng với các phương pháp kiểm thử hộp đen. Điều này cho phép các nhóm phần mềm khảo sát các phần của 1 hệ thống ít khi được kiểm tra và đảm bảo rằng những điểm chức năng quan trọng nhất đã được kiểm tra.

C- Kiểm thử hộp xám – Gray box testing

-Kiểm thử hộp xám đòi hỏi phải có sự truy cập tới cấu trúc dữ liệu và giải thuật bên trong cho những mục đích thiết kế các ca kiểm thử, nhưng là kiểm thử ở mức người sử dụng hay mức hộp đen. Việc thao tác tới dữ liệu đầu vào và định dạng dữ liệu đầu ra là không rõ ràng, giống như một chiếc “hộp xám”, bởi vì đầu vào và đầu ra rõ ràng là ở bên ngoài “hộp đen” mà chúng ta vẫn gọi về hệ thống được kiểm tra. Sự khác biệt này đặc biệt quan trọng khi quản lý kiểm thử tích hợp – Intergartion testing giữa 2 modun mã lệnh được viết bởi hai chuyên viên thiết kế khác nhau, trong đó chỉ giao diện là được đưa ra để kiểm thử. Kiểm thử hộp xám có thể cũng bao gồm cả thiết kế đối chiếu để quyết định, ví dụ, giá trị biên hay thông báo lỗi.