Báo cáo phát triển hệ thống thông tin | Môn tin học đại cương

Một phương pháp được định nghĩa như một tập hợp các bước và các công cụ cho phép tiến hành một quá trình phát triển hệ thống chặt chẽ nhưng dễ quản lý hơn. Phương pháp được đề nghị ở đây dựa vào ba nguyên tắc cơ sở chung của nhiều phương pháp hiện đại có cấu trúc để phát triển hệ thống thông tin. Tài liệu giúp bạn tham khảo, ôn tập và đạt kết quả cao. Mời bạn đọc đón xem !

Thông tin:
38 trang 1 tháng trước

Bình luận

Vui lòng đăng nhập hoặc đăng ký để gửi bình luận.

Báo cáo phát triển hệ thống thông tin | Môn tin học đại cương

Một phương pháp được định nghĩa như một tập hợp các bước và các công cụ cho phép tiến hành một quá trình phát triển hệ thống chặt chẽ nhưng dễ quản lý hơn. Phương pháp được đề nghị ở đây dựa vào ba nguyên tắc cơ sở chung của nhiều phương pháp hiện đại có cấu trúc để phát triển hệ thống thông tin. Tài liệu giúp bạn tham khảo, ôn tập và đạt kết quả cao. Mời bạn đọc đón xem !

