1 Phát triển hệ thống 1 1 Giới thiệu 2


Phương pháp luận phát triển



tải về 1.95 Mb.
trang2/20
Chuyển đổi dữ liệu30.08.2016
Kích1.95 Mb.
#28837
1   2   3   4   5   6   7   8   9   ...   20

1.2Phương pháp luận phát triển


  • Mục này giới thiệu về mối quan hệ giữa các hệ thống doanh nghiệp nghiệp, công nghệ thông tin và các phương pháp phát triển chính.


1.2.1Vai trò của tổ chức phát triển hệ thống


(1) Hoạt động xí nghiệp và hệ thông tin

  • Cần nhiều nỗ lực để tạo ra sự phát triển liên tục của xí nghiệp. Trong đó việc sử dụng Công nghệ Thông tin (CNTT) là điều chủ chốt.

  • Với các xí nghiệp, có hai kiểu thông tin:

  • Thông tin nội bộ :Thông tin được phát sinh qua các hoạt động nghiệp vụ, và bao gồm cả các hoá đơn, biểu mẫu và tài liệu quản lí được dùng trong bán hàng, ra lệnh sản xuất và kế toán.

  • Thông tin ngoài :Thông tin được phát sinh ra tuỳ thuộc vào tình trạng kinh tế bao quanh công ti, kể cả việc bán sản phẩm, xu hướng các ngành công nghiệp có liên quan, động thái của các công ti cạnh tranh, và các giao tác với các công ti có liên quan.

  • Doanh nghiệp dùng các thông tin trên trong hoạt động hàng ngày của mình một cách hiệu quả. Hệ thông tin được phân thành hai loại:



  • Hệ xử lí tác nghiệp : Được dùng để hỗ trợ cho các hoạt động hàng ngày và cung cấp dữ liệu quản lí doanh nghiệp. Việc xử lí thông tin đều kì được tiến hành để làm tăng hiệu suất và cải tiến hiệu quả vận hành.

  • Hệ thông tin chiến lược : Để đạt tới các hoạt động nghiệp vụ đa dạng, điều quan trọng là dùng tài nguyên sẵn có, con người, vật tư và tiền bạc theo cách hiệu quả nhất. Hệ thống cung cấp thông tin cần cho việc quản lí các tài nguyên này. Hệ thống này chủ yếu được dùng để sinh ra các báo cáo theo quan điểm quản lí.



Hình 1-1-1 Hệ thông tin chiến lược và hệ xử lí tác nghiệp



























  • Mục đích của từng hệ là như sau.



- Làm giảm nhân công cho những thao tác có liên quan

- Làm giảm việc xử lí nghiệp vụ

- Làm giảm thời gian giao hàng

- Làm giảm việc quản lí kho

- Thực hiện các thao tác không giấy tờ




- Làm tăng bán hàng

- Cải thiện hiệu quả bán hàng

- Cải thiện sự thoả mãn của khách hàng

- Tạo ra thị trường mới



  • Nói chung, một tổ chức chịu trách nhiệm phát triển các hệ thống xử lí thông tin được gọi là tổ chức phát triển hệ thống hay cái gì đó tương tự, và các kĩ sư hệ thống (SE) là các lập trình viên thuộc tổ chức này.

  • Mặt khác, một tổ chức dùng các hệ thống đã phát triển được gọi là tổ chức người dùng.



