Một số cách tiếp cận dự án tiêu biểu

Tổng quan

Dự án có nhiều cách khác nhau để thực hiện. Cần biết về các đặc điểm và lựa chọn để đưa ra cách tiếp cận có nhiều khả năng thành công cao nhất cho dự án.
Có bốn loại life cycles, được định nghĩa như dưới đây.
Predictive life cycle. Một cách thức truyền thống, chủ yếu là lập kế hoạch, sau đó thực hiện trong một lần duy nhất trong một quy trình tuần tự.
Iterative life cycle. Một cách thức cho phép nhận được phản hồi cả với công việc chưa hoàn thành để cải thiện và sửa đổi công việc đó.
Incremental life cycle. Một cách thức cung cấp các sản phẩm đã hoàn thành mà khách hàng có thể sử dụng ngay lập tức
Agile life cycle. Một cách tiếp cận vừa lặp lại vừa tăng dần để tinh chỉnh các hạng mục công việc và bàn giao liên tục.

Predictive life cycles: tận dụng những điều đã biết và đã được chứng minh từ trước. Sự phức tạp và không chắc chắn được giảm thiểu cho phép chia công việc thành một chuỗi các công việc được dự đoán từ trước.
Iterative life cycles: cho phép phản hồi về công việc đã hoàn thành một phần hoặc chưa hoàn thành để cải tiến và sửa đổi công việc đó.
Incremental life cycles: Cung cấp các sản phẩm đã hoàn thành mà khách hàng có thể sử dụng ngay lập tức
Agile life cycles: Tận dụng các đặc tính của cả Iterative và Incremental life cycles. Khi teams sử dụng các phương pháp Agile, họ sẽ lặp đi lặp lại việc thực hiện để tạo ra các sản phẩm đã hoàn thành. Team nhận được phản hồi sớm và cung cấp cho khách hàng khả năng hiển thị, sự tự tin và quyền kiểm soát sản phẩm. Bởi vì nhóm có thể phát hành sớm hơn, dự án có thể mang lại lợi tức đầu tư sớm hơn vì nhóm thực hiện công việc có giá trị cao nhất.

Chi tiết

Vòng đời phát triển phần mềm (SDLC – Software Development Life Cycle) là một quá trình theo sau cho một dự án phần mềm, trong một tổ chức phần mềm. Nó bao gồm một kế hoạch chi tiết mô tả làm thế nào để phát triển, duy trì, thay đổi hoặc nâng cấp phần mềm cụ thể.

Quy trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án.

Trong thực tế các công ty xây dựng và phát triển phần mềm tùy theo từng quy mô, hình thức hoạt động mà có thể điều chỉnh gộp tách các giai đoạn tùy theo nhu cầu thực tế của công ty đó. Tuy nhiên để tạo ra một sản phẩm phần mềm sẽ bao gồm các giai đoạn sau:

1. Pha yêu cầu
2. Pha đặc tả
3. Pha thiết kế
4. Pha lập trình
5. Pha kiểm thử
6. Pha triển khai và bảo trì

1. Pha yêu cầu

Ở pha này bộ phận phân tích yêu cầu sẽ đi gặp và trao đổi với khách hàng cũng như làm rõ các chức năng, các yêu cầu mà khách hàng mong muốn xây dựng trong phần mềm của mình. Trong thực tế khi ở pha này các đơn vị phần mềm sẽ có bộ câu hỏi chung dành cho các dự án cũng như câu hỏi riêng cho đặc thù của dự án cần làm.

Đây là pha quan trọng ảnh hưởng đến việc xây dựng và phát triển phần mềm trong thời gian tới do vậy đội ngũ phân tích yêu cầu thường là những người đã có nhiều kinh nghiệm giúp trong quá trình trao đổi với khách hàng sẽ làm rõ và hiểu đúng được các yêu cầu bài toán của khách hàng cũng như thu thập các biểu mẫu thông tin liên quan đến dự án về phục vụ phân tích ở giai đoạn kế tiếp.

2. Pha đặc tả

Đây là pha sẽ được thực hiện sau khi đã ghi nhận các yêu cầu của khách hàng về bộ phận phân tích sẽ thực hiện làm rõ các yêu cầu và hiện thực hóa bằng một tài liệu SRS gọi là “Tài liệu đặc tả“. Đây là tài liệu rất quan trọng đối với qúa trình phát triển phần mềm vì bao gồm tất cả các yêu cầu sản phẩm được thiết kế và phát triển trong suốt vòng đời dự án. Các bộ phận liên quan như lập trình, kiểm thử viên,… sẽ thực hiện công việc dựa trên mô tả các chức năng chi tiết trong tài liệu và nó sẽ trả lời câu hỏi “Phần mềm sẽ làm gì ?“.

3. Pha thiết kế

Ở pha này sau khi căn cứ vào tài liệu đặc tả, bộ phận thiết kế sẽ thiết kế đưa ra giao diện chung cũng như bộ phận lập trình sẽ thiết kế giao diện mức chi tiết theo từng chức năng của phần mềm. Tức là sẽ hiển thực hóa các chức năng trong tài liệu mô tả thành giao diện chức năng phần mềm dạng prototype. Sau đó sử dụng bản khung phần mềm này để trao đổi và thống nhất với khách hàng về giao diện, bố cục. Khi khách hàng đồng ý với thiết kế phần mềm theo prototype đó sẽ mới chuyển sang giai đoạn tiếp theo nếu không sẽ ghi nhận ý kiến đóng góp và thực hiện chỉnh sửa cho đến khi khách hàng đồng thuận với bản prototype phần mềm.

4. Pha lập trình

