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

Trong pha thiết kế và xây dựng, tổ phải đưa mọi nỗ lực vào hoàn thành dự án trong hạn thời gian lịch biểu. Dùng danh sách dãy các nhiệm vụ, các thành viên tổ có thể thiết kế và thực hiện có trật tự các nhiệm vụ được phân công của họ tương ứng. Điều được khuyến cáo là họ thực hiện các yếu tố giao diện người dùng đồ hoạ (GUI) và các use case chủ yếu trước vì chúng là hữu ích cho việc biểu diễn bản mẫu cho khách hàng (Lưu ý: Vì từng dự án là khác nhau, chi tiết về bản mẫu có thể cũng thay đổi. Giáo sư thường cho chỉ dẫn riêng trong những dự án này.)

Với từng nhiệm vụ được thực hiện, người quản lí dự án (PM) phải phân công trách nhiệm cho các thành viên tổ để hoàn thành trong thời gian đã được lên lịch. Tổ phải tiến hành các cuộc kiểm điểm thiết kế, kiểm điểm mã, và kiểm điểm kế hoạch kiểm thử mọi lúc họ hoàn thành một chức năng chính để chắc rằng mọi sự xảy ra theo trật tự và với chất lượng cao. Ngay cả hai pha này (thiết kế và viết mã) cần được hiểu rõ bởi các thành viên tổ, điều quan trọng là tổ phối hợp nhiệm vụ của họ theo cách có nghĩa. PM phải không bao giờ cho phép bất kì thành viên nào né tránh công việc này hay hoàn thành dự án Capstone mà không có cơ hội phát triển kĩ năng này. (Lưu ý: Một số thành viên không thích thiết kế hay viết mã cho nên họ thường tình nguyện làm các hoạt động hỗ trợ như  SQA, SCM hay làm tài liệu.)

Các hoạt động thiết kế, viết mã và kiểm thử được yêu cầu với mọi thành viên cho nên PM phải giám sát thời gian hàng tuần dành cho từng thành viên và theo dõi thời gian của họ dành cho từng hoạt động. Mục đích là để nhận diện bất kì thời gian bất thường hay không mong đợi mà từng cá nhân đóng góp cho công việc của toàn tổ. Các pha này thường là khu vực có nhiều thứ xảy ra bất ngờ cho nên điều mấu chốt là giám sát các hoạt động một cách cẩn thận. PM cũng phải kiểm tra bất kì thay đổi nào với kế hoạch dự án gốc liên quan tới tính khả thi, khó khăn và rủi ro của dự án về bất kì độ lệch nào khỏi kế hoạch dự án (thực tế so với ước lượng).

Tổ nên có các cuộc họp hàng tuần để kiểm điểm lại tiến độ của nó và ước lượng chi phí về chất lượng (COQ) như số phần trăm nỗ lực trong pha này. COQ biếu thị cho chi phí đã xảy ra do thiếu chất lượng và những chi phí đã xảy ra trong việc đạt tới chất lượng. (Lưu ý: Chi phí của việc đạt tới chất lượng và chi phí do thiếu chất lượng có mối quan hệ nghịch đảo với nhau: khi đầu tư vào đạt tới chất lượng tăng lên, chi phí do thiếu chất lượng giảm đi.) COQ chỉ báo mọi nỗ lực được dành cho việc ngăn ngừa lỗi, nhận diện lỗi, và sửa lỗi. (Lưu ý: Ngăn ngừa lỗi bao gồm nỗ lực để ngăn cản các khiếm khuyết khỏi đưa vào dự án. Ngăn ngừa lỗi bao gồm mọi nỗ lực để giám định thiết kế hay thảo duyệt mã, lập trình cặp đôi, tuân theo chuẩn lập trình, huấn luyện tổ, thu thập và phân tích các độ đo. Nhận diện lỗi bao gồm mọi nỗ lực để khám phá chất lượng của công việc dự án. Nó bao gồm mọi hoạt động như kiểm thử, kiểm thử của người dùng, phân tích căn nguyên v.v. Sửa lỗi bao gồm mọi nỗ lực để giải quyết việc sửa chữa vấn đề trong dự án. Sửa lỗi có thể bao gồm nỗ lực làm lại và kiểm thử lại thiết kế, viết mã hay làm tài liệu.)

