Bệnh ngoài da 

Các mô hình và các giai đoạn của vòng đời phần mềm. Mô hình vòng đời phần mềm


Tiêu chuẩn vòng đời phần mềm

  • GOST 34.601-90
  • ISO/IEC 12207:1995 (tương tự tiếng Nga - GOST R ISO/IEC 12207-99)

Phương pháp phát triển phần mềm

  • Quy trình Hợp nhất Hợp lý (RUP).
  • Khung giải pháp của Microsoft (MSF). Bao gồm 4 giai đoạn: phân tích, thiết kế, phát triển, ổn định, liên quan đến việc sử dụng mô hình hướng đối tượng.
  • Lập trình cực đoan ( lập trình cực đỉnh, XP). Phương pháp này dựa trên tinh thần đồng đội, giao tiếp hiệu quả giữa khách hàng và nhà thầu trong toàn bộ dự án phát triển IS. Quá trình phát triển được thực hiện bằng cách sử dụng các nguyên mẫu được cải tiến liên tiếp.

Tiêu chuẩn GOST 34.601-90

Tiêu chuẩn GOST 34.601-90 cung cấp các giai đoạn và giai đoạn tạo hệ thống tự động sau:

  1. Hình thành các yêu cầu đối với AU
    1. Kiểm tra đối tượng và biện minh cho nhu cầu tạo AU
    2. Hình thành các yêu cầu của người dùng đối với AU
    3. Đăng ký một báo cáo về hiệu suất công việc và một ứng dụng cho sự phát triển của AS
  2. Sự phát triển của khái niệm AS
    1. Nghiên cứu đối tượng
    2. Thực hiện các công việc nghiên cứu cần thiết
    3. Phát triển các biến thể của khái niệm AU và lựa chọn biến thể của khái niệm AU đáp ứng yêu cầu của người dùng
    4. Chuẩn bị một báo cáo về công việc được thực hiện
  3. Nhiệm vụ kỹ thuật
    1. Phát triển và phê duyệt các điều khoản tham chiếu cho việc thành lập AU
  4. thiết kế sơ bộ
    1. Phát triển các giải pháp thiết kế sơ bộ cho hệ thống và các bộ phận của nó
  5. dự án kỹ thuật
    1. Phát triển các giải pháp thiết kế cho hệ thống và các bộ phận của nó
    2. Phát triển tài liệu cho AU và các bộ phận của nó
    3. Phát triển và thực hiện các tài liệu cho việc cung cấp các thành phần
    4. Phát triển các nhiệm vụ thiết kế trong các phần liền kề của dự án
  6. tài liệu làm việc
    1. Phát triển tài liệu làm việc cho NPP và các bộ phận của nó
    2. Phát triển và điều chỉnh các chương trình
  7. vận hành
    1. Chuẩn bị đối tượng tự động hóa
    2. Huấn luyện nhân viên
    3. Hoàn thành AU với các sản phẩm được cung cấp (phần mềm và phần cứng, hệ thống phần mềm và phần cứng, sản phẩm thông tin)
    4. Công trình xây lắp
    5. vận hành công trình
    6. Tiến hành các xét nghiệm sơ bộ
    7. Tiến hành vận hành thử
    8. Tiến hành nghiệm thu
  8. hỗ trợ máy lạnh.
    1. Thực hiện công việc theo đúng nghĩa vụ bảo hành
    2. Dịch vụ sau bảo hành

Dự thảo, thiết kế kỹ thuật và tài liệu làm việc là một cấu trúc nhất quán của các giải pháp thiết kế ngày càng chính xác hơn. Cho phép loại trừ giai đoạn “Thiết kế phác thảo” và các giai đoạn công việc riêng lẻ ở tất cả các giai đoạn, kết hợp giai đoạn “Thiết kế kỹ thuật” và “Hồ sơ chi tiết” thành giai đoạn “Thiết kế chi tiết”, thực hiện song song các giai đoạn, công việc khác nhau, để bao gồm những cái bổ sung.

Tiêu chuẩn này không hoàn toàn phù hợp để phát triển ở thời điểm hiện tại: nhiều quy trình không được phản ánh đầy đủ và một số quy định đã lỗi thời.

ISO/IEC 12207/ và ứng dụng của nó

ISO/IEC 12207:1995 "Công nghệ thông tin - Các quy trình vòng đời phần mềm" là tài liệu quy chuẩn chính quy định thành phần của các quy trình vòng đời phần mềm. Nó xác định khung vòng đời chứa các quy trình, hoạt động và nhiệm vụ phải được hoàn thành trong quá trình phát triển phần mềm.

Mỗi quá trình được chia thành một tập hợp các hành động, mỗi hành động thành một tập hợp các nhiệm vụ. Mỗi quy trình, hành động hoặc tác vụ được bắt đầu và thực hiện bởi một quy trình khác khi cần và không có trình tự thực hiện được xác định trước. Các kết nối theo dữ liệu đầu vào được giữ nguyên.

Quy trình vòng đời phần mềm

  • Chủ yếu:
    • Mua lại (hành động và nhiệm vụ của khách hàng mua phần mềm)
    • Giao hàng (các hoạt động và nhiệm vụ của nhà cung cấp cung cấp cho khách hàng sản phẩm hoặc dịch vụ phần mềm)
    • Phát triển (các hành động và nhiệm vụ được thực hiện bởi nhà phát triển: tạo phần mềm, soạn thảo tài liệu thiết kế và vận hành, chuẩn bị tài liệu kiểm tra và đào tạo, v.v.)
    • Vận hành (hành động, nhiệm vụ của người vận hành - tổ chức vận hành hệ thống)
    • Bảo trì (các hành động và nhiệm vụ được thực hiện bởi tổ chức đi kèm, nghĩa là dịch vụ bảo trì). Bảo trì - thực hiện các thay đổi đối với phần mềm để sửa lỗi, cải thiện hiệu suất hoặc thích ứng với các điều kiện hoặc yêu cầu vận hành đang thay đổi.
  • Phụ trợ
    • Tài liệu (mô tả chính thức về thông tin được tạo trong vòng đời phần mềm)
    • Quản lý cấu hình (áp dụng các thủ tục hành chính và kỹ thuật trong suốt vòng đời phần mềm để xác định trạng thái của các thành phần phần mềm, quản lý các sửa đổi của nó).
    • Đảm bảo chất lượng (đảm bảo rằng IS và các quy trình trong vòng đời của nó tuân thủ các yêu cầu cụ thể và các kế hoạch đã được phê duyệt)
    • Xác minh (xác định rằng các sản phẩm phần mềm, là kết quả của một số hành động, đáp ứng đầy đủ các yêu cầu hoặc điều kiện do các hành động trước đó)
    • Chứng nhận (xác định tính đầy đủ của việc tuân thủ các yêu cầu được chỉ định và hệ thống được tạo với mục đích chức năng cụ thể của chúng)
    • Đánh giá chung (đánh giá tình trạng công việc của dự án: kiểm soát việc lập kế hoạch và quản lý tài nguyên, nhân sự, thiết bị, công cụ)
    • Kiểm toán (xác định việc tuân thủ các yêu cầu, kế hoạch và điều khoản của hợp đồng)
    • Giải quyết vấn đề (phân tích và giải quyết các vấn đề, bất kể nguồn gốc hay nguồn gốc của chúng, được phát hiện trong quá trình phát triển, vận hành, bảo trì hoặc các quy trình khác)
  • tổ chức
    • Quản lý (các hoạt động và nhiệm vụ có thể được thực hiện bởi bất kỳ bên nào quản lý quy trình của họ)
    • Tạo cơ sở hạ tầng (lựa chọn và bảo trì công nghệ, tiêu chuẩn và công cụ, lựa chọn và cài đặt phần cứng và phần mềm được sử dụng để phát triển, vận hành hoặc bảo trì phần mềm)
    • Cải tiến (đánh giá, đo lường, kiểm soát và cải tiến các quy trình vòng đời)
    • Đào tạo (đào tạo ban đầu và phát triển nhân viên liên tục sau đó)

Mỗi quá trình bao gồm một số hoạt động. Ví dụ: quy trình mua lại bao gồm các bước sau:

  1. Bắt đầu mua lại
  2. Chuẩn bị hồ sơ dự thầu
  3. Soạn thảo và điều chỉnh hợp đồng
  4. giám sát nhà cung cấp
  5. Nghiệm thu và hoàn thành công trình

Mỗi hành động bao gồm một số nhiệm vụ. Ví dụ, việc chuẩn bị hồ sơ dự thầu nên bao gồm:

  1. Hình thành các yêu cầu đối với hệ thống
  2. Lập danh mục sản phẩm phần mềm
  3. Đặt điều kiện và thỏa thuận
  4. Mô tả các giới hạn kỹ thuật (môi trường vận hành hệ thống, v.v.)

Các giai đoạn vòng đời phần mềm, mối quan hệ giữa các quy trình và các giai đoạn

Mô hình vòng đời phần mềm- một cấu trúc xác định trình tự thực hiện và mối quan hệ của các quy trình, hành động và nhiệm vụ trong suốt vòng đời. Mô hình vòng đời phụ thuộc vào các chi tiết cụ thể, quy mô và độ phức tạp của dự án và các điều kiện cụ thể mà hệ thống được tạo ra và vận hành.

Tiêu chuẩn GOST R ISO/IEC 12207-99 không đưa ra mô hình vòng đời cụ thể. Các điều khoản của nó là chung cho mọi mô hình vòng đời, phương pháp và công nghệ để tạo IP. Nó mô tả cấu trúc của các quy trình vòng đời mà không chỉ định cách triển khai hoặc thực hiện các hoạt động và nhiệm vụ có trong các quy trình này.

Mô hình vòng đời phần mềm bao gồm:

  1. giai đoạn;
  2. Kết quả công việc từng giai đoạn;
  3. Các sự kiện chính - điểm hoàn thành công việc và ra quyết định.

Sân khấu- một phần của quy trình tạo phần mềm, được giới hạn bởi một khung thời gian nhất định và kết thúc bằng việc phát hành một sản phẩm cụ thể (mô hình, thành phần phần mềm, tài liệu), được xác định bởi các yêu cầu được chỉ định cho giai đoạn này.

Ở mỗi giai đoạn, một số quy trình được xác định trong ISO/IEC 12207-99 có thể được thực hiện và ngược lại, cùng một quy trình có thể được thực hiện ở các giai đoạn khác nhau. Mối quan hệ giữa các quy trình và các giai đoạn cũng được xác định bởi mô hình vòng đời phần mềm được sử dụng.

