Đây là phần 3 của hướng dẫn cho dự án Capstone:

Trong dự án Capstone, người quản lí dự án (PM) phải giữ dấu vết về cách các thành viên tổ dành thời gian của họ cho dự án. Theo dõi thời gian là hoạt động quan trọng để giám sát trách nhiệm cá nhân với dự án. Việc ghi thời gian cho phép PM so sánh thời gian thực tế so với thời gian được lập kế hoạch của từng thành viên. PM phải tóm tắt thời gian hàng tuần cho từng thành viên và cho tổ để tìm ra tổ thực sự làm việc bao nhiêu thời gian trên dự án. Bằng việc làm điều đó, PM có thể nhận diện đóng góp của từng cá nhân cho công việc dự án trong từng pha. (Lưu ý: PM phải báo cáo tính toán thời gian cho giáo sư.)

Trước từng pha phát triển, PM phải chia sẻ thông tin với các thành viên tổ liên quan tới số giờ thực tế mà họ dành cho nhiệm vụ của họ. Dùng dữ liệu này, thành viên tổ có thể ước lượng số giờ họ sẽ cần để hoàn thành nhiệm vụ tiếp. PM phải phân công cho từng thành viên tổ một số nhiệm vụ để làm cũng như ngày hoàn thành được mong đợi. Điều quan trọng là phân công người dự phòng trong trường hợp một người không có khả năng hoàn thành nhiệm vụ tương ứng. Bắt đầu từng pha cũng là lúc chuyển vai trò và phân công cho nên mọi thành viên đều có cơ hội thực hiện những vai trò nào đó. (Lưu ý: Nhớ rằng vai trò tới cùng trách nhiệm và họ phải hoàn thành chúng.)

Tổ cũng phải định nghĩa tập các độ đo để đo tiến bộ của tổ, năng suất và tính hiệu quả. Với từng độ đo, tổ phải chỉ ra cách họ thu thập dữ liệu, ghi dữ liệu, và cách họ dùng những dữ liệu này để ra quyết định. Tập các độ đo phải bao gồm cách đo chất lượng sản phẩm (lỗi và tỉ lệ lỗi), trạng thái và tiến độ dự án (ước lượng kích cỡ và nỗ lực so với thực tế), chất lượng qui trình (khối lượng việc làm lại, cột mốc được thực hiện và bị lỡ). Tổ phải phát triển một danh sách các rủi ro vì chúng là đe doạ nghiêm trọng cho dự án như thiếu lịch biểu, thay đổi với dự án v.v. Với từng dự án, tổ phải cung cấp một mô tả, và khả năng có thể xuất hiện (thấp, vừa, cao), và chiến lược giảm thiểu rủi ro. Quản lí rủi ro là kĩ năng quan trọng mà tổ phải học. (Lưu ý: Rủi ro thông thường nhất trong dự án Capstone là thay đổi trong yêu cầu. Trong dự án khách hàng thường làm điều đó để xem cách tổ phản ứng. Tổ phải dự đoán những thay đổi này và có kế hoạch giải quyết nó.)

Một khi khách hàng chấp thuận đề nghị của tổ về phạm vi mới, tổ có thể bắt đầu dự án. Điều đầu tiên cần làm là sửa lại bản đặc tả yêu cầu phần mềm (SRS) với phạm vi đã được chấp thuận (Khử bỏ các yêu cầu ưu tiên thấp không cần thiết mà khách hàng đã đồng ý hay thêm yêu cầu mới mà khách hàng đã yêu cầu tổ đưa vào). Dự án Capstone bắt đầu với SRS mới làm cơ sở cho mọi hoạt động dự án. Tổ cũng phải sửa lại và hiệu chỉnh các biểu đồ trường hợp sử dụng use case và lời dẫn mà họ đã làm trước đó và rót đầy những chi tiết còn thiếu và chỉ ra mọi tiền điều kiện, hậu điều kiện và các bộ lẩy cò cho từng use case.