Chất lượng là rất quan trọng cho phát triển phần mềm cho nên tổ phải tuân theo qui trình dành cho các hoạt động thiết kế, viết mã và kiểm thử. Bất kì vấn đề nào trong cách tổ tuân theo qui trình hay bất kì cái gì làm tổ xa với qui trình đều phải được nhận diện để cho tổ có thể học từ những sai lầm. (Lưu ý: Đây là lúc sinh viên học về cách làm việc tổ và ích lợi của việc tuân theo qui trình. Trong các phân công trong lớp lập trình, sinh viên hiếm khi có cơ hội để kiểm điểm lại toàn bộ qui trình phát triển phần mềm và nhận diện vấn đề xảy ra ở đâu.) Bằng việc thực hiện những pha này, sinh viên áp dụng tri thức của họ và biến nó thành kĩ năng.

Mọi dự án phần mềm đều có rủi ro. Nếu tổ đã nhận diện ra các rủi ro đó và có kế hoạch giảm nhẹ chúng ngay từ đầu dự án thì đây là lúc họ nên kiểm điểm và cập nhật kế hoạch rủi ro của họ để xem có cảnh báo sớm nào đã xuất hiện không. Tổ có thể thảo luận về cách rủi ro xảy ra hay không xảy ra cũng như cách giải quyết chúng. PM phải có họp hàng tuần với tổ để nhận diện có vấn đề lớn nào không như chất lượng, kĩ thuật, thành viên tổ, rủi ro và vấn đề môi trường phát triển, v.v. điều tổ đã gặp phải trong khi hoàn thành pha này. (Lưu ý: Những cuộc họp này là thời gian học cho các thành viên để học về vấn đề thường xảy ra trong dự án phần mềm. Khi họ học chúng, họ cũng học cách giải quyết chúng.)

Trong các cuộc họp hàng tuần, các thành viên tổ phải nhận diện chức năng nào đã được thực hiện đầy đủ hay một phần, và cái gì còn chưa đầy đủ. Họ cũng phải giải thích mọi sai lệch khỏi kế hoạch gốc và tại sao họ đã ra quyết định khác đi. Họ phải thảo luận bất kì công việc không đầy đủ nào và tại sao chúng không đầy đủ. PM cần làm tài liệu cho bất kì thay đổi nào mà tổ đã làm cho kế hoạch của họ, các yêu cầu, thiết kế, hay kế hoạch thực hiện như các chức năng, use case, hay yêu cầu phi chức năng mà tổ đã hoặc thêm vào, bỏ đi, hay thay đổi so với bản kế hoạch đề nghị gốc. Tổ phải ước lượng cách chất lượng toàn thể của sản phẩm cuối cùng được nâng cao hay giảm đi như kết quả của những thay đổi này.

Sau khi viết mã được hoàn thành, mọi trường hợp kiểm thử phải được thực hiện để đảm bảo rằng phần mềm đáp ứng yêu cầu. Ngày kiểm thử và người cho chạy kiểm thử phải được ghi lại. Người quản lí kiểm thử cũng phải báo cáo mọi trường hợp kiểm thử thất bại. Riêng từng thành viên có thể giữ trách nhiệm về báo cáo không chính xác về kết quả kiểm thử. Với từng lỗi đã biết vẫn còn trong sản phẩm, người quản lí kiểm thử phải cung cấp mô tả ngắn gọn, đặt tỉ lệ nghiêm trọng của nó (thấp, vừa, cao) và mô tả giải pháp của nó và ước lượng nỗ lực được cần để sửa nó. Người quản lí kiểm thử phải phân tích những lỗi này để tìm ra liệu chúng có là kết quả của phân tích yêu cầu không đầy đủ, hay thiết kế, viết mã, lập kế hoạch dự án, hay bất kì nguyên nhân nào. Báo cáo này phải trung thực, đầy đủ, chính xác và dựa trên phương pháp tốt nhất mà tổ có thể thực hiện. (Lưu ý: Các lỗi không được báo cáo được tìm ra trong kiểm điểm của các thầy trong khoa phản ánh sự nghèo nàn làm việc của tổ và sẽ được lấy làm bằng chứng cho việc quản lí tổ không đầy đủ hay không thích hợp.)