Mô hình vòng đời phần mềm

Mô hình vòng đời được hiểu là một cấu trúc xác định trình tự thực hiện và mối quan hệ của các quy trình, hoạt động và nhiệm vụ được thực hiện trong suốt vòng đời. Mô hình vòng đời phụ thuộc vào các chi tiết cụ thể của hệ thống thông tin và các điều kiện cụ thể mà hệ thống thông tin được tạo ra và vận hành.

Cho đến nay, các mô hình vòng đời chính sau đây được sử dụng rộng rãi nhất:

  • Mô hình nhiệm vụ;
  • mô hình thác (hoặc hệ thống) (70-85);
  • mô hình xoắn ốc (hiện tại).

mô hình nhiệm vụ

Khi phát triển một hệ thống "từ dưới lên" từ các tác vụ riêng lẻ đến toàn bộ hệ thống (mô hình tác vụ), chắc chắn sẽ mất đi một cách tiếp cận duy nhất để phát triển, các vấn đề nảy sinh trong quá trình kết nối thông tin của các thành phần riêng lẻ. Theo quy định, khi số lượng nhiệm vụ tăng lên, khó khăn tăng lên, cần phải liên tục thay đổi các chương trình và cấu trúc dữ liệu hiện có. Tốc độ phát triển của hệ thống chậm lại, điều này làm chậm sự phát triển của chính tổ chức. Tuy nhiên, trong một số trường hợp, công nghệ này có thể phù hợp:

  • Cực kỳ khẩn cấp (điều cần thiết là ít nhất bằng cách nào đó các nhiệm vụ được giải quyết; sau đó bạn phải làm lại mọi thứ);
  • Thử nghiệm và thích ứng của khách hàng (các thuật toán không rõ ràng, các giải pháp được tìm kiếm bằng cách thử và sai).

Kết luận chung là không thể tạo ra một hệ thống thông tin hiệu quả đủ lớn theo cách này.

mô hình thác

mô hình thác vòng đời được đề xuất vào năm 1970 bởi Winston Royce. Nó cung cấp cho việc thực hiện tuần tự tất cả các giai đoạn của dự án theo một thứ tự cố định nghiêm ngặt. Việc chuyển sang giai đoạn tiếp theo có nghĩa là hoàn thành toàn bộ công việc ở giai đoạn trước (Hình 1). Các yêu cầu được xác định ở giai đoạn hình thành yêu cầu được ghi lại nghiêm ngặt dưới dạng các điều khoản tham chiếu và cố định trong toàn bộ thời gian phát triển dự án. Mỗi giai đoạn lên đến đỉnh điểm trong việc phát hành một bộ tài liệu hoàn chỉnh đủ để nhóm phát triển khác tiếp tục phát triển.

Các khía cạnh tích cực của việc áp dụng cách tiếp cận theo tầng như sau:

  • ở mỗi giai đoạn, một bộ tài liệu dự án hoàn chỉnh được hình thành đáp ứng các tiêu chí về tính đầy đủ và nhất quán;
  • các giai đoạn công việc được thực hiện theo trình tự hợp lý cho phép bạn lập kế hoạch thời gian hoàn thành tất cả công việc và chi phí tương ứng.

Các giai đoạn dự án theo mô hình thác nước:

  1. Hình thành các yêu cầu;
  2. Thiết kế;
  3. Thực hiện;
  4. Kiểm tra;
  5. thực hiện;
  6. Vận hành và bảo trì.

Cơm. 1. Đề án phát triển bậc thang

Cách tiếp cận thác nước đã chứng tỏ bản thân trong việc xây dựng các hệ thống thông tin mà ngay từ đầu quá trình phát triển, tất cả các yêu cầu có thể được xây dựng khá chính xác và đầy đủ để cho phép các nhà phát triển tự do thực hiện chúng một cách tốt nhất có thể từ quan điểm kỹ thuật. Các hệ thống tính toán phức tạp, hệ thống thời gian thực và các nhiệm vụ tương tự khác thuộc loại này. Tuy nhiên, trong quá trình sử dụng phương pháp này, một số thiếu sót của nó đã được phát hiện, chủ yếu là do quá trình tạo hệ thống thực sự không bao giờ hoàn toàn phù hợp với một sơ đồ cứng nhắc như vậy. Trong quá trình sáng tạo, luôn có nhu cầu quay lại các giai đoạn trước đó và làm rõ hoặc sửa đổi các quyết định đã đưa ra trước đó. Do đó, quy trình tạo phần mềm thực sự có dạng sau (Hình 2):

Cơm. 2. Quy trình thực sự của phát triển phần mềm theo sơ đồ cascade

Nhược điểm chính của cách tiếp cận theo tầng là độ trễ đáng kể trong việc thu được kết quả. Việc phối hợp kết quả với người dùng chỉ được thực hiện tại các điểm đã lên kế hoạch sau khi hoàn thành từng giai đoạn công việc, các yêu cầu đối với hệ thống thông tin được "đóng băng" dưới dạng một nhiệm vụ kỹ thuật trong toàn bộ thời gian tạo ra nó. Do đó, người dùng chỉ có thể gửi nhận xét của mình sau khi công việc trên hệ thống được hoàn thành đầy đủ. Nếu các yêu cầu không được nêu chính xác hoặc thay đổi trong một thời gian dài phát triển phần mềm, người dùng sẽ nhận được một hệ thống không đáp ứng nhu cầu của họ. Các mô hình (cả chức năng và thông tin) của một đối tượng tự động có thể trở nên lỗi thời đồng thời với sự chấp thuận của chúng. Bản chất của cách tiếp cận có hệ thống đối với sự phát triển của IS nằm ở sự phân rã (phân vùng) thành các chức năng tự động: hệ thống được chia thành các hệ thống con chức năng, từ đó được chia thành các chức năng con, được chia thành các nhiệm vụ, v.v. Quá trình phân vùng tiếp tục cho đến các thủ tục cụ thể. Đồng thời, hệ thống tự động vẫn giữ được cái nhìn tổng thể trong đó tất cả các thành phần được kết nối với nhau. Do đó, mô hình này có ưu điểm chính là phát triển có hệ thống và nhược điểm chính là chậm và tốn kém.

mô hình xoắn ốc

Để khắc phục những vấn đề này, người ta đề xuất mô hình xoắn ốc vòng đời (Hình 3), được phát triển vào giữa những năm 1980 bởi Barry Boehm. Nó dựa trên các giai đoạn ban đầu của vòng đời: phân tích và thiết kế. Ở những giai đoạn này, tính khả thi của các giải pháp kỹ thuật được kiểm tra bằng cách tạo nguyên mẫu.

Nguyên mẫu- một thành phần phần mềm hoạt động thực hiện các chức năng riêng lẻ và giao diện bên ngoài. Mỗi lần lặp tương ứng với việc tạo một đoạn hoặc phiên bản của phần mềm, tại đó các mục tiêu và đặc điểm của dự án được chỉ định, chất lượng của kết quả thu được được đánh giá và công việc của lần lặp tiếp theo được lên kế hoạch.

Mỗi lần lặp lại là một chu kỳ phát triển hoàn chỉnh dẫn đến việc phát hành phiên bản bên trong hoặc bên ngoài của sản phẩm (hoặc một tập hợp con của sản phẩm cuối cùng) được cải tiến từ lần lặp này sang lần lặp khác để trở thành một hệ thống hoàn chỉnh.

Mỗi vòng xoắn ốc tương ứng với việc tạo ra một đoạn hoặc phiên bản phần mềm, trên đó các mục tiêu và đặc điểm của dự án được chỉ định, chất lượng của nó được xác định và công việc của vòng xoắn ốc tiếp theo được lên kế hoạch. Do đó, các chi tiết của dự án được đào sâu và cụ thể hóa một cách nhất quán, và kết quả là một phương án hợp lý được lựa chọn để đưa vào thực hiện.

Sự phát triển bằng cách lặp đi lặp lại phản ánh chu kỳ xoắn ốc tồn tại một cách khách quan của việc tạo ra hệ thống. Việc hoàn thành công việc chưa hoàn thành ở mỗi giai đoạn cho phép bạn chuyển sang giai đoạn tiếp theo mà không cần chờ hoàn thành công việc ở giai đoạn hiện tại. Với sự phát triển lặp đi lặp lại, công việc còn thiếu có thể được hoàn thành trong lần lặp lại tiếp theo. Nhiệm vụ chính là hiển thị cho người dùng hệ thống một sản phẩm khả thi càng sớm càng tốt, từ đó kích hoạt quá trình làm rõ và bổ sung các yêu cầu.

Vấn đề chính của chu kỳ xoắn ốc là xác định thời điểm chuyển sang giai đoạn tiếp theo. Để giải quyết nó, cần phải đưa ra các giới hạn thời gian cho từng giai đoạn của vòng đời. Quá trình chuyển đổi diễn ra theo kế hoạch, ngay cả khi không phải tất cả các công việc theo kế hoạch đều được hoàn thành. Kế hoạch được soạn thảo trên cơ sở dữ liệu thống kê thu được trong các dự án trước đó và kinh nghiệm cá nhân của các nhà phát triển.

Hình 3. Mô hình vòng đời xoắn ốc của IS

Một trong những cách tiếp cận khả thi để phát triển phần mềm trong khuôn khổ mô hình vòng đời xoắn ốc là phương pháp phát triển ứng dụng nhanh RAD (Rapid Application Development) được sử dụng rộng rãi gần đây. Thuật ngữ này thường được hiểu là một quy trình phát triển phần mềm bao gồm 3 yếu tố:

  • một nhóm lập trình viên nhỏ (từ 2 đến 10 người);
  • lịch trình sản xuất ngắn nhưng được vạch ra cẩn thận (từ 2 đến 6 tháng);
  • một chu kỳ lặp đi lặp lại trong đó các nhà phát triển, khi ứng dụng bắt đầu hình thành, yêu cầu và triển khai trong sản phẩm các yêu cầu nhận được thông qua tương tác với khách hàng.

Vòng đời phần mềm theo phương pháp RAD bao gồm bốn giai đoạn:

  • giai đoạn xác định và phân tích yêu cầu;
  • giai đoạn thiết kế;
  • giai đoạn thực hiện;
  • giai đoạn thực hiện.

