Download
1 / 26
260 likes | 421 Views
E – PROJECT. GUIDE Version 7.0. NỘI DUNG. Công nghệ, giải pháp sử dụng Các bước thực hiện khi thực hiện e-project Document e-Project outline Coding guide. CÔNG NGHỆ – GIẢI PHÁP SỬ DỤNG. Các công nghệ trong J2EE cụ thể
E N D
E – PROJECT GUIDE Version 7.0
NỘI DUNG • Công nghệ, giải pháp sử dụng • Các bước thực hiện khi thực hiện e-project • Document e-Project outline • Coding guide
CÔNG NGHỆ – GIẢI PHÁP SỬ DỤNG • Các công nghệ trong J2EE cụ thể • JSP, Servlet để trình bày/ hiển thị (xử lý ứng dụng – tùy theo e-project sẽ qui định) và report (sử dụng Jasper, BIRT hay jsp/ html thuần) • EJB (2.0 hay 3.0) để xử lý business logic (số lượng CMP và Session Bean sẽ qui định tùy theo project) • Struts để áp dụng mô hình xử lý MVC (có thể sử dụng Spring, ZK Framework, GWT, JSF, Flex, Ruby … – nhúng toàn bộ thành jsp hay html – không dùng zul, mmxl hay các file đặc chủng của ngôn ngữ) • SQL Server (version 2005) cho CSDL + SPx (tùy loại và yêu cầu) • UML hỗ trợ phân tích kế • JDK 6.0 hỗ trợ JVM nền cho J2EE • Các Web Application Server như Tomcat, JBoss, Sun App Server • Report • Là trang/ form trình bày dữ liệu dưới dạng table (không có bất kỳ control xử lý nào trên form) • Dạng cửa sổ browser mới (không có hyperlink) • Phải truyền tham số (không làm dạng 1 bảng).
CÁC BƯỚC THỰC HIỆN • Analysis: khi nhận eproject, từng nhóm thực hiện seminar trình bày về đề tàitrong buổi Analysis (1 buổi – 10% điểm) • Đặc tả hệ thống (gồm những đối tượng gì, cần làm gì ...) • Mô tả các chức năng cần xây dựng cho hệ thống (theo yêu cầu của project) • Các đối tượng quản lý khi thực hiện project (lưu trữ trên CSDL, thực hiện xây dựng project) • Xác định thành phần chính của ứng dụng (core của ứng dụng) và các phần cần thiết cho ứng dụng • Xác định công việc của từng thành viên trên core chính (fixing) – qui trình chính (workflow) của toàn bộ ứng dụng hay chức năng của phần mềm, các thành phần còn lại (admin, security, transaction …) sẽ chia đều cho các thành viên tùy theo phân công của group leader và sự thỏa thuận các member • Các thành viên sẽ hoàn tất các thành phần core chính và phần cần thiết từ đầu đến cuối • Group leader dự kiến tasksheet • Kết thúc giai đoạn này, tasksheet chính thức được approved để mọi người thực hiện nhanh chóng và đúng tiến độ
Design và Documentation (ít hơn 1,5 tuần): • Thực hiện thiết kế các mô hình • Usecase diagram • Sequence diagram • ERD (conceptual và logical), Database, và Validation • Form, Report, Validation • Tasksheet (group leader thực hiện để phân chia công việc đồng đều trên việc xử lý) • Documentation song song trong quá trình thiết kế (member thực hiện phần nào sẽ dump document phần đó – Lưu ý: group leader qui định rõ style – template khi làm document để thực hiện tích hợp – cùng với tiến độ thực hiện công việc – dựa trên tasksheet) • Coding (tối thiểu 2 tuần) • Thực hiện coding theo bảng thiết kế đã xây dựng trong 02 bước trên (giai đoạn thi công) • Không có bất kỳ chỉnh sửa nào trong giai đoạn này • Deadline của từng giai đoạn: xem thông báo và thực hiện đúng tiến độ (thời gian nộp document, deadline code ...) CÁC BƯỚC THỰC HIỆN (tt)
CÁC BƯỚC THỰC HIỆN (tt) • Có 02 loại tài liệu cần nộp • 2 quyển document (cho dù nhóm có 3 hay 5 người) nộp cho Aptech tại Việt Nam (hoàn tất đến phần TaskSheet) • Bản softcopy nộp cho ấn độ cần có đầy đủ 4 phần nộp Aptech Việt Nam cùng với các báo cáo về testing, công việc thực hiện .. • Trong giai đoạn từ khi start eProject đến thời hạn deadline, các công việc cần thực hiện với Ấn độ sau • Cứ mỗi 10 ngày, các group leader phải gửi status report (đính kèm trong eProject assignment) để báo cáo tiến độ thực hiện cùng với comment về các group’s member của nhóm (các giai đoạn này sẽ được hướng dẫn cụ thể bằng email) • Có 3 lần báo cáo • 10 ngày kể từ ngày start: gửi status report kèm theo review 1, 2 • 10 ngày kế tiếp: gửi status report kèm theo document tới tasksheet • Ngày deadline: gửi status report cuối cùng với document hoàn chỉnh, source code, install guide, user guide (nếu có) và feedback form
DOCUMENT OUTLINE • Trang bìa: thực hiện theo đúng mẫu qui định Aptech (có 2 logo, canh lề, ...) – sẽ có file mẫu (table content đặt đầu tài liệu) • Chia làm các phần • Review 1 • Review 2 • Review 3 • Tasksheet • Monitoring Report (chỉ có trong softcopy nộp cho Ấn độ) • Các tiêu đề của từng phần (ví dụ: Review 1) phải được đặt trên một trang riêng • Các phần header, footer, kích thước, định dạng trang thực hiện theo đúng mẫu qui định Aptech • Toàn bộ tài liệu được viết bằng tiếng Anh • Kết thúc mỗi phần phải có phần ký tên xác nhận của group leader và giáo viên hướng dẫn (có tất cả 4 chữ ký – review 1, 2, 3 và tasksheet)
REVIEW 1 • Thực hiện đầy đủ các nội dung trong phần cấu trúc chung theo hướng dẫn bên dưới. • Phần ký tên xác nhận của group leader và giáo viên hướng dẫn • Cấu trúc chung • Introduction • Nêu tổng quát sự cần thiết để viết ứng dụng này (tình huống cần để xây dựng ứng dụng – nhu cầu xây dựng ứng dụng) • Hint: Viết lại phần Introduction của Problem Statement trong bản Specification của Ấn độ gửi cho các nhóm. Nếu không có, sinh viên cần xác định ứng dụng có thể áp dụng trong mô hình thực tiễn nào để viết nội dung này • Existing Scenario • Nêu lên tổng quát yêu cầu – mong muốn của người đặt hàng khi cần viết chương trình này • Hint: Viết lại phần Existing Scenerio của Problem Statement (nếu có). Nếu không có, sinh viên phải dựa trên các đặc tả chức năng để mô tả nội dung này.
REVIEW 1 (tt) • Cấu trúc chung (tt) • Customer Requirement Specification • Nêu chi tiết hay đặc tả các user requirements • Hint: Viết lại nội dung phần Proposed Solution của Problem Statement (nếu có). Nếu không có, sinh viên phải căn cứ trên function requirement – các chức năng được yêu cầu để giảng giải thành các câu giải nghĩa cho phần này. • Functional Requirements Specification • Nêu các chức năng sẽ được design và implement cho ứng dụng này • Hint1: Viết lại từng nội dung được mô tả trong functional requirement kết hợp với customer requirement (Dùng các phần financial, non-finacial, function requirement). Sau đó thực hiện phân tích – một ý đó có bao nhiêu chức năng được thực hiện và liệt kê ra (đề nghị xem demo trong eProject Document Good) • Hint2: trong quá trình mô tả này nên đánh mã số tăng dần cho từng chức năng để chúng ta có thể mapping với các chức năng thiết kế và implement trong các phần tiếp theo (dễ kiểm tra và theo dõi)
REVIEW 1 (tt) • Cấu trúc chung (tt) • System requirements Specification • Nêu lên cấu hình hệ thống, cấu hình phần cứng, phần mềm yêu cầu cần đáp ứng khi chạy ứng dụng này • Chia rõ thành 02 phần: server và client. • Development Software • Nêu tên các phần mềm chúng ta sẽ sử dụng trong quá trình phân tích, thiết kế, implement ứng dụng • Hint: Cần nêu rõ phiên bản của từng phần mềm cùng với SP (nếu có) để đảm bảo khi deploy ứng dụng chúng ta sẽ chạy đúng WORA • Technology • Nêu tên các công nghệ chúng ta áp dụng để xây dựng phần mềm để thiết kế mô hình chung của ứng dụng • Ví dụ: J2EE, ZK framework, Java Web Services … • Tip: Bắt buộc phải phân tích và đánh mã số chi tiết các yêu cầu để đạt điểm cao (xem demoGood)
REVIEW 2 • Algorithms • Nêu ra cách giải quyết (solution description) và các bước áp dụng để giải quyết từng chức năng đã nêu trong phần functional requirements (mapping với các mã số đã ghi trong phần functional requirements) • Các nội dung mô tả trong phần này sẽ tương ứng với các nội dung giải thích trong sequence diagram và usecase. • Use Case Diagram: Thể hiện các hình vẽ • Các actor của hệ thống • Chức năng của các actor • Mô tả đối tượng trong hình vẽ • Các thành phần phải có mối liên kết với nhau (sử dụng các từ khóa uses – includes hay extends)
REVIEW 2 (tt) • Sequence Diagram: hình vẽ và mô tả (dùng form mẫu) • Các luồng xử lý tương ứng với Algorithms mô tả • Các bước tuần tự (hint: nên thiết kế cùng với form mô tả đầy đủ các control vì nơi đây sẽ là tổng quát giao diện chúng ta sẽ thi công) • Các cách xử lý exception (hint: vị trí lỗi phải được xác định cụ thể tại ví trí nào – dùng label và cách giải quyết) • Các bước thay thế – alternative (hint: các luồng xử lý tương ứng khi trong 1 solution có 2 cách xứ lý hay giải quyết. Cần xác định vị trí xử lý tương tự như exception) • Có bao nhiều usecase diagram (tất cả các hình bầu dục – kể cả usecase phân rã thì sẽ có bấy nhiêu sequence diagram) • Mô hình ERD: • Mô hình tổng quan (conceptual) – thiết kế thích hợp với mô tả (có các quan hệ n:n – chưa có thực thể relationship) • Mô hình phân rã (logical) – thiết kế có thể tiến tới cài đặt – các dạng thực thể được phân rã (chỉ còn quan hệ 1:n) • Các thực thể được vẽ với các thuộc tính (dựa trên mô hình logical). Lưu ý: vẽ đầy đủ kể các thực thể cùng thuộc tính của nó kể cả thực thể phát sinh. • Phần ký tên xác nhận của group leader và giáo viên hướng dẫn
REVIEW 2 (tt) • Bảng mô tả Sequence Diagram
REVIEW 3 • Thiết kế Database • Relationship thực hiện cài đặt thực tế trên DB management (Hint: chụp hình relationship diagram) • Cài đặt của các table trình bày theo cấu trúc (theo form bên dưới). Đối với các khóa làm khóa ngoại phải ghi rõ tên bảng và tên field tham chiếu (table.field). • Các cột là số – number, ngày tháng, bit và một số dạng chuỗi bắt buộc xác định giá trị Default Value • Các validation trên DB, cụ thể • Định dạng ID của các khóa chính – thiết kế mã • Ràng buộc trên các khóa chính và khóa ngoại (constraints) • Các ràng buộc trên các field đặc biệt trong CSDL • Các ràng buộc liên quan giữa các bảng (ví dụ: ngày đặt hóa đơn của bảng hóa đơn phải lớn hơn ngày mua hàng ở bảng nhập hàng)
REVIEW 3 (tt) • Thiết kế Database (tt) • Thể hiện các validation trên CSDL (tt) • Ràng buộc trên từng bảng liên thuộc tính. • Ràng buộc giữa các bảng với nhau. • Ví dụ: • ngày nhận hàng (bảng invoice) phải lớn hơn ngày đặt hàng. • một khách hàng có nhiều hóa đơn Tables: Invoice Constraints: ngày nhận hàng lớn hơn ngày đặt hàng Tables: Customer, Order Constraints: một khách hàng có nhiều hóa đơn
REVIEW 3 (tt) • GUI Interface (Form) • Trình bày giao diện của từng form (chụp hình) • Trình bày từng loại control, phương thức xử lý, validation trên từng control (theo mẫu bên dưới) • Lưu ý: đối với control là combo box, listbox phải liệt kê rõ ràng giá trị nạp trong giá trị chọn lựa của control (liệt kê từng giá trị). Nếu giá trị nạp từ table trên CSDL, xác định rõ tên table và tên field được nạp (mô tả trong Validation) • Lưu ý: đối với loại radio button và check box phải ghi rõ giá trị chọn lựa cài đặt cùng tên cho các radio button trong nhóm (mô tả trong Validation) • Mô tả chức năng và cách sử dụng form này (người dùng sẽ làm được những gì và làm như thế nào) • Report: • Trình bày giao diện (chụp hình) • Trình bày nguồn kết xuất ra report (table, các field và sử dụng liên kết gì) • Phần ký tên xác nhận của group leader và giáo viên hướng dẫn
TASK SHEET • Trình bày tasksheet theo từng Review • Các thành phần tasksheet phải được phân đều cho các thành viên trong nhóm (từng thành viên đều có cột điểm riêng trong từng phần) – tránh 01 member làm từng phần riêng biệt (điểm sẽ thấp) • Cấu trúc trình bày theo mẫu (bên dưới) • Phần ký tên xác nhận của group leader và giáo viên hướng dẫn
HOÀN TẤT DOCUMENT • Giai đoạn document nêu trên chúng ta mất khoảng 10 – 15 ngày (1,5 đến 2 tuần) • Gửi Status Report lần 1 cùng với các comment và Review 1 và 2 (cho dù chúng ta đã xong đến tasksheet) • Tiến hành các bước chuẩn bị giai đoạn coding, review và chỉnh sửa Project • In tài liệu để chuẩn bị nộp tại Aptech Việt Nam • Phân chia công việc cho giai đoạn coding • Notes: Chỉ in tài liệu khi được chấp nhận (tiết kiệm tiền và thời gian), tài liệu sẽ không được ký nếu chưa được chấp nhận cho dù đã tới hạn nộp hay bất ký lý do nào
CODING • Các thành viên trong nhóm phân chia công việc code cho đồng đều– việc coding dựa trên tasksheet đã phân trong phần analysis (tập trung coding vào phần core đã phân công đi dần ra phần admin – việc đánh giá để được lên bảo vệ dựa theo tiến độ trên 70% tính chỉ dựa trên core chính) • Mỗi thành viên chịu trách nhiệm coding từ bên trong (business logic) đến presentation – tránh 01 người làm một phần riêng biệt (nếu có drop các thành viên còn lại vẫn có thể demo để bảo vệ) • Mỗi thành viên coding phần của mình và tự testing (bảng testing sẽ đính kèm tài liệu và gửi Ấn độ khi deadline) để đảm bảo phần nội dung của mình là đúng • Cuối cùng, Group leader cùng các thành viên phối hợp để tích hợp thành thể thống nhất của chương trình và testing tổng thể. • Lưu ý: • Trước khi coding, nhóm phải thống nhất về cách đặt tên đối tượng và phương thức xử lý chung để tiến hành tích hợp nhanh chóng và tránh xuất hiện lỗi (group leader đề ra template – cách thức, mẫu chung để đặt tên biến, hàm …. - chung để dễ dàng tích hợp) • Báo cáo tiến độ trong quá trình coding, thực hiện demo theo lịch (sẽ qui định ngày cụ thể khi hoàn thành document), nếu không đảm bảo đúng tiến độ -> drop, không được bảo vệ
CODING (tt) • Trong quá trình coding chúng ta cần thực hiện các vấn đề sau: • Bổ sung softcopy để nộp cho Ấn độ các nội dung liên quan đến coding theo cấu trúc hướng dẫn (slide tiếp theo) • 10 ngày tiếp theo gửi status Report cùng với comment và document report đến phần tasksheet (Lưu ý: chú thích cho Ấn độ biết là bảng mới nhất có chỉnh sửa so với status report lần 1) • Trong quá trình coding phải chú thích – comment trong code (dễ hiểu – bằng tiếng Anh – requirements) – xem mẫu ví dụ bên dưới. Notes: Chú thích tất cả các file source, kể cả tập tin jsp, html. Chú thích trên từng phương thức, biến • Đẩy nhanh công việc để hoàn thành công việc đúng thời hạn deadline. Lưu ý: hiệu quả là trên hết – không cần hay và tối ưu nghĩa là đáp ứng mọi chức năng Ấn độ yêu cầu . Chỉ tối ưu khi còn thời gian
CODING (tt) – COMMENTS – VÍ DỤ /** /* Calculate the series of adding many integer number. /* @param /* start starting number – integer type. /* end ending number – integer type. /* @return /* sum of result in the series of adding – long type. /* if start or num is not numeric, return the /* NumberFormatException (msg) with msg /* presents the corresponding message. /* Modifier public */ public long seriesAdd (int start, int end) { long sum = 0; //declare a sum to store the result of adding, then initializing to 0 /* /* loop from start to end. /* add to sum. */ for (int i = start; i <= end; i ++) { sum += i; // sum = sum + i. adding the sum with i, then assign the result to sum again } /end for return sum; //return the ending result to method } ….
MONITORING REPORTs • Cấutrúcchung • Project Review and Monitoring Report • Nêucácnội dung đánhgiá Pros và Con trong quá trìnhthựchiện coding củatừngthànhviên. (Khó khănvà tiếnđộ) • Nêulênviệccảitiến hay tốiưucáchthứcvậndụng so vớithiếtkế. Đánhgiá cácnội dung hoàntấtvà mứcđộ (%) so vớiyêucầu • Unit Testing check List • Tạo sheet nêurõ từngchứcnăngvà từngthànhviên code đã testing để đảmbảochứcnăngthựchiệnđúngthiếtkế cùngtrìnhtự thờigian (căncứ dựatrên sequence diagram) • Nội dung nàynhằmđảmbảocácchứcnăngđúngthiếtkế và đã thựchiện. Ngườitheodõidễ quansát project làmđạtnhữngphầnnào • Final check List • Tạo sheet nêurõ chứcnăngphầnmềmđã được test saukhitíchhợp. (groupleaderthựchiệnnội dung này) • Hint: nêntạoracácmẫuvề test case vàđínhkèmvào softcopy
HƯỚNG DẪN • Trong quá trình làm project, các thành viên của nhóm sẽ phải demo theo từng giai đoạn để lấy điểm thiết kế và final project để được phép tham gia bảo vệ tại VN (nếu không đạt các yêu cầu này có thể không được bảo vệ) • Trong quá trình hướng dẫn sẽ có email hướng dẫn theo từng giai đoạn để đảm bảo công việc thực hiện tốt. • Group leader sẽ là người thực hiện phân công và hỗ trợ công việc cho thành viên. • Group leader thực hiện báo cáo tình trạng, tiến độ công việc để có việc điều chỉnh công việc phù hợp và reject thành viên không thực hiện phân công và tiến độ đề ra. • Các vấn đề khúc mắc hay xung đột giữa các thành viên cần thông báo để chúng ta giải quyết – không đưa nội dung chưa giải quyết đến Ấn Độ
GOOD LUCK! HARD WORKING! GOOD OVER NIGHT!