(2) Tiến bộ trong CNTT và tổ chức phát triển hệ thống

  •  Tiến bộ trong công nghệ thông tin

  • Những tiến bộ mới đây trong công nghệ là rất đáng ngạc nhiên. Trong số nhiều tiến bộ đa dạng, những điều sau đây được xem như các nhân tố ảnh hưởng rất đáng kể tới việc phát triển hệ thống.

  • a. Tiến bộ trong công nghệ máy tính

  • Việc cải tiến hiệu năng của cả máy tính cá nhân và trạm làm việc, và việc giảm giá đáng kể của chúng là điều rất đáng ngạc nhiên. Những thao tác mà có thời đã phải được thực hiện chỉ với máy tính lớn thì bây giờ có thể được thực hiện bằng những máy tính nhỏ hơn.

  • b. Sử dụng rộng rãi các gói phần mềm

  • Bởi vì sự phát triển nhanh chóng của các gói phần mềm, nên những gói phần mềm cho quản trị cơ sở dữ liệu RDBMS (Relational Data Base Management System) và bảng tính nay đã sẵn có, và nó cũng có thể được tích hợp vào một số hệ thống.

  • c. Tiến bộ trong công nghệ mạng

  • Đổi mới công nghệ trong lĩnh vực thông tin và truyền thông, kể cả việc tổ hợp của mạng cục bộ LAN (Local Area Network) và WAN (Wide Area Network) và việc xây dựng các mạng nội bộ intranets và mạng ngoại bộ extranets (mạng được tạo ra bằng việc mở rộng mạng nội bộ ra bên ngoài công ti), là rất đáng chú ý.

  • d. Tiến bộ trong công nghệ xây dựng hệ thống

  • Công nghệ đã dịch chuyển từ cách tiếp cận hướng xử lí sang cách tiếp cận hướng dữ liệu (DOA). Kết quả là các kí pháp như Biểu đồ luồng dữ liệu - Data Flow Diagram (DFD), Biểu đồ thực thể quan hệ - Entity-Relationship Diagram (ERD), và Cấp bậc cộng với Vào Xử lí Ra - Hierarchy plus Input Process Output (HIPO) được tạo ra để biểu diễn cho các thiết kế có cấu trúc, đã được chấp nhận rộng rãi. Thêm vào đó, các công cụ CASE (Computer Aided Software Engineering) đã trở nên sẵn có để hỗ trợ cho những nỗ lực phát triển, và đã trở nên được dùng rộng rãi.

  •  Hiện trạng của các tổ chức phát triển hệ thống

  • Với việc tăng qui mô hệ thống và việc đưa vào multimedia, các tổ chức phát triển hệ thống đang phải đương đầu với những vấn đề sau:

  • a. Tăng khối lượng công việc tồn đọng lại

  • Số lượng việc tồn đọng lại, điều chỉ ra hệ thống không thể được bắt đầu ngay lập tức theo yêu cầu phát triển từ tổ chức người dùng, đã tăng lên. Mọi công ti trung bình đều tồn đọng 2 đến 3 năm công việc.

  • b. Đưa vào hệ mutimedia và tăng số các hệ thống qui mô lớn

  • Các hệ thống multimedia, trong đó các dữ liệu đa dạng, kể cả tiếng nói, video và văn bản đều được dùng, đã đi vào thực tế. Thêm vào đó, WAN và LAN đã được tổ hợp và mạng nội bộ intranets đã được xây dựng. Do đó, ngày nay con người phải giải quyết các hệ thống qui mô ngày càng lớn và phức tạp.

  • c. Tăng công việc bảo trì

  • Với qui mô ngày càng mở rộng hệ thống, khối lượng công việc bảo trì cũng tăng lên. Khối lượng này tăng lên bởi vì các yêu cầu sửa đổi hệ thống từ các phòng ban người dùng tăng lên, sửa đổi các hệ thống hiện có trở thành cần thiết, và việc sửa đổi toàn bộ hệ thống do gặp nhiều lỗi cũng tăng lên.

  •  Vai trò mới của tổ chức phát triển hệ thống

  • Bên cạnh những công việc qui ước về việc phát triển hệ thống và bảo trì, các tổ chức phát triển hệ thống hiện nay được trông đợi thực hiện những công việc có liên quan như sau:

  • a. Phát triển hệ thống cùng sự vận hành và bảo trì chúng

  • Bên cạnh các công việc qui ước, các tổ chức phải chấp nhận công nghệ và phương pháp mới một cách tích cực.

  • b. Xây dựng và vận hành các cơ sở dữ liệu và mạng

  • Các cơ sở dữ liệu khác nhau là bản chất cho sự vận hành và quản lí nghiệp vụ. Bên cạnh đó, bây giờ không thể xem xét các hoạt động nghiệp vụ mà không dùng mạng. Việc xây dựng, vận hành và quản lí các cơ sở dữ liệu và mạng này được coi như công việc bản chất của tổ chức.

  • c. Lập kế hoạch và điều phối tin học hoá toàn công ti

  • Việc lập kế hoạch cho các hệ thống lớn bao quát toàn bộ công ti, và phản ánh cái nhìn của người dùng và ban điều hành công ti, cũng là việc quan trọng của tổ chức.

  • d. Gắn chặt với người dùng

  • Người ta trông đợi rằng tổ chức chấp nhận các yêu cầu của người dùng một cách tích cực và phát triển các hệ thống thực tế hơn. Tổ chức cũng cần sẵn sàng cung cấp sự hỗ trợ kĩ thuật cần thiết để hướng dẫn môi trường tính toán người dùng cuối (EUC), huấn luyện từ xa và huấn luyện tại chỗ về xử lí thông tin trong công ti.

1.2.2Mô hình phát triển phần mềm


  • Với việc phát triển hệ thống, người ta dùng nhiều mô hình khác nhau tuỳ theo qui mô của công ti và cách thức làm việc chủ đạo trong công ti. Tại đây, những phương pháp này được mô tả một cách vắn tắt. Đặc biệt, chúng tôi sẽ nêu chi tiết về mô hình thác đổ trong mục 1.1.3.

  • Như được vẽ trong Hình 1-1-2, việc xem xét cách xây nhà sẽ làm cho chúng ta dễ hiểu hơn về cách thức tiến triển việc xây dựng hệ thống.

  • Nếu chỉ riêng các biểu đồ lược đồ khách hàng khó có thể có được hình ảnh rõ ràng về ngôi nhà và ngôi nhà trông sẽ như thế nào khi được hoàn tất. Do đó, hãy kiểm tra với ngôi nhà mô hình, hay các ảnh 3 chiều trên máy tính mới được cung cấp gần đây.

  • Việc giải quyết tương tự cũng được dùng trong phát triển hệ thống.



Hình 1-1-2

