Nhiều sinh viên đã viết cho tôi hỏi xin giúp đỡ về dự án Capstone của họ. Vì đây là dự án “thực” đầu tiên, nhiều người lo lắng và không chắc về phải làm gì. Dựa trên yêu cầu của họ, tôi đã viết bản hướng dẫn tóm tắt cho dự án Capstone dựa trên điều tôi đã dạy ở Carnegie Mellon (mỗi trường có thể khác) mà một số trong các bạn có thể thấy nó là hữu dụng:

Dự án Capstone được thiết kế để giúp cho sinh viên kinh nghiệm việc phát triển phần mềm “thế giới thực”. Qua vài tháng tiếp, tổ của bạn sẽ thiết kế và xây dựng sản phẩm phần mềm bằng việc dùng tri thức bạn đã học trong ba năm quá khứ trong trường. Đây là cơ hội cho bạn áp dụng tri thức của bạn và chuyển nó thành kĩ năng “thực”. Bằng việc tuân theo hướng dẫn này, bạn sẽ học các kinh nghiệm có giá trị trong làm việc tổ, giải quyết vấn đề, qui trình phần mềm, và quản lí dự án. Đây là những kĩ năng mà công nghiệp phần mềm cần và mong đợi người tốt nghiệp biết.

Ngày nay phát triển phần mềm vẫn còn có vấn đề. Nhiều dự án không đáp ứng lịch biểu của chúng. Ngay cả khi được chuyển giao, nhiều sản phẩm phần mềm chưa bao giờ được dùng vì chất lượng thấp. Điều đáng quan tâm là các dự án này không thất bại bởi vì các lí do kĩ thuật mà chúng thất bại do quản lí dự án kém và làm việc tổ không hiệu quả. Nói cách khác, chúng thất bại do các lí do có liên quan tới “qui trình” hơn là “công nghệ”. Đó là lí do tại sao trong các dự án Capstone, điều quan trọng nhất mà sinh viên phải học là “làm việc tổ” và “qui trình” như lập kế hoạch, quản lí và thực hiện dự án phần mềm.

Phát triển phần mềm là hoạt động phức tạp. Mặc dầu các ngôn ngữ lập trình và công cụ cho phép người phát triển viết nhiều mã nhanh hơn, nhưng viết mã chỉ đại diện cho một phần nhỏ của hoạt động phát triển phần mềm. Học về phát triển phần mềm hiệu quả, tổ của bạn phải tuân theo cách tiếp cận vòng đời phần mềm và tạo ra một loạt các tài liệu. Tổ của bạn được yêu cầu đệ trình các báo cáo pha dự án được viết ra trong toàn thể dự án capstone. Các báo cáo này được dùng để làm tài liệu cho tiến bộ của tổ và để nhận diện các vấn đề mà tổ tìm ra. Các báo cáo này là công cụ có giá trị cho quản lí dự án và tự đánh giá của tổ. Chúng cũng cung cấp cho giáo sư của bạn các thông tin họ cần để đánh giá hiệu năng của tổ và cung cấp hướng dẫn cho tổ trong dự án Capstone project.

Trước khi bạn bắt đầu, có vài điều bạn cần biết: Bạn phải KHÔNG BAO GIỜ nhảy vào viết mã như bạn nghĩ bạn có thể làm. Đây là vấn đề thông thường trong các sinh viên. Nhiều người nghĩ họ đã biết về giải pháp cho nên họ bắt đầu viết mã ngay. Đó là lí do tại sao nhiều dự án Capstone thất bại. Xin nhớ cho rằng dự án Capstone KHÔNG phải là phân công nhiệm vụ trong lớp lập trình. Bạn không học về Java, PHP, hay C++ ở đây. Bạn đã học chúng trong các năm trước và không cần lặp lại ở đây. Dự án Capstone là về thực hiện vòng đời phát triển phần mềm. Nó sẽ giúp bạn hiểu mọi bước cần thiết để xây dựng chất lượng của sản phẩm phần mềm. Xin nhớ cho rằng viết mã chiếm ít hơn 20% của mọi công việc được cần tới trong dự án phần mềm điển hình. Không dự án nào đã bao giờ thất bại vì viết mã nhưng bởi vì mọi người KHÔNG tuân theo qui trình. Cho nên bạn phải học về qui trình phần mềm và không bỏ qua bất kì bước nào. Một khi bạn học mọi bước này, bạn cũng phát triển kĩ năng phát triển riêng của bạn và do đó không có vấn đề gì khi làm việc trong công nghiệp phần mềm.