Để nhận diện mọi nhiệm vụ phải được hoàn thành cho từng pha, tổ phải phân rã công việc dự án thành một số các nhiệm vụ và phân công chúng cho từng thành viên. Từ những nhiệm vụ này, thành viên tổ có thể ước lượng nỗ lực của họ (cần bao lâu để hoàn thành chúng) và tổ hợp vào lịch dự án tổng thể. Vì không phải mọi nhiệm vụ đều có thể được làm cùng lúc, một số nhiệm vụ phụ thuộc vào cái ra từ các nhiệm vụ khác, tổ phải nhận diện sự phụ thuộc giữa các nhiệm vụ và xây dựng trình tự có thứ tự các hoạt động thực hiện nhiệm vụ. (Lưu ý: Đây là bài tập lặp, tổ không nên tìm sự hoàn hảo mà chỉ cần biết từng nhiệm vụ trong đủ chi tiết để cho PM có thể theo dõi và báo cáo về tiến độ của họ.)

Việc phân rã công việc (cấu trúc phân việc) thường phụ thuộc vào phương pháp mà tổ dùng nhưng tổ phải thực tế về việc xác định các nhiệm vụ này. Chẳng hạn một nhiệm vụ lớn như “Phân tích vấn đề” hay “Thiết kế chức năng” là không thực tế vì nó không đủ chi tiết cho ước lượng hay theo dõi.  Chia thành nhiệm vụ quá nhỏ có thể thành phân mảnh quá cũng không có ích. Cách tốt nhất là cân nhắc một nhiệm vụ như cái gì đó có thể hoàn thành trong vòng 32 giờ (Man-week) là cách tốt nhất để xác định một nhiệm vụ, vì nó dễ cho theo dõi và đo. Khi làm việc về lịch biểu toàn thể, tổ cũng phải xem xét các nhiệm vụ liên quan tới các hoạt động hỗ trợ như SQA, SCM, quản lí thay đổi cũng như bao gồm mọi nhiệm vụ liên quan tới việc học công nghệ mới, quản trị máy phục vụ, công cụ mới v.v.. Những nhiệm vụ hỗ trợ này thường bị quên mất hay không được tính tới trong lịch biểu toàn thể và đó là lí do tại sao nhiều dự án phần mềm bị chậm, lỡ lịch và chúng bị ước lượng thấp.

Khi phân rã được hoàn thành, người quản lí kiểm thử và thành viên tổ phải bắt đầu xây dựng một tập các trường hợp kiểm thử cho phần mềm. Phải có tối thiếu một trường hợp kiểm thử cho từng use case. Nhiều use case có thể yêu cầu nhiều trường hợp kiểm thử. (Lưu ý: Trường hợp kiểm thử nên được thực hiện ở cuối pha phân tích yêu cầu và đầu pha thiết kế để nhận diện bất kì yêu cầu nào bị bỏ sót hay còn mơ hồ. Nếu bạn không thể kiểm thử được cái gì đó điều đó nghĩa là yêu cầu của bạn không rõ ràng hay kiểm thử được. Trong trường hợp đó tổ nên quay lại và đề nghị khách hàng kiểm nghiệm. Mọi trường hợp kiểm thử đều phải dùng một khuôn mẫu tương tự: với từng trường hợp đều phải có mục đích kiểm thử, dữ liệu kiểm thử, kết quả mong đợi, và ngày trường hợp kiểm thử được cho chạy (và cho lại kết quả xác định) và tên của thành viên tổ tiến hành kiểm thử).

Bên cạnh các chức năng được mô tả trong SRS, tổ phải nhận diện các yêu cầu phi chức năng (thuộc tính chất lượng) như an ninh, hiệu năng, tính truy nhập được, tính dễ dùng, tính dễ học, tính bảo trì được, v.v.) vì sản phẩm phải thoả mãn các ràng buộc vận hành thực tế (các cấu phần hệ điều hành, cơ sở dữ liệu, phần cứng và phần mềm). PM phải chỉ ra cách những yêu cầu phi chức năng này có thể được đáp ứng và bất kì hỗ trợ bảo trì nào mà sản phẩm cần sau khi đưa ra cho khách hàng. (Lưu ý: Đây là hoạt động nhiều tổ capstone không đạt tới. Mặc dầu khách hàng không yêu cầu điều đó nhưng tổ dự án phải thực hiện nó vì đó là mấu chốt cho vận hành và nó sẽ vượt quá mong đợi của khách hàng và cho ấn tượng tích cực hơn cho tổ.)