Quy trình xây dựng nhà



  • Yêu cầu của khách về một ngôi nhà được đưa cho nhà xây dựng. Dựa trên các yêu cầu này, người xây dựng đưa ra giá thành ước lượng, các bản vẽ sơ đồ và lịch biểu, và nói điều đó với khách hàng. Thêm vào đó, người chủ nhà còn phải đi xin phép các cơ quan chính phủ có liên quan.

  • Dựa trên thiết kế sơ đồ, người xây dựng tạo ra các bản thiết kế chi tiết có tính tới những ràng buộc cần thiết như các điều kiện địa lí và xã hội của vị trí này và giá thành. Cuối cùng, việc thiết kế được chia xuống mức cho phép việc xây dựng thực.

  • Việc lắp ráp được thợ mộc thực hiện trên các thiết kế.

  • Việc kiểm tra được tiến hành mỗi khi hoàn tất một bộ phận. Đến cuối, việc kiểm tra được thực hiện với sự có mặt của khách hàng. Sau đó ngôi nhà được chuyển giao cho khách hàng.

  • Nhiều loại bảo trì sẽ được tiến hành tương ứng theo yêu cầu của khách..

(1) Mô hình thác đổ

  • Mô hình thác đổ, công nghệ phát triển hệ thống, vẫn là mô hình được sử dụng rộng rãi nhất. Trong mô hình này công việc được phân chia thành một số pha, và việc quản lí được tiến hành cho từng pha.



























  • Như được chỉ ra bởi cái tên "thác đổ", công việc tiến triển trong mô hình này từ luồng trên cao (lập kế hoạch cơ sở) tới luồng dưới thấp (kiểm thử), không bao giờ đi ngược lại.

(2) Mô hình bản mẫu

  • Mô hình thác đổ bao gồm những vấn đề sau.

  • - Với mô hình thác đổ cực kì khó hiểu thấu yêu cầu của người dùng trong pha lập kế hoạch cơ sở cho hệ thống. Đôi khi ngay cả khách hàng cũng không biết tới những yêu cầu đó.

  • - Các biểu đồ thiết kế và giải thích miệng đôi khi không đủ.

  • Để giải quyết những vấn đề này, mô hình bản mẫu đã được đề xuất ra. Với mô hình bản mẫu, hệ thống được xây dựng sẽ được làm mô hình thô trong các ngôn ngữ lập trình đơn giản như SQL (Structured Query Language) để giúp cho khách hàng hiểu. Sau đó, công việc phát triển dự định sẽ được bắt đầu.

  • Bản mẫu bao gồm nhiều mô hình đa dạng.




"Kiểu vứt đi": Các mảnh mẩu thử bị vứt đi sau khi đã đạt tới mục đích của chúng.

"Kiểu khung xương": Các chi tiết được thêm dần vào cho các mảnh mẫu thử để mở rộng dần nó thành hệ thống dự định.






"Kiểu dùng bộ phận": Mô hình này được dùng trong các pha xác định yêu cầu và thiết kế ngoài.

"Kiểu dùng toàn bộ": Mô hình này được xây dựng cho tất cả các pha.



  • Hình 1-1-4 chỉ ra một ví dụ lưu đồ của mô hình bản mẫu theo kiểu dùng bộ phận.





























  • Việc dùng mô hình bản mẫu đem tới cảm giác về sự tham gia của người dùng, ngăn ngừa các lỗi trong các pha thượng lưu vốn ảnh hưởng đáng kể tới công việc về sau.

  • Tuy nhiên, mô hình bản mẫu bao gồm các vấn đề sau cần được giải quyết.

  • - Chi phí phát triển vượt quá mô hình thác đổ.

- Khó điều chỉnh lịch.

(3) Mô hình xoắn ốc



  • Trong mô hình xoắn ốc, một loạt các tiến trình bao gồm thiết kế, lập trình và kiểm thử được lặp lại cho từng đơn vị con của hệ thống, với việc phát triển được lặp lại nhiều lần (xem Hình 1-1-5).



  • - Cách dùng mô hình này là thích hợp cho những trường hợp mà đơn vị con của hệ thống được phát triển là tương đối độc lập lẫn nhau.

- Nó tuân theo mô hình thác đổ theo bộ phận.

- Nó cho phép mô hình bản mẫu được sử dụng khi có nhu cầu nảy sinh.

- Được sử dụng trong việc phát triển kiểu hướng đối tượng và theo những cách khác.






















Hình 1-1-5 Mô hình xoắn ốc
(4) Phát triển hướng đối tượng

  • Gần đây sự chú ý đã dồn vào cách phát triển hướng đối tượng. Theo mô hình này, hệ thống được xét như một tập các đối tượng, và việc phát triển được tiến hành trên cơ sở đối tượng. Trong phát triển đối tượng, tiến trình phân tích tới thiết kế tới thực hiện được thực hiện lặp đi lặp lại thiết lập nên một loại mô hình xoắn ốc.

