Các mô hình cổ điển của quá trình phát triển phần mềm. Tổng quan về quy trình phát triển phần mềm

Quá trình phát triển phần mềm (quy trình phần mềm) là cấu trúc mà theo đó sự phát triển phần mềm được xây dựng.
Có một số mô hình của một quá trình như vậy (phương pháp luận phát triển phần mềm), mỗi mô hình mô tả cách tiếp cận riêng của nó, dưới dạng các nhiệm vụ và / hoặc hoạt động diễn ra trong quá trình.

Có các mô hình quy trình chính sau đây hoặc phương pháp luận phát triển phần mềm:

Phát triển xếp tầng hay mô hình thác nước - một mô hình của quá trình phát triển phần mềm, trong đó quá trình phát triển giống như một dòng chảy, tuần tự đi qua các giai đoạn phân tích yêu cầu, thiết kế, thực hiện, thử nghiệm, tích hợp và hỗ trợ. Một bài báo của W. W. Royce xuất bản năm 1970 thường được trích dẫn như là nguồn gốc của cái tên "thác nước"; buồn cười là bản thân Royce đã sử dụng một mô hình phát triển lặp đi lặp lại và thậm chí không sử dụng thuật ngữ "thác nước".
Phát triển lặp đi lặp lại(eng. iteration - sự lặp lại) - việc thực hiện công việc song song với việc phân tích liên tục các kết quả thu được và điều chỉnh các giai đoạn trước của công việc. Dự án với cách tiếp cận này trong mỗi giai đoạn phát triển sẽ trải qua một chu trình lặp lại: Lập kế hoạch - Thực hiện - Kiểm tra - Đánh giá (chu trình thực hiện kế hoạch - thực hiện - kiểm tra - hành động).
Trong quá trình phát triển, các yêu cầu bổ sung luôn được xác định hoặc các thay đổi đã được xác định trước đó. Ngoài ra, có những hạn chế mới liên quan đến các giải pháp kỹ thuật được thông qua. Trong quá trình phát triển lặp đi lặp lại, chúng có thể được xem xét đến mức tối đa, vì với cách tiếp cận này, ban quản lý dự án đã hoàn toàn sẵn sàng cho những thay đổi. Cách tiếp cận lặp lại hiện là phổ biến nhất do những ưu điểm rõ ràng của nó và các biến thể khác nhau của nó được sử dụng tại DPGroup.
Các phương pháp phát triển phần mềm lặp đi lặp lại được DPGroup sử dụng:
- Rational Unified Process(RUP) là một phương pháp luận phát triển phần mềm do Rational Software tạo ra.
  RUP dựa trên các nguyên tắc cơ bản sau:
  - Xác định sớm và liên tục (cho đến khi kết thúc dự án) loại bỏ các rủi ro chính.
  - Tập trung vào việc đáp ứng các yêu cầu của khách hàng đối với chương trình thực thi (phân tích và xây dựng mô hình tiền lệ).
  - Dự kiến những thay đổi về yêu cầu, quyết định thiết kế và triển khai trong quá trình phát triển.
  - Một kiến trúc thành phần được triển khai và thử nghiệm trong giai đoạn đầu của dự án.
  - Đảm bảo chất lượng liên tục ở tất cả các giai đoạn phát triển dự án (sản phẩm).
  - Làm việc trên dự án trong một nhóm gắn bó chặt chẽ, trong đó kiến trúc sư đóng vai trò chủ chốt.
- Phương pháp luận phát triển Agile(Anh. Phát triển phần mềm nhanh nhẹn).
  Hầu hết các phương pháp linh hoạt nhằm mục đích giảm thiểu rủi ro bằng cách giảm sự phát triển thành một chuỗi các chu kỳ ngắn được gọi là sự lặp lại thường kéo dài một đến hai tuần. Bản thân mỗi lần lặp lại trông giống như một dự án phần mềm thu nhỏ và bao gồm tất cả các nhiệm vụ cần thiết để tạo ra sự phát triển nhỏ về chức năng: lập kế hoạch, phân tích yêu cầu, thiết kế, mã hóa, thử nghiệm và tài liệu. Mặc dù một lần lặp lại nói chung là không đủ để phát hành phiên bản mới của sản phẩm, người ta cho rằng một dự án phần mềm nhanh đã sẵn sàng để phát hành vào cuối mỗi lần lặp. Vào cuối mỗi lần lặp lại, nhóm sẽ đánh giá lại các mức độ ưu tiên phát triển.
  Các phương pháp Agile nhấn mạnh vào giao tiếp mặt đối mặt. Hầu hết các đội nhanh nhẹn được đặt trong cùng một văn phòng, đôi khi được gọi là bullpen. Ở mức tối thiểu, nó cũng bao gồm "khách hàng" (khách hàng xác định sản phẩm, chẳng hạn như người quản lý sản phẩm, nhà phân tích kinh doanh hoặc khách hàng). Văn phòng cũng có thể bao gồm người kiểm tra, nhà thiết kế giao diện, người viết kỹ thuật và người quản lý. Một trong những phương pháp giải nhanh nổi tiếng và tiên tiến nhất là phương pháp luận.

Hơn 50 năm phát triển của kỹ thuật phần mềm, một số lượng lớn mô hình phát triển phần mềm. Thật thú vị khi rút ra một sự tương đồng giữa lịch sử phát triển của các phương pháp được sử dụng trong hệ thống điều khiển tự động cho máy bay và sự phát triển của các phương pháp tiếp cận để quản lý các dự án phần mềm.

"Chúng ta sẽ xem nó diễn ra như thế nào". Hệ thống điều khiển vòng hở. Hoàn toàn tin tưởng vào các nhà lãnh đạo kỹ thuật. Các đại diện doanh nghiệp thực tế không tham gia vào dự án. Lập kế hoạch, nếu nó tồn tại, là không chính thức và bằng lời nói. Thời gian và ngân sách nói chung không được kiểm soát. Tương tự: chuyến bay đạn đạo không có phản hồi. Nó có thể, nhưng gần và không chính xác.

"Thác nước" hoặc mô hình thác nước. Kiểm soát phản hồi cứng nhắc. Tính toán quỹ đạo tham chiếu (kế hoạch dự án), đo độ lệch, hiệu chỉnh và quay trở lại quỹ đạo tham chiếu. Tốt hơn, nhưng không hiệu quả.

"Quản lý linh hoạt". Tính toán quỹ đạo tham chiếu, đo độ lệch, tính toán quỹ đạo đến mới và hiệu chỉnh để đạt được quỹ đạo đó. "Kế hoạch không là gì cả, lập kế hoạch là tất cả" (Eisenhower, Dwight David)

"Phương pháp giao hàng thường xuyên". Homing. Tính toán quỹ đạo tham chiếu, đo độ lệch, đặc điểm kỹ thuật của mục tiêu, tính toán quỹ đạo đến mới và hiệu chỉnh để đạt được nó.

Các phương pháp điều khiển cổ điển ngừng hoạt động trong trường hợp chúng ta không biết cấu trúc và thuộc tính của đối tượng được quản lý và / hoặc thay đổi theo thời gian. Những cách tiếp cận này cũng sẽ không hữu ích nếu các thuộc tính hiện tại của đối tượng không cho phép nó di chuyển với các đặc tính cần thiết. Ví dụ, một chiếc máy bay không thể phát triển gia tốc cần thiết hoặc bị phá hủy do quá tải không thể chấp nhận được. Tương tự, nếu nhóm dự án không thể cung cấp hiệu quả cần thiết và do đó liên tục làm việc trong chế độ khẩn cấp, thì điều này không dẫn đến việc tăng năng suất mà là dẫn đến sự ra đi của các chuyên gia khỏi dự án.

Khi chúng ta không biết cấu trúc và thuộc tính của đối tượng được quản lý, chúng ta cần sử dụng Kiểm soát thích nghi, mà ngoài các hành động điều khiển trực tiếp còn nhằm nghiên cứu và thay đổi các thuộc tính của đối tượng bị điều khiển. Tiếp tục tương tự với điều khiển máy bay, đây là tính toán quỹ đạo tham chiếu, đo độ lệch, tinh chỉnh mục tiêu, tinh chỉnh đối tượng điều khiển, sự thích nghi (thay đổi cần thiết) của đối tượng điều khiển, tính toán một quỹ đạo rơi mới và sự điều chỉnh để đạt được nó.

Để hiểu cấu trúc và thuộc tính của một đối tượng và hành động trên nó nhằm đưa chúng đến trạng thái mong muốn, dự án phải có thêm một vòng phản hồi - vòng lặp thích ứng.

Được biết, hiệu suất của các lập trình viên khác nhau có thể chênh lệch hàng chục lần. Tôi khẳng định rằng hiệu suất của cùng một lập trình viên cũng có thể chênh lệch hàng chục lần. Bỏ người chạy giỏi nhất thế giới vào một cái bao tải và anh ta sẽ tệ hơn gấp 10 lần. Buộc lập trình viên giỏi nhất làm "lao động Sisyphean": tạo ra tài liệu (theo quy luật, không ai đọc) vì lợi ích của "Phương pháp luận" (cụ thể là với chữ M viết hoa), và năng suất của anh ta sẽ giảm 10 lần.

Vì vậy, bên cạnh những nhiệm vụ thuần túy quản lý, người lãnh đạo, nếu muốn đạt được năng suất cao nhất của nhóm làm việc, thì người lãnh đạo phải nỗ lực không ngừng để nghiên cứu và thay đổi đối tượng quản lý: con người và mối quan hệ tương tác giữa họ.

Mô hình(hoặc, như họ muốn nói, phương pháp luận) các quy trình phát triển phần mềm thường được phân loại theo "trọng số" - số lượng các quy trình được chính thức hóa (hầu hết các quy trình hoặc chỉ những quy trình chính) và chi tiết về quy định của chúng. Càng nhiều quy trình được lập thành văn bản, càng được mô tả chi tiết, thì “trọng lượng” của mô hình càng lớn.

Các mô hình hiện đại phổ biến nhất của quá trình phát triển phần mềm được trình bày trong hình. 2.3.

Cơm. 2.3. Các mô hình khác nhau của quá trình phát triển phần mềm

GOST

GOST 19 "Hệ thống thống nhất tài liệu phần mềm" và GOST 34 "Tiêu chuẩn phát triển và bảo trì hệ thống tự động" tập trung vào một cách tiếp cận nhất quán để phát triển phần mềm. Việc phát triển theo các tiêu chuẩn này được thực hiện theo từng giai đoạn, mỗi giai đoạn bao gồm việc thực hiện các công việc được xác định nghiêm ngặt, và kết thúc bằng việc phát hành một số lượng khá lớn các tài liệu được chính thức hóa và mở rộng. Do đó, việc tuân thủ nghiêm ngặt những vị khách này không chỉ dẫn đến cách tiếp cận thác nước, mà còn đòi hỏi mức độ chính thức hóa phát triển rất cao. Dựa trên các tiêu chuẩn này, các hệ thống phần mềm đang được phát triển cho các đơn đặt hàng của chính phủ ở Nga.