Tại mỗi lần lặp lại, những điều sau đây được đánh giá:

  • rủi ro vượt quá các điều khoản và chi phí của dự án;
  • sự cần thiết phải thực hiện một lần lặp khác;
  • mức độ đầy đủ và chính xác của việc hiểu các yêu cầu đối với hệ thống;
  • lý do chấm dứt dự án.

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

  • Phát triển lặp lại đơn giản hóa rất nhiều việc đưa ra các thay đổi cho dự án khi thay đổi yêu cầu của khách hàng.
  • Khi sử dụng mô hình xoắn ốc, các yếu tố riêng lẻ của hệ thống thông tin dần dần được tích hợp thành một tổng thể duy nhất. Trong cách tiếp cận lặp, tích hợp hầu như liên tục. Vì quá trình tích hợp bắt đầu với ít phần tử hơn nên sẽ có ít vấn đề hơn trong quá trình triển khai (theo một số ước tính, khi sử dụng mô hình phát triển thác nước, việc tích hợp chiếm tới 40% tổng chi phí khi kết thúc dự án).
  • Phát triển lặp lại cung cấp tính linh hoạt cao hơn trong quản lý dự án bằng cách cho phép thực hiện các thay đổi chiến thuật đối với sản phẩm đang được phát triển.
  • Phương pháp lặp lại đơn giản hóa việc sử dụng lại các thành phần (thực hiện cách tiếp cận thành phần để lập trình). Điều này là do thực tế là việc xác định (xác định) các phần chung của dự án khi chúng đã được phát triển một phần sẽ dễ dàng hơn nhiều so với việc cố gắng làm nổi bật chúng ngay từ đầu dự án. Xem lại thiết kế sau một số lần lặp lại ban đầu cho thấy các thành phần phổ biến có thể tái sử dụng sẽ được cải thiện trong các lần lặp lại tiếp theo.
  • Mô hình xoắn ốc cho phép bạn có được một hệ thống ổn định và đáng tin cậy hơn. Điều này là do khi hệ thống phát triển, các lỗi và điểm yếu được tìm thấy và khắc phục ở mỗi lần lặp lại. Đồng thời, các tham số hiệu suất quan trọng có thể được điều chỉnh, trong trường hợp mô hình thác nước, các tham số này chỉ khả dụng trước khi triển khai hệ thống.
  • Cách tiếp cận lặp đi lặp lại tạo cơ hội để cải thiện quy trình phát triển - phân tích được thực hiện ở cuối mỗi lần lặp lại cho phép bạn đánh giá những gì cần thay đổi trong tổ chức phát triển và cải thiện nó trong lần lặp lại tiếp theo.

Dưới Mô hình vòng đời phần mềm được hiểu là một cấu trúc xác định trình tự thực hiện và mối quan hệ của các quy trình, hành động và nhiệm vụ trong suốt vòng đời. Mô hình vòng đời phụ thuộc vào các chi tiết cụ thể, quy mô và độ phức tạp của dự án và các điều kiện cụ thể mà hệ thống được tạo ra và vận hành.

Tiêu chuẩn ISO/IEC 12207 không đưa ra mô hình vòng đời và phương pháp phát triển phần mềm cụ thể. Các điều khoản của nó là chung cho mọi mô hình vòng đời, phương pháp và công nghệ phát triển phần mềm. Tiêu chuẩn mô tả cấu trúc của các quy trình vòng đời phần mềm, nhưng không chỉ định chi tiết cách triển khai hoặc thực hiện các hoạt động và nhiệm vụ có trong các quy trình này.

Mô hình vòng đời của bất kỳ phần mềm EIS cụ thể nào xác định bản chất của quá trình tạo ra nó, đó là một tập hợp các công việc được sắp xếp theo thời gian, được kết nối với nhau và thống nhất theo các giai đoạn, việc triển khai là cần thiết và đủ để tạo ra phần mềm đáp ứng các yêu cầu cụ thể. yêu cầu. Giai đoạn tạo phần mềm được hiểu là một phần của quy trình tạo phần mềm, được giới hạn bởi một số khung thời gian và kết thúc bằng việc phát hành một sản phẩm cụ thể (mô hình phần mềm, thành phần phần mềm, tài liệu), được xác định bởi các yêu cầu được chỉ định cho giai đoạn này. Các giai đoạn tạo phần mềm được phân biệt vì lý do lập kế hoạch hợp lý và tổ chức công việc, kết thúc với kết quả mong muốn. Vòng đời phần mềm thường bao gồm các giai đoạn sau:

  • 1. Hình thành yêu cầu phần mềm.
  • 2. Thiết kế.
  • 3. Thực hiện.
  • 4. Thử nghiệm.
  • 5. Vận hành thử.
  • 6. Vận hành và bảo dưỡng.
  • 7. Ngừng hoạt động.

Giai đoạn hình thành yêu cầu phần mềm. Đây là một trong những điều quan trọng nhất, bởi vì nó quyết định sự thành công của toàn bộ dự án. Giai đoạn này bao gồm các bước sau:

lập kế hoạch công việc, dự kiến ​​các công việc trong dự án. Nhiệm vụ chính của giai đoạn là: xác định mục tiêu phát triển, đánh giá kinh tế sơ bộ của dự án, xây dựng lịch trình công việc, thành lập và đào tạo nhóm làm việc chung;

tiến hành khảo sát các hoạt động của một đối tượng (tổ chức) tự động hóa, trong khuôn khổ của nó được thực hiện như sau: xác định sơ bộ các yêu cầu cho hệ thống trong tương lai; xác định cấu trúc của tổ chức; xác định danh sách các chức năng mục tiêu của tổ chức; phân tích sự phân bổ chức năng của các bộ phận và nhân viên; xác định các tương tác chức năng giữa các phòng ban, luồng thông tin trong các phòng ban và giữa chúng, các đối tượng bên ngoài liên quan đến tổ chức và các tương tác thông tin bên ngoài; phân tích các phương tiện hiện có để tự động hóa các hoạt động của tổ chức;

xây dựng các mô hình hoạt động của tổ chức, bao gồm việc xử lý các tài liệu khảo sát và xây dựng hai loại mô hình:

mô hình "AS-IS" ("nguyên trạng") phản ánh tình trạng hiện tại của tổ chức tại thời điểm khảo sát và cho phép bạn hiểu tổ chức hoạt động như thế nào, cũng như xác định các nút thắt cổ chai và đưa ra các đề xuất để cải thiện tình huống;

mô hình "TO-BE" ("như nó phải là"), phản ánh ý tưởng về công nghệ mới của tổ chức.

Mỗi mô hình bao gồm một mô hình thông tin và chức năng hoàn chỉnh về các hoạt động của tổ chức, cũng như, nếu cần, một mô hình mô tả động lực của hành vi của tổ chức.

Việc chuyển đổi từ mô hình "AS-IS" sang mô hình "TO-BE" có thể được thực hiện theo hai cách:

  • 1. Cải tiến công nghệ hiện có trên cơ sở đánh giá hiệu quả.
  • 2. Thay đổi triệt để công nghệ và thiết kế lại quy trình kinh doanh (reengineering of business process).

Các mô hình được xây dựng có ý nghĩa thực tiễn độc lập. Ví dụ: mô hình "AS-IS" cho phép bạn xác định các nút thắt cổ chai trong các công nghệ hiện có và đưa ra các khuyến nghị để giải quyết vấn đề, bất kể việc phát triển thêm EIS có được mong đợi ở giai đoạn này hay không. Ngoài ra, mô hình tạo điều kiện thuận lợi cho việc đào tạo nhân viên trong các lĩnh vực hoạt động cụ thể của tổ chức thông qua việc sử dụng các sơ đồ trực quan (được biết rằng "một bức tranh đáng giá cả ngàn từ").

Thiết kế sân khấu. Nó thường bao gồm các bước sau:

  • * phát triển một dự án hệ thống. Ở giai đoạn này, câu trả lời được đưa ra cho câu hỏi: "Hệ thống trong tương lai nên làm gì?", cụ thể là: kiến ​​trúc của hệ thống, chức năng của nó, điều kiện hoạt động bên ngoài, giao diện và phân phối chức năng giữa người dùng và hệ thống, các yêu cầu đối với các thành phần phần mềm và thông tin, thành phần của những người thực hiện và thời gian phát triển. Cơ sở của dự án hệ thống là các mô hình của EIS được thiết kế, được xây dựng trên cơ sở mô hình "TO-BE". Kết quả được ghi lại của giai đoạn này là các điều khoản tham chiếu;
  • * Phát triển một dự án kỹ thuật. Ở giai đoạn này, trên cơ sở thiết kế hệ thống, thiết kế hệ thống thực tế được thực hiện, bao gồm thiết kế kiến ​​trúc hệ thống và thiết kế chi tiết. Do đó, một câu trả lời được đưa ra cho câu hỏi: "Làm thế nào để xây dựng một hệ thống sao cho nó đáp ứng các yêu cầu đặt ra cho nó?". Đồng thời, các mô hình của EIS thiết kế được trau chuốt và chi tiết đến mức cần thiết.

Mỗi giai đoạn có thể chạy nhiều quy trình được xác định trong ISO/IEC 12207 và ngược lại, cùng một quy trình có thể chạy trong các giai đoạn khác nhau.

Cho đến nay, hai mô hình chính sau đây của vòng đời phần mềm đã được sử dụng rộng rãi nhất: mô hình theo tầng (1970-1985) và mô hình xoắn ốc (1986-1990).

Trong EIS đồng nhất của thập niên 70 và 80. phần mềm ứng dụng là một thực thể duy nhất. Để phát triển loại phần mềm này, người ta đã sử dụng cách tiếp cận thác nước (tên gọi khác là thác nước) (Hình 1.3). Đặc điểm cơ bản của cách tiếp cận theo tầng là như sau: quá trình chuyển đổi sang giai đoạn tiếp theo chỉ được thực hiện sau khi công việc ở giai đoạn hiện tại được hoàn thành đầy đủ và không cung cấp khả năng quay lại các giai đoạn đã qua. Mỗi giai đoạn kết thúc với một số kết quả làm đầu vào cho giai đoạn tiếp theo. Các yêu cầu đối với phần mềm đã phát triển, được xác định ở giai đoạn hình thành yêu cầu, được ghi lại nghiêm ngặt dưới dạng nhiệm vụ kỹ thuật và được cố định trong toàn bộ thời gian phát triển dự án. Mỗi giai đoạn lên đến đỉnh điểm trong việc phát hành một bộ tài liệu hoàn chỉnh đủ để nhóm phát triển khác tiếp tục phát triển. Tiêu chí cho chất lượng phát triển với phương pháp này là độ chính xác của việc đáp ứng các thông số kỹ thuật của các điều khoản tham chiếu.

Đồng thời, sự chú ý chính của các nhà phát triển tập trung vào việc đạt được các giá trị tối ưu cho các đặc tính kỹ thuật của phần mềm đang được phát triển: hiệu suất, dung lượng bộ nhớ chiếm dụng, v.v.