Khi cả các nhiệm vụ chức năng và phi chức năng (thuộc tính chất lượng) được thực hiện, tổ có thể bắt đầu làm việc trên bản mẫu, hay hiển thị màn hình điều sẽ biểu diễn cách “nhìn và cảm” của sản phẩm phần mềm như hiển thị menu chính của mọi chức năng mà người dùng sẽ thấy khi đăng nhập. Tài liệu thiết kế phải chỉ ra ít nhất vài trường hợp sử dụng use case khác biệt (khác hơn đăng nhập/đăng xuất) trong chiều sâu đầy đủ. Tổ phải kiểm điểm và biện minh bất kì vấn đề thiết kế nào hay quyết định thiết kế còn chưa rõ vào lúc này. Nếu cần, PM phải triệu tập cuộc họp với khách hàng để thẩm tra lại các yêu cầu. (Lưu ý: Đây là lần đầu tiên khách hàng thấy việc biểu diễn thực tế của công việc của tổ. Bản mẫu là quan trọng cần để thẩm tra khái niệm vận hành mà tổ có. Sau khi kiểm điểm bản mẫu, khách hàng thường đổi một số yêu cầu cho nên tổ phải được chuẩn bị và không bị thất vọng. Chấp nhận thay đổi ở pha sớm hơn là tốt hơn nhiều so với pha muộn hơn.)

Nếu có thay đổi, tổ phải quay lại cập nhật bản đặc tả yêu cầu phần mềm (SRS) với những thay đổi mới cũng như mọi use case và tài liệu bị ảnh hưởng. (Lưu ý: Nhiều dự án Capstone không làm điều này và thường gặp khó khăn trong pha kiểm thử và bảo trì về sau. Chính các thực hành rất tốt là cập nhật mọi tài liệu ngay khi thay đổi xảy ra. Tổ phải làm việc cùng nhau để vẽ ra các biểu đồ lớp chi tiết hay biểu đồ thực thể-quan hệ. Họ phải chỉ ra mọi lớp, quan hệ, thuộc tính. Có thể dùng kí pháp UML vì nó rất phổ biến trong hầu hết các dự án toàn cầu. Tổ có thể tạo ra từ điển dữ liệu cho mọi thuộc tính trong mô hình của bạn. Các mục từ phải được làm chi tiết, chính xác và không nhập nhằng. Lưu tâm rằng các khái niệm và thuộc tính bạn đang làm việc có các nghĩa hiển nhiên cho bạn nhưng có thể không hiển nhiên cho người dùng.)

—-English version—-

A guide to Capstone project part 3

This is part 3 of the guide to Capstone project:

During the Capstone project, Project Manager (PM) must keep track of how team members are spending their time on the project. Time tracking is an important activity to monitor individual responsibility to the project. The time records allow PM to compare actual time spend against planned time of each member. PM must summarize the weekly time spend for each member and for the team to find out how much time the team really works on the project. By doing that, PM can identifies each person’s contributions to the project work during each phase. (Note: PM must report the time accounting to the professor).

Before each development phase, PM must share these information with team members regarding their actual number of hours that they spent on their tasks. Using these data, team members can estimate the number of hours they will need to complete the next task. PM must assign each member a numbers of task to do as well as an expected completion date. It is important to assign a backup person just in case a person is not able to complete the task accordingly. The beginning of each phase is also time to switch roles and assignment so every members have chances to perform certain roles. (Note: Remember that role comes with responsibility and they must fulfill them).

The team must also define a set of metrics to measure the team’s progress, productivity and effectiveness. For each metric, the team must indicate how they collect data, record data, and how they use these data for making decision. The set of metrics should include measures of product quality (defects and defect rates), project status and progress (size and effort estimates versus actual), process quality (amount of rework, milestones made and missed). The team must develop a list of risks as they are the serious threats to the project such as missing schedule, changes to the project etc.. For each risk, the team must provide a description, and likelihood of occurrence (low, medium, high), and an appropriate risk mitigation strategy. Risk management is an important skill that the team must learn. (Note: The most common risk in Capstone is the change in requirements. During the project the client often does that to see how the team react. The team must anticipate these changes and have plan to deal with it).