Vào giữa những năm 1980, Bộ Quốc phòng Hoa Kỳ đã suy nghĩ rất nhiều về cách chọn các nhà phát triển phần mềm cho các dự án phần mềm quy mô lớn. Được sự ủy quyền của quân đội, Viện Kỹ thuật Phần mềm, một phần của Đại học Carnegie Mellon, đã phát triển SW-CMM, Mô hình trưởng thành khả năng cho phần mềm, làm mô hình tham chiếu cho các tổ chức phát triển phần mềm.

Mô hình này xác định năm mức độ trưởng thành của quá trình phát triển phần mềm.

1) Ban đầu - quá trình phát triển là hỗn loạn. Rất ít quy trình được xác định, và sự thành công của các dự án phụ thuộc vào từng tác nhân.

2) Tính lặp lại - các quy trình quản lý dự án cơ bản được thiết lập: theo dõi chi phí, thời hạn và chức năng. Một số quy trình cần thiết để tái tạo những thành tựu trước đây trên các dự án tương tự đã được sắp xếp hợp lý.

3) Được xác định - các quy trình phát triển phần mềm và quản lý dự án được mô tả và thực hiện trong một hệ thống quy trình duy nhất của công ty. Tất cả các dự án đều sử dụng quy trình hỗ trợ và phát triển phần mềm tiêu chuẩn của tổ chức, phù hợp với dự án cụ thể.

4) Được quản lý - dữ liệu định lượng chi tiết được thu thập về hoạt động của các quá trình phát triển và chất lượng của sản phẩm cuối cùng. Ý nghĩa và động lực của những dữ liệu này được phân tích.

5) Có thể tối ưu hóa - cải tiến liên tục các quy trình dựa trên dữ liệu định lượng về các quy trình và việc triển khai thử nghiệm các ý tưởng và công nghệ mới.

Tài liệu đầy đủ của SW-CMM dài khoảng 500 trang và xác định một tập hợp 312 yêu cầu mà một tổ chức phải đáp ứng nếu tổ chức có kế hoạch đủ điều kiện cho tiêu chuẩn này ở cấp độ 5.

Quy trình Hợp nhất Rational (RUP) được phát triển bởi Philippe Kruchten, Ivar Jacobson và những người khác tại Rational Software như một sự bổ sung cho ngôn ngữ mô hình hóa UML. Mô hình RUP mô tả một quy trình chung trừu tượng mà từ đó tổ chức hoặc nhóm dự án sẽ tạo ra một quy trình cụ thể, chuyên biệt, tập trung vào các nhu cầu của tổ chức hoặc nhóm dự án. Chính đặc điểm này của RUP gây ra chỉ trích chính - vì nó có thể là bất cứ thứ gì, nên nó không thể được coi là bất cứ điều gì xác định. Kết quả của thiết kế chung này, RUP có thể được sử dụng vừa làm nền tảng cho sự phát triển kiểu thác nước truyền thống nhất, vừa là một quy trình nhanh.

Microsoft Solutions Framework (MSF) là một mô hình linh hoạt và khá nhẹ được xây dựng dựa trên sự phát triển lặp đi lặp lại. Một đặc điểm hấp dẫn của MSF là tập trung mạnh mẽ vào việc xây dựng một nhóm dự án hiệu quả và không quan liêu. Để đạt được mục tiêu này, MSF đưa ra các cách tiếp cận khá phi tiêu chuẩn đối với cơ cấu tổ chức, phân bổ trách nhiệm và các nguyên tắc tương tác trong nhóm.

Một trong những phát triển mới nhất của Viện Công nghệ Phần mềm Quy trình Phần mềm Cá nhân / Quy trình Phần mềm Nhóm. Quy trình Phần mềm Cá nhân xác định các yêu cầu về năng lực của nhà phát triển. Theo mô hình này, mọi lập trình viên sẽ có thể:

tính đến thời gian dành cho dự án;

tính đến các khuyết tật được tìm thấy;

phân loại các dạng khuyết tật;

ước tính quy mô của nhiệm vụ;

· Thực hiện một cách tiếp cận có hệ thống để mô tả các kết quả thử nghiệm;

kế hoạch chương trình nhiệm vụ;

Phân bổ chúng theo thời gian và lập một lịch trình làm việc.

thực hiện đánh giá thiết kế và kiến trúc cá nhân;

thực hiện kiểm tra mã cá nhân;

Thực hiện kiểm thử hồi quy.

Quy trình phần mềm nhóm dựa trên các nhóm tự quản lý gồm 3-20 nhà phát triển. Các đội phải:

đặt mục tiêu của riêng bạn;

· Lập quy trình và kế hoạch của riêng bạn;

theo dõi công việc;

Duy trì động lực và hiệu suất cao nhất.

Việc áp dụng nhất quán mô hình PSP / TSP cho phép bạn biến cấp độ thứ năm của CMM trở thành chuẩn mực trong tổ chức.

Ý tưởng chính đằng sau tất cả các mô hình nhanh nhẹn là quá trình phát triển phần mềm phải thích ứng. Họ tuyên bố rằng giá trị cao nhất của họ là tập trung vào con người và sự tương tác của họ, chứ không phải vào các quy trình và phương tiện. Trên thực tế, cái gọi là phương pháp nhanh không phải là phương pháp luận, mà là một tập hợp các phương pháp có thể (hoặc có thể không) cho phép phát triển phần mềm hiệu quả dựa trên lặp đi lặp lại, tăng dần, tự quản lý của nhóm và khả năng thích ứng của quy trình.

Lựa chọn mô hình quy trình

Các mô hình nặng và nhẹ của quá trình sản xuất có những ưu điểm và nhược điểm của chúng, được trình bày trong Bảng. 2.1.

Bảng 2.1

Ưu và nhược điểm của các mô hình quy trình phát triển phần mềm nặng và nhẹ

Trọng lượng mô hình	thuận	Số phút
Nặng	Các quy trình được thiết kế cho trình độ trung bình của những người thực hiện. Chuyên môn hóa tuyệt vời của người biểu diễn. Dưới đây là các yêu cầu về sự ổn định của nhóm. Không có hạn chế về khối lượng và độ phức tạp của các dự án đang thực hiện.	Yêu cầu chi phí quản lý đáng kể. Các giai đoạn phân tích và thiết kế dài hơn. Thông tin liên lạc chính thức hơn.
Phổi	Ít chi phí liên quan đến quản lý dự án, rủi ro, thay đổi, cấu hình. Đơn giản hóa các giai đoạn phân tích và thiết kế, tập trung chính vào sự phát triển của chức năng, sự kết hợp của các vai trò. thông tin liên lạc không chính thức.	Hiệu quả phụ thuộc nhiều vào khả năng của từng cá nhân, đòi hỏi một đội ngũ chất lượng, đa năng và ổn định hơn. Phạm vi và mức độ phức tạp của các dự án đang triển khai bị hạn chế.

Người ta tin rằng người da trắng đã giành quyền kiểm soát những mặt hàng này một cách không trung thực. Các nhà thờ chở hàng nổi tiếng nhất xây dựng các bản sao của đường băng, sân bay và tháp đài từ thân dừa và rơm. Các thành viên giáo phái xây dựng chúng với niềm tin rằng những cấu trúc này sẽ thu hút các máy bay vận tải (được coi là sứ giả của các linh hồn) chở đầy hàng hóa (hàng hóa). Các tín đồ thường xuyên tiến hành các cuộc diễn tập quân sự (“diễn tập”) và một số loại hành quân quân sự, sử dụng cành cây thay vì súng trường và vẽ trên thân lệnh và dòng chữ “USA”. Tất cả những điều này để máy bay có thể bay xuống từ bầu trời một lần nữa và sẽ có nhiều mặt hàng này hơn nữa.

Alistair Cowburn, một trong những tác giả của Tuyên ngôn Agile, đã phân tích các dự án phần mềm rất khác nhau đã được thực hiện trong các mô hình khác nhau từ hoàn toàn nhẹ và "nhanh nhẹn" đến nặng (CMM-5) trong 20 năm qua. Ông không tìm thấy mối tương quan nào giữa sự thành công hay thất bại của các dự án và các mô hình quy trình phát triển được sử dụng trong các dự án. Từ đó, ông kết luận rằng hiệu quả của việc phát triển phần mềm không phụ thuộc vào mô hình quy trình, và cả rằng:

Mỗi dự án nên có một mô hình quy trình phát triển riêng.

Mọi mô hình đều có thời gian của nó.

Điều này có nghĩa là không có quy trình phát triển phần mềm chính xác duy nhất, trong mỗi dự án mới, quy trình này phải được xác định lại mỗi lần, tùy thuộc vào dự án, sản phẩm và nhân sự, phù hợp với "Định luật 4 Ps" (Hình 2.4). Các quy trình hoàn toàn khác nên được áp dụng trong các dự án có 5 người và các dự án có 500 người. Nếu sản phẩm của dự án là phần mềm quan trọng, chẳng hạn như hệ thống điều khiển nhà máy điện hạt nhân, thì quá trình phát triển sẽ rất khác với quá trình phát triển, ví dụ, trang web “otdokhni.ru”. Và, cuối cùng, quá trình phát triển nên được tổ chức khác nhau trong một nhóm sinh viên của ngày hôm qua và trong một nhóm các chuyên gia có thành tích.

Nhóm bắt đầu dự án không thay đổi, họ trải qua một số giai đoạn hình thành nhất định và theo quy luật, phát triển về mặt số lượng khi dự án phát triển. Do đó, quá trình phải liên tục thích ứng với những thay đổi này. Nguyên tắc chính: không nên xây dựng con người theo mô hình quy trình đã chọn, mà mô hình quy trình nên được điều chỉnh cho một nhóm cụ thể để đảm bảo hiệu quả cao nhất.

Cơm. 2.4. "Luật 4 chữ Ps". Quy trình trong dự án nên được xác định tùy thuộc vào dự án, sản phẩm và nhân sự

Trước khi đưa ra một cái nhìn tổng quan về quá trình phát triển đã phát triển là kết quả của việc tích lũy kinh nghiệm trong những năm qua, tôi muốn đưa ra một vài giải thích chung mà đối với tôi có vẻ rất cần thiết.