Người quản lí kiểm thử phải tạo ra báo cáo cuối cùng dựa trên kiểm thử chấp nhận chính thức với cán bộ của khách hàng. Báo cáo này phải mô tả các trường hợp về tính dùng được, kịch bản kiểm thử hay kịch đoạn kiểm thử, chủ đề, hoàn cảnh, cái ra và kết quả. Tổ phải kiểm điểm các kết quả từ kiểm thử chấp nhận và so sánh các kiểm thử đã được tiến hành trước đây bởi tổ (kiểm thử đơn vị, kiểm thử tích hợp, kiểm thử hệ thống, kiểm thử rà lại) để tìm ra liệu có lỗi nào thoát ra khỏi kiểm thử của họ không.

Vào ngày cuối cùng của dự án Capstone, tổ sẽ họp cùng giáo sư để kiểm điểm lại mọi thứ họ đã học trong dự án. Các khoản mục tổ phải được chuẩn bị để thảo luận bao gồm: đánh giá cuối cùng về chất lượng toàn diện (làm việc tổ và qui trình), tóm tắt về mọi độ đo và tính hữu dụng của chúng, và thành tựu toàn diện. Các thành viên tổ phải được chuẩn bị để thảo luận về tính hiệu quả và chất lượng của qui trình của tổ của bạn, việc trao đổi, quản lí, và vật chuyển giao cuối cùng. Họ phải có bằng chứng để hỗ trợ cho vai trò, trách nhiệm của họ trong dự án. Khi tổ chuẩn bị cho việc kiểm điểm này, cân nhắc hai câu hỏi: “Bạn (như một tổ và như cá nhân) đã thực sự học được gì trong dự án Capstone này?” và “Bài học nào bạn sẽ khuyên cho tổ dự án tương lai?”

Trong toàn bộ dự án Capstone, tổ phải làm tài liệu các hoạt động của họ trong báo cáo. Báo cáo này phải có tóm tắt dành cho giáo sư và cho khách hàng. Nó nói cho họ bằng mô tả chính xác mọi hoạt động trong dự án cũng như tiến bộ của dự án trong từng pha. Bài tóm tắt nên trình bày thành tựu của tổ, kết luận của nó, các khuyến nghị, và vấn đề gặp phải. Báo cáo phải có chất lượng cao nhất: đầy đủ, đúng giờ, được viết tốt, được trình bày tốt và rõ ràng. Không có cớ nào cho bất kì cái gì kém hơn.

Báo cáo của tổ phản ánh nỗ lực và tiến bộ của tổ trong dự án. Báo cáo tốt là kết quả của cách làm việc tổ tốt, có qui trình, chú ý tới chi tiết, và hiệu năng tốt về công việc được yêu cầu. Sẽ khó che giấu hành vi tổ kém hiệu quả, thiếu qui trình, hay công việc chất lượng kém bằng báo cáo lớn lao. Bất kì báo cáo sai lạc và không chính xác sẽ bị phạt. Đừng cố làm giáo sư và khách hàng hiểu sai bằng báo cáo không đề cập tới vấn đề của tổ, thiếu tiến bộ hay các vấn đề quan trọng khác mà có thể làm giảm đi việc hoàn thành thành công của dự án của bạn. (Lưu ý: Đừng làm giáo sư hiểu sai và nói với thầy điều bạn nghĩ thầy muốn nghe. Nhiều tổ Capstone không chuyển giao được sản phẩm chất lượng nhưng đã tạo ra báo cáo hay với hi vọng rằng họ sẽ nhận được điểm tốt. Đó là gian lận vì họ đã không học gì. Xin nhớ cho rằng dự án Capstone được thiết kế cho sinh viên học về dự án “thực” trong công nghiệp. Nếu tổ có vấn đề, bạn phải làm tài liệu chúng để trong kiểm điểm cuối cùng, giáo sư và tổ có thể thảo luận và tìm ra giải pháp. Đó là học tập cho nên không có lí do gì để che giấu mọi sự với giáo sư.)