Phần lớn các dự án Capstone được trao cho bạn bởi các công ti bên ngoài (khách hàng) trong cộng tác với đại học của bạn. Về truyền thống, khách hàng cho đại học của bạn bản đặc tả yêu cầu phần mềm (SRS) cho dự án Capstone. Phần lớn thời gian, yêu cầu là mông lung và không được xác định rõ (Tất nhiên, nó là được dự định cho bạn học về phân tích yêu cầu). Như một tổ, bạn phải kiểm điểm yêu cầu một cách cẩn thận để nhận diện từng cấu phần hệ thống và chức năng. Tổ của bạn phải hiểu điều khách hàng (công ti phần mềm bên ngoài) muốn tổ thực hiện. Tất nhiên, bạn phải biết cái gì đó về khách hàng. Bước đầu tiên là tổ viết ra phát biểu ngắn mô tả công việc của khách hàng của bạn và cách họ vận hành như họ là ai, họ làm gì v.v. (Bạn học về kinh doanh của họ). Sau đó, bạn phải phỏng vấn khách hàng để hiểu sản phẩm và dịch vụ của họ. Bạn muốn biết cách họ làm công việc, cách họ giải quyết thông tin, cách họ phát triển phần mềm (bạn học về qui trình công việc của họ). Bạn phải kiểm điểm công nghệ họ dùng để hiểu nhu cầu của họ và các lí do tại sao họ muốn tổ của bạn làm việc trên dự án này. Bằng việc hỏi họ, thảo luận với họ tổ của bạn sẽ biết nhiều thêm về qui trình của khách hàng và yêu cầu của họ (Xin ôn lại tài liệu của lớp kĩ nghệ yêu cầu).
Một khi tổ của bạn biết lí do và yêu cầu của khách hàng, bạn có thể bắt đầu viết ra phát biểu viễn kiến mô tả dự án capstone bằng những cấu phần hệ thống riêng mà tổ bạn phải phát triển để đáp ứng cho nhu cầu của khách hàng. Bạn có thể không có khả năng đáp ứng được tất cả mọi yêu cầu mà khách hàng đã trao cho đại học của bạn, cho nên giới hạn viễn kiến của bạn vào các cấu phần khả thi và hữu dụng. (Đây là “thủ đoạn” thông thường trong các dự án Capstone, vì khách hàng bao giờ cũng đòi hỏi nhiều cho nên bạn phải áp dụng kĩ năng phân tích và thương lượng ở đây – Đây là chỗ bạn cũng học kĩ năng mềm: Kĩ năng thương lượng). Bạn phải giải thích cho khách hàng của bạn rằng tổ của bạn muốn nhận diện vấn đề, hay nhu cầu mà dự án Capstone của bạn sẽ giải quyết cho khách hàng. Bạn phải nhận diện khách hàng và người dùng của hệ thống được đề nghị và cách sản phẩm mà tổ bạn dựng có thể giúp cho họ. (Đây là phần mấu chốt của mọi dự án phần mềm. Tổ của bạn phải có khả năng thuyết phục khách hàng xác định phạm vi của dự án và giới hạn các yêu cầu vào cái gì đó mà tổ của bạn có thể thực hiện được trong thời gian hợp lí. Kĩ năng thương thảo của bạn là rất quan trọng ở đây).

Vì khách hàng có thể không quen thuộc với điều bạn đề nghị (họ bao giờ cũng nói rằng họ không hiểu thuật ngữ kĩ thuật), tổ của bạn phải tạo ra tập các biểu đồ use case trường hợp sử dụng (chỉ ra các tác nhân, qui trình, biên hệ thống) cho hệ thống. Phải chắc đưa vào các chức năng quản  trị bản chất trong biểu đồ của bạn. Viết lời dẫn tóm tắt cho từng use case với việc giải thích use case đó. Chỉ ra mức ưu tiên của các use case như # 1 cho use case bản chất đối với vận hành hệ thống; # 2 cho use case là không bản chất với vận hành hệ thống nhưng sẽ tăng thêm giá trị đáng kể cho người dùng hệ thống; và # 3 cho use case sẽ thêm một số giá trị nhỏ cho người dùng hệ thống. Mô tả vắn tắt mọi tác nhân (người dùng, hệ thống hay tổ chức) những người tương tác với hệ thống của bạn, như được chỉ ra trong biểu đồ của bạn. Đừng giả định rằng nghĩa của bất kì use case, tác nhân, hay chức năng nào bị bỏ qua cho khách hàng của bạn; mô tả của bạn phải rất rõ ràng và không nhập nhằng. (Xin ôn lại tài liệu lớp yêu cầu về chỉ dẫn cách thực hiện điều đó).