Tôi đã làm việc trong lĩnh vực CNTT trong 15 năm qua, mặc dù tôi đã bắt đầu lập trình sớm hơn nhiều. Trọng tâm chính của tôi với tư cách là kiến trúc sư hệ thống là tổ chức phát triển phần mềm, phát triển các khái niệm và kiến trúc cấp cao, đồng thời giám sát việc thực hiện khái niệm trong suốt dự án. Ngoài việc quản lý phát triển phần mềm và tạo kiến trúc, thỉnh thoảng tôi giải quyết các vấn đề kỹ thuật phức tạp và viết một số đoạn mã quan trọng đòi hỏi không chỉ kiến thức về bản thân ngôn ngữ và môi trường phát triển, mà còn cả tổ chức nội bộ của chúng, đôi khi mang lại cảm giác khó chịu những điều bất ngờ.

Các dự án tôi làm thường liên quan đến việc phát triển phần mềm tùy chỉnh hoặc đầu tư. Tôi cũng đã phải làm việc với phần mềm nhúng và các chương trình tập trung vào việc phát hành các "hit" (với bàn tay nhẹ nhàng của Joel Spolsky, tôi gọi sau đây là phần mềm chơi game, mặc dù trên thực tế, một số dự án chơi game gần với các dự án đầu tư hơn).

Phần mềm tùy chỉnh có thể dành cho khách hàng nội bộ hoặc bên ngoài. Khách hàng nhận được độc quyền đối với hệ thống đã phát triển và công việc phát triển hệ thống có thể được chuyển giao cho một nhà thầu khác trong tương lai.

Không giống như phần mềm tùy chỉnh, công việc trên phần mềm đầu tư được thực hiện bởi chính nhà thầu với tiền của một nhà đầu tư bên trong hoặc bên ngoài. Theo quy định, các quyền đối với mã hệ thống vẫn thuộc về nhà phát triển, điều này kích thích công việc liên tục để cải thiện sản phẩm của họ và phát hành nhất quán các phiên bản có chức năng nâng cao hơn.

Phần mềm cơ sở đi kèm với phần cứng và nói một cách đại khái là không thể sửa chữa được, vì việc thu hồi một loạt thiết bị của nhà sản xuất là rất tốn kém và do đó rất đặc biệt.

Sự phát triển của các trò chơi hit trên thực tế cũng không có giai đoạn đi kèm. Ngoài ra, người dùng các chương trình chơi game, ngay cả khi gặp lỗi trong trò chơi, rất hiếm khi tải xuống phiên bản cập nhật. Vì vậy, trò chơi phát triển, như một quy luật, có nền kinh tế riêng và quá trình phát triển riêng của nó.

Khách hàng của chúng tôi là các cơ quan chức năng, các tổ chức thương mại và nhà nước lớn và tất nhiên là chính chúng tôi. Do đó, về phần mềm tùy chỉnh, thường có một số khác biệt trong quy trình của chúng tôi giữa việc phát triển sản phẩm cho khách hàng nội bộ và bên ngoài. Tôi sẽ chỉ ra một số sắc thái trong bài viết này. Mức độ chính thức hóa quan hệ với khách hàng rất khác nhau giữa các dự án. Nhìn chung, ngân sách dự án càng lớn thì tính hình thức càng cao. Khách hàng nhà nước hoặc các doanh nghiệp thương mại lớn (đặc biệt là có sự tham gia của nhà nước) thường có những hạn chế về mặt pháp lý đối với việc hình thành, đặt hàng và chấp nhận kết quả công việc. Một hạn chế khác của các tổ chức lớn là thực tế là nhân viên của họ, những người cung cấp các yêu cầu và là người sử dụng chính của hệ thống của chúng tôi, có rất ít khả năng sẵn sàng cho những người thực hiện, nếu chỉ vì sự bận rộn của họ. Tuy nhiên, đối với các tổ chức nhỏ, mức độ chính thức hóa giảm xuống và đôi khi đi đến thái cực ngược lại, nơi không có đủ mức độ trách nhiệm của khách hàng trong dự án.

Mặt khác của các dự án tùy chỉnh của chúng tôi là yêu cầu cao về chức năng. Đây là mức tải cao trên tất cả các hệ thống, và phân bố địa lý lớn, và yêu cầu cao về độ chính xác của các phép tính với khung thời gian rất hạn chế. Thông thường trong các dự án của chúng tôi có các yếu tố của công việc nghiên cứu và tìm kiếm sáng tạo nhằm giải quyết các vấn đề thiết kế không tầm thường. Đôi khi chúng ta phải kết hợp các phương pháp luận khác nhau trong cùng một quá trình phát triển, chẳng hạn như bằng cách chèn một hoặc nhiều giai đoạn của scrum gần như thuần túy vào quy trình tổng thể, gần với RUP, tạo ra một cái gì đó giống như một dự án trong một dự án. Điều này cho phép chúng tôi duy trì mức độ tương tác của người dùng thấp do bản chất của dự án, với sự linh hoạt trong phát triển khi đối mặt với sự không chắc chắn của các yêu cầu cao. Về vấn đề này, đó là giai đoạn chuẩn bị quan trọng đối với tôi, trong đó bạn có thể chọn phương pháp luận cần thiết và xây dựng một quy trình phát triển tối ưu. Tôi đã mô tả một trong những ví dụ về việc sử dụng phương pháp nhanh trong bài báo “Ứng dụng nhanh khi phát triển dự án cho khách hàng chính phủ”.

Như một ví dụ về việc làm trong một dự án đầu tư, tôi có thể trích dẫn sự phát triển của một hệ thống bảo mật tích hợp mà chúng tôi đã tạo ra như một sản phẩm “đóng hộp”. Dưới sự lãnh đạo của tôi, bốn phiên bản của hệ thống này đã được phát hành liên tiếp, đối tượng sử dụng là nhiều tổ chức thương mại và chính phủ, bao gồm Tòa thị chính Moscow, AFK Sistema, ngân hàng, trung tâm thương mại và tất nhiên, văn phòng của chính chúng tôi. Phiên bản đầu tiên không thành công lắm, nhưng chúng tôi đã có một chiến lược phát triển cho phép chúng tôi nắm bắt thành công thị trường và tồn tại trong thời kỳ khó khăn của cuộc khủng hoảng. Kinh nghiệm làm việc về vấn đề này và một số dự án đầu tư khác cũng được tính đến khi định hình quy trình phát triển mà tôi sử dụng.

Quy trình của chúng tôi là một chuỗi các giai đoạn nhất định. Việc phân loại phần mềm do tôi đưa ra chỉ để cho thấy sự khác biệt có thể có trong việc tổ chức phát triển các công cụ phần mềm khác nhau. Khi tìm hiểu tổng quan về quy trình phát triển, tôi sẽ chỉ tập trung vào những điểm khác biệt trong chính quy trình liên quan đến các loại phần mềm khác nhau. Tuy nhiên, chúng ta phải nhớ rằng sự khác biệt giữa các quy trình phát triển của các loại phần mềm khác nhau sâu sắc hơn nhiều, vì vậy khi lập kế hoạch cho từng giai đoạn, các sắc thái này phải được tính đến.

Điều quan trọng là phải hiểu rằng sự chuyển đổi của quá trình từ giai đoạn này sang giai đoạn khác không có một ranh giới rõ ràng. Theo quy định, công việc của giai đoạn tiếp theo bắt đầu khi 80-90% công việc của giai đoạn trước được hoàn thành. Điều này đặc biệt đúng đối với sự phát triển của các yêu cầu, khi trong một số trường hợp, việc loại bỏ sự không chắc chắn chỉ xảy ra khi kết thúc dự án. Tất nhiên, sự hiện diện của sự không chắc chắn như vậy trong dự án là một rủi ro đáng kể và cần được kiểm soát liên tục.

Quy trình phát triển phần mềm tùy chỉnh

Hãy bắt đầu xem xét quá trình phát triển với trường hợp phổ biến nhất - sự phát triển của phần mềm tùy chỉnh. Sơ đồ quy trình được thể hiện trong Hình 1.

Hình 1. Quy trình phát triển phần mềm tùy chỉnh.

Công việc của dự án bắt đầu với giai đoạn chuẩn bị. Mục đích của giai đoạn này là tạo ra một khái niệm về hệ thống tương lai dựa trên đề xuất của khách hàng và dựa trên khái niệm này để đánh giá mức độ phù hợp và tính khả thi của dự án. Nếu quyết định thu hút nhà thầu được khách hàng đưa ra trên cơ sở cạnh tranh, thì giai đoạn sơ bộ thực sự là giai đoạn chuẩn bị một nhà thầu tiềm năng cho cuộc đấu thầu, bao gồm cả việc hình thành các tài liệu cần thiết.

Không cần lãng phí thời gian và nguồn lực vào một dự án mà khái niệm của nó được công nhận là vô thừa nhận hoặc không thể kiểm chứng. Dự án này phải được hoàn thành. Trong một số trường hợp, một số công việc lặp đi lặp lại với khách hàng được yêu cầu để điều chỉnh khái niệm của dự án, cho đến khi đạt được sự cân bằng có thể chấp nhận được giữa yêu cầu của khách hàng và chi phí nhà thầu hoặc quyết định cắt giảm công việc.

Một dự án có khái niệm có thể chấp nhận được để thực hiện sẽ bước vào giai đoạn phát triển các yêu cầu. Ở giai đoạn này, nhà thầu phải hình thành một danh sách tất cả các nhu cầu rõ ràng và tiềm ẩn của khách hàng. Nó thường chỉ ra rằng khách hàng hoặc đã không quyết định về nhu cầu của mình, hoặc nhu cầu của họ mâu thuẫn với nhau, với khả năng của khách hàng hoặc với khả năng của nhà thầu. Mục tiêu của giai đoạn là xác định tất cả các nhu cầu tiềm ẩn, giải quyết các xung đột của các yêu cầu, hình thành một giải pháp kỹ thuật tổng thể và phân tích tính khả thi của giải pháp đã chuẩn bị.

Đôi khi việc làm rõ các yêu cầu dẫn đến việc sửa đổi khái niệm dự án. Nếu sau khi làm rõ tất cả các yêu cầu mà không thể tìm được giải pháp kỹ thuật có thể chấp nhận được, thì dự án sẽ phải tạm dừng hoặc hoãn lại một thời gian để đề phòng những trường hợp có thể chấp nhận được.

Nếu một giải pháp kỹ thuật được tìm thấy, người biểu diễn sẽ tiến hành phát triển kiến trúc của hệ thống trong tương lai. Mục đích của giai đoạn này là xác định kiến trúc logic và vật lý cấp cao nhất bao gồm đầy đủ tất cả các yêu cầu của khách hàng. Khi phát triển kiến trúc, khái niệm, yêu cầu và giải pháp kỹ thuật sơ bộ được xem xét và hoàn thiện để có thể ngăn ngừa những rủi ro nguy hiểm nhất.

