Đề tài Quy trình phát triển SCRUM, Visual Studio Team System Team Foudation Server, ứng dụng quản lí kinh doanh quán Coffee

BÁO CÁO ĐỀ TÀI : QUI TRÌNH PHÁT TRIỂN SCRUM, VISUAL STUDIO TEAM SYSTEM TEAM FOUNDATION SERVER, ỨNG DỤNG QUẢN LÍ KINH DOANH QUÁN COOFFEE GVHD: Trần Trọng Tuyên Nhóm SV thực hiện gồm: Lê Kim Hưng (Nhóm trưởng) Đặng Thị Hồng Sâm Huỳnh Lý Ngọc Văn Thị Thùy Trinh CHƯƠNG I: QUY TRÌNH PHÁT TRIỂN PHẦN MỀM LINH HOẠT SCRUM I. Định nghĩa: Scrum là một trong các khung làm việc linh hoạt phổ biến nhất hiện nay. Scrum được dùng để quản lý các dự án phát triển phần mềm, nhưng cũng được dùng trong các công việc khác với độ phức tạp và tính sáng tạo rất đa dạng. Dựa trên lý thuyết quản lý thực nghiệm: Scrum sử dụng kỹ năng lặp và tăng dần để tối ưu hóa sự hiệu quả và kiểm soát rủi ro. Scrum rất đơn giản, dễ học và khả năng ứng dụng lớn. Vì vậy, để dùng scrum chúng ta cần nghiên cứu các thành phần sau đây: II. Các thành tố cấu tạo trong Scrum: 1. Ba giá trị cốt lỗi: a) Minh bạch (Transparency): Trong Scrum, minh bạch được xem như là giá trị cốt lõi cơ bản nhất. Muốn thành công với Scrum, thông tin phải minh bạch và thông suốt. Từ đó mọi người với các vai trò khác nhau có đủ thông tin cần thiết để tiến hành các quyết định có giá trị để nâng cao hiệu quả công việc. Các công cụ và cuộc họp trong Scrum luôn bảo đảm thông tin được minh bạch cho các bên. b) Thanh tra (Inspection): Công tác thanh tra liên tục các hoạt động trong Scrum bảo đảm cho việc phát hiện các vấn đề cũng như giải pháp để thông tin đa dạng và hữu ích đến được với các bên tham gia dự án. Với việc truy xét kỹ càng và liên tục là cơ chế khởi đầu cho việc thích nghi và cải tiến liên tục trong Scrum. c) Thích nghi (Adaptation): Scrum là một trong những phương pháp phát triển rất linh hoạt. Nhờ đó nó mang lại tính thích nghi rất cao. Scrum có thể phản hồi lại các thay đổi một cách tích cực nhờ đó mang lại nhiều thành công lớn cho dự án. 2. Ba vai trò: a) Product Owner (Chủ sản phẩm): Là người chịu trách nhiệm về sự thành công của dự án, là người định nghĩa các yêu cầu và đánh giá cuối cùng đầu ra của các nhà phát triển phần mềm. b) Scrum master (Đội trưởng): Là người hiểu biết sâu sắc về Scrum và đảm bảo nhóm có thể làm việc hiệu quả với Scrum. c) Team (Đội sản xuất): Là một nhóm liên chức năng có nhiệm vụ giải quyết các yêu cầu từ Product Owner để tạo ra các gói sản phẩm tốt nhất. 3. Bốn cuộc họp (Four ceremonies): a) Sprint Planning (Lập kế hoach cho Sprint): Đội sản xuất sẽ gặp gỡ với Product Owner để lên kế hoạch làm việc cho một Sprint. Các công việc như là: chọn lựa các yêu cầu cần phát triển, phân tích và nhận biết các công việc phải làm kèm theo các ước lượng thời gian cần thiết để hoàn tất các công việc. Scrum sử dụng phương thức lập kế hoạch từng phần và tăng dần theo thời gian. Theo đó, việc lập kế hoạch không diễn ra duy nhất một lần trong vòng đời của dự án mà được lặp đi lặp lại, có sự thích nghi với tình hình thực tiễn trong tiến trình đi đến sản phẩm. b) Daily Scrum (Buổi họp hằng ngày): Scrum Master cùng với Đội sản xuất tổ chức họp hàng ngày để Đội chia sẽ tiến độ công việc cũng như các khó khăn gặp phải trong quá trình phát triển phần mềm suốt một Sprint. c) Sprint Review (Buổi họp đánh giá): Cuối Sprint, đội sản xuất cùng với Product Owner sẽ rà soát lại các công việc đã hoàn thành trong Sprint vừa qua và đề xuất các chỉnh sửa hoặc thay đổi cần thiết cho sản phẩm. d) Sprint Retrospective (Buổi họp cải tiến): Dưới sự chỉ đạo của Scrum Master, Đội sản xuất sẽ rà soát lại toàn diện Sprint vừa kết thúc và tìm cách cải tiến quy trình làm việc cũng như bản thân sản phẩm. 4) Ba công cụ (Artifacts): a) Product backlog: Có thể hiểu như là danh sách các yêu cầu của dự án. Product Owner chịu trách nhiệm sắp xếp độ ưu tiên cho từng hạng mục trong Product Backlog dựa trên các giá trị do Product Owner định nghĩa. b) Sprint backlog: Là kết quả của buổi họp lập kế hoạch cho một Sprint với sự kết hợp giữa Product Owner và Đội sản xuất. Họ sẽ cùng nhau phân tích các yêu cầu theo độ ưu tiên từ cao xuống thấp để hiện thực hóa các hạng mục trong Product Backlog dưới dạng danh sách công việc. c) Burndown Chart: Đây là biểu đồ hiển thị xu hướng của dự án dựa trên lượng thời gian cần thiết để hoàn tất công việc. Burndown Chart còn được dùng để theo dõi tiến độ của một Sprint hoặc của cả dự án. III. Nguyên lý hoạt động của Scrum: Với mỗi dự án thì nhiệm vụ của Product Owner là tạo ra các Product Backlog chứa các yêu cầu của dự án với các hạng mục được sắp xếp theo thứ tự ưu tiên. Đội sản xuất sẽ có nhiệm vụ hiện thực hóa các hạng mục do Product Owner yêu cầu với sự lặp đi lặp lại các giai đoạn nước rút trong vòng 2 đến 4 tuần, với đầu vào là các Product Backlog và đầu ra là các gói sản phẩm có thể chuyển giao được. Trong lúc cùng nhau đua nước rút thì Đội sản xuất cùng họp với Product Owner để lên kế hoạch cho từng Sprint. Kết quả của mỗi buổi họp là các Sprint Backlog. Trong quá trình phát triển Đội sản xuất sẽ thường xuyên cập nhật Sprint Backlog và thực hiện công việc này hằng ngày để cùng nhau chia sẽ tiến độ công việc cũng như các khó khăn trong quá trình làm việc. Mỗi Sprint kết thúc là lúc nhóm tạo ra các gói phần mềm có thể chuyển giao được. Cuối mỗi Sprint, Đội sản xuất sẽ cùng họp đánh giá với Product Owner để thấy được Đội sản xuất đã chuyển giao được những gì, còn những gì phải làm hoặc phải thay đổi, cải tiến. Sau khi cuộc họp đánh giá kết thúc, Scrum Master và Đội sản xuất sẽ tổ chức họp cải tiến để tìm ra các cải tiến mới trước khi Sprint tiếp theo bắt đầu. Các Sprint sẽ được lặp đi lặp lại cho tới khi các hạng mục trong Product Backlog được hoàn tất hoặc khi Product Owner quyết định dừng dự án căn cứ vào tình hình thực tế. Với chiến thuật “quan trọng làm trước” nên các hạng mục mang lại giá trị lớn cho dự án. Do đó, Scrum luôn mang lại giá trị tốt nhất cho người đầu tư cho dự án. Qui trình luôn được cải tiến nên nhóm Scrum thường có năng suất hoạt động cao và đây là lợi ích mà Scrum mang lại cho các tổ chức. IV. So sánh Scrum và các quy trình phần mềm truyền thống: 1. Các quy trình truyền thống: a) Quy trình thác nước(Waterfall): chia dự án phần mềm gồm các giai đoạn: đặt tả yêu cầu, thiết kế hệ thống, cài đặt (lập trình), kiểm thử và bảo trì. Quy trình này dễ quản lí nhưng kém linh hoạt và không hiệu quả bởi có sự thay đổi trong giai đoạn sau sẽ có sự ảnh hưởng rất lớn đến các giai đoạn trước. Tất cả các yêu cầu công việc được xác định trong quá trình lập kế hoạch gồm những việc cơ bản như: xác định các yêu cầu sản phẩm, chi phí sản phẩm, ngày hoàn thành… Dẫn đến khả năng thành công thấp nếu có những yêu cầu mới hoặc chỉnh sửa sản phẩm sẽ có sự ảnh hưởng rất lớn đến các giai đoạn trước. b) Quy trình xoắn ốc (Spiral): chia dự án thành các giai đoạn như: lập kế hoạch, phân tích rủi ro, giao tiếp khách hàng, đánh giá lại, sản xuất và phân phối. Nhưng chưa được sử dụng rộng rãi. 2. Đối với quy trình Scrum: Điểm mạnh nhất đó là việc linh hoạt, dự án không được cố định từ đầu về thời gian hoàn thành hay những yêu cầu mà nó sẽ được xác định khi phát triển thực tế. Phân phối sản phẩm mềm dẻo: nội dung sản phẩm chuyển giao được xác định linh hoạt theo môi trường sử dụng thực tế. Thời gian biểu linh hoạt: có thể muộn hoặc sớm hơn so với kế hoạch ban đầu. Chất lượng sản phẩm tốt và giảm rủi ro sản xuất, chi phí thấp. Khả năng trao đổi giữa khách hàng và nhà phát triển, giữa những thành viên trong đội được đặt lên mức cao. Tốc độ phát triển nhanh, tiết kiệm thời gian. Việc chuẩn bị hành động cho những thay đổi trong quá trình phát triển tốt hơn vì hầu như hàng ngày luôn có những buổi họp đánh giá lại ở những vòng lặp phát triển. Các bugs (lỗi) và các vấn đề được phát hiện sớm hơn rất nhiều so với các phương pháp truyền thống bởi vì khách hàng được tham gia đánh giá rất nhiều và đầu ra của sản phẩm rất nhanh. Và khi đi sai hướng, có thể hủy ngay Sprint đó để quay lại với bản kế hoạch. Bảng so sánh các quy trình phần mềm: Đặc điểm Waterfall Spiral Scrum Xác định các giai đoạn phát triển Bắt buộc Bắt buộc Chỉ có giai đoạn lập kế hoạch và kết thúc Sản phẩm cuối cùng Được xác định trong quá trình lập kế hoạch Được xác định trong quá trình lập kế hoạch Xác định trong quá trình xây dựng dự án Chi phí sản phẩm Được xác định trong quá trình lập kế hoạch Thay đổi cục bộ Xác định trong quá trình xây dựng dự án Ngày hoàn thành sản phẩm Được xác định trong quá trình lập kế hoạch Thay đổi cục bộ Xác định trong quá trình xây dựng dự án Đáp ứng với môi trường sử dụng Trong kế hoạch ban đầu Trong kế hoạch ban đầu Xuyên suốt từ kế hoạch đến xây dựng và kết thúc Kinh nghiệm trao đổi Đào tạo trước cho đến khi bắt tay làm dự án Đào tạo trước cho đến khi bắt tay làm dự án Thực hiện trong quá trình làm dự án Khả năng thành công Thấp Trung bình thấp Cao CHƯƠNG II: VISUAL STUDIO TEAM SYSTEM, TEAM FOUNDATION SERVER Giới thiệu: Visual Studio Team System, Team Foundation Server là phần mềm hỗ trợ để nâng cao hiệu quả của đội ngũ phát triển phần mềm cơ bản của bạn. Thí dụ bạn đang sử dụng Team Foundation Server hay đã áp dụng từ lâu, thì trong tài liệu này bạn sẽ tìm thấy những hướng dẫn cụ thể và hiểu thấu đáo để điều chỉnh cho phù hợp với tình huống cụ thể của bạn. Những hướng dẫn cụ thể đó được trình bày trong những phần sau đây: Phần I: Trình bày cho chúng ta một cái nhìn tổng quát một cách nhanh chóng của Team Development với Team Foundation Server. Bạn cũng sẽ hình dung ra bức tranh lớn trong những điều kiện của môi trường phát triển phần mềm của bạn, bao gồm môi trường phát triển và kiểm thử. Bạn cũng sẽ tìm hiểu kiến trúc cơ bản của Team Foundation Server. Phần II: Trình bày cho bạn bằng cách nào để kết cấu Source Code của bạn và quản lí những phần phụ thuộc. Nó cũng trình bày cho bạn bằng cách nào để quyết định một chiến thuật Branching và Merging…. Và nhiều phần khác nữa. Mục đích: Mô tả cấu trúc Microsoft Visual Studio Team System (VSTS) và Team Foundation Server (TFS). Xác định những thành phần cấu tạo nên các tầng Client, Application và Data. Làm rõ sự khác nhau giữa việc triển khai một Single-server và Multi-server. Tổng quan về kiến trúc Team Foundation Server: Chương này giới thiệu với các bạn kiến trúc TFS và sự triển khai cấu trúc liên kết cơ bản. Hình 2: Thành phần và các tầng trong TFS TFS có một kiến trúc ba tầng một cách logic bao gồm: một tầng Client, một tầng Application và một tầng Data. Tầng Client tương tác với tầng Application qua các Web Services khác nhau, tầng Application sử dụng các Database khác nhau trong tầng Data. Sự triển khai cấu trúc cơ bản: phần lớn phụ thuộc vào kích cỡ nhóm của bạn. Nếu các thành viên tham gia trong nhóm ít hơn 50 người thì bạn tiến hành triển khai cấu trúc Single-server. Nhưng với một máy chủ đủ mạnh có thể hỗ trợ tối đa 400 người sử dụng. Nếu các thành viên tham gia trong nhóm với số lượng lớn vài ngàn người thì bạn tiến hành triển khai cấu trúc Dual-server. I. Thành phần cấu tạo nên các tầng Client, Application và Data: 1. Tầng Client: Hình 2.1 Mô hình tầng Client Chứa các thành phần quan trọng sau đây: Team Foundation Server Object Model: Đây là public API được sử dụng để tương tác với TFS. Bạn có thể sử dụng mô hình đối tượng để tạo những ứng dụng trong Client-side cho riêng bạn mà tương tác với TFS. Những thành phần Visual Studio Industry Partners (VSIP): Đây là những công cụ của bên thứ ba (third-party tools), add-ins và những ngôn ngữ được sử dụng trong Visual Studio. Microsoft Office tích hợp: bao gồm một bộ các add-ins dành cho Microsoft Office excel và Microsoft Office Project cho phép bạn truy vấn và cập nhật các Work Item trong cơ sở dữ liệu TFS Work Item Tracking. Điều này đặc biệt hữu ích cho các nhà quản lí dự án đã sử dụng rộng rãi các công cụ này. Command-line tools: là những công cụ cho phép bạn tương tác với TFS từ những dòng lệnh (Command-line). Phần lớn các công cụ này cung cấp các chức năng kiểm soát mã nguồn và chúng hữu ích trong việc tự động hóa các tác vụ lặp và các tác vụ cố định. Check-in Policy Framework: thành phần này hỗ trợ check-in policy feature, là một cơ chế mở rộng cho phép bạn xác nhận tính hợp lệ của Code trong suốt Check-in process. 2. Tầng Application: Hình 2.2 Mô hình tầng Application Những Web Services này được nhóm vào các tập sau: Team Foundation Data Services. Team Foundation Integration Services. a) Team Foundation Data Services: Những Services này gồm có các thành phần sau: Version control Web Services: Tầng Client sử dụng Web Services này để thực thi các chức năng kiểm soát mã nguồn (Source Control Features) TFS khác nhau và để tương ứng với Source Control Database. Work Item Tracking Web Services: Tầng Client sử dụng Web services này để tạo, cập nhật và truy vấn các Work Item trong Work Item Tracking Database. Team Foundation Build Web services: Tầng Client và MS Build Framework sử Web Services này để thực thi các quy trình thiết kế. b) Team Foundation Integration Services: Tập các Web Services này cung cấp các chức năng tự động và thống nhất. Những Web Services này không tương tác với tầng Data. Những thành phần trong Team Foundation Integration Services này gồm có: Registration Web Services: Service này được sử dụng để đăng kí các dịch vụ TFS khác. Nó gìn giữ thông tin trong một cơ sở dữ liệu đăng kí. Những Web Services sử dụng thông tin này để khám phá và xác định xem bằng cách nào để tương tác với Web Services khác. Security Web Service: Service này bao gồm Group Security Service và Authorization Service. Group Security Service được dùng để quản lí tất cả các User và Group của TFS. Authorization Service cung cấp một hệ thống truy cập cho TFS. Linking Web Service: Service này cho phép các công cụ thiết lâp một mối quan hệ được liên kết lỏng lẻo giữa các phần tử dữ liệu mà chúng đang chứa. Ví dụ: Mối quan hệ giữa một Work Item sai soát và Source Code được thay đổi để sửa chữa sự sai soát được tổ chức bởi TFS sử dụng một Link. Eventing Web Service: Service này cho phép một công cụ hay một dịch vụ đăng kí các loại sự kiện. Người sử dụng có thể đồng ý để nhận được những sự kiện này và thông báo qua e-mail hay sự dẫn ra của một Web Service. Ví dụ: Bạn có thể sử dụng một Check-in event để kích hoạt một Continuous Integration Build. Classification Web Service: Service này làm việc với Linking Web Service để kích hoạt những TFS Artifact để phân loại tùy theo những nguyên tắc phân loại đã được định nghĩa trước. Thành phần này giúp hỗ trợ Cross-tool Reporting ngay cả đối với những Artifacts mà không chia sẽ một nguyên tắc phân chia thông thường để tổ chức dữ liệu của họ. Ví dụ: Nếu các Work Item được tổ chức bình thường bởi nhóm của bạn, trong khi Test được tổ chức bởi các thành phần Component, bạn cũng có thể tổ chức Test bởi nhóm của bạn để các Test đó có thể được báo cáo cùng với các Work Item. 3. Tầng Data: Hình 2.3 Mô hình tầng Data TFS không hỗ trợ truy cập trực tiếp đến dữ liệu mà được lưu trữ trên tầng Data từ những ứng dụng Client. Thay vào đó, tất cả các yêu cầu về dữ liệu được thực hiện thông qua các Web Services trên tầng Application. Tầng Data của TFS bao gồm các dữ liệu sau được lưu trữ tương ứng với các Data Services trên tầng Application. Work Item Tracking: Phần này lưu trữ tất cả các dữ liệu có liên quan đến Work Items. Version Control: Phần này lưu trữ tất cả các dữ liệu có liên quan đến Source Control. Team Foundation Build: Phần này lưu trữ tất cả các thông tin liên quan đến các chức năng của TFS Team Build. Reporting Warehouse: Phần này lưu trữ tất cả các thông tin liên quan đến tất cả các công cụ và chức năng của TFS. Reporting Warehouse giúp việc tạo ra các báo cáo đơn giản hơn bằng cách kết hợp dữ liệu từ nhiều công cụ khác nhau. II. Sự khác nhau giữa việc triển khai một Single-server và Multi-server: Single-server Deployment: Hình 2.2.1 Cấu trúc liên kết Single Server. Sự triển khai Single-server là một cấu trúc liên kết đơn giản nhất và dành cho một đội phát triển hay những dự án thí điểm tối đa cho 400 người sử dụng. Với phương pháp tiếp cận này, bạn cài đặt tất cả các thành phần của tầng Application và tầng Data trên một Single-server và truy cập chúng trên một Domain. Nếu bạn cần cài thử cho việc kiểm thử, thì bạn có thể cài đặt chúng trên một node server hay là một hay nhiều Client. 2.Dual-server Deployment: Hình 2.2.2 Cấu trúc liên kết Dual Server Triển khai cấu trúc liên kết Dual-server rất có lợi cho các nhóm phát triển lớn khoảng 2000 người sử dụng. Trong việc triển khai cấu trúc này, bạn cài đặt tầng Application trên một server node riêng biệt từ tầng Data. Bạn có thể cài đặt Team Foundation Build Server trên tầng Application, nhưng bạn được khuyến khích để thiết lập một hay nhiều Build Server dành riêng cho các nhóm lớn. Nếu dự án dùng để kiểm thử thì chúng ta có thể triển khai các thiết bị kiểm thử đến các server node bổ sung. 3. Giải thích rõ về việc triển khai cấu trúc liên kết: Bạn có thể triển khai cấu trúc TFS bằng cách sử dụng một sự khác nhau của vùng cấu trúc liên kết khác nhau từ việc cài đặt Single server đơn giản đến cấu trúc liên kết phức tạp hơn là Multi server. Bất kể bạn sử dụng bao nhiêu cấu trúc liên kết thì bạn cần phải nhận biết được một số yêu cầu chính sau: Bạn phải cài đặt tầng Application và tầng Data trên cùng một Domain, mặc dù chúng có thể được đặt trên cùng Node server hay là trên một Node server riêng lẻ. Bạn phải cài đặt những máy tính có TFS với Microsoft Windows Server 2003 phiên bản Service Pack 1 hoặc mới hơn. Bạn phải cài đặt tất cả các tầng ứng dụng của TFS Web Services trên cùng một Server. Bạn phải cài đặt những thể hiện TFS đơn trên một máy tính đơn. Bạn không thể cài đặt nhiều hơn một thể hiện của TFS trên một server. Bạn không thể phân tán những Database của TFS qua nhiều server dữ liệu. Tất cả các dự án phải tập trung vào một nhóm Team Foundation Server, và không thể triển khai trên nhiều nhóm Server. Bạn không thể sử dụng một Microsoft Sharepoint portal Server Infrastructure đã tồn tại để lưu trữ cho cổng dự án của nhóm bạn. Hãy cân nhắc việc sử dụng một Server dành riêng cho các cổng TFS Sharepoint. Bạn không nên cài đặt TFS trên một Server được cấu hình như một Domain Controller bởi vì điều này không được hỗ trợ. Đối với việc triển khai Dual-Server, bạn cần phải chuẩn bị một vài Account Domain để sử dụng khi chạy TFS services. Thí dụ: Bạn cần tạo các account như là: Domain\TFS Service ang Dmain\TFS Reports. CHƯƠNG III: ỨNG DỤNG QUẢN LÍ KINH DOANH QUÁN COFFEE I. Mô hình quán cà phê gồm: Diện tích của quán: 1000 m2 Số bàn: 40 bàn Khu_Tầng: 3 khu, 1 tầng. Số lượng quản lí và nhân viên phục vụ: 2 quản lí, 15 nhân viên. II. Bảng cơ sở dữ liệu: Thực đơn ( Tên nhóm, tên mặt hàng, đơn vị tính, số lượng, đơn giá) Mặt hàng ( Mã mặt hàng, tên mặt hàng) Hàng hóa ( Mahh, tên hàng, nhóm, đơn vị tính, giá nhập, trạng thái) Nhóm hàng hóa ( Mã nhóm, tên nhóm) Đơn vị tính ( Mã đơn vị tính, tên đơn vị tính) Ca làm việc ( Mã ca làm việc, thời gian) Khu-tầng ( STT, tên khu-tầng) Bàn ( STT, mã bàn, tên bàn, thuộc khu-tầng, tình trạng) Hóa đơn ( Mã hđ, tên hđ, mãhh, tên hàng, đơn vị tính, số lượng, đơn giá, thành tiền) Nhân viên ( STT, mãnv, họ hên, địa chỉ, sodt, chức vụ, ngày vào làm, hsl, hslcb, giới tính) Phiếu N-X ( Mãsp, tên phiếu, số lượng nhập, số lượng xuất, đơn giá, ngày nhập, ngày xuất, Phân loại N-X) Bán ( Mãhh, mã mặt hàng, tên mặt hàng, số lượng bán, đơn giá bán, ngày bán) III. Các hạng mục và yêu cầu: Liệt kê dang sách tất cả các mặt hàng. Liệt kê danh sách hàng hóa nhập vào trong ngày. Liệt kê danh sách hàng hóa nhập vào từ ngày đến ngày. Thống kê những mặt hàng bán ra nhiều nhất trong ngày, in ra những danh sách đó. Thống kê các mặt hàng tồn trong ngày, in ra những danh sách này. In phiếu tính tiền cho khách hàng. Tính tổng số tiền chi ra trong ngày. Tính tổng số tiền thu vào trong ngày. Tính lương cho quản lí và nhân viên phục vụ. IV. Dự kiến hoàn thành các hạng mục: trong thời gian 3 tuần (21 ngày). Tuần đầu tiên, nhóm sẽ tiến hành khảo sát hiện trạng và xác lập các yêu cầu.