Bằng việc dùng các kịch bản use-case, tổ của bạn sẽ hiểu nhiều hơn về các yêu cầu chức năng của dự án Capstone. Nó cũng làm cho mọi cấu phần được đề nghị thành thấy được nhiều hơn đối với khách hàng của bạn khi bạn thương lượng và thảo luận với họ về phạm vi của dự án. (Cái gì cần giữ và cái gì không cần giữ trong thương lượng). Tổ phải kiểm điểm phạm vi và độ phức tạp của hệ thống được đề nghị của bạn và ước lượng công việc tham gia vào đó. (Đây là chỗ công việc tổ thành rất mấu chốt vì bạn thảo luận với từng thành viên tổ về thời gian và nỗ lực cần dành ra để hoàn thành các nhiệm vụ này. Nhớ rằng đây chỉ là ước lượng sơ khởi, mọi người đều có ý kiến riêng của họ, tổ phải học cách cộng tác để đi tới ước lượng hợp lí.)

Từng thành viên tổ phải ước lượng nỗ lực được cần tới (theo man-hours), để hoàn thành các pha phân tích yêu cầu và thiết kế của dự án. Họ phải giải thích cách ước lượng của họ được suy ra cho các thành viên tổ khác để cho cùng nhau họ có thể đi tới ước lượng toàn thể của cả tổ. (Có thể làm ước lượng trung bình ở đây, nếu một nửa tổ đi tới 100 man-hours và nửa kia ước lượng 200 man-hours thì bạn có thể đồng ý điều chỉnh ước lượng tổng thể là 150 giờ).

Từng thành viên tổ phải ước lượng nỗ lực được cần tới (theo man-hours), để làm các pha xây dựng và kiểm thử của dự án. Họ có thể ước lượng nỗ lực để thực hiện điểm use case cho cả # 1 (ưu tiên cao) và  # 2 (ưu tiên trung bình) nhưng không thể làm cho # 3 vì điều này nên có tính thương lượng với khách hàng hay liệu họ có muốn tổ làm điều đó không. Dùng thông tin này để ước lượng nỗ lực toàn bộ được yêu cầu để hoàn thành cả hai kiểu use case. Thành viên tổ phải giải thích được cách họ làm ước lượng. (Nhớ rằng bạn phải xem xét tới các ước lượng từ từng thành viên tổ rồi thảo luận để có sự thoả thuận của tổ về ước lượng toàn thể. Bạn sẽ học nhiều về làm việc tổ trong hoạt động này.)

Từng thành viên tổ phải ước lượng “hoạt động nỗ lực hỗ trợ” được yêu cầu cho việc quản lí dự án, họp, viết, kiểm điểm, báo cáo, làm tài liệu, viết mã và kiểm điểm thiết kế, tích hợp và kiểm thử mức hệ thống, các kĩ năng học và kĩ năng phát triển khác như học công nghệ mới, hoạt động đảm bảo chất lượng QA và các qui trình khác hay các vấn đề quản lí qui trình có liên quan tới dự án của bạn hay tổ của bạn. (Đây là lí do tại sao nhiều dự án phần mềm thất bại bởi vì nhiều người quản lí dự án quên tính tới những nỗ lực hỗ trợ này vì họ chỉ làm ước lượng về khía cạnh kĩ thuật mà không có khía cạnh hỗ trợ. Đó là lí do tại sao nhiều dự án đã không đáp ứng lịch biểu.)

