Quy Trình Phát Triển Phần Mềm | Tầm Nhìn Của Các Quy Trình[Sửa | Sửa Mã Nguồn]

TÌm hiểu về Mô hình Scrum

Khái niệm Scrum

Là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile). Với nguyên tắc chủ đạo là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ để phát triển (các phần nhỏ này phải đọc lập và Release được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong muốn. Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.

Một số đặc điểm của Quy trình phát triển phần mềm SCRUM

• • Scrum (hay agile nói chung) được xếp vào nhóm “Feature-driven development”. Sản phầm được phát triển theo tính năng, chứ không phát triển sản phẩm theo kiến trúc hệ thống.

Scrum khác với các mô hình Agile ở chỗ nó là mô hình hướng khách hàng (Customer oriented), vai trò của khách hàng trong việc đánh giá sản phẩm rất quan trọng. Chỉ sau mỗi sprint (2-4 tuần) khách hàng sẽ thấy được sự thay đổi của sản phẩm của mình qua đó đưa ra phản hồi sớm để định hướng -> Thích ứng nhanh với sự thay đổi yêu cầu.

• • Scrum giảm thiểu tài nguyên dành cho việc quản lý mà tập trung nhiều hơn cho những công việc liên quan trực tiếp đến việc làm ra sản phẩm. Bằng cách giảm vai trò quản lý (PM) bằng cách đẩy việc quản lý tới từng người.
  • Giảm thời gian dành cho việc viết tài liệu bằng cách tăng thời gian trao đổi trực tiếp. Thông thường khi estimate công việc, thì team estimate cả thời gian dành cho communication để hoàn thành task đó nữa.
  • Tập trung vào sản phẩm, sản phẩm mới là đích cuối cùng chứ không phải qui trình.

Tham khảo thêm: Tuyển dụng lập trình Scrum lương cao tại Topdev.

Ưu điểm, nhược điểm của mô hình Scrum

ƯU ĐIỂM:

• Một người có thể làm nhiều việc ví dụ như dev có thể test
• Phát hiện lỗi sớm hơn rất nhiều so với các phương pháp truyền thống
• Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm.
• Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.

NHƯỢC ĐIỂM:

• Trình độ của nhóm là có một kỹ năng nhất định
• Phải có sự hiểu biết về mô hình aglie .
• Khó khăn trong việc xác định ngân sách và thời gian.
• Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài khi có quá nhiều yêu cầu thay đổi từ khách hàng.
• Vai trò của PO (Product Owner) rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung.

Các nhân tố cấu tạo lên 1 quy trình phát triển phần mềm trong Scrum

Một cách đơn giản có 03 thành tố quan trọng cấu thành nên SCRUM: Tổ chức (Organization), Qui trình (Process), Tài liệu (Atifacts). Trong mỗi thành tố có 03 thành tố con. Như vậy, chúng ta chỉ cần hiểu và áp dụng được 9 thành tố này là có thể áp dụng SCRUM.

• Tổ chức (Organization): Tổ chức nhóm dự án và Roles (Vài trò)
  • • Product Owner (Người sở hữu sản phẩm)
    • ScrumMaster (Người điều phối )
    • Development Team (Nhóm phát triển)
• Tài liệu (Atifacts): các kết quả đầu ra
  • • Product Backlog (Danh sách các chức năng cần phát triển của sản phẩm)
    • Sprint Backlog (Danh sách các chức năng cần phát triển cho mỗi giai đoạn)
    • Estimation (Kết quả ước lượng của Team)
• Qui trình(Process): Qui định cách thức vận hành của SCRUM
• • • Sprint Planning meeting (Họp để hoạch định cho mỗi giai đoạn)
    • Sprint Review (Họp để tổng kết cho mỗi giai đoạn)
    • Daily Scrum Meeting (Họp review hàng ngày)

4.1 Tổ chức của dự án(Organization)

• Product Owner

Product Owner là người sở hữu sản phẩm, người quyết định sản phẩm có những chức năng nào và là người quyết định Product Backlog, họ sẽ tham gia 1 phần vào quy trình phát triển phần mềm. Thông thường Role này được khách hàng hoặc người đại diện cho khách hàng đảm nhận.

• ScrumMaster

Scrum Master là người đảm bảo các qui trình của Scrum được thực hiện đúng và thuận lợi, giúp đỡ cho Team thực hiện công việc phát triển sản phẩm một cách tốt nhất.

• Development Team (Nhóm phát triển)

Một nhóm từ 4-7 kỹ sư phần mềm chịu trách nhiệm phát triển sản phẩm. Nhóm dự án phải làm việc với Product Owner để quyết định những gì sẽ làm trong Sprint (giai đoạn )này và kết quả sẽ ra sao. Đồng thời nhóm cũng thảo luận để đưa ra các giải pháp, ước lượng thời gian thực hiện công việc, họp đánh giá kết quả công việc. Nếu dự án lớn chúng ta cần chia ra thành các dự án nhỏ.

4.2 Tài liệu (Atifacts)

• Product Backlog

Product Backlog là danh sách các chức năng cần được phát triển của sản phẩm trong quy trình phát triển phần mềm. Danh sách này do Product Owner quyết định. Nó thường xuyên được cập nhật để đáp ứng được nhu cầu thay đổi của khách hàng cũng như các điều kiện của dự án.

• Sprint Backlog

Sprint là một giai đoạn phát triển trong quá trình phát triển sản phẩm, nó được khuyến khích có chiều dài từ 2 – 4 tuần. Mỗi Sprint được xác định bằng thời gian phát triển, danh sách các chức năng phát triển (Sprint Backlog).

Mỗi sprint phải Release được sản phẩm để đảm bảo lấy được ý kiến khách hàng, qua được các qui trình phát triển của sản phẩm nhằm rút kinh nghiệm và tránh sự cố sau này.

Sprint Backlog là danh sách chức năng phát triển trong Sprint, nó được quyết định bởi cuộc họp Sprint Planning. Sprint Backlog là các chức năng được chọn từ Product Backlog dựa trên mức độ ưu tiên và khả năng của team phát triển.

• Estimation (ước lượng)

Trong SCRUM thì các thành viên của Team sẽ tự lựa chọn Task cho mình và ước lượng thời gian phát triển dự kiến và chịu trách nhiệm với ước lượng này. Sau khi hoàn thành sẽ cập nhật vào bảng Sprint Backlog.

4.3 Qui trình(Process)

• Sprint Planning meeting (Họp lập kế hoạch cho mỗi Sprint)

Như chúng ta đã biết ở trên Sprint là một giai đoạn phát triển có thời gian từ 2-4 tuần. Để chuẩn bị cho mỗi Sprint team cần phải họp để xác định những chức năng nào (story) sẽ phát triển trong giai đoạn này (sprint backlog), kết quả đầu ra dự kiến (Goal, kết quả Release), Estimate (ước lượng ai làm việc gì) và thảo luận các giải pháp. Tất cả được ghi thành biên bản để có cơ sở thực hiện và Review sau này.

• Sprint Review

Là cuộc họp để đánh giá lại kết quả thực hiện của Sprint vừa qua, xác định những chức năng được Release, những chức năng tiếp tục sửa hoặc phát triển thêm, xác định những vấn đề phát sinh và bàn phương án giải quyết, bổ sung Product Backlog v….

• Daily Scrum Meeting (hay còn gọi là Standup Meeting)
  • Daily Scrum Meeting là cuộc họp hàng ngày và được đề nghị không quá 15 phút và họp đứng để đảm bảo thời gian họp không bị kéo dài vào đầu mỗi ngày, mỗi thành viên chỉ trả lời 3 câu hỏi:

• • • Phát sinh vấn đề gì trong quy trình phát triển phần mềm?
    • Hôm nay bạn sẽ làm gì
    • Hôm qua bạn làm được gì?
    • Nếu thành viên gặp vấn đề thì nên làm việc riêng để giải quyết để không mất nhiều thời gian của các thành viên. Scrum Master phải đảm bảo cuộc họp này được thực hiện đúng qui định.
    • Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất hoặc khi Product Owner quyết định có thể dừng dự án căn cứ tình hình thực tế. Do sử dụng chiến thuật “có giá trị hơn làm trước” nên các hạng mục mang lại nhiều giá trị hơn cho chủ dự án luôn được hoàn tất trước. Do đó Scrum luôn mang lại giá trị cao nhất cho người đầu tư cho dự án. Do quy trình luôn luôn được cải tiến, nhóm Scrum thường có năng suất lao động rất cao. Đây là hai lợi ích to lớn mà quy trình phát triển phần mềm Scrum mang lại cho tổ chức.

Tầm nhìn của các quy trình[sửa | sửa mã nguồn]

Do bản chất không thể nắm bắt cụ thể của các hệ thống phần mềm, các nhà quản lý quy trình phần mềm cần các báo cáo, các hồ sơ và xem xét để theo dõi tiến độ cũng như những gì xảy ra của công việc. Hầu hết các tổ chức phát triển các phần mềm lớn dùng kiểu quy trình “định hướng chuyển giao được”. Mỗi thao tác phải kết thúc bằng một hồ sơ hay báo cáo nhằm làm cho quy trình phần mềm trở nên cụ thể hơn.

7 Giai Đoạn Quan Trọng Trong Quy Trình Phát Triển Phần Mềm

Có nhiều quy trình phát triển phần mềm khác nhau mà đội ngũ developers có thể áp dụng để tạo ra sản phẩm cuối. Các phương pháp này còn được gọi là ‘Mô hình quy trình phát triển phần mềm’ và bao gồm một vài mô hình phổ biến như Mô hình thác nước, Mô hình chữ V, v.v. Các mô hình này bao gồm một vòng đời cụ thể mà chúng tuân theo để xác định mức độ thành công trong quy trình phát triển phần mềm.

Trong bài viết này Savvycom sẽ giới thiệu 7 giai đoạn quan trọng trong Quy trình phát triển phần mềm, Vòng đời phát triển phần mềm (SDLC- Software Development Life ) và 05 mô hình phát triển phần mềm được dùng nhiều nhất hiện nay.

Làm thế nào để tăng tốc quá trình phát triển phần mềm?

Như đã nói ở trên, để tạo ra được một phần mềm, đội ngũ lập trình viên cần tuân thủ đủ các quá trình phát triển phần mềm tiêu chuẩn. Muốn tăng tốc quá trình phát triển, bạn bắt buộc phải có giải pháp để tối ưu hoá các bước này.

Tại BMD Solutions, chúng tôi áp dụng quy trình phát triển phần mềm tinh gọn bao gồm một số quy tắc như:

• Loại bỏ lãng phí: Tất cả mọi thứ không tăng thêm giá trị cho khách hàng được coi là lãng phí và cần loại bỏ;
• Áp dụng công nghệ mới: Luôn luôn tìm hiểu các phương pháp lập trình và công nghệ mới nhằm áp dụng và tối ưu hoá việc lập trình;
• Nguyên tắc “độ trễ”: Trong khi tiến hành các bước phát triển phần mềm, bạn sẽ gặp phải rất nhiều biến số, và nhất là khi thiết kế các phần mềm phức tạp thì biến số này càng nhiều. Bạn cần xác định được độ trễ trong quá trình thiết kế cho các quyết định quan trọng để tránh được việc xảy ra sai sót và phải sửa đi sửa lại nhiều lần;
• Đề cao việc tối ưu hóa cục bộ: Một phần mềm được tạo ra nhờ sự tương tác giữa các bộ phận nhỏ. Bởi vậy trong quá trình phát triển phần mềm bạn cần nhìn nhiều hơn vào tổng thể để nhận ra vấn đề kết nối trong các bộ phận nhỏ đó. Việc này sẽ giúp sửa lỗi và thiết kế nhanh hơn…

Các mô hình phát triển sản phẩm phần mềm[sửa | sửa mã nguồn]

Mô hình Waterfall (Mô hình thác nước)[sửa | sửa mã nguồn]

Mô hình phát triển phần mềm Waterfall là quy trình phát triển phần mềm từ phân tích yêu cầu cho tới khi phát hành sản phẩm mà không quay về bước trước đó. Các bước phát triển phần mềm theo một chiều các bước sau:

1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu được hình thành bởi sự trợ ý của hệ thống người tiêu dùng. Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người tiêu dùng.
2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay nhiều chương trình khả thi.
3. Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập hợp nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó.
4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng.
5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là pha lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đoạn trước của chu kì sống; nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện về yêu cầu mới.

Chỗ yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Hệ thống phân phối đôi khi không dùng được vì không thỏa mãn được yêu cầu của khách hàng. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là một hệ quả đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm – phần cứng.

Mô hình phát triển tiến hoá[sửa | sửa mã nguồn]

• Phân loại sự phát triển tiến hóa
  1. Lập trình thăm dò: đối tượng của quy trình bằng cách làm việc với khách hàng để thăm dò các yêu cầu và phân phối phần mềm dứt điểm. Sự phát triển nên bắt đầu với những phần nào đã được hiểu rõ. Phần mềm sẽ được thêm vào các chức năng mới khi mà nó được đề nghị cho khách hàng (và nhận về các thông tin).
  2. Mẫu thăm dò: đối tượng của phát triển tiến hoá này là nhằm hiểu các yêu cầu của khách hàng và do đó phát triển các định nghĩa yêu cầu tốt hơn cho phần mềm. Các mẫu tập trung trên các thí nghiệm với những phần đòi hỏi nào của khách hàng mà có thể gây sự khó hiểu hay ngộ nhận.

• Phân tích mô hình: Mô hình phát triển tiến hóa này hiệu quả hơn mô hình thác nước. Tuy nhiên, nó vẫn còn các khuyết điểm:
  1. quy trình thì không nhìn thấy rõ được: Các nhà quản lý cần phân phối thường xuyên để đo lường sự tiến bộ. Nó không kinh tế trong việc làm ra các hồ sơ cho phần mềm.
  2. Phần mềm thường dược cấu trúc nghèo nàn: Sự thay đổi liên tục dễ làm đổ vỡ cấu trúc của phần mềm, tạo ra sự khó khăn và tốn phí.
  3. Thường đòi hỏi những kỹ năng đặc biệt: Hầu hết các hệ thống khả dĩ theo cách này được tiến hành bởi các nhóm nhỏ có kỹ năng cao cũng như các cá nhân phải năng động.
• Mô hình này thích hợp với:
  1. Phát triển các loại phần mềm tương đối nhỏ
  2. Phát triển các loại phần mềm có đời sống tương đối ngắn
  3. Tiến hành trong các hệ thống lớn hơn ở những chỗ mà không thể biểu thị được các đặc tả chi tiết trong lúc tiến hành. Thí dụ của trường hợp này là các hệ thống thông minh nhân tạo (AI) và các giao diện cho người dùng.

Mô hình xoắn ốc Boehm[sửa | sửa mã nguồn]

Đây là mô hình phát triển từ mô hình thác nước cho thấy mức độ tổng quát hơn của các pha sản xuất của một sản phẩm. Mô hình được đề nghị bởi Boehm vào năm 1988. Mô hình này có thể chỉ ra các rủi ro có thể hình thành trên căn bản của mô hình quy trình (sản xuất) tổng quát.

Mô hình Boehm có dạng xoắn ốc. Mỗi vòng lặp đại diện cho một pha của quy trình phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế lo về định nghĩa các yêu cầu, kế đến là thiết kế,…

Không có một pha nào được xem là cố định trong vòng xoắn. Mỗi vòng có 4 phần tương ứng với một pha.

1. Cài đặt đối tượng: Chỉ ra các đối tượng của pha trong đề án. Những khó khăn hay cưỡng bức của quy trình và của sản phẩm được xác định và được lên kế hoạch chi tiết. Xác định các yếu tố rủi ro của đề án. Các phương án thay thế tùy theo các rủi ro này có thể được dự trù.
2. Lượng định và giảm thiểu rủi ro. Tiến hành phân tích mỗi yếu tố rủi ro đã xác định. Các bước đặt ra để giảm thiểu rủi ro.
3. Phát triển và đánh giá: Sau khi đánh giá các yếu tố rủi ro, một mô hình phát triển cho hệ thống được chọn.
4. Lên kế hoạch: Đề án được xem xét và quyết định có nên hay không tiếp tục pha mới trong vòng lặp.

Các quy trình linh hoạt(Agenda)[sửa | sửa mã nguồn]

Là quy trình mà trong đó cấu trúc khởi động sẽ nhỏ nhưng linh động và lớn dần của các đề án phần mềm nhằm tìm ra các khó khăn trước khi nó trở thành vấn đề có thể dẫn tới những hủy hoại. quy trình này nhấn mạnh sự gọn nhẹ và tập trung hơn là các phương pháp truyền thống. Các quy trình linh hoạt dùng các thông tin phản hồi thay vì dùng các kế hoạch, như là một cơ chế diều khiển chính. Các thông tin phản hồi có được từ các thử nghiệm và các phiên bản phát hành của phần mềm tham gia.

Các quy trình linh hoạt thưòng có hiệu quả hơn các phương pháp cũ, nó dùng ít thời gian lập trình để sản xuất ra nhiều chức năng hơn, chất lượng cao hơn, nhưng nó không cung cấp một khả năng kế hoạch lâu dài.

Một cách ngắn gọn các phương pháp này cung ứng hiệu quả cao nhất cho vốn đầu tư, nhưng lại không định rõ hiệu quả gì.

Lập trình cực hạn, gọi tắt là XP, là loại quy trình linh hoạt được biết đến nhiều nhất. Trong XP, các pha được xúc tiến trong các bước cực nhỏ (hay liên tục) nếu so với các quy trình kiểu cũ, gọi là các “toán” xử lý. Bước đầu tiên (với chủ định là không hoàn tất) cho đến các bước có thể chỉ tốn một ngày hay một tuần, thay vì phải tốn nhiều tháng như trong phương pháp thác nước. Đầu tiên, một người viết các thử nghiệm tự động để cung cấp các mục tiêu cụ thể cho sự phát triển. Kế đến là giai đoạn viết mã (bởi một cặp lập trình viên); giai đoạn này hoàn tất khi mà các mã viết qua được tất cả các thử nghiệm và những người lập trình không tìm ra thêm được thử nghiệm cần thiết nào nữa. Thiết kế và kiến trúc được điều chỉnh và nâng cao ngay sau giai đoạn viết mã này bởi người đã viết mã trong giai đoạn trước. Hệ thống chưa hoàn tất nhưng hoạt động được này được khai thác hay được đem ra minh họa cho (một phần) người tiêu dùng mà trong số đó có người trong đội phát triển phần mềm. Thời điểm này những người thực nghiệm lại bắt đầu viết các thử nghiệm cho những phần quan trọng kế tiếp của hệ thống.

II- 7 Giai Đoạn Trong Quy Trình Phát Triển Phần Mềm

Có thể bạn đã quen thuộc với các bước khác nhau trong SDLC nếu bạn là người quản lý dự án. Bạn phải xem xét mọi thứ, từ các yêu cầu đến giao tiếp với các bên liên quan, phát triển và bảo trì liên tục với tư cách là người quản lý một dự án kỹ thuật số.

Các bước này về cơ bản là giống nhau bất kể bạn sử dụng phương pháp phát triển phần mềm nào. Tuy nhiên, như chúng ta sẽ thấy ở phần sau, thứ tự và trình tự mà chúng xảy ra có thể khác nhau tùy thuộc vào nhu cầu, mục tiêu và quy mô của dự án và đội ngũ nhân sự (ví dụ: một số bước có thể được kết hợp, sao chép hoặc chạy song song).

Phân Tích & Lên Kế Hoạch

Sau khi khách hàng hoặc bên liên quan yêu cầu một dự án, bước đầu tiên của Quy Trình Phát Triển Phần Mềm là lập kế hoạch. Điều này thường có nghĩa là xem xét:

• Sắp xếp: Làm thế nào để dự án này kết nối với sứ mệnh và mục tiêu của công ty bạn?
• Sự sẵn có và phân bổ nguồn lực: Doanh nghiệp có nhân sự và công cụ cần thiết để thực hiện việc này không? Hay bạn cần thuê ngoài phát triển?
• Lập kế hoạch dự án: Lên kế hoạch, timeline dự kiến cho dự án
• Ước tính chi phí: Nó sẽ có giá bao nhiêu, các chi phí gì?

Giai đoạn lập kế hoạch là bước đầu tiên nhưng cũng rất quan trọng quy trình phát triển phần mềm, giai đoạn này sẽ có sự tham gia của các bộ phần liên quan như: Product Owner, Project manager, Business Analyst, CTO. Tùy vào từng dự án mà thời gian cho giai đoạn phân tích lập kế hoạch sẽ có sự thay đổi khác nhau. Tuy nhiên để 1 dự án đảm bảo thành công, không có sự tranh cãi về sản phẩm thì giai đoạn này cần được làm chỉn chu và chi tiết nhất.

Xác Định Yêu Cầu

Bước tiếp theo là hiểu các yêu cầu kỹ thuật của dự án này. Mọi phần mềm, ngăn xếp công nghệ (tech stack), cho dù đó là ứng dụng, thiết kế lại trang web hay tính năng mới cần thiết để giải quyết vấn đề của khách hàng.Khi bạn chuyển từ giai đoạn lập kế hoạch và tiếp tục điền vào SOW, hãy tự hỏi bản thân và Đối tác CNTT của bạn xem liệu bạn có định thuê gia công phần mềm hay không, những câu hỏi này về các chi tiết cụ thể xung quanh dự án này, chẳng hạn như:

• Điều này giải quyết vấn đề gì?
• Ai sẽ sử dụng nó và tại sao?
• Loại dữ liệu đầu vào/đầu ra nào là cần thiết?
• Bạn có cần tích hợp với các công cụ hoặc API khác không?
• Bạn sẽ xử lý vấn đề bảo mật/riêng tư như thế nào?

Sau khi nhóm phát triển nhận được câu trả lời, họ có thể vạch ra các yêu cầu kỹ thuật và điều khoản thử nghiệm (Test Scenario) và quyết định ngăn xếp công nghệ (tech stack). Giai đoạn này cũng là lúc bạn có thể bắt đầu lập kế hoạch chạy nước rút (nếu bạn đang sử dụng quy trình phát triển phần mềm Agile) hoặc chia nhỏ các nhiệm vụ lớn thành các bước dễ thực hiện hơn.

Thiết Kế & Tạo Mẫu Thử

Với tất cả các yêu cầu đã có, đã đến lúc bắt đầu thiết kế phần mềm này sẽ trông như thế nào và nó sẽ hoạt động như thế nào.

Tùy thuộc vào quy trình phát triển phần mềm mà bạn đang theo dõi, giai đoạn này của SDLC có nghĩa là bạn tạo các wireframe đơn giản để hiển thị cách các tương tác sẽ được đưa vào hoặc tạo các nguyên mẫu chính thức hơn để thử nghiệm với người dùng. Ngoài ra, bạn có thể quyết định rằng bạn cần thêm phản hồi của người dùng và tạo một cuộc chạy nước rút thiết kế để nhanh chóng đưa một tính năng hoặc ý tưởng đến với người dùng của bạn.

Giai đoạn này giúp đội ngũ chuyên gia và khách hàng xác thực các ý tưởng và nhận phản hồi có giá trị trước khi đưa vào mã code. System Architect và UX/UI design sẽ tham gia trược tiếp vào giai đoạn này.

Phát Triển Phần Mềm

Với tất cả thành viên tham gia vào viedcj sản xuất phần mềm, đây là lúc xây dựng nó theo yêu cầu và SOW (Statement of Work – tài liệu chứa các yêu cầu về các nhiệm vụ cần thực hiện, phạm vi của dự án các tiêu chuẩn chất lượng, mục tiêu và các thời hạn cần thiết để hoàn thành dự án). Giai đoạn này rõ ràng là giai đoạn khó khăn nhất và có khả năng rủi ro cao nhất của SDLC (và mỗi quy trình phát triển phần mềm mà chúng tôi sẽ thảo luận bên dưới sẽ xử lý nó theo cách khác nhau).

Tuy nhiên, cho dù bạn đang làm việc trong Agile sprints, xây dựng MVP hay sử dụng mô hình thác nước Wallterfall Model thì bạn vẫn cần bám sát SOW, các kỹ sư Front-end và back-end sẽ cố gắng tránh đi chệch khỏi SOW và tạo phần mềm sạch, hiệu quả.

Kiểm Thử

Việc kiểm tra, theo dõi và khắc phục sự cố khi phát triển chương trình phần mềm là vô cùng cần thiết. Vì vậy, sau khi các tính năng được hoàn thiện và sản phẩm được tuyên bố là sẵn sàng hoạt động, bạn sẽ cần tiến hành nhiều thử nghiệm hơn. Ngoài ra, hãy sử dụng bản beta hoặc theo dõi cách người dùng tương tác với sản phẩm bằng các công cụ UX để tìm ra các vấn đề.

Mặc dù kiểm thử phần mềm sẽ chiếm nhiều thời gian trong Quy Trình Phát Triển Phần Mềm, nhưng điều quan trọng là sản phẩm bán ra phải hoàn thiện và không có lỗi. Các lỗi có thể hủy hoại danh tiếng của doanh nghiệp, tiêu tốn tiền bạc và tệ nhất là tốn thời gian để sửa chữa.

Đây là giai đoạn có sự tham gia của tất cả các bộ phận tham gia dự án.

Triển Khai Trên Môi Trường Khách Hàng Sử Dụng

Bây giờ bạn đã hoàn thành công việc nặng nhọc và mã hóa, đã đến lúc cung cấp phần mềm cho tất cả người dùng. Đưa mã của bạn vào sản xuất là những gì chúng ta đang nói đến ở đây. Việc đưa ra và thực hiện chiến lược tiếp cận thị trường tùy thuộc vào nhân viên bán hàng và tiếp thị của bạn.

Data Administrator và DevOps sẽ tham gia thực hiện triển khai trên 1 môi trường khách hàng sử dụng sản phẩm, có thể là cài đặt và truy cập trên máy tính.

Bảo Trì & Cập Nhật

Quy Trình Phát Triển Phần Mềm vẫn chưa kết thúc sau khi phần mềm của bạn được phát hành mở. Bạn có nhớ thuật ngữ “vòng đời” không? Sự kết thúc của một giai đoạn báo trước sự bắt đầu của giai đoạn tiếp theo và điều này cũng đúng đối với giai đoạn sau khi ra mắt.

Sau quá trình dùng thử, khách hàng sẽ đưa ra các mong muốn, chỉnh sửa, hoặc bổ sung các tính năng mới để đưa ra 1 sản phẩn hoàn hảo nhất, phù hợp với nhu cầu của họ.

Tất cả các yêu cầu này phải được chuyển trở lại Product Backlog, nơi chúng có thể được ưu tiên và đưa vào lộ trình sản phẩm.

Công ty Outsource hàng đầu cho doanh nghiệp

Nếu bạn đã đọc đến đây thì chắc hẳn đã phần nào tin tưởng vào dịch vụ của BMD Solutions. Trong nhiều năm hoạt động trên thị trường, chúng tôi đã có cơ hội hợp tác với hàng nghìn đối tác doanh nghiệp/ cá nhân trong và ngoài nước để tạo ra các sản phẩm công nghệ tân tiến nhất. Để làm được điều đó, chúng tôi luôn nỗ lực nâng cao chất lượng sản phẩm và hoàn thiện các quy trình phát triển phần mềm của mình.

Đặc biệt, BMD Solutions là công ty outsource, do đó, chúng tôi có thế mạnh hơn về mức giá. Bạn có thể yên tâm rằng mức giá lập trình chúng tôi đưa ra là cạnh tranh nhất trên thị trường. Với bất kỳ yêu cầu nào của quý khách hàng, BMD Solutions đều có thể đưa ra phương án tối ưu nhất. Hãy liên hệ trực tiếp với chúng tôi để có cơ hội hợp tác phát triển trong tương lai bạn nhé. Hân hạnh được phục vụ quý khách hàng.

Liên hệ ngay với chúng tôi để được tư vấn và báo giá trực tiếp:

CÔNG TY TNHH TƯ VẤN GIẢI PHÁP PHẦN MỀM BMD

Địa chỉ: 51 Thép Mới, Phường 12, Tân Bình, Thành phố Hồ Chí Minh

Hotline: 0357 415 495

Email: [email protected]

Website: https://bmdsolutions.vn

Phạm Trung Sơn hiện đang là CEO của công ty BMD Solutions có hơn 7 năm kinh nghiệm trong ngành lập trình, tư vấn giải pháp công nghệ cho doanh nghiệp

Quy trình phát triển phần mềm – itnavi.com.vn

Hiểu được quy trình phát triển phần mềm chuẩn chỉnh không chỉ giúp developers tạo ra được các sản phẩm chất lượng có hiệu quả cao mà còn mang lại cơ hội rộng lớn về nghề nghiệp trong ngành Công nghệ thông tin. Trong bài viết này, cùng ITNavi tìm hiểu về quy trình và mô hình phát triển phần mềm một cách tổng quan nhé!

Quy trình phát triển phần mềm – SDLC – Software Development Life Cycle

6 giai đoạn phát triển phần mềm

Theo quy tắc chung, quy trình SDLC sẽ bao gồm 6 bước:

Bước 1: Analysis (Lập kế hoạch và phân tích yêu cầu)

Trước khi bắt đầu xây dựng phần mềm, chúng ta cần thu thập và xác định rõ các yêu cầu của người dùng và các bên liên quan đối với sản phẩm phần mềm sắp xây dựng. Chúng ta cần nghiên cứu thị trường để xác định các chức năng mà phần mềm nên cung cấp cho người dùng để họ cảm thấy đây là phần mềm hữu ích cho họ. Việc nghiên cứu này cũng giúp ta xác định được khả năng tồn tại của phần mềm trên thị trường như thế nào?

Sau đó, các thành viên trong nhóm phát triển phần mềm sẽ làm việc cùng với khách hàng để đưa ra các thông số kỹ thuật và yêu cầu chi tiết về sản phẩm phần mềm dự định làm ra. Tất cả thông tin này sẽ được tổng hợp thành một tài liệu được gọi là tài liệu đặc tả yêu cầu phần mềm (Software Requirement Specification). Tài liệu sẽ bao gồm các yêu cầu về chức năng, giao diện, hiệu suất,… Ngoài ra, còn có cả bản phác thảo về thành phần, nhiệm vụ của từng developer và các thông số thử nghiệm để tạo nên một sản phẩm chất lượng.

Ở giai đoạn này, người quản lý và các nhà phát triển phần mềm sẽ thống nhất việc lựa chọn kiểu mô hình phát triển phần mềm nào (Các kiểu mô hình phát triển phần mềm sẽ được cụ thể trong phần tiếp theo)

Bước 2: Design (Thiết kế phần mềm)

Từ các yêu cầu và thông số kỹ thuật được đưa ra trong bước 1, các nhà phát triển phần mềm sẽ vạch ra kiến trúc tổng thể cần thiết để tạo ra phần mềm. Ngoài ra, các yếu tố như: ngân sách, thời gian, công nghệ áp dụng, mức độ rủi ro,… cũng được xác định rõ ràng.

Kết quả cuối cùng của giai đoạn này là các đặc điểm kỹ thuật thiết kế. Nó bao gồm các chỉ định về thiết kế kiến trúc, yêu cầu hệ thống cũng như đại diện Back-end, Front-end,… cho phép cả nhóm phát triển theo dõi toàn bộ quá trình phát triển nên phần mềm.

Bước 3: Development (Thực hiện)

Ở bước này, các nhà phát triển phần mềm sẽ bắt đầu viết code và triển khai các thông số thiết kế đã đưa ra ở bước 2. Cụ thể, các Front-end developer sẽ xây dựng phần giao diện của phần mềm. Các Back-end developer sẽ sử dụng các loại ngôn ngữ lập trình, framework để lập trình trên máy chủ và cùng với các quản trị viên cơ sở dữ liệu xử lý dữ liệu.

Sau khi hoàn tất việc coding, developers sẽ deploy (triển khai) sản phẩm trong môi trường phát triển. Lập trình viên sẽ tiến hành thử nghiệm sản phẩm và có sự điều chỉnh cho phù hợp với yêu cầu đã đưa ra.

Giai đoạn này thường chiếm khá nhiều thời gian và nhân lực trong toàn bộ quy trình phát triển phần mềm.

Bước 4: Testing (Kiểm thử phần mềm)

Sau khi hoàn tất phần lập trình phần mềm, sản phẩm sẽ tiếp tục chuyển cho các tester (người kiểm thử phần mềm). Các tester sẽ tạo ra các tình huống kiểm thử (test case) và tiến hành kiểm thử phần mềm. Mục đích của việc kiểm thử phần mềm là xác minh và đảm bảo chất lượng của sản phẩm đúng như yêu cầu để ra.

Sau khi kiểm thử, tester sẽ cập nhật các lỗi vào công cụ quản lý và thông báo các bug (lỗi) cho developers. Bước này, tester sẽ ngồi cùng với developers để xử lý các bug hiện có và cập nhật vào hệ thống quản lý lỗi. Tùy vào mô hình phát triển phần mềm được lựa chọn ở bước 1 mà hoạt động của developer và tester có thể tiến hành lần lượt hoặc diễn ra song song.

Bước 5: Deployment stage (Giai đoạn triển khai)

Sau khi hoàn tất kiểm thử, phần mềm không còn lỗi, các nhà phát triển sẽ triển khai sản phẩm trên Production environment (môi trường chứa ứng dụng thật, chạy với người dùng thật, dữ liệu thật) và cung cấp sản phẩm hoàn thiện cho khách hàng.

Sau khi đăng ký, thử nghiệm Beta sẽ được tiến hành để thu thập các phản hồi của người dùng thực tế để hoàn thiện chất lượng phần mềm khi triển khai ở quy mô lớn. Ở bước này, developer cũng cần phải lên kế hoạch chuẩn bị cho mọi trường hợp bất trắc có thể xảy ra để chủ động hơn trong việc giải quyết các sự cố bất ngờ.

Bước 6: Maintenance (Duy trì)

Sau khi phần mềm được đưa vào vận hành chính thức, khách hàng đã bắt đầu sử dụng phần mềm ở mức chất lượng cao nhất, bước tiếp theo chúng ta cần phải bảo trì sản phẩm. Công ty sẽ thành lập một nhóm chuyên về bảo trì và quản lý các vấn để người dùng gặp phải trong quá trình sử dụng sản phẩm. Họ sẽ quản lý và giải quyết tất cả các vấn để của người dùng gặp phải. Đồng thời, phần mềm cũng được cập nhật sau khi triển khai để loại bỏ các lỗi và cải thiện hiệu suất.

Quy trình phát triển phần mềm là gì?

Mọi hoạt động của một dự án phát triển phần mềm đều phải được lên kế hoạch, chia thành các giai đoạn và sắp xếp theo một trình tự hợp lý. Thứ tự này được gọi là quy trình phát triển phần mềm hoặc còn được gọi với cái tên là vòng đời phát triển phần mềm. Mỗi quá trình phát triển phần mềm đều là một bước quan trọng của quá trình phát triển một hệ thống, vì vậy đây là kiến thức căn bản nhất mà bất kỳ nhà phát triển, kiểm thử phần mềm nào cũng cần nắm được.

Quy trình phát triển càng tinh gọn và khoa học thì sản phẩm tạo ra càng tối ưu và hoạt động tốt hơn.

Tổng quan quy trình phát triển phần mềm

Theo định nghĩa từ Indeed, quy trình phát triển phần mềm (SDLC – Software Development Life Cycle) là toàn bộ quá trình xây dựng lên sản phẩm đáp ứng các thông số kỹ thuật và yêu cầu của người dùng. SDLC cung cấp một tiêu chuẩn quốc tế mà các công ty sản xuất phần mềm có thể sử dụng để xây dựng và cải tiến sản phẩm công nghệ. Một quy trình tốt sẽ luôn tạo ra những sản phẩm đạt tiêu chuẩn.

Quy trình được chia thành 6 bước và mỗi giai đoạn đều có sự tham gia của đội ngũ phát triển phần mềm. Quy trình giúp tương tác hóa các hoạt động và yếu tố với nhau một cách nhịp nhàng, đem lại hiệu quả trong quá trình sản xuất phần mềm. Chúng ta hãy cùng tìm kiểu rõ hơn về 6 bước này trong phần tiếp theo.

Mô hình Agile – Agile Model

Agile là một tập hợp các nguyên lý dành cho phát triển phần mềm, trong đó khuyến khích việc lập kế hoạch thích ứng, phát triển tăng dần, chuyển giao sớm, và cải tiến liên tục. Agile cũng chủ trương thích ứng nhanh chóng với các thay đổi. Những nguyên lý này được chia sẻ trong Tuyên ngôn Phát triển Phần mềm Linh hoạt và 12 Nguyên lý phía sau.

Agile không định nghĩa một phương pháp cụ thể để đạt được những điều này, nhưng lại có nhiều phương pháp phát triển phần mềm khác nhau thỏa mãn và hướng theo các tiêu chí đó.

Mục đích của các phương pháp Agile là giúp các doanh nghiệp đạt được sự linh hoạt (Agility), từ đó nâng cao sức cạnh tranh và phát triển bền vững. Các phương pháp Agile đã thay đổi diện mạo thế giới không chỉ trong Phát triển phần mềm mà còn đang thể hiện giá trị trong các lĩnh vực khác như Marketting (Agile Marketting), giáo dục (EduScrum, Lean Edu, v.v.), thiết kế (Lean UX, Design Thinking), khởi nghiệp (Lean Startup) và Phần cứng.

Áp dụng

Có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng nó cần sự tham gia và tính tương tác của khách hàng. Ngoài ra, nó có thể được sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn ( 3 tuần )

Đặc điểm

Ưu điểm:

Giảm thời gian cần thiết để tận dụng một số tính năng của hệ thống Kết quả cuối cùng là phần mềm chất lượng cao trong thời gian ít nhất có thể và sự hài lòng của khách hàng Nhược điểm:

Phụ thuộc vào kỹ năng của người phát triển phần mềm Scalability Tài liệu được thực hiện ở giai đoạn sau

Các bước chính của quy trình phát triển phần mềm

Ngoài các mô hình trên thì quá trình phát triển phần mềm cũng có thể được triển khai theo các mô hình khác như mô hình xoắn ốc Boehm, mô hình phát triển tiến hoá,… Nhưng dù theo mô hình nào đi chăng nữa thì các bước chính trong quá trình phát triển phần mềm vẫn không thay đổi.

Lập kế hoạch

Tại BMD Solutions, các quy trình phát triển phần mềm đều được tiến hành theo 7 bước nhằm đảm bảo chất lượng của sản phẩm tạo ra. Bước đầu tiên sau khi tiếp nhận yêu cầu của khách hàng, đội ngũ lập trình viên của chúng tôi sẽ tiến hành lên kế hoạch phát triển.

Thông thường với một dự án chúng tôi sẽ đưa ra ít nhất 3 kế hoạch nhằm giúp khách hàng có thêm nhiều lựa chọn và đề xuất được giải pháp tối ưu.

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

Tiếp đó, lập trình viên cần đi sâu vào từng bước, phân tích dữ liệu để cho ra báo cáo chi tiết nhất về kế hoạch phát triển phần mềm. Đây cũng là một trong những bước quan trọng nhất trong vòng đời phát triển phần mềm, nó góp phần quyết định chất lượng sản phẩm sau này. Và đó cũng chính là ưu điểm của BMD Solutions.

Thiết kế và tạo mẫu phần mềm

Với mỗi sản phẩm và yêu cầu cụ thể của quý khách hàng, đội ngũ kỹ thuật viên sẽ chịu trách nhiệm lên bản vẽ thiết kế sơ bộ cũng như tạo mẫu khung để định hình phần mềm. Tại bước này, chúng tôi sẽ thống nhất với khách hàng lần cuối để tiến hành lập trình sản phẩm. Trong quy trình phát triển phần mềm Agile thì đây sẽ là bước cầu nối cho tất cả các giai đoạn sau này.

Lập trình

BMD Solutions sử dụng công nghệ lập trình tiên tiến cùng các ngôn ngữ lập trình phổ biến nhằm tạo ra sản phẩm có khả năng tương tác cao trên thị trường. Chúng tôi có trách nhiệm thông báo cụ thể từng giai đoạn và phát sinh trong bước lập trình phần mềm và cam kết hoàn thành đúng sản phẩm theo thời gian thỏa thuận.

Thử nghiệm

Thử nghiệm là bước không thể thiếu trong vòng đời phát triển phần mềm. Để tạo ra một sản phẩm hoàn chỉnh, chúng tôi cần đưa sản phẩm vào thử nghiệm nhiều lần để đảm bảo kiểm soát được chất lượng và khắc phục sớm được các sai sót trong quá trình lập trình.

Triển khai dự án

Khi thống nhất được về chất lượng và khả năng hoạt động của phần mềm, BMD Solutions sẽ tiến hành bàn giao cho khách hàng để triển khai dự án.

Bảo trì

Sau quá trình bàn giao, chúng ta đến với bước cuối của các quá trình phát triển phần mềm. Tại bước này, đội ngũ kỹ thuật viên vẫn luôn theo sát hỗ trợ và sửa lỗi phát sinh của phần mềm trong quá trình sử dụng. Với mỗi sản phẩm làm ra, chúng tôi cam kết bảo hành, nâng cấp và cập nhật sản phẩm trọn đời giúp khách hàng có trải nghiệm tốt nhất khi sử dụng phần mềm.

Các hoạt động cơ bản của quy trình phát triển phần mềm

• Đặc tả phần mềm: Định nghĩa được các chức năng, điều kiện hoạt động của phần mềm.
• Phát triển phần mềm: Là quá trình xây dựng các đặc tả.
• Đánh giá phần mềm: Phầm mềm phải được đánh giá để chắc chắn rằng ít nhất có thể thực hiện những gì mà tài liệu đặc tả yêu cầu.
• Tiến hóa phần mềm: Đây là quá trình hoàn thiện các chức năng cũng như giao diện để ngày càng hoàn thiện phần mềm cũng như các yêu cầu đưa ra từ phía khách hàng.

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

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

Waterfall model – Mô hình thác nước

• Mô tả
  • Mô hình thác nước là mô hình áp dụng theo tính tuần tự của các giai đoạn phát triển phần mềm
  • Có nghĩa là: giai đoạn sau chỉ được thực hiện tiếp khi giai đoạn trước đã kết thúc
  • Không được quay lại giai đoạn trước để xử lí các thay đổi trong yêu cầu
  • Đây được coi là mô hình phát triển phần mềm đầu tiên.
• Áp dụng
  • Thường được áp dụng cho các dự án không thường xuyên bị thay đổi về yêu cầu.
• Đặc điểm
  • Ưu điểm:
    • Dễ sử dụng, dễ tiếp cận
    • Các giai đoạn và hoạt động được xác định rõ ràng
    • Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi
  • Nhược điểm:
    • Rất khó để quay lại giai đoạn nào khi nó đã kết thúc
    • Ít tính linh hoạt và phạm vi điều chỉnh của nó khá là khó khăn, tốn kém.
• Ưu điểm:

Tham khảo thêm: https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

V- Shaped Model- Mô hình chữ V

• Mô tả
  • Đây là mô hình mở rộng từ mô hình thác nước
  • Thay vì di chuyển xuống theo tuần tự các bước thì quy trình sẽ đi theo hình chữ V
• Áp dụng
  • Yêu cầu phần mềm phải xác định rõ ràng
  • Công nghệ phần mềm và các công cụ phải được tìm hiểu kĩ
• Đặc điểm
  • Ưu điểm:
    • Đơn giản dễ sử dụng
    • Phấn phối cụ thể theo mỗi giai đoạn
    • Thực hiện verification và validation sớm trong mỗi giai đoạn phát triển
  • Nhược điểm:
    • Phạm vi điều chỉnh khá là khó khăn và tốn kém.
• Ưu điểm:

Tham khảo thêm: https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

Spiral Model – Mô hình xoắn ốc

• Mô tả
  • Là mô hình kết hợp giữa các tính năng của mô hình prototyping và mô hình thác nước.
  • Mô hình xoắn ốc được ưa chuộng cho các dự án lớn, đắt tiền và phức tạp.
  • Mô hình này sử dụng nhiều những giai đoạn tương tự như mô hình thác nước, về thứ tự, plan, đánh giá rủi ro, …
• Áp dụng
  • Thường được sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn
• Đặc điểm
  • Ưu điểm:
    • Estimates (i.e. budget, schedule, etc.) trở nên thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan trọng đã được phát hiện sớm hơn.
    • Có sự tham gia sớm của deverlopers
    • Quản lý rủi ro và phát triển hệ thống theo phase
  • Nhược điểm:
    • Chi phí cao và thời gian dài để có sản phẩm cuối cùng
    • Phải có kỹ năng tốt để đánh giá rủi ro và giả định.
• Ưu điểm:

Tham khảo thêm: https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

Iterative Model- Mô hình tiếp cận lặp

Example:

Diagram:

• Mô tả
  • Một mô hình được lặp đi lặp lại từ khi start cho đến khi làm đầy đủ spec
  • Thay vì phát triển phần mềm từ spec đặc tả rồi mới bắt đầu thực thi thì mô hình này có thể review dần dần để đi đến yêu cầu cuối cùng.
  • Quy trình phát triển được lặp đi lặp lại cho mỗi một version của sản phẩm trong mỗi chu kỳ.
• Áp dụng
  • Yêu cầu của hề thống đã hoàn chỉnh, được xác định rõ ràng và dễ hiểu
  • Yêu cầu chính cần được xác định, và một số chi tiết có thể được đổi mới theo thời gian
• Đặc điểm
• • Ưu điểm:
    • Xây dựng và hoàn thiện các bước sản phẩm theo từng bước
    • Nhận được phản hồi của người sử dụng từ những bản phác thảo
    • Thời gian làm tài liệu sẽ ít hơn so với thời gian thiết kế
  • Nhược điểm:
    • Mỗi giai đoạn lặp lại thì cứng nhắc
    • Tốn kiến trúc hệ thống hoặc thiết kế các vấn đề có thể phát sinh nhưng không phải tất cả đều xảy ra trong toàn bộ vòng đời.
• Ưu điểm:

Tham khảo thêm: http://istqbexamcertification.com/what-is-incremental-model-advantages-disadvantages-and-when-to-use-it/https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

Incremental Model – Mô hình tăng trưởng

Example:

Diagram:

• Mô tả
  • Trong mô hình này thì spec được chia thành nhiều phần.
  • Chu kỳ được chia thành các module nhỏ, dễ quản lý.
  • Mỗi module sẽ đi qua các yêu cầu về thiết kế, thực hiện, … như 1 vòng đời phát triển thông thường.
• Áp dụng
  • Áp dụng cho những dự án có yêu cầu đã được mô tả, định nghĩa và hiểu một cách rõ ràng
  • Có nhu cầu về sản phẩm sớm
• Đặc điểm
  • Ưu điềm:
    • Phần mềm làm việc một cách nhanh chóng trong suốt vòng đời phát triền
    • Mô hình này linh hoạt hơn, ít tốn kém hơn để thay đổi phạm vi và yêu cầu
    • Dễ dàng hơn trong việc kiểm tra và sửa lỗi với sự lặp lại nhỏ hơn
  • Nhược điểm:
    • Cần lập plan và thiết kế tốt
    • Cần một định nghĩa rõ ràng và đầy đủ của toàn bộ hệ thống trước khi nó có thể được chia nhỏ và được xây dựng từng bước
    • Tổng chi phí là cao hơn so với thác nước.
• Ưu điềm:

Tham khảo thêm: https://melsatar.wordpress.com/2012/03/15/software-development-life-cycle-models-and-methodologies/

RAD Model (Rapid Application Development)

• Mô tả
  • Là một dạng của incremental model
  • Trong mô hình RAD các thành phần hoặc chức năng được phát triển song song như thể chúng là các dự án nhỏ
  • Việc phát triển này theo thời gian nhất định, cung cấp và lắp ráp thành một nguyên mẫu làm việc
  • Điều này có thể nhanh chóng đưa ra một cái gì đó cho khách hàng để xem và sử dụng và cung cấp thông tin phản hồi liên quan đến việc cung cấp và yêu cầu của họ.
• Áp dụng
  • RAD nên được sử dụng khi có nhu cầu để tạo ra một hệ thống có Modularized trong khoảng thời gian 2-3 tháng.
  • Nên được sử dụng khi đã có sẵn designer cho model và chi phí cao
  • Đặc điểm:
  • Ưu điềm:
    • Giảm thời gian phát triển.
    • Tăng khả năng tái sử dụng của các thành phần
    • Đưa ra đánh giá ban đầu nhanh chóng
    • Khuyến khích khách hàng đưa ra phản hồi
  • Nhược điểm:
    • Cần có một team giỏi để xác định yêu cầu phần mềm
    • Chỉ những hệ thống có module mới sứ dụng được mô hình này
    • Yêu cầu về dev/ design phải có nhiều kinh nghiệm
    • Phụ thuộc rất nhiều vào kỹ năng model

Tham khảo thêm Quy trình phát triển phần mềm: http://istqbexamcertification.com/what-is-rad-model-advantages-disadvantages-and-when-to-use-it/

Agile Model

• Mô tả
  • Dựa trên mô hình iterative and incremental
  • Các yêu cầu và giải pháp phát triển dựa trên sự kết hợp của các function
• Áp dụng
  • Nó có thể được sử dụng với bất kỳ loại hình dự án nào, nhưng nó cần sự tham gia và tính tương tác của khách hàng. Ngoài ra, nó có thể được sử dụng khi khách hàng yêu cầu chức năng sẵn sàng trong khoảng thời gian ngắn ( 3 tuần )
• Đặc điểm
  • Ưu điểm:
    • Giảm thời gian cần thiết để tận dụng một số tính năng của hệ thống
    • Kết quả cuối cùng là phần mềm chất lượng cao trong thời gian ít nhất có thể và sự hài lòng của khách hàng
  • Nhược điểm:
    • Phụ thuộc vào kỹ năng của người phát triển phần mềm Scalability
    • Tài liệu được thực hiện ở giai đoạn sau
    • Cần một team có kinh nghiệm Needs special skills for the team.
• Ưu điểm:

Tham khảo thêm Quy trình phát triển phần mềm: http://istqbexamcertification.com/what-is-rad-model-advantages-disadvantages-and-when-to-use-it/

Scrum (Scrum là một quy trình phát triển phần mềm thuộc họ agile)

Mô tả: Scrum là một phương pháp linh hoạt (agile), vì thế nó tuân thủ các nguyên tắc của Agile Manifesto (xem thêm Tuyên ngôn Agile). Ngoài ra Scrum hoạt động dựa trên ba giá trị cốt lõi, còn gọi là Ba chân của Scrum bao gồm Minh bạch, Thanh tra và Thích nghi.

• Scrum là gì? Cùng hiểu rõ về Scrum
• 18 công cụ quản lý dự án theo Agile
• Những điểm khác biệt giữa Kanban và Scrum
• Agile và văn hóa Việt Nam

6 giai đoạn phát triển phần mềm

Quy trình phát triển phần mềm bao gồm 6 giai đoạn: Needs identification (Xác định nhu cầu), Requirements Analytics (Phân tích yêu cầu), Design (Thiết kế), Development (Lập trình), Testing (Kiểm thử), Deployment & Maintenance (Triển khai & bảo trì).

Giai đoạn 1: Needs identification (Xác định nhu cầu)

Ngoài ra, developers cũng nên thảo luận cùng với các bộ phận khác trong công ty về : Điểm mạnh, điểm yếu và cơ hội của sản phẩm. Quá trình phát triển phần mềm chỉ bắt đầu nếu sản phẩm thỏa mãn được mọi thông số nhất thiết để thành công.

Xác định nhu cầu là giai đoạn 1 trong quy trình phát triển phần mềm.

Giai đoạn 2: Requirements Analytics (Phân tích yêu cầu)

Requirements Analytics là giai đoạn thực hiện khảo sát chi tiết yêu cầu, mong muốn của khách hàng. Sau đó, thông tin sẽ được tổng hợp vào tài liệu đặc tả yêu cầu ( Prototype). Tài liệu đặc tả phải đầy đủ các yêu cầu về chức năng, phi chức năng và giao diện. Ngoài ra, tài liệu còn cung cấp một bản phác thảo chi tiết về thành phần, phạm vi, nhiệm vụ của developers và các thông số thử nghiệm để tạo ra sản phẩm chất lượng.

Phân tích yêu cầu cũng là giai đoạn mà các developers lựa chọn cách tiếp cận phát triển phần mềm như: Mô hình chữ V (V Model) hay mô hình thác nước (Waterfall)

Giai đoạn 3: Design (Thiết kế)

Sau khi đã xác định & phân tích kỹ lưỡng về yêu cầu, chúng ta sẽ chuyển sang giai đoạn nắm vai trò quan trọng thiết yếu của Quy trình phát triển phần mềm – Design (thiết kế). Tại đây, các kiến trúc sư và nhà phát triển phần mềm sẽ đưa ra các thông số kỹ thuật tiên tiến mà họ cần để tạo ra sản phẩm theo yêu cầu. Vấn đề cần được thảo luận thêm giữa các bên bao gồm: Mức độ rủi ro, thành phần nhóm, công nghệ áp dụng, thời gian, ngân sách, giới hạn của dự án, phương pháp và thiết kế kiến trúc.

Tài liệu DSD (Đặc điểm kỹ thuật thiết kế) sẽ là kết quả cuối cùng của giai đoạn. DSD chỉ định thiết kế kiến trúc, thành phần, giao tiếp, đại diện front-end và luồng người dùng của sản phẩm.

Giai đoạn 4: Development (Lập trình)

Tại giai đoạn 4, developers sẽ lập trình và triển khai thông số thiết kế. Lập trình viên sẽ coding dựa trên các thông số kỹ thuật và yêu cầu của sản phẩm đã được thống nhất trong các giai đoạn trước.

Sau khi coding hoàn tất, developers sẽ deploy sản phẩm trong môi trường phát triển (development environment). Lập trình viên sẽ thử nghiệm phiên bản đã tạo ra và điều chỉnh lại cho phù hợp với yêu cầu.

Lập trình là giai đoạn thứ 4 của quy trình phát triển phần mềm.

Giai đoạn 5: Testing (Kiểm thử)

Sau khi developers đã hoàn thành giai đoạn lập trình, tester sẽ tiếp nhận sản phẩm và tiến hành testing. Tester sẽ tạo test case (Kịch bản kiểm thử) dựa trên tài liệu giải pháp tạo ở giai đoạn 2 và tiến hành kiểm tra. Tester sẽ cập nhật kết quả test vào tool quản lý và thông báo bug (lỗi) đến developers. Tester và developers sẽ cùng nhau phối hợp xử lý các bug và cập nhật trên hệ thống quản lý lỗi. Trong thực tế, tùy theo mô hình phát triển phần mềm mà hoạt động Develop và Kiểm Thử có thể diễn ra song song hoặc tiến hành lần lượt. Vì dụ như ở mô hình Waterfall, lập trình được thực hiện xong mới đến giai đoạn kiểm thử.

Giai đoạn 6: Deployment & Maintenance (Triển khai & bảo trì)

Tại giai đoạn này khi lỗi đã được xử lý xong, nhà phát triển phần mềm sẽ cung cấp sản phẩm hoàn chỉnh đến tay khách hàng. Testing vẫn được diễn ra ở giai đoạn triển khai để đảm bảo sản phẩm luôn có mức độ hoàn hảo cao. Sau khi phát hành, công ty sẽ tạo ra một nhóm bảo trì để quản lý các vấn đề mà khách hàng gặp phải khi sử dụng sản phẩm. Bảo trì giúp khắc phục nhanh các vấn đề nhỏ xảy ra trong quá trình sử dụng sản phẩm.

I- Quy Trình Phát Triển Phần Mềm Là Gì?

Kể từ những năm 50, khi chương trình máy tính đầu tiên được giới thiệu, vòng đời phát triển sản phẩm đã phát triển vượt bậc. Các nhà tiếp thị, quản lý dự án và nhà phát triển cần một quy trình thống nhất để ghi lại cái gì, khi nào và tại sao của mọi giai đoạn quá trình hình thành phần mềm. Đây là cách khái niệm về vòng đời phát triển phần mềm xuất hiện.

Vòng đời phát triển phần mềm (SDLC) là một Quy Trình Phát Triển Phần Mềm từng bước đưa ý tưởng của sản phẩm từ giai đoạn ý tưởng đến triển khai và cuối cùng là đưa ra thị trường. Thông thường, vòng đời phát triển phần mềm bao gồm các giai đoạn sau:

• Phân tích yêu cầu
• Lập kế hoạch
• Thiết kế phần mềm
• Phát triển phần mềm
• Thử nghiệm
• Triển khai
• Bảo trì & cập nhật

Mô hình thác nước – Waterfall model

Mô hình thác nước (tiếng Anh: waterfall model) là một mô hình của quy trình phát triển phần mềm, trong đó quy trình phát triển trông giống như một dòng chảy, với các pha được thực hiện theo trật tự nghiêm ngặt và không có sự quay lui hay nhảy vượt pha là: phân tích yêu cầu, thiết kế, triển khai thực hiện, kiểm thử, liên kết và bảo trì.

Các giai đoạn của mô hình thác nước

Thu thập yêu cầu (Requirement gathering) : Đây là giai đoạn xác định các yêu cầu chức năng và phi chức năng mà hệ thống phần mềm cần có. Kết quả của giai đoạn này là bản tài liệu đặc tả yêu cầu. Tài liệu này sẽ là nền tảng cho những giai đoạn tiếp theo cho đến cuối dự án.

Phân tích hệ thống ( System Analysis): Là giai đoạn định ra làm thế nào để hệ thống phần mềm đáp ứng đúng yêu cầu của khách hàng. Giai đoạn này thực hiện phân tích, thiết kế hệ thống phần mềm.

Coding: Là giai đoạn thực hiện sản phẩm dựa trên đặc tả yêu cầu và tài liệu thiết kế module.

Testing: Tester sẽ nhận sản phẩm từ dev và thực hiện kiểm thử cho nhóm các thành phần và kiểm thử hệ thống. Khâu kiểm thử cuối cùng sẽ là Kiểm thử chấp nhận, giai đoạn này còn có sự tham gia của khách hàng.

Implementation: Triển khai hệ thống ra môi trường của khách hàng.

Operations &Maintenance: Đây là giai đoạn cài đặt, cấu hình và đào tạo cho khách hàng. Giai đoạn này sửa chữa những lỗi của sản phẩm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu.

Áp dụng

Thường được áp dụng cho các dự án không thường xuyên bị thay đổi về yêu cầu.

Đặc điểm

Ưu điểm:

Dễ sử dụng, dễ tiếp cận Các giai đoạn và hoạt động được xác định rõ ràng Xác nhận ở từng giai đoạn, đảm bảo phát hiện sớm các lỗi Nhược điểm:

Rất khó để quay lại giai đoạn nào khi nó đã kết thúc Ít tính linh hoạt và phạm vi điều chỉnh của nó khá là khó khăn, tốn kém.

Tổng quan về quy trình phát triển phần mềm

• Một quy trình tốt và hợp lí luôn tạo ra những sản phẩm đạt tiêu chuẩn. Nó giúp tương tác hóa các hoạt động và yếu tố với nhau một các nhịp nhàng, đem lại hiệu quả.
• Có thể cho rằng quy trình phần mềm đem lại chất lượng, năng suất, giá thành phần phềm, từ đó tăng tính cạnh tranh và đem lại lợi nhuận cao cho doanh nghiệp.

Khái niệm Quy trình phát triển phần mềm

Quy trình phát triển phần mềm là một tập hợp các hoạt động tổ chức mà mục đích của chúng là xây dựng và phát triển phần mềm.

• Những câu hỏi được đặt ra ở đâu là:
  • Nhân sự: Ai sẽ làm? Ai làm gì?
  • Thời gian: Khi nào làm? Làm mất bao nhiêu thời gian?
  • Phương pháp: Làm như thế nào?
  • Công cụ: Dùng công cụ gì để làm công việc này?
  • Chi phí: Chi phí bỏ ra bao nhiêu? Thu về bao nhiêu? (ước tính)
  • Mục tiêu: Mục tiêu hướng đến là gì?
    • Mỗi loại hệ thống khác nhau thì cần những quy trình phát triển khác nhau.

Các hoạt động cơ bản của quy trình phát triển phần mềm

Có 4 thao tác là nền tảng của hầu hết các quy trình phát triển phần mềm:

• Đặc tả phần mềm: Định nghĩa được các chức năng, điều kiện hoạt động của phần mềm.
• Quy trình phát triển phần mềm: Là quá trình xây dựng các đặc tả.
• Đánh giá phần mềm: Phầm mềm phải được đánh giá để chắc chắn rằng ít nhất có thể thực hiện những gì mà tài liệu đặc tả yêu cầu.
• Tiến hóa phần mềm: Đây là quá trình hoàn thiện các chức năng cũng như giao diện để ngày càng hoàn thiện phần mềm cũng như các yêu cầu đưa ra từ phía khách hàng.

Mô hình xoắn ốc – Spiral Model

Mô hình xoắn ốc (tiếng Anh: spiral model) là quy trình phát triển định hướng rủi ro cho các dự án phần mềm. Kết hợp của thế mạnh của các mô hình khác và giải quyết khó khăn của các mô hình trước còn tồn tại. Dựa trên các mô hình rủi ro riêng biệt của mỗi dự án, mô hình xoắn ốc đưa ra cách áp dụng các yếu tố của một hoặc nhiều mô hình xử lý, chẳng hạn như mô hình gia tốc, mô hình thác nước hoặc mô hình tạo mẫu tiến hóa.

Các giai đoạn của mô hình xoắn ốc

Lập kế hoạch – Planning phase:

Thu thập, phân tích yêu cầu từ của dự án từ phía khách hàng. Bao gồm các công việc: Ước lượng chi phí (estimating cost), lên lịch trình thực hiện dự án (shedule-master), xác định số lượng nhân lực, môi trường làm việc (identifying necessary resources and work environment), tìm hiểu yêu cầu hệ thống (requirements) từ đó đưa ra các tài liệu đặc tả (Bussiness Requirement Specifications và System Requirement specifications) để phục vụ cho việc trao đổi giữa khách hàng và phân tích hệ thống sau này.

Phân tích rủi ro – Risk analysis phase:

Một quá trình phân tích sẽ được thực hiện để xác định rủi ro và đưa ra các giải pháp thay thế. Một prototype sẽ được tạo ra ở cuối giai đoạn phân tích rủi ro. Nếu có bất kỳ rủi ro nào được tìm thấy trong quá trình này thì các giải pháp thay thế sẽ được đề xuất và thực hiện.

Thực thi kỹ thuật – Engineering phase:

Đây là giai đoạn mà dự án được các dev tiến hành code, các tester tiến hành test và deploying software trên trang web của khách hàng.

Đánh giá – Evaluation phase:

Khách hàng sẽ tham gia vào giai đoạn này để đánh giá công việc, sản phẩm và đảm bảo rằng sản phẩm đáp ứng tất cả các yêu cầu đã đặt ra trước đó. Nếu có bất kỳ yêu cầu thay đổi nào từ khách hàng, các giai đoạn sẽ được lặp lại. Đây là giai đoạn quan trọng vì cần có sự phản hồi của khách hàng về sản phẩm trước khi sản phẩm được release.

Áp dụng

Thường được sử dụng cho các ứng dụng lớn và các hệ thống được xây dựng theo các giai đoạn nhỏ hoặc theo các phân đoạn

Đặc điểm

Ưu điểm:

Estimates (i.e. budget, schedule, etc.) trở nên thực tế hơn như là một quy trình làm việc, bởi vì những vấn đề quan trọng đã được phát hiện sớm hơn. Có sự tham gia sớm của deverlopers Quản lý rủi ro và phát triển hệ thống theo phase Nhược điểm:

Chi phí cao và thời gian dài để có sản phẩm cuối cùng Phải có kỹ năng tốt để đánh giá rủi ro và giả định.

Tổng quan[sửa | sửa mã nguồn]

Tiêu chuẩn quốc tế miêu tả các phương pháp cho việc lựa chọn, triển khai và giám sát vòng đời cho phần mềm là ISO/IEC 12207.

Một quá trình kéo dài hàng thập kỷ với mục tiêu tìm ra được các quy trình có tính lặp lại và có thể dự đoán trước được để cải thiện hiệu suất lao động và chất lượng sản phẩm. Một số người đã cố gắng hệ thống hóa hoặc hình thức hóa các nhiệm vụ viết phần mềm vốn không tuân theo quy tắc nào cả. Một số khác áp dụng các kỹ thuật quản lý dự án để viết phần mềm. Nếu như không có quản lý dự án, thì các dự án phần mềm có thể sẽ dễ bị chuyển giao chậm hoặc vượt quá ngân sách. Với một số lượng lớn các dự án phần mềm không đáp ứng được kỳ vọng về chức năng, chi phí hoặc kế hoạch chuyển giao đã cho thấy một thực tế là do đang thiếu các phương thức quản lý dự án hiệu quả.

Có 4 thao tác là nền tảng của hầu hết các quy trình phần mềm là:

1. Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được định nghĩa.
2. Sự phát triển phần mềm: Để phần mềm đạt được đặc tả thì phải có quy trình phát triển này.
3. Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó làm những gì mà khách hàng muốn.
4. Sự tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các yêu cầu của khách hàng.

Mô hình chữ V – V- Shaped Model

Mô hình V hiện nay là một trong những quy trình phát triển phần mềm được sử dụng rộng rãi nhất. Trong mô hình V việc thực hiện kiểm tra được diễn ra ngay từ giai đoạn lấy yêu cầu. V mô hình cũng được gọi là mô hình xác minh (verification) và mô hình xác nhận (validation).

Để hiểu được mô hình V, trước hết chúng ta hãy hiểu xác minh (verification) và xác nhận hợp lệ (validation) trong phần mềm là gì.

Xác minh (verification) : Xác minh là một kỹ thuật phân tích tĩnh. Trong kiểm thử, kỹ thuật này được thực hiện mà không phải chạy code. Nó bao gồm một số hoạt đông như xem lại (review), kiểm tra (inspection) và kiểm tra từ đầu tới cuối (walkthrough).

Xác nhận (validation): Xác nhận là một kỹ thuật phân tích động, trong đó việc kiểm thử được thực hiện bằng cách thực hiện code. Ví dụ bao gồm kỹ thuật kiểm tra chức năng (function) và phi chức năng (non-function).

Áp dụng

Yêu cầu phần mềm phải xác định rõ ràng Công nghệ phần mềm và các công cụ phải được tìm hiểu kĩ

Đặc điểm

Ưu điểm:

Đơn giản dễ sử dụng Phân phối cụ thể theo mỗi giai đoạn Thực hiện verification và validation sớm trong mỗi giai đoạn phát triển Nhược điểm:

Phạm vi điều chỉnh khá là khó khăn và tốn kém. Trong mô hình V, các hoạt động phát triển và đảm bảo chất lượng được thực hiện đồng thời. Không có pha rời rạc được gọi là kiểm thử, thay vào đó kiểm thử được bắt đầu ngay từ giai đoạn lấy yêu cầu. Các hoạt động xác minh và xác nhận đi liền với nhau.

So sánh mô hình Scrum và mô hình waterfall, Sprial

Đặc điểm	Waterfall	Spiral	Scrum
Xác định các giai đoạn phát triển	Bắt buộc	Bắt buộc	Chỉ có giai đoạn lập kế hoạch và kết thúc
Sản phẩm cuối cùng	Được xác định trong quá trình lập kế hoạch	Được xác định trong quá trình lập kế hoạch	Xác định trong suốt quá trình dự án
Chi phí sản xuất	Được xác định trong quá trình lập kế hoạch	Thay đổi cục bộ	Xác định trong quá trình xây dựng dự án
Ngày hoàn thành sản phẫm	Được xác định trong quá trình lập kế hoạch	Thay đổi cục bộ	Xác định trong quá trình xây dựng dự án

Via Techtalk

Có thể bạn muốn xem thêm:

• Tìm hiểu về Jira – Sử dụng JIRA để tối ưu quy trình như nào?
• Một số hàm thông dụng trong matlab để vẽ đồ thị
• Những nguyên lý đằng sau việc tối ưu một ứng dụng React

Xem thêm việc làm Developer tại TopDev!

7 Bước CƠ BẢN Trong Quy Trình Phát Triển Phần Mềm

Nếu bạn đang thắc mắc “Bao lâu thì thiết kế xong 1 phần mềm?” thì…

Biết về quy trình để làm phần mềm sẽ giúp bạn hiểu rõ hơn thời gian cần thiết để hoàn thiện 1 sản phẩm.

Mỗi phần mềm sẽ được tạo thành bởi một quy trình phát triển phần mềm riêng, tuỳ theo loại hình và công nghệ sử dụng mà các lập trình viên sẽ có cách áp dụng khác nhau.

Dưới đây là các thông tin chi tiết nhất về quá trình phát triển phần mềm mà bạn cần nắm vững.

Quy trình phát triển phần mềm: các phương pháp phổ biến

Mỗi phần mềm sẽ có tiêu chuẩn riêng mà theo đó các nhiệm vụ và thao tác sẽ diễn ra khác nhau, để cụ thể hoá các bước này, người ta xây dựng mô hình riêng cho mỗi quy trình. Cụ thể BMD Solutions sẽ chỉ ra một số loại quá trình phát triển phần mềm phổ biến dưới đây:

Mô hình thác nước

Mô hình này được áp dụng khi nhà phát triển muốn làm rõ ý nghĩa của việc sản xuất phần mềm, phù hợp với các dự án vừa và nhỏ. Bạn có thể hiểu đơn giản một phần mềm được thiết kế theo mô hình thác nước thì từng phần sẽ được diễn ra tuần tự theo từng giai đoạn: phân tích – thiết kế – thực hiện – thử nghiệm – sản xuất – bảo trì.

Ưu điểm của loại quy trình phát triển phần mềm này là tránh được sai sót do quy trình thực hiện rõ ràng. Tuy nhiên nhược điểm đi kèm với đó là tính linh hoạt kém, bạn chỉ có thể thử nghiệm sau khi đã thực hiện xong bước thiết kế phần mềm và nếu muốn thay đổi các bước trước đó thì hầu như là rất khó. Đó cũng chính là lý do người ta phát minh ra thêm mô hình chữ V.

Mô hình chữ V

Mô hình này được áp dụng khá nhiều trong các quá trình phát triển phần mềm. Mô hình chữ V là phiên bản cải tiến của mô hình thác nước. Phương pháp này giúp cho việc phát triển và kiểm thử diễn ra song song nhau, thông qua đó các lập trình viên có thể kiểm soát các công đoạn tốt hơn.

Bên cạnh đó, các kiểm thử viên (tester) cũng có thể tham gia kiểm thử ở ngay giai đoạn đầu của dự án và có thể phát hiện lỗi thiết kế từ rất sớm giúp đảm bảo chất lượng sản phẩm tốt hơn.

Mô hình Agile

Agile là một thuật ngữ bao trùm để chỉ tất cả các thực hành, khuôn khổ dựa trên sự phát triển lặp đi lặp lại, đây là một tập hợp các nguyên tắc cần tuân theo khi làm việc trong một dự án phát triển phần mềm.

Mọi người coi đây là một công cụ thay đổi cuộc chơi lớn cung cấp một phương pháp quản lý bổ sung.

Để áp dụng phương pháp này, dự án của bạn sẽ được tách thành nhiều gói nhỏ và có thể tiêu hao được và phải hoàn thành trong một khung thời gian. Quá trình, hầu hết thời gian là yêu cầu -> thiết kế -> phát triển -> thử nghiệm -> xem xét, sẽ được lặp lại hết lần này đến lần khác.

Hơn nữa, mọi thứ phải minh bạch, hợp tác và dễ dàng thích ứng cho tất cả các thành viên.

Điều này có nghĩa là, ví dụ, nhà thiết kế sẽ cho mọi người trong nhóm biết bản thảo của họ xuất hiện như thế nào theo yêu cầu từ nhà phân tích kinh doanh. Bằng cách này, những người khác có thể giải quyết ý kiến đóng góp hoặc phê bình của họ một cách cởi mở và mang tính xây dựng. Kết quả là giai đoạn sau có thể được thực hiện tốt hơn.

Bằng cách áp dụng phát triển phần mềm Agile, nhóm của bạn có thể trở nên linh hoạt và thích ứng với những thay đổi. Chúng sẽ hoạt động hiệu quả hơn và đảm bảo phần mềm sẽ hoạt động đúng giờ.

Ngày nay, hai framework phát triển phần mềm Agile phổ biến nhất là Scrum và Kanban nhưng Scrum chiếm phần lớn hơn trong miếng bánh này ở đây là 58% so với 5% thuộc về Kanban.

Quy trình phát triển phần mềm là gì?

Quy trình phát triển phần mềm còn được gọi là SDLC (Software Development Life Cycle). Quy trình này bao gồm các hành động được thực hiện theo một thứ tự nhất định để xây dựng và cung cấp một sản phẩm có thể đáp ứng được yêu cầu về kỹ thuật và phục vụ cho việc kinh doanh.

SDLC cung cấp một khuôn khổ để các nhà phát triển phần mềm và kỹ sư có thể sử dụng trong suốt một dự án phát triển phần mềm. Cụ thể, bằng việc tuân thủ đúng theo các giai đoạn được xác định rõ ràng của SDLC, tất cả thành viên trong nhóm dự án đều nắm được trách nhiệm, mục tiêu và lịch trình của dự án. Việc này giúp cho nhóm làm việc hiệu quả, có thể tạo ra sản phẩm phần mềm chất lượng cao và đúng hạn như dự kiến.Vậy quy trình này có bao nhiêu giai đoạn và trong từng giai đoạn phát triển phần mềm sẽ diễn những công việc gì? Cùng VTC Academy tìm hiểu ngay trong phần tiếp theo.

III- 5 Mô Hình Phát Triển Phần Mềm Phổ Biển Hiện Nay

Mục đích chính của Vòng đời phát triển phần mềm là cung cấp sự phát triển phần mềm chất lượng cao trong thời gian và giá cả hạn chế. Do đó, các quy trình phát triển phần mềm khác nhau tùy thuộc vào các phương pháp quản lý như Waterfall hoặc Agile. Và chúng ta sẽ tìm hiểu thêm về 05 Phương pháp hàng đầu bên dưới.

Mô Hình Thác Nước (Waterfall Model)

Mô hình thác nước (Waterfall) là mô hình và phương pháp tiếp cận vòng đời phát triển phần mềm đầu tiên được giới thiệu để xây dựng phần mềm. Trong mô hình này, mỗi giai đoạn phải được hoàn thành trước khi bắt đầu giai đoạn tiếp theo vì không có sự chồng chéo trong các giai đoạn.

Mô hình thác nước là một phương pháp quản lý dự án dựa trên quy trình thiết kế tuần tự và liên tiếp. Do đó, nó còn được gọi là mô hình vòng đời tuần tự tuyến tính, dễ sử dụng và dễ hiểu.

Mô Hình Chữ V (V Model)

Quy trình phát triển phần mềm chữ V là một bước ngoặt đối với phương pháp Thác nước truyền thống bù đắp cho khuyết điểm chính của nó: thiếu thử nghiệm. Thay vì làm việc tuần tự trong suốt quá trình phát triển và để lại tất cả các thử nghiệm cho đến khi kết thúc, mỗi giai đoạn của quy trình hình chữ V có một bước “xác nhận và xác minh” nghiêm ngặt, trong đó các yêu cầu được kiểm tra trước khi tiếp tục.

Quy trình:

• Lập kế hoạch
• Xác định yêu cầu
• Thiết kế hệ thống và phần mềm
• Thực hiện
• Kiểm thử
• Triển khai
• Bảo trì/Cập nhật

Áp dụng:

Mô hình thác nước cung cấp nguyên tắc quản lý dự án và đưa ra kết quả rõ ràng vào cuối mỗi giai đoạn. Tuy nhiên, có rất ít cơ hội để thay đổi sau khi một giai đoạn được coi là hoàn thành, vì những thay đổi có thể ảnh hưởng đến thời gian, chi phí và chất lượng phân phối của phần mềm. Do đó, mô hình phù hợp nhất cho các dự án phát triển phần mềm nhỏ, nơi mà các tác vụ dễ sắp xếp và quản lý và các yêu cầu có thể được xác định trước một cách chính xác.

Mô Hình Agile (Agile Model)

Quy trình phát triển phần mềm Agile (và phương pháp nổi bật nhất của nó, Scrum) ủng hộ cách tiếp cận phát triển năng động và lặp đi lặp lại.

Trái ngược với quy trình tuần tự, chặt chẽ của phương pháp thác nước, các nhóm Agile đa chức năng làm việc trong “Sprints” từ 2 tuần đến 2 tháng để xây dựng và phân phối phần mềm có thể sử dụng được cho khách hàng để lấy ý kiến phản hồi.

Quy Trình Phát Triển Phần Mềm Agile là phương pháp di chuyển nhanh chóng, phát hành thường xuyên và đáp ứng nhu cầu thực sự của người dùng, ngay cả khi nó mâu thuẫn với chiến lược ban đầu của bạn. Điều này có nghĩa là bạn không cần hoàn thành các yêu cầu và SOW chi tiết trước khi bắt đầu công việc. Thay vào đó, bạn đang đi theo một hướng một cách hiệu quả với kỳ vọng sẽ thay đổi hướng trên đường đi.

Quy trình:

• Tạo Product backlog
• Tạo Sprint backlog
• Triển khai Sprint (Thiết kế & Phát triển)
• Phát hành phần mềm đã hoạt động
• Phản hồi và xác nhận (thêm vào backlog)
• Lập kế hoạch Sprint tiếp theo

Áp dụng:

Agile cho phép các công ty di chuyển nhanh hơn và thử nghiệm các lý thuyết mà không gây nguy hiểm cho công việc kinh doanh của doanh nghiệp đối với một bản phát hành lớn, vì việc thực hiện các bản phát hành nhỏ và thu thập thông tin đầu vào của người dùng trở nên dễ dàng hơn. Hơn nữa, vì quá trình thử nghiệm diễn ra sau mỗi lần lặp lại nhỏ, nên việc theo dõi các lỗi hoặc quay trở lại phiên bản sản phẩm trước đó sẽ dễ dàng hơn nếu có sự cố nghiêm trọng hơn.

Mô Hình Xoắn Ốc (Spiral Model)

Mô hình xoắn ốc kết hợp các chu kỳ nhỏ lặp đi lặp lại của mô hình lặp lại với dòng tuần tự tuyến tính của mô hình thác nước để ưu tiên phân tích rủi ro. Bạn có thể sử dụng mô hình xoắn ốc để đảm bảo phát hành dần dần và cải tiến phần mềm bằng cách xây dựng nguyên mẫu ở mỗi giai đoạn.

Quy trình:

• Lập kế hoạch
• Đánh giá rủi ro
• Phát triển và xác nhận
• Đánh giá kết quả và lập kế hoạch cho “vòng lặp” tiếp theo

Áp dụng:

Mô hình xoắn ốc phù hợp với các dự án lớn và phức tạp, đòi hỏi phải thay đổi thường xuyên. Tuy nhiên, nó có thể tốn kém cho các dự án nhỏ hơn với phạm vi hạn chế.

Mô Hình Tiếp Cận Lặp (Iterative Model)

Mô hình tiếp cận lặp là một quá trình kết hợp phương pháp thiết kế lặp với mô hình xây dựng tăng dần. Nó được sử dụng bởi các nhà phát triển phần mềm để giúp quản lý các dự án.

Để hiểu đầy đủ về quy trình phát triển gia tăng và lặp đi lặp lại, trước tiên bạn phải chia nó thành hai phần:Gia tăng: Cách tiếp cận gia tăng chia quy trình phát triển phần mềm thành các phần nhỏ, có thể quản lý được gọi là gia tăng. Mỗi phần gia tăng được xây dựng trên phiên bản trước để các cải tiến được thực hiện từng bước.

Lặp lại: Một mô hình lặp lại có nghĩa là các hoạt động phát triển phần mềm được lặp lại một cách có hệ thống theo các chu kỳ được gọi là các lần lặp lại. Một phiên bản mới của phần mềm được tạo ra sau mỗi lần lặp cho đến khi đạt được sản phẩm tối ưu.

Áp dụng:

Mô hình tiếp cận lặp có thể được sử dụng khi hầu hết các yêu cầu đều được biết trước nhưng dự kiến sẽ phát triển theo thời gian. Ngoài ra, nó có thể áp dụng trong những dự án có thời gian phát triển dài hay sử dụng những công nghệ mới, hoặc cho sản phẩm thuộc một lĩnh vực mới đối với đội ngũ phát triển.

Savvycom – Đối Tác Công Nghệ Hàng Đầu Tại Việt nam

Thành lập từ 2009, Savvycom là một trong những công ty Công nghệ thông tin hàng đầu tại Việt Nam, chuyên cung cấp các dịch vụ tư vấn chuyển đổi số và giải pháp phần mềm trong lĩnh vực tài chính, y tế và bán lẻ cho các doanh nghiệp trong nước và quốc tế. Với mong muốn góp phần nâng cao vị thế của Việt Nam trên bản đồ công nghệ thông tin toàn cầu, Savvycom hướng đến sứ mệnh đưa công nghệ đổi mới vào cuộc sống bằng cách tận dụng nguồn lực lao động kỹ thuật tại Việt Nam, và tầm nhìn trở thành công ty CNTT hàng đầu trong khu vực ASEAN.

Liên lạc với chúng tôi qua, hoặc gửi yêu cầu của bạn trực tiếp tại Form liên lạc:

• Điện Thoại: +84 24 3202 9222
• Hotline: +84 352 287 866 (VN)
• Email: [email protected]

CÁC QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Nội dung chính

• 1. Quy trình phát triển phần mềm là gì?
• 2. Một số mô hình cho việc xây dựng quy trình phát triển phần mềm.

Bên cạnh khái niệm về kiểm thử phần mềm, để nắm vững chuỗi các kiến thức cần thiết cho 1 Tester, Hybrid Technologies sẽ giới thiệu cho các bạn về các quy trình phát triển phần mềm.

Đây là 1 kiến thức rất quan trọng và cần thiết không chỉ Tester cần hiểu rõ mà ngay cả các Developer cũng cần phải biết đến.

Quy trình phát triển phần mềm là gì?

Quy trình phát triển phần mềm là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất ra một sản phẩm phần mềm. Nhìn chung, một quy trình phát triển phần mềm bao gồm các giai đoạn như sau:

1.Giải pháp, yêu cầu

Nhiệm vụ: Thực hiện khảo sát chi tiết yêu cầu của khách hàng để từ đó tổng hợp vào tài liệu giải pháp. Tài liệu này phải mô tả đầy đủ các yêu cầu về chức năng, phi chức năng và giao diện.

Kết quả: Đầu ra của giai đoạn này là Tài liệu đặc tả yêu cầu

1.Thiết kế:

Nhiệm vụ: Thực hiện thiết kế và tổng hợp vào tài liệu thiết kế.

Kết quả: Tài liệu thiết kế tổng thể, thiết kế module, thiết kế CSDL

1.Lập trình

Nhiệm vụ: Lập trình viên thực hiện lập trình dựa trên tài liệu Giải pháp và Thiết kế đã được phê duyệt.

Kết quả: Source code.

1.Kiểm thử

Nhiệm vụ: Tester tạo kịch bản kiểm thử (test case) theo tài liệu đặc tả yêu cầu, thực hiện kiểm thử và cập nhật kết quả vào kịch bản kiểm thử, log lỗi trên các tool quản lý lỗi.

Kết quả: Test case , lỗi trên hệ thống quản lý lỗi.

1.Triển khai

Nhiệm vụ: Triển khai sản phẩm cho khách hàng.

Kết quả: Biên bản triển khai với khách hàng.

Một số mô hình cho việc xây dựng quy trình phát triển phần mềm.

Có rất nhiều mô hình phát triển phần mềm nhưng trong bài viết này, mình sẽ giới thiệu 3 mô hình phát triển phần mềm phổ biến nhất đó là: Mô hình thác nước, Mô hình chữ V, Mô hình Agile (Phương pháp Scrum).

2.Mô hình thác nước

Mô hình này gồm các giai đoạn xử lý nối tiếp nhau như sau:

• Thu thập yêu cầu (Requirement gathering): Đây là giai đoạn xác định các yêu cầu chức năng và phi chức năng mà hệ thống phần mềm cần có. Kết quả của giai đoạn này là bản tài liệu đặc tả yêu cầu. Tài liệu này sẽ là nền tảng cho những giai đoạn tiếp theo cho đến cuối dự án.
• Phân tích hệ thống ( System Analysis): Là giai đoạn định ra làm thế nào để hệ thống phần mềm đáp ứng đúng yêu cầu của khách hàng. Giai đoạn này thực hiện phân tích, thiết kế hệ thống phần mềm.
• Coding: Là giai đoạn thực hiện sản phẩm dựa trên đặc tả yêu cầu và tài liệu thiết kế module.
• Testing: Tester sẽ nhận sản phẩm từ developer và thực hiện kiểm thử cho nhóm các thành phần và kiểm thử hệ thống. Khâu kiểm thử cuối cùng sẽ là Kiểm thử chấp nhận, giai đoạn này còn có sự tham gia của khách hàng.
• Implementation: Triển khai hệ thống ra môi trường của khách hàng.
• Operations & Maintenance: Đây là giai đoạn cài đặt, cấu hình và đào tạo cho khách hàng. Giai đoạn này sửa chữa những lỗi của sản phẩm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu.

Đặc điểm:

Thường áp dụng cho các phần mềm có quy mô vừa và nhỏ.

Các dự án có yêu cầu rõ ràng, ít thay đổi.

Nguồn lực được đào tạo và sẵn sàng.

Ưu điểm: Vì có yêu cầu rõ ràng nên dễ hiểu, dễ áp dụng. Dễ phân công công việc, bố trí , giám sát

Nhược điểm: Thực tế cho thấy rằng đến những giai đoạn cuối cùng của dự án mới có khả năng nhận ra sai sót trong những giai đoạn trước để có thể quay lại sửa chữa.

2.Mô hình chữ V

• Hoạt động tốt với các dự án có quy mô vừa và nhỏ.
• Dễ dàng quản lý vì mỗi giai đoạn có các mục tiêu và mục tiêu được xác định rõ ràng.
• Toàn bộ quy trình được chia thành 2 nhóm giai đoạn tương ứng nhau là phát triển và kiểm thử. Mỗi giai đoạn phát triển sẽ tiến hành song song với một giai đoạn kiểm thử tương ứng. Do đó, các lỗi được phát hiện sớm ngay từ đầu.

Ưu điểm

Ngay từ lúc nhận được tài liệu đặc tả yêu cầu, tester sẽ tham gia vào review tài liệu đặc tả yêu cầu sau đó lên kế hoạch và thực hiện viết test case. Lỗi được phát hiện từ giai đoạn này sẽ ít tốn thời gian và chi phí hơn các giai đoạn sau.

Nhược điểm

Trong mô hình chữ V, các yêu cầu vẫn được đưa vào thực hiện cùng 1 lúc mà rủi ro về thay đổi yêu cầu từ phía khách hàng là rất lớn. Do đó, mô hình này vẫn có thể gặp rắc rối khi khách hàng thường xuyên thay đổi yêu cầu.

2.Mô hình Agile: quy trình Scrum

Agile là một phương pháp phát triển phần mềm linh hoạt để làm sao đưa sản phẩm đến tay người dùng càng nhanh càng tốt.

2.3.Đặc trưng của Agile?

Tính lặp (Interactive): Dự án sẽ được thực hiện trong các phân đoạn lặp đi lặp lại. Các phân đoạn (được gọi là Interation hoặc Sprint) này thường có khung thời gian ngắn ( từ 1 đến 4 tuần) . Trong mỗi phân đoạn này , nhóm phát triển phải thực hiện đầy đủ các công việc cần thiết như lập kế hoạch, phân tích yêu cầu, thiết kế, triển khai, kiểm thử để cho ra các phần nhỏ của sản phẩm. Các phân đoạn Sprint lặp đi lặp lại trong Agile: các phương pháp Agile thường phân rã mục tiêu thành các phần nhỏ với quá trình lập kế hoạch đơn giản và gọn nhẹ nhất có thể, không thực hiện lập kế hoạch dài hạn.

Tính tiệm tiến và tiến hóa: Cuối các phân đoạn Sprint, nhóm phát triển thường cho ra các phần nhỏ của sản phẩm cuối cùng. Các phần nhỏ này thường đầy đủ, có khả năng chạy tốt, được kiểm thử cẩn thận và có thể sử dụng được ngay. Theo thời gian, các phân đoạn này nối tiếp các phân đoạn kia, các phần chạy được tích lũy và lớn dần lên cho tới khi toàn bộ yêu cầu của khách hàng được thỏa mãn.

Tính thích ứng: Do các sprint chỉ kéo dài trong khoảng 1 thời gian ngắn và việc lập kế hoạch cũng được điều chỉnh liên tục, nên các thay đổi trong quá trình phát triển đều có thể áp dụng theo cách thích hợp. Theo đó, các quy trình Agile thường thích ứng rất tốt với các thay đổi.

2.3.Scrum là gì?

Scrum là một quy trình phát triển phần mềm theo mô hình linh hoạt. Vì thế, nó tuân thủ các nguyên tắc của Agile Scrum rất linh hoạt như các phương pháp Agile khác. Nhờ đó nó mang lại tính thích nghi rất cao. Dựa trên các thông tin minh bạch hóa từ các quá trình thanh tra và làm việc, Scrum có thể phản hồi lại các thay đổi một cách tích cực, nhờ đó mang lại thành công cho dự án.

Các công cụ (artifacts) Scrum:

Product backlog: Đây là danh sách ưu tiên các tính năng (feature) hoặc đầu ra khác của dự án, có thể hiểu như là danh sách yêu cầu (requirement) của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục (Product Backlog Item) trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa

Sprint backlog: Đây là bản kế hoạch cho một Sprint, là kết quả của buổi họp lập kế hoạch (Sprint Planning). Với sự kết hợp của Product Owner, nhóm sẽ phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc (TODO list).

• Product Owner tạo ra Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp theo thứ tự ưu tiên. Đội sản xuất sẽ thực hiện việc hiện thực hóa dần các yêu cầu của Product Owner với sự lặp đi lặp lại các giai đoạn từ 1 đến 4 tuần làm việc (gọi là Sprint) với đầu vào là các hạng mục trong Product Backlog, đầu ra là các gói phần mềm hoàn chỉnh có thể chuyển giao được (Potentially Shippable Product Increment)
• Đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint. Kết quả của buổi lập kế hoạch (theo cách làm của Scrum) là Sprint Backlog chứa các công việc cần làm trong suốt một Sprint.
• Các Sprint sẽ được lặp đi lặp lại cho tới khi nào các hạng mục trong Product Backlog đều được hoàn tất
• Trong suốt quá trình phát triển, nhóm sẽ phải cập nhật Sprint Backlog và thực hiện công việc họp hằng ngày (Daily Scrum) để chia sẻ tiến độ công việc cũng như các vướng mắc trong quá trình làm việc cùng nhau. Nhóm được trao quyền để tự quản lí và tổ chức lấy công việc của mình để hoàn thành công việc trong Sprint.
• Khi kết thúc Sprint, nhóm tạo ra các gói phần mềm có chức năng hoàn chỉnh, sẵn sàng chuyển giao (shippable) cho khác hàng. Buổi họp Sơ kết Sprint (Sprint Review) ở cuối Sprint sẽ giúp khách hàng thấy được nhóm đã có thể chuyển giao những gì, còn những gì phải làm hoặc còn gì phải thay đổi hay cải tiến.
• Sau khi kết thúc việc đánh giá Sprint, Scrum Master và nhóm cùng tổ chức họp Cải tiến Sprint (Sprint Retrospective) để tìm kiếm các cải tiến trước khi Sprint tiếp theo bắt đầu, điều này sẽ giúp nhóm liên tục học hỏi và trưởng thành qua từng Sprint.

Bao gồm 4 cuộc họp như sau:

1. Sprint Planning (Họp Kế hoạch Sprint): Nhóm phát triển họp với Product Owner để lên kế hoạch làm việc cho một Sprint. Công việc lập kế hoạch bao gồm việc chọn lựa các yêu cầu cần phải phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các tác vụ. Scrum sử dụng cách thức lập kế hoạch từng phần và tăng dần theo thời gian, theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với các tình hình thực tiễn trong tiến trình đi đến sản phẩm.

2. Daily Scrum (Họp Scrum hằng ngày): Scrum Master tổ chức cho Đội sản xuất họp hằng ngày trong khoảng 15 phút để Nhóm Phát triển chia sẻ tiến độ công việc Trong cuộc họp này, từng người trong nhóm phát triển lần lượt trình bày để trả lời 3 câu hỏi sau:

• Hôm qua đã làm gì?

• Hôm nay sẽ làm gì?

• Có khó khăn trở ngại gì không?

3. Sprint Review (Họp Sơ kết Sprint): Cuối Sprint, nhóm phát triển cùng với Product Owner sẽ rà soát lại các công việc đã hoàn tất (DONE) trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm.

4. Sprint Retrospective (Họp Cải tiến Sprint): Dưới sự trợ giúp của Scrum Master, nhóm phát triển sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm.

Bao gồm 3 vai trò:

1. Product Owner: Là người chịu trách nhiệm về sự thành công dự án, người định nghĩa các yêu cầu cho sản phẩm và đánh giá đầu ra cuối cùng của các nhà phát triển phần mềm.

2. Scrum Master: Là người đảm bảo các sprint được hoàn thành theo đúng quy trình Scrum, giúp đỡ loại bỏ các trở ngại cho đội dự án.

3. Development Team: Là tập hợp của từ 5 đến 9 thành viên chịu trách nhiệm trực tiếp tham gia sản xuất. Tùy theo quy mô của dự án để bố trí số thành viên cho phù hợp.

Ưu điểm

• Phù hợp với các yêu cầu / nghiệp vụ hay thay đổi, hoặc hệ thống nghiên cứu do làm theo từng giai đoạn ngắn ngày, có thể nhìn thấy những rủi ro hay những điểm chưa phù hợp để thay đổi.

Nhược điểm

• Thiếu sự nhấn mạnh về thiết kế và tài liệu cần thiết

• Quy mô nhân lực thường giới hạn , sẽ có trở ngại lớn nếu nguồn nhân lực yêu cầu vượt quá con số này ví dụ trong các cuộc họp trao đổi.

• Yêu cầu nguồn nhân lực phải có kiến thức và am hiểu về Agile

Như vậy, trên đây là những kiến thức về các quy trình phát triển phần mềm phổ biến hiện. Trong quá trình tìm hiểu nếu có bất kỳ ý kiến đóng góp nào, vui lòng comment bên dưới. Chúc các bạn một ngày học tập và làm việc hiệu quả!

Nguồn: Viblo.

Các mô hình phát triển phần mềm phổ biến hiện nay

Waterfall

Đặc điểm

• Áp dụng theo trình tự nhất định của các giai đoạn phát triển phần mềm.
• Bước tiếp theo không thể bắt đầu nếu bước trước chưa hoàn thành.
• Mỗi giai đoạn đều được ghi chép lại một cách chặt chẽ.
• Chỉ có thể kiểm thử ở giai đoạn hoàn thiện sản phẩm cuối cùng nên việc kiểm tra thường diễn ra gấp rút. Do đó mà việc sửa lỗi cũng gặp nhiều khó khăn, tốn kém và mất thời gian.

Áp dụng

• Các dự án có quy mô vừa và nhỏ với các yêu cầu được đưa ra rõ ràng và không thay đổi.
• Các dự án yêu cầu kiểm soát chặt chẽ, ngân sách có thể dự đoán trước.
• Các dự án cần tuân theo nhiều nguyên tắc và quy định khác nhau như các dự án về chăm sóc sức khỏe.

V-Model (Mô hình chữ V)

Đặc điểm

• Là mô hình tuyến tính, mỗi giai đoạn đều có một lần chạy thử nghiệm. Có nghĩa là tiến hành song song 2 hoạt động: phát triển và kiểm thử.
• Mô hình có tính kỷ luật cao. Giai đoạn tiếp theo chỉ có thể bắt đầu khi giai đoạn trước hoàn thành.
• Việc tester được tham gia ngay từ đầu nên lỗi được tìm ra từ sớm dễ khắc phục.

Áp dụng

• Các dự án yêu cầu không có lỗi và thời gian chết như các phần mềm dùng trong y tế hay phần mềm quản lý chuyến bay.
• Các dự án ngắn. Công nghệ không có sự thay đổi và được nhóm phát triển dự án hiểu rõ.

Iterative and Incremental model (Mô hình tiếp cận lặp)

Đặc điểm

• Mô hình được lặp đi lặp lại từ khi bắt đầu cho đến khi hoàn thành đầy đủ các thông số kỹ thuật.
• Cuối mỗi lần lặp, một phiên bản mới của phần mềm sẽ được tạo ra.
• Mỗi lần lặp lại phần mềm vẫn được xây dựng dựa trên lần lặp trước đó nên thiết kế phần mềm vẫn đảm bảo tính nhất quán.
• Vì phần mềm được chia thành từng phần nên không cần phải có đặc tả kỹ thuật hoàn chỉnh ngay từ đầu và các yêu cầu có thể thay đổi một chút trong quá trình phát triển phần mềm.
• Mô hình yêu cầu phải có sự tham gia của khách hàng.

Áp dụng

• Phù hợp cho các dự án lớn
• Những dự án về công nghệ mới có thời gian để nhóm phát triển phần mềm có thể học tập thêm.

Agile Methodologies (Mô hình Agile)

Đặc điểm

• Tập trung vào việc phát triển lặp đi lặp lại, giao tiếp liên tục và nhận phản hồi sớm từ khách hàng để cải thiện tốt hơn.
• Các tác vụ được chia thành các mô đun nhỏ cung cấp các tính năng cụ thể cho bản phát hành cuối cùng.
• Liên tục ra mắt các bản cập nhật cải tiến phần mềm.
• Giai đoạn bảo trì phức tạp hơn.

Áp dụng

• Phù hợp với nhiều dạng dự án nhưng cần có sự tham gia và tương tác của khách hàng.
• Với các dự án có quy mô lớn thì có thể chia thành các phần chức năng nhỏ dễ dàng và có thể phát triển dần trong mỗi lần lặp lại.

Sau khi tìm hiểu về quy trình phát triển phần mềm bạn có muốn trở thành một mảnh ghép trong quy trình này không? Đến với khóa học lập trình phần mềm full-stack tại VTC Academy bạn sẽ được cung cấp đầy đủ các kiến thức chuyên sâu về lập trình phần mềm. Từ đó bạn có thể đảm nhiệm nhiều vị trí trong quy trình phát triển phần mềm như lập trình phần mềm Front-end, Back-end, Full-stack, lập trình ứng dụng Android, lập trình ứng dụng iOS, hay thậm chí cả lập trình game Android và IOS (xem thêm bài viết này để hiểu rõ hơn lập trình game là gì)… Với chương trình học được thiết kế dựa trên nhu cầu thực tế của các doanh nghiệp, sau khi tốt nghiệp tại VTC Academy, 100% các bạn đều có việc làm với mức lương khởi điểm lên đến 15 triệu đồng.

Rất tiếc vì trải nghiệm không tốt của bạn về bài viết này!

Bạn có thể cho chúng tôi biết bạn chưa hài lòng vì điều gì không?

QUY TRÌNH PHÁT TRIỂN PHẦN MỀM VÀ CÁC MÔ HÌNH PHÁT TRIỂN PHẦN MỀM

Bài đăng này đã không được cập nhật trong 3 năm

Quy trình phát triển phần mềm là gì?

Mô hình Scrum

Scrum là một quy trình phát triển phần mềm thuộc họ agile.

Là một quy trình phát triển phần mềm theo mô hình linh hoạt (agile). Với nguyên tắc chủ đạo là chia nhỏ phần mềm cần sản xuất ra thành các phần nhỏ để phát triển (các phần nhỏ này phải đọc lập và Release được), lấy ý kiến khách hàng và thay đổi cho phù hợp ngay trong quá trình phát triển để đảm bảo sản phẩm release đáp ứng những gì khách hàng mong muốn. Scrum chia dự án thành các vòng lặp phát triển gọi là các sprint. Mỗi sprint thường mất 2- 4 tuần (30 ngày) để hoàn thành. Nó rất phù hợp cho những dự án có nhiều sự thay đổi và yêu cầu tốc độ cao.

Ưu điểm

Một người có thể làm nhiều việc ví dụ như dev có thể test Phát hiện lỗi sớm hơn rất nhiều so với các phương pháp truyền thống Khách hàng nhanh chóng thấy được sản phẩm qua đó đưa ra phản hồi sớm. Có khả năng áp dụng được cho những dự án mà yêu cầu khách hàng không rõ ràng ngay từ đầu.

Nhược điểm:

Trình độ của nhóm là có một kỹ năng nhất định Phải có sự hiểu biết về mô hình aglie . Khó khăn trong việc xác định ngân sách và thời gian. Luôn nghe ý kiến phản hồi từ khách hàng và thay đổi theo nên thời gian sẽ kéo dài khi có quá nhiều yêu cầu thay đổi từ khách hàng. Vai trò của PO (Product Owner) rất quan trọng, PO là người định hướng sản phẩm. Nếu PO làm không tốt sẽ ảnh hưởng đến kết quả chung.

All rights reserved

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

Một phần của loạt bài về

Phát triển phần mềm

Hoạt động cốt lõi

Mô hình và hình mẫu

Tiêu chuẩn và khối kiến thức

Bảng thuật ngữ

Sơ lược

Quy trình phát triển phần mềm (software development methodology) là một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụng trong việc phát triển để sản xuất hay phát triển ra một sản phẩm phần mềm. Các thuật ngữ tương tự là vòng đời phần mềm và quy trình phần mềm. Đây được coi là một thành phần tập con của vòng đời phát triển hệ thống. Có một số mô hình cho việc xây dựng các quy trình này, mỗi mô hình mô tả các phương thức cũng như các nhiệm vụ hoặc thao tác cần được thực hiện trong cả quá trình. Nhiều người coi mô hình vòng đời “Software Development Life Cycle” là một phần trong quy trình phát triển phần mềm “Software development methodology”. Ví dụ, có rất nhiều quy trình phát triển phần mềm tuân theo mô hình vòng đời xoắn ốc. ISO/IEC 12207 là một tiêu chuẩn quốc tế cho các quy trình vòng đời phần mềm, mục đích là trở thành một tiêu chuẩn định nghĩa tất cả các công việc cần thực hiện để xây dựng và bảo trì sản phẩm phần mềm.

Keywords searched by users: quy trình phát triển phần mềm

Categories: Phổ biến 17 Quy Trình Phát Triển Phần Mềm

See more here: kientrucannam.vn

See more: https://kientrucannam.vn/vn/