Sau khi hoàn thành thiết kế kiến trúc, cần phải điều chỉnh lại các thông số chính của công trình và quyết định xem nhà thầu có đủ khả năng hoàn thành công trình hay không. Sẽ rất hữu ích ở giai đoạn phát triển kiến trúc nếu từ bỏ những chức năng không cần thiết và quá rườm rà. Việc tối ưu hóa giải pháp kiến trúc thường giúp phù hợp với các thông số chấp nhận được của dự án. Trong các trường hợp khác, cần phải giảm triệt để chức năng của hệ thống đang được phát triển. Tuy nhiên, ngay cả việc dừng dự án ở giai đoạn này, nếu nó xảy ra vì lý do chính đáng, nên được coi là một chiến thắng: việc tiếp tục công việc trong trường hợp này chỉ có thể dẫn đến tổn thất thậm chí còn lớn hơn.

Nếu tìm thấy sự cân bằng và một kiến trúc hệ thống có thể chấp nhận được đã được tạo ra, nhà thầu có thể chuyển sang việc triển khai và cung cấp hệ thống. Việc thực hiện có thể diễn ra trong một hoặc nhiều giai đoạn. Đối với các dự án nhỏ, việc phân phối một giai đoạn tất cả các chức năng của hệ thống có thể khá chấp nhận được. Tuy nhiên, dự án càng lớn thì mức độ phụ thuộc của các hệ thống con trong hệ thống được tạo ra càng cao. Trong những điều kiện này, việc thực hiện nên được chia thành nhiều giai đoạn để cuối mỗi giai đoạn, nhóm phát triển có một sản phẩm sẵn sàng để giao. Đồng thời, chức năng cơ bản, quan trọng nhất nên được phát triển ở giai đoạn đầu và các tiện ích bổ sung hoạt động trên các thành phần cốt lõi này sẽ được triển khai sau đó. Trong trường hợp này, các lỗi nguy hiểm nhất đối với hệ thống sẽ được sửa chữa trong giai đoạn đầu tiên và nguy cơ chức năng ứng dụng của hệ thống dựa trên cơ sở không ổn định sẽ giảm đáng kể.
Sau khi cung cấp một hệ thống hoàn chỉnh đầy đủ, một dự án phần mềm tùy chỉnh thường chuyển sang giai đoạn beta. Mục đích của giai đoạn này là kiểm tra chất lượng của hệ thống đã phát triển trong điều kiện hoạt động thực tế. Theo quy luật, ở giai đoạn này, người thực hiện cùng với khách hàng đo lường các chỉ số định lượng để có thể xác định chất lượng của hệ thống được tạo ra. Trước hết, các đặc tính chức năng của chất lượng được kiểm tra, sau đó là các đặc tính phi chức năng. Nếu có sự khác biệt, người biểu diễn sẽ sửa lại mã hệ thống.

Hệ thống đã gỡ lỗi và điều chỉnh hoàn toàn được đưa vào vận hành thương mại. Theo quy định, nhà thầu phải đồng hành cùng hệ thống, ít nhất là trong thời gian bảo hành. Những mâu thuẫn đã xác định cần được sửa chữa. Người dùng và nhân viên dịch vụ khách hàng sẽ nhận được hỗ trợ tư vấn nhanh chóng.

Cuối cùng, thời điểm đến khi hệ thống ngừng hoạt động phù hợp với khách hàng vì bất kỳ lý do gì. Hệ thống hiện đang trong quá trình ngừng hoạt động. Tuy nhiên, đối với phần mềm tùy chỉnh, giai đoạn này không phải lúc nào cũng phù hợp, vì khách hàng có thể sử dụng độc quyền của mình đối với hệ thống và loại bỏ nhà thầu khỏi việc bảo trì và phát triển hệ thống ngay cả trước khi nó trở nên không liên quan.

Bất kỳ dự án nào cuối cùng cũng đi đến hồi kết. Giai đoạn kết thúc dự án nhằm mục đích phân tích kết quả, thực hiện các thay đổi đối với quy trình phát triển dựa trên kinh nghiệm thu được và bổ sung cơ sở kiến thức cho nhà phát triển bằng các giải pháp và lưu ý hiệu quả mới, cũng như các thành phần mới có sẵn có thể được sử dụng trong các dự án tương lai.

Cần lưu ý thêm hai giai đoạn của quá trình phát triển. Nó xảy ra khi hoàn cảnh không cho phép tiếp tục thực hiện dự án, nhưng kết quả của công việc đã thực hiện cho thấy dự án có thể có tương lai. Còn quá sớm để đóng một dự án như vậy. Do đó, thay vì ngừng hoàn toàn công việc, nhà thầu có thể tạm dừng các hoạt động của dự án, ấn định kết quả đã đạt được. Ngay khi hoàn cảnh cho phép, dự án có thể được tiếp tục bằng cách cải tạo lại cơ sở hạ tầng, đưa các nhà phát triển trở lại dự án và khôi phục trạng thái của dự án. Tuy nhiên, điều quan trọng là phải tiếp tục công việc kể từ thời điểm dự án bị gián đoạn bằng cách đánh giá lại các kết quả đạt được.

Quy trình đầu tư phát triển phần mềm

Quá trình phát triển phần mềm đầu tư khác ở chỗ công việc có thể được thực hiện đồng thời trên nhiều phiên bản của sản phẩm cùng một lúc: trong khi phiên bản đầu tiên đang được duy trì, phiên bản thứ hai đã được triển khai và các yêu cầu đang được xây dựng cho phiên bản thứ ba. Quá trình này được thể hiện trong Hình 2.

Hình 2. Quy trình đầu tư phát triển phần mềm.

Có thể dễ dàng nhận thấy, trong quá trình phát triển phần mềm đầu tư, các giai đoạn tương tự diễn ra đã được thảo luận ở trên đối với quá trình phát triển phần mềm tùy chỉnh. Nhưng sự khác biệt là các công đoạn không áp dụng cho toàn bộ sản phẩm mà áp dụng cho một phiên bản riêng biệt của sản phẩm. Ngoại lệ là giai đoạn kết thúc dự án: dự án không thể hoàn thành trong khi có ít nhất một phiên bản của sản phẩm đang được thực hiện.

Hãy chú ý đến việc bắt đầu công việc trên phiên bản tiếp theo của sản phẩm. Thời điểm này đến ngay sau khi giai đoạn tạo kiến trúc của phiên bản phát triển hiện tại đã hoàn thành. Trước đó, các yêu cầu và giai đoạn kiến trúc thường thảo luận về tính năng nào nên được triển khai trong phiên bản hiện tại và tính năng nào sẽ được chuyển sang tương lai. Và chỉ khi các yêu cầu đối với phiên bản hiện tại được kiến trúc hệ thống xây dựng, xem xét và xác nhận, thì việc suy nghĩ về phiên bản tiếp theo mới có ý nghĩa.

Ngoài ra, sau khi phát triển kiến trúc, theo quy luật, các nhà phân tích và kiến trúc sư của dự án có một số quyền tự do hành động, vì gánh nặng chính thuộc về các lập trình viên trong các giai đoạn phân phối. Sự tự do này có thể được sử dụng để tìm ra khái niệm và yêu cầu cho phiên bản tiếp theo.

Về nguyên tắc, bạn có thể hoãn việc bắt đầu công việc của phiên bản tiếp theo sang một ngày sau đó. Ví dụ: việc đầu tiên đưa phiên bản hiện tại vào hoạt động thử nghiệm hoặc thậm chí thương mại là điều hoàn toàn có thể chấp nhận được và chỉ sau đó bắt đầu công việc trên phiên bản tiếp theo. Nhưng bạn cần nhớ rằng giải pháp như vậy không thể áp dụng trong trường hợp cạnh tranh cao: đơn giản là họ sẽ đi trước bạn và ép bạn ra khỏi thị trường. Quyết định phải được đưa ra dựa trên đầy đủ các trường hợp ảnh hưởng đến hoạt động kinh doanh của bạn.

Nói về quy trình phát triển phần mềm đầu tư, bạn cần hiểu rằng làm việc trên nhiều phiên bản có một số mối quan hệ phụ thuộc lẫn nhau rõ ràng và ẩn giữa các nhánh song song của quy trình.

Trước tiên, các bản sửa lỗi cho các mâu thuẫn được xác định trong phiên bản trước đó phải được thực hiện cho phiên bản mà chúng được phát hiện và tất cả các phiên bản sau đó, bao gồm cả những phiên bản đang được phát triển. Điều này không chỉ áp dụng cho mã chương trình, mà còn cho tất cả các thành phần khác của dự án: tài liệu kỹ thuật và người dùng, hệ thống trợ giúp, ước tính và kế hoạch làm việc, v.v. Hơn nữa, việc sửa chữa nên được thực hiện ngay lập tức, vì bạn sẽ không thể giảm chi phí sửa chữa, nhưng nếu không sửa chữa ngay lập tức, chi phí của chúng ở giai đoạn sau có thể tăng lên hàng chục, thậm chí hàng trăm lần.

Thứ hai, để làm việc song song trên một số phiên bản, cần có cơ sở hạ tầng dự án đặc biệt, bao gồm tổ chức kiểm soát phiên bản mã và tài liệu, kiểm soát công việc và sự không nhất quán, các tiện ích xây dựng và kiểm tra tự động, v.v. Làm việc trên một phiên bản của sản phẩm không được phép chặn việc thực thi các tác vụ trên các phiên bản khác chỉ vì cơ sở hạ tầng dự án không cho phép chạy hai quy trình xây dựng cùng một lúc cho các phiên bản khác nhau của sản phẩm.

Cần đặc biệt chú ý đến các băng ghế thử nghiệm: họ nên triển khai tất cả các phiên bản của sản phẩm đã được phát hành trước đó (ít nhất là những phiên bản được hỗ trợ) và tất cả các phiên bản hiện đang được phát triển.

Thứ ba, những người tham gia giống nhau có thể tham gia vào công việc trên nhiều phiên bản cùng một lúc. Có một nguy cơ cao là một người chủ chốt có thể sa lầy vào việc làm việc trên một phiên bản của chương trình và để dành thời gian đáng kể cho các nhiệm vụ liên quan đến phiên bản khác.

Thứ tư, có một tình huống ngược lại, khi nhân viên làm việc trên một phiên bản không biết gì về những quyết định được đưa ra như một phần của công việc trên phiên bản kia. Một phần của vấn đề sẽ được gỡ bỏ nếu các sửa chữa đối với tất cả tài liệu và mã được phân phối ngay lập tức cho tất cả các phiên bản sau, như tôi đã đề cập ở trên. Nhưng vấn đề không nên chỉ giới hạn trong việc sửa chữa. Điều cần thiết là nhóm làm việc trên một phiên bản phải hiểu lý do tại sao các quyết định nhất định được đưa ra khi làm việc trên một phiên bản khác. Để làm được điều này, bạn cần có cơ sở kiến thức dành cho nhà phát triển - một hệ thống thông tin đặc biệt sẽ mô tả tất cả các vấn đề mà nhà phát triển gặp phải khi làm việc trên một phiên bản cụ thể của sản phẩm và cách giải quyết những vấn đề này. Cơ sở kiến thức nên gửi thông báo cho tất cả những người tham gia dự án khi có hồ sơ mới. Không thể để sự tương tác của hai nhóm làm việc trên các phiên bản khác nhau của cùng một sản phẩm làm mất công việc của nó.