(5) Cấu trúc phân việc

  • Để đạt tới mục đích của mình, dự án phát triển hệ thống được phân ra thành các mức theo thứ tự sau, tuỳ theo tiến trình phát triển.

  • 1. Mức quyết định cấu trúc chính của dự án

  • 2. Mức công việc tạo nên khuôn khổ cho từng pha

  • 3
    0.0
    . Mức công việc hiện hành chi tiết


  • Dự án phát triển sản phẩm





  • 1.0

    2.0





  • 2.2

    2.1







  • 2.1.2

    2.1.1







  • Hình 1-1-6 Cấu trúc phân việc

    2.1.1.1

    2.1.1.2





  • Cấu trúc phân việc - Work Breakdown Structure (WBS) được suy ra bằng cách bổ sung thêm các mục đích cụ thể, lịch công việc, và việc quản lí tiến trình xác định các chi tiết ở mức mịn nhất có thể được cho điều thu được bởi những thao tác phân chia này. WBS được biểu diễn bằng cấu trúc phân cấp như được vẽ trong Hình1-1-6.

  • Việc dùng WBS đưa ra những ích lợi sau:

    Cung cấp các ước lượng chi phí và dữ liệu cho việc phân tích chi phí.

    Làm sáng tỏ cấu trúc công việc và bao quát công việc dự án cùng trách nhiệm về công việc.

    Việc hiểu thấu tiến trình thực tại cho từng đơn vị công việc, và lập kế hoạch công việc được dễ dàng hơn.



    Tên của các đơn vị công việc được phân ra và hệ thống phân lớp là một phần của tri thức chuyên gia về cách làm.

  • Với WBS, mục đích của công việc, như chất lượng, chi phí và thời gian được cho trên cơ sở đơn vị công việc. Cho nên, công việc được thực hiện với các mục tiêu như tham chiếu.



(6) Tiến trình và mô hình tiến trình

  • Tiến trình được định nghĩa như các đơn vị công việc nào, như phân tích, thiết kế và chế tạo, được cần tới trong việc tạo ra sản phẩm (kể cả sản phẩm phần mềm), và được bố trí theo chuỗi thời gian. Mỗi cấu phần của tiến trình được gọi là "giai đoạn tiến trình". Với WBS được mô tả ở trên, công việc được biểu diễn theo cấp bậc, nhưng không theo chuỗi thời gian. Điều này tạo ra sự khác biệt lớn.

  • Tiến trình được thiết kế đại thể trong pha lập kế hoạch cơ sở. Trong thiết kế này, mô hình tiến trình được nêu trong Hình 1-1-7 có thể được dùng như tham chiếu.



Lập kế hoạch

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

Thiết kế

Chế tạo, xây dựng và kiểm thử

Chuyển dịch

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



Thiết kế quan niệm

Thiết kế cơ sở

Thiết kế chi tiết

Mã hoá

Kiểm thử

Chuyển dịch

Bảo trì



Phân tích hệ thống

Kế hoạch hệ thống hoá

Thiết kế chương trình

Sinh chương trình

Kiểm thử

Chuyển dịch

Bảo trì



Lập kế hoạch

Thiết kế

Chế tạo

Kiểm thử hệ thống

Chuyển dịch sang vận hành thực tế

Bảo trì




Kế hoạch hệ thống hoá

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

Thiết kế ngoài

Thiết kế trong

Thực hiện phát triển

Kiểm thử hệ thống

Bảo trì

Thiết kế mô đun

Mã hoá

Kiểm thử đơn vị

Kiểm thử móc nối

Chuyển dịch




Lập kế hoạch hệ thống hoá

Phân tích hệ thống

Thiết kế hệ thống đại cương

Thiết kế hệ thống chi tiết

Chế tạo

Kiểm thử, chuyển dịch

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




Lập kế hoạch hệ thống

Phân tích hệ thống

Thiết kế giao diện người dùng

Thiết kế cấu trúc hệ thống

Thiết kế cấu trúc chương trình

Lập trình

Kiểm thử chương trình

Kiểm thử móc nối

Kiểm thử hệ thống

Kiểm thử vận hành

Bảo trì/ đánh giá hệ thống

Hình 1-1-7 Mô hình tiến trình

  • Các sản phẩm phần mềm được tạo ra qua từng tiến trình phát triển. Do đó, thiết kế của từng tiến trình, cho cơ sở của tiến trình, chủ yếu ảnh hưởng tới chất lượng và chi phí của sản phẩm phần mềm.

1.2.3Vòng đời phần mềm


  • Vòng đời là tiến trình từ khi sinh đến khi chết hay khoảng sống của vật sống và sản phẩm. Với khái niệm về vòng đời phần mềm (SLC) cũng vậy, đó là khoảng thời gian từ lúc bắt đầu dự án phát triển hệ thống, và thời gian khi việc cập nhật hệ thống kết thúc, được xem như cuộc sống của hệ thống. Vậy, các hoạt động xuất hiện trong thời kì đó được biểu diễn bằng cuộc sống thực được dùng, xem như mô hình diễn tả cho mối quan hệ giữa các tiến trình.

  • Hình 1-1-8 Vòng đời của hệ thống phần mềm











  • Trong phần sau đây sẽ giải thích về mô hình thác đổ, là mô hình điển hình nhất.