Những ưu điểm của việc sử dụng phương pháp xếp tầng như sau:

ở mỗi giai đoạn, một bộ tài liệu dự án hoàn chỉnh được hình thành đáp ứng các tiêu chí về tính đầy đủ và nhất quán;

các giai đoạn công việc được thực hiện theo trình tự hợp lý cho phép bạn lập kế hoạch thời gian hoàn thành tất cả công việc và chi phí tương ứng.

Cách tiếp cận theo tầng đã được chứng minh trong việc xây dựng EIS, trong đó ngay từ đầu quá trình phát triển, có thể xây dựng tất cả các yêu cầu khá chính xác và đầy đủ để giúp các nhà phát triển tự do triển khai chúng về mặt kỹ thuật tốt nhất có thể. Danh mục này bao gồm các hệ thống phức tạp với số lượng lớn các tác vụ tính toán, hệ thống thời gian thực, v.v.

Đồng thời, cách tiếp cận này có một số nhược điểm, chủ yếu là do quy trình phát triển phần mềm thực sự chưa bao giờ hoàn toàn phù hợp với một sơ đồ cứng nhắc như vậy. Quy trình tạo phần mềm, như một quy luật, có tính chất lặp đi lặp lại: kết quả của giai đoạn tiếp theo thường gây ra những thay đổi trong các quyết định thiết kế được phát triển ở giai đoạn trước. Do đó, luôn có nhu cầu quay lại các giai đoạn trước đó và làm rõ hoặc sửa đổi các quyết định đã đưa ra trước đó. Do đó, quá trình tạo phần mềm thực tế có một dạng khác (Hình 1.4).

Hiển thị trong hình. Sơ đồ trong Hình 1.4 thường được gọi là một mô hình riêng biệt, cái gọi là mô hình điều khiển trung gian, trong đó các điều chỉnh giữa các giai đoạn mang lại độ tin cậy cao hơn mô hình thác nước, mặc dù chúng làm tăng toàn bộ giai đoạn phát triển.

Nhược điểm chính của cách tiếp cận theo tầng là độ trễ đáng kể trong việc thu được kết quả và do đó, có nguy cơ khá cao khi tạo ra một hệ thống không đáp ứng nhu cầu thay đổi của người dùng. Thực tiễn cho thấy rằng ở giai đoạn đầu của dự án, không thể hình thành đầy đủ và chính xác tất cả các yêu cầu cho hệ thống trong tương lai. Điều này là do hai lý do:

  • 1. Người dùng không thể nói ngay tất cả các yêu cầu của mình và không thể thấy trước chúng sẽ thay đổi như thế nào trong quá trình phát triển.
  • 2. Trong quá trình phát triển, có thể có những thay đổi của môi trường bên ngoài làm ảnh hưởng đến yêu cầu đối với hệ thống.

Trong khuôn khổ của cách tiếp cận theo tầng, các yêu cầu đối với EIS được cố định dưới dạng điều khoản tham chiếu trong toàn bộ thời gian tạo và kết quả thu được chỉ được thống nhất với người dùng tại các điểm được lên kế hoạch sau khi hoàn thành từng giai đoạn ( có thể điều chỉnh kết quả theo góp ý của người sử dụng nếu không ảnh hưởng đến các yêu cầu đặt ra trong điều khoản tham chiếu). Do đó, người dùng chỉ có thể đưa ra nhận xét quan trọng sau khi hoàn thành công việc trên hệ thống. Nếu các yêu cầu không chính xác hoặc thay đổi trong một thời gian dài phát triển phần mềm, người dùng sẽ nhận được một hệ thống không đáp ứng nhu cầu của họ. Kết quả là bạn phải bắt đầu một dự án mới, dự án này có thể chịu chung số phận.

Để khắc phục những vấn đề này vào giữa những năm 80. một mô hình xoắn ốc của vòng đời đã được đề xuất (Hình 1.5). Tính năng cơ bản của nó là như sau: phần mềm ứng dụng không được tạo ngay lập tức, như trong trường hợp của cách tiếp cận thác nước, mà là từng phần bằng phương pháp tạo mẫu. Nguyên mẫu là một thành phần phần mềm hoạt động thực hiện các chức năng riêng lẻ và giao diện bên ngoài của phần mềm đang được phát triển. Việc tạo ra các nguyên mẫu được thực hiện trong một số lần lặp lại, hoặc các vòng xoắn ốc. Mỗi lần lặp tương ứng với việc tạo một đoạn hoặc phiên bản của phần mềm, tại đó các mục tiêu và đặc điểm của dự án được chỉ định, chất lượng của kết quả thu được được đánh giá và công việc của lần lặp tiếp theo được lên kế hoạch. Ở mỗi lần lặp lại, rủi ro vượt quá thời gian và chi phí của dự án được đánh giá cẩn thận để xác định xem có cần lặp lại lần nữa hay không, mức độ đầy đủ và chính xác trong việc hiểu các yêu cầu hệ thống và liệu có nên chấm dứt dự án hay không. Mô hình xoắn ốc giải phóng người dùng và nhà phát triển phần mềm khỏi nhu cầu xây dựng đầy đủ và chính xác các yêu cầu hệ thống ở giai đoạn ban đầu, vì chúng được tinh chỉnh ở mỗi lần lặp lại. Do đó, các chi tiết của dự án được đào sâu và cụ thể hóa một cách nhất quán, và kết quả là một phương án hợp lý được lựa chọn để đưa vào thực hiện.

Sự phát triển bằng cách lặp đi lặp lại phản ánh chu kỳ xoắn ốc tồn tại một cách khách quan của việc tạo ra hệ thống. Việc hoàn thành công việc chưa hoàn thành ở mỗi giai đoạn cho phép bạn chuyển sang giai đoạn tiếp theo mà không cần chờ hoàn thành công việc ở giai đoạn hiện tại. Với sự phát triển lặp đi lặp lại, công việc còn thiếu có thể được hoàn thành trong lần lặp lại tiếp theo. Nhiệm vụ chính là hiển thị cho người dùng hệ thống một sản phẩm khả thi càng sớm càng tốt, từ đó kích hoạt quá trình làm rõ và bổ sung các yêu cầu.

Mô hình xoắn ốc không loại trừ việc sử dụng cách tiếp cận thác nước ở giai đoạn cuối của dự án trong trường hợp các yêu cầu đối với hệ thống được xác định đầy đủ.

Vấn đề chính của chu kỳ xoắn ốc là xác định thời điểm chuyển sang giai đoạn tiếp theo. Để giải quyết nó, cần phải đưa ra các giới hạn thời gian cho từng giai đoạn của vòng đời. Quá trình chuyển đổi diễn ra theo kế hoạch, ngay cả khi không phải tất cả các công việc theo kế hoạch đều được hoàn thành. Kế hoạch được soạn thảo trên cơ sở dữ liệu thống kê thu được trong các dự án trước đó và kinh nghiệm cá nhân của các nhà phát triển.

Mô hình vòng đời được hiểu là một cấu trúc xác định trình tự thực hiện và mối quan hệ của các quy trình, hành động và nhiệm vụ được thực hiện trong vòng đời phần mềm.

Mô hình vòng đời phụ thuộc vào các chi tiết cụ thể của phần mềm và các chi tiết cụ thể của các điều kiện mà nó được tạo ra và vận hành.

Tiêu chuẩn ISO/IEC 12207 không cung cấp một mô hình vòng đời cụ thể và phương pháp phát triển phần mềm. Quy định của nó là chung cho bất kỳ người mẫu Vòng đời, phương pháp và công nghệ phát triển. Tiêu chuẩn ISO/IEC 12207 mô tả cấu trúc của các quy trình vòng đời phần mềm, nhưng không chỉ định chi tiết cách triển khai hoặc thực hiện các hoạt động và nhiệm vụ có trong các quy trình này.

Mô hình vòng đời của bất kỳ phần mềm cụ thể nào xác định bản chất của quá trình tạo ra nó.

Quy trình tạo ra phần mềm là một tập hợp các công việc được sắp xếp theo thứ tự thời gian, có mối liên hệ với nhau và được kết hợp thành các giai đoạn, việc thực hiện cần và đủ để tạo ra phần mềm đáp ứng các yêu cầu đã định.

Giai đoạn sáng tạo phần mềm được hiểu là một phần của quy trình phát triển phần mềm, bị giới hạn bởi một số khung thời gian và kết thúc bằng việc phát hành một sản phẩm cụ thể (mô hình phần mềm, thành phần phần mềm, tài liệu), được xác định bởi các yêu cầu được chỉ định cho giai đoạn này. Các giai đoạn phát triển phần mềm được phân biệt vì lý do lập kế hoạch hợp lý và tổ chức công việc, kết thúc với kết quả mong muốn.

Vòng đời phần mềm thường bao gồm các bước sau:

1) hình thành các yêu cầu đối với phần mềm;

2) thiết kế cấu trúc phần mềm;

3) thực hiện;

4) thử nghiệm;

5) chạy thử;

6) vận hành và bảo dưỡng;

7) ngừng hoạt động.

Nhiều quy trình được xác định trong 1SO/IEC 12207 có thể được thực thi ở mỗi giai đoạn và ngược lại, cùng một quy trình có thể được thực hiện ở các giai đoạn khác nhau.

hiện có người mẫu J C xác định trình tự thực hiện các bước trong quá trình phát triển và tiêu chí chuyển đổi từ giai đoạn này sang giai đoạn khác.

Cho đến nay, được sử dụng rộng rãi nhất ba mô hình vòng đời chính.

1)mô hình thác(1970-1980) liên quan đến việc chuyển sang giai đoạn tiếp theo sau khi hoàn thành công việc của giai đoạn trước.

2)Mô hình từng bước với kiểm soát trung gian (1980-1985) - mô hình phát triển phần mềm lặp đi lặp lại với các vòng phản hồi giữa các giai đoạn.

3)mô hình xoắn ốc(1986-1990) không nhấn mạnh vào các giai đoạn đầu tiên của vòng đời(phân tích yêu cầu, thiết kế đặc tả, thiết kế sơ bộ và chi tiết).

Các đặc điểm chính của phương pháp xếp tầng:

Chia nhỏ toàn bộ quá trình phát triển thành các giai đoạn;

Việc chuyển đổi từ giai đoạn này sang giai đoạn tiếp theo chỉ xảy ra sau khi hoàn thành toàn bộ công việc ở giai đoạn hiện tại (Hình 4.1);