Quy trình phát triển phần mềm nhúng

Như đã nói ở trên, phần mềm nhúng khác với phần mềm tùy chỉnh ở chỗ nó cực kỳ khó bảo trì.

Giả sử bạn phát hành phần mềm cho tủ lạnh. Một khi phần mềm được giao cho nhà sản xuất, hàng chục nghìn thiết bị bắt đầu phân tán trên khắp thế giới và bạn không biết chúng sẽ đến đâu. Và nếu một trong những tủ lạnh bị lỗi do lỗi phần mềm của bạn, thì bạn sẽ dễ dàng bị phạt hơn là trả tủ lạnh về nhà máy và tiến hành chẩn đoán. Tất nhiên, có thể đào tạo các kỹ sư cho các đại lý, những người có thể thực hiện chẩn đoán tại chỗ và thay thế phần sụn cho hệ thống của bạn, nhưng điều này vẫn rất tốn kém.

Do đó, khi phát triển phần mềm nhúng, một số hạn chế quan trọng phát sinh cùng một lúc.

Thứ nhất, việc phân phối được thực hiện trong khuôn khổ chỉ một giai đoạn: không ai xây dựng một chương trình làm việc nửa vời vào các thiết bị.

Thứ hai, khi giao hàng, bạn phải đặc biệt quan tâm đến chất lượng của chương trình, vì ngay từ khi nó được đưa vào hộp sắt, sẽ rất khó để đổi trả. Cần đặc biệt chú ý đến giai đoạn vận hành thử nghiệm, khi chương trình được thực hiện trong một loạt thiết bị hạn chế và các thiết bị này trải qua các thử nghiệm toàn diện ở các chế độ vận hành khác nhau. Bạn phải thu thập càng nhiều thông tin càng tốt về hoạt động của hệ thống, phân tích thông tin này và tinh chỉnh phần mềm.

Thứ ba, khi một thiết bị có phần mềm của bạn đã bị lỗi, bạn có rất ít cơ hội để sửa lỗi. Trên thực tế, các bản sửa lỗi như vậy chỉ có thể thực hiện được trong trường hợp phần mềm bị lỗi dẫn đến toàn bộ lô thiết bị không thể hoạt động được, do đó nhà sản xuất sẽ buộc phải thu hồi lô này và bạn sẽ nhận được một vết đen lớn về danh tiếng của mình. .

Cuối cùng, thứ tư, không có giai đoạn ngừng hoạt động cho phần mềm nhúng. Chương trình chỉ đơn giản là vứt bỏ cùng với thiết bị. Do đó, ngay sau khi hết thời hạn bảo hành cho một lô thiết bị mà phần mềm của bạn đang chạy, bạn có thể tiến hành đóng dự án.

Quá trình phát triển phần sụn được thể hiện trong Hình 3.

Hình 3 Quy trình phát triển phần mềm nhúng.

Quá trình phát triển trò chơi

Phần mềm chơi game đã được tôi chọn ra do các chi tiết cụ thể về sản xuất và vận hành của chúng. Việc kinh doanh phần mềm trò chơi dựa trên việc phát hành các lượt truy cập. Một lần truy cập thành công trả cho chi phí tạo ra một số trò chơi mà người dùng không chú ý. Do đó, quá trình phát triển của một trò chơi này có mối liên hệ với các quá trình phát triển của các trò chơi khác.

Một yếu tố khác làm cho việc sản xuất trò chơi trở nên nổi bật là thực tế là trò chơi thú vị đối với người dùng cho đến khi anh ta vượt qua cấp độ cuối cùng, hoặc cho đến khi anh ta mắc phải một lỗi nghiêm trọng. Điều này có nghĩa là anh ta sẽ không mua phiên bản thứ hai của trò chơi hoặc thậm chí tải xuống miễn phí chỉ để sửa một vài lỗi.

Những yếu tố này ảnh hưởng đến quá trình phát triển của phần mềm chơi game. Quá trình này được thể hiện trong Hình 4.

Hình 4. Quy trình phát triển phần mềm trò chơi.

Cần lưu ý các đặc điểm sau của quá trình phát triển phần mềm chơi game.

Trước hết, trong sản xuất game, chất lượng của khái niệm là vô cùng quan trọng. Nếu khái niệm của trò chơi không cho phép bạn tạo ra một cú đánh, thì công việc tiếp theo là vô nghĩa. Tình huống khi hầu hết các dự án kết thúc ở giai đoạn chuẩn bị là điển hình cho việc phát triển phần mềm trò chơi.

Yêu cầu và phát triển kiến trúc cho phần mềm chơi game thường sử dụng lại các bài học kinh nghiệm từ các dự án trước đó. Về vấn đề này, giai đoạn kết thúc dự án cũng có thêm sức nặng, khi tất cả các phát triển hữu ích phải được ghi lại trong cơ sở kiến thức của nhà phát triển.

Việc phân phối phần mềm chơi game diễn ra trong một giai đoạn duy nhất. Ngay cả khi một lõi nhất định, “động cơ” của hệ thống trò chơi, được tạo ra lần đầu tiên, hoạt động của nó không thể được xác minh nếu không thực hiện toàn bộ chức năng của hệ thống.

Không có giai đoạn thử nghiệm hoặc ngừng hoạt động cho phần mềm trò chơi. Các trò chơi ngay lập tức được rao bán và sau khi sử dụng, người dùng chỉ cần xóa chúng đi vì họ không còn hứng thú với chúng.

Sự kết luận

Như một phần của bài viết, tôi đã cố gắng đưa ra một cái nhìn tổng quan về “cấp cao nhất” của quy trình phát triển phần mềm ứng dụng. Tất nhiên, mỗi giai đoạn của quy trình cần có một cuộc thảo luận riêng với việc xem xét bắt buộc các tính năng của phần mềm đã phát triển.

Tôi lưu ý rằng sơ đồ quy trình được xem xét ở đây là kết quả tổng hợp kinh nghiệm cá nhân của tôi trong việc phát triển các công cụ phần mềm khác nhau. Giống như bất kỳ sự tổng quát hóa nào, lược đồ của tôi là một sự trừu tượng. Và, giống như bất kỳ sự trừu tượng nào, nó có giới hạn về khả năng ứng dụng. Bạn không thể áp dụng kế hoạch này một cách thiếu suy nghĩ cho một dự án cụ thể. Điều quan trọng là phải hiểu rằng mỗi dự án có những sắc thái riêng ảnh hưởng đến việc tổ chức quá trình phát triển. Và do đó, đối với mỗi dự án, kế hoạch được trình bày ở đây phải được điều chỉnh, và trong một số trường hợp, cần phải phát triển một cách tiếp cận cơ bản khác nhau.

quản lý phần mềm

Quá trình phát triển phần mềm là nhiều hoạt động, phương pháp, kỹ thuật và bước khác nhau được sử dụng để phát triển và phát triển phần mềm và các sản phẩm liên quan (kế hoạch dự án, tài liệu, mã, thử nghiệm, tài liệu người dùng).

Tuy nhiên, ngày nay không có quy trình phát triển phần mềm toàn cầu - một tập hợp các phương pháp, quy tắc và quy định phù hợp với bất kỳ loại phần mềm nào, cho bất kỳ công ty nào, cho các đội thuộc bất kỳ quốc tịch nào. Mỗi quy trình phát triển hiện tại được thực hiện bởi một nhóm nhất định trong một dự án nhất định có một số lượng lớn các tính năng và cá thể. Tuy nhiên, nên lập kế hoạch quy trình làm việc trước khi bắt đầu dự án, xác định vai trò và trách nhiệm trong nhóm, sản phẩm công việc (trung gian và cuối cùng), thứ tự tham gia vào quá trình phát triển của các thành viên trong nhóm, v.v.

Quá trình phát triển phần mềm không đồng nhất. Một hoặc một phương pháp phát triển phần mềm, như một quy luật, xác định một số động lực của việc triển khai các loại hoạt động nhất định, nghĩa là, nó xác định mô hình quy trình.

Mô hình là sự trừu tượng hóa tốt các phương pháp phát triển phần mềm khác nhau, cho phép chúng được trình bày ngắn gọn, súc tích và đầy đủ thông tin. Tuy nhiên, ý tưởng về một mô hình quy trình là một trong những ý tưởng sớm nhất trong kỹ thuật phần mềm, khi người ta tin rằng một mô hình thành công là điều quan trọng nhất góp phần vào sự thành công của sự phát triển. Sau đó, người ta nhận ra rằng có nhiều khía cạnh khác (ví dụ như các nguyên tắc quản lý và phát triển, cấu trúc đội ngũ) cần được xác định phù hợp với nhau. Và các phương pháp luận phát triển tích hợp bắt đầu phát triển. Tuy nhiên, có một số mô hình cổ điển của quá trình phát triển phần mềm.

Mô hình đầu tiên được biết đến rộng rãi và thực sự cấu trúc nên quá trình phát triển là kiểu xếp tầng hoặc thác nước. Nó được tạo ra sau hội nghị khoa học và công nghệ của NATO năm 1968, giải quyết những vấn đề như vậy và chia quá trình tạo ra một sản phẩm phần mềm thành các giai đoạn liên tiếp (cần lưu ý rằng nó đã được sử dụng bởi nhiều nhà phát triển khác nhau, nhưng không phải số lượng cũng như nội dung của các giai đoạn thống nhất).

Hình 1 - Mô hình phát triển phần mềm thác nước đã sửa đổi

Mô hình thác đã sửa đổi cung cấp khả năng quay trở lại các giai đoạn trước đó.

Ngay sau khi xuất hiện, mô hình thác nước đã được Winst Royce hoàn thiện lần cuối, có tính đến sự phụ thuộc lẫn nhau của các giai đoạn và sự cần thiết phải quay lại các giai đoạn trước đó, ví dụ như do các yêu cầu không hoàn chỉnh hoặc lỗi trong quá trình hình thành nhiệm vụ. Ở dạng “có thể đảo ngược” này, mô hình thác nước đã tồn tại trong một thời gian dài và là cơ sở cho nhiều dự án (Hình 1).