(1) Đặc trưng của mô hình thác đổ

















  • R: họp xét duyệt

  • Hình 1-1-9 Hình ảnh toàn thể của mô hình thác nước (cấu trúc hình chữ V)



  • Trong mô hình thác đổ, các kĩ thuật sau được sử dụng. Do đó, có thể trực quan hoá mô hình này như cấu trúc hình chữ V trong Hình 1-1-9.

  • Pha lập kế hoạch cơ sở tới pha lập trình: phương pháp làm mịn từng bước (tiếp cận trên xuống)

  • Pha kiểm thử đơn vị tới pha kiểm thử vận hành: phương pháp tích hợp từng bước (cách tiếp cận dưới lên)










  • Hình 1-1-10 Mối quan hệ giữa từng pha trong mô hình thác đổ và khối lượng công việc của nó







  • Kế hoạch hệ thống hoá

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

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


    Thiết kế trong

    Thiết kế chi tiết

    Lập trình

    Kiểm thử



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

    Lập kế hoạch cơ sở





  • Các đặc trưng của Mô hình thác đổ được tóm tắt sau đây:

  • Công việc phát triển hệ thống được chia thành một số pha cho việc quản lí.

  • Khi công việc của một pha hoàn tất thì sản phầm công việc (kể cả đủ loại tài liệu thiết kế) của pha này được xét duyệt để kiểm tra tính đúng đắn.

  • Các sản phẩm công việc (kể cả đủ loại tài liệu thiết kế) từ pha này được chuyển tiếp sang tiến trình tiếp. Theo cách này, sự nhất quán trong việc phát triển hệ thống được duy trì.

  • Về cơ bản, không được phép trở lại công việc của pha trước.

  • Cách tổ chức dự án có tầm quan trọng chủ chốt

  • Như đã mô tả ở trên, việc phân chia tiến trình phát triển hệ thống thành một số pha cho quản lí là một trong những đặc trưng của mô hình thác nước. Hình 1-1-10 chỉ ra mối quan hệ giữa từng pha và khối lượng công việc ở đó.

  • Trong các mục (2) tới (8) dưới đây, sẽ mô tả đại cương từng pha công việc trong phát triển hệ thống.



(2) Lập kế hoạch cơ sở

  • Lập kế hoạch cơ sở là bước đầu tiên của việc phát triển hệ thống. Cần phải có tri thức thấu đáo về hoạt động hiện tại nhằm đạt mục đích tin học hoá. Bằng không, không thể nào phát triển được hệ thống có thể thoả mãn cho người dùng. Do vậy, việc lập kế hoạch cơ sở bắt đầu bằng phân tích về hệ thống hiện tại, rồi nhận diện ra vấn đề của nó.

  • Hình 1-1-11 Lập kế hoạch cơ sở















  • Thủ tục chi tiết trong lập kế hoạch cơ sở được mô tả sau đây:

  • 1. Kế hoạch hệ thống hoá

  • Việc lập kế hoạch hệ thống hoá là công việc soạn thảo ra các kế hoạch cơ sở cho một hệ thống.



  • Điều tra và phân tích vấn đề trong các hoạt động nhằm tới việc hệ thống hoá.

  • Dựa trên kết quả của mục a, khảo sát giải pháp tốt nhất và sự cần thiết phát triển hệ thống được xem xét lại. Nếu thấy rằng có một giải pháp tốt hơn, thì chấp nhận giải pháp đó.

  • Nếu từ công việc của mục b thấy rằng việc phát triển hệ thống mới là thích hợp thì bản kế hoạch hệ thống hoá sẽ được tạo ra và được đề đạt cho người có trách nhiệm.



  • Bản kế hoạch hệ thống hoá.

  • 2. Kế hoạch thực hiện dự án

  • Sau khi người có trách nhiệm chấp thuận kế hoạch hệ thống hoá, thì bản kế hoạch thực hiện (bản kế hoạch thực hiện dự án) được viết ra.



  • a. Dự án được tổ chức (kể cả bổ nhiệm người phụ trách)

  • b. Bản kế hoạch tài nguyên hệ thống (ước lượng) được soạn thảo ra.

  • Kế hoạch nhân sự

  • Phần cứng cho phát triển hệ thống

  • Ước lượng qui mô phát triển (kể cả nhân lực và ngân sách)

  • Tài chính

  • Và những thứ khác

  • c. Bản kế hoạch tiến trình công việc và lịch biểu mức cao nhất được soạn ra.

  • Có các kiểu lịch sau:

  • Lịch biểu mức cao nhất: lịch cho toàn bộ hệ thống

  • Lịch biểu mức trung: Lịch cho từng pha trong việc phát triển hệ thống.

  • Lịch biểu mức thấp nhất: Lịch biểu cho từng người có liên quan.

  • Nếu lập được tất cả các loại lịch biểu trên tại pha này là tốt nhất nhưng thực tế thì khó làm được. Cho nên ít nhất cần soạn ra lịch biểu mức cao nhất tại pha này.



  • Bản kế hoạch phát triển.

  • 3. Xác định yêu cầu

  • Trong xác định yêu cầu, các chức năng đích thiết lập nên cái vào cho việc phát triển hệ thống, và các yêu cầu cho hệ thông tin được phân tích và định nghĩa chi tiết hơn trong các bản kế hoạch phát triển, bằng các phương pháp có cấu trúc như DFD (biểu đồ luồng dữ liệu) và ERD (biểu đồ thực thể quan hệ)



  • a. Thông tin về hệ thống, như công việc trong các chức năng đích (mô hình công việc được sinh ra tại đây được gọi là mô hình logic hiện tại), các khuôn mẫu được dùng và các mục đích, được thu thập.

  • b. Các yêu cầu về hệ thống xem như một tổng thể, bao gồm các chức năng, các yêu cầu hiệu năng và thao tác được xác định.

  • c. Các yêu cầu cho cả phần cứng và phần mềm được làm sáng tỏ.



  • Bản đặc tả yêu cầu

  • 4. Tóm tắt về việc lập kế hoạch cơ sở

  • Việc lập kế hoạch cơ sở là pha thiết kế ra đại cương về hệ thông tin, kể cả việc phân tích hệ thống cần phát triển và vạch ra lịch biểu mức cao nhất. Kết quả của nó ảnh hưởng rất nhiều tới các tiến trình đi sau. Bên cạnh đó, nó là pha đầu tiên trong việc phát triển hệ thống. Do đó, điều cần thiết là công việc được thực hiện với sự xác nhận của người dùng, công việc được người phân tích hệ thống có kĩ năng cao và có tri thức cốt lõi thực hiện.