Khả năng lập kế hoạch thời gian hoàn thành tất cả các công việc và chi phí tương ứng;

Kết quả của mỗi giai đoạn là các giải pháp kỹ thuật và một bộ tài liệu dự án hoàn chỉnh đáp ứng các tiêu chí về tính đầy đủ và thống nhất, đủ để nhóm phát triển khác tiếp tục phát triển;

Đầu tiên cho mỗi giai đoạn là các tài liệu và quyết định thu được ở giai đoạn trước.

Cách tiếp cận xếp tầng đã chứng tỏ bản thân rất tốt trong quá trình phát triển phần mềm đơn giản, khi mỗi chương trình là một tổng thể duy nhất. Khi xây dựng phần mềm như vậy ngay từ khi bắt đầu phát triển, có thể xây dựng tất cả các yêu cầu một cách chính xác và đầy đủ để cho phép các nhà phát triển tự do thực hiện chúng một cách tốt nhất có thể từ quan điểm kỹ thuật.

Cơm. 4.1. Mô hình phát triển phần mềm thác nước

Tuy nhiên, quá trình tạo phần mềm thực tế hầu như không bao giờ hoàn toàn không vừa trong một khuôn khổ cứng nhắc như vậy. Luôn có nhu cầu quay lại các giai đoạn trước đó và làm rõ hoặc sửa đổi các quyết định đã đưa ra trước đó.

Nhược điểm chính của cách tiếp cận theo tầng: các yêu cầu phần mềm bị "đóng băng" dưới dạng một nhiệm vụ kỹ thuật trong toàn bộ thời gian tạo ra nó. Người dùng chỉ có thể gửi ý kiến ​​​​của mình sau khi công việc trên phần mềm được hoàn thành đầy đủ.


Nếu các yêu cầu không chính xác hoặc thay đổi trong một thời gian dài phát triển phần mềm, người dùng sẽ nhận được một hệ thống không đáp ứng nhu cầu của họ. Các mô hình (cả chức năng và thông tin) của một đối tượng tự động có thể trở nên lỗi thời đồng thời với sự chấp thuận của chúng.

Do đó, mô hình tầng thực sự của việc tạo phần mềm có dạng như trong Hình. 4.2.

Cơm. 4.2. Mô hình với điều khiển trung gian

Trong mô hình điều khiển trung gian (một biến thể của mô hình thác nước), các điều chỉnh giữa các giai đoạn mang lại tính linh hoạt và độ tin cậy cao hơn mô hình thác nước, mặc dù chúng làm tăng toàn bộ thời gian tạo.

Để khắc phục những vấn đề này, một mô hình xoắn ốc của vòng đời đã được đề xuất (Hình 4.3), nhấn mạnh các giai đoạn ban đầu của vòng đời: phân tích yêu cầu, xác định đặc tả và thiết kế (sơ bộ và chi tiết).

Cơm. 4.3. Mô hình vòng đời xoắn ốc

Tại các giai đoạn này, tính khả thi của các giải pháp kỹ thuật được kiểm tra bằng các ứng dụng nguyên mẫuđược hiển thị cho khách hàng được thảo luận.

Nguyên mẫu thường được hiểu là một tập hợp các chương trình mô phỏng (mô tả, mô phỏng) hoạt động của một hệ thống đã hoàn thiện. Mục đích của việc tạo nguyên mẫu là hình dung rõ ràng hơn về hệ thống trong tương lai, dự đoán những thiếu sót của nó ở giai đoạn thiết kế, thực hiện các điều chỉnh cần thiết đối với các điều khoản tham chiếu và thiết kế kỹ thuật, nếu nó đã sẵn sàng. Thật tiện lợi khi trình diễn nguyên mẫu của hệ thống cho nhân viên của doanh nghiệp khách hàng để họ hiểu việc sử dụng hệ thống sẽ thuận tiện như thế nào đối với họ, những chức năng nào nên được thêm vào hoặc loại bỏ.

Mỗi vòng xoắn ốc tương ứng tạo một đoạn mã hoặc phiên bản QUA, các mục tiêu và đặc điểm của dự án được chỉ định trên đó, chất lượng của nó được xác định và công việc của vòng xoắn ốc tiếp theo được lên kế hoạch. Do đó, các chi tiết của dự án được đào sâu và cụ thể hóa một cách nhất quán.

Phát triển bằng cách lặp lại phản ánh chu kỳ phát triển phần mềm xoắn ốc hiện có một cách khách quan. Việc hoàn thành công việc chưa hoàn thành ở mỗi giai đoạn cho phép bạn chuyển sang giai đoạn tiếp theo mà không cần chờ hoàn thành công việc ở giai đoạn hiện tại. Với sự phát triển lặp đi lặp lại, công việc còn thiếu có thể được hoàn thành trong lần lặp lại tiếp theo.

nhiệm vụ chinh- hiển thị cho người dùng một sản phẩm khả thi càng sớm càng tốt, từ đó kích hoạt quá trình làm rõ và bổ sung các yêu cầu, sửa lỗi do sự không chắc chắn hoặc không chính xác của các nhiệm vụ kỹ thuật và thông số kỹ thuật của yêu cầu.

Mô hình xoắn ốc không loại trừ việc sử dụng cách tiếp cận thác nước ở giai đoạn cuối của dự án trong trường hợp các yêu cầu đối với hệ thống được xác định đầy đủ.

Chủ yếu vấn đề chu kỳ xoắn ốc — sự định nghĩa khoảnh khắc chuyển tiếp sang giai đoạn tiếp theo. Để giải quyết nó, cần phải đưa ra các giới hạn thời gian cho từng giai đoạn của vòng đời. Quá trình chuyển đổi diễn ra theo kế hoạch, ngay cả khi không phải tất cả các công việc theo kế hoạch đều được hoàn thành. Kế hoạch được soạn thảo trên cơ sở dữ liệu thống kê thu được trong các dự án trước đó và kinh nghiệm cá nhân của các nhà phát triển.

Những nhược điểm khác của mô hình xoắn ốc là:

Sự phức tạp của việc thực hiện các thay đổi;

Một lượng lớn tài liệu dự án gây khó khăn cho việc lập trình;

Khó khăn khi chuyển sang các nền tảng khác.

Do đó, với tất cả các ưu điểm của mô hình xoắn ốc, nếu có thể, vẫn nên "đảm bảo tiến trình tăng dần của quy trình phát triển phần mềm, không cần quay lại để tinh chỉnh hoặc làm lại các thành phần hoặc thậm chí toàn bộ gói phần mềm" - V.V. Lipaev.

Đặc điểm chính của ngành Phần mềm bao gồm ở mức độ phức tạp tập trung ở giai đoạn đầu của vòng đời- phân tích, xác định các thông số kỹ thuật và thiết kế, với độ phức tạp và cường độ lao động tương đối thấp của các giai đoạn tiếp theo. Hơn nữa, những vấn đề chưa được giải quyết và những sai lầm mắc phải ở giai đoạn đầu dẫn đến những vấn đề khó khăn, thường không thể giải quyết được trong các giai đoạn tiếp theo và cuối cùng dẫn đến sự thất bại của toàn bộ dự án.

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

Một trong những khái niệm cơ bản của phương pháp thiết kế IS là khái niệm về vòng đời phần mềm (LCS).

J C là một mô hình về các trạng thái khác nhau của một sản phẩm phần mềm, bắt đầu từ thời điểm phát sinh nhu cầu về sản phẩm phần mềm này và kết thúc vào thời điểm nó trở nên lỗi thời đối với tất cả người dùng.

Vòng đời của cơ sở dữ liệu chưa được quy định bởi các tiêu chuẩn - các tiêu chuẩn hiện có chỉ áp dụng cho vòng đời của các công cụ phần mềm.

Các tiêu chuẩn về vòng đời của PS có thể được sử dụng làm tài liệu chỉ đạo, hướng dẫn hoặc tư vấn.

Vòng đời hoàn chỉnh nhất, công nghệ để phát triển và đảm bảo chất lượng của PS được phản ánh trong các tiêu chuẩn ISO (Tổ chức Tiêu chuẩn Quốc tế - International Organization for Standardization). Tiêu chuẩn ISO 12207:1995 - "Quy trình Vòng đời Phần mềm" - phản ánh đầy đủ nhất kiến ​​trúc, công việc, tổ chức và quản lý vòng đời của PS.

Các mô hình vòng đời PS thực sự được sử dụng trong các công ty gần đây đã thay đổi so với các mô hình được đưa ra trong các tiêu chuẩn liên quan đến việc giới thiệu và phát triển các phương pháp và phân tích hướng đối tượng để phát triển nhanh các ứng dụng phần mềm, hệ thống CASE và ngôn ngữ thế hệ thứ tư. Trong các mô hình mới, công việc tạo trực tiếp các thành phần phần mềm được giảm bớt và công việc phân tích và thiết kế hệ thống của PS và DB được chi tiết hóa.

Nói chung, khi tạo các dự án PS và cung cấp vòng đời của chúng, bạn nên sử dụng lựa chọn từ toàn bộ bộ tiêu chuẩn đã đệ trình (cả quốc tế và quốc gia) và lấp đầy những khoảng trống hiện có trong tiêu chuẩn hóa bằng các tiêu chuẩn thực tế và quy định của bộ.

Hồ sơ là tập hợp một số tiêu chuẩn cơ bản và các văn bản quy định khác được thiết kế để thực hiện một chức năng hoặc một nhóm chức năng nhất định.

Dựa trên cùng một bộ tiêu chuẩn cơ bản, các hồ sơ khác nhau có thể được hình thành cho các dự án khác nhau.

Khi chứng nhận hệ thống thông tin, chứng nhận tuân thủ hồ sơ được phân biệt là một loại thử nghiệm đặc biệt. Và ở đây, cần lưu ý rằng trong tiêu chuẩn hóa quốc tế về IP, một cách giải thích chặt chẽ về khái niệm hồ sơ được thông qua - người ta tin rằng chỉ các tiêu chuẩn được quốc tế và quốc gia phê duyệt mới có thể là cơ sở của hồ sơ (nghĩa là việc sử dụng của các tiêu chuẩn thực tế và các tài liệu quy định của các công ty không được phép).

Dựa trên một hồ sơ cụ thể, nó được lên kế hoạch để viết tài liệu. Hơn nữa, đối với mỗi giai đoạn của vòng đời, tài liệu riêng của nó được viết, do đó, được chia thành các loại, tùy thuộc vào chuyên gia mà nó được tạo ra.