Báo cáo của bạn phải đầy đủ và chuyển vào việc cho điểm. Các giáo sư sẽ cho điểm điều được cho và điều được viết ở đó. Chính trách nhiệm của tổ là đảm bảo rằng tài liệu trong báo cáo được tổ chức tốt, rõ ràng và đã được kiểm điểm kĩ lưỡng về chất lượng. (Lưu ý: Nhiều sinh viên không biết rằng viết là kĩ năng mấu chốt và được người quản lí thuê người đánh giá cao). Báo cáo phải có chất lượng cao nhất có thể được. Một báo cáo được chuẩn bị tốt, viết tốt, làm tài liệu tốt phản ánh rõ tổ của bạn và gây ấn tượng tốt cho các giáo sư và khách hàng. Công việc không đầy đủ, hay được chuẩn bị kém gây ấn tượng rất xấu. Là một tổ, các bạn phải có lòng tự hào trong công việc của mình và biến nó thành báo cáo phản ánh chính xác công việc khó khăn và nỗ lực các bạn đã đưa vào trong dự án của mình. Đừng bao giờ làm công việc “đủ tốt” bởi vì nếu giáo sư của bạn không thích điều đó, thì người chủ lao động tương lai của bạn cũng không thích. (Lưu ý: Về truyền thống, công ti cho đại học dự án capstone cũng là công ti thường thuê sinh viên. Theo nhiều nghiên cứu đại học, trên 90% các thành viên dự án capstone được thuê bởi những công ti đó vì họ đã biết kĩ năng của sinh viên qua dự án này. Không cần làm đơn xin việc hay phỏng vấn vì chúng là không cần thiết. Người quản lí của công ti phân công dự án Capstone thường là người sẽ quyết định thuê sinh viên. Tất nhiên, trong toàn dự án, họ giám sát hiệu năng của sinh viên dựa trên thời gian sinh viên dành ra và chất lượng công việc của họ đã làm.)

—-English version—-

A guide to Capstone part 4

This is part 4 of the guide to Capstone project:

During the design and construction phases, the team must put all efforts to complete project within the schedule dateline. Using the list of sequence of tasks execution, team members can orderly design and implement their assigned tasks accordingly. It is recommended that they implement the main Graphical User Interface (GUI) elements and primary use cases first because they are useful for the prototype demonstration to the client (Note: Since each project is different, detail of the prototype may also vary. Professor usually gives specific instruction on these)

For each task to be implemented, Project Manager (PM) must assign team member responsible for the completion within a scheduled time. The team must conduct design reviews, code reviews, and test plans review every time they complete a major function to make sure that everything happens orderly and with high quality. Even these two phases (Design and Code) are well understood by team members, it is important that the team coordinate their tasks in meaningful ways. PM should never allow any member to avoid this work or to complete the Capstone project without the opportunity to develop this technical skills. (Note: Some members do not like design or code so they often volunteer to work on support activities such as  SQA, SCM or documentation).

Design, code and test activities are required for all members so PM must monitor weekly time spend for each member and track their time spent on each activity. The purpose is to identify any unusual or unexpected time needed to identify each person’s contributions to the overall team’s work. These phases are usually areas when many things happen unexpectedly so it is critical to monitor the activities carefully. PM must also check for any changes to the original plan regarding the project’s feasibility, difficulty and risks for any deviation from the project plan (actual vs. estimated).

The team should have weekly meetings to review its progress and estimate the Cost of Quality (COQ) as a percentage of effort in this phase. The COQ represents the costs which are happened due to a lack of quality and those which are happened in the achievement of quality. (Note: The costs of achieving quality and the costs due to lack of quality have an inverse relationship to one another: as the investment in achieving quality increases, the costs due to lack of quality decrease.) COQ indicates all effort devoted to defect prevention, defect identification, and defect correction. (Note: Defect Prevention includes efforts to prevent defects from entering the project. Defect prevention includes all efforts for design inspections or code walkthroughs, pair programming, follow programming standards, team training, collection and analysis of metrics. Defect identification includes all efforts to discover the quality of project works. It includes all activities such as testing, user testing, audit, root cause analysis, etc. Defect Correction includes all efforts to deal with fixing problems in the project. Defect correction may include efforts for rework and retesting of design, code or documentation).

Quality is very important to software development so the team must follow a process for the design, code and test activities. Any issues in the way the team follows the process or anything that detracts the team from the process must be identified so the team can learn from the mistakes. (Note: This is the time when students learn about teamwork and the benefit of following a process. During assignments in programming class, students rarely have opportunity to review the entire software development process and identify where problems happen). By implement these phases, students apply their knowledge and turn it into skills.

Every software projects have risks. If the team have identified risks and have plan to mitigate them at the beginning of the project then this is time where they should review and update their risks plan to see if any early warnings have occurred. The team can discuss on how risks happen or not happen as well as how to deal with them. The PM should have weekly meeting with the team to identify any significant problems such as quality, technical, team members, risk and development environmental issues, etc. that the team has encountered in completing this phase. (Note: These meetings are the learning time for members to learn about issues that happen often in software projects. As they learn about them, they also learn how to solve them.)