34 17 lượt tải Tải xuống
lOMoARcPSD| 47207194
BỘ TÀI CHÍNH TRƯỜNG ĐẠI HỌC TÀI CHÍNH
MARKETING KHOA CÔNG NGHỆ THÔNG TIN
--------------- --------------
BÁO CÁO MÔN HỌC
PHÁT TRIỂN HỆ THỐNG THÔNG TIN
TRÊN CÁC FRAMEWORK
Mã lớp học phần:
Đề tài:
XÂY DỰNG WEBSITE BÁN ĐIỆN THOẠI
DI ĐỘNG
Giảng viên hướng dẫn: Mai Thanh Tâm
TP.HCM, Tháng 2 năm 2023
THÀNH VIÊN NHÓM 02:
1. Thị Quỳnh Như – 2021010240
2. Thân Diệu Yến
lOMoARcPSD| 47207194
3. Nguyễn Thị Quỳnh Như
4. Phạm Thanh Ngân
5. Nguyễn Đình Nguyên
lOMoARcPSD| 47207194
Mục lục
2.1 Khái niệm về phát triển hệ thống thông tin.......................................................................4
2.2 Tiêu chí lựa chọn phương pháp phát triển hệ thống thông tin...........................................6
2.3 Một số phương phát phải triển hệ thống thông tin............................................................7
2.3.1 Phương pháp phát triển truyền thống.........................................................................7
2.3.2 Phát triển ứng dụng nhanh (RAD)...........................................................................10
3.3 Các bộ công cụ CASE....................................................................................................13
3.3.1 Diagram tools...........................................................................................................13
3.3.2 Process Modeling tools............................................................................................17
3.3.3 Project Management tools........................................................................................18
3.3.4 Documentation tools................................................................................................20
3.3.5. Analysis Tools.........................................................................................................23
3.3.6. Design Tools...........................................................................................................24
3.3.7. Configuration Management Tools...........................................................................24
3.3.8. Change Control Tools.............................................................................................25
4.1.........................................................................................................................................30
4.1.1: Sơ lược về Ionic......................................................................................................31
4.1.2 Sơ lược về Meteor....................................................................................................32
4.2.3 Sơ lược về PhoneGap...............................................................................................34
4.1.4 Sơ lược về Angular UI.............................................................................................36
4.1.5 Sơ lược về Sencha Touch.........................................................................................38
4.1.6 Sơ lược về MVC......................................................................................................39
4.1.7 Sơ lược về Spring.....................................................................................................41
4.2 Ứng dung Framework.....................................................................................................43
4.2.1 Enterprite API..........................................................................................................43
Chương 2
2.1 Khái niệm về phát triển hệ thống thông tin
- Mục tiêu cuối cùng của những cố gắng phát triển hệ thống thông tin là cung cấp cho các
thành viên của tổ chức những công cụ quản lý tốt nhất. Phát triển một hệ thống thông tin bao
gồm việc phân tích hệ thống đang tồn tại, thiết kế một hệ thống mới, thực hiện và tiến hành cài
lOMoARcPSD| 47207194
đặt nó. Phân tích một hệ thống bắt đầu từ việc thu thập dữ liệu và chỉnh đốn chúng để đưa ra
được chẩn đoán về tình hình thực tế.
- Một phương pháp được định nghĩa như một tập hợp các bước và các công cụ cho phép
tiếnhành một quá trình phát triển hệ thống chặt chẽ nhưng dễ quản lý hơn. Phương pháp được
đề nghị ở đây dựa vào ba nguyên tắc cơ sở chung của nhiều phương pháp hiện đại có cấu trúc
để phát triển hệ thống thông tin. Ba nguyên tắc đó là :
Nguyên tắc 1. Sử dụng các mô hình.
Nguyên tắc 2. Chuyển từ cái chung sang cái riêng.
Nguyên tắc 3. Chuyển từ mô hình vật lý sang mô hình lô gíc khi phân tích và từ
hình lô gíc sang mô hình vật lý khi thiết kế.
Các công đoạn của phát triển hệ thống
Giai đoạn 1 : Đánh giá yêu cầu
1.1 Lập kế hoạch đánh giá yêu cầu.
1.2 Làm rõ yêu cầu.
1.3 Đánh giá khả năng thực thi.
1.4 Chuẩn bị và trình bày báo cáo đánh giá yêu cầu.
Giai đoạn 2 : Phân tích chi tiết
2.1 Lập kế hoạch phân tích chi tiết.
2.2 Nghiên cứu môi trường của hệ thống đang tồn tại.
2.3 Nghiên cứu hệ thống thực tại.
2.4 Đưa ra chẩn đoán và xác định các yếu tố giải pháp.
lOMoARcPSD| 47207194
2.5 Đánh giá lại tính khả thi.
2.6 Thay đổi đề xuất của dự án.
2.7 Chuẩn bị và trình bày báo cáo phân tích chi tiết.
Giai đoạn 3: Thiết kế lô gíc
3.1 Thiết kế cơ sở dữ liệu.
3.2 Thiết kế xử lý.
3.3 Thiết kế các luồng dữ liệu vào.
3.4 Chỉnh sửa tài liệu cho mức lô gíc.
3.5 Hợp thức hoá mô hình lô gíc.
Giai đoạn 4: Đề xuất các phương án của giải pháp
4.1 Xác định các ràng buộc tin học và ràng buộc tổ
chức.
4.2 Xây dựng các phương án của giải pháp.
4.3 Đánh giá các phương án của giải pháp.
4.4 Chuẩn bị và tình bày báo cáo của giai đoạn đề xuất các phương án giải pháp.
Giai đoạn 5 : Thiết kế vật lý ngoài
5.1 Lập kế hoạch thiết kế vật lý ngoài
5.2 Thiết kế chi tiết các giao diện (vào/ ra)
5.3 Thiết kế cách thức tương tác với phần tin học hoá
5.4 Thiết kế các thủ tục thủ công
5.5 Chuẩn bị và trình bày báo cáo về thiết kế vật lý ngoài
Giai đoạn 6: Triển khai kỹ thuật hệ thống
6.1 Lập kế hoạch thực hiện kỹ thuật
6.2 Thiết kế vật lý trong
6.3 Lập trình
6.4 Thử nghiệm hệ thống
6.5 Chuẩn bị tài liệu
Giai đoạn 7: Cài đặt và khai thác
7.1 Lập kế hoạch cài đặt
7.2 Chuyển đổi
7.3 Khai thác và bảo trì
7.4 Đánh giá
2.2 Tiêu chí lựa chọn phương pháp phát triển hệ thống thông tin
lOMoARcPSD| 47207194
- Tiêu chí:
Phương pháp phải đảm bảo tính hiệu quả
Phương pháp có kế hoạch rõ ràng, và nguồn lực đầy đủ
Yêu cầu
Giải pháp hoặc sản phẩm cuối cùng
Phản hồi về công việc đã làm
Tần suất yêu cầu thay đổi hoặc cải tiến
Chi phí chậm trễ
Kinh nghiệm về các dự án
Do nhu cầu về c hệ thống thông tin doanh nghiệp giảm trở thành một câu hỏi quan trọng,
việc cải thiện mối quan hệ giá-chất lượng của sản phẩm phần mềm trở thành một câu hỏi quan
trọng.
Nó đòi hỏi phải tăng mức chất lượng đồng thời với việc giảm chi phí cơ bản. Mục đích của
công việc nhất định là mô tả khả năng tối ưu hóa việc sử dụng tài nguyên bằng cách áp dụng
các phương pháp phát triển hệ thống khác nhau. Trong phân tích đã sử dụng các phương pháp
thác nước, lặp lại, xoắn ốc và nhanh nhẹn.
Các tiêu chí lựa chọn từ chúng được mô tả có tính đến sự cần thiết của việc giảm thiểu chi phí
và thời gian của dự án.
Trong công việc đã phân tích các rủi ro có thể xuất hiện khi áp dụng các phương pháp khác
nhau và cách giảm thiểu chúng. Do phân tích được thực hiện trong bài viết, đề xuất chọn
phương pháp không phải cho toàn bộ công ty mà cho từng dự án riêng biệt. Trong bài viết
được đưa ra các khuyến nghị thực tế có thể được sử dụng trong các dự án thực tế.
2.3 Một số phương phát phải triển hệ thống thông tin
2.3.1 Phương pháp phát triển truyền thống
Giai đoạn 1: Khảo sát dự án
Khảo sát hiện trạng là giai đoạn đầu tiên trong quá trình phát triển một hệ thống thông tin.
Nhiệm vụ chính trong giai đoạn này là m hiểu, thu thập thông tin cần thiết để chuẩn bị cho
việc giải quyết các yêu cầu được đặt ra của dự án. Giai đoạn khảo sát được chia làm hai bước:
Bước 1:
Khảo sát sơ bộ: tìm hiểu các yếu tố cơ bản (tổ chức, văn hóa, đặc trưng, con người,...)
tạo tiền đề để phát triển HTTT phù hợp với dự án và doanh nghiệp.
lOMoARcPSD| 47207194
Khảo sát chi tiết: thu thập thông tin chi tiết của hệ thống (chức năng xử lý, thông tin
được phép nhập và xuất khỏi hệ thống, ràng buộc, giao diện cơ bản, nghiệp vụ) phục vụ
cho việc phân tích và thiết kế.
Bước 2: Đặt ra các vấn đề trọng tâm cần phải giải quyết, như:
Thông tin đưa vào hệ thống phải như thế nào?
Dữ liệu hiển thị và xuất ra khác nhau ở những điểm nào?
Ràng buộc giữa các đối tượng trong hệ thống cần xây được dựng ra sao?
Chức năng và quy trình xử lý của hệ thống phải đảm bảo những yêu cầu nào?
Cần sử dụng những giải pháp nào? Tính khả thi của từng giải pháp ra sao?
Từ những thông tin thu thập được và vấn đề đã đặt ra trong giai đoạn khảo sát, nhà quản trị và
các chuyên gia sẽ chọn lọc những yếu tố cần thiết để cấu thành hệ thống thông tin riêng cho
doanh nghiệp.
Giai đoạn 2: Phân tích hệ thống
Mục tiêu của giai đoạn là xác định các thông tin và chức năng xử lý của hệ thống, cụ thể như
sau:
Xác định yêu cầu của HTTT gồm: các chức năng chính - phụ; nghiệp vụ cần phải xử lý
đảm bảo tính chính xác, tuân thủ đúng các văn bản luật và quy định hiện hành; đảm bảo
tốc độ xử lý và khả năng nâng cấp trong tương lai.
Phân tích và đặc tả mô hình phân cấp chức năng tổng thể thông qua sơ đồ BFD
(Business Flow Diagram), từ mô hình BFD sẽ tiếp tục được xây dựng thành mô hình
luồng dữ liệu DFD (Data Flow Diagram) thông qua quá trình phân rã chức năng theo
các mức 0, 1, 2 ở từng ô xử lý.
Phân tích bảng dữ liệu. Cần đưa vào hệ thống những bảng dữ liệu (data table) gồm các
trường dữ liệu (data field) nào? Xác định khóa chính (primary key), khóa ngoại (foreign
key) cũng như mối quan hệ giữa các bảng dữ liệu (relationship) và ràng buộc
(constraint) dữ liệu cần thiết.
Ở giai đoạn này, các chuyên gia sẽ đặc tả sơ bộ các bảng dữ liệu trên giấy để có cái nhìn khách
quan. Qua đó, xác định các giải pháp tốt nhất cho hệ thống đảm bảo đúng các yêu cầu đã khảo
sát trước khi thực hiện trên các phần mềm chuyên dụng.
Giai đoạn 3: Thiết kế
lOMoARcPSD| 47207194
Thông qua thông tin được thu thập từ quá trình khảo sát và phân tích, các chuyên gia sẽ
chuyển hóa vào phần mềm, công cụ chuyên dụng để đặc tả thiết kế hệ thống chi tiết. Giai đoạn
này được chia làm hai bước sau:
Bước 1: Thiết kế tổng thể
Trên cơ sở các bảng dữ liệu đã phân tích và đặc tả trên giấy sẽ được thiết kế dưới dạng mô
hình mức ý niệm bằng phần mềm chuyên dụng như Sybase PowerDesigner, CA ERwin
Data Modeler. Bằng mô hình mức ý niệm sẽ cho các chuyên gia có cái nhìn tổng quát nhất
về mối quan hệ giữa các đối tượng trước khi chuyển đổi thành mô hình mức vật lý. Bước 2:
Thiết kế chi tiết
Thiết kế cơ sở dữ liệu (Database): Với mô hình mức vật lý hoàn chỉnh ở giai đoạn thiết
kế đại thể sẽ được kết sinh mã thành file sql.
Thiết kế truy vấn, thủ tục, hàm: thu thập, xử lý thông tin nhập và đưa ra thông tin chuẩn
xác theo đúng nghiệp vụ.
Thiết kế giao diện chương trình đảm bảo phù hợp với môi trường, văn hóa và yêu cầu
của doanh nghiệp thực hiện dự án.
Thiết kế chức năng chương trình đảm bảo tính logic trong quá trình nhập liệu và xử lý
cho người dùng.
Thiết kế báo cáo. Dựa trên các yêu cầu của mỗi doanh nghiệp và quy định hiện hành sẽ
thiết kế các mẫu báo cáo phù hợp hoặc cho phép doanh nghiệp tư tạo mẫu báo cáo ngay
trên hệ thống.
Thiết kế các kiểm soát bằng hình thức đưa ra các thông báo, cảnh báo hoặc lỗi cụ thể
tạo tiện lợi và kiểm soát chặt chẽ quá trình nhập liệu với mục tiêu tăng độ chính xác cho
dữ liệu.
Tóm lại, thiết kế là việc áp dụng các công cụ, phương pháp, thủ tục để tạo ra mô hình hệ
thống cần sử dụng. Sản phẩm cuối cùng của giai đoạn thiết kế là đặc tả hệ thống ở dạng nó
tồn tại thực tế, sao cho nhà lập trình và kỹ sư phần cứng có thể dễ dàng chuyển thành chương
trình và cấu trúc hệ thống. Giai đoạn 4: Thực hiện
Đây là giai đoạn nhằm xây dựng hệ thống theo các thiết kế đã xác định. Giai đoạn này bao
gồm các công việc sau:
Lựa chọn hệ quản trị cơ sở dữ liệu (SQL Server, Oracle, MySQL, …) và cài đặt cơ sở
dữ liệu cho hệ thống.
lOMoARcPSD| 47207194
Lựa chọn công cụ lập trình để xây dựng các modules chương trình của hệ thống
(Microsoft Visual Studio, PHP Designer,...).
Lựa chọn công cụ để xây dựng giao diện hệ thống (DevExpress, Dot Net Bar,...).
Viết tài liệu hướng dẫn sử dụng, tài liệu kỹ thuật hoặc clip hướng dẫn.
Giai đoạn 5: Kiểm thử
Trước hết phải lựa chọn công cụ kiểm thử.
Kiểm chứng các modules chức năng của hệ thống thông tin, chuyển các thiết kế thành
các chương trình (phần mềm).
Thử nghiệm hệ thống thông tin.
Cuối cùng là khắc phục các lỗi (nếu có).
Viết test case theo yêu cầu.
Kết quả cuối cùng là một hệ thống thông tin đạt yêu cầu đặt ra.
Giai đoạn 6: Triển khai và bảo trì
Lắp đặt phần cứng để làm cơ sở cho hệ thống.
Cài đặt phần mềm.
Chuyển đổi hoạt động của hệ thống cũ sang hệ thống mới, gồm có: chuyển đổi dữ liệu;
bố trí, sắp xếp người làm việc trong hệ thống; tổ chức hệ thống quản lý và bảo trì.
Phát hiện các sai sót, khuyết điểm của hệ thống thông tin.
Đào tạo và hướng dẫn sử dụng.
Cải tiến và chỉnh sửa hệ thống thông tin.
Bảo hành.
Nâng cấp chương trình khi có phiên bản mới
2.3.3 Phương pháp linh hoạt (Agile Scrum)
Agile Scrum là gì?
Agile Scrum là một hệ thống quản lý dự án dựa trên Sprint với mục tiêu cung cấp giá trị cao
nhất cho các bên liên quan.
Agile và Scrum là hai phương pháp khác nhau có thể được sử dụng riêng biệt.
Sự khác biệt giữa Agile và Scrum là gì?
Mặc dù Agile và Scrum là tương tự nhau, nhưng chúng có một số khác biệt như:
- Agile hoạt động linh hoạt hơn Scrum.
- Agile có người lãnh đạo đóng vai trò quan trọng trong khi Scrum là một nhóm chức
năng chéo tự hoạt động.
- Agile với chức năng đơn giản mặc định trong khi Scrum có thể sáng tạo và thử nghiệm.
lOMoARcPSD| 47207194
- Agile cung cấp dự án từ đầu đến cuối trong khi Scrum chỉ cung cấp các dự án ngắn hạn.
Lợi ích mà Agile Scrum mang lại
- Tính linh hoạt và khả năng thích ứng
- Sáng tạo và đổi mới
- Giảm chi phí
- Cải thiện chất lượng
- Tổ chức Synergy
- Sự hài lòng của nhân viên
- Sự hài lòng của khách hàng
Lợi ích lớn nhất của phương pháp Agile Scrum là tính linh hoạt. Với mô hình hoạt động dựa
trên Sprint, nhóm Scrum thường nhận được phản hồi từ các bên liên quan sau mỗi dự án.
Nếu có bất kỳ vấn đề hoặc thay đổi nào, nhóm Scrum có thể dễ dàng và nhanh chóng điều
chỉnh. Điều này đã giúp các bên có liên quan đến dự án cảm thấy tốt hơn vì họ được làm
những điều họ muốn. Ngoài ra, họ còn được tham gia vào từng bước của dự án.
So sánh điều này với hệ thống quản lý dự án truyền thống cho thấy hệ thống Scrum phản hồi
thường xuyên tránh việc lãng phí thời gian.
Điều đó giúp các bên liên quan hiểu nhau hơn tránh xảy ra trường hợp phải bắt đầu lại dự án
sau khi sản phẩm đã được xây dựng vì sự không hiểu nhau giữa các bên.
Để thực hiện phương pháp Agile Scrum, phải có chuyên gia Scrum trong công ty hoặc một nhà
tư vấn bên ngoài để đảm bảo các nguyên tắc Scrum được áp dụng chính xác.
Phương pháp Agile Scrum có thể dẫn đến các vấn đề nghiêm trọng nếu không được thực hiện
đúng.
Agile là gì?
Agile Software Developer là phát triển phần mềm linh hoạt. Agile có nghĩa là khả năng phát
triển hoặc thích nghi với sự thay đổi của hoàn cảnh một cách nhanh chóng thông qua sự hợp
tác giữa các nhóm tự tổ chức và chức năng chéo với các khách hàng là những người dùng
cuối. Agile sẽ lập kế hoạch, phát triển, phân phối, cải tiến liên tục và phản ứng linh hoạt với
những thay đổi về yêu cầu, năng lực và sự hiểu biết về các vấn đề cần giải quyết, phù hợp với
sự phát triển của khách hàng và mục tiêu của các công ty.
Agile đề cập đến quá trình phát triển phù hợp với các khái niệm của tuyên ngôn Agile. Tuyên
ngôn được phát triển bởi một nhóm mười bốn nhân vật hàng đầu trong ngành công nghiệp
phần mềm.
lOMoARcPSD| 47207194
Các giá trị cốt lõi của Agile
- Agile lần đầu tiên được mô tả trong Tuyên ngôn Agile vào năm 2000 bởi một nhóm các
nhà phát triển đã tìm kiếm một phương pháp viết phần mềm mới. Bản tuyên ngôn trích
dẫn bốn giá trị sau:
- Cá nhân và sự tương tác hơn là các quy trình và công cụ.
- Phần mềm chạy tốt hơn là tài liệu đầy đủ.
- Đàm phán với khách hàng hơn là đàm phán bằng hợp đồng.
- Phản hồi với sự thay đổi hơn là theo kế hoạch.
12 nguyên tắc của Agile
Bản tuyên ngôn Agile ban hành 12 nguyên tắc liên quan đến việc phát triển phần mềm. Về sau
được cấu hình lại để phù hợp với quan điểm của người dùng:
- Sự hài lòng của khách hàng
- Giao hàng sớm và liên tục
- Nắm lấy cơ hội
- Giao hàng thường xuyên
- Hợp tác của các doanh nghiệp và nhà phát triển
- Các cá nhân có động lực
- Đối thoại trực tiếp
- Sản phẩm chức năng
- Kỹ thuật xuất sắc
lOMoARcPSD| 47207194
Sự đơn giản
- Các đội tự tổ chức
- Quy định, phản ánh và điều chỉnh - Lợi ích mà Agile mang lại
Lợi ích mà Agile mang lại
- Đối với khách hàng
Nhà cung cấp đã phản ứng nhanh với các yêu cầu phát triển, việc này đã làm khách hàng rất
hài lòng. Trong thời gian ngắn thì các tính năng có giá trị cao được phát triển và cung cấp
nhanh hơn. So với thời gian ngắn thì thời gian dài với quy trình “waterfall” vẫn được ưa
chuộng hơn.
- Đối với các nhà cung cấp
Các nhà cung cấp tập trung nỗ lực phát triển vào các tính năng có giá trị cao đồng thời giảm
thời gian so với các quy trình “waterfall” do giảm chi phí và tăng sự hiệu quả. Cải thiện sự
hài lòng của khách hàng sau đó việc duy trì khách hàng sẽ trở nên tốt hơn. - Đối với nhóm
phát triển (Development Teams)
Là thành viên trong nhóm phát triển, họ rất thích khi các dự án họ phát triển được khách hàng
sử dụng và tạo ra giá trị.
lOMoARcPSD| 47207194
-
Scrum mang lại lợi ích cho các thành viên trong nhóm bằng cách giảm công việc không sản
xuất, ví dụ: viết thông số kỹ thuật hoặc các tạo tác khác mà không ai sử dụng. Và cho họ thêm
thời gian để thực hiện công việc họ thích.
- Đối với người quản lý sản phẩm (Product Manager)
Người quản lý sản phẩm, người có vai trò sở hữu sản phẩm, chịu trách nhiệm làm cho khách
hàng hài lòng bằng cách đảm bảo rằng công việc phát triển phù hợp với nhu cầu của khách
hàng.
Scrum làm cho sự liên kết này dễ dàng hơn bằng cách sắp xếp lại công việc theo mức độ ưu
tiên nhằm đảm bảo công việc đạt được giá trị tối đa.
- Đối với các nhà quản lý dự án (Project Managers)
Người quản lý dự án là người lập kế hoạch, theo dõi các quy trình “waterfall”. Việc sử dụng
Burndown để hiển thị tiến trình công việc và các cuộc họp scrum hàng ngày đã giúp người
quản lý dự án nhận thức rõ ràng hơn về tình trạng của dự án.
Nhận thức được xem là chìa khóa quan trọng để theo dõi dự án và giải quyết các vấn đề
nhanh chóng. Scrum là gì?
Scrum là một tập hợp con của Agile với “bộ khung quy trình làm việc” cơ bản để tiếp cận
những công việc phức tạp và nó được sử dụng rộng rãi nhất.
Sự khác nhau giữa quy trình Scrum và quy trình Agile là các khái niệm và việc thực tiễn cụ
thể.
lOMoARcPSD| 47207194
Scrum thường được sử dụng để quản lý phát triển phần mềm và sản phẩm phức tạp.
Scrum làm tăng đáng kể năng suất và giảm thời gian so với các quá trình "waterfall" cổ
điển.
- Một quy trình Scrum mang lại lợi ích cho các tổ chức bằng cách - Tăng chất lượng
của các sản phẩm.
- Giao dịch tốt hơn.
- Tốn ít thời gian trong việc tạo ra các dự định tốt hơn.
- Kiểm soát được lịch trình dự án và trạng thái hoạt động. Các giá trị cốt lõi của Scrum
- Tính minh bạch (Transparency)
- Thanh tra (Inspection)
- Thích nghi (Adaptation)
- Lợi ích mà Scrum mang lại
Scrum có nhiều lợi thế hơn so với các phương pháp Agile khác. Nó hiện là khung tham chiếu
được sử dụng và đáng tin cậy nhất trong ngành công nghiệp phần mềm. Dưới đây là một số lợi
ích của Scrum:
- Có thể mở rộng dễ dàng
- Đề cao sự kỳ vọng của khách hàng
- Sự thay đổi linh hoạt
- Thời gian hoàn thành dự án linh hoạt
- Chất lượng phần mềm cao hơn
- Dự đoán kịp thời
- Giảm rủi ro
Ai được hưởng lợi nhất từ Scrum?
Scrum có thể hữu ích với nhiều doanh nghiệp và dự án, nhưng dưới đây mới là những
người được hưởng lợi nhất:
- Các dự án phức tạp
- Các công ty có giá trị kết quả
- Các công ty phục vụ cho khách hàng
Các vai trò khác nhau trong Scrum
Ba vai trò cốt lõi được xác định trong Scrum là Scrum Master, Product Owner và các Team.
Những người này sẽ làm việc chặt chẽ với nhau hàng ngày nhằm đảm bảo luồng thông tin luôn
hoạt động trơn tru và nhanh chóng giải quyết các vấn đề khi có phát sinh.
lOMoARcPSD| 47207194
-
Scrum Master có vai trò gì trong Scrum
Scrum Master là người đóng vai trò quan trọng trong việc giúp các thành viên trong nhóm
hiểu lý thuyết, các kỹ thuật thực hành, quy tắc, và giá trị của Scrum.
Scrum Master có trách nhiệm giúp cho quá trình diễn ra suôn sẻ, loại bỏ các chướng ngại
vật làm ảnh hưởng đến năng suất và tổ chức. Trách nhiệm của Scrum Masters bao gồm:
- Giúp Product Owner cách tối đa hóa lợi tức đầu tư (ROI) và đáp ứng các mục tiêu của
họ thông qua Scrum.
- Cải thiện cuộc sống của nhóm phát triển bằng cách tạo điều kiện giúp họ sáng tạo theo
mức mình muốn.
- Cải thiện năng suất của nhóm phát triển theo bất kỳ cách nào có thể.
- Cải thiện các thực tiễn và công cụ kỹ thuật để chia sẻ cho các thành viên trong nhóm
khác biết.
- Giữ thông tin về tiến trình của nhóm cập nhật và hiển thị cho tất cả các bên.
Product Owner có vai trò gì trong Scrum
Product Owner cung cấp "nguồn sự thật duy nhất" cho nhóm về các yêu cầu và lệnh
thực hiện theo kế hoạch của họ. Trong thực tế, Product Owner là cầu nối giữa doanh
nghiệp, khách hàng và sản phẩm của họ.
lOMoARcPSD| 47207194
- Product Owner làm việc chặt chẽ với Team để xác định các yêu cầu về người dùng và
kỹ thuật, để ghi lại các yêu cầu cần thiết và để xác định thứ tự triển khai của họ.
- Product Owner duy trì tồn đọng sản phẩm (Product Backlog) là kho lưu trữ cho tất cả
các thông tin còn tồn động trong việc phát triển phần mềm. Team có vai trò gì trong
Scrum
- Nhóm nghiên cứu là những người thực hiện công việc phát triển và thử nghiệm sản
phẩm. Vì nhóm chịu trách nhiệm sản xuất sản phẩm, nên cũng có thẩm quyền đưa ra
quyết định về cách thực hiện công việc.
- Do đó, các thành viên trong nhóm tự quyết định cách chia công việc và cách phân bổ
các nhiệm vụ cho các cá nhân, trong suốt quá trình triển khai dự án.
lOMoARcPSD| 47207194
-
Chương 3:
3.3 Các bộ công cụ CASE
3.3.1 Diagram tools
Ngôn ngữ mô hình hóa thống nhất (tiếng Anh: Unified Modeling Language, viết tắt thành
UML) là một ngôn ngữ mô hình gồm các ký hiệu đồ họa mà các phương pháp hướng đối
tượng sử dụng để thiết kế các hệ thống thông tin một cách nhanh chóng.
Cách xây dựng các mô hình trong UML phù hợp mô tả các hệ thống thông tin cả về cấu trúc
cũng như hoạt động. Cách tiếp cận theo mô hình của UML giúp ích rất nhiều cho những người
thiết kế và thực hiện hệ thống thông tin cũng như những người sử dụng nó; tạo n một cái
nhìn bao quát và đầy đủ về hệ thống thông tin dự định xây dựng. Cách nhìn bao quát này giúp
nắm bắt trọn vẹn các yêu cầu của người dùng; phục vụ từ giai đoạn phân tích đến việc thiết kế,
thẩm định và kiểm tra sản phẩm ứng dụng công nghệ thông tin. Các mô hình hướng đối tượng
được lập cũng là cơ sở cho việc ứng dụng các chương trình tự động sinh mã trong các ngôn
ngữ lập trình hướng đối tượng, chẳng hạn như ngôn ngữ C++, Java,... Phương pháp mô hình
này rất hữu dụng trong lập trình hướng đối tượng. Các mô hình được sử dụng bao gồm Mô
hình đối tượng (mô hình tĩnh) và Mô hình động.
UML sử dụng một hệ thống ký hiệu thống nhất biểu diễn các Phần tử mô hình (model
elements). Tập hợp các phần tử mô hình tạo thành các Sơ đồ UML (UML diagrams). Có các
loại sơ đồ UML chủ yếu sau:
Sơ đồ lớp (Class Diagram)
Sơ đồ đối tượng (Object Diagram)
Sơ đồ tình huống sử dụng (Use Cases Diagram)
Sơ đồ trình tự (Sequence Diagram)
Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram)
Sơ đồ trạng thái (State Machine Diagram)
Sơ đồ thành phần (Component Diagram)
Sơ đồ hoạt động (Activity Diagram)
Sơ đồ triển khai (Deployment Diagram)
Sơ đồ gói (Package Diagram)
Sơ đồ liên lạc (Communication Diagram)
Sơ đồ tương tác (Interaction Overview Diagram - UML 2.0)
lOMoARcPSD| 47207194
Sơ đồ phối hợp thời gian (Timing Diagram - UML 2.0)
lOMoARcPSD| 47207194
a) Một số dạng biểu đồ UML phổ biến
* Biểu đồ Use case (Use Case Diagram)
Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liên kết của chúng
đối với Use case mà hệ thống cung cấp.
Hệ thống: Với vai trò là thành phần của biểu đồ use case, hệ thống biểu diễn ranh giới
giữa bên trong và bên ngoài của một chủ thể trong phần mềm chúng ta xây dựng.Một hệ
thống ở trong biểu đồ use case không nhất thiết là một hệ phần mềm; nó có thể là một
chiếc máy,hoặc là một hệ thống thực như một doanh nghiệp, một trường đại học,
Tác nhân(actor):là người dùng của hệ thống, một tác nhân có thể là một người dùng
thực hoặc các hệ thống máy tính khác có vai trò nào đó trong hoạt động của hệ thống.
Như vậy, tác nhân thực hiện các use case. Một tác nhân có thể thực hiện nhiều use case
và ngược lại một use case cũng có thể được thực hiện bởi nhiều tác nhân
Tác nhân được kí hiệu:
hoặc
Các use case: Đây là thành phần cơ bản của biểu đồ use case. Các use case được biểu
diễn bởi các hình elip.Tên các use case thể hiện một chức năng xác định của hệ thống.
Các Use case được kí hiệu bằng hình elips.
Mối quan hệ giữa các use case:
o Association: thường được dùng để mô tả mối quan hệ giữa Actor và Use Case và
giữa các Use Case với nhau
lOMoARcPSD| 47207194
*Biểu đồ lớp (Class Diagram)
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. Các lớp là đại diện cho các
“đối tượng” được xử lý trong hệ thống. Các lớp có thể quan hệ với nhau trong nhiều dạng thức:
liên kết (associated - được nối kết với nhau),
phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác),
chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp
khác),
hay đóng gói ( packaged - hợp với nhau thành một đơn vị).
Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong
của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation). Biểu đồ được coi là
biểu đồ tĩnh theo phương diện cấu trúc được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào
trong toàn bộ vòng đời hệ thống.
Một hệ thống thường sẽ có một loạt các biểu đồ lớp – không phải bao giờ tất cả các biểu đồ lớp
này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có thể tham gia vào
nhiều biểu đồ lớp.
-Một lớp có các thành phần sau
Tên lớp
Các thuộc tính
Các phương thức
-Liên kết giữa các lớp
Liên kết (Association) o Mối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự liên kết
giữa các thể hiện của chúng
o Mối quan hệ về mặt cấu trúc chỉ ra các đối tượng của lớp này có kết nối với các
đối tượng của lớp khác.
| 1/38