Vòng đời của phần mềm là một quá trình liên tục bắt đầu từ thời điểm quyết định về nhu cầu tạo ra phần mềm được đưa ra và kết thúc vào thời điểm phần mềm rút hoàn toàn khỏi hoạt động.

Văn bản quy định chính điều chỉnh vòng đời của phần mềm là tiêu chuẩn quốc tế ISO/IEC 12207 (ISO - International Organisation of Standardization - Tổ chức tiêu chuẩn hóa quốc tế, IEC - International Electrotechnical Commission - Ủy ban kỹ thuật điện quốc tế). Nó xác định cấu trúc vòng đời chứa các quy trình, hoạt động và nhiệm vụ phải được hoàn thành trong quá trình phát triển phần mềm.

Cấu trúc của vòng đời phần mềm theo tiêu chuẩn ISO/IEC 12207 dựa trên 3 nhóm quy trình:

· quy trình cơ bản Vòng đời phần mềm (mua, cung cấp, phát triển, vận hành, bảo trì);

· quy trình hỗ trợ, đảm bảo thực hiện các quy trình chính (tài liệu, quản lý cấu hình, đảm bảo chất lượng, kiểm định, chứng nhận, đánh giá, kiểm toán, giải quyết vấn đề);

· quy trình tổ chức(quản lý dự án, tạo cơ sở hạ tầng dự án, định nghĩa, đánh giá và cải thiện vòng đời của chính nó, đào tạo).

Phát triển bao gồm tất cả các công việc tạo ra phần mềm và các thành phần của nó theo các yêu cầu đã chỉ định, bao gồm chuẩn bị tài liệu thiết kế và vận hành, chuẩn bị tài liệu cần thiết để kiểm tra khả năng hoạt động và chất lượng phù hợp của sản phẩm phần mềm, tài liệu cần thiết để tổ chức đào tạo nhân sự, vân vân.

Phát triển phần mềm bao gồm, thường xuyên:

· Phân tích;

· thiết kế;

thực hiện (lập trình).

Giai đoạn phát triển bắt đầu với nghiên cứu khả thi của dự án, sau đó có sự chuyển đổi từ các yêu cầu của người dùng thành một dạng có sẵn để thực hiện trên máy tính.

Giai đoạn này thường chiếm 50% chi phí PI và 32% chi phí nhân công.

Khai thác bắt đầu từ khi sản phẩm được bàn giao cho người sử dụng, vận hành và sử dụng.

Bao gồm:

Đưa các thành phần phần mềm vào hoạt động, bao gồm cấu hình cơ sở dữ liệu và máy trạm của người dùng;

Cung cấp tài liệu vận hành;

Tiến hành đào tạo nhân viên, v.v., và vận hành trực tiếp, bao gồm cả việc khoanh vùng các vấn đề và loại bỏ nguyên nhân của chúng,

Sửa đổi phần mềm theo các quy định đã được thiết lập, chuẩn bị các đề xuất cải tiến, phát triển và hiện đại hóa hệ thống.

Giai đoạn bảo trì còn được gọi là giai đoạn phát triển đang diễn ra.

Bao gồm xác định và loại bỏ lỗi trong chương trình và thay đổi chức năng của chúng.

Các học viên nhận ra rằng phần này của vòng đời (LC) nên được tính đến ngay từ thời điểm phát triển để cải thiện giao diện người dùng phù hợp với nhu cầu của người dùng.

Quy trình bảo trì, sẽ tiếp tục song song với hoạt động của PI.

Cơ cấu chi phí lao động cho các loại hoạt động bảo trì khác nhau sao cho mất khoảng 78% thời gian để thay đổi chức năng của giao diện người dùng và 17% để xác định lỗi.

quản lý cấu hình là một trong những quy trình phụ trợ hỗ trợ các quy trình chính của vòng đời phần mềm, chủ yếu là các quy trình phát triển và bảo trì phần mềm. Khi tạo các dự án IS phức tạp bao gồm nhiều thành phần, mỗi thành phần có thể có nhiều loại hoặc phiên bản, vấn đề nảy sinh là tính đến các mối quan hệ và chức năng của chúng, tạo ra một cấu trúc thống nhất và đảm bảo sự phát triển của toàn bộ hệ thống. Quản lý cấu hình cho phép bạn tổ chức, xem xét một cách có hệ thống và kiểm soát các thay đổi đối với phần mềm ở tất cả các giai đoạn của vòng đời. Các nguyên tắc và đề xuất chung cho kế toán cấu hình, lập kế hoạch và quản lý cấu hình phần mềm được phản ánh trong dự thảo tiêu chuẩn ISO 12207-2.

Công trình đảm bảo chất lượng gắn liền với các bài toán thẩm tra, xác minh và kiểm thử phần mềm. xác minh là quá trình xác định xem hiện trạng phát triển đạt được ở một giai đoạn nhất định có đáp ứng được yêu cầu của giai đoạn đó hay không. Bài kiểm tra cho phép bạn đánh giá sự tuân thủ của các tham số phát triển với các yêu cầu ban đầu. Xác minh một phần trùng khớp với thử nghiệm, liên quan đến việc xác định sự khác biệt giữa kết quả thực tế và kết quả mong đợi cũng như đánh giá sự tuân thủ của các đặc điểm phần mềm với các yêu cầu ban đầu. Trong quá trình thực hiện dự án, các vấn đề về xác định, mô tả và kiểm soát cấu hình của các thành phần riêng lẻ và toàn bộ hệ thống nói chung chiếm một vị trí quan trọng.

Quản lý dự án liên quan đến các vấn đề về lập kế hoạch và tổ chức công việc, tạo nhóm các nhà phát triển và giám sát thời gian cũng như chất lượng công việc được thực hiện. Hỗ trợ kỹ thuật và tổ chức của dự án bao gồm lựa chọn phương pháp và công cụ để thực hiện dự án, định nghĩa phương pháp mô tả các trạng thái phát triển trung gian, phát triển phương pháp và công cụ để kiểm thử phần mềm, đào tạo nhân sự, v.v.

Mỗi quá trình được đặc trưng bởi:

một số nhiệm vụ và phương pháp cho giải pháp của họ,

dữ liệu ban đầu thu được ở giai đoạn trước,

kết quả.

Đặc biệt, kết quả phân tích là các mô hình chức năng, mô hình thông tin và các sơ đồ tương ứng của chúng. Phần mềm vòng đời hao mòn bản chất lặp đi lặp lại: kết quả của giai đoạn tiếp theo thường gây ra những thay đổi trong các quyết định thiết kế được phát triển ở giai đoạn trước.

Mô hình vòng đời phần mềm

Tiêu chuẩn ISO/IEC 12207 không đưa ra mô hình vòng đời và phương pháp phát triển phần mềm cụ thể. (Mô hình vòng đời phụ thuộc vào các chi tiết cụ thể của IS và các điều kiện cụ thể mà IS được tạo ra và vận hành). Các quy định của nó là chung cho bất kỳ mô hình vòng đời, phương pháp luận và công nghệ phát triển nào. Tiêu chuẩn ISO/IEC 12207 mô tả cấu trúc của các quy trình vòng đời phần mềm, nhưng không chỉ định chi tiết cách triển khai hoặc thực hiện hành động Và nhiệm vụ bao gồm trong các quá trình này.

Cho đến nay, hai mô hình vòng đời chính sau đây đã trở nên phổ biến nhất:

mẫu thác (năm 70-85);

· mô hình xoắn ốc (86-90).

Trong IS đồng nhất hiện có ban đầu, mỗi ứng dụng là một tổng thể duy nhất. Để phát triển loại ứng dụng này, chúng tôi đã sử dụng phương pháp xếp tầng. Đặc điểm chính của nó là sự phân chia toàn bộ quá trình phát triển thành các giai đoạn và quá trình chuyển đổi từ giai đoạn này sang giai đoạn tiếp theo chỉ xảy ra sau khi công việc trên giai đoạn hiện tại được hoàn thành đầy đủ (Hình 1). Mỗi giai đoạn lên đến đỉnh điểm trong việc phát hành một bộ tài liệu hoàn chỉnh, đủ để nhóm phát triển khác tiếp tục phát triển.

Các khía cạnh tích cực của việc áp dụng cách tiếp cận theo tầng như sau:

· ở mỗi giai đoạn, một bộ tài liệu dự án hoàn chỉnh được hình thành đáp ứng các tiêu chí về tính đầy đủ và nhất quán;

· các giai đoạn công việc được thực hiện theo trình tự hợp lý cho phép bạn lập kế hoạch thời gian hoàn thành tất cả công việc và chi phí tương ứng.


Cơm. 1. Sơ đồ phát triển phần mềm thác nước

Cách tiếp cận theo tầng đã được chứng minh trong việc xây dựng các IS mà ngay từ đầu quá trình phát triển, tất cả các yêu cầu có thể được xây dựng khá chính xác và đầy đủ để cho phép các nhà phát triển tự do triển khai chúng một cách tốt nhất có thể từ quan điểm kỹ thuật. Các hệ thống tính toán phức tạp, hệ thống thời gian thực và các nhiệm vụ tương tự khác thuộc loại này. Tuy nhiên, trong quá trình sử dụng phương pháp này, một số thiếu sót của nó đã được phát hiện, chủ yếu là do quy trình tạo phần mềm thực sự không bao giờ hoàn toàn phù hợp với một sơ đồ cứng nhắc như vậy:

· Xác định lý do tại sao bạn cần thay đổi dự án ở giai đoạn sau: Kiểm tra sức khỏe và tính khả thi của thiết kế ứng dụng trong giai đoạn đầu thường không được thực hiện.

· Quản lý rủi ro không đầy đủ: Các rủi ro liên quan đến dự án được xác định trong giai đoạn sau của dự án.

· Thiếu quy trình xem xét yêu cầu: trong mô hình này, các yêu cầu phải được hình thành và cố định trong giai đoạn phát triển ban đầu. Theo quy định, các mục tiêu và mục tiêu của dự án không được hiểu đầy đủ khi bắt đầu làm việc với dự án, và do đó chúng phải được sửa đổi trong các giai đoạn sau, dẫn đến sự gia tăng đáng kể chi phí phát triển và sự chậm trễ trong việc phát hành sản phẩm. Nếu các yêu cầu đã thay đổi không được tính đến trong dự án, khách hàng sẽ không coi ứng dụng là phù hợp với nhiệm vụ.


Cơm. 2 Quy trình thực sự của phát triển phần mềm theo sơ đồ thác nước