Tuy nhiên, thực tế sử dụng mô hình này đã bộc lộ nhiều nhược điểm của nó, mà nguyên nhân chính là nó phù hợp với các dạng hoạt động kỹ thuật truyền thống hơn là phát triển phần mềm. Đặc biệt, một trong những vấn đề lớn nhất là "khuynh hướng" có thể xảy ra mâu thuẫn giữa sản phẩm kết quả và các yêu cầu đặt ra. Lý do chính cho điều này là một sản phẩm được hình thành hoàn chỉnh chỉ xuất hiện ở giai đoạn sau của quá trình phát triển, nhưng vì công việc ở các giai đoạn khác nhau thường được thực hiện bởi các chuyên gia khác nhau và dự án được chuyển từ nhóm này sang nhóm khác, do đó, nguyên tắc của một chiếc điện thoại bị hư hỏng, hóa ra là kết quả đầu ra không hoàn toàn như dự định ban đầu.

Để loại bỏ những thiếu sót của mô hình thác nước, một mô hình phát triển phần mềm hình chữ V hoặc bản lề đã được đề xuất (Hình 2).

Hình 2 - Mô hình phát triển phần mềm hình chữ V

Mô hình hình chữ V cho phép kiểm soát nhiều hơn đối với kết quả về mức độ tuân thủ các kỳ vọng của nó, vì nó tập trung vào thử nghiệm.

Mô hình hình chữ V có thể cải thiện đáng kể chất lượng của phần mềm do tập trung vào kiểm tra và cũng giải quyết phần lớn vấn đề tuân thủ của sản phẩm được tạo ra với các yêu cầu đưa ra do quy trình xác minh và chứng nhận ở giai đoạn đầu của phát triển (các đường chấm trong hình biểu thị sự phụ thuộc của các nhiệm vụ lập kế hoạch / giai đoạn thiết lập và kiểm tra / nghiệm thu).

Tuy nhiên, nhìn chung, mô hình chữ V chỉ là một cải biến của mô hình xếp tầng và còn nhiều khuyết điểm của nó. Đặc biệt, cả hai đều kém thích ứng với những thay đổi có thể có trong yêu cầu của khách hàng. Nếu quá trình phát triển diễn ra trong một thời gian dài (đôi khi lên đến vài năm), thì sản phẩm thu được có thể thực sự không cần thiết đối với khách hàng, vì nhu cầu của họ đã thay đổi đáng kể.

Không giống như, chẳng hạn, phần mềm có thể được đưa vào vận hành theo từng bộ phận, có nghĩa là nó cũng có thể được phát triển và chuyển giao dần dần cho khách hàng. Đây là cơ sở của mô hình gia tăng, cung cấp cho việc phân mảnh sản phẩm thành các thành phần tương đối độc lập được phát triển và đưa vào hoạt động riêng biệt.

Mô hình này có lợi cho cả khách hàng và người tạo ra hệ thống, vì nó cho phép bạn tiến lên phía trước, tôn trọng lợi ích của cả hai bên.

Tuy nhiên, cô ấy có những khuyết điểm của mình. Việc phân chia thành các khối chức năng nói chung làm chậm quá trình, vì nó trở nên cần thiết để đảm bảo sự tương tác giữa chúng. Đối với nhiều giải pháp, phương pháp này là không thể áp dụng được, vì không thể tách các thành phần riêng lẻ khỏi chúng, các thành phần này có thể được phân phối và hoạt động độc lập. Khối lượng công việc của nhân viên quản lý cũng tăng lên đáng kể do sự phức tạp của các nhiệm vụ điều phối công việc trên các thành phần riêng lẻ của hệ thống, chi phí thực hiện thay đổi các thành phần làm sẵn đã được lắp đặt và làm việc tại khách hàng tăng lên.

Được đề xuất bởi Barry Boehm vào năm 1988, mô hình xoắn ốc là một bước đột phá đáng kể trong việc hiểu bản chất của phát triển phần mềm, mặc dù nó kết hợp phương pháp tiếp cận thác nước và quy trình thiết kế lặp lại dựa trên nguyên mẫu (Hình 3).

Cơm. 3.

Mô hình xoắn ốc của Boehm tập trung vào thiết kế, phát triển phần mềm chỉ là bước cuối cùng của vòng xoắn dọc theo mô hình thác nước thông thường, nhưng điều này được dẫn trước bởi một số lần lặp lại thiết kế dựa trên tạo mẫu - với mỗi lần lặp lại bao gồm giai đoạn xác định và phân tích rủi ro và nhiệm vụ khó khăn nhất.

Vì mô hình xoắn ốc chủ yếu bao gồm thiết kế, ở dạng ban đầu, nó không được sử dụng rộng rãi như một phương pháp quản lý toàn bộ vòng đời của phát triển phần mềm. Tuy nhiên, ý tưởng chính của cô ấy, đó là quá trình làm việc trong một dự án có thể bao gồm các chu trình trải qua các giai đoạn giống nhau, được dùng làm điểm khởi đầu cho các nghiên cứu sâu hơn và trở thành cơ sở của hầu hết các mô hình hiện đại của quá trình phát triển phần mềm.

Được Philip Krachten đề xuất lần đầu tiên vào năm 1995, mô hình lặp kết hợp những ưu điểm chính của mô hình thác nước, xoắn ốc, gia tăng, cũng như các phương pháp phát triển dựa trên phương pháp tạo mẫu và hướng đối tượng (Hình 4). Nó đã trở nên phổ biến rộng rãi và được sử dụng dưới hình thức này hay hình thức khác trong nhiều dự án hiện đại.

Hình 4 - Mô hình phát triển phần mềm lặp đi lặp lại

Theo mô hình lặp lại, có bốn giai đoạn chính của vòng đời phát triển phần mềm (bắt đầu, nghiên cứu, xây dựng và triển khai). Ở mỗi giai đoạn, dự án trải qua nhiều lần lặp lại, dẫn đến việc tạo ra các phiên bản khả thi: ở giai đoạn đầu, các nguyên mẫu được tạo ra, các yêu cầu được chỉ định và các vấn đề phức tạp nhất được giải quyết; những cái cuối cùng dẫn đến việc tạo ra một sản phẩm, cải tiến và mở rộng chức năng của nó.

Mô hình lặp lại, ngoài các giai đoạn chính, còn phân biệt thêm hai nhóm quy trình: làm việc (quản lý yêu cầu, phân tích và thiết kế, thực hiện, thử nghiệm, triển khai) và phụ trợ (cấu hình và quản lý thay đổi, dự án và quy trình). Số lượng và bản chất của các quy trình khác nhau tùy thuộc vào nhu cầu của nhà phát triển, chúng cũng có thể có các chu trình riêng, thậm chí không nhất thiết phải tương ứng với các giai đoạn chính. Tuy nhiên, quy trình làm việc luôn dẫn đến việc tạo ra các phiên bản sản phẩm.

Mô hình lặp đi lặp lại, giống như mô hình xoắn ốc, giúp bạn có thể quản lý rủi ro thành công. Nếu trong quá trình làm việc trên phiên bản tiếp theo, người ta xác định rằng chi phí lao động để thực hiện các chức năng cần thiết là quá cao, thì có thể tránh được việc vượt quá ngân sách và thời hạn bằng cách so sánh các ưu tiên phát triển và chi phí lao động ở đầu mỗi lần lặp lại. Do đó, mô hình này rất phù hợp với hầu hết các loại dự án phần mềm, nhưng ưu điểm của nó là đặc biệt đáng chú ý khi làm việc trên các sản phẩm dự định gia nhập thị trường tự do, do tập trung ban đầu vào việc phát hành các phiên bản kế tiếp.

Tiêu chuẩn chất lượng nổi tiếng và có thẩm quyền nhất nên được coi là Mô hình trưởng thành năng lực (CMM) - một mô hình để đánh giá mức độ trưởng thành của các quá trình phát triển cùng với các dẫn xuất của nó. Nó được tạo ra bởi SEI (Viện Kỹ thuật Phần mềm), được tài trợ bởi Bộ Quốc phòng Hoa Kỳ và là một đơn vị cấu trúc của Đại học Carnegie Mellon. Phiên bản chính thức đầu tiên của tiêu chuẩn được phát hành vào năm 1993, mặc dù công việc về tiêu chuẩn này đã bắt đầu sớm hơn nhiều - các điều khoản chính của tiêu chuẩn đã được xuất bản sớm nhất vào năm 1986. Sự thành công của CMM được xác định trước bởi một số yếu tố. Tiêu chuẩn này là một trong những tiêu chuẩn đầu tiên tính đến các chi tiết cụ thể của phát triển phần mềm ngay từ đầu. Nó hóa ra khá đơn giản và minh bạch về cả cách hiểu và cách sử dụng, và quy định “cái gì” chứ không phải “cách thức” thực hiện, và do đó phù hợp với các mô hình vòng đời khác nhau, phương pháp luận phát triển và không áp đặt bất kỳ hạn chế nào đối với tài liệu tiêu chuẩn, công cụ, môi trường và ngôn ngữ được sử dụng trong các dự án. Và, có lẽ, yếu tố chính xác định trước sự phổ biến của CMM là sự hợp tác của SEI với Bộ Quốc phòng Hoa Kỳ, điều này trên thực tế có nghĩa là việc sử dụng tiêu chuẩn này trong việc thực hiện các dự án do bộ này giao.

Mô hình CMM (bảng 1) cung cấp năm cấp độ trưởng thành, mỗi cấp độ tương ứng với các lĩnh vực quy trình chính nhất định (Khu vực quy trình chính, KPA).

Bảng 1 - Mô hình HMM

Tên cấp độ	Các lĩnh vực quy trình chính
1 - Ban đầu	Nếu tổ chức ở cấp độ này, thì không có lĩnh vực quy trình chính nào cho nó
2 - Định kỳ	Quản lý cấu hình chương trình. Đảm bảo chất lượng của sản phẩm phần mềm. Quản lý hợp đồng của các nhà thầu. Kiểm soát tiến độ dự án. Lập kế hoạch của các dự án phần mềm. Quản lý yêu cầu
3 - Đã xác định	Các đánh giá của chuyên gia. Phối hợp tương tác giữa các nhóm dự án. Kỹ thuật sản phẩm phần mềm. Quản lý phần mềm tích hợp. Chương trình đào tạo nhân viên. Định nghĩa quy trình tổ chức. Phạm vi quy trình tổ chức
4 - Được quản lý	Quản lý chất lượng phần mềm. Kiểm soát quá trình dựa trên các phương pháp định lượng
5 - Tối ưu hóa	Quản lý thay đổi quy trình. Quản lý các thay đổi công nghệ. Phòng chống khiếm khuyết

Việc phân chia thành các cấp độ và định nghĩa KPA cho mỗi cấp độ cho phép thực hiện nhất quán CMM, sử dụng tiêu chuẩn làm hướng dẫn, có thể đảm bảo cải tiến liên tục trong quá trình phát triển.