Preview text:

lOMoAR cPSD| 47207194
BỘ TÀI CHÍNH TRƯỜNG ĐẠI HỌC TÀI CHÍNH –
MARKETING KHOA CÔNG NGHỆ THÔNG TIN --------------- -------------- BÁO CÁO MÔN HỌC
PHÁT TRIỂN HỆ THỐNG THÔNG TIN TRÊN CÁC FRAMEWORK
Mã lớp học phần: Đề tài:
XÂY DỰNG WEBSITE BÁN ĐIỆN THOẠI DI ĐỘNG
Giảng viên hướng dẫn: Mai Thanh Tâm
TP.HCM, Tháng 2 năm 2023 THÀNH VIÊN NHÓM 02:
1. Lê Thị Quỳnh Như – 2021010240 2. Lê Thân Diệu Yến lOMoAR cPSD| 47207194
3. Nguyễn Thị Quỳnh Như 4. Phạm Thanh Ngân 5. Nguyễn Đình Nguyên lOMoAR cPSD| 47207194 Mục lục
2.1 Khái niệm về phát triển hệ thống thông tin.......................................................................4
2.2 Tiêu chí lựa chọn phương pháp phát triển hệ thống thông tin...........................................6
2.3 Một số phương phát phải triển hệ thống thông tin............................................................7
2.3.1 Phương pháp phát triển truyền thống.........................................................................7
2.3.2 Phát triển ứng dụng nhanh (RAD)...........................................................................10
3.3 Các bộ công cụ CASE....................................................................................................13
3.3.1 Diagram tools...........................................................................................................13
3.3.2 Process Modeling tools............................................................................................17
3.3.3 Project Management tools........................................................................................18
3.3.4 Documentation tools................................................................................................20
3.3.5. Analysis Tools.........................................................................................................23
3.3.6. Design Tools...........................................................................................................24
3.3.7. Configuration Management Tools...........................................................................24
3.3.8. Change Control Tools.............................................................................................25
4.1.........................................................................................................................................30
4.1.1: Sơ lược về Ionic......................................................................................................31
4.1.2 Sơ lược về Meteor....................................................................................................32
4.2.3 Sơ lược về PhoneGap...............................................................................................34
4.1.4 Sơ lược về Angular UI.............................................................................................36
4.1.5 Sơ lược về Sencha Touch.........................................................................................38
4.1.6 Sơ lược về MVC......................................................................................................39
4.1.7 Sơ lược về Spring.....................................................................................................41
4.2 Ứng dung Framework.....................................................................................................43
4.2.1 Enterprite API..........................................................................................................43 Chương 2
2.1 Khái niệm về phát triển hệ thống thông tin -
Mục tiêu cuối cùng của những cố gắng phát triển hệ thống thông tin là cung cấp cho các
thành viên của tổ chức những công cụ quản lý tốt nhất. Phát triển một hệ thống thông tin bao
gồm việc phân tích hệ thống đang tồn tại, thiết kế một hệ thống mới, thực hiện và tiến hành cài lOMoAR cPSD| 47207194
đặt nó. Phân tích một hệ thống bắt đầu từ việc thu thập dữ liệu và chỉnh đốn chúng để đưa ra
được chẩn đoán về tình hình thực tế. -
Một phương pháp được định nghĩa như một tập hợp các bước và các công cụ cho phép
tiếnhành một quá trình phát triển hệ thống chặt chẽ nhưng dễ quản lý hơn. Phương pháp được
đề nghị ở đây dựa vào ba nguyên tắc cơ sở chung của nhiều phương pháp hiện đại có cấu trúc
để phát triển hệ thống thông tin. Ba nguyên tắc đó là :
Nguyên tắc 1. Sử dụng các mô hình.
Nguyên tắc 2. Chuyển từ cái chung sang cái riêng.
Nguyên tắc 3. Chuyển từ mô hình vật lý sang mô hình lô gíc khi phân tích và từ mô
hình lô gíc sang mô hình vật lý khi thiết kế.
Các công đoạn của phát triển hệ thống
Giai đoạn 1 : Đánh giá yêu cầu
1.1 Lập kế hoạch đánh giá yêu cầu. 1.2 Làm rõ yêu cầu.
1.3 Đánh giá khả năng thực thi.
1.4 Chuẩn bị và trình bày báo cáo đánh giá yêu cầu.
Giai đoạn 2 : Phân tích chi tiết
2.1 Lập kế hoạch phân tích chi tiết.
2.2 Nghiên cứu môi trường của hệ thống đang tồn tại.
2.3 Nghiên cứu hệ thống thực tại.
2.4 Đưa ra chẩn đoán và xác định các yếu tố giải pháp. lOMoAR cPSD| 47207194
2.5 Đánh giá lại tính khả thi.
2.6 Thay đổi đề xuất của dự án.
2.7 Chuẩn bị và trình bày báo cáo phân tích chi tiết.
Giai đoạn 3: Thiết kế lô gíc
3.1 Thiết kế cơ sở dữ liệu. 3.2 Thiết kế xử lý.
3.3 Thiết kế các luồng dữ liệu vào.
3.4 Chỉnh sửa tài liệu cho mức lô gíc.
3.5 Hợp thức hoá mô hình lô gíc.
Giai đoạn 4: Đề xuất các phương án của giải pháp
4.1 Xác định các ràng buộc tin học và ràng buộc tổ chức.
4.2 Xây dựng các phương án của giải pháp.
4.3 Đánh giá các phương án của giải pháp.
4.4 Chuẩn bị và tình bày báo cáo của giai đoạn đề xuất các phương án giải pháp.
Giai đoạn 5 : Thiết kế vật lý ngoài
5.1 Lập kế hoạch thiết kế vật lý ngoài
5.2 Thiết kế chi tiết các giao diện (vào/ ra)
5.3 Thiết kế cách thức tương tác với phần tin học hoá
5.4 Thiết kế các thủ tục thủ công
5.5 Chuẩn bị và trình bày báo cáo về thiết kế vật lý ngoài
Giai đoạn 6: Triển khai kỹ thuật hệ thống
6.1 Lập kế hoạch thực hiện kỹ thuật
6.2 Thiết kế vật lý trong 6.3 Lập trình
6.4 Thử nghiệm hệ thống 6.5 Chuẩn bị tài liệu
Giai đoạn 7: Cài đặt và khai thác
7.1 Lập kế hoạch cài đặt 7.2 Chuyển đổi 7.3 Khai thác và bảo trì 7.4 Đánh giá
2.2 Tiêu chí lựa chọn phương pháp phát triển hệ thống thông tin lOMoAR cPSD| 47207194 - Tiêu chí:
Phương pháp phải đảm bảo tính hiệu quả
Phương pháp có kế hoạch rõ ràng, và nguồn lực đầy đủ Yêu cầu
Giải pháp hoặc sản phẩm cuối cùng
Phản hồi về công việc đã làm
Tần suất yêu cầu thay đổi hoặc cải tiến Chi phí chậm trễ
Kinh nghiệm về các dự án
Do nhu cầu về các hệ thống thông tin doanh nghiệp giảm trở thành một câu hỏi quan trọng,
việc cải thiện mối quan hệ giá-chất lượng của sản phẩm phần mềm trở thành một câu hỏi quan trọng.
Nó đòi hỏi phải tăng mức chất lượng đồng thời với việc giảm chi phí cơ bản. Mục đích của
công việc nhất định là mô tả khả năng tối ưu hóa việc sử dụng tài nguyên bằng cách áp dụng
các phương pháp phát triển hệ thống khác nhau. Trong phân tích đã sử dụng các phương pháp
thác nước, lặp lại, xoắn ốc và nhanh nhẹn.
Các tiêu chí lựa chọn từ chúng được mô tả có tính đến sự cần thiết của việc giảm thiểu chi phí
và thời gian của dự án.
Trong công việc đã phân tích các rủi ro có thể xuất hiện khi áp dụng các phương pháp khác
nhau và cách giảm thiểu chúng. Do phân tích được thực hiện trong bài viết, đề xuất chọn
phương pháp không phải cho toàn bộ công ty mà cho từng dự án riêng biệt. Trong bài viết
được đưa ra các khuyến nghị thực tế có thể được sử dụng trong các dự án thực tế.
2.3 Một số phương phát phải triển hệ thống thông tin
2.3.1 Phương pháp phát triển truyền thống
Giai đoạn 1: Khảo sát dự án
Khảo sát hiện trạng là giai đoạn đầu tiên trong quá trình phát triển một hệ thống thông tin.
Nhiệm vụ chính trong giai đoạn này là tìm hiểu, thu thập thông tin cần thiết để chuẩn bị cho
việc giải quyết các yêu cầu được đặt ra của dự án. Giai đoạn khảo sát được chia làm hai bước: Bước 1: •
Khảo sát sơ bộ: tìm hiểu các yếu tố cơ bản (tổ chức, văn hóa, đặc trưng, con người,...)
tạo tiền đề để phát triển HTTT phù hợp với dự án và doanh nghiệp. lOMoAR cPSD| 47207194 •
Khảo sát chi tiết: thu thập thông tin chi tiết của hệ thống (chức năng xử lý, thông tin
được phép nhập và xuất khỏi hệ thống, ràng buộc, giao diện cơ bản, nghiệp vụ) phục vụ
cho việc phân tích và thiết kế.
Bước 2: Đặt ra các vấn đề trọng tâm cần phải giải quyết, như: •
Thông tin đưa vào hệ thống phải như thế nào? •
Dữ liệu hiển thị và xuất ra khác nhau ở những điểm nào? •
Ràng buộc giữa các đối tượng trong hệ thống cần xây được dựng ra sao? •
Chức năng và quy trình xử lý của hệ thống phải đảm bảo những yêu cầu nào? •
Cần sử dụng những giải pháp nào? Tính khả thi của từng giải pháp ra sao?
Từ những thông tin thu thập được và vấn đề đã đặt ra trong giai đoạn khảo sát, nhà quản trị và
các chuyên gia sẽ chọn lọc những yếu tố cần thiết để cấu thành hệ thống thông tin riêng cho doanh nghiệp.
Giai đoạn 2: Phân tích hệ thống
Mục tiêu của giai đoạn là xác định các thông tin và chức năng xử lý của hệ thống, cụ thể như sau: •
Xác định yêu cầu của HTTT gồm: các chức năng chính - phụ; nghiệp vụ cần phải xử lý
đảm bảo tính chính xác, tuân thủ đúng các văn bản luật và quy định hiện hành; đảm bảo
tốc độ xử lý và khả năng nâng cấp trong tương lai. •
Phân tích và đặc tả mô hình phân cấp chức năng tổng thể thông qua sơ đồ BFD
(Business Flow Diagram), từ mô hình BFD sẽ tiếp tục được xây dựng thành mô hình
luồng dữ liệu DFD (Data Flow Diagram) thông qua quá trình phân rã chức năng theo
các mức 0, 1, 2 ở từng ô xử lý. •
Phân tích bảng dữ liệu. Cần đưa vào hệ thống những bảng dữ liệu (data table) gồm các
trường dữ liệu (data field) nào? Xác định khóa chính (primary key), khóa ngoại (foreign
key) cũng như mối quan hệ giữa các bảng dữ liệu (relationship) và ràng buộc
(constraint) dữ liệu cần thiết.
Ở giai đoạn này, các chuyên gia sẽ đặc tả sơ bộ các bảng dữ liệu trên giấy để có cái nhìn khách
quan. Qua đó, xác định các giải pháp tốt nhất cho hệ thống đảm bảo đúng các yêu cầu đã khảo
sát trước khi thực hiện trên các phần mềm chuyên dụng. Giai đoạn 3: Thiết kế lOMoAR cPSD| 47207194
Thông qua thông tin được thu thập từ quá trình khảo sát và phân tích, các chuyên gia sẽ
chuyển hóa vào phần mềm, công cụ chuyên dụng để đặc tả thiết kế hệ thống chi tiết. Giai đoạn
này được chia làm hai bước sau:
Bước 1: Thiết kế tổng thể
Trên cơ sở các bảng dữ liệu đã phân tích và đặc tả trên giấy sẽ được thiết kế dưới dạng mô
hình mức ý niệm bằng phần mềm chuyên dụng như Sybase PowerDesigner, CA ERwin
Data Modeler. Bằng mô hình mức ý niệm sẽ cho các chuyên gia có cái nhìn tổng quát nhất
về mối quan hệ giữa các đối tượng trước khi chuyển đổi thành mô hình mức vật lý. Bước 2: Thiết kế chi tiết •
Thiết kế cơ sở dữ liệu (Database): Với mô hình mức vật lý hoàn chỉnh ở giai đoạn thiết
kế đại thể sẽ được kết sinh mã thành file sql. •
Thiết kế truy vấn, thủ tục, hàm: thu thập, xử lý thông tin nhập và đưa ra thông tin chuẩn
xác theo đúng nghiệp vụ. •
Thiết kế giao diện chương trình đảm bảo phù hợp với môi trường, văn hóa và yêu cầu
của doanh nghiệp thực hiện dự án. •
Thiết kế chức năng chương trình đảm bảo tính logic trong quá trình nhập liệu và xử lý cho người dùng. •
Thiết kế báo cáo. Dựa trên các yêu cầu của mỗi doanh nghiệp và quy định hiện hành sẽ
thiết kế các mẫu báo cáo phù hợp hoặc cho phép doanh nghiệp tư tạo mẫu báo cáo ngay trên hệ thống. •
Thiết kế các kiểm soát bằng hình thức đưa ra các thông báo, cảnh báo hoặc lỗi cụ thể
tạo tiện lợi và kiểm soát chặt chẽ quá trình nhập liệu với mục tiêu tăng độ chính xác cho dữ liệu.
Tóm lại, thiết kế là việc áp dụng các công cụ, phương pháp, thủ tục để tạo ra mô hình hệ
thống cần sử dụng. Sản phẩm cuối cùng của giai đoạn thiết kế là đặc tả hệ thống ở dạng nó
tồn tại thực tế, sao cho nhà lập trình và kỹ sư phần cứng có thể dễ dàng chuyển thành chương
trình và cấu trúc hệ thống. Giai đoạn 4: Thực hiện
Đây là giai đoạn nhằm xây dựng hệ thống theo các thiết kế đã xác định. Giai đoạn này bao gồm các công việc sau: •
Lựa chọn hệ quản trị cơ sở dữ liệu (SQL Server, Oracle, MySQL, …) và cài đặt cơ sở dữ liệu cho hệ thống. lOMoAR cPSD| 47207194 •
Lựa chọn công cụ lập trình để xây dựng các modules chương trình của hệ thống
(Microsoft Visual Studio, PHP Designer,...). •
Lựa chọn công cụ để xây dựng giao diện hệ thống (DevExpress, Dot Net Bar,...).
Viết tài liệu hướng dẫn sử dụng, tài liệu kỹ thuật hoặc clip hướng dẫn. Giai đoạn 5: Kiểm thử •
Trước hết phải lựa chọn công cụ kiểm thử. •
Kiểm chứng các modules chức năng của hệ thống thông tin, chuyển các thiết kế thành
các chương trình (phần mềm). •
Thử nghiệm hệ thống thông tin. •
Cuối cùng là khắc phục các lỗi (nếu có). •
Viết test case theo yêu cầu.
Kết quả cuối cùng là một hệ thống thông tin đạt yêu cầu đặt ra.
Giai đoạn 6: Triển khai và bảo trì •
Lắp đặt phần cứng để làm cơ sở cho hệ thống. • Cài đặt phần mềm. •
Chuyển đổi hoạt động của hệ thống cũ sang hệ thống mới, gồm có: chuyển đổi dữ liệu;
bố trí, sắp xếp người làm việc trong hệ thống; tổ chức hệ thống quản lý và bảo trì. •
Phát hiện các sai sót, khuyết điểm của hệ thống thông tin. •
Đào tạo và hướng dẫn sử dụng. •
Cải tiến và chỉnh sửa hệ thống thông tin. • Bảo hành. •
Nâng cấp chương trình khi có phiên bản mới
2.3.3 Phương pháp linh hoạt (Agile Scrum) Agile Scrum là gì?
Agile Scrum là một hệ thống quản lý dự án dựa trên Sprint với mục tiêu cung cấp giá trị cao
nhất cho các bên liên quan.
Agile và Scrum là hai phương pháp khác nhau có thể được sử dụng riêng biệt.
Sự khác biệt giữa Agile và Scrum là gì?
Mặc dù Agile và Scrum là tương tự nhau, nhưng chúng có một số khác biệt như:
- Agile hoạt động linh hoạt hơn Scrum.
- Agile có người lãnh đạo đóng vai trò quan trọng trong khi Scrum là một nhóm chức
năng chéo tự hoạt động.
- Agile với chức năng đơn giản mặc định trong khi Scrum có thể sáng tạo và thử nghiệm. lOMoAR cPSD| 47207194
- Agile cung cấp dự án từ đầu đến cuối trong khi Scrum chỉ cung cấp các dự án ngắn hạn.
Lợi ích mà Agile Scrum mang lại
- Tính linh hoạt và khả năng thích ứng
- Sáng tạo và đổi mới - Giảm chi phí
- Cải thiện chất lượng - Tổ chức Synergy
- Sự hài lòng của nhân viên
- Sự hài lòng của khách hàng
Lợi ích lớn nhất của phương pháp Agile Scrum là tính linh hoạt. Với mô hình hoạt động dựa
trên Sprint, nhóm Scrum thường nhận được phản hồi từ các bên liên quan sau mỗi dự án.
Nếu có bất kỳ vấn đề hoặc thay đổi nào, nhóm Scrum có thể dễ dàng và nhanh chóng điều
chỉnh. Điều này đã giúp các bên có liên quan đến dự án cảm thấy tốt hơn vì họ được làm
những điều họ muốn. Ngoài ra, họ còn được tham gia vào từng bước của dự án.
So sánh điều này với hệ thống quản lý dự án truyền thống cho thấy hệ thống Scrum phản hồi
thường xuyên tránh việc lãng phí thời gian.
Điều đó giúp các bên liên quan hiểu nhau hơn tránh xảy ra trường hợp phải bắt đầu lại dự án
sau khi sản phẩm đã được xây dựng vì sự không hiểu nhau giữa các bên.
Để thực hiện phương pháp Agile Scrum, phải có chuyên gia Scrum trong công ty hoặc một nhà
tư vấn bên ngoài để đảm bảo các nguyên tắc Scrum được áp dụng chính xác.
Phương pháp Agile Scrum có thể dẫn đến các vấn đề nghiêm trọng nếu không được thực hiện đúng. Agile là gì?
Agile Software Developer là phát triển phần mềm linh hoạt. Agile có nghĩa là khả năng phát
triển hoặc thích nghi với sự thay đổi của hoàn cảnh một cách nhanh chóng thông qua sự hợp
tác giữa các nhóm tự tổ chức và chức năng chéo với các khách hàng là những người dùng
cuối. Agile sẽ lập kế hoạch, phát triển, phân phối, cải tiến liên tục và phản ứng linh hoạt với
những thay đổi về yêu cầu, năng lực và sự hiểu biết về các vấn đề cần giải quyết, phù hợp với
sự phát triển của khách hàng và mục tiêu của các công ty.
Agile đề cập đến quá trình phát triển phù hợp với các khái niệm của tuyên ngôn Agile. Tuyên
ngôn được phát triển bởi một nhóm mười bốn nhân vật hàng đầu trong ngành công nghiệp phần mềm. lOMoAR cPSD| 47207194
Các giá trị cốt lõi của Agile
- Agile lần đầu tiên được mô tả trong Tuyên ngôn Agile vào năm 2000 bởi một nhóm các
nhà phát triển đã tìm kiếm một phương pháp viết phần mềm mới. Bản tuyên ngôn trích dẫn bốn giá trị sau:
- Cá nhân và sự tương tác hơn là các quy trình và công cụ.
- Phần mềm chạy tốt hơn là tài liệu đầy đủ.
- Đàm phán với khách hàng hơn là đàm phán bằng hợp đồng.
- Phản hồi với sự thay đổi hơn là theo kế hoạch.
12 nguyên tắc của Agile
Bản tuyên ngôn Agile ban hành 12 nguyên tắc liên quan đến việc phát triển phần mềm. Về sau
được cấu hình lại để phù hợp với quan điểm của người dùng:
- Sự hài lòng của khách hàng
- Giao hàng sớm và liên tục - Nắm lấy cơ hội - Giao hàng thường xuyên
- Hợp tác của các doanh nghiệp và nhà phát triển
- Các cá nhân có động lực
- Đối thoại trực tiếp - Sản phẩm chức năng - Kỹ thuật xuất sắc lOMoAR cPSD| 47207194 Sự đơn giản
- Các đội tự tổ chức
- Quy định, phản ánh và điều chỉnh -
Lợi ích mà Agile mang lại
Lợi ích mà Agile mang lại - Đối với khách hàng
Nhà cung cấp đã phản ứng nhanh với các yêu cầu phát triển, việc này đã làm khách hàng rất
hài lòng. Trong thời gian ngắn thì các tính năng có giá trị cao được phát triển và cung cấp
nhanh hơn. So với thời gian ngắn thì thời gian dài với quy trình “waterfall” vẫn được ưa chuộng hơn.
- Đối với các nhà cung cấp
Các nhà cung cấp tập trung nỗ lực phát triển vào các tính năng có giá trị cao đồng thời giảm
thời gian so với các quy trình “waterfall” do giảm chi phí và tăng sự hiệu quả. Cải thiện sự
hài lòng của khách hàng sau đó việc duy trì khách hàng sẽ trở nên tốt hơn. - Đối với nhóm
phát triển (Development Teams)
Là thành viên trong nhóm phát triển, họ rất thích khi các dự án họ phát triển được khách hàng
sử dụng và tạo ra giá trị. lOMoAR cPSD| 47207194 -
Scrum mang lại lợi ích cho các thành viên trong nhóm bằng cách giảm công việc không sản
xuất, ví dụ: viết thông số kỹ thuật hoặc các tạo tác khác mà không ai sử dụng. Và cho họ thêm
thời gian để thực hiện công việc họ thích.
- Đối với người quản lý sản phẩm (Product Manager)
Người quản lý sản phẩm, người có vai trò sở hữu sản phẩm, chịu trách nhiệm làm cho khách
hàng hài lòng bằng cách đảm bảo rằng công việc phát triển phù hợp với nhu cầu của khách hàng.
Scrum làm cho sự liên kết này dễ dàng hơn bằng cách sắp xếp lại công việc theo mức độ ưu
tiên nhằm đảm bảo công việc đạt được giá trị tối đa.
- Đối với các nhà quản lý dự án (Project Managers)
Người quản lý dự án là người lập kế hoạch, theo dõi các quy trình “waterfall”. Việc sử dụng
Burndown để hiển thị tiến trình công việc và các cuộc họp scrum hàng ngày đã giúp người
quản lý dự án nhận thức rõ ràng hơn về tình trạng của dự án.
Nhận thức được xem là chìa khóa quan trọng để theo dõi dự án và giải quyết các vấn đề nhanh chóng. Scrum là gì?
Scrum là một tập hợp con của Agile với “bộ khung quy trình làm việc” cơ bản để tiếp cận
những công việc phức tạp và nó được sử dụng rộng rãi nhất.
Sự khác nhau giữa quy trình Scrum và quy trình Agile là các khái niệm và việc thực tiễn cụ thể. lOMoAR cPSD| 47207194
Scrum thường được sử dụng để quản lý phát triển phần mềm và sản phẩm phức tạp.
Scrum làm tăng đáng kể năng suất và giảm thời gian so với các quá trình "waterfall" cổ điển.
- Một quy trình Scrum mang lại lợi ích cho các tổ chức bằng cách - Tăng chất lượng của các sản phẩm. - Giao dịch tốt hơn.
- Tốn ít thời gian trong việc tạo ra các dự định tốt hơn.
- Kiểm soát được lịch trình dự án và trạng thái hoạt động. Các giá trị cốt lõi của Scrum
- Tính minh bạch (Transparency) - Thanh tra (Inspection) - Thích nghi (Adaptation)
- Lợi ích mà Scrum mang lại
Scrum có nhiều lợi thế hơn so với các phương pháp Agile khác. Nó hiện là khung tham chiếu
được sử dụng và đáng tin cậy nhất trong ngành công nghiệp phần mềm. Dưới đây là một số lợi
ích của Scrum:
- Có thể mở rộng dễ dàng
- Đề cao sự kỳ vọng của khách hàng
- Sự thay đổi linh hoạt
- Thời gian hoàn thành dự án linh hoạt
- Chất lượng phần mềm cao hơn - Dự đoán kịp thời - Giảm rủi ro
Ai được hưởng lợi nhất từ Scrum?
Scrum có thể hữu ích với nhiều doanh nghiệp và dự án, nhưng dưới đây mới là những
người được hưởng lợi nhất: - Các dự án phức tạp
- Các công ty có giá trị kết quả
- Các công ty phục vụ cho khách hàng
Các vai trò khác nhau trong Scrum
Ba vai trò cốt lõi được xác định trong Scrum là Scrum Master, Product Owner và các Team.
Những người này sẽ làm việc chặt chẽ với nhau hàng ngày nhằm đảm bảo luồng thông tin luôn
hoạt động trơn tru và nhanh chóng giải quyết các vấn đề khi có phát sinh. lOMoAR cPSD| 47207194 -
Scrum Master có vai trò gì trong Scrum
Scrum Master là người đóng vai trò quan trọng trong việc giúp các thành viên trong nhóm
hiểu lý thuyết, các kỹ thuật thực hành, quy tắc, và giá trị của Scrum.
Scrum Master có trách nhiệm giúp cho quá trình diễn ra suôn sẻ, loại bỏ các chướng ngại
vật làm ảnh hưởng đến năng suất và tổ chức. Trách nhiệm của Scrum Masters bao gồm:
- Giúp Product Owner cách tối đa hóa lợi tức đầu tư (ROI) và đáp ứng các mục tiêu của họ thông qua Scrum.
- Cải thiện cuộc sống của nhóm phát triển bằng cách tạo điều kiện giúp họ sáng tạo theo mức mình muốn.
- Cải thiện năng suất của nhóm phát triển theo bất kỳ cách nào có thể.
- Cải thiện các thực tiễn và công cụ kỹ thuật để chia sẻ cho các thành viên trong nhóm khác biết.
- Giữ thông tin về tiến trình của nhóm cập nhật và hiển thị cho tất cả các bên.
Product Owner có vai trò gì trong Scrum
Product Owner cung cấp "nguồn sự thật duy nhất" cho nhóm về các yêu cầu và lệnh
thực hiện theo kế hoạch của họ. Trong thực tế, Product Owner là cầu nối giữa doanh
nghiệp, khách hàng và sản phẩm của họ. lOMoAR cPSD| 47207194
- Product Owner làm việc chặt chẽ với Team để xác định các yêu cầu về người dùng và
kỹ thuật, để ghi lại các yêu cầu cần thiết và để xác định thứ tự triển khai của họ.
- Product Owner duy trì tồn đọng sản phẩm (Product Backlog) là kho lưu trữ cho tất cả
các thông tin còn tồn động trong việc phát triển phần mềm. Team có vai trò gì trong Scrum
- Nhóm nghiên cứu là những người thực hiện công việc phát triển và thử nghiệm sản
phẩm. Vì nhóm chịu trách nhiệm sản xuất sản phẩm, nên cũng có thẩm quyền đưa ra
quyết định về cách thực hiện công việc.
- Do đó, các thành viên trong nhóm tự quyết định cách chia công việc và cách phân bổ
các nhiệm vụ cho các cá nhân, trong suốt quá trình triển khai dự án. lOMoAR cPSD| 47207194 - Chương 3:
3.3 Các bộ công cụ CASE
3.3.1 Diagram tools
Ngôn ngữ mô hình hóa thống nhất (tiếng Anh: Unified Modeling Language, viết tắt thành
UML) là một ngôn ngữ mô hình gồm các ký hiệu đồ họa mà các phương pháp hướng đối
tượng sử dụng để thiết kế các hệ thống thông tin một cách nhanh chóng.
Cách xây dựng các mô hình trong UML phù hợp mô tả các hệ thống thông tin cả về cấu trúc
cũng như hoạt động. Cách tiếp cận theo mô hình của UML giúp ích rất nhiều cho những người
thiết kế và thực hiện hệ thống thông tin cũng như những người sử dụng nó; tạo nên một cái
nhìn bao quát và đầy đủ về hệ thống thông tin dự định xây dựng. Cách nhìn bao quát này giúp
nắm bắt trọn vẹn các yêu cầu của người dùng; phục vụ từ giai đoạn phân tích đến việc thiết kế,
thẩm định và kiểm tra sản phẩm ứng dụng công nghệ thông tin. Các mô hình hướng đối tượng
được lập cũng là cơ sở cho việc ứng dụng các chương trình tự động sinh mã trong các ngôn
ngữ lập trình hướng đối tượng, chẳng hạn như ngôn ngữ C++, Java,... Phương pháp mô hình
này rất hữu dụng trong lập trình hướng đối tượng. Các mô hình được sử dụng bao gồm Mô
hình đối tượng (mô hình tĩnh) và Mô hình động.
UML sử dụng một hệ thống ký hiệu thống nhất biểu diễn các Phần tử mô hình (model
elements). Tập hợp các phần tử mô hình tạo thành các Sơ đồ UML (UML diagrams). Có các
loại sơ đồ UML chủ yếu sau: •
Sơ đồ lớp (Class Diagram) •
Sơ đồ đối tượng (Object Diagram) •
Sơ đồ tình huống sử dụng (Use Cases Diagram) •
Sơ đồ trình tự (Sequence Diagram) •
Sơ đồ cộng tác (Collaboration Diagram hay là Composite Structure Diagram) •
Sơ đồ trạng thái (State Machine Diagram) •
Sơ đồ thành phần (Component Diagram) •
Sơ đồ hoạt động (Activity Diagram) •
Sơ đồ triển khai (Deployment Diagram) •
Sơ đồ gói (Package Diagram) •
Sơ đồ liên lạc (Communication Diagram) •
Sơ đồ tương tác (Interaction Overview Diagram - UML 2.0) lOMoAR cPSD| 47207194 •
Sơ đồ phối hợp thời gian (Timing Diagram - UML 2.0) lOMoAR cPSD| 47207194
a) Một số dạng biểu đồ UML phổ biến
* Biểu đồ Use case (Use Case Diagram)
Một biểu đồ Use case chỉ ra một số lượng các tác nhân ngoại cảnh và mối liên kết của chúng
đối với Use case mà hệ thống cung cấp. •
Hệ thống: Với vai trò là thành phần của biểu đồ use case, hệ thống biểu diễn ranh giới
giữa bên trong và bên ngoài của một chủ thể trong phần mềm chúng ta xây dựng.Một hệ
thống ở trong biểu đồ use case không nhất thiết là một hệ phần mềm; nó có thể là một
chiếc máy,hoặc là một hệ thống thực như một doanh nghiệp, một trường đại học,… •
Tác nhân(actor):là người dùng của hệ thống, một tác nhân có thể là một người dùng
thực hoặc các hệ thống máy tính khác có vai trò nào đó trong hoạt động của hệ thống.
Như vậy, tác nhân thực hiện các use case. Một tác nhân có thể thực hiện nhiều use case
và ngược lại một use case cũng có thể được thực hiện bởi nhiều tác nhân
Tác nhân được kí hiệu: hoặc •
Các use case: Đây là thành phần cơ bản của biểu đồ use case. Các use case được biểu
diễn bởi các hình elip.Tên các use case thể hiện một chức năng xác định của hệ thống.
Các Use case được kí hiệu bằng hình elips. •
Mối quan hệ giữa các use case:
o Association: thường được dùng để mô tả mối quan hệ giữa Actor và Use Case và
giữa các Use Case với nhau lOMoAR cPSD| 47207194
*Biểu đồ lớp (Class Diagram)
Một biểu đồ lớp chỉ ra cấu trúc tĩnh của các lớp trong hệ thống. Các lớp là đại diện cho các
“đối tượng” được xử lý trong hệ thống. Các lớp có thể quan hệ với nhau trong nhiều dạng thức: •
liên kết (associated - được nối kết với nhau), •
phụ thuộc (dependent - một lớp này phụ thuộc vào lớp khác), •
chuyên biệt hóa (specialized - một lớp này là một kết quả chuyên biệt hóa của lớp khác), •
hay đóng gói ( packaged - hợp với nhau thành một đơn vị).
Tất cả các mối quan hệ đó đều được thể hiện trong biểu đồ lớp, đi kèm với cấu trúc bên trong
của các lớp theo khái niệm thuộc tính (attribute) và thủ tục (operation). Biểu đồ được coi là
biểu đồ tĩnh theo phương diện cấu trúc được miêu tả ở đây có hiệu lực tại bất kỳ thời điểm nào
trong toàn bộ vòng đời hệ thống.
Một hệ thống thường sẽ có một loạt các biểu đồ lớp – không phải bao giờ tất cả các biểu đồ lớp
này cũng được nhập vào một biểu đồ lớp tổng thể duy nhất – và một lớp có thể tham gia vào nhiều biểu đồ lớp.
-Một lớp có các thành phần sau • Tên lớp • Các thuộc tính • Các phương thức
-Liên kết giữa các lớp •
Liên kết (Association) o Mối liên hệ ngữ nghĩa giữa hai hay nhiều lớp chỉ ra sự liên kết
giữa các thể hiện của chúng
o Mối quan hệ về mặt cấu trúc chỉ ra các đối tượng của lớp này có kết nối với các
đối tượng của lớp khác.