Vì vậy, nhược điểm chính của cách tiếp cận theo tầng là độ trễ đáng kể trong việc thu được kết quả. Việc phối hợp kết quả với người dùng chỉ được thực hiện tại các điểm được lên kế hoạch sau khi hoàn thành từng giai đoạn công việc, các yêu cầu đối với IS được "đóng băng" dưới dạng phân công kỹ thuật trong toàn bộ thời gian tạo ra nó. Do đó, người dùng chỉ có thể gửi nhận xét của mình sau khi công việc trên hệ thống được hoàn thành đầy đủ. Nếu các yêu cầu không chính xác hoặc thay đổi trong một thời gian dài phát triển phần mềm, người dùng sẽ nhận được một hệ thống không đáp ứng nhu cầu của họ. Các mô hình (cả chức năng và thông tin) của một đối tượng tự động có thể trở nên lỗi thời đồng thời với sự chấp thuận của chúng.

Do đó, trong quá trình tạo phần mềm, luôn có nhu cầu quay lại các giai đoạn trước đó và làm rõ hoặc sửa đổi các quyết định đã đưa ra trước đó. Do đó, quy trình tạo phần mềm thực sự có dạng sau (Hình 2):

Để khắc phục những vấn đề này, người ta đề xuất mô hình vòng đời xoắn ốc(Hình 3), tập trung vào các giai đoạn ban đầu của vòng đời: phân tích và thiết kế. Ở những giai đoạn này, tính khả thi của các giải pháp kỹ thuật được kiểm tra bằng cách tạo nguyên mẫu. Mỗi vòng xoắn ốc tương ứng với việc tạo ra một đoạn hoặc phiên bản của phần mềm. Nó làm rõ các mục tiêu và đặc điểm của dự án, xác định chất lượng của nó và lên kế hoạch cho công việc của vòng xoắn ốc tiếp theo. Do đó, các chi tiết của dự án được đào sâu và cụ thể hóa một cách nhất quán, và kết quả là một phương án hợp lý được lựa chọn để đưa vào thực hiện.

Sự phát triển bằng cách lặp đi lặp lại phản ánh chu kỳ xoắn ốc tồn tại một cách khách quan của việc tạo ra hệ thống. Việc hoàn thành công việc chưa hoàn thành ở mỗi giai đoạn cho phép bạn chuyển sang giai đoạn tiếp theo mà không cần chờ giai đoạn hiện tại hoàn thành. Với sự phát triển lặp đi lặp lại, công việc còn thiếu có thể được hoàn thành trong lần lặp lại tiếp theo. Nhiệm vụ chính là hiển thị cho người dùng hệ thống một sản phẩm khả thi càng sớm càng tốt, từ đó kích hoạt quá trình làm rõ và bổ sung các yêu cầu.

Vấn đề chính của chu kỳ xoắn ốc là xác định thời điểm chuyển sang giai đoạn tiếp theo. Để giải quyết nó, cần phải đưa ra các giới hạn thời gian cho từng giai đoạn của vòng đời. Quá trình chuyển đổi diễn ra theo kế hoạch, ngay cả khi không phải tất cả các công việc theo kế hoạch đều được hoàn thành. Kế hoạch được soạn thảo trên cơ sở dữ liệu thống kê thu được trong các dự án trước đó và kinh nghiệm cá nhân của các nhà phát triển.

Trong mô hình xoắn ốc của vòng đời, người ta nhấn mạnh vào các giai đoạn ban đầu của vòng đời: phân tích và thiết kế. Ở những giai đoạn này, tính khả thi của các giải pháp kỹ thuật được kiểm tra bằng cách tạo nguyên mẫu. Mỗi vòng xoắn ốc tương ứng với việc tạo ra một đoạn hoặc phiên bản phần mềm, trên đó các mục tiêu và đặc điểm của dự án được chỉ định, chất lượng của nó được xác định và công việc của vòng xoắn ốc tiếp theo được lên kế hoạch. Do đó, các chi tiết của dự án được đào sâu và cụ thể hóa một cách nhất quán, và kết quả là một phương án hợp lý được lựa chọn để đưa vào thực hiện.

Cơm. 3. Mô hình vòng đời xoắn ốc

Khi tạo phần mềm có thể sử dụng "Mô hình tái sử dụng và kỹ thuật đảo ngược".

Trong đó, trọng lượng chính của các quyết định thiết kế rơi vào thiết kế. Mục đích của mô hình này là tái sử dụng (tái sử dụng) trong các dự án hiện tại các giải pháp thiết kế "cũ" đã được chứng minh trong thực tế, được ghi lại trong thư viện của các dự án đã hoàn thành. Trong quá trình phân tích và thiết kế sơ bộ, các kế hoạch làm việc được vạch ra, trong đó bao gồm các nhiệm vụ kiểm tra các giải pháp thiết kế thay thế. Sau đó, công việc bắt đầu bằng việc tạo ra các nguyên mẫu theo kế hoạch trong sơ đồ xếp tầng. Kết quả là, một trong các giải pháp thay thế được chọn, được phát triển lặp lại song song cho phần còn lại của chu kỳ phát triển sản phẩm. Có thể chọn một biến thể hỗn hợp dựa trên việc kết hợp kết quả của một số lượt.

Trong trường hợp phiên bản đã triển khai bị lỗi, dự án có thể bị lùi lại (Tái cấu trúc).

Phát triển phần mềm là không thể nếu không hiểu cái gọi là vòng đời phần mềm. Một người dùng bình thường có thể không cần biết điều này, nhưng nên tìm hiểu các tiêu chuẩn cơ bản (tại sao điều này lại cần thiết sẽ được nói sau).

Vòng đời theo nghĩa chính thức là gì?

Theo vòng đời của bất kỳ ứng dụng nào, người ta thường hiểu thời gian tồn tại của nó, bắt đầu từ giai đoạn phát triển và cho đến thời điểm ngừng sử dụng hoàn toàn trong lĩnh vực ứng dụng đã chọn, cho đến khi loại bỏ hoàn toàn ứng dụng khỏi sử dụng.

Nói một cách đơn giản, các hệ thống thông tin dưới dạng chương trình, cơ sở dữ liệu hoặc thậm chí hệ điều hành chỉ được yêu cầu nếu dữ liệu và cơ hội mà chúng cung cấp là phù hợp.

Người ta tin rằng định nghĩa về vòng đời không áp dụng theo bất kỳ cách nào để thử nghiệm các ứng dụng, chẳng hạn như các phiên bản beta, hoạt động không ổn định nhất. Bản thân vòng đời của phần mềm phụ thuộc vào nhiều yếu tố, trong đó một trong những vai trò chính là do môi trường mà chương trình sẽ được sử dụng. Tuy nhiên, có thể chỉ ra các điều kiện chung được sử dụng để xác định khái niệm về vòng đời.

Yêu cầu ban đầu

  • xây dựng của vấn đề;
  • phân tích các yêu cầu lẫn nhau của phần mềm trong tương lai đối với hệ thống;
  • thiết kế;
  • lập trình;
  • mã hóa và biên dịch;
  • thử nghiệm;
  • gỡ lỗi;
  • triển khai và bảo trì sản phẩm phần mềm.

Phát triển phần mềm bao gồm tất cả các giai đoạn nêu trên và không thể thiếu ít nhất một trong số chúng. Nhưng để kiểm soát các quy trình như vậy, các tiêu chuẩn đặc biệt được thiết lập.

Tiêu chuẩn quy trình vòng đời phần mềm

Trong số các hệ thống xác định trước các điều kiện và yêu cầu cho các quy trình như vậy, ngày nay chỉ có thể kể tên ba hệ thống chính:

  • GOST 34.601-90;
  • ISO/IEC 12207:2008;
  • Oracle CDM.

Có một chất tương tự của Nga cho tiêu chuẩn quốc tế thứ hai. Đây là GOST R ISO / IEC 12207-2010, chịu trách nhiệm về hệ thống và kỹ thuật phần mềm. Nhưng vòng đời phần mềm được mô tả trong cả hai quy tắc về cơ bản là giống hệt nhau. Điều này được giải thích khá đơn giản.

Các loại phần mềm và cập nhật

Nhân tiện, đối với hầu hết các chương trình đa phương tiện hiện được biết đến, chúng là phương tiện lưu các tham số cấu hình chính. Tất nhiên, việc sử dụng loại phần mềm này khá hạn chế, nhưng việc hiểu các nguyên tắc chung để làm việc với cùng một trình phát phương tiện không có hại gì. Và đó là lý do tại sao.

Trên thực tế, chúng có vòng đời phần mềm chỉ ở cấp độ thời gian cập nhật cho phiên bản của chính trình phát hoặc cài đặt codec và bộ giải mã. Và bộ chuyển mã âm thanh và video là thuộc tính thiết yếu của bất kỳ hệ thống âm thanh hoặc video nào.

Ví dụ dựa trên FL Studio

Ban đầu, studio-sequencer ảo FL Studio được gọi là Fruity Loops. Vòng đời của phần mềm trong lần sửa đổi chính của nó đã hết hạn, nhưng ứng dụng đã được chuyển đổi phần nào và có được hình thức hiện tại.

Nếu chúng ta nói về các giai đoạn của vòng đời, thì lúc đầu, ở giai đoạn thiết lập nhiệm vụ, một số điều kiện bắt buộc đã được đặt ra:

  • tạo mô-đun trống tương tự như máy tạo nhịp điệu như Yamaha RX, nhưng sử dụng mẫu một lần hoặc chuỗi WAV được ghi trực tiếp trong phòng thu;
  • tích hợp vào hệ điều hành Windows;
  • khả năng xuất dự án ở định dạng WAV, MP3 và OGG;
  • khả năng tương thích của dự án với ứng dụng bổ sung Fruity Tracks.

Ở giai đoạn phát triển, các công cụ của ngôn ngữ lập trình C đã được sử dụng. Nhưng nền tảng này trông khá thô sơ và không cung cấp cho người dùng cuối chất lượng âm thanh cần thiết.

Về vấn đề này, ở giai đoạn thử nghiệm và sửa lỗi, các nhà phát triển đã phải đi theo con đường của tập đoàn Steinberg của Đức và áp dụng hỗ trợ chế độ Full Duplex trong các yêu cầu đối với trình điều khiển âm thanh chính. Chất lượng âm thanh đã trở nên cao hơn và cho phép bạn thay đổi nhịp độ, cao độ và áp dụng các hiệu ứng FX bổ sung trong thời gian thực.

Sự kết thúc vòng đời của phần mềm này được coi là việc phát hành phiên bản chính thức đầu tiên của FL Studio, không giống như tổ tiên của nó, đã có giao diện trình sắp xếp thứ tự chính thức với khả năng chỉnh sửa các tham số trên kênh 64 ảo bảng điều khiển trộn với việc bổ sung không giới hạn các rãnh âm thanh và rãnh MIDI.