(3) Thiết kế ngoài

  • Thiết kế ngoài là để xác định phần thấy được bên ngoài hay những phần dành cho giao tiếp với người dùng. Do đó, hệ thống được xét thuần tuý theo quan điểm của người dùng mà không để ý tới những ràng buộc về phần cứng (như máy tính). Bên cạnh đó, cấu trúc hệ thống cần được đạt tới cũng được làm sáng tỏ.


  • Hình 1-1-12 Thiết kế ngoài




























  • a. Kiểm tra đặc tả yêu cầu

  • Sau khi kiểm tra bản đặc tả yêu cầu có trong bản kế hoạch cơ sở, thì việc xét tổng quan về hệ thống được biểu diễn bởi việc dùng các biểu đồ sao cho việc xử lí và luồng dữ liệu có thể được hiểu dễ dàng. Dựa trên các biểu diễn này, thực hiện việc phân chia thành các hệ con và thiết kế vào/ra. Các DFD hay HIPO được dùng để vẽ biểu đồ.

  • b. Xác định các hệ con và phân chia thêm nữa

  • Toàn bộ hệ thống được chia thành một số hệ con trên cơ sở chức năng, rồi hệ con lại được phân chia thêm nữa thành các đơn vị nhỏ hơn.



  • c. Thiết kế tài liệu và màn hình.

  • Trong thiết kế màn hình và tài liệu, các thiết kế thô cho màn hình và việc chuyển đổi màn hình, thiết kế thô cho tài liệu vào/ra được tạo ra.

  • d. Thiết kế mã

  • Tại đây, việc thiết kế mã, như việc xác định hệ thống mã được tiến hành.

  • e. Thiết kế dữ liệu logic

  • Trong thiết kế dữ liệu logic, mối quan hệ giữa dữ liệu được phân tích, và ứng cử viên cho cơ sở dữ liệu và tệp được rút ra. (công việc chi tiết cho điều này được tiến hành trong thiết kế ngoài).

  • f. Xét duyệt thiết kế ngoài

  • Tài liệu thiết kế ngoài được xét duyệt.



  • Tài liệu thiết kế ngoài

  • Báo cáo xét duyệt tài liệu thiết kế ngoài

(4) Thiết kế trong

  • Thiết kế trong dành cho phần không thấy được của hệ thống, và xử lí với những thiết kế được xem xét từ phía máy tính hay phía phát triển hệ thống. Trong thiết kế ngoài, hệ thống được nhìn từ quan điểm của người dùng. Tuy nhiên trong thiết kế trong, các chi tiết được thiết kế bằng việc xem xét tới các thiết kế ngoài này được cài đặt hiệu quả thế nào trên máy tính, hay bởi việc tính tới những ràng buộc phần cứng cũng như phần mềm.

  • Trong thiết kế trong, công việc được chỉ ra trong Hình 1-1-13 sẽ được tiến hành.

  • Hình 1-1-13 Thiết kế trong



























  • a. Phân hoạch và cấu trúc chức năng (thiết kế cấu trúc)

  • Trong phân hoạch và cấu trúc chức năng (thiết kế cấu trúc), mỗi hệ con đều phân hoạch thành các đơn vị lập trình, và luồng dữ liệu và xử lí giữa các chương trình được làm sáng tỏ.

  • b. Thiết kế dữ liệu vật lí

  • Trong thiết kế dữ liệu vật lí (thiết kế tệp), để dùng hiệu quả các đặc trưng phần cứng, việc thiết kế vật lí về tệp và cơ sở dữ liệu được dựa trên thiết kế dữ liệu logic đã được thực hiện trong pha phân tích hệ thống.

  • c. Thiết kế vào-ra chi tiết

  • Trong thiết kế vào ra chi tiết, các chi tiết về màn hình và tài liệu vào-ra được thiết kế bằng việc dùng mẫu đặc biệt.

  • d. Xét duyệt thiết kế trong

  • Việc xét duyệt được tiến hành với tài liệu thiết kế trong.



  • Tài liệu thiết kế trong

  • Báo cáo xét duyệt thiết kế trong

