Ở giai đoạn này nền tảng kiến trúc đã được xác định, quy trình, cơ sở hạ tầng, môi trường phát triển cũng đã được mô tả rõ ràng.
3.3.1 Opportunity
Trạng thái cần đạt được ở giai đoạn này là Viability Establish.
Để đạt được trạng thái này thì nhóm phát triển cần xác định tính khả thi của dự án và xác nhận đại diện các bên liên quan để trao đổi thông tin giữa những người sử dụng và nhóm phát triển.
- Xác định tính khả thi của ứng dụng: Anh Long tính toán kinh phí cho việc phát triển ứng dụng, xem xét lại những khó khó khăn có thể gặp phải trong quá trình phát triển ứng dụng và thấy kinh phí cho việc phát triển thỏa mãn điều kiện kinh phí mà giám đốc duyệt, một số khó khăn khác như thời gian hoàn thành dự án hơi gấp thì nhóm phát triển có thể khắc phục được. Do vậy ứng dụng này có thể tiếp tục phát triển được.
- Xác định đại diện các bên liên quan: Người sử dụng ứng dụng này là nhân viên phòng kế toán, nhân viên phòng kinh doanh. Hai phòng này đã họp lại và quyết định anh
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 đó.