Điều này không bị giới hạn. Ở giai đoạn quản lý dự án, hỗ trợ đã được giới thiệu để kết nối các trình cắm ở định dạng VST (đầu tiên là phiên bản thứ hai và sau đó là phiên bản thứ ba), từng được Steinberg phát triển. Nói một cách đại khái, bất kỳ bộ tổng hợp ảo nào hỗ trợ VST-host đều có thể kết nối với chương trình.

Không có gì đáng ngạc nhiên khi bất kỳ nhà soạn nhạc nào cũng có thể sớm sử dụng các chất tương tự của các mô hình "sắt", chẳng hạn như bộ âm thanh hoàn chỉnh của Korg M1 nổi tiếng một thời. Hơn nữa nhiều hơn nữa. Việc sử dụng các mô-đun như Addictive Drums hoặc plug-in Kontakt phổ biến giúp tái tạo âm thanh trực tiếp của các nhạc cụ thực được ghi lại với tất cả các sắc thái phát âm trong các phòng thu chuyên nghiệp.

Đồng thời, các nhà phát triển đã cố gắng đạt được chất lượng tối đa bằng cách tạo hỗ trợ cho trình điều khiển ASIO4ALL, điều này hóa ra lại vượt trội so với chế độ Song công hoàn toàn. Theo đó, tốc độ bit cũng tăng lên. Cho đến nay, chất lượng của tệp âm thanh được xuất có thể là 320 kbps với tốc độ lấy mẫu là 192 kHz. Đây là âm thanh chuyên nghiệp.

Đối với phiên bản ban đầu, vòng đời của nó có thể được gọi là hoàn thành, nhưng tuyên bố như vậy là tương đối, vì ứng dụng chỉ thay đổi tên và có thêm các tính năng mới.

Triển vọng phát triển

Các giai đoạn của vòng đời phần mềm là gì đã rõ ràng. Nhưng sự phát triển của các công nghệ như vậy đáng được đề cập riêng.

Không cần phải nói, bất kỳ nhà phát triển phần mềm nào cũng không quan tâm đến việc tạo ra một sản phẩm thoáng qua không có khả năng tồn tại trên thị trường trong một vài năm. Trong tương lai, mọi người đang nhìn vào việc sử dụng lâu dài của nó. Điều này có thể đạt được theo những cách khác nhau. Tuy nhiên, theo quy định, hầu hết tất cả đều bắt nguồn từ việc phát hành các bản cập nhật hoặc phiên bản mới của chương trình.

Ngay cả trong trường hợp của Windows, những xu hướng như vậy có thể được nhìn thấy bằng mắt thường. Không chắc rằng ngày nay sẽ có ít nhất một người dùng sử dụng các hệ thống như sửa đổi 3.1, 95, 98 hoặc Millennium. Vòng đời của chúng kết thúc sau khi phát hành phiên bản XP. Nhưng các phiên bản máy chủ dựa trên công nghệ NT vẫn có liên quan. Ngay cả Windows 2000 ngày nay không chỉ rất cập nhật mà thậm chí còn vượt qua những phát triển mới nhất trong một số thông số cài đặt hoặc bảo mật. Điều tương tự cũng áp dụng cho hệ thống NT 4.0, cũng như một sửa đổi chuyên biệt của Windows Server 2012.

Nhưng liên quan đến các hệ thống này, hỗ trợ vẫn được tuyên bố ở mức cao nhất. Nhưng Vista giật gân trong thời đại của nó rõ ràng đang trải qua sự suy giảm của chu kỳ. Nó không chỉ chưa hoàn thành mà còn có quá nhiều lỗi và lỗ hổng trong hệ thống bảo mật của nó khiến người ta chỉ có thể đoán làm thế nào một giải pháp không thể kiểm soát được như vậy lại có thể được tung ra thị trường phần mềm.

Nhưng nếu chúng ta nói về thực tế là sự phát triển của bất kỳ loại phần mềm nào (điều khiển hoặc ứng dụng) không đứng yên mà chỉ có thể xảy ra... Rốt cuộc, ngày nay nó không chỉ liên quan đến các hệ thống máy tính mà còn cả các thiết bị di động, trong đó các công nghệ được sử dụng thường đi trước lĩnh vực máy tính. Sự xuất hiện của chip xử lý dựa trên tám lõi - tại sao không phải là ví dụ điển hình nhất? Nhưng không phải máy tính xách tay nào cũng có thể tự hào về việc có phần cứng như vậy.

Một số câu hỏi bổ sung

Đối với việc hiểu về vòng đời của phần mềm, có thể nói rằng nó đã kết thúc vào một thời điểm cụ thể nào đó, điều đó rất có điều kiện, bởi vì các sản phẩm phần mềm vẫn có sự hỗ trợ từ các nhà phát triển đã tạo ra chúng. Thay vào đó, phần kết đề cập đến các ứng dụng cũ không đáp ứng các yêu cầu của hệ thống hiện đại và không thể hoạt động trong môi trường của chúng.

Nhưng ngay cả khi tính đến tiến bộ công nghệ, nhiều trong số chúng trong tương lai gần có thể trở nên không thể kiểm soát được. Đó là lúc bạn sẽ phải đưa ra quyết định phát hành các bản cập nhật hoặc sửa đổi hoàn toàn toàn bộ khái niệm ban đầu được tích hợp vào sản phẩm phần mềm. Do đó, chu kỳ mới, bao gồm việc thay đổi các điều kiện ban đầu, môi trường phát triển, thử nghiệm và ứng dụng lâu dài có thể có trong một khu vực nhất định.

Nhưng trong công nghệ máy tính ngày nay, người ta ưu tiên phát triển các hệ thống điều khiển tự động (ACS), được sử dụng trong sản xuất. Ngay cả hệ điều hành cũng thua so với các chương trình chuyên dụng.

Các môi trường dựa trên Visual Basic tương tự vẫn phổ biến hơn nhiều so với các hệ thống Windows. Và chúng ta hoàn toàn không nói về phần mềm ứng dụng cho hệ thống UNIX. Tôi có thể nói gì nếu hầu hết tất cả các mạng truyền thông của cùng một Hoa Kỳ đều hoạt động dành riêng cho họ. Nhân tiện, các hệ thống như Linux và Android ban đầu cũng được tạo trên nền tảng này. Do đó, rất có thể, UNIX có nhiều triển vọng hơn nhiều so với các sản phẩm khác cộng lại.

Thay vì tổng

Cần phải nói thêm rằng trong trường hợp này chỉ đưa ra các nguyên tắc chung và các giai đoạn của vòng đời phần mềm. Trên thực tế, ngay cả những nhiệm vụ ban đầu cũng có thể khác nhau rất nhiều. Theo đó, sự khác biệt có thể được quan sát thấy ở các giai đoạn khác.

Nhưng các công nghệ cơ bản để phát triển các sản phẩm phần mềm với việc bảo trì tiếp theo của chúng phải rõ ràng. Đối với phần còn lại, người ta nên tính đến các chi tiết cụ thể của phần mềm được tạo, môi trường mà nó được cho là hoạt động và khả năng của các chương trình được cung cấp cho người dùng cuối hoặc sản xuất, v.v.

Ngoài ra, đôi khi vòng đời có thể phụ thuộc vào mức độ phù hợp của các công cụ phát triển. Ví dụ, nếu một số ngôn ngữ lập trình trở nên lỗi thời, sẽ không có ai viết chương trình dựa trên nó, và thậm chí còn hơn thế - hãy triển khai chúng trong các hệ thống điều khiển tự động trong sản xuất. Ở đây, thậm chí không phải các lập trình viên, mà là các nhà tiếp thị, những người phải phản ứng kịp thời với những thay đổi của thị trường máy tính. Và không có nhiều chuyên gia như vậy trên thế giới. Nhân sự có trình độ cao có khả năng bám sát thị trường đang trở thành nhu cầu nhiều nhất. Và chính họ thường được gọi là "hồng y xám", mà sự thành công hay thất bại của một sản phẩm phần mềm nào đó trong lĩnh vực CNTT phụ thuộc vào đó.

Mặc dù không phải lúc nào họ cũng hiểu bản chất của lập trình, nhưng rõ ràng họ có thể xác định các mô hình vòng đời phần mềm và thời lượng sử dụng của chúng, dựa trên các xu hướng toàn cầu trong lĩnh vực này. Quản lý hiệu quả thường tạo ra nhiều kết quả hữu hình hơn. Có, ít nhất là các công nghệ PR, quảng cáo, v.v. Người dùng có thể không cần một số ứng dụng, nhưng nếu nó được quảng cáo tích cực, người dùng sẽ cài đặt nó. Có thể nói, đây đã là một cấp độ tiềm thức (tác động tương tự của khung hình thứ 25, khi thông tin được đưa vào tâm trí người dùng bất kể anh ta là ai).

Tất nhiên, những công nghệ như vậy bị cấm trên thế giới, nhưng nhiều người trong chúng ta thậm chí không nhận ra rằng chúng vẫn có thể được sử dụng và ảnh hưởng đến tiềm thức theo một cách nào đó. Việc “zombization” các kênh tin tức hoặc trang Internet có giá trị gì, chưa kể đến việc sử dụng các phương tiện mạnh mẽ hơn, chẳng hạn như tiếp xúc với sóng siêu âm (điều này đã được sử dụng trong một vở opera), do đó một người có thể cảm thấy sợ hãi hoặc cảm xúc không phù hợp.

Quay trở lại phần mềm, cần nói thêm rằng một số chương trình sử dụng tín hiệu âm thanh khi khởi động để thu hút sự chú ý của người dùng. Và các nghiên cứu cho thấy rằng các ứng dụng như vậy khả thi hơn các chương trình khác. Đương nhiên, vòng đời của phần mềm cũng tăng lên, bất kể ban đầu nó được gán cho chức năng gì. Và điều này, thật không may, được sử dụng bởi nhiều nhà phát triển, điều này làm dấy lên nghi ngờ về tính hợp pháp của các phương pháp đó.

Nhưng nó không phải là để chúng ta đánh giá điều này. Có thể trong tương lai gần các công cụ sẽ được phát triển để xác định các mối đe dọa như vậy. Cho đến nay, đây chỉ là lý thuyết, nhưng theo một số nhà phân tích và chuyên gia, còn rất ít trước khi áp dụng vào thực tế. Nếu họ đã tạo ra các bản sao của mạng lưới thần kinh của bộ não con người, thì tôi có thể nói gì đây?