(5) Thiết kế chương trình

  • Trong thiết kế chương trình, các cấu trúc trong của từng chương trình được thiết kế. Mỗi chương trình được dẫn ra qua việc phân chia trong pha thiết kế hệ thống lại được phân chia thêm nữa một cách có phân cấp thành các đơn vị chức năng được gọi là mô đun. Sau đó, các giao diện (dữ liệu vào/ra) giữa các modun được thiết kế.

  • Bên cạnh đó, các kế hoạch cho việc kiểm thử chương trình (tích hợp) cũng được chuẩn bị, và các trường hợp kiểm thử được thiết lập. Trong thiết kế chương trình, công việc được chỉ ra trong Hình 1-1-14 sẽ được tiến hành.

  • Hình 1-1-14 Thiết kế chương trình



















  • a. Thiết kế có cấu trúc cho chương trình (Phân hoạch môdun)

  • Trong thiết kế có cấu trúc, mỗi chương trình lại được phân hoạch thành các đơn vị chức năng được gọi là mô đun để cho phép dễ dàng bảo trì, còn luồng dữ liệu và xử lí giữa các chương trình thì rõ ràng, mạch lạc. Bên cạnh đó, các chức năng của từng mô đun và giao diện giữa các mô đun cũng được xác định.

  • b. Thiết kế các trường hợp kiểm thử (tích hợp) chương trình

  • Các kế hoạch cho kiểm thử chương trình được chuẩn bị và các trường hợp kiểm thử được thiết kế.





  • c. Xét duyệt thiết kế chương trình

  • Trong xét duyệt thiết kế chương trình, tiến hành xét duyệt tài liệu thiết kế chương trình.



  • Tài liệu thiết kế chương trình

  • Báo cáo xét duyệt thiết kế chương trình

  • Kế hoạch kiểm thử (tích hợp) chương trình

(6) Lập trình

  • Trong lập trình, việc thiết kế các cấu trúc logic của mô đun được định nghĩa trong pha thiết kế chi tiết và việc mã hoá cho các mô đun được thực hiện. Bên cạnh đó, các kế hoạch cho kiểm thử (đơn vị) mô đun được chuẩn bị, và các trường hợp kiểm thử được thiết lập.



  • a. Thiết kế mô đun

  • Trong thiết kế mô đun, các cấu trúc logic trong của mô đun (các thủ tục xử lí chi tiết bên trong từng mô đun) được thiết kế bằng việc dùng các kĩ thuật có cấu trúc khác nhau.

  • Hình 1-1-15 Lập trình



  • b. Lập kế hoạch kiểm thử đơn vị

  • Các kế hoạch kiểm thử đơn vị được chuẩn bị. (Tạo ra dữ liệu kiểm thử thích hợp, xác định lịch kiểm thử.)

  • c. Mã hoá

  • Từng mô đun được mã hoá trong ngôn ngữ lập trình

  • d. Kiểm thử đơn vị

  • Tiến hành kiểm thử đơn vị cho từng mô đun



  • Tài liệu thiết kế mô đun

  • Báo cáo xét duyệt thiết kế mô đun

  • Kế hoạch kiểm thử đơn vị

  • Danh sách chương trình gốc

  • Báo cáo xét duyệt chương trình gốc

  • Báo cáo kiểm thử đơn vị

(7) Kiểm thử

  • Công việc kiểm thử được tiến hành để phát hiện lỗi trong hành vi và cấu trúc của mô đun, chương trình hay hệ thống xem như một tổng thể (xem Hình 1-1-16). Nếu lỗi được tìm ra thì cần làm phản hồi, nếu cần, cho pha lập trình hay thiết kế để sửa chữa. Rồi lại tiến hành kiểm thử để kiểm tra liệu lỗi trên thực tế đã được sửa hay chưa.

  • Hình 1-1-16 Các loại kiểm thử























  • a. Kiểm thử đơn vị (được tiến hành trong pha lập trình)

  • Trong kiểm thử đơn vị, mỗi mô đun đều được kiểm tra xem liệu nó có thực hiện đúng đắn hay không.



  • b. Kiểm thử tích hợp

  • Trong kiểm thử tích hợp, các kiểm thử được tiến hành cho từng chương trình được tạo ra bằng việc móc nối các mô đun. Kiểm tra việc vận hành của chương trình và giao diện giữa các mô đun.

  • c. Kiểm thử hệ thống

  • Trong kiểm thử hệ thống, sự vận hành của hệ thống xem như một tổng thể được kiểm tra toàn bộ theo quan điểm của mục đích và hiệu năng được yêu cầu. Rồi việc bắt đầu vận hành thực tế được quyết định dựa trên kết quả này.

  • d. Kiểm thử vận hành

  • Trong kiểm thử vận hành, các nhóm vận hành từ phía người dùng tiến hành các kiểm thử trong điều kiện và môi trường như trong vận hành thực tế.



  • Báo cáo kiểm thử đơn vị

  • Báo cáo kiểm thử tích hợp

  • Báo cáo kiểm thử hệ thống

  • Báo cáo kiểm thử vận hành

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

  • Việc sản xuất theo hệ thống đã phát triển được bắt đầu. Các hoạt động bào trì được tiến hành khi khiếm khuyết (như khó dùng) hay lỗi được phát hiện ra, hay khi thay đổi là không thể tránh khỏi. Trong một số trường hợp, hệ thống cần phải được thay đổi.