Tổ phải trình bày phân tích yêu cầu và các ước lượng dự án (Đây vẫn là ước lượng sơ khởi vì phạm vi vẫn còn đang được thương lượng với khách hàng). Bạn phải làm tài liệu cho những hoạt động này và có khả năng giải thích cho khách hàng và giáo sư của bạn trong bài trình bày dưới dạng họ có thể hiểu được. Bạn phải nói rõ ràng và biện minh cho bất kì giả định nào bạn đã làm trong ước lượng của bạn. Dựa trên ước lượng nỗ lực của bạn (theo Man-hours), bạn phải giải thích chính xác trường hợp sử dụng use case nào mà tổ của bạn sẽ thực hiện cho dự án này cũng như ước lượng về tổng nỗ lực công việc theo thời gian lịch biểu nhà trường. Tất nhiên bạn phải giải thích các lí do của bạn tại sao tổ của bạn ra quyết định đó (Hoạt động này sẽ giúp cho bạn học kĩ năng trình bày, kĩ năng thương lượng, kĩ năng cộng tác, và kĩ năng lắng nghe – những kĩ năng mềm này là bản chất trong công nghiệp phần mềm). Tất nhiên khách hàng có thể không đồng ý (Họ bao giờ cũng làm điều đó trong mọi dự án Capstone vì họ muốn thấy thêm về kĩ năng mềm của bạn. Bạn cần thuyết phục họ bằng việc có các lập luận rõ ràng và logic như ưu tiên, ích lợi và lịch biểu. Đến cuối, phần lớn thời gian khách hàng đồng ý để cho bạn thực hiện mọi # 1 (ưu tiên cao) và # 2 (ưu tiên vừa) vì lịch biểu nhà trường cho phép.)

Đây là pha đầu của Capstone thường mất ít nhất một tháng (4 tuần) để hoàn thành. Nó yêu cầu tri thức về phân tích yêu cầu, biểu đồ trường hợp sử dụng use case, ước lượng, vòng đời phát triển phần mềm, lập kế hoạch dự án và kĩ năng mềm.

—-English version—-

A Guide to the Capstone projects part 1

Many students wrote to me asking for help on their Capstone projects. Since this is their first “real” project, many are worry and not sure about what to do. Based on their requests, I wrote a brief guideline for Capstone project based on what I taught at Carnegie Mellon (Each school may differ) that some of you may find it useful:

The Capstone project is designed to help students experience “real-world” software development. Over the next several months, your team will design and build a software product using the knowledge that you have learned in the past three years in school. This is your chance to apply your knowledge and transfer it into “real” skills. By following this guideline, you will learn valuable experience in teamwork, problem solving, software process, and project management. These are skills that software industry needs and expects graduates to know.

Today software development is still having problems. Many projects do not meet their schedule. Even when delivered, many software products are never use because of low quality. The interesting thing is these projects do not fail for technical reasons but they fail due to bad project management and ineffective teamwork. In other words, they fail for reasons related to “Process” rather than “Technology”. That is why during Capstone projects, the most important things students must learn are “teamworks” and “process” such as software project planning, management, and execution.

Developing software is a complex activity. Although programming languages and tools allow developers to write more code faster, but coding represents only a small part of the software development activity. To learn about effective software development, your team must follow a software life cycle approach and produce a series of documents. Your team is required to submit written project phase reports throughout the capstone project. These reports are used to document the team’s progress and to identify any serious problems that the team finds. These reports are valuable tool for project management and team self-assessment. They also provide your professors with the information they need to assess the team’s performance and to provide guidance to the team during the Capstone project.

Before you start, there are few things you need to know: You must NEVER jump into coding as you think you could. This is a common problem among students. Many think they already know the solution so they start coding right away. That is why many Capstone projects failed. Please remember that Capstone project is NOT an assignment in programming class. You are not learning about Java, PHP, or C++ here. You already learned them in previous years and there is no need to repeat here. Capstone project is about implementing a software development life cycle. It will help you to understand all the steps necessary to build quality a software product. Please remember that coding is less than 20% of all the works needed in a typical software project. No project ever fail because of coding but because of people do NOT follow a process. So you must learn about the software process and do not skip any step. Once you learn all these steps, you also develop your own development skills and therefore should not have any problem working in the software industry.

Most Capstone projects are given to you by an outside companies (The client) in collaboration with your university. Traditionally, the client gives your university a software requirements specification (SRS) for the Capstone project. Most of the time, the requirements are vague and not well defined (Of course, it is intentional for you to learn about requirements analysis). As a team, you must review the requirements careful to identify each system components and functions. Your team must understand what the client (The outside software company) want the team to do. Of course, you must know something about the client. The first step is to the team to write a short statement describing the work of your client and the ways they operate such as who they are, what they do etc. (You learn about their business). After that,  you must interview the client to understand their products and services. You want to know how do they work, how do they handle information, how do they develop software (You learn about their business process). You must review the technology that they use to understand their needs and the reasons why they want your team to work on this project. By asking them, discuss with them your team will know more about the client ‘s process and their requirements (Please review the Requirements Engineering class materials).
Once your team knows the reasons and the client’s requirements. You can start to write a vision statement describing the capstone project with specific system components that your team must develop to meet the client’s needs. You may not be able to meet all requirements that the client gave to your university, so limit your vision to components that are feasible and useful. (This is a common “trick” in Capstone projects, as the client always ask for more so you must apply your analysis and negotiation skills here – This is where you also learn soft skills: Negotiation skills). You must explain to your client that your team want to identify the problem, or the need that your Capstone project will solve for the client. You must identify the customers and users of the proposed system and how the product that your team build may help them. (This is a critical part of every software project. Your team must be able to convince the client to define the scope of the project and limit the requirements to something that your team could implement within a reasonable time. Your negotiation skills are very important here).

Since the client may not be familiar with what you propose. (They always say that they do not understand technical terms) Your team must create a set of use case diagrams (show actors, processes, system boundaries) for the system. Be sure to include essential administrative functions in your diagram. Write a brief narrative for each use case explaining the use case. Indicate the use case’s priority level such as # 1 for use case that is essential for system operation; # 2 for use case is not essential for system operation but would add significant value to system’s users; and # 3 for use case that would add some small value to the system’s users. Briefly describe all actors (users, systems, or organizations) who interact with your system, as indicated in your diagram. Do not assume that the meaning of any use case, actor, or function is obvious to your client; your descriptions must be very clear and unambiguous. (Please review the requirements engineering class materials on instruction how to do it).

By using use-case scenarios, your team will understand more about functional requirements of the Capstone project. It also make all proposed components more visible to your client as you negotiate and discuss with them about the scope of the project. (What to keep and what not to keep during negotiation). The team must review the scope and complexity of your proposed system and estimate the work involved. (This is where teamwork is very critical as you discuss with each team member about the time and effort it takes to complete these tasks. Remember that this is only a rough estimates, everybody have their own opinion, the team must learn to collaborate to come up with a reasonable estimates).

Each team member must estimate the effort required (in man-hours), to complete the requirements analysis and design phases of the project. They must explain how their estimate is derived to other team members so together they can come up with an team’s overall estimates. (It is possible to do an average estimates here, if half of the team come up with 100 man-hours and the other half estimates at 200 man-hours then you may agree to adjust the overall estimate as 150 hours).

Each team member must estimate the effort required (in man-hours), to do the construct and test phases of the project. They may want to estimate the effort to implement use case points for both the # 1 (High priority) and # 2 (Medium priority) but may not do the # 3 since this should be negotiate with the client on whether they want the team to do that. Use this information to estimate the total effort required to complete both types of use cases. Team member must explain how they estimate. (Remember that you must take into consideration estimates from each team member then discuss to have the team agree on a overall estimates. You will learn a lot about teamwork in this activity).

Each team member must estimate the “Supporting effort activity” required for project management, meetings, writing, reviewing, reports, documentation, code and design reviews, integration and system level testing, learning and other developing skills such as learning new technologies, QA activities and other process or process management issues that are relevant to your project or your team. (This is why many software project failed because many project managers forget to take into consideration these supporting efforts as they only estimate the technical aspect but not the supporting aspect. That is why many projects did not meet schedule).

The team must present the requirements analysis and project estimates (This is still a rough estimates as the scope is still being negotiated with the client). You must document these activities and be able to explain to the client and your professor in a presentation using terms that they can understand. You must articulate and justify any assumptions you have made in your estimates. Based on your effort estimates (in Man-hours), you must explain exactly which use cases your team will implement for this project as well as an estimate of total work effort in school calendar time. Of course you must explain your reasons why your team make that decision (This activity will help you to learn presentation skills, negotiation skills, collaboration skills, and listening skills – these soft-skills are essential in software industry). Of course the client may disagree (They always do that in every Capstone projects because they want to see more of your soft-skills. You need to convince them by having a clear and logical reasons such as priority, benefits and schedule. In the end, most of the time the client agree to let your team implement all # 1 (High priority) and # 2 (Medium priority) as your school schedule permit.)

This first phase of Capstone usually takes at least one month (4 weeks) to complete. It requires knowledge of requirements analysis, use case diagram, estimates, software development life cycle, project planning, and soft skills.