Once the client approves the team’s proposal on the new scope, the team can start the project. The first thing to do is revise the software requirements specification (SRS) with the approved scope (Eliminate the unnecessary low priority requirements that the client has agreed or add new requirements that the client has asked the team to include). The Capstone project starts with this new SRS as the base for all project activities. The team must also revise and correct the use case diagrams and narratives that they did previously and fill in all missing details and indicate all preconditions, post-conditions and triggers for each use cases.

To identify all tasks that must be completed for each phase, the team must decompose the project works into number of tasks and assign them to each member. From these tasks, team member can estimate their efforts (How long will it take to complete them) and incorporate into an overall project schedule. Since not all tasks can be done at the same time, some depend on outputs from others, the team must identify the dependencies among tasks and building an orderly sequence of task execution activities. (Note: This is an iteration exercise, the team should not look for perfection but only need know each task in sufficiently detail enough so that the PM can track and report on their progress).

The decomposition of works (Work breakdown structure) is often depending on the method that the team use but the team must be realistic about defining these tasks. For example a large task such as “Problem Analysis” or “Design function” is not realistic as it is not detail enough for estimating or tracking.  Breakdown into too small task which may be so fragment is also not so helpful either. The best way is consider a task as something a person can complete within 32 hours (Man-week) is the best way to define a task, as it is easy to track and measure. When working on the overall schedule, the team must also consider tasks related to support activities such as SQA, SCM, Change management as well as including all tasks related to learning new technologies, server administration, new tools etc. These supporting tasks are often forgot or not considered into the overall schedule and that is why many software projects were late, missed schedule as they underestimated.

When the decomposition is done, the test manager and team members should start to build an initial set of test cases for the software. There must be a minimum of one test case per use case. Many use cases may require multiple test cases. (Note: Test cases should be done at the end of requirement analysis and early design phase to identify any missing or vague requirements. If you cannot test something that means your requirements are not clear or testable. In that case the team should go back and ask the client for validation. All test cases must use a similar template: for each case there must be a test purpose, test data, expected results, and the date the test case was run (and returned the specified results) and name of the team member conducting the test).

Beside functions that described in the SRS. The team must identify nonfunctional requirements (Quality attributes) such as security, performance, accessibility, ease of use, ease of learning, maintainability, etc.) since the product must satisfy realistic operational constraints (operating system, database, hardware, and software components). The PM must indicate how these nonfunctional requirements can be met and any maintenance support the product need after release to the client (Note: This is a activity that many capstone team failed to achieve. Although the client does not ask for it but the project team must implement it as it is critical to the operation and it will exceed the users’ expectation and give more positive impression for the team).

When both functional and non-functional (Quality attributed) tasks are done. The team can begin to work on prototype, or screen display that will demonstrate the “look and feel” of the software product such as the main menu display of all functionalities that users will see when logon. The design documentation must show at least several different use cases (other than login/logout) in full depth. The team must review and justify any design issues or design decisions that are not clear at this time. If needed, the PM must call a meeting with the client to verify the requirements. (Note: This is the first time the client sees the actual demonstration of the team’s work. Prototype is important to verify the operation concepts that the team has. After viewing the prototype, the client often changes some requirements so the team must be prepared and not be disappointed. It is much better to accept changes at the earlier phase than at later phase).

If there are changes, the team must go back to update the software requirements specification (SRS) with new changes as well as all the affected use cases and documents. (Note: Many Capstone projects failed to do this and often have difficult during testing and maintenance phases later. It is very good practices to update all documents as soon as changes happen. The team must work together to draw a detailed class diagram or entity-relationship diagram. They must show all classes, relationships, attributes. It is possible to use UML notation since it is very popular in most global project. The team can create a data dictionary entries for all attributes in your model. Entries must be detailed, precise and unambiguous. Keep in mind that the concepts and attributes you are working with may have obvious meaning for you but may not for users.)