Hình 3 .9 Cập nhật trạng thái Use Case tới Story Structure Understood
Hình 3.13 Opportunity Game Board ở trạng thái Viability Establish
Hải sẽ là người đại diện cho ý kiến của các nhân viên của hai phòng này, sẽ có nhiệm vụ trao đổi thông tin qua lại giữa nhóm phát triển và nhân viên hai phòng.
3.3.2 Requirement
Trạng thái cần đạt được ở giai đoạn này của Alpha Requirement là Stable
Mục đích của trạng thái này là xác định chắc chắn về các yêu cầu của ứng dụng để tránh việc sửa đổi sau này. Sau khi Submit thì các nhiệm vụ cần thực hiện để Requirement đạt được trạng thái này được mô tả trong Work Pad như hình 3.12:
- Xác định kiến trúc của Requirement: Như mô tả ở phần trên thì yêu cầu của của hệ thống gồm có ba chức năng chính là quản trị hệ thống, quản lý thông tin khách hàng, theo dõi nợ khách hàng. Mỗi một chức năng này lại gồm phân cấp các chức năng nhỏ như mô tả ở các hình vẽ phần trình bày về các Actor và Use Case ở các hình 3.6, 3.7, 3.8. Các thông tin về hoạt động của từng chức năng cũng đã được mô tả trong phần 3.7.
- Chuyển trạng thái Use Case Slice thành Prepared như hình 3.16 như sau: Hình 3.14: Requirement với trạng thái đích là Stable.
Ở trạng thái này nhóm đã viết mô tả về các chức năng được liệt kê dưới dạng một kịch bản chứa trạng thái bắt đầu là gì và trạng thái kết thúc là gì để hỗ trợ cho nhân viên kiểm thử thực hiện công việc kiểm thử sau này.
Chức năng nhập thông tin người dùng: Khi có người dùng mới thì người quản trị sẽ nhập thông tin người dùng mới và ghi lại. Thông tin người dùng sẽ được lưu lại trong cơ sở dữ liệu gồm hai thông tin cơ bản để đăng nhập được hệ thống đó là: User và Password.
Chức năng phân quyền người dùng: Chức năng này cho phép người dùng có thể sử dụng chức năng nào của hệ thống khi đăng nhập. Quản trị hệ thống là người thực hiện công việc này.
Chức năng sửa thông tin người dùng: Khi quản trị hệ thống ghi sai thông tin của người dùng thì người quản trị cần đăng nhập vào hệ thống và sửa các thông tin bị sai, hoặc khi một nhân viên chuyển từ phòng này sang phòng khác mà chức năng về quyền người dùng thay đổi thì quản trị hệ thống cũng phải sửa lại. Kết quả được lưu lại trong cơ sở dữ liệu thông tin đã sửa.
Chức năng xóa thông tin người dùng: Quản trị hệ thống đăng nhập vào hệ thống và xóa người dùng không dùng ứng dụng hoặc nghỉ việc tại công ty. Sau khi xóa thông tin của người dùng không còn trong cơ sở dữ liệu nữa.
Chưc năng đăng nhập: Mỗi người dùng được cấp một user và password. Khi muốn sử dụng ứng dụng thì người dùng sẽ nhập user và password. Sau khi đăng nhập thì người dùng sẽ được sử dụng các chức năng cho phép.
Nhập thông tin khách hàng: Khi có một hợp đồng mới được ký, nhân viên kinh doanh sẽ đăng nhập vào hệ thống và nhập các thông tin của khách hàng này vào hệ thống. Kết quả là thông tin của khách hàng sẽ được lưu lại trong cơ sở dữ liệu.
Sửa thông tin khách hàng: Nếu khi nhập thông tin bị sai lệch thì nhân viên nhập thông tin cho khách hàng đó sẽ có nhiệm vụ sửa lại thông tin bị sai. Kết quả thông tin chỉnh sửa của khách hàng sẽ được lưu lại trong cơ sở dữ liệu.
Xem danh sách khách hàng: Mỗi nhân viên được cấp user và password đều có thể xem danh sách khách hàng. Sau khi nhân viên chọn chức năng xem danh sách khách hàng thì hệ thống sẽ hiển thị danh sách khách hàng cùng với các tiêu chí mà nhân viên đó muốn xem.
Tìm kiếm khách hàng: Người dùng nhập thông tin tìm kiếm có thể là tên công ty hoặc tên đại diện hợp đồng, sau khi nhập thông tin này thì hệ thống sẽ hiển thị những khách có thông tin giống như thông tin tìm kiếm.
Thống kê nợ: Nhân viên kế toán có thể thực hiện chức năng thống kê nợ theo tháng, theo quý, theo năm. Sau khi chọn chức năng này thì hệ thống sẽ hiển thị ra danh sách những khách hàng còn nợ, số tiền nợ của từng khách hàng, và tổng tiền nợ theo tiêu chí thống kê tương ứng.
Cập nhật tình hình thu nợ: Khi khách hàng trả tiền hàng, hoặc trả nợ hàng đã mua thì nhân viên kế toán cần cập nhật lại thông tin trả nợ của khách, đồng thời thêm vào trường ghi chú ngày trả và đợt trả. Với mỗi lần đòi nợ, khách hàng có thể trả hoặc không thì nhân viên kế toán cũng ghi lại vào trường ghi chú ngày đòi,tình hình trả của khách
hàng đó. Kết thúc quá trình thanh toán thì nhân viên phụ trách việc thu hồi nợ cần thêm vào trường ghi chú nhận xét về việc thanh toán của khách hàng đó.
Thoát khỏi ứng dụng: Khi không dùng ứng dụng nữa người dùng sẽ chọn chức năng thoát khỏi ứng dụng. Khi chọn chức năng này thì không thể thực hiện bất kỳ chức năng nào khác trong ứng dụng nữa.
Sau khi mô tả xong thì các Use Case được chuyển sang trạng thái đích là Analyzed
Nhóm phát triển đã tiến hành phân tích từng Use Case trên xem có thể chia nhỏ nữa được không để sẵn sàng cho việc viết code và kiểm thử.
- Kiểm tra và chỉnh sửa lại ca sử dụng: Nhóm đã xem xét và thấy rằng chức năng phân quyền người dùng là không cần thiết vì hoạt động này đã được thực hiện trong chức năng thêm người dùng nên quyết định bỏ chức năng này.
Sau các hoạt động này thì bảng trạng thái Use Case được cập nhật lại như hình 3.18: Hình 3.17: Use Case Slice ở trạng thái Analyzed.
3.3.3 System
Trạng thái cần đạt được của Alpha System trong giai đoạn này là Production Quality Achieved.
Các công việc của giai đoạn này được thể hiện trong Work Pad như hình 3.20: Hình 3.18: Bảng Use Case Game Board khi Requirement đạt trạng thái Stable.
- Xác định kiến trúc cho ứng dụng: Nhóm xây dựng bản thiết kế kiến trúc cho ứng dụng để đáp ứng được các chức năng yêu cầu của người sử dụng.
- Nhóm bắt đầu xây dựng một vài chức năng ban đầu như trong kế hoạch của dự án.
- Cùng với việc xây dựng chức năng thì việc viết test case cũng được thực hiện. - Thực hiện kiểm thử các chức năng đã hoàn thành:
Hình 3.20: Các nhiệm vụ cần thực hiện để System đạt được trạng thái Production Quality Achieve.
- Sau khi có kết quả test thì tiến hành phân tích xem có lỗi không, lỗi được đưa lên bảng quản lý lỗi.
Hình 3.23: Xác nhận lỗi.
- Sau khi sửa lỗi xong thì những lỗi đã được sửa đạt trạng thái Closed
Sau khi đã sửa xong các lỗi ở những chức năng đã kiểm thử thì tiến hành kiểm thử lại, sau khi hoàn thành việc kiểm thử ở những chức năng đã hoàn thành thì cập nhật lại trạng thái trong bảng kiểm thử.
- Tích hợp các chức năng đã hoàn thành vào hệ thống và gửi cho người sử dụng kiểm chứng lại những chức năng đã hoàn thiện xem có đạt yêu cầu đặt ra hay không.
Hình 3.24: Cập nhật lại những lỗi đã được sửa.
3.3.4 Project
Trạng thái đích của giai đoạn này là Rick Under Control: Do đây là dự án nhỏ, nhóm phát triển rất thành thạo công cụ lựa chọn, chỉ có vấn đề là thời gian thực hiện dự án hơi ngắn tuy nhiên nhóm đã xác định khắc phục bằng cách làm thêm giờ để đạt tiến độ. Nên rủi ro của dự án là hầu như không có, các mục tiêu của dự án đang dần hoàn thành theo đúng kế hoạch đề ra ban đầu. Do đó mục tiêu tiếp theo của dự án sẽ là Development Complete
3.3.5 Team
Trạng thái đích của Team trong giai đoạn này là Collaborating.
- Focused: Nhóm tập trung hoàn thành nhiệm vụ của nhóm, các thành viên trong nhóm tích cực hoàn thành nhiệm vụ của mình. Trong quá trình làm việc thì các thành viên trong nhóm được anh Long tích cực hỗ trợ về mặt kỹ thuật khi gặp khó khăn.
Hình 3.26: Project Game Board với mục tiêu là Development Complete.
- Collaborating: Các thành viên trong nhóm đoàn kết, hỗ trợ giúp đỡ lần nhau hoàn thành mục tiêu đề ra, công việc luôn tiến triển tốt. Mỗi khi hoàn thành một modul nhóm luôn có một cuộc họp ngắn để rút kinh nghiệm và giải đáp những khó khăn mà các thành viên khách gặp phải. Do vậy trạng thái của các thành viên trong nhóm đổi thành Integrated.
3.3.6 Way of Working
Mục tiêu đạt được của Way of Working trong giai đoạn này là trạng thái Essential in Place. Mục đích của trạng thái này là xác định lựa chọn những công cụ hỗ trợ cho công việc của nhóm và hỗ trợ việc cộng tác nhóm để đạt mục tiêu đề ra. Để đạt được điều này nhóm đã sử dụng công cụ quản lý code và quản lý lỗi, nhờ vậy mà việc cộng tác trao đổi giữa các thành viên dễ dàng hơn.
Ví dụ: Mỗi khi nhân viên kiểm thử phát hiện lỗi sẽ cập nhật lên bảng quản lý lỗi, người phát triển sẽ vào đó xem các chức năng nào còn lỗi để sửa chữa hay phản hồi về các lỗi đó.
3.4 Giai đoạn hoàn thành
3.4.1 Opportunity
Lúc này một số chức năng đã được hoàn thiện và tích hợp dần vào hệ thống, người sử dụng đã dùng thử một số chức năng hoàn thành và họ nhận thấy đã đạt được những yêu cầu đề ra ban đầu, giải quyết một số khó khăn trong công việc của họ. Lúc này trạng thái Problem Adressed đã đạt được.
3.4.2 Requirement
Lúc này các thành viên trong nhóm đang hoàn thiện nốt các chức năng còn lại, nhân viên kiểm thử đang kiểm thử các chức năng còn lại của ứng dụng xem có thỏa mãn yêu cầu đặt ra ban đầu hay không.
Kết thúc giai đoạn này thì các chức năng đã được hoàn thiện hết và được kiểm thử, một số chức năng phát hiện lỗi đã được gửi cho nhóm lập trình sửa chữa lại và cập nhập lại thành công.
3.4.3 System
Trạng thái mục tiêu của giai đoạn này là Release Candidate.
Để đạt được trạng thái này thì nhóm tích cực hoàn thành nốt các chức năng còn lại. Khi các chức năng đã hoàn thiện thì bảng Component được cập nhật lại
Thực hiển kiểm thử và tích hợp vào hệ thống, kiểm thử toàn hệ thống, trạng thái của bảng Test Game Board cũng được cập nhật lại thành Evalued. Sau Khi hoàn thành các công việc trên thì trạng thái này đã đạt được đồng thời trạng thái của Alpha Requirement đã đạt được Fulfilled. Và trạng thái đích hướng tới của Alpha System là Release.
3.4.4 Team
Nhóm tiếp tục cộng tác với nhau để hoàn thành nốt các công việc còn lại. Các thành viên trong nhóm vẫn sử dụng các công cụ nêu ra để phục vụ cho việc cộng tác được tốt hơn và hoàn thành mục tiêu đề ra.
3.4.5 Project
Lúc này dự án gần đã hoàn thành và có đầy đủ các chức năng ban đầu đặt ra, đạt tiến độ như kế hoạch, trạng thái đã được chuyển sang Development Complete. Ứng dụng chuẩn bị đưa vào triển khai chạy thử trong môi trường thực để nhận phản hồi từ người dùng.
3.4.6 Way of Working
Trong quá trình hoàn thành nốt các chức năng còn lại nhóm vẫn tiếp tục sử dụng các công cụ hỗ trợ cho công việc của mình, các thành viên trong nhóm sử dụng các công cụ ấy một cách thành thạo không cần suy nghĩ, nhờ có việc sử dụng thành thạo
các công cụ đó trong việc phát triển và cộng tác làm việc mà công việc tiến triển ngày một nhanh chóng hơn. Trạng thái đạt được ở giai đoạn này là Embedded.
3.5 Giai đoạn chuyển giao
3.5.1 Opportunity
Người sử dụng đã nhận thấy rõ hiệu quả của hệ thống ứng dụng phục vụ vào công việc của mình, giải quyết được các khó khăn gặp phải trong công việc nhờ đó mà hiệu quả công việc được tốt hơn.
3.5.2 Requirement
Tất cả các chức năng đã hoàn thành đáp ứng mọi yêu cầu đặt ra.
3.5.3 System
Hệ thống mang đi triển khai trong môi trường thực, đồng thời xây dựng tài liệu hướng dẫn sử dụng, hướng dẫn cài đặt. Chị Hòa chịu trách nhiệm hướng dẫn cho người
Hình 3.32: Requirement đã đạt được trạng thái Fulfilled.
dùng sử dụng ứng dụng và giải quyết những thắc mắc của người dùng, nhận phản hồi của người dùng về ứng dụng.
3.5.4 Team
Lúc này nhiệm vụ của nhóm là triển khai ứng dụng tới người dùng, khi hoàn thành việc triển khai thì nhóm được giải tán không còn thực hiện nhiệm vụ liên quan đến dự án này nữa. Nhóm có thể cùng nhau làm việc ở các dự án khác hoặc không làm việc cùng nhau nữa.
3.5.5 Project
Dự án đã hoàn thành đúng tiến độ và hoàn thành các chức năng như ban đầu, công việc bàn giao cho người sử dụng được tiến hành, người dùng hài lòng với ứng dụng mà nhóm đã phát triển.
Hình 3.33: System đã đạt được trạng thái Released.
3.5.6 Way of Working
Do công việc đã hoàn thành, ứng dụng đã được bàn giao cho người sử dụng mang vào ứng dụng trong thực tế nên cách làm việc không còn dùng nữa. Tuy nhiên các tài liệu về dự án được lưu giữ lại ở phòng IT để nếu sau này có phát triển tiếp thì có thể dùng nó làm tham khảo hoặc có thể dùng nó làm tham khảo cho các dự án khác. Trạng thái kết thúc của Alpha này là Hand Over.
Hình3.35: Project đã hoàn thành việc chuyển giao.
CHƯƠNG 4 - NHẬN XÉT, ĐÁNH GIÁ, THẢO LUẬN
Sau quá trình tìm hiểu vể SEMAT và công cụ EssWork, tôi có một số nhận xét và đánh giá như sau:
4.1 Ưu điểm của SEMAT
Áp dụng SEMAT sẽ giảm thiểu những rủi ro trước khi bắt tay vào việc thực hiện dự án. Bởi trước khi xác định yêu cầu thì trong hướng dẫn của Kernel còn cần phải xác định một loạt các điều kiện khác như: Xác định xem liệu giải pháp đưa ra có thực sự có lợi ích không? Lợi ích đó là gì? Có khả thi không? (chính là một số trạng thái ban đầu của Alpha Opportunity) Những người sử dụng có đồng ý với giải pháp nêu ra không? Nếu tất cả những điều kiện đó được đáp ứng thì mới đi tới bước tiếp theo là xác định yêu cầu. Rõ ràng việc xác định trước những điều đó sẽ giúp cho dự án có tính an toàn cao hơn là việc mất thời gian xác định các yêu cầu người dùng, xác định xong chức năng của ứng dụng rồi mới thấy dự án không thể tiến hành vì một lý do nào đó như: Kinh phí không đảm bảo, kỹ thuật quá phức tạp mà trình độ của đội dự án không thể đáp ứng để hoàn thành…
Kernel trong SEMAT giúp theo dõi sự phát triển của dự án một cách thuận lợi, người dùng có thể theo dõi bằng cách gắn mỗi trạng thái của từng Alpha lên bảng, nếu trạng thái nào hoàn thành thì được chuyển sang bên trái của bảng, trạng thái nào chưa hoàn thành thì để ở bên phải. Nhờ đó có thể dễ dàng biết được họ đang ở giai đoạn nào, vị trí nào của dự án và đích họ cần đến là gì. Việc tới đích như thế nào lại có các hướng dẫn thực hiện công việc trong từng trạng thái.