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

• Báo cáo

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

I. 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.

1. Khái niệ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.

**2. 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.
• 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.

II. Các mô hình phát triển trong dự án phần mềm

• 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.

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

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ềmScalability
• Tài liệu được thực hiện ở giai đoạn sau
• Cần một team có kinh nghiệmNeeds special skills for the team.

Tham khảo thêm: http://istqbexamcertification.com/what-is-rad-model-advantages-disadvantages-and-when-to-use-it/

• 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êmTuyê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.

III. TÌm hiểu về Mô hình 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.

3.2 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 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
• 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. 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. 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.

3.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: + Hôm qua bạn làm được gì?
• Phát sinh vấn đề gì?
• Hôm nay bạn sẽ làm 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à Scrum mang lại cho tổ chức.

Trên đây là bài seminar của QA được tìm hiểu bởi các thành viên:

- Phạm Thị Kim Oanh

- Nguyễn Thị Huyền Châm

- Nguyễn Thị Phương Mai

- Trần Thị Trang

- Nguyễn Thu Phương