1.2.4Dùng lại phần mềm


  • Hệ thống đã được phát triển trên cơ sở xây dựng theo đơn hàng. Dựa trên yêu cầu của người dùng, người phát triển phân tích các thao tác đích, và thiết kế, lập trình, và kiểm thử hệ thống trước khi hoàn thành việc phát triển của nó. Sau đó người dùng làm quen với thao tác của mình bằng việc dùng hệ thống đã được xây dựng đáp ứng cho các yêu cầu riêng của người đó.

  • Tuy nhiên bây giờ nhiều công ti bị phiền hà bởi việc tồn đọng của họ (các khoản mục phát triển còn chưa được bắt đầu). Việc sản xuất dựa theo xây dựng theo đơn hàng là nguyên nhân làm tăng thêm việc tồn đọng. Với sản xuất dựa theo việc xây dựng theo đơn hàng, việc phát triển hệ thống phải mất nhiều tháng và nhiều năm. Bên cạnh đó, việc tham dự của các chuyên gia như kĩ sư hệ thống (SE) là cần thiết để phát triển hệ thống. Tuy nhiên, trong những nỗ lực thực tế của các kĩ sư hệ thống tốn nhiều vào việc bảo trì hệ thống hiện có, điều này nghĩa là số nhân viên có thể dự phòng cho các dự án phát triển mới là nhỏ. Tình huống này đã tạo ra ý tưởng về việc dùng lại phần mềm hiện có.

  • Trong việc dùng lại phần mềm, các bộ phận của toàn bộ phần mềm được tạo ra từng phần, hay phần mềm hiện tại được phân tích, và sửa đổi, và kết quả là thu được phần mềm mới. Theo cách đó, một phần mềm có thể được dùng lặp lại trong các hệ thống khác nhau.

  • Có những cách sau đây để dùng lại phần mềm:

  • - Dùng lại như các bộ phận

  • - Dùng lại qua tái kĩ nghệ

(1) Dùng lại như các cấu phần

  • Phương pháp tạo ra các cấu phần từ phần mềm hiện có và lắp ráp chúng để xây dựng hệ thống mới làm giảm chi phí và tăng chất lượng hệ thống. Bên cạnh đó, chu kì phát triển có thể được làm ngắn lại.

  •  Phương pháp để tạo ra các cấu phần

  • Các bộ phận được chính người dùng tạo ra hay được người bán phần mềm cung cấp. Các bộ phận do người bán cung cấp đều được chuẩn hoá. Tuy nhiên, việc chuẩn hoá theo định dạng đặc biệt, và việc biểu diễn cũng cần cho các bộ phận do người dùng tạo ra. Lí do là ở chỗ các cấu phần mà không được chuẩn hoá thì không thể được lắp ráp đúng. Hơn nữa, trong khi ngôn ngữ nào được dùng về cơ bản không phải là vấn đề, thì tốt hơn cả là nên dùng cùng một ngôn ngữ để tính tới mã nguồn có thể phải được thay đổi.

Hình 1-1-17 Chuẩn hoá các cấu phần





















  •  Thư viện cấu phần và hệ thống tìm kiếm

  • Để xây dựng hệ thống bằng việc dùng các cấu phần phần mềm, các cấu phần được cất giữ và duy trì trong thư viện cấu phần. Số các cấu phần được cất giữ trong thư viện càng lớn, thì kết cấu của hệ thống càng trở nên linh hoạt hơn.

  • Hơn nữa, khi hệ thống tìm được cải tiến, thì thư viện cấu phần sẽ được dùng thường xuyên hơn, cải tiến cơ sở dữ liệu cấu phần và tăng cơ hội dùng thư viện.



Hình 1-1-18 Thư viện cấu phần





  • Sự tồn tại của thư viện cấu phần rất phong phú và công cụ dễ dùng tạo ra hiệu quả tổng hợp



  •  Cải tiến các cấu phần - tạo ra công cụ và công cụ tìm cấu phần

  • Khi cấu phần phần mềm được tạo ra và nó cung cấp cách thức dễ dàng để tìm kiếm cấu phần trong thư viện, thì việc dùng lại phần mềm sẽ được tăng tốc bởi vì dễ dùng. Hệ quả là sẽ có thể cung cấp các công cụ tạo cấu phần đã được cải tiến và những công cụ tìm cấu phần.

  • Các phương pháp hay công cụ để phát triển ứng dụng bằng việc lắp ráp các cấu phần phần mềm được tạo ra, dựa trên các đặc tả chuẩn để có khả năng dùng lại, được gọi là "componentware."

(2) Dùng lại qua tái kĩ nghệ

  • Việc tạo ra phần mềm mới từ phần mềm hiện có được gọi là "tái kĩ nghệ.Tái kĩ nghệ là công nghệ được dùng để tạo ra hệ thống mới bằng việc sử dụng hệ thống đang trong sử dụng.

  • Để thực hiện tái kĩ nghệ, các công cụ CASE (như công cụ CASE bảo trì) thường được dùng.

  • Trong tái kĩ nghệ thông thường, các đặc tả phần mềm hiện có được dẫn ra ngay bước đầu tiên. Công nghệ được dùng trong phần này của công việc được gọi là "kĩ nghệ đảo". Sau đó, đặc tả cho phần mềm mới được tạo ra bằng việc sửa đổi đặc tả suy dẫn. Dựa trên các đặc tả mới, một hệ thống mới được tạo ra. Công nghệ phát triển truyền thống được dùng ở đây được gọi là "kĩ nghệ tiến" tương phản với 'kĩ nghệ đảo" (xem Hình 1-1-19).



Hình 1-1-19 Tái kĩ nghệ






 Tiến   Đảo   Tiến

= Tái kĩ nghệ


tải về 1.95 Mb.

Chia sẻ với bạn bè của bạn:
1   2   3   4   5   6   7   8   9   ...   20



Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý
    Quê hương
BÁO CÁO
Tài liệu