Trong giai đoạn này SDLC bắt đầu phát triển thực tế và sản phẩm được xây dựng. Pha lập trình là pha hiện thực hóa các chức năng của phần mềm sau khi khách hàng đã thống nhất prototype của phần mềm. Ở pha này các lập trình viên (developer) sẽ lập trình xử lý chức năng, module theo yêu cầu được giao giao sau đó sẽ chuyển cho kiểm thử viên thực hiện kiểm tra các chức năng theo testcase được xây dựng dựa trên tài liệu đặc tả.

5. Pha kiểm thử

Ở pha này, các kiểm thử viên sẽ nhận được các bàn giao chức năng thực hiện từ lập trình viên. Sau đó các kiểm thử viên sẽ thực hiện kiểm tra các chức năng này theo các testcase được xây dựng. Trong quá trình kiểm thử theo testcase nếu có phát sinh lỗi, kiểm thử viên sẽ thực hiện báo bug lỗi để lập trình viên xử lý chức năng đó fix lỗi.

Quá trình kiểm thử chức năng, kiểm tra lại, báo bug lỗi, báo cáo sẽ thực hiện đi thực hiện lại cho đến khi các chức năng lập trình đã thực hiện đúng theo tài liệu đặc tả hay yêu cầu của khách hàng.

Sau khi hoàn thiện các chức năng cũng như đạt yêu cầu về kiểm thử, phần mềm sẽ được triển khai thử nghiệm trên môi trường của khách hàng. Nếu có yêu cầu chỉnh sửa đội ngũ phát triển phần mềm sẽ thực hiện bổ sung, sửa lỗi để có thể nghiệm thu phần mềm.

6. Pha triển khai bảo trì

Một khi sản phẩm sau khi được kiểm thử và sẵn sàng triển khai, sản phẩm được phát hành chính thức trên thị trường thích hợp. Đôi khi việc triển khai sản phẩm xảy ra theo từng giai đoạn theo chiến lược kinh doanh của tổ chức đó. Trong quá trình sử dụng phần mềm của khách hàng, công ty phát triển phần mềm sẽ phải hỗ trợ, xử lý lỗi nếu có phát sinh trong quá trình sử dụng. Ở đây có 2 khái niệm cần chú ý đó là:

– Software repair (bảo trì sửa lỗi): Thực hiện chỉnh sửa các lỗi phát sinh trong quá trình sử dụng phần mềm của khách hàng.

– Software update (bảo trì cập nhật)

• Bảo trì hoàn thiện: Sửa đổi phần mềm theo ý khách hàng
• Bảo trì thích nghi: Sửa đổi để phần mềm thích nghi với môi trường mới

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

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

• Phân tích yêu cầu và tài liệu đặc tả (Requirements and Specifications): là giai đoạn xác định những Yêu cầu liên quan đến chức năng và phi chức năng mà hệ thống phần mềm cần có. Giai đoạn này cần sự tham gia tích cực của khách hàng và kết thúc bằng một tài liệu được gọi là “Bản đặc tả yêu cầu phần mềm” hay SRS (software requirement specification). Tài liệu Đặc tả yêu cầu chính là nền tảng cho các hoạt động tiếp theo cho đến cuối dự án.
• Phân tích hệ thống và thiết kế (System Analysis and Design): là giai đoạn định ra làm thế nào để hệ thống phần mềm đáp ứng những yêu cầu mà khách hàng yêu cầu trong tài liệu SRS.
• Lập trình (Coding and Unit Test): là giai đoạn hiện thực làm thế nào được chỉ ra trong giai đoạn “Phân tích hệ thống và thiết kế”
• Kiểm thử (Test): bao gồm kiểm thử tích hợp cho nhóm các thành phần và kiểm thử toàn hệ thống (system test). Một khâu kiểm thử cuối cùng thường được thực hiện là nghiệm thu (acceptance test), với sự tham gia của khách hàng trong vai trò chính để xác định hệ thống phần mềm có đáp ứng yêu cầu của họ hay không.
• Cài đặt và bảo trì (Deployment and 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 phần mềm (nếu có) và phát triển những thay đổi mới được khách hàng yêu cầu (như sửa đổi, thêm hay bớt chức năng/đặc điểm của hệ thống).

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

Sprint là chu trình nhỏ để phát triển sản phẩm. Trong Sprint, nhóm dự án sẽ tập trung phát triển những chức năng cụ thể nào đó và hoàn thiện nó vào mỗi cuối sprint. Mỗi Sprint có thời gian thống nhất, thường là 1 hoặc 2 tuần và thường không quá 4 tuần.

• Trước khi cả nhóm thực hiện làm các sprint, đội sản xuất cùng họp với Product Owner để lập kế hoạch cho từng Sprint (gọi là Scrum Meeting). 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
• 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
• 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.
• 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 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.
• Scrum định nghĩa quy tắc cho bốn sự kiện chủ chốt (các cuộc họp) nhằm tạo môi trường và quy cách hoạt động và cộng tác cho các thành viên trong dự án. Các lễ nghi này diễn ra trước khi Sprint bắt đầu (Sprint Planning), trong khi Sprint diễn ra (Daily Scrum) và sau khi Sprint kết thúc (Sprint Review và Sprint Retrospective)
• Trong Scrum, đội ngũ tham gia phát triển phần mềm được phân chia ra ba vai trò với trách nhiệm rõ ràng để đảm bảo tối ưu hóa các công việc đặc thù. Ba vai trò này bao gồm: Product Owner (chủ sản phẩm), Scrum Master và Development Team (Đội sản xuất hay Nhóm Phát triển).

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

Scrum Master: họ phải đảm bảo các sprint được hoàn thành đúng mục đích, bảo vệ đội làm việc và loại bỏ các trở ngại

Development Team: thường từ 5-9 người, tùy theo quy mô dự án nó có thể có rất nhiều đội, nhiều người tham gia.

You need to login in order to like this post: click here