In weekly meetings, team members must identify what function has been fully or partially implemented, and what remains incomplete. They must also explain any deviations from their original plan and why they made decisions to differ. They must discuss any incomplete works and why they are incomplete. The PM need to document any changes that the team have made to their plans, their requirements, their design, or implementation plans such as functions, use cases, or nonfunctional requirements that the team have either added, dropped, or changed from your original proposal plan. The team must evaluate how the overall quality of the final product is enhanced or diminished as a result of these changes.

After coding is done, all test cases must be executed to make sure that the software meets requirements. The date of the test and the person running the test must be recorded. Test manager must also report any test cases that fail. Individual members may be held responsible for inaccurate reporting of test results. For each known defect remaining in the product, test manager must provide a brief description, rate its severity (Low, Medium or High) and describe its solution and an estimate of effort required to fix it. Test manager must analyze these defects to find out whether they are the result of a incomplete requirements analysis, design, code, project planning, project management, or whatever causes. The report must be honest, completed, accurate and based on the best methods the team can execute. (Note: Unreported defects found during the faculty review reflect poorly on the team and will be taken as evidence of incomplete or inadequate team management).

Test manager must create a final report based on formal acceptance tests with the client’s staff. The report must describe the usability tests, the test scenarios or test scripts, the subjects, the conditions, the outcomes and results. The team must review results from acceptance tests and compare with those tests conducted earlier by the team (Unit tests, integration tests, system tests, regression tests) to find out if any defects escape their tests.

On the last day of the Capstone project, the team will meet with the professor to review things that they learned during the project. Items the team should be prepared to discuss include: final assessment of overall quality (teamwork and process), summary of all metrics and their usefulness, and overall achievement. Team members must be prepared to discuss the effectiveness and quality of your team’s process, communications, management, and ultimate deliverables. They must have evidences to support their roles, responsibilities during the project. As the team prepares for this review, consider two questions: “What have you (as a team and as individuals) really learned in this Capstone project?” and “What lessons would you recommend to future project teams?”

Throughout the Capstone project, the team must document their activities in a report. The report should have a summary for the professor and the client. It tells them in an accurate description of all activities in the project as well as its progress during each phase. The summary should present the team’s accomplishments, its conclusions, recommendations, and problems encountered. The reports must be of the highest quality: complete, on-time, well written, well presented and clear. There is no excuse for anything less.

The team’s reports reflect on the team’s efforts and progress during the project. Good reports are a result of great teamwork, process, attention to detail, and good performance on the required works. It will be difficult to disguise a ineffective team behavior, lack of progress, or poor quality work with a great report. Any misleading and not accurate reports will be penalized. Do not attempt to mislead the professor and the client with a reports that fail to address team problems, lack of progress or other important issues that may detract from the successful completion of your project. (Note: Do not mislead the professor and tell him what you think he wish to hear. Many Capstone teams failed to deliver a quality product but created a wonderful report with the hope that they will receive a good grade. That is cheating as they have not learn anything. Please remember that Capstone project is designed for students to learn about “real” project in the industry. If the team has problems, you must document them so during final review, professor and the team can discuss and find solutions. That is learning so there is no reason to hide things from professor).

Your reports must be complete and turn in for grading. Professors will grade what are given and what is written in there. It is the team’s responsibility to make sure that materials in the report are well organized, clear and have been thoroughly reviewed for quality. (Note: Many students do not know that writing is a critical skill and highly value by hiring managers). The reports must be of the highest quality possible. A well prepared, well written, well documented report reflects well on your team and makes good impression on the professors and clients. Incomplete, or poorly prepared work makes a very poor impression. As a team, you must take pride in your work and turn in reports that accurately reflect the hard work and effort you are putting into your projects. Never turn in “good enough” work because if your professor do not like it, so does your future employer. (Note: Traditionally, the company that gives the capstone projects to university is also the company that often hire students. According to several university studies, over 90% of capstone project members are hired by those companies since they already know the skills of students via the project. There is no need for any job application or interviews as they are not necessary. The company’s managers assign to Capstone usually are the one who will make decision to hire students. Of course, throughout the project, they monitor students’ performance based on the time they spend and their quality of works already.)