Tiêu chuẩn CMM hóa ra rất thành công và sau đó toàn bộ một loạt tiêu chuẩn đã được tạo ra trên cơ sở của nó, và nó nhận được một tên mới - SW-CMM (Capability Maturity Model for Software), phản ánh chính xác hơn vị trí của nó trong một họ của các tiêu chuẩn.

Tuy nhiên, ứng dụng thực tế của các tiêu chuẩn dòng CMM đã cho thấy rằng chúng không mang lại thành công vô điều kiện trong việc phát triển phần mềm. Các tiêu chuẩn này không được phối hợp tốt với nhau - việc thực hiện đồng thời các sửa đổi khác nhau của CMM có thể là một thách thức khá lớn và dẫn đến sự bối rối của các chuyên gia của các tổ chức đã đối mặt với nó.

Ngoài ra, một vấn đề quan trọng của CMM là cần phải "căn chỉnh" tất cả các quy trình. Nếu một tổ chức đang cố gắng chứng nhận ở một cấp độ nhất định, thì tổ chức đó phải đảm bảo rằng cấp độ thích hợp được áp dụng cho tất cả các quá trình của tổ chức đó. Ngay cả khi các chi tiết cụ thể, phương pháp luận hoặc các tính năng phát triển không có các quy trình nhất định phải được thực hiện, thì việc chứng nhận vẫn yêu cầu điều này.

Một vấn đề khác là do vị trí của các tiêu chuẩn CMM trong ngành công nghiệp phần mềm hiện đại. Vì một tổ chức có cấp độ cao phù hợp với CMM phải cung cấp hiệu suất sản phẩm phần mềm cao hơn so với tổ chức được chứng nhận ở cấp độ thấp hơn, tiêu chuẩn này đã được sử dụng như một tiêu chí lựa chọn để tham gia vào các dự án thầu phát triển phần mềm hoặc gia công phần mềm.

Tình trạng này có thể xảy ra do những thiếu sót của quá trình chứng nhận. Không phải toàn bộ tổ chức nói chung phải được chứng nhận, mà chỉ một dự án cụ thể. Không có gì ngăn cản một tổ chức tạo ra một dự án "trình diễn" đáp ứng tất cả các yêu cầu của các cấp độ cao của tiêu chuẩn CMM, đạt được cấp độ chứng nhận phù hợp và tuyên bố rằng tất cả các sản phẩm đều đáp ứng các cấp độ như vậy của tiêu chuẩn.

Tiêu chuẩn mới SEI - Capability Maturity Model Integrated (CMMI) - là một mô hình tích hợp để đánh giá mức độ trưởng thành của các quá trình phát triển. Tiêu chuẩn CMMI ban đầu được tạo ra theo cách kết hợp các tùy chọn CMM hiện có và loại bỏ bất kỳ mâu thuẫn nào trong ứng dụng thực tế của nó trong các lĩnh vực hoạt động khác nhau của các công ty công nghệ cao.

Để loại bỏ nhu cầu "sắp xếp" các quy trình của tổ chức và thích nghi hơn với nhu cầu kinh doanh của tổ chức, và không phải ngược lại, tiêu chuẩn CMMI có hai hình thức trình bày - cổ điển, đa cấp, tương ứng với CMM, và mới, liên tục. Hình thức trình bày liên tục không xem xét các mức độ trưởng thành (Maturity Levels) mà là các Mức năng lực, được đánh giá cho các lĩnh vực quy trình riêng lẻ (Vùng quy trình, PA).

Bảng 2 đưa ra ánh xạ về mức độ trưởng thành của tiêu chuẩn CMM, cũng như mức độ trưởng thành của bản trình bày CMMI phân lớp và mức độ khả năng của bản trình bày CMMI liên tục.

Bảng 2 - Tuân thủ các mức độ trưởng thành của tiêu chuẩn CMM, CMMI

SEI đang rời bỏ CMM và đổi lại là tích cực thúc đẩy CMMI, hứa hẹn sẽ thắt chặt kiểm soát quá trình chứng nhận, giảm chi phí và làm cho nó trở nên hấp dẫn hơn đối với các tổ chức nhỏ; đảm bảo tương thích với các tiêu chuẩn ISO.

Trong điều kiện hiện đại, sự hiện diện của chứng chỉ của một cấp độ CMM / CMMI nhất định không phải là một yếu tố quan trọng như cách đây vài năm và được chấp nhận mà không có câu hỏi bổ sung, ngoại trừ có lẽ trong các dự án được thực hiện theo lệnh của chính phủ.

Tiêu chuẩn ISO / IEC 15504 nhằm đánh giá quá trình phát triển hệ thống thông tin, cụ thể là phần mềm. Ban đầu nó được thiết kế để phù hợp với các tiêu chuẩn công nghiệp để đánh giá quá trình phát triển phần mềm. Chính yêu cầu này đã xác định sự tương đồng của tiêu chuẩn với các nguyên tắc cơ bản của CMM / CMMI.

Mô hình trưởng thành của quá trình phát triển phần mềm (CMM) được phát triển bởi Viện Kỹ thuật Phần mềm tại Đại học Carnegie Mellon đề xuất năm mức độ trưởng thành (Bảng 3). Nó giúp các tổ chức tăng cường sự trưởng thành của các quy trình phát triển phần mềm của họ và các tổ chức có thể được đánh giá và công nhận theo các cấp độ này.

Bảng 3 - Mức độ trưởng thành của phát triển phần mềm

Cấp độ 1 - cấp độ đầu vào	Quá trình phát triển phần mềm là tự phát và chỉ có một số quy trình được quy định. Sự thành công của sự phát triển có thể phụ thuộc vào từng nhân viên.
Mức độ 2 - mức độ lặp lại	Đã tạo các quy trình quản lý dự án cốt lõi để theo dõi chi phí, lịch trình và chức năng.
Cấp độ 3 - cấp độ quy định	Quy trình phát triển phần mềm được lập thành văn bản, tiêu chuẩn hóa và tích hợp với quy trình phát triển phần mềm tiêu chuẩn của tổ chức cho cả hoạt động quản lý và phát triển. Tất cả các dự án đều sử dụng một quy trình chuẩn hóa.
Cấp độ 4 - cấp độ quản lý	Các số liệu chi tiết về quy trình phát triển phần mềm và chất lượng sản phẩm được thu thập để giúp hiểu và quản lý quy trình cũng như sản phẩm.
Cấp độ 5 - cấp độ tối ưu hóa	Tối ưu hóa quy trình liên tục được đảm bảo bằng phản hồi định lượng từ quy trình và từ các ý tưởng và công nghệ đổi mới thí điểm.

Do đó, các mô hình và phương pháp hiện đại được sử dụng trong các dự án phát triển phần mềm thực tế rất đa dạng. Mỗi người trong số họ có những lợi thế riêng của nó, được thể hiện trong các điều kiện thích hợp. Ngay cả mô hình thác nước lỗi thời cũng hoàn toàn phù hợp cho một số dự án. Mỗi quy trình cũng có một số đặc điểm giới hạn khu vực sử dụng hiệu quả của nó. Tình huống này khá điển hình đối với phát triển phần mềm, nơi mà nhiều công nghệ và kỹ thuật đã được tích lũy, nhưng không có phương pháp phổ quát nào là tối ưu cho bất kỳ nhiệm vụ nào.

S. Archipenkov

Các mô hình (hoặc, như họ muốn nói, phương pháp luận) của các quy trình phát triển phần mềm thường được phân loại theo "trọng số" - số lượng các quy trình được chính thức hóa (hầu hết các quy trình hoặc chỉ những quy trình chính) và chi tiết về quy định của chúng. Càng nhiều quy trình được lập thành văn bản, càng được mô tả chi tiết, thì “trọng lượng” của mô hình càng lớn.

Các mô hình quy trình phát triển phần mềm hiện đại phổ biến nhất được thể hiện trong Hình 3.

Hình 3 Các mô hình khác nhau của quy trình phát triển phần mềm và sự phân bổ của chúng theo "trọng số"

GOST

SW-CMM

Mô hình này xác định năm mức độ trưởng thành của quá trình phát triển phần mềm.

Ban đầu - quá trình phát triển là hỗn loạn. Rất ít quy trình được xác định, và sự thành công của các dự án phụ thuộc vào từng tác nhân.
Lặp lại - Các quy trình quản lý dự án cơ bản được thiết lập: theo dõi chi phí, thời hạn và chức năng. Một số quy trình cần thiết để tái tạo những thành tựu trước đây trên các dự án tương tự đã được sắp xếp hợp lý.
Được xác định - các quy trình phát triển phần mềm và quản lý dự án được mô tả và thực hiện trong một hệ thống quy trình duy nhất của công ty. Tất cả các dự án đều sử dụng quy trình hỗ trợ và phát triển phần mềm tiêu chuẩn của tổ chức, phù hợp với dự án cụ thể.
Được quản lý - thu thập dữ liệu định lượng chi tiết về hoạt động của các quá trình phát triển và chất lượng của sản phẩm cuối cùng. Ý nghĩa và động lực của những dữ liệu này được phân tích.
Tối ưu hóa - cải tiến quy trình liên tục dựa trên dữ liệu định lượng về các quy trình và việc triển khai thử nghiệm các ý tưởng và công nghệ mới.

RUP

MSF

PSP / TSP

Một trong những phát triển mới nhất của Viện Công nghệ Phần mềm Quy trình Phần mềm Cá nhân / Nhóm Phần mềm [,]. Quy trình Phần mềm Cá nhân xác định các yêu cầu về năng lực của nhà phát triển. Theo mô hình này, mọi lập trình viên sẽ có thể:

tính đến thời gian dành cho dự án;
tính đến các khuyết tật được tìm thấy;
phân loại các dạng khuyết tật;
ước tính quy mô của nhiệm vụ;
thực hiện một cách tiếp cận có hệ thống để mô tả kết quả thử nghiệm;
kế hoạch chương trình nhiệm vụ;
phân phối chúng theo thời gian và lập một lịch trình làm việc.
thực hiện đánh giá thiết kế và kiến trúc cá nhân;
thực hiện xác minh cá nhân của mã;
thực hiện kiểm thử hồi quy.

Quy trình phần mềm nhóm dựa trên các nhóm tự quản lý gồm 3-20 nhà phát triển. Các đội phải:

đặt mục tiêu của riêng bạn;
phát triển quy trình và kế hoạch của bạn;
theo dõi công việc;
duy trì động lực và hiệu suất cao nhất.

Việc áp dụng nhất quán mô hình PSP / TSP cho phép bạn biến cấp độ thứ năm của CMM trở thành chuẩn mực trong tổ chức.

Nhanh nhẹn

Lựa chọn mô hình quy trình

Các mô hình nặng và nhẹ của quá trình sản xuất có những ưu điểm và nhược điểm của chúng (Bảng 1).

Bảng 1. Ưu nhược điểm của các mô hình nặng và nhẹ của các quy trình phát triển phần mềm

Trọng lượng mô hình	thuận	Số phút
Nặng	Các quy trình được thiết kế cho trình độ trung bình của những người thực hiện. Chuyên môn hóa tuyệt vời của người biểu diễn. Dưới đây là các yêu cầu về sự ổn định của nhóm. Không có hạn chế về khối lượng và độ phức tạp của các dự án đang thực hiện.	Yêu cầu chi phí quản lý đáng kể. Các giai đoạn phân tích và thiết kế dài hơn. Thông tin liên lạc chính thức hơn.
Phổi	Ít chi phí liên quan đến quản lý dự án, rủi ro, thay đổi, cấu hình. Đơn giản hóa các giai đoạn phân tích và thiết kế, tập trung chính vào sự phát triển của chức năng, sự kết hợp của các vai trò. thông tin liên lạc không chính thức.	Hiệu quả phụ thuộc nhiều vào khả năng của từng cá nhân, đòi hỏi một đội ngũ chất lượng, đa năng và ổn định hơn. Phạm vi và mức độ phức tạp của các dự án đang triển khai bị hạn chế.

Trọng lượng mô hình

thuận

Số phút

Nặng

Các quy trình được thiết kế cho trình độ trung bình của những người thực hiện. Chuyên môn hóa tuyệt vời của người biểu diễn. Dưới đây là các yêu cầu về sự ổn định của nhóm.

Không có hạn chế về khối lượng và độ phức tạp của các dự án đang thực hiện.

Yêu cầu chi phí quản lý đáng kể.

Các giai đoạn phân tích và thiết kế dài hơn.

Thông tin liên lạc chính thức hơn.

Phổi

Ít chi phí liên quan đến quản lý dự án, rủi ro, thay đổi, cấu hình.

Đơn giản hóa các giai đoạn phân tích và thiết kế, tập trung chính vào sự phát triển của chức năng, sự kết hợp của các vai trò. thông tin liên lạc không chính thức.

Hiệu quả phụ thuộc nhiều vào khả năng của từng cá nhân, đòi hỏi một đội ngũ chất lượng, đa năng và ổn định hơn.

Phạm vi và mức độ phức tạp của các dự án đang triển khai bị hạn chế.

Những người cố gắng làm theo các mô hình được mô tả trong sách, mà không phân tích khả năng ứng dụng của chúng trong một tình huống cụ thể, các chỉ định và chống chỉ định, được ví như những tín đồ của giáo phái Cargo - tôn giáo của những người sùng bái máy bay. Ở Melanesia, họ tin rằng hàng hóa phương Tây (hàng hóa, hàng hóa tiếng Anh) được tạo ra bởi linh hồn của tổ tiên và dành cho người Melanesia. Người ta tin rằng người da trắng đã giành quyền kiểm soát những mặt hàng này một cách không trung thực. Các nhà thờ chở hàng nổi tiếng nhất xây dựng các bản sao của đường băng, sân bay và tháp đài từ thân dừa và rơm. Các thành viên giáo phái xây dựng chúng với niềm tin rằng những cấu trúc này sẽ thu hút các máy bay vận tải (được coi là sứ giả của các linh hồn) chở đầy hàng hóa (hàng hóa). Các tín đồ thường xuyên tiến hành các cuộc diễn tập quân sự ("khoan") và một số loại hành quân quân sự, sử dụng cành cây thay cho súng trường và vẽ trên thân lệnh và dòng chữ "USA". Tất cả những điều này để máy bay có thể bay xuống từ bầu trời một lần nữa và sẽ có nhiều mặt hàng này hơn nữa.

Alistair Cowburn, một trong những tác giả của "Tuyên ngôn Phát triển Phần mềm Agile" đã phân tích các dự án phần mềm rất khác nhau đã được thực hiện theo các mô hình khác nhau từ hoàn toàn nhẹ và "nhanh nhẹn" đến nặng (CMM-5) trong 20 năm qua [ ,]. Ông không tìm thấy mối tương quan nào giữa sự thành công hay thất bại của các dự án và các mô hình quy trình phát triển được sử dụng trong các dự án. Từ đó, ông kết luận rằng hiệu quả của việc phát triển phần mềm không phụ thuộc vào mô hình quy trình, và cả rằng:

Mỗi dự án nên có một mô hình quy trình phát triển riêng.
Mỗi mô hình có thời gian của nó.

Điều này có nghĩa là không có quy trình phát triển phần mềm chính xác duy nhất, trong mỗi dự án mới, quy trình này phải được xác định lại mỗi lần, tùy thuộc vào dự án, sản phẩm và nhân sự, phù hợp với "Quy luật 4 P" (Hình 4). Các quy trình hoàn toàn khác nên được áp dụng trong các dự án có 5 người và các dự án có 500 người. Nếu sản phẩm của dự án là phần mềm quan trọng, ví dụ, một hệ thống điều khiển cho nhà máy điện hạt nhân, thì quá trình phát triển sẽ rất khác với quá trình phát triển, ví dụ, trang web "otdokhni.ru". Và, cuối cùng, quá trình phát triển nên được tổ chức khác nhau trong một nhóm sinh viên của ngày hôm qua và trong một nhóm các chuyên gia có thành tích.

Hình 4. "Định luật 4 Ps". Quy trình trong dự án nên được xác định tùy thuộc vào dự án, sản phẩm và nhân sự

Cần phải làm gì để thành công một dự án phần mềm

Steve McConnell trong cuốn sách của mình đã đưa ra một bài kiểm tra về một dự án phần mềm để tồn tại. Đây là một danh sách kiểm tra 33 điểm, tôi cho rằng cần phải trích dẫn với những điều chỉnh nhỏ. Người quản lý dự án phần mềm nên định kỳ sử dụng nó để đánh giá nội bộ các quy trình của họ.

Để một dự án phần mềm thành công, bạn phải:

Đặt mục tiêu rõ ràng.
Xác định cách thức đạt được mục tiêu.
Kiểm soát và quản lý việc thực hiện.
Phân tích các mối đe dọa và chống lại chúng.
Tạo một đội.

Chúng tôi đặt mục tiêu
1.1. Khái niệm xác định các mục tiêu rõ ràng, rõ ràng.
1.2. Tất cả các thành viên trong nhóm đều coi khái niệm này là thực tế.
1.3. Dự án có cơ sở lý luận về hiệu quả kinh tế.
1.4. Một nguyên mẫu giao diện người dùng đã được phát triển.
1.5. Đặc tả các chức năng mục tiêu của sản phẩm phần mềm đã được phát triển.
1.6. Giao tiếp hai chiều đã được thiết lập với người dùng cuối của sản phẩm
Xác định cách đạt được mục tiêu
2.1. Có kế hoạch chi tiết bằng văn bản để phát triển sản phẩm.
2.2. Danh sách các nhiệm vụ của dự án bao gồm các nhiệm vụ "nhỏ" (quản lý cấu hình, chuyển đổi dữ liệu, tích hợp với các hệ thống khác).
2.3. Sau mỗi giai đoạn của dự án, tiến độ và ngân sách được cập nhật.
2.4. Các quyết định về kiến trúc và thiết kế được lập thành văn bản.
2.5. Có một kế hoạch đảm bảo chất lượng xác định việc kiểm tra và xem xét.
2.6. Một kế hoạch phân phối sản phẩm nhiều giai đoạn đã được xác định.
2.7. Kế hoạch có tính đến đào tạo, cuối tuần, kỳ nghỉ, ngày nghỉ ốm.
2.8. Kế hoạch và tiến độ dự án được tất cả các thành viên trong nhóm phê duyệt.
Chúng tôi kiểm soát và quản lý việc triển khai
3.1. Dự án có một người phụ trách. Đây là một nhà quản lý hàng đầu của công ty biểu diễn, người rất quan tâm đến sự thành công của dự án này.
3.2. Dự án có một người quản lý, và chỉ có một!
3.3. Kế hoạch dự án xác định các mốc "nhị phân".
3.4. Tất cả các bên quan tâm có thể nhận được thông tin cần thiết về tiến độ của dự án.
3.5. Một mối quan hệ tin cậy đã được thiết lập giữa ban quản lý và các nhà phát triển.
3.6. Thiết lập quy trình quản lý thay đổi cho dự án.
3.7. Những người chịu trách nhiệm về quyết định chấp nhận các thay đổi trong dự án đã được xác định.
3.8. Thông tin về kế hoạch, lịch trình và tình trạng của dự án được cung cấp cho mỗi người tham gia.
3.9. Mã hệ thống được tự động xem xét.
3.10. Một hệ thống quản lý lỗi được áp dụng.
Chúng tôi phân tích các mối đe dọa
4.1. Có một danh sách các rủi ro của dự án. Nó thường xuyên được xem xét và cập nhật.
4.2. Người quản lý dự án giám sát sự xuất hiện của những rủi ro mới.
4.3. Đối với mỗi nhà thầu, một người chịu trách nhiệm làm việc với anh ta được xác định.
Làm việc để xây dựng một đội
5.1. Kinh nghiệm của đội là đủ để hoàn thành dự án.
5.2. Nhóm có đủ năng lực trong lĩnh vực ứng dụng.
5.3. Dự án có một trưởng nhóm kỹ thuật.
5.4. Số lượng nhân viên vừa đủ.
5.5. Đội có đủ sự gắn kết.
5.6. Tất cả những người tham gia đều cam kết với dự án.

Đánh giá và giải thích bài kiểm tra

Điểm: tổng điểm, mỗi mục được đánh giá từ 0 đến 3:

0 - thậm chí chưa nghe nói về nó;
1 - đã nghe, nhưng chưa được áp dụng;
2 - áp dụng một phần;
3 - áp dụng đầy đủ.

Các yếu tố hiệu chỉnh:

cho các dự án nhỏ (tối đa 5 người) - 1,5;
cho trung bình (từ 5 đến 20 người) - 1,25.

Kết quả:

<40 - завершение проекта сомнительно.
40-59 - kết quả trung bình. Sẽ có những vấn đề nghiêm trọng xảy ra trong quá trình thực hiện dự án.
60-79 là một kết quả tốt. Dự án có khả năng thành công.
80-89 là một kết quả tuyệt vời. Cơ hội thành công cao.
> 90 là một kết quả tuyệt vời. 100% cơ hội thành công.

Danh sách kiểm tra này liệt kê những gì cần phải làm để thành công của một dự án phần mềm, nhưng không trả lời câu hỏi làm thế nào để thực hiện nó. Đây là nội dung phần còn lại của các bài giảng sẽ nói về.